図面 (/)

技術 情報処理装置、情報処理方法、プログラム、情報処理システム

出願人 株式会社コナミデジタルエンタテインメント
発明者 五島章千手昭彦松村謙
出願日 2012年10月26日 (8年0ヶ月経過) 出願番号 2012-236205
公開日 2014年5月12日 (6年6ヶ月経過) 公開番号 2014-083340
状態 特許登録済
技術分野 電子ゲーム機
主要キーワード 一致頻度 予想内容 ボウリング 受付終了時刻 スコアブック タッチパネル入力方式 ホームチーム 予想データ
関連する未来課題
重要な関連分野

この項目の情報は公開日時点(2014年5月12日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (20)

課題

実時間のイベントに自らが参加しているかのような感覚をユーザが感じることができるようにした情報処理装置情報処理方法プログラム情報処理システムを提供する。

解決手段

情報処理装置は、イベントが実時間で行われる場合に、実時間のイベント内で特定の状況が発生したタイミングにおいて、記憶装置を参照して、特定の状況に関する問題と、問題に対応付けられている複数の選択肢とをユーザに提示する提示手段52と、提示された複数の選択肢のうちいずれかに対するユーザの選択結果を受け付ける受付手段53と、受け付けた選択結果に基づいてユーザのタイプを決定する決定手段54と、決定したタイプに関する情報をユーザに通知する通知手段55と、を備える。

概要

背景

従来、例えば野球試合勝敗などの結果を事前にユーザに予想させておき、試合終了後に予想が当たったユーザにポイントを付与するシステムが知られている。例えば、特許文献1には、プロ野球試合結果の勝敗等の事象に対してユーザの予想内容に対応する予想データをユーザの端末装置から受け付け、受け付けた予想データを当該ユーザに関連付けて登録しておき、予想データと、現実に発生した事象である結果データとが予め定めた条件を満たすときに、そのユーザに所定のポイントを付与するようにしたネットワークゲーム情報処理装置が開示されている。

概要

実時間のイベントに自らが参加しているかのような感覚をユーザが感じることができるようにした情報処理装置、情報処理方法プログラム情報処理システムを提供する。情報処理装置は、イベントが実時間で行われる場合に、実時間のイベント内で特定の状況が発生したタイミングにおいて、記憶装置を参照して、特定の状況に関する問題と、問題に対応付けられている複数の選択肢とをユーザに提示する提示手段52と、提示された複数の選択肢のうちいずれかに対するユーザの選択結果を受け付ける受付手段53と、受け付けた選択結果に基づいてユーザのタイプを決定する決定手段54と、決定したタイプに関する情報をユーザに通知する通知手段55と、を備える。

目的

本発明は上述した観点に鑑みてなされたもので、実時間のイベントに自らが参加しているかのような感覚をユーザが感じることができるようにした情報処理装置、情報処理方法、プログラム、情報処理システムを提供する

効果

実績

技術文献被引用数
0件
牽制数
1件

この技術が所属する分野

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

現実世界イベント内で発生しうる状況に関する問題の情報と、当該状況の後に前記イベント内で発生しうる状況についての複数の選択肢の情報と、を対応付け記憶装置に記憶させる記憶手段と、前記イベントと同種のイベントが実時間で行われる場合に、実時間のイベント内で特定の状況が発生したタイミングにおいて、前記記憶装置を参照して、前記特定の状況に関する問題と、当該問題に対応付けられている複数の選択肢とをユーザに提示する提示手段と、前記提示手段によって提示された複数の選択肢のうちいずれかに対する前記ユーザの選択結果を受け付ける受付手段と、前記受付手段によって受け付けた選択結果に基づいて前記ユーザのタイプを決定する決定手段と、前記決定手段によって決定したタイプに関する情報を前記ユーザに通知する通知手段と、を備えた、情報処理装置

請求項2

前記提示手段は、前記実時間のイベント内でいずれかの特定の状況が発生するごとに、前記いずれかの特定の状況に関する問題と、当該問題に対応付けられている複数の選択肢とを前記ユーザに提示し、前記決定手段は、前記受付手段によって受け付けた複数の選択結果に基づいて前記ユーザのタイプを決定することを特徴とする、請求項1に記載された情報処理装置。

請求項3

前記記憶手段は、過去の現実世界のイベントの結果に基づいて、前記タイプを前記複数の選択肢の各々に対応付けて、前記記憶装置に記憶させ、前記決定手段は、前記受付手段によって前記選択結果を受け付けると、前記記憶装置を参照して、前記選択結果となる選択肢に対応するタイプを前記ユーザのタイプとして決定することを特徴とする、請求項1または2に記載された情報処理装置。

請求項4

ユーザ同士関係付ける関係付け手段と、同じタイプに決定されたユーザ同士が関係付けられた場合、あるいは互いに関係付けられたユーザの各々が同じタイプに決定された場合に、各ユーザの少なくともいずれかに対して特典を付与する付与手段と、を備えたことを特徴とする、請求項1〜3のいずれかに記載された情報処理装置。

請求項5

ユーザ同士を関係付ける関係付け手段と、同じタイプに決定されたユーザ同士が関係付けられた場合、あるいは互いに関係付けられたユーザの各々が同じタイプに決定された場合に、各ユーザ間の関係の程度を示す親密度を高めるように調整する調整手段と、を備えたことを特徴とする、請求項1〜4のいずれかに記載された情報処理装置。

請求項6

前記決定手段は、前記選択結果に対応する状況と、過去の現実世界のイベント内で前記問題に対応する状況の後に発生した状況とが一致した数あるいは頻度が所定の閾値以上であるか否かに基づいて、前記ユーザのタイプを決定することを特徴とする、請求項1〜5のいずれかに記載された情報処理装置。

請求項7

現実世界のイベント内で発生しうる状況に関する問題の情報と、当該状況の後に前記イベント内で発生しうる状況についての複数の選択肢の情報と、を対応付けて記憶装置に記憶させるステップと、前記イベントと同種のイベントが実時間で行われる場合に、実時間のイベント内で特定の状況が発生したタイミングにおいて、前記記憶装置を参照して、前記特定の状況に関する問題と、当該問題に対応付けられている複数の選択肢とをユーザに提示するステップと、提示された複数の選択肢のうちいずれかに対する前記ユーザの選択結果を受け付けるステップと、受け付けた選択結果に基づいて前記ユーザのタイプを決定するステップと、決定したタイプに関する情報を前記ユーザに通知するステップと、を備えた、情報処理方法

請求項8

コンピュータに、現実世界のイベント内で発生しうる状況に関する問題の情報と、当該状況の後に前記イベント内で発生しうる状況についての複数の選択肢の情報と、を対応付けて記憶装置に記憶させる機能、前記イベントと同種のイベントが実時間で行われる場合に、実時間のイベント内で特定の状況が発生したタイミングにおいて、前記記憶装置を参照して、前記特定の状況に関する問題と、当該問題に対応付けられている複数の選択肢とをユーザに提示する機能、提示された複数の選択肢のうちいずれかに対する前記ユーザの選択結果を受け付ける機能、受け付けた選択結果に基づいて前記ユーザのタイプを決定する機能、及び決定したタイプに関する情報を前記ユーザに通知する機能、を実現させるためのプログラム

請求項9

通信端末と、当該通信端末からアクセスされるサーバとを含む情報処理システムであって、現実世界のイベント内で発生しうる状況に関する問題の情報と、当該状況の後に前記イベント内で発生しうる状況についての複数の選択肢の情報と、を対応付けて記憶装置に記憶させる記憶手段、前記イベントと同種のイベントが実時間で行われる場合に、実時間のイベント内で特定の状況が発生したタイミングにおいて、前記記憶装置を参照して、前記特定の状況に関する問題と、当該問題に対応付けられている複数の選択肢とをユーザに提示する提示手段、前記提示手段によって提示された複数の選択肢のうちいずれかに対する前記ユーザの選択結果を受け付ける受付手段、前記受付手段によって受け付けた選択結果に基づいて前記ユーザのタイプを決定する決定手段、前記決定手段によって決定したタイプに関する情報を前記ユーザに通知する通知手段、の各手段を、前記通信端末又は前記サーバのいずれか一方が備えた、情報処理システム。

技術分野

0001

本発明は、実時間のイベント連動して、ネットワーク接続可能な通信端末との間で情報処理を行うための技術に関する。

背景技術

0002

従来、例えば野球試合勝敗などの結果を事前にユーザに予想させておき、試合終了後に予想が当たったユーザにポイントを付与するシステムが知られている。例えば、特許文献1には、プロ野球試合結果の勝敗等の事象に対してユーザの予想内容に対応する予想データをユーザの端末装置から受け付け、受け付けた予想データを当該ユーザに関連付けて登録しておき、予想データと、現実に発生した事象である結果データとが予め定めた条件を満たすときに、そのユーザに所定のポイントを付与するようにしたネットワークゲーム情報処理装置が開示されている。

先行技術

0003

特開2003−000954号公報

発明が解決しようとする課題

0004

ところで一般に、例えばプロ野球あるいはその放送番組等のイベントに対して、視聴者の注目を引きつけるための様々な試みがなされている。特にテレビジョン放送ラジオ放送あるいはインターネット放送によって実時間で提供されるスポーツ番組等、比較的長時間に亘って提供されるイベントに対して、継続的に視聴者の注目を引くようにし、視聴率を上げるための新たな仕組みが要請されている。上述した公知のシステムも、イベントに対して視聴者の注目を引きつけるための試みの1つと考えることができるが、このシステムでは、実時間のイベントにユーザが参加しているかのような魅力的な仕組みとなっていない。上述した公知のシステムでは、例えば野球の試合の勝敗などの結果のみが分かればユーザはポイントが付与されるか否かが分かるので、野球の試合自体に参加しているかのような感覚を味わえないためである。

0005

本発明は上述した観点に鑑みてなされたもので、実時間のイベントに自らが参加しているかのような感覚をユーザが感じることができるようにした情報処理装置、情報処理方法プログラム情報処理システムを提供することを目的とする。

課題を解決するための手段

0006

以下で開示される情報処理装置は、特定多数あるいは不特定多数のユーザの通信端末の各々と、通信を介してコネクション確立できる情報処理装置であれば何でもよい。そのような情報処理装置は、例えばネットワーク上に配置された1または複数のサーバ、あるいは大型コンピュータ装置であってよい。また、ユーザと通信端末は必ずしも1対1で対応する固定的な関係である必要はなく、複数のユーザが単一の通信端末を共用する通信端末の使用形態も想定される。したがって、この情報処理装置は、ユーザを一意に特定可能な情報として、ユーザID等のユーザ識別情報ごとにユーザを管理してもよい。

0007

本発明の第1の観点は、情報処理装置である。
この情報処理装置は、
現実世界のイベント内で発生しうる状況に関する問題の情報と、当該状況の後に前記イベント内で発生しうる状況についての複数の選択肢の情報と、を対応付け記憶装置に記憶させる記憶手段(51)と、
前記イベントと同種のイベントが実時間で行われる場合に、実時間のイベント内で特定の状況が発生したタイミングにおいて、前記記憶装置を参照して、前記特定の状況に関する問題と、当該問題に対応付けられている複数の選択肢とをユーザに提示する提示手段(52)と、
前記提示手段(52)によって提示された複数の選択肢のうちいずれかに対する前記ユーザの選択結果を受け付ける受付手段(53)と、
前記受付手段(53)によって受け付けた選択結果に基づいて前記ユーザのタイプを決定する決定手段(54)と、
前記決定手段(54)によって決定したタイプに関する情報を前記ユーザに通知する通知手段(55)と、
を備える。

0008

この情報処理装置において、「イベント」とは、例えば、野球等のスポーツの試合や、将棋チェス等の対局であってよく、そのジャンルは問わない。イベント内の「状況」は、イベントの内容にもよるが、イベント内で特定の場面(例えば野球の試合の場合、3回表で1死満塁など)に限られず、イベント内の区切り(例えば野球の試合の場合、特定の回のイニング間や、試合開始前、試合開始後等)等の時期的な状況も含む。

0009

この情報処理装置によって、実時間のイベント内で特定の状況が発生したタイミングにおいて、その特定の状況に関する問題と、その特定の状況の後に発生する状況についての複数の選択肢とがユーザに提示され、ユーザは、いずれかの選択肢を選択するように構成される。例えば、ユーザは、実時間のイベントを視聴しながら、そのイベント内で特定の状況が生じたときに、その次に発生する状況を予想することになる。このとき、ユーザは、実時間のイベントを視聴しながら、例えばイベントにおける様々な状況(例えば野球の試合の場合、1死3塁等の場面、監督配、打者投手の特性等)を考慮して選択肢を検討するようになるため、その後に生ずるイベント内の状況に対してより注目するようになり、実時間のイベントに自らが参加しているかのような感覚をユーザが感じることができるようになる。
また、この情報処理装置では、ユーザがいずれかの選択肢を選択すると、その選択結果に基づいて当該ユーザのタイプを決定して、決定したタイプに関する情報を当該ユーザに通知するように構成されている。この場合、ユーザは、例えば実時間のイベント内で特定の状況が生じたときに、その次に発生する状況を予想して選択肢を選択することによって、自身のタイプを知ることができる。ここで、ユーザのタイプは、例えば実時間のイベントが野球の試合の場合、現役あるいは過去の監督別に分類されてもよい。この場合、ユーザは、自身のタイプに関する情報が通知されることにより、野球の試合(イベント)の特定の状況における自身の予想(すなわち、特定の状況に対する判断や采配など)が、現役あるいは過去の監督のうちどの監督に類似しているのかを知ることができる。このため、ユーザが、例えば実時間のイベントにおける様々な状況において自身の特徴や傾向などを認識することができるという興趣性のある仕組みとすることができる。

0010

上記情報処理装置において、前記提示手段(52)は、前記実時間のイベント内でいずれかの特定の状況が発生するごとに、前記いずれかの特定の状況に関する問題と、当該問題に対応付けられている複数の選択肢とを前記ユーザに提示し、前記決定手段(54)は、前記受付手段(53)によって受け付けた複数の選択結果に基づいて前記ユーザのタイプを決定してもよい。
この構成では、実時間のイベント内でいずれかの特定の状況が発生するごとに、ユーザがいずれかの選択肢を選択することによって複数の選択結果が受け付けられるまで、ユーザは自身のタイプを知ることができない。このため、自身のタイプの内容に対するユーザの期待感を高める仕組みとすることができる。

0011

上記情報処理装置において、前記記憶手段(51)は、過去の現実世界のイベントの結果に基づいて、前記タイプを前記複数の選択肢の各々に対応付けて、前記記憶装置に記憶させ、前記決定手段(54)は、前記受付手段(53)によって前記選択結果を受け付けると、前記記憶装置を参照して、前記選択結果となる選択肢に対応するタイプを前記ユーザのタイプとして決定してもよい。
この場合、過去の現実世界のイベントの結果に適合したタイプを決定することができ、信頼性の高いタイプ決定を行うことが可能となる。

0012

上記情報処理装置において、ユーザ同士関係付ける関係付け手段(56)と、同じタイプに決定されたユーザ同士が関係付けられた場合、あるいは互いに関係付けられたユーザの各々が同じタイプに決定された場合に、各ユーザの少なくともいずれかに対して特典を付与する付与手段(57)と、を備えてもよい。
例えば、同じタイプに決定されたユーザ同士が関係付けられた(仲間になった)ときに各ユーザの少なくともいずれかに対して特典が付与される場合には、ユーザは、特典を得るために、自身と同じタイプの他のユーザと仲間になることが動機付けられる。また、例えば、互いに関係付けられたユーザの各々が同じタイプに決定されたときに各ユーザの少なくともいずれかに対して特典が付与される場合には、ユーザが特典を得ることによって、同じタイプの他のユーザ(仲間)に対する当該ユーザの親近感を増す仕組みとすることができる。これにより、本構成によれば、ユーザ同士の交流を促進させることができるので、ソーシャル性を向上させることができる。

0013

上記情報処理装置において、ユーザ同士を関係付ける関係付け手段(56)と、同じタイプに決定されたユーザ同士が関係付けられた場合、あるいは互いに関係付けられたユーザの各々が同じタイプに決定された場合に、各ユーザ間の関係の程度を示す親密度を高めるように調整する調整手段(58)と、を備えてもよい。
例えば、同じタイプに決定されたユーザ同士が関係付けられた(仲間になった)ときに各ユーザ間の親密度が高くなる場合には、ユーザは、自身と同じタイプであることを契機として、当該タイプの他のユーザと仲間になることが動機付けられる。また、例えば、互いに関係付けられたユーザの各々が同じタイプに決定されたときに各ユーザ間の親密度が高くなる場合には、親密度が高くなったことを契機として、各ユーザ間の交流を促進させる仕組みとすることができる。これにより、ソーシャル性を向上させることができる。

0014

上記情報処理装置において、前記決定手段(54)は、前記選択結果に対応する状況と、過去の現実世界のイベント内で前記問題に対応する状況の後に発生した状況とが一致した数あるいは頻度が所定の閾値以上であるか否かに基づいて、前記ユーザのタイプを決定してもよい。
例えば、ユーザのタイプを上位のグループと下位のグループに区分したとき、選択結果に対応する状況と、過去の現実世界のイベント内で問題に対応する状況の後に発生した状況とが一致した数あるいは頻度が所定の閾値以上である場合には、上位のグループの中からユーザのタイプを決定し、当該所定の閾値未満である場合には、下位のグループの中からユーザのタイプを決定してもよい。ここで、例えばイベントが野球の試合の場合、上位のグループには、現実世界におけるいずれかの野球チームの一監督に相当するタイプが含まれ、下位のグループには、現実世界におけるいずれかの野球チームの二軍監督に相当するタイプが含まれてもよい。また、例えば、現実世界におけるいずれかの野球チームの監督に相当するタイプが上位のグループに含まれる場合、下位のグループには、監督としての条件を満たさないものとして、例えばコーチファン初心者、あるいは野次などに相当するタイプが含まれてもよい。この場合、ユーザは、自身のタイプが上位のグループ内のいずれかのタイプとして決定されるために、過去の現実世界のイベント内で実際に発生した状況と一致する選択肢を選択することがもとめられる。このため、ユーザに対して、上位のグループに含まれるタイプになろうとする挑戦意欲あるいは緊張感を喚起することができ、より興趣性のある仕組みとすることができる。

0015

本発明の第2の観点は、情報処理方法である。
この情報処理方法は、
現実世界のイベント内で発生しうる状況に関する問題の情報と、当該状況の後に前記イベント内で発生しうる状況についての複数の選択肢の情報と、を対応付けて記憶装置に記憶させるステップと、
前記イベントと同種のイベントが実時間で行われる場合に、実時間のイベント内で特定の状況が発生したタイミングにおいて、前記記憶装置を参照して、前記特定の状況に関する問題と、当該問題に対応付けられている複数の選択肢とをユーザに提示するステップと、
提示された複数の選択肢のうちいずれかに対する前記ユーザの選択結果を受け付けるステップと、
受け付けた選択結果に基づいて前記ユーザのタイプを決定するステップと、
決定したタイプに関する情報を前記ユーザに通知するステップと、
を備える。

0016

本発明の第3の観点は、コンピュータに、
現実世界のイベント内で発生しうる状況に関する問題の情報と、当該状況の後に前記イベント内で発生しうる状況についての複数の選択肢の情報と、を対応付けて記憶装置に記憶させる機能、
前記イベントと同種のイベントが実時間で行われる場合に、実時間のイベント内で特定の状況が発生したタイミングにおいて、前記記憶装置を参照して、前記特定の状況に関する問題と、当該問題に対応付けられている複数の選択肢とをユーザに提示する機能、
提示された複数の選択肢のうちいずれかに対する前記ユーザの選択結果を受け付ける機能、
受け付けた選択結果に基づいて前記ユーザのタイプを決定する機能、及び
決定したタイプに関する情報を前記ユーザに通知する機能、
を実現させるためのプログラムである。

0017

コンピュータは、例えばネットワークサーバ、大型計算機等であってよい。また、このプログラムは、DVD−ROMやCD−ROM等のコンピュータが読み取り可能な情報記憶媒体に格納されてもよい。

0018

本発明の第4の観点は、通信端末(10)と、当該通信端末(10)からアクセスされるサーバ(20)とを含む情報処理システムである。
この情報処理システムは、
現実世界のイベント内で発生しうる状況に関する問題の情報と、当該状況の後に前記イベント内で発生しうる状況についての複数の選択肢の情報と、を対応付けて記憶装置に記憶させる記憶手段(51)、
前記イベントと同種のイベントが実時間で行われる場合に、実時間のイベント内で特定の状況が発生したタイミングにおいて、前記記憶装置を参照して、前記特定の状況に関する問題と、当該問題に対応付けられている複数の選択肢とをユーザに提示する提示手段(52)、
前記提示手段(52)によって提示された複数の選択肢のうちいずれかに対する前記ユーザの選択結果を受け付ける受付手段(53)、
前記受付手段(53)によって受け付けた選択結果に基づいて前記ユーザのタイプを決定する決定手段(54)、
前記決定手段(54)によって決定したタイプに関する情報を前記ユーザに通知する通知手段(55)、
の各手段を、前記通信端末(10)又は前記サーバ(20)のいずれか一方が備える。

0019

なお、上記では、本発明の理解を容易にするため、適宜図面に記載された符号を括弧書きで記載しているが、これにより本発明に係る情報処理装置等が図示の態様に限定されるものではない。

発明の効果

0020

本発明の情報処理装置、情報処理方法、プログラム、情報処理システムによれば、実時間のイベントに自らが参加しているかのような感覚をユーザが感じることができる。

図面の簡単な説明

0021

第1実施形態の情報処理システムの基本構成を示す図。
第1実施形態の通信端末の外観の例を示す図。
第1実施形態の通信端末の構成を示すブロック図。
第1実施形態のメインサーバの構成を示すブロック図。
ユーザの通信端末に表示される一連ウェブページとその表示タイミングの例を、実時間で進行する野球の試合と対応付けて示す図。
ユーザの通信端末に表示されるウェブページの例を示す図。
ユーザの通信端末に表示される一連のウェブページとその表示タイミングの例を、実時間で進行する野球の試合と対応付けて示す図。
第1実施形態のデータベースサーバの構成を示すブロック図。
問題データベースの構成例を示す図。
回答データベースの構成例を示す図。
タイプデータベースの構成例を示す図。
試合運営プログラムを実行しているときにメインサーバに表示される入力用画面の例を示す図。
試合運営プログラムを実行しているときにメインサーバに表示される入力用画面の例を示す図。
第1実施形態の情報処理装置の機能ブロック図。
第1実施形態の情報処理装置の処理を示すフローチャート
(a)〜(c)は、第2実施形態において、複数のタイプの各々に対応する選択肢の選択回数の一例を示す図。
第3実施形態の情報処理装置の機能ブロック図。
第4実施形態の情報処理装置の機能ブロック図。
親密度データの構成例を示す図。

実施例

0022

以下、本発明の実施形態について説明する。

0023

(1)第1実施形態
(1−1)情報処理システムの構成
図1は、実施形態の情報処理システムのシステム構成例を示している。図1に示すように、この情報処理システムは、例えばインターネットなどの通信網NW(ネットワーク)に接続可能な通信端末10a,10b,10c,…と、通信網NWに接続されているメインサーバ20と、データベースサーバ30とによって構成されている。各通信端末10a,10b,10c,…はそれぞれ、個々のユーザによって操作される端末であり、例えば、携帯端末スマートフォン、PDA(Personal Digital Assistant)、パーソナルコンピュータ、双方向の通信機能を備えたテレビジョン受像機(いわゆる多機能型スマートテレビも含む。)などの通信端末である。なお、以下の説明において、各通信端末10a,10b,10c,…に共通して言及するときには、通信端末10と表記する。
この情報処理システムにおいて、メインサーバ20は、クライアントである通信端末10と通信可能に構成されており、通信端末10に対してゲーミングサービスを提供する。メインサーバ20には、ウェブブラウザ上で動作可能なアプリケーション実装されている。データベースサーバ30は、後述する速報サービスやゲームを実行する上での後述する様々な情報を格納しており、それらの情報の読み書きのためにメインサーバ20と例えば有線で接続される。
通信端末10は、メインサーバ20によって提供されるウェブページを表示可能なウェブブラウザを備えており、ユーザは、通信端末10でウェブページに対する操作をしてメインサーバ20からウェブサービスを受ける。

0024

また、図1には図示していないが、メインサーバ20とは別に各通信端末10のユーザを認証するための認証サーバを設けてもよい。また、多くの通信端末10からのアクセスを受け入れるために複数のメインサーバ20を設ける場合は、その複数のメインサーバ20間の負荷を調整するためのロードバランサを設けてもよい。また、メインサーバ20は単一のサーバ装置として構成してもよいが、機能を分散させた複数のサーバ装置として構成してもよい。

0025

(1−2)通信端末の構成
図2及び図3を参照して通信端末10について説明する。
図2は、通信端末10の外観の例を示す図であって、(a)は、例えば折り畳み式の携帯端末(携帯電話機)などの釦入力方式の通信端末を例示したものであり、(b)は、例えばスマートフォンなどのタッチパネル入力方式の通信端末を例示したものである。図3は、通信端末10の内部構成を示すブロック図である。
図3に示すように、通信端末10は、CPU(Central Processing Unit)11、ROM(Read Only Memory)12、RAM(Random Access Memory)13、画像処理部14、指示入力部15、表示部16、及び、信号送受信部としての通信インタフェース部17を備えており、各部間の制御信号あるいはデータ信号伝送するためのバス18が設けられている。

0026

CPU11は、ROM12内のウェブブラウザをRAM13にロードして実行する。そして、CPU11は、指示入力部15等によってユーザに入力されるURL(Uniform Resource Locator)の適切な指定に基づき、通信インタフェース部17を介して、メインサーバ20からウェブページを表示するためのデータ、すなわち、HTML(HyperText Markup Language)文書や当該文書と関連付けられた画像などのオブジェクトのデータ(以下、総称して適宜「HTMLデータ」と表記する。)を、通信インタフェース部17を介して取得し、そのHTMLデータを解釈する。なお、通信端末10には、ウェブブラウザのブラウザ機能拡張するための様々なプラグインが実装されていてよい。そのようなプラグインの一例は、アドビシステムズ社(米国)によるフラッシュプレイヤである。あるいは、本実施形態でのHTMLデータを、動画及び音声再生機能を備えたHTML5形式としてもよい。
なお、HTMLデータの取得に当たって、CPU11は、予め登録されたユーザID(ユーザ識別情報)、あるいは指示入力部15を介して入力されるユーザIDを含むアクセス要求メッセージを、通信インタフェース部17を介してメインサーバ20へ通知する。

0027

ウェブブラウザは、メインサーバ20とHTTP(HyperText Transfer Protocol)に従った通信を行う。ウェブブラウザは、メインサーバ20から取得したHTMLデータを解釈して、画像処理部14を介してウェブページを表示部16に表示する。また、ウェブブラウザは、ユーザが指示入力部15の操作によってウェブページ上のハイパーリンク(Hyperlink)またはメニューが選択されると、ウェブページの更新のために、その選択結果を含むHTTPリクエストをメインサーバ20に送信する。

0028

画像処理部14は、HTMLデータの解析結果としてCPU11から与えられる表示用画像データに基づいて、表示部16にウェブページを表示する。表示部16は、例えば、マトリクス状画素単位で配置された薄膜トランジスタを含むLCD(Liquid Cristal Display)モニタであり、表示用画像データに基づいて薄膜トランジスタを駆動することでウェブページの画像を表示画面16aに表示する。

0029

通信端末10が釦入力方式の通信端末(図2(a))である場合、指示入力部15は、ユーザの操作入力を受け入れるための方向指示釦と決定釦などの複数の指示入力釦を含む釦群15a、及び、テンキーなどの複数の指示入力釦を含む釦群15bを備え、各釦の押下(操作)入力を認識してCPU11へ出力するためのインタフェース回路を含む。例えば、方向指示釦は、表示部16に表示されているウェブページをスクロールして表示することをCPU11へ指示するために設けられる。また、決定釦は、例えばウェブページ上で複数のハイパーリンクまたはメニューが表示されるときに、アクティブ表示(例えば強調表示)されている1つのハイパーリンクまたはメニューをユーザが選択することをCPU11へ指示するために設けられる。なお、通信端末10を小型の携帯端末によって構成する場合には、これらの釦は、ユーザが通信端末10を片手で保持したままその親指で操作(クリック)しやすいように、通信端末10の前面に配置されていることが好ましい。図2(a)に示す例では、釦群15bは、釦群15aの下方に配置され、「0」〜「9」、「*」、「#」(テンキー)が表記された複数の指示入力釦を含む。

0030

通信端末10がタッチパネル入力方式の通信端末(図2(b))である場合、指示入力部15は、主として表示画面16aに指先あるいはペンで触れることによるタッチパネル方式の入力を受け付ける。タッチパネル入力方式は、静電容量方式などの公知の方式でよい。なお、図2(b)に示すように、通信端末10がタッチパネル入力方式の場合であっても釦群15aが設けられる場合もある。

0031

通信端末10に表示されるウェブページ上のメニューの選択操作は、例えば通信端末10が携帯端末である場合には、方向指示釦の押下操作によってメニューを選択し、決定釦の押下操作によって、選択したメニューを確定することによって行われる。また、選択操作は、例えば通信端末10がタッチパネル入力方式の場合には、ウェブページが表示されている表示画面16a上のメニューの位置を指あるいはペンで指示(タッチ操作)することによって行われる。

0032

(1−3)メインサーバの構成
図4を参照してメインサーバ20の構成について説明する。
メインサーバ20は、クライアントである通信端末10に対してウェブサービスを提供する。図4に示すように、メインサーバ20は、CPU21、ROM22、RAM23、データベース(DB)アクセス部24、通信インタフェース部25、入力部26、及び、表示部27を備えており、各部間の制御信号あるいはデータ信号を伝送するためのバス28が設けられている。なお、メインサーバ20は、ハードウエアに関しては汎用ウェブサーバと同一の構成をとることができる。

0033

ROM22には、クライアントである通信端末10のウェブブラウザに対してHTML文書や画像などのオブジェクトの表示(ウェブページの表示)のサービスを提供するプログラムや試合運営プログラム(後述する)が格納されている。ROM22には、プログラム以外にもCPU21によって参照される各種データが格納されている。
CPU21は、ROM22内のプログラムをRAM23にロードして実行し、通信インタフェース部25を介して、各種の処理を行う。

0034

例えば、CPU21は、通信インタフェース部25を介して、メインサーバ20のウェブブラウザとの間でHTTPに従った通信を行う。例えば、CPU21は、通信インタフェース部25を介して、通信端末10から受信したHTTPリクエスト(例えば、ウェブページ上でのユーザのハイパーリンクまたはメニューの選択結果を含む。)に基づいて所定のデータ処理や、演算処理を行い、その処理結果を含むHTTPレスポンスをメインサーバ20のウェブブラウザに返す。HTTPレスポンスには、ウェブページを更新するためのHTMLデータが含まれる。また、メインサーバ20が通信端末10のユーザの認証処理を行う場合には、CPU21はその認証処理を行う。
データベースアクセス部24は、CPU21がデータベースサーバ30に対してデータの読み書きを行うときのインタフェースである。
入力部26は、例えばキーボード及び/又はマウス等の入力装置と、その入力装置によって入力されるデータをメインサーバ20内で認識させるためのインタフェース回路とを含む。表示部27は、CPU21によって実行されるプログラムの実行結果(出力結果)を表示するためのものであって、例えば前述したLCDモニタを含んでもよい。

0035

(1−4)メインサーバによって提供されるサービス
本実施形態のメインサーバ20は、実時間で行われているイベントに関する内容を、ユーザの通信端末10からのHTTPリクエストに応じて、通信端末10にて表示可能な形式で送信する。以下、実時間で行われているイベントが、プロ野球(以下、適宜「野球」と略記する。)の試合(ホームチームアウェイチーム対戦)、あるいはその試合の放送番組である場合を例として説明する。本実施形態では、通信端末10からメインサーバ20に対して、HTTPリクエストが所定時間おきに(例えば、5〜10秒間隔で)自動的に(つまり、ユーザ操作無しに)送信され、それによって試合の経過(スコア等)を含む野球の試合に関する実時間の情報を含むHTMLデータを含むHTTPレスポンスが通信端末10へ返信される。以下では、野球の試合に関する情報が逐次更新されて通信端末10に提供されるウェブサービスを、「速報サービス」という。

0036

上述した速報サービスは、メインサーバ20が提供する単独のサービスであってもよいが、例えばソーシャルゲームの一サービスとして組み込まれていてもよい。この場合、ゲームの内容と速報サービスの対象となるイベントの内容が、互いに関連性があることが好ましい。例えば、そのような好ましい例では、メインサーバ20は、野球を対象としたデジタルカードゲーム(ソーシャルゲーム)のゲーミングサービスを提供するサーバとしても機能する。

0037

本実施形態において、速報サービスは、HTTPリクエストに応じて実時間で行われている野球の試合(イベント)の内容を送信するだけではなく、その試合の状況に応じてユーザに対して適時に問題の出題も行う。つまり、速報サービスは、問題とその問題に対する複数の選択肢についての情報を、いずれかの選択肢をユーザが選択(決定)可能な状態で、ユーザの通信端末10へ送信することも含む。問題は、例えば出題時の試合の状況下で、その状況以降においてその試合で発生する状況を問うものであり、所定数(例えば、3〜4個)の選択肢の中からいずれかの選択肢をユーザが選択(決定)するように構成されている。問題が出題された場合には、その問題に対する回答受付期間が設定される。回答受付期間は、ユーザによって選択された選択肢をユーザの回答として受付可能な期間であり、例えば、出題された時刻(出題時刻)から所定時間まで、又は問題に対する回答の選択肢のうちいずれかの状況が野球の試合において発生するまでの期間である。

0038

例えば問題の一例は、チームPとチームQの野球の試合の場合、以下のようなものである。
・出題のタイミング:「1回の表裏のイニングの間」
・出題時の試合の状況:「1回の裏、同点、ノーアウトランナー無し」
・問題:「1回の裏のチームQの攻撃は本田から。あなたならどのような策をとる?」
・回答の選択肢:「A:強打、B:セーフティバント、C:その他」

0039

つまり、出題の内容は、実時間で進行している実際の野球の試合(イベント)の状況に関するものであり、例えばチームの監督の立場に立って、現在の状況から監督の采配をユーザ自ら考えさせる問題となっている。そのため、実際の野球の試合に自らが参加しているかのような感覚をユーザが感じることができるようになっている。

0040

図5は、速報サービスによってユーザの通信端末に表示される一連のウェブページとその表示タイミングの例を、実時間で進行する野球の試合と対応付けて示す図である。この例では、回答受付期間が概ね、特定のイニングの表と裏の間の期間に設定されている。図5において、ウェブページP1は、速報サービスにおいて問題(この場合、「第2問」)の出題が行われた場合の例を示しており、表示領域101,102を含む。
問題の出題が行われていない場合のウェブページは図示しないが、少なくともスコアを表示する表示領域102を含み、さらに試合についてのより詳細な情報を表示してもよい。このような速報サービスの提供は、ユーザの通信端末10から速報サービスのURLを指定したHTTPリクエストをメインサーバ20へ送信することによって開始される。
ウェブページP1に示す表示領域101には、上述した問題と当該問題についての選択肢A〜Cが表示されている。表示領域102には、現在のチームPとチームQの試合のスコアが表示される。

0041

図5の例では、出題時刻は、1回表のチームPの攻撃が終了した時刻である。後述するように、出題時刻は、メインサーバ20のオペレータ(以下、単に「オペレータ」という。)によって決定され、その時点での試合の状況から、適切な問題及び回答の選択肢が、後述する問題データベースからオペレータによって選択される。
図5の例では、回答受付期間は、投手が1回裏の最初の打者に対して第1球を投げる前までの期間に設定されている。図5のウェブページP1はその後、回答受付期間内においてP2に示すように更新される。ウェブページP2には、表示領域101,102に加えて、ユーザに対して回答を促すメッセージ(図の例では、「回答受付中です!」)が表示される。

0042

回答受付期間中にユーザが選択肢A〜Cのいずれか(この場合、選択肢B)に対する選択操作を行うと、P3に示すようにウェブページが更新される。ウェブページP3には、表示領域101に加えて、選択された選択肢に基づいて決定されたユーザのタイプに関する情報が表示される。これにより、ユーザは、例えば現在の試合の状況からその次に発生する状況を予想して選択肢を選択することによって、自身のタイプを知ることができる。ここで、本実施形態では、ユーザのタイプを、野球チームの現役あるいは過去の監督別に分類した場合(図の例では、「SチームのB監督」)を一例として示している。ユーザのタイプに相当する監督は、例えば、問題が出題されたときと同じ状況が過去の野球の試合中に発生したときに、ユーザが選択した選択肢と同じ采配(結果)をとった回数あるいは頻度の多い監督である。この場合、ユーザは、自身のタイプに関する情報が通知されることにより、野球の試合の特定の状況における自身の予想(すなわち、特定の状況に対する判断や采配など)が、現役あるいは過去の監督のうちどの監督に類似しているのかを知ることができる。このため、ユーザが、例えば実時間の野球の試合における様々な状況において自身の特徴や傾向などを認識することができるという興趣性のある仕組みとすることができる。なお、回答受付期間の経過した後にユーザが選択操作を行った場合には、ウェブページP2から、例えば図6のP4に示すようにウェブページが更新されてもよい。これによって、ユーザによって決定された選択肢が受け付けられなかったことが通知される。

0043

図7は、速報サービスによってユーザの通信端末に表示される一連のウェブページとその表示タイミングの別の例を、実時間で進行する野球の試合と対応付けて示す図である。この例では、回答受付期間が概ね、ある打者とその次の打者が打席に入っている期間の間に設定されている。図7において、ウェブページP5は、速報サービスにおいて問題(この場合、「第7問」)の出題が行われた場合の例を示しており、図5のP1と同様に、表示領域101,102を含む。

0044

図7の例では、出題時刻は、4回表のチームPの攻撃において最初にランナーが出塁した時刻である。後述するように、出題時刻は、オペレータによって決定され、その時点での試合の状況から、適切な問題及び回答の選択肢が、オペレータによって後述する問題データベースから選択される。
図7の例では、回答受付期間は、4回表の第2打者がヒットを打って出塁してから、それに続く第3打者に対して第1球が投げられる前までの期間に設定されている。図7のウェブページP5はその後、回答受付期間内においてP6に示すように更新され、それによって、ユーザに対して回答を促すメッセージ(図の例では、「回答受付中です!」)が表示される。回答受付期間中にユーザが選択肢A〜Cのいずれか(この場合、選択肢C)に対する選択操作を行うと、P7に示すようにウェブページが更新される。これによって、選択された選択肢に基づいて決定されたユーザのタイプ(図の例では、「RチームのA監督」)に関する情報が通知される。

0045

なお、本実施形態では、ユーザが1つの問題に対して回答するごとに当該ユーザのタイプが通知される場合を一例として説明しているが、この場合に限られない。例えば、複数の問題の各々に対するユーザの回答結果に基づき当該ユーザのタイプを決定し、例えば速報サービスが終了した場合に当該タイプを通知するためのウェブページ(図示せず)が、当該ユーザの通信端末10に表示されてもよい。

0046

また、本実施形態では、ユーザのタイプが野球チームの現役あるいは過去の監督別に分類されている場合を一例として説明しているが、ユーザのタイプがどのように分類されるかについては任意に設定されてもよい。例えば、ユーザのタイプは、性格別(例えば、積極型、慎重型など)に分類されてもよいし、あるいは例えば速報サービスがソーシャルゲームの一サービスとして組み込まれている場合には、当該ゲームのキャラクタ別などに分類されてもよい。

0047

(1−5)データベースサーバ
データベースサーバ30(記憶装置;図1参照)は、大容量のハードディスク装置やRAID(Redundant Arrays of Inexpensive Disks)等の形態の装置等、汎用ストレージで実現できる。データベースサーバ30内の各データベースは、メインサーバ20のデータベースアクセス部24を介してCPU21からのデータの読み書きが可能となるように構成されている。
図8に、データベースサーバ30の構成の一例を示す。図8に示すように、データベースサーバ30は、ユーザデータベース31と、試合記録データベース32と、出題運営データベース33とを備える。
メインサーバ20が野球を対象としたデジタルカードゲームのゲーミングサービスをも提供する場合には、ユーザデータベース31は、ユーザID(ユーザ識別情報)ごとにユーザデータが含まれている。特定のユーザIDのユーザデータは、例えば、通信端末10を特定するための情報(例えばUID(Unique Identifier)などの端末の個体識別情報メールアドレス等)を認証情報として含んでもよい。ユーザデータはまた、ユーザがゲーム上で保有している各種のポイント、ゲーム上で利用可能なアイテム、あるいはユーザが保有するゲーム上のオブジェクト(例えば、カードやキャラクタ等)のパラメータ(例えばオブジェクトの能力を示す変数)のデータ、ユーザと関係付けられた他のユーザ(仲間)のユーザID等、ゲーム用データを含んでもよい。ユーザデータベース31に含まれるデータは、メインサーバ20によって逐次更新されうる。

0048

試合記録データベース32には、野球の試合毎にそのスコアのデータが記録される。例えば、各試合の終了後に、メインサーバ20のRAM23に記憶する試合のスコアの最終的なデータが試合記録データベース32に転送される。

0049

出題運営データベース33は、問題データベース、回答データベース、及びタイプデータベースを含む。図9は、問題データベースの構成例を示す図である。図10は、回答データベースの構成例を示す図である。図11は、タイプデータベースの構成例を示す図である。
問題データベースは、野球の試合において問題を出題するときに、オペレータの操作に基づいてCPU21によって読み出されるデータベースであり、実際の野球の試合(現実世界のイベント)の中で発生しうる状況に関する問題の情報と、当該状況の後に野球の試合の中で発生しうる状況についての複数の選択肢の情報と、が対応付けて記述されている。図9に示す問題データベースの例では、各問題が識別番号(QID)で管理されており、QID毎に、試合の状況と、その状況に関する問題と、その問題に対する複数の選択肢とが対応付けて記述されている。

0050

回答データベースは、野球の試合において出題された問題に対して各ユーザから受け付けた回答(いずれかの選択肢)が記述されているデータベースである。図10に示す回答データベースの例では、各問題(QID:3,8,14,…)に対して、ユーザIDに対応付けられた選択肢(A,B,C,等)が記録される。

0051

タイプデータベースは、ユーザのタイプ毎に、出題された問題に対応する複数の選択肢の各々を対応付けて記録したデータである。図11に示すタイプデータベースの例では、ユーザのタイプに相当する現在あるいは過去の監督毎に、問題の内容を識別するためのQID(図9参照)と、問題に対応する複数の選択肢のうちいずれかの選択肢とが対応付けられている。ここで、ユーザのタイプに相当する監督と、複数の選択肢のうちいずれかの選択肢とは、例えば過去に行われた実際の野球の試合の結果に基づいて対応付けられてもよい。過去の野球の試合の結果は、例えば、現時点を起点として過去の所定期間(例えば10年間)内に行われたプロ野球の全試合の結果がスコアブック形式で記録された情報であってもよい。また、監督に対応する選択肢は、問題と同じ状況が過去の野球の試合中に発生したときに当該監督がとった回数あるいは頻度の多い采配によって決定されてもよい。図11の例を参照して説明すると、例えば、QIDが「8」の状況(つまり、1回裏、同点、ノーアウト、ランナー無しの状況)において、RチームのA監督が「強打」の采配をとった回数あるいは頻度が「セーフティバント」あるいは「その他」の采配をとった回数あるいは頻度よりも多い場合には、RチームのA監督には、QIDが「8」の状況に対応する選択肢として「A.強打」という選択肢が対応付けられる。

0052

(1−6)試合の記録方法出題方法
以下、図12及び図13を参照して、試合の記録方法と出題方法について説明する。図12及び図13はそれぞれ、メインサーバ20のCPU21が試合運営プログラムを実行しているときに、メインサーバ20の表示部27に表示されるオペレータによる入力用画面の例を示す図である。図12は、スコア等の試合情報の入力を行うための画面(以下、「試合記録用画面」という。)の一例を示す。図13は、試合の前後、あるいは試合の途中においてオペレータが適当なタイミングで出題等を行うときの入力用画面(以下、「出題用画面」という。)の一例である。
試合運営プログラムは、ウェブによる速報サービスを提供するときに、実時間で進行する野球の試合に基づく情報の入力を、オペレータの操作によって受け入れるためにCPU21によって実行されるプログラムである。オペレータは、例えば、実時間で行われている野球の試合のテレビジョン放送を視聴し、あるいはスタジアム観戦しながら、試合記録用画面及び出題用画面に対する入力を行う。試合運営プログラムの実行により、試合記録用画面及び出題用画面に入力される情報を基に、後述する所定の処理が行われる。

0053

図12に示すように、試合記録用画面は、試合の進行に伴って変化するデータを適宜設定するための表示領域201と、表示領域201内のデータの設定を確定させるときの操作対象となるメニュー202(「編集確認」)とを含む。表示領域201内の各項目プルダウンメニュー形式となっており、各項目について複数のメニューの中からいずれかのメニューを選択することができる。試合中に変更する項目は、イニング、表裏、ホームスコア(ホームチームのスコア)、及びアウェイスコア(アウェイチームのスコア)である。例えばホームスコアを変更するときには、対応するプルダウンメニューを操作して、例えば0〜20の数字の中からいずれかの数字を選択する。メニュー202(「編集確認」)が選択操作されると、表示領域201内に設定されている内容によって試合情報が更新される。更新後にユーザの通信端末10からHTTPリクエストを受けた場合、メインサーバ20は、更新された試合情報を基にHTMLデータを生成する。これによって、ユーザの通信端末10上に表示されるウェブページ上のスコア(例えば、図5のP1の表示領域102)が更新される。

0054

図13に示すように、出題用画面は、問題編集を行うための領域(「問題編集」)と、出題を行うための領域(「出題」)とに区分されている。問題データベース(図9参照)には、予め実時間で行われる野球の試合で生じうる状況についての問題とその回答の選択肢が記録されているが、実時間で行われる野球の試合では想定外の状況も生じうる。そこで、実時間で行われている野球の試合のテレビジョン放送を視聴し、あるいはスタジアムで観戦しながら、問題データベースに記録されていないが現実の状況下で適切な問題を思いついたときには、オペレータは問題を自ら作成することができる。オペレータが問題を作成するときの入力領域が問題編集の領域である。
この問題編集のための領域には、問題のテキスト入力を受け入れるためのテキストボックス301と、試合の状況についてのテキスト入力を受け入れるためのテキストボックス302と、問題についての各選択肢のテキスト入力を受け入れるためのテキストボックス303と、作成された問題とその問題についての各選択肢を問題データベースに登録するためのメニュー304(「登録」)とが含まれる。テキストボックス301,302,303が入力済みの状態でメニュー304が選択操作されると、CPU21は、問題データベースに既に登録されているQIDと重複しない新たなQIDを発行して、発行したQIDと対応付けて、テキストボックス301,302,303にそれぞれ入力された問題と、状況と、各選択肢とを問題データベースに書き込む。

0055

図13において、出題を行うための領域には、登録されているQIDの一覧を表示するためのメニュー305と、出題対象となるQIDを選択するための表示領域306と、出題についての設定入力を行うための表示領域307とが含まれる。
メニュー305(「QIDの一覧表示」)を選択操作することによって、図9に例示した問題データベースの内容が一覧表示される画面(図示せず)に移行する。この画面を見ることでオペレータは、出題すべき問題のQIDを認識することができる。
出題すべきQIDを決定した場合、オペレータは、表示領域306のうちプルダウンメニュー306aを操作して、出題すべきQIDの番号を決定した後に、メニュー306b(「選択する」)を選択操作する。これによって、選択(決定)されたQIDの番号が、表示領域307のリスト末尾に加えられる。表示領域307には、各QIDに対応付けて、削除メニュー307a、出題指示メニュー307b、受付終了メニュー307c、及び、QIDが有効か否かを示す有効/無効の情報307dが設けられている。表示領域307のリストでは、有効となっているQIDについてのみ削除メニュー307a、出題指示メニュー3067、又は受付終了メニュー307cの選択操作が可能である。無効となっているQIDは既に出題済みで、回答受付期間が終了したQIDである。表示領域307のリストには順に末尾にQIDが加えられるため、最新のQID、つまり有効となるQIDは通常、リスト上の最後尾となっている。

0056

いったん表示領域307のリストに加えられたQIDは、出題指示メニュー307bが選択操作される前であれば、削除メニュー307aを選択操作することで表示領域307のリストから削除することが可能である。例えば、図13の例では、QID:14が現在有効であるが、出題指示メニュー307bが選択操作される前であれば、QID:14を削除して、代わりに新たなQIDをリストに追加することが可能である。表示領域307において、有効となっているQIDに対応する出題指示メニュー307bが選択操作されると、メインサーバ20は、それ以降にHTTPリクエストを受信した場合に、選択されたQIDに対応する問題とその選択肢を含むHTMLデータをユーザの通信端末10へ送信する。
問題の出題時刻から所定時間後に回答受付期間を終了させる場合には、オペレータは何もしない。問題の出題後の所定の状況が生じたタイミング、あるいは問題に対するいずれかの選択肢が生ずるまでのタイミングで回答受付期間を終了させる場合には、オペレータは、実時間で行われている野球の試合のテレビジョン放送を視聴し、あるいはスタジアムで観戦しながら、実時間の状況の変化を案して回答受付期間を終了させるべき適切なタイミングを決定して、有効となっているQIDに対応する受付終了メニュー307cを選択操作する。これによって、それ以降に回答としての選択肢を含むHTTPリクエストを受信した場合には、その回答の受付が行われないようになる。

0057

(1−7)情報処理装置における各機能の概要
本実施形態では、メインサーバ20及びデータベースサーバ30によって情報処理装置が構成されている。以下では、ユーザに提供される速報サービスが野球の試合である場合を例として、本実施形態の情報処理装置で実現される機能について、図14を参照して説明する。図14は、本実施形態の情報処理装置で主要な役割を果たす機能を説明するための機能ブロック図である。

0058

記憶手段51は、野球の試合(現実世界のイベント)の中で発生しうる状況に関する問題の情報と、当該状況の後にその野球の試合の中で発生しうる状況についての複数の選択肢の情報と、を対応付けてデータベースサーバ30(記憶装置)に記憶させる機能を備える。野球の試合の中で発生しうる状況は特に制限されるものではなく、試合中の特定の場面(例えば、3回表で1死満塁など)であってもよいし、試合中の区切り(例えば、特定の回のイニング間や、投手交代の間、試合開始前、試合開始後等)等の時期的な状況であってもよい。
記憶手段51の機能を実現するために、メインサーバ20のCPU21は、試合前又は試合中にオペレータによって入力された問題のテキストデータと、その問題に対応する複数の選択肢のテキストデータとを固有のQIDに対応付けて、出題運営データベース33内の問題データベース(図9参照)に書き込む。

0059

また、記憶手段51は、過去の野球の試合(現実世界のイベント)の結果に基づいて、タイプを複数の選択肢の各々に対応付けて、データベースサーバ30(記憶装置)に記憶させる機能を備えてもよい。この場合、過去の野球の試合の結果に適合したタイプを決定することができ、信頼性の高いタイプ決定を行うことが可能となる。
この場合における記憶手段51の機能を実現するために、メインサーバ20のCPU21は、ユーザのタイプに相当する監督ごとに、複数のQIDと、各QIDのそれぞれに対応する選択肢とを対応付けて、出題運営データベース33内のタイプデータベース(図11参照)に書き込む。なお、過去の野球の試合の結果を参照して、ユーザのタイプに相当する監督ごとに、各QIDのそれぞれに対応する選択肢を決定する処理は、CPU21が行ってもよいし、例えばオペレータが行ってもよい。

0060

提示手段52は、野球の試合(同種のイベント)が実時間で行われる場合に、実時間の野球の試合内で特定の状況が発生したタイミングにおいて、問題データベースを参照して、その特定の状況に関する問題と、当該問題に対応付けられている複数の選択肢とをユーザに提示する機能を備える。
提示手段52の機能は以下のようにして実現される。実時間の野球の試合の中で特定の状況が発生した場合、オペレータは、図13の出題用画面において、問題データベースに記録されているいずれかのQIDを選択して表示領域307のリストに加え、出題指示メニュー307bを選択操作する。なお、オペレータは、実時間の野球の試合の中で発生した特定の状況が予め作成されている問題データベースに存在しないことを、メニューm305を操作すること等によって確認すると、問題編集のための領域内でテキスト入力を行うことによって新たな問題を作成して問題データベースに登録する。その上で、オペレータは、その新たな問題に対応するQIDを選択して表示領域307のリストに加え、出題指示メニュー307bを選択操作する。出題指示メニュー307bが選択操作されたことを認識すると、メインサーバ20のCPU21は、それ以降にユーザの通信端末10からHTTPリクエストを受信した場合には、選択された問題と、当該問題に対応する選択肢とを含むHTMLデータを生成してユーザの通信端末10へ送信する。この場合、ユーザの通信端末10には、問題と、当該問題に対応する選択肢とを含むウェブページが表示される。これによって、ユーザに対して、問題と当該問題に対応する選択肢とが提示される。

0061

受付手段53は、提示手段52によって提示された複数の選択肢のうちいずれかに対するユーザの選択結果を受け付ける機能を備える。
ここで、選択結果を受け付ける期間(回答受付期間)は任意に設定され得るが、例えば、所定時刻までの、又はユーザに提示された選択肢のうちいずれかの状況が実時間の野球の試合(イベント)において発生するまでの期間であってもよい。また、「所定時刻」とは、例えば、実時間の野球の試合において特定の状況が発生してから所定時間後の時刻に限られず、実時間の野球の試合において特定の状況の後に発生した状況の発生時刻であってもよい。例えば、特定の状況が発生した時刻をT0とし、ユーザに提示された選択肢のうちいずれかの状況が前記実時間の野球の試合において発生する時刻をT1としたときに、T0とT1の間において、実時間の野球の試合内の所定の状況が発生した時刻であってもよい。つまり、いずれかの選択肢の状況が発生する前に、所定の状況が発生することで選択肢の回答の受付が終了してもよい。例えば、9回表の攻撃が終了した時刻(T0)に出題し、出題の内容が「9回裏、チームPの監督は抑えの切り、野田を投入するか?」というものであり、上記時刻T1が、9回裏が終了する時刻である場合には、回答受付期間の終了時刻は、9回裏が開始した時刻(T0とT1の間の時刻)であってもよい。

0062

受付手段53の機能は以下のようにして実現される。オペレータにより有効となっているQIDに対応する出題指示メニュー307bが選択操作された後、受付終了メニュー307cが選択操作されるまでの期間、つまり回答受付期間内において、メインサーバ20のCPU21は、ユーザの通信端末10から、問題の回答としてのいずれかの選択肢を含むHTTPリクエストを取得した場合には、その選択肢をユーザIDとQIDに対応付けて回答データベースに書き込む。回答データベースへの書き込み処理は、ユーザの選択結果(選択肢)を受け付けたことに相当する。

0063

決定手段54は、受付手段53によって受け付けた選択結果に基づいてユーザのタイプを決定する機能を備える。また、決定手段54は、受付手段53によって選択結果を受け付けると、データベースサーバ30(記憶装置)を参照して、前記選択結果となる選択肢に対応するタイプをユーザのタイプとして決定する機能を備えてもよい。
決定手段54の機能は以下のようにして実現される。メインサーバ20のCPU21は、ユーザの通信端末10から、問題の回答としてのいずれかの選択肢を含むHTTPリクエストを取得した場合に、タイプデータベースにアクセスして、当該HTTPリクエストに含まれる選択肢と同じ選択肢に対応付けられている監督を抽出する。当該監督の抽出処理は、ユーザのタイプを決定することに相当する。なお、当該HTTPリクエストに含まれる選択肢と同じ選択肢に対応付けられている監督が複数存在する場合、CPU21は、各監督をユーザのタイプとして決定してもよい。

0064

また、決定手段54は、選択結果に対応する状況と、過去の野球の試合(現実世界のイベント)で問題に対応する状況の後に発生した状況とが一致した数あるいは頻度が所定の閾値以上であるか否かに基づいて、ユーザのタイプを決定してもよい。
例えば、ユーザのタイプを上位のグループと下位のグループに区分したとき、選択結果に対応する状況と、過去の野球の試合で問題に対応する状況の後に発生した状況とが一致した数あるいは頻度が所定の閾値以上である場合には、上位のグループの中からユーザのタイプを決定し、当該所定の閾値未満である場合には、下位のグループの中からユーザのタイプを決定してもよい。ここで、例えば、上位のグループには、現実世界におけるいずれかの野球チームの一軍監督に相当するタイプが含まれ、下位のグループには、現実世界におけるいずれかの野球チームの二軍監督に相当するタイプが含まれてもよい。また、例えば、現実世界におけるいずれかの野球チームの監督に相当するタイプが上位のグループに含まれる場合、下位のグループには、監督の条件を満たさないものとして、例えばコーチ、ファン、初心者、あるいは野次馬などに相当するタイプが含まれてもよい。この場合、ユーザは、自身のタイプが上位のグループ内のいずれかのタイプとして決定されるために、過去の野球の試合で実際に発生した状況と一致する選択肢を選択することがもとめられる。このため、ユーザに対して、上位のグループに含まれるタイプになろうとする挑戦意欲あるいは緊張感を喚起することができ、より興趣性のある仕組みとすることができる。

0065

この場合における決定手段54の機能は、例えば以下のように実現される。なお、ここでは、上位のグループには、いずれかの監督に相当するタイプが含まれ、下位のグループには、予め設定されたタイプ(例えば「ファン」、あるいは「初心者」など)が含まれる場合を一例として説明する。また、ここでは、所定の閾値が1である場合を一例として説明する。メインサーバ20のCPU21は、問題の回答としてのいずれかの選択肢を含むHTTPリクエストを取得した場合に、タイプデータベースにアクセスして、HTTPリクエストに含まれる選択肢(選択結果に対応する状況)と、タイプ(監督)に対応付けられている複数の選択肢のうち当該問題のQIDに対応する選択肢(過去の野球の試合で問題に対応する状況の後に発生した状況)との一致数をタイプ毎(監督毎)にもとめる。例えば、当該HTTPリクエストに含まれる選択肢と、監督に対応付けられている選択肢とが同じ場合、一致数(あるいは、一致頻度(割合))は1となる。そして、CPU21は、一致数(あるいは、一致頻度)が所定の閾値(ここでは1)以上の監督をユーザのタイプとして決定する。これにより、上位のグループの中からユーザのタイプが決定される。
一方、CPU21は、一致数(あるいは、一致頻度)が所定の閾値以上の監督が存在しない場合、下位グループに含まれるタイプ(例えば「ファン」、あるいは「初心者」など)をユーザのタイプとして決定する。

0066

通知手段55は、決定手段54によって決定したタイプに関する情報をユーザに通知する機能を備える。ここで、「タイプに関する情報」は、例えば、テキストデータであってもよいし、音声データあるいは画像データであってもよい。
通知手段55の機能は、例えば以下のようにして実現される。メインサーバ20のCPU21は、ユーザのタイプを決定すると、決定したタイプを通知するためのメッセージ(タイプに関する情報;図の例では、「あなたは「SチームのB監督」タイプです!」)などを含むHTMLデータを生成してユーザの通信端末10へ送信する。これによって、ユーザのタイプに関する情報がユーザに通知される。

0067

(1−8)本実施形態の情報処理装置の処理例
次に、本実施形態の情報処理装置により行われる好ましい処理例について、図15を参照して説明する。図15は、ユーザの通信端末10から逐次メインサーバ20へ送信されるHTTPリクエストに対するメインサーバ20の処理を示すフローチャートである。

0068

本実施形態の情報処理システムの好ましいユーザの利用形態は、以下のとおりである。
ユーザは、自らの通信端末10を介して、本実施形態の情報処理装置から、実時間で行われている野球の試合の速報サービスを受けている。前述したように、速報サービスは、野球の試合に関する情報が逐次更新されて通信端末10に提供されるウェブサービスである。この速報サービスでは、状況に応じてユーザに対して問題が出題され、その問題に対する回答を複数の選択肢の中から選択するように構成されている。このとき、ユーザは、速報サービスによって受けている野球の試合の状況を検討し、さらには同時に同じ試合について行われているテレビジョン放送等を視聴することによってより詳細な試合の状況を把握することもできる。

0069

速報サービスでは、各ユーザの通信端末10からメインサーバ20に対して、HTTPリクエストが所定時間おきに(例えば、5〜10秒間隔で)自動的に(つまり、ユーザ操作無しに)送信される。

0070

メインサーバ20のCPU21は、ユーザからHTTPリクエストを受信すると(ステップS10:YES)、速報サービスが終了していない場合には(ステップS20:NO)、いずれかのQIDに対応する問題の回答受付期間内であるか否かを判断する(ステップS30)。ここでCPU21は、現在有効となっているQIDに対応する出題指示メニューが選択操作され、かつ受付終了メニューが選択操作されていない場合には、QIDに対応する問題の回答受付期間内であると判断する。CPU21は、現在有効となっているQIDに対応する受付終了メニューが選択操作された場合には、その問題の回答受付期間内でないと判断する。
CPU21は、回答受付期間内でないと判断した場合には(ステップS30:NO)、オペレータに入力された最新の試合情報(図12の試合記録用画面の入力情報)を基に、実時間の試合のスコアの情報を含むHTMLデータ(図15のHTMLデータ(試合))を生成して(ステップS40)、ユーザの通信端末10へ送信する(ステップS90)。

0071

CPU21は、問題の回答受付期間内であると判断した場合(ステップS30:YES)、ステップS10で受信したHTMLデータに問題の回答(選択肢)が含まれるか否かについて判断する(ステップS50)。CPU21は、ステップS10で受信したHTTPリクエストに問題の回答が含まれていない場合には(ステップS50:NO)、問題とその回答の複数の選択肢を含むHTMLデータ(図15のHTMLデータ(問題))を生成して(ステップS60)、ユーザの通信端末10へ送信する(ステップS90)。問題とその回答の複数の選択肢をHTMLデータに含めるに当たって、CPU21は、有効となっているQIDに対応する問題とその回答の複数の選択肢のテキストを、問題データベースから読み出す。ユーザの通信端末10は、HTMLデータ(問題)を受信すると、例えば図5のP1に示すようにウェブページを表示する。
なお、CPU21は、同一の回答受付期間内においてHTMLデータ(問題)を繰り返し生成する場合、回答を受け付けていることを示すメッセージをHTMLデータ(問題)に含めてもよい。この場合、ユーザの通信端末10は、HTMLデータ(問題)を受信すると、例えば図5のP2に示すようにウェブページを表示する。

0072

CPU21は、ステップS10で受信したHTTPリクエストに問題の回答が含まれる場合(ステップS50:YES)、回答受付処理(ステップS80)を実行する。回答受付処理の内容について具体的に説明すると、CPU21は、先ず、ステップS10で受信したHTTPリクエストに含まれる問題(対象となるQIDに対応する問題)に対する回答(選択肢)を、ユーザIDと対応付けて回答データベースに書き込む。次に、CPU21は、タイプデータベースにアクセスして、当該HTTPリクエストに含まれる回答(選択肢)と同じ選択肢に対応付けられている監督を抽出することによって、ユーザのタイプを決定する。
CPU21は、回答受付処理を実行した後、決定したタイプを通知するメッセージなどを含むHTMLデータ(図15のHTMLデータ(タイプ通知))を生成して(ステップS80)、ユーザの通信端末10へ送信する(ステップS90)。ユーザの通信端末10は、HTMLデータ(タイプ通知)を受信すると、例えば図5のP3に示すようにウェブページを表示する。

0073

以上説明したように、本実施形態の情報処理装置によって、実時間の野球の試合(イベント)内で特定の状況が発生したタイミングにおいて、その特定の状況に関する問題と、その特定の状況の後に発生する状況についての複数の選択肢とがユーザに提示され、ユーザは、いずれかの選択肢を選択するように構成される。例えば、ユーザは、実時間で進行する野球の試合を視聴しながら、その試合の中で特定の状況が生じたときに、その次に発生する状況を予想することになる。このとき、ユーザは、実時間で進行する野球の試合を視聴しながら、例えば試合における様々な状況(例えば、1死3塁等の場面、監督の采配、打者・投手の特性等)を考慮して選択肢を検討するようになるため、その後に生ずる試合の状況に対してより注目するようになり、実時間で進行する野球の試合に自らが参加しているかのような感覚をユーザが感じることができるようになる。
また、本実施形態の情報処理装置では、ユーザがいずれかの選択肢を選択すると、その選択結果に基づいて当該ユーザのタイプを決定して、決定したタイプに関する情報を当該ユーザに通知するように構成されている。この場合、ユーザは、野球の試合中に特定の状況が生じたときに、その次に発生する状況を予想して選択肢を選択することによって、自身のタイプを知ることができる。ここで、ユーザのタイプは、例えば現役あるいは過去の監督別に分類されてもよい。この場合、ユーザは、自身のタイプに関する情報が通知されることにより、野球の試合の特定の状況における自身の予想(すなわち、特定の状況に対する判断や采配など)が、現役あるいは過去の監督のうちどの監督に類似しているのかを知ることができる。このため、ユーザが、例えば試合中の様々な状況において自身の特徴や傾向などを認識することができるという興趣性のある仕組みとすることができる。

0074

(2)第2実施形態
次に、第2実施形態について説明する。第2実施形態の情報処理システムにおいて、通信端末10、メインサーバ20、及びデータベースサーバ30の各構成は、それぞれ図3図4、及び図8に示した構成と同じでもよい。ユーザに速報サービスが提供されている間に、ユーザに問題が出題され、その問題に対する回答としてユーザが決定した選択肢の受付を行う点も第1実施形態と同一である。
本実施形態の情報処理装置では、複数の問題の各々に対する複数の選択結果(選択肢)に基づいてユーザのタイプを決定する点が第1実施形態と異なる。

0075

提示手段52は、実時間の野球の試合(イベント)でいずれかの特定の状況が発生するごとに、前記いずれかの特定の状況に関する問題と、当該問題に対応付けられている複数の選択肢とをユーザに提示する機能を備える。
提示手段52の機能は例えば以下のように実現される。メインサーバ20のCPU21は、出題指示メニュー307bが選択操作されたことを認識すると、それ以降にユーザの通信端末10からHTTPリクエストを受信した場合には、選択された問題と、当該問題に対応する選択肢とを含むHTMLデータを生成してユーザの通信端末10へ送信する。このとき、オペレータが、試合中にいずれかの特定の状況が発生するごとに、当該状況に関する問題の出題指示メニュー307bを選択操作した場合には、ユーザの通信端末10には、いずれかの特定の状況が発生するごとに、問題と、当該問題に対応する選択肢とを含むウェブページが表示される。

0076

決定手段54は、受付手段53によって受け付けた複数の選択結果に基づいてユーザのタイプを決定する機能を備える。この構成によって、実時間の野球の試合(イベント)でいずれかの特定の状況が発生するごとに、ユーザがいずれかの選択肢を選択することによって複数の選択結果が受け付けられるまで、ユーザは自身のタイプを知ることができない。このため、自身のタイプの内容に対するユーザの期待感を高める仕組みとすることができる。
また、決定手段54は、選択結果に対応する状況と、過去の野球の試合(現実世界のイベント)で問題に対応する状況の後に発生した状況とが一致した数あるいは頻度が所定の閾値以上であるか否かに基づいて、前記ユーザのタイプを決定してもよい。

0077

決定手段54の機能は例えば以下のように実現される。メインサーバ20のCPU21は、例えば、速報サービスが終了すると回答データベースを参照して、複数のユーザごとに全ての回答結果(選択肢)を抽出する。次に、CPU21は、タイプデータベースにアクセスして、タイプデータベースに含まれるタイプ(監督)ごとに、対応する選択肢と、ユーザの各問題の回答結果(選択肢)との一致数(つまり、選択結果に対応する状況と、過去の野球の試合で問題に対応する状況の後に発生した状況との一致数)をもとめる。そして、CPU21は、一致数が所定の閾値以上であり、且つ、当該一致数が最大となる監督を、ユーザのタイプとして決定する。
ここで、ユーザのタイプを決定する場合におけるCPU21の処理の一例について、図16を参照して説明する。例えば、複数の監督の各々の選択肢とユーザの回答結果との一致数が図16(a)のように示される場合、CPU21は、一致数が所定の閾値(例えば6)以上となる監督を抽出する。図16(a)の例では、「TチームのC監督」と、「UチームのD監督」が抽出される。次に、CPU21は、一致数が最大となる監督(図の例では、「UチームのD監督」)を、ユーザのタイプとして決定する。
また、例えば、複数の監督の各々の選択肢とユーザの回答結果との一致数が図16(b)のように示される場合、一致数が所定の閾値以上となる監督が存在しないため、CPU21は、例えば、当該所定の閾値以下の第2閾値(例えば5)を用いてユーザのタイプを決定してもよい。具体的には、CPU21は、一致数が第2閾値以上となる監督(図の例では、「VチームのE監督」)が存在する場合には、ユーザのタイプを下位のグループに含まれるタイプ(例えば「ファン」)に決定する。
さらに、例えば、複数の監督の各々の選択肢とユーザの回答結果との一致数が図16(c)のように示される場合、一致数が第2閾値以上となる監督が存在しないため、CPU21は、ユーザのタイプを下位のグループに含まれるタイプ(例えば「初心者」)に決定してもよい。

0078

なお、ここでは、監督の選択肢とユーザの回答結果との一致数と、所定の閾値との大小比較によって、ユーザのタイプを決定する場合を一例として説明したが、この場合に限られない。例えば、一ユーザ当たりの回答数に対する当該一致数の頻度(割合)と、所定の閾値(例えば40%)との大小比較によって、ユーザのタイプを決定してもよい。
また、一致数の平均値を用いてユーザのタイプを決定してもよい。例えば、一致数の平均値をもとめ(図16(a)〜(c)のいずれの場合も、一致数の平均値は3.3(≒20/6)である)、全てのタイプについて、監督の選択肢とユーザの回答結果との一致数が当該平均値の例えば±2の範囲内に存在する場合、ユーザのタイプを例えば「ファン」タイプに決定してもよい。また、全てのタイプについて、監督の選択肢とユーザの回答結果との一致数が当該平均値の例えば±1の範囲内に存在する場合、ユーザのタイプを例えば「初心者」タイプに決定してもよい。さらに、監督の選択肢とユーザの回答結果との一致数が当該平均値の例えば+3以上のタイプが存在する場合、当該タイプ(監督タイプ)をユーザのタイプとして決定してもよい。

0079

(3)第3実施形態
次に、第3実施形態について説明する。第3実施形態の情報処理システムにおいて、通信端末10、メインサーバ20、及びデータベースサーバ30の各構成は、それぞれ図3図4、及び図8に示した構成と同じでもよい。ユーザに速報サービスが提供されている間に、ユーザに問題が出題され、その問題に対する回答としてユーザが決定した選択肢の受付を行う点も第1実施形態と同一である。
本実施形態の情報処理装置では、図17に示す機能ブロック図において、関係付け手段56と、付与手段57とを備えた点が第1実施形態と異なる。

0080

関係付け手段56は、ユーザ同士を関係付ける機能を備える。つまり、関係付け手段56は、例えばユーザIDに基づく申請を契機として、当該ユーザIDを他のユーザIDとを関連付けて記録する。すなわち、関係付け手段56は、ユーザIDに基づく申請を契機として、他のユーザID(つまり、他のユーザ)を「仲間」として記録する。

0081

関係付け手段56の機能は例えば、以下のように実現される。メインサーバ20のCPU21は、通信インタフェース部25を介して、あるユーザIDに対応するユーザの通信端末10から、仲間になりたいユーザID(あるいは、対応するユーザ名)を指定した申請メッセージ仲間申請)を受け付ける。この申請メッセージの送信は、ユーザの通信端末10に提供されるウェブページの機能として予め設定されてもよい。
CPU21は、申請メッセージを受け付けると、申請メッセージに含まれるユーザIDに基づくアクセスがあったタイミングで、そのユーザIDに対応する通信端末10へ、他のユーザIDに基づく申請を承認するか否かを返信することを要求するウェブページを表示するためのHTMLデータを送信する。その申請を承認することが返信されれば、CPU21は、両者を仲間として登録する。具体的には、CPU21は、ユーザデータベース31内の対応する2つのユーザIDのユーザデータにデータ(相手のユーザID)を書き込む。なお、CPU21は、仲間申請先のユーザの承認を不要とする場合は、ユーザによる所定の操作を契機として、両者を仲間として登録してもよい。

