JP6287174B2 - 情報処理システム、情報処理装置、情報処理方法および情報処理プログラム - Google Patents

Description

本発明は情報処理の制御技術に関する。

Ｗｅｂ上で各種のサービス（Ｗｅｂサービス）を提供する手段として、ＳＯＡＰ（Simple Object Access Protocol）、ＲＥＳＴ（Representational State Transfer）と呼ばれる方式のＷｅｂＡＰＩ（Web Application Program Interface）が多く使われている。ＷｅｂＡＰＩのベースとなっているのはＨＴＴＰプロトコル（HyperText Transfer Protocol）での通信であり、サービス提供側はＨＴＴＰサーバとなってＷｅｂＡＰＩを提供し、サービス利用側はＨＴＴＰクライアントとなってそのＷｅｂＡＰＩを利用する。

一方、情報処理システムまたは情報処理装置の一例として、ＬＰ（Laser Printer）、ＭＦＰ（Multi Function Peripheral、Multi Function Printer）等の画像形成装置が挙げられる。この種の画像形成装置では、画面表示やキー入力の操作を行う部分を操作部として本体部（コントローラ、エンジン）から独立させ、本体部の負荷が高くても操作レスポンスを低下させないようにすることが考えられている。操作部にはAndroid（登録商標） OS等の独立したＯＳ（Operating System）が搭載され、本体部とは独立に動作する。

このような操作部を備えた画像形成装置内においても、前述したＲＥＳＴ方式のＷｅｂＡＰＩが用いられることが考えられ、操作部上のアプリ（アプリケーションプログラム）は、本体部が提供するＷｅｂＡＰＩを利用して機能を実現することになる。

クライアントからのリクエストに対して、サーバがレスポンスを返す、というのが一般的なＨＴＴＰ通信の基本である。そのため、ＨＴＴＰ通信では、サーバ側で任意のタイミングで発生した状態変化（イベント）をクライアント側に通知することが原理的にできないアーキテクチャとなっている。

これまでも、サーバ側で発生した状態変化をクライアントに通知するために、複数の方式が検討されてきた。代表的なものとして、ポーリング方式と呼ばれる、一定期間毎にクライアントがサーバに問い合わせを行い、サーバ側の状態変化をチェックする方式が一般的に知られている。

また、疑似的にクライアントに対してサーバ側の状態変化を通知する手段として、Ａｊａｘ（Asynchronous JavaScript（登録商標） + XML（Extensible Markup Language））、ＬｏｎｇＰｏｌｌｉｎｇ、Ｃｏｍｅｔといった方式が一般的によく知られている（特許文献１等を参照。）。

上述したように、ＨＴＴＰサーバからＨＴＴＰクライアントに対して、サーバの状態変化を通知する方式は複数考えられてきた。

一方、前述した画像形成装置の本体部から独立して動作する操作部への適用を想定すると、操作部上のアプリは本体部が提供するＷｅｂＡＰＩを利用してアプリの機能を実現する。しかし、これらの本体部や操作部には通信に利用できるリソースが充分ではなく、通信のリソースを圧迫しない手法で状態変化の通知を実現することが望まれる。

例えば、これらの本体部や操作部で同時に接続できるセッション数には限りがあるため、アプリの起動時から終了時まで接続し続けるような生存期間の長いセッションが存在した場合、それによって、利用可能なセッション数が圧迫してしまう。また、生存期間の長いセッションが増加すると、通信処理の負荷が高くなり、その結果、画像処理等の本来の機能における性能への影響も懸念される。

本発明は上記の従来の問題点に鑑み提案されたものであり、その目的とするところは、クライアントとなる情報処理装置に対してサーバとなる情報処理装置の状態変化を通知する際に、通信のリソースを圧迫しないものとすることにある。

上記の課題を解決するため、本発明にあっては、第１の情報処理装置から第２の情報処理装置に対して状態通知のリクエストを送信し、前記第２の情報処理装置から前記第１の情報処理装置に対して状態通知のレスポンスを送信する情報処理システムであって、前記第１の情報処理装置は、通知すべき状態の種類を設定するリクエストまたは状態通知のリクエストを前記第２の情報処理装置に送信する手段と、通知すべき状態の種類を設定するリクエストおよび状態通知のリクエストに伴う、リクエスト送信元のクライアントを前記第２の情報処理装置に識別させる識別情報を取得する手段とを備え、前記第２の情報処理装置は、前記第１の情報処理装置から通知すべき状態の種類を設定するリクエストを受信した場合に、通知すべき状態の種類を内部に保持し、設定完了のレスポンスを前記第１の情報処理装置に対して送信する手段と、通知すべき状態変化が発生した場合に、前記第１および第２の情報処理装置間に維持されるセッションを用いて、状態の種類と状態の値を含むレスポンスを前記第１の情報処理装置に対して送信する手段と、同じ識別情報を有するクライアントから状態通知のリクエストを受信した場合に、当該リクエストが無効であることを前記第１の情報処理装置に通知する手段とを備えるようにしている。

本発明にあっては、クライアントとなる情報処理装置に対してサーバとなる情報処理装置の状態変化を通知する際に、通信のリソースを圧迫しないものとすることができる。

