JP2007274588A - 電子機器及び当該機器における制御方法 - Google Patents

Abstract

【課題】 通知登録の有効期間の判断に、装機器の状況が考慮されていない。このため、クライアントが機器の状況に関係なく登録要求を発行して、機器が高負荷状態となり、イベント情報の通知が欠落してしまう。
【解決手段】 クライアントからのイベント通知の登録要求に応じて、登録の可否を判定し、登録可と判定したクライアントに対する通知回数の上限値を設定して登録する（Ｓ７０２）。イベント通知に対応するイベントの発生に応じて、登録されているクライアントに対して当該イベントの発生を通知し（Ｓ７０５〜Ｓ７１３）、その通知回数が上限値に達すると、登録されているクライアントの登録を無効にする（Ｓ７１４）。
【選択図】 図７

Description

本発明は、電子機器の状態情報を外部機器に通知する電子機器及び当該機器における制御方法に関するものである。

ある電子機器でのイベントの発生を特定の外部機器に通知することをその電子機器に登録するイベント通知の登録処理が知られている。そして、その電子機器で、このようなイベント通知の登録要求を外部機器から受取ると、その外部機器を通知先として登録する。そして電子機器でイベントが発生すると、そのイベントの発生を、その電子機器に通知先として登録されている外部機器へ通知する電子機器が存在する（特許文献１）。この電子機器では更に、所定時間が経過した後に、その外部機器の登録を登録テーブルから削除するようにも構成されているものもある。
特開平１１−２０３０９４号公報

このような電子機器と外部機器とで構成されるシステムにおいて、外部機器がその電子機器の状態情報を取得するために、その電子機器に対してイベント通知の登録要求を行う。この登録要求を受けた電子機器では、その登録要求をしてきた外部機器をイベントの通知先として登録する。そして電子機器の内部でイベントが発生すると、登録しているイベントの通知先を取得し、その通知先の全てに、そのイベントを示すイベント情報を送信する。このようなシステムにおいて、電子機器で発生するイベント数が急増した場合、或は、イベントの通知先として登録されている外部機器の数が短期間に急増した場合は、発生したイベントに対して通知処理が追いつかずイベント通知の欠落が発生する虞がある。この問題は、イベントの通知をＵＤＰによるブロードキャストではなくＴＣＰで送信する場合に特に顕著となる。このため通知先として登録されている外部機器に確実にイベント情報を通知すること、また電子機器が自身の処理限界に達する前にイベント処理の負荷を調節する仕組みが必要となる。またイベント通知の通知先として登録されている外部機器がノートＰＣ等の場合、イベント通知の登録を解除することなく、そのＰＣがネットワークから除去される場合がある。このような場合、イベントが発生する度にそのＰＣに対してイベントが通知され、その度にＰＣから応答がないためＴＣＰのタイムアウト待ちが発生してしまう。これらの処理は無駄な処理であり、電子機器への負担を増大させるものとなる。このため、何らかの条件によって、イベント通知の登録を解除する仕組みが必要となる。

イベント通知の登録を解除するための仕組みとして、所定時間経過後に、イベント通知の登録を自動的に解除するものがあった。ただし、その所定時間が固定な時間であったり、外部機器から一方的に指定された時間であったりした。このため、外部機器が電子機器の状況に関係なく登録要求を発行して、電子機器が高負荷状態となり、イベント情報の通知が欠落してしまう危険性がある。

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

本発明の特徴は、状態情報を通知する電子機器側で、特定の外部機器への状態情報の通知を解除するまでの期間を動的に決定することができる技術を提供することにある。

また本願発明の特徴は、特定の外部機器への状態情報の通知が有効な期間を動的に決定し、その期間内で状態情報を通知する技術を提供することにある。

上記目的を達成するために本発明の一態様に係る電子機器は以下のような構成を備える。即ち、
状態情報を通知する電子機器であって、
特定の外部機器に状態情報を通知することを前記電子機器に登録するよう求める登録要求を外部機器から受信する受信手段と、
前記特定の外部機器に対して状態情報を通知する通知手段と、
前記特定の外部機器への状態情報の通知が有効な期間を動的に決定する決定手段と、
前記決定手段により決定された期間が終了すると、前記特定の外部機器に状態情報を通知することの登録を無効にする無効化手段とを有することを特徴とする。

上記目的を達成するために本発明の一態様に係る電子機器における制御方法は以下のような工程を備える。即ち、
状態情報を通知する電子機器における制御方法であって、
特定の外部機器に状態情報を通知することを前記電子機器に登録するよう求める登録要求を外部機器から受信する受信工程と、
前記受信工程で受信したイベント通知の登録要求に応じて、登録の可否を判定する判定工程と、
前記特定の機器に対して状態情報を通知する通知工程と、
前記特定の外部機器への状態情報の通知が有効な期間を動的に決定する決定工程と、
前記決定工程で決定された期間が終了すると、前記特定の外部機器に状態情報を通知することの登録を無効にする無効化工程とを有することを特徴とする。

尚、この課題を解決するための手段は、本願発明の特徴の全てを列挙しているものではなく、特許請求の範囲に記載された他の請求項及びそれら特徴群の組み合わせも発明になり得る。

