JP2005316991A - 仲介装置、通信システム、通信方法、プログラム及び記録媒体 - Google Patents

Abstract

【課題】 サーバにおいて動作要求に対応する処理に時間を要する場合でも、サーバからクライアントへの動作応答の転送のために必要な通信トラフィックを抑えながら、動作要求をタイムアウトさせずに済ませられるようにする。
【解決手段】 ファイアウォール１０４の内側に設けることで、そのファイアウォール１０４の外側に設けられるーバである管理装置１０２と、ファイアウォール１０４の内側に設けられる数のクライアントである被管理装置１０との間の通信を仲介する仲介装置１０１が、各被管理装置１０からのコマンドを受信して管理装置１０２に転送し、管理装置１０２にアクセスした際、管理装置１０２において、それまでに転送したいずれかのコマンドに対する応答が送信可能な状態になっていた場合に、その応答を受信し、その応答を、その応答と対応するコマンドの送信元に転送するようにした。
【選択図】 図１

Description

この発明は、サーバと複数のクライアントとの間の通信を仲介する仲介装置、このような仲介装置と上記サーバと上記複数のクライアントとを備える通信システム、このような仲介装置を用いた通信方法、コンピュータをこのような仲介装置として機能させるためのプログラム、およびこのようなプログラムを記録したコンピュータ読み取り可能な記録媒体に関する。

従来から、通信装置をネットワークを介して接続した通信システムにおいて、通信装置同士で互いにメッセージを交換させることにより、通信相手の装置に対して通知や要求を行わせることが行われている。そして、このようなシステムにおいて、ある装置から別の装置に動作要求としてコマンドを送信して動作を実行させ、送信相手から動作の実行結果を動作応答として返信させることも行われている。

このような技術は、例えば特許文献１に開示されており、この文献には、リモートプロセッサがローカルプロセッサに対して実行されるべきコマンドを指示するメッセージを送信し、そのコマンドに対する応答を受信することが記載されている。
また、この文献には、ローカルプロセッサがファイアウォールの内側に配置されている場合において、ローカルプロセッサからファイアウォールの外側のリモートプロセッサに通信要求を送信し、リモートプロセッサがこの通信要求に対する応答としてローカルプロセッサに対してコマンドを送信するようにすることにより、ファイアウォールの外側から内側に向けてコマンドを送信できるようにする技術も開示されている。
特開２００１−２７３２１１号公報

また、このような動作要求に関する技術は、通信装置に接続された装置の動作を遠隔制御するシステムにも適用することができる。特許文献２には、ブラインド及び照明を操作する機能を有する遠隔被操作装置に、ユーザからの操作を受け付ける機能を有する遠隔操作装置からコマンドを送信してブラインド及び照明を操作させる遠隔操作システムにこのような技術を適用した例が記載されている。ただし、この文献には、コマンドに対する応答を送信する点は示されていない。
特開２００２−１３５８５８号公報

ところで、クライアントがサーバに何らかの動作を要求する場合には、クライアントがサーバに対して動作要求としてコマンドを送信し、サーバから動作応答としてそのコマンドに対する応答を受信するようにすることが行われている。
しかし、このような処理を採用した場合、サーバにおいてコマンドに係る処理の実行に時間を要する場合に、処理が終了するまで何の応答も返さないとすると、クライアント側ではサーバがコマンドを正常に受信したか否かを判断できない。そして、一定期間応答がなかった場合には、コマンドをタイムアウトさせてエラー処理を行ってしまうことが一般的である。

そこで、コマンドのタイムアウトを防止するため、サーバの機能として、クライアントからのコマンドを受信した場合に直ちにその旨を示す受信通知を返し、その後、処理の終了後に改めて実行結果をクライアントに送信する機能を設ける方式を採ることが考えられる。しかし、通信にＨＴＴＰ（Hyper Text Transfer Protocol）のようなプロトコルを採用する場合、クライアントがファイアウォールの内側にあると、通常はサーバからクライアントに対して通信を要求することはできない。従って、実行結果をクライアントに送信するためには、クライアントにサーバに対する通信を要求させ、その通信要求に対する応答に実行結果を記載してクライアントに返すことになる。

このため、クライアントから見ると、コマンドの送信後、実行結果を取得するためには定期的にサーバに通信を要求してコネクションを確立する必要があり、また速やかに実行結果を取得したければ、それだけ頻繁にサーバに通信を要求する必要があることになる。従って、単純に動作要求を送信した際に応答としてその実行結果を受信するといった方式に比べ、通信要求の回数が増し、全体として通信トラフィックや処理負荷が増大することになるという問題があった。そして、クライアントの台数が多い場合には、この実行結果取得のための通信要求による通信トラフィックは無視できない量になる。

また現状では、ネットワークを介した通信をダイヤルアップ接続で行う環境もまだ多く残っており、このような環境においては通信要求の回数増加が特に問題となる。このような環境では、コネクションの確立に数十秒単位の時間を要することもあり、またコネクションを確立する毎に料金を課金されるので、コネクションを確立する回数が増加するとコストアップにつながるためである。

この発明は、このような問題を解決し、ファイアウォールの内側に設けられるクライアントがファイアウォールの外側にあるサーバに動作要求を送信してその動作要求に対する動作応答を受信する場合において、サーバにおいて動作要求に対応する処理に時間を要する場合でも、サーバからクライアントへの動作応答の転送のために必要な通信トラフィックを抑えながら、動作要求をタイムアウトさせずに済ませられるようにすることを目的とする。

上記の目的を達成するため、この発明の仲介装置は、ファイアウォールの内側に設けることで、そのファイアウォールの外側に設けられるサーバと、そのファイアウォールの内側に設けられる複数のクライアントとの間の通信を仲介する仲介装置において、上記各クライアントからの動作要求を受信して上記サーバに転送する転送手段と、上記サーバに問い合わせを送信した際、そのサーバにおいて、それまでに転送したいずれかの動作要求に対する動作応答が送信可能な状態になっていた場合に、その動作応答を受信する受信手段と、その手段が動作応答を受信した場合に、その動作応答を、その動作応答と対応する動作要求の送信元に転送する第２の転送手段とを設けたものである。

このような仲介装置において、上記受信手段を、上記サーバに問い合わせを送信した際、そのサーバにおいて、それまでに転送した複数の動作要求に対する動作応答がそれぞれ送信可能な状態になっていた場合に、それらの動作応答を複数一括して受信する手段とするとよい。
さらに、上記受信手段に、上記転送手段が上記サーバに動作要求を転送した後、そのサーバに転送した全ての動作要求に対する動作応答を受信するまで、定期的に上記サーバに上記問い合わせを送信する手段を設けるとよい。

さらに、上記受信手段に、定期的に上記サーバに上記問い合わせを送信する手段を設け、その手段を、上記転送手段が上記サーバに動作要求を転送した後、そのサーバに転送した全ての動作要求に対する動作応答を受信するまでは、それ以外の期間よりも短い間隔で上記サーバに上記問い合わせを送信する手段とするとよい。
また、上記の各仲介装置において、上記クライアントから動作要求を受信した場合に、そのクライアントに対して受信通知を送信する受信通知手段を設けるとよい。

また、この発明の通信システムは、ファイアウォールの外側に設けられるサーバと、そのファイアウォールの内側に設けられる複数のクライアントと、そのファイアウォールの内側に設けることで、上記サーバと上記複数のクライアントの間の通信を仲介する仲介装置とを備えた通信システムにおいて、上記仲介装置に、上記各クライアントからの動作要求を受信して上記サーバに転送する転送手段と、上記サーバに問い合わせを送信した際、そのサーバにおいて、それまでに転送したいずれかの動作要求に対する動作応答が送信可能な状態になっていた場合に、その動作応答を受信する受信手段と、その手段が動作応答を受信した場合に、その動作応答を、その動作応答と対応する動作要求の送信元に転送する第２の転送手段とを設け、上記各クライアントに、上記動作要求を上記仲介装置に送信する送信手段と、その送信した動作要求に対する動作応答を上記仲介装置から受信する受信手段とを設け、上記サーバに、上記クライアントからの動作要求を受信した場合に、その動作要求に係る動作を実行して動作応答を生成する手段と、上記仲介装置から上記問い合わせを受信した場合に、その仲介装置から受信したいずれかの動作要求に対する動作応答が送信可能な状態であれば、その動作応答をその仲介装置に送信する送信手段とを設けたものである。

このような通信システムにおいて、上記仲介装置の受信手段を、上記サーバに上記問い合わせを送信した際、そのサーバにおいて、それまでに転送した複数の動作要求に対する動作応答がそれぞれ送信可能な状態になっていた場合に、それらの動作応答を複数一括して受信する手段とし、上記サーバの送信手段を、上記仲介装置から上記問い合わせを受信した場合に、その仲介装置から受信した複数の動作要求に対する動作応答がそれぞれ送信可能な状態であれば、それらの動作応答をその仲介装置に複数一括して送信する手段とするとよい。
さらに、上記仲介装置において、上記受信手段に、上記転送手段が上記サーバに動作要求を転送した後、そのサーバに転送した全ての動作要求に対する動作応答を受信するまで、定期的に上記サーバに上記問い合わせを送信する手段を設けるとよい。

さらに、上記仲介装置の受信手段に、定期的に上記サーバに上記問い合わせを送信する手段を設け、その手段を、上記転送手段が上記サーバに動作要求を転送した後、そのサーバに転送した全ての動作要求に対する動作応答を受信するまでは、それ以外の期間よりも短い間隔で上記サーバに上記問い合わせを送信する手段とするとよい。
また、上記の各通信システムにおいて、上記仲介装置に、上記クライアントから動作要求を受信した場合に、そのクライアントに対して受信通知を送信する受信通知手段を設け、上記各クライアントに、その受信通知を受信する手段を設けるとよい。

また、この発明の通信方法は、ファイアウォールの外側に設けられるサーバと、そのファイアウォールの内側に設けられる複数のクライアントとの間の通信を、そのファイアウォールの内側に設ける仲介装置によって仲介して行う通信方法において、上記仲介装置に、上記各クライアントからの動作要求を受信して上記サーバに転送する転送手順と、上記サーバに問い合わせを送信した際、そのサーバにおいて、それまでに転送したいずれかの動作要求に対する動作応答が送信可能な状態になっていた場合に、その動作応答を受信する受信手順と、その手順で動作応答を受信した場合に、その動作応答を、その動作応答と対応する動作要求の送信元に転送する第２の転送手順とを実行させるようにしたものである。

このような通信方法において、上記仲介装置に実行させる受信手順を、上記サーバに上記問い合わせを送信した際、そのサーバにおいて、それまでに転送した複数の動作要求に対する動作応答がそれぞれ送信可能な状態になっていた場合に、それらの動作応答を複数一括して受信する手順とするとよい。
さらに、上記仲介装置に、上記受信手順において、上記転送手順で上記サーバに動作要求を転送した後、そのサーバに転送した全ての動作要求に対する動作応答を受信するまで、定期的に上記サーバに上記問い合わせを送信する手順を実行させるようにするとよい。

さらに、上記仲介装置に、上記受信手順において、定期的に上記サーバに上記問い合わせを送信する手順を実行させ、その手順を、上記転送手順で上記サーバに動作要求を転送した後、そのサーバに転送した全ての動作要求に対する動作応答を受信するまでは、それ以外の期間よりも短い間隔で上記サーバに上記問い合わせを送信する手順とするとよい。
また、上記の各通信方法において、上記仲介装置に、さらに、上記クライアントから動作要求を受信した場合に、そのクライアントに対して受信通知を送信する受信通知手順を実行させるようにするとよい。

また、この発明のプログラムは、ファイアウォールの内側に設けることで、そのファイアウォールの外側に設けられるサーバと、そのファイアウォールの内側に設けられる複数のクライアントとの間の通信を仲介する仲介装置を制御するコンピュータを、上記各クライアントからの動作要求を受信して上記サーバに転送する転送手段と、上記サーバに問い合わせを送信した際、そのサーバにおいて、それまでに転送したいずれかの動作要求に対する動作応答が送信可能な状態になっていた場合に、その動作応答を受信する受信手段と、その手段が動作応答を受信した場合に、その動作応答を、その動作応答と対応する動作要求の送信元に転送する第２の転送手段として機能させるためのプログラムである。

このようなプログラムにおいて、上記受信手段の機能を、上記サーバに上記問い合わせを送信した際、そのサーバにおいて、それまでに転送した複数の動作要求に対する動作応答がそれぞれ送信可能な状態になっていた場合に、それらの動作応答を複数一括して受信する機能とするとよい。
さらに、上記受信手段に、上記転送手段が上記サーバに動作要求を転送した後、そのサーバに転送した全ての動作要求に対する動作応答を受信するまで、定期的に上記サーバに上記問い合わせを送信する機能を設けるとよい。

さらに、上記受信手段に、定期的に上記サーバに上記問い合わせを送信する機能を設け、その機能を、上記転送手段が上記サーバに動作要求を転送した後、そのサーバに転送した全ての動作要求に対する動作応答を受信するまでは、それ以外の期間よりも短い間隔で上記サーバに上記問い合わせを送信する機能とするとよい。
また、上記の各プログラムにおいて、上記コンピュータを、上記クライアントから動作要求を受信した場合に、そのクライアントに対して受信通知を送信する受信通知手段として機能させるためのプログラムを更に含めるとよい。

また、この発明の記録媒体は、上記のいずれかのプログラムを記録したコンピュータ読み取り可能な記録媒体である。

以上のようなこの発明の仲介装置、通信システム、又は通信方法によれば、ファイアウォールの内側に設けられるクライアントがファイアウォールの外側にあるサーバに動作要求を送信してその動作要求に対する動作応答を受信する場合において、サーバにおいて動作要求に対応する処理に時間を要する場合でも、サーバからクライアントへの動作応答の転送のために必要な通信トラフィックを抑えながら、動作要求をタイムアウトさせずに済ませられるようにすることができる。
また、この発明のプログラムによれば、コンピュータを上記の仲介装置として機能させてその特徴を実現し、同様な効果を得ることができる。この発明の記録媒体によれば、上記のプログラムを記憶していないコンピュータにそのプログラムを読み出させて実行させ、上記の効果を得ることができる。

以下、この発明を実施するための最良の形態について、図面を参照して説明する。
〔実施形態：図１，図２〕
まず、この発明の仲介装置及びその仲介装置を用いて構成した通信システムの第１の実施形態について説明する。図１は、その通信システムの構成を示すブロック図である。
図１に示すように、この通信システムは、第１の通信装置である管理装置１０２と、第２の通信装置である複数の被管理装置１０と、これらの間の通信を仲介する仲介装置１０１及び被管理仲介装置１０１を備える。そして、このうち仲介装置１０１，被管理仲介装置１１０及び被管理装置１０をユーザ側の設置環境に配置し、これらと管理装置１０２とがインターネット１０３を介して通信可能な構成としている。そして、管理装置１０２が各被管理装置１０と通信を行って各被管理装置１０を集中的に遠隔管理する遠隔管理システムを構成している。

なお、被管理装置１０としては、種々の電子装置に通信機能を設けた通信装置が考えられ、例えば、プリンタ，ＦＡＸ装置，デジタル複写機，スキャナ装置，デジタル複合機等の画像処理装置や、ネットワーク家電，自動販売機，医療機器，電源装置，空調システム，ガス・水道・電気等の計量システム，自動車，航空機等に通信機能を持たせた通信装置が考えられる。
ところで、この通信システムにおいて、各設置環境内の仲介装置１０１と被管理装置１０および被管理仲介装置１１０は、互いにＬＡＮ（ローカルエリアネットワーク）によって接続し、これを介して通信可能としている。そして、セキュリティ面を考慮し、ファイアウォール１０４を介してＬＡＮをインターネット１０３に接続している。

ここで、ファイアウォール１０４は、通常は外部からの通信要求を遮断するよう設定されているため、管理装置１０２は、ＨＴＴＰ（Hyper Text Transfer Protocol）リクエストのような通信要求を送信するだけではファイアウォール１０４の内側の被管理装置１０に情報を送信することができない。従って、管理装置１０２と被管理装置１０とが情報を授受するためには、特殊なプロトコルを採用する必要があるが、各被管理装置１０をこのプロトコルに対応させるためには、手間やコストがかかる。そこで、被管理装置１０には一般的な通信プロトコルを採用してＬＡＮ内での（ファイアウォールを挟まない）通信のみに対応させる一方、上記の特殊なプロトコルに対応した仲介装置１０１を設け、管理装置１０２と被管理装置１０の間の通信を仲介させることにより、特殊なプロトコルに対応していない被管理装置１０と管理装置１０２との間での情報の授受を可能としている。
また、仲介装置１０１に通信を仲介させることにより、被管理装置１０が個々に管理装置１０２と通信を行う場合に比べて、通信トラフィックを低減できるようにしている。

なお、仲介装置１０１と被管理装置１０との接続は、ＬＡＮに限らず、ＲＳ−４８５規格等に準拠したシリアル接続や、ＳＣＳＩ（Small Computer System Interface）規格等に準拠したパラレル接続等によって行ってもよい。例えばＲＳ−４８５規格の場合には、仲介装置１０１に直列に５台までの被管理装置１０を接続することができる。
また、これらの仲介装置１０１、被管理装置１０及び被管理仲介装置１１０は、その利用環境に応じて多様な階層構造を成す。

例えば、図１に示す設置環境Ａでは、管理装置１０２とＨＴＴＰによる直接的なコネクションを確立できる仲介装置１０１ａが、被管理装置１０ａ及び１０ｂを従える単純な階層構造になっているが、同図に示す設置環境Ｂでは、４台の被管理装置１０を設置するため、１台の仲介装置１０１を設置しただけでは負荷が大きくなる。そのため、管理装置１０２とＨＴＴＰによる直接的なコネクションを確立できる仲介装置１０１ｂが、被管理装置１０ｃ及び１０ｄだけでなく、他の仲介装置として被管理仲介装置１１０を従え、この被管理仲介装置１１０が被管理装置１０ｅ及び１０ｆを更に従えるという階層構造を形成している。この場合、被管理装置１０ｅ及び１０ｆを遠隔管理するために管理装置１０２から発せられた情報は、仲介装置１０１ｂとその下位のノードである被管理仲介装置１１０とを経由して、被管理装置１０ｅ又は１０ｆに到達することになる。

また、このような通信システムにおいて、仲介装置１０１は、これに接続された被管理装置１０の制御管理のためのアプリケーションプログラムを実装している。管理装置１０２は、各仲介装置１０１の制御管理、更にはこの仲介装置１０１を介した被管理装置１０及び被管理仲介装置１１０の制御管理を行うためのアプリケーションプログラムを実装している。そして、被管理装置１０も含め、この遠隔管理システムにおけるこれら各ノードは、ＲＰＣ（remote procedure call）により、相互の実装するアプリケーションプログラムのメソッドに対する処理の依頼である「動作要求」を送信し、この依頼された処理の結果である「動作応答」を取得することができるようになっている。

即ち、管理装置１０２は、被管理装置１０や仲介装置１０１への動作要求（以下、管理装置側動作要求という）を生成してこれを被管理装置１０や仲介装置１０１へ引き渡し、この動作要求に対する動作応答を取得できる一方で、被管理装置１０は、仲介装置１０１や管理装置１０２への動作要求（以下、被管理装置側要求という）を生成してこれを仲介装置１０１や管理装置１０２へ引き渡し、この動作要求に対する動作応答を取得できるようになっている。また、仲介装置１０１も、被管理装置１０や管理装置１０２への動作要求（以下、仲介装置側要求という）を生成してこれを被管理装置１０や管理装置１０２へ引き渡し、この動作要求に対する動作応答を取得できるようになっている。

なお、ここではメソッドを、入力と出力の形式を規定した論理的な関数として定義するものとする。そしてこの場合、動作要求はこの関数を呼び出す関数呼び出し（Procedure Call）となり、動作応答はその関数呼び出しによって呼び出された関数の実行結果となる。動作要求による要求の内容には、意味のある実行結果を伴わない通知も含まれる。

図２に、これらの動作要求と動作応答の関係の一部を示す。なお、この図においてはファイアウォール１０４の存在は考慮していない。
図２（Ａ）は、被管理装置１０で管理装置１０２に対する動作要求が発生したケースである。このケースでは、被管理装置１０が被管理装置側動作要求ａを生成し、これを仲介装置１０１を経由して受け取った管理装置１０２がこの動作要求に対する動作応答ａを返すというモデルになる。また、図に示す仲介装置１０１が複数であるケースも想定できる（例えば被管理装置が図１に示した被管理装置１０ｅ又は１０ｆの場合）。なお、被管理装置側動作要求ａは、管理装置１０２に送信される動作要求であるから、管理装置「宛て」の動作要求と言うことができる。

また、図２（Ａ）では、動作応答ａだけでなく遅延通知ａ′を返信するケースも表記している。これは管理装置１０２が、接続してきた仲介装置１０１から被管理装置側動作要求ａを受け取って、これとの接続中にその動作要求に対する応答を返せないと判断したときには、応答が遅延する旨を通知して一旦接続状態を切断し、後の接続の際に上記動作要求に対する応答を改めて引き渡す構成とすることが考えられるためである。なお、このシステムにおいては、被管理装置１０に遅延通知を処理する機能を設けなくてよいようにするため、遅延通知は被管理装置１０に転送せずに仲介装置１０１で管理しておき、仲介装置１０１が管理装置１０２から応答ａを受信した時点で被管理装置１０にその応答を転送するようにしている。また、被管理装置１０に遅延通知を処理する機能を設けるのであれば、被管理装置１０に遅延通知をするように転送してもよい。

図２（Ｂ）は、被管理装置１０で仲介装置１０１に対する動作要求が発生したケースである。このケースでは、被管理装置１０が、例えば、被管理装置側動作要求ｂを生成し、これを受け取った仲介装置１０１が、その動作要求に対する動作応答ｂを返すというモデルになる。なお、図２（Ｂ）のケースでは、遅延通知は返さない。

図２（Ｃ）は、仲介装置１０１で、管理装置１０２に対する動作要求が発生したケースである。このケースでは、仲介装置１０１が仲介装置側動作要求ｃを生成し、これを受け取った管理装置１０２が、その動作要求に対する動作応答ｃを返すというモデルになる。この（Ｃ）のケースでも、（Ａ）の場合と同様、管理装置１０２は、応答を即座に返せない時は遅延通知ｃ′を返すようにすることが考えられる。

図２（Ｄ）は、仲介装置１０１で被管理装置１０に対する動作要求が発生したケースである。このケースでは、仲介装置１０１が仲介装置側動作要求ｄを生成し、これを受け取った被管理装置１０が、その動作要求に対する動作応答ｄを返すというモデルになる。なお、ここで被管理装置１０が使用している一般的な通信プロトコルは、遅延通知を返す機能を有していないので、被管理装置１０は遅延通知は返さない。
なお、管理装置１０２からの仲介装置１０１や被管理装置１０宛ての動作要求についても、上記の場合と同様に動作要求を受け取った装置がその動作要求に対して応答を返す。しかし、この実施形態は、ファイアウォール１０４の内側の被管理装置１０や仲介装置１０１の側からファイアウォール１０４の外側の管理装置１０２の側への動作要求及びその動作要求に対する応答の転送の方式に特徴を有するため、管理装置１０２側からの動作要求については、ここでは図示を省略する。

また、ここではＲＰＣによる引数並びに戻り値の受け渡しのプロトコルとしてＳＯＡＰ（Simple Object Access Protocol）を採用し、上記の動作要求や動作応答は、ここではＳＯＡＰメッセージとして記載するようにしている。
そして、実際に動作要求や動作応答を転送するための通信プロトコルとしては、システムの構成に合わせて適当なものを採用することができ、例えばＨＴＴＰ（HyperText Transfer Protocol）やＳＭＴＰ（Simple Mail Transfer Protocol）を採用することができるが、ここでは、通信プロトコルにＨＴＴＰを採用する場合について説明する。

