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

Abstract

【課題】 ある通信装置が複数の通信装置に動作要求を送信してその動作要求に対する動作応答を受け取る場合において、効率よく通信を行うことができるようにする。
【解決手段】 複数の端末装置１０，１０′と処理サーバ１３との間の通信を仲介する仲介サーバ１２が、処理サーバ１３から、端末装置１０，１０′に転送すべき動作要求を複数一括して受信し、受信した動作要求を、転送先となる各端末装置１０，１０′に装置毎に一括して送信する。また、各端末装置１０，１０′から、処理サーバ１３から転送されてきた動作要求に対する動作応答を複数一括して受信し、その動作応答を、転送先となる処理サーバ１３に複数一括して送信する。
【選択図】 図１

Description

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

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

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

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

ところで、複数の通信装置間でメッセージを交換する場合において、１つの通信装置が、複数の通信装置に対してコマンドを送信する場合が考えられる。そして、このような場合、コマンドを受け付けた各通信装置には、それぞれコマンドの送信元に対してコマンドの実行結果を返すことが求められている。
従来、このような動作を行う場合には、コマンドの宛先となる通信装置と個別に通信を行い、宛先毎にコマンドを送信するようにしていた。また、コマンド応答を受信する際にも、コマンドを送信した各通信装置と個別に通信を行ってコマンド応答を受信するようにしていた。

しかし、このような方式では、当然のことながら、コマンドやコマンド応答を送受信する度に、コマンドの宛先毎にそれぞれ別々に通信のコネクションを確立する必要がある。従って、通信のオーバーヘッドが大きくなり、効率性の点で問題があった。
現状では、ネットワークを介した通信をダイヤルアップ接続で行う環境もまだ多く残っており、このような環境においては上記の点が特に問題となる。このような環境では、コネクションの確立に数十秒単位の時間を要することもあり、またコネクションを確立する毎に料金を課金されるので、コネクションを確立する回数が増加するとコストアップにつながるためである。

この発明は、このような問題を解決し、ある通信装置が複数の通信装置に動作要求を送信してその動作要求に対する動作応答を受け取る場合において、効率よく通信を行うことができるようにすることを目的とする。

上記の目的を達成するため、この発明の仲介装置は、複数の第１の通信装置と第２の通信装置との間の通信を仲介する仲介装置において、上記各第１の通信装置から、上記第２の通信装置から転送されてきた動作要求に対する動作応答を複数一括して受信する第１の受信手段と、その第１の受信手段が受信した各動作応答を、転送先となる第２の通信装置に複数一括して送信する第１の送信手段と、上記第２の通信装置から、上記第１の通信装置に転送すべき動作要求を複数一括して受信する第２の受信手段と、上記第２の受信手段が受信した各動作要求を、転送先となる上記各第１の通信装置に装置毎に一括して送信する第２の送信手段とを設けたものである。

また、複数の第１の通信装置と第２の通信装置との間の通信を仲介する仲介装置において、上記各第１の通信装置から、動作要求と、上記第２の通信装置から転送されてきた動作要求に対する動作応答とを一括して受信する第１の受信手段と、その第１の受信手段が受信した各動作要求及び動作応答を、各動作要求及び動作応答の種別に従って転送先となる第２の通信装置に一括して送信する第１の送信手段と、上記第２の通信装置から、上記第１の通信装置に転送すべき動作要求と、上記第１の通信装置から転送されてきた動作要求に対する動作応答とを一括して受信する第２の受信手段と、その第２の受信手段が受信した各動作要求と各動作応答とを転送先となる上記各第１の通信装置に装置毎に一括して送信する第２の送信手段とを設けたものである。

また、複数の第１の通信装置と第２の通信装置との間の通信を仲介する仲介装置において、上記各第１の通信装置から、上記第２の通信装置に転送すべき動作要求と、上記第２の通信装置から転送されてきた動作要求に対する動作応答とを一括して受信する第１の受信手段と、その第１の受信手段が受信した各動作要求及び動作応答を、転送先となる第２の通信装置に一括して送信する第１の送信手段と、上記第２の通信装置から、上記第１の通信装置に転送すべき動作要求と、上記第１の通信装置から転送されてきた動作要求に対する動作応答とを一括して受信する第２の受信手段と、その第２の受信手段が受信した各動作要求と各動作応答とを転送先となる上記各第１の通信装置に装置毎に一括して送信する第２の送信手段とを設けたものである。

これらの仲介装置において、上記第１の受信手段が受信した動作要求がその仲介装置において実行すべきものであった場合にその動作要求に係る動作を実行し、実行結果としてその動作要求に対する動作応答を生成する応答生成手段を設け、上記第２の送信手段を、その応答生成手段が生成した動作応答も上記第２の受信手段が受信した各動作要求及び各動作応答と一括して上記第１の通信装置に送信する手段とするとよい。

また、この発明は、複数の第１の通信装置と第２の通信装置との間の通信を仲介する仲介装置において、上記各第１の通信装置から、上記第２の通信装置から転送されてきたＳＯＡＰリクエストに対するＳＯＡＰレスポンスを１つのＨＴＴＰリクエストに複数記載した状態で受信する第１の受信手段と、その第１の受信手段が受信した各ＳＯＡＰレスポンスを、転送先となる第２の通信装置に１つのＨＴＴＰに複数記載して送信する第１の送信手段と、上記第２の通信装置から、上記第１の通信装置に転送すべきＳＯＡＰリクエストを１つのＨＴＴＰリクエストに複数記載した状態で受信する第２の受信手段と、その第２の受信手段が受信した各ＳＯＡＰリクエストを、上記第１の受信手段が受信したＨＴＴＰリクエストに対する１つのＨＴＴＰレスポンスに複数記載して転送先となる上記各第１の通信装置に装置毎に送信する第２の送信手段とを設けた仲介装置も提供する。
このような仲介装置において、上記第１の送信手段に、上記第２の通信装置に対して定期的にＨＴＴＰリクエストを送信する手段を設けるとよい。
さらに、上記第２の送信手段を、上記第１の受信手段がＨＴＴＰリクエストを受信した場合に、その要求元に送信すべきＳＯＡＰリクエストを全て、受信したＨＴＴＰリクエストに対するＨＴＴＰレスポンスに記載して送信する手段とするとよい。

また、この発明の分散処理システムは、処理サーバと、その処理サーバと複数の端末装置との間の通信を仲介する仲介サーバとを備えた分散処理システムにおいて、上記仲介サーバに、上記各端末装置から、上記処理サーバからの動作要求に対する動作応答を複数一括して受信する第１の受信手段と、その第１の受信手段が受信した各動作応答を、転送先となる処理サーバに複数一括して送信する第１の送信手段と、上記処理サーバから、上記端末装置宛ての動作要求を複数一括して受信する第２の受信手段と、その第２の受信手段が受信した各動作要求を転送先となる上記各端末装置に装置毎に複数一括して送信する第２の送信手段とを設け、上記処理サーバに、上記端末装置宛ての動作要求を複数一括して上記仲介サーバに送信する送信手段と、上記端末装置宛ての動作要求に対する動作応答を複数一括して上記仲介サーバから受信する受信手段とを設けたものである。

また、処理サーバと、その処理サーバと複数の端末装置との間の通信を仲介する仲介サーバとを備えた分散処理システムにおいて、上記仲介サーバに、上記各端末装置から、動作要求と、上記処理サーバからの動作要求に対する動作応答とを一括して受信する第１の受信手段と、その第１の受信手段が受信した各動作要求及び動作応答を、各動作要求及び動作応答の種別に従って転送先となる処理サーバに一括して送信する第１の送信手段と、上記処理サーバから、上記端末装置宛ての動作要求と、上記端末装置からの動作要求に対する動作応答とを一括して受信する第２の受信手段と、その第２の受信手段が受信した各動作要求と各動作応答とを転送先となる上記各端末装置に装置毎に一括して送信する第２の送信手段とを設け、上記処理サーバに、上記端末装置からのその処理サーバに対する動作要求と、上記端末装置宛ての動作要求に対する動作応答とを一括して上記仲介サーバから受信する受信手段と、その手段が受信した動作要求に係る動作を実行し、実行結果としてその動作要求に対する動作応答を生成する手段と、その手段が生成した動作応答と、上記端末装置宛ての動作要求とを一括して上記仲介サーバに送信する送信手段とを設けたものである。

また、処理サーバと、その処理サーバと複数の端末装置との間の通信を仲介する仲介サーバとを備えた分散処理システムにおいて、上記仲介サーバに、上記各端末装置から、上記処理サーバ宛ての動作要求と、上記処理サーバからの動作要求に対する動作応答とを一括して受信する第１の受信手段と、その第１の受信手段が受信した各動作要求及び動作応答を、転送先となる処理サーバに一括して送信する第１の送信手段と、上記処理サーバから、上記端末装置宛ての動作要求と、上記端末装置からの動作要求に対する動作応答とを一括して受信する第２の受信手段と、その第２の受信手段が受信した各動作要求と各動作応答とを転送先となる上記各端末装置に装置毎に一括して送信する第２の送信手段とを設け、上記処理サーバに、上記端末装置からのその処理サーバ宛ての動作要求と、上記端末装置宛ての動作要求に対する動作応答とを一括して上記仲介サーバから受信する受信手段と、その手段が受信した動作要求に係る動作を実行し、実行結果としてその動作要求に対する動作応答を生成する手段と、その手段が生成した動作応答と、上記端末装置宛ての動作要求とを一括して上記仲介サーバに送信する送信手段とを設けたものである

これらの分散処理システムにおいて、上記仲介サーバにおいて、上記第１の受信手段が受信した動作要求がその仲介装置において実行すべきものであった場合にその動作要求に係る動作を実行し、実行結果としてその動作要求に対する動作応答を生成する応答生成手段を設け、上記第２の送信手段を、その応答生成手段が生成した動作応答も上記第２の受信手段が受信した各動作要求及び各動作応答と一括して上記端末装置に送信する手段とするとよい。

また、この発明は、処理サーバと、その処理サーバと複数の端末装置との間の通信を仲介する仲介サーバとを備えた分散処理システムにおいて、上記仲介サーバに、上記各端末装置から、上記処理サーバからのＳＯＡＰリクエストに対するＳＯＡＰレスポンスを１つのＨＴＴＰリクエストに複数記載した状態で受信する第１の受信手段と、その第１の受信手段が受信したＳＯＡＰレスポンスを、転送先となる処理サーバに１つのＨＴＴＰリクエストに複数記載して送信する第１の送信手段と、上記処理サーバから、上記端末装置宛てのＳＯＡＰリクエストを１つのＨＴＴＰレスポンスに複数記載した状態で受信する第２の受信手段と、その第２の受信手段が受信した各ＳＯＡＰリクエストを、上記第１の受信手段が受信したＨＴＴＰリクエストに対する１つのＨＴＴＰレスポンスに複数記載して、転送先となる上記端末装置に装置毎に送信する第２の送信手段とを設け、上記処理サーバに、上記端末装置宛てのＳＯＡＰリクエストに対するＳＯＡＰレスポンスを１つのＨＴＴＰリクエストに複数記載した状態で上記仲介サーバから受信する受信手段と、上記端末装置宛てのＳＯＡＰリクエストを、上記仲介サーバから受信したＨＴＴＰリクエストに対する１つのＨＴＴＰレスポンスに複数記載して上記仲介サーバに送信する送信手段とを設けた分散処理システムも提供する。
このような分散処理システムにおいて、上記仲介サーバの第１の送信手段に、上記処理サーバに対して定期的にＨＴＴＰリクエストを送信する手段を設けるとよい。
さらに、上記仲介サーバの上記第２の送信手段を、上記第１の受信手段がＨＴＴＰリクエストを受信した場合に、その要求元に送信すべきＳＯＡＰリクエストを全て受信したＨＴＴＰリクエストに対するＨＴＴＰレスポンスに記載して送信する手段とし、上記処理サーバの送信手段を、その処理サーバの受信手段がＨＴＴＰリクエストを受信した場合に、その要求元に送信すべきＳＯＡＰリクエストを全て受信したＨＴＴＰリクエストに対するＨＴＴＰレスポンスに記載して送信する手段とするとよい。

また、この発明のデータ転送方法は、複数の第１の通信装置と第２の通信装置との間で仲介装置を介して動作要求及び動作応答を送受信させるデータ転送方法において、上記仲介装置に、上記各第１の通信装置から、上記第２の通信装置から転送されてきた動作要求に対する動作応答を複数一括して受信する第１の受信手順と、その第１の受信手順で受信した各動作応答を、転送先となる第２の通信装置に複数一括して送信する第１の送信手順と、上記第２の通信装置から、上記第１の通信装置に転送すべき動作要求を複数一括して受信する第２の受信手順と、上記第２の受信手順で受信した各動作要求を、転送先となる上記各第１の通信装置に装置毎に一括して送信する第２の送信手順とを実行させるようにしたものである。

また、複数の第１の通信装置と第２の通信装置との間で仲介装置を介して動作要求及び動作応答を送受信させるデータ転送方法において、上記仲介装置に、上記各第１の通信装置から、動作要求と、上記第２の通信装置から転送されてきた動作要求に対する動作応答とを一括して受信する第１の受信手順と、その第１の受信手順で受信した各動作要求及び動作応答を、各動作要求及び動作応答の種別に従って転送先となる第２の通信装置に一括して送信する第１の送信手順と、上記第２の通信装置から、上記第１の通信装置に転送すべき動作要求と、上記第１の通信装置から転送されてきた動作要求に対する動作応答とを一括して受信する第２の受信手順と、その第２の受信手順で受信した各動作要求と各動作応答とを転送先となる上記各第１の通信装置に装置毎に一括して送信する第２の送信手順とを実行させるようにしたものである。

また、複数の第１の通信装置と第２の通信装置との間で仲介装置を介して動作要求及び動作応答を送受信させるデータ転送方法において、上記仲介装置に、上記各第１の通信装置から、上記第２の通信装置に転送すべき動作要求と、上記第２の通信装置から転送されてきた動作要求に対する動作応答とを一括して受信する第１の受信手順と、その第１の受信手順で受信した各動作要求及び動作応答を、転送先となる第２の通信装置に一括して送信する第１の送信手順と、上記第２の通信装置から、上記第１の通信装置に転送すべき動作要求と、上記第１の通信装置から転送されてきた動作要求に対する動作応答とを一括して受信する第２の受信手順と、その第２の受信手順で受信した各動作要求と各動作応答とを転送先となる上記各第１の通信装置に装置毎に一括して送信する第２の送信手順とを実行させるようにしたものである。

これらのデータ転送方法において、上記第１の受信手順で受信した動作要求がその仲介装置において実行すべきものであった場合にその動作要求に係る動作を実行し、実行結果としてその動作要求に対する動作応答を生成する応答生成手順を設け、上記第２の送信手順を、その応答生成手順で生成した動作応答も上記第２の受信手順で受信した各動作要求及び各動作応答と一括して上記第１の通信装置に送信する手順とするとよい。

また、この発明は、複数の第１の通信装置と第２の通信装置との間で仲介装置を介して動作要求及び動作応答を送受信させるデータ転送方法において、上記仲介装置に、上記各第１の通信装置から、上記第２の通信装置から転送されてきたＳＯＡＰリクエストに対するＳＯＡＰレスポンスを１つのＨＴＴＰリクエストに複数記載した状態で受信する第１の受信手順と、その第１の受信手順で受信した各ＳＯＡＰレスポンスを、転送先となる第２の通信装置に１つのＨＴＴＰに複数記載して送信する第１の送信手順と、上記第２の通信装置から、上記第１の通信装置に転送すべきＳＯＡＰリクエストを１つのＨＴＴＰリクエストに複数記載した状態で受信する第２の受信手順と、その第２の受信手順で受信した各ＳＯＡＰリクエストを、上記第１の受信手順で受信したＨＴＴＰリクエストに対する１つのＨＴＴＰレスポンスに複数記載して転送先となる上記各第１の通信装置に装置毎に送信する第２の送信手順とを実行させるようにしたデータ転送方法も提供する。
このようなデータ転送方法において、上記第１の送信手順に、上記第２の通信装置に対して定期的にＨＴＴＰリクエストを送信する手順を設けるとよい。
さらに、上記第２の送信手順を、上記第１の受信手順でＨＴＴＰリクエストを受信した場合に、その要求元に送信すべきＳＯＡＰリクエストを全て、受信したＨＴＴＰリクエストに対するＨＴＴＰレスポンスに記載して送信する手順とするとよい。

また、この発明のプログラムは、コンピュータを、複数の第１の通信装置と第２の通信装置との間の通信を仲介する仲介装置として機能させるためのプログラムであって、上記コンピュータを、上記各第１の通信装置から、上記第２の通信装置から転送されてきた動作要求に対する動作応答を複数一括して受信する第１の受信手段と、その第１の受信手段が受信した各動作応答を、転送先となる第２の通信装置に複数一括して送信する第１の送信手段と、上記第２の通信装置から、上記第１の通信装置に転送すべき動作要求を複数一括して受信する第２の受信手段と、上記第２の受信手段が受信した各動作要求を、転送先となる上記各第１の通信装置に装置毎に一括して送信する第２の送信手段として機能させるためのプログラムである。

また、コンピュータを、複数の第１の通信装置と第２の通信装置との間の通信を仲介する仲介装置として機能させるためのプログラムであって、上記コンピュータを、上記各第１の通信装置から、動作要求と、上記第２の通信装置から転送されてきた動作要求に対する動作応答とを一括して受信する第１の受信手段と、その第１の受信手段が受信した各動作要求及び動作応答を、各動作要求及び動作応答の種別に従って転送先となる第２の通信装置に一括して送信する第１の送信手段と、上記第２の通信装置から、上記第１の通信装置に転送すべき動作要求と、上記第１の通信装置から転送されてきた動作要求に対する動作応答とを一括して受信する第２の受信手段と、その第２の受信手段が受信した各動作要求と各動作応答とを転送先となる上記各第１の通信装置に装置毎に一括して送信する第２の送信手段として機能させるためのプログラムである。

また、コンピュータを、複数の第１の通信装置と第２の通信装置との間の通信を仲介する仲介装置として機能させるためのプログラムであって、上記コンピュータを、上記各第１の通信装置から、上記第２の通信装置に転送すべき動作要求と、上記第２の通信装置から転送されてきた動作要求に対する動作応答とを一括して受信する第１の受信手段と、その第１の受信手段が受信した各動作要求及び動作応答を、転送先となる第２の通信装置に一括して送信する第１の送信手段と、上記第２の通信装置から、上記第１の通信装置に転送すべき動作要求と、上記第１の通信装置から転送されてきた動作要求に対する動作応答とを一括して受信する第２の受信手段と、その第２の受信手段が受信した各動作要求と各動作応答とを転送先となる上記各第１の通信装置に装置毎に一括して送信する第２の送信手段として機能させるためのプログラムである。

これらのプログラムにおいて、上記コンピュータを、上記第１の受信手段が受信した動作要求がその仲介装置において実行すべきものであった場合にその動作要求に係る動作を実行し、実行結果としてその動作要求に対する動作応答を生成する応答生成手段として機能させるためのプログラムをさらに含め、上記第２の送信手段の機能を、その応答生成手段が生成した動作応答も上記第２の受信手段が受信した各動作要求及び各動作応答と一括して上記第１の通信装置に送信する機能とするとよい。

また、この発明は、コンピュータを、複数の第１の通信装置と第２の通信装置との間の通信を仲介する仲介装置として機能させるためのプログラムであって、上記コンピュータを、上記各第１の通信装置から、上記第２の通信装置から転送されてきたＳＯＡＰリクエストに対するＳＯＡＰレスポンスを１つのＨＴＴＰリクエストに複数記載した状態で受信する第１の受信手段と、その第１の受信手段が受信した各ＳＯＡＰレスポンスを、転送先となる第２の通信装置に１つのＨＴＴＰに複数記載して送信する第１の送信手段と、上記第２の通信装置から、上記第１の通信装置に転送すべきＳＯＡＰリクエストを１つのＨＴＴＰリクエストに複数記載した状態で受信する第２の受信手段と、その第２の受信手段が受信した各ＳＯＡＰリクエストを、上記第１の受信手段が受信したＨＴＴＰリクエストに対する１つのＨＴＴＰレスポンスに複数記載して転送先となる上記各第１の通信装置に装置毎に送信する第２の送信手段として機能させるためのプログラムも提供する。
このようなプログラムにおいて、上記第１の送信手段に、上記第２の通信装置に対して定期的にＨＴＴＰリクエストを送信する機能を設けるとよい。
さらに、上記第２の送信手段の機能を、上記第１の受信手段がＨＴＴＰリクエストを受信した場合に、その要求元に送信すべきＳＯＡＰリクエストを全て、受信したＨＴＴＰリクエストに対するＨＴＴＰレスポンスに記載して送信する機能とするとよい。
この発明の記録媒体は、上記のいずれかのプログラムを記録したコンピュータ読み取り可能な記録媒体である。

以上のようなこの発明の仲介装置、分散処理システム、又はデータ転送方法によれば、ある通信装置が複数の通信装置に動作要求を送信してその動作要求に対する動作応答を受け取るような通信システムを構成する場合において、通信装置間の通信を適切に仲介することにより、通信の効率を上げることができる。また、この発明のプログラムによれば、コンピュータを上記の仲介装置として機能させてその特徴を実現し、同様な効果を得ることができる。この発明の記録媒体によれば、上記のプログラムを記憶していないコンピュータにそのプログラムを読み出させて実行させ、上記の効果を得ることができる。

以下、この発明を実施するための最良の形態について、図面を参照して説明する。
〔実施形態〕
まず、この発明の仲介装置である仲介サーバ及び、その仲介サーバを用いて構成した通信システムである分散処理システムの１つの実施形態について説明する。図１は、その分散処理システムの構成を示すブロック図である。

図１に示すように、この分散処理システムは、第１の通信装置である端末装置１０と、第２の通信装置である複数の処理サーバ１３と、これらの間の通信を仲介する仲介サーバ１２を備える。そして、このうち端末装置１０を顧客先（ユーザ側）の設置環境に配置し、これらと仲介サーバ１２とがインターネット１４を介して通信可能な構成としている。そして、処理サーバ１３が提供する機能を端末装置１０から利用する場合に、端末装置１０から要求を仲介サーバ１２に送信するのみで、仲介サーバ１２がその要求を適切な処理サーバ１３に転送し、処理サーバ１３が提供する機能を利用することができるシステムを構成している。
なお、ここではシステムの理解を容易にするために「仲介サーバ」及び「処理サーバ」の用語を用いているが、これは、これらの装置をネットワーク上で「サーバ」としての機能を果たす装置には限定する意図ではない。

また、端末装置１０としては、通信機能を有する公知のＰＣ（パーソナルコンピュータ）を使用することも考えられるが、種々の電子装置に通信機能を設けた通信装置が考えられる、例えば、プリンタ，ＦＡＸ装置，デジタル複写機，スキャナ装置，デジタル複合機等の画像処理装置や、ネットワーク家電，自動販売機，医療機器，電源装置，空調システム，ガス・水道・電気等の計量システム，自動車，航空機等に通信機能を持たせた通信装置が考えられる。

また、端末装置１０は、破線で示したように複数設けることも可能であり、異なる種類の装置を混在させることもできる。
さらに、各顧客先環境内の端末装置１０は、ＬＡＮ（ローカルエリアネットワーク）に接続して設けているが、セキュリティ面を考慮し、ファイアウォール１１を介してＬＡＮをインターネット１４に接続している。

ここで、ファイアウォール１１は通常は外部からの通信要求を遮断するよう設定されているため、仲介サーバ１２は、ＨＴＴＰ（Hyper Text Transfer Protocol）リクエストのような通信要求を送信するだけではファイアウォール１１の内側の端末装置１０に情報を送信することができない。従って、仲介サーバ１２と端末装置１０とが情報を授受するためには、特殊なプロトコルを採用する必要がある。

また、処理サーバ１３は、ここでは仲介サーバ１２と接続した２台のみを示しているが、多様な階層構造を成す配置とすることができるし、システムの運用中に配置を変更することも可能である。このようにしても、後述するように仲介サーバ１２でコマンドの転送先を管理しているので、この転送先管理のデータを変更することにより、容易にシステム構成の変更に対応可能である。
さらに、ここでは処理サーバ１３と仲介サーバ１２との間の接続はインターネット１４とは異なる線で示しているが、これらがインターネット１４を介して通信可能な構成とすることも、もちろん可能である。

また、このような分散処理システムにおいて、処理サーバ１３は、端末装置１０からの動作要求に応じた動作を行ったり、端末装置１０に動作要求を送信したりするためのアプリケーションプログラムを実装している。仲介サーバ１２は、端末装置１０と各処理サーバ１３との間で動作要求及びその動作要求に対する動作応答の送受信を仲介するためのアプリケーションプログラムを実装している。さらに、仲介サーバ１２は処理サーバとしての機能を実現するためのアプリケーションプログラムも実装している。そして、端末装置１０も含め、この分散処理システムにおけるこれら各ノードは、ＲＰＣ（remote procedure call）により、相互の実装するアプリケーションプログラムのメソッドに対する処理の依頼である「動作要求」を送信し、この依頼された処理の結果である「動作応答」を取得することができるようになっている。

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

図２に、これらの動作要求と動作応答の関係を示す。なお、この図においてはファイアウォール１１の存在は考慮していない。
図２（Ａ）は、端末装置１０で処理サーバ１３に対する動作要求が発生したケースである。このケースでは、端末装置１０が端末装置側動作要求ａを生成し、これを仲介サーバ１２を経由して受け取った処理サーバ１３がこの動作要求に対する動作応答ａを返すというモデルになる。

なおこのとき、後述するように、端末装置１０側では、動作要求が最終的にどの処理サーバ１３に転送されるかを把握している必要はなく、単に仲介サーバ１２に動作要求を送信すれば、仲介サーバ１２が適切な処理サーバ１３にその動作要求を転送し、その処理サーバ１３から動作応答を受信して端末装置１０に返すようにしている。また、端末装置側動作要求ａが複数の仲介サーバ１２に順次仲介されて処理サーバ１３に到達するケースも想定できる。

また、図２（Ａ）では、応答ａだけでなく遅延通知ａ′を返信するケースも表記している。これは処理サーバ１３が、接続してきた仲介サーバ１２から端末装置側動作要求ａを受け取って、これとの接続中にその動作要求に対する応答を返せないと判断したときには、応答が遅延する旨を通知して一旦接続状態を切断し、後の接続の際に上記動作要求に対する応答を改めて引き渡す構成になっているためである。

図２（Ｂ）は、端末装置１０で仲介サーバ１２に対する動作要求が発生したケースである。このケースでは、端末装置１０が、例えば、端末装置側動作要求ｂを生成し、これを受け取った仲介サーバ１２が、その動作要求に対する動作応答ｂを返すというモデルになる。ただし、この場合にも、端末装置１０側では図２（Ａ）の場合と異なる対応をする必要はない。そして、図２（Ａ）の場合と同様に仲介サーバ１２に動作要求を送信すれば、仲介サーバ１２側で、自身で実行すべき動作要求を判別し、自身で実行すべきと認識した場合に、処理サーバ１３への転送に代えて動作要求に係る動作を実行するようにしている。
また、図２（Ｂ）のケースでも、応答を即座に返せないときに遅延通知ｂ′を返すことは図２（Ａ）のケースと同様である。

