知財求人 - 知財ポータルサイト「IP Force」
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2023-09-21
(45)【発行日】2023-09-29
(54)【発明の名称】放送受信装置、放送受信方法及びプログラム
(51)【国際特許分類】
H04N 21/435 20110101AFI20230922BHJP
H04N 21/462 20110101ALI20230922BHJP
H04H 20/24 20080101ALI20230922BHJP
H04H 60/11 20080101ALI20230922BHJP
H04H 60/82 20080101ALI20230922BHJP
H04H 20/28 20080101ALI20230922BHJP
H04H 60/13 20080101ALI20230922BHJP
【ＦＩ】
H04N21/435
H04N21/462
H04H20/24
H04H60/11
H04H60/82
H04H20/28
H04H60/13
【請求項の数】
6
(21)【出願番号】P 2018225766
(22)【出願日】2018-11-30
(65)【公開番号】P2020088824
(43)【公開日】2020-06-04
【審査請求日】2021-10-08
(73)【特許権者】
【識別番号】314012076
【氏名又は名称】パナソニックＩＰマネジメント株式会社
(74)【代理人】
【識別番号】110002000
【氏名又は名称】弁理士法人栄光事務所
(72)【発明者】
【氏名】影山 光宏
【審査官】鈴木 隆夫
(56)【参考文献】
【文献】特開２００７－３２９６４９（ＪＰ，Ａ）
【文献】特開２００４－１３４８４７（ＪＰ，Ａ）
【文献】特開２０１８－１０７６７０（ＪＰ，Ａ）
【文献】特開２０１３－０７４４５７（ＪＰ，Ａ）
【文献】国際公開第２０１０／０４１６２７（ＷＯ，Ａ１）
【文献】特開２００５－０７９９５５（ＪＰ，Ａ）
【文献】特開２００４－０２３１１８（ＪＰ，Ａ）
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｈ０４Ｎ ２１／００－２１／８５８
Ｈ０４Ｎ ５／７６－５／７７５
Ｈ０４Ｎ ５／８０－５／９０７
Ｈ０４Ｎ ５／９１－５／９５６
Ｈ０４Ｈ ２０／００－２０／４６
Ｈ０４Ｈ ２０／５１－２０／８６
Ｈ０４Ｈ ２０／９１－４０／２７
Ｈ０４Ｈ ４０／９０－６０／９８
(57)【特許請求の範囲】
【請求項1】
放送受信装置であって、
第１の放送信号を受信する第１の受信部と、
第２の放送信号を受信する第２の受信部と、
前記第１の受信部により受信された前記第１の放送信号から、前記第１の放送信号により放送される番組を管理するための第１の番組管理情報を取得し、前記第２の受信部により受信された前記第２の放送信号から、前記第２の放送信号により放送される番組を管理するための第２の番組管理情報を取得する取得部と、
前記第１の番組管理情報と前記第２の番組管理情報とのいずれか一方の形式を、前記第１の番組管理情報と前記第２の番組管理情報とのいずれか他方の形式に変換する変換部と、
前記いずれか一方の形式が変換された前記第１の番組管理情報と前記第２の番組管理情報との少なくとも一部を統合して、統合番組管理情報を生成する生成部と、
前記統合番組管理情報を記憶する記憶部と、
前記番組の管理に関する処理を行う番組処理部と、を備え、
前記番組処理部は、
前記第１の放送信号又は前記第２の放送信号により放送される番組の視聴、録画、およびリモート視聴の予約要求を取得し、
予約要求された前記番組の視聴、録画、およびリモート視聴の予約に関する予約情報を前記統合番組管理情報に記憶し、
前記生成部は、前記記憶部に記憶されている前記統合番組管理情報に基づいて統合電子番組表を生成し、
前記第２の放送信号は、ＩＰ放送信号であり、
前記取得部は、前記第２の番組管理情報から、前記第２の放送信号により放送されるチャネルを識別するための第２のチャネル識別情報で識別されるチャネルのＩＰマルチキャスト通信に関するマルチキャスト情報を取得し、
前記生成部は、前記マルチキャスト情報を含む前記統合番組管理情報を生成し、
前記記憶部は、前記放送受信装置のリソースを管理するためのリソース管理情報を記憶し、
前記番組処理部は、前記リソース管理情報に、予約要求された前記番組の視聴、録画、およびリモート視聴の予約に関する第２の予約情報を登録し、
前記リソースは、録画およびリモート視聴に用いられる、番組コンテンツを復号、変換、記録および再生を行うための２つのリソースと、視聴に用いられる、番組コンテンツを復号および再生を行うための１つのリソースと、を有する、
放送受信装置。
【請求項2】
前記第２の予約情報は、前記予約要求に係るリソースの種別と、前記予約要求に係る番組の放送時間と、の情報を含む、請求項１に記載の放送受信装置。
【請求項3】
前記番組処理部は、予約要求された前記番組の前記放送時間において前記リソースが空いているか否かを判定し、
前記リソースが空いている場合、前記リソース管理情報に、前記第２の予約情報を登録する、
請求項２に記載の放送受信装置。
【請求項4】
前記番組処理部は、前記リソースが空いている場合、予約成功を提示部に提示させ、
前記リソースが空いていない場合、予約失敗を前記提示部に提示させる、
請求項３に記載の放送受信装置。
【請求項5】
第１の放送信号を受信するステップと、第２の放送信号を受信するステップと、
受信された前記第１の放送信号から、前記第１の放送信号により放送される番組を管理するための第１の番組管理情報を取得するステップと、
受信された前記第２の放送信号から、前記第２の放送信号により放送される番組を管理するための第２の番組管理情報を取得するステップと、
前記第１の番組管理情報と前記第２の番組管理情報とのいずれか一方の形式を、前記第１の番組管理情報と前記第２の番組管理情報とのいずれか他方の形式に変換するステップと、
前記いずれか一方の形式が変換された前記第１の番組管理情報と前記第２の番組管理情報との少なくとも一部を統合して、統合番組管理情報を生成するステップと、
前記統合番組管理情報を記憶部に記憶するステップと、
前記第１の放送信号又は前記第２の放送信号により放送される番組の視聴、録画、およびリモート視聴の予約要求を取得し、予約要求された前記番組の視聴、録画、およびリモート視聴の予約に関する予約情報を前記統合番組管理情報に記憶するステップと、
を有し、
前記記憶部に記憶されている前記統合番組管理情報に基づいて統合電子番組表を生成し、
前記第２の放送信号は、ＩＰ放送信号であり、
前記第２の番組管理情報から、前記第２の放送信号により放送されるチャネルを識別するための第２のチャネル識別情報で識別されるチャネルのＩＰマルチキャスト通信に関するマルチキャスト情報を取得し、
前記マルチキャスト情報を含む前記統合番組管理情報を生成し、
放送受信装置のリソースを管理するためのリソース管理情報を記憶し、
前記リソース管理情報に、予約要求された前記番組の視聴、録画、およびリモート視聴の予約に関する第２の予約情報を登録し、
前記リソースは、録画およびリモート視聴に用いられる、番組コンテンツを復号、変換、記録および再生を行うための２つのリソースと、視聴に用いられる、番組コンテンツを復号および再生を行うための１つのリソースと、を有する、
放送受信方法。
【請求項6】
請求項５に記載の放送受信方法をコンピュータに実行させるプログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本開示は、放送受信装置及び放送受信方法に関する。
【背景技術】
【0002】
従来、映像出力装置が電子プログラム案内情報を提供する方法が知られている（特許文献１参照）。この方法では、複数の入力ソースからそれぞれ映像出力装置に信号を提供され、複数の入力ソースを識別し、複数の入力ソースそれぞれのＥＰＧ情報を受信し、ＥＰＧ情報を統合して統合されたＥＰＧ情報を生成し、統合されたＥＰＧ情報を出力する。
【先行技術文献】
【特許文献】
【0003】
【文献】特開２０１３－８５２３２号公報
【発明の概要】
【発明が解決しようとする課題】
【0004】
本開示は、複数の放送信号用の番組管理情報の形式が異なっても、番組管理情報を統合して簡単に管理できる放送受信装置及び放送が受信方法を提供する。
【課題を解決するための手段】
【0005】
本開示の一態様は、放送受信装置であって、第１の放送信号を受信する第１の受信部と、第２の放送信号を受信する第２の受信部と、前記第１の受信部により受信された前記第１の放送信号から、前記第１の放送信号により放送される番組を管理するための第１の番組管理情報を取得し、前記第２の受信部により受信された前記第２の放送信号から、前記第２の放送信号により放送される番組を管理するための第２の番組管理情報を取得する取得部と、前記第１の番組管理情報と前記第２の番組管理情報とのいずれか一方の形式を、前記第１の番組管理情報と前記第２の番組管理情報とのいずれか他方の形式に変換する変換部と、前記いずれか一方の形式が変換された前記第１の番組管理情報と前記第２の番組管理情報との少なくとも一部を統合して、統合番組管理情報を生成する生成部と、前記統合番組管理情報を記憶する記憶部と、前記番組の管理に関する処理を行う番組処理部と、を備え、前記番組処理部は、前記第１の放送信号又は前記第２の放送信号により放送される番組の視聴、録画、およびリモート視聴の予約要求を取得し、予約要求された前記番組の視聴、録画、およびリモート視聴の予約に関する予約情報を前記統合番組管理情報に記憶し、前記生成部は、前記記憶部に記憶されている前記統合番組管理情報に基づいて統合電子番組表を生成し、前記第２の放送信号は、ＩＰ放送信号であり、前記取得部は、前記第２の番組管理情報から、前記第２の放送信号により放送されるチャネルを識別するための第２のチャネル識別情報で識別されるチャネルのＩＰマルチキャスト通信に関するマルチキャスト情報を取得し、前記生成部は、前記マルチキャスト情報を含む前記統合番組管理情報を生成し、前記記憶部は、前記放送受信装置のリソースを管理するためのリソース管理情報を記憶し、前記番組処理部は、前記リソース管理情報に、予約要求された前記番組の視聴、録画、およびリモート視聴の予約に関する第２の予約情報を登録し、前記リソースは、録画およびリモート視聴に用いられる、番組コンテンツを復号、変換、記録および再生を行うための２つのリソースと、視聴に用いられる、番組コンテンツを復号および再生を行うための１つのリソースと、を有する、放送受信装置である。
【0006】
本開示の一態様は、第１の放送信号を受信するステップと、第２の放送信号を受信するステップと、受信された前記第１の放送信号から、前記第１の放送信号により放送される番組を管理するための第１の番組管理情報を取得するステップと、受信された前記第２の放送信号から、前記第２の放送信号により放送される番組を管理するための第２の番組管理情報を取得するステップと、前記第１の番組管理情報と前記第２の番組管理情報とのいずれか一方の形式を、前記第１の番組管理情報と前記第２の番組管理情報とのいずれか他方の形式に変換するステップと、前記いずれか一方の形式が変換された前記第１の番組管理情報と前記第２の番組管理情報との少なくとも一部を統合して、統合番組管理情報を生成するステップと、前記統合番組管理情報を記憶部に記憶するステップと、前記第１の放送信号又は前記第２の放送信号により放送される番組の視聴、録画、およびリモート視聴の予約要求を取得し、予約要求された前記番組の視聴、録画、およびリモート視聴の予約に関する予約情報を前記統合番組管理情報に記憶するステップと、を有し、前記記憶部に記憶されている前記統合番組管理情報に基づいて統合電子番組表を生成し、前記第２の放送信号は、ＩＰ放送信号であり、前記第２の番組管理情報から、前記第２の放送信号により放送されるチャネルを識別するための第２のチャネル識別情報で識別されるチャネルのＩＰマルチキャスト通信に関するマルチキャスト情報を取得し、前記マルチキャスト情報を含む前記統合番組管理情報を生成し、前記放送受信装置のリソースを管理するためのリソース管理情報を記憶し、前記リソース管理情報に、予約要求された前記番組の視聴、録画、およびリモート視聴の予約に関する第２の予約情報を登録し、前記リソースは、録画およびリモート視聴に用いられる、番組コンテンツを復号、変換、記録および再生を行うための２つのリソースと、視聴に用いられる、番組コンテンツを復号および再生を行うための１つのリソースと、を有する、放送受信方法である。
【発明の効果】
【0007】
本開示によれば、複数の放送信号用の番組管理情報の形式が異なっても、番組管理情報を統合して簡単に管理できる。
【図面の簡単な説明】
【0008】
【図1A】第１の実施形態における放送システムの構成例を示すブロック図
【図1B】受信機の構成例を示すブロック図
【図2】番組情報管理テーブルの一例を示す図
【図3】チャネル管理情報の一例を示す図
【図4】番組情報管理表の一例を示す図
【図5】リソース管理情報の一例を示す情報
【図6】番組表情報の一例を示す図
【図7】受信機による番組表収集時の動作例を示すフローチャート
【図8】受信機によるＲＦ放送の番組表収集時の動作例を示すフローチャート
【図9】受信機によるＩＰ放送の番組表収集時の動作例を示すフローチャート
【図10】受信機による予約時のリソース管理の動作例を示すフローチャート
【発明を実施するための形態】
【0009】
以下、適宜図面を参照しながら、実施形態を詳細に説明する。但し、必要以上に詳細な説明は省略する場合がある。例えば、既によく知られた事項の詳細説明や実質的に同一の構成に対する重複説明を省略する場合がある。これは、以下の説明が不必要に冗長になることを避け、当業者の理解を容易にするためである。尚、添付図面及び以下の説明は、当業者が本開示を十分に理解するために提供されるものであり、これらにより特許請求の範囲に記載の主題を限定することは意図されていない。
【0010】
（本開示の一形態を得るに至った経緯）
近年、ＦＴＴＨ(Fiber To The Home)／ＨＦＣ(Hybrid Fiber Coaxial)等の高速ネット回線の普及により、有料放送サービス事業者が高速ネット回線を用いたＩＰ（Internet Protocol）放送サービスの提供が進みつつある。一方、ケーブルテレビ放送を提供するケーブルテレビ放送事業者では、既存の放送波を介した放送（ＲＦ（Radio Frequency）放送とも称する）を実施しており、突然、ＲＦ放送を終了してＩＰ放送に切り替えることは困難である。そのため、ケーブルテレビ放送事業者は、ケーブルテレビ用のＲＦ放送を継続し、ＩＰ放送を並行して実施し、徐々にＩＰ放送のチャネルを増やしながら、ＲＦ放送のチャネル数を減らすことが考えられる。または、例えば地上波放送用のＲＦ放送を残し、他の有料多チャンネル放送（例えばＢＳ放送、高度ＢＳ放送、ケーブルテレビ放送）をＩＰ放送に移行することも考えられる。以上から、ＲＦ放送とＩＰ放送とを並行して運用されることが想定され、放送信号を受信する放送受信装置についても、両方の放送信号（放送形態）に対応した受信機能を有することが求められる。
近年、ＦＴＴＨ(Fiber To The Home)／ＨＦＣ(Hybrid Fiber Coaxial)等の高速ネット回線の普及により、有料放送サービス事業者が高速ネット回線を用いたＩＰ（Internet Protocol）放送サービスの提供が進みつつある。一方、ケーブルテレビ放送を提供するケーブルテレビ放送事業者では、既存の放送波を介した放送（ＲＦ（Radio Frequency）放送とも称する）を実施しており、突然、ＲＦ放送を終了してＩＰ放送に切り替えることは困難である。そのため、ケーブルテレビ放送事業者は、ケーブルテレビ用のＲＦ放送を継続し、ＩＰ放送を並行して実施し、徐々にＩＰ放送のチャネルを増やしながら、ＲＦ放送のチャネル数を減らすことが考えられる。または、例えば地上波放送用のＲＦ放送を残し、他の有料多チャンネル放送（例えばＢＳ放送、高度ＢＳ放送、ケーブルテレビ放送）をＩＰ放送に移行することも考えられる。以上から、ＲＦ放送とＩＰ放送とを並行して運用されることが想定され、放送信号を受信する放送受信装置についても、両方の放送信号（放送形態）に対応した受信機能を有することが求められる。
【0011】
また、ＲＦ放送とＩＰ放送とが平行して運用された場合、ＲＦ放送の放送信号（ＲＦ放送信号）とＩＰ放送の放送信号（ＩＰ放送信号）との双方を受信可能な共用受信機が要望される。共用受信機では、ＲＦ放送信号とＩＰ放送信号とにより放送される番組コンテンツ（単に「番組」とも称する）をいずれの放送信号の番組であるかを区別することなく視聴等できることが望ましい。この場合、ＲＦ放送信号の番組を管理するための番組管理情報とＩＰ放送信号の番組を管理するための番組管理情報とが、区別なく扱えることが望ましい。なお、番組管理情報は、各放送信号によってフォーマットが異なることも想定される。この場合でも、共用受信機において各放送信号の番組を簡単に管理できることが望ましい。
【0012】
以下の実施形態では、複数の放送信号用の番組管理情報の形式が異なっても、番組管理情報を統合して簡単に管理できる放送受信装置及び放送受信方法について説明する。
【0013】
以下の実施形態では、下記の参考非特許文献１～１１の標準規格に準拠する情報を含む。参考特許文献１～４は、デジタル放送に関する文献である。参考特許文献５～７は、ケーブルテレビ放送に関する文献である。参考特許文献８～１１は、ＩＰ放送に関する文献である。
（参考非特許文献１：ARIB STD-B10 「デジタル放送に使用する番組配列情報」、ＡＲＩＢ標準規格、一般社団法人電波産業会）
（参考非特許文献２：ARIB TR-B14 「地上デジタル放送運用規定」、ＡＲＩＢ標準規格、一般社団法人電波産業会）
（参考非特許文献３：ARIB TR-B15 「ＢＳ/広帯域ＣＳデジタル放送運用規定」、ＡＲＩＢ標準規格、一般社団法人電波産業会）
（参考非特許文献４：ARIB TR-B39 「高度広帯域衛星デジタル放送運用規定」、ＡＲＩＢ標準規格、一般社団法人電波産業会）
（参考非特許文献５：JLabs SPEC-003 「デジタル放送リマックス運用仕様（自主放送）」、一般社団法人日本ケーブルラボ）
（参考非特許文献６：JLabs SPEC-004 「デジタル放送リマックス運用仕様（ｉ－ＨＩＴＳ）」、一般社団法人日本ケーブルラボ）
（参考非特許文献７：JLabs SPEC-035 「高度ケーブル自主放送運用仕様（ＡＣＡＳ対応）」、一般社団法人日本ケーブルラボ）
（参考非特許文献８：IPTVFJ STD-0004 「ＩＰ放送仕様」、一般社団法人ＩＰＴＶフォーラム）
（参考非特許文献９：IPTVFJ STD-0005 「地上デジタルテレビジョン放送IP再送信運用規定」、一般社団法人ＩＰＴＶフォーラム）
（参考非特許文献１０：IPTVFJ STD-0009 「BSデジタル放送IP再送信運用規定」、一般社団法人ＩＰＴＶフォーラム）
（参考非特許文献１１：JLabs SPEC-028 「IP放送運用仕様（自主放送）」、一般社団法人日本ケーブルラボ）
（参考非特許文献１：ARIB STD-B10 「デジタル放送に使用する番組配列情報」、ＡＲＩＢ標準規格、一般社団法人電波産業会）
（参考非特許文献２：ARIB TR-B14 「地上デジタル放送運用規定」、ＡＲＩＢ標準規格、一般社団法人電波産業会）
（参考非特許文献３：ARIB TR-B15 「ＢＳ/広帯域ＣＳデジタル放送運用規定」、ＡＲＩＢ標準規格、一般社団法人電波産業会）
（参考非特許文献４：ARIB TR-B39 「高度広帯域衛星デジタル放送運用規定」、ＡＲＩＢ標準規格、一般社団法人電波産業会）
（参考非特許文献５：JLabs SPEC-003 「デジタル放送リマックス運用仕様（自主放送）」、一般社団法人日本ケーブルラボ）
（参考非特許文献６：JLabs SPEC-004 「デジタル放送リマックス運用仕様（ｉ－ＨＩＴＳ）」、一般社団法人日本ケーブルラボ）
（参考非特許文献７：JLabs SPEC-035 「高度ケーブル自主放送運用仕様（ＡＣＡＳ対応）」、一般社団法人日本ケーブルラボ）
（参考非特許文献８：IPTVFJ STD-0004 「ＩＰ放送仕様」、一般社団法人ＩＰＴＶフォーラム）
（参考非特許文献９：IPTVFJ STD-0005 「地上デジタルテレビジョン放送IP再送信運用規定」、一般社団法人ＩＰＴＶフォーラム）
（参考非特許文献１０：IPTVFJ STD-0009 「BSデジタル放送IP再送信運用規定」、一般社団法人ＩＰＴＶフォーラム）
（参考非特許文献１１：JLabs SPEC-028 「IP放送運用仕様（自主放送）」、一般社団法人日本ケーブルラボ）
【0014】
参考非特許文献１～１１の標準規格に準拠する情報を以下に例示列挙する。この情報は、例えば、ＳＩ（Service Information）、ＰＳＩ（Program Specific Information）、ＭＭＴ（MPEG Media Transport）、ＴＬＶ（Type Length Value）、サービスＩＤ（service id）、イベントＩＤ（event id）、オリジナルネットワークＩＤ（original network id）、ストリームＩＤ（stream id）、ストリーム種別（stream type）、ＮＩＴ（Network Information Table）、ＥＩＴ（Event Information Table）、ＥＰＧ（Electronic Program Guide）、ＳＤＴ（Service Description Table）等を含む。
【0015】
（第１の実施形態）
図１Ａは、第１の実施形態における放送システム５の構成例を示すブロック図である。放送システム５は、送信機５０及び受信機１００を備える。送信機５０と受信機１００との間は、ネットワーク７０で接続されてよい。ネットワークは、有線ネットワーク、無線ネットワーク、又は有線ネットワーク及び無線ネットワークの組み合わせで形成されてよい。
図１Ａは、第１の実施形態における放送システム５の構成例を示すブロック図である。放送システム５は、送信機５０及び受信機１００を備える。送信機５０と受信機１００との間は、ネットワーク７０で接続されてよい。ネットワークは、有線ネットワーク、無線ネットワーク、又は有線ネットワーク及び無線ネットワークの組み合わせで形成されてよい。
【0016】
受信機１００は、例えば、各家庭に設置されたセットトップボックスやＴＶ放送受信機やレコーダでよい。受信機１００は、送信機５０によりネットワーク７０を介して送出された番組コンテンツのストリームの放送波（ＲＦ放送信号）やＩＰパケット（ＩＰ放送信号）を受信する。受信機１００がセットトップボックスやレコーダの場合、受信機１００は、例えばＨＤＭＩ（登録商標）（High-Definition Multimedia Interface）を介して、番組コンテンツをＴＶ放送受信機やレコーダに出力してよい。ＴＶ放送受信機は番組コンテンツを再生可能であり、レコーダは番組コンテンツを記録（例えば録画、録音、データ保存）可能である。なお、受信機１００自身が、取得された番組コンテンツを再生又は記録可能でもよい。
【0017】
ネットワーク７０は、インターネットや通信事業者が敷設する閉域網やケーブルテレビ局が敷設する閉域網を含んでよい。ネットワーク７０は、ＦＴＴＨネットワーク又はＨＦＣネットワーク、有線又は無線のＩＰネットワーク、等を含んでよい。
【0018】
送信機５０は、番組コンテンツ、番組コンテンツを管理するための番組管理情報、等を含むストリーム（放送信号の一例）を送信する。放送信号は、ＲＦ放送信号、ＩＰ放送信号、等を含む。ＲＦ放送は、地上波放送、衛星放送及びケーブルテレビ放送を含んでよい。ＩＰ放送は、地上波放送、衛星放送及びケーブルテレビ放送を含んでよい。ＩＰ放送は、ＩＰＴＶのようなＶＯＤ（Video On Demand）／ストリーミング方式の放送式を含んでよい。ＩＰ放送は、配信側がＩＰパケットを用いて自主放送（ＩＰ自主放送）を行うことを含んでよい。また、ＩＰ放送は、配信側が放送波を介して番組コンテンツを取得し、ＩＰパケットを用いて番組コンテンツを再送信（ＩＰ再送信）することを含んでよい。
【0019】
送信機５０は、映像データを含む映像ストリーム、音声データを含む音声ストリーム、データ放送用データを含むデータ放送ストリーム、及びＳＩ（Service Information）／ＰＳＩ（Program Specific Information）データを多重化し、番組コンテンツのストリームを生成してよい。つまり、番組コンテンツは、映像データ、音声データ、データ放送用のデータ、ＳＩ／ＰＳＩデータを含んでよい。ＳＩ／ＰＳＩデータは、ＳＩ及びＰＳＩの少なくとも一方を含み、番組表情報、字幕データ、等を含んでよい。ＳＩ／ＰＳＩデータは、番組管理情報の１つである。ＳＩ／ＰＳＩデータは、番組コンテンツが配信されるストリームとは別のストリームで伝送されてもよい。映像データは、Ｈ．２６５方式（ＨＥＶＣ（High Efficiency Video Coding）方式）、等で符号化されてよい。音声データは、ＭＰＥＧ－２ ＡＡＣ（Advanced Audio Coding）、ＭＰＥＧ－４ ＡＡＣ、ＭＰＥＧ－４ ＡＬＳ（Audio Lossless Coding）等で符号化されていてよい。ここでの多重化方式は、ＭＭＴ（MPEG Media Transport）・ＴＬＶ（Type Length Value）方式、等でよい。送信機５０は、番組コンテンツを含むストリームを送信（配信）する。
【0020】
図１Ｂは、受信機２０の構成例を示すブロック図である。
【0021】
受信機１００は、制御部１０２、チューナ１０４、ＩＰ通信部１０６、デマルチプレクサ１０８、マルチメディア処理部１１０、映像デコーダ１１２、音声デコーダ１１４、トランスコーダ１１６、録画部１１８、レンダリング部１２０、操作部１２２、番組表管理部１２６、番組表制御部１２８、を備える。
【0022】
制御部１０２は、受信機１００の各部を制御し、受信機１００全体を管理する。例えば、制御部１０２は、チューナ１０４及びＩＰ通信部１０６による通信を制御してよい。制御部１０２は、デマルチプレクサ１０８によるストリームの分割を制御してよい。制御部１０２は、番組表管理部１２６による統合番組管理情報の管理、及び番組表制御部１２８による統合番組管理情報の制御を補助してよい。
【0023】
制御部１０２は、操作部１２２からの指示に応じて、チューナ１０４又はＩＰ通信部１０６による選局を制御してよい。この場合、制御部１０２は、指示された選局がチューナ１０４によるストリームの受信かＩＰ通信部１０６によるストリームの受信かを判定してよい。制御部１０２は、ストリームを受信するチューナ１０４又はＩＰ通信部１０６へ受信指示を行い、デマルチプレクサ１０８へデコードの指示を行ってよい。
【0024】
制御部１０２は、番組表管理部１２６からの選局指示を受け、選局してよい。制御部１０２は、番組表管理部１２６からの予約指示を受け、予約指示された番組コンテンツの放送時間に従って、選局してよい。予約指示は、番組コンテンツの視聴予約や録画予約を含んでよい。選局指示や予約指示は、操作部１２２から受けてもよい。
【0025】
制御部１０２は、受信機１００のリソースを管理してよい。リソースは、番組コンテンツの視聴、録画、リモート視聴に用いられるリソースを含んでよい。受信機１００のリソースは、同時デコード可能数、同時トランスコード可能数、同時選局可能数、等で管理されてよい。
【0026】
チューナ１０４は、ＲＦ放送信号のデータを通信する。チューナ１０４は、送信機５０からの番組コンテンツのストリームを受信し、デマルチプレクサ１０８に送る。
【0027】
ＩＰ通信部１０６は、ＩＰパケットを用いてＩＰ放送信号のデータを通信する。ＩＰ通信部１０６は、送信機５０からの番組コンテンツのストリームを受信し、デマルチプレクサ１０８に送る。ＩＰ通信部１０６は、送信機５０からの番組管理情報専用のストリームを受信し、デマルチプレクサ１０８に送る。番組管理情報は、番組コンテンツのストリームに含まれる場合もあるし、番組管理情報専用のストリームに含まれる場合もある。
【0028】
デマルチプレクサ１０８は、チューナ１０４又はＩＰ通信部１０６から送信されたストリームであって、映像、音声、データ放送コンテンツ、ＳＩ／ＰＳＩデータなどが多重化して生成された番組コンテンツのストリームを、複数のストリームに分割する。具体的には、デマルチプレクサ１０８は、番組コンテンツのストリームを、映像ストリーム、音声ストリーム、データ放送ストリーム、及びＳＩ／ＰＳＩデータに分割する。デマルチプレクサ１０８による分割方式は、送信機５０のマルチプレクサの多重化方式に対応する方式でよい。
【0029】
マルチメディア処理部１１０は、デマルチプレクサ１０８からのＳＩ／ＰＳＩデータを取得する。ＳＩ／ＰＳＩデータは、番組管理情報を含み、例えばＥＩＴ（Event Information Table）を含んでよい。また、マルチメディア処理部１１０は、デマルチプレクサ１０８からのデータ放送ストリームを取得し、データ放送ストリームのデータ放送データをデコード（復号化）し、レンダリング部１２０に送る。
【0030】
映像デコーダ１１２は、デマルチプレクサ１０８からの映像ストリームを取得し、映像ストリームの映像データをデコードし、レンダリング部１２０に送る。音声デコーダ１１４は、デマルチプレクサ１０８からの音声ストリームを取得し、音声ストリームの音声データをデコードし、レンダリング部１２０に送る。
【0031】
トランスコーダ１１６は、少なくともデマルチプレクサ１０８からの映像ストリームと音声ストリームを、録画用の映像・音声データにトランスコードして多重化して録画データを生成する。トランスコーダ１１６は、録画データを含む録画コンテンツを録画部１１８へ送る。
【0032】
録画部１１８は、トランスコーダ１１６でトランスコードされた録画データを蓄積する。録画部１１８は、例えば操作部１２２を介して番組コンテンツの録画を指示された場合、指示された番組コンテンツの録画データを蓄積してよい。録画部１１８は、録画データを蓄積する記憶部としての機能を有してよい。記憶部は、記憶媒体を含んでよい。
【0033】
また、例えば操作部１２２を介して番組コンテンツの再生を指示された場合、指示された番組コンテンツの録画データを抽出し、デマルチプレクサ１０８に送る。デマルチプレクサ１０８は、マルチメディア処理部１１０、映像デコーダ１１２、音声デコーダ１１４を介して、及びレンダリング部１２０を介して、録画データを再生する。番組コンテンツの再生は、番組コンテンツの視聴の指示に応じて行われてよい。
【0034】
レンダリング部１２０は、マルチメディア処理部１１０からのデータ放送データ、映像デコーダ１１２からの映像データ、音声デコーダ１１４からの音声データ、の少なくとも１つを取得する。レンダリング部１２０は、データ放送データ、映像データ、音声データの少なくとも１つをレンダリングし、表示部又は音声出力部からレンダリングされたデータを出力する。表示部及び音声出力部は、受信機１００が備えてもよいし、受信機１００とは別に設けられてもよい。表示部は、液晶ディスプレイ、有機ＥＬディスプレイ、その他の表示部でよい。音声出力部は、スピーカ、イヤホン、その他の音声出力部でよい。
【0035】
操作部１２２は、視聴者（ユーザの一例）からの操作を受け付け、操作に基づく操作情報を、制御部１０２、マルチメディア処理部１１０、番組表制御部１２８、等へ送る。操作部１２２は、受信機１００に設けられてもよいし、受信機１００とは別体で設けられてもよい。操作部１２２は、各種ボタン、キー、タッチパネル、マイクロホン、リモコン、等を含んでよい。
【0036】
番組表管理部１２６は、チューナ１０４のチューニングを制御し、ＲＦ放送用の番組管理情報を取得してよい。ＲＦ放送信号用の番組管理情報は、ＲＦ放送用の少なくともＮＩＴとＥＩＴを含む番組表情報を含んでよい。番組表管理部１２６は、ＩＰ通信部１０６のＩＰ放送受信処理を制御し、ＩＰ放送用の番組管理情報を取得してよい。ＩＰ放送用の番組管理情報は、ＩＰ放送用の少なくともＮＩＴとＥＩＴを含む番組表情報を含んでよい。番組表管理部１２６は、ＲＦ放送信号用の番組管理情報とＩＰ放送用の番組管理情報とを基に、統合された番組管理情報（統合番組管理情報）を生成してよい。統合番組管理情報は、チャネル管理情報Ｉ１を含んでよい。番組表管理部１２６は、ＲＦ放送用の番組管理情報とＩＰ放送用の番組管理情報とのいずれか一方の形式を、ＲＦ放送信号用の番組管理情報とＩＰ放送用の番組管理情報とのいずれか他方の形式に変換してよい。番組表管理部１２６は、いずれか一方の形式が変換されたＲＦ放送用の番組管理情報とＩＰ放送用の番組管理情報との少なくとも一部を統合して、統合番組管理情報を生成してよい。
【0037】
番組表管理部１２６は、複数のタイミングで（例えば定期的に）、ＲＦ放送用及びＩＰ放送用の番組表情報を取得し、前回以前に取得された番組表情報と今回に取得された番組表情報とで相違がないか（変更されている点がないか）を判定してよい。番組表管理部１２６は、前回以前に取得された番組表情報において含まれていなかった又は含まれていたが変更されたデータを、新たに取得した番組表情報から取得し、チャネル管理情報Ｉ１や番組情報管理表Ｉ２に追加又は上書きしてよい。
【0038】
番組表管理部１２６は、送信機５０から、ＲＦ放送及びＩＰ放送の個別の番組管理情報を取得してよい。個別の番組管理情報は、ＲＦ放送用の番組表情報Ｉ０（図示せず）とＩＰ放送用の番組表情報Ｉ０（図示せず）を含んでよい。番組表管理部１２６は、ＲＦ放送及びＩＰ放送の番組を管理するための統合番組管理情報を生成し、記憶し、管理する。番組表管理部１２６は、各種データ、情報、テーブル等を記憶する記憶部の機能を有してよい。記憶部は、記憶媒体を含んでよい。統合番組管理情報は、チャネル管理情報Ｉ１、番組情報管理表Ｉ２、リソース管理情報Ｉ４等を含んでよく、その他の情報を含んでよい。チャネル管理情報Ｉ１は、ＮＩＴ又はＳＤＴを基に生成されてよい。番組情報管理表Ｉ２は、ＥＩＴを基に生成されてよい。
【0039】
番組表情報Ｉ０は、放送毎に用意され、つまりＲＦ放送とＩＰ放送とで個別に用意され、例えば各放送信号に含まれて受信機１００が取得する。つまり、番組表情報Ｉ０は、ＲＦ放送用の番組表情報、ＩＰ放送用の番組表情報を含む。チャネル管理情報Ｉ１、番組情報管理表Ｉ２及びリソース管理情報Ｉ４は、各放送（ＲＦ放送、ＩＰ放送）で共用される。チャネル管理情報Ｉ１は、ＲＦ放送及びＩＰ放送で放送されるチャネルやチャネル毎の番組を管理するための情報である。番組情報管理表Ｉ２は、ＲＦ放送及びＩＰ放送で放送される番組を管理するための情報である。番組情報管理表Ｉ２は、チャネル管理情報Ｉ１に含まれてよい。リソース管理情報Ｉ４は、受信機１００が有するリソースを管理するための情報である。
【0040】
番組表制御部１２８は、ＲＦ放送及びＩＰ放送で共用される統合番組管理情報（例えばチャネル管理情報Ｉ１、番組情報管理表Ｉ２）を用いて番組の予約、視聴、録画、リモート視聴を行うための処理を行う。番組表制御部１２８は、例えば、番組表制御部１２８は、統合番組管理情報のデータを使って、図６の統合電子番組表Ｇ１を生成し、レンダリング部１２０を経由して統合電子番組表Ｇ１を図示せぬ画面に表示させる。操作部１２２としてリモコンを用いる場合、制御部１０２の指示に従って、統合電子番組表Ｇ１において所定の項目を選択するためのカーソルやフォーカスの位置の制御を行ってよい。番組表制御部１２８は、番組コンテンツを録画又はリモート視聴する場合、トランスコーダ１１６に録画又はリモート視聴に関する制御を指示してよい。
【0041】
図２は、番組情報管理テーブルＴＢ１の一例を示す図である。番組情報管理テーブルＴＢ１は、番組表管理部１２６により生成されるチャネル管理情報Ｉ１を保持する。チャネル管理情報Ｉ１は、１つ以上の番組情報管理表Ｉ２を有する。番組情報管理表Ｉ２は、各放送ソース（ＲＦ放送、ＩＰ放送）のチャネル毎に用意される番組コンテンツに関する情報でよい。
【0042】
図３は、チャネル管理情報Ｉ１の一例を示す図である。
【0043】
チャネル管理情報Ｉ１は、ストリーム種別、サービスＩＤ、オリジナルネットワークＩＤ，ストリームＩＤ、及び契約情報を含む。チャネル管理情報Ｉ１は、ＩＰ放送用のＩＰマルチキャスト情報を含む。
【0044】
ストリーム種別（stream type）は、チューナ１０４又はＩＰ通信部１０６により受信されたストリームの種別を識別する情報である。ストリーム種別は、ＲＦ放送信号のＴＳ（Transport Stream）であることを示すＴＳ情報（「１」とも示す）、ＩＰ放送信号のＴＬＶ（Type Length Value）であることを示すＴＬＶ情報（「２」とも示す）、ＩＰ放送信号のＴＳであることを示すＩＰ－ＴＳ情報（「３」とも示す）、及びＩＰ放送信号のＴＬＧであることを示すＩＰ－ＴＬＶ情報（「４」とも示す）を含んでよい。
【0045】
サービスＩＤ（Service_id）は、放送サービスを識別する情報であり、チャネルを識別する情報である。オリジナルネットワークＩＤ（Original_network_id）は、ストリームが伝送されるネットワークを識別する情報であり、起源となるネットワークを識別するＩＤである。このネットワークは、例えば、地上波、ＢＳ、高度ＢＳ、ＩＰネットワーク、等を含む。
【0046】
ストリームＩＤ（Stream_id）は、ストリームを識別する情報である。例えば、ストリーム種別＝「２」（ＴＬＶ情報）又は「４」（ＩＰ－ＴＬＶ情報）である場合、ストリームＩＤは、「tlv_stream_id」である。ストリーム種別＝「１」（ＴＳ情報）又は「３」（ＩＰ－ＴＳ情報）である場合、ストリームＩＤは、「ts_stream_id」である。契約情報は、番組コンテンツを視聴するための契約に関する情報である。契約情報は、無料であることを示す無料情報、未契約であることを示す未契約情報、契約済みであることを示す契約済み情報を含んでよい。
【0047】
ＩＰマルチキャスト情報は、ストリーム識別情報が「３」（ＩＰ－ＴＳ情報）又は「４」（ＩＰ－ＴＬＶ情報）の場合、チャネル管理情報Ｉ１に含まれる。ＩＰマルチキャスト情報は、ＩＰバージョン情報、プロトコル情報、グループアドレス情報ソース、アドレス情報、等を含み、その他の情報を含んでもよい。ＩＰバージョン情報は、ＩＰパケットのバージョンを示す情報であり、例えば、ＩＰｖ４（「０」とも示す）であるか、ＩＰｖ６（「１」とも示す）であるか、を示してよい。プロトコル情報は、ＩＰマルチキャストのグループ管理プロトコルの情報であり、例えば、ＩＧＭＰｖ２であるか、ＭＬＤｖ２であるか、を示してよい。ＩＧＭＰ（Internet Group Management Protocol）は、ルータ及びホスト間で使用されるＩＰｖ４のマルチキャストグループ管理プロトコルである。ＭＬＤ（Multicast Listener Discovery）は、ルータ及びホスト間で使用されるＩＰｖ６のマルチキャストグループ管理プロトコルである。グループアドレスは、ＩＰマルチキャストで使用されるグループアドレスである。ソースアドレスは、ＩＰマルチキャストで使用される送信元を示すＩＰアドレスである。
【0048】
図４は、番組情報管理表Ｉ２の一例を示す図である。図４では、サービスＩＤ＝「２７７」である場合の番組情報管理表Ｉ２を示す。サービスＩＤの下位の情報として、番組情報管理表Ｉ２がある。よって、番組情報管理表Ｉ２は、チャネル管理情報Ｉ１に含まれる。番組情報管理表Ｉ２は、１つ以上の番組情報を管理するものである。番組（番組コンテンツ）は、イベントＩＤ（event_id）により識別される。よって、番組情報管理表Ｉ２には、サービスＩＤで識別されるＲＦ放送又はＩＰ放送の、イベントＩＤで識別される番組の情報が含まれる。
【0049】
番組情報管理表Ｉ２は、イベントＩＤ（event_id）、開始時刻情報、継続時間情報、番組名情報、短形式記述情報、予約情報、等を含み、その他の情報を含んでもよい。イベントＩＤは、番組コンテンツを識別する情報である。開始時刻情報は、イベントＩＤで識別される番組コンテンツが放送される開始時刻（例えば日時）に関する情報を示す。継続時間は、イベントＩＤで識別される番組コンテンツの放送が継続する時間（例えば秒）を示す。番組名情報は、イベントＩＤで識別される番組コンテンツの名称（番組名）を示す。短形式記述情報は、例えば短形式イベント記述子であり、番組名と番組内容を定義する情報を含む。予約情報は、イベントＩＤで識別される番組コンテンツの予約に関する情報である。予約情報は、予約されていないことを示す予約無し情報（「０」とも示す）、視聴の予約がされていることを示す視聴予約情報（「１」とも示す）、録画の予約がされていることを示す録画予約情報（「２」とも示す）、及びリモート視聴の予約がされていることを示すリモート視聴予約情報（「３」とも示す）を含んでよい。
【0050】
【0051】
図５では、受信機１００のリソースが３つ存在することを示している。この３つのリソースは、ＤＥＣＯＤＥ、ＤＴＲ（Digital TV Recorder）１、ＤＴＲ２、を含む。ＤＥＣＯＤＥは、番組コンテンツをデコードし、表示部に表示させるためのリソースである。つまり、ＤＥＣＯＤＥは、例えばＴＶ画面で視聴するためのリソースでよい。ＤＴＲ１及びＤＴＲ２は、デコードし、トランスコードし、録画し、再生するためのリソースである。つまり、ＤＴＲ１及びＤＴＲ２は、録画やリモート視聴するためのリソースでよい。ここでは、一例として、ＤＴＲ１を録画用のリソースとし、ＤＴＲ２をリモート視聴用のリソースとする。受信機１００は、ＤＥＣＯＤＥ、ＤＴＲ１及びＤＴＲ２を備えることで、２番組同時録画が可能であり、更に別のチャネルを選局して視聴者に視聴させることが可能である。または、受信機１００は、１番組を録画し、１番組をリモート視聴し、１番組を自宅のテレビで視聴者に視聴させることが可能である。
【0052】
図５では、２０１８年ＡＡ月ＢＢ日において、１１：００～１１：２０に、ＤＴＲ１のリソースが予約されており、録画予約されている。また、１８：００～２０：００に、ＤＥＣＯＤＥのリソースが予約されており、視聴予約されている。また、１９：００～２０：００に、ＤＴＲ１のリソースが予約されており、録画予約されている。また、１９：００～２０：００に、ＤＴＲ２のリソースが予約されており、リモート視聴予約されている。番組情報管理表Ｉ２、リソース管理情報Ｉ４等では、未来の８日間の番組コンテンツが管理できる。よって、番組表管理部１２６は、図５で１日分として例示したリソース管理情報Ｉ４を、８日分管理してよい。１日単位の管理は一例であり、他の時間単位で管理されてよい。また、８日分も一例であり、他の日数分や時間分であってもよい。
【0053】
図６は、番組情報管理表Ｉ２の一例を示す図である。
【0054】
図６では、ＲＦＣＨ（ＲＦ放送のチャネル）とＩＰＣＨ（ＩＰ放送のチャネル）とで放送される番組の情報が並列に表示されることを例示している。例えば、チャネル１０１はＲＦ放送のチャネルであり、チャネル２７６のチャネルはＩＰ放送のチャネルでよい。図６では、各チャネルで放送される番組コンテンツの情報が時系列で記載されている。
【0055】
図６に示す、ＲＦ放送とＩＰ放送とで共用される統合電子番組表Ｇ１は、例えばＥＰＧ形式の番組表でよい。つまり、番組表管理部１２６は、ＲＦ放送用の番組表の形式を採用し、ＲＦ放送用の番組表の形式をそのままにし、ＩＰ放送用の番組表の形式を変換して（ここではＥＰＧ形式に合わせて）、ＲＦ放送用の番組に関する情報とＩＰ放送用の番組に関する情報とを統合して、統合電子番組表Ｇ１を生成してよい。番組表管理部１２６は、ＥＩＴを基に、ＥＰＧ形式の番組表を生成してよい。番組表管理部１２６は、ＲＦ放送用のＥＰＧ形式をそのままにし、ＩＰ放送用のＥＰＧ形式をＲＦ放送用のＥＰＧ形式に変換して、両者を統合してよい。
【0056】
図６では、表示部に表示された統合電子番組表Ｇ１において、番組コンテンツｐ１が操作部１２２により選択されている。選択された番組コンテンツｐ１の詳細情報が、別画面としての詳細画面Ｇ２において表示されている。詳細画面Ｇ２は、番組コンテンツｐ１の詳細情報の他に、録画予約ボタンｂ１、視聴予約ボタンｂ２、リモート視聴予約ｂ３、等が表示されてよい。
【0057】
例えば、制御部１０２は、操作部１２２を介して録画予約ボタンｂ１が選択されたことを検知すると、録画用のリソースを予約し、リソース管理情報Ｉ４、番組情報管理表Ｉ２に録画予約に関する予約情報を登録する。例えば、制御部１０２は、操作部１２２を介して視聴予約ボタンｂ２が選択されたことを検知すると、視聴用のリソースを予約し、リソース管理情報Ｉ４、番組情報管理表Ｉ２に視聴予約に関する予約情報を登録する。例えば、制御部１０２は、操作部１２２を介してリモート視聴予約ボタンｂ３が選択されたことを検知すると、リモート視聴用のリソースを予約し、リソース管理情報Ｉ４、番組情報管理表Ｉ２にリモート視聴予約に関する予約情報を登録する。
【0058】
次に、受信機１００の動作について説明する。
【0059】
図７は、受信機１００の番組表収集時の動作例を示すフローチャートである。図７の処理は、番組表管理部１２６が開始を判断してよい。例えば、番組表管理部１２６は、時刻を計時し、１日１回ｎ時に図７の処理を開始してよいし、他のタイミングで図７の処理を開始してもよい。受信機１００は、ＲＦ放送の番組表情報Ｉ０を収集し、取得する（Ｓ１０１）。受信機１００は、ＩＰ放送の番組表情報Ｉ０を収集し、取得する（Ｓ１０２）。なお、ＲＦ放送とＩＰ放送の番組表情報Ｉ０は、共にＥＩＴに基づく番組表情報でよい。
【0060】
図８は、ＲＦ放送の番組表収集時の動作例を示すフローチャートである。ここでは、ＲＦ放送としてＴＳ形式のストリームを受信することを例示するが、ＴＬＶ形式の場合でも同様である。
【0061】
チューナ１０４は、ＲＦ放送信号のストリームを受信する。番組表管理部１２６は、デマルチプレクサ１０８及びマルチメディア処理部１１０を介して、ストリームからＳＩ／ＰＳＩデータを取得し、ＳＩ／ＰＳＩデータからＮＩＴ（Network Information Table）を取得（例えば抽出）する（Ｓ２０１）。ＮＩＴは、周波数や変調方式等のチャネルの物理的位置や情報が記載されている。ＮＩＴには、サービス情報リストが含まれ、どのようなチャネルが含まれているかを示す情報を含む。ＮＩＴは、サービスＩＤ、ストリームＩＤ、等が含まれてよい。また、番組表管理部１２６は、ＳＩ／ＰＳＩデータに含まれる、チャネル管理情報の生成に必要な情報（例えばストリーム種別情報、オリジナルネットワークＩＤ、契約情報、等）を取得してよい。
【0062】
番組表管理部１２６は、サービス情報リスト分、つまりＮＩＴに含まれる１つ以上のサービスＩＤについて、Ｓ２０３～Ｓ２０９の処理を反復して行い、又は反復して行わせる（Ｓ２０２）。番組表管理部１２６は、全てのサービスＩＤについて反復処理が終了した場合、図８の処理を終了する。
【0063】
番組表管理部１２６は、該当するサービスＩＤがチャネル管理情報Ｉ１に登録されておらず、つまり未登録である場合、このサービスＩＤをチャネル管理情報Ｉ１に追加し、つまり登録する（Ｓ２０３）。この場合、番組表管理部１２６は、取得された他の情報（例えばストリーム種別情報、オリジナルネットワークＩＤ、ストリームＩＤ、契約情報）についても、チャネル管理情報Ｉ１に追加し、登録する。
【0064】
チューナ１０４は、番組表管理部１２６からの指示に従って、このサービスＩＤに対応するＴＳパケットを含むストリームを受信する（Ｓ２０４）。ストリームは、パケット単位（例えばＴＳパケット）のストリームを含む。デマルチプレクサ１０８は、ストリームを分割し、ＴＳパケットを取得する。
【0065】
番組表管理部１２６は、デマルチプレクサ１０８から取得したＴＳパケットから、自サービスの情報であるＥＩＴ情報としてのＥＩＴ－ｓｃｈ（Ａｃｔｕａｌ）（以下、単位「ＥＩＴ」とも称する）を取得する（Ｓ２０５）。ＥＩＴには、イベントＩＤ、その他の番組コンテンツに関する情報が含まれてよい。ＥＩＴには、例えば８日分の番組コンテンツの情報が含まれる。その他の番組コンテンツに関する情報は、番組情報管理表Ｉ２の生成に必要な情報でよく、例えば、開始時刻情報、継続時間情報、番組名情報、短形式記述情報、予約情報、等を含んでよい。
【0066】
番組表管理部１２６は、イベント情報リスト分、つまりＥＩＴに含まれる１つ以上のイベントＩＤについて、Ｓ２０７～Ｓ２０９の処理を反復して行い、又は反復して行わせる（Ｓ２０６）。番組表管理部１２６は、全てのイベントＩＤについて反復処理が終了した場合、Ｓ２０２に進む。
【0067】
番組表管理部１２６は、該当するイベントＩＤが番組情報管理表Ｉ２に記載されているか否か、つまりこのイベントＩＤが管理済みであるか否かを判定する（Ｓ２０７）。
【0068】
イベントＩＤが管理済みである場合、番組表管理部１２６は、このイベントＩＤに対応する予約情報を番組情報管理表Ｉ２から継承して、受信されたＲＦ放送用のＥＩＴの内容を、番組情報管理表Ｉ２の同イベントＩＤの欄に上書き登録する（Ｓ２０８）。これにより、該当するイベントＩＤに対応する情報が番組情報管理表Ｉ２上で更新される。Ｓ２０８の後、Ｓ２０６に進む。
【0069】
イベントＩＤが管理済みでない場合、番組表管理部１２６は、受信されたＲＦ放送用のＥＩＴの内容を、番組情報管理表Ｉ２に新規イベントＩＤに対応する情報として追加登録する（Ｓ２０９）。Ｓ２０９の後、Ｓ２０６に進む。
【0070】
ＥＩＴの情報は、例えば、８日分の番組に関する情報が含まれるので、毎日ＥＩＴ情報を取得する場合、最後の一日分が前日のＥＩＴ情報に含まれていなかった情報となる。よって、基本的に最後の一日分の情報が番組情報管理表Ｉ２に追加されればよい。なお、前日にも取得された変更のない７日分の情報については、番組情報管理表Ｉ２に上書き登録されたり登録が省略されたりしてよいが、前日までに予約情報が登録されている場合には、この予約情報については上書きせずに、登録されている予約情報が、そのまま残される（継承される）。また、受信機１００は、上書き登録する場合には、ＥＩＴに変更箇所が存在する場合でも、この変更を反映して番組情報管理表Ｉ２を生成できる。これらのことは、ＩＰ放送の番組表収集時も同様である。
【0071】
このようなＲＦ放送の番組表収集時の動作例によれば、受信機１００は、ＲＦ放送独自の番組表情報Ｉ０を基に、複数の放送信号に対応した統合番組管理情報（チャネル管理情報Ｉ１、番組情報管理表Ｉ２等）におけるＲＦ放送に関する部分の情報を生成できる。
【0072】
図９は、ＩＰ放送の番組表収集時の動作例を示すフローチャートである。ここでは、ＩＰ放送としてＴＳ形式のストリームを受信することを例示するが、ＴＬＶ形式の場合でも同様である。
【0073】
ＩＰ通信部１０６は、制御部１０２の指示に従って、ＳＩ専用ストリームのマルチキャストに参加するよう、ｊｏｉｎメッセージ（例えばＩＧＭＰ（Internet Group Management Protocol） ｊｏｉｎメッセージ）を送信する（Ｓ３０１）。これにより、受信機１００は、ＳＩ専用ストリームのマルチキャストに参加する。なお、ＳＩ専用ストリームには、ＳＩ／ＰＳＩデータが含まれ、通常の番組コンテンツに含まれる映像データ等が含まれない。
【0074】
ＩＰ通信部１０６は、ＩＰ放送信号のストリームを受信する。番組表管理部１２６は、は、デマルチプレクサ１０８及びマルチメディア処理部１１０を介して、ストリームからＳＩ／ＰＳＩデータを取得し、ＳＩ／ＰＳＩデータからＮＩＴ（Network Information Table）を取得（例えば抽出）する（Ｓ３０２）。ＮＩＴは、周波数や変調方式等のチャネルの物理的位置や情報が記載されている。ＮＩＴには、サービス情報リストが含まれ、どのようなチャネルが含まれているかを示す情報を含む。ＮＩＴは、サービスＩＤ、ストリームＩＤ、ＩＰマルチキャスト情報、等が含まれてよい。また、サービスＩＤに対応するＩＰマルチキャスト情報は、サービスＩＤと該当サービスが配信されるＩＰマルチキャストアドレスのペアが記載された選局制御情報として図示せぬサーバから取得されてもよい。また、番組表管理部１２６は、ＳＩ／ＰＳＩデータに含まれる、チャネル管理情報の生成に必要な情報（例えばストリーム種別情報、契約情報、オリジナルネットワークＩＤ、等）を取得してよい。
【0075】
番組表管理部１２６は、サービス情報リスト分、つまりＮＩＴに含まれる１つ以上のサービスＩＤについて、Ｓ３０４～Ｓ３１０の処理を反復して行い、又は反復して行わせる（Ｓ３０３）。番組表管理部１２６は、全てのサービスＩＤについて反復処理が終了した場合、図９の処理を終了する。
【0076】
番組表管理部１２６は、該当するサービスＩＤがチャネル管理情報Ｉ１に登録されておらず、つまり未登録である場合、このサービスＩＤをチャネル管理情報Ｉ１に追加し、つまり登録する（Ｓ３０４）。この場合、番組表管理部１２６は、取得された他の情報（例えばストリーム種別情報、オリジナルネットワークＩＤ、ストリームＩＤ、契約情報、）についても、チャネル管理情報Ｉ１に追加し、登録する。また、番組表管理部１２６は、ＩＰマルチキャスト情報についても、チャネル管理情報Ｉ１に追加し、登録する（Ｓ３０５）。
【0077】
番組表管理部１２６は、マルチメディア処理部１１０を介して、該当するサービスＩＤに対応するＳＩ専用ストリームから、ＥＩＴを取得する（Ｓ３０６）。ＥＩＴには、イベントＩＤ、その他の番組コンテンツに関する情報が含まれてよい。ＥＩＴには、例えば８日分の番組コンテンツの情報が含まれる。その他の番組コンテンツに関する情報は、番組情報管理表Ｉ２の生成に必要な情報でよく、例えば、開始時刻情報、継続時間情報、番組名情報、短形式記述情報、予約情報、等を含んでよい。
【0078】
番組表管理部１２６は、イベント情報リスト分、つまりＥＩＴに含まれる１つ以上のイベントＩＤについて、Ｓ３０８～Ｓ３１０の処理を反復して行い、又は反復して行わせる（Ｓ３０７）。番組表管理部１２６は、全てのイベントＩＤについて反復処理が終了した場合、Ｓ３０３に進む。
【0079】
番組表管理部１２６は、該当するイベントＩＤが番組情報管理表Ｉ２に記載されているか否か、つまりこのイベントＩＤが管理済みであるか否かを判定する（Ｓ３０８）。
【0080】
イベントＩＤが管理済みである場合、番組表管理部１２６は、このイベントＩＤに対応する予約情報を番組情報管理表Ｉ２から継承して、受信されたＩＰ放送用のＥＩＴの内容を、番組情報管理表Ｉ２の同イベントＩＤの欄に上書き登録する（Ｓ３０９）。これにより、該当するイベントＩＤに対応する情報が番組情報管理表Ｉ２上で更新される。Ｓ３０９の後、Ｓ３０７に進む。
【0081】
イベントＩＤが管理済みでない場合、番組表管理部１２６は、受信されたＩＰ放送用のＥＩＴの内容を、番組情報管理表Ｉ２に新規イベントＩＤに対応する情報として追加登録する（Ｓ３１０）。Ｓ３１０の後、Ｓ３０７に進む。
【0082】
このようなＩＰ放送の番組表収集時の動作例によれば、受信機１００は、ＩＰ放送独自の番組表情報Ｉ０を基に、複数の放送信号に対応した統合番組管理情報（チャネル管理情報Ｉ１、番組情報管理表Ｉ２等）におけるＩＰ放送に関する部分の情報を生成できる。
【0083】
したがって、受信機１００は、ＲＦ放送の番組表収集時の動作とＩＰ放送の番組表収集時の動作とにより、ＲＦ放送とＩＰ放送とで番組管理情報を統合して、共通して利用できる統合電子番組表Ｇ１等の統合番組管理情報を生成できる。視聴者は、統合番組管理情報を利用することで、複数の放送信号（例えばＲＦ放送信号、ＩＰ放送信号）を特別に意識することなく、簡単に統合番組管理情報を利用できる。
【0084】
また、受信機１００は、ＩＰ放送用の番組管理情報を取得するためにＳＩ専用ストリームのマルチキャストに参加することで、複数のストリームを受信するためにマルチキャストのＪｏｉｎメッセージやｌｅａｖｅメッセージを反復して通信することを抑制でき、処理負荷及びネットワーク負荷を低減できる。
【0085】
また、ＲＦ放送の番組表等の番組管理情報とＩＰ放送の番組表等の番組管理情報との表示形式や管理形式が異なる場合でも、１つのチャネル管理情報Ｉ１や番組情報管理表Ｉ２等の統合番組管理情報に集約できる。この場合、Ｆ放送の番組管理情報とＩＰ放送の番組管理情報との少なくとも一方の形式が変換されて、形式が統一されて、統合番組管理情報が生成されてよい。
【0086】
また、番組表管理部１２６は、番組情報管理表Ｉ２を基に統合電子番組表Ｇ１を生成してよい。この場合、番組表管理部１２６は、ＩＰ放送用の番組表に含まれる各情報をＲＦ信号用の番組表に含まれる各情報と統合して表示してよい生成された統合電子番組表Ｇ１は、統合番組管理情報の一例である。これにより、視聴者は、使い慣れたＥＰＧ形式等の統合電子番組表Ｇ１を用いて、つまり形式が統一された統合番組管理情報を用いて、番組の視聴等を指示することができる。
【0087】
図１０は、受信機１００による予約時のリソース管理の動作例を示すフローチャートである。
【0088】
図１０では、番組表制御部１２８が、図６に示した統合電子番組表Ｇ１を表示部に表示させ、視聴者からの操作部１２２としてのリモコンから詳細画面Ｇ２の表示指示を受け付けることを想定する。そして、視聴者が、詳細画面Ｇ２の表示を確認し、リモコンで予約操作を行うことを想定している。なお、図１０の動作時には、ＲＦ放送とＩＰ放送とで共用される番組管理情報（統合番組管理情報）が生成済みである。
【0089】
操作部１２２（例えばリモコン）は、視聴者からの統合電子番組表Ｇ１の表示指示を受け、制御部１０２が、統合電子番組表Ｇ１を表示部に表示させる。操作部１２２は、統合電子番組表Ｇ１に表示された所定の番組コンテンツを選択する操作を受け、つまり視聴者からの詳細画面Ｇ２の表示指示を受け、制御部１０２が、詳細画面Ｇ２を表示部に表示させる。視聴者は、表示部を見て、詳細画面Ｇ２上の録画予約、視聴予約、又はリモート視聴予約を確認する。操作部１２２は、ユーザ入力による予約要求を受け付ける（Ｓ４０１）。番組表制御部１２８は、操作部１２２から予約要求の情報を取得する（Ｓ４０２）。予約要求は、例えば、録画予約要求、視聴予約要求、又はリモート視聴予約要求でよい。
【0090】
番組表制御部１２８は、詳細画面Ｇ２で表示された、つまり統合電子番組表Ｇ１で選択された番組コンテンツに係るサービスＩＤ、イベントＩＤ、放送開始時刻、継続時間の情報を、チャネル管理情報Ｉ１、番組情報管理表Ｉ２、等の統合番組管理情報から取得する（Ｓ４０３）。番組表制御部１２８は、取得された予約要求を参照し、予約要求の種別を判別する（Ｓ４０４）。
【0091】
予約要求の種別が録画予約又はリモート視聴予約の要求であった場合、番組表制御部１２８は、リソース管理情報Ｉ４を参照し、該当する番組コンテンツの放送開始時刻と放送終了時刻との時間で、ＤＴＲ１又はＤＴＲ２のリソースに空きがあるか否かを判定する（Ｓ４０５、Ｓ４０６）。放送終了時刻は、例えば番組表制御部１２８により、放送開始時刻と継続時間とを加算することにより導出されてよい。
【0092】
ＤＴＲ１又はＤＴＲ２のリソースに空きがある場合（Ｓ４０６のＹＥＳ）、番組表制御部１２８は、ＤＴＲ１又はＤＴＲ２に該当する番組コンテンツの録画予約又はリモート視聴予約のためのリソースを予約する（Ｓ４０７）。この場合、番組表制御部１２８は、リソース管理情報Ｉ４に、この録画又はリモート視聴のためのリソース予約に係るリソース予約情報を登録する。この場合、番組表制御部１２８は、番組表管理部１２６に対して番組情報管理表Ｉ２の該当する番組コンテンツの予約情報に、「２」（録画予約）又は「３」（リモート視聴予約）を登録させ、リソース管理情報Ｉ４のＤＴＲ１又はＤＴＲ２の該当時間帯を、予約状態にする。
【0093】
番組表制御部１２８は、録画又はリモート視聴のためのリソース予約に成功したことを示す予約成功情報を、レンダリング部１２０を介して表示部に表示させる（Ｓ４０８）。
【0094】
一方、ＤＴＲ１及びＤＴＲ２のリソースに空きがない場合（Ｓ４０６のＮＯ）、番組表制御部１２８は、録画又はリモート視聴のためのリソース予約に失敗したことを示す予約失敗情報を、レンダリング部１２０を介して表示部に表示させる（Ｓ４０９）。
【0095】
Ｓ４０４において、予約要求の種別が視聴予約の要求であった場合、番組表制御部１２８は、リソース管理情報Ｉ４を参照し、該当する番組コンテンツの放送開始時刻と放送終了時刻との時間で、ＤＥＣＯＤＥのリソースに空きがあるか否かを判定する（Ｓ４１０、Ｓ４１１）。
【0096】
ＤＥＣＯＤＥのリソースに空きがある場合（Ｓ４１１のＹＥＳ）、番組表制御部１２８は、ＤＥＣＯＤＥに該当する番組コンテンツの視聴予約のためのリソースを予約する（Ｓ４１２）。この場合、番組表制御部１２８は、リソース管理情報Ｉ４に、この視聴のためのリソース予約に係るリソース予約情報を登録する。この場合、番組表制御部１２８は、番組情報管理表Ｉ２の該当する番組コンテンツの予約情報に、「１」（視聴予約）を登録させ、リソース管理情報Ｉ４のＤＥＣＯＤＥの該当時間帯を、予約状態にする
【0097】
番組表制御部１２８は、視聴のためのリソース予約に成功したことを示す予約成功情報を、レンダリング部１２０を介して表示部に表示させる（Ｓ４０８）。
【0098】
一方、ＤＥＣＯＤＥのリソースに空きがない場合（Ｓ４１１のＮＯ）、番組表制御部１２８は、視聴のためのリソース予約に失敗したことを示す予約失敗情報を、レンダリング部１２０を介して表示部に表示させる（Ｓ４１３）。
【0099】
このような予約時のリソース管理の動作例によれば、受信機１００は、生成された統合電子番組表等の統合番組管理情報を利用することで、複数の放送信号（例えばＲＦ放送信号、ＩＰ放送信号）を特別に意識することなく、簡単に番組コンテンツの予約、視聴、録画、リモート視聴等を実施できる。
【0100】
このように、本実施形態の受信機１００は、ＩＰ放送とＲＦ放送の共用受信機として動作でき、共用される番組管理情報である統合番組管理情報を用いることで、ＩＰ放送とＲＦ放送とで機能差の無い使用感を視聴者に提供できる。そして、視聴者は、統合電子番組表Ｇ１を確認することで、放送のソース（例えばＲＦ放送、ＩＰ放送）を意識することなく、放送サービスを視聴等できる。また、受信機１００は、ＲＦ放送の番組表情報Ｉ０とＩＰ放送の番組表情報Ｉ０とを別々に取得し、受信機１００内で１つのチャネル管理情報Ｉ１、番組情報管理テーブルＴＢ１で管理できる。また、受信機１００は、統合番組管理情報を用いて、受信機１００内のリソース（例えばストリームの受信能力、デコード能力、番組コンテンツの表示能力、録画能力）を、ＲＦ放送とＩＰ放送とで共用できる。視聴者は、統合電子番組表Ｇ１を用いて視聴予約や録画予約を行う場合に、ＩＰ放送でもＲＦ放送でも齟齬なく、最大限に受信機１００のリソースを活用できる。
【0101】
また、受信機１００は、ＲＦ放送とＩＰ放送とを同じアプリケーション上で動作させてよい。よって、受信機１００は、ＲＦ放送とＩＰ放送とが別々のアプリケーションで起動するためにＩＰ放送の番組表を見るために手間がかかる場合と比較すると、双方の放送信号用の番組表を確認するための手間を低減できる。また、受信機１００は、統合電子番組表Ｇ１を用いることで、ＩＰ放送においてもＲＦ放送と同様の番組表の動作を実現できるとともに、視聴者に対して選局しようとしているチャネルがＲＦ放送かＩＰ放送かを意識させることなく、シームレスに番組切り替えできる。
【0102】
以上、図面を参照しながら各種の実施形態について説明したが、本開示はかかる例に限定されないことは言うまでもない。当業者であれば、特許請求の範囲に記載された範疇内において、各種の変更例または修正例に想到し得ることは明らかであり、それらについても当然に本開示の技術的範囲に属するものと了解される。
【0103】
上記実施形態では、データ放送に関する処理が省略されてもよい。つまり、送信機５０によるデータ放送のデータやデータ放送のストリームに関する処理、受信機１００によるデータ放送のデータやデータ放送のストリームに関する処理が省略されてもよい。
【0104】
上記実施形態では、図１Ｂ等に示した放送システム５の各構成部を専用のハードウェアで構成してもよいし、汎用のハードウェアを用いてソフトウェアにより各構成部の機能を実現してもよい。専用のハードウェアや汎用のハードウェアは、各種のプロセッサを含んでよい。
【0105】
上記実施形態では、プロセッサは、物理的にどのように構成してもよい。また、プログラム可能なプロセッサを用いれば、プログラムの変更により処理内容を変更できるので、プロセッサの設計の自由度を高めることができる。プロセッサは、１つの半導体チップで構成してもよいし、物理的に複数の半導体チップで構成してもよい。複数の半導体チップで構成する場合、第１の実施形態の各制御をそれぞれ別の半導体チップで実現してもよい。この場合、それらの複数の半導体チップで１つのプロセッサを構成すると考えることができる。また、プロセッサは、半導体チップと別の機能を有する部材（コンデンサ等）で構成してもよい。また、プロセッサが有する機能とそれ以外の機能とを実現するように、１つの半導体チップを構成してもよい。
【0106】
以上のように、本実施形態の放送受信装置（例えば受信機１００）は、第１の放送信号（例えばＲＦ放送信号）を受信する第１の受信部（例えばチューナ１０４）と、第２の放送信号（例えばＩＰ放送信号）を受信する第２の受信部（例えばＩＰ通信部１０６）と、を備えてよい。放送受信装置は、第１の受信部により受信された第１の放送信号から、第１の放送信号により放送される番組を管理するための第１の番組管理情報（例えばＲＦ放送用のＳＩ／ＰＳＩデータのうちのチャネルに関するチャネル情報、番組に関する番組情報を構成するデータ）を取得し、第２の受信部により受信された第２の放送信号から、第２の放送信号により放送される番組を管理するための第２の番組管理情報（例えばＩＰ放送用のＳＩ／ＰＳＩデータのうちのチャンネル情報、番組情報を構成するデータ）を取得する取得部（例えば番組表管理部１２６）を備えてよい。放送受信装置は、第１の番組管理情報と第２の番組管理情報とのいずれか一方の形式を、第１の番組管理情報と第２の番組管理情報とのいずれか他方の形式に変換する変換部（例えば番組表管理部１２６）を備えてよい。放送受信装置は、いずれか一方の形式が変換された第１の番組管理情報と第２の番組管理情報との少なくとも一部を統合して、統合番組管理情報（例えばチャネル管理情報Ｉ１、番組情報管理表Ｉ２、リソース管理情報Ｉ４）を生成する生成部（例えば番組表管理部１２６）を備えてよい。
【0107】
これにより、放送受信装置は、複数の放送信号用のそれぞれの番組管理情報を取得し、形式を合わせて、統合番組管理情報を生成できる。よって、放送受信装置は、各放送信号によって番組管理情報のフォーマットが異なる場合でも、各放送信号の番組を簡単に管理できることが望ましい。
【0108】
また、取得部は、第１の番組管理情報から、第１の放送信号により放送されるチャネルを識別するための第１のチャネル識別情報（例えばサービスＩＤ）を取得してよい。取得部は、第１の番組管理情報から、第１のチャネル識別情報で識別される番組を識別するための第１の番組識別情報（例えばイベントＩＤ）を取得してよい。取得部は、第１の番組管理情報から、第１の番組識別情報で識別される番組に関する第１の番組情報（例えばＲＦ放送用の番組表情報Ｉ０）を取得してよい。取得部は、第２の番組管理情報から、第２の放送信号により放送されるチャネルを識別するための第２のチャネル識別情報（例えばサービスＩＤ）を取得してよい。取得部は、第２の番組管理情報から、第２のチャネル識別情報で識別される番組を識別するための第２の番組識別情報（例えばイベントＩＤ）を取得してよい。取得部は、第２の番組管理情報から、第２の番組識別情報で識別される番組に関する第２の番組情報（例えばＩＰ放送用の番組表情報Ｉ０）を取得してよい。生成部は、第１の番組情報及び前記第２の番組情報を含む統合番組管理情報を生成してよい。
【0109】
これにより、放送受信装置は、各放送信号の番組管理情報に含まれる、チャネル識別情報や番組識別情報等の、統合番組管理情報を生成するためのキーとなる情報を取得できる。放送受信装置は、取得されたキーを用いて統合番組管理情報に必要となる情報（例えばチャネル管理情報Ｉ１、番組情報管理表Ｉ２に含まれる情報）を取得して、統合番組管理情報の生成に用いることができる。
【0110】
また、第２の放送信号は、ＩＰ放送信号でよい。取得部は、第２の番組管理情報から、第２のチャネル識別情報で識別されるチャネルのＩＰマルチキャスト通信に関するマルチキャスト情報（例えばＩＰマルチキャスト情報）を取得してよい。生成部は、マルチキャスト情報を含む統合番組管理情報を生成してよい。
【0111】
これにより、放送受信装置は、ＩＰ放送については、ＲＦ放送では用いないマルチキャスト情報も収集し、統合番組管理情報に含めて使用可能にできる。
【0112】
放送受信装置は、統合番組管理情報を記憶する記憶部（例えば番組表管理部１２６）と、番組に関する処理を行う番組処理部（例えば番組表制御部１２８）を備えてよい。番組処理部は、第１の放送信号又は第２の放送信号により放送される番組の視聴、録画、又はリモート視聴の予約要求を取得してよい。番組処理部は、統合番組管理情報に、予約要求された番組の視聴、録画、又はリモート視聴の予約に関する第１の予約情報を登録してよい。
【0113】
これにより、放送受信装置は、ＲＦ放送とＩＰ放送とを区別せずに、予約情報を統合番組管理情報に登録して予約管理できる。
【0114】
記憶部は、前記受信機のリソースを管理するためのリソース管理情報Ｉ４を記憶してよい。リソース管理情報Ｉ４に、予約要求された番組の視聴、録画、又はリモート視聴の予約に関する第２の予約情報を登録してよい。
【0115】
これにより、放送受信装置は、ＲＦ放送とＩＰ放送とを区別せずに、予約情報をリソース管理情報Ｉ４に登録してリソース管理できる。
【0116】
また、第２の予約情報は、予約要求に係るリソースの種別と、予約要求に係る番組の放送時間と、の情報を含んでよい。
【0117】
これにより、放送受信装置は、ＲＦ放送とＩＰ放送との番組が区別なく予約された場合であっても、予約要求に対応するリソースがどのリソースであるかを管理でき、リソースの使用予定時間を管理できる。
【0118】
また、番組処理部は、予約要求された番組の前記放送時間においてリソースが空いているか否かを判定してよい。番組処理部は、リソースが空いている場合、リソース管理情報Ｉ４に、第２の予約情報を登録してよい。
【0119】
これにより、放送受信装置は、ＲＦ放送とＩＰ放送との番組が区別なく予約された場合であっても、各予約が同一リソース且つ同一時間帯で重複することを防止でき、予約に係る放送受信装置の動作を確実に実施できる。
【0120】
また、番組処理部は、リソースが空いている場合、予約成功を提示部（例えば表示部）に提示させてよい。番組処理部は、リソースが空いていない場合、予約失敗を提示部に提示させてよい。
【0121】
これにより、視聴者は、統合番組管理情報を用いて行われた予約要求に係る予約の処理が、問題なく実施されたか否かを、視覚的に容易に判断できる。
【産業上の利用可能性】
【0122】
本開示は、複数の放送信号用の番組管理情報の形式が異なっても、番組管理情報を統合して簡単に管理できる放送受信装置及び放送受信方法等に有用である。
【符号の説明】
【0123】
５ 放送システム
５０ 送信機
７０ ネットワーク
１００ 受信機
１０２ 制御部
１０４ チューナ
１０６ ＩＰ通信部
１０８ デマルチプレクサ
１１０ マルチメディア処理部
１１２ 映像デコーダ
１１４ 音声デコーダ
１１６ トランスコーダ
１１８ 録画部
１２０ レンダリング部
１２２ 操作部
１２６ 番組表管理部
１２８ 番組表制御部
Ｉ１ チャネル管理情報
Ｉ２ 番組情報管理表
Ｉ４ リソース管理情報
Ｇ１ 統合電子番組表
Ｇ２ 詳細画面
ＴＢ１ 番組情報管理テーブル
５０ 送信機
７０ ネットワーク
１００ 受信機
１０２ 制御部
１０４ チューナ
１０６ ＩＰ通信部
１０８ デマルチプレクサ
１１０ マルチメディア処理部
１１２ 映像デコーダ
１１４ 音声デコーダ
１１６ トランスコーダ
１１８ 録画部
１２０ レンダリング部
１２２ 操作部
１２６ 番組表管理部
１２８ 番組表制御部
Ｉ１ チャネル管理情報
Ｉ２ 番組情報管理表
Ｉ４ リソース管理情報
Ｇ１ 統合電子番組表
Ｇ２ 詳細画面
ＴＢ１ 番組情報管理テーブル
【図1A】
【図1B】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】