JP5813141B2 - データ処理装置及び方法、並びにプログラム - Google Patents

Description

本発明は、通知先アドレスの登録を要求する登録要求を情報処理装置から受信し、データ処理装置に関する情報を該通知先アドレスに通知するデータ処理装置及び方法、並びにプログラムに関する。

近年、情報処理装置がデータ処理装置に関する情報を当該データ処理装置から受け取る方法として、Ｗｅｂサービスによるイベント方式が提案されている。Ｗｅｂサービスによるイベント方式の概要を説明する。

まず、通知を希望するイベントの内容やイベントを通知する宛先（「イベント通知先」と呼ぶ）等の情報を含むイベント通知先登録要求メッセージ（「イベント登録要求」と呼ぶ）を情報処理装置からデータ処理装置に対してＷｅｂサービスを用いて送信する。次に、イベント登録要求を受け取ったデータ処理装置は、該イベント登録要求に含まれている情報を保存（登録）する。そして、データ処理装置で該当するイベント（エラーやジョブ開始、ジョブ終了等のイベント）が発生した際に、登録されたイベント通知先に対してイベント通知メッセージを送信する。以上がＷｅｂサービスによるイベント方式の概要である。

一方、Ｗｅｂサービスによるイベント方式では、イベント登録要求に含まれるイベント通知先として、登録要求を送信した情報処理装置とは異なる装置を指定することも可能である。

ところで、イベント登録要求を受信したデータ処理装置が登録する情報には、必ずイベント発生時に通知を行なうイベント通知先がＵＲＬとして含まれている。このように登録要求されたＵＲＬを登録する方法については従来から知られている（特許文献１参照）。

Ｗｅｂサービスの利用においては、Ｗｅｂサービスを利用するためのリクエストを送信する際の宛先情報として、Uniform Resource Locator（ＵＲＬ）が用いられる。近年は、このＵＲＬに特定の記号で区切られた任意の文字列（クエリストリング：query string）を付加して情報処理装置からデータ処理装置にＷｅｂサービスのリクエストを送信することができる。

クエリストリングを含んだＵＲＬ宛てにＷｅｂサービスのリクエストを送信すると、それを受信したサーバはリクエストに含まれているクエリストリングに基づいた処理を行う。このような技術を用いると、例えば簡単にＷｅｂメールシステムなどが作成できる。すなわち、ブラウザ側からユーザ、パスワード、メール情報などをクエリストリングとして付加してリクエストを送信し、それを受信したＷｅｂメールサーバは含まれている情報に基づいたメール情報を検索して返信する。返信された結果はブラウザに表示され、ユーザはブラウザさえあればメールを見ることが可能となる。

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

情報処理装置がデータ処理装置にイベント通知先登録を要求するには以下の場合がある。例えば、イベント通知先の装置から情報処理装置に対して代行して登録要求するように依頼するのではなく、情報処理装置が自動的にイベント通知先を予測して宛先となるＵＲＬを作成し、該ＵＲＬをデータ処理装置にイベント通知先として登録要求する場合である。この場合、情報処理装置が自動的に作成するイベント通知先ＵＲＬにクエリストリングを含んでしまうことがある。

イベント登録要求を受信したデータ処理装置がクエリストリングを含むイベント通知先を登録すると、データ処理装置から送信されるイベント通知メッセージは、登録された、クエリストリングを含むＵＲＬに送信される。

このようなイベント通知メッセージを受信した装置でクエリストリングの処理を行うことができた場合、イベント通知された装置からイベント通知元であるデータ処理装置に対して、イベント通知メッセージの受信に成功したことを示すメッセージが返信される。返信されたメッセージの中にクエリストリングに基づいて得られたデータが付加されているが、このデータは巨大な場合がある。データ処理装置が巨大なデータを受信すると、その巨大なデータの処理に時間がかかり、その間、他のイベント通知が行なえなくなったり、イベント通知先登録要求が行なえなくなったりしてしまうという課題がある。

本発明は、クエリストリングに基づく大きなデータを受信して処理を行うことがなくなり、装置上での他のイベント通知や登録要求に影響を与えることを防止することができるデータ処理装置及び方法、並びにプログラムを提供することを目的とする。

上記目的を達成するために、請求項１記載のデータ処理装置は、データ処理装置であって、前記データ処理装置に関する情報の通知先として、通知先を示す通知先情報を登録する登録手段と、新しい通知先を登録するよう要求する登録要求を受け付ける受付手段と、前記登録要求に含まれる、通知先を示す通知先情報に、所定の情報が含まれているか否かを判定する判定手段とを備え、前記判定手段によって前記所定の情報が含まれていないと判定された場合に、前記登録手段は、前記登録要求に含まれる前記通知先情報を通知先として登録し、前記判定手段によって前記所定の情報が含まれていると判定された場合に、前記登録手段は、前記登録要求に含まれる前記通知先情報を通知先として登録しないことを特徴とする。

本発明によれば、クエリストリングに基づく大きなデータを受信して処理を行うことがなくなり、装置上での他のイベント通知や登録要求に影響を与えることを防止することができる。