〔第１の実施例：図３乃至図４１〕
ここで、図１に示した通信システムのより具体的な実施例として、サーバである管理装置によってそれぞれクライアントである複数の画像処理装置の遠隔管理を行い、これらの装置間の通信をこの発明の仲介装置によって仲介する遠隔管理システムについて説明する。図３は、その遠隔管理システムの構成の一例を示す概念図であるが、被管理装置１０を画像処理装置１００に変更した点が図１と相違するのみであるので、システムの全体構成についての説明は省略する。
画像処理装置１００は、コピー、ファクシミリ、スキャナ等の機能及び外部装置と通信を行う機能を備えたデジタル複合機であり、それらの機能に係るサービスを提供するためのアプリケーションプログラムを実装しているものである。

また、図１に示した通信システムの場合と同様に、仲介装置１０１は、これに接続された画像処理装置１００の制御管理のためのアプリケーションプログラムを実装している。管理装置１０２は、各仲介装置１０１の制御管理、更にはこの仲介装置１０１を介した画像処理装置１００及び被管理仲介装置１１０の制御管理を行うためのアプリケーションプログラムを実装している。そして、ＲＰＣ（remote procedure call）により、相互の実装するアプリケーションプログラムのメソッドに対する処理の依頼である「動作要求」を送信し、この依頼された処理の結果である「動作応答」を取得することができるようになっている。

図４に、これらの動作要求と動作応答の関係を示す。なお、この図においてもファイアウォール１０４の存在は考慮していない。
図４（Ａ）は、画像処理装置１００で管理装置１０２に対する動作要求が発生したケースである。このケースでは、画像処理装置１００が画像処理装置側動作要求ａ（以下、「画像機器コマンド」とも呼ぶ）を生成し、これを仲介装置１０１を経由して受け取った管理装置１０２がこのコマンドに対する動作応答ａ（以下、「コマンド応答」あるいは単に「応答」とも呼ぶ）を返すというモデルになる。また、図に示す仲介装置１０１が複数であるケースも想定できる。なお、応答を即座に返せないときに遅延通知ａ′を返信するようにしてもよいことは、図２（Ａ）のケースと同様である。

図４（Ｂ）は、画像処理装置１００で仲介装置１０１に対する動作要求が発生したケースである。このケースでは、画像処理装置１００が、例えば、画像処理装置側動作要求（画像機器コマンド）ｂを生成し、これを受け取った仲介装置１０１が、その動作要求に対する動作応答ｂを返すというモデルになる。仲介装置１０１が遅延通知は返さないことは、図２（Ｂ）のケースと同様である。

図４（Ｃ）は、仲介装置１０１で、管理装置１０２に対する動作要求が発生したケースである。このケースでは、仲介装置１０１が仲介装置側動作要求ｃ（以下、「仲介装置コマンド」とも呼ぶ）を生成し、これを受け取った管理装置１０２が、その動作要求に対する動作応答ｃを返すというモデルになる。なお、応答を即座に返せないときに遅延通知ｃ′を返信するようにしてもよいことは、図２（Ａ）のケースと同様である。

図４（Ｄ）は、仲介装置１０１で画像処理装置１００に対する動作要求が発生したケースである。このケースでは、仲介装置１０１が仲介装置側動作要求（仲介装置コマンド）ｄを生成し、これを受け取った画像処理装置１００が、その動作要求に対する動作応答ｄを返すというモデルになる。なお、画像処理装置１００が遅延通知は返さないことは、図２（Ｄ）のケースと同様である。
以下、このようなコマンド及びコマンド応答を転送する際の通信シーケンスについて説明する。

まず、図５に画像処理装置と仲介装置との間の通信シーケンスの例を示す。
この図に示すように、画像処理装置１００と仲介装置１０１とは、通信要求であるＨＴＴＰリクエストと、その通信要求に対する通信応答であるＨＴＴＰレスポンスとを、互いに送受信することによって通信を行っている。そして、画像処理装置１００と仲介装置１０１との間にはファイアウォールがないため、画像処理装置１００と仲介装置１０１のどちらがＨＴＴＰリクエストを送信しても（通信サーバとして機能しても）通信を行うことができる。例えば、画像処理装置１００が送信したＨＴＴＰリクエストＸに対して仲介装置１０１がＨＴＴＰレスポンスＸを返すこともできるし、仲介装置１０１が送信したＨＴＴＰリクエストＷに対して画像処理装置１００がＨＴＴＰレスポンスＷを返すこともできるという具合である。

そして、画像処理装置１００は、仲介装置１０１あるいは管理装置１０２に対するコマンドを、ＨＴＴＰリクエストに記載して仲介装置１０１に送信する（ＨＴＴＰリクエストＸ，Ｙ）。そして、仲介装置１０１は、受信したコマンドが自身に対するものであれば、コマンドに応じた処理を行い、コマンド受信時のＨＴＴＰリクエストに対するＨＴＴＰレスポンスに応答を記載して画像処理装置１００に送信する（ＨＴＴＰレスポンスＸ）。

また、仲介装置１０１は、受信したコマンドが管理装置１０２に対するものであれば、コマンドを管理装置１０２に転送し、管理装置１０２から応答を受信して、その応答を画像処理装置１００に送信する。ただし、この場合には管理装置１０２においてコマンドに応じた処理に時間がかかったり、ただちに応答を取得できなかったりする場合がある。そして、このような場合にも応答をコマンド受信時のＨＴＴＰリクエストに対するＨＴＴＰレスポンスに記載して送信するとすると、画像処理装置１００においてＨＴＴＰリクエストがタイムアウトしてしまい、結果としてコマンドに対する応答を受信できなくなってしまう場合がある。

そこで、ここでは、図５（ｂ）に示すようなシーケンスを採用し、仲介装置１０１は、管理装置１０２に対するコマンド（自身で処理せずに転送するコマンド）を受信した場合には、コマンド受信時のＨＴＴＰリクエストに対するＨＴＴＰレスポンスに受付通知を記載して画像処理装置１００に送信するようにしている（ＨＴＴＰレスポンスＹ）。そして、管理装置１０２からコマンドに対する応答を受信した時点で、その応答の内容を通知する結果通知をＨＴＴＰリクエストに記載して画像処理装置１００に送信するようにしている（ＨＴＴＰリクエストＺ）。また、画像処理装置１００は、このＨＴＴＰリクエストに対応するＨＴＴＰレスポンスに、結果通知の受信通知を記載して仲介装置１０１に返すようにしている。

このようにすることにより、画像機器コマンドに対する応答を受信通知という形で速やかに返すことが可能になり、画像処理装置１００におけるＨＴＴＰリクエストのタイムアウトを防止することができる。
なお、仲介装置１０１から画像処理装置１００に対する結果通知は、図５（ｃ）に示すようなシーケンスで転送される仲介装置１０１から画像処理装置１００に対するコマンドの１種として構成することができる。
また、画像処理装置１００から仲介装置１０１に対する画像機器コマンドについても、上述の受付通知及び結果通知を用いるようにしてもよい。

次に、図６に仲介装置と管理装置との間の通信シーケンスの例を示す。
仲介装置１０１と管理装置１０２との間には、ファイアウォール１０４があるため、この図に示すように、通信は常に、仲介装置１０１から通信要求としてＨＴＴＰリクエストを管理装置１０２に送信し、管理装置１０２からこの通信要求に対する通信応答としてＨＴＴＰレスポンスを仲介装置１０１に返すという手順で行われる。例えば仲介装置１０１が送信したＨＴＴＰリクエストＭに対して管理装置１０２がＨＴＴＰレスポンスＭを返し、同じくＨＴＴＰリクエストＮに対してＨＴＴＰレスポンスＮを返すという具合である。

仲介装置１０１は、画像処理装置１００から受信した画像機器コマンドのうち、自身で処理せず転送するコマンドを、ＨＴＴＰリクエストに記載して管理装置１０２に転送するようにしている（ＨＴＴＰリクエストＭ，Ｎ）。
一方、管理装置１０２は、受信したコマンドに対する応答がすぐに生成できる場合には、図６（ａ）に示すように、コマンド受信時のＨＴＴＰリクエストに対するＨＴＴＰレスポンスに応答を記載して仲介装置１０１に送信するようにしてもよい（ＨＴＴＰレスポンスＭ）。
しかし、処理に時間がかかることがある場合には、仲介装置１０１においてＨＴＴＰリクエストがタイムアウトしてしまう場合があるので、（ｂ）に示すように、コマンド受信時のＨＴＴＰリクエストに対するＨＴＴＰレスポンスに受付通知を記載して仲介装置１０１に送信するようにしている（ＨＴＴＰレスポンスＮ）。

そしてこの場合、仲介装置１０１は定期的に結果問い合わせのコマンドを記載したＨＴＴＰリクエストを管理装置１０２に送信するようにしている（ＨＴＴＰリクエストＯ，Ｐ）。そして、管理装置１０２は、受信したコマンドに対する処理が完了していなければ、結果問い合わせに対する応答として未完了通知を、対応するＨＴＴＰレスポンスに記載して仲介装置１０１に送信する（ＨＴＴＰレスポンスＯ）。また、処理が完了していれば、処理が完了したコマンドに対する応答を、結果問い合わせに対する応答として、結果問い合わせが記載されていたＨＴＴＰリクエストに対応するＨＴＴＰレスポンスに記載して仲介装置１０１に送信する（ＨＴＴＰレスポンスＰ）。
なお、管理装置１０２が遅延通知を送信する場合には、上記受付通知あるいは未完了通知に代えて遅延通知を記載してもよい。

また、図７に、仲介装置と管理装置との間の別の通信シーケンスの例を示す。
この図に示すように、仲介装置１０１は、送信したコマンドに対する応答を管理装置１０２から受信する前に、他のコマンド（初めのコマンドとは別の画像処理装置が生成したものでもよい）を管理装置１０２に送信することができる（ＨＴＴＰリクエストＱ，Ｒ）。そして、管理装置１０２は、このそれぞれに対して受付通知を返す（ＨＴＴＰレスポンスＱ，Ｒ）。
しかし、このような場合、管理装置１０２は、仲介装置１０１からの結果問い合わせに対し、必ずしも先に受信したコマンドに対する応答を先に返すわけではなく、結果問い合わせがあった時点で応答が返信可能になっているもののいずれかを返すようにしている。この結果、図７に示したように、後から受信した画像機器コマンドＣに対する応答を、画像機器コマンドＢに対する応答よりも先に返すようになることもある。
なお、結果問い合わせがあった時点で返信可能な応答が複数あった場合には、先に受信したコマンドに対する応答を先に返信するようにするとよい。

以上のような通信シーケンスを採用することにより、管理装置１０２が仲介装置１０１から受信したコマンドの実行結果をすぐに用意できない場合でも、仲介装置１０１に対してコマンドに対する応答を転送することができる。
また、このようにして管理装置１０２からコマンドの実行結果を受信するためには、管理装置１０２に対して定期的に通信要求を行う（ここでは結果問い合わせコマンドを記載したＨＴＴＰリクエストの送信が該当する）必要がある。しかし、仲介装置１０１がこの定期的な通信要求を取りまとめて行うことができるので、複数の画像処理装置１００がばらばらに行う場合に比べて通信要求の回数を低減し、管理装置１０２から仲介装置１０１への動作応答の転送のために必要な通信トラフィックを抑えられるようにすることができる。また、画像処理装置１００には、このような定期的な通信要求を行う機能を設ける必要がないので、画像処理装置１００の構成を単純化でき、設計や開発のコストを低減することができる。

次に、図８乃至図１０を用いて、図３に示した管理装置、画像処理装置、仲介装置のハードウェア構成について説明する。
まず、図８のブロック図に管理装置のハードウェア構成の概略を示す。
この管理装置１０２は、モデム１２１，通信端末１２２，外部接続Ｉ／Ｆ１２３，操作者端末１２４，データベース１２５，制御装置１２６等からなる。
モデム１２１は、公衆回線を介して機器利用者側（例えば画像処理装置を利用しているユーザ先）の仲介装置１０１との通信を司るものであり、送受信するデータを変復調する。このモデム１２１と通信端末１２２により通信手段としての機能を果たす。

通信端末１２２は、公衆回線を介してラインアダプタや仲介装置１０１とのデータの送受信を行う。
外部接続Ｉ／Ｆ１２３は、インターネット１０３を介して機器利用者側の仲介装置１０１とのデータの送受信及びセキュリティ管理を行う。この外部接続Ｉ／Ｆ１２３も、通信手段としての機能を果たす。また、セキュリティ管理のためのプロキシサーバ等を設けてもよい。

操作者端末１２４は、管理センタのオペレータが操作する端末であり、各種データの入力をオペレータによるキーボード等の入力装置上の操作により受け付けたり、オペレータに通知すべき情報を表示部に表示したりする。入力されるデータとしては、例えば、各機器利用者側の仲介装置１０１が管理装置１０２へ通信する際に使用するＩＰアドレスや発呼先電話番号等の顧客情報がある。
データベース１２５は、図示しないデータベースサーバのハードディスク装置等の記憶装置に存在し、画像処理装置１００のＩＰアドレスや電話番号、それらの装置から受信した異常情報等のデータ、操作者端末１２４から入力されたデータ等の各種データを記憶する。

制御装置１２６は、図示しないＣＰＵ，ＲＯＭ，ＲＡＭ等からなるマイクロコンピュータを備えており、管理装置１０２全体を統括的に制御する。そのＣＰＵが、ＲＯＭ等に記憶している制御プログラムを必要に応じて実行すると共に、モデム１２１，通信端末１２２，外部接続Ｉ／Ｆ１２３，操作者端末１２４またはデータベース１２５を利用することにより、各種の機能を実現することができる。
なお、管理装置１０２の構成はこれに限られることはなく、例えば１台のＰＣを用いて構成することもできる。

次に、図９に画像処理装置のハードウェア構成を示す。
画像処理装置１００はここでは、プリンタ、ファクシミリ（ＦＡＸ）装置、デジタル複写機、スキャナ装置、文書管理装置等の機能を備えたデジタル複合機として構成しており、図９に示すように、ＣＰＵ２０１，ＡＳＩＣ（Application Specific Integrated Circuit）２０２，ＳＤＲＡＭ２０３，フラッシュメモリ（不揮発性メモリ）２０４，ＮＲＳ用メモリ２０５，ＰＨＹ（物理メディアインタフェース）２０６，ＮＶＲＡＭ（不揮発性メモリ）２０７，操作部２０９，ＨＤＤ（ハードディスクドライブ）２１０，モデム２１１，ＰＩ（パーソナルインタフェース）２１２，ＦＣＵ（ファックスコントロールユニット）２１３，ＵＳＢ（Universal Serial Bus）２１４，ＩＥＥＥ（Institute of Electrical and Electronic Engineers）１３９４＿２１５，エンジンインタフェース（Ｉ／Ｆ）２１６，およびエンジン部２１７を備えている。これらの構成が、画像読み取り、画像形成、画情報送信等の画像処理を行うためのハードウェア資源である。

ＣＰＵ２０１は、ＡＳＩＣ２０２を介してデータ処理（各機能の制御）を行う演算処理手段である。
ＡＳＩＣ２０２は、ＣＰＵインターフェース，ＳＤＲＡＭインターフェース，ローカルバスインタフェース，ＰＣＩインタフェース，ＭＡＣ（Media Access Controller）、ＨＤＤインタフェースなどからなる多機能デバイスボードであり、ＣＰＵ２０１の制御対象となるデバイスの共有化を図り、アーキテクチャの面からアプリ（アプリケーションソフト）や共通システムサービスの開発の高効率化を支援するものである。
また、このＡＳＩＣ２０２には各エンジン部の操作命令等を受け付けるオペレーションパネル等による操作部２０９が直接的に接続されると共に、ＰＨＹ２０６も直接的に接続される。また、ＦＣＵ２１３やＵＳＢ２１４，ＩＥＥＥ１３９４＿２１５及びエンジンＩ／Ｆ２１６がＰＣＩバス２１８を介して接続され、必要に応じてモデム２１１やＰＩ２１２等が直接接続される。

そして、上記のＣＰＵ２０１は、このＡＳＩＣ２０２を介してフラッシュメモリ２０４やＨＤＤ２１０等の記憶手段から必要な制御プログラムを読み出し、ＳＤＲＡＭ２０３等に展開して実行することにより、情報の処理を行う処理手段として機能することができる。
ＳＤＲＡＭ２０３は、ＯＳを含む各種プログラムを記憶するプログラムメモリや、ＣＰＵ２０１がデータ処理を行う際に使用するワークメモリ等として使用するメインメモリである。なお、このＳＤＲＡＭ２０３の代わりに、ＤＲＡＭやＳＲＡＭを使用してもよい。

フラッシュメモリ２０４は、例えば、画像処理装置１００を起動させるブートローダ（ブートプログラム）やＯＳのファイルであるＯＳイメージ及び後述する種々のプログラムを記憶するプログラムメモリ、種々の固定パラメータを記憶する固定パラメータメモリ等として使用する不揮発性メモリ（記憶手段）であり、電源がオフになっても記憶内容を保持するようになっている。なお、このフラッシュメモリ２０４の代わりに、ＲＡＭと電池を利用したバックアップ回路を集積した不揮発性ＲＡＭや、ＥＥＰＲＯＭ等の他の不揮発性メモリを使用してもよい。

ＮＲＳ用メモリ２０５は、後述するＮＲＳアプリを記憶する不揮発性メモリであり、オプションでＮＲＳ機能を追加することができる。
ＰＨＹ２０６は、ＬＡＮを介して外部装置と通信を行うためのインタフェースである。
ＮＶＲＡＭ２０７は、例えば、この画像処理装置１００の識別情報である機種機番を記憶する機種機番メモリ、操作部２０９による操作上の初期値を記憶するメモリ、各アプリ（ＡＰＬ）の初期値を記憶するメモリ、各カウンタ情報（課金カウンタのデータ）を記憶するメモリ、自身や通信相手の設定状況、ネットワークアドレス情報、プロトコル等の機種情報を記憶するメモリ等として使用する不揮発性メモリ（記憶手段）であり、電源がオフになっても記憶内容を保持するようになっている。なお、このＮＶＲＡＭ２０７として、ＲＡＭと電池を利用したバックアップ回路を集積した不揮発性ＲＡＭや、ＥＥＰＲＯＭ，フラッシュメモリ等の不揮発性メモリを使用することができる。

操作部２０９は、操作表示手段（操作手段および表示手段）である。
ＨＤＤ２１０は、電源のオン・オフに関係なくデータを記憶保存する記憶手段（記録媒体）である。このＨＤＤ２１０に、上述したフラッシュメモリ２０４内のプログラムやそれ以外のデータ、あるいはＮＶＲＡＭ２０７内のデータを記憶しておくこともできる。また、定期的に収集、更新、送信等の処理を行う対象となるデータも、このＨＤＤ２１０に記憶させておくとよい。
モデム２１１は、変復調手段であり、管理装置１０２へ公衆回線経由でデータを送信する場合、そのデータを公衆回線に流せる形に変調する。また、管理装置１０２から送られてくる変調されたデータを受信した場合、そのデータを復調する。

ＰＩ２１２は、ＲＳ４８５規格に準拠したインタフェースを備え、図示しないラインアダプタを介して公衆回線に接続している。
ＦＣＵ２１３は、ＦＡＸ装置又はモデム機能（ＦＡＸ通信機能）を有するデジタル複写機やデジタル複合機等の画像処理装置および管理装置１０２等の外部装置との通信を公衆回線経由で制御する。
ＵＳＢ２１４及びＩＥＥＥ１３９４＿２１５はそれぞれ、周辺機器と通信を行うための、ＵＳＢ規格及びＩＥＥＥ１３９４規格のインタフェースである。
エンジンＩ／Ｆ２１６は、エンジン部２１７をＰＣＩバスに接続するためのインタフェースである。
エンジン部２１７は、公知のスキャナエンジン及びプロッタエンジン等からなる画像読み取り／形成用のエンジンや、プロッタエンジンによって画像を形成した用紙に、ソート、穴開け、ステープル処理等の後処理を行う後処理ユニット等が該当する。

このような画像処理装置１００において、電源投入（電源オン）時には、ＣＰＵ２０１は、ＡＳＩＣ２０２経由でフラッシュメモリ２０４内のブートローダを起動させ、そのブートローダに従い、フラッシュメモリ２０４内のＯＳイメージを読み出し、それをＳＤＲＡＭ２０３にロードして使用可能なＯＳに展開する。そして、ＯＳの展開が完了すると、そのＯＳを起動させる。その後、必要に応じてフラッシュメモリ２０４内のアプリ等のプログラムあるいはＮＲＳ用メモリ２０５内のＮＲＳアプリを読み出し、それをＳＤＲＡＭ２０３にロードして展開し、起動させることにより、各種機能を実現することができる。

次に、図１０に仲介装置のハードウェア構成を示す。
仲介装置１０１は、図１０に示すように、ＣＰＵ５２，ＳＤＲＡＭ５３，フラッシュメモリ５４（不揮発性メモリ），ＲＴＣ（内部時計であるリアルタイムクロック回路）５５，Ｏｐ−Ｐｏｒｔ（操作部接続ポート）５６，ＰＨＹ５７，モデム５８，ＨＤＤ制御部５９，拡張Ｉ／Ｆ６０，ＲＳ２３２Ｉ／Ｆ（インタフェース）６１，ＲＳ４８５Ｉ／Ｆ６２，ＨＤＤ６３等を備えている。

そして、ＣＰＵ５２は、フラッシュメモリ５４やＨＤＤ６３等の記憶手段から必要な制御プログラムを読み出し、ＳＤＲＡＭ５３等に展開して実行することにより、仲介装置１０１全体を制御し、この発明による機能（記憶手段，収集手段，分配手段，個別送信手段，個別受信手段，一括送信手段，一括受信手段，その他の手段としての機能）を実現することができる。
ＳＤＲＡＭ５３は、ＯＳを含む各種プログラムを記憶するプログラムメモリや、ＣＰＵ５２がデータ処理を行う際に使用するワークメモリ等として使用するメインメモリである。

フラッシュメモリ５４は、例えば、仲介装置１０１を起動させるブートローダ（ブートプログラム）やＯＳのファイルであるＯＳイメージ及び後述する種々のプログラムを記憶するプログラムメモリ、種々の固定パラメータを記憶する固定パラメータメモリ等として使用する不揮発性メモリ（記憶手段）であり、電源がオフになっても記憶内容を保持するようになっている。ＨＤＤ６３にも同様なデータを記憶させることができる。
ＲＴＣ５５は計時のための回路であり、Ｏｐ−Ｐｏｒｔ５６は図示しない操作部における操作を検出する回路である。
また、ＰＨＹ５７，モデム５８，ＲＳ４８５Ｉ／Ｆ６２は、それぞれＬＡＮ，公衆回線，ＲＳ４８５規格のシリアル通信によって通信を行うためのインタフェースである。
拡張Ｉ／Ｆ６０は、無線ＬＡＮボードや拡張メモリ等の拡張ボードを接続するためのＩ／Ｆである。

そして、この仲介装置１０１はＰＨＹ５７を介してネットワーク上の画像処理装置１００や被管理仲介装置１１０と接続され、またインターネット１０３に接続されている。また、画像処理装置１００とは、ＲＳ２３２Ｉ／Ｆ６１およびＲＳ４８５Ｉ／Ｆ６２を介しても接続可能である。なお、ＳＤＲＡＭ５３の代わりに、ＤＲＡＭやＳＲＡＭを使用してもよい。また、フラッシュメモリ５４の代わりに、ＥＥＰＲＯＭ等の他の不揮発性メモリを使用してもよい。