本発明によれば、状態情報を通知する電子機器側で、特定の外部機器への状態情報の通知を解除するまでの期間を動的に決定することができる。

また本発明によれば、特定の外部機器への状態情報の通知が有効な期間を動的に決定し、その期間内で状態情報を通知することにより、電子機器が高負荷状態となり状態情報の通知が欠落するといった事態の発生を軽減できる。

以下、添付図面を参照して本発明の好適な実施の形態を詳しく説明する。尚、以下の実施の形態は特許請求の範囲に係る本発明を限定するものでなく、また本実施の形態で説明されている特徴の組み合わせの全てが本発明の解決手段に必須のものとは限らない。

図１は、本発明の実施の形態に係るシステムを説明する構成図である。ここでは、イベントの通知の登録処理時のシステム構成を示している。

外部機器としてのクライアント（以下、クライアント）１０１乃至１０５と電子機器としての画像形成装置（複写機）１０６とは、ＬＡＮ１００に接続されている。１１０と１１１は、クライアントから画像形成装置１０６へのイベント通知の登録要求を示している。登録要求１１０は、画像形成装置１０６におけるプリンタ関連及びスキャナ関連のイベントの発生を通知するよう求める登録要求を示し、登録要求１１１は、スキャナ関連のイベントの発生を通知するよう求める登録要求を示している。よって、ここではクライアント１０１乃至１０３のそれぞれには、画像形成装置１０６におけるプリンタ関連及びスキャナ関連のイベントの発生が画像形成装置１０６から通知される。また、クライアント１０４，１０５には、スキャナ関連のみのイベントの発生が画像形成装置１０６から通知される。以下、イベントの発生を通知することを「イベント通知」とする。また、イベント通知をしてほしい旨を画像形成装置１０６に登録すること或いはイベントの発生を示すイベント情報の通知先を画像形成装置１０６に登録することを「イベント通知の登録」とする。さらに、イベント通知の登録を画像形成装置１０６に求めること或いはイベント通知の登録を画像形成装置１０６に求める要求メッセージを「イベント通知の登録要求」とする。イベントは主に、画像形成装置１０６の状態を示し、例えば、紙詰まりの発生や、ドア・オープンや、紙詰まりの解消などを示す。

図２は、本発明の実施の形態に係るイベント通知処理時のシステム構成を示す図で、図１と共通する部分は同じ記号で示している。

図２では、画像形成装置１０６のプリンタモジュールで紙詰まりが発生した場合を示している。この場合、紙詰まりのイベント情報２０１は、図１の登録要求１１０に応じて、クライアント１０１乃至１０３にのみ通知される。

図３は、本発明の実施の形態に係るクライアント（１０１）のハードウェア構成を示すブロック図である。このクライアントは、例えばパーソナルコンピュータ（ＰＣ）やワークステーション等の情報処理装置（コンピュータ機器）である。

ＣＰＵ３０１は、このクライアントのソフトウェアプログラムを実行し、この装置全体の制御を行う。ＲＯＭ３０２には、この装置のブートプログラムや固定パラメータ等が格納されている。ＲＡＭ３０３はＣＰＵ３０１がこの装置を制御する際に、一時的なデータの格納等に使用される。ＨＤＤ３０４はハードディスクドライブであり、各種ソフトウェア等の様々なデータの格納に使用される。ＮＶＲＡＭ３０５は不揮発性のメモリで、この装置の各種設定値を保存する。ネットワークＩ／Ｆ制御部３０６は、ＬＡＮ１００とのデータの送受信を制御する。バス３００はＣＰＵ３０１，ＲＯＭ３０２，ＲＡＭ３０３，ＨＤＤ３０４，ＮＶＲＡＭ３０５，ネットワークＩ／Ｆ制御部３０６が接続され、ＣＰＵ３０１からの制御信号やデータ信号が送受信されるシステムバスである。ＣＰＵ３０１により実行される各種アプリケーションプログラムやＯＳ等はＨＤＤ３０４にインストールされており、実行時にはＲＡＭ３０３にロードされて実行される。尚、他のクライアントの構成も基本的には、このクライアント１０１の構成と同じであるため、それらの説明を省略する。

図４は、本実施の形態に係る画像形成装置１０６のハードウェア構成を示すブロック図である。

スキャナ制御部４０２は、スキャナエンジン４０１を制御する。エンジン制御部４０５はプリンタエンジン４０４を制御する。４０３はＲＯＭ、４０６はＨＤＤ（ハードディスク）、４０７はＣＰＵである。不揮発性のメモリであるＮＶＲＡＭ４０９は、ユーザにより設定された各種値を保持している。Ｉ／Ｏ制御部４１１は、スピーカ４１５、タッチパネル４１６やボタン４１７、ランプ４１８等を含む操作部４１４を制御する。ネットワーク制御部４１２は、ＬＡＮ１００と接続されていて、ネットワーク通信の制御を行なう。ＲＴＣ（タイマ）４１３は省エネモード中も動作しており、電源制御部４１０に対して復帰時刻の通知を行なう。バス４１９には、前述した各部が接続されている。