本発明の一実施形態にかかる画像形成装置のハードウェア構成例を示す図である。 ネットワーク構成例を示す図である。 画像形成装置のソフトウェア構成例を示す図である。 プリンタに関するＷｅｂＡＰＩの例を示す図である。 ＷｅｂＡＰＩによる印刷処理の例を示すシーケンス図である。 ＨＴＴＰ通信の例を示す図である。 ＨＴＴＰデータの構造を示す図である。 分割したレスポンスとＨＴＴＰデータの関係の例を示す図である。 データ書式の例を示す図である。 クライアントが必要な状態変化毎にセッションを張る場合の処理例を示す図である。 １つのクライアントに対して状態変化通知用のセッションを１つだけとする場合の処理例を示す図である。 画像形成装置が通知する状態変化の例を示す図である。 ＷｅｂＡＰＩによる状態通知の処理例を示すシーケンス図である。 状態変化通知に関するＷｅｂＡＰＩの例を示す図である。 状態変化通知種類設定リクエストによる設定例を示す図である。 状態変化通知種類テーブルの例を示す図である。 状態変化発生時の処理例を示すフローチャートである。 クライアントに通知されるレスポンスデータの例を示す図である。 印刷ジョブの状態変化に対するデータの例を示す図である。 機器の状態変化に対するデータの例を示す図である。 機器システムの状態変化に対するデータの例を示す図である。 ＷｅｂＡＰＩによる状態通知の処理例を示すシーケンス図である。 状態変化通知リクエストを受信したサーバ側の処理例を示すフローチャートである。 クライアント管理テーブルの例を示す図である。

以下、本発明の好適な実施形態につき説明する。なお、情報処理システムまたは情報処理装置として画像形成装置を例に説明するが、画像形成装置以外の情報処理システムまたは情報処理装置にも適用できることは言うまでもない。

＜構成＞
図１は本発明の一実施形態にかかる画像形成装置１のハードウェア構成例を示す図である。

図１において、画像形成装置１は、本体部（コントローラ、エンジン）２と操作部３とを備えている。操作部３は本体部２に有線路または無線路により接続される。

本体部２は、その時設定されている制御モードおよびホストコンピュータ４等からの制御コードに従って、ホストコンピュータ４からの印字データをビデオデータに変換し、プリンタエンジン２１２へ出力する機能を有している。また、本体部２は、スキャナエンジン２１３により原稿画像を読み込み、プリンタエンジン２１２に出力することでコピーを行ない、あるいは、読取画像をホストコンピュータ４等に出力する機能を有している。

操作部３は、タッチパネルを備え、独自のＯＳを搭載したコンピュータ装置である。

本体部２は、ＣＰＵ２０１とＲＡＭ２０２とＮＶ−ＲＡＭ２０３とプログラムＲＯＭ２０４とフォントＲＯＭ２０５とネットワークインタフェース２０６と操作部インタフェース２０７とプリンタエンジンインタフェース２０８とスキャナエンジンインタフェース２０９とＨＤＤ２１０とオプションＲＡＭ２１１とプリンタエンジン２１２とスキャナエンジン２１３とを備えている。

ＣＰＵ２０１は、ホストコンピュータ４等からのデータ（印字データ、制御データ）を処理する。

ＲＡＭ２０２は、ＣＰＵ２０１が処理する時のワークメモリ、ホストコンピュータ４等からのデータをページ単位に管理して一時記憶するバッファ、バッファに記憶されたデータを実際の印字パターンに変換しビデオデータを記憶するビットマップメモリ等に使われる。

ＮＶ−ＲＡＭ２０３は、電源を切っても保持したいデータを格納しておくための不揮発性ＲＡＭである。

プログラムＲＯＭ２０４は、本体部２内でのデータの管理や、周辺モジュールを制御するためのプログラムが格納されている。

フォントＲＯＭ２０５は、印字に使用されるさまざまな種類のフォントデータが格納されている。

ネットワークインタフェース２０６は、ホストコンピュータ４から画像形成装置１への制御信号やデータ、画像形成装置１からホストコンピュータ４へのステータス信号やデータインターフェースである。

操作部インタフェース２０７は、操作部３との間での制御信号やデータのインタフェースである。

プリンタエンジンインタフェース２０８は、プリンタエンジン２１２への制御信号やデータ、プリンタエンジン２１２からのステータス信号のインタフェースである。

スキャナエンジンインタフェース２０９は、スキャナエンジン２１３への制御信号、スキャナエンジン２１３からのステータス信号やデータのインタフェースである。

ＨＤＤ２１０は、大容量の記憶装置である。

オプションＲＡＭ２１１は、追加的に装着されるＲＡＭである。

プリンタエンジン２１２は、プリンタエンジンインタフェース２０８を介して与えられるビデオ信号および制御信号により感光体上に静電潜像を作り、現像し、また給紙部より転写紙を給紙し、転写および定着し、画像を形成する。

スキャナエンジン２１３は、原稿を光学的に読み取り、画像情報を出力する。

図２はネットワーク構成例を示す図である。

図２において、ネットワーク上には、複数のホストコンピュータ４Ａ、４Ｂ、４Ｃと画像形成装置１が接続されている。

画像形成装置１は、本体部２と操作部３とを備えている。操作部３は、本体部２との間で有線または無線で直接に接続されるほか、ネットワーク上のアクセスポイント（図示せず）を介して本体部２に接続することもできる。操作部３上のアプリは本体部２が提供するＷｅｂＡＰＩを使ってアプリの機能を実現する。

ホストコンピュータ４Ａ、４Ｂ、４Ｃは、画像形成装置１に対して印刷を要求したり、原稿の読取画像の送信を受けたりすることができるとともに、画像形成装置１（本体部２）の提供するＷｅｂＡＰＩを使ってＷｅｂサービスを利用することができる。

図３は画像形成装置１のソフトウェア構成例を示す図である。なお、操作部３上のアプリが本体部２の提供するＷｅｂサービスを利用するクライアントとなる場合を例として説明するが、操作部３上のアプリに限定されるものではなく、ホストコンピュータ４上のアプリ（ＰＣアプリ、サーバアプリ）等がクライアントとなってもよい。

