JP6101554B2 - 番組判定装置およびプログラム - Google Patents

Description

本発明は、テキストデータに基づいて放送等の対応する番組を判定するための番組判定装置およびプログラムに関する。

インターネットによる通信を用いて短文を投稿することを可能とするサービスが定着している。いわゆる短文投稿サービスにおいては、サーバー装置が、投稿された短文テキストを蓄積するとともに、多数のユーザーから投稿された短文テキストをユーザーごとの設定に応じた形で提示する。そのような短文投稿サービスは、実際に起こっている各種のイベント等と関連して多数のユーザーが共時的に且つインタラクティブに楽しむことができるという特性を有しており、テレビやラジオの放送番組との親和性も高い。一方、放送事業者や放送番組制作者にとっては、投稿される短文テキストを分析することによって、放送された番組への反響を得ることができるとともに、その分析結果をより良い番組制作に役立てることもできる。

なお、上では短文投稿サービスの場合について特に述べたが、より一般的には、ウェブを用いた各種のサービスにおいてユーザーから投稿されるテキストデータを、放送番組に対する反響の分析を行うための情報源として活用することができる。具体例としては、各種ＳＮＳ（ソーシャル・ネットワーキング・サービス）サイト、掲示板サイト、写真投稿サイト、動画投稿サイト、オンラインゲームサイトなどが該当するが、ここに挙げたものに限定されない。

上記のような各種サービス、各種サイトに投稿されるテキストデータを放送番組への反響データとして分析の対象とするためには、投稿されたテキストデータが、どの放送番組を対象としたものであるかを特定することが必要である。

特許文献１には、自然言語処理の技術であって、文脈を処理することにより省略語を補完する技術が記載されている。また、特許文献２には、自然言語処理の技術であって、シソーラスに基づいて省略語を補完する技術が記載されている。

非特許文献１には、テレビ番組に対する意見を持つツイッターユーザーを検出するために、特徴語群を設定し、それら特徴語である名詞に言及したツイートを検出する手法が記載されている。

特許第３９５２２１６号公報 特許第３３００１４２号公報

山本祐輔，外４名，「テレビ番組に対する意見を持つＴｗｉｔｔｅｒユーザーのリアルタイム検出」，ＤＥＩＭ Ｆｏｒｕｍ ２０１３ Ｃ１−４，２０１３年

テキストデータを元に、対象とする番組を特定するためには、不足している情報を補うこと、即ち省略語の補完をすることも考えられるが、特許文献１や特許文献２に記載されている技術は、前提が異なり、当該目的に適用することはできない。

また、非特許文献１に記載されているように、放送番組に特有の単語を検索語として全文検索を行い、その検索結果を当該番組に対するテキストデータとして抽出する方法では、放送番組の正式名称以外の呼称による言及や、番組名を伴わないで内容のみについての言及が多く見られるために、適切に放送番組を特定するためには、１つの番組に対して、詳細な検索条件（複数の検索語や、それらの論理積、論理輪、否定などの組合せ条件）を設定する必要がある。そのように複雑な検索条件を設定して、良好な検出精度を望むことは困難であった。例えば、視聴者の意向を把握するために、番組に関するツイートの総数を番組間で比較する場合や、シリーズ番組の時系列の変化を見たい場合は、複数の番組に対して繰り返し詳細な検索条件の作成作業をしなければならず、大きな手間がかかることは問題であった。

より具体的に課題を整理すると、（１）番組名が常に投稿されるテキストに含まれているわけではない、（２）投稿されるテキストにおいては番組名の表記には揺らぎが生じる（特に、短文投稿サイト等ではカジュアルな口語表現や略語も多用される）、（３）一つの番組であっても、放送回ごとに番組内容が異なるため、放送回ごとに対応した検索語の条件を設定するのにはコストがかかりすぎる、（４）投稿されるテキストデータの中には、番組に対して述べているものの、番組名も番組内容も明示されていない場合もある。

本発明は、上記のような課題を考慮して行われたものであり、通信を用いた各種の交流サイト等での発言から、放送番組を対象としたものを検出し、且つ対象とする番組を特定することのできる番組判定装置およびそのプログラムを提供するものである。

［１］上記の課題を解決するため、本発明の一態様による番組判定装置は、番組名の表記パターンと、番組内容を説明した番組説明文テキストと、番組の放送時間帯データとを、番組ごとに記憶する番組データ記憶部と、外部からテキストデータと、前記テキストデータに関連付けられた投稿日時データとを取得する入力部と、前記入力部が取得した前記テキストデータと、前記番組データ記憶部に記憶されている前記番組名の表記パターンとをマッチングさせることによって番組を推定する番組名マッチング部と、前記入力部が取得した前記テキストデータと、前記番組データ記憶部に記憶されている前記番組説明文テキストとの間の類似度に基づいて番組を推定する番組内容マッチング部と、前記入力部が取得した前記テキストデータに番組視聴中を表わす特定文字列が含まれているか否かと、当該テキストデータの投稿日時データと前記番組データ記憶部に記憶されている番組の放送時間帯データとの関係とに基づいて、番組を推定する時刻条件マッチング部と、前記番組名マッチング部と前記番組内容マッチング部と前記時刻条件マッチング部とのそれぞれによって推定された番組の候補の集合を基に、予め定められた所定の優先順位にしたがって、前記テキストデータが対象とする番組を判定する総合判定部と、を具備することを特徴とする。

