JP5791367B2 - 画像形成装置とプロキシサーバを有するネットワークシステムおよび、その制御方法、制御プログラム、並びにプロキシサーバ - Google Patents

Description

本発明は、画像形成装置とプロキシサーバとを有するネットワークシステムおよび、その制御方法、制御プログラム、並びにプロキシサーバに関する。

従来、スキャナやプリンタ、ファクシミリ、ネットワーク送信装置などの各装置の機能を１つの筺体内に収納した画像処理装置が一般的に知られている。このような画像処理装置の操作部にＷｅｂブラウザーを用いる形態も一般的である。ここで、Ｗｅｂブラウザーで表示する操作画面で上述の各機能を利用する形態として特許文献１のような方法が知られている。

特許文献１によると、画像処理装置が備えているＷｅｂブラウザーは、ネットワーク上の外部装置から受信した画面情報（画面データ）に基づいて画像処理機能に関する操作画面を操作部に表示する。そして、その操作画面を用いてユーザーの操作を受けると、Ｗｅｂブラウザーは、ユーザーから受け付けた操作の内容を外部装置へ送信する。その後、画像処理装置は、外部装置からそのユーザーの操作に基づくＷｅｂサービスの要求を受信する。画像処理装置は、Ｗｅｂサービスの要求に応じて画像処理装置のスキャン機能又はプリント機能を実行する。

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

Ｗｅｂブラウザーを備える情報処理装置と、ネットワーク上に存在する外部装置との間にファイアウォールが存在する場合がある。ファイアウォールは一般的に内部から外部への接続は許可するが外部から内部への接続は許可しない。そのため上述した従来の方法では、外部装置からのＷｅｂサービスの要求を受け付けることができない場合がある。

また、ネットワークアドレス変換装置（ＮＡＴ）によりＩＰアドレスとプライベートアドレスを相互に変換してアドレスを使用する環境にＭＦＰが存在する場合には、Ｗｅｂサービスを要求するＭＦＰをインターネット上の外部装置からは特定できない、という問題がある。

本発明は、上述のような課題にかんがみて、ＭＦＰと外部装置との間にファイアウォールが存在する場合や、ＭＦＰがアドレス変換を用いる環境に存在する場合でも、好適に外部装置からのＷｅｂサービスの要求をＭＦＰに処理させるための手段を提供することを目的とする。

上記目的を達成するため、本発明によるネットワークシステムは、画像形成装置と、外部サーバと通信するためのプロキシサーバとを有するネットワークシステムであって、前記画像形成装置は、ウェブブラウザにより表示される操作画面で情報の入力を受け付ける入力手段と、前記プロキシサーバから受信したコマンドに従って、ジョブを実行する実行手段と、を備え、前記プロキシサーバは、前記入力手段で入力された情報を含む第１のリクエストを前記画像形成装置のウェブブラウザから受信したことに応じて、前記第１のリクエストを前記外部サーバに転送し、前記第１のリクエストに対する第１のレスポンスを前記外部サーバから受信したことに応じて、前記第１のレスポンスを前記ウェブブラウザに転送する転送手段を有し、前記転送手段は、前記コマンドが前記第１のレスポンスに含まれる場合は、前記ウェブブラウザに前記第１のレスポンスを転送するのではなく、前記実行手段に前記第１のレスポンスに含まれる前記コマンドを送信することを特徴とする。

本発明によれば、ネットワーク上に存在する外部装置との間にファイアウォールが存在する場合や、ＭＦＰがアドレス変換を用いる環境に存在する場合でも、外部装置から送信されたＷｅｂサービスの要求であってＷｅｂブラウザーでの操作に基づくＷｅｂサービスの要求を好適に処理することができる。

本発明の実施の形態による、中継装置および情報処理装置が収容されたネットワークシステムの一例を示す図である。 図１に示す情報処理装置についてその構成の一例を示すブロック図である。 図１に示すサーバーおよび仲介装置のハードウェア構成の一例を示すブロック図である。 図４は、図１に示す情報処理装置、サーバー、および仲介装置のソフトウェア構成の一例を示す図である。 図４に示す情報処理装置（ＭＦＰ）、サーバー、および仲介装置における処理を説明するためのシーケンス図である。 仲介装置における処理を説明するためのフローチャートである。 仲介装置における処理を説明するためのフローチャートである。 仲介装置がＭＦＰのＷｅｂサービスを呼び出した際のタイムアウト処理を説明するためのフローチャートである。 図４に示すＷｅｂアプリケーションが仲介アプリケーションに送信するＨＴＴＰレスポンスヘッダーの構成を示す図である。

以下、本発明の実施の形態によるネットワークシステムにおける中継装置の一例について図面を参照して説明する。

図１は、本発明の実施の形態による、中継装置および情報処理装置が収容されたネットワークシステムの一例を示す図である。図示の例では、情報処理装置１０１と中継装置（以下仲介装置あるいはプロキシサーバとも呼ぶ）１０３がローカルエリアネットワーク（ＬＡＮ）１００を介して互いに通信可能に接続されている。またインターネット上にはサーバー（Ｗｅｂサーバー）１０２が存在する。