本発明の第１の実施形態に係るデータ処理装置が接続されたネットワーク環境の一例を示すネットワーク構成図である。 図１のＭＦＰのハードウェア構成を示すブロック図である。 ＭＦＰのソフトウェア構成を示すブロック図である。 一般的に送信されるイベント通知先登録要求メッセージとその返信メッセージの一例を示す図である。 イベント発生時に送信されるイベント通知メッセージとその返信メッセージの一例を示す図である。 サーバ装置がＷｅｂメールサービスを提供する際に使用するメッセージの一例を示す図である。 クエリストリングを含むＵＲＬ宛てのイベント通知先登録要求メッセージとイベント通知メッセージの一例を示す図である。 ＭＦＰからＰＣに向けて送信されるエラーメッセージの一例を示す図である。 Ｗｅｂサービスサーバ部で実行される処理の一例を示すフローチャートである。 本発明の第２の実施形態におけるＷｅｂサービスサーバ部で実行される処理の一例を示すフローチャートである。 本発明の第３の実施形態におけるＭＦＰのソフトウェア構成を示すブロック図である。 図１１のＷｅｂサービスサーバ部で実行される処理の一例を示すフローチャートである。 本発明の第４の実施形態におけるＭＦＰのソフトウェアの構成を示すブロック図である。 図１３のＷｅｂサービスサーバ部で実行される処理の一例を示すフローチャートである。 ＭＦＰの操作パネル上に表示されるユーザーインターフェースの一例を示す図である。

以下、本発明の実施の形態を図面を参照して詳細に説明する。

［第１実施形態］
図１は、本発明の第１の実施形態に係るデータ処理装置が接続されたネットワーク環境の一例を示すネットワーク構成図である。

図示例のネットワークでは、以下に説明する装置を含む全ての装置がＬＡＮ１００に接続されている。そして、各装置には、例えば、ネットワークアドレス192.168.242.0、サブネットマスク255.255.255.0というＩＰアドレスが設定されている。

パーソナル・コンピュータ（ＰＣ）１０２は、ＭＦＰ１０１に対してイベント通知先登録の要求を送信する情報処理装置である。ＰＣ１０２には、ＩＰアドレスとして、192.168.242.102が割り当てられている。ＭＦＰ１０１は、プリンタ・スキャナ・ＦＡＸなどの機能を有するデータ処理装置であり、ＰＣ１０２からイベント通知先登録要求を受信してイベント発生時にイベントを通知する。ＭＦＰ１０１には、ＩＰアドレスとして、192.168.242.101が割り当てられている。

サーバ装置１０３は、ＭＦＰ１０１から実際にイベント通知が送信される通知先（宛先）である。本実施の形態では、サーバ装置１０３は、Ｗｅｂメールシステムを提供するサーバとする。サーバ装置１０３には、ＩＰアドレスとして、192.168.242.103が割り当てられている。

なお、ＬＡＮ１００は、ルーターのようなものを介していてもよいし、ネットワークアドレス、サブネットマスク、ＩＰアドレスなどは任意のものであってもよい。また、サーバ装置１０３は、Ｗｅｂメールシステムを提供するサーバ以外の任意の装置であってよい。

次に、図１におけるＭＦＰ１０１のハードウェア構成について説明する。

図２は、図１のＭＦＰ１０１のハードウェア構成を示すブロック図である。

図２において、ＣＰＵ５０１は、ＲＯＭ５０３を構成するプログラム用ＲＯＭに記憶された制御プログラムに基づいて、システムバス５０４に接続される各種のデバイスとのアクセスを総括的に制御する。また、ＣＰＵ５０１は、印刷インターフェース５０７を介して接続される印刷部（プリンタエンジン）５１０に出力情報としての画像信号を出力する。さらに、ＣＰＵ５０１は、読取インターフェース５１２を介して接続される読取部（スキャナ）５１３から入力される画像信号を制御する。

ＲＯＭ５０３を構成するプログラム用ＲＯＭには、ＣＰＵ５０１が実行可能な制御プログラム等を記憶する。ＲＯＭ５０３を構成するフォント用ＲＯＭには、上記出力情報を生成する際に使用されるフォントデータ（アウトラインフォントデータを含む）等を記憶する。ＲＯＭ５０３を構成するデータ用ＲＯＭには、ＭＦＰ上で利用される情報等を記憶している。

ＣＰＵ５０１は、ＬＡＮコントローラ（ＮＩＣ）５０６を介して、ＬＡＮ１００上のＰＣ１０２やサーバ装置１０３等との通信が可能となっている。ＲＡＭ５０２は、主としてＣＰＵ５０１の主メモリ，ワークエリア等として機能し、図示しない増設ポートに接続されるオプションＲＡＭによりメモリ容量を拡張することができるように構成されている。また、ＲＡＭ５０２は、出力情報展開領域、環境データ格納領域等に用いられる。

記憶装置５１１は、ハードディスク（ＨＤ）やＩＣカード等のメモリで構成され、ディスクコントローラ（ＤＫＣ）５０８によりアクセスが制御される。記憶装置５１１は、フォントデータ、エミュレーションプログラム、フォームデータ等を記憶し、プリントジョブを一時的にスプールし、スプールされたジョブを外部から制御するためのジョブ格納領域として使用される。また、記憶装置５１１は、スキャナ５１３から読み取った画像データやプリントジョブの画像データをＢＯＸデータとして保持し、ネットワークから参照し、印刷を行うＢＯＸデータ格納領域としても使用される。なお、記憶装置５１１は、１個であっても複数であってもよく、内蔵フォントに加えてオプションフォントカード、言語系の異なるプリンタ制御言語を解釈するプログラムを格納した外部メモリを複数接続できるように構成されていてもよい。