上記の構成によれば、番組名マッチング部と番組内容マッチング部と時刻条件マッチング部とのそれぞれが、互いに異なる推定方法を用いてテキストデータが対象とする番組を推定する。また、総合判定部は、上記の各部の推定結果に基づいて、所定の優先順位やルールに従った判定を行う。これにより、多様なテキストデータに対応して、対象番組の判定を行なうことができる。また、番組名の表記の揺れにも対応して、対象番組の推定および判定を行なうことができる。

［２］また、本発明の一態様は、上記の番組判定装置において、前記番組名は、上位層の番組名と下位層の番組名とを含んでなるものであり、番組データ記憶部は、前記上位層の番組名についての前記表記パターンと、前記下位層の番組名についての番組内容を説明した前記番組説明文テキストと、前記下位層の番組名についての放送時間帯データとを記憶する、ことを特徴とする。

この構成により、番組名のマッチングについては、上位層の番組名について行う。また、番組内容のマッチングと時刻条件のマッチングについては、下位層の番組名について行う。したがって、番組名の表記パターンのデータ（例えば、正規表現など）を、下位層の番組目にいちいち対応付けて準備する必要がない。その一方で、番組内容に基づく推定や、時刻条件に基づく推定は、下位層の番組名についてきめ細かく行うことができる。

［３］また、本発明の一態様は、上記の番組判定装置において、前記総合判定部は、前記番組名マッチング部による推定結果としての番組の候補が存在する場合には当該番組を判定結果として採用するとともに、前記番組内容マッチング部による推定結果と前記時刻条件マッチング部による推定結果のいずれか矛盾しない番組を個別放送回の判定結果として採用し、また、前記番組名マッチング部による推定結果としての番組の候補が存在しない場合には、前記番組内容マッチング部による推定結果と前記時刻条件マッチング部による推定結果のいずれかの番組を判定結果として採用する、ことを特徴とする。

［４］また、本発明の一態様は、コンピュータープログラムであって、コンピューターを、番組名の表記パターンと、番組内容を説明した番組説明文テキストと、番組の放送時間帯データとを、番組ごとに記憶する番組データ記憶手段と、外部からテキストデータと、前記テキストデータに関連付けられた投稿日時データとを取得する入力手段と、前記入力手段が取得した前記テキストデータと、前記番組データ記憶手段に記憶されている前記番組名の表記パターンとをマッチングさせることによって番組を推定する番組名マッチング手段と、前記入力手段が取得した前記テキストデータと、前記番組データ記憶手段に記憶されている前記番組説明文テキストとの間の類似度に基づいて番組を推定する番組内容マッチング手段と、前記入力手段が取得した前記テキストデータに番組視聴中を表わす特定文字列が含まれているか否かと、当該テキストデータの投稿日時データと前記番組データ記憶手段に記憶されている番組の放送時間帯データとの関係とに基づいて、番組を推定する時刻条件マッチング手段と、前記番組名マッチング手段と前記番組内容マッチング手段と前記時刻条件マッチング手段とのそれぞれによって推定された番組の候補の集合を基に、予め定められた所定の優先順位にしたがって、前記テキストデータが対象とする番組を判定する総合判定手段として機能させるためのプログラムである。

本発明によれば、複数の方法による推定結果に基づいて、総合的に番組判定を行なうことができる。これにより、現実に投稿される多様なテキストデータを広くカバーして高い精度で番組判定を行なうことが出来るようになる。また、テキストデータ内に正式な番組名が明示されていなくとも、つまり、テキストデータ内で番組名の表記の揺れが生じていても、あるいは番組名が全く言及されていなくても、対象とする番組を推定することができるようになる。

本発明の一実施形態による番組判定装置の概略機能構成を示すブロック図である。 同実施形態によるテキストデータ記憶部３０のデータ構成およびデータ例の一部を示す概略図である。 同実施形態による番組データ記憶部に含まれる番組属性テーブルのデータ構成およびデータ例の一部を示す概略図である。 同実施形態による番組データ記憶部に含まれる表記パターンテーブルのデータ構成およびデータ例の一部を示す概略図である。 同実施形態による番組判定装置が番組を判定するための処理の手順を示すフローチャートである。 同実施形態による、番組名マッチング部による推定結果である番組の集合と、番組内容マッチング部による推定結果である番組の集合と、時刻条件マッチング部による推定結果である番組の集合との関係を示すベン図である。

次に、本発明の一実施形態について、図面を参照しながら説明する。
図１は、同実施形態による番組判定装置の概略機能構成を示すブロック図である。図示するように、番組判定装置１は、入力部１０と、判定部２０と、テキストデータ記憶部３０と、番組データ記憶部４２とを含んで構成される。また、判定部２０は、番組名マッチング部２２と、番組内容マッチング部２４と、時刻条件マッチング部２６と、総合判定部２８とを含んで構成される。また、番組データ記憶部４２は、内部に、番組名マッチングデータ記憶部４０と放送局送出・編成情報記憶部４１とを含んで構成される。これら各部の機能は、電子回路および記憶装置（磁気ハードディスク装置あるいは半導体メモリ等）を用いて実現される。

