2026-127455 システムおよびシステムの制御方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】

(43)【公開日】

(54)【発明の名称】システムおよびシステムの制御方法

(51)【国際特許分類】

   

   

【ＦＩ】

【審査請求】未請求

【請求項の数】7

【出願形態】

(21)【出願番号】

(22)【出願日】

(71)【出願人】

【識別番号】000001007

【氏名又は名称】キヤノン株式会社

(74)【代理人】

【識別番号】100114775

【弁理士】

【氏名又は名称】高岡 亮一

(74)【代理人】

【識別番号】100121511

【弁理士】

【氏名又は名称】小田 直

(74)【代理人】

【識別番号】100208580

【弁理士】

【氏名又は名称】三好 玲奈

(72)【発明者】

【氏名】鈴木 貴文

【テーマコード（参考）】

【Ｆターム（参考）】

2C061AP01

2C061AP07

2C061HJ08

2C061HK11

2C061HK19

2C061HN05

2C061HN15

2C061HP00

(57)【要約】      （修正有）

【課題】対応優先度の高いイベント通知を優先して処理できるシステムを提供する。
【解決手段】サービスに対応する通知実行アプリを有する画像形成装置と、画像形成装置に対するイベント通知を管理する通知管理サーバとを含むシステムは、ポーリングが高頻度である場合に、通知管理サーバから受信したイベント通知が対応優先度の高いイベント通知であるか判断し、対応優先度の高いイベント通知である場合にイベント通知に対応するアプリにイベント通知の処理を要求し、対応優先度の高いイベント通知でない場合にはイベント通知の処理を要求しない通知管理処理を行う通知管理アプリと、イベント通知の処理を実行する通知実行アプリと、を有し、通知管理アプリは、イベント通知に含まれる識別情報と、ポーリングの頻度の変更要求を行った通知実行アプリを示す識別情報が一致する場合に、イベント通知が対応優先度の高いイベント通知であると判断する。
【選択図】図６

【特許請求の範囲】

【請求項】

サービスに対応するアプリケーションを有する画像形成装置と、前記サービスからの前記画像形成装置に対するイベント通知を管理する通知管理サーバとを含むシステムであって、
前記画像形成装置は、
ポーリングにより前記通知管理サーバに対してイベント通知要求を行い、前記通知管理サーバから前記画像形成装置に対するイベント通知を一括で受信する受信部と、
前記ポーリングが高頻度である場合に、受信した前記イベント通知が対応優先度の高いイベント通知であるか判断し、対応優先度の高いイベント通知である場合に前記イベント通知に対応するアプリケーションに前記イベント通知の処理を要求し、対応優先度の高いイベント通知でない場合には前記イベント通知の処理を要求しない通知管理処理を行う通知管理部と、
前記イベント通知の処理の要求を受けた場合に、前記イベント通知の処理を実行するアプリケーションと、を有し、
前記通知管理部は、前記イベント通知に含まれる該イベント通知の処理を行うアプリケーションを示す識別情報と、前記ポーリングの頻度の変更要求を行ったアプリケーションを示す識別情報が一致する場合に、前記イベント通知が対応優先度の高いイベント通知であると判断することを特徴とするシステム。

【請求項】

前記ポーリングの頻度の変更要求は、ポーリングの頻度を高頻度にする変更要求であり、
前記アプリケーションは、前記通知管理部に対してポーリングの頻度の変更要求を行った場合、前記通知管理部に前記アプリケーションの識別情報を送信し、
前記通知管理部は、前記アプリケーションから前記ポーリングの頻度の変更要求を受け付けた場合に該アプリケーションの識別情報を取得し、前記ポーリングの頻度の変更要求により高頻度で行われたポーリングにより受信するイベント通知に含まれる前記アプリケーションを示す識別情報との比較に利用することを特徴とする請求項１に記載のシステム。

【請求項】

前記アプリケーションは、前記通知管理部から処理を要求された前記イベント通知に含まれる処理の対応優先度の高さを示すフラグ情報に基づいて、前記イベント通知が処理対象であるか判定し、前記フラグ情報が高い対応優先度を示す値である場合に前記イベント通知の処理を行い、前記フラグ情報が高い対応優先度を示す値でない場合には前記イベント通知の処理を行わないことを特徴とする請求項１に記載のシステム。

【請求項】

前記通知管理サーバは、
前記サービスからの要求に応じて画像形成装置に対するイベント通知を生成する生成部と、
生成した前記イベント通知を管理する管理部と、
前記画像形成装置からのポーリングによるイベント通知要求に対して前記イベント通知を画像形成装置に通知する通知部と、と有し、
前記画像形成装置の前記通知管理部は、前記アプリケーションにおけるイベント通知の処理の結果を前記通知管理サーバに送信し、
前記管理部は、前記イベント通知のステータスおよび有効期限を管理することを特徴とする請求項１に記載のシステム。

【請求項】

前記ポーリングが高頻度である場合に対応優先度の高いイベント通知でないと判断されて処理されなかったイベント通知は、前記ポーリングの高頻度が解除された後のポーリングにより再び前記通知管理サーバから前記画像形成装置に通知され、前記画像形成装置の前記アプリケーションにより処理されることを特徴とすることを特徴とする請求項４に記載のシステム。

【請求項】

前記画像形成装置の前記通知管理部は、イベント通知の処理が行われなかった場合には、イベント通知の処理が行われなかったことを示すレスポンスを前記通知管理サーバに送信し、
前記管理部は、前記画像形成装置において処理が行われなかったイベント通知の有効期限を延長することを特徴とする請求項４に記載のシステム。

【請求項】

サービスに対応するアプリケーションを有する画像形成装置と、前記サービスからの前記画像形成装置に対するイベント通知を管理する通知管理サーバとを含むシステムの制御方法であって、
ポーリングにより前記通知管理サーバに対してイベント通知要求を行い、前記通知管理サーバから前記画像形成装置に対するイベント通知を一括で受信する工程と、
前記ポーリングが高頻度である場合に、受信した前記イベント通知が対応優先度の高いイベント通知であるか判断し、対応優先度の高いイベント通知である場合に前記イベント通知に対応するアプリケーションに前記イベント通知の処理を要求し、対応優先度の高いイベント通知でない場合には前記イベント通知の処理を要求しない通知管理処理を行う工程と、
前記イベント通知の処理の要求を受けた場合に、前記イベント通知の処理を実行する工程と、を有し、
前記通知管理処理では、前記イベント通知に含まれる該イベント通知の処理を行うアプリケーションを示す識別情報と、前記ポーリングの頻度の変更要求を行ったアプリケーションを示す識別情報が一致する場合に、前記イベント通知が対応優先度の高いイベント通知であると判断することを特徴とするシステムの制御方法。

【発明の詳細な説明】

【技術分野】

【】

本発明は、画像形成装置におけるイベント通知を管理するシステムおよびシステムの制御方法に関する。

【背景技術】

【】

一般的な画像形成装置に関する情報処理システムにおいて、クラウド上のサーバから画像形成装置に対してイベント通知をすることで、画像形成装置の管理者が、画像形成装置の設定値情報の変更といった操作を遠隔から指示することは広く行われている。またイベント通知は、画像形成装置が数時間毎にクラウド上のサーバにポーリングを行うことで、クラウド上のサーバから画像形成装置に送信されている。ここで、迅速に処理をしたいイベント通知が存在する場合は、クラウド上のサーバに対する画像形成装置のポーリング頻度を一時的に高速にすることで、画像形成装置が対応優先度の高いイベント通知を即座に受信できるようにすることも行われている。また特許文献１は、クラウド上のサーバが、サーバに接続している画像形成装置の台数に応じて、画像形成装置が処理するイベント通知の対応優先度を管理する方法を開示している。今日のクラウド上のサーバと接続された画像形成装置は、一度に複数のイベント通知を受信することがある。画像形成装置は、複数のイベント通知を一つずつ処理することによってサーバから要求された操作を実行する。複数のイベント通知の中には対応優先度の高いイベント通知も含まれているため、画像形成装置側で複数のイベント通知の中から対応優先度の高いイベント通知を迅速に処理することが求められる。

【先行技術文献】

【特許文献】

【】

【特許文献】特開２００９－１１７９４１号公報

【発明の概要】

【発明が解決しようとする課題】

【】

しかしながら、特許文献１の方法は、クラウド上のサーバに接続された画像形成装置の台数に基づいてイベント処理の対応優先度を決定するものであり、画像形成装置そのものが置かれた状況は考慮していない。そのため、対応優先度の高いイベント通知を迅速に処理することは出来ない。例えば、顧客が利用している画像形成装置に問題が発生したとする。画像形成装置の修理担当者は遠隔から修理対応を行うため、クラウド上のサーバに対する画像形成装置のポーリング頻度を一時的に高め、その場で修理機能を実行するためのイベントを画像形成装置に送信する。この際、画像形成装置に修理対応に関係のないファームウェアを更新するためのイベント通知も同時に受信していた場合、画像形成装置を利用している顧客の業務を中断させないため、修理機能を実行するためのイベント通知を最優先で処理する必要がある。しかし、ファームウェアを更新するためのイベント通知が先に処理された場合、ファームウェアの更新が完了するまで、画像形成装置は修理機能を実行するためのイベント通知を処理することができない。つまり、対応優先度の高いイベントを受信しているにも関わらず、画像形成装置はそのイベント通知を迅速に処理することができない。