図２（Ｃ）は、処理サーバ１３で、端末装置１０に対する動作要求が発生したケースである。このケースでは、処理サーバ１３が処理サーバ側動作要求ｃを生成し、これを仲介サーバ１２を経由して受け取った端末装置１０が、その動作要求に対する動作応答ｃを返すというモデルになる。
図２（Ｄ）は、仲介サーバ１２で端末装置１０に対する動作要求が発生したケースである。このケースでは、仲介サーバ１２が仲介サーバ側動作要求ｄを生成し、これを受け取った端末装置１０が、その動作要求に対する動作応答ｄを返すというモデルになる。

これらの図２（Ｃ）及び（Ｄ）の場合も、端末装置側では動作応答をどのサーバに返すかを認識している必要はなく、全ての動作応答を仲介サーバ１２に送信すれば、仲介サーバ１２側で適切な相手（自分自身も含む）に転送するようにしている。
遅延通知については、図２（Ｃ）及び（Ｄ）の場合も、図２（Ａ）や（Ｂ）の場合と同様である。
なお、ここではＲＰＣによる引数並びに戻り値の受け渡しのプロトコルとしてＳＯＡＰ（Simple Object Access Protocol）を採用し、上記の動作要求や動作応答は、ここではＳＯＡＰメッセージとして記載するようにしている。

この実施形態では、このように端末装置１０のような通信装置が処理サーバ１３のような複数の通信相手との間で互いに動作要求及び受信した動作要求に対する動作応答を送受信する場合において、その送受信を仲介する仲介装置として仲介サーバ１２を設け、その仲介サーバ１２が端末装置１０から受信した動作要求の種別に従って転送先となる処理サーバ１３に動作要求を転送し、また処理サーバ１３からの動作応答を動作要求の送信元の端末装置１０に返すようにしている。ここで、動作要求は上記通信装置からのみ送信し、上記通信相手はこの動作要求に対する動作応答のみを上記通信装置に送信する構成であっても構わない。

そして、実際に動作要求や動作応答を転送するための通信プロトコルとしては、システムの構成に合わせて適当なものを採用することができ、例えばＨＴＴＰ（HyperText Transfer Protocol）、ＳＭＴＰ（Simple Mail Transfer Protocol）あるいはＦＴＰ（File Transfer Protocol）等を採用することができる。ここでは、この中でＨＴＴＰを採用する場合の例について説明する。

次に、この実施形態について、より具体的な例を用いて説明する。
ここでは、図１に示した分散処理システムのより具体的な実施例として、第１の通信装置である画像処理装置１００から、それぞれ第２の通信装置である販売管理サーバ１０３ａや情報配信サーバ１０３ｂによって提供されるサービスを利用し、これらの装置間の通信をこの発明の仲介装置である機器管理サーバ１０２によって仲介する遠隔管理システムについて説明する。このシステムにおいて、画像処理装置１００は、機器管理サーバ１０２によって提供されるサービスを利用することもできる。
図３は、その分散処理システムの構成の一例を示す概念図であるが、端末装置１０を画像処理装置１００に変更し、各サーバに具体的な名称をつけた点が図１と相違するのみであるので、システムの全体構成についての説明は省略する。

なお、ここでは画像処理装置１００を１台のみ設けた例を示しているが、これを始めとする端末装置を複数設けてもよいことは図１に示した通りである。以後の説明において、説明を簡単にするため、基本的には端末装置は１台の画像処理装置１００のみであるものとして説明するが、端末装置を複数設けた場合にも容易に拡張して適用できるよう、一部の処理やデータについては、端末装置が複数ある例も、特に断らずに示す。この場合でも、その複数の端末装置のうち一つが画像処理装置１００であるものとして取り扱えば、図３に示したようなシステムにも問題なく適用できる。

ところで、画像処理装置１００は、コピー、ファクシミリ、スキャナ等の機能及び外部装置と通信を行う機能を備えたデジタル複合機であり、それらの機能に係るサービスを提供するためのアプリケーションプログラムを実装しているものである。
また、機器管理サーバ１０２は、処理サーバと画像処理装置１００との間の通信を仲介する仲介サーバとしての機能の他に、画像処理装置１００の遠隔管理及び保守に関するサービスを提供する機能を有する。
販売管理サーバ１０３ａは、画像処理装置１００における消耗品やサプライの注文受付や販売に関するサービスを提供する機能を有する。そして、情報配信サーバ１０３ｂは、画像処理装置１００のユーザに対してニュースや案内あるいは製品紹介等の種々の情報を配信するサービスを提供する機能を有する。

そして、これらの各ノードは、ＲＰＣ（remote procedure call）により、相互の実装するアプリケーションプログラムのメソッドに対する処理の依頼である「動作要求」を送信し、この依頼された処理の結果である「動作応答」を取得することができるようになっている。
なお、以後の説明においては、特にサービスの内容に関する説明をする場合以外は、機器管理サーバ１０２を仲介サーバ１０２と呼び、販売管理サーバ１０３ａ及び情報配信サーバ１０３ｂを併せて処理サーバ１０３と呼ぶことにする。

図４に、これらの動作要求と動作応答の関係を示す。なお、この図においてもファイアウォール１１の存在は考慮していない。
図４（Ａ）は、画像処理装置１００で処理サーバ１０３に対する動作要求が発生したケースである。このケースでは、画像処理装置１００が画像処理装置側動作要求ａ（以下、「端末装置コマンド」とも呼ぶ）を生成し、これを仲介サーバ１０２を経由して受け取った処理サーバ１０３がこのコマンドに対する動作応答ａ（以下、「コマンド応答」あるいは単に「応答」とも呼ぶ）を返すというモデルになる。なお、画像機器側動作要求ａが複数の仲介サーバ１０２に順次仲介されて処理サーバ１０３に到達するケースも想定できる。

図４（Ｂ）は、画像処理装置１００で仲介サーバ１０２に対する動作要求が発生したケースである。このケースでは、画像処理装置１００が、例えば、画像処理装置側動作要求ｂを生成し、これを受け取った仲介サーバ１０２が、そのコマンドに対する動作応答ｂを返すというモデルになる。
これらの図４（Ａ），（Ｂ）の場合において、画像処理装置１００側で、動作要求が最終的にどこに転送されるかを把握している必要がない点は、図２の場合と同様である。

図４（Ｃ）は、処理サーバ１０３で、画像処理装置１００に対する動作要求が発生したケースである。このケースでは、処理サーバ１０３が処理サーバ側動作要求ｃ（以下、「処理サーバコマンド」とも呼ぶ）を生成し、これを仲介サーバ１０２を経由して受け取った画像処理装置１００が、その動作要求に対する動作応答ｃを返すというモデルになる。
図４（Ｄ）は、仲介サーバ１０２で画像処理装置１００に対する動作要求が発生したケースである。このケースでは、仲介サーバ１０２が仲介サーバ側動作要求（以下、「仲介サーバコマンド」とも呼ぶ）ｄを生成し、これを受け取った画像処理装置１００が、そのコマンドに対する動作応答ｄを返すというモデルになる。

これらの図４（Ｃ），（Ｄ）の場合において、画像処理装置１００側で、動作応答が最終的にどこに転送されるかを把握している必要がない点は、図２の場合と同様である。
また、図４（Ａ）乃至（Ｄ）の全てについて、応答を即座に返せないときに遅延通知を返信することは、図２（Ａ）の場合と同様である。
このように、動作要求及び動作応答は、ＲＰＣのレベルでは、画像処理装置１００と処理サーバ１０３との間及び画像処理装置１００と仲介サーバ１０２との間で対称に取り扱われるものである。しかし、通信のレベルでは対称ではない。

次に、この通信システムにおける通信シーケンスについて説明する。
まず、図５に画像処理装置と仲介サーバとの間の通信シーケンスの例を示す。
この図に示すように、画像処理装置１００と仲介サーバ１０２とは、通信要求であるＨＴＴＰリクエストと、その通信要求に対する通信応答であるＨＴＴＰレスポンスとを、互いに送受信することによって通信を行っている。

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

そして、画像処理装置１００からのＨＴＴＰリクエストには、画像処理装置１００からの仲介サーバ１０２又は処理サーバ１０３に対する動作要求である端末装置コマンドと、処理サーバ１０３から仲介サーバ１０２を介して画像処理装置１００に送信されてきた処理サーバコマンドに対する応答（コマンド応答）と、仲介サーバ１０２から画像処理装置１００に送信されてきた仲介サーバコマンドに対する応答とを記載して送信するようにしている。

なお、端末装置コマンドについては、画像処理装置１００側では、仲介サーバ１０２又は処理サーバ１０３のいずれかに対して送信すべきものであることのみを把握していればよい。
そして、仲介サーバ１０２からのＨＴＴＰレスポンスには、処理サーバ１０３からの画像処理装置１００に対する動作要求である処理サーバコマンドと、仲介サーバ１０２からの画像処理装置１００に対する動作要求である仲介サーバコマンドと、画像処理装置１００からの仲介サーバ１０２又は処理サーバ１０３に対する端末装置コマンドに対する応答とを記載して送信するようにしている。

応答については、どの端末装置コマンドに対する応答かがわかるようにしておけば、どの仲介サーバ１０２又は処理サーバ１０３からの応答であるかを具体的に特定できるようにする必要はない。また、遅延通知を送信する場合には、上記応答に代えて遅延通知を記載してもよい。
また、この例からわかるように、例えば端末装置コマンドＡ及びＢは、ＨＴＴＰリクエストＸに記載して転送し、それに対する応答あるいは遅延通知をそのＨＴＴＰリクエストＸと対応するＨＴＴＰレスポンスＸに記載して転送することができる。しかし、処理サーバコマンドＣや仲介サーバコマンドＤについては、ＨＴＴＰリクエストＸと対応するＨＴＴＰレスポンスＸに記載して転送し、それに対する応答あるいは遅延通知は次のＨＴＴＰリクエストであるＨＴＴＰリクエストＹに記載して転送することになる。

さらに、上述した図４（Ａ）又は（Ｂ）のケースでは、画像処理装置１００は、端末装置コマンドを生成した後直ちに仲介サーバ１０２とコネクションを確立し、ＨＴＴＰリクエストにこれを含めて引き渡すことができるが、図４（Ｃ）又は（Ｄ）のケースでは、画像処理装置１００側に設置されたファイアウォール１１が仲介サーバ１０２からのＨＴＴＰリクエストを遮断するため、仲介サーバ１０２側から直ちに画像処理装置１００へアクセスして処理サーバコマンドを引き渡すことができないことになる。

次に、図６に仲介サーバと処理サーバとの間の通信シーケンスの例を示す。
仲介サーバ１０２と処理サーバ１０３との間には、ファイアウォールがあるとは限らない。しかし、処理サーバ１０３側で通信すべき相手を管理したり、通信を要求すべきタイミングを管理したりする負荷をなくすため、この図に示すように、通信は常に、仲介サーバ１０２から通信要求としてＨＴＴＰリクエストを処理サーバ１０３に送信し、処理サーバ１０３からこの通信要求に対する通信応答としてＨＴＴＰレスポンスを仲介サーバ１０２に返すという手順で行うようにしている。例えば仲介サーバ１０２が送信したＨＴＴＰリクエストＺに対して処理サーバ１０３がＨＴＴＰレスポンスＺを返し、同じくＨＴＴＰリクエストＷに対してＨＴＴＰレスポンスＷを返すという具合である。

そして、ＨＴＴＰリクエストには、画像処理装置１００から受信した端末装置コマンド及び画像機器１００に送信した処理サーバコマンドに対する応答であって画像処理装置１００から受信したもののうち、処理サーバ１０３に転送すべきと判断したものを記載して送信するようにしている。また、ＨＴＴＰレスポンスには、処理サーバ１０３からの画像処理装置１００宛ての動作要求である処理サーバコマンドと、処理サーバ１０３に転送した端末装置コマンドに対する応答とを記載して送信するようにしている。なお、遅延通知を送信する場合には、上記応答に代えて遅延通知を記載してもよい。

なお、端末装置コマンド、仲介サーバコマンド、処理サーバコマンド及びこれらに対する応答や遅延通知は、それぞれ任意の数ずつ（０でもよい）１つのＨＴＴＰリクエストやＨＴＴＰレスポンスに記載することができる。そして、１つのＨＴＴＰリクエスト又はＨＴＴＰレスポンスに記載した内容は、論理的に一括して転送する。
そして、このように、宛先や送信元の異なる動作要求や動作応答を一括して転送することにより、必要な情報を転送するために必要なコネクションの回数を減らし、オーバーヘッドを低減して通信の効率化を図ることができる。

図７に画像処理装置と仲介サーバとの間の別の通信シーケンスの例を示す。
説明のため、図５及び図６には極めて単純なシーケンス例を示したが、図７には、各ＨＴＴＰリクエストやＨＴＴＰレスポンスに記載するコマンドやコマンド応答の数が一定でない例を示している。
また、コマンドに対して遅延通知を送信した場合に、次の送信機会の時点で応答を返す必要もない。例えば、図７に示す端末装置コマンドＢのように遅延通知を記載したＨＴＴＰレスポンスＸ′の次のＨＴＴＰレスポンスＹ′に記載して応答を返さず、図示しないさらに後のＨＴＴＰレスポンス応答を返すようにしてもよい。
もちろん仲介サーバコマンドや処理サーバコマンドについても同様であり、遅延通知を記載したＨＴＴＰリクエストの次のＨＴＴＰリクエストにそのコマンドに対する応答を記載する必要はない。そして、さらに後のＨＴＴＰリクエストに記載して転送すればよい。

ところで、各コマンド及びコマンド応答は、それぞれ独立して生成され、また処理に供されるべきものであるから、画像処理装置１００と仲介サーバ１０２との間及び仲介サーバ１０２と処理サーバ１０３との間で上記のような一括転送を行うためには、転送前にこれらのコマンドやコマンド応答を結合し、また転送後に分離する処理が必要となる。次に、各装置のハードウェア構成と共に、このような処理を行うための機能構成及びその処理の手順について説明する。
なお、説明を簡単にするため、以後の説明では遅延通知に関する処理の記載を省略する。

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

外部接続Ｉ／Ｆ１２３は、インターネット１４あるいは専用線等によるネットワークを介した通信を行うためのインタフェースである。そして、ここを介して機器利用者側の画像処理装置１００や、処理サーバ１０３との通信を行う。また、セキュリティ管理のためのプロキシサーバ等を設けてもよい。
操作者端末１２４は、各種データの入力をオペレータによるキーボード等の入力装置上の操作により受け付ける。入力されるデータとしては、例えば、各顧客先環境の画像処理装置１００と通信する際に使用するそれらのＩＰアドレスや電話番号（発呼先電話番号）等の顧客情報がある。

制御装置１２５は、図示しないＣＰＵ，ＲＯＭ，ＲＡＭ等からなるマイクロコンピュータを備えており、仲介サーバ１０２全体を統括的に制御する。そのＣＰＵが、所要のプログラムに従って動作する（所要のプログラムを必要に応じて実行する）と共に、各部を必要に応じて選択的に使用することにより、各種処理を行うことができる。

ファイルサーバ１２６は、図示しないハードディスク装置等の記憶装置を備え、そこに各顧客先環境の画像処理装置１００のＩＰアドレスや電話番号、それらの装置から受信したデータ、管理対象の画像処理装置の識別情報、操作者端末１２４から入力されたデータ、各コマンドやコマンド応答の転送先を示す後述する転送先テーブル、およびこの発明に係わるプログラム等の各種データをそれぞれデータベース（ＤＢ）として記憶している。
なお、管理装置の構成はこれに限られることはなく、例えば１台のＰＣを用いて構成することもできる。

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

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

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

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

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

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

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

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

次に、図１０に処理サーバのハードウェア構成を示す。
この図に示すように、各処理サーバ１０３は、ＣＰＵ３０１、ＲＯＭ３０２、ＲＡＭ３０３、ＳＤ（Secure Digital）カード３０４、ネットワークインタフェースカード（ＮＩＣ）３０５を備え、これらがシステムバス３０６で接続されている。

これら構成要素を更に具体的に説明すると、まずＣＰＵ３０１は、ＲＯＭ３０２に格納している制御プログラムによって処理サーバ１０３全体を統括的に制御する制御手段である。そして、ＲＯＭ３０２は、ＣＰＵ３０１が使用する制御プログラムを含む各種固定データを格納している読み出し専用メモリである。
ＲＡＭ３０３は、ＣＰＵ３０１がデータ処理を行う際のワークメモリ等として使用する一時記憶用メモリである。ＳＤカード３０４は、装置の電源がオフになっても記憶内容を保持するようになっている不揮発性メモリである。ＮＩＣ３０５は、インターネット１４を始めとするネットワークを介して通信相手と情報の送受信を行うための通信手段である。
なお、これらの基本構成に、必要に応じてハードウェアを追加してもよいことはもちろんである。

次に、図１１の機能ブロック図に、仲介サーバ１０２の機能のうち、コマンド及びコマンド応答に関する処理を行うための機能の構成を示す。
図１１に示す機能のうち、端末装置コマンドプール４１、仲介サーバコマンドプール４２、送信用転送メッセージプール５１、受信用転送メッセージプール５２は、いずれかの書き換え可能な記憶手段に設けられるものである。例えば制御装置１２５内のフラッシュメモリあるいはＳＤＲＡＭやＨＤＤに設けることができるが、ファイルサーバ１２６に設けてもよい。端末装置コマンド実行結果生成手段４３、仲介サーバコマンド生成手段４４、メッセージ収集手段４５、メッセージ分配手段４７、メッセージ転送手段４８の機能は、制御装置１２５のＣＰＵによって実現されるものである。また、ＨＴＴＰサーバ機能部４６及びＨＴＴＰクライアント機能部４９の機能は、制御装置１２５のＣＰＵ及び外部接続Ｉ／Ｆ１２３によって実現されるものである。転送先情報記憶手段５０の機能は、制御装置１２５内のフラッシュメモリやＨＤＤのような不揮発性記憶手段によって実現されるものである。

これらの機能についてさらに詳述する。
まず、端末装置コマンドプール４１は、画像処理装置１００から受信した端末装置コマンドのうち仲介サーバ１０２自身が実行すべきと判断したものを、これらのコマンドに対する応答や、このコマンドの識別情報及び送信元の情報等と関連付けて登録するプールである。

また、仲介サーバコマンドプール４２は、仲介サーバコマンドを、このコマンドに対する応答や、このコマンドの識別情報及びこのコマンドの宛先の情報等と関連付けて登録するプールである。
これらのプールにおいては、コマンド毎にテーブル形式のコマンドシートを作成して情報を格納することにより、コマンドと、識別情報や応答等の情報とを関連付けるようにしている。

端末装置コマンド実行結果生成手段４３は、応答生成手段に該当する。そして、端末装置コマンドプール４１から端末装置コマンドを読み出して実行するアプリケーションである端末装置コマンドハンドラ４３ａを備え、この端末装置コマンドハンドラ４３ａが、端末装置コマンドに対する応答を生成し、端末装置コマンドのコマンドＩＤと関連付けて端末装置コマンドプール４１に登録する機能を有する。なお、画像処理装置１００から受信した端末装置コマンドは、このコマンドを識別するＩＤ及びこのコマンドを管理するための管理情報等と関連付けて、テーブル形式の端末装置コマンドシートとして端末装置コマンドプール４１に登録しておくようにしている。そして、端末装置コマンド実行結果生成手段４３が生成したコマンド応答も、端末装置コマンドプール４１に登録する際には実行した端末装置コマンドについての端末装置コマンドシートに登録する。

また、端末装置コマンドハンドラ４３ａに、端末装置コマンドプール４１から複数の種類の端末装置コマンドを読み出し、各端末装置コマンドに対する応答を生成する機能を設けることが考えられる。さらに、端末装置コマンドが仲介サーバ１０２に優先して処理を実行させるための実行優先順位の情報を含む場合には、優先順位の高いものから優先的に読み出して実行する機能を設けることも考えられる。
なお、端末装置コマンドハンドラ４３ａは、アプリケーションそのものではなく、端末装置コマンドの実行に必要なアプリケーションを呼び出してコマンドを実行させるモジュールであってもよい。

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

各データの内容について説明する。
まず、「メソッド名」は、仲介サーバ１０２に対するリクエストの内容であり、仲介サーバ１０２において呼び出す関数の種類を示す。「入力パラメータ」は、「メソッド名」に付随するデータであり、関数を呼び出す際の引数である。
「送信元情報」は、コマンドの送信元、すなわちコマンドを生成した装置の識別情報を示す。端末装置コマンドの場合には、ここには画像処理装置１００の識別情報を登録することになる。またこの情報は、コマンドに対する応答を送信する際の宛先を示す情報になる。
端末装置コマンドプール４１に記憶させる端末装置コマンドは、全て仲介サーバ１０２自身が実行すべきものであるから、コマンドの宛先を管理する必要はない。

「コマンドＩＤ」は、端末装置コマンドを識別するための識別情報である。「状態」は、端末装置コマンドに関する処理の状態を示すデータであり、処理の進行と共に、「未処理」→「処理完了」→「応答済」、あるいは「未処理」→「処理中」→「処理完了」→「応答済」と遷移していく。「出力パラメータ」には、端末装置コマンド実行結果生成手段４３によって生成された応答が格納される。端末装置コマンドの実行が終了し、上記の「状態」が「処理完了」となるまでは空である。「コマンドの通知先」は、端末装置コマンドの実行を行うモジュールを示す参照情報である。

図１１の説明に戻ると、仲介サーバコマンド生成手段４４は、要求生成手段に該当する。そして、仲介サーバコマンドを生成し、このコマンドを識別する識別情報（ＩＤ）を割り当て、さらにこのコマンドの宛先情報やこのコマンドを管理するための管理情報を付し、これらの情報を関連付けてテーブル形式の仲介サーバコマンドシートとして仲介サーバコマンドプール４２に登録する機能を有する。この処理を行うのが仲介サーバコマンド生成ハンドラ４４ａであり、このうち、仲介サーバコマンドを生成する部分には、例えば仲介サーバ１０２に備えるアプリケーションが該当する。また、仲介サーバコマンド生成ハンドラ４４ａに、画像処理装置１００に各コマンドを実行させる際の優先順位を、生成した仲介サーバコマンドに付する機能を設けてもよい。

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

各項目の内容について説明する。
まず、「メソッド名」は、画像処理装置１００に対するリクエストの内容であり、画像処理装置１００において呼び出す関数の種類を示す。「入力パラメータ」は、「メソッド名」に付随するデータであり、関数を呼び出す際の引数である。
「宛先情報」は、コマンドを実行させる対象の装置、すなわちコマンドの宛先となる装置の識別情報を示す。仲介サーバコマンドの場合には、ここには画像処理装置１００の識別情報を登録することになる。なお、識別情報としては、ＩＤ、固有名称、ＩＰアドレス等を用いることができる。
仲介サーバコマンドは常に仲介サーバ１０２自身が生成するものであるから、コマンドの送信元情報を管理する必要はない。

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

再び図１１の説明に戻ると、メッセージ収集手段４５は、収集手段に該当する。そして、端末装置コマンド実行結果生成手段４３が生成したコマンド応答とこのコマンド応答に対応する端末装置コマンドのコマンドＩＤ及び送信元情報とを関連付けて端末装置コマンドプール４１から読み出すと共に、仲介サーバコマンド生成手段４４が生成した仲介サーバコマンドとこのコマンドのコマンドＩＤ及び宛先情報とを関連付けて仲介サーバコマンドプール４２から読み出し、さらに、後に詳述する受信用転送メッセージプール５２の転送用メッセージシートに記載された転送用のメッセージを読み出し、これらから送信メッセージを生成する機能を有する。
なお、コマンド応答や端末装置コマンドあるいは転送用のメッセージに優先順位が指定されている場合には、メッセージ収集手段４５がそれぞれ優先順位の高いものから順に読み出すようにすることが考えられる。

ここで、送信メッセージとは、上記のコマンド応答やコマンドとコマンドＩＤとを、構造化言語であるＸＭＬ（Extensible Markup Language）で、ＳＯＡＰメッセージとして記載したものである。そして、メッセージ収集手段４５は、１つのコマンド応答あるいはコマンドにつき、送信メッセージとして１つのＳＯＡＰメッセージを生成する。またこのとき、各コマンドのコマンドＩＤはＳＯＡＰヘッダに記載し、コマンド応答やコマンドの内容は、ＳＯＡＰボディに記載する。ＳＯＡＰによる通信では、ＳＯＡＰヘッダとＳＯＡＰボディとからなるＳＯＡＰエンベロープ（封筒）と呼ばれるメッセージをＸＭＬで記載し、ＨＴＴＰなどのプロトコルで交換することになる。

このようなコマンドやコマンド応答からのＳＯＡＰメッセージの生成は、ＷＳＤＬ（Web Service Description Language）に基づいて生成される所要の変換プログラム（シリアライザ）を実行し、データを直列化することによって行うことができる。
なお、転送用のメッセージについては、ＸＭＬで記載したＳＯＡＰエンベロープの状態で記憶しておき、そのまま送信メッセージとして使用することができるようにしている。

また、ＨＴＴＰサーバ機能部４６は、ＨＴＴＰレスポンスを送信するＨＴＴＰレスポンス送信手段４６ａとＨＴＴＰリクエストを受信するＨＴＴＰリクエスト受信手段４６ｂとを備える。そして、ＨＴＴＰレスポンス送信手段４６ａは、第２の送信手段に該当し、メッセージ収集手段４５が生成した送信メッセージを記載したＨＴＴＰレスポンスを生成し、画像処理装置１００に送信する機能を有する。このとき、１つのＨＴＴＰレスポンスに送信メッセージをいくつ含めてもよいし、コマンド応答に係る送信メッセージと仲介サーバコマンドに係る送信メッセージと転送メッセージに係る送信メッセージとを任意に混在させることもできる。もちろん、異なる処理サーバが生成した転送用のメッセージに係る送信メッセージを混在させてもよい。

そこで、ＨＴＴＰレスポンス送信手段４６ａは、これらのいずれに係る送信メッセージかに関わり無く、メッセージ収集手段４５が生成した全ての送信メッセージを１つのＨＴＴＰレスポンスに含めて送信するようにしている。ただし、１つのＨＴＴＰレスポンスに含める送信メッセージの数に上限を設けることも考えられる。

ところで、このＨＴＴＰレスポンスの送信は、メッセージ収集手段４５が仲介サーバコマンドやコマンド応答あるいは転送用メッセージ等の読み出しを試みた場合には、読み出すデータがなく、結果的に送信すべきＳＯＡＰメッセージを生成しなかった場合にも行うものである。そして、この読み出しの試みは、ＨＴＴＰリクエスト受信手段４６ｂが画像処理装置１００からのＨＴＴＰリクエストを受信した場合に行うものとする。
このようにするのは、上述のように、仲介サーバ１０２からファイアウォール１１を越えて画像処理装置１００にＨＴＴＰリクエストを送信することができないためである。

