JP4160480B2

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

Info

Publication number: JP4160480B2
Application number: JP2003332571A
Authority: JP
Inventors: 弘幸松島
Original assignee: Ricoh Co Ltd
Current assignee: Ricoh Co Ltd
Priority date: 2002-09-24
Filing date: 2003-09-24
Publication date: 2008-10-01
Anticipated expiration: 2023-09-24
Also published as: JP2004140818A

Description

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

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

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

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

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

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

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

上記の目的を達成するため、この発明の仲介装置は、第１の通信装置と複数の第２の通信装置との間の通信を仲介する仲介装置において、記憶手段と、上記第１の通信装置から、上記第２の通信装置宛ての複数の動作要求を一括して受信するとともに、上記記憶手段に記憶させる一括受信手段と、その一括受信手段が受信した各動作要求を、その各動作要求に含まれる宛先情報に従って宛先となる第２の通信装置に送信する個別送信手段と、上記各第２の通信装置から、上記第１の通信装置からの動作要求に対する動作応答を受信するとともに、その動作応答と対応する動作要求と関連付けて上記記憶手段に記憶させる個別受信手段と、上記記憶手段に記憶された各動作応答を、それぞれ対応する動作要求を特定する情報を含んだ状態で一括して上記第１の通信装置に送信する一括送信手段とを設けたものである。

このような仲介装置において、上記動作要求及び動作応答をそれぞれ、形式を変更せずに複数結合して転送可能な１つのメッセージを生成することができる形式で表現し、また複数結合された状態では形式を変更せずに分割して転送可能な個々の動作要求及び動作応答に戻すことができる形式で表現するとよい。
さらに、仲介装置自身宛ての動作要求に係る動作を実行し、実行結果としてその動作要求に対する動作応答を生成する手段を設け、上記一括受信手段を、上記第１の通信装置から、上記第２の通信装置宛ての動作要求に加え、仲介装置自身宛ての動作要求も一括して受信する手段とし、上記一括送信手段を、上記第２の通信装置から受信した各動作応答に加え、上記第１の通信装置からの仲介装置自身宛ての動作要求に対する動作応答も一括して上記第１の通信装置に送信する手段とするとよい。
また、上記の各仲介装置において、上記記憶手段に記憶させた各動作要求について、その要求に関する処理の進行状況を管理し、その進行状況を示す進行情報を記憶する手段を設け、上記一括送信手段を、上記進行情報により要求に係る動作が実行済みであることが示されている動作要求に対する動作応答を上記記憶手段から読み出して上記第１の通信装置に送信する手段としてもよい。
あるいは、上記動作要求を、優先順位の情報を含むものとし、上記個別送信手段を、上記一括受信手段が受信した動作要求のうち、上記優先順位の高いものから優先的に上記宛先となる第２の通信装置に送信する手段としてもよい。

また、この発明は、第１の通信装置と複数の第２の通信装置との間の通信を仲介する仲介装置において、上記第１の通信装置からの上記第２の通信装置宛ての動作要求と、その動作要求に対する動作応答とを記憶する記憶手段と、上記第１の通信装置から、複数の上記動作要求を一括して受信する一括受信手段と、その一括受信手段が受信した各動作要求を、動作要求毎に分割して上記記憶手段に記憶させる分配手段と、上記動作要求を上記記憶手段から読み出すと共に、読み出した各動作要求を、その動作要求に含まれる宛先情報に従って宛先となる第２の通信装置に送信する個別送信手段と、上記各第２の通信装置から、上記動作応答を受信すると共に、受信した動作応答を、その動作応答と対応する動作要求と関連付けて上記記憶手段に記憶させる個別受信手段と、上記動作応答を上記記憶手段から読み出す収集手段と、上記第１の通信装置に対して、上記収集手段が読み出した複数の動作応答を、それぞれ対応する動作要求を特定する情報を含んだ状態で一括して送信する一括送信手段とを設けた仲介装置も提供する。

また、この発明は、第１の通信装置と複数の第２の通信装置との間の通信を仲介する仲介装置において、記憶手段と、上記第１の通信装置から、上記第２の通信装置宛ての複数のＳＯＡＰリクエストを１通の電子メールに記載した状態で受信するとともに、上記記憶手段に記憶させる一括受信手段と、その一括受信手段が受信した各ＳＯＡＰリクエストを、その各ＳＯＡＰリクエストに含まれる宛先情報に従って宛先となる第２の通信装置に送信する個別送信手段と、上記各第２の通信装置から、上記第１の通信装置からのＳＯＡＰリクエストに対するＳＯＡＰレスポンスを受信するとともに、そのＳＯＡＰレスポンスと対応するＳＯＡＰリクエストと関連付けて上記記憶手段に記憶させる個別受信手段と、上記記憶手段に記憶された各ＳＯＡＰレスポンスを、それぞれ対応するＳＯＡＰリクエストを特定する情報を含んだ状態で１通の電子メールに記載して上記第１の通信装置に送信する一括送信手段とを設けた仲介装置も提供する。

このような仲介装置において、上記ＳＯＡＰリクエスト及びＳＯＡＰレスポンスをそれぞれ、形式を変更せずに複数結合して転送可能な１つのメッセージを生成することができる形式で表現し、また複数結合された状態では形式を変更せずに分割して転送可能な個々のＳＯＡＰリクエスト及びＳＯＡＰレスポンスに戻すことができる形式で表現するとよい。
さらに、仲介装置自身宛てのＳＯＡＰリクエストによって要求された動作を実行し、そのＳＯＡＰリクエストに対するＳＯＡＰレスポンスに記載すべき実行結果を生成する手段を有し、上記一括受信手段を、上記第１の通信装置から、上記第２の通信装置宛てのＳＯＡＰリクエストに加え、仲介装置自身宛てのＳＯＡＰリクエストも１通の電子メールに記載した状態で受信する手段とし、上記一括送信手段を、上記第２の通信装置から受信した各ＳＯＡＰレスポンスに加え、上記第１の通信装置からの仲介装置自身宛てのＳＯＡＰリクエストに対するＳＯＡＰレスポンスも１通の電子メールに記載して上記第１の通信装置に送信する手段とするとよい。

さらに、この発明は、第１の通信装置と複数の第２の通信装置との間の通信を仲介する仲介装置において、上記第１の通信装置からの上記第２の通信装置宛ての動作要求と、その動作要求に対する動作応答とを記憶する記憶手段と、上記第１の通信装置から、上記動作要求の内容を記載した複数のＳＯＡＰリクエストを１通の電子メールに記載した状態で受信する一括受信手段と、その一括受信手段が受信した各ＳＯＡＰリクエストに記載された動作要求の内容を、動作要求毎に分割して上記記憶手段に記憶させる分配手段と、上記動作要求を上記記憶手段から読み出すと共に、読み出した各動作要求の内容を記載したＳＯＡＰリクエストを、その動作要求に含まれる宛先情報に従って宛先となる第２の通信装置に送信する個別送信手段と、上記各第２の通信装置から、上記動作応答の内容を記載したＳＯＡＰレスポンスを受信すると共に、受信したＳＯＡＰレスポンスに記載された動作応答の内容を、その動作応答と対応する動作要求と関連付けて上記記憶手段に記憶させる個別受信手段と、上記動作応答を上記記憶手段から読み出す収集手段と、上記第１の通信装置に対して、上記収集手段が読み出した動作応答の内容を記載した複数のＳＯＡＰレスポンスを、それぞれ対応するＳＯＡＰリクエストを特定する情報を含んだ状態で１通の電子メールに記載して送信する一括送信手段とを設けた仲介装置も提供する。

また、この発明の通信システムは、第１の通信装置と、複数の第２の通信装置と、その第１の通信装置と各第２の通信装置との間の通信を仲介する仲介装置とを備える通信システムにおいて、上記仲介装置に、記憶手段と、上記第１の通信装置から、上記第２の通信装置宛ての複数の動作要求を一括して受信するとともに、上記記憶手段に記憶させる一括受信手段と、その一括受信手段が受信した各動作要求を、その各動作要求に含まれる宛先情報に従って宛先となる第２の通信装置に送信する個別送信手段と、上記各第２の通信装置から、上記第１の通信装置からの動作要求に対する動作応答を受信するとともに、その動作応答と対応する動作要求と関連付けて上記記憶手段に記憶させる個別受信手段と、上記記憶手段に記憶された各動作応答を、それぞれ対応する動作要求を特定する情報を含んだ状態で一括して上記第１の通信装置に送信する一括送信手段とを設け、上記第１の通信装置に、上記第２の通信装置宛ての複数の動作要求を一括して上記仲介装置に送信する送信手段と、上記第２の通信装置宛ての動作要求に対する動作応答を、それぞれ対応する動作要求を特定する情報を含んだ状態で複数一括して上記仲介装置から受信する受信手段とを設け、上記各第２の通信装置に、上記第１の通信装置からのその第２の通信装置宛ての動作要求を上記仲介装置から受信する受信手段と、その手段が受信した動作要求に係る動作を実行し、実行結果として、その動作要求に対する動作応答であってその動作要求を特定する情報を含む動作応答を生成する手段と、その手段が生成した動作応答を上記仲介装置に送信する送信手段とを設けたものである。

このような通信システムにおいて、上記動作要求及び動作応答をそれぞれ、形式を変更せずに複数結合して転送可能な１つのメッセージを生成することができる形式で表現し、また複数結合された状態では形式を変更せずに分割して転送可能な個々の動作要求及び動作応答に戻すことができる形式で表現するとよい。
さらに、上記仲介装置に、仲介装置自身宛ての動作要求に係る動作を実行し、実行結果としてその動作要求に対する動作応答を生成する手段を設け、その仲介装置において、上記一括受信手段を、上記第１の通信装置から、上記第２の通信装置宛ての動作要求に加え、仲介装置自身宛ての動作要求も一括して受信する手段とし、上記一括送信手段を、上記第２の通信装置から受信した各動作応答に加え、上記第１の通信装置からの仲介装置自身宛ての動作要求に対する動作応答も一括して上記第１の通信装置に送信する手段とし、上記第１の通信装置において、上記送信手段を、上記第２の通信装置宛ての動作要求に加え、上記仲介装置宛ての動作要求も一括して上記仲介装置に送信する手段とし、上記受信手段を、上記第２の通信装置宛ての動作要求に対する動作応答に加え、上記仲介装置宛ての動作要求に対する動作応答も一括して上記仲介装置から受信する手段とするとよい。
また、上記の各通信システムにおいて、上記仲介装置に、上記記憶手段に記憶させた各動作要求について、その要求に関する処理の進行状況を管理し、その進行状況を示す進行情報を記憶する手段を設け、上記仲介装置の上記一括送信手段を、上記進行情報により要求に係る動作が実行済みであることが示されている動作要求に対する動作応答を上記記憶手段から読み出して上記第１の通信装置に送信する手段としてもよい。
あるいは、上記動作要求を、優先順位の情報を含むものとし、上記仲介装置の上記個別送信手段を、上記一括受信手段が受信した動作要求のうち、上記優先順位の高いものから優先的に上記宛先となる第２の通信装置に送信する手段としてもよい。

この発明はまた、第１の通信装置と、複数の第２の通信装置と、その第１の通信装置と各第２の通信装置との間の通信を仲介する仲介装置とを備える通信システムにおいて、上記仲介装置に、上記第１の通信装置からの上記第２の通信装置宛ての動作要求と、その動作要求に対する動作応答とを記憶する記憶手段と、上記第１の通信装置から、複数の上記動作要求を一括して受信する一括受信手段と、その一括受信手段が受信した各動作要求を、動作要求毎に分割して上記記憶手段に記憶させる分配手段と、上記動作要求を上記記憶手段から読み出すと共に、読み出した各動作要求を、その動作要求に含まれる宛先情報に従って宛先となる第２の通信装置に送信する個別送信手段と、上記各第２の通信装置から、上記動作応答を受信すると共に、受信した動作応答を、その動作応答と対応する動作要求と関連付けて上記記憶手段に記憶させる個別受信手段と、上記動作応答を上記記憶手段から読み出す収集手段と、上記第１の通信装置に対して、上記収集手段が読み出した複数の動作応答を、それぞれ対応する動作要求を特定する情報を含んだ状態で一括して送信する一括送信手段とを設け、上記第１の通信装置に、上記動作要求と上記動作応答とを記憶する記憶手段と、上記動作要求を生成して上記記憶手段に記憶させる要求生成手段と、上記動作要求を上記記憶手段から読み出す収集手段と、上記仲介装置に対して、上記収集手段が読み出した複数の動作要求を一括して送信する送信手段と、上記仲介装置から、上記動作応答を、それぞれ対応する動作要求を特定する情報を含んだ状態で複数一括して受信する受信手段と、その受信手段が受信した各動作応答を、それぞれの動作応答と対応する動作要求と関連付けて上記第２の記憶手段に記憶させる分配手段とを設け、上記各第２の通信装置に、上記動作要求を上記仲介装置から受信する受信手段と、その手段が受信した動作要求に係る動作を実行し、実行結果としてその動作要求に対する動作応答であってその動作要求を特定する情報を含む動作応答を生成する手段と、その手段が生成した動作応答を上記仲介装置に送信する送信手段とを設けた通信システムも提供する。

また、この発明は、第１の通信装置と、複数の第２の通信装置と、その第１の通信装置と各第２の通信装置との間の通信を仲介する仲介装置とを備える通信システムにおいて、上記仲介装置に、記憶手段と、上記第１の通信装置から、上記第２の通信装置宛ての複数のＳＯＡＰリクエストを１通の電子メールに記載した状態で受信するとともに、上記記憶手段に記憶させる一括受信手段と、その一括受信手段が受信した各ＳＯＡＰリクエストを、その各ＳＯＡＰリクエストに含まれる宛先情報に従って宛先となる第２の通信装置に送信する個別送信手段と、上記各第２の通信装置から、上記第１の通信装置からのＳＯＡＰリクエストに対するＳＯＡＰレスポンスを受信するとともに、そのＳＯＡＰレスポンスと対応するＳＯＡＰリクエストと関連付けて上記記憶手段に記憶させる個別受信手段と、上記記憶手段に記憶された各ＳＯＡＰレスポンスを、それぞれ対応するＳＯＡＰリクエストを特定する情報を含んだ状態で１通の電子メールに記載して上記第１の通信装置に送信する一括送信手段とを設け、上記第１の通信装置に、上記第２の通信装置宛ての複数のＳＯＡＰリクエストを１通の電子メールに記載して上記仲介装置に送信する送信手段と、上記第２の通信装置宛てのＳＯＡＰリクエストに対するＳＯＡＰレスポンスを複数、それぞれ対応するＳＯＡＰリクエストを特定する情報を含んだ状態かつ１通の電子メールに記載した状態で上記仲介装置から受信する受信手段とを設け、上記各第２の通信装置に、上記第１の通信装置からのその第２の通信装置宛てのＳＯＡＰリクエストを上記仲介装置から受信する受信手段と、その手段が受信したＳＯＡＰリクエストによって要求された動作を実行し、そのＳＯＡＰリクエストに対するＳＯＡＰレスポンスに記載すべき実行結果を生成する手段と、その手段が生成した実行結果を、上記ＳＯＡＰリクエストに対するＳＯＡＰレスポンスであって上記ＳＯＡＰリクエストを特定する情報を含むＳＯＡＰレスポンスに記載して上記仲介装置に送信する送信手段とを設けた通信システムも提供する。

このような通信システムにおいて、上記ＳＯＡＰリクエスト及びＳＯＡＰレスポンスをそれぞれ、形式を変更せずに複数結合して転送可能な１つのメッセージを生成することができる形式で表現し、また複数結合された状態では形式を変更せずに分割して転送可能な個々のＳＯＡＰリクエスト及びＳＯＡＰレスポンスに戻すことができる形式で表現するとよい。
さらに、上記仲介装置に、仲介装置自身宛てのＳＯＡＰリクエストによって要求された動作を実行し、そのＳＯＡＰリクエストに対するＳＯＡＰレスポンスに記載すべき実行結果を生成する手段を設け、その仲介装置において、上記一括受信手段を、上記第１の通信装置から、上記第２の通信装置宛てのＳＯＡＰリクエストに加え、仲介装置自身宛てのＳＯＡＰリクエストも１通の電子メールに記載した状態で受信する手段とし、上記一括送信手段を、上記第２の通信装置から受信した各ＳＯＡＰレスポンスに加え、上記第１の通信装置からの仲介装置自身宛てのＳＯＡＰリクエストに対するＳＯＡＰレスポンスも１通の電子メールに記載して上記第１の通信装置に送信する手段とし、上記第１の通信装置において、上記送信手段を、上記第２の通信装置宛てのＳＯＡＰリクエストに加え、上記仲介装置宛てのＳＯＡＰリクエストも１通の電子メールに記載して上記仲介装置に送信する手段とし、上記受信手段を、上記第２の通信装置宛てのＳＯＡＰリクエストに対するＳＯＡＰレスポンスに加え、上記仲介装置宛てのＳＯＡＰリクエストに対するＳＯＡＰレスポンスも１通の電子メールに記載した状態で上記仲介装置から受信する手段とするとよい。

さらにまた、この発明は、第１の通信装置と、複数の第２の通信装置と、その第１の通信装置と各第２の通信装置との間の通信を仲介する仲介装置とを備える通信システムにおいて、上記仲介装置に、上記第１の通信装置からの上記第２の通信装置宛ての動作要求と、その動作要求に対する動作応答とを記憶する記憶手段と、上記第１の通信装置から、上記動作要求の内容を記載した複数のＳＯＡＰリクエストを１通の電子メールに記載した状態で受信する一括受信手段と、その一括受信手段が受信した各ＳＯＡＰリクエストに記載された動作要求の内容を、動作要求毎に分割して上記記憶手段に記憶させる分配手段と、上記動作要求を上記記憶手段から読み出すと共に、読み出した各動作要求の内容を記載したＳＯＡＰリクエストを、その動作要求に含まれる宛先情報に従って宛先となる第２の通信装置に送信する個別送信手段と、上記各第２の通信装置から、上記動作応答の内容を記載したＳＯＡＰレスポンスを受信すると共に、受信したＳＯＡＰレスポンスに記載された動作応答の内容を、その動作応答と対応する動作要求と関連付けて上記記憶手段に記憶させる個別受信手段と、上記動作応答を上記記憶手段から読み出す収集手段と、上記第１の通信装置に対して、上記収集手段が読み出した動作応答の内容を記載した複数のＳＯＡＰレスポンスを、それぞれ対応するＳＯＡＰリクエストを特定する情報を含んだ状態で１通の電子メールに記載して送信する一括送信手段とを設け、上記第１の通信装置に、上記動作要求と上記動作応答とを記憶する記憶手段と、上記動作要求を生成して上記記憶手段に記憶させる要求生成手段と、上記動作要求を上記記憶手段から読み出す収集手段と、上記仲介装置に対して、上記収集手段が読み出した動作要求の内容を記載した複数のＳＯＡＰリクエストを１通の電子メールに記載して送信する送信手段と、上記仲介装置から、上記動作応答の内容を記載したＳＯＡＰレスポンスを複数、それぞれ対応するＳＯＡＰリクエストを特定する情報を含んだ状態かつ１通の電子メールに記載した状態で受信する受信手段と、上記受信手段が受信したＳＯＡＰレスポンスに記載された各動作応答の内容を、それぞれの動作応答と対応する動作要求と関連付けて上記記憶手段に記憶させる分配手段とを設け、上記各第２の通信装置に、上記第１の通信装置からのその第２の通信装置宛てのＳＯＡＰリクエストを上記仲介装置から受信する受信手段と、その手段が受信したＳＯＡＰリクエストによって要求された動作を実行し、そのＳＯＡＰリクエストに対するＳＯＡＰレスポンスであって上記ＳＯＡＰリクエストを特定する情報を含むＳＯＡＰレスポンスに記載すべき実行結果を生成する手段と、その手段が生成した実行結果を、上記ＳＯＡＰリクエストに対するＳＯＡＰレスポンスに記載して上記仲介装置に送信する送信手段とを設けた通信システムも提供する。

また、この発明の仲介装置の制御方法は、第１の通信装置と複数の第２の通信装置との間の通信を仲介する仲介装置の制御方法において、上記第１の通信装置から、上記第２の通信装置宛ての複数の動作要求を一括して受信するとともに、上記仲介装置の記憶手段に記憶させる一括受信手順と、その一括受信手順で受信した各動作要求を、その各動作要求に含まれる宛先情報に従って宛先となる第２の通信装置に送信する個別送信手順と、上記各第２の通信装置から、上記第１の通信装置からの動作要求に対する動作応答を受信するとともに、その動作応答と対応する動作要求と関連付けて上記記憶手段に記憶させる個別受信手順と、上記記憶手段に記憶された各動作応答を、それぞれ対応する動作要求を特定する情報を含んだ状態で一括して上記第１の通信装置に送信する一括送信手順とを上記仲介装置に実行させるようにしたものである。

このような仲介装置の制御方法において、上記動作要求及び動作応答をそれぞれ、形式を変更せずに複数結合して転送可能な１つのメッセージを生成することができる形式で表現し、また複数結合された状態では形式を変更せずに分割して転送可能な個々の動作要求及び動作応答に戻すことができる形式で表現するようにするとよい。
さらに、仲介装置自身宛ての動作要求に係る動作を実行し、実行結果としてその動作要求に対する動作応答を生成する手順をさらに上記仲介装置に実行させ、上記一括送信手順において、上記第２の通信装置から受信した各動作応答に加え、上記第１の通信装置からの仲介装置自身宛ての動作要求に対する動作応答も一括して上記第１の通信装置に送信するようにし、上記一括受信手順において、上記第１の通信装置から、上記第２の通信装置宛ての動作要求に加え、仲介装置自身宛ての動作要求も一括して受信するようにするとよい。
また、上記の各仲介装置の制御方法において、上記仲介装置にさらに、上記記憶手段に記憶させた各動作要求について、その要求に関する処理の進行状況を管理し、その進行状況を示す進行情報を記憶する手順を実行させ、上記一括送信手順を、上記進行情報により要求に係る動作が実行済みであることが示されている動作要求に対する動作応答を上記記憶手段から読み出して上記第１の通信装置に送信する手順としてもよい。
あるいは、上記動作要求を、優先順位の情報を含むものとし、上記個別送信手順を、上記一括受信手順で受信した動作要求のうち、上記優先順位の高いものから優先的に上記宛先となる第２の通信装置に送信する手順としてもよい。

また、この発明は、第１の通信装置と複数の第２の通信装置との間の通信を仲介する仲介装置の制御方法において、上記第１の通信装置からの上記第２の通信装置宛ての動作要求と、その動作要求に対する動作応答とを記憶する記憶領域を設ける手順と、上記第１の通信装置から、複数の上記動作要求を一括して受信する一括受信手順と、その一括受信手順で受信した各動作要求を、動作要求毎に分割して上記記憶領域に記憶させる分配手順と、上記動作要求を上記記憶領域から読み出すと共に、読み出した各動作要求を、その動作要求に含まれる宛先情報に従って宛先となる第２の通信装置に送信する個別送信手順と、上記各第２の通信装置から、上記動作応答を受信すると共に、受信した動作応答を、その動作応答と対応する動作要求と関連付けて上記記憶領域に記憶させる個別受信手順と、上記動作応答を上記記憶領域から読み出す収集手順と、上記第１の通信装置に対して、上記収集手順で読み出した複数の動作応答を、それぞれ対応する動作要求を特定する情報を含んだ状態で一括して送信する一括送信手順とを上記仲介装置に実行させる仲介装置の制御方法も提供する。

また、この発明は、第１の通信装置と複数の第２の通信装置との間の通信を仲介する仲介装置の制御方法において、上記第１の通信装置から、上記第２の通信装置宛ての複数のＳＯＡＰリクエストを１通の電子メールに記載した状態で受信するとともに、上記仲介装置の記憶手段に記憶させる一括受信手順と、その一括受信手順で受信した各ＳＯＡＰリクエストを、その各ＳＯＡＰリクエストに含まれる宛先情報に従って宛先となる第２の通信装置に送信する個別送信手順と、上記各第２の通信装置から、上記第１の通信装置からのＳＯＡＰリクエストに対するＳＯＡＰレスポンスを受信するとともに、そのＳＯＡＰレスポンスと対応するＳＯＡＰリクエストと関連付けて上記記憶手段に記憶させる個別受信手順と、上記記憶手段に記憶された各ＳＯＡＰレスポンスを、それぞれ対応するＳＯＡＰリクエストを特定する情報を含んだ状態で１通の電子メールに記載して上記第１の通信装置に送信する一括送信手順とを上記仲介装置に実行させる仲介装置の制御方法も提供する。

このような仲介装置の制御方法において、上記ＳＯＡＰリクエスト及びＳＯＡＰレスポンスをそれぞれ、形式を変更せずに複数結合して転送可能な１つのメッセージを生成することができる形式で表現し、また複数結合された状態では形式を変更せずに分割して転送可能な個々のＳＯＡＰリクエスト及びＳＯＡＰレスポンスに戻すことができる形式で表現するようにするとよい。
また、仲介装置自身宛てのＳＯＡＰリクエストによって要求された動作を実行し、そのＳＯＡＰリクエストに対するＳＯＡＰレスポンスに記載すべき実行結果を生成する手順をさらに上記仲介装置に実行させ、上記一括送信手順において、上記第２の通信装置から受信した各ＳＯＡＰレスポンスに加え、上記第１の通信装置からの仲介装置自身宛てのＳＯＡＰリクエストに対するＳＯＡＰレスポンスも１通の電子メールに記載して上記第１の通信装置に送信するようにし、上記一括受信手順において、上記第１の通信装置から、上記第２の通信装置宛てのＳＯＡＰリクエストに加え、仲介装置自身宛てのＳＯＡＰリクエストも１通の電子メールに記載した状態で受信するようにするとよい。