【】

本発明は、対応優先度の高いイベント通知を優先して処理できるシステムを提供することを目的とする。

【課題を解決するための手段】

【】

上記課題を解決するために、本発明のシステムは、サービスに対応するアプリケーションを有する画像形成装置と、前記サービスからの前記画像形成装置に対するイベント通知を管理する通知管理サーバとを含むシステムであって、前記画像形成装置は、ポーリングにより前記通知管理サーバに対してイベント通知要求を行い、前記通知管理サーバから前記画像形成装置に対するイベント通知を一括で受信する受信部と、前記ポーリングが高頻度である場合に、受信した前記イベント通知が対応優先度の高いイベント通知であるか判断し、対応優先度の高いイベント通知である場合に前記イベント通知に対応するアプリケーションに前記イベント通知の処理を要求し、対応優先度の高いイベント通知でない場合には前記イベント通知の処理を要求しない通知管理処理を行う通知管理部と、前記イベント通知の処理の要求を受けた場合に、前記イベント通知の処理を実行するアプリケーションと、を有する。前記通知管理部は、前記イベント通知に含まれる該イベント通知の処理を行うアプリケーションを示す識別情報と、前記ポーリングの頻度の変更要求を行ったアプリケーションを示す識別情報が一致する場合に、前記イベント通知が対応優先度の高いイベント通知である。

【発明の効果】

【】

本発明によれば、対応優先度の高いイベント通知を優先して処理できるシステムを提供することができる。

【図面の簡単な説明】

【】

【図】システムの構成を示す図である。

【図】通知管理サーバおよびサービス用サーバのハードウェア構成を示す図である。

【図】画像形成装置のハードウェア構成を示す図である。

【図】通知管理サーバのソフトウェア構成を示す図である。

【図】画像形成装置のソフトウェア構成を示す図である。

【図】第１実施形態における通知処理全体のシーケンスを示した図である。

【図】第１実施形態における画像形成装置１０３内でのイベント通知処理を説明するフローチャートである。

【図】第１実施形態における画像形成装置１０３内でのイベント通知処理を説明するフローチャートである。

【図】第２実施形態における通知処理全体のシーケンスを示した図である。

【図】第２実施形態における画像形成装置１０３内でのイベント通知処理を説明するフローチャートである。

【図】第２実施形態における画像形成装置１０３内でのイベント通知処理を説明するフローチャートである。

【図】第３実施形態における情報システムの全体シーケンスを示す図である。

【図】第３実施形態における画像形成装置のイベント通知の処理フローを示すフローチャートを示す図である。

【図】第３実施形態における画像形成装置のイベント通知の処理フローを示すフローチャートを示す図である。

【発明を実施するための形態】

【】

（第１実施形態）
図１は、システムの構成を示す図である。本実施形態のシステムは、通知管理サーバ１０２からのイベント通知を受けた画像形成装置１０３が、優先的に処理すべきイベント通知を優先して迅速に処理する通知管理システムである。システムは、各サービスから画像形成装置１０３へのイベント通知を管理して画像形成装置１０３へイベント通知を送信する通知管理サーバ１０２と、通知管理サーバ１０２からのイベント通知を受信してイベント通知の処理を行う画像形成装置１０３を有する。画像形成装置１０３は、サービス（サービス用サーバ１０１）に対応するアプリケーションを有しており、あるサービスの指示により生成されたイベント通知は、当該サービスに対応するアプリケーションが処理する。また、システムには、画像形成装置１０３に関するサービスを提供するサービス用サーバ１０１が含まれていてもよい。サービス用サーバ１０１は、通知管理サーバ１０２に指示を行い画像形成装置１０３に対するイベント通知を生成させて保持させ、ポーリングを行った画像形成装置１０３にイベント通知を送信させることが可能である。

【】

サービス用サーバ１０１、通知管理サーバ１０２、画像形成装置１０３は、それぞれネットワーク１００を介して接続されている。ネットワーク１００は、データの送受信が可能に構成されていればよく、通信方式は問わない。例えば、ネットワーク１００は、ＬＡＮ、ＷＡＮ、ＬＴＥや５Ｇなどのセルラネットワーク、無線ネットワーク、電話回線、専用デジタル回線等のいずれか、またはこれらの組み合わせで構成される。

【】

サービス用サーバ１０１は、一つまたは複数存在し、画像形成装置１０３に関するサービスを提供する。サービス用サーバ１０１は、画像形成装置１０３に送信するための通知の生成要求を通知管理サーバ１０２に対して行う。画像形成装置１０３には、サービス用サーバ１０１のそれぞれに対応する通知実行アプリケーション５０２が用意されている。サービス用サーバ１０１が提供するサービスには、例えば遠隔から画像形成装置１０３の修理を行うリモート修理サービスなど、画像形成装置１０３を遠隔から操作するサービスが含まれる。画像形成装置１０３を遠隔から操作するサービスを提供するサービス用サーバ１０１は、画像形成装置１０３を遠隔から操作するためのイベント通知の生成要求を通知管理サーバ１０２に対して行う。

【】

通知管理サーバ１０２は、一つまたは複数のサービス用サーバ１０１からイベント通知の生成要求を受け付け、画像形成装置１０３に送信するためのイベント通知を生成し、保持する。また通知管理サーバ１０２は、画像形成装置１０３からポーリングがあった際は、ポーリングを行った画像形成装置１０３に対応する一つまたは複数のイベント通知を、ポーリングを行った画像形成装置１０３に一括送信する。画像形成装置１０３によるイベント通知の処理が完了した際は、通知管理サーバ１０２は、画像形成装置１０３からイベント通知の処理結果を受信する。

【】

サービス用サーバ１０１は、１台または複数台の情報処理装置の他、情報処理装置を含むデータセンターにより提供されたリソースを利用した仮想マシン（クラウドサービス）、あるいはこれらの組み合わせにより実現されてもよい。また、通知管理サーバ１０２は、１台または複数台の情報処理装置の他、情報処理装置を含むデータセンターにより提供されたリソースを利用した仮想マシン（クラウドサービス）、あるいはこれらの組み合わせにより実現されてもよい。

【】

画像形成装置１０３は、システムにより通知が管理される画像形成装置の一例である。システムで管理される画像形成装置１０３は、複数あってもよい。画像形成装置１０３は、例えば、印刷、ＦＡＸ、コピー、スキャナなどの機能を備えるＭＦＰ（ＭｕｌｔｉＦｕｎｃｔｉｏｎＰｒｉｎｔｅｒ）である。なお、画像形成装置１００は、ＭＦＰに限られず、プリンタ、スキャナ、３Ｄプリンタ等、印刷機能、コピー機能、スキャン機能、データのネットワーク送信機能、ＦＡＸ機能のいずれかを有するものであればよい。

【】

画像形成装置１０３は、通知管理サーバ１０２に対してポーリングを行い、通知管理サーバ１０２に保持されている画像形成装置１０３に対応するイベント通知を受信する。画像形成装置１０３は、通知管理サーバ１０２からイベント通知を受信した際は、イベント通知に記載された内容に基づいて操作を実行する。例えば、ファームウェアを更新するためのイベント通知を通知管理サーバ１０２から受信した場合、画像形成装置１０３は、イベント通知に記載された時刻やファームウェアのバージョンに従って、ファームウェアの更新を行う。画像形成装置１０３は、イベント通知の処理が完了すると、通知管理サーバ１０２にイベント通知の処理結果を送信する。

【】

図２は、サービス用サーバ１０１および通知管理サーバ１０２のハードウェア構成を示す図である。ここでは、通知管理サーバ１０２のハードウェア構成を例に説明する。サービス用サーバ１０１も通知管理サーバ１０２と同様のハードウェア構成を有している。通知管理サーバ１０２は、ＣＰＵ２００、ＲＡＭ２０１、ストレージ２０２、ネットワークＩ／Ｆ２０３、入出力Ｉ／Ｆ２０５、二次記憶装置２０６を有している。システムバス２０４は、ＣＰＵ２００、ＲＡＭ２０１、ストレージ２０２、ネットワークＩ／Ｆ２０３、入出力Ｉ／Ｆ２０５、二次記憶装置２０６を接続し、ＣＰＵ２００からの制御命令を他のハードウェアに伝播させる。

【】

ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）２００は、通知管理サーバ１０２全体を制御する。ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）２０１は、一時的なメモリ領域であり、ＣＰＵ２００のワークエリア等として機能する。ストレージ２０２は、組み込みプログラムや顧客の個人情報といった所定情報を記録する。ＣＰＵ２００は、メモリ（ＲＡＭ２０１または二次記憶装置２０６）から読み込んだプログラムを実行することで、各種制御処理を実行する。

【】

ネットワークインターフェース２０３は、他のコンピュータやネットワーク機器と通信を行う。本実施形態においては、通知管理サーバ２０３のネットワークインターフェース２０３は、サービス用サーバ１０１および画像形成装置１０３と通信を行う。ネットワークインターフェース２０３は有線・無線双方の通信方式に対応する。なお、サービス用サーバ１０１のネットワークインターフェース２０３は、通知管理サーバ２０３との通信を行う。サービス用サーバ１０１は、ネットワークインターフェース２０３を介して、通知管理サーバ１０２にイベント通知の生成要求を行う。通知管理サーバ１０２は、ネットワークインターフェース２０３を介して、生成したイベント通知を画像形成装置１０３に送信する。