この画像形成装置１０６を制御するプログラムは予めＨＤＤ４０６に格納されており、電源が投入されるとＣＰＵ４０７はＲＯＭ４０３からブートプログラムを読み出し、そのブートプログラムの制御に従って各デバイス制御プログラムのブートを実行する。即ち、ＣＰＵ４０７は、このブートプログラムに従ってＨＤＤ４０６からデバイス制御プログラムをＲＡＭ４０８にロードして展開する。そしてこのＲＡＭ４０８に展開されたデバイス制御プログラムを読み出すことによって、この画像形成装置１０６の制御を実行する。

図５は、本実施の形態に係るクライアント１０１のソフトウェア構成を説明するブロック図である。尚、他のクライアントに関しても同様のソフトウェア構成であるため、その説明を省略する。

ネットワークドライバ５０１は、ネットワークＩ／Ｆ制御部３０６（図３）を制御し、ネットワーク１００との間でデータの送受信を行なう。ＴＣＰ／ＩＰ制御５０２は、ＴＣＰ／ＩＰプロトコルに従った通信の制御を行なう。ＨＴＴＰ制御５０４は、ＨＴＴＰクライアント機能を有し、画像形成装置１０６のＨＴＴＰサーバ制御６０４（図６）とＨＴＴＰプロトコルに従った通信を行なう。また上位アプリケーションから、ＳＳＬ接続による、ＨＴＴＰプロトコル通信が要求された場合、ＳＳＬ制御５０３と連携してＳＳＬ接続によるＨＴＴＰ通信を実現する。ＳＯＡＰ制御５０５は、ＸＭＬパーサ５０６と連携し、印刷アプリケーション５０７から渡されたデータをＳＯＡＰ要求メッセージへ変換する。そのＳＯＡＰ要求メッセージを画像形成装置１０６へ送信するとともに、その画像形成装置１０６から返されたＳＯＡＰ応答メッセージを解析して、その結果を印刷アプリケーション５０７へ渡す。ＰＤＬ制御５０８は、印刷アプリケーション５０７から渡された印刷データを、画像形成装置１０６がサポートするＰＤＬ（Page Description Language）形式のデータに変換して印刷ジョブとして転送する。

図６は、本実施の形態に係る画像形成装置１０６のソフトウェア構成を示すブロック図である。

ネットワークドライバ６０１は、ネットワークＩ／Ｆ制御部４１２（図４）を制御し、ネットワーク１００との間でデータの送受信を行なう。ＴＣＰ／ＩＰ制御６０２は、ＴＣＰ／ＩＰプロトコルに従った通信の制御を行なう。ＨＴＴＰ制御６０４はＨＴＴＰサーバ機能を有し、クライアント上のＨＴＴＰクライアント制御５０４とＨＴＴＰプロトコルに従った通信を行なう。また、クライアントからの接続要求がＳＳＬ接続要求の場合、ＳＳＬ制御６０３と連携してＨＴＴＰＳで通信を行なう。ここで要求メッセージがイベント通知の登録要求である場合は、ＨＴＴＰ制御６０４、ＳＯＡＰ制御６０５、イベント通知制御６０７がその要求を解析し、応答メッセージを生成して送信する。イベントの通知先の保持や、通知待ちのイベントの記憶は全てイベント通知制御６０７が行う。よって、この画像形成装置１０６のプリンタエンジン４０１及びスキャナエンジン４０４で何らかのイベントが発生した場合は、イベントが発生した旨がそれぞれプリンタドライバ６０９、スキャナドライバ６０８を経由して、イベント通知制御６０７に通知される。このイベント通知制御６０７は、内部に保持している管理テーブルの情報に従い、イベント通知を行い、イベント通知の登録を解除する解除処理を行う。ＰＤＬ制御６１０は、クライアント（１０１乃至１０５）から送られるＰＤＬデータを受信し、そのＰＤＬデータがプリンタドライバ６０９を通じて記録紙などの記録媒体に印刷（記録）されるように制御する。ＳＯＡＰ制御６０５は、ＸＭＬパーサ６０６と連携し、イベント通知制御６０７から渡されたイベント情報をＳＯＡＰ形式へ変換する。こうしてＳＯＡＰ形式へ変換されたイベント情報をＨＴＴＰ制御６０４を介してクライアントに送信する。

図７は、本実施の形態のシステムにおけるイベント通知の登録、及びイベント情報の通知時のシーケンスを示す図である。ここでの主な処理内容は、クライアント１０１とクライアント１０２がそれぞれ画像形成装置１０６へイベント通知の登録要求を送信する。これに従って画像形成装置１０６は、その登録要求で指定されている事項に従ってイベントの発生を、各対応するクライアントに通知する。またこのイベント通知には上限回数が設定されており、イベント通知された回数がその上限回数に到達すると、画像形成装置１０６からクライアントへのイベント通知の登録が無効になる。更にクライアントがイベント通知を要求する場合は、イベント通知の再登録を行う必要がある。以下、シーケンスの詳細を説明する。

