特許 5718878 情報処理装置、プログラム、情報処理システム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】5718878

(24)【登録日】2015年3月27日

(45)【発行日】2015年5月13日

(54)【発明の名称】情報処理装置、プログラム、情報処理システム

(51)【国際特許分類】

   A63F 13/79 20140101AFI20150423BHJP

   A63F 13/69 20140101ALI20150423BHJP

   A63F 13/80 20140101ALI20150423BHJP

   A63F 13/35 20140101ALI20150423BHJP

   A63F 13/812 20140101ALI20150423BHJP

【ＦＩ】

   A63F13/79 500

   A63F13/69 500

   A63F13/80 D

   A63F13/35

   A63F13/812 A

【請求項の数】9

【全頁数】32

(21)【出願番号】特願2012-236205(P2012-236205)

(22)【出願日】2012年10月26日

(65)【公開番号】特開2014-83340(P2014-83340A)

(43)【公開日】2014年5月12日

【審査請求日】2013年12月18日

(73)【特許権者】

【識別番号】506113602

【氏名又は名称】株式会社コナミデジタルエンタテインメント

(74)【代理人】

【識別番号】110000165

【氏名又は名称】グローバル・アイピー東京特許業務法人

(72)【発明者】

【氏名】五島 章

(72)【発明者】

【氏名】千手 昭彦

(72)【発明者】

【氏名】松村 謙

【審査官】 柴田 和雄

(56)【参考文献】

【文献】 特開２０００−３３９３８７（ＪＰ，Ａ）

【文献】 特開２００１−２１２３７１（ＪＰ，Ａ）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ａ６３Ｆ １３／００ − １３／９８

Ａ６３Ｆ ９／２４

(57)【特許請求の範囲】

【請求項1】

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

【請求項2】

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

【請求項3】

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

【請求項4】

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

【請求項5】

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

【請求項6】

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

【請求項7】

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

【請求項8】

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

【請求項9】

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

【発明の詳細な説明】

【技術分野】

【0001】

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

【背景技術】

【0002】

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

【先行技術文献】

【特許文献】

【0003】

【特許文献1】特開２００３−０００９５４号公報

【発明の概要】

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

【0004】

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

【0005】

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

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

【0006】

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

【0007】

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

【0008】

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

【0009】

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

【0010】

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

【0011】

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

【0012】

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

【0013】

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

【0014】

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

【0015】

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

【0016】

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

【0017】

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

【0018】

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

【0019】

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

【発明の効果】

【0020】

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

【図面の簡単な説明】

【0021】

【図1】第１実施形態の情報処理システムの基本構成を示す図。

【図2】第１実施形態の通信端末の外観の例を示す図。

【図3】第１実施形態の通信端末の構成を示すブロック図。

【図4】第１実施形態のメインサーバの構成を示すブロック図。

【図5】ユーザの通信端末に表示される一連のウェブページとその表示タイミングの例を、実時間で進行する野球の試合と対応付けて示す図。

【図6】ユーザの通信端末に表示されるウェブページの例を示す図。

【図7】ユーザの通信端末に表示される一連のウェブページとその表示タイミングの例を、実時間で進行する野球の試合と対応付けて示す図。

【図8】第１実施形態のデータベースサーバの構成を示すブロック図。

【図9】問題データベースの構成例を示す図。

【図10】回答データベースの構成例を示す図。

【図11】タイプデータベースの構成例を示す図。

【図12】試合運営プログラムを実行しているときにメインサーバに表示される入力用画面の例を示す図。

【図13】試合運営プログラムを実行しているときにメインサーバに表示される入力用画面の例を示す図。

【図14】第１実施形態の情報処理装置の機能ブロック図。

【図15】第１実施形態の情報処理装置の処理を示すフローチャート。

【図16】（ａ）〜（ｃ）は、第２実施形態において、複数のタイプの各々に対応する選択肢の選択回数の一例を示す図。

【図17】第３実施形態の情報処理装置の機能ブロック図。

【図18】第４実施形態の情報処理装置の機能ブロック図。

【図19】親密度データの構成例を示す図。

【発明を実施するための形態】

【0022】

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

【0023】

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

【0024】

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

【0025】

