JP6633809B2 - 送信受信システム及び送信受信方法 - Google Patents

Description

この実施形態は、ハイブリッドキャスト（Hybridcast）の技術仕様に準拠した、デジタル放送向けＡＰＩ（Application Programming Interface：アプリケーション実行環境向けのソフトウエアを開発する際に使用可能な命令や関数の集合）を応用した技術に関する。

ハイブリッドキャストは、ＨＴＭＬ５（Hyper Text Markup Language 5）を使って放送と通信を連携させたシステムであり、多様なサービスを可能としている。ハイブリッドキャストの技術仕様は、ＩＰＴＶフォーラムの技術仕様およびＡＲＩＢ（Association of Radio Industries and Businesses）の規格として、標準化されている。

特開２０１５−２７０８２号公報

「ハイブリッドキャスト技術仕様サービスガイドライン」IPTVFJ DOC-0002 1.6版 2013年4月19日改定、一般社団法人 ＩＰＴＶフォーラム 「放送通信連携システム」IPTVFJ STD-0010 2.1版 2016年3月7日改定、一般社団法人 ＩＰＴＶフォーラム 「ＨＴＭＬ５ブラウザ仕様」IPTVFJ STD-0011 2.2版 2016年3月7日改定、一般社団法人 ＩＰＴＶフォーラム 「ハイブリッドキャスト運用規定」IPTVFJ STD-0013 2.4版 2016年6月22日改定、一般社団法人 ＩＰＴＶフォーラム 「デジタル放送におけるデータ放送符号化方式と伝送方式 標準規格」ARIB STD-B24 6.3版 2016年7月6日改定、一般社団法人 電波産業会 「デジタル放送におけるマルチメディア符号化方式（第２世代） 標準規格」ARIB STD-B62 1.6版 2016年9月29日改定、一般社団法人 電波産業会

上記した規格に基づく送信装置、又は受信装置、又は送受信システムにおいて、例えば視聴予約、録画予約、視聴予約キャンセル、録画予約キャンセルの何れか、又はこれらの組み合わせを実現可能なものが要望されている。

一実施形態によれば、受信装置がデジタル放送に関連するＨＴＭＬ文書に埋め込まれたアプリケーションの関数を用い、ハイブリッドキャスト方式に準拠して、放送番組の録画予約又は録画予約取り消しを行えるように放送波を送信し受信する送信受信システムであって、
送信装置は、
前記ＨＴＭＬ文書には、前記ハイブリッドキャスト方式に準拠するか否かをチェックすることに利用可能な情報を含める手段、
前記関数には、受信側で前記録画予約又は録画予約取り消しを設定するか否かユーザに問合せすることに利用可能な第１の関数を含める手段、
さらに前記関数には、前記受信側で前記録画予約又は録画予約取り消しを設定することに利用可能な第２の関数も含める手段を備え、
前記受信装置は、
前記ハイブリッドキャスト方式に準拠するか否かをチェックすることに利用可能な情報を用いて前記ハイブリッドキャスト方式に準拠するか否かを装置内でチェックする手段、
前記チェック結果が前記ハイブリッドキャスト方式に準拠する場合に前記第１の関数、前記第２の関数を取得することで、
前記録画予約又は録画予約取り消しを設定するか否かユーザに問合せすることに利用可能な前記第１の関数を用いて前記録画予約又は録画予約取り消しを設定するか否か問合せする手段、
前記録画予約又は録画予約取り消しを設定することに利用可能な前記第２の関数を用いて前記録画予約又は録画予約取り消しを設定する手段を備える、
送信受信システムを提供する。

図１は、実施形態が適用されたハイブリッドキャスト仕様の全体システムの構成例を示す図である。 図２は、図１の構成をさらに具体化して示す図である。 図３は、放送局の概略的な構成を示す図である。 図４は、放送波伝送路及びハイブリッドキャスト伝送路におけるにおける主なストリーム及び情報を説明するための説明図である。 図５は、実施形態が適用された受信機の概略的構成例を示す図である。 図６は、実施形態が適用された受信機の要点の一部を概略的に示す構成図である。 図７は、上記ハイブリッドキャスト仕様の受信機をハードウエアと、受信或いは通信機能とアプリケーションの面から概略的に見た説明図である。 図８は、視聴予約、録画予約、予約取消等に関する関数の一例を説明する図である。 図９は、視聴予約関数、録画予約関数、予約取消関数等の引数（event_ref）に関する規定の一例（ＭＰＥＧ２−ＴＳ方式で伝送されるイベントを指定する場合）を説明する図である。 図１０は、視聴予約関数、録画予約関数、予約取消関数等の引数（event_ref）に関する規定の他例（ＭＭＴ方式で伝送されるイベントを指定する場合）を説明する図である。 図１１Ａは、視聴予約、録画予約、予約取消等に関する関数の他例を説明する図である。 図１１Ｂは、図１１Ａの続きを示す図である。 図１２は、ＩＰネットワークへの接続状態確認に関する関数（メソッド）の一例を説明する図である。 図１３は、アプリケーションオブジェクトの取得に関する関数（メソッド）の一例を説明する図である。 図１４Ａは、放送用拡張関数におけるクラスと拡張関数グループ指定の対応関係の一部（ＥＰＧ関連機能等を含む）を説明する図である。 図１４Ｂは、放送用拡張関数におけるクラスと拡張関数グループ指定の対応関係の他部（ＡＩＴコントロールドアプリケーション連携機能等を含む）を説明する図である。 図１５は、受信機が起動するデータ放送に関して、受信機形態とサービス形態との対応関係を例示する図である。 図１６は、ＢＭＬ／ＡＲＩＢ−Ｊ共用受信機におけるデータ放送処理系の起動動作の一例を説明するフローチャートである。 図１７は、放送用拡張関数（ＡＩＴコントロールドアプリケーション連携機能）と指定可能な名前空間との対応関係を例示する図である。 図１８Ａは、一部の拡張関数（getBrowserSupport()）とその引数に指定する文字列との対応関係（その１）を例示する図である。 図１８Ｂは、一部の拡張関数（getBrowserSupport()）とその引数に指定する文字列との対応関係（その２）を例示する図である。 図１８Ｃは、一部の拡張関数（getBrowserSupport()）とその引数に指定する文字列との対応関係（その３）を例示する図である。 図１９は、実施形態で用いられるパーミッションビットマップ（permission_bitmap）がどのように運用されるのかを例示する図である。 図２０Ａは、ビットマップ０、ビットマップ１におけるbit値と機能の割り当てと動作の関係（その１）を例示する図である。 図２０Ｂは、ビットマップ０、ビットマップ１におけるbit値と機能の割り当てと動作の関係（その２）を例示する図である。 図２１は、実施形態で使用できる外部アプリケーション制御記述子のデータ構造を例示する図である。 図２２は、アプリケーションクラスとビット値との対応関係を示すビットマップを例示する図である。 図２３は、放送用拡張関数（ＩＰＴＶ連携機能）と指定可能な名前空間との対応関係を例示する図である。 図２４は、実施形態が適用された送信側の処理の一例を説明するフローチャートである。 図２５Ａは、実施形態が適用された受信側の処理の一例を説明するフローチャート（その１）である。 図２５Ｂは、実施形態が適用された受信側の処理の一例を説明するフローチャート（その２）である。 図２６は、関数を用いた予約を受け付けるかどうかをユーザに問合せるアラート画面（現在表示中の映像にオーバーラップするウインドウの画面）を例示する図である。 図２７は、録画または視聴の予約がなされるときの画面表示を例示する図である。 図２８は、関数を用いた予約を受け付けるかどうかをユーザに問合せるアラート画面が図２７の画面表示上にオーバーラップウインドウで表示される場合を例示する図である。 図２９は、録画予約がなされたときの予約リストを例示する図である。 図３０は、受信機側のユーザが予約内容を確認し、予約の一部を取り消す操作画面を例示する図である。 図３１は、予約番組がマーキングされたＥＰＧの表示画面を例示する図である。 図３２は、放送番組を視聴するとき、或は視聴予約、視聴予約キャンセル、録画予約、録画予約キャンセルを行うときに利用される番組表の他の表示例を示す図である。 図３３は、放送番組を視聴するとき、或は視聴予約、視聴予約キャンセル、録画予約、録画予約キャンセルを行うときに利用される番組表のさらに他の表示例を示す図である。 図３４は、放送番組を視聴するとき、或は視聴予約、視聴予約キャンセル、録画予約、録画予約キャンセルを行うときに利用される番組表のさらにまた他の表示例を示す図である。 図３５は、放送番組を視聴するとき、或は視聴予約、視聴予約キャンセル、録画予約、録画予約キャンセルを行うときに利用される番組表のまた他の表示例を示す図である。 図３６は、放送番組を視聴するとき、或は視聴予約、視聴予約キャンセル、録画予約、録画予約キャンセルを行うときのサービス提供装置と受信機の動作例を説明するために示したフローチャートである。 図３７は、上記受信機においてパレンタルロック機能が働くときの動作例を説明するために示したフローチャートである。 図３８は、上記受信機において個人的なパレンタルロック機能が使用されるときの動作を説明するために示したフローチャートである。 図３９は、上記受信機の端末連携機能の拡張的利用形態を示す実施形態を示す図である。 図４０は、ホームゲートウェイの機能ブロックとセンサ群７２００内のセンサの種類を示す説明図である。 図４１は、上記受信機の第１処理部と第２処理部の電源起動に関する実施形態を示す図である。 図４２は、さらなるＨＴＭＬアプリケーションの起動シーケンス例を説明する図である。

以下、実施の形態について図面を参照して説明する。図１は、実施形態が適用されたハイブリッドキャスト仕様（ハイブリッドキャスト規定或いはＩＰＴＶ規定などと称される場合もある）の全体システムの構成例を示す図である。図２は、図１の構成をさらに具体化して示す図である。

図１及び図２を参照して以下説明する。

＜放送局１０００＞
放送局１０００は、放送局サーバ１１００、セキュリティー装置１２００を備える。放送局１０００は、電波による放送信号（この明細書ではＢＳ放送、ＣＳ放送、地上デジタル放送などいずれの信号でもよい）を送出する。また放送局１０００は、デジタル放送信号、アプリケーション制御情報、提示に関する制御情報などを送出するとともに、サービス業者装置（サービス事業者と称する場合もある）３０００に対して、契約に基づいて番組に関するメタデータや動画コンテンツなどを提供することができる。

