説明

フィルタリング装置およびフィルタリング方法

【課題】テキストデータを適切にフィルタリングする。
【解決手段】フィルタリング装置120は、番組ストリームに含まれる字幕データまたは番組情報を抽出し、形態素に分割して、その形態素を許可ワードテーブル200に登録し、出現回数を更新するテーブル更新部180と、任意のテキストデータを取得するデータ取得部182と、任意のテキストデータを形態素に分割し、分割した形態素が許可ワードテーブルに登録されていない、または、分割した形態素が許可ワードテーブルに登録されているが、その形態素に対応した出現回数が予め定められた第1閾値未満であれば、形態素を、予め定められた記号に置換し、テキストデータとして再結合するデータ加工部184とを備える。

【発明の詳細な説明】
【技術分野】
【0001】
本発明は、任意の手順に従ってテキストデータを加工するフィルタリング装置およびフィルタリング方法に関する。
【背景技術】
【0002】
近年、パーソナルコンピュータや携帯電話等の情報端末が普及し、インターネット等の通信網を介して、様々なサービスの提供を、昼夜を問わず容易に受けることが可能となった。このように情報端末が身近になると、成人のみならず未成年者も情報端末に触れる機会が多くなり、未成年者が単独でサービスの提供を受けることも少なくない。
【0003】
通信網を介してアクセス可能なサービスは有用なものも少なくはないが、例えば、第三者が自身の意見や他のユーザに知らせたいことを自由に投稿可能な電子掲示板等のソーシャルサービスでは、誹謗中傷や、猥雑な単語の連呼、暴力的な表現等、公序良俗に反する単語や文章が電子掲示板に投稿されている場合がある。このような公序良俗に反する単語や文章は、成人にも影響するが、特に未成年に悪影響を及ぼすおそれがある。したがって、未成年者が単独で情報端末を利用する際には、このような公序良俗に反する単語や文章を未成年者に見せないようにする仕組みが望まれる。
【0004】
国内では、「政令第三百七十八号 青少年が安全に安心してインターネットを利用できる環境の整備等に関する法律施行令」等の法令が規定され、サービス提供者(サービス提供サーバ)に対して、上述した公序良俗に違反するような情報に未成年者が触れないよう、情報をフィルタリングすることが義務づけられている。しかし、フィルタリングを厳格に遂行し、公序良俗に反する可能性があるだけでサービス自体を排除すると、本来、利用可能なサービスまでも強制的に排除されてしまうこととなる。そこで、ユーザの情報端末から受信したアクセス要求に応じ、中継装置が、サービス提供者から提供されるウェブコンテンツを一旦取得、解析し、アクセスの可否を判断して、アクセス可能と判断したウェブコンテンツのみをユーザに提供する技術が知られている(例えば、特許文献1)。
【先行技術文献】
【特許文献】
【0005】
【特許文献1】特開2006−209568号公報
【発明の概要】
【発明が解決しようとする課題】
【0006】
サービス提供者は、上述した法令等を遵守するため、サービスとして使用すべきでない単語(禁止ワード)をテーブル化した禁止ワードテーブルを保持し、その禁止ワードテーブルを参照して、例えば、電子掲示板に投稿された投稿データに対し、禁止ワードに該当する単語を排除する。しかし、この禁止ワードを排除するフィルタリング技術では、例えば、禁止ワードを他の漢字(当て字)に変更したり、文字間に空白や記号を挿入したりして、その単語に「ゆらぎ」を加え、禁止ワードに一致させないようにすることで、フィルタリングされるのを容易に回避することができる。そのため、禁止ワードの生成に関しては、投稿者とサービス提供者との鼬ごっことなっている。結果として、サービス提供者は、投稿データに含まれる個々の単語の排除を諦め、未成年者によるサービス提供サーバへのアクセス自体を禁止することとなってしまい、未成年者は、サービスの信頼性に拘わらず、サービス自体の提供を受けることができないといった問題が生じていた。
【0007】
また、上述した「ゆらぎ」によるフィルタリング回避を防止するために、禁止ワードをテーブル化した禁止ワードテーブルではなく、許可可能な単語(許可ワード)をテーブル化した許可ワードテーブルを用いて、公序良俗に反していない単語や文章のみを通過させることも考えられる。しかし、人物や建造物といった単語は、日々新たに出現しており、このような許可ワードがフィルタリングによって排除されないようにするには、許可ワードテーブルの更新頻度を高めなくてはならない。また、ワードテーブルを生成する上で、禁止ワードテーブルに対し許可ワードテーブルの必要単語数は著しく多く、そのワードテーブルの配信や更新に膨大なコストを要することとなる。
【0008】
そこで本発明は、このような課題に鑑み、テキストデータを適切にフィルタリングすることが可能な、フィルタリング装置およびフィルタリング方法を提供することを目的としている。
【課題を解決するための手段】
【0009】
上記課題を解決するために、本発明は下記のフィルタリング装置およびフィルタリング方法を提供するものである。
(1)複数の形態素とその出現回数とを対応付けた許可ワードテーブルを保持するテーブル保持部と、放送倫理規定に沿って生成された番組ストリームを取得する番組ストリーム取得部と、取得された前記番組ストリームに字幕データまたは番組の内容に関する第1のテキストデータである番組情報が含まれている場合、前記番組ストリームから前記字幕データまたは前記番組情報を抽出し、形態素に分割して、分割した前記形態素が前記許可ワードテーブルに無ければ、その形態素を前記許可ワードテーブルに登録し、分割した前記形態素が前記許可ワードテーブルに有れば、前記形態素に対応した出現回数を更新するテーブル更新部と、任意の第2のテキストデータを取得するデータ取得部と、前記第2のテキストデータを形態素に分割し、分割した前記形態素が前記許可ワードテーブルに登録されていない、または、分割した前記形態素が前記許可ワードテーブルに登録されているが、その形態素に対応した出現回数が予め定められた第1閾値未満であれば、前記形態素を、予め定められた記号に置換し、第3のテキストデータとして再結合するデータ加工部と、を備えることを特徴とするフィルタリング装置。
(2)複数の形態素とその出現回数とを対応付けた許可ワードテーブルを保持するテーブル保持部と、放送倫理規定に沿って生成された、番組の内容に関する第1のテキストデータである番組情報を取得する番組情報取得部と、前記番組情報を形態素に分割し、分割した前記形態素が前記許可ワードテーブルに無ければ、その形態素を前記許可ワードテーブルに登録し、分割した前記形態素が前記許可ワードテーブルに有れば、前記形態素に対応した出現回数を更新するテーブル更新部と、任意の第2のテキストデータを取得するデータ取得部と、前記第2のテキストデータを形態素に分割し、分割した前記形態素が前記許可ワードテーブルに登録されていない、または、分割した前記形態素が前記許可ワードテーブルに登録されているが、その形態素に対応した出現回数が予め定められた第1閾値未満であれば、前記形態素を、予め定められた記号に置換し、第3のテキストデータとして再結合するデータ加工部と、を備えることを特徴とするフィルタリング装置。
(3)前記第2のテキストデータは、前記番組に対して電子掲示板に投稿された投稿データであり、前記データ加工部によって前記第3のテキストデータとして再結合された前記投稿データを、取得された前記番組ストリームの番組と共に表示装置に表示させる表示制御部をさらに備えることを特徴とする上記(1)または(2)に記載のフィルタリング装置。
(4)放送倫理規定に沿って生成された番組ストリームを取得し、取得した前記番組ストリームに字幕データまたは番組の内容に関する第1のテキストデータである番組情報が含まれている場合、前記番組ストリームから前記字幕データまたは前記番組情報を抽出し、形態素に分割して、分割した前記形態素が、複数の形態素とその出現回数とを対応付けた許可ワードテーブルに無ければ、その形態素を前記許可ワードテーブルに登録し、分割した前記形態素が前記許可ワードテーブルに有れば、前記形態素に対応した出現回数を更新し、任意の第2のテキストデータを取得し、前記第2のテキストデータを形態素に分割し、分割した前記形態素が前記許可ワードテーブルに登録されていない、または、分割した前記形態素が前記許可ワードテーブルに登録されているが、その形態素に対応した出現回数が予め定められた第1閾値未満であれば、前記形態素を、予め定められた記号に置換し、第3のテキストデータとして再結合することを特徴とするフィルタリング方法。
(5)放送倫理規定に沿って生成された、番組の内容に関する第1のテキストデータである番組情報を取得し、前記番組情報を形態素に分割し、分割した前記形態素が、複数の形態素とその出現回数とを対応付けた許可ワードテーブルに無ければ、その形態素を前記許可ワードテーブルに登録し、分割した前記形態素が前記許可ワードテーブルに有れば、前記形態素に対応した出現回数を更新し、任意の第2のテキストデータを取得し、前記第2のテキストデータを形態素に分割し、分割した前記形態素が前記許可ワードテーブルに登録されていない、または、分割した前記形態素が前記許可ワードテーブルに登録されているが、その形態素に対応した出現回数が予め定められた第1閾値未満であれば、前記形態素を、予め定められた記号に置換し、第3のテキストデータとして再結合することを特徴とするフィルタリング方法。
【発明の効果】
【0010】
本発明によれば、テキストデータを適切にフィルタリングすることが可能となる。
【図面の簡単な説明】
【0011】
【図1】第1の実施形態における番組提供システムの概略的な接続関係を示した説明図である。
【図2】フィルタリング装置の概略的な構成を示した機能ブロック図である。
【図3】許可ワードテーブルを説明するための説明図である。
【図4】投稿データをレンダリングする例を示した説明図である。
【図5】フィルタリング方法の処理の流れを説明したフローチャートである。
【図6】テーブル更新部の処理を説明するための説明図である。
【図7】フィルタリング方法の処理の流れを説明したフローチャートである。
【図8】投稿データ群を例示した説明図である。
【図9】データ加工部の処理を説明するための説明図である。
【図10】第2の実施形態における番組提供システムの概略的な接続関係を示した説明図である。
【図11】番組検索装置の概略的な構成を示した機能ブロック図である。
【図12】番組検索方法の処理の流れを説明したフローチャートである。
【図13】番組付加データのうちの字幕データの一例を示した説明図である。
【図14】番組検索方法の処理の流れを説明したフローチャートである。
【図15】検索リストの表示例を示した説明図である。
【図16】表示装置での表示例を示した説明図である。
【発明を実施するための形態】
【0012】
以下に添付図面を参照しながら、本発明の好適な実施形態について詳細に説明する。かかる実施形態に示す寸法、材料、その他具体的な数値などは、発明の理解を容易とするための例示にすぎず、特に断る場合を除き、本発明を限定するものではない。なお、本明細書及び図面において、実質的に同一の機能、構成を有する要素については、同一の符号を付することにより重複説明を省略し、また本発明に直接関係のない要素は図示を省略する。
【0013】
ここでは、第1の実施形態として、任意のテキストデータを適切にフィルタリングするフィルタリング装置およびフィルタリング方法を説明し、第2の実施形態として、第1の実施形態におけるフィルタリング技術を用い、番組およびその番組内の所定シーンを適切に検索する番組検索装置および番組検索方法を説明する。両実施形態は少なくともフィルタリング技術に関して共通している。
【0014】
フィルタリング技術としては、一般的に、サービスに使用すべきではない、公序良俗に反する単語(禁止ワード)をテーブル化した禁止ワードテーブルを用いることが多く、サービス提供者は、禁止ワードテーブルを参照して、例えば、電子掲示板に投稿された投稿データに対し禁止ワードに該当する単語を排除するといったフィルタリングを実行している。しかし、この禁止ワードを排除するフィルタリングでは、禁止ワードを他の漢字(当て字)に変更したり、文字間に空白や記号を挿入したりして、その単語に「ゆらぎ」を加え、禁止ワードに一致させないようにすることで、フィルタリングされるのを容易に回避することができる。
【0015】
これは、禁止ワードに該当する単語を当て字に変更したり、記号を加えても、その単語の意味するところを他人に伝達できることに因る。そうすると、禁止すべき単語は、禁止ワード毎に相異なる表示態様が無数あることになり、サービス提供者は、禁止ワード自体を特定、排除できたとしても、その禁止ワードに対する無数の表示態様を全て排除することはできない。
【0016】
このような禁止ワードの無数の表示態様までを排除するには、禁止ワードをテーブル化した禁止ワードテーブルではなく、許可可能な単語(許可ワード)をテーブル化した許可ワードテーブルを用いて、公序良俗に反していない単語や文章のみを残すようにすればよい。しかし、人物や建造物といった単語は、日々新たに出現しており、このような許可ワードがフィルタリングによって排除されないようにするには、許可ワードテーブルの更新頻度を高めなくてはならない。
【0017】
しかし、現状では、許可ワードテーブルを利用しているサービス提供者はなく、許可ワードテーブルを各ユーザの情報端末に配信するシステムは構築されていない。そもそも、ワードテーブルを生成する上で、禁止ワードテーブルに対し許可ワードテーブルの必要単語数は著しく多く、例えば、1ヶ月に生じる禁止ワードが約4000ワードであるのに対して、許可ワードは約400万ワードであり、そのワードテーブルの配信や更新に膨大なコストを要することとなるので、許可ワードテーブルを用いるのは現実的ではなかった。
【0018】
そこで、第1の実施形態では、テレビジョン放送等の番組提供システムを用いて、フィルタリングのための許可ワードテーブルを自動的に形成する。
【0019】
(第1の実施形態:番組提供システム100)
図1は、第1の実施形態における番組提供システム100の概略的な接続関係を示した説明図である。番組提供システム100は、番組提供装置110と、フィルタリング装置120と、表示装置130と、サービス提供サーバ140とを含んで構成される。
【0020】
番組提供装置110は、放送局112や番組提供サーバ114で構成され、番組ストリームを配信する。番組ストリームには、番組そのものに加えて、番組に関する様々な情報が付加データとして含まれている。
【0021】
フィルタリング装置120は、番組提供装置110としての放送局112からアンテナ122を通じて、また、番組提供装置110としての番組提供サーバ114からインターネット等の通信網124を通じて、地上波デジタル放送、BS・CSデジタル放送、ケーブルテレビ放送、IP放送、ビデオオンデマンド等、様々な番組の番組ストリームを受信し、番組ストリームに含まれる字幕データや番組の内容に関する第1のテキストデータである番組情報を利用してフィルタリングを行うための許可ワードテーブルを生成する。また、フィルタリング装置120は、生成された許可ワードテーブルを用いて、任意のテキストデータをフィルタリングする。
【0022】
表示装置130は、液晶ディスプレイ、有機EL(Electro Luminescence)ディスプレイ、シネマスクリーン、プロジェクタ(投影機)等で構成され、フィルタリング装置120で受信された番組や、フィルタリングされたテキストデータを表示する。
【0023】
サービス提供サーバ140は、サービス提供者が運営するサーバであり、第三者が投稿データを投稿する電子掲示板等の様々なサービスを、第三者が有する情報端末やフィルタリング装置120等に提供する。
【0024】
本実施形態の番組提供システム100を構成するフィルタリング装置120は、テキストデータを適切にフィルタリングすることを目的としている。以下、フィルタリング装置120を構成する各機能部について説明し、その後、フィルタリング装置120を用いたフィルタリング方法を詳述する。
【0025】
(フィルタリング装置120)
図2は、フィルタリング装置120の概略的な構成を示した機能ブロック図である。フィルタリング装置120は、操作部150と、チューナー部152と、通信部154と、DEMUX(DEMUltipleXer)部156と、AVデコード部158と、テーブル保持部160と、中央制御部162とを含んで構成される。ここで、チューナー部152と、通信部154と、DEMUX部156とは番組ストリームを取得する番組ストリーム取得部として機能する。図2では、データの流れを実線の矢印で表し、制御信号の流れを破線の矢印で表している。
【0026】
操作部150は、操作キー、十字キー、ジョイスティック、ジョグダイヤル、タッチパネル等のスイッチから構成され、ユーザの操作入力を受け付ける。
【0027】
チューナー部152は、アンテナ122を介して放送局112から放送信号を受信し、操作部150を通じて設定されたチャンネル番号に従って放送信号を復調して番組ストリームを生成する。
【0028】
通信部154は、通信網124を介して番組提供サーバ114との通信を確立し、HTTP(HyperText Transfer Protocol)に類するインターネット・プロトコルを用いて、チューナー部152同様、番組提供サーバ114が配信した、放送信号に相当するIPストリーミングをパケット単位で取得し、IPストリーミングをタイムスタンプに従って復元して番組ストリームを生成する。また、通信部154は、サービス提供サーバ140との通信を確立することもできる。
【0029】
DEMUX部156は、番組ストリームを、例えば、映像データ(MPEG(Moving Picture Experts Group)ビデオストリーム)、音声データ(MPEG音声ストリーム)、字幕データ、時刻データ、番組情報といった複数のデータに分離する。
【0030】
AVデコード部158は、DEMUX部156から映像データおよび音声データを取得し、映像信号および音声信号にデコードして、デコードした映像信号を表示装置130に出力する。なお、音声信号は図示しないスピーカ等の音声出力装置に出力する。
【0031】
テーブル保持部160は、フラッシュメモリ、HDD(Hard Disk Drive)等の記憶媒体で構成され、複数の形態素とその出現回数とを対応付けた許可ワードテーブルを保持する。なお、HDDは正確には装置であるが、説明の便宜上本説明では他の記憶媒体と同義として扱う。
【0032】
中央制御部162は、中央処理装置(CPU)、プログラム等が格納されたROM、ワークエリアとしてのRAM等を含む半導体集積回路により、フィルタリング装置120全体を管理および制御する。また、本実施形態において、中央制御部162は、テーブル更新部180、データ取得部182、データ加工部184、表示制御部186としても機能する。
【0033】
テーブル更新部180は、番組ストリーム取得部としてのチューナー部152や通信部154を介して取得された番組ストリームに、字幕データまたは第1のテキストデータである番組情報が含まれている場合、番組ストリームから字幕データまたは番組情報のいずれか一方もしくは両方を抽出し、形態素に分割して、分割した形態素が、後述する許可ワードテーブルになければ、その形態素を登録し、分割した形態素が許可ワードテーブルにあれば、形態素に対応した出現回数を更新する。ここで、字幕データは、映画やテレビジョン等の映像メディアにおいて、題名、配役、解説、会話等の情報を、文字を用いて表示するためのテキストデータを言う。また、番組情報は、チャンネル番号、サービスID、イベントID、番組開始時刻、番組終了時刻、番組名、番組の解説情報、番組の出演者やスタッフの情報、主題歌に関する情報、番組のジャンル等、番組の内容に関する様々な情報を含んでいる。以下では、説明の便宜のため、字幕データまたは番組情報のいずれか一方もしくは両方を番組付加データと略す。また、説明によっては番組付加データが字幕データまたは番組情報の一方を示す場合もある。
【0034】
具体的に、テーブル更新部180は、チューナー部152や通信部154を介して取得された番組ストリームに番組付加データが含まれているか否か判定し、番組付加データが含まれていれば、その番組付加データを、形態素辞書を用いて1または複数の形態素に分割する。ここで、形態素辞書は、予め大量の文章を集計し、各形態素と、形態素の前後に連接する形態素の連接確率を、辞書形式にしたものである。形態素辞書を用いることで日本語のような区切りのない自然言語を形態素単位に分割することができる。また、分割した形態素が形態素辞書にない場合、テーブル更新部180は、漢字、英数字、かな、カタカナ等の文字種の区切りを利用して形態素に分割する。形態素に分割する形態素解析エンジンとしては、自然言語の「分かち」を統計的な手法によって推測し、形態素単位に分割する技術も利用することができる。なお、形態素辞書を用いた形態素への分割アルゴリズムの詳細については公知技術であるため記載を省略する。
【0035】
続いて、テーブル更新部180は、分割された各形態素を許可ワードテーブルに登録、または登録された形態素の出現回数を更新する。
【0036】
図3は、許可ワードテーブル200を説明するための説明図である。許可ワードテーブル200は、前連接形態素pwordと、主形態素wordと、出現回数wnumとが一意に関連付けられたテーブル構造を成している。ここで、前連接形態素pwordは、分割された形態素列において主形態素wordの前に位置する形態素であり、主形態素wordが文章の先頭の形態素であった場合、空値(NULL)となる。主形態素wordは、主たるキーワードとなる形態素であり空値は許されない。したがって、テーブル更新部180は、文章が「総理の命を受け、」であった場合、「総理」を主形態素wordとして、前連接形態素pwordが「NULL」となるレコード202を生成しても、「受け」を前連接形態素pwordとして、主形態素wordが「NULL」となるレコードは生成しない。出現回数wnumは、前連接主形態素pwordと主形態素wordの組み合わせが番組付加データ中に出現した回数であり1以上の整数で表される。
【0037】
テーブル更新部180は、分割した形態素に関して、前後2つの形態素の組み合わせが許可ワードテーブル200になければ、その2つの形態素の組み合わせを登録し、前後2つの形態素の組み合わせが許可ワードテーブル200にあれば、その組み合わせに対応した出現回数をインクリメント(+1)する。したがって、許可ワードテーブル200では、前連接形態素pwordと主形態素wordとの組み合わせがユニークになる。かかる許可ワードテーブル200を生成するための命令文を、例えばデータベース記述言語であるSQL(Structured Query Language)を用いて表すと、以下のように記述できる。
create table allowing_word_table(
pword text,
word text not null,
wnum integer,
UNIQUE(pword, word)
);
【0038】
本実施形態では、許可ワードテーブル200を、番組ストリームに含まれる番組付加データを用いて生成しているので、以下の効果を得ることができる。即ち、番組および番組付加データは放送倫理規定に従って生成されている。放送倫理規定は、例えば、放送倫理基本綱領に、「適正な言葉を用いると同時に、品位ある表現を心掛けるようつとめる」と規定され、放送倫理規定に従って生成された番組付加データには、公序良俗に反する単語や文章が含まれていない。したがって、番組ストリームに含まれる番組付加データに基づいて許可ワードテーブル200を生成すれば、個々の単語が許可ワードに相当するか否かの判断を要することなく、許可ワードを容易に蓄積することができる。
【0039】
また、番組ストリームを受信する機能自体は確立されているため、データ容量が大きい許可ワードテーブル200を各ユーザの情報端末に配信するシステムを新たに構築しなくとも、フィルタリング装置120内で番組ストリームに含まれる番組付加データを抽出するだけで、許可ワードテーブル200を随時更新することができる。したがって、最低限の維持コストで、許可ワードテーブル200を随時更新することが可能なシステムを構築することができる。
【0040】
ここで、仮に、データ容量が大きい許可ワードテーブル200を各ユーザの情報端末に配信するシステムが構築されたとしても、許可ワードテーブル200を情報端末に配信する際に第三者が許可ワードテーブル200を改竄する危険性が残る。本実施形態では、許可ワードテーブル200をフィルタリング装置120内の閉ざされた空間で更新するため、そのような改竄の危険性を最小限に抑えることができる。
【0041】
本実施形態では、このような目的の下、主としてチューナー部152を通じて取得された番組ストリームに含まれる番組付加データを採用するが、放送倫理規定に準じてさえいれば、例えば、ケーブルテレビ放送、IP放送、ビデオオンデマンド等を実施している番組提供サーバ114から取得された番組ストリームの番組付加データを採用することができる。
【0042】
また、番組ストリームの提供と独立してEPG(Electronic Program Guide)を提供しているサービス事業者もある。このようなサービス事業者が管理するサーバ(図示せず)からは、上述した番組情報を直接取得することができ、番組情報が放送倫理規定に準じてさえいれば、その番組情報を本実施形態に採用することができる。この場合、通信部154が番組情報を取得する番組情報取得部として機能し、テーブル更新部180は、番組情報取得部としての通信部154が取得した番組情報を形態素に分割して、許可ワードテーブル200に反映する。説明の便宜のため、以下では、番組ストリームから番組付加データ、即ち、字幕データや番組情報を抽出して許可ワードテーブル200に反映する構成を挙げているが、通信部154を通じて取得した番組情報も本実施形態の許可ワードテーブル200に採用可能なのは言うまでもない。
【0043】
データ取得部182は、通信部154を通じてサービス提供サーバ140から任意のテキストデータ(第2のテキストデータ)を取得すると共に、任意のテキストデータが生成、投稿、または、取得された日時を示す取得日時情報を任意のテキストデータに関連付ける。例えば、任意の放送局112で放送されている番組に関する投稿データを電子掲示板として公開しているサービス提供サーバ140があれば、データ取得部182は、その電子掲示板から投稿データを取得し、取得日時情報として、その投稿があった日時を投稿データに関連付ける。
【0044】
このような電子掲示板(実況電子掲示板)や実況ブログ(日記)では、特定の放送局112で放送されている一連の番組について、通信網124を介し、不特定多数の投稿者が、恰も実況中継を行っているが如く、ほぼリアルタイムに投稿データを投稿し合っている。本実施形態において、データ取得部182は、このような任意の放送局112専用に設けられた電子掲示板から投稿データを取得する。
【0045】
また、データ取得部182は、投稿専用サイトにおいて、任意の放送局112に関するスレッドのタイトルを指定し、その投稿データを取得してもよい。また、放送局112が独自に自局に対する意見等を募集するサイトを運営している場合、データ取得部182は、そのようなサイトを通じて投稿データを取得してもよい。
【0046】
このような投稿データはリアルタイム性が高いため、例えば、データ取得部182が取得した投稿データを、投稿対象である、番組ストリーム取得部が取得した番組ストリームの番組と共に表示装置130に表示することで、ユーザは、番組と並行して、その番組に関する意見や説明をほぼリアルタイムに閲覧することができる。
【0047】
なお、番組情報提供サーバ114から送信される番組ストリームの番組に対しても、上記と同様に投稿データを取得してもよい。しかし、この場合、番組情報提供サーバ114が送信する番組ストリームの番組は、放送局112から地上波デジタル放送、BS・CSデジタル放送、ケーブルテレビ放送等で放送される番組とほぼ同時刻に再送信される番組に限定される。
【0048】
データ加工部184は、データ取得部182が取得したテキストデータ(第2のテキストデータ)をフィルタリングして新たなテキストデータ(第3のテキストデータ)を生成する。例えば、上述したようにデータ取得部182が、サービス提供サーバ140から投稿データを取得している場合、データ加工部184は、その投稿データをフィルタリングして新たな投稿データを生成する。
【0049】
具体的に、データ加工部184は、まず、データ取得部182が取得したテキストデータ(第2のテキストデータ)を、上述した形態素辞書を用いて形態素に分割する。そして、データ加工部184は、分割した形態素(正確には、2つの形態素の組み合わせ)が許可ワードテーブル200に登録されているか否か判定し、許可ワードテーブル200に登録されている形態素に関しては、その出現回数が予め定められた第1閾値α以上であるか否か判定する。
【0050】
このとき、形態素が許可ワードテーブル200に登録されていない、または、形態素が許可ワードテーブル200に登録されているが、その形態素に対応した出現回数が第1閾値α未満であれば、データ加工部184は、形態素を、予め定められた1または複数の記号に置換して、分割した形態素をテキストデータ(第3のテキストデータ)として再結合する。したがって、新たに生成されたテキストデータには、許可ワードテーブル200に登録された形態素のみが残ることとなる。
【0051】
表示制御部186は、データ加工部184で加工されたテキストデータを、テキスト字幕状の画像にレンダリングして、そのレンダリング画像を、表示装置130に表示させる。
【0052】
図4は、投稿データをレンダリングする例を示した説明図である。上述したように、データ取得部182が、サービス提供サーバ140から投稿データ(第2のテキストデータ)を取得している場合に、データ加工部184によってフィルタリングされた投稿データ(第3のテキストデータ)を、表示装置130における番組の表示領域210の下に設けられた投稿データ領域212に表示することで、ユーザは、番組と並行してその投稿データを閲覧することが可能となる。このとき閲覧している投稿データは、データ加工部184でフィルタリングされているため、公序良俗に反する単語や文章を含んでいない。したがって、未成年であっても、何ら問題なくその投稿データを視聴することが可能となる。
【0053】
(フィルタリング方法)
図5は、フィルタリング方法の処理の流れを説明したフローチャートである。特に、図5では、フィルタリング方法のうち、許可ワードテーブル200を生成する処理について説明している。
【0054】
DEMUX部156が番組ストリームに番組付加データが有ることを検出すると(S300におけるYES)、テーブル更新部180は、DEMUX部156から番組付加データのテキスト本文を取得し(S302)、テキスト本文の字句解析を行い、テキスト本文中の1字以上の句読点、改行、記号および外字(予め定められた漢字、英数字、かな、カタカナ以外の文字)を特殊記号(例えば「■」)に置換する(S304)。このとき、句読点等が連続して記載されている場合、連続する全ての句読点等を合わせて1つの特殊記号に置換する。このように字句解析を行い、句読点等を特殊記号に置換する処理によって、番組付加データ特有のレイアウトに用いられる記号や空白により、許可ワードテーブル200に無駄に形態素が登録されるのを回避でき、検索に必要な形態素のみを蓄積することが可能となる。
【0055】
そして、テーブル更新部180は、形態素辞書を用いて、句読点等が置換されたテキスト本文を形態素に分割する(S306)。このとき、テーブル更新部180として機能する形態素エンジンでは、置換された特殊記号を形態素間の区切りとする。
【0056】
図6は、テーブル更新部180の処理を説明するための説明図である。ここでは、テキスト本文中の改行文字を(改行)、空白文字を(空白)で表している。例えば、番組ストリームに含まれている番組付加データのうちの字幕データが、図6(a)のようなテキストデータであった場合、テーブル更新部180は、「>>」、「、」、「。」、(改行)、(空白)といった句読点等を纏めて特殊記号「■」に置換し、さらに形態素に分解して、図6(b)のような形態素列を形成する。ここでは理解を容易にするため、形態素間に[/]の記号を挿入しているが、実際に存在する記号として扱うものではない。
【0057】
続いて、テーブル更新部180は、前連接形態素変数PREVを初期化(空値NULLを代入)し(S308)、許可ワードテーブル200の登録判定が為されていない形態素(形態素列)が残っているか否か判定し(S310)、残っていないと判定されると(S310におけるNO)、当該許可ワードテーブル200を生成する処理を終了する。登録判定が為されていない形態素がまだ残っていれば(S310におけるYES)、テーブル更新部180は、許可ワードテーブル200の登録判定が為されていない形態素列の先頭にある形態素を1つ取り出して、形態素変数WORDに代入し、その形態素列から対象の形態素を削除する(S312)。
【0058】
次に、テーブル更新部180は、形態素変数WORDが特殊記号「■」であるか否か判定し(S314)、特殊記号である場合(S314におけるYES)、前連接形態素変数初期化ステップS308から繰り返す。
【0059】
形態素変数WORDが特殊記号でなければ(S314におけるNO)、テーブル更新部180は、前連接形態素変数PREVと形態素変数WORDの組み合わせが、許可ワードテーブル200の前連接形態素pwordと主形態素wordの組み合わせとして存在するか否か判定し(S316)、存在すれば(S316におけるYES)、その前連接形態素pwordと主形態素wordに対応する出現回数wnumをインクリメントし(S318)、存在しなければ(S316におけるNO)、前連接形態素変数PREVと形態素変数WORDの組み合わせを、前連接形態素pwordと主形態素wordの新たなレコードとして、許可ワードテーブル200に追加し、対応する出現回数wnumを1に設定する(S320)。
【0060】
そして、テーブル更新部180は、前連接形態素変数PREVに形態素変数WORDの値を代入し(S322)、形態素残り判定ステップS310から繰り返す。こうして、図6(b)に示した形態素列に基づいて、図3に示した許可ワードテーブル200が生成される。上述した処理では、分割された形態素が、形態素辞書に含まれていなくとも、許可ワードテーブル200に登録でき、出現回数を計数することができる。
【0061】
以上により生成された許可ワードテーブル200は、番組付加データに含まれる2つの形態素間の連接の様相と、その出現回数とを蓄積している。かかる連接の様相は、ユーザが住んでいる地域にある放送局112や、ユーザがもっぱら視聴する放送局112における番組付加データの生成特性を色濃く反映するので、許可ワードテーブル200は、地域性やユーザの好みに応じたものとなる。
【0062】
また、存在判定ステップS316において、前連接形態素pwordと主形態素wordの2つの連接を判定しているのは、公序良俗に反していない形態素を連接することで公序良俗に反するようになる文字列等を排除するためである。例えば、文字列「基地外」といった文字列が「基地の外」といった意味であっても、読み方によっては公序良俗違反となる。このとき、データ加工部184が、「基地」と「外」とをそれぞれ単独で判定した場合に、文字列「基地外」が排除されないおそれがある。放送倫理規定の下では、「基地外」の表現は用いられず、「基地の外」といった表現が為されるので、許可ワードテーブル200には、「基地」「の」または「の」「外」といった連接した形態素が登録され、「基地外」といった文字列を排除することが可能になる。
【0063】
また、ここでは、理解を容易にするため、対象となる形態素と1つ前の形態素との組み合わせを蓄積する例を挙げているが、連接するn個前までの形態素の組み合わせを許可ワードテーブル200に登録することで、形態素の組み合わせに対して厳密なフィルタリングを実行することが可能となる(形態素2個の場合、2gram法、n個前までの連接性を集計する場合をn−gram法と言う。)。
【0064】
また、アプリケーションによっては、テキスト本文に含まれる一部の記号等を置換せずに残したまま許可ワードテーブル200の登録判定を行ってもよい。本実施形態は、形態素辞書の生成元テキストデータとは異なるテキストデータから形態素の組み合わせと出現回数とを抽出することを目的としているので、上述した、番組ストリームに含まれる番組付加データ(字幕データや番組情報)のテキスト本文のみならず、番組ストリームに含まれ得る他の情報から形態素を抽出してもよい。
【0065】
また、ここでは、番組ストリームを、チューナー部152や通信部154から取得する例を挙げたが、記憶媒体に記憶している番組ストリームファイル等、放送倫理規定に準じてさえいれば、様々な経路から番組ストリームを取得することができる。さらに、チューナー部152とDEMUX部156との組み合わせを複数備えることで複数の放送局112から番組ストリームを並列に受信し、より多くの形態素を高速に収集してもよいし、許可ワードテーブル200を生成するための機能部を、番組視聴のための機能部と独立して動作させ、例えば、24時間連続して番組ストリームを受信させ、許可ワードテーブル200を生成させてもよい。
【0066】
図7は、フィルタリング方法の処理の流れを説明したフローチャートである。特に、図7は、フィルタリング方法のうち、図5で生成された許可ワードテーブル200を利用してテキストデータをフィルタリングする処理を説明している。
【0067】
まず、データ取得部182は、視聴している番組の番組ストリームに含まれる時刻データを取得し(S350)、開始時刻変数STIMEに、取得した時刻データから所定秒(例えば10秒)を減算した値を設定し、終了時刻変数ETIMEに時刻データを設定する(S352)。そして、データ取得部182は、サービス提供サーバ140から通信部154を介して、開始時刻変数STIMEから終了時刻変数ETIMEまでの時刻範囲に投稿された投稿データ群を取得し(S354)、中央制御部162のRAMに設けた出力バッファを初期化する(S356)。
【0068】
図8は、投稿データ群を例示した説明図である。例えば、データ取得部182は、DEMUX部156から時刻データ「2009年9月30日 17:45:40」を取得すると、時刻範囲(STIME,ETIME)=(「2009年9月30日 17:45:30」,「2009年9月30日 17:45:40」)に該当する投稿データ群を取得する。ここでは、図8に示すような、時刻データが「2009年9月30日 17:45:31」となっている投稿データと、時刻データが「2009年9月30日 17:45:38」となっている投稿データが該当する。
【0069】
データ加工部184は、フィルタリング処理が為されていない投稿データが残っているか否か判定し(S358)、残っていないと判定すると(S358におけるNO)、表示制御部186は、出力バッファに蓄積されている、フィルタリングが施された投稿データを表示装置130に表示させて(S360)、当該処理を終了する。
【0070】
出力バッファのテーブル構造を形成するための命令文は、SQLを用いて表すと、以下のように記述できる。
create table output_buffer (
post timestamp not null,
wlist text list,
UNIQUE(post)
);
かかる出力バッファは、投稿データの、投稿日時post(取得日時情報)と形態素列wlistとを組み合わせたテーブル構造で形成される。投稿日時postは投稿が行われた日時であり、形態素列wlistはフィルタリングが施された形態素列である。また、出力バッファは、投稿日時postについてユニークになるように設定されている。
【0071】
また、フィルタリング処理が為されていない投稿データが残っていれば(S358におけるYES)、残っている投稿データ群の先頭にある投稿データを1つ取り出して、投稿日時postを投稿日時変数POSTTIMEに代入し、投稿元データのテキスト本文をテキスト変数TEXTに代入し、その投稿データ群から対象の投稿データを削除する(S362)。データ加工部184は、テキスト変数TEXTに対し、2字以上の句読点は1文字の句読点(「。」、「.」、「、」、「,」等)へ置換し、かつ改行や記号や空白は削除する字句解析を行い(S364)、形態素辞書を用いて、字句解析が施された投稿データのテキスト本文を形態素に分割する(S366)。このとき、データ加工部184として機能する形態素エンジンでは、句読点を形態素間の区切りとする。
【0072】
続いて、データ加工部184は、前連接形態素変数PREVを初期化(空値NULLを代入)し(S368)、対象となる投稿データに形態素が残っているか否か判定し(S370)、残っていないと判定されると(S370におけるNO)、新たな投稿データを判定すべく、投稿データ残り判定ステップS358から繰り返す。
【0073】
対象となる投稿データに形態素が残っていれば(S370におけるYES)、投稿データのテキスト本文における形態素列の先頭から形態素を1つ取り出して形態素変数WORDに代入する(S372)。そして、データ加工部184は、形態素変数WORDが句読点または空白であるか否か判定し(S374)、句読点または空白であれば(S374におけるYES)、時刻判定ステップS382に移行する。
【0074】
ここで、字句解析ステップS364や句読点判定ステップS374は、句読点、空白、改行、記号の挿入(ゆらぎ)によって、意図していない位置で単語が分離し、形態素同士の連接関係を崩さないようにするために実行されている。
【0075】
形態素変数WORDが句読点や空白でなければ(S374におけるNO)、データ加工部184は、許可ワードテーブル200に、前連接形態素pwordが前連接形態素変数PREVの値と等しく、かつ主形態素wordが形態素変数WORDの値と等しくなるレコードが存在するか否か、また、存在した場合、その出現回数wnumが第1閾値α以上であるか否か判定し(S376)、一致する形態素の組み合わせが存在しない場合、または、存在するが出現回数wnumが第1閾値α未満の場合(S376におけるNO)、前連接形態素変数PREVを初期化(空値を代入)し、さらに形態素変数WORDを、伏字を意味する特殊記号「◎」に置換する(S378)。ここで、出現回数wnumが第1閾値α未満の形態素の組み合わせも特殊記号に置換しているのは、出現回数wnumが第1閾値α未満であれば、番組付加データに十分に出現したと言えず、その形態素の組み合わせた許可ワードとして適当ではないからである。
【0076】
図9は、データ加工部184の処理を説明するための説明図である。例えば、投稿データのテキスト本文が図9(a)のようなテキストデータ「総理はBCDだな」であった場合(ここでBCDは連接すると公序良俗違反となる文字列であるとする。)、前連接形態素pword=「NULL」、主形態素word=「総理」となるレコードは、図3の許可ワードテーブル200に存在するので、データ加工部184は、形態素「総理」を出力バッファに蓄積する。また、「BC」と「D」とが連接する形態素は、許可ワードテーブル200に存在していないので、データ加工部184は、その形態素のうち形態素変数WORDにあたる「D」を特殊記号「◎」に置換して、図9(b)のような形態素列を形成する。ここでも理解を容易にするため、形態素間に[/]の記号を挿入しているが、実際に存在する記号として扱うものではない。
【0077】
また、許可ワードテーブル200に一致する形態素の組み合わせが存在し、かつ、その形態素の出現回数wnumが第1閾値α以上の場合(S376におけるYES)、データ加工部184は、前連接形態素変数PREVに形態素変数WORDの値を代入する(S380)。そして、データ加工部184は、出力バッファに、投稿日時変数POSTTIMEの値が投稿日時postと一致するレコードが存在するか否か判定し(S382)、存在する場合(S382におけるYES)、該当レコードの形態素列wlistの最後に形態素変数WORDの値を追加して(S384)、形態素残り判定ステップS370から繰り返す。存在しない場合(S382におけるNO)、データ加工部184は、投稿日時postと形態素列wlistとが、それぞれ前連接形態素変数POSTTIMEと形態素変数WORDとなる新たなレコードを追加して(S386)、形態素残り判定ステップS370から繰り返す。
【0078】
ここでは、理解を容易にするため第1閾値αを1とする。しかし、アプリケーションによって第1閾値αを適宜変更できることは言うまでもない。また、存在判定ステップS376を、出現回数wnumそのものではなく、以下の式1で求められる出現確率を用いて実行してもよい。
該当レコードのwnum値 / 全レコードのwnumの合計値 …(式1)
このように構成することで、データ加工部184は、許可ワードテーブル200の母集団との比率に基づいて存在判定ステップS376を実行することができる。したがって、任意の形態素が、母集団が小さいときに許可ワードとなっていても、その後、出現回数が更新されないと、母集団が大きくなるに連れて出現確率が減り、許可ワードから除外される場合もある。こうして、出現頻度が少なくなった形態素を自動的に排除することが可能となる。
【0079】
以上、説明したように、本実施形態のフィルタリング装置120は、形態素辞書と異なる許可ワードテーブル200を用い、番組ストリームに含まれる番組付加データから取得した形態素の組み合わせおよび出現回数を利用して、公序良俗に反する単語が含まれる投稿データを、そのような単語が含まれていない投稿データに適切に変更することが可能となる。
【0080】
また、上述したように、許可ワードテーブル200は、ユーザが住んでいる地域にある放送局112や、ユーザがもっぱら視聴する放送局112における番組付加データの生成特性を色濃く反映するので、許可ワードテーブル200は、地域性やユーザの好みに応じたものとなり、結果的に、フィルタリングされた投稿データも地域性やユーザの好みに応じた単語が残り易くなる。
【0081】
また、上述した実施形態では、電子掲示板から取得した投稿データをフィルタリングする例を挙げて説明したが、投稿データに限らず、ウェブブラウザに表示される様々なデータや、記憶媒体に収められているデータ等、様々なテキストデータをフィルタリングすることも可能である。
【0082】
(第2の実施形態:番組提供システム400)
第1の実施形態では、任意のテキストデータを適切にフィルタリングするフィルタリング装置120およびフィルタリング方法を説明した。第2の実施形態では、第1の実施形態で説明したフィルタリング技術を用い、番組や番組内の所定シーンを適切に検索する番組検索装置420および番組検索方法を説明する。
【0083】
図10は、第2の実施形態における番組提供システム400の概略的な接続関係を示した説明図である。番組提供システム400は、番組提供装置110と、番組検索装置420と、表示装置130と、サービス提供サーバ140とを含んで構成される。ここで、番組提供装置110、表示装置130、サービス提供サーバ140に関しては、第1の実施形態で説明した番組提供装置110、表示装置130、サービス提供サーバ140と実質的に動作が等しいのでここではその説明を省略する。
【0084】
番組検索装置420は、第1の実施形態で説明したフィルタリング装置120同様、番組提供装置110としての放送局112からアンテナ122を通じて、また、番組提供装置110としての番組提供サーバ114からインターネット等の通信網124を通じて、地上波デジタル放送、BS・CSデジタル放送、ケーブルテレビ放送、IP放送、ビデオオンデマンド等、様々な番組の番組ストリームを受信し、フィルタリングを行うための許可ワードテーブル200を生成する。
【0085】
また、番組検索装置420は、番組を保持すると共に、許可ワードテーブル200を用いて、番組のインデックスデータを生成し、保持された番組に付与する。そして、ユーザが番組や番組内の所定シーンの検索を試みると、番組検索装置420は、インデックスデータに基づいてユーザが所望する番組や番組内の所定シーンを迅速に抽出する。以下、番組検索装置420を構成する各機能部について説明し、その後、番組検索装置420を用いた番組検索方法を詳述する。
【0086】
(番組検索装置420)
番組を複数蓄積し、蓄積された番組を事後的に視聴する構成(例えば、HDR:Hard Disk Recorder)において、番組ストリームに字幕データが含まれている場合、その字幕データをインデックスデータとして番組それぞれに関連付けることで、HDRは、そのインデックスデータに基づいて、ユーザが所望する番組を迅速に提示することができる。しかし、番組ストリームには必ず字幕データが含まれているとは限らず、例えば、ニュースや生放送といった、予めその放送内容を提示できないものに関しては字幕データが含まれていない、または、含まれていたとしても表題等の極限られた情報である。そうすると、番組によっては、インデックスデータが関連付けられているものと、そうでないものが生じる。
【0087】
そこで、本実施形態の番組検索装置420は、字幕データが含まれていない番組ストリームについては、放送以外の経路からインデックスデータに相当する情報を取得して、インデックスデータとして番組に関連付けることを試みる。かかる情報の取得先としては、第1の実施形態で説明した、任意の放送局112で放送されている番組に関する投稿データを電子掲示板として公開しているサービス提供サーバ140等が適している。番組検索装置420は、例えば、番組の視聴時間と、投稿データの投稿日時とを比較して、日時が一致する投稿データが該当する番組に関連していると見なし、その投稿データをインデックスデータとして利用する。
【0088】
しかし、このようなサービス提供サーバ140では、投稿データの文章の制限が緩く、かかる文章がフィルタリングされていたとしても、禁止ワードテーブルを利用しているため、投稿データにゆらぎを加えることで、文章を自由に表現することができる。したがって、投稿データを利用してそのままインデックスデータを生成してしまうと、公序良俗に反する単語や文章を含む、ありとあらゆるテキストデータがインデックスデータとして関連付けられてしまい、インデックスデータの容量が膨大となって検索処理の遅延を招くことになる。このとき、インデックスデータが多くなることで検索のヒット率が高くなるように思えるが、実際には、アスキーアートによる無意味なテキストデータ等、検索用のインデックスデータとして不適当なものが多く、ヒット率が高くなるとは限らない。さらに、ゆらぎに相当する当て字等がインデックスデータとして登録された場合、その番組のインデックスデータとして機能しないばかりか、意図していない他の番組の検索に引っかかってしまい、検索精度が低下する。
【0089】
また、大容量のインデックスデータが関連付けられた番組と、字幕データに基づくインデックスデータが関連付けられた番組で、インデックスデータの量や質が異なることとなるので、検索のためのキーワードによっては、ユーザが所望する番組を適切に抽出できなくなる。このような問題を、以下に示す番組検索装置420および番組検索方法によって解決する。
【0090】
図11は、番組検索装置420の概略的な構成を示した機能ブロック図である。図11では、データの流れを実線の矢印で表し、制御信号の流れを破線の矢印で表している。番組検索装置420は、操作部150と、チューナー部152と、通信部154と、DEMUX部156と、AVデコード部158と、テーブル保持部160と、中央制御部462と、番組保持部464と、番組情報保持部466と、RTC(Real Time Clock)部468と、インデックス保持部470とを含んで構成される。ここで、チューナー部152と、通信部154と、DEMUX部156とは番組ストリームを取得する番組ストリーム取得部として機能する。
【0091】
また、中央制御部462は、テーブル更新部180、データ取得部482、データ加工部184、表示制御部186、番組記憶制御部488、番組情報記憶制御部490、インデックス付与部492、番組抽出部494としても機能する。
【0092】
第1の実施形態における構成要素として既に述べた操作部150と、チューナー部152と、通信部154と、DEMUX部156と、AVデコード部158と、テーブル保持部160と、テーブル更新部180と、データ加工部184と、表示制御部186とは、実質的に機能が同一なので重複説明を省略し、ここでは、構成が相違する中央制御部462、番組保持部464、番組情報保持部466、RTC部468と、インデックス保持部470、データ取得部482、番組記憶制御部488、番組情報記憶制御部490、インデックス付与部492、番組抽出部494を主に説明する。
【0093】
番組記憶制御部488は、番組を、チャンネル番号と時刻データで検索可能な形で番組保持部464に保持させる。
【0094】
番組保持部464は、フラッシュメモリ、HDD等の記憶媒体で構成され、1または複数の番組を保持する。また、番組保持部464として、番組検索装置420から着脱可能な、DVD(Digital Versatile Disc)やBD(Blu-ray Disc)といった光ディスク媒体や、磁気テープ、磁気ディスクといった磁気媒体、フラッシュメモリ、ポータブルHDD等の外部記憶媒体を適用してもよい。
【0095】
また、番組保持部464は、ランダムアクセス可能なファイルシステムであり、他の機能部は、番組保持部464に保持された映像データ、音声データ、字幕データを任意の時刻範囲を指定して読み出すことができる。ここで、ランダムアクセスの方法は既存の技術であるので詳しくは述べないが、例えば、番組を1時間ごとに分割して保存し、その分割したファイルのファイル名を「27CH_2009年9月30日17:00:00.TS」といった、チャンネル番号と記憶開始時刻とを含めた名称にすることで、大まかなランダムアクセスが可能となる。
【0096】
さらに番組中の任意のシーンのランダムアクセスは、任意の再生時刻のファイルオフセット(バイト)を求めることで行うことができる。例えば、1時間あたりのファイルの総サイズ(バイト)をTOTAL、任意のシーンの絶対再生時刻をT1、ファイル名から得られたファイル先頭の絶対時刻をT0とすると、以下の式2によりファイルオフセットが求まる。
TOTAL/3600×(T1−T0) …(式2)
ここで、(T1−T0)の結果は秒換算して用いるものとする。
【0097】
番組情報記憶制御部490は、番組ストリーム取得部としてのチューナー部152や通信部154を介して取得された番組ストリームに番組情報が含まれている場合、番組ストリームから番組情報を抽出し、番組情報テーブルとして番組情報保持部466に保持させる。
【0098】
かかる番組情報テーブルを生成するための命令文を、SQLを用いて表すと、以下のように記述できる。
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)
);
ここで番組情報は、少なくとも、チャンネル番号phych、サービスID:serviceid、イベントID:eventid、番組開始時刻sttime、番組終了時刻edtime、番組名title、字幕フラグcapflgを含んでいる。また、番組情報テーブルでは、サービスID:serviceidと、イベントID:eventidと、番組開始時刻sttimeとの組み合わせがユニークになる。番組情報記憶制御部490は、字幕フラグcapflg以外の情報は番組情報から取得できる。また、サービスIDは1つの放送局112中の1つ以上の編成に対応した固有な数値であり、イベントIDは1編成中の1つ以上のイベントに対応した固有な数値である。
【0099】
番組情報を番組情報テーブルに登録する際、番組情報保持部466に、サービスID:serviceidと、番組情報の番組開始時刻sttimeおよび番組終了時刻edtimeとが等しい番組情報が既に登録されていれば、番組情報記憶制御部490は、その番組情報を削除して新たに抽出した番組情報を登録する。こうすることで、同一編成における番組枠の重複を除外することができる。また、番組情報記憶制御部490は、番組情報を新たに登録する際、その番組情報の字幕フラグcapflgを0(未処理)に設定する。
【0100】
番組情報保持部466は、フラッシュメモリ、HDD等の記憶媒体で構成され、番組情報記憶制御部490の制御指令に基づいて、番組ストリームに含まれる番組情報をテーブル化した番組情報テーブルを保持する。また、番組情報保持部466は、EPGデータベースとして機能し、他の機能部(例えば、インデックス付与部492や番組抽出部494)は、番組情報保持部466が保持する番組情報テーブルを任意の条件で検索することができる。
【0101】
データ取得部482は、番組に関するテキストデータ(第2のテキストデータ)を取得する。本実施形態では、データ取得部482は、任意の放送局112で放送されている番組に関する投稿データを電子掲示板として公開しているサービス提供サーバ140から、その番組に関する投稿データ(第2のテキストデータ)を取得すると共に、投稿日時(取得日時情報)を投稿データに関連付ける。上述したように、このような電子掲示板では、特定の放送局112で放送されている一連の番組について、通信網124を介し、不特定多数の投稿者が、恰も実況中継を行っているが如く、ほぼリアルタイムに投稿データを投稿し合っている。本実施形態において、データ取得部482は、このような任意の放送局112専用に設けられた電子掲示板から投稿データを取得する。データ取得部482は、投稿専用サイトにおいて、任意の放送局112に関するスレッドのタイトルを指定し、その投稿データを取得してもよい。また、放送局112が独自に自局に対する意見等を募集するサイトを運営している場合、データ取得部482は、そのようなサイトを通じて投稿データを取得してもよい。
【0102】
具体的に、データ取得部482は、ウェブブラウザに相当し、通信部154を通じて、サービス提供サーバ140との通信を確立し、時刻範囲とチャンネル番号を含むリクエスト情報を送信し、時刻範囲に含まれる投稿データ群(テキストデータ群)をレスポンスとして取得する。データ取得部482が投稿データ群を取得すると、データ加工部184は、投稿データ(第2のテキストデータ)を形態素に分割し、分割した形態素が許可ワードテーブル200に登録されていない、または、形態素が許可ワードテーブル200に登録されているが、その形態素に対応した出現回数が予め定められた第1閾値α未満であれば、形態素を、予め定められた1または複数の文字に置換し、投稿データ(第3のテキストデータ)として再結合する。
【0103】
RTC部468は、RTC回路で構成され、番組検索装置420自体の時計としての役割を担う。
【0104】
インデックス付与部492は、番組保持部464に保持された番組に、番組付加データまたは投稿データから抽出した形態素と、番組付加データまたは投稿データ(第2のテキストデータ)に関連付けられた取得日時情報との組を、インデックスデータとして付与し(関連付け)、インデックステーブルとしてインデックス保持部470に保持させる。かかるインデックステーブルを生成するための命令文を、SQLを用いて表すと、以下のように記述できる。
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)
);
ここで、インデックステーブルは、少なくとも、検索語word、検索時刻postime、該当番組のサービスID:serviceid、該当番組のイベントID:eventidを含む。また、インデックステーブルは、検索語wordと、検索時刻postimeと、該当番組のサービスID:serviceidと、該当番組のイベントID:eventidとの組み合わせがユニークになる。
【0105】
また、本実施形態において、インデックス付与部492は、番組ストリームに字幕データが含まれていれば(番組に字幕データが付加されていれば)、その字幕データと取得日時情報との組をインデックスデータとしてその字幕データに対応する番組に付与し、番組ストリームに字幕データが含まれていなければ(番組に字幕データが付加されていなければ)、または、含まれていない(番組に字幕データが付加されていない)とみなせれば、再結合したテキストデータ(第3のテキストデータ)と、その取得日時情報との組をインデックスデータとしてその字幕データに対応する番組に付与する。ここで、含まれていない(番組に字幕データが付加されていない)とみなすとは、後述する字幕率が低いことを言う。
【0106】
具体的に、インデックス付与部492は、番組情報保持部466から、未処理(字幕フラグcapflg=0)の番組情報を取り出し、番組保持部464から、その番組情報に対応した番組の字幕データを取り出してインデックスデータとする。このとき、番組ストリームに、字幕データが存在しないか存在しないとみなせる場合(番組に字幕データが付加されていないか付加されていないとみなせる場合)、インデックス付与部492は、データ取得部482に、サービス提供サーバ140から投稿データ(テキストデータ)を取得させ、データ加工部184に、該当する番組を検索可能なインデックスデータを生成させる。そして、インデックス付与部492は、インデックスデータを、番組に付与するために、インデックスデータをインデックス保持部470のインデックステーブルへ登録する。
【0107】
かかるインデックス付与部492を備えることで、番組ストリームに含まれる字幕データと、サービス提供サーバ140の投稿データとのいずれを付与対象の番組のインデックスデータとすべきか適切に選択して、検索のための適当なインデックスデータを生成することが可能となる。こうして、字幕データがない場合であってもインデックスが付されるので、検索精度を向上することが可能となる。
【0108】
また、本実施形態では、テーブル更新部180が許可ワードテーブル200を更新するために用いる番組付加データのうちの字幕データと、インデックス付与部492がインデックスデータとして用いる字幕データとを区別しているが、インデックスデータとして用いる字幕データを利用して、許可ワードテーブル200を更新することも可能である。
【0109】
インデックス保持部470は、フラッシュメモリ、HDD等の記憶媒体で構成され、インデックス付与部492の制御指令に基づいて、インデックスデータをテーブル化したインデックステーブルを保持する。
【0110】
番組抽出部494は、操作部150を通じたユーザの操作入力を受け付け、その操作結果を表示装置130にGUI(Graphical User Interface)を通じて表示すると共に、ユーザが検索のため入力したキーワード等に基づいて、インデックステーブルを参照し、番組保持部464に保持された番組または番組内の所定シーンを抽出する。
【0111】
(番組検索方法)
図12は、番組検索方法の処理の流れを説明したフローチャートである。特に、図12では、番組検索方法のうち、インデックスデータの付与処理について説明している。まず、インデックス付与部492は、RTC部468から現在時刻を取得し、時刻変数NOWへ代入し(S500)、番組情報保持部466から、字幕フラグcapflgが0(未処理)であり、かつ番組終了時刻edtimeが時刻変数NOWより過去にあたる番組情報を検索し、番組情報列として取得する(S502)。
【0112】
インデックス付与部492は、番組情報列に番組情報が残っているか否か判定し(S504)、残っていれば(S504におけるYES)、番組情報列の先頭から番組情報を1つ取り出し、サービスID変数SERVICEIDにサービスID:serviceidを、イベントID変数EVENTIDにイベントID:eventidをそれぞれ代入して、その番組情報列から対象の番組情報を削除する(S506)。番組情報列に番組情報が残っていなかった場合(S504におけるNO)、当該インデックスデータの付与処理を終了する。
【0113】
続いて、インデックス付与部492は、番組保持部464から、チャンネル番号phychに関するファイルであり、かつ番組開始時刻sttimeから番組終了時刻edtimeまでの時刻範囲に含まれる番組付加データから字幕データ列を取得し(S508)、取得した字幕データ列に含まれる字幕データの総数を、変数CAPNUMに代入する(S510)。図13は、字幕データの一例を示した説明図である。図13に示すように、例えば字幕データ550には少なくとも字幕時刻552とテキスト本文554とが含まれている。本実施形態では、説明の簡単化のため、番組付加データのうち字幕データのみを扱うが、字幕以外の番組付加データから、時刻とテキストのセットを抽出してもよい。例えば、番組情報のうち(番組開始時刻sttime, 題名title)を1セットとして、字幕データ列の先頭に付加してもよい。
【0114】
そして、インデックス付与部492は、字幕データ列に1つ以上字幕データが残っているか否か判定し(S512)、残っていれば(S512におけるYES)、字幕データ列の先頭から字幕データを1つ取り出し、字幕時刻552を時刻変数POSTIMEへ代入し、テキスト本文554をテキスト変数TEXT2に代入し、その字幕データ列から対象の字幕データを削除する(S514)。インデックス付与部492は、さらにテキスト変数TEXT2に対して、1つ以上の改行や記号や空白を1つの空白に置換する字句解析を行い(S516)、形態素辞書を用いて、形態素に分割する(S518)。このとき、インデックス付与部492として機能する形態素エンジンでは、空白を形態素間の区切りとする。以上は字幕データ列を形態素列に分割する処理であり、CAPNUM個分繰り返される。また、字幕データ列に字幕データが残っていない場合(S512におけるNO)、形態素残り判定ステップS520に移行する。
【0115】
続いて、インデックス付与部492は、字幕データの形態素列に形態素が1つ以上残っているか否か判定し(S520)、残っていれば(S520におけるYES)、先頭の形態素を1つ取り出して形態素変数WORDへ代入し、その形態素列から対象の形態素を削除し(S522)、インデックス保持部470のインデックステーブルに(word,postime,serviceid,eventid)=(WORD,POSTIME,SERVICEID,EVENTID)となるレコードを追加する(S524)。なお、インデックステーブルは、上述したように、検索語wordと、検索時刻postimeと、該当番組のサービスID:serviceidと、該当番組のイベントID:eventidとの組み合わせがユニークになるので、同一番組の同一時刻の字幕データに同一の単語が複数現れた場合は、2つ目以降のレコードを無視することとする。
【0116】
また、形態素列に形態素が残っていなければ(S520におけるNO)、インデックス付与部492は、以下の式3を用いて字幕率CSTを算出する(S526)。このとき、(番組終了時刻edtime−番組開始時刻sttime)の結果は秒換算して用いるものとし、字幕率CSTは1秒あたりの字幕データ数を表す。
CST = CAPNUM / (edtime−sttime) …(式3)
統計上、字幕がついているとみなせる番組の字幕率CSTは0.1〜0.25の間の値をとるので、第2閾値β=0.1として判定し、インデックス付与部492は、字幕率CSTが第2閾値β以上であるか否か判定する(S528)。字幕率CSTが第2閾値β以上であれば(S528におけるYES)、字幕データ列が有効であると見なして、番組情報保持部466の番組情報テーブルにおける該当レコードの字幕フラグcapflgを1(字幕データあり)に設定し(S530)、番組情報残り判定ステップS504から繰り返す。ここでは、番組付加データのうち、字幕データに関する出現率(字幕率)を第2閾値βと比較しているが、同様に、番組情報のテキスト本文のデータ総数を第3閾値と比較して字幕データ列の有効性を判断してもよい。
【0117】
また、同様に、S518で出力された形態素列の形態素数を第4閾値と比較して字幕データ列の有効性を判断してもよい。
【0118】
一方、字幕率CSTが第2閾値β未満であった場合(S528におけるNO)、字幕データ列がインデックスデータとして十分ではないと判定し、データ取得部482およびデータ加工部184に対して、番組開始時刻sttimeから番組終了時刻edtimeの時刻範囲に含まれる投稿データを取得および加工させる(S532)。かかる加工された投稿データは、中央制御部462のRAMに設けられた出力バッファに蓄積される。投稿データ取得ステップS532は、第1の実施形態において図7を用いて説明した処理と実質的に等しいので、ここではその説明を省略する。ここで、字幕データ列がインデックスデータとして十分ではないとは、ニュースや生放送といったような予めその放送内容を提示できないものに関しては、字幕データが含まれていない、または、含まれていたとしても表題等の極限られた情報のみしかないので信頼性が低いことを示し、そのような場合には、少ない字幕データを利用するより、投稿データを採用することとし、信頼性の向上を図る。
【0119】
続いて、インデックス付与部492は、出力バッファにレコードが残っているか否か判定し(S534)、残っていない場合(S534におけるNO)、番組情報保持部466の番組情報テーブルにおける該当レコードの字幕フラグcapflgを2(コメント有り)に設定し(S536)、番組情報残り判定ステップS504から繰り返す。
【0120】
また、出力バッファにレコードが残っている場合(S534におけるYES)、インデックス付与部492は、レコードを取り出して、投稿日時postを時刻変数POSTIMEへ代入し、形態素列wlistを取得する(S538)。
【0121】
続いて、インデックス付与部492は、レコードの形態素列に形態素が1つ以上残っているか否か判定し(S540)、残っていない場合(S540におけるNO)、レコード残り判定ステップS534から繰り返す。
【0122】
レコードの形態素列に形態素が残っている場合(S540におけるYES)、先頭の形態素を1つ取り出して形態素変数WORDへ代入し、その形態素列から対象の形態素を削除し(S542)、インデックス保持部470のインデックステーブルに(word,postime,serviceid,eventid)=(WORD,POSTIME,SERVICEID,EVENTID)となるレコードを追加する(S544)。
【0123】
インデックス付与部492により生成されたインデックスデータは、字幕等が多い番組は字幕データを検索の情報源として使うため、正確度が高く、字幕等が少ない番組は投稿データを検索情報源として使うため、広く浅く検索が可能なものとなる。
【0124】
図14は、番組検索方法の処理の流れを説明したフローチャートである。特に、図14では、番組検索方法のうち、番組の検索処理について説明している。まず、番組抽出部494は、ユーザから検索のためのキーワードの入力を受け付けると(S570におけるYES)、キーワードを形態素変数WORDに代入する(S572)。そして、番組抽出部494は、インデックス保持部470のインデックステーブルを検索し(S574)、さらに検索結果の各行に含まれるサービスID:serviceid、イベントID:eventidを用い、番組情報保持部466の番組情報テーブルを検索して番組名等を取得し(S576)、検索結果である検索リストをユーザに表示する(S578)。
【0125】
図15は、検索リストの表示例を示した説明図である。ユーザが検索のためのキーワードを入力領域600に入力して、検索開始ボタン602をクリックすると、番組抽出部494は、そのキーワードに基づいてインデックスデータを検索し、検索されたインデックスデータに基づいて、図15のように、番組情報をリスト化して表示する。ここで、番組抽出部494は、番組情報保持部466の番組情報テーブルにおける各レコードをユーザが分かり易いように置換加工し、適切にレイアウトに収めて表示する。例えば、図15の例では、字幕フラグ(字幕:capflg=1、コメント:capflg=2)604、番組開始時刻606、番組終了時刻608、サービスID610、イベントID612が表示される。
【0126】
続いて、ユーザが検索リストのうち1つの番組を選択する選択入力を受け付けると(S580におけるYES)、番組抽出部494は、番組情報保持部466から取得したチャンネル番号phychと、インデックス保持部470から得られた検索時刻postimeを用いて番組保持部464を検索し(S582)、AVデコード部158は、検索処理によって抽出された番組を表示装置130に表示させる(S584)。
【0127】
図16は、表示装置130での表示例を示した説明図である。ここでは、GUIによる再生、停止、シーク等の動作モードを持つ典型的な表示装置130を起動する際、検索のためのキーワードに関連付けられた検索時刻620が再生開始点として選択されていることが分かる。
【0128】
このような、番組の検索処理によって、ユーザは、数千時間分の番組から、検索のためのキーワードに関連付けられた任意の番組または任意のシーンを閲覧することが可能となる。
【0129】
以上、説明した番組検索装置420および番組検索方法では、字幕データが含まれていない番組ストリームについて、他の経路、例えば、電子掲示板の投稿データから、インデックスデータに相当する情報を取得し、インデックスデータとして番組に関連付けることができるため、字幕データの有無に拘わらず、全ての番組にインデックスデータを付すことができ、番組の検索精度の向上を図ることが可能となる。
【0130】
また、投稿データをインデックスデータとして用いる際に、放送倫理規定に従うテキストデータに加工した投稿データのみをインデックスデータとすることで、公序良俗に反する単語や文章、対応する番組に無関係な当て字、アスキーアートによる無意味なテキストデータ等、不要なテキストデータを排除し、インデックスデータとして適当なテキストデータのみを番組に関連付けることが可能となる。こうして、インデックスデータのデータ容量が膨大になることや、不適当なインデックスデータによる検索精度の劣化を回避することができる。
【0131】
さらに、投稿データをフィルタリングして番組に関連付けるインデックスデータを制限することで、番組ストリームに予め含まれた字幕データと量的にバランスがとれることとなり、検索のヒット率が偏ることもない。また、フィルタリングが放送倫理規定に従って行われるので、加工された投稿データは、放送倫理規定に従ったテキストデータとなり、番組ストリームに予め含まれた字幕データと、放送倫理規定に従っている点でその単語や文章の質が等しくなる。このように、投稿データによるインデックスデータが関連付けられた番組と、字幕データによるインデックスデータが関連付けられた番組とが、インデックスデータの量や質においてバランスがとれるので、検索の均一性が保たれることとなり、ユーザは所望する番組およびその番組内の所定シーンを適切に抽出することが可能となる。
【0132】
また、第1の実施形態で説明したように、許可ワードテーブル200をフィルタリング装置120内で閉じられた状態で更新するため、チューナー部152や通信部154を通じて効率的に許可ワードテーブル200を生成することが可能となると共に、改竄の危険性を最小限に抑えつつ、フィルタリングを回避するためのゆらぎに関しても対応することが可能となる。
【0133】
また、許可ワードテーブル200は、ユーザが住んでいる地域にある放送局112や、ユーザがもっぱら視聴する放送局112の番組付加データの生成特性を色濃く反映するので、地域性やユーザの好みに応じた許可ワードテーブル200となり、結果的に、フィルタリングされた投稿データも地域性やユーザの好みに応じた単語が残り易くなる。
【0134】
以上、添付図面を参照しながら本発明の好適な実施形態について説明したが、本発明はかかる実施形態に限定されないことは言うまでもない。当業者であれば、特許請求の範囲に記載された範疇において、各種の変更例または修正例に想到し得ることは明らかであり、それらについても当然に本発明の技術的範囲に属するものと了解される。
【0135】
例えば、上述した実施形態においては、放送倫理規定に基づいて信頼性の高い番組付加データを用いる例を挙げているが、このような番組付加データに限られず、目的とする分野において、信頼性の高い単語または文章を自動的に取得できれば、本実施形態を様々な分野に適応することができる。
【0136】
なお、本明細書のフィルタリング方法や番組検索方法の各工程は、必ずしもフローチャートとして記載された順序に沿って時系列に処理する必要はなく、並列的あるいはサブルーチンによる処理を含んでもよい。
【符号の説明】
【0137】
100、400 …番組提供システム
120 …フィルタリング装置
160 …テーブル保持部
180 …テーブル更新部
182、482 …データ取得部
184 …データ加工部
200 …許可ワードテーブル
420 …番組検索装置
464 …番組保持部
492 …インデックス付与部
494 …番組抽出部

