JP2008059483A - 通信システム及びその制御方法及び通信装置 - Google Patents

Abstract

【課題】 ハードウエア資源が限られたサービス提供デバイスでは、不必要なイベント処理や通知を極力排除する工夫が必要となる。
【解決手段】 クライアントデバイスからサービス提供装置に対してイベントの通知要求を発行する（Ｓ１０４）とともに、その通知要求を発行したイベントを処理するイベント処理手段が有効か否かをサービス提供装置に通知する（Ｓ１１１，Ｓ１１５）。サービス提供装置は、イベントの発生を検知すると、そのイベントの通知要求が登録されているクライアントデバイスを検索し、その検索したクライアントデバイスの内、そのイベント処理手段が有効な状態にあるクライアントデバイスに、そのイベントの発生を通知する。
【選択図】 図２

Description

本発明は、ネットワークに対応した通信装置、及びこれらの装置を含む通信システム及びその制御方法に関するものである。

従来より、ネットワーク上のクライアント装置からのサービス要求に応答して、各種サービスを提供するサービス提供装置やサービス提供システムが知られている。例えば、インターネットによる通信の飛躍的な普及に伴い、ネットワーク対応型機器として、従来のパーソナルコンピュータ以外の種類の多様な機器が開発されている。例えば、ＰＤＡ（Personal Digital Assistance）、携帯電話等のユーザインタラクティブなデバイスに加えて、各種画像処理装置や家電製品等に至るまで、ネットワーク対応化が急速に進められている。

それに伴い、これらネットワーク対応型デバイスを利用する上での利便性、簡易性を高めるために、各種サービスを提供するネットワークデバイスを探索するソフトウエアが提供されている。またネットワーク対応型デバイスを制御するためのアプリケーションソフトウエア、ユーティリティソフトウエア、オペレーティングシステム等の自動セットアップ手段を提供する、種々なプロトコル、アーキテクチャが提案されている（特許文献１，２)。

また、複数の企業や標準化団体が、ローカルな入出力接続デバイス対して適用されてきたプラグアンドプレイをネットワークデバイスに対しても拡張対応すべく仕様策定作業を進めている。これには例えば、マイクロソフト社が主体となって策定を進めるＵＰｎＰ（登録商標:非特許文献１）がある。またＷＳＤ：Web Services for Devices（WS-Discovery/WS-MetadataExchange/WS-Eventing 非特許文献２，３，４）が推進するＢＭＬｉｎｋｓ（非特許文献５）等がある。
特開２００４−０３８９５６号公報 特開２００４−３６２５９４号公報 UPnP Device Architecture v1.0URL: http://www.upnp.org/download/UPnPDA10_20000613.htm Web Service Dynamic Discovery: WS-Discovery URL: http://specs.xmlsoap.org/ws/2005/04/discovery/ws-discovery.pdf WS-MetadataExchangeURL: http://msdn.microsoft.com/library/en-us/dnglobspec/html/ws-metadataexchange.pdf WS-Eventinghttp://msdn.microsoft.com/webservices/webservices/understanding/specs/default.aspx?pull=/library/en-us/dnglobspec/html/ws-eventing.asp 「ＢＭＬｉｎｋＳ」、ビジネス機械・情報システム産業協会、インターネット＜ＵＲＬ：http://www.jbmia.or.jp/bmlinks/index.htm＞

以上、例示した各ネットワークサービスシステムでは、ＧＥＮＡ：General Event Notification, WS-Eventing等に代表されるイベント通知のためのプロトコルを採用している。これによりクライアントデバイスは、サービスを提供するデバイスのステータスの変化、即ち、実行を依頼したジョブの処理状況、エラーステータス、構成情報の更新等の状態変化（イベント発生）をリアルタイムで掌握することが可能となった。

しかしながら上述した従来技術では以下のような問題があった。イベント通知のプロトコルでは、クライアントデバイスは、サービス提供デバイスに対しイベントの通知依頼を予め実行しなければならない。そしてサービス提供デバイスは、全てのクライアントデバイスから受けた通知依頼情報を保持して管理し、イベントの発生時には、その通知依頼のあった全てのクライアントデバイスの全てに対して通知しなければならない。このようなイベントの内、ジョブの実行に伴うステータスの変化に関連するイベントとしては、ジョブ開始、ジョブ進捗、ジョブ完了、エラー等のイベント事象が考えられる。これらイベントの発生を、通知依頼があった全てのクライアントに対して送信するためには、エラーリカバリ等を含むネットワークコネクションの確保等が必要となり、サービス提供デバイスにとって極めて負荷の大きいものであった。またそれに伴い、重要性、緊急性の高いイベントの通知に失敗してしまい、ネットワーク管理ツールに対するイベント通知が著しく遅延する等の問題が生じていた。

一方、通知依頼先であるクライアントデバイスに対してイベントを通知しても、クライアントデバイスが、そのイベントを処理する機能、即ち、イベント内容を解析し、利用者に対しその情報を通知する機能が無い場合も考えられる。またクライアントデバイスにおいて、そのイベント処理する機能、アプリケーション、ユーティリティ等が稼動していない（有効な状態でない）場合も考えられる。このような場合には、その通知されたイベント情報、及び通知のために費やされたプロセスは意味を持たなくなる。