操作パネル５０５は、ユーザがソフトウェアキーから各種情報を入力することが可能である。不揮発性メモリ５０９は、操作パネル５０５から設定される各種設定情報を記憶している。

なお、ＭＦＰ１０１には、オプションとして、ステープルやソート機能を行うフィニッシャや両面印刷機能を実現するための両面装置など各種拡張装置を装着することが可能となっており、それらの動作はＣＰＵ５０１から制御される。

次に、ＭＦＰ１０１のソフトウェアの構成について説明する。

図３は、図１のＭＦＰ１０１のソフトウェア構成を示すブロック図である。

ＭＦＰ１０１内部のソフトウェアは、ＬＡＮコントローラ５０６と、ＨＴＴＰ／ＴＣＰ／ＩＰのようなプロトコルを制御するプロトコルスタック部６０１と、Ｗｅｂサービスを提供するＷｅｂサービスサーバ部６００とに大きく分けられる。

プロトコルスタック部６０１は、送受信するデータにおけるＨＴＴＰヘッダまでを処理する。ＭＦＰ１０１が、例えば、後述する図７（ａ）に示すメッセージを受信した場合、最初の２行の部分はプロトコルスタック部６０１によって処理される。その後、ＸＭＬで記述されたメッセージ（以下、「ＸＭＬメッセージ」とする）の部分をＷｅｂサービスサーバ部６００に渡し、Ｗｅｂサービスサーバ部６００でＸＭＬメッセージが処理される。

Ｗｅｂサービスサーバ部６００において、Ｗｅｂサービスリクエスト受信部６０２は、ＸＭＬメッセージを受け取る機能を有する。ＸＭＬメッセージ解析部６０３は、受け取ったＸＭＬメッセージを解析して所定の情報を取り出す機能を有する。通知先ＵＲＬ抽出部６０４は、ＸＭＬメッセージ解析部６０３により取り出された情報から通知先ＵＲＬ（Uniform Resource Locator）情報を抽出する機能を有する。この通知先ＵＲＬ情報は、通知先を特定するための宛先情報であり、イベント通知先やイベント登録が終了したときの通知先のＵＲＬなどが含まれる。

通知先ＵＲＬ解析部６０５は、通知先ＵＲＬ抽出部６０４により取り出された通知先ＵＲＬを解析する。クエリストリング判定部６０６は、通知先ＵＲＬ解析部６０５による解析結果から、文字列判定手段として、特定の文字列すなわちクエリストリング（query string）を示す文字列が含まれているか否かの判定を行う。その判定結果を受けて、イベント登録可否判定部６０７がイベント通知先を登録するか否かを決定し、登録する場合はイベント登録部６１０に情報を渡し、イベント通知情報記憶部６１１に保存される。

ＸＭＬメッセージ構成部６０８は、イベント通知先の登録が行なわれるか否かに関わらず、返信メッセージを作成する。そして、Ｗｅｂサービスレスポンス返信部６０９がプロトコルスタック部６０１、ＬＡＮコントローラ５０６を介してＬＡＮ１００に返信メッセージを送信して、応答を行う。

次に、図１のネットワーク環境での通信に使用されるメッセージの内容について図４〜図８を用いて説明する。

各メッセージともＸＭＬを使って構成され、ＨＴＴＰ（Hypertext Transfer Protocol）を使用して送受信されるものと仮定しているが、それ以外のメッセージ形態やプロトコルを使用してもよい。

図４及び図５は、イベント通知先登録要求で一般的に送受信されるメッセージと、実際のイベント通知のメッセージの一例を示す図である。

図４（ａ）に示すメッセージは、ＰＣ１０２がＭＦＰ１０１に対してイベント通知先登録要求を行なうために送信されるＸＭＬメッセージである。図４（ａ）において、行２０１のAction要素の値が「Subscribe」であることが、このＸＭＬメッセージがイベント通知先登録要求のためのものであることを示している。

行２０２には、ＭＦＰ１０１がイベント通知先を登録した後、ＭＦＰ１０１が再起動されるなどの理由で登録が終了する際に通知する宛先ＵＲＬが記述されている。例えばＭＦＰ１０１の電源がＯＦＦになる際に、行２０２に記述されたＵＲＬ宛てにその旨（電源ＯＦＦになること）を通知する。行２０３には、ＭＦＰ１０１が実際にイベントを通知する宛先ＵＲＬが記述されている。図４（ａ）の例では、行２０２，２０３に宛先ＵＲＬとして、サーバ装置１０３のＩＰアドレスが記述されている。なお、行２０２と２０３に示す宛先ＵＲＬは同じ装置宛てのＵＲＬである必要はなく、異なる装置宛てのＵＲＬであっても構わない。行２０２も行２０３も、ＭＦＰ１０１で発生した何らかのイベントをもとにしてメッセージを送信する宛先なので、以降の説明ではどちらもイベント通知先と呼ぶ。

行２０４は、どのイベントが発生したときに通知してもらうかをＰＣ１０２が指定するためのものであり、図示例では「JobEndEvent」となっていることから、ＭＦＰ１０１でジョブが終了した際にイベント通知を行なうように要求したものである。

図４（ｂ）に示すＸＭＬメッセージは、図４（ａ）の通知メッセージに対する返信メッセージであり、ＭＦＰ１０１からＰＣ１０２に向けて送信される。行２０５はに、ＨＴＴＰの通信が正常に行えたことを示す内容が記述されている。行２０６のAction要素が「SubscribeResponse」であることが、このＸＭＬメッセージが図４（ａ）に対する返信であることを示している。