さらにまた、この発明は、第１の通信装置と複数の第２の通信装置との間の通信を仲介する仲介装置の制御方法において、上記第１の通信装置からの上記第２の通信装置宛ての動作要求と、その動作要求に対する動作応答とを記憶する記憶領域を設ける手順と、上記第１の通信装置から、上記動作要求の内容を記載した複数のＳＯＡＰリクエストを１通の電子メールに記載した状態で受信する一括受信手順と、その一括受信手順で受信した各ＳＯＡＰリクエストに記載された動作要求の内容を、動作要求毎に分割して上記記憶領域に記憶させる分配手順と、上記動作要求を上記記憶領域から読み出すと共に、読み出した各動作要求の内容を記載したＳＯＡＰリクエストを、その動作要求に含まれる宛先情報に従って宛先となる第２の通信装置に送信する個別送信手順と、上記各第２の通信装置から、上記動作応答の内容を記載したＳＯＡＰレスポンスを受信すると共に、受信したＳＯＡＰレスポンスに記載された動作応答の内容を、その動作応答と対応する動作要求と関連付けて上記記憶領域に記憶させる個別受信手順と、上記動作応答を上記記憶領域から読み出す収集手順と、上記第１の通信装置に対して、上記収集手順で読み出した動作応答の内容を記載した複数のＳＯＡＰレスポンスを、それぞれ対応するＳＯＡＰリクエストを特定する情報を含んだ状態で１通の電子メールに記載して送信する一括送信手順とを上記仲介装置に実行させる仲介装置の制御方法も提供する。

また、この発明のプログラムは、コンピュータを、第１の通信装置と複数の第２の通信装置との間の通信を仲介する仲介装置として機能させるためのプログラムであって、上記コンピュータを、記憶手段と、上記第１の通信装置から、上記第２の通信装置宛ての複数の動作要求を一括して受信するとともに、上記記憶手段に記憶させる一括受信手段と、その一括受信手段が受信した各動作要求を、その各動作要求に含まれる宛先情報に従って宛先となる第２の通信装置に送信する個別送信手段と、上記各第２の通信装置から、上記第１の通信装置からの動作要求に対する動作応答を受信するとともに、その動作応答と対応する動作要求と関連付けて上記記憶手段に記憶させる個別受信手段と、上記記憶手段に記憶された各動作応答を、それぞれ対応する動作要求を特定する情報を含んだ状態で一括して上記第１の通信装置に送信する一括送信手段として機能させるためのプログラムである。

このようなプログラムにおいて、上記動作要求及び動作応答をそれぞれ、形式を変更せずに複数結合して転送可能な１つのメッセージを生成することができる形式で表現し、また複数結合された状態では形式を変更せずに分割して転送可能な個々の動作要求及び動作応答に戻すことができる形式で表現するようにするとよい。
さらに、上記コンピュータを、上記仲介装置宛ての動作要求に係る動作を実行し、実行結果としてその動作要求に対する動作応答を生成する手段として機能させるためのプログラムを含め、上記一括受信手段の機能を、上記第１の通信装置から、上記第２の通信装置宛ての動作要求に加え、上記仲介装置宛ての動作要求も一括して受信する機能とし、上記一括送信手段の機能を、上記第２の通信装置から受信した各動作応答に加え、上記第１の通信装置からの上記仲介装置宛ての動作要求に対する動作応答も一括して上記第１の通信装置に送信する機能とするとよい。
また、上記の各プログラムにおいて、上記コンピュータをさらに、上記記憶手段に記憶させた各動作要求について、その要求に関する処理の進行状況を管理し、その進行状況を示す進行情報を記憶する手段として機能させるためのプログラムを含め、上記一括送信手段の機能を、上記進行情報により要求に係る動作が実行済みであることが示されている動作要求に対する動作応答を上記記憶手段から読み出して上記第１の通信装置に送信する機能とするとよい。
あるいは、上記動作要求を、優先順位の情報を含むものとし、上記個別送信手段の機能を、上記一括受信手段が受信した動作要求のうち、上記優先順位の高いものから優先的に上記宛先となる第２の通信装置に送信する機能としてもよい。

この発明はまた、コンピュータを、第１の通信装置と複数の第２の通信装置との間の通信を仲介する仲介装置として機能させるためのプログラムであって、上記コンピュータを、上記第１の通信装置からの上記第２の通信装置宛ての動作要求と、その動作要求に対する動作応答とを記憶する記憶手段と、上記第１の通信装置から、複数の上記動作要求を一括して受信する一括受信手段と、その一括受信手段が受信した各動作要求を、動作要求毎に分割して上記記憶手段に記憶させる分配手段と、上記動作要求を上記記憶手段から読み出すと共に、読み出した各動作要求を、その動作要求に含まれる宛先情報に従って宛先となる第２の通信装置に送信する個別送信手段と、上記各第２の通信装置から、上記動作応答を受信すると共に、受信した動作応答を、その動作応答と対応する動作要求と関連付けて上記記憶手段に記憶させる個別受信手段と、上記動作応答を上記記憶手段から読み出す収集手段と、上記第１の通信装置に対して、上記収集手段が読み出した複数の動作応答を、それぞれ対応する動作要求を特定する情報を含んだ状態で一括して送信する一括送信手段として機能させるためのプログラムも提供する。

また、この発明は、コンピュータを、第１の通信装置と複数の第２の通信装置との間の通信を仲介する仲介装置として機能させるためのプログラムであって、上記コンピュータを、記憶手段と、上記第１の通信装置から、上記第２の通信装置宛ての複数のＳＯＡＰリクエストを１通の電子メールに記載した状態で受信するとともに、上記記憶手段に記憶させる一括受信手段と、その受信手段が受信した各ＳＯＡＰリクエストを、その各ＳＯＡＰリクエストに含まれる宛先情報に従って宛先となる第２の通信装置に送信するとともに、そのＳＯＡＰレスポンスと対応するＳＯＡＰリクエストと関連付けて上記記憶手段に記憶させる個別送信手段と、上記各第２の通信装置から、上記第１の通信装置からのＳＯＡＰリクエストに対するＳＯＡＰレスポンスを受信する個別受信手段と、上記記憶手段に記憶された各ＳＯＡＰレスポンスを、それぞれ対応するＳＯＡＰリクエストを特定する情報を含んだ状態で１通の電子メールに記載して上記第１の通信装置に送信する一括送信手段として機能させるためのプログラムも提供する。

このようなプログラムにおいて、上記ＳＯＡＰリクエスト及びＳＯＡＰレスポンスをそれぞれ、形式を変更せずに複数結合して転送可能な１つのメッセージを生成することができる形式で表現し、また複数結合された状態では形式を変更せずに分割して転送可能な個々のＳＯＡＰリクエスト及びＳＯＡＰレスポンスに戻すことができる形式で表現するようにするとよい。
さらに、上記コンピュータを、上記仲介装置宛てのＳＯＡＰリクエストによって要求された動作を実行し、そのＳＯＡＰリクエストに対するＳＯＡＰレスポンスに記載すべき実行結果を生成する手段として機能させるためのプログラムを含め、上記一括受信手段の機能を、上記第１の通信装置から、上記第２の通信装置宛てのＳＯＡＰリクエストに加え、上記仲介装置宛てのＳＯＡＰリクエストも１通の電子メールに記載した状態で受信する機能とし、上記一括送信手段の機能を、上記第２の通信装置から受信した各ＳＯＡＰレスポンスに加え、上記第１の通信装置からの上記仲介装置宛てのＳＯＡＰリクエストに対するＳＯＡＰレスポンスも１通の電子メールに記載して上記第１の通信装置に送信する機能とするとよい。

さらにまた、この発明は、コンピュータを、第１の通信装置と複数の第２の通信装置との間の通信を仲介する仲介装置として機能させるためのプログラムであって、上記コンピュータを、上記第１の通信装置からの上記第２の通信装置宛ての動作要求と、その動作要求に対する動作応答とを記憶する記憶手段と、上記第１の通信装置から、上記動作要求の内容を記載した複数のＳＯＡＰリクエストを１通の電子メールに記載した状態で受信する一括受信手段と、その一括受信手段が受信した各ＳＯＡＰリクエストに記載された動作要求の内容を、動作要求毎に分割して上記記憶手段に記憶させる分配手段と、上記動作要求を上記記憶手段から読み出すと共に、読み出した各動作要求の内容を記載したＳＯＡＰリクエストを、その動作要求に含まれる宛先情報に従って宛先となる第２の通信装置に送信する個別送信手段と、上記各第２の通信装置から、上記動作応答の内容を記載したＳＯＡＰレスポンスを受信すると共に、受信したＳＯＡＰレスポンスに記載された動作応答の内容を、その動作応答と対応する動作要求と関連付けて上記記憶手段に記憶させる個別受信手段と、上記動作応答を上記記憶手段から読み出す収集手段と、上記第１の通信装置に対して、上記収集手段が読み出した動作応答の内容を記載した複数のＳＯＡＰレスポンスを、それぞれ対応するＳＯＡＰリクエストを特定する情報を含んだ状態で１通の電子メールに記載して送信する一括送信手段として機能させるためのプログラムも提供する。

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

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

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

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

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

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

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

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

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

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

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

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

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

図２（Ｃ）は、管理装置１０２で、被管理装置１０に対する動作要求が発生したケースである。このケースでは、管理装置１０２が管理装置側動作要求ｃを生成し、これを仲介装置１０１を経由して受け取った被管理装置１０が、その動作要求に対する動作応答ｃを返すというモデルになる。なお、被管理装置１０が使用する一般的な通信プロトコルは、遅延通知を返す機能を有していないが、仲介装置１０１が代わって遅延通知を行うことは考えられる（図示は省略した）。

図２（Ｄ）は、管理装置１０２で仲介装置１０１に対する動作要求が発生したケースである。このケースでは、管理装置１０２が管理装置側動作要求ｄを生成し、これを受け取った仲介装置１０１が、その動作要求に対する動作応答ｄを返すというモデルになる。なお、図２（Ｄ）のケースでは、図２（Ａ）のケースと同様に、応答を即座に返せないときに遅延通知ｄ′を返す。
なお、ここではＲＰＣによる引数並びに戻り値の受け渡しのプロトコルとしてＳＯＡＰ（Simple Object Access Protocol）を採用し、上記の動作要求や動作応答は、ここではＳＯＡＰメッセージとして記載するようにしている。

この発明の特徴は、このように管理装置１０２のような通信装置が被管理装置１０のような複数の通信相手との間で互いに動作要求及び受信した動作要求に対する動作応答を送受信する場合において、その送受信を仲介する仲介装置を設け、その仲介装置が、上記通信装置から各通信相手に宛てた動作要求や動作応答を一括して受信すると共にこれを分割して各宛先に転送し、また上記通信相手から上記通信装置に宛てた動作要求や動作応答を収集すると共にこれらを一括して上記通信装置に転送するようにする点である。ここで、動作要求は上記通信装置からのみ送信し、上記通信相手はこの動作要求に対する動作応答のみを上記通信装置に送信する構成であっても、この発明を適用することができる。

そして、実際に動作要求や動作応答を転送するための通信プロトコルとしては、システムの構成に合わせて適当なものを採用することができ、例えばＨＴＴＰ（HyperText Transfer Protocol）やＳＭＴＰ（Simple Mail Transfer Protocol）を採用することができる。ここでは、通信プロトコルにＨＴＴＰを採用する場合の実施形態を示しており、ＳＭＴＰを採用する場合については後の実施形態で説明する。
まず、この第１の実施形態について、より具体的な実施例を用いて説明する。

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

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

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

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

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

図４（Ｄ）は、管理装置１０２で仲介装置１０１に対する動作要求が発生したケースである。このケースでは、管理装置１０２が管理装置側動作要求（管理装置コマンド）ｄを生成し、これを受け取った仲介装置１０１が、そのコマンドに対する動作応答ｄを返すというモデルになる。なお、図４（Ｄ）のケースでは、図２（Ａ）のケースと同様に、応答を即座に返せないときに遅延通知ｄ′を返す。
このように、動作要求及び動作応答は、ＲＰＣのレベルでは、画像形成装置１００と管理装置１０２との間及び仲介装置１０１と管理装置１０２との間で対称に取り扱われるものである。しかし、通信のレベルでは対称ではない。

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

また、上述したように、画像形成装置１００は、管理装置コマンドを仲介装置１０１を経由して受け取るが、この場合、仲介装置１０１がＨＴＴＰリクエストに管理装置コマンドを記載して画像形成装置１００に送信する（ＨＴＴＰリクエストＸ，Ｙ）。そして、画像形成装置１００は、この管理装置コマンドに対する応答を、そのＨＴＴＰリクエストに対するＨＴＴＰレスポンスに記載して送信する（ＨＴＴＰレスポンスＸ，Ｙ）。
また、逆に画像形成装置１００が画像機器コマンドを仲介装置１０１を介して管理装置１０２に送信する場合には、画像形成装置１００がＨＴＴＰリクエストに画像機器コマンドを記載して仲介装置１０１に送信し（ＨＴＴＰリクエストＺ）、仲介装置１０１は、この画像機器コマンドに対する応答を、そのＨＴＴＰリクエストに対するＨＴＴＰレスポンスに記載して送信する（ＨＴＴＰレスポンスＺ）。

なお、後者の場合には、仲介装置１０１が管理装置１０２に画像機器コマンドを転送し、処理を実行させて応答を受け取るまでに時間がかかることも考えられるので、以下のような手順とすることも考えられる。
すなわち、画像形成装置１００がＨＴＴＰリクエストに画像機器コマンドを記載して仲介装置１０１に送信し（ＨＴＴＰリクエストＺ′）、これに対して仲介装置１０１はＨＴＴＰレスポンスにコマンドの受付通知を記載して返信し（ＨＴＴＰレスポンスＺ）、コマンドを管理装置１０２に転送して応答を待つ。そして、画像機器コマンドに対する応答を管理装置１０２から受信すると、これをＨＴＴＰリクエストに記載して画像形成装置１００に送信する（ＨＴＴＰリクエストＷ）。これによって画像形成装置１００は画像機器コマンドに対する応答を取得でき、ＨＴＴＰレスポンスに応答の受信通知を記載して返信する（ＨＴＴＰレスポンスＷ）、という手順である。
しかし、以下の説明においては、上記のＨＴＴＰレスポンスＺに応答を記載する手順を採用した場合について説明する。

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

そして、ＨＴＴＰリクエストには、仲介装置１０１からの管理装置１０２宛ての動作要求である仲介装置コマンドと、画像形成装置１００からの管理装置１０２宛ての動作要求である画像機器コマンドと、管理装置１０２から仲介装置１０１に送信されてきた管理装置コマンドに対する応答（コマンド応答）と、管理装置１０２から画像形成装置１００に送信されてきた管理装置コマンドに対する応答とを記載して送信するようにしている。また、ＨＴＴＰレスポンスには、管理装置１０２からの仲介装置１０１宛て又は画像形成装置１００宛ての動作要求である管理装置コマンドと、仲介装置１０１からの管理装置１０２宛ての動作要求である仲介装置コマンドに対する応答と、画像形成装置１００からの管理装置１０２宛ての動作要求である画像機器コマンドに対する応答とを記載して送信するようにしている。なお、遅延通知を送信する場合には、上記コマンド応答に代えて遅延通知を記載してもよい。

例えば画像機器コマンドＡ及び仲介装置コマンドＢは、ＨＴＴＰリクエストＸに記載して転送し、コマンド応答あるいは遅延通知をそのＨＴＴＰリクエストＸと対応するＨＴＴＰレスポンスＸに記載して転送することができる。しかし、管理装置コマンドＣ及びＤについては、ＨＴＴＰリクエストＸと対応するＨＴＴＰレスポンスＸに記載して転送し、そのコマンド応答あるいは遅延通知は次のＨＴＴＰリクエストであるＨＴＴＰリクエストＹに記載して転送することになる。
ここで、画像機器宛ての管理装置コマンドＤに対して仲介装置１０１が返す遅延通知は、画像形成装置１００が生成したものではなく、後述するように、仲介装置１０１が生成したものである。

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

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

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

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

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

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

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

制御装置１２６は、図示しないＣＰＵ，ＲＯＭ，ＲＡＭ等からなるマイクロコンピュータを備えており、管理装置１０２全体を統括的に制御する。そのＣＰＵが、ＲＯＭ等に記憶している制御プログラムを必要に応じて実行すると共に、モデム１２１，通信端末１２２，プロキシサーバ１２３，操作者端末１２４またはデータベース１２５を利用することにより、この発明による機能（記憶手段，要求生成手段，収集手段，分配手段，送信手段，受信手段，その他の手段としての機能）を実現することができる。
なお、管理装置の構成はこれに限られることはなく、例えば１台のＰＣを用いて構成することもできる。

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

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

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

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

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

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

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

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

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

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

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

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

次に、図１１に、仲介装置１０１の機能のうち、コマンド及びコマンド応答に関する処理を行うための機能の構成を示す機能ブロック図を示す。なお、この図において各手段及び機能部間の関連については図示を省略しており、図１２には、仲介装置１０１が管理装置１０２と通信を行う場合のデータの流れを示している。そこで、まず図１１及び図１２を参照して、管理装置１０２との通信に関連する部分の仲介装置１０１の機能について説明する。

図１１に示す機能のうち、被管理側コマンドプール４１及び管理装置コマンドプール４２は、いずれかの書き換え可能な記憶手段に設けられるものである。例えばフラッシュメモリ５４に設けることができるが、ＳＤＲＡＭ５３やＨＤＤ６３に設けてもよい。仲介装置コマンド生成手段４３、管理装置コマンド実行結果生成手段４４、送信メッセージ収集手段４５、受信メッセージ分配手段４８、応答状況管理手段４９の機能は、ＣＰＵ５２によって実現されるものである。また、ＨＴＴＰサーバ機能部４６及びＨＴＴＰクライアント機能部４７の機能は、ＣＰＵ５２及びＰＨＹ５７によって実現されるものである。

これらの機能についてさらに詳述する。
まず、被管理側コマンドプール４１は、仲介装置１０１に設けた第２の記憶領域に該当し、画像機器コマンド及び仲介機器コマンドを、これらのコマンドに対する応答や、このコマンドの識別情報及びコマンドの宛先や送信元の情報等と関連付けて登録するプールである。以後、画像機器コマンドと仲介機器コマンドとを一括して「被管理側コマンド」とも呼ぶことにする。

また、管理装置コマンドプール４２は、仲介装置１０１に設けた第１の記憶領域に該当し、管理装置コマンドを、このコマンドに対する応答や、このコマンドの識別情報及びこのコマンドの宛先や送信元の情報等と関連付けて登録するプールである。
これらのプールにおいては、コマンド毎にテーブル形式のコマンドシートを作成して情報を格納することにより、コマンドと、識別情報や応答等の情報とを関連付けるようにしている。また、これらのプールを設けた記憶手段がそれぞれ仲介装置１０１の第２，第１の記憶手段に該当するものとする。

仲介装置コマンド生成手段４３は、要求生成手段に該当する。そして、被管理側コマンドを生成し、このコマンドを識別する識別情報（ＩＤ）を割り当て、さらにこのコマンドの送信元情報やこのコマンドを管理するための管理情報を付し、これらの情報を関連付けてテーブル形式の被管理側コマンドシートとして被管理側コマンドプール４１に登録する機能を有する。この処理を行うのが仲介装置コマンド生成ハンドラ４３ａであり、このうち、仲介装置コマンドを生成する部分には、例えば仲介装置１０１に備えるアプリケーションが該当する。また、仲介装置コマンド生成ハンドラ４３ａに、管理装置１０２に各コマンドを実行させる際の優先順位を、生成した仲介装置コマンドに付する機能を設けてもよい。
また、図１１及び図１２には図示していないが、後述するように、仲介装置コマンド生成手段４３は、画像形成装置１００から受信した画像機器コマンドを、管理情報を付して被管理側コマンドシートとして被管理側コマンドプール４１に登録すると共に、そのコマンドに対する応答を被管理側コマンドプール４１から読み出して画像形成装置１００に転送する機能も有する。

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

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

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

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

また、管理装置コマンドハンドラ４４ａに、管理装置コマンドプール４２から複数の種類の管理装置コマンドを読み出し、各管理装置コマンドに対する応答を生成する機能を設けることが考えられる。さらに、管理装置コマンドが仲介装置１０１に優先して処理を実行させるための実行優先順位の情報を含む場合には、優先順位の高いものから優先的に読み出して実行する機能を設けることも考えられる。
なお、管理装置コマンドハンドラ４４ａは、アプリケーションそのものではなく、管理装置コマンドの実行に必要なアプリケーションを呼び出してコマンドを実行させるモジュールであってもよい。
また、図１１及び図１２では図示していないが、後述するように、管理装置コマンド実行結果生成手段４４は、画像形成装置１００や被管理仲介装置１１０宛ての管理装置コマンドを管理装置コマンドプール４２から読み出して画像形成装置１００や被管理仲介装置１１０に転送すると共に、そのコマンドに対する応答を取得して管理装置コマンドプール４２に登録する機能も有する。

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

各データの内容について説明する。
まず、「メソッド名」は、仲介装置１０１に対するリクエストの内容であり、仲介装置１０１において呼び出す関数の種類を示す。「入力パラメータ」は、「メソッド名」に付随するデータであり、関数を呼び出す際の引数である。
「送信元情報」は、コマンドの送信元、すなわちコマンドを生成した装置の識別情報を示す。管理装置コマンドの場合には、ここには管理装置１０２の識別情報を登録することになる。またこの情報は、コマンドに対する応答を送信する際の宛先を示す情報になる。「宛先情報」は、コマンドを実行させる対象の装置、すなわちコマンドの宛先となる装置の識別情報を示す。

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

再び図１１の説明に戻ると、送信メッセージ収集手段４５は、収集手段に該当する。そして、管理装置コマンド実行結果生成手段４４が生成したコマンド応答とこのコマンド応答に対応する管理装置コマンドのコマンドＩＤ及び宛先情報とを関連付けて管理装置コマンドプール４２から読み出すと共に、仲介装置コマンド生成手段４３が生成した被管理側コマンドとこのコマンドのコマンドＩＤ及び送信元情報とを関連付けて被管理側コマンドプール４１から読み出し、これらから送信メッセージを生成する機能を有する。さらに、遅延通知が必要な管理装置コマンドについて、そのコマンドＩＤ及び宛先情報を関連付けて管理装置コマンドプール４２から読み出し、遅延通知の送信メッセージを生成する機能も有する。
なお、コマンド応答や被管理側コマンドに実行優先順位が指定されている場合には、送信メッセージ収集手段４５がそれぞれ実行優先順位の高いものから順に読み出すようにすることが考えられる。

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

また、ＨＴＴＰクライアント機能部４７は、ＨＴＴＰリクエストを送信するＨＴＴＰリクエスト送信手段４７ａとＨＴＴＰレスポンスを受信するＨＴＴＰレスポンス受信手段４７ｂとを備える。そして、ＨＴＴＰリクエスト送信手段４７ａは、一括送信手段に該当し、送信メッセージ収集手段４５が生成した送信メッセージを記載したＨＴＴＰリクエストを生成し、管理装置１０２に送信する機能を有する。このとき、１つのＨＴＴＰリクエストに送信メッセージをいくつ含めてもよいし、コマンド応答に係る送信メッセージと被管理側コマンドに係る送信メッセージと遅延通知に係る送信メッセージとを任意に混在させることもできる。もちろん、送信元の異なるコマンドやコマンド応答あるいは遅延通知に係る送信メッセージを混在させてもよい。
そこで、ＨＴＴＰリクエスト送信手段４７ａは、これらのいずれに係る送信メッセージかに関わり無く、送信メッセージ収集手段４５が生成した全ての送信メッセージを１つのＨＴＴＰリクエストに含めて送信するようにしている。ただし、１つのＨＴＴＰリクエストに含める送信メッセージの数に上限を設けることも考えられる。

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

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

また、ＨＴＴＰレスポンス受信手段４７ｂは、一括受信手段に該当し、管理装置１０２からＨＴＴＰレスポンスを受信する機能を有する。そしてここでは、ＨＴＴＰレスポンスには、管理装置コマンド及びそのコマンドと関連付けられたコマンドＩＤと宛先情報を含む受信メッセージと、被管理側コマンドに対する応答及びそのコマンドと関連付けられたコマンドＩＤと送信元情報を含む受信メッセージと、被管理側コマンドに対する遅延通知及びそのコマンドと関連付けられたコマンドＩＤと送信元情報を含む受信メッセージとが、任意に混在して含まれている。
ここで、受信メッセージとは、上記のコマンドや応答、遅延通知とコマンドＩＤ等とをＳＯＡＰメッセージとして記載したものである。

受信メッセージ分配手段４８は、第１の分配手段に該当する。そして、ＨＴＴＰレスポンス受信手段４７ｂが受信したＨＴＴＰレスポンスに含まれるデータを、被管理側コマンドプール４１及び管理装置コマンドプール４２に振り分けて登録する機能を有する。
具体的には、管理装置コマンド及びそのコマンドと関連付けられたコマンドＩＤ及び宛先情報とを管理装置コマンドプール４２に管理装置コマンドシートを設けて登録すると共に、被管理側コマンドに対する応答については、そのコマンドと関連付けられたコマンドＩＤを被管理側コマンドプール４１に記憶している被管理側コマンドシートのコマンドＩＤと照合して対応する被管理側コマンドを特定し、その被管理側コマンドについての「出力パラメータ」として登録する。被管理側コマンドに対する遅延通知については、やはりコマンドＩＤをもとに被管理側コマンドを特定し、そのコマンドについての「状態」を「応答遅延」に変更して応答の受信が遅延することを示す。
そしてこのとき、ＨＴＴＰレスポンスを分割してそこに含まれる各受信メッセージを取り出し、そのデータをテーブルへの登録に必要な形式に変換するが、この変換は、ＷＳＤＬに基づいて生成される所要の変換プログラム（デシリアライザ）を実行することによって行うことができる。

応答状況管理手段４９は、管理装置コマンドプール４２に登録されている管理装置コマンドに対するコマンド応答の生成状況を管理する手段である。そして、管理装置コマンドについて、管理装置コマンドプール４２に登録後、所定時間内にコマンド応答を生成できない場合には、管理装置１０２に対して遅延通知が必要である旨を設定する。具体的には、管理装置コマンドシートの「状態」を「遅延未通知」に変更する。
なお、ＨＴＴＰサーバ機能部４６は、ＨＴＴＰレスポンスを送信するＨＴＴＰレスポンス送信手段４６ａとＨＴＴＰリクエストを受信するＨＴＴＰリクエスト受信手段４６ｂとを備えるが、管理装置１０２との通信においては使用しない。