図３において、本体部２は、サービス提供モジュール群２３０を構成するネットワーク管理モジュール２２５とＷｅｂサービス提供モジュール２２６と印刷管理モジュール２２７とシステム管理モジュール２２８とメモリ管理モジュール２２９とを備えている。また、本体部２は、サービス提供モジュール群２３０の各モジュールの機能を利用するプリンタジョブ管理モジュール２２２とコピージョブ管理モジュール２２３とスキャナジョブ管理モジュール２２４とを備えている。また、本体部２は、プリンタジョブ管理モジュール２２２が利用するＰＤＬ解析モジュール２２１を備えている。

操作部３は、操作部アプリ３０１〜３０３を備えている。操作部アプリ３０１〜３０３は、操作部３上で動作するアプリであり、ＪＡＶＡ（登録商標）やＡｎｄｒｏｉｄ（登録商標）ＳＤＫや本体部２が独自に提供するＡＰＩを利用して、様々な機能をもつアプリを開発することが可能である。なお、操作部アプリの数は図示のものに限定されるものではなく、１つでもよいし、４以上でもよい。ここでは、操作部アプリ３０１〜３０３は、Ｗｅｂサービスのクライアントとして動作するものとしている。

本体部２のＰＤＬ解析モジュール２２１は、画像形成装置１がホストコンピュータ４等から受信したＰＤＬデータを解析して印刷画像を生成するモジュールである。プリンタジョブ管理モジュール２２２よりＰＤＬデータを受け取り、プリンタジョブ管理モジュール２２２の仲介によりメモリ管理モジュール２２９から確保したメモリ上に印刷画像を生成することが主な責務である。また、印刷画像生成の際には機器構成情報、例えば、給紙トレイ・排紙トレイの構成や、給紙トレイ内の用紙サイズといった情報が必要になるが、これらの情報はプリンタジョブ管理モジュール２２２の仲介によりシステム管理モジュール２２８から得る。

プリンタジョブ管理モジュール２２２は、ＰＤＬ処理全般に関わる制御を行っており、主にＰＤＬ解析モジュール２２１側が必要とする処理を仲介して他モジュールに対して要求を行うモジュールである。ネットワーク管理モジュール２２５が受け取ったＰＤＬデータをＰＤＬ解析モジュール２２１へ受け渡す仲介、ＰＤＬ解析モジュール２２１に対しシステム管理モジュール２２８が管理する機器情報を取得する仲介、ＰＤＬ解析モジュール２２１がメモリ管理モジュール２２９から必要なメモリを確保する仲介、ＰＤＬ解析モジュール２２１が作成した印刷画像に関し印刷管理モジュール２２７に対する印刷要求の発行、といったことを行う。

コピージョブ管理モジュール２２３は、コピー処理全般に関する制御を行っており、サービス提供モジュール群２３０を利用してコピー機能を実現するのが主な責務である。

スキャナジョブ管理モジュール２２４は、スキャン処理全般に関する制御を行っており、サービス提供モジュール群２３０を利用してスキャナ機能を実現するのが主な責務である。

ネットワーク管理モジュール２２５は、ネットワークコントローラ（図示せず）の管理と、ネットワークコントローラから得られる受信データの処理を制御するモジュールである。ホストコンピュータ４からのデータ受信の際に欠かせない通信プロトコル（ｆｔｐやｌｐｒなど）を制御してネットワークコントローラからデータを受信し、他モジュールへ受信データを受け渡すことが主な責務である。Ｗｅｂサービス提供においては、クライアントからのＨＴＴＰ（ＲＥＳＴ）アクセスによるデータを受信し、Ｗｅｂサービス提供モジュール２２６に受け渡す。

Ｗｅｂサービス提供モジュール２２６は、ＲＥＳＴ／ＳＯＡＰ用のＨＴＴＰサーバとして動作し、クライアントに対してＷｅｂサービスを提供するモジュールである。様々な機能をＷｅｂサービスとして提供するために、画像形成装置１内の他のモジュールと連携する。例えば、プリンタ印刷機能を提供するためにはプリンタジョブ管理モジュール２２２と連携する。また、コピージョブ管理モジュール２２３、スキャナジョブ管理モジュール２２４と連携し、コピー機能、スキャナ機能をＷｅｂサービスとして提供する。なお、図には記載していないが、ファックス機能を実現するモジュールと連携してファックス機能をＷｅｂサービスとして提供することもできる。Ｗｅｂサービス提供モジュール２２６は、ＨＴＴＰクライアントからのリクエスト受信、クライアントへのレスポンス送信、サーバ・クライアント間で受け渡しするメッセージに含まれるＪＳＯＮ（JavaScript Object Notation）データのシリアライズ・デシリアライズなどが主な責務である。

印刷管理モジュール２２７は、ＰＤＬ解析モジュール２２１が生成した印刷画像の印刷処理に関する制御を行うモジュールである。メモリ管理モジュール２２９が管理するメモリ／外部記憶装置内に格納された印刷画像を、プリンタエンジンに印刷させるために必要な各種処理を実行するのが主な責務であり、給排紙命令の発行、後処理実行命令の発行、印刷に関わるエラー状態の検知と他モジュールへの通知などを行う。

システム管理モジュール２２８は、画像形成装置１の機器構成情報や機器状態を管理・制御するモジュールである。機器構成情報とは、給紙トレイや排紙トレイの着脱の情報や給紙トレイ内の用紙構成といった情報であり、機器状態とは、印刷中・待機中、ジャムや用紙切れなどのエラー発生中といった内容である。こうした情報を他モジュールへ通知する他、ユーザによる機器設定（設定により動作を変化させるカスタマイズ可能項目等）の管理が主な責務である。

メモリ管理モジュール２２９は、メモリおよび外部記憶装置を管理するモジュールであり、他モジュールの要求に基いてメモリおよび外部記憶装置の割り当て・解放を行うことが主な責務である。