0082

なお、ユーザ同士を関係付ける条件は、上記のような申請と承認を必要とする形式に限られない。例えば、メインサーバ20がゲーミングサービスを提供するサーバとしても機能する場合、ユーザと協働してゲームを実行した他のユーザ、例えば、ゲーム上の同一のステージエリアなどを実行する他のユーザや、バトルを行った他のユーザなどを、ユーザとゲーム内で関係付けられた他のユーザ、つまり仲間として登録してもよい。あるいは、所定回数挨拶メッセージを送信するユーザ同士を自動的に仲間として登録してもよいし、ユーザ間でバトルを行うゲーム上のモードが存在する場合には、所定回数以上バトルを行ったユーザ同士を自動的に仲間として登録してもよい。

0083

付与手段57は、同じタイプに決定されたユーザ同士が関係付けられた場合、あるいは互いに関係付けられたユーザの各々が同じタイプに決定された場合に、各ユーザの少なくともいずれかに対して特典を付与する機能を備える。
特典の内容は特に限定するものではないが、上記速報サービスがソーシャルゲーム等のサービスとして組み込まれている場合には、付与手段57によって得られる特典は、ゲームで利用可能なオブジェクト(例えば、ゲームキャラクタや、ゲームキャラクタが表示されるカード等)、アイテム、各種ポイント等であってもよい。これにより、ユーザにとってみれば、速報サービスで得られた特典を直ちにソーシャルゲームで利用することができるため、上記速報サービスとソーシャルゲームとを連携させることができる。

