知財求人 - 知財ポータルサイト「IP Force」
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2023-04-06
(45)【発行日】2023-04-14
(54)【発明の名称】投票集計装置及びプログラム
(51)【国際特許分類】
G06F 16/35 20190101AFI20230407BHJP
H04N 17/00 20060101ALI20230407BHJP
【ＦＩ】
G06F16/35
H04N17/00 Z
【請求項の数】
5
(21)【出願番号】P 2019047281
(22)【出願日】2019-03-14
(65)【公開番号】P2020149456
(43)【公開日】2020-09-17
【審査請求日】2022-02-14
(73)【特許権者】
【識別番号】000004352
【氏名又は名称】日本放送協会
(74)【代理人】
【識別番号】100141139
【弁理士】
【氏名又は名称】及川 周
(74)【代理人】
【識別番号】100171446
【弁理士】
【氏名又は名称】高田 尚幸
(74)【代理人】
【識別番号】100114937
【弁理士】
【氏名又は名称】松本 裕幸
(74)【代理人】
【識別番号】100171930
【弁理士】
【氏名又は名称】木下 郁一郎
(72)【発明者】
【氏名】宮▲崎▼ 太郎
(72)【発明者】
【氏名】後藤 淳
【審査官】原 秀人
(56)【参考文献】
【文献】特開２０１３－０８８８３２（ＪＰ，Ａ）
【文献】特開２０１４－２１９７６０（ＪＰ，Ａ）
【文献】特開２０１４－０７１８０１（ＪＰ，Ａ）
【文献】特開２００４－２２７３４３（ＪＰ，Ａ）
【文献】特開２００３－１９６４４５（ＪＰ，Ａ）
【文献】特開平０８－０１６６８０（ＪＰ，Ａ）
【文献】特開２０１３－１９６４２０（ＪＰ，Ａ）
【文献】国際公開第２０１６／１９４６２１（ＷＯ，Ａ１）
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｇ０６Ｆ １６／００－１６／９５８
Ｇ０６Ｑ ５０／１０
Ｇ０６Ｆ ４０／２０－４０／２９５
Ｈ０４Ｎ １７／００
(57)【特許請求の範囲】
【請求項1】
ユーザ以外の他のユーザに公開する文章の情報を含む投稿内容を前記ユーザの端末から送信し、前記投稿内容を閲覧することが予め登録されている他のユーザの端末へ、前記投稿内容を配信するサービスを利用している複数の前記ユーザそれぞれの前記投稿内容を取得する取得部と、前記取得部が取得した前記投稿内容のうち、投票であることを表す情報が含まれる前記投稿内容を抽出する抽出部と、
前記抽出部が抽出した前記投稿内容毎に、前記投稿内容による投票の対象である各投票対象に関する情報との関連を定量的に表す関連度を算出し、前記各投票対象それぞれについて算出された前記関連度に基づいて投票先の前記各投票対象を推定する投票先推定部と、
複数の前記投稿内容それぞれについて推定された前記投票先に基づいて、前記各投票対象ごとの投票数を集計する集計部と、
を備え、
前記各投票対象は番組であり、
前記投票先推定部は、前記抽出部が抽出した前記投稿内容毎に、複数の番組それぞれのタイトル及び概要文と前記投稿内容との間の文書同士の関連を定量的に表す第一スコアと、複数の前記番組それぞれの字幕と前記投稿内容との間の文書同士の関連を定量的に表す第二スコアとを算出し、前記番組それぞれの前記第一スコア及び前記第二スコアを総合したスコアに基づいて投票先の前記番組を推定する、
ことを特徴とする投票集計装置。
【請求項2】
前記サービスへ登録した日時が所定日時以降である前記ユーザから送信された前記投稿内容による投票を、投票数の集計対象から除く複数投票排除部をさらに備える、ことを特徴とする請求項１に記載の投票集計装置。
【請求項3】
前記ユーザから最初に送信された又は最初から所定回数以内に送信された前記投稿内容による投票を、投票数の集計対象から除く複数投票排除部をさらに備える、ことを特徴とする請求項１に記載の投票集計装置。
【請求項4】
前記投票先推定部により推定された前記投票先が同じである前記投稿内容のグループ毎に組織票排除処理を行う組織票排除部をさらに備え、前記取得部は、前記サービスにおける前記ユーザ間の関係を表す情報を取得し、
前記組織票排除処理は、
前記投稿内容を送信した前記ユーザをそれぞれノードにより表し、かつ、前記ユーザ間の関係を表す前記情報に基づいて関係のある前記ユーザを表す前記ノード間を結合したグラフ構造を作成するグラフ作成処理と、
前記グラフ構造において結合された前記ノード群であるサブグループ毎に、前記サブグループを構成する関係の数が、前記サブグループに含まれる前記ノード間の全てに関係があるときの前記関係の数に占める割合である充足率を算出する充足率算出処理と、
前記充足率がしきい値以上の前記サブグループに含まれる前記ノード群が表す複数の前記ユーザによる投票の重複を排除する排除処理と、
前記充足率が前記しきい値以下の前記サブグループから前記関係の数が所定よりも少ないノードを除去し、除去されなかったノードが所定数以上の前記サブグループに含まれる前記ユーザを対象として前記グラフ作成処理を行う繰り返し処理とを有する、
ことを特徴とする請求項１から請求項３のいずれか一項に記載の投票集計装置。
【請求項5】
コンピュータを、請求項１から請求項４のいずれか一項に記載の投票集計装置として機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、投票集計装置及びプログラムに関する。
【背景技術】
【0002】
テレビ番組の総集編などのいわゆるダイジェスト版を作成するために、過去の放送回の番組の中から人気の高かったシーンを視聴者の投票により選ぶことがある。この投票には、投稿フォームなどが活用されている。しかし、投票を実施する度に、投票対象を選択するプルダウンメニューなどを備えた専用の投稿フォームを用意する必要があり、制作者側に労力がかかる。視聴者にとっても、ウェブブラウザなどを利用して専用の投稿フォームにアクセスし、名前やメールアドレスを入力する必要があり、投票に手間がかかる。
【0003】
そこで、それらを必要としないＳＮＳ（ソーシャル・ネットワーキング・サービス）を活用した投票が考えられている。制作者側は、「特定のハッシュタグを付けてＳＮＳで投稿してください」と周知するだけで、投票用のフォームを準備することなく、投票を実施できる。また、視聴者は、スマートフォンなどから、例えばTwitter（登録商標）のようなＳＮＳのアプリケーション（アプリ）を用いて、気軽に投票を行うことができる。このように、ＳＮＳを活用した投票は、番組制作者と視聴者の双方にメリットがあると考えられる。しかしながら、ＳＮＳを用いた投票は、自由な文面で記述されるため、その文面からは投票先の番組が明確ではないことがある。
【0004】
一方で、ソーシャルメディアの情報を自動で分類する技術がある（例えば、特許文献１、２参照）。これらの技術はいずれも、ソーシャルメディアの投稿を解析し、目的に合わせた分類を行う。また、検索用のテキストに基づいてコンテンツを検索する技術（例えば、特許文献３、４参照）や、ＳＮＳへの書き込みに基づいて話題性のある番組を特定する技術がある（特許文献５参照）。
【先行技術文献】
【特許文献】
【0005】
【文献】特開２０１８－６３４６３号公報
【文献】特開２０１７－２０１４３７号公報
【文献】特開２０１７－１３４６７５号公報
【文献】特許第６１０１５５４号公報
【文献】特開２０１７－１２３０９４号公報
【発明の概要】
【発明が解決しようとする課題】
【0006】
上述した特許文献１、２の技術はいずれも、最終的な分類を行う際に機械学習を用いている。そのため、これらの技術を利用する場合、制作者側は、投票に適した学習データを用意する必要が生じる。例えば、特番に向けた投票など、ある特定の目的を持った１回のみの投票を実施する場合にも都度、学習データを用意しなければならない。また、特許文献３～５の技術は、投票先を特定して、投票数を集計するものではない。
【0007】
本発明は、このような事情を考慮してなされたもので、投票を実施する側と投票を行う側の両者の負荷を軽減しながら投票結果を集計することができる投票集計装置及びプログラムを提供する。
【課題を解決するための手段】
【0008】
本発明の一態様は、ユーザ以外の他のユーザに公開する文章の情報を含む投稿内容を前記ユーザの端末から送信し、前記投稿内容を閲覧することが予め登録されている他のユーザの端末へ、前記投稿内容を配信するサービスを利用している複数の前記ユーザそれぞれの前記投稿内容を取得する取得部と、前記取得部が取得した前記投稿内容のうち、投票であることを表す情報が含まれる前記投稿内容を抽出する抽出部と、前記抽出部が抽出した前記投稿内容毎に、前記投稿内容による投票の対象である各投票対象に関する情報との関連を定量的に表す関連度を算出し、前記各投票対象それぞれについて算出された前記関連度に基づいて投票先の前記各投票対象を推定する投票先推定部と、複数の前記投稿内容それぞれについて推定された前記投票先に基づいて、前記各投票対象ごとの投票数を集計する集計部と、を備えることを特徴とする投票集計装置である。
【0009】
本発明の一態様は、上述の投票集計装置であって、前記サービスへ登録した日時が所定日時以降である前記ユーザから送信された前記投稿内容による投票を、投票数の集計対象から除く複数投票排除部をさらに備える、ことを特徴とする。
【0010】
本発明の一態様は、上述の投票集計装置であって、前記ユーザから最初に送信された又は最初から所定回数以内に送信された前記投稿内容による投票を、投票数の集計対象から除く複数投票排除部をさらに備える、ことを特徴とする。
【0011】
本発明の一態様は、上述の投票集計装置であって、前記投票先推定部により推定された前記投票先が同じである前記投稿内容のグループ毎に組織票排除処理を行う組織票排除部をさらに備え、前記取得部は、前記サービスにおける前記ユーザ間の関係を表す情報を取得し、前記組織票排除処理は、前記投稿内容を送信した前記ユーザをそれぞれノードにより表し、かつ、前記ユーザ間の関係を表す前記情報に基づいて関係のある前記ユーザを表す前記ノード間を結合したグラフ構造を作成するグラフ作成処理と、前記グラフ構造において結合された前記ノード群であるサブグループ毎に、前記サブグループを構成する関係の数が、前記サブグループに含まれる前記ノード間の全てに関係があるときの前記関係の数に占める割合である充足率を算出する充足率算出処理と、前記充足率がしきい値以上の前記サブグループに含まれる前記ノード群が表す複数の前記ユーザによる投票の重複を排除する排除処理と、前記充足率が前記しきい値以下の前記サブグループから前記関係の数が所定よりも少ないノードを除去し、除去されなかったノードが所定数以上の前記サブグループに含まれる前記ユーザを対象として前記グラフ作成処理を行う繰り返し処理とを有する、ことを特徴とする。
【0012】
本発明の一態様は、上述の投票集計装置であって、前記各投票対象は番組であり、前記投票先推定部は、前記抽出部が抽出した前記投稿内容毎に、複数の番組それぞれのタイトル及び概要文との関連を定量的に表す第一スコアと、複数の前記番組それぞれの字幕との関連を定量的に表す第二スコアとを算出し、前記番組それぞれの前記第一スコア及び前記第二スコアに基づいて投票先の前記番組を推定する。
【0013】
本発明の一態様は、コンピュータを、上述したいずれかの投票集計装置として機能させるためのプログラムである。
【発明の効果】
【0014】
本発明によれば、投票を実施する側と投票を行う側の両者の負荷を軽減しながら投票結果を集計することができる。
【図面の簡単な説明】
【0015】
【図1】本発明の一実施形態による投票集計装置の構成を示す機能ブロック図である。
【図2】同実施形態によるユーザ情報を示す図である。
【図3】同実施形態による番組情報を示す図である。
【図4】同実施形態による投票集計装置の処理を示すフロー図である。
【図5】同実施形態による組織票排除処理のアルゴリズムを示す図である。
【図6】同実施形態による組織票排除処理を示すフロー図である。
【図7】同実施形態によるグラフ構造を示す図である。
【図8】同実施形態によるグラフ構造を示す図である。
【図9】同実施形態によるグラフ構造を示す図である。
【図10】同実施形態によるグラフ構造を示す図である。
【図11】同実施形態による投票の集計方法を説明するための図である。
【発明を実施するための形態】
【0016】
以下、図面を参照しながら本発明の実施形態を詳細に説明する。
図１は、本発明の一実施形態による投票集計装置１の構成を示す機能ブロック図である。投票集計装置１は、ＳＮＳシステム２及び番組情報記憶装置３と通信可能である。投票集計装置１は、ＳＮＳを利用して行われた投票の内容を解析して投票先の番組を推定し、番組ごとに投票数を集計する。
図１は、本発明の一実施形態による投票集計装置１の構成を示す機能ブロック図である。投票集計装置１は、ＳＮＳシステム２及び番組情報記憶装置３と通信可能である。投票集計装置１は、ＳＮＳを利用して行われた投票の内容を解析して投票先の番組を推定し、番組ごとに投票数を集計する。
【0017】
ＳＮＳシステム２は、サービス利用者として登録されているユーザにＳＮＳサービスを提供するサービス提供システムである。ＳＮＳサービスでは、サービス利用者の端末から他のサービス利用者に公開する情報をＳＮＳシステム２に送信し、登録する。サービス利用者の端末から、他のサービス利用者に公開する情報をＳＮＳシステム２に送信し、登録することを投稿と記載する。また、投稿された情報を投稿内容と記載する。ＳＮＳシステム２は、投稿を行ったサービス利用者である投稿者が閲覧を許可し、かつ、その投稿者が公開する情報の閲覧を希望することが予め登録されている他のサービス利用者の端末に、投稿内容を配信する。投稿者が、投稿内容の閲覧を許可する他のサービス利用者は、特定のユーザでもよく、ＳＮＳサービスを利用する全ユーザでもよい。
【0018】
本実施形態において利用可能なＳＮＳサービスでは、投稿内容に、少なくともテキストデータを用いることができる。このようなＳＮＳサービスとして、例えば、Twitter（登録商標）がある。特定のユーザが投稿したときにその投稿内容を配信するようＳＮＳシステム２に登録しておくことを、そのユーザを「フォローする」と記載する。例えば、ユーザＡの投稿内容の配信を希望するユーザＢは、ユーザＡをフォローするフォロワーである。このとき、ユーザＡがユーザＢのフォロワーであれば、ユーザＡとユーザＢは双方向の関係を有する。ユーザＢがユーザＡのフォロワーであるが、ユーザＡはユーザＢのフォロワーではない場合、ユーザＢからユーザＡへの片方向の関係を有する。
【0019】
番組情報記憶装置３は、例えば、１台以上のデータベースサーバにより構成される。番組情報記憶装置３は、各番組の番組情報を記憶する。番組情報は、番組の放送日時、番組タイトル、番組概要、字幕などの情報を含む。
【0020】
投票集計装置１は、取得部１１、記憶部１２、抽出部１３、投票先推定部１４、複数投票排除部１５、組織票排除部１６及び集計部１７を有する。投票集計装置１は、１台又は複数台のコンピュータ装置により実現される。投票集計装置１をネットワークにより接続される複数のコンピュータ装置により実現する場合、投票集計装置１の各機能部を、これら複数のコンピュータ装置のいずれにより実現するかは任意とすることができる。また、同一の機能部を複数のコンピュータ装置により実現してもよい。また、投票集計装置１は、番組情報記憶装置３を備えてもよい。また、ＳＮＳシステム２が投票集計装置１を備えてもよい。
【0021】
取得部１１は、ＳＮＳシステム２からＳＮＳ情報を取得する。ＳＮＳ情報は、ＳＮＳサービスの利用者となっている各ユーザのユーザ情報を含む。ユーザ情報は、ユーザを特定する情報であるユーザＩＤ、サービス利用を登録した日時、フォロワー、フォローしている他のユーザ、投稿情報などを含む。投稿情報は、投稿日時と投稿内容を含む。記憶部１２は、取得部１１が取得したＳＮＳ情報など、各部の処理に用いられる情報を記憶する。抽出部１３は、取得部１１が取得したユーザ情報に含まれる投稿情報のうち、投票であることを表す情報を含んだ投稿内容の投稿情報を抽出する。投票であることを表す情報として、例えば、ハッシュタグが用いられる。
【0022】
投票先推定部１４は、抽出部１３が抽出した各投稿情報の投稿内容から、ユーザが投票した番組を推定する。投票先推定部１４は、この推定に、文書同士の関連を定量的に表す値を利用した従来の検索技術を用いる。投票先推定部１４は、抽出部１３が抽出した投稿情報毎に、投稿内容の文書と各番組のタイトル及び概要文との関連を定量的な値で表した関連度である第一スコアと、投稿内容の文書と各番組の字幕との関連を定量的な値で表した関連度である第二スコアとを算出する。投票先推定部１４は、各番組について算出された第一スコア及び第二スコアに基づいて、投稿情報毎に投票先の番組を推定する。
【0023】
複数投票排除部１５は、「一人あたり一回の投票」の制限がある場合に、同一ユーザからの複数の投票を排除する。複数投票排除部１５は、抽出部１３が抽出した投稿情報の中に、同一のユーザＩＤが投稿者である複数の投稿情報を検出した場合、それら複数の投稿情報のうちいずれかを選択し、選択されなかった投稿情報による投票を無効とする。つまり、複数投票排除部１５は、無効とする投稿情報について投票先推定部１４が推定した投票先を、投票数の集計対象から除く。
【0024】
また、ユーザは、同一ユーザからの投票ではないように見せかけるために、新規にＳＮＳサービスのユーザＩＤを取得して、投票を行う場合がある。そこで、複数投票排除部１５は、抽出部１３が抽出した投稿情報のうち、以下の二つの条件のいずれか又は両方に合致する投稿情報を無効とし、その投稿情報による投票を、投票数の集計対象から除く。一つ目は、現在から所定時間遡った日時以降に新規にサービスの利用を登録したユーザからの投稿情報であるという条件である。二つ目は、サービスの利用を登録してから最初の又は最初から所定回（２回、３回など）以内の投稿情報であるという条件である。
【0025】
組織票排除部１６は、組織票を排除する。組織票とは、ある団体がまとまって特定の対象に投じる票である。そこでまず、組織票排除部１６は、同じ対象に投票したユーザを１つのグループとし、ユーザ情報を参照して、グループ毎にユーザ間の関係を表すグラフ構造を作成するグラフ作成処理を行う。グラフ構造は、抽出部１３が抽出した投稿情報の投稿者である各ユーザをそれぞれノードとして表し、さらに、各ユーザを表すノードから当該ユーザがフォロワーとなっている（フォローしている）他のユーザを表すノードに至る方向の矢印によりそれらノード間を結合して表される。このグラフ作成処理によって、矢印で結合されたノードの塊（ノード群）からなり、他のノード群とは結合がないノード群であるサブグループが得られる。組織票排除部１６は、サブグループ毎に、充足率を算出する充足率算出処理を行う。充足率は、サブグループに含まれる矢印の数が、そのサブグループに含まれるノード間を全て両方向で結合したときの矢印の数に占める割合である。組織票排除部１６は、充足率がしきい値以上のサブグループに含まれるノードに対応するユーザからの投票については組織票と判断し、それら組織票については投票の重複を排除してまとめて１票とする排除処理を行う。組織票排除部１６は、充足率がしきい値以下のサブグループについては、組織票とは関連しないユーザのノードを除去し、除去されずに残ったノードに対応したユーザを対象にしてグラフ作成処理を繰り返す繰り返し処理を行う。組織票とは関連しないユーザのノードは、矢印の数が所定よりも少ない、例えば、最も少ないノードである。また、組織票排除部１６は、サブグループに含まれるユーザが少ない場合、そのサブグループ自体が組織票とは関連しないユーザ群であると判断する。
【0026】
集計部１７は、複数の投稿情報それぞれについて特定された投票先の番組に基づいて番組ごとの投票数を集計する。集計部１７は、集計した各番組の投票数を出力する。
【0027】
図２は、ユーザ情報の例を示す図である。ユーザ情報は、ユーザＩＤ、ユーザ名、登録日時、フォロワー、フォロー対象ユーザ、投稿回数、投稿情報を含む。ユーザＩＤは、ユーザを一意に特定する識別情報である。ユーザ名は、ユーザの名前である。登録日時は、ユーザがサービス利用を登録した日時である。フォロワーは、ユーザが投稿内容の公開を許可している他のユーザを示す。フォロー対象ユーザは、ユーザがフォロワーとなっている他のユーザを示す。投稿回数は、ユーザが投稿を行った回数である。投稿情報は、投稿日時と投稿内容を含む。なお、ユーザがリツイートを行った場合、投稿情報にはリツイートである旨の情報と、リツイートされた投稿情報を投稿したユーザの情報が付加される。リツイートとは、自身がフォローしている他のユーザの投稿内容を、自身のフォロワーに公開するために投稿することである。なお、ユーザ情報は、ユーザに関する属性の情報をさらに含んでもよい。属性は、例えば、住所、生年月日、性別などであるが、これらに限定されない。
【0028】
図３は、番組情報の例を示す図である。番組情報は、番組ＩＤ、放送日時、番組タイトル、番組概要、字幕などの情報を含む。番組ＩＤは、番組を一意に特定する識別情報である。放送日時は、番組が放送された日時を示す。番組タイトルは、番組のタイトル及びサブタイトルを示すテキストデータである。番組概要は、番組のあらすじや番組内容などの文章や、出演者等を示すテキストデータである。字幕は、番組の字幕を示すテキストデータである。
【0029】
＜投票集計装置１の動作＞
図４は、投票集計装置１の処理を示すフロー図である。番組制作者は、番組投票を実施する際に、特定のハッシュタグを付けてＳＮＳにより投票するよう周知する。ＳＮＳの利用であるユーザは、自身が利用している端末から、投票先の番組について記述した文章と、周知されたハッシュタグとを含んだ投稿内容をＳＮＳシステム２に投稿する。ＳＮＳシステム２は、ユーザの端末から投稿内容を受信すると、投稿日時を付加してユーザ情報に追加する。
図４は、投票集計装置１の処理を示すフロー図である。番組制作者は、番組投票を実施する際に、特定のハッシュタグを付けてＳＮＳにより投票するよう周知する。ＳＮＳの利用であるユーザは、自身が利用している端末から、投票先の番組について記述した文章と、周知されたハッシュタグとを含んだ投稿内容をＳＮＳシステム２に投稿する。ＳＮＳシステム２は、ユーザの端末から投稿内容を受信すると、投稿日時を付加してユーザ情報に追加する。
【0030】
ステップＳ１１０において、投票集計装置１の取得部１１は、投票を集計するタイミングに応じて、ＳＮＳシステム２からＳＮＳ情報を読み出して記憶部１２に書き込む。読み出したＳＮＳ情報は、特定のユーザのみを公開対象としたユーザのユーザ情報を含まないようにしてもよい。ステップＳ１２０において、抽出部１３は、記憶部１２が記憶しているＳＮＳ情報に含まれるユーザ情報から、投稿日時が投票実施期間内に含まれ、かつ、投稿内容に投票を表すハッシュタグが設定されている投稿情報を抽出する。以下では、この抽出された投稿情報を、投票用投稿情報と記載する。ステップＳ１３０において、投票先推定部１４は、各投票用投稿情報による投票先の番組を推定する。
【0031】
一般にＳＮＳの投稿内容には文字数の制限がある。また、投稿内容は、自由記述である。そのため、投稿内容に記述された文言の選択も、番組情報に使用されているものと異なることが多い。そこで、投票先推定部１４は、単純なキーワードマッチングではなく、文書同士の関連を定量的な値として算出する検索技術を用いる。特に、関連語句にまで拡張して文書同士の関連を検索する技術が望ましい。この検索技術には、例えば、特許文献３の技術を用いることができる。また、Word2Vecや、Doc2Vecを用いることもできる。
【0032】
加えて、投稿内容には、「くらげ水族館の回」のように番組全体の内容を表す語句が使われる場合や、「飼育員の○○さんが言っていた△△という言葉に感動した」のように番組の一部のシーンを表す語句が使われる場合がある。そこで、投票先推定部１４は、投稿内容を用いた検索の対象を、各番組の「番組タイトルと概要文」と「番組の全字幕」との２種類とする。投票先推定部１４は、それら検索対象それぞれの検索結果として得られたスコアに重み付けを行った後に加算し、最終的なスコアを算出する。複数投票排除部１５は、最終的なスコアが高い番組を投票先として推定する。
【0033】
特許文献３に開示された検索キーと関連するコンテンツを検索するための番組情報検索装置の技術を適用した場合、投票先推定部１４は、以下のように検索を行う。まず、投票先推定部１４は、投稿内容を検索キーとする。投票先推定部１４は、投稿内容に含まれる単語を上位関連語として取得する。投票先推定部１４は、関連する単語と、それら関連する単語間の類似度とを示す概念マップから、各上位関連語について、関連する単語と、その関連する単語との類似度を読み出す。さらに、投票先推定部１４は、読み出された各単語について、関連する他の単語と、その関連する他の単語との類似度を概念マップから読み出す処理を所定回繰り返す。投票先推定部１４は、概念マップから読み出された単語である下位関連語毎に、上位関連語から下位関連語に至るまでに概念マップから読み出された単語を順に並べた単語の列であるパスを取得する。
【0034】
投票先推定部１４は、上位関連語から下位関連語に至るパスにおいて隣接する単語間の類似度と、パスに含まれる単語に関連する他の単語の数と、上位関連語の単語の重要度とに基づいて、下位関連語毎に検索キーとの関連の高さを表す関連度を計算する。この関連度は、類似度が高いほど、関連する他の単語の数が少ないほど、又は、重要度が高いほど、高いスコアとなる。また、上位関連語の単語の重要度として、ＩＤＦ（Inversed Document Frequency）を用いることができる。さらに、投票先推定部１４は、検索対象のテキストデータを単語に分割し、分割により得られた単語のうち上位関連語又は下位関連語に合致する各単語を特定する。投票先推定部１４は、特定した単語それぞれについて、単語の重要度と関連度とを乗算し、乗算した結果の合計を、検索対象の分割により得られた単語の数の対数により除算してスコアを計算する。ここで用いる単語の重要度として、ｏｋａｐｉ－ＢＭ２５や、特開２０１５－１３２８９９号公報に開示されているＣｏＭの値を用いることができる。ＣｏＭは、文中に関連する単語（類似度が高い単語）が多く出現する単語ほど、その文中で重要な単語である、という考え方に基づいた重み付け手法である。
【0035】
例えば、投票先推定部１４は、非特許文献３の技術を用いた第一検索エンジン及び第二検索エンジンを有する。第一検索エンジンは、検索対象が番組タイトル及び概要文であり、第二検索エンジンは、検索対象が番組の字幕である。投票先推定部１４は、これら第一及び第二検索エンジンに、投票用投稿情報の投稿内容を検索キーとして入力する。第一検索エンジンからは第一スコアｓｔが出力され、第二検索エンジンからは第二スコアｓｃが出力される。投票先推定部１４は、以下の式（１）により、投票先の候補となる番組ごとに、番組情報記憶装置３に記憶されるそれら番組情報を読み出して、第一スコアｓｔ及び第二スコアｓｃの重み付け和ｓを算出する。
【0036】
ｓ＝αｓｔ＋（１－α）ｓｃ …（１）
【0037】
投票先推定部１４は、番組について算出した重み付け和ｓを、その番組への投票である可能性を表すスコアとする。なお、字幕を対象とした検索では、検索対象に多くの文を含むため、投稿が意図した対象以外の番組にも比較的高いスコアを付与しやすい。そこで、αの値を０．５より大きくし、番組タイトル及び概要文を対象とした検索の重みを、字幕を対象とした検索よりも高くすることが望ましい。投票先推定部１４は、この重み付け和（スコア）sが最大の番組を、投票用投稿情報の投稿内容から推定される投票先の番組と判断する。
【0038】
投票集計装置１は、各投票用投稿情報の投票先を推定した後、投票実施要領に応じたフィルタを適用する。フィルタには、「複数投票の排除」、「組織票の排除」などがある。まず、ステップＳ１４０において、複数投票排除部１５は、「１人あたり１回の投票」のフィルタリング条件に合うように、複数投票の排除を行う（ステップＳ１４０）。投票先推定部１４は、各投票用投稿情報を投稿したユーザのユーザＩＤを記憶部１２が記憶しているユーザ情報から読み出す。投票先推定部１４は、同一のユーザＩＤの投票用投稿情報が複数ある場合、それらの投票用投稿情報のうち投稿日時が最も古いもの、又は、最も新しいものを選択し、選択されなかった残りの投票用投稿情報を用いた投票を投票数の集計対象から除く。フィルタリング条件が「１人１日１票まで」のときには、投票先推定部１４は、同一の投稿日に同一のユーザＩＤの投票用投稿情報が複数あるかを検出する。投票先推定部１４は、検出された同一投稿日かつ同一ユーザＩＤの複数の投票用投稿情報のうち投稿時刻が最も古いもの、又は、最も新しいものを選択し、選択されなかった残りの投票用投稿情報を投票数の集計対象から除く。
【0039】
さらに、複数投票排除部１５は、異なるユーザＩＤを用いて複数回投票を行うために使用されたと推定される投票用投稿情報を特定し、その投票用投稿情報による投票を無効にする。具体的には、複数投票排除部１５は、投票先が推定された投票用投稿情報を投稿したユーザの登録日時を、記憶部１２に記憶されているユーザ情報から読み出す。複数投票排除部１５は、登録日時が現在から所定時間遡った日時以降であるユーザの投票用投稿情報を投票数の集計対象から除く。例えば、投票の告知が最初に行われた日時を、現在から所定時間遡った日時としてもよい。また、複数投票排除部１５は、ユーザ情報に投票回数が１回又は所定回数以内（例えば、２～３回）であることが設定されているユーザの投票用投稿情報を投票数の集計対象から除く。あるいは、複数投票排除部１５は、投票先が推定された投票用投稿情報がユーザの何回目の投稿のものであるかを、ユーザ情報に含まれる投稿情報を参照して判断する。複数投票排除部１５は、ユーザの最初の又は最初から所定回以内の投稿による投票用投稿情報を投票数の集計対象から除く。
【0040】
ステップＳ１５０において、組織票排除部１６は、組織票を排除する（ステップＳ１５０）。組織票排除部１６は、投票用投稿情報を投稿したユーザのうち、同一の番組に投票したユーザ間の関係に着目する。組織票排除部１６は、ユーザ間の関係として、ユーザ情報に登録されているフォロー対象ユーザの情報を得る。Twitter（登録商標）の場合、@-mentionと呼ばれる記述により、フォロワーに公開する投稿内容に他のユーザの情報を埋め込むことができる。そこで、組織票排除部１６は、ユーザＡの投稿内容に@-mentionを用いてユーザＢの情報が記述されている場合、ユーザＡからユーザＢへの関係があるとみなしてもよい。また、ユーザＡがユーザＣの投稿内容をリツイートした場合に、ユーザＡはユーザＣへの関係がある（ユーザＣのフォロワーである）とみなしてもよい。このように、ユーザ間の関係を、投稿情報から得ることもできる。以下では、フォローの関係をユーザ間の関係として利用する場合を例に説明するが、@-mentionやリツイートなどから得られるユーザ間の関係を用いても同様の手順で実施可能である。なお、組織票の排除の処理は、図５及び図６を用いて後述する。組織票排除部１６は、同じ番組に組織票を投票したユーザのグループからの投票をまとめて１票とする。
【0041】
ステップＳ１６０において、集計部１７は、上記の処理よって、投票用投稿情報から同一ユーザによる投票や組織票を排除して得られた有効な投票用投稿情報の投票先を集計し、各番組の投票数を得る。集計部１７は、この最終的に得られた各番組の投票数を出力する。
【0042】
図５は、図４のステップＳ１５０における組織票排除処理のアルゴリズムを示す図であり、図６は、図５に示すアルゴリズムを用いた組織票排除処理を示すフロー図である。図５及び図６を参照して、組織票排除処理を詳細に説明する。組織票排除部１６は、投票対象となりうる番組をそれぞれ番組ｔとして、図５及び図６に示す組織票排除処理を行う。
【0043】
まず、ステップＳ２１０において、組織票排除部１６は、番組ｔに投票したユーザＵｔを処理対象ユーザＵ－
ｔとする。番組ｔに投票したとは、投票用投稿情報について推定された投票先が番組ｔであることを示す。ステップＳ２２０において、組織票排除部１６は、処理対象ユーザＵ－
ｔ間の関係を表すグラフ構造を作成する。組織票排除部１６は、作成したグラフ構造に基づき、処理対象ユーザＵ－
ｔを任意の距離で互いに接続されているユーザをまとめたサブグループに分割する。サブグループの数をＮとしたとき、ｎ番目（ｎは１以上Ｎ以下の整数）のサブグループをサブグループＵ－
ｔｎとする。組織票排除部１６は、処理継続サブグループＵ－’
ｔｎをＮＵＬＬなどに初期化する。
【0044】
図７は、グラフ構造の例を示す図である。丸で表される１０個のノードは、それぞれ異なる処理対象ユーザＵ－
ｔを表す。これらのノードを、ユーザＵ１～Ｕ１０と記載する。組織票排除部１６は、処理対象ユーザＵ－
ｔが表すユーザのユーザ情報を参照して、フォローの関係を表す矢印によりユーザＵ１～Ｕ１０間を結ぶ。ユーザＵｘ（ｘは１以上１０以下の整数）からユーザＵｙ（ｙ≠ｘ，ｙは１以上１０以下の整数）への矢印は、ユーザＵｘが表す処理対象ユーザＵ－
ｔは、ユーザＵｙが表す処理対象ユーザＵ－
ｔをフォローしている（フォロワーである）ことを表す。両方向の矢印はお互いをフォローしあっていることを示す。図７に示すグラフ構造では、サブグループの数Ｎは１である。
【0045】
図６のステップＳ２３０において、組織票排除部１６は、サブグループＵ－
ｔｎを一つ選択する。ステップＳ２４０において、組織票排除部１６は、選択したサブグループＵ－
ｔｎの関係の充足率ｓｎを、以下の式（２）及び（３）を用いて算出する。なお、ｕ，ｖは、サブグループＵ－
ｔｎに含まれる処理対象ユーザＵ－
ｔである。
【0046】
【数1】
【0047】
【数2】
【0048】
式（３）の右辺の分母は、サブグループＵ－
ｔｎに含まれる全ての処理対象ユーザＵ－
ｔ間に双方向の関係がある場合の関係の数である。処理対象ユーザＵ－
ｔの数をＭとした場合、分母はＭＣ２によって算出できる。また、式（３）の右辺の分子は、サブグループＵ－
ｔｎにおける実際の関係の数である。例えば、図７に示すサブグループの場合、処理対象ユーザＵ－
ｔの数Ｍは１０、関係の数は２３であるため、関係の充足率ｓｎ＝２３／１０Ｃ２＝０．２５６である。
【0049】
ステップＳ２５０において、組織票排除部１６は、充足率ｓｎがしきい値ｔｈｓを超えたか否かを判定する。組織票排除部１６は、しきい値を超えると判定した場合（ステップＳ２５０：ＹＥＳ）、ステップＳ２６０の処理を行う。すなわち、組織票排除部１６は、選択したサブグループＵ－
ｔｎを組織票グループとみなす。組織票排除部１６は、組織票グループに含まれる処理対象ユーザＵ－
ｔそれぞれから番組ｔへの投票をまとめて１票とする。
【0050】
一方、組織票排除部１６は、充足率ｓｎがしきい値ｔｈｓ以下であると判断した場合（ステップＳ２５０：ＮＯ）、ステップＳ２７０の処理を行う。すなわち、組織票排除部１６は、各処理対象ユーザＵ－
ｔの関係の数ｄｕを、以下の式（４）により算出する。グラフ構造において両矢印で表される双方向の関係は、関係数が２であるとして計数される。
【0051】
【数3】
【0052】
ステップＳ２８０において、組織票排除部１６は、サブグループＵ－
ｔｎから最も関係の数ｄｕが少ない処理対象ユーザＵ－
ｔを除去する。ステップＳ２８０において、組織票排除部１６は、ステップＳ２７０において除去した処理対象ユーザＵ－
ｔを、組織票グループに属さないとみなし、その処理対象ユーザＵ－
ｔの投票を１票として扱うと判断する。
【0053】
ステップＳ２９０において、組織票排除部１６は、最も関係の数ｄｕが少ない処理対象ユーザＵ－
ｔを除去した後のサブグループＵ－
ｔｎに含まれる処理対象ユーザＵ－
ｔの数がしきい値ｔｈｕを超えるか否かを判定する。組織票排除部１６は、しきい値ｔｈｕを超えないと判定した場合（ステップＳ２９０：ＮＯ）、ステップＳ３００の処理を行う。すなわち、組織票排除部１６は、サブグループＵ－
ｔｎに含まれる処理対象ユーザＵ－
ｔは、組織票グループに属さないと判定する。つまり、組織票排除部１６は、それら処理対象ユーザＵ－
ｔの投票は組織票ではなく、各処理対象ユーザＵ－
ｔの投票をそれぞれ１票として扱うと判定する。
【0054】
一方、組織票排除部１６は、サブグループＵ－
ｔｎに含まれる処理対象ユーザＵ－
ｔの数がしきい値ｔｈｕを超えると判断した場合（ステップＳ２９０：ＹＥＳ）、ステップＳ３１０の処理を行う。すなわち、組織票排除部１６は、処理継続サブグループＵ－’
ｔｎに現在のサブグループＵ－
ｔｎを追加する。
【0055】
ステップＳ２６０、ステップＳ３００又はステップＳ３１０の処理の後、組織票排除部１６は、ステップＳ３２０の処理を行い、全てのサブグループＵ－
ｔｎを選択したか否かを判定する。組織票排除部１６は、未選択のサブグループＵ－
ｔｎがあると判定した場合（ステップＳ３２０：ＮＯ）、ステップＳ２３０の処理に戻り、次のサブグループＵ－
ｔｎを選択する。
【0056】
組織票排除部１６は、Ｎ個の全てのサブグループＵ－
ｔｎを選択したと判定した場合（ステップＳ３２０：ＹＥＳ）、ステップＳ３３０の処理を行い、終了か否かを判定する。例えば、組織票排除部１６は、処理継続サブグループＵ－’
ｔ１～Ｕ－’
ｔＮのいずれかがＮＵＬＬではない場合に終了ではないと判定し、全てＮＵＬＬである場合に終了と判定する。組織票排除部１６は、終了ではないと判定した場合（ステップＳ３３０：ＹＥＳ）、ステップＳ３４０の処理を行う。すなわち、組織票排除部１６は、処理継続サブグループＵ－’
ｔ１～Ｕ－’
ｔＮに含まれるユーザを処理対象ユーザＵ－
ｔとし、ステップＳ２２０からの処理を繰り返す。そして、組織票排除部１６は、終了と判定した場合（ステップＳ３３０：ＮＯ）、番組ｔについての組織票排除処理を終了する。
【0057】
上記の組織票排除処理の具体的な例を以下に示す。充足率のしきい値ｔｈｓが０．５、ユーザ数のしきい値ｔｈｕが３である場合を例に説明する。
例えば、ステップＳ２２０において図７に示すグラフ構造が得られた場合、組織票排除部１６は、ステップＳ２４０において算出した充足率ｓｎ（＝０．２５６）がしきい値ｔｈｓ（＝０．５）以下であると判定する（ステップＳ２５０：ＮＯ）。組織票排除部１６は、ユーザＵ１～Ｕ１０それぞれの関係の数を計数する。
例えば、ステップＳ２２０において図７に示すグラフ構造が得られた場合、組織票排除部１６は、ステップＳ２４０において算出した充足率ｓｎ（＝０．２５６）がしきい値ｔｈｓ（＝０．５）以下であると判定する（ステップＳ２５０：ＮＯ）。組織票排除部１６は、ユーザＵ１～Ｕ１０それぞれの関係の数を計数する。
【0058】
図８は、ユーザＵ１～Ｕ１０それぞれの関係の数を計数した結果を記載したグラフ構造を示す図である。ユーザＵｘ（ｘ＝１～１０）のノードの中に記述された数字は、ユーザＵｘの関係の数を表す。例えば、ユーザＵ１は関係の数ｄｕが４であり、ユーザＵ２の関係の数ｄｕは６である。
【0059】
組織票排除部１６は、サブグループＵ－
ｔｎから最も関係の数ｄｕが少ないｄｕ＝３のユーザＵ６及びＵ７を除去する（ステップＳ２７０）。組織票排除部１６は、ユーザＵ６及びＵ７が表すユーザを、組織票グループに属さないとみなす（ステップＳ２８０）。ユーザＵ６及びＵ７を除去した後のサブグループＵ－
ｔｎのユーザ数は８であり、ユーザ数のしきい値ｔｈｕ（＝３）を超える（ステップＳ２９０：ＹＥＳ）。そこで、組織票排除部１６は、残ったユーザＵ１～Ｕ５、Ｕ８～Ｕ１０を処理対象ユーザＵ－
ｔとして再びグラフ構造を作成する（ステップＳ３１０、ステップＳ３２０：ＹＥＳ、ステップＳ３３０：ＮＯ、ステップＳ３４０、ステップＳ２２０）。
【0060】
図９は、図８において関係の数が最小のユーザＵ６及びＵ７を除去した後に生成されるグラフ構造を示す図である。図９に示すグラフ構造のサブグループの数Ｎは２であり、ユーザＵ１～Ｕ５から構成されるサブグループＵ－
ｔ１と、ユーザＵ８～Ｕ１０から構成されるＵ－
ｔ２とを有している。また、図９には、各ユーザＵ１～Ｕ５、Ｕ８～Ｕ１０の関係の数が示されている。
【0061】
一つ目のサブグループＵ－
ｔ１の充足率ｓｎは０．５５であり、しきい値ｔｈｓを超えない（ステップＳ２４０、ステップＳ２５０：ＮＯ）。よって、組織票排除部１６は、サブグループＵ－
ｔ１から最も関係の数ｄｕが少ないユーザＵ５を除去する（ステップＳ２７０）。除去後のサブグループＵ－
ｔ１のユーザ数は４であり、しきい値ｔｈｕ＝３を超えている（ステップＳ２９０：ＹＥＳ）。組織票排除部１６は、除去後のサブグループＵ－
ｔ１に属するユーザＵ１～Ｕ４を処理継続サブグループＵ－’
ｔ１に追加する（ステップＳ３１０）。
【0062】
二つ目のサブグループＵ－
ｔ２の充足率ｓｎは１．００であり、しきい値ｔｈｓを超えている（ステップＳ２４０、ステップＳ２５０：ＹＥＳ）。組織票排除部１６は、サブグループＵ－
ｔ２を組織票グループと判断する（ステップＳ２６０）。この組織票グループをＧ１と記載する。組織票排除部１６は、処理継続サブグループＵ－’
ｔ１に設定されているユーザＵ１～Ｕ４を処理対象ユーザＵ－
ｔとして再びグラフ構造を作成する（ステップＳ３２０：ＹＥＳ、ステップＳ３３０：ＮＯ、ステップＳ３４０、ステップＳ２２０）。
【0063】
図１０は、図９に示すグラフ構造の後に作成されたグラフ構造を示す図である。なお、図１０には、すでに検出された組織票グループＧ１も示されている。図１０に示すグラフ構造のサブグループの数Ｎは１である。さらに図１０には、サブグループＵ－
ｔ１を構成する各ユーザＵ１～Ｕ４の関係の数が記述されている。サブグループＵ－
ｔ１の充足率ｓｎは０．７５であり、しきい値ｔｈｓを超えている（ステップＳ２４０、ステップＳ２５０：ＹＥＳ）。よって、組織票排除部１６は、サブグループＵ－
ｔ１を組織票グループと判断する（ステップＳ２６０）。この組織票グループをＧ２と記載する。組織票排除部１６は、全てのサブグループの選択が終了し（ステップＳ３２０：ＹＥＳ）、かつ、処理継続サブグループＵ－’
ｔ１にはサブグループが設定されていないため（ステップＳ３３０：ＹＥＳ）、複数投票排除処理を終了する。上記により、各ユーザＵ１～Ｕ１０が、組織票グループに属するか否かが判断される。
【0064】
図１１は、図７に示すグラフ構造が得られたユーザからの投票の集計方法を説明するための図である。組織票排除部１６は、組織票グループＧ２に属するユーザＵ１～Ｕ４からの投票をまとめて１票とし、組織票グループＧ１に属するユーザＵ８～Ｕ１０からの投票をまとめて１票とする。従って、集計部１７は、番組ｔへの投票数を、組織票グループＧ２、ユーザＵ５、ユーザＵ６、ユーザＵ７、組織票グループＧ１からの５票と集計する。
【0065】
なお、充足率のしきい値ｔｈｓ、及び、ユーザ数のしきい値ｔｈｕは、任意に設定可能である。また、ユーザ情報にユーザの属性の情報が含まれている場合、抽出部１３は、属性が所定条件に合致するユーザの投稿情報について上記の処理を行ってもよい。これにより、投票可能なユーザを属性によりフィルタリングすることができる。また、集計部１７は、ユーザの属性毎に投票数を集計してもよい。
【0066】
上述した実施形態では、投票対象が番組である場合を例に説明したが、投票対象は任意とすることができる。この場合、投票集計装置１は、番組情報に代えて、投票対象に関する内容を記述したテキストデータを用いる。例えば、投票対象が商品である場合、投票集計装置１は、番組タイトル及び概要文に代えて商品名及び商品紹介を用い、字幕に代えて商品のレビューを用いてスコアを算出する。
【0067】
上述した実施形態によれば、投票集計装置１は、ＳＮＳに投稿された文面から、視聴者がどの番組へ投票しようとしていたのかを推定することができる。よって、ＳＮＳを用いた番組投票の実施が可能となるため、投票実施側は投稿フォームを用意する必要がなく、また、視聴者は手軽に投票を行うことができる。加えて、投票集計装置１による投票の集計は、ある特番に向けた投票など、１回のみ実施する投票にも活用できる。
【0068】
また、ＳＮＳを用いた投稿の特徴として、投稿者の情報を使用できることから、投票集計装置１は、投票の募集要件に合わせたフィルタリングを行うことができる。例えば、視聴者は手軽に投票できることから、同一ユーザからの複数投票や、組織票が発生する可能性がある。投票集計装置１は、ＳＮＳにおける投稿者の情報を参照して、投稿フォームからの投稿では難しかった「１人あたり１件の投票のみ」の制限や、組織票の排除などのフィルタリングを行うことができる。
【0069】
上述した実施形態における投票集計装置１及びＳＮＳシステム２の機能をコンピュータで実現するようにしてもよい。その場合、この投票集計装置１及びＳＮＳシステム２の機能を実現するためのプログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行することによって実現してもよい。なお、ここでいう「コンピュータシステム」とは、ＯＳや周辺機器等のハードウェアを含むものとする。また、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ＲＯＭ、ＣＤ－ＲＯＭ等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置のことをいう。さらに「コンピュータ読み取り可能な記録媒体」とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムを送信する場合の通信線のように、短時間の間、動的にプログラムを保持するもの、その場合のサーバやクライアントとなるコンピュータシステム内部の揮発性メモリのように、一定時間プログラムを保持しているものも含んでもよい。また上記プログラムは、前述した機能の一部を実現するためのものであってもよく、さらに前述した機能をコンピュータシステムにすでに記録されているプログラムとの組み合わせで実現できるものであってもよい。
【0070】
以上、この発明の実施形態について図面を参照して詳述してきたが、具体的な構成はこの実施形態に限られるものではなく、この発明の要旨を逸脱しない範囲の設計等も含まれる。
【符号の説明】
【0071】
１…投票集計装置、２…ＳＮＳシステム、３…番組情報記憶装置、１１…取得部、１２…記憶部、１３…抽出部、１４…投票先推定部、１５…複数投票排除部、１６…組織票排除部、１７…集計部
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】