(57)【要約】【課題】クライアントとなる情報処理装置に対してサーバとなる情報処理装置の状態変化を、リアルタイムかつ確実に通知する。【解決手段】リクエストに対して所定のレスポンスを返すことで１回のリクエストについてのセッションが完了するプロトコルを用い、第１の情報処理装置から第２の情報処理装置に対して状態通知のリクエストを送信し、前記第２の情報処理装置から前記第１の情報処理装置に対して状態通知のレスポンスを送信する情報処理システムであって、前記第２の情報処理装置は、前記第１の情報処理装置から状態通知のリクエストを受信した場合に、レスポンスのヘッダ部分を前記第１の情報処理装置に対して送信する手段と、通知すべき状態変化が発生した場合に、状態通知内容を含むレスポンスのボディ部分の一部を前記第１の情報処理装置に対して送信する手段と、状態通知が不要となった場合に、レスポンスのボディ部分の最後の部分を前記第１の情報処理装置に対して送信する手段とを備える。【選択図】図５
2018156692.tif 000002
【特許請求の範囲】
【請求項１】
リクエストに対して所定のレスポンスを返すことで１回のリクエストについてのセッションが完了するプロトコルを用い、第１の情報処理装置から第２の情報処理装置に対して状態通知のリクエストを送信し、前記第２の情報処理装置から前記第１の情報処理装置に対して状態通知のレスポンスを送信する情報処理システムであって、
前記第２の情報処理装置は、
前記第１の情報処理装置から状態通知のリクエストを受信した場合に、レスポンスのヘッダ部分を前記第１の情報処理装置に対して送信する手段と、
通知すべき状態変化が発生した場合に、状態通知内容を含むレスポンスのボディ部分の一部を前記第１の情報処理装置に対して送信する手段と、
状態通知が不要となった場合に、レスポンスのボディ部分の最後の部分を前記第１の情報処理装置に対して送信する手段と、
を備え、
前記状態通知内容を含むレスポンスのボディ部分の一部は、ＪＳＯＮ形式で記載され、ヘッダを有さずに送信されることを特徴とする情報処理システム。
【請求項２】
請求項１に記載の情報処理システムにおいて、
前記第２の情報処理装置は、
所定時間にわたって通知すべき状態変化が発生しない場合、状態変化なしの状態通知内容を含む前記レスポンスのボディ部分の一部を前記第１の情報処理装置に対して送信する手段
を更に備えたことを特徴とする情報処理システム。
【請求項３】
請求項１または２のいずれか一項に記載の情報処理システムにおいて、
前記第１の情報処理装置は、
通知すべき状態変化を指定するリクエストを前記第２の情報処理装置に送信する手段
を更に備え、
前記第２の情報処理装置は、指定された状態変化を前記第１の情報処理装置に通知する
ことを特徴とする情報処理システム。
【請求項４】
請求項１乃至３のいずれか一項に記載の情報処理システムにおいて、
前記第１の情報処理装置は、
前記第２の情報処理装置の機能毎に状態通知のリクエストを送信する手段
を更に備えたことを特徴とする情報処理システム。
【請求項５】
請求項１乃至４のいずれか一項に記載の情報処理システムにおいて、
前記レスポンスのヘッダ部分は、データサイズを含まないように記述されている
ことを特徴とする情報処理システム。
【請求項６】
請求項１乃至５のいずれか一項に記載の情報処理システムにおいて、
前記レスポンスのボディ部分の一部は、区切り文字が付加されたＪＳＯＮ形式で記述されている
ことを特徴とする情報処理システム。
【請求項７】
請求項１乃至６のいずれか一項に記載の情報処理システムにおいて、
前記第１の情報処理装置が所定の情報処理を行う本体部であり、前記第２の情報処理装置が前記本体部に対する操作を受け付ける操作部である
ことを特徴とする情報処理システム。
【請求項８】
画像形成または画像読み取りを行う本体部と、
前記本体部に対する操作を受け付ける操作部と、
を備える画像形成装置であって、
前記操作部は、前記本体部に対してＨＴＴＰリクエストを送信し、
前記本体部は、前記ＨＴＴＰリクエストを受信した場合に前記操作部に対してＨＴＴＰレスポンスを送信し、
前記本体部から前記操作部に送信する前記ＨＴＴＰレスポンスは、
前記ＨＴＴＰレスポンスのヘッダ部分と、
前記画像形成装置の機器状態の情報を含み、前記操作部から前記本体部への１回のＨＴＴＰリクエストに対するレスポンスとして複数回送信される前記ＨＴＴＰレスポンスのボディ部分と、
を有し、
前記ＨＴＴＰレスポンスのボディ部分は、ＪＳＯＮ形式で記載され、ヘッダを有さずに送信されることを特徴とする画像形成装置。
【請求項９】
請求項８に記載の画像形成装置において、
前記機器状態は、前記画像形成装置のエラー発生を示す内容を含むことを特徴とする画像形成装置。
【請求項１０】
請求項８又は９に記載の画像形成装置において、
前記操作部は、前記本体部が提供するＷｅｂＡＰＩを使って、前記本体部からの状態通知を含む前記ＨＴＴＰレスポンスを受けることを特徴とする画像形成装置。
【請求項１１】
請求項１０に記載の画像形成装置において、
前記本体部は、少なくともプリントを含むＷｅｂサービスを、前記ＷｅｂＡＰＩを使って、クライアントとなる情報処理装置に対して提供することを特徴とする画像形成装置。
【請求項１２】
請求項８乃至１１のいずれか一項に記載の画像形成装置において、
前記本体部と前記操作部は有線接続され、前記有線接続により前記ＨＴＴＰリクエスト及びＨＴＴＰレスポンスを送信することを特徴とする画像形成装置。
【請求項１３】
請求項８乃至１２のいずれか一項に記載の画像形成装置において、
前記本体部と前記操作部は互いに独立したＯＳを有することを特徴とする画像形成装置。
【請求項１４】
画像形成または画像読み取りを行う本体部と、前記本体部に対する操作を受け付ける操作部とを備え、
リクエストに対して所定のレスポンスを返すことで１回のリクエストについてのセッションが完了するプロトコルを用い、前記操作部から前記本体部に対して状態通知のリクエストを送信し、前記本体部から前記操作部に対して状態通知のレスポンスを送信する画像形成装置であって、
前記操作部は、前記本体部に対して状態通知のリクエストを送信する手段を備え、
前記本体部は、
前記操作部からの状態通知のリクエストに対してレスポンスのヘッダ部分を前記操作部に送信する手段と、
通知すべき状態変化が発生した場合に状態通知内容を含むレスポンスのボディ部分の一部を前記操作部に送信する手段と、
状態通知が不要となった場合にレスポンスのボディ部分の最後の部分を前記操作部に送信する手段と、
を備え、
前記状態通知内容を含むレスポンスのボディ部分の一部は、ＪＳＯＮ形式で記載され、ヘッダを有さずに送信されることを特徴とする画像形成装置。
【請求項１５】
リクエストに対して所定のレスポンスを返すことで１回のリクエストについてのセッションが完了するプロトコルを用い、第１の情報処理装置から第２の情報処理装置に対して状態通知のリクエストを送信し、前記第２の情報処理装置から前記第１の情報処理装置に対して状態通知のレスポンスを送信する情報処理システムの前記第１の情報処理装置が実行する方法であって、
前記第１の情報処理装置が、
前記第２の情報処理装置に対して状態通知のリクエストを送信する工程と、
前記第２の情報処理装置から、前記第１の情報処理装置からの状態通知のリクエストに対して送信されるレスポンスのヘッダ部分を受信する工程と、
前記第２の情報処理装置から、通知すべき状態変化が発生した場合に送信される状態通知内容を含むレスポンスのボディ部分の一部を受信する工程と、
前記第２の情報処理装置から、状態通知が不要となった場合に送信されるレスポンスのボディ部分の最後の部分を受信する工程と、
を実行し、
前記状態通知内容を含むレスポンスのボディ部分の一部は、ＪＳＯＮ形式で記載され、ヘッダを有さずに送信されることを特徴とする情報処理方法。
【請求項１６】
リクエストに対して所定のレスポンスを返すことで１回のリクエストについてのセッションが完了するプロトコルを用い、第１の情報処理装置から第２の情報処理装置に対して状態通知のリクエストを送信し、前記第２の情報処理装置から前記第１の情報処理装置に対して状態通知のレスポンスを送信する情報処理システムの前記第２の情報処理装置が実行する方法であって、
前記第２の情報処理装置が、
前記第１の情報処理装置から状態通知のリクエストを受信した場合に、レスポンスのヘッダ部分を前記第１の情報処理装置に対して送信する工程と、
通知すべき状態変化が発生した場合に、状態通知内容を含むレスポンスのボディ部分の一部を前記第１の情報処理装置に対して送信する工程と、
状態通知が不要となった場合に、レスポンスのボディ部分の最後の部分を前記第１の情報処理装置に対して送信する工程と
を実行し、
前記状態通知内容を含むレスポンスのボディ部分の一部は、ＪＳＯＮ形式で記載され、ヘッダを有さずに送信されることを特徴とする情報処理方法。
【請求項１７】
リクエストに対して所定のレスポンスを返すことで１回のリクエストについてのセッションが完了するプロトコルを用い、第１の情報処理装置から第２の情報処理装置に対して状態通知のリクエストを送信し、前記第２の情報処理装置から前記第１の情報処理装置に対して状態通知のレスポンスを送信する情報処理システムの前記第１の情報処理装置を構成するコンピュータを、
前記第２の情報処理装置に対して状態通知のリクエストを送信する手段、
前記第２の情報処理装置から、前記第１の情報処理装置からの状態通知のリクエストに対して送信されるレスポンスのヘッダ部分を受信する手段、
前記第２の情報処理装置から、通知すべき状態変化が発生した場合に送信される状態通知内容を含むレスポンスのボディ部分の一部を受信する手段、及び
前記第２の情報処理装置から、状態通知が不要となった場合に送信されるレスポンスのボディ部分の最後の部分を受信する手段、
として機能させ、
前記状態通知内容を含むレスポンスのボディ部分の一部は、ＪＳＯＮ形式で記載され、ヘッダを有さずに送信されることを特徴とする情報処理プログラム。
【請求項１８】
リクエストに対して所定のレスポンスを返すことで１回のリクエストについてのセッションが完了するプロトコルを用い、第１の情報処理装置から第２の情報処理装置に対して状態通知のリクエストを送信し、前記第２の情報処理装置から前記第１の情報処理装置に対して状態通知のレスポンスを送信する情報処理システムの前記第２の情報処理装置を構成するコンピュータを、
前記第１の情報処理装置から状態通知のリクエストを受信した場合に、レスポンスのヘッダ部分を前記第１の情報処理装置に対して送信する手段、
通知すべき状態変化が発生した場合に、状態通知内容を含むレスポンスのボディ部分の一部を前記第１の情報処理装置に対して送信する手段、及び
状態通知が不要となった場合に、レスポンスのボディ部分の最後の部分を前記第１の情報処理装置に対して送信する手段、
として機能させ、
前記状態通知内容を含むレスポンスのボディ部分の一部は、ＪＳＯＮ形式で記載され、ヘッダを有さずに送信されることを特徴とする情報処理プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は情報処理の制御技術に関する。
【背景技術】
【０００２】
Ｗｅｂ上で各種のサービス（Ｗｅｂサービス）を提供する手段として、ＳＯＡＰ（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）データのシリアライズ・デシリアライズなどが主な責務である。
【００５２】
印刷管理モジュール２２７は、ＰＤＬ解析モジュール２２１が生成した印刷画像の印刷処理に関する制御を行うモジュールである。メモリ管理モジュール２２９が管理するメモリ／外部記憶装置内に格納された印刷画像を、プリンタエンジンに印刷させるために必要な各種処理を実行するのが主な責務であり、給排紙命令の発行、後処理実行命令の発行、印刷に関わるエラー状態の検知と他モジュールへの通知などを行う。
【００５３】
システム管理モジュール２２８は、画像形成装置１の機器構成情報や機器状態を管理・制御するモジュールである。機器構成情報とは、給紙トレイや排紙トレイの着脱の情報や給紙トレイ内の用紙構成といった情報であり、機器状態とは、印刷中・待機中、ジャムや用紙切れなどのエラー発生中といった内容である。こうした情報を他モジュールへ通知する他、ユーザによる機器設定（設定により動作を変化させるカスタマイズ可能項目等）の管理が主な責務である。
【００５４】
メモリ管理モジュール２２９は、メモリおよび外部記憶装置を管理するモジュールであり、他モジュールの要求に基いてメモリおよび外部記憶装置の割り当て・解放を行うことが主な責務である。
【００５５】
サービス提供モジュール群２３０は、各種サービスを提供するモジュールの総称である。サービス提供モジュール群２３０の各モジュールは互いに通信をし合って画像形成装置１の基本動作を分担し、協力して上位層からの要求に対応する。
【００５６】
＜動作＞
以下、上記の実施形態の動作について説明する。
【００５７】
図６はＷｅｂＡＰＩによる印刷処理の例を示すシーケンス図である。
【００５８】
図６において、ＨＴＴＰクライアントとなるホストコンピュータ４が印刷実行のＨＴＴＰリクエストを画像形成装置１に送信すると、本体部２のネットワーク管理モジュール２２５が受信する（ステップＳ１０１）。印刷実行のＨＴＴＰリクエストは、例えば"/printer/job/"といったＵＲＩ（Uniform Resource Identifier）を指定して送信する。
【００５９】
ネットワーク管理モジュール２２５はＨＴＴＰリクエストを受け取ると、Ｗｅｂサービス提供モジュール２２６に印刷実行のリクエストを通知する（ステップＳ１０２）。
【００６０】
Ｗｅｂサービス提供モジュール２２６はリクエストに対応するモジュールに処理実行を通知する。この例では、プリンタジョブ管理モジュール２２２に印刷実行のリクエストを通知する（ステップＳ１０３）。より詳しくは、起動時のタイミング等においてＵＲＩとそれに対応するイベントハンドラを登録しておくことで、Ｗｅｂサービス提供モジュール２２６は委譲先となるモジュールを判断し、そのモジュールに通知を行う。
【００６１】
プリンタジョブ管理モジュール２２２は、印刷実行のリクエストに含まれるヘッダおよびボディを解析し（ステップＳ１０４）、ＰＤＬ解析モジュール２２１に画像生成を要求する（ステップＳ１０５）。
【００６２】
ＰＤＬ解析モジュール２２１から画像生成の終了のレスポンスがあると（ステップＳ１０６）、プリンタジョブ管理モジュール２２２は印刷管理モジュール２２７に印刷処理実行を指示する（ステップＳ１０７）。
【００６３】
印刷管理モジュール２２７から印刷処理の終了のレスポンスがあると（ステップＳ１０８）、プリンタジョブ管理モジュール２２２はＷｅｂサービス提供モジュール２２６にレスポンスとして結果を通知する（ステップＳ１０９）。
【００６４】
Ｗｅｂサービス提供モジュール２２６も同様にネットワーク管理モジュール２２５にレスポンスを通知し（ステップＳ１１０）、最終的にＨＴＴＰクライアントのホストコンピュータ４にＨＴＴＰレスポンスが通知される（ステップＳ１１１）。
【００６５】
ここでは、例としてプリンタでの印刷実行処理を示したが、その他の機能についてもＷｅｂサービス提供モジュール２２６が対応するモジュールに処理実行を通知することで実現される。
【００６６】
図７はＷｅｂＡＰＩによる状態通知の処理例を示すシーケンス図である。
【００６７】
図７において、ＨＴＴＰクライアントとなる操作部３の操作部アプリ３０１が状態通知のＨＴＴＰリクエストを本体部２に送信すると、ネットワーク管理モジュール２２５が受信する（ステップＳ１２１）。操作部アプリ３０１の状態通知のＨＴＴＰリクエストにより操作部アプリ３０１とネットワーク管理モジュール２２５の間でセッションが形成される。
【００６８】
ネットワーク管理モジュール２２５はＨＴＴＰリクエストを受け取ると、Ｗｅｂサービス提供モジュール２２６に状態通知のリクエストを通知する（ステップＳ１２２）。
【００６９】
Ｗｅｂサービス提供モジュール２２６は状態通知を行う状態を管理するモジュール、ここではプリンタジョブ管理モジュール２２２とコピージョブ管理モジュール２２３とスキャナジョブ管理モジュール２２４とシステム管理モジュール２２８に状態通知のリクエストを通知する（ステップＳ１２３〜Ｓ１２６）。
【００７０】
また、Ｗｅｂサービス提供モジュール２２６は状態通知を含まない初回のレスポンスをネットワーク管理モジュール２２５に通知する（ステップＳ１２７）。
【００７１】
これを受け、ネットワーク管理モジュール２２５は操作部アプリ３０１にヘッダのみのＨＴＴＰレスポンスを送信する（ステップＳ１２８）。このＨＴＴＰレスポンスは正規のＨＴＴＰレスポンスとして完結しておらず、セッションは維持されたままとなる。
【００７２】
その後、例えば、プリンタジョブ管理モジュール２２２において状態変化を検出すると、プリンタジョブ管理モジュール２２２は状態変化のレスポンスをＷｅｂサービス提供モジュール２２６に通知する（ステップＳ１２９）。
【００７３】
これを受け、Ｗｅｂサービス提供モジュール２２６はレスポンスの一部としての状態変化をネットワーク管理モジュール２２５に通知する（ステップＳ１３０）。
【００７４】
これを受け、ネットワーク管理モジュール２２５はボディの一部として状態変化のデータを含むＨＴＴＰレスポンスを操作部アプリ３０１に送信する（ステップＳ１３１）。
【００７５】
その後もプリンタジョブ管理モジュール２２２、コピージョブ管理モジュール２２３、スキャナジョブ管理モジュール２２４、システム管理モジュール２２８のいずれかで状態変化を検出すると、Ｗｅｂサービス提供モジュール２２６、ネットワーク管理モジュール２２５を介して操作部アプリ３０１にボディの一部として状態変化のデータを含むＨＴＴＰレスポンスが送信される。
【００７６】
また、Ｗｅｂサービス提供モジュール２２６は、所定時間にわたって操作部アプリ３０１側に通知すべき状態変化がない場合、操作部アプリ３０１側でタイムアップが発生してセッションのクローズが行われないよう、所定時間が経過した時点でレスポンスの一部としての状態変化なしをネットワーク管理モジュール２２５に通知する（ステップＳ１３２）。
【００７７】
これを受け、ネットワーク管理モジュール２２５はボディの一部として状態変化なしのデータを含むＨＴＴＰレスポンスを操作部アプリ３０１に送信する（ステップＳ１３３）。
【００７８】
そして、本体部２の電源オフ時等において、状態通知が不要となった場合、Ｗｅｂサービス提供モジュール２２６はネットワーク管理モジュール２２５にセッションを完結させる最後のレスポンスを通知する（ステップＳ１３４）。
【００７９】
ネットワーク管理モジュール２２５は操作部アプリ３０１にボディの最後の部分のＨＴＴＰレスポンスを送信し（ステップＳ１３５）、最初のＨＴＴＰリクエスト（ステップＳ１２１）に対応するＨＴＴＰレスポンスが完結し、セッションはクローズされる。
【００８０】
このように、操作部アプリ３０１からの状態通知のＨＴＴＰリクエストから状態通知が不要となるまでの間、セッションを維持し、その間、状態変化が検出された場合に分割したレスポンス（分割レスポンス）により状態変化を通知するようにしているので、リアルタイムに、かつ、取りこぼしなく、状態変化を通知することができる。
【００８１】
以下、上述した分割レスポンスについてより詳細に説明する。
【００８２】
ＷｅｂサービスはＨＴＴＰ通信によりサーバとクライアントで情報交換することが基本的な思想である。
【００８３】
図８はＨＴＴＰ通信の例を示す図であり、ＨＴＴＰクライアントとサーバの間のＨＴＴＰ通信を模式的に表している。ＨＴＴＰ通信は、ＨＴＴＰクライアントからサーバに対してヘッダとボディから構成されるＨＴＴＰリクエストを送信し、サーバはＨＴＴＰクライアントに、同じくヘッダとボディから構成されるＨＴＴＰレスポンスを送信する。これにより、ＨＴＴＰクライアントとサーバの間で情報の送受信を行っている。図９はＨＴＴＰデータの構造を示す図であり、ヘッダとボディを含んでいる。
【００８４】
ＨＴＴＰ通信のプロトコル上、常にＨＴＴＰクライアントからＨＴＴＰリクエストを出し、サーバはそのＨＴＴＰリクエストに応答することが基本原理である。通常は、ＨＴＴＰクライアントからのＨＴＴＰリクエストに対して、サーバがＨＴＴＰレスポンスを送信した時点で、リクエスト処理は完結し、その後、ＨＴＴＰクライアントがＨＴＴＰリクエストを出すまでは、サーバはＨＴＴＰクライアントに情報を伝えることはできない。
【００８５】
そこで、サーバからのＨＴＴＰレスポンスによりリクエスト処理が完結しないように、ＨＴＴＰレスポンスを分割して送信する。図１０は分割したレスポンスとＨＴＴＰデータの関係の例を示す図である。
【００８６】
サーバの状態変化を検出したいＨＴＴＰクライアントは、サーバに対して状態通知のＨＴＴＰリクエストを送信する。サーバは、ＨＴＴＰクライアントから接続された段階でまずヘッダ部分だけ応答する。通常、ヘッダにはデータサイズを示すContent-Lengthを記載することが一般的だが、今回は予め応答するデータサイズが分からない。したがって、Content-Lengthは記載せずにヘッダを応答することになる。なお、Content-Lengthを含まなくてもＨＴＴＰ仕様として問題はない。
【００８７】
その後、ボディ部分の送信処理はサーバで状態変化あるまで行わない。ＨＴＴＰクライアントはサーバからの応答待ちの状態になる。
【００８８】
サーバでエラー発生など何らかの状態変化が発生したタイミングで、状態変化を示すボディの一部をＨＴＴＰクライアントに送信する。ボディの一部の送信が完了しても、サーバは完了を送信しないため、ＨＴＴＰクライアント／サーバともにボディ部分の送受信中の状態を維持している。
【００８９】
これらの処理を、サーバの状態変化が発生する度に繰り返し実行することで、ＨＴＴＰクライアントのタイミングに依存しない状態通知が実現できる。
【００９０】
最終的にはヘッダとボディからなるＨＴＴＰプロトコルに従ったデータとなる。このことにより、一般的なＨＴＴＰ通信を行えるソフトウェアや動作環境で実現可能となる。
【００９１】
ＨＴＴＰクライアントは、一定期間にわたってサーバから応答が無い場合、通信を切断する場合がある。一定期間にわたってサーバで状態変化が発生しない場合は、サーバから状態変更なしを示すボディの一部を送信することで通信を維持することができる。
【００９２】
図１１はデータ書式の例を示す図である。
【００９３】
ＨＴＴＰでは、テキストデータ、画像データ、ＸＭＬ、ＪＳＯＮなど様々な種類のデータ送信が可能である。Ｗｅｂサービスの用途としては、最近はＪＳＯＮ形式でデータを送受信するケースが多い。
【００９４】
図１１（ａ）は通常のＨＴＴＰレスポンスにおいてＪＳＯＮ形式を用いた場合を示しており、ヘッダのContent-Typeにjsonが指定されている。ボディは全体がＪＳＯＮ形式で記述されている。
【００９５】
図１１（ｂ）は分割レスポンスにＪＳＯＮ形式を用いた場合を示しており、ボディの個々の部分データをＪＳＯＮ形式で記述し、区切り文字列（例えば、改行を２個）を付加している。この場合、ボディ全体はＪＳＯＮ形式とはならないため、ヘッダのContent-Typeはtext/plainとなっている。
【００９６】
ＨＴＴＰクライアントは部分データの個々を受信することに意味があるため、個々の部分データがＪＳＯＮ形式等の所定のデータ形式である方が、ＨＴＴＰクライアント側も処理が容易となる。
【００９７】
ＨＴＴＰクライアントは、ＨＴＴＰプロトコルに従い順次に受信データを読み出す。このとき、各データ部分の最後に付された区切り文字列により、個々の部分データを区別して読み出すことができる。
【００９８】
図１２はＷｅｂＡＰＩによる状態通知の他の処理例を示すシーケンス図であり、ＨＴＴＰクライアントから通知すべき状態変化を指定するようにしたものである。
【００９９】
図１２において、ＨＴＴＰクライアントとなる操作部３の操作部アプリ３０１が状態通知のＨＴＴＰリクエストを本体部２に送信すると、ネットワーク管理モジュール２２５が受信する（ステップＳ１４１）。操作部アプリ３０１の状態通知のＨＴＴＰリクエストにより操作部アプリ３０１とネットワーク管理モジュール２２５の間でセッションが形成される。
【０１００】
ネットワーク管理モジュール２２５はＨＴＴＰリクエストを受け取ると、Ｗｅｂサービス提供モジュール２２６に状態通知のリクエストを通知する（ステップＳ１４２）。
【０１０１】
Ｗｅｂサービス提供モジュール２２６は状態通知を行う状態を管理するモジュール、ここではプリンタジョブ管理モジュール２２２とコピージョブ管理モジュール２２３とスキャナジョブ管理モジュール２２４とシステム管理モジュール２２８に状態通知のリクエストを通知する（ステップＳ１４３〜Ｓ１４６）。
【０１０２】
また、Ｗｅｂサービス提供モジュール２２６は状態通知を含まない初回のレスポンスをネットワーク管理モジュール２２５に通知する（ステップＳ１４７）。
【０１０３】
これを受け、ネットワーク管理モジュール２２５は操作部アプリ３０１にヘッダのみのＨＴＴＰレスポンスを送信する（ステップＳ１４８）。このＨＴＴＰレスポンスは正規のＨＴＴＰレスポンスとして完結しておらず、セッションは維持されたままとなる。
【０１０４】
その後、操作部アプリ３０１がステータスＡの通知を指定するＨＴＴＰリクエストを本体部２に送信すると、ネットワーク管理モジュール２２５が受信する（ステップＳ１４９）。
【０１０５】
ネットワーク管理モジュール２２５はＨＴＴＰリクエストを受け取ると、Ｗｅｂサービス提供モジュール２２６にステータスＡの通知を指定するリクエストを通知する（ステップＳ１５０）。
【０１０６】
Ｗｅｂサービス提供モジュール２２６は、ステータスＡの指定を内部的に保持し、レスポンスをネットワーク管理モジュール２２５に返し（ステップＳ１５１）、ネットワーク管理モジュール２２５はレスポンスを操作部アプリ３０１に返す（ステップＳ１５２）。このリクエストのセッションはこれで完結する。
【０１０７】
その後、例えば、プリンタジョブ管理モジュール２２２においてステータスＡの状態変化を検出すると、プリンタジョブ管理モジュール２２２はステータスＡの状態変化のレスポンスをＷｅｂサービス提供モジュール２２６に通知する（ステップＳ１５３）。
【０１０８】
これを受けたＷｅｂサービス提供モジュール２２６は、内部的に保持した通知すべきステータスＡの指定と一致するため、レスポンスの一部としてのステータスＡの状態変化をネットワーク管理モジュール２２５に通知する（ステップＳ１５４）。
【０１０９】
これを受け、ネットワーク管理モジュール２２５はボディの一部としてステータスＡの状態変化のデータを含むＨＴＴＰレスポンスを操作部アプリ３０１に送信する（ステップＳ１５５）。
【０１１０】
その後、システム管理モジュール２２８においてステータスＢの状態変化を検出すると、システム管理モジュール２２８はステータスＢの状態変化のレスポンスをＷｅｂサービス提供モジュール２２６に通知する（ステップＳ１５６）。
【０１１１】
これを受けたＷｅｂサービス提供モジュール２２６は、内部的に保持した通知すべきステータスＡの指定と一致しないため、レスポンスを通知しない。
【０１１２】
その後、操作部アプリ３０１がステータスＢの通知を指定するリクエストを通知した場合、ステータスＢの状態変化についても通知が行われるようになる。
【０１１３】
Ｗｅｂサービス提供モジュール２２６が、所定時間にわたって操作部アプリ３０１側に通知すべき状態変化がない場合、レスポンスの一部としての状態変化なしをネットワーク管理モジュール２２５に通知する点は図７と同様である。
【０１１４】
また、本体部２の電源オフ時等において、ネットワーク管理モジュール２２５が操作部アプリ３０１にボディの最後の部分のＨＴＴＰレスポンスを送信する点も図７と同様である。
【０１１５】
なお、Ｗｅｂサービス提供モジュール２２６が通知すべきステータスを保持し、状態変化が通知された場合に通知すべきか否かを判断する場合について説明したが、通知すべきステータスを対応するモジュールに通知し、そのモジュール側で通知すべきか否か判断するようにしてもよい。
【０１１６】
図１３はＷｅｂＡＰＩによる状態通知の更に他の処理例を示すシーケンス図であり、機能毎に分割レスポンスを行い、状態変化がほぼ同時に発生しても、通知が待たされることがないようにしたものである。すなわち、図７に示した方式では、例えば、プリンタジョブ管理モジュール２２２が状態変化のレスポンスを行うのとほぼ同時にシステム管理モジュール２２８が状態変化のレスポンスを行うと、操作部アプリ３０１へのプリンタジョブ管理モジュール２２２からのＨＴＴＰレスポンスが完了するまでは、システム管理モジュール２２８からのＨＴＴＰレスポンスを送信することができない。この処理例は、このような不都合を解消している。
【０１１７】
図１３において、ＨＴＴＰクライアントとなる操作部３の操作部アプリ３０１が状態通知のＨＴＴＰリクエストを機能毎に本体部２に送信すると、ネットワーク管理モジュール２２５が受信する（ステップＳ１６１〜Ｓ１６４）。操作部アプリ３０１の状態通知のＨＴＴＰリクエストにより操作部アプリ３０１とネットワーク管理モジュール２２５の間で機能毎にセッションが形成される。
【０１１８】
ネットワーク管理モジュール２２５はＨＴＴＰリクエストを受け取ると、Ｗｅｂサービス提供モジュール２２６に状態通知のリクエストを通知する（ステップＳ１６５〜Ｓ１６８）。
【０１１９】
Ｗｅｂサービス提供モジュール２２６は状態通知を行う状態を管理するモジュール、ここではプリンタジョブ管理モジュール２２２とコピージョブ管理モジュール２２３とスキャナジョブ管理モジュール２２４とシステム管理モジュール２２８に状態通知のリクエストを通知する（ステップＳ１６９〜Ｓ１７２）。
【０１２０】
また、Ｗｅｂサービス提供モジュール２２６は状態通知を含まない初回のレスポンスをネットワーク管理モジュール２２５に通知する（ステップＳ１７３〜Ｓ１７６）。
【０１２１】
これを受け、ネットワーク管理モジュール２２５は操作部アプリ３０１にヘッダのみのＨＴＴＰレスポンスを送信する（ステップＳ１７７〜Ｓ１８０）。このＨＴＴＰレスポンスは正規のＨＴＴＰレスポンスとして完結しておらず、セッションは維持されたままとなる。
【０１２２】
その後、プリンタジョブ管理モジュール２２２において状態変化を検出すると、プリンタジョブ管理モジュール２２２は状態変化のレスポンスをＷｅｂサービス提供モジュール２２６に通知する（ステップＳ１８１）。
【０１２３】
これとほぼ同時に、システム管理モジュール２２８において状態変化を検出すると、システム管理モジュール２２８は状態変化のレスポンスをＷｅｂサービス提供モジュール２２６に通知する（ステップＳ１８２）。
【０１２４】
これを受け、Ｗｅｂサービス提供モジュール２２６はレスポンスの一部としての状態変化をネットワーク管理モジュール２２５に通知する（ステップＳ１８３、Ｓ１８４）。
【０１２５】
これを受け、ネットワーク管理モジュール２２５はボディの一部として状態変化のデータを含むＨＴＴＰレスポンスを操作部アプリ３０１に送信する（ステップＳ１８５、Ｓ１８６）。
【０１２６】
その後もプリンタジョブ管理モジュール２２２、コピージョブ管理モジュール２２３、スキャナジョブ管理モジュール２２４、システム管理モジュール２２８のいずれかで状態変化を検出すると、Ｗｅｂサービス提供モジュール２２６、ネットワーク管理モジュール２２５を介して操作部アプリ３０１にボディの一部として状態変化のデータを含むＨＴＴＰレスポンスが送信される。
【０１２７】
Ｗｅｂサービス提供モジュール２２６は、所定時間にわたって操作部アプリ３０１側に通知すべき状態変化がない場合、状態通知リクエスト毎にレスポンスの一部としての状態変化なしをネットワーク管理モジュール２２５に通知し、ネットワーク管理モジュール２２５は操作部アプリ３０１に状態通知リクエスト毎にＨＴＴＰレスポンスを送信する。
【０１２８】
また、Ｗｅｂサービス提供モジュール２２６は、状態通知が不要となった場合において、状態通知リクエスト毎にボディの最後の部分のレスポンスをネットワーク管理モジュール２２５に通知し、ネットワーク管理モジュール２２５は操作部アプリ３０１に状態通知リクエスト毎にＨＴＴＰレスポンスを送信し、セッションはクローズされる。
【０１２９】
＜総括＞
以上説明したように、本実施形態によれば、クライアントとなる情報処理装置に対してサーバとなる情報処理装置の状態変化を、リアルタイムかつ確実に通知することができる。
【０１３０】
以上、本発明の好適な実施の形態により本発明を説明した。ここでは特定の具体例を示して本発明を説明したが、特許請求の範囲に定義された本発明の広範な趣旨および範囲から逸脱することなく、これら具体例に様々な修正および変更を加えることができることは明らかである。すなわち、具体例の詳細および添付の図面により本発明が限定されるものと解釈してはならない。
【符号の説明】
【０１３１】
１                  画像形成装置
２                  本体部
２０１              ＣＰＵ
２０２              ＲＡＭ
２０３              ＮＶ−ＲＡＭ
２０４              プログラムＲＯＭ
２０５              フォントＲＯＭ
２０６              ネットワークインタフェース
２０７              操作部インタフェース
２０８              プリンタエンジンインタフェース
２０９              スキャナエンジンインタフェース
２１０              ＨＤＤ
２１１              オプションＲＡＭ
２１２              プリンタエンジン
２１３              スキャナエンジン
２２１              ＰＤＬ解析モジュール
２２２              プリンタジョブ管理モジュール
２２３              コピージョブ管理モジュール
２２４              スキャナジョブ管理モジュール
２２５              ネットワーク管理モジュール
２２６              Ｗｅｂサービス提供モジュール
２２７              印刷管理モジュール
２２８              システム管理モジュール
２２９              メモリ管理モジュール
２３０              サービス提供モジュール群
３                  操作部
３０１〜３０３      操作部アプリ
４、４Ａ〜４Ｃ      ホストコンピュータ
【先行技術文献】
【特許文献】
【０１３２】
【特許文献１】特開２０１１−２３２８９３号公報
【図１】
2018156692.tif 000003
【図２】
2018156692.tif 000004
【図３】
2018156692.tif 000005
【図４】
2018156692.tif 000006
【図５】
2018156692.tif 000007
【図６】
2018156692.tif 000008
【図７】
2018156692.tif 000009
【図８】
2018156692.tif 000010
【図９】
2018156692.tif 000011
【図１０】
2018156692.tif 000012
【図１１】
2018156692.tif 000013
【図１２】
2018156692.tif 000014
【図１３】
2018156692.tif 000015
【手続補正書】
【提出日】平成30年7月17日(2018.7.17)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
第１の情報処理装置と、該第１の情報処理装置と接続される第２の情報処理装置とを含む情報処理システムであって、
前記第２の情報処理装置は、前記第１の情報処理装置から受け取った１回のリクエストに応じて、前記第１の情報処理装置に対して、ヘッダ部分とボディ部分とを含むレスポンスを送信し、
前記レスポンスは、前記１回の前記リクエストに対して複数回に分けて送信され、前記複数回は、少なくとも前記ヘッダ部分が含まれる送信の回と、少なくとも前記ボディ部分が含まれるが、前記ヘッダ部分は含まない、複数の回とが含まれること
を特徴とする情報処理システム。
【請求項２】
請求項１に記載の情報処理システムにおいて、
前記第２の情報処理装置が前記第１の情報処理装置に対して送信する、少なくとも前記ボディ部分が含まれるが、前記ヘッダ部分は含まない、複数の回は、前記第２の情報処理装置の機器状態の情報を少なくとも含み、ＪＳＯＮ形式で記載されることを特徴とする情報処理システム。
【請求項３】
請求項１又は２に記載の情報処理システムにおいて、
前記第１の情報処理装置と前記第２の情報処理装置とは少なくともＨＴＴＰプロトコルで通信し、
前記ヘッダ部分は少なくともＨＴＴＰレスポンスのヘッダ部分であることを特徴とする情報処理システム。
【請求項４】
請求項１乃至３のいずれか一項に記載の情報処理システムにおいて、
前記第１の情報処理装置は、
通知すべき状態変化を指定するリクエストを前記第２の情報処理装置に送信する手段
を備え、
前記第２の情報処理装置は、指定された状態変化を前記第１の情報処理装置に通知する
ことを特徴とする情報処理システム。
【請求項５】
請求項１乃至４のいずれか一項に記載の情報処理システムにおいて、
前記第１の情報処理装置は、
前記第２の情報処理装置の機能毎に状態通知のリクエストを送信する手段
を備えたことを特徴とする情報処理システム。
【請求項６】
請求項１乃至３のいずれか一項に記載の情報処理システムにおいて、
前記ヘッダ部分は、データサイズを含まないように記述されている
ことを特徴とする情報処理システム。
【請求項７】
請求項１乃至６のいずれか一項に記載の情報処理システムにおいて、
前記第１の情報処理装置が所定の情報処理を行う本体部であり、前記第２の情報処理装置が前記本体部に対する操作を受け付ける操作部である
ことを特徴とする情報処理システム。
【請求項８】
画像形成または画像読み取りを行う本体部と、
前記本体部に対する操作を受け付ける操作部と、
を備える画像形成装置であって、
前記本体部は、前記操作部から受け取った１回のリクエストに応じて、前記操作部に対して、ヘッダ部分とボディ部分とを含むレスポンスを送信し、
前記レスポンスは、前記１回の前記リクエストに対して複数回に分けて送信され、前記複数回は、少なくとも前記ヘッダ部分が含まれる送信の回と、少なくとも前記ボディ部分が含まれるが、前記ヘッダ部分は含まない、複数の回とが含まれること
を特徴とする画像形成装置。
【請求項９】
請求項８に記載の画像形成装置において、
前記本体部が前記操作部に対して送信する、少なくとも前記ボディ部分が含まれるが、前記ヘッダ部分は含まない、複数の回は、前記本体部の機器状態の情報を少なくとも含み、ＪＳＯＮ形式で記載されることを特徴とする画像形成装置。
【請求項１０】
請求項８又は９に記載の画像形成装置において、
前記操作部と前記本体部とは少なくともＨＴＴＰプロトコルで通信し、
前記ヘッダ部分は少なくともＨＴＴＰレスポンスのヘッダ部分であることを特徴とする画像形成装置。
【請求項１１】
請求項９に記載の画像形成装置において、
前記機器状態は、前記画像形成装置のエラー発生を示す内容を含むことを特徴とする画像形成装置。
【請求項１２】
請求項８乃至１１のいずれか一項に記載の画像形成装置において、
前記操作部は、前記本体部が提供するＷｅｂＡＰＩを使って、前記本体部からの状態通知を含む前記レスポンスを受けることを特徴とする画像形成装置。
【請求項１３】
請求項１２に記載の画像形成装置において、
前記本体部は、少なくともプリントを含むＷｅｂサービスを、前記ＷｅｂＡＰＩを使って、クライアントとなる情報処理装置に対して提供することを特徴とする画像形成装置。
【請求項１４】
請求項８乃至１３のいずれか一項に記載の画像形成装置において、
前記本体部と前記操作部は互いに独立したＯＳを有することを特徴とする画像形成装置。
【請求項１５】
画像形成または画像読み取りを行う本体部と、前記本体部に対する操作を受け付ける操作部とを備え、
ＨＴＴＰプロトコルを用い、前記操作部から前記本体部に対してＨＴＴＰリクエストを送信し、前記本体部から前記操作部に対してＨＴＴＰレスポンスを送信する画像形成装置であって、
前記本体部は、前記操作部から受け取った１回のＨＴＴＰリクエストに応じて、前記操作部に対して、ヘッダ部分とボディ部分とを含むＨＴＴＰレスポンスを送信し、
前記ＨＴＴＰレスポンスは、前記１回の前記ＨＴＴＰリクエストに対して複数回に分けて送信され、前記複数回は、少なくとも前記ＨＴＴＰレスポンスのヘッダ部分が含まれる送信の回と、少なくとも前記ＨＴＴＰレスポンスのボディ部分が含まれるが、前記ＨＴＴＰレスポンスのヘッダ部分は含まない、複数の回とが含まれる
ことを特徴とする画像形成装置。
【請求項１６】
第１の情報処理装置と、該第１の情報処理装置と接続される第２の情報処理装置とを含む情報処理システムの前記第２の情報処理装置が実行する方法であって、
前記第２の情報処理装置は、第１の情報処理装置から受け取った１回のＨＴＴＰリクエストに応じて、前記第１の情報処理装置に対して、ヘッダ部分とボディ部分とを含むＨＴＴＰレスポンスを送信し、
前記ＨＴＴＰレスポンスは、前記１回の前記ＨＴＴＰリクエストに対して複数回に分けて送信され、前記複数回は、少なくとも前記ＨＴＴＰレスポンスのヘッダ部分が含まれる送信の回と、少なくとも前記ＨＴＴＰレスポンスのボディ部分が含まれるが、前記ＨＴＴＰレスポンスのヘッダ部分は含まない、複数の回とが含まれる
ことを特徴とする情報処理方法。
【請求項１７】
第１の情報処理装置と、該第１の情報処理装置と接続される第２の情報処理装置とを含む情報処理システムの前記第２の情報処理装置を構成するコンピュータに、
第１の情報処理装置から受け取った１回のＨＴＴＰリクエストに応じて、前記第１の情報処理装置に対して、ヘッダ部分とボディ部分とを含むＨＴＴＰレスポンスを送信する工程を実行させ、
前記ＨＴＴＰレスポンスは、前記１回の前記ＨＴＴＰリクエストに対して複数回に分けて送信され、前記複数回は、少なくとも前記ＨＴＴＰレスポンスのヘッダ部分が含まれる送信の回と、少なくとも前記ＨＴＴＰレスポンスのボディ部分が含まれるが、前記ＨＴＴＰレスポンスのヘッダ部分は含まない、複数の回とが含まれる
ことを特徴とする情報処理プログラム。
【請求項１８】
ＨＴＴＰプロトコルを用い、他の情報処理装置からＨＴＴＰリクエストを受信するとともに、前記ＨＴＴＰリクエストに応じて、前記他の情報処理装置に対してＨＴＴＰレスポンスを送信する情報処理装置であって、
前記情報処理装置は、前記他の情報処理装置から受け取った１回のＨＴＴＰリクエストに応じて、前記他の情報処理装置に対して、ヘッダ部分とボディ部分とを含むＨＴＴＰレスポンスを送信し、
前記ＨＴＴＰレスポンスは、前記１回の前記ＨＴＴＰリクエストに対して複数回に分けて送信され、前記複数回は、少なくとも前記ＨＴＴＰレスポンスのヘッダ部分が含まれる送信の回と、少なくとも前記ＨＴＴＰレスポンスのボディ部分が含まれるが、前記ＨＴＴＰレスポンスのヘッダ部分は含まない、複数の回とが含まれる
ことを特徴とする情報処理装置。
【手続補正３】
【補正対象書類名】明細書
【補正対象項目名】００１７
【補正方法】変更
【補正の内容】
【００１７】
上記の課題を解決するため、本発明にあっては、第１の情報処理装置と、該第１の情報処理装置と接続される第２の情報処理装置とを含む情報処理システムであって、
前記第２の情報処理装置は、前記第１の情報処理装置から受け取った１回のリクエストに応じて、前記第１の情報処理装置に対して、ヘッダ部分とボディ部分とを含むレスポンスを送信し、
前記レスポンスは、前記一回の前記リクエストに対して複数回に分けて送信され、前記複数回は、少なくとも前記ヘッダ部分が含まれる送信の回と、少なくとも前記ボディ部分が含まれるが、前記ヘッダ部分は含まない、複数の回とが含まれる。