アプリケーション制御情報は、番組と連動するアプリケーション等を本システムに対応する受信機に対して周知すると共に、起動・終了のためのコマンド、制御情報などを含むものである。

アプリケーション制御信号の伝送方式に関しては、例えば、専用のＥＳ（Elementary Stream)による伝送方式、データカーセル（同じデータを繰り返し送信する伝送方式）、通信ネットワークのサーバ上に置かれている制御信号ファイルの取得方式がある。後述するハイブリッドキャスト対応の受信機は、アプリケーション制御信号の指示に従って、指定されたＵＲＬからアプリケーションを取得し、アプリケーションバウンダリなどの制御を実行する。

放送局１０００は、本システムにおいて上記放送局サーバ１１００を運営する。放送局サーバ１１００は、番組タイトル、番組ＩＤ、番組概要、出演者、放送日時、その他のデータ等のメタデータを受信機に提供する。放送局１０００がサービス業者装置３０００に提供する情報は、放送局サーバ１１００が備えるＡＰＩ（Application Programming Interface）を通じて提供される。

また、放送局１０００は、ハイブリッドキャスト仕様のサービス業者装置３０００との間でデータ交換を行うことができる。つまり放送局１０００は、契約に基づいて番組に関するメタデータや動画コンテンツなどをサービス業者装置３０００に提供することができる。

＜サービス業者装置３０００＞
サービス業者装置３０００は、サービス毎のサーバ３１００、アプリケーションデータベース３２００を含む。サービス業者装置３０００は、サービス業者が、受信機５０００に対してサービスを提供するためのコンテンツ、アプリケーションの制作・配信、個々のサービスを実現するために利用される。また、サービス業者装置３０００は、サービス業者が、ユーザに対して、各種サービスを販売、契約を行った場合にも利用される。サービス業者は、放送局やＶＯＤサービス等のプラットホーム業者が兼ねてもよい。

また、サービス業者装置３０００は、ユーザである受信機５０００からアクセスされる場合、必ずしもＡＰＩに限定される必要はない。

サービス業者装置３０００は、アプリケーションの管理を行い、受信機５０００に対してアプリケーションを配布することができる。この装置内のサービス毎のサーバ３１００は、個々のサービス（例えばＶＯＤ番組レコメンドサービス）、多言語字幕サービス、ソーシャルＴＶサービス等）を実現するためのサーバ機能を備える。またサービス毎のサーバ３１００は、該サービスの機能面を実現するだけでなく、該サービスを構成するコンテンツ（ＶＯＤコンテンツ、字幕データなど）の送出も行う。

またサービス毎のサーバ３１００は、リポジトリを備える。リポジトリは、本システムのアプリケーションを配布するために登録しており、受信機からの問い合わせに応じて提供可能なアプリケーションの一覧の提供や検索を行うことができる。

＜受信機５０００＞
受信機５０００は、放送信号を受信して各種の放送番組及び各種サービス情報を受信することができる。受信機５０００は、デジタル放送の受信機能（基本機能）に加えて、放送通信機能連携サービスを実現するための機能を備える。

即ち、受信機５０００は、ブロードバンドネットワーク接続機能に加え次のような機能を備える。放送により送られてくるアプリケーション制御情報に応じてアプリケーションを実行する機能、放送と通信の連携による提示を行う機能、端末連携機能などである。

上記端末連携機能は、他の端末からの要求に応じて番組情報などの放送リソースにアクセスしたり、再生制御等の受信機能を呼び出したりすることができる。

受信機５０００には、データ記録再生用の記憶媒体５００１を接続可能であるとともに、表示器５００２、スピーカシステム５００３を接続することも可能である（これらは受信機５０００にすでに含まれている場合もある）。

＜連携端末７０００＞
連携端末７０００は、受信機５０００と通信機能により相互通信を行うことができる。また携帯端末７０００は、サービス業者装置３０００とも通信機能により相互通信を行うことができる。

図３は、上記放送局１０００の主な構成を概略的に示している。放送局１０００は、映像エンコーダ１３０１、オーディオエンコーダ１３０２、字幕エンコーダ１３０３、その他の制御データ及びサービスデータなどを生成する付属データ生成部１３０４を備える。また放送局１０００には、放送局サーバ１１００、セキュリティー装置１２００が連携している。

映像エンコーダ１３０１、オーディオエンコーダ１３０２、字幕エンコーダ１３０３、その他の制御データ及びサービスデータなどを生成する付属データ生成部１３０４の各出力は、ストリーム化されており、多重化部１３０５にて、各ストリームが多重化される。多重化ストリームは、トランスポートストリームとして送信機１３０６に送出され、放送電波に多重されてアンテナより送信される。

また放送局１０００は、サービス業装置３０００との通信を行うための送受信部１３１０も備える。

図４は、放送波伝送路２１００及びハイブリッドキャスト伝送路２２００における主なストリーム及び情報を示している。各伝送路では、映像ストリーム、音声ストリーム、アプリケーション制御情報、サービス情報が伝送される。ハイブリッドキャスト伝送路２２００においては、サービス業者装置３０００から受信機５０００への下りストリームのみならず、受信機５０００からサービス業者装置３０００への上りストリームも存在する。

図５は、実施形態が適用された受信機５０００の概略的構成例を示す図である。受信機５０００は、ネットワークに接続されるハイブリッドキャスト仕様の第１処理部（通信コンテンツ処理部と称してもよい）５１００と、放送波を受信する第２処理部（放送コンテンツ処理部と称してもよい）５３００を有する。ネットワークは、先のサービス事業者装置３０００に接続されている。

第１処理部５１００は、ＩＰ通信インターフェース５１０１を備える。ＩＰ通信インターフェース５１０１を介して取り込まれたストリームは、ストリーミング受信処理部５１０２で受信され、復調されたストリームがデスマルチプレクサ５１０３で元の配列状態に復元される。デマルチプレクサ５１０３には、ＤＲＡＭ処理部５１０４が接続されており、このＤＲＡＭ処理部５１０４で、プログラムを動作させ、例えば、自動ダウンロードを実行させることができる。

デマルチプレクサ５１０３で分離された映像ストリームは、映像デコーダ５１１１でデコードされ、音声ストリームは、音声デコーダ５１１２でデコードされ、字幕ストリームは、字幕デコーダ５１１３でデコードされる。

デコードされた映像データ及び字幕データは、合成器５５０１で合成されて表示器５００２に入力することができる。デコードされた音声データは、合成器５５０２を介して、スピーカシステムに入力することができる。

第２処理部５３００は、放送チューナ５３０１を備える。放送チューナ５３０１で受信・復調されたストリームは、デスクランブラ５３０２に入力される。デスクランブラ５３０２では、入力ストリームが、ＣＡＳ（Conditional Access System）モジュール５３０４からの鍵でデスクランブルされる。デスクランブラ５３０２でデスクランブルされたストリームは、デマルチプレクサ５３０３に入力される。デマルチプレクサ５３０３は、データ放送用のデータをデータ放送受信処理部５３３０に出力する。またデマルチプレクサ５３０３で分離された映像ストリームは、映像デコーダ５３１１でデコードされ、音声ストリームは、音声デコーダ５３１２でデコードされ、字幕ストリームは、字幕デコーダ５３１３でデコードされる。デコードされた映像データ及び字幕データは、合成器５５０１で合成されて表示器５００２に入力することができる。デコードされた音声データは、合成器５５０２を介して、スピーカシステム５００３に入力することができる。

またデマルチプレクサ５３０３で分離されたデータ放送信号は、データ放送受信処理部５３３０で受信され、データ放送エンジン５３１５に入力される。データ放送により送られてきた表示用信号は、合成器５５０１に入力されて表示器５５０２にて表示される。

受信機５０００の全体的な動作を制御する手段として、統合制御器５２００が設けられている。統合制御器５２００は、アプリケーション制御部５２０１、セキュリティー管理部５２０２を有する。アプリケーション制御部５２０１は、アプリケーション制御情報に含まれる各種情報や制御情報に基づいて、受信機５０００の各ブロックを制御する。

セキュリティー管理部５２０２は、アプリケーションを管理し、セキュリティー機能を実現する。例えばアプリケーション認証機能を持ち、認証されたアプリケーションをマネージメントアプリケーションとして扱う。またアクセス制御機能、提示機能、エンフォースメント機能、リボケーション機能（放送外のマネージメントアプリケーションを対象とする機能）等を備える。

アクセス制御機能は、利用が許可されたアプリケーションに対して放送リソース（映像、音声、メタデータＳＩ情報等）や、受信機リソース（受信機の映像音声出力、ネットワークインターフェース等）を参照可能とする。またアプリケーションのセキュリティークラスに応じてアクセス可能な受信機ＡＰＩを制限する。

提示制御機能は、放送事業者の意図に基づき、アプリケーションの表示方法（放送動画へのオーバーレイの可否、表示領域及びサイズ、表示/非表示など）を決定する。さらに災害報道などの緊急時において、例えばアプリケーション又はその関連表示を一時的に非表示として、放送番組の全画面表示の制御を可能とする。

リボケーション機能は、放送事業者や利用者の利益を損なう、問題のあるアプリケーションを無効化できる機能である。

アプリケーションエンジン５１３０は、アプリケーションを実行するための環境を形成している。アプリケーションエンジン５１３０としては、ハイブリッドキャストに対応するための拡張ＡＰＩを搭載した例えば、ＨＴＭＬ５ブラウザが用いられる。

端末連携制御部５５００は、外部の連携端末との連携を実行するインターフェースである。

図６は、図５の受信機の全体的な構成を概略的に示し、ハイブリッドキャスト仕様の受信機に関連する部分がわかるように示している。放送波は第２処理部５３００で受信・処理される。インターネットを介して受信される信号は、第１処理部５１００で処理される。統合制御部５２００は、第１処理部５１００、第２処理部５３００を制御すると共に、また、ＧＵＩ（グラフィックインターフェース）を制御し、第１処理部５１００、及び第２処理部５３００の表示状態を制御することができる。

図７は、上記ハイブリッドキャスト仕様の受信機をハードウエア５６０１と、受信或いは通信機能５６０２とアプリケーション５６０３の面から概略的に見た説明図である。

ハードウエア５６０１は、通信インターフェース（通信I/F）、チューナ、デコーダなどを備える。