図５（ａ）に示すメッセージは、ＭＦＰ１０１においてイベントが発生した際に送信されるイベント通知であり、ＭＦＰ１０１からサーバ装置１０３に向けて送信される。行２０７の「JobEndEvent」の文字列がジョブ終了を通知するメッセージであることを示している。

図５（ｂ）に示すメッセージは、図５（ａ）に対する返信メッセージであり、サーバ装置１０３からＭＦＰ１０１に向けて送信される。図示例では、特にＸＭＬで記述されたメッセージは含まれていないものとする。

図６は、サーバ装置１０３がＷｅｂメールサービスを提供する際に使用するメッセージの一例を示す図である。なお、図示例のメッセージでは、ＸＭＬではなく、HyperText Markup Language（ＨＴＭＬ）が使用されている。

図６（ａ）に示すメッセージは、サーバ装置１０３を利用したい任意の装置（不図示）からサーバ装置１０３に送信されるメッセージである。図示例のメッセージには、行３０１にクエリストリングを含んでいる。ここでクエリストリングに含まれている文字列「ｕｓｒ」と「ｐｗ」と「ｉｄ」は、それぞれユーザ名、パスワード、メールＩＤを示す。なお、クエリストリングとして含まれる文字列はこれ以外のものであってもよい。また、多くのＷｅｂサーバでは、クエリストリングを含むリクエストはＰＯＳＴではなく、ＧＥＴメソッドを用いて行なわれるが、Ｗｅｂサーバの中にはＰＯＳＴメソッドであってもクエリストリングを受け付けるものが存在することが知られている。

図６（ｂ）に示すメッセージは、図６（ａ）に対する返信メッセージであり、サーバ装置１０３からリクエストを送信した装置に向けて送信される。行３０２には、行３０１に含まれていたクエリストリングの内容に対応するメールの本文が含まれている。

図７及び図８は、本発明の実施形態におけるイベント通知先登録要求で送受信されるメッセージと、実際のイベント通知のメッセージの一例を示す図である。

図７（ａ）に示すメッセージは、クエリストリングを含むＵＲＬ宛てのイベント通知先登録要求メッセージの一例であり、ＰＣ１０２からＭＦＰ１０１に向けて送信される。図示のメッセージは、図４（ａ）のメッセージにおける行２０２，２０３がそれぞれ行４０１，４０２のように変更されている。

図７（ｂ）に示すメッセージは、図７（ａ）のメッセージの内容をＭＦＰ１０１が登録した後に、ＭＦＰ１０１でイベントが発生した際にサーバ装置１０３に向けて送信されるイベント通知メッセージである。図示のイベント通知メッセージが図５（ａ）のメッセージと異なる点は、行４０３でクエリストリングを含んでいることである。

図８は、ＭＦＰ１０１がイベント通知先登録要求のメッセージを受信した際に何らかの理由で登録を行なえなかった場合に、ＭＦＰ１０１からＰＣ１０２に向けて送信されるエラーメッセージの一例を示す図である。

図８において、行４０４の「Regist Error」という文字列が登録に失敗したことを示している。

ここで、上述した課題が起こり得る状況について図を用いて説明する。

例えば、ＰＣ１０２がＭＦＰ１０１に対して図７（ａ）に示すメッセージを送信し、ＭＦＰ１０１が行４０１，４０２に記述されたイベント通知先ＵＲＬを登録する。その後、ＭＦＰ１０１でイベントが発生した場合、ＭＦＰ１０１が図７（ｂ）に示すイベント通知メッセージをサーバ装置１０３に送信してしまう。そのイベント通知に対するＨＴＴＰ返信メッセージとして、図６（ｂ）に示すメッセージがサーバ装置１０３からＭＦＰ１０１に返信される。これを受信したＭＦＰ１０１は、通常であれば処理する必要がないＨＴＴＰ返信メッセージに含まれたメールのデータ（行３０２）も処理する必要が生じ、ＭＦＰ１０１に不要な負荷がかかってしまう。本発明の課題の一例である。

図９は、Ｗｅｂサービスサーバ部６００で実行される処理の一例を示すフローチャートである。

ＭＦＰ１０１は、ＰＣ１０２から送信された図７（ａ）のイベント通知先登録要求メッセージをＬＡＮコントローラ５０６で受信する。すると、プロトコルスタック部６０１によりＸＭＬメッセージが抽出され、Ｗｅｂサービスリクエスト受信部６０２がＸＭＬメッセージを受け取る（ステップＳ７０１）。

次に、受け取ったＸＭＬメッセージをＸＭＬメッセージ解析部６０３が解析し、該メッセージに含まれている行２０１の<Action>タグの値や行４０１の<EndTo>タグの値、行４０２の<NotifyTo>タグの値を取得する（ステップＳ７０２）。

次に、ステップＳ７０２で取得された各値から、通知先ＵＲＬ抽出部６０４が通知先ＵＲＬ情報を抽出する（ステップＳ７０３）。この通知先ＵＲＬ情報は、上述したように、行４０１，４０２に記述されたイベント通知先やイベント登録が終了したときの通知先のＵＲＬなどである。