次に、図１５に、図１１に示した管理装置１０２の機能構成において、仲介装置１０１が画像形成装置１００と通信を行う場合のデータの流れを示す。そして、図１５を参照して、この場合の仲介装置１０１の機能について説明する。
この場合においては、図１１及び図１２では図示を省略していた、仲介装置コマンド生成手段４３の画像機器コマンド転送ハンドラ４３ｂ及び管理装置コマンド実行結果生成手段４４の管理装置コマンド転送ハンドラ４４ｂが重要な役割を担う。

まず、画像機器コマンド転送ハンドラ４３ｂについては、画像機器コマンドを被管理側コマンドプール４１に登録し、またそのコマンドに対する応答を画像形成装置１００に転送する機能を有する。
すなわち、画像機器コマンド転送ハンドラ４３ｂは、画像形成装置１００が生成してＳＯＡＰメッセージとしてＨＴＴＰリクエストに記載して送信してきた画像機器コマンドを、ＨＴＴＰサーバ機能部４６のＨＴＴＰリクエスト受信手段４６ｂを介して受信すると共に、受信した画像機器コマンドに管理情報を付し、ＩＤと関連付けてテーブル形式の被管理側コマンドシートとして被管理側コマンドプール４１に登録する機能を有する。この場合において、画像機器コマンド転送ハンドラ４３ｂとＨＴＴＰリクエスト受信手段４６ｂとが個別受信手段に該当し、画像機器コマンド転送ハンドラ４３ｂが第２の分配手段に該当する。また、ここで行う処理が、個別受信手順、第２の分配手順の処理に該当する。

またこのとき、被管理側コマンドシートの形式は、仲介装置の場合と全く同じものであり、画像機器コマンドは、仲介装置コマンドの場合と同様に送信メッセージ収集手段４５が収集して管理装置１０２に転送し、管理装置１０２からの応答は、受信メッセージ分配手段４８が分配して被管理側コマンドプールに登録する。
そして、画像機器コマンド転送ハンドラ４３ｂは、この登録があった場合に、被管理側コマンドプール４１から画像機器コマンドに対する応答を読み出して、ＳＯＡＰによる送信メッセージを生成し、ＨＴＴＰレスポンス送信手段４６ａを介して、画像形成装置１００が画像機器コマンドを記載して送信してきたＨＴＴＰリクエストに対するＨＴＴＰレスポンスに記載して画像形成装置１００に転送する機能も有する。この場合において、画像機器コマンド転送ハンドラ４３ｂとＨＴＴＰレスポンス送信手段４６ａとが個別送信手段として機能し、ここで行う処理が、個別送信手順の処理に該当する。。
また、図示は省略したが、被管理仲介装置１１０や、被管理仲介装置１１０の通信相手となる画像形成装置１００が被管理側コマンドを生成した場合には、コマンドを被管理仲介装置１１０から受信すると共に、応答を被管理仲介装置１１０に転送して必要な処理（画像形成装置１００への転送も含む）を実行させることになる。

次に、管理装置コマンド転送ハンドラ４４ｂについては、管理装置コマンドプール４２に登録された、画像形成装置１００宛ての管理装置コマンドを画像形成装置１００に転送し、応答を取得してこれを管理装置コマンドプールに登録する機能を有する。
すなわち、管理装置コマンド転送ハンドラ４４ｂは、画像形成装置１００宛ての管理装置コマンドが管理装置コマンドプール４２に登録されている場合、このコマンドに対する処理を行おうとする際に、処理用のハンドラとして呼び出される。そして、この場合、管理装置コマンド転送ハンドラ４４ｂは、管理装置コマンドプール４２から管理装置コマンドを読み出し、ＳＯＡＰによる送信メッセージを生成して、ＨＴＴＰリクエスト送信手段４７ａを介してＨＴＴＰリクエストに記載して画像形成装置１００に転送し、画像形成装置１００にそのコマンドに応じた動作を実行させる機能を有する。このときどの画像形成装置１００に転送するかは、管理装置コマンドシートの「宛先情報」を参照して定めることができる。また、この場合において、管理装置コマンド転送ハンドラ４４ｂとＨＴＴＰリクエスト送信手段４７ａとが個別送信手段に該当し、ここで行う処理も、個別送信手順の処理に該当する。

そして、画像形成装置１００が動作を実行して動作応答をＳＯＡＰメッセージとしてＨＴＴＰレスポンスに記載して返してくると、ＨＴＴＰレスポンス受信手段４７ｂを介してこれを受信し、その内容を管理装置コマンドプール４２の、実行した管理装置コマンドについての管理装置コマンドシートに登録する。この場合において、管理装置コマンド転送ハンドラ４４ｂとＨＴＴＰレスポンス受信手段４７ｂとが個別受信手段に該当し、管理装置コマンド転送ハンドラ４４ｂが第２の分配手段に該当し、ここで行う処理も、個別受信手順及び第２の分配手順の処理に該当する。
なお、管理装置コマンド転送ハンドラ４４ｂは、実際には画像形成装置１００に動作応答を生成させるのであるが、呼び出し及び動作応答の登録の方式は、上述した管理装置コマンドハンドラ４４ａの場合と全く同一である。そこで、他のモジュールから見た場合には、管理装置コマンド転送ハンドラ４４ｂが自身で動作応答を生成しているものと取り扱っても全く問題ない。そして、ここではこのように取り扱うものとする。
また、図示は省略したが、管理装置コマンドの宛先が、被管理仲介装置１１０や、被管理仲介装置１１０の通信相手となる画像形成装置１００であった場合には、コマンドを被管理仲介装置１１０に転送して必要な処理（画像形成装置１００への転送も含む）を実行させ、応答を取得することになる。

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

ＨＴＴＰリクエストに埋め込まれて引き渡されるＳＯＡＰエンベロープには、被管理側コマンドを記載したものと、管理装置コマンドに対する応答を記載したものと、管理装置コマンドに対する遅延通知を記載したものとがある。
また、このような機能を有する仲介装置１０１が管理装置１０２から受信するＨＴＴＰレスポンスの例を図１７に示す。

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

そして、以上のような形式のＨＴＴＰリクエストやＨＴＴＰレスポンスは、転送可能な１つのメッセージであり、各パートのＳＯＡＰエンベロープを、形式を変更せずに複数結合して生成することができる。また、このような形式のＨＴＴＰリクエストやＨＴＴＰレスポンスを分割して各パートのＳＯＡＰエンベロープを取り出せば、各ＳＯＡＰエンベロープ毎に個別に別のＨＴＴＰリクエストやＨＴＴＰレスポンスに記載して転送することができる。

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

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

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

またＳＯＡＰヘッダには、「要求ＩＤ」のＸＭＬタグの内容として、この被管理側コマンドのＩＤである「１２３４５」が記載されている。
さらに、「送信元」タグの内容として、このコマンドの送信元を示す情報である「仲介装置ＩＤ」及び「画像形成装置ＩＤ」の情報が記載されている。このうち、「画像形成装置ＩＤ」は、この画像機器コマンドを生成した画像形成装置のＩＤであり、「仲介装置ＩＤ」は、この画像機器コマンドが管理装置に転送される際に経由する仲介装置のＩＤである。これは、被管理側コマンドシートの「送信元情報」に記憶されていた情報である。

なお、この遠隔管理システムでは管理装置は１つしかないので、発信元の情報からこのＳＯＡＰメッセージが画像機器コマンドを記載したものであることが分かれば、宛先がその管理装置であることは自明であるため、ここでは宛先は特に記載していないが、記載するようにしてもよい。
また、ＳＯＡＰボディには、被管理側コマンドシートの「メソッド名」に記憶されていたメソッドを指定する情報として、「異常通知」タグが記載され、その下位のタグ「エラーＩＤ」や「説明」の要素として、「入力パラメータ」に記憶されていた引数が記載されている。ここでは異常通知の通知内容が記載されている。

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

さらに、「宛先」タグの内容として、このコマンド応答の宛先を示す情報である「仲介装置ＩＤ」及び「画像形成装置ＩＤ」の情報が記載されている。このうち、「画像形成装置ＩＤ」は、このコマンド応答の最終的な送信先となる画像形成装置のＩＤであり、「仲介装置ＩＤ」は、このコマンド応答が画像形成装置に転送される際に経由する仲介装置のＩＤである。

なお、この遠隔管理システムでは管理装置は１つしかないので、宛先の情報からこのＳＯＡＰメッセージが画像機器コマンドに対する応答を記載したものであることが分かれば、送信元がその管理装置であることは自明であるため、ここでは送信元は特に記載していないが、記載するようにしてもよい。
ＳＯＡＰボディには、「異常通知」コマンドに対する応答であることを示すための「異常通知Response」タグが設けられ、その下位のタグに、コマンド応答の内容が記載される。ここでは、異常通知を正常に受信した旨の情報が記載されている。そして、この情報が被管理側コマンドシートの「出力パラメータ」の項目に格納される。

図２０に示すのは、仲介装置コマンドを記載したパートの例である。
この例においても、図１８の場合と同様に、「X-SOAP-Type」ヘッダの値の「Request」により、このパートに記載されているＳＯＡＰエンベロープがＳＯＡＰリクエストであることを示し、「SOAPAction」ヘッダの情報により、ＳＯＡＰリクエストの内容を示している。

また、「Envelope」タグの属性として、名前空間の宣言を行っている点も、図１３の場合と同様である。
ＳＯＡＰヘッダには、「要求ＩＤ」のＸＭＬタグの内容として、この仲介装置コマンドのＩＤである「１２３４５」が記載されている。また、「送信元」タグの内容として、このコマンドの送信元を示す情報である「仲介装置ＩＤ」及び「画像形成装置ＩＤ」の情報が記載されているが、このコマンドは仲介装置が生成するものであるので、「仲介装置ＩＤ」要素の内容としてその仲介装置のＩＤが記載され、「画像形成装置ＩＤ」要素の内容は空である。

また、ＳＯＡＰボディには、被管理側コマンドシートの「メソッド名」に記憶されていたメソッドを指定する情報として、「異常通知」タグが記載され、その下位のタグ「エラーＩＤ」や「説明」の要素として、「入力パラメータ」に記憶されていた引数が記載されている。ここでは異常通知の通知内容が記載されている。

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

ＳＯＡＰボディには、「異常通知」コマンドに対する応答であることを示すための「異常通知Response」タグが設けられ、その下位のタグに、コマンド応答の内容が記載される。ここでは、異常通知を正常に受信した旨の情報が記載されている。そして、この情報が被管理側コマンドシートの「出力パラメータ」の項目に格納される。

図２２に示すのは、画像形成装置宛ての管理装置コマンドを記載したパートの例である。
この例においても、図１８の場合と同様に、「X-SOAP-Type」ヘッダの値の「Request」により、このパートに記載されているＳＯＡＰエンベロープがＳＯＡＰリクエストであることを示し、「SOAPAction」ヘッダの情報により、ＳＯＡＰリクエストの内容を示している。

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

さらに、「宛先」タグの内容として、このコマンド応答の宛先を示す情報である「仲介装置ＩＤ」及び「画像形成装置ＩＤ」の情報が記載されている。このうち、「画像形成装置ＩＤ」は、このコマンドに係る動作を実行させる画像形成装置のＩＤであり、「仲介装置ＩＤ」は、このコマンドがその画像形成装置に転送される際に経由する仲介装置のＩＤである。ここで、「画像形成装置ＩＤ」に複数の画像形成装置のＩＤを記載し、複数の画像形成装置を宛先として指定することもできる。
また、この遠隔管理システムでは管理装置は１つしかないので、宛先の情報からこのＳＯＡＰメッセージが管理装置コマンドであることが分かれば、送信元がその管理装置であることは自明であるため、ここでは送信元は特に記載していないが、記載するようにしてもよい。

そして、ＳＯＡＰボディには、管理装置コマンドシートの「メソッド名」に記憶されるべきメソッドを指定する情報として、「温度センサ値取得」タグが記載され、その下位のタグ「センサＩＤ」の要素として、「入力パラメータ」に記憶されるべき引数が記載されている。ここではセンサ値を取得するセンサのＩＤが記載されている。
なお、管理装置がこのようなコマンドを送信する場合としては、例えば、画像形成装置からの異常通知を受けて異常の原因を特定しようとする場合等が考えられる。

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

また、この例においても、名前空間の宣言は図２２に示した例と同様である。そして、ＳＯＡＰヘッダには、「コマンドＩＤ」のＸＭＬタグの内容として、応答を生成した管理装置コマンドのＩＤである「９８７６５」が記載されている。
さらに、「送信元」タグの内容として、このコマンド応答の送信元を示す情報である「仲介装置ＩＤ」及び「画像形成装置ＩＤ」の情報が記載されている。このうち、「画像形成装置ＩＤ」は、このコマンド応答を生成した画像形成装置のＩＤであり、「仲介装置ＩＤ」は、このコマンド応答が管理装置に転送される際に経由する仲介装置のＩＤである。宛先を記載していない点は、図１８等の場合と同様である。

また、ＳＯＡＰボディには、「温度センサ値取得」コマンドに対する応答であることを示すための「温度センサ値取得Response」タグが設けられ、その下位のタグに、コマンド応答の内容が記載される。ここでは、値取得を要求されたセンサの示す温度値の情報が記載されている。

図２４に示すのは、仲介装置宛ての管理装置コマンドを記載したパートの例である。
この例においても、図１８の場合と同様に、「X-SOAP-Type」ヘッダの値の「Request」により、このパートに記載されているＳＯＡＰエンベロープがＳＯＡＰリクエストであることを示し、「SOAPAction」ヘッダの情報により、ＳＯＡＰリクエストの内容を示している。
また、「Envelope」タグの属性として、名前空間の宣言を行っている点も、図１８の場合と同様である。そしてここでは、ＳＯＡＰで標準として定義されている名前空間の他に、「http://www.foo.com/header」及び「http://www.foo.com/agent」のＵＲＩで特定される名前空間の宣言を行っている。

ＳＯＡＰヘッダには、「要求ＩＤ」のＸＭＬタグの内容として、この管理装置コマンドのＩＤである「９８７６５」が記載されている。
さらに、「宛先」タグの内容として、このコマンド応答の宛先を示す情報である「仲介装置ＩＤ」及び「画像形成装置ＩＤ」の情報が記載されているが、このコマンドは仲介装置宛てであるので、「仲介装置ＩＤ」要素の内容としてその仲介装置のＩＤが記載され、「画像形成装置ＩＤ」要素の内容は空である。送信元を記載していない点は、図２２等の場合と同様である。

また、ＳＯＡＰボディには、管理装置コマンドシートの「メソッド名」に記憶されるべきメソッドを指定する情報として、「通信状況確認」タグが記載され、その下位のタグ「機器ＩＤ」の要素として、「入力パラメータ」に記憶されるべき引数が記載されている。ここでは、通信状況を確認すべき、仲介装置の通信相手機器のＩＤが記載されている。ここでは全ての機器を指定するＡＬＬを記載している。
なお、管理装置がこのようなコマンドを送信する場合としては、例えば、仲介装置からの異常通知を受けてシステムの状態を確認しようとする場合等が考えられる。

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

さらに、「送信元」タグの内容として、このコマンド応答の送信元を示す情報である「仲介装置ＩＤ」及び「画像形成装置ＩＤ」の情報が記載されているが、このコマンド応答は仲介装置が生成するものであるので、「仲介装置ＩＤ」要素の内容としてその仲介装置のＩＤが記載され、「画像形成装置ＩＤ」要素の内容は空である。送信元を記載していない点は、図１８等の場合と同様である。
また、ＳＯＡＰボディには、「通信状況確認」コマンドに対する応答であることを示すための「通信状況確認Response」タグが設けられ、その下位のタグに、コマンド応答の内容が記載される。ここでは、通信状況に異常がなかった旨の情報を記載している。

図２６に示すのは、仲介装置宛ての管理装置コマンドに対する遅延通知を記載したパートの例である。
この図に示すように、遅延通知は、ＳＯＡＰレスポンスとして取扱い、ＳＯＡＰヘッダについては、コマンドに対して応答を返す場合とほぼ同一の書式となっている。そして、応答を返す場合の書式に加えてＳＯＡＰヘッダ中に「遅延」タグを設けてこのＳＯＡＰメッセージが遅延通知に係るものであることを示すと共に、ＳＯＡＰボディは空にしている。なお、「遅延通知」要素の内容として、応答送信予定時刻等の情報を記載するようにしてもよい。

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

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

次に、管理装置コマンドに対する応答である管理装置コマンド実行結果の収集処理を行う（Ｓ１２）。この処理は、管理装置コマンドプールから管理装置１０２に送信すべきコマンド応答及び遅延通知を収集する処理であり、やはり収集したデータからＳＯＡＰエンベロープによるパートを生成する処理を含む。
その後、ステップＳ１１及びＳ１２の処理で生成したパートを１つにマージして、すべてのパートを含むＨＴＴＰリクエストを生成し（Ｓ１３）、そのＨＴＴＰリクエストを管理装置１０２に送信する（Ｓ１４）。
ここまでの処理において、ステップＳ１１及びＳ１２が収集手順の処理であり、ここではＣＰＵ５２は送信メッセージ収集手段４５として機能する。また、ステップＳ１３及びＳ１４が一括送信手順の処理であり、ここではＣＰＵ５２はＨＴＴＰリクエスト送信手段４７ａとして機能する。

次に、ＨＴＴＰリクエストに対する通信応答として管理装置１０２からＨＴＴＰレスポンスを受信する（Ｓ１５）。そして、受信したＨＴＴＰレスポンスのＨＴＴＰボディを各パートに分割する（Ｓ１６）。ここで、各パートへの分割は、「MIME_boundary」で区分された要素に分割することであり、またここで全てのパートに関して分割する。
そしてその後、分割して得た全てのパートを順に対象として、ステップＳ１７乃至Ｓ１９の処理を繰り返す。この処理においては、まず対象のパートが管理装置コマンドを記載したパートか否か判断する（Ｓ１７）。この判断は、対象のパートにSOAPActionヘッダが存在するか否か、あるいはX-SOAP-Typeヘッダの内容によって判断することができる。
そして、管理装置コマンドであれば管理装置コマンド登録処理を行う（Ｓ１８）。また、管理装置コマンドでないときは、被管理側コマンドに対する応答又は遅延通知が記載されたパートであるので、応答通知処理を行う（Ｓ１９）。

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

次に、図２７のフローチャートに示した処理について、一部分ずつより詳細に示したフローチャートを用いて説明する。
図２８及び図２９は、図２７のステップＳ１１乃至Ｓ１４の部分である送信側の処理をより詳細に示したフローチャートである。このうち、図２８にはステップＳ１１に相当する被管理側コマンド収集処理の部分を、図２９にはステップＳ１２乃至Ｓ１４に相当する管理装置コマンド収集処理からＨＴＴＰリクエスト送信処理の部分を示している。

この処理においては、仲介装置１０１のＣＰＵ５２はまず、被管理側コマンドプール４１から、「状態」が「未送信」である被管理側コマンドシートの「メソッド名」と「入力パラメータ」の内容を、送信すべき被管理側コマンドとして収集し、「コマンドＩＤ」の内容もそのコマンドのコマンドＩＤとして、また「送信元情報」の内容もそのコマンドの送信元の情報として収集する（Ｓ２１）。「未送信」という「状態」は、コマンドが被管理側コマンド生成手段４３によって生成された後、まだ管理装置１０２に送信されていないことを示すものであるので、これを基準に管理装置１０２に送信すべきコマンドを抽出できる。また、この時、画像機器コマンドと仲介装置コマンドとは区別せずに取り扱う。

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

これらが全て完了した後、処理は図２９のフローチャートに示す部分に進み、ＣＰＵ５２は、管理装置コマンドプール４２から、「状態」が「処理完了」又は「遅延未通知」である管理装置コマンドシートを、送信に係る処理を行う対象にすべきものとして抽出する（Ｓ２５）。「処理完了」という「状態」は、管理装置コマンドに対応する処理が管理装置コマンド実行結果生成手段４４によって生成された後、まだ管理装置１０２に通知されていないことを示すものであり、また、「遅延未通知」という「状態」は、管理装置コマンド対して遅延通知を行うべき旨が設定されていながらまだ遅延通知を行っていないことを示すものであるので、これらを基準に管理装置１０２に送信すべき内容を含むシートを抽出できる。

そしてステップＳ２５の後で、ここで抽出した全ての管理装置コマンドシートを順次対象として、ステップＳ２６乃至Ｓ３３の処理を繰り返す。
これらの処理においては、まず対象の管理装置コマンドシートの「状態」が「処理完了」であるか否か判断する（Ｓ２６）。そして、「処理完了」であれば、コマンド応答を管理装置１０２に送信するための処理を行うべくステップＳ２７以下に進み、まず対象の管理装置コマンドシートの「出力パラメータ」の内容を、そのシートに記載された管理装置コマンドに対するコマンド応答として収集し、「コマンドＩＤ」の内容も、対応する管理装置コマンドのコマンドＩＤとして収集して、また「宛先情報」の内容もそのコマンドの宛先すなわちコマンド応答の送信元の情報として収集する（Ｓ２７）。

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

一方、ステップＳ２６で「処理完了」でなければ、対象シートの「状態」は「遅延未通知」であるので、遅延通知を管理装置１０２に送信するための処理を行うべくステップＳ３１以下に進み、まず対象の管理装置コマンドシートに記載されている管理装置コマンドについてのＳＯＡＰエンベロープによる遅延通知を作成する（Ｓ３１）。なお、上述のように、遅延通知の書式はコマンド応答の場合とほぼ同様であるので、シートの「コマンドＩＤ」や「宛先情報」等を参照して作成することになる。そして、これにエンティティヘッダを付加して遅延通知に関するパートを生成し（Ｓ３２）、対象の管理装置コマンドシートの「状態」を「処理待ち」に変更する（Ｓ３３）。「処理待ち」という「状態」は、遅延通知を管理装置１０２に送信済であり、コマンドに関する処理の実行を待っている状態であることを示すものである。

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

図３０及び図３１は、受信側処理の一部である、図２７のステップＳ１８に示した管理装置コマンド登録処理をより詳細に示すフローチャートである。
この処理においては、ＣＰＵ５２は、図２７のステップＳ１７の処理で、対象のパートは管理装置コマンドを記載したパートであることがわかっているので、そのパートのＳＯＡＰエンベロープを解析して内容を参照できる形式のデータに変換し（Ｓ４１）、その管理装置コマンドを登録するための管理装置コマンドシートを管理装置コマンドプール４２に作成して（Ｓ４２）、管理装置コマンドとコマンドＩＤ及び宛先情報をその管理装置コマンドシートに登録する（Ｓ４３）。

ここで、管理装置コマンドの内容は管理装置コマンドシートの「メソッド名」及び「入力パラメータ」の項目に登録し、パートに記載されていたコマンドＩＤは「コマンドＩＤ」の項目に登録する。また、コマンドの宛先を示す情報は、「宛先情報」の項目に登録し、管理装置１０２の情報を「送信元情報」に登録する。なお、後者の情報については、この遠隔管理システムでは一意に定まるので、ＳＯＡＰエンベロープに記載していなくても必要な情報を参照して作製可能であるし、登録も必須ではない。また、「状態」の初期値は「未処理」であり、「出力パラメータ」の初期値はＮＵＬＬである。

そして、以上の項目への登録が終了すると、宛先情報を参照して、コマンドの宛先が仲介装置１０１すなわち自分自身であるか否か判断する（Ｓ４４）。そして、仲介装置１０１であれば、管理装置コマンドシートの「メソッド名」に記憶させたメソッドを実行させるためのハンドラ（管理装置コマンドハンドラ４４ａ）への参照情報を、予め用意してあるメソッドとハンドラとの対応関係の情報を参照して検索し（Ｓ４５）、発見した参照情報を管理装置コマンドシートの「コマンドの通知先」の項目に登録する（Ｓ４６）。

一方、ステップＳ４４で仲介装置１０１でなければ、コマンドを宛先に転送するためのハンドラ（管理装置コマンド転送ハンドラ４４ｂ）への参照情報を検索し（Ｓ４７）、発見した参照情報を同様に登録する（Ｓ４６）。
そして、ここまでの処理で、管理装置コマンドの管理装置コマンドプール４２への登録が完了し、続けて応答状況管理のための図３１に示す処理に進む。

この処理においては、まず所定時間内に管理装置コマンドに対する応答を生成できるか否か判断する（Ｓ５１）。この「生成」には、上述のように、画像形成装置等にコマンド転送して応答を取得することも含むが、この場合には、ある程度の時間を要するので、ステップＳ５１の判断は必ずＮＯにするものとする。
そして、ステップＳ５１で所定時間内に生成できると判断した場合には、ステップＳ５２以下の処理を行って直ちに管理装置コマンドに係る処理を実行する。すなわち、まず登録した管理装置コマンドについての管理装置コマンドシートの「コマンドの通知先」の情報に基づいて管理装置コマンドハンドラ４４ａを呼び出し、「メソッド名」や「入力パラメータ」のデータを渡して管理装置コマンドに係る処理を実行させる（Ｓ５２）。なお、管理装置コマンドに係る処理自体は、このフローチャートには示していないが、ハンドラを用いてＣＰＵ５２が別途実行することになる。

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

一方、ステップＳ５１で所定時間内に生成できないと判断した場合には、登録した管理装置コマンドについての管理装置コマンドシートの「状態」を「遅延未通知」に変更して遅延通知が必要であることを示す（Ｓ５５）。
そして、ステップＳ５４又はＳ５５が完了すると、管理装置コマンド登録処理を終了し、図２７に示す通り、次のパートを対象としてステップＳ１７の処理を行うか、次のパートがなければ処理を終了する。

次の図３２は、受信側処理の一部である、図２７のステップＳ１９に示した応答通知処理をより詳細に示すフローチャートである。
この処理においては、図２７のステップＳ１７の処理で、対象のパートが被管理側コマンドに対する応答又は遅延通知を記載したパートであることがわかっているので、まずそのパートのＳＯＡＰエンベロープを解析して内容を参照できる形式のデータに変換する（Ｓ６１）。

そして、そのデータ中の応答内容を参照し、そのパートがコマンド応答を記載したパートであるか否かを判断する（Ｓ６２）。遅延通知の場合には、応答内容としてこれが遅延通知である旨の情報が記憶されているので、このような情報がなければコマンド応答であると判断できる。
そして、コマンド応答であれば、被管理側コマンドプール４１からそのコマンド応答に対応する被管理側コマンドシート（コマンド応答と対応する被管理側コマンドを登録してあるシート）を探索し、その被管理側コマンドシートの「出力パラメータ」の項目にコマンド応答のデータを登録する（Ｓ６３）。なお、コマンド応答には、「コマンドＩＤ」の情報として、被管理側コマンドの送信時に付したものと同じコマンドＩＤが付してあるものとし、被管理側コマンドシートの探索は、この情報をキーとして行うことができる。