また、ＨＴＴＰリクエスト受信手段４６ｂは、第１の受信手段に該当し、画像処理装置１００からＨＴＴＰリクエストを受信する機能を有する。そしてここでは、ＨＴＴＰリクエストには、端末装置コマンド及びそのコマンドと関連付けられたコマンドＩＤを含む受信メッセージと、仲介サーバコマンド又は処理サーバコマンドに対する応答及びそのコマンドと関連付けられたコマンドＩＤを含む受信メッセージとを含む受信メッセージとが、任意に混在して含まれている。
ここで、受信メッセージとは、上記のコマンドや応答とコマンドＩＤ等とをＳＯＡＰメッセージとして記載したものである。そして、仲介サーバ１０２に宛てたメッセージであるか処理サーバ１０３等の他の装置に転送すべきメッセージであるかは、受信の時点では区別しないし、そのための宛先や転送先の情報が含まれている必要もない。

メッセージ分配手段４７は、ＨＴＴＰリクエスト受信手段４６ｂが受信したＨＴＴＰリクエストに含まれるデータを、端末装置コマンドプール４１、仲介サーバコマンドプール４２、および送信用転送メッセージプール５１に振り分けて登録する機能を有する。
具体的には、転送先情報記憶手段５０に記憶している転送先テーブルを参照し、転送先決定手段として機能して受信したコマンドやコマンド応答の種別に従ってその転送先を判断し、その結果に基づいて登録するプールを決定する。詳細は後述するが、転送先テーブルは、コマンドやコマンド応答の群毎にその群に属するコマンドやコマンド応答の転送先を定めた転送先テーブルを記載したものである。そして、コマンドやコマンド応答をキーにしてその転送先テーブルを検索することにより、そのコマンドやコマンド応答を転送すべき転送先の情報を取得することができる。

そして、受信したコマンド（端末装置コマンド）の転送先が、仲介サーバ１０２自身であれば、その端末装置コマンド及びそのコマンドと関連付けられたコマンドＩＤを端末装置コマンドプール４１に端末装置コマンドシートを設けて登録する。また、受信したコマンド応答の転送先が仲介サーバ１０２自身であれば、その応答は仲介サーバコマンドに対する応答であるので、そのコマンドと関連付けられたコマンドＩＤを仲介サーバコマンドプール４２に記憶している仲介サーバコマンドシートのコマンドＩＤと照合して対応する仲介サーバコマンドを特定し、その仲介サーバコマンドについての「出力パラメータ」として登録する。

そしてこのとき、ＨＴＴＰリクエストを分割してそこに含まれる各受信メッセージを取り出し、そのデータをテーブルへの登録に必要な形式に変換するが、この変換は、ＷＳＤＬに基づいて生成される所要の変換プログラム（デシリアライザ）を実行することによって行うことができる。
一方、仲介サーバ１０２自身以外が転送先であるコマンドやコマンド応答については、そのコマンドやコマンド応答に係るメッセージを他の装置に転送するために送信用転送メッセージプール５１に登録する。そして、送信用転送メッセージプール５１への登録を行う場合には、転送メッセージシートを作成して登録する。

図１４にその転送メッセージシートにおけるデータ構造の例を示す。
この図に示すように、送信用転送メッセージプール５１の転送メッセージコマンドシートには、「転送先情報」、「エンティティヘッダ情報」、「メッセージのＸＭＬデータ」を記憶する領域を設けている。
そして、このうち「転送先情報」には、メッセージ分配手段４７が受信したコマンドやコマンド応答の種別に従って判断した転送先の情報を登録する。「エンティティヘッダ情報」には、メッセージが記載されていたパートのエンティティヘッダの情報（詳細は後述する）を登録し、「メッセージのＸＭＬデータ」には、メッセージに係るＳＯＡＰエンベロープの内容を登録する。ここで、転送用のメッセージについては、メッセージの内容によらずそのまま転送すればよいので、ＳＯＡＰエンベロープのデータ形式を変換する必要はない。
なお、メッセージ分配手段４７が送信用転送メッセージプール５１にメッセージを登録する際には、そのメッセージが記載されていたＨＴＴＰリクエストの送信元の情報を参照し、メッセージの送信元の情報を記載したヘッダを生成してエンティティヘッダ情報に追加するようにしている。

再度図１１の説明に戻ると、メッセージ転送手段４８は、送信用転送メッセージプール５１に登録されている転送用のメッセージを読み出して送信メッセージを生成し、またＨＴＴＰクライアント機能部４９のＨＴＴＰレスポンス受信手段４９ｂが受信したメッセージを受信用転送メッセージプール５２に登録する機能を有する。

まず、送信メッセージの生成に関しては、転送先毎に、その転送先に送信すべき転送メッセージを読み出す。そしてこのとき、転送メッセージシートには、メッセージがＸＭＬで記載したＳＯＡＰエンベロープの状態で登録されているので、そのまま転送用メッセージとして使用することができる。また、そのＳＯＡＰメッセージには、同じシートの「エンティティヘッダ情報」に登録されているエンティティヘッダを付してそのメッセージを記載した送信用のパートを生成する。
また、受信用転送メッセージプール５２への登録に関しては、受信したメッセージを登録するための転送メッセージシートを作成して登録する。しかし、このシートの形式は、送信用転送メッセージプール５１の場合とは若干異なる。

図１５に受信用転送メッセージプール５２の転送メッセージシートにおけるデータ構造の例を示す。
この図に示すように、受信用転送メッセージプール５２の転送メッセージシートには、「エンティティヘッダ情報」及び「メッセージのＸＭＬデータ」を記憶する領域を設けている。

そして、このうち「エンティティヘッダ情報」には、メッセージが記載されていたパートのエンティティヘッダの情報（詳細は後述する）を登録し、「メッセージのＸＭＬデータ」には、メッセージに係るＳＯＡＰエンベロープの内容を登録する。ここで、ＳＯＡＰエンベロープのデータ形式を変換する必要がない点は、送信用転送メッセージプール５１の場合と同様である。
受信用転送メッセージプール５２の場合には、「転送先情報」の項目がないが、これは、メッセージの転送経路の情報をエンティティヘッダに記載するようにしているためである。

再度図１１の説明に戻ると、ＨＴＴＰクライアント機能部４９は、ＨＴＴＰリクエストを送信するＨＴＴＰリクエスト送信手段４９ａとＨＴＴＰレスポンスを受信するＨＴＴＰレスポンス受信手段４９ｂとを備える。そして、ＨＴＴＰリクエスト送信手段４９ａは、第１の送信手段に該当し、メッセージ転送手段４８が生成した送信メッセージを記載したＨＴＴＰリクエストを生成し、処理サーバ１０３に送信する機能を有する。このとき、１つのＨＴＴＰリクエストに送信メッセージをいくつ含めてもよいし、コマンド応答に係る送信メッセージと画像機器コマンドに係る送信メッセージとを任意に混在させることもできる。そもそも、メッセージの転送に際しては、転送先さえ認識できればメッセージの内容を認識する必要はない。そして、送信元の異なるコマンドやコマンド応答あるいは転送メッセージに係る送信メッセージを混在させてもよい。

そこで、ＨＴＴＰリクエスト送信手段４９ａは、これらのいずれに係る送信メッセージかに関わり無く、メッセージ転送手段４８が１つの転送先について生成した全ての送信メッセージを１つのＨＴＴＰリクエストに含めて送信するようにしている。ただし、１つのＨＴＴＰリクエストに含める送信メッセージの数に上限を設けることも考えられる。

また、このＨＴＴＰリクエストの送信は、メッセージ転送手段４８がある転送先について転送用メッセージの読み出しを試みた場合には、読み出したデータがなく、結果的に送信すべきＳＯＡＰメッセージを生成しなかった場合にも行うものである。そして、この読み出しの試みは、定期的に行うものとする。例えば、タイマによって６０分毎に読み出すことが考えられる。

このようにするのは、上述のように、処理サーバ１０３から仲介サーバ１０２に送信したい情報があったとしても仲介サーバ１０２から通信を要求しない限り送信できないようにしているためである。仲介サーバ１０２から何も送信するデータがなかったとしても、定期的に各処理サーバ１０３に対して通信要求を送信して、各処理サーバ１０３から仲介サーバ１０２に情報を送信する機会を与えることにより、転送の必要な情報が長期間に亘って処理サーバ１０３に滞留してしまうことを防止できる。

なお、メッセージ転送手段４８による読み出しと、それに続くＨＴＴＰリクエスト送信手段４９ａによるＨＴＴＰリクエストの送信とを、定期的なタイミング以外に適宜行ってよいことはもちろんである。例えば、緊急に送信が必要な情報が送信用転送メッセージプール５１に登録された場合に、メッセージ分配手段４７がメッセージ転送手段４８にその旨を通知して読み出しを行わせるようにしてもよい。

また、ＨＴＴＰレスポンス受信手段４９ｂは、第２の受信手段に該当し、処理サーバ１０３からＨＴＴＰレスポンスを受信する機能を有する。そしてここでは、ＨＴＴＰレスポンスには、処理サーバコマンド及びそのコマンドと関連付けられたコマンドＩＤを含む受信メッセージと、端末装置コマンドに対する応答及びそのコマンドと関連付けられたコマンドＩＤを含む受信メッセージとが、任意に混在して含まれている。

そして、受信メッセージとは、上記のコマンドや応答とコマンドＩＤ等とをＳＯＡＰメッセージとして記載したものである。そして、これらは画像処理装置１００に転送すべきメッセージであるので、上述のようにメッセージ転送手段４８によって受信用転送メッセージプール５２に登録され、適当なタイミングでメッセージ収集手段４５によって読み出され、ＨＴＴＰレスポンス送信手段４６ａによって画像処理装置１００に送信されることになる。

なお、受信用転送メッセージプール５２に登録する時点では、メッセージの転送先がどこであるかによって対応を変える必要はない。また、メッセージ収集手段４５が受信用転送メッセージプール５２からメッセージを読み出して送信メッセージを生成する際には、「エンティティヘッダ情報」に記載された転送経路の情報のうち、これからメッセージを送信しようとする送信先の情報を削除してからエンティティヘッダの部分を生成するようにしている。

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

ＨＴＴＰリクエストに埋め込まれて引き渡されるＳＯＡＰエンベロープには、端末装置コマンドを記載したものと、仲介サーバコマンドに対する応答を記載したものと、処理サーバコマンドに対する応答を記載したものとがある。
また、このような機能を有する仲介サーバ１０２が画像処理装置１００に送信するＨＴＴＰレスポンスの例を図１７に示す。

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

次に、仲介サーバ１０２が処理サーバ１０３に送信するＨＴＴＰリクエストの例を図１８に示す。
図１８に示すように、このＨＴＴＰリクエストは、形式としては図１６に示したＨＴＴＰリクエストと同様なものである。ただし、ＳＯＡＰエンベロープの内容については、当然コマンドやコマンド応答の内容に従って異なるものである。そして、このＨＴＴＰリクエストに埋め込まれて引き渡されるＳＯＡＰエンベロープには、端末装置コマンドを記載したものと、処理サーバコマンドに対する応答を記載したものとがある。

また、各パートのエンティティヘッダには、「X-Received-From」ヘッダとして、そのパートに記載されたＳＯＡＰメッセージの送信元を示す情報が、仲介サーバ１０２のメッセージ分配手段４７によって付加されている。そして、後述するように、処理サーバ１０３はこの情報をもとに端末装置コマンドに対する応答や処理サーバコマンドの転送経路を定めることができる。

また、仲介サーバ１０２が処理サーバ１０３から受信するＨＴＴＰレスポンスの例を図１９に示す。
図１９に示すように、このＨＴＴＰレスポンスは、形式としては図１８に示したＨＴＴＰレスポンスと同様なものである。ただし、ＳＯＡＰエンベロープの内容については、当然コマンドやコマンド応答の内容に従って異なるものである。そして、このＨＴＴＰレスポンスに埋め込まれて引き渡されるＳＯＡＰエンベロープには、処理サーバコマンドを記載したものと、端末装置コマンドに対する応答を記載したものとがある。

また、各パートのエンティティヘッダには、X-Send-Toヘッダとして、そのパートに記載されたＳＯＡＰメッセージの転送経路及び宛先を示す情報が付加されている。そして、仲介サーバ１０２のメッセージ収集手段４５は、この情報をもとにメッセージの転送先を認識することができる。

そして、以上のような形式のＨＴＴＰリクエストやＨＴＴＰレスポンスは、転送可能な１つのメッセージであり、各パートのＳＯＡＰエンベロープを、形式を変更せずに複数結合して生成することができる。また、このような形式のＨＴＴＰリクエストやＨＴＴＰレスポンスを分割して各パートのＳＯＡＰエンベロープを取り出せば、通常のウェブサービス（ＳＯＡＰ ＲＰＣ）機能を備えた他の通信装置との間で、ＨＴＴＰリクエストまたはＨＴＴＰレスポンスに１つのＳＯＡＰエンベロープを記載した通信に、そのまま使用することもできる。
なお、図１６及び図１７に示したような、画像処理装置１００と仲介サーバ１０２との間で授受するメッセージにおいては、ＳＯＡＰメッセージの宛先や転送経路を記載する必要はない。

次に、これらのＨＴＴＰリクエスト又はＨＴＴＰレスポンスに記載されるパートの具体例を図２０乃至図３１に示す。
図２０には、仲介サーバ（機器管理サーバ）１０２に対する端末装置コマンドを記載したパートの例を示す。
この例においては、まず、エンティティヘッダの部分の「X-SOAP-Type」ヘッダに、このパートに記載されているＳＯＡＰメッセージがＳＯＡＰリクエストであるかＳＯＡＰレスポンスであるかを示す情報を記載している。この例では、値の「Request」により、ＳＯＡＰリクエストであること、すなわちコマンドを記載したＳＯＡＰメッセージであることを示している。

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

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

また、ＳＯＡＰヘッダには、「要求ＩＤ」のＸＭＬタグの内容として、この端末装置コマンドのＩＤである「１２３４５」が記載されている。
ＳＯＡＰボディには、仲介サーバ１０２において呼び出すメソッドを指定する情報として、「Ｂｏｄｙ」タグの直下に、「異常通知」タグが記載され（「メソッド名」に該当し、コマンドの種別を示す）、その下位のタグ「エラーＩＤ」や「説明」の要素として、そのメソッドを呼び出す際の引数が記載されている（「入力パラメータ」に該当する）。ここでは異常通知の通知内容が記載されている。

なお、このパートに記載されたコマンドが仲介サーバ１０２で実行すべきものであることは、仲介サーバ１０２のメッセージ分配手段４７がコマンドの種類に従って認識するものである。従って、このパートにはコマンドの宛先や転送先は記載していないし、画像処理装置１００側で、このコマンドが最終的にどの装置で実行されるかを認識している必要はない。

図２１には、図２０に示した端末装置コマンドに対する応答を記載したパートの例を示す。
この例においては、まず、エンティティヘッダの部分の「X-SOAP-Type」ヘッダの値を「Response」と記載することにより、このパートに記載されているＳＯＡＰメッセージがＳＯＡＰレスポンスであること、すなわちコマンド応答を記載したＳＯＡＰメッセージであることを示している。
また、この例においても、名前空間の宣言は図２０に示した例と同様である。そして、ＳＯＡＰヘッダには、「コマンドＩＤ」のＸＭＬタグの内容として、応答を生成した端末装置コマンドのＩＤである「１２３４５」が記述されている。

ＳＯＡＰボディには、「Ｂｏｄｙ」タグの直下に、「異常通知」コマンドに対する応答であることを示すための「異常通知Response」タグ（コマンド応答の種別を示す）が設けられ、その下位のタグに、コマンド応答の内容が記載される。ここでは、異常通知を正常に受信した旨の情報が記載されている。そして、この情報は、後述するように、画像処理装置１００における端末装置コマンドシートの「出力パラメータ」の項目に格納される。
この分散処理システムにおいては、画像処理装置１００側に、コマンド応答がどの装置で生成されたものであるかを認識させる必要はないので、このパートにはコマンド応答の送信元は記載していない。

図２２には、処理サーバ（販売管理サーバ）１０３ａに対する端末装置コマンドを、画像処理装置１００から仲介サーバ１０２に転送する際のパートの記載例を示す。
この例においても、図２０の場合と同様に、「X-SOAP-Type」ヘッダの値の「Request」により、このパートに記載されているＳＯＡＰエンベロープがＳＯＡＰリクエストであることを示し、「SOAPAction」ヘッダの情報により、ＳＯＡＰリクエストの内容を示している。

また、「Envelope」タグの属性として、名前空間の宣言を行っている点も、図２０の場合と同様である。そしてここでは、ＳＯＡＰで標準として定義されている名前空間の他に、「http://www.example.com/header」及び「http://www.example.com/sales/server」のＵＲＩで特定される名前空間の宣言を行っている。
ＳＯＡＰヘッダには、「要求ＩＤ」のＸＭＬタグの内容として、この画像機器コマンドのＩＤである「１２３４６」が記載されている。

ＳＯＡＰボディには、「Ｂｏｄｙ」タグの直下に、処理サーバ１０３ａにおいて呼び出すメソッドを指定する情報として、「用紙注文」タグが記載され、その下位のタグ「商品名」や「数量」の要素として、そのメソッドを呼び出す際の引数が記載されている。ここでは用紙の注文内容が記載されている。
なお、このパートに記載されたコマンドが処理サーバ１０３ａに転送すべきものであることは、仲介サーバ１０２のメッセージ分配手段４７がコマンドの種類に従って認識するものである。従って、このパートにもコマンドの宛先や転送先は記載していないし、画像処理装置１００側で、このコマンドが最終的にどの装置で実行されるかを認識している必要はない。

図２３には、図２２に示したコマンドを仲介サーバ１０２から処理サーバ１０３ａに転送する際のパートの記載例を示す。
このパートは、図２２に示したものと同じコマンドを処理サーバ１０３ａに転送する際のものであるから、図２２に示したパートとほぼ同じ内容が記載されている。しかし、エンティティヘッダ部に「X-Received-From」ヘッダが追加され、このパートに記載されたコマンドが「Cilent_A」（画像処理装置１００とする）から送信されてきたことを示す情報が記載されている。そして、この情報は、コマンドが実行された後、コマンド応答を返す際の転送経路を指定するために使用される。

また、ここではコマンドの送信元である画像処理装置１００の識別情報が記載されているが、コマンドが複数装置に亘って転送されてきた場合には、転送毎に「X-Received-From」ヘッダが順次追加され、最上段にコマンドの送信元である装置、最下段に、パートを生成した装置から見て直近の転送元である装置の識別情報が記載される。
なおここでも、パートにはコマンドの宛先は記載する必要はない。仲介サーバ１０２は、コマンドを次に転送する転送先を認識しているのみであり、最終的にどの装置に転送されるかは認識していなくてもよいためである。

図２４には、処理サーバ１０３ａに対する端末装置コマンドに対する応答を、処理サーバ１０３ａから仲介サーバ１０２に転送する際のパートの記載例を示す。
この例においても、図２１の場合と同様に、エンティティヘッダの部分の「X-SOAP-Type」ヘッダの値を「Response」と記載することにより、このパートに記載されているＳＯＡＰメッセージがＳＯＡＰレスポンスであることを示している。

また、コマンド応答を仲介サーバ１０２から先に転送する際の転送経路を、「X-Send-To」ヘッダに記載している。ここでは、最終的な宛先となる画像処理装置１００の識別情報が記載されているが、転送経路が複数装置に亘る場合には、複数の「X-Send-To」ヘッダを設けて経路となる装置の識別情報を順次記載し、最下段に次の転送先となる装置、最上段に最終的な宛先となる装置の識別情報を記載する。
また、この例においても、名前空間の宣言は図２２に示した例と同様である。そして、ＳＯＡＰヘッダには、「コマンドＩＤ」のＸＭＬタグの内容として、応答を生成した端末装置コマンドのＩＤである「１２３４６」が記載されている。

ＳＯＡＰボディには、「Ｂｏｄｙ」タグの直下に、「用紙注文」コマンドに対する応答であることを示すための「用紙注文Response」タグが設けられ、その下位のタグに、コマンド応答の内容が記載される。ここでは、用紙注文を正常に受信した旨の情報及び、料金を通知する情報が記載されている。
この分散処理システムにおいては、仲介サーバ１０２側に、コマンド応答がどの装置で生成されたものであるかを認識させる必要はないので、このパートにはコマンド応答の送信元は記載していない。

図２５には、図２４に示したコマンド応答を仲介サーバ１０２から画像処理装置１００に転送する際のパートの記載例を示す。
このパートは、図２４に示したものと同じコマンド応答を画像処理装置１００に転送する際のものであるから、図２４に示したパートとほぼ同じ内容が記載されている。しかし、もはや画像処理装置１００に対して転送すべき旨の転送経路の情報は必要ないので、エンティティヘッダ部の「X-Send-To」ヘッダは削除している。

図２６には、画像処理装置に対する仲介サーバコマンドを記載したパートの例を示す。
この例においても、図２０の場合と同様に、「X-SOAP-Type」ヘッダの値の「Request」により、このパートに記載されているＳＯＡＰエンベロープがＳＯＡＰリクエストであることを示し、「SOAPAction」ヘッダの情報により、ＳＯＡＰリクエストの内容を示している。仲介サーバ１０２から画像処理装置１００へは直接コマンドを転送することができるので、転送経路の情報を示す「X-Send-To」ヘッダは記載していない。

また、「Envelope」タグの属性として、名前空間の宣言を行っている点も、図２０の場合と同様である。そしてここでは、ＳＯＡＰで標準として定義されている名前空間の他に、「http://www.example.com/header」及び「http://www.example.com/maintenance/client」のＵＲＩで特定される名前空間の宣言を行っている。
ＳＯＡＰヘッダには、「要求ＩＤ」のＸＭＬタグの内容として、この仲介サーバコマンドのＩＤである「９８７６５」が記載されている。

そして、ＳＯＡＰボディには、「Ｂｏｄｙ」タグの直下に、画像処理装置において呼び出すメソッドを指定する情報として、「温度センサ値取得」タグが記載され、その下位のタグ「センサＩＤ」の要素として、そのメソッドを呼び出す際の引数が記載されている。ここではセンサ値を取得するセンサのＩＤが記載されている。
また、画像処理装置１００側では、受信したコマンドに対するコマンド応答はとりあえず仲介サーバ１０２に送信すればよいということを認識できるようにしているので、パートには、コマンドの送信元の情報は記載していない。

図２７には、図２６に示した仲介サーバコマンドに対する応答を記載したパートの例を示す。
この例においても、図２１の場合と同様に、エンティティヘッダの部分の「X-SOAP-Type」ヘッダの値を「Response」と記載することにより、このパートに記載されているＳＯＡＰメッセージがＳＯＡＰレスポンスであることを示している。

また、この例においても、名前空間の宣言は図２６に示した例と同様である。そして、ＳＯＡＰヘッダには、「コマンドＩＤ」のＸＭＬタグの内容として、応答を生成した仲介サーバコマンドのＩＤである「９８７６５」が記載されている。
ＳＯＡＰボディには、「Ｂｏｄｙ」タグの直下に、「温度センサ値取得」コマンドに対する応答であることを示すための「温度センサ値取得Response」タグが設けられ、その下位のタグに、コマンド応答の内容が記載される。ここでは、値取得を要求されたセンサの示す温度値の情報が記載されている。

なお、このパートに記載されたコマンド応答が仲介サーバコマンドに対するものであり、仲介サーバ１０２が宛先となるものであることは、仲介サーバ１０２のメッセージ分配手段４７がコマンド応答の種別に従って認識するものである。従って、このパートにもコマンド応答の宛先や転送先を記載する必要はないし、画像処理装置１００側で、このコマンド応答が最終的にどの装置に転送されるかを認識している必要もない。

図２８には、画像処理装置に対する処理サーバコマンドを、処理サーバ１０３ａから仲介サーバ１０２に転送する際のパートの記載例を示す。
この例においても、図２０の場合と同様に、「X-SOAP-Type」ヘッダの値の「Request」により、このパートに記載されているＳＯＡＰエンベロープがＳＯＡＰリクエストであることを示し、「SOAPAction」ヘッダの情報により、ＳＯＡＰリクエストの内容を示している。また、処理サーバ１０３ａでは、コマンドの転送経路及び宛先を認識できるようにしており、コマンドを仲介サーバ１０２から先に転送する際の転送経路を、図２４の場合と同様に「X-Send-To」ヘッダに記載している。

また、「Envelope」タグの属性として、名前空間の宣言を行っている点は、図２０の場合と同様である。そしてここでは、ＳＯＡＰで標準として定義されている名前空間の他に、「http://www.example.com/header」及び「http://www.example.com/sales/client」のＵＲＩで特定される名前空間の宣言を行っている。
ＳＯＡＰヘッダには、「要求ＩＤ」のＸＭＬタグの内容として、この処理サーバコマンドのＩＤである「７７７７７」が記載されている。

ＳＯＡＰボディには、「Ｂｏｄｙ」タグの直下に、画像処理装置１００において呼び出すメソッドを指定する情報として、「新製品情報通知」タグが記載され、その下位のタグ「商品名」や「単価」の要素として、そのメソッドを呼び出す際の引数が記載されている。ここでは新製品の商品名や単価が記載されている。
仲介サーバ１０２は、後述するように、コマンドがどこから送信されてきたものかわからなくても、コマンド応答を適切な転送先に転送することができるので、パートにはコマンドの送信元の情報は記載していない。

図２９には、図２８に示した処理サーバコマンドを仲介サーバ１０２から画像処理装置１００に転送する際のパートの記載例を示す。
このパートは、図２８に示したものと同じ処理サーバコマンドを画像処理装置１００に転送する際のものであるから、図２８に示したパートとほぼ同じ内容が記載されている。しかし、もはや画像処理装置１００に対して転送すべき旨の転送経路の情報は必要ないので、エンティティヘッダ部の「X-Send-To」ヘッダは削除している。
画像処理装置１００側では、受信したコマンドに対するコマンド応答はとりあえず仲介サーバ１０２に送信すればよいということを認識できるようにしているし、その後コマンド応答がどこに転送されるかは認識する必要がないので、パートには、コマンドの送信元の情報は記載していない。

図３０には、図２８に示した処理サーバコマンドに対する応答を、画像処理装置１００から仲介サーバ１０２に転送する際のパートの記載例を示す。
この例においても、図２１の場合と同様に、エンティティヘッダの部分の「X-SOAP-Type」ヘッダの値を「Response」と記載することにより、このパートに記載されているＳＯＡＰメッセージがＳＯＡＰレスポンスであることを示している。

また、この例においても、名前空間の宣言は図２８に示した例と同様である。そして、ＳＯＡＰヘッダには、「コマンドＩＤ」のＸＭＬタグの内容として、応答を生成した処理サーバコマンドのＩＤである「７７７７７」が記載されている。
ＳＯＡＰボディには、「Ｂｏｄｙ」タグの直下に、「新製品情報通知」コマンドに対する応答であることを示すための「新製品情報通知Response」タグが設けられ、その下位のタグに、コマンド応答の内容が記載される。ここでは、通知を正常に受け付けた旨の情報が記載されている。

なお、このパートに記載されたコマンド応答が処理サーバコマンドに対するものであり、処理サーバ１０３ａに転送すべきものであることは、仲介サーバ１０２のメッセージ分配手段４７がコマンド応答の種別に従って認識するものである。従って、このパートにもコマンド応答の宛先や転送先を記載する必要はないし、画像処理装置１００側で、このコマンド応答が最終的にどの装置に転送されるかを認識している必要もない。また、仲介サーバ１０２も、このコマンド応答が最終的にどの装置に転送されるかを認識している必要はない。

