JP5084456B2 - 通信システム、通信処理方法、及びデバイス - Google Patents

Description

本発明は、通信システム、通信処理方法、及びデバイスに関し、特に、デバイスの状態を表示するために用いて好適なものである。

近年、デジタル放送とブロードバンドネットワークの普及に伴い、放送サービスに加えて通信サービスを便利に且つ簡単に利用できるデジタルテレビジョン（以下「ＤＴＶ」と称する）が普及している。また、ＤＴＶとプリンタ等のデジタルデバイスとを相互に接続する技術も普及しており、ＤＴＶと各種デジタルデバイスとの連携により提供されるサービスも注目されている。ＤＴＶとプリンタとが連携したサービスとして、ＤＴＶからの指示により、ＤＴＶが受信したコンテンツをプリンタが印刷するというサービス（印刷サービス）が知られている（特許文献１を参照）。このサービスの実現のために一般的には通信プロトコルとしてＵＰｎＰ（Universal Plug and Play）が使用される。

デジタル放送の前記コンテンツは次のようにして印刷される。すなわち、ＤＴＶの画面に表示される印刷指示ボタンをユーザがリモコン操作等で選択する。そうすると、ＤＴＶからプリンタへ印刷ジョブが発行され、プリンタがその印刷ジョブを印刷する。当然ながら、このようなコンテンツの多くは、ユーザが番組を視聴しているときに印刷されることとなる。この印刷の実行時にプリンタにおいて、紙なしエラーやインク残量警告等のエラー状態が発生した場合には、そのタイミングでプリンタからＤＴＶにエラー通知がＵＰｎＰイベントという形で一回発行される。このエラーは、通常、ＤＴＶの画面にオーバーレイメッセージとして表示されることが多い。このように、この種のエラーメッセージは視聴番組の放映画面上にオーバーレイされるため、番組視聴の妨げにならないように、一定時間表示された後に消去されるようなテレビの仕様となっていることが多い。

特開２００６−３０４３３８号公報

しかしながら、前述したように、プリンタからのイベントの受信に伴うエラーメッセージが一定時間経過後に画面から消去されてしまうと、そのエラーメッセージの表示を見逃してしまったユーザは、エラーの認識不足により適切な対応を行えない。したがって、プリンタにおいてエラー状態が放置され、印刷がいつまでたっても開始、又は正常完了しない恐れがある。

一方、このような印刷システムで通信プロトコルとして使用するＵＰｎＰやＷＳＤ（Web Service on Devices）等のネットワーク通信プロトコルでは、プリンタ等のデバイスからＤＴＶへのステータスの通知は主にイベント通知で行われる。このイベント通知は、デバイスのステータスに変化が生じた場合にのみ発行可能であると規格上規定されている。したがって、従来は、あるエラー状態に対してイベントを複数回発行することができなかった。

そこで本発明は、ＤＴＶ等のデータ処理装置と、プリンタ等のデバイスとが通信可能に相互に接続されたシステムにおいて、デバイスの状態に関する表示をデータ処理装置のユーザが見落としてしまうことを可及的に防止することを目的とする。

本発明の通信システムは、デバイスと、当該デバイスに対して処理を要求するデータ処理装置とが通信可能に相互に接続された通信システムであって、前記デバイスは、当該デバイスにおいて特定の状態が継続している時間に応じて、前記特定の状態が継続していることを示す状態識別情報を変更する変更手段と、前記変更手段により状態識別情報が変更されたことに応じて、前記デバイスが前記状態識別情報に対応する特定の状態であること示す通知を前記データ処理装置に送信する送信手段とを有し、前記データ処理装置は、前記デバイスから前記デバイスが前記特定の状態であることを示す通知を受信する受信手段と、前記受信手段により前記通知が受信される度に、前記デバイスが前記特定の状態であることを、予め定められた表示時間だけ表示装置に表示するための表示手段とを有し、前記変更手段は、前記状態識別情報を変更する周期を、前記表示時間よりも短くし、前記送信手段は、前記デバイスの状態に変化があったことに応じて、デバイスの状態を示す通知を前記データ処理装置に対して送信するプロトコルを用いており、前記変更手段が状態識別情報を変更することで、前記デバイスが継続して前記特定の状態であったとしても、前記プロトコルを用いて前記デバイスが前記特定の状態であることを示す通知を再度、前記データ処理装置に送信することを特徴とする。
本発明のデバイスは、デバイスから通知された当該デバイスの状態を予め定められた表示時間だけ表示装置に表示するデータ処理装置と通信可能に接続されたデバイスであって、前記デバイスにおいて特定の状態が継続している時間に応じて、前記特定の状態が継続していることを示す状態識別情報を変更する変更手段と、前記変更手段により状態識別情報が変更されたことに応じて、前記デバイスが前記状態識別情報に対応する特定の状態であること示す通知を前記データ処理装置に送信する送信手段とを有し、前記送信手段は、前記デバイスの状態に変化があったことに応じて、デバイスの状態を示す通知を前記データ処理装置に対して送信するプロトコルを用いており、前記変更手段が状態識別情報を変更することで、前記デバイスが継続して前記特定の状態であったとしても、前記プロトコルを用いて前記デバイスが前記特定の状態であることを示す通知を再度、前記データ処理装置に送信することを特徴とする。

本発明の通信処理方法は、デバイスと、当該デバイスに対して処理を要求するデータ処理装置とが通信可能に相互に接続された通信システムにおける通信処理方法であって、前記デバイスは、当該デバイスにおいて特定の状態が継続している時間に応じて、前記特定の状態が継続していることを示す状態識別情報を変更する変更工程と、前記変更工程で状態識別情報が変更されたことに応じて、前記デバイスが前記状態識別情報に対応する特定の状態であること示す通知を前記データ処理装置に送信する送信工程とを有し、前記データ処理装置は、前記デバイスから前記デバイスが前記特定の状態であることを示す通知を受信する受信工程と、前記通知が受信される度に、前記デバイスが前記特定の状態であることを、予め定められた表示時間だけ表示装置に表示するための表示工程とを有し、前記変更工程では、前記状態識別情報を変更する周期を、前記表示時間よりも短くし、前記送信工程では、前記デバイスの状態に変化があったことに応じて、デバイスの状態を示す通知を前記データ処理装置に対して送信するプロトコルを用いており、前記変更工程により状態識別情報を変更することで、前記デバイスが継続して前記特定の状態であったとしても、前記プロトコルを用いて前記デバイスが前記特定の状態であることを示す通知を再度、前記データ処理装置に送信することを特徴とする。
また、本発明の通信処理方法の他の態様例では、デバイスから通知された当該デバイスの状態を予め定められた表示時間だけ表示装置に表示するデータ処理装置と通信可能に接続されたデバイスにおける通信処理方法であって、前記デバイスにおいて特定の状態が継続している時間に応じて、前記特定の状態が継続していることを示す状態識別情報を変更する変更工程と、前記変更工程で状態識別情報が変更されたことに応じて、前記デバイスが前記状態識別情報に対応する特定の状態であること示す通知を前記データ処理装置に送信する送信工程とを有し、前記送信工程では、前記デバイスの状態に変化があったことに応じて、デバイスの状態を示す通知を前記データ処理装置に対して送信するプロトコルを用いており、前記変更工程により状態識別情報を変更することで、前記デバイスが継続して前記特定の状態であったとしても、前記プロトコルを用いて前記デバイスが前記特定の状態であることを示す通知を再度、前記データ処理装置に送信することを特徴とする。

本発明のコンピュータプログラムは、前記デバイスの各手段としてコンピュータを機能させることを特徴とする。

本発明によれば、デバイスの状態が継続している場合であっても、データ処理装置における表示時間が経過する前に、内容を変更したステータス情報をデータ処理装置に送信することができる。これにより、デバイスの状態が継続している場合であっても、デバイスの状態に関わる情報を継続して表示することができる。よって、デバイスの状態に関する表示をデータ処理装置のユーザが見落としてしまうことを可及的に防止することができる。

以下に、図面を参照しながら、本発明の一実施形態について説明する。
本実施形態では、ＤＴＶと、ＤＴＶプリンタ（以下「プリンタ」と略称する）を有する印刷システムを例に挙げて説明する。ここで、ＤＴＶとプリンタは、ＵＰｎＰプロトコルで通信を行うことができる。ＤＴＶは、受信したコンテンツをＤＴＶに対して、ＵＰｎＰプロトコルを用いて送信することによりＤＴＶに印刷を指示する印刷指示機能を備える。一方、プリンタは、ＵＰｎＰプロトコルを用いてＤＴＶから送信されたコンテンツに基づく印刷を行う。そして、本実施形態では、このような印刷システムにおいて、プリンタでエラーが発生した際に、その発生したエラーをＤＴＶに通知する方法に主たる特徴がある。そこで、プリンタでエラーが発生した際の通知方法について以下に詳しく説明する。尚、以下の説明で記載されているプロトコル、ヴァージョン、アドレス、その他の数値等は、特に特定的な記載がない限りは、本発明の範囲をそれらのみに限定する趣旨のものではない。

