中継装置、その制御方法、および制御プログラム
【課題】ＭＦＰなどの情報処理装置が備えるインタフェースに機能拡張などの変更が行われても、情報処理装置が備えるモジュールの変更を行う必要がないようにする。
【解決手段】仲介アプリケーション４２０はＭＦＰ１０１に表示された操作画面の操作に応じたリクエストをサーバー１０２に送信するとともに、リクエストに対するレスポンスをサーバーから受信する。仲介アプリケーションはレスポンスの内容に応じてレスポンスをＷｅｂブラウザー４３０およびサービスプロバイダー部４４０の双方又はいずれに送信するかを判定する。仲介アプリケーションは判定結果に応じてレスポンスをＷｅｂブラウザーおよびサービスプロバイダー部の双方又はいずれに送信する。
【解決手段】仲介アプリケーション４２０はＭＦＰ１０１に表示された操作画面の操作に応じたリクエストをサーバー１０２に送信するとともに、リクエストに対するレスポンスをサーバーから受信する。仲介アプリケーションはレスポンスの内容に応じてレスポンスをＷｅｂブラウザー４３０およびサービスプロバイダー部４４０の双方又はいずれに送信するかを判定する。仲介アプリケーションは判定結果に応じてレスポンスをＷｅｂブラウザーおよびサービスプロバイダー部の双方又はいずれに送信する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、中継装置、その制御方法、および制御プログラムに関し、特に、外部装置から提供される操作画面を表示して当該操作画面による操作に応じた処理を行う情報処理装置と外部装置と情報処理装置とを仲介する中継装置に関する。
【背景技術】
【０００２】
従来、スキャナやプリンタ、ファクシミリ、ネットワーク送信装置などの各装置の機能を１つの筺体内に収納した画像処理装置が一般的に知られている。このような画像処理装置の操作部にＷｅｂブラウザーを用いる形態も一般的である。ここで、Ｗｅｂブラウザーで表示する操作画面で上述の各機能を利用する形態として特許文献１のような方法が知られている。
【０００３】
特許文献１によると、画像処理装置が備えているＷｅｂブラウザーは、ネットワーク上の外部装置から受信した画面情報（画面データ）に基づいて画像処理機能に関する操作画面を操作部に表示する。そして、その操作画面を用いてユーザーの操作を受けると、Ｗｅｂブラウザーは、ユーザーから受け付けた操作の内容を外部装置へ送信する。その後、画像処理装置は、外部装置からそのユーザーの操作に基づくＷｅｂサービスの要求を受信する。画像処理装置は、Ｗｅｂサービスの要求に応じて画像処理装置のスキャン機能又はプリント機能を実行する。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００６−２０３８６９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
Ｗｅｂブラウザーを備える情報処理装置と、ネットワーク上に存在する外部装置との間にファイアウォールが存在する場合がある。ファイアウォールは一般的に内部から外部への接続は許可するが外部から内部への接続は許可しない。そのため上述した従来の方法では、外部装置からのＷｅｂサービスの要求を受け付けることができない場合がある。
【０００６】
また、ネットワークアドレス変換装置（ＮＡＴ）によりＩＰアドレスとプライベートアドレスを相互に変換してアドレスを使用する環境にＭＦＰが存在する場合には、Ｗｅｂサービスを要求するＭＦＰをインターネット上の外部装置からは特定できない、という問題がある。
【０００７】
本発明は、上述のような課題にかんがみて、ＭＦＰと外部装置との間にファイアウォールが存在する場合や、ＭＦＰがアドレス変換を用いる環境に存在する場合でも、好適に外部装置からのＷｅｂサービスの要求をＭＦＰに処理させるための手段を提供することを目的とする。
【課題を解決するための手段】
【０００８】
上記目的を達成するため、本発明による中継装置は、外部装置とネットワークを介して接続され、前記外部装置から提供される操作画面の操作に応じてジョブ処理を実行する情報処理装置と前記外部装置とを仲介する中継装置であって、前記情報処理装置には、前記操作画面を表示部に表示する表示制御手段と、前記ジョブ処理を実行するジョブ処理手段とが備えられており、前記操作画面の操作に応じたリクエストを前記情報処理装置から受信して前記外部装置に送信し、前記リクエストに対するレスポンスを前記外部装置から受信する送受信手段と、前記レスポンスの内容に応じて前記レスポンスを前記表示制御手段および前記ジョブ処理手段のいずれに送信するかを判定する判定手段と、前記判定手段による判定結果に応じて前記レスポンスを前記表示制御手段および前記ジョブ処理手段のいずれに送信する送信手段とを有することを特徴とする。
【発明の効果】
【０００９】
本発明によれば、ネットワーク上に存在する外部装置との間にファイアウォールが存在する場合や、ＭＦＰがアドレス変換を用いる環境に存在する場合でも、外部装置から送信されたＷｅｂサービスの要求であってＷｅｂブラウザーでの操作に基づくＷｅｂサービスの要求を好適に処理することができる。
【図面の簡単な説明】
【００１０】
【図１】本発明の実施の形態による中継装置および情報処理装置が収容されたネットワークシステムの一例を示す図である。
【図２】図１に示す情報処理装置についてその構成の一例を示すブロック図である。
【図３】図１に示すサーバーおよび仲介装置のハードウェア構成の一例を示すブロック図である。
【図４】図４は、図１に示す情報処理装置、サーバー、および仲介装置のソフトウェア構成の一例を示す図である。
【図５】図４に示す情報処理装置（ＭＦＰ）、サーバー、および仲介装置における処理を説明するためのシーケンス図である。
【図６】仲介装置における処理を説明するためのフローチャートである。
【図７】仲介装置における処理を説明するためのフローチャートである。
【図８】仲介装置がＭＦＰのＷｅｂサービスを呼び出した際のタイムアウト処理を説明するためのフローチャートである。
【図９】図４に示すＷｅｂアプリケーションが仲介アプリケーションに送信するＨＴＴＰレスポンスヘッダーの構成を示す図である。
【発明を実施するための形態】
【００１１】
以下、本発明の実施の形態による中継装置の一例について図面を参照して説明する。
【００１２】
図１は、本発明の実施の形態による中継装置および情報処理装置が収容されたネットワークシステムの一例を示す図である。図示の例では、情報処理装置１０１と中継装置（以下仲介装置あるいはプロキシサーバとも呼ぶ）１０３がローカルエリアネットワーク（ＬＡＮ）１００を介して互いに通信可能に接続されている。またインターネット上にはサーバー（Ｗｅｂサーバー）１０２が存在する。
【００１３】
本実施形態では、図１には図示しないが、インターネットとＬＡＮ１００との間にはファイアウォール及びＮＡＴ（Ｎｅｔｗｏｒｋ Ａｄｄｒｅｓｓ Ｔｒａｎｓｌａｔｏｒ）が設けられている。ファイアウォールはインターネットからＬＡＮ１００内への不正アクセスを防止する機能を持っている。
【００１４】
またＮＡＴは、ＩＰアドレスとＬＡＮ１００内で使用するプライベートアドレスとを相互に変換するアドレス変換テーブルを持つ。このアドレス変換テーブルによるアドレス変換により、プライベートアドレスしか持たないＬＡＮ１００内の装置がインターネット上の外部装置に透過的にアクセスすることができる。
【００１５】
なお以降では、情報処理装置１０１の一例として画像形成（印刷）機能、画像読取機能、画像送信機能などの各種の画像処理機能を備えたＭＦＰ（Ｍｕｌｔｉｐｌｅ Ｆｕｎｃｔｉｏｎ Ｐｅｒｉｐｈｅｒａｌ）について説明する。
【００１６】
ＭＦＰ１０１は所謂Ｗｅｂブラウザー機能を有しており、サーバー１０２はＷｅｂコンテンツを、ネットワーク１００を介して配信する配信機能を有している。そして、サーバー１０２はＭＦＰ１０１からのリクエストに応じてＷｅｂコンテンツをＭＦＰ１０１に返送する。なお、ＭＦＰ１０１は通信を行うための複数のインタフェースを備えている。
【００１７】
ＭＦＰ１０１は、上述のブラウザー機能を用いてサーバー１０２にリクエストを送信する場合、必ず中継装置（仲介装置）１０３を介するよう設定されている。そのため、ＭＦＰ１０１のＷｅｂブラウザーで送信されたサーバー１０２へのリクエスト及びそのリクエストに対するレスポンスは、全て中継装置（仲介装置）１０３を介することになる。
【００１８】
仲介装置１０３は、サーバー１０２とＭＦＰ１０１との間の通信を仲介する。例えば、サーバー１０２からＭＦＰ１０１にリクエスト又はレスポンスを送信する際、仲介装置１０３はその通信内容を解析して、この解析結果に応じて、ＭＦＰ１０１が備える複数のインタフェースのいずれかを選択する処理を行う。さらに、仲介装置１０３はＭＦＰ１０１で実行された処理結果（ジョブ処理結果）をサーバー１０１に送る。
【００１９】
なお、本実施形態ではサーバー（Ｗｅｂサーバー）を外部装置の一例として説明するが、汎用のパーソナルコンピュータを外部装置として適用してもよいことはいうまでもない。
【００２０】
図２は、図１に示すＭＦＰ１０１についてその構成の一例を示すブロック図である。
【００２１】
図２において、ＭＦＰ１０１は、ＣＰＵ２０１を有しており、ＣＰＵ２０１はＭＦＰ１０１全体の制御を司る。さらに、ＭＦＰ１０１は、ＣＰＵ２０１のワークエリアとして用いられるＲＡＭ２０２、原稿から画像を読み取る読取装置２０３、および画像データに応じて印刷を行う印刷装置２０４を備えている。また、ＭＦＰ１０１は、記憶装置２０５、ユーザー入力装置２０６、ＵＩ（ユーザーインタフェース）表示装置２０７、およびネットワーク装置２０８を備えている。そして、これらＣＰＵ２０１、ＲＡＭ２０２、読取装置２０３、印刷装置２０４、記憶装置２０５、ユーザー入力装置２０６、ＵＩ表示装置２０７、およびネットワーク装置２０８はメインバス２００で相互に接続されている。
【００２２】
記憶装置２０５にはプログラムおよび各種設定情報が記憶され、例えば、ＨＤＤ又はＮＶＲＡＭ等が用いられる。ユーザー入力装置２０６はユーザーがコマンドの入力を行うためのものであり、ＵＩ表示装置２０７には各種画面表示が行われる。ネットワーク装置２０８は外部機器（例えば、サーバー１０２）とネットワーク１００を介して通信を行うためのものである。なお、図示の例では、ＣＰＵ２０１はメインバス２００を介してＲＡＭ２０２、読取装置２０３、印刷装置２０４、記憶装置２０５、ユーザー入力装置２０６、ＵＩ表示装置２０７、およびネットワーク装置２０８を制御する。また、タッチパネルディスプレイを用いてＵＩ表示装置２０７がユーザー入力装置２０６を兼ねるにしてもよい。
【００２３】
図３は、図１に示すサーバー１０２および仲介装置１０３のハードウェア構成の一例を示すブロック図である。
【００２４】
図３において、サーバー１０２は、ＣＰＵ３０１、ＲＡＭ３０２、記憶装置３０３、およびネットワーク装置３０４を有しており、これらはメインバス３００によって相互に接続されている。ＲＡＭ３０２はＣＰＵ３０１のワークエリアとして用いられ、記憶装置３０３にはプログラムおよび各種設定情報が記憶される。ネットワーク装置３０４はネットワーク１００を介してＭＦＰ１０１と通信を行う。
【００２５】
図示の例では、ＣＰＵ３０１はメインバス３００を介してＲＡＭ３０２、記憶装置３０３、およびネットワーク装置３０４を制御する。なお、仲介装置１０３はサーバー１０２と同様のハードウェア構成を有している。
【００２６】
図４は、図１に示すＭＦＰ１０１、サーバー１０２、および仲介装置１０３のソフトウェア構成の一例を示す図である。なお、図４に示すソフトウェア（制御プログラム）はＭＦＰ１０１のＣＰＵ２０１又はサーバー１０２および仲介装置１０３のＣＰＵ３０１で実行される。
【００２７】
図４において、サーバー１０２上ではＷｅｂアプリケーション４１０が動作する。そして、Ｗｅｂアプリケーション４１０は、プレゼンテーション部４１１、ロジック部４１２、および通信部４１３を備えている。
【００２８】
プレゼンテーション部４１１は、通信部４１３を介して、仲介装置１０３と通信を行って、情報処理装置（以下ＭＦＰとも呼ぶ）１０１からのリクエストに応答して、ＭＦＰ１０１に表示される操作画面又は処理要求を、ＭＦＰ１０１にレスポンスとして送信する。また、プレゼンテーション部４１１はＭＦＰ１０１に表示された操作画面を介して入力された入力情報を、通信部４１３を介してＭＦＰ１０１から受け取る。
【００２９】
ロジック部４１２は、プレゼンテーション部４１１から通知された上記の入力情報に対する処理を行う。例えば、ロジック部４１２は、入力情報に応じて、表示する画面を変更し、そして、ＭＦＰ１０１におけるデバイス機能実行のための処理要求を作成する。
【００３０】
通信部４１３は、ネットワーク装置３０４（図３）を制御してＨＴＴＰプロトコルにより通信を行うソフトウェアモジュールである。
【００３１】
仲介装置１０３は、仲介アプリケーション４２０を備えている。そして、この仲介アプリケーション４２０は、通信部４２１および処理部４２２を有している。通信部４２１はＭＦＰ１０１から送信されたリクエストを受け付ける。そして、通信部４２１は通信部４１３を介してプレゼンテーション部４１１およびロジック部４１２に当該リクエストを送信する。
【００３２】
また、通信部４２１はＷｅｂアプリケーション４１０から送られたレスポンスを受けると、当該レスポンスを処理部４２２に渡す。処理部４２２はこのレスポンスを解析して、解析結果に応じて後述するように通信部４２１を介してＭＦＰ１０１と通信を行う。
【００３３】
ＭＦＰ１０１は、Ｗｅｂブラウザー４３０およびサービスプロバイダー部４４０を有している。Ｗｅｂブラウザー４３０およびサービスプロバイダー部４４０の各々は、ＭＦＰ１０１のＣＰＵ２０１によって実行される。なお、Ｗｅｂブラウザー４３０は、サーバー１０２から送られたコンテンツを表示するものに限定するものではない。同様に、サーバー１０２および仲介装置１０３もＨＴＴＰプロトコルに従ってリクエスト／レスポンスを送受信する機器に限定するものではない。Ｗｅｂブラウザー４３０は、任意のサーバーと通信を行うことによってコンテンツを取得して、画面に表示するといった機能を有すればよい。
【００３４】
図示の例では、Ｗｅｂブラウザー４３０は、通信部４３１、解析部４３２、および画面表示部４３３を有している。通信部４３１は、ＨＴＴＰプロトコルに従って、通信部４２１を介して（つまり、仲介装置１０３を介して）、サーバー１０２と通信を行う。サービスプロバイダー部４４０は、通信部４４１およびジョブ生成部４４２を有している。通信部４４１は、ＨＴＴＰプロトコルに従って、通信部４２１を介してサーバー１０２と通信を行う。
【００３５】
つまり、ＭＦＰ１０１において、Ｗｅｂブラウザー４３０又はサービスプロバイダー部４４０がＷｅｂアプリケーション４１０からのレスポンスに対してリクエストを行う場合、通信部４２１が通信部４３１又は４４１からリクエストを受ける。そして、通信部４２１は通信部４１３を介してプレゼンテーション部４１１にリクエストを通知する。
【００３６】
例えば、通信部４３１は、Ｗｅｂブラウザー４３０で表示した操作画面を介して入力される情報（入力情報）を、仲介装置１０３を介してＷｅｂアプリケーション４１０に対するリクエストとして送信する。そして、通信部４３１は、Ｗｅｂアプリケーション４１０から仲介装置１０３を介して送信されるレスポンスを受信する。
【００３７】
解析部４３２は、Ｗｅｂアプリケーション４１０から仲介装置１０３を介して受信したレスポンスを解析する。レスポンスにはＷｅｂブラウザー４３０が表示する操作画面の内容を示す記述であるＨＴＭＬデータが記載されている。
【００３８】
画面表示部４３３は、解析部４３２による解析結果に基づいて、サーバーが提供したＨＴＭＬデータを操作画面としてＵＩ表示装置２０７（図２）に画面表示する。
【００３９】
サービスプロバイダー部４４０において、通信部４４１は、仲介アプリケーション部４２０から処理依頼を受け付ける。処理依頼を受け付ける際に用いられるインタフェースとして、例えば、Ｗｅｂサービスインタフェースが用いられる。ジョブ生成部４４２は、通信部４４１で受け付けた処理依頼を受け取って、依頼された処理を実行するためのジョブを生成して当該ジョブを実行する。
【００４０】
図５は、図４に示す情報処理装置（ＭＦＰ）１０１、サーバー１０２、および仲介装置１０３における処理を説明するためのシーケンス図である。
【００４１】
図２〜図５を参照して、ここでは、ＭＦＰ１０１がリクエストを行って、仲介装置１０３が当該リクエストに係る処理を仲介してレスポンスとしてサーバー１０２に送信する例について説明する。
【００４２】
いま、ユーザーがＭＦＰ１０１においてＵＩ表示装置２０７から送信を行うためのハードウェアボタン（図示せず）を押下げると、Ｗｅｂブラウザー４３０が起動される。
【００４３】
Ｗｅｂブラウザー４３０は、ジョブ処理実行に係る設定画面を取得するため、サーバー１０２上のＷｅｂアプリケーション４１０に設定画面に係るリクエストを行う。図示の例では、メニュー画面（設定画面）のコンテンツを示すＵＲＬが予めＭＦＰ１０１に設定されている。
【００４４】
Ｗｅｂブラウザー４３０はＵＲＬで示されるコンテンツを保持するＷｅｂアプリケーション４１０に対して、ＨＴＴＰのＧＥＴコマンドによるリクエストを行う。具体的には、Ｗｅｂブラウザー４３０において、通信部４３１はＨＴＭＬデータ（ＵＲＬ）に応じてＨＴＴＰプロトコルによって仲介装置１０３の通信部４２１と通信を行う。そして、通信部４２１は、サーバー１０２の通信部４１３と通信を行う。
【００４５】
これによって、通信部４１３は受信したＵＲＬに応じてＷｅｂアプリケーション４１０にＨＴＭＬデータを渡す。この結果、Ｗｅｂブラウザー４３０からＷｅｂアプリケーション４１０に対するリクエストが行われることになる。なお、以下の説明では、通信部４３１、通信部４２１、および通信部４３１の動作（処理）について説明を省略する。
【００４６】
前述のように、Ｗｅｂブラウザー４３０から仲介アプリケーション４２０に対してリクエストが行われると（ステップＳ５０１）、仲介アプリケーション４２０はＷｅｂブラウザー４３０から受けたリクエストをＷｅｂアプリケーション４１０に転送する（ステップＳ５０２）。
【００４７】
Ｗｅｂアプリケーション４１０はリクエストの内容に応じた処理を行って、その処理結果をレスポンスとして仲介アプリケーション４２０に送る（ステップＳ５０３）。仲介アプリケーション４２０は、レスポンスを受けると後述する判断処理を行って、当該レスポンスをＷｅｂブラウザー４３０およびサービスプロバイダー部４４０の双方又はいずれか一方に送るか否かを決定する。
【００４８】
仲介アプリケーション４２０は、判断処理の結果に応じてＷｅｂブラウザー４３０およびサービスプロバイダー部４４０の双方又はいずれか一方に送る（ステップＳ５０４およびＳ５０５）。
【００４９】
Ｗｅｂブラウザー４３０はレスポンスを受けると、当該レスポンスが示す処理結果をＵＩ表示装置２０７（図２）に表示して処理を終了する。一方、サービスプロバイダー部４４０はレスポンスを受けると、レスポンスに応じた処理を行ってその結果を仲介アプリケーション４２０に送る（ステップＳ５０６）。そして、仲介アプリケーション４２０は、サービスプロバイダー部４４０から受信した処理結果をＷｅｂアプリケーション４１０に送って処理を終了する。
【００５０】
図６は、図４に示す仲介アプリケーション４２０においてＭＦＰ１０１（Ｗｅｂブラウザー４３０とサービスプロバイダー部４４０）とＷｅｂアプリケーション４１０とを仲介する処理を説明するためのフローチャートである。
【００５１】
なお以降の説明では、ＭＦＰ１０１がインターネット上のサーバー１０２（Ｗｅｂアプリケーション４１０）宛てに送信するメッセージのことを「ＨＴＴＰリクエストメッセージ」と呼ぶ。そして、サーバー１０２（Ｗｅｂアプリケーション４１０）がそのＨＴＴＰリクエストメッセージの応答として送信するメッセージのことを「ＨＴＴＰレスポンスメッセージ」と呼ぶ。Ｗｅｂブラウザー４３０は、ＨＴＴＰリクエストメッセージの中に、サーバー１０２が提供する操作画面のコンテンツを要求するコマンドや、その他にもＷｅｂアプリケーション４１０に各種の処理を実行するためのコマンドを含めて送信することができる。
【００５２】
一方、Ｗｅｂアプリケーション４１０は、ＨＴＴＰリクエストメッセージの応答であるＨＴＴＰレスポンスメッセージの中にＭＦＰ１０１に処理を要求するコマンドを含めることができる。例えば、ＭＦＰ１０１に対するスキャン処理を要求するコマンドやファイルを送信する処理を要求するコマンド等をＨＴＴＰレスポンスメッセージに含めて送信し、そのメッセージに含まれるコマンドに従って情報処理装置にジョブを実行させる。このような構成とすることで、ＭＦＰ１０１とサーバー１０２との間にファイアウォールが存在する場合でも、サーバー１０２が情報処理装置に対して処理を要求することができる。
【００５３】
図６及び図７のフローチャートは、ＭＦＰ１０１が備えるＷｅｂブラウザー４３０からＨＴＴＰリクエストメッセージを受信したことにより、処理が開始される。
【００５４】
図４および図６を参照して、いま、仲介アプリケーション４２０はＷｅｂブラウザー４３０からＷｅｂアプリケーション４１０宛てのＨＴＴＰリクエストメッセージを受信すると、当該ＨＴＴＰリクエストメッセージをＷｅｂアプリケーション４１０に転送する（ステップＳ６０１）。そして仲介アプリケーション４２０は、Ｗｅｂアプリケーション４１０からＨＴＴＰリクエストメッセージの応答としてＨＴＴＰレスポンスメッセージを受信する（ステップＳ６０２）。
【００５５】
ここで、Ｗｅｂアプリケーション４１０が仲介アプリケーション４２０に送信するＨＴＴＰレスポンスヘッダーについて図９を参照して説明する。図９は、Ｗｅｂアプリケーション４１０が仲介アプリケーション４２０に送信するＨＴＴＰレスポンスメッセージのヘッダー部の構成を示す図である。
【００５６】
図９に示すように、ＨＴＴＰレスポンスメッセージのヘッダー部９００は、宛先９０１（Ｘ−Ｗｅｂ Ｓｅｒｖｉｃｅ−Ａｄｄｒｅｓｓ）、タイムアウト時間９０２（Ｘ−Ｗｅｂ ｓｅｒｖｉｃｅ−Ｒｅｑｕｅｓｔ Ｔｉｍｅ ｏｕｔ）、およびコンテントタイプ９０３（Ｃｏｎｔｅｎｔ−Ｔｙｐｅ）を備えている。仲介アプリケーション４２０は、例えば、図５に示すステップＳ５０５において、宛先９０１に応じてＨＴＴＰレスポンスメッセージのボディー部に記述されたコマンドを送信する。送信するコマンドは、ここでは図示しないがＳＯＡＰ（Ｓｉｍｐｌｅ Ｏｂｊｅｃｔ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ）に従ったＸＭＬ形式のメッセージであり、サービスプロバイダー部４４０にスキャンやプリント、ファイル送信等のジョブを実行させるものである。
【００５７】
タイムアウト時間９０２は、例えば、仲介装置１０３がサービスプロバイダー部４４０と通信する際のタイムアウト時間であり、秒単位で示される。仲介装置１０３は、サービスプロバイダー部４４０と通信を行う際に時間を計測し、タイムアウト時間９０２で指定された時間が経過すると通信を停止し、仲介装置１０３はタイムアウトエラーレスポンスをＷｅｂアプリケーション４１０に送る。図６のフローチャートの説明に戻る。Ｓ６０２でＨＴＴＰレスポンスメッセージをＷｅｂアプリケーション４１０から受信すると、仲介アプリケーション４２０は、ＨＴＴＰレスポンスメッセージに含まれるヘッダー部のＣｏｎｔｅｎｔ−Ｔｙｐｅフィールド（コンテントタイプフィールド）８０３がａｐｐｌｉｃａｔｉｏｎ／ｖｎｄ．ｃａｎｏｎ．ｗｅｂｓｅｒｖｉｃｅであるか否かを判定する（ステップＳ６０３）。
【００５８】
Ｃｏｎｔｅｎｔ−Ｔｙｐｅフィールド８０３がａｐｐｌｉｃａｔｉｏｎ／ｖｎｄ．ｃａｎｏｎ．ｗｅｂｓｅｒｖｉｃｅでないと判定した場合には（ステップ６０３において、ＮＯ）、判定結果に応じて、仲介アプリケーション４２０はそのＨＴＴＰレスポンスメッセージをＷｅｂブラウザー４３０に送信し（ステップＳ６０４）、本フローチャートの処理を終了する。
【００５９】
一方Ｃｏｎｔｅｎｔ−ＴｙｐｅフィールドがＷｅｂサービスの呼び出しを要求する属性、すなわち、ａｐｐｌｉｃａｔｉｏｎ／ｖｎｄ．ｃａｎｏｎ．ｗｅｂｓｅｒｖｉｃｅであると判定した場合（ステップ６０３において、ＹＥＳ）、ステップＳ６０６に進む。ステップＳ６０６では、仲介アプリケーション４２０はＨＴＴＰレスポンスメッセージに含まれるＳＯＡＰのコマンドをサービスプロバイダー部４４０に送信してＷｅｂサービスを呼び出す（ステップＳ６０６）。一般に、クライアント／サーバシステムにおいては、ＨＴＴＰリクエストメッセージに対するＨＴＴＰレスポンスメッセージはリクエストを発行したクライアント（ここではＷｅｂブラウザー４３０）に返却される。ただしステップＳ６０６に処理を進めた場合には、Ｗｅｂブラウザー４３０が送信したＨＴＴＰリクエストメッセージの応答がＷｅｂブラウザー４３０ではなくサービスプロバイダー部４４０に送信される。そのため、Ｗｅｂブラウザー４３０はこの時点ではＨＴＴＰリクエストメッセージに対する応答の待ち状態となっている。
【００６０】
Ｓ６０６で仲介装置１０３（仲介アプリケーション４２０）がＳＯＡＰのコマンドをＭＦＰ１０１のサービスプロバイダー部４４０に送信すると、サービスプロバイダー部４４０ではその送信されたコマンドに従いジョブ生成部４４２でジョブ（スキャンジョブや送信ジョブなど）を生成し、ＷｅｂサービスとしてＭＦＰ１０１の処理手段に画像処理を実行させる。例えば、受け取ったコマンドがスキャンの要求である場合には画像読取機能により原稿を読み取って画像データを生成する。そして、ファイル送信の要求である場合には画像送信機能により指定宛先へ画像データを送信する。
【００６１】
図７は、図６のフローチャートの処理の続きを説明するためのフローチャートである。ここでは、サービスプロバイダー部４４０から仲介アプリケーション４２０経由で処理結果をＷｅｂアプリケーション４１０に送信した後、再度Ｗｅｂアプリケーション４１０から仲介装置１０３に処理依頼があったものとする。図示の例では、サービスプロバイダー部４４０に返却されるべきＨＴＴＰレスポンスメッセージについて、当該ＨＴＴＰレスポンスメッセージのヘッダー部におけるＣｏｎｔｅｎｔ−Ｔｙｐｅフィールドを解析して、その解析結果に応じてＨＴＴＰレスポンスメッセージをサービスプロバイダー部４４０及びＷｅｂブラウザー４３０のいずれに送信すべきかを決定する。
【００６２】
前述したように、ステップＳ６０６で仲介装置１０３（仲介アプリケーション４２０）がＷｅｂサービスを呼び出し、その結果サービスプロバイダー部４４０によりジョブが実行されると、その後、仲介アプリケーション４２０はサービスプロバイダー部４４０から処理結果（例えば、ジョブ処理結果）を取得する（ステップＳ８０１）。そして、仲介アプリケーション４２０は取得した処理結果を含むＨＴＴＰリクエストメッセージをＷｅｂアプリケーション４１０に送信する（ステップＳ８０２）。
【００６３】
続いて、仲介アプリケーション４２０は再度サーバー１０２（Ｗｅｂアプリケーション４１０）から処理に関する指示を含むＨＴＴＰレスポンスメッセージを受信する（ステップＳ８０３）。仲介アプリケーション４２０はステップＳ６０３の処理と同様にＨＴＴＰレスポンスメッセージのヘッダー部のＣｏｎｔｅｎｔ−Ｔｙｐｅフィールドを解析する。Ｃｏｎｔｅｎｔ−Ｔｙｐｅフィールドが再度サービスプロバイダー部４４０にＷｅｂサービスを要求する属性（ａｐｐｌｉｃａｔｉｏｎ／ｖｎｄ．ｃａｎｏｎ．ｗｅｂｓｅｒｖｉｃｅ）である場合には（ステップＳ８０４でＹＥＳ）ステップＳ８０７に進む。ステップＳ８０７では、Ｓ８０３で受信したＨＴＴＰリクエストメッセージに含まれるＳＯＡＰのコマンドを再度サービスプロバイダー部４４０に送信しＷｅｂサービスを呼び出す。一方Ｗｅｂサービスを要求する属性でなければ(ステップＳ８０４でＮＯ)、Ｗｅｂアプリケーション４１０からの指示はサービスプロバイダー部４４０への指示ではなくＷｅｂブラウザー４３０への指示と判断し、ステップＳ８０５に進む。ステップＳ８０５では、仲介アプリケーション４２０はＷｅｂブラウザー４３０にＨＴＴＰレスポンスメッセージを送信し（ステップＳ８０８）本フローチャートの処理を終了する。
【００６４】
以上、図６及び図７で説明したように、仲介アプリケーション４２０はコンテントタイプ９０３に応じて、ＨＴＴＰレスポンスメッセージのボディー部の内容がサービスプロバイダー部４４０に対する処理要求であるか又はＷｅｂブラウザー４３０で表示するＨＴＭＬコンテンツであるかを判定する。具体的には、ＨＴＴＰレスポンスメッセージのヘッダー部にＷｅｂサービスの要求を示す属性（ａｐｐｌｉｃａｔｉｏｎ／ｖｎｄ．ｃａｎｏｎ．ｗｅｂｓｅｒｖｉｃｅ）があるか否かを解析することで上記判定を行う。そして、Ｗｅｂサービスの要求を示す属性がある場合、そのＨＴＴＰレスポンスメッセージに含まれるＷｅｂサービスの要求を示すコマンドをサービスプロバイダー部４４０に送信する。
【００６５】
本実施形態では、Ｗｅｂブラウザー４３０が送信したＨＴＴＰリクエストメッセージの応答であるＨＴＴＰレスポンスメッセージにＷｅｂサービスを要求する属性を含む場合は、そのメッセージはＷｅｂブラウザー４３０で受信せず、仲介アプリケーション４２０がサービスプロバイダー部４４０へ転送するように構成した。そのため、Ｗｅｂブラウザーには特別な機能を拡張する必要がない。
【００６６】
以上のように、本実施の形態によれば、ＭＦＰなどの情報処理装置が備えるインタフェースに機能拡張などの変更が行われても、ＭＦＰが備えるモジュール（特にＷｅｂブラウザー）の変更を行う必要がない。つまり、情報処理装置においてジョブ処理を司るサービスプロバイダー部が拡張されても柔軟に対応することができる。そして、情報処理装置に呼び出しのためのアプリケーションを組み込むことなく、サーバーとは別に仲介装置を配置して、当該仲介装置で動作する仲介アプリケーションによって呼び出しを行うようにしたので、ユーザーに対する影響を少なくして、システムの拡張を行うことができる。
【００６７】
図８は、図４に示す仲介アプリケーション４２０がサービスプロバイダー部４４０のＷｅｂサービスを呼び出した際のタイムアウト処理を説明するためのフローチャートである。
【００６８】
図４および図７を参照して、図６で説明したように、Ｃｏｎｔｅｎｔ−Ｔｙｐｅフィールドがａｐｐｌｉｃａｔｉｏｎ／ｖｎｄ．ｃａｎｏｎ．ｗｅｂｓｅｒｖｉｃｅであると、仲介アプリケーション４２０はＨＴＴＰレスポンスメッセージに記載されたサービスプロバイダー部４４０に係るＷｅｂサービスを呼び出す。つまり、仲介アプリケーション４２０はサービスプロバイダー部４４０のインタフェースであるＷｅｂサービスを呼び出す（ステップＳ７０１）。そして、仲介アプリケーション４２０はＷｅｂサービス呼び出しを行った後、所定のタイムアウト時間の監視を開始する（ステップＳ７０２）。
【００６９】
仲介アプリケーション４２０はタイムアウト時間が経過したか否かをチェックする（ステップＳ７０３）。タイムアウト時間が経過しないと（ステップ７０３において、ＮＯ）、仲介アプリケーション４２０はサービスプロバイダー部４４０から処理結果を受信したか否かをチェックする（ステップＳ７０４）。
【００７０】
サービスプロバイダー部４４０から処理結果を受信しないと（ステップＳ７０４において、ＮＯ）、仲介アプリケーション４２０はステップＳ７０３の処理に戻る。一方、サービスプロバイダー部４４０から処理結果を受信すると（ステップＳ７０４において、ＹＥＳ）、仲介アプリケーション４２０は処理を終了する。
【００７１】
タイムアウト時間が経過すると（ステップ７０３において、ＹＥＳ）、仲介アプリケーション４２０はタイムアウトエラーと判定して、タイムアウトエラーレスポンスをＷｅｂアプリケーション４１０に通知する（ステップＳ７０５）。そして、仲介アプリケーション４２０は処理を終了する。
【００７２】
上述の説明から明らかなように、図４において、Ｗｅｂブラウザー４３０が表示制御手段として機能し、サービスプロバイダー部４４０がジョブ処理手段として機能する。また、仲介アプリケーション４２０が送受信手段、判定手段、および送信手段として機能する。加えて、仲介アプリケーション４２０はカウント手段および通知手段として機能する。
【００７３】
以上、本発明について実施の形態に基づいて説明したが、本発明は、これらの実施の形態に限定されるものではなく、この発明の要旨を逸脱しない範囲の様々な形態も本発明に含まれる。
【００７４】
例えば、上記の実施の形態の機能を制御方法として、この制御方法を、中継装置（仲介装置）に実行させるようにすればよい。また、上述の実施の形態の機能を有するプログラムを制御プログラムとして、この制御プログラムを中継装置が備えるコンピュータに実行させるようにしてもよい。なお、制御プログラムは、例えば、コンピュータに読み取り可能な記録媒体に記録される。
【００７５】
この際、制御方法および制御プログラムは、少なくとも送受信ステップ、判定ステップ、および送信ステップを有することになる。
【００７６】
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記録媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。
【符号の説明】
【００７７】
４１０ Ｗｅｂアプリケーション
４１１ プレゼンテーション部
４１２ ロジック部
４１３，４３１，４４１ 通信部
４３０ Ｗｅｂブラウザー
４３２ 解析部
４３２ 画面表示部
４４０ サービスプロバイダー部
４４２ ジョブ生成部
【技術分野】
【０００１】
本発明は、中継装置、その制御方法、および制御プログラムに関し、特に、外部装置から提供される操作画面を表示して当該操作画面による操作に応じた処理を行う情報処理装置と外部装置と情報処理装置とを仲介する中継装置に関する。
【背景技術】
【０００２】
従来、スキャナやプリンタ、ファクシミリ、ネットワーク送信装置などの各装置の機能を１つの筺体内に収納した画像処理装置が一般的に知られている。このような画像処理装置の操作部にＷｅｂブラウザーを用いる形態も一般的である。ここで、Ｗｅｂブラウザーで表示する操作画面で上述の各機能を利用する形態として特許文献１のような方法が知られている。
【０００３】
特許文献１によると、画像処理装置が備えているＷｅｂブラウザーは、ネットワーク上の外部装置から受信した画面情報（画面データ）に基づいて画像処理機能に関する操作画面を操作部に表示する。そして、その操作画面を用いてユーザーの操作を受けると、Ｗｅｂブラウザーは、ユーザーから受け付けた操作の内容を外部装置へ送信する。その後、画像処理装置は、外部装置からそのユーザーの操作に基づくＷｅｂサービスの要求を受信する。画像処理装置は、Ｗｅｂサービスの要求に応じて画像処理装置のスキャン機能又はプリント機能を実行する。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００６−２０３８６９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
Ｗｅｂブラウザーを備える情報処理装置と、ネットワーク上に存在する外部装置との間にファイアウォールが存在する場合がある。ファイアウォールは一般的に内部から外部への接続は許可するが外部から内部への接続は許可しない。そのため上述した従来の方法では、外部装置からのＷｅｂサービスの要求を受け付けることができない場合がある。
【０００６】
また、ネットワークアドレス変換装置（ＮＡＴ）によりＩＰアドレスとプライベートアドレスを相互に変換してアドレスを使用する環境にＭＦＰが存在する場合には、Ｗｅｂサービスを要求するＭＦＰをインターネット上の外部装置からは特定できない、という問題がある。
【０００７】
本発明は、上述のような課題にかんがみて、ＭＦＰと外部装置との間にファイアウォールが存在する場合や、ＭＦＰがアドレス変換を用いる環境に存在する場合でも、好適に外部装置からのＷｅｂサービスの要求をＭＦＰに処理させるための手段を提供することを目的とする。
【課題を解決するための手段】
【０００８】
上記目的を達成するため、本発明による中継装置は、外部装置とネットワークを介して接続され、前記外部装置から提供される操作画面の操作に応じてジョブ処理を実行する情報処理装置と前記外部装置とを仲介する中継装置であって、前記情報処理装置には、前記操作画面を表示部に表示する表示制御手段と、前記ジョブ処理を実行するジョブ処理手段とが備えられており、前記操作画面の操作に応じたリクエストを前記情報処理装置から受信して前記外部装置に送信し、前記リクエストに対するレスポンスを前記外部装置から受信する送受信手段と、前記レスポンスの内容に応じて前記レスポンスを前記表示制御手段および前記ジョブ処理手段のいずれに送信するかを判定する判定手段と、前記判定手段による判定結果に応じて前記レスポンスを前記表示制御手段および前記ジョブ処理手段のいずれに送信する送信手段とを有することを特徴とする。
【発明の効果】
【０００９】
本発明によれば、ネットワーク上に存在する外部装置との間にファイアウォールが存在する場合や、ＭＦＰがアドレス変換を用いる環境に存在する場合でも、外部装置から送信されたＷｅｂサービスの要求であってＷｅｂブラウザーでの操作に基づくＷｅｂサービスの要求を好適に処理することができる。
【図面の簡単な説明】
【００１０】
【図１】本発明の実施の形態による中継装置および情報処理装置が収容されたネットワークシステムの一例を示す図である。
【図２】図１に示す情報処理装置についてその構成の一例を示すブロック図である。
【図３】図１に示すサーバーおよび仲介装置のハードウェア構成の一例を示すブロック図である。
【図４】図４は、図１に示す情報処理装置、サーバー、および仲介装置のソフトウェア構成の一例を示す図である。
【図５】図４に示す情報処理装置（ＭＦＰ）、サーバー、および仲介装置における処理を説明するためのシーケンス図である。
【図６】仲介装置における処理を説明するためのフローチャートである。
【図７】仲介装置における処理を説明するためのフローチャートである。
【図８】仲介装置がＭＦＰのＷｅｂサービスを呼び出した際のタイムアウト処理を説明するためのフローチャートである。
【図９】図４に示すＷｅｂアプリケーションが仲介アプリケーションに送信するＨＴＴＰレスポンスヘッダーの構成を示す図である。
【発明を実施するための形態】
【００１１】
以下、本発明の実施の形態による中継装置の一例について図面を参照して説明する。
【００１２】
図１は、本発明の実施の形態による中継装置および情報処理装置が収容されたネットワークシステムの一例を示す図である。図示の例では、情報処理装置１０１と中継装置（以下仲介装置あるいはプロキシサーバとも呼ぶ）１０３がローカルエリアネットワーク（ＬＡＮ）１００を介して互いに通信可能に接続されている。またインターネット上にはサーバー（Ｗｅｂサーバー）１０２が存在する。
【００１３】
本実施形態では、図１には図示しないが、インターネットとＬＡＮ１００との間にはファイアウォール及びＮＡＴ（Ｎｅｔｗｏｒｋ Ａｄｄｒｅｓｓ Ｔｒａｎｓｌａｔｏｒ）が設けられている。ファイアウォールはインターネットからＬＡＮ１００内への不正アクセスを防止する機能を持っている。
【００１４】
またＮＡＴは、ＩＰアドレスとＬＡＮ１００内で使用するプライベートアドレスとを相互に変換するアドレス変換テーブルを持つ。このアドレス変換テーブルによるアドレス変換により、プライベートアドレスしか持たないＬＡＮ１００内の装置がインターネット上の外部装置に透過的にアクセスすることができる。
【００１５】
なお以降では、情報処理装置１０１の一例として画像形成（印刷）機能、画像読取機能、画像送信機能などの各種の画像処理機能を備えたＭＦＰ（Ｍｕｌｔｉｐｌｅ Ｆｕｎｃｔｉｏｎ Ｐｅｒｉｐｈｅｒａｌ）について説明する。
【００１６】
ＭＦＰ１０１は所謂Ｗｅｂブラウザー機能を有しており、サーバー１０２はＷｅｂコンテンツを、ネットワーク１００を介して配信する配信機能を有している。そして、サーバー１０２はＭＦＰ１０１からのリクエストに応じてＷｅｂコンテンツをＭＦＰ１０１に返送する。なお、ＭＦＰ１０１は通信を行うための複数のインタフェースを備えている。
【００１７】
ＭＦＰ１０１は、上述のブラウザー機能を用いてサーバー１０２にリクエストを送信する場合、必ず中継装置（仲介装置）１０３を介するよう設定されている。そのため、ＭＦＰ１０１のＷｅｂブラウザーで送信されたサーバー１０２へのリクエスト及びそのリクエストに対するレスポンスは、全て中継装置（仲介装置）１０３を介することになる。
【００１８】
仲介装置１０３は、サーバー１０２とＭＦＰ１０１との間の通信を仲介する。例えば、サーバー１０２からＭＦＰ１０１にリクエスト又はレスポンスを送信する際、仲介装置１０３はその通信内容を解析して、この解析結果に応じて、ＭＦＰ１０１が備える複数のインタフェースのいずれかを選択する処理を行う。さらに、仲介装置１０３はＭＦＰ１０１で実行された処理結果（ジョブ処理結果）をサーバー１０１に送る。
【００１９】
なお、本実施形態ではサーバー（Ｗｅｂサーバー）を外部装置の一例として説明するが、汎用のパーソナルコンピュータを外部装置として適用してもよいことはいうまでもない。
【００２０】
図２は、図１に示すＭＦＰ１０１についてその構成の一例を示すブロック図である。
【００２１】
図２において、ＭＦＰ１０１は、ＣＰＵ２０１を有しており、ＣＰＵ２０１はＭＦＰ１０１全体の制御を司る。さらに、ＭＦＰ１０１は、ＣＰＵ２０１のワークエリアとして用いられるＲＡＭ２０２、原稿から画像を読み取る読取装置２０３、および画像データに応じて印刷を行う印刷装置２０４を備えている。また、ＭＦＰ１０１は、記憶装置２０５、ユーザー入力装置２０６、ＵＩ（ユーザーインタフェース）表示装置２０７、およびネットワーク装置２０８を備えている。そして、これらＣＰＵ２０１、ＲＡＭ２０２、読取装置２０３、印刷装置２０４、記憶装置２０５、ユーザー入力装置２０６、ＵＩ表示装置２０７、およびネットワーク装置２０８はメインバス２００で相互に接続されている。
【００２２】
記憶装置２０５にはプログラムおよび各種設定情報が記憶され、例えば、ＨＤＤ又はＮＶＲＡＭ等が用いられる。ユーザー入力装置２０６はユーザーがコマンドの入力を行うためのものであり、ＵＩ表示装置２０７には各種画面表示が行われる。ネットワーク装置２０８は外部機器（例えば、サーバー１０２）とネットワーク１００を介して通信を行うためのものである。なお、図示の例では、ＣＰＵ２０１はメインバス２００を介してＲＡＭ２０２、読取装置２０３、印刷装置２０４、記憶装置２０５、ユーザー入力装置２０６、ＵＩ表示装置２０７、およびネットワーク装置２０８を制御する。また、タッチパネルディスプレイを用いてＵＩ表示装置２０７がユーザー入力装置２０６を兼ねるにしてもよい。
【００２３】
図３は、図１に示すサーバー１０２および仲介装置１０３のハードウェア構成の一例を示すブロック図である。
【００２４】
図３において、サーバー１０２は、ＣＰＵ３０１、ＲＡＭ３０２、記憶装置３０３、およびネットワーク装置３０４を有しており、これらはメインバス３００によって相互に接続されている。ＲＡＭ３０２はＣＰＵ３０１のワークエリアとして用いられ、記憶装置３０３にはプログラムおよび各種設定情報が記憶される。ネットワーク装置３０４はネットワーク１００を介してＭＦＰ１０１と通信を行う。
【００２５】
図示の例では、ＣＰＵ３０１はメインバス３００を介してＲＡＭ３０２、記憶装置３０３、およびネットワーク装置３０４を制御する。なお、仲介装置１０３はサーバー１０２と同様のハードウェア構成を有している。
【００２６】
図４は、図１に示すＭＦＰ１０１、サーバー１０２、および仲介装置１０３のソフトウェア構成の一例を示す図である。なお、図４に示すソフトウェア（制御プログラム）はＭＦＰ１０１のＣＰＵ２０１又はサーバー１０２および仲介装置１０３のＣＰＵ３０１で実行される。
【００２７】
図４において、サーバー１０２上ではＷｅｂアプリケーション４１０が動作する。そして、Ｗｅｂアプリケーション４１０は、プレゼンテーション部４１１、ロジック部４１２、および通信部４１３を備えている。
【００２８】
プレゼンテーション部４１１は、通信部４１３を介して、仲介装置１０３と通信を行って、情報処理装置（以下ＭＦＰとも呼ぶ）１０１からのリクエストに応答して、ＭＦＰ１０１に表示される操作画面又は処理要求を、ＭＦＰ１０１にレスポンスとして送信する。また、プレゼンテーション部４１１はＭＦＰ１０１に表示された操作画面を介して入力された入力情報を、通信部４１３を介してＭＦＰ１０１から受け取る。
【００２９】
ロジック部４１２は、プレゼンテーション部４１１から通知された上記の入力情報に対する処理を行う。例えば、ロジック部４１２は、入力情報に応じて、表示する画面を変更し、そして、ＭＦＰ１０１におけるデバイス機能実行のための処理要求を作成する。
【００３０】
通信部４１３は、ネットワーク装置３０４（図３）を制御してＨＴＴＰプロトコルにより通信を行うソフトウェアモジュールである。
【００３１】
仲介装置１０３は、仲介アプリケーション４２０を備えている。そして、この仲介アプリケーション４２０は、通信部４２１および処理部４２２を有している。通信部４２１はＭＦＰ１０１から送信されたリクエストを受け付ける。そして、通信部４２１は通信部４１３を介してプレゼンテーション部４１１およびロジック部４１２に当該リクエストを送信する。
【００３２】
また、通信部４２１はＷｅｂアプリケーション４１０から送られたレスポンスを受けると、当該レスポンスを処理部４２２に渡す。処理部４２２はこのレスポンスを解析して、解析結果に応じて後述するように通信部４２１を介してＭＦＰ１０１と通信を行う。
【００３３】
ＭＦＰ１０１は、Ｗｅｂブラウザー４３０およびサービスプロバイダー部４４０を有している。Ｗｅｂブラウザー４３０およびサービスプロバイダー部４４０の各々は、ＭＦＰ１０１のＣＰＵ２０１によって実行される。なお、Ｗｅｂブラウザー４３０は、サーバー１０２から送られたコンテンツを表示するものに限定するものではない。同様に、サーバー１０２および仲介装置１０３もＨＴＴＰプロトコルに従ってリクエスト／レスポンスを送受信する機器に限定するものではない。Ｗｅｂブラウザー４３０は、任意のサーバーと通信を行うことによってコンテンツを取得して、画面に表示するといった機能を有すればよい。
【００３４】
図示の例では、Ｗｅｂブラウザー４３０は、通信部４３１、解析部４３２、および画面表示部４３３を有している。通信部４３１は、ＨＴＴＰプロトコルに従って、通信部４２１を介して（つまり、仲介装置１０３を介して）、サーバー１０２と通信を行う。サービスプロバイダー部４４０は、通信部４４１およびジョブ生成部４４２を有している。通信部４４１は、ＨＴＴＰプロトコルに従って、通信部４２１を介してサーバー１０２と通信を行う。
【００３５】
つまり、ＭＦＰ１０１において、Ｗｅｂブラウザー４３０又はサービスプロバイダー部４４０がＷｅｂアプリケーション４１０からのレスポンスに対してリクエストを行う場合、通信部４２１が通信部４３１又は４４１からリクエストを受ける。そして、通信部４２１は通信部４１３を介してプレゼンテーション部４１１にリクエストを通知する。
【００３６】
例えば、通信部４３１は、Ｗｅｂブラウザー４３０で表示した操作画面を介して入力される情報（入力情報）を、仲介装置１０３を介してＷｅｂアプリケーション４１０に対するリクエストとして送信する。そして、通信部４３１は、Ｗｅｂアプリケーション４１０から仲介装置１０３を介して送信されるレスポンスを受信する。
【００３７】
解析部４３２は、Ｗｅｂアプリケーション４１０から仲介装置１０３を介して受信したレスポンスを解析する。レスポンスにはＷｅｂブラウザー４３０が表示する操作画面の内容を示す記述であるＨＴＭＬデータが記載されている。
【００３８】
画面表示部４３３は、解析部４３２による解析結果に基づいて、サーバーが提供したＨＴＭＬデータを操作画面としてＵＩ表示装置２０７（図２）に画面表示する。
【００３９】
サービスプロバイダー部４４０において、通信部４４１は、仲介アプリケーション部４２０から処理依頼を受け付ける。処理依頼を受け付ける際に用いられるインタフェースとして、例えば、Ｗｅｂサービスインタフェースが用いられる。ジョブ生成部４４２は、通信部４４１で受け付けた処理依頼を受け取って、依頼された処理を実行するためのジョブを生成して当該ジョブを実行する。
【００４０】
図５は、図４に示す情報処理装置（ＭＦＰ）１０１、サーバー１０２、および仲介装置１０３における処理を説明するためのシーケンス図である。
【００４１】
図２〜図５を参照して、ここでは、ＭＦＰ１０１がリクエストを行って、仲介装置１０３が当該リクエストに係る処理を仲介してレスポンスとしてサーバー１０２に送信する例について説明する。
【００４２】
いま、ユーザーがＭＦＰ１０１においてＵＩ表示装置２０７から送信を行うためのハードウェアボタン（図示せず）を押下げると、Ｗｅｂブラウザー４３０が起動される。
【００４３】
Ｗｅｂブラウザー４３０は、ジョブ処理実行に係る設定画面を取得するため、サーバー１０２上のＷｅｂアプリケーション４１０に設定画面に係るリクエストを行う。図示の例では、メニュー画面（設定画面）のコンテンツを示すＵＲＬが予めＭＦＰ１０１に設定されている。
【００４４】
Ｗｅｂブラウザー４３０はＵＲＬで示されるコンテンツを保持するＷｅｂアプリケーション４１０に対して、ＨＴＴＰのＧＥＴコマンドによるリクエストを行う。具体的には、Ｗｅｂブラウザー４３０において、通信部４３１はＨＴＭＬデータ（ＵＲＬ）に応じてＨＴＴＰプロトコルによって仲介装置１０３の通信部４２１と通信を行う。そして、通信部４２１は、サーバー１０２の通信部４１３と通信を行う。
【００４５】
これによって、通信部４１３は受信したＵＲＬに応じてＷｅｂアプリケーション４１０にＨＴＭＬデータを渡す。この結果、Ｗｅｂブラウザー４３０からＷｅｂアプリケーション４１０に対するリクエストが行われることになる。なお、以下の説明では、通信部４３１、通信部４２１、および通信部４３１の動作（処理）について説明を省略する。
【００４６】
前述のように、Ｗｅｂブラウザー４３０から仲介アプリケーション４２０に対してリクエストが行われると（ステップＳ５０１）、仲介アプリケーション４２０はＷｅｂブラウザー４３０から受けたリクエストをＷｅｂアプリケーション４１０に転送する（ステップＳ５０２）。
【００４７】
Ｗｅｂアプリケーション４１０はリクエストの内容に応じた処理を行って、その処理結果をレスポンスとして仲介アプリケーション４２０に送る（ステップＳ５０３）。仲介アプリケーション４２０は、レスポンスを受けると後述する判断処理を行って、当該レスポンスをＷｅｂブラウザー４３０およびサービスプロバイダー部４４０の双方又はいずれか一方に送るか否かを決定する。
【００４８】
仲介アプリケーション４２０は、判断処理の結果に応じてＷｅｂブラウザー４３０およびサービスプロバイダー部４４０の双方又はいずれか一方に送る（ステップＳ５０４およびＳ５０５）。
【００４９】
Ｗｅｂブラウザー４３０はレスポンスを受けると、当該レスポンスが示す処理結果をＵＩ表示装置２０７（図２）に表示して処理を終了する。一方、サービスプロバイダー部４４０はレスポンスを受けると、レスポンスに応じた処理を行ってその結果を仲介アプリケーション４２０に送る（ステップＳ５０６）。そして、仲介アプリケーション４２０は、サービスプロバイダー部４４０から受信した処理結果をＷｅｂアプリケーション４１０に送って処理を終了する。
【００５０】
図６は、図４に示す仲介アプリケーション４２０においてＭＦＰ１０１（Ｗｅｂブラウザー４３０とサービスプロバイダー部４４０）とＷｅｂアプリケーション４１０とを仲介する処理を説明するためのフローチャートである。
【００５１】
なお以降の説明では、ＭＦＰ１０１がインターネット上のサーバー１０２（Ｗｅｂアプリケーション４１０）宛てに送信するメッセージのことを「ＨＴＴＰリクエストメッセージ」と呼ぶ。そして、サーバー１０２（Ｗｅｂアプリケーション４１０）がそのＨＴＴＰリクエストメッセージの応答として送信するメッセージのことを「ＨＴＴＰレスポンスメッセージ」と呼ぶ。Ｗｅｂブラウザー４３０は、ＨＴＴＰリクエストメッセージの中に、サーバー１０２が提供する操作画面のコンテンツを要求するコマンドや、その他にもＷｅｂアプリケーション４１０に各種の処理を実行するためのコマンドを含めて送信することができる。
【００５２】
一方、Ｗｅｂアプリケーション４１０は、ＨＴＴＰリクエストメッセージの応答であるＨＴＴＰレスポンスメッセージの中にＭＦＰ１０１に処理を要求するコマンドを含めることができる。例えば、ＭＦＰ１０１に対するスキャン処理を要求するコマンドやファイルを送信する処理を要求するコマンド等をＨＴＴＰレスポンスメッセージに含めて送信し、そのメッセージに含まれるコマンドに従って情報処理装置にジョブを実行させる。このような構成とすることで、ＭＦＰ１０１とサーバー１０２との間にファイアウォールが存在する場合でも、サーバー１０２が情報処理装置に対して処理を要求することができる。
【００５３】
図６及び図７のフローチャートは、ＭＦＰ１０１が備えるＷｅｂブラウザー４３０からＨＴＴＰリクエストメッセージを受信したことにより、処理が開始される。
【００５４】
図４および図６を参照して、いま、仲介アプリケーション４２０はＷｅｂブラウザー４３０からＷｅｂアプリケーション４１０宛てのＨＴＴＰリクエストメッセージを受信すると、当該ＨＴＴＰリクエストメッセージをＷｅｂアプリケーション４１０に転送する（ステップＳ６０１）。そして仲介アプリケーション４２０は、Ｗｅｂアプリケーション４１０からＨＴＴＰリクエストメッセージの応答としてＨＴＴＰレスポンスメッセージを受信する（ステップＳ６０２）。
【００５５】
ここで、Ｗｅｂアプリケーション４１０が仲介アプリケーション４２０に送信するＨＴＴＰレスポンスヘッダーについて図９を参照して説明する。図９は、Ｗｅｂアプリケーション４１０が仲介アプリケーション４２０に送信するＨＴＴＰレスポンスメッセージのヘッダー部の構成を示す図である。
【００５６】
図９に示すように、ＨＴＴＰレスポンスメッセージのヘッダー部９００は、宛先９０１（Ｘ−Ｗｅｂ Ｓｅｒｖｉｃｅ−Ａｄｄｒｅｓｓ）、タイムアウト時間９０２（Ｘ−Ｗｅｂ ｓｅｒｖｉｃｅ−Ｒｅｑｕｅｓｔ Ｔｉｍｅ ｏｕｔ）、およびコンテントタイプ９０３（Ｃｏｎｔｅｎｔ−Ｔｙｐｅ）を備えている。仲介アプリケーション４２０は、例えば、図５に示すステップＳ５０５において、宛先９０１に応じてＨＴＴＰレスポンスメッセージのボディー部に記述されたコマンドを送信する。送信するコマンドは、ここでは図示しないがＳＯＡＰ（Ｓｉｍｐｌｅ Ｏｂｊｅｃｔ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ）に従ったＸＭＬ形式のメッセージであり、サービスプロバイダー部４４０にスキャンやプリント、ファイル送信等のジョブを実行させるものである。
【００５７】
タイムアウト時間９０２は、例えば、仲介装置１０３がサービスプロバイダー部４４０と通信する際のタイムアウト時間であり、秒単位で示される。仲介装置１０３は、サービスプロバイダー部４４０と通信を行う際に時間を計測し、タイムアウト時間９０２で指定された時間が経過すると通信を停止し、仲介装置１０３はタイムアウトエラーレスポンスをＷｅｂアプリケーション４１０に送る。図６のフローチャートの説明に戻る。Ｓ６０２でＨＴＴＰレスポンスメッセージをＷｅｂアプリケーション４１０から受信すると、仲介アプリケーション４２０は、ＨＴＴＰレスポンスメッセージに含まれるヘッダー部のＣｏｎｔｅｎｔ−Ｔｙｐｅフィールド（コンテントタイプフィールド）８０３がａｐｐｌｉｃａｔｉｏｎ／ｖｎｄ．ｃａｎｏｎ．ｗｅｂｓｅｒｖｉｃｅであるか否かを判定する（ステップＳ６０３）。
【００５８】
Ｃｏｎｔｅｎｔ−Ｔｙｐｅフィールド８０３がａｐｐｌｉｃａｔｉｏｎ／ｖｎｄ．ｃａｎｏｎ．ｗｅｂｓｅｒｖｉｃｅでないと判定した場合には（ステップ６０３において、ＮＯ）、判定結果に応じて、仲介アプリケーション４２０はそのＨＴＴＰレスポンスメッセージをＷｅｂブラウザー４３０に送信し（ステップＳ６０４）、本フローチャートの処理を終了する。
【００５９】
一方Ｃｏｎｔｅｎｔ−ＴｙｐｅフィールドがＷｅｂサービスの呼び出しを要求する属性、すなわち、ａｐｐｌｉｃａｔｉｏｎ／ｖｎｄ．ｃａｎｏｎ．ｗｅｂｓｅｒｖｉｃｅであると判定した場合（ステップ６０３において、ＹＥＳ）、ステップＳ６０６に進む。ステップＳ６０６では、仲介アプリケーション４２０はＨＴＴＰレスポンスメッセージに含まれるＳＯＡＰのコマンドをサービスプロバイダー部４４０に送信してＷｅｂサービスを呼び出す（ステップＳ６０６）。一般に、クライアント／サーバシステムにおいては、ＨＴＴＰリクエストメッセージに対するＨＴＴＰレスポンスメッセージはリクエストを発行したクライアント（ここではＷｅｂブラウザー４３０）に返却される。ただしステップＳ６０６に処理を進めた場合には、Ｗｅｂブラウザー４３０が送信したＨＴＴＰリクエストメッセージの応答がＷｅｂブラウザー４３０ではなくサービスプロバイダー部４４０に送信される。そのため、Ｗｅｂブラウザー４３０はこの時点ではＨＴＴＰリクエストメッセージに対する応答の待ち状態となっている。
【００６０】
Ｓ６０６で仲介装置１０３（仲介アプリケーション４２０）がＳＯＡＰのコマンドをＭＦＰ１０１のサービスプロバイダー部４４０に送信すると、サービスプロバイダー部４４０ではその送信されたコマンドに従いジョブ生成部４４２でジョブ（スキャンジョブや送信ジョブなど）を生成し、ＷｅｂサービスとしてＭＦＰ１０１の処理手段に画像処理を実行させる。例えば、受け取ったコマンドがスキャンの要求である場合には画像読取機能により原稿を読み取って画像データを生成する。そして、ファイル送信の要求である場合には画像送信機能により指定宛先へ画像データを送信する。
【００６１】
図７は、図６のフローチャートの処理の続きを説明するためのフローチャートである。ここでは、サービスプロバイダー部４４０から仲介アプリケーション４２０経由で処理結果をＷｅｂアプリケーション４１０に送信した後、再度Ｗｅｂアプリケーション４１０から仲介装置１０３に処理依頼があったものとする。図示の例では、サービスプロバイダー部４４０に返却されるべきＨＴＴＰレスポンスメッセージについて、当該ＨＴＴＰレスポンスメッセージのヘッダー部におけるＣｏｎｔｅｎｔ−Ｔｙｐｅフィールドを解析して、その解析結果に応じてＨＴＴＰレスポンスメッセージをサービスプロバイダー部４４０及びＷｅｂブラウザー４３０のいずれに送信すべきかを決定する。
【００６２】
前述したように、ステップＳ６０６で仲介装置１０３（仲介アプリケーション４２０）がＷｅｂサービスを呼び出し、その結果サービスプロバイダー部４４０によりジョブが実行されると、その後、仲介アプリケーション４２０はサービスプロバイダー部４４０から処理結果（例えば、ジョブ処理結果）を取得する（ステップＳ８０１）。そして、仲介アプリケーション４２０は取得した処理結果を含むＨＴＴＰリクエストメッセージをＷｅｂアプリケーション４１０に送信する（ステップＳ８０２）。
【００６３】
続いて、仲介アプリケーション４２０は再度サーバー１０２（Ｗｅｂアプリケーション４１０）から処理に関する指示を含むＨＴＴＰレスポンスメッセージを受信する（ステップＳ８０３）。仲介アプリケーション４２０はステップＳ６０３の処理と同様にＨＴＴＰレスポンスメッセージのヘッダー部のＣｏｎｔｅｎｔ−Ｔｙｐｅフィールドを解析する。Ｃｏｎｔｅｎｔ−Ｔｙｐｅフィールドが再度サービスプロバイダー部４４０にＷｅｂサービスを要求する属性（ａｐｐｌｉｃａｔｉｏｎ／ｖｎｄ．ｃａｎｏｎ．ｗｅｂｓｅｒｖｉｃｅ）である場合には（ステップＳ８０４でＹＥＳ）ステップＳ８０７に進む。ステップＳ８０７では、Ｓ８０３で受信したＨＴＴＰリクエストメッセージに含まれるＳＯＡＰのコマンドを再度サービスプロバイダー部４４０に送信しＷｅｂサービスを呼び出す。一方Ｗｅｂサービスを要求する属性でなければ(ステップＳ８０４でＮＯ)、Ｗｅｂアプリケーション４１０からの指示はサービスプロバイダー部４４０への指示ではなくＷｅｂブラウザー４３０への指示と判断し、ステップＳ８０５に進む。ステップＳ８０５では、仲介アプリケーション４２０はＷｅｂブラウザー４３０にＨＴＴＰレスポンスメッセージを送信し（ステップＳ８０８）本フローチャートの処理を終了する。
【００６４】
以上、図６及び図７で説明したように、仲介アプリケーション４２０はコンテントタイプ９０３に応じて、ＨＴＴＰレスポンスメッセージのボディー部の内容がサービスプロバイダー部４４０に対する処理要求であるか又はＷｅｂブラウザー４３０で表示するＨＴＭＬコンテンツであるかを判定する。具体的には、ＨＴＴＰレスポンスメッセージのヘッダー部にＷｅｂサービスの要求を示す属性（ａｐｐｌｉｃａｔｉｏｎ／ｖｎｄ．ｃａｎｏｎ．ｗｅｂｓｅｒｖｉｃｅ）があるか否かを解析することで上記判定を行う。そして、Ｗｅｂサービスの要求を示す属性がある場合、そのＨＴＴＰレスポンスメッセージに含まれるＷｅｂサービスの要求を示すコマンドをサービスプロバイダー部４４０に送信する。
【００６５】
本実施形態では、Ｗｅｂブラウザー４３０が送信したＨＴＴＰリクエストメッセージの応答であるＨＴＴＰレスポンスメッセージにＷｅｂサービスを要求する属性を含む場合は、そのメッセージはＷｅｂブラウザー４３０で受信せず、仲介アプリケーション４２０がサービスプロバイダー部４４０へ転送するように構成した。そのため、Ｗｅｂブラウザーには特別な機能を拡張する必要がない。
【００６６】
以上のように、本実施の形態によれば、ＭＦＰなどの情報処理装置が備えるインタフェースに機能拡張などの変更が行われても、ＭＦＰが備えるモジュール（特にＷｅｂブラウザー）の変更を行う必要がない。つまり、情報処理装置においてジョブ処理を司るサービスプロバイダー部が拡張されても柔軟に対応することができる。そして、情報処理装置に呼び出しのためのアプリケーションを組み込むことなく、サーバーとは別に仲介装置を配置して、当該仲介装置で動作する仲介アプリケーションによって呼び出しを行うようにしたので、ユーザーに対する影響を少なくして、システムの拡張を行うことができる。
【００６７】
図８は、図４に示す仲介アプリケーション４２０がサービスプロバイダー部４４０のＷｅｂサービスを呼び出した際のタイムアウト処理を説明するためのフローチャートである。
【００６８】
図４および図７を参照して、図６で説明したように、Ｃｏｎｔｅｎｔ−Ｔｙｐｅフィールドがａｐｐｌｉｃａｔｉｏｎ／ｖｎｄ．ｃａｎｏｎ．ｗｅｂｓｅｒｖｉｃｅであると、仲介アプリケーション４２０はＨＴＴＰレスポンスメッセージに記載されたサービスプロバイダー部４４０に係るＷｅｂサービスを呼び出す。つまり、仲介アプリケーション４２０はサービスプロバイダー部４４０のインタフェースであるＷｅｂサービスを呼び出す（ステップＳ７０１）。そして、仲介アプリケーション４２０はＷｅｂサービス呼び出しを行った後、所定のタイムアウト時間の監視を開始する（ステップＳ７０２）。
【００６９】
仲介アプリケーション４２０はタイムアウト時間が経過したか否かをチェックする（ステップＳ７０３）。タイムアウト時間が経過しないと（ステップ７０３において、ＮＯ）、仲介アプリケーション４２０はサービスプロバイダー部４４０から処理結果を受信したか否かをチェックする（ステップＳ７０４）。
【００７０】
サービスプロバイダー部４４０から処理結果を受信しないと（ステップＳ７０４において、ＮＯ）、仲介アプリケーション４２０はステップＳ７０３の処理に戻る。一方、サービスプロバイダー部４４０から処理結果を受信すると（ステップＳ７０４において、ＹＥＳ）、仲介アプリケーション４２０は処理を終了する。
【００７１】
タイムアウト時間が経過すると（ステップ７０３において、ＹＥＳ）、仲介アプリケーション４２０はタイムアウトエラーと判定して、タイムアウトエラーレスポンスをＷｅｂアプリケーション４１０に通知する（ステップＳ７０５）。そして、仲介アプリケーション４２０は処理を終了する。
【００７２】
上述の説明から明らかなように、図４において、Ｗｅｂブラウザー４３０が表示制御手段として機能し、サービスプロバイダー部４４０がジョブ処理手段として機能する。また、仲介アプリケーション４２０が送受信手段、判定手段、および送信手段として機能する。加えて、仲介アプリケーション４２０はカウント手段および通知手段として機能する。
【００７３】
以上、本発明について実施の形態に基づいて説明したが、本発明は、これらの実施の形態に限定されるものではなく、この発明の要旨を逸脱しない範囲の様々な形態も本発明に含まれる。
【００７４】
例えば、上記の実施の形態の機能を制御方法として、この制御方法を、中継装置（仲介装置）に実行させるようにすればよい。また、上述の実施の形態の機能を有するプログラムを制御プログラムとして、この制御プログラムを中継装置が備えるコンピュータに実行させるようにしてもよい。なお、制御プログラムは、例えば、コンピュータに読み取り可能な記録媒体に記録される。
【００７５】
この際、制御方法および制御プログラムは、少なくとも送受信ステップ、判定ステップ、および送信ステップを有することになる。
【００７６】
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記録媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。
【符号の説明】
【００７７】
４１０ Ｗｅｂアプリケーション
４１１ プレゼンテーション部
４１２ ロジック部
４１３，４３１，４４１ 通信部
４３０ Ｗｅｂブラウザー
４３２ 解析部
４３２ 画面表示部
４４０ サービスプロバイダー部
４４２ ジョブ生成部
【特許請求の範囲】
【請求項１】
外部装置とネットワークを介して接続され、前記外部装置から提供される操作画面の操作に応じてジョブ処理を実行する情報処理装置と前記外部装置とを仲介する中継装置であって、
前記情報処理装置には、前記操作画面を表示部に表示する表示制御手段と、前記ジョブ処理を実行するジョブ処理手段とが備えられており、
前記操作画面の操作に応じたリクエストを前記情報処理装置から受信して前記外部装置に送信し、前記リクエストに対するレスポンスを前記外部装置から受信する送受信手段と、
前記レスポンスの内容に応じて前記レスポンスを前記表示制御手段および前記ジョブ処理手段のいずれに送信するかを判定する判定手段と、
前記判定手段による判定結果に応じて前記レスポンスを前記表示制御手段および前記ジョブ処理手段のいずれかに送信する送信手段と、
を有することを特徴とする中継装置。
【請求項２】
前記判定手段による判定結果が前記レスポンスを前記ジョブ処理手段に送信することを示していると、前記送受信手段は前記ジョブ処理手段によるジョブ処理結果を示す通知を前記外部装置に送信することを特徴とする請求項１に記載の中継装置。
【請求項３】
前記レスポンスはＨＴＴＰプロトコルに応じたレスポンスであり、
前記レスポンスのヘッダーにおけるコンテントタイプフィールドに応じて、前記判定手段は前記レスポンスを前記表示制御手段および前記ジョブ処理手段の双方又はいずれに送信するかを判定することを特徴とする請求項１又は２に記載の中継装置。
【請求項４】
前記レスポンスを前記ジョブ処理手段に送信すると、カウントを開始するカウント手段と、
前記カウント手段によるカウントが所定のタイムアウト時間を経過すると、タイムアウトエラーを前記外部装置に通知する通知手段とを有することを特徴とする請求項２に記載の中継装置。
【請求項５】
外部装置にネットワークを介して接続され、前記外部装置から提供される操作画面を表示部に表示する表示制御手段と、前記操作画面の操作に応じてジョブ処理を実行するジョブ処理手段とを備える情報処理装置と前記外部装置とを仲介する中継装置の制御方法であって、
前記操作画面の操作に応じたリクエストを前記外部装置に送信し、前記リクエストに対するレスポンスを前記外部装置から受信する送受信ステップと、
前記レスポンスの内容に応じて前記レスポンスを前記表示制御手段および前記ジョブ処理手段のいずれに送信するかを判定する判定ステップと、
前記判定ステップによる判定結果に応じて前記レスポンスを前記表示制御手段および前記ジョブ処理手段のいずれかに送信する送信ステップと、
を有することを特徴とする制御方法。
【請求項６】
外部装置にネットワークを介して接続され、前記外部装置から提供される操作画面を表示部に表示する表示制御手段と、前記操作画面の操作に応じてジョブ処理を実行するジョブ処理手段とを備える情報処理装置と前記外部装置とを仲介する中継装置で用いられる制御プログラムであって、
前記中継装置が備えるコンピュータに、
前記操作画面の操作に応じたリクエストを前記外部装置に送信し、前記リクエストに対するレスポンスを前記外部装置から受信する送受信ステップと、
前記レスポンスの内容に応じて前記レスポンスを前記表示制御手段および前記ジョブ処理手段のいずれに送信するかを判定する判定ステップと、
前記判定ステップによる判定結果に応じて前記レスポンスを前記表示制御手段および前記ジョブ処理手段のいずれかに送信する送信ステップと、
を実行させることを特徴とする制御プログラム。
【請求項１】
外部装置とネットワークを介して接続され、前記外部装置から提供される操作画面の操作に応じてジョブ処理を実行する情報処理装置と前記外部装置とを仲介する中継装置であって、
前記情報処理装置には、前記操作画面を表示部に表示する表示制御手段と、前記ジョブ処理を実行するジョブ処理手段とが備えられており、
前記操作画面の操作に応じたリクエストを前記情報処理装置から受信して前記外部装置に送信し、前記リクエストに対するレスポンスを前記外部装置から受信する送受信手段と、
前記レスポンスの内容に応じて前記レスポンスを前記表示制御手段および前記ジョブ処理手段のいずれに送信するかを判定する判定手段と、
前記判定手段による判定結果に応じて前記レスポンスを前記表示制御手段および前記ジョブ処理手段のいずれかに送信する送信手段と、
を有することを特徴とする中継装置。
【請求項２】
前記判定手段による判定結果が前記レスポンスを前記ジョブ処理手段に送信することを示していると、前記送受信手段は前記ジョブ処理手段によるジョブ処理結果を示す通知を前記外部装置に送信することを特徴とする請求項１に記載の中継装置。
【請求項３】
前記レスポンスはＨＴＴＰプロトコルに応じたレスポンスであり、
前記レスポンスのヘッダーにおけるコンテントタイプフィールドに応じて、前記判定手段は前記レスポンスを前記表示制御手段および前記ジョブ処理手段の双方又はいずれに送信するかを判定することを特徴とする請求項１又は２に記載の中継装置。
【請求項４】
前記レスポンスを前記ジョブ処理手段に送信すると、カウントを開始するカウント手段と、
前記カウント手段によるカウントが所定のタイムアウト時間を経過すると、タイムアウトエラーを前記外部装置に通知する通知手段とを有することを特徴とする請求項２に記載の中継装置。
【請求項５】
外部装置にネットワークを介して接続され、前記外部装置から提供される操作画面を表示部に表示する表示制御手段と、前記操作画面の操作に応じてジョブ処理を実行するジョブ処理手段とを備える情報処理装置と前記外部装置とを仲介する中継装置の制御方法であって、
前記操作画面の操作に応じたリクエストを前記外部装置に送信し、前記リクエストに対するレスポンスを前記外部装置から受信する送受信ステップと、
前記レスポンスの内容に応じて前記レスポンスを前記表示制御手段および前記ジョブ処理手段のいずれに送信するかを判定する判定ステップと、
前記判定ステップによる判定結果に応じて前記レスポンスを前記表示制御手段および前記ジョブ処理手段のいずれかに送信する送信ステップと、
を有することを特徴とする制御方法。
【請求項６】
外部装置にネットワークを介して接続され、前記外部装置から提供される操作画面を表示部に表示する表示制御手段と、前記操作画面の操作に応じてジョブ処理を実行するジョブ処理手段とを備える情報処理装置と前記外部装置とを仲介する中継装置で用いられる制御プログラムであって、
前記中継装置が備えるコンピュータに、
前記操作画面の操作に応じたリクエストを前記外部装置に送信し、前記リクエストに対するレスポンスを前記外部装置から受信する送受信ステップと、
前記レスポンスの内容に応じて前記レスポンスを前記表示制御手段および前記ジョブ処理手段のいずれに送信するかを判定する判定ステップと、
前記判定ステップによる判定結果に応じて前記レスポンスを前記表示制御手段および前記ジョブ処理手段のいずれかに送信する送信ステップと、
を実行させることを特徴とする制御プログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【公開番号】特開２０１２−２４４４０５（Ｐ２０１２−２４４４０５Ａ）
【公開日】平成２４年１２月１０日（２０１２．１２．１０）
【国際特許分類】
【出願番号】特願２０１１−１１２４４８（Ｐ２０１１−１１２４４８）
【出願日】平成２３年５月１９日（２０１１．５．１９）
【出願人】（０００００１００７）キヤノン株式会社 (59,756)
【Ｆターム（参考）】
【公開日】平成２４年１２月１０日（２０１２．１２．１０）
【国際特許分類】
【出願日】平成２３年５月１９日（２０１１．５．１９）
【出願人】（０００００１００７）キヤノン株式会社 (59,756)
【Ｆターム（参考）】
[ Back to top ]