ステップＳ７０１で、クライアント１０１が画像形成装置１０６へイベント通知の登録要求をＳＯＡＰメッセージで送信する。ステップＳ７０２で、そのイベント通知の登録要求に対して画像形成装置１０６はクライアント１０１へ保証できるイベントの通知回数を算出する。また、画像形成装置１０６はクライアント１０１をイベント情報の通知先として管理テーブルに登録する。そしてステップＳ７０３で、その通知回数を示すＳＯＡＰ応答メッセージを、クライアント１０１に返信する。このＳＯＡＰ応答メッセージには、イベント通知の登録要求を受理した旨と、イベント通知の上限回数とが含まれている。ここでは上限となる回数を１０回としている。この場合、イベント情報が通知された回数が１０回になるまでは、クライアント１０１へのイベント通知の登録が有効である。イベント情報が１０回通知された段階で、そのクライアント１０１に対するイベント通知の登録は無効となる。よって、クライアント１０１が、継続してイベント情報の通知を要求する場合は、再度、イベント通知の登録要求を行うことが必要となる。こうしてステップＳ７０１乃至ステップＳ７０３で、イベント通知の登録が完了する。

その後ステップＳ７０４で、画像形成装置１０６のプリンタエンジン４０４でイベントが発生すると、イベント通知制御６０７に保存された管理テーブルに基づいて、管理テーブルに登録されているクライアント（ここではクライアント１０１）に、イベントが発生したことを通知する。ここではステップＳ７０５で、紙詰まり発生を通知し、ステップＳ７０６でドア・オープンを通知し、ステップＳ７０７では、紙詰まり解消をクライアント１０１へ通知している。

またステップＳ７０８乃至Ｓ７１０では、別のクライアント１０２からのイベント通知の登録要求を受付けて、クライアント１０１の場合と同様のシーケンスが実行されている。ここではイベント情報の通知先が２つの場合を示し、ステップＳ７１１でイベントが発生した場合には、画像形成装置１０６は、これら２つのクライアント１０１，１０２にイベント情報を送信している（ステップＳ７１２乃至Ｓ７１３）。尚、ここではクライアント１０１，１０２は共に、プリンタ関連のイベントを通知するよう画像形成装置１０６に要求しているものとする。

ここでステップＳ７１３のイベント通知により、クライアント１０１へのイベントの通知回数がの上限回数（１０回）に達する。このためステップＳ７１４では、イベント通知制御６０７は、そのクライアント１０１を管理テーブルから削除し、クライアント１０１に対するイベント通知の登録を無効にする。

クライアント１０１は、ステップＳ７１３でイベント情報を受信したことにより、イベント通知の登録が画像形成装置１０６で無効になったと判断する。そしてステップＳ７１５で、イベント通知の再登録が必要か否かを判断する。再登録が必要と判断した場合はステップＳ７１６で、イベント通知の登録要求を画像形成装置１０６に送信する。そしてステップＳ７１７で、画像形成装置１０６は、クライアント１０１を管理テーブルに登録するとともに、イベントの通知を保証できる上限回数を再計算する。そして再度、ステップＳ７１８で、イベント通知の登録を受け付けた旨と、イベント通知の上限回数をクライアント１０１に返信する。前回は上限回数が１０回であったのに対して、このステップＳ７１８では、上限回数がより少ない７回に変更されている。ステップＳ７１７の時点では、Ｓ７０２の時点と比べて、管理テーブルに既に登録されているクライアント数が増えているためである。

図８は、本実施の形態において、クライアントが、イベント通知の登録要求として使用するＳＯＡＰ要求メッセージの一例を示す図である。

＜ClientID＞タグ８０１で、どのクライアントから受信した要求であるかを特定する。ここではクライアント（Ｃ１０１）からの登録要求であることが記述されている。また＜RequestEventList＞タグ８０２では、通知してほしいイベント情報の種別を個別に指定する。例えば、プリンタ関連のイベントの通知が必要な場合は、＜EventInfo＞タグの子要素である＜EventType＞タグ８０３に「PrEv」を記述する。またスキャナ関連のイベントの通知が必要な場合は、＜EventInfo＞タグの子要素である＜EventType＞タグ８０４に「ScEV」を記述する。

図９は、イベント通知の登録要求に対する応答メッセージの一例を示す図である。

＜ClientID＞タグ９０１には、どのクライアントに対する応答メッセージかを記述する。ここではクライアント（Ｃ１０１）への応答である旨が記述されている。＜AcceptedEventList＞タグ９０２には、図８の＜RequestedEventList＞タグ８０２で指定されたイベント情報の種別に対して、イベント通知の登録が許容されたイベント情報の種別を記述する。１つの種別に対して＜EventInfo＞タグが対応している。イベント通知が画像形成装置１０６に登録された時の登録ＩＤが＜RegistID＞タグに、登録に成功したイベント情報の種別が＜EventType＞タグに、イベントの通知回数の上限値が＜NotifyLimit＞タグに、それぞれ格納される。

図９の９０３は、登録ＩＤが「001111」であり、イベント情報の種別がプリンタ関連であり、イベント通知の上限回数が１２回であることを示している。また９０４では、登録ＩＤが「001112」であり、イベント情報の種別がスキャナ関連であり、イベント通知の上限回数が７回であることを示している。