次に、通知先ＵＲＬ解析部６０５が、ステップＳ７０３で抽出された通知先ＵＲＬ情報にどのような文字列が含まれているか通知先ＵＲＬ情報を解析する（ステップＳ７０４）。そして、クエリストリング判定部６０６によって、通知先ＵＲＬ情報の中にクエリストリングを示す文字列が含まれているか否かが判定され、さらにイベント登録可否判定部６０７によって、イベント通知先を登録するか否かが判断される（ステップＳ７０５）。つまり、図４（ａ）のタイプの登録要求メッセージか、図７（ａ）のタイプの登録要求メッセージかを判定し、図４（ａ）のタイプであれば登録すると判断する。一方、図７（ａ）のタイプであれば登録しないと判断する。

イベント通知先を登録する判断がなされた場合（ステップＳ７０５でＮＯ）、イベント登録部６１０は、イベント通知情報記憶部６１１に必要な情報を保存し、イベント登録を行う（ステップＳ７０６）。必要な情報とは、どのイベントが発生したときにイベント通知を行なうか、イベント登録が終了したことを通知する際の宛先、イベント通知先などの情報である。

一方、イベント通知先を登録しない判断がなされた場合（ステップＳ７０５でＹＥＳ）、イベント登録可否判定部６０７は、受信したイベント通知先登録要求メッセージを破棄する（ステップＳ７０８）。そして、ＸＭＬメッセージ構成部６０８が返信メッセージを作成し、Ｗｅｂサービスレスポンス返信部６０９によってＰＣ１０２に向けてメッセージが送出される（ステップＳ７０９）。

送出されるメッセージに関しては、イベント通知先の登録が行なわれた場合、図４（ｂ）に示すようなメッセージをＸＭＬメッセージ構成部６０８が作成し、Ｗｅｂサービスレスポンス返信部６０９がＰＣ１０２に送信する（ステップＳ７０７）。イベント通知先が登録されなかった場合、図８に示すようなエラーメッセージをＸＭＬメッセージ構成部６０８が作成し、Ｗｅｂサービスレスポンス返信部６０９がＰＣ１０２に送信する（ステップＳ７０９）。

上記第１の実施形態によれば、クエリストリングを含んだＵＲＬ宛てのイベント通知登録要求を破棄し、上記のような宛先ＵＲＬへのイベント通知が送信されないようにすることで、クエリストリングに基づいた巨大なデータを受信しないようにする。これにより、データ処理に時間がかかることがなくなり、他のイベント通知や登録要求処理に影響を及ぼすことがなくなる。

［第２の実施形態］
本発明の第２の実施の形態に係るデータ処理装置は、図１〜図３に示す構成等が上記第１の実施の形態に係るデータ処理装置と同じであり、第１の実施の形態と同様の部分については、同一の符号を用いてその説明を省略する。以下に、上記第１の実施の形態と異なる点のみを説明する。

図１０は、本発明の第２の実施形態におけるＷｅｂサービスサーバ部６００で実行される処理の一例を示すフローチャートである。なお、図示の処理では、図９における同一の処理ステップには同一のステップ番号を付して、その説明を省略する。

図９に示す処理との違いは、ＭＦＰ１０１が図７（ａ）に示すメッセージを受信して、クエリストリングを含んだ通知先ＵＲＬ情報を抽出した際の動作のみである。まず、抽出した通知先ＵＲＬ情報にどのような文字列が含まれているかを通知先ＵＲＬ解析部６０５が解析する（ステップＳ７０４）。そして、クエリストリング判定部６０６によって、通知先ＵＲＬ情報の中にクエリストリングが含まれているか否かが判定される（ステップＳ７０５）。その結果、クエリストリングが含まれているという理由から、イベント登録可否判定部６０７によって、イベント通知先を登録しない判断がなされた場合（ステップＳ７０５でＹＥＳ）、ステップＳ７０８へ移行する。

ステップＳ７０８では、イベント登録可否判定部６０７は、受信したイベント通知先登録要求メッセージを破棄する（ステップＳ７０８）。そして、図４（ｂ）に示すような、登録が成功したことを示すメッセージをＸＭＬメッセージ構成部６０８が作成し、Ｗｅｂサービスレスポンス返信部６０９がＰＣ１０２に送信する（ステップＳ７０７）。

上記第２の実施形態によれば、クエリストリングを含んだＵＲＬ宛てのイベント通知登録要求を破棄しつつ、登録要求を送信したＰＣに通知先登録の成功を示すメッセージを返信する。これによって、以降そのＰＣ１０２からのクエリストリングを含んだＵＲＬの登録要求を防ぐことができる。

［第３の実施形態］
本発明の第３の実施の形態に係るデータ処理装置は、図１〜図２に示す構成等が上記第１の実施の形態に係るデータ処理装置と同じであり、第１の実施の形態と同様の部分については、同一の符号を用いてその説明を省略する。なお、本実施形態では、第１の実施形態におけるＭＦＰ１０１がＭＦＰ１０１ａに対応する。

本実施形態では、上記第１の実施形態と異なり、ＭＦＰ１０１ａにおいてイベント通知先登録要求メッセージを受信した際に、通知先ＵＲＬ情報にクエリストリングを含んでいた場合、クエリストリングの部分をＵＲＬから取り除いてから登録を行なう。さらに、本実施形態では、登録を行なう前に、本当にイベント通知を送信できるか否かを判定するために、試しに何らかのメッセージを送信して、送信できることを確認した段階で登録する。