入力部１０は、インターネット等のネットワークを介して、外部のサーバー装置からテキストデータを取得する。入力部１０は、ＨＴＴＰ（ハイパーテキスト転送プロトコル）のクライアント機能、あるいは対象とするウェブサイトからデータを取得するための専用クライアント機能を備える。入力部１０は、一例としては、短文投稿サイトのサーバー装置から、同サイトに投稿されるすべての短文テキストを投稿単位で取得する。入力部１０が取得するデータには、各投稿のテキストデータのほかに、投稿日時（テキストデータに関連付けられた投稿日時データ）や、投稿を識別する情報や、投稿者のアカウント名などが含まれる。入力部１０は、取得したテキストデータおよびそれに付随するデータをテキストデータ記憶部３０に書き込むとともに、判定部２０に渡す。

判定部２０は、入力部１０が取得したテキストデータについて、対象とする放送番組を判定する。そのために、判定部２０は、番組名マッチング部２２と、番組内容マッチング部２４と、時刻条件マッチング部２６と、総合判定部２８とを含んで構成される。

番組名マッチング部２２は、入力部１０が取得したテキストデータと、番組名マッチングデータ記憶部４０に記憶されている番組名の表記パターンとをマッチングさせることによって番組を推定する機能を有する。
番組内容マッチング部２４は、入力部１０が取得したテキストデータと、放送局送出・編成情報記憶部４１に記憶されている番組説明文テキストとの間の類似度に基づいて番組を推定する機能を有する。
時刻条件マッチング部２６は、入力部１０が取得したテキストデータに番組視聴中を表わす特定文字列が含まれているか否かと、当該テキストデータの投稿日時データと前記放送局送出・編成情報記憶部４１に記憶されている番組の放送時間帯データとの関係とに基づいて、番組を推定する機能を有する。

総合判定部２８は、番組名マッチング部２２と番組内容マッチング部２４と時刻条件マッチング部２６とのそれぞれによって推定された番組の候補の集合を基に、予め定められた所定の優先順位にしたがって、入力部１０から入力されたテキストデータが対象とする番組を判定する。

テキストデータ記憶部３０は、入力部１０が取得したテキストデータと、そのテキストデータの投稿日時等の関連するデータとを記憶する。また、テキストデータ記憶部３０は、判定部２０内の各部による推定結果や判定結果を記憶する領域を有している。

番組名マッチングデータ記憶部４０は、番組名のレベルにおいて番組名の表記の揺れを吸収することを可能とする表記パターンを格納するための表記パターンテーブルを備えている。放送局送出・編成情報記憶部４１は、少なくとも、番組内容を説明した番組説明文テキストと、番組の放送時間帯データとを、番組ごとに記憶する。

なお、本実施形態では、放送番組を階層的に捉える。放送番組は、通常１週間を基本単位とする固定の放送スケジュール（放送枠）が決まっており、共通するコンセプトまたは構成のもと、毎回内容を変えて送出される。つまり、本実施形態は、週単位での放送スケジュールにおける枠としての「番組」（およびそれに対応する番組名）と、放送される各回ごとの「放送回」（およびそれに対応する放送回名）との階層で放送番組を捉える。この場合、番組を特定するための情報としては、番組名と放送回名の２階層の情報がある。これに加えて、例外的に、３階層の情報で番組を特定する場合もある。この場合は、番組名と放送回名の間の階層として、シリーズ名の階層を設ける。現実の放送番組の例として、このシリーズ名が存在するのは、「朝の連続テレビ小説」などである。この例では、番組名が「朝の連続テレビ小説」であり、番組名の下位のシリーズ名として例えば「純と愛」や「カーネーション」があり、各シリーズのさらに下位に放送回名がある。以下においては、番組名が３階層である場合について述べるが、この階層数は２であっても良く、また４以上であっても良い。

本実施形態では、番組名マッチングデータ記憶部４０には、番組判定装置１のために人手によって作成されたデータを格納しておく。人手によるデータ作成のコストが高い場合には更新頻度が低くても構わないように、定時番組のみを選定することも可能である。また、放送局送出・編成情報記憶部４１には、他のシステムから自動で取得できるデータを格納しておくか、他のシステムの複製を用いることができる。番組名マッチングデータ記憶部４０と放送局送出・編成情報記憶部４１は、別々のデータベースからなる構成でもよいし、単一のデータベースで構成してもよい。

また、階層構成が番組名−シリーズ名−放送回名の３階層である場合に、番組名の階層を上位層と呼び、放送回名（およびシリーズ名が存在する場合にはシリーズ名と個別放送回名）の階層を下位層と呼ぶ。

図２は、テキストデータ記憶部３０のデータ構成およびデータ例の一部を示す概略図である。図示するように、テキストデータ記憶部３０は、表形式のテーブルとして構成される。そして、このテーブルは、テキストＩＤ、サイト名、投稿日時、ＵＲＬ（ユニフォーム・リソース・ロケーター）、アカウント名、短文テキスト、番組判定結果情報の各項目を含む。そして、このテーブルの各行が投稿された一つのテキストに対応する。なお、アカウント名に相当する情報として、ユーザーＩＤ（user_id）、ユーザー名（user_name）、スクリーンネーム（screen_name）をテキストデータ記憶部３０のテーブルに持つようにしても良い。