次に、図１１乃至図３４を用いて、以上のようなハードウェア構成を有する管理装置１０２、画像処理装置１００及び仲介装置１０１における、上述したような通信シーケンスを実現するための機能やその機能を実現するための処理について説明する。以下の説明においても、主として画像処理装置１００あるいは仲介装置１０１から管理装置１０２に対してのコマンド及びそのコマンドに対するコマンド応答について説明し、管理装置１０２側からのコマンドについては、説明を省略するか簡単にする。

まず、図１１に、仲介装置１０１の機能のうち、コマンド及びコマンド応答に関する処理を行うための機能の構成を示す機能ブロック図を示す。図１１に示す各機能は、ＣＰＵ５２が所要の制御プログラムを実行して仲介装置１０１の各部の動作を制御することにより実現されるものである。
また、図１１に示す機能のうち、ＨＴＴＰサーバ機能部４１及びＨＴＴＰクライアント機能部４５の機能は、ＣＰＵ５２及びＰＨＹ５７によって実現されるものである。コマンド分配機能部４２，アクションハンドラ群４３，コマンド転送ハンドラ４４の機能は、ＣＰＵ５２によって実現されるものである。

これらの機能についてさらに詳述する。
まず、ＨＴＴＰサーバ機能部４１は、ＨＴＴＰリクエストを受信するＨＴＴＰリクエスト受信機能部４１ａとＨＴＴＰレスポンスを送信するＨＴＴＰレスポンス送信機能部４１ｂとを備える。
そして、ＨＴＴＰリクエスト受信機能部４１ａは、画像処理装置１００が送信してくるＨＴＴＰリクエストを受信し、これをコマンド分配機能部４２に渡す機能を有する（Ａ１，Ａ２）。また、ＨＴＴＰレスポンス送信機能部４１ｂは、コマンド分配機能部４２から渡されるメッセージ、すなわち画像機器コマンドに対する応答や受付通知等に係るＳＯＡＰレスポンスを、ＨＴＴＰレスポンスに記載し、受信したＨＴＴＰリクエストに対する応答として画像処理装置１００に送信する機能も有する（Ａ５，Ａ６）。

また、コマンド分配機能部４２は、ＨＴＴＰリクエスト受信機能部４１ａが受信したＨＴＴＰリクエスト中のＳＯＡＰリクエストに記載されているコマンドの種類あるいは分類を解析する機能を有する。そして、その結果に応じて、自身で処理すべきコマンドであればＳＯＡＰリクエストをアクションハンドラ群４３の適当なアクションハンドラ４３ａに渡し、自身で処理すべきコマンドでなければ、管理装置１０２に転送するため、ＳＯＡＰリクエストをコマンド転送ハンドラ４４に渡す機能も有する（Ａ３）。

さらに、アクションハンドラ４３ａが返してくるコマンド実行結果や、コマンド転送ハンドラ４４が管理装置１０２に転送すべきコマンドを受け取った場合に返してくる受信通知（Ａ４）から、コマンドに対する応答や受信通知に係るＳＯＡＰレスポンスを生成し、ＨＴＴＰレスポンス送信機能部４１ｂに渡してこれを画像処理装置１００に送信させる機能も有する。また、アクションハンドラ４３ａが生成した仲介装置コマンドを、画像処理装置１００や管理装置１０２に転送させるためにコマンド転送ハンドラ４４に渡す機能も有する。
また、ここでは図示していないが、ＳＯＡＰリクエスト以外のメッセージが記載されたＨＴＴＰリクエストについても、その内容を解釈し、適当な処理手段に要求を伝えたり、ＨＴＴＰレスポンス送信機能部４１ｂに応答を返させたりする機能も有する。

また、アクションハンドラ群４３は、複数のアクションハンドラ４３ａ及びコマンド転送ハンドラ４４を有する。そして、各アクションハンドラ４３ａは、概ねコマンドの種類に対応して用意されており、画像処理装置１００から受信したコマンドに応じた処理を実行してその結果を返す機能や、画像処理装置１００や管理装置１０２に対するコマンドを生成し、そのコマンドに対する応答を受け取ってその応答に応じた処理を行う機能を有する。前者の機能を有するアクションハンドラ４３ａは、ウェブサービスの機能を提供するためのハンドラであると言うことができる。また、コマンドや応答の送受信は、コマンド分配機能部４２を介して行うようにしており、ここでは管理装置１０２側からのコマンドの取扱いについては図示を省略しているが、アクションハンドラ群４３には、管理装置１０２からのコマンドに応じて処理を実行してその結果を返すアクションハンドラも含まれる。

コマンド転送ハンドラ４４は、アクションハンドラ群４３に属するハンドラのうち、コマンドの転送に係る機能を担う特殊なハンドラである。そして、コマンド分配機能部４２から管理装置１０２に転送すべき画像機器コマンドを受け取ると、コマンド分配機能部４２に受付通知を返した上で（Ａ４）、その画像機器コマンドに係るＳＯＡＰリクエストを生成し、ＨＴＴＰクライアント機能部４５のＨＴＴＰリクエスト送信機能部４５ａに渡して管理装置１０２に送信させる機能を有する（Ｂ１）。また、ＨＴＴＰレスポンス受信機能部４５ｂから受け取る、管理装置１０２からの受信通知や未完了通知、あるいはコマンドに対する応答等に応じて、管理装置１０２に転送したコマンドの状態を管理し、転送したコマンドに対する応答が得られるまで定期的に結果問い合わせに係るＳＯＡＰリクエストを生成し、ＨＴＴＰリクエスト送信機能部４５ａに渡して管理装置１０２に送信させる機能も有する。

さらに、管理装置１０２から画像機器コマンドに対する応答を（ＨＴＴＰレスポンス受信機能部４５ｂを介して）受信した場合に（Ｂ４）、結果通知に係るＳＯＡＰリクエストを生成し、ＨＴＴＰクライアント機能部４５のＨＴＴＰリクエスト送信機能部４５ａに渡して画像処理装置１００に送信させる機能も有する（Ｃ１）。このとき送信先となるのは、もちろん応答と対応する画像機器コマンドの送信元の画像処理装置１００である。また、画像処理装置１００からの結果通知の受信通知に応じて、コマンドの状態を管理する機能も有する（Ｃ４）。

さらにまた、ここでは詳細な図示は省略しているが、アクションハンドラ群４３のアクションハンドラ４３ａが生成したコマンドについても、画像機器コマンドに準じて取り扱う機能を有する。すなわち、管理装置１０２に対するコマンドであれば、画像機器コマンドの場合と同様に管理装置１０２に転送し、応答はコマンド分配機能部４２を介してアクションハンドラ４３ａに返す。また、画像処理装置１００に対するコマンドであれば、結果通知の場合と同様に画像処理装置１００に転送し、転送時のＨＴＴＰリクエストに対応するＨＴＴＰレスポンスに記載された応答を、コマンド分配機能部４２を介してアクションハンドラ４３ａに返す。

また、ＨＴＴＰクライアント機能部４５は、ＨＴＴＰリクエストを送信するＨＴＴＰリクエスト送信機能部４５ａとＨＴＴＰレスポンスを受信するＨＴＴＰレスポンス受信機能部４５ｂとを備える。
そして、ＨＴＴＰリクエスト送信機能部４５ａは、コマンド転送ハンドラ４４から渡されるメッセージ、すなわち管理装置１０２や画像処理装置１００に転送すべき各種ＳＯＡＰリクエストを、ＨＴＴＰリクエストに記載して管理装置１０２や画像処理装置１００に送信する機能を有する（Ｂ２，Ｃ２）。また、ＨＴＴＰレスポンス受信機能部４５ｂは、管理装置１０２や画像処理装置１００が送信してくるＨＴＴＰレスポンスを受信し、これをコマンド転送ハンドラ４４に渡す機能を有する（Ｂ３，Ｂ４，Ｃ３，Ｃ４）。

次に、図１２に、画像処理装置１００の機能のうち、コマンド及びコマンド応答に関する処理を行うための機能の構成を示す機能ブロック図を示す。図１２に示す各機能は、ＣＰＵ２０１が所要の制御プログラムを実行して画像処理装置１００の各部の動作を制御することにより実現されるものである。
また、図１２に示す機能のうち、ＨＴＴＰサーバ機能部２４１及びＨＴＴＰクライアント機能部２４５の機能は、ＣＰＵ２０１及びＰＨＹ２０６によって実現されるものである。コマンド分配機能部２４２及びアクションハンドラ群２４３の機能は、ＣＰＵ２０１によって実現されるものである。

これらの機能についてさらに詳述する。
まず、ＨＴＴＰサーバ機能部２４１は、ＨＴＴＰリクエストを受信するＨＴＴＰリクエスト受信機能部２４１ａとＨＴＴＰレスポンスを送信するＨＴＴＰレスポンス送信機能部２４１ｂとを備える。
そして、ＨＴＴＰリクエスト受信機能部２４１ａは、仲介装置１０１が送信してくるＨＴＴＰリクエストを受信し、これをコマンド分配機能部２４２に渡す機能を有する（Ｅ１，Ｅ２）。また、ＨＴＴＰレスポンス送信機能部２４１ｂは、アクションハンドラ群の各アクションハンドラ２４３ａから渡されるメッセージ、すなわち仲介装置１０１から受信した結果通知に対する受信通知等に係るＳＯＡＰレスポンスを、ＨＴＴＰレスポンスに記載し、受信したＨＴＴＰリクエストに対する応答として仲介装置１０１に送信する機能を有する（Ｅ５，Ｆ５）。

また、コマンド分配機能部２４２は、ＨＴＴＰリクエスト受信機能部２４１ａが受信したＨＴＴＰリクエスト中のＳＯＡＰリクエストや、ＨＴＴＰクライアント機能部２４５のＨＴＴＰレスポンス受信機能部が受信したＨＴＴＰレスポンス中のＳＯＡＰレスポンスに記載されているコマンドやコマンド応答の種類あるいは分類を解析する機能を有する。そして、その結果に応じてＳＯＡＰリクエストやＳＯＡＰレスポンスをアクションハンドラ群２４３の適当なアクションハンドラ２４３ａに渡す機能も有する（Ｅ３）。また、仲介装置１０１の場合と異なり、画像処理装置１００には受信したコマンドを他の装置に転送する機能は設けていないので、自身で処理できないコマンドを受信した場合にはエラー処理を行うようにしており、そのための機能も有する。

また、アクションハンドラ群２４３は、複数のアクションハンドラ２４３ａを有する。そして、各アクションハンドラ２４３ａは、概ねコマンドの種類に対応して用意されており、仲介装置１０１から受信したコマンドに応じた処理を実行してその結果を返す機能や、仲介装置１０１や管理装置１０２に対するコマンドを生成し、そのコマンドに対する応答を受け取ってその応答に応じた処理を行う機能を有する。前者の機能を有するアクションハンドラ２４３ａは、ウェブサービスの機能を提供するためのハンドラであると言うことができる。また、コマンドや応答の受信は、コマンド分配機能部２４２を介して行うようにしている。さらに、ここでは管理装置１０２からのコマンドの取扱いについては図示を省略しているが、アクションハンドラ群２４３には、管理装置１０２からのコマンドに応じて処理を実行してその結果を返すアクションハンドラも含まれる。また、各アクションハンドラ２４３ａは、仲介装置１０１に送信すべきコマンドやコマンド応答に係るＳＯＡＰメッセージを生成し、ＨＴＴＰリクエスト送信機能部２４５ａやＨＴＴＰレスポンス送信機能部２４１ｂに渡してこれを仲介装置１０１に送信させる機能も有する。

また、ＨＴＴＰクライアント機能部２４５は、ＨＴＴＰリクエストを送信するＨＴＴＰリクエスト送信機能部２４５ａとＨＴＴＰレスポンスを受信するＨＴＴＰレスポンス受信機能部２４５ｂとを備える。
そして、ＨＴＴＰリクエスト送信機能部２４５ａは、各アクションハンドラ２４３ａから渡されるメッセージ、すなわち仲介装置１０１に送信すべき各種ＳＯＡＰリクエストを、ＨＴＴＰリクエストに記載して仲介装置１０１に送信する機能を有する（Ｆ２）。また、ＨＴＴＰレスポンス受信機能部２４５ｂは、管理装置１０２や画像処理装置１００が送信してくるＨＴＴＰレスポンスを受信し、これをコマンド分配機能部２４２に渡す機能を有する（Ｆ３，Ｆ４）。

次に、図１３に、管理装置１０２の機能のうち、コマンド及びコマンド応答に関する処理を行うための機能の構成を示す機能ブロック図を示す。図１３に示す各機能は、制御装置１２６中のＣＰＵが所要の制御プログラムを実行して管理装置１０２の各部の動作を制御することにより実現されるものである。
また、図１３に示す機能のうち、ＨＴＴＰサーバ機能部１４１の機能は、制御装置１２６内のＣＰＵ及び外部接続Ｉ／Ｆ１２３によって実現されるものである。コマンド分配機能部１４２及びアクションハンドラ群１４３の機能は、制御装置１２６内のＣＰＵによって実現されるものである。コマンド実行結果記憶機能部１４６の機能は、制御装置１２６内のメモリによって実現されるものである。

これらの機能についてさらに詳述する。
まず、ＨＴＴＰサーバ機能部１４１は、ＨＴＴＰリクエストを受信するＨＴＴＰリクエスト受信機能部１４１ａとＨＴＴＰレスポンスを送信するＨＴＴＰレスポンス送信機能部１４１ｂとを備える。
そして、ＨＴＴＰリクエスト受信機能部１４１ａは、仲介装置１０１が送信してくるＨＴＴＰリクエストを受信し、これをコマンド分配機能部１４２に渡す機能を有する（Ｇ１，Ｇ２）。また、ＨＴＴＰレスポンス送信機能部１４１ｂは、コマンド分配機能部１４２から渡されるメッセージ、すなわち画像機器コマンドや仲介装置コマンドに対する受付通知や応答等に係るＳＯＡＰレスポンスを、ＨＴＴＰレスポンスに記載し、受信したＨＴＴＰリクエストに対する応答として仲介装置１０１に送信する機能を有する（Ｇ５，Ｇ６）。

また、コマンド分配機能部１４２は、ＨＴＴＰリクエスト受信機能部１４１ａが受信したＨＴＴＰリクエスト中のＳＯＡＰリクエストに記載されているコマンドの種類あるいは分類を解析する機能を有する。そして、その結果に応じてＳＯＡＰリクエストをアクションハンドラ群１４３の適当なアクションハンドラ１４３ａ又は結果問い合わせハンドラ１４４に渡す機能も有する（Ｇ３，Ｈ１）。また、画像処理装置１００の場合と同様に自身で処理できないコマンドを受信した場合にはエラー処理を行う機能も有する。

また、アクションハンドラ群１４３は、複数のアクションハンドラ１４３ａ及び結果問い合わせハンドラを有する。そして、各アクションハンドラ１４３ａは、概ねコマンドの種類に対応して用意されており、仲介装置１０１から受信したコマンド（画像機器コマンドの場合も仲介装置コマンドの場合もある）に応じた処理を実行し、その結果をコマンド実行結果記憶機能部１４６に記憶させる機能を有する。また一方で、コマンドに対する受付通知に係るＳＯＡＰメッセージを生成し、これをコマンド分配機能部１４２に渡して仲介装置１０１に送信させる機能も有する。コマンドと応答の対応関係に注目すると、この受付通知がコマンドに対する直接の応答となり、アクションハンドラ２４３ａは、応答として受付通知を返すウェブサービスの機能を提供するためのハンドラであると言うことができる。

また、コマンドや応答の受信は、コマンド分配機能部１４２を介して行うようにしている。そして、ここでは管理装置１０２が生成するコマンドの取扱いについては図示を省略しているが、アクションハンドラ群１４３には、仲介装置１０１や画像処理装置１００に対するコマンドを生成し、またそのコマンドに対する応答に応じた処理を行う機能を有するアクションハンドラも含まれる。

結果問い合わせハンドラ１４４は、アクションハンドラ群１４３中の特殊なハンドラであり、仲介装置１０１からの結果問い合わせコマンドを受け取った場合に、コマンド実行結果記憶機能部１４６を検索する機能を有する（Ｈ２）。そして、仲介装置１０１に返すべき動作結果が記憶されていれば、これを取得してその動作結果を通知するＳＯＡＰレスポンスを生成し、コマンド分配機能部１４２に渡して仲介装置１０１に送信させる機能も有する（Ｈ３）。また、仲介装置１０１に返すべき動作結果がなかった場合に、その旨を通知するＳＯＡＰレスポンスを生成して同様に仲介装置１０１に返させる機能も有する。
このような結果問い合わせハンドラ１４４は、管理装置１０２が受け付けるコマンドに対応させて各コマンド毎に設けてもよいが、いくつかのコマンドをまとめたコマンド群毎に設けたり、１つだけ設けて全てのコマンドに対応した処理を行わせるようにしたりしてもよい。

また、コマンド実行結果記憶機能部１４６は、アクションハンドラ群１４３の結果問い合わせハンドラ１４４以外の各アクションハンドラ１４３ａによるコマンドの実行結果を記憶する機能を有する。そして、この実行結果の記憶は、結果問い合わせハンドラ１４４による検索が可能な形式で行うようにしている。
以上のような各機能を仲介装置１０１，画像処理装置１００，管理装置１０２に設けることにより、仲介装置１０１に、複数の画像処理装置１００からの動作要求を受信して管理装置１０２に転送する転送手順と、管理装置１０２にアクセスした際、管理装置１０２において、それまでに転送したいずれかのコマンドに対する応答が送信可能な状態になっていた場合に、その応答を受信する受信手順と、その手順で応答を受信した場合に、その応答を、その応答と対応するコマンドの送信元に転送する第２の転送手順とを実行させることが可能になる。

次に、図１４に、このような機能を有する仲介装置１０１が管理装置１０２や画像処理装置１００に送信するＨＴＴＰリクエストの例を示す。仲介装置１０１が画像処理装置１００から受信するＨＴＴＰリクエストも、基本的には同様な構成である。
このＨＴＴＰリクエストは、ボディ部としてＳＯＡＰリクエストを記載したものであり、ヘッダ部の「SOAPAction」ヘッダにより、このことを示している。また、「SOAPAction」ヘッダは、ＳＯＡＰリクエストの内容を示すものであり、この例では、「http://www.…」というＵＲＩ（Uniform Resource Identifier）によりリクエストの内容を示している。さらに、これ以外にＨＴＴＰの仕様で既定されている標準ヘッダを付加してもよい。

また、図１５に、仲介装置１０１が管理装置１０２や画像処理装置１００から受信するＨＴＴＰレスポンスの例を示す。仲介装置１０１が画像処理装置１００に送信するＨＴＴＰレスポンスも、基本的には同様な構成である。
このＨＴＴＰレスポンスは、ボディ部としてＳＯＡＰレスポンスを記載したものである。ただし、こちらには「SOAPAction」ヘッダに相当するヘッダは記載していない。ＳＯＡＰリクエストを記載して送信したＨＴＴＰリクエストに対応するＨＴＴＰレスポンスには必ずＳＯＡＰレスポンスを記載するようにプロトコルを設計しておけば、特にヘッダに明示しなくても、ＨＴＴＰレスポンスにＳＯＡＰレスポンスが記載されているか否かを容易に認識できるからである。また、ＨＴＴＰレスポンスについても、図示したもの以外にＨＴＴＰの仕様で既定されている標準ヘッダを付加してもよい。

仲介装置１０１、画像処理装置１００及び管理装置１０２は、このような形式でＳＯＡＰリクエストを通信相手に送信して所定のメソッドに関する動作を要求し、通信相手がその動作の結果として返してくるＳＯＡＰレスポンスを受け取ってその結果に応じた処理を行うようにしている。
そして、以上説明したような各機能を効率よく実現するためには、各装置において用意するメソッドを、一定の規約に従って作成するようにするとよい。次に、この点について説明する。

まず、具体例として、画像処理装置１００から管理装置１０２に対して用紙の注文を行えるようにするためのコマンドについて考える。この場合、コマンドの名称を「用紙注文」とし、引数（入力パラメータ）として「商品名」と「数量」を渡すとすると、各装置において例えば表１に示すような仕様のメソッドを用意するとよい。この表において、下線は、異なる種類（名称）のメソッドについても共通にしておくとよい部分を示す。

画像処理装置１００から管理装置１０２にコマンドを送信する際には、まず仲介装置１０１にそのコマンドを送信する構成となっているので、まず、仲介装置１０１に、「用紙注文」のメソッドを用意する必要がある。この場合、フォーマットとしては入力パラメータとして「商品名」と「数量」を受け取ることができるようにする必要があるが、仲介装置１０１は入力パラメータの内容等を解析する必要はなく、応答として受付通知に相当するメッセージを返せばよい。ただし、受付番号等により、どの画像処理装置からどのようなコマンドを受信したか、また管理装置１０２からの応答受信や画像処理装置１００への結果通知の有無等を管理しておく必要がある。

そして、コマンドが到達すべき管理装置１０２においても、「用紙注文」のメソッドを用意し、「商品名」と「数量」を入力パラメータとして受けとって、「結果」を出力パラメータ（応答）として返すようにするとよいことはもちろんである。なお、仲介装置１０１において、コマンドを管理装置１０２に転送する際にメソッドの名称や入力パラメータの構成を作り変えれば、仲介装置１０１が受け取るコマンドと管理装置１０２が受け取るコマンドで呼び出すメソッドの名称や入力パラメータが一致している必要はないのであるが、仲介装置１０１がコマンドをそのまま転送するようにした方が構成が単純で処理負荷も小さいので、ここではそのようにしている。

また、仲介装置１０１から管理装置１０２へ結果問い合わせを行うので、管理装置１０２には、この結果問い合わせに対応するためのメソッド（結果問い合わせハンドラ１４４に該当）を用意しておくようにしている。そして、このメソッドの名称を、例えばコマンドの名称＋「結果問い合わせ」としておけば、管理装置１０２に転送したコマンドから結果問い合わせのコマンドを容易に生成することができる。また、結果問い合わせメソッドの出力パラメータとしては、「結果」の他、これがどのコマンドに対する結果かを示すため、コマンドの受付時に送信した「受付番号」等の識別情報も返すようにするとよい。「料金」については、用紙注文コマンドに特有の出力パラメータである。

また、仲介装置１０１から画像処理装置１００に結果通知を行うので、画像処理装置１００には、この結果通知に対応するためのメソッドを用意しておくようにしている。そして、このメソッドの名称を、例えばコマンドの名称＋「結果通知」としておけば、画像処理装置１００から受信したコマンドから結果通知のコマンドを容易に生成することができる。また、結果通知メソッドの入力パラメータとしては、「結果」の他、管理装置１０２から受け取った「料金」も送信するようにしている。

以上の各メソッドにおいて、「結果」の記載形式が表１に示したものに限られないことはもちろんであるが、表１に示したものと同じような内容を記載することが好ましい。また、名前空間については、自由に設定してよいが、１つのコマンド（ここでは「用紙注文」）から派生した他のコマンド（ここでは「用紙注文結果問い合わせ」や「用紙注文結果通知」）については、ある程度共通な名前空間とすることが好ましい。
そして、１つのコマンドを作成しようとする場合、各装置にそのコマンドに関連する処理を行う以上のような各メソッドを用意するようにすれば、相互の関連が認識しやすく、また各装置におけるコマンドの管理が容易な構成とすることができる。

