印刷デバイス
【課題】 印刷デバイスのイベント発行時に、無駄なイベント送信を行なうことを軽減する。
【解決手段】 イベント送信元となるデバイスは、イベント送信失敗あて先リストを保持する。
イベント送信が失敗した場合には、失敗カウントログを残してイベント送信失敗あて先リストへ追加する。
このイベント送信失敗あて先リストのカウント数が一定の上限を超えた場合には、そのホストに次回イベントを送信するタイミングのときに、イベント送信を行なわない、または、イベント発行宛先の登録を削除する。
【解決手段】 イベント送信元となるデバイスは、イベント送信失敗あて先リストを保持する。
イベント送信が失敗した場合には、失敗カウントログを残してイベント送信失敗あて先リストへ追加する。
このイベント送信失敗あて先リストのカウント数が一定の上限を超えた場合には、そのホストに次回イベントを送信するタイミングのときに、イベント送信を行なわない、または、イベント発行宛先の登録を削除する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワーク上に接続された印刷デバイスのイベント通知の手段に関する。
【背景技術】
【０００２】
近年、インターネットなど大規模なネットワークの普及に伴い、ネットワーク技術が飛躍的に向上している中で、XML、SOAPなどのWWW関連の技術を用いて、ネットワークで接続された機器間の連携によって、さまざまなネットワーク上のサービスを利用できるようにしたWebサービスと呼ばれる技術が注目を集めている。その中でも、ネットワーク上に接続された端末から、ネットワーク上からの印刷要求を受け付け、印刷を実行することが可能な複数の印刷デバイスを登録あるいは検索し、所望の機能を有した印刷デバイスから印刷を行うプリントサービスと呼ばれるサービスが利用されつつある。
【０００３】
このようなサービスを提供する機器は、サービスを開始していることを通知するとともに、機器情報やサービス内容をネットワーク上に公開する。ネットワークに接続されている端末装置はそれらの公開されている情報を取得、あるいは検索することによって、ネットワーク上のサービスにアクセスすることが可能となる。
【０００４】
上記のようなプリントサービスなど各種サービスを提供する印刷デバイスのサービスを利用する場合において、印刷デバイスの印刷ジョブのステータスが変化した場合には、印刷デバイスは、印刷ジョブを要求したホストや、あらかじめ登録されているホストに対して、印刷ジョブのステータス変化を告げる旨のイベントを発行する。このようなイベント通知によって、印刷デバイスのプリント処理終了などのジョブ状態を検知することができる。
【０００５】
また、同様に、紙/トナー切れや紙ジャム発生時などによって印刷デバイスが印刷不可になるなど、デバイス自身のステータスが変化した場合にも、デバイスの状態変化を告げる旨のイベントを発行する。 このようなイベント通知によって、サービスを利用するホストは印刷デバイスの状態変化を検知することができる。
【０００６】
特にネットワーク上に複数の印刷デバイスが接続され、おのおのの印刷デバイスが印刷サービスなどのサービスを提供しているような環境においては、サービス提供機器である複数の印刷デバイスを、統括的にサーバなどのデバイス管理用機器が、各デバイスの状態に不具合が無いか監視している。各印刷デバイスは、あらかじめ登録しておいた管理サーバに対して印刷デバイスのエラー発生等の状態をイベントによって通知する。これによって印刷デバイスのエラー発生等の状態変化を統括的に管理することができる。
【０００７】
又、別の従来例としては、特許文献１をあげることが出来る。
【特許文献１】特開平１１−２６６２４８号公報
【発明の開示】
【発明が解決しようとする課題】
【０００８】
しかし、このようなイベントの発行・通知を行なう場合に、イベント受信側ホストが、何らかの問題によってイベントを受信することができない事態が発生する。
【０００９】
このような状況下で頻繁にイベント通知を行なう必要がある場合には、そのイベント発行の必要があるごとに毎回、不通となっているホストに対して無駄なイベント送信を行なう事となる。また、不通となっているホストに無駄なイベント送信をすることでネットワークトラフィックが増大するといった問題があった。
【課題を解決するための手段】
【００１０】
少なくとも１つ以上のネットワークサービスを利用・提供可能であり、そのサービスに関連するイベント発行および送受信が可能な印刷デバイスにおいて、前記印刷デバイスはイベント発行・通知手段を有し、
前記印刷デバイスは、イベント発行対象となるイベント送信先ホストの宛先情報が含まれるイベント発行宛先リストと、
イベント発行に失敗したホストの宛先情報と、イベント発行に失敗した回数と、イベント発行に失敗した時刻情報を含むイベント送信失敗宛先リストを保持することが可能であって、
前記印刷デバイスは、前記イベント発行宛先リストに、イベント発行対象となるイベント送信先ホストの宛先情報を登録・削除することが可能であって、
前記印刷デバイスは、前記イベント発行宛先リストに登録されているホストの宛先情報に基づき、イベントを送信しイベント発行することが可能であって、
前記印刷デバイスから発行したイベントを、イベント送信先ホストが受信できるか否かを判断する手段と、前記判断手段によってイベントを前記イベント送信先ホストが受信できないと判断した場合には、イベント送信失敗宛先リストに、そのホストの宛先情報と受信に失敗した結果、または結果と時刻情報を登録する手段を有するイベント発行履歴登録手段を有する。
【００１１】
さらに、前記印刷デバイスにおけるイベントを受信できるか否かを判断する手段は、
イベント発行・通知を行う時のコネクション型の通信において、
イベント送信先ホストとの通信コネクションを確立し、イベントデータを送信した後に、イベント送信先ホストから、そのイベントデータ受信にエラーが発生した旨の応答を返したときに、イベント受信ができなかったことを判断する手段と、
イベント送信先ホストとの通信コネクションを確立し、イベントデータを送信した後に、イベント送信先ホストが、一定時間の間に、その送信イベントに対する応答を返さなかったときに、イベント受信ができなかったことを判断する手段と、
さらに、イベント発行・通知を行う時のコネクションレス型の通信において、
イベント送信後にイベント送信先ホストから送信されるイベントに対する応答として、イベント受信にエラーが発生した旨の応答を返したときに、イベント受信ができなかったことを判断する手段と、
イベント送信後にイベント送信先ホストから送信されるイベントに対する応答が一定時間の間に返却されなかったときに、イベント受信ができなかったことを判断する手段を有する。
【００１２】
さらに、前記デバイスのイベント発行履歴登録手段は、
イベント送信の結果に応じて、イベント送信失敗宛先リストにイベント送信先のホストを登録するか否かを決定することが可能な手段と、
イベント発行・通知を行う時のコネクション型、またはコネクションレス型の通信におけるイベント送信に失敗した場合に、発行するイベントの内容に応じて、イベント送信失敗宛先リストにイベント送信先のホストを登録するか否かを決定することが可能な手段と、
イベント受信に失敗したホストが前記イベント送信失敗宛先リストにすでに登録されている場合には、前記イベント送信失敗宛先リストのそのホストのイベント受信失敗回数を負やす手段、またはそのイベント受信に失敗した時刻情報を更新する手段を有する。
【００１３】
また、前記イベント受信失敗回数を増やす手段は、前記のイベント送信先ホストが受信できるか否かを判断する判断手段によって判断された結果に応じて、失敗回数増やすか否かを決定するが可能である。
【００１４】
また、前記イベント受信に失敗した時刻情報を更新する手段は、前記のイベント送信先ホストが受信できるか否かを判断する判断手段によって判断された結果に応じて、イベント受信に失敗した時刻情報を更新するか否かを決定することが可能である。
【００１５】
また前記デバイスは、登録された前記送信失敗宛先リストに登録されているホストにイベント送信をする際に、そのホストのイベント送信失敗カウントが設定された回数の制限を越えているかを判断するイベント発行判断手段を有し、さらに回数の制限を超えた場合には、
イベント送信を行なわないイベント発行手段と、
イベント送信を行なうタイミングを毎回ではなく、一定回数の間隔をあけて送信するように変更するイベント発行手段と、
イベント送信を行なうタイミングを毎回ではなく、所定の数の倍数ごと間隔をあけてイベント送信するように変更するイベント発行手段と、
イベントの内容に応じてイベント送信するか否かを決定するイベント発行手段を有する。
【００１６】
また、前記印刷デバイスは、前記イベント発行履歴登録方法によって、登録された前記送信失敗宛先リストに登録されており、かつ、あらかじめ設定された、既定のイベント発行宛先に登録されているホストにイベント送信をする場合に、前記イベント発行判断手段によって送信を行なわないと判断された場合には、前記既定のイベント発行宛先からそのホストの登録を削除するイベント発行宛先削除方法を有する。
【００１７】
また、前記印刷デバイスは、前記イベント発行履歴登録方法によって、前記送信失敗宛先リストに登録されたホストに、イベントの送信に失敗してから一定時間経過した後、または手動でそのホストに対してホストの存在確認をおこなうイベントを発行し、イベントの送信が可能か否かをチェックするイベント送信可否のチェック手段と、前記チェック手段によってイベント送信に成功した場合には、イベント送信失敗宛先リストからそのホストを削除するイベント送信失敗宛先リストからの削除手段と、さらに、イベント送信失敗宛先リストに登録されているホストが、イベント発行宛先削除手段によって、規定のイベント発行宛先リストから削除されていた場合に、前記チェック手段によってイベント送信に成功した場合には、イベント送信失敗宛先リストからそのホストを削除するとともに、再びイベント発行を行なうことができるように規定のイベント発行宛先リストへ再登録するイベント発行宛先再登録手段を有する。
【００１８】
また、前記デバイスは前記イベント発行履歴登録方法によって、前記送信失敗宛先リストに登録されたホストに、イベントの送信に失敗してから一定時間経過した場合や、あるいは手動で、そのホストに対して存在確認をおこなうイベントを発行し、イベントの送信が可能か否かをチェックするイベント送信可否のチェック手段と、前記チェック手段によってイベント送信に成功した場合には、イベント送信失敗宛先リストのカウント情報をデクリメントする手段と、カウント情報が0になったら、イベント送信失敗宛先リストからそのホストを削除するイベント送信失敗宛先リストからの削除手段と、さらに、イベント送信失敗宛先リストに登録されているホストが、イベント発行宛先削除手段によって、規定のイベント発行宛先リストから削除されていた場合に、前記チェック手段によってイベント送信に成功した場合には、イベント送信失敗宛先リストからそのホストを削除するとともに、再びイベント発行を行なうことができるように規定のイベント発行宛先リストへ再登録するイベント発行宛先再登録手段も有する。
【００１９】
上記手段によって、イベントを受信することができないホストに対して、無駄なイベント送信を行なう事を回避することができる。特に、頻繁にイベント送信を行なう必要がある場合には、ネットワークトラフィックを軽減できる。特に、デバイスがイベントの送受信を行なう際には、送信側ホストであるデバイスが、不通状態の受信側ホストからのイベントレスポンス受信待ち状態になることを回避し、デバイスの処理負荷を軽減することができる。
【発明の効果】
【００２０】
以上説明したように、本発明によれば、印刷デバイスがイベント発行する再に、イベント発行左記のホストが、何らかの理由によって、イベントを受信することができない場合に、無駄なイベント送信を行なう事を回避することができる。特に、頻繁にイベント送信を行なう必要がある場合には、ネットワークトラフィックを軽減できる。また、デバイスがイベント送受信を行なう際には、送信側ホストであるデバイスが、不通状態の受信側ホストからのイベントレスポンス受信待ち状態になることを回避し、デバイスの処理負荷を軽減することができる。
【発明を実施するための最良の形態】
【００２１】
次に、本発明の詳細を実施例の記述に従って説明する。
【００２２】
以下に本発明の実施例を示す。
【００２３】
図１は本発明のサービスの利用・イベント通知を行う一実施の形態の構成を示す図である。
【００２４】
本実施形態は、サービス監視するサーバ端末装置101、サービスを利用するクライアント端末装置102と、サービス提供機器である印刷デバイス103とから構成される。そして、これらのサーバ/クライアント端末装置101、102、印刷デバイス103は、ネットワーク100を介して接続され、相互にデータの通信を行うことができるようになっており、全てネットワーク対応デバイスである。なお、ここではサーバ装置101、クライアント端末装置102、印刷デバイス103を１つのみ示しているが、これらは複数であっても良い。
【００２５】
また、本実施例では、サービス提供機器は印刷サービスにおけるイベント通知を行う印刷デバイスのみを記述しているが、提供するサービスはスキャンサービス、ストレージサービスなどの他のサービスであっても良い。また、本実施例では、サービス提供機器から端末装置へのイベント通知方法について述べるが、サーバ/クライアント端末装置が本発明によるイベント通知を行なう事が可能であっても良い。
【００２６】
図２は、一般的な端末装置のハードウェア構成を示すブロック図である。図２において、200はコンピュータPCであり、図１におけるサーバ/クライアント端末装置101、102、103と同等である。PC200は、CPU201を備え、ROM202またはハードディスク(HD)211に記憶された、あるいはフロッピー（登録商標）ディスクドライブ(FD)212に格納されるプログラムを実行し、システムバス204に接続される各デバイスを総括的に制御し、本実施形態の各手段が構成される。
【００２７】
203はRAMで、CPU201の主メモリ、ワークエリア等として機能する。205はキーボードコントローラ(KBC)で、キーボード(KB)209や不図示のマウス等のポインティングデバイスからの指示入力を制御する。
【００２８】
206はCRTコントローラ(CRTC)で、CRTディスプレイ(CRT)210の表示を制御する。２０７はディスクコントローラ(DKC)で、ブートプログラム（起動プログラム：パソコンのハードやソフトの実行（動作）を開始するプログラム）、複数のアプリケーション、編集ファイル、ユーザファイルそしてネットワーク管理プログラム等を記憶するハードディスク(HD)211、及びフロッピー（登録商標）ディスク(FD)212とのアクセスを制御する。
【００２９】
208はネットワークI/F制御部で、LAN213を介して、印刷デバイスなど、他のネットワーク機器と双方向のデータのやり取りを行う。なお、本実施形態においては、LAN213は図１におけるネットワーク100と同じものである。
【００３０】
図３は、本発明の実施例における印刷デバイスのハードウェア構成を示すブロック図である。図３において、300は印刷デバイスであり、図１における印刷デバイス103と同等である。印刷デバイス300は、CPU（中央処理装置）301を備えている。このCPU301は、ROM（リードオンリーメモリ）302またはハードディスク310に格納されているプログラムを実行して、システムバス304に接続される各デバイスを総括的に制御し、本実施形態の各手段が構成される。303はRAM（ランダムアクセスメモリ）で、CPU301の主メモリ、ワークエリアとして機能する。305は、プリンタI/F制御部であり、プリンタ306を制御する装置である。上記MFP300のCPU301、ROM302またはハードディスク310に記憶されたプログラムにより、本実施形態の各手段が構成される。307は不揮発性のメモリNVRAMであり印刷デバイスの各種設定値を保存するためのものである。パネル制御部308は、オペレーションパネル309を制御し、各種情報の表示、使用者からの指示入力を行なう。ネットワークI/F制御部311は、LAN312とのデータの送受信を制御する。なお、本実施形態においては、LAN310は図１におけるネットワーク100と同じものである。
【００３１】
図２０は本実施例でデバイス103が所有するユーザインターフェース部分であり、図３のオペレーションパネル309に相当する。313は大型タッチパネルで、ユーザはタッチパネルを操作することで、各種設定を行うことが可能である。図の画面はコピーの待機画面である。314はテンキーボタンで、数字などの値を入力するのに使う。Sのボタンはサービスボタンで、このボタンを押下することにより、タッチパネル上に各種サービス画面が出現し、コピー以外のサービスを行うことができる。Rのボタンは設定ボタンで、このボタンを押下することによって、タッチパネル上に、各種設定画面が出現し、パラメータの設定を行うことができる。
【００３２】
図4は、本発明の実施例におけるサーバ/クライアント端末装置200のソフトウェア構成を示すブロック図である。印刷アプリケーション401は、ユーザの指示操作によって印刷を実行するアプリケーションであり、印刷処理制御部へ印刷データを渡す。印刷処理制御部402は、受信したデータを印刷可能なデータに変換するとともに、印刷部数、両面印刷等の印刷に関する様々な制御を行なう。イベント処理部403は本実施例におけるイベント通知処理を実行するための処理を行なうモジュールであり、イベントの送受信に関する処理を行なう。ネットワークドライバ408は、図2におけるネットワークI/F制御部208を制御し、ネットワーク409とのデータ送受信の制御を行う。TCP/IP制御部407は、TCP/IPプロトコルによるデータの送受信及び制御を行なう。HTTPクライアントは、HTTPプロトコルのクライアント機能を有しており、上位アプリケーションの指示によりHTTPリクエストパケットを印刷デバイスに返信するとともに、印刷デバイスから送信された、HTTPレスポンスパケットを解析して、データをSOAP制御部404、サービス検索処理部403や印刷処理制御部402等の上位アプリケーションにわたす処理を行なう。SOAP制御部404はSOAP(Simple Object Access Protocol)と呼ばれるプロトコルを制御するモジュールであり、端末装置から受信したXML（eXtensible Markup LANguage）形式のデータをXMLパーサ405を使用して解析し、印刷処理制御部402の適切なモジュールを呼び出したり、イベント処理部403へ印刷デバイスから送信されるイベントのデータを渡すと同時に、印刷デバイスに返すべきデータをXMLデータに変換し、HTTPサーバ制御部506を介して印刷デバイスに返信する制御を行なう。XMLパーサ505はXML形式データを入力とし解析結果を出力するモジュールである。
【００３３】
図５は、本発明の実施例における印刷デバイス300のソフトウェア構成を示すブロック図である。プリンタ制御部501は、図３におけるプリンタI/F制御部305を制御して、図３におけるプリンタ306へのデータ送信、排紙制御などを行う。印刷処理制御部502は、受信したデータを印刷可能なデータに変換するとともに、印刷部数、両面印刷等の印刷に関する様々な制御を行なう。イベント処理部503は本実施例におけるイベント通知を実行するための処理を行なうモジュールであり、イベントに関する処理を行なう。ネットワークドライバ508は、図3におけるネットワークI/F制御部311を制御し、ネットワーク509とのデータ送受信の制御を行う。TCP/IP制御部507は、TCP/IPプロトコルによるデータの送受信及び制御を行なう。HTTPサーバは、HTTPプロトコルのサーバ機能を有しており、端末装置から受信したHTTPリクエストパケットを解析して、データをSOAP制御部504、サービス検索処理部503や印刷処理制御部502等の上位アプリケーションにわたすと共に、上位アプリケーションの指示によりHTTPレスポンスパケットを端末装置に返信する制御を行なう。SOAP制御部504はSOAP(Simple Object Access Protocol)と呼ばれるプロトコルを制御するモジュールであり、端末装置から受信したXML（eXtensible Markup LANguage）形式のデータをXMLパーサ505を使用して解析し、印刷処理制御部502の適切なモジュールを呼び出したり、イベント処理部503へ端末装置から送信されるイベントのデータを渡すと同時に、端末装置に返すべきデータをXMLデータに変換し、HTTPサーバ制御部506を介して端末装置に返信する制御を行なう。XMLパーサ505はXML形式データを入力とし解析結果を出力するモジュールである。
【００３４】
以下に本実施例における、クライアント端末装置から印刷デバイスであるMFPによって印刷を行う場合の印刷デバイスの動作について述べる。
【００３５】
図６は、本実施例におけるHTTP上のSOAPを用いてクライアント端末装置から印刷デバイスに送信されるCreateJobと称されるパケットデータの一例である。このデータはXML形式で記述されている。CreateJobパケットは、印刷デバイスに対し、ジョブ（印刷）の開始を指示するコマンドであり、要求元のユーザ名(<requesting-user-name>タグ)やジョブの処理に関する指示(<job-instruction>タグ)等の情報が記述されている。<job-instruction>タグには印刷部数を設定する<copies>タグ、両面印刷を設定する<sides>タグ、印刷の仕上げを設定する<finishing>タグなどが含まれ、印刷デバイスはこれらのタグに設定された値に基づき、ジョブの処理を行う。さらに、<job-instruction>タグにはオプションとして<notification-instruction>タグを含めることも可能である。この<notification-instruction>タグにはジョブに関する通知情報が記述される。図６の例においては通知情報として、通知先を設定する<notification-recipient>タグおよび通知条件を設定する<event>タグが記述されている。印刷デバイスはこれらのタグに設定された値に基づいてイベント送信処理を行う。
【００３６】
図７は、図６のCreateJobパケットに対する応答パケットデータの一例である。本データも図６と同様にXML形式で記述され、本実施例においてはHTTP上のSOAPを用いて送受信される。CreateJob応答パケットには、CreateJobコマンド対する結果コード(<result-code>タグ)や生成されたジョブの識別子(<job-id>タグ)、印刷用ポートのURI(<data-sink-uri>タグ)等の情報が含まれている。
【００３７】
図８は、クライアント端末装置が印刷を行う場合における本実施例の印刷デバイスの動作を示すフローチャートである。
【００３８】
以下、図８を用いて、本実施例の印刷デバイスの動作を説明する。
【００３９】
ホストコンピュータから例えば図６に示したようなCreateJobパケットが印刷デバイスに送信されると、印刷デバイスはS801において、CreateJobに記述されたXMLデータを解析し、S802に進み解析結果にエラーがないか判定する。エラーがなければ、S803において印刷データ受信用の印刷ポートを生成する。S803の処理が終わるとS804へ進み、CreateJobパケットに対するレスポンスのXMLデータの生成を行なう。このときに印刷データ受信用に生成したポートのURIを<data-sink-uri>タグの値として設定する。例えば、図５の例のようなURIがXMLデータに埋め込まれる。CreateJobレスポンスデータの生成が終了するとS805へ進み、そのデータをSOAPを用いてホストコンピュータに送信する。ホストコンピュータは、その後、<data-sink-uri>タグで指定されたURIに対してHTTPのPOSTメソッドを用いて印刷データを送信する。図９はHTTP POSTメソッドによる印刷データ転送パケットの一例である。印刷デバイスはS806において印刷ポートに到着したデータを受信し、適切な処理をしながらプリンタに印刷する。S806において、印刷データの受信が正常に終了すると印刷デバイスはS807において図１０に示した例のようなHTTPレスポンスパケットをホストコンピュータに送信し、印刷用ポートを削除（クローズ）して印刷動作を終了する。一方、S802においてCreateJobに記述されたXMLデータにエラーがあると判定された場合はS808へ進み、エラーレスポンスデータを生成する。図１1はエラーレスポンスの例である。次にS805においてエラーレスポンスをホストコンピュータに送信すると、ホストコンピュータは印刷データを送信することはせず、処理を終了する。
【００４０】
次に、上記の本実施例における印刷サービスを提供する印刷デバイスの状態変化によるサーバ端末装置へのイベント通知手段、イベント失敗リスト登録手段、およびイベント発行宛先の登録削除手段について述べる。
【００４１】
図１２は印刷デバイスがイベント通知を行う場合における本実施形態の印刷デバイスの動作を示すフローチャートである。
【００４２】
以下、図１２を用いて、本実施形態の印刷デバイスの動作を説明する。
【００４３】
本実施形態における印刷デバイスは図1に示す印刷デバイス103であり、サーバ装置は図1に示すサーバ装置101、クライアント端末は図1に示すクライアント端末102である。
【００４４】
印刷デバイスは図８に示した印刷処理での印刷ジョブのステータス変化や、紙ジャム、紙/トナー切れなどのエラーによる印刷デバイスの状態変化があった場合には、その状態変化をイベント発行によってサーバ装置あるいはクライアント端末に通知する。
【００４５】
特に、紙/トナー切れなどのエラーによる印刷デバイスの状態変化があった場合には、図１３に示すような、あらかじめイベント発行先のホストに関する情報が登録されているイベント発行宛先リストを保持しておき、そのリストに登録されているホストに対してイベントを発行する。このリストへの登録は、図３に示したオペレーションパネル等からユーザによって宛先が入力され、登録される。
【００４６】
一方、リストからの削除についても同様にオペレーションパネル等からユーザによって削除可能である。
【００４７】
本実施例では、イベントを発行するホストに関する情報としてIPアドレスをイベント発行宛先リスト記載してあるが、その他、MACアドレス、FQDN名などホストを識別できる情報であれば、どのような情報でもよい。
【００４８】
印刷デバイスは前記したような、イベント発行の必要があった場合には、イベント発行宛先リストに登録されているホストに対してイベント発行する前に、ステップS1201において、そのホストが、図１４に示したようなイベント送信失敗宛先リストに登録されているか否かを判断する。イベント送信失敗リストには、以前にイベント発行に失敗したホストに関する情報と、失敗したカウント数、およびイベント送信に失敗した時刻情報が記載されている。本実施例では、前記ホストに関する情報としてIPアドレスをイベント通知リスト記載してあるが、その他、MACアドレス、FQDN名などホストを識別できる情報であれば、どのような情報でもよい。
【００４９】
また、本実施例では、イベント発行宛先リストとイベント送信失敗宛先リストの２つのリストを保持しているが、イベント発行宛先リストに、送信に失敗したカウント数、およびイベント送信に失敗した時刻情報などを記載することによって、イベント送信失敗宛先リストを保持しない構成をとっても良い。
【００５０】
（すなわちイベント発行宛先リスト＝イベント送信失敗宛先リスト）
イベント送信失敗リストにそのホストが登録されていない場合には、次のステップへ進み、ステップS1205において図1５に示したようなイベントパケットデータを生成し、ステップS1206においてイベントパケットデータを送信することで、イベントを発行する。
【００５１】
イベント発行先であるサーバ装置やクライアント装置のホストが、イベント受信可能であった場合には、図１６に示したようなイベントの応答パケットデータが返信されるので、ステップS1207においてステップS1206で発行したイベントの応答が返信されたかを確認することで、イベントの発行に成功したか否かの判断を行い、成功した場合には処理を終了する。
【００５２】
本実施例におけるイベント発行が成功したか否かの判断は、TCPプロトコルなどのコネクション型の通信によって、イベント発行先ホストであるサーバ装置との通信コネクションを確立し、その確立したコネクションにおいて、発行したイベントに対する応答があるか否かで判断を行なっているが、通信コネクションそのものが確立できなかったり、イベント応答としてイベントを受信できなかった旨のエラーなどが返却された場合や、応答待ちのタイムアウトが発生した場合も、イベント発行が失敗したと判断しても良い。
【００５３】
また、イベント発行に関する通信は、UDPプロトコルなどのコネクションレス型の通信であってもよく、イベントデータの送信後、同プロトコルで発行したイベントに対する応答を受け取ることで、イベント発行が成功したか否かを判断しても良い。
【００５４】
従って、コネクション型の通信と同様に、イベント送信後にイベント送信先ホストから送信されるイベントに対する応答として、イベント受信にエラーが発生した旨の応答を返したときや、イベントに対する応答が一定時間の間に返却されなかったときに、イベント受信ができなかったときには、イベント発行が失敗したと判断しても良い。
【００５５】
ステップS1207においてイベントの送信に失敗したと判断した場合には、ステップS1208において、そのホストがイベント送信失敗リストに登録されているか否かの判断を行い、イベント送信失敗リストに登録されていない場合には、ステップS1209においてイベント送信失敗宛先リストにそのホストを登録するとともに、ステップS1210においてイベント送信失敗宛先リスト内の、イベント送信失敗カウントを増やし、さらにその時刻情報を登録して処理を終了する。
【００５６】
本実施例では、ステップS1207においてイベント送信に失敗した何れの場合も、イベント送信失敗リストに登録する、あるいはイベント送信失敗カウントを増やす構成をとっている。
【００５７】
しかし、たとえば「通信のタイムアウトが発生した場合には、イベント送信失敗リストに登録しない、あるいはイベント送信失敗カウントを増さない」など、イベント発行の際のエラーの内容によって、イベント送信失敗リストへの登録やイベント送信失敗カウントを増やすか否かを判断しても良い。
【００５８】
また、本実施例では何れのイベントにおいてもイベント送信失敗リストに登録する、あるいはイベント送信失敗カウントを増やす構成をとっている。
【００５９】
しかし、イベント送信に失敗したとき、たとえばイベントの内容が
「印刷終了通知」である場合には、イベント送信失敗リストに登録する、あるいはイベント送信失敗カウントを増やす。
【００６０】
「印刷デバイスの設定変更」である場合には、イベント送信失敗リストに登録しない、あるいはイベント送信失敗カウントを増やさない。
【００６１】
など、イベントの内容によって、イベント送信失敗リストへの登録やイベント送信失敗カウントを増やすか否かを判断しても良い。
【００６２】
ステップS1208において、イベント送信失敗リストに登録されている場合には、ステップS1209をスキップし、ステップS1210においてイベント送信失敗宛先リスト内の、イベント送信失敗カウントをインクリメントし、さらにその時刻情報を更新して処理を終了する。
【００６３】
本実施例では、ステップS1207においてイベントの送信に失敗したと判断したイベント送信先ホストが既にイベント送信失敗宛先リストに登録されている場合には、毎回、イベント送信失敗宛先リストの時刻情報を更新しているが、初回にイベント送信に失敗した時刻のみを登録するような構成をとっても良い。
【００６４】
また、ステップS1201において、イベント送信失敗宛先リストに、イベントを送信するホストが登録されている場合には、ステップS1202へ進み、ステップS1202において、イベント送信失敗リストのそのホストのイベント送信失敗カウントの値が、あらかじめ設定してある上限数を超えているか否かの判断を行なう。カウント数が上限を超えていない場合には、ステップS1205へ進み、前記したステップS1205からステップS1210までの処理を行なう。
【００６５】
ステップS1202において、カウント数が上限を超えていない場合には、ステップS1203へ進む。
【００６６】
この場合、イベント送信を行なわずに処理を終了する。
【００６７】
本実施例では、印刷デバイスは、図３のオペレーションパネルからユーザによって、イベント送信失敗のカウント数が一定の値を超えた場合に『イベント発行宛先からホストを削除する』という設定を行なうことができる。ステップS1203において、この設定がされているか否かの判断を行ない、削除の設定がされている場合にはステップS1204において、イベント発行宛先リストからこのホストを削除し、処理を終了する。
【００６８】
本実施例では、イベント送信失敗リストのイベント送信失敗カウントの値が一定の上限値を超えてしまったホストに対しては、イベント送信を行なわない構成をとっているが、
たとえば、上限値を５回と設定されている場合には、さらに失敗した数をカウントし
６回目 ← イベントを送信する
７回目 ← イベントを送信しない
８回目 ← イベントを送信する
９回目 ← イベントを送信しない
……
などのように一定回数の間隔をあけて、イベント送信を行なったり、
５+１回目 ← イベントを送信する
５+２回目 ← イベントを送信する
５+４回目 ← イベントを送信する
５+８回目 ← イベントを送信する
……
などのように一定倍数の回数ごとにイベント送信を行なうなど、イベントの発行間隔を変更するような構成をとっても良い。
【００６９】
さらに、イベントの内容を解析し、その内容に応じてイベント送信を行なわない構成をとっても良い。
【００７０】
また、イベント発行先ホストのイベント発行宛先リスト登録時に、一定の上限値を超えた場合においても、イベント発行宛先リストからの削除を抑止するような設定をオペレーションパネルから行なうことで、リストからの削除しないようにする構成をとっても良い。
【００７１】
本実施例では、前記した図１２のステップS1202からS1203の処理によって、イベント送信失敗リストに登録されているホストに対して、リスト内の時刻情報を元に、イベント送信に失敗してから一定時間経過している場合には、ホスト存在確認を行なうイベントを発行し、そのホストがイベント受信可能であるかの検証を定期的に行ない、そのホストがイベント受信可能であった場合には、イベント送信失敗リストから削除する。
【００７２】
また、イベント送信失敗リストに登録されているホストが、ステップS1204の処理によって、イベント発行宛先リストから削除されてしまっていた場合に、ホスト存在確認ができた場合には、そのホストをイベント発行宛先リストへ再登録を行なう。
【００７３】
図１５は、本実施例におけるHTTP上のSOAPを用いて印刷デバイスからサーバ装置あるいはクライアント端末に送信されるイベントパケットデータの一例である。このデータは図１２のステップS1205で作成されるイベントパケットデータでありXML形式で記述されている。イベントパケットには、Notifyメソッドが用いられる。イベントパケットはサーバ装置あるいはクライアント端末に対し、ジョブ（印刷）または印刷デバイスの状態変化を通知するコマンドであり、イベントの内容(<trigger-event>タグ)やイベント発生時刻(<trigger-time >タグ)、イベントのID情報（< notification-id >タグ）等の情報が記述されている。本実施例でのイベントパケットデータには、ジョブの状態を通知するイベントの例(図１５-A)とデバイスの状態を通知するイベントの例(図１５-B)を記述している。ジョブの状態をイベント通知する場合には、 <trigger-event>タグ内にジョブの終了（" job-completed"）やジョブのキャンセル（"job-canceled" ）等のジョブのステータスを表す文字列が記述される。
【００７４】
また、デバイスの状態をイベント通知する場合には、 <trigger-event>タグ内にデバイスの状態変化を表す文字列“device-state-changed”が記述され、さらに<device-status>タグ内にデバイスの状態を表す文字列（"stop" etc。）と、<device-state-reason>タグ内にデバイスの状態変化の理由（紙ジャムやトナー残量が少ない）などを表す文字列（"paper-jam"、 "toner-low"）が記述される。
【００７５】
図１６は、図１５のイベントパケットに対する応答パケットデータの一例である。本データも図１６と同様にXML形式で記述され、本実施例においてはHTTP上のSOAPを用いて送受信される。イベント応答パケットにはNotifyResponseメソッドが用いられ、イベントパケットのNotifyコマンド対する結果コード(<result-code>タグ)が含まれている。正常にイベントを受信した場合には(<result-code>タグ内に"ok"が記述される。
【００７６】
図１７は印刷デバイスがイベント送信失敗リストに登録されているホストの存在確認を行なう動作と、イベント送信失敗リストに登録されているイベント発行宛先リストから削除されたホストをイベント発行宛先リストへ再登録する場合における、本実施形態の印刷デバイスの動作を示すフローチャートである。
【００７７】
以下、図１７を用いて、本実施形態の印刷デバイスの動作を説明する。
【００７８】
本実施形態における印刷デバイスは図1に示す印刷デバイス103であり、サーバ装置は図1に示すサーバ装置101、クライアント端末は図1に示すクライアント端末102である。
【００７９】
印刷デバイスは、一定時間間隔で図１７に示した以下のステップの処理を定期的に行なう。この処理を実行するか否かの設定は図３に示したオペレーションパネルからユーザによって設定することが可能である。また、その時間間隔もユーザか指定・設定することが可能である。
【００８０】
また、何れの時間が経過している場合にもデバイスのオペレーションパネルなどから手動で、上記の処理を実行させてもよい。
【００８１】
まず、印刷デバイスはステップS1701において、イベント送信失敗宛先リストからイベント送信に失敗したホストの情報を取得する。
【００８２】
次に、ステップS1702においてステップS1701でのホスト情報の取得に成功したか否かの判断を行い、成功した場合には次のステップに進む。ホスト情報の取得に失敗あるいは、イベント送信失敗宛先リストにホストの情報がない場合には、処理を終了する。
【００８３】
次にステップS1703において、ステップS1701において取得したイベント受信の確認対処となるホストがイベント受信に失敗した時刻が現在時刻から一定時間経過しているか否かの判断を行なう。
【００８４】
ステップS1703においてそのホストがイベント受信に失敗した時刻から、前記した設定時刻よりも時間が経過している場合には、次のステップへ進む。また、設定時刻よりも時間が経過していない場合には、ステップS1701に戻り、次のホスト情報を取得し、前記した同様の処理を行なう。
【００８５】
S1704において、図１８に示したようなホストの存在確認を行なうイベント発行のためのイベントパケットデータを作成し、S1705においてホストの存在確認イベントの発行送信処理を行なう。
【００８６】
存在確認イベント発行先であるサーバ装置やクライアント装置のホストが、イベント受信可能であった場合には、図１９に示したようなイベントの応答パケットデータが返信されるので、ステップS1706において、ステップS1705で発行したイベントの応答が返信されたかを確認することで、イベントの発行に成功したか否かの判断を行い、成功した場合には次のステップへ進む。また、イベント送信に失敗した場合には、S1710において、イベント送信失敗宛先リストの時刻情報を更新し、ステップS1701に戻り、次のホスト情報を取得し、前記した同様の処理を行なう。
【００８７】
上記のイベント発行が成功したか否かの判断は、図１２を用いて説明したイベント発行における判断と同様である。
【００８８】
ステップS1706において送信先ホストが存在確認イベントの受信に成功し、レスポンスパケットデータを受信した場合には、送信ホストがイベントの受信が可能であると判断されるので、ステップS1708においてイベント送信失敗リストから削除する。さらに次のステップS1709においてイベント送信失敗リストから削除したホストが、イベント発行宛先リストに登録されているか否かを判断する。登録されていない場合には、図１２に示したステップS1204において既にイベント発行宛先リストから削除されていることになるので、ステップS1709において、そのホストをイベント発行宛先リストにホストの情報を再登録する。
【００８９】
ステップS1708においてイベント送信失敗リストから削除したホストが、イベント発行宛先リストに登録されている場合には、処理を行なわずに、ステップS1701に戻り、次のホスト情報を取得し、前記した同様の処理を行なう。
【００９０】
本実施例では、イベント送信失敗宛先リストに登録されているホストが、存在確認イベントの発行によって、イベントの受信が可能であると判断された場合には、いずれの場合も、イベント送信失敗宛先リストからの削除、または、イベント発行宛先リストへの再登録を行なっているが、存在確認イベントの発行によって、ホストがイベントの受信が可能であると判断された場合には、イベント送信失敗宛先リストのイベント送信失敗カウントを減らしてしていき、最終的にカウントが０になったらイベント送信失敗リストからの削除や、イベント発行宛先リストにホストの情報を再登録するような構成をとってもよい。
【００９１】
S1709までの処理が終了したら、ステップS1701に戻り、次のホスト情報を取得し、前記した同様の処理を行なう。
【００９２】
イベント送信失敗宛先リスト内に登録されている全てのホストに対して、上記のステップを実行したら処理を終了する。
【００９３】
本実施例においてイベント送信失敗宛先リスト内に登録されているホストの情報は、図３に示したオペレーションパネル等に表示可能であって、ユーザによってホストの宛先をリストから削除することも可能である。
【００９４】
なお、本実施例においては、ダミーイベントを送信することによりホストの存在を確認していたが、例えば、Pingコマンドなどを使用しIPレベルでホストの存在を確認する構成とすることも可能である。送信先ホストの存在やイベント発行が可能であることが確認できれば何れの通信プロトコルを使用してもかまわない。
【００９５】
図１８は、本実施例におけるHTTP上のSOAPを用いて印刷デバイスからサーバ装置あるいはクライアント端末に送信されるホストの存在確認イベントのパケットデータの一例である。このデータは図１７のステップS1705で作成されるイベントパケットデータであり、XML形式で記述されている。イベントパケットには、Notifyメソッドが用いられる。イベントパケットはサーバ装置あるいはクライアント端末に対し、ジョブ（印刷）または印刷デバイスの状態変化を通知するコマンドであり、イベントの内容(<trigger-event>タグ)やイベント発生時刻(<trigger-time >タグ)、イベントのID情報（< notification-id >タグ）等の情報が記述されている。本実施例におけるイベントパケットデータには、イベントの内容を表す<trigger-event>タグ内に、ホストが存在するか否か、またはイベントを受信可能であるか否かの確認を行なうためのダミーイベントを表す"dummy-event"が記述される。
【００９６】
図１９は、図１８のイベントパケットに対する応答パケットデータの一例である。本データも図１６と同様にXML形式で記述され、本実施例においてはHTTP上のSOAPを用いて送受信される。イベント応答パケットはNotifyResponseメソッドが用いられ、イベントパケットのNotifyコマンド対する結果コードのみ(<result-code>タグ)が含まれている。正常にイベントを受信した場合には(<result-code>タグ内に"ok"が記述される。
【図面の簡単な説明】
【００９７】
【図１】本実施例におけるサービス検索・印刷システムの構成図
【図２】端末装置のハードウェア構成ブロック図
【図３】印刷デバイスのハードウェア構成ブロック図
【図４】端末装置のソフトウェア構成ブロック図
【図５】印刷デバイスのソフトウェア構成ブロック図
【図６】印刷デバイスに送信されるCreateJobパケットデータの一例
【図７】CreateJobパケットに対する応答パケットデータの一例
【図８】印刷実行時の印刷デバイスの動作を示すフローチャート
【図９】HTTP POSTメソッドによる印刷データ転送パケットの一例
【図１０】印刷終了時に印刷デバイスが送信するHTTPのレスポンスパケットの例
【図１１】CreateJobパケットエラーのレスポンスの例
【図１２】イベント通知を行う場合における印刷デバイスの動作を示すフローチャート
【図１３】イベント発行宛先リストの一例
【図１４】イベント送信失敗宛先リストの一例
【図１５】イベントパケットデータの一例
【図１６】イベント応答パケットデータの一例
【図１７】イベント発行宛先リストへ再登録する場合の印刷デバイスの動作を示すフローチャート
【図１８】存在確認イベントパケットデータの一例
【図１９】存在確認イベント応答パケットデータの一例
【図２０】印刷デバイスが所有するユーザインターフェース部
【技術分野】
【０００１】
本発明は、ネットワーク上に接続された印刷デバイスのイベント通知の手段に関する。
【背景技術】
【０００２】
近年、インターネットなど大規模なネットワークの普及に伴い、ネットワーク技術が飛躍的に向上している中で、XML、SOAPなどのWWW関連の技術を用いて、ネットワークで接続された機器間の連携によって、さまざまなネットワーク上のサービスを利用できるようにしたWebサービスと呼ばれる技術が注目を集めている。その中でも、ネットワーク上に接続された端末から、ネットワーク上からの印刷要求を受け付け、印刷を実行することが可能な複数の印刷デバイスを登録あるいは検索し、所望の機能を有した印刷デバイスから印刷を行うプリントサービスと呼ばれるサービスが利用されつつある。
【０００３】
このようなサービスを提供する機器は、サービスを開始していることを通知するとともに、機器情報やサービス内容をネットワーク上に公開する。ネットワークに接続されている端末装置はそれらの公開されている情報を取得、あるいは検索することによって、ネットワーク上のサービスにアクセスすることが可能となる。
【０００４】
上記のようなプリントサービスなど各種サービスを提供する印刷デバイスのサービスを利用する場合において、印刷デバイスの印刷ジョブのステータスが変化した場合には、印刷デバイスは、印刷ジョブを要求したホストや、あらかじめ登録されているホストに対して、印刷ジョブのステータス変化を告げる旨のイベントを発行する。このようなイベント通知によって、印刷デバイスのプリント処理終了などのジョブ状態を検知することができる。
【０００５】
また、同様に、紙/トナー切れや紙ジャム発生時などによって印刷デバイスが印刷不可になるなど、デバイス自身のステータスが変化した場合にも、デバイスの状態変化を告げる旨のイベントを発行する。 このようなイベント通知によって、サービスを利用するホストは印刷デバイスの状態変化を検知することができる。
【０００６】
特にネットワーク上に複数の印刷デバイスが接続され、おのおのの印刷デバイスが印刷サービスなどのサービスを提供しているような環境においては、サービス提供機器である複数の印刷デバイスを、統括的にサーバなどのデバイス管理用機器が、各デバイスの状態に不具合が無いか監視している。各印刷デバイスは、あらかじめ登録しておいた管理サーバに対して印刷デバイスのエラー発生等の状態をイベントによって通知する。これによって印刷デバイスのエラー発生等の状態変化を統括的に管理することができる。
【０００７】
又、別の従来例としては、特許文献１をあげることが出来る。
【特許文献１】特開平１１−２６６２４８号公報
【発明の開示】
【発明が解決しようとする課題】
【０００８】
しかし、このようなイベントの発行・通知を行なう場合に、イベント受信側ホストが、何らかの問題によってイベントを受信することができない事態が発生する。
【０００９】
このような状況下で頻繁にイベント通知を行なう必要がある場合には、そのイベント発行の必要があるごとに毎回、不通となっているホストに対して無駄なイベント送信を行なう事となる。また、不通となっているホストに無駄なイベント送信をすることでネットワークトラフィックが増大するといった問題があった。
【課題を解決するための手段】
【００１０】
少なくとも１つ以上のネットワークサービスを利用・提供可能であり、そのサービスに関連するイベント発行および送受信が可能な印刷デバイスにおいて、前記印刷デバイスはイベント発行・通知手段を有し、
前記印刷デバイスは、イベント発行対象となるイベント送信先ホストの宛先情報が含まれるイベント発行宛先リストと、
イベント発行に失敗したホストの宛先情報と、イベント発行に失敗した回数と、イベント発行に失敗した時刻情報を含むイベント送信失敗宛先リストを保持することが可能であって、
前記印刷デバイスは、前記イベント発行宛先リストに、イベント発行対象となるイベント送信先ホストの宛先情報を登録・削除することが可能であって、
前記印刷デバイスは、前記イベント発行宛先リストに登録されているホストの宛先情報に基づき、イベントを送信しイベント発行することが可能であって、
前記印刷デバイスから発行したイベントを、イベント送信先ホストが受信できるか否かを判断する手段と、前記判断手段によってイベントを前記イベント送信先ホストが受信できないと判断した場合には、イベント送信失敗宛先リストに、そのホストの宛先情報と受信に失敗した結果、または結果と時刻情報を登録する手段を有するイベント発行履歴登録手段を有する。
【００１１】
さらに、前記印刷デバイスにおけるイベントを受信できるか否かを判断する手段は、
イベント発行・通知を行う時のコネクション型の通信において、
イベント送信先ホストとの通信コネクションを確立し、イベントデータを送信した後に、イベント送信先ホストから、そのイベントデータ受信にエラーが発生した旨の応答を返したときに、イベント受信ができなかったことを判断する手段と、
イベント送信先ホストとの通信コネクションを確立し、イベントデータを送信した後に、イベント送信先ホストが、一定時間の間に、その送信イベントに対する応答を返さなかったときに、イベント受信ができなかったことを判断する手段と、
さらに、イベント発行・通知を行う時のコネクションレス型の通信において、
イベント送信後にイベント送信先ホストから送信されるイベントに対する応答として、イベント受信にエラーが発生した旨の応答を返したときに、イベント受信ができなかったことを判断する手段と、
イベント送信後にイベント送信先ホストから送信されるイベントに対する応答が一定時間の間に返却されなかったときに、イベント受信ができなかったことを判断する手段を有する。
【００１２】
さらに、前記デバイスのイベント発行履歴登録手段は、
イベント送信の結果に応じて、イベント送信失敗宛先リストにイベント送信先のホストを登録するか否かを決定することが可能な手段と、
イベント発行・通知を行う時のコネクション型、またはコネクションレス型の通信におけるイベント送信に失敗した場合に、発行するイベントの内容に応じて、イベント送信失敗宛先リストにイベント送信先のホストを登録するか否かを決定することが可能な手段と、
イベント受信に失敗したホストが前記イベント送信失敗宛先リストにすでに登録されている場合には、前記イベント送信失敗宛先リストのそのホストのイベント受信失敗回数を負やす手段、またはそのイベント受信に失敗した時刻情報を更新する手段を有する。
【００１３】
また、前記イベント受信失敗回数を増やす手段は、前記のイベント送信先ホストが受信できるか否かを判断する判断手段によって判断された結果に応じて、失敗回数増やすか否かを決定するが可能である。
【００１４】
また、前記イベント受信に失敗した時刻情報を更新する手段は、前記のイベント送信先ホストが受信できるか否かを判断する判断手段によって判断された結果に応じて、イベント受信に失敗した時刻情報を更新するか否かを決定することが可能である。
【００１５】
また前記デバイスは、登録された前記送信失敗宛先リストに登録されているホストにイベント送信をする際に、そのホストのイベント送信失敗カウントが設定された回数の制限を越えているかを判断するイベント発行判断手段を有し、さらに回数の制限を超えた場合には、
イベント送信を行なわないイベント発行手段と、
イベント送信を行なうタイミングを毎回ではなく、一定回数の間隔をあけて送信するように変更するイベント発行手段と、
イベント送信を行なうタイミングを毎回ではなく、所定の数の倍数ごと間隔をあけてイベント送信するように変更するイベント発行手段と、
イベントの内容に応じてイベント送信するか否かを決定するイベント発行手段を有する。
【００１６】
また、前記印刷デバイスは、前記イベント発行履歴登録方法によって、登録された前記送信失敗宛先リストに登録されており、かつ、あらかじめ設定された、既定のイベント発行宛先に登録されているホストにイベント送信をする場合に、前記イベント発行判断手段によって送信を行なわないと判断された場合には、前記既定のイベント発行宛先からそのホストの登録を削除するイベント発行宛先削除方法を有する。
【００１７】
また、前記印刷デバイスは、前記イベント発行履歴登録方法によって、前記送信失敗宛先リストに登録されたホストに、イベントの送信に失敗してから一定時間経過した後、または手動でそのホストに対してホストの存在確認をおこなうイベントを発行し、イベントの送信が可能か否かをチェックするイベント送信可否のチェック手段と、前記チェック手段によってイベント送信に成功した場合には、イベント送信失敗宛先リストからそのホストを削除するイベント送信失敗宛先リストからの削除手段と、さらに、イベント送信失敗宛先リストに登録されているホストが、イベント発行宛先削除手段によって、規定のイベント発行宛先リストから削除されていた場合に、前記チェック手段によってイベント送信に成功した場合には、イベント送信失敗宛先リストからそのホストを削除するとともに、再びイベント発行を行なうことができるように規定のイベント発行宛先リストへ再登録するイベント発行宛先再登録手段を有する。
【００１８】
また、前記デバイスは前記イベント発行履歴登録方法によって、前記送信失敗宛先リストに登録されたホストに、イベントの送信に失敗してから一定時間経過した場合や、あるいは手動で、そのホストに対して存在確認をおこなうイベントを発行し、イベントの送信が可能か否かをチェックするイベント送信可否のチェック手段と、前記チェック手段によってイベント送信に成功した場合には、イベント送信失敗宛先リストのカウント情報をデクリメントする手段と、カウント情報が0になったら、イベント送信失敗宛先リストからそのホストを削除するイベント送信失敗宛先リストからの削除手段と、さらに、イベント送信失敗宛先リストに登録されているホストが、イベント発行宛先削除手段によって、規定のイベント発行宛先リストから削除されていた場合に、前記チェック手段によってイベント送信に成功した場合には、イベント送信失敗宛先リストからそのホストを削除するとともに、再びイベント発行を行なうことができるように規定のイベント発行宛先リストへ再登録するイベント発行宛先再登録手段も有する。
【００１９】
上記手段によって、イベントを受信することができないホストに対して、無駄なイベント送信を行なう事を回避することができる。特に、頻繁にイベント送信を行なう必要がある場合には、ネットワークトラフィックを軽減できる。特に、デバイスがイベントの送受信を行なう際には、送信側ホストであるデバイスが、不通状態の受信側ホストからのイベントレスポンス受信待ち状態になることを回避し、デバイスの処理負荷を軽減することができる。
【発明の効果】
【００２０】
以上説明したように、本発明によれば、印刷デバイスがイベント発行する再に、イベント発行左記のホストが、何らかの理由によって、イベントを受信することができない場合に、無駄なイベント送信を行なう事を回避することができる。特に、頻繁にイベント送信を行なう必要がある場合には、ネットワークトラフィックを軽減できる。また、デバイスがイベント送受信を行なう際には、送信側ホストであるデバイスが、不通状態の受信側ホストからのイベントレスポンス受信待ち状態になることを回避し、デバイスの処理負荷を軽減することができる。
【発明を実施するための最良の形態】
【００２１】
次に、本発明の詳細を実施例の記述に従って説明する。
【００２２】
以下に本発明の実施例を示す。
【００２３】
図１は本発明のサービスの利用・イベント通知を行う一実施の形態の構成を示す図である。
【００２４】
本実施形態は、サービス監視するサーバ端末装置101、サービスを利用するクライアント端末装置102と、サービス提供機器である印刷デバイス103とから構成される。そして、これらのサーバ/クライアント端末装置101、102、印刷デバイス103は、ネットワーク100を介して接続され、相互にデータの通信を行うことができるようになっており、全てネットワーク対応デバイスである。なお、ここではサーバ装置101、クライアント端末装置102、印刷デバイス103を１つのみ示しているが、これらは複数であっても良い。
【００２５】
また、本実施例では、サービス提供機器は印刷サービスにおけるイベント通知を行う印刷デバイスのみを記述しているが、提供するサービスはスキャンサービス、ストレージサービスなどの他のサービスであっても良い。また、本実施例では、サービス提供機器から端末装置へのイベント通知方法について述べるが、サーバ/クライアント端末装置が本発明によるイベント通知を行なう事が可能であっても良い。
【００２６】
図２は、一般的な端末装置のハードウェア構成を示すブロック図である。図２において、200はコンピュータPCであり、図１におけるサーバ/クライアント端末装置101、102、103と同等である。PC200は、CPU201を備え、ROM202またはハードディスク(HD)211に記憶された、あるいはフロッピー（登録商標）ディスクドライブ(FD)212に格納されるプログラムを実行し、システムバス204に接続される各デバイスを総括的に制御し、本実施形態の各手段が構成される。
【００２７】
203はRAMで、CPU201の主メモリ、ワークエリア等として機能する。205はキーボードコントローラ(KBC)で、キーボード(KB)209や不図示のマウス等のポインティングデバイスからの指示入力を制御する。
【００２８】
206はCRTコントローラ(CRTC)で、CRTディスプレイ(CRT)210の表示を制御する。２０７はディスクコントローラ(DKC)で、ブートプログラム（起動プログラム：パソコンのハードやソフトの実行（動作）を開始するプログラム）、複数のアプリケーション、編集ファイル、ユーザファイルそしてネットワーク管理プログラム等を記憶するハードディスク(HD)211、及びフロッピー（登録商標）ディスク(FD)212とのアクセスを制御する。
【００２９】
208はネットワークI/F制御部で、LAN213を介して、印刷デバイスなど、他のネットワーク機器と双方向のデータのやり取りを行う。なお、本実施形態においては、LAN213は図１におけるネットワーク100と同じものである。
【００３０】
図３は、本発明の実施例における印刷デバイスのハードウェア構成を示すブロック図である。図３において、300は印刷デバイスであり、図１における印刷デバイス103と同等である。印刷デバイス300は、CPU（中央処理装置）301を備えている。このCPU301は、ROM（リードオンリーメモリ）302またはハードディスク310に格納されているプログラムを実行して、システムバス304に接続される各デバイスを総括的に制御し、本実施形態の各手段が構成される。303はRAM（ランダムアクセスメモリ）で、CPU301の主メモリ、ワークエリアとして機能する。305は、プリンタI/F制御部であり、プリンタ306を制御する装置である。上記MFP300のCPU301、ROM302またはハードディスク310に記憶されたプログラムにより、本実施形態の各手段が構成される。307は不揮発性のメモリNVRAMであり印刷デバイスの各種設定値を保存するためのものである。パネル制御部308は、オペレーションパネル309を制御し、各種情報の表示、使用者からの指示入力を行なう。ネットワークI/F制御部311は、LAN312とのデータの送受信を制御する。なお、本実施形態においては、LAN310は図１におけるネットワーク100と同じものである。
【００３１】
図２０は本実施例でデバイス103が所有するユーザインターフェース部分であり、図３のオペレーションパネル309に相当する。313は大型タッチパネルで、ユーザはタッチパネルを操作することで、各種設定を行うことが可能である。図の画面はコピーの待機画面である。314はテンキーボタンで、数字などの値を入力するのに使う。Sのボタンはサービスボタンで、このボタンを押下することにより、タッチパネル上に各種サービス画面が出現し、コピー以外のサービスを行うことができる。Rのボタンは設定ボタンで、このボタンを押下することによって、タッチパネル上に、各種設定画面が出現し、パラメータの設定を行うことができる。
【００３２】
図4は、本発明の実施例におけるサーバ/クライアント端末装置200のソフトウェア構成を示すブロック図である。印刷アプリケーション401は、ユーザの指示操作によって印刷を実行するアプリケーションであり、印刷処理制御部へ印刷データを渡す。印刷処理制御部402は、受信したデータを印刷可能なデータに変換するとともに、印刷部数、両面印刷等の印刷に関する様々な制御を行なう。イベント処理部403は本実施例におけるイベント通知処理を実行するための処理を行なうモジュールであり、イベントの送受信に関する処理を行なう。ネットワークドライバ408は、図2におけるネットワークI/F制御部208を制御し、ネットワーク409とのデータ送受信の制御を行う。TCP/IP制御部407は、TCP/IPプロトコルによるデータの送受信及び制御を行なう。HTTPクライアントは、HTTPプロトコルのクライアント機能を有しており、上位アプリケーションの指示によりHTTPリクエストパケットを印刷デバイスに返信するとともに、印刷デバイスから送信された、HTTPレスポンスパケットを解析して、データをSOAP制御部404、サービス検索処理部403や印刷処理制御部402等の上位アプリケーションにわたす処理を行なう。SOAP制御部404はSOAP(Simple Object Access Protocol)と呼ばれるプロトコルを制御するモジュールであり、端末装置から受信したXML（eXtensible Markup LANguage）形式のデータをXMLパーサ405を使用して解析し、印刷処理制御部402の適切なモジュールを呼び出したり、イベント処理部403へ印刷デバイスから送信されるイベントのデータを渡すと同時に、印刷デバイスに返すべきデータをXMLデータに変換し、HTTPサーバ制御部506を介して印刷デバイスに返信する制御を行なう。XMLパーサ505はXML形式データを入力とし解析結果を出力するモジュールである。
【００３３】
図５は、本発明の実施例における印刷デバイス300のソフトウェア構成を示すブロック図である。プリンタ制御部501は、図３におけるプリンタI/F制御部305を制御して、図３におけるプリンタ306へのデータ送信、排紙制御などを行う。印刷処理制御部502は、受信したデータを印刷可能なデータに変換するとともに、印刷部数、両面印刷等の印刷に関する様々な制御を行なう。イベント処理部503は本実施例におけるイベント通知を実行するための処理を行なうモジュールであり、イベントに関する処理を行なう。ネットワークドライバ508は、図3におけるネットワークI/F制御部311を制御し、ネットワーク509とのデータ送受信の制御を行う。TCP/IP制御部507は、TCP/IPプロトコルによるデータの送受信及び制御を行なう。HTTPサーバは、HTTPプロトコルのサーバ機能を有しており、端末装置から受信したHTTPリクエストパケットを解析して、データをSOAP制御部504、サービス検索処理部503や印刷処理制御部502等の上位アプリケーションにわたすと共に、上位アプリケーションの指示によりHTTPレスポンスパケットを端末装置に返信する制御を行なう。SOAP制御部504はSOAP(Simple Object Access Protocol)と呼ばれるプロトコルを制御するモジュールであり、端末装置から受信したXML（eXtensible Markup LANguage）形式のデータをXMLパーサ505を使用して解析し、印刷処理制御部502の適切なモジュールを呼び出したり、イベント処理部503へ端末装置から送信されるイベントのデータを渡すと同時に、端末装置に返すべきデータをXMLデータに変換し、HTTPサーバ制御部506を介して端末装置に返信する制御を行なう。XMLパーサ505はXML形式データを入力とし解析結果を出力するモジュールである。
【００３４】
以下に本実施例における、クライアント端末装置から印刷デバイスであるMFPによって印刷を行う場合の印刷デバイスの動作について述べる。
【００３５】
図６は、本実施例におけるHTTP上のSOAPを用いてクライアント端末装置から印刷デバイスに送信されるCreateJobと称されるパケットデータの一例である。このデータはXML形式で記述されている。CreateJobパケットは、印刷デバイスに対し、ジョブ（印刷）の開始を指示するコマンドであり、要求元のユーザ名(<requesting-user-name>タグ)やジョブの処理に関する指示(<job-instruction>タグ)等の情報が記述されている。<job-instruction>タグには印刷部数を設定する<copies>タグ、両面印刷を設定する<sides>タグ、印刷の仕上げを設定する<finishing>タグなどが含まれ、印刷デバイスはこれらのタグに設定された値に基づき、ジョブの処理を行う。さらに、<job-instruction>タグにはオプションとして<notification-instruction>タグを含めることも可能である。この<notification-instruction>タグにはジョブに関する通知情報が記述される。図６の例においては通知情報として、通知先を設定する<notification-recipient>タグおよび通知条件を設定する<event>タグが記述されている。印刷デバイスはこれらのタグに設定された値に基づいてイベント送信処理を行う。
【００３６】
図７は、図６のCreateJobパケットに対する応答パケットデータの一例である。本データも図６と同様にXML形式で記述され、本実施例においてはHTTP上のSOAPを用いて送受信される。CreateJob応答パケットには、CreateJobコマンド対する結果コード(<result-code>タグ)や生成されたジョブの識別子(<job-id>タグ)、印刷用ポートのURI(<data-sink-uri>タグ)等の情報が含まれている。
【００３７】
図８は、クライアント端末装置が印刷を行う場合における本実施例の印刷デバイスの動作を示すフローチャートである。
【００３８】
以下、図８を用いて、本実施例の印刷デバイスの動作を説明する。
【００３９】
ホストコンピュータから例えば図６に示したようなCreateJobパケットが印刷デバイスに送信されると、印刷デバイスはS801において、CreateJobに記述されたXMLデータを解析し、S802に進み解析結果にエラーがないか判定する。エラーがなければ、S803において印刷データ受信用の印刷ポートを生成する。S803の処理が終わるとS804へ進み、CreateJobパケットに対するレスポンスのXMLデータの生成を行なう。このときに印刷データ受信用に生成したポートのURIを<data-sink-uri>タグの値として設定する。例えば、図５の例のようなURIがXMLデータに埋め込まれる。CreateJobレスポンスデータの生成が終了するとS805へ進み、そのデータをSOAPを用いてホストコンピュータに送信する。ホストコンピュータは、その後、<data-sink-uri>タグで指定されたURIに対してHTTPのPOSTメソッドを用いて印刷データを送信する。図９はHTTP POSTメソッドによる印刷データ転送パケットの一例である。印刷デバイスはS806において印刷ポートに到着したデータを受信し、適切な処理をしながらプリンタに印刷する。S806において、印刷データの受信が正常に終了すると印刷デバイスはS807において図１０に示した例のようなHTTPレスポンスパケットをホストコンピュータに送信し、印刷用ポートを削除（クローズ）して印刷動作を終了する。一方、S802においてCreateJobに記述されたXMLデータにエラーがあると判定された場合はS808へ進み、エラーレスポンスデータを生成する。図１1はエラーレスポンスの例である。次にS805においてエラーレスポンスをホストコンピュータに送信すると、ホストコンピュータは印刷データを送信することはせず、処理を終了する。
【００４０】
次に、上記の本実施例における印刷サービスを提供する印刷デバイスの状態変化によるサーバ端末装置へのイベント通知手段、イベント失敗リスト登録手段、およびイベント発行宛先の登録削除手段について述べる。
【００４１】
図１２は印刷デバイスがイベント通知を行う場合における本実施形態の印刷デバイスの動作を示すフローチャートである。
【００４２】
以下、図１２を用いて、本実施形態の印刷デバイスの動作を説明する。
【００４３】
本実施形態における印刷デバイスは図1に示す印刷デバイス103であり、サーバ装置は図1に示すサーバ装置101、クライアント端末は図1に示すクライアント端末102である。
【００４４】
印刷デバイスは図８に示した印刷処理での印刷ジョブのステータス変化や、紙ジャム、紙/トナー切れなどのエラーによる印刷デバイスの状態変化があった場合には、その状態変化をイベント発行によってサーバ装置あるいはクライアント端末に通知する。
【００４５】
特に、紙/トナー切れなどのエラーによる印刷デバイスの状態変化があった場合には、図１３に示すような、あらかじめイベント発行先のホストに関する情報が登録されているイベント発行宛先リストを保持しておき、そのリストに登録されているホストに対してイベントを発行する。このリストへの登録は、図３に示したオペレーションパネル等からユーザによって宛先が入力され、登録される。
【００４６】
一方、リストからの削除についても同様にオペレーションパネル等からユーザによって削除可能である。
【００４７】
本実施例では、イベントを発行するホストに関する情報としてIPアドレスをイベント発行宛先リスト記載してあるが、その他、MACアドレス、FQDN名などホストを識別できる情報であれば、どのような情報でもよい。
【００４８】
印刷デバイスは前記したような、イベント発行の必要があった場合には、イベント発行宛先リストに登録されているホストに対してイベント発行する前に、ステップS1201において、そのホストが、図１４に示したようなイベント送信失敗宛先リストに登録されているか否かを判断する。イベント送信失敗リストには、以前にイベント発行に失敗したホストに関する情報と、失敗したカウント数、およびイベント送信に失敗した時刻情報が記載されている。本実施例では、前記ホストに関する情報としてIPアドレスをイベント通知リスト記載してあるが、その他、MACアドレス、FQDN名などホストを識別できる情報であれば、どのような情報でもよい。
【００４９】
また、本実施例では、イベント発行宛先リストとイベント送信失敗宛先リストの２つのリストを保持しているが、イベント発行宛先リストに、送信に失敗したカウント数、およびイベント送信に失敗した時刻情報などを記載することによって、イベント送信失敗宛先リストを保持しない構成をとっても良い。
【００５０】
（すなわちイベント発行宛先リスト＝イベント送信失敗宛先リスト）
イベント送信失敗リストにそのホストが登録されていない場合には、次のステップへ進み、ステップS1205において図1５に示したようなイベントパケットデータを生成し、ステップS1206においてイベントパケットデータを送信することで、イベントを発行する。
【００５１】
イベント発行先であるサーバ装置やクライアント装置のホストが、イベント受信可能であった場合には、図１６に示したようなイベントの応答パケットデータが返信されるので、ステップS1207においてステップS1206で発行したイベントの応答が返信されたかを確認することで、イベントの発行に成功したか否かの判断を行い、成功した場合には処理を終了する。
【００５２】
本実施例におけるイベント発行が成功したか否かの判断は、TCPプロトコルなどのコネクション型の通信によって、イベント発行先ホストであるサーバ装置との通信コネクションを確立し、その確立したコネクションにおいて、発行したイベントに対する応答があるか否かで判断を行なっているが、通信コネクションそのものが確立できなかったり、イベント応答としてイベントを受信できなかった旨のエラーなどが返却された場合や、応答待ちのタイムアウトが発生した場合も、イベント発行が失敗したと判断しても良い。
【００５３】
また、イベント発行に関する通信は、UDPプロトコルなどのコネクションレス型の通信であってもよく、イベントデータの送信後、同プロトコルで発行したイベントに対する応答を受け取ることで、イベント発行が成功したか否かを判断しても良い。
【００５４】
従って、コネクション型の通信と同様に、イベント送信後にイベント送信先ホストから送信されるイベントに対する応答として、イベント受信にエラーが発生した旨の応答を返したときや、イベントに対する応答が一定時間の間に返却されなかったときに、イベント受信ができなかったときには、イベント発行が失敗したと判断しても良い。
【００５５】
ステップS1207においてイベントの送信に失敗したと判断した場合には、ステップS1208において、そのホストがイベント送信失敗リストに登録されているか否かの判断を行い、イベント送信失敗リストに登録されていない場合には、ステップS1209においてイベント送信失敗宛先リストにそのホストを登録するとともに、ステップS1210においてイベント送信失敗宛先リスト内の、イベント送信失敗カウントを増やし、さらにその時刻情報を登録して処理を終了する。
【００５６】
本実施例では、ステップS1207においてイベント送信に失敗した何れの場合も、イベント送信失敗リストに登録する、あるいはイベント送信失敗カウントを増やす構成をとっている。
【００５７】
しかし、たとえば「通信のタイムアウトが発生した場合には、イベント送信失敗リストに登録しない、あるいはイベント送信失敗カウントを増さない」など、イベント発行の際のエラーの内容によって、イベント送信失敗リストへの登録やイベント送信失敗カウントを増やすか否かを判断しても良い。
【００５８】
また、本実施例では何れのイベントにおいてもイベント送信失敗リストに登録する、あるいはイベント送信失敗カウントを増やす構成をとっている。
【００５９】
しかし、イベント送信に失敗したとき、たとえばイベントの内容が
「印刷終了通知」である場合には、イベント送信失敗リストに登録する、あるいはイベント送信失敗カウントを増やす。
【００６０】
「印刷デバイスの設定変更」である場合には、イベント送信失敗リストに登録しない、あるいはイベント送信失敗カウントを増やさない。
【００６１】
など、イベントの内容によって、イベント送信失敗リストへの登録やイベント送信失敗カウントを増やすか否かを判断しても良い。
【００６２】
ステップS1208において、イベント送信失敗リストに登録されている場合には、ステップS1209をスキップし、ステップS1210においてイベント送信失敗宛先リスト内の、イベント送信失敗カウントをインクリメントし、さらにその時刻情報を更新して処理を終了する。
【００６３】
本実施例では、ステップS1207においてイベントの送信に失敗したと判断したイベント送信先ホストが既にイベント送信失敗宛先リストに登録されている場合には、毎回、イベント送信失敗宛先リストの時刻情報を更新しているが、初回にイベント送信に失敗した時刻のみを登録するような構成をとっても良い。
【００６４】
また、ステップS1201において、イベント送信失敗宛先リストに、イベントを送信するホストが登録されている場合には、ステップS1202へ進み、ステップS1202において、イベント送信失敗リストのそのホストのイベント送信失敗カウントの値が、あらかじめ設定してある上限数を超えているか否かの判断を行なう。カウント数が上限を超えていない場合には、ステップS1205へ進み、前記したステップS1205からステップS1210までの処理を行なう。
【００６５】
ステップS1202において、カウント数が上限を超えていない場合には、ステップS1203へ進む。
【００６６】
この場合、イベント送信を行なわずに処理を終了する。
【００６７】
本実施例では、印刷デバイスは、図３のオペレーションパネルからユーザによって、イベント送信失敗のカウント数が一定の値を超えた場合に『イベント発行宛先からホストを削除する』という設定を行なうことができる。ステップS1203において、この設定がされているか否かの判断を行ない、削除の設定がされている場合にはステップS1204において、イベント発行宛先リストからこのホストを削除し、処理を終了する。
【００６８】
本実施例では、イベント送信失敗リストのイベント送信失敗カウントの値が一定の上限値を超えてしまったホストに対しては、イベント送信を行なわない構成をとっているが、
たとえば、上限値を５回と設定されている場合には、さらに失敗した数をカウントし
６回目 ← イベントを送信する
７回目 ← イベントを送信しない
８回目 ← イベントを送信する
９回目 ← イベントを送信しない
……
などのように一定回数の間隔をあけて、イベント送信を行なったり、
５+１回目 ← イベントを送信する
５+２回目 ← イベントを送信する
５+４回目 ← イベントを送信する
５+８回目 ← イベントを送信する
……
などのように一定倍数の回数ごとにイベント送信を行なうなど、イベントの発行間隔を変更するような構成をとっても良い。
【００６９】
さらに、イベントの内容を解析し、その内容に応じてイベント送信を行なわない構成をとっても良い。
【００７０】
また、イベント発行先ホストのイベント発行宛先リスト登録時に、一定の上限値を超えた場合においても、イベント発行宛先リストからの削除を抑止するような設定をオペレーションパネルから行なうことで、リストからの削除しないようにする構成をとっても良い。
【００７１】
本実施例では、前記した図１２のステップS1202からS1203の処理によって、イベント送信失敗リストに登録されているホストに対して、リスト内の時刻情報を元に、イベント送信に失敗してから一定時間経過している場合には、ホスト存在確認を行なうイベントを発行し、そのホストがイベント受信可能であるかの検証を定期的に行ない、そのホストがイベント受信可能であった場合には、イベント送信失敗リストから削除する。
【００７２】
また、イベント送信失敗リストに登録されているホストが、ステップS1204の処理によって、イベント発行宛先リストから削除されてしまっていた場合に、ホスト存在確認ができた場合には、そのホストをイベント発行宛先リストへ再登録を行なう。
【００７３】
図１５は、本実施例におけるHTTP上のSOAPを用いて印刷デバイスからサーバ装置あるいはクライアント端末に送信されるイベントパケットデータの一例である。このデータは図１２のステップS1205で作成されるイベントパケットデータでありXML形式で記述されている。イベントパケットには、Notifyメソッドが用いられる。イベントパケットはサーバ装置あるいはクライアント端末に対し、ジョブ（印刷）または印刷デバイスの状態変化を通知するコマンドであり、イベントの内容(<trigger-event>タグ)やイベント発生時刻(<trigger-time >タグ)、イベントのID情報（< notification-id >タグ）等の情報が記述されている。本実施例でのイベントパケットデータには、ジョブの状態を通知するイベントの例(図１５-A)とデバイスの状態を通知するイベントの例(図１５-B)を記述している。ジョブの状態をイベント通知する場合には、 <trigger-event>タグ内にジョブの終了（" job-completed"）やジョブのキャンセル（"job-canceled" ）等のジョブのステータスを表す文字列が記述される。
【００７４】
また、デバイスの状態をイベント通知する場合には、 <trigger-event>タグ内にデバイスの状態変化を表す文字列“device-state-changed”が記述され、さらに<device-status>タグ内にデバイスの状態を表す文字列（"stop" etc。）と、<device-state-reason>タグ内にデバイスの状態変化の理由（紙ジャムやトナー残量が少ない）などを表す文字列（"paper-jam"、 "toner-low"）が記述される。
【００７５】
図１６は、図１５のイベントパケットに対する応答パケットデータの一例である。本データも図１６と同様にXML形式で記述され、本実施例においてはHTTP上のSOAPを用いて送受信される。イベント応答パケットにはNotifyResponseメソッドが用いられ、イベントパケットのNotifyコマンド対する結果コード(<result-code>タグ)が含まれている。正常にイベントを受信した場合には(<result-code>タグ内に"ok"が記述される。
【００７６】
図１７は印刷デバイスがイベント送信失敗リストに登録されているホストの存在確認を行なう動作と、イベント送信失敗リストに登録されているイベント発行宛先リストから削除されたホストをイベント発行宛先リストへ再登録する場合における、本実施形態の印刷デバイスの動作を示すフローチャートである。
【００７７】
以下、図１７を用いて、本実施形態の印刷デバイスの動作を説明する。
【００７８】
本実施形態における印刷デバイスは図1に示す印刷デバイス103であり、サーバ装置は図1に示すサーバ装置101、クライアント端末は図1に示すクライアント端末102である。
【００７９】
印刷デバイスは、一定時間間隔で図１７に示した以下のステップの処理を定期的に行なう。この処理を実行するか否かの設定は図３に示したオペレーションパネルからユーザによって設定することが可能である。また、その時間間隔もユーザか指定・設定することが可能である。
【００８０】
また、何れの時間が経過している場合にもデバイスのオペレーションパネルなどから手動で、上記の処理を実行させてもよい。
【００８１】
まず、印刷デバイスはステップS1701において、イベント送信失敗宛先リストからイベント送信に失敗したホストの情報を取得する。
【００８２】
次に、ステップS1702においてステップS1701でのホスト情報の取得に成功したか否かの判断を行い、成功した場合には次のステップに進む。ホスト情報の取得に失敗あるいは、イベント送信失敗宛先リストにホストの情報がない場合には、処理を終了する。
【００８３】
次にステップS1703において、ステップS1701において取得したイベント受信の確認対処となるホストがイベント受信に失敗した時刻が現在時刻から一定時間経過しているか否かの判断を行なう。
【００８４】
ステップS1703においてそのホストがイベント受信に失敗した時刻から、前記した設定時刻よりも時間が経過している場合には、次のステップへ進む。また、設定時刻よりも時間が経過していない場合には、ステップS1701に戻り、次のホスト情報を取得し、前記した同様の処理を行なう。
【００８５】
S1704において、図１８に示したようなホストの存在確認を行なうイベント発行のためのイベントパケットデータを作成し、S1705においてホストの存在確認イベントの発行送信処理を行なう。
【００８６】
存在確認イベント発行先であるサーバ装置やクライアント装置のホストが、イベント受信可能であった場合には、図１９に示したようなイベントの応答パケットデータが返信されるので、ステップS1706において、ステップS1705で発行したイベントの応答が返信されたかを確認することで、イベントの発行に成功したか否かの判断を行い、成功した場合には次のステップへ進む。また、イベント送信に失敗した場合には、S1710において、イベント送信失敗宛先リストの時刻情報を更新し、ステップS1701に戻り、次のホスト情報を取得し、前記した同様の処理を行なう。
【００８７】
上記のイベント発行が成功したか否かの判断は、図１２を用いて説明したイベント発行における判断と同様である。
【００８８】
ステップS1706において送信先ホストが存在確認イベントの受信に成功し、レスポンスパケットデータを受信した場合には、送信ホストがイベントの受信が可能であると判断されるので、ステップS1708においてイベント送信失敗リストから削除する。さらに次のステップS1709においてイベント送信失敗リストから削除したホストが、イベント発行宛先リストに登録されているか否かを判断する。登録されていない場合には、図１２に示したステップS1204において既にイベント発行宛先リストから削除されていることになるので、ステップS1709において、そのホストをイベント発行宛先リストにホストの情報を再登録する。
【００８９】
ステップS1708においてイベント送信失敗リストから削除したホストが、イベント発行宛先リストに登録されている場合には、処理を行なわずに、ステップS1701に戻り、次のホスト情報を取得し、前記した同様の処理を行なう。
【００９０】
本実施例では、イベント送信失敗宛先リストに登録されているホストが、存在確認イベントの発行によって、イベントの受信が可能であると判断された場合には、いずれの場合も、イベント送信失敗宛先リストからの削除、または、イベント発行宛先リストへの再登録を行なっているが、存在確認イベントの発行によって、ホストがイベントの受信が可能であると判断された場合には、イベント送信失敗宛先リストのイベント送信失敗カウントを減らしてしていき、最終的にカウントが０になったらイベント送信失敗リストからの削除や、イベント発行宛先リストにホストの情報を再登録するような構成をとってもよい。
【００９１】
S1709までの処理が終了したら、ステップS1701に戻り、次のホスト情報を取得し、前記した同様の処理を行なう。
【００９２】
イベント送信失敗宛先リスト内に登録されている全てのホストに対して、上記のステップを実行したら処理を終了する。
【００９３】
本実施例においてイベント送信失敗宛先リスト内に登録されているホストの情報は、図３に示したオペレーションパネル等に表示可能であって、ユーザによってホストの宛先をリストから削除することも可能である。
【００９４】
なお、本実施例においては、ダミーイベントを送信することによりホストの存在を確認していたが、例えば、Pingコマンドなどを使用しIPレベルでホストの存在を確認する構成とすることも可能である。送信先ホストの存在やイベント発行が可能であることが確認できれば何れの通信プロトコルを使用してもかまわない。
【００９５】
図１８は、本実施例におけるHTTP上のSOAPを用いて印刷デバイスからサーバ装置あるいはクライアント端末に送信されるホストの存在確認イベントのパケットデータの一例である。このデータは図１７のステップS1705で作成されるイベントパケットデータであり、XML形式で記述されている。イベントパケットには、Notifyメソッドが用いられる。イベントパケットはサーバ装置あるいはクライアント端末に対し、ジョブ（印刷）または印刷デバイスの状態変化を通知するコマンドであり、イベントの内容(<trigger-event>タグ)やイベント発生時刻(<trigger-time >タグ)、イベントのID情報（< notification-id >タグ）等の情報が記述されている。本実施例におけるイベントパケットデータには、イベントの内容を表す<trigger-event>タグ内に、ホストが存在するか否か、またはイベントを受信可能であるか否かの確認を行なうためのダミーイベントを表す"dummy-event"が記述される。
【００９６】
図１９は、図１８のイベントパケットに対する応答パケットデータの一例である。本データも図１６と同様にXML形式で記述され、本実施例においてはHTTP上のSOAPを用いて送受信される。イベント応答パケットはNotifyResponseメソッドが用いられ、イベントパケットのNotifyコマンド対する結果コードのみ(<result-code>タグ)が含まれている。正常にイベントを受信した場合には(<result-code>タグ内に"ok"が記述される。
【図面の簡単な説明】
【００９７】
【図１】本実施例におけるサービス検索・印刷システムの構成図
【図２】端末装置のハードウェア構成ブロック図
【図３】印刷デバイスのハードウェア構成ブロック図
【図４】端末装置のソフトウェア構成ブロック図
【図５】印刷デバイスのソフトウェア構成ブロック図
【図６】印刷デバイスに送信されるCreateJobパケットデータの一例
【図７】CreateJobパケットに対する応答パケットデータの一例
【図８】印刷実行時の印刷デバイスの動作を示すフローチャート
【図９】HTTP POSTメソッドによる印刷データ転送パケットの一例
【図１０】印刷終了時に印刷デバイスが送信するHTTPのレスポンスパケットの例
【図１１】CreateJobパケットエラーのレスポンスの例
【図１２】イベント通知を行う場合における印刷デバイスの動作を示すフローチャート
【図１３】イベント発行宛先リストの一例
【図１４】イベント送信失敗宛先リストの一例
【図１５】イベントパケットデータの一例
【図１６】イベント応答パケットデータの一例
【図１７】イベント発行宛先リストへ再登録する場合の印刷デバイスの動作を示すフローチャート
【図１８】存在確認イベントパケットデータの一例
【図１９】存在確認イベント応答パケットデータの一例
【図２０】印刷デバイスが所有するユーザインターフェース部
【特許請求の範囲】
【請求項１】
少なくとも１つ以上のネットワークサービスを利用・提供可能であり、そのサービスに関連するイベント発行および送受信が可能な印刷デバイスにおいて、前記印刷デバイスはイベント発行・通知手段を有し、
前記印刷デバイスは、イベント発行対象となるイベント送信先ホストの宛先情報が含まれるイベント発行宛先リストと、
イベント発行に失敗したホストの宛先情報と、イベント発行に失敗した回数を含むイベント送信失敗宛先リストを保持することが可能であって、
前記印刷デバイスは、前記イベント発行宛先リストに、イベント発行対象となるイベント送信先ホストの宛先情報を登録・削除することが可能であって、
前記印刷デバイスは、前記イベント発行宛先リストに登録されているホストの宛先情報に基づき、イベントを送信しイベント発行することが可能であって、
さらに、前記印刷デバイスから発行したイベントを、イベント送信先ホストが受信できるか否かを判断する手段と、前記判断手段によってイベントを前記イベント送信先ホストが受信できないと判断した場合には、イベント送信失敗宛先リストに、そのホストの宛先情報と受信に失敗した結果を登録する手段を有するイベント発行履歴登録手段を備えることを特徴とする印刷デバイス。
【請求項２】
請求項1に記載の印刷デバイスにおける、イベント発行・通知手段において、
前記印刷デバイスは、イベント発行対象となるイベント送信先ホストの宛先情報が含まれるイベント発行宛先リストと、
イベント発行に失敗したホストの宛先情報と、イベント発行に失敗した回数と、イベント発行に失敗した時刻情報を含むイベント送信失敗宛先リストを保持することが可能であって、
前記印刷デバイスは、前記イベント発行宛先リストに、イベント発行対象となるイベント送信先ホストの宛先情報を登録・削除することが可能であって、
前記印刷デバイスは、前記イベント発行宛先リストに登録されているホストの宛先情報に基づき、イベントを送信しイベント発行することが可能であって、
前記印刷デバイスから発行したイベントを、イベント送信先ホストが受信できるか否かを判断する手段と、前記判断手段によってイベントを前記イベント送信先ホストが受信できないと判断した場合には、イベント送信失敗宛先リストに、そのホストの宛先情報と受信に失敗した結果を時刻情報とともに登録する手段を有するイベント発行履歴登録手段を備えることを特徴とする印刷デバイス。
【請求項３】
請求項1、又は請求項２に記載の印刷デバイスにおけるイベントを受信できるか否かを判断する手段は、イベント発行・通知を行う時のコネクション型の通信において、イベント送信先ホストに対する通信コネクションを確立することができなかったときに、イベント受信ができなかったことを判断する手段を備えることを特徴とする印刷デバイス。
【請求項４】
請求項1、又は請求項２に記載の印刷デバイスにおけるイベントを受信できるか否かを判断する手段は、イベント発行・通知を行う時のコネクション型の通信において、イベント送信先ホストとの通信コネクションを確立し、イベントデータを送信した後に、イベント送信先ホストから、そのイベントデータ受信にエラーが発生した旨の応答を返したときに、イベント受信ができなかったことを判断する手段を備えることを特徴とする印刷デバイス。
【請求項５】
請求項1、又は請求項２に記載の印刷デバイスにおけるイベントを受信できるか否かを判断する手段は、イベント発行・通知を行う時のコネクション型の通信において、イベント送信先ホストとの通信コネクションを確立し、イベントデータを送信した後に、イベント送信先ホストが、一定時間の間に、その送信イベントに対する応答を返さなかったときに、イベント受信ができなかったことを判断する手段を備えることを特徴とする印刷デバイス。
【請求項６】
請求項1、又は請求項２に記載の印刷デバイスにおけるイベントを受信できるか否かを判断する手段は、イベント発行・通知を行う時のコネクションレス型の通信において、イベント送信後にイベント送信先ホストから送信されるイベントに対する応答として、イベント受信にエラーが発生した旨の応答を返したときに、イベント受信ができなかったことを判断する手段を備えることを特徴とする印刷デバイス。
【請求項７】
請求項1、又は請求項２に記載の印刷デバイスにおけるイベントを受信できるか否かを判断する手段は、イベント発行・通知を行う時のコネクションレス型の通信において、イベント送信後にイベント送信先ホストから送信されるイベントに対する応答が一定時間の間に返却されなかったときに、イベント受信ができなかったことを判断する手段を備えることを特徴とする印刷デバイス。
【請求項８】
請求項1、又は請求項２に記載のイベント発行履歴登録手段は、請求項３から７に記載の判断手段によって判断されたイベント送信の結果に応じて、イベント送信失敗宛先リストにイベント送信先のホストを登録するか否かを決定することが可能な手段を備えることを特徴とする印刷デバイス。
【請求項９】
請求項1、又は請求項２に記載のイベント発行履歴登録手段は、イベント送信に失敗した場合に、発行するイベントの内容に応じて、イベント送信失敗宛先リストにイベント送信先のホストを登録するか否かを決定することが可能な手段を備えることを特徴とする印刷デバイス。
【請求項１０】
請求項1、又は請求項２に記載の印刷デバイスにおける、前記イベント発行履歴登録方法において、イベント受信に失敗したホストが前記イベント送信失敗宛先リストにすでに登録されている場合には、前記イベント送信失敗宛先リストのそのホストのイベント受信失敗回数のカウントを増やす手段を有するイベント発行履歴登録手段を備えることを特徴とする印刷デバイス。
【請求項１１】
請求項２に記載の印刷デバイスにおける、前記イベント発行履歴登録方法において、イベント受信に失敗したホストが前記イベント送信失敗宛先リストにすでに登録されている場合には、前記イベント送信失敗宛先リストのそのホストのイベント受信失敗回数のカウントを増やす手段と、そのイベント受信に失敗した時刻情報を更新する手段を有するイベント発行履歴登録手段を備えることを特徴とする印刷デバイス。
【請求項１２】
請求項１０、又は請求項１１に記載のイベント受信失敗回数のカウントを増やす手段は、請求項３から請求項７に記載の判断手段によって判断された結果、またはイベントの内容に応じて、受信失敗回数のカウントを増やすか否かを決定する手段を備えることを特徴とする印刷デバイス。
【請求項１３】
請求項１１に記載のイベント受信に失敗した時刻情報を更新する手段は、請求項３から請求項７に記載の判断手段によって判断された結果、またはイベントの内容に応じて、イベント受信に失敗した時刻情報を更新するか否かを決定することが可能な手段を備えることを特徴とする印刷デバイス。
【請求項１４】
請求項１、又は請求項２に記載のデバイスにおけるイベント発行履歴登録方法によって、登録された前記送信失敗宛先リストに登録されており、かつ、あらかじめ設定された、既定のイベント発行宛先に登録されているホストにイベント送信をする場合に、そのホストのイベント送信失敗カウントが設定された回数の制限を越えているかを判断するイベント発行判断手段と、超えた場合には、イベント送信を行なわないイベント発行手段を備えることを特徴とする印刷デバイス。
【請求項１５】
請求項１、又は請求項２に記載のデバイスにおけるイベント発行履歴登録方法によって、登録された前記送信失敗宛先リストに登録されており、かつ、あらかじめ設定された、既定のイベント発行宛先に登録されているホストにイベント送信をする場合に、そのホストのイベント送信失敗カウントが設定された回数の制限を越えているかを判断する請求項１４に記載のイベント発行判断手段と、設定された回数を超えた場合には、イベント送信を行なうタイミングを毎回ではなく、一定回数の間隔をあけて送信するように変更するイベント発行手段を備えることを特徴とする印刷デバイス。
【請求項１６】
請求項１、又は請求項２に記載のデバイスにおけるイベント発行履歴登録方法によって、登録された前記送信失敗宛先リストに登録されており、かつ、あらかじめ設定された、既定のイベント発行宛先に登録されているホストにイベント送信をする場合に、そのホストのイベント送信失敗カウントが設定された回数の制限を越えているかを判断する請求項１４に記載のイベント発行判断手段と、設定された回数を超えた場合には、イベント送信を行なうタイミングを毎回ではなく、予め定めた数の倍数ごと間隔をあけてイベント送信するように変更するイベント発行手段を備えることを特徴とする印刷デバイス。
【請求項１７】
請求項１、又は請求項２に記載のデバイスにおけるイベント発行履歴登録方法によって、登録された前記送信失敗宛先リストに登録されており、かつ、あらかじめ設定された、既定のイベント発行宛先に登録されているホストにイベント送信をする場合に、そのホストのイベント送信失敗カウントが設定された回数の制限を越えているかを判断するイベント発行判断手段と、超えた場合には、送信するイベントの内容に応じてイベント送信を行なわないイベント発行手段を備えることを特徴とする印刷デバイス。
【請求項１８】
請求項１、又は請求項２に記載のデバイスにおけるイベント発行履歴登録方法によって、登録された前記送信失敗宛先リストに登録されており、かつ、あらかじめ設定された、既定のイベント発行宛先に登録されているホストにイベント送信をする場合に、請求項１４に記載のイベント発行判断手段によって送信を行なわないと判断された場合には、前記既定のイベント発行宛先からそのホストの登録を削除するイベント発行宛先削除手段を備えることを特徴とする印刷デバイス。
【請求項１９】
規定のイベント発行宛先に登録されているホストに対して、イベント送信に失敗し、送信失敗宛先リストに登録されたばあいにも、請求項１８に記載のイベント発行宛先削除方法による宛先削除を行なうことを抑止することが可能な、イベント発行宛先削除抑止手段を備えることを特徴とする印刷デバイス。
【請求項２０】
請求項１、又は請求項２に記載のデバイスにおけるイベント発行履歴登録方法によって、前記送信失敗宛先リストに登録されたホストに、イベントの送信に失敗してから一定時間経過した後、そのホストに対してホストの存在確認をおこなうイベントを発行または、通信を行ない、イベント発行が可能か否かをチェックするイベント発行可否のチェック手段と、前記チェック手段によってイベント発行が可能であると判断した場合には、イベント送信失敗宛先リストからそのホストを削除するイベント送信失敗宛先リストからの削除手段と、
さらに、イベント送信失敗宛先リストに登録されているホストが、請求項１８に記載のイベント発行宛先削除手段によって、規定のイベント発行宛先リストから削除されていた場合に、前記チェック手段によってイベント送信に成功した場合には、イベント送信失敗宛先リストからそのホストを削除するとともに、再びイベント発行を行なうことができるように規定のイベント発行宛先リストへ再登録するイベント発行宛先再登録手段を備えることを特徴とする印刷デバイス。
【請求項２１】
請求項１、又は請求項２に記載のデバイスにおけるイベント発行履歴登録方法によって、前記送信失敗宛先リストに登録されたホストに対して手動でホストの存在確認をおこなうイベントを発行または、通信を行ない、イベント発行が可能か否かをチェックするイベント発行可否のチェック手段と、前記チェック手段によってイベント発行が可能であると判断した場合には、イベント送信失敗宛先リストからそのホストを削除するイベント送信失敗宛先リストからの削除手段と、
さらに、イベント送信失敗宛先リストに登録されているホストが、請求項１８に記載のイベント発行宛先削除手段によって、規定のイベント発行宛先リストから削除されていた場合に、前記チェック手段によってイベント送信に成功した場合には、イベント送信失敗宛先リストからそのホストを削除するとともに、再びイベント発行を行なうことができるように規定のイベント発行宛先リストへ再登録するイベント発行宛先再登録手段を備えることを特徴とする印刷デバイス。
【請求項２２】
請求項１、又は請求項２に記載のデバイスにおけるイベント発行履歴登録方法によって、前記送信失敗宛先リストに登録されたホストに、イベントの送信に失敗してから一定時間経過した場合や、あるいは手動で、そのホストに対して存在確認をおこなうイベントを発行または、通信を行ない、イベント発行が可能か否かをチェックするイベント発行可否のチェック手段と、前記チェック手段によってイベント発行が可能であると判断した場合には、イベント送信失敗宛先リストのカウントを減らす手段と、カウント情報が0になったら、イベント送信失敗宛先リストからそのホストを削除するイベント送信失敗宛先リストからの削除手段と、
さらに、イベント送信失敗宛先リストに登録されているホストが、請求項１８に記載のイベント発行宛先削除手段によって、規定のイベント発行宛先リストから削除されていた場合に、前記チェック手段によってイベント送信に成功した場合には、イベント送信失敗宛先リストのカウントを減らす手段と、カウント情報が0になったら、イベント送信失敗宛先リストからそのホストを削除するとともに、再びイベント発行を行なうことができるように規定のイベント発行宛先リストへ再登録するイベント発行宛先再登録手段を備えることを特徴とする印刷デバイス。
【請求項１】
少なくとも１つ以上のネットワークサービスを利用・提供可能であり、そのサービスに関連するイベント発行および送受信が可能な印刷デバイスにおいて、前記印刷デバイスはイベント発行・通知手段を有し、
前記印刷デバイスは、イベント発行対象となるイベント送信先ホストの宛先情報が含まれるイベント発行宛先リストと、
イベント発行に失敗したホストの宛先情報と、イベント発行に失敗した回数を含むイベント送信失敗宛先リストを保持することが可能であって、
前記印刷デバイスは、前記イベント発行宛先リストに、イベント発行対象となるイベント送信先ホストの宛先情報を登録・削除することが可能であって、
前記印刷デバイスは、前記イベント発行宛先リストに登録されているホストの宛先情報に基づき、イベントを送信しイベント発行することが可能であって、
さらに、前記印刷デバイスから発行したイベントを、イベント送信先ホストが受信できるか否かを判断する手段と、前記判断手段によってイベントを前記イベント送信先ホストが受信できないと判断した場合には、イベント送信失敗宛先リストに、そのホストの宛先情報と受信に失敗した結果を登録する手段を有するイベント発行履歴登録手段を備えることを特徴とする印刷デバイス。
【請求項２】
請求項1に記載の印刷デバイスにおける、イベント発行・通知手段において、
前記印刷デバイスは、イベント発行対象となるイベント送信先ホストの宛先情報が含まれるイベント発行宛先リストと、
イベント発行に失敗したホストの宛先情報と、イベント発行に失敗した回数と、イベント発行に失敗した時刻情報を含むイベント送信失敗宛先リストを保持することが可能であって、
前記印刷デバイスは、前記イベント発行宛先リストに、イベント発行対象となるイベント送信先ホストの宛先情報を登録・削除することが可能であって、
前記印刷デバイスは、前記イベント発行宛先リストに登録されているホストの宛先情報に基づき、イベントを送信しイベント発行することが可能であって、
前記印刷デバイスから発行したイベントを、イベント送信先ホストが受信できるか否かを判断する手段と、前記判断手段によってイベントを前記イベント送信先ホストが受信できないと判断した場合には、イベント送信失敗宛先リストに、そのホストの宛先情報と受信に失敗した結果を時刻情報とともに登録する手段を有するイベント発行履歴登録手段を備えることを特徴とする印刷デバイス。
【請求項３】
請求項1、又は請求項２に記載の印刷デバイスにおけるイベントを受信できるか否かを判断する手段は、イベント発行・通知を行う時のコネクション型の通信において、イベント送信先ホストに対する通信コネクションを確立することができなかったときに、イベント受信ができなかったことを判断する手段を備えることを特徴とする印刷デバイス。
【請求項４】
請求項1、又は請求項２に記載の印刷デバイスにおけるイベントを受信できるか否かを判断する手段は、イベント発行・通知を行う時のコネクション型の通信において、イベント送信先ホストとの通信コネクションを確立し、イベントデータを送信した後に、イベント送信先ホストから、そのイベントデータ受信にエラーが発生した旨の応答を返したときに、イベント受信ができなかったことを判断する手段を備えることを特徴とする印刷デバイス。
【請求項５】
請求項1、又は請求項２に記載の印刷デバイスにおけるイベントを受信できるか否かを判断する手段は、イベント発行・通知を行う時のコネクション型の通信において、イベント送信先ホストとの通信コネクションを確立し、イベントデータを送信した後に、イベント送信先ホストが、一定時間の間に、その送信イベントに対する応答を返さなかったときに、イベント受信ができなかったことを判断する手段を備えることを特徴とする印刷デバイス。
【請求項６】
請求項1、又は請求項２に記載の印刷デバイスにおけるイベントを受信できるか否かを判断する手段は、イベント発行・通知を行う時のコネクションレス型の通信において、イベント送信後にイベント送信先ホストから送信されるイベントに対する応答として、イベント受信にエラーが発生した旨の応答を返したときに、イベント受信ができなかったことを判断する手段を備えることを特徴とする印刷デバイス。
【請求項７】
請求項1、又は請求項２に記載の印刷デバイスにおけるイベントを受信できるか否かを判断する手段は、イベント発行・通知を行う時のコネクションレス型の通信において、イベント送信後にイベント送信先ホストから送信されるイベントに対する応答が一定時間の間に返却されなかったときに、イベント受信ができなかったことを判断する手段を備えることを特徴とする印刷デバイス。
【請求項８】
請求項1、又は請求項２に記載のイベント発行履歴登録手段は、請求項３から７に記載の判断手段によって判断されたイベント送信の結果に応じて、イベント送信失敗宛先リストにイベント送信先のホストを登録するか否かを決定することが可能な手段を備えることを特徴とする印刷デバイス。
【請求項９】
請求項1、又は請求項２に記載のイベント発行履歴登録手段は、イベント送信に失敗した場合に、発行するイベントの内容に応じて、イベント送信失敗宛先リストにイベント送信先のホストを登録するか否かを決定することが可能な手段を備えることを特徴とする印刷デバイス。
【請求項１０】
請求項1、又は請求項２に記載の印刷デバイスにおける、前記イベント発行履歴登録方法において、イベント受信に失敗したホストが前記イベント送信失敗宛先リストにすでに登録されている場合には、前記イベント送信失敗宛先リストのそのホストのイベント受信失敗回数のカウントを増やす手段を有するイベント発行履歴登録手段を備えることを特徴とする印刷デバイス。
【請求項１１】
請求項２に記載の印刷デバイスにおける、前記イベント発行履歴登録方法において、イベント受信に失敗したホストが前記イベント送信失敗宛先リストにすでに登録されている場合には、前記イベント送信失敗宛先リストのそのホストのイベント受信失敗回数のカウントを増やす手段と、そのイベント受信に失敗した時刻情報を更新する手段を有するイベント発行履歴登録手段を備えることを特徴とする印刷デバイス。
【請求項１２】
請求項１０、又は請求項１１に記載のイベント受信失敗回数のカウントを増やす手段は、請求項３から請求項７に記載の判断手段によって判断された結果、またはイベントの内容に応じて、受信失敗回数のカウントを増やすか否かを決定する手段を備えることを特徴とする印刷デバイス。
【請求項１３】
請求項１１に記載のイベント受信に失敗した時刻情報を更新する手段は、請求項３から請求項７に記載の判断手段によって判断された結果、またはイベントの内容に応じて、イベント受信に失敗した時刻情報を更新するか否かを決定することが可能な手段を備えることを特徴とする印刷デバイス。
【請求項１４】
請求項１、又は請求項２に記載のデバイスにおけるイベント発行履歴登録方法によって、登録された前記送信失敗宛先リストに登録されており、かつ、あらかじめ設定された、既定のイベント発行宛先に登録されているホストにイベント送信をする場合に、そのホストのイベント送信失敗カウントが設定された回数の制限を越えているかを判断するイベント発行判断手段と、超えた場合には、イベント送信を行なわないイベント発行手段を備えることを特徴とする印刷デバイス。
【請求項１５】
請求項１、又は請求項２に記載のデバイスにおけるイベント発行履歴登録方法によって、登録された前記送信失敗宛先リストに登録されており、かつ、あらかじめ設定された、既定のイベント発行宛先に登録されているホストにイベント送信をする場合に、そのホストのイベント送信失敗カウントが設定された回数の制限を越えているかを判断する請求項１４に記載のイベント発行判断手段と、設定された回数を超えた場合には、イベント送信を行なうタイミングを毎回ではなく、一定回数の間隔をあけて送信するように変更するイベント発行手段を備えることを特徴とする印刷デバイス。
【請求項１６】
請求項１、又は請求項２に記載のデバイスにおけるイベント発行履歴登録方法によって、登録された前記送信失敗宛先リストに登録されており、かつ、あらかじめ設定された、既定のイベント発行宛先に登録されているホストにイベント送信をする場合に、そのホストのイベント送信失敗カウントが設定された回数の制限を越えているかを判断する請求項１４に記載のイベント発行判断手段と、設定された回数を超えた場合には、イベント送信を行なうタイミングを毎回ではなく、予め定めた数の倍数ごと間隔をあけてイベント送信するように変更するイベント発行手段を備えることを特徴とする印刷デバイス。
【請求項１７】
請求項１、又は請求項２に記載のデバイスにおけるイベント発行履歴登録方法によって、登録された前記送信失敗宛先リストに登録されており、かつ、あらかじめ設定された、既定のイベント発行宛先に登録されているホストにイベント送信をする場合に、そのホストのイベント送信失敗カウントが設定された回数の制限を越えているかを判断するイベント発行判断手段と、超えた場合には、送信するイベントの内容に応じてイベント送信を行なわないイベント発行手段を備えることを特徴とする印刷デバイス。
【請求項１８】
請求項１、又は請求項２に記載のデバイスにおけるイベント発行履歴登録方法によって、登録された前記送信失敗宛先リストに登録されており、かつ、あらかじめ設定された、既定のイベント発行宛先に登録されているホストにイベント送信をする場合に、請求項１４に記載のイベント発行判断手段によって送信を行なわないと判断された場合には、前記既定のイベント発行宛先からそのホストの登録を削除するイベント発行宛先削除手段を備えることを特徴とする印刷デバイス。
【請求項１９】
規定のイベント発行宛先に登録されているホストに対して、イベント送信に失敗し、送信失敗宛先リストに登録されたばあいにも、請求項１８に記載のイベント発行宛先削除方法による宛先削除を行なうことを抑止することが可能な、イベント発行宛先削除抑止手段を備えることを特徴とする印刷デバイス。
【請求項２０】
請求項１、又は請求項２に記載のデバイスにおけるイベント発行履歴登録方法によって、前記送信失敗宛先リストに登録されたホストに、イベントの送信に失敗してから一定時間経過した後、そのホストに対してホストの存在確認をおこなうイベントを発行または、通信を行ない、イベント発行が可能か否かをチェックするイベント発行可否のチェック手段と、前記チェック手段によってイベント発行が可能であると判断した場合には、イベント送信失敗宛先リストからそのホストを削除するイベント送信失敗宛先リストからの削除手段と、
さらに、イベント送信失敗宛先リストに登録されているホストが、請求項１８に記載のイベント発行宛先削除手段によって、規定のイベント発行宛先リストから削除されていた場合に、前記チェック手段によってイベント送信に成功した場合には、イベント送信失敗宛先リストからそのホストを削除するとともに、再びイベント発行を行なうことができるように規定のイベント発行宛先リストへ再登録するイベント発行宛先再登録手段を備えることを特徴とする印刷デバイス。
【請求項２１】
請求項１、又は請求項２に記載のデバイスにおけるイベント発行履歴登録方法によって、前記送信失敗宛先リストに登録されたホストに対して手動でホストの存在確認をおこなうイベントを発行または、通信を行ない、イベント発行が可能か否かをチェックするイベント発行可否のチェック手段と、前記チェック手段によってイベント発行が可能であると判断した場合には、イベント送信失敗宛先リストからそのホストを削除するイベント送信失敗宛先リストからの削除手段と、
さらに、イベント送信失敗宛先リストに登録されているホストが、請求項１８に記載のイベント発行宛先削除手段によって、規定のイベント発行宛先リストから削除されていた場合に、前記チェック手段によってイベント送信に成功した場合には、イベント送信失敗宛先リストからそのホストを削除するとともに、再びイベント発行を行なうことができるように規定のイベント発行宛先リストへ再登録するイベント発行宛先再登録手段を備えることを特徴とする印刷デバイス。
【請求項２２】
請求項１、又は請求項２に記載のデバイスにおけるイベント発行履歴登録方法によって、前記送信失敗宛先リストに登録されたホストに、イベントの送信に失敗してから一定時間経過した場合や、あるいは手動で、そのホストに対して存在確認をおこなうイベントを発行または、通信を行ない、イベント発行が可能か否かをチェックするイベント発行可否のチェック手段と、前記チェック手段によってイベント発行が可能であると判断した場合には、イベント送信失敗宛先リストのカウントを減らす手段と、カウント情報が0になったら、イベント送信失敗宛先リストからそのホストを削除するイベント送信失敗宛先リストからの削除手段と、
さらに、イベント送信失敗宛先リストに登録されているホストが、請求項１８に記載のイベント発行宛先削除手段によって、規定のイベント発行宛先リストから削除されていた場合に、前記チェック手段によってイベント送信に成功した場合には、イベント送信失敗宛先リストのカウントを減らす手段と、カウント情報が0になったら、イベント送信失敗宛先リストからそのホストを削除するとともに、再びイベント発行を行なうことができるように規定のイベント発行宛先リストへ再登録するイベント発行宛先再登録手段を備えることを特徴とする印刷デバイス。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【公開番号】特開２００７−２５７４８１（Ｐ２００７−２５７４８１Ａ）
【公開日】平成１９年１０月４日（２００７．１０．４）
【国際特許分類】
【出願番号】特願２００６−８３２０９（Ｐ２００６−８３２０９）
【出願日】平成１８年３月２４日（２００６．３．２４）
【出願人】（０００００１００７）キヤノン株式会社 (59,756)
【Ｆターム（参考）】
【公開日】平成１９年１０月４日（２００７．１０．４）
【国際特許分類】
【出願日】平成１８年３月２４日（２００６．３．２４）
【出願人】（０００００１００７）キヤノン株式会社 (59,756)
【Ｆターム（参考）】
[ Back to top ]