テキストＩＤは、テキストによる投稿を一意に識別するための情報である。テキストＩＤとしては、例えば、数値情報を用いる。サイト名は、テキストが投稿された先のサービスを特定するための情報である。言い換えれば、番組判定装置１の入力部１０によるテキストの取得先のウェブサイトを識別するための情報がサイト名である。図示するデータ例では、テキストＩＤが「１２３４５６７８９０」である行のデータは、サイト名が「ＴＷ」であるサービス(短文投稿サイト)から取得したものであることを表わしている。投稿日時は、テキストデータが投稿された日時を、「ＹＹＹＹ／ＭＭ／ＤＤ ｈｈ：ｍｍ：ｓｓ」（年月日・時分秒）の形式で保持するデータである。入力部１０がテキストデータを取得する際に、この投稿日時のデータも同時に取得する。ＵＲＬは、テキストデータに対応付けられた所在情報であり、短文投稿サイトのサーバー装置上のロケーションを表わす情報である。アカウント名は、短文投稿サイトにおいてテキストを投稿したユーザーのアカウントを識別するための名前である。短文テキストは、投稿されたテキストそのもののデータである。ここでは、テキスト長は可変であり、最大１４０文字である。番組判定結果情報は、判定部２０によって用いられるデータ領域であり、判定部２０による判定の途中結果、および最終結果を格納するためのデータ領域である。

図３は、放送局送出・編成情報記憶部４１に含まれる番組属性テーブルのデータ構成およびデータ例の一部を示す概略図である。図示するように、この番組属性テーブルは、表形式のテーブルとして構成される。そして、番組構成テーブルは、番組ＩＤ、放送開始日時、放送終了日時、放送チャンネル、番組名、シリーズ名、放送回名、ＥＰＧテキスト（番組説明文）の各項目を含む。なお、「ＥＰＧ」は、Electronic Program Guide（電子番組表）を表わす。番組構成テーブルにおける各行は、「放送回名」に対応する１回の番組に対応する。つまり、前述した番組名の上位層および下位層との関連で言えば、番組属性テーブルの各行は、番組名の下位層に対応するものである。

なお、上記の放送開始日時のデータと放送終了日時のデータとを組み合わせたものが、放送時間帯を表わすデータである。

番組ＩＤは、番組名とシリーズ名と放送回名の組合せとして、番組を一意に識別するための情報である。放送開始日時は、その番組（放送回）が放送される時間帯の開始日時である。また、放送開始日時は、放送される時間帯の終了日時である。放送開始日時および放送終了日時のデータは、「ＹＹＹＹ／ＭＭ／ＤＤ ｈｈ：ｍｍ：ｓｓ」（年月日 時分秒）の形式で表わされる。放送チャンネルは、番組が放送されたチャンネルを特定するための情報である。放送チャンネルとして、図示するデータ例では「総合ＴＶ」と文字によるデータを保持するようにしているが、チャンネル番号を表わす数字などのデータを保持するようにしても良い。番組名とシリーズ名と放送回名は、前述の通り、階層構成によって放送番組の各放送回を特定するための名前の情報である。なお、シリーズ名が存在せず、番組名と放送回名の２階層の放送回を特定する場合には、シリーズ名の欄にはヌル値を格納するようにする。ＥＰＧテキストは、番組内容を説明するためのテキストデータである。ＥＰＧテキストの欄には、ＥＰＧとして提供するために準備されたテキストデータをそのまま格納しておくようにする。現在は、ＥＰＧシステムが広く普及しており、多くの番組で、このＥＰＧに掲載するためのテキストが番組制作と同時に作成されている。したがって、この番組説明文を利用すれば、本実施形態による番組判定装置１のためにわざわざ番組説明文を作成する必要はない。なお、ＥＰＧテキストは、便宜上、メタデータと呼ばれることもある。

なお、放送が行われる地域によって、チャンネルや放送時間帯が異なる場合には、上記の番組属性テーブルが地域ごとの情報を保持するようにしても良い。その場合、必要に応じて、番組属性テーブル内に、地域を表わすデータ項目を設けるようにする。

図４は、番組名マッチングデータ記憶部４０に含まれる表記パターンテーブルのデータ構成およびデータ例の一部を示す概略図である。図示するように、この表記パターンテーブルは、表形式の構造を有しており、番組名と、正規表現（regular expression）の項目を含んでいる。表記パターンテーブルの各行は、番組名に対応する（但し、シリーズ名が存在しない（ヌルである）場合もある）。つまり、前述した番組名の上位層および下位層との関連で言えば、表記パターンテーブルの各行は、番組名の上位層に対応するものである。

番組名は、前述の番組属性テーブルにおける、番組名と関連付けられるデータである。また、正規表現は、その番組名に関して、あり得る表記パターンを表わす文字列のデータである。正規表現自体は、形式言語の分野で知られている表現手段である。図示するデータ例では、表記パターンテーブルは、番組名「ためしてガッテン」に対応し得る複数の表現を表わすパターンを、正規表現の欄に保持している。言い換えれば、この正規表現は、投稿されるテキストデータにおける表記の揺れに対応し得るものである。例えば、このデータ例は、全角カタカナまたは半角カタカナによる単なる「ガッテン」という表記が、番組名「ためしてガッテン」に対応することを表わしている。また、「ためガテ」（カタカナ部分は、全角または半角のいずれかによる表記）や「ためがて」や「試ガテ」や「試がて」という表記が番組名「ためしてガッテン」に対応することを表わしている。また「＃gatten」（半角英字による表記）なども、番組名「ためしてガッテン」に対応することを表わしている。