図１は、印刷システム（通信システム）の構成の一例を示す図である。
図１において、印刷システムは、ＤＴＶ１０１と、プリンタ１０２と、ルータ１０３と、アンテナ１０４と、ホームネットワーク１０８とを有している。ＤＴＶ１０１とプリンタ１０２とがホームネットワーク１０８を介して相互に通信可能に接続されている。ホームネットワーク１０８は、ルータ１０３を介してインターネット１０５に接続することが可能となっている。つまり、ＤＴＶ１０１及びプリンタ１０２は、インターネット１０５を介してＷｅｂサーバ１０６にアクセスすることが可能となっている。また、ＤＴＶプリンタ１０２は、Ｗｅｂサーバ１０６に保存された印刷用コンテンツ１０７を取得することが可能である。

ＤＴＶ１０１は、放送局１０９から送出されたデジタル放送を、アンテナ１０４を介して受信することが可能である。また、ＤＴＶ１０１は、デジタル放送のデータ放送を利用して送信される印刷用コンテンツデータ１１０を取得することが可能である。更に、ＤＴＶ１０１は、印刷用コンテンツデータ１１０を、ホームネットワーク１０８を介してプリンタ１０２に転送することが可能である。

図２は、ＤＴＶ１０１の内部構成の一例を示す図である。
図２において、ＣＰＵ２０１は、ＤＴＶ１０１全体の制御を行う。メモリ２０２は、制御プログラムの格納や動作等に利用される。ＣＰＵ２０１やメモリ２０２は、内部バス２１０を介して、リモコンＩ／Ｆ２１１やネットワークＩ／Ｆ２１２と相互に通信可能に接続される。
リモコンＩ／Ｆ２１１は、不図示のリモコン装置との間で通信を行うためのインタフェースである。また、ネットワークＩ／Ｆ２１２は、ホームネットワーク１０８を介してプリンタ１０２やルータ１０３と通信を行うためのインタフェースである。このネットワークＩ／Ｆ２１２を制御するプログラムはメモリ２０２に格納されており、このプログラムには、外部機器とのネットワーク通信プロトコルの一例であるＵＰｎＰに基づいた通信制御プログラムが含まれている。

アンテナ１０４で受信した放送波はチューナ２０３に入力される。チューナ２０３は、リモコン装置の選局操作等でユーザにより指定された周波数の放送波を選択的に復調回路２０４に出力する。復調回路２０４は、入力された放送波をＭＰＥＧ−２ ＴＳ（Transport Stream）に復調する。ＭＰＥＧ−２ ＴＳは、映像や音声、データ等が符号化されて多重されたデータストリームである。分離回路２０５は、このＭＰＥＧ−２ ＴＳを映像ＰＥＳ（Packetized Elementary Stream）や、音声ＰＥＳといったパケット化された符号化データに分離する。また、ＭＰＥＧ−２ ＴＳに含まれている字幕データやＥＰＧ（electronic program guide）の生成等に利用されるＳＩ（Service Information）等のセクションデータも分離回路２０５が分離する。

分離回路２０５で分離されたＰＥＳやセクションデータは、それぞれデコーダ部（図２において破線で示されている部分）に入力される。デコーダ部は、映像ＰＥＳを映像信号に復号する映像デコーダ２０６と、音声ＰＥＳを音声信号に復号する音声デコーダ２０７と、セクションデータを復号するデータデコーダ２０８とを備えている。
デコーダ部で復号された映像信号や音声信号は、夫々画像処理や音声処理が施された後に、モニタやスピーカ等を備える出力部２０９に出力される。また、復号されたデータはメモリ２０２に格納されて管理され、ユーザによる所定の操作によって、出力部２０９が備えるモニタに出力される。例えば、ユーザによる字幕表示の操作があった場合、字幕データが映像信号に合成されてモニタに出力される。また、ユーザによるデータ放送表示の操作があった場合、データデコーダ２０８で復号されたデータ放送用コンテンツは、メモリ２０２に格納されている所定のアプリケーションプログラムを用いて解釈され、出力部２０９にデータ放送画面として表示される。

続いて、プリンタ１０２の構成の一例を説明する。図３は、プリンタ１０２の内部構成の一例を示す図である。
図３において、ＤＴＶ１０１とホームネットワーク１０８を介して相互に通信可能に接続されるプリンタ１０２の構成は、ネットワークコントローラ３０１とプリンタコントローラ３０２とに大きく分けられる。
まず、ネットワークコントローラ３０１の構成の一例を説明する。
ネットワークコントローラ３０１は、制御を司るＣＰＵ３１１と、受信したデータを一時的に格納するためのバッファメモリやワークメモリとして使用するＤＲＡＭ３１２とを有する。また、ネットワークコントローラ３０１は、ホームネットワーク１０８に接続された機器との通信を行うネットワークインタフェースコントローラであるＮＩＣ３１５を有する。更に、ネットワークコントローラ３０１は、ＣＰＵ３１１によって実行されるプログラムが格納されたプログラムＲＯＭ３１３と、フォントデータが格納されたフォントＲＯＭ３１４とを有する。プログラムＲＯＭ３１３に格納されるプログラムには、外部機器と通信を行うネットワーク通信プロトコルの一例であるＴＣＰＩＰと、その上位通信プロトコルの一例であるＵＰｎＰと、その関連通信プロトコルとに基づく通信制御を行うプログラムが格納されている。また、ネットワークコントローラ３０１は、後述するプリンタコントローラ３０２との通信に用いられるシリアルＩＯ３１６を有している。尚、これらの各機能ブロックはネットワークコントローラ３０１の内部バスを介して相互に通信可能に接続されている。

続いて、プリンタコントローラ３０２の構成の一例を説明する。
プリンタコントローラ３０２は、制御を司るプリンタコントローラ用ＣＰＵであるＰ−ＣＰＵ３２１を備える。また、プリンタコントローラ３０２は、受信したデータを一時的に格納するためのバッファメモリやワークメモリとして使用するＰ−ＤＲＡＭ３２２を備える。また、プリンタコントローラ３０２は、Ｐ−ＣＰＵ３２１によって実行されるプログラムが格納されたＰ−ＲＯＭ３２３と、Ｐ−シリアルＩＯ３２４と、プリンタエンジンコントローラ３２５とを備える。

Ｐ−シリアルＩＯ３２４は、ネットワークコントローラ３０１と通信するためのプリンタコントローラ３０２側のシリアルＩＯである。これらのブロックは、内部バスを介してプリンタエンジンコントローラ３２５と通信可能に相互に接続されている。
プリンタエンジンコントローラ３２５は、プリンタ１０２の駆動に関する各種のドライバやモータ等を制御するためのコントローラである。インクジェットヘット３２７を駆動するためのヘッドドライバ３２６がプリンタエンジンコントローラ３２５によって制御される。また、ヘッドを動かすためのキャリッジモータ３２９を駆動するためのモータドライバ３２８と、紙を搬送するペーパーフィードモータ３３１を駆動するためのモータドライバ３３０とがプリンタエンジンコントローラ３２５によって制御される。

ＤＴＶ放送規格であるＡＲＩＢで定められたデータ放送印刷では、印刷コンテンツはマークアップ言語形式で記述された印刷用構造化文書データとなっている。このため、印刷データを生成するのはプリンタ１０２となる。印刷用コンテンツデータを取得したプリンタ１０２のネットワークコントローラ３０１は、その印刷用コンテンツデータをＤＲＡＭ３１２に格納する。次に、ネットワークコントローラ３０１は、印刷用コンテンツデータに含まれる構造化文書データであるＸＨＴＭＬ−ＰｒｉｎｔファイルやＣＳＳＰＰファイルを解釈する。これらのファイルを解釈した上で、ネットワークコントローラ３０１は、印刷イメージデータを生成するレンダリング処理を行う。

ネットワークコントローラ３０１で生成された印刷イメージデータはシリアルＩＯ３１６及びシリアルＩ／Ｆ３０７を経由してプリンタコントローラ３０２に転送される。プリンタコントローラ３０２は、受信した印刷イメージデータを印刷するために、プリンタエンジンコントローラ３２５による制御により、プリンタ１０２を駆動して印刷出力を行う。
データ放送印刷における印刷コンテンツの取得方法には、大きく分けると、プリントファイル方式とプリントＵＲＩ方式との２種類がある。

図４は、データ放送印刷におけるプリントファイル方式の実行手順の一例を説明する図である。図４では、図の上から下に向かって時間が進むものとする。
まず、印刷用コンテンツデータの実体をデータ放送用データから取得したＤＴＶ１０１は、印刷準備ができると、プリンタ１０２に対して印刷要求ジョブを発行（送信）する（ステップＳ４０１）。
印刷要求ジョブを受信したプリンタ１０２は、印刷用コンテンツデータの受付が可能であるか否かを判定し、可能であれば、印刷用コンテンツデータを受信するためのデータシンク領域を設定する。そして、プリンタ１０２は、データシンク領域の情報と共に、印刷可能であるというステータス情報をＤＴＶ１０１に返送する（ステップＳ４０２）。