また、以上のような各メソッドが従うべき規約を示すと、表２のようになる。この表中において、下線部は、コマンドの種類に応じて定めるべき部分を示し、それ以外は、コマンドの種類によらず共通とすることが好ましい部分を示す。そして、「要求名」は表１に示した例では「用紙注文」に該当し、「要求のパラメータ」は「商品名」と「数量」に、「要求の結果」は「料金」に該当する。

次に、画像処理装置１００が、画像機器コマンドとして表１を用いて説明した用紙注文コマンドを管理装置１０２に対して発した場合に各装置が送受信するＳＯＡＰメッセージの具体例を図１６乃至図２８に示す。
図１６に示すのは、画像処理装置１００から仲介装置１０１に送信する用紙注文コマンドに係るＳＯＡＰリクエストの例である。

この例においては、ルートタグである「Envelope」タグの属性として、名前空間の宣言を行っており、ここでは、ＳＯＡＰで標準として定義されている名前空間の他に、「http://www.example.com/header」及び「http://www.example.com/sales/server」のＵＲＩで特定される名前空間の宣言を行っている。従って、「ｎ」の名前空間接頭辞が付されたＸＭＬタグについては「http://www.example.com/header」のＵＲＩで特定される名前空間に属するタグであることがわかり、「ｎｓ」の名前空間接頭辞が付されたＸＭＬタグについては「http://www.example.com/sales/server」のＵＲＩで特定される名前空間に属するタグであることがわかる。

またＳＯＡＰヘッダには、「コマンドＩＤ」のＸＭＬタグの内容として、この用紙注文コマンドのＩＤである「ＤＢ１２３４５」が記載されている。このＩＤは、コマンドの発行者である画像処理装置１００が付したものである。
さらに、「送信元」タグの内容として、このコマンドの送信元を示す情報である「仲介装置ＩＤ」及び「画像処理装置ＩＤ」の情報が記載されている。このうち、「画像処理装置ＩＤ」は、この画像機器コマンドを生成した画像処理装置のＩＤであり、「仲介装置ＩＤ」は、この画像機器コマンドが仲介装置１０１に転送されてくるまでに経由した仲介装置のＩＤである。「仲介装置ＩＤ」が複数記載される場合もあるが、画像処理装置１００から直接転送されてきた場合には、「仲介装置ＩＤ」タグの内容は空である。

なお、この遠隔管理システムにおいては、コマンドの宛先は特に明示せず、ＳＯＡＰリクエストを受信した装置が自ら処理できるコマンドであれば処理し、そうでなければ他の装置に転送したりエラー処理を行ったりするようにしている。従って、ここでは宛先は特に記載していないが、記載するようにしてもよい。
また、ＳＯＡＰボディには、送信先の装置に実行させるメソッドを指定する情報として、「用紙注文」タグが記載され、その下位のタグ「商品名」や「数量」の要素として、メソッドに引数として引き渡すパラメータが記載されている。ここでは注文内容が記載されている。

図１７に示すのは、仲介装置１０１から画像処理装置１００に送信する、用紙注文コマンドの受付通知に係るＳＯＡＰレスポンスの例である。
この例においても、名前空間の宣言は図１６に示した例と同様である。そして、ＳＯＡＰヘッダには、「コマンドＩＤ」のＸＭＬタグの内容として、対応する用紙注文コマンドのＩＤである「ＤＢ１２３４５」が記述されている。

さらに、「宛先」タグの内容として、「仲介装置リスト」タグや「画像処理装置リスト」タグの下位に、このコマンド応答の宛先を示す情報である「仲介装置ＩＤ」及び「画像処理装置ＩＤ」の情報を記載している。このうち、「画像処理装置ＩＤ」は、このコマンド応答の最終的な送信先となる画像処理装置のＩＤであり、「仲介装置ＩＤ」は、このコマンド応答が画像処理装置に転送される際に経由する仲介装置のＩＤである。「仲介装置ＩＤ」については、ここでは記載すべき情報がないことから記載していない。また、「仲介装置リスト」タグや「画像処理装置リスト」タグを設けず、図１６の場合と同様に「宛先」タグの下位に直接「画像処理装置ＩＤ」や「仲介装置ＩＤ」のタグを設けるようにしてもよい。

なお、この遠隔管理システムにおいては、コマンドの送信元の装置がコマンドに対する応答を受け取ることができれば、コマンドがどのような経路で転送されてどの装置において処理されたかを認識する必要はないので、ここでは送信元は特に記載していないが、記載するようにしてもよい。
ＳＯＡＰボディには、用紙注文コマンドに対する応答であることを示すための「用紙注文Response」タグが設けられ、その下位のタグに、応答の内容が記載される。ここでは、用紙注文コマンドを正常に受け付けた旨の情報として「受付完了」が記載されている。

図１８に示すのは、仲介装置１０１から管理装置１０２に送信（転送）する、用紙注文コマンドに係るＳＯＡＰリクエストの例である。
この例においても、図１６の場合と同様に、「Envelope」タグの属性として、名前空間の宣言を行っている。
ＳＯＡＰヘッダには、「コマンドＩＤ」として、この用紙注文コマンドのＩＤが記載されているが、このコマンドは、仲介装置１０１が生成したものであるので、このＩＤは、仲介装置１０１が付したものである。また、「送信元」タグの内容として、このコマンドの送信元を示す情報である「仲介装置ＩＤ」及び「画像処理装置ＩＤ」の情報を記載している。ここでは、このコマンドは画像処理装置１００が生成して仲介装置１０１が転送するものであるから、これら双方の装置のＩＤを記載している。また、ＳＯＡＰボディには、図１６の場合と同様な情報が記載されている。

図１９に示すのは、管理装置１０２から仲介装置１０１に送信する、用紙注文コマンドの受付通知に係るＳＯＡＰレスポンスの例である。
この例においても、名前空間の宣言は図１６に示した例と同様である。そして、ＳＯＡＰヘッダには、「コマンドＩＤ」のＸＭＬタグの内容として、対応する用紙注文コマンドのＩＤを記載している。このＩＤは、直接の返信先となる仲介装置１０１が付したＩＤである。
また、「宛先」タグの内容として、このコマンド応答の宛先を示す情報である「仲介装置ＩＤ」及び「画像処理装置ＩＤ」の情報を記載している。

ＳＯＡＰボディには、用紙注文コマンドに対する応答であることを示すための「用紙注文Response」タグが設けられ、その下位のタグに、応答の内容が記載される。ここでは、用紙注文コマンドを正常に受け付けた旨の情報として、管理装置１０２が付した受付番号を記載している。
これを受け取った仲介装置１０１は、コマンドＩＤと受付番号とを対応させて管理しておき、後で受付番号と共に処理結果を取得した場合に、それがどのコマンドに対する処理結果かを把握できるようにしておく。

図２０には、用紙注文コマンドの受付通知に係る、図１９とは異なるＳＯＡＰレスポンスの例を示す。
この例は、管理装置１０２において用紙注文コマンドを正常に受け付けられなかった場合の例であり、ここでは、「結果」タグの内容として、指定した商品名の商品が存在しなかったことを示す「商品名エラー」を記載してる。
「Envelope」タグの属性や、ＳＯＡＰヘッダの内容は、図１９の場合と同様である。

図２１に示すのは、仲介装置１０１から管理装置１０２に送信する、用紙注文結果問い合わせコマンドに係るＳＯＡＰリクエストの例である。
この例においても、図１６の場合と同様に、「Envelope」タグの属性として、名前空間の宣言を行っている。
ＳＯＡＰヘッダには、「コマンドＩＤ」として、この用紙注文結果問い合わせコマンドのＩＤが記載されている。このコマンドは、仲介装置１０１が生成するものであるから、このＩＤも、仲介装置１０１が付したものである。

また、「送信元」タグの内容として、このコマンドの送信元を示す情報である「仲介装置ＩＤ」の情報を記載している。このコマンドは画像処理装置１００からのコマンドを転送するものではないので、「画像処理装置ＩＤ」の情報は記載しない。
また、ＳＯＡＰボディには、このＳＯＡＰリクエストが用紙注文結果問い合わせコマンドに係るものであることを示すため、同名のタグを設けているが、引数は必要ないので、その内容は空である。

図２２に示すのは、管理装置１０２から仲介装置１０１に送信する、用紙注文結果問い合わせコマンドに対する応答に係るＳＯＡＰレスポンスの例である。
この例においても、名前空間の宣言は図１６に示した例と同様である。そして、ＳＯＡＰヘッダには、「コマンドＩＤ」のＸＭＬタグの内容として、対応する用紙注文結果問い合わせコマンドのＩＤを記載している。このＩＤは、仲介装置１０１が付したＩＤである。
また、「宛先」タグの内容として、このコマンド応答の宛先を示す情報である「仲介装置ＩＤ」の情報を記載している。他のＳＯＡＰレスポンスと書式を共通化するため、「画像処理装置リスト」タグも設けているが、ここに記載すべき情報はないので、このタグは設けなくてもよい。

ＳＯＡＰボディには、用紙注文結果問い合わせコマンドに対する応答であることを示すための「用紙注文Response」タグを設け、その下位のタグに、応答の内容を記載している。ここでは、処理が完了した用紙注文結果問い合わせコマンドがない旨の情報として、「処理中」を記載している。

図２３には、用紙注文結果問い合わせコマンドに対する応答に係る、図２２とは異なるＳＯＡＰレスポンスの例を示す。
この例は、管理装置１０２において、正常に処理が完了した用紙注文コマンドがあった場合の例であり、ここでは、「結果」タグの内容として、処理が完了したコマンドの受付番号及び、用紙注文コマンドの出力パラメータである料金を記載している。
「Envelope」タグの属性やＳＯＡＰヘッダの内容は、図１９の場合と同様である。ただし、管理装置１０２側で受付番号と対応するコマンドの送信元の情報を把握できるのであれば、仲介装置１０１だけでなく、その送信元までの転送経路の情報を「宛先」タグに記載するようにしてもよい。

図２４には、用紙注文結果問い合わせコマンドに対する応答に係る、さらに別のＳＯＡＰレスポンスの例を示す。
この例は、管理装置１０２において、処理が完了したものの結果がエラーである用紙注文コマンドがあった場合の例であり、ここでは、「結果」タグの内容として、処理が完了したコマンドの受付番号及び、注文に係る用紙の在庫がなく、注文を受け付けられなかった旨を示す「在庫なし」を記載している。
「Envelope」タグの属性やＳＯＡＰヘッダの内容は、図２３の場合と同様である。

図２５に示すのは、仲介装置１０１から画像処理装置１００に送信する、用紙注文結果通知コマンドに係るＳＯＡＰリクエストの例である。
この例においても、「Envelope」タグの属性として名前空間の宣言を行っているが、「ｎｃ」の名前空間接頭辞について「http://www.example.com/sales/client」のＵＲＩで特定される名前空間の宣言を行っている点が、図１６等の場合と異なる。
また、ＳＯＡＰヘッダには、「コマンドＩＤ」として、この用紙注文結果通知コマンドのＩＤが記載されている。このコマンドは、仲介装置１０１が生成するものであるから、このＩＤも、仲介装置１０１が付したものである。

また、「宛先」タグの内容として、このコマンドの宛先を示す情報である「画像処理装置ＩＤ」の情報を記載している。ここでは、結果通知は直接画像処理装置１００に送信するので、「仲介装置ＩＤ」の情報は記載していないが、他の被管理仲介装置１１０をかいして画像処理装置１００に送信するのであれば、送信を仲介させる「仲介装置ＩＤ」の情報も記載する。これらの情報は、初めに用紙注文コマンドを受信した際に、コマンドＩＤと対応して送信元の情報を記憶しておき、その情報を参照して記載するようにすることができる。
また、ＳＯＡＰボディには、このＳＯＡＰリクエストが用紙注文結果通知コマンドに係るものであることを示すため、同名のタグを設け、その下位に、コマンドの実行結果を示す情報を記載している。その内容は、用紙注文結果問い合わせコマンドに対する応答として受け取った実行結果から、「受付番号」を除いたものとするとよい。図２５には、処理が正常に完了し、用紙の料金が１０００円である場合の例を示している。

なお、画像処理装置１００が、コマンドの送信後、そのコマンドに対する応答を受信するまでは次のコマンドを送信しないようにする場合には、特にＩＤ等によって管理しなくても、画像処理装置１００が送信したコマンドとそのコマンドに対する結果通知とを容易に対応付けることができる。
しかし、応答を受信する前に次のコマンドを送信できるような構成とすることも可能であり、この場合には、仲介装置１０１側で、結果通知コマンドの「コマンドＩＤ」として、対応する画像機器コマンドに画像処理装置１００が付していたＩＤを使用するようにする等して、画像処理装置１００が画像機器コマンドと結果通知との対応関係を認識できるようにすればよい。

図２６には、用紙注文結果通知コマンドに係るＳＯＡＰリクエストの図２５とは別の例を示す。
この例は、管理装置１０２において、用紙注文コマンドが正常に受け付けられなかった場合の例であり、ここでは、「結果」タグの内容として、用紙注文コマンドに対する応答に記載されていた「商品名エラー」を記載してる。
「Envelope」タグの属性やＳＯＡＰヘッダの内容は、図２５の場合と同様である。

図２７には、用紙注文結果通知コマンドに係るＳＯＡＰリクエストのさらに別の例を示す。
この例は、管理装置１０２において、用紙注文コマンドの処理は完了したものの結果がエラーであった場合の例であり、ここでは、「結果」タグの内容として、図２４に示したような用紙注文結果問い合わせコマンドの実行結果から「受付番号」を除いた、「在庫なし」を記載している。

図２８には、用紙注文結果通知コマンドに対する応答に係るＳＯＡＰレスポンスの例を示す。
この例においても、名前空間の宣言は図２５に示した例と同様である。そして、ＳＯＡＰヘッダには、「コマンドＩＤ」のＸＭＬタグの内容として、応答を生成した用紙注文結果通知コマンドのＩＤを記載している。このＩＤは、直接の返信先となる仲介装置１０１が付したＩＤである。
また、「宛先」タグの内容として、このコマンド応答の宛先を示す情報である「仲介装置ＩＤ」及び「画像処理装置ＩＤ」の情報を記載している。

ＳＯＡＰボディには、用紙注文結果通知コマンドに対する応答であることを示すための「用紙注文結果通知Response」タグが設けられ、その下位のタグに、応答の内容を記載している。ここでは、用紙注文結果通知コマンドにより用紙注文コマンドの実行結果を正常に受信した旨の情報として、「結果受信完了」を記載している。

次に、図２９に、仲介装置１０１において以上説明してきたような画像機器コマンドの転送に係る機能を実現するために行う処理のうち、ＨＴＴＰサーバ機能部４１に通信要求があった場合に実行する処理のフローチャートを示す。
この処理は、仲介装置１０１をＨＴＴＰサーバとして機能させるためのＨＴＴＰサーバスレッドの処理であり、ＣＰＵ５２が図１１に示した各部として機能して実行するものである。そして、ＣＰＵ５２は、ＨＴＴＰサーバ機能部４１に通信要求があった場合にこのスレッドを作成し、図２９のフローチャートに示す処理を開始する。

そして、まずステップＳ１で、ＣＰＵ５２はＨＴＴＰリクエスト受信機能部４１ａとしての機能により、画像処理装置１００から画像機器コマンドに係るＳＯＡＰリクエスト（例えば図１６に示したもの）を記載したＨＴＴＰリクエストを受信する。
次のステップＳ２では、ＳＯＡＰリクエスト中に記載されているコマンドに係る名前空間ＵＲＩ及びメソッド名を抽出し、ステップＳ３でこれらをもとにハンドラテーブルを参照し、そのコマンドを実行させるハンドラを検索する。
なお、コマンドに係る名前空間ＵＲＩとメソッド名は、ＳＯＡＰボディを示す「Body」要素の子要素の属する名前空間と要素のローカル名であり、「Body」要素の子要素のタグに記載されている。例えば図１６に示したＳＯＡＰリクエストの例では、図３０に示す通り「ｎｓ：用紙注文」である。そして、符号ａで示す名前空間接頭辞から、「Envelope」タグの属性における名前空間ＵＲＩの定義を参照すると、コマンドに係る名前空間ＵＲＩは「http://www.example.com/sales/server」であることがわかる。また、「：」の後側の符号ｂで示した部分は、そのままメソッド名である。

また、ハンドラテーブルは、ステップＳ２で抽出される名前空間ＵＲＩ及びメソッド名と、それらで規定されるコマンドに係る処理を実行させるための仲介装置１０１中のアクションハンドラとの対応関係を記載したテーブルであり、仲介装置１０１が不揮発メモリに保持している。
そして、具体例としては、図３１に示すようなものとすることが考えられ、ここでは、仲介装置１０１自身の情報の取得を要求する「仲介装置情報取得」コマンドは仲介装置情報取得ハンドラに実行させるものであり、時刻合わせのために仲介装置１０１の設定時刻を取得を要求する「現在時刻取得」コマンドは現在時刻取得ハンドラに実行させることが記載されている。もちろん、他のコマンドについても同様に記載することができる。

なお、このハンドラテーブルには、仲介装置１０１が自ら実行するコマンドのみが記載されており、ここに記載されていないコマンドは、他の装置に転送して実行させるため、コマンド転送ハンドラ４４に取り扱わせるようにしている。ただし、転送するものも含めて受信し得るコマンドを全てハンドラテーブルに記載しておき、ハンドラテーブルに記載されていないコマンドを受信した場合にエラー処理を行うようにすることも考えられる。

図２９の説明に戻る。
ステップＳ３での検索が終了すると、処理はＳ４に進み、受信したコマンドに関する処理を行わせるべきアクションハンドラが発見されたか否か判断する。ここまでのステップＳ２乃至Ｓ４の処理は、コマンド分配機能部４２としての機能による処理である。
そして、ステップＳ４でアクションハンドラが発見されていた場合には、ステップＳ５に進み、発見されたアクションハンドラにコマンドを渡してそのコマンドに係る処理を実行させ、その結果を受け取って、ステップＳ６でそのコマンドに対する応答のＳＯＡＰレスポンスを記載したＨＴＴＰレスポンスを画像処理装置１００に送信して処理を終了する。これらのステップＳ５及びＳ６の処理は、通常のウェブサービスの提供に係る処理であり、コマンド分配機能部４２及びＨＴＴＰレスポンス送信機能部４１ｂとして機能によるものである。

一方、ステップＳ４でアクションハンドラが発見されなかった場合には、コマンド転送ハンドラ４４としての機能により、ステップＳ７乃至Ｓ９の処理を行う。すなわち、ステップＳ７で受信したＳＯＡＰリクエストを保存し、ステップＳ８でコマンドの受付通知に係るＳＯＡＰレスポンス（例えば図１７に示したもの）を記載したＨＴＴＰレスポンスを画像処理装置１００に送信する。そして、ステップＳ９で受信したコマンドを管理装置１０１に転送するための転送スレッドを起動して処理を終了する。
以上の処理により、仲介装置１０１は、画像処理装置１００からのコマンドを受け付け、それが自身で処理するコマンドであれば処理を行って応答を返し、自身で処理しない（できない）コマンドであれば受付通知を返した上で管理装置１０１への転送を準備することができる。また、以上の処理において、ステップＳ８が受信通知手順の処理であり、この処理において、ＣＰＵ５２が受信通知手段として機能する。

次に、図３２に、仲介装置１０１が受信した画像機器コマンドを管理装置１０２へ転送する機能を実現するために実行する転送スレッドの処理のフローチャートを示す。この処理は、ＣＰＵ５２が図１１に示した各部、主としてコマンド転送ハンドラ４４として機能して実行するものである。そして、ＣＰＵ５２は、図２９のステップＳ９において起動が指示された場合にこのスレッドを作成し、図３２のフローチャートに示す処理を開始する。
この処理においては、まずステップＳ１１で、画像機器コマンドに係る未送信のＳＯＡＰリクエストを読み出す。そして、ステップＳ１２で、取得したＳＯＡＰリクエストに、仲介装置１０１がコマンドを管理するためのコマンドＩＤと、自身の仲介装置ＩＤとを記載して転送用ＳＯＡＰリクエスト（例えば図１８に示したもの）を生成する。

そしてその後、ステップＳ１３で、ＨＴＴＰリクエスト送信機能部４５ａとしての機能により、ステップＳ１２で生成したＳＯＡＰリクエストを記載したＨＴＴＰリクエストを管理装置１０２に送信する。
そして、次のステップＳ１４で、管理装置１０２からのＨＴＴＰレスポンスを待ち、これを受信すると、そこに記載されているＳＯＡＰレスポンスの内容を記憶する。このＳＯＡＰレスポンスは、管理装置１０２に転送したコマンドに対する受付通知のはずである。

そして、ステップＳ１５でそのＳＯＡＰレスポンスが、コマンドを正常に受け付けた旨のもの（例えば図１９に示したもの）であるか否か判断する。ここでは、管理装置１０２がコマンドを正常に受け付けた場合には、「結果」要素として受付ＩＤを記載して返してくるため、例えば「結果」要素の値が数値であるか否かによってこの判断を行うことができる。このような判断手法を採れば、ＳＯＡＰレスポンスの内容を詳細に解析しなくてもステップＳ１５の判断を行うことができるので、処理を簡略化することができる。
そして、ステップＳ１５でＹＥＳであれば、ステップＳ１６以下に進み、図３３に示すような結果問い合わせスレッドが存在しているか否か判断し、なければステップＳ１７で結果問い合わせスレッドを起動して処理を終了する。あればそのまま処理を終了する。なお、コマンドによって異なる結果問い合わせスレッドを用いるようにしている場合には、ステップＳ１３で送信したコマンドと対応する結果問い合わせスレッドが存在していなければ、対応する結果問い合わせスレッドを起動する。

一方、ステップＳ１５でＮＯであれば、ステップＳ１８に進み、転送した画像機器コマンドが受付エラーとなった旨の結果通知に係るＳＯＡＰリクエスト（例えば図２６に示したもの）を生成し、ステップＳ１９で、ＨＴＴＰリクエスト送信機能部４５ａとしての機能により、そのＳＯＡＰリクエストを記載したＨＴＴＰリクエストを、転送した画像機器コマンドの送信元の画像処理装置１００に送信する。

そして、ステップＳ２０で画像処理装置１００からのＨＴＴＰレスポンスの受信を待ち、これを受信すると、そこに記載されているＳＯＡＰレスポンスの内容を記憶する。このＳＯＡＰレスポンスは、画像処理装置１００に送信した結果通知に対する受信通知（例えば図２８に示したもの）のはずである。そして、以上で処理を終了する。
ステップＳ２０で処理を終了した場合には、管理装置１０２に転送した画像機器コマンドに係る処理は完結しているので、画像処理装置１００からの受信通知に基づいてその点を把握できれば、転送した画像機器コマンドや結果通知等の情報は、その時点で破棄してしまってよい。もちろん、エラー情報を抽出して管理する等してもよい。

以上の処理により、画像処理装置１００から受信した画像機器コマンドを、管理装置１０２に転送することができる。また、ＨＴＴＰサーバスレッドの処理とこの転送スレッドの処理が、転送手順の処理であり、この処理において、ＣＰＵ５２が転送手段として機能する。この転送の過程において、仲介装置１０１は、画像処理装置１００から受信したコマンドに係るＳＯＡＰメッセージのＳＯＡＰボディをそのまま転送するのみであり、コマンド名以外の部分についてＳＯＡＰボディの内容を解析する必要はない。