サービス提供モジュール群２３０は、各種サービスを提供するモジュールの総称である。サービス提供モジュール群２３０の各モジュールは互いに通信をし合って画像形成装置１の基本動作を分担し、協力して上位層からの要求に対応する。

＜ＷｅｂＡＰＩの例＞
画像形成装置１の本体部２は様々なＷｅｂサービスをＷｅｂＡＰＩにより提供している。例えば、コピー、プリンタ、スキャナなどのジョブを実行するＡＰＩや、それぞれのジョブの状態をクライアントに通知するＡＰＩがある。

図４は画像形成装置１の本体部２が提供するプリンタに関するＷｅｂＡＰＩの例を示している。図示のＵＲＩ（Uniform Resource Identifier）とメソッドを用い、必要に応じてパラメータを指定することで、所定の処理のリクエストを行うことができる。

これらのＷｅｂＡＰＩを利用するクライアントは、ネットワーク接続されたホストコンピュータ４上のアプリケーションや操作部３上で動作する操作部アプリ３０１〜３０３など様々である。

＜印刷処理の動作例＞
図５はＷｅｂＡＰＩによる印刷処理の例を示すシーケンス図である。

図５において、ＨＴＴＰクライアントとなるホストコンピュータ４が印刷実行のＨＴＴＰリクエストを画像形成装置１に送信すると、本体部２のネットワーク管理モジュール２２５が受信する（ステップＳ１０１）。印刷実行のＨＴＴＰリクエストは、例えば、前述した"/printer/job/"というＵＲＩを指定して送信する。

ネットワーク管理モジュール２２５はＨＴＴＰリクエストを受け取ると、Ｗｅｂサービス提供モジュール２２６に印刷実行のリクエストを通知する（ステップＳ１０２）。

Ｗｅｂサービス提供モジュール２２６はリクエストに対応するモジュールに処理実行を通知する。この例では、プリンタジョブ管理モジュール２２２に印刷実行のリクエストを通知する（ステップＳ１０３）。より詳しくは、起動時のタイミング等においてＵＲＩとそれに対応するイベントハンドラを登録しておくことで、Ｗｅｂサービス提供モジュール２２６は委譲先となるモジュールを判断し、そのモジュールに通知を行う。

プリンタジョブ管理モジュール２２２は、印刷実行のリクエストに含まれるヘッダおよびボディを解析し（ステップＳ１０４）、ＰＤＬ解析モジュール２２１に画像生成を要求する（ステップＳ１０５）。

ＰＤＬ解析モジュール２２１から画像生成の終了のレスポンスがあると（ステップＳ１０６）、プリンタジョブ管理モジュール２２２は印刷管理モジュール２２７に印刷処理実行を指示する（ステップＳ１０７）。

印刷管理モジュール２２７から印刷処理の終了のレスポンスがあると（ステップＳ１０８）、プリンタジョブ管理モジュール２２２はＷｅｂサービス提供モジュール２２６にレスポンスとして結果を通知する（ステップＳ１０９）。

Ｗｅｂサービス提供モジュール２２６も同様にネットワーク管理モジュール２２５にレスポンスを通知し（ステップＳ１１０）、最終的にＨＴＴＰクライアントのホストコンピュータ４にＨＴＴＰレスポンスが通知される（ステップＳ１１１）。

ここでは、例としてプリンタでの印刷実行処理を示したが、その他の機能についてもＷｅｂサービス提供モジュール２２６が対応するモジュールに処理実行を通知することで実現される。

＜分割レスポンスの動作例＞
ＷｅｂサービスはＨＴＴＰ通信によりサーバとクライアントで情報交換することが基本的な思想である。

図６はＨＴＴＰ通信の例を示す図であり、ＨＴＴＰクライアントとサーバの間のＨＴＴＰ通信を模式的に表している。ＨＴＴＰ通信は、ＨＴＴＰクライアントからサーバに対してヘッダとボディから構成されるＨＴＴＰリクエストを送信し、サーバはＨＴＴＰクライアントに、同じくヘッダとボディから構成されるＨＴＴＰレスポンスを送信する。これにより、ＨＴＴＰクライアントとサーバの間で情報の送受信を行っている。図７はＨＴＴＰデータの構造を示す図であり、ヘッダとボディを含んでいる。

ＨＴＴＰ通信のプロトコル上、常にＨＴＴＰクライアントからＨＴＴＰリクエストを出し、サーバはそのＨＴＴＰリクエストに応答することが基本原理である。通常は、ＨＴＴＰクライアントからのＨＴＴＰリクエストに対して、サーバがＨＴＴＰレスポンスを送信した時点で、リクエスト処理は完結し、その後、ＨＴＴＰクライアントがＨＴＴＰリクエストを出すまでは、サーバはＨＴＴＰクライアントに情報を伝えることはできない。

そこで、サーバからのＨＴＴＰレスポンスによりリクエスト処理が完結しないように、ＨＴＴＰレスポンスを分割して送信する。図８は分割したレスポンスとＨＴＴＰデータの関係の例を示す図である。

サーバの状態変化を検出したいＨＴＴＰクライアントは、サーバに対して状態通知のＨＴＴＰリクエストを送信する。サーバは、ＨＴＴＰクライアントから接続された段階でまずヘッダ部分だけ応答する。通常、ヘッダにはデータサイズを示すContent-Lengthを記載することが一般的だが、今回は予め応答するデータサイズが分からない。したがって、Content-Lengthは記載せずにヘッダを応答することになる。なお、Content-Lengthを含まなくてもＨＴＴＰ仕様として問題はない。

その後、ボディ部分の送信処理はサーバで状態変化あるまで行わない。ＨＴＴＰクライアントはサーバからの応答待ちの状態になる。