これらの情報を印刷可能である旨の情報として受信したＤＴＶ１０１は、印刷用コンテンツデータをプリンタ１０２に転送する（ステップＳ４０３）。尚、印刷用コンテンツデータの転送はＨＴＴＰのＰＯＳＴ処理で行われる。
プリンタ１０２は、受信した印刷用コンテンツデータをデータシンク領域に格納すると共に、印刷用コンテンツデータを用いた印刷処理を開始する。尚、印刷処理の詳細は後述する。

図５は、データ放送印刷におけるプリントＵＲＩ方式の実行手順の一例を説明する図である。
プリントＵＲＩ方式では、ＤＴＶ１０１は、印刷用コンテンツデータの実体を取得せずに、印刷用コンテンツデータの保存先を示すアドレス情報（ＵＲＩ：Uniform Resource Indicator）をデータ放送用データから取得する。
印刷準備ができるとＤＴＶ１０１は、取得したアドレス情報（ＵＲＩ情報）を印刷要求ジョブとしてプリンタ１０２に発行（送信）する（ステップＳ５０１）。
印刷要求ジョブを受信したプリンタ１０２は、印刷が可能な状態であるか否かを判定する。そして、印刷が可能な状態であれば、プリンタ１０２は、アドレス情報（ＵＲＩ情報）に含まれているＵＲＩで示された場所（図５ではＵＲＩがＡＡＡの場所にある装置）にアクセスする（ステップＳ５０２）。
そして、プリンタ１０２は、印刷用コンテンツデータの実体（構造化文書データや付属するモノメディアデータ）を取得する（ステップＳ５０３）。尚、この印刷用コンテンツデータの取得は、ＨＴＴＰのＧＥＴ処理で行われる。印刷用コンテンツデータの実体を取得すると、ＤＴＶプリンタ１０２は印刷処理を開始する。

ＤＴＶ１０１とプリンタ１０２のネットワークプロトコルスタックには、ＵＰｎＰプロトコルの処理部がある。ＤＴＶ１０１は、電源投入時等に予め行われるＵＰｎＰのデバイス検出機能を用いたプリンタ検出機能に加えて、以下の機能を備える。すなわち、ＤＴＶ１０１は、ＵＰｎＰの手順に従った印刷要求ジョブの発行機能や、イベントによるステータスの取得といったプリンタ１０２の制御のためのＵＰｎＰによる通信機能を備える。
一方、プリンタ１０２は、ネットワークへの接続時に自デバイスのネットワーク加入を他のＵＰｎＰデバイスに対して通知する機能を備える。また、プリンタ１０２は、ＤＴＶ１０１等のプリントクライアントであるコントロールポイントから発行される印刷要求ジョブの受信機能を備える。更に、プリンタ１０２は、機器情報の問い合わせに対する応答機能や、自デバイスのエラー状態や印刷終了といったプリンタステータスの変化を、イベント機能を使ってコントロールポイントに発行するＵＰｎＰ通信機能を備える。

ここで、ＤＴＶ１０１とプリンタ１０２との間の通信プロトコルの一例であるＵＰｎＰについて説明する。
＜ＵＰｎＰの概要＞
ＵＰｎＰで通信を行うネットワーク（以下「ＵＰｎＰネットワーク」と称する）は、ピアツーピアのネットワークである。ＵＰｎＰネットワークにより、従来、ネットワーク機器を接続するために必要だった、ＩＰアドレスの設定やデバイスドライバのインストール等の煩雑な設定が不要になる。
ここでは、ＵＰｎＰネットワークの基本構成、プロトコル、及び実行ステップについてその概要を説明する。詳細についてはそれぞれの規格のドキュメントに記載されている。

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

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

図７は、ＵＰｎＰのプロトコルスタックの一例を示す図である。
ＨＴＴＰＵ、ＨＴＴＰＭＵは、ＨＴＴＰをＵＤＰへ拡張したものである。プロトコルで使用する基本メッセージ形式はＨＴＴＰである。ＨＴＴＰＵはユニキャスト通信で用いられ、ＨＴＴＰＭＵはマルチキャスト通信で用いられる。
ＳＳＤＰ（Simple Service Discovery Protocol）は、ネットワークサービスを検出する方法を定義している。ＳＳＤＰは、ＨＴＴＰＵ及びＨＴＴＰＭＵに基づいて作成されていて、コントロールポイントが関心のあるサービスを検出する方法と、デバイスがそのサービスを告知する方法を定義している。

ＧＥＮＡ（Generic Event Notification Architecture）は、ＨＴＴＰ及びＨＴＴＰＭＵを使用して通知を送受信する機能である。イベントを可能にするために通知のサブスクライバーやパブリッシャーの概念を定義している。
ＳＯＡＰ（Simple Object Access Protocol）は、ＲＰＣ（Remote Procedure Call）を実行するためのＸＭＬとＨＴＴＰの仕様を定義している。コントロールポイントは、ＳＯＡＰを使用してデバイスの制御を行う。

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

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

＜アドレッシング＞
このステップでは、ＵＰｎＰが基本とするＴＣＰ／ＩＰでの通信が可能になるようにＩＰアドレスの割り当てが行われる。ＵＰｎＰデバイスは少なくともＤＨＣＰ（Dynamic Host Configuration Protocol）クライアントを実装しなければならない。初めてネットワークに接続した場合、デバイスは、ＤＨＣＰサーバを探してアドレスを取得する。ＤＨＣＰサーバが見つからない場合、デバイスは、Ａｕｔｏ−ＩＰを使ってアドレスを取得しなければならない。Ａｕｔｏ−ＩＰは、ＩＡＮＡが定めるLink-localアドレス（IP Version 4では169.254/16）の範囲でランダムにアドレスを生成する。そして、Ａｕｔｏ−ＩＰは、ＡＲＰ（Address Resolution Protocol）を使って、生成したアドレスが既に使用されていないかどうかの確認と、そのアドレスの使用のアナウンスを行う。デバイスは、Ａｕｔｏ−ＩＰでＩＰアドレスを取得した場合、定期的にＤＨＣＰサーバを探し、ＤＨＣＰサーバが見つかればＤＨＣＰサーバからアドレスを取得する。

＜ディスカバリ＞
ＩＰアドレスの割り当てが終わると、次はディスカバリが行われる。デバイスは、ネットワークに追加すると、ＵＰｎＰのディスカバリプロトコルを使ってデバイスが持つサービスの告知を行う。同様にコントロールポイントがネットワークに追加されると、コントロールポイントは、デバイスのサーチを行う。
図８は、ＵＰｎＰのディスカバリプロトコルを使ってデバイスが告知を行う際の印刷システムにおける情報の流れの一例を示す図である。デバイスであるプリンタ１０２は、ＩＡＮＡがＳＳＤＰのために割り当てたマルチキャストアドレス（ポート239.255.255.250:1900）にＵＤＰマルチキャストパケットを送信して告知を行う。図８に示す例では、プリンタ１０２は、コントロールポイントであるＤＴＶ１０１、ＳＴＢ１１１、ＰＣ１１２に告知を行う。

図９は、デバイスがネットワークに追加され利用可能なことを示す告知パケットの一例を示す図である。告知パケットは、ＨＴＴＰＭＵを介して送信される。リクエストにはＧＥＮＡのNOTIFYメソッドを用いる。また、ＮＴＳヘッダは、ssdp:aliveでなければならない。その他、ヘッダには、告知の有効時間、デバイスディスクリプションＵＲＬ、告知のタイプ、サービスの固有名等が含まれる。また、メッセージのボディはなく空白行のみである。

図１０は、デバイスがネットワークから削除されつつあり利用できなくなることを示す告知パケットの一例を示す図である。リクエストにはＧＥＮＡのNOTIFYメソッドを用いる。また、ＮＴＳヘッダは、ssdp:byebyeでなければならない。
図１１は、コントロールポイントがＵＰｎＰのディスカバリプロトコルを使ってサーチを行い、デバイスが応答する際の印刷システムにおける情報の流れの一例を示す図である。コントロールポイントの一例のＤＴＶ１０１は、ＩＡＮＡがＳＳＤＰのために割り当てたマルチキャストアドレス（ポート239.255.255.250:1900）にＵＤＰマルチキャストパケット（サーチリクエストパケット）を送信してデバイスをサーチする。ＵＤＰマルチキャストパケット受けたデバイスの一例であるプリンタ１０２は、ＵＤＰユニキャストでサーチレスポンスパケットをコントロールポイントに送信して応答する。

図１２は、サーチリクエストパケットの一例を示す図である。サーチリクエストは、ＨＴＴＰＭＵを介して送信される。リクエストにはＭ−ＳＥＡＲＣＨメソッドを用いる。また、ＭＡＮヘッダは、ssdp:discoverでなければならない。ＳＴヘッダは、サーチターゲットである。また、メッセージボディはなく空白行のみである。
図１３は、サーチレスポンスパケットの一例を示す図である。サーチレスポンスはＨＴＴＰＵを介して送信される。レスポンスには、告知の有効時間、デバイスディスクリプションＵＲＬ、サーチターゲット、及び告知のサービス固有名等が含まれる。