次に、図３３に、仲介装置１０１が管理装置１０２へ転送したコマンドに実行結果を取得する機能を実現するために実行する結果問い合わせスレッドの処理のフローチャートを示す。この処理は、ＣＰＵ５２が図１１に示した各部、主としてコマンド転送ハンドラ４４として機能して実行するものである。そして、ＣＰＵ５２は、図３２のステップＳ１７において起動が指示された場合にこのスレッドを作成し、図３３のフローチャートに示す処理を開始する。
この処理においては、まずステップＳ３１で所定時間待機する。その後、ステップＳ３２で結果問い合わせのＳＯＡＰリクエスト（例えば図２１に示したもの）を生成し、ＨＴＴＰリクエスト送信機能部４５ａとしての機能により、ステップＳ３３でそのＳＯＡＰリクエストを記載したＨＴＴＰリクエストを管理装置１０２に送信する。

そして、次のステップＳ３４で、管理装置１０２からのＨＴＴＰレスポンスを待ち、これを受信すると、そこに記載されているＳＯＡＰレスポンスの内容を記憶する。このＳＯＡＰレスポンスの内容は、結果問い合わせに対する管理装置１０２からの応答のはずである。また、管理装置１０２には、結果問い合わせを行った時点で、それまでに転送したいずれかのコマンドに対する応答が送信可能な状態になっていた場合に、その応答を結果問い合わせに対する応答として返させるようにしており、このステップＳ３４の処理は、受信手順の処理に該当する。またこの処理において、ＣＰＵ５２は受信手段として機能する。

そして、ステップＳ３５で、そのＳＯＡＰレスポンスが、コマンドの処理が完了していない旨の応答（例えば図２２に示したもの）であるか否か判断する。ここでは、管理装置１０２において処理が完了しているコマンドがなかった場合には、管理装置１０２は「結果」要素として「処理中」を記載して返してくるため、例えば「結果」要素の値が「処理中」であるか否かによってこの判断を行うことができる。また、このような内容であっても、ＳＯＡＰレスポンスは動作応答に該当する。
そして、処理が完了していない旨の応答であった場合には、ステップＳ３１に戻って処理を繰り返し、所定時間後に再度結果問い合わせのＳＯＡＰリクエストを管理装置１０２に送信する。すなわち、定期的に管理装置１０２にアクセスし、コマンドに対する応答の取得を試みる。

一方、ステップＳ３５が処理が完了していない旨の応答でなかった場合（処理が完了した旨の応答であった場合）には、ステップＳ３６で、処理が正常に完了した旨の応答（例えば図２３に示したもの）であったか否か判断する。ここでは、管理装置１０２において制御に処理が完了した応答を返してくる場合には、管理装置１０２は「結果」要素として「処理完了」を記載して返してくるため、例えば「結果」要素の値が「処理完了」であるか否かによってこの判断を行うことができる。このような判断手法を採れば、ＳＯＡＰレスポンスの内容を詳細に解析しなくてもステップＳ１５の判断を行うことができるので、処理を簡略化することができる。ステップＳ３５についても同様である。

そして、ステップＳ３６でＹＥＳであった場合には、ステップＳ３７に進んで、処理が完了した画像機器コマンドについて、処理が完了した旨及びその処理結果を通知する結果通知のＳＯＡＰリクエスト（例えば図２５に示したもの）を生成する。そしてステップＳ３８で、ＨＴＴＰリクエスト送信機能部４５ａとしての機能により、そのＳＯＡＰリクエストを記載したＨＴＴＰリクエストを、処理が完了した画像機器コマンドの送信元の画像処理装置１００に送信する。
そして、ステップＳ３９で画像処理装置１００からのＨＴＴＰレスポンスの受信を待ち、これを受信すると、そこに記載されているＳＯＡＰレスポンスの内容を記憶する。このＳＯＡＰレスポンスは、画像処理装置１００に送信した結果通知に対する受信通知（例えば図２８に示したもの）のはずである。

そして、ステップＳ４３で応答を受信していない画像機器コマンドがあるか否か判断し、あればステップＳ３１に戻って処理を繰り返す。すなわち、管理装置１０２に転送した全ての画像機器コマンドに対する応答を受信するまで、定期的に管理装置１０２にアクセスし、コマンドに対する応答の取得を試みる。そして、ステップＳ４３で応答を受信していない画像機器コマンドがなければ、処理を終了する。
また、ステップＳ３６でＮＯであった場合には、受信したＳＯＡＰレスポンスは、処理が正常に完了していない旨の応答（例えば図２０に示したもの）であるが、このような内容であっても、ＳＯＡＰレスポンスは動作応答に該当する。
そして、この場合、ステップＳ４０に進んで、処理が完了した画像機器コマンドについて、処理が完了したがエラーであった旨及びその処理結果を通知する結果通知のＳＯＡＰリクエスト（例えば図２７に示したもの）を生成する。そしてステップＳ４１及びＳ４２で、ステップＳ３８及びＳ３９の場合と同様に画像処理装置１００との間で結果通知と受信通知のＳＯＡＰメッセージを授受して処理を終了する。

なお、ステップＳ３９又はステップＳ４２の処理が終了すると、管理装置１０２に転送した画像機器コマンドに係る処理は完結したことになるので、画像処理装置１００からの受信通知に基づいてその点を把握できれば、転送した画像機器コマンドや結果通知等の情報は、その時点で破棄してしまってよい。もちろん、実行結果やエラー情報を抽出して管理する等してもよい。
この結果問い合わせスレッドの処理を行うことにより、仲介装置１０１が管理装置１０２に転送した画像機器コマンドの実行結果を取得し、これを画像処理装置１００に通知することができる。この処理において、ステップＳ３８及びＳ４１が第２の転送手順の処理であり、ここではＣＰＵ５２が第２の転送手段として機能する。

なお、以上説明した各スレッドは、処理終了時に消滅させてしまう必要はなく、処理終了後も、新たな開始トリガーがあるまで待機状態にしておくようにしてもよい。従って、各スレッドの処理が同時に並行して実行されることも有り得る。また、転送スレッドについては、複数のスレッドを同時に起動し、複数のコマンドについて並行して転送の処理を行うことができるようにしてもよい。ＨＴＴＰサーバスレッドについても、サーバ機能の仕様が許せば、複数同時に起動してもよい。ただし、これらの場合でも、スレッドを多く設けすぎるとリソースの消費が大きくなるので、スレッド数に上限を設けることが好ましい。

また、結果問い合わせスレッドについては、同種のものを複数同時に用意すると、それだけ結果問い合わせの回数が増してしまう。むしろ、状況に応じて結果問い合わせの間隔を調整し、応答を受信していないコマンドが多数ある場合に間隔を短くする等の対応を行う方がよい。このようにすれば、多数のコマンドを逐次的に処理する場合でも、管理装置１０２において処理が完了していれば、短時間のうちに全てのコマンドに対する応答を取得することができる。また、受信すべき応答がない場合でも結果問い合わせスレッドを待機状態にしておくのであれば、その間は結果問い合わせを行わないようにするとよい。

また、以上の各フローチャートでは、仲介装置１０１からの管理装置１０２に対するコマンドについては特に言及していないが、このコマンドも、転送スレッド及び結果問い合わせスレッドとほぼ同じ処理によって取り扱うことができる。ただし、実行結果を画像処理装置１００に通知することは当然不要であり、それに代えて、コマンドを生成したアクションハンドラに結果を通知するようにすればよい。
さらに、ここでは結果問い合わせスレッドは１つしか示していないが、転送したコマンドの種類に応じて異なる結果問い合わせコマンドを用意する場合には、各結果問い合わせコマンドに対応する結果問い合わせスレッドを設け、独立して動作させるようにするとよい。

ここで、図３４に、仲介装置１０１に以上説明した各スレッドに係る処理を実行させて画像処理装置１００からの管理装置１０２に対するコマンドの転送を仲介させる場合の処理シーケンスを示す。
すなわち、画像処理装置１００が画像機器コマンドを生成した場合（Ｓ５１）、まずそのコマンドを仲介装置１０１に送信する（Ｓ５２）。このとき、画像処理装置１００は、送信したコマンドが最終的にどの装置で実行されるかを必ずしも認識している必要はない。

また、仲介装置１０１は、画像機器コマンドを受信し、これが転送の必要なコマンドであると認識した場合、とりあえず画像処理装置１００に受信通知を返し（Ｓ５３）、その後管理装置１０２にコマンドを転送する（Ｓ５４）。そして、管理装置１０２は、これを受信すると受付通知を返す（Ｓ５５）。
その後、仲介装置１０１は定期的に管理装置１０２に結果問い合わせを行う（Ｓ５６，Ｓ５９）。そして、管理装置１０２は、この結果問い合わせに対し、受信したコマンドに対する処理が完了していなければ処理未完了の応答を（Ｓ５７）、画像機器コマンドに応じた処理（Ｓ５８）を行って処理が完了していれば、処理完了の応答を返す（Ｓ６０）。

そして、仲介装置１０１は、処理完了の応答を受け取ると、画像処理装置１００にその旨及び応答の内容を示す結果通知を送信する（Ｓ６１）。そして、画像処理装置１００はその結果通知に対して受信通知を返すと共に（Ｓ６２）、受け取ったコマンド実行結果に応じた処理を行う（Ｓ６３）。

以上説明してきたように、この実施例の遠隔管理システムにおいては、仲介装置１０１は、複数の画像処理装置１００からコマンドを受信して管理装置１０２に転送することができる。そして、各装置は、コマンドを受信した場合に直ちにその送信元に対して受付通知や受信通知を返すので、コマンドの転送や処理に時間がかかる場合でもＨＴＴＰリクエストがタイムアウトしないようにすることができる。特に、仲介装置１０１と画像処理装置１００との間の通信は、ユーザ環境内のＬＡＮ等によって行うため、タイムアウトの発生を非常に少なくすることができる。

また、仲介装置１０１は、タイムアウトを気にすることなく任意のタイミングでコマンドの転送を行うことができるので、プロトコル設計の自由度を向上させることができる。
また、その後の結果問い合わせや結果通知は仲介装置１０１が行うため、末端の画像処理装置１００には、これらの機能を設ける必要がない。従って、通常の画像処理装置をこの実施形態の遠隔管理システムに対応させるような場合に付加すべき機能が少なくて済み、設計や開発が容易になる。

また、仲介装置１０１は、結果問い合わせを、コマンドの送信元がどの装置であるかを特に考慮することなく行い、管理装置１０２も、結果問い合わせがあった時点でいずれかのコマンドに応じた処理が完了していれば、それがどの装置からのコマンドに係るものであるかに関わりなく応答を返すようにしている。
従って、仲介装置１０１が複数の画像処理装置１００（さらに仲介装置１０１自身あるいは被管理仲介装置１１０）が行うべき結果問い合わせを代行し、一本化して行うことができるので、各装置がばらばらに結果問い合わせを行う場合に比較して、各コマンドに対する応答の取得に必要な結果問い合わせの数を削減して通信トラフィックの量を低減することができる。

すなわち、ファイアウォール１０４の内側に設けられる画像処理装置１００がファイアウォール１０４の外側にある管理装置１０２にコマンドを送信してそのコマンドに対する応答を受信する場合において、管理装置１０２においてコマンドに対応する処理に時間を要する場合でも、コマンドをタイムアウトさせずに済むようにしながら、管理装置１０２から画像処理装置１００への動作応答の転送のために必要な通信トラフィックを抑えられるようにすることができる。
また、管理装置１０２には、積極的に結果通知を行う機能を設けなくても、仲介装置１０１からの、表１や表２に示したようなコマンドに応じた処理を行う機能を設けるのみで、コマンドの処理結果を末端の画像処理装置１００まで伝達することができる。従って、管理装置１０２の機能構成も単純化し、設計や開発のコストを低減することができる。

なお、以上の説明において、表１及び表２を用いて説明した仕様例では、コマンド（サービス）毎に対応する結果問い合わせメソッドを用意する例を示したが、全てのコマンドに対応可能な共通の結果問い合わせメソッドを用意するようにしたり、複数のコマンドに対応可能な結果問い合わせメソッドを用意するようにしてもよいことはもちろんである。
ただし、このようにした場合、仲介装置１０１が画像処理装置１００に対して適当な結果通知コマンドを送信できるようにするためには、結果問い合わせコマンドに対する応答として画像機器コマンドの実行結果を受け取った仲介装置１０１が、受け取ったものがどの種類のコマンドに対する実行結果であるのかを認識できるようにすることが好ましい。そして、このためには、結果問い合わせコマンドに対する応答に、画像機器コマンドに記載されていたコマンド名を追加したり、仲介装置１０１側で、受付番号とコマンド名とを対応付けて管理しておき、受付番号からコマンド名を検索できるようにする等することが考えられる。

また、結果通知メソッドについても、画像機器コマンドと対応させて設けることは必須ではなく、上記の結果問い合わせメソッドの場合と同様、複数の画像機器コマンドに対応可能な共通のメソッドを用意するようにしてもよい。そして、結果問い合わせメソッドと結果通知メソッドとが対応していれば、仲介装置１０１において、画像機器コマンドの具体的なコマンド名を管理しておく必要はない。
ただし、この場合、画像処理装置１００の側で、通知された動作結果がその画像機器コマンドに対応するものかを管理できるようにしておくことが必要である。このためには例えば、仲介装置１０１側で、結果通知コマンドの「コマンドＩＤ」として、対応する画像機器コマンドに画像処理装置１００が付したＩＤを使用するようにすることが考えられる。

さらに、管理装置１０２において、結果問い合わせコマンドを受け付けた時点で同一の装置からの複数のコマンドに関する処理が完了していた場合、これらのコマンドに対する応答を、１つのＳＯＡＰレスポンスに記載してまとめて返すようにしてもよい。
別々の装置からの複数のコマンドに関する処理が完了していた場合でも、同様な対応を行うことは可能であるが、この場合には、コマンド送信元（応答の宛先）の装置の情報をＳＯＡＰヘッダに記載することができないので、各応答と対応させてＳＯＡＰボディに記載することになる。

〔第２の実施例：図３５乃至図５６〕
次に、図１に示した通信システムの第２の実施例である遠隔管理システムについて説明する。この遠隔管理システムの特徴は、仲介装置１０１と管理装置１０２との間で、１つのＨＴＴＰメッセージに複数のＳＯＡＰメッセージを記載して送信できるようにした点と、結果問い合わせという独立のメソッドを設けなくても、管理装置１０２に転送するコマンドとそのコマンドに対する応答とにより、実質的にこれを同じ機能を実現できるようにした点である。そして、このような特徴を実現するため、主に仲介装置１０１及び管理装置１０２における処理が第１の実施例の場合と異なる。そして、システムのハードウェア構成及び、画像処理装置１００の機能については、第１の実施例の場合とほぼ同様であるから、これらについての説明は省略するか簡単にする。また、第１の実施例の構成と対応する部分には、第１の実施例の場合と同じ符号を用いる。

まず、図３５に、この遠隔管理システムにおける仲介装置１０１と管理装置１０２の間の通信シーケンスの例を示す。
この遠隔管理システムにおいても、仲介装置１０１と管理装置１０２との間には、ファイアウォール１０４があるため、この図に示すように、通信は常に、仲介装置１０１から通信要求としてＨＴＴＰリクエストを管理装置１０２に送信し、管理装置１０２からこの通信要求に対する通信応答としてＨＴＴＰレスポンスを仲介装置１０１に返すという手順で行われる。

そして、仲介装置１０１は、画像処理装置１００から受信した画像機器コマンドのうち、自身で処理せず転送するコマンドを、ＨＴＴＰリクエストに記載して管理装置１０２に転送するようにしている（ＨＴＴＰリクエストＸ）。また、仲介装置１０１自身が生成したコマンドも、同じＨＴＴＰリクエストに記載して管理装置１０２に転送することができる。この場合において、１つのＨＴＴＰリクエストに０も含めて任意の数（データ量の観点から上限を設けてもよい）のコマンドを記載することができ、ＨＴＴＰリクエストＸには２つの画像機器コマンドと１つの仲介装置コマンドを記載した例を示している。

一方、管理装置１０２は、受信したコマンドに対する応答がすぐに生成できる場合には、コマンド受信時のＨＴＴＰリクエストに対するＨＴＴＰレスポンスに応答を記載して仲介装置１０１に送信する（ＨＴＴＰレスポンスＸ）。この場合にも、上記の場合と同様、１つのＨＴＴＰレスポンスに任意の数の応答を記載することができる。
しかし、処理に時間がかかる場合には、特に応答を記載せずにＨＴＴＰレスポンスを送信する。図３５に示した例では画像機器コマンドＣに対する応答はＨＴＴＰレスポンスＸには記載していない。

そして、仲介装置１０１は、定期的に管理装置１０２にＨＴＴＰリクエストを送信してアクセスし、管理装置１０２は、このアクセスがあった時点で仲介装置１０１に送信できる状態になっている応答があれば、対応するＨＴＴＰレスポンスにその応答を記載して送信する。図３５に示した例では、画像機器コマンドＣに対する応答をＨＴＴＰレスポンスＹに記載して送信している。
このように、この遠隔管理システムにおいては、第１の実施例の場合と異なり、管理装置１０２からの受付通知や、仲介装置１０１からの結果問い合わせといったＳＯＡＰメッセージは採用していない。しかし、このようなシーケンスを採用しても、第１の実施例の場合と同様に画像機器コマンドの転送と応答の取得は可能である。この遠隔簡易システムにおいては、仲介装置１０１から管理装置１０２に対して送信するＨＴＴＰリクエストが、それ自体で結果問い合わせと同様な機能を有するようにしているためである。
なお、仲介装置１０１と画像処理装置１００との間の通信シーケンスについては、第１の実施例の場合と同様である。

次に、図３６に、この実施例における仲介装置１０１の機能のうち、コマンド及びコマンド応答に関する処理を行うための機能の構成を示す機能ブロック図を示す。図３６に示す各機能は、ＣＰＵ５２が所要の制御プログラムを実行して仲介装置１０１の各部の動作を制御することにより実現されるものである。
また、図３６に示す機能のうち、ＨＴＴＰサーバ機能部４１及びＨＴＴＰクライアント機能部４５の機能は、ＣＰＵ５２及びＰＨＹ５７によって実現されるものである。コマンド分配機能部４２，アクションハンドラ群４３，コマンド転送ハンドラ４４，送信メッセージ収集機能部４７，受信メッセージ分配機能部４８，応答状況管理機能部４９の機能は、ＣＰＵ５２によって実現されるものである。被管理側コマンドプール４６は、いずれかの書き換え可能な記憶手段に設けられるものである。例えばフラッシュメモリ５４に設けることができるが、ＳＤＲＡＭ５３やＨＤＤ６３に設けてもよい。

これらの機能についてさらに詳述する。
まず、ＨＴＴＰサーバ機能部４１及びコマンド分配機能部４２の機能は、第１の実施例の場合と同様である。ただし、この実施例においては、後述する通り、コマンド分配機能部４２は仲介装置コマンドの管理装置１０２への送信には関与しない。
また、アクションハンドラ群４３は、第１の実施例の場合と同様、複数のアクションハンドラ４３ａ及びコマンド転送ハンドラ４４を有する。ただし、これらの各ハンドラは、画像処理装置１００から受信したり自身で生成したりして管理装置１０２に転送すべきコマンドを、転送用コマンドシートを作成して被管理側コマンドプール４６に登録する（Ｌ１）ようにしている点が、第１の実施例の場合と異なる。

また、コマンド転送ハンドラ４４は、管理装置１０２に転送したコマンドに対する応答を受け取った場合に、その応答を画像処理装置１００に通知するため、結果通知コマンドに係るＳＯＡＰリクエストを生成してＨＴＴＰリクエスト送信機能部４５ａに渡し、これをＨＴＴＰリクエストに記載して画像処理装置１００に送信させる機能も有する（Ｍ１）。
そして、被管理側コマンドプール４６は、管理装置１０２に送信すべき画像機器コマンド及び仲介装置コマンドを、これらのコマンドに対する応答や、このコマンドの識別情報及び宛先や送信元の情報等と関連付けて登録するプールである。以後、画像機器コマンドと仲介装置コマンドとを一括して「被管理側コマンド」とも呼ぶことにする。

ここで、図３７に仲介装置１０１の転送用コマンドシートにおけるデータ構造の例を示す。
この図に示すように、仲介装置１０１においては、転送用コマンドシートには、「コマンドＩＤ」、「送信元情報」、「メソッド名」、「入力パラメータ」、「状態」、「コマンド実行結果の通知先」、および「出力パラメータ」のデータを記憶する領域を設けている。そして、このうち「コマンドＩＤ」、「メソッド名」、および「入力パラメータ」が被管理側コマンド（及びそこに付されたＩＤ）に該当し、「状態」及び「コマンド実行結果の通知先」が管理情報に該当する。「出力パラメータ」は、管理装置１０２から受信するコマンド応答の内容である。

各項目の内容について説明する。
まず、「メソッド名」は、管理装置１０２に対するリクエストの内容であり、管理装置１０２において呼び出す関数（メソッド）の種類を示す。「入力パラメータ」は、「メソッド名」に付随するデータであり、関数を呼び出す際の引数である。
「送信元情報」は、コマンドの送信元、すなわちコマンドを生成した装置の識別情報を示す。またこの情報は、コマンドに対する応答を送信する際の宛先を示す情報になる。なお、識別情報としては、ＩＤ、固有名称、ＩＰアドレス等を用いることができる。また、シートに記載されているコマンドが複数の装置を経由して転送されてきたものである場合には、最終的な応答の宛先までの経路情報も含む。

「コマンドＩＤ」は、被管理側コマンドを識別するための識別情報である。「状態」は、被管理側コマンドに関する処理の進行状況を示すデータであり、処理の進行と共に、「未処理」→「応答待ち」→「応答受信済」もしくは、遅延通知があった場合には「未処理」→「応答待ち」→「応答遅延」→「応答受信済」と遷移していく。
「コマンド実行結果の通知先」は、そのシートに記載している被管理側コマンドに対する応答を受信した場合に、その旨を通知して必要な処理を実行させるモジュールを示す参照情報である。参照するモジュールは、被管理側コマンドを登録したハンドラであることが多いが、必ずしもそうである必要はない。
「出力パラメータ」には、コマンド応答を受け取った段階で、その内容を格納する。管理装置１０２からのコマンド応答を受け取るまでは空である。
この他に、シートのプロパティを記録できるようにしてもよい。

図３８に、画像処理装置１００から受信した画像機器コマンド（例えば図１６に示したようなＳＯＡＰリクエスト）をコマンド転送ハンドラ４４が転送用コマンドシートに登録する場合の、各項目に記載すべきデータの取得先を示す。
この図に示すように、「コマンドＩＤ」及び「送信元情報」は、それぞれＳＯＡＰリクエストのＳＯＡＰヘッダから抽出する。図１６に示した例では、前者は「コマンドＩＤ」タグの要素として、後者は「送信元」タグの要素として記載されている。

また、「メソッド名」は、ＳＯＡＰボディから抽出するが、一般に、「Body」要素の子要素のタグに記載されている。そして、「入力パラメータ」としては、ＳＯＡＰボディのＸＭＬ文字列をそのまま登録する。この場合において、ＳＯＡＰボディの内容を解釈する必要はない。
そして、「状態」には初期値として「未処理」を登録し、「コマンド実行結果の通知先」には、コマンドシートを作成したコマンド転送ハンドラ４４を登録する。「出力パラメータ」の初期値が空であることは、上述の通りである。

図３６の説明に戻ると、送信メッセージ収集機能部４７は、管理装置１０２に転送すべき被管理側コマンドを、コマンドＩＤ及び宛先情報と関連付けて被管理側コマンドプール４６から読み出し（Ｌ２）、これらから送信メッセージを生成する機能を有する。なお、被管理側コマンドに転送優先順位が指定されている場合には、送信メッセージ収集機能部４７が転送優先順位の高いものから順に読み出すようにすることが考えられる。