図１０（Ａ）は、本実施の形態に係る画像形成装置１０６がイベント通知に用いるＳＯＡＰメッセージの一例を示す図、図１０（Ｂ）は、クライアントが返す応答メッセージの一例を示す図である。

イベント情報を示すＳＯＡＰメッセージでは、＜To＞タグ１００１に、イベント通知の登録要求の＜ClientID＞タグに記述されていたＩＤ（ここではＣ１０１）を記述する。これにより、どのクライアント宛のイベント情報であるかを特定できる。イベント情報は、＜EventDataList＞タグ１００２に記述される。ここでは＜EventType＞タグ別に、通知するイベント情報を記述する。図１０（Ａ）の１００２では、プリンタ関連のイベント（「PrEv」）を示し、１００３で示すように、＜Status＞タグ以下の＜StatusCode＞タグにイベントコードをリスト型で列挙する。また、図１０（Ａ）の１００４は、スキャナ関連のイベント（「ScEv」）を示し、１００５で示すように＜Status＞タグ以下の＜StatusCode＞タグにイベントコードをリスト型で列挙する。これを受信したクライアントは、＜StatusCode＞タグに列挙されたイベントコードから、画像形成装置１０６で発生したイベントを把握することができる。

図１０（Ｂ）に示す応答メッセージでは、各クライアントは、イベント情報の通知を正常に受信すると、＜Return＞タグ１００６に「Success」を記述する。

図１１は、本実施の形態に係る画像形成装置１０６におけるイベント情報のキューイング処理の機能概略を説明する図である。ここで図６の画像形成装置１０６のソフトウェア構成図と共通する部分は同じ記号で示し、それらの説明を省略する。

プリンタ関連及びスキャナ関連で何らかのイベントが発生した場合、それぞれ、プリンタドライバ６０９，スキャナドライバ６０８がイベント情報（PrEvi, ScEvi）をイベントキューに加える。こうしてイベントキュー１１０３に入れられたイベント情報をイベント通知制御６０７が取得する。そして後述する図１６のフローに従って、イベントキューに並んでいるイベント情報を複数の送信キューのいずれかへ入れる。ここで１１０５は、スキャナ関連のイベント情報の送信キューを示し、１１０６は、プリンタ関連のイベント情報の送信キューをそれぞれ示している。こうして送信キューに並んでいるイベント情報は、イベントのタイプ毎にそれぞれ独立したＳＯＡＰ制御６０５／ＨＴＴＰ制御６０４によりＳＯＡＰメッセージに変換され、ＴＣＰ／ＩＰ制御６０２及びネットワークドライバ６０１を介して、対応するクライアントに送信される。１１０８，１１０９はそれぞれ、プリンタ関連、スキャナ関連のイベント情報を含むＳＯＡＰメッセージを示している。

図１２乃至図１４は、本実施の形態に係るイベント通知制御６０７が有するイベント情報管理テーブルを説明する図で、図１２（Ａ）は、スキャナ関連の管理テーブルを示し、図１２（Ｂ）は、プリント関連の管理テーブルを示している。また図１３は通知済みNotifyLimit管理テーブルを、図１４は新規クライアント用のNotifyLimit管理テーブルを示している。

このようにイベント情報管理テーブルは３種類のテーブルから構成される。図１２（Ａ）に示す通知待ち管理テーブルは、スキャナドライバ６０８からイベントキューへ加えられたイベント情報と、イベント通知制御６０７によって送信キューに加えられたイベント情報との関連付けを記述している。図１２（Ａ）の例によれば、イベントキューに並んでいるスキャナ関連のイベント情報「ScEv1」に基づいて、スキャナ関連のイベント情報「ScEv1Cl01」「ScEv1Cl02」「ScEv1Cl03」「ScEv1Cl04」「ScEv1Cl05」がスキャナ関連の送信キューに加えられている。なお、「ScEv1Cl01」はクライアント「Cl01」に送信される「ScEv1」のイベント情報を示している。

また図１２（Ｂ）に示す通知待ち管理テーブルは、プリンタドライバ６０９からイベントキューへ加えられたイベント情報と、イベント通知制御６０７によって送信キューに加えられたイベント情報との関連付けを記述している。図１２（Ｂ）の例によれば、イベントキューに並んでいるプリンタ関連のイベント情報「PrEv1」に基づいて、プリンタ関連のイベント情報「PrEv1Cl01」「PrEv1Cl02」「PrEv1Cl03」「PrEv1Cl04」「PrEv1Cl05」がプリンタ関連の送信キューに加えられている。なお、「PrEv1Cl01」は、クライアント「Cl01」に送信される「PrEv1」のイベント情報を示している。

これら図１２の管理テーブルは、イベントが発生してイベント通知制御６０７が、通知用のイベント情報を生成した段階でレコードが追加される。そして、このイベント情報の通知が成功すると、このテーブルから、そのレコードが削除される。EvSrcフィールドには、ドライバが生成した時のキューＩＤが記述される。Sc(Pv)SndWaitEvフィールドには、送信キューＩＤが記述される。このテーブルはイベント情報の種別ごとに個別に存在する。