＜ディスクリプション＞
ディスクリプションは、ＵＰｎＰネットワークの第２ステップであり、コントロールポイントがディスカバリでデバイスを見つけた後に行われる。このステップ（ディスクリプション）の後に、他のステップ（コントロール、イベンティング、プレゼンテーション）が可能になる。
図１４は、ディスクリプションを行う際の印刷システムにおける情報の流れの一例を示す図である。
コントロールポイント７１０は、デバイス７２０のデバイスディスクリプションＵＲＬをディスカバリにより取得した後、デバイス７２０に対してディスクリプションリクエスト１４０１を送信する。デバイス７２０は、ディスクリプションリクエスト１４０１に対し、ディスクリプションを含むディスクリプションレスポンス１４０２をコントロールポイント７１０に返信する。

図１５は、ディスクリプションリクエスト１４０１の一例を示す図である。ディスクリプションリクエスト１４０１は、HTTP GETメソッドを用いて送信される。
図１６は、ディスクリプションレスポンス１４０２の一例を示す図である。ＨＴＴＰメッセージのボディは、ＸＭＬで記述されたディスクリプションである。ＵＰｎＰにおいてディスクリプションには、デバイスディスクリプションとサービスディスクリプションとの２種類がある。

デバイスディスクリプションには、デバイス７２０が持つサービスのリストが含まれ、各サービスのサービスディスクリプションＵＲＬ、コントロールＵＲＬ、イベンティングＵＲＬ等が含まれる。また、デバイス７２０に埋め込まれた埋め込みデバイス７２２がある場合には、デバイスリストもデバイスディスクリプションに含まれる。
サービスディスクリプションには、サービス７２１、７２３をコントロールするためのアクションリストと、サービスの状態を示すサービスステータステーブルとが含まれる。アクションリストには、各アクションの「名前、引数、関連する状態変数、入出力の方向」が記述されている。サービスステートテーブルには、各状態変数の「名前、型、範囲、イベント特性」が記述されている。

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

＜コントロール＞
コントロールのステップでは、コントロールポイントがデバイスの持つサービスにリクエストを行い、デバイスを制御する。
図１７は、コントロールポイントがデバイスをコントロールする際の印刷システムにおける情報の流れの一例を示す図である。
コントロールポイント７１０は、ディスクリプションのステップで、デバイス７２０のデバイスディスクリプションとサービスディスクリプションとを取得した後、デバイス７２０をコントロールすることができる。コントロールポイント７１０は、アクションの実行（アクションリクエスト１７０１の送信）と結果の取得（アクションレスポンス１７０２の受信）とを行える。また、コントロールポイント７１０は、状態変数のクエリの実行（クエリリクエスト１７０３の送信）と状態変数の現在値の取得（クエリレスポンス１７０４の受信）とを行うことができる。

ＵＰｎＰのコントロールにはＳＯＡＰが使用される。ＳＯＡＰは、リモートプロシージャコールの実現のためにXML/HTMLの使用に関して定義している。コントロールメッセージは、ＳＯＡＰヘッダ及びボディエレメントをベースにフォーマットされＨＴＴＰを介して配信される。
コントロールポイント７１０は、デバイス７２０のデバイスディスクリプションから取得したコントロールＵＲＬへ、HTTP POSTないしM-POSTメソッドを用いてアクションリクエスト１７０１を送信する。

図１８は、アクションリクエスト１７０１の一例を示す図である。図１８に示す例では、リクエストラインにはＰＯＳＴメソッドが用いられている。CONTENT-TYPEは、text/xmlであり、charset="utf-8"でなければならない。SOAPACTIONにアクション名を含む。メッセージボディはＸＭＬで記述され、ＳＯＡＰで定義されたEnvelopeエレメントを含み、そのサブエレメントＢｏｄｙにアクション、引数等のサブエレメントを含む。
図１９は、アクションレスポンス１７０２の一例を示す図である。図１９に示す例では、成功レスポンスの一例を示している。レスポンスラインにはＨＴＴＰ成功コードが含まれる。メッセージボディはＸＭＬで記述され、ＳＯＡＰで定義されたEnvelopeエレメントを含み、そのサブエレメントボディにアクションレスポンスサブエレメントを含む。アクションに出力引数がある場合には、アクションレスポンス１７０２は、その引数をサブエレメントとして含む。

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

図２０は、イベンティングを行う際の印刷システムにおける情報の流れの一例を示す図である。
コントロールポイント７１０は、ディスクリプションで取得した「デバイス７２０のデバイスディスクリプション」のイベンティングＵＲＬへのＨＴＴＰリクエストによりイベンティングのリクエスト（サブスクリプションリクエスト２００１）を送信する。そして、コントロールポイント７１０は、ＨＴＴＰレスポンスによりイベンティングのレスポンス（サブスクリプションレスポンス２００２）を受信する。サブスクリプションリクエスト２００１には、イベントの通知要求を登録するサブスクリプションと、登録の期限が切れる前に登録の更新を要求するリニューと、登録の期限が切れる前に登録の取りやめを要求するキャンセルとの３種類がある。

図２１は、サブスクリプションリクエスト２００１の一例を示す図である。図２１に示す例では、リクエストラインには、ＧＥＮＡに定義されたSUBSCRIBEメソッドが用いられている。ヘッダには、イベントメッセージの送信先ＵＲＬと、通知タイプ（UPnP:event）等含まれる。メッセージのボディはなく空行のみである。
図２２は、サブスクリプションレスポンス２００２の一例を示す図である。図２２に示す例では、成功レスポンスの一例を示している。レスポンスラインにはＨＴＴＰ成功コードが含まれている。ヘッダには、サブスクリブションを特定するＩＤや、サブスクリプションの有効時間等が含まれている。

サブスクリプションの更新リクエスト２００３は、SUBSCRIBEメソッドを用いて、ヘッダにサブスクリプションＩＤを設定することにより行われる。この更新リクエスト２００３に対して更新レスポンス２００４がなされる。
サブスクリプションのキャンセルリクエスト２００５は、UNSUBSCRIPTメソッドを用いてヘッダにサブスクリプションＩＤを設定することにより行われる。
デバイス７２０のサービス７２１（パブリッシャー）は、サブスクリプションリクエスト２００１に含まれるイベントメッセージの送信先ＵＲＬへのＨＴＴＰリクエストにより、コントロールポイント７１０、１３００にイベントメッセージ２００６を送信する。イベントメッセージ２００６を受信した「サブスクライバーであるコントロールポイント７１０、１３００」は、ＨＴＴＰレスポンスをデバイス７２０のサービス７２１（パブリッシャー）返す。

図２３は、イベントメッセージ２００６の一例を示す図である。リクエストラインにはNOTIFYメソッドが用いられる。ヘッダには、CONTENT-TYPE（text/xml）、ＮＴ（upnp:event）、ＮＴＳ（upnp:propchange）、ＳＩＤ（uuid:＜subscription ID＞）等が含まれる。メッセージボディは、ＸＭＬで記述される。propertysetエレメントには、状態変数をサブエレメントに持つpropertyサブエレメントが必要なだけ含まれる。

＜プレゼンテーション＞
プレゼンテーションのステップでは、デバイスが持つＷｅｂサービスをブラウザに表示する。これによりＷｅｂページからデバイスの制御や、サービスの状態の表示ができる。
図２４は、ブラウザがデバイスのプレゼンテーションページにアクセスする際の印刷システムにおける情報の流れの一例を示す図である。
コントロールポイント７１０は、デバイス７２０のデバイスディスクリプションに含まれるプレゼンテーションＵＲＬを取得すると、ブラウザ１４００を使って、デバイス７２０のプレゼンテーションページを表示することができる。ブラウザ１４００は、デバイス７２０のプレゼンテーションＵＲＬへプレゼンテーションリクエスト２４０１を送信し、HTTP GETすることによりプレゼンテーションページ２４０２を取得する。デバイス７２０は、プレゼンテーションページを介して、サービス７２１のコントロール手段と状態表示手段とをコントロールポイント７１０に提供することができる。
以上が、ＵＰｎＰの概要である。

続いて、印刷及びステータス通知処理の詳細について説明する。
図２５は、プリンタ１０２のネットワークコントローラ３０１におけるソフトウェアモジュールの構成の一例を示す図である。
プリントコントロールポイントであるＤＴＶ１０１から、ＵＰｎＰの印刷要求コマンドであるCreateJobV2又はCreateURLJobをインタフェースモジュール６０１が受信すると、プリンタ１０２は印刷処理を開始する。
印刷要求コマンドがCreateJobV2の場合、インタフェースモジュール６０１は、ＨＴＴＰプロトコルを使ったＰＯＳＴで送りつけられる印刷用コンテンツデータ１１０を取り込む。一方、印刷要求コマンドが、CreateURLJobの場合、インタフェースモジュール６０１は、印刷要求コマンドに付随するＵＲＩ情報に基づき、ＨＴＴＰのＧＥＴを使って印刷用コンテンツデータ６２０を取得する。