また、送信メッセージとは、上記のコマンド応答やコマンドとコマンドＩＤとを、構造化言語であるＸＭＬ（Extensible Markup Language）で、ＳＯＡＰメッセージとして記載したものである。そして、送信メッセージ収集機能部４７は、１つのコマンドにつき、送信メッセージとして１つのＳＯＡＰメッセージを生成する。またこのとき、各コマンドのコマンドＩＤ、送信元情報及び宛先情報はＳＯＡＰヘッダに記載し、被管理側コマンドの内容は、ＳＯＡＰボディに記載する。ＳＯＡＰによる通信では、ＳＯＡＰヘッダとＳＯＡＰボディとからなるＳＯＡＰエンベロープ（封筒）と呼ばれるメッセージをＸＭＬで記載し、ＨＴＴＰなどのプロトコルで交換することになる。
このようなコマンドからのＳＯＡＰメッセージの生成は、ＷＳＤＬ（Web Service Description Language）に基づいて生成される所要の変換プログラム（シリアライザ）を実行し、データを直列化することによって行うことができる。なお、転送用コマンドシートにＸＭＬ文字列がそのまま登録されている部分については、シリアライザは不要である。

また、ＨＴＴＰクライアント機能部４５は、第１の実施例の場合と同様、ＨＴＴＰリクエスト送信機能部４５ａとＨＴＴＰレスポンス受信機能部４５ｂとを備える。
そして、ＨＴＴＰリクエスト送信機能部４５ａは、送信メッセージ収集機能部４７が生成した送信メッセージを記載したＨＴＴＰリクエストを生成し、管理装置１０２に送信する機能を有する（Ｌ３，Ｌ４）。このとき、１つのＨＴＴＰリクエストに送信メッセージをいくつ含めてもよい。もちろん、送信元の異なるコマンドに係る送信メッセージを混在させてもよい。
そこで、ＨＴＴＰリクエスト送信機能部４５ａは、コマンドの種類や送信元に関わり無く、送信メッセージ収集機能部４７が生成した全ての送信メッセージを１つのＨＴＴＰリクエストに含めて送信するようにしている。ただし、１つのＨＴＴＰリクエストに含める送信メッセージの数に上限を設けることも考えられる。

ところで、このＨＴＴＰリクエストの送信は、送信メッセージ収集機能部４７が被管理側コマンドやコマンド応答等の読み出しを試みた場合には、読み出すデータがなく、結果的に送信すべきＳＯＡＰメッセージを生成しなかった場合にも行うものである。そして、この読み出しの試みは、定期的に行うものとする。例えば、タイマによって６０分毎に読み出すことが考えられる。
このようにするのは、上述のように、管理装置１０２から仲介装置１０１に送信したい情報があったとしても仲介装置１０１から通信を要求しない限り送信できないためである。仲介装置１０１から何も送信するデータがなかったとしても、定期的に管理装置１０２に対して通信要求を送信して、管理装置１０２から仲介装置１０１に情報を送信する機会を与えることにより、転送の必要な情報が長期間に亘って管理装置１０２に滞留してしまうことを防止できる。

なお、送信メッセージ収集機能部４７による読み出しと、それに続くＨＴＴＰリクエスト送信機能部４５ａによるＨＴＴＰリクエストの送信とを、定期的なタイミング以外に適宜行ってよいことはもちろんである。例えば、緊急に送信が必要な情報が被管理側コマンドプール４６に登録された場合に、アクションハンドラ群４３の各ハンドラ４３ａ，４４が送信メッセージ収集機能部４７にその旨を通知して読み出しを行わせるようにしてもよい。
また、ＨＴＴＰリクエスト送信機能部４５ａは、コマンド転送ハンドラ４４から渡される、画像処理装置１００に転送すべき各種ＳＯＡＰリクエストを、ＨＴＴＰリクエストに記載して画像処理装置１００に送信する機能も有する（Ｍ２）。この場合には、１つのＨＴＴＰリクエストに対して１つのＳＯＡＰリクエストを記載するようにしている。

また、ＨＴＴＰレスポンス受信機能部４５ｂは、管理装置１０２が送信してくるＨＴＴＰレスポンスを受信し、これを受信メッセージ分配機能部４８に渡す機能と（Ｌ５，Ｌ６）、画像処理装置１００が送信してくるＨＴＴＰレスポンスを受信し、これをコマンド転送ハンドラ４４に渡す機能を有する（Ｍ３，Ｍ４）。ここで、画像処理装置１００が送信してくるＨＴＴＰレスポンスは、第１の実施例の場合と同様、１つのＳＯＡＰレスポンスを記載したものであるが、管理装置１０２が送信してくるＨＴＴＰレスポンスには、被管理側コマンドに対する応答及びそのコマンドと関連付けられたコマンドＩＤと送信元情報を含むＳＯＡＰメッセージによる任意の数の受信メッセージが含まれている。

受信メッセージ分配機能部４８は、ＨＴＴＰレスポンス受信機能部４５ｂが受信したＨＴＴＰレスポンスに含まれるデータを、被管理側コマンドプール４６に記憶している適当な転送用コマンドシートに振り分けて登録する機能を有する（Ｌ７）。
具体的には、管理装置１０２から受信したＨＴＴＰレスポンスに含まれる、被管理側コマンドに対する応答を、対応する被管理側コマンドについての「出力パラメータ」として登録する。その際、そのコマンドと関連付けられたコマンドＩＤを被管理側コマンドプール４６に記憶している転送用コマンドシートのコマンドＩＤと照合して対応する被管理側コマンドを特定することができる。

そしてこのとき、ＨＴＴＰレスポンスを分割してそこに含まれる各受信メッセージを取り出し、そのデータをテーブルへの登録に必要な形式に変換するが、この変換は、ＷＳＤＬに基づいて生成される所要の変換プログラム（デシリアライザ）を実行することによって行うことができる。なお、応答を画像処理装置１００に転送する場合には、ＳＯＡＰボディ中の「結果」要素以外の部分については、ＸＭＬ文字列をそのまま出力パラメータとして登録すればよく、この部分に付いてはデシリアライザによる処理は不要である。

応答状況管理機能部４９は、被管理側コマンドプール４６に登録されているコマンドに対するコマンド応答の受信状況を管理する手段である。そして、管理装置１０２への転送後、応答を受信していないコマンドがある場合には、送信メッセージ収集機能部４７によるコマンドの読み出し周期、すなわち管理装置１０２へのアクセス周期を短くする制御を行う機能を有する。
なお、ここでは説明を省略したが、仲介装置１０１は、管理装置１０２から仲介装置１０１や画像処理装置１００へのコマンド（管理装置コマンド）に係るＳＯＡＰリクエストを、管理装置１０２から送信されてくるＨＴＴＰレスポンスに記載した状態で受信したり、そのコマンドに対する応答に係るＳＯＡＰレスポンスを、ＨＴＴＰリクエストに記載して管理装置１０２に送信したりする機能も有する。

このとき、受信した管理装置コマンドは、受信メッセージ分配機能部４８により図示を省略した管理装置コマンドプールに登録し、その旨をコマンドに応じたアクションハンドラに通知して、コマンドに係る処理を実行させるようにするとよい。そして、その結果も管理装置コマンドと対応するように管理装置コマンドプールに登録し、送信メッセージ収集機能部４７が読み出して管理装置１０２に返すようにするとよい。

次に、図３９に、管理装置１０２の機能のうち、コマンド及びコマンド応答に関する処理を行うための機能の構成を示す機能ブロック図を示す。図３９に示す各機能は、制御装置１２６内のＣＰＵが所要の制御プログラムを実行して管理装置１０２の各部の動作を制御することにより実現されるものである。
また、図３９に示す機能のうち、ＨＴＴＰサーバ機能部１４１の機能は、制御装置１２６内のＣＰＵ及び外部接続Ｉ／Ｆ１２３によって実現されるものである。アクションハンドラ群１４３，送信メッセージ収集機能部１４７，受信メッセージ分配機能部１４８，応答状況管理機能部１４９の機能は、制御装置１２６内のＣＰＵによって実現されるものである。被管理側コマンドプール１５０は、制御装置１２６内のメモリに設けられるものである。

これらの機能についてさらに詳述する。
まず、ＨＴＴＰサーバ機能部１４１は、第１の実施例の場合と同様、ＨＴＴＰリクエスト受信機能部１４１ａとＨＴＴＰレスポンス送信機能部１４１ｂとを備える。
そして、ＨＴＴＰリクエスト受信機能部１４１ａは、仲介装置１０１が送信してくるＨＴＴＰリクエストを受信し、これを受信メッセージ分配機能部１４８に渡す機能を有する（Ｎ１，Ｎ２）。ここで、仲介装置１０１が送信してくるＨＴＴＰリクエストには、被管理側コマンド及びそのコマンドと関連付けられたコマンドＩＤと送信元情報を含むＳＯＡＰメッセージが含まれている。

また、ＨＴＴＰレスポンス送信機能部１４１ｂは、送信メッセージ収集機能部１４７が生成した送信メッセージを記載したＨＴＴＰレスポンスを生成し、受信したＨＴＴＰリクエストに対する通信応答として仲介装置１０１に送信する機能を有する（Ｎ７，Ｎ８）。このとき、１つのＨＴＴＰリクエストに送信メッセージをいくつ含めてもよい。もちろん、送信元の異なるコマンドに対する応答を混在させてもよい。
そこで、ＨＴＴＰレスポンス送信機能部１４１ｂは、コマンドの種類や送信元に関わり無く、送信メッセージ収集機能部１４７が生成した全ての送信メッセージを１つのＨＴＴＰレスポンスに含めて送信するようにしている。ただし、１つのＨＴＴＰレスポンスに含める送信メッセージの数に上限を設けることも考えられる。

また、受信メッセージ分配機能部１４８は、ＨＴＴＰリクエスト受信機能部１４１ａが受信したＨＴＴＰリクエストに含まれるデータを、被管理側コマンドプール１５０に被管理側コマンドシートを設けて登録する機能を有する（Ｎ３）。
そして、被管理側コマンドプール１５０は、被管理側コマンドを、これらのコマンドに対する応答や、このコマンドの識別情報及びコマンドの送信元の情報等と関連付けて登録するプールである。

ここで、図４０に管理装置１０２の被管理側コマンドシートにおけるデータ構造の例を示す。
この図に示すように、管理装置１０２においては、被管理側コマンドシートには、「コマンドＩＤ」、「送信元情報」、「メソッド名」、「入力パラメータ」、「状態」、「コマンドの通知先」、および「出力パラメータ」のデータを記憶する領域を設けている。そして、このうち「コマンドＩＤ」、「メソッド名」、および「入力パラメータ」が被管理側コマンド（及びそこに付されたＩＤ）に該当し、「状態」及び「コマンドの通知先」が管理情報に該当する。「出力パラメータ」は、アクションハンドラ群１４３のアクションハンドラが生成するコマンド応答の内容である。この他に、シートのプロパティを記録できるようにしてもよい。

これらの各項目の内容は概ね仲介装置１０１の転送用コマンドシートの場合と同様である。ただし、「コマンドの通知先」は、そのシートに記載している被管理側コマンドを実行させるためのモジュールを示す参照情報である。また、「状態」の遷移は、「未処理」→「処理完了」→「応答済」もしくは、遅延通知を行う場合には「未処理」→「遅延未通知」→「処理待ち」→「処理中」→「処理完了」→「応答済」となる。

図４１に、仲介装置１０１から受信した被管理側コマンド（例えば図１８に示したようなＳＯＡＰリクエスト）を受信メッセージ分配機能部１４８が被管理側コマンドシートに登録する場合の、各項目に記載すべきデータの取得先を示す。
この図に示すように、「コマンドＩＤ」及び「送信元情報」は、それぞれＳＯＡＰリクエストのＳＯＡＰヘッダから抽出する。図１８に示した例では、前者は「コマンドＩＤ」タグの要素として、後者は「送信元」タグの要素として記載されている。

また、「メソッド名」及び「入力パラメータ」は、それぞれＳＯＡＰボディから抽出する。このとき、ＳＯＡＰボディのデータをテーブルへの登録に必要な形式に変換するが、この変換は、ＷＳＤＬに基づいて生成される所要の変換プログラム（デシリアライザ）を実行することによって行うことができる。
そして、「状態」には初期値として「未処理」を登録し、「コマンド実行結果の通知先」には、第１の実施例で図３１を用いて説明したようなハンドラテーブルを管理装置１０２についても用意しておいてこれを参照し、コマンドに係る処理を実行させるためのアクションハンドラを登録する。「出力パラメータ」の初期値が空であることは、上述の通りである。

図３９の説明に戻ると、アクションハンドラ群１４３は、第１の実施例の場合と同様、複数のアクションハンドラを有する。しかし、結果問い合わせハンドラ１４４が不要である点と、各ハンドラが、受信メッセージ分配機能部１４８からの通知に基づいて被管理側コマンドプール１５０の被管理側コマンドシートから必要な情報を取得して（Ｎ４）その情報に基づいて被管理側コマンドに係る処理を行い、処理の完了後、応答を同じ被管理側コマンドシートに登録する（Ｎ５）点が、第１の実施例の場合と異なる。

また、送信メッセージ収集機能部１４７は、仲介装置１０１に送信すべき、被管理側コマンドに対する応答を、コマンドＩＤ及び宛先情報とを関連付けて被管理側コマンドプール１５０から読み出し（Ｎ６）、これらから送信メッセージを生成する機能を有する。なお、応答に送信優先順位が指定されている場合には、送信メッセージ収集機能部１４７が送信優先順位の高いものから順に読み出すようにすることが考えられる。

また、送信メッセージ収集機能部１４７がコマンド応答の読み出しを試みるのは、仲介装置１０１からのＨＴＴＰリクエストを受信した場合である。これ以外の場面で読み出しを試みても、管理装置１０２からファイアウォール１０４を越えて仲介装置１０１にＨＴＴＰリクエストを送信することができないので、送信メッセージを仲介装置１０１に転送することができないためである。そして、ＨＴＴＰレスポンスの送信は、送信メッセージ収集機能部１４７がコマンド応答等の読み出しを試みた場合には、読み出すデータがなく、結果的に送信すべきＳＯＡＰメッセージを生成しなかった場合にも行うものである。
応答状況管理機能部１４９は、被管理側コマンドプール１５０に登録されているコマンドに対するコマンド応答の生成及び送信状況を管理する手段である。

なお、ここでは説明を省略したが、管理装置１０２は、仲介装置１０１や画像処理装置１００へのコマンド（管理装置コマンド）に係るＳＯＡＰリクエストを、ＨＴＴＰレスポンスに記載した状態で仲介装置１０１に送信したり、そのコマンドに対する応答に係るＳＯＡＰレスポンスを、ＨＴＴＰリクエストに記載した状態で仲介装置１０１から受信する機能も有する。
このとき、生成した管理装置コマンドは、コマンドを生成したアクションハンドラが図示を省略した管理装置コマンドプールに登録し、送信メッセージ収集機能部１４７がこれを収集して送信するようにするとよい。また、応答を受信した場合には、受信メッセージ分配機能部１４８がその応答を管理装置コマンドと対応するように管理装置コマンドプールに登録し、適当なアクションハンドラにその旨を通知して応答に応じた処理を行わせるようにするとよい。

以上のような各機能を仲介装置１０１及び管理装置１０２に設けることによっても、第１の実施例の場合と同様、仲介装置１０１に、複数の画像処理装置１００からの動作要求を受信して管理装置１０２に転送する転送手順と、管理装置１０２にアクセスした際、管理装置１０２において、それまでに転送したいずれかのコマンドに対する応答が送信可能な状態になっていた場合に、その応答を受信する受信手順と、その手順で応答を受信した場合に、その応答を、その応答と対応するコマンドの送信元に転送する第２の転送手順とを実行させることが可能になる。なお、画像処理装置１００の機能は、第１の実施例の場合と同様である。

次に、図４２にこのような機能を有する仲介装置１０１が管理装置１０２に送信するＨＴＴＰリクエストの例を示す。
このＨＴＴＰリクエストには、図４２に示すように、ボディ部としてＭＩＭＥ（Multipurpose Internet Mail Extension）に従ったマルチパートのメッセージを記載し、この各パートには、それぞれエンティティヘッダを記載すると共に、詳細な図示は省略しているが、ＳＯＡＰエンベロープを埋め込んでいる。ＳＯＡＰエンベロープの内容については、当然コマンドやコマンド応答の内容に従って異なるものである。
また、図４２の例では、ＨＴＴＰリクエストのＨＴＴＰボディには、「MIME_boundary」で区分された各要素が、独立した第１パート、第２パート、第３パート、第４パートを構成しているが、ＨＴＴＰボディに含めることのできるパート数は４つに限られない。０個を含め、いくつでもよい。
ＨＴＴＰリクエストに埋め込まれて引き渡されるＳＯＡＰエンベロープには、被管理側コマンドを記載したものと、管理装置コマンドに対する応答を記載したものとがある。

また、図４３にこのような機能を有する仲介装置１０１が管理装置１０２から受信するＨＴＴＰレスポンスの例を示す。
図４３に示すように、このＨＴＴＰレスポンスは、形式としては図４２に示したＨＴＴＰリクエストとＨＴＴＰヘッダ部が異なるのみであり、ボディ部には、ＨＴＴＰリクエストの場合と同様に、詳細な図示は省略しているが、ＭＩＭＥに従ったマルチパートのＳＯＡＰエンベロープを記載する。ＳＯＡＰエンベロープの内容については、当然コマンドやコマンド応答の内容に従って異なるものである。
ＨＴＴＰレスポンスに埋め込まれて引き渡されるＳＯＡＰエンベロープには、管理装置コマンドを記載したものと、被管理側コマンドに対する応答を記載したものとがある。

そして、以上のような形式のＨＴＴＰリクエストやＨＴＴＰレスポンスは、転送可能な１つのメッセージであり、各パートのＳＯＡＰエンベロープを、形式を変更せずに複数結合して生成することができる。また、このような形式のＨＴＴＰリクエストやＨＴＴＰレスポンスを分割して各パートのＳＯＡＰエンベロープを取り出せば、各ＳＯＡＰエンベロープ毎に個別に別のＨＴＴＰリクエストやＨＴＴＰレスポンスに記載して転送することができる。
また、各パートには、ＳＯＡＰエンベロープの他、そのパートの内容を示すエンティティヘッダも記載している。そしてこのうち、「X-SOAP-Type」ヘッダには、このパートに記載されているＳＯＡＰメッセージがＳＯＡＰリクエストであるかＳＯＡＰレスポンスであるかを示す情報を記載している。そして、あるパートがＳＯＡＰリクエストのパートであれば、そのパートの「X-SOAP-Type」ヘッダの値を「Request」とし、あるパートがＳＯＡＰレスポンスのパートであれば、そのパートの「X-SOAP-Type」ヘッダの値を「Response」としている。

また、「SOAPAction」ヘッダは、ＳＯＡＰリクエストの内容を示すものであり、この例では、「http://www.…」というＵＲＩ（Uniform Resource Identifier）によりリクエストの内容を示している。なお、「SOAPAction」ヘッダは、ＳＯＡＰメッセージがＳＯＡＰレスポンスである場合には付加しないため、メッセージの受信側において、このヘッダの有無により、各パートのＳＯＡＰメッセージがＳＯＡＰリクエストであるかＳＯＡＰレスポンスであるかを判断することもできる。

また、以上説明したような各機能を効率よく実現するためには、各装置において用意するメソッドを、第１の実施例の場合とは多少異なる一定の規約に従って作成するようにするとよい。次に、この点について説明する。
まず、具体例として、第１の実施例において表１を用いて説明したような、「用紙注文」のコマンドについて考える。この場合、コマンドの名称を「用紙注文」とし、引数（入力パラメータ）として「商品名」と「数量」を渡すとすると、各装置において例えば表３に示すような仕様のメソッドを用意するとよい。この表において、下線は、異なる種類（名称）のメソッドについても共通にしておくとよい部分を示す。

この実施例においても、画像処理装置１００と仲介装置１０１との間の通信シーケンスは第１の実施例の場合と同様であるから、用意すべきメソッドも、第１の実施例の場合と同様である。
しかし、管理装置１０２については、「用紙注文結果問い合わせ」のメソッドを設けず、「用紙注文」のみとしている。この場合において、「用紙注文」メソッドの出力パラメータには、「用紙注文」メソッドに特有の出力パラメータである「料金」が含まれる。また、管理装置１０２側で受付番号を用意しなくても、メソッドを呼び出すコマンドとそのコマンドに対する応答との対応関係は、コマンドＩＤにより容易に把握できる。従って、この実施例においては、第１の実施例の場合のような「受付番号」は不要である。

また、これらの各メソッドが従うべき規約を示すと、表４のようになる。この表中において、下線部は、コマンドの種類に応じて定めるべき部分を示し、それ以外は、コマンドの種類によらず共通とすることが好ましい部分を示す。そして、「要求名」は、表３に示した例では「用紙注文」に該当し、「要求のパラメータ」は「商品名」と「数量」に、「要求の結果」は「料金」に該当する。

なお、画像機器コマンドとして表３を用いて説明した用紙注文コマンドを管理装置１０２に対して発した場合に各装置が送受信するＳＯＡＰメッセージ（ＳＯＡＰエンベロープ）の具体例については、第１の実施例で図を図１６乃至図２８に示したものと概ね同様である。ただし、この実施例においては、結果問い合わせコマンドを使用していないため、そのコマンド及びそのコマンドに対する応答に係るメッセージが送受信されることはない。また、管理装置１０２における「用紙注文」メソッドの変更に伴って、管理装置１０２に転送した画像機器コマンドに対する応答のＳＯＡＰメッセージの形式が、第１の実施例の場合と若干異なる。

図４４に、管理装置１０２から仲介装置１０１に送信する、用紙注文コマンドに対する応答の例を示す。
この例においても、名前空間の宣言やＳＯＡＰヘッダの内容は、図１９に示した、用紙注文コマンドの受付通知に係るＳＯＡＰレスポンスの例の場合と同様である。
しかし、ＳＯＡＰボディにおいて、用紙注文コマンドに対する応答として、処理結果そのもの（「結果」及び「料金」）を返すようにしている点が、第１の実施例の場合と異なる。このような対応が可能であるのは、この実施例においては、ＨＴＴＰリクエスト／レスポンスとＳＯＡＰリクエスト／レスポンスが１対１に対応しなくてもよいようにしているので、コマンドに対して即座に応答を返さなくてもよいためである。

図４５には、用紙注文コマンドに対する応答に係る、別のＳＯＡＰレスポンスの例を示す。
この例は、管理装置１０２において、用紙注文コマンドに応じた処理が完了したものの結果がエラーである場合の例であり、ここでは、「結果」タグの内容として、注文に係る用紙の在庫がなく、注文を受け付けられなかった旨を示す「在庫なし」を記載している。
「Envelope」タグの属性やＳＯＡＰヘッダの内容は、図４４の場合と同様である。
なお、管理装置１０２において用紙注文コマンドの受付時にエラーとなった場合については、第１の実施例においても、図２０に示したように、用紙注文コマンドに対する応答にその旨を記載していたので、この実施例についても同様なフォーマットとしている。

次に、以上説明したような構成及び機能を有する仲介装置１０１において実行する処理について、図４６乃至図５０のフローチャートを用いて説明する。これらのフローチャートに示す処理は、仲介装置１０１のＣＰＵ５２が所要の制御プログラムを実行することによって行うものである。
まず、図４６に、仲介装置１０１において以上説明してきたような画像機器コマンドの転送に係る機能を実現するために行う処理のうち、ＨＴＴＰサーバ機能部４１に通信要求があった場合に実行する処理のフローチャートを示す。