ハードウエア資源が限られたサービス提供デバイス、特にホームネットワーク環境下で利用されるデバイス、或は大量のクライアントデバイスが存在するオフィス等の環境においては、不必要なイベント処理や通知を極力排除する工夫が必要となる。

本発明の目的は上記従来技術の問題点を解決することにある。

本発明の特徴は、イベントの通知要求が登録されているクライアント装置のうち、イベント処理が可能な状態にあるクライアント装置に対してイベント通知することにより、不必要なイベント発生通知を排除することにある。

上記目的を達成するために本発明の一態様に係る通信システムは以下のような構成を備える。即ち、
クライアント装置と、クライアント装置に対して通信媒体を介してサービスを提供するサービス提供装置とを有する通信システムであって、
前記クライアント装置は、
前記サービス提供装置に対してイベントの通知要求を発行する通知要求手段と、
前記通知要求手段により通知要求を発行したイベントを処理するイベント処理手段が有効か否かを前記サービス提供装置に通知する通知手段とを有し、
前記サービス提供装置は、
イベントの発生を検知すると、当該イベントの通知要求が登録されているクライアント装置を検索する検索手段と、
前記検索手段により検索したクライアント装置の内、当該クライアント装置のイベント処理手段が有効な状態にあるクライアント装置に当該イベントの発生を通知するイベント通知手段と、を有することを特徴とする。

上記目的を達成するために本発明の一態様に係る通信装置は以下のような構成を備える。即ち、
通信媒体を介してクライアント装置と接続され前記クライアント装置にサービスを提供する通信装置であって、
イベントの通知要求を受信したクライアント装置を登録する登録手段と、
イベントの発生を検知すると、前記登録手段に登録されている当該イベントの通知要求を発行しているクライアント装置を検索する検索手段と、
前記検索手段により検索したクライアント装置の内、当該クライアント装置のイベント処理手段が有効な状態にあるクライアント装置に当該イベントの発生を通知するイベント通知手段と、を有することを特徴とする。

上記目的を達成するために本発明の一態様に係る通信システムの制御方法は以下のような工程を備える。即ち、
クライアント装置と、クライアント装置に対して通信媒体を介してサービスを提供するサービス提供装置とを有する通信システムの制御方法であって、
前記クライアント装置から前記サービス提供装置に対してイベントの通知要求を発行する通知要求工程と、
前記通知要求工程で通知要求を発行したイベントを処理するイベント処理手段が有効か否かを前記サービス提供装置に通知する通知工程と、
前記サービス提供装置においてイベントの発生を検知すると、当該イベントの通知要求が登録されているクライアント装置を検索する検索工程と、
前記検索工程で検索したクライアント装置の内、当該クライアント装置のイベント処理手段が有効な状態にあるクライアント装置に当該イベントの発生を通知するイベント通知工程と、を有することを特徴とする。

本発明によれば、イベントの通知要求が登録されているクライアント装置のうち、イベント処理が可能な状態にあるクライアント装置に対してイベント通知することにより、不必要なイベント発生の通知を排除できる。これによりイベント通信プロセスの負荷を軽減でき、また、イベント通知が本来備えるべくイベント通知のリアルタイム性を向上させることが可能となった。

以下、添付図面を参照して本発明の好適な実施の形態を詳しく説明する。尚、以下の実施の形態は特許請求の範囲に係る本発明を限定するものでなく、また本実施の形態で説明されている特徴の組み合わせの全てが本発明の解決手段に必須のものとは限らない。また本実施の形態に記載されているプロトコル、ヴァージョン、アドレス、その他の数値等は、特に特定的な記載がない限りは、この発明の範囲をそれらのみに限定する趣旨のものではない。

図１は、本発明の一実施の形態に係るネットワークプラグアンドプレイシステムの構成を示すブロック図である。

図中、１００はクライアントデバイスで、Ethernetに対応する通信機能を有している。このクライアントデバイス１００は、TCP/UDP/IPプロトコルスタック１を備え、そのプロトコルスタック１上にＨＴＴＰ２を備えて、ＨＴＴＰリクエストの解析及びレスポンス処理を行っている。これらTCP/UDP/IPプロトコルスタック１及びＨＴＴＰ２の上位層にはSimple Object Access Protocol(SOAP)プロセッサ３が備えられている。更に、プラグアンドプレイコントローラ４、イベントマネージャ５、ユーティリティ６、アプリケーション７がそれぞれ、ＸＭＬで記述されたデータの双方向通信を実現している。

プラグアンドプレイモジュール４は、ＳＯＡＰプロセッサ３を介して、マイクロソフト社らが、その仕様の策定を推進するWS-Discovery仕様に基づき、ネットワークデバイスから通知されるHelloメッセージに対する応答処理を実行する。またネットワークデバイスの検索のためのProbeメッセージの発行処理を実行する。また、WS-MetadataExchange仕様に基づいてGetMetadataメッセージを発行することで、ネットワークデバイスの属性情報を取得する処理を実行する。