0084

付与手段57の機能は例えば以下のように実現される。
先ず、同じタイプに決定されたユーザ同士が関係付けられたときに各ユーザの少なくともいずれかに対して特典が付与される場合の一例を説明する。メインサーバ20のCPU21は、関係付け手段56の機能に基づいてユーザ同士が関係付けられると、回答データベースにアクセスして、各ユーザの回答結果を抽出する。次に、CPU21は、タイプデータベースにアクセスして、各ユーザの回答結果を用いて各ユーザのタイプを決定する。そして、CPU21は、各ユーザのタイプが同じである場合、各ユーザに対して特典を付与することを決定する。CPU21は、各ユーザに対して特典を付与することを決定すると、ユーザデータベース31にアクセスして、各ユーザに対応付けて特典の内容を記録する。例えば、特典がゲーム上で利用可能なポイントである場合、所定量のポイント(例えば1000ポイント)だけ加算するように特典の内容が記録される。

0085

次に、互いに関係付けられたユーザの各々が同じタイプに決定されたときに各ユーザの少なくともいずれかに対して特典が付与される場合の一例を説明する。メインサーバ20のCPU21は、例えば図15のフローのステップS70の処理においてユーザのタイプを決定すると、ユーザデータベース31にアクセスして、当該ユーザと関係付けられたユーザ(仲間)のユーザIDを抽出する。次に、CPU21は、回答データベースにアクセスして、仲間のユーザIDごとに回答結果を抽出して、仲間のタイプを決定する。そして、CPU21は、ユーザのタイプと仲間のタイプとが一致する場合、ユーザ及び仲間に対して特典を付与することを決定する。CPU21は、各ユーザに対して特典を付与することを決定すると、ユーザデータベース31にアクセスして、各ユーザに対応付けて特典の内容を記録する。
なお、特典の付与対象となるユーザは、互いに関係付けられた各ユーザのいずれか一方であってもよい。