（１−２）通信端末の構成
図２及び図３を参照して通信端末１０について説明する。
図２は、通信端末１０の外観の例を示す図であって、（ａ）は、例えば折り畳み式の携帯端末（携帯電話機）などの釦入力方式の通信端末を例示したものであり、（ｂ）は、例えばスマートフォンなどのタッチパネル入力方式の通信端末を例示したものである。図３は、通信端末１０の内部構成を示すブロック図である。
図３に示すように、通信端末１０は、ＣＰＵ（Central Processing Unit）１１、ＲＯＭ(Read Only Memory)１２、ＲＡＭ(Random Access Memory)１３、画像処理部１４、指示入力部１５、表示部１６、及び、信号送受信部としての通信インタフェース部１７を備えており、各部間の制御信号あるいはデータ信号を伝送するためのバス１８が設けられている。

【0026】

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

【0027】

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

【0028】

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

【0029】

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

【0030】

通信端末１０がタッチパネル入力方式の通信端末（図２（ｂ））である場合、指示入力部１５は、主として表示画面１６ａに指先あるいはペンで触れることによるタッチパネル方式の入力を受け付ける。タッチパネル入力方式は、静電容量方式などの公知の方式でよい。なお、図２（ｂ）に示すように、通信端末１０がタッチパネル入力方式の場合であっても釦群１５ａが設けられる場合もある。

【0031】

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

【0032】

（１−３）メインサーバの構成
図４を参照してメインサーバ２０の構成について説明する。
メインサーバ２０は、クライアントである通信端末１０に対してウェブサービスを提供する。図４に示すように、メインサーバ２０は、ＣＰＵ２１、ＲＯＭ２２、ＲＡＭ２３、データベース（ＤＢ）アクセス部２４、通信インタフェース部２５、入力部２６、及び、表示部２７を備えており、各部間の制御信号あるいはデータ信号を伝送するためのバス２８が設けられている。なお、メインサーバ２０は、ハードウエアに関しては汎用のウェブサーバと同一の構成をとることができる。

【0033】

ＲＯＭ２２には、クライアントである通信端末１０のウェブブラウザに対してＨＴＭＬ文書や画像などのオブジェクトの表示（ウェブページの表示）のサービスを提供するプログラムや試合運営プログラム（後述する）が格納されている。ＲＯＭ２２には、プログラム以外にもＣＰＵ２１によって参照される各種データが格納されている。
ＣＰＵ２１は、ＲＯＭ２２内のプログラムをＲＡＭ２３にロードして実行し、通信インタフェース部２５を介して、各種の処理を行う。

【0034】

例えば、ＣＰＵ２１は、通信インタフェース部２５を介して、メインサーバ２０のウェブブラウザとの間でＨＴＴＰに従った通信を行う。例えば、ＣＰＵ２１は、通信インタフェース部２５を介して、通信端末１０から受信したＨＴＴＰリクエスト（例えば、ウェブページ上でのユーザのハイパーリンクまたはメニューの選択結果を含む。）に基づいて所定のデータ処理や、演算処理を行い、その処理結果を含むＨＴＴＰレスポンスをメインサーバ２０のウェブブラウザに返す。ＨＴＴＰレスポンスには、ウェブページを更新するためのＨＴＭＬデータが含まれる。また、メインサーバ２０が通信端末１０のユーザの認証処理を行う場合には、ＣＰＵ２１はその認証処理を行う。
データベースアクセス部２４は、ＣＰＵ２１がデータベースサーバ３０に対してデータの読み書きを行うときのインタフェースである。
入力部２６は、例えばキーボード及び／又はマウス等の入力装置と、その入力装置によって入力されるデータをメインサーバ２０内で認識させるためのインタフェース回路とを含む。表示部２７は、ＣＰＵ２１によって実行されるプログラムの実行結果（出力結果）を表示するためのものであって、例えば前述したＬＣＤモニタを含んでもよい。

【0035】

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

【0036】

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

【0037】

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

【0038】

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

【0039】

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

【0040】