本実施形態では、図１には図示しないが、インターネットとＬＡＮ１００との間にはファイアウォール及びＮＡＴ（Ｎｅｔｗｏｒｋ Ａｄｄｒｅｓｓ Ｔｒａｎｓｌａｔｏｒ）が設けられている。ファイアウォールはインターネットからＬＡＮ１００内への不正アクセスを防止する機能を持っている。

またＮＡＴは、ＩＰアドレスとＬＡＮ１００内で使用するプライベートアドレスとを相互に変換するアドレス変換テーブルを持つ。このアドレス変換テーブルによるアドレス変換により、プライベートアドレスしか持たないＬＡＮ１００内の装置がインターネット上の外部装置に透過的にアクセスすることができる。

なお以降では、情報処理装置１０１の一例として画像形成（印刷）機能、画像読取機能、画像送信機能などの各種の画像処理機能を備えたＭＦＰ（Ｍｕｌｔｉｐｌｅ Ｆｕｎｃｔｉｏｎ Ｐｅｒｉｐｈｅｒａｌ）について説明する。

ＭＦＰ１０１は所謂Ｗｅｂブラウザー機能を有しており、サーバー１０２はＷｅｂコンテンツを、ネットワーク１００を介して配信する配信機能を有している。そして、サーバー１０２はＭＦＰ１０１からのリクエストに応じてＷｅｂコンテンツをＭＦＰ１０１に返送する。なお、ＭＦＰ１０１は通信を行うための複数のインタフェースを備えている。

ＭＦＰ１０１は、上述のブラウザー機能を用いてサーバー１０２にリクエストを送信する場合、必ず中継装置（仲介装置）１０３を介するよう設定されている。そのため、ＭＦＰ１０１のＷｅｂブラウザーで送信されたサーバー１０２へのリクエスト及びそのリクエストに対するレスポンスは、全て中継装置（仲介装置）１０３を介することになる。

仲介装置１０３は、サーバー１０２とＭＦＰ１０１との間の通信を仲介する。例えば、サーバー１０２からＭＦＰ１０１にリクエスト又はレスポンスを送信する際、仲介装置１０３はその通信内容を解析して、この解析結果に応じて、ＭＦＰ１０１が備える複数のインタフェースのいずれかを選択する処理を行う。さらに、仲介装置１０３はＭＦＰ１０１で実行された処理結果（ジョブ処理結果）をサーバー１０１に送る。

なお、本実施形態ではサーバー（Ｗｅｂサーバー）を外部装置の一例として説明するが、汎用のパーソナルコンピュータを外部装置として適用してもよいことはいうまでもない。

図２は、図１に示すＭＦＰ１０１についてその構成の一例を示すブロック図である。

図２において、ＭＦＰ１０１は、ＣＰＵ２０１を有しており、ＣＰＵ２０１はＭＦＰ１０１全体の制御を司る。さらに、ＭＦＰ１０１は、ＣＰＵ２０１のワークエリアとして用いられるＲＡＭ２０２、原稿から画像を読み取る読取装置２０３、および画像データに応じて印刷を行う印刷装置２０４を備えている。また、ＭＦＰ１０１は、記憶装置２０５、ユーザー入力装置２０６、ＵＩ（ユーザーインタフェース）表示装置２０７、およびネットワーク装置２０８を備えている。そして、これらＣＰＵ２０１、ＲＡＭ２０２、読取装置２０３、印刷装置２０４、記憶装置２０５、ユーザー入力装置２０６、ＵＩ表示装置２０７、およびネットワーク装置２０８はメインバス２００で相互に接続されている。

記憶装置２０５にはプログラムおよび各種設定情報が記憶され、例えば、ＨＤＤ又はＮＶＲＡＭ等が用いられる。ユーザー入力装置２０６はユーザーがコマンドの入力を行うためのものであり、ＵＩ表示装置２０７には各種画面表示が行われる。ネットワーク装置２０８は外部機器（例えば、サーバー１０２）とネットワーク１００を介して通信を行うためのものである。なお、図示の例では、ＣＰＵ２０１はメインバス２００を介してＲＡＭ２０２、読取装置２０３、印刷装置２０４、記憶装置２０５、ユーザー入力装置２０６、ＵＩ表示装置２０７、およびネットワーク装置２０８を制御する。また、タッチパネルディスプレイを用いてＵＩ表示装置２０７がユーザー入力装置２０６を兼ねるにしてもよい。

図３は、図１に示すサーバー１０２および仲介装置１０３のハードウェア構成の一例を示すブロック図である。

図３において、サーバー１０２は、ＣＰＵ３０１、ＲＡＭ３０２、記憶装置３０３、およびネットワーク装置３０４を有しており、これらはメインバス３００によって相互に接続されている。ＲＡＭ３０２はＣＰＵ３０１のワークエリアとして用いられ、記憶装置３０３にはプログラムおよび各種設定情報が記憶される。ネットワーク装置３０４はネットワーク１００を介してＭＦＰ１０１と通信を行う。