0086

また、本実施形態において、通知手段55は、同じタイプに決定されたユーザ同士が関係付けられた場合、あるいは互いに関係付けられたユーザの各々が同じタイプに決定された場合に、各ユーザが同じタイプであることを示す情報を各ユーザに通知する機能を備えてもよい。この場合、各ユーザは、新たに関係付けられた(仲間になった)ユーザ、あるいは既に関係付けられている仲間のユーザが同じタイプであることを認識することができるので、特典を得ることを容易に想定することができる。
この場合、CPU21は、付与手段57の機能に基づいて、ユーザに対して特典を付与すると、互いに関係付けられた各ユーザが同じタイプであることを示す情報(例えば「仲間になった(あるいは、仲間の)Aさんは、あなたと同じタイプのユーザです。」など)を含むHTMLデータを生成して、各ユーザの通信端末10に送信する。なお、当該情報は、テキストデータで構成されていてもよいし、音声データあるいは画像データで構成されていてもよい。

0087

本実施形態の情報処理装置によれば、例えば、同じタイプに決定されたユーザ同士が関係付けられた(仲間になった)ときに各ユーザの少なくともいずれかに対して特典が付与される場合には、ユーザは、特典を得るために、自身と同じタイプの他のユーザと仲間になることが動機付けられる。また、例えば、互いに関係付けられたユーザの各々が同じタイプに決定されたときに各ユーザの少なくともいずれかに対して特典が付与される場合には、ユーザが特典を得ることによって、同じタイプの他のユーザ(仲間)に対する当該ユーザの親近感を増す仕組みとすることができる。これにより、本構成によれば、ユーザ同士の交流を促進させることができるので、ソーシャル性を向上させることができる。