なお、それぞれの番組名に対応する正規表現は、予め人手で作成して、表記パターンテーブルに登録しておくようにする。番組名に対してあり得る表記の揺れをカバーするような適切な正規表現を作成するには多少の熟練を要する。しかしながら、膨大な量のテキストデータを処理するために数十ないしは数百程度の番組名等に対応できる正規表現を作成することのコストは、相対的に非常に小さい。

図５は、番組判定装置１による処理の手順を示すフローチャートである。以下、このフローチャートに沿って、テキストデータを元に対象の番組を判定するための処理手順について説明する。なお、このフローチャートは、投稿されたテキストデータの１件についての処理を示す。テキストデータが複数件存在する場合には、それらのそれぞれについてこのフローチャートに示す処理を行うようにする。また、以下においては各ステップを順次処理するものとして説明するが、１件のテキストデータに対して、ステップＳ１２とＳ１３とＳ１４の処理を並列的に行うようにしても良い。また、並列処理としない場合であっても、ステップＳ１２とＳ１３とＳ１４の処理の順序を適宜入れ替えても良い。

まずステップＳ１１において、入力部１０が、外部のサーバー装置等から１件の投稿データを取得する。取得するデータは、例えば、テキスト形式、ＨＴＭＬ形式、ＸＭＬ形式などといった形式のデータである。入力部１０は、取得したデータをテキストデータ記憶部３０に書き込むとともに、番組名マッチング部２２に渡す。

次にステップＳ１２において、番組名マッチング部２２は、番組名によるマッチングを行うことにより、対象番組を推定する。具体的には、番組名マッチング部２２は、前述の表記パターンテーブルの正規表現の欄に含まれる各表現と、入力されたテキストデータ（テキストデータ記憶部３０に登録されたデータにおける項目「短文データ」のデータ）とのマッチングを図る。プレーンなテキストが所定の正規表現にマッチするか否かを判定すること自体は、既存の技術により行なうことができる。なお、マッチング対象の番組名を、テーブルに登録されているすべての番組としても良く、その投稿が行われた時点で放送されている番組に限定するようにしても良い。また、その投稿が行われた時点から前後両方に所定の時間の枠内の時間帯において放送されている番組に限定するようにしても良い。そして、マッチング処理の結果、いずれかの正規表現にマッチした場合には、番組名マッチング部２２は、その正規表現に対応する番組名を、このテキストデータの対象番組として推定する。ここで推定結果として得られる対象番組は１つとは限らず、２つ以上の対象番組候補があってもよい。推定結果として、対象番組候補が２つ以上得られる場合は、その候補をすべて出力する。いずれの正規表現にもマッチしない場合には、番組名マッチング部２２は、対象番組なしという推定結果を出力する。番組名マッチング部２２は、その推定結果である候補番組の集合の情報を、テキストデータ記憶部３０の番組判定結果情報の欄に書き込む。

番組名等は、テキストデータが対象とする番組を表す最も直接的な手掛かりである。したがって、番組名に対応する表現がテキストデータに含まれていた場合には、その判定精度はかなり高い。なお、本ステップにおいて番組名マッチング部２２が推定するのは、番組名までのレベルであり、放送回名の推定は行われない。

次にステップＳ１３において、番組内容マッチング部２４は、番組内容によるマッチングを行うことにより、対象番組を推定する。具体的には、番組内容マッチング部２４は、前述の番組属性テーブル内のＥＰＧテキスト（番組説明文）と、入力されたテキストデータ（テキストデータ記憶部３０に登録されたデータにおける項目「短文データ」のデータ）との間の類似度を算出し、類似度の高い番組を当該テキストデータに対応する推定結果とする。番組内容マッチング部２４による推定結果として出力される対象番組も、番組名マッチング部２２による推定結果と同様に、１つの候補の場合も、複数個の候補の場合もある。また、番組の候補が１つもない場合もある。番組内容マッチング部２４は、その推定結果である候補番組の集合の情報を、テキストデータ記憶部３０の番組判定結果情報の欄に書き込む。

２つのテキスト間（ここでは、ＥＰＧ用のテキストと、投稿されたテキスト）での類似の算出方法の一例は、次の通りである。即ち、一方のテキスト（ここでは、ＥＰＧテキスト）から複数の検索語を自動的に抽出し、他方のテキスト（ここでは、投稿されたテキスト）にそれらの検索語のうちの一定数以上あるいは一定比率以上が含まれている場合に、それら両テキストが類似であるとみなす。その条件を満たさない場合、即ち検索語が一定数以上あるいは一定比率以上含まれていない場合には、それら両テキストが非類似であるとみなす。なお、上記の検索語としては、例えば自立語のみを抽出したり、例えば体言のみを抽出したりする。

テキスト間の類似度の算出方法の他の例は、次の通りである。即ち、両テキストのそれぞれにおいて出現する語の頻度をカウントし、その頻度ベクトル同士のコサイン類似度を算出したり、カーネル化された内積を算出したりして、類似度とする。そして、一定値よりも高い類似度を有する番組を、当該テキスト（投稿されたテキスト）が対象とする番組の候補であると推定する。