図３１には、図３０に示したコマンド応答を仲介サーバ１０２から処理サーバ１０３ａに転送する際のパートの記載例を示す。
このパートは、図３０に示したものと同じコマンド応答を処理サーバ１０３ａに転送する際のものであるから、図３０に示したパートとほぼ同じ内容が記載されている。エンティティヘッダ部には、図２３の場合と同様に「X-Received-From」ヘッダを追加しているが、コマンド応答に対する応答を返してもらう必要はないので、ここではこの記載は必須ではない。パートにコマンド応答の宛先を記載しない点については、図２３の場合と同様である。

次に、以上説明したような構成及び機能を有する仲介サーバ１０２において実行する処理について、図３２乃至図４１のフローチャートを用いて説明する。これらのフローチャートに示す処理は、制御装置１２５のＣＰＵ（図３２乃至図４１の説明においては、特に断らない限り、単に「ＣＰＵ」と言った場合にはこのＣＰＵを指すものとする）が所要の制御プログラムを実行することによって行うものである。

まず、図３２にメッセージの収集及び分配処理の基本動作のフローチャートを示す。
ＣＰＵは、画像処理装置１００からＨＴＴＰリクエストが送信されてくると、図３２のフローチャートに示す処理を開始する。
そして、まず画像処理装置１００からそのＨＴＴＰリクエストを受信し（Ｓ１１）、受信したＨＴＴＰリクエストのＨＴＴＰボディを各パートに分割する（Ｓ１２）。ここで、各パートへの分割は、「MIME_boundary」で区分された要素に分割することであり、またここで全てのパートに関して分割する。

その後、分割して得た全てのパートを順に対象として、ステップＳ１３のメッセージ分配処理を繰り返す。そして、全てのパートについてこれらの処理を行った時点で、次のステップＳ１４に進む。
ここまでの処理において、ステップＳ１１及びＳ１２が第１の受信手順の処理であり、ここではＣＰＵはＨＴＴＰリクエスト受信手段４６ｂとして機能する。また、ステップＳ１３では、ＣＰＵはメッセージ分配手段４７として機能する。

ステップＳ１４以降の処理は、画像処理装置１００へのＨＴＴＰレスポンスの送信に関連する処理である。そして、この処理においてはまず、ＣＰＵは転送メッセージ収集処理を行う（Ｓ１４）。この処理は、受信用転送メッセージプール５２から画像処理装置１００に転送すべきメッセージを収集する処理であり、収集したメッセージから転送に係るパートを生成する処理を含む。
その後、仲介サーバコマンド収集処理を行う（Ｓ１５）。この処理は、仲介サーバコマンドプール４２から画像処理装置１００に送信すべき仲介サーバコマンドを収集する処理であり、収集したデータからＳＯＡＰエンベロープによるパートを生成する処理を含む。

次に、端末装置コマンドに対する応答である端末装置コマンド実行結果の収集処理を行う（Ｓ１６）。この処理は、端末装置コマンドプール４１から画像処理装置１００に送信すべきコマンド応答を収集する処理であり、やはり収集したデータからＳＯＡＰエンベロープによるパートを生成する処理を含む。
その後、ステップＳ１４乃至Ｓ１６の処理で生成したパートを１つにマージして、すべてのパートを含むＨＴＴＰレスポンスを生成し（Ｓ１７）、そのＨＴＴＰレスポンスを画像処理装置１００に送信する（Ｓ１８）。なお、ステップＳ１４乃至Ｓ１６の処理は、順不同でよい。
ここまでの処理において、ステップＳ１４乃至Ｓ１６ではＣＰＵはメッセージ収集手段４５として機能する。また、ステップＳ１７及びＳ１８が第２の送信手順の処理であり、ここではＣＰＵはＨＴＴＰレスポンス送信手段４６ａとして機能する。

次に、図３２のフローチャートに示した処理について、一部分ずつより詳細に示したフローチャートを用いて説明する。
図３３は、図３２に示したメッセージ分配処理の内容をより詳細に示したフローチャートである。

この処理においては、ＣＰＵは、まず対象パートのＳＯＡＰメッセージから、Ｂｏｄｙタグの直下のタグの名前空間ＵＲＩを取得する（Ｓ２１）。図２０乃至図３１の例に示したように、ＳＯＡＰメッセージにおいて、Ｂｏｄｙタグの直下のタグにはコマンドあるいはコマンド応答の種別を示すタグが記載されている。また、このタグには名前空間接頭辞（例えば図２０の場合には「ｎｓ」）が付されており、この名前空間接頭辞と、「Envelope」タグ中での名前空間の定義内容とから、タグの名前空間ＵＲＩを取得することができる。また、名前空間ＵＲＩは、タグのグルーピングに使用されるので、同じ名前空間ＵＲＩを有するコマンド又はコマンド応答は、同じ群に属するコマンド又はコマンド応答であると考えることができる。

次に、取得した名前空間ＵＲＩをキーに、転送先情報記憶手段５０に記憶している転送先テーブルを検索し、対象パートのメッセージの転送先の情報を取得する（Ｓ２２）。
この転送先テーブルの例を図３４に示す。
この図に示すように、転送先テーブルには、名前空間ＵＲＩ毎に、その名前空間に属するコマンド又はコマンド応答の転送先の情報を記載している。そして、転送先の情報は、ＩＰアドレスやホスト名等として記憶しておくと良い。このとき、異なる名前空間ＵＲＩに同じ転送先を対応させてももちろん構わない。

そして、ステップＳ２１で取得した名前空間ＵＲＩをキーにこのテーブルを検索することにより、対象パートのメッセージの転送先を取得することができる。このとき、対象パートのメッセージがコマンドに係るものであるかコマンド応答に係るものであるかを区別する必要はない。例えば、対象パートが図２０に示したパートであった場合には、「Ｂｏｄｙ」タグの直下のタグは「http://www.example.com/maintenance/server」の名前空間に属するから、そのパートに係るメッセージの転送先は仲介サーバ１０２自身であることがわかる。なお、名前空間ＵＲＩが転送先テーブルに含まれていないものであった場合には、エラー処理を行うとよい。

次に、ステップＳ２２で取得した転送先が仲介サーバ１０２（自分自身）であるか否か判断する（Ｓ２３）。そして、自分自身であれば、対象のパートは仲介サーバコマンドに対する応答又は仲介サーバが実行すべき端末装置コマンドであることがわかる。
そこで、対象のパートがそのいずれであるかを判断する。図３３には、仲介サーバコマンドに対する応答か否かを判断するものとして記載している（Ｓ２４）。そして、この判断は、対象のパートに「SOAPAction」ヘッダが存在するか否か、あるいは「X-SOAP-Type」ヘッダの内容によって判断することができる。

そして、仲介サーバコマンドに対する応答であれば、ステップＳ２５乃至Ｓ２８で、その応答の登録に係る処理を行う。
すなわち、まずそのパートのＳＯＡＰエンベロープを解析して仲介サーバコマンドシートに登録できる形式のデータに変換し（Ｓ２５）、仲介サーバコマンドプール４２からその応答に対応する仲介サーバコマンドを探索し、その仲介サーバコマンドについての仲介サーバコマンドシートの「出力パラメータ」の項目に応答のデータを登録する（Ｓ２６）。なお、コマンド応答には、「コマンドＩＤ」の情報として、仲介サーバコマンドの送信時に付したものと同じコマンドＩＤが付してあるものとし、仲介サーバコマンドの探索は、この情報をキーとして行うことができる。

データの登録が終わると、データを登録した仲介サーバコマンドシートの「状態」を「応答受信済」に変更してその旨を示す（Ｓ２７）。そして、「コマンド実行結果の通知先」に登録されている通知先に、応答があった旨を通知する（Ｓ２８）。この通知によって、仲介サーバコマンドを生成したアプリケーション等は、その生成したコマンドに応答があったことを認識し、応答に応じた処理を行うことができる。

例えば、画像処理装置１００での異常発生に対応するアプリケーションが画像処理装置１００の温度センサのセンサ値を取得する仲介サーバコマンドを生成した場合、このコマンドが画像処理装置１００に送信されると、画像処理装置１００は要求されたセンサ値を含むコマンド応答を返してくる。そして、仲介サーバ（機器管理サーバ）１０２側では、このコマンド応答を受信すると、ここに含まれるコマンドＩＤを基にどの仲介サーバコマンドに対する応答であるかを探索し、見つかった仲介サーバコマンドと対応させてそのコマンド応答を登録する。そして、そのコマンドの実行結果通知先として登録されている、異常発生に対応するアプリケーションに、応答があった旨を通知するのである。アプリケーションは、この通知を受けた場合に仲介サーバコマンドシートを参照すれば、生成したコマンドの実行結果を「出力パラメータ」の項目から取得することができる。
以上のステップＳ２８までの処理が終了すると、図３３の処理を終了して元の処理に戻る。

また、ステップＳ２４で仲介サーバコマンドに対する応答でなかった場合には、対象のパートは仲介サーバが実行すべき端末装置コマンドであるので、ステップＳ２９乃至Ｓ３３で、そのコマンドの登録に関する処理を行う。
すなわち、まずそのパートのＳＯＡＰエンベロープを解析して端末装置コマンドシートに登録できる形式のデータに変換し（Ｓ２９）、その端末装置コマンドを登録するための端末装置コマンドシートを端末装置コマンドプール４１に作成して（Ｓ３０）、端末装置コマンドとコマンドＩＤと送信元情報とをその端末装置コマンドシートに登録する（Ｓ３１）。

ここで、端末装置コマンドの内容は端末装置コマンドシートの「メソッド名」及び「入力パラメータ」の項目に登録し、パートに記載されていたコマンドＩＤは「コマンドＩＤ」の項目に登録する。また、「送信元情報」については、対象のパートが記載されていたＨＴＴＰリクエストの送信元情報を取得して登録することができる。また、対象のパートのエンティティヘッダに「X-Received-From」ヘッダがあった場合には、その内容も転送経路の情報として登録する。また、「状態」の初期値は「未処理」であり、「出力パラメータ」の初期値はＮＵＬＬである。

そして、以上の項目への登録が終了すると、端末装置コマンドシートの「メソッド名」に記憶させたメソッドを実行させるためのハンドラ（端末装置コマンドハンドラ４３ａ）への参照情報を、予め用意してあるメソッドとハンドラとの対応関係の情報を参照して検索し（Ｓ３２）、発見した参照情報を端末装置コマンドシートの「コマンドの通知先」の項目に登録する（Ｓ３３）。
以上のステップＳ３３までの処理が終了すると、図３３の処理を終了して元の処理に戻る。

また、ステップＳ２３で転送先が自分自身でなければ、対象のパートのメッセージは他の装置に転送すべきものであるので、ステップＳ３４乃至Ｓ３６で、転送用メッセージの登録に係る処理を行う。
すなわち、まずそのメッセージを登録するための転送メッセージシートを送信用転送メッセージプール５１に作成して（Ｓ３４）、メッセージ及びそのメッセージの転送先情報をその転送用メッセージシートに登録する（Ｓ３５）。

ここで、対象パートのエンティティヘッダをそのまま「エンティティヘッダ情報」の項目に登録し、ＳＯＡＰエンベロープの内容をそのまま「メッセージのＸＭＬデータ」の項目に登録する。また、「転送先情報」については、ステップＳ２２で取得した情報を登録する。
そして、以上の項目への登録が終了すると、「エンティティヘッダ情報」に登録したエンティティヘッダの末尾に、「X-Received-From」ヘッダを追加し、メッセージの送信元の情報として、対象のパートが記載されていたＨＴＴＰリクエストの送信元の情報を記載する（Ｓ３６）。
以上のステップＳ３６までの処理が終了すると、図３３の処理を終了して元の処理に戻る。
図３３の処理を終了した後は、図３２の処理に戻るが、この図に示したように、次のパートがあればそのパートを対象として図３３の処理を繰り返すことになる。

次に、図３５に、図３２のステップＳ１４に示した転送メッセージ収集処理をより詳細に示す。
この処理においては、ＣＰＵは、まず受信用転送メッセージプール５２から「X-Send-To」ヘッダの最下段に、図３２のステップＳ１１で受信したＨＴＴＰリクエストの送信元が記載されている転送メッセージシートを収集する（Ｓ４１）。なお、受信用転送メッセージプール５２中の転送メッセージシートに登録されている情報は図１５に示した通りであり、「X-Send-To」ヘッダは、このうち「エンティティヘッダ情報」の項目に登録されている。

次に、ステップＳ４１で収集した全ての転送メッセージシートを順次対象として、ステップＳ４２及びＳ４３の処理を繰り返す。
そして、この処理においては、まず対象の転送メッセージシートに記載された転送メッセージのパートを生成する（Ｓ４２）。この処理は、対象シートの「メッセージのＸＭＬデータ」の項目に登録されているＳＯＡＰエンベロープに、「エンティティヘッダ情報」の項目に登録されているエンティティヘッダを付すものである。ただし、エンティティヘッダ中の最下段の「X-Send-To」ヘッダの内容は、転送先の装置に伝える必要はないので、このヘッダは取り除くようにしている。
また、パートの作成が終了すると、対象の転送メッセージシートを受信用転送メッセージプール５２から削除する（Ｓ４３）。そして、収集した全てのシートについてこれらの処理を行った時点で、図３２のステップＳ１５に示した処理に進む。

次に、図３６に、図３２のステップＳ１５以降の処理をより詳細に示す。
この処理においては、ＣＰＵは、まず仲介サーバコマンドプール４２から、宛先情報が図３２のステップＳ１１で受信したＨＴＴＰリクエストの送信元と等しく、かつ「状態」が「未送信」である仲介サーバコマンドシートの「メソッド名」と「入力パラメータ」の内容を、送信すべき仲介サーバコマンドとして収集し、「コマンドＩＤ」の内容もそのコマンドのコマンドＩＤとして収集する（Ｓ５１）。「未送信」という「状態」は、コマンドが仲介サーバコマンド生成手段４４によって生成された後、まだ画像処理装置１００に送信されていないことを示すものであるので、これを基準に画像処理装置１００に送信すべきコマンドを抽出できる。

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

そして、収集した全ての仲介サーバコマンドについてこれらの処理を行った時点で、ステップＳ５５に進む。
ここでは、ＣＰＵは、端末装置コマンドプール４１から、送信元情報が図３２のステップＳ１１で受信したＨＴＴＰリクエストの送信元と等しく、かつ「状態」が「処理完了」である端末装置コマンドシートの「出力パラメータ」の内容を、端末装置コマンドに対するコマンド応答のうち送信すべきものとして収集し、「コマンドＩＤ」の内容も、対応する端末装置コマンドのコマンドＩＤとして収集する（Ｓ５５）。仲介サーバ１０２においては、「処理完了」という「状態」は、端末装置コマンドに対応する処理が端末装置コマンド実行結果生成手段４３によって生成された後、まだ画像処理装置１００に通知されていないことを示すものであるので、これを基準に画像処理装置１００に送信すべきコマンド応答を抽出できる。

その後、ステップＳ５５で収集した全てのコマンド応答を順次対象として、ステップＳ５６乃至Ｓ５８の処理を繰り返す。これらの処理は、まず対象のコマンド応答とその応答と共に収集したコマンドＩＤとを、これらの情報がそれぞれＳＯＡＰボディとＳＯＡＰヘッダとに含まれるＸＭＬ文書（ＳＯＡＰエンベロープ）に変換し（Ｓ５６）、これにエンティティヘッダを付加して対象のコマンドに関するパートを生成する（Ｓ５７）。これらの処理は、対象が異なる点以外はステップＳ５２及びＳ５３の処理と同じものである。そして、次に対象のコマンド応答を記載していた端末装置コマンドシートの「状態」を「応答済」に変更する（Ｓ５８）。「応答済」という「状態」は、ここではコマンド応答を画像処理装置１００に通知済であることを示すものである。

そして、ここまでの処理が全て完了した後、ＣＰＵは、ステップＳ５３，Ｓ５７又は図３５のステップＳ４２で生成した各パートをマージし、図１７に示したようなマルチパートのＨＴＴＰレスポンスを生成して画像処理装置１００に送信し（Ｓ５９）、処理を終了する。
以上のように、図３２乃至図３６を用いて説明したメッセージの分配及び収集の処理を行うことにより、仲介サーバ１０２は、画像処理装置１００から複数の動作要求及び動作応答を一括して受信して処理することができるし、それらに宛先が付されていない場合にも、適当な転送先を自動で認識し、転送先に応じた対応を行うことができる。また、自身が生成したり他の装置から受信したりした、画像処理装置１００に転送すべき複数の動作要求及び動作応答を、一括して画像処理装置１００に転送することもできる。

なお、ステップＳ５４又はＳ５８で行った「状態」の変更は、実際にこの送信が終了してから行うようにしてもよい。このようにすることにより、通信エラーが発生しても、送信しようとしていたコマンド及びコマンド応答を再度送信の対象とすることができるので、システムの信頼性が向上する。図３５のステップＳ４３で行った転送メッセージシートの削除についても同様である。
また、ここでは送信すべき全てのパートを全て生成してからマージして送信を行うようにし、また全てのパートを受信してからこれを各パートに分割して処理を行うように説明したが、このようにする必要はない。

送信については、まず始めにＨＴＴＰヘッダを送信し、以後パートを生成するたびにそのパートを順次送信し、全てのパートの送信が完了した時点でその旨のデータを送信するようにしてもよい。このようにしても、これらの課程で送信されるデータが１つのみのＨＴＴＰヘッダを持つ論理的に連続した１つのＨＴＴＰレスポンスであれば、１回のセッションで転送でき、ネゴシエーションの処理は１回で済むので、マージして送信する場合と同様な効果を得ることができる。また、送信すべきデータのバッファに必要なメモリ容量を低減できるので、低コストの通信装置で大きなデータを取り扱うことができる。
また、受信側でも、各パートに関する処理を、各パートを受信するたびに順次行うようにすることができる。このようにした場合にメモリ容量を低減できることは、送信側の場合と同様である。

次に、端末装置コマンドの実行に関する処理について説明する。
図３７は、この処理の一例を示すフローチャートである。
端末装置コマンドの実行に関する処理としては、まず、図３７のフローチャートに示す処理を、図３３に示したステップＳ３３の処理の後に、すなわち端末装置コマンドを端末装置コマンドプール４１に登録した直後に行うことが考えられる。この処理において、ＣＰＵは、端末装置コマンド実行結果生成手段４３として機能する。

そして、この処理においては、まず登録した端末装置コマンドについての端末装置コマンドシートの「コマンドの通知先」の情報に基づいてアプリケーション等を呼び出し、「メソッド名」や「入力パラメータ」のデータを渡して端末装置コマンドに係る処理を実行させる（Ｓ６１）。なお、端末装置コマンドに係る処理自体は、このフローチャートには示していないが、ハンドラを用いてＣＰＵが別途実行することになる。

そして、これが完了すると、実行結果を取得して端末装置コマンドシートの「出力パラメータ」の項目に登録する（Ｓ６２）と共に、端末装置コマンドシートの「状態」を「処理完了」に変更し、処理が完了したことを示す（Ｓ６３）。以上の処理を行うことにより、端末装置コマンドを実行し、その結果をコマンド応答として画像処理装置１００に送信可能な状態にすることができる。

また、端末装置コマンドの実行に関する処理としては、図３２に示した画像処理装置１００との間のメッセージの送受信に係る処理とは独立して、図３８のフローチャートに示す処理を行うようにすることもできる。この処理においても、ＣＰＵは、端末装置コマンド実行結果生成手段４３として機能する。
この処理は、ＣＰＵが仲介サーバ１０２の起動時に開始するものである。そして、この処理においては、まず端末装置コマンドプール４１に「状態」が「未処理」である端末装置コマンドシートがあるか否か判断し（ＳＸ１）、なければこのような端末装置コマンドシートを発見するまで待機する。なお、上述のように、「未処理」という状態は、端末装置コマンドシートにおける「状態」の初期値であり、コマンドの登録後に特に処理が行われていないことを示すものである。

ステップＳＸ１で「未処理」の端末装置コマンドシートを発見した場合には、その１つを処理対象とし、その端末装置コマンドシートの「状態」を「処理中」に変更する（ＳＸ２）。
その後、図３７の場合と同様なステップＳ６１乃至Ｓ６３の処理を行って処理対象の端末装置コマンドシートに記載された端末装置コマンドを実行し、これが完了するとステップＳＸ１に戻って処理を繰り返す。

なお、以上の処理は、複数のスレッド（例えば４スレッド）で同時に行うようにしてもよい。処理対象となった端末装置コマンドシートの「状態」は、「未処理」ではないため、複数のスレッドで同時に処理を行っても、１つの端末装置コマンドシートを重複して処理対象としてしまうことはない。
以上のような処理を行うようにすれば、任意のタイミングで端末装置コマンドを実行することができるので、実行に時間のかかるコマンドがあった場合でも、以後の処理が滞ることがない。そして、実行の終了したものから順に、その結果をコマンド応答として画像処理装置に送信可能な状態にすることができる。

次に、図３９に、処理サーバとの間でのメッセージの転送に係る処理のフローチャートを示す。この処理は、ＣＰＵが、図３４に示した転送先テーブルに記載されている転送先のいずれか（ここでは処理サーバ１０３とする）を対象として、適当なタイミングで実行するものである。
この処理においては、まず送信用転送メッセージプール５１から、対象の転送先が「転送先情報」の項目に登録された転送メッセージシートを収集する（Ｓ７１）。そして、ステップＳ７１で収集した全ての転送メッセージシートを順次対象として、ステップＳ７２及びＳ７３の処理を繰り返す。

そして、これらの処理においては、まず対象の転送メッセージシートに記載された転送メッセージのパートを生成する（Ｓ７２）。この処理は、対象シートの「メッセージのＸＭＬデータ」の項目に登録されているＳＯＡＰエンベロープに、「エンティティヘッダ情報」の項目に登録されているエンティティヘッダを付すものである。

また、パートの作成が終了すると、対象の転送メッセージシートを送信用転送メッセージプール５１から削除する（Ｓ７３）。そして、収集した全てのシートについてこれらの処理を行った時点で、生成したパートを１つにマージし（Ｓ７４）、図１８に示したようなマルチパートのＨＴＴＰリクエストを生成して対象の転送先に送信する（Ｓ７５）。
ここまでの処理において、ステップＳ７１乃至Ｓ７３ではＣＰＵはメッセージ転送手段４８として機能する。また、ステップＳ７４及びＳ７５が第１の送信手順の処理であり、ここではＣＰＵはＨＴＴＰリクエスト送信手段４９ａとして機能する。
なお、ステップＳ７３で行った転送メッセージシートの削除は、実際にこの送信が終了してから行うようにしてもよいことは、上述した図３５のステップＳ４３の場合と同様である。

次に、送信したＨＴＴＰリクエストに対する通信応答として、対象の転送先からＨＴＴＰレスポンスを受信する（Ｓ７６）。そして、受信したＨＴＴＰレスポンスのＨＴＴＰボディを各パートに分割する（Ｓ７７）。ここで、各パートへの分割は、図３２のステップＳ１２の場合と同様、「MIME_boundary」で区分された要素に分割することであり、またここで全てのパートに関して分割する。

そしてその後、分割して得た全てのパートを順に対象として、ステップＳ７８及びＳ７９の処理を繰り返す。
これらの処理においては、まず対象のメッセージを登録するための転送メッセージシートを受信用転送メッセージプール５２に作成して（Ｓ７８）、対象のメッセージをその転送用メッセージシートに登録する（Ｓ７９）。ここで、対象パートのエンティティヘッダをそのまま「エンティティヘッダ情報」の項目に登録し、ＳＯＡＰエンベロープの内容をそのまま「メッセージのＸＭＬデータ」の項目に登録する。「X-Send-To」ヘッダもこの時点では削除しない。

ステップＳ７７で得た全てのパートについてこれらの処理を行った時点で、図３９の処理を終了する。
以上の処理において、ステップＳ７６及びＳ７７が第２の受信手順の処理であり、ここではＣＰＵはＨＴＴＰレスポンス受信手段４９ｂとして機能する。ステップＳ７８及びＳ７９ではＣＰＵはメッセージ転送手段４８として機能する。

ここで、図４０に、図３９に示したメッセージ転送処理の実行タイミング制御に係る処理のフローチャートを示す。
この処理は、ＣＰＵが仲介サーバ１０２の起動時に開始するものである。そして、この処理は、一定時間毎に、図３４に示した転送先テーブルに記載されている全ての転送先を順次対象として図３９に示したのメッセージ転送処理を行うものである。この場合において、同じ転送先が転送先テーブルに複数回登場する場合にも、１つの転送先について１回のメッセージ転送処理を行えば足りる。

このように、メッセージを転送し得る全ての転送先について定期的にメッセージ転送処理を行って通信要求であるＨＴＴＰリクエストを送信するようにすれば、仲介サーバ１０２から転送先への通信を、常に仲介サーバ１０２側から通信要求を送信することによって行うようにする場合でも、転送先から仲介サーバ１０２に情報を送信する機会を与えることができ、仲介サーバ１０２に対する転送の必要な情報が長期間に亘って処理サーバ１０３等に滞留してしまうことを防止できる。

なお、メッセージ転送処理を、定期的なタイミング以外に適宜行ってよいことはもちろんである。例えば、緊急に送信が必要な情報がいずれかのプールに登録された場合に、メッセージ分配手段４７がメッセージ転送手段４８にその旨を通知してメッセージ転送処理を行わせるようにしてもよい。このようにすれば、コマンドが登録された場合にこれを直ちに転送先に転送することができる。

以上のように、図３９及び図４０に示したメッセージの転送に関する処理を行うことにより、複数の転送先の各々について、その転送先に転送すべき動作要求及び動作応答を一括して転送すると共に、その転送先から画像処理装置１００に送信すべき動作要求及び動作応答を一括して受信し、それぞれを独立に画像処理装置１００に対して送信可能な状態で記憶しておくことができる。

なお、画像処理装置１００側からのコマンドを取り扱うのみでよい場合においては、図３９及び図４０に示した処理に代えて、あるいはそれに加えて、図４１のフローチャートに示すような処理を行うことも考えられる。
この処理は、図３８の場合と同様、ＣＰＵが仲介サーバ１０２の起動時に開始するものである。そして、この処理においては、まず送信用転送メッセージプール５１にコマンドを記載した転送メッセージシートがあるか否か判断し（Ｓ９１）、なければこのような転送メッセージシートを発見するまで待機する。

ステップＳ９１でコマンドを記載した転送メッセージシートを発見した場合には、その１つを処理対象とし、その転送メッセージシートに記載された「X-Received-From」ヘッダの内容を記憶する（Ｓ９２）。そして、対象シートの「転送先情報」を参照し、対象シートに記載された転送メッセージ（ＳＯＡＰリクエスト）を記載したＨＴＴＰリクエストを、その転送先に送信する（Ｓ９３）。なお、転送メッセージの生成に際しては、「メッセージのＸＭＬデータ」の項目に登録されているＳＯＡＰエンベロープに、必要なＨＴＴＰヘッダを付せばよい。このとき、「エンティティヘッダ情報」の項目に登録されているエンティティヘッダ情報を利用することができる。