0088

(4)第4実施形態
次に、第4実施形態について説明する。第3実施形態の情報処理システムにおいて、通信端末10、メインサーバ20、及びデータベースサーバ30の各構成は、それぞれ図3図4、及び図8に示した構成と同じでもよい。ユーザに速報サービスが提供されている間に、ユーザに問題が出題され、その問題に対する回答としてユーザが決定した選択肢の受付を行う点も第1実施形態と同一である。
本実施形態の情報処理装置では、図18に示す機能ブロック図において、関係付け手段56と、調整手段58とを備えた点が第1実施形態と異なる。なお、関係付け手段56の機能及び実現例は、第3実施形態で説明したものと同一である。

0089

調整手段58は、同じタイプに決定されたユーザ同士が関係付けられた場合、あるいは互いに関係付けられたユーザの各々が同じタイプに決定された場合に、各ユーザ間の関係の程度を示す親密度を高めるように調整する機能を備える。
ここで、親密度とは、仲間のユーザ間の関係性の高さを一定の基準で数値化したものである。親密度のデータ(親密度データ)の一例を図19に示す。図19に示す親密度データの例では、各ユーザの仲間のユーザ(ユーザID)と対応付けて、ユーザ間のメッセージの送信あるいは受信の頻度(通信頻度)、例えばゲーム上で使用可能なアイテムなどのプレゼントを送信あるいは受信した回数(プレゼント回数)などが記録され、これらの頻度や回数に基づいて一定の基準で親密度の値が設定される。通信頻度やプレゼント回数が多いほど親密度が高く設定される。また、一定の基準では、親密度の設定の基礎となる項目(図19では、通信頻度やプレゼント回数など)ごとに、重み付けを考慮したものであってもよい。例えば、通信頻度が少なくてもプレゼント回数が多い場合に親密度を高く設定してもよい。このような親密度データは、例えば、ユーザデータベース31内に記録される。
また、調整手段58は、情報処理装置が例えばソーシャルゲームなどのゲーミングサービスを提供する場合、ユーザ間の親密度が高くなるほど、各ユーザが協力してゲームをプレイする際に当該ゲームの進行が有利になるように調整してもよい。例えば、ユーザがゲーム上のバトルを実行する場合、当該ユーザと協力してバトルを行う仲間との親密度が高いほど、ユーザが当該バトルに勝利する確率が高くなるように調整してもよい。