図１１は、本発明の第３の実施形態におけるＭＦＰ１０１ａのソフトウェア構成を示すブロック図である。

Ｗｅｂサービスサーバ部６００ａは、図３のイベント登録可否判定部６０７に代えて、通知先ＵＲＬ調整・決定部９０１とＵＲＬ使用可否チェック部９０２を備える。通知先ＵＲＬ調整・決定部９０１は、通知先決定手段として、通知先ＵＲＬ情報にクエリストリングが含まれていたときに、クエリストリングの部分だけを削除して新たな通知先を作成する機能を有する。ＵＲＬ使用可否チェック部９０２は、通知先ＵＲＬ調整・決定部９０１によってクエリストリングが削除された通知先ＵＲＬ情報が実際に通信可能か否かを判定する。つまり、ＵＲＬ使用可否チェック部９０２は、通信可否判定手段として、クエリストリングが削除された新たな宛先情報宛てに通信が可能か否かを判定する。

図１２は、図１１のＷｅｂサービスサーバ部６００ａで実行される処理の一例を示すフローチャートである。なお、図示の処理では、図９における同一の処理ステップには同一のステップ番号を付して、その説明を省略する。

ステップＳ７０５で通知先ＵＲＬ情報にクエリストリングが含まれていると判断された場合、通知先ＵＲＬ調整・決定部９０１は、通知先ＵＲＬ情報からクエリストリングの部分を削除して、新たな通知先ＵＲＬ情報を作成する（ステップＳ１００１）。クエリストリングの部分が削除された通知先ＵＲＬ情報を登録する場合、ＵＲＬ使用可否チェック部９０２は、クエリストリングの部分が削除された、新たな通知先ＵＲＬ情報に基づいてメッセージ（プローブメッセージ）を送信する（ステップＳ１００２）。そして、通信が可能か否かを判定する（ステップＳ１００３）。これら一連の処理については登録前に行ってもよいし、登録後に最初にイベント通知を行う際に行ってもよい。また、場合によっては、これらの一連処理を行わなくてもよい。

上記ステップＳ１００１〜Ｓ１００３の処理で送信が可能であることが分かった場合や、もともとクエリストリングが含まれていないＵＲＬが登録されようとしていた場合は、図４（ｂ）に示すメッセージをＰＣ１０２に向けて送信する（ステップＳ７０７）。

ステップＳ１００１〜Ｓ１００３の処理で送信が不可能であることが分かった場合は（ステップＳ１００３でＮＯ）、イベント登録可否判定部６０７は、受信したイベント通知先登録要求メッセージを破棄する（ステップＳ７０８）。そして、図８に示すようなエラーメッセージをＸＭＬメッセージ構成部６０８が作成し、Ｗｅｂサービスレスポンス返信部６０９がＰＣ１０２に送信する（ステップＳ７０９）。

一方、ステップＳ１００３で通信可能であると判定された場合、イベント登録部６１０は、イベント通知情報記憶部６１１に必要な情報を保存し、イベント登録を行う（ステップＳ７０６）。

上記第３の実施形態によれば、登録要求されたイベント通知先ＵＲＬ情報にクエリストリングが含まれていた場合に、クエリストリングの部分を削除する。これにより、サーバ装置１０３へのイベント通知機能だけは維持しつつ、クエリストリングに基づく大きなデータの受信を防止することができる。

また、本実施形態では、クエリストリングの部分を取り除いた通知先ＵＲＬ情報に対して、本当にイベント通知が可能か否かを判定する手段を設けることにより、無駄な登録を行なわないようにできる。

［第４の実施形態］
本発明の第４の実施の形態に係るデータ処理装置は、図１〜図２に示す構成等が上記第１の実施の形態に係るデータ処理装置と同じであり、第１の実施の形態と同様の部分については、同一の符号を用いてその説明を省略する。以下に、上記第１の実施の形態と異なる点のみを説明する。

本実施形態では、クエリストリングを含む通知先ＵＲＬ情報に対してイベント通知を行なうように要求してきたＰＣ１０２に対して、ＭＦＰ１０１が以降のイベント通知先登録を拒否する。そして、拒否されたものはユーザーインターフェース（ＵＩ）で確認することができ、ユーザによって拒否設定が解除できる。

図１３は、本発明の第４の実施形態におけるＭＦＰ１０１ｂのソフトウェアの構成を示すブロック図である。なお、図示例では、ハードウェアとして操作パネル５０５が含まれる。

Ｗｅｂサービスサーバ部６００ｂは、図３のＷｅｂサービスサーバ部６００が備える各部に加えて、受信アドレス取得部１１０１と受信可否判定部１１０２とＩＰアドレス記憶部１１０３とＨＴＴＰエラー処理送信依頼部１１０４を備える。ＭＦＰ１０１ｂは、保存アドレス削除部１１０５を備える。

上記のようなイベント通知先登録要求を拒否するＩＰアドレスは、ＩＰアドレス記憶部１１０３に保存されている。受信アドレス取得部１１０１は、イベント通知先登録要求メッセージの送信元のＩＰアドレス情報を取得する。ここでは、ＰＣ１０２のネットワークアドレス192.168.242.102を取得することになる。