図示の例では、ＣＰＵ３０１はメインバス３００を介してＲＡＭ３０２、記憶装置３０３、およびネットワーク装置３０４を制御する。なお、仲介装置１０３はサーバー１０２と同様のハードウェア構成を有している。

図４は、図１に示すＭＦＰ１０１、サーバー１０２、および仲介装置１０３のソフトウェア構成の一例を示す図である。なお、図４に示すソフトウェア（制御プログラム）はＭＦＰ１０１のＣＰＵ２０１又はサーバー１０２および仲介装置１０３のＣＰＵ３０１で実行される。

図４において、サーバー１０２上ではＷｅｂアプリケーション４１０が動作する。そして、Ｗｅｂアプリケーション４１０は、プレゼンテーション部４１１、ロジック部４１２、および通信部４１３を備えている。

プレゼンテーション部４１１は、通信部４１３を介して、仲介装置１０３と通信を行って、情報処理装置（以下ＭＦＰとも呼ぶ）１０１からのリクエストに応答して、ＭＦＰ１０１に表示される操作画面又は処理要求を、ＭＦＰ１０１にレスポンスとして送信する。また、プレゼンテーション部４１１はＭＦＰ１０１に表示された操作画面を介して入力された入力情報を、通信部４１３を介してＭＦＰ１０１から受け取る。

ロジック部４１２は、プレゼンテーション部４１１から通知された上記の入力情報に対する処理を行う。例えば、ロジック部４１２は、入力情報に応じて、表示する画面を変更し、そして、ＭＦＰ１０１におけるデバイス機能実行のための処理要求を作成する。

通信部４１３は、ネットワーク装置３０４（図３）を制御してＨＴＴＰプロトコルにより通信を行うソフトウェアモジュールである。

仲介装置１０３は、仲介アプリケーション４２０を備えている。そして、この仲介アプリケーション４２０は、通信部４２１および処理部４２２を有している。通信部４２１はＭＦＰ１０１から送信されたリクエストを受け付ける。そして、通信部４２１は通信部４１３を介してプレゼンテーション部４１１およびロジック部４１２に当該リクエストを送信する。

また、通信部４２１はＷｅｂアプリケーション４１０から送られたレスポンスを受けると、当該レスポンスを処理部４２２に渡す。処理部４２２はこのレスポンスを解析して、解析結果に応じて後述するように通信部４２１を介してＭＦＰ１０１と通信を行う。

ＭＦＰ１０１は、Ｗｅｂブラウザー４３０およびサービスプロバイダー部４４０を有している。Ｗｅｂブラウザー４３０およびサービスプロバイダー部４４０の各々は、ＭＦＰ１０１のＣＰＵ２０１によって実行される。なお、Ｗｅｂブラウザー４３０は、サーバー１０２から送られたコンテンツを表示するものに限定するものではない。同様に、サーバー１０２および仲介装置１０３もＨＴＴＰプロトコルに従ってリクエスト／レスポンスを送受信する機器に限定するものではない。Ｗｅｂブラウザー４３０は、任意のサーバーと通信を行うことによってコンテンツを取得して、画面に表示するといった機能を有すればよい。

図示の例では、Ｗｅｂブラウザー４３０は、通信部４３１、解析部４３２、および画面表示部４３３を有している。通信部４３１は、ＨＴＴＰプロトコルに従って、通信部４２１を介して（つまり、仲介装置１０３を介して）、サーバー１０２と通信を行う。サービスプロバイダー部４４０は、通信部４４１およびジョブ生成部４４２を有している。通信部４４１は、ＨＴＴＰプロトコルに従って、通信部４２１を介してサーバー１０２と通信を行う。

つまり、ＭＦＰ１０１において、Ｗｅｂブラウザー４３０又はサービスプロバイダー部４４０がＷｅｂアプリケーション４１０からのレスポンスに対してリクエストを行う場合、通信部４２１が通信部４３１又は４４１からリクエストを受ける。そして、通信部４２１は通信部４１３を介してプレゼンテーション部４１１にリクエストを通知する。

例えば、通信部４３１は、Ｗｅｂブラウザー４３０で表示した操作画面を介して入力される情報（入力情報）を、仲介装置１０３を介してＷｅｂアプリケーション４１０に対するリクエストとして送信する。そして、通信部４３１は、Ｗｅｂアプリケーション４１０から仲介装置１０３を介して送信されるレスポンスを受信する。

解析部４３２は、Ｗｅｂアプリケーション４１０から仲介装置１０３を介して受信したレスポンスを解析する。レスポンスにはＷｅｂブラウザー４３０が表示する操作画面の内容を示す記述であるＨＴＭＬデータが記載されている。

画面表示部４３３は、解析部４３２による解析結果に基づいて、サーバーが提供したＨＴＭＬデータを操作画面としてＵＩ表示装置２０７（図２）に画面表示する。

