コンテンツ詳細情報管理装置、コンテンツ詳細情報管理方法及びプログラム
【課題】コンテンツ詳細情報についても、できるだけ取得して記憶しておくように、コンテンツ詳細情報を効率良く管理する。
【解決手段】地デジの例である。日時の２次元平面に多数の３時間毎の１固まりの情報５７が設けられ、ＥＩＴのバージョン番号５７ａと、番組詳細情報を取得済みであるか否かの情報５７ｂ・５７ｃとを有している。従って、ある日のある時間帯の１固まりの情報が取得済みであるか否かを知ることが出来る。例えば地デジの受信中に、番組詳細情報を含む情報をサーバから取得しＥＩＴバージョンマトリックスを埋めていくことで、どの日のどの時間帯の１固まりの情報を取得済みであるかを知ることが出来る。このＥＩＴバージョンマトリクスは、テレビとサーバとの最小単位の共有情報ともいうべきものである。このＥＩＴバージョンマトリクスには、番組詳細情報が含まれず、あくまで、その情報がサーバにあるか否かの情報のみが存在する。
【解決手段】地デジの例である。日時の２次元平面に多数の３時間毎の１固まりの情報５７が設けられ、ＥＩＴのバージョン番号５７ａと、番組詳細情報を取得済みであるか否かの情報５７ｂ・５７ｃとを有している。従って、ある日のある時間帯の１固まりの情報が取得済みであるか否かを知ることが出来る。例えば地デジの受信中に、番組詳細情報を含む情報をサーバから取得しＥＩＴバージョンマトリックスを埋めていくことで、どの日のどの時間帯の１固まりの情報を取得済みであるかを知ることが出来る。このＥＩＴバージョンマトリクスは、テレビとサーバとの最小単位の共有情報ともいうべきものである。このＥＩＴバージョンマトリクスには、番組詳細情報が含まれず、あくまで、その情報がサーバにあるか否かの情報のみが存在する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンテンツ詳細情報の管理技術に関し、特に、デジタル放送受信装置における番組詳細情報の管理技術に関する。
【背景技術】
【０００２】
デジタル放送受信装置において利用されるコンテンツ（番組）に関連する情報には、番組に関する簡単な説明を含む番組情報と、番組の詳細な説明を含む番組詳細情報と、が含まれる。
【０００３】
デジタル放送などでは、多くの番組が提供されるため、コンテンツの管理が重要になってくる。例えば、下記特許文献１に記載の技術では、テレビ放送局から放送衛星を介して多重化ストリームで送信されたデジタル放送を、送受信機で受信してテレビで表示する。このデジタル放送は情報付与センタでも受信されるようにしておく。そして、情報付与センタでは、データ放送用文書を構文解析して、名詞（キーワードなど）を抽出する。この名詞に基づく詳細情報をインターネット等で検索し、この詳細情報を番組情報データベースに格納するとともに、この名詞をカテゴリやキーワードとしてテレビに表示させるものである。
【０００４】
このようにして表示されたカテゴリやキーワードを視聴者が選択することにより、番組情報データベースからテレビの画面上に、その選択されたカテゴリやキーワードに応じた詳細情報を提供することができる。
【０００５】
また、非特許文献１には、番組詳細情報を含む規格が規定されている。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２００２−２４２５０号公報
【非特許文献】
【０００７】
【非特許文献１】http://www.arib.or.jp/tyosakenkyu/kikaku_hoso/hoso_gijutsu_number.html技術資料 ARIB TR-B14 3.9版
【発明の概要】
【発明が解決しようとする課題】
【０００８】
しかしながら、上記特許文献１に記載の技術は、送受信機で受信してテレビで表示する情報を、情報付与センタでも受信し、この情報付与センタにおいて、ＥＰＧや番組関連情報など、放送局が作成して画面上で提供する情報に追加して、番組検索などを行うものであり、その、現在放送している番組の内容に直接関連するものがほとんどである。上記の視聴中でない番組を含むＥＰＧや番組関連情報、特に番組詳細情報を取得し視聴者に提供するためには、受信機で受信できる情報の再送周期が長いため十分な応答性を確保できず、視聴者の要求を十分に満足させることができない。
【０００９】
また、上記非特許文献１に記載の規格によれば、番組詳細情報は必ずしも全てのイベント（番組）に対して記載されている訳ではなく、また、視聴中でない番組を含むＥＩＴ（Ｅｖｅｎｔ Ｉｎｆｏｒｍａｔｉｏｎ Ｔａｂｌｅ）の再送周期が長いため、十分な応答性を確保できるものではないとの記述があるので、受信機では不揮発性メモリ（フラッシュメモリ）には保存せず、番組情報のみをフラッシュメモリに保存し番組詳細情報は取得できた分だけを揮発性メモリ（ＲＡＭ）にのみ記憶させるように設計されている場合が多い。
【００１０】
加えて、ユーザがＢＳ・ＣＳを視聴するのか、地デジを視聴するのか、ＩＰＴＶを視聴するのか、それとも全てのネットワークに対し同じ様に視聴するのか、などを前もって判別することはできないため、ＢＳ・ＣＳ、地デジ、ＩＰＴＶにおけるそれぞれの番組情報を差別化せずに同じ様にフラッシュメモリに保存しているのが現状である。
【００１１】
本発明は、多様なコンテンツネットワークを有するコンテンツ受信装置において、コンテンツの詳細情報を効率良く管理する技術を提供することを目的とする。
【課題を解決するための手段】
【００１２】
本発明は、地デジ・ＢＳ・ＣＳ・ＩＰＴＶなどの多様なコンテンツネットワークから得られた番組詳細情報をテレビジョン受信装置などの装置本体の内部の不揮発性メモリ（フラッシュメモリ）には保存せずに、イーサネットワーク上の外部サーバ等のサーバに適時保存しておくこと、サーバにおけるコンテンツ詳細情報の取得状況を高速ＲＡＭに記憶しておくことを特徴とする。更新時にも、同様にＲＡＭに、コンテンツ詳細情報の保存状況を記憶するとともに、コンテンツ詳細情報自体はサーバに記憶する。
【００１３】
そして、“キーワード検索”などの操作で番組詳細情報に基づく検索が必要になった時点で、サーバに保存されている番組詳細情報を対象に検索を行い、検索にヒットした情報だけをサーバから再取得することにより、莫大な記憶領域を占有する番組詳細情報を対象に“キーワード検索”等の処理が可能となる。
【００１４】
本発明の一観点によれば、コンテンツネットワークにおけるコンテンツのコンテンツ詳細情報を管理するコンテンツ詳細情報管理装置であって、前記コンテンツ詳細情報と、取得した前記コンテンツ詳細情報のバージョン情報及びコンテンツ詳細情報の取得状況を含むＥＩＴバージョン情報と、を取得するコンテンツ情報取得部と、前記コンテンツ情報取得部が取得した前記コンテンツ詳細情報と前記ＥＩＴバージョン情報とを記憶する第１の記憶部と、前記第１の記憶部に記憶させて生成した前記ＥＩＴバージョン情報と前記コンテンツ詳細情報とを、インターフェイス部を介して装置と接続されたサーバの第２の記憶部にも前記第１の記憶部の前記ＥＩＴバージョン情報と対応させて記憶させる処理を行うコンテンツ詳細情報管理部と、を有することを特徴とするコンテンツ詳細情報管理装置が提供される。
【００１５】
また、本発明は、コンテンツネットワークにおけるコンテンツのコンテンツ詳細情報を管理するコンテンツ詳細情報管理装置であって、前記コンテンツ詳細情報と、取得した前記コンテンツ詳細情報のバージョン情報及びコンテンツ詳細情報の取得状況を含むＥＩＴバージョン情報と、を取得するコンテンツ情報取得部と、前記コンテンツ情報取得部が取得した前記コンテンツ詳細情報と前記ＥＩＴバージョン情報とを記憶する第１の記憶部と、前記コンテンツ情報取得部が取得した前記コンテンツ詳細情報を順次記憶する第２の記憶部を有するサーバと接続するためのインターフェイス部と、前記第１の記憶部に記憶させて生成した前記ＥＩＴバージョン情報と前記コンテンツ詳細情報とを、前記インターフェイス部を介して装置と接続されたサーバの第２の記憶部にも前記第１の記憶部の前記ＥＩＴバージョン情報と対応させて記憶させる処理を行うコンテンツ詳細情報管理部と、を有することを特徴とするコンテンツ詳細情報管理装置である。
【００１６】
前記コンテンツ詳細情報管理部は、前記ＥＩＴバージョン情報の前記一単位を複数集めて生成したＥＩＴバージョンマトリックスを生成し、前記第１の記憶部に記憶させることが好ましい。ＥＩＴバージョンマトリックスのＥＩＴバージョン情報とコンテンツ詳細情報の取得状況とから、サーバの第２の記憶部に記憶されているコンテンツ詳細情報にアクセスして、所望のコンテンツ詳細情報のみを取得することができる。ＥＩＴバージョンマトリックスは、例えば、ネットワークＩＤとサービスＩＤとの組毎に、ＥＩＴのバージョン情報とコンテンツ詳細情報が取得済みか否かの情報とを、放送時間軸と日時軸との２軸で画定された２次元平面上にマトリックス状に記載したものである。前記ＥＩＴバージョンマトリックスにおける前記一単位は、放送時間帯と放送日とにより画定されることが好ましい。
【００１７】
前記コンンツ詳細情報管理部は、複数のコンテンツネットワークについて、それぞれ、チャンネル軸に沿って前記ＥＩＴバージョン情報を有する全ＥＩＴマトリックスを作成することが好ましい。全ＥＩＴマトリクスを取得する際に、取得済みである旨の情報、未取得である旨の情報を保存する領域に対し、サーバ側で未取得ＥＩＴの取得優先順位を付けることが好ましい。また、前記ＥＩＴマトリクスにおける情報取得の速度を考慮して、未取得ＥＩＴの取得優先順位を付けることが好ましい。前記ＥＩＴバージョン情報の前記バージョン情報に基づいて、前記コンテンツ詳細情報の更新の有無を判定すると良い。前記コンテンツ詳細情報は、拡張形式イベント記述子により記載されていることを特徴とする。
【００１８】
本発明は、上記のいずれか１に記載のコンテンツ詳細情報管理装置と、前記サーバに記憶されている前記コンテンツ詳細情報に基づいて、コンテンツの検索を行うコンテンツ検索部と、を有することを特徴とするコンテンツ検索装置であっても良い。
【００１９】
また、上記のいずれか１に記載のコンテンツ詳細情報管理装置と、前記サーバに記憶されている前記コンテンツ詳細情報とに基づいて、コンテンツの情報の表示制御を行うコンテンツ情報表示制御部を有することを特徴とするコンテンツ表示装置であっても良い。
【００２０】
また、上記のいずれか１に記載のコンテンツ詳細情報管理装置を備えたことを特徴とするコンテンツ視聴装置であっても良い。
【００２１】
本発明の他の観点によれば、コンテンツネットワークにおけるコンテンツのコンテンツ詳細情報を管理するコンテンツ詳細情報管理方法であって、前記コンテンツ詳細情報と、取得した前記コンテンツ詳細情報のバージョン情報及びコンテンツ詳細情報の取得状況を含むＥＩＴバージョン情報と、を取得するコンテンツ情報取得ステップと、前記コンテンツ情報取得ステップが取得した前記コンテンツ詳細情報と前記ＥＩＴバージョン情報とを第１の記憶部に記憶するステップと、前記コンテンツ情報取得ステップが取得した前記コンテンツ詳細情報と前記ＥＩＴバージョン情報とを第１の記憶部に記憶するステップと、前記第１の記憶部に記憶させて生成した前記ＥＩＴバージョン情報と前記コンテンツ詳細情報とを、インターフェイス部を介して装置と接続されたサーバの第２の記憶部にも前記第１の記憶部の前記ＥＩＴバージョン情報と対応させて記憶させる処理を行うコンテンツ詳細情報管理ステップと、を有することを特徴とするコンテンツ詳細情報管理方法が提供される。
【００２２】
本発明は、上記に記載のコンテンツ詳細情報管理方法をコンピュータに実行させるためのプログラムであっても良く、当該プログラムを記録するコンピュータ読み取り可能な記録媒体であっても良い。プログラムは、インターネットなどの伝送媒体によって取得されるものでも良い。
【発明の効果】
【００２３】
本発明によれば、コンテンツの詳細情報を外部サーバに記憶させ、装置本体では、その取得状況のみを記憶しておき、必要なタイミングで必要な分だけ外部サーバから装置内に取得することにより、コンテンツの詳細情報を効率良く管理することが可能となる。例えば、この詳細情報を利用して、番組検索などに利用することができる。また、不揮発性メモリの記憶領域を無駄にせずに、効率的に利用することができるという利点がある。
【図面の簡単な説明】
【００２４】
【図１】番組情報と番組詳細情報の構成例を示す図である。
【図２】拡張形式イベント記述子の項目名を示す図である。
【図３】一般的なデジタルテレビジョン受信装置における、短形式イベント記述子のフラッシュメモリへの保存の様子を示す概念図である。
【図４】本発明の実施の形態によるデジタルテレビジョン受信装置における、拡張形式イベント記述子のメモリへの保存の様子を示す概念図である。
【図５】ＥＩＴバージョンマトリックスの構成要素であって一度に取得できる最小単位のＥＩＴの構成例を示す図である。
【図６】図５と同様の１固まりの情報であるが、深夜の番組などで、時間的に継続していない途中で放送が無い場合の例を示す図である。
【図７】本実施の形態による番組情報管理技術の特徴の１つである、ＥＩＴバージョンマトリックス（対照表）の一構成例を示す図である。
【図８】全ＥＩＴバージョンマトリクスの構成例を示す図である。
【図９】本発明の実施の形態によるコンテンツ管理装置を含むコンテンツ視聴装置の一例として示すデジタル放送受信装置の一構成例を示す図である。
【図１０】図１０（ａ）、（ｂ）は、サーバへの番組詳細情報の初期保存処理の一例を示すフローチャート図である。
【図１１Ａ】番組詳細情報のサーバへの追加処理の流れを示すフローチャート図であり、視聴中のサービスのＥＩＴバージョンマトリックス情報を取得する場合の例を示す図である。
【図１１Ｂ】図１１Ａに続き、番組詳細情報のサーバへの追加処理の流れを示すフローチャート図であり、視聴中のサービスのＥＩＴバージョンマトリックス情報を取得する場合の例を示す図である。
【図１２Ａ】番組詳細情報のサーバへの追加処理の流れを示すフローチャート図であり、視聴中以外のサービスのＥＩＴバージョンマトリックス情報を取得する場合の例である。
【図１２Ｂ】図１２Ａに続き、番組詳細情報のサーバへの追加処理の流れを示すフローチャート図であり、視聴中以外のサービスのＥＩＴバージョンマトリックス情報を取得する場合の例である。
【図１３】本発明の第２の実施の形態によるコンテンツ検索技術における処理の流れを示すフローチャート図である。
【発明を実施するための形態】
【００２５】
以下に、本発明の実施の形態によるコンテンツ管理技術について説明する前に、コンテンツ情報の例としてデジタル放送受信装置における、番組情報と番組詳細情報とについて説明を行う。
【００２６】
図１、図２は、番組情報と番組詳細情報との構成例を示す図である。図１に示すように、番組情報２は、簡単な番組の情報を含むものであり、番組のタイトル１とともに、短形式イベント記述子５により記述されている。その他、入力情報７は、コンテンツの信号の形態に関する情報である。
【００２７】
さらに詳細な番組情報は、符号１１、符号１５などに示されるように表示されている。番組詳細情報１１は、サブタイトル、番組内容（あらすじ）、出演者などの各種の番組情報の詳細を含む。さらに、音楽の情報、脚本、演出、プロデューサ、制作者などの情報１５が記述されており、これらは、拡張形式イベント記述子１７と呼ばれている。拡張形式イベント記述子１７は、図２に示すように、放送開始当初の予約語として、「おしらせ」、「番組内容」、「出演者」、「原作・脚本」、「監督・演出」、「音楽」、「制作」などの項目が記述される。発明者は、これらの番組詳細情報を利用してより高度な番組検索などをより便利に利用することができることに想到した。
【００２８】
デジタル放送の規格によれば、地上デジタル放送（地デジ）の場合には、番組名は、短形式イベント記述子であって、全角４０文字以下かつ９６バイト以下で記述される。また、番組記述は、短形式イベント記述子であって、全角８０文字以下かつ１９２バイト以下で、項目名は、拡張形式イベント記述子であって、全角８文字以下かつ１６バイト以下、項目記述は、拡張形式イベント記述子であって、１つの記述子あたり２２０バイト以下とし、１つの項目名に対して最大２つの記述子を配置でき、あわせ全角２００文字以下とすることが規定されている。
【００２９】
また、ＢＳ／広帯域ＣＳの場合には、番組名は、短形式イベント記述子であって、全角４０文字以下かつ８０バイト以下、番組記述は、短形式イベント記述子であって、全角８０文字以下かつ１６０バイト以下、項目名は、拡張形式イベント記述子であって、全角８文字以下かつ１６バイト以下、項目記述は、拡張形式イベント記述子であって、１つの記述子あたり全角１００文字以下かつ２００バイト以下とし、１つの項目名に対して最大２つの記述子を配置できる。また、拡張形式イベント記述子は、１番組当たり最大１６個配置できるため、最大：全角１００文字×１６＝１６００文字である。このように、拡張形式イベント記述子はより多くの情報を含むことから、情報量が多くなることがわかる。
【００３０】
また、拡張形式記述子に必要なメモリ量について概算すると、以下のようになる。
【００３１】
まず、標準的に、３時間当たり８番組であるすると、８日分では最大で、
１６００[文字]×２[バイトコード]×８[番組]＝２５，６００ [byte]となる。また、２４[時間]÷３[時間]×８[日]×２５，６００[byte]＝１，６３８，４００[byte]であるため、地デジ（８ｃｈ）、ＢＳ（１２ｃｈ）、ＣＳ（６５ｃｈ）、ＩＰＴＶ（９１ｃｈ）全部で１７６ｃｈあるとすると、１，６３８，４００[byte]×１７６[ch]＝２８８，３５８，４００ [byte]、すなわち、約２９０[Mbyte]と膨大なデータ量になる。
【００３２】
ＡＲＩＢにおいて標準的に想定しているデジタルＴＶサービス（地デジ）のＥＩＴ [schedule extended]の標準的な見積もり量を参照(ARIB TR-B14 3.9版 第二分冊 4-362)すると、１ＴＳあたり８日分で９４２，５９２ [byte]であり、同様に、地デジ・ＢＳ・ＣＳ・ＩＰＴＶ全部で１７６chであるとすると、９４２，５９２[byte]×１７６[ch]＝１６５，８９６，１９２ [byte]、すなわち約１６６[Mbyte]となる。
【００３３】
一方、デジタル放送受信装置において想定されている短形式イベント記述子用のフラッシュメモリの容量としては、５．５[Mbyte]程度を見込んでいるため、実際のバードウェアの約３０倍の記憶容量が必要となる。
【００３４】
次に、短形式イベント記述子、拡張形式イベント記述子も、各ネットワーク毎の再送周期について説明する。
【００３５】
まず、地デジの場合について説明する。地デジでは、ＰＳＩおよび共通運用ＳＩで伝送すると、Ｈ−ＥＩＴ（固定受信用の番組の名称、放送日時・内容など番組に関する情報）、[p/f] （Ｐｒｅｓｅｎｔ（現在）／ｆｏｌｌｏｗｉｎｇ（次）の番組）の短形式イベント記述子、拡張形式イベント記述子の再送周期は１−３[s]である。
【００３６】
共通ＳＩのうち、短形式イベント記述子（デジタルＴＶサービス）のＨ−ＥＩＴ[ｓｃｈｅｄｕｌｅ ｂａｓｉｃの再送周期は、６０−１８０[s]である。
【００３７】
また、個別運用ＳＩで伝送する場合には、Ｈ−ＥＩＴ[p/f:1-3[s]] 短形式イベント記述子、拡張形式イベント記述子、Ｈ−ＥＩＴ[ｓｃｈｅｄｕｌｅ ｂａｓｉｃ:６０−１８０[s]] 短形式イベント記述子(デジタルＴＶサービス)、Ｈ−ＥＩＴ[ｓｃｈｅｄｕｌｅ ｅｘｔｅｎｄｅｄ:６０−１８０[s]] 拡張形式イベント記述子、である。
【００３８】
また、ＢＳ／広帯域ＣＳの場合において、ＰＳＩおよび全局ＳＩで伝送する場合には、
ＥＩＴ[ｐ／ｆ ａｃｔｕａｌ:１−３[s]][ｐ／ｆ ｏｔｈｅｒ:５−２０[s]] 短形式イベント記述子、ＥＩＴ[ｓｃｈｅｄｕｌｅ ａｃｔｕａｌ ｂａｓｉｃ:６０−３６０[s]][ｓｃｈｅｄｕｌｅ ｏｔｈｅｒ ｂａｓｉｃ:６０−３６０[s]] 短形式イベント記述子であり、各局ＳＩで伝送すると、ＥＩＴ[ｐ／ｆ ａｃｔｕａｌ:１−３[s]][ｐ／ｆ ｏｔｈｅｒ:５−２０[s]] 拡張形式イベント記述子、ＥＩＴ[ｓｃｈｅｄｕｌｅｂａｓｉｃ:６０−３６０[s]]短形式イベント記述子、ＥＩＴ[ｓｃｈｅｄｕｌｅｅｘｔｅｎｄｅｄ:６０−３６０[s]]拡張形式イベント記述子、ＬＤＴ (ＣＳのみ) 拡張形式イベント記述子[６０−３６０[s]]である。
【００３９】
従って、現在または次の番組より後の欲しい拡張形式イベント記述子を取得するには、同チャンネルに選局を行った上で、ＢＳでは、最大で３６０[s]×２(周期)=７２０[s]、すなわち、１２分を要する。また、地デジでは、最大で１８０[s]×２（周期）＝３６０[s]、すなわち、６分を要する。
【００４０】
仮に放送局が最短の再送周期で送ってくれた場合であっても、ＢＳ・地デジとも、最短で６０[s]×２(周期)=１２０[s]、すなわち、２分を要する。（標準的な再送周期では１８０×２(周期)=３６０[s]、すなわち６分を要する。）
【００４１】
従って、全てのチャンネル分の詳細情報を取得するためには、ＢＳでは、最大で７２０[s]×１２(チャンネル)＝８６４０[s]、すなわち１４４分を要する。一方、地デジ(東京)では、最大で３６０[s]×８(チャンネル)=２８８０[s]、すなわち４８分を要する。
【００４２】
従って、最短でも、１２０[s]×１２(チャンネル)＝１４４０[s]、すなわち２４分を要する。但し、この計算は、あくまで放送局が最短の再送周期で送ってくれた場合であり、より長時間を要する可能性が高い。
【００４３】
このように、地デジ、ＢＳで、全チャンネル分の詳細番組情報を全て取得するためには、実際上、かなり長い時間を必要とすることになる。尚、上記において、actualとは、自己のＴＳ（視聴中のチャンネル）であり、otherとは他のＴＳ（視聴中でないチャンネル）であり、scheduleとは、スケジュール情報（ｐ／ｆ）を含む以降の全ての番組情報である。
【００４４】
尚、詳細情報は、必ずしも全てのイベントに対して記載されるわけではない。更にＨ−ＥＩＴ[schedule extended]またはＥＩＴ[schedule extended]の再送周期が長いため、十分な応答性を確保できるものではない。全ブロードキャスタが提供する詳細情報を全て受信しようとすると、ほぼ全てのＴＳを受信しなければならないため、少なくとも選局中ＴＳの個別運用ＥＩＴまたは各局ＥＩＴは速やかに蓄積することが望ましい。但し、ＴＳによってはＨ−ＥＩＴ[schedule extended] またはＥＩＴ[schedule extended]に対して拡張周期グループを運用する場合があり、その場合はある程度の再送周期で伝送される。
【００４５】
イベント毎に詳細情報が存在するかどうかは、Ｈ−ＥＩＴ[schedule extended] またはＥＩＴ[schedule extended]を取得しない限り把握できないが、Ｈ−ＥＩＴ[schedule extended] またはＥＩＴ[schedule extended]自身が運用されているかどうかや運用している場合、どの程度の割合で運用されているかは、ＢＩＴ第２記述子ループ中のＳＩ伝送パラメータ記述子に記載される。詳細は、PSI/SI運用規定13.2.2章に記載されている。伝送の割合に関しては、例えばデータ量の見積もりや、取得動作を起こすかどうかの判断には使えるが、不要だと判断すればあえて利用する必要はない。
【００４６】
図３は、一般的なデジタルテレビジョン受信装置における、短形式イベント記述子のフラッシュメモリへの保存の様子を示す概念図である。図３に示すように、地デジ、ＢＳ、ＣＳ、ＩＰＴＶの全てのネットワークに対し、公平に番組情報（短形式イベント記述子）をフラッシュメモリに保存していることがわかる（符号２１ａから２１ｄまで）。
【００４７】
従って、上記の説明からもわかるように、全てのネットワークにおける番組情報に加えて番組詳細情報も取得し、フラッシュメモリに格納するとなると、フラッシュメモリの占有容量が大きくなる上に、取得に要する時間も長くなるという問題がある。
【００４８】
そこで、本発明の実施の形態によるデジタルテレビジョン受信装置では、番組情報の管理（保存）処理に関して、以下のような工夫を行っている。
【００４９】
図４は、図３に対応する図であり、後述する構成を持つ本発明の実施の形態によるデジタルテレビジョン受信装置における、拡張形式イベント記述子の保存の様子を示す概念図である。図４に示すように、地デジ、ＢＳ、ＣＳ、インターネットを介して映像を配信するＩＰＴＶ（Internet Protocol Television）などの全てのネットワークの番組詳細情報を、装置とネットワーク（オープンネットワーク、次世代ネットワークやＬＡＮでも良い。）ＮＴ経由で接続される外部サーバなどのサーバ２５内に格納している様子が示される。この図では、外部サーバの大きな記憶容量を利用して、全てのコンテンツネットワークの番組詳細情報２１を外部サーバ２５内に保持している。そして、ネットワーク経由で、適宜、デジタル放送テレビジョン受信装置内に必要に応じて利用する仕組みになっている。尚、サーバは、記録再生装置内蔵テレビのＨＤＤであっても良く、或いは、装置からアクセスできるメーカの運用するサーバであっても良い。いずれにしても、番組情報とは異なり、装置内のフラッシュメモリ内に全てを記憶しない点が重要である。
【００５０】
図５は、後述するＥＩＴバージョンマトリックスの構成要素であって一度に取得できる最小単位のＥＩＴの構成例を示す図である。図５に示すように、最小単位は、３時間毎に固まった１固まりの情報３１になっている。この１固まりの情報３１には、ＥＩＴ（Ｖｅｒ．０ｘ１Ａで示される５ビットのインデックス（２次元）が対応付けされている。図５に示す１固まりの情報３１は、例えば、０．５時間の時間帯毎の３つの情報３１ａから３１ｆまでになっており、それぞれの情報には、サブタイトルＸ１〜Ｘ６までのぞれぞれと、１６ビットの異なるイベントＩＤとが記述されている。続きの番組であれば、イベントＩＤが同じになっていることでわかるようになっている。尚、サブタイトルが異なれば、イベントＩＤも異なるが、ここでは、その点を図には反映させていない。
【００５１】
図６は、図５と同様の１固まりの情報３１であるが、例えば、深夜の番組などで、時間的に継続していない途中で放送が無い場合の例を示す図である。図６に示すように、途中の放送（１：００〜２：３０分）が無い場合でも、情報自体が無いことは、１固まりの情報を取得した時点でわかるようになっている。尚、１固まりの定義は、任意である。
【００５２】
また、同じ番組の詳細情報であっても、１週間先の番組として最初に記述されても、途中で（例えば当日）情報が更新されることもありうる。情報が更新されたことは、図５、６に示すような、ＥＩＴ (Event Information Table)のバージョン番号（version_number）が更新されたか否かを見ることによって判別することができる。
【００５３】
図７は、本実施の形態による番組情報管理技術の特徴の１つである、ＥＩＴバージョンマトリックス（対照表）５１の一構成例を示す図である。このＥＩＴバージョンマトリックスは、ネットワークＩＤとサービスＩＤとの組毎に、ＥＩＴのバージョン情報と番組詳細情報が取得済みか否かの情報とを、放送時間帯と日時との２軸で画定された２次元平面上にマトリックス状に記載したものである。
【００５４】
図７は、地デジ（ネットワークＩＤ：０ｘ７ＦＥ０）、０１１ｃｈ（サービスＩＤ：０ｘ０４００）のＥＩＴバージョンマトリクス５１の例である。横軸は時間帯５５であり、縦軸は現在日時（１日目）から起算した８日目までの日５３である。縦軸５３と横軸５５とにより画定される２次元平面に多数の３時間毎の１固まりの情報５７が設けられている。この１固まりの情報５７は、ＥＩＴのバージョン番号５７ａと、番組詳細情報を取得済みであるか否かの情報５７ｂ（取得済み）又は５７ｃ（未取得）の情報と、を有している。このＥＩＴのバージョンマトリックス５１により、ある日のある時間帯の１固まりの情報が取得済みであるか否かを符号５７ｂ・５７ｃの記述により知ることが出来る。また、現在時間もポインタ６１により表示されていると便利である。例えば地デジの受信中に、番組詳細情報を含む情報をサーバ２５から取得して、ＥＩＴバージョンマトリックス５１を埋めていくことで、どの日のどの時間帯の１固まりの情報を取得済みであるかを知ることが出来る。このＥＩＴバージョンマトリクス５１は、テレビとサーバとの最小単位の共有情報ともいうべきものである。もちろん、このＥＩＴバージョンマトリクス５１には、番組詳細情報が含まれず、あくまで、その情報がサーバにあるか否かの情報のみが存在するのが好ましい。
【００５５】
図８は、全ＥＩＴバージョンマトリクスの構成例を示す図である。図８に示すように、全ＥＩＴバージョンマトリクス５０は、チャンネル軸（地デジ５１−１、ＢＳ５１−２、ＣＳ５１−３、…ＩＰＴＶ５１−ｎなど）をもつ３次元的な構成を有している。この全ＥＩＴバージョンマトリクス５０により、全てのコンテンツネットワークについて、テレビとサーバとが最小単位の共有情報を有することになる。
【００５６】
次に、必要なメモリ（ＲＡＭ）について説明する。必要なメモリ領域としては、通常の視聴に不足が無い分の番組情報と、メモリ（ＲＡＭ）に展開可能な分の幾つかの番組詳細情報と、８日分のＥＩＴマトリクス（バージョン）を保存できるだけの領域があれば良い。
例えば、ＥＩＴマトリクス１個当たりＥＩＴのバージョン１[byte]と、状態管理用（取得済み／未取得／取得要求）用に１[byte]で、計２[byte]を使うと仮定すると、必要な記憶領域の容量は、１チャンネル当たり：２４[時間]÷３[時間]×８[日]×２[byte]＝１２８[byte]である。
【００５７】
また、地デジ（８ｃｈ）、ＢＳ（１２ｃｈ）、ＣＳ（６５ｃｈ）、ＩＰＴＶ（９１ｃｈ）あるとすると、８＋１２＋６５＋９１＝１７６[ｃｈ]分であり、従って、１２８[byte]×１７６[ｃｈ]＝２２５２８[byte]=約２３[Ｋbyte]の記憶容量があれば良いことになる。従って、番組詳細情報自体を持たないため、ＥＩＴバージョンマトリックスに要する記憶容量はきわめて少なくて良い。
【００５８】
図９は、本発明の実施の形態によるコンテンツ管理装置を含むコンテンツ視聴装置の一例として示すデジタル放送受信装置の一構成例を示す図である。図９に示すように、デジタル放送受信装置Ａは、アンテナ１０１から受信した放送波の受信処理を行うフロントエンド１０３と、受信した信号を、映像・音声とデータとに分けるデマルチプレクサ１０５と、映像・音声のデコードを行う映像・音声デコード部１０７と、スピーカなどの音声出力部１０９と、映像と種々のデータ等を合成する画面合成部１１１と、合成された画面表示を行う液晶ディスプレイなどの表示部１１３と、高速のＲＡＭなどからなるメモリ部１２３と、フラッシュメモリからなる記憶部１２５と、全体を制御する制御部（ＣＰＵ）１２１と、外部とのインターフェイス部１３１と、を有している。コンテンツ情報は、アンテナ１０１からフロントエンド１０３と、デマルチプレクサ１０５と、介して取得することができる（コンテンツ情報取得部を形成する）。さらに、デマルチプレクサ１０５により取得したＳＩ情報などに含まれる番組情報（番組詳細情報を含む）をデコードする番組情報デコード部１１５と、番組情報に基づいて、電子番組表（ＥＰＧ）を作成する電子番組表データ生成部１１７と、リモコン信号を受光するリモコン受光部１２７と、外部サーバ２５などとネットワークＮＴを介して機器を接続するための外部とのインターフェイス部１３１と、を有している。記憶部１２５には、以下において説明する番組情報の管理に関するフローチャートで示す処理を制御部１２１に実行させるためのプログラムが格納されている。このプログラムにより、コンテンツ情報を管理するコンテンツ情報管理部１２１ａを形成することができる。さらに、後述するように、装置内部（ハードディスクなど）又は外部に存在するコンテンツを検索するコンテンツ検索部１２１ｂが設けられていても良い。
【００５９】
また、インターフェイス部１３１は、ネットワークＮＴを介してサーバ２５と接続されている。サーバ２５は、番組詳細情報を格納する番組詳細情報格納部２５ａを有している。
【００６０】
また、コンテンツ管理部１２１ａは、図７，８に示すＥＩＴバージョンマトリックスを作成し、メモリ部（ＲＡＭ）１２３に保存する。
【００６１】
以下に、プログラム処理について説明する。まず、本発明の第１の実施の形態によるコンテンツ情報管理技術について説明する。
【００６２】
図１０（ａ）、（ｂ）は、サーバ２５への番組詳細情報の初期保存処理の一例を示すフローチャート図である。図１０に示すように、まず、ステップＳ１において、自動的に又はユーザ操作により処理が開始されると（ＳＴＲＡＴ）、ステップＳ２において、ＲＡＭ内のＥＩＴバージョンマトリックス（ｍ，ｎ）を初期化する。ｍ、ｎは、日にちと時間帯である。次いで、ステップＳ３において、視聴中のネットワーク（例えば地デジ）の拡張形式イベント記述子を含むＥＩＴのネットワークＩＤとサービスＩＤとを取得し、ＲＡＭ内に保存する。ネットワークとしては地デジ以外から処理を開始するようにしても良い。ステップＳ４において、上記ＥＩＴのイベントＩＤと同じイベントＩＤを持つ番組詳細情報を取得し、ＲＡＭ内に保存する。これにより、図７のＥＩＴバージョンマトリクスの１つのマス目５７内の情報を取得できる。ここで、ＲＡＭであれば、比較的大容量であるから、番組詳細情報を一時的に保存するのに適している。次いで、ステップＳ５において、図７のマトリクスの１つのマス目５７内の全てのイベントの番組詳細情報を取得したか否かを判定し、ＮＯであれば、ステップＳ４に戻り、ＹＥＳであれば、ステップＳ６に進む。ステップＳ６においては、ＥＩＴマトリクス(ｍ，ｎ)に、取得したＥＩＴのバージョンを書き込み、ＥＩＴ取得済みフラグを立ててＲＡＭ内に保存する。これにより、図５の１固まりの情報が保存される。上記の処理で、未取得分のみ情報を取得することができる。
【００６３】
次いで、ステップＳ７において、インターフェイス部１３１を介してネットワークＮＴ上のサーバ２５に接続する。ステップＳ８において、サーバに接続出来たか否かを判定する。ＮＯの場合には、ステップＳ３に戻り、ＹＥＳの場合には、ステップＳ９に進む。ステップＳ９においては、機器個体ＩＤ、すなわち、テレビを一意に識別するＩＤ（機体のシリアル番号など）をサーバに通知する。ステップＳ１０において、テレビの設置されている地域設定（地域コード）をサーバ２５に通知する。これにより、サーバ２５は、接続されているテレビがどのテレビであり、どの地域に設置されているかを知ることが出来る。例えば、サーバが装置メーカ等の運用するサーバであれば、そのテレビがサービスとなるテレビであるかなどをチェックすることも可能である。また、地デジなどの場合には、地域コードが異なると、チャネル構成が異なるため、地域コードを取得する必要がある。
【００６４】
ステップＳ１１において、テレビのＲＡＭ１２３に保存したネットワークＩＤとサービスＩＤと、をサーバ２５にも登録する。この処理により、ＥＩＴバージョンマトリックス５１の１マス５７内の情報（ＥＩＴバージョンＩＤ、番組詳細情報、取得済みか否か）を埋めることができる。
【００６５】
次いで、ステップＳ１２において、ＲＡＭ１２３に保存したイベントＩＤと同じイベントＩＤを持つ番組の番組詳細情報をサーバ２５に登録する。この処理により、図７のＥＩＴバージョンマトリクスの１つのマス目５７内の情報が登録される。次いで、ステップＳ１３において、１つのマス目内の全てのイベントの番組詳細情報をサーバ２５に通知したか否かを判定する。ＮＯであれば、ステップＳ１２に戻り、ＹＥＳであれば、ステップＳ１４に進み、図７に示すようなＥＩＴマトリクス(ｍ，ｎ)を、上記のネットワークＩＤおよびサービスＩＤに関連付けてサーバ２５に登録し、ステップＳ１５においてサーバと装置との接続を切り、サーバへの初期保存処理を終了する。これにより、１つのＥＩＴバージョンマトリックスがサーバ２５に格納される。
【００６６】
図１１Ａ、図１１Ｂは、番組詳細情報のサーバへの追加処理の流れを示すフローチャート図であり、視聴中のサービスのＥＩＴバージョンマトリックス情報を取得する場合の例を示す図である。まずこの処理を開始すると（ステップＳ２１：ＳＴＡＲＴ）、ステップＳ２２において、装置をネットワーク上のサーバ２５に接続を試みる。ステップＳ２３で、サーバ２５への接続を確認すると（ＹＥＳ）、ステップＳ２４において、サーバ２５から、現在時刻以降の全サービスのＥＩＴマトリクス(ｍ，ｎ)を取得し、保存していた古いデータを消去する。ステップＳ２５において、視聴中のネットワークおよびサービスからＥＩＴマトリクス(ｍ，ｎ)上で未取得の拡張形式イベント記述子を取得可能か否かについて判定する（拡張形式イベント記述子の取得判定部）。ＮＯであれば、ステップＳ３０に進み、ＹＥＳであれば、ステップＳ２６に進む。ステップＳ２６においては、未取得の拡張形式イベント記述子を含むＥＩＴを取得しネットワークＩＤとサービスＩＤとを、装置のＲＡＭ１２３に保存する。ステップＳ２７においては、上記ＥＩＴのイベントＩＤと同イベントの番組詳細情報とをＲＡＭ１２３に保存する。この際、フラッシュメモリ１２５には保存しない。次いで、ステップＳ２８において、図７のマトリクスの１つのマス目５７内の全てのイベントのイベントＩＤと同イベントの番組詳細情報をＲＡＭ１２３に保存したか否かを判定する。ＮＯであれば、ステップＳ２７に戻り、ＲＡＭ１２３への保存処理を継続する。ＹＥＳであれば、ステップＳ２９に進み、取得したＥＩＴのバージョンをＥＩＴマトリクス(ｍ，ｎ)に書き込み、ＥＩＴ取得済みフラグを立ててＲＡＭ１２３に保存する。次いで、ステップＳ３０において、ＥＩＴマトリクス(ｍ，ｎ)上で、放送波中のＥＩＴと格納されているＥＩＴバージョンマトリックスとを比較することで、取得済みの拡張形式イベント記述子を含むＥＩＴのバージョンに変更が生じたか否かを判定する。
【００６７】
次いで、ステップＳ３１において、上記ＥＩＴのイベントＩＤと同イベントの番組詳細情報とを再取得し、再取得した情報をＲＡＭ１２３に保存する。ステップＳ３２において、図７のマトリクスの１つのマス目５７内の全てのイベントのイベントＩＤと同イベントの番組詳細情報をＲＡＭ１２３に保存したか否かを判定する。ＮＯの場合には、ステップＳ３１に戻り、全てのイベントについてイベントＩＤと同イベントの番組詳細情報をＲＡＭ１２３に保存するまで処理を継続する。ＹＥＳの場合には、ステップＳ３３に進み、ＥＩＴマトリクス(ｍ，ｎ)に、取得したＥＩＴのバージョンを書き込み、ＥＩＴ取得済みフラグを立ててＲＡＭ１２３に保存する。
【００６８】
次いで、ステップＳ３４において、ＥＩＴマトリクス(ｍ，ｎ)に変更が生じているか否かを判定する。ＮＯの場合にはステップＳ４１に進み、ＹＥＳの場合にはステップＳ３５に進む。ステップＳ３５では、装置の機器個体ＩＤをサーバ２５に通知する。次いで、ステップＳ３６に進み、装置が設置されている地域設定（地域コード）をサーバ２５に通知する。次いで、ステップＳ３７において、ＲＡＭ１２３に保存したネットワークＩＤとサービスＩＤとをサーバ２５にも登録する。ステップＳ３８において、ＲＡＭ１２３に保存したイベントＩＤと同イベントの番組詳細情報をサーバ２５に登録する。ステップＳ３９において、図７のマトリクスの１つのマス目５７内の全てのイベントのイベントＩＤと同イベントの番組詳細情報をサーバ２５に通知したか否かを判定する。ＮＯの場合には、ステップＳ３８に戻り、全てのイベントの番組詳細情報をサーバ２５に通知するまで処理を継続する。ＹＥＳの場合には、ステップＳ４０に進み、更新したＥＩＴマトリクス(ｍ，ｎ)を、上記ネットワークＩＤおよびサービスＩＤに関連付けてサーバ２５に登録する。次いで、ステップＳ４１に進み（ステップＳ３４でＮＯの場合も）、サーバと装置との接続を切り、ステップＳ４２で処理を終了する。このようにして、視聴中のサービスの番組情報をサーバに追加し、更新したＥＩＴバージョンマトリックスの情報（ＥＩＴバージョンマトリックス（ｍ，ｎ））を、ネットワークＩＤ、サービスＩＤに関連付けしてサーバに登録することができる。これにより、ＲＡＭ１２３に保存したサービスＩＤとイベントＩＤと関連付けした番組詳細情報とＥＩＴバージョンマトリックスをサーバから取得可能になる。
【００６９】
図１２Ａ、図１２Ｂは、番組詳細情報のサーバへの追加処理の流れを示すフローチャート図であり、視聴中以外のサービスのＥＩＴバージョンマトリックス情報を取得する場合の例である。まずこの処理を開始すると（ステップＳ５１：ＳＴＡＲＴ）、ユーザ操作又は更新情報の検知などにより、ステップＳ５２において、装置を、ネットワーク上のサーバ２５に接続する。次いで、ステップＳ５３において、サーバに接続できたか否かを検出し、ＮＯであれば、ステップＳ５２に戻り接続処理を例えば所定の回数だけ継続する。ＹＥＳであれば、サーバ２５に接続できたので、次いで、ステップＳ５４において、サーバ２５から現在時刻以降の全サービスのＥＩＴマトリクス(ｍ，ｎ)を取得し、現在時刻以前の古いデータを消去する。ステップＳ５５において、視聴中では無いサービス又は視聴中のサービス以外にＥＩＴマトリクス(ｍ，ｎ)上で未取得の拡張形式イベント記述子を取得することが可能か否かを判定する（拡張形式イベント記述子の取得判定部）。例えば、サービスを視聴中で、チューナを利用している場合に、視聴等を行っていない別のチューナがあれば、ＹＥＳと判定され、余りのチューナがなければＮＯと判定される。ここでＮＯであれば、ステップＳ５７に進み、視聴が終了しチューナが空くまで待機し、ステップＳ５８において、視聴が終了したか否かを監視する。視聴が終了すると（ＹＥＳ）、ステップＳ５５においてＹＥＳの場合と同様に、ステップＳ５６に進み、未取得の拡張形式イベント記述子を含むＥＩＴを取得しネットワークＩＤとサービスＩＤとを装置のＲＡＭ１２３に保存する。
【００７０】
次に、ステップＳ５９において、上記ＥＩＴのイベントＩＤと同イベントの番組詳細情報をＲＡＭ１２３内に保存する。ステップＳ６０において、図７のマトリクスの１つのマス目５７内の全てのイベントの番組詳細情報をＲＡＭ１２３内に保存したか否かを判定する。ＮＯの場合には、ステップＳ５９に戻り、次のＥＩＴのイベントＩＤと同イベントの番組詳細情報をＲＡＭ１２３内に保存していく。ＹＥＳの場合には、ステップＳ６１に進み、ＥＩＴマトリクス(ｍ，ｎ)に、取得したＥＩＴのバージョンを書き込み、ＥＩＴ取得済みフラグを立ててＲＡＭ１２３内に保存する。
【００７１】
次に、ステップＳ６２において、ＥＩＴマトリクス(ｍ，ｎ)上で、取得済みの拡張形式イベント記述子を含むＥＩＴのバージョンに変更が生じたか否かを判定する。ＮＯであれば、ステップＳ６６に進み、ＹＥＳであれば、ステップＳ６３に進む。ステップＳ６３において、上記ＥＩＴのイベントＩＤと同イベントの番組詳細情報を再取得しＲＡＭ１２３内に保存する。ステップＳ６４において、図７のマトリクスの１つのマス目５７内の全てのイベントの番組詳細情報を保存したかを判定し、ＮＯであればステップＳ６３に戻り、１つのマス目内の全てのイベントの番組詳細情報を保存すると（ＹＥＳ）ステップＳ６５に進み、取得したＥＩＴのバージョンをＥＩＴマトリクス(ｍ，ｎ)に書き込み、ＥＩＴ取得済みフラグを立ててＲＡＭ１２３内に保存する。ステップＳ６６に進むと、ＥＩＴマトリクス(ｍ，ｎ)に変更が生じているか否かを判定する。ＮＯの場合にはステップＳ７３に進み、ＹＥＳの場合にはステップＳ６７に進む。ステップＳ６７においては、機器個体ＩＤをサーバ２５に通知する。次いで、ステップＳ６８において、地域設定（地域コード）をサーバに通知する。これにより、装置及びその設置地域をユニークに特定することができる。次に、ステップＳ６９において、ＲＡＭ１２３に保存したネットワークＩＤとサービスＩＤとをサーバ２５に登録し、ステップＳ７０において、ＲＡＭ１２３に保存したイベントＩＤと同イベントの番組詳細情報とをサーバ２５に登録する。ステップＳ７１において、図７のマトリクスの１つのマス目５７内の全てのイベントの番組詳細情報をサーバ２５に通知したか否かを判定し、ＮＯの場合には、ステップＳ７０に戻る。ＹＥＳの場合には、ステップＳ７２に進み、上記ネットワークＩＤおよびサービスＩＤに関連付けて、更新したＥＩＴマトリクス(ｍ，ｎ)をサーバ２５に登録する。次いで、ステップＳ６５でＮＯの場合と同様に、ステップＳ７３に進み、装置とサーバとの接続を切断し、ステップＳ７４で処理を終了する。以上の処理により、視聴中以外のサービスにおいて、ＥＩＴバージョンマトリックスの情報を取得することができるため、このような場合でも、追加の番組情報、番組詳細情報を取得することができる。
【００７２】
次に、本発明の第１の実施の形態によるコンテンツ情報管理技術を利用したコンテンツの検索技術について説明する。図１３（ａ）、（ｂ）は、本発明の第２の実施の形態によるコンテンツ検索技術における処理の流れを示すフローチャート図である。ここでは、地デジを対象にした例について説明するが、全ネットワーク（例えば地デジ・ＢＳ・ＣＳ・ＩＰＴＶ）を対象にしても良い。すなわち、全サービス（例えば１０１ｃｈ〜２２２ｃｈ）を対象にしても良いことは言うまでもない。前提として、上記コンテンツ詳細情報の管理が行われているものとする。
【００７３】
まず、処理が開始されると（ステップＳ８１：ＳＴＡＲＴ）、ステップＳ８２において、検索キーワードと検索対象とするネットワーク（例えばコンテンツネットワークとして地デジの範囲内）とサービス（１０１ｃｈ）と検索日時（２００９年１０月１０日など）および検索範囲（時間帯１２：００〜１５：００）を指定（決定）する。ステップＳ８３において、ネットワーク上のサーバに接続を試みる。ステップＳ８４において、ネットワーク上のサーバに接続出来たか否かを判定し、ＮＯであれば、ステップＳ８３で、ある回数、再接続を試みる。ＹＥＳであれば、ステップＳ８５で、機器個体ＩＤをサーバ２５に通知する。次いで、ステップＳ８６で、地域設定（地域コード）をサーバ２５に通知する。これにより、装置の設置場所と装置の機種をユニークに識別することができる。ステップＳ８７において、装置側からの入力などにより、検索キーワードと検索対象のネットワークＩＤとサービスＩＤと日時および範囲をサーバ２５に通知する。ステップＳ８８において、検索キーワードに該当する（全部一致又は一部一致などでヒットする）イベントＩＤと同イベントの番組詳細情報とをサーバ２５から取得する。ステップＳ８９において、全ての情報をサーバ２５から取得したか否かを判定し、ＮＯであれば、ステップＳ８８に戻り、情報の取得を継続する。ＹＥＳであれば、ステップＳ９０において、検索キーワードに該当するイベントの番組詳細情報をＴＶ画面など装置の表示部に表示させることができる。ステップＳ９１で、ネットワーク上のサーバとの接続を切断すると、処理が終了する（ステップＳ９２）。
【００７４】
上記の検索処理においては、番組詳細情報も検索対象とすることで、より精度の良い番組検索を実行することができる。尚、検索など、サーバ上の番組詳細情報が必要な場合は通常、装置が起動中であるため図１の場合に相当し、既にＥＩＴマトリクスは装置側で取得済みであるため、検索日時および範囲がＥＩＴマトリクスの取得済みの範囲に該当する場合にのみネットワークに接続して検索を行うようにしても良い。該当しない場合には、番組詳細情報に基づく検索はできないからである。番組情報のみによる検索と、番組詳細情報を加えた詳細検索を、切り替えて実行できるようにしても良い。
【００７５】
また、装置とネットワーク接続されるサーバを例にして説明したが、ネットワーク接続は、有線、無線を問わない。また、サーバの位置を限定するものではなく、また、分散配置されたサーバであっても良い。
【００７６】
尚、ＴＶなどの装置が、全ＥＩＴマトリクスを取得する際には、取得済みの情報、未取得の情報を保存する領域に対し、サーバ側で未取得ＥＩＴの取得優先順位を付けるようにしてもよい。例えば、上記の再送周期の説明において、再送周期は３日目までが短いことを考慮して、全ＥＩＴバージョンマトリックスを早く完成させるために、ＥＩＴマトリクスにおける情報取得の速度を考慮して、未取得ＥＩＴの取得優先順位を付けても良い。
【００７７】
さらに、本発明の実施の形態によるコンテンツ（情報）管理技術を利用したコンテンツ表示技術について説明する。図９の番組表データ生成部１１７において、番組表に番組情報のみならず詳細番組情報を生成し、番組表データに保持させると便利である。このような場合にも、利用するネットワークコンテンツの詳細番組情報をサーバに持たせておく管理を行うことで、サーバから番組詳細情報も読み出すことで電子番組表などを作成する場合などのコンテンツ表示において、より詳細な情報を表示させることができるという利点がある。
【００７８】
上記の実施の形態において、添付図面に図示されている構成及び明細書での説明等については、これらに限定されるものではなく、本発明の効果を発揮する範囲内で適宜変更することが可能である。その他、本発明の目的の範囲を逸脱しない限りにおいて適宜変更して実施することが可能である。例えば、本実施の形態では、デジタル放送受信装置を例にして説明したが、その他、デジタル放送を受信可能なレコーダ装置、携帯端末などにも利用可能である。特に、テレビ機能付き携帯端末装置では、メモリの容量が少なくなるため、本発明による効果が大きい。
【００７９】
また、本実施の形態で説明した機能を実現するためのプログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行することにより各部の処理を行ってもよい。尚、ここでいう「コンピュータシステム」とは、ＯＳや周辺機器等のハードウェアを含むものとする。
【００８０】
また、「コンピュータシステム」は、ＷＷＷシステムを利用している場合であれば、ホームページ提供環境（あるいは表示環境）も含むものとする。
【００８１】
また、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ＲＯＭ、ＣＤ−ＲＯＭ等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置のことをいう。さらに「コンピュータ読み取り可能な記録媒体」とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムを送信する場合の通信線のように、短時間の間、動的にプログラムを保持するもの、その場合のサーバやクライアントとなるコンピュータシステム内部の揮発性メモリのように、一定時間プログラムを保持しているものも含むものとする。また前記プログラムは、前述した機能の一部を実現するためのものであっても良く、さらに前述した機能をコンピュータシステムにすでに記録されているプログラムとの組み合わせで実現できるものであっても良い。
【産業上の利用可能性】
【００８２】
本発明は、コンテンツ受信装置のコンテンツ情報管理に利用可能である。
【符号の説明】
【００８３】
Ａ…デジタル放送受信装置、２５…サーバ、２５ａ…番組詳細情報格納部（第２の記憶部）、１０１…アンテナ、１０３…フロントエンド、１０５…デマルチプレクサ、１０７…映像・音声デコード部、１０９…音声出力部、１１１…画面合成部、１１３…表示部、１１５…番組情報デコード部、１１７…電子番組表データ生成部、１２１…制御部（ＣＰＵ）、１２１ａ…コンテンツ詳細情報管理部、１２１ｂ…コンテンツ検索部、１２３…メモリ部（第１の記憶部、ＲＡＭ）、１２５…記憶部（フラッシュメモリ）、１２７…リモコン受光部、１３１…インターフェイス部。
【技術分野】
【０００１】
本発明は、コンテンツ詳細情報の管理技術に関し、特に、デジタル放送受信装置における番組詳細情報の管理技術に関する。
【背景技術】
【０００２】
デジタル放送受信装置において利用されるコンテンツ（番組）に関連する情報には、番組に関する簡単な説明を含む番組情報と、番組の詳細な説明を含む番組詳細情報と、が含まれる。
【０００３】
デジタル放送などでは、多くの番組が提供されるため、コンテンツの管理が重要になってくる。例えば、下記特許文献１に記載の技術では、テレビ放送局から放送衛星を介して多重化ストリームで送信されたデジタル放送を、送受信機で受信してテレビで表示する。このデジタル放送は情報付与センタでも受信されるようにしておく。そして、情報付与センタでは、データ放送用文書を構文解析して、名詞（キーワードなど）を抽出する。この名詞に基づく詳細情報をインターネット等で検索し、この詳細情報を番組情報データベースに格納するとともに、この名詞をカテゴリやキーワードとしてテレビに表示させるものである。
【０００４】
このようにして表示されたカテゴリやキーワードを視聴者が選択することにより、番組情報データベースからテレビの画面上に、その選択されたカテゴリやキーワードに応じた詳細情報を提供することができる。
【０００５】
また、非特許文献１には、番組詳細情報を含む規格が規定されている。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２００２−２４２５０号公報
【非特許文献】
【０００７】
【非特許文献１】http://www.arib.or.jp/tyosakenkyu/kikaku_hoso/hoso_gijutsu_number.html技術資料 ARIB TR-B14 3.9版
【発明の概要】
【発明が解決しようとする課題】
【０００８】
しかしながら、上記特許文献１に記載の技術は、送受信機で受信してテレビで表示する情報を、情報付与センタでも受信し、この情報付与センタにおいて、ＥＰＧや番組関連情報など、放送局が作成して画面上で提供する情報に追加して、番組検索などを行うものであり、その、現在放送している番組の内容に直接関連するものがほとんどである。上記の視聴中でない番組を含むＥＰＧや番組関連情報、特に番組詳細情報を取得し視聴者に提供するためには、受信機で受信できる情報の再送周期が長いため十分な応答性を確保できず、視聴者の要求を十分に満足させることができない。
【０００９】
また、上記非特許文献１に記載の規格によれば、番組詳細情報は必ずしも全てのイベント（番組）に対して記載されている訳ではなく、また、視聴中でない番組を含むＥＩＴ（Ｅｖｅｎｔ Ｉｎｆｏｒｍａｔｉｏｎ Ｔａｂｌｅ）の再送周期が長いため、十分な応答性を確保できるものではないとの記述があるので、受信機では不揮発性メモリ（フラッシュメモリ）には保存せず、番組情報のみをフラッシュメモリに保存し番組詳細情報は取得できた分だけを揮発性メモリ（ＲＡＭ）にのみ記憶させるように設計されている場合が多い。
【００１０】
加えて、ユーザがＢＳ・ＣＳを視聴するのか、地デジを視聴するのか、ＩＰＴＶを視聴するのか、それとも全てのネットワークに対し同じ様に視聴するのか、などを前もって判別することはできないため、ＢＳ・ＣＳ、地デジ、ＩＰＴＶにおけるそれぞれの番組情報を差別化せずに同じ様にフラッシュメモリに保存しているのが現状である。
【００１１】
本発明は、多様なコンテンツネットワークを有するコンテンツ受信装置において、コンテンツの詳細情報を効率良く管理する技術を提供することを目的とする。
【課題を解決するための手段】
【００１２】
本発明は、地デジ・ＢＳ・ＣＳ・ＩＰＴＶなどの多様なコンテンツネットワークから得られた番組詳細情報をテレビジョン受信装置などの装置本体の内部の不揮発性メモリ（フラッシュメモリ）には保存せずに、イーサネットワーク上の外部サーバ等のサーバに適時保存しておくこと、サーバにおけるコンテンツ詳細情報の取得状況を高速ＲＡＭに記憶しておくことを特徴とする。更新時にも、同様にＲＡＭに、コンテンツ詳細情報の保存状況を記憶するとともに、コンテンツ詳細情報自体はサーバに記憶する。
【００１３】
そして、“キーワード検索”などの操作で番組詳細情報に基づく検索が必要になった時点で、サーバに保存されている番組詳細情報を対象に検索を行い、検索にヒットした情報だけをサーバから再取得することにより、莫大な記憶領域を占有する番組詳細情報を対象に“キーワード検索”等の処理が可能となる。
【００１４】
本発明の一観点によれば、コンテンツネットワークにおけるコンテンツのコンテンツ詳細情報を管理するコンテンツ詳細情報管理装置であって、前記コンテンツ詳細情報と、取得した前記コンテンツ詳細情報のバージョン情報及びコンテンツ詳細情報の取得状況を含むＥＩＴバージョン情報と、を取得するコンテンツ情報取得部と、前記コンテンツ情報取得部が取得した前記コンテンツ詳細情報と前記ＥＩＴバージョン情報とを記憶する第１の記憶部と、前記第１の記憶部に記憶させて生成した前記ＥＩＴバージョン情報と前記コンテンツ詳細情報とを、インターフェイス部を介して装置と接続されたサーバの第２の記憶部にも前記第１の記憶部の前記ＥＩＴバージョン情報と対応させて記憶させる処理を行うコンテンツ詳細情報管理部と、を有することを特徴とするコンテンツ詳細情報管理装置が提供される。
【００１５】
また、本発明は、コンテンツネットワークにおけるコンテンツのコンテンツ詳細情報を管理するコンテンツ詳細情報管理装置であって、前記コンテンツ詳細情報と、取得した前記コンテンツ詳細情報のバージョン情報及びコンテンツ詳細情報の取得状況を含むＥＩＴバージョン情報と、を取得するコンテンツ情報取得部と、前記コンテンツ情報取得部が取得した前記コンテンツ詳細情報と前記ＥＩＴバージョン情報とを記憶する第１の記憶部と、前記コンテンツ情報取得部が取得した前記コンテンツ詳細情報を順次記憶する第２の記憶部を有するサーバと接続するためのインターフェイス部と、前記第１の記憶部に記憶させて生成した前記ＥＩＴバージョン情報と前記コンテンツ詳細情報とを、前記インターフェイス部を介して装置と接続されたサーバの第２の記憶部にも前記第１の記憶部の前記ＥＩＴバージョン情報と対応させて記憶させる処理を行うコンテンツ詳細情報管理部と、を有することを特徴とするコンテンツ詳細情報管理装置である。
【００１６】
前記コンテンツ詳細情報管理部は、前記ＥＩＴバージョン情報の前記一単位を複数集めて生成したＥＩＴバージョンマトリックスを生成し、前記第１の記憶部に記憶させることが好ましい。ＥＩＴバージョンマトリックスのＥＩＴバージョン情報とコンテンツ詳細情報の取得状況とから、サーバの第２の記憶部に記憶されているコンテンツ詳細情報にアクセスして、所望のコンテンツ詳細情報のみを取得することができる。ＥＩＴバージョンマトリックスは、例えば、ネットワークＩＤとサービスＩＤとの組毎に、ＥＩＴのバージョン情報とコンテンツ詳細情報が取得済みか否かの情報とを、放送時間軸と日時軸との２軸で画定された２次元平面上にマトリックス状に記載したものである。前記ＥＩＴバージョンマトリックスにおける前記一単位は、放送時間帯と放送日とにより画定されることが好ましい。
【００１７】
前記コンンツ詳細情報管理部は、複数のコンテンツネットワークについて、それぞれ、チャンネル軸に沿って前記ＥＩＴバージョン情報を有する全ＥＩＴマトリックスを作成することが好ましい。全ＥＩＴマトリクスを取得する際に、取得済みである旨の情報、未取得である旨の情報を保存する領域に対し、サーバ側で未取得ＥＩＴの取得優先順位を付けることが好ましい。また、前記ＥＩＴマトリクスにおける情報取得の速度を考慮して、未取得ＥＩＴの取得優先順位を付けることが好ましい。前記ＥＩＴバージョン情報の前記バージョン情報に基づいて、前記コンテンツ詳細情報の更新の有無を判定すると良い。前記コンテンツ詳細情報は、拡張形式イベント記述子により記載されていることを特徴とする。
【００１８】
本発明は、上記のいずれか１に記載のコンテンツ詳細情報管理装置と、前記サーバに記憶されている前記コンテンツ詳細情報に基づいて、コンテンツの検索を行うコンテンツ検索部と、を有することを特徴とするコンテンツ検索装置であっても良い。
【００１９】
また、上記のいずれか１に記載のコンテンツ詳細情報管理装置と、前記サーバに記憶されている前記コンテンツ詳細情報とに基づいて、コンテンツの情報の表示制御を行うコンテンツ情報表示制御部を有することを特徴とするコンテンツ表示装置であっても良い。
【００２０】
また、上記のいずれか１に記載のコンテンツ詳細情報管理装置を備えたことを特徴とするコンテンツ視聴装置であっても良い。
【００２１】
本発明の他の観点によれば、コンテンツネットワークにおけるコンテンツのコンテンツ詳細情報を管理するコンテンツ詳細情報管理方法であって、前記コンテンツ詳細情報と、取得した前記コンテンツ詳細情報のバージョン情報及びコンテンツ詳細情報の取得状況を含むＥＩＴバージョン情報と、を取得するコンテンツ情報取得ステップと、前記コンテンツ情報取得ステップが取得した前記コンテンツ詳細情報と前記ＥＩＴバージョン情報とを第１の記憶部に記憶するステップと、前記コンテンツ情報取得ステップが取得した前記コンテンツ詳細情報と前記ＥＩＴバージョン情報とを第１の記憶部に記憶するステップと、前記第１の記憶部に記憶させて生成した前記ＥＩＴバージョン情報と前記コンテンツ詳細情報とを、インターフェイス部を介して装置と接続されたサーバの第２の記憶部にも前記第１の記憶部の前記ＥＩＴバージョン情報と対応させて記憶させる処理を行うコンテンツ詳細情報管理ステップと、を有することを特徴とするコンテンツ詳細情報管理方法が提供される。
【００２２】
本発明は、上記に記載のコンテンツ詳細情報管理方法をコンピュータに実行させるためのプログラムであっても良く、当該プログラムを記録するコンピュータ読み取り可能な記録媒体であっても良い。プログラムは、インターネットなどの伝送媒体によって取得されるものでも良い。
【発明の効果】
【００２３】
本発明によれば、コンテンツの詳細情報を外部サーバに記憶させ、装置本体では、その取得状況のみを記憶しておき、必要なタイミングで必要な分だけ外部サーバから装置内に取得することにより、コンテンツの詳細情報を効率良く管理することが可能となる。例えば、この詳細情報を利用して、番組検索などに利用することができる。また、不揮発性メモリの記憶領域を無駄にせずに、効率的に利用することができるという利点がある。
【図面の簡単な説明】
【００２４】
【図１】番組情報と番組詳細情報の構成例を示す図である。
【図２】拡張形式イベント記述子の項目名を示す図である。
【図３】一般的なデジタルテレビジョン受信装置における、短形式イベント記述子のフラッシュメモリへの保存の様子を示す概念図である。
【図４】本発明の実施の形態によるデジタルテレビジョン受信装置における、拡張形式イベント記述子のメモリへの保存の様子を示す概念図である。
【図５】ＥＩＴバージョンマトリックスの構成要素であって一度に取得できる最小単位のＥＩＴの構成例を示す図である。
【図６】図５と同様の１固まりの情報であるが、深夜の番組などで、時間的に継続していない途中で放送が無い場合の例を示す図である。
【図７】本実施の形態による番組情報管理技術の特徴の１つである、ＥＩＴバージョンマトリックス（対照表）の一構成例を示す図である。
【図８】全ＥＩＴバージョンマトリクスの構成例を示す図である。
【図９】本発明の実施の形態によるコンテンツ管理装置を含むコンテンツ視聴装置の一例として示すデジタル放送受信装置の一構成例を示す図である。
【図１０】図１０（ａ）、（ｂ）は、サーバへの番組詳細情報の初期保存処理の一例を示すフローチャート図である。
【図１１Ａ】番組詳細情報のサーバへの追加処理の流れを示すフローチャート図であり、視聴中のサービスのＥＩＴバージョンマトリックス情報を取得する場合の例を示す図である。
【図１１Ｂ】図１１Ａに続き、番組詳細情報のサーバへの追加処理の流れを示すフローチャート図であり、視聴中のサービスのＥＩＴバージョンマトリックス情報を取得する場合の例を示す図である。
【図１２Ａ】番組詳細情報のサーバへの追加処理の流れを示すフローチャート図であり、視聴中以外のサービスのＥＩＴバージョンマトリックス情報を取得する場合の例である。
【図１２Ｂ】図１２Ａに続き、番組詳細情報のサーバへの追加処理の流れを示すフローチャート図であり、視聴中以外のサービスのＥＩＴバージョンマトリックス情報を取得する場合の例である。
【図１３】本発明の第２の実施の形態によるコンテンツ検索技術における処理の流れを示すフローチャート図である。
【発明を実施するための形態】
【００２５】
以下に、本発明の実施の形態によるコンテンツ管理技術について説明する前に、コンテンツ情報の例としてデジタル放送受信装置における、番組情報と番組詳細情報とについて説明を行う。
【００２６】
図１、図２は、番組情報と番組詳細情報との構成例を示す図である。図１に示すように、番組情報２は、簡単な番組の情報を含むものであり、番組のタイトル１とともに、短形式イベント記述子５により記述されている。その他、入力情報７は、コンテンツの信号の形態に関する情報である。
【００２７】
さらに詳細な番組情報は、符号１１、符号１５などに示されるように表示されている。番組詳細情報１１は、サブタイトル、番組内容（あらすじ）、出演者などの各種の番組情報の詳細を含む。さらに、音楽の情報、脚本、演出、プロデューサ、制作者などの情報１５が記述されており、これらは、拡張形式イベント記述子１７と呼ばれている。拡張形式イベント記述子１７は、図２に示すように、放送開始当初の予約語として、「おしらせ」、「番組内容」、「出演者」、「原作・脚本」、「監督・演出」、「音楽」、「制作」などの項目が記述される。発明者は、これらの番組詳細情報を利用してより高度な番組検索などをより便利に利用することができることに想到した。
【００２８】
デジタル放送の規格によれば、地上デジタル放送（地デジ）の場合には、番組名は、短形式イベント記述子であって、全角４０文字以下かつ９６バイト以下で記述される。また、番組記述は、短形式イベント記述子であって、全角８０文字以下かつ１９２バイト以下で、項目名は、拡張形式イベント記述子であって、全角８文字以下かつ１６バイト以下、項目記述は、拡張形式イベント記述子であって、１つの記述子あたり２２０バイト以下とし、１つの項目名に対して最大２つの記述子を配置でき、あわせ全角２００文字以下とすることが規定されている。
【００２９】
また、ＢＳ／広帯域ＣＳの場合には、番組名は、短形式イベント記述子であって、全角４０文字以下かつ８０バイト以下、番組記述は、短形式イベント記述子であって、全角８０文字以下かつ１６０バイト以下、項目名は、拡張形式イベント記述子であって、全角８文字以下かつ１６バイト以下、項目記述は、拡張形式イベント記述子であって、１つの記述子あたり全角１００文字以下かつ２００バイト以下とし、１つの項目名に対して最大２つの記述子を配置できる。また、拡張形式イベント記述子は、１番組当たり最大１６個配置できるため、最大：全角１００文字×１６＝１６００文字である。このように、拡張形式イベント記述子はより多くの情報を含むことから、情報量が多くなることがわかる。
【００３０】
また、拡張形式記述子に必要なメモリ量について概算すると、以下のようになる。
【００３１】
まず、標準的に、３時間当たり８番組であるすると、８日分では最大で、
１６００[文字]×２[バイトコード]×８[番組]＝２５，６００ [byte]となる。また、２４[時間]÷３[時間]×８[日]×２５，６００[byte]＝１，６３８，４００[byte]であるため、地デジ（８ｃｈ）、ＢＳ（１２ｃｈ）、ＣＳ（６５ｃｈ）、ＩＰＴＶ（９１ｃｈ）全部で１７６ｃｈあるとすると、１，６３８，４００[byte]×１７６[ch]＝２８８，３５８，４００ [byte]、すなわち、約２９０[Mbyte]と膨大なデータ量になる。
【００３２】
ＡＲＩＢにおいて標準的に想定しているデジタルＴＶサービス（地デジ）のＥＩＴ [schedule extended]の標準的な見積もり量を参照(ARIB TR-B14 3.9版 第二分冊 4-362)すると、１ＴＳあたり８日分で９４２，５９２ [byte]であり、同様に、地デジ・ＢＳ・ＣＳ・ＩＰＴＶ全部で１７６chであるとすると、９４２，５９２[byte]×１７６[ch]＝１６５，８９６，１９２ [byte]、すなわち約１６６[Mbyte]となる。
【００３３】
一方、デジタル放送受信装置において想定されている短形式イベント記述子用のフラッシュメモリの容量としては、５．５[Mbyte]程度を見込んでいるため、実際のバードウェアの約３０倍の記憶容量が必要となる。
【００３４】
次に、短形式イベント記述子、拡張形式イベント記述子も、各ネットワーク毎の再送周期について説明する。
【００３５】
まず、地デジの場合について説明する。地デジでは、ＰＳＩおよび共通運用ＳＩで伝送すると、Ｈ−ＥＩＴ（固定受信用の番組の名称、放送日時・内容など番組に関する情報）、[p/f] （Ｐｒｅｓｅｎｔ（現在）／ｆｏｌｌｏｗｉｎｇ（次）の番組）の短形式イベント記述子、拡張形式イベント記述子の再送周期は１−３[s]である。
【００３６】
共通ＳＩのうち、短形式イベント記述子（デジタルＴＶサービス）のＨ−ＥＩＴ[ｓｃｈｅｄｕｌｅ ｂａｓｉｃの再送周期は、６０−１８０[s]である。
【００３７】
また、個別運用ＳＩで伝送する場合には、Ｈ−ＥＩＴ[p/f:1-3[s]] 短形式イベント記述子、拡張形式イベント記述子、Ｈ−ＥＩＴ[ｓｃｈｅｄｕｌｅ ｂａｓｉｃ:６０−１８０[s]] 短形式イベント記述子(デジタルＴＶサービス)、Ｈ−ＥＩＴ[ｓｃｈｅｄｕｌｅ ｅｘｔｅｎｄｅｄ:６０−１８０[s]] 拡張形式イベント記述子、である。
【００３８】
また、ＢＳ／広帯域ＣＳの場合において、ＰＳＩおよび全局ＳＩで伝送する場合には、
ＥＩＴ[ｐ／ｆ ａｃｔｕａｌ:１−３[s]][ｐ／ｆ ｏｔｈｅｒ:５−２０[s]] 短形式イベント記述子、ＥＩＴ[ｓｃｈｅｄｕｌｅ ａｃｔｕａｌ ｂａｓｉｃ:６０−３６０[s]][ｓｃｈｅｄｕｌｅ ｏｔｈｅｒ ｂａｓｉｃ:６０−３６０[s]] 短形式イベント記述子であり、各局ＳＩで伝送すると、ＥＩＴ[ｐ／ｆ ａｃｔｕａｌ:１−３[s]][ｐ／ｆ ｏｔｈｅｒ:５−２０[s]] 拡張形式イベント記述子、ＥＩＴ[ｓｃｈｅｄｕｌｅｂａｓｉｃ:６０−３６０[s]]短形式イベント記述子、ＥＩＴ[ｓｃｈｅｄｕｌｅｅｘｔｅｎｄｅｄ:６０−３６０[s]]拡張形式イベント記述子、ＬＤＴ (ＣＳのみ) 拡張形式イベント記述子[６０−３６０[s]]である。
【００３９】
従って、現在または次の番組より後の欲しい拡張形式イベント記述子を取得するには、同チャンネルに選局を行った上で、ＢＳでは、最大で３６０[s]×２(周期)=７２０[s]、すなわち、１２分を要する。また、地デジでは、最大で１８０[s]×２（周期）＝３６０[s]、すなわち、６分を要する。
【００４０】
仮に放送局が最短の再送周期で送ってくれた場合であっても、ＢＳ・地デジとも、最短で６０[s]×２(周期)=１２０[s]、すなわち、２分を要する。（標準的な再送周期では１８０×２(周期)=３６０[s]、すなわち６分を要する。）
【００４１】
従って、全てのチャンネル分の詳細情報を取得するためには、ＢＳでは、最大で７２０[s]×１２(チャンネル)＝８６４０[s]、すなわち１４４分を要する。一方、地デジ(東京)では、最大で３６０[s]×８(チャンネル)=２８８０[s]、すなわち４８分を要する。
【００４２】
従って、最短でも、１２０[s]×１２(チャンネル)＝１４４０[s]、すなわち２４分を要する。但し、この計算は、あくまで放送局が最短の再送周期で送ってくれた場合であり、より長時間を要する可能性が高い。
【００４３】
このように、地デジ、ＢＳで、全チャンネル分の詳細番組情報を全て取得するためには、実際上、かなり長い時間を必要とすることになる。尚、上記において、actualとは、自己のＴＳ（視聴中のチャンネル）であり、otherとは他のＴＳ（視聴中でないチャンネル）であり、scheduleとは、スケジュール情報（ｐ／ｆ）を含む以降の全ての番組情報である。
【００４４】
尚、詳細情報は、必ずしも全てのイベントに対して記載されるわけではない。更にＨ−ＥＩＴ[schedule extended]またはＥＩＴ[schedule extended]の再送周期が長いため、十分な応答性を確保できるものではない。全ブロードキャスタが提供する詳細情報を全て受信しようとすると、ほぼ全てのＴＳを受信しなければならないため、少なくとも選局中ＴＳの個別運用ＥＩＴまたは各局ＥＩＴは速やかに蓄積することが望ましい。但し、ＴＳによってはＨ−ＥＩＴ[schedule extended] またはＥＩＴ[schedule extended]に対して拡張周期グループを運用する場合があり、その場合はある程度の再送周期で伝送される。
【００４５】
イベント毎に詳細情報が存在するかどうかは、Ｈ−ＥＩＴ[schedule extended] またはＥＩＴ[schedule extended]を取得しない限り把握できないが、Ｈ−ＥＩＴ[schedule extended] またはＥＩＴ[schedule extended]自身が運用されているかどうかや運用している場合、どの程度の割合で運用されているかは、ＢＩＴ第２記述子ループ中のＳＩ伝送パラメータ記述子に記載される。詳細は、PSI/SI運用規定13.2.2章に記載されている。伝送の割合に関しては、例えばデータ量の見積もりや、取得動作を起こすかどうかの判断には使えるが、不要だと判断すればあえて利用する必要はない。
【００４６】
図３は、一般的なデジタルテレビジョン受信装置における、短形式イベント記述子のフラッシュメモリへの保存の様子を示す概念図である。図３に示すように、地デジ、ＢＳ、ＣＳ、ＩＰＴＶの全てのネットワークに対し、公平に番組情報（短形式イベント記述子）をフラッシュメモリに保存していることがわかる（符号２１ａから２１ｄまで）。
【００４７】
従って、上記の説明からもわかるように、全てのネットワークにおける番組情報に加えて番組詳細情報も取得し、フラッシュメモリに格納するとなると、フラッシュメモリの占有容量が大きくなる上に、取得に要する時間も長くなるという問題がある。
【００４８】
そこで、本発明の実施の形態によるデジタルテレビジョン受信装置では、番組情報の管理（保存）処理に関して、以下のような工夫を行っている。
【００４９】
図４は、図３に対応する図であり、後述する構成を持つ本発明の実施の形態によるデジタルテレビジョン受信装置における、拡張形式イベント記述子の保存の様子を示す概念図である。図４に示すように、地デジ、ＢＳ、ＣＳ、インターネットを介して映像を配信するＩＰＴＶ（Internet Protocol Television）などの全てのネットワークの番組詳細情報を、装置とネットワーク（オープンネットワーク、次世代ネットワークやＬＡＮでも良い。）ＮＴ経由で接続される外部サーバなどのサーバ２５内に格納している様子が示される。この図では、外部サーバの大きな記憶容量を利用して、全てのコンテンツネットワークの番組詳細情報２１を外部サーバ２５内に保持している。そして、ネットワーク経由で、適宜、デジタル放送テレビジョン受信装置内に必要に応じて利用する仕組みになっている。尚、サーバは、記録再生装置内蔵テレビのＨＤＤであっても良く、或いは、装置からアクセスできるメーカの運用するサーバであっても良い。いずれにしても、番組情報とは異なり、装置内のフラッシュメモリ内に全てを記憶しない点が重要である。
【００５０】
図５は、後述するＥＩＴバージョンマトリックスの構成要素であって一度に取得できる最小単位のＥＩＴの構成例を示す図である。図５に示すように、最小単位は、３時間毎に固まった１固まりの情報３１になっている。この１固まりの情報３１には、ＥＩＴ（Ｖｅｒ．０ｘ１Ａで示される５ビットのインデックス（２次元）が対応付けされている。図５に示す１固まりの情報３１は、例えば、０．５時間の時間帯毎の３つの情報３１ａから３１ｆまでになっており、それぞれの情報には、サブタイトルＸ１〜Ｘ６までのぞれぞれと、１６ビットの異なるイベントＩＤとが記述されている。続きの番組であれば、イベントＩＤが同じになっていることでわかるようになっている。尚、サブタイトルが異なれば、イベントＩＤも異なるが、ここでは、その点を図には反映させていない。
【００５１】
図６は、図５と同様の１固まりの情報３１であるが、例えば、深夜の番組などで、時間的に継続していない途中で放送が無い場合の例を示す図である。図６に示すように、途中の放送（１：００〜２：３０分）が無い場合でも、情報自体が無いことは、１固まりの情報を取得した時点でわかるようになっている。尚、１固まりの定義は、任意である。
【００５２】
また、同じ番組の詳細情報であっても、１週間先の番組として最初に記述されても、途中で（例えば当日）情報が更新されることもありうる。情報が更新されたことは、図５、６に示すような、ＥＩＴ (Event Information Table)のバージョン番号（version_number）が更新されたか否かを見ることによって判別することができる。
【００５３】
図７は、本実施の形態による番組情報管理技術の特徴の１つである、ＥＩＴバージョンマトリックス（対照表）５１の一構成例を示す図である。このＥＩＴバージョンマトリックスは、ネットワークＩＤとサービスＩＤとの組毎に、ＥＩＴのバージョン情報と番組詳細情報が取得済みか否かの情報とを、放送時間帯と日時との２軸で画定された２次元平面上にマトリックス状に記載したものである。
【００５４】
図７は、地デジ（ネットワークＩＤ：０ｘ７ＦＥ０）、０１１ｃｈ（サービスＩＤ：０ｘ０４００）のＥＩＴバージョンマトリクス５１の例である。横軸は時間帯５５であり、縦軸は現在日時（１日目）から起算した８日目までの日５３である。縦軸５３と横軸５５とにより画定される２次元平面に多数の３時間毎の１固まりの情報５７が設けられている。この１固まりの情報５７は、ＥＩＴのバージョン番号５７ａと、番組詳細情報を取得済みであるか否かの情報５７ｂ（取得済み）又は５７ｃ（未取得）の情報と、を有している。このＥＩＴのバージョンマトリックス５１により、ある日のある時間帯の１固まりの情報が取得済みであるか否かを符号５７ｂ・５７ｃの記述により知ることが出来る。また、現在時間もポインタ６１により表示されていると便利である。例えば地デジの受信中に、番組詳細情報を含む情報をサーバ２５から取得して、ＥＩＴバージョンマトリックス５１を埋めていくことで、どの日のどの時間帯の１固まりの情報を取得済みであるかを知ることが出来る。このＥＩＴバージョンマトリクス５１は、テレビとサーバとの最小単位の共有情報ともいうべきものである。もちろん、このＥＩＴバージョンマトリクス５１には、番組詳細情報が含まれず、あくまで、その情報がサーバにあるか否かの情報のみが存在するのが好ましい。
【００５５】
図８は、全ＥＩＴバージョンマトリクスの構成例を示す図である。図８に示すように、全ＥＩＴバージョンマトリクス５０は、チャンネル軸（地デジ５１−１、ＢＳ５１−２、ＣＳ５１−３、…ＩＰＴＶ５１−ｎなど）をもつ３次元的な構成を有している。この全ＥＩＴバージョンマトリクス５０により、全てのコンテンツネットワークについて、テレビとサーバとが最小単位の共有情報を有することになる。
【００５６】
次に、必要なメモリ（ＲＡＭ）について説明する。必要なメモリ領域としては、通常の視聴に不足が無い分の番組情報と、メモリ（ＲＡＭ）に展開可能な分の幾つかの番組詳細情報と、８日分のＥＩＴマトリクス（バージョン）を保存できるだけの領域があれば良い。
例えば、ＥＩＴマトリクス１個当たりＥＩＴのバージョン１[byte]と、状態管理用（取得済み／未取得／取得要求）用に１[byte]で、計２[byte]を使うと仮定すると、必要な記憶領域の容量は、１チャンネル当たり：２４[時間]÷３[時間]×８[日]×２[byte]＝１２８[byte]である。
【００５７】
また、地デジ（８ｃｈ）、ＢＳ（１２ｃｈ）、ＣＳ（６５ｃｈ）、ＩＰＴＶ（９１ｃｈ）あるとすると、８＋１２＋６５＋９１＝１７６[ｃｈ]分であり、従って、１２８[byte]×１７６[ｃｈ]＝２２５２８[byte]=約２３[Ｋbyte]の記憶容量があれば良いことになる。従って、番組詳細情報自体を持たないため、ＥＩＴバージョンマトリックスに要する記憶容量はきわめて少なくて良い。
【００５８】
図９は、本発明の実施の形態によるコンテンツ管理装置を含むコンテンツ視聴装置の一例として示すデジタル放送受信装置の一構成例を示す図である。図９に示すように、デジタル放送受信装置Ａは、アンテナ１０１から受信した放送波の受信処理を行うフロントエンド１０３と、受信した信号を、映像・音声とデータとに分けるデマルチプレクサ１０５と、映像・音声のデコードを行う映像・音声デコード部１０７と、スピーカなどの音声出力部１０９と、映像と種々のデータ等を合成する画面合成部１１１と、合成された画面表示を行う液晶ディスプレイなどの表示部１１３と、高速のＲＡＭなどからなるメモリ部１２３と、フラッシュメモリからなる記憶部１２５と、全体を制御する制御部（ＣＰＵ）１２１と、外部とのインターフェイス部１３１と、を有している。コンテンツ情報は、アンテナ１０１からフロントエンド１０３と、デマルチプレクサ１０５と、介して取得することができる（コンテンツ情報取得部を形成する）。さらに、デマルチプレクサ１０５により取得したＳＩ情報などに含まれる番組情報（番組詳細情報を含む）をデコードする番組情報デコード部１１５と、番組情報に基づいて、電子番組表（ＥＰＧ）を作成する電子番組表データ生成部１１７と、リモコン信号を受光するリモコン受光部１２７と、外部サーバ２５などとネットワークＮＴを介して機器を接続するための外部とのインターフェイス部１３１と、を有している。記憶部１２５には、以下において説明する番組情報の管理に関するフローチャートで示す処理を制御部１２１に実行させるためのプログラムが格納されている。このプログラムにより、コンテンツ情報を管理するコンテンツ情報管理部１２１ａを形成することができる。さらに、後述するように、装置内部（ハードディスクなど）又は外部に存在するコンテンツを検索するコンテンツ検索部１２１ｂが設けられていても良い。
【００５９】
また、インターフェイス部１３１は、ネットワークＮＴを介してサーバ２５と接続されている。サーバ２５は、番組詳細情報を格納する番組詳細情報格納部２５ａを有している。
【００６０】
また、コンテンツ管理部１２１ａは、図７，８に示すＥＩＴバージョンマトリックスを作成し、メモリ部（ＲＡＭ）１２３に保存する。
【００６１】
以下に、プログラム処理について説明する。まず、本発明の第１の実施の形態によるコンテンツ情報管理技術について説明する。
【００６２】
図１０（ａ）、（ｂ）は、サーバ２５への番組詳細情報の初期保存処理の一例を示すフローチャート図である。図１０に示すように、まず、ステップＳ１において、自動的に又はユーザ操作により処理が開始されると（ＳＴＲＡＴ）、ステップＳ２において、ＲＡＭ内のＥＩＴバージョンマトリックス（ｍ，ｎ）を初期化する。ｍ、ｎは、日にちと時間帯である。次いで、ステップＳ３において、視聴中のネットワーク（例えば地デジ）の拡張形式イベント記述子を含むＥＩＴのネットワークＩＤとサービスＩＤとを取得し、ＲＡＭ内に保存する。ネットワークとしては地デジ以外から処理を開始するようにしても良い。ステップＳ４において、上記ＥＩＴのイベントＩＤと同じイベントＩＤを持つ番組詳細情報を取得し、ＲＡＭ内に保存する。これにより、図７のＥＩＴバージョンマトリクスの１つのマス目５７内の情報を取得できる。ここで、ＲＡＭであれば、比較的大容量であるから、番組詳細情報を一時的に保存するのに適している。次いで、ステップＳ５において、図７のマトリクスの１つのマス目５７内の全てのイベントの番組詳細情報を取得したか否かを判定し、ＮＯであれば、ステップＳ４に戻り、ＹＥＳであれば、ステップＳ６に進む。ステップＳ６においては、ＥＩＴマトリクス(ｍ，ｎ)に、取得したＥＩＴのバージョンを書き込み、ＥＩＴ取得済みフラグを立ててＲＡＭ内に保存する。これにより、図５の１固まりの情報が保存される。上記の処理で、未取得分のみ情報を取得することができる。
【００６３】
次いで、ステップＳ７において、インターフェイス部１３１を介してネットワークＮＴ上のサーバ２５に接続する。ステップＳ８において、サーバに接続出来たか否かを判定する。ＮＯの場合には、ステップＳ３に戻り、ＹＥＳの場合には、ステップＳ９に進む。ステップＳ９においては、機器個体ＩＤ、すなわち、テレビを一意に識別するＩＤ（機体のシリアル番号など）をサーバに通知する。ステップＳ１０において、テレビの設置されている地域設定（地域コード）をサーバ２５に通知する。これにより、サーバ２５は、接続されているテレビがどのテレビであり、どの地域に設置されているかを知ることが出来る。例えば、サーバが装置メーカ等の運用するサーバであれば、そのテレビがサービスとなるテレビであるかなどをチェックすることも可能である。また、地デジなどの場合には、地域コードが異なると、チャネル構成が異なるため、地域コードを取得する必要がある。
【００６４】
ステップＳ１１において、テレビのＲＡＭ１２３に保存したネットワークＩＤとサービスＩＤと、をサーバ２５にも登録する。この処理により、ＥＩＴバージョンマトリックス５１の１マス５７内の情報（ＥＩＴバージョンＩＤ、番組詳細情報、取得済みか否か）を埋めることができる。
【００６５】
次いで、ステップＳ１２において、ＲＡＭ１２３に保存したイベントＩＤと同じイベントＩＤを持つ番組の番組詳細情報をサーバ２５に登録する。この処理により、図７のＥＩＴバージョンマトリクスの１つのマス目５７内の情報が登録される。次いで、ステップＳ１３において、１つのマス目内の全てのイベントの番組詳細情報をサーバ２５に通知したか否かを判定する。ＮＯであれば、ステップＳ１２に戻り、ＹＥＳであれば、ステップＳ１４に進み、図７に示すようなＥＩＴマトリクス(ｍ，ｎ)を、上記のネットワークＩＤおよびサービスＩＤに関連付けてサーバ２５に登録し、ステップＳ１５においてサーバと装置との接続を切り、サーバへの初期保存処理を終了する。これにより、１つのＥＩＴバージョンマトリックスがサーバ２５に格納される。
【００６６】
図１１Ａ、図１１Ｂは、番組詳細情報のサーバへの追加処理の流れを示すフローチャート図であり、視聴中のサービスのＥＩＴバージョンマトリックス情報を取得する場合の例を示す図である。まずこの処理を開始すると（ステップＳ２１：ＳＴＡＲＴ）、ステップＳ２２において、装置をネットワーク上のサーバ２５に接続を試みる。ステップＳ２３で、サーバ２５への接続を確認すると（ＹＥＳ）、ステップＳ２４において、サーバ２５から、現在時刻以降の全サービスのＥＩＴマトリクス(ｍ，ｎ)を取得し、保存していた古いデータを消去する。ステップＳ２５において、視聴中のネットワークおよびサービスからＥＩＴマトリクス(ｍ，ｎ)上で未取得の拡張形式イベント記述子を取得可能か否かについて判定する（拡張形式イベント記述子の取得判定部）。ＮＯであれば、ステップＳ３０に進み、ＹＥＳであれば、ステップＳ２６に進む。ステップＳ２６においては、未取得の拡張形式イベント記述子を含むＥＩＴを取得しネットワークＩＤとサービスＩＤとを、装置のＲＡＭ１２３に保存する。ステップＳ２７においては、上記ＥＩＴのイベントＩＤと同イベントの番組詳細情報とをＲＡＭ１２３に保存する。この際、フラッシュメモリ１２５には保存しない。次いで、ステップＳ２８において、図７のマトリクスの１つのマス目５７内の全てのイベントのイベントＩＤと同イベントの番組詳細情報をＲＡＭ１２３に保存したか否かを判定する。ＮＯであれば、ステップＳ２７に戻り、ＲＡＭ１２３への保存処理を継続する。ＹＥＳであれば、ステップＳ２９に進み、取得したＥＩＴのバージョンをＥＩＴマトリクス(ｍ，ｎ)に書き込み、ＥＩＴ取得済みフラグを立ててＲＡＭ１２３に保存する。次いで、ステップＳ３０において、ＥＩＴマトリクス(ｍ，ｎ)上で、放送波中のＥＩＴと格納されているＥＩＴバージョンマトリックスとを比較することで、取得済みの拡張形式イベント記述子を含むＥＩＴのバージョンに変更が生じたか否かを判定する。
【００６７】
次いで、ステップＳ３１において、上記ＥＩＴのイベントＩＤと同イベントの番組詳細情報とを再取得し、再取得した情報をＲＡＭ１２３に保存する。ステップＳ３２において、図７のマトリクスの１つのマス目５７内の全てのイベントのイベントＩＤと同イベントの番組詳細情報をＲＡＭ１２３に保存したか否かを判定する。ＮＯの場合には、ステップＳ３１に戻り、全てのイベントについてイベントＩＤと同イベントの番組詳細情報をＲＡＭ１２３に保存するまで処理を継続する。ＹＥＳの場合には、ステップＳ３３に進み、ＥＩＴマトリクス(ｍ，ｎ)に、取得したＥＩＴのバージョンを書き込み、ＥＩＴ取得済みフラグを立ててＲＡＭ１２３に保存する。
【００６８】
次いで、ステップＳ３４において、ＥＩＴマトリクス(ｍ，ｎ)に変更が生じているか否かを判定する。ＮＯの場合にはステップＳ４１に進み、ＹＥＳの場合にはステップＳ３５に進む。ステップＳ３５では、装置の機器個体ＩＤをサーバ２５に通知する。次いで、ステップＳ３６に進み、装置が設置されている地域設定（地域コード）をサーバ２５に通知する。次いで、ステップＳ３７において、ＲＡＭ１２３に保存したネットワークＩＤとサービスＩＤとをサーバ２５にも登録する。ステップＳ３８において、ＲＡＭ１２３に保存したイベントＩＤと同イベントの番組詳細情報をサーバ２５に登録する。ステップＳ３９において、図７のマトリクスの１つのマス目５７内の全てのイベントのイベントＩＤと同イベントの番組詳細情報をサーバ２５に通知したか否かを判定する。ＮＯの場合には、ステップＳ３８に戻り、全てのイベントの番組詳細情報をサーバ２５に通知するまで処理を継続する。ＹＥＳの場合には、ステップＳ４０に進み、更新したＥＩＴマトリクス(ｍ，ｎ)を、上記ネットワークＩＤおよびサービスＩＤに関連付けてサーバ２５に登録する。次いで、ステップＳ４１に進み（ステップＳ３４でＮＯの場合も）、サーバと装置との接続を切り、ステップＳ４２で処理を終了する。このようにして、視聴中のサービスの番組情報をサーバに追加し、更新したＥＩＴバージョンマトリックスの情報（ＥＩＴバージョンマトリックス（ｍ，ｎ））を、ネットワークＩＤ、サービスＩＤに関連付けしてサーバに登録することができる。これにより、ＲＡＭ１２３に保存したサービスＩＤとイベントＩＤと関連付けした番組詳細情報とＥＩＴバージョンマトリックスをサーバから取得可能になる。
【００６９】
図１２Ａ、図１２Ｂは、番組詳細情報のサーバへの追加処理の流れを示すフローチャート図であり、視聴中以外のサービスのＥＩＴバージョンマトリックス情報を取得する場合の例である。まずこの処理を開始すると（ステップＳ５１：ＳＴＡＲＴ）、ユーザ操作又は更新情報の検知などにより、ステップＳ５２において、装置を、ネットワーク上のサーバ２５に接続する。次いで、ステップＳ５３において、サーバに接続できたか否かを検出し、ＮＯであれば、ステップＳ５２に戻り接続処理を例えば所定の回数だけ継続する。ＹＥＳであれば、サーバ２５に接続できたので、次いで、ステップＳ５４において、サーバ２５から現在時刻以降の全サービスのＥＩＴマトリクス(ｍ，ｎ)を取得し、現在時刻以前の古いデータを消去する。ステップＳ５５において、視聴中では無いサービス又は視聴中のサービス以外にＥＩＴマトリクス(ｍ，ｎ)上で未取得の拡張形式イベント記述子を取得することが可能か否かを判定する（拡張形式イベント記述子の取得判定部）。例えば、サービスを視聴中で、チューナを利用している場合に、視聴等を行っていない別のチューナがあれば、ＹＥＳと判定され、余りのチューナがなければＮＯと判定される。ここでＮＯであれば、ステップＳ５７に進み、視聴が終了しチューナが空くまで待機し、ステップＳ５８において、視聴が終了したか否かを監視する。視聴が終了すると（ＹＥＳ）、ステップＳ５５においてＹＥＳの場合と同様に、ステップＳ５６に進み、未取得の拡張形式イベント記述子を含むＥＩＴを取得しネットワークＩＤとサービスＩＤとを装置のＲＡＭ１２３に保存する。
【００７０】
次に、ステップＳ５９において、上記ＥＩＴのイベントＩＤと同イベントの番組詳細情報をＲＡＭ１２３内に保存する。ステップＳ６０において、図７のマトリクスの１つのマス目５７内の全てのイベントの番組詳細情報をＲＡＭ１２３内に保存したか否かを判定する。ＮＯの場合には、ステップＳ５９に戻り、次のＥＩＴのイベントＩＤと同イベントの番組詳細情報をＲＡＭ１２３内に保存していく。ＹＥＳの場合には、ステップＳ６１に進み、ＥＩＴマトリクス(ｍ，ｎ)に、取得したＥＩＴのバージョンを書き込み、ＥＩＴ取得済みフラグを立ててＲＡＭ１２３内に保存する。
【００７１】
次に、ステップＳ６２において、ＥＩＴマトリクス(ｍ，ｎ)上で、取得済みの拡張形式イベント記述子を含むＥＩＴのバージョンに変更が生じたか否かを判定する。ＮＯであれば、ステップＳ６６に進み、ＹＥＳであれば、ステップＳ６３に進む。ステップＳ６３において、上記ＥＩＴのイベントＩＤと同イベントの番組詳細情報を再取得しＲＡＭ１２３内に保存する。ステップＳ６４において、図７のマトリクスの１つのマス目５７内の全てのイベントの番組詳細情報を保存したかを判定し、ＮＯであればステップＳ６３に戻り、１つのマス目内の全てのイベントの番組詳細情報を保存すると（ＹＥＳ）ステップＳ６５に進み、取得したＥＩＴのバージョンをＥＩＴマトリクス(ｍ，ｎ)に書き込み、ＥＩＴ取得済みフラグを立ててＲＡＭ１２３内に保存する。ステップＳ６６に進むと、ＥＩＴマトリクス(ｍ，ｎ)に変更が生じているか否かを判定する。ＮＯの場合にはステップＳ７３に進み、ＹＥＳの場合にはステップＳ６７に進む。ステップＳ６７においては、機器個体ＩＤをサーバ２５に通知する。次いで、ステップＳ６８において、地域設定（地域コード）をサーバに通知する。これにより、装置及びその設置地域をユニークに特定することができる。次に、ステップＳ６９において、ＲＡＭ１２３に保存したネットワークＩＤとサービスＩＤとをサーバ２５に登録し、ステップＳ７０において、ＲＡＭ１２３に保存したイベントＩＤと同イベントの番組詳細情報とをサーバ２５に登録する。ステップＳ７１において、図７のマトリクスの１つのマス目５７内の全てのイベントの番組詳細情報をサーバ２５に通知したか否かを判定し、ＮＯの場合には、ステップＳ７０に戻る。ＹＥＳの場合には、ステップＳ７２に進み、上記ネットワークＩＤおよびサービスＩＤに関連付けて、更新したＥＩＴマトリクス(ｍ，ｎ)をサーバ２５に登録する。次いで、ステップＳ６５でＮＯの場合と同様に、ステップＳ７３に進み、装置とサーバとの接続を切断し、ステップＳ７４で処理を終了する。以上の処理により、視聴中以外のサービスにおいて、ＥＩＴバージョンマトリックスの情報を取得することができるため、このような場合でも、追加の番組情報、番組詳細情報を取得することができる。
【００７２】
次に、本発明の第１の実施の形態によるコンテンツ情報管理技術を利用したコンテンツの検索技術について説明する。図１３（ａ）、（ｂ）は、本発明の第２の実施の形態によるコンテンツ検索技術における処理の流れを示すフローチャート図である。ここでは、地デジを対象にした例について説明するが、全ネットワーク（例えば地デジ・ＢＳ・ＣＳ・ＩＰＴＶ）を対象にしても良い。すなわち、全サービス（例えば１０１ｃｈ〜２２２ｃｈ）を対象にしても良いことは言うまでもない。前提として、上記コンテンツ詳細情報の管理が行われているものとする。
【００７３】
まず、処理が開始されると（ステップＳ８１：ＳＴＡＲＴ）、ステップＳ８２において、検索キーワードと検索対象とするネットワーク（例えばコンテンツネットワークとして地デジの範囲内）とサービス（１０１ｃｈ）と検索日時（２００９年１０月１０日など）および検索範囲（時間帯１２：００〜１５：００）を指定（決定）する。ステップＳ８３において、ネットワーク上のサーバに接続を試みる。ステップＳ８４において、ネットワーク上のサーバに接続出来たか否かを判定し、ＮＯであれば、ステップＳ８３で、ある回数、再接続を試みる。ＹＥＳであれば、ステップＳ８５で、機器個体ＩＤをサーバ２５に通知する。次いで、ステップＳ８６で、地域設定（地域コード）をサーバ２５に通知する。これにより、装置の設置場所と装置の機種をユニークに識別することができる。ステップＳ８７において、装置側からの入力などにより、検索キーワードと検索対象のネットワークＩＤとサービスＩＤと日時および範囲をサーバ２５に通知する。ステップＳ８８において、検索キーワードに該当する（全部一致又は一部一致などでヒットする）イベントＩＤと同イベントの番組詳細情報とをサーバ２５から取得する。ステップＳ８９において、全ての情報をサーバ２５から取得したか否かを判定し、ＮＯであれば、ステップＳ８８に戻り、情報の取得を継続する。ＹＥＳであれば、ステップＳ９０において、検索キーワードに該当するイベントの番組詳細情報をＴＶ画面など装置の表示部に表示させることができる。ステップＳ９１で、ネットワーク上のサーバとの接続を切断すると、処理が終了する（ステップＳ９２）。
【００７４】
上記の検索処理においては、番組詳細情報も検索対象とすることで、より精度の良い番組検索を実行することができる。尚、検索など、サーバ上の番組詳細情報が必要な場合は通常、装置が起動中であるため図１の場合に相当し、既にＥＩＴマトリクスは装置側で取得済みであるため、検索日時および範囲がＥＩＴマトリクスの取得済みの範囲に該当する場合にのみネットワークに接続して検索を行うようにしても良い。該当しない場合には、番組詳細情報に基づく検索はできないからである。番組情報のみによる検索と、番組詳細情報を加えた詳細検索を、切り替えて実行できるようにしても良い。
【００７５】
また、装置とネットワーク接続されるサーバを例にして説明したが、ネットワーク接続は、有線、無線を問わない。また、サーバの位置を限定するものではなく、また、分散配置されたサーバであっても良い。
【００７６】
尚、ＴＶなどの装置が、全ＥＩＴマトリクスを取得する際には、取得済みの情報、未取得の情報を保存する領域に対し、サーバ側で未取得ＥＩＴの取得優先順位を付けるようにしてもよい。例えば、上記の再送周期の説明において、再送周期は３日目までが短いことを考慮して、全ＥＩＴバージョンマトリックスを早く完成させるために、ＥＩＴマトリクスにおける情報取得の速度を考慮して、未取得ＥＩＴの取得優先順位を付けても良い。
【００７７】
さらに、本発明の実施の形態によるコンテンツ（情報）管理技術を利用したコンテンツ表示技術について説明する。図９の番組表データ生成部１１７において、番組表に番組情報のみならず詳細番組情報を生成し、番組表データに保持させると便利である。このような場合にも、利用するネットワークコンテンツの詳細番組情報をサーバに持たせておく管理を行うことで、サーバから番組詳細情報も読み出すことで電子番組表などを作成する場合などのコンテンツ表示において、より詳細な情報を表示させることができるという利点がある。
【００７８】
上記の実施の形態において、添付図面に図示されている構成及び明細書での説明等については、これらに限定されるものではなく、本発明の効果を発揮する範囲内で適宜変更することが可能である。その他、本発明の目的の範囲を逸脱しない限りにおいて適宜変更して実施することが可能である。例えば、本実施の形態では、デジタル放送受信装置を例にして説明したが、その他、デジタル放送を受信可能なレコーダ装置、携帯端末などにも利用可能である。特に、テレビ機能付き携帯端末装置では、メモリの容量が少なくなるため、本発明による効果が大きい。
【００７９】
また、本実施の形態で説明した機能を実現するためのプログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行することにより各部の処理を行ってもよい。尚、ここでいう「コンピュータシステム」とは、ＯＳや周辺機器等のハードウェアを含むものとする。
【００８０】
また、「コンピュータシステム」は、ＷＷＷシステムを利用している場合であれば、ホームページ提供環境（あるいは表示環境）も含むものとする。
【００８１】
また、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ＲＯＭ、ＣＤ−ＲＯＭ等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置のことをいう。さらに「コンピュータ読み取り可能な記録媒体」とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムを送信する場合の通信線のように、短時間の間、動的にプログラムを保持するもの、その場合のサーバやクライアントとなるコンピュータシステム内部の揮発性メモリのように、一定時間プログラムを保持しているものも含むものとする。また前記プログラムは、前述した機能の一部を実現するためのものであっても良く、さらに前述した機能をコンピュータシステムにすでに記録されているプログラムとの組み合わせで実現できるものであっても良い。
【産業上の利用可能性】
【００８２】
本発明は、コンテンツ受信装置のコンテンツ情報管理に利用可能である。
【符号の説明】
【００８３】
Ａ…デジタル放送受信装置、２５…サーバ、２５ａ…番組詳細情報格納部（第２の記憶部）、１０１…アンテナ、１０３…フロントエンド、１０５…デマルチプレクサ、１０７…映像・音声デコード部、１０９…音声出力部、１１１…画面合成部、１１３…表示部、１１５…番組情報デコード部、１１７…電子番組表データ生成部、１２１…制御部（ＣＰＵ）、１２１ａ…コンテンツ詳細情報管理部、１２１ｂ…コンテンツ検索部、１２３…メモリ部（第１の記憶部、ＲＡＭ）、１２５…記憶部（フラッシュメモリ）、１２７…リモコン受光部、１３１…インターフェイス部。
【特許請求の範囲】
【請求項１】
コンテンツネットワークにおけるコンテンツのコンテンツ詳細情報を管理するコンテンツ詳細情報管理装置であって、
前記コンテンツ詳細情報と、取得した前記コンテンツ詳細情報のバージョン情報及びコンテンツ詳細情報の取得状況を含むＥＩＴバージョン情報と、を取得するコンテンツ情報取得部と、
前記コンテンツ情報取得部が取得した前記コンテンツ詳細情報と前記ＥＩＴバージョン情報とを記憶する第１の記憶部と、
前記第１の記憶部に記憶させて生成した前記ＥＩＴバージョン情報と前記コンテンツ詳細情報とを、インターフェイス部を介して装置と接続されたサーバの第２の記憶部にも前記第１の記憶部の前記ＥＩＴバージョン情報と対応させて記憶させる処理を行うコンテンツ詳細情報管理部と、を有することを特徴とするコンテンツ詳細情報管理装置。
【請求項２】
コンテンツネットワークにおけるコンテンツのコンテンツ詳細情報を管理するコンテンツ詳細情報管理装置であって、
前記コンテンツ詳細情報と、取得した前記コンテンツ詳細情報のバージョン情報及びコンテンツ詳細情報の取得状況を含むＥＩＴバージョン情報と、を取得するコンテンツ情報取得部と、
前記コンテンツ情報取得部が取得した前記コンテンツ詳細情報と前記ＥＩＴバージョン情報とを記憶する第１の記憶部と、
前記コンテンツ情報取得部が取得した前記コンテンツ詳細情報を順次記憶する第２の記憶部を有するサーバと接続するためのインターフェイス部と、
前記第１の記憶部に記憶させて生成した前記ＥＩＴバージョン情報と前記コンテンツ詳細情報とを、前記インターフェイス部を介して装置と接続されたサーバの第２の記憶部にも前記第１の記憶部の前記ＥＩＴバージョン情報と対応させて記憶させる処理を行うコンテンツ詳細情報管理部と、を有することを特徴とするコンテンツ詳細情報管理装置。
【請求項３】
前記コンテンツ詳細情報管理部は、
前記ＥＩＴバージョン情報の一単位を複数集めて生成したＥＩＴバージョンマトリックスを生成し、前記第１の記憶部に記憶させることを特徴とする請求項１又は２に記載のコンテンツ詳細情報管理装置。
【請求項４】
前記ＥＩＴバージョンマトリックスにおける前記一単位は、放送時間軸と放送日軸とにより画定されることを特徴とする請求項３に記載のコンテンツ詳細情報管理装置。
【請求項５】
前記コンンツ詳細情報管理部は、
複数のコンテンツネットワークについて、それぞれ、前記ＥＩＴバージョン情報を有し、チャンネル軸に沿って全ＥＩＴマトリックスを作成することを特徴とする請求項１から３までのいずれか１項に記載のコンテンツ詳細情報管理装置。
【請求項６】
全ＥＩＴマトリクスを取得する際に、取得済みの情報、未取得の情報を保存する領域に対し、サーバ側で未取得ＥＩＴの取得優先順位を付けることを特徴とする請求項５に記載のコンテンツ詳細情報管理装置。
【請求項７】
前記ＥＩＴマトリクスにおける情報取得の速度を考慮して、未取得ＥＩＴの取得優先順位を付けることを特徴とする請求項６に記載のコンテンツ詳細情報管理装置。
【請求項８】
前記ＥＩＴバージョン情報の前記バージョン情報に基づいて、前記コンテンツ詳細情報の更新の有無を判定することを特徴とする請求項１から７までのいずれか１項に記載のコンテンツ詳細情報管理装置。
【請求項９】
前記コンテンツ詳細情報は、拡張形式イベント記述子により記載されていることを特徴とする請求項１から８までのいずれか１項に記載のコンテンツ詳細情報管理装置。
【請求項１０】
請求項１から９までのいずれか１項に記載のコンテンツ詳細情報管理装置と、
前記サーバに記憶されている前記コンテンツ詳細情報に基づいて、コンテンツの検索を行うコンテンツ検索部と、を有することを特徴とするコンテンツ検索装置。
【請求項１１】
請求項１から９までのいずれか１項に記載のコンテンツ詳細情報管理装置と、
前記サーバに記憶されている前記コンテンツ詳細情報に基づいて、コンテンツの情報の表示制御を行うコンテンツ情報表示制御部を有することを特徴とするコンテンツ表示装置。
【請求項１２】
請求項１から９までのいずれか１項に記載のコンテンツ詳細情報管理装置を備えたことを特徴とするコンテンツ視聴装置。
【請求項１３】
コンテンツネットワークにおけるコンテンツのコンテンツ詳細情報を管理するコンテンツ詳細情報管理方法であって、
前記コンテンツ詳細情報と、取得した前記コンテンツ詳細情報のバージョン情報及びコンテンツ詳細情報の取得状況を含むＥＩＴバージョン情報と、を取得するコンテンツ情報取得ステップと、
前記コンテンツ情報取得ステップが取得した前記コンテンツ詳細情報と前記ＥＩＴバージョン情報とを第１の記憶部に記憶するステップと、
前記第１の記憶部に記憶させて生成した前記ＥＩＴバージョン情報と前記コンテンツ詳細情報とを、インターフェイス部を介して装置と接続されたサーバの第２の記憶部にも前記第１の記憶部の前記ＥＩＴバージョン情報と対応させて記憶させる処理を行うコンテンツ詳細情報管理ステップと、を有することを特徴とするコンテンツ詳細情報管理方法。
【請求項１４】
請求項１３に記載のコンテンツ情報管理方法をコンピュータに実行させるためのプログラム。
【請求項１】
コンテンツネットワークにおけるコンテンツのコンテンツ詳細情報を管理するコンテンツ詳細情報管理装置であって、
前記コンテンツ詳細情報と、取得した前記コンテンツ詳細情報のバージョン情報及びコンテンツ詳細情報の取得状況を含むＥＩＴバージョン情報と、を取得するコンテンツ情報取得部と、
前記コンテンツ情報取得部が取得した前記コンテンツ詳細情報と前記ＥＩＴバージョン情報とを記憶する第１の記憶部と、
前記第１の記憶部に記憶させて生成した前記ＥＩＴバージョン情報と前記コンテンツ詳細情報とを、インターフェイス部を介して装置と接続されたサーバの第２の記憶部にも前記第１の記憶部の前記ＥＩＴバージョン情報と対応させて記憶させる処理を行うコンテンツ詳細情報管理部と、を有することを特徴とするコンテンツ詳細情報管理装置。
【請求項２】
コンテンツネットワークにおけるコンテンツのコンテンツ詳細情報を管理するコンテンツ詳細情報管理装置であって、
前記コンテンツ詳細情報と、取得した前記コンテンツ詳細情報のバージョン情報及びコンテンツ詳細情報の取得状況を含むＥＩＴバージョン情報と、を取得するコンテンツ情報取得部と、
前記コンテンツ情報取得部が取得した前記コンテンツ詳細情報と前記ＥＩＴバージョン情報とを記憶する第１の記憶部と、
前記コンテンツ情報取得部が取得した前記コンテンツ詳細情報を順次記憶する第２の記憶部を有するサーバと接続するためのインターフェイス部と、
前記第１の記憶部に記憶させて生成した前記ＥＩＴバージョン情報と前記コンテンツ詳細情報とを、前記インターフェイス部を介して装置と接続されたサーバの第２の記憶部にも前記第１の記憶部の前記ＥＩＴバージョン情報と対応させて記憶させる処理を行うコンテンツ詳細情報管理部と、を有することを特徴とするコンテンツ詳細情報管理装置。
【請求項３】
前記コンテンツ詳細情報管理部は、
前記ＥＩＴバージョン情報の一単位を複数集めて生成したＥＩＴバージョンマトリックスを生成し、前記第１の記憶部に記憶させることを特徴とする請求項１又は２に記載のコンテンツ詳細情報管理装置。
【請求項４】
前記ＥＩＴバージョンマトリックスにおける前記一単位は、放送時間軸と放送日軸とにより画定されることを特徴とする請求項３に記載のコンテンツ詳細情報管理装置。
【請求項５】
前記コンンツ詳細情報管理部は、
複数のコンテンツネットワークについて、それぞれ、前記ＥＩＴバージョン情報を有し、チャンネル軸に沿って全ＥＩＴマトリックスを作成することを特徴とする請求項１から３までのいずれか１項に記載のコンテンツ詳細情報管理装置。
【請求項６】
全ＥＩＴマトリクスを取得する際に、取得済みの情報、未取得の情報を保存する領域に対し、サーバ側で未取得ＥＩＴの取得優先順位を付けることを特徴とする請求項５に記載のコンテンツ詳細情報管理装置。
【請求項７】
前記ＥＩＴマトリクスにおける情報取得の速度を考慮して、未取得ＥＩＴの取得優先順位を付けることを特徴とする請求項６に記載のコンテンツ詳細情報管理装置。
【請求項８】
前記ＥＩＴバージョン情報の前記バージョン情報に基づいて、前記コンテンツ詳細情報の更新の有無を判定することを特徴とする請求項１から７までのいずれか１項に記載のコンテンツ詳細情報管理装置。
【請求項９】
前記コンテンツ詳細情報は、拡張形式イベント記述子により記載されていることを特徴とする請求項１から８までのいずれか１項に記載のコンテンツ詳細情報管理装置。
【請求項１０】
請求項１から９までのいずれか１項に記載のコンテンツ詳細情報管理装置と、
前記サーバに記憶されている前記コンテンツ詳細情報に基づいて、コンテンツの検索を行うコンテンツ検索部と、を有することを特徴とするコンテンツ検索装置。
【請求項１１】
請求項１から９までのいずれか１項に記載のコンテンツ詳細情報管理装置と、
前記サーバに記憶されている前記コンテンツ詳細情報に基づいて、コンテンツの情報の表示制御を行うコンテンツ情報表示制御部を有することを特徴とするコンテンツ表示装置。
【請求項１２】
請求項１から９までのいずれか１項に記載のコンテンツ詳細情報管理装置を備えたことを特徴とするコンテンツ視聴装置。
【請求項１３】
コンテンツネットワークにおけるコンテンツのコンテンツ詳細情報を管理するコンテンツ詳細情報管理方法であって、
前記コンテンツ詳細情報と、取得した前記コンテンツ詳細情報のバージョン情報及びコンテンツ詳細情報の取得状況を含むＥＩＴバージョン情報と、を取得するコンテンツ情報取得ステップと、
前記コンテンツ情報取得ステップが取得した前記コンテンツ詳細情報と前記ＥＩＴバージョン情報とを第１の記憶部に記憶するステップと、
前記第１の記憶部に記憶させて生成した前記ＥＩＴバージョン情報と前記コンテンツ詳細情報とを、インターフェイス部を介して装置と接続されたサーバの第２の記憶部にも前記第１の記憶部の前記ＥＩＴバージョン情報と対応させて記憶させる処理を行うコンテンツ詳細情報管理ステップと、を有することを特徴とするコンテンツ詳細情報管理方法。
【請求項１４】
請求項１３に記載のコンテンツ情報管理方法をコンピュータに実行させるためのプログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１Ａ】
【図１１Ｂ】
【図１２Ａ】
【図１２Ｂ】
【図１３】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１Ａ】
【図１１Ｂ】
【図１２Ａ】
【図１２Ｂ】
【図１３】
【公開番号】特開２０１１−１３００１０（Ｐ２０１１−１３００１０Ａ）
【公開日】平成２３年６月３０日（２０１１．６．３０）
【国際特許分類】
【出願番号】特願２００９−２８４２１５（Ｐ２００９−２８４２１５）
【出願日】平成２１年１２月１５日（２００９．１２．１５）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．イーサネット
【出願人】（０００００５０４９）シャープ株式会社 (33,933)
【Ｆターム（参考）】
【公開日】平成２３年６月３０日（２０１１．６．３０）
【国際特許分類】
【出願日】平成２１年１２月１５日（２００９．１２．１５）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．イーサネット
【出願人】（０００００５０４９）シャープ株式会社 (33,933)
【Ｆターム（参考）】
[ Back to top ]