【特許請求の範囲】
【請求項1】
複数の形態素とその出現回数とを対応付けた許可ワードテーブルを保持するテーブル保持部と、
放送倫理規定に沿って生成された番組ストリームを取得する番組ストリーム取得部と、
取得された前記番組ストリームに字幕データまたは番組の内容に関する第1のテキストデータである番組情報が含まれている場合、前記番組ストリームから前記字幕データまたは前記番組情報を抽出し、形態素に分割して、分割した前記形態素が前記許可ワードテーブルに無ければ、その形態素を前記許可ワードテーブルに登録し、分割した前記形態素が前記許可ワードテーブルに有れば、前記形態素に対応した出現回数を更新するテーブル更新部と、
任意の第2のテキストデータを取得するデータ取得部と、
前記第2のテキストデータを形態素に分割し、分割した前記形態素が前記許可ワードテーブルに登録されていない、または、分割した前記形態素が前記許可ワードテーブルに登録されているが、その形態素に対応した出現回数が予め定められた第1閾値未満であれば、前記形態素を、予め定められた記号に置換し、第3のテキストデータとして再結合するデータ加工部と、
を備えることを特徴とするフィルタリング装置。
【請求項2】
複数の形態素とその出現回数とを対応付けた許可ワードテーブルを保持するテーブル保持部と、
放送倫理規定に沿って生成された、番組の内容に関する第1のテキストデータである番組情報を取得する番組情報取得部と、
前記番組情報を形態素に分割し、分割した前記形態素が前記許可ワードテーブルに無ければ、その形態素を前記許可ワードテーブルに登録し、分割した前記形態素が前記許可ワードテーブルに有れば、前記形態素に対応した出現回数を更新するテーブル更新部と、
任意の第2のテキストデータを取得するデータ取得部と、
前記第2のテキストデータを形態素に分割し、分割した前記形態素が前記許可ワードテーブルに登録されていない、または、分割した前記形態素が前記許可ワードテーブルに登録されているが、その形態素に対応した出現回数が予め定められた第1閾値未満であれば、前記形態素を、予め定められた記号に置換し、第3のテキストデータとして再結合するデータ加工部と、
を備えることを特徴とするフィルタリング装置。
【請求項3】
前記第2のテキストデータは、前記番組に対して電子掲示板に投稿された投稿データであり、
前記データ加工部によって前記第3のテキストデータとして再結合された前記投稿データを、取得された前記番組ストリームの番組と共に表示装置に表示させる表示制御部をさらに備えることを特徴とする請求項1または2に記載のフィルタリング装置。
【請求項4】
放送倫理規定に沿って生成された番組ストリームを取得し、
取得した前記番組ストリームに字幕データまたは番組の内容に関する第1のテキストデータである番組情報が含まれている場合、前記番組ストリームから前記字幕データまたは前記番組情報を抽出し、形態素に分割して、分割した前記形態素が、複数の形態素とその出現回数とを対応付けた許可ワードテーブルに無ければ、その形態素を前記許可ワードテーブルに登録し、分割した前記形態素が前記許可ワードテーブルに有れば、前記形態素に対応した出現回数を更新し、
任意の第2のテキストデータを取得し、
前記第2のテキストデータを形態素に分割し、分割した前記形態素が前記許可ワードテーブルに登録されていない、または、分割した前記形態素が前記許可ワードテーブルに登録されているが、その形態素に対応した出現回数が予め定められた第1閾値未満であれば、前記形態素を、予め定められた記号に置換し、第3のテキストデータとして再結合することを特徴とするフィルタリング方法。
【請求項5】
放送倫理規定に沿って生成された、番組の内容に関する第1のテキストデータである番組情報を取得し、
前記番組情報を形態素に分割し、分割した前記形態素が、複数の形態素とその出現回数とを対応付けた許可ワードテーブルに無ければ、その形態素を前記許可ワードテーブルに登録し、分割した前記形態素が前記許可ワードテーブルに有れば、前記形態素に対応した出現回数を更新し、
任意の第2のテキストデータを取得し、
前記第2のテキストデータを形態素に分割し、分割した前記形態素が前記許可ワードテーブルに登録されていない、または、分割した前記形態素が前記許可ワードテーブルに登録されているが、その形態素に対応した出現回数が予め定められた第1閾値未満であれば、前記形態素を、予め定められた記号に置換し、第3のテキストデータとして再結合することを特徴とするフィルタリング方法。

【図1】
image rotate

【図2】
image rotate

【図3】
image rotate

【図4】
image rotate

【図5】
image rotate

【図6】
image rotate

【図7】
image rotate

【図8】
image rotate

【図9】
image rotate

【図10】
image rotate

【図11】
image rotate

【図12】
image rotate

【図13】
image rotate

【図14】
image rotate

【図15】
image rotate

【図16】
image rotate