サービスプロバイダー部４４０において、通信部４４１は、仲介アプリケーション部４２０から処理依頼を受け付ける。処理依頼を受け付ける際に用いられるインタフェースとして、例えば、Ｗｅｂサービスインタフェースが用いられる。ジョブ生成部４４２は、通信部４４１で受け付けた処理依頼を受け取って、依頼された処理を実行するためのジョブを生成して当該ジョブを実行する。

図５は、図４に示す情報処理装置（ＭＦＰ）１０１、サーバー１０２、および仲介装置１０３における処理を説明するためのシーケンス図である。

図２〜図５を参照して、ここでは、ＭＦＰ１０１がリクエストを行って、仲介装置１０３が当該リクエストに係る処理を仲介してレスポンスとしてサーバー１０２に送信する例について説明する。

いま、ユーザーがＭＦＰ１０１においてＵＩ表示装置２０７から送信を行うためのハードウェアボタン（図示せず）を押下げると、Ｗｅｂブラウザー４３０が起動される。

Ｗｅｂブラウザー４３０は、ジョブ処理実行に係る設定画面を取得するため、サーバー１０２上のＷｅｂアプリケーション４１０に設定画面に係るリクエストを行う。図示の例では、メニュー画面（設定画面）のコンテンツを示すＵＲＬが予めＭＦＰ１０１に設定されている。

Ｗｅｂブラウザー４３０はＵＲＬで示されるコンテンツを保持するＷｅｂアプリケーション４１０に対して、ＨＴＴＰのＧＥＴコマンドによるリクエストを行う。具体的には、Ｗｅｂブラウザー４３０において、通信部４３１はＨＴＭＬデータ（ＵＲＬ）に応じてＨＴＴＰプロトコルによって仲介装置１０３の通信部４２１と通信を行う。そして、通信部４２１は、サーバー１０２の通信部４１３と通信を行う。

これによって、通信部４１３は受信したＵＲＬに応じてＷｅｂアプリケーション４１０にＨＴＭＬデータを渡す。この結果、Ｗｅｂブラウザー４３０からＷｅｂアプリケーション４１０に対するリクエストが行われることになる。なお、以下の説明では、通信部４３１、通信部４２１、および通信部４３１の動作（処理）について説明を省略する。

前述のように、Ｗｅｂブラウザー４３０から仲介アプリケーション４２０に対してリクエストが行われると（ステップＳ５０１）、仲介アプリケーション４２０はＷｅｂブラウザー４３０から受けたリクエストをＷｅｂアプリケーション４１０に転送する（ステップＳ５０２）。

Ｗｅｂアプリケーション４１０はリクエストの内容に応じた処理を行って、その処理結果をレスポンスとして仲介アプリケーション４２０に送る（ステップＳ５０３）。仲介アプリケーション４２０は、レスポンスを受けると後述する判断処理を行って、当該レスポンスをＷｅｂブラウザー４３０およびサービスプロバイダー部４４０の双方又はいずれか一方に送るか否かを決定する。

仲介アプリケーション４２０は、判断処理の結果に応じてＷｅｂブラウザー４３０およびサービスプロバイダー部４４０の双方又はいずれか一方に送る（ステップＳ５０４およびＳ５０５）。

Ｗｅｂブラウザー４３０はレスポンスを受けると、当該レスポンスが示す処理結果をＵＩ表示装置２０７（図２）に表示して処理を終了する。一方、サービスプロバイダー部４４０はレスポンスを受けると、レスポンスに応じた処理を行ってその結果を仲介アプリケーション４２０に送る（ステップＳ５０６）。そして、仲介アプリケーション４２０は、サービスプロバイダー部４４０から受信した処理結果をＷｅｂアプリケーション４１０に送って処理を終了する。

図６は、図４に示す仲介アプリケーション４２０においてＭＦＰ１０１（Ｗｅｂブラウザー４３０とサービスプロバイダー部４４０）とＷｅｂアプリケーション４１０とを仲介する処理を説明するためのフローチャートである。

なお以降の説明では、ＭＦＰ１０１がインターネット上のサーバー１０２（Ｗｅｂアプリケーション４１０）宛てに送信するメッセージのことを「ＨＴＴＰリクエストメッセージ」と呼ぶ。そして、サーバー１０２（Ｗｅｂアプリケーション４１０）がそのＨＴＴＰリクエストメッセージの応答として送信するメッセージのことを「ＨＴＴＰレスポンスメッセージ」と呼ぶ。Ｗｅｂブラウザー４３０は、ＨＴＴＰリクエストメッセージの中に、サーバー１０２が提供する操作画面のコンテンツを要求するコマンドや、その他にもＷｅｂアプリケーション４１０に各種の処理を実行するためのコマンドを含めて送信することができる。

一方、Ｗｅｂアプリケーション４１０は、ＨＴＴＰリクエストメッセージの応答であるＨＴＴＰレスポンスメッセージの中にＭＦＰ１０１に処理を要求するコマンドを含めることができる。例えば、ＭＦＰ１０１に対するスキャン処理を要求するコマンドやファイルを送信する処理を要求するコマンド等をＨＴＴＰレスポンスメッセージに含めて送信し、そのメッセージに含まれるコマンドに従って情報処理装置にジョブを実行させる。このような構成とすることで、ＭＦＰ１０１とサーバー１０２との間にファイアウォールが存在する場合でも、サーバー１０２が情報処理装置に対して処理を要求することができる。