データの登録が終わると、データを登録した被管理側コマンドシートの「状態」を「応答受信済」に変更してその旨を示す（Ｓ６４）。そして、「コマンド実行結果の通知先」に登録されている通知先に、応答があった旨を通知する（Ｓ６５）。この通知によって、被管理側コマンドを生成したハンドラは、その生成したコマンドに応答があったことを認識し、応答に応じた処理を行うことができる。

例えば、異常通知を発する仲介装置コマンド生成ハンドラ４３ａが管理装置１０２に異常通知を行う旨の仲介装置コマンドを生成した場合、このコマンドが管理装置１０２に送信されると、管理装置１０２はこれを正しく受け取った旨のコマンド応答を返してくる。そして、仲介装置１０１側では、このコマンド応答を受信すると、ここに含まれるコマンドＩＤを基にどの被管理側コマンドに対する応答であるかを探索し、見つかった被管理側コマンドと対応させてそのコマンド応答を登録する。そして、そのコマンドの実行結果通知先として登録されている仲介装置コマンド生成ハンドラ４３ａに、応答があった旨を通知するのである。仲介装置コマンド生成ハンドラ４３ａは、この通知を受けた場合に被管理側コマンドシートを参照すれば、生成したコマンドの実行結果を「出力パラメータ」の項目から取得することができる。

なお、被管理側コマンドが画像機器コマンドである場合には、この通知を画像機器コマンド転送ハンドラ４３ｂが受け取り、被管理側コマンドシートから必要な情報を読み出して応答のＳＯＡＰレスポンスを生成し、ＨＴＴＰレスポンスに記載して、コマンドの送信元（応答の宛先）である画像形成装置１００に送信する。この場合の処理は、被管理側コマンドが仲介装置コマンドである場合と大きく異なるものであるが、図３２の処理においては、どちらも応答をハンドラに通知するという点で同じ処理であり、特に区別はない。

また、ステップＳ６２でコマンド応答でなかった場合には、対象のパートは遅延通知を記載したパートであるので、被管理側コマンドプール４１からその遅延通知に対応する被管理側コマンドシートを探索し、その被管理側コマンドシートの「状態」の項目を「応答遅延」に変更して遅延通知を受信したことを示す（Ｓ６６）。この場合にも、「コマンドＩＤ」の情報をキーとして探索を行うことができることは、ステップＳ６３の場合と同様である。

その後、「コマンド実行結果の通知先」に登録されている通知先に、遅延通知があった旨を通知する（Ｓ６７）。この通知によって、被管理側コマンドを生成したハンドラは、その生成したコマンドに遅延通知があったことを認識し、それに応じた処理を行うことができる。なお、被管理側コマンドが画像機器コマンドである場合の取扱いについては、ステップＳ６５の場合と概ね同様であるが、画像形成装置１００は遅延通知に対応していないため、画像形成装置１００に遅延を通知することはしない。
そして、ステップＳ６４又はＳ６５が完了すると、応答通知処理を終了し、図２７に示す通り、次のパートを対象としてステップＳ１７の処理を行うか、次のパートがなければ処理を終了する。

以上のようなメッセージの収集及び分配処理を行うことにより、仲介装置１０１が、画像形成装置１００及び仲介装置１０１自身からの管理装置１０２宛ての動作要求と、管理装置１０２からの画像形成装置１００及び仲介装置１０１自身宛ての動作要求に対する動作応答とを一括して管理装置１０２に送信することができる。また、管理装置１０２からの画像形成装置１００及び仲介装置１０１自身宛ての動作要求と、画像形成装置１００及び仲介装置１０１自身からの管理装置１０２宛ての動作要求に対する動作応答とを、一括して管理装置１０２から受信して処理することができる。

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

次に、遅延通知をした管理装置コマンドの実行に関する処理について説明する。
図３３は、この処理を示すフローチャートである。この処理においては、仲介装置１０１のＣＰＵ５２は、管理装置コマンド実行結果生成手段４４として機能する。
この処理は、図２７に示した管理装置１０２との間のメッセージの送受信に係る処理とは独立して、ＣＰＵ５２が仲介装置１０１の起動時に開始するものである。
そして、この処理においては、まず管理装置コマンドプール４２に「状態」が「処理待ち」である管理装置コマンドシートがあるか否か判断し（ＳＡ１）、なければこのような管理装置コマンドシートを発見するまで待機する。なお、上述のように、「処理待ち」という状態は、管理装置１０２に対して遅延通知を送信済でかつコマンドに係る処理は未実行あることを示すものである。

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

なお、ステップＳ５２の処理では、図３０のステップＳ４６の処理で管理装置コマンドシートの「コマンドの通知先」に登録した参照情報を用いてハンドラを呼び出すが、このハンドラは、管理装置コマンドが仲介装置１０１宛てである場合には管理装置コマンドハンドラ４４ａであり、画像形成装置１００又は被管理仲介装置１１０宛てである場合には管理装置コマンド転送ハンドラ４４ｂである。そして、前者の場合には仲介装置１０１の内部でコマンド応答を生成するのに対し、後者の場合には他の装置にコマンドを転送してコマンド応答を生成させるため、処理が大きく異なる。
しかし、図３３の処理においては、ハンドラを呼び出してコマンドに係る処理を実行させるという点で同じ処理であり、特に区別はない。

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

以上のような処理を行うようにすれば、任意のタイミングで管理装置コマンドを実行することができるので、実行に時間のかかるコマンドがあった場合でも、以後の処理が滞ることがない。そして、実行の終了したものから順に、その結果をコマンド応答として管理装置１０２に送信可能な状態にすることができる。
なお、図３１に示した処理において、ステップＳ５１乃至Ｓ５４の処理を行わず、全ての管理装置コマンドについて「状態」を「遅延未通知」にして一旦遅延通知を送信するようにし、その後図３３に示した処理によって管理装置コマンドに係る処理を実行するようにしてもよい。このようにすれば、処理を単純化できる。そして、このようにした場合、遅延通知は、全てのコマンドについて送信するのであるから、コマンドの受信通知のような意味合いを持つことになる。

次に、対象のコマンドが仲介装置１０１宛てでない場合の上記の図３３のステップＳ５２の処理、すなわち、管理装置コマンド転送ハンドラ４４ｂが実行する処理について、より詳細に説明する。図３４はこの処理を示すフローチャートである。なお、ステップＳ５２は図３１にも存在するが、対象のコマンドが仲介装置１０１宛てでない場合には、Ｓ５１の判断がＮＯになるので、こちらの処理が実行されることはない。
図３４に示す処理においては、まず対象の管理装置コマンドシートに登録されているコマンド（実行対象となる管理装置コマンド）が、仲介装置１０１の通信相手となる画像形成装置１００又は被管理仲介装置１１０宛てであるか否か判断する（Ｓ７１）。なお、この遠隔管理システムにおいては、各仲介装置の負荷が過大になることを防止するため、各装置に通信相手となる装置を定めており、同じＬＡＮに接続されていたとしても、その定めた装置以外とは通常は通信を行わないようにしている。

そして、ステップＳ７１の判断がＮＯであれば、実行対象となる管理装置コマンドは下位の被管理仲介装置１１０を介して宛先まで転送する必要があるので、対象のシートから、メソッド名、入力パラメータ、コマンドＩＤ、宛先情報等の必要な情報を読み出して管理装置コマンドを記載したＳＯＡＰメッセージに変換し（Ｓ７２）、そのＳＯＡＰメッセージをＨＴＴＰリクエストに記載して、ＨＴＴＰリクエスト送信手段４７ａを介して宛先装置への通信経路となる被管理仲介装置１１０に送信する（Ｓ７３）。そして、被管理仲介装置１１０はこれを受け取るとコマンドの宛先まで（必要ならさらに他の被管理仲介装置を介して）転送してコマンドを実行させ、応答を取得してこれを返してくるので、仲介装置１０１では、その応答を被管理仲介装置１１０から受信する（Ｓ７４）。
なお、各仲介装置には、遠隔管理システムを構成する装置のうち、少なくとも自身より下位に接続されている装置については接続関係の情報を保持しており、通信経路はこれを参照して定めることができるものとする。

また、ステップＳ７１の判断がＹＥＳであれば、ステップＳ７２の場合と同様にＳＯＡＰメッセージを生成し（Ｓ７５）、そのＳＯＡＰメッセージをＨＴＴＰリクエストに記載して、ＨＴＴＰリクエスト送信手段４７ａを介してコマンドの宛先である画像形成装置１００又は被管理仲介装置１１０に送信する（Ｓ７６）。そして、宛先の装置はこれを受け取るとコマンドに係る動作を実行し、応答を返してくるので、仲介装置１０１では、その応答を宛先の装置から受信する（Ｓ７７）。なお、画像形成装置１００には遅延通知を行う機能は設けていないので、所定時間内に応答を受信できない場合には、処理をタイムアウトさせるようにするとよい。
ステップＳ７４又はＳ７７の後は、図３３のステップＳ５３以降の処理に進む。
これらの処理が、個別送信手順及び個別受信手順の処理である。
以上で、仲介装置１０１において実行する、各コマンド及びコマンド応答の転送に関する処理の説明を終了する。

次に、管理装置１０２側においてコマンド及びコマンド応答を取り扱うための機能構成について説明する。ハードウェアについては、図８を用いて説明した通りである。
図３５は、管理装置１０２の機能のうち、コマンド及びコマンド応答に関する処理を行うための機能の構成を示す機能ブロック図である。
図３５に示す各機能は、制御装置１２６中のＣＰＵが所要の制御プログラムを実行して管理装置１０２の各部の動作を制御することにより実現されるものである。そして、これらの機能のうち、管理装置コマンドプール１４１及び被管理側コマンドプール１４２は、制御装置１２６中の書き換え可能な記憶手段に設けられるものである。管理装置コマンド生成手段１４３、被管理側コマンド実行結果生成手段１４４、送信メッセージ収集手段１４５、受信メッセージ分配手段１４８の機能は、制御装置１２６中のＣＰＵによって実現されるものである。また、ＨＴＴＰサーバ機能部１４６の機能は、制御装置１２６中のＣＰＵ及び通信Ｉ／Ｆによって実現されるものである。

図３５に示した各手段の機能についてさらに詳述する。
まず、管理装置コマンドプール１４１は、管理装置１０２に設けた第２の記憶領域に該当し、管理装置コマンドを、このコマンドに対する応答や、このコマンドの識別情報及びコマンドの宛先や送信元の情報等と関連付けて登録するプールである。また、被管理側コマンドプール１４２は、管理装置１０２に設けた第１の記憶領域に該当し、被管理側コマンドを、このコマンドに対する応答や、このコマンドの識別情報及びコマンドの宛先や送信元の情報等と関連付けて登録するプールである。また、これらのプールを設けた記憶手段がそれぞれ管理装置１０２の第２，第１の記憶手段に該当するものとする。

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

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

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

次に、送信メッセージ収集手段１４５は、収集手段に該当する。そして、被管理側コマンド実行結果生成手段１４４が生成したコマンド応答とこのコマンド応答に対応する被管理側コマンドのコマンドＩＤ及び送信元情報とを関連付けて被管理側コマンドプール１４２から読み出すと共に、管理装置コマンド生成手段１４３が生成した管理装置コマンドとこのコマンドのコマンドＩＤ及び宛先情報とを関連付けて管理装置コマンドプール１４１から読み出し、これらから送信メッセージを生成する機能を有する。さらに、遅延通知が必要な被管理側コマンドについて、そのコマンドＩＤ及び宛先情報を関連付けて被管理側コマンドプール１４２から読み出し、遅延通知の送信メッセージを生成する機能も有する。
送信メッセージの形式については、図１８乃至図２６を用いて説明した通りである。

また、ＨＴＴＰサーバ機能部１４６に設けたＨＴＴＰレスポンス送信手段１４６ａは、送信手段に該当し、送信メッセージ収集手段１４５が生成した送信メッセージを含むＨＴＴＰレスポンスを、仲介装置１０１から受信したＨＴＴＰリクエストに対する通信応答として生成し、仲介装置１０１に送信する機能を有する。このとき、１つのＨＴＴＰレスポンスに送信メッセージをいくつ含めてもよいし、コマンド応答に係る送信メッセージと管理装置コマンドに係る送信メッセージと遅延通知に係る送信メッセージとを任意に混在させることもできる。もちろん、宛先の異なる送信メッセージを混在させることもできる。
そこで、ＨＴＴＰレスポンス送信手段１４６ａは、これらのいずれに係る送信メッセージかに関わり無く、送信メッセージ収集手段１４５が生成した全ての送信メッセージを１つのＨＴＴＰレスポンスに含めて送信するようにしている。ただし、１つのＨＴＴＰレスポンスに含める送信メッセージの数に上限を設けることも考えられる。

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

また、ＨＴＴＰリクエスト受信手段１４６ｂは、受信手段に該当し、仲介装置１０１からのＨＴＴＰリクエストを受信する機能を有する。そしてここでは、ＨＴＴＰリクエストには、被管理側コマンド及びそのコマンドと関連付けられたコマンドＩＤと送信元情報を含む受信メッセージと、管理装置コマンドに対する応答及びそのコマンドと関連付けられたコマンドＩＤと宛先情報を含む受信メッセージと、管理装置コマンドに対する遅延通知及びそのコマンドと関連付けられたコマンドＩＤと宛先情報を含む受信メッセージとが、任意に混在して含まれている。
ここで、受信メッセージとは、上記のコマンドや応答あるいは遅延通知と、コマンドＩＤ及び送信元情報等とをＳＯＡＰメッセージとして記載したものである。

受信メッセージ分配手段１４８は、分配手段に該当する。そして、ＨＴＴＰリクエスト受信手段１４６ｂが受信したＨＴＴＰリクエストに含まれるデータを、管理装置コマンドプール１４１及び被管理側コマンドプール１４２に振り分けて登録する機能を有する。
具体的には、被管理側コマンド及びそのコマンドと関連付けられたコマンドＩＤ及び送信元情報とを被管理側コマンドプール１４２に被管理側コマンドシートを設けて登録すると共に、管理装置コマンドに対する応答については、その応答と関連付けられたコマンドＩＤを管理装置コマンドプール１４１に記憶している管理装置コマンドシートのコマンドＩＤと照合して対応する管理装置コマンドシートを特定し、その管理装置コマンドシートの「出力パラメータ」の項目に登録する。管理装置コマンドに対する遅延通知については、やはりコマンドＩＤをもとに管理装置コマンドシートを特定し、そのコマンドシートの「状態」を「応答遅延」に変更して応答の受信が遅延することを示す。

そしてこのとき、ＨＴＴＰリクエストを分割してそこに含まれる各受信メッセージを取り出し、そのデータをテーブルへの登録に必要な形式に変換するが、この変換は、ＷＳＤＬに基づいて生成される所要の変換プログラム（デシリアライザ）を実行することによって行うことができる。
このような機能を有する管理装置１０２が受信するＨＴＴＰリクエストは、仲介装置１０１から送信されてくるものであるので、例えば仲介装置１０１の機能の説明中で図１６を用いて説明したものである。管理装置１０２が送信するＨＴＴＰレスポンスも、仲介装置１０１に対して送信し、仲介装置１０１が受信するものであるので、例えば図１７を用いて説明したものである。これらに含まれるパートの内容も、図１８乃至図２６を用いて説明したようなものとなる。

次に、以上説明したような構成及び機能を有する管理装置１０２において実行する処理について説明する。
図３６にメッセージの収集及び分配処理の基本動作のフローチャートを示すが、このフローチャートに示す処理は、管理装置１０２における制御装置１２６中のＣＰＵが所要の制御プログラムを実行することによって行うものである。

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

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

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

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

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

これらの処理の詳細については、仲介装置１０１側の説明において図２８乃至図３２を用いて説明した処理と同様であるので、詳細な説明は省略する。ただし、被管理側コマンドと管理装置コマンドの位置付けが逆になった点及び、ＨＴＴＰリクエストを受信してＨＴＴＰレスポンスを送信することから受信用のステップＳ３１１乃至Ｓ３１５の処理を送信用のステップＳ３１６乃至Ｓ３１９の処理よりも先に行う点は仲介装置１０１の場合と異なる。また、図示は省略したが、管理装置１０２側では、遅延通知をした被管理側コマンドの実行処理として、図３３に示した処理と対応する処理も行っている。

なお、管理装置１０２は、受信したコマンドやコマンド応答をさらに他の装置に転送することはしないため、ステップＳ３１４の被管理側コマンド登録処理は、仲介装置１０１側の対応する処理である管理装置コマンド登録処理（図３０及び図３１に詳細を示した）とはこの点で異なる。そこで、図３７を用いて、この相違点について説明を補足する。図３７は、管理装置１０２における被管理側コマンド登録処理（Ｓ３１４）をより詳細に示すフローチャートである。この図から分かるように、この処理は、基本的には図３０及び図３１に示した処理と対応するものであり、扱うコマンドが管理装置コマンドではなく被管理側コマンドである点で異なるものであるが、図３０のステップＳ４４及びＳ４７に対応する処理を設けていない点が異なるものである。
以上で、管理装置１０２において実行する、各コマンド及びコマンド応答の取扱いに関する処理の説明を終了する。

次に、画像形成装置１００側においてコマンド及びコマンド応答を取り扱うための機能構成について説明する。ハードウェアについては、図９を用いて説明した通りである。
図３８及び図３９は、画像形成装置１００の機能のうち、コマンド及びコマンド応答に関する処理を行うための機能の構成を示す機能ブロック図である。これらの図において、図３８には管理装置コマンドを取り扱う場合のデータの流れを示す矢印を記載し、図３９には画像機器コマンドを取り扱う場合のデータの流れを示す矢印を記載している。
これらの図に示す各機能は、ＣＰＵ２０１が所要の制御プログラムを実行して画像形成装置１００の各部の動作を制御することにより実現されるものである。そして、これらの機能のうち、管理装置コマンド実行結果生成手段２４３及び画像機器コマンド生成手段２４４の機能は、ＣＰＵ２０１によって実現されるものである。また、ＨＴＴＰサーバ機能部２４６及びＨＴＴＰクライアント機能部２４７の機能は、ＣＰＵ２０１及びＰＨＹ２０６によって実現されるものである。

これらの各手段の機能についてさらに詳述する。
まず、管理装置コマンド実行結果生成手段２４３は、応答生成手段に該当する。そして、ＨＴＴＰリクエスト受信手段２４６ｂを介して受信した管理装置コマンドに係る動作を実行し、実行結果として動作応答を生成し、これをＨＴＴＰレスポンス送信手段２４６ａを介して送信する機能を有する。すなわち、ウェブサービスを提供する機能を有する。
なお、この遠隔管理システムにおいては、管理装置コマンドは、仲介装置１０１からＨＴＴＰリクエストに記載された状態でＳＯＡＰリクエストとして送信されてくるので、管理装置コマンド実行結果生成手段２４３が生成した動作応答は、このＨＴＴＰリクエストに対するＨＴＴＰレスポンスにＳＯＡＰレスポンスとして記載して仲介装置１０１に返すことになる。この場合において、ＨＴＴＰリクエスト受信手段２４６ｂが受信手段として、ＨＴＴＰレスポンス送信手段２４６ａが送信手段としてそれぞれ機能する。

一方、画像機器コマンド生成手段２４４は、要求生成手段に該当する。そして、画像機器コマンドを生成し、このコマンドを識別する識別情報（ＩＤ）を割り当て、さらにこのコマンドの宛先情報を付して、これらの情報を記載した画像機器コマンドに係るＳＯＡＰリクエストを生成する機能を有する。このＳＯＡＰリクエストの形式は、例えば図１８に示したようなものである。
そして、ＨＴＴＰリクエスト送信手段２４７ａが送信手段に該当し、画像機器コマンド生成手段２４４が生成したＳＯＡＰリクエストをＨＴＴＰリクエストに記載して仲介装置１０１に送信する機能を有する。

また、仲介装置１０１が管理装置１０２から画像機器コマンドに対する応答を受信すると、この応答に係るＳＯＡＰレスポンスを、画像機器コマンドを記載したＨＴＴＰリクエストに対するＨＴＴＰレスポンスに記載して画像形成装置１００に送信してくるが、ＨＴＴＰレスポンス受信手段２４７ｂはこれを受信する機能を有し、受信手段に該当する。そして、画像機器コマンド生成手段２４４は、ＨＴＴＰレスポンス受信手段２４７ｂからこのＳＯＡＰレスポンスを受け取り、そこに記載された応答に応じた処理を行う機能も有する。

以上のように、画像形成装置１００は、画像機器コマンドを生成すると共にこのコマンドに対する応答を受信する機能を有し、また、管理装置コマンドを受信し、これに対するコマンド応答を生成して送信する機能を有する。しかし、仲介装置１０１や管理装置１０２の場合のように、コマンドプールや収集手段、分配手段は設けていないため、コマンドやコマンド応答の送受信は、１つずつ行うことになる。即ち、１つのＨＴＴＰリクエスト又はＨＴＴＰレスポンスに、１つのコマンド又はコマンド応答を記載して送受信することになる。
また、図示は省略したが、画像形成装置１００で仲介装置１０１宛ての動作要求が発生した場合あるいは逆に仲介装置１０１で画像形成装置１００宛ての動作要求が発生した場合にも、コマンドプールや収集手段、分配手段は使用しない。そして、要求が発生した側で要求を１つのＨＴＴＰリクエストに記載して相手に送信し、要求を受ける側では要求の受信時に要求に係る動作を実行して動作結果をＨＴＴＰレスポンスに記載して返信する処理を行う。

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

そして、以上の説明からわかるように、この遠隔管理システムにおいては、仲介装置１０１を設け、画像形成装置１００と管理装置１０２との間の通信を、この仲介装置１０１を介して行うようにしたことにより、管理装置１０２から複数の画像形成装置１００に宛てた動作要求を送信する場合でも、仲介装置１０１までは一括して送信でき、また複数の画像形成装置１００に宛てた動作要求に対する動作応答も仲介装置１０１から一括して受信できるので、動作要求の送信と動作応答の送信とについて別々にネゴシエーションを行って通信のコネクションを確立する必要がなく、通信のオーバーヘッドを低減して通信効率を高めることができる。

管理装置１０２が仲介装置１０１宛ての動作要求を送信したり、仲介装置１０１や画像形成装置１００から管理装置１０２宛ての動作要求を送信したりして、各々動作応答を受信する場合でも、管理装置１０２と仲介装置１０１の間の転送を一括して行うことができるので、高い通信効率を維持することができる。画像形成装置１００の数が多くなり、また管理装置１０２と画像形成装置１００や仲介装置１０１との間で転送すべき動作要求や動作応答が多くなればなるほど、この効果は大きくなる。
また、画像形成装置１００と仲介装置１０１との間では、上記のような一括転送は行わず、動作要求や動作応答を個別に転送するようにしているので、一括転送に対応していないシンプルな機能の画像形成装置１００でも、仲介装置１０１に通信を仲介させることにより、特に機能の拡張を行うことなく、管理装置１０２と通信を行う場合の通信効率を向上させることができる。そして、このようにしたとしても、画像形成装置１００と仲介装置１０１とは通常はＬＡＮのような通信相手が限定されたネットワークを介して通信を行うため、ネゴシエーションの処理負荷は小さくて済むので、通信の回数が増えてもさほど通信効率は低下しない。さらに、画像形成装置１００を複雑な通信プロトコルに対応させる必要がないので、全体としてシステムを構成するための手間やコストを抑えることができる。

また、動作要求と動作応答とを一括して送信できるのは、これらをそれぞれ直列化したデータに変換し、構造化言語形式で記載した送信メッセージに変換しているためである。このようにしたことにより、フォーマットの異なる動作要求と動作応答とを容易に結合し、論理的に１つの送信内容として送信することができるのである。
そして、このようにしたことにより、仲介装置１０１や管理装置１０２が、一括して受信した動作要求と動作応答とを、容易に個々のメッセージに分離し、それが動作要求であるか動作応答であるか、またその宛先に応じて、適切な処理を行うことができる。
また、動作要求及び動作応答をそれぞれ、形式を変更せずに複数結合して転送可能な１つのメッセージを生成することができる形式で表現し、また複数結合された状態では形式を変更せずに分割して転送可能な個々の動作要求及び動作応答に戻すことができる形式となるようにすれば、動作要求や動作応答の結合や分割を行う際の処理負荷を低減することができる。

さらに、管理装置１０２と仲介装置１０１との間の通信について、通信要求を常に仲介装置１０１から発して通信を行い、その管理装置１０２から仲介装置１０１への動作要求等の送信は、その通信要求に対する応答として行うようにすれば、仲介装置１０１がファイアウォールの内側に設けられている場合であっても、ファイアウォールの存在を意識せずに動作要求及び動作応答の送受信を行うことができる。また、通信要求と通信応答とが対応しているため、通信のレベルでのタイミング管理が容易である。
この場合において、上記の仲介装置１０１から管理装置１０２に定期的に通信要求を送信するようにすれば、管理装置１０２から仲介装置１０１や画像形成装置１００に向けての情報の送信が長時間に亘って停滞してしまう事態を防止できる。

また、画像形成装置１００と仲介装置１０１との間では、どちらから通信要求を発しても通信を行うことができるようにしているので、ファイアウォール越しに通信するためのプロトコルに対応していないシンプルな機能の画像形成装置１００であっても、仲介装置１０１に通信を仲介させることにより、特に機能の拡張を行うことなく管理装置１０２と動作要求及び動作応答の送受信を行うことができるようになる。そして、画像形成装置１００と仲介装置１０１との間には通常はファイアウォールは設けないので、このような構成にした方が、動作要求や動作応答の転送を適切なタイミングで行うことができる。
また、画像形成装置１００をファイアウォール越しに通信するためのプロトコルに対応させたとしても、情報送信の停滞を防止するためには上記のような定期的な通信要求を個々に行うことになるため、管理装置１０２に多数の通信要求が殺到することになり、通信のオーバーヘッドの面でも、管理装置１０２の処理負荷の面でも好ましくないので、仲介装置１０１を設けて仲介装置１０１に代表で定期的な通信要求を行わせることが好ましい。