0090

調整手段58の機能は、例えば以下のように実現される。
先ず、同じタイプに決定されたユーザ同士が関係付けられたときに親密度を高めるように調整する場合の一例を説明する。メインサーバ20のCPU21は、関係付け手段56の機能に基づいてユーザ同士が関係付けられると、回答データベースにアクセスして、各ユーザの回答結果を抽出する。次に、CPU21は、タイプデータベースにアクセスして、各ユーザの回答結果を用いて各ユーザのタイプを決定する。そして、CPU21は、各ユーザのタイプが同じである場合、ユーザデータベース31内の親密度データにアクセスして、各ユーザ間の親密度を所定値(例えば1)だけ加算する。

0091

次に、互いに関係付けられたユーザの各々が同じタイプに決定されたときに親密度を高めるように調整する場合の一例を説明する。メインサーバ20のCPU21は、例えば図15のフローのステップS70の処理においてユーザのタイプを決定すると、ユーザデータベース31にアクセスして、当該ユーザと関係付けられたユーザ(仲間)のユーザIDを抽出する。次に、CPU21は、回答データベースにアクセスして、仲間のユーザIDごとに回答結果を抽出して、仲間のタイプを決定する。そして、CPU21は、ユーザのタイプと仲間のタイプとが一致する場合、ユーザデータベース31内の親密度データにアクセスして、各ユーザ間の親密度を所定値(例えば1)だけ加算する。