ネットワークデバイス２００がイベントの通知機能を備える場合、このネットワークデバイス２００の属性情報には、イベント通知依頼の登録先情報が記録されている。イベントマネージャ５は、ＳＯＡＰプロセッサ３を介して、このイベント通知依頼の登録先に対し、マイクロソフト社らが仕様策定を推進するWS-Eventing仕様に基づいてイベント通知依頼（Subscribeメッセージ）を発行する。又或は、イベント通知の解除依頼（UnSubscribeメッセージ）を発行する。また、イベントマネージャ５は、ユーティリティ６、アプリケーション７からのイベント通知依頼の有無を調べる。そして稼動状態にある、いずれかのユーティリティ６、アプリケーション７がイベント通知依頼を要する場合は、ＳＯＡＰプロセッサ３を介して、ネットワークデバイス２００に対してステータスメッセージを発行する。また、イベント通知依頼を要するユーティリティ６、アプリケーション７のいずれもが稼動状態でなくなった場合には、ＳＯＡＰプロセッサ３を介して、ネットワークデバイス２００に対してステータスメッセージを発行する機能を有する。

ネットワークデバイス２００から通知されたイベント情報は、ＳＯＡＰプロセッサ３を介してイベントマネージャ５に通知される。これによりイベントマネージャ５は、予め通知依頼のあったユーティリティ６、アプリケーション７に対してイベントを通知する。ここで、ユーティリティ６、アプリケーション７は、プリンタドライバダイアログ、プリンタキュービュー、ネットワーク管理アプリケーション等のネットワークデバイス２００から通知されるイベントを処理する機能を有するソフトウエアを含む。

次に、ネットワーク対応デバイス２００について説明する。

本実施の形態ではネットワーク対応型デバイス２００は、Ethernetに対応する通信機能を有している。このデバイス２００は、TCP/UDP/IPプロトコルスタック８と、そのプロトコルスタック８上にＨＴＴＰ９を備え、ＨＴＴＰリクエストの解析、及びレスポンス処理を行う。TCP/UDP/IPプロトコルスタック８及びＨＴＴＰ９の上位層には、ＳＯＡＰプロセッサ１０が設けられている。ＷＳＤモジュール１１、イベントマネージャ１２及びプリンタコントローラ１３がそれぞれ、このＳＯＡＰプロセッサ１０を介してＸＭＬで記述されたデータの双方向通信を実現する。

ＷＳＤモジュール１５は、マイクロソフト社らが仕様策定を推進するWS-Discovery仕様に基づき、ネットワーク３００に接続した際に、ＳＯＡＰプロセッサ１０を介してHelloメッセージを送信する。またクライアントデバイス１００から発行されるProbeメッセージに対する応答処理を実行する。また、WS-MetadataExchange仕様に基づき、クライアントデバイス１００から発行されたGetMetadataメッセージに応じて、ネットワーク対応デバイス２００（本実施の形態ではネットワーク対応プリンタ）が有する属性情報を返信する。

イベントマネージャ１２は、クライアントデバイス１００から通知されるイベントの通知依頼（Active）、イベントの通知解除依頼（InActive）を、クライアントデバイス１００を含む、複数の各クライアントデバイス別に管理する機能を備える。またイベントマネージャ１２は、プリンタコントローラ１３から通知されるプリンタのステータス情報を管理し、対応するイベントデータを生成する。そしてＳＯＡＰプロセッサ１０を介して、イベントメッセージを送信する機能を備える。

以下に、本実施の形態に係るネットワークプラグアンドプレイシステムにおける制御の流れをフローチャートに従って説明する。

［実施の形態１］
図２は、本実施の形態１に係るクライアントデバイス１００における制御処理を説明するフローチャートである。また図３は、本実施の形態１に係るネットワーク対応デバイス２００における制御処理を説明するフローチャートである。以下、これら２つのフローチャートを参照して説明する。

まずステップＳ１０１で、クライアントデバイス１００のプラグアンドプレイコントローラ４は、ネットワーク３００上で利用可能なサービス提供デバイス、即ちネットワーク対応デバイス２００の存在を探索する。ここではWS-Discovery仕様で規定されるネットワークデバイス探索パケット（Probeパケット）をＳＯＡＰプロセッサ３を介して発行する。そしてステップＳ１０２で、その応答を受信したかどうかをみる。応答を受信するとステップＳ１０３に進み、その応答したデバイスのデバイスプロファイルを取得する。

一方、ネットワーク対応デバイス２００は、図３のステップＳ２００でHelloメッセージを送信した後ステップＳ２０１で、前述のステップＳ１０１で送信されたProbeパケットを受信する。これを受信するとステップＳ２０２に進み、ネットワーク対応デバイス２００のＷＳＤモジュール１１は、クライアント１００に対してプロファイル情報を取得するためのアドレス情報を送信して応答する。ここでは、WS-Discovery仕様に規定される応答パケットとして、ProbeMatchレスポンスに記述し、ＳＯＡＰプロセッサ１０を介して返信する。

これによりクライアントデバイス１００では、ステップＳ１０４で、このProbeMatchレスポンスを受信したプラグアンドプレイコントローラ４が、その応答を発行したネットワーク対応デバイス２００のプロファイル情報を取得する。ここでは、WS-MetadataExchange仕様で規定されるGetMetadataリクエストを、先に受信したProbeMatchレスポンスに記述されたアドレスに対してＳＯＡＰプロセッサ３を介して発行する。尚、ネットワーク３００上には複数のネットワーク対応デバイスが存在する可能性がある。このためクライアントデバイス１００は、ProbeMatchレスポンスを返信したネットワーク対応デバイスの内、利用したいデバイスを選択する。そしてその選択したネットワーク対応デバイスの全てからプロファイル情報を取得する。