また、仲介装置１０１において被管理側コマンドプールや管理装置コマンドプールを設け、各アプリケーション等が生成したり、管理装置１０２あるいは画像形成装置１００から受信したりした動作要求や動作応答を、これらのプールに蓄積しておくようにすることにより、動作要求や動作応答の生成及び送受信を、その転送先に対する送信タイミングを考慮せずに行うことができる。従って、処理のタイミング管理を簡略化することができ、設計や開発が容易になる。管理装置１０２においても、これらのプールを設けることにより、同様に動作要求や動作応答の生成のタイミング管理を簡略化することができ、設計や開発が容易になる。

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

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

〔第１の実施例の変形例：図４２〕
次に、上述した第１の実施例の変形例について説明する。この変形例は、仲介装置１０１が実行する管理装置コマンド登録処理の一部が第１の実施例の遠隔管理システムと異なるのみである。従って、これ以外の点は説明を省略する。図４２は、この変形例における管理装置コマンド登録処理の一部を示すフローチャートである。
この変形例では、仲介装置１０１は、図２７のステップＳ１８の管理装置コマンド登録処理において、第１の実施例で図３０を用いて説明した処理に代えて、図４２に示す処理を行う。すなわち、まず図２７のステップＳ１７乃至Ｓ１９のループで処理対象となっているパートのＳＯＡＰエンベロープを、ＳＯＡＰヘッダのみ解析して内容を参照できる形式のデータに変換すると共に（Ｓ８１）、その管理装置コマンドを登録するための管理装置コマンドシートを管理装置コマンドプール４２に作成する（Ｓ８２）。その後、ＳＯＡＰヘッダに記載されていた宛先情報を参照して、対象パートに記載されている管理装置コマンドの宛先が仲介装置１０１自身であるか否か判断する。（Ｓ８３）。

そして、コマンドが仲介装置１０１宛てであれば、対象パートのＳＯＡＰボディも解析して内容を参照できる形式のデータに変換し（Ｓ８４）、ステップＳ８２で作成した管理装置コマンドシートに管理装置コマンドとコマンドＩＤ及び宛先情報を登録する（Ｓ８５）。各項目への登録内容については、第１の実施例の場合と同様である。そして、各項目への登録が終了すると、仲介装置１０１が管理装置コマンドシートの「メソッド名」に記憶させたメソッドを実行するためのハンドラ（管理装置コマンドハンドラ４４ａ）への参照情報を、予め用意してあるメソッドとハンドラとの対応関係の情報を参照して検索し（Ｓ８６）、発見した参照情報を管理装置コマンドシートの「コマンドの通知先」の項目に登録する（Ｓ８７）。

一方、ステップＳ８３で仲介装置１０１でなければ、対象パートのＳＯＡＰエンベロープを、作成した管理装置コマンドシートの「入力パラメータ」の項目にＸＭＬのまま登録すると共に（Ｓ８８）、ＳＯＡＰヘッダに記載されていたコマンドＩＤ及び宛先情報については、ステップＳ８１での変換後のデータを管理装置コマンドシートに登録する（Ｓ８９）。そして、コマンドを宛先に転送するためのハンドラ（管理装置コマンド転送ハンドラ４４ｂ）への参照情報を検索し（Ｓ９０）、発見した参照情報を登録する（Ｓ８７）。
ステップＳ８７より後の処理は、第１の実施例の場合と同様である。

この変形例においては、以上のように、仲介装置１０１自身以外が宛先であり、宛先まで転送する必要があるコマンドについては、ＳＯＡＰボディを解析せず、ＳＯＡＰエンベロープ全体をＸＭＬのままコマンドシートに登録するようにしている。従って、この変形例では、管理装置コマンドを宛先に転送する処理を行う際に、管理装置コマンドシートの「入力パラメータ」の項目から読み出したデータをそのまま転送すればよいことになる。

第１の実施例では、コマンドを転送する際に、コマンドシートから読み出したデータからＳＯＡＰメッセージを生成する必要があったが、この変形例ではこの処理が不要であり、処理負荷を低減することができる。また、コマンドをコマンドシートに登録する際にもＳＯＡＰボディー部分のデータ形式を変換する必要がないので、この点でも処理負荷を低減することができる。ただし、コマンドの宛先が仲介装置１０１自身である場合には、コマンドを実行するためにデータを管理装置コマンドハンドラ４４ａが内容を参照できる形式とする必要があることから、データ形式を変換してからコマンドシートに登録するようにしている。
なお、管理装置コマンドの宛先から仲介装置１０１が受け取るコマンド応答を「出力パラメータ」の項目に登録する際にも、応答に係るＳＯＡＰエンベロープをＸＭＬのまま登録するようにしてもよい。このようにすれば、コマンド応答を管理装置１０２に転送する際の処理負荷も低減することができる。

〔第２の実施例：図４３乃至図４５〕
次に、図１に示した通信システムの第２の実施例である遠隔管理システムについて説明する。この遠隔管理システムの特徴は、管理装置１０２が、複数の装置を宛先とした管理装置コマンドを１つのＳＯＡＰリクエストとして送信できる点及び、このような管理装置コマンドに対する応答を、各宛先からの動作応答が揃った後で仲介装置１０１から管理装置１０２に送信する点である。そして、このような特徴を実現するため、主に仲介装置１０１における処理が第１の実施例の場合と異なる。そして、ハードウェア構成及び、管理装置１０２や画像形成装置１００が実行する処理については、第１の実施例の場合とほぼ同様であるから、これらについての説明は省略するか簡単にする。

この遠隔管理システムにおいては、まず、仲介装置１０１における管理装置コマンドシートの形式が第１の実施例の場合と異なる。図４３は、この実施例の仲介装置１０１における管理装置コマンドシートにおけるデータ構造の例を示す。
この図に示すように、この遠隔管理システムでも、管理装置コマンドシートに登録するデータの項目は第１の実施例の場合と同じである。しかし、「宛先情報」の項目を複数登録可能とし、また、「出力パラメータ」及び「コマンドの通知先」の項目も、各「宛先情報」と対応させて複数登録可能としている。

従って、複数の装置を宛先とした管理装置コマンドを、１つの管理装置コマンドシートに登録することができる。また、各宛先に転送又は仲介装置１０１自身で実行するためのハンドラへの参照を宛先毎に検索して登録することができる。さらに、各装置がコマンドに係る動作を実行して生成する動作応答も、宛先毎に登録することができる。そして、「コマンドＩＤ」や「送信元情報」といった、各宛先に共通の情報については、１つだけ記憶させるようにし、データ量を小さくしている。
また、ここでは、動作応答の管理装置１０２への送信は、全ての宛先から動作応答を取得した後で一括して行うようにしているので、「状態」の項目についても、１つの管理装置コマンドシート全体で１つだけ設けている。

なお、複数の装置を宛先とした管理装置コマンドは、管理装置１０２が同じ内容の動作要求を同時に複数の装置に対して送信しようとしたときに作成するものである。そして、転送時のＳＯＡＰメッセージの形式としては、例えば、図２２に示した形式において、宛先のリスト中に複数の画像形成装置１００のＩＤを記載したものが考えられる。

次に、この遠隔管理システムにおいて仲介装置１０１が実行する処理について説明する。
この遠隔管理システムにおいても、仲介装置１０１が実行するメッセージの収集及び分配処理の基本動作は、第１の実施例で図２７を用いて説明したものと同様なものである。しかし、複数の装置を宛先とした管理装置コマンドを処理できるようにするため、各処理の詳細は、第１の実施例の場合と異なる箇所もある。

まず、ステップＳ１８の管理装置コマンド登録処理は、図４４及び図４５のフローチャートに示す処理となる。
この処理においては、まず、図２７のステップＳ１７乃至Ｓ１９のループで処理対象となっているパートのＳＯＡＰエンベロープを、ＳＯＡＰヘッダのみ解析して内容を参照できる形式のデータに変換し（Ｓ１０１）、その管理装置コマンドを登録するための管理装置コマンドシートを管理装置コマンドプール４２に作成する（Ｓ１０２）。このとき、「宛先情報」及びこれに対応する項目は、管理装置コマンドに含まれる宛先の数だけ設ける。その後、ＳＯＡＰヘッダに記載されていた宛先情報を参照して、対象パートに記載されている管理装置コマンドの宛先に仲介装置１０１自身が含まれているか否か判断する（Ｓ１０３）。

そして、コマンドの宛先に仲介装置１０１が含まれていれば、対象パートのＳＯＡＰボディも解析して内容を参照できる形式のデータに変換し（Ｓ１０４）、ステップＳ１０２で作成した管理装置コマンドシートに管理装置コマンドとコマンドＩＤ及び宛先情報を登録する（Ｓ１０５）。各項目への登録内容については、第１の実施例の場合と同様である。そして、各項目への登録が終了すると、仲介装置１０１が管理装置コマンドシートの「メソッド名」に記憶させたメソッドを実行するためのハンドラ（管理装置コマンドハンドラ４４ａ）への参照情報を、予め用意してあるメソッドとハンドラとの対応関係の情報を参照して検索し（Ｓ１０６）、発見した参照情報を、管理装置コマンドシートのうち仲介装置の宛先情報と対応する「コマンドの通知先」の項目に登録する（Ｓ１０７）。
そして、処理中の管理装置コマンドの宛先に仲介装置１０１自身以外も含まれているか否か判断し（Ｓ１０８）、含まれていなければ図４５に示す処理に進む。含まれていれば、ステップＳ１１１に進む。

一方、ステップＳ８３で宛先に仲介装置１０１が含まれていなければ、上述した第１の実施例の変形例の場合のように、対象パートのＳＯＡＰエンベロープを、作成した管理装置コマンドシートの「入力パラメータ」の項目にＸＭＬのまま登録すると共に（Ｓ１０９）、ＳＯＡＰヘッダに記載されていたコマンドＩＤ及び宛先情報については、ステップＳ８１での変換後のデータを管理装置コマンドシートに登録する（Ｓ１１０）。

そして、コマンドを各宛先に転送するためのハンドラ（管理装置コマンド転送ハンドラ４４ｂ）への参照情報を検索し（Ｓ１１１）、発見した参照情報を、管理装置コマンドシートのうち画像形成装置１００又は被管理仲介装置１１０の宛先情報と対応する「コマンドの通知先」の項目に登録して（Ｓ１１２）、図４５に示す処理に進む。
ここで、宛先毎に異なる管理装置コマンド転送ハンドラ４４ｂを用いることが考えられる場合には、参照情報の検索及び登録は、宛先毎に行うものとする。また、コマンドを内容を参照できるデータ形式に変換して管理装置コマンドシートに登録した場合と、ＸＭＬのまま登録した場合とで、転送のための管理装置コマンド転送ハンドラ４４ｂは異なる場合もある。
以上のような処理で、複数の装置を宛先とした管理装置コマンドを、管理装置コマンドプール４２の１つの管理装置コマンドシートに登録することができる。

次の図４５に示す処理においては、まず所定時間内に管理装置コマンドに対する応答を全ての宛先について生成できるか否か判断する（Ｓ１２１）。なお、第１の実施例の場合と同様、画像形成装置等にコマンドを転送して応答を取得する必要がある場合には、ここでの判断は必ずＮＯにするものとする。
そして、ステップＳ１２１で所定時間内に生成できると判断した場合には、ステップＳ１２２以下の処理を行って直ちに管理装置コマンドに係る処理を実行する。すなわち、まず登録した管理装置コマンドに含まれる各「宛先情報」を順次対象として、ステップＳ１２２及びＳ１２３の処理を繰り返す。
この部分の処理は、対象の「宛先情報」と対応する「コマンドの通知先」の情報に基づいてハンドラを呼び出し、「メソッド名」や「入力パラメータ」や「宛先情報」のデータを渡して管理装置コマンドに係る処理を実行させると共に（Ｓ１２２）、その実行結果を取得して対象の「宛先情報」と対応する「出力パラメータ」の項目に登録する（Ｓ１２３）処理である。

そして、全ての「宛先情報」を対象についてこれらの処理が終了すると、管理装置コマンドシートの「状態」を「処理完了」に変更し、全ての宛先について処理が完了したことを示す（Ｓ１２４）。以上の処理を行うことにより、全ての宛先について管理装置コマンドを実行し、その結果をコマンド応答として管理装置１０２に送信可能な状態にすることができる。

一方、ステップＳ１２１で全ての宛先については所定時間内に生成できないと判断した場合には、登録した管理装置コマンドについての管理装置コマンドシートの「状態」を「遅延未通知」に変更して遅延通知が必要であることを示す（Ｓ１２５）。
そして、ステップＳ１２４又はＳ１２５が完了すると、管理装置コマンド登録処理を終了する。以上がこの遠隔管理システムにおいて仲介装置１０１が実行する管理装置コマンド登録処理である。
なお、以上の処理において、第１の実施例の場合と同様に、ＳＯＡＰエンベロープを初めから全て解析し、管理装置コマンドを、内容を参照できる形式のデータとして管理装置コマンドシートに登録するようにしてもよい。

また、図２７のステップＳ１２乃至Ｓ１４に相当する管理装置コマンド実行結果収集処理からＨＴＴＰリクエスト送信処理までの処理は、図４６に示すものになる。
この処理においてはまず、管理装置コマンドプール４２から、「状態」が「処理完了」又は「遅延未通知」である管理装置コマンドシートを、送信に係る処理を行う対象にすべきものとして抽出する（Ｓ１３１）。そして、ステップＳ１３１の後で、ここで抽出した全ての管理装置コマンドシートを順次対象として、ステップＳ１３２乃至Ｓ１３９の処理を繰り返す。

この部分の処理においては、まず対象の管理装置コマンドシートの「状態」が「処理完了」であるか否か判断する（Ｓ１３２）。
そして、「処理完了」であれば、コマンド応答を管理装置１０２に送信するための処理を行うべくステップＳ１３３以下に進み、まず対象の管理装置コマンドシートの全ての「宛先情報」を順次対象としてステップＳ１３３乃至Ｓ１３５の処理を行う。この部分の処理では、まず対象の管理装置コマンドシートの、対象の「宛先情報」と対応する「出力パラメータ」の内容を、そのシートに記載された管理装置コマンドに対する対象の宛先からのコマンド応答として収集し、また「コマンドＩＤ」の内容を、対応する管理装置コマンドのコマンドＩＤとして収集する（Ｓ１３３）。なお、対象の「宛先情報」の内容自体もコマンド応答の送信元の情報として収集する。

その後、ステップＳ１３３で収集したコマンド応答と、その応答と共に収集したコマンドＩＤ及び送信元の情報とを、これらの情報がそれぞれＳＯＡＰボディとＳＯＡＰヘッダとに含まれるＸＭＬ文書（ＳＯＡＰエンベロープ）に変換し（Ｓ１３４）、これにエンティティヘッダを付加して、対象のシートに記載された管理装置コマンドに対する対象の宛先からのコマンド応答に関するパートを生成する（Ｓ１３５）。そして、全ての「宛先情報」についてこれらの処理を行った時点で、対象の管理装置コマンドシートの「状態」を「応答済」に変更する（Ｓ１３６）。
この部分の記載からわかるように、１パートで複数の装置を宛先とした管理装置コマンドを受信した場合でも、そのコマンドに対する応答は、宛先毎に別々のパートに記載して送信する。これは、コマンドが各宛先に対して同じ内容であったとしても、応答は宛先毎に独立して生成されるためである。

一方、ステップＳ１３２で「処理完了」でなければ、対象シートの「状態」は「遅延未通知」であるので、遅延通知を管理装置１０２に送信するための処理を行うべくステップＳ１３７以下に進み、まず対象の管理装置コマンドシートに記載されている管理装置コマンドについてのＳＯＡＰエンベロープによる遅延通知を、シートの「コマンドＩＤ」や「宛先情報」等を参照して作成する（Ｓ１３７）。そして、これにエンティティヘッダを付加して遅延通知に関するパートを生成し（Ｓ１３８）、対象の管理装置コマンドシートの「状態」を「処理待ち」に変更する（Ｓ１３９）。

ステップＳ１３６又はＳ１３９の後は、ステップＳ１３２に戻り、次のシートを対象として処理を繰り返す。そして、全てのシートについてこれらの処理を行った時点で、ステップＳ１３５、Ｓ１３９又は、ここでは詳細を示していない図２７のステップＳ１１の部分で生成した各パートをマージし、図１６に示したようなマルチパートのＨＴＴＰリクエストを生成して管理装置１０２に送信する（Ｓ１４０）。
なお、ステップＳ１３６又はＳ１３９で行った「状態」の変更は、実際にこの送信が終了してから行うようにしてもよい。このようにすることにより、通信エラーが発生しても、送信しようとしていたコマンド及びコマンド応答を再度送信の対象とすることができるので、システムの信頼性が向上する。
ステップＳ１４０の後は、図２７のステップＳ１５以降に相当する処理に進む。
この遠隔管理システムにおいては、メッセージの収集及び分配処理の基本動作を、以上のように変更することにより、複数の装置を宛先とした管理装置コマンドを処理することができる。

次に、この遠隔管理システムにおいて仲介装置１０１が実行する、遅延通知をした管理装置コマンドの実行に関する処理について説明する。
図４７は、この処理を示すフローチャートである。この処理においては、仲介装置１０１のＣＰＵ５２は、管理装置コマンド実行結果生成手段４４として機能する。またこの処理は、図２７に示した管理装置１０２との間のメッセージの送受信に係る処理とは独立して、ＣＰＵ５２が仲介装置１０１の起動時に開始するものである。

そして、この処理においては、まず管理装置コマンドプール４２に「状態」が「処理待ち」である管理装置コマンドシートがあるか否か判断し（ＳＡ１）、なければこのような管理装置コマンドシートを発見するまで待機する。なお、第１の実施例の場合と同様に、「処理待ち」という状態は、管理装置１０２に対して遅延通知を送信済でかつコマンドに係る処理は未実行あることを示すものである。
ステップＳＡ１で「処理待ち」の管理装置コマンドシートを発見した場合には、その１つを処理対象とし、その管理装置コマンドシートの「状態」を「処理中」に変更する（ＳＡ２）。

その後、図４５の場合と同様なステップＳ１２２乃至Ｓ１２４の処理を行って処理対象の管理装置コマンドシートに記載された管理装置コマンドを実行し、これが完了するとステップＳＡ１に戻って処理を繰り返す。
なお、ステップＳ１２２及びＳ１２３の処理は、複数の「宛先情報」に関して並行して行ってもよい。すなわち、ある宛先について「コマンドの通知先」に登録した参照情報を用いてハンドラを呼び出して処理を指示した後、実行結果を受け取る前に次の宛先についてハンドラを呼び出して処理を指示してもよい。
また、図４６に示した処理全体を複数のスレッド（例えば４スレッド）で同時に行うようにしてもよいことは、第１の実施例における図３３の処理の場合と同様である。

以上のような処理を行うようにすれば、任意のタイミングで管理装置コマンドを実行することができるので、実行に時間のかかるコマンドがあった場合でも、以後の処理が滞ることがない。そして、全ての宛先について処理が完了し、その結果をコマンド応答として管理装置１０２に送信可能な状態にできた場合に管理装置コマンドシートの「状態」を「処理完了」に変更してその旨を示すことができる。

この実施例の遠隔管理システムにおいては、以上のような処理を行うようにしたことにより、複数の装置を宛先とした管理装置コマンドに対応可能となり、管理装置が複数の装置に同じコマンドを送信しようとする場合に、宛先以外の部分を繰り返し送信する必要がなくなるため、転送データ量を低減して通信の効率化を図ることができる。
また、応答については各宛先毎に別のパートで送信するが、全ての宛先からの応答が揃ってから送信を行うため、各宛先からの応答を一括して送信できるため、応答送信のための仲介装置１０１から管理装置１０２への通信要求が１回で済むので、通信のオーバーヘッドを低減して通信効率を高めることができる。なお、被管理側コマンドや、他の管理装置コマンドに対する応答もこれらの応答と一括して転送してよいことは、言うまでもない。

〔第３の実施例：図４８乃至図５０〕
次に、図１に示した通信システムの第３の実施例である遠隔管理システムについて説明する。この遠隔管理システムの特徴は、第２の実施例の場合と同様、複数の装置を宛先とした管理装置コマンドに対応している点及び、この場合に各宛先からの動作応答が揃った後で応答を送信する点である。そして、このような特徴を実現するため、主に仲介装置１０１における処理が第１の実施例の場合と異なる。そして、ハードウェア構成及び、管理装置１０２や画像形成装置１００が実行する処理については、第１の実施例の場合とほぼ同様であるから、これらについての説明は省略するか簡単にする。

この遠隔管理システムにおいても、管理装置１０２が、同じ内容の動作要求を同時に複数の装置に対して送信しようとしたときに複数の装置を宛先とした管理装置コマンドを作成することは、第２の実施例の場合と同様である。しかし、仲介装置においてこれを登録する管理装置コマンドシートは、宛先毎に別々に設けるため、第１の実施例の場合と同様な形式のものを用いる。
また、この遠隔管理システムにおいても、仲介装置１０１が実行するメッセージの収集及び分配処理の基本動作は、第１の実施例で図２７を用いて説明したものと同様なものである。しかし、複数の装置を宛先とした管理装置コマンドを処理できるようにするため、各処理の詳細は、第１の実施例の場合と異なる箇所もある。

まず、ステップＳ１８の管理装置コマンド登録処理は、図４８及び図４９のフローチャートに示す処理となる。
この処理においては、まず、図２７のステップＳ１７乃至Ｓ１９のループで処理対象となっているパートのＳＯＡＰエンベロープを解析して内容を参照できる形式のデータに変換し（Ｓ１５１）、そのパートに記載されたコマンドを、宛先情報に従って展開、すなわち宛先情報を個々の宛先毎に分けると共に、各宛先情報に対応させてコマンドに係るそれ以外の情報をコピーする（Ｓ１５２）。そしてその後、対象のパートに宛先情報として記載されていた全ての宛先を順次対象として、ステップＳ１５３乃至Ｓ１５８の処理を繰り返す。

この部分の処理においては、まず対象の宛先についての管理装置コマンドを登録するための管理装置コマンドシートを管理装置コマンドプール４２に作成する（Ｓ１５３）。そして、管理装置コマンドとコマンドＩＤ及び対象の宛先の宛先情報をその管理装置コマンドシートに登録する（Ｓ１５４）。各項目への登録内容については、第１の実施例の場合と同様である。
そして、以上の項目への登録が終了すると、対象としている宛先が仲介装置１０１すなわち自分自身であるか否か判断する（Ｓ１５５）。そして、仲介装置１０１であれば、管理装置コマンドシートの「メソッド名」に記憶させたメソッドを実行させるためのハンドラ（管理装置コマンドハンドラ４４ａ）への参照情報を、予め用意してあるメソッドとハンドラとの対応関係の情報を参照して検索し（Ｓ１５６）、発見した参照情報を管理装置コマンドシートの「コマンドの通知先」の項目に登録する（Ｓ１５７）。

一方、ステップＳ１５５で仲介装置１０１でなければ、コマンドを宛先に転送するためのハンドラ（管理装置コマンド転送ハンドラ４４ｂ）への参照情報を検索し（Ｓ１５８）、発見した参照情報を同様に登録する（Ｓ１５７）。
ステップＳ１５７の後は、ステップＳ１５３に戻り、次の宛先を対象として処理を繰り返す。そして、全ての宛先についてこれらの処理を行った時点で、複数の装置を宛先とした管理装置コマンドを、管理装置コマンドプール４２の宛先毎の管理装置コマンドシートに登録することができる。そして、続けて応答状況管理のための図４９に示す処理に進む。

図４９に示す処理においては、まず所定時間内に管理装置コマンドに対する応答を全ての宛先について生成できるか否か判断する（Ｓ１６１）。なお、第１の実施例の場合と同様、画像形成装置等にコマンド転送して応答を取得する必要がある場合には、ここでの判断は必ずＮＯにするものとする。
そして、ステップＳ１６１で所定時間内に生成できると判断した場合には、ステップＳ１６２以下の処理を行って直ちに管理装置コマンドに係る処理を実行する。すなわち、ステップＳ１５３で作成した各管理装置コマンドシートを順次対象として、ステップＳ１６２乃至Ｓ１６４の処理を繰り返す。

この部分の処理は、対象の管理装置コマンドシートの「コマンドの通知先」の情報に基づいてハンドラを呼び出し、「メソッド名」や「入力パラメータ」や「宛先情報」のデータを渡して管理装置コマンドに係る処理を実行させると共に（Ｓ１６２）、その実行結果を取得して対象の「宛先情報」と対応する「出力パラメータ」の項目に登録し（Ｓ１６３）、これが終了すると、対象の管理装置コマンドシートの「状態」を「処理完了」に変更し、そのコマンドシートについて処理が完了したことを示す（Ｓ１６４）ものである。
以上の処理をステップＳ１５３で作成した全ての管理装置コマンドシートについて繰り返すことにより、全ての宛先について管理装置コマンドを実行し、その結果をコマンド応答として管理装置１０２に送信可能な状態にすることができる。

一方、ステップＳ１６１で全ての宛先については所定時間内に生成できないと判断した場合には、ステップＳ１５３で作成した全ての管理装置コマンドシートの「状態」を「遅延未通知」に変更して遅延通知が必要であることを示す（Ｓ１６５）。ここで、全てのコマンドシートの「状態」を変更するのは、全てのコマンドシートに応答が登録された後で管理装置１０２にそれらを一括して送信するためである。
そして、これらのいずれかの処理が完了すると、管理装置コマンド登録処理を終了する。以上がこの遠隔管理システムにおいて仲介装置１０１が実行する管理装置コマンド登録処理である。

また、図２７のステップＳ１２乃至Ｓ１４に相当する管理装置コマンド実行結果収集処理からＨＴＴＰリクエスト送信処理までの処理は、図５０に示すものになる。
この処理においてはまず、管理装置コマンドプール４２から、コマンドＩＤ毎に組にして管理装置コマンドシートを抽出する。別々のコマンドシートであっても、同じコマンドＩＤを有する管理装置コマンドシートには、もともと１つのパートに記載されていたコマンドが登録されていると考えられるためである。
そして、ここで抽出した全ての組を順次対象としてステップＳ１７２乃至Ｓ１８０の処理を繰り返す。

この部分の処理においては、まず対象組の全管理装置コマンドシートの「状態」が「処理完了」であるか否か判断する。そして、全て「処理完了」であれば、これらのシートに登録されているコマンド応答を一括して管理装置１０２に送信すべく、対象組の全ての管理装置コマンドシートを順次対象としてステップＳ１７３乃至Ｓ１７６の処理を繰り返す。