0092

また、本実施形態において、通知手段55は、同じタイプに決定されたユーザ同士が関係付けられた場合、あるいは互いに関係付けられたユーザの各々が同じタイプに決定された場合に、各ユーザが同じタイプであることを示す情報を各ユーザに通知する機能を備えてもよい。この場合、各ユーザは、新たに関係付けられた(仲間になった)ユーザ、あるいは既に関係付けられている仲間のユーザが同じタイプであることを認識することができるので、親密度が高くなることを容易に想定することができる。
この場合、CPU21は、調整手段57の機能に基づいて、各ユーザの親密度を高めるように調整すると、互いに関係付けられた各ユーザが同じタイプであることを示す情報(例えば「仲間になった(あるいは、仲間の)Aさんは、あなたと同じタイプのユーザです。」など)を含むHTMLデータを生成して、各ユーザの通信端末10に送信する。なお、当該情報は、テキストデータで構成されていてもよいし、音声データあるいは画像データで構成されていてもよい。

0093

本実施形態の情報処理装置によれば、例えば、同じタイプに決定されたユーザ同士が関係付けられた(仲間になった)ときに各ユーザ間の親密度が高くなる場合には、ユーザは、自身と同じタイプであることを契機として、当該タイプの他のユーザと仲間になることが動機付けられる。また、例えば、互いに関係付けられたユーザの各々が同じタイプに決定されたときに各ユーザ間の親密度が高くなる場合には、親密度が高くなったことを契機として、各ユーザ間の交流を促進させる仕組みとすることができる。これにより、ソーシャル性を向上させることができる。