図５は、速報サービスによってユーザの通信端末に表示される一連のウェブページとその表示タイミングの例を、実時間で進行する野球の試合と対応付けて示す図である。この例では、回答受付期間が概ね、特定のイニングの表と裏の間の期間に設定されている。図５において、ウェブページＰ１は、速報サービスにおいて問題（この場合、「第２問」）の出題が行われた場合の例を示しており、表示領域１０１，１０２を含む。
問題の出題が行われていない場合のウェブページは図示しないが、少なくともスコアを表示する表示領域１０２を含み、さらに試合についてのより詳細な情報を表示してもよい。このような速報サービスの提供は、ユーザの通信端末１０から速報サービスのＵＲＬを指定したＨＴＴＰリクエストをメインサーバ２０へ送信することによって開始される。
ウェブページＰ１に示す表示領域１０１には、上述した問題と当該問題についての選択肢Ａ〜Ｃが表示されている。表示領域１０２には、現在のチームＰとチームＱの試合のスコアが表示される。

【0041】

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

【0042】

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

【0043】

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

【0044】

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

【0045】

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

【0046】

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

【0047】

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

【0048】

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

【0049】

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

【0050】

回答データベースは、野球の試合において出題された問題に対して各ユーザから受け付けた回答（いずれかの選択肢）が記述されているデータベースである。図１０に示す回答データベースの例では、各問題（ＱＩＤ：３，８，１４，…）に対して、ユーザＩＤに対応付けられた選択肢（Ａ，Ｂ，Ｃ，等）が記録される。

【0051】

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

【0052】

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

【0053】

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

【0054】

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

【0055】

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

【0056】

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

【0057】

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

【0058】

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

【0059】

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

【0060】

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

【0061】

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

【0062】

受付手段５３の機能は以下のようにして実現される。オペレータにより有効となっているＱＩＤに対応する出題指示メニュー３０７ｂが選択操作された後、受付終了メニュー３０７ｃが選択操作されるまでの期間、つまり回答受付期間内において、メインサーバ２０のＣＰＵ２１は、ユーザの通信端末１０から、問題の回答としてのいずれかの選択肢を含むＨＴＴＰリクエストを取得した場合には、その選択肢をユーザＩＤとＱＩＤに対応付けて回答データベースに書き込む。回答データベースへの書き込み処理は、ユーザの選択結果（選択肢）を受け付けたことに相当する。

【0063】

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

【0064】

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

【0065】

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

【0066】

通知手段５５は、決定手段５４によって決定したタイプに関する情報をユーザに通知する機能を備える。ここで、「タイプに関する情報」は、例えば、テキストデータであってもよいし、音声データあるいは画像データであってもよい。
通知手段５５の機能は、例えば以下のようにして実現される。メインサーバ２０のＣＰＵ２１は、ユーザのタイプを決定すると、決定したタイプを通知するためのメッセージ（タイプに関する情報；図の例では、「あなたは「ＳチームのＢ監督」タイプです！」）などを含むＨＴＭＬデータを生成してユーザの通信端末１０へ送信する。これによって、ユーザのタイプに関する情報がユーザに通知される。

【0067】

（１−８）本実施形態の情報処理装置の処理例
次に、本実施形態の情報処理装置により行われる好ましい処理例について、図１５を参照して説明する。図１５は、ユーザの通信端末１０から逐次メインサーバ２０へ送信されるＨＴＴＰリクエストに対するメインサーバ２０の処理を示すフローチャートである。

【0068】

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

【0069】

速報サービスでは、各ユーザの通信端末１０からメインサーバ２０に対して、ＨＴＴＰリクエストが所定時間おきに（例えば、５〜１０秒間隔で）自動的に（つまり、ユーザ操作無しに）送信される。

【0070】

メインサーバ２０のＣＰＵ２１は、ユーザからＨＴＴＰリクエストを受信すると（ステップＳ１０：ＹＥＳ）、速報サービスが終了していない場合には（ステップＳ２０：ＮＯ）、いずれかのＱＩＤに対応する問題の回答受付期間内であるか否かを判断する（ステップＳ３０）。ここでＣＰＵ２１は、現在有効となっているＱＩＤに対応する出題指示メニューが選択操作され、かつ受付終了メニューが選択操作されていない場合には、ＱＩＤに対応する問題の回答受付期間内であると判断する。ＣＰＵ２１は、現在有効となっているＱＩＤに対応する受付終了メニューが選択操作された場合には、その問題の回答受付期間内でないと判断する。
ＣＰＵ２１は、回答受付期間内でないと判断した場合には（ステップＳ３０：ＮＯ）、オペレータに入力された最新の試合情報（図１２の試合記録用画面の入力情報）を基に、実時間の試合のスコアの情報を含むＨＴＭＬデータ（図１５のＨＴＭＬデータ（試合））を生成して（ステップＳ４０）、ユーザの通信端末１０へ送信する（ステップＳ９０）。