この部分の処理は、まず対象の管理装置コマンドシートの「出力パラメータ」の内容を、そのシートに記載された管理装置コマンドに対する「宛先情報」に登録された宛先からのコマンド応答として収集し、「宛先情報」の内容もコマンド応答の送信元の情報として収集し、また「コマンドＩＤ」の内容も、対応する管理装置コマンドのコマンドＩＤとして収集する（Ｓ１７３）。その後、ステップＳ１７３で収集したコマンド応答と、その応答と共に収集したコマンドＩＤ及び送信元の情報とを、これらの情報がそれぞれＳＯＡＰボディとＳＯＡＰヘッダとに含まれるＸＭＬ文書（ＳＯＡＰエンベロープ）に変換し（Ｓ１７４）、これにエンティティヘッダを付して、対象のシートに記載された管理装置コマンド対する対象の宛先からのコマンド応答に関するパートを生成する（Ｓ１７５）。そしてその後、対象の管理装置コマンドシートの「状態」を「応答済」に変更する（Ｓ１７６）。
ステップＳ１７６の後は、ステップＳ１７３に戻り、次の管理装置コマンドシートを対象として処理を繰り返す。

一方、ステップＳ１７２で全て「処理完了」でなかった場合には、対象組の全管理装置コマンドシートの「状態」が「遅延未通知」であるか否か判断する（Ｓ１７７）。そして、全て「遅延未通知」であれば、対象組の各管理装置コマンドシートに登録されている管理装置コマンドに対する遅延通知を管理装置１０２に送信すべく、ステップＳ１７８以下の処理に進む。そして、まずＳＯＡＰエンベロープによるこの遅延通知を、シートの「コマンドＩＤ」や「宛先情報」等を参照して作成する（Ｓ１７８）。そして、これにエンティティヘッダを付して遅延通知に関するパートを生成し（Ｓ１７９）、対象組の各管理装置コマンドシートの「状態」を「処理待ち」に変更する（Ｓ１８０）。ここで、遅延通知は対象組について１つだけ作成し、各管理装置コマンドシートから収集した「宛先情報」を全て登録するものとする。遅延通知は、コマンドの宛先が異なっても同じ内容なので、このような形式で作成することにより、データ量の低減を図っている。

この処理が完了すると、ステップＳ１７２に戻って次の組を対象として処理を繰り返す。ステップＳ１７６の後で次の管理装置コマンドシートがなかった場合も同様である。また、ステップＳ１７７で全て「遅延未通知」でなかった場合にも、そのままステップＳ１７２に戻って次の組を対象として処理を繰り返す。このケースに該当するのは、例えば遅延通知の送信後に各管理装置コマンドシートの「状態」が「処理待ち」になっていたり、一部のシートのみについて「処理中」や「処理完了」になっている場合である。
そして、これらの場合に全ての組について処理が完了していれば、ステップＳ１７５、Ｓ１７９又は、ここでは詳細を示していない図２７のステップＳ１１の部分で生成した各パートをマージし、図１６に示したようなマルチパートのＨＴＴＰリクエストを生成して管理装置１０２に送信する（Ｓ１８１）。

なお、ステップＳ１７６又はＳ１８０で行った「状態」の変更は、実際にこの送信が終了してから行うようにしてもよい。このようにすることにより、通信エラーが発生しても、送信しようとしていたコマンド及びコマンド応答を再度送信の対象とすることができるので、システムの信頼性が向上する。
ステップＳ１８１の後は、図２７のステップＳ１５以降に相当する処理に進む。

この遠隔管理システムにおいては、メッセージの収集及び分配処理の基本動作を、以上のように変更することにより、複数の装置を宛先とした管理装置コマンドを、宛先毎に管理装置コマンドシートを用意して処理することができる。
なお、この遠隔管理システムにおいては、管理装置コマンドシートの形式は第１の実施例の場合と同様であるので、仲介装置１０１が実行する、遅延通知をした管理装置コマンドの実行に関する処理は、第１の実施例で図３３を用いて説明した処理をそのまま用いることができる。なお、この処理では管理装置コマンドシートの選択順を考慮していないが、「コマンドＩＤ」が同じ管理装置コマンドシートに関する処理を続けて行うようにするとよい。

この実施例の遠隔管理システムにおいても、以上のような処理を行うようにしたことにより、複数の装置を宛先とした管理装置コマンドに対応可能となり、管理装置が複数の装置に同じコマンドを送信しようとする場合に、宛先以外の部分を繰り返し送信する必要がなくなるため、転送データ量を低減して通信の効率化を図ることができる。
また、応答については各宛先毎に別のパートで送信するが、全ての宛先からの応答が揃ってから送信を行うため、各宛先からの応答を一括して送信できるため、仲介装置１０１から管理装置１０２への通信要求が１回で済むので、通信のオーバーヘッドを低減して通信効率を高めることができる。
なお、この実施例においても、第１の実施例と同様な変形を適用することが可能である。

〔第４の実施例：図５１乃至図５３〕
次に、図１に示した通信システムの第４の実施例である遠隔管理システムについて説明する。この遠隔管理システムの特徴は、管理装置１０２が、複数の装置を宛先とした管理装置コマンドを１つのＳＯＡＰリクエストとして送信できる点及び、このような管理装置コマンドに対する応答を、応答が取得できたものから順に仲介装置１０１から管理装置１０２に送信する点である。そして、このような特徴を実現するため、主に仲介装置１０１における処理が第１の実施例の場合と異なる。そして、ハードウェア構成及び、管理装置１０２や画像形成装置１００が実行する処理については、第１の実施例の場合とほぼ同様であるから、これらについての説明は省略するか簡単にする。

この遠隔管理システムにおいても、管理装置１０２が、同じ内容の動作要求を同時に複数の装置に対して行おうとしたときに複数の装置を宛先とした管理装置コマンドを作成することは、第２及び第３の実施例の場合と同様である。
そして、仲介装置１０１においてこれを登録する管理装置コマンドシートは、第２の実施例で用いたものに若干変更を加えた形式としている。図５１に、この実施例の仲介装置１０１における管理装置コマンドシートにおけるデータ構造の例を示す。
この図に示すように、この遠隔管理システムでも、仲介装置１０１の管理装置コマンドシートに登録するデータの構成は、第２の実施例の場合と概ね同様である。しかし、「状態」の項目を各「宛先情報」と対応させて複数登録可能とした点が、第２の実施例の場合と異なる。これは、コマンド応答が取得できたものから順に応答を管理装置１０２に送信するようにするためには、宛先毎に「状態」を管理する必要あるためである。

次に、この遠隔管理システムにおいて仲介装置１０１が実行する処理について説明する。この遠隔管理システムにおいても、仲介装置１０１が実行するメッセージの収集及び分配処理の基本動作は、第１の実施例で図２７を用いて説明したものと同様なものである。しかし、複数の装置を宛先とした管理装置コマンドを処理できるようにするため、各処理の詳細は、第１の実施例の場合と異なる箇所もある。

まず、ステップＳ１８の管理装置コマンド登録処理は、第２の実施例で説明したものと同様な処理となる。ただし、図４５に示した部分に関しては、宛先毎に「状態」を管理するようにしたため、第２の実施例で説明したものとは若干異なる。図５２に、この遠隔管理システムにおいて仲介装置１０１が実行する処理のうち、図４５と対応する部分の処理を示す。
この図から分かるように、図５２に示す処理は、第１の実施例で図３１を用いて説明した処理を、作成した管理装置コマンドシートに含まれる各「宛先情報」を順次対象として繰り返すものである。従って、各処理の詳細についての説明は省略する。

また、図２７のステップＳ１２乃至Ｓ１４に相当する管理装置コマンド実行結果収集処理からＨＴＴＰリクエスト送信処理までの処理は、図５３に示すものになる。
この処理においてはまず、管理装置コマンドプール４２から、少なくとも１つの「宛先情報」に対応する「状態」が「処理完了」又は「遅延未通知」である管理装置コマンドシートを、送信に係る処理を行う対象にすべきものとして抽出する（Ｓ１９１）。そして、ステップＳ１９１の後で、ここで抽出した全ての管理装置コマンドシートを順次対象とし、さらに対象の管理装置コマンドシートに含まれる全ての「宛先情報」を順次対象として、ステップＳ１９２乃至Ｓ２００の処理を繰り返す。

この部分の処理においては、まず対象のシートの中の対象の「宛先情報」と対応する「状態」が「処理完了」であるか否か判断する（Ｓ１９２）。
そして、「処理完了」であれば、コマンド応答を管理装置１０２に送信するための処理を行うべくステップＳ１３３以下に進み、対象の管理装置コマンドシートの、対象の「宛先情報」と対応する「出力パラメータ」の内容を、そのシートに記載された管理装置コマンドに対する対象の宛先からのコマンド応答として収集し、対象の「宛先情報」の内容自体もコマンド応答の送信元の情報として収集し、また「コマンドＩＤ」の内容も、対応する管理装置コマンドのコマンドＩＤとして収集する（Ｓ１９３）。

その後、ステップＳ１９３で収集したコマンド応答と、その応答と共に収集したコマンドＩＤ及び送信元の情報とを、これらの情報がそれぞれＳＯＡＰボディとＳＯＡＰヘッダとに含まれるＸＭＬ文書（ＳＯＡＰエンベロープ）に変換し（Ｓ１９４）、これにエンティティヘッダを付して、対象のシートに記載された管理装置コマンドに対する対象の宛先からのコマンド応答に関するパートを生成する（Ｓ１９５）。そして、これらの処理が完了すると、対象の管理装置コマンドシート中の対象の「宛先情報」に対応する「状態」を「応答済」に変更する（Ｓ１９６）。

一方、ステップＳ１９２で「処理完了」でなければ、対象シートの中の対象の「宛先情報」と対応する「状態」が「遅延未通知」であるか否か判断する（Ｓ１９７）。そして、「遅延未通知」であれば、対象の「宛先情報」が示す宛先についての遅延通知を管理装置１０２に送信するための処理を行うべくステップＳ１９８以下に進み、まず対象の管理装置コマンドシートに記載されている管理装置コマンドについての、対象の「宛先情報」が示す宛先についてのＳＯＡＰエンベロープによる遅延通知を、シートの「コマンドＩＤ」や「宛先情報」等を参照して作成する（Ｓ１９８）。そして、これにエンティティヘッダを付してその遅延通知に関するパートを生成し（Ｓ１９９）、対象の管理装置コマンドシート中の対象の「宛先情報」と対応する「状態」を「処理待ち」に変更する（Ｓ２００）。

ステップＳ１９６又はＳ２００の後は、ステップＳ１９２に戻り、次のシートを対象として処理を繰り返す。また、ステップＳ１９７で「遅延未通知」でなかった場合には、特に管理装置１０２に通知を行う必要はないので、そのままステップＳ１９２に戻り、次の「宛先情報」を対象として処理を繰り返す。
そして、対象の管理装置コマンドシートの全ての「宛先情報」についてこれらの処理を行った時点で、次の管理装置コマンドシートを対象として同様な処理を行い、ステップＳ１９１で抽出した全ての管理装置コマンドシートについて処理が終了すると、ステップＳ２０１に進む。

そして、ステップＳ１９５，Ｓ１９９又は、ここでは詳細を示していない図２７のステップＳ１１の部分で生成した各パートをマージし、図１６に示したようなマルチパートのＨＴＴＰリクエストを生成して管理装置１０２に送信する（Ｓ２０１）。
なお、ステップＳ１９６又はＳ２００で行った「状態」の変更は、実際にこの送信が終了してから行うようにしてもよい。このようにすることにより、通信エラーが発生しても、送信しようとしていたコマンド及びコマンド応答を再度送信の対象とすることができるので、システムの信頼性が向上する。
ステップＳ２０１の後は、図２７のステップＳ１５以降に相当する処理に進む。
この遠隔管理システムにおいては、メッセージの収集及び分配処理の基本動作を、以上のように変更することにより、複数の装置を宛先とした管理装置コマンドを処理することができる。

次に、この遠隔管理システムにおいて仲介装置１０１が実行する、遅延通知をした管理装置コマンドの実行に関する処理について説明する。
図５４は、この処理を示すフローチャートである。この処理においては、仲介装置１０１のＣＰＵ５２は、管理装置コマンド実行結果生成手段４４として機能する。またこの処理は、図２７に示した管理装置１０２との間のメッセージの送受信に係る処理とは独立して、ＣＰＵ５２が仲介装置１０１の起動時に開始するものである。

そして、この処理においては、まず管理装置コマンドプール４２に少なくとも１つの「宛先情報」と対応する「状態」が「処理待ち」である管理装置コマンドシートがあるか否か判断し（Ｓ２１１）、なければこのような管理装置コマンドシートを発見するまで待機する。そして、ステップＳ２１１で「処理待ち」の管理装置コマンドシートを発見した場合には、その１つを処理対象とすると共に（Ｓ２１２）、その管理装置コマンドシートに含まれる各「宛先情報」を順次対象としてステップＳ２１３乃至Ｓ２１７の処理を繰り返す。

この部分の処理は、対象の管理装置コマンドシート中の対象「宛先情報」と対応する「状態」が処理待ちであるか否か判断する（Ｓ２１３）。ここで「処理待ち」であれば、その「宛先情報」の示す宛先について、管理装置コマンドに係る処理を実行する必要があることから、ステップＳ２１４以下に進む。
そして、まず対象の管理装置コマンドシート中の対象の「宛先情報」と対応する「状態」を「処理中」に変更し、その後、図５２のステップＳ１８２乃至Ｓ１８４と同様なステップＳ２１５乃至Ｓ２１７の処理を行って処理対象の管理装置コマンドシートに記載された管理装置コマンドを対象の「宛先情報」の示す宛先について実行する。
また、ステップＳ２１３で「処理待ち」でなければ、対象の「宛先情報」の示す宛先については処理を行う必要がないので、そのまま次の「宛先情報」を対象として処理を繰り返す。
そして、全ての「宛先情報」について処理が終了すると、ステップＳ２１１に戻って処理を繰り返す。

なお、ステップＳ２１３乃至Ｓ２１７の処理は、複数の「宛先情報」に関して並行して行ってもよい。すなわち、ある宛先について「コマンドの通知先」に登録した参照情報を用いてハンドラを呼び出して処理を指示した後、実行結果を受け取る前に次の宛先についてハンドラを呼び出して処理を指示してもよい。また、全ての「宛先情報」に関する処理を一連の処理として行うことは必須ではない。
また、図５４に示した処理全体を複数のスレッド（例えば４スレッド）で同時に行うようにしてもよいことは、第１の実施例における図３３の処理の場合と同様である。
以上のような処理を行うようにすれば、任意のタイミングで管理装置コマンドを実行することができるので、実行に時間のかかるコマンドがあった場合でも、以後の処理が滞ることがない。そして、コマンドに係る動作の結果をコマンド応答として管理装置１０２に送信可能な状態にできたものから順に、管理装置コマンドシートの「状態」を「処理完了」に変更してその旨を示すことができる。

この実施例の遠隔管理システムにおいては、以上のような処理を行うようにしたことにより、複数の装置を宛先とした管理装置コマンドに対応可能となり、管理装置が複数の装置に同じコマンドを送信しようとする場合に、宛先以外の部分を繰り返し送信する必要がなくなるため、転送データ量を低減して通信の効率化を図ることができる。
また、応答については、応答が取得できたものから順に送信を行うため、応答の取得後速やかに転送を行うことができる。なおこの場合に、被管理側コマンドや、他の管理装置コマンドに対する応答もこれらの応答と一括して転送することができるので、第１の実施例の場合ような通信効率の向上の効果を得ることができる。

なお、この実施例では１つの管理装置コマンドシートに複数の宛先を登録するようにしているが、第３の実施例の場合のように、宛先毎に管理装置コマンドシートを設けるようにしてもよい。このようにした場合、管理装置コマンドシートの作成後の処理は、第１の実施例の場合と同じものでよい。
また、この実施例においても、第１の実施例と同様な変形を適用することが可能である。

〔各実施例の第２の変形例：図５５，図５６〕
次に、以上説明した各実施例の第２の変形例について説明する。この変形例は、仲介装置１０１の管理装置コマンドシートにおける「状態」の遷移を上述の各実施例の場合と変えたものである。すなわち、初期状態の「未処理」から、「未処理」→「処理中」→「処理完了」→「応答済み」、「未処理」→「処理中」→「遅延通知済処理中」→「処理完了」→「応答済み」、または「未処理」→「遅延通知済未処理」→「遅延通知済処理中」→「処理完了」→「応答済み」と遷移するようにしている。
なお、「遅延通知済未処理」は、まだコマンドに係る処理に着手していないが管理装置１０２に対する遅延通知の送信は完了している状態を示し、「遅延通知済処理中」は、管理装置１０２に対する遅延通知の送信が完了しており、かつコマンドに係る処理を実行中であることを示す。また、この変形例での「未処理」及び「処理中」は、それぞれコマンドに係る処理に着手していない状態及び着手はしているが完了していない状態で、かつ管理装置１０２に対する遅延通知の送信が完了していない状態を示し、「遅延未通知」及び「処理待ち」の「状態」はここでは設けていない。

この変形例においては、このようにしたことに伴い、仲介装置１０１が実行する処理が、上述した各実施例の場合と一部異なる。そして、ここではこの変形を第１の実施例に適用した場合の処理例について説明する。
まず、この変形例においては、図２７のステップＳ１８に示した管理装置コマンド登録処理において、図３１に示した処理は行わず、図３０に示した処理により管理装置コマンドの管理装置コマンドプール４２への登録が完了すると、そのまま次のパートを対象として図２７のステップＳ１７の処理を行うか、次のパートがなければ処理を終了するようにしている。
そして、管理装置コマンドの実行は、図３３に示した処理と対応する図５５に示す処理によって行うようにしている。

この処理においては、まず管理装置コマンドプール４２に「状態」が「未処理」又は「遅延通知済未処理」である管理装置コマンドシートがあるか否か判断し（ＳＢ１）、なければこのような管理装置コマンドシートを発見するまで待機する。
ステップＳＢ１で「未処理」又は「遅延通知済未処理」の管理装置コマンドシートを発見した場合には、その１つを処理対象とし、その管理装置コマンドシートの「状態」を、元が「未処理」であれば「処理中」に、「遅延通知済未処理」であれば「遅延通知済処理中」に変更する（ＳＢ２）。
その後のステップＳ５２乃至Ｓ５４の処理については、図３３の場合と同様である。
この処理の内容からわかるように、この変形例では、「状態」が「未処理」の管理装置コマンドシートも処理の対象としているので、管理装置コマンドプールに登録後、遅延通知の送信が完了していない管理装置コマンドシートも、直ちに処理の対象となる。

また、この変形例においては、「状態」の遷移を変更したことにより、図２７のステップＳ１２乃至Ｓ１４に相当する管理装置コマンド実行結果収集処理からＨＴＴＰリクエスト送信処理までの処理も、上述した第１の実施例のものから変更され、図５６に示すものになる。
この処理においては、まず、管理装置コマンドプール４２に登録されている全ての管理装置コマンドシートを順次対象として、ステップＳ４０１乃至Ｓ４０９の処理を繰り返す。

そして、この部分の処理では、まず対象の管理装置コマンドシートの状態が「未処理」又は「処理中」であるか否か判断する（Ｓ４０１）。これらの「状態」は、コマンドに係る処理が完了していないが管理装置１０２に遅延通知も送信していないことを示すものであるので、これらの「状態」のいずれかであれば、管理装置１０２に遅延通知を送信すべく、ステップＳ４０２以下の処理に進む。
そして、まず対象の管理装置コマンドシートに記載されている管理装置コマンドについてのＳＯＡＰエンベロープによる遅延通知を、シートの「コマンドＩＤ」や「宛先情報」等を参照して作成する（Ｓ４０２）。そして、これをにエンティティヘッダを付して遅延通知に関するパートを生成し（Ｓ４０３）、対象の管理装置コマンドシートの「状態」が「未処理」であれば「遅延通知済未処理」に、「処理中」であれば「遅延通知済処理中」に変更して遅延通知を行った旨を示す（Ｓ４０４）。

一方、ステップＳ４０１で「未処理」又は「処理中」でなければ、対象の管理装置コマンドシートの状態が「処理完了」であるか否か判断する（Ｓ４０５）。そして、「処理完了」であれば、コマンド応答を管理装置１０２に送信するための処理を行うべくステップＳ４０６以下に進み、まず対象の管理装置コマンドシートの「出力パラメータ」の内容を、そのシートに記載された管理装置コマンドに対するコマンド応答として収集し、「コマンドＩＤ」の内容も、対応する管理装置コマンドのコマンドＩＤとして収集して、また「宛先情報」の内容もそのコマンドの宛先すなわちコマンド応答の送信元の情報として収集する（Ｓ４０６）。

その後、ステップＳ４０６で収集したコマンド応答と、その応答と共に収集したコマンドＩＤ及び送信元の情報とを、これらの情報がそれぞれＳＯＡＰボディとＳＯＡＰヘッダとに含まれるＸＭＬ文書（ＳＯＡＰエンベロープ）に変換し（Ｓ４０７）、これにエンティティヘッダを付して、対象のシートに記載された管理装置コマンドに対するコマンド応答に関するパートを生成する（Ｓ４０８）。そして、次に対象の管理装置コマンドシートの「状態」を「応答済」に変更する（Ｓ４０９）。
ステップＳ４０４又はＳ４０９の後は、ステップＳ４０１に戻り、次の管理装置コマンドシートを対象として処理を繰り返す。ステップＳ４０５で「処理完了」でなかった場合にも、同様である。

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

この変形例の遠隔管理システムにおいては、以上のような処理を行うようにしたことにより、処理が遅延するか否かを判断する必要がなく、管理装置コマンドシートの「状態」のみを参照して遅延通知の要否を判断することができるので、処理を効率よく行うことができる。また、遅延通知を行う前であってもコマンドに係る処理に着手できるので、この点でも処理の効率化を図ることができる。
なお、ここではこの変形例を第１の実施例に適用した例について説明したが、他の実施例にも適用できることはもちろんである。この場合において、具体的な処理はここで説明したものと異なることになるが、管理装置コマンドシート毎あるいは宛先情報毎に上記のような「状態」の遷移を行わせるようにすればよい。
また、管理装置１０２でも同様な処理を行い、被管理側コマンドシートについても同様な取扱いを行うようにしてもよい。

〔第２の実施形態：図５７乃至図６２〕
次に、この発明の仲介装置及びその仲介装置を用いて構成した通信システムの第２の実施形態について説明する。なお、この実施形態は、上述した第１の実施形態と共通点が多いので、この実施形態の説明に使用する図面において、第１の実施形態及びその各実施例で説明した構成と対応する部分には、同じ符号を用いる。
まず、図５７に、この実施形態の通信システムの構成を示す。
この通信システムも、第１の実施形態の場合と同様、第１の通信装置である管理装置１０２と、第２の通信装置である複数の画像形成装置１００と、これらの間の通信を仲介する仲介装置１０１を備える。しかし、この実施形態では、仲介装置１０１と管理装置１０２との間の通信プロトコルにＳＭＴＰを採用しているため、全体としての構成は第１の実施形態とはかなり異なったものとなっている。なお、仲介装置１０１と画像形成装置１００との間の通信方式は、第１の実施形態の場合と全く同様である。

この通信システムは、図５７に示すように、管理装置１０２とメールサーバＡ′とを接続したＬＡＮ＿Ａと、仲介装置１０１及び複数の画像形成装置１００とメールサーバＢ′とを接続したＬＡＮ＿Ｂとを、それぞれファイアウォールＡとファイアウォールＢとを介してインターネット１０３に接続して構成している。また、ファイアウォールを介して外部からアクセス可能な位置に、ＬＡＮ＿Ａ側ではメールサーバＡを、ＬＡＮ＿Ｂ側ではメールサーバＢをそれぞれ設けている。

ＳＭＴＰを用いて通信を行う場合には、管理装置１０２と仲介装置１０１との間での情報転送は電子メールによって行う。そして、例えば仲介装置１０１から管理装置１０２に情報を送信する場合、図５７に破線で示したように、仲介装置１０１は、管理装置１０２を宛先とする電子メールをまずメールサーバＢ′に送信する。すると、各メールサーバＢ′，Ｂ，Ａを順次介して、管理装置１０２が直接アクセスするメールサーバＡ′まで電子メールが転送される。また、図示は省略したが、通常はメールサーバＢとメールサーバＡとの間に更に別のメールサーバを介して転送を行うことになる。

そして、一点鎖線で示したように管理装置１０２が定期的にメールサーバＡ′にアクセスすることにより、管理装置１０２宛の電子メールを受け取ることができ、以上で仲介装置１０１から管理装置１０２への情報転送が完了する。管理装置１０２から仲介装置１０１への情報転送は、逆の手順で行うことができ、情報転送に関しては、管理装置１０２と仲介装置１０１とは対称である。ただし、メールサーバＡ′及びＢ′を設けることは必須ではなく、管理装置１０２がメールサーバＡと、仲介装置１０１がメールサーバＢと直接通信を行うようにしてもよい。また、メール受信用のメールサーバとメール送信用のメールサーバが異なってもよい。

このような通信システムにおいて、各ＬＡＮには外部からアクセス可能な位置にメールサーバを設けていることから、ファイアウォールを越えて電子メールを転送することができる。
なお、この実施例においては、管理装置１０２と仲介装置１０１とが直接ネゴシエーションをした上で通信を行っているわけではないが、相互に情報転送を行うことが可能である。

また、この通信システムにおいても、管理装置１０２及び仲介装置１０１は、第１の実施形態の場合と同様に、互いの制御管理を行うためのアプリケーションプログラムを実装している。そして、ＲＰＣにより、互いの実装するアプリケーションプログラムのメソッドに対する処理の依頼である「動作要求」を送信し、この依頼された処理の結果である「動作応答」を取得することができるようになっている。
また、これらの動作要求と動作応答の関係も、第１の実施形態の場合と同様、管理装置１０２と仲介装置１０１とで対称なものである。しかし、ＳＭＴＰの場合には、通信のレベルでも管理装置１０２と仲介装置１０１とが対称な関係にあることが、ＨＴＴＰの場合と異なる。