受信或いは通信機能５６０２において、放送受信再生機能は、放送波を受信し、特定の放送サービスを選局し、サービスを構成する映像、音声、字幕、データ放送を同期し再生する機能である。通信コンテンツ受信再生機能は、通信ネットワーク上のサーバに置かれた映像コンテンツにアクセスし、ＶＯＤストリーミングとして受信し、コンテンツを構成する映像、音声、字幕を同期再生する機能である。アプリケーション制御機能は、通信ネットワーク上のサーバ或いは放送信号から取得したアプリケーション制御情報に基づき、主にマネージメントアプリケーションに関してアプリケーションエンジンに対して働きかけ、アプリケーション単位のライフサイクル及びイベントの制御・管理を行う機能である。セキュリィテーマネジメント機能は、主にアプリケーション制御機能に関連して、規定されるセキュリティーマネジメントに関わるルールに基づいて、アプリケーションの状態と放送信号等により指定される指示に依存し、適宜アプリケーションの機能制約を実施する機能である。端末連携制御機能は、外部の連携端末との連携において、機器発見を行い、受信機と連携端末間の接続及びアプリケーションの連携を管理しインターフェースする機能である。提示同期制御機能があり、放送受信による映像・音声等のストリームと、ストリーミング受信による映像・音声等のストリームの提示同期を制御する機能である。

アプリケーション５６０３において、アプリケーションエンジンは、アプリケーションを取得し、実行する機能である（ＨＴＭＬ５ブラウザに相当する）。アプリケーションロンチャーは、主に放送外マネージドアプリケーションをユーザが選択、起動するためのナビゲーションを実行する。

＜ハイブリッドキャスト仕様に関わる説明＞
ところで、図１の放送局１０００は、例えば２Ｋ、４Ｋ、または８Ｋ、の高解像度コンテンツを含む放送信号を受信機５０００側に送出するように構成されている。放送局１０００と連携してサービス事業を展開するサービス事業者３０００は、例えばインターネットを利用して受信機５０００にアプリケーションを配信し、種々なサービスを提供できるようにしている。このサービス提供には、ＨＴＭＬ５（またはそれ以降のバージョンのＨＴＭＬ）を利用できる。配信されるアプリケーションとしては、ＨＴＭＬ文書に埋め込み可能な、スクリプトタイプのコンピュータプログラム（Java（登録商標）を用いたJavaScript（登録商標）、ECMA scriptなど）を用いることができる。（以後、このコンピュータプログラムを、適宜「スクリプト」と略称する。実施形態では、そのスクリプトとして、JavaScriptを採用できる。）
ＨＴＭＬ（HTML5以降）に埋め込まれるスクリプトは、種々な関数を含むことができる。例えば視聴予約や録画予約を行う場合、ARIB STD-B62第二編（マルチメディア符号化方式言語仕様）やARIB TR-B39第三編（高度BS デジタル放送マルチメディアサービス運用規定）に記載された関数を、スクリプトに含めることができる。その一例を以下に示す：
partial interface ReceiverDevice {
boolean isScheduledToTune(
ISDBResourceReference event_ref,
optional Date startTime);
void scheduleToTune(
ISDBResourceReference event_ref,
optional Date startTime);
void unscheduleToTune(
ISDBResourceReference event_ref);
boolean isScheduledToRecord(
ISDBResourceReference event_ref,
optional Date startTime);
void scheduleToRecord(
ISDBResourceReference event_ref,
optional Date startTime);
void unscheduleToRecord(
ISDBResourceReference event_ref);};………。

上記の例において、「isScheduledToTune()」、「scheduleToTune()」は視聴予約に関する関数（図８（ａ）（ｂ）を参照）であり、「isScheduledToRecord()」、「scheduleToRecord()」は録画予約（図８（ｄ）（ｅ）を参照）に関する関数であり、「unscheduleToTune()」、「unscheduleToRecord()」は予約取消に関する関数（図８（ｃ）（ｆ）を参照）である。視聴予約関数、録画予約関数、予約取消関数等は、送信側（放送局および／またはサービス事業者）により適宜使用される関数であり、受信側（受信機ユーザ）で適宜実行(又は監視又は検出又は利用)される関数である。予約取消関数は、受信機ユーザが送信側により予約されようとしている（または予約された）番組の一部または全部を、受信機ユーザがリモコン操作等により取消す際に使用できる。

あるいは、ARIB STD-B24第二編（ＸＭＬベースのマルチメディア符号化方式）に記載された関数（図１４ＡのＥＰＧ関連機能のクラスを参照）をスクリプトで用いることもできる。

なお、受信側での録画は、録画コンテンツ（予約録画した１以上の番組）を受信側のストレージ（ハードディスクドライブ、フラッシュメモリ、光ディスクなど）に蓄積する操作と捉えることもできる。従い、実施形態においては、録画というタームで、適宜、蓄積の場合もカバーするものとする。

予約関連の関数（isScheduledToTune()、scheduleToTune()、isScheduledToRecord()、scheduleToRecord()、unscheduleToTune()、unscheduleToRecord()）の引数（event_ref）には、イベント伝送方式によって異なる規定を設けることができる。

ＭＰＥＧ２−ＴＳ方式で伝送されるイベントを指定するときは、event_refはＭＰＥＧ２−ＴＳで伝送されるリソースを参照していると解釈されるオブジェクトでなければならず、その各プロパティの扱いは、図９に示すように規定される。

ＭＭＴ方式で伝送されるイベントを指定するときは、event_refはＭＭＴで伝送されるリソースを参照していると解釈されるオブジェクトでなければならず、その各プロパティの扱いは、図１０に示すように規定される。

なお、視聴予約、録画予約、予約取消等には、図１１Ａ〜図１１Ｂの（ａ）〜（ｆ）に示すような関数（メソッド）を利用することもできる。

受信機のＩＰネットワークへの接続状態は、例えば図１２の関数（メソッド）を用いて確認できる。また、受信機は、例えば図１３の関数（メソッド）を用いて、アプリケーションオブジェクトを取得できる。

ハイブリッドキャスト方式に対応（準拠）したシステム（例えば図１の送受信システム）では、図１４Ａ、図１４Ｂに示すような放送用拡張関数を利用して種々な操作を行うことができる。例えば、送信側（図１では放送局１０００および／またはサービス事業者３０００）は、ハイブリッドキャスト方式に準拠した受信機（図１では受信機５０００）に対して、ＨＴＭＬ文書を用いて、視聴予約、録画予約、予約取消等を行うことができる。この視聴予約、録画予約、予約取消等には、ＨＴＭＬ文書に埋め込まれたスクリプト（JavaScript等）に含まれる関数（例えば図１４Ａに示されるＥＰＧ関連機能の関数）を利用できる。

図１５は、受信機が起動するデータ放送に関して、受信機形態とサービス形態との対応関係を例示する図である。データ放送としてＢＭＬだけが利用される場合は、複数のＢＭＬ文書がグループ単位で切り替えられることは想定されていない。しかし、ＡＲＩＢ−Ｊでは、複数のＡＲＩＢ−Ｊアプリケーションを同時に送出でき、それらを視聴者（受信機ユーザ）が切り替えることは想定される。そこで、アプリケーション情報テーブル（ＡＩＴ）によりＡＲＩＢ−Ｊアプリケーションのライフサイクルを管理し、それを受信機の機能によって視聴者が切り替えできるような仕組みが用意されている。

ＢＭＬとＡＲＩＢ−Ｊの双方に対応する共用受信機においては、ＢＭＬ文書についてもアプリケーションとして管理することとする。その管理のため、ARIB STD-B23ではアプリケーションマネージャと呼ばれる受信機機能を規定している。ＢＭＬ／ＡＲＩＢ−Ｊの共用受信機においては、このアプリケーションマネージャによって、ＢＭＬ文書が提示する処理のライフサイクルを制御できる。このアプリケーションマネージャを用いて、図１５に例示されるようなＢＭＬとＡＲＩＢ−Ｊの起動制御ができる。

図１６は、ＢＭＬ／ＡＲＩＢ−Ｊ共用受信機におけるデータ放送処理系の起動動作の一例を説明するフローチャートである。ＡＲＩＢ−Ｊによるデータ放送が送出されておれば、ＰＭＴ中のデータ符号化方式記述子としてadditional_arib_j_info()が存在する。共用受信機は、データ放送処理系を起動しようとするとき、ＰＭＴを検索し（ＳＴ１０）、ＰＭＴ中にadditional_arib_j_info()があるかどうかをチェックする（ＳＴ１２）。

additional_arib_j_info()がないときは（ＳＴ１２のＮ）、ＡＲＩＢ−Ｊによるデータ放送は送出されていないので、ＰＭＴ中のadditional_bxml_info()を取得し（ＳＴ１４）、ＢＭＬを起動する（ＳＴ２０）。

additional_arib_j_info()があるときは（ＳＴ１２のＹ）、additional_arib_j_info()内のinvocation_priorityを参照する。invocation_priorityが「０」のときは（ＡＲＩＢ−Ｊが優先）、ＡＩＴ伝送方式により伝送されるＡＩＴを取得する（ＳＴ１６）。

invocation_priorityが「１」のときは（受信機の設定が優先）、受信機の設定を取得するＳＴ１８）。受信機設定が「ＡＲＩＢ−Ｊ優先」となっているときは、ＡＩＴを取得する（ＳＴ１６）。受信機設定が「ＢＭＬ優先」となっているときは、additional_bxml_info()を取得して（ＳＴ１４）、ＢＭＬを起動する（ＳＴ２０）。invocation_priorityが「２」のときは、ＢＭＬが優先され、additional_bxml_info()を取得して（ＳＴ１４）、ＢＭＬを起動する（ＳＴ２０）。

ＡＩＴを取得（ＳＴ１６）した後、ＡＲＩＢ−Ｊを起動する場合は、ＡＩＴ内のapplication_control_codeを参照する（ＳＴ２２）。application_control_codeがAUTOSTARTとなっていれば（ＳＴ２２のＹ）、ＡＲＩＢ−Ｊアプリケーションが自動的に起動する（ＳＴ２４）。application_control_codeがAUTOSTARTでない（PRESENTなど）ときは（ＳＴ２２のＮ）、ＡＲＩＢ−Ｊアプリケーションの起動を保留し（ＳＴ２６）、ＡＩＴを監視する。監視中にＡＩＴが更新され、application_control_codeがAUTOSTARTになれば、ＡＲＩＢ−Ｊアプリケーションが自動的に起動する（ＳＴ２４）。ＡＲＩＢ−Ｊアプリケーションを配置するデフォルトのＥＳ（例えば0xA0）を規定することで、こうした監視やその他の起動シーケンスを容易に実行できる。

