(57)【要約】【課題】多機能周辺機器（ＭＦＰ）のような装置のウェブサービスアプリケーションにおけるイベント通知量を減少させる技術が与えられる。【解決手段】一技術において、登録ＩＤは、減少された通知のテーブルにおいてジョブＩＤと結び付けられている。特定のジョブに関連するイベントが発生するとき、そのジョブに関連付けられる加入者のみに対してイベント通知が送信される。【選択図】図１
2009087344.tif 000002
【特許請求の範囲】
【請求項１】
装置において通知を管理するコンピュータ実施方法であって、各々が少なくとも１つのサービスを提供する複数のウェブサービスアプリケーションを前記装置が有する、コンピュータ実施方法であって：
複数のアイテムを有する加入データを確立する段階であって、各々のアイテムが、アイテム毎に、少なくとも加入ＩＤフィールド、ＩＰアドレスフィールド及びジョブＩＤのフィールドを有する少なくともテーブルを有する、段階；
前記装置に対して加入要求について注意を払う段階；
各々の加入要求について前記加入ＩＤフィールド及び前記ＩＰアドレスフィールドを埋めることにより、各々のアイテムについてのテーブルのエントリを部分的に終了する段階；
前記装置により処理されたジョブについて注意を払う段階；
各々のジョブについて、各々のジョブＩＤを加入ＩＤと関連付け、前記ジョブＩＤフィールドを埋め、それにより、テーブルのエントリを終了する段階；並びに
特定のジョブに関連するイベントを検出することに応じて、特定のジョブに関連付けられ、検索された登録ＩＤと適合する加入者のみに対してイベント通知を送信するように前記テーブルを用いる段階；
を有するコンピュータ実施方法。
【請求項２】
請求項１に記載のコンピュータ実施方法であって：
特定のイベント通知が前記テーブルにおける何れのジョブＩＤとも関連付けられていないことを判定する段階；及び
イベント通知を送信しない段階；
を更に有する、コンピュータ実施方法。
【請求項３】
請求項１に記載のコンピュータ実施方法であって、前記確立する段階は、前記テーブルにおける通知フィールドを有する段階を更に有する、コンピュータ実施方法。
【請求項４】
請求項１に記載のコンピュータ実施方法であって、前記イベント通知はＷＳ−Ｅｖｅｎｔｉｎｇモジュールにより生成される、コンピュータ実施方法。
【請求項５】
請求項１に記載のコンピュータ実施方法であって、前記装置は、プリンタ、ファックス、スキャナ又は多機能周辺機器の何れかの一である、コンピュータ実施方法。
【請求項６】
多機能周辺機器において通知を管理する装置であって、前記多機能周辺機器は、各々が少なくとも１つのサービスを提供する複数のウェブサービスアプリケーションを有する、装置であって：
複数のアイテムを有する加入データを確立する通知機構であって、各々のアイテムが、少なくとも加入ＩＤフィールド、ＩＰアドレスフィールド及びジョブＩＤのフィールドを有する少なくともテーブルを有する、通知機構；
前記多機能周辺機器に対して加入要求について注意を払い、そして各々の加入要求のために前記加入ＩＤフィールド及び前記ＩＰアドレスフィールドを埋めることにより各々のアイテムについてテーブルエントリを部分的に終了する、モジュール；
前記多機能周辺機器により処理されたジョブについて注意を払い、各々のジョブＩＤを加入ＩＤと関連付け、前記ジョブＩＤフィールドを埋め、それにより、各々のジョブについてテーブルエントリを終了する、モジュール；並びに
特定のジョブに関連するイベントを検出するモジュールであって、前記モジュールは特定のジョブに関連付けられた加入者のみに対してイベント通知を送信するように前記テーブルを用いる、モジュール；
を有する装置。
【請求項７】
多機能周辺機器において通知を管理するコンピュータ実施方法であって、前記多機能周辺機器は、各々が少なくとも１つのサービスを提供する複数のウェブサービスアプリケーションを有する、コンピュータ実施方法であり：
クライアントが、多機能周辺機器により提供される第１イベンティングサービスに加入するように加入要求を送信する段階；
前記加入要求メッセージを受信し、前記メッセージが有効であることを確認し、加入応答メッセージをクライアントに戻すように送信する段階；
動作可能パネルにおいて登録されたスキャン宛先の全てを示す段階；
少なくとも２つのフィールド、即ち、宛先表示名及び加入ＩＤで通知テーブルを埋める段階；
ユーザが、スキャン宛先を選択し、オリジナルを取り込み、開始ボタンを押す段階；
前記第１イベンティングサービスの例を生成し、前記スキャン宛先に基づくテーブルから加入ＩＤを検索する段階；及び
前記検索された加入ＩＤと適合するクライアントのみに対して前記第１イベンティングサービスに対応するイベント通知を送信する段階；
を有するコンピュータ実施方法。
【請求項８】
請求項７に記載のコンピュータ実施方法であって、前記加入要求メッセージは、少なくともスキャン宛先登録情報及び宛先表示名を有する、コンピュータ実施方法。
【請求項９】
請求項８に記載のコンピュータ実施方法であって、加入することは、特定のジョブの状態、多機能周辺機器のスキャナ／プリンタ部分の状態及び前記第１イベンティングサービスの通知のような前記クライアントが関心を有するイベントをクライアントが認識することを可能にする、コンピュータ実施方法。
【請求項１０】
請求項７に記載のコンピュータ実施方法であって、前記第１イベンティングサービスはスキャン有効イベントである、コンピュータ実施方法。
【請求項１１】
多機能周辺機器においてイベント通知を処理するコンピュータ読み出し可能媒体であって、前記多機能周辺機器は、各々が少なくとも１つのサービスを提供する複数のサービスアプリケーションを有し、少なくとも１つの処理器により処理されるとき、命令を担持する前記コンピュータ読み出し可能媒体は：
各々のアイテムが、アイテム毎に、少なくとも加入ＩＤフィールド、ＩＰアドレスフィールド及びジョブＩＤフィールドを有する少なくともテーブルを有するように、複数のアイテムを有する加入データを確立し；
多機能周辺機器に対して加入要求について注意を払い；
各々の加入要求について前記加入ＩＤフィールド及び前記ＩＰアドレスフィールドを埋めることにより、各々のアイテムについてのテーブルのエントリを部分的に終了し；
前記多機能周辺機器により処理されたジョブについて注意を払い；
各々のジョブについて、各々のジョブＩＤを加入ＩＤと関連付け、前記ジョブＩＤフィールドを埋め、それにより、テーブルのエントリを終了し；そして
特定のジョブに関連するイベントを検出することに応じて、特定のジョブに関連付けられた加入者のみに対してイベント通知を送信するように前記テーブルを用いる；
ようにする、コンピュータ読み出し可能媒体。
【請求項１２】
請求項１１に記載のコンピュータ読み出し可能媒体であって：
特定のイベント通知が前記テーブルにおける何れのジョブＩＤとも関連付けられていないことを判定し；そして
イベント通知を送信しない；
ように更にする、コンピュータ読み出し可能媒体。
【請求項１３】
請求項１１に記載のコンピュータ読み出し可能媒体であって、前記イベント通知はＷＳ−Ｅｖｅｎｔｉｎｇモジュールにより生成される、コンピュータ読み出し可能媒体。
【請求項１４】
請求項１１に記載のコンピュータ読み出し可能媒体であって：
単独のクライアントが複数のＩＰアドレスを有することが可能であるときのために、前記テーブルに第４の通知フィールドを付加する；
ように更にする、コンピュータ読み出し可能媒体。
【請求項１５】
多機能周辺機器において通知を管理するコンピュータ読み出し可能手段であって、前記多機能周辺機器は、各々が少なくとも１つのサービスを提供する複数のウェブサービスアプリケーションを有する、コンピュータ読み出し可能手段であり：
クライアントが、ウェブサービスを可能にする多機能周辺機器を発見し；
前記クライアントを操作するユーザが前記多機能周辺機器をインストールすることを所望するかどうかを判定し；
前記クライアントが、スキャン有効イベントに加入するように加入要求を送信し；
前記加入要求メッセージを受信し、前記メッセージが有効であることを確認し、スキャン宛先トークンを有する加入応答メッセージをクライアントに戻すように送信し；
動作可能パネルにおいて登録されたスキャン宛先の全てを示し；
少なくとも２つのフィールド、即ち、宛先表示名及び加入ＩＤで通知テーブルを埋め；
スキャン有効イベントを生成し、前記スキャン宛先に基づくテーブルから加入ＩＤを検索し；そして
前記検索された加入ＩＤと適合されたクライアントのみに対して前記スキャン有効イベントを送信する；
コンピュータ読み出し可能手段。
【請求項１６】
請求項１５に記載のコンピュータ読み出し可能手段であって、前記加入要求メッセージは、少なくともスキャン宛先登録情報及び宛先表示名を有する、コンピュータ読み出し可能手段。
【請求項１７】
請求項１５に記載のコンピュータ読み出し可能手段であって、加入することは、特定のジョブの状態、多機能周辺機器のスキャナ／プリンタ部分の状態及びスキャン有効イベントの通知のような前記クライアントが関心を有するイベントをクライアントが認識することを可能にする、コンピュータ読み出し可能手段。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、多機能周辺機器（ＭＦＰ）等の装置に関し、特に、その多機能周辺機器におけるイベント通知の処理に関するが、それに限定されるものではない。
【背景技術】
【０００２】
この段落で説明する方法は推し進めることが可能である方法であるが、必ずしも、予め構想された又は推し進められた方法ではない。従って、他に示していない場合、この段落で説明する方法の何れも、この段落で単に説明することによって従来技術とみなされることを前提とするべきではない。
【０００３】
用語“ウェブサービス”は、ネットワーキングプロトコルにおいてＸＭＬ、ＳＯＡＰ及びＷＳＤＬ規格を用いてウェブベースのアプリケーションを統合する標準化された方法である。ＸＭＬはデータをタグ付けするように用いられ、ＳＯＡＰはウェブサービス要求及び応答とＸＭＬメッセージにエンコードする方法とを指定し、ＷＳＤＬは有効なサービスを表すために用いられる。ウェブサービスは、それらのウェブサービスを実施するためのプラットフォームに拘わらず、互いに通信するようにプログラマチック（ｐｒｏｇｒａｍｍａｔｉｃ）エンティティ及びネットワークエンティティのために用いられる。そのようなエンティティの多くは業務関連であるため、ウェブサービスは、ファイアウォールの先の各々の他のＩＴシステムの詳細な情報なしに、各々の他のＩＴシステムと業務においてデータを通信することを可能にする。
【０００４】
ウェブサービスは、ネットワークにおけるプログラマチックインタフェースを介してビジネスロジック、データ及び処理を共有する。ウェブサービスは、時間を要するカスタムコーディングを伴うことなく、異なるソースからの異なるアプリケーションが互いに通信することを可能にする。しかも、それらの通信がＸＭＬにおけるものである場合、ウェブサービスは、何れの１つのオペレーティングシステム又はプログラミング言語に関連するものではない。例えば、Ｊａｖａ（登録商標）はＰｙｔｈｏｎで記述することができ、Ｗｉｎｄｏｗｓ（登録商標）のアプリケーションはＵＮＩＸ（登録商標）のアプリケーションと対話することができる。
【０００５】
ウェブサービス規格は、セキュリティ、高信頼性のメッセージ及び疎結合システムにおける取引のための相互動作可能プロトコルを与えるように互いに構成される。ウェブサービス規格は、２つの承認された規格（例えば、ワールド・ワイド・ウェブ・コンソーシアム（Ｗ３Ｃ）及びＯＡＳＩＳ（Ｏｒｇａｎｉｚａｔｉｏｎ  ｆｏｒ  ｔｈｅ  Ａｄｖａｎｃｅｍｅｎｔ  ｏｆ  Ｓｔｒｕｃｔｕｒｅｄ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｓｔａｎｄａｒｄｓ）と、規格になる可能性のある提案中の文書及び草案を有する。
【０００６】
ウェブサービス規格を有効に利用する複数のサービスを提供する１つの方法は多機能周辺機器（ＭＦＰ）を介するものである。そのようなサービスは、プリント、コピー、ファックス、スキャン及びアーカイブを有することが可能である。各々のサービスは、ＭＦＰで実行されるウェブサービスアプリケーション（ＷＳＡ）により提供されることが可能である。
【０００７】
しかしながら、ＷＳＡは、ＭＦＰがジョブを終了したときはいつでも、大量のイベント通知を生成することが可能である。多数のイベント通知を生成することが可能である１つの有効なＭＦＰの例には、高速プリンタ／スキャナ／コピア／ファクシミリ投の機能を備えている製品がある。オフィス環境又は企業環境においては、１つの大きいＭＦＰを共有する数百の又は場合によっては数千のＰＣクライアントを有することがある。各々のクライアントは、ＭＦＰが生成することができるジョブイベントの全てに対する加入者であることが可能である。それらのジョブイベントは、プリントジョブが終了したことを特定のユーザに通知することを有するが、それに限定されるものではない。そのような場合、全てのジョブイベントについて、ＷＳＡは、加入している全てのＰＣクライアントのために一意のイベント通知を作成して送信する。
【０００８】
各々のＭＦＰは、短い時間で多数の通知を出すことが可能である。それらの通知は、処理するタイプ、サイズ、時間により変わり、ＭＦＰの種々の構成要素を必要とする。そのような環境は、数百又は数千の通知を作成して送信する。そのように通知を行うことは、プリンタ／スキャナ／コピア／ファクシミリの機能を備えたＭＦＰ又は何れの他の種類の機能を組み合わせて持ち合わせたＭＦＰに対しても有効な資源を容易に圧迫し、また、過多のネットワークトラフィックをもたらす。従って、それらの通知量を減少させるための機構を有するＭＦＰを備えることは有用である。
【発明の開示】
【発明が解決しようとする課題】
【０００９】
本発明は、ＷＳＡを備えるデバイスからの通知の数を減少させる技術を提供する。
【課題を解決するための手段】
【００１０】
本発明の実施形態においては、加入ＩＤを特定のジョブＩＤと関連付けるテーブルを作成することにより通知を減少することができる。その場合、本発明は、ジョブを生成した加入クライアントのみに対して、特定のジョブＩＤに関連する通知が送信されることを確実にする。  
更なる実施形態においては、加入ＩＤは宛先名と関連付けられる。
【発明を実施するための最良の形態】
【００１１】
以下の説明においては、説明目的のために、本発明の十分な理解が得られるように、複数の特定の詳細についての説明が与えられている。しかしながら、本発明については、それらの特定な詳細を伴わずに実行されることが可能であることを理解することができる。他の実施例においては、本発明を不必要に曖昧にすることを回避するように、周知の構造及び装置をブロック図の形式で示している。
【００１２】
図１は、本発明の実施形態に従った多機能周辺機器（ＭＦＰ）における通信を処理する例示としてのシステム１００を示すブロック図である。そのシステム１００は、クライアント１０２と、アドミニストレータ１０４と、装置設備マネージャ（ＤＦＭ）１０６及びＭＦＰにおいて実行される複数のＷＳＡ１０８を有する。
【００１３】
図１に示すシステム１００は、レガシーＯ／Ｓ、Ｌｉｎｕｘ又はＶｘＷｏｒｋｓを含む複数のオペレーティングシステム（Ｏ／Ｓ）プラットフォーム１４０を有することが可能である。クライアント１０２は、Ｗｉｎｄｏｗｓ  Ｖｉｓｔａ（登録商標）であることが可能である。少なくとも１つのＷＳＡｓ１０８はプレットフォーム１４０において実行されることが可能である。
【００１４】
ＤＦＭ１０６は、発見要求、クライアント１０２からのメタデータ要求及び構成、並びにアドミニストレータ１０４からの他のＭＦＰ管理要求に対して応答することによるＭＦＰを表現する。ＤＦＭ１０６は、ＷＳ−Ｄｉｓｃｏｖｅｒｙ、ＷＳ−ＭｅｔａｄａｔａＥｘｃｈａｎｇｅ、ＷＳ−Ｔｒａｎｓｆｅｒ及びＷＳ−Ｓｅｃｕｒｉｔｙ等の複数のウェブサービス規格の実施のリポジトリとしての機能を果たすことが可能であるが、それらに限定されるものではない。
【００１５】
ＭＦＰにおいて実行する各々のＷＳＡ１０８は、サービスを要求するクライアント１０２に対して、サービスを提供する。各々のＷＳＡ１０８は、ターゲットプラットフォームから独立した抽象ＡＰＩ１２４のような特定サービス用抽象ＡＰＩを用いることが可能である。図１に示すように、各々のＷＳＡ１０８はまた、ＷＳＡ１０８の内部又は外部のどちらかで、ＷＳ−Ｅｖｅｎｔｉｎｇモジュール１２２を用いることが可能である。
【００１６】
クライアント１０２は、ＭＦＰが発見要求又は発見ＨＥＬＬＯメッセージ（即ち、同様のネットワークにおいてＭＦＰから装置に報知するブロードキャストメッセージ又はマルチキャストメッセージ）を介して存在することを発見することが可能である。一旦、クライアント１０２がＭＦＰの存在を確認すると、クライアント１０２は、ＭＦＰが提供するサービスの全てを発見するように、例えば、ＭＳ−ＭｅｔａｄａｔａＥｘｃｈａｎｇｅを介して、装置メタデータ交換要求を送信する。ＤＦＭ１０６はその要求を受信し、ＭＦＰにより提供される種々のサービスを表わすメタデータを返送する。クライアント１０２は、ＭＦＰにおいて実行する特定のサービスアプリケーション、例えば、ＷＳＡ１０８からのサービスメタデータを要求することが可能である。このＷＳＡ１０８は、ウェブサービス装置（ＷＳＤ）マネージャ１１０からのサービスメタデータを要求することが可能であり、そのＷＳＤマネージャは、ＷＳＡ１０８にサービスメタデータを返送する。ＷＳＡ１０８は、クライアント１０２にそのサービスメタデータを転送する。
【００１７】
代替として、ＭＦＰの装置メタデータ及び少なくとも１つのＷＳＡのサービスメタデータは、同様な応答においてクライアント１０２に送信されることが可能である。
【００１８】
サービスメタデータに基づいて、クライアント１０２は、ＷＳＡ１０８が受信して、処理する、ＷＳＡ１０８により提供されるサービスに対応する要求を作成して、送信する。サービス要求に基づいて、ＷＳＡは、抽象ＡＰＩ１２４の実施、例えば、抽象ＡＰＩの実施１４４に対して特定プラットフォーム用コールを行うように抽象ＡＰＩ１２４を用いることが可能である。このように、ウェブサービスアプリケーションの開発者は、ウェブサービスを実行する基礎プラットフォームの複雑性を理解する必要なく、ウェブサービス自体の開発に注力することが可能である。それ故、ターゲットプラットフォームの知識を有するウェブサービスアプリケーション開発者以外の誰かが、対応する抽象ＡＰＩの実施を規定することが可能である。
【００１９】
クライアント１０２は、ＭＦＰにより提供される少なくとも１つのサービスを要求する処理に関連するアプリケーションである。クライアント１０２は、典型的には、最初の要求処理を支援するオペレーティングシステムと関連するアプリケーションである。クライアント１０２の１つの潜在的な目的は、ＳＯＡＰを“理解する”アプリケーションにより処理されるＳＯＡＰ要求に対する要求処理から特定プラットフォーム用手続きコールを変換することである。
【００２０】
例えば、要求処理はＭｉｃｒｏｓｏｆｔ  Ｗｏｒｄ（登録商標）と関連付けられることが可能であり、ＷＳＡ１０８はプリントサービスを提供することが可能である。クライアント１０２は、その場合、最初の要求処理を支援するオペレーティングシステムに関連するアプリケーションであることが可能である。クライアント１０２は、要求処理から送信される特定プラットフォーム用“プリントデータ”要求を受信する。クライアント１０２は、その場合、ＳＯＡＰメッセージを“理解する”ＷＳＡにより処理されることができるＳＯＡＰメッセージにおけるプリントデータ要求をエンコードする。
【００２１】
ＤＦＭ１０６は、発見要求、ロギング情報のための要求及び構成指示を受け入れることによりＭＦＰを表す。実施形態に従って、ＤＦＭ１０６は、少なくとも１つのウェブサービス規格（例えば、ＷＳ−Ｓｅｃｕｒｉｔｙ、ＷＳ−ＭｅｔａｄａｔａＥｘｃｈａｎｇｅ）により規定された少なくとも１つの機能を各々実施するルーチンの共有ライブラリを有する。このようにして、複数のウェブサービス規格が一度、実施され、それはＭＦＰにおいて実行される複数のウェブサービスアプリケーションの各々により供給されることが可能である。
【００２２】
ウェブサービスアプリケーション（ＷＳＡ）モジュール１０８は少なくとも１つのウェブサービスを提供し、ウェブサービスプロトコル及び技術、例えば、ＤＦＭ１０６により提供されるプロトコルに依存する。ＷＳＡ１０８はまた、図１の実線のボックスで示しているように、クライアント１０２からのイベントの要求に応答するＷＳ−Ｅｖｅｎｔｉｎｇモジュール１２２を有することが可能である。代替として、ＷＳ−Ｅｖｅｎｔｉｎｇモジュール１２２は、図１の実線のボックスで示しているように、ＷＳＡ１０８の外側に位置付けられることが可能である。何れの場合も、クライアント１０２は、ＷＳＡ１０８により提供されるサービスに関連するイベントに加入することが可能である。例えば、ＷＳＡ１０８はプリンティングアプリケーションであり、クライアント１０２が加入するイベントはＷＳＡに関連するＭＦＰがプリントジョブを終了するときである。従って、ジョブの終了時に、ＷＳＡ１０８は、プリントジョブが終了したことを示すイベントメッセージをクライアント１０２に送信する。ＷＳ−ＥｖｅｎｔｉｎｇをＷＳＡに統合することに関する追加の詳細については、下の節で説明する。
【００２３】
ＷＳＡ１０８はまた、特定プラットフォーム用コールが生成されることが可能である抽象ＡＰＩ（例えば、抽象ＡＰＩ１２４）を有することが可能である。抽象ＡＰＩは、関連ＷＳＡ１０８がＭＦＰにおいて少なくとも１つの機能を読み出すインタフェースを規定する。それ故、ＷＳＡ１０８の開発者は、ターゲットプラットフォームの基本的な複雑性を知っている必要はなく、その開発者が提供することを目的とする新しいサービスのみが分かるだけでよい。抽象ＡＰＩが、ウェブサービスアプリケーション開発者により規定されている場合、特定のプラットフォームのための抽象ＡＰＩの実行が規定される必要がある。他のプラットフォームにおいて実施される同様のＷＳＡ／同様の抽象ＡＰＩ、例えば、Ｌｉｎｕｘのために、異なる実施が規定されることが可能である。ウェブサービスアプリケーションのどの開発者も、その実施を規定することが可能である、又は、ターゲットプラットフォームの知識を有する他の誰かがその実施を規定することが可能である。
【００２４】
下のＷＳ−Ｅｖｅｎｔｉｎｇへの言及は、全体的に、イベンティング規格に適用されることが意図され、それ故、例えば、ＷＳ−Ｎｏｔｉｆｉｃａｔｉｏｎ等の他のイベント規格に適用されることがまた、意図されているが、それに限定されるものではない。従って、ＭＦＰは、ＷＳ−Ｅｖｅｎｔｉｎｇに代えて、ＷＳ−Ｎｏｔｉｆｉｃａｔｉｏｎを実施することが可能である、又は、ここでは、明示的に名前を挙げていない他のイベント規格を実施することが可能である。ＷＳ−Ｅｖｅｎｔｉｎｇへの言及は、排他的に、この規格に限定するように考慮される必要はない。
【００２５】
ＭＦＰのＷＳＡに複数のウェブサービス規格を提供する一方法は、単独のＭＦＰの位置、例えば、ＤＦＭ１０６において、ウェブサービス規格を実施することである。そのようにして、ウェブサービスが一旦、実施されると、ＭＦＰの全てのＷＳＡ１０８の間で共有される。しかしながら、ＤＦＭ１０６におけるＷＳ−Ｅｖｅｎｔｉｎｇモジュールの実施は、種々の理由のために問題がある。
【００２６】
ＷＳ−Ｅｖｅｎｔｉｎｇは、簡単なイベント加入及び通知サービスであるように最初にデザインされる。しかしながら、一部のＷＳＡは、そのような簡単なイベントサービス以上のものを要求する。それ故、イベント加入応答メッセージが要求しているクライアントに送信される前に、それらのＷＳＡ（スキャンサービスを提供する）がイベント加入要求の追加処理を実行するように、ＷＳ−Ｅｖｅｎｔｉｎｇが実行される必要がある。一部のイベント加入要求は対応するＷＳＡに対して特有である情報を含むため、そのような追加処理が必要である。
【００２７】
ＷＳ−ＥｖｅｎｔｉｎｇがＭＦＰのＤＦＭ１０６において実施される場合、ＤＦＭ１０６はＷＳＡ１０８の詳細について認識していないため、ＷＳＡ１０８とＤＦＭ１０６との間で付加的通信が行われる必要がある。それ故、ＷＳＡ１０８とＤＦＭ１０６との間の通信の複雑性は増し、そのことは、エラー及び少なくとも処理時間中の劣化をもたらす傾向を有する。クライアントが加入応答メッセージを受信しない場合、又はイベント加入要求に応じてエラーメッセージを受信する場合、ＭＦＰが認識される有用性はかなり低下する。
【００２８】
それ故、本発明の実施形態に従って、ＷＳ−Ｅｖｅｎｔｉｎｇモジュール１２２は、図１に示すように、ＭＦＰの少なくとも１つのＷＳＡ１０８に組み込まれる。この組み込まれた機能（以下、イベントマネージャという）は一般的なイベントの実施を与えるばかりでなく、そのイベントマネージャはまた、対応するＷＳＡ１０８の他の構成要素と密接に機能することが可能であり、その対応するＷＳＡ１０８は、それらの構成要素とイベントマネージャとの間の有効な双方向通信を可能にする。代替として、ＷＳ−Ｅｖｅｎｔｉｎｇモジュール１２２は、図１に破線で示しているように、ＷＳＡ１０８の外部で実施されるが、ＷＳＡ１０８と密に通信することができる。
【００２９】
図２は、システム１００のイベント構成要素の関係を示すブロック図であり、それらの一部は図１に示されている。クライアント１０２は、ＷＳＡ１０８にイベント加入要求を送信し、そのＷＳＡ１０８は、イベントマネージャ（ＥＭ）２０６として図２に示しているイベントマネージャと通信する。ＥＭ２０６は、イベント加入要求を処理して、クライアント１０２にイベント加入応答を送信するように、図１に示しているＷＳ−Ｅｖｅｎｔｉｎｇ特徴１２２を実施する。
【００３０】
ＥＭ２０６は、ＷＳＡ１０８におけるスレッド又はモジュールとして実施されることが可能である。後の時点で、装置２０８は、ＷＳＡ１０８の抽象レイヤ１２４にイベントの通知を送信し、その場合、その装置は、ＷＳＡ１０８にその通知を転送する。抽象レイヤ１２４は、例えば、別個のモジュール、又はＭＦＰの種々のプラットフォームとの通信に専用のスレッドとして実施されることが可能である。代替として、その装置２０８は、抽象レイヤ１２４にバイパスを付け、ＷＳＡ１０８に直接、その通知を送信することができる。その装置２０８は、例えば、少なくとも一部のイベントが生成されるターゲットプラットフォームであることが可能である。
【００３１】
ＷＳＡ１０８は、その場合、ＥＭ２０６に通知を転送し、そのＥＭ２０６は、ＷＳＡ１０８におけるモジュール又はスレッドとして実施されることが可能であるため、その通知の転送は比較的簡単な手法である。その時点で、ＥＭ２０６は通知を処理し、通知メッセージを作成し、クライアント１０２にそのメッセージを送信する。
【００３２】
図３は、実施形態に従って、図１及び２に示す他の構成要素と共に、ＷＳＡ１０８及び関連ＥＭ２０６によりどのようにイベント加入要求が処理されることが可能であるかについて、更に詳細に示している。図３においては、イベント全ては時系列で起こり、その場合、時間は上から下に経過するようになっている。
【００３３】
ステップ１においては、クライアント１０２は、イベント加入要求を作成し、ＷＳＡ１０８にその要求を送信する。ステップ２においては、ＷＳＡ１０８は、その加入要求をＥＭ２０６に転送する。ＷＳＡ１０８は、ＷＳ−Ｅｖｅｎｔｉｎｇ規格を認識していないため、加入要求に含まれる何れの必要な特定ＷＳＡ用データも検索することはできない。ＷＳＡ１０８がスキャンンサービスを提供する場合、そのような特定ＷＳＡ用データはスキャンジョブの目的であることが可能である。それ故、ＥＭ２０６は、加入要求から特定ＷＳＡ用データを検索し、それを処理のためにＷＳＡ１０８に送信する（ステップ３）。
【００３４】
ステップ３の前に、ＥＭ２０６は、イベント加入要求が適切に（即ち、ＷＳ−Ｅｖｅｎｉｎｇ規格に従って）転送されたかどうかを判定することが可能である。それが否定的である場合、ＷＳＡ１０８又はＥＭ２０６は、クライアント１０２に障害メッセージを直接、送信することが可能である。
【００３５】
ステップ４においては、ＷＳＡ１０８は、ＥＭ２０６がイベント加入応答を作成する前に、特定ＷＳＡ用データを前処理する。例えば、ＷＳＡ１０８がスキャンサービスを提供する場合、クライアント１０２からのイベント加入要求は、スキャンされた文書を送信すべき宛先を確認する。従って、ＷＳＡ１０８は、特定ＷＳＡ用データにおいて指定された宛先を管理する宛先マネージャを有することが可能である。この前処理中、ＷＳＡ１０８が、宛先が無効であると判定した（例えば、宛先マネージャを用いて）場合、そのＷＳＡ１０８は、エラーについてクライアント１０２に通知するように、クライアント１０２に直接、障害メッセージを送信する（ステップ５において）ことが可能であり、その後、イベント加入要求の処理は中止する。従って、ＷＳＡ１０８とＥＭ２０６との間の付加的な通信は必要なく、そのことは、ＷＳＡにおいてＷＳ−Ｅｖｅｎｔｉｎｇモジュール１２２を実施する有利点の１つである。
【００３６】
宛先が無効である一例は、イベント加入要求において宛先の閾値を上回ることである。
【００３７】
代替として、ステップ４においては、ＷＳＡ１０８は、特定ＷＳＡ用データを認識しないことが可能である。その結果、ＷＳＡ１０８は、エラーをクライアント１０２に通知するように、クライアントに直接、障害メッセージを送信する（ステップ５において）ことが可能である。
【００３８】
ステップ４における前処理の他の実施例はまた、スキャニングコンテキストにおけるものである。ＷＳＡ１０８は、セキュリティ目的のために、宛先のアドレスを変更するように特定ＷＳＡ用データにおいて指定された宛先をマッピングすることが可能である。代替の宛先アドレスがＥＭ２０６に送信され、ＥＭ２０６は、クライアント１０２に送信されるイベント加入要求に代替の宛先アドレスを付加する。
【００３９】
ＷＳＡ１０８からＥＭ２０６（例えば、代替の宛先アドレス）に渡されたデータは“ブラックボックス”として渡されるものであり、ＥＭ２０６は、データのコンテンツについての知識を有さず、データにおいて何れの処理も実行しない。ＥＭ２０６は、イベント加入応答における固定位置に、現状のままのデータを容易に挿入する。換言すれば、ＷＳＡ１０８及びＥＭ２０６は、実際には、互いのデータについての知識を有さず、そのことは、モジュレータのまま維持され且つ互いに独立するように、ＷＳＡにおけるイベントマネージャを組み込むことにおいて重要である。
【００４０】
同様に、ＥＭ２０６が要求以外の特定ＷＳＡ用データを抽出するとき、ＥＭ２０６は、データの内容について知識を有することなく、要求における固定点において、データを容易に検索することができる。
【００４１】
ステップ５において、障害メッセージが送信されない場合、ＷＳＡ１０８は、イベント加入応答メッセージ（“加入応答”）に含まれるように、特定ＷＳＡ用データを送信する。段階６において、ＥＭ２０６は、イベント加入応答が成功裏に行われたことをクライアント１０２に通知するクライアント１０２に加入応答を送信する。ＷＳＡ１０８は、ＷＳ−Ｅｖｅｎｔｉｎｇ規格について知識を有しないため、ＥＭ２０６は、加入応答を生成する責任を担う。
【００４２】
ステップ７において、ＥＭ２０６は、後処理のためにＷＳＡ１０８にデータを送信し、その後、ＷＳＡ１０８はデータを後処理する（ステップ８）ことが可能である。例えば、スキャンの実施例においては、ＷＳＡ１０８は、将来の使用のためにローカルメモリの宛先リストに対する加入要求において指定された宛先を付加する及び保存する（例えば、宛先マネージャを用いて）ことが可能である。
【００４３】
ステップ８の後処理についての一理由は、ＥＭ２０６が加入要求を作成するとき、ＷＳＡ１０８がＥＭ２０６により生成されたデータを利用する必要があることである。例えば、ＷＳＡ１０８は、受け入れられた加入を一意に識別するようにＥＭ２０６が生成する加入識別子を把握する必要がある。それ故、後処理は前処理と組み合わされる必要はない。しかしながら、これは異常な場合である。ＷＳＡ１０８は、一般に、イベンティングについてのいずれかの知識を有さず、それに代えて、例えば、ＷＳ−Ｅｖｅｎｔｉｎｇモジュール１２２を含む他のモジュールにその責任を委ねる。
【００４４】
ステップ８の後処理についての他の理由は、不必要な処理ステップを回避することである。前処理（ステップ４）中、ＥＭ２０６は、妥当な場合、特定ＷＳＡ用データを抽出する必要がある。ＷＳ−Ｅｖｅｎｔｉｎｇ規格に基づいて、ＥＭ２０６がイベント加入要求を有効にすることは任意である。ＥＭ２０６が、イベント加入要求が加入応答メッセージの作成前に無効であると判定する場合、ＥＭ２０６は、そのエラーについて、ＷＳＡ１０８に通知し、それ故、ＷＳＡ１０８は、後処理ステップを実行する必要はない。
【００４５】
イベントマネージャ加入処理からの前処理及び後処理の分離することにより、イベントマネージャ及びＷＳＡのモジュール性を維持しながら、柔軟性及び拡張性を最大化するようになる。このようにして、イベントマネージャも、ＷＳＡも、互いのデータスキーム又はビジネスロジックを理解する必要はない。
【００４６】
ステップ９において、装置２０８は、イベントを生成し、抽象レイヤ１２４にそのイベントの表示を送信する。ステップ１０においては、抽象レイヤ１２４はＷＳＡ１０８にイベント表示を転送し、また、特定ＷＳＡ用通知本体を生成し、それをイベントマネージャ２０６に渡す（ステップ１１）。一実施形態においては、ＷＳＡ１０８は、抽象レイヤ１２４からそのようなイベント表示を受信し、イベントシンクにイベント通知を供給するイベント処理スレッドを有する。このようにして、イベント加入要求を処理するタスクは、生成されたイベントを処理し、イベント通知を供給するタスクから分離されることが可能である。従って、後続のステップは、代替として、少なくとも１つのイベント処理スレッドにより実行されることが可能である。
【００４７】
ステップ１２において、ＥＭ２０６は、通知本体に基づいて適切なイベント通知メッセージを作成し、イベントシンクにそのメッセージを送信し、そのイベントシンクはクライアント１０２を有し、そしてそのクライアント１０２についての何れかの他のクライアントがイベントに加入していることが可能である。ステップ１３において、ＥＭ２０６は、特定のイベント（例えば、適切なクライアントがイベントについて通知された）の供給状態を更新する。
【００４８】
ステップ１４において、イベント加入期限が切れている又は加入していない場合、ＥＭ２０６はＷＳＡ１０８に通知する。特定のイベント加入が期限切れ又は加入していないことのために削除されているとき、一部のＷＳＡは特定の動作を行う必要がある。例えば、クライアントレジスタが、イベント加入要求により宛先をスキャンし、その加入が削除される場合、スキャナＷＳＡは、登録されているスキャン宛先を削除する必要がある。
【００４９】
ＷＳ−ＥｖｅｎｔｉｎｇモジュールのＷＳＡ１０８への組み込みは、装置設備マネージャ（ＤＦＭ）においてＷＳ−Ｅｖｅｎｔｉｎｇを実施すること等の、他の有効な方法における多くの有利点を与えることが可能である。一の有利点は、大量のデータがアプリケーション境界を越えて渡される必要がないことである。他の有利点は、アプリケーション間の通信エラーの可能性が、少なくともＷＳ−Ｅｖｅｎｔｉｎｇコンテキストにおいては排除されていることである。また、ＷＳ−ＥｖｅｎｔｉｎｇがＷＳＡ１０８内に組み込まれている場合、ＥＭ２０６がイベント加入要求から特定ＷＳＡ用データを抽出して応答すること、及びイベントマネージャに特定ＷＳＡ用データを渡すことは、比較的簡単である。更に、ＷＳＡ１０８は、イベントマネージャの他の特徴に対する制御を有する。例えば、ＷＳＡ１０８は、加入除去のために指定スレッドを生成するイベントマネージャを有することに代えて、ＷＳＡがアイドル状態にあるとき、期限切れの加入を除去するように、イベントマネージャの機能を呼び出すことができる。
【００５０】
ＷＳ−ＥｖｅｎｔｉｎｇをＷＳＡに組み込むことはまた、ＷＳＡ及び関連イベントマネージャのモジュール性を維持する。そのようなモジュール性は、簡単なデザイン、並びにＷＳＡ及びイベントマネージャの更なる更新を容易にする。最終的には、ＷＳＡは、イベント通知の供給状況についてのイベントマネージャからのタイムリーな更新を受信することを可能にする。
【００５１】
実施形態に従って、装置であって、例えば、ＭＦＰからのイベント通知を減少させるための方法が与えられるが、それに限定されるものではない。このことを容易にするように、図４は、少なくとも３つのフィールド、即ち、加入ＩＤ４０４、クライアントＩＰアドレス４０８及びジョブＩＤ４１２により成るテーブル４００を示している。テーブル４００は他のサイズを有し、他のフォーマットを有することが可能である。従って、図４に示す構成は単なる例示を目的とするものであり、何れかの状況を限定するとみなされるべきでない。
【００５２】
加入ＩＤフィールド４０４は、受け入れられた加入を一意に確認するように、ＥＭ２０６が生成する加入のＩＤである。クライアントＩＰアドレスフィールド４０８は、特定のクライアントのＩＰアドレスを保持し、そのＩＰアドレスは特定の加入ＩＤが割り当てられているクライアントを識別する。ジョブＩＤフィールド４１２は、現在実行されている特定のジョブのＩＤである又はＭＦＰにより終了されたものである。
【００５３】
単に例示目的で、図４のテーブル４００においては、３つのエンティティのみを示している。テーブル４００は、図４においける下の部分の矢印により暗示されているように、図４に示しているものよりかなり大きくなることが可能であることが予測できる。
【００５４】
図５は、どのようにテーブル４００が構築され、ポピュレートされ、そして利用されるかを示すフローチャートである。先ず、ステップ５０４において、本発明は、通知を減少させるためのフラグが可能であるかどうかを理解するように、Ｏ／Ｓプラットフォーム１４０を調べる。通知の減少が可能でない、又は、特定のプラットフォームが通知の削減を全く支援しない例が存在する。従って、このフラグは、必ずしも有効でない。
【００５５】
通知減少フラグが有効でない場合、ステップ５０８に示すように、通知減少モジュール（ＮＲＭ）がテーブル４００についてのデータ構造を作成する。この時点で、テーブル４００は、何れのデータによっても未だにポピュレートされていないが、データ構造自体はメモリに保存されている。次に、ＭＦＰは、そのサービスを受けることを所望する種々のクライアント１０２からの加入要求を待つ。それらの加入要求が発生するとき。通知減少モジュールは、クライアントの加入ＩＤを特定のＩＤアドレスと関連付け、ステップ５１２に示すように、テーブル４００における特定のエントリの三分の二をポピュレートする。
【００５６】
通知減少モジュールは、その場合、種々のクライアント１０２からのジョブ要求を待つ。ＭＦＰによるサービスについての要求が発生したとき、ステップ５１６に示すように、そのサービスについてのジョブＩＤが生成される。その場合、同時に、通知減少モジュールはそのジョブＩＤをクライアントＩＰアドレスと関連付け、テーブル４００を更新する。
【００５７】
通知減少モジュールは、その場合、ジョブに関連するイベント又は発生するジョブを待つ。特定のジョブに関連するイベントが発生したとき、ステップ５２０に示すように、通知減少モジュールはＷＳＡ１０８からジョブＩＤを受信する。通知減少モジュールは、その場合、イベントをもたらしたジョブＩＤについて、テーブル４００を調べる。通知減少モジュールがジョブＩＤを見つけることができない場合、それは、イベントを発生させたジョブをもたらしたクライアントは何れのジョブのイベント加入もしていないことを意味するため、通知は送信されない。しかしながら、通知減少モジュールがジョブＩＤを発見した場合、ステップ５２４に示しているように、その通知減少モジュールは、そのジョブＩＤに関連付けられる加入ＩＤをＷＳ−Ｅｖｅｎｔｉｎｇモジュール１２２に渡す。ＷＳ−Ｅｖｅｎｔｉｎｇモジュール１２２は、その場合、ステップ５２８に示しているように、通知を作成し、ＮＲＭにより抽出されて渡された加入ＩＤに基づいて、特定の加入ＩＤと関連付けられたクライアントのみに対して送信される。このことは、そのジョブをもたらし、その種類のイベントに加入し、それにより、通知の減少を達成することができるクライアントのみに対して送信されるジョブ関連イベント通知が得られる。
【００５８】
単独のクライアントは複数の加入ＩＤを有することが可能であり、それ故、そのクライアントはＭＦＰの多くの異なる機能を用いることが可能であることに留意する必要がある。そのような場合、ひとりのクライアントが複数の加入要求を送信することができるため、テーブル４００は、同じＩＰアドレスを全てが共有する複数の異なる加入ＩＤを有することが可能である。
【００５９】
図６は、図４及び５における情報並びに本発明の他の特徴の一部を明確にするように意図されたシーケンス図である。図６における種々のステップについての役割は、クライアント１０２、システム１００及びプラットフォーム１４０間に分配される。図６においては、経時的に、上から下に時間が経過するように、種々のステップ及び役割が配置されている。
【００６０】
図６に示すシーケンスは、基本的には、６つの主要部分を有する。第１に、通知減少が可能かどうかを判定する。それが肯定的である場合、第２に、テーブル４００を作成する。第３に、加入者に対して注意を払い、テーブル４００における加入ＩＤ及びＩＰアドレスをポピュレートする。第４に、ジョブ要求に対して注意を払い、テーブル４００においてジョブＩＤがクライアントＩＰアドレスと関連付けられる。
【００６１】
この時点で、通知が減少したテーブル４００に記入される。第５ステップにおいては、特定のジョブＩＤに関連するイベント通知について注意を払う。イベント通知が発生した場合、第６の最終ステップにおいては、加入ＩＤに基づいて、通知が適切なクライアントのみに対して送信されることを確実にするように、テーブル４００を用いる。
【００６２】
更に変形することができる。上記のように、テーブル４００におけるＩＰアドレスフィールドは、加入要求したクライアントを有する。しかしながら、他のシナリオが存在する。例えば、クライアントＢの代わりに発生したイベント全てにクライアントＡが加入し、従って、クライアントＢがイベントシンクであることを示す例が存在し得る。このことは、通知（ＮｏｔｉｆｙＴｏ）フィールドがクライアントＢのＩＰアドレスを保持し、それ故、クライアントＢはどのイベント通知も受信することを意味する。
【００６３】
一方、クライアントＢがＷＳＡ１０８にジョブ生成要求を送信する場合について考える。そのような場合、テーブル４００が３つのフィールド（イベント加入者（クライアントＡ）ＩＰアドレス、加入ＩＤ及びジョブＩＤ）のみを有する場合、テーブル４００においては何ら適合するエントリは存在しない。これは、クライアントＡがその加入に関連付けられていて、クライアントＢはそのジョブに関連付けられているためである。それ故、どちらのクライアントも、イベントについて通知されない。
【００６４】
これに対処するように、第４のフィールドがテーブル４００に加えられることが可能である。テーブル４００が加入者（クライアントＡ）ＩＰアドレス、ＮｏｔｉｆｙＴｏ（クライアントＢ）ＩＰアドレス、加入ＩＤ及びジョブＩＤを保持しているとき、ジョブ要求者のＩＰアドレスは、加入者ＩＰアドレス又はＮｏｔｉｆｙＴｏ  ＩＰアドレスと比較される。上記の例を用いる場合、ジョブ要求者はクライアントＢであり、そのクライアントＢはＮｏｔｉｆｙＴｏアドレスに適合し、それ故、そのエントリはテーブル４００に保存される。
【００６５】
他の種類の通知減少機構がまた、存在し、それについては、図７乃至１０に示されている。この第２の実施形態については、スキャン有効イベント（ＳｃａｎＡｖａｉｌａｂｌｅＥｖｅｎｔ）特徴を用いて説明することができるが、ＳｃａｎＡｖａｉｌａｂｌｅＥｖｅｎｔに関連しない他の特徴についてもまた、実施されることが可能である。図７に示すように、典型的なスキャナ操作パネル７００は、スキャン画像をどこに送信すべきかをユーザが指定することを可能にする。パネル７００から、スキャナが複数の宛先に接続されることが可能であり、それらの宛先の各々はスキャン宛先表示名を有し、それらの２つ（ＪｏｈｎのＰＣ、ＪａｎｅのＰＣ）が表示されている。宛先表示名は、スキャン宛先のユーザ認識可能形式であるように意図されている。
【００６６】
クライアント１０２はＳｃａｎＡｖａｉｌａｂｌｅＥｖｅｎｔ全てに加入することができ、関係のないイベントでさえ受信される可能性があることに留意する必要がある。このことは、行いの悪いクライアント１０２がそのクライアントに関係のない種々のイベントについて察知することが可能であるために、種々のセキュリティホールを課す。従って、Ｊａｎｅ若しくは一部の又は他の悪質なクライアントは、Ｊｏｈｎがまさに機密文書を受信しつつあることを学習することが可能である。そのようなイベントは、ある環境下では、セキュリティに関する違反とみなされる可能性がある。上記のように、ネットワークトラフィックを減少させることがまた、所望されている。第２の実施形態においては、下で説明するように、上記の及び他の問題点に対処することができる。
【００６７】
第２実施形態がどのように機能するかを理解するためには、加入処理を理解することが重要である。加入要求は、クライアント１０２からＷＳＡ１０８に送信される。第２実施形態においては、例えば、ＳｃａｎＡｖａｉｌａｂｌｅＥｖｅｎｔに対する加入要求は、ＷＳ−Ｅｖｅｎｔｉｎｇ規格により規定されるフィールドに加えて、スキャン宛先登録関連フィールド（例えば、スキャン宛先表示名）を含む。加入することにより、特定のジョブの状態、ＭＦＰのスキャナ／プリンタ部分の状態及びＳｃａｎＡｖａｉｌａｂｌｅＥｖｅｎｔ（スキャナ部分のみ）の通知等のそのクライアントにとって関心があるイベントをクライアントが認識することを可能にする。
【００６８】
例として、宛先表示名フィールドが、図７のパネル７００に示されている。そのＮｏｔｉｆｙＴｏフィールド又はイベントシンクは、ＭＦＰにより送信される種々の通知を受信するように用いられる。
【００６９】
図８に示すように、スキャン宛先全てがテーブル８００に記憶され、そのテーブルは、宛先表示名８０４（ＪｏｈｎのＰＣ、ＪａｎｅのＰＣ）ばかりでなく、加入ＩＤフィールド８０８もまた、保持する。上記のように、加入要求メッセージは、クライアントコンテキスト又は宛先表示名８０４等の、少なくともスキャン宛先登録情報を有する。
【００７０】
図７及び８の機構におけるイベントの特定の順序を図９のフローチャートに示しているが、破線で示されている発見ステップ９０４及びインストールステップ９０８等の特定部分は任意である。一部のクライアント１０２は、ステップ９０４及び９０８を用いることが可能である一方、他のクライアント１０２は、何れの発見処理及びインストール処理を用いずに、加入要求を直接、送信することが可能である。
【００７１】
従って、ステップ９０４においては、適切である場合には、クライアントはウェブサービス可能ＭＦＰを発見する。次に、ステップ９０８において、そのクライアントを操作するユーザがＭＦＰをインストールすることを所望するかどうかに関する判定が行われる。
【００７２】
ステップ９１６においては、クライアントは、ＳｃａｎＡｖａｉｌａｂｌｅＥｖｅｎｔに加入するように加入要求を送信する。ＷＳＡが、ステップ９２０において、加入要求を受信し、有効であることを確認したとき、ＷＳＡは、加入応答メッセージがクライアントに戻るように送信する。ステップ９２４においては、ＷＳＡは、動作可能なパネル７００に登録されているスキャン宛先全てを示す。
【００７３】
図７及び８の通知機構は、ここでは、通知テーブル８００に記入される十分な情報を有する。上記のように、このテーブル８００は、常に少なくとも２つのフィールド、即ち、宛先表示名８０４及び加入ＩＤ８０８を有する。
【００７４】
図４乃至６の実施形態においては、ジョブイベント加入要求は、生成されるようになっているジョブＩＤのような何れの特定なジョブ情報も含まない。それ故、テーブル４００においては、クライアントＩＰアドレスは、ジョブ生成要求に応じて生成されるジョブＩＤとジョブイベント加入を関連付ける相関フィールドになる。
【００７５】
逆に、図７乃至１０の実施形態においては、ＳｃａｎＡｖａｉｌａｂｌｅＥｖｅｎｔ加入要求は、スキャン宛先登録情報を既に有し、その要求は、テーブル４００と関連付けられたジョブイベント加入要求とは異なる。従って、テーブル８００は、スキャン宛先表示名と加入ＩＤを関連付ける付加的なクライアントＩＰアドレスフィールドを必要としない。
【００７６】
ステップ９２８においては、ユーザは、スキャン宛先を選択し、オリジナルを取り込み、そして‘開始’ボタンを押す。ステップ９３２においては、ＷＳＡ１０８はＳｃａｎＡｖａｉｌａｂｌｅＥｖｅｎｔを生成し、宛先表示名をＳｃａｎＡｖａｉｌａｂｌｅＥｖｅｎｔ通知減少モジュールに渡す。ＳｃａｎＡｖａｉｌａｂｌｅＥｖｅｎｔ通知減少モジュールは、選択された宛先表示名に基づいて、適合した加入ＩＤのためにテーブル８００を調べる。適合するエントリが発見された場合、ＷＳＡ１０８はＳｃａｎＡｖａｉｌａｂｌｅＥｖｅｎｔメッセージを作成し、ＷＳ−Ｅｖｅｎｔｉｎｇモジュールにイベント本体及び検索された加入ＩＤを渡し、その加入要求において規定されたイベントシンクに通知を順次、送信する。ステップ９３６においては、ＷＳ−Ｅｖｅｎｔｉｎｇモジュール１２２は、検索された加入ＩＤと適合されたクライアントのみに、ＳｃａｎＡｖａｉｌａｂｌｅＥｖｅｎｔを送信する。
【００７７】
図７乃至１０に示す実施形態の１つの潜在的な付加特徴は、中央スキャナインストーラモジュールの存在である。一部のクライアント１０２は、同様の表示名を有するスキャン宛先を登録することを所望する可能性があり、それ故、テーブル８００にクライアントＩＰアドレスを付加することは付加フィルタリング基準を可能にする。従って、イベント加入者ＩＰアドレス１００４がテーブル８００に付加され、それにより、図１０のテーブル１０００が得られる。
【００７８】
図７乃至１０の実施形態及び図１乃至６の実施形態の両方は、加入ＩＤを用いるテーブルを有する。テーブル４００は、相関フィールドとして用いられるジョブＩＤフィールドにどのように記入するかを判定するように、クライアントＩＰアドレスを用いる。一方、テーブル８００は、相関フィールドとして宛先表示名８０４を用いる。
【００７９】
図１乃至１０に示す方法は、イベンティング能力を支援する何れかのＷＳＡに拡張されるが、ここで示すまさにシステム１００でないことが可能である。上記の方法は、ジョブ関連イベントを生成し、送信された通知のどのフィルタリング／減少が実行されたかに基づいて、インデキシングパラメータとイベント加入を関連付けることができる。
【００８０】
更に、通知減少特徴のオン−オフ設定は、ケーブル又はネットワークを介してＭＦＰに接続されたウェブＵＩ又はコンソールＵＩ、又は何れかの他の種類の管理構成インタフェースから制御されることが可能である。
【００８１】
ここで説明している方法は、何れかの種類のコンピューティングプラットフォーム又はアーキテクチャにおいて実施されることが可能である。図１１は、本発明の実施形態が実施されることが可能であるコンピュータシステム１１００を示すブロック図である。コンピュータシステム１１００は、情報を通信するバス１１０２又は他の通信機構と、情報を処理するバス１１０２に結合されている処理器１１０４とを有する。コンピュータシステム１１００はまた、処理器１１０４により実行される命令及び情報を記憶するバス１１０２に結合されているランダムアクセスメモリ（ＲＡＭ）又は他の動的記憶装置等の主メモリ１１０６を有する。主メモリ１１０６はまた、処理器１１０４により実行されるようになっている命令の実行中、一時的変数又は他の中間的情報を記憶するために用いられることが可能である。コンピュータシステム１１００は、処理器１１０４についての静的情報及び命令を記憶するために、バス１１０２に結合されている読み出し専用メモリ（ＲＯＭ）１１０８又は他の静的記憶装置を更に有する。磁気ディスク又は光ディスク等の記憶装置１１１０が、情報及び命令を記憶するように備えられ、そしてバス１１０２に結合されている。
【００８２】
コンピュータシステム１１００は、コンピュータユーザに情報を表示するように、陰極線管（ＣＲＴ）等のディスプレイ１１１２にバス１１０２を介して結合される。英数字及び他のキーを有する入力装置１１１４は、処理器１１０４に情報及びコマンド選択を通信するために、バス１１０２に結合されている。処理器１１０４に方向付け情報及びコマンド選択を通信するために並びにディスプレイ１１１２におけるカーソルの移動を制御するように、他の種類のユーザ入力装置、例えば、マウス、トラックボール又はカーソル方向付けキー等のカーソル制御器１１１６である。この入力装置は、典型的には、２つの軸、即ち、第１（例えば、ｘ）軸及び第２（例えば、ｙ）軸において２つの自由度を有し、それにより、装置が面内で位置を定めることを可能にする。
【００８３】
本発明は、ここで説明している技術を実施するためにコンピュータシステム１１００を用いることに関する。本発明の一実施形態に従って、それらの技術は、主メモリ１１０６に含まれる少なくとも１つの命令の少なくとも１つのシーケンスを実行する処理器１１０４に応じて、コンピュータシステム１１００により実行される。そのような命令は、記憶装置１１１０等の他のコンピュータ読み出し可能媒体から主メモリ１１０６に読み出されることが可能である。主メモリ１１０６に含まれる命令のシーケンスの実行は、ここで説明している処理ステップを処理器１１０４が実行するようにする。代替の実施形態においては、ハードワイヤード回路が、本発明を実施するようにソフトウェアの命令に代えて又はその命令と組み合わせて用いられることが可能である。従って、本発明の実施形態は、ハードウェア回路及びソフトウェアの何れかの特定の組み合わせに限定されるものではない。
【００８４】
ここで用いている用語“コンピュータ読み出し可能媒体”とは、機械が特定の様式で動作するようにするデータの供給に関係する何れかの媒体のことをいう。コンピュータシステム１１００を用いて実施される実施形態においては、種々のコンピュータ読み出し可能媒体が、例えば、処理器１１０４を実行するための命令の供給において関与する。そのような媒体には、不揮発性媒体及び揮発性媒体を含む多くの方式があるが、それらに限定されるものではない。不揮発性媒体には、例えば、記憶装置１１１０等の光ディスク又は磁気ディスクがある。揮発性媒体には、主メモリ１１０６等の動的メモリがある。
【００８５】
コンピュータ読み出し可能媒体の一般的な様式には、例えば、フロッピー（登録商標）ディスク、フレキシブルディスク、ハードディスク、磁気ディスク、何れかの他の磁気媒体、ＣＤ−ＲＯＭ、何れかの他の光媒体、ＲＡＭ、ＰＲＯＭ、ＥＰＲＯＭ、フラッシュＥＰＲＯＭ、何れかの他のメモリチップ又はカートリッジ、又はコンピュータが読み出される何れかの他の媒体がある。
【００８６】
コンピュータ読み出し可能媒体の種々の様式は、処理器を実行するための少なくとも１つの命令の少なくとも１つのシーケンスの担持に関与する。例えば、遠隔コンピュータの磁気ディスクにおいて命令は、初期に担持されることが可能である。遠隔コンピュータは、動的メモリに命令をロードし、モデムを用いて電話回線において命令を送信することが可能である。コンピュータシステム１１００に局在するモデムは、電話回線においてデータを受信し、データを赤外信号に変換するように赤外変換器を用いることが可能である。赤外検出器は、赤外信号に担持されたデータを受け入れ、バス１１０２にそのデータを位置付ける。バス１１０２は、処理器１１０４が命令を検索して、実行する主メモリ１１０６にデータを搬送する。主メモリ１１０６により受信された命令は、処理器１１０４による実行の前後に、記憶装置１１１０において任意に記憶されることが可能である。
【００８７】
コンピュータシステム１１００はまた、バス１１０２に結合されている通信インタフェース１１１８を有する。通信インタフェース１１１８は、ローカルネットワーク１１２２に結合されているネットワークリンク１１２０に結合する双方向データ通信を与える。例えば、通信インタフェース１１１８は、対応する種類の電話回線へのデータ通信接続を与えるように、ＩＳＤＮ（Ｉｎｔｅｇｒａｔｅｄ  Ｓｅｒｖｉｃｅｓ  Ｄｉｇｉｔａｌ  Ｎｅｔｗｏｒｋ）カード又はモデムであることが可能である。他の実施例としては、通信インタフェース１１１８は、対応ローカルエリアネットワーク（ＬＡＮ）へのデータ通信接続を与えるように、ＬＡＮカードであることが可能である。無線リンクがまた、実施されることが可能である。何れのそのような実施においても、通信インタフェース１１１８は、種々の種類の情報を表すディジタルデータストリームを担持する電気信号、電磁信号又は光信号を送受信する。
【００８８】
ネットワークリンク１１２０は、典型的には、少なくとも１つのネットワークを介して他のデータ装置にデータ通信を供給する。例えば、ネットワークリンク１１２０は、インターネットサービスプロバイダ（ＩＳＰ）１１２６により操作されるホストコンピュータ１１２４又はデータ装置にローカルネットワーク１１２２を介して接続することが可能である。ＩＳＰ１１２６はまた、現在、一般に“インターネット”１１２８といわれる世界規模のパケットデータ通信ネットワークを介してデータ通信サービスを与える。ローカルネットワーク１１２２及びインターネット１１２８の両方は、ディジタルデータストリームを担持する電気信号、電磁信号又は光信号を用いる。種々のネットワークを介する信号、ネットワークリンク１１２０における信号及び通信インタフェース１１１８を介する信号は、コンピュータシステムに又はコンピュータシステムからディジタルデータを搬送し、例えば、情報を搬送する搬送波を構成する。
【００８９】
コンピュータシステム１１００は、ネットワーク、ネットワークリンク１１２０及び通信インタフェース１１１８を介して、プログラムコードを含む受信データ及びメッセージを送信することができる。インターネットの例においては、サーバ１１３０は、インターネット１１２８、ＩＳＰ１１２６、ローカルネットワーク１１２２及び通信インタフェース１１１８を介して、アプリケーションプログラムのために要求されるコードを送信することが可能である。
【００９０】
受信されたコードは、それが受信されるとき、及び／又は、後の実行のために、記憶装置１１１０、又は他の不揮発性記憶装置に記憶されるときに、処理器１１０４により実行されることが可能である。このように、コンピュータシステム１１００は、担持波の形でアプリケーションコードを得ることが可能である。
【００９１】
この明細書においては、本発明の実施形態については、実施例毎に変わる複数の具体的な詳細を参照して説明している。従って、本発明が何であるかについて、及び何を本発明として本発明者が意図しているかについての唯一の且つ排他的なものは、本出願により与えられる特許請求の範囲に記載され、本出願における明細書から特許請求の範囲は由来する。請求項に記載されている用語についてここで明確に示されている何れの定義も、請求項で用いているそれらの用語の意味を定めるものである。従って、請求項に明確に列挙されていない要素、性質、特徴、有利点又は属性は、何れにしてもそのような請求項の範囲を限定するものではない。従って、明細書及び図面は、例示であるとみなされ、限定的なものではない。
【図面の簡単な説明】
【００９２】
【図１】本発明の実施形態に従った、ＭＦＰとの通信を処理する例示としてのシステムを示すブロック図である。
【図２】本発明の実施形態に従った、ＷＳＡ及びそれが関連するイベントマネージャによりどのようにイベント加入要求が処理されるかを示すバルーン図である。
【図３】本発明の実施形態に従った、ＭＦＰのウェブサービスアプリケーション（ＷＳＡ）において実行することが可能である種々のスレッドを示すシーケンス図である。
【図４】本発明の実施形態に従った、加入ＩＤをジョブＩＤと関連付けるために構築されることが可能であるデータテーブルの例である。
【図５】本発明の実施形態に従ったフロー図である。
【図６】図５に示す実施形態に従ったシーケンス図である。
【図７】本発明の実施形態に従った動作パネルディスプレイの部分図である。
【図８】図７に示す実施形態に従った例示としてのフィルタリングデータテーブルである。
【図９】図７及び８に示す実施形態に従ったフロー図である。
【図１０】図７乃至９に示す実施形態に従ったデータテーブルである。
【図１１】本発明の実施形態が実施されることが可能であるコンピュータシステムを示すブロック図である。
【符号の説明】
【００９３】
１００    システム
１０２    クライアント
１０４    アドミニストレータ
１０６    装置設備マネージャ（ＤＦＭ）
１０８    ＷＳＡ
１１０    ウェブサービス装置（ＷＳＤ）マネージャ
１２２    ＷＳ−Ｅｖｅｎｔｉｎｇモジュール
１２４    抽象ＡＰＩ（又は、抽象レイヤ）
１４０    Ｏ／Ｓプラットフォーム
２０６    イベントマネージャ（ＥＭ）
２０８    装置
４００    テーブル
４０４    加入ＩＤ
４０８    クライアントＩＰアドレス
４１２    ジョブＩＤ
７００    スキャナ操作パネル
８００    通知テーブル
８０４    宛先表示名
８０８    加入ＩＤフィールド
１０００  テーブル
１００４  イベント加入者ＩＰアドレス
１１００  コンピュータシステム
１１０２  バス
１１０４  処理器
１１０６  主メモリ
１１０８  読み出し専用メモリ（ＲＯＭ）
１１１０  記憶装置
１１１２  ディスプレイ
１１１４  入力装置
１１１６  カーソル制御器
１１１８  通信インタフェース
１１２０  ネットワークリンク
１１２２  ローカルネットワーク
１１２４  ホストコンピュータ
１１２６  インターネットサービスプロバイダ（ＩＳＰ）
１１２８  インターネット
１１３０  サーバ
【図１】
2009087344.tif 000003
【図２】
2009087344.tif 000004
【図３】
2009087344.tif 000005
【図４】
2009087344.tif 000006
【図５】
2009087344.tif 000007
【図６】
2009087344.tif 000008
【図７】
2009087344.tif 000009
【図８】
2009087344.tif 000010
【図９】
2009087344.tif 000011
【図１０】
2009087344.tif 000012
【図１１】
2009087344.tif 000013