【】

入出力インターフェース２０５は、キーボード、マウス、タッチパネルなどの機器からの信号や情報を受信する。また、入出力インターフェース２０５は、ディスプレイやタッチパネルなどの機器に信号や情報を出力する。また、入出力インターフェース２０５は、リモートデスクトップやリモートシェルなどを通して、他のコンピュータからの接続と操作を受け付けることも可能である。二次記憶装置２０６は、各種データやプログラムを記憶する間接記憶装置である。二次記憶装置２０６は、例えば、Ｈａｒｄ Ｄｉｓｃ Ｄｒｉｖｅ（ＨＤＤ）、Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ（ＳＳＤ）、フラッシュメモリなどである。また、二次記憶装置２０６は、外部メディアを装填するＤｉｓｋＤｒｉｖｅなど他の記憶装置を備えていてもよい。

【】

図３は、画像形成装置１０３のハードウェア構成を示す図である。画像形成装置１０３は、ＣＰＵ３００、ＲＡＭ３０１、ＲＯＭ３０２、ネットワークＩ／Ｆ３０３、デバイスコントローラ３０５、プリンタ３０６、スキャナ３０７、二次記憶装置３０８、入出力Ｉ／Ｆ３０９、入出力装置３１０を有する。システムバス３０４は、ＣＰＵ３００、ＲＡＭ３０１、ＲＯＭ３０２、ネットワークＩ／Ｆ３０３、デバイスコントローラ３０５、二次記憶装置３０８、入出力Ｉ／Ｆ３０９を接続し、ＣＰＵ３００からの制御命令を画像形成装置１０３全体に伝播させる。

【】

ＣＰＵ３００は、画像形成装置１０３全体の制御を行う。ＲＡＭ３０１は、プログラムの実行に必要となる情報を一時的に記憶し、ＣＰＵ３００のワークエリア等として機能する。ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）３０２は、基本Ｉ／Ｏプログラム等の各種データを記憶する。二次記憶装置３０８は、各種データやプログラムを記憶する間接記憶装置である。二次記憶装置３０８は、例えば、Ｈａｒｄ Ｄｉｓｃ Ｄｒｉｖｅ（ＨＤＤ）、Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ（ＳＳＤ）、フラッシュメモリなどである。また、二次記憶装置３０８は、外部メディアを装填するＤｉｓｋＤｒｉｖｅなど他の記憶装置を備えていてもよい。ＣＰＵ３００は、ＲＯＭ３０２や二次記憶装置３０８に記憶されているプログラムを実行して各種制御処理を実行する。ＣＰＵ３００は、ＲＡＭ３０１にプログラムの実行に必要な情報を一時的に格納する。

【】

ネットワークインターフェース３０３は、画像形成装置１０３が、ネットワーク１００を介して通知管理サーバ１０２などの外部機器と通信することを可能にする。画像形成装置１０３の通信方式は、有線・無線双方に対応する。デバイスコントローラ３０５は、ＣＰＵ３００から受けた制御命令に基づいて、プリンタ３０６やスキャナ３０７等の装置を制御する。プリンタ３０６は、印刷などのジョブを実行して、記録紙などに印刷を行う。スキャナ３０７は、原稿台やＡＤＦ（Ａｕｔｏ Ｄｏｃｕｍｅｎｔ Ｆｅｅｄｅｒ）にセットされた原稿を光学的に読み取り、電子データに変換する。また、画像形成装置１０３は、スキャナ３０７を利用するＦＡＸ機能を有していてもよい。

【】

入出力インターフェース３０９は、入出力装置３１０から受信した信号を、画像形成装置１０２内の各部に伝達する。入出力装置３１０は、画像形成装置１０３における入出力を担う複数の構成を有する。入出力装置３１０は、例えば、タッチパネルやハードキー等である。タッチパネルにおける入力座標と表示座標を対応付けることで、あたかもユーザがタッチパネルに表示された画面を直接的に操作可能であるかのようなグラフィカルユーザインタフェース（ＧＵＩ）を構成することができる。入出力装置３１０は、ユーザからの入力を受け付け、前記入力に対応する信号を、入出力インターフェース３０９を介して画像形成装置１０３内の各部に送信する。

【】

図４は、通知管理サーバ１０２のソフトウェア構成の一例を示す図である。通知管理サーバ１０２のソフトウェア構成を実現するプログラムは、メモリ（ＲＡＭ２０１、ストレージ２０２、二次記憶装置２０６）から読み込まれ、ＣＰＵ２００によって実行される。通知管理サーバ１０２の外部との通信は、ネットワークインターフェース２０３を用いることで行う。通知管理サーバ１０２は、外部通信部４００、通知生成部４０１、通知管理部４０２を有する。通知管理サーバ１０２は、サービス用サーバ１０１からのイベント通知生成の指示を外部通信部４００で受信し、通知生成部４０１でイベント通知を生成する。そして、生成したイベント通知を通知管理部４０２で管理し、画像形成装置１０３からのポーリングによるイベント通知の送信要求に応じてイベント通知を画像形成装置１０３に送信する。

【】

外部通信部４００は、サービス用サーバ１０１からイベント通知生成要求を受信し、イベント通知の生成処理を通知生成部４０１に依頼する。また、外部通信部４００は、画像形成装置１０３からイベント通知の送信要求があった際は、通知管理部４０２に問い合わせ、当該画像形成装置１０３にイベント通知を通知する通知部として機能する。さらに、外部通信部４００は、画像形成装置１０３からイベント通知の処理結果を受信した際は、通知管理部４０２にイベント通知のステータス更新を依頼する。

【】

通知生成部４０１は、サービス用サーバ１０１からイベント通知の生成要求に応じて、イベント通知を生成する生成部として機能する。そして通知生成部４０１は、生成したイベント通知を通知管理部４０２に送信する。通知管理部４０２は、生成されたイベント通知を管理する管理部として機能する。イベント通知は、例えば通知管理部４０２において、イベント通知が持つ画像形成装置ＩＤごとに、キュー形式で管理される。通知管理部４０２が管理するイベント通知には、イベント通知に対応するアプリケーションを示す識別情報であるアプリケーションＩＤと、イベント通知のステータスおよび有効期限が含まれる。表１は、イベント通知の一例である。

【表】

【】

イベント通知には、通知ＩＤ、画像形成装置ＩＤ、アプリケーションＩＤ、ステータス、更新日時、キュー日時、有効期限、ペイロードが含まれる。「通知ＩＤ」は、イベント通知を一意に識別するための値を示す属性である。「画像形成装置ＩＤ」は、画像形成装置１０３を一意に識別するための値を示す属性である。「アプリケーションＩＤ」は、イベント通知を実行する通知実行アプリケーション５０２を一意に識別するための識別情報である。通知実行アプリケーション５０２はサービス用サーバ１０１に対応している。そのため、通知生成部４０１はイベント通知の生成要求を行ったサービス用サーバ１０１に応じた「アプリケーションＩＤ」の値を格納することで、イベント通知を実行する通知実行アプリケーション５０２を一意に識別することができる。

【】

「ステータス」は、イベント通知の処理状況を示す属性である。「ステータス」属性が取りうる値域として、“ＱＵＥＵＥＤ”、“ＡＣＣＥＰＴＥＤ”、“ＲＥＪＥＣＴＥＤ”、“ＥＲＲＯＲ”等がある。イベント通知が生成された際、「ステータス」属性の値は“ＱＵＥＵＥＤ”に設定される。“ＱＵＥＵＥＤ”のステータスを持つイベント通知のみが、通知管理アプリケーション５０１に送信される。また、画像形成装置１０３から受信するイベント通知の処理結果に基づいて、「ステータス」属性の値は変更される。画像形成装置１０３からイベント通知の成功を示すレスポンスを受信した場合、通知管理部４０２は、「ステータス」属性の値を“ＱＵＥＵＥＤ”から“ＡＣＣＥＰＴＥＤ”に更新する。一方で、画像形成装置１０３からイベント通知の失敗を示すレスポンスを受信した場合、通知管理部４０２は、「ステータス」属性の値を“ＥＲＲＯＲ”に更新する。

【】

「更新日時」は、イベント通知の最終更新日時を示す属性である。「キュー日時」は、イベント通知が生成された日時を示す属性である。「有効期限」は、イベント通知の通知管理サーバ１０２における有効期限を示す属性である。有効期限を超過したイベント通知は、通知管理部４０２により通知管理サーバ１０２から削除される。「ペイロード」は、イベント通知を処理する画像形成装置１０３の通知実行アプリケーション５０２が参照し、処理を実行するために必要な内容をＪＳＯＮ形式で保持した属性である。具体的に「ペイロード」属性の値には、イベント通知処理を行うためのモジュール名やパラメータが保持される。また、「ペイロード」属性の値には、当該イベント通知を優先して処理する必要があるかどうかを示すフラグが含まれていてもよい

【】

通知管理部４０２は、管理対象の画像形成装置に送信するイベント通知をキュー形式で保持する。画像形成装置１０３からイベント通知の送信要求があった際は、通知管理部４０２は、送信要求を行った画像形成装置１０３の画像形成装置ＩＤを持ち、かつ「ステータス」属性の値が“ＱＵＥＵＥＤ”に設定されているイベント通知を全て送信する。また通知管理部４０２は、画像形成装置１０３からイベント通知の処理結果を受信することで、イベント通知のステータス管理を行う。