図５８に、この通信システムにおける通信シーケンスの例を示す。
上述したように、この通信システムにおいては、管理装置１０２と仲介装置１０１との間の通信は、電子メールを用いて行う。そして、電子メールには、送信元と宛先は存在し、その宛先から送信元に返信を行うことも可能である。しかし、初めの電子メールと返信とは全く独立したものであり、ＨＴＴＰの場合のような、通信要求と通信応答のような関係はない。
従って、どちらの通信装置から先に通信を行ってもよいし、交互に電子メールを送信しなければならないということもないのであるが、ここでは、管理装置１０２から仲介装置１０１にまず電子メールを送信し、交互に計３通の電子メールを送受信する場合の例を示している。

この図に示すように、仲介装置１０１から管理装置１０２への電子メールには、仲介装置コマンドと、画像機器コマンドと、仲介装置１０１宛ての管理装置コマンドに対する応答（コマンド応答）と、画像形成装置１００宛ての管理装置コマンドに対する応答とを記載して送信するようにしている。また、管理装置１０２から仲介装置１０１への電子メールには、仲介装置１０１宛て又は画像形成装置１００宛ての管理装置コマンドと、仲介装置コマンドに対する応答と、画像機器コマンドに対する応答とを記載して送信するようにしている。なお、遅延通知を送信する場合には、上記コマンド応答に代えて遅延通知を記載してもよい。
従って、例えば画像機器コマンドａは、電子メールｘに記載して転送し、管理装置１０２からのコマンド応答をその後の電子メールｙに記載して転送することができる。また、仲介装置１０１宛ての管理装置コマンドｃは、電子メールｙに記載して転送し、仲介装置１０１からのコマンド応答をその後の電子メールｚに記載して転送することができる。

なお、コマンド及びコマンド応答はそれぞれ任意の数ずつ（０でもよい）１通の電子メールに記載することができる。そして、１通の電子メールに記載した内容は、１つのメッセージであり、当然論理的に一括して転送する。そして、このようにすることにより、必要な情報を転送するための電子メールの数を減らし、オーバーヘッドを低減して通信の効率化を図っている。
また、コマンドを受信した後最初に送信する電子メールにコマンド応答を記載しなくてもよいことは、図７を用いて説明した第１の実施形態の場合と同様である。

次に、管理装置１０２及び仲介装置１０１における、コマンドやコマンド応答を結合し、また分離する処理を行うための機能構成及びその処理の手順について説明する。ハードウェア構成については、それぞれ第１の実施形態で説明したものと同様なものを使用することができる。
図５９は、仲介装置１０１の機能のうち、コマンド及びコマンド応答に関する処理を行うための機能の構成を示す図１１と対応する機能ブロック図である。そして、この図には、仲介装置１０１が管理装置１０２と通信を行う場合のデータの流れを示している。
図５９に示す機能のうち、被管理側コマンドプール４１，管理装置コマンドプール４２，仲介装置コマンド生成手段４３，管理装置コマンド実行結果生成手段４４は、それぞれ図１１に示した同名の構成要素と対応するものであり、同様な機能を有する。

また、送信メッセージ収集手段７５及び受信メッセージ分配手段７８も、図１１に示した同名の手段と対応するものである。ただし、送受信するためのデータの形式が、ＳＭＴＰに対応した形式である点が図１１に示した例とは異なる。しかし、コマンドやコマンド応答に対応する、個々のＳＯＡＰメッセージについては、図１１の場合と同様なものである。
メール送信手段７６及びメール受信手段７７については、それぞれ一括送信手段及び一括受信手段に該当するが、送受信に使用するプロトコルが異なることに伴って、図１１に示したＨＴＴＰリクエスト送信手段４７ａ及びＨＴＴＰレスポンス受信手段４７ｂとは異なるものである。

すなわち、メール送信手段７６は、送信メッセージ収集手段４５が生成した送信メッセージを含む、管理装置１０２宛の電子メールを生成し、メールサーバＢ′に送信する機能を有する。そして、それ以降の電子メールの転送には、仲介装置１０１は関与しない。また、１つの電子メールに送信メッセージをいくつ含めてもよいし、コマンド応答に係る送信メッセージと管理装置１０２側コマンドに係る送信メッセージとを任意に混在させることもできる点等は、図１１に示した例の場合と同様である。

メール受信手段７７は、定期的にメールサーバＢ′にアクセスして仲介装置１０１宛ての新着メールの有無を調べ、新着メールがあった場合にこれを受信する機能を有する。そしてここでは、受信する電子メールには、管理装置コマンド及びそのコマンドと関連付けられたコマンドＩＤを含む受信メッセージと、仲介装置コマンド又は画像機器コマンドに対する応答又は遅延通知及びそのコマンドと関連付けられたコマンドＩＤを含む受信メッセージとが、任意に混在して含まれている。
また、この実施形態においても、仲介装置１０１にＨＴＴＰサーバ機能部４６とＨＴＴＰクライアント機能部４７とを設けているが、これは、被管理装置１０と通信を行うためのものである。

次に、このような機能を有する仲介装置１０１が管理装置１０２宛てに送信する電子メールの例を図６０に示す。
この電子メールは、図１６に示したＨＴＴＰリクエストの場合と同様に、ボディ部としてＭＩＭＥ（Multipurpose Internet Mail Extension）に従ったマルチパートのメッセージが記載され、この各パートには、それぞれＳＯＡＰエンベロープが埋め込まれている。すなわち、ボディの部分はＨＴＴＰリクエストの場合と同様なものになっている。

しかし、ヘッダ部分はＨＴＴＰリクエストの場合とは異なり、電子メールの送信元アドレスを示すFrom、宛先アドレスを示すTo、表題を示すSubject等の情報が記載されている。
管理装置１０２から仲介装置１０１に送信する電子メールについては、ヘッダのうちFromの内容とToの内容を入れ替えたものになる。
また、これらの電子メールに記載されるＳＯＡＰエンベロープの内容は、ＨＴＴＰリクエストやＨＴＴＰレスポンスの場合と同様なものである。ただし、各パートのエンティティヘッダの部分は、データのエンコード方式が異なるためＨＴＴＰの場合とは一部が異なる。

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

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

次に、管理装置コマンドに対する応答である管理装置コマンド実行結果の収集処理を行う（Ｓ５０２）。この処理は、管理装置コマンドプール４２から管理装置に送信すべきコマンド応答を収集する処理であり、やはり収集したデータからＳＯＡＰエンベロープのパートを生成する処理を含む。
その後、ステップＳ５０１及びＳ５０２の処理で生成したパートを１つにマージして、すべてのパートを含む電子メールを生成し（Ｓ５０３）、その電子メールを管理装置１０２に宛てて送信して（Ｓ５０４）、処理を終了する。

以上の処理において、ステップＳ５０１及びＳ５０２の処理が収集手順の処理であり、ここではＣＰＵ５２は送信メッセージ収集手段４５として機能する。また、ステップＳ５０３及びＳ５０４が一括送信手順の処理であり、ここではＣＰＵ５２がメール送信手段７６として機能する。
これらの処理は、図２７に示したステップＳ１１乃至Ｓ１４の処理と対応するものであるが、ＳＭＴＰの場合には、電子メールの送信と受信の間には、通信要求と通信応答のような関係はないため、処理は一旦ここで終了し、電子メールを受信する場合には、別途図６２に示す処理を行う。

図６２には、メッセージ受信時の処理の基本動作のフローチャートを示す。
仲介装置１０１のＣＰＵ５２は、定期的にメールサーバＢ′にアクセスし、仲介装置１０１宛ての新着の電子メールがあると、図６２のフローチャートに示す処理を開始する。
この処理においては、まず新着の電子メールを受信する（Ｓ５１１）。そして、受信した電子メールのボディ（本文）を、各パートに分割する（Ｓ５１２）。ここで、各パートへの分割は、「MIME_boundary」で区分された要素に分割することであり、またここで全てのパートに関して分割する。

そしてその後、全てのパートを順に対象としてステップＳ５１３乃至Ｓ５１５の処理を繰り返す。この処理においては、まず対象のパートが管理装置コマンドを記載したパートか否か判断する（Ｓ５１３）。そして、管理装置コマンドであれば管理装置コマンド登録処理を行う（Ｓ５１４）。また、管理装置コマンドでないときは、被管理側コマンドに対する応答又は遅延通知が記載されたパートであるので、応答通知処理を行う（Ｓ５１５）。

ステップＳ５１４又はＳ５１５の後は、ステップＳ５１３に戻り、次のパートを対象として処理を繰り返す。そして、全てのパートについてこれらの処理を行った時点で、図６２のフローチャートに示す処理を終了する。
以上の処理においては、ステップＳ５１１が一括受信手順の処理であり、ここではＣＰＵ５２はメール受信手段７７として機能する。また、ステップＳ５１２乃至Ｓ５１５が第１の分配手順の処理であり、ここではＣＰＵ５２が受信メッセージ分配手段４８として機能する。これらの処理は、図２７に示したステップＳ１５乃至Ｓ１９の処理と対応するものである。

以上の各処理の詳細は、第１の実施形態で図２８乃至図３２を用いて説明したものと同様である。また、遅延通知をした管理装置コマンドの実行に関する処理については、第１の実施形態で図３３を用いて説明した処理と同様なものである。
以上で、仲介装置１０１において実行する、各コマンド及びコマンド応答の転送に関する処理の説明を終了する。
なお、管理装置１０２の機能及び管理装置１０２において実行する処理については、管理装置コマンドと被管理側コマンドとの意味合いが逆になる点以外は、仲介装置１０１の場合と概ね同様である。ただし、管理装置１０２は、画像形成装置１００宛ての管理装置コマンドのように、他の装置に転送して実行させるべきコマンドを受信することはないので、ＨＴＴＰクライアント機能部やＨＴＴＰサーバ機能部を設ける必要はない。また、第１の実施形態で図３７を用いて説明したように、受信したコマンドの転送に関連する処理は行う必要がない。

以上説明してきたように、この発明は、ＳＭＴＰのように、情報の送信と返信とが必ずしも対応しないプロトコルを使用して通信を行う場合にも適用できる。そして、この場合にも、仲介装置１０１を設け、画像形成装置１００と管理装置１０２との間の通信を、この仲介装置１０１を介して行うようにしたことにより、管理装置１０２から複数の画像形成装置１００に宛てた動作要求を送信する場合でも、仲介装置１０１までは一括して送信でき、また複数の画像形成装置１００に宛てた動作要求に対する動作応答も仲介装置１０１から一括して受信できるので、通信のオーバーヘッドを低減して通信効率を高めることができる。これ以外の点についても、第１の実施形態の場合と概ね同様な効果を得ることができる。

また、通信に電子メールを用いれば、ファイアウォールの内側へも容易に情報を転送することができる。
なお、この第２の実施形態についても、第１の実施形態について説明した第１乃至第４の実施例やその変形例のような処理を採用し、同様な効果を得ることができる。

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

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

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

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

さらにまた、通信システムの構成についても、以上説明したものに限られることはなく、遠隔管理システム以外の通信システムにもこの発明を適用できることは、言うまでもない。例えば、第２の通信装置が遅延通知等の機能に対応しているものであってもよいし、第１の通信装置が第２の通信装置や仲介装置を管理する機能を有しない装置であってもよい。また、第１の通信装置が、第２の通信装置が提供する種々の機能を利用して動作する装置であるような構成も考えられる。
この場合において、この発明を適用することにより、第１の通信装置が多数の第２の通信装置に処理を依頼する場合でも、少ない通信負荷で動作要求及び動作応答を授受することができるので、多数の第２の通信装置を連携して動作させるシステムを容易に実現でき、負荷の大きな処理を依頼する場合でも、多数の第２の通信装置間に効率よく処理を分散させることができる。
また、仲介装置を多段にカスケード接続する構成にも対応可能である。

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

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

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

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

図３に示した仲介装置の機能のうち、コマンド及びコマンド応答に関する処理を行うための機能の構成を示す機能ブロック図である。図１１に、仲介装置が管理装置と通信を行う場合のデータの流れを加えた図である。図３に示した仲介装置の被管理側コマンドシートにおけるデータ構造の例を示す図である。同じく画像機器コマンドシートにおけるデータ構造の例を示す図である。図１１に、仲介装置が画像形成装置と通信を行う場合のデータの流れを加えた図である。図３に示した仲介装置が管理装置に送信するＨＴＴＰリクエストの例を示す図である。同じく仲介装置が管理装置から受信するＨＴＴＰレスポンスの例を示す図である。図３に示した遠隔管理システムにおける、画像機器コマンドを記載したパートの例を示す図である。同じく管理装置コマンドに対する応答を記載したパートの例を示す図である。同じく仲介装置コマンドを記載したパートの例を示す図である。

同じく仲介装置コマンドに対する応答を記載したパートの例を示す図である。同じく画像形成装置宛ての管理装置コマンドを記載したパートの例を示す図である。同じく画像形成装置宛ての管理装置コマンドに対する応答を記載したパートの例を示す図である。同じく仲介装置宛ての管理装置コマンドを記載したパートの例を示す図である。同じく仲介装置宛ての管理装置コマンドに対する応答を記載したパートの例を示す図である。同じく仲介装置宛ての管理装置コマンドに対する遅延通知を記載したパートの例を示す図である。図３に示した仲介装置におけるメッセージの収集及び分配処理の基本動作を示すフローチャートである。同じく、被管理側コマンド収集処理をより詳細に示すフローチャートである。同じく、管理装置コマンド実行結果収集処理乃至ＨＴＴＰリクエスト送信処理をより詳細に示すフローチャートである。同じく管理装置コマンド登録処理の一部をより詳細に示すフローチャートである。

図３０の続きの処理を示すフローチャートである。同じく応答通知処理をより詳細に示すフローチャートである。図３に示した仲介装置における、遅延通知をした管理装置コマンドの実行に関する処理を示すフローチャートである。対象のコマンドが仲介装置宛てでない場合の図３３のステップＳ５２の処理をより詳細に示すフローチャートである。図３に示した管理装置の機能のうち、コマンド及びコマンド応答に関する処理を行うための機能の構成を示す機能ブロック図である。図３に示した管理装置におけるメッセージの収集及び分配処理の基本動作を示すフローチャートである。同じく、被管理側コマンド登録処理をより詳細に示すフローチャートである。図３に示した画像形成装置の機能のうち、コマンド及びコマンド応答に関する処理を行うための機能の構成を、管理装置コマンドを取り扱う場合のデータの流れと共に示す機能ブロック図である。同じく、画像機器コマンドを取り扱う場合のデータの流れと共に示す機能ブロック図である。図３に示した遠隔管理システムにおいて、画像形成装置が画像機器コマンドを生成してからそのコマンドに対する応答を受け取るまでに各装置において行われる一連の処理を示すフローチャートである。

同じく、管理装置が画像形成装置宛ての管理装置コマンドを生成してからそのコマンドに対する応答を受け取るまでに各装置において行われる一連の処理を示すフローチャートである。第１の実施例の変形例の仲介装置における管理装置コマンド登録処理の一部を示すフローチャートである。第２の実施例の仲介装置における管理装置コマンドシートにおけるデータ構造の例を示す図である。第２の実施例の仲介装置における管理装置コマンド登録処理の一部を示すフローチャートである。その続きの処理を示すフローチャートである。第２の実施例の仲介装置における管理装置コマンド実行結果収集処理乃至ＨＴＴＰリクエスト送信処理を示すフローチャートである。同じく、遅延通知をした管理装置コマンドの実行に関する処理を示すフローチャートである。第３の実施例の仲介装置における管理装置コマンド登録処理の一部を示すフローチャートである。その続きの処理を示すフローチャートである。第３の実施例の仲介装置における管理装置コマンド実行結果収集処理乃至ＨＴＴＰリクエスト送信処理を示すフローチャートである。

第４の実施例の仲介装置における管理装置コマンドシートにおけるデータ構造の例を示す図である。第４の実施例の仲介装置における、第２の実施例の図４５と対応する部分の処理を示すフローチャートである。同じく、管理装置コマンド実行結果収集処理乃至ＨＴＴＰリクエスト送信処理を示すフローチャートである。同じく、遅延通知をした管理装置コマンドの実行に関する処理を示すフローチャートである。第１の実施形態の第２の変形例の仲介装置における、遅延通知をした管理装置コマンドの実行に関する処理を示すフローチャートである。同じく、管理装置コマンド実行結果収集処理乃至ＨＴＴＰリクエスト送信処理を示すフローチャートである。この発明の仲介装置を用いて構成した通信システムの第２の実施形態の構成を示すブロック図である。その通信システムにおける通信シーケンスの例を示す図である。図５７に示した仲介装置の機能のうち、コマンド及びコマンド応答に関する処理を行うための機能の構成を示す、図１１と対応する機能ブロック図である。図５７に示した仲介装置が管理装置宛てに送信する電子メールの例を示す図である。図５７に示した仲介装置が実行するメッセージ送信時の処理の基本動作を示すフローチャートである。同じく、メッセージ受信時の処理の基本動作を示すフローチャートである。

符号の説明

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

Claims