【0071】

ＣＰＵ２１は、問題の回答受付期間内であると判断した場合（ステップＳ３０：ＹＥＳ）、ステップＳ１０で受信したＨＴＭＬデータに問題の回答（選択肢）が含まれるか否かについて判断する（ステップＳ５０）。ＣＰＵ２１は、ステップＳ１０で受信したＨＴＴＰリクエストに問題の回答が含まれていない場合には（ステップＳ５０：ＮＯ）、問題とその回答の複数の選択肢を含むＨＴＭＬデータ（図１５のＨＴＭＬデータ（問題））を生成して（ステップＳ６０）、ユーザの通信端末１０へ送信する（ステップＳ９０）。問題とその回答の複数の選択肢をＨＴＭＬデータに含めるに当たって、ＣＰＵ２１は、有効となっているＱＩＤに対応する問題とその回答の複数の選択肢のテキストを、問題データベースから読み出す。ユーザの通信端末１０は、ＨＴＭＬデータ（問題）を受信すると、例えば図５のＰ１に示すようにウェブページを表示する。
なお、ＣＰＵ２１は、同一の回答受付期間内においてＨＴＭＬデータ（問題）を繰り返し生成する場合、回答を受け付けていることを示すメッセージをＨＴＭＬデータ（問題）に含めてもよい。この場合、ユーザの通信端末１０は、ＨＴＭＬデータ（問題）を受信すると、例えば図５のＰ２に示すようにウェブページを表示する。

【0072】

ＣＰＵ２１は、ステップＳ１０で受信したＨＴＴＰリクエストに問題の回答が含まれる場合（ステップＳ５０：ＹＥＳ）、回答受付処理（ステップＳ８０）を実行する。回答受付処理の内容について具体的に説明すると、ＣＰＵ２１は、先ず、ステップＳ１０で受信したＨＴＴＰリクエストに含まれる問題（対象となるＱＩＤに対応する問題）に対する回答（選択肢）を、ユーザＩＤと対応付けて回答データベースに書き込む。次に、ＣＰＵ２１は、タイプデータベースにアクセスして、当該ＨＴＴＰリクエストに含まれる回答（選択肢）と同じ選択肢に対応付けられている監督を抽出することによって、ユーザのタイプを決定する。
ＣＰＵ２１は、回答受付処理を実行した後、決定したタイプを通知するメッセージなどを含むＨＴＭＬデータ（図１５のＨＴＭＬデータ（タイプ通知））を生成して（ステップＳ８０）、ユーザの通信端末１０へ送信する（ステップＳ９０）。ユーザの通信端末１０は、ＨＴＭＬデータ（タイプ通知）を受信すると、例えば図５のＰ３に示すようにウェブページを表示する。

【0073】

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

【0074】

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

【0075】

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

【0076】

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

【0077】

決定手段５４の機能は例えば以下のように実現される。メインサーバ２０のＣＰＵ２１は、例えば、速報サービスが終了すると回答データベースを参照して、複数のユーザごとに全ての回答結果（選択肢）を抽出する。次に、ＣＰＵ２１は、タイプデータベースにアクセスして、タイプデータベースに含まれるタイプ（監督）ごとに、対応する選択肢と、ユーザの各問題の回答結果（選択肢）との一致数（つまり、選択結果に対応する状況と、過去の野球の試合で問題に対応する状況の後に発生した状況との一致数）をもとめる。そして、ＣＰＵ２１は、一致数が所定の閾値以上であり、且つ、当該一致数が最大となる監督を、ユーザのタイプとして決定する。
ここで、ユーザのタイプを決定する場合におけるＣＰＵ２１の処理の一例について、図１６を参照して説明する。例えば、複数の監督の各々の選択肢とユーザの回答結果との一致数が図１６（ａ）のように示される場合、ＣＰＵ２１は、一致数が所定の閾値（例えば６）以上となる監督を抽出する。図１６（ａ）の例では、「ＴチームのＣ監督」と、「ＵチームのＤ監督」が抽出される。次に、ＣＰＵ２１は、一致数が最大となる監督（図の例では、「ＵチームのＤ監督」）を、ユーザのタイプとして決定する。
また、例えば、複数の監督の各々の選択肢とユーザの回答結果との一致数が図１６（ｂ）のように示される場合、一致数が所定の閾値以上となる監督が存在しないため、ＣＰＵ２１は、例えば、当該所定の閾値以下の第２閾値（例えば５）を用いてユーザのタイプを決定してもよい。具体的には、ＣＰＵ２１は、一致数が第２閾値以上となる監督（図の例では、「ＶチームのＥ監督」）が存在する場合には、ユーザのタイプを下位のグループに含まれるタイプ（例えば「ファン」）に決定する。
さらに、例えば、複数の監督の各々の選択肢とユーザの回答結果との一致数が図１６（ｃ）のように示される場合、一致数が第２閾値以上となる監督が存在しないため、ＣＰＵ２１は、ユーザのタイプを下位のグループに含まれるタイプ（例えば「初心者」）に決定してもよい。

