(57)【特許請求の範囲】
【請求項１】
複数の形態素とその出現回数とを対応付けた許可ワードテーブルを保持するテーブル保持部と、
放送倫理規定に沿って生成された番組ストリームを取得する番組ストリーム取得部と、
取得された前記番組ストリームに字幕データまたは番組の内容に関する第１のテキストデータである番組情報が含まれている場合、前記番組ストリームから前記字幕データまたは前記番組情報を抽出し、形態素に分割して、分割した前記形態素が前記許可ワードテーブルに無ければ、その形態素を前記許可ワードテーブルに登録し、分割した前記形態素が前記許可ワードテーブルに有れば、前記形態素に対応した出現回数を更新するテーブル更新部と、
取得された番組ストリームに含まれる番組を保持する番組保持部と、
保持された前記番組に関する第２のテキストデータを取得すると共に、取得日時情報を関連付けるデータ取得部と、
前記第２のテキストデータを形態素に分割し、分割した前記形態素が前記許可ワードテーブルに登録されていない、または、分割した前記形態素が前記許可ワードテーブルに登録されているが、その形態素に対応した出現回数が予め定められた第１閾値未満であれば、前記形態素を、予め定められた記号に置換し、第３のテキストデータとして再結合するデータ加工部と、
保持された前記番組に、再結合した前記第３のテキストデータと、この第３のテキストデータに対応する前記第２のテキストデータに関連付けられた前記取得日時情報との組をインデックスデータとして付与するインデックス付与部と、
検索のため入力されたキーワードと前記インデックスデータとに基づいて、前記番組保持部に保持された番組または番組内の所定シーンを抽出する番組抽出部と、
を備えることを特徴とする番組検索装置。
【請求項２】
複数の形態素とその出現回数とを対応付けた許可ワードテーブルを保持するテーブル保持部と、
放送倫理規定に沿って生成された、番組の内容に関する第１のテキストデータである番組情報を取得する番組情報取得部と、
前記番組情報を形態素に分割し、分割した前記形態素が前記許可ワードテーブルに無ければ、その形態素を前記許可ワードテーブルに登録し、分割した前記形態素が前記許可ワードテーブルに有れば、前記形態素に対応した出現回数を更新するテーブル更新部と、
取得された番組ストリームに含まれる番組を保持する番組保持部と、
保持された前記番組に関する第２のテキストデータを取得すると共に、取得日時情報を関連付けるデータ取得部と、
前記第２のテキストデータを形態素に分割し、分割した前記形態素が前記許可ワードテーブルに登録されていない、または、分割した前記形態素が前記許可ワードテーブルに登録されているが、その形態素に対応した出現回数が予め定められた第１閾値未満であれば、前記形態素を、予め定められた記号に置換し、第３のテキストデータとして再結合するデータ加工部と、
保持された前記番組に、再結合した前記第３のテキストデータと、この第３のテキストデータに対応する前記第２のテキストデータに関連付けられた前記取得日時情報との組をインデックスデータとして付与するインデックス付与部と、
検索のため入力されたキーワードと前記インデックスデータとに基づいて、前記番組保持部に保持された番組または番組内の所定シーンを抽出する番組抽出部と、
を備えることを特徴とする番組検索装置。
【請求項３】
前記インデックス付与部は、保持された前記番組に字幕データが付加されていれば、その字幕データをインデックスデータとして前記番組に付与し、前記番組に字幕データが付加されていなければ、または、字幕データが付加されていないとみなせれば、再結合した前記第３のテキストデータをインデックスデータとして前記番組に付与することを特徴とする請求項１または２に記載の番組検索装置。
【請求項４】
前記インデックス付与部は、１秒あたりの字幕データ数である字幕率が予め定められた第２閾値未満であれば、前記番組に字幕データが付加されていないとみなすことを特徴とする請求項３に記載の番組検索装置。
【請求項５】
番組を検索する番組検索装置において実行される番組検索方法であって、
前記番組検索装置が、
取得した放送倫理規定に沿って生成された番組ストリームを取得する番組ストリーム取得ステップ、
取得した前記番組ストリームに字幕データまたは番組の内容に関する第１のテキストデータである番組情報が含まれている場合、前記番組ストリームから前記字幕データまたは前記番組情報を抽出し、形態素に分割して、分割した前記形態素が、複数の形態素とその出現回数とを対応付けた許可ワードテーブルに無ければ、その形態素を前記許可ワードテーブルに登録し、分割した前記形態素が前記許可ワードテーブルに有れば、前記形態素に対応した出現回数を更新するテーブル更新ステップ、
取得した番組ストリームに含まれる番組を番組保持部に保持させる番組保持ステップ、
保持した前記番組に関する第２のテキストデータを取得すると共に、取得日時情報を関連付けるデータ取得ステップ、
前記第２のテキストデータを形態素に分割し、分割した前記形態素が前記許可ワードテーブルに登録されていない、または、分割した前記形態素が前記許可ワードテーブルに登録されているが、その形態素に対応した出現回数が予め定められた第１閾値未満であれば、前記形態素を、予め定められた記号に置換し、第３のテキストデータとして再結合するデータ加工ステップ、
保持した前記番組に、再結合した前記第３のテキストデータと、この第３のテキストデータに対応する前記第２のテキストデータに関連付けられた前記取得日時情報との組をインデックスデータとして付与するインデックス付与ステップ、
検索のため入力されたキーワードと前記インデックスデータとに基づいて、前記番組保持部に保持された番組または番組内の所定シーンを抽出する番組抽出ステップ、
を含むことを特徴とする番組検索方法。
【請求項６】
番組を検索する番組検索装置において実行される番組検索方法であって、
前記番組検索装置が、
放送倫理規定に沿って生成された、番組の内容に関する第１のテキストデータである番組情報を取得する番組情報取得ステップ、
前記番組情報を形態素に分割し、分割した前記形態素が、複数の形態素とその出現回数とを対応付けた許可ワードテーブルに無ければ、その形態素を前記許可ワードテーブルに登録し、分割した前記形態素が前記許可ワードテーブルに有れば、前記形態素に対応した出現回数を更新するテーブル更新ステップ、
取得した番組ストリームに含まれる番組を番組保持部に保持させる番組保持ステップ、
保持した前記番組に関する第２のテキストデータを取得すると共に、取得日時情報を関連付けるデータ取得ステップ、
前記第２のテキストデータを形態素に分割し、分割した前記形態素が前記許可ワードテーブルに登録されていない、または、分割した前記形態素が前記許可ワードテーブルに登録されているが、その形態素に対応した出現回数が予め定められた第１閾値未満であれば、前記形態素を、予め定められた記号に置換し、第３のテキストデータとして再結合するデータ加工ステップ、
保持した前記番組に、再結合した前記第３のテキストデータと、この第３のテキストデータに対応する前記第２のテキストデータに関連付けられた前記取得日時情報との組をインデックスデータとして付与するインデックス付与ステップ、
検索のため入力されたキーワードと前記インデックスデータとに基づいて、前記番組保持部に保持された番組または番組内の所定シーンを抽出する番組抽出ステップ、
を含むことを特徴とする番組検索方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、任意の手順に従ってテキストデータを加工し、インデックスデータとして検索に用いる番組検索装置および番組検索方法に関する。
【背景技術】
【０００２】
テレビジョン放送において、日々放送される番組を一旦装置に蓄積し、ユーザがその蓄積された番組を事後的に視聴できる技術が従来から利用されている。ここで、番組に字幕データが付加されている場合（文字多重放送）、その字幕データをインデックスデータとして番組や番組内の所定シーンに関連付けると、番組検索装置は、インデックスデータに対してキーワード検索することで、蓄積された番組の中からユーザが所望する番組や番組内の所定シーンを迅速に抽出することができる。
【０００３】
また、辞書データ等に基づき任意の文字列とその文字列を説明する文章とを関連付けてデータベース装置に保持しておき、番組の字幕データを取得した際に、その字幕データを、形態素に分割し、その形態素とデータベース装置に保持された文字列とを比較して一致する形態素のみを強調表示する技術が知られている（例えば、特許文献１）。ユーザは、その強調表示された形態素を選択するだけで、データベース装置に蓄積されたその形態素を説明する文章を参照することが可能となる。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特許第３５３８９５５号
【発明の概要】
【発明が解決しようとする課題】
【０００５】
今日、地上波アナログ放送から地上波デジタル放送への移行が進んでおり、地上波デジタル放送では、番組と共に字幕データや番組情報が番組ストリームとして多重化されて放送されることが多く、字幕データや番組情報を、検索用のインデックスデータとして利用する上述した技術がより効果的に用いられることが予想される。
【０００６】
しかしながら、地上波デジタル放送であっても番組に必ず字幕データが付加されているとは限らず、例えば、ニュースや生放送といったような、予めその放送内容を提示できないものに関しては、字幕データが含まれていない、または、含まれていたとしても表題等の極限られた情報である。
【０００７】
したがって、装置に蓄積された複数の番組には、字幕データを含む（付加されている）番組と字幕データを含まない（付加されていない）番組とが混在し、換言すれば、インデックスデータが付された番組とインデックスデータのない番組が混在することとなり、後者の番組は検索対象にすらならないので、視聴対象として抽出されにくくなる。こうして、蓄積された番組や番組内の所定シーンを検索しても、所望する番組や番組内の所定シーンを適切に抽出できない場合が生じ得る。
【０００８】
そこで本発明は、このような課題に鑑み、字幕データの有無に拘わらず、番組や番組内の所定シーンを適切に検索することが可能な、番組検索装置および番組検索方法を提供することを目的としている。
【課題を解決するための手段】
【０００９】
上記課題を解決するために、本発明は下記の番組検索装置および番組検索方法を提供するものである。
（１）複数の形態素とその出現回数とを対応付けた許可ワードテーブルを保持するテーブル保持部と、放送倫理規定に沿って生成された番組ストリームを取得する番組ストリーム取得部と、取得された前記番組ストリームに字幕データまたは番組の内容に関する第１のテキストデータである番組情報が含まれている場合、前記番組ストリームから前記字幕データまたは前記番組情報を抽出し、形態素に分割して、分割した前記形態素が前記許可ワードテーブルに無ければ、その形態素を前記許可ワードテーブルに登録し、分割した前記形態素が前記許可ワードテーブルに有れば、前記形態素に対応した出現回数を更新するテーブル更新部と、取得された番組ストリームに含まれる番組を保持する番組保持部と、保持された前記番組に関する第２のテキストデータを取得すると共に、取得日時情報を関連付けるデータ取得部と、前記第２のテキストデータを形態素に分割し、分割した前記形態素が前記許可ワードテーブルに登録されていない、または、分割した前記形態素が前記許可ワードテーブルに登録されているが、その形態素に対応した出現回数が予め定められた第１閾値未満であれば、前記形態素を、予め定められた記号に置換し、第３のテキストデータとして再結合するデータ加工部と、保持された前記番組に、再結合した前記第３のテキストデータと、この第３のテキストデータに対応する前記第２のテキストデータに関連付けられた前記取得日時情報との組をインデックスデータとして付与するインデックス付与部と、検索のため入力されたキーワードと前記インデックスデータとに基づいて、前記番組保持部に保持された番組または番組内の所定シーンを抽出する番組抽出部と、を備えることを特徴とする番組検索装置。
（２）複数の形態素とその出現回数とを対応付けた許可ワードテーブルを保持するテーブル保持部と、放送倫理規定に沿って生成された、番組の内容に関する第１のテキストデータである番組情報を取得する番組情報取得部と、前記番組情報を形態素に分割し、分割した前記形態素が前記許可ワードテーブルに無ければ、その形態素を前記許可ワードテーブルに登録し、分割した前記形態素が前記許可ワードテーブルに有れば、前記形態素に対応した出現回数を更新するテーブル更新部と、取得された番組ストリームに含まれる番組を保持する番組保持部と、保持された前記番組に関する第２のテキストデータを取得すると共に、取得日時情報を関連付けるデータ取得部と、前記第２のテキストデータを形態素に分割し、分割した前記形態素が前記許可ワードテーブルに登録されていない、または、分割した前記形態素が前記許可ワードテーブルに登録されているが、その形態素に対応した出現回数が予め定められた第１閾値未満であれば、前記形態素を、予め定められた記号に置換し、第３のテキストデータとして再結合するデータ加工部と、保持された前記番組に、再結合した前記第３のテキストデータと、この第３のテキストデータに対応する前記第２のテキストデータに関連付けられた前記取得日時情報との組をインデックスデータとして付与するインデックス付与部と、検索のため入力されたキーワードと前記インデックスデータとに基づいて、前記番組保持部に保持された番組または番組内の所定シーンを抽出する番組抽出部と、を備えることを特徴とする番組検索装置。
（３）前記インデックス付与部は、保持された前記番組に字幕データが付加されていれば、その字幕データをインデックスデータとして前記番組に付与し、前記番組に字幕データが付加されていなければ、または、字幕データが付加されていないとみなせれば、再結合した前記第３のテキストデータをインデックスデータとして前記番組に付与することを特徴とする上記（１）または（２）に記載の番組検索装置。
（４）前記インデックス付与部は、１秒あたりの字幕データ数である字幕率が予め定められた第２閾値未満であれば、前記番組に字幕データが付加されていないとみなすことを特徴とする上記（３）に記載の番組検索装置。
（５）番組を検索する番組検索装置において実行される番組検索方法であって、前記番組検索装置が、取得した放送倫理規定に沿って生成された番組ストリームを取得する番組ストリーム取得ステップ、取得した前記番組ストリームに字幕データまたは番組の内容に関する第１のテキストデータである番組情報が含まれている場合、前記番組ストリームから前記字幕データまたは前記番組情報を抽出し、形態素に分割して、分割した前記形態素が、複数の形態素とその出現回数とを対応付けた許可ワードテーブルに無ければ、その形態素を前記許可ワードテーブルに登録し、分割した前記形態素が前記許可ワードテーブルに有れば、前記形態素に対応した出現回数を更新するテーブル更新ステップ、取得した番組ストリームに含まれる番組を番組保持部に保持させる番組保持ステップ、保持した前記番組に関する第２のテキストデータを取得すると共に、取得日時情報を関連付けるデータ取得ステップ、前記第２のテキストデータを形態素に分割し、分割した前記形態素が前記許可ワードテーブルに登録されていない、または、分割した前記形態素が前記許可ワードテーブルに登録されているが、その形態素に対応した出現回数が予め定められた第１閾値未満であれば、前記形態素を、予め定められた記号に置換し、第３のテキストデータとして再結合するデータ加工ステップ、保持した前記番組に、再結合した前記第３のテキストデータと、この第３のテキストデータに対応する前記第２のテキストデータに関連付けられた前記取得日時情報との組をインデックスデータとして付与するインデックス付与ステップ、検索のため入力されたキーワードと前記インデックスデータとに基づいて、前記番組保持部に保持された番組または番組内の所定シーンを抽出する番組抽出ステップ、を含むことを特徴とする番組検索方法。
（６）番組を検索する番組検索装置において実行される番組検索方法であって、前記番組検索装置が、放送倫理規定に沿って生成された、番組の内容に関する第１のテキストデータである番組情報を取得する番組情報取得ステップ、前記番組情報を形態素に分割し、分割した前記形態素が、複数の形態素とその出現回数とを対応付けた許可ワードテーブルに無ければ、その形態素を前記許可ワードテーブルに登録し、分割した前記形態素が前記許可ワードテーブルに有れば、前記形態素に対応した出現回数を更新するテーブル更新ステップ、取得した番組ストリームに含まれる番組を番組保持部に保持させる番組保持ステップ、保持した前記番組に関する第２のテキストデータを取得すると共に、取得日時情報を関連付けるデータ取得ステップ、前記第２のテキストデータを形態素に分割し、分割した前記形態素が前記許可ワードテーブルに登録されていない、または、分割した前記形態素が前記許可ワードテーブルに登録されているが、その形態素に対応した出現回数が予め定められた第１閾値未満であれば、前記形態素を、予め定められた記号に置換し、第３のテキストデータとして再結合するデータ加工ステップ、保持した前記番組に、再結合した前記第３のテキストデータと、この第３のテキストデータに対応する前記第２のテキストデータに関連付けられた前記取得日時情報との組をインデックスデータとして付与するインデックス付与ステップ、検索のため入力されたキーワードと前記インデックスデータとに基づいて、前記番組保持部に保持された番組または番組内の所定シーンを抽出する番組抽出ステップ、を含むことを特徴とする番組検索方法。
【発明の効果】
【００１０】
本発明によれば、字幕データの有無に拘わらず、番組や番組内の所定シーンを適切に検索することが可能となる。
【図面の簡単な説明】
【００１１】
【図１】第１の実施形態における番組提供システムの概略的な接続関係を示した説明図である。
【図２】フィルタリング装置の概略的な構成を示した機能ブロック図である。
【図３】許可ワードテーブルを説明するための説明図である。
【図４】投稿データをレンダリングする例を示した説明図である。
【図５】フィルタリング方法の処理の流れを説明したフローチャートである。
【図６】テーブル更新部の処理を説明するための説明図である。
【図７】フィルタリング方法の処理の流れを説明したフローチャートである。
【図８】投稿データ群を例示した説明図である。
【図９】データ加工部の処理を説明するための説明図である。
【図１０】第２の実施形態における番組提供システムの概略的な接続関係を示した説明図である。
【図１１】番組検索装置の概略的な構成を示した機能ブロック図である。
【図１２】番組検索方法の処理の流れを説明したフローチャートである。
【図１３】番組付加データのうちの字幕データの一例を示した説明図である。
【図１４】番組検索方法の処理の流れを説明したフローチャートである。
【図１５】検索リストの表示例を示した説明図である。
【図１６】表示装置での表示例を示した説明図である。
【発明を実施するための形態】
【００１２】
以下に添付図面を参照しながら、本発明の好適な実施形態について詳細に説明する。かかる実施形態に示す寸法、材料、その他具体的な数値などは、発明の理解を容易とするための例示にすぎず、特に断る場合を除き、本発明を限定するものではない。なお、本明細書及び図面において、実質的に同一の機能、構成を有する要素については、同一の符号を付することにより重複説明を省略し、また本発明に直接関係のない要素は図示を省略する。
【００１３】
ここでは、第１の実施形態として、任意のテキストデータを適切にフィルタリングするフィルタリング装置およびフィルタリング方法を説明し、第２の実施形態として、第１の実施形態におけるフィルタリング技術を用い、番組およびその番組内の所定シーンを適切に検索する番組検索装置および番組検索方法を説明する。両実施形態は少なくともフィルタリング技術に関して共通している。
【００１４】
フィルタリング技術としては、一般的に、サービスに使用すべきではない、公序良俗に反する単語（禁止ワード）をテーブル化した禁止ワードテーブルを用いることが多く、サービス提供者は、禁止ワードテーブルを参照して、例えば、電子掲示板に投稿された投稿データに対し禁止ワードに該当する単語を排除するといったフィルタリングを実行している。しかし、この禁止ワードを排除するフィルタリングでは、禁止ワードを他の漢字（当て字）に変更したり、文字間に空白や記号を挿入したりして、その単語に「ゆらぎ」を加え、禁止ワードに一致させないようにすることで、フィルタリングされるのを容易に回避することができる。
【００１５】
これは、禁止ワードに該当する単語を当て字に変更したり、記号を加えても、その単語の意味するところを他人に伝達できることに因る。そうすると、禁止すべき単語は、禁止ワード毎に相異なる表示態様が無数あることになり、サービス提供者は、禁止ワード自体を特定、排除できたとしても、その禁止ワードに対する無数の表示態様を全て排除することはできない。
【００１６】
このような禁止ワードの無数の表示態様までを排除するには、禁止ワードをテーブル化した禁止ワードテーブルではなく、許可可能な単語（許可ワード）をテーブル化した許可ワードテーブルを用いて、公序良俗に反していない単語や文章のみを残すようにすればよい。しかし、人物や建造物といった単語は、日々新たに出現しており、このような許可ワードがフィルタリングによって排除されないようにするには、許可ワードテーブルの更新頻度を高めなくてはならない。
【００１７】
しかし、現状では、許可ワードテーブルを利用しているサービス提供者はなく、許可ワードテーブルを各ユーザの情報端末に配信するシステムは構築されていない。そもそも、ワードテーブルを生成する上で、禁止ワードテーブルに対し許可ワードテーブルの必要単語数は著しく多く、例えば、１ヶ月に生じる禁止ワードが約４０００ワードであるのに対して、許可ワードは約４００万ワードであり、そのワードテーブルの配信や更新に膨大なコストを要することとなるので、許可ワードテーブルを用いるのは現実的ではなかった。
【００１８】
そこで、第１の実施形態では、テレビジョン放送等の番組提供システムを用いて、フィルタリングのための許可ワードテーブルを自動的に形成する。
【００１９】
（第１の実施形態：番組提供システム１００）
図１は、第１の実施形態における番組提供システム１００の概略的な接続関係を示した説明図である。番組提供システム１００は、番組提供装置１１０と、フィルタリング装置１２０と、表示装置１３０と、サービス提供サーバ１４０とを含んで構成される。
【００２０】
番組提供装置１１０は、放送局１１２や番組提供サーバ１１４で構成され、番組ストリームを配信する。番組ストリームには、番組そのものに加えて、番組に関する様々な情報が付加データとして含まれている。
【００２１】
フィルタリング装置１２０は、番組提供装置１１０としての放送局１１２からアンテナ１２２を通じて、また、番組提供装置１１０としての番組提供サーバ１１４からインターネット等の通信網１２４を通じて、地上波デジタル放送、ＢＳ・ＣＳデジタル放送、ケーブルテレビ放送、ＩＰ放送、ビデオオンデマンド等、様々な番組の番組ストリームを受信し、番組ストリームに含まれる字幕データや番組の内容に関する第１のテキストデータである番組情報を利用してフィルタリングを行うための許可ワードテーブルを生成する。また、フィルタリング装置１２０は、生成された許可ワードテーブルを用いて、任意のテキストデータをフィルタリングする。
【００２２】
表示装置１３０は、液晶ディスプレイ、有機ＥＬ(Electro Luminescence)ディスプレイ、シネマスクリーン、プロジェクタ（投影機）等で構成され、フィルタリング装置１２０で受信された番組や、フィルタリングされたテキストデータを表示する。
【００２３】
サービス提供サーバ１４０は、サービス提供者が運営するサーバであり、第三者が投稿データを投稿する電子掲示板等の様々なサービスを、第三者が有する情報端末やフィルタリング装置１２０等に提供する。
【００２４】
本実施形態の番組提供システム１００を構成するフィルタリング装置１２０は、テキストデータを適切にフィルタリングすることを目的としている。以下、フィルタリング装置１２０を構成する各機能部について説明し、その後、フィルタリング装置１２０を用いたフィルタリング方法を詳述する。
【００２５】
（フィルタリング装置１２０）
図２は、フィルタリング装置１２０の概略的な構成を示した機能ブロック図である。フィルタリング装置１２０は、操作部１５０と、チューナー部１５２と、通信部１５４と、ＤＥＭＵＸ（DEMUltipleXer）部１５６と、ＡＶデコード部１５８と、テーブル保持部１６０と、中央制御部１６２とを含んで構成される。ここで、チューナー部１５２と、通信部１５４と、ＤＥＭＵＸ部１５６とは番組ストリームを取得する番組ストリーム取得部として機能する。図２では、データの流れを実線の矢印で表し、制御信号の流れを破線の矢印で表している。
【００２６】
操作部１５０は、操作キー、十字キー、ジョイスティック、ジョグダイヤル、タッチパネル等のスイッチから構成され、ユーザの操作入力を受け付ける。
【００２７】
チューナー部１５２は、アンテナ１２２を介して放送局１１２から放送信号を受信し、操作部１５０を通じて設定されたチャンネル番号に従って放送信号を復調して番組ストリームを生成する。
【００２８】
通信部１５４は、通信網１２４を介して番組提供サーバ１１４との通信を確立し、ＨＴＴＰ（HyperText Transfer Protocol）に類するインターネット・プロトコルを用いて、チューナー部１５２同様、番組提供サーバ１１４が配信した、放送信号に相当するＩＰストリーミングをパケット単位で取得し、ＩＰストリーミングをタイムスタンプに従って復元して番組ストリームを生成する。また、通信部１５４は、サービス提供サーバ１４０との通信を確立することもできる。
【００２９】
ＤＥＭＵＸ部１５６は、番組ストリームを、例えば、映像データ（ＭＰＥＧ（Moving Picture Experts Group）ビデオストリーム）、音声データ（ＭＰＥＧ音声ストリーム）、字幕データ、時刻データ、番組情報といった複数のデータに分離する。
【００３０】
ＡＶデコード部１５８は、ＤＥＭＵＸ部１５６から映像データおよび音声データを取得し、映像信号および音声信号にデコードして、デコードした映像信号を表示装置１３０に出力する。なお、音声信号は図示しないスピーカ等の音声出力装置に出力する。
【００３１】
テーブル保持部１６０は、フラッシュメモリ、ＨＤＤ（Hard Disk Drive）等の記憶媒体で構成され、複数の形態素とその出現回数とを対応付けた許可ワードテーブルを保持する。なお、ＨＤＤは正確には装置であるが、説明の便宜上本説明では他の記憶媒体と同義として扱う。
【００３２】
中央制御部１６２は、中央処理装置（ＣＰＵ）、プログラム等が格納されたＲＯＭ、ワークエリアとしてのＲＡＭ等を含む半導体集積回路により、フィルタリング装置１２０全体を管理および制御する。また、本実施形態において、中央制御部１６２は、テーブル更新部１８０、データ取得部１８２、データ加工部１８４、表示制御部１８６としても機能する。
【００３３】
テーブル更新部１８０は、番組ストリーム取得部としてのチューナー部１５２や通信部１５４を介して取得された番組ストリームに、字幕データまたは第１のテキストデータである番組情報が含まれている場合、番組ストリームから字幕データまたは番組情報のいずれか一方もしくは両方を抽出し、形態素に分割して、分割した形態素が、後述する許可ワードテーブルになければ、その形態素を登録し、分割した形態素が許可ワードテーブルにあれば、形態素に対応した出現回数を更新する。ここで、字幕データは、映画やテレビジョン等の映像メディアにおいて、題名、配役、解説、会話等の情報を、文字を用いて表示するためのテキストデータを言う。また、番組情報は、チャンネル番号、サービスＩＤ、イベントＩＤ、番組開始時刻、番組終了時刻、番組名、番組の解説情報、番組の出演者やスタッフの情報、主題歌に関する情報、番組のジャンル等、番組の内容に関する様々な情報を含んでいる。以下では、説明の便宜のため、字幕データまたは番組情報のいずれか一方もしくは両方を番組付加データと略す。また、説明によっては番組付加データが字幕データまたは番組情報の一方を示す場合もある。
【００３４】
具体的に、テーブル更新部１８０は、チューナー部１５２や通信部１５４を介して取得された番組ストリームに番組付加データが含まれているか否か判定し、番組付加データが含まれていれば、その番組付加データを、形態素辞書を用いて１または複数の形態素に分割する。ここで、形態素辞書は、予め大量の文章を集計し、各形態素と、形態素の前後に連接する形態素の連接確率を、辞書形式にしたものである。形態素辞書を用いることで日本語のような区切りのない自然言語を形態素単位に分割することができる。また、分割した形態素が形態素辞書にない場合、テーブル更新部１８０は、漢字、英数字、かな、カタカナ等の文字種の区切りを利用して形態素に分割する。形態素に分割する形態素解析エンジンとしては、自然言語の「分かち」を統計的な手法によって推測し、形態素単位に分割する技術も利用することができる。なお、形態素辞書を用いた形態素への分割アルゴリズムの詳細については公知技術であるため記載を省略する。
【００３５】
続いて、テーブル更新部１８０は、分割された各形態素を許可ワードテーブルに登録、または登録された形態素の出現回数を更新する。
【００３６】
図３は、許可ワードテーブル２００を説明するための説明図である。許可ワードテーブル２００は、前連接形態素ｐｗｏｒｄと、主形態素ｗｏｒｄと、出現回数ｗｎｕｍとが一意に関連付けられたテーブル構造を成している。ここで、前連接形態素ｐｗｏｒｄは、分割された形態素列において主形態素ｗｏｒｄの前に位置する形態素であり、主形態素ｗｏｒｄが文章の先頭の形態素であった場合、空値（ＮＵＬＬ）となる。主形態素ｗｏｒｄは、主たるキーワードとなる形態素であり空値は許されない。したがって、テーブル更新部１８０は、文章が「総理の命を受け、」であった場合、「総理」を主形態素ｗｏｒｄとして、前連接形態素ｐｗｏｒｄが「ＮＵＬＬ」となるレコード２０２を生成しても、「受け」を前連接形態素ｐｗｏｒｄとして、主形態素ｗｏｒｄが「ＮＵＬＬ」となるレコードは生成しない。出現回数ｗｎｕｍは、前連接主形態素ｐｗｏｒｄと主形態素ｗｏｒｄの組み合わせが番組付加データ中に出現した回数であり１以上の整数で表される。
【００３７】
テーブル更新部１８０は、分割した形態素に関して、前後２つの形態素の組み合わせが許可ワードテーブル２００になければ、その２つの形態素の組み合わせを登録し、前後２つの形態素の組み合わせが許可ワードテーブル２００にあれば、その組み合わせに対応した出現回数をインクリメント（＋１）する。したがって、許可ワードテーブル２００では、前連接形態素ｐｗｏｒｄと主形態素ｗｏｒｄとの組み合わせがユニークになる。かかる許可ワードテーブル２００を生成するための命令文を、例えばデータベース記述言語であるＳＱＬ（Structured Query Language）を用いて表すと、以下のように記述できる。
create table allowing_word_table(
pword text,
word text not null,
wnum integer,
UNIQUE(pword, word)
);
【００３８】
本実施形態では、許可ワードテーブル２００を、番組ストリームに含まれる番組付加データを用いて生成しているので、以下の効果を得ることができる。即ち、番組および番組付加データは放送倫理規定に従って生成されている。放送倫理規定は、例えば、放送倫理基本綱領に、「適正な言葉を用いると同時に、品位ある表現を心掛けるようつとめる」と規定され、放送倫理規定に従って生成された番組付加データには、公序良俗に反する単語や文章が含まれていない。したがって、番組ストリームに含まれる番組付加データに基づいて許可ワードテーブル２００を生成すれば、個々の単語が許可ワードに相当するか否かの判断を要することなく、許可ワードを容易に蓄積することができる。
【００３９】
また、番組ストリームを受信する機能自体は確立されているため、データ容量が大きい許可ワードテーブル２００を各ユーザの情報端末に配信するシステムを新たに構築しなくとも、フィルタリング装置１２０内で番組ストリームに含まれる番組付加データを抽出するだけで、許可ワードテーブル２００を随時更新することができる。したがって、最低限の維持コストで、許可ワードテーブル２００を随時更新することが可能なシステムを構築することができる。
【００４０】
ここで、仮に、データ容量が大きい許可ワードテーブル２００を各ユーザの情報端末に配信するシステムが構築されたとしても、許可ワードテーブル２００を情報端末に配信する際に第三者が許可ワードテーブル２００を改竄する危険性が残る。本実施形態では、許可ワードテーブル２００をフィルタリング装置１２０内の閉ざされた空間で更新するため、そのような改竄の危険性を最小限に抑えることができる。
【００４１】
本実施形態では、このような目的の下、主としてチューナー部１５２を通じて取得された番組ストリームに含まれる番組付加データを採用するが、放送倫理規定に準じてさえいれば、例えば、ケーブルテレビ放送、ＩＰ放送、ビデオオンデマンド等を実施している番組提供サーバ１１４から取得された番組ストリームの番組付加データを採用することができる。
【００４２】
また、番組ストリームの提供と独立してＥＰＧ（Electronic Program Guide）を提供しているサービス事業者もある。このようなサービス事業者が管理するサーバ（図示せず）からは、上述した番組情報を直接取得することができ、番組情報が放送倫理規定に準じてさえいれば、その番組情報を本実施形態に採用することができる。この場合、通信部１５４が番組情報を取得する番組情報取得部として機能し、テーブル更新部１８０は、番組情報取得部としての通信部１５４が取得した番組情報を形態素に分割して、許可ワードテーブル２００に反映する。説明の便宜のため、以下では、番組ストリームから番組付加データ、即ち、字幕データや番組情報を抽出して許可ワードテーブル２００に反映する構成を挙げているが、通信部１５４を通じて取得した番組情報も本実施形態の許可ワードテーブル２００に採用可能なのは言うまでもない。
【００４３】
データ取得部１８２は、通信部１５４を通じてサービス提供サーバ１４０から任意のテキストデータ（第２のテキストデータ）を取得すると共に、任意のテキストデータが生成、投稿、または、取得された日時を示す取得日時情報を任意のテキストデータに関連付ける。例えば、任意の放送局１１２で放送されている番組に関する投稿データを電子掲示板として公開しているサービス提供サーバ１４０があれば、データ取得部１８２は、その電子掲示板から投稿データを取得し、取得日時情報として、その投稿があった日時を投稿データに関連付ける。
【００４４】
このような電子掲示板（実況電子掲示板）や実況ブログ（日記）では、特定の放送局１１２で放送されている一連の番組について、通信網１２４を介し、不特定多数の投稿者が、恰も実況中継を行っているが如く、ほぼリアルタイムに投稿データを投稿し合っている。本実施形態において、データ取得部１８２は、このような任意の放送局１１２専用に設けられた電子掲示板から投稿データを取得する。
【００４５】
また、データ取得部１８２は、投稿専用サイトにおいて、任意の放送局１１２に関するスレッドのタイトルを指定し、その投稿データを取得してもよい。また、放送局１１２が独自に自局に対する意見等を募集するサイトを運営している場合、データ取得部１８２は、そのようなサイトを通じて投稿データを取得してもよい。
【００４６】
このような投稿データはリアルタイム性が高いため、例えば、データ取得部１８２が取得した投稿データを、投稿対象である、番組ストリーム取得部が取得した番組ストリームの番組と共に表示装置１３０に表示することで、ユーザは、番組と並行して、その番組に関する意見や説明をほぼリアルタイムに閲覧することができる。
【００４７】
なお、番組情報提供サーバ１１４から送信される番組ストリームの番組に対しても、上記と同様に投稿データを取得してもよい。しかし、この場合、番組情報提供サーバ１１４が送信する番組ストリームの番組は、放送局１１２から地上波デジタル放送、ＢＳ・ＣＳデジタル放送、ケーブルテレビ放送等で放送される番組とほぼ同時刻に再送信される番組に限定される。
【００４８】
データ加工部１８４は、データ取得部１８２が取得したテキストデータ（第２のテキストデータ）をフィルタリングして新たなテキストデータ（第３のテキストデータ）を生成する。例えば、上述したようにデータ取得部１８２が、サービス提供サーバ１４０から投稿データを取得している場合、データ加工部１８４は、その投稿データをフィルタリングして新たな投稿データを生成する。
【００４９】
具体的に、データ加工部１８４は、まず、データ取得部１８２が取得したテキストデータ（第２のテキストデータ）を、上述した形態素辞書を用いて形態素に分割する。そして、データ加工部１８４は、分割した形態素（正確には、２つの形態素の組み合わせ）が許可ワードテーブル２００に登録されているか否か判定し、許可ワードテーブル２００に登録されている形態素に関しては、その出現回数が予め定められた第１閾値α以上であるか否か判定する。
【００５０】
このとき、形態素が許可ワードテーブル２００に登録されていない、または、形態素が許可ワードテーブル２００に登録されているが、その形態素に対応した出現回数が第１閾値α未満であれば、データ加工部１８４は、形態素を、予め定められた１または複数の記号に置換して、分割した形態素をテキストデータ（第３のテキストデータ）として再結合する。したがって、新たに生成されたテキストデータには、許可ワードテーブル２００に登録された形態素のみが残ることとなる。
【００５１】
表示制御部１８６は、データ加工部１８４で加工されたテキストデータを、テキスト字幕状の画像にレンダリングして、そのレンダリング画像を、表示装置１３０に表示させる。
【００５２】
図４は、投稿データをレンダリングする例を示した説明図である。上述したように、データ取得部１８２が、サービス提供サーバ１４０から投稿データ（第２のテキストデータ）を取得している場合に、データ加工部１８４によってフィルタリングされた投稿データ（第３のテキストデータ）を、表示装置１３０における番組の表示領域２１０の下に設けられた投稿データ領域２１２に表示することで、ユーザは、番組と並行してその投稿データを閲覧することが可能となる。このとき閲覧している投稿データは、データ加工部１８４でフィルタリングされているため、公序良俗に反する単語や文章を含んでいない。したがって、未成年であっても、何ら問題なくその投稿データを視聴することが可能となる。
【００５３】
（フィルタリング方法）
図５は、フィルタリング方法の処理の流れを説明したフローチャートである。特に、図５では、フィルタリング方法のうち、許可ワードテーブル２００を生成する処理について説明している。
【００５４】
ＤＥＭＵＸ部１５６が番組ストリームに番組付加データが有ることを検出すると（Ｓ３００におけるＹＥＳ）、テーブル更新部１８０は、ＤＥＭＵＸ部１５６から番組付加データのテキスト本文を取得し（Ｓ３０２）、テキスト本文の字句解析を行い、テキスト本文中の１字以上の句読点、改行、記号および外字（予め定められた漢字、英数字、かな、カタカナ以外の文字）を特殊記号（例えば「■」）に置換する（Ｓ３０４）。このとき、句読点等が連続して記載されている場合、連続する全ての句読点等を合わせて１つの特殊記号に置換する。このように字句解析を行い、句読点等を特殊記号に置換する処理によって、番組付加データ特有のレイアウトに用いられる記号や空白により、許可ワードテーブル２００に無駄に形態素が登録されるのを回避でき、検索に必要な形態素のみを蓄積することが可能となる。
【００５５】
そして、テーブル更新部１８０は、形態素辞書を用いて、句読点等が置換されたテキスト本文を形態素に分割する（Ｓ３０６）。このとき、テーブル更新部１８０として機能する形態素エンジンでは、置換された特殊記号を形態素間の区切りとする。
【００５６】
図６は、テーブル更新部１８０の処理を説明するための説明図である。ここでは、テキスト本文中の改行文字を（改行）、空白文字を（空白）で表している。例えば、番組ストリームに含まれている番組付加データのうちの字幕データが、図６（ａ）のようなテキストデータであった場合、テーブル更新部１８０は、「＞＞」、「、」、「。」、（改行）、（空白）といった句読点等を纏めて特殊記号「■」に置換し、さらに形態素に分解して、図６（ｂ）のような形態素列を形成する。ここでは理解を容易にするため、形態素間に［／］の記号を挿入しているが、実際に存在する記号として扱うものではない。
【００５７】
続いて、テーブル更新部１８０は、前連接形態素変数ＰＲＥＶを初期化（空値ＮＵＬＬを代入）し（Ｓ３０８）、許可ワードテーブル２００の登録判定が為されていない形態素（形態素列）が残っているか否か判定し（Ｓ３１０）、残っていないと判定されると（Ｓ３１０におけるＮＯ）、当該許可ワードテーブル２００を生成する処理を終了する。登録判定が為されていない形態素がまだ残っていれば（Ｓ３１０におけるＹＥＳ）、テーブル更新部１８０は、許可ワードテーブル２００の登録判定が為されていない形態素列の先頭にある形態素を１つ取り出して、形態素変数ＷＯＲＤに代入し、その形態素列から対象の形態素を削除する（Ｓ３１２）。
【００５８】
次に、テーブル更新部１８０は、形態素変数ＷＯＲＤが特殊記号「■」であるか否か判定し（Ｓ３１４）、特殊記号である場合（Ｓ３１４におけるＹＥＳ）、前連接形態素変数初期化ステップＳ３０８から繰り返す。
【００５９】
形態素変数ＷＯＲＤが特殊記号でなければ（Ｓ３１４におけるＮＯ）、テーブル更新部１８０は、前連接形態素変数ＰＲＥＶと形態素変数ＷＯＲＤの組み合わせが、許可ワードテーブル２００の前連接形態素ｐｗｏｒｄと主形態素ｗｏｒｄの組み合わせとして存在するか否か判定し（Ｓ３１６）、存在すれば（Ｓ３１６におけるＹＥＳ）、その前連接形態素ｐｗｏｒｄと主形態素ｗｏｒｄに対応する出現回数ｗｎｕｍをインクリメントし（Ｓ３１８）、存在しなければ（Ｓ３１６におけるＮＯ）、前連接形態素変数ＰＲＥＶと形態素変数ＷＯＲＤの組み合わせを、前連接形態素ｐｗｏｒｄと主形態素ｗｏｒｄの新たなレコードとして、許可ワードテーブル２００に追加し、対応する出現回数ｗｎｕｍを１に設定する（Ｓ３２０）。
【００６０】
そして、テーブル更新部１８０は、前連接形態素変数ＰＲＥＶに形態素変数ＷＯＲＤの値を代入し（Ｓ３２２）、形態素残り判定ステップＳ３１０から繰り返す。こうして、図６（ｂ）に示した形態素列に基づいて、図３に示した許可ワードテーブル２００が生成される。上述した処理では、分割された形態素が、形態素辞書に含まれていなくとも、許可ワードテーブル２００に登録でき、出現回数を計数することができる。
【００６１】
以上により生成された許可ワードテーブル２００は、番組付加データに含まれる２つの形態素間の連接の様相と、その出現回数とを蓄積している。かかる連接の様相は、ユーザが住んでいる地域にある放送局１１２や、ユーザがもっぱら視聴する放送局１１２における番組付加データの生成特性を色濃く反映するので、許可ワードテーブル２００は、地域性やユーザの好みに応じたものとなる。
【００６２】
また、存在判定ステップＳ３１６において、前連接形態素ｐｗｏｒｄと主形態素ｗｏｒｄの２つの連接を判定しているのは、公序良俗に反していない形態素を連接することで公序良俗に反するようになる文字列等を排除するためである。例えば、文字列「基地外」といった文字列が「基地の外」といった意味であっても、読み方によっては公序良俗違反となる。このとき、データ加工部１８４が、「基地」と「外」とをそれぞれ単独で判定した場合に、文字列「基地外」が排除されないおそれがある。放送倫理規定の下では、「基地外」の表現は用いられず、「基地の外」といった表現が為されるので、許可ワードテーブル２００には、「基地」「の」または「の」「外」といった連接した形態素が登録され、「基地外」といった文字列を排除することが可能になる。
【００６３】
また、ここでは、理解を容易にするため、対象となる形態素と１つ前の形態素との組み合わせを蓄積する例を挙げているが、連接するｎ個前までの形態素の組み合わせを許可ワードテーブル２００に登録することで、形態素の組み合わせに対して厳密なフィルタリングを実行することが可能となる（形態素２個の場合、２ｇｒａｍ法、ｎ個前までの連接性を集計する場合をｎ−ｇｒａｍ法と言う。）。
【００６４】
また、アプリケーションによっては、テキスト本文に含まれる一部の記号等を置換せずに残したまま許可ワードテーブル２００の登録判定を行ってもよい。本実施形態は、形態素辞書の生成元テキストデータとは異なるテキストデータから形態素の組み合わせと出現回数とを抽出することを目的としているので、上述した、番組ストリームに含まれる番組付加データ（字幕データや番組情報）のテキスト本文のみならず、番組ストリームに含まれ得る他の情報から形態素を抽出してもよい。
【００６５】
また、ここでは、番組ストリームを、チューナー部１５２や通信部１５４から取得する例を挙げたが、記憶媒体に記憶している番組ストリームファイル等、放送倫理規定に準じてさえいれば、様々な経路から番組ストリームを取得することができる。さらに、チューナー部１５２とＤＥＭＵＸ部１５６との組み合わせを複数備えることで複数の放送局１１２から番組ストリームを並列に受信し、より多くの形態素を高速に収集してもよいし、許可ワードテーブル２００を生成するための機能部を、番組視聴のための機能部と独立して動作させ、例えば、２４時間連続して番組ストリームを受信させ、許可ワードテーブル２００を生成させてもよい。
【００６６】
図７は、フィルタリング方法の処理の流れを説明したフローチャートである。特に、図７は、フィルタリング方法のうち、図５で生成された許可ワードテーブル２００を利用してテキストデータをフィルタリングする処理を説明している。
【００６７】
まず、データ取得部１８２は、視聴している番組の番組ストリームに含まれる時刻データを取得し（Ｓ３５０）、開始時刻変数ＳＴＩＭＥに、取得した時刻データから所定秒（例えば１０秒）を減算した値を設定し、終了時刻変数ＥＴＩＭＥに時刻データを設定する（Ｓ３５２）。そして、データ取得部１８２は、サービス提供サーバ１４０から通信部１５４を介して、開始時刻変数ＳＴＩＭＥから終了時刻変数ＥＴＩＭＥまでの時刻範囲に投稿された投稿データ群を取得し（Ｓ３５４）、中央制御部１６２のＲＡＭに設けた出力バッファを初期化する（Ｓ３５６）。
【００６８】
図８は、投稿データ群を例示した説明図である。例えば、データ取得部１８２は、ＤＥＭＵＸ部１５６から時刻データ「２００９年９月３０日  １７：４５：４０」を取得すると、時刻範囲（ＳＴＩＭＥ，ＥＴＩＭＥ）＝（「２００９年９月３０日  １７：４５：３０」，「２００９年９月３０日  １７：４５：４０」）に該当する投稿データ群を取得する。ここでは、図８に示すような、時刻データが「２００９年９月３０日  １７：４５：３１」となっている投稿データと、時刻データが「２００９年９月３０日  １７：４５：３８」となっている投稿データが該当する。
【００６９】
データ加工部１８４は、フィルタリング処理が為されていない投稿データが残っているか否か判定し（Ｓ３５８）、残っていないと判定すると（Ｓ３５８におけるＮＯ）、表示制御部１８６は、出力バッファに蓄積されている、フィルタリングが施された投稿データを表示装置１３０に表示させて（Ｓ３６０）、当該処理を終了する。
【００７０】
出力バッファのテーブル構造を形成するための命令文は、ＳＱＬを用いて表すと、以下のように記述できる。
create table output_buffer (
post timestamp not null,
wlist text list,
UNIQUE(post)
);
かかる出力バッファは、投稿データの、投稿日時ｐｏｓｔ（取得日時情報）と形態素列ｗｌｉｓｔとを組み合わせたテーブル構造で形成される。投稿日時ｐｏｓｔは投稿が行われた日時であり、形態素列ｗｌｉｓｔはフィルタリングが施された形態素列である。また、出力バッファは、投稿日時ｐｏｓｔについてユニークになるように設定されている。
【００７１】
また、フィルタリング処理が為されていない投稿データが残っていれば（Ｓ３５８におけるＹＥＳ）、残っている投稿データ群の先頭にある投稿データを１つ取り出して、投稿日時ｐｏｓｔを投稿日時変数ＰＯＳＴＴＩＭＥに代入し、投稿元データのテキスト本文をテキスト変数ＴＥＸＴに代入し、その投稿データ群から対象の投稿データを削除する（Ｓ３６２）。データ加工部１８４は、テキスト変数ＴＥＸＴに対し、２字以上の句読点は１文字の句読点（「。」、「.」、「、」、「,」等）へ置換し、かつ改行や記号や空白は削除する字句解析を行い（Ｓ３６４）、形態素辞書を用いて、字句解析が施された投稿データのテキスト本文を形態素に分割する（Ｓ３６６）。このとき、データ加工部１８４として機能する形態素エンジンでは、句読点を形態素間の区切りとする。
【００７２】
続いて、データ加工部１８４は、前連接形態素変数ＰＲＥＶを初期化（空値ＮＵＬＬを代入）し（Ｓ３６８）、対象となる投稿データに形態素が残っているか否か判定し（Ｓ３７０）、残っていないと判定されると（Ｓ３７０におけるＮＯ）、新たな投稿データを判定すべく、投稿データ残り判定ステップＳ３５８から繰り返す。
【００７３】
対象となる投稿データに形態素が残っていれば（Ｓ３７０におけるＹＥＳ）、投稿データのテキスト本文における形態素列の先頭から形態素を１つ取り出して形態素変数ＷＯＲＤに代入する（Ｓ３７２）。そして、データ加工部１８４は、形態素変数ＷＯＲＤが句読点または空白であるか否か判定し（Ｓ３７４）、句読点または空白であれば（Ｓ３７４におけるＹＥＳ）、時刻判定ステップＳ３８２に移行する。
【００７４】
ここで、字句解析ステップＳ３６４や句読点判定ステップＳ３７４は、句読点、空白、改行、記号の挿入（ゆらぎ）によって、意図していない位置で単語が分離し、形態素同士の連接関係を崩さないようにするために実行されている。
【００７５】
形態素変数ＷＯＲＤが句読点や空白でなければ（Ｓ３７４におけるＮＯ）、データ加工部１８４は、許可ワードテーブル２００に、前連接形態素ｐｗｏｒｄが前連接形態素変数ＰＲＥＶの値と等しく、かつ主形態素ｗｏｒｄが形態素変数ＷＯＲＤの値と等しくなるレコードが存在するか否か、また、存在した場合、その出現回数ｗｎｕｍが第１閾値α以上であるか否か判定し（Ｓ３７６）、一致する形態素の組み合わせが存在しない場合、または、存在するが出現回数ｗｎｕｍが第１閾値α未満の場合（Ｓ３７６におけるＮＯ）、前連接形態素変数ＰＲＥＶを初期化（空値を代入）し、さらに形態素変数ＷＯＲＤを、伏字を意味する特殊記号「◎」に置換する（Ｓ３７８）。ここで、出現回数ｗｎｕｍが第１閾値α未満の形態素の組み合わせも特殊記号に置換しているのは、出現回数ｗｎｕｍが第１閾値α未満であれば、番組付加データに十分に出現したと言えず、その形態素の組み合わせた許可ワードとして適当ではないからである。
【００７６】
図９は、データ加工部１８４の処理を説明するための説明図である。例えば、投稿データのテキスト本文が図９（ａ）のようなテキストデータ「総理はＢＣＤだな」であった場合（ここでＢＣＤは連接すると公序良俗違反となる文字列であるとする。）、前連接形態素ｐｗｏｒｄ＝「ＮＵＬＬ」、主形態素ｗｏｒｄ＝「総理」となるレコードは、図３の許可ワードテーブル２００に存在するので、データ加工部１８４は、形態素「総理」を出力バッファに蓄積する。また、「ＢＣ」と「Ｄ」とが連接する形態素は、許可ワードテーブル２００に存在していないので、データ加工部１８４は、その形態素のうち形態素変数ＷＯＲＤにあたる「Ｄ」を特殊記号「◎」に置換して、図９（ｂ）のような形態素列を形成する。ここでも理解を容易にするため、形態素間に［／］の記号を挿入しているが、実際に存在する記号として扱うものではない。
【００７７】
また、許可ワードテーブル２００に一致する形態素の組み合わせが存在し、かつ、その形態素の出現回数ｗｎｕｍが第１閾値α以上の場合（Ｓ３７６におけるＹＥＳ）、データ加工部１８４は、前連接形態素変数ＰＲＥＶに形態素変数ＷＯＲＤの値を代入する（Ｓ３８０）。そして、データ加工部１８４は、出力バッファに、投稿日時変数ＰＯＳＴＴＩＭＥの値が投稿日時ｐｏｓｔと一致するレコードが存在するか否か判定し（Ｓ３８２）、存在する場合（Ｓ３８２におけるＹＥＳ）、該当レコードの形態素列ｗｌｉｓｔの最後に形態素変数ＷＯＲＤの値を追加して（Ｓ３８４）、形態素残り判定ステップＳ３７０から繰り返す。存在しない場合（Ｓ３８２におけるＮＯ）、データ加工部１８４は、投稿日時ｐｏｓｔと形態素列ｗｌｉｓｔとが、それぞれ前連接形態素変数ＰＯＳＴＴＩＭＥと形態素変数ＷＯＲＤとなる新たなレコードを追加して（Ｓ３８６）、形態素残り判定ステップＳ３７０から繰り返す。
【００７８】
ここでは、理解を容易にするため第１閾値αを１とする。しかし、アプリケーションによって第１閾値αを適宜変更できることは言うまでもない。また、存在判定ステップＳ３７６を、出現回数ｗｎｕｍそのものではなく、以下の式１で求められる出現確率を用いて実行してもよい。
該当レコードのｗｎｕｍ値  ／  全レコードのｗｎｕｍの合計値  …（式１）
このように構成することで、データ加工部１８４は、許可ワードテーブル２００の母集団との比率に基づいて存在判定ステップＳ３７６を実行することができる。したがって、任意の形態素が、母集団が小さいときに許可ワードとなっていても、その後、出現回数が更新されないと、母集団が大きくなるに連れて出現確率が減り、許可ワードから除外される場合もある。こうして、出現頻度が少なくなった形態素を自動的に排除することが可能となる。
【００７９】
以上、説明したように、本実施形態のフィルタリング装置１２０は、形態素辞書と異なる許可ワードテーブル２００を用い、番組ストリームに含まれる番組付加データから取得した形態素の組み合わせおよび出現回数を利用して、公序良俗に反する単語が含まれる投稿データを、そのような単語が含まれていない投稿データに適切に変更することが可能となる。
【００８０】
また、上述したように、許可ワードテーブル２００は、ユーザが住んでいる地域にある放送局１１２や、ユーザがもっぱら視聴する放送局１１２における番組付加データの生成特性を色濃く反映するので、許可ワードテーブル２００は、地域性やユーザの好みに応じたものとなり、結果的に、フィルタリングされた投稿データも地域性やユーザの好みに応じた単語が残り易くなる。
【００８１】
また、上述した実施形態では、電子掲示板から取得した投稿データをフィルタリングする例を挙げて説明したが、投稿データに限らず、ウェブブラウザに表示される様々なデータや、記憶媒体に収められているデータ等、様々なテキストデータをフィルタリングすることも可能である。
【００８２】
（第２の実施形態：番組提供システム４００）
第１の実施形態では、任意のテキストデータを適切にフィルタリングするフィルタリング装置１２０およびフィルタリング方法を説明した。第２の実施形態では、第１の実施形態で説明したフィルタリング技術を用い、番組や番組内の所定シーンを適切に検索する番組検索装置４２０および番組検索方法を説明する。
【００８３】
図１０は、第２の実施形態における番組提供システム４００の概略的な接続関係を示した説明図である。番組提供システム４００は、番組提供装置１１０と、番組検索装置４２０と、表示装置１３０と、サービス提供サーバ１４０とを含んで構成される。ここで、番組提供装置１１０、表示装置１３０、サービス提供サーバ１４０に関しては、第１の実施形態で説明した番組提供装置１１０、表示装置１３０、サービス提供サーバ１４０と実質的に動作が等しいのでここではその説明を省略する。
【００８４】
番組検索装置４２０は、第１の実施形態で説明したフィルタリング装置１２０同様、番組提供装置１１０としての放送局１１２からアンテナ１２２を通じて、また、番組提供装置１１０としての番組提供サーバ１１４からインターネット等の通信網１２４を通じて、地上波デジタル放送、ＢＳ・ＣＳデジタル放送、ケーブルテレビ放送、ＩＰ放送、ビデオオンデマンド等、様々な番組の番組ストリームを受信し、フィルタリングを行うための許可ワードテーブル２００を生成する。
【００８５】
また、番組検索装置４２０は、番組を保持すると共に、許可ワードテーブル２００を用いて、番組のインデックスデータを生成し、保持された番組に付与する。そして、ユーザが番組や番組内の所定シーンの検索を試みると、番組検索装置４２０は、インデックスデータに基づいてユーザが所望する番組や番組内の所定シーンを迅速に抽出する。以下、番組検索装置４２０を構成する各機能部について説明し、その後、番組検索装置４２０を用いた番組検索方法を詳述する。
【００８６】
（番組検索装置４２０）
番組を複数蓄積し、蓄積された番組を事後的に視聴する構成（例えば、ＨＤＲ：Hard Disk Recorder）において、番組ストリームに字幕データが含まれている場合、その字幕データをインデックスデータとして番組それぞれに関連付けることで、ＨＤＲは、そのインデックスデータに基づいて、ユーザが所望する番組を迅速に提示することができる。しかし、番組ストリームには必ず字幕データが含まれているとは限らず、例えば、ニュースや生放送といった、予めその放送内容を提示できないものに関しては字幕データが含まれていない、または、含まれていたとしても表題等の極限られた情報である。そうすると、番組によっては、インデックスデータが関連付けられているものと、そうでないものが生じる。
【００８７】
そこで、本実施形態の番組検索装置４２０は、字幕データが含まれていない番組ストリームについては、放送以外の経路からインデックスデータに相当する情報を取得して、インデックスデータとして番組に関連付けることを試みる。かかる情報の取得先としては、第１の実施形態で説明した、任意の放送局１１２で放送されている番組に関する投稿データを電子掲示板として公開しているサービス提供サーバ１４０等が適している。番組検索装置４２０は、例えば、番組の視聴時間と、投稿データの投稿日時とを比較して、日時が一致する投稿データが該当する番組に関連していると見なし、その投稿データをインデックスデータとして利用する。
【００８８】
しかし、このようなサービス提供サーバ１４０では、投稿データの文章の制限が緩く、かかる文章がフィルタリングされていたとしても、禁止ワードテーブルを利用しているため、投稿データにゆらぎを加えることで、文章を自由に表現することができる。したがって、投稿データを利用してそのままインデックスデータを生成してしまうと、公序良俗に反する単語や文章を含む、ありとあらゆるテキストデータがインデックスデータとして関連付けられてしまい、インデックスデータの容量が膨大となって検索処理の遅延を招くことになる。このとき、インデックスデータが多くなることで検索のヒット率が高くなるように思えるが、実際には、アスキーアートによる無意味なテキストデータ等、検索用のインデックスデータとして不適当なものが多く、ヒット率が高くなるとは限らない。さらに、ゆらぎに相当する当て字等がインデックスデータとして登録された場合、その番組のインデックスデータとして機能しないばかりか、意図していない他の番組の検索に引っかかってしまい、検索精度が低下する。
【００８９】
また、大容量のインデックスデータが関連付けられた番組と、字幕データに基づくインデックスデータが関連付けられた番組で、インデックスデータの量や質が異なることとなるので、検索のためのキーワードによっては、ユーザが所望する番組を適切に抽出できなくなる。このような問題を、以下に示す番組検索装置４２０および番組検索方法によって解決する。
【００９０】
図１１は、番組検索装置４２０の概略的な構成を示した機能ブロック図である。図１１では、データの流れを実線の矢印で表し、制御信号の流れを破線の矢印で表している。番組検索装置４２０は、操作部１５０と、チューナー部１５２と、通信部１５４と、ＤＥＭＵＸ部１５６と、ＡＶデコード部１５８と、テーブル保持部１６０と、中央制御部４６２と、番組保持部４６４と、番組情報保持部４６６と、ＲＴＣ（Real Time Clock）部４６８と、インデックス保持部４７０とを含んで構成される。ここで、チューナー部１５２と、通信部１５４と、ＤＥＭＵＸ部１５６とは番組ストリームを取得する番組ストリーム取得部として機能する。
【００９１】
また、中央制御部４６２は、テーブル更新部１８０、データ取得部４８２、データ加工部１８４、表示制御部１８６、番組記憶制御部４８８、番組情報記憶制御部４９０、インデックス付与部４９２、番組抽出部４９４としても機能する。
【００９２】
第１の実施形態における構成要素として既に述べた操作部１５０と、チューナー部１５２と、通信部１５４と、ＤＥＭＵＸ部１５６と、ＡＶデコード部１５８と、テーブル保持部１６０と、テーブル更新部１８０と、データ加工部１８４と、表示制御部１８６とは、実質的に機能が同一なので重複説明を省略し、ここでは、構成が相違する中央制御部４６２、番組保持部４６４、番組情報保持部４６６、ＲＴＣ部４６８と、インデックス保持部４７０、データ取得部４８２、番組記憶制御部４８８、番組情報記憶制御部４９０、インデックス付与部４９２、番組抽出部４９４を主に説明する。
【００９３】
番組記憶制御部４８８は、番組を、チャンネル番号と時刻データで検索可能な形で番組保持部４６４に保持させる。
【００９４】
番組保持部４６４は、フラッシュメモリ、ＨＤＤ等の記憶媒体で構成され、１または複数の番組を保持する。また、番組保持部４６４として、番組検索装置４２０から着脱可能な、ＤＶＤ（Digital Versatile Disc）やＢＤ（Blu-ray Disc）といった光ディスク媒体や、磁気テープ、磁気ディスクといった磁気媒体、フラッシュメモリ、ポータブルＨＤＤ等の外部記憶媒体を適用してもよい。
【００９５】
また、番組保持部４６４は、ランダムアクセス可能なファイルシステムであり、他の機能部は、番組保持部４６４に保持された映像データ、音声データ、字幕データを任意の時刻範囲を指定して読み出すことができる。ここで、ランダムアクセスの方法は既存の技術であるので詳しくは述べないが、例えば、番組を１時間ごとに分割して保存し、その分割したファイルのファイル名を「２７ＣＨ＿２００９年９月３０日１７：００：００．ＴＳ」といった、チャンネル番号と記憶開始時刻とを含めた名称にすることで、大まかなランダムアクセスが可能となる。
【００９６】
さらに番組中の任意のシーンのランダムアクセスは、任意の再生時刻のファイルオフセット（バイト）を求めることで行うことができる。例えば、１時間あたりのファイルの総サイズ（バイト）をＴＯＴＡＬ、任意のシーンの絶対再生時刻をＴ１、ファイル名から得られたファイル先頭の絶対時刻をＴ０とすると、以下の式２によりファイルオフセットが求まる。
ＴＯＴＡＬ／３６００×（Ｔ１−Ｔ０）    …（式２）
ここで、（Ｔ１−Ｔ０）の結果は秒換算して用いるものとする。
【００９７】
番組情報記憶制御部４９０は、番組ストリーム取得部としてのチューナー部１５２や通信部１５４を介して取得された番組ストリームに番組情報が含まれている場合、番組ストリームから番組情報を抽出し、番組情報テーブルとして番組情報保持部４６６に保持させる。
【００９８】
かかる番組情報テーブルを生成するための命令文を、ＳＱＬを用いて表すと、以下のように記述できる。
create table epg_table (
phych integer not null,
serviceid integer not null,
eventid integer not null,
sttime timestamp not null,
edtime timestamp not null,
title text not null,
capflg integer not null,
UNIQUE(serviceid, eventid, sttime)
);
ここで番組情報は、少なくとも、チャンネル番号ｐｈｙｃｈ、サービスＩＤ：ｓｅｒｖｉｃｅｉｄ、イベントＩＤ：ｅｖｅｎｔｉｄ、番組開始時刻ｓｔｔｉｍｅ、番組終了時刻ｅｄｔｉｍｅ、番組名ｔｉｔｌｅ、字幕フラグｃａｐｆｌｇを含んでいる。また、番組情報テーブルでは、サービスＩＤ：ｓｅｒｖｉｃｅｉｄと、イベントＩＤ：ｅｖｅｎｔｉｄと、番組開始時刻ｓｔｔｉｍｅとの組み合わせがユニークになる。番組情報記憶制御部４９０は、字幕フラグｃａｐｆｌｇ以外の情報は番組情報から取得できる。また、サービスＩＤは１つの放送局１１２中の１つ以上の編成に対応した固有な数値であり、イベントＩＤは１編成中の１つ以上のイベントに対応した固有な数値である。
【００９９】
番組情報を番組情報テーブルに登録する際、番組情報保持部４６６に、サービスＩＤ：ｓｅｒｖｉｃｅｉｄと、番組情報の番組開始時刻ｓｔｔｉｍｅおよび番組終了時刻ｅｄｔｉｍｅとが等しい番組情報が既に登録されていれば、番組情報記憶制御部４９０は、その番組情報を削除して新たに抽出した番組情報を登録する。こうすることで、同一編成における番組枠の重複を除外することができる。また、番組情報記憶制御部４９０は、番組情報を新たに登録する際、その番組情報の字幕フラグｃａｐｆｌｇを０（未処理）に設定する。
【０１００】
番組情報保持部４６６は、フラッシュメモリ、ＨＤＤ等の記憶媒体で構成され、番組情報記憶制御部４９０の制御指令に基づいて、番組ストリームに含まれる番組情報をテーブル化した番組情報テーブルを保持する。また、番組情報保持部４６６は、ＥＰＧデータベースとして機能し、他の機能部（例えば、インデックス付与部４９２や番組抽出部４９４）は、番組情報保持部４６６が保持する番組情報テーブルを任意の条件で検索することができる。
【０１０１】
データ取得部４８２は、番組に関するテキストデータ（第２のテキストデータ）を取得する。本実施形態では、データ取得部４８２は、任意の放送局１１２で放送されている番組に関する投稿データを電子掲示板として公開しているサービス提供サーバ１４０から、その番組に関する投稿データ（第２のテキストデータ）を取得すると共に、投稿日時（取得日時情報）を投稿データに関連付ける。上述したように、このような電子掲示板では、特定の放送局１１２で放送されている一連の番組について、通信網１２４を介し、不特定多数の投稿者が、恰も実況中継を行っているが如く、ほぼリアルタイムに投稿データを投稿し合っている。本実施形態において、データ取得部４８２は、このような任意の放送局１１２専用に設けられた電子掲示板から投稿データを取得する。データ取得部４８２は、投稿専用サイトにおいて、任意の放送局１１２に関するスレッドのタイトルを指定し、その投稿データを取得してもよい。また、放送局１１２が独自に自局に対する意見等を募集するサイトを運営している場合、データ取得部４８２は、そのようなサイトを通じて投稿データを取得してもよい。
【０１０２】
具体的に、データ取得部４８２は、ウェブブラウザに相当し、通信部１５４を通じて、サービス提供サーバ１４０との通信を確立し、時刻範囲とチャンネル番号を含むリクエスト情報を送信し、時刻範囲に含まれる投稿データ群（テキストデータ群）をレスポンスとして取得する。データ取得部４８２が投稿データ群を取得すると、データ加工部１８４は、投稿データ（第２のテキストデータ）を形態素に分割し、分割した形態素が許可ワードテーブル２００に登録されていない、または、形態素が許可ワードテーブル２００に登録されているが、その形態素に対応した出現回数が予め定められた第１閾値α未満であれば、形態素を、予め定められた１または複数の文字に置換し、投稿データ（第３のテキストデータ）として再結合する。
【０１０３】
ＲＴＣ部４６８は、ＲＴＣ回路で構成され、番組検索装置４２０自体の時計としての役割を担う。
【０１０４】
インデックス付与部４９２は、番組保持部４６４に保持された番組に、番組付加データまたは投稿データから抽出した形態素と、番組付加データまたは投稿データ（第２のテキストデータ）に関連付けられた取得日時情報との組を、インデックスデータとして付与し（関連付け）、インデックステーブルとしてインデックス保持部４７０に保持させる。かかるインデックステーブルを生成するための命令文を、ＳＱＬを用いて表すと、以下のように記述できる。
create table index_table (
word text not null,
postime timestamp not null,
serviceid integer not null,
eventid integer not null,
UNIQUE(word, postime, serviceid, eventid)
);
ここで、インデックステーブルは、少なくとも、検索語ｗｏｒｄ、検索時刻ｐｏｓｔｉｍｅ、該当番組のサービスＩＤ：ｓｅｒｖｉｃｅｉｄ、該当番組のイベントＩＤ：ｅｖｅｎｔｉｄを含む。また、インデックステーブルは、検索語ｗｏｒｄと、検索時刻ｐｏｓｔｉｍｅと、該当番組のサービスＩＤ：ｓｅｒｖｉｃｅｉｄと、該当番組のイベントＩＤ：ｅｖｅｎｔｉｄとの組み合わせがユニークになる。
【０１０５】
また、本実施形態において、インデックス付与部４９２は、番組ストリームに字幕データが含まれていれば（番組に字幕データが付加されていれば）、その字幕データと取得日時情報との組をインデックスデータとしてその字幕データに対応する番組に付与し、番組ストリームに字幕データが含まれていなければ（番組に字幕データが付加されていなければ）、または、含まれていない（番組に字幕データが付加されていない）とみなせれば、再結合したテキストデータ（第３のテキストデータ）と、その取得日時情報との組をインデックスデータとしてその字幕データに対応する番組に付与する。ここで、含まれていない（番組に字幕データが付加されていない）とみなすとは、後述する字幕率が低いことを言う。
【０１０６】
具体的に、インデックス付与部４９２は、番組情報保持部４６６から、未処理（字幕フラグｃａｐｆｌｇ＝０）の番組情報を取り出し、番組保持部４６４から、その番組情報に対応した番組の字幕データを取り出してインデックスデータとする。このとき、番組ストリームに、字幕データが存在しないか存在しないとみなせる場合（番組に字幕データが付加されていないか付加されていないとみなせる場合）、インデックス付与部４９２は、データ取得部４８２に、サービス提供サーバ１４０から投稿データ（テキストデータ）を取得させ、データ加工部１８４に、該当する番組を検索可能なインデックスデータを生成させる。そして、インデックス付与部４９２は、インデックスデータを、番組に付与するために、インデックスデータをインデックス保持部４７０のインデックステーブルへ登録する。
【０１０７】
かかるインデックス付与部４９２を備えることで、番組ストリームに含まれる字幕データと、サービス提供サーバ１４０の投稿データとのいずれを付与対象の番組のインデックスデータとすべきか適切に選択して、検索のための適当なインデックスデータを生成することが可能となる。こうして、字幕データがない場合であってもインデックスが付されるので、検索精度を向上することが可能となる。
【０１０８】
また、本実施形態では、テーブル更新部１８０が許可ワードテーブル２００を更新するために用いる番組付加データのうちの字幕データと、インデックス付与部４９２がインデックスデータとして用いる字幕データとを区別しているが、インデックスデータとして用いる字幕データを利用して、許可ワードテーブル２００を更新することも可能である。
【０１０９】
インデックス保持部４７０は、フラッシュメモリ、ＨＤＤ等の記憶媒体で構成され、インデックス付与部４９２の制御指令に基づいて、インデックスデータをテーブル化したインデックステーブルを保持する。
【０１１０】
番組抽出部４９４は、操作部１５０を通じたユーザの操作入力を受け付け、その操作結果を表示装置１３０にＧＵＩ（Graphical User Interface）を通じて表示すると共に、ユーザが検索のため入力したキーワード等に基づいて、インデックステーブルを参照し、番組保持部４６４に保持された番組または番組内の所定シーンを抽出する。
【０１１１】
（番組検索方法）
図１２は、番組検索方法の処理の流れを説明したフローチャートである。特に、図１２では、番組検索方法のうち、インデックスデータの付与処理について説明している。まず、インデックス付与部４９２は、ＲＴＣ部４６８から現在時刻を取得し、時刻変数ＮＯＷへ代入し（Ｓ５００）、番組情報保持部４６６から、字幕フラグｃａｐｆｌｇが０（未処理）であり、かつ番組終了時刻ｅｄｔｉｍｅが時刻変数ＮＯＷより過去にあたる番組情報を検索し、番組情報列として取得する（Ｓ５０２）。
【０１１２】
インデックス付与部４９２は、番組情報列に番組情報が残っているか否か判定し（Ｓ５０４）、残っていれば（Ｓ５０４におけるＹＥＳ）、番組情報列の先頭から番組情報を１つ取り出し、サービスＩＤ変数ＳＥＲＶＩＣＥＩＤにサービスＩＤ：ｓｅｒｖｉｃｅｉｄを、イベントＩＤ変数ＥＶＥＮＴＩＤにイベントＩＤ：ｅｖｅｎｔｉｄをそれぞれ代入して、その番組情報列から対象の番組情報を削除する（Ｓ５０６）。番組情報列に番組情報が残っていなかった場合（Ｓ５０４におけるＮＯ）、当該インデックスデータの付与処理を終了する。
【０１１３】
続いて、インデックス付与部４９２は、番組保持部４６４から、チャンネル番号ｐｈｙｃｈに関するファイルであり、かつ番組開始時刻ｓｔｔｉｍｅから番組終了時刻ｅｄｔｉｍｅまでの時刻範囲に含まれる番組付加データから字幕データ列を取得し（Ｓ５０８）、取得した字幕データ列に含まれる字幕データの総数を、変数ＣＡＰＮＵＭに代入する（Ｓ５１０）。図１３は、字幕データの一例を示した説明図である。図１３に示すように、例えば字幕データ５５０には少なくとも字幕時刻５５２とテキスト本文５５４とが含まれている。本実施形態では、説明の簡単化のため、番組付加データのうち字幕データのみを扱うが、字幕以外の番組付加データから、時刻とテキストのセットを抽出してもよい。例えば、番組情報のうち（番組開始時刻ｓｔｔｉｍｅ, 題名ｔｉｔｌｅ）を１セットとして、字幕データ列の先頭に付加してもよい。
【０１１４】
そして、インデックス付与部４９２は、字幕データ列に１つ以上字幕データが残っているか否か判定し（Ｓ５１２）、残っていれば（Ｓ５１２におけるＹＥＳ）、字幕データ列の先頭から字幕データを１つ取り出し、字幕時刻５５２を時刻変数ＰＯＳＴＩＭＥへ代入し、テキスト本文５５４をテキスト変数ＴＥＸＴ２に代入し、その字幕データ列から対象の字幕データを削除する（Ｓ５１４）。インデックス付与部４９２は、さらにテキスト変数ＴＥＸＴ２に対して、１つ以上の改行や記号や空白を１つの空白に置換する字句解析を行い（Ｓ５１６）、形態素辞書を用いて、形態素に分割する（Ｓ５１８）。このとき、インデックス付与部４９２として機能する形態素エンジンでは、空白を形態素間の区切りとする。以上は字幕データ列を形態素列に分割する処理であり、ＣＡＰＮＵＭ個分繰り返される。また、字幕データ列に字幕データが残っていない場合（Ｓ５１２におけるＮＯ）、形態素残り判定ステップＳ５２０に移行する。
【０１１５】
続いて、インデックス付与部４９２は、字幕データの形態素列に形態素が１つ以上残っているか否か判定し（Ｓ５２０）、残っていれば（Ｓ５２０におけるＹＥＳ）、先頭の形態素を１つ取り出して形態素変数ＷＯＲＤへ代入し、その形態素列から対象の形態素を削除し（Ｓ５２２）、インデックス保持部４７０のインデックステーブルに（ｗｏｒｄ，ｐｏｓｔｉｍｅ，ｓｅｒｖｉｃｅｉｄ，ｅｖｅｎｔｉｄ）＝（ＷＯＲＤ，ＰＯＳＴＩＭＥ，ＳＥＲＶＩＣＥＩＤ，ＥＶＥＮＴＩＤ）となるレコードを追加する（Ｓ５２４）。なお、インデックステーブルは、上述したように、検索語ｗｏｒｄと、検索時刻ｐｏｓｔｉｍｅと、該当番組のサービスＩＤ：ｓｅｒｖｉｃｅｉｄと、該当番組のイベントＩＤ：ｅｖｅｎｔｉｄとの組み合わせがユニークになるので、同一番組の同一時刻の字幕データに同一の単語が複数現れた場合は、２つ目以降のレコードを無視することとする。
【０１１６】
また、形態素列に形態素が残っていなければ（Ｓ５２０におけるＮＯ）、インデックス付与部４９２は、以下の式３を用いて字幕率ＣＳＴを算出する（Ｓ５２６）。このとき、（番組終了時刻ｅｄｔｉｍｅ−番組開始時刻ｓｔｔｉｍｅ）の結果は秒換算して用いるものとし、字幕率ＣＳＴは１秒あたりの字幕データ数を表す。
ＣＳＴ  ＝  ＣＡＰＮＵＭ  ／  （ｅｄｔｉｍｅ−ｓｔｔｉｍｅ）    …（式３）
統計上、字幕がついているとみなせる番組の字幕率ＣＳＴは０．１〜０．２５の間の値をとるので、第２閾値β＝０．１として判定し、インデックス付与部４９２は、字幕率ＣＳＴが第２閾値β以上であるか否か判定する（Ｓ５２８）。字幕率ＣＳＴが第２閾値β以上であれば（Ｓ５２８におけるＹＥＳ）、字幕データ列が有効であると見なして、番組情報保持部４６６の番組情報テーブルにおける該当レコードの字幕フラグｃａｐｆｌｇを１（字幕データあり）に設定し（Ｓ５３０）、番組情報残り判定ステップＳ５０４から繰り返す。ここでは、番組付加データのうち、字幕データに関する出現率（字幕率）を第２閾値βと比較しているが、同様に、番組情報のテキスト本文のデータ総数を第３閾値と比較して字幕データ列の有効性を判断してもよい。
【０１１７】
また、同様に、Ｓ５１８で出力された形態素列の形態素数を第４閾値と比較して字幕データ列の有効性を判断してもよい。
【０１１８】
一方、字幕率ＣＳＴが第２閾値β未満であった場合（Ｓ５２８におけるＮＯ）、字幕データ列がインデックスデータとして十分ではないと判定し、データ取得部４８２およびデータ加工部１８４に対して、番組開始時刻ｓｔｔｉｍｅから番組終了時刻ｅｄｔｉｍｅの時刻範囲に含まれる投稿データを取得および加工させる（Ｓ５３２）。かかる加工された投稿データは、中央制御部４６２のＲＡＭに設けられた出力バッファに蓄積される。投稿データ取得ステップＳ５３２は、第１の実施形態において図７を用いて説明した処理と実質的に等しいので、ここではその説明を省略する。ここで、字幕データ列がインデックスデータとして十分ではないとは、ニュースや生放送といったような予めその放送内容を提示できないものに関しては、字幕データが含まれていない、または、含まれていたとしても表題等の極限られた情報のみしかないので信頼性が低いことを示し、そのような場合には、少ない字幕データを利用するより、投稿データを採用することとし、信頼性の向上を図る。
【０１１９】
続いて、インデックス付与部４９２は、出力バッファにレコードが残っているか否か判定し（Ｓ５３４）、残っていない場合（Ｓ５３４におけるＮＯ）、番組情報保持部４６６の番組情報テーブルにおける該当レコードの字幕フラグｃａｐｆｌｇを２（コメント有り）に設定し（Ｓ５３６）、番組情報残り判定ステップＳ５０４から繰り返す。
【０１２０】
また、出力バッファにレコードが残っている場合（Ｓ５３４におけるＹＥＳ）、インデックス付与部４９２は、レコードを取り出して、投稿日時ｐｏｓｔを時刻変数ＰＯＳＴＩＭＥへ代入し、形態素列ｗｌｉｓｔを取得する（Ｓ５３８）。
【０１２１】
続いて、インデックス付与部４９２は、レコードの形態素列に形態素が１つ以上残っているか否か判定し（Ｓ５４０）、残っていない場合（Ｓ５４０におけるＮＯ）、レコード残り判定ステップＳ５３４から繰り返す。
【０１２２】
レコードの形態素列に形態素が残っている場合（Ｓ５４０におけるＹＥＳ）、先頭の形態素を１つ取り出して形態素変数ＷＯＲＤへ代入し、その形態素列から対象の形態素を削除し（Ｓ５４２）、インデックス保持部４７０のインデックステーブルに（ｗｏｒｄ，ｐｏｓｔｉｍｅ，ｓｅｒｖｉｃｅｉｄ，ｅｖｅｎｔｉｄ）＝（ＷＯＲＤ，ＰＯＳＴＩＭＥ，ＳＥＲＶＩＣＥＩＤ，ＥＶＥＮＴＩＤ）となるレコードを追加する（Ｓ５４４）。
【０１２３】
インデックス付与部４９２により生成されたインデックスデータは、字幕等が多い番組は字幕データを検索の情報源として使うため、正確度が高く、字幕等が少ない番組は投稿データを検索情報源として使うため、広く浅く検索が可能なものとなる。
【０１２４】
図１４は、番組検索方法の処理の流れを説明したフローチャートである。特に、図１４では、番組検索方法のうち、番組の検索処理について説明している。まず、番組抽出部４９４は、ユーザから検索のためのキーワードの入力を受け付けると（Ｓ５７０におけるＹＥＳ）、キーワードを形態素変数ＷＯＲＤに代入する（Ｓ５７２）。そして、番組抽出部４９４は、インデックス保持部４７０のインデックステーブルを検索し（Ｓ５７４）、さらに検索結果の各行に含まれるサービスＩＤ：ｓｅｒｖｉｃｅｉｄ、イベントＩＤ：ｅｖｅｎｔｉｄを用い、番組情報保持部４６６の番組情報テーブルを検索して番組名等を取得し（Ｓ５７６）、検索結果である検索リストをユーザに表示する（Ｓ５７８）。
【０１２５】
図１５は、検索リストの表示例を示した説明図である。ユーザが検索のためのキーワードを入力領域６００に入力して、検索開始ボタン６０２をクリックすると、番組抽出部４９４は、そのキーワードに基づいてインデックスデータを検索し、検索されたインデックスデータに基づいて、図１５のように、番組情報をリスト化して表示する。ここで、番組抽出部４９４は、番組情報保持部４６６の番組情報テーブルにおける各レコードをユーザが分かり易いように置換加工し、適切にレイアウトに収めて表示する。例えば、図１５の例では、字幕フラグ（字幕：ｃａｐｆｌｇ＝１、コメント：ｃａｐｆｌｇ＝２）６０４、番組開始時刻６０６、番組終了時刻６０８、サービスＩＤ６１０、イベントＩＤ６１２が表示される。
【０１２６】
続いて、ユーザが検索リストのうち１つの番組を選択する選択入力を受け付けると（Ｓ５８０におけるＹＥＳ）、番組抽出部４９４は、番組情報保持部４６６から取得したチャンネル番号ｐｈｙｃｈと、インデックス保持部４７０から得られた検索時刻ｐｏｓｔｉｍｅを用いて番組保持部４６４を検索し（Ｓ５８２）、ＡＶデコード部１５８は、検索処理によって抽出された番組を表示装置１３０に表示させる（Ｓ５８４）。
【０１２７】
図１６は、表示装置１３０での表示例を示した説明図である。ここでは、ＧＵＩによる再生、停止、シーク等の動作モードを持つ典型的な表示装置１３０を起動する際、検索のためのキーワードに関連付けられた検索時刻６２０が再生開始点として選択されていることが分かる。
【０１２８】
このような、番組の検索処理によって、ユーザは、数千時間分の番組から、検索のためのキーワードに関連付けられた任意の番組または任意のシーンを閲覧することが可能となる。
【０１２９】
以上、説明した番組検索装置４２０および番組検索方法では、字幕データが含まれていない番組ストリームについて、他の経路、例えば、電子掲示板の投稿データから、インデックスデータに相当する情報を取得し、インデックスデータとして番組に関連付けることができるため、字幕データの有無に拘わらず、全ての番組にインデックスデータを付すことができ、番組の検索精度の向上を図ることが可能となる。
【０１３０】
また、投稿データをインデックスデータとして用いる際に、放送倫理規定に従うテキストデータに加工した投稿データのみをインデックスデータとすることで、公序良俗に反する単語や文章、対応する番組に無関係な当て字、アスキーアートによる無意味なテキストデータ等、不要なテキストデータを排除し、インデックスデータとして適当なテキストデータのみを番組に関連付けることが可能となる。こうして、インデックスデータのデータ容量が膨大になることや、不適当なインデックスデータによる検索精度の劣化を回避することができる。
【０１３１】
さらに、投稿データをフィルタリングして番組に関連付けるインデックスデータを制限することで、番組ストリームに予め含まれた字幕データと量的にバランスがとれることとなり、検索のヒット率が偏ることもない。また、フィルタリングが放送倫理規定に従って行われるので、加工された投稿データは、放送倫理規定に従ったテキストデータとなり、番組ストリームに予め含まれた字幕データと、放送倫理規定に従っている点でその単語や文章の質が等しくなる。このように、投稿データによるインデックスデータが関連付けられた番組と、字幕データによるインデックスデータが関連付けられた番組とが、インデックスデータの量や質においてバランスがとれるので、検索の均一性が保たれることとなり、ユーザは所望する番組およびその番組内の所定シーンを適切に抽出することが可能となる。
【０１３２】
また、第１の実施形態で説明したように、許可ワードテーブル２００をフィルタリング装置１２０内で閉じられた状態で更新するため、チューナー部１５２や通信部１５４を通じて効率的に許可ワードテーブル２００を生成することが可能となると共に、改竄の危険性を最小限に抑えつつ、フィルタリングを回避するためのゆらぎに関しても対応することが可能となる。
【０１３３】
また、許可ワードテーブル２００は、ユーザが住んでいる地域にある放送局１１２や、ユーザがもっぱら視聴する放送局１１２の番組付加データの生成特性を色濃く反映するので、地域性やユーザの好みに応じた許可ワードテーブル２００となり、結果的に、フィルタリングされた投稿データも地域性やユーザの好みに応じた単語が残り易くなる。
【０１３４】
以上、添付図面を参照しながら本発明の好適な実施形態について説明したが、本発明はかかる実施形態に限定されないことは言うまでもない。当業者であれば、特許請求の範囲に記載された範疇において、各種の変更例または修正例に想到し得ることは明らかであり、それらについても当然に本発明の技術的範囲に属するものと了解される。
【０１３５】
例えば、上述した実施形態においては、放送倫理規定に基づいて信頼性の高い番組付加データを用いる例を挙げているが、このような番組付加データに限られず、目的とする分野において、信頼性の高い単語または文章を自動的に取得できれば、本実施形態を様々な分野に適応することができる。
【０１３６】
なお、本明細書のフィルタリング方法や番組検索方法の各工程は、必ずしもフローチャートとして記載された順序に沿って時系列に処理する必要はなく、並列的あるいはサブルーチンによる処理を含んでもよい。
【符号の説明】
【０１３７】
１００、４００  …番組提供システム
１２０  …フィルタリング装置
１６０  …テーブル保持部
１８０  …テーブル更新部
１８２、４８２  …データ取得部
１８４  …データ加工部
２００  …許可ワードテーブル
４２０  …番組検索装置
４６４  …番組保持部
４９２  …インデックス付与部
４９４  …番組抽出部
【図１】
0005392228.tif 000002
【図２】
0005392228.tif 000003
【図３】
0005392228.tif 000004
【図４】
0005392228.tif 000005
【図５】
0005392228.tif 000006
【図６】
0005392228.tif 000007
【図７】
0005392228.tif 000008
【図８】
0005392228.tif 000009
【図９】
0005392228.tif 000010
【図１０】
0005392228.tif 000011
【図１１】
0005392228.tif 000012
【図１２】
0005392228.tif 000013
【図１３】
0005392228.tif 000014
【図１４】
0005392228.tif 000015
【図１５】
0005392228.tif 000016
【図１６】
0005392228.tif 000017