その後、転送先から、送信したＨＴＴＰリクエストに対するＨＴＴＰレスポンスを受信するが（Ｓ９４）、これには送信したＳＯＡＰリクエストに対するＳＯＡＰレスポンスが記載されているはずである。そこで、受信用転送メッセージプール５２に転送メッセージシートを作成し、受信したＨＴＴＰレスポンスに記載されているＳＯＡＰメッセージの内容を、その作成した転送メッセージシートに登録する（Ｓ９５）。この登録については、ＳＯＡＰエンベロープの部分をそのまま「メッセージのＸＭＬデータ」の項目に登録し、ＨＴＴＰヘッダ中の必要な部分を「エンティティヘッダ情報」の項目に登録すればよい。

そして、作成した転送メッセージシートの「エンティティヘッダ情報」に、「X-SOAP-Type」ヘッダ及びその内容として「Response」を追加すると共に、「X-Send-To」ヘッダを追加し、ステップＳ９２で記憶しておいた「X-received-From」ヘッダの内容をここに記載する（Ｓ９６）。そして、ステップＳ９１に戻って処理を繰り返す。
以上の処理により、コマンドの転送先からコマンド応答を取得してその内容を受信用転送メッセージプール５２に登録することができるので、登録したコマンド応答は、図３９及び図４０の処理によって登録した場合と同様に、メッセージ収集手段４５によって収集して画像処理装置１００に送信することができる。

また、このような処理を行うようにすれば、転送先の装置が図３９に示したような一括転送に対応していない場合でも、コマンドを転送して実行させることができる。そして、コマンドが登録された場合にこれを直ちに転送先に転送することもできる。
以上で、仲介サーバ１０２において実行する、各コマンド及びコマンド応答の転送に関する処理の説明を終了する。

次に、画像処理装置１００側においてコマンド及びコマンド応答を取り扱うための機能構成について説明する。ハードウェアについては、図９を用いて説明した通りである。
図４２は、画像処理装置１００の機能のうち、コマンド及びコマンド応答に関する処理を行うための機能の構成を示す機能ブロック図である。
図４２に示す機能のうち、端末装置コマンドプール１４１及びサーバ側コマンドプール１４２は、いずれかの書き換え可能な記憶手段に設けられるものである。例えばＮＶＲＡＭ２０７に設けることができるが、ＳＤＲＡＭ２０３やＨＤＤ２１０に設けてもよい。端末装置コマンド生成手段１４３、サーバ側コマンド実行結果生成手段１４４、メッセージ収集手段１４５、メッセージ分配手段１４７の機能は、ＣＰＵ２０１によって実現されるものである。また、ＨＴＴＰクライアント機能部１４６の機能は、ＣＰＵ２０１及びＰＨＹ２０６によって実現されるものである。

なお、画像処理装置１００においては、コマンドの送信元が仲介サーバ１０２であっても処理サーバ１０３であっても共通の取扱いをするようにしているので、画像処理装置１００に関する説明においては、上述した仲介サーバコマンドと処理サーバコマンドとを併せて「サーバ側コマンド」と呼ぶことにする。

これらの機能についてさらに詳述する。
まず、端末装置コマンドプール１４１は、端末装置コマンドと、このコマンドに対する応答と、このコマンドの識別情報とを関連付けて登録するプールである。また、サーバ側コマンドプール１４２は、サーバ側コマンドと、このコマンドに対する応答と、このコマンドの識別情報とを関連付けて登録するプールである。これらのプールにおいては、コマンド毎にテーブル形式のコマンドシートを作成して情報を格納することにより、コマンドと、識別情報や応答等の情報とを関連付けるようにしている。

端末装置コマンド生成手段１４３は、要求生成手段に該当する。そして、端末装置コマンドを生成し、このコマンドを識別する識別情報（ＩＤ）を割り当て、さらにこのコマンドを管理するための管理情報を付し、これらの情報を関連付けてテーブル形式の端末装置コマンドシートとして端末装置コマンドプール１４１に登録する機能を有する。このうち、端末装置コマンドを生成する部分には、例えば画像処理装置１００に備えるアプリケーションが該当する。また、端末装置コマンド生成手段１４３に、転送先で各コマンドを実行させる際の優先順位を、生成した端末装置コマンドに付する機能を設けてもよい。

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

各項目の内容については、仲介サーバ１０２における端末装置コマンドシートあるいは仲介サーバコマンドシートの同名の項目の内容と同様なものであるので、説明を省略する。なお、画像処理装置１００は、端末装置コマンドを仲介サーバ１０２に送信してしまえば、それがその後どの装置に転送されて処理されるかを認識する必要はないので、「宛先情報」の項目は設けていない。

図４２の説明に戻ると、サーバ側コマンド実行結果生成手段１４４は、応答生成手段に該当する。そして、サーバ側コマンドプール１４２からサーバ側コマンドを読み出して実行するアプリケーションである。そして、サーバ側コマンドに対する応答を生成し、サーバ側コマンドのコマンドＩＤと関連付けてサーバ側コマンドプール１４２に登録する機能を有する。なお、仲介サーバ１０２から受信したサーバ側コマンドは、このコマンドを識別するＩＤ及びこのコマンドを管理するための管理情報と関連付けて、テーブル形式のサーバ側コマンドシートとしてサーバ側コマンドプール１４２に登録しておくようにしている。そして、サーバ側コマンド実行結果生成手段１４４が生成したコマンド応答も、実行したサーバ側コマンドについてのサーバ側コマンドシートに登録する。

また、サーバ側コマンド実行結果生成手段１４４に、サーバ側コマンドプール１４２から複数の種類のサーバ側コマンドを読み出し、各サーバ側コマンドに対する応答を生成する機能を設けることが考えられる。さらに、サーバ側コマンドが画像処理装置１００に優先して処理を実行させるための実行優先順位の情報を含む場合には、優先順位の高いものから優先的に読み出して実行する機能を設けることも考えられる。
なお、サーバ側コマンド実行結果生成手段１４４は、アプリケーションそのものではなく、サーバ側コマンドの実行に必要なアプリケーションを呼び出してコマンドを実行させるモジュールであってもよい。

ここで、図４４に画像処理装置１００のサーバ側コマンドシートにおけるデータ構造の例を示す。
この図に示すように、画像処理装置１００においては、サーバ側コマンドシートには、「コマンドＩＤ」、「メソッド名」、「入力パラメータ」、「状態」、「出力パラメータ」、および「コマンドの通知先」のデータを記憶する領域を設けている。そして、このうち「コマンドＩＤ」、「メソッド名」、および「入力パラメータ」がサーバ側コマンド（及びそこに付されたＩＤ）に該当し、「状態」及び「コマンドの通知先」が管理情報に該当する。「出力パラメータ」は、サーバ側コマンドの実行結果であり、画像処理装置１００が返すコマンド応答の内容となる。

各項目の内容については、仲介サーバ１０２における仲介サーバコマンドシート又は端末装置コマンドシートの同名の項目の内容と同様なものであるので、説明を省略する。なお、画像処理装置１００は、サーバ側コマンドに対する応答を仲介サーバ１０２に送信してしまえば、それがその後どの装置に転送されるかを認識する必要はないので、「送信元情報」の項目は設けていない。

再び図４２の説明に戻ると、メッセージ収集手段１４５は、収集手段に該当する。そして、サーバ側コマンド実行結果生成手段１４４が生成したコマンド応答とこのコマンド応答に対応するサーバ側コマンドのコマンドＩＤとを関連付けてサーバ側コマンドプール１４２から読み出すと共に、端末装置コマンド生成手段１４３が生成した端末装置コマンドとこのコマンドのコマンドＩＤとを関連付けて端末装置コマンドプール１４１から読み出し、これらから送信メッセージを生成する機能を有する。

なお、コマンド応答や端末装置コマンドに実行優先順位が指定されている場合には、メッセージ収集手段１４５がそれぞれ実行優先順位の高いものから順に読み出すようにすることが考えられる。
送信メッセージの記載形式や生成方式については、仲介サーバ１０２について説明したものと同様である。

また、ＨＴＴＰクライアント機能部１４６は、ＨＴＴＰリクエストを送信するＨＴＴＰリクエスト送信手段１４６ａとＨＴＴＰレスポンスを受信するＨＴＴＰレスポンス受信手段１４６ｂとを備える。
そして、ＨＴＴＰリクエスト送信手段１４６ａは、送信手段に該当し、メッセージ収集手段１４５が生成した送信メッセージを含むＨＴＴＰリクエストを生成し、仲介サーバ１０２に送信する機能を有する。このとき、１つのＨＴＴＰリクエストに送信メッセージをいくつ含めてもよいし、コマンド応答に係る送信メッセージと端末装置コマンドに係る送信メッセージとを任意に混在させることもできる。

そこで、ＨＴＴＰリクエスト送信手段１４６ａは、これらのいずれに係る送信メッセージかに関わり無く、メッセージ収集手段１４５が生成した全ての送信メッセージを１つのＨＴＴＰリクエストに含めて送信するようにしている。ただし、１つのＨＴＴＰリクエストに含める送信メッセージの数に上限を設けることも考えられる。

ところで、このＨＴＴＰリクエストの送信は、メッセージ収集手段１４５が端末装置コマンドやコマンド応答等の読み出しを試みた場合には、読み出すデータがなく、結果的に送信すべきＳＯＡＰメッセージを生成しなかった場合にも行うものである。そして、この読み出しの試みは、定期的に行うものとする。例えば、タイマによって６０分毎に読み出すことが考えられる。

このようにするのは、上述のように、仲介サーバ１０２から画像処理装置１００に送信したい情報があったとしても画像処理装置１００から通信を要求しない限り送信できないためである。画像処理装置１００から何も送信するデータがなかったとしても、定期的に仲介サーバ１０２に対して通信要求を送信して、仲介サーバ１０２から画像処理装置１００に情報を送信する機会を与えることにより、転送の必要な情報が長期間に亘って仲介サーバ１０２に滞留してしまうことを防止できる。

なお、メッセージ収集手段１４５による読み出しと、それに続くＨＴＴＰリクエスト送信手段１４６ａによるＨＴＴＰリクエストの送信とを、定期的なタイミング以外に適宜行ってよいことはもちろんである。例えば、緊急に送信が必要な情報がいずれかのプールに登録された場合に、端末装置コマンド生成手段１４３あるいはサーバ側コマンド実行結果生成手段１４４がメッセージ収集手段１４５にその旨を通知して読み出しを行わせるようにしてもよい。

また、ＨＴＴＰレスポンス受信手段１４６ｂは、受信手段に該当し、仲介サーバ１０２からＨＴＴＰレスポンスを受信する機能を有する。そしてここでは、ＨＴＴＰレスポンスには、サーバ側コマンド及びそのコマンドと関連付けられたコマンドＩＤを含む受信メッセージと、端末装置コマンドに対する応答及びそのコマンドと関連付けられたコマンドＩＤを含む受信メッセージとが、任意に混在して含まれている。
ここで、受信メッセージの記載形式については、仲介サーバ１０２について説明したものと同様である。

メッセージ分配手段１４７は、分配手段に該当する。そして、ＨＴＴＰレスポンス受信手段１４６ｂが受信したＨＴＴＰレスポンスに含まれるデータを、端末装置コマンドプール１４１及びサーバ側コマンドプール１４２に振り分けて登録する機能を有する。
具体的には、サーバ側コマンド及びそのコマンドと関連付けられたコマンドＩＤとをサーバ側コマンドプール１４２にサーバ側コマンドシートを設けて登録すると共に、端末装置コマンドに対する応答については、そのコマンドと関連付けられたコマンドＩＤを端末装置コマンドプール１４１に記憶している端末装置コマンドシートのコマンドＩＤと照合して対応する端末装置コマンドを特定し、その端末装置コマンドについての「出力パラメータ」として登録する。
この登録の際のデータ変換方式についても、仲介サーバ１０２について説明したものと同様である。

次に、以上説明したような構成及び機能を有する画像処理装置１００において実行する処理について、図４５乃至図４７のフローチャートを用いて説明する。これらのフローチャートに示す処理は、画像処理装置１００のＣＰＵ２０１が所要の制御プログラムを実行することによって行うものである。

まず、図４５にメッセージの収集及び分配処理の基本動作のフローチャートを示す。
ＣＰＵ２０１は、メッセージ収集手段１４５が端末装置コマンドやコマンド応答等の読み出しを試みるタイミングになると、図４５のフローチャートに示す処理を開始する。
そして、まず端末装置コマンドの収集処理を行う（Ｓ１１１）。この処理は、端末装置コマンドプール１４１から仲介サーバ１０２に送信すべき端末装置コマンドを収集する処理であり、収集したデータからＳＯＡＰエンベロープによるパートを生成する処理を含む。

次に、サーバ側コマンドに対する応答であるサーバ側コマンド実行結果の収集処理を行う（Ｓ１１２）。この処理は、サーバ側コマンドプール１４２から仲介サーバ１０２に送信すべきコマンド応答を収集する処理であり、やはり収集したデータからＳＯＡＰエンベロープによるパートを生成する処理を含む。

その後、ステップＳ１１１及びＳ１１２の処理で生成したパートを１つにマージして、すべてのパートを含むＨＴＴＰリクエストを生成し（Ｓ１１３）、そのＨＴＴＰリクエストを仲介サーバ１０２に送信する（Ｓ１１４）。
ここまでの処理において、ステップＳ１１１及びＳ１１２ではＣＰＵ２０１はメッセージ収集手段１４５として機能し、ステップＳ１１３及びＳ１１４ではＨＴＴＰリクエスト送信手段１４６ａとして機能する。

次に、ＨＴＴＰリクエストに対する通信応答として仲介サーバ１０２からＨＴＴＰレスポンスを受信する（Ｓ１１５）。そして、受信したＨＴＴＰレスポンスのＨＴＴＰボディを各パートに分割する（Ｓ１１６）。ここで、各パートへの分割は、「MIME_boundary」で区分された要素に分割することであり、またここで全てのパートに関して分割する。

そしてその後、分割して得た全てのパートを順に対象として、ステップＳ１１７乃至Ｓ１１９の処理を繰り返す。この処理においては、まず対象のパートが端末装置コマンドに対する応答を記載したパートか否か判断する（Ｓ１１７）。そして、端末装置コマンドに対する応答であれば応答通知処理を行う（Ｓ１１８）。また、端末装置コマンドに対する応答でないときは、サーバ側コマンドが記載されたパートであるので、サーバ側コマンド登録処理を行う（Ｓ１１９）。

ステップＳ１１８又はＳ１１９の後は、ステップＳ１１７に戻り、次のパートを対象として処理を繰り返す。そして、全てのパートについてこれらの処理を行った時点で、図４５のフローチャートに示す処理を終了する。
ここまでの処理において、ステップＳ１１５及びＳ１１６ではＣＰＵ２０１はＨＴＴＰレスポンス受信手段１４６ｂとして機能し、ステップＳ１１７乃至Ｓ１１９ではメッセージ分配手段１４７として機能する。

次に、図４５のフローチャートに示した処理について、一部分ずつより詳細に示したフローチャートを用いて説明する。
図４６は、図４５のステップＳ１１４までの部分の処理をより詳細に示したフローチャートである。

この処理においては、ＣＰＵ２０１はまず、端末装置コマンドプール１４１から、「状態」が「未送信」である端末装置コマンドシートの「メソッド名」と「入力パラメータ」の内容を、送信すべき端末装置コマンドとして収集し、「コマンドＩＤ」の内容もそのコマンドのコマンドＩＤとして収集する（Ｓ１２１）。「未送信」という「状態」は、コマンドが端末装置コマンド生成手段１４３によって生成された後、まだ仲介サーバ１０２に通知されていないことを示すものであるので、これを基準に仲介サーバ１０２に送信すべきコマンドを抽出できる。

その後、ステップＳ１２１で収集した全ての端末装置コマンドを順次対象として、ステップＳ１２２乃至Ｓ１２４の処理を繰り返す。これらの処理においては、まず対象の端末装置コマンドとそのコマンドＩＤとを、これらの情報がそれぞれＳＯＡＰボディとＳＯＡＰヘッダとに含まれるＳＯＡＰエンベロープに変換し（Ｓ１２２）、これにエンティティヘッダを付加して対象のコマンドに関するパートを生成する（Ｓ１２３）。そして、対象の端末装置コマンドを記載していた端末装置コマンドシートの「状態」を「応答待ち」に変更する（Ｓ１２４）。「応答待ち」という「状態」は、コマンドを仲介サーバ１０２に通知済であることを示すものである。

これらが全て完了した後、ＣＰＵ２０１は、サーバ側コマンドプール１４２から、「状態」が「処理完了」であるサーバ側コマンドシートの「出力パラメータ」の内容を、サーバ側コマンドに対するコマンド応答のうち送信すべきものとして収集し、「コマンドＩＤ」の内容も、対応するサーバ側コマンドのコマンドＩＤとして収集する（Ｓ１２５）。「処理完了」という「状態」は、サーバ側コマンドに対応する処理がサーバ側コマンド実行結果生成手段１４４によって生成された後、まだ仲介サーバ１０２に通知されていないことを示すものであるので、これを基準に仲介サーバ１０２に送信すべきコマンド応答を抽出できる。

その後、ステップＳ１２５で収集した全てのコマンド応答を順次対象として、ステップＳ１２６乃至Ｓ１２８の処理を繰り返す。これらの処理は、まず対象のコマンド応答とその応答と共に収集したコマンドＩＤとを、これらの情報がそれぞれＳＯＡＰボディとＳＯＡＰヘッダとに含まれるＳＯＡＰエンベロープに変換し（Ｓ１２６）、これにエンティティヘッダを付加して対象のコマンド応答に関するパートを生成する（Ｓ１２７）処理である。これらの処理は、対象が異なる点以外はステップＳ１２２及びＳ１２３の処理と同じものである。そして、次に対象のコマンド応答を記載していたサーバ側コマンドシートの「状態」を「応答済」に変更する（Ｓ１２８）。「応答済」という「状態」は、コマンド応答を仲介サーバ１０２に通知済であることを示すものである。

そして、ここまでの処理が全て完了した後、ＣＰＵ２０１は、ステップＳ１２３又はＳ１２７で生成した各パートをマージし、図１６に示したようなマルチパートのＨＴＴＰリクエストを生成して仲介サーバ１０２に送信する（Ｓ１２９）。
なお、ステップＳ１２４又はＳ１２８で行った「状態」の変更は、実際にこの送信が終了してから行うようにしてもよい。このようにすることにより、通信エラーが発生しても、送信しようとしていたコマンド及びコマンド応答を再度送信の対象とすることができるので、システムの信頼性が向上する。
以上でＨＴＴＰリクエストの送信に関する処理を終了し、図４５のステップＳ１１５以降に相当する処理に進む。

図４７は、図４５のステップＳ１１５以降の部分の処理をより詳細に示すフローチャートである。図４６のステップＳ１２９の次の処理は、この図ではステップＳ１３１に該当する。
この処理においては、ＣＰＵ２０１はまず、送信したＨＴＴＰリクエストに対するＨＴＴＰレスポンスの受信を待ち、仲介サーバ１０２からこれを受信する（Ｓ１３１）。これを受信すると、そのＨＴＴＰボディを解析して各パートに分割する（Ｓ１３２）。
そしてその後、分割して得た各パートを順次対象として、ステップＳ１３３乃至ステップＳ１４２の処理を繰り返す。

この部分の処理においては、まず、対象のパートが端末装置コマンドに対する応答であるか否か判断する（Ｓ１３３）。上述したように、ＨＴＴＰレスポンスには、サーバ側コマンドと、端末装置コマンドに対する応答とが含まれている可能性があるので、対象のパートがこのいずれであるかを判断するのである。そして、この判断は、対象のパートに「SOAPAction」ヘッダが存在するか否か、あるいは「X-SOAP-Type」ヘッダの内容によって判断することができる。

ステップＳ１３３で端末装置コマンドに対する応答であれば、ステップＳ１３４乃至Ｓ１３７の、その応答の登録に係る処理を行う。
すなわち、まずそのパートのＳＯＡＰエンベロープを解析して端末装置コマンドシートに登録できる形式のデータに変換し（Ｓ１３４）、端末装置コマンドプール１４１からそのコマンド応答に対応する端末装置コマンドを探索し、その端末装置コマンドについての端末装置コマンドシートの「出力パラメータ」の項目にコマンド応答のデータを登録する（Ｓ１３５）。なお、コマンド応答には、「コマンドＩＤ」の情報として、端末装置コマンドの送信時に付したものと同じコマンドＩＤが付してあるものとし、端末装置コマンドの探索は、この情報をキーとして行うことができる。

データの登録が終わると、データを登録した端末装置コマンドシートの「状態」を「応答受信済」に変更してその旨を示す（Ｓ１３６）。そして、「コマンド実行結果の通知先」に登録されている通知先に、応答があった旨を通知する（Ｓ１３７）。この通知によって、端末装置コマンドを生成したアプリケーション等は、その生成したコマンドに応答があったことを認識し、応答に応じた処理を行うことができる。

例えば、異常通知を発するアプリケーションが異常通知を行う旨の端末装置コマンドを生成した場合、このコマンドが仲介サーバ１０２に送信されると、仲介サーバ１０２はこれを正しく受け取った旨のコマンド応答を返してくる。そして、画像処理装置１００側では、このコマンド応答を受信すると、ここに含まれるコマンドＩＤを基にどの端末装置コマンドに対する応答であるかを探索し、見つかった端末装置コマンドと対応させてそのコマンド応答を登録する。そして、そのコマンドの実行結果通知先として登録されている、異常通知を発するアプリケーションに、応答があった旨を通知するのである。アプリケーションは、この通知を受けた場合に端末装置コマンドシートを参照すれば、生成したコマンドの実行結果を「出力パラメータ」の項目から取得することができる。
以上のステップＳ１３７までの処理が終了すると、次のパートがあればそれを対象としてステップＳ１３３からの処理を繰り返す。

一方、ステップＳ１３３で端末装置コマンドに対する応答でなければ、そのパートはサーバ側コマンドに係るパートであるので、ステップＳ１３８乃至Ｓ１４２でそのコマンドの登録に係る処理を行う。
すなわち、まずそのパートのＳＯＡＰエンベロープを解析してサーバ側コマンドシートに登録できる形式のデータに変換し（Ｓ１３８）、そのサーバ側コマンドを登録するためのサーバ側コマンドシートをサーバ側コマンドプール１４２に作成して（Ｓ１３９）、サーバ側コマンドとコマンドＩＤとをそのサーバ側コマンドシートに登録する（Ｓ１４０）。

ここで、サーバ側コマンドの内容はサーバ側コマンドシートの「メソッド名」及び「入力パラメータ」の項目に登録し、パートに記載されていたコマンドＩＤは「コマンドＩＤ」の項目に登録する。また、「状態」の初期値は「未処理」であり、「出力パラメータ」の初期値はＮＵＬＬである。

そして、以上の項目への登録が終了すると、サーバ側コマンドシートの「メソッド名」に記憶させたメソッドを実行させるためのハンドラ（サーバ側コマンド実行結果生成手段１４４に含まれる）への参照情報を、予め用意してあるメソッドとハンドラとの対応関係の情報を参照して検索し（Ｓ１４１）、発見した参照情報をサーバ側コマンドシートの「コマンドの通知先」の項目に登録する（Ｓ１４２）。

以上のステップＳ１４２までの処理が終了すると、次のパートがあればそれを対象としてステップＳ１３３からの処理を繰り返す。
全てのパートについてステップＳ１３３乃至Ｓ１４２の処理が終了すると、図４７のフローチャートに示した処理は終了する。

以上のような処理を行うことにより、画像処理装置１００が、仲介サーバ１０２に送信すべき動作要求と仲介サーバ１０２から受信した動作要求に対する動作応答とを一括して仲介サーバ１０２に送信することができる。また、仲介サーバ１０２や処理サーバ１０３からの動作要求と仲介サーバ１０２に送信した動作要求に対する動作応答とを一括して仲介サーバ１０２から受信して処理することができる。

なお、ここでは送信すべきパートを全て生成してからマージして送信を行うようにし、また全てのパートを受信してからこれを各パートに分割して処理を行うように説明したが、このようにする必要はない。各パートを生成するたびに順次送信するようにしたり、各パートを受信するたびに順次各パートに関する処理を行うようにしてもよいことは、仲介サーバ１０２の場合と同様である。
また、サーバ側コマンドの実行に関する処理としては、仲介サーバ１０２について図３７又は図３８を用いて説明した処理を、サーバ側コマンドシートについて実行するようにすればよい。

ところで、画像処理装置１００が生成した動作要求については、とりあえず仲介サーバ１０２に送信しておけば、仲介サーバ１０２が適当な転送先（処理サーバ１０３等）に転送し、そこから動作応答を取得して返してくる。従って、画像処理装置１００にとっては、全ての動作要求に係る動作を仲介サーバ１０２が実行しているものとして送受信の処理を行っても差し支えない。

また、画像処理装置１００が受信する動作要求についても、実際にどの装置が生成したかを把握せずに、仲介サーバ１０２から受信して動作応答も仲介サーバ１０２に返す。従って、画像処理装置１００にとっては、全ての動作要求を仲介サーバ１０２が生成しているものとして送受信の処理を行っても差し支えない。
以上で、画像処理装置１００において実行する、各コマンド及びコマンド応答の転送に関する処理の説明を終了する。

次に、処理サーバ１０３側においてコマンド及びコマンド応答を取り扱うための機能構成について説明する。ハードウェアについては、図１０を用いて説明した通りである。
図４８は、処理サーバ１０３の機能のうち、コマンド及びコマンド応答に関する処理を行うための機能の構成を示す機能ブロック図である。

図４８に示す各機能は、処理サーバ１０３のＣＰＵ３０１が所要の制御プログラムを実行して処理サーバ１０３の各部の動作を制御することにより実現されるものである。そして、これらの機能のうち、処理サーバコマンドプール２４１及び端末装置コマンドプール２４２は、ＲＡＭ３０３のような書き換え可能な記憶手段に設けられるものである。処理サーバコマンド生成手段２４３、端末装置コマンド実行結果生成手段２４４、メッセージ収集手段２４５、メッセージ分配手段２４７の機能は、ＣＰＵ３０１によって実現されるものである。また、ＨＴＴＰサーバ機能部２４６の機能は、ＣＰＵ３０１及びＮＩＣ３０５によって実現されるものである。経路情報記憶手段２５０は、ＳＤカード３０４のような書き換え可能な不揮発性記憶手段に設けられるものである。

図４８に示した各手段の機能についてさらに詳述する。
まず、処理サーバコマンドプール２４１は、処理サーバコマンドを、このコマンドに対する応答や、このコマンドの識別情報及びコマンドの宛先や送信元の情報等と関連付けて登録するプールである。また、端末装置コマンドプール２４２は、端末装置コマンドを、このコマンドに対する応答や、このコマンドの識別情報及びコマンドの宛先や送信元の情報等と関連付けて登録するプールである。

処理サーバコマンド生成手段２４３は、要求生成手段に該当する。そして、処理サーバコマンドを生成し、このコマンドを識別する識別情報（ＩＤ）を割り当て、さらにこのコマンドの宛先情報やこのコマンドを管理するための管理情報を付し、これらの情報を関連付けてテーブル形式の処理サーバコマンドシートとして処理サーバコマンドプール２４１に登録する機能を有する。このうち、処理サーバコマンドを生成する部分には、例えば処理サーバ１０３に備えるアプリケーションが該当する。また、処理サーバ１０３の処理サーバコマンドシートにおけるデータ構造は、図１３に示した仲介サーバ１０２の仲介サーバコマンドシートにおけるデータ構造と同様なものである。