ＢＭＬが起動すると（ＳＴ２０）、ＢＭＬ内に記述されたＡＩＴのＵＲＬを参照して、ＡＩＴ（通信サーバ上のＡＩＴ）をインターネットから入手できる。このＡＩＴから、前述したパーミッションビットマップ（permission_bitmap）を獲得できる。（このpermission_bitmapは、例えば図２５ＡのＳＴ２００において利用できる。なおＡＩＴの獲得については、図４２を参照して後述する。）
図１７は、放送用拡張関数（ＡＩＴコントロールドアプリケーション連携機能）と指定可能な名前空間との対応関係を例示する図である。ここでは、モジュール、リソース、ES/NPT汎用イベントコンポーネントおよびＩＰ伝送路上の名前空間に関して、「ＵＲＩ記述要素としての引数がait_uriであるstartReceivingAIT()」と、「ＵＲＩ記述要素としての引数がait_uriであるgetReceivedAIT()」と、「ＵＲＩ記述要素としての引数がait_uriであるstartAITControlledApp()」が指定可能となっている。なお、ＵＲＩ記述要素としての戻り値がArray[][2]の場合、関数「getReceivedAIT()」が対応する名前空間は、モジュール、リソース、およびＩＰ伝送路上の名前空間となっている。

図１８Ａ〜図１８Ｃは、一部の拡張関数（getBrowserSupport()）とその引数に指定する文字列との対応関係を例示している。

図１９は、実施形態で用いられるパーミッションビットマップ（permission_bitmap）がどのように運用されるのかを例示する図である。図２０Ａ〜図２０Ｂは、ビットマップ０、ビットマップ１におけるbit値と機能の割り当てと動作の関係を例示する図である。また、図２１は、実施形態で使用できる外部アプリケーション制御記述子のデータ構造を例示する図である。

受信機がハイブリッドキャスト方式の下で視聴予約、録画予約、予約取消等を実施できるかどうかは、例えばpermission_bitmapのbit値（図２０Ｂのbit4に示される「視聴予約、録画予約ＡＰＩ」における「○」印を参照）を用いて決定するように構成できる。

受信機がハイブリッドキャスト方式に準拠しているかどうかについては、permission_bitmapの特定bit値（例えば図２０Ｂのbit0〜bit2）を用いて決定するように構成できる。

permission_bitmapは、アクセス権限を決めるビットマップであり、各放送リソースへのアクセス可否を、機能毎の16 bitのビットマップで決定できるようになっている。permission_bitmapの上位３ビットはビットマップの切り替えを示し、それ以外の機能ビットマップのアサインは実際の運用において規定できる。

permission_bitmapによりアクセス権限を持たないと判断された場合は、受信機はアクセスを無効とする。例えば、permission_bitmapによりハイブリッドキャスト方式のアクセス権限を持たないと判断された場合は、受信機は予約関連関数を含むＨＴＭＬ文書へアクセスをしないように構成できる。

permission_bitmapは、外部アプリケーション制御記述子に含めることができる（図２１を参照）。この外部アプリケーション制御記述子は、ARIB STD-B24第四編5.1で規定されるアプリケーション情報テーブル（ＡＩＴ）で伝送される。permission_bitmap（放送外マネージドアプリケーションの制御に用いられる情報の一部）を含むＡＩＴは、ＡＩＴコントロールドアプリケーション連携機能の関数（図１４Ｂを参照）を用いて、獲得できる。

図２２は、アプリケーションクラスとビット値との対応関係を示すビットマップを例示する図である。このビットマップにより、アクセス権限設定の対象となるアプリケーションのクラスが示される。このビットマップにおいて、複数のビットが１の場合は、各クラスの範囲のＯＲ条件で範囲設定を行うことができる。

図２３は、放送用拡張関数（ＩＰＴＶ連携機能）と指定可能な名前空間との対応関係を例示する図である。ここでは、ＩＰ伝送路上の名前空間として、「ＵＲＩ記述要素としての引数がsrc_pathであるstartDlcDownload()」と「ＵＲＩ記述要素としての引数がmetafile_uriであるstartVOD()」が指定可能となっている。

図２４は、実施形態が適用された送信側の処理の一例を説明するフローチャートである。この処理の内容は、送信側（例えば図１の放送局１０００および／またはサービス事業者３０００）の意向により決定できる。

まず、放送局１０００が送出する１以上の番組について、視聴予約したい場合は（ＳＴ１００のＹ）、視聴予約の関数を用いて、視聴予約対象番組毎の予約スクリプト（JavaScriptなど）を作成する（ＳＴ１０２）。その予約を取消可能にする場合は（ＳＴ１０４のＹ）、スクリプトに予約取消の関数を記載する（ＳＴ１０６）。

放送局１０００が送出する１以上の番組について、録画（蓄積）予約したい場合は（ＳＴ１００のＮ、ＳＴ１１０のＹ）、録画予約の関数を用いて、録画予約対象番組毎の予約スクリプト（JavaScriptなど）を作成する（ＳＴ１１２）。その予約を取消可能にする場合は（ＳＴ１１４のＹ）、スクリプトに予約取消の関数を記載する（ＳＴ１１６）。

予約取消関数をスクリプトに記載しない場合（ＳＴ１０４のＮ、ＳＴ１１４のＮ）、あるいは予約取消関数をスクリプトに記載（ＳＴ１０６、ＳＴ１１６）したあと、作成されたスクリプトが２以上あるときは、それらのスクリプトの記載内容を処理順にマージする（ＳＴ１２０）。マージ後のスクリプトは、ＨＴＭＬ５文書に埋め込まれる。

受信側がハイブリッドキャストに準拠するか否かをチェックする情報として、例えば、permission_bitmapを含むＡＩＴを獲得することに利用できる関数（図１４Ｂの「startReceivingAIT()」、「getReceivedAIT()」など）が考えられる。このようなチェック情報が、ＨＴＭＬ文書にないときは（ＳＴ１２２のＮ）、その情報をＨＴＭＬ文書に付加する（ＳＴ１２４）。チェック情報が付加されたＨＴＭＬ文書の作成が終了したあと、さらに予約の追加（または修正）があるときは（ＳＴ１２６のＮ）、ＳＴ１００〜ＳＴ１２４の処理が反復される。作成したＨＴＭＬ文書でＯＫのときは、図２４の処理を終了する（ＳＴ１２６のＹ）。こうして作成されたＨＴＭＬ文書（ＨＴＭＬ５以降の文書）は、インターネット経由で受信側へ送ることができる。

図２５Ａおよび図２５Ｂは、実施形態が適用された受信側の処理の一例を説明するフローチャートである。図２６は、関数を用いた予約を受け付けるかどうかをユーザに問合せるアラート画面（現在表示中の映像にオーバーラップするウインドウの画面）を例示する図である。

図２７は、録画または視聴の予約がなされるときの画面表示を例示する図である。また図２８は、関数を用いた予約を受け付けるかどうかをユーザに問合せるアラート画面が図２７の画面表示上にオーバーラップウインドウで表示される場合を例示する図である。

図２９は、録画予約がなされたときの予約リストを例示する図である。図３０は、受信機側のユーザが予約内容を確認し、予約の一部を取り消す操作画面を例示する図である。図３０は、予約番組がマーキングされたＥＰＧの表示画面を例示する図である。

受信側（例えば図１の受信機５０００の１つ）は、図２４の処理により作成されたＨＴＭＬ文書（ＨＴＭＬ５以降の文書）を受け取ると、図２５Ａの処理に入る。送られてきたＨＴＭＬ文書内の予約関連情報は、ハイブリッドキャスト方式を前提としている。ハイブリッドキャストに非対応の受信機でＨＴＭＬ文書内の予約関連スクリプトが処理されると、送信側が意図する予約動作が完遂されない可能性があるため、最初に受信機がハイブリッドキャストに準拠しているかどうかチェックする（ＳＴ２００）。

このチェックは、例えばＡＩＴに含まれるpermission_bitmap内の特定ビットが、ハイブリッドキャストを識別するビット（ＩＤビット）に該当するかどうかで行うことができる。（permission_bitmap以外にハイブリッドキャスト準拠を示すことのできる情報がＨＴＭＬ文書にあるときは、その情報をチェックに利用してもよい。）
受信側がハイブリッドキャストに準拠していないときは（ＳＴ２０２のＮ）、受信したＨＴＭＬ文書内のスクリプトを処理することなく、他の処理へリターンする。受信側がハイブリッドキャストに準拠しているときは（ＳＴ２０２のＹ）、ＨＴＭＬ文書内のスクリプトに予約に関する関数があるかどうか、チェックされる（ＳＴ２０４）。予約に関する関数が１つもないときは（ＳＴ２０４のＮ）、何も処理せずに他の処理へリターンする。

ＨＴＭＬ文書内のスクリプトに予約に関する関数が１以上あるときは（ＳＴ２０４のＹ）、そのスクリプトに記載された１以上の関数を用いた予約をするかどうか、ユーザに問合せる（ＳＴ２０６）。この問合せは、ＳＴ２０４でイエスと判定された直後に、行うことができる。

予約するかどうかの問合せの方法としては、ユーザの受信機で現在表示している画面１００の一部の領域１００ａ（図２６の（ａ））に、「予約の確認」のためのオーバーラッピングウインドウ２００（図２６の（ｂ））を出す方法が考えられる。画面１００の最上面にポップアップされたウインドウ２００では、例えば、「放送局から視聴予約（または録画予約）が入っています。予約しますか？予約するなら「はい」、しないなら「いいえ」をリモコンキー操作で選択し決定してください」といった表示をすることが考えられる。この表示は、ユーザが「はい」または「いいえ」を選択し決定するまで消さないように構成できる。

また、図２７で例示するように、録画または視聴の予約を行うウインドウ３００が表示されているときに、予約対象番組の縮小画面４００を動画で表示できる。ＨＴＭＬ５以降のブラウザは動画表示にも対応しているので、このような動画の縮小画面表示（４００）を含めた画面表示（１００）がブラウザの画面上で可能となる。動画表示できることで、例えば、ユーザが予約する際にその縮小画面で内容を確認することができ、間違えることなく予約の可否を判断することができる。