これにより図３のステップＳ２０３で、デバイス２００はそのGetMetadataリクエストを受信するとステップＳ２０４に進み、ＷＳＤモジュール１１は、クライアントデバイス１００に対してプロファイル情報をＳＯＡＰプロセッサ１０により送信する。

こうしてクライアントデバイス１００は、ネットワーク対応デバイス２００からのプロファイル情報を取得する。そしてプラグアンドプレイコントローラ４は、そのプロファイル情報に記述されるイベント通知リクエスト登録アドレスを、イベントマネージャ５に通知する。これによりイベントマネージャ５は、そのアドレスに対して、WS-Eventing仕様で規定されるイベント登録リクエスト（Subscribeリクエスト）をＳＯＡＰプロセッサ３を介して発行する（Ｓ１０４）。

これによりネットワーク対応デバイス２００は、ステップＳ２０５で、このSubscribeリクエストを受信する。これによりステップＳ２０６に進み、そのイベントマネージャ１２は、そのクライアントデバイスを一義的に識別するためのSubscribeIDを生成する。そして、そのSubscribeID及びSubscribeリクエストに記述されたクライアントデバイス１００のイベント通知先のアドレス情報を管理テーブルとして記憶する。

図４は、この管理テーブルの書式を記述したXMLデータを示す図である。

ここで＜SubscribeID＞タグには、イベントマネージャ１２が、クライアントデバイス１００に対して割り当てたSubscribeIDの値が属性値の形式で記述される。また＜EventPort＞タグには、クライアントデバイス１００のイベント通知先アドレス情報がURL形式で記述される。また＜Status＞は、後述する、クライアントデバイス１００におけるイベント処理ソフトウエアの稼動状況を記憶するために使用され、ステータスに応じてActive、InActiveのいずれかが記述される。このような書式で、登録された各クライアントデバイスのそれぞれに対応する情報がテーブルとして記憶される。

次にステップＳ２０７に進み、イベントマネージャ１２は、その生成したSubscribeIDを、WS-Event仕様で規定されるSubscribeレスポンスパケットに記述する。そして、そのSubscribeレスポンスをＳＯＡＰプロセッサ１０を介して送信する。

これによりクライアントデバイス１００はステップＳ１０５で、このSubscribeレスポンスを受信してステップＳ１０６に進み、イベントマネージャ５は、そのパケットに記述されるSubscribeIDを記憶してステップＳ１０７に進む。

次にクライアントデバイス１００のイベントマネージャ５は、その上位レイヤで機能するユーティリティ６、アプリケーション７が起動しているかを判断する。ここではユーティリティ６、アプリケーション７の内、ドライバダイアログ、プリントキュービュー、ネットワークデバイス管理ソフトウエア等、ネットワークデバイス２００からのイベントを処理するソフトウエアが起動したかをみる。ここで、これらのソフトウエアが起動している場合には、これらソフトウエアは、イベントマネージャ５に対してイベント通知を登録する。

ステップＳ１０７で、イベントマネージャ５は、ユーティリティ６、アプリケーション７のいずれかからイベント通知の登録を受けるとステップＳ１０８に進む。ここではSubscribeIDの取得の有無を確認する。ここで既にネットワーク対応デバイス２００よりSubscribeIDを取得済みであればステップＳ１０９に進む。ステップＳ１０９では、イベント通知を要するユーティリティ６或はアプリケーション７の稼動総数が「１」或はそれ以上かどうかを判断し、そうであればステップＳ１１０に進む。ステップＳ１１０では、ステータス通知メッセージを発行済かどうかを調べる。ここで発行済でなければステップＳ１１１に進み、ネットワーク対応デバイス２００に対してステータス通知メッセージ（Active）をＳＯＡＰプロセッサ３を介して発行してステップＳ１１３に進む。

またステップＳ１０９で、イベント通知を要するユーティリティ６或はアプリケーション７の稼動総数が「０」、或はステップＳ１１０でステータス通知メッセージが発行済であれば、イベントマネージャ５はステータス通知メッセージを発行せずにステップＳ１１３に進む。またステップＳ１０８で、SubscribeIDが取得されていない場合はステップＳ１１２に進み、イベントマネージャ５は、ユーティリティ６或はアプリケーション７に対してエラーを通知してステップＳ１１３に進む。

図５は、このステータス通知メッセージの書式を説明する図である。このメッセージは、ＳＯＡＰプロセッサ３により、SOAPエンベロープの形式に変換された後、ネットワークデバイス２００に対して送信される。

ここで＜SubscribeID＞は、ステップＳ１０６でネットワーク対応デバイス２００より取得した識別子（SubscriptionID）を記述する。又＜Status＞には、イベントの通知を要するユーティリティ６或はアプリケーション７の稼動状況が記述される。稼動中の場合は「Active」と記述する。

図３のステップＳ２０８で、このステータス通知メッセージを受信するとステップＳ２０９に進み、イベントマネージャ１２は、前述の管理テーブルより、ステータス通知メッセージに記述されたSubscibeIDを参照する。そして管理テーブルより、該当するクライアントデバイス情報を検索し、＜Status＞のフィールドを、受信した内容に応じて管理テーブルを更新してステップＳ２１０に進む。