図１３は、通知済みNotifyLimit管理テーブルを示し、クライアントからイベント通知の登録要求を受付けてイベント通知の登録をした段階で、イベント情報の種別ごとに１レコードが追加される。ClientIDフィールドには、このイベント通知の登録要求をしてきたクライアントのClientIDが登録される。またEvTypeには、そのクライアントから要求されたイベントの種別（EventType）（ここではプリンタ関連、スキャナ関連）が記述される。NotifyLimitは、イベントを通知する残り回数が記憶されている。RegIDは、イベント通知の登録要求の登録ＩＤで、各クライアントの＜EventType＞毎に固有の値をとる。

図１４に示す新規クライアント用のNotifyLimit管理テーブルは、現在の送信キューの処理状況を監視し、イベント通知の登録要求の応答でクライアントへ通知するNotifyLimitの値（イベントの通知回数の上限値）の計算に用いる。本実施の形態に係る画像形成装置１０６では、２つのイベントタイプ、即ち、スキャナ関連とプリンタ関連（ScEv／PrEv）をサポートしているので、２レコードとなる。QueueMaxフィールドは、各イベントタイプ毎に、図１１の送信キュー（１１０５または１１０６）で格納可能なイベント情報の数を示している。ClientNumフィールドは、現時点でイベント通知の通知先として登録されているクライアントの数を記述する。SendWaitingEventフィールドは、イベント通知制御６０７によって生成されて、送信キューで通知待ちとなっているイベント情報の数を記述する。ProcessingEventフィールドは、送信キュー内のイベント情報の元となっているイベントキュー内のイベント情報の数を記述する。Reservedフィールドは、通知済みNotifyLimit管理テーブル（図１３）の残り通知回数（NotifyLimit）をイベントのタイプ毎に集計した値を記述する。NewClフィールドは必ず、イベント通知の通知先として登録できるのを保証しておきたいクライアントの数を示す。SndQueueは、［送信キューで格納可能なイベント情報の数（QueueMax）］−［通知待ちとなっている送信キュー内のイベント情報の数（SendWaitingEvent）］−［残り通知回数（Reserved）］に従って算出される。よってこのSndQueueは、送信キューで新規に扱えるイベント情報の数を記述する。NotifyLimitの値は、［送信キューで新規に扱えるイベント情報の数（SndQueue）］／［イベント通知の通知先として登録できることを保証しておきたいクライアントの数（NewCl）］で算出され、新規に登録できるのを保証するクライアントに応答できるNotifyLimitの最大値を記述する。

図１５は、イベント通知の登録要求を受信した際の画像処理装置１０６における処理を説明するフローチャートで、この処理を実行するプログラムは、実行時にＨＤＤ４０６からＲＡＭ４０８にロードされ、ＣＰＵ４０７の制御の下に実行される。

まずステップＳ１５０１で、図８に示すイベント通知の登録要求を受信するとステップＳ１５０２に進み、その登録要求で通知するよう要求されたイベント情報のタイプを確認する。次にステップＳ１５０３で、図１４に示す新規クライアント用NotifyLimit管理テーブルを参照して、その要求してきたクライアントに割り当てられる通知回数（NotifyLimit値）を取得する。次にステップＳ１５０４で、ステップＳ１５０３で取得したNotifyLimit値が「１」以上かどうかを判定する。「１」以上でないとき、即ち、そのクライアントに通知回数が割り当てられないときはステップＳ１５０７に進み、その登録要求を送信してきたクライアントに対して、イベント通知の登録が失敗した旨を含む応答メッセージを送信する。

一方ステップＳ１５０４でNotifyLimit値が「１」以上であればステップＳ１５０５に進み、図１３に示す通知済みNotifyLimit管理テーブルに新規レコードを追加する。ここで、通知済みNotifyLimit管理テーブル全体でユニークなRegIDを新規に生成し、生成したRegIDと、ステップＳ１５０４の判定で取得したNotifyLimit値と、ステップＳ１５０１で受信した登録要求の＜ClientID＞タグに記述されていたＩＤとをそれぞれのフィールドに記述する。次にステップＳ１５０６で、その要求してきたクライアントに対して、イベント通知の登録が成功した旨を含む応答メッセージを送信する。

尚、ステップＳ１５０１，ステップＳ１５０６，ステップＳ１５０７の処理は、図６のソフトウェアでは、ＳＯＡＰ制御６０５で実行される。またステップＳ１５０２，ステップＳ１５０３，ステップＳ１５０４，ステップＳ１５０５の処理は、イベント通知制御６０７で実行される。

図１６は、本実施の形態に係る画像形成装置１０６において実行されるイベント情報の生成処理を示すフローチャートで、この処理を実行するプログラムは、実行時にＨＤＤ４０６からＲＡＭ４０８にロードされ、ＣＰＵ４０７の制御の下に実行される。