図６及び図７のフローチャートは、ＭＦＰ１０１が備えるＷｅｂブラウザー４３０からＨＴＴＰリクエストメッセージを受信したことにより、処理が開始される。

図４および図６を参照して、いま、仲介アプリケーション４２０はＷｅｂブラウザー４３０からＷｅｂアプリケーション４１０宛てのＨＴＴＰリクエストメッセージを受信すると、当該ＨＴＴＰリクエストメッセージをＷｅｂアプリケーション４１０に転送する（ステップＳ６０１）。そして仲介アプリケーション４２０は、Ｗｅｂアプリケーション４１０からＨＴＴＰリクエストメッセージの応答としてＨＴＴＰレスポンスメッセージを受信する（ステップＳ６０２）。

ここで、Ｗｅｂアプリケーション４１０が仲介アプリケーション４２０に送信するＨＴＴＰレスポンスヘッダーについて図９を参照して説明する。図９は、Ｗｅｂアプリケーション４１０が仲介アプリケーション４２０に送信するＨＴＴＰレスポンスメッセージのヘッダー部の構成を示す図である。

図９に示すように、ＨＴＴＰレスポンスメッセージのヘッダー部９００は、宛先９０１（Ｘ−Ｗｅｂ Ｓｅｒｖｉｃｅ−Ａｄｄｒｅｓｓ）、タイムアウト時間９０２（Ｘ−Ｗｅｂ ｓｅｒｖｉｃｅ−Ｒｅｑｕｅｓｔ Ｔｉｍｅ ｏｕｔ）、およびコンテントタイプ９０３（Ｃｏｎｔｅｎｔ−Ｔｙｐｅ）を備えている。仲介アプリケーション４２０は、例えば、図５に示すステップＳ５０５において、宛先９０１に応じてＨＴＴＰレスポンスメッセージのボディー部に記述されたコマンドを送信する。送信するコマンドは、ここでは図示しないがＳＯＡＰ（Ｓｉｍｐｌｅ Ｏｂｊｅｃｔ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ）に従ったＸＭＬ形式のメッセージであり、サービスプロバイダー部４４０にスキャンやプリント、ファイル送信等のジョブを実行させるものである。

タイムアウト時間９０２は、例えば、仲介装置１０３がサービスプロバイダー部４４０と通信する際のタイムアウト時間であり、秒単位で示される。仲介装置１０３は、サービスプロバイダー部４４０と通信を行う際に時間を計測し、タイムアウト時間９０２で指定された時間が経過すると通信を停止し、仲介装置１０３はタイムアウトエラーレスポンスをＷｅｂアプリケーション４１０に送る。図６のフローチャートの説明に戻る。Ｓ６０２でＨＴＴＰレスポンスメッセージをＷｅｂアプリケーション４１０から受信すると、仲介アプリケーション４２０は、ＨＴＴＰレスポンスメッセージに含まれるヘッダー部のＣｏｎｔｅｎｔ−Ｔｙｐｅフィールド（コンテントタイプフィールド）８０３がａｐｐｌｉｃａｔｉｏｎ／ｖｎｄ．ｃａｎｏｎ．ｗｅｂｓｅｒｖｉｃｅであるか否かを判定する（ステップＳ６０３）。

Ｃｏｎｔｅｎｔ−Ｔｙｐｅフィールド８０３がａｐｐｌｉｃａｔｉｏｎ／ｖｎｄ．ｃａｎｏｎ．ｗｅｂｓｅｒｖｉｃｅでないと判定した場合には（ステップ６０３において、ＮＯ）、判定結果に応じて、仲介アプリケーション４２０はそのＨＴＴＰレスポンスメッセージをＷｅｂブラウザー４３０に送信し（ステップＳ６０４）、本フローチャートの処理を終了する。

一方Ｃｏｎｔｅｎｔ−ＴｙｐｅフィールドがＷｅｂサービスの呼び出しを要求する属性、すなわち、ａｐｐｌｉｃａｔｉｏｎ／ｖｎｄ．ｃａｎｏｎ．ｗｅｂｓｅｒｖｉｃｅであると判定した場合（ステップ６０３において、ＹＥＳ）、ステップＳ６０６に進む。ステップＳ６０６では、仲介アプリケーション４２０はＨＴＴＰレスポンスメッセージに含まれるＳＯＡＰのコマンドをサービスプロバイダー部４４０に送信してＷｅｂサービスを呼び出す（ステップＳ６０６）。一般に、クライアント／サーバシステムにおいては、ＨＴＴＰリクエストメッセージに対するＨＴＴＰレスポンスメッセージはリクエストを発行したクライアント（ここではＷｅｂブラウザー４３０）に返却される。ただしステップＳ６０６に処理を進めた場合には、Ｗｅｂブラウザー４３０が送信したＨＴＴＰリクエストメッセージの応答がＷｅｂブラウザー４３０ではなくサービスプロバイダー部４４０に送信される。そのため、Ｗｅｂブラウザー４３０はこの時点ではＨＴＴＰリクエストメッセージに対する応答の待ち状態となっている。