また図２のステップＳ１０７で、ユーティリティ６、アプリケーション７の内、ドライバダイアログ、プリントキュービュー等のネットワークデバイスからのイベントを処理するソフトウエアが起動していない場合はステップＳ１１３に進む。これらソフトウエアはイベントマネージャ５に対してイベント通知登録の解除通知を行う。こうしてステップＳ１１３で、イベントマネージャ５が、ユーティリティ６、アプリケーション７のいずれかからイベント通知の登録解除を受けるとステップＳ１１４に進む。ステップＳ１１４では、イベント通知を要するユーティリティ６或はアプリケーション７の稼動総数が「０」かどうかを判断する。ここで「０」であればステップＳ１１５に進み、ネットワーク対応デバイス２００に対して、ステータス通知メッセージをＳＯＡＰプロセッサ３を介して発行する。この場合、イベントマネージャ５は、先に説明した図５に示す＜Status＞タグに「InActive」と記述する。

又ステップＳ１１４で、イベントの通知を要するユーティリティ６或はアプリケーション７の稼動総数が「１」或はそれ以上の場合は、イベントマネージャ５はステータス通知メッセージを発行せずにステップＳ１１６に進む。

ステップＳ２０８で、このステータス通知メッセージを受信したネットワーク対応デバイス２００のイベントマネージャ１２は、前述の管理テーブルより、ステータス通知メッセージに記述されたSubscibeIDを参照する。そしてステップＳ２０９に進み、管理テーブルより、該当するクライアントデバイス情報を検索し、＜Status＞のフィールドを、その受信した内容に応じて変更して管理テーブルを更新する。

こうしてクライアントデバイス１００のイベントマネージャ５は、前述のステップＳ１０７〜Ｓ１１６の処理を繰り返し、イベント処理を実行するユーティリティ６、アプリケーション７の稼動状況を監視する。

尚、クライアントデバイス１００が休止状態に移行する場合、或はシャットダウンする場合はステップＳ１１７に進む。ステップＳ１１７では、ネットワークデバイス２００に対して、WS-Eventing仕様で規定されるイベント登録解除リクエスト（UnSubscribeリクエスト）をＳＯＡＰプロセッサ３を介して発行する。

これによりステップＳ２１０で、このUnSubscribeリクエストを受信したネットワーク対応デバイス２００のイベントマネージャ１２はステップＳ２１１に移行する。ここで前述の管理テーブルより、そのUnSubscribeリクエストに記述されたSubscibeIDを参照する。そして、その管理テーブルより該当するクライアントデバイスを検索し、該当するクライアントデバイスの情報を管理テーブルより削除する。

またステップＳ１０２で、クライアントデバイス１００がProbeMatchレスポンスを受信できなかった場合はステップＳ１１８に進む。ここでプラグアンドプレイコントローラ４は、それ以降にネットワーク３００上に参加したネットワーク対応デバイス２００から送信されるHelloメッセージの受信の有無を監視する。そして、そのメッセージを受信するとステップＳ１０３に進んで、それ以降の処理を実行する。

尚、このHelloメッセージは、ネットワーク対応デバイス２００が起動し、ネットワーク３００上でサービスの提供が可能になったタイミングで発行されるパケットである。ここではWS-Discovery仕様において規定されるパケットで、図３のステップＳ２００で発行される。

図６は、本実施の形態に係るネットワーク対応デバイス２００においてイベントが発生した場合の制御処理の流れを示すフローチャートである。

この処理は、ネットワーク対応デバイス２００、即ち、ネットワーク対応プリンタにおける処理を示す。この処理は、例えばジョブに対する遷移状態変化に関わるイベント、エラー情報関連イベント、オプション装置等の変更に関連するイベント、諸設定変更に関連するイベント等が発生することにより起動される。まずステップＳ３０１で何らかのイベントが発生するとプリンタコントローラ１３は、イベントマネージャ１２に対してイベントの発生を通知する。これによりステップＳ３０２に進み、この通知を受けたイベントマネージャ１２は管理テーブルを検索する。そしてステップＳ３０３で、Subscribe情報が記述され、かつ＜TAG＞のステータスが「Active」であるかを判断する。そうであればステップＳ３０４に進み、その管理テーブルに記述したアドレスに対してイベントの発生を通知する。

ここでイベントマネージャ１２は、プリンタコントローラ１３より通知されたイベント事象を、WS-Eventing仕様に規定されるNotificationsの書式に従ってXMLで記述する。そしてＳＯＡＰプロセッサ１０を介してネットワーククライアント１００に送信する。

尚、ステップＳ３０３で、Subscribe情報が記述管理テーブルに記述されていても、＜TAG＞情報が「InActive」となっている場合はステップＳ３０４は実行されない。よって、クライアントデバイス１００、即ち、イベント処理を実施するユーティリティ６、アプリケーション７が稼動状態でないクライアントデバイス１００に対してはイベントは通知されない。

そしてステップＳ３０５で、イベントマネージャ１２は、管理テーブルに記録された全てのDescriptionIDに対するイベントの通知処理が完了したかを調べ、完了していないときはステップＳ３０２に戻り、前述の処理を実行する。

一方、このネットワークデバイス２００よりイベント通知を受けたクライアントデバイス１００のイベントマネージャ５は、イベント通知登録のあったユーティリティ６或はアプリケーション７に対してイベント情報を通知する。