サーバでエラー発生など何らかの状態変化が発生したタイミングで、状態変化を示すボディの一部をＨＴＴＰクライアントに送信する。ボディの一部の送信が完了しても、サーバは完了を送信しないため、ＨＴＴＰクライアント／サーバともにボディ部分の送受信中の状態を維持している。

これらの処理を、サーバの状態変化が発生する度に繰り返し実行することで、ＨＴＴＰクライアントのタイミングに依存しない状態通知が実現できる。

最終的にはヘッダとボディからなるＨＴＴＰプロトコルに従ったデータとなる。このことにより、一般的なＨＴＴＰ通信を行えるソフトウェアや動作環境で実現可能となる。

ＨＴＴＰクライアントは、一定期間にわたってサーバから応答が無い場合、通信を切断する場合がある。一定期間にわたってサーバで状態変化が発生しない場合は、サーバから状態変更なしを示すボディの一部を送信することで通信を維持することができる。

図９はデータ書式の例を示す図である。

ＨＴＴＰでは、テキストデータ、画像データ、ＸＭＬ、ＪＳＯＮなど様々な種類のデータ送信が可能である。Ｗｅｂサービスの用途としては、最近はＪＳＯＮ形式でデータを送受信するケースが多い。

図９（ａ）は通常のＨＴＴＰレスポンスにおいてＪＳＯＮ形式を用いた場合を示しており、ヘッダのContent-Typeにjsonが指定されている。ボディは全体がＪＳＯＮ形式で記述されている。

図９（ｂ）は分割レスポンスにＪＳＯＮ形式を用いた場合を示しており、ボディの個々の部分データをＪＳＯＮ形式で記述し、区切り文字列（例えば、改行を２個）を付加している。この場合、ボディ全体はＪＳＯＮ形式とはならないため、ヘッダのContent-Typeはtext/plainとなっている。

ＨＴＴＰクライアントは部分データの個々を受信することに意味があるため、個々の部分データがＪＳＯＮ形式等の所定のデータ形式である方が、ＨＴＴＰクライアント側も処理が容易となる。

ＨＴＴＰクライアントは、ＨＴＴＰプロトコルに従い順次に受信データを読み出す。このとき、各データ部分の最後に付された区切り文字列により、個々の部分データを区別して読み出すことができる。

＜分割レスポンスによるセッション数＞
画像形成装置等の情報処理装置がクライアントに通知すべき状態変化には複数の種類がある。例えば、
・印刷ジョブの状態変化（印刷ジョブが処理中／待機中／排紙枚数変化等）
・機器の状態変化（機器が印刷ジョブ処理中／待機中／メンテナンス中等）
・機器システムの状態変化（ユーザーのログイン／ログアウト状態変化等）
等があげられる。

これらの状態変化のうち、どの情報を通知してほしいかはクライアント毎に異なるのが一般的である。

このような場合に分割レスポンスの利用を考えると、クライアント側／サーバ側双方の設計として、「クライアントが必要な状態変化毎にセッションを張り、サーバ側はそのセッションに分割レスポンスを返す」とすると、設計がシンプルであり、かつ、実装も容易である。

図１０はクライアントが必要な状態変化毎にセッションを張る場合の処理例を示す図である。図示の例では、操作部３の操作部アプリＡと本体部２の間には印刷ジョブの状態変化通知用セッションと機器の状態変化通知用セッションが、操作部アプリＢと本体部２の間には印刷ジョブの状態変化通知用セッションが、操作部アプリＣと本体部２の間には機器の状態変化通知用セッションと機器システムの状態変化通知用セッションが張られている。

しかし、この設計では、接続されるセッション数は最大で『クライアント数×状態変化の種類』となってしまい、通信のリソースを圧迫する可能性がある。

そこで、
・クライアント毎に状態変化通知用セッションを１つだけとする
・クライアントが必要な状態変化をサーバ側に通知する手段を設ける
・クライアントへのレスポンスに状態変化の種類情報を付加する
とすることで、１つのクライアントに対するセッションを１本としたまま、クライアントが必要な状態変化を通知することができる。

図１１は１つのクライアントに対して状態変化通知用のセッションを１つだけとする場合の処理例を示す図である。図示の例では、操作部３の操作部アプリＡ、Ｂと本体部２の間には、それぞれ１本の状態変化通知用セッションが張られている。この状態で、操作部アプリＡから別のセッションにより印刷ジョブの状態変化通知リクエストを行ない（ステップＳ１）、続いて、機器の状態変化通知リクエストを行なう（ステップＳ２）。本体部２側では、要求されていた状態変化があると、操作部アプリＡに対して状態変化通知を分割レスポンスにより行う（ステップＳ３）。

このように、１つのクライアントに対して、状態変化通知用（分割レスポンス用）のセッションを常に１つにすることができるようになるため、通信のリソースを圧迫することがなくなる。

＜状態通知の動作例＃１＞
図４に示したようなＷｅｂＡＰＩを利用すれば、本体部２の機能を操作部３の操作部アプリやホストコンピュータ４のアプリ等から利用することができる。しかし、本体部２の機能を利用する他に本体部２で発生した状態変化をクライアントに通知する必要がある。例えば、プリンタで紙詰まりが発生した場合、これをクライアントに通知し、これを通知されたクライアント側は紙詰まりが発生していることを示す画面を表示する必要がある。

クライアントに通知すべき状態変化には複数の種類があるが、画像形成装置が通知する状態変化の例を図１２に示す。図示の例では、印刷ジョブの状態変化と、機器の状態変化と、機器システムの状態変化を例にあげている。