インタフェースモジュール６０１は、取得した印刷用コンテンツデータ１１０を、パース処理モジュール６０２に渡す。インタフェースモジュール６０１は、プリンタコントローラ３０２からプリンタ１０２の内部状態（ステータス）を取得し、そのステータスを示すプリンタステータス情報をＵＰｎＰイベンティングの機能を使い、ＤＴＶ１０１に送信する機能も有している。更に、インタフェースモジュール６０１は、プリンタコントローラ３０２に対してＤＴＶ１０１からのコマンドやネットワークコントローラ３０１からのコマンドを送信する機能を有する。
尚、インタフェースモジュール６０１は、前述したプリントファイル方式に従いＤＴＶ１０１から印刷用コンテンツデータ１１０を直接受信することができる。また、インタフェースモジュール６０１は、前述したプリントＵＲＩ方式に従い、ＤＴＶ１０１から印刷用コンテンツデータ１１０の保存先を示すＵＲＩを取得し、そのＵＲＩに基づいて印刷用コンテンツデータ１１０の実体を取得することもできる。
パース処理モジュール６０２は、印刷用コンテンツデータ１１０の実体をＤＲＡＭ３１２に格納した後、印刷用コンテンツデータ１１０に含まれる構造化文書データであるXHTML-PrintファイルやCSSPPファイルを解釈する。

レイアウト処理モジュール６０３は、フォント処理モジュール６０４から得られるフォント情報を使用して、印刷用コンテンツデータ１１０に基づく画像のレイアウトを行う。そして、レンダリング処理モジュール６０５は、フォント処理モジュール６０４から得られるフォントデータを使用して、印刷イメージデータを生成する。印刷イメージデータは、バンディングモジュール６０６及びラスタライズモジュール６０７による処理を経てプリントアウトされる。このとき、ネットワークコントローラ３０１で生成された印刷イメージデータは、シリアルＩＯ３１６を経由してプリンタコントローラ３０２に転送される。プリンタコントローラ３０２は、送信された印刷イメージデータを印刷するために、プリンタエンジンコントローラ３２５による制御により、プリンタ１０２を駆動して印刷出力を行う。
また、記述変更処理モジュール６０８は、パース処理モジュール６０２とレイアウト処理モジュール６０３の処理結果に基づいて印刷用コンテンツデータ１１０の記述を変更し、ＨＴＴＰサーバモジュール６０９に出力する。ＨＴＴＰサーバモジュール６０９は、図示しないＨＴＴＰサーバに、記述を変更した印刷用コンテンツデータ１１０を出力する。

図２６は、イベントを発行する際のプリンタ１０２の動作の一例を説明するフローチャートである。プリンタ１０２は、プリンタ１０２のステータスをＤＴＶ１０１に応答するための手段としてＵＰｎＰのイベンティング仕様に基づいたイベント処理モジュールを有する。
プリントコントロールポイント（例えばＤＴＶ１０１）からイベントの登録コマンドを受信すると（ステップＳ２６０１）、プリンタ１０２は、登録元のコントローラの情報を記憶する（ステップＳ２６０２）。次に、プリンタ１０２は、登録時点でのプリンタ１０２のステータスを初期イベントとして発行する（ステップＳ２６０３）。
次に、プリンタ１０２は、プリンタ１０２のステータスを監視（モニタリング）した上で、イベントの発行条件がそろうまで、すなわちイベントデータ（プリンタ１０２のステータス）に変化が生じるまで待機する（ステップＳ２６０４）。

そして、イベントデータ（プリンタ１０２のステータス）に変化が生じると、プリンタ１０２は、登録されたプリントコントロールポイントに対してイベントを発行する。イベントデータには、待機状態（idle）、処理状態(processing)、停止状態（stopped）といったプリンタ１０２の基本ステータス（printer state）が定義されている。この他、イベントデータには、エラー状態の詳細を示す「基本ステータスを補完するプリンタ１０２の詳細ステータス(printer state reasons)」をはじめ、プリンタ１０２の構成情報等のデータが定義されている。

このとき、プリンタ１０２は、イベントを管理するために、プリンタコントローラ３０２からプリンタステータス情報を取得し、そのプリンタステータス情報をイベントデータの該当エレメントに代入する。プリンタステータス情報に変化が生じていることで、エレメントの値に変化が生じることが検出されると、プリンタ１０２は、該当エレメントをデータに含むイベントの発行処理を行う（ステップＳ２６０５）。

一方、ＤＴＶ１０１は、放送を利用して送信される印刷用コンテンツデータ１１０又はその格納場所を示すＵＲＩを取得することが可能である。図２７は、印刷を指示する際のＤＴＶ１０１の動作の一例を説明するフローチャートである。
ネットワークＩ／Ｆ２１２の制御用プログラムＲＯＭには、ＵＰｎＰに基づきコントロールポイントとしてプリンタ１０２と通信を行う制御プログラムが格納されている。
ＤＴＶ１０１は、放送データに、印刷用コンテンツデータ１１０又は印刷用コンテンツデータ１１０のＵＲＬが含まれているか否かを判定する（ステップＳ２７０１）。この判定の結果、放送データに、印刷用コンテンツデータ１１０又は印刷用コンテンツデータ１１０のＵＲＬが含まれていない場合には、図２７のフローチャートによる処理を終了する。

一方、放送データに、印刷用コンテンツデータ１１０又は印刷用コンテンツデータ１１０のＵＲＬが含まれる場合、ＤＴＶ１０１は、放送データに付随される表示制御スクリプト（ＢＭＬ）に基づいて表示画面に印刷指示ボタンを表示する（ステップＳ２７０２）。
次に、ＤＴＶ１０１は、ユーザからの印刷指示を入力するまで待機する（ステップＳ２７０３）。そして、ユーザのリモコン操作等による印刷指示があると、ＤＴＶ１０１は、次の処理を行う（ステップＳ２７０４）。すなわち、ＤＴＶ１０１は、ＵＰｎＰのプリントコントロール仕様に基づく印刷要求コマンド（CreateJobV2又はCreateURLJob）と共に、印刷用コンテンツデータ１１０又はそのＵＲＬの情報を、予め発見したプリンタ１０２に発行する。尚、ＤＴＶ１０１は、印刷要求コマンドの発行前に、ＵＰｎＰのイベンティング仕様に基づいて、プリンタ１０２のステータス（状態）の変化に関するイベント通知の要求をプリンタ１０２に予め登録しておく。これにより、ＤＴＶ１０１は、プリンタ１０２においてステータスの変化が生じた際にイベントを受信することができるようになっている。

そして、ＤＴＶ１０１は、プリンタ１０２から、イベントを受信したか否かを判定する（ステップＳ２７０５）。この判定の結果、イベントを受信していない場合には、図２７のフローチャートによる処理を終了する。一方、イベントを受信した場合には、ＤＴＶ１０１は、そのイベントで通知されるプリンタステータス情報に応じて、ユーザへの注意喚起が必要か否かを判定する（ステップＳ２７０６）。この判定の結果、ユーザへの注意喚起が必要でない場合には、図２７のフローチャートによる処理を終了する。一方、ユーザへの注意喚起が必要な場合、ＤＴＶ１０１は、出力部２０９が備えるモニタに、放送画面表示に対するオーバーレイ表示としてメッセージを表示する（放送画面表示の前面にメッセージを表示する。
図２８は、ＤＴＶ１０１の出力部２０９（モニタの表示画面）に、ユーザへの注意喚起を行うためのメッセージの一例が表示された状態を示す図である。
このようにして放送画面表示の前面に表示されるメッセージ９０１を長時間表示し続けると放送の閲覧の妨げになる。したがって、本実施形態では、このメッセージ９０１は、イベントに含まれるプリンタステータス情報の変化がなければ、一定時間後（例えば、５〜１０秒後）に消える構成にしている。

次に、このような構成において、ＤＴＶ１０１からの印刷要求に従いプリンタ１０２が印刷処理を行う際、プリンタ１０２において給紙エラーが発生するケースを例に挙げて、本実施形態の印刷システムの動作を説明する。
ＤＴＶ１０１から印刷要求を受けたプリンタ１０２は、印刷用コンテンツデータ１１０の実体を取得してレンダリングした後に印刷出力を開始する。その際、プリンタステータス情報は、アイドル状態から印刷状態に推移する。このプリンタステータス情報の変化に伴いイベントがプリンタ１０２からＤＴＶ１０１に対して発行される。

図２９は、プリンタステータス情報（プリンタ１０２の基本ステータス情報）がアイドル状態から印刷状態に推移した際に発行されるＵＰｎＰのイベントデータのうち、ＵＰｎＰの印刷仕様で定義されている標準的な部分の一例を示す図である。
図２９において、基本ステータス情報は、<PrinterState>１００１とステータス詳細変数<PrinterStateReasons>１００２とで表される。プリンタ１０２がアイドル状態から印刷状態に移行する際には<PrinterState>１００１がidleからprocessingに変わる。一方、<PrinterStateReasons>１００２はnoneのままである。

このようなイベントデータを受信したＤＴＶ１０１は、メッセージのオーバーレイ表示の必要性をプリンタステータス情報の変化から判定する。プリンタ１０２がアイドル状態から印刷状態に推移した場合、ＤＴＶ１０１は、印刷開始に伴う正常動作範囲内のステータス情報の変化と判断し、ＤＴＶ１０１の出力部２０９（モニタの表示画面）の前面へのメッセージの表示を行わない。

次に、用紙への記録開始に伴いプリンタ１０２は、記録用紙の給紙を行う。ここで、本実施形態の特徴的な部分を説明するために、プリンタ１０２の用紙ビンには紙が存在せず、プリンタ１０２が給紙動作を行った結果、用紙がない状態、すなわち給紙エラーが発生した場合を例に挙げて、印刷システムの動作の一例を説明することとする。