【】

図５は、画像形成装置１０３のソフトウェア構成の一例を示す図である。画像形成装置１０３のソフトウェア構成を実現するプログラムは、メモリ（ＲＯＭ３０２、二次記憶装置３０８）から読み込まれ、ＣＰＵ３００によって実行される。画像形成装置１０３と通知管理サーバ１０２との通信は、ネットワークインターフェース３０３を介して行われる。画像形成装置１０３は、外部通信部５００、通知管理アプリケーション５０１、通知実行アプリケーション５０２を有する。さらに、画像形成装置１０３は、設定値管理部５０３、ジョブ実行部５０４、ＦＡＸ部５０５、ＳＥＮＤ部５０６、ＰＤＬ部５０７、ファームウェア更新部５０８を有する。

【】

外部通信部５００は、ネットワークインターフェース３０３を利用することで、外部機器との通信を行う。本実施形態の外部通信部５００は、通知管理サーバ１０２からのイベント通知の受信を行う受信部として機能する。より具体的には、外部通信部５００は、通知管理アプリケーション５０１から指示された頻度でポーリングにより通知管理サーバ１０２に対してイベント通知要求を行い、通知管理サーバ１０２から画像形成装置１０３に対するイベント通知を一括で受信する。また、外部通信部５００は、通知管理サーバ１０２に対するイベント通知の処理結果の送信を実現する。

【】

通知管理アプリケーション５０１（以下、通知管理アプリ５０１と記載する）は、画像形成装置１０３に対するイベント通知を管理する通知管理部として機能する。通知管理アプリ５０１は、外部通信部５００を介して通知管理サーバ１０２に対して定期的にポーリングを行うことで、通知管理サーバ１０２から一つまたは複数のイベント通知を画像形成装置１０３が一括受信するよう制御する。通知管理アプリ５０１は、各イベント通知の実行を、イベント通知に対応した通知実行アプリケーション５０２に要求する。通知管理アプリ５０１は、イベント通知が保持するアプリケーションＩＤとアプリケーションＩＤが一致する通知実行アプリケーション５０２にイベント通知の実行要求を行う。

【】

また、本実施形態の通知管理アプリ５０１は、優先して処理を行いたいイベント通知が存在する場合、そのイベント通知を実行する通知実行アプリケーション５０２から、通知管理サーバ１０２に対するポーリング頻度の変更要求を受信する。これにより通知管理アプリ５０１は、高頻度ポーリングモードに移行する。同時に通知管理アプリ５０１は、ポーリング頻度の変更要求を行った通知実行アプリケーション５０２のアプリケーションＩＤを取得し、記憶する。ポーリングが高頻度である場合には、通知管理アプリ５０１は、イベント通知が対応優先度の高いイベント通知であるか判断し、対応優先度に応じてイベント通知の通知実行アプリケーション５０２への処理要求を制御する通知管理処理を行う。対応優先度の高いイベント通知であるか否かは、イベント通知に含まれるアプリケーションＩＤと、高頻度のポーリングを要求した通知実行アプリケーション５０２を示す識別情報であるアプリケーションＩＤに基づいて判断される。イベント通知に含まれるアプリケーションＩＤは、イベント通知の処理を行うアプリケーションを示す識別情報である。通知管理アプリ５０１は、ポーリング頻度の変更要求を行った通知実行アプリケーション５０２の識別情報であるアプリケーションＩＤを持つイベント通知を優先して処理を行いたいイベント通知であると判断し、当該イベント通知の処理を実行させる。通知管理アプリ５０１は、イベント通知が保持するアプリケーションＩＤと通知実行アプリケーション５０２が保持するアプリケーションＩＤが一致する場合にのみ、イベント通知に対応する通知実行アプリケーション５０２にイベント通知の実行要求を行う。一方、アプリケーションＩＤが一致しない場合には、通知実行アプリケーション５０２にイベント通知の処理を要求しないことで、イベント要求を無視する。さらに、通知管理アプリ５０１は、通知実行アプリケーション５０２からイベント通知の処理結果を受信し、外部通信部５００を介して、画像形成装置１０３におけるイベント通知の処理結果を通知管理サーバ１０２に送信する。

【】

通知実行アプリケーション５０２（以下、通知実行アプリ５０２と記載する）は、サービス用サーバ１０１に対応するアプリケーションである。通知実行アプリ５０２は、画像形成装置１０３内に一つまたは複数インストールされており、自身に対応するサービス用サーバ１０１からのイベント通知の処理を実行することで、画像形成装置１０３内の機能を操作する。また、各通知実行アプリ５０２は、自身を一意に示す識別情報であるアプリケーションＩＤを保有する。通知実行アプリ５０２は、通知管理アプリ５０１からイベント通知の処理要求を受信した場合、そのイベント通知を実行する。通知実行アプリ５０２は、イベント通知を実行することで、画像形成装置１０３内の多様な機能（例えば設定値管理部５０３、ジョブ実行部５０４、ファームウェア更新部５０８等）を遠隔から利用することを可能にする。また、通知実行アプリ５０２は、イベント通知の処理を実行すると、その処理結果を通知管理アプリ５０１に送信する。なお、本実施形態では、通知実行アプリ５０２が実行する画像形成装置１０３の機能を特に限定しないものとする。例えば画像形成装置１０３の利用者は、通知実行アプリ５０２を介して、画像形成装置１０３にインストールするアプリケーションのライセンスを管理しても良い。

【】

設定値管理部５０３は、画像形成装置１０３の設定値情報を管理する。また、設定値管理部５０３は、通知実行アプリ５０２から設定値情報の送信要求を受けた際は、画像形成装置１０３の設定値情報を送信する。ジョブ実行部５０４は、画像形成装置１０３内の機能を実行するためのジョブ情報を管理する。ジョブ実行部５０４は、例えば、ＦＡＸ部５０５、ＳＥＮＤ部５０６、ＰＤＬ部５０７の機能を実行するためのジョブ情報を管理する。ジョブ実行部５０４は、通知実行アプリ５０２からジョブ実行要求を受信することで、ＦＡＸ部５０５、ＳＥＮＤ部５０６、ＰＤＬ部５０７を実行する。ＦＡＸ部５０５は、画像形成装置１０３のＦＡＸ機能を実行する。ＳＥＮＤ部５０６は、画像形成装置１０３のＳＥＮＤ機能を実行する。ＰＤＬ部５０７は、画像形成装置１０３のＰＤＬ機能を実行する。ファームウェア更新部５０８は、通知実行アプリ５０２からファームウェアのバージョン更新の指示を受けると、画像形成装置１０３のファームウェアのバージョン更新処理を実行する。

【】

図６は、第１実施形態における通知処理全体のシーケンスを示した図である。通知処理においてサービス用サーバ１０１が実行する各処理は、サービス用サーバ１０１のＣＰＵ２００がメモリ（ＲＡＭ２０１、二次記憶装置２０６）に記憶されたプログラム等を読み出して、実行することで実現される。通知処理において通知管理サーバ１０２が実行する各処理は、通知管理サーバ１０２のＣＰＵ２００がメモリ（ＲＡＭ２０１、二次記憶装置２０６）に記憶されたプログラム等を読み出して、実行することで実現される。通知処理において画像形成装置１０３が実行する各処理は、画像形成装置１０３のＣＰＵ３００がメモリ（ＲＯＭ３０２、二次記憶装置３０８）に記憶されたプログラム等を読み出して、実行することで実現される。

【】

ステップＳ６００では、サービス用サーバ１０１が、遠隔から画像形成装置１０３を操作するために、通知管理サーバ１０２に対してイベント通知の生成要求を行う。ここでは、サービス用サーバ１０１が表１に記載のイベント通知の生成要求行った場合を例に説明する。ステップＳ６０１では、通知管理サーバ１０２が、イベント通知の生成を行う。生成されたイベント通知は、イベント通知が持つ画像形成装置ＩＤごとに、キュー形式で通知管理サーバ１０２内に保存される。通知管理サーバ１０２は、表１に記載のイベント通知の生成を行う。ステップＳ６０２では、通知管理サーバ１０２が、サービス用サーバ１０１に、イベント通知を生成した旨を通知する。

【】

ステップＳ６０３では、画像形成装置１０３内の通知実行アプリ５０２が、画像形成装置１０３内のイベント通知実行アプリケーション５０１に、通知管理サーバ１０２に対するポーリング頻度の変更を要求する。ポーリング頻度の変更を要求する実行アプリ５０２は、イベント通知実行アプリケーション５０１に、通知管理サーバ１０２に対するポーリング頻度を高頻度に変更するように要求する。ステップＳ６０４では、ステップＳ６０３でポーリング頻度の変更要求を行った通知実行アプリ５０２が、通知管理アプリ５０１に自身のアプリケーションＩＤを伝達する。ステップＳ６０５では、通知管理アプリ５０１が、通知管理サーバ１０２に高頻度で問い合わせを行うよう、高頻度ポーリングモードへの移行をする。

【】

ステップＳ６０６からステップＳ６１２は、ステップＳ６０５で移行した高頻度ポーリングモードが解除されるまで繰り返し行われる。ステップＳ６０６では、画像形成装置１０３内の通知管理アプリ５０１が、通知管理サーバ１０２に対して、画像形成装置１０３の画像形成装置ＩＤに一致するイベント通知を全て送信するよう要求をする。

【】