以上説明した図２、図３及び図６のフローチャートで記述された一連の制御処理が実行される。これにより、本実施の形態に係る特徴であるクライアントデバイス１００において、イベント処理を実施するユーティリティ６或はアプリケーション７が稼動状態にある場合、ネットワーク対応デバイス２００からイベントを通知する制御を実現できる。

［実施の形態２］
上述の実施の形態１では、クライアントデバイス１００のイベントマネージャ５は、その上位レイヤで機能するユーティリティ６、アプリケーション７の起動状況に応じて、ネットワークデバイス２００に対してステータス通知メッセージを発行していた。

クライアントデバイス１００で稼動するユーティリティ６、アプリケーション７の数が少ないデバイスの場合は、ネットワーク対応デバイス２００に対して通知されるSubscribe情報のみで、イベント通知を制御しても良い。

以下、本発明の実施の形態２について図７及び図８を参照して説明する。尚、この実施の形態２に係る装置及びシステム構成は、前述の実施の形態１と同様であるため、その説明を省略する。

図７は、本実施の形態２に係るクライアントデバイス１００における制御処理を説明するフローチャートである。また図８は、本実施の形態２に係るクネットワーク対応デバイス２００における制御処理を説明するフローチャートである。尚ここで、前述の図２及び図３と共通する処理には同じ記号を付して、その説明を省略する。

ステップＳ４０１で、デバイス情報を取得した後、クライアントデバイス１００のイベントマネージャ５は、その上位レイヤで機能するユーティリティ６、アプリケーション７の起動状況を監視する。

ユーティリティ６、アプリケーション７のうち、ドライバダイアログ、プリントキュービュー、ネットワークデバイス管理ソフトウエア等、ネットワークデバイスからのイベントを処理するソフトウエアが起動した場合、これらソフトウエアは、イベントマネージャ５に対してイベント通知登録を行う。

こうしてステップＳ１０７で、イベントマネージャ５は、ユーティリティ６、アプリケーション７のいずれかからイベント通知登録を受けるとステップＳ１０９に進む。ステップＳ１０９では、イベント通知を要するユーティリティ６或はアプリケーション７の稼動総数が「１」或はそれ以上かどうかを判断する。そうであればステップＳ４０２に進み、イベント登録リクエスト（Subscribeリクエスト）が発行済かどうかを判定する。発行済でないときはステップＳ４０３に進み、ネットワーク対応デバイス２００に対して、WS-Eventing仕様に規定されるイベント登録リクエスト（Subscribeリクエスト）をＳＯＡＰプロセッサ３を介して発行する。尚、発行済であればステップＳ１１３に進む。

このSubscribeリクエストを受信したネットワーク対応デバイス２００イベントマネージャ１２は、図８のステップＳ５０１で、クライアントデバイスを一義的に識別するためのSubscribeIDを生成する。そして、そのSubscribeID及びSubscribeリクエストに記述されたクライアントデバイス１００のイベント通知先アドレス情報を管理テーブルとして記録する。次にイベントマネージャ１２は、ステップＳ５０２で、その生成したSubscribeIDを、WS-Event仕様に規定されるSubscribeレスポンスパケットに記述する。そして、そのSubscribeレスポンスをＳＯＡＰプロセッサ１０を介して送信する。

このSubscribeレスポンスがステップＳ４０４で受信されたかを判断する。このSubscribeレスポンスを受信しないときはステップＳ４０５に進み、エラーを通知してステップＳ１１３に進む。一方、ステップＳ４０４でSubscribeレスポンスを受信するとステップＳ４０６に進み、イベントマネージャ５は、そのパケットに記述されるSubscribeIDを記憶してステップＳ１１３に進む。

ステップＳ１１３では、ユーティリティ、アプリケーションの内、ドライバダイアログ、プリントキュービュー、ネットワークデバイス管理ソフトウエア等、ネットワークデバイスからのイベントを処理するソフトウエアの状態をみる。これらソフトウエアが終了した場合、これらソフトウエアは、イベントマネージャ５に対してイベント通知登録の解除通知を行う。

イベントマネージャ５は、ユーティリティ６、アプリケーション７のいずれかからイベント通知登録解除を受けるとステップＳ１１３からステップＳ１１４に進む。このステップＳ１１４で、イベント通知を要するユーティリティ６或はアプリケーション７の稼動総数が「０」かどうかを判断する。「０」であればステップＳ４０７に進み、ネットワーク対応デバイス２００に対して、WS-Eventing仕様で規定されるイベント登録解除リクエスト（UnSubscribeリクエスト）をＳＯＡＰプロセッサ３を介して発行する。

これにより、このUnSubscribeリクエストを受信したネットワーク対応デバイス２００のイベントマネージャ１２は、ステップＳ５０３で、前述の管理テーブルより、UnSubscribeリクエストに記述されたSubscibeIDを参照する。そして、その管理テーブルより該当するクライアントデバイス情報を検索し、該当するクライアントデバイスの情報を管理テーブルより削除する。

こうしてネットワーク対応デバイス２００でイベントが発生した場合、管理テーブルを検索し、Subscribe情報が記述されている場合、該管理テーブルに記述したアドレスに対してイベント通知を実行する。

以上の制御処理により、クライアントデバイス１００では、イベント処理を実施するユーティリティ６、アプリケーション７が稼動状態にある場合にのみ、ネットワーク対応デバイス２００に対して、イベント通知依頼リクエストを発行する。