プリンタ１０２が給紙を行った結果、給紙エラーが発生すると、プリンタステータス情報（プリンタ１０２の基本ステータス情報）は印刷処理中状態からエラー状態へと推移する。このプリンタステータス情報の変化に伴い、ＤＴＶ１０１にイベントデータが通知される。
図３０は、印刷処理中状態からエラー状態へと推移したときに発行されるイベントデータの一例を示す図である。
プリンタ１０２が印刷処理中状態から紙なし給紙エラーによるエラー状態（停止状態）に移行することで、<PrinterState>１００１はprocessingからstoppedに変わる。また、<PrinterStateReasons>１００２はnoneからmedia-emptyに変わる。

このようなイベントデータを受信したＤＴＶ１０１は、メッセージ表示の必要性について判定処理を行う。まず、ＤＴＶ１０１は、受信したイベントデータに含まれるステータス情報の内容を判定する。図３０に示す例の場合、ＤＴＶ１０１は、給紙エラーの発生に伴うステータス変化が発生したと判断する。このようなエラーの場合、ＤＴＶ１０１は、ユーザへの注意とエラー回避処理の催促とを喚起するためのメッセージ（すなわち、給紙可能な用紙をセットすることを喚起するための所定のメッセージ）を画面上にオーバーレイ表示する処理を行う。

このように、プリンタ１０２からイベントデータを受信したＤＴＶ１０１は、必要に応じて画面上にメッセージをオーバーレイ表示する。しかしながら、前述したように、オーバーレイ表示するメッセージは放送閲覧の妨げを防止するため、一定時間後に消える仕組みとなっている。例えば、一回の表示時間が予め定められた時間（Ｔ＝１０秒）が経過した後に消える仕組みとなっているとする。この場合、給紙エラーの発生に伴うプリンタステータス情報が変化したイベントデータが一回限りである場合、又は最初のイベントデータの通知から１０秒以内に再度イベントデータが通知されない場合には、オーバーレイ表示されたメッセージは非表示となる。

一方、前述したように、本実施形態のＤＴＶ１０１とプリンタ１０２との間の通信で使われるＵＰｎＰプロトコルの仕様では、イベントデータは、通知すべきデータ、すなわちプリンタステータス情報に変化が生じた場合にのみ発行可能であると規定されている。規格で規定されているプリンタステータス情報の変化にのみ基づいたイベントデータの発行を行う場合、プリンタ１０２が正常（印刷開始）状態からエラー（給紙エラー）状態へ推移することに伴い、イベントデータは一回発行される。しかしながら、以降エラー状態が解消されてステータス情報が再変化しない限りはイベントデータの発行は行われない。イベントデータに伴うオーバーレイ表示の表示時間についてのＤＴＶ１０１の仕様が１０秒であるとする。そうすると、ユーザはメッセージの表示が開始されてから１０秒の表示期間が経過するまでの間に画面を見てメッセージ表示を認識しない限りは給紙エラーが起きていることをＤＴＶ１０１の画面上で確認することが出来ない。これにより、プリンタ１０２のエラー状態が気づかれないままとなってしまう。

本実施形態では、このような不都合を以下のようにして解決するようにしている。
図３１は、イベントデータを発行する際のプリンタ１０２の動作の一例を説明するフローチャートである。
プリンタ１０２は、ＤＴＶ１０１から印刷要求コマンド（例えばCreateJobV2）を受信したか否かを判定する（ステップＳ３１０１）。この判定の結果、ＤＴＶ１０１から印刷要求コマンドを受信していない場合には、図３１のフローチャートによる処理を終了する。一方、ＤＴＶ１０１から印刷要求コマンドを受信した場合には、ステップＳ３１０２に進む。

プリンタ１０２には、プリンタ１０２における、ある所定のステータス継続時間を増加する値として表す変数state＿duration（以下必要に応じて「state＿duration変数」と称する）が状態識別情報の一例として定義されている。これにより、プリンタ１０２のステータスが変更された際に、その状態が継続される間、state＿duration変数は予め定められた時間が経過する毎にカウントアップされる。
本実施形態においては、そのカウントアップされる周期（以下「カウントアップ周期」と称する）は、ＤＴＶ１０１のメッセージ表示継続時間Ｔから１秒短い時間Ｄとなっている。ＤＴＶ１０１は、メッセージ表示継続時間Ｔ（例えば１０秒）を、印刷要求コマンドの中に変数として含めて発行することができる。したがって、プリンタ１０２は、メッセージ表示継続時間Ｔを知ることが可能となり、カウントアップ周期Ｄを求めることができる。

プリンタ１０２は、メッセージ表示継続時間Ｔがメッセージ要求コマンドに含まれているか否かを判定する（ステップＳ３１０２）。この判定の結果、メッセージ表示継続時間Ｔがメッセージ要求コマンドに含まれている場合、プリンタ１０２は、メッセージ表示継続時間Ｔから１を減算してカウントアップ周期Ｄを算出する（ステップＳ３１０３）。そして、プリンタ１０２は、プリンタ１０２に内蔵されているタイマのカウントを開始する。
一方、メッセージ表示継続時間Ｔがメッセージ要求コマンドに含まれていない場合、プリンタ１０２は、予め設定されている時間（ここでは５秒とする）をカウントアップ周期Ｄとして設定する（ステップＳ３１０４）。そして、プリンタ１０２は、プリンタ１０２に内蔵されているタイマのカウントを開始する。

以上のようにしてカウントアップ周期Ｄを求めると、プリンタ１０２は、プリンタ１０２のステータス（状態）に変化があったか否かを判定する（ステップＳ３１０５）。この判定の結果、プリンタ１０２のステータス（状態）に変化があった場合には、後述するステップＳ３１０８に進む。
一方、プリンタ１０２のステータス（状態）に変化がない場合、プリンタ１０２は、タイマのカウント値に基づいて、カウントアップ周期Ｄが経過したか否かを判定する（ステップＳ３１０６）。この判定の結果、カウントアップ周期Ｄが経過していない場合には、ステップＳ３１０５に戻り、カウントアップ周期Ｄが経過するまでステップＳ３１０５、Ｓ３１０６を繰り返し行う。

一方、カウントアップ周期Ｄが経過した場合、プリンタ１０２は、state＿duration変数の値に１を加算する（ステップＳ３１０７）。
そして、プリンタ１０２は、ステップＳ３１０７で加算したstate＿duration変数に基づく情報を含むイベントデータをＤＴＶ１０１に発行すると共に、タイマをリセットする（ステップＳ３１０８）。

プリンタ１０２の状態に変化があり、ステップＳ３１０５からステップＳ３１０８に進んだ場合には、現在のstate＿duration変数に基づく情報を含むイベントデータをＤＴＶ１０１に発行すると共に、タイマをリセットすることになる。また、プリンタ１０２の状態がエラー状態から正常状態に変化した場合には、これらの処理に加え、state＿duration変数の値をリセットする。

最後に、プリンタ１０２は、ステップＳ３１０１で受信した印刷要求コマンドに基づく印刷処理が終了したか否かを判定する（ステップＳ３１０９）。この判定の結果、印刷処理が終了した場合には、図３１のフローチャートによる処理を終了する。一方、印刷処理が終了していない場合には、ステップＳ３１０５に戻り、印刷処理が終了するまでステップＳ３１０５〜Ｓ３１０９を繰り返し行う。

次に、state＿duration変数の詳細について説明する。
state＿duration変数は、イベントとしてＤＴＶ１０１に通知すべきステータスデータ構造体に含まれる。ステータスデータ構造体に含まれるエレメントの中に<PrinterStateDuration>というエレメントが存在し、そこにstate＿duration変数の値が反映される。すなわち、state＿duration変数の値がインクリメントされると、それに伴い<PrinterStateDuration>の値もインクリメントされる仕組みになっている。図３０に示す例では、エレメント１１０１がこれに相当する。

このように本実施形態では、state＿duration変数の値に応じた値を有する<PrinterStateDuration>をイベントデータに含めるようにしている。これにより、あるプリンタ１０２の状態が発生した場合、その状態の推移に伴うステータス情報の変化時にイベントが発行されるのは勿論のこと、以下のような効果が得られる。すなわち、プリンタ１０２の状態が継続した場合においては、カウントアップ周期Ｄ毎のstate＿duration変数のインクリメントによる<PrinterStateDuration>エレメントの変化に伴い、ステータス情報に変化が生じる。このため、カウントアップ周期Ｄ毎に、すなわち定期的に、ステータス情報が変化するイベントデータが発行されることとなる。本実施形態では、この<PrinterStateDuration>エレメントの変化に伴い、イベントデータの発行は、ステータスの分類がエラー状態のときに行われることになっている。