ステップＳ６０７では、通知管理サーバ１０２の通知管理部４０２が、画像形成装置１０３に対してイベント通知を一括送信する。送信するイベント通知は、イベント通知の「画像形成装置ＩＤ」属性の値がステップＳ６０６でイベント通知の送信要求を行った画像形成装置１０３を示し、かつイベント通知の「ステータス」属性の値が“ＱＵＥＵＥＤ”であるイベント通知全てである。画像形成装置１０３は、通知管理サーバ１０２からイベント通知を一括受信する。

【】

ステップＳ６０８からステップＳ６１１のステップは、ステップＳ６０７で一括取得したイベント通知の数だけ、イベント通知毎に繰り返し実行される。本実施形態の例では、表１に記載のイベント通知の数だけ、イベント通知毎にステップＳ６０８からステップＳ６１１のステップが繰り返し実行される。ステップＳ６０８では、画像形成装置１０３内の通知管理アプリ５０１が、ステップＳ６０７で受信したイベント通知の処理要求を通知実行アプリ５０２に対して行うか判断をする。通知管理アプリ５０１は、識別情報であるアプリケーションＩＤに基づいて、受信したイベント通知が対応優先度の高いイベント通知であるか判断する。対応優先度の高いイベント通知であると判断した場合にのみ、通知実行アプリ５０２にイベント通知の処理を要求し、対応優先度の高いイベント通知であると判断されなかった場合には、通知実行アプリ５０２にイベント通知の処理を要求しない。具体的には、通知管理アプリ５０１は、イベント通知の「アプリケーションＩＤ」属性の値と、ステップＳ６０４で取得した通知実行アプリ５０２のアプリケーションＩＤを照合することで、処理要求をするイベント通知を判断する。すなわち、通知管理アプリ５０１は、ポーリング頻度を高頻度に変更するよう要求した通知実行アプリ５０２のアプリケーションＩＤを有するイベント通知があるか否かを判断する。イベント通知のアプリケーションＩＤとステップＳ６０４で取得した通知実行アプリ５０２のアプリケーションＩＤが一致する場合、通知管理アプリ５０１は、対応優先度の高いイベント通知であると判断し通知実行アプリ５０２にイベント通知の処理要求を行う。一方、イベント通知のアプリケーションＩＤとステップＳ６０４で取得した通知実行アプリ５０２のアプリケーションＩＤが一致しない場合、通知管理アプリ５０１は、通知実行アプリ５０２に対してイベント通知の処理要求を行わない。

【】

以下では、イベント通知のアプリケーションＩＤとポーリング頻度を高頻度に変更するよう要求した通知実行アプリ５０２のアプリケーションＩＤが一致した場合の処理について説明する。ステップＳ６０９～ステップＳ６１２のステップは、ステップＳ６０８で照合したアプリケーションＩＤが同一のものであると判定された場合に実行される。ステップＳ６０９では、Ｓ６０８で通知管理アプリ５０１からイベント通知の処理要求を受けた通知実行アプリ５０２が、ステップＳ６０８で通知管理アプリ５０１から受信したイベント通知の処理を実行する。すなわち、ポーリング頻度を高頻度に変更するよう要求した通知実行アプリ５０２が、受信したイベント通知の処理を実行する。また、イベント通知の処理を実行した通知実行アプリ５０２は、イベント通知の処理結果を通知管理アプリ５０１に伝達する。

【】

ステップＳ６１０は、ステップＳ６０９で処理したイベント通知が、サービス用サーバ１０１に対する高頻度ポーリングモードを終了させるものであった場合に実行される。ステップＳ６１０では、通知実行アプリ５０２が、通知管理アプリ５０１に対して、高頻度ポーリングモードを終了させる要求を行う。これにより、ステップＳ６０６からステップＳ６１１の繰り返し処理が終了する。

【】

ステップＳ６１１では、画像形成装置１０３内の通知管理アプリ５０１が、通知管理サーバ１０２に対してイベント通知の処理結果を送信する。ステップＳ６１２では、イベント通知サーバ内の通知管理部４０２が、ステップＳ６１１で受信したイベント通知の処理結果に基づいて、イベント通知の「ステータス」属性の値を更新する。例えば、ステップＳ６１１で、通知管理サーバ１０２がイベント通知の成功を示すレスポンスを受信した場合、イベント通知の「ステータス」属性の値を“ＡＣＣＥＰＴＥＤ”に更新する。一方で、ステップＳ６１１で通知管理サーバ１０２がイベント通知の失敗を示すレスポンスを受信した場合、イベント通知の「ステータス」属性の値を“ＥＲＲＯＲ”に更新する。

【】

このように本処理では、ステップＳ６０８において、ポーリング頻度を高頻度に変更するよう要求した通知実行アプリ５０２のアプリケーションＩＤと一致するイベント通知のアプリケーションＩＤがある場合は、当該イベント通知の処理が行われる。一方、ポーリング頻度を高頻度に変更するよう要求した通知実行アプリ５０２のアプリケーションＩＤとアプリケーションＩＤが一致しないイベント通知は、通知管理アプリ５０１が通知実行アプリ５０２に処理要求が行われない。これにより、ポーリング頻度を高頻度に変更するよう要求した通知実行アプリ５０２のアプリケーションＩＤとアプリケーションＩＤが一致するイベント通知、すなわち優先度の高いイベント通知を優先して処理することできる。

【】

一方、優先度の高くないイベント通知は、優先度の高いイベント通知の処理が完了し、高頻度のポーリングモードが解除された後に実行される。優先度の高くないイベント通知は、ポーリング頻度を高頻度に変更するよう要求した通知実行アプリ５０２のアプリケーションＩＤとアプリケーションＩＤが一致しないイベント通知である。具体的には、ポーリングが高頻度である場合に対応優先度の高いイベント通知でないと判断されて画像形成装置１０３で処理されなかったイベント通知は、通知管理サーバ１０２においてイベント通知のステータスが“ＱＵＥＵＥＤ”のまま維持されている。そのため、処理されなかったイベント通知は、ポーリングの高頻度が解除された後のポーリングにより再び通知管理サーバ１０２から画像形成装置１０３に通知され、通知実行アプリ５０２により処理される。

【】

図７および図８は、第１実施形態における画像形成装置１０３内でのイベント通知処理を説明するフローチャートである。図７および図８の各処理は、画像形成装置１０３のＣＰＵ３００がメモリ（ＲＯＭ３０２、二次記憶装置３０８）から各ソフトウェアモジュールを実行するためのプログラムをＲＡＭ３０１に読み出し、実行することにより実現される。

【】

ステップＳ７００では、通知実行アプリ５０２が、通知管理アプリ５０１に対して、通知管理サーバ１０２へのポーリング頻度を変更するための要求を行う。通知実行アプリ５０２が通知管理アプリ５０１に対して行うポーリング頻度の変更要求は、ポーリング頻度を高頻度に変更する要求である。ステップＳ７００の処理は、図６のステップＳ６０３の処理にあたる。

【】

ステップＳ７０１では、ポーリング頻度変更の要求元である通知実行アプリ５０２が、通知管理アプリ５０１に対して、自身を識別するために必要な識別情報であるアプリケーションＩＤを送信する。これにより、通知管理アプリ５０１は、ポーリング頻度を変更するよう要求した通知実行アプリ５０２のアプリケーションＩＤを取得することができる。通知管理アプリ５０１は、取得した通知実行アプリ５０２のアプリケーションＩＤをポーリングの頻度の変更要求により高頻度で行われたポーリングにより受信するイベント通知に含まれるアプリケーションを示す識別情報との比較に利用する。ステップＳ７０１の処理は、図６のステップＳ６０４の処理にあたる。ステップＳ７０２では、通知管理アプリ５０１が、通知管理サーバ１０２に高頻度で問い合わせを行うよう、ポーリングモードを高頻度に変更する。これにより、画像形成装置１０３のポーリングモードが高頻度ポーリングモードに移行する。ステップＳ７０２の処理は、図６のステップＳ６０５の処理にあたる。

【】

ステップＳ７０３では、通知管理アプリ５０１の高頻度ポーリングモードが解除されるまで、ステップＳ７０４からＳ７１１を繰り返し実行する。ステップＳ７０４では、通知管理アプリ５０１が、通知管理サーバ１０２にポーリングし、通知管理サーバ１０２からイベント通知を一括受信する。ここでは、通知管理アプリ５０１が、表１に記載のイベント通知を一括受信したものとする。ステップＳ７０１の処理は、図６のステップＳ６０６およびステップＳ６０７の処理にあたる。

【】

ステップＳ７０５では、通知管理アプリ５０１と通知実行アプリ５０２が、ステップＳ７０６からステップＳ７１０までのステップを繰り返し行うことで、ステップＳ７０４で一括受信したイベント通知を一つずつ処理する。ステップＳ７０６では、通知管理アプリ５０１が、イベント通知の対応優先度が高いか、すなわち、イベント通知を処理するかどうか判定する。通知管理アプリ５０１は、対象のイベント通知に含まれる「アプリケーションＩＤ」属性の値と、ステップＳ７０１で取得した通知実行アプリ５０２のアプリケーションＩＤを照合することで、判定を行う。ステップＳ７０１で取得した通知実行アプリ５０２のアプリケーションＩＤ、すなわち高頻度ポーリングモードへの移行要求を行った通知実行アプリ５０２のアプリケーションＩＤを有するイベント通知は処理の優先度の高いイベント通知である。アプリケーションＩＤが一致する場合、通知管理アプリ５０１はステップＳ７０７の処理を行う。一方、アプリケーションＩＤが一致しない場合、通知管理アプリ５０１は対象のイベント通知を処理せず、通知管理アプリ５０１は、ステップＳ７１１の処理を行う。

