JP4474320B2 - デジタル放送受信装置及びデジタル放送受信装置の制御方法 - Google Patents

Description

本発明は、デジタル放送受信装置及びデジタル放送受信装置の制御方法に関し、特に、デジタルデータ放送を受信するデジタル放送受信装置における印刷処理に用いて好適なものである。

近年、一般家庭内における多くの家庭電化製品は、デジタル化が進み、ネットワーク化されてきている。
ＴＶ（Television）装置においてもデジタル放送の開始とともにデジタル情報制御装置、例えば、デジタル放送用テレビ（Digital Television、以下ＤＴＶと称する）が普及してきている。このＤＴＶを用いて、ネットワークに接続したり、ネットワークルータを介してインターネットに接続したりして、ＤＴＶのテレビ画面に、ＷＥＢの内容を表示して利用されるまでになってきている。
ＤＴＶを取り巻く環境は、デジタル放送系の放送局及び番組の拡充、データ放送系のコンテンツの拡充、ＤＴＶの各種マルチメディアへの対応、及び前述したＤＴＶのインターネットへの対応等により、ユーザへ提供される情報量が確実に増加してきた。そこで、それらの情報を簡単に印刷出力して情報を保存する技術が望まれてきている。
このようにしてＤＴＶ等の家庭用デジタル情報機器で受信した情報をプリンタで印刷出力する際には、家庭用デジタル情報機器で印刷データを一時的に保持（スプール）し、プリンタの印刷状況に合わせてスプールした印刷データをプリンタに出力する必要がある。プリンタの方が、家庭用デジタル情報機器より処理速度が遅いからである。

ネットワークを介した印刷システムのプロトコルとして、ＩＰＰ（Internet Printing Protocol）が普及してきた。このＩＰＰには、印刷ジョブを要求する際に、印刷データを渡す代わりに印刷データの所在を示すＵＲＩ（Uniform Resource Identifier）をクライアントホストからネットワークプリンタに渡すPrint-URIリクエストが規定されている。

このPrint-URIリクエストを用いた技術として、ネットワークプリンタからのPrint-URIリクエストを受け取った印刷制御装置であるＩＰＰサーバが、FTP GETメソッド又はHTTP GETメソッドを用いて印刷データをネットワークプリンタに送信する技術が提案されている（特許文献１を参照）。

一方、情報家電の普及や、事務機のネットワーク対応に伴い、家庭内や小規模オフィスのネットワーク化が進んでいる。家庭内や小規模オフィスといった管理されないネットワークにおいてネットワーク機器の制御を行うために、ＵＰｎＰ（Universal Plug and Play）が提案されている。このＵＰｎＰの標準プリントサービスであるPrintBasicサービスにおいても、印刷データが存在するＵＲＩをネットワークプリンタに引き渡して行われるＰＵＬＬ印刷が可能になっている。十分なリソースを持たない家庭用のネットワークプリンタにおいて、複数の印刷ジョブの要求を受け付け、キューイング（queuing）しなければならない場合などは、必要なときにプリンタが印刷をとりにいけばよいＰＵＬＬ印刷は非常に好都合である。

そこで、プリンタが、家庭用デジタル情報機器にスプール機能があるか否かを確認し、家庭用デジタル情報機器にスプール機能がある場合は、印刷データのスプール先を家庭用デジタル情報機器に設定し、家庭用デジタル情報機器にスプール機能がない場合は、印刷データのスプール先をプリンタ側に設定する技術が提案されている（特許文献２を参照）。

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

しかしながら、前述した特許文献１に記載の技術では、Print-URIリクエストを行うクライアントホストは、ＨＴＴＰサーバないしＦＴＰサーバが管理するディレクトリに印刷データのファイルを置き、そのファイルを参照するＵＲＩを生成してこれをネットワークプリンタに送ってPrint-URIリクエストを行う。このため、予め印刷データを生成しておく必要があった。情報家電のように十分なリソースを持たない電子機器においては、予め印刷データを生成しておくことは、印刷以外の処理を行う上で負荷になるという問題点があった。

また、前述した特許文献２に記載した技術でも、ＤＴＶ等の家庭用デジタル情報機器で受信した情報を印刷できるシステムには限定条件が多い。 デジタル情報制御装置、特に、ＤＴＶのようなデジタル放送用出力装置では、ＣＰＵの処理やメモリ等のリソースをデジタル放送の表示処理に割り当てることが要求されるため、印刷機能や印刷処理に関わる負荷をなるべく押さえる傾向がある。そのため、印刷だけのための特別なリソースはＤＴＶにほとんど与えられない。従って、デジタル情報機器は印刷データのスプール機能を備えていないことが多く、大半の印刷処理はプリンタ側で行われることが一般的である。よって、特許文献２の技術では、プリンタは、デジタル情報機器にはスプール機能を備えていないと判断し、プリンタ側でスプール処理を行う。

このような状況において、ＤＴＶで受信した番組内の情報に基づく静止画像データをプリンタに転送して印刷する場合、ＤＴＶは、自身でスプール機能を備えていないため、プリンタでの印刷処理と並行して静止画像データの出力を行うことになる。よって、ＤＴＶは、プリンタで静止画像データの印刷処理が終わるまで静止画像データの生成と送信処理を行うため、他の処理を行いたい場合もプリンタでの印刷処理が終わるまで待たなければならないという問題が発生する。

本発明は、前述の問題点に鑑みてなされたものであり、画像形成装置に画像の形成（印刷）を要求するデジタル放送受信装置の負荷を可及的に低減させるようにすることを目的とする。

本発明のデジタル放送受信装置の制御装置は、カルーセル方式により繰り返し放送されるデジタルデータ放送に含まれる印刷用文書データを用いて、通信可能に接続された画像形成装置に送信する印刷データを生成するデジタル放送受信装置であって、前記デジタルデータ放送に含まれる、データ放送画面を表示するための表示用文書データと印刷に利用される印刷用文書データとを取得し、記憶部に格納する取得手段と、前記表示用文書データを用いてデータ放送画面を表示する表示手段と、前記表示手段で表示されたデータ放送画面を介して、ユーザから印刷用文書データの印刷処理の実行を指示する印刷指示を受け付けたことに応じて、前記画像形成装置に印刷要求を発行する印刷要求手段と、前記印刷要求手段により前記画像形成装置に印刷要求を発行した後、前記記憶部に格納されている前記印刷用文書データを削除する制御を行う制御手段と、前記印刷要求に応答して前記画像形成装置から送信された印刷データの配信要求を受け付ける受付手段と、前記デジタルデータ放送に含まれる印刷用文書データから前記画像形成装置が解釈可能な印刷データを生成し、前記画像形成装置に送信する印刷データ出力手段と、を有し、前記取得手段は、前記受付手段により配信要求を受け付けた後に、受信中のデジタルデータ放送に含まれる印刷用文書データを当該デジタルデータ放送から再び取得し、前記印刷データ出力手段は、前記取得手段により再び取得された印刷文書データから前記画像形成装置が解釈可能な印刷データを生成し、前記画像形成装置に送信することを特徴とする。

本発明のデジタル放送受信装置の制御方法は、カルーセル方式により繰り返し放送されるデジタルデータ放送に含まれる印刷用文書データを用いて、通信可能に接続された画像形成装置に送信する印刷データを生成するデジタル放送受信装置の制御方法であって、前記デジタルデータ放送に含まれる、データ放送画面を表示するための表示用文書データと印刷に利用される印刷用文書データとを取得し、記憶部に格納する第１の取得ステップと、前記表示用文書データを用いてデータ放送画面を表示部に表示する表示ステップと、前記表示ステップで表示されたデータ放送画面を介して、ユーザから印刷用文書データの印刷処理の実行を指示する印刷指示を受け付けたことに応じて、前記画像形成装置に印刷要求を発行する印刷要求ステップと、前記印刷要求ステップにより前記画像形成装置に印刷要求を発行した後、前記記憶部に格納されている前記印刷用文書データを削除する制御を行う制御ステップと、前記印刷要求に応答して前記画像形成装置から送信された印刷データの配信要求を受け付ける受付ステップと、前記受付ステップにより配信要求を受け付けた後に、受信中のデジタルデータ放送に含まれる印刷用文書データを当該デジタルデータ放送から再び取得する第２の取得ステップと、前記第２の取得ステップにより再び取得された印刷用文書データから前記画像形成装置が解釈可能な印刷データを生成し、前記画像形成装置に送信する印刷データ出力ステップと、を有することを特徴とする。

本発明によれば、デジタル放送受信装置が行う処理の負荷が、印刷用文書データの保管や準備によって増大することを可及的に防止することができる。

以下、図面を参照しながら本発明に係る実施形態を詳細に説明する。
（第１の実施形態）
図１は、本実施形態におけるネットワークシステムの構成の一例を示した図である。
図１において、ホストとして動作するデジタル情報制御装置（ホスト機器）としては、ＤＴＶ１０１、セットトップボックス（ＳＴＢ）１０２、及びパーソナルコンピュータ（ＰＣ）１０３等がある。これらのデジタル情報制御装置は、デジタル放送、データ放送を受信して表示部に放送内容を表示することが可能なデジタル放送出力装置である。これらホストとして動作する機器と、画像形成装置の一種である印刷装置として動作するネットワークプリンタ（Network Printer）１０４は、イーサネット（登録商標）１１０を介してお互いに通信可能な状況となっている。また、このイーサネット（登録商標）１１０に繋がった各機器は、ブロードバンドルータ（Router）１０５を介してインターネット（Internet）１０８へ接続することも可能となる。よって、イーサネット（登録商標）１１０に繋がった各機器は、ＷＥＢサーバ（WWW Server）１０９に格納されているコンテンツデータを任意にブラウジング（browsing）することが可能である。