なお、番組内容マッチング部２４が算出する類似度は、対象番組を特定するための参考とはなるものの、決定的要因とはならない。よって、番組内容マッチング部２４による推定の精度は、前述の番組名マッチング部２２による推定の精度よりは低い。しかしながら、ＥＰＧテキストは個別の放送回ごとに作成されるため、番組名までのレベルだけではなく、番組内容マッチング部２４は、放送回名（シリーズ名がある場合にはシリーズ名と放送回名）のレベルまでの推定を行うことが可能である。

次にステップＳ１４において、時刻条件マッチング部２６は、時刻条件により対象の番組の推定を行う。具体的には、時刻条件マッチング部２６は、投稿されたテキストデータ中に、放送番組を視聴中であることを示す特定の文字列が含まれている場合に、その投稿日時において放送されていた番組を、当該テキストデータが対象とする番組であると推定する。ここで、視聴中であることを示す文字列（特定文字列）とは、例えば「視聴中」や「見てるなう」などといった文字列であり、予め定めておくようにする。また、放送チャンネル番号や放送局名などに対応する文字列（短文投稿サイトで用いられるハッシュタグの類を含む）とのマッチングを同時に行うようにしても良い。なお、投稿日時は元のサービス（短文投稿サービス等）のサーバー側において付与され、入力部１０が取得するデータにもその投稿日時が含まれている。また、この投稿日時のデータは、テキストデータ記憶部３０の投稿日時の欄にも格納されている。なお、放送時間帯と投稿日時との間に若干の時間的なずれが生じる可能性もあるため、投稿日時において放送されていた番組だけでなく、その前後の番組をも候補として推定するようにしても良い。また、放送チャンネルあるいは放送局名などに対応する文字が投稿されたテキストデータ中に含まれていなかったときには、複数のチャンネルの番組を候補として推定するようにしても良い。時刻条件マッチング部２６による推定結果として出力される対象番組は、番組名マッチング部２２や番組内容マッチング部２４による推定結果と同様に、１つの候補の場合も、複数個の候補の場合もある。また、番組の候補が１つもない場合もある。時刻条件マッチング部２６は、その推定結果である候補番組の集合の情報を、テキストデータ記憶部３０の番組判定結果情報の欄に書き込む。

時刻条件マッチング部２６による推定結果では、最終的に一つの番組に絞りきれない場合もある。また、時刻条件マッチング部２６は、番組名までのレベルだけではなく、放送回名（シリーズ名がある場合にはシリーズ名と放送回名）のレベルまでの推定を行うことが可能である。時刻条件マッチング部２６が対象番組候補を１つに絞りきれない事例は、１つの放送事業者が複数の異なる番組を同時に放送する場合に生じる。例えば、「ＮＨＫなう。」というテキストによる投稿があった場合に、その対象の番組が、当該発言時刻における総合テレビの番組であるか教育テレビの番組であるかは、そのテキストデータだけからは決定できない。但し、当該投稿のテキストデータ内に、番組名マッチング部２２または番組内容マッチング部２４の機能によって、それら複数のうちのいずれかとマッチする表現等が含まれている場合には、後述の総合判定部２８による処理によって、適切な番組が判定結果として得られる。

次にステップＳ１５において、総合判定部２８は、上記のステップＳ１２からＳ１４までの推定結果を用いながら、総合的な判定を行う。そして、総合判定部２８は、総合的な判定結果をテキストデータ記憶部３０の番組判定結果情報の欄に書き込む。具体的な総合判定の手順については、図６を参照しながら、以下で説明する。

図６は、ある１つの入力テキストデータに対して、番組名マッチング部２２と、番組内容マッチング部２４と、時刻条件マッチング部２６とのそれぞれが推定した番組名の集合の関係を表わすベン図である。同図において、符号２２ａは、番組名マッチング部２２によって推定された番組名の集合である。この集合の要素の個数は０個以上である。なお、この集合においては、番組名が特定されており、放送回名（シリーズ名が存在する場合にはシリーズ名と放送回目）は特定されていない。また、符号２４ａは、番組内容マッチング部２４によって推定された番組名の集合である。この集合の要素の個数は０個以上である。なお、この集合においては、放送回名のレベルまでが特定されている。また、符号２６ａは、時刻条件マッチング部２６によって推定された番組名の集合である。この集合の要素の個数は０個以上である。なお、この集合においては、放送回名のレベルまでが特定されている。

総合判定手順１： 総合判定部２８は、上位階層の単位である番組名から決定する。総合判定部２８が番組名を特定する際の、優先順位は、番組名マッチング部２２による推定＞番組内容マッチング部２４による推定＞時刻条件マッチング部２６による推定、の順である（不等号の開いている側（左側）が優先順位の上位）。但し、番組名マッチング部２２による推定のみでは、下位階層である個別の放送回名に関する情報は得られないので、番組名マッチング部２２による推定結果と矛盾しない番組名が番組内容マッチング部２４による推定または時刻条件マッチング部２６による推定で得られた場合に限り、そこで得られた個別の放送回名（シリーズ名が存在する場合にはシリーズ名と放送回名）をあわせて総合判定の結果とする（ここで、番組内容マッチング部２４による推定と時刻条件マッチング部２６による推定との間で矛盾が生じる場合には、前者の番組内容マッチング部２４による推定を優先させる）。ここで、番組名マッチング部２２による推定結果が、番組内容マッチング部２４による推定結果または時刻条件マッチング部２６による推定結果と矛盾しないということは、集合２２ａと集合２４ａの共通部分が要素を有する（空集合ではない）、または集合２２ａと集合２６ａの共通部分が要素を有する（空集合ではない）、ということである。つまり、総合判定部２８は、番組名マッチング部２２による推定結果（番組名）を、番組内容マッチング部２４による推定結果または時刻条件マッチング部２６による推定結果（放送回名またはシリーズ名と放送回名）で補完する。