【】

ステップＳ７０７では、通知管理アプリ５０１が、イベント通知が保持するアプリケーションＩＤに一致する通知実行アプリ５０２に対して、イベント通知の処理要求を行う。つまり、ステップＳ７００で高頻度ポーリングモードへの移行を要求した通知実行アプリ５０２に対してのみ、通知管理アプリ５０１は、イベント通知の処理要求を行う。ステップＳ７０６およびステップＳ７０７の処理は、図６のステップＳ６０８の処理にあたる。

【】

ステップＳ７０８では、通知実行アプリ５０２が、イベント通知の「ペイロード」属性の内容に沿った処理を実行する。例えば、画像形成装置１０３の設定値情報を画像形成装置１０３の外部に送信する指示がイベント通知の「ペイロード」属性の値に記載されていた場合、通知実行アプリ５０２は設定値管理部５０３に問い合わせを行うことで指示を実行する。その後通知実行アプリ５０２は、通知管理アプリ５０１に、イベント通知の処理結果を伝達する。ステップＳ７０８の処理は、図６のステップＳ６０９の処理にあたる。

【】

通知実行アプリ５０２におけるイベント通知の処理が完了したことを契機に、すなわち、通知管理アプリ５０１が通知実行アプリ５０２からイベント通知の処理結果を受信すると、通知管理アプリ５０１がＳ７０９の処理を実行する。ステップＳ７０９では、通知管理アプリ５０１が、イベント通知の処理結果を通知管理サーバ１０２に送信する。例えば、イベント通知の処理が正常に行われた場合、通知管理アプリ５０１はイベント通知の処理成功を示すレスポンス（例：“ＡＣＣＥＰＴＥＤ”）を通知管理サーバ１０２に送信する。一方でイベント通知の処理が失敗した場合、通知管理アプリ５０１はイベント通知の処理失敗を示すレスポンス（例：“ＥＲＲＯＲ”）を通知管理サーバ１０２に送信する。ステップＳ７０１の処理は、図６のステップＳ６１１の処理にあたる。

【】

ステップＳ７１０では、通知実行アプリ５０２が、ステップＳ７０８で処理したイベント通知が高頻度ポーリングモードを解除するものであったかを判定を行う。通知実行アプリ５０２は、イベント通知の「ペイロード」属性の値を参照することで高頻度ポーリングモードを解除するイベント通知か否かの判定を行う。高頻度ポーリングモードを解除するイベント通知であった場合、通知実行アプリ５０２は通知管理アプリ５０１に対して、高頻度ポーリングモードを終了させる要求を行う。高頻度ポーリングモードを終了させる要求を受けた通知管理アプリ５０１は、ステップＳ７０５からステップＳ７１１までのステップの繰り返し処理を終了し、ステップＳ７１２の処理を行う。一方、高頻度ポーリングモードを終了させる要求を受けなかった場合は、通知管理アプリ５０１はステップＳ７１１の処理を行う。ステップＳ７０１の処理は、図６のステップＳ６１０の処理にあたる。

【】

なお、本実施形態では、イベント通知が高頻度ポーリングモードを解除するものであるかの判定を通知実行アプリ５０２で行う例を説明したが、通知管理アプリ５０１が判定を行うようにしてもよい。この場合、通知管理アプリ５０１が、ステップＳ７０８で処理されたイベント通知が高頻度ポーリングモードを解除するものであったかどうか判定を行う。通知管理アプリ５０１は、イベント通知の「ペイロード」属性の値を参照することで高頻度ポーリングモードを解除するイベント通知か否かの判定を行う。高頻度ポーリングモードを解除するイベント通知であった場合、ステップＳ７０５からステップＳ７１１までのステップの繰り返し処理は終了する。一方、高頻度ポーリングモードを解除するイベント通知でなかった場合、通知管理アプリ５０１はステップＳ７１１の処理を行う。

【】

ステップＳ７１１では、ステップＳ７０４で一括取得したイベント通知で未処理のものがある場合、フローチャートはステップＳ７０５に戻る。一方、ステップＳ７０４で一括取得したイベント通知が全て処理された場合、フローチャートはステップＳ７１２に遷移し、ステップＳ７０５からステップＳ７１１のステップの繰り返し処理を終了する。
すなわち、通知管理アプリ５０１は、ステップＳ７０４で一括取得したイベント通知が全て処理したか否か判断する。通知管理アプリ５０１は、ステップＳ７０４で一括取得したイベント通知で未処理のものがあると判断した場合、再びステップＳ７０５の処理を行う。一方、通知管理アプリ５０１は、ステップＳ７０４で一括取得したイベント通知が全て処理したと判断した場合、ステップＳ７０５からステップＳ７１１のステップの繰り返し処理を終了し、ステップＳ７１２の処理を行う。

【】

ステップＳ７１２では、ステップＳ７１０にて高頻度ポーリングモードが解除されたと判定された場合、ステップＳ７０５からステップＳ７１１のステップの繰り返し処理が終了する。これにより、図７および図８のフローチャートは終了する。一方で、ステップＳ７１０にて高頻度ポーリングモードが解除されていないと判定された場合、フローチャートはステップＳ７０３に遷移し、画像形成装置１０３は改めて通知管理サーバ１０２からイベント通知を一括受信し、処理をする。すなわち、通知管理アプリ５０１は、高頻度ポーリングモードが解除されたか否かを判断する。通知管理アプリ５０１は、高頻度ポーリングモードが解除されていると判断した場合は、本処理を終了する。一方、高頻度ポーリングモードが解除されていないと判断した場合は、再びステップＳ７０３の処理を行う。

【】

本処理により、高頻度ポーリングモードへの移行を要求した通知実行アプリ５０２に対するイベント通知の処理を迅速に行うことが出来る処理フローが実現される。そのため、高頻度ポーリングモード中、画像形成装置１０３は対応優先度の高いイベント通知を迅速に処理することが可能となる。

【】

ここで、画像形成装置１０３が遠隔修理のイベント通知と、ファームウェア更新のイベント通知の両方を受信している場合を例に、イベント通知処理について説明する。遠隔修理のイベント通知は遠隔修理を受けるための通知であり、画像形成装置１０３は遠隔修理を必要とする状態、例えば故障状態である。修理が必要な状態である場合、画像形成装置１０３を利用できる状態に戻すために他の処理より修理に関する処理を優先して処理する必要がある。したがって、ファームウェア更新のイベント通知よりも遠隔修理のイベント通知を優先して処理する必要がある。このように、画像形成装置１０３は迅速に修理を行うため、ステップＳ６００で遠隔修理サーバが生成要求を行った遠隔修理のイベント通知を優先的に処理する必要がある。一方で画像形成装置１０３は、修理が完了するまでの間、修理対応と関係のないステップＳ６００でファームウェア更新サーバが生成要求を行ったファームウェア更新のイベント通知を処理する必要はない。

【】

遠隔修理のイベント通知は、画像形成装置１０３を遠隔から修理するためのサービス用サーバ１０１（以下、遠隔修理サーバと記載する）による通知である。ファームウェア更新のイベント通知は、画像形成装置１０３のファームウェアを更新するためのサービス用サーバ１０１（以下、ファームウェア更新サーバと記載する）による通知である。画像形成装置１０３には、ファームウェア更新サーバと遠隔修理サーバのそれぞれに対応する、異なるアプリケーションＩＤが割り当てられた通知実行アプリ５０２が用意されている。

【】

例えば、画像形成装置１０３の故障を検知すると、遠隔修理サーバに対応する通知実行アプリ５０２は、ステップＳ６０３で通知管理アプリ５０１にポーリングを高頻度に変更するよう通知管理アプリ５０１に要求する。そして、遠隔修理サーバに対応する通知実行アプリ５０２は、ステップＳ６０４で通知管理アプリ５０１に自身のアプリケーションＩＤを伝達し、通知管理アプリ５０１を高頻度ポーリングモードに移行させる。遠隔修理サーバ由来のイベント通知は、ステップＳ６０８でアプリケーションＩＤに基づいて処理対象と判定されるため、遠隔修理サーバに対応する通知実行アプリ５０２によって処理されるようになる。

【】

一方で、ファームウェア更新サーバに対応する通知実行アプリ５０２は、通知管理アプリ５０１に自身のアプリケーションＩＤを伝達していない。そのため、ファームウェア更新サーバ由来のイベント通知は、ステップＳ６０８で処理対象と判断されず、ステップＳ６１２におけるステータスの更新も行われない。そのため、通知管理サーバ１０２におけるファームウェア更新サーバ由来のイベント通知のステータスは“ＱＵＥＵＥＤ”を維持する。つまり、ファームウェア更新サーバ由来のイベント通知は次回のポーリングの際に再送され、高頻度ポーリングモード終了後に初めて対応する通知実行アプリ５０２によって処理される。これにより画像形成装置１０３は、高頻度ポーリングモード中は、対応優先度の高い遠隔修理サーバ由来のイベント通知を迅速に処理し、対応優先度の低いファームウェア更新サーバ由来のイベント通知の処理を見送ることができるようになる。