クライアントは図４に示したＷｅｂＡＰＩと図１２に示した状態変化の通知を利用して、アプリを開発することができる。図１２に示した状態変化のうち、どの情報を通知してほしいかはクライアント毎に異なるのが一般的である。例えば、印刷を実行するアプリであれば、「印刷ジョブの状態変化」と「機器の状態変化」の通知が必要となる。機器状態を管理するようなアプリであれば、「機器の状態変化」と「機器システムの状態」の通知が必要となる。

図１３はＷｅｂＡＰＩによる状態通知の処理例を示すシーケンス図である。なお、操作部３の操作部アプリ３０１が本体部２に対して状態変化通知リクエストを行う場合を例としている。

図１３において、クライアントとなる操作部３の操作部アプリ３０１は、サーバとなる本体部２に対して、どの状態変化通知が必要かを設定するための状態変化通知種類設定リクエストを送信する（ステップＳ１１）。図１４は状態変化通知に関するＷｅｂＡＰＩの例を示す図であり、ＵＲＩ「/printer/events/lists」、メソッド「PUT」によって状態変化通知種類設定リクエストを行う。状態変化通知種類設定リクエストではＪＳＯＮ形式などあらかじめ決められたデータ構造に従って、通知してほしい状態変化種類を設定する。図１５は状態変化通知種類設定リクエストによる設定例を示す図である。図示の例では、印刷ジョブの状態変化と機器の状態変化については要求するものとし、機器システムの状態変化については要求しないものとしている。

図１３に戻り、本体部２のＷｅｂサービス提供モジュール２２６は、状態変化通知種類設定リクエストを受信すると、どの状態変化を通知する必要があるかを記憶しておく状態変化通知種類テーブルの内容を更新する（ステップＳ１２）。図１６は状態変化通知種類テーブルの例を示す図であり、図１５の状態変化通知種類設定リクエストの設定内容に対応している。

図１３に戻り、その後、本体部２は操作部アプリ３０１に設定完了のレスポンスを操作部アプリ３０１に送信する（ステップＳ１３）。これにより、状態変化通知種類設定リクエストからのセッションは切れる。

次いで、クライアントとなる操作部３の操作部アプリ３０１は、サーバとなる本体部２に対して、状態変化通知リクエストを送信する（ステップＳ１４）。状態変化通知リクエストは、図１４に示したＵＲＩ「/printer/events」、メソッド「GET」によって行う。

図１３に戻り、本体部２は分割レスポンスの初回分として、ヘッダのみの部分的なレスポンスを操作部アプリ３０１に送信する（ステップＳ１５）。その後、サーバ側は状態変化が発生した場合、このリクエストに対する分割レスポンスでクライアントに状態変化を通知する。このリクエストによって形成されるセッションは生存期間の長いセッションとなる。

図１７は状態変化発生時の処理例を示すフローチャートである。

図１７において、サーバは何かしらの状態変化が発生した際、状態変化通知種類テーブルを参照し（ステップＳ１６）、対象の状態変化に対する通知要求があるかどうか判断する（ステップＳ１７）。通知要求がされていない状態変化の場合（ステップＳ１７のＮＯ）、処理は終了となる。

そして、通知要求がされている状態変化の場合（ステップＳ１７のＹＥＳ）、状態変化種類に合わせたレスポンスデータ（分割レスポンスによる部分的なレスポンスデータ）を生成し（ステップＳ１８）、それをクライアントに送信する（ステップＳ１９）。図１８はクライアントに通知されるレスポンスデータの例を示す図である。また、図１９は印刷ジョブの状態変化に対するデータの例、図２０は機器の状態変化に対するデータの例、図２１は機器システムの状態変化に対するデータの例を示している。これらは、ＪＳＯＮ形式等により記述される。

このように、クライアント毎に状態変化通知要求を１つだけ（生存期間の長いセッションを１つだけ）として、クライアントが必要な状態変化をサーバ側に通知する手段を設け、クライアントへのレスポンスに状態変化の種類情報を付加することで、１つのクライアントに対する状態変化通知用セッションを１本としたまま、クライアントが必要な状態変化を通知することができる。

＜状態通知の動作例＃２＞
上述した状態通知の動作例＃１では、１つのクライアントに対する状態変化通知用セッションを１本としたまま、クライアントが必要な状態変化を通知する方式について示した。しかし、動作例＃１の方式では同一クライアントから状態変化通知リクエストがきた場合でも、状態変化通知用セッションを形成してしまう。一般に公開されるＷｅｂＡＰＩではクライアントにＡＰＩの利用方法を強制することは難しいため、同一クライアントから２回以上の状態変化通知リクエストがくることは十分に起こりえる。

そこで、動作例＃２では、同一クライアントからの状態変化通知リクエストがきた場合、新規に状態変化通知用セッションを形成するのではなく、要求が無効である旨をレスポンスデータとして返すようにしている。

図２２はＷｅｂＡＰＩによる状態通知の処理例を示すシーケンス図である。

図２２において、クライアントとなる操作部３の操作部アプリ３０１がサーバとなる本体部２に対して要求元識別ＩＤ発行リクエストを送信すると（ステップＳ２１）、本体部２は要求元識別ＩＤを発行し、要求元識別ＩＤを含むレスポンスを操作部アプリ３０１に送信する（ステップＳ２２）。

その後、操作部アプリ３０１が要求元識別ＩＤを伴う状態変化通知種類設定リクエストを本体部２に送信すると（ステップＳ２３）、本体部２は処理完了によりレスポンスを操作部アプリ３０１に送信する（ステップＳ２４）。

その後、操作部アプリ３０１は本体部２に要求元識別ＩＤを伴う状態変化通知リクエストを送信する（ステップＳ２５）。

図２３は状態変化通知リクエストを受信したサーバ側の処理例を示すフローチャートである。

図２３において、本体部２は状態変化通知リクエストを受信すると、クライアント管理テーブルを参照する（ステップＳ２０１）。