メッセージ表示継続時間Ｔとして１０秒がメッセージ要求コマンドに含まれている場合には、次のようにしてイベントデータが発行されることになる。例えば、紙なしエラーが発生すると、プリンタ１０２は、状態推移に伴うイベントデータをＤＴＶ１０１に発行する。そして、このイベントデータを発行した後、紙なしエラーが解消されて、状態推移が行われるまで、プリンタ１０２は、Ｔ−１秒、すなわち９秒毎にstate＿duration変数をインクリメントする。それに伴い、プリンタ１０２は、<PrinterStateDuration>の値がインクリメントされたイベントデータを９秒毎にＤＴＶ１０１に発行する。

このイベントデータを受信したＤＴＶ１０１は、その都度イベントデータに含まれるプリンタステータス情報を判定する。例えば、紙なしエラーの発生に伴うイベントデータを受信した場合、ＤＴＶ１０１は、所定のメッセージを画面上にオーバーレイ表示する。前述した例では、一回のメッセージ表示継続時間Ｔが１０秒であり、イベントデータの発行周期は９秒となっている。このため、メッセージが消える前に次のメッセージを表示する要求がプリンタ１０２からＤＴＶ１０１に行われることになる。したがって、紙なしエラーの状態が継続している間、メッセージの表示を途切れることなく継続的に行うことができる。図３２は、メッセージを表示するタイミングの一例を説明する図である。具体的に図３２（ａ）は、本実施形態のようにstate＿duration変数を用いずにメッセージを表示するタイミングを制御する従来の方法を示す図である。また、図３２（ｂ）は、state＿duration変数を用いてメッセージを表示するタイミングを制御する本実施形態の方法を示す図である。

ユーザがエラー状態に気づき、プリンタ１０２への用紙補充といったエラー回復作業を行うまでステータスは不変のため、この周期的なイベントデータは発行され続ける。ユーザによるエラー回復作業が完了した場合、プリンタ１０２の状態がエラー状態から正常状態へと推移すると、状態継続の解除に伴い、プリンタ１０２は、state＿duration変数の値をリセットする。そして、プリンタ１０２は、正常状態への移行タイミングで状態推移に伴う<PrinterState>をprocessingに、<PrinterStateReasons>をnoneにセットしたイベントデータの発行を行う。

一方、ＤＴＶ１０１は、イベントデータに含まれるステータス情報の判定を行う。そして、ＤＴＶ１０１は、<PrinterState>のstoppedからprocessingへの移行、すなわち正常状態の検出に伴いメッセージの表示を終了する。したがって、結果的に、プリンタ１０２の給紙エラーが発生した時点からエラーが解消されるタイミングまで、継続的にエラーメッセージが表示されることになる。

前述したように、ＤＴＶ１０１においては、エラー状態が継続している最中に受信するイベントデータの<PrinterStateDuration>の値はインクリメントされている。ＤＴＶ１０１は、この値をモニタリング（監視）することで、エラー状態の継続時間を知ることが可能である。これによりエラー状態の継続時間によって制御を変えることが可能となる。例えばエラー状態が長時間続く場合、ユーザがそのエラー状態を未だ認識していない可能性が高い。したがって、ＤＴＶ１０１は、エラー状態の継続時間が一定時間を超えたと判定した場合、すなわち<PrinterStateDuration>の値が所定の値を超えたと判定した場合、メッセージの内容を強い喚起を促す内容の表示に変更することができる。

状態継続変数<PrinterStateDuration>のさらなる活用方法として、エラー状態におけるプリンタ１０２の動作確認が挙げられる。プリンタ１０２から通知されるイベントデータに含まれるステータス情報において、エラー状態の判定基準となる基本ステータス変数<PrinterState>とステータス詳細変数<PrinterStateReasons>が変わらない場合がある。すなわち、<PrinterState>とステータス詳細変数<PrinterStateReasons>で表される状態が継続している状態の場合がある。このような場合にもかかわらず、<PrinterStateDuration>の値が変化しない場合、なんらかの理由によりプリンタ１０２からイベントデータが発行されていないか、イベントデータがＤＴＶ１０１で受信されていない可能性がある。そこでＤＴＶ１０１は、<PrinterState>と<PrinterStateReasons>と<PrinterStateDuration>とに基づき、プリンタ１０２が正常に動作していない可能性があることを検出する。例えば、ＤＴＶ１０１は、前述したような状態が予め設定された一定時間継続した場合に、プリンタ１０２が正常に動作していない（異常である）と判定し、判定した結果に応じた処理（例えば、異常を知らせるメッセージの表示）を実行する。

また、ＤＴＶ１０１に表示されたメッセージを確認した場合、ユーザによっては、そのメッセージが邪魔に感じることがある。したがって、ユーザがリモコン装置等を操作して、ＤＴＶ１０１に対してメッセージの表示を解除する指示を行うと、ＤＴＶ１０１は、プリンタ１０２の状態が継続していてもメッセージの表示を強制的に解除するようにするのが好ましい。

以上のように本実施形態では、例えばプリンタ１０２の状態が継続していることを、時間に応じて変化する値として表すstate＿duration変数に基づく<PrinterStateDuration>エレメントをイベントデータに含める。そして、<PrinterStateDuration>エレメントの値の変化をきっかけにしてイベントデータをプリンタ１０２からＤＴＶ１０１に発行する。このとき、state＿duration変数を更新するカウントアップ周期Ｄを、メッセージ表示継続時間Ｔよりも短くする。これにより、ＵＰｎＰ等の通信プロトコルに則った上で定期的にイベントデータを発行でき、１回のイベントデータの受信に基づき一定期間（のみ）メッセージ（エラー）の表示を行うＤＴＶ１０１等のデータ処理装置でも継続的にメッセージを表示できる。

（本発明の他の実施形態）
前述した本発明の実施形態における通信システムを構成する各手段、並びにデバイス状態表示方法の各ステップは、コンピュータのＲＡＭやＲＯＭなどに記憶されたプログラムが動作することによって実現できる。このプログラム及び前記プログラムを記録したコンピュータ読み取り可能な記録媒体は本発明に含まれる。

また、本発明は、例えば、システム、装置、方法、プログラム若しくは記憶媒体等としての実施形態も可能であり、具体的には、複数の機器から構成されるシステムに適用してもよいし、また、一つの機器からなる装置に適用してもよい。

尚、本発明は、前述した実施形態の機能を実現するソフトウェアのプログラム（実施形態では図２６、図２７、図３１に示すフローチャートに対応したプログラム）を、システムあるいは装置に直接、あるいは遠隔から供給するものを含む。そして、そのシステムあるいは装置のコンピュータが前記供給されたプログラムコードを読み出して実行することによっても達成される場合も本発明に含まれる。

したがって、本発明の機能処理をコンピュータで実現するために、前記コンピュータにインストールされるプログラムコード自体も本発明を実現するものである。つまり、本発明は、本発明の機能処理を実現するためのコンピュータプログラム自体も含まれる。

その場合、プログラムの機能を有していれば、オブジェクトコード、インタプリタにより実行されるプログラム、ＯＳに供給するスクリプトデータ等の形態であってもよい。

プログラムを供給するための記録媒体としては、例えば、フロッピー（登録商標）ディスク、ハードディスク、光ディスク、光磁気ディスク、ＭＯ、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷなどがある。また、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＤＶＤ（ＤＶＤ−ＲＯＭ，ＤＶＤ−Ｒ）などもある。

その他、プログラムの供給方法としては、クライアントコンピュータのブラウザを用いてインターネットのホームページに接続する。そして、前記ホームページから本発明のコンピュータプログラムそのもの、若しくは圧縮され自動インストール機能を含むファイルをハードディスク等の記録媒体にダウンロードすることによっても供給できる。

また、本発明のプログラムを構成するプログラムコードを複数のファイルに分割し、それぞれのファイルを異なるホームページからダウンロードすることによっても実現可能である。つまり、本発明の機能処理をコンピュータで実現するためのプログラムファイルを複数のユーザに対してダウンロードさせるＷＷＷサーバも、本発明に含まれるものである。

また、本発明のプログラムを暗号化してＣＤ−ＲＯＭ等の記憶媒体に格納してユーザに配布し、所定の条件をクリアしたユーザに対し、インターネットを介してホームページから暗号化を解く鍵情報をダウンロードさせる。そして、ダウンロードした鍵情報を使用することにより暗号化されたプログラムを実行してコンピュータにインストールさせて実現することも可能である。

また、コンピュータが、読み出したプログラムを実行することによって、前述した実施形態の機能が実現される。その他、そのプログラムの指示に基づき、コンピュータ上で稼動しているＯＳなどが、実際の処理の一部又は全部を行い、その処理によっても前述した実施形態の機能が実現され得る。

さらに、記録媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれる。その後、そのプログラムの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部又は全部を行い、その処理によっても前述した実施形態の機能が実現される。

尚、前述した各実施形態は、何れも本発明を実施するにあたっての具体化の例を示したものに過ぎず、これらによって本発明の技術的範囲が限定的に解釈されてはならないものである。すなわち、本発明はその技術思想、又はその主要な特徴から逸脱することなく、様々な形で実施することができる。