【】

以上説明したように、本実施形態によると、高頻度ポーリングモードへの移行を要求した通知実行アプリ５０２に対応するイベント通知を優先度の高いイベント通知として迅速に処理することが可能となる。これにより、高頻度ポーリングモード中、画像形成装置１０３は対応優先度の高いイベント通知を迅速に処理し、優先度の高くないイベント通知については優先度の高いイベント通知の処理が完了して高頻度ポーリングモード解除後に処理することができる。

【】

（第２実施形態）
第１実施形態では、高頻度ポーリングモード中、通知管理アプリ５０１がアプリケーションＩＤに基づいてイベント通知の処理を実行するかを判断する。そのため、１つの通知実行アプリ５０２が複数の異なる目的のイベント通知を処理する場合、対応優先度の高いイベント通知が迅速に処理されなくなる可能性が考えられる。例えば、ある１つの通知実行アプリ５０２が、遠隔から画像形成装置１０３の修理対応を行うためのイベント通知と、画像形成装置１０３のファームウェアを更新するためのイベント通知の双方を処理すると仮定する。この場合、画像形成装置１０３の利用者の業務を停止させないためにも、画像形成装置１０３は、遠隔から画像形成装置１０３の修理対応を行うためのイベント通知を最優先で処理する必要がある。しかしながら、修理対応目的のイベント通知とファームウェア更新のためのイベント通知を同時に受信し、通知管理アプリ５０１でファームウェア更新のためのイベント通知が先に処理される場合、修理目的のイベント通知の処理が後回しにされてしまう。そこで、第２実施形態では、通知管理アプリ５０１側だけでなく、通知実行アプリ５０２でもイベント通知の処理の判断を行う。

【】

通知実行アプリ５０２において、イベント通知の対応優先度の高さを判定できるようにするために、本実施形態の通知管理サーバ１０２は、イベント通知を生成する際に、イベント通知にイベント通知の対応優先度の高さを判定できる値を含める。例えば、通知管理サーバ１０２は、サービス用サーバ１０１からの指示に応じて、イベント通知の「ペイロード」属性の値に対応優先度の高さを示すフラグ情報を含める。対応優先度が高いイベント通知の「ペイロード」属性にはＴＲＵＥのフラグを付与し、対応優先度が高くないイベント通知の「ペイロード」属性にはＦＡＬＳＥのフラグを付与する。そして、本実施形態の通知実行アプリ５０２は、処理を要求されたイベント通知に含まれる処理の対応優先度の高さを示すフラグ情報に基づいて、イベント通知が処理対象であるか判定する。

【】

図９は、第２実施形態における通知処理全体のシーケンスを示した図である。ステップＳ８００からステップＳ８０８の処理は、第１実施形態のステップＳ６００からステップＳ６０８の処理とそれぞれ同様である。また、ステップＳ８１０からステップＳ８１３の処理は、第１実施形態のステップＳ６０９からステップＳ６１２の処理とそれぞれ同様である。ここでは、第１実施形態との差異であるステップＳ８０９について説明する。画像形成装置１０３が実行するＳ８０９の処理は、画像形成装置１０３のＣＰＵ３００がメモリ（ＲＯＭ３０２、二次記憶装置３０８）に記憶されたプログラム等を読み出して、実行することで実現される。

【】

ステップＳ８０９は、通知管理アプリ５０１により、ポーリングモードの変更要求を行った通知実行アプリ５０２のアプリケーションＩＤと通知管理サーバ１０２から受信したイベント通知のアプリケーションＩＤが一致すると判断された場合に実行される。Ｓ８０８でアプリケーションＩＤが一致する場合、通知管理アプリ５０１は、ポーリングモードの変更要求を行った通知実行アプリ５０２にアプリケーションＩＤが一致するイベント通知の処理を要求する。

【】

ステップＳ８０９では、通知実行アプリ５０２が、イベント通知の「ペイロード」属性の値を参照することで、そのイベント通知を処理するか否かを判断する。通知実行アプリ５０２は、「ペイロード」属性の値に基づいて処理対象であると判定した場合、ステップＳ８１０の処理を行う。ステップＳ８１０では、通知実行アプリ５０２はイベント通知を処理する。一方、通知実行アプリ５０２は、「ペイロード」属性の値に基づいて処理対象でないと判定された場合、ステップＳ８０８の処理に戻る。ステップＳ８０８では、通知管理アプリ５０１が次のイベント通知の処理判断を行う。

【】

図１０および図１１は、第２実施形態における画像形成装置１０３内でのイベント通知処理を説明するフローチャートである。図１０および図１１の各処理は、画像形成装置１０３のＣＰＵ３００がメモリ（ＲＯＭ３０２、二次記憶装置３０８）から各ソフトウェアモジュールを実行するためのプログラムをＲＡＭ３０１に読み出し、実行することにより実現される。

【】

ステップＳ９００からステップＳ９０７は、第１実施形態のステップＳ７００からＳ７０７とそれぞれ同様である。ステップＳ９０９からステップＳ９１３は、第１実施形態のステップＳ７０８からＳ７１２とそれぞれ同様である。ここでは、第１実施形態との差異であるステップＳ９０８について説明する。通知管理アプリ５０１により、Ｓ９０７で、高頻度ポーリングモードを要求した通知実行アプリ５０２にアプリケーションＩＤが一致するイベント通知の処理要求がされると、当該通知実行アプリ５０２は、ステップＳ９０８の処理を行う。

【】

Ｓ９０８では、通知実行アプリ５０２が、処理要求を受けたイベント通知の「ペイロード」属性の値を参照して、イベント通知を処理するか判断する。通知実行アプリ５０２は、「ペイロード」属性の値に含まれる対応優先度の高さを示すフラグ情報を参照し、フラグ情報が高い対応優先度を示す値であるＴＲＵＥの場合はステップＳ９０９の処理を行う。ステップＳ９０９では、通知実行アプリ５０２が、イベント通知の処理を行う。一方、「ペイロード」属性の値に含まれる対応優先度の高さを示すフラグ情報を参照し、フラグが高くない対応優先度を示す値であるＦＡＬＳＥの場合、通知実行アプリ５０２はそのイベント通知を処理せず、ステップＳ９１２の処理を行う。すなわち、通知実行アプリ５０２は、「ペイロード」属性の値に含まれるフラグ情報が高い対応優先度を示す値であるＴＲＵＥでない場合には、通知実行アプリ５０２はそのイベント通知を処理せず、ステップＳ９１２の処理を行う。

【】

以上説明したように、本実施形態によると、通知実行アプリ５０２においても、イベント通知を処理するかどうかの判断を行うことができるようになる。これにより、通知実行アプリ５０２が異なる複数種類のイベント通知を処理する場合でも、画像形成装置１０３の状況に応じて、適切に対応優先度の高いイベント通知の処理をすることが可能となる。

【】

（第３実施形態）
第１実施形態と第２実施形態では、通知管理サーバ１０２が管理するイベント通知に有効期限が設定されているため、画像形成装置１０３内でイベント通知の処理が見送られた結果、イベント通知の有効期限が経過してしまうケースが考えられる。この場合、有効期限を超過したイベント通知は通知管理サーバ１０２内から削除されてしまうため、高頻度ポーリングモード終了後にイベント通知を行うことができなくなる。そのため、当該イベント通知の生成を依頼したサービス用サーバ１０１の要求に応えることができなくなる。そこで、第３実施形態では、画像形成装置１０３が高頻度ポーリングモード中である際に処理が見送られたイベント通知を画像形成装置１０３に再度通知を行えるように管理を行う。そのため、本実施形態では、画像形成装置１０３が高頻度ポーリングモード中に限り、処理が見送られたイベント通知の有効期限を通知管理サーバ１０２が延長することができる形態を提供する。

【】

図１２は、第３実施形態におけるにおける通知処理全体のシーケンスを示した図である。ステップＳ１０００からステップＳ１０１１の処理は、第２実施形態におけるステップＳ８００からステップＳ８１１の処理とそれぞれ同様である。ここでは、第２実施形態との差異であるステップＳ１０１２～ステップＳ１０１４の処理について説明する。通知管理サーバ１０２が実行するステップＳ１０１３およびステップＳ１０１４の処理は、通知管理サーバ１０２のＣＰＵ２００がメモリ（ＲＡＭ２０１、二次記憶装置２０６）に記憶されたプログラム等を読み出して、実行することで実現される。画像形成装置１０３が実行するステップＳ１０１２の処理は、画像形成装置１０３のＣＰＵ３００がメモリ（ＲＯＭ３０２、二次記憶装置３０８）に記憶されたプログラム等を読み出して、実行することで実現される。

【】

ステップＳ１０１０で、対応優先度の高いイベント通知を処理した通知実行アプリ５０２は、処理結果を通知管理アプリ５０１に伝達する。イベント通知の処理結果を受け取った通知管理アプリ５０１は、ステップＳ１０１２の処理を行う。また、ステップＳ１００８またはステップＳ１００９でイベント通知が処理対象として判定されなかった場合にも、通知管理アプリ５０１は、ステップＳ１０１２の処理を行う。

【】