図２は、本実施形態における画像形成システムの構成の一例を示した図である。この画像形成システムは、図１に示したネットワークシステムの一部を構成する。
図２において、本実施形態における画像形成システムでは、ホスト機器として、処理パフォーマンスの高いパーソナルコンピュータ１０３を使用せずに、デジタル放送を受信して表示部に放送を表示する機能を有するデジタル情報機器であるＤＴＶ１０１を使用する。すなわち、本実施形態における画像形成システムは、ＤＴＶ１０１とネットワークプリンタ１０４とが１対１に接続されたシステム構成となる。よって、ホスト機器としてパーソナルコンピュータ１０３を使用した場合にホスト側で一般的に行われる、プリンタドライバを用いた印刷データの生成は行われない。すなわち、ホスト機器であるＤＴＶ１０１は、デジタル放送またはデータ放送に含まれる印刷用コンテンツデータ２０４をＸＨＴＭＬ形式の言語で生成して、その印刷用コンテンツデータ２０４を、ネットワークプリンタ１０４で解釈して印刷を行う。

このような本実施形態における画像形成システムの概略動作の一例を説明する。
まず、ＤＴＶ１０１は、ＸＨＴＭＬ形式の言語で記述された印刷用コンテンツデータ（Contents data）２０４をイーサネット（登録商標）１１０を経由してネットワークプリンタ１０４に送信する。ネットワークプリンタ１０４は、入力された印刷用コンテンツデータ２０４を解釈して印刷用イメージデータ（Image data）２０５を生成するネットワークコントローラ（Network Controller）２０１と、印刷用イメージデータ２０５に基づき印刷メディア（Print Media）２０３上に画像を形成するための画像データ（Image data）２０６を出力するプリンタコントローラ（Printer Controller）２０２とを用いて、印刷処理を実行する。

図３は、ネットワークコントローラ２０１が有する機能モジュールの概略構成の一例を示す図である。以下に、ネットワークコントローラ２０１を構成する各機能モジュールについて説明する。
図３において、インターフェイス（Interface）部３０１は、ホスト装置であるＤＴＶ１０１等から送られてきた印刷用コンテンツデータ２０４を取り込み、パース（Parse）処理部３０２に引き渡すモジュールである。この他、インターフェイス部３０１は、プリントエンジンから、用紙切れやインク切れなどの印刷状況を取得し、取得した印刷状況に基づくステータス情報（Printer Status Information）３１０をホスト装置に通知する機能も持ち合わせている。

パース処理部３０２は、ＸＨＴＭＬ形式の言語で記述されたコンテンツデータ２０４の構文を解析するモジュールである。コンテンツデータ２０４は「個別のファイル形式」またはパッケージングした「一括モジュール形式」として入力される。

レイアウト（Layout）処理部３０３は、パース処理部３０２で解析された構文情報を、印刷オブジェクトの配置情報データとして作成するモジュールである。
フォント（Font）処理部３０４は、コンテンツデータ２０４によって指定されたフォントデータ（Font Data）３０８の作成及び管理を行うモジュールである。この他、フォント処理部３０４は、配置情報データを作成するためにレイアウト処理部３０３がフォント情報（Font Information）３０９を取得する際にも呼び出される。

イメージング（Imaging）処理部３０５は、印字オブジェクトにおける画像データ（例えばＪＰＥＧ形式データ）をＲＧＢビットマップデータにデコードしたり、画像データのサイズを調整するために解像度を変換したりするモジュールである。
バンディング（Banding）処理部３０６は、描画領域を複数のバンドに分割して、次段のレンダリング（Rendering）処理部３０７にバンド単位での描画処理を行わせるモジュールである。

レンダリング（Rendering）処理部３０７は、レイアウト処理による配置情報データに基づいて描画処理を行い、その結果としてカラー画像の各色成分画素を多値データで構成した印刷用イメージデータ２０５を出力するモジュールである。

図４は、プリンタコントローラ２０２が有する機能モジュールの概略構成の一例を示す図である。以下に、プリンタコントローラ２０２を構成する各機能モジュールについて説明する。なお、本実施形態では、ネットワークプリンタ１０４として、インクジェット方式のプリンタを用いた場合を例に挙げて説明する。また、ネットワークプリンタ１０４側では高度な画像処理は行わないようにする。このようにすることで、メモリ空間を確保し、確保したメモリ空間上に印刷用イメージデータ２０５を展開し、展開した印刷用イメージデータ２０５をネットワークプリンタ１０４で直接印刷できる形態に変換してプリンタエンジンに送り、印刷することになる。

図４において、プリンタ制御実行部４０１は、ネットワークプリンタ１０４の統括制御を司るモジュールであり、画像処理部４０２や出力制御部４０３の動作を管理したり、印刷実行状況に基づくステータス情報３１０をネットワークコントローラ２０１に出力したりしている。

画像処理部４０２は、入力された印刷用イメージデータ２０５をプリンタエンジン４０４への出力形式に合わせて多値ＲＧＢから２値ＹＭＣＫに変換する処理を行うモジュールである。この多値ＲＧＢから２値ＹＭＣＫに変換する処理と、２値ＹＭＣＫに変換した印刷用イメージデータ２０５をプリンタエンジン４０４へ出力する処理では、バンディング処理部３０６によってメモリ空間が最適に利用される。一方、プリンタコントローラ２０２に十分大きな容量のメモリが実装されている場合は、１ページ分の印刷用イメージデータ２０５を展開することが可能な領域を確保しても構わない。

出力制御部４０３は、画像処理部４０２で２値ＹＭＣＫに変換されて出力された印刷用イメージデータ２０５の各色データを、プリンタエンジン４０４に実装されたインクジェット用ヘッドの駆動パターンに合わせて順次出力するモジュールである。

プリンタエンジン４０４は、出力制御部４０３から出力された印刷用イメージデータ２０５に合わせてインクを吐出するヘッドと、ヘッドが装着されたキャリア部を走査するキャリッジ機構と、印刷メディア２０３の搬送に用いるペーパーフィード機構とを備えて構成されたプリンタ可動部を有する。

図５は、ネットワークコントローラ２０１の内部構成の一例を示したブロック図である。
図５において、ネットワークコントローラ２０１は、ネットワークコントローラ２０１の主たる制御を司るＣＰＵ５０１と、受信した印刷用コンテンツデータ２０４を一時的に取り込むためのバッファメモリやワークメモリとして使用するＤＲＡＭ５０２と、イーサネット（登録商標）１１０に接続されたホスト装置との通信を行うネットワーク・インターフェイス・コントローラ（ＮＩＣ）５０５と、実行プログラムが書き込まれたプログラムＲＯＭ５０３と、フォントデータ３０８が書き込まれたフォントＲＯＭ５０４と、シリアルインターフェイス（シリアルＩ／Ｆ）５０７を介したプリンタコントローラ２０２との通信に用いられるシリアルＩ／Ｏ（ＳＩＯ）５０６とが、内部バス５０８によって相互に接続された構成となっている。

図６は、プリンタコントローラ２０２の内部構成の一例を示したブロック図である。
図６において、プリンタコントローラ２０２は、プリンタコントローラ２０２の主たる制御を司るＰ−ＣＰＵ６０１と、受信した画像データ２０６を一時的に取り込むためのバッファメモリやワークメモリとして使用するＰ−ＤＲＡＭ６０２と、実行プログラムが書き込まれたＰ−ＲＯＭ６０３と、シリアルＩインターフェイス５０７を介して接続されたネットワークコントローラ部２０１と通信を行うＰ−ＳＩＯ６０４とが、内部バス６１２を介してプリンタエンジンコントローラ部６０５と接続されている。また、プリンタエンジンコントローラ部６０５には、印刷機構部のインクジェットヘッド６０７を駆動するヘッドドライバ６０６と、キャリッジモータ（ＣＲモータ）６０９を駆動するモータドライバ６０８と、ペーパーフィードモータ（ＰＦモータ）６１１を駆動するモータドライバ６１０とがさらに接続されている。

（ＵＰｎＰ（Universal Plug and Play）の概要）
本実施形態のネットワークシステムでは、ＤＴＶ１０１からネットワークプリンタ１０４を制御するために、ＵＰｎＰ（Universal Plug and Play）を用いている。そこで、以下に、ＵＰｎＰの概要について説明する。
ＵＰｎＰネットワークは、ＩＰアドレスの設定やデバイスドライバのインストールなどの煩雑な設定を行わなくても、ネットワーク機器を接続することができるピアツーピアネットワークである。ここでは、ＵＰｎＰネットワークの基本構成、プロトコル、及び実行ステップについてその概要を説明する。詳細についてはそれぞれの規格のドキュメントに記載されている。

ＵＰｎＰネットワークの基本構成として、デバイス、サービス、及びコントロールポイントが定義されている。デバイスは、ＵＰｎＰに対応した機器であり、プリンタ、ブロードバンド（Broadband）ルータ（インターネット・ゲートウェイ・デバイス）１０５などが、これにあたる。サービスは、デバイスが提供する機能を表す最小単位であり、例えば、デバイスがUPnP Forumにより定義されたプリンタ（Printer）デバイスであれば、PrintBasicサービスが提供される。コントロールポイントは、デバイスが持っているサービスを制御して、利用するものであり、ＤＴＶ１０１、ＰＣ１０３やＳＴＢ１０２などがこれにあたる。
デバイスは、少なくとも１つのサービスを持つ。また、デバイスは内部に埋め込みデバイスを持つことができる。ベースとなるデバイスをルートデバイスという。