なお、処理サーバコマンド生成手段２４３は、宛先情報として、最終的な宛先だけでなく、その宛先に転送するまでの経路情報も処理サーバコマンドシートに登録する。そして、この経路情報は、経路情報記憶手段２５０から取得できる。
すなわち、経路情報記憶手段２５０は、コマンド（あるいはその他の情報）の宛先と、その宛先にコマンドを送信する際の経路情報とを対応させて、経路情報テーブルとして記憶しているので、最終的な宛先をキーとしてこの経路情報テーブルを検索することにより、その宛先に転送するまでの経路情報を取得することができる。

図４９に、この経路情報テーブルの例を示す。
この例では、４台の画像処理装置が登録されているテーブルを示している。そして、画像処理装置Ａ及びＢについては、仲介サーバ１０２を介してコマンドを転送すれば良い旨の情報が登録されているが、画像処理装置Ｃ及びＤについては、経路が不明である旨の情報が登録されている。

ここでは、処理サーバ１０３側からは端末装置に通信を要求しないようなシステム構成としているため、ユーザ登録ハガキ等の情報を元にオペレータが端末装置ＩＤを入力した後、端末装置から転送されてくる情報を一度も受け取っていない場合等には、どの仲介サーバ１０２を介してその端末装置にコマンドを転送してもらえばよいか認識できないため、経路情報が不明であるという状態が起こり得る。

なお、経路情報テーブルの情報は、後述するように、処理サーバ１０３が受信したＨＴＴＰリクエストに記載されているメッセージの情報を参照して自動で更新することができる他、処理サーバ１０３のオペレータが手動で入力することもできる。
また、複数の仲介サーバを介して転送するような転送経路も登録可能であるが、１つの端末装置につき、経路は１種類のみ登録するようにしている。

図４８の説明に戻ると、端末装置コマンド実行結果生成手段２４４は、応答生成手段に該当する。そして、端末装置コマンドプール２４２から端末装置コマンドを読み出して実行するアプリケーションである。そして、端末装置コマンドに対する応答を生成し、端末装置コマンドのコマンドＩＤと関連付けて端末装置コマンドプール２４２に登録する機能を有する。なお、仲介サーバ１０２から受信した端末装置コマンドは、このコマンドを識別するＩＤ、このコマンドの送信元情報（コマンド応答の宛先情報となる）及びこのコマンドを管理するための管理情報と関連付けて、テーブル形式の端末装置コマンドシートとして端末装置コマンドプール２４２に登録しておくようにしている。そして、端末装置コマンド実行結果生成手段２４４が生成したコマンド応答も、実行した端末装置コマンドについての端末装置コマンドシートに登録する。

また、端末装置コマンド実行結果生成手段２４４に、端末装置コマンドプール２４２から複数の種類の端末装置コマンドを読み出し、各端末装置コマンドに対する応答を生成する機能を設けることが考えられる。さらに、端末装置コマンド実行結果生成手段２４４は、アプリケーションそのものではなく、端末装置コマンドの実行に必要なアプリケーションを呼び出してコマンドを実行させるモジュールであってもよい。
また、処理サーバ１０３の端末装置コマンドシートにおけるデータ構造は、図１２に示した仲介サーバ１０２の端末装置コマンドシートにおけるデータ構造と同様なものである。

次に、メッセージ収集手段２４５は、収集手段に該当する。そして、端末装置コマンド実行結果生成手段２４４が生成したコマンド応答とこのコマンド応答に対応する端末装置コマンドのコマンドＩＤ及び送信元情報とを関連付けて端末装置コマンドプール２４２から読み出すと共に、処理サーバコマンド生成手段２４３が生成した処理サーバコマンドとこのコマンドのコマンドＩＤ及び宛先情報とを関連付けて処理サーバコマンドプール２４１から読み出し、これらから送信メッセージを生成する機能を有する。
送信メッセージの記載形式や生成方式については、仲介サーバ１０２について説明したものと同様である。

また、ＨＴＴＰサーバ機能部２４６は、ＨＴＴＰレスポンスを送信するＨＴＴＰレスポンス送信手段２４６ａとＨＴＴＰリクエストを受信するＨＴＴＰリクエスト受信手段２４６ｂとを備える。
そして、ＨＴＴＰレスポンス送信手段２４６ａは、送信手段に該当し、メッセージ収集手段２４５が生成した送信メッセージを含むＨＴＴＰレスポンスを、仲介サーバ１０２から受信したＨＴＴＰリクエストに対する通信応答として生成し、仲介サーバ１０２に送信する機能を有する。このとき、１つのＨＴＴＰレスポンスに送信メッセージをいくつ含めてもよいし、コマンド応答に係る送信メッセージと処理サーバコマンドに係る送信メッセージとを任意に混在させることもできる。もちろん、宛先の異なる送信メッセージを混在させることもできる。

また、ＨＴＴＰレスポンス送信手段２４６ａは、これらのいずれに係る送信メッセージかに関わり無く、メッセージ収集手段２４５が生成した全ての送信メッセージを１つのＨＴＴＰレスポンスに含めて送信するようにしている。ただし、１つのＨＴＴＰレスポンスに含める送信メッセージの数に上限を設けることも考えられる。

ところで、ＨＴＴＰレスポンスの送信は、メッセージ収集手段２４５が処理サーバコマンドやコマンド応答等の読み出しを試みた場合には、読み出すデータがなく、結果的に送信すべきＳＯＡＰメッセージを生成しなかった場合にも行うものである。そして、この読み出しの試みは、仲介サーバ１０２からのＨＴＴＰリクエストを受信した場合に行うものとする。
これ以外の場面で読み出しを試みても、処理サーバ１０３はＨＴＴＰクライアント機能部を有しないので、自らＨＴＴＰリクエストを送信して送信メッセージを仲介サーバ１０２に転送することができないためである。

また、ＨＴＴＰリクエスト受信手段２４６ｂは、受信手段に該当し、仲介サーバ１０２からのＨＴＴＰリクエストを受信する機能を有する。そしてここでは、ＨＴＴＰリクエストには、端末装置コマンド及びそのコマンドと関連付けられたコマンドＩＤと転送経路情報とを含む受信メッセージと、処理サーバコマンドに対する応答及びそのコマンドと関連付けられたコマンドＩＤと転送経路情報とを含む受信メッセージとが、任意に混在して含まれている。
受信メッセージの記載形式については、仲介サーバ１０２について説明したものと同様である。

メッセージ分配手段２４７は、分配手段に該当する。そして、ＨＴＴＰリクエスト受信手段２４６ｂが受信したＨＴＴＰリクエストに含まれるデータを、処理サーバコマンドプール２４１及び端末装置コマンドプール２４２に振り分けて登録する機能を有する。
具体的には、端末装置コマンド及びそのコマンドと関連付けられたコマンドＩＤ及び転送経路情報（送信元情報として登録する）とを端末装置コマンドプール２４２に端末装置コマンドシートを設けて登録すると共に、処理サーバコマンドに対する応答については、その応答と関連付けられたコマンドＩＤを処理サーバコマンドプール２４１に記憶している処理サーバコマンドシートのコマンドＩＤと照合して対応する処理サーバコマンドシートを特定し、その処理サーバコマンドシートの「出力パラメータ」の項目に登録する。
この登録の際のデータ変換方式についても、仲介サーバ１０２について説明したものと同様である。

次に、以上説明したような構成及び機能を有する処理サーバ１０３において実行する処理について説明する。
図５０に仲介サーバとの間でのメッセージの送受信に関する基本動作のフローチャートを示すが、このフローチャートに示す処理は、処理サーバ１０３のＣＰＵ３０１が所要の制御プログラムを実行することによって行うものである。

ＣＰＵ３０１は、仲介サーバ１０２からＨＴＴＰリクエストが送信されてくると、図５０のフローチャートに示す処理を開始する。
そして、まずそのＨＴＴＰリクエストを受信する（Ｓ２１１）。そして、受信したＨＴＴＰリクエストのＨＴＴＰボディを各パートに分割する（Ｓ２１２）。ここで、各パートへの分割は、「MIME_boundary」で区分された要素に分割することであり、またここで全てのパートに関して分割する。

そしてその後、分割して得た全てのパートを順に対象として、ステップＳＹ及びＳ２１３乃至Ｓ２１５の処理を繰り返す。この処理においては、まず図４９に示した経路情報テーブルを更新するための経路情報テーブル更新処理を行い（ＳＹ）、次に対象のパートが処理サーバコマンドに対する応答を記載したパートか否か判断する（Ｓ２１３）。そして、処理サーバコマンドに対する応答であれば応答通知処理を行う（Ｓ２１４）。また、処理サーバコマンドに対する応答でないときは、端末装置コマンドが記載されたパートであるので、端末装置コマンド登録処理を行う（Ｓ２１５）。

ステップＳ２１４又はＳ２１５の後は、ステップＳ２１３に戻り、次のパートを対象として処理を繰り返す。そして、全てのパートについてこれらの処理を行った時点で、次のステップＳ２１６に進む。
ここまでの処理において、ステップＳ２１１及びＳ２１２ではＣＰＵ３０１はＨＴＴＰリクエスト受信手段２４６ｂとして機能し、ステップＳ２１３乃至Ｓ２１５ではメッセージ分配手段２４７として機能する。

次に、ＣＰＵ３０１は処理サーバコマンドの収集処理を行う（Ｓ２１６）。この処理は、処理サーバコマンドプール２４１から仲介サーバ１０２に送信すべき処理サーバコマンドを収集する処理であり、収集したデータからＳＯＡＰエンベロープによるパートを生成する処理を含む。
次に、端末装置コマンドに対する応答である端末装置コマンド実行結果の収集処理を行う（Ｓ２１７）。この処理は、端末装置コマンドプール２４２から仲介サーバ１０２に送信すべきコマンド応答を収集する処理であり、やはり収集したデータからＳＯＡＰエンベロープによるパートを生成する処理を含む。

その後、ステップＳ２１６及びＳ２１７の処理で生成したパートを１つにマージして、すべてのパートを含むＨＴＴＰレスポンスを生成し（Ｓ２１８）、そのＨＴＴＰレスポンスを、ステップＳ２１１で受信したＨＴＴＰリクエストに対する通信応答として仲介サーバ１０２に送信して（Ｓ２１９）処理を終了する。
ここまでの処理において、ステップＳ２１６及びＳ２１７ではＣＰＵ３０１はメッセージ収集手段２４５として機能し、ステップＳ２１８及びＳ２１９ではＨＴＴＰレスポンス送信手段２４６ａとして機能する。

次に、図５０のフローチャートに示した処理について、一部分ずつより詳細に示したフローチャートを用いて説明する。
図５１は、図５０のステップＳ２１５までの部分の処理をより詳細に示したフローチャートである。
この処理においては、ＣＰＵ３０１はまず、仲介サーバ１０２からＨＴＴＰリクエストを受信する（Ｓ２２１）。そしてこれを受信すると、そのＨＴＴＰボディを解析して各パートに分割する（Ｓ２２２）。

そしてその後、分割して得た各パートを順次対象として、ステップＳＹ及びステップＳ２２３乃至ステップＳ２３２の処理を繰り返す。
これらの処理について、ステップＳＹについては後述する。また、ステップＳ２２３乃至ステップＳ２３２については、画像処理装置１００について図４７を用いて説明したステップＳ１３３乃至Ｓ１４２の処理とほぼ同様なものである。そして、基本的には、図４７の処理で端末装置コマンドであったものがここでは処理サーバコマンドであり、サーバ側コマンドであったものが端末装置コマンドであり、またそれに伴ってコマンドシートの名称が異なるのみである。

それ以外の相違点は、ステップＳ２３０で、端末装置コマンドを記載していたパートのエンティティヘッダから、転送経路に関する情報（「X-Received-From」ヘッダの内容）を抽出して「送信元情報」の項目に登録し、さらにＨＴＴＰリクエストの送信元の情報も、直近の転送経路の情報として同項目に登録する点のみである。
そこで、その他の点については説明を省略する。
そして、全てのパートについてステップＳＹ及びステップＳ２２３乃至ステップＳ２３２のの処理が終了すると、図５１のフローチャートに示した処理は終了し、図５０のステップＳ２１６以降に相当する処理に進む。

図５２は、図５０のステップＳ２１６以降の部分の処理をより詳細に示したフローチャートである。図５１のステップＳ２２７又は２３２の次の処理は、この図ではステップＳ２４１に該当する。
この処理においては、ＣＰＵ３０１はまず、処理サーバコマンドプール２４１から、直近の転送先がステップＳ２１１で受信したＨＴＴＰリクエストの送信元と等しく、かつ「状態」が「未送信」である処理サーバコマンドシートの「メソッド名」と「入力パラメータ」の内容を、送信すべき処理サーバコマンドとして収集し、「コマンドＩＤ」の内容もそのコマンドのコマンドＩＤとして収集する（Ｓ２４１）。

ここで、「宛先情報」には、経路情報テーブルを参照してコマンドの転送に係る経路情報を登録してあるので、処理サーバ１０３から直接転送する転送先としてＨＴＴＰリクエストの送信元の情報が記載されているシートが、そのＨＴＴＰリクエストに対するＨＴＴＰレスポンスに記載して送信すべきコマンドが記載されているシートであると認識できる。
また、「未送信」という「状態」は、コマンドが処理サーバコマンド生成手段２４３によって生成された後、まだ仲介サーバ１０２に通知されていないことを示すものであるので、これを基準に仲介サーバ１０２に送信すべきコマンドを抽出できる。

その後、ステップＳ２４１で収集した全ての処理サーバコマンドを順次対象として、ステップＳ２４２乃至Ｓ２４４の処理を繰り返す。
これらの処理においては、まず対象の処理サーバコマンドとそのコマンドＩＤとを、これらの情報がそれぞれＳＯＡＰボディとＳＯＡＰヘッダとに含まれるＳＯＡＰエンベロープに変換し（Ｓ２４２）、これにエンティティヘッダを付加して対象のコマンドに関するパートを生成する（Ｓ２４３）。なお、ステップＳ２４３では、エンティティヘッダに、「宛先情報」を参照して上述した「X-Send-To」ヘッダにより転送経路の情報を記載する。このとき、これからＨＴＴＰレスポンスを送信しようとする対象の情報は、もはや不要であるので記載しない。
そして、対象の処理サーバコマンドを記載していた処理サーバコマンドシートの「状態」を「応答待ち」に変更する（Ｓ２４４）。「応答待ち」という「状態」は、コマンドを仲介サーバ１０２に送信済であることを示すものである。

これらが全て完了した後、ＣＰＵ３０１は、端末装置コマンドプール２４２から、直近の転送先がステップＳ２１１で受信したＨＴＴＰリクエストの送信元と等しく、かつ「状態」が「処理完了」である端末装置コマンドシートの「出力パラメータ」の内容を、端末装置コマンドに対するコマンド応答のうち送信すべきものとして収集し、「コマンドＩＤ」の内容も、対応する端末装置コマンドのコマンドＩＤとして収集する（Ｓ２４５）。

ここで、「送信元情報」には、端末装置コマンドを受信した際に転送に係る経路情報を登録してあるので、処理サーバ１０３から直接転送する転送先としてＨＴＴＰリクエストの送信元の情報が記載されているシートが、そのＨＴＴＰリクエストに対するＨＴＴＰレスポンスに記載して送信すべきコマンドが記載されているシートであると認識できる。
また、「処理完了」という「状態」は、端末装置コマンドに対応する処理が端末装置コマンド実行結果生成手段２４４によって生成された後、まだ仲介サーバ１０２に送信されていないことを示すものであるので、これを基準に仲介サーバ１０２に送信すべきコマンド応答を抽出できる。

その後、ステップＳ２４５で収集した全てのコマンド応答を順次対象として、ステップＳ２４６乃至Ｓ２４８の処理を繰り返す。これらの処理は、まず対象のコマンド応答とその応答と共に収集したコマンドＩＤとを、これらの情報がそれぞれＳＯＡＰボディとＳＯＡＰヘッダとに含まれるＳＯＡＰエンベロープに変換し（Ｓ２４６）、これにエンティティヘッダを付加して対象のコマンドに関するパートを生成する（Ｓ２４７）。

なお、ステップＳ２４７では、エンティティヘッダに、「送信元情報」を参照して上述した「X-Send-To」ヘッダにより転送経路の情報を記載する。このとき、これからＨＴＴＰレスポンスを送信しようとする対象の情報は、もはや不要であるので記載しない。すなわち、「X-Send-To」ヘッダの内容は、対応する端末装置コマンドを受信した際に記載してあった「X-Received-From」ヘッダの内容と同一とすればよい。
そして、次に対象のコマンド応答を記載していた端末装置コマンドシートの「状態」を「応答済」に変更する（Ｓ２４８）。「応答済」という「状態」は、コマンド応答を仲介サーバ１０２に送信済であることを示すものである。

そして、ここまでの処理が全て完了した後、ＣＰＵ３０１は、ステップＳ２４３又はＳ２４７で生成した各パートをマージし、マルチパートのＨＴＴＰレスポンスを生成し、受信したＨＴＴＰリクエストに対する応答として仲介サーバ１０２に送信する（Ｓ２４９）。
なお、ステップＳ２４４又はＳ２４８で行った「状態」の変更は、実際にこの送信が終了してから行うようにしてもよい。このようにすることにより、通信エラーが発生しても、送信しようとしていたコマンド及びコマンド応答を再度送信の対象とすることができるので、システムの信頼性が向上する。
以上で図５２に示した処理を終了する。

次に、図５３に、図５０等に示した経路情報テーブル更新処理のフローチャートを示す。
この処理においては、ＣＰＵ３０１は、まず対象パートに「X-Received-From」ヘッダがあるか否か、すなわちエンティティヘッダに経路情報が記載されているか否か判断する（Ｓ２５１）。
そして、「X-Received-From」ヘッダがあれば、対象パートの送信元情報として先頭の「X-Received-From」ヘッダの値を取得し、経路情報として残りの「X-Received-From」ヘッダの値及び図５０のステップＳ２１１で受信したＨＴＴＰリクエストの送信元情報を取得する（Ｓ２５２）。一方、「X-Received-From」ヘッダがなければ、対象パートの送信元情報としてＨＴＴＰリクエストの送信元情報を取得し、経路情報がない旨を記憶する（Ｓ２５３）。

いずれの場合も、次に、対象パートの送信元が経路情報テーブルに登録されているか否か判断する（Ｓ２５４）。そして、登録されていれば、経路情報が登録内容と一致しているか否か判断し（Ｓ２５５）、これが一致していれば、経路情報テーブルの内容を変更する必要がないので、図５３の処理を終了して元の処理に戻る。
ステップＳ２５４で登録されていなかった場合には、パートの送信元を新規に経路情報テーブルに登録すべく、経路情報テーブルに、端末装置ＩＤとして送信元情報を登録し、対応する経路情報として、ステップＳ２５２又はＳ２５３で取得した経路情報を登録する。

また、ステップＳ２５５で一致しなかった場合には、送信元の端末装置ＩＤについての経路情報を、ステップＳ２５２又はＳ２５３で取得した経路情報に置き換え、経路情報を更新する。これは、元の経路情報が不明であった場合も含む。
ステップＳ２５６又はＳ２５７の後では、経路情報テーブルの更新内容を既にプールに登録されているコマンドシートに反映させるべく、処理サーバコマンドプール２４１及び端末装置コマンドプールから、宛先又送信元（途中の転送経路は含まない）が対象パートの送信元（ステップＳ２５２又はＳ２５３で取得した送信元情報）と一致するコマンドシートを抽出する（Ｓ２５８）。

そして、抽出した全てのシートを順次対象として、対象シートの宛先情報又は送信元情報を、変更後の経路情報テーブルの内容に従って置き換える処理を行う（Ｓ２５９）。このとき、置き換えるのは転送経路のみであり、最終的な宛先又はコマンドの送信元は変更しない。
以上の処理が全て終了すると、図５３のフローチャートに示す処理を終了し、元の処理に戻る。

以上のような、図５０乃至図５３を用いて説明した処理を行うことにより、処理サーバ１０３が、種々の画像処理装置１００に送信すべき動作要求と画像処理装置１００から受信した動作要求に対する動作応答とを一括して仲介サーバ１０２に送信することができる。また、画像処理装置１００からの動作要求と画像処理装置１００に送信した動作要求に対する動作応答とを一括して仲介サーバ１０２から受信して処理することができる。さらに、処理サーバ１０３から通信要求を送信しない場合でも、画像処理装置１００までの通信を仲介してくれる適切な仲介サーバ１０２に動作要求や動作応答を引き渡すことができる。

なお、ここでも送信すべきパートを全て生成してからマージして送信を行うようにし、また全てのパートを受信してからこれを各パートに分割して処理を行うように説明したが、このようにする必要はない。各パートを生成するたびに順次送信するようにしたり、各パートを受信するたびに順次各パートに関する処理を行うようにしてもよいことは、仲介サーバ１０２の場合と同様である。
また、画像機器コマンドの実行に関する処理としては、仲介サーバ１０２について図３７又は図３８を用いて説明した処理と同様な処理を実行するようにすればよい。
以上で、処理サーバ１０３において実行する、各コマンド及びコマンド応答の取扱いに関する処理の説明を終了する。

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

そして、以上の説明からわかるように、この遠隔管理システムにおいては、仲介サーバ１０２を設け、画像処理装置１００と処理サーバ１０３との間の通信を、この仲介サーバ１０２を介して行うようにしたことにより、画像処理装置１００が処理サーバ１０３の存在を認識しておらず、またコマンドやコマンド応答が最終的にどの装置に転送されるべきものであるかを認識していない場合でも、画像処理装置１００が送信したコマンドやコマンド応答を、適切な転送先に転送することができる。これは、仲介サーバ１０２が、画像処理装置１００から受信したコマンドやコマンド応答を、その種別に従って適当な転送先を定めて転送するようにしているためである。

このことにより、顧客側環境に設置される端末装置である画像処理装置１００における宛先情報管理の負担を低減することができる。すなわち、機能提供側の仲介サーバ１０２や処理サーバ１０３が提供するサービスの構成を変更する場合に、コマンドやコマンド応答の転送経路の変更については、仲介サーバ１０２が記憶している転送先テーブルの内容を変更するのみで対応可能である。すなわち、サービス提供側のみのメンテナンスで対応可能であるので、宛先情報管理が非常に容易である。

また、コマンドを群に分けて階層的に管理することはよく行われるが、種別と転送先との対応関係を、その群毎に定義するようにすれば、同一群内でコマンドを追加あるいは削除した場合でも、転送先テーブルを変更する必要がない。従って、仲介サーバ１０２における宛先情報の管理負担も低減することができる。そして、同一群内のコマンドは通常は同じアプリケーションで処理されることから、転送先を同一としても通常は特に問題は起こらない。

また、コマンドやコマンド応答を、ＳＯＡＰリクエスト及びＳＯＡＰレスポンスとして記載するようにすれば、ＸＭＬで規格化されたデータを送受信することができるので、送受信したデータの再利用を有効に行うことができる。すなわち、受信したデータを社内システムに登録したり、ＸＳＬＴ（XML Stylesheet Language Transform）等の技術を利用して受け取ったデータを表示するホームページを自動生成するとっいた処理を容易に行うことができる。

さらにまた、ＳＯＡＰメッセージにおいては、タグの名前空間を定義することがよく行われるが、コマンド又はコマンド応答に係るタグの名前空間毎に転送先を指定するようにすれば、転送先の管理が容易である。この場合において、転送先の指定に係る名前空間と、名前空間接頭辞の定義に係る名前空間とで、分類の細かさが必ずしも同一である必要はない。

また、遠隔管理システムを構成する各装置において、以上説明してきた構成を採ることにより、各装置間で送受信すべき動作要求や動作応答を、動作要求又は動作応答のいずれであるか、最終的な転送先がどこであるかによらず、一括して送受信できるので、動作要求の送信と動作応答の送信とについて、また最終的な転送先毎に、別々にネゴシエーションを行って通信のコネクションを確立する必要がなく、通信のオーバーヘッドを低減して通信効率を高めることができる。

画像処理装置１００の数が多くなり、また処理サーバ１０３や仲介サーバ１０２と画像処理装置１００との間で転送すべき動作要求や動作応答が多くなればなるほど、この効果は大きくなる。
特に、画像処理装置１００にとっては、仲介サーバ１０２との間で、全ての動作要求及び動作応答を一括して転送できるので、通信のタイミング管理も容易になる。

また、動作要求と動作応答とを一括して送信できるのは、これらをそれぞれ直列化したデータに変換し、構造化言語形式で記載した送信メッセージに変換しているためである。このようにしたことにより、フォーマットの異なる動作要求と動作応答とを容易に結合し、論理的に１つの送信内容として送信することができるのである。
そして、このようにしたことにより、各装置が、一括して受信した動作要求と動作応答とを、容易に個々のメッセージに分離し、それが動作要求であるか動作応答であるか、またその種別や転送先に応じて、適切な処理を行うことができる。

また、動作要求及び動作応答をそれぞれ、形式を変更せずに複数結合して転送可能な１つのメッセージを生成することができる形式で表現し、また複数結合された状態では形式を変更せずに分割して転送可能な個々の動作要求及び動作応答に戻すことができる形式となるようにすれば、動作要求や動作応答の結合や分割を行う際の処理負荷を低減することができる。

さらに、画像処理装置１００と仲介サーバ１０２との間の通信について、通信要求を常に画像処理装置１００から発して通信を行い、その仲介サーバ１０２から画像処理装置１００への動作要求等の送信は、その通信要求に対する応答として行うようにすれば、画像処理装置１００がファイアウォールの内側に設けられている場合であっても、ファイアウォールの存在を意識せずに動作要求及び動作応答の送受信を行うことができる。また、通信要求と通信応答とが対応しているため、通信のレベルでのタイミング管理が容易である。

この場合において、上記の画像処理装置１００から仲介サーバ１０２に定期的に通信要求を送信するようにすれば、仲介サーバ１０２から画像処理装置１００に向けての情報の送信が長時間に亘って停滞してしまう事態を防止できる。
同様に、仲介サーバ１０２と処理サーバ１０３の間の通信についても、通信要求を常に仲介サーバ１０２から発して通信を行うようにすれば、処理サーバ１０３側でどの仲介サーバが通信相手となり得るかを管理していない場合であっても、問題なく動作要求及び動作応答の送受信を行うことができる。従って、処理サーバ１０３側での通信先の管理負担を低減することができる。
この場合において、上記の仲介サーバ１０２から処理サーバ１０３に定期的に通信要求を送信するようにすれば、処理サーバ１０３から仲介サーバ１０２に向けての情報の送信が長時間に亘って停滞してしまう事態を防止できる。

また、各装置において、自身が実行する動作要求を登録するコマンドプールと自身が生成した動作要求を登録するコマンドプールとを設け、各アプリケーション等が生成したり、他の装置から受信したりした動作要求や動作応答を、これらのプールに蓄積しておくようにすることにより、動作要求や動作応答の生成及び送受信を、転送先に対する送信タイミングを考慮せずに行うことができる。従って、処理のタイミング管理を簡略化することができ、設計や開発が容易になる。