上述した実施の形態１，２では、図２のステップＳ１１１、Ｓ１１５において、イベントマネージャ５が、ユーティリティ６、アプリケーション７の起動状況に応じて、ネットワークデバイス２００に対してステータス通知メッセージを発行している。

しかし、クライアントデバイス１００が複数のユーティリティ６、アプリケーション７を実行可能であり、また各ソフトウエアがウインドウ形式でそのユーザインターフェイスを表示する機能を備える場合には以下のようにしても良い。即ち、イベントマネージャ５に対してイベント通知登録を行い、かつ起動状態にあっても、該当するソフトウエアのウインドウにフォーカスが当たっている（即ち、ウインドウがActiveな状態になっている）か否かをイベントマネージャ５が監視する。そして、イベント通知を要するユーティリティ６、アプリケーション７の内、そのウインドウにフォーカスが当たっているソフトウエアの総数が「１」或はそれ以上の場合に、ネットワークデバイス２００に対してステータス通知メッセージを発行する。これにより、クライアントデバイス１００においてイベント処理を実施するユーティリティ６、アプリケーション７が稼動状態で、かつそれらソフトウエアのユーザインターフェイスであるウインドウにフォーカスが当たっている場合にのみイベントを通知するようにできる。

また上述した実施形態１，２では、クライアントデバイス１００で、イベント処理を実施するユーティリティ６、アプリケーション７が稼動状態でない場合に、ネットワーク対応デバイス２００は、いずれのイベント事象であっても、クライアントデバイス１００に通知していない。しかし、イベント事象のうち、例えば重要なエラーステータス、デバイスの構成変更に関わるステータス変化等、予め定めたイベント事象に関しては、上記ユーティリティ６、アプリケーション７が稼動状態であるか否かに関わらず、イベント通知するようにしても良い。

また、上述した実施の形態１，２では、ネットワークデバイスの検索、及びネットワークデバイスがネットワークに参加したことの通知、及びイベントの登録、通知手段としてWS-Discovery、WS-Eventing仕様で定義されるプロトコルを採用している。しかし、本発明はこれに限定されるものでなく、例えばUPnP(tm) v1で規定されるSSDP(Simple Service Discovery Protocol)、及びGENA(General Event Notification Architecture)などを利用しても良い。

また、ネットワークデバイスの検索プロトコルとして、ネットワークデバイスの属性情報を取得するためのアドレス、及びネットワークデバイスを制御するための制御情報送信先が取得できるプロトコルであれば、いずれのプロトコルも適用できる。

またイベントの登録、通知手段として、ネットワークを介してイベント通知依頼、イベント送信先の通知が実施可能であり、また発生したイベント情報をイベント通知依頼先に対し送信することが可能なプロトコルであれば、いずれのプロトコルであっても良い。

また、上述した実施の形態１，２において、ネットワークデバイスがプリンタの場合を示したが、通信媒体を介して利用、制御可能なデバイスであれば、複写機、スキャナ、ストレージデバイス等の事務機、テレビ、冷蔵庫、エアコン等の家電製品でも良い。

また、上述した実施の形態に係るクライアントデバイス１００及びネットワーク対応デバイス２００における各処理機能は、各処理機能を実現するためのプログラムをメモリから読み出してＣＰＵ（中央演算装置）が実行して、その機能を実現させている。しかし本発明はこれに限定されるものでなく、各処理機能の全部又は一部の機能を専用のハードウェアにより実現してもよい。また上述したメモリは、光磁気ディスク等の不揮発性メモリや、ＣＤ−ＲＯＭ等の読み出しのみが可能な記憶媒体、ＲＡＭ以外の揮発性のメモリ或はこれらの組合せによるコンピュータにより読み取り、書き込み可能な記憶媒体であっても良い。

また、クライアントデバイス１００及びネットワーク対応デバイス２００内の各機能を実現するためのプログラムを、コンピュータにより読み取り可能な記憶媒体に記憶し、そのプログラムをコンピュータシステムに読み込ませて実行して各処理を行っても良い。尚、ここでいう「コンピュータシステム」とは、ＯＳや周辺機器等のハードウェアを含むものとする。具体的には、記憶媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれる。その後、プログラムの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含む。

また「コンピュータ読み取り可能な記憶媒体」とは、フレキシブルディスク、光磁気ディスク、ＲＯＭ、ＣＤ−ＲＯＭ等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置のことをいう。更に、「コンピュータ読み取り可能な記憶媒体」とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムが送信された場合のサーバやクライアントとなるコンピュータシステム内部の揮発メモリ（ＲＡＭ）のように、一定時間プログラムを保持しているものも含む。

また、上記プログラムは、このプログラムを記憶装置等に格納したコンピュータシステムから、伝送媒体を介して、あるいは、伝送媒体中の伝送波により他のコンピュータシステムに伝送されてもよい。ここで、プログラムを伝送する「伝送媒体」は、インターネット等のネットワーク（通信網）や電話回線等の通信回線（通信線）のように情報を伝送する機能を有する媒体のことをいう。

また上記プログラムは、前述した機能の一部を実現するものであっても良い。更に、前述した機能をコンピュータシステムに既に記録されているプログラムとの組合せで実現できるもの、いわゆる差分ファイル（差分プログラム）であっても良い。