図７は、ＵＰｎＰネットワークの基本構成の一例を示すブロック図である。
図７において、コントロールポイント７１０及びデバイス７２０が、ネットワーク７００に接続されている。デバイス７２０は、サービス７２１と、埋め込みデバイス７２２とを持つ。埋め込みデバイス７２２はサービス７２３を持つ。
ＵＰｎＰネットワークでは、ＴＣＰ／ＩＰを基礎とし、HTTP（Hypertext Transfer Protocol）や、ＸＭＬ（Extensible Makeup Language）を利用してメッセージを配信する。ＵＰｎＰネットワークにおけるデバイス２００は、ＴＣＰ（Transmission Control Protocol）、ＵＤＰ（User Datagram Protocol）、ＩＧＭＰ（Internet Group Management Protocol）、及びＡＲＰ（Address Resolution Protocol）など、ＴＣＰ／ＩＰスタックのプロトコルを使用できる。また、デバイス２００は、ＤＨＣＰ（Dynamic Host Configuration Protocol）やＤＮＳ（Domain Name System）などのＴＣＰ／ＩＰサービスを利用できる。ＴＣＰ／ＩＰを採用したことによりＵＰｎＰは、ネットワークの物理メディアから独立になっている。

図８は、ＵＰｎＰのプロトコルスタックの一例を示す図である。
図８において、ＨＴＴＰＵと、ＨＴＴＰＭＵは、ＨＴＴＰをＵＤＰへ拡張したものである。プロトコルで使用する基本メッセージ形式はＨＴＴＰである。ＨＴＴＰＵはユニキャスト通信を用い、ＨＴＴＰＭＵはマルチキャスト通信を用いる。

ＳＳＤＰ（Simple Service Discovery Protocol）は、ネットワークサービスを検出する方法を定義している。ＳＳＤＰは、ＨＴＴＰＵ及びＨＴＴＰＭＵに基づいて作成されており、コントロールポイント７１０が関心のあるサービスを検出する方法と、デバイス７２０がそのサービスを告知する方法とを定義している。

ＧＥＮＡ（Generic Event Notification Architecture）は、ＨＴＴＰおよびＨＴＴＰＭＵを使用して通知を送受信する機能である。イベントを可能にするために通知のサブスクライバーや、パブリッシャーの概念を定義している。