そして、このようにした場合でも、通信相手に送信すべき動作要求や動作応答をプールから読み出す収集手段を設けることにより、通信を行う場合に、送信すべき情報を漏れなく送信することができる。
また、受信した動作要求や動作応答を各々分離して適切なプールに記憶させる分配手段を設け、受信した情報もプールに蓄積しておくようにすることにより、受信した動作要求に係る動作の実行や、動作応答受信後の処理、動作要求及び動作応答の転送を、通信相手からの受信タイミングを考慮せずに行うことができる。従って、タイミング管理を簡略化することができ、装置の設計や開発が容易になる。

また、生成した動作要求にＩＤ等の識別情報を付して、動作要求を記憶、送信する際にこの識別情報と関連付けて行うようにし、また動作応答を記憶、送信する際にも対応する動作要求の識別情報と関連付けて行うようにすれば、１つのメッセージ（ここではＨＴＴＰメッセージ）に複数の動作要求や動作応答を含める場合でも、その識別情報を媒介に動作要求と動作応答との対応関係を容易に認識することができる。
さらに、動作要求に優先順位を付して、これが高いものから順に実行したり応答を送信したりするようにすれば、緊急を要する動作を優先的に実行すると共にその応答も優先的に返すことができる。

また、仲介サーバ１０２においては、転送メッセージプールを設け、単に転送を仲介する動作要求及び動作応答を、自身が生成又は実行するものを分けて登録するようにすれば、転送に係るメッセージについて、それ以外のメッセージとは別の処理を行うことができる。例えば、転送に係るメッセージは、その内容を解釈する必要がない（例えばＸＭＬをデシリアライズする必要がない）ため、受信したままの形式で転送メッセージプールに登録しておくことができる。また、処理サーバ１０３へ転送すべきメッセージを検索する際にも、検索範囲を狭くすることができる。従って、転送メッセージプールを設けることにより、仲介サーバ１０２におけるメッセージ転送仲介処理の処理負担を低減することができる。

〔実施形態の変形例〕
次に、上述した実施形態の変形例について説明する。
まず、上述した実施形態においては、画像処理装置１００のような端末装置と処理サーバ１０３との間で仲介サーバ１０２を１つだけ介してメッセージを送受信する例について説明したが、２つ以上の仲介装置を介して送受信するようにしてもよいことはもちろんである。
このような分散処理システムの例を図５６に示す。

この例においては、端末装置Ａは、仲介サーバＢと仲介サーバＣの２つの仲介サーバを介して処理サーバＤとの間でメッセージを送受信することができる。この場合において、仲介サーバＢ及びＣの機能は、上述した実施形態における仲介サーバ１０２と同様なものである。また、処理サーバＤの機能は、処理サーバ１０３と同様なものである。
そして、この場合において、端末装置から処理サーバに向かう方向に転送するメッセージは通信要求に記載して、逆方向に転送するメッセージはその通信要求に対する通信応答に記載して転送するものとする。
また、どの装置が第１の通信装置でどの通信装置が第２の通信装置であるかは、各仲介サーバに関して相対的に定まるものである。具体的には、仲介サーバに通信要求を送信してくる装置が第１の通信装置、仲介サーバが通信要求を送信する相手の装置が第２の通信装置となる。あるいは、転送先を記載していないメッセージを送信してくる装置が第１の通信装置、転送先を記載してあるメッセージを送信してくる装置が第２の通信装置と考えることもできる。

この分散処理システムにおいては、仲介サーバＢには、処理サーバＤに転送すべき種別のメッセージについて、その転送先は仲介サーバＣである旨記憶させておく（これが最終的にどこに転送されるかを記憶させておく必要はない）。そして、仲介サーバＣには、処理サーバＤに転送すべき種別のメッセージについて、その転送先は処理サーバＤである旨記憶させておく。このように転送先の設定を行うことにより、端末装置Ａから仲介サーバＢに送信されたメッセージを、さらに仲介サーバＣを介して処理サーバＤに転送することができる。

このとき、端末装置Ａから仲介サーバＢに転送されたメッセージには、これがさらに仲介サーバＣに転送される際に、送信元情報として、「X-Received-From」ヘッダに「端末装置Ａ」の情報が記載される。また、これがさらに処理サーバＤに転送される際に、送信元情報として、次の「X-Received-From」ヘッダに「仲介サーバＢ」の情報が追加される。また、処理サーバＤは、このメッセージが記載されたＨＴＴＰリクエストの送信元情報から、仲介サーバＣも転送経路であることが認識できる。

従って、処理サーバＤ側で、端末装置Ａに送信するメッセージは、仲介サーバＣ→仲介サーバＢ→端末装置Ａの経路で転送させればよいことがわかる。そこで、処理サーバＤは、端末装置Ａに送信するメッセージに、「X-Send-To」ヘッダによりその経路情報を記載することができる（直接の転送先となる仲介サーバＣの情報を記載する必要はない）。
そして、このようにしておけば、転送経路に当たる仲介サーバは、この経路情報を参照し、次の転送先にメッセージを転送して、最終的に端末装置Ａまでメッセージを転送することができる。このとき、メッセージの転送に際して、転送先を示す経路情報は消去し、最下段に次の転送先が示されるようにしている。

なお、以上の構成においては、図５６の記載からわかるように、端末装置から処理サーバに向けて転送されるメッセージに記載される「X-Received-From」ヘッダの内容と、同じ経路を処理サーバから端末装置に向けて転送されるメッセージに記載される「X-Send-To」ヘッダの内容とは、全く同じものになる。
また、上述した実施形態では、「X-Received-From」ヘッダの追加は受信側で、「X-Send-To」ヘッダの削除は送信側で行う例について説明したが、このようにすることは必須ではない。逆に、「X-Received-From」ヘッダの追加を送信側で、「X-Send-To」ヘッダの削除を受信側で行うようにしてもよい。

図５７に、分散処理システムのさらに別の構成例を示す。
この図に示すように、この発明の分散処理システムにおいて、端末装置と直接通信する仲介サーバが１つである必要はない。また、処理サーバについても、１つの仲介サーバとの間でのみメッセージの送受信を行う構成である必要もない。１つの仲介サーバが複数の端末装置との間でメッセージの送受信を行ってもよいことは、上述した通りである。
このようにしても、端末装置から処理サーバに向けて転送するメッセージには送信元及び転送経路の情報を記載し、また途中の仲介サーバがメッセージの種別毎に転送先の情報を記憶しており、処理サーバから端末装置に向けて転送するメッセージには転送経路及び宛先の情報を記載しているので、これらを参照すれば、適切な相手にメッセージを転送することができる。

このような構成の分散処理システムにおいて、処理サーバＪにおける経路情報テーブルは、図５８に示すようになる。すなわち、端末装置Ａについては、端末装置Ａ⇔仲介サーバＦ⇔仲介サーバＧ⇔処理サーバＪのような転送経路でメッセージを転送できることが、処理サーバＪ側で認識できる。端末装置Ｂについては、端末装置Ｂ⇔仲介サーバＨ⇔処理サーバＪのような転送経路でメッセージを転送できることが認識できる。
端末装置Ｃ及びＤについては、まだ経路が登録されていない。しかし、例えば処理サーバＪが端末装置Ｄからのメッセージを受信すると、そのメッセージの転送経路の情報から、端末装置Ｄ⇔仲介サーバＦ⇔仲介サーバＧ⇔処理サーバＪの経路を認識し、これを経路情報テーブルに登録することができる。

端末装置Ｅのように、経路情報テーブルに登録されていない端末装置からのメッセージを受信した場合も、同様に、メッセージの転送経路の情報から、端末装置Ｅ⇔仲介サーバＨ⇔処理サーバＪの経路を認識し、これを経路情報テーブルに登録することができる。ただし、予め経路情報テーブルに登録されていない端末装置からのメッセージに対してはエラーを返し、新たに経路情報テーブルには登録しないような対応も考えられる。
なお、分散処理システムとして、図５６や図５７に示した構成以外にも、種々の構成が取り得ることは言うまでもない。ただし、１つの端末装置から複数の仲介サーバにメッセージを送信可能とすると、端末装置側でメッセージの宛先を管理する必要が生じてしまう。そこで、各端末装置からは１つの仲介サーバのみにメッセージを送信可能とすることが好ましい。

なお、上述した実施形態の分散処理システムも含め、これらの分散処理システムにおいて、必ずしも処理サーバと仲介サーバを区別する必要はない。そして、このようにする場合、これらのサーバの機能は、実施形態で仲介サーバ１０２について説明した機能に、処理サーバ１０３について説明した経路情報記憶手段２５０に関する機能を追加したものとすればよい。

そして、転送先テーブルに、転送先として自分自身以外の情報が登録されていない装置においては、受信する全ての動作要求及び動作応答に係る処理を全て自身で行うことになり、転送用メッセージプールやメッセージ転送手段が使用されることはなく、結果的に処理サーバとして機能することになる。従って、このようにすれば、転送先テーブルの内容を変更するだけで、同じ装置を処理サーバ及び仲介サーバのいずれとしても任意に機能させることができるので、システムの構成変更が容易になる。

なお、逆に、仲介サーバに、動作要求に係る処理を行ったり、動作要求を生成したりする機能を設けず、仲介サーバをメッセージの仲介に特化した装置とすることも可能である。このようにした場合、端末装置コマンドプール、仲介サーバコマンドプール、端末装置コマンド実行結果生成手段、仲介サーバコマンド生成手段は不要である。従って、仲介サーバの構成を単純化し、設計や開発の手間を低減して低コスト化を図ることができる。
また、処理サーバから仲介サーバに対して通信要求を送信し、その通信要求に動作要求や動作応答に係るメッセージを記載して転送することを可能とすることも考えられる。

また、上述した実施形態においては、仲介サーバ１０２における転送先テーブルとして、図３４に示したように、名前空間ＵＲＩ毎に、その名前空間に属するコマンド又はコマンド応答に係るメッセージの転送先の情報を記載したものを使用する例について説明した。しかし、転送先テーブルにおいて転送先がはっきり定められていないメッセージを、所定の転送先に転送するようにすることも考えられる。

このようにする場合、図５９に示すように、転送先テーブルに「default」の項目を設け、コマンドやコマンド応答の名前空間ＵＲＩが転送先テーブルに登録されていない場合には、「default」欄に登録されている転送先にそのコマンドやコマンド応答に係るメッセージを転送することが考えられる。そして、この場合、図３３に示したようなメッセージ分配処理において、ステップＳ２２で名前空間ＵＲＩが転送先テーブルに登録されていなかった場合に、対象パートのメッセージの転送先を「default」欄に登録されている転送先とするようにするとよい。

また、図５９に示した転送先テーブルを利用するシステム構成としては、例えば図６０に示した構成が考えられる。すなわち、図３に示した分散処理システムにおいて、総合管理サーバ１０３ｃを追加して設けた構成である。そして、機器管理サーバ１０２に図５９に示したような転送先テーブルを記憶させ、機器管理サーバ１０２で処理するものでも、販売管理サーバ１０３ａや情報配信サーバ１０３ｂに転送するものでもないメッセージを、全て総合管理サーバ１０３ｃに転送するようにするのである。
このようにすることにより、仲介サーバ１０２において、扱い得る全てのコマンドやコマンド応答に応じた転送先情報を指定しなくてもよいようになるので、システムの設計や管理が容易になる。

この場合において、総合管理サーバ１０３ｃが受け取ったメッセージを自身で処理する必要はなく、さらに他の装置に転送するようにしてもよい。また、その場合に総合管理サーバ１０３ｃが用いる転送先テーブルは、図３４に示したような「default」の項目がないものでも、図５９に示したような「default」の項目があるものであってもよい。さらに、「default」の項目に登録する転送先を、いずれかの名前空間ＵＲＩと対応させて転送先テーブルに登録されている転送先と同じものとすることも考えられる。

また、各仲介サーバにおいて図６１に示したような転送先テーブルを使用するようにすることも考えられる。すなわち、自身で処理すべきコマンドやコマンド応答についてのみ、その仲介サーバ自身を転送先として登録し、それ以外のコマンドやコマンド応答は、全て次の仲介サーバに転送するようにすることも考えられる。
この場合、例えば、分散処理システムを図６２に示すように構成し、複数の仲介サーバを直列に配置して、各仲介サーバは、自身で処理すべきもの以外のコマンドやコマンド応答に係るメッセージを、順次次のサーバに転送していくようにすることができる。このようにシステムを構成すれば、各仲介サーバには、自身で処理すべきコマンド及びコマンド応答の情報と、その他のコマンド及びコマンド応答の転送先のみを記憶させておけばよいので、システムの設計や管理がさらに容易になる。

そして、各仲介サーバは、メッセージの転送先の仲介サーバや処理サーバにおいてメッセージがどのように処理されるかを知る必要がないので、転送先の仲介サーバや処理サーバにおいて、受け付けるコマンドの種類や処理の分担を、転送元の仲介サーバに通知することなく自由に定めることができる。従って、仲介サーバを設けた会社がメッセージに係る処理を別会社に下請けに出したり、またその下請けを受注した会社が処理をさらに孫請けに出したりする場合には、このような構成を採用すると、処理を受注した会社が自由にシステムを構成できるため、特に有効である。
そして、最終段の処理サーバＮにおいては、転送先テーブルに「default」の項目を設けないようにし、名前空間ＵＲＩが転送先テーブルに登録されていないコマンドやコマンド応答に対してエラー処理を行うようにすれば、全く関係ないコマンド等についても、適切な対応が可能になる。

さらに、図６２に示したように複数の仲介サーバを直接に配置した構成のみに対応できればよいのであれば、各仲介サーバに転送先テーブルに代えて図６３に示したような情報を記憶させておくようにしてもよい。すなわち、自身で処理するメソッドの属する名前空間ＵＲＩと、それ以外のコマンド等を転送する転送先サーバのＩＤとを記憶させておくようにしてもよい。

図６４に、受信したメッセージを図６３に示したような情報を用いて取り扱う場合の処理のフローチャートを示す。図６４に示した処理は、図３３に示した処理のステップＳ２２とＳ２３に代えて、ステップＳＡとステップＳＢの処理を行うようにしたものである。
すなわち、図６３に示した情報を用いる場合、図３２に示したメッセージ送受信の基本フロー中のメッセージ分配処理において、図６４に示した処理を行うようにする。そして、ステップＳ２１で対象パートのＳＯＡＰメッセージからそのメッセージに係るコマンド又はコマンド応答の名前空間ＵＲＩを取得し、ステップＳＡで、その名前空間ＵＲＩが図６３に示した「自身で処理するメソッドの属する名前空間ＵＲＩ」に含まれるか否か判断する。

そして、含まれる場合には、そのコマンド又はコマンド応答は自身で処理すべきものであるから、ステップＳ２４以下に進み、図３３の場合と同様な処理を行う。また、含まれない場合には、そのコマンド又はコマンド応答は次の仲介サーバに転送すべきものであるから、ステップＳＢでメッセージの宛先を図６３に示した「転送先サーバＩＤ」として登録されている「次の仲介サーバ」に設定し、ステップＳ３４以下に進んで対象のメッセージを送信用転送メッセージプール５１に登録する。
各仲介サーバに、以上のような処理を実行させるようにすれば、図６３に示したような情報のみで、メッセージの転送を適切に行わせることができる。なお、このような処理を採用した場合、転送先のサーバは１つしかないので、図３９に示したようなメッセージ転送処理を行う場合において、送信用転送メッセージプール５１に登録されている全てのメッセージを収集し、所定の転送先に送信するようにすればよい。従って、図１４に示したような転送メッセージシートにおいてメッセージの転送先を管理することも、必須ではない。

なお、「転送先サーバＩＤ」として複数のサーバを登録し、他のサーバに転送すべきコマンドに係るメッセージの転送先を、メッセージの受信日時に応じたスケジューリング、メッセージの受信元、あるいはランダム等により、各サーバに振り分けるようにしてもよい。このようにすれば、転送先のサーバにメッセージが集中することを防止し、処理負荷の分散を図ることができる。
さらに、コマンド応答についても同様な処理を行うようにしてもよい。この場合において、最終的にメッセージを受け取る可能性がある各装置が共通に参照できるデータベースを設けてここに受け取ったメッセージをプールしておくようにすれば、コマンド応答がコマンドの送信元の装置に届かなかったとしても、送信元の装置は、データベースにアクセスすることによりコマンド応答を参照することができる。

また、自身で処理できるコマンドに係るメッセージであっても、自身での処理に必要なリソースが十分確保できない場合等、場合によっては他のサーバに転送するようにしてもよい。このようにする場合において、転送先のサーバに、転送元のサーバと同じコマンドを処理する機能を設けるようにするとよい。このようにすれば、一部のサーバに処理負荷が集中している場合において、単純な処理で効率良く複数のサーバに処理を分散させることができる。

また、上述した実施形態においては、各装置間のメッセージの転送を、マルチパートで行う例について説明したが、このようにすることは必須ではない。例えば、システム全体で取り扱うコマンドを、端末装置から仲介サーバや処理サーバに向けたものだけとする場合には、１つのＨＴＴＰリクエスト又はＨＴＴＰレスポンスに、１つのＳＯＡＰメッセージのみ記載するような方式、例えば仲介サーバ１０２において図４１を用いて説明したような処理、も採用可能である。このようにすれば、各装置をマルチパートのような特殊な転送プロトコルに対応させる必要がなくなるので、設計や開発の手間を低減して低コスト化を図ることができる。
また、システム全体で取り扱うコマンドを、端末装置から仲介サーバや処理サーバに向けたものだけとしても、上述のようなマルチパートによる転送を行うようにすれば、上述した効果を同様に得ることができる。

また、上述した各実施形態においては、ＲＰＣを実現する上位プロトコルとしてＳＯＡＰを採用し、アプリケーションは直接プールを操作してＲＰＣを実現しているが、アプリケーションとプールとの間にＣＯＲＢＡ（Common Object Request Broker Architecture）やＪＡＶＡ（登録商標）ＲＭＩ（Remote Method Invocation）とのブリッジ（メッセージ変換機能）を備えることによってアプリケーションの開発効率をさらに向上させてもよい。

また、上述した実施形態において、各ノード間でのコマンド及びこれに対するコマンド応答のやり取りは、ＸＭＬで記述されたＳＯＡＰメッセージにより行うこととしているが、これに限るものでなく、他の形式で記述されていてもよい。
また、送受信するコマンドやコマンド応答の情報量に制限を設けても構わない。特に、受信するコマンドの情報量を制限するようにすると、受信側がメモリ容量の限られた装置である場合にメモリの使用量を抑えることができる。

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

なお、メッセージの転送プロトコルとしてＳＭＴＰを採用する場合には、メッセージは電子メールに記載して送信することになるが、ＭＩＭＥマルチパート等を利用して、１通の電子メールに複数のメッセージを記載することは可能である。従って、上述したＨＴＴＰリクエスト及びＨＴＴＰレスポンスに代えて、電子メールとその返信の電子メールを使用することができる。しかし、電子メールには通信要求と応答のような対応関係はないため、始めの送信とそれに対する返信のタイミングは、独立に管理する必要がある。また、電子メールは宛先への到達に長時間を要することもあるので、システムの円滑な運用のためには、転送プロトコルとしてＨＴＴＰを使用する方が好ましい。

また、ここでは画像処理装置１００と仲介サーバ１０２とをインターネット１４を介して接続した例について説明したが、これ以外にも、有線、無線を問わず、ネットワーク通信が可能な各種通信経路を用いることができる。仲介サーバ１０２と処理サーバ１０３の相互間においても、同様に各種通信経路を用いることができる。

さらにまた、分散処理システムの構成についても、以上説明したものに限られることはなく、遠隔管理システム以外の分散処理システム、そして任意の通信システムにもこの発明を適用できることは、言うまでもない。
例えば、上述した実施形態における「端末装置」は、あくまで分散処理システムにおける「端末」であって、顧客先環境内においても「端末」として機能している必要はない。すなわち、顧客先環境における基幹系サーバを「端末装置」として上述の実施形態のような分散処理システムに接続し、ここから取得した情報を加工して顧客先環境内の他の装置に配布するような構成も採りうる。

また、処理サーバについても、各々異なったコマンドを実行するための装置である必要はない。例えば、仲介サーバにおいて、動作要求や動作応答の種類だけでなく、メッセージの送信元の情報も参照して転送先を定めるようにしてもよい。このようにすれば、動作要求を送信する端末装置の数が増え、処理サーバの負担が過大となった場合でも、一定台数の端末装置毎に処理サーバを分ける等して、容易に処理の負荷分散を図ることができる。この場合においても、処理の分散内容を端末装置側に一切知らせる必要がないので、システム構成変更の際の負担は最低限で済む。
さらに、端末装置側からの動作要求については、仲介サーバが通信トラフィックを監視する等して、その内容に応じて転送先を動的に変更することも可能である。このようにしても、処理サーバには適切な転送経路を指定して動作応答を返す機能があるので、動作要求の送信元まで正確に動作応答を返すことができる。

また、仲介サーバに相当する装置を顧客先環境にも設置し、複数の端末装置に関するメッセージの転送を、一括して担わせるようにしてもよい。この場合において、顧客先環境内の仲介サーバと端末装置とは、ＬＡＮによって接続することが考えられるので、これらの間の通信には、ＬＡＮ内での通信に使用する一般的な通信プロトコルを適用可能である。
従って、顧客先環境の仲介サーバにこのようなプロトコル変換機能を設ければ、特殊なプロトコルに対応していない端末装置であっても、マルチパート転送等の特殊なプロトコルを使用する分散処理システムに接続し、上述した効果を得ることができる。

そして、このようにしたとしても、顧客先環境内の仲介サーバと端末装置とは、通常は通信相手が限定されたネットワークを介して通信を行うため、ネゴシエーションの処理負荷は小さくて済むので、通信の回数が増えてもさほど通信効率は低下しない。さらに、端末装置を複雑な通信プロトコルに対応させる必要がないので、全体としてシステムを構成するための手間やコストを抑えることができる。
なおこの場合、顧客先環境の仲介サーバと端末装置との接続は、ＬＡＮに限らず、ＲＳ−４８５規格等に準拠したシリアル接続や、ＳＣＳＩ（Small Computer System Interface）規格等に準拠したパラレル接続等によって行ってもよい。例えばＲＳ−４８５規格の場合には、仲介サーバに直列に５台までの端末装置を接続することができる。

また、顧客先環境に仲介サーバを設けないとすると、情報送信の停滞を防止するために、各々の端末装置が上述したような定期的な通信要求を個々に行うことになる。従って、機能提供側の仲介サーバ１０２に多数の通信要求が殺到することになる。従って、顧客先環境に多数の端末装置を設ける場合には、顧客先環境に仲介サーバも設け、その仲介サーバに代表で定期的な通信要求を行わせることが好ましい。

この場合、図６５に示すようなシステム構成が考えられる。この図においては、顧客環境側仲介サーバ１１２を別途設ける被管理装置の例としてテレビ受像機１０ａや冷蔵庫１０ｂのようなネットワーク家電、医療機器１０ｃ，自動販売機１０ｄ，計量システム１０ｅ，空調システム１０ｆを挙げている。そして、顧客環境側仲介サーバ１１２を別途設けない被管理装置の例として、自動車１０ｇや航空機１０ｈを挙げている。また、自動車１０ｇや航空機１０ｈのように広範囲を移動する装置においては、ファイアウォール（ＦＷ）１１の機能も併せ持つようにすることが好ましい。また、顧客環境側仲介サーバ１１２と、機能提供側の仲介サーバ１０２との間にファイアウォール１１があったとしても、常に顧客環境側仲介サーバ１１２から通信要求を発してメッセージの転送を行うようにすれば、メッセージの転送に特に支障はない。

また、機能提供側についても、仲介サーバ１０２と処理サーバ１０３とを同じベンダーが提供する必要はない。各仲介サーバにおいてコマンドの転送先を把握することができていれば、転送先の処理サーバで機能がどのように提供されようと構わない。
従って、端末装置側で、観光地案内、時刻表案内、チケット予約、宿泊予約といった機能を提供する複数の処理サーバに対するコマンドを送信し、各々コマンド応答のＸＭＬデータを加工して結合し、１つのＨＴＭＬ文書に変換するような処理を行えば、仲介サーバは、複数のサイトの機能を１つのウェブページ内で提供するような、いわゆるポータルサイトと同様なサービスを提供することもできる。

また、上述した実施形態においては、端末装置は仲介サーバに送信する動作要求及び動作応答に、宛先や転送先に係るメッセージを記載しない例について説明した。しかしながら、端末装置側で、端末装置コマンドを送信すべき処理サーバの宛先や、処理サーバコマンドの送信元の情報を把握し、仲介サーバに送信するコマンド及びコマンド応答に、宛先を記載するようにしてもよい。
このようにする場合には、ＳＯＡＰメッセージ中のＳＯＡＰヘッダに、宛先や送信元の情報を記載しておき、これを端末装置コマンドシートやサーバ側コマンドシートに記載して管理すれば良い。

また、仲介サーバは、端末装置から受信する動作要求及び動作応答に記載される宛先が自分自身又は直接通信可能な装置のみである場合には、転送先テーブルを設けず、ＳＯＡＰヘッダに記載された宛先を転送先として転送メッセージシートに登録すればよい。宛先に、さらに別の仲介サーバを介して転送すべき装置が含まれ得る場合には、転送先テーブルとして、宛先情報と、直接の転送先となる装置との対応関係を記憶しておき、このテーブルを参照して次段の転送先を判断することが考えられる。
なお、いずれにしろ、ＳＯＡＰヘッダの内容を解釈するためには、一旦ＳＯＡＰメッセージをデシリアライズする必要がある。

このような構成を取った場合でも、処理サーバから、複数の端末装置に宛てた動作要求を一括して仲介サーバに転送することによる通信の効率向上の効果は、上述した実施形態の場合と同様に得られる。この効果は、仲介サーバが上述した顧客環境側仲介サーバである場合に特に大きい。
また、仲介サーバが、端末装置宛ての複数の処理サーバからの動作要求を端末装置に一括して送信し、それらの動作要求に対する動作応答を一括して受信する場合にも、同様に通信効率向上の効果が得られる。この効果は、仲介サーバが機能提供側に設けられている場合に特に効果が大きい。
これらの効果は、端末装置側からの動作要求を取り扱わず、処理サーバ側からの動作要求と、それに対する動作応答のみを取り扱う場合でも得られるものである。
なお、以上説明した各変形を、矛盾しない範囲で組み合わせて適用できることはもちろんである。

また、この発明によるプログラムは、コンピュータを、第１の通信装置と複数の第２の通信装置との間の通信を仲介する仲介装置として機能させるためのプログラムであり、このようなプログラムをコンピュータに実行させることにより、上述したような効果を得ることができる。

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

以上説明してきたように、この発明の仲介装置、分散処理システム、データ転送方法、プログラムあるいは記録媒体を用いれば、ある通信装置が複数の通信装置に動作要求を送信してその動作要求に対する動作応答を受け取るような通信システムを構成する場合において、通信装置間の通信を適切に仲介することにより、通信の効率を上げることができる。
従って、この発明を、このような通信システム又はこのような通信システムにおいて通信を仲介する仲介装置に適用することにより、通信の負荷が小さい通信システムを構成することができる。

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