Ｓ６０６で仲介装置１０３（仲介アプリケーション４２０）がＳＯＡＰのコマンドをＭＦＰ１０１のサービスプロバイダー部４４０に送信すると、サービスプロバイダー部４４０ではその送信されたコマンドに従いジョブ生成部４４２でジョブ（スキャンジョブや送信ジョブなど）を生成し、ＷｅｂサービスとしてＭＦＰ１０１の処理手段に画像処理を実行させる。例えば、受け取ったコマンドがスキャンの要求である場合には画像読取機能により原稿を読み取って画像データを生成する。そして、ファイル送信の要求である場合には画像送信機能により指定宛先へ画像データを送信する。

図７は、図６のフローチャートの処理の続きを説明するためのフローチャートである。ここでは、サービスプロバイダー部４４０から仲介アプリケーション４２０経由で処理結果をＷｅｂアプリケーション４１０に送信した後、再度Ｗｅｂアプリケーション４１０から仲介装置１０３に処理依頼があったものとする。図示の例では、サービスプロバイダー部４４０に返却されるべきＨＴＴＰレスポンスメッセージについて、当該ＨＴＴＰレスポンスメッセージのヘッダー部におけるＣｏｎｔｅｎｔ−Ｔｙｐｅフィールドを解析して、その解析結果に応じてＨＴＴＰレスポンスメッセージをサービスプロバイダー部４４０及びＷｅｂブラウザー４３０のいずれに送信すべきかを決定する。

前述したように、ステップＳ６０６で仲介装置１０３（仲介アプリケーション４２０）がＷｅｂサービスを呼び出し、その結果サービスプロバイダー部４４０によりジョブが実行されると、その後、仲介アプリケーション４２０はサービスプロバイダー部４４０から処理結果（例えば、ジョブ処理結果）を取得する（ステップＳ８０１）。そして、仲介アプリケーション４２０は取得した処理結果を含むＨＴＴＰリクエストメッセージをＷｅｂアプリケーション４１０に送信する（ステップＳ８０２）。

続いて、仲介アプリケーション４２０は再度サーバー１０２（Ｗｅｂアプリケーション４１０）から処理に関する指示を含むＨＴＴＰレスポンスメッセージを受信する（ステップＳ８０３）。仲介アプリケーション４２０はステップＳ６０３の処理と同様にＨＴＴＰレスポンスメッセージのヘッダー部のＣｏｎｔｅｎｔ−Ｔｙｐｅフィールドを解析する。Ｃｏｎｔｅｎｔ−Ｔｙｐｅフィールドが再度サービスプロバイダー部４４０にＷｅｂサービスを要求する属性（ａｐｐｌｉｃａｔｉｏｎ／ｖｎｄ．ｃａｎｏｎ．ｗｅｂｓｅｒｖｉｃｅ）である場合には（ステップＳ８０４でＹＥＳ）ステップＳ８０７に進む。ステップＳ８０７では、Ｓ８０３で受信したＨＴＴＰリクエストメッセージに含まれるＳＯＡＰのコマンドを再度サービスプロバイダー部４４０に送信しＷｅｂサービスを呼び出す。一方Ｗｅｂサービスを要求する属性でなければ(ステップＳ８０４でＮＯ)、Ｗｅｂアプリケーション４１０からの指示はサービスプロバイダー部４４０への指示ではなくＷｅｂブラウザー４３０への指示と判断し、ステップＳ８０５に進む。ステップＳ８０５では、仲介アプリケーション４２０はＷｅｂブラウザー４３０にＨＴＴＰレスポンスメッセージを送信し（ステップＳ８０８）本フローチャートの処理を終了する。

以上、図６及び図７で説明したように、仲介アプリケーション４２０はコンテントタイプ９０３に応じて、ＨＴＴＰレスポンスメッセージのボディー部の内容がサービスプロバイダー部４４０に対する処理要求であるか又はＷｅｂブラウザー４３０で表示するＨＴＭＬコンテンツであるかを判定する。具体的には、ＨＴＴＰレスポンスメッセージのヘッダー部にＷｅｂサービスの要求を示す属性（ａｐｐｌｉｃａｔｉｏｎ／ｖｎｄ．ｃａｎｏｎ．ｗｅｂｓｅｒｖｉｃｅ）があるか否かを解析することで上記判定を行う。そして、Ｗｅｂサービスの要求を示す属性がある場合、そのＨＴＴＰレスポンスメッセージに含まれるＷｅｂサービスの要求を示すコマンドをサービスプロバイダー部４４０に送信する。

本実施形態では、Ｗｅｂブラウザー４３０が送信したＨＴＴＰリクエストメッセージの応答であるＨＴＴＰレスポンスメッセージにＷｅｂサービスを要求する属性を含む場合は、そのメッセージはＷｅｂブラウザー４３０で受信せず、仲介アプリケーション４２０がサービスプロバイダー部４４０へ転送するように構成した。そのため、Ｗｅｂブラウザーには特別な機能を拡張する必要がない。