ステップＳ１６０１で、イベント通知制御部６０７がプリンタドライバ６０９またはスキャナドライバ６０８から、新規に発生したイベントを示すイベント情報を受信する。次にステップＳ１６０２で、図１２（Ａ）（Ｂ）に示す通知待ち管理テーブルによって管理されている送信キューに、ステップＳ１６０１で受信したイベント情報を追加できるか否かを判定する。追加可能な場合はステップＳ１６０３へ進み、追加できない場合はステップＳ１６０４へ進む。ここで追加可能かどうかは、送信キューに並んでいるイベント情報の数が送信キューが格納可能なイベント情報の数の最大値以上であるか、或はイベント通知の通知先として登録されているクライアントの数が上限値を超えているかなどに基づいて判定される。ステップＳ１６０３では、そのイベント情報を送信キューに追加するべく、そのイベント情報に対応する送信キューＩＤを通知待ち管理テーブルに追加する。そして図１４に示す新規クライアント用のNotifyLimit管理テーブルのProcessingEvent及びSndWaitingEventを更新して終了する。

またステップＳ１６０３で追加できないと判断した場合はステップＳ１６０４に進み、ステップＳ１６０１で取得したイベント情報を破棄して処理を終了する。尚この図１６のフローチャートで示す処理は、図６のソフトウェアでは、イベント通知制御６０７で実行される。

図１７は、本実施の形態に係る画像形成装置１０６において実行されるのイベント情報の通知（送信）、通知完了後の管理テーブルの更新処理を示すフローチャートで、この処理を実行するプログラムは、実行時にＨＤＤ４０６からＲＡＭ４０８にロードされ、ＣＰＵ４０７の制御の下に実行される。

まずステップＳ１７０１で、送信キューの先頭のイベント情報を取得する。次にステップＳ１７０２で、ステップＳ１７０１で取得したイベント情報を、対応するクライアントに通知する。次にステップＳ１７０３で、このイベント通知が成功したか判定する。イベント通知が成功しないときはステップＳ１７０２に戻るが、イベント通知が成功するとステップＳ１７０４に進み、図１３に示す通知済みNotifyLimit管理テーブルにおいて、通知先となったクライアントに対応するNotifyLimit値を−１する。その結果、NotifyLimit値が「０」となった場合は、そのクライアントに対するレコードを通知済みNotifyLimit管理テーブルから削除する。そして、これに伴って図１４に示す、新規クライアント用のNotify管理テーブルのClientNum，ProcessingEvent，SendWaitingEvent，Reserved，SndQueue，NotifyLimitを更新して、この処理を終了する。

以上説明したように本実施の形態によれば、画像形成装置が、送信キューに並んでいるイベント情報の数に応じて、イベント通知の登録を要求するクライアントへのイベントの通知回数の上限値を動的に決定できる。なお、イベント通知の登録が有効な期間を通知回数で示したが、時間で示しても良い。この場合には、送信キューで新規に扱えるイベント情報の数や、イベント通知の通知先として登録できることを保証しておきたいクライアントの数や、通知待ちとなっている送信キュー内のイベント情報の数に基づいて決定される。

これにより、イベント通知の通知先として登録されたクライアントの数が急増した場合や、発生するイベントの数が急増した場合でも、通知先を絞り込み、通知先として事前に登録されているクライアントには確実にイベントを通知できるようにできる。これとともに、新規のイベント通知先の受付を限定することで、イベント情報の通知が欠落することなく高負荷状態を回避することができる。

尚、本実施の形態では、画像形成装置とクライアントとの間でのイベント通知の場合で説明したが本発明はこれに限定されるものでなく、一般的なクライアントとサーバ間、ＰＣ同士、或はＰＣと各種入出力機器との間でのイベント処理にも適用できる。

（他の実施形態）
以上、本発明の実施形態について詳述したが、本発明は、複数の機器から構成されるシステムに適用しても良いし、また一つの機器からなる装置に適用しても良い。

なお、本発明は、前述した実施形態の機能を実現するソフトウェアのプログラムを、システム或いは装置に直接或いは遠隔から供給し、そのシステム或いは装置のコンピュータが該供給されたプログラムを読み出して実行することによっても達成され得る。その場合、プログラムの機能を有していれば、形態は、プログラムである必要はない。

従って、本発明の機能処理をコンピュータで実現するために、該コンピュータにインストールされるプログラムコード自体も本発明を実現するものである。つまり、本発明のクレームでは、本発明の機能処理を実現するためのコンピュータプログラム自体も含まれる。その場合、プログラムの機能を有していれば、オブジェクトコード、インタプリタにより実行されるプログラム、ＯＳに供給するスクリプトデータ等、プログラムの形態を問わない。

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

その他、プログラムの供給方法としては、クライアントコンピュータのブラウザを用いてインターネットのホームページに接続し、該ホームページからハードディスク等の記録媒体にダウンロードすることによっても供給できる。その場合、ダウンロードされるのは、本発明のコンピュータプログラムそのもの、もしくは圧縮され自動インストール機能を含むファイルであってもよい。また、本発明のプログラムを構成するプログラムコードを複数のファイルに分割し、それぞれのファイルを異なるホームページからダウンロードすることによっても実現可能である。つまり、本発明の機能処理をコンピュータで実現するためのプログラムファイルを複数のユーザに対してダウンロードさせるＷＷＷサーバも、本発明のクレームに含まれるものである。

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

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

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