【0078】

なお、ここでは、監督の選択肢とユーザの回答結果との一致数と、所定の閾値との大小比較によって、ユーザのタイプを決定する場合を一例として説明したが、この場合に限られない。例えば、一ユーザ当たりの回答数に対する当該一致数の頻度（割合）と、所定の閾値（例えば４０％）との大小比較によって、ユーザのタイプを決定してもよい。
また、一致数の平均値を用いてユーザのタイプを決定してもよい。例えば、一致数の平均値をもとめ（図１６（ａ）〜（ｃ）のいずれの場合も、一致数の平均値は３．３（≒２０／６）である）、全てのタイプについて、監督の選択肢とユーザの回答結果との一致数が当該平均値の例えば±２の範囲内に存在する場合、ユーザのタイプを例えば「ファン」タイプに決定してもよい。また、全てのタイプについて、監督の選択肢とユーザの回答結果との一致数が当該平均値の例えば±１の範囲内に存在する場合、ユーザのタイプを例えば「初心者」タイプに決定してもよい。さらに、監督の選択肢とユーザの回答結果との一致数が当該平均値の例えば＋３以上のタイプが存在する場合、当該タイプ（監督タイプ）をユーザのタイプとして決定してもよい。

【0079】

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

【0080】

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

【0081】

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

【0082】

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

【0083】

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

【0084】

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

【0085】

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

【0086】

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

【0087】

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

【0088】

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

【0089】

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

【0090】

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

【0091】

次に、互いに関係付けられたユーザの各々が同じタイプに決定されたときに親密度を高めるように調整する場合の一例を説明する。メインサーバ２０のＣＰＵ２１は、例えば図１５のフローのステップＳ７０の処理においてユーザのタイプを決定すると、ユーザデータベース３１にアクセスして、当該ユーザと関係付けられたユーザ（仲間）のユーザＩＤを抽出する。次に、ＣＰＵ２１は、回答データベースにアクセスして、仲間のユーザＩＤごとに回答結果を抽出して、仲間のタイプを決定する。そして、ＣＰＵ２１は、ユーザのタイプと仲間のタイプとが一致する場合、ユーザデータベース３１内の親密度データにアクセスして、各ユーザ間の親密度を所定値（例えば１）だけ加算する。

【0092】

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

【0093】

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

【0094】

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

【0095】

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

【0096】

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

【0097】

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

【0098】

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

【符号の説明】

【0099】

１０…通信端末
１１…ＣＰＵ
１２…ＲＯＭ
１３…ＲＡＭ
１４…画像処理部
１５…指示入力部
１６…表示部
１７…通信インタフェース部
１８…バス
２０…メインサーバ
２１…ＣＰＵ
２２…ＲＯＭ
２３…ＲＡＭ
２４…データベースアクセス部
２５…通信インタフェース部
２６…入力部
２７…表示部
２８…バス
３０…データベースサーバ
３１…ユーザデータベース
３２…試合記録データベース
３３…出題運営データベース
５１…記憶手段
５２…提示手段
５３…受付手段
５４…決定手段
５５…通知手段
５６…関係付け手段
５７…付与手段
５８…調整手段

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】