以上のように、本実施の形態によれば、ＭＦＰなどの情報処理装置が備えるインタフェースに機能拡張などの変更が行われても、ＭＦＰが備えるモジュール（特にＷｅｂブラウザー）の変更を行う必要がない。つまり、情報処理装置においてジョブ処理を司るサービスプロバイダー部が拡張されても柔軟に対応することができる。そして、情報処理装置に呼び出しのためのアプリケーションを組み込むことなく、サーバーとは別に仲介装置を配置して、当該仲介装置で動作する仲介アプリケーションによって呼び出しを行うようにしたので、ユーザーに対する影響を少なくして、システムの拡張を行うことができる。

図８は、図４に示す仲介アプリケーション４２０がサービスプロバイダー部４４０のＷｅｂサービスを呼び出した際のタイムアウト処理を説明するためのフローチャートである。

図４および図７を参照して、図６で説明したように、Ｃｏｎｔｅｎｔ−Ｔｙｐｅフィールドがａｐｐｌｉｃａｔｉｏｎ／ｖｎｄ．ｃａｎｏｎ．ｗｅｂｓｅｒｖｉｃｅであると、仲介アプリケーション４２０はＨＴＴＰレスポンスメッセージに記載されたサービスプロバイダー部４４０に係るＷｅｂサービスを呼び出す。つまり、仲介アプリケーション４２０はサービスプロバイダー部４４０のインタフェースであるＷｅｂサービスを呼び出す（ステップＳ７０１）。そして、仲介アプリケーション４２０はＷｅｂサービス呼び出しを行った後、所定のタイムアウト時間の監視を開始する（ステップＳ７０２）。

仲介アプリケーション４２０はタイムアウト時間が経過したか否かをチェックする（ステップＳ７０３）。タイムアウト時間が経過しないと（ステップ７０３において、ＮＯ）、仲介アプリケーション４２０はサービスプロバイダー部４４０から処理結果を受信したか否かをチェックする（ステップＳ７０４）。

サービスプロバイダー部４４０から処理結果を受信しないと（ステップＳ７０４において、ＮＯ）、仲介アプリケーション４２０はステップＳ７０３の処理に戻る。一方、サービスプロバイダー部４４０から処理結果を受信すると（ステップＳ７０４において、ＹＥＳ）、仲介アプリケーション４２０は処理を終了する。

タイムアウト時間が経過すると（ステップ７０３において、ＹＥＳ）、仲介アプリケーション４２０はタイムアウトエラーと判定して、タイムアウトエラーレスポンスをＷｅｂアプリケーション４１０に通知する（ステップＳ７０５）。そして、仲介アプリケーション４２０は処理を終了する。

上述の説明から明らかなように、図４において、Ｗｅｂブラウザー４３０が表示制御手段として機能し、サービスプロバイダー部４４０がジョブ処理手段として機能する。また、仲介アプリケーション４２０が送受信手段、判定手段、および送信手段として機能する。加えて、仲介アプリケーション４２０はカウント手段および通知手段として機能する。

以上、本発明について実施の形態に基づいて説明したが、本発明は、これらの実施の形態に限定されるものではなく、この発明の要旨を逸脱しない範囲の様々な形態も本発明に含まれる。

例えば、上記の実施の形態の機能を制御方法として、この制御方法を、中継装置（仲介装置）に実行させるようにすればよい。また、上述の実施の形態の機能を有するプログラムを制御プログラムとして、この制御プログラムを中継装置が備えるコンピュータに実行させるようにしてもよい。なお、制御プログラムは、例えば、コンピュータに読み取り可能な記録媒体に記録される。

この際、制御方法および制御プログラムは、少なくとも送受信ステップ、判定ステップ、および送信ステップを有することになる。

また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記録媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。

４１０ Ｗｅｂアプリケーション
４１１ プレゼンテーション部
４１２ ロジック部
４１３，４３１，４４１ 通信部
４３０ Ｗｅｂブラウザー
４３２ 解析部
４３２ 画面表示部
４４０ サービスプロバイダー部
４４２ ジョブ生成部

Claims (9)

1. 画像形成装置と、外部サーバと通信するためのプロキシサーバとを有するネットワークシステムであって、
   前記画像形成装置は、
   ウェブブラウザにより表示される操作画面で情報の入力を受け付ける入力手段と、
   前記プロキシサーバから受信したコマンドに従って、ジョブを実行する実行手段と、を備え、
   前記プロキシサーバは、
   前記入力手段で入力された情報を含む第１のリクエストを前記画像形成装置のウェブブラウザから受信したことに応じて、前記第１のリクエストを前記外部サーバに転送し、前記第１のリクエストに対する第１のレスポンスを前記外部サーバから受信したことに応じて、前記第１のレスポンスを前記ウェブブラウザに転送する転送手段を有し、
   前記転送手段は、
   前記コマンドが前記第１のレスポンスに含まれる場合は、前記ウェブブラウザに前記第１のレスポンスを転送するのではなく、前記実行手段に前記第１のレスポンスに含まれる前記コマンドを送信することを特徴とするネットワークシステム。