図２４はクライアント管理テーブルの例を示す図である。クライアント管理テーブルにはサーバ側で発行した要求元識別ＩＤを登録し、状態変化通知リクエストがされたクライアントが登録されている否かを確認するのに用いる。今の例では、クライアントを識別するためのＩＤをサーバ側で発行しているが、クライアントを特定する情報であれば、発行する方式をとる必要はない。例えば、クライアントのＩＰアドレス等を利用する等が考えられる。

図２３に戻り、本体部２は状態変化通知リクエストを送信してきたクライアントがクライアント管理テーブルに登録されているか判断する（ステップＳ２０２）。

クライアント管理テーブルに登録されていない場合（ステップＳ２０２のＮＯ）、クライアント管理テーブルに登録する（ステップＳ２０３）。また、そのクライアントは状態変化通知用セッションをまだ形成していないため、状態変化通知用セッションを形成する（ステップＳ２０４）。

クライアント管理テーブルに既に登録されている場合（ステップＳ２０２のＹＥＳ）、既に状態変化通知用セッションを形成しているため、リクエストが無効であることをクライアントに通知する（ステップＳ２０５）。

＜総括＞
以上説明したように、本実施形態によれば、クライアントとなる情報処理装置に対してサーバとなる情報処理装置の状態変化を通知する際に、通信のリソースを圧迫しないものとすることができる。

以上、本発明の好適な実施の形態により本発明を説明した。ここでは特定の具体例を示して本発明を説明したが、特許請求の範囲に定義された本発明の広範な趣旨および範囲から逸脱することなく、これら具体例に様々な修正および変更を加えることができることは明らかである。すなわち、具体例の詳細および添付の図面により本発明が限定されるものと解釈してはならない。

１ 画像形成装置
２ 本体部
２０１ ＣＰＵ
２０２ ＲＡＭ
２０３ ＮＶ−ＲＡＭ
２０４ プログラムＲＯＭ
２０５ フォントＲＯＭ
２０６ ネットワークインタフェース
２０７ 操作部インタフェース
２０８ プリンタエンジンインタフェース
２０９ スキャナエンジンインタフェース
２１０ ＨＤＤ
２１１ オプションＲＡＭ
２１２ プリンタエンジン
２１３ スキャナエンジン
２２１ ＰＤＬ解析モジュール
２２２ プリンタジョブ管理モジュール
２２３ コピージョブ管理モジュール
２２４ スキャナジョブ管理モジュール
２２５ ネットワーク管理モジュール
２２６ Ｗｅｂサービス提供モジュール
２２７ 印刷管理モジュール
２２８ システム管理モジュール
２２９ メモリ管理モジュール
２３０ サービス提供モジュール群
３ 操作部
３０１〜３０３ 操作部アプリ
４、４Ａ〜４Ｃ ホストコンピュータ

特開２０１１−２３２８９３号公報

Claims (9)

1. 第１の情報処理装置から第２の情報処理装置に対して状態通知のリクエストを送信し、前記第２の情報処理装置から前記第１の情報処理装置に対して状態通知のレスポンスを送信する情報処理システムであって、
   前記第１の情報処理装置は、
   通知すべき状態の種類を設定するリクエストまたは状態通知のリクエストを前記第２の情報処理装置に送信する手段と、
   通知すべき状態の種類を設定するリクエストおよび状態通知のリクエストに伴う、リクエスト送信元のクライアントを前記第２の情報処理装置に識別させる識別情報を取得する手段とを備え、
   前記第２の情報処理装置は、
   前記第１の情報処理装置から通知すべき状態の種類を設定するリクエストを受信した場合に、通知すべき状態の種類を内部に保持し、設定完了のレスポンスを前記第１の情報処理装置に対して送信する手段と、
   通知すべき状態変化が発生した場合に、前記第１および第２の情報処理装置間に維持されるセッションを用いて、状態の種類と状態の値を含むレスポンスを前記第１の情報処理装置に対して送信する手段と、
   同じ識別情報を有するクライアントから状態通知のリクエストを受信した場合に、当該リクエストが無効であることを前記第１の情報処理装置に通知する手段と
   を備えたことを特徴とする情報処理システム。
2. 請求項１に記載の情報処理システムにおいて、
   前記第２の情報処理装置は、
   前記第１の情報処理装置からのリクエストに応じて前記識別情報を発行する手段
   を備えたことを特徴とする情報処理システム。
3. 請求項１又は２に記載の情報処理システムにおいて、
   前記第２の情報処理装置が所定の情報処理を行う本体部であり、前記第１の情報処理装置が前記本体部に対する操作を受け付ける操作部である
   ことを特徴とする情報処理システム。
4. 第１の情報処理装置から第２の情報処理装置に対して状態通知のリクエストを送信し、前記第２の情報処理装置から前記第１の情報処理装置に対して状態通知のレスポンスを送信する情報処理システムの前記第１の情報処理装置であって、
   通知すべき状態の種類を設定するリクエストまたは状態通知のリクエストを前記第２の情報処理装置に送信する手段と、
   通知すべき状態の種類を設定するリクエストおよび状態通知のリクエストに伴う、リクエスト送信元のクライアントを前記第２の情報処理装置に識別させる識別情報を取得する手段と、
   前記第２の情報処理装置から、当該第２の情報処理装置が通知すべき状態の種類を内部に保持したことを示す設定完了のレスポンスまたは同じ識別情報を有するクライアントから状態通知のリクエストを前記第２の情報処理装置が受信した場合に当該リクエストが無効であることを示すレスポンスを受信する手段と、
   前記第２の情報処理装置から、通知すべき状態変化が発生した場合に送信される、状態の種類と状態の値を含むレスポンスを当該第２の情報処理装置との間に維持されるセッションを用いて受信する手段と
   を備えたことを特徴とする情報処理装置。