本発明の実施の形態に係るシステムを説明する構成図である。 本発明の実施の形態に係るイベント通知処理時のシステム構成を示す図である。 本発明の実施の形態に係るクライアントのハードウェア構成を示すブロック図である。 本実施の形態に係る画像形成装置の概略構成を示す構成図である。 本実施の形態に係るクライアントのソフトウェア構成を説明するブロック図である。 本実施の形態に係る画像形成装置のソフトウェア構成を示すブロック図である。 本実施の形態に係るイベントの通知登録、及びイベント情報の通知時のシーケンスを示す図である。 本実施の形態に係るクライアントが、イベント通知の登録で使用するＳＯＡＰ要求メッセージの一例を示す図である。 本実施の形態に係るイベント通知の登録要求に対する応答メッセージの一例を示す図である。 本実施の形態に係る画像形成装置がイベントの通知に用いるＳＯＡＰメッセージの一例を示す図（Ａ）、及びクライアントが返す応答メッセージの一例を示す図（Ｂ）である。 本実施の形態に係る画像形成装置におけるイベント・キュー処理の機能概略を説明する図である。 本実施の形態に係るイベント通知制御が有するイベント情報管理テーブルを説明する図である。 通知済みNotifyLimit管理テーブルの一例を示す図である。 新規クライアント用のNotifyLimit管理テーブルの一例を示す図である。 本実施の形態に係る画像形成装置における、イベント通知の登録要求を受信した際の処理を説明するフローチャートである。 本実施の形態に係る画像形成装置において実行されるイベント情報の通知キューの生成処理を示すフローチャートである。 本実施の形態に係る画像形成装置において実行されるのイベント情報の通知、通知完了後の管理テーブルの更新処理を示すフローチャートである。

Claims (13)

1. 状態情報を通知する電子機器であって、
   特定の外部機器に状態情報を通知することを前記電子機器に登録するよう求める登録要求を外部機器から受信する受信手段と、
   前記特定の外部機器に対して状態情報を通知する通知手段と、
   前記特定の外部機器への状態情報の通知が有効な期間を動的に決定する決定手段と、
   前記決定手段により決定された期間が終了すると、前記特定の外部機器に状態情報を通知することの登録を無効にする無効化手段と、
   を有することを特徴とする電子機器。
2. 前記決定手段は、状態情報の通知先として新たに登録可能な外部機器の数、状態情報の通知待ちの件数の少なくともいずれかを基に前記期間を決定することを特徴とする請求項１に記載の電子機器。
3. 前記決定手段により決定された期間を、前記登録要求を送信した外部機器に送信する期間通知手段を更に有することを特徴とする請求項１又は２に記載の電子機器。
4. 前記通知手段は、前記決定手段により決定された期間のうちの残りの期間と共に前記状態情報を通知することを特徴とする請求項１乃至３のいずれか１項に記載の電子機器。
5. 前記特定の外部機器の識別情報、通知されるべき状態情報の種別及び前記決定手段により決定された期間を登録する登録手段を更に有することを特徴とする請求項１乃至４のいずれか１項に記載の電子機器。
6. 前記決定手段により決定された期間を基に、前記特定の外部機器に状態情報を通知することの登録の可否を判定する判定手段を更に有することを特徴とする請求項１乃至５のいずれか１項に記載の電子機器。
7. 前記決定手段により決定される期間は、状態情報の通知回数で示されることを特徴とする請求項１乃至６のいずれか１項に記載の電子機器。
8. 状態情報を通知する電子機器における制御方法であって、
   特定の外部機器に状態情報を通知することを前記電子機器に登録するよう求める登録要求を外部機器から受信する受信工程と、
   前記受信工程で受信したイベント通知の登録要求に応じて、登録の可否を判定する判定工程と、
   前記特定の機器に対して状態情報を通知する通知工程と、
   前記特定の外部機器への状態情報の通知が有効な期間を動的に決定する決定工程と、
   前記決定工程で決定された期間が終了すると、前記特定の外部機器に状態情報を通知することの登録を無効にする無効化工程と、
   を有することを特徴とする電子機器における制御方法。
9. 前記決定工程では、状態情報の通知先として新たに登録可能な外部機器の数、状態情報の通知待ちの件数の少なくともいずれかを基に前記期間を決定することを特徴とする請求項８に記載の電子機器における制御方法。
10. 前記決定工程で決定された期間を、前記登録要求を送信した外部機器に送信する期間通知工程を更に有することを特徴とする請求項８又は９に記載の電子機器における制御方法。
11. 前記通知工程では、前記決定工程で決定された期間のうちの残りの期間と共に前記状態情報を通知することを特徴とする請求項８乃至１０のいずれか１項に記載の電子機器における制御方法。
12. 前記特定の機器の識別情報、通知されるべき状態情報の種別及び前記決定肯定で決定された期間を登録する登録工程を更に有することを特徴とする請求項８乃至１１のいずれか１項に記載の電子機器における制御方法。
13. 前記決定工程で決定された期間を基に、前記特定の外部機器に状態情報を通知することの登録の可否を判定する判定工程を更に有することを特徴とする請求項８乃至１２のいずれか１項に記載の電子機器における制御方法。

Images