2. 前記第１のレスポンスはＨＴＴＰプロトコルに応じたレスポンスであり、
   前記第１のレスポンスのヘッダーにおけるコンテントタイプフィールドに応じて、前記コマンドが前記第１のレスポンスに含まれるか否かを判定する判定手段を更に有することを特徴とする請求項１に記載のネットワークシステム。
3. 前記プロキシサーバは、前記実行手段から前記コマンドに従った前記ジョブの実行処理結果を受信すると、前記ジョブの実行処理結果を前記実行手段から受信したことに応じて、前記ジョブの実行処理結果を含む第２のリクエストを前記外部サーバに送信し、
   前記転送手段は、前記第１のリクエストと同一のプロトコルである第２のレスポンスを、前記第２のリクエストに対するレスポンスとして前記外部サーバから受信したことに応じて、前記第２のレスポンスを前記ウェブブラウザに転送することを特徴とする請求項１又は２記載のネットワークシステム。
4. 前記プロキシサーバは、
   前記第１のレスポンスに含まれる前記コマンドを前記実行手段に送信すると、カウントを開始するカウント手段と、
   前記カウント手段によるカウントが所定のタイムアウト時間を経過するまでに前記ジョブの実行処理結果を前記実行手段から受信しなかった場合、タイムアウトエラーを前記外部サーバに通知する通知手段とを更に有することを特徴とする請求項１乃至３のいずれか１項に記載のネットワークシステム。
5. 前記実行手段は、原稿を読み取って画像データを生成するスキャンジョブを実行することを特徴とする請求項１乃至４のいずれか１項に記載のネットワークシステム。
6. 前記実行手段は、指定宛先へ画像データを送信する送信ジョブを実行することを特徴とする請求項１乃至５のいずれか１項に記載のネットワークシステム。
7. 画像形成装置と、外部サーバと通信するためのプロキシサーバとを有するネットワークシステムの制御方法であって、
   前記画像形成装置におけるウェブブラウザにより表示される操作画面で情報の入力を受け付ける入力ステップと、
   前記プロキシサーバから受信したコマンドに従って、ジョブを前記画像形成装置における実行手段により実行する実行ステップと、
   前記プロキシサーバにおいて、前記入力ステップにおいて入力された情報を含む第１のリクエストを前記ウェブブラウザから受信したことに応じて、前記第１のリクエストを前記外部サーバに転送し、前記第１のリクエストに対する第１のレスポンスを前記外部サーバから受信したことに応じて、前記第１のレスポンスを前記ウェブブラウザに転送する転送ステップとを有し、
   前記転送ステップは、前記コマンドが前記第１のレスポンスに含まれる場合は、前記ウェブブラウザに前記第１のレスポンスを転送するのではなく、前記実行手段に前記第１のレスポンスに含まれる前記コマンドを送信することを特徴とするネットワークシステムの制御方法。
8. 画像形成装置と、外部サーバと通信するためのプロキシサーバとを有するネットワークシステムの制御方法をコンピュータに実行させるための制御プログラムであって、
   前記ネットワークシステムの制御方法は、
   前記画像形成装置におけるウェブブラウザにより表示される操作画面で情報の入力を受け付ける入力ステップと、
   前記プロキシサーバから受信したコマンドに従ってジョブを前記画像形成装置における実行手段により実行する実行ステップと、
   前記プロキシサーバにおいて、前記入力ステップにおいて入力された情報を含む第１のリクエストを前記ウェブブラウザから受信したことに応じて、前記第１のリクエストを前記外部サーバに転送し、前記第１のリクエストに対する第１のレスポンスを前記外部サーバから受信したことに応じて、前記第１のレスポンスを前記ウェブブラウザに転送する転送ステップとを有し、
   前記転送ステップは、前記コマンドが前記第１のレスポンスに含まれる場合は、前記ウェブブラウザに前記第１のレスポンスを転送するのではなく、前記実行手段に前記第１のレスポンスに含まれる前記コマンドを送信することを特徴とする制御プログラム。
9. 画像形成装置を外部サーバと通信させるためのプロキシサーバであって、
   前記画像形成装置の入力手段により入力された情報を含む第１のリクエストを前記画像形成装置のウェブブラウザから受信したことに応じて、前記第１のリクエストを前記外部サーバに転送し、前記第１のリクエストに対する第１のレスポンスを前記外部サーバから受信したことに応じて、前記第１のレスポンスを前記ウェブブラウザに転送する転送手段を有し、
   前記転送手段は、
   前記画像形成装置の実行手段にジョブを実行させるためのコマンドが前記第１のレスポンスに含まれる場合は、前記ウェブブラウザに前記第１のレスポンスを転送するのではなく、前記実行手段に前記第１のレスポンスに含まれる前記コマンドを送信することを特徴とするプロキシサーバ。

Images