このようなウインドウ３００や縮小画面４００が表示されている際に、受信機が送信側（放送局やサーバ）から予約関数を含むＨＴＭＬ文書（HTML5以降のＨＴＭＬ文書）を受け取ることがある。その場合、図２８で例示するように、ＨＴＭＬ文書の関数を用いた予約を受け付けるかどうかをユーザに問合せるアラート画面を、現在の画面表示（図２７）上に、オーバーラッピングウインドウ２００で表示できる。例えばユーザがウインドウ２００内の「予約」ボタンをリモコン操作で選択し決定すると、ＨＴＭＬ文書の予約関数に基づく番組予約（録画予約および／または視聴予約）がなされる。このときの予約には、ユーザ自らが予約用に選択していた番組（例えば10/22(土）よる10：00からの放送番組）を含めることができる。

オーバーラッピングウインドウ２００の出力とともに、あるいはオーバーラッピングウインドウ２００を出力する代わりに、「予約の確認」のための音声案内をしてもよい。例えば、「放送局から視聴予約が入っています。予約しますか？予約するならテレビに向かって「予約します」、しないなら「予約しません」と声をかけてください」いった音声案内を、受信機５０００のスピーカを用いて行うことが考えられる。（受信機に図示しないマイクと音声認識部を設け、音声案内に対するユーザの返答を音声認識して、返答内容に対応する処理を行うように構成できる。）この音声案内は、ユーザが「予約します」または「予約しません」と返答するまで、一定周期で反復するように構成できる。この音声案内をするか否かは、受信機に対するユーザの事前設定により、決定できる。

ここで、図２５Ａを参照した説明に戻る。ユーザがウインドウ２００（図２６（ｂ））で「いいえ」を選択し決定したら、あるいは音声で「予約しません」と返答したら（ＳＴ２０８のＮ）、何も処理せずに他の処理へリターンする。ユーザがウインドウ２００で「はい」を選択し決定したら、あるいは音声で「予約します」と返答したら（ＳＴ２０８のＹ）、予約の内容に応じた処理を行う。

すなわち、ＨＴＭＬ文書内のスクリプト中に録画予約の関数が１以上あるときは、それらの関数を用いて、１以上の録画予約対象番組の予約リスト（図２９を参照）を作成する（ＳＴ２１０）。あるいは、それらの関数を用いて、１以上の録画予約対象番組がマーキングされたＥＰＧ（図３１のマークＲＲＭを参照）を作成する（ＳＴ２１０）。

ＨＴＭＬ文書内のスクリプト中に視聴予約の関数が１以上あるときは、それらの関数を用いて、１以上の視聴予約対象番組の予約リスト（図示しないが、図２９から「録画先」の項目を除いたものに相当）を作成する（ＳＴ２１２）。あるいは、それらの関数を用いて、１以上の視聴予約対象番組がマーキングされたＥＰＧ（図２９のマークＲＷＭを参照）を作成する（ＳＴ２１２）。

録画予約リスト（図２９）または録画予約のマーキングが付いたＥＰＧ（図３１）を見たユーザは、リモコン操作などにより、予約された番組の一部または全部の録画予約を取り消すことができる。録画予約の一部または全部を取り消したい場合（ＳＴ２１４のＹ１）、録画予約取消の関数があるときは、予約リスト上の各番組に対して録画予約取消のためのユーザ操作画面（図３０を参照）を作成する（ＳＴ２１６）。あるいは、１以上の録画予約対象番組がマーキングされたＥＰＧ（図３１のマークＲＲＭを参照）から予約マーキングを番組毎に外せるように、ＥＰＧを作成する（ＳＴ２１６）。

同様に、視聴予約リスト（図２９から「録画」の項目を除いたもの）または視聴予約のマーキングが付いたＥＰＧ（図３１）を見たユーザは、予約された番組の一部または全部の視聴予約を取り消すことができる。視聴予約の一部または全部を取り消したい場合（ＳＴ２１４のＹ２）、視聴予約取消の関数があるときは、予約リスト上の各番組に対して視聴予約取消のためのユーザ操作画面（図示しないが、図２９から「ＵＳＢ＿ＨＤＤ１」の項目を除いたものに相当）を作成する（ＳＴ２１８）。あるいは、１以上の視聴予約対象番組がマーキングされたＥＰＧ（図３１のマークＲＷＭを参照）から予約マーキングを番組毎に外せるように、ＥＰＧを作成する（ＳＴ２１８）。

予約リストまたはＥＰＧ上で予約された１以上の番組の一部または全部が取り消されたときは（ＳＴ２２０のＹ）、予約取消操作後の視聴予約および／または録画予約の処理が実行される（ＳＴ２２２）。予約リストまたはＥＰＧ上で予約された１以上の番組のいずれも取り消されなかったときは（ＳＴ２２０のＮ）、予約取消がない視聴予約および／または録画予約の処理が実行される（ＳＴ２２４）。以上の予約処理が済むと、他の処理へリターンする。

なお、個々の受信機は、上記の予約が済んだ後に予約内容の変更（予約の全取消を含む）をユーザ操作で行えるように、構成できる。

つまり、上記した予約視聴や予約録画或いは予約取消しを行うために利用される関数は、上記したように、オーバーラッピングウインドウを表示するために利用される関数でもあってもよいし、或は、この関数がオーバーラッピングウインドウを表示するために利用される関数を別途含んでいてもよい。なおオーバーラッピングウインドウは、必ずしもウインドウに限らず、要はユーザが予約や予約取消しを決定するか否かの意思表示を示すために利用する確認用表示（ボタン）であればよく、受信機のユーザインターフェースによってユーザへ録画及び蓄積動作の可否を問い合わせる機能を有すればよい。

図４２は、ＨＴＭＬアプリケーションの起動シーケンスの一例を説明する図である。図４２は、トリガＡから始まるネットワーク系の起動シーケンスＳＱ１と、トリガＢから始まる放送系の起動シーケンスＳＱ２を例示している。

ＡＲＩＢフェーズ０の運用仕様に対応したアプリケーションの起動では、アプリケーションの起動シーケンスにＳＱ１を用いる。すなわち、必ずデータ放送コンテンツの起動（トリガＡ）から始まり、ＨＴＭＬ（実施形態ではHTML5以降のバージョン）アプリケーションを直接起動しない。アプリケーションを起動する際は、ＢＭＬコンテンツをまず起動（シーケンスＳＱ１）し、コンテンツに記述されたスクリプトによって通信サーバ上のＡＩＴを取得し、以後、そのＡＩＴに従ってＨＴＭＬアプリケーション（予約関連関数を利用したアプリケーション等）を起動する。

ＡＲＩＢフェーズ１の運用仕様に対応したアプリケーションの起動では、シーケンスＳＱ１に加えて、シーケンスＳＱ２を用いることができる。すなわち、ＰＭＴ（プログラムマップテーブル）の優先情報およびデータカルーセルにより伝送するセクション形式のＡＩＴの優先情報により、ＢＭＬコンテンツを起動するか、直接ＨＴＭＬアプリケーションを起動するかを、指定できる。直接ＨＴＭＬアプリケーションを起動する場合は、データカルーセルにより伝送されるＡＩＴに指定された情報に従って、アプリケーションを取得し起動する。

アプリケーションの起動優先制御の運用は、ARIB TR-B14第三編第２部「8.5 ＡＩＴコントロールドアプリケーションの起動・終了」に従うことができる。ＡＲＩＢフェーズ１の運用では、ARIB STD-B24第二編9.3.2に記載の「additional_arib_bxml_info()」構造の拡張パラメータである起動優先度（start_priority）の値を規格通りに運用し、受信機はこの運用に従った動作を行うように構成する。

・ＡＲＩＢフェーズ０における、アプリケーション識別子の指定について
ＸＭＬ形式のＡＩＴで指定されるisdb:orgIDには、ＩＰＴＶフォーラムよりサービス事業者に付与された値が用いられる。この値として「０」は特別な値としてリザーブされ、「０」は全てのisdb:orgIDに合致すると解釈することができる。この「０」をＡＩＴの記述中で用いることはできない。isdb:orgIDは、サービス事業者がアプリケーション毎に唯一の値となるように、値の付与がなされる。

・ＡＲＩＢフェーズ０における、アプリケーションプロファイル、バージョンの運用について
ARIB TR-B14第三編第２部第８章で規定されるフェーズ０運用仕様に対応するものとして、ＸＭＬ形式のＡＩＴで指定されるmhp:profileは「１」とし、mhp:versionMajor、mhp:versionMinor、およびmhp:versionMicroは、それぞれ「１」に固定する。

・ＡＲＩＢフェーズ０における、シグナリングについて
シグナリングは、例えば図４２の通信サーバ上のＸＭＬ＿ＡＩＴファイルによる。サーバ上のＸＭＬ＿ＡＩＴファイルは、MIME typeをapplication/X-arib-ait-xml; charset="UTF-8"とし、httpまたはhttpsでサーバから取得する。ＡＩＴファイルは、それによって起動されたアプリケーションが有効である間のみ、その効力を持つ。

・ＡＲＩＢフェーズ１における、アプリケーション識別子の指定について
データカルーセルで伝送されるセクション形式のＡＩＴで指定されるorganization_idには、ＩＰＴＶフォーラムよりサービス事業者に付与された値が用いられる。この値として「０」は特別な値としてリザーブされ、「０」は全てのorganization_idに合致すると解釈することができる。この「０」をＡＩＴの記述中で用いることはできない。一方、application_idは、サービス事業者がアプリケーション毎に唯一の値となるように、値の付与がなされる。

・ＡＲＩＢフェーズ１における、アプリケーションプロファイル、バージョンの運用について
ARIB TR-B14第三編第２部第８章で規定されるＡＲＩＢフェーズ１運用仕様に対応するものとして、ＸＭＬ形式のＡＩＴで指定されるmhp:profileは「２」とし、mhp:versionMajor、mhp:versionMinor、およびmhp:versionMicroは、それぞれ「１」とする。セクション形式のＡＩＴで指定されるmhp:profileは「0x0002」とし、mhp:versionMajor、mhp:versionMinor、およびmhp:versionMicroは、それぞれ「0ｘ01」とする。

・ＡＲＩＢフェーズ１における、application_control_codeの運用について
フェーズ１の運用では、セクション形式のＡＩＴにおいて、application_control_codeの値は、0ｘ01（識別名：AUTOSTART）、0ｘ02（識別名：PRESENT）、0ｘ04（識別名：KILL）を運用する、0ｘ05（識別名：PREFETCH）は運用しない。不明なapplication_control_codeを受信した受信機は、当該アプリケーションがＡＩＴに記載されていなかったものとして無視する。

・ＡＲＩＢフェーズ１における、確率的運用遅延記述子の運用について
フェーズ１の運用では、セクション形式のＡＩＴにおいて、確率的運用遅延記述子を運用しない。

・ＡＲＩＢフェーズ１における、キャッシュ情報記述子の運用について
フェーズ１の運用では、ARIB TR-B14第三編第２部「8.3.4.7キャッシュ情報記述子の運用」に記載されるように、キャッシュ情報記述子を運用しない。フェーズ１の運用におけるアプリケーションキャッシュの運用については、ARIB TR-B14第三編第２部「8.3.4.7キャッシュ情報記述子の運用」および「8.4.1.5オートスタートアプリケーションのキャッシュ」を参照。

・ＡＲＩＢフェーズ１における、シグナリングについて
フェーズ１の運用では、データカルーセルで伝送するセクション形式のＡＩＴおよび、通信から取得するＸＭＬ＿ＡＩＴの両方を用いることができる。データカルーセルで伝送する特定のセクション形式のＡＩＴは、受信機により常時監視される。その監視の結果ＡＩＴの状態が変化したことが検出されたら、ＡＩＴコントロールドアプリケーションの起動・終了等の制御を行うことができる。ＡＩＴの更新に関する動作については、ARIB TR-B14第三編第２部「8.5.2 常時監視するＡＩＴに基づくＡＩＴコントロールドアプリケーションの起動・終了」を参照。

前述した、permission_bitmapなどを含むＡＩＴ（受信側がハイブリッドキャストに準拠しているかどうかを判定するのに利用できる情報）は、例えば図１の放送局１０００から受信機５０００へ、放送信号を介して伝送できる（図４２のＳＱ２に対応）。あるいは、そのＡＩＴは、例えば図１のサービス事業者３０００から受信機５０００へ、インターネットを介して伝送できる（図４２のＳＱ１に対応）。さらには、そのＡＩＴを、放送信号を介して受信機５０００に送るとともに、インターネットを介して受信機５０００に送るように構成することもできる。

放送信号を介して送られたＡＩＴとインターネットを介して送られたＡＩＴの受信時刻が異なるときは、そのＡＩＴに関係するＨＴＭＬ文書内の関数の実行前（例えば図２５ＡのＳＴ２００のチェック時）に、受信時刻がより遅いＡＩＴ（最新のＡＩＴ）の情報内容を優先的に採用するように構成できる。あるいは、放送信号経由のＡＩＴとインターネット経由のＡＩＴとの間で優先度の高低を事前に決めておけば、受信時刻の後先を問わず、優先度の高いほうのＡＩＴを採用するように構成できる。（この優先度の決定に当たっては、ARIB STD-B24第二編9.3.2に記載の「additional_arib_bxml_info()」構造の拡張パラメータである起動優先度（start_priority）の値を参照できる。）
図３２、図３３及び図３４は、放送番組を視聴するとき、或は視聴予約、視聴予約キャンセル、録画予約、録画予約キャンセルを行うときに利用される番組表の表示例を示している。

番組表の表示切替は、例えば端末連携機能と連携している連携端末７０００の操作により行うことができる。連携端末７０００は、地デジ放送番組表を表示させるためのボタン７００１、ＢＳ及びＣＳ放送番組用の番組表を表示させるためのボタン７００２、ＩＰＴＶによる放送（配信）用の番組表を表示させるためのボタン７００３を備える。また、番組表が表示されているときに、画面を垂直方向と水平方向へ選択的にスクロールさせるためのボタン７００５を備える。

さらに連携端末７０００は、録画予約する番組の録画予約ボタン７００６、視聴予約する番組の視聴予約ボタン７００７、録画予約した番組、或は視聴予約した番組の予約取り消しボタン７００８などを備える。

図３２は、表示器５００２に地デジ放送番組用の番組表が表示された様子を示している。地デジ放送番組用の番組表が表示されたときは、番組表の種類を示す識別マーク７０１１が表示器５００２の一部に表示される。図３３は、表示器５００２にＢＳ及びＣＳ放送番組用の番組表が表示された様子を示している。ＢＳ及びＣＳ放送番組用の番組表が表示されたときは、番組表の種類を示す識別マーク７０１２が表示器５００２の一部に表示される。図３４は、表示器５００２にＩＰＴＶ放送用の番組表が表示された様子を示している。ＩＰＴＶ放送用の番組表が表示されたときは、番組表の種類を示す識別マーク７０１３が表示器５００２の一部に表示される。上記識別マーク７０１１，７０１２及び７０１３はそれぞれ色が異なっていてもよい。

なお図示の番組表の例は、ＩＰＴＶ放送において、番組が繰り返し或いは間隔を置いて繰り返し放送される期間を示している。ビデオオンデマンドによる配信がある場合にもこの番組表は便利である。しかし、地デジ放送番組用、或はＢＳ及びＣＳ放送番組用の番組表のような表示形式でもよい。

上記した地デジ放送番組用の番組表及びＢＳ及びＣＳ放送番組用の番組表は、第２処理部５３００を介して取得された電子番組ガイド情報（ＥＰＧ情報）に基づいて、例えば統合制御部５２００において作成され、メモリに保存されている。このＥＰＧ情報は、例えば定期的に自動的に更新される。

また第１処理装置５１００を介して、ＩＰＴＶ用のＥＰＧ情報が取得される。第１処理装置５１００は、各チャンネルの番組表を定期的に取得し、例えば統合制御部５２００において、各チャンネルの番組表が組み合わせられ、表示用の番組表としてメモリに保存されている。

上記した番組表は、それぞれ、独立して表示器５００２に表示されるものとして説明した。しかしこのような表示方法に限定されるものではなく、複数の種類の番組表が重なって表示器５００２に同時に表示されてもよい。

図３５は、表示器５００２において、地デジ放送番組用の番組表５０３１と、ＢＳ及びＣＳ放送番組用の番組表３０１２と、ＩＰＴＶ放送用の番組表３０１３が同時に表示された様子を示している。

複数の番組表が同時に表示される場合、各番組表が重なって表示されてもよい。また各番組の表示領域が画面上で区分されていてもよい。いずれの表示形態においても、各番組表は、それぞれの一部がカーソルにより指定された場合、画面の縦方向或いは横方向にスクロールさせることができる。

上記した番組表の表示例を示す各実施形態において、視聴予約及び又は録画予約がされていることは、番組名の領域に着色、或はマークが付加されることで、視覚的に認識可能とされ、また、録画が済んでいることも着色或いはマークなどで視覚的に認識可能とされる。

図３５の実施形態の場合も、連携端末７０００に備えられている地デジ放送番組表を操作するためのボタン７００１、ＢＳ及びＣＳ放送番組用の番組表を操作するためのボタン７００２、ＩＰＴＶ放送（配信）用の番組表を操作するためのボタン７００３を利用して、視聴予約（又は予約取り消し）、録画予約（又は予約取り消し）などを行うことができる。

図３２−図３５に示した番組表は、横軸が時間或いは日時であり、縦軸がチャンネル（放送局）であるが、横軸がチャンネル（放送局）、縦軸が時間或いは日時で表示されてもよい。

図３６は、視聴予約、視聴予約取消し、録画予約、録画予約取消しを行う際の受信機５０００とサービス業者装置３０００との間の通信形態の他の例を示す図である。

受信機５０００は、ユーザ操作に基づいて、ＩＰＴＶ放送用の番組表（ＥＰＧ）を表示する（ＡＳ１）。ユーザは、番組表の中から例えば録画予約したい番組をリモートコントローラ操作により選択し決定することができる（ＡＳ２、ＡＳ３）。

受信機５０００は、ＵＲＬを利用して当該番組のサービス業者装置３０００をアクセスし、番組に関する情報を要求する（ＡＳ３）。すると、サービス業者装置５０００は、受信機５０００に対して録画予約に関する関数が含まれる情報（ＡＰＩ情報と称してもよい）（或いは録画予約に関する情報のみが含まれる情報でもよい）をＨＴＭＬ５による記述文書で返信する（ＥＳ１）。

受信機５０００は、送られてきた関数を確認し（ＡＳ４）、予約不可の場合は、予約不可であることのメッセージを受信機５０００の表示器に表示して、処理を終了する（ＡＳ６）。送られてきた関数において、予約可能が判定された場合（ＡＳ７）、表示器に予約画面が表示されるので、ユーザは、予約ボタンを選択して設定ボタンを押し、操作を終了する。

受信機５０００内では、予約管理テーブルに、当該番組の番組予約情報を記載する。例えば、予約管理テーブル内の当該番組の情報（チャンネル（アドレス）、放送開始時間、放送終了時間などを含む）領域の欄に予約マークが追記される。

受信機５０００は、前記予約番組の放送時間が近付くと、第１処理部５１００の受信チャンネルを設定する（ＡＳ８）。そして、当該番組の受信を開始し、自動録画を開始する（ＡＳ９、ＡＳ１０、ＡＳ１１）。このときは、サービス事業者装置３０００による当該番組の放送が開始されると（ＥＳ２）ている。サービス事業者装置３０００は、当該番組の放送が終了すると受信機に対して終了関数を通知する（ＥＳ３）。受信機５０００は、終了通知を受けると、サービス事業者装置３０００との接続をオフし、予約録画を終了する（ＳＡ１２）。接続がオフされた後、「予約録画を終了します」とメッセージを表示してもよい。そうすることでユーザは接続がオフされたことが分かる。

上記の説明は録画予約であるが、視聴予約についても同様な手順で視聴予約がなされる。但し、視聴予約の場合は、録画は行われず、受信機５０００は、予約番組の表示状態に制御される。

視聴予約取消しや、録画予約取消しの場合は、予約管理テーブル内の予約番組の予約情報の削除が行われるのみである。

図３７は、パレンタルロック機能・ロック解除機能を説明するためのフローチャートである。番組によってはその番組情報（サービス情報）にパレンタルに関する関数が付随している場合がある。そのような場合は、人によっては、例えば２１歳以上は、パレンタルロックを解除する権限をもつ人がいる。このフローチャートは、このようなパンレンタルロックを伴う番組に対する操作処理機能を実現するフローチャートである。この機能も統合制御器５２００におけるアプリケーションにより実現される。

今、受信機５０００がある番組を受信し、操作装置（リモートコントローラ或いは携帯端末）から、その再生指示があったとする（ステップＳＢ１）。すると、当該番組の関連情報にパレンタルロックレベル情報が付随しているか否かを判定する（ステップＳＢ２）。パレンタルロックレベル情報が付随していない番組の場合は、受信した番組の再生表示が実行される（ステップＳＢ３）。

しかし、パレンタルロックレベル情報が付随している番組の場合は、「パンレンタルロックがかかっている番組です」のようなメッセージを表示器５００２に表示する（ステップＳＢ４）。ここで、操作装置から解除キー入力があった場合（ステップＳＢ５）は、当該解除キーが正しいか否かを判定する（ステップＳＢ６）。解除キーが正しい場合は、受信した番組の再生表示が実行される（ステップＳＢ３）。解除キーが正しくない場合は、当該番組の受信から一定時間が経過したか否かを判定し（ステップＳＢ７）、一定時間経過していない場合は、解除キーの入力を待ち、一定時間が経過した場合は、終了となり（ステップＳＢ７）、例えば「視聴できません」などのメッセージを表示する。

図３８は、ユーザ自身が、任意の番組に対して、パレンタルロック機能を設定できるようにした機能を説明するためのフローチャートである。例えば、ある番組については、親は、子供に見せたくないかもしれない。そのような場合、ユーザは操作装置を操作して、パレンタルロック機能を起動することができる（ステップＳＢ１）。そして所望の番組表を表示させる（ステップＳＢ２）。次に、パレンタルロックを設定したい番組をカーソルにより選択する（ステップＳＢ３）。次に決定ボタンが押されると（ＳＢ４）、視聴時のロック解除キーの入力を要求する（ステップＳＢ５）。ここでユーザがロック解除キーの設定入力を行うと（ステップＳＢ６）、処理が終了する。

当該番組を視聴する場合には、視聴しようとする者は、前記ロック解除キーを入力しなければならない。この時のロック解除キーの入力タイミングは、先のフローチャートで説明した通りである。

図３９、図４０は、端末連携機能５５００が有効活用される実施形態を示している。端末連携機能５５００は、機器登録している複数の携帯端末７０００ａ，７０００ｂをサーチすることができ、相互でデータ通信（例えば緊急通信など）を行うことができる。

さらに端末連携機能５５００は、ホームゲートウェイ７１００と通信を行うことができるように、ホームゲートウェイ７１００（ＨＧＷ）の識別情報も所有する。つまりホームゲートウェイ７１００（ＨＧＷ）は、端末連携機能５５００により認識されることが可能である。

このＨＧＷ７１００は、インターネットを介してサーバ７８００と通信を行うことができる。ＨＧＷ７１００は、図４０に示すように、システムコントローラ７１０２、デバイス管理器７１０３、ネットワークインターフェース（以下ネットワークＩ／Ｆ）７１０４、記録管理器７１０５、センサ制御テーブル７１０６を含む。

制御データ管理部７１０１は、アプリケーションマネージャ（以下ＡＰＰ−Ｍｇ）、イベントマネージャ（以下ＥＶＴ−Ｍｇ）、コンフィギュレーションマネージャ（以下ＣＯＮＦＩＧ−Ｍｇ）を含む。

ＡＰＰ−Ｍｇは、ＨＧＷ７１００の各種動作を制御するための複数のアプリケーションを管理している。ＥＶＴ−Ｍｇは、各種イベントの発生に応じて、各種動作を制御するためのイベント用アプリケーションなどを管理している。ＥＶＴ−Ｍｇは、記録管理器７１０５を制御することもできる。記録管理器７１０５は、端末連携機能５５００を介して、記憶媒体５００１にデータ或いは映像を記録することができる。

ＣＯＮＦ−Ｍｇは、ＨＧＷ７１００内の機能とこのＨＧＷ７１００が関連している各種機能を認識して、例えば動作順位、動作制限などを行う構成用アプリケーションを管理している。またＣＯＮＦ−Ｍｇは、各機能ブロックの初期設定、機能の制限、機能の拡張、優先順位、動作時間などの設定を行うことができる。システムコントローラ７１０２は、ＨＧＷ７１００内の各ブロックを統括してシーケンス制御することができる。

ＨＧＷ７１００は、有線或いは無線により各種センサ群７２００と通信することができる。家庭内のネットワーク７３００の圏外に位置する携帯端末７０００ｃは、ＨＧＷ７１００の管理下にある場合は、ＨＧＷ７１００と通信することが可能であり、かつこのＨＧＷ７１００を介して端末連携機能５５００と通信することも可能である。各種センサ群７２００は、図４０に示すように、ＥＶＴ−Ｍｇにより制御可能なカメラ７２０１、マイク７２０２、スピーカ７２０３などを含む。なおカメラ７２０１、マイク７２０２、スピーカ７２０３は、家庭内の複数個所に設置されている。

またＥＶＴ−Ｍｇは、ネットワークＩ／Ｆ７１０４から取り込まれた外部センサからの検出データ及び又はカメラ７２０１、マイク７２０３からのデータを判定し、次のアクションや振る舞いを制御することができる。

デバイス管理器７１０３は、ＨＧＷ７１００に関連して動作する他の装置を認証し、メモリに登録することができる。したがって、デバイス管理器７１０３は、ネットワークＩ／Ｆ７１０４を介して、接続される他のセンサ（センサ群７２００）を管理することができる。

またデバイス管理器７１０３は、インターネットを介して接続されるサーバ（図示せず）の識別データも登録しており、認識することができる。

またセンサ制御テーブル７１０６は、センサ群７２００の各センサの名前、各センサの位置情報、各センサを制御するためのデータを記憶している。また各センサの名前や位置情報は、例えばスマートフォーン７０００ａ, ７０００ｂに表示されることができ、これにより、ユーザはセンサの種類や取り付け位置を確認することができる。

ネットワークＩ／Ｆ７１０４は、近距離無線を介して家庭内の他のセンサ、・・・・と接続される。

高機能のセンサによっては、制御データ管理部を含んでもよい。制御データ管理部は、ＨＧＷ７１００が有するようなアプリケーションマネージャ（ＡＰＰ−Ｍｇ）、イベントマネージャ（ＥＶＴ−Ｍｇ）、コンフィギュレーションマネージャ（ＣＯＮＦＩＧ−Ｍｇ）を含む。またセンサが含むセンシング機能としては、センシング目的に応じて各種の要素がある。各種要素としては、例えば、ＨＧＷ６００と同様に、カメラ、マイクである場合もある。さらに各種要素としては、熱センサ、温度センサ、湿度センサ、照明センサ、圧力センサ、スイッチ、などが含まれる。センサは、その利用目的において、１つ或いは複数のセンシング要素を備える場合もある。

上記のセンサは、ドアの開閉を検知するセンサ、一定の大きさの音の発音を検知するセンサ、人の動きを検知するセンサ、窓の開閉を検知するセンサ、撮影を行うセンサとして、例えば家庭内の種々の箇所に配置される。

上記したシステムにおいて、ＨＧＷ７１００は、カメラ、マイク、他のセンサ、・・・のいずれかの１又は複数から検出信号が出力された場合、制御データ管理部７１０１はイベント発生として認識する。すると制御データ管理部７１０１は、記録管理器７１０５を介して任意のカメラ７２０１を制御する。これにより、カメラ７２０１は、イベント発生時点より以前（例えば１０分前）からキャッシュしている監視データを記録管理器７１０５を介して例えば記憶媒体５００１に送るとともに、続けて一定時間（例えば３分、５分、１０分、２０分或いは３０分など）撮像した監視データを送り続ける。この監視データとともに、本システムでは前記イベントが検出されたときのイベント関連データ（イベント属性データと称してもよい）も記憶媒体５００１に送られる。

イベント関連データは、例えばイベントの発生時刻、該イベントを検出したセンサの種類、センサの位置データ、記録開始時間、記録終了時間などのいずれか１つ或いは複数を含むことができる。

ここで、図では、上記記憶媒体５００１は、家庭内であるが、必ずしも家庭内の記憶媒体である必要はない。監視データの記憶場所は、インターネットを介して接続されているサーバ７８００内の記憶媒体でもよい。記憶媒体５００１は、データ領域、管理領域を備える。データ領域に監視データが格納され、管理領域にイベント関連データが格納される。

監視データは、映像データのみならず、音データやセンサからの計測データも含む場合がある。監視データは、例えば特定の箇所の温度の変化状況、湿度の変化状況、或いは圧力の変化状況なども含む場合がある。

管理領域には、監視データを再生するための管理データが記述されている。この管理データが、先のイベント関連データも含む。管理データは、イベント関連データ、及びイベント関連データに対応する監視データの記録アドレスを含む。複数のイベントが発生した場合、複数のイベント関連データ、及び複数のイベント関連データに対応する複数の監視データが、存在する。

イベント関連データは、イベント（センサと称してもよい）の種類を含む。またイベントに基づいて監視データ（例えば監視映像）が記録されるが、イベント関連データは、その記録開始時間、記録終了時間なども含む。

上記のシステムにおいて、端末連携機能５５００は、ＨＧＷ７１００と通信を行うことができる。ＨＧＷ７１００は、サーバ７８００と通信を行うことができる。このために、携帯端末７０００ｃは、サーバ７８００、ＨＧＷ７１００を通じて、端末連携機能５５００をアクセスすることが可能である。

図４１のフローチャートは、受信機５０００の本格的な電源オン時の動作を簡略化して示している。先に説明したように、受信機５０００は、第１処理部５１００、第２処理部５２００を備える。本実施形態では、直前の電源オフ時（なおメモリなどの予備電源は、常にオン状態にある）に第１処理部５１００と第２処理部５２００の系統のどちらの映像出力、もしくは両方が動作していたかを記憶する手段を備えている。そして、次の電源オン時には、例えば統合制御部５２００が、電源オフ直前に機能していた系統を立ち上げるようにしている。

例えば、電源オン時には、統合制御部５２００が、直前の電源オフ時の環境データをチェックする（ステップＳＡ１）。そして直前の電源オフ時に視聴していたコンテンツが、第２処理部５３００で処理された放送波信号Ａか、第１処理部５１００で処理されたハイブリッドキャスト仕様による配信信号Ｂであるかを判断する（ステップＳＡ２）。

もし、直前の電源オフ時に視聴していたコンテンツが、第２処理部５３００で処理された放送波信号Ａならば、第２処理部５３００を起動する。これにより、第２処理部５３００からの映像・音声信号が表示器５００２、スピーカシステム５００３に供給される。また一定時間は、表示されているコンテンツのソースが、第２処理部（或いは放送信号）５３００であることを表示器５００２にて表示する。或いは表示器５００２に、第２処理部５３００からの放送信号であることを示すインジケータが点灯してもよい（ステップＳＡ３）。

逆に、直前の電源オフ時に視聴していたコンテンツが、第１処理部５１００で処理された配信信号Ｂならば、第１処理部５１００を起動する。これにより、第１処理部５１００からの映像・音声信号が表示器５００２、スピーカシステム５００３に供給される。また一定時間は、表示されているコンテンツのソースが、第１処理部（或いは配信信号）５１００であることを表示器５００２にて表示する。或いは表示器５００２に、第１処理部５１００からの放送信号であることを示すインジケータが点灯してもよい（ステップＳＡ４）。

ここから図４３は、端末連携機能５５００、記録媒体５００１、ＨＧＷ７１００を有効活用することを考慮した実施形態である。本システムでは、さらに制御対象としてＲ（赤）Ｇ（緑）Ｂ（青）の発光色の組み合わせにより、各種の色の光を照明できる複数の照明器７２０４、複数のスピーカ７２０３、複数のマイク７２０１の何れか又はこれらの組み合わせが利用される。

例えば、自宅に幼児を残して、保護者が外出する場合がある。保護者は、時々、幼児の様子を監視したい場合がある。このような場合、保護者は、自身が所有する携帯端末７０００ｃを利用して、自宅の幼児の様子を監視することができる。幼児に話しかけたい場合は、スピーカ７２０３−１を介して、話しかけることもできるし、幼児の返事を聞きたい場合は、マイク７２０２−１を介して幼児からの返事を聞くこともできる。

上記したシステムは、託児所に導入されていても便利である。託児所に幼児を預けて仕事に出かけた保護者は、外出先から預けた幼児の様子を外部から確認することができる。

さらには、自宅に被介護者がいた場合、介護者は、スピーカ７２０３−１、照明器７２０４−１を利用して被介護者に意思を伝えることができる。例えば、聴覚が不便な被介護者に対しては、照明器７２０４−１の色を種々変更して意思を伝えることができる。また視覚が不自由な被介護者に対しては、スピーカ７２０３−１を通じて意思を伝えることができる。

上記した実施形態においては、さらに以下の手段及び方法を含むものである。即ち、受信装置は、デジタル放送に関連するＨＴＭＬ文書に埋め込まれたアプリケーションの関数を用い、ハイブリッドキャスト方式に準拠して、放送番組の視聴予約を行えるように構成されている。そして、前記ハイブリッドキャスト方式に準拠するか否かをチェックすることに利用可能な情報を用いて前記ハイブリッドキャスト方式に準拠するか否かをチェックする手段及び方法を含む。さらに、前記視聴予約を設定するか否かユーザに問合せするための第１の画面を表示する手段及び方法も含む。また前記第１の画面を利用して所定の入力操作がなされた場合、前記視聴予約を設定するための第２の画面を表示する手段及び方法を含む。そして、所定の条件により前記視聴予約ができないことを示す第３の画面を表示する手段及び方法も含むものである。

また該装置は、視聴予約の取消しを行うか否かを問い合わせするための第４の画面を表示する手段と、前記第４の画面を利用して所定の入力操作がなされた場合、前記視聴予約を取り消すための第５の画面を表示する手段及び方法も含む。

本発明のいくつかの実施形態を説明したが、これらの実施形態は例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。

１０００・・・放送局、１１００・・・放送局サーバ、１２００・・・セキュリティー装置、２１００・・・放送波伝送路、２２００・・・ハイブリッドキャスト伝送路、３０００・・・サービス業者装置、３１００・・・サービス毎のサーバ、３２００・・・アプリケーションデータベース、５０００・・・受信機、５００１・・・記憶媒体、５００２・・・表示器、５００３・・・スピーカシステム、７０００・・・連携端末。

Claims (4)

1. 受信装置がデジタル放送に関連するＨＴＭＬ文書に埋め込まれたアプリケーションの関数を用い、ハイブリッドキャスト方式に準拠して、放送番組の録画予約又は録画予約取り消しを行えるように放送波を送信し受信する送信受信システムであって、
   送信装置は、
   前記ＨＴＭＬ文書には、前記ハイブリッドキャスト方式に準拠するか否かをチェックすることに利用可能な情報を含める手段、
   前記関数には、受信側で前記録画予約又は録画予約取り消しを設定するか否かユーザに問合せすることに利用可能な第１の関数を含める手段、
   さらに前記関数には、前記受信側で前記録画予約又は録画予約取り消しを設定することに利用可能な第２の関数も含める手段を備え、
   前記受信装置は、
   前記ハイブリッドキャスト方式に準拠するか否かをチェックすることに利用可能な情報を用いて前記ハイブリッドキャスト方式に準拠するか否かを装置内でチェックする手段、
   前記チェック結果が前記ハイブリッドキャスト方式に準拠する場合に前記第１の関数、前記第２の関数を取得することで、
   前記録画予約又は録画予約取り消しを設定するか否かユーザに問合せすることに利用可能な前記第１の関数を用いて前記録画予約又は録画予約取り消しを設定するか否か問合せする手段、
   前記録画予約又は録画予約取り消しを設定することに利用可能な前記第２の関数を用いて前記録画予約又は録画予約取り消しを設定する手段を備える、
   送信受信システム。
2. 受信装置がデジタル放送に関連するＨＴＭＬ文書に埋め込まれたアプリケーションの関数を用い、ハイブリッドキャスト方式に準拠して、放送番組の録画予約又は録画予約取り消しを行えるように放送波を送信し受信する送信受信方法であって、
   送信装置が、
   前記ＨＴＭＬ文書には、前記ハイブリッドキャスト方式に準拠するか否かをチェックすることに利用可能な情報を含め、
   前記関数には、受信側で前記録画予約又は録画予約取り消しを設定するか否かユーザに問合せすることに利用可能な第１の関数を含め、
   さらに前記関数には、前記受信側で前記録画予約又は録画予約取り消しを設定することに利用可能な第２の関数も含め、
   前記受信装置が、
   前記ハイブリッドキャスト方式に準拠するか否かをチェックすることに利用可能な情報を用いて前記ハイブリッドキャスト方式に準拠するか否かを装置内でチェックし、
   前記チェック結果が前記ハイブリッドキャスト方式に準拠する場合に前記第１の関数、前記第２の関数を取得することで、
   前記録画予約又は録画予約取り消しを設定するか否かユーザに問合せすることに利用可能な前記第１の関数を用いて前記録画予約又は録画予約取り消しを設定するか否か問合せし、
   前記録画予約又は録画予約取り消しを設定することに利用可能な前記第２の関数を用いて前記録画予約又は録画予約取り消しを設定する、
   送信受信方法。
3. 受信装置がデジタル放送に関連するＨＴＭＬ文書に埋め込まれたアプリケーションの関数を用い、ハイブリッドキャスト方式に準拠して、放送番組の録画予約又は録画予約取り消しを行えるように放送波を送信し受信する送信受信システムであって、
   送信装置は、
   前記ＨＴＭＬ文書には、前記ハイブリッドキャスト方式に準拠するか否かをチェックすることに利用可能な情報が含める手段を有し、
   前記関数に含まれる第１の関数が記述ToRecordを含む複数の関数の内の何れかの関数であり、
   前記関数に含まれる第２の関数が記述unscheduleToRecordを有する関数で記述され、
   前記関数に含まれる第３の関数が記述isscheduleToRecordを有する関数で記述され、
   前記受信装置は、
   前記ハイブリッドキャスト方式に準拠するか否かをチェックすることに利用可能な情報を用いて前記ハイブリッドキャスト方式に準拠するか否かを装置内でチェックする手段、
   前記チェック結果が前記ハイブリッドキャスト方式に準拠する場合に前記第１の関数、前記第２の関数及び前記第３の関数を取得することで、
   前記録画予約又は録画予約取り消しを設定するか否かユーザに問合せすることに利用可能な前記第１の関数を用いて前記録画予約又は録画予約取り消しを設定するか否か問合せする手段、
   前記録画予約又は録画予約取り消しを設定することに利用可能な前記第２の関数を用いて前記録画予約又は録画予約取り消しを設定する手段、
   録画予約済みか否かを確認するために利用可能な前記第３の関数を用いて前記録画予約を確認する手段を備えた、
   送信受信システム。
4. 受信装置がデジタル放送に関連するＨＴＭＬ文書に埋め込まれたアプリケーションの関数を用い、ハイブリッドキャスト方式に準拠して、放送番組の録画予約又は録画予約取り消しを行えるように放送波を送信し受信する送信受信方法にであって、
   送信装置は、
   前記ＨＴＭＬ文書には、前記ハイブリッドキャスト方式に準拠するか否かをチェックすることに利用可能な情報が含め、
   前記関数に含まれる第１の関数が記述ToRecordを含む複数の関数の内の何れかの関数であり、
   前記関数に含まれる第２の関数が記述unscheduleToRecordを有する関数で記述され、
   前記関数に含まれる第３の関数が記述isscheduleToRecordを有する関数で記述され、
   前記受信装置は、
   前記受信装置が前記ハイブリッドキャスト方式に準拠するか否かをチェックすることに利用可能な情報を用いて前記ハイブリッドキャスト方式に準拠するか否かを装置内でチェックし、
   前記チェック結果が前記ハイブリッドキャスト方式に準拠する場合に前記第１の関数、前記第２の関数及び前記第３の関数を取得することで、
   前記録画予約又は録画予約取り消しを設定するか否かユーザに問合せすることに利用可能な前記第１の関数を用いて前記録画予約又は録画予約取り消しを設定するか否か問合せし、
   前記録画予約又は録画予約取り消しを設定することに利用可能な前記第２の関数を用いて前記録画予約又は録画予約取り消しを設定し、
   録画予約済みか否かを確認するために利用可能な前記第３の関数を用いて前記録画予約を確認する、送信受信方法。

Images