0094

以上、本発明の各実施形態について詳細に説明したが、本発明は各実施形態に限定されない。また、各実施形態は、本発明の主旨を逸脱しない範囲において、種々の改良や変更をしてもよいのは勿論である。各実施形態の構成及び特徴は、適宜組み合わせてもよい。例えば、第2実施形態の情報処理装置の一構成要素である付与手段57(図17)は、第3実施形態の情報処理装置に備わっていてもよい。

0095

上述した実施形態では、本発明のイベントが野球の試合である場合を例として説明したが、イベントはこれに限られない。イベントは、将棋、チェス等の対局であってもよく、そのジャンルは問わない。
また、イベントは、テレビジョン放送、ラジオ放送あるいはインターネット放送等、公営あるいは民営のメディアを通じて提供されるものであってもよいし、所定の会場で観戦するものであってもよい。

0096

上述した実施形態では、出題時刻や回答の受付終了時刻がオペレータの入力によって設定される場合について説明したが、このような場合に限られない。検出装置によって自動的に検出可能な所定の状況を含むイベントの場合には、検出装置による検出結果を情報処理装置に自動的に入力するような構成を採ることが可能であるため、オペレータの入力は必要ない。そのようなイベントとしては例えば、ボウリングの試合等が挙げられる。ボウリングの試合では、点数の算出や投球タイミングがシステムによって自動化されているため、このようなシステムと連携することで、ボウリングにおける所定の状況を示す信号を情報処理装置へ取り込むことは当業者が適宜実施可能である。

0097

上述した実施形態では、ユーザによる通信端末10に対する所定の操作入力は、ユーザの通信端末10に対する所定の操作釦の押下操作の入力や、タッチパネル機能を備えた通信端末10に対する表示画面上のタッチ操作の入力であるとしたが、操作入力はこれに限られない。操作入力は、加速度センサを備えた通信端末10を振ることによる操作入力、あるいはジェスチャによる操作入力(ジェスチャ入力)であってもよい。ジェスチャ入力では、撮像機能を備えた通信端末10に対する所定のジェスチャを行うことで通信端末10がそのジェスチャを画像認識し、予めジェスチャに対応付けられた操作入力を認識する。また、音声認識プログラムを実行可能な通信端末10の場合には、操作入力は、音声を入力することにより行われてもよい。

0098

上述した実施形態では、ネットワーク上のメインサーバ20及びデータベースサーバ30によって、図14に示した各手段の機能を実現する構成としたが、この構成に限られない。少なくとも一部の手段を通信端末10によって実現する構成としてもよい。例えば、決定手段54を実現するために、ユーザの通信端末10は、ユーザの選択した選択肢を問題毎にRAM13等に記憶しておき、タイプデータベース上の複数のタイプごとの選択肢をメインサーバ20から受信して取得することによって、通信端末10のCPU11がユーザのタイプを決定するようにしてもよい。

0099

10…通信端末
11…CPU
12…ROM
13…RAM
14…画像処理部
15…指示入力部
16…表示部
17…通信インタフェース部
18…バス
20…メインサーバ
21…CPU
22…ROM
23…RAM
24…データベースアクセス部
25…通信インタフェース部
26…入力部
27…表示部
28…バス
30…データベースサーバ
31…ユーザデータベース
32…試合記録データベース
33…出題運営データベース
51…記憶手段
52…提示手段
53…受付手段
54…決定手段
55…通知手段
56…関係付け手段
57…付与手段
58…調整手段

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

関連する公募課題

該当するデータがありません

ページトップへ

技術視点だけで見ていませんか?

この技術の活用可能性がある分野

分野別動向を把握したい方- 事業化視点で見る -

(分野番号表示ON)※整理標準化データをもとに当社作成

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

新着 最近 公開された関連が強い技術

この 技術と関連性が強い技術

関連性が強い 技術一覧

この 技術と関連性が強い人物

関連性が強い人物一覧

この 技術と関連する社会課題

関連する挑戦したい社会課題一覧

この 技術と関連する公募課題

該当するデータがありません

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