以下、図面を参照して本発明の実施形態について詳細に説明する。以下に説明する実施の形態は、競馬においてインターネット投票によりユーザが馬券(勝馬投票券)を購入するための情報処理システムに対して本発明を適用した場合の実施形態である。レースに出場する競走馬は、本発明におけるレース対象の一例である。馬券は、本発明における投票券の一例である。なお、本発明が適用可能なレースは競馬に限られない。例えば、競輪、競艇、オートレース等の公営競技等に本発明が適用可能である。
[1.第1実施形態]
[1−1.情報処理システムの構成及び機能概要]
先ず、本実施形態に係る情報処理システムSの構成について、図1を用いて説明する。図1は、本実施形態に係る情報処理システムSの概要構成の一例を示す図である。
図1に示すように、情報処理システムSは、馬券発売代行サーバ1と、主催元サーバ2と、複数のユーザ端末3と、を含んで構成されている。そして、馬券発売代行サーバ1と主催元サーバ2と各ユーザ端末3とは、ネットワークNWを介して、例えば、通信プロトコルにTCP/IP等を用いて相互にデータの送受信が可能になっている。なお、ネットワークNWは、例えば、インターネット、専用通信回線(例えば、CATV(Community Antenna Television)回線)、移動体通信網(基地局等を含む)、及びゲートウェイ等により構築されている。
馬券発売代行サーバ1は、競馬の主催者に代わって馬券を発売するための競馬サイトに関する各種処理を行うサーバ装置である。馬券発売代行サーバ1は、本発明における情報処理装置の一例である。馬券発売代行サーバ1は、主催者が発表するレースに関する情報を、主催元サーバ2から取得する。また、馬券発売代行サーバ1は、ユーザ端末3からの要求に応じて、ウェブページを送信する。これにより、馬券発売代行サーバ1は、レースに関する情報等を提供する。提供される情報としては、例えば、出馬表、オッズ、予想、レース結果等がある。また、馬券発売代行サーバ1は、例えば、馬券の購入を受け付ける処理を行ったり、的中した馬券に対する払い戻しの処理を行ったりする。
競馬サイトのユーザは、馬券を購入するとき、買い目や購入金額(または購入枚数)等を選択する。買い目は、式別(投票法)、及び、投票対象としてユーザが選択した競走馬又は枠を含む。投票対象の競走馬又は枠は、馬番又は枠番で指定される。馬番の組み合わせだけではなく、着順をも的中させる式別の場合、買い目は、各投票対象の競走馬に対する着順も含む。
また、馬券発売代行サーバ1は、ユーザ端末3からの要求に基づいて、ユーザによるレースの予想の投稿を受け付ける。ユーザは、予想を投稿するとき、着順が上位であると予想する競走馬として、本命(favorite)、対抗(rival)、単穴(dark horse)及び連下(lower level)を選択する。本命、対抗、単穴及び連下の何れかに選択された競走馬を、予想馬と称する。
主催元サーバ2は、競馬の主催者がレースの情報を提供したり、馬券を発行したりするために設置されたサーバ装置である。主催元サーバ2は、レースに関する情報を馬券発売代行サーバ1へ送信する。また、主催元サーバ2は、購入情報DB22a、オッズ情報DB22b等のデータベースを備える。購入情報DB22aには、馬券の購入者による購入内容に関する馬券購入情報が登録される。馬券購入情報は、本発明における購入情報の一例である。購入情報DB22aには、馬券発売代行サーバ1により管理される競馬サイトでの馬券の購入に関する馬券購入情報が少なくとも登録される。また、購入情報DB22aには、例えば、馬券場での馬券の購入に関する馬券購入情報や、馬券発売代行サーバ1により管理される競馬サイトとは異なるサイトでの馬券の購入に関する馬券購入情報等が登録されてもよい。オッズ情報DB22bには、馬券のオッズに関するオッズ情報が登録される。主催元サーバ2は、購入情報DB22aに登録された馬券購入情報に基づいて、馬券のオッズを計算する。そして、主催元サーバ2は、計算したオッズをオッズ情報DB22bに登録する。主催元サーバ2が計算したオッズは、馬券が的中した場合の払戻金額の計算の基礎となる。
ユーザ端末3は、馬券発売代行サーバ1により管理される競馬サイトを利用するユーザの端末装置である。ユーザ端末3は、ユーザからの操作に基づいて馬券発売代行サーバ1にアクセスすることにより、馬券発売代行サーバ1からウェブページを受信して表示する。ユーザ端末3には、ブラウザや電子メールクライアント等のソフトウェアが組み込まれている。ユーザ端末3としては、例えば、パーソナルコンピュータ、PDA(Personal Digital Assistant)、スマートフォン等の携帯情報端末、携帯電話機等が用いられる。
このような構成の情報処理システムSにおいて、馬券発売代行サーバ1は、レースに出場する複数の競走馬の人気を示す予想支援情報をユーザ端末2へ提供する。予想支援情報は、本発明における人気情報の一例である。競走馬の人気は、例えば馬券の購入に基づく競走馬の評価である。予想支援情報の例として、オッズ、人気順位等がある。馬券の式別に応じて選択可能な複数の買い目(または、購入可能な馬券)の中で、相対的にオッズが低い買い目ほど、人気が高い買い目である。例えば、単勝、複勝の場合、相対的にオッズが高い競走馬ほど、人気が高い競走馬である。人気順位は、馬券の式別に応じて選択可能な複数の買い目を、オッズが低い順に並べたときの各買い目の順位を示す。ユーザは、予想支援情報を、勝馬等のレースの結果を予想したり、購入する馬券の買い目を決定したりするための参考にする場合がある。
馬券発売代行サーバ1は、ユーザ端末からの要求に応じて、オッズページをユーザ端末2へ送信する。オッズページは、予想支援情報が表示されるウェブページである。馬券発売代行サーバ1は、主催元サーバ2からオッズ情報を取得する。そして、馬券発売代行サーバ1は、オッズ情報に基づいてオッズページを生成する。主催元サーバ2から取得されたオッズ情報に含まれるオッズ及び人気順位を、基本予想支援情報という。基本予想支援情報は、本発明における基準人気情報の一例である。
[1−2.馬券発売代行サーバの構成]
次に、馬券発売代行サーバ1の構成について、図2及び図3を用いて説明する。
図2(a)は、本実施形態に係る馬券発売代行サーバ1の概要構成の一例を示すブロック図である。図2(a)に示すように、馬券発売代行サーバ1は、通信部11と、記憶部12と、入出力インターフェース13と、システム制御部14と、を備えている。そして、システム制御部14と入出力インターフェース13とは、システムバス15を介して接続されている。
通信部11は、ネットワークNWに接続してユーザ端末3等との通信状態を制御するようになっている。
記憶部12は、本発明における記憶手段、履歴記憶手段、人気情報記憶手段の一例である。記憶手段、履歴記憶手段及び人気情報記憶手段は同一のデバイスで構成されてもよいし、互いに異なるデバイスで構成されてもよい。記憶部12は、例えば、ハードディスクドライブ等により構成されている。この記憶部12には、会員情報DB12a、レース情報DB12b、馬券情報DB12c、購入情報DB12d、オッズ情報DB12e、予想情報DB12f、操作履歴DB12g、レース結果DB12h等のデータベースが構築されている。「DB」は、データベースの略語である。
図3(a)は、会員情報DB12aに登録される内容の一例を示す図である。会員情報DB12aには、競馬サイトに会員登録しているユーザに関する会員情報が、ユーザごとに対応付けて登録される。具体的に、会員情報DB12aには、ユーザID、パスワード、ニックネーム、氏名、生年月日、性別、郵便番号、住所、電話番号、電子メールアドレス、クレジットカード情報等のユーザの属性が対応付けて登録される。ユーザIDは、ユーザの識別情報である。ユーザIDは、本発明におけるユーザ識別情報の一例である。
図3(b)は、レース情報DB12bに登録される内容の一例を示す図である。レース情報DB12bには、レースに関するレース情報が、レースとレース情報の更新日時との組み合わせごとに登録される。具体的に、レース情報DB12bには、レースID、更新日時、レース名、グレード、競馬場ID、開催日、販売締切時刻、発走時刻、レース番号、馬場情報、出走馬情報、騎手情報等の情報が対応付けて登録される。レースIDは、レースの識別情報である。レースIDは、本発明におけるレース式別情報の一例である。更新日時は、レース情報が更新された日時である。例えば、主催元サーバ2は、或るレースについて最初にレース情報を馬券発売代行サーバ1へ送信するとき、その送信日時を更新日時として含むレース情報を送信する。また例えば、レース情報に含まれる複数の項目の情報のうち少なくとも1つの項目の情報が変更されたとき、主催元サーバ2は、変更後のレース情報を馬券発売代行サーバ1へ送信する。このとき、変更日時を更新日時として含むレース情報が送信される。馬券発売代行サーバ1は、主催元サーバ2から受信したレース情報をレース情報DB12bに登録する。競馬場IDは、レースが開催される競馬場の識別情報である。販売締切時刻は、馬券の販売が締め切られる時刻である。すなわち、販売締切時刻まで馬券の購入が可能である。発走時刻は、レースが開始される時刻である。馬場情報は、例えば、馬場状態等を含む。出走馬情報は、レースに出場する競走馬に関する情報である。例えば、出走馬情報には、出走馬の馬番、枠番、馬名、馬体重、前回のレースからの馬体重の増減、過去ノーレースのレースタイム、勝利数、勝率等が登録されている。騎手情報は、競走馬に騎乗する騎手に関する情報である。例えば、騎手情報には、騎乗する競走馬の馬番、騎手名、騎手の過去の成績、騎手変更の有無等が、競走馬ごとに登録される。
図3(c)は、馬券情報DB12cに登録される内容の一例を示す図である。馬券情報DB12cには、発売される馬券に関する馬券情報が、馬券ごとに登録されている。具体的に、馬券情報DB12cには、レースID、買い目情報等が対応付けて登録される。レースIDは、買い目情報が示す馬券が、どのレースの馬券であるかを示す。買い目情報は、馬券ID、式別及び投票対象の番号を含む。馬券IDは、馬券の識別情報である。式別として、例えば、単勝式、複勝式、枠番号二連勝複式(枠複)、枠番号二連勝単式(枠単)、馬番号二連勝単式(馬複)、馬番号二連勝単式(馬単)、拡大馬番号二連勝複式(ワイド)、馬番号三連勝複式(三連複)、番号三連勝単式(三連単)等がある。投票対象の番号は、馬番又は枠番である。投票対象の番号は、式別に応じて一又は複数登録されている。式別と投票対象の番号との組み合わせは、買い目を示す。
図3(d)は、購入情報DB12dに登録される内容の一例を示す図である。購入情報DB12dには、ユーザによる競馬サイトにおける馬券の購入内容を示す馬券購入情報が、登録される。馬券購入情報は、馬券の購入履歴でもある。具体的に、購入情報DB12dには、ユーザID、購入日時、レースID、買い目情報、購入金額等が対応付けて登録される。ユーザIDは、馬券を購入したユーザを示す。購入日時は、馬券の購入が受け付けられた日時を示す。買い目情報は、ユーザが購入した馬券を示すとともに、投票対象としてユーザが選択した出走馬を示す。枠番を指定する式別の場合、枠番により、1頭又は複数頭の出走馬を指定したことになる。買い目情報と購入金額との組み合わせは、ユーザが一度に購入した馬券の馬券IDごとに登録される。なお、例えば購入金額とともに、又は購入金額に代えて、馬券の購入枚数が購入情報DB12dに登録されてもよい。購入枚数から購入金額を特定可能である。
ユーザが馬券を購入するとき、馬券を購入するレース、買い目及び購入金額を指定する。すると、ユーザ端末2は、購入申込情報を馬券発売代行サーバ1へ送信する。購入申込情報は、例えば、馬券を購入するユーザのユーザID、指定されたレースのレースID、指定された買い目に応じた買い目情報、購入金額を含む。馬券発売代行サーバ1は、例えば受信した購入申込情報に、購入日時として現在日時を追加することにより、馬券購入情報を生成する。そして、馬券発売代行サーバ1は、馬券購入情報を購入情報DB12dに登録する。また、馬券発売代行サーバ1は、馬券購入情報を主催元サーバ2へ送信する。主催元サーバ2は、例えば受信した馬券購入情報を購入情報DB22aに登録する。従って、主催元サーバ2は、購入情報DB12dに登録された馬券情報を少なくとも用いて、基本予想支援情報を生成する。
図3(e)は、オッズ情報DB12eに登録される内容の一例を示す図である。オッズ情報DB12eには、馬券のオッズに関するオッズ情報が、各馬券について所定時間間隔ごとに登録される。具体的に、オッズ情報DB12eには、レースID、馬券ID、更新日時、オッズ、人気順位等が対応付けて登録される。オッズ情報は、主催元サーバ2から馬券発売代行サーバ1へ所定時間間隔(例えば、1分間隔等)で送信される。システム制御部14は、受信したオッズ情報をオッズ情報DB12eに登録する。更新日時は、馬券IDが示す馬券のオッズが主催元サーバ2により更新された日時を示す。
主催元サーバ2は、例えば開催日が本日であり、且つ、発走時刻がまだ経過していないレースのオッズを所定時間ごとに計算する。このとき、主催元サーバ2は、式別ごとにオッズを計算する。例えば、単勝の場合、主催元サーバ2は、購入情報DB22aから、対象のレースのレースIDに対応する馬券購入情報のうち、式別が単勝である馬券購入情報を全て検索する。次いで、主催元サーバ2は、検索された馬券購入情報に含まれる買い目情報の単勝の馬番と、購入金額に基づいて、各馬番のオッズを計算する。例えば、主催元サーバ2は、レースの出走馬の馬番ごとに、投票券の購入金額の合計を計算する。次いで、主催元サーバ2は、全馬番の購入金額を合計して、単勝の投票券の総購入金額を計算する。次いで、主催元サーバ2は、総購入金額に所定係数を掛けることにより、基準金額を計算する。次いで、主催元サーバ2は、基準金額を各馬番の購入金額で割ることにより、各馬番のオッズを計算する。主催元サーバ2は、レースの複数の出走馬の馬番を、オッズが低い順に並べて、各馬番の人気順位を決定する。主催元サーバ2は、計算したオッズ、人気順位、対象のレースのレースID、単勝と馬番の組み合わせに対応する馬券ID、及び更新日時を含むオッズ情報を生成する。更新日時は、オッズ情報が生成された日時である。主催元サーバ2は、単勝と異なる式別のオッズについても同様の方法でオッズ情報を生成する。但し、式別に応じて、オッズの計算方法が異なる場合がある。主催元サーバ2は、生成したオッズ情報をオッズ情報DB22bに登録する。また、主催元サーバ2は、オッズ情報を馬券発売代行サーバ1へ送信する。馬券発売代行サーバ1は、受信したオッズ情報をオッズ情報DB12eに登録する。なお、主催元サーバ2が人気順位を決定する代わりに、馬券発売代行サーバ1が人気順位を決定してもよい。
図3(f)は、予想情報DB12fに登録される内容の一例を示す図である。予想情報DB12fには、ユーザによるレースの予想を示す予想情報が、馬券発売代行サーバ1が予想を受け付けるごとに登録される。具体的に、予想情報DB12fには、ユーザID、投稿日時、レースID、予想馬情報等が対応付けて登録される。ユーザIDは、予想を行ったユーザを示す。投稿日時は、予想が投稿された日時を示す。レースIDは、受け付けられた予想がどのレースに対する予想であるかを示す。予想馬情報は、ユーザが選択した予想馬を示す。具体的に、予想馬情報は、本命馬の馬番、対抗馬の馬番、単穴馬の馬番、連下馬の馬番を含む。
図3(g)は、操作履歴DB12gに登録される内容の一例を示す図である。操作履歴DB12gには、競馬サイトにおけるユーザの操作履歴が登録される。操作履歴は、本発明における履歴の一例である。競馬サイトにおいて、ユーザが何らかの操作をすると、ユーザ端末3は、操作に応じたリクエストを馬券発売代行サーバ1へ送信する。システム制御部14は、リクエストを受信するごとに、操作履歴を登録する。具体的に、操作履歴DB12gには、ユーザID、操作日時、履歴詳細等が登録される。ユーザIDは、操作を行ったユーザを示す。操作日時は、操作が行われた日時を示す。より具体的に、操作日時は、操作履歴DB12gに操作履歴が登録された日時である。履歴詳細は、操作に関する詳細な情報である。履歴詳細は、例えば、ユーザ端末3から送信されたリクエストに含まれるURL(Uniform Resource Locator)であってもよい。
操作履歴のうち、ウェブページの閲覧の履歴を、閲覧履歴という。履歴詳細は、少なくとも操作区分を含む。システム制御部14は、操作区分から、操作履歴が閲覧履歴であるか否かを判定することができる。操作履歴が閲覧履歴である場合、操作日時はアクセス日時を示す。アクセス日時は、ウェブページの表示が開始された日時である。また、閲覧履歴の場合、履歴詳細は、更にレースID及び内容種別等を含む。レースIDは、閲覧されたウェブページがどのレースに関するウェブページかを示す。内容種別は、閲覧されたウェブページに表示される内容の種類を示す。例えば、内容種別は、出馬表ページ、オッズページ、レース分析ページ、予想一覧ページ等、閲覧されたウェブページの種類を示してもよい。
図3(h)は、レース結果DB12hに登録される内容の一例を示す図である。レース結果DB12hには、レースの結果に関するレース結果情報が、レースごとに登録される。具体的に、レース結果DB12hには、レースID、着順情報、的中馬券情報等が対応付けて登録される。着順情報は、レースにおける各競走馬の着順を示す。例えば、着順情報には、着順と馬番とが競走馬ごとに対応付けて設定される。的中馬券情報は、的中した馬券に関する情報である。例えば、的中馬券情報には、的中した馬券の馬券ID及び最終オッズ等が馬券ごとに対応付けて設定される。主催元サーバ2は、レースが終了して、レースの結果が確定すると、対応するレース結果情報を馬券発売代行サーバ1へ送信する。馬券発売代行サーバ1は、受信したレース結果情報をレース結果DB12hに登録する。
次に、記憶部12に記憶されるその他の情報について説明する。記憶部12には、ウェブページを表示するためのHTML文書、XML(Extensible Markup Language)文書、画像データ、テキストデータ、電子文書等の各種データが記憶されている。また、記憶部12には、各種の設定値、閾値、基準値、規定値、定数等が記憶されている。
また、記憶部12には、オペレーティングシステム、WWW(World Wide Web)サーバプログラム、DBMS(Database Management System)、馬券発行代行管理プログラム等の各種プログラムが記憶されている。馬券発行代行管理プログラムは、馬券の購入の受け付け、払い戻し、予想の受け付け、予想支援情報補生成等の処理を実行するためのプログラムである。馬券発行代行管理プログラムは、本発明における情報処理プログラムの一例である。なお、各種プログラムは、例えば、他のサーバ装置等からネットワークNWを介して取得されるようにしてもよいし、DVD(Digital Versatile Disc)等の記録媒体に記録されてドライブ装置を介して読み込まれるようにしてもよい。また、馬券発行代行管理プログラムは、プログラム製品であってもよい。
入出力インターフェース13は、通信部11及び記憶部12とシステム制御部14との間のインターフェース処理を行うようになっている。
システム制御部14は、CPU14a、ROM(Read Only Memory)14b、RAM(Random Access Memory)14c等により構成されている。CPU14は、プロセッサの一例である。なお、本発明は、CPUと異なる様々なプロセッサに対しても適用可能である。記憶部12、ROM14b及びRAM14cは、それぞれメモリの一例である。なお、本発明は、ハードディスク、ROM及びRAMと異なる様々なメモリに対しても適用可能である。
なお、馬券発売代行サーバ1が、複数のサーバ装置で構成されてもよい。例えば、馬券の購入の受け付けや払い戻し等の処理を行うサーバ装置、予想の受け付けや予想の表示の制御等の処理を行うサーバ装置、予想支援情報を生成するサーバ装置、ユーザ端末3からのリクエストに応じてウェブページを送信するサーバ装置、及びデータベースを管理するサーバ装置等が、互いにLAN等で接続されてもよい。
[1−3.システム制御部の機能詳細]
次に、図2(b)、図4及び図5を用いて、システム制御部14の機能について説明する。図2(b)は、本実施形態に係る馬券発売代行サーバ1のシステム制御部14の機能ブロックの一例を示す図である。システム制御部14は、CPU14aが、馬券発行代行管理プログラム等のプログラムを読み出し実行することにより、図2(b)に示すように、予想支援情報要求取得部141、購入情報抽出部142、予想支援情報生成部143、予想視線情報提供部144等として機能する。予想支援情報要求取得部141は、本発明における特定手段の一例である。購入情報抽出部142は、本発明における予想時間取得手段及び人気順特定手段の一例である。購入情報抽出部142と予想支援情報生成部143との組み合わせは、本発明における生成手段の一例である。予想視線情報提供部144は、本発明における提供手段の一例である。
上述したように、主催元サーバ2は、或るレースの或る式別のオッズを計算するとき、そのレースのその式別の全ての馬券購入情報を用いる。オッズページに表示される基本予想支援情報としてのオッズは、このようにして計算されたオッズである。また、オッズページに表示される基本予想支援情報としての人気順位は、このようなオッズに基づく。しかしながら、馬券購入情報の中には、レースの結果を予想するための参考としての基本予想支援情報の有用性を低下させる馬券購入情報が存在する場合もある。そこで、情報処理システムSにおいては、予想支援情報の有用性を低下させる馬券購入情報の条件が予め定められる。この条件を不適合条件という。システム制御部14は、不適合条件に合致しない馬券購入情報に基づいて、予想支援情報を生成する。
予想支援情報要求取得部141は、ユーザから予想支援情報が要求されたレースを特定する。具体的に、ユーザによるオッズページの要求操作に基づいて、ユーザ端末2がオッズページ要求を馬券発売代行サーバ1へ送信する。オッズページ要求は、例えば、オッズページを要求したユーザのユーザID、オッズページが要求されたレースのレースID、オッズページが要求された式別を含む。オッズページを要求したユーザを要求ユーザという。また、オッズページが要求されたレースを要求レースという。予想支援情報要求取得部141は、オッズページ要求から、要求レースのレースIDを取得する。
購入情報抽出部142は、要求レースのレースID及び要求された式別に対応付けて購入情報DB12dに登録されている複数の馬券購入情報のうち、不適合条件に合致しない馬券購入情報を、予想支援情報の生成に用いる馬券購入情報として取得する。不適合条件としては、様々な条件が挙げられる。本実施形態において、購入情報抽出部は、馬券購入情報に含まれる内容に基づいてその馬券購入情報がノイズであると判定可能であることを、不適合条件として用いる。ノイズとなる馬券購入情報は、予想支援情報の信頼性を低下させる。例えば、購入情報抽出部142は、馬券購入情報に含まれる購入金額に基づいて、その馬券購入情報がノイズであるか否かを判定してもよい。具体的に、購入情報抽出部142は、複数の馬券購入情報の中で、購入金額が突出している度合いが、所定の度合い未満である購入情報を、予想支援情報に用いる購入情報として抽出してもよい。購入金額が突出している度合いとは、例えば、他の購入金額とかけ離れて購入金額が大きいことをいう。この場合の不適合条件は、購入金額が突出している度合いが閾値異常であることである。
図4(a)乃至図4(c)を用いて具体例を示す。図4(a)は、単勝の各馬券購入情報の購入金額の例を示すグラフである。図4(a)のグラフは、各馬券購入情報の購入金額を、購入時刻の順に並べて示している。また、グラフを示す各矩形内には、投票された競走馬の馬番が表示されている。或るレースにおいて馬番1〜6の競走馬が出走するとする。図4(a)に示すように、馬番6の馬券の購入金額が、他の馬番の馬券の購入金額と比較して、突出して多い。例えば、馬番1〜5の馬券の購入金額は、100〜1,000円程度であり、馬番6の馬券の購入金額が10万円程度であるとする。その一方で、馬番6の馬券の購入者の人数は1名であり、馬番1〜5のそれぞれの馬券の購入者の人数は複数名である。例えば、馬番4の馬券の購入者の人数は6人である。図4(b)は、基本予想支援情報の人気順位の一例を示す図である。図4(a)に示す状態の馬券購入情報に基づいて基本予想支援情報が生成された場合、例えば図4(b)に示すように、馬番6の競走馬の人気順位が1番になることがある。これは、馬番6の馬券の購入者が少人数であるにも関わらず、その購入者による購入金額が突出して大きいために起こる現象である。すなわち、或る購入者による突出した購入金額により、オッズ及び人気順位が大きく変化する。これは、基本予想支援情報の信頼性を低下させる要因になる。購入情報抽出部142は、例えば、所定の度合いとして、購入金額に対する閾値を決定してもよい。例えば、購入情報抽出部142は、購入金額の平均値、標準偏差等を用いて、閾値を決定することができる。そして、購入情報抽出部142は、購入金額が閾値を超える馬券購入情報を、予想支援情報の生成に用いられる馬券購入情報から除外する。この場合、例えば購入金額と平均値との差等が、購入金額が突出している度合いである。また例えば、購入情報抽出部142は、全ての馬券の総購入金額に対する購入金額の割合が、出走馬の頭数等に応じて定められる閾値を超える馬券購入情報を、予想支援情報の生成に用いられる馬券購入情報から除外してもよい。この場合、例えば購入金額の割合と、出走馬の頭数の逆数との差が、購入金額が突出している度合いである。図4(a)の例では、購入金額が閾値よりも大きい馬番6の馬券の馬券購入情報が除外される。図4(c)は、予想支援情報の人気順位の一例を示す図である。馬番6の馬券の馬券購入情報を除外して予想支援情報が生成された場合、例えば図4(b)に示すように、馬番4の競走馬の人気順位が1番になり、馬番6の競走馬の人気順位が6番になる。これにより、基本予想支援情報と比較して、予想支援情報の信頼性が高くなる。
購入金額に対する閾値を決定するとき、購入情報抽出部142は、例えば要求レースの馬券購入情報の購入金額に基づいて閾値を決定してもよい。また、購入情報抽出部142は、例えば要求レースとは異なる過去のレースの馬券購入情報に基づいて、閾値を決定してもよい。例えば、購入情報抽出部142は、過去の全てのレースの馬券購入情報を用いて閾値を決定してもよいし、過去の所定期間内の全てのレースの馬券購入情報を用いて閾値を決定してもよい。また例えば、購入情報抽出部142は、過去のレースのうち、馬券の購入者の構成が、要求レースにおける馬券の購入者の構成と類似するレースの馬券購入情報を用いて、閾値を決定してもよい。購入情報抽出部142は、購入情報DB12dに登録された馬券購入情報に基づいて、馬券の購入者の構成を特定することができる。例えば、購入情報抽出部142は、過去のレースの中で、馬券を購入したユーザのうち所定割合のユーザが、要求レースの馬券を購入したユーザのうち所定割合のユーザと一致するレースの馬券購入情報を用いてもよい。また例えば、購入情報抽出部142は、過去のレースのうち、全ての馬券購入情報がノイズではないと判定されたレースの馬券購入情報を用いて、閾値を決定してもよい。例えば、購入情報抽出部142は、レースが開始又は終了するごとに、そのレースの馬券購入情報の中にノイズとなる馬券購入情報が1つ以上含まれているか否かを判定し、この判定結果をレースIDと対応付けて記憶部12に記憶させてもよい。そして、購入情報抽出部142は、記憶された判定結果に基づいて、何れのレースの馬券購入情報が用いるかを決定してもよい。
ところで、馬券発売代行サーバ1が管理する競馬サイトでの馬券の購入に関する馬券購入情報は、購入情報DB12d及び購入情報DB22aの両方に登録される。しかしながら、馬券場等での馬券の購入に関する馬券購入情報は、購入情報DB22aには登録される一方で、購入情報DB12dには登録されない。従って、購入情報抽出部142は、購入情報DB22aに登録される馬券購入情報のうちの一部の馬券購入情報を登録している購入情報DB12dから、予想支援情報の生成に用いられる馬券購入情報を抽出することになる。この場合、例えば、購入情報DB22aに登録された馬券購入情報が母集団とされ、購入情報DB12dに登録された馬券購入情報が標本とみなされてもよい。すなわち、購入情報DB22aに登録された全ての馬券購入情報に基づくオッズの計算結果と、購入情報DB12dに登録された全ての馬券購入情報に基づくオッズの計算結果とは、ほぼ一致するものとみなされる。なお、システム制御部14が、例えば購入情報DB12dに登録された馬券購入情報に基づいて、基本予想支援情報を生成してもよい。例えば、システム制御部14は、所定時間間隔で、レースID及び式別の組み合わせごとに、レースID及び式別に対応付けて購入情報DB12dに登録された全ての購入情報に基づいて、基本予想支援情報に含まれるオッズを計算し、人気順位を決定してもよい。そして、システム制御部14は、生成した基本予想支援情報を、レースID、式別、及び更新時刻に対応付けて、所定のデータベースに登録してもよい。
予想支援情報生成部143は、購入情報抽出部142により抽出された馬券購入情報に基づいて、予想支援情報を生成する。例えば、予想支援情報生成部143は、オッズ及び人気順位の両方を含む予想支援情報を生成してもよいし、オッズ及び人気順位の何れか一方のみを含む予想支援情報を生成してもよい。予想支援情報生成部143によるオッズの計算方法及び人気順位の決定方法は、主催元サーバ2によるオッズの計算方法及び人気順位の決定方法と同じであってもよい。
予想支援情報提供部144は、予想支援情報生成部143により生成された予想支援情報をユーザ端末2へ提供する。具体的に、予想支援情報提供部144は、基本予想支援情報及び予想支援情報を含むオッズページを生成してもよい。図5は、単勝のオッズページの表示例を示す図である。図5に示すように、オッズページは、基本予想支援情報表示領域110及び予想支援情報表示領域120を含む。基本予想支援情報表示領域110には、基本予想支援情報が表示される。例えば、基本予想支援情報表示領域110には、出走馬ごとに、枠番、馬番、馬名、基本予想支援情報のオッズ及び人気順位が表示される。予想支援情報表示領域120には、予想支援情報が表示される。例えば、予想支援情報表示領域120には、出走馬ごとに、予想支援情報のオッズ及び人気順位が表示される。単勝と異なる式別のオッズページにおいては、表示される買い目やレイアウトが単勝と異なる場合がある。しかしながら、基本予想支援情報及び予想支援情報が表示される点については、他の式別のオッズページも単勝のオッズページと同様である。本実施形態においては、予想支援情報提供部144は、基本予想支援情報と予想支援情報の両方を提供する。しかしながら、予想支援情報提供部144は、例えば予想支援情報のみを提供してもよい。
予想支援情報提供部144は、予想支援情報に含まれる複数の項目のうち、基本予想支援情報に含まれる項目との差が所定の閾値よりも大きい項目を、他の項目とは異なる表示態様でオッズページに表示させてもよい。この場合、基本予想支援情報は、予想支援情報に対する基準ともいえる。項目は、各出走馬のオッズと、各出走馬の人気順位である。これにより、ユーザは、予想支援情報において、基本予想支援情報と異なる項目を容易に認識することができる。表示態様として、例えば文字の大きさ、太さ、色、フォントスタイル、背景の色、枠の色、太さ等が挙げられる。閾値は、例えば0以上の範囲で設定される。図5が示すオッズページは、背景の色を変える場合の例である。また、図5が示すオッズページは、オッズに対する閾値を10とし、人気順位に対する閾値を0とした場合の例である。また、図5の例のように、予想支援情報提供部144は、基本予想支援情報に含まれる項目との差が大きい項目ほど、表示態様が他の項目の表示態様と異なる度合いを大きくしてもよい。
[1−4.情報処理システムの動作]
次に、情報処理システムSの動作について、図6を用いて説明する。なお、以降においては、便宜上、単勝の予想支援情報を生成する場合について説明する。単勝と異なる式別の場合、オッズの計算方法が単勝と異なることを除き、予想支援情報の生成方法は単勝の場合と基本的に同様である。
図6(a)は、本実施形態に係る馬券発売代行サーバ1のシステム制御部14によるオッズページ提供処理の一例を示すフローチャートである。ユーザがユーザ端末3を操作することにより、オッズページを要求する。すると、ユーザ端末3は、オッズページを馬券発売代行サーバ1へ送信する。システム制御部14は、ユーザ端末3からオッズページ要求を受信したときに、オッズページ提供処理を実行する。
図6(a)に示すように、予想支援情報要求取得部141は、オッズページ要求から、要求ユーザのユーザID及び要求レースのレースIDを取得する。次いで、予想支援情報生成部143は、オッズ情報DB12eから要求レースのレースID及び単勝に対応するオッズ情報のうち、更新日時が最新のオッズ情報を、馬券IDごとに取得する。そして、予想支援情報提供部144は、取得したオッズ情報から、オッズ及び人気順位を基本予想支援情報として抽出する(ステップS11)。次いで、購入情報抽出部142は、購入情報DB12dから、要求レースのレースIDに対応する馬券購入情報のうち、式別が単勝である馬券購入情報を全て検索する(ステップS12)。そして、購入情報抽出部142は、検索された馬券購入情報を含む購入情報リストを生成する。このとき、要求ユーザのユーザIDを含む馬券購入情報がある場合、購入情報抽出部142は、その馬券購入情報を購入情報リストに含めてもよいし、含めなくてもよい。次いで、購入情報抽出部142は、利用馬券購入情報抽出処理を実行する(ステップS13)。利用馬券購入情報抽出処理において、購入情報抽出部142は、予想支援情報の生成に用いる馬券購入情報を抽出する。具体的に、購入情報抽出部142は、購入情報リストから、予想支援情報の生成に用いない馬券購入情報を削除する。利用馬券購入情報抽出処理の詳細は後述する。
次いで、予想支援情報生成部143は、購入情報リストに登録された馬券購入情報に含まれる買い目情報の単勝の馬番と、購入金額に基づいて、各馬番のオッズを計算する(ステップS14)。具体的に、購入情報抽出部142は、レースの出走馬の馬番ごとに、投票券の購入金額の合計を計算する。次いで、購入情報抽出部142は、全馬番の購入金額を合計して、単勝の投票券の総購入金額を計算する。次いで、購入情報抽出部142は、総購入金額に所定係数を掛けることにより、基準金額を計算する。そして、購入情報抽出部142は、基準金額を各馬番の購入金額で割ることにより、各馬番のオッズを計算する。
次いで、予想支援情報生成部143は、レースの出走馬の馬番を、ステップS14で計算したオッズが低い順にソートして、人気順位を決定する(ステップS15)。次いで、予想支援情報生成部143は、馬番、ステップS14で計算したオッズ、ステップS15で決定した人気順位を含む予想支援情報を生成する(ステップS16)。
次いで、予想支援情報提供部144は、ステップS11で抽出した基本予想支援情報と、ステップS16で生成した予想支援情報とを含むオッズページのHTML文書を生成する(ステップS17)。このとき、予想支援情報提供部144は、予想支援情報に含まれる全てのオッズ及び人気順位の表示態様を、基本予想支援情報に含まれるオッズ及び人気順位の表示態様に一致させる。例えば、予想支援情報提供部144は、表示スタイルの定義が基本予想支援情報及び予想支援情報の全てのオッズ及び人気順位が一致するようHTML文書を生成する。
次いで、予想支援情報提供部144は、オッズページの予想支援情報に含まれる項目のうち、基本予想支援情報の対応する項目との値の差が所定値よりも大きい項目の表示態様を変更する(ステップS18)。具体的に、予想支援情報提供部144は、馬番ごとに、予想支援情報に含まれるオッズと基本予想支援情報に含まれるオッズとの差を計算する。次いで、オッズの差が、記憶部12に記憶されたオッズ閾値を超える馬番が存在する場合、その馬番を特定する。予想支援情報提供部144は、予想支援情報において、特定した馬番のオッズの表示に利用するスタイル定義を、別のスタイル定義に変更するよう、HTML文書に変更を施す。また、予想支援情報提供部144は、馬番ごとに、予想支援情報に含まれる人気順位と基本予想支援情報に含まれる人気順位との差を計算する。次いで、予想支援情報提供部144は、人気順位の差が、記憶部12に記憶された順位閾値を超える馬番が存在する場合、その馬番を特定する。予想支援情報提供部144は、予想支援情報において、特定した馬番の人気順位の表示に利用するスタイル定義を、別のスタイル定義に変更するよう、HTML文書に変更を施す。ステップS18を終えると、予想支援情報提供部144は、生成したオッズページのHTML文書をユーザ端末3へ送信して(ステップS19)、オッズページ提供処理を終了させる。
図6(b)は、本実施形態に係る馬券発売代行サーバ1のシステム制御部14による利用馬券購入情報抽出処理の一例を示すフローチャートである。図6(b)に示すように、購入情報抽出部142は、購入情報リストに含まれる全ての馬券購入情報の購入金額の合計を、購入情報リストに含まれる馬券購入情報の数で割ることにより、購入金額の平均値を計算する。また、購入情報抽出部142は、平均値と各馬券購入情報の購入金額との差に基づき、標準偏差を計算する(ステップS21)。次いで、購入情報抽出部142は、購入金額の閾値を計算する(ステップS22)。例えば、購入情報抽出部142は、標準偏差に、記憶部12に記憶された係数を掛けることにより、突出量を計算する。突出量は、本発明における突出度の一例である。購入情報抽出部142は、平均値に突出量を加算することにより、閾値を計算する。次いで、購入情報抽出部142は、購入金額が閾値を超える馬券購入情報を購入情報リストから削除する(ステップS23)。そして、購入情報抽出部142は、利用馬券購入情報抽出処理を終了させる。
以上説明したように、本実施形態によれば、システム制御部14が、複数のレースのうち予想支援情報が要求された要求レースを特定する。また、システム制御部14が、馬券購入情報、ユーザID及びレースIDとを対応付けて記憶する記憶部12に要求レースのレースIDに対応付けて記憶された複数の馬券購入情報のうち、不適合条件に合致しない馬券購入情報に基づいて、予想支援情報を生成して提供する。従って、適切な馬券購入情報に基づいた予想支援情報を提供することができる。
また、システム制御部14が、馬券購入情報に含まれる購入内容に基づきノイズではないと判定される馬券購入情報を予想支援情報の生成に用いてもよい。この場合、予想支援情報の信頼性を高めることができる。
このとき、システム制御部14が、要求レースのレースIDに対応付けて記憶された複数の馬券購入情報における購入金額の突出の度合いが所定度未満である馬券購入情報を予想支援情報の生成に用いてもよい。この場合、突出した購入金額に予想支援情報が影響されることを防止することができる。
また、システム制御部14が、予想支援情報に含まれる複数の項目のうち、要求レースのレースIDに対応付けて記憶部12に記憶された複数の馬券購入情報に基づいて生成された基本予想支援情報に含まれる項目との差が所定値よりも大きい項目を、他の項目とは異なる表示態様で表示させてもよい。この場合、予想支援情報において如何なる項目が基本予想支援情報と異なるかをユーザに容易に認識させることができる。
[2.第2実施形態]
[2−1.馬券発売代行サーバ1の機能概要]
次に、第2実施形態における機能概要について、図7を用いて説明する。本実施形態においても、購入情報抽出部142は、馬券購入情報に含まれる内容に基づいてその馬券購入情報がノイズであると判定可能であることを、不適合条件として用いる。本実施形態の場合、購入情報抽出部142は、馬券購入情報に含まれる買い目情報に基づいて、その馬券購入情報がノイズであるか否かを判定する。具体的に、購入情報抽出部142は、馬券を購入するためのレースの結果の予想に要した予想時間が所定時間未満であり、且つ、馬券の購入時における予想支援情報において、投票された競走馬の人気順位が、投票されなかった競走馬の人気順位よりも上位であるユーザからの馬券購入情報を、ノイズと判定する。すなわち、購入情報抽出部142は、予想時間が所定時間以上であるユーザ、及び、馬券の購入時における予想支援情報において、投票された競走馬の人気順位が、投票されなかった競走馬の人気順位よりも下位であるユーザの少なくとも何れか一方からの馬券購入情報を、予想支援情報の生成に用いる馬券購入情報として抽出する。このとき、購入情報抽出部142は、予想支援情報生成部143が生成する予想支援情報を用いてもよし、基本予想支援情報を用いてもよい。予想支援情報生成部143が生成する予想支援情報を用いる場合、予想支援情報生成部143は、例えば、所定時間間隔で予想支援情報を生成する。そして、予想支援情報生成部143は、例えば生成した予想支援情報を生成日時と対応付けて所定のデータベースに登録する。その他の点において、第2実施形態は第1実施形態と同様である。
予想時間が短く、且つ、予想支援情報において人気順位が上位の競走馬に投票したユーザは、予想支援情報に便乗したユーザである蓋然性がある。すなわち、このようなユーザは、自分ではまともに予想を行わず、予想支援情報の人気順位に依拠して馬券を購入した蓋然性がある。このようなユーザからの馬券購入情報が示す予想は信頼することができない。
図7(a)及び図7(b)を用いて具体例を示す。図7(a)は、或るユーザによる馬券の購入内容の一例を示す。図7(b)は、馬券の購入時の基本予想支援情報の一例を示す。例えば、図7(a)に示すように、予想時間が短かった或るユーザが、単勝の馬券として、馬番3の馬券を購入したとする。図7(b)に示すように、馬券の購入時点における基本予想支援情報では、馬番3の人気順位が1番である。従って、ユーザは、基本予想支援情報に便乗した蓋然性がある。このようなユーザが多数存在すると、基本予想支援情報において元々オッズが低い競走馬のオッズが更に低くなる。購入情報抽出部142は、このようなユーザからの馬券購入情報を除外する。
購入情報抽出部142は、要求レースに関する情報が表示されるウェブページの閲覧履歴に基づいて、馬券を購入したユーザの予想時間を推定してもよい。閲覧履歴を用いる理由は、ユーザは、ウェブページの情報を見ながら、投票する競走馬を検討する蓋然性があるからである。購入情報抽出部142は、閲覧履歴からウェブページの閲覧時間を特定してもよい。閲覧時間は、ユーザがウェブページを閲覧した時間の長さを示す。閲覧時間は、例えば、ウェブページが継続して表示された時間であってもよい。また例えば、閲覧時間は、或るウェブページが表示されてから、次のウェブページが表示されるまでに経過した時間であってもよい。購入情報抽出部142は、閲覧時間の合計を予想時間に決定してもよい。
[2−2.情報処理システムの動作]
次に、情報処理システムSの動作について、図8を用いて説明する。図8は、本実施形態に係る馬券発売代行サーバ1のシステム制御部14による利用馬券購入情報抽出処理の一例を示すフローチャートである。図8は、基本予想支援情報を用いて馬券購入情報がノイズであるか否かを判定する場合の処理例を示す。
図8に示すように、購入情報抽出部142は、番号iを1に設定する(ステップS31)。次いで、購入情報抽出部142は、購入情報リストに登録された馬券購入情報のうち、i番目の馬券購入情報からユーザID及び購入日時を取得する(ステップS32)。次いで、購入情報抽出部142は、操作履歴DB12gから、馬券購入情報から取得したユーザIDに対応する閲覧履歴のうち、アクセス日時が本日の日時である閲覧履歴を検索する(ステップS33)。
次いで、購入情報抽出部142は、検索された操作履歴に基づいて、馬券購入情報から取得したユーザIDが示すユーザによる要求レースの予想時間を推定する(ステップS34)。例えば、購入情報抽出部142は、検索された閲覧履歴の中から、要求レースのレースIDに対応する閲覧履歴を抽出する。このとき、購入情報抽出部142は、購入日時よりもアクセス日時が早い閲覧履歴を抽出する。次いで、購入情報抽出部142は、要求レースの情報の総閲覧時間を計算する。例えば、購入情報抽出部142は、抽出した閲覧履歴から、ウェブページのアクセス日時を取得する。次いで、購入情報抽出部142は、検索された閲覧履歴に含まれるアクセス日時のうち、抽出した閲覧履歴から取得したアクセス日時の次に早いアクセス日時を取得する。次いで、購入情報抽出部142は、取得した2つのアクセス日時の差を、1つのウェブページの閲覧時間として計算する。購入情報抽出部142は、抽出した閲覧履歴ごとに閲覧時間を計算する。次いで、購入情報抽出部142は、閲覧時間の合計値を、総閲覧時間として計算する。購入情報抽出部142は、総閲覧時間を予想時間に決定する。
次いで、購入情報抽出部142は、予想時間が、記憶部12に記憶された閾時間未満であるか否かを判定する(ステップS35)。このとき、購入情報抽出部142は、予想時間が閾時間未満ではないと判定した場合には(ステップS35:NO)、ステップS39に進む。一方、購入情報抽出部142は、予想時間が閾時間未満であると判定した場合には(ステップS35:YES)、ステップS36に進む。
ステップS36において、購入情報抽出部142は、オッズ情報DB12eから、要求レースのレースID及び単勝に対応するオッズ情報の中で、更新日時が購入日時以前であるオッズ情報のうち、購入日時に最も近い更新日時を含むオッズ情報を、馬券IDごとに取得する。次いで、購入情報抽出部142は、i番目の馬券購入情報の買い目情報から、投票された馬番を取得する。ユーザが複数の単勝の投票券を同時に購入した場合、馬券購入情報は、買い目情報と購入金額の組み合わせが複数含まれている。この場合、購入情報抽出部142は、各買い目情報から馬番を取得する。そして、購入情報抽出部142は、取得したオッズ情報に含まれる人気順位に基づいて、馬券の購入時において、投票された馬番の人気順位が、投票されなかった馬番の人気順位よりも上位であるか否かを判定する(ステップS37)。例えば、馬券購入情報に馬番が1つのみ含まれているとき、購入情報抽出部142は、その馬番の人気順位が1位である場合に、投票された馬番の人気順位が投票されなかった馬番の人気順位よりも上位であると判定する。また、馬券購入情報に馬番が複数含まれている場合、購入情報抽出部142は、投票された全ての馬番の人気順位をソートする。そして、購入情報抽出部142は、ソートされた人気順位が1位から、投票された馬番の数分連続している場合、投票された馬番の人気順位が投票されなかった馬番の人気順位よりも上位であると判定する。購入情報抽出部142は、投票された馬番の人気順位が投票されなかった馬番の人気順位よりも上位ではないと判定した場合には(ステップS37:NO)、ステップS39に進む。一方、購入情報抽出部142は、投票された馬番の人気順位が投票されなかった馬番の人気順位よりも上位であると判定した場合には(ステップS37:YES)、ステップS38に進む。ステップS38において、購入情報抽出部142は、i番目の馬券購入情報を購入情報リストから削除して、ステップS39に進む。
ステップS39において、購入情報抽出部142は、番号iが、購入情報リストに登録されている馬券購入情報の数の値未満であるか否かを判定する。このとき、購入情報抽出部142は、番号iが馬券購入情報の数の値未満であると判定した場合には(ステップS39:YES)、ステップS40に進む。ステップS40において、購入情報抽出部142は、番号iに1を加算して、ステップS32に進む。一方、購入情報抽出部142は、番号iが馬券購入情報の数の値未満ではないと判定した場合には(ステップS39:NO)、利用馬券購入情報抽出処理を終了させる。
以上説明したように、本実施形態によれば、システム制御部14が、ユーザIDと対応付けてユーザごとに記憶部12に記憶された操作履歴に基づいて、要求レースのレースIDに対応付けて記憶部12に記憶されたユーザIDが示すユーザによる要求レースの予想時間を取得する。また、システム制御部14が、記憶部12に記憶された馬券購入情報と、記憶部12に対応付けて記憶された過去に生成された予想支援情報及びその予想支援情報の更新時刻とに基づいて、要求レースのレースIDに対応付けて記憶部12に記憶されたユーザIDが示すユーザが要求レースの馬券を購入した時点において、該ユーザが投票した競走馬の人気順を特定する。また、システム制御部14が、予想時間が所定時間以上であるユーザ、及び投票した競走馬の馬券を購入した時点の人気順が、投票されていない競走馬の人気順よりも下位であるユーザの少なくとも何れか一方のユーザIDに対応する馬券購入情報を、予想支援情報の生成に用いる。従って、提供された予想支援情報に便乗して馬券を購入した蓋然性があるユーザが投票した競走馬に予想支援情報が影響されることを防止することができる。
[3.第3実施形態]
[3−1.馬券発売代行サーバ1の機能概要]
次に、第3実施形態における機能概要について図9を用いて説明する。本実施形態において、購入情報抽出部142は、要求レースのレース情報の少なくとも一部が変更されている場合、レース情報の変更日時以後の購入日時を含む馬券購入情報を、予想支援情報の生成に用いる馬券購入情報として抽出する。すなわち、本実施形態の不適合条件は、購入日時がレース情報の変更日時より前であることである。その他の点において、第3実施形態は第1実施形態と同様である。
レース情報は、レースの結果を予想するための基礎となる。すなわち、ユーザは、レース情報に基づいて、購入する馬券及び購入金額を決定する。予想の基礎となるレース情報の少なくとも一部が変更された場合、各ユーザの予想が変化する可能性がある。そのため、古いレース情報に基づく馬券の購入に対応する馬券情報は、予想支援情報の生成に用いるには適切ではない蓋然性がある。例えば、レース情報において或る出走馬にとって有利であった情報に基づいてその出走馬に多くのユーザが投票していたが、その情報がその出走馬にとって不利な情報に変わった場合、多くのユーザはその出走馬に投票しない蓋然性がある。
図9は、基本予想支援情報及び予想支援情報の生成に用いられる馬券購入情報の範囲の一例を、購入日時で示す図である。図9に示すように、要求レースについてのレース情報の少なくとも一部が或る時点で変更されたとする。主催元サーバ2は、レース情報に変更があったとしても、全ての馬券購入情報を用いて基本予想支援情報を生成する。すなわち、主催元サーバ2は、レース情報の変更前の馬券の購入に対応する馬券購入情報及び変更後の馬券の購入に対応する馬券購入情報の両方を用いる。一方、馬券発売代行サーバ1は、レース情報の変更後の馬券の購入に対応する馬券購入情報のみに基づいて、予想支援情報を生成する。
[3−2.情報処理システムの動作]
次に、情報処理システムSの動作について、図10を用いて説明する。図10は、本実施形態に係る馬券発売代行サーバ1のシステム制御部14による利用馬券購入情報抽出処理の一例を示すフローチャートである。
図10に示すように、購入情報抽出部142は、要求レースのレースIDに対応するレース情報を検索する(ステップS41)。次いで、購入情報抽出部142は、レース情報の中で、情報が変更された項目があるか否かを判定する(ステップS42)。具体的に、購入情報抽出部142は、検索された各レース情報をその更新日時でソートする。購入情報抽出部142は、更新日時が隣接する2つのレース情報ごとに、規定の1又は複数の項目の情報をレース情報間で比較する。そして、購入情報抽出部142は、例えば少なくとも1つの項目について情報が異なる場合、情報が変更された項目があると判定してもよい。このとき、購入情報抽出部142は、例えば所定の項目については、情報の差が、予め定められた基準値以上である場合にのみ、その項目の情報が変更されたと判定してもよい。購入情報抽出部142は、情報が変更された項目がないと判定した場合には(ステップS42:NO)、利用馬券購入情報抽出処理を終了させる。一方、購入情報抽出部142は、報が変更された項目があると判定した場合には(ステップS42:YES)、ステップS43に進む。
ステップS43において、購入情報抽出部142は、情報の変更日時として、情報が変更されたレース情報から更新日時を取得する。情報の変更が複数回行われている場合、購入情報抽出部142は、例えば最終の変更日時を取得してもよい。また例えば、購入情報抽出部142は、変更前のレース情報との差が最も大きいレース情報の更新日時を変更日時として取得してもよい。次いで、購入情報抽出部142は、購入情報リストから、購入日時が情報の変更日時よりも前である馬券購入情報を削除して(ステップS44)、利用馬券購入情報抽出処理を終了させる。
以上説明したように、本実施形態によれば、システム制御部14が、レース情報が変更されている場合、記憶部12に要求レースのレースIDに対応付けて記憶された複数の馬券購入情報のうち、レース情報の変更時刻以後の購入時刻を含む馬券購入情報を、予想支援情報の生成に用いる。従って、予想支援情報の信頼性を高めることができる。
[4.第4実施形態]
[4−1.馬券発売代行サーバ1の機能概要]
次に、第4実施形態における機能概要について用いて説明する。本実施形態において、購入情報抽出部142は、第2実施形態の場合と同様に、要求レースのレース情報が変更されている場合、レース情報の変更日時以後の購入日時を含む馬券購入情報を、予想支援情報の生成に用いる馬券購入情報として抽出する。但し、購入情報抽出部142は、レース情報の変更前の購入時刻の馬券購入情報に基づき、レース情報の変更前の予想傾向を特定し、レース情報の変更以後の購入時刻の馬券購入情報に基づき、レース情報の変更後の予想傾向を特定する。そして、予想支援情報提供部144は、レース情報の変更前から変更後の間で、予想傾向に所定の基準以上の変更がある場合のみ、予想支援情報を提供する。予想傾向に変化がない場合、基本予想支援情報と予想支援情報との間には、さほどの差がないと考えられる。従って、予想支援情報提供部144は、基本予想支援情報のみを提供すればよく、予想支援情報を提供する必要がない。その他の点において、第4実施形態は第3実施形態と同様である。
予想傾向を示す情報は、例えば予想支援情報であってもよい。例えば、予想支援情報提供部144は、レース情報の変更前の購入時刻の馬券購入情報に基づき、レース情報の変更前の予想支援情報を生成してもよい。このレース情報は、レース情報の変更の直前に生成された基本予想支援情報であってもよい。また、予想支援情報提供部144は、レース情報の変更以後の購入時刻の馬券購入情報に基づき、レース情報の変更後の予想支援情報を生成する。予想支援情報提供部144は、例えば、レース情報変更前と変更後の予想支援情報の間で、項目ごとに値の差を計算する。そして、予想支援情報提供部144は、計算された差に基づいて、予想傾向が変化したか否かを判定する。
予想傾向は、例えば予想支援情報と異なる情報であってもよい。例えば、予想傾向は、各出走馬(または買い目)に対して投票したユーザの人数の比率であってもよい。
[4−2.情報処理システムの動作]
次に、情報処理システムSの動作について、図11及び図12を用いて説明する。図11は、本実施形態に係る馬券発売代行サーバ1のシステム制御部14によるオッズページ提供処理の一例を示すフローチャートである。図11において、図6(a)と同様の処理については同様の符号が付されている。図11に示すように、ステップS11〜S13が実行される。ステップS13において、購入情報抽出部142は、利用馬券購入情報抽出処理を実行する。
図12は、本実施形態に係る馬券発売代行サーバ1のシステム制御部14による利用馬券購入情報抽出処理の一例を示すフローチャートである。図12において、図10と同様の処理については同様の符号が付されている。図12に示すように、購入情報抽出部142は、ステップS41〜S43を実行する。ステップS42において、購入情報抽出部142は、情報が変更された項目がないと判定した場合には(ステップS42:NO)、ステップS45に進む。ステップS45において、購入情報抽出部142は、提供フラグをFALSEに設定して、利用馬券購入情報抽出処理を終了させる。
ステップS43を終えると、購入情報抽出部142は、オッズ情報DB12eから、更新日時がレース情報の変更日時よりも前である単勝のオッズ情報のうち、更新日時が変更日時に最も近いオッズ情報を、レース情報変更前の予想支援情報として取得する(ステップS46)。
次いで、購入情報抽出部142は、購入情報リストから、更新日時が変更日時以後である馬券購入情報を全て取得する。そして、予想支援情報生成部143は、取得した馬券購入情報を用いて、レース情報変更後の予想支援情報を生成する(ステップS47)。予想支援情報の生成方法は、図6(a)に示す基本予想支援情報生成処理のステップS14〜S16の場合と同様である。
次いで、予想支援情報提供部144は、レース情報変更前の予想支援情報と変更後の予想支援情報との間で、予想傾向が変化しているか否かを判定する(ステップS48)。例えば、予想支援情報提供部144は、馬番ごとに、レース情報変更前と変更後の予想支援情報に含まれるオッズの差を計算する。また、予想支援情報提供部144は、馬番ごとに、レース情報変更前と変更後の予想支援情報に含まれる人気順位の差を計算する。予想支援情報提供部144は、例えば、オッズの差が、記憶部12に記憶された第2オッズ閾値を超える馬番が1以上存在するか、又は人気順位の差が、記憶部12に記憶された第2順位閾値を超える馬番が1以上存在する場合、予想傾向が変化していると判定してもよい。また例えば、予想支援情報提供部144は、オッズの差の合計が第3オッズ閾値を超えるか、又は人気順位の差の合計が第3順位閾値を超える場合、予想傾向が変化していると判定してもよい。このときの第3オッズ閾値、第3順位閾値は、例えば出走馬の頭数が多いほど大きい値であってもよい。また、予想支援情報提供部144は、オッズの差が第2オッズ閾値を超えるか、又は人気順位の差が第2順位閾値を超える馬番の数が頭数閾値を超える場合、予想傾向が変化していると判定してもよい。このときの頭数閾値は、例えば出走馬の頭数が多いほど大きい値であってもよい。予想支援情報提供部144は、予想傾向が変化していないと判定した場合には(ステップS48:NO)、ステップS45に進む。一方、予想支援情報提供部144は、予想傾向が変化していると判定した場合には(ステップS48:YES)、ステップS49に進む。ステップS49において、予想支援情報提供部144は、提供フラグをTRUEに設定して、利用馬券購入情報抽出処理を終了させる。
利用馬券購入情報抽出処理を終えると、図11に示すように、予想支援情報提供部144は、提供フラグがTRUEに設定されているか否かを判定する(ステップS51)。このとき、予想支援情報提供部144は、提供フラグがTRUEに設定されていると判定した場合には(ステップS51:YES)、ステップS52に進む。ステップS52において、予想支援情報提供部144は、基本予想支援情報、及び利用購入情報抽出処理で生成された予想支援情報を含むオッズページのHTML文書を生成する。そして、予想支援情報提供部144は、ステップS18、S19を実行する。一方、予想支援情報提供部144は、提供フラグがTRUEに設定されていないと判定した場合には(ステップS51:NO)、ステップS53に進む。ステップS53において、予想支援情報提供部144は、基本予想支援情報のみを含むオッズページのHTML文書を生成する。そして、予想支援情報提供部144は、生成したHTML文書をユーザ端末3へ送信して(ステップS19)、オッズページ提供処理を終了させる。
以上説明したように、本実施形態によれば、システム制御部14が、要求レースのレースIDに対応付けて記憶部12に記憶された複数の馬券購入情報に基づいて特定される要求レースの結果の予想傾向に、レース情報の変更前後で所定基本以上の変化がある場合、予想支援情報を提供する。従って、予想傾向の変化により予想支援情報の必要性がある場合に予想支援情報を提供することができる。
[5.第5実施形態]
[5−1.馬券発売代行サーバ1の機能概要]
次に、第5実施形態における機能概要について、図13を用いて説明する。本実施形態において、購入情報抽出部142は、馬券購入情報に含まれるユーザIDが示すユーザの属性に基づいて、要求ユーザの属性と類似する属性を有するユーザの馬券購入情報を、予想支援情報の生成に用いる馬券購入情報として抽出する。すなわち、本実施形態の不適合条件は、購入条件に含まれるユーザIDが、要求ユーザの属性と類似しない属性を有するユーザのユーザIDであることである。属性が類似するユーザの間では、レースの結果の予想の傾向が一致又は類似する蓋然性がある。従って、要求ユーザの属性と一致又は類似する属性を有するユーザの馬券購入情報に基づいて生成される予想支援情報が示す予想傾向は、要求ユーザの予想傾向と一致又は類似する蓋然性がある。この場合の予想支援情報は、信頼性とは別に、要求ユーザにとって有用である。その理由は、要求ユーザの予想傾向と一致又は類似する予想傾向に基づく予想支援情報は、要求ユーザにとって利用しやすい、又は要求ユーザにとって受け入れられやすいからである。その他の点において、第5実施形態は第1実施形態と同様である。
図13は、本実施形態に係る馬券発売代行サーバ1のシステム制御部14の機能ブロックの一例を示す図である。図13において、図2(b)と同様の要素については同様の符号が付されている。図13に示すように、システム制御部14は、予想支援情報要求取得部141、購入情報抽出部142、予想支援情報生成部143、予想視線情報提供部144、ユーザ属性特定部145等として機能する。ユーザ属性特定部145は、各ユーザの属性を特定する。
馬券購入情報の抽出に用いられる属性は、例えば、性別、年齢、住所がある都道府県や地域等であってもよい。これらの情報は、会員情報から取得可能である。類似の範囲は、例えば予め定められている。例えば、購入情報抽出部142は、性別が同一である場合にのみ、性別が類似すると判定してもよい。また例えば、購入情報抽出部142は、年齢層が一致する場合に、年齢が類似すると判定してもよい。
馬券購入情報の抽出に用いられる属性は、例えばレースの結果を予想するための観点や予想に用いる情報の傾向であってもよい。この予想傾向は、ユーザが閲覧する情報の傾向であってもよい。例えば、レースに関する情報として、出馬表ページ、オッズページ、レース分析ページ、予想一覧ページ等の様々なウェブページが閲覧可能である。出馬表ページにはレース情報が表示される。レース分析ページには、各出走馬の過去のレースの成績の分析結果が表示される。予想一覧ページには、投稿された予想の一覧が表示される。閲覧する情報の種類が類似するユーザの間では、レースの予想傾向が類似する蓋然性がある。例えば、ユーザ属性特定部145は、各ユーザについて、ウェブページの種類ごとに、ウェブページの閲覧時間を計算してもよい。第2実施形態で説明したように、閲覧時間は、閲覧履歴に基づいて計算可能である。ユーザ属性特定部145は、ユーザが重視すると判定したウェブページの種類を示すウェブページ情報を、例えば会員情報DB12aに登録する。ウェブページ情報は、本発明における属性情報の一例である。購入情報抽出部142は、ウェブページ情報に基づいて、重視するウェブページの種類の類比を判定する。例えば、購入情報抽出部142は、重視するウェブページの種類のうち少なくとも1つが、要求ユーザが重視するウェブページの種類のうち少なくとも1つと一致するユーザのユーザIDを含む馬券購入情報を抽出してもよい。
また、予想傾向は、例えば、レースの情報に含まれる複数の項目のうち、レースの結果を予想するためにユーザが重視する項目であってもよい。この項目を、重視項目という。重視項目の候補は、レースの複数の出走馬の情報であって、その複数の出走馬の優劣を比較可能な項目である。出走馬の優劣を比較可能とは、例えば、出走馬が上位に入賞する蓋然性を比較することが可能であることをいう。そのような項目としては、例えば、単勝オッズ、馬体重、過去のレースのレースタイム、勝利数、勝率等が挙げられる。オッズが低い出走馬ほど優位である。馬体重が軽い出走馬ほど優位である。また、前走からの馬体重の増減が小さい出走馬ほど優位である。レースタイムが短い出走馬ほど優位である。勝利数が多い出走馬ほど優位である。勝率が高い出走馬ほど優位である。ユーザ属性特定部145は、例えば、これら全ての項目の情報を取得してもよいし、予め定められた項目の情報のみを取得してもよい。また、過去のレースの成績について、ユーザ属性特定部145は、重視項目が特定される対象のレースの条件と一致する条件下での成績のみを取得してもよい。例えば、対象のレースの距離が1700メートルである場合、1700メートルでのコースにおける成績を取得してもよい。また、出走馬ごとに、騎乗する騎手が異なる。そこで、例えば、ユーザ属性特定部145は、対象のレースについて、各出走馬の騎手を騎手情報から特定し、出走馬ごとに、特定した騎手が騎乗したレースの過去の成績を取得してもよい。
ユーザ属性特定部145は、馬券購入情報及び予想情報の少なくとも一方を用いて、重視項目を特定することができる。例えば、馬券購入情報は、ユーザが入賞すると予想した出走馬を示す買い目情報を含む。ユーザ属性特定部145は、レースの複数の出走馬のうち、ユーザが投票した出走馬の少なくとも1の出走馬が他の出走馬よりも相対的に優位な項目を、複数の項目うち重視項目として特定する。ユーザが何らかの項目を重視する場合、重視する項目において相対的に優位な出走馬に対してユーザが投票する蓋然性が高い。従って、重視項目を適切に特定することができる。
以下に、具体例を説明する。例えば、或るレースで、ユーザが馬券を購入したとする。なお、このレースには6頭の競走馬が出走する。例えば、ユーザは、馬単で1−2、1−3、2−3の馬券を購入したとする。つまり、ユーザは馬番1〜3の出走馬に投票した。重視項目の候補が、各出走馬のオッズ、レースタイム(1700メートル、軽馬場)、レースタイム(1700メートル、重馬場)、勝利数、馬体重を取得したとする。重視項目特定部143は、項目ごとに、各出走馬の優劣順位を決定する。優劣順位は、優位な順に各出走馬の順位を決定したときの順位である。例えば、オッズでは、馬番1、3、2、5、6、4の順に優劣順位が高い。レースタイム(1700メートル、軽馬場)では、馬番1、2、3、4、5、6の順に優劣順位が高い。レースタイム(1700メートル、重馬場)では、馬番3、1、5、2、6、4の順に優劣順位が高い。勝利数では、馬番2、1、3、5、4、6の順に優劣順位が高い。馬体重では、馬番4、1、2、3、6、5の順に優劣順位が高い。
オッズ、レースタイム(1700メートル、軽馬場)、勝利数において、馬番1〜3の出走馬は、馬番4〜6の出走馬よりも優位である。また、レースタイム(1700メートル、重馬場)において、馬番1及び3の出走馬は、馬番4〜6の出走馬よりも優位である。従って、買い目情報が示す出走馬の少なくとも1の出走馬が他の出走馬よりも相対的に優位な項目は、オッズ、レースタイム(1700メートル、軽馬場)、レースタイム(1700メートル、重馬場)、及び勝利数である。この場合、ユーザ属性特定部145は、この4つの項目を重視項目として特定してもよい。
重視項目が複数あるような場合、ユーザ属性特定部145は、例えば、予め設定された数以下の項目のみを重視項目として特定してもよい。また、ユーザ属性特定部145は、各項目の優先度を決定してもよい。この優先度は、複数の重視項目の中でユーザが或る項目を重視する程度を示す。この優先度は、例えば優先順位であってもよい。この優先順位を項目優先順位という。例えば、ユーザ属性特定部145は、ユーザが投票した出走馬のうち相対的に優位な出走馬の数に基づいて、項目優先順位を決定してもよい。具体的に、ユーザ属性特定部145は、ユーザが投票した出走馬のうち相対的に優位な出走馬の数が多い項目ほど、項目優先順位を高くしてもよい。上述の例の場合、オッズ、レースタイム(1700メートル、軽馬場)、及び勝利数では、馬番1〜3の3頭の出走馬が相対的に優位である。また、レースタイム(1700メートル、重馬場)では、馬番1及び3の2頭の出走馬が相対的に優位である。従って、4つの項目のうち、レースタイム(1700メートル、重馬場)の項目優先順位が最も低くなる。また、ユーザ属性特定部145は、ユーザが選択した出走馬のうち相対的に優位な出走馬の数が所定数以上である項目のみを、重視項目として特定してもよい。
上述の例は、ユーザが購入した馬券が馬単の馬券である。ユーザが馬単と異なる馬券を購入した場合であっても、ユーザ属性特定部145は、同様の方法で重視項目を特定可能である。また、予想情報を用いた場合にも、ユーザ属性特定部145は、馬券購入情報を用いた場合と同様の方法で、同様の方法で重視項目を特定可能である。
ユーザは複数のレースに対して馬券を購入したり、予想を投稿したりすることができる。従って、1人のユーザについて、レースごとに、ユーザが投票した出走馬が相対的に優位な項目が特定される場合がある。この場合、ユーザ属性特定部145は、例えば、項目ごとに、優位な項目として特定された回数を計算してもよい。そして、ユーザ属性特定部145は、例えば、優位な項目として特定された回数が最も多い項目を、最終的な重視項目に決定してもよい。また例えば、ユーザ属性特定部145は、優位な項目として特定された回数の比率が、所定の閾値を超える1又は複数の項目を、最終的な重視項目に決定してもよい。
[5−2.情報処理システムの動作]
次に、情報処理システムSの動作について、図14及び図15を用いて説明する。以下に説明する動作は、ユーザの予想傾向を特定するための属性を重視項目に適用した場合の動作である。図14は、本実施形態に係る馬券発売代行サーバ1のシステム制御部14による重視項目特定処理の一例を示すフローチャートである。システム制御部14は、例えばユーザごとに重視項目特定処理を実行する。例えば、システム制御部14は、定期的に重視項目特定処理を実行してもよい。例えば、システム制御部14は、1日に所定回数、重視項目特定処理を実行してもよい。また例えば、システム制御部14は、1つのレースが開始又は終了するごとに、そのレースの投票券を購入したユーザを対象として重視項目特定処理を実行してもよい。
図14に示すように、ユーザ属性特定部145は、重視項目が特定される対象ユーザのユーザIDを取得する(ステップS61)。次いで、ユーザ属性特定部145は、取得したユーザIDに対応する馬券購入情報を購入情報DB12dから検索する(ステップS62)。
次いで、ユーザ属性特定部145は、検索された馬券購入情報ごとに、対象ユーザにより投票された出走馬の少なくとも1つが、投票されなかった出走馬と比較して優位な項目を特定する(ステップS63)。具体的に、ユーザ属性特定部145は、馬券購入情報に含まれる買い目情報に基づいて、ユーザが投票した1又は複数の出走馬の馬番を特定する。また、ユーザ属性特定部145は、馬券購入情報からレースIDを取得する。次いで、ユーザ属性特定部145は、取得したレースIDに対応するレース情報をレース情報DB12bから取得する。レースIDに対応するレース情報が複数存在する場合、ユーザ属性特定部145は、馬券の購入日時よりも前の更新日時を含むレース情報のうち、購入日時に最も近い更新日時を含むレース情報を取得する。また、ユーザ属性特定部145は、取得したレースIDに対応する単勝のオッズ情報を、オッズ情報DB12eから取得する。このとき、ユーザ属性特定部145は、馬券の購入日時よりも前の更新日時を含むオッズ情報のうち、購入日時に最も近い更新日時を含むオッズ情報を取得する。ユーザ属性特定部145は、レース情報及びオッズ情報に基づいて、項目ごとに、各出走馬の優劣順位を決定する。次いで、ユーザ属性特定部145は、投票された出走馬のうち少なくとも1の出走馬が相対的に優位な項目を特定する。例えば、ユーザ属性特定部145は、優劣順位が1位の出走馬が、投票された出走馬の何れかである項目を特定してもよい。このとき、ユーザ属性特定部145は、例えば投票された出走馬が相対的に優位な項目を複数特定してもよい。
ステップS63を終えると、ユーザ属性特定部145は、各項目について、対象ユーザに投票された出走馬が優位であると特定された回数を計算する。そして、ユーザ属性特定部145は、優位な項目として特定された回数に基づいて、対象ユーザの重視項目を特定する(ステップS64)。例えば、ユーザ属性特定部145は、全ての項目について、投票した出走馬が優位であると特定された回数の合計を計算する。次いで、ユーザ属性特定部145は、項目ごとに、出走馬が優位であると特定された回数の、合計に対する比率を計算する。そして、ユーザ属性特定部145は、比率が、記憶部12に記憶された比率閾値を超える1又は複数の項目を、重視項目に特定する。
ステップS64を終えると、ユーザ属性特定部145は、特定した重視項目の項目IDを取得する。項目IDは、項目の識別情報である。ユーザ属性特定部145は、対象ユーザのユーザIDに対応付けて、重視項目の項目IDを含む重視項目情報を会員情報DB12aに登録する(ステップS65)。重視項目情報は、本発明における属性情報の一例である。ユーザ属性特定部145は、ステップS65を終えると、重視項目特定処理を終了させる。
図15は、本実施形態に係る馬券発売代行サーバ1のシステム制御部14による利用馬券購入情報抽出処理の一例を示すフローチャートである。図15に示すように、購入情報抽出部142は、要求ユーザのユーザIDに対応する重視項目情報を会員情報DB12aから取得する(ステップS71)。次いで、購入情報抽出部142は、番号iを1に設定する(ステップS72)。次いで、購入情報抽出部142は、購入情報リストに登録されている馬券購入情報のうちi番目の馬券購入情報からユーザIDを取得する(ステップS73)。次いで、購入情報抽出部142は、取得したユーザIDに対応する重視項目情報を会員情報DB12aから取得する(ステップS74)。
次いで、購入情報抽出部142は、ステップS74で取得された重視項目情報に含まれる項目IDの中に、ステップS71で取得した重視項目情報に含まれる何れかの項目IDと一致する項目IDがあるか否かを判定する(ステップS75)。このとき、購入情報抽出部142は、一致する項目IDがあると判定した場合には(ステップS75:YES)、ステップS77に進む。一方、購入情報抽出部142は、一致する項目IDがないと判定した場合には(ステップS75:NO)、ステップS76に進む。ステップS76において、購入情報抽出部142は、i番目の馬券購入情報を購入情報リストから削除して、ステップS77に進む。
ステップS77において、購入情報抽出部142は、番号iが、購入情報リストに登録されている馬券購入情報の数の値未満であるか否かを判定する。このとき、購入情報抽出部142は、番号iが馬券購入情報の数の値未満であると判定した場合には(ステップS77:YES)、ステップS78に進む。ステップS78において、購入情報抽出部142は、番号iに1を加算して、ステップS73に進む。一方、購入情報抽出部142は、番号iが馬券購入情報の数の値未満ではないと判定した場合には(ステップS77:NO)、利用馬券購入情報抽出処理を終了させる。
以上説明したように、本実施形態によれば、システム制御部14が、要求レースのレースIDに対応付けて記憶部12に記憶された馬券購入情報のうち、要求ユーザの属性と類似する属性を有するユーザを示すユーザIDに対応する馬券購入情報を、予想支援情報の生成に用いる。従って、要求ユーザの属性に適した予想支援情報を提供することができる。
このとき、システム制御部14が、重視項目情報等に基づいて、要求ユーザによる予想傾向と類似する予想傾向を有するユーザを示すユーザIDに対応する馬券購入情報を、予想支援情報の生成に用いてもよい。この場合、要求ユーザの予想傾向に適した予想支援情報を提供することができる。
[6.第6実施形態]
[6−1.馬券発売代行サーバ1の機能概要]
次に、第6実施形態における機能概要について説明する。本実施形態において、予想支援情報生成部143は、要求ユーザが馬券を購入したことがある過去のレースにおいて、要求ユーザが払戻金を獲得した程度を特定する。払戻金を獲得した程度を、投票成績ともいう。払戻金を獲得した程度は、例えば、的中数、的中率、総払戻金額、回収率等であってもよい。予想支援情報生成部143は、払戻金を獲得した程度が初程度未満である場合にのみ、予想支援情報を生成する。予想支援情報は、レースの結果を予想するための参考にされる。しかしながら、投票成績がよいユーザは、基本予想支援情報を見ればよく、予想支援情報に依拠して、購入する馬券を決定する必要はない。本実施形態によれば、予想支援情報を必要とする蓋然性があるユーザにのみ、予想支援情報を提供することができる。その他の点において、第6実施形態は第1実施形態〜第5実施形態と同様である。
[6−2.情報処理システムの動作]
次に、情報処理システムSの動作について、図16を用いて説明する。図16は、本実施形態に係る馬券発売代行サーバ1のシステム制御部14によるオッズページ提供処理の一例を示すフローチャートである。図16において、図6(a)と同様の処理については同様の符号が付されている。
図16に示すように、予想支援情報生成部143は、ステップS11を実行する。次いで、予想支援情報生成部143は、要求ユーザのユーザIDに対応する馬券購入情報を購入情報DB12dから検索する(ステップS81)。次いで、予想支援情報生成部143は、検索された各馬券購入情報からレースIDを取得する。そして、予想支援情報生成部143は、各馬券購入情報のレースIDに対応するレース結果情報をレース結果DB12hから取得する(ステップS82)。次いで、予想支援情報生成部143は、馬券購入情報及びレース結果情報に基づいて、要求ユーザの回収率を計算する(ステップS83)。具体的に、予想支援情報生成部143は、馬券購入情報に含まれる購入金額に基づいて、馬券の総購入金額を計算する。また、予想支援情報生成部143は、馬券購入情報に含まれる購入金額及び買い目情報の馬券IDと、レース結果情報に含まれる的中馬券の馬券ID及び最終オッズに基づいて、総払戻金額を計算する。そして、予想支援情報生成部143は、総払戻金額を総購入金額で割ることにより、回収率を計算する。次いで、予想支援情報生成部143は、回収率が、記憶部12に記憶されている回収率閾値未満であるか否かを判定する(ステップS84)。このとき、予想支援情報生成部143は、回収率が回収率閾値未満であると判定した場合には(ステップS84:YES)、ステップS12に進む。そして、ステップS12〜S19が実行される。一方、予想支援情報生成部143は、回収率が回収率閾値未満ではないと判定した場合には(ステップS84:NO)、ステップS85に進む。ステップS85において、予想支援情報提供部144は、基本予想支援情報のみを含むオッズページのHTML文書を生成する。そして、予想支援情報提供部144は、生成したHTML文書をユーザ端末3へ送信して(ステップS19)、オッズページ提供処理を終了させる。
以上説明したように、本実施形態によれば、システム制御部14が、要求ユーザが馬券を購入した過去のレースにおいて要求ユーザが配当金を獲得した程度が所定度未満である場合、予想支援情報を生成する。従って、これまでの投票成績が低いユーザに対して予想支援情報を提供することができる。
[7.第7実施形態]
[7−1.馬券発売代行サーバ1の機能概要]
次に、第7実施形態における機能概要について説明する。本実施形態において、予想支援情報提供部144は、基本予想支援情報と、生成された予想支援情報とを比較する。そして、予想支援情報提供部144は、基本予想支援情報と予想支援情報との差が所定値よりも大きい場合にのみ、予想支援情報を提供する。基本予想支援情報と予想支援情報との差が小さければ、基本予想支援情報のみ提供されればよい。本実施形態によれば、基本予想支援情報との差が大きいことにより、提供する必要がある場合にのみ予想支援情報を提供することができる。その他の点において、第7実施形態は第1実施形態〜第6実施形態と同様である。
[7−2.情報処理システムの動作]
次に、情報処理システムSの動作について、図17を用いて説明する。図17は、本実施形態に係る馬券発売代行サーバ1のシステム制御部14によるオッズページ提供処理の一例を示すフローチャートである。図17において、図6(a)と同様の処理については同様の符号が付されている。
図17に示すように、ステップS11〜S16が実行される。次いで、予想支援情報提供部144は、予想支援情報に含まれる項目の中に、基本予想支援情報の対応する項目との値の差が所定値よりも大きい項目があるか否かを判定する(ステップS91)。このときの判定方法は、ステップS18において、値の差が所定値よりも大きい項目を特定する方法と同様であってもよい。このとき、予想支援情報生成部143は、値の差が所定値よりも大きい項目があると判定した場合には(ステップS91:YES)、ステップS17に進む。そして、ステップS17〜S19が実行される。一方、予想支援情報生成部143は、予想支援情報提供部144は、値の差が所定値よりも大きい項目がないと判定した場合には(ステップS91:NO)、ステップS92に進む。ステップS92において、予想支援情報提供部144は、基本予想支援情報のみを含むオッズページのHTML文書を生成する。そして、予想支援情報提供部144は、生成したHTML文書をユーザ端末3へ送信して(ステップS19)、オッズページ提供処理を終了させる。
以上説明したように、本実施形態によれば、システム制御部14が、基本予想支援情報と予想支援情報との差が所定値よりも大きい場合、予想支援情報を提供する。従って、予想支援情報の必要性があるときに予想支援情報を提供することができる。
なお、購入情報抽出部142は、第1実施形態、第2実施形態、第3実施形態及び第5実施形態で説明された不適合条件のうち少なくとも2つの不適合条件を組み合わせて、予想支援情報の生成に用いられる購入情報を抽出してもよい。
また、上記実施形態においては、本発明の情報処理装置が、クライアントサーバシステムにおけるサーバ装置に適用されていた。しかしながら、本発明の情報処理装置が、サーバ装置以外の情報処理装置に適用されてもよい。例えば、本発明の情報処理装置がユーザ端末3等に適用されてもよい。そして、ユーザ端末3が備えるCPU等の制御部が本発明における手段として機能してもよい。この場合、ユーザ端末3は、例えば馬券発売代行サーバ1から要求レースの馬券購入情報を取得してもよい。ユーザ端末3は、取得した購入情報の中から、不適合条件に合致しない購入情報を抽出し、抽出した購入情報に基づいて予想支援情報を生成してもよい。そして、ユーザ端末3は、ディスプレイ等の表示手段に予想支援情報を表示することにより、予想支援情報をユーザに提供してもよい。この場合、表示手段は、ユーザ端末3に備えられていてもよい。または、表示手段は、ユーザ端末3とは別個の装置であってもよい。