第１の通信装置と複数の第２の通信装置との間の通信を仲介する仲介装置であって、
記憶手段と、
前記第１の通信装置から、前記第２の通信装置宛ての複数の動作要求を一括して受信するとともに、前記記憶手段に記憶させる一括受信手段と、
該一括受信手段が受信した各動作要求を、該各動作要求に含まれる宛先情報に従って宛先となる第２の通信装置に送信する個別送信手段と、
前記各第２の通信装置から、前記第１の通信装置からの動作要求に対する動作応答を受信するとともに、その動作応答と対応する動作要求と関連付けて前記記憶手段に記憶させる個別受信手段と、
前記記憶手段に記憶された各動作応答を、それぞれ対応する動作要求を特定する情報を含んだ状態で一括して前記第１の通信装置に送信する一括送信手段とを設けたことを特徴とする仲介装置。
請求項１記載の仲介装置であって、
前記動作要求及び動作応答がそれぞれ、形式を変更せずに複数結合して転送可能な１つのメッセージを生成することができる形式で表現され、また複数結合された状態では形式を変更せずに分割して転送可能な個々の動作要求及び動作応答に戻すことができる形式で表現されていることを特徴とする仲介装置。
請求項１又は２記載の仲介装置であって、
当該仲介装置宛ての動作要求に係る動作を実行し、実行結果としてその動作要求に対する動作応答を生成する手段を有し、
前記一括受信手段を、前記第１の通信装置から、前記第２の通信装置宛ての動作要求に加え、当該仲介装置宛ての動作要求も一括して受信する手段とし、
前記一括送信手段を、前記第２の通信装置から受信した各動作応答に加え、前記第１の通信装置からの当該仲介装置宛ての動作要求に対する動作応答も一括して前記第１の通信装置に送信する手段としたことを特徴とする仲介装置。
請求項１又は２記載の仲介装置であって、
前記記憶手段に記憶させた各動作要求について、その要求に関する処理の進行状況を管理し、その進行状況を示す進行情報を記憶する手段を設け、
前記一括送信手段が、前記進行情報により要求に係る動作が実行済みであることが示されている動作要求に対する動作応答を前記記憶手段から読み出して前記第１の通信装置に送信する手段であることを特徴とする仲介装置。
請求項１又は２記載の仲介装置であって、
前記動作要求が、優先順位の情報を含むものであり、
前記個別送信手段が、前記一括受信手段が受信した動作要求のうち、前記優先順位の高いものから優先的に前記宛先となる第２の通信装置に送信する手段であることを特徴とする仲介装置。
第１の通信装置と複数の第２の通信装置との間の通信を仲介する仲介装置であって、
前記第１の通信装置からの前記第２の通信装置宛ての動作要求と、該動作要求に対する動作応答とを記憶する記憶手段と、
前記第１の通信装置から、複数の前記動作要求を一括して受信する一括受信手段と、
該一括受信手段が受信した各動作要求を、動作要求毎に分割して前記記憶手段に記憶させる分配手段と、
前記動作要求を前記記憶手段から読み出すと共に、読み出した各動作要求を、その動作要求に含まれる宛先情報に従って宛先となる第２の通信装置に送信する個別送信手段と、
前記各第２の通信装置から、前記動作応答を受信すると共に、受信した動作応答を、その動作応答と対応する動作要求と関連付けて前記記憶手段に記憶させる個別受信手段と、
前記動作応答を前記記憶手段から読み出す収集手段と、
前記第１の通信装置に対して、前記収集手段が読み出した複数の動作応答を、それぞれ対応する動作要求を特定する情報を含んだ状態で一括して送信する一括送信手段とを設けたことを特徴とする仲介装置。
第１の通信装置と複数の第２の通信装置との間の通信を仲介する仲介装置であって、
記憶手段と、
前記第１の通信装置から、前記第２の通信装置宛ての複数のＳＯＡＰリクエストを１通の電子メールに記載した状態で受信するとともに、前記記憶手段に記憶させる一括受信手段と、
該一括受信手段が受信した各ＳＯＡＰリクエストを、該各ＳＯＡＰリクエストに含まれる宛先情報に従って宛先となる第２の通信装置に送信する個別送信手段と、
前記各第２の通信装置から、前記第１の通信装置からのＳＯＡＰリクエストに対するＳＯＡＰレスポンスを受信するとともに、そのＳＯＡＰレスポンスと対応するＳＯＡＰリクエストと関連付けて前記記憶手段に記憶させる個別受信手段と、
前記記憶手段に記憶された各ＳＯＡＰレスポンスを、それぞれ対応するＳＯＡＰリクエストを特定する情報を含んだ状態で１通の電子メールに記載して前記第１の通信装置に送信する一括送信手段とを設けたことを特徴とする仲介装置。
請求項７記載の仲介装置であって、
前記ＳＯＡＰリクエスト及びＳＯＡＰレスポンスがそれぞれ、形式を変更せずに複数結合して転送可能な１つのメッセージを生成することができる形式で表現され、また複数結合された状態では形式を変更せずに分割して転送可能な個々のＳＯＡＰリクエスト及びＳＯＡＰレスポンスに戻すことができる形式で表現されていることを特徴とする仲介装置。
請求項７又は８記載の仲介装置であって、
当該仲介装置宛てのＳＯＡＰリクエストによって要求された動作を実行し、そのＳＯＡＰリクエストに対するＳＯＡＰレスポンスに記載すべき実行結果を生成する手段を有し、
前記一括受信手段を、前記第１の通信装置から、前記第２の通信装置宛てのＳＯＡＰリクエストに加え、当該仲介装置宛てのＳＯＡＰリクエストも１通の電子メールに記載した状態で受信する手段とし、
前記一括送信手段を、前記第２の通信装置から受信した各ＳＯＡＰレスポンスに加え、前記第１の通信装置からの当該仲介装置宛てのＳＯＡＰリクエストに対するＳＯＡＰレスポンスも１通の電子メールに記載して前記第１の通信装置に送信する手段としたことを特徴とする仲介装置。
第１の通信装置と複数の第２の通信装置との間の通信を仲介する仲介装置であって、
前記第１の通信装置からの前記第２の通信装置宛ての動作要求と、該動作要求に対する動作応答とを記憶する記憶手段と、
前記第１の通信装置から、前記動作要求の内容を記載した複数のＳＯＡＰリクエストを１通の電子メールに記載した状態で受信する一括受信手段と、
該一括受信手段が受信した各ＳＯＡＰリクエストに記載された動作要求の内容を、動作要求毎に分割して前記記憶手段に記憶させる分配手段と、
前記動作要求を前記記憶手段から読み出すと共に、読み出した各動作要求の内容を記載したＳＯＡＰリクエストを、その動作要求に含まれる宛先情報に従って宛先となる第２の通信装置に送信する個別送信手段と、
前記各第２の通信装置から、前記動作応答の内容を記載したＳＯＡＰレスポンスを受信すると共に、受信したＳＯＡＰレスポンスに記載された動作応答の内容を、その動作応答と対応する動作要求と関連付けて前記記憶手段に記憶させる個別受信手段と、
前記動作応答を前記記憶手段から読み出す収集手段と、
前記第１の通信装置に対して、前記収集手段が読み出した動作応答の内容を記載した複数のＳＯＡＰレスポンスを、それぞれ対応するＳＯＡＰリクエストを特定する情報を含んだ状態で１通の電子メールに記載して送信する一括送信手段とを設けたことを特徴とする仲介装置。
第１の通信装置と、複数の第２の通信装置と、該第１の通信装置と各第２の通信装置との間の通信を仲介する仲介装置とを備える通信システムであって、
前記仲介装置に、
記憶手段と、
前記第１の通信装置から、前記第２の通信装置宛ての複数の動作要求を一括して受信するとともに、前記記憶手段に記憶させる一括受信手段と、
該一括受信手段が受信した各動作要求を、該各動作要求に含まれる宛先情報に従って宛先となる第２の通信装置に送信する個別送信手段と、
前記各第２の通信装置から、前記第１の通信装置からの動作要求に対する動作応答を受信するとともに、その動作応答と対応する動作要求と関連付けて前記記憶手段に記憶させる個別受信手段と、
前記記憶手段に記憶された各動作応答を、それぞれ対応する動作要求を特定する情報を含んだ状態で一括して前記第１の通信装置に送信する一括送信手段とを設け、
前記第１の通信装置に、
前記第２の通信装置宛ての複数の動作要求を一括して前記仲介装置に送信する送信手段と、
前記第２の通信装置宛ての動作要求に対する動作応答を、それぞれ対応する動作要求を特定する情報を含んだ状態で複数一括して前記仲介装置から受信する受信手段とを設け、
前記各第２の通信装置に、
前記第１の通信装置からの当該第２の通信装置宛ての動作要求を前記仲介装置から受信する受信手段と、
該手段が受信した動作要求に係る動作を実行し、実行結果として、その動作要求に対する動作応答であってその動作要求を特定する情報を含む動作応答を生成する手段と、
該手段が生成した動作応答を前記仲介装置に送信する送信手段とを設けたことを特徴とする通信システム。
請求項１１記載の通信システムであって、
前記動作要求及び動作応答がそれぞれ、形式を変更せずに複数結合して転送可能な１つのメッセージを生成することができる形式で表現され、また複数結合された状態では形式を変更せずに分割して転送可能な個々の動作要求及び動作応答に戻すことができる形式で表現されていることを特徴とする通信システム。
請求項１１又は１２記載の通信システムであって、
前記仲介装置に、当該仲介装置宛ての動作要求に係る動作を実行し、実行結果としてその動作要求に対する動作応答を生成する手段を設け、
該仲介装置において、
前記一括受信手段を、前記第１の通信装置から、前記第２の通信装置宛ての動作要求に加え、当該仲介装置宛ての動作要求も一括して受信する手段とし、
前記一括送信手段を、前記第２の通信装置から受信した各動作応答に加え、前記第１の通信装置からの当該仲介装置宛ての動作要求に対する動作応答も一括して前記第１の通信装置に送信する手段とし、
前記第１の通信装置において、
前記送信手段を、前記第２の通信装置宛ての動作要求に加え、前記仲介装置宛ての動作要求も一括して前記仲介装置に送信する手段とし、
前記受信手段を、前記第２の通信装置宛ての動作要求に対する動作応答に加え、前記仲介装置宛ての動作要求に対する動作応答も一括して前記仲介装置から受信する手段としたことを特徴とする通信システム。
請求項１２又は１３記載の通信システムであって、
前記仲介装置に、前記記憶手段に記憶させた各動作要求について、その要求に関する処理の進行状況を管理し、その進行状況を示す進行情報を記憶する手段を設け、
前記仲介装置の前記一括送信手段が、前記進行情報により要求に係る動作が実行済みであることが示されている動作要求に対する動作応答を前記記憶手段から読み出して前記第１の通信装置に送信する手段であることを特徴とする通信システム。
請求項１２又は１３記載の通信システムであって、
前記動作要求が、優先順位の情報を含むものであり、
前記仲介装置の前記個別送信手段が、前記一括受信手段が受信した動作要求のうち、前記優先順位の高いものから優先的に前記宛先となる第２の通信装置に送信する手段であることを特徴とする通信システム。
第１の通信装置と、複数の第２の通信装置と、該第１の通信装置と各第２の通信装置との間の通信を仲介する仲介装置とを備える通信システムであって、
前記仲介装置に、
前記第１の通信装置からの前記第２の通信装置宛ての動作要求と、該動作要求に対する動作応答とを記憶する記憶手段と、
前記第１の通信装置から、複数の前記動作要求を一括して受信する一括受信手段と、
該一括受信手段が受信した各動作要求を、動作要求毎に分割して前記記憶手段に記憶させる分配手段と、
前記動作要求を前記記憶手段から読み出すと共に、読み出した各動作要求を、その動作要求に含まれる宛先情報に従って宛先となる第２の通信装置に送信する個別送信手段と、
前記各第２の通信装置から、前記動作応答を受信すると共に、受信した動作応答を、その動作応答と対応する動作要求と関連付けて前記記憶手段に記憶させる個別受信手段と、
前記動作応答を前記記憶手段から読み出す収集手段と、
前記第１の通信装置に対して、前記収集手段が読み出した複数の動作応答を、それぞれ対応する動作要求を特定する情報を含んだ状態で一括して送信する一括送信手段とを設け、
前記第１の通信装置に、
前記動作要求と前記動作応答とを記憶する記憶手段と、
前記動作要求を生成して前記記憶手段に記憶させる要求生成手段と、
前記動作要求を前記記憶手段から読み出す収集手段と、
前記仲介装置に対して、前記収集手段が読み出した複数の動作要求を一括して送信する送信手段と、
前記仲介装置から、前記動作応答を、それぞれ対応する動作要求を特定する情報を含んだ状態で複数一括して受信する受信手段と、
該受信手段が受信した各動作応答を、それぞれの動作応答と対応する動作要求と関連付けて前記第２の記憶手段に記憶させる分配手段とを設け、
前記各第２の通信装置に、
前記動作要求を前記仲介装置から受信する受信手段と、
該手段が受信した動作要求に係る動作を実行し、実行結果としてその動作要求に対する動作応答であってその動作要求を特定する情報を含む動作応答を生成する手段と、
該手段が生成した動作応答を前記仲介装置に送信する送信手段とを設けたことを特徴とする通信システム。
第１の通信装置と、複数の第２の通信装置と、該第１の通信装置と各第２の通信装置との間の通信を仲介する仲介装置とを備える通信システムであって、
前記仲介装置に、
記憶手段と、
前記第１の通信装置から、前記第２の通信装置宛ての複数のＳＯＡＰリクエストを１通の電子メールに記載した状態で受信するとともに、前記記憶手段に記憶させる一括受信手段と、
該一括受信手段が受信した各ＳＯＡＰリクエストを、該各ＳＯＡＰリクエストに含まれる宛先情報に従って宛先となる第２の通信装置に送信する個別送信手段と、
前記各第２の通信装置から、前記第１の通信装置からのＳＯＡＰリクエストに対するＳＯＡＰレスポンスを受信するとともに、そのＳＯＡＰレスポンスと対応するＳＯＡＰリクエストと関連付けて前記記憶手段に記憶させる個別受信手段と、
前記記憶手段に記憶された各ＳＯＡＰレスポンスを、それぞれ対応するＳＯＡＰリクエストを特定する情報を含んだ状態で１通の電子メールに記載して前記第１の通信装置に送信する一括送信手段とを設け、
前記第１の通信装置に、
前記第２の通信装置宛ての複数のＳＯＡＰリクエストを１通の電子メールに記載して前記仲介装置に送信する送信手段と、
前記第２の通信装置宛てのＳＯＡＰリクエストに対するＳＯＡＰレスポンスを複数、それぞれ対応するＳＯＡＰリクエストを特定する情報を含んだ状態かつ１通の電子メールに記載した状態で前記仲介装置から受信する受信手段とを設け、
前記各第２の通信装置に、
前記第１の通信装置からの当該第２の通信装置宛てのＳＯＡＰリクエストを前記仲介装置から受信する受信手段と、
該手段が受信したＳＯＡＰリクエストによって要求された動作を実行し、そのＳＯＡＰリクエストに対するＳＯＡＰレスポンスに記載すべき実行結果を生成する手段と、
該手段が生成した実行結果を、前記ＳＯＡＰリクエストに対するＳＯＡＰレスポンスであって前記ＳＯＡＰリクエストを特定する情報を含むＳＯＡＰレスポンスに記載して前記仲介装置に送信する送信手段とを設けたことを特徴とする通信システム。
請求項１７記載の通信システムであって、
前記ＳＯＡＰリクエスト及びＳＯＡＰレスポンスがそれぞれ、形式を変更せずに複数結合して転送可能な１つのメッセージを生成することができる形式で表現され、また複数結合された状態では形式を変更せずに分割して転送可能な個々のＳＯＡＰリクエスト及びＳＯＡＰレスポンスに戻すことができる形式で表現されていることを特徴とする通信システム。
請求項１７又は１８記載の通信システムであって、
前記仲介装置に、当該仲介装置宛てのＳＯＡＰリクエストによって要求された動作を実行し、そのＳＯＡＰリクエストに対するＳＯＡＰレスポンスに記載すべき実行結果を生成する手段を設け、
該仲介装置において、
前記一括受信手段を、前記第１の通信装置から、前記第２の通信装置宛てのＳＯＡＰリクエストに加え、当該仲介装置宛てのＳＯＡＰリクエストも１通の電子メールに記載した状態で受信する手段とし、
前記一括送信手段を、前記第２の通信装置から受信した各ＳＯＡＰレスポンスに加え、前記第１の通信装置からの当該仲介装置宛てのＳＯＡＰリクエストに対するＳＯＡＰレスポンスも１通の電子メールに記載して前記第１の通信装置に送信する手段とし、
前記第１の通信装置において、
前記送信手段を、前記第２の通信装置宛てのＳＯＡＰリクエストに加え、前記仲介装置宛てのＳＯＡＰリクエストも１通の電子メールに記載して前記仲介装置に送信する手段とし、
前記受信手段を、前記第２の通信装置宛てのＳＯＡＰリクエストに対するＳＯＡＰレスポンスに加え、前記仲介装置宛てのＳＯＡＰリクエストに対するＳＯＡＰレスポンスも１通の電子メールに記載した状態で前記仲介装置から受信する手段としたことを特徴とする通信システム。
第１の通信装置と、複数の第２の通信装置と、該第１の通信装置と各第２の通信装置との間の通信を仲介する仲介装置とを備える通信システムであって、
前記仲介装置に、
前記第１の通信装置からの前記第２の通信装置宛ての動作要求と、該動作要求に対する動作応答とを記憶する記憶手段と、
前記第１の通信装置から、前記動作要求の内容を記載した複数のＳＯＡＰリクエストを１通の電子メールに記載した状態で受信する一括受信手段と、
該一括受信手段が受信した各ＳＯＡＰリクエストに記載された動作要求の内容を、動作要求毎に分割して前記記憶手段に記憶させる分配手段と、
前記動作要求を前記記憶手段から読み出すと共に、読み出した各動作要求の内容を記載したＳＯＡＰリクエストを、その動作要求に含まれる宛先情報に従って宛先となる第２の通信装置に送信する個別送信手段と、
前記各第２の通信装置から、前記動作応答の内容を記載したＳＯＡＰレスポンスを受信すると共に、受信したＳＯＡＰレスポンスに記載された動作応答の内容を、その動作応答と対応する動作要求と関連付けて前記記憶手段に記憶させる個別受信手段と、
前記動作応答を前記記憶手段から読み出す収集手段と、
前記第１の通信装置に対して、前記収集手段が読み出した動作応答の内容を記載した複数のＳＯＡＰレスポンスを、それぞれ対応するＳＯＡＰリクエストを特定する情報を含んだ状態で１通の電子メールに記載して送信する一括送信手段と、
を設け、
前記第１の通信装置に、
前記動作要求と前記動作応答とを記憶する記憶手段と、
前記動作要求を生成して前記記憶手段に記憶させる要求生成手段と、
前記動作要求を前記記憶手段から読み出す収集手段と、
前記仲介装置に対して、前記収集手段が読み出した動作要求の内容を記載した複数のＳＯＡＰリクエストを１通の電子メールに記載して送信する送信手段と、
前記仲介装置から、前記動作応答の内容を記載したＳＯＡＰレスポンスを複数、それぞれ対応するＳＯＡＰリクエストを特定する情報を含んだ状態かつ１通の電子メールに記載した状態で受信する受信手段と、
前記受信手段が受信したＳＯＡＰレスポンスに記載された各動作応答の内容を、それぞれの動作応答と対応する動作要求と関連付けて前記記憶手段に記憶させる分配手段とを設け、
前記各第２の通信装置に、
前記第１の通信装置からの当該第２の通信装置宛てのＳＯＡＰリクエストを前記仲介装置から受信する受信手段と、
該手段が受信したＳＯＡＰリクエストによって要求された動作を実行し、そのＳＯＡＰリクエストに対するＳＯＡＰレスポンスに記載すべき実行結果を生成する手段と、
該手段が生成した実行結果を、前記ＳＯＡＰリクエストに対するＳＯＡＰレスポンスであって前記ＳＯＡＰリクエストを特定する情報を含むＳＯＡＰレスポンスに記載して前記仲介装置に送信する送信手段とを設けたことを特徴とする通信システム。
第１の通信装置と複数の第２の通信装置との間の通信を仲介する仲介装置の制御方法であって、
前記第１の通信装置から、前記第２の通信装置宛ての複数の動作要求を一括して受信するとともに、前記仲介装置の記憶手段に記憶させる一括受信手順と、
該一括受信手順で受信した各動作要求を、該各動作要求に含まれる宛先情報に従って宛先となる第２の通信装置に送信する個別送信手順と、
前記各第２の通信装置から、前記第１の通信装置からの動作要求に対する動作応答を受信するとともに、その動作応答と対応する動作要求と関連付けて前記記憶手段に記憶させる個別受信手順と、
前記記憶手段に記憶された各動作応答を、それぞれ対応する動作要求を特定する情報を含んだ状態で一括して前記第１の通信装置に送信する一括送信手順とを前記仲介装置に実行させることを特徴とする仲介装置の制御方法。
請求項２１記載の仲介装置の制御方法であって、
前記動作要求及び動作応答をそれぞれ、形式を変更せずに複数結合して転送可能な１つのメッセージを生成することができる形式で表現し、また複数結合された状態では形式を変更せずに分割して転送可能な個々の動作要求及び動作応答に戻すことができる形式で表現することを特徴とする仲介装置の制御方法。
請求項２１又は２２記載の仲介装置の制御方法であって、
当該仲介装置宛ての動作要求に係る動作を実行し、実行結果としてその動作要求に対する動作応答を生成する手順をさらに前記仲介装置に実行させ、
前記一括受信手順において、前記第１の通信装置から、前記第２の通信装置宛ての動作要求に加え、当該仲介装置宛ての動作要求も一括して受信するようにし、
前記一括送信手順において、前記第２の通信装置から受信した各動作応答に加え、前記第１の通信装置からの当該仲介装置宛ての動作要求に対する動作応答も一括して前記第１の通信装置に送信するようにしたことを特徴とする仲介装置の制御方法。
請求項２１又は２２記載の仲介装置の制御方法であって、
前記仲介装置にさらに、前記記憶手段に記憶させた各動作要求について、その要求に関する処理の進行状況を管理し、その進行状況を示す進行情報を記憶する手順を実行させ、
前記一括送信手順が、前記進行情報により要求に係る動作が実行済みであることが示されている動作要求に対する動作応答を前記記憶手段から読み出して前記第１の通信装置に送信する手順であることを特徴とする仲介装置の制御方法。
請求項２１又は２２記載の仲介装置の制御方法であって、
前記動作要求が、優先順位の情報を含むものであり、
前記個別送信手順が、前記一括受信手順で受信した動作要求のうち、前記優先順位の高いものから優先的に前記宛先となる第２の通信装置に送信する手順であることを特徴とする仲介装置の制御方法。
第１の通信装置と複数の第２の通信装置との間の通信を仲介する仲介装置の制御方法であって、
前記第１の通信装置からの前記第２の通信装置宛ての動作要求と、該動作要求に対する動作応答とを記憶する記憶領域を設ける手順と、
前記第１の通信装置から、複数の前記動作要求を一括して受信する一括受信手順と、
該一括受信手順で受信した各動作要求を、動作要求毎に分割して前記記憶領域に記憶させる分配手順と、
前記動作要求を前記記憶領域から読み出すと共に、読み出した各動作要求を、その動作要求に含まれる宛先情報に従って宛先となる第２の通信装置に送信する個別送信手順と、
前記各第２の通信装置から、前記動作応答を受信すると共に、受信した動作応答を、その動作応答と対応する動作要求と関連付けて前記記憶領域に記憶させる個別受信手順と、
前記動作応答を前記記憶領域から読み出す収集手順と、
前記第１の通信装置に対して、前記収集手順で読み出した複数の動作応答を、それぞれ対応する動作要求を特定する情報を含んだ状態で一括して送信する一括送信手順とを前記仲介装置に実行させることを特徴とする仲介装置の制御方法。
第１の通信装置と複数の第２の通信装置との間の通信を仲介する仲介装置の制御方法であって、
前記第１の通信装置から、前記第２の通信装置宛ての複数のＳＯＡＰリクエストを１通の電子メールに記載した状態で受信するとともに、前記仲介装置の記憶手段に記憶させる一括受信手順と、
該一括受信手順で受信した各ＳＯＡＰリクエストを、該各ＳＯＡＰリクエストに含まれる宛先情報に従って宛先となる第２の通信装置に送信する個別送信手順と、
前記各第２の通信装置から、前記第１の通信装置からのＳＯＡＰリクエストに対するＳＯＡＰレスポンスを受信するとともに、そのＳＯＡＰレスポンスと対応するＳＯＡＰリクエストと関連付けて前記記憶手段に記憶させる個別受信手順と、
前記記憶手段に記憶された各ＳＯＡＰレスポンスを、それぞれ対応するＳＯＡＰリクエストを特定する情報を含んだ状態で１通の電子メールに記載して前記第１の通信装置に送信する一括送信手順とを前記仲介装置に実行させることを特徴とする仲介装置の制御方法。
請求項２７記載の仲介装置の制御方法であって、
前記ＳＯＡＰリクエスト及びＳＯＡＰレスポンスをそれぞれ、形式を変更せずに複数結合して転送可能な１つのメッセージを生成することができる形式で表現し、また複数結合された状態では形式を変更せずに分割して転送可能な個々のＳＯＡＰリクエスト及びＳＯＡＰレスポンスに戻すことができる形式で表現することを特徴とする仲介装置の制御方法。
請求項２７又は２８記載の仲介装置の制御方法であって、
当該仲介装置宛てのＳＯＡＰリクエストによって要求された動作を実行し、そのＳＯＡＰリクエストに対するＳＯＡＰレスポンスに記載すべき実行結果を生成する手順をさらに前記仲介装置に実行させ、
前記一括受信手順において、前記第１の通信装置から、前記第２の通信装置宛てのＳＯＡＰリクエストに加え、当該仲介装置宛てのＳＯＡＰリクエストも１通の電子メールに記載した状態で受信するようにし、
前記一括送信手順において、前記第２の通信装置から受信した各ＳＯＡＰレスポンスに加え、前記第１の通信装置からの当該仲介装置宛てのＳＯＡＰリクエストに対するＳＯＡＰレスポンスも１通の電子メールに記載して前記第１の通信装置に送信するようにしたことを特徴とする仲介装置の制御方法。
第１の通信装置と複数の第２の通信装置との間の通信を仲介する仲介装置の制御方法であって、
前記第１の通信装置からの前記第２の通信装置宛ての動作要求と、該動作要求に対する動作応答とを記憶する記憶領域を設ける手順と、
前記第１の通信装置から、前記動作要求の内容を記載した複数のＳＯＡＰリクエストを１通の電子メールに記載した状態で受信する一括受信手順と、
該一括受信手順で受信した各ＳＯＡＰリクエストに記載された動作要求の内容を、動作要求毎に分割して前記記憶領域に記憶させる分配手順と、
前記動作要求を前記記憶領域から読み出すと共に、読み出した各動作要求の内容を記載したＳＯＡＰリクエストを、その動作要求に含まれる宛先情報に従って宛先となる第２の通信装置に送信する個別送信手順と、
前記各第２の通信装置から、前記動作応答の内容を記載したＳＯＡＰレスポンスを受信すると共に、受信したＳＯＡＰレスポンスに記載された動作応答の内容を、その動作応答と対応する動作要求と関連付けて前記記憶領域に記憶させる個別受信手順と、
前記動作応答を前記記憶領域から読み出す収集手順と、
前記第１の通信装置に対して、前記収集手順で読み出した動作応答の内容を記載した複数のＳＯＡＰレスポンスを、それぞれ対応するＳＯＡＰリクエストを特定する情報を含んだ状態で１通の電子メールに記載して送信する一括送信手順とを前記仲介装置に実行させることを特徴とする仲介装置の制御方法。
コンピュータを、第１の通信装置と複数の第２の通信装置との間の通信を仲介する仲介装置として機能させるためのプログラムであって、
前記コンピュータを、
記憶手段と、
前記第１の通信装置から、前記第２の通信装置宛ての複数の動作要求を一括して受信するとともに、前記記憶手段に記憶させる一括受信手段と、
該一括受信手段が受信した各動作要求を、該各動作要求に含まれる宛先情報に従って宛先となる第２の通信装置に送信する個別送信手段と、
前記各第２の通信装置から、前記第１の通信装置からの動作要求に対する動作応答を受信するとともに、その動作応答と対応する動作要求と関連付けて前記記憶手段に記憶させる個別受信手段と、
前記記憶手段に記憶された各動作応答を、それぞれ対応する動作要求を特定する情報を含んだ状態で一括して前記第１の通信装置に送信する一括送信手段として機能させるためのプログラム。
請求項３１記載のプログラムであって、
前記動作要求及び動作応答をそれぞれ、形式を変更せずに複数結合して転送可能な１つのメッセージを生成することができる形式で表現し、また複数結合された状態では形式を変更せずに分割して転送可能な個々の動作要求及び動作応答に戻すことができる形式で表現するようにしたことを特徴とするプログラム。
請求項３２又は３３記載のプログラムであって、
前記コンピュータを、前記仲介装置宛ての動作要求に係る動作を実行し、実行結果としてその動作要求に対する動作応答を生成する手段として機能させるためのプログラムを含み、
前記一括受信手段の機能を、前記第１の通信装置から、前記第２の通信装置宛ての動作要求に加え、前記仲介装置宛ての動作要求も一括して受信する機能とし、
前記一括送信手段の機能を、前記第２の通信装置から受信した各動作応答に加え、前記第１の通信装置からの前記仲介装置宛ての動作要求に対する動作応答も一括して前記第１の通信装置に送信する機能としたことを特徴とするプログラム。
請求項３１又は３２記載のプログラムであって、
前記コンピュータをさらに、前記記憶手段に記憶させた各動作要求について、その要求に関する処理の進行状況を管理し、その進行状況を示す進行情報を記憶する手段として機能させるためのプログラムを含み、
前記一括送信手段の機能を、前記進行情報により要求に係る動作が実行済みであることが示されている動作要求に対する動作応答を前記記憶手段から読み出して前記第１の通信装置に送信する機能としたことを特徴とするプログラム。
請求項３１又は３２記載のプログラムであって、
前記動作要求が、優先順位の情報を含むものであり、
前記個別送信手段の機能が、前記一括受信手段が受信した動作要求のうち、前記優先順位の高いものから優先的に前記宛先となる第２の通信装置に送信する機能であることを特徴とするプログラム。
コンピュータを、第１の通信装置と複数の第２の通信装置との間の通信を仲介する仲介装置として機能させるためのプログラムであって、
前記コンピュータを、
前記第１の通信装置からの前記第２の通信装置宛ての動作要求と、該動作要求に対する動作応答とを記憶する記憶手段と、
前記第１の通信装置から、複数の前記動作要求を一括して受信する一括受信手段と、
該一括受信手段が受信した各動作要求を、動作要求毎に分割して前記記憶手段に記憶させる分配手段と、
前記動作要求を前記記憶手段から読み出すと共に、読み出した各動作要求を、その動作要求に含まれる宛先情報に従って宛先となる第２の通信装置に送信する個別送信手段と、
前記各第２の通信装置から、前記動作応答を受信すると共に、受信した動作応答を、その動作応答と対応する動作要求と関連付けて前記記憶手段に記憶させる個別受信手段と、
前記動作応答を前記記憶手段から読み出す収集手段と、
前記第１の通信装置に対して、前記収集手段が読み出した複数の動作応答を、それぞれ対応する動作要求を特定する情報を含んだ状態で一括して送信する一括送信手段として機能させるためのプログラム。
コンピュータを、第１の通信装置と複数の第２の通信装置との間の通信を仲介する仲介装置として機能させるためのプログラムであって、
前記コンピュータを、
記憶手段と、
前記第１の通信装置から、前記第２の通信装置宛ての複数のＳＯＡＰリクエストを１通の電子メールに記載した状態で受信するとともに、前記記憶手段に記憶させる一括受信手段と、
該一括受信手段が受信した各ＳＯＡＰリクエストを、該各ＳＯＡＰリクエストに含まれる宛先情報に従って宛先となる第２の通信装置に送信する個別送信手段と、
前記各第２の通信装置から、前記第１の通信装置からのＳＯＡＰリクエストに対するＳＯＡＰレスポンスを受信するとともに、そのＳＯＡＰレスポンスと対応するＳＯＡＰリクエストと関連付けて前記記憶手段に記憶させる個別受信手段と、
前記記憶手段に記憶された各ＳＯＡＰレスポンスを、それぞれ対応するＳＯＡＰリクエストを特定する情報を含んだ状態で１通の電子メールに記載して前記第１の通信装置に送信する一括送信手段として機能させるためのプログラム。
請求項３７記載のプログラムであって、
前記ＳＯＡＰリクエスト及びＳＯＡＰレスポンスをそれぞれ、形式を変更せずに複数結合して転送可能な１つのメッセージを生成することができる形式で表現し、また複数結合された状態では形式を変更せずに分割して転送可能な個々のＳＯＡＰリクエスト及びＳＯＡＰレスポンスに戻すことができる形式で表現するようにしたことを特徴とするプログラム。
請求項３７又は３８記載のプログラムであって、
前記コンピュータを、前記仲介装置宛てのＳＯＡＰリクエストによって要求された動作を実行し、そのＳＯＡＰリクエストに対するＳＯＡＰレスポンスに記載すべき実行結果を生成する手段として機能させるためのプログラムを含み、
前記一括受信手段の機能を、前記第１の通信装置から、前記第２の通信装置宛てのＳＯＡＰリクエストに加え、前記仲介装置宛てのＳＯＡＰリクエストも１通の電子メールに記載した状態で受信する機能とし、
前記一括送信手段の機能を、前記第２の通信装置から受信した各ＳＯＡＰレスポンスに加え、前記第１の通信装置からの前記仲介装置宛てのＳＯＡＰリクエストに対するＳＯＡＰレスポンスも１通の電子メールに記載して前記第１の通信装置に送信する機能としたことを特徴とするプログラム。
コンピュータを、第１の通信装置と複数の第２の通信装置との間の通信を仲介する仲介装置として機能させるためのプログラムであって、
前記コンピュータを、
前記第１の通信装置からの前記第２の通信装置宛ての動作要求と、該動作要求に対する動作応答とを記憶する記憶手段と、
前記第１の通信装置から、前記動作要求の内容を記載した複数のＳＯＡＰリクエストを１通の電子メールに記載した状態で受信する一括受信手段と、
該一括受信手段が受信した各ＳＯＡＰリクエストに記載された動作要求の内容を、動作要求毎に分割して前記記憶手段に記憶させる分配手段と、
前記動作要求を前記記憶手段から読み出すと共に、読み出した各動作要求の内容を記載したＳＯＡＰリクエストを、その動作要求に含まれる宛先情報に従って宛先となる第２の通信装置に送信する個別送信手段と、
前記各第２の通信装置から、前記動作応答の内容を記載したＳＯＡＰレスポンスを受信すると共に、受信したＳＯＡＰレスポンスに記載された動作応答の内容を、その動作応答と対応する動作要求と関連付けて前記記憶手段に記憶させる個別受信手段と、
前記動作応答を前記記憶手段から読み出す収集手段と、
前記第１の通信装置に対して、前記収集手段が読み出した動作応答の内容を記載した複数のＳＯＡＰレスポンスを、それぞれ対応するＳＯＡＰリクエストを特定する情報を含んだ状態で１通の電子メールに記載して送信する一括送信手段として機能させるためのプログラム。
請求項３１乃至４０のいずれか一項記載のプログラムを記録したコンピュータ読み取り可能な記録媒体。