5. 第１の情報処理装置から第２の情報処理装置に対して状態通知のリクエストを送信し、前記第２の情報処理装置から前記第１の情報処理装置に対して状態通知のレスポンスを送信する情報処理システムの前記第２の情報処理装置であって、
   前記第１の情報処理装置から、リクエスト送信元のクライアントを識別する識別情報を伴う、通知すべき状態の種類を設定するリクエストまたは状態通知のリクエストを受信する手段と、
   前記第１の情報処理装置から通知すべき状態の種類を設定するリクエストを受信した場合に、通知すべき状態の種類を内部に保持し、設定完了のレスポンスを前記第１の情報処理装置に対して送信する手段と、
   通知すべき状態変化が発生した場合に、前記第１の情報処理装置との間に維持されるセッションを用いて、状態の種類と状態の値を含むレスポンスを前記第１の情報処理装置に対して送信する手段と、
   同じ識別情報を有するクライアントから状態通知のリクエストを受信した場合に、当該リクエストが無効であることを前記第１の情報処理装置に通知する手段と
   を備えたことを特徴とする情報処理装置。
6. 第１の情報処理装置から第２の情報処理装置に対して状態通知のリクエストを送信し、前記第２の情報処理装置から前記第１の情報処理装置に対して状態通知のレスポンスを送信する情報処理システムの前記第１の情報処理装置が実行する方法であって、
   通知すべき状態の種類を設定するリクエストまたは状態通知のリクエストを前記第２の情報処理装置に送信する工程と、
   通知すべき状態の種類を設定するリクエストおよび状態通知のリクエストに伴う、リクエスト送信元のクライアントを前記第２の情報処理装置に識別させる識別情報を取得する工程と、
   前記第２の情報処理装置から、当該第２の情報処理装置が通知すべき状態の種類を内部に保持したことを示す設定完了のレスポンスまたは同じ識別情報を有するクライアントから状態通知のリクエストを前記第２の情報処理装置が受信した場合に当該リクエストが無効であることを示すレスポンスを受信する工程と、
   前記第２の情報処理装置から、通知すべき状態変化が発生した場合に送信される、状態の種類と状態の値を含むレスポンスを当該第２の情報処理装置との間に維持されるセッションを用いて受信する工程と
   を備えたことを特徴とする情報処理方法。
7. 第１の情報処理装置から第２の情報処理装置に対して状態通知のリクエストを送信し、前記第２の情報処理装置から前記第１の情報処理装置に対して状態通知のレスポンスを送信する情報処理システムの前記第２の情報処理装置が実行する方法であって、
   前記第１の情報処理装置から、リクエスト送信元のクライアントを識別する識別情報を伴う、通知すべき状態の種類を設定するリクエストまたは状態通知のリクエストを受信する工程と、
   前記第１の情報処理装置から通知すべき状態の種類を設定するリクエストを受信した場合に、通知すべき状態の種類を内部に保持し、設定完了のレスポンスを前記第１の情報処理装置に対して送信する工程と、
   通知すべき状態変化が発生した場合に、前記第１の情報処理装置との間に維持されるセッションを用いて、状態の種類と状態の値を含むレスポンスを前記第１の情報処理装置に対して送信する工程と、
   同じ識別情報を有するクライアントから状態通知のリクエストを受信した場合に、当該リクエストが無効であることを前記第１の情報処理装置に通知する工程と
   を備えたことを特徴とする情報処理方法。
8. 第１の情報処理装置から第２の情報処理装置に対して状態通知のリクエストを送信し、前記第２の情報処理装置から前記第１の情報処理装置に対して状態通知のレスポンスを送信する情報処理システムの前記第１の情報処理装置を構成するコンピュータを、
   通知すべき状態の種類を設定するリクエストまたは状態通知のリクエストを前記第２の情報処理装置に送信する手段、
   通知すべき状態の種類を設定するリクエストおよび状態通知のリクエストに伴う、リクエスト送信元のクライアントを前記第２の情報処理装置に識別させる識別情報を取得する手段、
   前記第２の情報処理装置から、当該第２の情報処理装置が通知すべき状態の種類を内部に保持したことを示す設定完了のレスポンスまたは同じ識別情報を有するクライアントから状態通知のリクエストを前記第２の情報処理装置が受信した場合に当該リクエストが無効であることを示すレスポンスを受信する手段、
   前記第２の情報処理装置から、通知すべき状態変化が発生した場合に送信される、状態の種類と状態の値を含むレスポンスを当該第２の情報処理装置との間に維持されるセッションを用いて受信する手段
   として機能させることを特徴とする情報処理プログラム。
9. 第１の情報処理装置から第２の情報処理装置に対して状態通知のリクエストを送信し、前記第２の情報処理装置から前記第１の情報処理装置に対して状態通知のレスポンスを送信する情報処理システムの前記第２の情報処理装置を構成するコンピュータを、
   前記第１の情報処理装置から、リクエスト送信元のクライアントを識別する識別情報を伴う、通知すべき状態の種類を設定するリクエストまたは状態通知のリクエストを受信する手段、
   前記第１の情報処理装置から通知すべき状態の種類を設定するリクエストを受信した場合に、通知すべき状態の種類を内部に保持し、設定完了のレスポンスを前記第１の情報処理装置に対して送信する手段、
   通知すべき状態変化が発生した場合に、前記第１の情報処理装置との間に維持されるセッションを用いて、状態の種類と状態の値を含むレスポンスを前記第１の情報処理装置に対して送信する手段、
   同じ識別情報を有するクライアントから状態通知のリクエストを受信した場合に、当該リクエストが無効であることを前記第１の情報処理装置に通知する手段
   として機能させることを特徴とする情報処理プログラム。

Images