受信可否判定部１１０２は、アドレス判定手段として、取得したＩＰアドレスがＩＰアドレス記憶部１１０３に保存されているか否かを判定し、保存されている場合はイベント通知先登録要求を拒否すると判断する。そして、ＨＴＴＰエラー処理送信依頼部１１０４がプロトコルスタック部６０１を介してエラーメッセージをＰＣ１０２宛てに返信する。ＩＰアドレス記憶部１１０３に保存されているＩＰアドレスは、操作パネル５０５から削除依頼を行なうことができ、削除依頼を受けると保存アドレス削除部１１０５によって選択されたＩＰアドレスが削除される。

図１４は、図１３のＷｅｂサービスサーバ部６００ｂで実行される処理の一例を示すフローチャートである。なお、図示の処理では、図９における同一の処理ステップには同一のステップ番号を付して、その説明を省略する。

本実施形態では、Ｗｅｂサービスリクエスト受信部６０２が図７（ａ）に示すメッセージを受け取った場合、ＸＭＬメッセージを解析する前に、イベント通知先登録要求メッセージの送信元をチェックする。

ステップＳ７０１の後、ステップＳ１２０１では、受信アドレス取得部１１０１は、受信したメッセージの送信元ＩＰアドレス情報を取得する。次に、取得されたＩＰアドレスに対して、受信可否判定部１１０２が、ＩＰアドレス記憶部１１０３に保持されているＩＰアドレスと比較処理を施し（ステップＳ１２０２）、一致するものがあるか否かを判定する（ステップＳ１２０３）。その結果、一致するものが存在する場合は（ステップＳ１２０３でＹＥＳ）、ＨＴＴＰエラー処理送信依頼部１１０４が今回受信したイベント通知先登録要求を拒否し、ＨＴＴＰによるエラーメッセージを返信する（ステップＳ１２０４）。ここでは、ＨＴＴＰのエラーメッセージを返信するが、図８に示すようなＷｅｂサービスのエラーメッセージを返信してもよい。

一方、ステップＳ１２０３でＩＰアドレス記憶部１１０３に一致するものが無い場合は（ステップＳ１２０３でＮＯ）、ＸＭＬメッセージの処理を継続するため、受信可否判定部１１０２がＸＭＬメッセージをＸＭＬメッセージ解析部６０３に渡す。そして、ステップＳ７０２以降の処理が実行される。

そして、イベント通知先が登録されず、イベント登録可否判定部６０７によって、図７（ａ）のような受信したイベント通知先登録要求メッセージが破棄された場合（ステップＳ７０８）、ステップＳ１２０５へ移行する。ステップＳ１２０５では、イベント登録可否判定部６０７が登録要求を送信した装置（ここではＰＣ１０２）のＩＰアドレス情報をＩＰアドレス記憶部１１０３に保存して、ステップＳ７０９へ移行する。ステップＳ７０９では、図８に示すようなエラーメッセージをＸＭＬメッセージ構成部６０８が作成し、Ｗｅｂサービスレスポンス返信部６０９がＰＣ１０２に向けて送信する（ステップＳ７０９）。

次に、ＭＦＰ１０１ｂでイベント通知先登録要求を拒否した場合のユーザーインターフェースについて説明する。

本実施形態では、ＩＰアドレス記憶部１１０３に保存されたＩＰアドレス情報は、操作パネル５０５に表示されるユーザーインターフェースで確認することができると共に、ユーザがイベント登録拒否状態を解除することができる。

図１５は、ＭＦＰ１０１ｂの操作パネル５０５上に表示されるユーザーインターフェースの一例を示す図である。

図示のユーザーインターフェースは操作パネル５０５に表示されるタッチパネルである。ユーザはタッチパネルをタッチすることで設定を変更することができる。

図１５に示すイベント通知先登録要求拒否リスト画面において、１３０１には、ＩＰアドレス記憶部１１０３が保持しているＩＰアドレスの一覧が表示される。一覧表示されているＩＰアドレスについては、上記処理にてイベント通知先登録要求を拒否した装置のＩＰアドレスである。図示例では、ＰＣ１０２のＩＰアドレス１３０１ａ（192.168.242.102）がイベント通知先登録要求拒否リストに追加されている。

拒否解除ボタン１３０２は、拒否されているＩＰアドレス１３０１の拒否状態を解除するためのボタンである。拒否解除ボタン１３０２が押下されると、保存アドレス削除部１１０５は、該当するＩＰアドレスに対する削除指示に応じて、ＩＰアドレス記憶部１１０３に保存されているＩＰアドレス情報（192.168.242.102）を削除する。削除された後は、再度イベント通知先登録要求を受信することができるようになる。なお、不図示であるが、一度ユーザによって解除されたものを保持しておき、そのＩＰアドレスからの登録要求に対しては、常に受け付けるようにしてもよい。

上記第４の実施形態によれば、クエリストリングを含んだＵＲＬ宛てのイベント通知登録要求を受信した際に、登録要求を送信したＰＣ１０２の情報を保持しておき、以降そのＰＣからの登録を常に拒否するようにする。これにより、イベント通知先ＵＲＬの解析の手間を省くことができる。また、そのような拒否設定を解除できるようなユーザーインターフェースを設けることによって、自動的に行われた拒否設定をユーザの意思によって解除することもでき、利便性を損なわない。

上記第１〜第４の実施形態では、本発明をデータ処理装置としてＭＦＰに適用した形態について説明したが、これに限定されるものではなく、プリンタやスキャナ、通信装置や通信機能を有する情報処理装置、端末等であってもよいことは云うまでもない。