ステップＳ１０１２では、画像形成装置１０３内の通知管理アプリ５０１が、通知管理サーバ１０２に対して、イベント通知の処理のレスポンスを送信する。イベント通知がステップＳ１０１０で処理された場合、通知管理アプリ５０１は、当該イベント通知の処理結果を示すレスポンスを通知管理サーバ１０２に送信する。また、イベント通知がステップＳ１００８またはステップＳ１００９で処理対象として判定されなかった場合、通知管理アプリ５０１は、当該イベント通知の処理が見送られたことを示すレスポンスを通知管理サーバ１０２に送信する。例えば、通知管理アプリ５０１はイベント通知の処理が見送られたことを示すレスポンスとして“ＰＥＮＤＩＮＧ”を送信する。すなわち、通知管理アプリ５０１は通知管理サーバ１０２に対して、対応優先度が高いイベント通知については当該イベント通知の処理結果を通知し、対応優先度が高くないイベント通知については当該イベント通知の処理が見送られたことを通知する。

【】

ステップＳ１０１３では、通知管理サーバ１０２内の通知管理部４０２が、イベント通知の有効期限の調整を行う。ステップＳ１０１２で受信したレスポンスがイベント通知の処理結果を示す内容であった場合、通知管理部４０２は、イベント通知の「有効期限」属性の値を更新しない。一方で、ステップＳ１０１２で受信したレスポンスがイベント通知の処理が見送られたことを示す内容であった場合、通知管理部４０２はイベント通知の「有効期限」属性の値を更新する。例えば、通知管理部４０２は、現在時刻とイベント通知の「更新日時」属性の値の差分を「有効期限」属性の値に加算することで、イベント通知の「有効期限」属性の値の更新処理を行う。したがって、ステップＳ１０１３のイベント通知の有効期限の調整は、画像形成装置１０３の通知実行アプリ５０２においてイベント通知の処理が実施されなかった場合に行われる。

【】

ステップＳ１０１４では、通知管理サーバ１０２内の通知管理部４０２が、イベント通知のステータス更新を行う。Ｓ１０１３でイベント通知の「有効期限」属性の値が更新された場合、通知管理部４０２は「ステータス」属性の値を更新しない。つまり、イベント通知の「ステータス」属性の値は“ＱＵＥＵＥＤ”を維持し、当該イベント通知は、次回画像形成装置１０３からポーリングがあった際に、画像形成装置１０３内の通知管理アプリ５０１に再度送信される。それ以外の場合は、Ｓ８１３と同様の方法で、ベント通知管理部４０２は「ステータス」属性の値を更新する。

【】

図１３および図１４は、第３実施形態における画像形成装置１０３内でのイベント通知処理を説明するフローチャートである。図１３および図１４の各処理は、画像形成装置１０３のＣＰＵ３００がメモリ（ＲＯＭ３０２、二次記憶装置３０８）から各ソフトウェアモジュールを実行するためのプログラムをＲＡＭ３０１に読み出し、実行することにより実現される。ステップＳ１１００からステップＳ１１０９の処理は、第２実施形態のステップ９００からステップ９０９の処理と、それぞれ同様である。また、ステップＳ１１１１からステップＳ１１１３の処理は、第２実施形態のステップ９１１からステップＳ９１３の処理とそれぞれ同時である。ここでは、第２実施形態の差異であるステップＳ１１１０の処理について説明する。

【】

ステップＳ１１１０では、通知管理アプリ５０１が、通知管理サーバ１０２に対して、イベント通知の処理のレスポンスを送信する。イベント通知がステップＳ１１０９で処理された場合、通知管理アプリ５０１は通知管理サーバ１０２に対してステップＳ９１０と同様の方法で、イベント通知の処理結果を送信する。一方で、イベント通知の処理がＳ１１０６もしくはＳ１１０８で見送られた場合、通知管理アプリ５０１は、イベント通知の処理が見送られたことを示すレスポンスを通知管理サーバ１０２に対して送信する。したがって、イベント通知の処理が正常に行われた場合、通知管理アプリ５０１はイベント通知の処理成功を示すレスポンスの値として“ＡＣＣＥＰＴＥＤ”を通知管理サーバ１０２に送信する。一方でイベント通知の処理が失敗した場合、通知管理アプリ５０１はイベント通知の処理失敗を示すレスポンスの値として“ＥＲＲＯＲ”を通知管理サーバ１０２に送信する。イベント通知の処理が見送られた場合、通知管理アプリ５０１はイベント通知の処理が見送られたことを示すレスポンスの値として“ＰＥＮＤＩＮＧ”を通知管理サーバ１０２に送信する。レスポンスを受信した通知管理サーバ１０２は、レスポンスの値に基づいてイベント通知の処理が実行されたか否かと実行された場合の結果を認識することができる。レスポンスの値として“ＰＥＮＤＩＮＧ”を受信した場合、通知管理サーバ１０２は当該イベント通知の処理が見送られたこと認識することができ、ステップＳ１０１３でイベント通知の有効期限の調整を行うことが可能となる。

【】

以上説明したように、本実施形態によると、通知管理サーバ１０２は、画像形成装置１０３において処理がされなかった対応優先度が高くないイベント通知の有効期限を延長する調整することができる。これによりイベント通知は、処理が見送られたことによる有効期限切れ、また有効期限切れによる自動削除を回避することが可能となる。そして、高頻度ポーリングモードが解除された後の画像形成装置１０３からのポーリングに応じて、有効期限を延長したイベント通知を再度画像形成装置１０３に通知することが可能となる。本実施形態により、対応優先度が高くないイベント通知の生成要求を行ったサービス用サーバ１０１の要求に応えることが可能となる。

【】

本実施形態の開示は、以下のシステムの構成を含む。
（構成１）
サービスに対応するアプリケーションを有する画像形成装置と、前記サービスからの前記画像形成装置に対するイベント通知を管理する通知管理サーバとを含むシステムであって、
前記画像形成装置は、
ポーリングにより前記通知管理サーバに対してイベント通知要求を行い、前記通知管理サーバから前記画像形成装置に対するイベント通知を一括で受信する受信部と、
前記ポーリングが高頻度である場合に、受信した前記イベント通知が対応優先度の高いイベント通知であるか判断し、対応優先度の高いイベント通知である場合に前記イベント通知に対応するアプリケーションに前記イベント通知の処理を要求し、対応優先度の高いイベント通知でない場合には前記イベント通知の処理を要求しない通知管理処理を行う通知管理部と、
前記イベント通知の処理の要求を受けた場合に、前記イベント通知の処理を実行するアプリケーションと、を有し、
前記通知管理部は、前記イベント通知に含まれる該イベント通知の処理を行うアプリケーションを示す識別情報と、前記ポーリングの頻度の変更要求を行ったアプリケーションを示す識別情報が一致する場合に、前記イベント通知が対応優先度の高いイベント通知であると判断することを特徴とするシステム。
（構成２）
前記ポーリングの頻度の変更要求は、ポーリングの頻度を高頻度にする変更要求であり、
前記アプリケーションは、前記通知管理部に対してポーリングの頻度の変更要求を行った場合、前記通知管理部に前記アプリケーションの識別情報を送信し、
前記通知管理部は、前記アプリケーションから前記ポーリングの頻度の変更要求を受け付けた場合に該アプリケーションの識別情報を取得し、前記ポーリングの頻度の変更要求により高頻度で行われたポーリングにより受信するイベント通知に含まれる前記アプリケーションを示す識別情報との比較に利用することを特徴とする構成１に記載のシステム。
（構成３）
前記アプリケーションは、前記通知管理部から処理を要求された前記イベント通知に含まれる処理の対応優先度の高さを示すフラグ情報に基づいて、前記イベント通知が処理対象であるか判定し、前記フラグ情報が高い対応優先度を示す値である場合に前記イベント通知の処理を行い、前記フラグ情報が高い対応優先度を示す値でない場合には前記イベント通知の処理を行わないことを特徴とする構成１乃至３のいずれかに記載のシステム。
（構成４）
前記通知管理サーバは、
前記サービスからの要求に応じて画像形成装置に対するイベント通知を生成する生成部と、
生成した前記イベント通知を管理する管理部と、
前記画像形成装置からのポーリングによるイベント通知要求に対して前記イベント通知を画像形成装置に通知する通知部と、と有し、
前記画像形成装置の前記通知管理部は、前記アプリケーションにおけるイベント通知の処理の結果を前記通知管理サーバに送信し、
前記管理部は、前記イベント通知のステータスおよび有効期限を管理することを特徴とする構成１乃至４のいずれかに記載のシステム。
（構成５）
前記ポーリングが高頻度である場合に対応優先度の高いイベント通知でないと判断されて処理されなかったイベント通知は、前記ポーリングの高頻度が解除された後のポーリングにより再び前記通知管理サーバから前記画像形成装置に通知され、前記画像形成装置の前記アプリケーションにより処理されることを特徴とすることを特徴とする構成４に記載のシステム。
（構成６）
前記画像形成装置の前記通知管理部は、イベント通知の処理が行われなかった場合には、イベント通知の処理が行われなかったことを示すレスポンスを前記通知管理サーバに送信し、
前記管理部は、前記画像形成装置において処理が行われなかったイベント通知の有効期限を延長することを特徴とする構成４または５に記載のシステム。

【】

（その他の実施形態）
本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。

【】

以上、本発明の好ましい実施形態について説明したが、本発明は、これらの実施形態に限定されず、その要旨の範囲内で種々の変形および変更が可能である。

【図】

【図】

【図】

【図】

【図】

【図】

【図】

【図】

【図】

【図】

【図】

【図】

【図】

【図】