総合判定手順２： 総合判定部２８は、番組名マッチング部２２による推定結果が得られず（つまり集合２２ａの要素が０個）、番組内容マッチング部２４による推定結果または時刻条件マッチング部２６による推定結果として番組名（個別の放送回名までのレベル）が得られた場合には、そこで得られた番組名と、（シリーズ名がある場合には）シリーズ名と、放送回名とを、判定結果として採用する。なおここでも、番組内容マッチング部２４による推定結果または時刻条件マッチング部２６による推定結果とが矛盾する場合には、前者の番組内容マッチング部２４による推定結果を優先させる。

総合判定手順３： 総合判定部２８は、番組名マッチング部２２による推定結果のみが得られて（つまり集合２２ａの要素が１個以上）、番組内容マッチング部２４による推定結果も時刻条件マッチング部２６による推定結果も得られなかった場合（つまり、集合２４ａの要素数も０個で、集合２６ａの要素数も０個の場合）には、番組名マッチング部２２による推定結果のみを判定結果として出力することとし、個別の放送回名を不明として出力する。

総合判定手順４： また、総合判定部２８は、番組名マッチング部２２による推定結果が得られて（つまり集合２２ａの要素が１個以上）、番組内容マッチング部２４による推定結果も時刻条件マッチング部２６による推定結果も番組名マッチング部２２による推定結果と矛盾する場合には、上の総合判定手順３と同様に、番組名マッチング部２２による推定結果のみを判定結果として出力することとし、個別の放送回名を不明として出力する。

総合判定手順５： 上の総合判定手順１から４までの結果としてなお複数の候補が残った場合は、ＳＮＳ等における投稿のリアルタイム性（投稿内容と発信時刻に強い相関があること）を重視し、ツイート発信時刻に最も近い候補をその判定法における代表とする。つまり、番組名マッチング部２２による推定結果と、番組内容マッチング部２４による推定結果と、時刻条件マッチング部２６による推定結果に共通する番組の候補が２個以上ある場合には、ツイート発信時刻に最も近い候補を代表として、総合判定の結果とする。

上記の総合判定手順１から５までの説明を集合論的に言い換えると、次の通りである。即ち、集合２２ａと集合２４ａとの間の共通部分に集合の要素が存在する場合、その共通部分の候補を採用する。これは、図中の「α」で示す部分と「β」で示す部分との和集合にあたる。

集合２２ａと集合２４ａとの間の共通部分に集合の要素が存在しない場合、集合２２ａと集合２６ａの共通部分に集合の要素が存在するか否かを調べる。その共通部分に集合の要素が存在する場合、その共通部分の候補を採用する。これは、図中の「γ」で示す部分である（「β」の部分が上記の通り空集合であるから）。

上述した「β」の部分に集合の要素がなく、「α」および「γ」の部分のそれぞれに集合の要素がある場合には、「γ」の部分に含まれる要素よりも、「α」の部分に含まれる要素を、番組の判定結果として優先させる。その理由は、番組内容マッチング部のほうが時刻条件マッチング部よりも精度が高いからである。
また、上述した「α」と「β」と「γ」のいずれの部分にも集合の要素がない場合には、集合２２ａの要素＞集合２４ａの要素＞集合２６ａの要素の優先順にしたがって、総合判定の結果として出力する。

以上述べたように、総合判定部２８は、番組名マッチング部２２と番組内容マッチング部２４と時刻条件マッチング部２６とのそれぞれによって推定された番組の候補の集合を基に、予め定められた所定の優先順位にしたがって、対象とする番組を判定する。
また、総合判定部２８は、番組名マッチング部２２による推定結果としての番組の候補が存在する場合には当該番組を判定結果として採用し、番組内容マッチング部２４による推定結果と時刻条件マッチング部２６による推定結果のいずれか矛盾しない番組を個別放送回の判定結果として採用する。また、番組名マッチング部２２による推定結果としての番組の候補が存在しない場合には、総合判定部２８は、番組内容マッチング部２４による推定結果と時刻条件マッチング部２６による推定結果のいずれかの番組を判定結果として採用する。

図５に戻り、ステップＳ１５の処理が終了すると、番組判定装置１は、当該テキストデータに関する番組判定の処理を終了する。