本発明の実施の形態は、ネットワーク又は各種記憶媒体を介して取得したソフトウェア（プログラム）をパーソナルコンピュータ（ＣＰＵ，プロセッサ）にて実行することでも実現できる。

１０１ ＭＦＰ
１０２ ＰＣ
６０１ プロトコルスタック部
６０２ Ｗｅｂサービスリクエスト受信部
６０３ ＸＭＬメッセージ解析部
６０４ 通知先ＵＲＬ抽出部
６０５ 通知先ＵＲＬ解析部
６０６ クエリストリング判定部
６０７ イベント登録可否判定部
６１０ イベント登録部

Claims (15)

1. データ処理装置であって、
   前記データ処理装置に関する情報の通知先として、通知先を示す通知先情報を登録する登録手段と、
   新しい通知先を登録するよう要求する登録要求を受け付ける受付手段と、
   前記登録要求に含まれる、通知先を示す通知先情報に、所定の情報が含まれているか否かを判定する判定手段とを備え、
   前記判定手段によって前記所定の情報が含まれていないと判定された場合に、前記登録手段は、前記登録要求に含まれる前記通知先情報を通知先として登録し、前記判定手段によって前記所定の情報が含まれていると判定された場合に、前記登録手段は、前記登録要求に含まれる前記通知先情報を通知先として登録しないことを特徴とするデータ処理装置。
2. データ処理装置であって、
   前記データ処理装置に関する情報の通知先として、通知先を示す通知先情報を登録する登録手段と、
   新しい通知先を登録するよう要求する登録要求を受け付ける受付手段と、
   前記登録要求に含まれる、通知先を示す通知先情報に、所定の情報が含まれているか否かを判定する判定手段とを備え、
   前記判定手段によって前記所定の情報が含まれていないと判定された場合に、前記登録手段は、前記登録要求に含まれる前記通知先情報を通知先として登録し、前記判定手段によって前記所定の情報が含まれていると判定された場合に、前記登録手段は、前記登録要求に含まれる前記通知先情報から前記所定の情報を削除した情報を通知先として登録することを特徴とするデータ処理装置。
3. 前記所定の情報はクエリストリングを示す情報であることを特徴とする請求項１又は２に記載のデータ処理装置。
4. 前記受付手段は、ネットワークを介して外部装置から送信された登録要求を受け付けることを特徴とする請求項１乃至３のいずれか１項に記載のデータ処理装置。
5. 前記データ処理装置と前記外部装置との間の通信にはＨＴＴＰが使用され、前記通知先情報はＵＲＬであることを特徴とする請求項４に記載のデータ処理装置。
6. 前記外部装置が受信拒否の対象ではないことを条件にして、前記判定手段による判定が実行されることを特徴とする請求項４又は５に記載のデータ処理装置。
7. 前記データ処理装置は、前記外部装置が受信拒否の対象であるか否かを、前記外部装置のＩＰアドレスに基づいて決定することを特徴とする請求項６に記載のデータ処理装置。
8. 前記データ処理装置に関する情報を、前記登録手段によって登録されている前記通知先情報が示す通知先に通知する通知手段を更に備えることを特徴とする請求項１乃至７のいずれか１項に記載のデータ処理装置。
9. 前記データ処理装置においてイベントが発生した場合に、前記通知手段は、前記データ処理装置に関する情報として前記イベントを通知することを特徴とする請求項８に記載のデータ処理装置。
10. 前記イベントは、前記データ処理装置の電源がＯＦＦになることを示すことを特徴とする請求項９に記載のデータ処理装置。
11. 前記イベントは、前記データ処理装置においてジョブが終了したことを示すことを特徴とする請求項９に記載のデータ処理装置。
12. 前記データ処理装置は印刷装置であることを特徴とする請求項１乃至１１のいずれか１項に記載のデータ処理装置。
13. データ処理装置のデータ処理方法であって、
    前記データ処理装置に関する情報の通知先として、通知先を示す通知先情報を登録する登録工程と、
    新しい通知先を登録するよう要求する登録要求を受け付ける受付工程と、
    前記登録要求に含まれる、通知先を示す通知先情報に、所定の情報が含まれているか否かを判定する判定工程とを有し、
    前記判定工程で前記所定の情報が含まれていないと判定された場合に、前記登録工程は、前記登録要求に含まれる前記通知先情報を通知先として登録し、前記判定工程で前記所定の情報が含まれていると判定された場合に、前記登録工程は、前記登録要求に含まれる前記通知先情報を通知先として登録しないことを特徴とするデータ処理方法。
14. データ処理装置のデータ処理方法であって、
    前記データ処理装置に関する情報の通知先として、通知先を示す通知先情報を登録する登録工程と、
    新しい通知先を登録するよう要求する登録要求を受け付ける受付工程と、
    前記登録要求に含まれる、通知先を示す通知先情報に、所定の情報が含まれているか否かを判定する判定工程とを有し、
    前記判定工程で前記所定の情報が含まれていないと判定された場合に、前記登録工程は、前記登録要求に含まれる前記通知先情報を通知先として登録し、前記判定工程で前記所定の情報が含まれていると判定された場合に、前記登録工程は、前記登録要求に含まれる前記通知先情報から前記所定の情報を削除した情報を通知先として登録することを特徴とするデータ処理方法。
15. 請求項１３又は１４に記載のデータ処理方法をコンピュータに実行させるためのコンピュータで読み取り可能なプログラム。

Images