図３に示した仲介サーバの機能のうち、コマンド及びコマンド応答に関する処理を行うための機能の構成を示す機能ブロック図である。 図３に示した仲介サーバの端末装置コマンドシートにおけるデータ構造の例を示す図である。 同じく仲介サーバコマンドシートにおけるデータ構造の例を示す図である。 同じく送信用転送メッセージプール中の転送メッセージシートにおけるデータ構造の例を示す図である。 同じく受信用転送メッセージプール中の転送メッセージシートにおけるデータ構造の例を示す図である。 図３に示した仲介サーバが画像処理装置から受信するＨＴＴＰリクエストの例を示す図である。 同じく仲介サーバが画像処理装置に送信するＨＴＴＰレスポンスの例を示す図である。 同じく仲介サーバが処理サーバに送信するＨＴＴＰリクエストの例を示す図である。 同じく仲介サーバが処理サーバから受信するＨＴＴＰレスポンスの例を示す図である。 図３に示した遠隔管理システムにおける、仲介サーバに対する端末装置コマンドを記載したパートの例を示す図である。

同じく図２０に示した端末装置コマンドに対する応答を記載したパートの例を示す図である。 同じく処理サーバ（販売管理サーバ）に対する端末装置コマンドを、画像処理装置から仲介サーバに転送する際のパートの記載例を示す図である。 同じく図２２に示した端末装置コマンドを、仲介サーバから処理サーバに転送する際のパートの記載例を示す図である。 同じく図２２に示した端末装置コマンドに対する応答を、処理サーバから仲介サーバに転送する際のパートの記載例を示す図である。 同じく図２４に示したコマンド応答を、仲介サーバから画像処理装置に転送する際のパートの記載例を示す図である。 同じく画像処理装置に対する仲介サーバコマンドを記載したパートの記載例を示す図である。 同じく図２６に示した仲介サーバコマンドに対する応答を記載したパートの記載例を示す図である。 同じく画像処理装置に対する処理サーバコマンドを、処理サーバから仲介サーバに転送する際のパートの記載例を示す図である。 同じく図２８に示した処理サーバコマンドを、仲介サーバから画像処理装置に転送する際のパートの記載例を示す図である。 同じく図２８に示した処理サーバコマンドに対する応答を、画像処理装置から仲介サーバに転送する際のパートの記載例を示す図である。

同じく図３０に示したコマンド応答を、仲介サーバから処理サーバ（販売管理サーバ）に転送する際のパートの記載例を示す図である。 図３に示した仲介サーバにおける、画像処理装置との間の通信に係るメッセージの収集及び分配処理の基本動作を示すフローチャートである。 図３２に示したメッセージ分配処理を示すフローチャートである。 図３に示した仲介サーバが記憶する転送先テーブルの例を示す図である。 図３２のステップＳ１４に示した転送メッセージ収集処理をより詳細に示すフローチャートである。 図３２のステップＳ１５以降の処理をより詳細に示すフローチャートである。 図３に示した仲介サーバにおける端末装置コマンドの実行に関する処理の一例を示すフローチャートである。 その別の例を示すフローチャートである。 図３に示した仲介サーバにおける、処理サーバとの間でのメッセージの転送に係る処理を示すフローチャートである。 図３９に示したメッセージ転送処理の実行タイミング制御に係る処理のフローチャートを示す。

図３に示した仲介サーバにおける、端末装置コマンドの転送に係る別の処理例を示すフローチャートである。 図３に示した画像処理装置の機能のうち、コマンド及びコマンド応答に関する処理を行うための機能の構成を示す機能ブロック図である。 図３に示した画像処理装置の端末装置コマンドシートにおけるデータ構造の例を示す図である。 同じくサーバ側コマンドシートにおけるデータ構造の例を示す図である。 図３に示した画像処理装置におけるメッセージの収集及び分配処理の基本動作を示すフローチャートである。 図４５のステップＳ１１４までの処理をより詳細に示すフローチャートである。 図４５のステップＳ１１５以降の処理をより詳細に示すフローチャートである。 図３に示した処理サーバの機能のうち、コマンド及びコマンド応答に関する処理を行うための機能の構成を示す機能ブロック図である。 図３に示した処理サーバが記憶する経路情報テーブルの例を示す図である。 図３に示した処理サーバにおけるメッセージの収集及び分配処理の基本動作を示すフローチャートである。

図５０のステップＳ２１５までの処理をより詳細に示すフローチャートである。 図５０のステップＳ２１６以降の処理をより詳細に示すフローチャートである。 図５０に示した経路情報テーブル更新処理の内容を示すフローチャートである。 図３に示した遠隔管理システムにおいて、画像処理装置が処理サーバで実行される端末装置コマンドを生成してからそのコマンドに対する応答を受け取るまでに各装置において行われる一連の処理を示すフローチャートである。 同じく、管理サーバが画像処理装置宛ての処理サーバコマンドを生成してからそのコマンドに対する応答を受け取るまでに各装置において行われる一連の処理を示すフローチャートである。 この発明の実施形態である分散処理システムの別の構成例を示す図である。 その更に別の構成例を示す図である。 図５７に示した処理サーバＪにおける経路情報テーブルの記憶例を示す図である。 図３４に示した転送先テーブルの別の例を示す図である。 図５９に示した転送先テーブルを使用する場合の分散処理システムの構成例を示す図である。

転送先テーブルのさらに別の例を示す図である。 図６１に示した転送先テーブルを使用する場合の分散処理システムの構成例を示す図である。 分散処理システムを図６２に示したように構成する場合に転送先テーブルに代えて使用し得るデータの例を示す図である。 図６３に示したデータを用いる場合に実行するメッセージ分配処理の例を示す、図３３と対応するフローチャートである。 この発明の実施形態である分散処理システムのさらに別の構成例を示す図である。

符号の説明

１０：端末装置 １１：ファイアウォール
１２，１０２：仲介サーバ １３，１０３：処理サーバ
１４：インターネット
４１，１４１，２４２：端末装置コマンドプール
４２：仲介サーバコマンドプール
４３，２４４：端末装置コマンド実行結果生成手段
４３ａ：端末装置コマンドハンドラ
４４：仲介サーバコマンド生成手段
４４ａ：仲介サーバコマンド生成ハンドラ
４５，１４５，２４５：メッセージ収集手段
４６，２４６：ＨＴＴＰサーバ機能部
４６ａ，２４６ａ：ＨＴＴＰレスポンス送信手段
４６ｂ，２４６ｂ：ＨＴＴＰリクエスト受信手段
４７，１４７，２４７：メッセージ分配手段
４８：メッセージ転送手段
４９，１４６：ＨＴＴＰクライアント機能部
４９ａ，１４６ａ：ＨＴＴＰリクエスト送信手段
４９ｂ，１４６ｂ：ＨＴＴＰレスポンス受信手段
５０：転送先情報記憶手段
５１：送信用転送メッセージプール
５２：受信用転送メッセージプール
１００：画像処理装置 １１２：顧客環境側仲介サーバ
１２５：制御装置 １４２：サーバ側コマンドプール
１４３：端末装置コマンド生成手段
１４４：サーバ側コマンド実行結果生成手段
２０１，３０１：ＣＰＵ
２４１：処理サーバコマンドプール
２４３：処理サーバコマンド生成手段
２４４：端末装置コマンド実行結果生成手段
２５０：経路情報記憶手段

Claims (29)

1. 複数の第１の通信装置と第２の通信装置との間の通信を仲介する仲介装置であって、
   前記各第１の通信装置から、前記第２の通信装置から転送されてきた動作要求に対する動作応答を複数一括して受信する第１の受信手段と、
   該第１の受信手段が受信した各動作応答を、転送先となる第２の通信装置に複数一括して送信する第１の送信手段と、
   前記第２の通信装置から、前記第１の通信装置に転送すべき動作要求を複数一括して受信する第２の受信手段と、
   前記第２の受信手段が受信した各動作要求を、転送先となる前記各第１の通信装置に装置毎に一括して送信する第２の送信手段とを設けたことを特徴とする仲介装置。
2. 複数の第１の通信装置と第２の通信装置との間の通信を仲介する仲介装置であって、
   前記各第１の通信装置から、動作要求と、前記第２の通信装置から転送されてきた動作要求に対する動作応答とを一括して受信する第１の受信手段と、
   該第１の受信手段が受信した各動作要求及び動作応答を、各動作要求及び動作応答の種別に従って転送先となる第２の通信装置に一括して送信する第１の送信手段と、
   前記第２の通信装置から、前記第１の通信装置に転送すべき動作要求と、前記第１の通信装置から転送されてきた動作要求に対する動作応答とを一括して受信する第２の受信手段と、
   該第２の受信手段が受信した各動作要求と各動作応答とを転送先となる前記各第１の通信装置に装置毎に一括して送信する第２の送信手段とを設けたことを特徴とする仲介装置。
3. 複数の第１の通信装置と第２の通信装置との間の通信を仲介する仲介装置であって、
   前記各第１の通信装置から、前記第２の通信装置に転送すべき動作要求と、前記第２の通信装置から転送されてきた動作要求に対する動作応答とを一括して受信する第１の受信手段と、
   該第１の受信手段が受信した各動作要求及び動作応答を、転送先となる第２の通信装置に一括して送信する第１の送信手段と、
   前記第２の通信装置から、前記第１の通信装置に転送すべき動作要求と、前記第１の通信装置から転送されてきた動作要求に対する動作応答とを一括して受信する第２の受信手段と、
   該第２の受信手段が受信した各動作要求と各動作応答とを転送先となる前記各第１の通信装置に装置毎に一括して送信する第２の送信手段とを設けたことを特徴とする仲介装置。
4. 請求項２又は３記載の仲介装置であって、
   前記第１の受信手段が受信した動作要求が当該仲介装置において実行すべきものであった場合にその動作要求に係る動作を実行し、実行結果としてその動作要求に対する動作応答を生成する応答生成手段を有し、
   前記第２の送信手段を、該応答生成手段が生成した動作応答も前記第２の受信手段が受信した各動作要求及び各動作応答と一括して前記第１の通信装置に送信する手段としたことを特徴とする仲介装置。
5. 複数の第１の通信装置と第２の通信装置との間の通信を仲介する仲介装置であって、
   前記各第１の通信装置から、前記第２の通信装置から転送されてきたＳＯＡＰリクエストに対するＳＯＡＰレスポンスを１つのＨＴＴＰリクエストに複数記載した状態で受信する第１の受信手段と、
   該第１の受信手段が受信した各ＳＯＡＰレスポンスを、転送先となる第２の通信装置に１つのＨＴＴＰに複数記載して送信する第１の送信手段と、
   前記第２の通信装置から、前記第１の通信装置に転送すべきＳＯＡＰリクエストを１つのＨＴＴＰリクエストに複数記載した状態で受信する第２の受信手段と、
   該第２の受信手段が受信した各ＳＯＡＰリクエストを、前記第１の受信手段が受信したＨＴＴＰリクエストに対する１つのＨＴＴＰレスポンスに複数記載して転送先となる前記各第１の通信装置に装置毎に送信する第２の送信手段とを設けたことを特徴とする仲介装置。
6. 請求項５記載の仲介装置であって、
   前記第１の送信手段に、前記第２の通信装置に対して定期的にＨＴＴＰリクエストを送信する手段を設けたことを特徴とする仲介装置。
7. 請求項５又は６記載の仲介装置であって、
   前記第２の送信手段は、前記第１の受信手段がＨＴＴＰリクエストを受信した場合に、その要求元に送信すべきＳＯＡＰリクエストを全て、受信したＨＴＴＰリクエストに対するＨＴＴＰレスポンスに記載して送信する手段であることを特徴とする仲介装置。
8. 処理サーバと、該処理サーバと複数の端末装置との間の通信を仲介する仲介サーバとを備えた分散処理システムであって、
   前記仲介サーバに、
   前記各端末装置から、前記処理サーバからの動作要求に対する動作応答を複数一括して受信する第１の受信手段と、
   該第１の受信手段が受信した各動作応答を、転送先となる処理サーバに複数一括して送信する第１の送信手段と、
   前記処理サーバから、前記端末装置宛ての動作要求を複数一括して受信する第２の受信手段と、
   該第２の受信手段が受信した各動作要求を転送先となる前記各端末装置に装置毎に複数一括して送信する第２の送信手段とを設け、
   前記処理サーバに、
   前記端末装置宛ての動作要求を複数一括して前記仲介サーバに送信する送信手段と、
   前記端末装置宛ての動作要求に対する動作応答を複数一括して前記仲介サーバから受信する受信手段とを設けた
   ことを特徴とする分散処理システム。
9. 処理サーバと、該処理サーバと複数の端末装置との間の通信を仲介する仲介サーバとを備えた分散処理システムであって、
   前記仲介サーバに、
   前記各端末装置から、動作要求と、前記処理サーバからの動作要求に対する動作応答とを一括して受信する第１の受信手段と、
   該第１の受信手段が受信した各動作要求及び動作応答を、各動作要求及び動作応答の種別に従って転送先となる処理サーバに一括して送信する第１の送信手段と、
   前記処理サーバから、前記端末装置宛ての動作要求と、前記端末装置からの動作要求に対する動作応答とを一括して受信する第２の受信手段と、
   該第２の受信手段が受信した各動作要求と各動作応答とを転送先となる前記各端末装置に装置毎に一括して送信する第２の送信手段とを設け、
   前記処理サーバに、
   前記端末装置からの当該処理サーバに対する動作要求と、前記端末装置宛ての動作要求に対する動作応答とを一括して前記仲介サーバから受信する受信手段と、
   該手段が受信した動作要求に係る動作を実行し、実行結果としてその動作要求に対する動作応答を生成する手段と、
   該手段が生成した動作応答と、前記端末装置宛ての動作要求とを一括して前記仲介サーバに送信する送信手段とを設けた
   ことを特徴とする分散処理システム。
10. 処理サーバと、該処理サーバと複数の端末装置との間の通信を仲介する仲介サーバとを備えた分散処理システムであって、
    前記仲介サーバに、
    前記各端末装置から、前記処理サーバ宛ての動作要求と、前記処理サーバからの動作要求に対する動作応答とを一括して受信する第１の受信手段と、
    該第１の受信手段が受信した各動作要求及び動作応答を、転送先となる処理サーバに一括して送信する第１の送信手段と、
    前記処理サーバから、前記端末装置宛ての動作要求と、前記端末装置からの動作要求に対する動作応答とを一括して受信する第２の受信手段と、
    該第２の受信手段が受信した各動作要求と各動作応答とを転送先となる前記各端末装置に装置毎に一括して送信する第２の送信手段とを設け、
    前記処理サーバに、
    前記端末装置からの当該処理サーバ宛ての動作要求と、前記端末装置宛ての動作要求に対する動作応答とを一括して前記仲介サーバから受信する受信手段と、
    該手段が受信した動作要求に係る動作を実行し、実行結果としてその動作要求に対する動作応答を生成する手段と、
    該手段が生成した動作応答と、前記端末装置宛ての動作要求とを一括して前記仲介サーバに送信する送信手段とを設けた
    ことを特徴とする分散処理システム。
11. 請求項９又は１０記載の分散処理システムであって、
    前記仲介サーバにおいて、
    前記第１の受信手段が受信した動作要求が当該仲介装置において実行すべきものであった場合にその動作要求に係る動作を実行し、実行結果としてその動作要求に対する動作応答を生成する応答生成手段を有し、
    前記第２の送信手段を、該応答生成手段が生成した動作応答も前記第２の受信手段が受信した各動作要求及び各動作応答と一括して前記端末装置に送信する手段としたことを特徴とする分散処理システム。
12. 処理サーバと、該処理サーバと複数の端末装置との間の通信を仲介する仲介サーバとを備えた分散処理システムであって、
    前記仲介サーバに、
    前記各端末装置から、前記処理サーバからのＳＯＡＰリクエストに対するＳＯＡＰレスポンスを１つのＨＴＴＰリクエストに複数記載した状態で受信する第１の受信手段と、
    該第１の受信手段が受信したＳＯＡＰレスポンスを、転送先となる処理サーバに１つのＨＴＴＰリクエストに複数記載して送信する第１の送信手段と、
    前記処理サーバから、前記端末装置宛てのＳＯＡＰリクエストを１つのＨＴＴＰレスポンスに複数記載した状態で受信する第２の受信手段と、
    該第２の受信手段が受信した各ＳＯＡＰリクエストを、前記第１の受信手段が受信したＨＴＴＰリクエストに対する１つのＨＴＴＰレスポンスに複数記載して、転送先となる前記端末装置に装置毎に送信する第２の送信手段とを設け、
    前記処理サーバに、
    前記端末装置宛てのＳＯＡＰリクエストに対するＳＯＡＰレスポンスを１つのＨＴＴＰリクエストに複数記載した状態で前記仲介サーバから受信する受信手段と、
    前記端末装置宛てのＳＯＡＰリクエストを、前記仲介サーバから受信したＨＴＴＰリクエストに対する１つのＨＴＴＰレスポンスに複数記載して前記仲介サーバに送信する送信手段と、
    を設けたことを特徴とする分散処理システム。
13. 請求項１２記載の分散処理システムであって、
    前記仲介サーバの第１の送信手段に、前記処理サーバに対して定期的にＨＴＴＰリクエストを送信する手段を設けたことを特徴とする分散処理システム。
14. 請求項１２又は１３記載の分散処理システムであって、
    前記仲介サーバの前記第２の送信手段は、前記第１の受信手段がＨＴＴＰリクエストを受信した場合に、その要求元に送信すべきＳＯＡＰリクエストを全て受信したＨＴＴＰリクエストに対するＨＴＴＰレスポンスに記載して送信する手段であり、
    前記処理サーバの送信手段は、当該処理サーバの受信手段がＨＴＴＰリクエストを受信した場合に、その要求元に送信すべきＳＯＡＰリクエストを全て受信したＨＴＴＰリクエストに対するＨＴＴＰレスポンスに記載して送信する手段であることを特徴とする分散処理システム。
15. 複数の第１の通信装置と第２の通信装置との間で仲介装置を介して動作要求及び動作応答を送受信させるデータ転送方法であって、
    前記仲介装置に、
    前記各第１の通信装置から、前記第２の通信装置から転送されてきた動作要求に対する動作応答を複数一括して受信する第１の受信手順と、
    該第１の受信手順で受信した各動作応答を、転送先となる第２の通信装置に複数一括して送信する第１の送信手順と、
    前記第２の通信装置から、前記第１の通信装置に転送すべき動作要求を複数一括して受信する第２の受信手順と、
    前記第２の受信手順で受信した各動作要求を、転送先となる前記各第１の通信装置に装置毎に一括して送信する第２の送信手順とを実行させることを特徴とするデータ転送方法。
16. 複数の第１の通信装置と第２の通信装置との間で仲介装置を介して動作要求及び動作応答を送受信させるデータ転送方法であって、
    前記仲介装置に、
    前記各第１の通信装置から、動作要求と、前記第２の通信装置から転送されてきた動作要求に対する動作応答とを一括して受信する第１の受信手順と、
    該第１の受信手順で受信した各動作要求及び動作応答を、各動作要求及び動作応答の種別に従って転送先となる第２の通信装置に一括して送信する第１の送信手順と、
    前記第２の通信装置から、前記第１の通信装置に転送すべき動作要求と、前記第１の通信装置から転送されてきた動作要求に対する動作応答とを一括して受信する第２の受信手順と、
    該第２の受信手順で受信した各動作要求と各動作応答とを転送先となる前記各第１の通信装置に装置毎に一括して送信する第２の送信手順とを実行させることを特徴とするデータ転送方法。
17. 複数の第１の通信装置と第２の通信装置との間で仲介装置を介して動作要求及び動作応答を送受信させるデータ転送方法であって、
    前記仲介装置に、
    前記各第１の通信装置から、前記第２の通信装置に転送すべき動作要求と、前記第２の通信装置から転送されてきた動作要求に対する動作応答とを一括して受信する第１の受信手順と、
    該第１の受信手順で受信した各動作要求及び動作応答を、転送先となる第２の通信装置に一括して送信する第１の送信手順と、
    前記第２の通信装置から、前記第１の通信装置に転送すべき動作要求と、前記第１の通信装置から転送されてきた動作要求に対する動作応答とを一括して受信する第２の受信手順と、
    該第２の受信手順で受信した各動作要求と各動作応答とを転送先となる前記各第１の通信装置に装置毎に一括して送信する第２の送信手順とを実行させることを特徴とするデータ転送方法。
18. 請求項１６又は１７記載のデータ転送方法であって、
    前記第１の受信手順で受信した動作要求が当該仲介装置において実行すべきものであった場合にその動作要求に係る動作を実行し、実行結果としてその動作要求に対する動作応答を生成する応答生成手順を有し、
    前記第２の送信手順を、該応答生成手順で生成した動作応答も前記第２の受信手順で受信した各動作要求及び各動作応答と一括して前記第１の通信装置に送信する手順としたことを特徴とするデータ転送方法。
19. 複数の第１の通信装置と第２の通信装置との間で仲介装置を介して動作要求及び動作応答を送受信させるデータ転送方法であって、
    前記仲介装置に、
    前記各第１の通信装置から、前記第２の通信装置から転送されてきたＳＯＡＰリクエストに対するＳＯＡＰレスポンスを１つのＨＴＴＰリクエストに複数記載した状態で受信する第１の受信手順と、
    該第１の受信手順で受信した各ＳＯＡＰレスポンスを、転送先となる第２の通信装置に１つのＨＴＴＰに複数記載して送信する第１の送信手順と、
    前記第２の通信装置から、前記第１の通信装置に転送すべきＳＯＡＰリクエストを１つのＨＴＴＰリクエストに複数記載した状態で受信する第２の受信手順と、
    該第２の受信手順で受信した各ＳＯＡＰリクエストを、前記第１の受信手順で受信したＨＴＴＰリクエストに対する１つのＨＴＴＰレスポンスに複数記載して転送先となる前記各第１の通信装置に装置毎に送信する第２の送信手順とを実行させることを特徴とするデータ転送方法。
20. 請求項１９記載のデータ転送方法であって、
    前記第１の送信手順に、前記第２の通信装置に対して定期的にＨＴＴＰリクエストを送信する手順を設けたことを特徴とするデータ転送方法。
21. 請求項１９又は２０記載のデータ転送方法であって、
    前記第２の送信手順は、前記第１の受信手順でＨＴＴＰリクエストを受信した場合に、その要求元に送信すべきＳＯＡＰリクエストを全て、受信したＨＴＴＰリクエストに対するＨＴＴＰレスポンスに記載して送信する手順であることを特徴とするデータ転送方法。
22. コンピュータを、複数の第１の通信装置と第２の通信装置との間の通信を仲介する仲介装置として機能させるためのプログラムであって、
    前記コンピュータを、
    前記各第１の通信装置から、前記第２の通信装置から転送されてきた動作要求に対する動作応答を複数一括して受信する第１の受信手段と、
    該第１の受信手段が受信した各動作応答を、転送先となる第２の通信装置に複数一括して送信する第１の送信手段と、
    前記第２の通信装置から、前記第１の通信装置に転送すべき動作要求を複数一括して受信する第２の受信手段と、
    前記第２の受信手段が受信した各動作要求を、転送先となる前記各第１の通信装置に装置毎に一括して送信する第２の送信手段として機能させるためのプログラム。
23. コンピュータを、複数の第１の通信装置と第２の通信装置との間の通信を仲介する仲介装置として機能させるためのプログラムであって、
    前記コンピュータを、
    前記各第１の通信装置から、動作要求と、前記第２の通信装置から転送されてきた動作要求に対する動作応答とを一括して受信する第１の受信手段と、
    該第１の受信手段が受信した各動作要求及び動作応答を、各動作要求及び動作応答の種別に従って転送先となる第２の通信装置に一括して送信する第１の送信手段と、
    前記第２の通信装置から、前記第１の通信装置に転送すべき動作要求と、前記第１の通信装置から転送されてきた動作要求に対する動作応答とを一括して受信する第２の受信手段と、
    該第２の受信手段が受信した各動作要求と各動作応答とを転送先となる前記各第１の通信装置に装置毎に一括して送信する第２の送信手段として機能させるためのプログラム。
24. コンピュータを、複数の第１の通信装置と第２の通信装置との間の通信を仲介する仲介装置として機能させるためのプログラムであって、
    前記コンピュータを、
    前記各第１の通信装置から、前記第２の通信装置に転送すべき動作要求と、前記第２の通信装置から転送されてきた動作要求に対する動作応答とを一括して受信する第１の受信手段と、
    該第１の受信手段が受信した各動作要求及び動作応答を、転送先となる第２の通信装置に一括して送信する第１の送信手段と、
    前記第２の通信装置から、前記第１の通信装置に転送すべき動作要求と、前記第１の通信装置から転送されてきた動作要求に対する動作応答とを一括して受信する第２の受信手段と、
    該第２の受信手段が受信した各動作要求と各動作応答とを転送先となる前記各第１の通信装置に装置毎に一括して送信する第２の送信手段として機能させるためのプログラム。
25. 請求項２３又は２４記載のプログラムであって、
    前記コンピュータを、
    前記第１の受信手段が受信した動作要求が当該仲介装置において実行すべきものであった場合にその動作要求に係る動作を実行し、実行結果としてその動作要求に対する動作応答を生成する応答生成手段として機能させるためのプログラムをさらに含み、
    前記第２の送信手段の機能を、該応答生成手段が生成した動作応答も前記第２の受信手段が受信した各動作要求及び各動作応答と一括して前記第１の通信装置に送信する機能としたことを特徴とするプログラム。
26. コンピュータを、複数の第１の通信装置と第２の通信装置との間の通信を仲介する仲介装置として機能させるためのプログラムであって、
    前記コンピュータを、
    前記各第１の通信装置から、前記第２の通信装置から転送されてきたＳＯＡＰリクエストに対するＳＯＡＰレスポンスを１つのＨＴＴＰリクエストに複数記載した状態で受信する第１の受信手段と、
    該第１の受信手段が受信した各ＳＯＡＰレスポンスを、転送先となる第２の通信装置に１つのＨＴＴＰに複数記載して送信する第１の送信手段と、
    前記第２の通信装置から、前記第１の通信装置に転送すべきＳＯＡＰリクエストを１つのＨＴＴＰリクエストに複数記載した状態で受信する第２の受信手段と、
    該第２の受信手段が受信した各ＳＯＡＰリクエストを、前記第１の受信手段が受信したＨＴＴＰリクエストに対する１つのＨＴＴＰレスポンスに複数記載して転送先となる前記各第１の通信装置に装置毎に送信する第２の送信手段として機能させるためのプログラム。
27. 請求項２６記載のプログラムであって、
    前記第１の送信手段に、前記第２の通信装置に対して定期的にＨＴＴＰリクエストを送信する機能を設けたことを特徴とするプログラム。
28. 請求項２６又は２７記載のプログラムであって、
    前記第２の送信手段の機能は、前記第１の受信手段がＨＴＴＰリクエストを受信した場合に、その要求元に送信すべきＳＯＡＰリクエストを全て、受信したＨＴＴＰリクエストに対するＨＴＴＰレスポンスに記載して送信する機能であることを特徴とするプログラム。
29. 請求項２２乃至２８のいずれか一項記載のプログラムを記録したコンピュータ読み取り可能な記録媒体。
    

Images