なお、上述した実施形態における番組判定装置の機能の一部または全部をコンピューターで実現するようにしても良い。その場合、この制御機能を実現するためのプログラムをコンピューター読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピューターシステムに読み込ませ、実行することによって実現しても良い。なお、ここでいう「コンピューターシステム」とは、ＯＳや周辺機器等のハードウェアを含むものとする。また、「コンピューター読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ＲＯＭ、ＣＤ−ＲＯＭ等の可搬媒体、コンピューターシステムに内蔵されるハードディスク等の記憶装置のことをいう。さらに「コンピューター読み取り可能な記録媒体」とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムを送信する場合の通信線のように、短時間の間、動的にプログラムを保持するもの、その場合のサーバーやクライアントとなるコンピューターシステム内部の揮発性メモリのように、一定時間プログラムを保持しているものも含んでも良い。また上記プログラムは、前述した機能の一部を実現するためのものであっても良く、さらに前述した機能をコンピューターシステムにすでに記録されているプログラムとの組み合わせで実現できるものであっても良い。

以上、この発明の実施形態について図面を参照して詳述してきたが、具体的な構成はこの実施形態に限られるものではなく、この発明の要旨を逸脱しない範囲の設計等も含まれる。

本発明は、産業としては、放送番組等の分析（番組間の統計的比較分析などを含む）や、放送視聴者の動向の把握・分析や、社会動向・社会ニーズの分析や、マーケティングや、広告、番組推薦などに利用することが可能である。

短文投稿サービスなどのＳＮＳを利用して、関連する投稿数の多い対象番組を抽出して番組推薦に利用することもできる。また、そのとき、ユーザー間のつながりの関係（友人関係や、フォロー／被フォローの関係）を併用することによって、あるユーザーに着目したとき、そのユーザーにつながっている他のユーザーによる投稿数の多い対象番組を、そのユーザーに推薦するといった利用方法も考えられる。

１ 番組判定装置
１０ 入力部
２０ 判定部
２２ 番組名マッチング部
２４ 番組内容マッチング部
２６ 時刻条件マッチング部
２８ 総合判定部
３０ テキストデータ記憶部
４０ 番組名マッチングデータ記憶部
４１ 放送局送出・編成情報記憶部
４２ 番組データ記憶部

Claims (4)

1. 番組名の表記パターンと、番組内容を説明した番組説明文テキストと、番組の放送時間帯データとを、番組ごとに記憶する番組データ記憶部と、
   外部からテキストデータと、前記テキストデータに関連付けられた投稿日時データとを取得する入力部と、
   前記入力部が取得した前記テキストデータと、前記番組データ記憶部に記憶されている前記番組名の表記パターンとをマッチングさせることによって番組を推定する番組名マッチング部と、
   前記入力部が取得した前記テキストデータと、前記番組データ記憶部に記憶されている前記番組説明文テキストとの間の類似度に基づいて番組を推定する番組内容マッチング部と、
   前記入力部が取得した前記テキストデータに番組視聴中を表わす特定文字列が含まれているか否かと、当該テキストデータの投稿日時データと前記番組データ記憶部に記憶されている番組の放送時間帯データとの関係とに基づいて、番組を推定する時刻条件マッチング部と、
   前記番組名マッチング部と前記番組内容マッチング部と前記時刻条件マッチング部とのそれぞれによって推定された番組の候補の集合を基に、予め定められた所定の優先順位にしたがって、前記テキストデータが対象とする番組を判定する総合判定部と、
   を具備することを特徴とする番組判定装置。
2. 前記番組名は、上位層の番組名と下位層の番組名とを含んでなるものであり、
   番組データ記憶部は、前記上位層の番組名についての前記表記パターンと、前記下位層の番組名についての番組内容を説明した前記番組説明文テキストと、前記下位層の番組名についての放送時間帯データとを記憶する、
   ことを特徴とする請求項１に記載の番組判定装置。
3. 前記総合判定部は、前記番組名マッチング部による推定結果としての番組の候補が存在する場合には当該番組を判定結果として採用するとともに、前記番組内容マッチング部による推定結果と前記時刻条件マッチング部による推定結果のいずれか矛盾しない番組を個別放送回の判定結果として採用し、また、前記番組名マッチング部による推定結果としての番組の候補が存在しない場合には、前記番組内容マッチング部による推定結果と前記時刻条件マッチング部による推定結果のいずれかの番組を判定結果として採用する、
   ことを特徴とする請求項１または２のいずれか一項に記載の番組判定装置。
4. コンピューターを、
   番組名の表記パターンと、番組内容を説明した番組説明文テキストと、番組の放送時間帯データとを、番組ごとに記憶する番組データ記憶手段と、
   外部からテキストデータと、前記テキストデータに関連付けられた投稿日時データとを取得する入力手段と、
   前記入力手段が取得した前記テキストデータと、前記番組データ記憶手段に記憶されている前記番組名の表記パターンとをマッチングさせることによって番組を推定する番組名マッチング手段と、
   前記入力手段が取得した前記テキストデータと、前記番組データ記憶手段に記憶されている前記番組説明文テキストとの間の類似度に基づいて番組を推定する番組内容マッチング手段と、
   前記入力手段が取得した前記テキストデータに番組視聴中を表わす特定文字列が含まれているか否かと、当該テキストデータの投稿日時データと前記番組データ記憶手段に記憶されている番組の放送時間帯データとの関係とに基づいて、番組を推定する時刻条件マッチング手段と、
   前記番組名マッチング手段と前記番組内容マッチング手段と前記時刻条件マッチング手段とのそれぞれによって推定された番組の候補の集合を基に、予め定められた所定の優先順位にしたがって、前記テキストデータが対象とする番組を判定する総合判定手段と、
   として機能させるためのプログラム。

Images