この処理は、仲介装置１０１をＨＴＴＰサーバとして機能させるためのＨＴＴＰサーバスレッドの処理であり、ＣＰＵ５２が図３６に示した各部として機能して実行するものである。そして、ＣＰＵ５２は、ＨＴＴＰサーバ機能部４１に通信要求があった場合にこのスレッドを作成し、図４６のフローチャートに示す処理を開始する。また、この処理は、第１の実施例で図２９を用いて説明した処理と対応するものであり、ステップＳ１０１乃至Ｓ１０６の処理は、図２９のステップＳ１乃至Ｓ６の処理と同様なものである。

そして、ステップＳ１０４でハンドラがなく、受信した画像機器コマンドが管理装置１０２に転送すべきものであった場合の処理が、図２９の場合と異なる。
すなわちこの場合、ステップＳ１０７で、受信したＳＯＡＰリクエストをもとに転送用コマンドシートを作成し、ステップＳ１０８でその作成した転送用コマンドシートを被管理側コマンドプール４６に登録する。そして、ステップＳ１０９で、コマンドの受付通知に係るＳＯＡＰレスポンス（例えば図１７に示したもの）を記載したＨＴＴＰレスポンスを画像処理装置１００に送信する。

以上の処理により、仲介装置１０１は、画像処理装置１００からのコマンドを受け付け、それが自身で処理するコマンドであれば処理を行って応答を返し、自身で処理しない（できない）コマンドであれば受付通知を返した上で管理装置１０２への転送を準備することができる。また、以上の処理において、ステップＳ１０９が受信通知手順の処理であり、この処理において、ＣＰＵ５２が受信通知手段として機能する。

次に、図４７及び図４８に、仲介装置１０１が受信した画像機器コマンドを管理装置１０２へ転送する機能を実現するために実行する転送スレッドの処理のフローチャートを示す。この処理は、ＣＰＵ５２が図３６に示した各部、主として送信メッセージ収集機能部４７及び受信メッセージ分配機能部４８として機能して実行するものである。そして、ＣＰＵ５２は、定期的に、管理装置１０２にアクセスするタイミングになると、図４７のフローチャートに示す処理を開始する。

そして、この処理においては、仲介装置１０１のＣＰＵ５２はまず、ステップＳ１１１で、被管理側コマンドプール４６から、「状態」が「未送信」である被管理側コマンドシートに登録されているコマンドとコマンドＩＤとを収集する。「未送信」という「状態」は、コマンドが被管理側コマンドプール４６に登録された後、まだ管理装置１０２に送信されていないことを示すものであるので、これを基準に管理装置１０２に送信すべきコマンドを抽出できる。また、この時、画像機器コマンドと仲介装置コマンドとは区別せずに取り扱う。

その後、ステップＳ１１１で収集した全ての被管理側コマンドを順次対象として、ステップＳ１１２乃至Ｓ１１４の処理を繰り返す。この部分の処理においては、まずステップＳ１１２で、対象の被管理側コマンドと、そのコマンドＩＤ及び送信元情報とを、これらの情報がそれぞれＳＯＡＰボディとＳＯＡＰヘッダとに含まれるＸＭＬ文書（ＳＯＡＰエンベロープ）に変換し、ステップＳ１１３でこれにエンティティヘッダを付加して対象の被管理側コマンドに関するパートを生成する。そして、ステップＳ１１４で、対象の被管理側コマンドを記載していた被管理側コマンドシートの「状態」を「応答待ち」に変更する。「応答待ち」という「状態」は、コマンドを管理装置１０２に送信済であり、応答はまだ受信していないことを示すものである。

これらが全て完了した後、ＣＰＵ５２は、ステップＳ１１５で、ステップＳ１１３で生成した各パートをマージし、図４２に示したようなマルチパートのＨＴＴＰリクエストを生成して、ＨＴＴＰリクエスト送信機能部４５ａの機能により管理装置１０２に送信する。
なお、管理装置コマンドプールに管理装置コマンドに対する未送信の応答がある場合には、その応答のパートも作成して、同じＨＴＴＰリクエストに記載して管理装置１０２に送信するようにするとよい。また、ステップＳ１１４で行った「状態」の変更は、実際にこの送信が終了してから行うようにしてもよい。このようにすることにより、通信エラーが発生しても、送信しようとしていたコマンドを再度送信の対象とすることができるので、システムの信頼性が向上する。

以上でＨＴＴＰリクエストの送信に関する処理を終了し、図４８の処理に進む。
そして、ステップＳ１１６でＨＴＴＰレスポンス受信機能部４５ｂとしての機能により管理装置１０２からＨＴＴＰレスポンスを受信し、ステップＳ１１７でそのＨＴＴＰレスポンスのＨＴＴＰボディを解析してパートに分割する。ここで、各パートへの分割は、「MIME_boundary」で区分された要素に分割することであり、またここで全てのパートに関して分割する。そして、ここで得られた各パートについて、以下のステップＳ１１８乃至Ｓ１２７の処理を繰り返す。ここでは、各パートは被管理側コマンドに対する応答のパートであるとする。

この場合、まずステップＳ１１８で対象パートのＳＯＡＰヘッダを解析し、ステップＳ１１９で、ＳＯＡＰヘッダ中のコマンドＩＤをキーに、被管理側コマンドプール４６から、対象パートの応答に対応する転送用コマンドシートを検索する。
そして、ステップＳ１２０で、発見したコマンドシートに記載されているコマンドが転送用のコマンド、すなわち画像処理装置１００から受信して管理装置１０２に転送した画像機器コマンドであるか否か判断する。そして、ＹＥＳであれば、ステップＳ１２１で対象パートのＳＯＡＰボディのうち「結果」要素を抽出してステップＳ１２２でこの内容を抽出した転送用コマンドシートの「結果」の項目に登録する。そして、ステップＳ１２３ではＳＯＡＰボディの「結果」以外の部分を、ＸＭＬ文字列のまま「その他の出力パラメータ」の項目に登録する。すなわち、この場合には、応答に応じた処理を自身では行わず、応答を他の装置に転送するので、応答の内容全体を解釈する必要はないのである。

一方、ステップＳ１２０でＮＯであれば、ステップＳ１２６で対象パートのＳＯＡＰボディ全体を解析し、ステップＳ１２７でこの内容を抽出した転送用コマンドシートの「出力パラメータ」の項目に登録する。
そして、ステップＳ１２３又はＳ１２７の後は、ステップＳ１２４に進み、応答を登録した転送用コマンドシートの「状態」を「応答受信済」に変更する。「応答受信済」という「状態」は、コマンドに対する応答を管理装置１０２から受信済であることを示すものである。

その後、応答を受信した旨を、応答を登録した転送用コマンドシートの「コマンド実行結果の通知先」に記載されたハンドラに通知し、そのハンドラが応答の受信に応じた処理を行う。このとき、コマンドが画像機器コマンドであれば、通知の対象はコマンド転送ハンドラ４４であり、応答の受信に応じた処理は、図５０に示す結果通知スレッドの処理である。
ステップＳ１１７で得られた全てのパートについて以上の処理が終了すると、転送スレッドの処理は終了する。
なお、受信したＨＴＴＰレスポンスに管理装置コマンドのパートがあった場合には、管理装置コマンドシートを作成してこのコマンドを管理装置コマンドプールに登録し、「コマンドの通知先」に記載されたハンドラに通知して、コマンドに係る処理を実行させるようにするとよい。

以上の処理により、画像処理装置１００から受信した画像機器コマンドを、管理装置１０２に転送すると共に、管理装置１０２に転送した画像機器コマンドの実行結果を受信することができる。そして、管理装置１０２において、それまでに転送した複数のコマンドに対する応答がそれぞれ送信可能な状態になっていた場合に、それらの動作応答を複数一括して受信することができる。また、ＨＴＴＰサーバスレッドの処理とこの転送スレッドの処理のうち図４７に示した部分の処理が、転送手順の処理であり、この処理において、ＣＰＵ５２が転送手段として機能する。また、図４８に示した部分の処理は、受信手順の処理であり、この処理において、ＣＰＵ５２が受信手段として機能する。

次に、図４９に、仲介装置１０１が管理装置１０２へのアクセスタイミングを設定するための転送タイミング設定スレッドの処理のフローチャートを示す。この処理は、ＣＰＵ５２が図３６に示した応答状況管理機能部４９として機能して実行するものである。
ＣＰＵ５２は、適当なタイミングで図４９のフローチャートに示す処理を開始し、管理装置１０２へのアクセスタイミングの管理を開始する。そして、ステップＳ３０１で、管理装置１０２からのＨＴＴＰレスポンスの受信イベントがあるまで待機する。そして、このイベントがあるとステップＳ３０２に進んで「状態」が「処理待ち」の転送用コマンドシートが被管理側コマンドプール４６に記憶されているか否か判断する。すなわち、管理装置１０２に送信済みで、かつ応答を受信していない被管理側コマンドがあるか否か判断する。

そして、あればステップＳ３０３で転送スレッドの実行間隔を短い時間に設定して管理装置１０２へのアクセス間隔を短縮し、なければステップＳ３０４で実行間隔を長い時間に設定してアクセス間隔を長くする。その後、ステップＳ３０１に戻って処理を繰り返す。なお、ステップＳ３０２の判断は、ＨＴＴＰレスポンスに記載した状態で受信した受信メッセージの分配が完了してから行うようにするとよい。

以上のような処理を行うことにより、管理装置１０２に被管理側コマンドを送信した後、管理装置１０２に送信した全ての被管理側コマンドに対する応答を受信するまでは、それ以外の期間よりも短い間隔で前記サーバにアクセスするようにすることができる。このようにすることにより、通常は、ネットワークトラフィックの低減を考慮して管理装置１０２へのアクセス間隔を１時間に１回等ある程度長めの期間に設定してシステムを運用しながら、コマンドを管理装置１０２に送信した後は、なるべく早いタイミングで応答を受け取れるよう、アクセス間隔を短縮するといった対応が可能となる。従って、通信効率をある程度維持しながら、ネットワークのトラフィックを削減することができる。

なお、図４９に示した条件よりも細かくアクセス間隔を制御できるようにしてもよい。また例えば、極端に処理に時間がかかるコマンドを管理装置１０２に送信した場合でも応答が得られるまで短い間隔でアクセスを繰り返すとすると、無駄に通信トラフィックを増加させることになってしまう。そこで、このような場合には、管理装置１０２が遅延通知を返してコマンドの処理に時間がかかる旨を通知するようにするとよい。そして、仲介装置１０１側では、送信済みで応答を受け取っていない被管理側コマンドがある場合でも、それらについて全て遅延通知を受け取っている場合には、管理装置１０２へのアクセス間隔を長くするように制御することが考えられる。

次に、図５０に、仲介装置１０１が画像処理装置１００に画像機器コマンドの実行結果を通知する機能を実現するために実行する結果通知スレッドの処理のフローチャートを示す。この処理は、ＣＰＵ５２が図３６に示した各部、主としてコマンド転送ハンドラ４４として機能して実行するものである。そして、ＣＰＵ５２は、図４８のステップＳ１２５においてコマンド転送ハンドラ４４に画像機器コマンドに対する応答が被管理側コマンドプール４６に登録された旨の通知がなされた場合に、このスレッドを作成し、図５０のフローチャートに示す処理を開始する。

なお、この処理の内容は、ステップＳ１３１で、処理結果を画像処理装置１００に通知すべき画像機器コマンドについて、転送用コマンドシートの内容を読み出し、ステップＳ１３３又はＳ１３６でその内容をもとに結果通知のＳＯＡＰリクエストを生成する点以外は、図３３のステップＳ３６乃至Ｓ４２の内容とほぼ同様である。
従って、詳細な説明は省略するが、この結果問い合わせスレッドの処理を行うことにより、仲介装置１０１が画像処理装置１００に画像機器コマンドの実行結果を通知することができる。この処理において、ステップＳ１３４及びＳ１３７が第２の転送手順の処理であり、ここではＣＰＵ５２が第２の転送手段として機能する。

なお、以上説明した各スレッドは、処理終了時に消滅させてしまう必要はなく、処理終了後も、新たな開始トリガーがあるまで待機状態にしておくようにしてもよい。その他、第１の実施例で説明したような変形を適宜適用可能である。ただし、転送スレッドについては、管理装置１０２へのアクセス間隔の管理の便宜のため、複数スレッドを同時に設けないことが好ましい。

次に、以上説明したような構成及び機能を有する管理装置１０２において実行する処理について、図５１乃至図５４のフローチャートを用いて説明する。これらのフローチャートに示す処理は、制御装置１２６中のＣＰＵが所要の制御プログラムを実行することによって行うものである。
まず、図５１及び図５２に、仲介装置１０１との間のＳＯＡＰメッセージの送受信に係る機能を実現するために行う処理のフローチャートを示す。

この処理は、制御装置１２６中のＣＰＵが図３９に示した各部として機能して実行するものである。そして、制御装置１２６中のＣＰＵは、仲介装置１０１からＨＴＴＰサーバ機能部１４１に通信要求があった場合にこのフローチャートに示す処理を開始する。
そして、この処理においては、まずステップＳ２０１で、仲介装置１０１からＨＴＴＰリクエストを受信する。そして、ステップＳ２０２で、受信したＨＴＴＰリクエストのＨＴＴＰボディを各パートに分割する。ここで、各パートへの分割は、「MIME_boundary」で区分された要素に分割することであり、またここで全てのパートに関して分割する。

そしてその後、分割して得た全てのパートを順に対象として、ステップＳ２０３及びＳ２０４の処理を繰り返す。そして、この部分の処理においては、まずステップＳ２０３で、対象パートのＳＯＡＰリクエストをもとに図４１を用いて説明したように被管理側コマンドシートを作成し、ステップＳ２０４でその作成した被管理側コマンドシートを被管理側コマンドプール１５０に登録する。これらの処理は、受信メッセージ分配機能部１４８の機能によるものである。
なお、受信したＨＴＴＰリクエストに管理装置コマンドに対する応答のパートがあった場合には、管理装置コマンドプールからその応答と対応するコマンドの管理装置コマンドシートを抽出し、そのコマンドシートに応答の内容を登録すると共に、「コマンド実行結果の通知先」に記載されたハンドラに通知して、受信したコマンド応答に係る処理を実行させるようにするとよい。

全てのパートについてステップＳ２０３及びＳ２０４の処理が終了すると、処理は図５２のステップＳ２０５に進み、被管理側コマンドプール１５０から、「状態」が「処理完了」である被管理側コマンドシートに登録されているコマンドとコマンドＩＤとを収集する。「処理完了」という「状態」は、コマンドに係る処理が完了し、応答が被管理側コマンドプール１５０に登録された後、まだ仲介装置１０１に送信されていないことを示すものであるので、これを基準に仲介装置１０１に送信すべき応答を抽出できる。

そして、ここで収集した全てのコマンドについて、ステップＳ２０６乃至Ｓ２０８の処理を繰り返す。この部分の処理においては、まずステップＳ２０６で、対象の被管理側コマンドに係る出力パラメータ（応答）と、そのコマンドＩＤ及び送信元情報とを、これらの情報がそれぞれＳＯＡＰボディとＳＯＡＰヘッダとに含まれるＸＭＬ文書（ＳＯＡＰエンベロープ）に変換し、ステップＳ２０７でこれにエンティティヘッダを付加して対象のコマンドに対する応答に関するパートを生成する。そして、ステップＳ２０８で、対象の被管理側コマンドを記載していた被管理側コマンドシートの「状態」を「応答済」に変更する。「応答済」という「状態」は、コマンド応答を仲介装置１０１に送信済であることを示すものである。

これらが全て完了した後、制御装置１２６中のＣＰＵは、ステップＳ２０９で、ステップＳ２０７で生成した各パートをマージし、図４３に示したようなマルチパートのＨＴＴＰレスポンスを生成して、ステップＳ２１０でＨＴＴＰレスポンス送信機能部１４１ｂとしての機能によりそのＨＴＴＰレスポンスを仲介装置１０１に送信して処理を終了する。
なお、管理装置コマンドプールに未送信の管理装置コマンドがある場合には、そのコマンドのパートも作成して、同じＨＴＴＰリクエストに記載して管理装置１０２に送信するようにするとよい。また、ステップＳ２０８で行った「状態」の変更は、実際にこの送信が終了してから行うようにしてもよい。このようにすることにより、通信エラーが発生しても、送信しようとしていたコマンド応答を再度送信の対象とすることができるので、システムの信頼性が向上する。

以上の処理により、管理装置１０２において、仲介装置１０１からアクセスがあった場合に、その仲介装置１０１から受信したいずれかのコマンドに対する応答が送信可能な状態であれば、その応答を仲介装置１０１に送信することができる。またステップＳ２０５乃至Ｓ２１０の処理が送信手順の処理であり、この部分の処理において、制御装置１２６中のＣＰＵが送信手段として機能する。

次に、図５３に、管理装置１０２における被管理側コマンドの実行に関する処理のフローチャートを示す。
被管理側コマンドの実行に関する処理としては、まず、制御装置１２６中のＣＰＵが、図５３のフローチャートに示す処理を、図５１に示したステップＳ２０４の処理の後に、すなわち被管理側コマンドを被管理側コマンドプール１５０に登録した直後に行うことが考えられる。

そして、この処理においては、まずステップＳ２２１で、登録した被管理側コマンドについての被管理側コマンドシートの「コマンドの通知先」の情報に基づいて被管理側ハンドラを呼び出し、「入力パラメータ」のデータを渡して被管理側コマンドに関する処理を実行させる。なお、この被管理側コマンドに関する処理は、このフローチャートには示していないが、制御装置１２６中のＣＰＵが別途実行することになる。
そして、これが完了すると、ステップＳ２２２で実行結果を被管理側コマンドシートの「出力パラメータ」の項目に登録すると共に、ステップＳ２２３で被管理側コマンドシートの「状態」を「処理完了」に変更し、処理が完了したことを示して、もとの図５１の処理に戻る。
以上の処理を行うことにより、仲介装置１０１から被管理側コマンドを受信した場合に、そのコマンドに係る動作を実行し、その結果をコマンド応答として生成して仲介装置１０１に送信可能な状態にすることができる。

また、図５４に、被管理側コマンドの実行に関する処理の別の例のフローチャートを示す。この処理は、図５１に示した処理とは独立に行うものであり、この処理を用いる場合、制御装置１２６中のＣＰＵは適当なタイミングで図５４のフローチャートに示す処理を開始する。

そして、この処理においては、まずステップＳＸ１で、被管理側コマンドプール１５０に「状態」が「処理待ち」である被管理側コマンドシートがあるか否か判断し、なければこのような被管理側コマンドシートが追加されるまで待機する。そして、このような被管理側コマンドシートを発見した場合、ステップＳＸ２でその１つを処理対象とし、その被管理側コマンドシートの「状態」を「処理中」に変更する。
その後、図５３の場合と同様なステップＳ２２１乃至Ｓ２２３の処理を行って処理対象の被管理側コマンドシートに記載された被管理側コマンドを実行し、これが完了するとステップＳＸ１に戻って処理を繰り返す。

以上の処理は、複数のスレッド（例えば４スレッド）で同時に行うようにしてもよい。処理対象となった被管理側コマンドシートの「状態」は、「処理待ち」ではないため、複数のスレッドで同時に処理を行っても、１つの被管理側コマンドシートを重複して処理対象としてしまうことはない。

以上のような処理を行うようにすれば、任意のタイミングで被管理側コマンドを実行することができるので、実行に時間のかかるコマンドがあった場合でも、以後の処理が滞ることがない。そして、実行の終了したものから順に、その結果をコマンド応答として仲介装置１０１に送信可能な状態にすることができる。
以上で、管理装置１０２において実行する、各コマンド及びコマンド応答の転送に関する処理の説明を終了する。
なお、画像処理装置１００において実行する、各コマンド及びコマンド応答の転送に関する処理は、第１の実施例の場合と同様であるから、説明を省略する。

ここで、図５５に、以上説明してきた遠隔管理システムにおいて、画像処理装置１００が管理装置１０２に対する画像機器コマンドを生成してからそのコマンドに対する応答を受け取るまでに各装置において行われる一連の処理を示す。
この図に示す処理の各々は、既に説明した処理のいずれかであるので、詳細な説明は省略するが、以上説明してきた遠隔管理システムにおいては、このような処理を行うことにより、画像処理装置１００と管理装置１０２との間のコマンド及びコマンド応答の送受信を、仲介装置１０１によって仲介して行うことができる。

また、図５６に、以上説明してきた遠隔管理システムにおいて、画像処理装置１００が管理装置１０２に対する画像機器コマンドを生成してからそのコマンドに対する応答を受け取るまでの各装置間における通信シーケンス例を示す。
この例においては、まず画像処理装置１００が、管理装置１０２に対する画像機器コマンドを生成し、これをＨＴＴＰリクエストｘに記載して仲介装置１０１に送信している。そして、仲介装置１０１は、ＨＴＴＰサーバスレッドの処理により、これが自身で実行すべきものでないと判断し、転送用コマンドシートに登録すると共に、ＨＴＴＰリクエストｘに対するＨＴＴＰレスポンスに、受信通知を記載して画像処理装置１００に返す。

一方、仲介装置１０１は、これとは別に、転送スレッドの処理により、管理装置１０２に転送すべき画像機器コマンドと、自身が生成したコマンドとを、同じＨＴＴＰリクエストに記載して管理装置１０２に転送する。ここでは、まずＨＴＴＰリクエストＸがこの転送に係るＨＴＴＰリクエストに該当し、画像処理装置１００から受信した画像機器コマンドＡと、自身で生成した仲介装置コマンドＢとをＨＴＴＰリクエストＸに記載して管理装置１０２に転送している。

そして、管理装置は、受信したコマンドを被管理側コマンドシートに登録し、実行結果も同じシートに登録するが、応答がすぐに生成できる場合には、コマンドが記載されていたＨＴＴＰリクエストに対するＨＴＴＰレスポンスに、応答を記載して仲介装置１０１に送信することができる。ここでは仲介装置コマンドＢに対する応答を、ＨＴＴＰレスポンスＸに記載して送信している。
しかし、すぐに応答を生成できないコマンドについては、応答の生成後、仲介装置１０１からＨＴＴＰリクエストを受信した際にこれを仲介装置１０１に送信するようにしている。

一方、仲介装置１０１は、特に管理装置１０２に送信すべき情報がなくても、定期的に管理装置１０２にＨＴＴＰリクエストを送信し、管理装置１０２から仲介装置１０１に送信すべき情報を受け取ることができるようにしている。
ここでは、ＨＴＴＰリクエストＹがこれに該当し、この時点までに管理装置１０２で画像機器コマンドＡに対する応答が生成されていれば、管理装置１０２は、このＨＴＴＰリクエストＹに対するＨＴＴＰレスポンスＹに、画像機器コマンドＡに対する応答を記載して仲介装置１０１に返す。

この場合において、送信するＨＴＴＰリクエストＹに何らかのコマンドが記載されていたとしても、画像機器コマンドＡに対する応答の送信は同様に行われる。すなわち、仲介装置１０１からのコマンドの送信と、管理装置１０２からのコマンド応答の送信は、基本的には独立して行われ、仲介装置１０１から管理装置１０２に対して何らかの問い合わせ（ここではＨＴＴＰリクエストの送信）をした際に、管理装置１０２側で生成されているコマンド応答があれば、これを受け取るという処理を行うようにしている。もちろん、複数のコマンドについて応答が生成されていれば、それらを全て一括して受け取ることができる。