ＳＯＡＰ（Simple Object Access Protocol）は、ＲＰＣ(Remote Procedure Call）を実行するためのＸＭＬとＨＴＴＰの仕様を定義している。コントロールポイント７１０は、ＳＯＡＰを使用してデバイス７２０の制御を行う。

プロトコルスタックの最上位は、ベンダ（Vender）に固有の情報を持つメッセージである。その次は、ＵＰｎＰフォーラムのワーキングコミッティー（ＷＣ）で定義された情報により補足されたメッセージである。上位のメッセージは、ＳＳＤＰや、ＧＥＮＡなど、ＵＰｎＰに固有のプロトコルに従ったＨＴＴＰメッセージ形式でＩＰアドレスに配信される。

次に、ＵＰｎＰの実行ステップについて説明する。ＵＰｎＰは、アドレッシング、ディスカバリ、ディスクリプション、コントロール、イベンティング、及びプレゼンテーションの６つのステップで実行される。以下、各ステップについて説明する。

＜アドレッシング＞
このステップでは、ＵＰｎＰが基本とするＴＣＰ／ＩＰでの通信が可能になるようにＩＰアドレスの割り当てを行う。ＵＰｎＰデバイスは、少なくともＤＨＣＰ（Dynamic Host Configuration Protocol）クライアントを実装しなければならない。デバイス７２０がはじめてネットワーク７００に接続したときは、ＤＨＣＰサーバを探してアドレスを取得する。ＤＨＣＰサーバが見つからない場合は、デバイス７２０は、Ａｕｔｏ−ＩＰを使ってアドレスを取得しなければならない。

Ａｕｔｏ−ＩＰは、ＩＡＮＡが定めるＬｉｎｋ−ｌｏｃａｌアドレス（ＩＰ Ｖｅｒｓｉｏｎ ４では１６９．２５４／１６）の範囲でランダムにアドレスを生成し、生成したアドレスがすでに使用されていないかどうかの確認と、そのアドレスの使用のアナウンスとを、ＡＲＰ（Address Resolution Protocol）を使って行うものである。デバイス７２０は、Ａｕｔｏ−ＩＰでＩＰアドレスを取得した場合、定期的にＤＨＣＰサーバを探して、見つかればＤＨＣＰサーバからアドレスを取得する。

＜ディスカバリ＞
ＩＰアドレスの割り当てが終わるとディスカバリを行う。ネットワーク７００に追加されたデバイス７２０は、ＵＰｎＰのディスカバリプロトコルを使ってデバイス７２０が持つサービス７２１の告知を行う。同様にネットワーク７００に追加されたコントロールポイント７１０は、デバイス７２０のサーチを行う。

例えば、デバイス７２０は、ＩＡＮＡがＳＳＤＰのために割り当てたマルチキャストアドレス：ポート２３９．２５５．２５５．２５０：１９００にＵＤＰマルチキャストパケットを送信して告知を行う。図１に示した例では、ＵＰｎＰデバイスであるネットワークプリンタ１０４が告知を行い、コントロールポイントであるＤＴＶ１０１、ＳＴＢ１０２、及びＰＣ１０３がこれを受信することになる。

図９（ａ）は、デバイス７２０がネットワーク７００に追加され利用可能なことを示す告知パケット９０１の一例を示す図である。
告知パケット９０１は、ＨＴＴＰＭＵを介して送信される。リクエストには、ＧＥＮＡのＮＯＴＩＦＹメソッドを用いている。ＮＴＳヘッダは、「ｓｓｄｐ：ａｌｉｖｅ」でなければならない。その他、ヘッダには、告知の有効時間、デバイスディスクリプションＵＲＬ、告知のタイプ、及びサービスの固有名などが含まれている。メッセージのボディはなく空白行のみである。

図９（ｂ）は、デバイス７２０がネットワーク７００から削除されつつあり利用できなくなることを示す告知パケット９０２の一例を示す図である。リクエストにはＧＥＮＡのＮＯＴＩＦＹメソッドを用いている。ＮＴＳヘッダは、「ｓｓｄｐ：ｂｙｅｂｙｅ」でなければならない。

また、コントロールポイント７１０がＵＰｎＰのディスカバリプロトコルを使ってサーチを行い、デバイス７２０がこのサーチに応答する場合、コントロールポイント７１０は、ＩＡＮＡがＳＳＤＰのために割り当てたマルチキャストアドレス：ポート２３９．２５５．２５５．２５０：１９００にＵＤＰマルチキャストパケット（サーチリクエストパケット）を送信する。デバイス７２０は、ＵＤＰマルチキャストパケットに対し、ＵＤＰユニキャスト（サーチレスポンスパケット）で応答する。図１に示した例では、コントロールポイントであるＤＴＶ１０１が、ＵＰｎＰデバイスであるネットワークプリンタ１０４のサーチを行い、ネットワークプリンタ１０４がそのサーチに応答することになる。

図１０（ａ）は、サーチリクエストパケット１００１の一例を示す図である。
サーチリクエストパケット１００１は、ＨＴＴＰＭＵを介して送信される。リクエストには、Ｍ−ＳＥＡＲＣＨメソッドを用いている。ＭＡＮヘッダは、「ｓｓｄｐ：ｄｉｓｃｏｖｅｒ」でなければならない。ＳＴヘッダはサーチターゲットである。メッセージボディはなく空白行のみである。

図１０（ｂ）は、サーチレスポンスパケット１００２の一例を示す図である。サーチレスポンスパケット１００２は、ＨＴＴＰＵを介して送信される。レスポンスには告知の有効時間、デバイスディスクリプションＵＲＬ、サーチターゲット、及び告知のサービス固有名などが含まれる。

＜ディスクリプション＞
ディスクリプションは、コントロールポイント７１０がディスカバリでデバイス７２０を見つけた後に行われる。このステップの後に、他のステップ（コントロール、イベンティング、及びプレゼンテーション）を実行することが可能になる。

図１１（ａ）は、ディスクリプションを行う際のコントロールポイント７１０とデバイス７２０との様子を概念的に示した図である。このディスクリプションでは、コントロールポイント７１０がディスクリプションリクエスト１１１１ａ〜１１１１ｃを送信し、デバイス７２０がデバイスディスクリプション１１１２ａ、及びサービスディスクリプション１１１３ａ、１１１３ｂを応答する。コントロールポイント７１０は、ディスカバリによりデバイス７２０のデバイスディスクリプションＵＲＬを取得した後、デバイス７２０に対してディスクリプションタリクエスト１１１１ａ、１１１１ｂを送信する。

図１１（ｂ）は、ディスクリプションリクエスト１１０１（ディスクリプションリクエスト１１１１ａ〜１１１１ｃ）の一例を示す図である。
ディスクリプションリクエスト１１０１は、ＨＴＴＰ ＧＥＴメソッドを用いて送信される。
図１１（ｃ）は、ディスクリプションレスポンス１１０２（デバイスディスクリプション１１１２ａ及びサービスディスクリプション１１１３ａ、１１１３ｂ）の一例を示す図である。
ＨＴＴＰメッセージのボディは、ＸＭＬで記述されたディスクリプションである。ＵＰｎＰにおけるディスクリプションレスポンスには、デバイスディスクリプション１１１２ａとサービスディスクリプション１１１３ａ、１１１３ｂの２種類がある。

デバイスディスクリプション１１１２ａには、デバイス７２０が持つサービス７２１のリストが含まれている。また、デバイスディスクリプション１１１２ａには、各サービス７２１のサービスディスクリプションＵＲＬ、コントロールＵＲＬ、及びイベンティングＵＲＬなどが含まれる。さらに、デバイス７２０に埋め込まれたデバイス７２２がある場合には、そのデバイス７２２のリストも含まれる。

サービスディスクリプション１１１３ａ、１１１３ｂには、サービス７２１、７２３をコントロールするためのアクションリストと、サービスの状態を示すサービスステータステーブルとが含まれる。アクションリストには、各アクションの、名前、引数、関連する状態変数、及び入出力の方向が記述されている。サービスステートテーブルには、各状態変数の、名前、型、範囲、及びイベント特性が記述されている。

コントロールポイント７１０は、デバイスディスクリプション１１１２ａを取得した後、そこに含まれる各サービスディスクリプションＵＲＬへアクセス（HTTP GET）することにより、各サービスディスクリプション１１１３ａ、１１１３ｂを取得する。サービスディスクリプション１１１３ａ、１１１３ｂを取得した後、コントロールポイント７１０は、デバイス７２０の各サービスをコントロールしたり、状態を表示したりできるようになる。

＜コントロール＞
コントロールでは、コントロールポイント７１０がデバイス７２０の持つサービス７２１にリクエストを行い、デバイス７２０を制御する。
図１２（ａ）は、コントロールポイント７１０がデバイス７２０をコントロールする様子を概念的に示した図である。

コントロールポイント７１０は、ディスクリプションで、デバイス７２０のデバイスディスクリプション１１１２ａと、サービスディスクリプション１１１３ａ、１１１３ｂを取得した後、デバイス７２０をコントロールすることができる。コントロールポイント７１０ができることは、アクションの実行（アクションリクエスト１２１１の送信）と、アクションの結果の取得（アクションレスポンス１２１２の受信）と、状態変数のクエリの実行（クエリリクエスト１２１３の送信）と、状態変数の現在値の取得（クエリレスポンス１２１４の受信）とを行うことである。

ＵＰｎＰのコントロールにはＳＯＡＰを使用する。ＳＯＡＰはＲＰＣ(Remote Procedure Call)の実現のためにＸＭＬ／ＨＴＭＬの使用に関して定義している。コントロールメッセージはＳＯＡＰヘッダおよびボディエレメントをベースにフォーマットされＨＴＴＰを介して配信される。
コントロールポイント７１０は、デバイス７２０のデバイスディスクリプションから取得したコントロールＵＲＬへ、ＨＴＴＰ ＰＯＳＴないしＭ−ＰＯＳＴメソッドを用いてリクエストを送信する。

図１２（ｂ）は、アクションリクエスト１２１１の一例を示す図である。この例では、リクエストラインにはＰＯＳＴメソッドを用いている。ＣＯＮＴＥＮＴ−ＴＹＰＥは、「ｔｅｘｔ／ｘｍｌ」である。また、「ｃｈａｒｓｅｔ＝"ｕｔｆ−８"」でなければならない。ＳＯＡＰＡＣＴＩＯＮにアクション名を含む。メッセージボディは、ＸＭＬで記述され、ＳＯＡＰで定義されたＥｎｖｅｌｏｐｅエレメントを含み、そのサブエレメントボディにアクションや、引数などのサブエレメントが含まれる。

図１２（ｃ）は、アクションレスポンス１２１２の一例を示す図である。この例では、成功レスポンスの一例を示している。レスポンスラインにはＨＴＴＰ成功コードが含まれている。メッセージボディはＸＭＬで記述され、ＳＯＡＰで定義されたＥｎｖｅｌｏｐｅエレメントを含み、そのサブエレメントボディにアクションレスポンスサブエレメントが含まれる。アクションレスポンス１２１２には、アクションに出力引数があればその引数がサブエレメントとして含まれる。

＜イベンティング＞
イベンティングでは、コントロールポイント７１０が、デバイス７２０に状態変化の通知要求を登録し、デバイス７２０から通知を受ける。イベントのソースであるサービス７２１をパブリッシャーといい、イベントのターゲットであるコントロールポイント７１０をサブスクライバーと呼ぶ。サブスクライバーがイベントの通知を要求することをサブスクリプションと呼ぶ。

図１３（ａ）はイベンティングを行う際のコントロールポイント７１０、１３００とデバイス７２０との様子を概念的に示した図である。コントロールポイント７１０、１３００（サブスクライバー）は、ディスクリプションで取得したデバイス７２０のデバイスディスクリプション１１１２ａのイベンティングＵＲＬへＨＴＴＰリクエスト（イベンティングのリクエスト）を送信し、ＨＴＴＰレスポンス（イベンティングのレスポンス）を受信する。
イベンティングのリクエストには、イベントの通知要求を登録するサブスクリプションリクエスト１３１１、登録の期限が切れる前に登録の更新を要求する更新リクエスト１３１２、及び登録の期限が切れる前に登録の取りやめを要求するキャンセルリクエスト１３１３の３種類がある。

図１３（ｂ）は、サブスクリプションリクエスト１３１１の一例を示す図である。リクエストラインには、ＧＥＮＡに定義されたSUBSCRIBEメソッドを用いる。ヘッダには、イベントメッセージの送信先ＵＲＬや、通知タイプ「ＵＰｎＰ：ｅｖｅｎｔ」などが含まれる。メッセージのボディはなく空白行のみである。

図１３（ｃ）は、サブスクリプションレスポンス１３１４の一例を示す。ここでは、成功レスポンスの例を示す。レスポンスラインにはＨＴＴＰ成功コードが含まれる。ヘッダにはサブスクリブションを特定するＩＤや、サブスクリプションの有効時間などが含まれる。
サブスクリプションの更新リクエスト１３１２は、SUBSCRIBEメソッドを用いて、ヘッダにサブスクリプションＩＤを設定して行う。

サブスクリプションのキャンセルリクエスト１３１３は、UNSUBSCRIPTメソッドを用いてヘッダにサブスクリプションＩＤを設定して行う。

デバイス７２０のサービス７２１（パブリッシャー）は、サブスクリプションリクエスト１３１１に含まれるイベントメッセージの送信先ＵＲＬへのＨＴＴＰリクエストにより、サブスクライバーであるコントロールポイント７１０、１３００にイベントメッセージ１３１５ａ、１３１５ｂを送信する。イベントメッセージ１３１５ａ、１３１５ｂを受信したコントロールポイント（サブスクライバー）７１０、１３００は、ＨＴＴＰレスポンスをサービス（パブリッシャー）７２１に返す。

図１３（ｄ）は、イベントメッセージ１３１５の一例を示す図である。リクエストラインにはNOTIFYメソッドが用いられている。ヘッダには、「ＣＯＮＴＥＮＴ−ＴＹＰＥ：ｔｅｘｔ／ｘｍｌ」、「ＮＴ：ｕｐｎｐ：ｅｖｅｎｔ」、「ＮＴＳ：ｕｐｎｐ：ｐｒｏｐｃｈａｎｇｅ」、及び「ＳＩＤ：ｕｕｉｄ：＜ｓｕｂｓｃｒｉｐｔｉｏｎ ＩＤ＞」などが含まれる。メッセージボディはＸＭＬで記述される。Propertysetエレメントには、状態変数をサブエレメントに持つPropertyサブエレメントが必要なだけ含まれる。

＜プレゼンテーション＞
プレゼンテーションでは、デバイス７２０が持つＷｅｂサービスをブラウザに表示する。これによりＷｅｂページから、デバイスの制御や、サービスの状態表示ができる。
図１４は、ブラウザ１４００がデバイス７２０のプレゼンテーションページにアクセスする様子を概念的に示した図である。

図１４において、コントロールポイント７１０は、プレゼンテーションリクエスト１４１１をデバイス７２０に送信することによって、デバイス７２０のデバイスディスクリプションに含まれるプレゼンテーションＵＲＬを取得する。そうすると、ブラウザ１４００を使って、デバイス７２０のプレゼンテーションページ１４１２を表示することができる。ブラウザ１４００は、デバイス７２０のプレゼンテーションＵＲＬへアクセス（HTTP GET）することによりプレゼンテーションページ１４１２を取得する。デバイス７２０は、プレゼンテーションページ１４１２を介して、サービス７２１のコントロール手段、状態表示手段をコントロールポイント７１０に提供することができる。

（ＤＴＶ（デジタルテレビジョン）装置）
図１５は、ＤＴＶ１０１の内部構成の一例を示した機能ブロック図である。
図１５において、１５０１は、ＤＴＶ１０１の主たる制御を行うＣＰＵである。１５０２は、プログラム等が保存されている読み出し専用メモリであるＲＯＭである。１５０３は、データの一時的な保存を行うＲＡＭである。１５０５はアンテナである。１５０４は、アンテナ１５０５で受信した信号を取り込んで音声／映像／画像／データに復元するデジタル放送受信制御部である。

１５０６は、後述する表示／音響部１５０８のテレビ表示画面に操作ボタン等の操作用画面を表示したり、その操作用画面に連動した操作をリモコン（不図示）装置で行ったりするＵＩ処理（操作）部である。１５０７は、テレビ受像部や音響部等がある表示／音響部１５０８へ、音声／映像／画像／データを出力する出力処理部である。１５０９は、イーサネット（登録商標）１１０を介して相互に接続された外部のネットワークプリンタ１０４に所望の印刷を指示する印刷処理部である。

１５１０は、イーサネット（登録商標）１１０のネットワークラインと接続して外部との通信処理を行うネットワーク処理部である。１５１２は、メモリカード用コネクタであり、デジタルカメラ等で撮影した画像が保存されたメモリカード等を接続することにより、表示／音響部１５０８で画像の再生を行うことが出来る。１５２０は、前述した各処理ブロックを相互に接続するバスラインである。

図１６は、デジタル放送受信制御部１５０４でのデータ処理の流れの一例を概念的に示した図である。
外部放送局において、映像，画像、音声等のコンテンツデータは、MPEG-2方式により符号化、圧縮され、他のメディアと共に多重化されて、アンテナから発信される。衛星放送の場合は、さらに単一搬送波でＰＳＫ（Phase shift keying）変調がなされた後に、アンテナから発信される。この他、地上波デジタル放送、ＣＡＴＶにおけるコンテンツデータも外部放送局から発信される。

本実施形態のＤＴＶ１０１では、外部放送局から発信された電波（コンテンツデータ）をアンテナ１５０５で受信し、デジタル放送受信制御部１５０４へ取り込む。取り込んだ電波ＲＦは、復調（De-modulation）部１６０１へ運ばれて復調（De-modulation）される。そうすると、ＴＳ多重化ストリームであるMPEG-2 TS（Transport Stream）packet（MPEG-2 TSパケット）１６０２が得られる。

復号器（De-multiplex／De-scramble／De-code）１６０３では、ＴＳ多重化ストリーム１６０２が多重分離（De-multiplex）される。また、必要に応じて使用者が選択したチャネル情報に基づき番組番号が与えられて選局（De-scramble）される。こうして、ＴＳ多重化ストリーム１６０２は、映像データ１６０４、オーディオデータ１６０５、情報（ＰＳＩ／ＳＩテーブル）１６０６、及びＤＳＭ−ＣＣ（Digital Storage Media-Command and Control）１６０７へ各々分離され、分離された各々のデータ１６０４〜１６０７は、必要に応じてデコード（De-code）される。ＤＳＭ−ＣＣ１６０７は、蓄積オーディオ・ビジュアル・プリント・データを遠隔からアクセスするためのプロトコルを規定した情報であり、アクセス対象の情報の場所（ＵＲＬ）が記述される。

ここで、トランスポートストリームＴＳについて詳細に説明する。
図１７は、トランスポートストリームＴＳを概念的に示した図である。
図１７において、トランスポートＴＳは、ＴＳパケット１７０１ａ〜１７０１ｃの連続で構成され、それぞれのＴＳパケット１７０１ａ〜１７０１ｃのパケット長は、１８８ｂｙｔｅで固定である。
ＴＳパケット１７０１ａ〜１７０１ｃは、ＴＳヘッダ１７０２ａ、１７０２ｂとペイロード１７０３ａ、１７０３ｂとを備えて構成され、それぞれのペイロード１７０３ａ、１７０３ｂを繋ぎ合わせることで、ＰＥＳ（Packetized Elementary Stream）１７０４のペイロード部１７０５が構成される。

ＰＥＳ１７０４は、ペイロード部１７０５とＰＥＳヘッダ部１７０６とを備えて構成される。
ＰＥＳ１７０４のペイロード部１７０５は、後述するＴＳパケット１７０１内のＰＩＤ情報から同一のコンテンツに属するものであると判断されて結合される。
ＰＥＳ１７０４とは、ＭＰＥＧビデオデータや、オーディオデータといったコンテンツ要素となる情報がブロックに区切られたものに、ヘッダが追加されたものである。このため、ＰＥＳ１７０４から放送番組のコンテンツ情報を抽出できる。

図１８は、ＴＳパケット１７０１の構成を概念的に示した図である。
図１８において、ＴＳパケット１７０１は、４ｂｙｔｅのヘッダ部と、アダプテーションフィールド部及びペイロード部の少なくとも何れか一方を含む情報部１８０２とが合わさった１８８ｂｙｔｅのデータである。
ヘッダ部１８０１は、同期バイト部１８０１ａや、ＰＩＤ部１８０１ｂなどを備えて構成される。このＰＩＤ部１８０１ｂのＰＩＤとは識別符号であり、ＴＳパケットを識別する役割がある。

前記アダプテーションフィールド部には、同期処理時に使用されるＰＣＲ情報等の情報がある。
前記ペイロード部には、映像音声等の情報のほかにＰＳＩ（Program Specific Information）／ＳＩがある。ＰＳＩは、番組使用情報を示すテーブルとして送られてくる。

図１９は、ＰＳＩ１９０１を概念的に示した図である。
図１９に示すように、ＰＳＩ１９０１は番組仕様情報であり、受信したＴＳパケット１７０１の中の情報を示す。ＰＡＴ（Program Association Table）１９０２は、番組の種類を示す。ＰＭＴ（Program Map Table）１９０３は、映像、音声のＰＩＤとその復号方法を示す。ＮＩＴ（Network Information Table）１９０４は、ネットワーク上のサービス等の情報を示す。ＣＡＴ（Conditional Access Table）１９０５は、有料放送情報を示す。

このようなＰＳＩ１９０１に含まれる情報を基に、前述した復号器１６０３でトランスポートストリームＴＳから分離されたストリームデータから、選択チャネルに応じた番組情報が抽出され、出力処理部１５０７を介して表示／音響部１５０８へ出力される。

図２０は、ＴＳパケット１７０１から番組情報を抽出する際のデジタル放送受信制御部１５０４における処理動作の一例を説明するフローチャートである。
まず、ステップＳ２００１で、使用者のチャネル選択操作により番組番号が与えられる。次に、ステップＳ２００２では、受信したＴＳパケット１７０１に含まれるＰＳＩ１９０１から、ＰＡＴ１９０２及びＰＭＴ１９０３に関する情報を参照する。
次に、ステップＳ２００３では、番組構成要素のＰＩＤ値を取得する。次に、ステップＳ２００４では、ステップＳ２００３で取得した前記ＰＩＤ値を基に、ＴＳパケット１７０１を抽出して番組を組み立てる。
最後に、ステップＳ２００５では、ステップＳ２００４で抽出した番組のデータに対し、ビデオ／オーディオそれぞれのデコード処理を実行して処理を終了する。

次に、映像データ１６０４のデコードを行ってビデオデータを生成する処理について説明する。
図２１は、ＴＳパケット１７０１からビデオデータを選択する際の復号器１６０３における構成の一例を示した図である。
図２１において、２１０１はタイミング再生信号発生部であり、ＴＳパケット１７０１の情報部１８０２のアダプテーションフィールド部内にあるＰＣＲ情報２１０４を取り込む。
２１０２はバッファメモリであり、ＴＳパケット１７０１から抽出されたビデオパケット（ＰＥＳ）１７０４を一時的に保存する。
前記アダプテーションフィールド部に含まれているＰＣＲ情報２１０４で設定されたタイミングでタイミング再生信号発生部２１０１から信号がバッファメモリ２１０２に対して発行される。その発行されたタイミングで、ビデオパケット（ＰＥＳ）１７０４のデータがデコーダ２１０３へ送られる。デコーダ２１０３に送られたデータは、デコードされた後、ビデオデータ２１０５として出力される。

次に、データ放送サービスについて説明する。データ放送サービスは、電子番組ガイドや字幕スーパーなど、広い意味で用いられることもある。しかしながら、ここでは、ＢＭＬ（Broadcast Markup Language：デジタル放送中のコンテンツを表すマークアップ言語）に基づくマルチメディア放送サービスを例に挙げて説明する。

ＢＭＬは、日本のデジタルデータ放送のためにＸＭＬ（eXtensible Markup Language）をベースにＡＲＩＢ（Association of Radio Industries and Businesses）により開発された。データ放送は、放送波にＢＭＬ文書をのせて送信され、受信機で受信される。そして、受信機のＢＭＬブラウザで、受信したＢＭＬ文書を表示することにより、サービスを提供する。ＢＭＬの詳細については規格書に記載されている。

まず、データ放送のデータ伝送について説明する。データ放送するためのデータは、カルーセル伝送とイベントメッセージ伝送との２方式で伝送される。ここでは、データがカルーセル伝送される場合を例に挙げて説明する。カルーセル伝送は、ＤＳＭ−ＣＣ（Digital Storage Media Command and Control）ダウンロードカルーセルと呼ばれる方式であり、ＭＭＰＥＧ−２に関連する規格で規定されている。

図２２は、データ放送の伝送方式の一例を概念的に示す図である。
ＢＭＬコンテンツ２２０１は、図示しない制作装置（オーサリングシステム）で作成する。図２２に示す例では、２つのＢＭＬコンテンツ２２０１ａ、２２０１ｂがある。本実施形態では、ＢＭＬコンテンツ２２０１ａは、Ｆｉｌｅ１ａ、Ｆｉｌｅ１ｂ、及びＦｉｌｅ１ｃの３つのファイルからなる。また、ＢＭＬコンテンツ２２０１ｂは、Ｆｉｌｅ２ａ、及びＦｉｌｅ２ｂの２つのファイルからなる。例えば、Ｆｉｌｅ１ａはＢＭＬ文書であり、Ｆｉｌｅ１ｂは、ＢＭＬ文書であるＦｉｌｅ１ａに埋め込まれたＰＮＧファイルであり、Ｆｉｌｅ１ｃは、ＪＰＥＧファイルである。

カルーセル伝送を行う送信機２２０２は、伝送路２２０３を介して、これらのＦｉｌｅ（ファイル）をＭＰＥＧ−ＴＳ２２０５上に繰り返し伝送する。受信機２２０４は、カルーセルの周期でＢＭＬコンテンツ２２０１を取得する。したがって少なくともカルーセルが一周しないとＢＭＬコンテンツ２２０１を提示することができない。

図２３は、データカルーセルの一例を示す図である。
ＢＭＬ文書、静止画、及び図形などのファイルは、リソース２３０１と呼ばれる単位で表現される。このリソース２３０１は、モジュール２３０２という単位にまとめられる。１個のモジュール２３０２は、１個又は複数個のリソース２３０１からなる。複数個のリソース２３０１をまとめたモジュール２３０２は、マルチパートと呼ばれる。モジュール２３０２は、ＤＤＢ（Download Data Block）２３０３に分割され、ＭＰＥＧ−ＴＳ２２０５上に伝送される。受信したときに必要な情報がわかるように、ＤＤＢには、ＤＩＩ（Download Info Indication）メッセージが付加される。このＤＩＩから、次のＤＩＩの１つ前にあるＤＤＢまでがカル−セル２３０３の一単位となる。

図２４は、データストリームの構成の一例を示す図である。
図２４に示す例では、映像ストリーム２４０１が１つ、音声ストリーム２４０２が１つ、データストリーム２４０３、２４０４が２つ含まれる。データはセクション形式で伝送されるので正確にはストリームではないが、ここでは簡単のためにデータストリームと呼ぶことにする。ＢＭＬコンテンツ２２０１に含まれるＢＭＬ文書は、通常１つではなく、いくつかの文書に分かれて構成されている。

図２５は、ＢＭＬ文書が遷移する様子の一例を示す図である。
図２５において、データストリーム２４０３には、表示文書２５０１及び印刷文書２５０２が含まれている。データストリーム２４０４には、表示文書２５０３、２５０４及び印刷文書２５０５、２５０６が含まれる。表示文書２５０１は、最初に表示される文書であり、スタートアップ文書と呼ばれる。各表示文書２５０１、２５０３、２５０４の「次へ」及び「戻る」ボタンの操作で、表示文書２５０１及び表示文書２５０３間の遷移と、表示文書２５０３及び表示文書２５０４間の遷移とが行われる（「表示文書２５０１」⇔「表示文書２５０３」⇔「表示文書２５０４」の遷移が行われる）。また、各表示文書２５０１、２５０３、２５０４の「印刷」ボタンの操作で、対応する印刷文書２５０２、２５０５、２５０６の印刷が行われる。

図２６は、受信機２２０４内でのデータ放送のデータの流れの一例を示す図である。
放送波のＭＰＥＧ２−ＴＳ２２０５上にカルーセル伝送されるＢＭＬコンテンツ２２０１のファイルが取り出される。受信機２２０４の出力処理部２６０１は、前記取り出されたファイルに含まれる表示コンテンツを取り出して表示出力する。また、受信機２２０４の印刷処理部２６０２は、前記取り出されたファイルに含まれる印刷コンテンツを取り出して印刷装置が解釈可能な印刷データに変換して印刷出力する。なお、取り出されたＢＭＬコンテンツ２２０１のファイルは、バッファに一時的に格納される。

次に、データ放送の印刷サービスについて説明する。
印刷用の文書はＢＭＬではなくＨＴＭＬで記述される。印刷文書のフォーマットは、XHTML-Print、CSS Print Profileに規定される。これは、主にプリンタ（ネットワークプリンタ１０４）への負荷を軽減する目的で規定されている。データ放送の印刷サービスでは、受信機２２０４にプリンタドライバをインストールすることなしに印刷を行うことができるように、プリンタが印刷用ＨＴＭＬを解釈し、印刷イメージデータを作成するようにしているからである。なお、詳細については、それぞれの規格書に記載されている。

ＢＭＬコンテンツ２２０１の印刷は、印刷用コンテンツをどこに置くかで大きく２つに分けられる。１つは印刷用ＨＴＭＬを放送波に含む場合であり、もう１つは印刷用ＨＴＭＬをインターネット上に配置する場合である。また、ネットワークプリンタ１０４が実際に印刷を行うときのＢＭＬコンテンツ２２０１のデータの受け取り方により、ＰＵＳＨ印刷（配信型印刷方式）とＰＵＬＬ印刷（要求型印刷方式）とに分けることができる。

ＰＵＳＨ印刷とは、印刷データをプリンタに直接送信することにより印刷を行うものである。ＰＵＬＬ印刷とは、プリンタに印刷データの所在を示すＵＲＩを送信し、プリンタが渡されたＵＲＩから印刷データを取得して印刷を行うものである。

図２７（ａ）は、放送波に印刷データを含む場合の第１の印刷モデルの一例を示す図である。この第１の印刷モデルでは、放送衛星２７０１からの放送波に含まれるＭＰＥＧ−ＴＳ上にカルーセル伝送される印刷用ＨＴＭＬ２７０２を、受信機であるＤＴＶ１０１が取り出す。そして、ＤＴＶ１０１からネットワークプリンタ１０４に、この印刷用ＨＴＭＬ２７０２を送って印刷を行う。

図２７（ｂ）は、インターネット上に印刷データを配置する場合の第２の印刷モデルの一例を示す図である。この第２の印刷モデルでは、受信機であるＤＴＶ１０１は、印刷用ＨＴＭＬ２７０２を持たない。ＤＴＶ１０１は、放送衛星２７０１からの放送波を通して取得した印刷用ＨＴＭＬ２７０２のＵＲＩ２７０３をネットワークプリンタ１０４に送る。ネットワークプリンタ１０４は、そのＵＲＩ２７０３にあるＷＥＢサーバ１０９にアクセスして印刷用ＨＴＭＬ２７０２を取得して印刷を行う。したがって、この印刷モデルでは、ＰＵＬＬ印刷を行うことになる。

図２７（ｃ）は、放送衛星２７０１からの放送波に含まれる印刷用ＨＴＭＬ２７０２を、ＰＵＬＬ印刷を実行して印刷する場合の第３の印刷モデルの一例を示す図である。放送衛星２７０１からの放送波に印刷用ＨＴＭＬ２７０２が含まれる場合、受信機であるＤＴＶ１０１がＨＴＴＰサーバを持つようにする。そして、ＤＴＶ１０１が、放送衛星２７０１からの放送波から取り出した印刷用ＨＴＭＬ２７０２を要求するためにＤＴＶ１０１のＵＲＩ２７０３を、ネットワークプリンタ１０４に送る。ネットワークプリンタ１０４は、そのＵＲＩ２７０３にあるＤＴＶ１０１にアクセスして印刷用ＨＴＭＬ２７０２を取得して印刷を行う。このように、ＤＴＶ１０１とネットワークプリンタ１０４との間でＰＵＬＬ印刷を行うことも可能である。

この第３の印刷モデルにおける方式のメリットは、ＤＴＶ１０１のリソース負荷が軽いことである。なぜなら、第１の印刷モデルにおける方式は、印刷用ＨＴＭＬ２７０２を直接ネットワークプリンタ１０４に送信することになるため、ネットワークプリンタ１０４が印刷要求ジョブを受け付けることが可能な状態でなければならず、ネットワークプリンタ１０４が他の印刷処理中である場合、印刷要求ジョブを受け付けることができず、ＤＴＶ１０１は、印刷要求ジョブが受諾されるまで、ｘＨＴＭＬ形式の印刷データをＤＴＶ１０１の何部メモリに保持していなければならない。これに対して第３の印刷モデルにおける方式（図２７（ｃ））では、プル型の印刷要求ジョブをネットワークプリンタに発行するだけで、ｘＨＴＭＬ形式の印刷データ（印刷用コンテンツ）は保持しておかなくてよく、削除することができる。なぜなら、前述したように、カルーセル方式のデータ放送は、繰り返し送信されるため、ネットワークプリンタ１０４からＤＴＶ１０１がHTTP GETのような配信要求を受けた後で、受信したデータ放送中に含まれるｘＨＴＭＬ形式の印刷用コンテンツをネットワークプリンタ１０４に配信すればよいからである。

図２８は、図２７（ａ）に示した第１の印刷モデルを実行する場合のネットワークシステムの動作の一例を示す図である。また、図２９は、図２７（ａ）に示した第１の印刷モデルを実行する場合のネットワークシステムを機能的に示した機能ブロック図である。
図２８及び図２９において、コントロールポイント（ＣＰ）であるＤＴＶ１０１は、クリエイトジョブリクエスト（Create Job Request）を、ネットワークプリンタ１０４に送信する（ステップＳ１）。
次に、ネットワークプリンタ１０４は、クリエイトジョブレスポンス（Create Job Response）に印刷データの送信先であるデータシンク（DataSink）を含めて、ＤＴＶ１０１に送信する（ステップＳ２）。

次に、ＤＴＶ１０１は、データシンクに印刷データを送信する（ステップＳ３）。印刷データの送信が完了すると、ネットワークプリンタ１０４は、印刷データが送信されたことを示すHTTPレスポンス（HTTP Response）を、ＤＴＶ１０１に返す（ステップＳ４）。

なお、図２９に示すように、ＤＴＶ１０１は、印刷データ生成処理２９０１を起動させることにより生成された印刷データは、出力ファイル２９０２に格納される。

図３０は、図２７（ｂ）に示した第２の印刷モデルを実行する場合のネットワークシステムの動作の一例を示す図である。また、図３１は、図２７（ｂ）に示した第２の印刷モデルを実行する場合のネットワークシステムを機能的に示した機能ブロック図である。
図３０及び図３１において、コントロールポイント（ＣＰ）であるＤＴＶ１０１は、クリエイトジョブリクエスト（Create Job Request）を、ネットワークプリンタ１０４に送信する（ステップＳ１１）。
次に、ネットワークプリンタ１０４は、クリエイトジョブレスポンス（Create Job Response）に印刷データの送信先であるデータシンク（DataSink）を含めて、ＤＴＶ１０１に送信する（ステップＳ１２）。

次に、ＤＴＶ１０１は、データシンクに印刷データの所在を示すＵＲＩを送信する（ステップＳ１３）。
次に、ＵＲＩを受け取ったネットワークプリンタ１０４は、印刷データが送信されたことを示すHTTPレスポンス（HTTP Response）を、ＤＴＶ１０１に返す（ステップＳ１４）。
次に、ネットワークプリンタ１０４は、渡されたＵＲＩに基づいて、HTTP GET、あるいはFTP GETして、ＷＥＢサーバ１０９から印刷データを受信する（ステップＳ１５、S１６）。

図３２は、図２７（ｃ）に示した本発明の特徴となる第３の印刷モデルを実行する場合のネットワークシステムの動作の一例を示す図である。また、図３３は、図２７（ｃ）に示した第３の印刷モデルを実行する場合のネットワークシステムを機能的に示した機能ブロック図である。
図３２及び図３３において、コントロールポイント（ＣＰ）であるＤＴＶ１０１は、ユーザがリモコンを操作することによりＵＩ処理部（操作部）１５０６が印刷指示を受け付けた場合に、デジタルデータ放送中に含まれるｘＨＴＭＬ形式の印刷用コンテンツを印刷するための印刷要求であるクリエイトジョブリクエスト（Create Job Request）を、ネットワークプリンタ１０４に送信する（ステップＳ２１）。そして、この段階で、ＤＴＶ１０１は、デジタルデータ放送中に含まれるｘＴＨＭＬ形式の印刷用コンテンツは削除可能であり、リソースを必要に応じて他の処理にまわすことを許可する。
次に、ネットワークプリンタ１０４は、クリエイトジョブレスポンス（Create Job Response）に印刷データの送信先であるデータシンク（DataSink）を含めて、ＤＴＶ１０１に送信する（ステップＳ２２）。

次に、ＤＴＶ１０１は、データシンクに印刷データの所在を示すＵＲＩとして、ＤＴＶ１０１自身のＵＲＩを送信する（ステップＳ２３）。
次に、ＵＲＩを受け取ったネットワークプリンタ１０４は、HTTPレスポンス（HTTP Response）を、ＤＴＶ１０１に返す（ステップＳ２４）。
次に、ネットワークプリンタ１０４は、渡されたＵＲＩに基づいて、HTTP GET、あるいはFTP GETが行われる（ステップＳ２５）。
次に、ＤＴＶ１０１は、ネットワークプリンタからファイル転送要求（HTTP GET, FTP GET）を受け取ると、新たにデジタル放送受信制御部１５０４から受信したデジタルデータ放送中の印刷用コンテンツを取り出して、印刷データを生成し、ネットワークプリンタ１０４に送信する（ステップＳ２６）。これにより、ＤＴＶ１０１は、プル型印刷方式の場合にも、ＤＴＶ１０１のリソースを常に確保することなく、印刷用コンテンツが必要になった際に受信したデジタルデータ放送中の印刷用コンテンツを印刷データとして用いるため、ＤＴＶ１０１のリソースの有効利用が可能となる。

なお、以上のような第３の印刷モデルの変形例として、図３３に示すように、ＤＴＶ１０１が有している印刷データ生成処理部３３０１が起動することにより印刷データを生成し、この印刷データが、ＨＴＴＰサーバ（又はＦＴＰサーバ）３３０３が管理するディレクトリに置かれた出力ファイル３３０２内に格納されてもよい。ＨＴＴＰサーバ（又はＦＴＰサーバ）３３０３では、ＨＴＴＰＤ（HyperText Transfer Protocol Daemon）を用いて処理が実行される。

以上のような第３の印刷モデルの変形例として、図３４に示す第４の印刷モデルを利用ことができる。図３４は、放送衛星２７０１からの放送波に含まれる印刷用ＨＴＭＬ２７０２に対し、ＰＵＬＬ印刷を行う印刷モデルを実行する場合のネットワークシステムを機能的に示した機能ブロック図である。

図３４に示すように、ＣＧＩ（Common Gateway Interface）スクリプトで印刷データ生成処理３３０１を起動する場合には、生成する印刷データを特定するために、印刷データのＩＤを引数としてＵＲＩに付加し、例えば、「http://server/cgi-bin/script?id=source＿id」といったＵＲＩをネットワークプリンタ１０４に送信するようにする。

図３５は、印刷方法を選択する場合のネットワークシステムにおける動作の一例を説明するフローチャートである。
まず、ＤＴＶ１０１は、ネットワークプリンタ１０４の状態を取得する（ステップＳ３００１）。
次に、ＤＴＶ１０１は、ネットワークプリンタ１０４が印刷を実行することが可能かどうかを判定する（ステップＳ３００２）。この判定の結果、ネットワークプリンタ１０４が印刷を実行することが可能であれば、図２７（ａ）に示した第１の印刷モデルに従ったＰＵＳＨ印刷が実行される（ステップＳ３００３）。すなわち、第１の印刷モデルに従って、ＤＴＶ１０１は、印刷データを生成し、生成した印刷データをネットワークプリンタ１０４に送信して、ＰＵＳＨ印刷を実行する。

一方、前記ステップＳ３３０２において、ネットワークプリンタ１０４が印刷を実行することが不可能であると判定された場合には、ＤＴＶ１０１は、内部の状態を取得する（ステップＳ３００４）。
次に、ＤＴＶ１０１は、デジタルデータ放送中に印刷用コンテンツ（ｘＨＴＭＬ形式もしくはＢＭＬ形式）が含まれているか判定することにより、印刷データを生成することが可能かどうかを判定する（ステップＳ３００５）。この判定の結果、印刷データを生成することが可能であれば、図２７（ｃ）に示した第３の印刷モデルに従ったＰＵＬＬ印刷が実行される（ステップＳ３００６）。すなわち、第３の印刷モデルに従って、印刷データ生成処理部３３０１は、印刷要求ジョブを生成し、ネットワークプリンタ１０４に送信して、ＰＵＬＬ印刷を実行する。このときに、印刷用コンテンツはＤＴＶ１０１内に保持される必要はなく、ＤＴＶ１０１の他の処理によりメモリリソースが必要な場合は削除することを許可する。

前記ステップＳ３００５において、デジタルデータ放送中に印刷用コンテンツが含まれておらず、印刷用ドキュメントの場所を示すＵＲＩの指定が存在しており、ＤＴＶ１０１では印刷データを生成することが不可能であると判定された場合には、第２の印刷モデルに従ったＰＵＬＬ印刷が実行される（ステップＳ３００７）。すなわち、第２の印刷モデルに従って、印刷データ生成処理部３３０１は、印刷データが格納されているＷＥＢサーバ１０９の場所を示すＵＲＩをネットワークプリンタ１０４に送信して、ネットワークプリンタによるＰＵＬＬ印刷を実行する。

図３６は、ＣＧＩスクリプトで印刷データを生成する場合のネットワークシステムにおける動作の一例を説明するフローチャートである。
まず、ＤＴＶ１０１のＨＴＴＰサーバ３３０３は、引数として渡されたＩＤが正しいかどうかを判定する（ステップＳ３１０１）。この判定の結果、ＩＤが正しい場合には、ＤＴＶ１０１のＨＴＴＰサーバ３３０３は、印刷データが生成済みであるかどうかを判定する（ステップＳ３１０１）。

この判定の結果、印刷データが生成済みであれば、生成済みの印刷データを含む成功応答を、ネットワークプリンタ１０４に返す（ステップＳ３１０３）。一方、印刷データが生成済みでなければ、ＤＴＶ１０１のＨＴＴＰサーバ３３０３は、印刷データ生成処理３３０３を起動して印刷データを生成し、生成した印刷データを含む成功応答をネットワークプリンタ１０４に返す（ステップＳ３１０４）。
前記ステップＳ３１０１において、ＩＤが不正であると判定された場合には、ＤＴＶ１０１のＨＴＴＰサーバ３３０３は、失敗応答をネットワークプリンタ１０４に返す（ステップＳ３１０５）。

以上のように本実施形態では、ＤＴＶ１０１は、印刷データ生成処理部３３０１の起動をネットワークプリンタ１０４が指示できるようにするためのＵＲＩをネットワークプリンタ１０４に送信する。そして、そのＵＲＩに基づく印刷データの取得要求（HTTP GET）が、ネットワークプリンタ１０４からなされると、ＤＴＶ１０１は、印刷データ生成処理部３３０１を起動して印刷データを生成する。生成された印刷データは、出力ファイル３３０２に格納される。出力ファイル３３０２に格納された印刷データは、ＤＴＶ１０１が有しているＨＴＴＰサーバ３３０３からネットワークプリンタ１０４に送信される。
このように、ＤＴＶ１０１は、ネットワークプリンタ１０４から印刷データの取得要求があった後に印刷データを生成するので、ＤＴＶ１０１が行う他の処理の負荷が、印刷データの生成によって増大することを、いわゆるスプール機能を設けなくても、可及的に防止することができる。

また、ネットワークプリンタ１０４で印刷が可能でなく、ＤＴＶ１０１の内部状態により、印刷データの生成が可能でない場合に、印刷データ生成処理部３３０１の起動をネットワークプリンタ１０４が指示できるようにするためのＵＲＩをネットワークプリンタ１０４に送信するようにした。これにより、ＤＴＶ１０１が他の処理を行っている場合にだけ、ネットワークプリンタ１０４から印刷データの取得要求があった後に印刷データを生成するので、より適切なタイミングで印刷データを生成することが可能になる。

また、ネットワークプリンタ１０４の状態と、ＤＴＶ１０１の内部の状態とに基づいて、異なるＵＲＩをネットワークプリンタ１０４に送信して、印刷方法を異ならせるようにしたので、より一層適切なタイミングで印刷データを生成することが可能になる。

なお、本実施形態では、印刷を要求するホスト（ＤＴＶ１０１）にはプリンタドライバをインストールせずに、印刷データをＨＴＭＬ文書とした。しかしながら、ホスト（ＤＴＶ１０１）が複数のデータフォーマットを出力することが可能な場合には、例えば、「http://server/cgi-bin/script?id=source_id,format=[html,ps,jpg]」といったＵＲＩでＰＵＬＬ印刷の要求を行い、ネットワークプリンタは、例えば、「http://server/cgi-bin/script?id=source_id,format=ps」というＵＲＩ宛てに印刷データを要求することにより、ホストがネットワークプリンタの要求するフォーマットで印刷データを生成することも可能である。

このようにすれば、ＤＴＶ１０１と、ネットワークプリンタ１０４とが、事前にネゴシエーション（negotiation）を省略することができ、より簡単に且つ迅速に印刷データを生成することが可能になる。

（本発明の他の実施形態）
上述した実施形態の機能を実現するべく各種のデバイスを動作させるように、該各種デバイスと接続された装置あるいはシステム内のコンピュータに対し、前記実施形態の機能を実現するためのソフトウェアのプログラムコードを供給し、そのシステムあるいは装置のコンピュータ（ＣＰＵあるいはＭＰＵ）に格納されたプログラムに従って前記各種デバイスを動作させることによって実施したものも、本発明の範疇に含まれる。

また、この場合、前記ソフトウェアのプログラムコード自体が上述した実施形態の機能を実現することになり、そのプログラムコード自体、及びそのプログラムコードをコンピュータに供給するための手段、例えば、かかるプログラムコードを格納した記録媒体は本発明を構成する。かかるプログラムコードを記憶する記録媒体としては、例えばフレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、磁気テープ、不揮発性のメモリカード、ＲＯＭ等を用いることができる。

また、コンピュータが供給されたプログラムコードを実行することにより、上述の実施形態の機能が実現されるだけでなく、そのプログラムコードがコンピュータにおいて稼働しているＯＳ（オペレーティングシステム）あるいは他のアプリケーションソフト等と共同して上述の実施形態の機能が実現される場合にもかかるプログラムコードは本発明の実施形態に含まれることは言うまでもない。

さらに、供給されたプログラムコードがコンピュータの機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに格納された後、そのプログラムコードの指示に基づいてその機能拡張ボードや機能拡張ユニットに備わるＣＰＵ等が実際の処理の一部または全部を行い、その処理によって上述した実施形態の機能が実現される場合にも本発明に含まれることは言うまでもない。

本発明の実施形態を示し、ネットワークシステムの構成の一例を示した図である。 本発明の実施形態を示し、画像形成システムの構成の一例を示した図である。 本発明の実施形態を示し、ネットワークコントローラが有する機能モジュールの概略構成の一例を示す図である。 本発明の実施形態を示し、プリンタコントローラが有する機能モジュールの概略構成の一例を示す図である。 本発明の実施形態を示し、ネットワークコントローラの内部構成の一例を示したブロック図である。 本発明の実施形態を示し、プリンタコントローラの内部構成の一例を示したブロック図である。 本発明の実施形態を示し、ＵＰｎＰネットワークの基本構成の一例を示すブロック図である。 本発明の実施形態を示し、ＵＰｎＰのプロトコルスタックの一例を示す図である。 本発明の実施形態を示し、は、デバイスがネットワークに追加され利用可能なことを示す告知パケットの一例と、デバイスがネットワークから削除されつつあり利用できなくなることを示す告知パケットの一例を示す図である。 本発明の実施形態を示し、サーチリクエストパケットの一例と、サーチレスポンスパケットの一例とを示す図である。 本発明の実施形態を示し、ディスクリプションを行う際のコントロールポイントとデバイスとの様子と、ディスクリプションリクエストの一例と、ディスクリプションレスポンスの一例とを示す図である。 本発明の実施形態を示し、コントロールポイントがデバイスをコントロールする様子と、アクションリクエストの一例と、アクションレスポンスの一例とを示す図である。 本発明の実施形態を示し、イベンティングを行う際のコントロールポイントとデバイスとの様子と、サブスクリプションリクエストの一例と、サブスクリプションレスポンスの一例と、イベントメッセージの一例とを示す図である。 本発明の実施形態を示し、ブラウザがデバイスのプレゼンテーションページにアクセスする様子を概念的に示した図である。 本発明の実施形態を示し、ＤＴＶの内部構成の一例を示した機能ブロック図である。 本発明の実施形態を示し、デジタル放送受信制御部でのデータ処理の流れの一例を概念的に示した図である。 本発明の実施形態を示し、トランスポートストリームを概念的に示した図である。 本発明の実施形態を示し、ＴＳパケットの構成を概念的に示した図である。 本発明の実施形態を示し、ＰＳＩを概念的に示した図である。 本発明の実施形態を示し、ＴＳパケットから番組情報を抽出する際のデジタル放送受信制御部における処理動作の一例を説明するフローチャートである。 本発明の実施形態を示し、ＴＳパケットからビデオデータを選択する際の復号器における構成の一例を示した図である。 本発明の実施形態を示し、データ放送の伝送方式の一例を概念的に示す図である。 本発明の実施形態を示し、データカルーセルの一例を示す図である。 本発明の実施形態を示し、データストリームの構成の一例を示す図である。 本発明の実施形態を示し、ＢＭＬ文書が遷移する様子の一例を示す図である。 本発明の実施形態を示し、受信機内でのデータ放送のデータの流れの一例を示す図である。 本発明の実施形態を示し、印刷モデルの一例を示す図である。 本発明の実施形態を示し、第１の印刷モデルを実行する場合のネットワークシステムの動作の一例を示す図である。 本発明の実施形態を示し、第１の印刷モデルを実行する場合のネットワークシステムを機能的に示した機能ブロック図である。 本発明の実施形態を示し、第２の印刷モデルを実行する場合のネットワークシステムの動作の一例を示す図である。 本発明の実施形態を示し、第２の印刷モデルを実行する場合のネットワークシステムを機能的に示した機能ブロック図である。 本発明の実施形態を示し、第３の印刷モデルを実行する場合のネットワークシステムの動作の一例を示す図である。 本発明の実施形態を示し、第３の印刷モデルを実行する場合のネットワークシステムを機能的に示した機能ブロック図である。 本発明の実施形態を示し、第４の印刷モデルを実行する場合のネットワークシステムを機能的に示した機能ブロック図である。 本発明の実施形態を示し、印刷方法を選択する場合のネットワークシステムにおける動作の一例を説明するフローチャートである。 本発明の実施形態を示し、ＣＧＩスクリプトで印刷データを生成する場合のネットワークシステムにおける動作の一例を説明するフローチャートである。

符号の説明

１０１ デジタル放送用テレビ（ＤＴＶ）
１０４ ネットワークプリンタ
２０１ ネットワークコントローラ
２０２ プリンタコントローラ
７１０ コントロールポイント
７２０、７２２ デバイス
７２１、７２３ サービス

Claims (2)

1. カルーセル方式により繰り返し放送されるデジタルデータ放送に含まれる印刷用文書データを用いて、通信可能に接続された画像形成装置に送信する印刷データを生成するデジタル放送受信装置であって、
   前記デジタルデータ放送に含まれる、データ放送画面を表示するための表示用文書データと印刷に利用される印刷用文書データとを取得し、記憶部に格納する取得手段と、
   前記表示用文書データを用いてデータ放送画面を表示する表示手段と、
   前記表示手段で表示されたデータ放送画面を介して、ユーザから印刷用文書データの印刷処理の実行を指示する印刷指示を受け付けたことに応じて、前記画像形成装置に印刷要求を発行する印刷要求手段と、
   前記印刷要求手段により前記画像形成装置に印刷要求を発行した後、前記記憶部に格納されている前記印刷用文書データを削除する制御を行う制御手段と、
   前記印刷要求に応答して前記画像形成装置から送信された印刷データの配信要求を受け付ける受付手段と、
   前記デジタルデータ放送に含まれる印刷用文書データから前記画像形成装置が解釈可能な印刷データを生成し、前記画像形成装置に送信する印刷データ出力手段と、を有し、
   前記取得手段は、前記受付手段により配信要求を受け付けた後に、受信中のデジタルデータ放送に含まれる印刷用文書データを当該デジタルデータ放送から再び取得し、
   前記印刷データ出力手段は、前記取得手段により再び取得された印刷文書データから前記画像形成装置が解釈可能な印刷データを生成し、前記画像形成装置に送信することを特徴とするデジタル放送受信装置。
2. カルーセル方式により繰り返し放送されるデジタルデータ放送に含まれる印刷用文書データを用いて、通信可能に接続された画像形成装置に送信する印刷データを生成するデジタル放送受信装置の制御方法であって、
   前記デジタルデータ放送に含まれる、データ放送画面を表示するための表示用文書データと印刷に利用される印刷用文書データとを取得し、記憶部に格納する第１の取得ステップと、
   前記表示用文書データを用いてデータ放送画面を表示部に表示する表示ステップと、
   前記表示ステップで表示されたデータ放送画面を介して、ユーザから印刷用文書データの印刷処理の実行を指示する印刷指示を受け付けたことに応じて、前記画像形成装置に印刷要求を発行する印刷要求ステップと、
   前記印刷要求ステップにより前記画像形成装置に印刷要求を発行した後、前記記憶部に格納されている前記印刷用文書データを削除する制御を行う制御ステップと、
   前記印刷要求に応答して前記画像形成装置から送信された印刷データの配信要求を受け付ける受付ステップと、
   前記受付ステップにより配信要求を受け付けた後に、受信中のデジタルデータ放送に含まれる印刷用文書データを当該デジタルデータ放送から再び取得する第２の取得ステップと、
   前記第２の取得ステップにより再び取得された印刷用文書データから前記画像形成装置が解釈可能な印刷データを生成し、前記画像形成装置に送信する印刷データ出力ステップと、を有することを特徴とするデジタル放送受信装置の制御方法。

Images