また上記プログラムを記憶したコンピュータ読み取り可能な記憶媒体等のプログラムプロダクトも本発明の実施形態として適用することができる。上記のプログラム、記憶媒体、伝送媒体及びプログラムプロダクトは、本発明の範疇に含まれる。

以上、この発明の実施形態について図面を参照して詳述してきたが、具体的な構成はこの実施形態に限られるものではなく、この発明の要旨を逸脱しない範囲の設計等も含まれる。

本発明の一実施の形態に係るネットワークプラグアンドプレイシステムの構成を示すブロック図である。 本実施の形態１に係るクライアントデバイスにおける制御処理を説明するフローチャートである。 本実施の形態に係るクネットワーク対応デバイスにおける制御処理を説明するフローチャートである。 本実施の形態に係る管理テーブルの書式を記述したXMLデータを示す図である。 本実施の形態に係るステータス通知メッセージの書式を説明する図である。 本実施の形態に係るネットワーク対応デバイスにおいてイベントが発生した場合の制御処理の流れを示すフローチャートである。 本実施の形態２に係るクライアントデバイスにおける制御処理を説明するフローチャートである。 本実施の形態２に係るクネットワーク対応デバイスにおける制御処理を説明するフローチャートである。

Claims (11)

1. クライアント装置と、クライアント装置に対して通信媒体を介してサービスを提供するサービス提供装置とを有する通信システムであって、
   前記クライアント装置は、
   前記サービス提供装置に対してイベントの通知要求を発行する通知要求手段と、
   前記通知要求手段により通知要求を発行したイベントを処理するイベント処理手段が有効か否かを前記サービス提供装置に通知する通知手段とを有し、
   前記サービス提供装置は、
   イベントの発生を検知すると、当該イベントの通知要求が登録されているクライアント装置を検索する検索手段と、
   前記検索手段により検索したクライアント装置の内、当該クライアント装置のイベント処理手段が有効な状態にあるクライアント装置に当該イベントの発生を通知するイベント通知手段と、
   を有することを特徴とする通信システム。
2. 前記サービス提供装置は、少なくともイベントの通知要求を発行したクライアント装置の識別情報、前記クライアント装置のアドレス、及び前記クライアント装置のイベント処理手段の状況を登録する登録手段を有することを特徴とする請求項１に記載の通信システム。
3. 前記通知手段は、前記サービス提供装置より通知されるイベントを処理するイベント処理手段が少なくとも１つ以上有効な状態にある場合に、前記イベント処理手段が有効である旨を通知することを特徴とする請求項１又は２に記載の通信システム。
4. 前記通知手段は、少なくとも１つの前記イベント処理手段が有効な状態に遷移した場合、前記イベント処理手段が有効である旨を通知することを特徴とする請求項１又は２に記載の通信システム。
5. 前記通知手段は、有効な前記イベント処理手段の数が０になると前記イベント処理手段が無効である旨を通知することを特徴とする請求項１に記載の通信システム。
6. 通信媒体を介してサービスを提供するサービス提供装置に接続され、前記サービス提供装置のサービスを享受する通信装置であって、
   前記サービス提供装置に対してイベントの通知要求を発行する通知要求手段と、
   前記通知要求手段により通知要求を発行したイベントを処理するイベント処理手段が有効か否かを前記サービス提供装置に通知する通知手段と、
   を有することを特徴とする通信装置。
7. 通信媒体を介してクライアント装置と接続され前記クライアント装置にサービスを提供する通信装置であって、
   イベントの通知要求を受信したクライアント装置を登録する登録手段と、
   イベントの発生を検知すると、前記登録手段に登録されている当該イベントの通知要求を発行しているクライアント装置を検索する検索手段と、
   前記検索手段により検索したクライアント装置の内、当該クライアント装置のイベント処理手段が有効な状態にあるクライアント装置に当該イベントの発生を通知するイベント通知手段と、
   を有することを特徴とする通信装置。
8. クライアント装置と、クライアント装置に対して通信媒体を介してサービスを提供するサービス提供装置とを有する通信システムの制御方法であって、
   前記クライアント装置から前記サービス提供装置に対してイベントの通知要求を発行する通知要求工程と、
   前記通知要求工程で通知要求を発行したイベントを処理するイベント処理手段が有効か否かを前記サービス提供装置に通知する通知工程と、
   前記サービス提供装置においてイベントの発生を検知すると、当該イベントの通知要求が登録されているクライアント装置を検索する検索工程と、
   前記検索工程で検索したクライアント装置の内、当該クライアント装置のイベント処理手段が有効な状態にあるクライアント装置に当該イベントの発生を通知するイベント通知工程と、
   を有することを特徴とする通信システムの制御方法。
9. 前記通知工程では、前記サービス提供装置より通知されるイベントを処理するイベント処理手段が少なくとも１つ以上有効な状態にある場合に、前記イベント処理手段が有効である旨を通知することを特徴とする請求項８に記載の通信システムの制御方法。
10. 前記通知工程では、少なくとも１つの前記イベント処理手段が有効な状態に遷移した場合、前記イベント処理手段が有効である旨を通知することを特徴とする請求項８に記載の通信システムの制御方法。
11. 前記通知工程では、有効な前記イベント処理手段の数が０になると前記イベント処理手段が無効である旨を通知することを特徴とする請求項８に記載の通信システムの制御方法。
    

Images