本発明の実施形態を示し、印刷システムの構成の一例を示す図である。 本発明の実施形態を示し、ＤＴＶの内部構成の一例を示す図である。 本発明の実施形態を示し、プリンタの内部構成の一例を示す図である。 本発明の実施形態を示し、データ放送印刷におけるプリントファイル方式の実行手順の一例を説明する図である。 本発明の実施形態を示し、データ放送印刷におけるプリントＵＲＩ方式の実行手順の一例を説明する図である。 本発明の実施形態を示し、ＵＰｎＰネットワークの基本構成の一例を示す図である。 本発明の実施形態を示し、ＵＰｎＰのプロトコルスタックの一例を示す図である。 本発明の実施形態を示し、ＵＰｎＰのディスカバリプロトコルを使ってデバイスが告知を行う際の印刷システムにおける情報の流れの一例を示す図である。 本発明の実施形態を示し、デバイスがネットワークに追加され利用可能なことを示す告知パケットの一例を示す図である。 本発明の実施形態を示し、デバイスがネットワークから削除されつつあり利用できなくなることを示す告知パケットの一例を示す図である。 本発明の実施形態を示し、コントロールポイントがＵＰｎＰのディスカバリプロトコルを使ってサーチを行い、デバイスが応答する際の印刷システムにおける情報の流れの一例を示す図である。 本発明の実施形態を示し、サーチリクエストパケットの一例を示す図である。 本発明の実施形態を示し、サーチレスポンスパケットの一例を示す図である。 本発明の実施形態を示し、ディスクリプションを行う際の印刷システムにおける情報の流れの一例を示す図である。 本発明の実施形態を示し、ディスクリプションリクエストの一例を示す図である。 本発明の実施形態を示し、ディスクリプションレスポンスの一例を示す図である。 本発明の実施形態を示し、コントロールポイントがデバイスをコントロールする際の印刷システムにおける情報の流れの一例を示す図である。 本発明の実施形態を示し、アクションリクエスト１７０１の一例を示す図である。 本発明の実施形態を示し、アクションレスポンスの一例を示す図である。 本発明の実施形態を示し、イベンティングを行う際の印刷システムにおける情報の流れの一例を示す図である。 本発明の実施形態を示し、サブスクリプションリクエストの一例を示す図である。 本発明の実施形態を示し、サブスクリプションレスポンスの一例を示す図である。 本発明の実施形態を示し、イベントメッセージの一例を示す図である。 本発明の実施形態を示し、ブラウザがデバイスのプレゼンテーションページにアクセスする際の印刷システムにおける情報の流れの一例を示す図である。 本発明の実施形態を示し、プリンタのネットワークコントローラにおけるソフトウェアモジュールの構成の一例を示す図である。 本発明の実施形態を示し、イベントを発行する際のプリンタの動作の一例を説明するフローチャートである。 本発明の実施形態を示し、印刷を指示する際のＤＴＶの動作の一例を説明するフローチャートである。 本発明の実施形態を示し、ＤＴＶの出力部（モニタの表示画面）に、ユーザへの注意喚起を行うためのメッセージの一例が表示された状態を示す図である。 本発明の実施形態を示し、プリンタの基本ステータス情報がアイドル状態から印刷状態に推移した際に発行されるＵＰｎＰのイベントデータのうち、ＵＰｎＰの印刷仕様で定義されている標準的な部分の一例を示す図である。 本発明の実施形態を示し、印刷処理中状態からエラー状態へと推移したときに発行されるイベントデータの一例を示す図である。 本発明の実施形態を示し、イベントデータを発行する際のプリンタの動作の一例を説明するフローチャートである。 本発明の実施形態を示し、メッセージを表示するタイミングの一例を説明する図である。

符号の説明

１０１ ＤＴＶ
１０２ ＤＴＶプリンタ
１０８ ホームネットワーク
２０１ ＣＰＵ
２０９ 出力部
３０１ ネットワークコントローラ
３０２ プリンタコントローラ

Claims (7)

1. デバイスと、当該デバイスに対して処理を要求するデータ処理装置とが通信可能に相互に接続された通信システムであって、
   前記デバイスは、
   当該デバイスにおいて特定の状態が継続している時間に応じて、前記特定の状態が継続していることを示す状態識別情報を変更する変更手段と、
   前記変更手段により状態識別情報が変更されたことに応じて、前記デバイスが前記状態識別情報に対応する特定の状態であること示す通知を前記データ処理装置に送信する送信手段とを有し、
   前記データ処理装置は、
   前記デバイスから前記デバイスが前記特定の状態であることを示す通知を受信する受信手段と、
   前記受信手段により前記通知が受信される度に、前記デバイスが前記特定の状態であることを、予め定められた表示時間だけ表示装置に表示するための表示手段とを有し、
   前記変更手段は、前記状態識別情報を変更する周期を、前記表示時間よりも短くし、
   前記送信手段は、前記デバイスの状態に変化があったことに応じて、デバイスの状態を示す通知を前記データ処理装置に対して送信するプロトコルを用いており、
   前記変更手段が状態識別情報を変更することで、前記デバイスが継続して前記特定の状態であったとしても、前記プロトコルを用いて前記デバイスが前記特定の状態であることを示す通知を再度、前記データ処理装置に送信することを特徴とする通信システム。
2. 前記送信手段が送信する通知には前記状態識別情報が含まれ、
   前記データ処理装置は、前記受信手段が受信した通知に含まれる前記状態識別情報に基づいて、前記デバイスの前記特定の状態の継続が一定時間を超えたことを検出する検出手段を有し、
   前記表示手段は、前記検出手段により前記デバイスの前記特定の状態の継続が一定時間を超えたことが検出された場合に、前記受信手段が受信した通知に基づき、前記デバイスが前記特定の状態であることを表示する際に、それまでに表示していた情報と異なる情報を前記表示装置に表示することを特徴とする請求項１に記載の通信システム。
3. 前記デバイスは、前記状態識別情報を変更する周期を設定する設定手段を有し、
   前記設定手段は、前記データ処理装置からの前記デバイスに対する要求に、前記表示時間に関する情報が含まれていた際に、前記状態識別情報を変更する周期を当該表示時間よりも短くなるように設定することを特徴とする請求項１又は２に記載の通信システム。
4. デバイスと、当該デバイスに対して処理を要求するデータ処理装置とが通信可能に相互に接続された通信システムにおける通信処理方法であって、
   前記デバイスは、
   当該デバイスにおいて特定の状態が継続している時間に応じて、前記特定の状態が継続していることを示す状態識別情報を変更する変更工程と、
   前記変更工程で状態識別情報が変更されたことに応じて、前記デバイスが前記状態識別情報に対応する特定の状態であること示す通知を前記データ処理装置に送信する送信工程とを有し、
   前記データ処理装置は、
   前記デバイスから前記デバイスが前記特定の状態であることを示す通知を受信する受信工程と、
   前記通知が受信される度に、前記デバイスが前記特定の状態であることを、予め定められた表示時間だけ表示装置に表示するための表示工程とを有し、
   前記変更工程では、前記状態識別情報を変更する周期を、前記表示時間よりも短くし、
   前記送信工程では、前記デバイスの状態に変化があったことに応じて、デバイスの状態を示す通知を前記データ処理装置に対して送信するプロトコルを用いており、
   前記変更工程により状態識別情報を変更することで、前記デバイスが継続して前記特定の状態であったとしても、前記プロトコルを用いて前記デバイスが前記特定の状態であることを示す通知を再度、前記データ処理装置に送信することを特徴とする通信処理方法。
5. デバイスから通知された当該デバイスの状態を予め定められた表示時間だけ表示装置に表示するデータ処理装置と通信可能に接続されたデバイスであって、
   前記デバイスにおいて特定の状態が継続している時間に応じて、前記特定の状態が継続していることを示す状態識別情報を変更する変更手段と、
   前記変更手段により状態識別情報が変更されたことに応じて、前記デバイスが前記状態識別情報に対応する特定の状態であること示す通知を前記データ処理装置に送信する送信手段とを有し、
   前記送信手段は、前記デバイスの状態に変化があったことに応じて、デバイスの状態を示す通知を前記データ処理装置に対して送信するプロトコルを用いており、
   前記変更手段が状態識別情報を変更することで、前記デバイスが継続して前記特定の状態であったとしても、前記プロトコルを用いて前記デバイスが前記特定の状態であることを示す通知を再度、前記データ処理装置に送信することを特徴とするデバイス。
6. デバイスから通知された当該デバイスの状態を予め定められた表示時間だけ表示装置に表示するデータ処理装置と通信可能に接続されたデバイスにおける通信処理方法であって、
   前記デバイスにおいて特定の状態が継続している時間に応じて、前記特定の状態が継続していることを示す状態識別情報を変更する変更工程と、
   前記変更工程で状態識別情報が変更されたことに応じて、前記デバイスが前記状態識別情報に対応する特定の状態であること示す通知を前記データ処理装置に送信する送信工程とを有し、
   前記送信工程では、前記デバイスの状態に変化があったことに応じて、デバイスの状態を示す通知を前記データ処理装置に対して送信するプロトコルを用いており、
   前記変更工程により状態識別情報を変更することで、前記デバイスが継続して前記特定の状態であったとしても、前記プロトコルを用いて前記デバイスが前記特定の状態であることを示す通知を再度、前記データ処理装置に送信することを特徴とする通信処理方法。
7. 請求項５に記載のデバイスの各手段としてコンピュータを機能させることを特徴とするコンピュータプログラム。

Images