そして、仲介装置１０１は、管理装置１０２から、画像機器コマンドに対する応答を受信すると、結果通知スレッドの処理により、応答に記載された処理結果を、コマンド送信元の画像処理装置１００に通知するための結果通知を生成し、画像処理装置１００に対するＨＴＴＰリクエストｙに記載して送信する。そして、これを受け取った画像処理装置１００は、受信通知を、そのＨＴＴＰリクエストに対する応答であるＨＴＴＰレスポンスｙに記載して仲介装置１０１に送信し、以上で画像機器コマンドＡに関する一連の通信シーケンスは終了する。

以上説明してきたように、この実施例の遠隔管理システムにおいても、第１の実施例の場合と同様、ファイアウォール１０４の内側に設けられる画像処理装置１００がファイアウォール１０４の外側にある管理装置１０２にコマンドを送信してそのコマンドに対する応答を受信する場合において、管理装置１０２においてコマンドに対応する処理に時間を要する場合でも、管理装置１０２から画像処理装置１００へのコマンド応答の転送のために必要な通信トラフィックを抑えながら、コマンドをタイムアウトさせずに済ませられるようにすることができる。
またその他、第１の実施形態の場合と同様な効果を有する。さらに、複数のコマンドを１つのＨＴＴＰリクエストを記載して送信したり、複数の応答を１つのＨＴＴＰレスポンスに記載して受信したりすることができるので、１つずつばらばらのＨＴＴＰメッセージに記載する場合に比べ、通信のオーバーヘッドを低減すると共に、送信すべきデータ量も低減し、第１の実施形態の場合よりも通信の負荷を低減することができる。

〔変形例：図５７〕
ここで、上述した実施形態に適用する変形例について説明する。
上述した実施形態においては、ＲＰＣを実現する上位プロトコルとしてＳＯＡＰを採用し、アプリケーションは直接プールを操作してＲＰＣを実現しているが、アプリケーションとプールとの間にＣＯＲＢＡ（Common Object Request Broker Architecture）やＪＡＶＡ（登録商標）ＲＭＩ（Remote Method Invocation）とのブリッジ（メッセージ変換機能）を備えることによってアプリケーションの開発効率をさらに向上させてもよい。
すなわち、上述した各実施形態において、各ノード間でのコマンド及びこれに対するコマンド応答のやり取りは、ＸＭＬで記述されたＳＯＡＰメッセージにより行うこととしているが、これに限るものでなく、他の形式で記述されていてもよい。

また、上述した実施形態において、被管理装置１０や画像処理装置１００が、仲介装置１０１と管理装置１０２との間でコマンドやコマンド応答の送受信に使用するプロトコル（ここではＳＯＡＰ）に対応していない場合、仲介装置１０１がデータ形式を変換し、被管理装置１０や画像処理装置１００が対応する形式でこれらの装置との間でコマンドやコマンド応答の送受信を行うようにしてもよい。例えば、画像処理装置１００がＳＮＭＰ（Simple Network Management Protocol）にしか対応していない場合、仲介装置１０１が画像機器コマンドをＭＩＢ（Management Information Base）形式に変換して転送することが考えられる。
また、送受信するコマンドやコマンド応答の情報量に制限を設けても構わない。特に、受信するコマンドの情報量を制限するようにすると、受信側がメモリ容量の限られた装置である場合にメモリの使用量を抑えることができる。

また、上述した第２の実施例において、ＳＯＡＰ標準のプロトコルだけでなく、ＳＯＡＰとＭＩＭＥマルチパートを組み合わせた独自のプロトコルをもこれに加えて採用することにより、ＨＴＴＰリクエスト、或いはＨＴＴＰレスポンスに含まれるＳＯＡＰエンベロープを全く独立したものとして扱うこととしているが、ＳＯＡＰの関連仕様として定義されたＳＯＡＰアタッチメントによって、ＨＴＴＰレスポンスに含まれる第１パートのＳＯＡＰエンベロープに、第２パート以降のＳＯＡＰエンベロープへのリンクを埋め込んでこれらを関連付けて引き渡す構成にしてもよい。ＳＭＴＰを用いる電子メールの場合にも同様である。

更に、ＳＯＡＰ等の上位プロトコルの下位に位置するデータ通信のプロトコルとして、ここではＨＴＴＰを採用した例について説明したが、この下位プロトコルについても、ＳＭＴＰやＦＴＰ（File Transfer Protocol）等の他のプロトコルを採用してもよい。
また、ここでは仲介装置１０１と管理装置１０２とをインターネット１０３を介して接続した例について説明したが、これ以外にも、有線、無線を問わず、ネットワーク通信が可能な各種通信経路を用いることができる。仲介装置１０１、被管理仲介装置１１０、被管理装置１０の相互間においても、ＬＡＮ以外の各種通信経路を用いることもできる。

さらにまた、通信システムの構成についても、以上説明したものに限られることはなく、遠隔管理システム以外の通信システムにもこの発明を適用できることは、言うまでもない。管理対象の装置も、画像処理装置に限られることはない。
例えば、図１に示した遠隔管理システムにおいて、種々の電子装置に通信機能を設けた通信装置を被管理装置とし、図５７に示すような遠隔管理システムを構成することが考えられる。この図においては、被管理装置の例として、テレビ受像機１２ａや冷蔵庫１２ｂのようなネットワーク家電、医療機器１２ｃ，自動販売機１２ｄ，計量システム１２ｅ，空調システム１２ｆ、自動車１３ａや航空機１３ｂを挙げている。

また、自動車１３ａや航空機１３ｂのように、広範囲を移動する装置においても、自動車や航空機そのものに仲介装置１０１やファイアウォール１０４の機能を設けて設置環境として捉え、例えば自動車１３ａに搭載している制御用コンピュータ、ナビゲーションシステムあるいはＩＴＳ（Intelligent Transport System）端末等を、クライアントとして取り扱うことも可能である。
さらに、通信システムの構成として、クライアントが遅延通知等の機能に対応しているものであってもよいし、サーバがクライアントや仲介装置を管理する機能を有しない装置であってもよい。
また、仲介装置を多段にカスケード接続する構成にも対応可能である。あるいは、仲介装置がいずれかのクライアントと一体として構成されていてもよい。

また、この発明によるプログラムは、コンピュータに、ファイアウォールの内側に設けられ、そのファイアウォールの外側に設けられるサーバと、そのファイアウォールの内側に設けられる複数のクライアントとの間の通信を仲介する仲介装置を制御させるためのプログラムであり、このようなプログラムをコンピュータに実行させることにより、上述したような効果を得ることができる。

このようなプログラムは、はじめからコンピュータに備えるＲＯＭあるいはＨＤＤ等の記憶手段に格納しておいてもよいが、記録媒体であるＣＤ−ＲＯＭあるいはフレキシブルディスク，ＳＲＡＭ，ＥＥＰＲＯＭ，メモリカード等の不揮発性記録媒体（メモリ）に記録して提供することもできる。そのメモリに記録されたプログラムをコンピュータにインストールしてＣＰＵに実行させるか、ＣＰＵにそのメモリからこのプログラムを読み出して実行させることにより、上述した各手順を実行させることができる。
さらに、ネットワークに接続され、プログラムを記録した記録媒体を備える外部機器あるいはプログラムを記憶手段に記憶した外部機器からダウンロードして実行させることも可能である。

以上説明してきたように、この発明の仲介装置、通信システム、通信方法、プログラム又は記録媒体によれば、ファイアウォールの内側に設けられるクライアントがファイアウォールの外側にあるサーバに動作要求を送信してその動作要求に対する動作応答を受信する場合において、サーバにおいて動作要求に対応する処理に時間を要する場合でも、サーバからクライアントへの動作応答の転送のために必要な通信トラフィックを抑えながら、動作要求をタイムアウトさせずに済ませられるようにすることができる。
従って、この発明を、このような通信システム又はこのような通信システムにおいて通信を仲介する仲介装置に適用することにより、安定した通信が可能でありながら通信の負荷が小さい通信システムを構成することができる。

この発明の仲介装置を用いて構成した通信システムの実施形態の構成を示すブロック図である。 図１に示した通信システムにおける動作要求と動作応答の関係を示す図である。 この発明の第１の実施例である遠隔管理システムの構成を示すブロック図である。 図３に示した遠隔管理システムにおける動作要求と動作応答の関係を示す図である。 同じく画像処理装置と仲介装置との間の通信シーケンスの例を示す図である。 同じく仲介装置と管理装置との間の通信シーケンスの例を示す図である。 その別の例を示す図である。 図３に示した管理装置のハードウェア構成の概略を示すブロック図である。 同じく画像処理装置のハードウェア構成の概略を示すブロック図である。 同じく仲介装置のハードウェア構成の概略を示すブロック図である。

図３に示した仲介装置の機能のうち、コマンド及びコマンド応答に関する処理を行うための機能の構成を示す機能ブロック図である。 同じく画像処理装置の機能のうち、コマンド及びコマンド応答に関する処理を行うための機能の構成を示す機能ブロック図である。 同じく管理装置の機能のうち、コマンド及びコマンド応答に関する処理を行うための機能の構成を示す機能ブロック図である。 同じく仲介装置が管理装置や画像処理装置に送信するＨＴＴＰリクエストの例を示す図である。 同じく仲介装置が管理装置や画像処理装置から受信するＨＴＴＰレスポンスの例を示す図である。 同じく画像処理装置から仲介装置に送信する用紙注文コマンドに係るＳＯＡＰリクエストの例を示す図である。 同じく、仲介装置から画像処理装置に送信する、用紙注文コマンドの受付通知に係るＳＯＡＰレスポンスの例を示す図である。 同じく、仲介装置から管理装置に送信する用紙注文コマンドに係るＳＯＡＰリクエストの例を示す図である。 同じく、管理装置から仲介装置に送信する、用紙注文コマンドの受付通知に係るＳＯＡＰレスポンスの例を示す図である。 その別の例を示す図である。

図３に示した仲介装置から管理装置に送信する、用紙注文結果問い合わせコマンドに係るＳＯＡＰリクエストの例を示す図である。 同じく、管理装置から仲介装置に送信する、用紙注文結果問い合わせコマンドに対する応答に係るＳＯＡＰレスポンスの例を示す図である。 その別の例を示す図である。 そのさらに別の例を示す図である。 図３に示した仲介装置から画像処理装置に送信する用紙注文結果通知コマンドに係るＳＯＡＰリクエストの例を示す図である。 その別の例を示す図である。 そのさらに別の例を示す図である。 用紙注文結果通知コマンドに対する応答に係るＳＯＡＰレスポンスの例を示す図である。 図３に示した仲介装置が実行するＨＴＴＰサーバスレッドの処理を示すフローチャートである。 コマンドに係る名前空間ＵＲＩとメソッド名について説明するための図である。

図３に示した仲介装置におけるハンドラテーブルの例を示す図である。 同じく仲介装置が実行する転送スレッドの処理を示すフローチャートである。 同じく結果問い合わせスレッドの処理を示すフローチャートである。 図３に示した仲介装置に図２９，３２及び３３に示した各処理を実行させて画像処理装置からの管理装置に対するコマンドの転送を仲介させる場合の処理シーケンスを示す図である。 この発明の第２の実施例の遠隔管理システムにおける、仲介装置と管理装置との間の通信シーケンスの例を示す図である。 その遠隔管理システムにおける仲介装置の機能のうち、コマンド及びコマンド応答に関する処理を行うための機能の構成を示す機能ブロック図である。 その仲介装置における転送用コマンドシートの構成を示す図である。 その仲介装置が画像処理装置から受信した画像機器コマンドを転送用コマンドシートに登録する場合の、各項目に記載すべきデータの取得先について説明するための図である。 この発明の第２の実施例の遠隔管理システムにおける管理装置の機能のうち、コマンド及びコマンド応答に関する処理を行うための機能の構成を示す機能ブロック図である。 その管理装置における被管理側コマンドシートの構成を示す図である。

その管理装置が仲介装置から受信した被管理側コマンドを被管理側コマンドシートに登録する場合の、各項目に記載すべきデータの取得先について説明するための図である。 図３６に示した仲介装置が図３９に示した管理装置に送信するＨＴＴＰリクエストの例を示す図である。 同じく仲介装置が管理装置から受信するＨＴＴＰレスポンスの例を示す図である。 同じく、管理装置から仲介装置に送信する、用紙注文コマンドに対する応答の例を示す図である。 その別の例を示す図である。 図３６に示した仲介装置が実行するＨＴＴＰサーバスレッドの処理を示すフローチャートである。 同じく仲介装置が実行する転送スレッドの処理の一部を示すフローチャートである。 その続きの処理を示すフローチャートである。 図３６に示した仲介装置が実行する転送タイミング設定スレッドの処理を示すフローチャートである。 同じく仲介装置が実行する結果通知スレッドの処理を示すフローチャートである。

図３９に示した管理装置が仲介装置との間のＳＯＡＰメッセージの送受信に係る機能を実現するために行う処理の一部を示すフローチャートである。 その続きの処理を示すフローチャートである。 図３９に示した管理装置が実行する、被管理側コマンドの実行に関する処理を示すフローチャートである。 その別の例を示すフローチャートである。 この発明の第２の実施例の遠隔管理システムにおいて、画像処理装置が管理装置に対する画像機器コマンドを生成してからそのコマンドに対する応答を受け取るまでに各装置において行われる一連の処理を示すフローチャートである。 同じく、画像処理装置が管理装置に対する画像機器コマンドを生成してからそのコマンドに対する応答を受け取るまでの各装置間における通信シーケンス例を示す図である。 図１に示した通信システムの別の構成例を示す図である。

符号の説明

１０：被管理装置
４１，１４１，２４１：ＨＴＴＰサーバ機能部
４１ａ，１４１ａ，２４１ａ：ＨＴＴＰリクエスト受信機能部
４１ｂ，１４１ｂ，２４１ｂ：ＨＴＴＰレスポンス送信機能部
４２，１４２，２４２：コマンド分配機能部
４３，１４３，２４３：アクションハンドラ群
４３ａ，１４３ａ，２４３ａ：アクションハンドラ
４４：コマンド転送ハンドラ
４５，２４５：ＨＴＴＰクライアント機能部
４５ａ，２４５ａ：ＨＴＴＰリクエスト送信機能部
４５ｂ，２４５ｂ：ＨＴＴＰレスポンス受信機能部
４７，１４７：送信メッセージ収集機能部
４８，１４８：受信メッセージ分配機能部
４９，１４９：応答状況管理機能部
５２，２０１：ＣＰＵ ５７，２０６：ＰＨＹ
１００：画像処理装置 １０１：仲介装置
１０２：管理装置 １０３：インターネット
１０４：ファイアウォール １２６：制御装置
１４４：結果問い合わせハンドラ
１４６：コマンド実行結果記憶機能部

Claims (21)

1. ファイアウォールの内側に設けることで、該ファイアウォールの外側に設けられるサーバと、該ファイアウォールの内側に設けられる複数のクライアントとの間の通信を仲介する仲介装置であって、
   前記各クライアントからの動作要求を受信して前記サーバに転送する転送手段と、
   前記サーバに問い合わせを送信した際、そのサーバにおいて、それまでに転送したいずれかの動作要求に対する動作応答が送信可能な状態になっていた場合に、その動作応答を受信する受信手段と、
   該手段が動作応答を受信した場合に、その動作応答を、その動作応答と対応する動作要求の送信元に転送する第２の転送手段とを設けたことを特徴とする仲介装置。
2. 請求項１記載の仲介装置であって、
   前記受信手段が、前記サーバに問い合わせを送信した際、そのサーバにおいて、それまでに転送した複数の動作要求に対する動作応答がそれぞれ送信可能な状態になっていた場合に、それらの動作応答を複数一括して受信する手段であることを特徴とする仲介装置。
3. 請求項１又は２記載の仲介装置であって、
   前記受信手段に、前記転送手段が前記サーバに動作要求を転送した後、該サーバに転送した全ての動作要求に対する動作応答を受信するまで、定期的に前記サーバに前記問い合わせを送信する手段を設けたことを特徴とする仲介装置。
4. 請求項３記載の仲介装置であって、
   前記受信手段に、定期的に前記サーバに前記問い合わせを送信する手段を設け、該手段が、前記転送手段が前記サーバに動作要求を転送した後、該サーバに転送した全ての動作要求に対する動作応答を受信するまでは、それ以外の期間よりも短い間隔で前記サーバに前記問い合わせを送信する手段であることを特徴とする仲介装置。
5. 請求項１乃至４のいずれか一項記載の仲介装置であって、
   前記クライアントから動作要求を受信した場合に、該クライアントに対して受信通知を送信する受信通知手段を設けたことを特徴とする仲介装置。
6. ファイアウォールの外側に設けられるサーバと、該ファイアウォールの内側に設けられる複数のクライアントと、該ファイアウォールの内側に設けることで、前記サーバと前記複数のクライアントの間の通信を仲介する仲介装置とを備えた通信システムであって、
   前記仲介装置に、
   前記各クライアントからの動作要求を受信して前記サーバに転送する転送手段と、
   前記サーバに問い合わせを送信した際、そのサーバにおいて、それまでに転送したいずれかの動作要求に対する動作応答が送信可能な状態になっていた場合に、その動作応答を受信する受信手段と、
   該手段が動作応答を受信した場合に、その動作応答を、その動作応答と対応する動作要求の送信元に転送する第２の転送手段とを設け、
   前記各クライアントに、
   前記動作要求を前記仲介装置に送信する送信手段と、
   その送信した動作要求に対する動作応答を前記仲介装置から受信する受信手段とを設け、
   前記サーバに、
   前記クライアントからの動作要求を受信した場合に、その動作要求に係る動作を実行して動作応答を生成する手段と、
   前記仲介装置から前記問い合わせを受信した場合に、その仲介装置から受信したいずれかの動作要求に対する動作応答が送信可能な状態であれば、その動作応答をその仲介装置に送信する送信手段とを設けたことを特徴とする通信システム。
7. 請求項６記載の通信システムであって、
   前記仲介装置の受信手段が、前記サーバに前記問い合わせを送信した際、そのサーバにおいて、それまでに転送した複数の動作要求に対する動作応答がそれぞれ送信可能な状態になっていた場合に、それらの動作応答を複数一括して受信する手段であり、
   前記サーバの送信手段が、前記仲介装置から前記問い合わせを受信した場合に、その仲介装置から受信した複数の動作要求に対する動作応答がそれぞれ送信可能な状態であれば、それらの動作応答を該仲介装置に複数一括して送信する手段であることを特徴とする通信システム。
8. 請求項６又は７記載の通信システムであって、
   前記仲介装置において、前記受信手段に、前記転送手段が前記サーバに動作要求を転送した後、該サーバに転送した全ての動作要求に対する動作応答を受信するまで、定期的に前記サーバに前記問い合わせを送信する手段を設けたことを特徴とする通信システム。
9. 請求項８記載の通信システムであって、
   前記仲介装置の受信手段に、定期的に前記サーバに前記問い合わせを送信する手段を設け、該手段が、前記転送手段が前記サーバに動作要求を転送した後、該サーバに転送した全ての動作要求に対する動作応答を受信するまでは、それ以外の期間よりも短い間隔で前記サーバに前記問い合わせを送信する手段であることを特徴とする通信システム。
10. 請求項６乃至９のいずれか一項記載の通信システムであって、
    前記仲介装置に、前記クライアントから動作要求を受信した場合に、該クライアントに対して受信通知を送信する受信通知手段を設け、
    前記各クライアントに、該受信通知を受信する手段を設けたことを特徴とする通信システム。
11. ファイアウォールの外側に設けられるサーバと、該ファイアウォールの内側に設けられる複数のクライアントとの間の通信を、該ファイアウォールの内側に設ける仲介装置によって仲介して行う通信方法であって、
    前記仲介装置に、
    前記各クライアントからの動作要求を受信して前記サーバに転送する転送手順と、
    前記サーバに問い合わせを送信した際、そのサーバにおいて、それまでに転送したいずれかの動作要求に対する動作応答が送信可能な状態になっていた場合に、その動作応答を受信する受信手順と、
    該手順で動作応答を受信した場合に、その動作応答を、その動作応答と対応する動作要求の送信元に転送する第２の転送手順とを実行させるようにしたことを特徴とする通信方法。
12. 請求項１１記載の通信方法であって、
    前記仲介装置に実行させる受信手順が、前記サーバに前記問い合わせを送信した際、そのサーバにおいて、それまでに転送した複数の動作要求に対する動作応答がそれぞれ送信可能な状態になっていた場合に、それらの動作応答を複数一括して受信する手順であることを特徴とする通信方法。
13. 請求項１１又は１２記載の通信方法であって、
    前記仲介装置に、前記受信手順において、前記転送手順で前記サーバに動作要求を転送した後、該サーバに転送した全ての動作要求に対する動作応答を受信するまで、定期的に前記サーバに前記問い合わせを送信する手順を実行させるようにしたことを特徴とする通信方法。
14. 請求項１３記載の通信方法であって、
    前記仲介装置に、前記受信手順において、定期的に前記サーバに前記問い合わせを送信する手順を実行させ、該手順を、前記転送手順で前記サーバに動作要求を転送した後、該サーバに転送した全ての動作要求に対する動作応答を受信するまでは、それ以外の期間よりも短い間隔で前記サーバに前記問い合わせを送信する手順としたことを特徴とする通信方法。
15. 請求項１１乃至１４のいずれか一項記載の通信方法であって、
    前記仲介装置に、さらに、前記クライアントから動作要求を受信した場合に、該クライアントに対して受信通知を送信する受信通知手順を実行させるようにしたことを特徴とする仲介装置。
16. ファイアウォールの内側に設けることで、該ファイアウォールの外側に設けられるサーバと、該ファイアウォールの内側に設けられる複数のクライアントとの間の通信を仲介する仲介装置を制御するコンピュータを、
    前記各クライアントからの動作要求を受信して前記サーバに転送する転送手段と、
    前記サーバに問い合わせを送信した際、そのサーバにおいて、それまでに転送したいずれかの動作要求に対する動作応答が送信可能な状態になっていた場合に、その動作応答を受信する受信手段と、
    該手段が動作応答を受信した場合に、その動作応答を、その動作応答と対応する動作要求の送信元に転送する第２の転送手段として機能させるためのプログラム。
17. 請求項１６記載のプログラムであって、
    前記受信手段の機能が、前記サーバに前記問い合わせを送信した際、そのサーバにおいて、それまでに転送した複数の動作要求に対する動作応答がそれぞれ送信可能な状態になっていた場合に、それらの動作応答を複数一括して受信する機能であることを特徴とするプログラム。
18. 請求項１６又は１７記載のプログラムであって、
    前記受信手段に、前記転送手段が前記サーバに動作要求を転送した後、該サーバに転送した全ての動作要求に対する動作応答を受信するまで、定期的に前記サーバに前記問い合わせを送信する機能を設けたことを特徴とするプログラム。
19. 請求項１８記載のプログラムであって、
    前記受信手段に、定期的に前記サーバに前記問い合わせを送信する機能を設け、該機能を、前記転送手段が前記サーバに動作要求を転送した後、該サーバに転送した全ての動作要求に対する動作応答を受信するまでは、それ以外の期間よりも短い間隔で前記サーバに前記問い合わせを送信する機能としたことを特徴とするプログラム。
20. 請求項１６乃至１９のいずれか一項記載のプログラムであって、
    前記コンピュータを、前記クライアントから動作要求を受信した場合に、該クライアントに対して受信通知を送信する受信通知手段として機能させるためのプログラムを更に含むことを特徴とするプログラム。
21. 請求項１６乃至２０のいずれか一項記載のプログラムを記録したコンピュータ読み取り可能な記録媒体。
    

Images