JP2006134110A - 通信システム及び通信装置 - Google Patents

Abstract

【課題】 サーバ装置に対する問合せを効率的に実行して、ネットワークトラフィックを抑えること。
【解決手段】 クライアント装置としての複合機１０は、機能サーバ３０が提供する複数種のサービスの内、自装置が受けるサービス毎に、そのサービスの問合せ時期を示す情報として、問合せ間隔情報と、残り時間情報と、即時の問合せの要否を表す即時処理情報と、を記憶しており、これらの情報に基づいて、自装置が機能サーバ３０から受けるサービス毎に、定期問合せ信号の送信時期が到来したか否かを判断する。そして、送信時期が到来したと判断すると（Ｓ９０６でＹｅｓ）、上記送信時期が到来したと判断したサービスの識別情報としてのリクエストサービスＩＤを、まとめて記述した統合問合せ情報を生成し、統合問合せ情報を格納した定期問合せ信号を、機能サーバ３０に向けて送信する（Ｓ９１１）。
【選択図】 図１９

Description

本発明は、サービスを提供するサーバ装置と、このサービスを受けるクライアント装置と、を備える通信システム、及び、クライアント装置として機能する通信装置に関する。

従来、サービスを提供するサーバ装置としては、クライアント装置からの要求があると、クライアント装置にサービスに関するデータを送信し、サービスを提供するもの（情報提供サービス等）や、クライアント装置からサービスに関するデータを取得して、これを処理することにより、そのデータ処理に係るサービスを提供するものが知られている。

一方、クライアント装置としては、ウェブデータをサーバ装置に送信することにより、ウェブデータをウェブ上で公開するサービスを受けたり、サーバ装置が有するウェブデータを受信し、これを表示することにより、ウェブサービスを受けるものが知られている。

また、情報提供サービスを受けるクライアント装置としては、サーバ装置に対し、定期的に問合せを行うことによって、新しい情報がサーバ装置にあるか否か判断し、新しい情報がある場合には、サーバ装置から、その情報を取得するものが知られている（非特許文献１参照）。

その他、サーバ装置からクライアント装置へサービスを提供するシステムとしては、ディジタル複写機が備えていない機能を、ネットワークを介してディジタル複写機に接続されたホストコンピュータに設け、その機能をホストコンピュータにて実現し、処理結果をディジタル複写機に与えるようにしたシステムが知られている（特許文献１参照）。
特開平９−２３８２１５号公報 "ＲＳＳリーダー Ｒａｂｂｉｔ Ｔｉｃｋｅｒ"、［online］、［平成１６年１０月２０日検索］、インターネット＜ＵＲＬ：http://www.work-at.co.jp/rabbit/＞

ところで、広域ネットワーク（インターネット）と、その広域ネットワークに接続されるＬＡＮ（ローカルエリアネットワーク）との間には、一般的に、ネットワークトラフィックの効率化やセキュリティ確保を目的として、ルータが設けられる。このようなルータが介在したネットワークにおいては、不要なパケットがＬＡＮ外部に出ないようにされ、又、不要なパケットがＬＡＮ外部から内部に入力されないようにされる。

また、上記のＬＡＮは、外部のサーバ装置等から送信されるデータを、当該ＬＡＮ内の装置から要求したデータに限って、取り込むように構成される。従って、このようなネットワークにおいては、ＬＡＮ外部のサーバ装置から能動的にデータを送信して、ＬＡＮ内部のクライアント装置にデータを提供することができない。即ち、ルータが介在したネットワーク内の装置に対しては、サーバ装置から、インターネットを通じ、能動的に、サービスを提供しようとしても、これらのサービスを、ルータが介在したネットワーク内の装置に提供することができない。

従って、サーバ装置側でクライアント装置に提供可能なサービスがある場合に迅速に、そのサービスをクライアント装置に提供するためのシステムとしては、ポーリング通信を用いたシステムが考えられる。このようなシステムは、常に新しい情報を、クライアント装置に提供するサービスに非常に有効である。

しかしながら、このようなシステムでは、サーバ装置から提供するサービスの種類が増えたり、クライアント装置が増えると、クライアント装置によるポーリング通信の量（各サービスについての問合せ信号の量）が多くなり、ネットワークトラフィックが増大する。また、クライアント装置からのアクセスが増大するため、サーバ装置に対しても、大きな負荷がかかるといった問題がある。

本発明は、こうした問題に鑑みなされたものであり、クライアント装置からのサーバ装置に対する問合せを効率的に行えるようにし、ネットワークトラフィックの増大を抑制することを目的とする。

かかる目的を達成するためになされた請求項１記載の通信システムは、複数種のサービスを提供するサーバ装置と、サーバ装置と通信するための通信デバイスを有し、サーバ装置との通信によって、サーバ装置が提供するサービスを受けるクライアント装置と、を有する。

この通信システムにおけるサーバ装置は、クライアント装置から送信される上記複数種のサービスに関する問合せ信号を受信する受信手段を有すると共に、受信手段が問合せ信号を受信すると、その問合せ信号に含まれるサービスの識別情報に基づき、問合せ対象のサービスについての返答情報を生成し、この返答情報を格納した応答信号を、問合せ元のクライアント装置に向けて送信する返信手段を有する。

一方、クライアント装置は、サーバ装置が提供する複数種のサービスの内、自装置がサーバ装置から受けるサービス毎に、そのサービスの問合せ時期を示す情報を記憶する記憶手段を有する。このクライアント装置は、記憶手段が記憶する各サービスの問合せ時期を示す情報に基づき、自装置がサーバ装置から受けるサービス毎に、問合せ信号の送信時期が到来したか否かを、時期判断手段にて判断し、時期判断手段により送信時期が到来したと判断されると、問合せ手段にて、上記送信時期が到来したと判断されたサービスの識別情報を、問合せ対象のサービスの識別情報として格納した問合せ信号を生成し、この問合せ信号を、上記通信デバイスを通じてサーバ装置に向けて送信する。また、クライアント装置は、問合せ手段により送信された問合せ信号に対する応答信号を、上記通信デバイスを介してサーバ装置から受信する受信手段を備える。

この他、本発明の特徴として、クライアント装置が備える問合せ手段は、時期判断手段により送信時期が到来したと判断されたサービスが複数ある場合、送信時期が到来したと判断された各サービスの識別情報を、問合せ対象のサービスの識別情報として、まとめて記述した統合問合せ情報を生成し、この統合問合せ情報を格納した問合せ信号を、サーバ装置に向けて送信する。

上述したように、請求項１記載の通信システムでは、複数の問合せ対象がある場合、問合せ手段が、これらの問合せを示す情報をまとめて問合せ信号に格納し送信する。このため、本発明の通信システムによれば、各サービスについて個々に問合せ信号を生成し、これをサーバ装置に送信するよりも、ネットワークトラフィックを抑えることができ、効率的に問合せを行うことができる。

即ち、問合せ信号には、宛先やプロトコル等を表すヘッダ情報が含まれるため、各サービスに対して問合せ信号を送信する場合には、ヘッダ情報を、問合せ毎に、繰返しネットワークに送出することになる。しかしながら、本発明のように、統合問合せ情報を生成し問合せ信号をサーバ装置に送信すれば、問合せに伴うヘッダ情報の送出量を抑えることができ、ネットワーク内の通信量を抑えることができる。

また、ネットワーク経由で、問合せ信号をサーバ装置に送信する場合には、ルータ等で信号中継が行われるため、問合せ対象のサービス毎に問合せ信号を送信すると、サービスの量が増大した場合、ルータ等に大きな負荷がかかる。しかしながら、本発明によれば、統合問合せ情報を生成して問合せ信号を送信するので、問合せ信号の量を抑えることができ、ルータ等にかかる負荷を抑えることができる。

その他、上記ネットワークがＩＰ（インターネットプロトコル）ネットワークである場合には、サーバ装置の宛先を表す情報として、ＵＲＬ情報が用いられる場合がある。この場合には、サーバ装置に対し問合せ信号を送信するために、サーバ装置のＵＲＬに対応するＩＰアドレスを、ＤＮＳ（Ｄｏｍａｉｎ Ｎａｍｅ Ｓｙｓｔｅｍ）サーバに問合せ、サーバ装置のＩＰアドレスを取得する必要がある。しかしながら、これを個々のサービスに対する問合せ毎に実行すると、ＤＮＳサーバに大きな負荷がかかる。

これに対し、本発明の通信システムでは、同一のサーバ装置に対する複数の問合せをまとめるため、ＤＮＳサーバへのアクセス回数を抑えることができ、結果として、ＤＮＳサーバにかかる負荷を抑えることができる。

尚、各サービスに対する問合せに際しては、問合せ時刻が到来しても一定時間、問合せを猶予（保留）し、猶予した複数のサービスに対する問合せを、一度にまとめて実行するとよいが、サービスによっては、問合せ時刻が到来した場合に、直ちに問合せをしたほうがよい場合もある。

従って、上記の通信システムにおいては、即時の問合せが必要のないサービスについては、その問合せを一定期間猶予（保留）し、即時の問合せが必要なサービスについては、その問合せを即時実行するように、クライアント装置を構成するとよい（請求項２）。

請求項２記載の通信システムにおけるクライアント装置の記憶手段は、サーバ装置から受けるサービス毎に、そのサービスの問合せ時期を示す情報として、次回の問合せ時刻を表す時間情報と、即時の問合せが必要か否かを表す即時要否情報と、記憶しており、上記時期判断手段には、第一〜第三判断手段が設けられている。

第一判断手段は、記憶手段が記憶する各サービスの時間情報に基づき、自装置がサーバ装置から受けるサービス毎に、問合せ時刻が到来したか否かを判断する。一方、第二判断手段は、記憶手段が記憶する各サービスの即時要否情報に基づき、自装置がサーバ装置から受けるサービス毎に、即時の問合せが必要か否かを判断する。また、第三判断手段は、予め定められた問合せの実行猶予期間が経過したか否かを判断する。

時期判断手段は、これら第一〜第三判断手段の判断結果に基づき、第一判断手段により問合せ時刻が到来したと判断されたサービスが存在しない場合、又は、第二判断手段により即時の問合せが必要であると判断されたサービスが存在せず、第三判断手段により実行猶予期間が経過していないと判断されている場合、自装置がサーバ装置から受ける全サービスについて、問合せ信号の送信時期が到来していないと判断する。

一方、第一判断手段により問合せ時刻が到来したと判断され且つ第二判断手段により即時の問合せが必要であると判断されたサービスが存在する場合、又は、第一判断手段により問合せ時刻が到来したと判断されたサービスが存在し且つ第三判断手段により実行猶予期間が経過したと判断されている場合には、問合せ時刻が到来したと判断されたサービスの全てについて、問合せ信号の送信時期が到来したと判断する。

この通信システムによれば、問合せを保留し、問合せ対象のサービスが複数個となった時点で、これらの問合せをまとめて実行することができると共に、即時の問合せが必要なサービスについては、直ちに、問合せを実行することができる。

尚、上記通信システムにおける問合せの内容は、全サービスについて共通なものであってもよいし、サービス毎に、異なるものであってもよい。また、問合せの内容が、全サービスに共通なものである場合には、問合せ対象のサービスの識別情報をまとめて記述して統合問合せ情報を生成すればよいが、異なる問合せをまとめて行う場合には、請求項３記載のように、通信システムを構成するとよい。

請求項３記載の通信システムにおける記憶手段は、サーバ装置から受けるサービス毎に、そのサービスの問合せ時期を示す情報に関連付けて、問合せ内容を表すパラメータの値を記憶しており、問合せ手段は、問合せ対象のサービスの識別情報と共に、その問合せ対象のサービスについて記憶手段が記憶する上記問合せ内容を表すパラメータの値を、問合せ対象のサービスの識別情報に関連付けて、問合せ信号に格納する。

このように、各サービスの識別情報とパラメータの値とを関連付けて、問合せ信号に格納すれば、異なる問合せをまとめて実行することができる。
また、この通信システムにおいては、時期判断手段により送信時期が到来したと判断されたサービスが複数ある場合、問合せ対象のサービスの識別情報を、記憶手段が記憶する上記問合せ内容を表すパラメータの値が同一であるサービスの識別情報毎にまとめて記述し、まとめて記述したパラメータの値が同一である問合せ対象のサービスの識別情報の一群に対し、上記パラメータの値を関連付けて記述して、統合問合せ情報を生成するように、上記問合せ手段を構成するとよい（請求項４）。

この通信システムによれば、問合せ対象のサービスの一群のうち、同一内容の問合せを行うサービスについては、パラメータの値を複数回記述する必要がないので、効率的に問合せを行うことができる。即ち、この通信システムによれば、問合せ対象のサービスの識別情報と、問合せ内容を表すパラメータとを関連付ける際の冗長な記述を抑えることができ、統合問合せ情報のデータ量を抑えることができる。従って、この発明によれば、一層、ネットワークトラフィックを抑えることができる。

また、クライアント装置が、上記通信デバイスの他に、複数種の入出力デバイスを有し、通信デバイスと、上記複数種の入出力デバイスの一つ又は複数と、を用いて、サーバ装置から提供されるサービスを受ける構成にされている場合には、請求項５記載のように、通信システムを構成するとよい。

即ち、クライアント装置には、時期判断手段により、問合せ信号の送信時期が到来したと判断されたサービス毎に、そのサービスを受けるために駆動が必要な入出力デバイスが動作中であるか否かを判断するデバイス動作判断手段、を設けて、問合せ手段を、デバイス動作判断手段の判断結果に基づき、送信時期が到来したと判断されたサービスであって、そのサービスを受けるために駆動が必要な入出力デバイスが動作していないサービスがある場合にのみ、入出力デバイスが動作していないサービスの識別情報を選択的に、問合せ対象のサービスの識別情報として、問合せ信号に格納し、この問合せ信号を送信する構成にされるとよい。

クライアント装置が、複数種の入出力デバイスを用いて、サーバ装置から提供されるサービスを受ける構成にされている場合には、クライアント装置が、問合せに対する応答信号に基づいて、サービスを受けるための処理を実行する際に、他のサービス等によって既に入出力デバイスが使用され、サービスを受けるために必要な入出力デバイスを利用することができない場合が予想され、このような場合には、問合せをしても無駄になる可能性がある。従って、請求項５記載のように、入出力デバイスが既に動作中である場合には、問合せをしないようにすると、無駄な問合せをしなくて済み、問合せの効率化が図れる。

また、クライアント装置からサーバ装置への問合せの内容としては、実施の形態によって様々なものが考えられるが、例えば、クライアント装置とサーバ装置との間にルータが介在したネットワークにおいて、クライアント装置から、サービスの提供準備が整っているか否かをサーバ装置に問い合わせ（即ち、ポーリングし）、整っている場合には、その旨の返答情報をサーバ装置からクライアント装置に返して、クライアント装置にサービスを提供する形態を考えた場合には、請求項６，１０記載のように、通信システムを構成するとよい。

請求項６，１０記載の通信システムにおけるサーバ装置の返信手段は、問合せ対象のサービスについて、そのサービスを問合せ元のクライアント装置に提供する準備が完了しているか否かを判断し、サービスを提供する準備が完了していると判断すると、その旨の返答情報を生成して応答信号に格納する構成にされ、クライアント装置は、自装置の受信手段が受信した応答信号に基づいて、応答信号に含まれる返答情報に対応するサービスが、サーバ装置にて提供する準備が完了しているサービスであるか否かを、準備完了判断手段にて判断し、準備完了判断手段により、サーバ装置にて提供する準備が完了していると判断された場合には、その判断対象のサービスを受けるために必要な処理を実行する。

クライアント装置から、サービスの提供準備が整っているか否かをサーバ装置に問い合わる通信システムにおいて、本発明を適用すれば、ネットワークトラフィックを抑え、効率的に問合せを行うことができる。

ところで、上述した通信システムにおいては、問合せ信号と同様に、応答信号に対しても、本発明の概念を適用することができる。
請求項７記載の通信システムにおけるサーバ装置の返信手段は、サーバ装置の受信手段が受信した問合せ信号に、問合せ対象のサービスの識別情報として、複数のサービスの識別情報が格納されている場合、各問合せ対象のサービスについての返答情報を、まとめて記述した統合返答情報を生成し、この統合返答情報を格納した応答信号を、問合せ元の前記クライアント装置に向けて送信する。

この通信システムによれば、各問合せに対して個別に応答信号を生成し、送信するよりも、ネットワークトラフィックを抑えることができ、問合せに対し効率的に応答することができる。尚具体的に、統合返答情報は、問合せ対象のサービス毎に、問合せ対象のサービスについての返答情報と、その返答情報に対応する問合せ対象のサービスの識別情報と、を関連付けてなる情報とすればよい（請求項８）。

また、サービスの識別情報と、返答情報とを関連付けて統合返答情報を生成する際には、問合せ対象のサービスの識別情報毎に、返答情報を記述して統合返答情報を生成してもよいが、同一の返答となるサービスの識別情報をまとめて記述し、その一群に対して単一の返答情報を関連付けることで、統合返答情報を生成すると好ましい。

即ち、上記返信手段は、サーバ装置の受信手段が受信した問合せ信号に、問合せ対象のサービスの識別情報として、複数のサービスの識別情報が格納されている場合、返答情報が同一である問合せ対象のサービスの識別情報を、まとめて記述し、まとめて記述した上記返答情報が同一である問合せ対象のサービスの識別情報の一群に対し、返答情報を関連付けて記述して、統合返答情報を生成する構成にされるとよい（請求項９）。

サービス毎に個別に返答情報を記述した場合には、同一の返答情報が複数回に渡って統合返答情報に記述されることにより情報量が増大するが、本発明のように統合返答情報を生成すれば、情報量を抑えることができ、ネットワークトラフィックを抑えることができる。

尚具体的に、返答情報として、サービスを提供する準備が完了しているか否かを表す情報を、統合返答情報に格納する場合には、提供する準備が完了しているサービスの識別情報をまとめて記述すると共に、提供する準備が完了していないサービスの識別情報をまとめて記述し、更に、各サービスの識別情報の一群に対し、夫々に対応する返答情報を関連付けて、統合返答情報を生成すればよい。

また、返信手段は、問合せに対する返答が、特定の返答となるサービスについての返答情報のみを格納して、応答信号を生成し、送信する構成にされるとよい（請求項１１）。
問合せに対する返答が、例えば、肯定／否定を表す程度の簡単なものである場合には、返答が肯定（又は否定）の場合にのみ、その旨の返答情報を応答信号に格納し、否定（又は肯定）の場合には、返答情報を格納せずに、応答信号を生成するようにしても、クライアント装置側では、返答情報の有無で、問合せに対するサーバ装置の返答を得ることができる。従って、特定の返答情報のみを格納して応答信号を送信するようにすれば、応答信号のデータ量を抑えることができ、ネットワークトラフィックを抑えることができる。

その他、請求項１２記載の通信システムは、クライアント装置が、自装置の受信手段が受信した応答信号に複数の返答情報が含まれ、準備完了判断手段により、サーバ装置にて提供する準備が完了していると判断されたサービスが複数存在する場合、サーバ装置にて提供する準備が完了していると判断された各サービスを受けるために必要な処理を、夫々、並列に実行する構成にされたものである。

この通信システムによれば、クライアント装置がサービスを受けるために必要な処理を並列に実行するので、クライアント装置にて、各サービスを利用した機能を、効率的に実現することができる。即ち、本発明によれば、クライアント装置を通じて、利用者に対し、効率的にサービスを提供することができる。

但し、クライアント装置が、通信デバイスと、自装置内蔵の複数種の入出力デバイスの一つ又は複数と、を用いて、サーバ装置から提供されるサービスを受ける構成にされている場合には、複数のサービスにおいて、使用する入出力デバイスが重複する場合があり、並列に、サービスに係る処理を実行することができない場合がある。従って、複数種の入出力デバイスの一つ又は複数を用いてサービスを受ける場合には、請求項１３記載のように、上記クライアント装置を構成するとよい。

請求項１３記載の通信システムにおけるクライアント装置は、自装置の受信手段が受信した応答信号に複数の返答情報が含まれ、準備完了判断手段により、サーバ装置にて提供する準備が完了していると判断されたサービスが複数存在する場合、使用する入出力デバイスが重複しない各サービスについて、各サービスを受けるために必要な処理を、並列に実行すると共に、使用する入出力デバイスが重複する各サービスについては、順次、各サービスを受けるために必要な処理を実行することを特徴とする。

このように構成された請求項１３記載の通信システムによれば、サーバ装置から提供されるサービスを、クライアント装置側で効率よく受けることができる。
また、クライアント装置は、請求項１４記載のように、複数種の入出力デバイスとして、少なくとも、記録媒体に画像を形成可能な画像形成装置を含む二以上の入出力デバイスを備える構成とすることができる。尚、その他の入出力デバイスとしては、原稿に描写された画像を読み取り画像データに変換可能な画像読取装置、音声を入力可能な音声入力装置、音声を出力可能な音声出力装置等が挙げられる。

その他、請求項１５記載の発明は、複数種のサービスを提供する上述のサーバ装置と通信するための通信デバイスを有し、サーバ装置との通信によって、サーバ装置が提供するサービスを受ける通信装置であって、サーバ装置が提供する複数種のサービスの内、自装置がサーバ装置から受けるサービス毎に、そのサービスの問合せ時期を示す情報を記憶する記憶手段と、記憶手段が記憶する各サービスの問合せ時期を示す情報に基づき、自装置がサーバ装置から受けるサービス毎に、問合せ信号の送信時期が到来したか否かを判断する時期判断手段と、時期判断手段により送信時期が到来したと判断されると、送信時期が到来したと判断されたサービスの識別情報を、問合せ対象のサービスの識別情報として格納した問合せ信号を生成し、この問合せ信号を、サーバ装置に向けて送信する問合せ手段と、問合せ手段により送信された問合せ信号に対する応答信号を、通信デバイスを介してサーバ装置から受信する受信手段と、を有し、時期判断手段により送信時期が到来したと判断されたサービスが複数ある場合、問合せ手段が、上記送信時期が到来したと判断された各サービスの識別情報を、問合せ対象のサービスの識別情報として、まとめて記述した統合問合せ情報を生成し、この統合問合せ情報を格納した問合せ信号を、サーバ装置に向けて送信する構成にされていることを特徴とする。

この通信装置を、上述のクライアント装置として、通信システムに導入すれば、上述した請求項１と同様の効果を得ることができる。尚、この通信装置には、本発明の通信システム（請求項１〜１４）を構成するクライアント装置と同一の構成を適用することができる。

また、サーバ装置が備える各手段としての機能をコンピュータに実現させるためのプログラム及びクライアント装置が備える各手段としての機能をコンピュータに実現するためのプログラムは、コンピュータ読取可能な記録媒体に格納して、提供することができる。

以下、本発明の実施例について、図面と共に説明する。図１は、本発明が適用された通信システム１の構成を表すブロック図である。
本実施例の通信システム１は、複数のディジタル複合機（以下、単に「複合機」とする）１０と、ディレクトリサーバ２０と、機能サーバ３０とを備え、これらは、広域ネットワークＮＴ（具体的にはインターネット）を介して双方向通信可能に接続されている。具体的に、複合機１０、ディレクトリサーバ２０及び機能サーバ３０は、夫々ルータ２，３，４を介して、広域ネットワークＮＴと接続されている。

ルータ２は、複合機１０等から構成される下位ネットワーク（サブネット）のノードと、この下位ネットワークより外部の広域ネットワークＮＴのノードとの間のデータ通信を中継するものである。このルータ２は、外部の広域ネットワークＮＴ内の装置から、下位ネットワーク内の装置（複合機１０等）へ送信されてくるパケットのうち、下位ネットワーク内から外部への要求（リクエスト）に対する返答（レスポンス）を通過させ、それ以外のパケットを遮断する構成にされており、広域ネットワークＮＴから複合機１０に対する不正なアクセスを防止するためのファイアウォールとして機能する。

複合機１０は、電話（音声通信）機能、スキャナ機能、プリンタ機能、コピー機能、ファクシミリ機能等を有する多機能装置として構成されており、上記機能を用いた複数種の入出力機能を、機能サーバ３０から利用可能に構成されている。

機能サーバ３０は、複合機１０からの要求に応じて、上記複数種のサービスの提供に必要な処理（後述する定期サービス提供処理（図２９参照）等）を実行し、要求元の複合機１０に対してサービスを提供する。即ち、複合機１０は、機能サーバ３０と通信して、上記複数種のサービスを受けるための処理（後述するサービス受信処理や出力ジョブ等）を実行し、機能サーバ３０からのサービスを受ける。例えば、複合機１０は、サービスの提供にかかるデータ通信で、機能サーバ３０から得た印刷データを、プリンタ機能（記録部１４）を利用して、印刷出力する。

また、ディレクトリサーバ２０は、各複合機１０が利用可能なサービス（機能サーバ３０が提供可能なサービス）についての情報を、複合機１０へ提供可能に構成されている。
続いて、複合機１０、ディレクトリサーバ２０及び機能サーバ３０の詳細構成を説明する。複合機１０は、制御部１１、操作部１２、読取部１３、記録部１４、通信部１５、記憶部１６、音入力部１７、音出力部１８、及び、表示部１９を備える。制御部１１は、図示しない周知のＣＰＵ、ＲＯＭ、ＲＡＭ等を備え、複合機１０を構成する各部を統括制御する。尚、ＲＯＭには、後述する各種処理をＣＰＵに実行させるためのプログラムが記憶されている。

操作部１２は、利用者が操作可能な複数のキーを備え（図示せず）、これらのキーを介して、利用者の操作情報を取得し、この操作情報（各種指令等）を制御部１１に入力する。また、読取部（スキャナ）１３は、原稿に記録（例えば印刷）された画像を読み取り、この画像を表す画像データを生成する構成にされている。その他、記録部（プリンタ）１４は、印刷データに基づく画像を、用紙等のシート状記録媒体に形成（印刷）する構成にされ、通信デバイスとしての通信部１５は、広域ネットワークＮＴを介して、ディレクトリサーバ２０や機能サーバ３０等のノードとデータを送受信するための電気的な処理を行う構成にされている。

また、記憶部１６は、図示しない不揮発性ＲＡＭを有し、この不揮発性ＲＡＭにデータを記憶する構成にされている。その他、音入力部１７は、複合機１０が備える図示しないハンドセットに設けられたマイクから集音し、その音を表す音データ（ＰＣＭデータ）を生成する構成にされ、音出力部１８は、音データ（ＰＣＭデータ）に基づく音声を、ハンドセットに設けられたスピーカ、又は、複合機１０本体に設けられた図示しないスピーカから出力する構成にされている。また、表示部１９は、ディスプレイ１９ａを備え、このディスプレイ１９ａを介して、利用者に対する情報の表示（図２参照）を行う構成にされている。

次に、ディレクトリサーバ２０について説明する。ディレクトリサーバ２０は、制御部２１、通信部２２、及び、記憶部２３を備える。制御部２１は、図示しない周知のＣＰＵ、ＲＯＭ、ＲＡＭ等を備え、ディレクトリサーバ２０を構成する各部を統括制御する。尚、ＲＯＭには、後述する処理をＣＰＵに実行させるためのプログラムが記憶されている。

通信部２２は、広域ネットワークＮＴを介してデータを送受信するための電気的な処理を行う構成にされており、記憶部２３は、図示しないハードディスクを備え、このハードディスクにデータを記憶する構成にされている。具体的に、記憶部２３には、サービス定義情報２５を記憶するためのサービス定義情報記憶部２４が設けられている。

サービス定義情報２５は、機能サーバ３０が実行可能なサービスについての情報（サービスの種類やサービス要求先のＵＲＬ情報等）を、複合機１０へ提供するためのものである。具体的に、複合機１０の制御部１１は、利用者が操作部１２を操作することにより、操作部１２からサービス選択用画面の表示指令が入力されると、通信部１５を通じて、ディレクトリサーバ２０からサービス定義情報２５を取得する。また、サービス定義情報２５を取得すると、制御部１１は、そのサービス定義情報２５に基づいて、表示部１９のディスプレイ１９ａにサービスの種類を示すサービス選択用画面（図２参照）を表示し、複合機１０の利用者にサービスの選択を促す。

ディレクトリサーバ２０において、機能サーバ３０が実行可能なサービスは、「印刷サービス」、「コピー応用サービス」、「情報提供サービス」等、複数のカテゴリに分類管理されており、サービス選択用画面においては、まず、上記複数のカテゴリが表示される（図２（ａ））。また、利用者が操作部１２を操作することにより、上記複数のカテゴリのいずれかが選択されると、次に、選択されたカテゴリに属するサービスが表示される（図２（ｂ））。

このような処理を実現するため、サービス定義情報記憶部２４には、カテゴリの選択を促すサービス選択用画面（図２（ａ））に対応するサービス定義情報２５（以下「トップのサービス定義情報２５」という。）と、各カテゴリに含まれるサービスの選択を促すサービス選択用画面（図２（ｂ））に対応するサービス定義情報２５とが記憶されている。

図３及び図４は、サービス定義情報２５の構成例を表す説明図である。具体的に、図３は、トップのサービス定義情報２５の構成例を表す図であり、図４は、上記カテゴリの一つである「情報提供サービス」についてのサービス定義情報２５の構成例を表す図である。

図３及び図４に示すように、サービス定義情報２５は、ＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）によって記述されている。尚、ここで用いられる各タグの定義は、表１に示すとおりである。

トップのサービス定義情報２５（図３）が複合機１０で受信されると、ディスプレイ１９ａには、図２（ａ）に示すサービス選択用画面が表示される。具体的には、タイトル（Ｔｉｔｌｅ）として「ディレクトリサービス」の文字がディスプレイ１９ａにおける上部に表示され、その下には、選択可能なカテゴリを表す項目（Ｌｉｎｋ＿Ｔｉｔｌｅ）として、「印刷サービス」、「コピー応用サービス」及び「情報提供サービス」の文字が表示される。

各項目には、カテゴリに対応するサービス定義情報２５のＩＤがそれぞれ対応づけられており（Ｌｉｎｋ＿Ｌｏｃａｔｉｏｎ）、図２（ａ）に示す状態で、操作部１２から項目の選択を確定する信号（操作情報）が入力されると、制御部１１は、選択が確定された項目に対応するＩＤのサービス定義情報２５に基づき、選択されたカテゴリに対応するサービス選択用画面を、表示部１９のディスプレイ１９ａに表示する。

例えば、図２（ａ）に示すサービス選択用画面で「情報提供サービス」が選択されると、ディスプレイ１９ａには、図２（ｂ）に示す情報提供サービスに対応するサービス選択用画面が表示される。具体的には、タイトル（Ｔｉｔｌｅ）として「情報提供サービス」の文字がディスプレイ１９ａにおける上部に表示され、その下には、選択可能なサービスを表す項目（Ｌｉｎｋ＿Ｔｉｔｌｅ）として、「ブログ検索サービス」、「ニュース提供サービス」、「Ｘ種情報提供サービス」、及び、「Ｙ種情報提供サービス」の文字が表示される。尚、ディスプレイ１９ａのサイズの都合上、すべての項目を一度に表示することができない場合には、サービス選択用画面をスクロール可能に構成し、一部の項目を表示する。

各項目には、サービスを呼び出すためのＵＲＬ情報がそれぞれ対応付けられており（Ｌｉｎｋ＿Ｌｏｃａｔｉｏｎ）、利用者が操作部１２を操作することにより、項目の選択が確定されると、制御部１１は、通信部１５を介して、その項目に対応するＵＲＬ先にアクセスし、ＵＲＬ先のサーバ装置（機能サーバ３０）が提供するサービスを受ける。尚、この際、複合機１０は、一旦、ＤＮＳサーバ４０にアクセスして、ＵＲＬ先のＩＰ（インターネットプロトコル）アドレスを取得し、これに基づきＵＲＬ先のＩＰアドレスを把握して、ＵＲＬ先にアクセスする。

次に、機能サーバ３０について説明する。機能サーバ３０は、制御部３１、通信部３２、及び、記憶部３３を備える。制御部３１は、図示しない周知のＣＰＵ、ＲＯＭ、ＲＡＭ等を備えており、機能サーバ３０を構成する各部を統括制御する。尚、ＲＯＭには、後述する各種処理をＣＰＵに実行させるためのプログラムが記憶されている。

通信部３２は、広域ネットワークＮＴを介してデータを送受信するための電気的な処理を行う構成にされており、記憶部３３は、図示しないハードディスクを備え、このハードディスクに、各種データを記憶する構成にされている。具体的に、記憶部３３には、サービスＩ／Ｆ（インタフェース）情報３６を記憶するためのサービスＩ／Ｆ情報記憶部３４や、サービスソフトウェア３７を記憶するためのサービスソフト記憶部３５等が設けられている。

サービスソフトウェア３７は、複数種のサービスを実行するためのプログラムである。サービスソフト記憶部３５には、複数種のサービスソフトウェア３７が記憶されており、制御部３１は、各サービスソフトウェア３７を実行することにより、各サービスソフトウェア３７に対応したサービスを、クライアント装置としての複合機１０に提供する。

また、サービスＩ／Ｆ情報３６は、サービスを実行する際に必要なパラメータ情報を複合機１０へ要求するためのものである。サービスＩ／Ｆ情報記憶部３４には、機能サーバ３０が実行可能な複数種のサービスのそれぞれに対応する複数種類のサービスＩ／Ｆ情報３６が記憶されている。

複合機１０は、このサービスＩ／Ｆ情報３６を受信すると、受信したサービスＩ／Ｆ情報３６に基づいて、設定すべきパラメータを示すパラメータ入力用画面（図５参照）をディスプレイ１９ａに表示し、複合機１０の利用者にパラメータの設定を促す。

ここで、サービスＩ／Ｆ情報３６の具体例について説明する。図６及び図７は、サービスＩ／Ｆ情報３６の構成例を表す説明図である。具体的に、図６は、特定のブログサイトに掲載された新しい投稿の中から、利用者が指定したキーワードを含む投稿を検索し、その投稿内容を表す印刷データを生成して複合機１０の記録部１４に印刷させるというサービス（ブログ検索サービス）に対応するサービスＩ／Ｆ情報３６の構成例を表す図である。また、図７は、特定のデータベースが有するニュースデータの中から、利用者が指定した地域のローカルニュースデータを取得し、この取得情報を表す印刷データを生成して複合機１０の記録部１４に印刷させるというサービス（ローカルニュース提供サービス）に対応するサービスＩ／Ｆ情報３６の構成例を表す図である。

図６及び図７に示すように、サービスＩ／Ｆ情報３６は、上述したサービス定義情報２５と同じマークアップ言語により記述されており、図６及び図７で用いられている各タグの定義は表２に示すとおりである。尚、表２における基本データは、上述したサービス定義情報２５の基本データ（表１）と同じである。

図６に示すサービスＩ／Ｆ情報３６が複合機１０側で受信されると、複合機１０が備えるディスプレイ１９ａには、図５（ａ）に示すパラメータ入力用画面が表示される。具体的には、表示用タイトル（Ｔｉｔｌｅ）として「ブログ検索サービス」の文字がディスプレイ１９ａにおける上部位置に表示され、その下には、入力項目（Ｄｉｓｐ＿Ｎａｍｅ）として「検索キー１」の文字が表示され、更にその下には、入力項目「検索キー１」に対応する検索キーの入力欄が表示される。また、この入力欄には、利用者が操作部１２を通じて入力した文字が表示される。

尚、「ブログ検索サービス」に関する入力項目（Ｄｉｓｐ＿Ｎａｍｅ）としては、「検索キー１」に加え、「検索キー２」及び「検索キー３」が存在するが（図６参照）、ディスプレイ１９ａの大きさの都合上、すべての入力項目を一度にディスプレイ１９ａに表示することができない。

このため、複合機１０では、ディスプレイ１９ａにおける入力項目表示位置の左右両側に左右の矢印（三角印）を表示して、パラメータ入力用画面を左右にスクロール可能に構成する。この状態で、操作部１２を通じて、スクロールの指令が入力されると、ディスプレイ１９ａには、その指令に従って、他の入力項目に対応したパラメータ入力用画面が表示される。尚、入力項目「検索キー２」及び「検索キー３」のパラメータ入力用画面の表示形態は、入力項目「検索キー１」と基本的に同様である。

また、図７に示すサービスＩ／Ｆ情報３６が複合機１０で受信されると、複合機１０が備えるディスプレイ１９ａには、図５（ｂ）に示すパラメータ入力用画面が表示される。
図５（ｂ）に示すパラメータ入力用画面では、表示用タイトル（Ｔｉｔｌｅ）としての「ローカルニュース提供サービス」の文字の下に、入力項目（Ｄｉｓｐ＿Ｎａｍｅ）として「地域」の文字が表示され、更にその下には、入力項目「地域」について選択可能なパラメータの値を表す項目（Ｄｉｓｐ＿Ｓｅｌｅｃｔ）として、「北海道」、「関東」、「東海」等の地域を表す文字が表示される。尚、ディスプレイ１９ａに表示できない項目がある場合には、パラメータ入力用画面を、上下方向にスクロール可能に構成する。

また、「ローカルニュース提供サービス」に関する入力項目（Ｄｉｓｐ＿Ｎａｍｅ）としては、「地域」に加え、「プリペイドカード番号」及び「情報を収める紙の枚数」が存在するが（図７参照）、ディスプレイ１９ａの大きさの都合上、すべての入力項目を一度にディスプレイ１９ａに表示することができない。

このため、複合機１０では、「ブログ検索サービス」と同様、ディスプレイ１９ａにおける入力項目表示位置の左右両側に左右の矢印（三角印）を表示して、パラメータ入力用画面を左右にスクロール可能に構成する。この状態で、操作部１２を通じて、スクロールの指令が入力されると、ディスプレイ１９ａには、その指令に従って、他の入力項目に対応したパラメータ入力用画面が表示される。具体的に、操作部１２を通じて右方向へのスクロールを指示する指令が入力されると、ディスプレイ１９ａには、図５（ｃ）に示すように、入力項目「プリペイドカード番号」についてのパラメータ入力用画面が表示される。

尚、入力項目「プリペイドカード番号」のパラメータ入力用画面では、プリペイドカード番号を入力するための入力欄が表示され、入力欄には、利用者が操作部１２を通じて入力した文字（プリペイドカード番号）が表示される。その他、図示しないが入力項目「情報を収める紙の枚数」のパラメータ入力用画面には、ニュースを印刷する際の紙の枚数を入力するための入力欄が表示される。

また、各パラメータ入力用画面において入力されたパラメータの値（入力欄に入力された文字列も含む）は、利用者の操作により操作部１２を通じて、確定信号が入力されると、これらのパラメータの値を受けて動作するＵＲＬ（Ａｃｔｉｏｎ）先のプログラム（機能サーバ３０が有するプログラム）へ送信される。

次に、複合機１０、ディレクトリサーバ２０及び機能サーバ３０間で行われる通信について説明する。本実施例では、複合機１０、ディレクトリサーバ２０及び機能サーバ３０が互いにデータを送受信するための通信プロトコルとして、ＨＴＴＰ１．１（ＨＴＴＰ：ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）が採用されており、複合機１０、ディレクトリサーバ２０及び機能サーバ３０は、ＨＴＴＰリクエスト及びレスポンスに伴わせたメッセージにより、互いに指令及び指令に対する返答を行う。

指令は、複合機１０から各サーバ２０，３０に対する指令（サーバ指令）と、各サーバ２０，３０から複合機１０に対する指令（複合機指令）とに分類されるが、いずれの指令にかかる通信も、複合機１０が常にＨＴＴＰ通信のクライアント（ＨＴＴＰリクエストを送信する側）となるようにしている。これにより、ルータ２が介在していても、各サーバ２０，３０から複合機１０への指令が遮断されてしまうことはない。

具体的に、複合機１０は、ＨＴＴＰリクエストのＰＯＳＴコマンドに伴わせたメッセージによりディレクトリサーバ２０又は機能サーバ３０に対する指令を送信する。一方、各サーバ２０，３０は、複合機１０からのＨＴＴＰリクエストのＰＯＳＴコマンドに伴わせたメッセージによる問合せに対し、複合機指令があれば、上記問合せに対するＨＴＴＰレスポンスのメッセージに、複合機指令を伴わせて送信する。

次に、複合機１０、ディレクトリサーバ２０及び機能サーバ３０の各制御部１１，２１，３１が行う処理について説明する。まず最初に、複合機１０の制御部１１が行う複合機処理について、図８のフローチャートを用いて説明する。尚、この複合機処理は、複合機１０の電源が投入されると、ただちに開始される。

複合機処理を開始すると、制御部１１は、まずＳ１０１で、複合機１０の初期化処理を行う。続いて、Ｓ１０２では、複合機１０への指令入力を受け付ける。ここで、複合機１０への指令入力とは、複合機１０に何らかの処理を実行させるための入力であり、例えば、操作部１２からのキー入力や、図示しないパーソナルコンピュータからの指令入力等が挙げられる。

続いて、Ｓ１０３では、Ｓ１０２で受けた指令入力が、サービスモードへの移行を指示する指令入力であるか否かを判断する。Ｓ１０３で、サービスモードへの移行を指示する指令入力ではないと判断すると（Ｓ１０３でＮｏ）、制御部１１は、Ｓ１０４へ移行し、Ｓ１０２で受けた入力に応じたその他のモードに対応する処理（例えば、パーソナルコンピュータから入力された印刷データの出力処理）を行い、Ｓ１０２へ移行する。

一方、Ｓ１０３で、指令入力がサービスモードへの移行を指示する入力であると判断すると、制御部１１は、Ｓ１０５へ移行し、機能サーバ３０に要求するサービスを決定する方法として、リストから選択する方法及びサービス要求先のＵＲＬ情報を直接入力する方法のうち、いずれの方法を採用するかを利用者に問い合わせるための選択画面をディスプレイ１９ａに表示する。そして、利用者の指令が操作部１２を通じて入力されるのを待つ。そして、指令が入力されると、その内容に従って、機能サーバ３０に要求するサービスをリストから選択するか否かを判断する。

Ｓ１０５で、機能サーバ３０に要求するサービスをリストから選択すると判断した場合、制御部１１は、Ｓ１０６へ移行し、ディレクトリサーバ２０にサービスの一覧を要求する。具体的には、ディレクトリサーバ２０に対しトップのサービス定義情報２５（図３）の送信を要求する。尚、本実施例において、複合機１０には、トップのサービス定義情報２５を要求するためのＵＲＬ情報が記憶部１６にあらかじめ記憶されている。

Ｓ１０６の処理後、制御部１１は、Ｓ１０６での要求に対してディレクトリサーバ２０から送信されたトップのサービス定義情報２５を、通信部１５を介して受信する（Ｓ１０７）。更に、Ｓ１０８では、Ｓ１０７で受信したサービス定義情報２５に基づくサービス選択用画面を表示部１９のディスプレイ１９ａに表示し（図２（ａ））、Ｓ１１０へ移行する。

一方、Ｓ１０５で、機能サーバ３０に要求するサービスをリストから選択しないと判断した場合には、Ｓ１０９に移行し、ＵＲＬ情報を直接入力するためのアドレス入力画面（図示せず）を表示部１９のディスプレイ１９ａに表示し、Ｓ１１０へ移行する。

Ｓ１１０では、サービス選択用画面又はアドレス入力画面に基づいた利用者による入力操作が操作部１２を介して行われるまで待機し、操作部１２から、入力操作に基づく操作情報が入力されると、Ｓ１１１に移行して、利用者による入力操作が、リンク選択のための操作であるか否かを判断する。具体的には、Ｓ１０８で表示した情報に基づき選択操作が正常に行われた場合、又は、Ｓ１０９で表示したアドレス入力画面にＵＲＬ情報の入力が正常に行われた場合に、入力操作がリンク選択のための操作であると判断する。

入力操作がリンク選択のための操作でないと判断すると（Ｓ１１１でＮｏ）、制御部１１は、Ｓ１１２へ移行し、Ｓ１１０で受けた入力操作が、サービスモードを終了するための停止操作であるか否かを判断する。そして、サービスモードを終了するための停止操作であると判断すると、Ｓ１０２へ移行する。即ち、サービスモードとしての処理を終了する。一方、Ｓ１１２で、サービスモードを終了するための停止操作でないと判断すると、Ｓ１１３へ移行し、拒否音（ビープ音等）を鳴動した後、Ｓ１１０へ移行する。即ち、Ｓ１１０で受けた入力操作が、リンク選択のための操作でなく、停止操作でもない場合に、拒否音によって、操作無効を利用者に通知する。

また、Ｓ１１１で入力操作がリンク選択のための操作であると判断すると、制御部１１は、Ｓ１１４へ移行し、選択されたリンクが、サービスのＵＲＬ情報で表されているか否かを判断する。

ここで、サービスのＵＲＬ情報で表されていない（サービス定義情報２５の識別情報である又はディレクトリサーバ２０のＵＲＬ情報で表されている）と判断すると、制御部１１は、Ｓ１１５へ移行し、Ｌｉｎｋ＿Ｌｏｃａｔｉｏｎが示すサービス定義情報２５の識別情報（ＵＲＬ情報が直接入力された場合には、そのＵＲＬ情報）に基づき、ディレクトリサーバ２０に対し、該当するサービス定義情報２５の送信を要求し、要求したサービス定義情報２５をディレクトリサーバ２０から受信する。その後、Ｓ１０８に移行し、新たなサービス選択用画面を表示部１９のディスプレイ１９ａに表示する。

一方、Ｓ１１４で、リンクがサービスのＵＲＬ情報で表されていると判断すると、制御部１１は、Ｓ１１６へ移行し、上記選択されたリンクのＵＲＬ情報（サービス定義情報２５のＬｉｎｋ＿Ｌｏｃａｔｉｏｎタグに記載のＵＲＬ情報、又は、直接入力されたＵＲＬ情報）を引数に設定して、サービスを受けるためのサービス受信処理（図１０参照。詳細後述）を実行した後、Ｓ１０２に移行する。

ここで、サービス受信処理を説明する前に、Ｓ１０６にて送信されるサービス一覧の要求、及び、サービス定義情報２５の送信要求を受けるディレクトリサーバ２０の動作について説明する。図９は、ディレクトリサーバ２０の制御部２１が繰返し実行するディレクトリサーバ処理を表すフローチャートである。

ディレクトリサーバ２０の制御部２１は、ディレクトリサーバ処理を実行すると、Ｓ２０１にて、ＨＴＴＰリクエストを受信するまで待機し、ＨＴＴＰリクエストを受信すると、Ｓ２０２に移行する。Ｓ２０２では、Ｓ２０１で受信したＨＴＴＰリクエストがサービス一覧の要求であるか否かを判断し、サービス一覧の要求であると判断すると、Ｓ２０３へ移行し、記憶部２３のサービス定義情報記憶部２４からトップのサービス定義情報２５を読み出す。その後、Ｓ２０７へ移行し、読み出したサービス定義情報２５を含むＨＴＴＰレスポンスを、ＨＴＴＰリクエストの送信元へ送信する。Ｓ２０７での処理を終えると、制御部２１は、当該ディレクトリサーバ処理を終了する。

一方、Ｓ２０２で、サービス一覧の要求でないと判断すると、制御部２１は、Ｓ２０４へ移行し、Ｓ２０１で受信したＨＴＴＰリクエストがサービス定義情報の送信要求であるか否かを判断する。そして、サービス定義情報の送信要求であると判断すると、Ｓ２０５へ移行し、記憶部２３のサービス定義情報記憶部２４から、上記送信要求で指定されたサービス定義情報２５を読み出す。その後、Ｓ２０７へ移行し、読み出したサービス定義情報２５を含むＨＴＴＰレスポンスを、ＨＴＴＰリクエストの送信元へ送信した後、当該ディレクトリサーバ処理を終了する。

一方、Ｓ２０４で、ＨＴＴＰリクエストがサービス定義情報の送信要求でもないと判断すると、制御部２１は、Ｓ２０６へ移行し、Ｓ２０１で受信したＨＴＴＰリクエストに対応する所定の処理を実行し、その処理結果を示す情報を含むＨＴＴＰレスポンスを送信する（Ｓ２０７）。その後、当該ディレクトリサーバ処理を終了する。

次に、複合機処理（図８）におけるＳ１１６で実行されるサービス受信処理について、図１０のフローチャートを用いて説明する。
このサービス受信処理を開始すると、制御部１１は、Ｓ３０１で、上記引数に設定されたＵＲＬ情報に従うＵＲＬ先へ、通信部１５を介して、サービス起動指令（ＨＴＴＰリクエスト）を送信し、上記ＵＲＬ情報に対応するサービス（利用者によって選択されたサービス）にかかるプロセスを、ＵＲＬ先の機能サーバ３０に起動させる。

その後、Ｓ３０２に移行し、ＵＲＬ先の機能サーバ３０からセッションＩＤを受信する。尚、セッションＩＤは、機能サーバ３０の制御部３１により実行される後述の機能サーバ処理（図１２）のＳ４０５で生成され、Ｓ４０９で、指令元の当該複合機１０に送信される。

続くＳ３０３では、複合機１０に対する指令（複合機指令）の有無を問い合わせるための信号である「複合機指令問合せ」を、機能サーバ３０へ送信する。尚、「複合機指令問合せ」には、Ｓ３０２で受信したセッションＩＤが含まれる。

Ｓ３０３の処理後、制御部１１は、Ｓ３０３で送信した「複合機指令問合せ」に対する応答信号（ＨＴＴＰレスポンス）を受信し（Ｓ３０４）、「複合機指令問合せ」に対する返答が「ジョブ起動指令」であるか否かを判断する（Ｓ３０５）。尚、「ジョブ起動指令」は、機能サーバ３０の制御部３１により実行される後述のＳ６０３，Ｓ１７０３等の各処理で出力される。この「ジョブ起動指令」には、ジョブを特定するためのジョブＩＤと、ジョブ実行時の通信先のＵＲＬ情報である通信先ＵＲＬ情報と、が含まれる。

Ｓ３０５で「ジョブ起動指令」であると判断すると、制御部１１は、Ｓ３０６へ移行し、ジョブの起動に必要なリソースを確保し、更にＳ３０７へ移行して、指定ジョブの起動処理（図１１参照。詳細後述）を実行する。その後、Ｓ３０８へ移行し、所定インターバル待機した後、Ｓ３０３へ移行する。

一方、Ｓ３０５で「ジョブ起動指令」でないと判断すると、制御部１１は、Ｓ３０９へ移行し、「複合機指令問合せ」に対する返答が「ジョブ終了指令」であるか否かを判断する。尚、「ジョブ終了指令」は、機能サーバ３０の制御部３１により実行される後述のＳ６１０，Ｓ１７０８等の各処理で出力される。この「ジョブ終了指令」には、ジョブを特定するためのジョブＩＤが含まれる。

Ｓ３０９で、「ジョブ終了指令」であると判断すると、制御部１１は、Ｓ３１０へ移行し、ジョブＩＤに対応するジョブに対して終了指示を入力して、そのジョブを終了し、リソースを解放する。その後、Ｓ３０８へ移行し、所定インターバル待機した後、Ｓ３０３に移行する。

一方、Ｓ３０９で、「ジョブ終了指令」でないと判断した場合には、Ｓ３１１へ移行し、「複合機指令問合せ」に対する返答が「定期問合せ開始指令」であるか否か判断する。尚、「定期問合せ開始指令」は、機能サーバ３０の制御部３１により実行される後述のＳ６０９で出力される。

Ｓ３１１で「定期問合せ開始指令」であると判断すると、制御部１１は、Ｓ３１２に移行し、「定期問合せ開始指令」が含む情報に基づいて、記憶部１６が記憶する定期問合せ管理テーブル（図１６参照）に、問合せ管理情報を書き込む。尚、Ｓ３１２の具体的な処理内容は、Ｓ６０９に関する説明と共に後述する。Ｓ３１２での処理を終えると、制御部１１は、Ｓ３０８へ移行し、所定インターバル待機した後、Ｓ３０３に移行する。

また、Ｓ３１１で「定期問合せ開始指令」でないと判断すると、制御部１１は、Ｓ３１３に移行し、「複合機指令問合せ」に対する返答が「指令なし」を表すものであるか否かを判断する。

Ｓ３１３で、「複合機指令問合せ」に対する返答が「指令なし」を表すものであると判断すると、制御部１１は、Ｓ３０８へ移行し、所定インターバル待機した後、Ｓ３０３へ移行する。一方、Ｓ３１３で、「複合機指令問合せ」に対する返答が「指令なし」を表すものでないと判断すると、Ｓ３１４へ移行し、「複合機指令問合せ」に対する返答が「サービス終了指令」であるか否かを判断する。尚、「サービス終了指令」は、機能サーバ３０の制御部３１により実行される後述のＳ６１１、Ｓ１７０９等で出力される。

Ｓ３１４で「サービス終了指令」であると判断すると、制御部１１は、当該サービス受信処理を終了する。一方、「サービス終了指令」ではないと判断すると、Ｓ３１５に移行し、エラー処理（例えば、エラーである旨のメッセージを表示部１９のディスプレイ１９ａに表示する処理等）を実行し、その後、当該サービス受信処理を終了する。

次に、Ｓ３０７にて実行される指定ジョブの起動処理について、図１１のフローチャートを用いて説明する。
指定ジョブの起動処理を開始すると、制御部１１は、まずＳ３５１で、「ジョブ起動指令」が「ＵＩ（ユーザインタフェース）ジョブ起動指令」であるか否かを判断する。尚、「ＵＩジョブ起動指令」とは、複合機１０に設けられたＵＩデバイス（操作部１２）の利用開始を通知するものである。

そして、「ＵＩジョブ起動指令」であると判断すると、Ｓ３５２へ移行し、ジョブＩＤ、ジョブの通信先ＵＲＬ情報を渡してＵＩジョブ（図１８参照。詳細後述）を起動した後、当該指定ジョブの起動処理を終了する。これにより、複合機１０と機能サーバ３０との間で、ＵＩジョブの通信処理が開始される。尚、ＵＩジョブは、サービス受信処理のプロセスと並列動作する。

一方、Ｓ３５１で、「ジョブ起動指令」が「ＵＩジョブ起動指令」でないと判断すると、制御部１１は、Ｓ３５３へ移行し、「ジョブ起動指令」が「入力ジョブ起動指令」であるか否かを判断する。尚、「入力ジョブ起動指令」とは、複合機１０に設けられた入力デバイス（読取部１３又は音入力部１７）の利用開始を通知するものである。

具体的に、ここでは、「ジョブ起動指令」が、当該複合機１０の読取部（スキャナ）１３を用いて機能サーバ３０から提供されるサービスを受けるように指示する「スキャナジョブ起動指令」、又は、音入力部１７を用いて機能サーバ３０から提供されるサービスを受けるように指示する「ボイスジョブ起動指令」である場合に、「ジョブ起動指令」が「入力ジョブ起動指令」であると判断する。

そして、「入力ジョブ起動指令」であると判断すると、Ｓ３５４へ移行し、ジョブＩＤ、ジョブの通信先ＵＲＬ情報を渡して入力ジョブを起動した後、当該指定ジョブの起動処理を終了する。尚、入力ジョブ起動の際には、入力ジョブに駆動対象の入力装置（読取部１３又は音入力部１７）を指定する。

これにより、複合機１０と機能サーバ３０との間で、入力ジョブの通信処理が開始される。具体的に、入力ジョブを実行すると、制御部１１は、機能サーバ３０から指示されたデータを、入力装置（読取部１３又は音入力部１７）を用いて生成し、これを、機能サーバ３０に提供して、所定のサービス（データの公開サービス等）を受ける。尚、この入力ジョブも、サービス受信処理のプロセスと並列動作する。

また、Ｓ３５３で「ジョブ起動指令」が「入力ジョブ起動指令」ではないと判断すると、制御部１１は、Ｓ３５５に移行し、「ジョブ起動指令」が「出力ジョブ起動指令」であるか否か判断する。尚、「出力ジョブ起動指令」とは、複合機１０に設けられた出力デバイス（記録部１４又は音出力部１８）の利用開始を通知するものである。

具体的に、ここでは、「ジョブ起動指令」が、当該複合機１０の記録部（プリンタ）１４を用いて機能サーバ３０から提供されるサービスを受けるように指示する「印刷ジョブ起動指令」、又は、音出力部１８を用いて機能サーバ３０から提供されるサービスを受けるように指示する「スピーカジョブ起動指令」である場合に、「ジョブ起動指令」が「出力ジョブ起動指令」であると判断する。

そして、「出力ジョブ起動指令」であると判断すると、Ｓ３５６に移行し、ジョブＩＤ、ジョブの通信先ＵＲＬ情報を渡して、出力ジョブ（図３１参照。詳細後述）を起動した後、当該指定ジョブの起動処理を終了する。尚、出力ジョブの起動の際には、出力ジョブに駆動対象の出力装置（記録部１４又は音出力部１８）を指定する。これにより、複合機１０と機能サーバ３０との間で、出力ジョブの通信処理が開始される。そして、この出力ジョブは、サービス受信処理のプロセスと並列動作する。

一方、Ｓ３５５で、「ジョブ起動指令」が「出力ジョブ起動指令」ではないと判断すると、制御部１１は、ジョブ（ＵＩジョブ、入力ジョブ、出力ジョブ）を起動することなく、当該指定ジョブの起動処理を終了する。

次に、Ｓ３０１で複合機１０が送信するサービス起動指令を受ける機能サーバ３０側のプログラムにて実現される機能サーバ処理について説明する。尚、図１２は、機能サーバ３０の制御部３１が実行する機能サーバ処理を表すフローチャートである。この機能サーバ処理を実現するためのプログラムは、サービスの種類毎に用意される。

機能サーバ処理を開始すると、制御部３１は、ＨＴＴＰリクエストを受信するまで待機し（Ｓ４０１）、通信部１５を介してＨＴＴＰリクエストを受信すると、Ｓ４０２に移行し、Ｓ４０１で受信したＨＴＴＰリクエストがサービス起動指令であるか否かを判断する。Ｓ４０２で、サービス起動指令であると判断すると、制御部３１は、Ｓ４０５へ移行し、セッションＩＤを生成して、これを格納した送信データを生成すると共に、サービスを提供するためのプロセスを起動する。例えば、当該機能サーバ処理が、定期的に情報を提供するサービス（ブログ検索サービス、ローカルニュース提供サービス）の利用登録を受けるための処理である場合には、上記プロセスとして、図１４に示す登録処理を実行する（詳細後述）。その後、Ｓ４０９に移行する。

また、Ｓ４０２で、ＨＴＴＰリクエストがサービス起動指令でないと判断すると、制御部３１は、Ｓ４０６に移行し、Ｓ４０１で受信したＨＴＴＰリクエストが「サービス終了指令」であるか否かを判断する。Ｓ４０６で、「サービス終了指令」であると判断すると、制御部３１は、Ｓ４０７に移行し、セッションＩＤ及び確保したリソースを解放し、Ｓ４０９へ移行する。

一方、Ｓ４０６で「サービス終了指令」でないと判断すると、制御部３１は、Ｓ４０８にて、サービス制御情報処理（図１３参照。詳細後述）を実行した後、Ｓ４０９に移行する。Ｓ４０９では、Ｓ４０５，Ｓ４０７及びＳ４０８のいずれかのステップで生成した送信データを格納したＨＴＴＰレスポンスを生成し、これを通信部３２を介して、ＨＴＴＰリクエスト送信元の複合機１０に送信する。

Ｓ４０９の処理後、制御部３１は、Ｓ４０８にてサービス制御情報処理を実行したか否か判断し（Ｓ４１０）、サービス制御情報処理を実行したと判断すると、Ｓ４１１にて、セッションＩＤ又はジョブＩＤに対応するメモリアドレスに「送信済み」フラグをセットした後、当該機能サーバ処理を終了する。一方、Ｓ４１０でサービス制御情報処理を実行していないと判断すると、Ｓ４１１での処理を実行することなく、当該機能サーバ処理を終了する。

次に、制御部３１が、機能サーバ処理のＳ４０８にて実行するサービス制御情報処理について説明する。図１３は、サービス制御情報処理を表すフローチャートである。
サービス制御情報処理を実行すると、制御部３１は、Ｓ５０１で、サービスに送る情報が存在するか否かを判断する。具体的には、機能サーバ処理（図１２）のＳ４０１で受信したＨＴＴＰリクエストに、セッションＩＤ又はジョブＩＤにて特定されるサービスを実現するプロセスに対する情報が含まれているか否かを判断する。

そして、サービス（プロセス）に送る情報が存在しないと判断すると、Ｓ５０６に移行し、サービス（プロセス）に送る情報が存在すると判断すると、Ｓ５０２に移行して、セッションＩＤ又はジョブＩＤに対応するプロセスを特定する。即ち、受信したＨＴＴＰリクエストに含まれている情報の送信先となるプロセスを特定する。

ここで、プロセスを特定することができないと、制御部３１は、Ｓ５０３でＹｅｓと判断して、送信データとしてエラー通知情報を生成し（Ｓ５０４）、当該サービス制御情報処理を終了する。一方、プロセスを特定することができた場合には、Ｓ５０３でＮｏと判断し、Ｓ５０５で、特定したプロセスに、上記情報を送信した後、Ｓ５０６へ移行する。

Ｓ５０６では、セッションＩＤ又はジョブＩＤに対応するプロセスにて生成された返信情報を記憶するメモリ領域（以下、「返信情報格納領域」とする。）を特定し、特定できない場合には、Ｓ５０７でＹｅｓと判断して、Ｓ５０４に移行し、ＨＴＴＰレスポンスに格納する送信データとして、エラー通信情報を生成する。その後、当該サービス制御情報処理を終了する。

一方、特定できた場合には、Ｓ５０７でＮｏと判断して、Ｓ５０８に移行し、特定した返信情報格納領域に、返信情報が格納されているか否か判断する。そして、返信情報が格納されていると判断すると、Ｓ５０９へ移行し、その返信情報に基づく「複合機指令」を、送信データとして生成する。その後、当該サービス制御情報処理を終了する。

一方、Ｓ５０８で、上記特定した返信情報格納領域に返信情報が格納されていないと判断すると、Ｓ５１０に移行し、送信データとして、「複合機指令無し」の情報を生成した後、当該サービス制御情報処理を終了する。

次に、機能サーバ３０の制御部３１がＳ４０５で起動するプロセスについて説明する。尚、上記プロセスが行う処理の内容はサービスの種類によって異なるため、ここでは、定期的に情報を提供するサービス（ブログ検索サービス、ローカルニュース提供サービス）の利用登録を受けるためのプロセスが行う登録処理ついて説明する。尚、図１４は、制御部３１が実行する登録処理を表すフローチャートである。

登録処理を実行すると、制御部３１は、Ｓ６０１で初期化処理を実行し、続くＳ６０２で、サービス側ＵＩジョブ（図１７参照。詳細後述）を起動する。続いて、Ｓ６０３では、「ＵＩジョブ起動指令」を複合機指令として出力する。具体的には、Ｓ４０５で生成したセッションＩＤに対応する返信情報格納領域に対して、「ＵＩジョブ起動指令」を書き込む処理を行う。

これによって、「ＵＩジョブ起動指令」は、サービス制御情報処理を介し、複合機指令として、複合機１０に送信される。また、制御部３１は、上述の機能サーバ処理（図１２）におけるＳ４１１にて「送信済み」がセットされることで出力を確認する。尚、この「ＵＩジョブ起動指令」には、Ｓ６０２で起動したサービス側ＵＩジョブについてのジョブＩＤとジョブの通信先ＵＲＬ情報とが含まれる。

Ｓ６０３での処理を終えると、制御部３１は、Ｓ６０４に移行し、パラメータの値入力が完了したか否かを判断する。尚、パラメータの値入力が完了したか否かは、後述するサービス側ＵＩジョブ（図１７）におけるＳ７１１によってパラメータ入力済みの通知が、当該登録処理のプロセスに対して入力されたか否かにより判断する。

Ｓ６０４で、パラメータの値入力が完了していないと判断すると、制御部３１は、Ｓ６０５へ移行し、停止が通知されたか否かを判断する。尚、停止の通知は、後述するサービス側ＵＩジョブ（図１７）におけるＳ７０９で行われる。

Ｓ６０５で、停止が通知されていないと判断すると、制御部３１は、Ｓ６０４に移行し、Ｓ６０５で停止が通知されたと判断すると、Ｓ６１０に移行する。また、Ｓ６０４で、パラメータの値入力が完了したと判断した場合には、Ｓ６０６へ移行し、リクエストサービスＩＤを生成する。

尚、リクエストサービスＩＤは、入力されたパラメータの値に対応するサービスを、入力元の複合機１０に対してのみ提供するためのものである。このリクエストサービスＩＤは、サービスの利用登録毎に（即ち、パラメータ情報の入力毎に）、ユニークに生成され、後述のＳ６０９により、上記入力元の複合機１０に対してのみに通知される。

Ｓ６０６での処理を終えると、制御部３１は、Ｓ６０７にて、記憶部３３に記憶されたリクエストサービスＩＤ管理テーブルに、Ｓ６０６で生成したリクエストサービスＩＤと、入力された各パラメータの値（パラメータ情報）と、を書き込む。図１５（ａ）は、記憶部３３に記憶されたリクエストサービスＩＤ管理テーブルの構成を表す説明図である。

リクエストサービスＩＤ管理テーブルは、リクエストサービスＩＤと、そのリクエストサービスＩＤの生成時にクライアント装置としての複合機１０から入力された各パラメータの値（パラメータ情報）とが、互いに関連付けられて記憶されたものである。このリクエストサービスＩＤ管理テーブルは、サービスの種類毎に用意される登録処理のプロセスに対応して、サービスの種類毎に、記憶部３３に設けられている。例えば、記憶部３３には、ブログ検索サービス用のリクエストサービスＩＤ管理テーブルと、ローカルニュース提供サービス用のリクエストサービスＩＤ管理テーブルとが設けられている。

即ち、Ｓ６０７では、当該プロセスに対応するリクエストサービスＩＤ管理テーブルに、Ｓ６０６で生成したリクエストサービスＩＤと、複合機１０から入力された各パラメータの値（パラメータ情報）と、を記述して登録する。

Ｓ６０７での処理を終えると、制御部３１は、Ｓ６０８に移行し、記憶部３３が記憶する定期問合せ返信管理テーブルに、Ｓ６０６で生成したリクエストサービスＩＤの返信管理情報を書き込む。尚、図１５（ｂ）は、記憶部３３に記憶された定期問合せ返信管理テーブルの構成を表す説明図である。

図１５（ｂ）に示すように、定期問合せ返信管理テーブルは、リクエストサービスＩＤと、サービススタート情報と、サービスＵＲＬ情報と、サービスステータス情報と、サービスキャンセル情報と、からなる返信管理情報が、リクエストサービスＩＤ毎に、記述された構成にされている。

サービススタート情報は、サービスを提供する準備が完了したか否かを表す情報であって、サービスを提供する準備が完了している場合には、値「ＴＲＵＥ」で表され、サービスを提供する準備か完了していない場合には、値「ＦＡＬＳＥ」で表される情報である。

また、サービスＵＲＬ情報は、リクエストサービスＩＤに対応するサービスを提供する機能サーバ３０のＵＲＬ情報であり、サービスステータス情報は、サービスを提供する機能サーバ３０側のステータス情報である。

サービスステータス情報は、リクエストサービスＩＤに対応するサービスのステータスが正常である場合には値「０」で表され、サービスのステータスが異常である場合には、その原因に対応する負値で表される。

その他、サービスキャンセル情報は、サービスの提供が終了したか否かを表す情報であり、サービスの提供が終了している場合には、値「ＴＲＵＥ」で表され、サービスの提供が継続している場合には、値「ＦＡＬＳＥ」で表される。尚、サービスキャンセル情報が値「ＴＲＵＥ」である返信管理情報は、機能サーバ３０の定期削除プログラム（図示せず）により、一定期間後、自動削除される。また、この削除に伴って、リクエストサービスＩＤ管理テーブルの上記削除対象のリクエストサービスＩＤに関するパラメータ情報も、削除される。

そして、Ｓ６０８の処理を終えると、制御部３１は、「定期問合せ開始指令」を複合機指令として出力する（Ｓ６０９）。具体的に、ここでは、Ｓ４０５で生成したセッションＩＤに対応する返信情報格納領域に対して、「定期問合せ開始指令」を書き込む処理を行う。この書き込みによって、「定期問合せ開始指令」は、サービス制御情報処理を介し、複合機指令として、複合機１０に送信される。

尚、「定期問合せ開始指令」は、Ｓ６０６で生成したリクエストサービスＩＤと、複合機１０に対して指定する定期問合せの時間間隔を表す情報（問合せ間隔情報）と、その時間間隔後、即時の問合せが必要であるか否かを表す情報（即時処理情報）と、サービスの利用時に複合機１０側で動作が必要となる入出力デバイスの種類を表す情報（利用デバイス情報）と、を含むものである。

複合機１０の制御部１１は、この「定期問合せ開始指令」を受信すると、Ｓ３１２（図１０）に移行し、「定期問合せ開始指令」が含む情報に基づいて、記憶部１６が記憶する定期問合せ管理テーブル（図１６参照）に、リクエストサービスＩＤ、リクエストステータス情報、問合せ間隔情報、残り時間情報、即時処理情報、及び、利用デバイス情報からなる問合せ管理情報を追加する。尚、図１６は、記憶部１６が記憶する定期問合せ管理テーブルの構成を表す説明図である。

ここで、定期問合せ管理テーブルに書き込まれるリクエストサービスＩＤ、問合せ間隔情報、即時処理情報、及び利用デバイス情報は、「定期問合せ開始指令」に含まれる情報と同一のものである。一方、リクエストステータス情報は、問合せに対する返答として、上述したサービスステータス情報を機能サーバ３０側から取得するか否かを表す情報であり、取得する場合には値「ＴＲＵＥ」で表され、取得しない場合には値「ＦＡＬＳＥ」で表される。

尚、Ｓ３１２では、リクエストステータス情報を値「ＴＲＵＥ」として、定期問合せ管理テーブルに、その情報を書き込む。但し、本実施例の複合機１０は、操作部１２からリクエストステータス情報の値変更指令が入力されると、その指令に従って、定期問合せ管理テーブルにおける指令対象のリクエストステータス情報の値を「ＦＡＬＳＥ」（又は「ＴＲＵＥ」）に変更する。

その他、残り時間情報は、次回の問合せ時刻までの残り時間を表す情報である。Ｓ３１２では、問合せ間隔情報と同一の値を示す残り時間情報が、定期問合せ管理テーブルに書き込まれるが、この残り時間情報は、後述するＳ９０１の処理にて逐次更新される。

話を戻して、Ｓ６０９での出力を終えると、制御部３１は、Ｓ６１０に移行し、「ＵＩジョブ終了指令」を複合機指令として出力する（Ｓ６１０）。具体的に、ここでは、Ｓ４０５で生成したセッションＩＤに対応する返信情報格納領域に対して、「ＵＩジョブ終了指令」を書き込む処理を行う。これにより、「ＵＩジョブ終了指令」は、サービス制御情報処理を介し、複合機指令として、複合機１０に送信される。

Ｓ６１０での処理を終えると、制御部３１は、Ｓ６１１に移行し、Ｓ６０３で起動したサービス側ＵＩジョブに対して終了指示を入力して、サービス側ＵＩジョブを終了すると共に、「サービス終了指令」を複合機指令として出力する。その後、当該登録処理を終了する。

次に、機能サーバ３０の制御部３１がＳ６０２で起動するサービス側ＵＩジョブを、図１７を用いて説明すると共に、複合機１０の制御部１１が、Ｓ６０３で出力される「ＵＩジョブ起動指令」を受けて（Ｓ３０４）、Ｓ３５２で起動するＵＩジョブを、図１８を用いて説明する。尚、図１７は、機能サーバ３０の制御部３１が実行するサービス側ＵＩジョブを表すフローチャートであり、図１８は、複合機１０の制御部１１が実行するＵＩジョブを表すフローチャートである。

サービス側ＵＩジョブを実行すると、制御部３１は、まずＳ７０１で、複合機１０から「複合機ジョブ指令問合せ」を受信する。尚、「複合機ジョブ指令問合せ」は、複合機１０の制御部１１により実行されるＵＩジョブ（図１８）のＳ８００等で送信用データに設定され、Ｓ８０６で送信される。

続いて、Ｓ７０２では、サービスの実行に必要なパラメータの値を入力させるための「パラメータ要求指令」を複合機指令として複合機１０へ送信する。尚、「パラメータ要求指令」と共に、複合機１０には、記憶部３３のサービスＩ／Ｆ情報記憶部３４に記憶されているサービスＩ／Ｆ情報３６が送信される。具体的に、当該サービス側ＵＩジョブを起動した登録処理のプロセスが、ブログ検索サービスの利用登録を受けるためのプロセスである場合には、図６に示すサービスＩ／Ｆ情報３６が送信される。また、当該サービス側ＵＩジョブを起動した登録処理のプロセスが、ローカルニュース提供サービスの利用登録のためのプロセスである場合には、図７に示すサービスＩ／Ｆ情報３６が送信される。

Ｓ７０２の処理後、制御部３１は、Ｓ７０３に移行し、エラーカウントを初期化する。その後、上記サービスＩ／Ｆ情報３６に基づくパラメータ入力用画面を通じて利用者から入力された各パラメータの値を、複合機１０から受信する（Ｓ７０４）。尚、各パラメータの値は、複合機１０の制御部１１により実行されるＵＩジョブ（図１８）のＳ８１０で送信用データに設定され、Ｓ８０６で送信される。

Ｓ７０４で各パラメータの値を受信すると、制御部３１は、Ｓ７０５に移行し、Ｓ７０４で受信した各パラメータの値が正常であるか否かを判断する。そして、パラメータの値が正常でないと判断すると、Ｓ７０６へ移行し、正常でないと判断された回数が２回目であるか否かを、上述のエラーカウントに基づいて判断する。

Ｓ７０６で、２回目でない（１回目である）と判断した場合には、Ｓ７０７へ移行し、機能サーバ３０が複合機１０からの情報を正常に受け取ることができたか否かの通知であるサーバ受取状況として「サーバ受取ＮＧ（異常受取）」を、複合機１０のＵＩジョブに向けて出力する。

Ｓ７０７の処理後、制御部３１は、エラーカウントをカウントアップし（Ｓ７０８）、Ｓ７０４に移行する。一方、Ｓ７０６で、２回目であると判断すると、制御部３１は、Ｓ７０９へ移行し、当該サービス側ＵＩジョブの起動元のプロセス（登録処理のプロセス）へ停止を通知した後、当該サービス側ＵＩジョブを終了する。

また、Ｓ７０５で、パラメータの値が正常であると判断すると、制御部３１は、Ｓ７１０へ移行し、サーバ受取状況として「サーバ受取ＯＫ（正常受取）」を、複合機１０のＵＩジョブに向けて出力する。

Ｓ７１０での処理を終えると、制御部３１は、Ｓ７１１に移行し、当該サービス側ＵＩジョブの起動元のプロセス（登録処理のプロセス）へ「パラメータ入力済み」を通知する。その後、制御部３１は、Ｓ７１２にて、複合機１０から「サービス状態情報要求」を受信するまで待機し、「サービス状態情報要求」を受信すると、Ｓ７１３にて、「サービス状態情報」を、複合機１０のＵＩジョブに向けて送信する。その後、Ｓ７１２へ移行する。

即ち、他の処理によって、当該サービス側ＵＩジョブが終了される（Ｓ６１１）まで、複合機１０から「サービス状態情報要求」を受信し、それに応答して「サービス状態情報」を送信するという処理を繰返す。尚具体的に、「サービス状態情報」は、パラメータの値入力が正常に行われたことを示す情報である。

一方、複合機１０の制御部１１は、Ｓ６０３で出力される「ＵＩジョブ起動指令」を受けて、Ｓ３５２でＵＩジョブ（図１８）を起動すると、次の処理を実行する。
ＵＩジョブを実行すると、複合機１０の制御部１１は、まずＳ８００にて、複合機１０に対する指令の問い合わせである「複合機ジョブ指令問合せ」を、送信用データに設定し、その後、Ｓ８０１で、当該ＵＩジョブ起動元のプロセス（サービス受信処理のプロセス）からの終了指示があったか否かを判断する。尚、終了指示は、Ｓ３１０で出力される。

Ｓ８０１で終了指示があったと判断すると、制御部１１は、Ｓ８０２に移行し、当該ＵＩジョブ起動元のプロセス（サービス受信処理のプロセス）へ終了を通知した後、当該ＵＩジョブを終了する。

一方、Ｓ８０１で終了指示がないと判断すると、制御部１１は、Ｓ８０３へ移行し、操作部１２及び表示部１９がビジー状態であるか否かを判断する。具体的には、操作部１２及び表示部１９がビジー状態であるか否かを表すビジーフラグＦｕに基づき、ビジーフラグＦｕが立っている場合にはビジー状態であると判断し、ビジーフラグＦｕが下りている場合にはビジー状態でないと判断する。

そして、操作部１２及び表示部１９がビジー状態であると判断すると、Ｓ８０４へ移行し、操作部１２及び表示部１９のビジー状態が解除されるまで待機した後、Ｓ８０３へ移行する。一方、Ｓ８０３で、ビジー状態でないと判断した場合には、Ｓ８０５へ移行し、ビジーフラグＦｕを立てる。

Ｓ８０５の処理を終えると、制御部１１は、Ｓ８０６に移行し、予めＳ８００等で設定した送信用データを機能サーバ３０へ送信する。送信後、制御部１１は、Ｓ８０６での送信に対する応答信号を受信し（Ｓ８０７）、受信した応答信号が「パラメータ要求指令」であるか否かを判断する（Ｓ８０８）。尚、「パラメータ要求指令」は、機能サーバ３０の制御部３１により実行されるＳ７０２の処理で送信される。

Ｓ８０８で、「パラメータ要求指令」であると判断すると、制御部１１は、Ｓ８０９へ移行し、「パラメータ要求指令」に含まれるサービスＩ／Ｆ情報３６に基づきパラメータ入力用画面を表示部１９のディスプレイ１９ａに表示し、パラメータ値についての入力操作を利用者に促すと共に、パラメータの値入力を受け付ける。

そして、操作部１２を通じて、Ｓ８０９で受け付けたパラメータの値についての確定信号が入力されると、上記入力されたパラメータの値を、機能サーバ３０のサービス側ＵＩジョブに提供するため、これを送信用データに設定する（Ｓ８１０）。その後、制御部１１は、Ｓ８１１へ移行し、ビジーフラグＦｕを下げた後、Ｓ８０１へ移行する。

一方、Ｓ８０８で、「パラメータ要求指令」ではないと判断すると、制御部１１は、Ｓ８１２へ移行し、Ｓ８０７で受信した応答信号が「サービス状態情報」であるか否かを判断する。尚、「サービス状態情報」は、機能サーバ３０の制御部３１により実行されるＳ７１３の処理で送信される。

Ｓ８１２で、「サービス状態情報」であると判断すると、制御部１１は、Ｓ８１３へ移行し、この「サービス状態情報」に基づく情報を、表示部１９のディスプレイ１９ａに表示する。その後、サービス状態情報を機能サーバ３０から取得するための「サービス状態情報要求」を、送信用データに設定する（Ｓ８２１）。Ｓ８２１での処理を終えると、制御部１１は、Ｓ８１１へ移行し、ビジーフラグＦｕを下げた後、Ｓ８０１へ戻る。

一方、Ｓ８１２で、「サービス状態情報」でないと判断した場合には、Ｓ８１４へ移行し、Ｓ８０７で受信した応答信号が、機能サーバ３０が複合機１０からの情報を正常に受け取ることができたか否かを表す「サーバ受取状況」であるか否かを判断する。そして、「サーバ受取状況」であると判断すると、制御部１１は、Ｓ８１５へ移行し、この「サーバ受取状況」が「サーバ受取ＮＧ」を表すものであるか否かを判断する。

「サーバ受取ＮＧ」を表すものであると判断すると、制御部１１は、Ｓ８１６に移行し、機能サーバ３０のサービス側ＵＩジョブに、前回送信した情報を提供するために、前回送信した情報と同一の情報である再送信情報（パラメータ情報）を、送信用データに設定する。その後、Ｓ８１１へ移行し、ビジーフラグＦｕを下げた後、Ｓ８０１へ移行する。

一方、Ｓ８１５で、「サーバ受取状況」が「サーバ受取ＮＧ」を表すものではないと判断すると、制御部１１は、Ｓ８２２に移行し、「サービス状態情報要求」を、送信用データに設定する。その後、Ｓ８１１へ移行し、ビジーフラグＦｕを下げた後、Ｓ８０１へ移行する。

また、Ｓ８１４で、上記応答信号が「サーバ受取状況」でないと判断すると、制御部１１は、Ｓ８１７へ移行し、Ｓ８０７で受信した応答信号が「指令なし」を表すものであるか否かを判断する。

Ｓ８１７で、複合機指令が「指令なし」を表すものであると判断すると、制御部１１は、Ｓ８２３に移行し、「複合機ジョブ指令問合せ」を、送信用データに設定する。その後、Ｓ８１１へ移行し、ビジーフラグＦｕを下げた後、Ｓ８０１へ移行する。一方、Ｓ８１７で、複合機指令が「指令なし」を表すものでないと判断した場合には、Ｓ８１８へ移行し、その他の処理を実行する。尚、この際には、処理の内容に適合するデータを、送信用データに設定する。例えば、ここでは、応答信号に対応する処理の実行後に、「複合機ジョブ指令問合せ」を、送信用データに設定する。その後、Ｓ８１１へ移行し、ビジーフラグＦｕを下げた後、Ｓ８０１へ移行する。

次に、上述の定期問合わせを実現するために、複合機１０の制御部１１が実行する定期問合せ処理について説明する。図１９は、制御部１１が実行する定期問合せ処理を表すフローチャートである。尚、この定期問合せ処理は、複合機１０の電源投入時から開始され、複合機１０の電源がオフにされるまで、継続的に実行される。

定期問合せ処理を実行すると、制御部１１は、Ｓ９０１にて、定期問合せ管理テーブルの各残り時間情報を更新する。具体的には、前回の内部時計の値（時刻）と、現在の内部時計の値（時刻）との差を求めて、この差（カウントダウン量）を、残り時間情報が示す値から引き算し、残り時間情報を更新する。即ち、Ｓ９０１では、残り時間のカウントダウンと共に、内部時計の値の取得及び一時記憶を行う。

尚、Ｓ９０１の処理は、後述するように（高速で）繰り返されるため、前回のカウントダウンと、今回のカウントダウンとの間に、新規に定期問合せ管理テーブルに追加された問合せ管理情報についての残り時間情報のカウントダウン量についての誤差は許容する。また、初回のＳ９０１については、前回の電源オフ時前の最後の機会に取得した内部時計の値に基づいて、カウントダウン量を算出してもよいし、現在の内部時計の値を記憶するだけで、カウントダウンの処理を行わないようにしてもよい。

Ｓ９０１での処理を終えると、制御部１１は、Ｓ９０２に移行し、定期問合せ管理テーブルから、処理対象の問合せ管理情報を、一つ選択する（Ｓ９０２）。処理対象の問合せ管理情報がない場合、即ち、後述するＳ９０４以降の処理の対象となっていない未処理の問合せ管理情報が存在しない場合には、Ｓ９０３でＮｏと判断して、Ｓ９１０に移行し、処理対象の問合せ管理情報（未処理の問合せ管理情報）がある場合には、Ｓ９０３でＹｅｓと判断して、Ｓ９０４に移行し、予め定められた問合せの実行猶予（保留）期間（最後の定期問合せ信号の送信時点から所定時間）が経過しているか否か判断する。

Ｓ９０４で、実行猶予期間が経過していないと判断すると、制御部１１は、Ｓ９０５に移行し、上記選択した処理対象の問合せ管理情報が有する即時処理情報に基づいて、即時の問合せが必要であるか否かを判断する。ここで、即時の問合せが必要でないと判断すると、Ｓ９０２に移行し、即時の問合せが必要であると判断すると、Ｓ９０６に移行する。

Ｓ９０６では、上記選択した処理対象の問合せ管理情報が有する残り時間情報に基づき、その問合せ管理情報に対応するリクエストサービスＩＤのサービスについて、定期問合せの送信時刻が到来しているか否か判断し、送信時刻が到来していないと判断すると、Ｓ９０２に移行する。尚、Ｓ９０６では、残り時間情報の値がゼロ又は負値である場合に、送信時刻が到来していると判断し、残り時間情報の値が正値である場合には、送信時刻が到来していないと判断する。

Ｓ９０６で送信時刻が到来していると判断すると、制御部１１は、上記選択した処理対象の問合せ管理情報が有する利用デバイス情報に基づき、当該問合せ管理情報に対応するサービスを受ける際に利用する入出力デバイスが、並列動作している他のプロセスによって使用されているか否かを判断する（Ｓ９０７）。

具体的に、ここでは、処理対象の問合せ管理情報が有する利用デバイス情報が「Ｐｒｉｎｔｅｒ」である場合、記録部１４が使用されているか否かを判断する。また、利用デバイス情報が「Ｓｃａｎｎｅｒ」である場合、読取部１３が使用されているか否かを判断する。その他、利用デバイス情報が「Ｓｐｅａｋｅｒ」である場合には、音出力部１８が使用されているか否か判断し、利用デバイス情報が「Ｍｉｃｒｏｐｈｏｎｅ」である場合には、音入力部１７が使用されているか否か判断する。

また、利用デバイス情報に複数の入出力デバイスが示されている場合には、それら複数のデバイスが使用されているか否かを判断する。そして、複数のデバイスの一つでも使用されている場合には、当該問合せ管理情報に対応するサービスを受ける際に利用する入出力デバイスが使用されていると判断する。

Ｓ９０７で入出力デバイスが使用されていると判断すると、制御部１１は、Ｓ９０２に移行し、使用されていないと判断すると、Ｓ９０８に移行し、統合問合せ情報生成処理を実行する。尚、図２０は、制御部１１が実行する統合問合せ情報生成処理を表すフローチャートであり、図２１は、統合問合せ情報の構成を表す説明図である。また、統合問合せ情報は、図２１に示すように、マークアップ言語によって記述されており、この統合問合せ情報で用いられる各タグの定義は表３に示すとおりである。

統合問合せ情報生成処理を実行すると、制御部１１は、まずＳ１００１にて、当該統合問合せ情報生成処理の実行が、Ｓ９０１の処理後、最初の実行であるか否か判断する。そして、最初の実行であると判断すると、Ｓ１０１１に移行し、統合問合せ情報を生成するための領域をＲＡＭに確保し、その領域（空の統合問合せ情報）に、ヘッダ情報を書き込む（Ｓ１０１２）。

尚、本実施例では、統合問合せ情報を、ＨＴＴＰプロトコルにおけるＰＯＳＴコマンドで送信するため、ヘッダ情報には、その旨の情報や送信先のＵＲＬ情報等が書き込まれる。尚、統合問合せ情報の送信先は、予め決められており、ヘッダ情報には、その送信先のＵＲＬ情報が書き込まれる。

Ｓ１０１２の処理後、制御部１１は、パラメータＮｕｍＰａｔｔｅｒｎの値を「１」として、ＮｕｍＰａｔｔｅｒｎタグ（文字列＜ＮｕｍＰａｔｔｅｒｎ＞１＜／ＮｕｍＰａｔｔｅｒｎ＞）を生成し、これを、統合問合せ情報（統合問合せ情報生成領域）に追加する（Ｓ１０１３）。また、Ｒｅｑｕｅｓｔ＿Ｓｅｒｖｉｃｅタグを統合問合せ情報に追加する（Ｓ１０１４）。

その後、Ｒｅｑｕｅｓｔ＿Ｓｅｒｖｉｃｅタグの間（即ち、＜Ｒｅｑｕｅｓｔ＿Ｓｅｒｖｉｃｅ＞と＜／Ｒｅｑｕｅｓｔ＿Ｓｅｒｖｉｃｅ＞との間）に、処理対象の問合せ管理情報のリクエストステータス情報に基づいて、Ｒｅｑｕｅｓｔ＿Ｓｔａｔｕｓタグを書き込む（Ｓ１０１５）。

例えば、リクエストステータス情報の値が「ＦＡＬＳＥ」である場合には、パラメータＲｅｑｕｅｓｔ＿Ｓｔａｔｕｓの値を「ＦＡＬＳＥ」として、Ｒｅｑｕｅｓｔ＿Ｓｔａｔｕｓタグ（文字列＜Ｒｅｑｕｅｓｔ＿Ｓｔａｔｕｓ＞ＦＡＬＳＥ＜／Ｒｅｑｕｅｓｔ＿Ｓｔａｔｕｓ＞）を生成し、これを統合問合せ情報に書き込む。

また、Ｓ１０１５の処理を終えると、パラメータＮｕｍ＿Ｓｅｒｖｉｃｅ＿ＩＤの値を「１」として、Ｎｕｍ＿Ｓｅｒｖｉｃｅ＿ＩＤタグ（文字列＜Ｎｕｍ＿Ｓｅｒｖｉｃｅ＿ＩＤ＞１＜／Ｎｕｍ＿Ｓｅｒｖｉｃｅ＿ＩＤ＞）を生成し、これを統合問合せ情報におけるＲｅｑｕｅｓｔ＿Ｓｅｒｖｉｃｅタグの間に書き込む（Ｓ１０１６）。

また、Ｓ１０１６の処理を終えると、処理対象の問合せ管理情報が示すリクエストサービスＩＤの値を、パラメータＲｅｑｕｅｓｔ＿Ｓｅｒｖｉｃｅ＿ＩＤの値として、Ｒｅｑｕｅｓｔ＿Ｓｅｒｖｉｃｅ＿ＩＤタグ（文字列＜Ｒｅｑｕｅｓｔ＿Ｓｅｒｖｉｃｅ＿ＩＤ＞（リクエストサービスＩＤ）＜／Ｒｅｑｕｅｓｔ＿Ｓｅｒｖｉｃｅ＿ＩＤ＞）を生成し、これを統合問合せ情報におけるＲｅｑｕｅｓｔ＿Ｓｅｒｖｉｃｅタグの間に書き込む（Ｓ１０１７）。その後、当該統合問合せ情報生成処理を終了する。

一方、Ｓ１００１にて、当該統合問合せ情報生成処理の実行が、Ｓ９０１の処理後、初回ではなく二回目以降の実行であると判断すると、制御部１１は、Ｓ１０２１に移行し、同じパラメータ値のタグがあるか否かを判断する。即ち、当該処理対象の問合せ管理情報が有するリクエストステータス情報の値と、同一の値を示すＲｅｑｕｅｓｔ＿Ｓｔａｔｕｓタグが、統合問合せ情報に既に書き込まれているか否か判断する。

Ｓ１０２１で、同じパラメータ値（Ｒｅｑｕｅｓｔ＿Ｓｔａｔｕｓ）のタグがあると判断すると、制御部１１は、そのタグと、同一のＲｅｑｕｅｓｔ＿Ｓｅｒｖｉｃｅタグの間にあるＮｕｍ＿Ｓｅｒｖｉｃｅ＿ＩＤタグの値を更新する（Ｓ１０２２）。例えば、統合問合せ情報における更新前のＮｕｍ＿Ｓｅｒｖｉｃｅ＿ＩＤタグが、文字列＜Ｎｕｍ＿Ｓｅｒｖｉｃｅ＿ＩＤ＞１＜／Ｎｕｍ＿Ｓｅｒｖｉｃｅ＿ＩＤ＞である場合には、これを＜Ｎｕｍ＿Ｓｅｒｖｉｃｅ＿ＩＤ＞２＜／Ｎｕｍ＿Ｓｅｒｖｉｃｅ＿ＩＤ＞に更新する。

Ｓ１０２２の処理を終えると、制御部１１は、処理対象の問合せ管理情報が示すリクエストサービスＩＤの値を、パラメータＲｅｑｕｅｓｔ＿Ｓｅｒｖｉｃｅ＿ＩＤの値として、Ｒｅｑｕｅｓｔ＿Ｓｅｒｖｉｃｅ＿ＩＤタグを生成し、これを統合問合せ情報におけるＲｅｑｕｅｓｔ＿Ｓｅｒｖｉｃｅタグの間に書き込む（Ｓ１０２３）。その後、当該統合問合せ情報生成処理を終了する。

また、Ｓ１０２１で、同じパラメータ値（Ｒｅｑｕｅｓｔ＿Ｓｔａｔｕｓ）のタグがないと判断すると、制御部１１は、Ｓ１０３１に移行し、統合問合せ情報のＮｕｍＰａｔｔｅｒｎタグにおけるパラメータＮｕｍＰａｔｔｅｒｎの値を更新する。即ち、統合問合せ情報のＮｕｍＰａｔｔｅｒｎタグが文字列＜ＮｕｍＰａｔｔｅｒｎ＞１＜／ＮｕｍＰａｔｔｅｒｎ＞である場合には、これを、文字列＜ＮｕｍＰａｔｔｅｒｎ＞２＜／ＮｕｍＰａｔｔｅｒｎ＞に更新する。

Ｓ１０３１の処理を終えると、制御部１１は、Ｓ１０３２に移行し、既に統合問合せ情報に書き込まれているＲｅｑｕｅｓｔ＿Ｓｅｒｖｉｃｅタグに続く領域に、新しいＲｅｑｕｅｓｔ＿Ｓｅｒｖｉｃｅタグを書き込み、その新しいＲｅｑｕｅｓｔ＿Ｓｅｒｖｉｃｅタグの間に、処理対象の問合せ管理情報が有するリクエストステータス情報の値に基づくＲｅｑｕｅｓｔ＿Ｓｔａｔｕｓタグを書き込む（Ｓ１０３３）。

例えば、リクエストステータス情報の値が「ＴＲＵＥ」である場合には、パラメータＲｅｑｕｅｓｔ＿Ｓｔａｔｕｓの値を「ＴＲＵＥ」として、Ｒｅｑｕｅｓｔ＿Ｓｔａｔｕｓタグ（文字列＜Ｒｅｑｕｅｓｔ＿Ｓｔａｔｕｓ＞ＴＲＵＥ＜／Ｒｅｑｕｅｓｔ＿Ｓｔａｔｕｓ＞）を生成し、これを統合問合せ情報に書き込む。

Ｓ１０３３の処理を終えると、制御部１１は、パラメータＮｕｍ＿Ｓｅｒｖｉｃｅ＿ＩＤの値を「１」として、Ｎｕｍ＿Ｓｅｒｖｉｃｅ＿ＩＤタグ（文字列＜Ｎｕｍ＿Ｓｅｒｖｉｃｅ＿ＩＤ＞１＜／Ｎｕｍ＿Ｓｅｒｖｉｃｅ＿ＩＤ＞）を生成し、これを統合問合せ情報における上記新しいＲｅｑｕｅｓｔ＿Ｓｅｒｖｉｃｅタグの間に書き込む（Ｓ１０３４）。

また、Ｓ１０３４の処理を終えると、処理対象の問合せ管理情報が示すリクエストサービスＩＤの値を、パラメータＲｅｑｕｅｓｔ＿Ｓｅｒｖｉｃｅ＿ＩＤの値として、Ｒｅｑｕｅｓｔ＿Ｓｅｒｖｉｃｅ＿ＩＤタグを生成し、これを統合問合せ情報における上記新しいＲｅｑｕｅｓｔ＿Ｓｅｒｖｉｃｅタグの間に書き込む（Ｓ１０３５）。その後、当該統合問合せ情報生成処理を終了し、Ｓ９０２（図１９参照）に移行する。

また、Ｓ９０２の処理後、Ｓ９０３で処理対象の問合せ管理情報がないと判断すると（即ち、Ｓ９０４以降の処理を、定期問合せ管理テーブルに記載された全ての問合せ管理情報に対して実行したと判断すると）、制御部１１は、Ｓ９１０に移行し、統合問合せ情報が生成されているか否かを判断する。そして、統合問合せ情報が生成されていると判断すると、ＲＡＭの統合問合せ情報生成領域に格納されている統合問合せ情報を格納した定期問合せ信号を生成し、これを通信部１５を通じて、問合せ先の機能サーバ３０に送信する（Ｓ９１１）。その後、Ｓ９０１に移行する。

一方、Ｓ９１０で統合問合せ情報が生成されていない（Ｓ９０８を実行していない）と判断すると、制御部１１は、Ｓ９１１の処理を実行することなく、Ｓ９０１に移行して、再び、残り時間のカウントダウンを行う。

続いて、Ｓ９１１で複合機１０から送信される定期問合せ信号を受ける機能サーバ３０側の定期問合せ応答処理について説明する。図２２は、機能サーバ３０の制御部３１が実行する定期問合せ応答処理を表すフローチャートである。この定期問合せ応答処理は、機能サーバ３０の動作中、継続して行われる。

問合せ応答処理を実行すると、制御部３１は、通信部３２を介して、複合機１０から定期問合せ信号を受信するまで待機し（Ｓ１１０１）、定期問合せ信号を受信すると、その定期問合せ信号に含まれる統合問合せ情報の中から、処理対象のリクエストサービスＩＤを一つ選択する（Ｓ１１０２）。

ここで、処理対象のリクエストサービスＩＤがない場合、即ち、後述するＳ１１０４以降の処理対象となっていない未処理のリクエストサービスＩＤが存在しない場合には、Ｓ１１０３でＮｏと判断して、Ｓ１１１５に移行し、処理対象（未処理）のリクエストサービスＩＤがある場合には、Ｓ１１０３でＹｅｓと判断してＳ１１０４に移行し、そのリクエストサービスＩＤについての返答を表す定期問合せ返信情報を生成するための定期問合せ返信情報生成領域を、ＲＡＭに確保し、その領域に、パラメータＲｅｑｕｅｓｔ＿Ｓｅｒｖｉｃｅ＿ＩＤの値として、上記処理対象のリクエストサービスＩＤを書き込む。

その後、処理対象のリクエストサービスＩＤに対応する返信管理情報を、記憶部３３に格納された定期問合せ返信管理テーブル内で検索し（Ｓ１１０５）、検索できなかった場合には、定期問合せ返信管理テーブルに、処理対象のリクエストサービスＩＤに対する返信管理情報が登録されていないと判断して（Ｓ１１０６でＮｏ）、Ｓ１１０７に移行し、上記定期問合せ返信情報生成領域に、パラメータＳｅｒｖｉｃｅ＿Ｃａｎｃｅｌｅｄの値として、「ＴＲＵＥ」を書き込むと共に、パラメータＳｅｒｖｉｃｅ＿Ｓｔａｒｔの値として、「ＦＡＬＳＥ」を書き込む。Ｓ１１０７での処理を終えると、制御部３１は、Ｓ１１１４に移行し、図２３に示す統合返信情報生成処理を実行する。

これに対し、Ｓ１１０５にて、処理対象のリクエストサービスＩＤに対応する返信管理情報を、記憶部３３に格納された定期問合せ返信管理テーブルにて特定（検索）することができると、制御部３１は、Ｓ１１０６でＹｅｓと判断し、上記定期問合せ返信情報生成領域に、パラメータＳｅｒｖｉｃｅ＿Ｓｔａｒｔの値として、当該処理対象のリクエストサービスＩＤに対応する返信管理情報が有するサービススタート情報の値を、書き込む（Ｓ１１０８）。

Ｓ１１０８の処理を終えると、制御部３１は、Ｓ１１０９に移行し、上記定期問合せ返信情報生成領域に、パラメータＳｅｒｖｉｃｅ＿Ｃａｎｃｅｌｅｄの値として、当該処理対象のリクエストサービスＩＤに対応する返信管理情報が有するサービスキャンセル情報の値を、書き込む。

Ｓ１１０９の処理を終えると、制御部３１は、Ｓ１１１０に移行し、上記定期問合せ返信情報生成領域に書き込んだパラメータＳｅｒｖｉｃｅ＿Ｓｔａｒｔの値が「ＴＲＵＥ」であるか否か判断し、「ＴＲＵＥ」であると判断すると、上記定期問合せ返信情報生成領域に、パラメータＳｅｒｖｉｃｅ＿ＵＲＬの値として、当該処理対象のリクエストサービスＩＤに対応する返信管理情報が有するサービスＵＲＬ情報の値（文字列）を書き込む（Ｓ１１１１）。その後、Ｓ１１１２に移行する。

一方、上記定期問合せ返信情報生成領域に書き込んだパラメータＳｅｒｖｉｃｅ＿Ｓｔａｒｔの値が「ＴＲＵＥ」ではない（「ＦＡＬＳＥ」である）と判断すると、Ｓ１１１１の処理を実行せずに、Ｓ１１１２に移行する。

Ｓ１１１２に移行すると、制御部３１は、統合問合せ情報における上記処理対象のリクエストサービスＩＤに関連付けられたＲｅｑｕｅｓｔ＿Ｓｔａｔｕｓタグ（処理対象のリクエストサービスＩＤが記述されたＲｅｑｕｅｓｔ＿Ｓｅｒｖｉｃｅタグの間にあるＲｅｑｕｅｓｔ＿Ｓｔａｔｕｓタグ）の値が「ＴＲＵＥ」であるか否か判断し、「ＴＲＵＥ」であると判断すると、Ｓ１１１３に移行して、上記定期問合せ返信情報生成領域に、パラメータＳｅｒｖｉｃｅ＿Ｓｔａｔｕｓの値として、当該処理対象のリクエストサービスＩＤに対応する返信管理情報が有するサービスステータス情報の値を書き込む。その後、Ｓ１１１４に移行する。

一方、Ｓ１１１２にて、統合問合せ情報における上記処理対象のリクエストサービスＩＤに関連付けられたＲｅｑｕｅｓｔ＿Ｓｔａｔｕｓタグの値が「ＴＲＵＥ」ではない（「ＦＡＬＳＥ」である）と判断すると、Ｓ１１１３の処理を実行せずに、Ｓ１１１４に移行する。

Ｓ１１１４に移行すると、制御部３１は、統合返信情報生成処理を実行する。図２３は、制御部３１が実行する統合返信情報生成処理を表すフローチャートであり、図２４は、統合返信情報生成処理で実行される返信判断処理を表すフローチャートである。また、図２５は、統合返信情報の構成を表す説明図である。その他、統合返信情報は、図２５に示すように、マークアップ言語によって記述されており、この統合返信情報で用いられる各タグの定義は表４に示すとおりである。

統合返信情報生成処理を実行すると、制御部３１は、まずＳ１２０１にて、当該統合返信情報生成処理の実行が、Ｓ１１０１にて定期問合せ信号を受信した後、最初の実行であるか否かを判断する。そして、最初の実行であると判断すると、Ｓ１２１１に移行し、統合返信情報を生成するための統合返信情報生成領域をＲＡＭに確保し、その領域（空の統合返信情報）に、ヘッダ情報を書き込む（Ｓ１２１２）。

Ｓ１２１２の処理後、制御部３１は、パラメータＮｕｍＰａｔｔｅｒｎの値を「１」として、ＮｕｍＰａｔｔｅｒｎタグ（文字列＜ＮｕｍＰａｔｔｅｒｎ＞１＜／ＮｕｍＰａｔｔｅｒｎ＞）を生成し、これを、統合返信情報（統合返信情報生成領域）に追加する（Ｓ１２１３）。また、Ｒｅｓｐｏｎｃｅ＿Ｓｅｒｖｉｃｅタグを統合返信情報に追加する（Ｓ１２１４）。その後、返信判断処理（図２４）を実行する。

返信判断処理を実行すると、制御部３１は、Ｓ１３０１にて、処理対象のリクエストサービスＩＤに対応する定期問合せ返信情報（定期問合せ返信情報生成領域に書き込まれた情報）が示すパラメータＳｅｒｖｉｃｅ＿Ｓｔａｒｔの値が「ＴＲＵＥ」であるか否かを判断し、「ＴＲＵＥ」であると判断すると、返信ＯＫと判断する（Ｓ１３０４）。

一方、Ｓ１３０１で「ＴＲＵＥ」ではないと判断すると、制御部３１は、Ｓ１３０２に移行し、上記定期問合せ返信情報が示すパラメータＳｅｒｖｉｃｅ＿Ｃａｎｃｅｌｅｄの値が「ＴＲＵＥ」であるか否かを判断する。

そして、パラメータＳｅｒｖｉｃｅ＿Ｃａｎｃｅｌｅｄの値が「ＴＲＵＥ」であると判断すると、制御部３１は、Ｓ１３０４に移行して、返信ＯＫと判断する。これに対し、パラメータＳｅｒｖｉｃｅ＿Ｃａｎｃｅｌｅｄの値が「ＴＲＵＥ」ではないと判断すると、制御部３１は、Ｓ１３０３にて、上記定期問合せ返信情報に、パラメータＳｅｒｖｉｃｅ＿Ｓｔａｔｕｓの値が存在するか否か判断する。そして、存在すると判断すると、Ｓ１３０４に移行して、返信ＯＫと判断する。一方、Ｓ１３０３で存在しないと判断すると、Ｓ１３０５に移行して、返信ＮＧと判断する。その後、当該返信判断処理を終了する。

Ｓ１２１５での返信判断処理を終了すると、制御部３１は、Ｓ１２１６にて、返信判断処理での判断が、返信ＯＫとの判断であるか否かを判断する。そして、返信ＯＫではない（返信ＮＧである）と判断すると、当該統合返信情報生成処理を終了する。一方、返信ＯＫであると判断すると、Ｓ１２１７に移行する。

Ｓ１２１７に移行すると、制御部３１は、処理対象のリクエストサービスＩＤに対応する定期問合せ返信情報（定期問合せ返信情報生成領域に書き込まれた情報）に基づいて、Ｒｅｓｐｏｎｃｅ＿Ｓｅｒｖｉｃｅタグの間（即ち、＜Ｒｅｓｐｏｎｃｅ＿Ｓｅｒｖｉｃｅ＞と＜／Ｒｅｓｐｏｎｃｅ＿Ｓｅｒｖｉｃｅ＞との間）に、Ｓｅｒｖｉｃｅ＿Ｓｔａｒｔタグを書き込む。

例えば、定期問合せ返信情報におけるパラメータＳｅｒｖｉｃｅ＿Ｓｔａｒｔの値が「ＴＲＵＥ」である場合、Ｓｅｒｖｉｃｅ＿Ｓｔａｒｔタグとして、文字列＜Ｓｅｒｖｉｃｅ＿Ｓｔａｒｔ＞ＴＲＵＥ＜／Ｓｅｒｖｉｃｅ＿Ｓｔａｒｔ＞）を生成し、これを統合返信情報に書き込む。

また、Ｓ１２１７の処理を終えると、制御部３１は、処理対象のリクエストサービスＩＤに対応する定期問合せ返信情報に基づいて、Ｒｅｓｐｏｎｃｅ＿Ｓｅｒｖｉｃｅタグの間に、Ｓｅｒｖｉｃｅ＿ＵＲＬタグを書き込む（Ｓ１２１８）。尚、定期問合せ返信情報に、パラメータＳｅｒｖｉｃｅ＿ＵＲＬの値が存在しない場合には、Ｓｅｒｖｉｃｅ＿ＵＲＬタグとして、文字列＜Ｓｅｒｖｉｃｅ＿ＵＲＬ＞＜／Ｓｅｒｖｉｃｅ＿ＵＲＬ＞を生成し、パラメータＳｅｒｖｉｃｅ＿ＵＲＬの値が存在する場合には、その値を記述したＳｅｒｖｉｃｅ＿ＵＲＬタグを生成して、統合返信情報に書き込む。

Ｓ１２１８の処理を終えると、制御部３１は、処理対象のリクエストサービスＩＤに対応する定期問合せ返信情報に基づいて、Ｒｅｓｐｏｎｃｅ＿Ｓｅｒｖｉｃｅタグの間に、Ｓｅｒｖｉｃｅ＿Ｓｔａｔｕｓタグを書き込む（Ｓ１２１９）。

この際、定期問合せ返信情報に、パラメータＳｅｒｖｉｃｅ＿Ｓｔａｔｕｓの値が存在しない場合には、Ｓｅｒｖｉｃｅ＿Ｓｔａｔｕｓタグとして、文字列＜Ｓｅｒｖｉｃｅ＿Ｓｔａｔｕｓ＞＜／Ｓｅｒｖｉｃｅ＿Ｓｔａｔｕｓ＞を生成し、パラメータＳｅｒｖｉｃｅ＿Ｓｔａｔｕｓの値が存在する場合には、その値を記述したＳｅｒｖｉｃｅ＿Ｓｔａｔｕｓタグを生成し、これを統合返信情報に書き込む。

また、Ｓ１２１９の処理を終えると、制御部３１は、処理対象のリクエストサービスＩＤに対応する定期問合せ返信情報に基づいて、Ｒｅｓｐｏｎｃｅ＿Ｓｅｒｖｉｃｅタグの間に、Ｓｅｒｖｉｃｅ＿Ｃａｎｃｅｌｅｄタグを書き込む（Ｓ１２２０）。

例えば、定期問合せ返信情報におけるパラメータＳｅｒｖｉｃｅ＿Ｃａｎｃｅｌｅｄの値が「ＦＡＬＳＥ」である場合、Ｓｅｒｖｉｃｅ＿Ｃａｎｃｅｌｅｄタグとして、文字列＜Ｓｅｒｖｉｃｅ＿Ｃａｎｃｅｌｅｄ＞ＦＡＬＳＥ＜／Ｓｅｒｖｉｃｅ＿Ｃａｎｃｅｌｅｄ＞）を生成し、これを統合返信情報に書き込む。

Ｓ１２２０の処理を終えると、制御部３１は、パラメータＮｕｍ＿Ｓｅｒｖｉｃｅ＿ＩＤの値を「１」として、Ｎｕｍ＿Ｓｅｒｖｉｃｅ＿ＩＤタグ（文字列＜Ｎｕｍ＿Ｓｅｒｖｉｃｅ＿ＩＤ＞１＜／Ｎｕｍ＿Ｓｅｒｖｉｃｅ＿ＩＤ＞）を生成し、これを統合返信情報におけるＲｅｓｐｏｎｃｅ＿Ｓｅｒｖｉｃｅタグの間に書き込む（Ｓ１２２１）。

そして、Ｓ１２２１の処理を終えるとＳ１２２２に移行し、処理対象のリクエストサービスＩＤの値を、パラメータＲｅｑｕｅｓｔ＿Ｓｅｒｖｉｃｅ＿ＩＤの値として、Ｒｅｑｕｅｓｔ＿Ｓｅｒｖｉｃｅ＿ＩＤタグ（文字列＜Ｒｅｑｕｅｓｔ＿Ｓｅｒｖｉｃｅ＿ＩＤ＞（リクエストサービスＩＤ）＜／Ｒｅｑｕｅｓｔ＿Ｓｅｒｖｉｃｅ＿ＩＤ＞）を生成し、これを統合返信情報におけるＲｅｓｐｏｎｃｅ＿Ｓｅｒｖｉｃｅタグの間に書き込む。その後、当該統合返信情報生成処理を終了する。

一方、Ｓ１２０１にて、当該統合返信情報生成処理の実行が、Ｓ１１０１の処理後、初回ではなく二回目以降の実行であると判断すると、制御部３１は、Ｓ１２２５で返信判断処理（図２４）を実行し、Ｓ１２２６で、返信判断処理の判断結果が返信ＯＫであるか否かを判断する。そして、返信ＯＫではない（返信ＮＧである）と判断すると、当該統合返信処理を終了する。

これに対し、Ｓ１２２６で、返信ＯＫであると判断すると、制御部３１は、Ｓ１２２７に移行し、当該処理対象のリクエストサービスＩＤの定期問合せ返信情報と同じパラメータ値のＲｅｓｐｏｎｃｅ＿Ｓｅｒｖｉｃｅタグがあるか否か判断する。即ち、当該処理対象のリクエストサービスＩＤの定期問合せ返信情報が有するリクエストサービスＩＤ以外の情報（パラメータＳｅｒｖｉｃｅ＿Ｓｔａｒｔ，Ｓｅｒｖｉｃｅ＿ＵＲＬ，Ｓｅｒｖｉｃｅ＿Ｓｔａｔｕｓ，Ｓｅｒｖｉｃｅ＿Ｃａｎｃｅｌｅｄの値）が同一であるＲｅｓｐｏｎｃｅ＿Ｓｅｒｖｉｃｅタグが存在するか否か判断する。

そして、同じパラメータ値のＲｅｓｐｏｎｃｅ＿Ｓｅｒｖｉｃｅタグがあると判断すると、制御部３１は、そのＲｅｓｐｏｎｃｅ＿Ｓｅｒｖｉｃｅタグの間にあるＮｕｍ＿Ｓｅｒｖｉｃｅ＿ＩＤタグの値を更新する（Ｓ１２２８）。例えば、統合返信情報における更新前のＮｕｍ＿Ｓｅｒｖｉｃｅ＿ＩＤタグが、文字列＜Ｎｕｍ＿Ｓｅｒｖｉｃｅ＿ＩＤ＞１＜／Ｎｕｍ＿Ｓｅｒｖｉｃｅ＿ＩＤ＞である場合には、これを＜Ｎｕｍ＿Ｓｅｒｖｉｃｅ＿ＩＤ＞２＜／Ｎｕｍ＿Ｓｅｒｖｉｃｅ＿ＩＤ＞に更新する。

Ｓ１２２８の処理を終えると、制御部３１は、処理対象のリクエストサービスＩＤの値を、パラメータＲｅｑｕｅｓｔ＿Ｓｅｒｖｉｃｅ＿ＩＤの値として、Ｒｅｑｕｅｓｔ＿Ｓｅｒｖｉｃｅ＿ＩＤタグを生成し、これを統合返信情報における上記パラメータ値が同一であるＲｅｓｐｏｎｃｅ＿Ｓｅｒｖｉｃｅタグの間に書き込む（Ｓ１２２９）。その後、当該統合返信情報生成処理を終了する。

また、Ｓ１２２７で、同じパラメータ値のＲｅｓｐｏｎｃｅ＿Ｓｅｒｖｉｃｅタグがないと判断すると、制御部３１は、Ｓ１２３１に移行し、統合返信情報のＮｕｍＰａｔｔｅｒｎタグにおけるパラメータＮｕｍＰａｔｔｅｒｎの値を更新する。例えば、統合返信情報のＮｕｍＰａｔｔｅｒｎタグが文字列＜ＮｕｍＰａｔｔｅｒｎ＞１＜／ＮｕｍＰａｔｔｅｒｎ＞である場合には、これを、文字列＜ＮｕｍＰａｔｔｅｒｎ＞２＜／ＮｕｍＰａｔｔｅｒｎ＞に更新する。

但し、Ｓ１２３１の実行時において、統合返信情報に、空のＲｅｓｐｏｎｃｅ＿Ｓｅｒｖｉｃｅタグがある場合（具体的には、Ｓ１２１６でＮｏと判断した後の、最初のＳ１２３１実行時）には、例外的に、パラメータＮｕｍＰａｔｔｅｒｎの値を更新しないこととする。

Ｓ１２３１の処理を終えると、制御部３１は、Ｓ１２３２に移行し、既に統合返信情報に存在するＲｅｓｐｏｎｃｅ＿Ｓｅｒｖｉｃｅタグに続く領域に、新しいＲｅｓｐｏｎｃｅ＿Ｓｅｒｖｉｃｅタグを書き込む。但し、Ｓ１２３２の実行時において、統合返信情報に、空のＲｅｓｐｏｎｃｅ＿Ｓｅｒｖｉｃｅタグがある場合には、例外的に、新しいＲｅｓｐｏｎｃｅ＿Ｓｅｒｖｉｃｅタグの書込を実行しないこととする。

Ｓ１２３２の処理を終えると、制御部３１は、Ｓ１２３３に移行し、処理対象のリクエストサービスＩＤに対応する定期問合せ返信情報に基づいて、新しいＲｅｓｐｏｎｃｅ＿Ｓｅｒｖｉｃｅタグ（空のＲｅｓｐｏｎｃｅ＿Ｓｅｒｖｉｃｅタグ）の間に、Ｓｅｒｖｉｃｅ＿Ｓｔａｒｔタグを書き込む。

例えば、定期問合せ返信情報におけるパラメータＳｅｒｖｉｃｅ＿Ｓｔａｒｔの値が「ＦＡＬＳＥ」である場合、Ｓｅｒｖｉｃｅ＿Ｓｔａｒｔタグとして、文字列＜Ｓｅｒｖｉｃｅ＿Ｓｔａｒｔ＞ＦＡＬＳＥ＜／Ｓｅｒｖｉｃｅ＿Ｓｔａｒｔ＞）を生成し、これを統合返信情報に書き込む。

また、Ｓ１２３３の処理を終えると、制御部３１は、処理対象のリクエストサービスＩＤに対応する定期問合せ返信情報に基づいて、上記Ｒｅｓｐｏｎｃｅ＿Ｓｅｒｖｉｃｅタグの間に、Ｓｅｒｖｉｃｅ＿ＵＲＬタグを書き込む（Ｓ１２３４）。また、処理対象のリクエストサービスＩＤに対応する定期問合せ返信情報に基づき、上記Ｒｅｓｐｏｎｃｅ＿Ｓｅｒｖｉｃｅタグの間に、Ｓｅｒｖｉｃｅ＿Ｓｔａｔｕｓタグを書き込む（Ｓ１２３５）。

そして、Ｓ１２３５の処理を終えると、制御部３１は、処理対象のリクエストサービスＩＤに対応する定期問合せ返信情報に基づいて、Ｒｅｓｐｏｎｃｅ＿Ｓｅｒｖｉｃｅタグの間に、Ｓｅｒｖｉｃｅ＿Ｃａｎｃｅｌｅｄタグを書き込む（Ｓ１２３６）。この後、パラメータＮｕｍ＿Ｓｅｒｖｉｃｅ＿ＩＤの値を「１」として、Ｎｕｍ＿Ｓｅｒｖｉｃｅ＿ＩＤタグを生成し、これを統合返信情報における上記Ｒｅｓｐｏｎｃｅ＿Ｓｅｒｖｉｃｅタグの間に書き込む（Ｓ１２３７）。

Ｓ１２３７の処理を終えると、制御部３１は、処理対象のリクエストサービスＩＤの値を、パラメータＲｅｑｕｅｓｔ＿Ｓｅｒｖｉｃｅ＿ＩＤの値として、Ｒｅｑｕｅｓｔ＿Ｓｅｒｖｉｃｅ＿ＩＤタグを生成し、これを統合返信情報における上記Ｒｅｓｐｏｎｃｅ＿Ｓｅｒｖｉｃｅタグの間に書き込む（Ｓ１２３８）。その後、当該統合返信情報生成処理を終了する。

このようにしてＳ１１１４（図２２）で統合返信情報生成処理を実行すると、制御部３１は、Ｓ１１０２に移行して、統合問合せ情報の中から、次の処理対象（未処理のリクエストサービスＩＤ）を選択する。ここで、未処理のリクエストサービスＩＤが存在しないと、制御部３１は、Ｓ１１１５に移行して、統合返信情報生成領域に記憶されている統合返信情報を格納した応答信号を生成し、これを、通信部３２を介して、定期問合せ信号送信元（問合せ元）の複合機１０に送信する。その後、Ｓ１１０１に移行して、次の定期問合せ信号を受信するまで待機する。

次に、ブログ検索サービスとして、利用登録された複合機１０に対し提供する情報を生成するブログ検索処理について説明する。図２６は、機能サーバ３０の制御部３１が実行するブログ検索処理を表すフローチャートである。このブログ検索処理は、機能サーバ３０の動作中、所定期間毎に、繰返し実行される。

ブログ検索処理を実行すると、制御部３１は、まずＳ１４０１にて、ブログ検索サービスに対応するリクエストサービスＩＤ管理テーブルから、処理対象のリクエストサービスＩＤを、一つ選択する。ここで、上記リクエストサービスＩＤ管理テーブルにおいて処理対象のリクエストサービスＩＤが存在しない、即ち、Ｓ１４０３以降の処理対象となっていない未処理のリクエストサービスＩＤが存在しない場合には、Ｓ１４０２でＮｏと判断して、当該ブログ検索処理を終了する。

一方、処理対象（未処理）のリクエストサービスＩＤが存在すると、制御部３１は、Ｓ１４０２でＹｅｓと判断し、処理対象のリクエストサービスＩＤに対応する定期問合せ返信管理テーブル内の返信管理情報が有するサービススタート情報を、値「ＦＡＬＳＥ」に更新する（Ｓ１４０３）。

その後、当該処理対象のリクエストサービスＩＤに関連付けられてリクエストサービスＩＤ管理テーブルに記憶されているパラメータの値を、キーワードに設定すると共に、予め定められた特定のブログサイトにアクセスし、そのブログサイトに掲載された新しい投稿群の中から、上記設定したキーワードを有する投稿を検索する（Ｓ１４０４）。

この検索時において、リクエストサービスＩＤ管理テーブルに記憶されているパラメータの値が不正な値であるなどし、エラーが発生すると、制御部３１は、Ｓ１４０５でＹｅｓと判断し、当該処理対象のリクエストサービスＩＤに対応する定期問合せ返信管理テーブル内の返信管理情報が有するサービスキャンセル情報を、値「ＴＲＵＥ」に更新する（Ｓ１４０６）。

更に、エラーの発生原因に応じたサービスステータスの値を導出し、この導出値を、当該処理対象のリクエストサービスＩＤに対応する定期問合せ返信管理テーブル内のサービスステータス情報に、反映させる（Ｓ１４０７）。その後、Ｓ１４０１に移行して、未処理のリクエストサービスＩＤを、リクエストサービスＩＤ管理テーブル内から一つ選択する。

一方、Ｓ１４０４における検索が正常に終了すると、制御部３１は、Ｓ１４０５でＮｏと判断して、Ｓ１４０８に移行し、上記検索の結果、上記設定されたキーワードを含む新しい投稿がブログサイトから発見されたか否か判断する。そして、新しい投稿が発見されていないと判断すると、Ｓ１４０１に移行する。

また、Ｓ１４０８において、上記設定されたキーワードを含む新しい投稿がブログサイトから発見されたと判断すると、制御部３１は、Ｓ１４０９に移行し、上記キーワードを含む投稿の内容を表した提供用データを生成する。そして、これを、記憶部３３に保存すると共に、Ｓ１４１０に移行し、上記保存した提供用データのダウンロード先のＵＲＬ情報（例えば、文字列”ｈｔｔｐ：／／＊＊＊＊．ｃｏ．ｊｐ／ｃｇｉ／ｂｌｏｇ？ｆ＝＊＊＊＊”等）を生成する。また、上記定期問合せ返信管理テーブルにおける当該処理対象のリクエストサービスＩＤに対応するサービスＵＲＬ情報を、上記生成したダウンロード先（即ち、サービス提供先）のＵＲＬ情報に変更する（Ｓ１４１１）。

Ｓ１４１１での処理を終えると、制御部３１は、上記定期問合せ返信管理テーブルにおける当該処理対象のリクエストサービスＩＤに対応するサービススタート情報を、値「ＴＲＵＥ」に変更する（Ｓ１４１２）。その後、Ｓ１４０１に移行し、リクエストサービスＩＤ管理テーブルから、未処理のリクエストサービスＩＤを一つ選択する。そして、リクエストサービスＩＤ管理テーブルに列挙された全リクエストサービスＩＤについて、Ｓ１４０３以降の処理を実行すると、Ｓ１４０２にてＮｏと判断し、当該ブログ検索処理を終了する。

次に、上記ローカルニュース提供サービスについて利用登録された複合機１０に対し提供する情報を生成するニュース情報生成処理について説明する。尚、図２７は、機能サーバ３０の制御部３１が実行するニュース情報生成処理を表すフローチャートである。このニュース情報生成処理は、機能サーバ３０の動作中、所定期間毎に、繰返し行われる。

ニュース情報生成処理を実行すると、制御部３１は、まずローカルニュース提供サービスに対応するリクエストサービスＩＤ管理テーブルから、処理対象のリクエストサービスＩＤを一つ選択する（Ｓ１５０１）。ここで、処理対象のリクエストサービスＩＤが存在しない、即ち、後述するＳ１５０３以降の処理対象となっていない未処理のリクエストサービスＩＤが存在しない場合には、Ｓ１５０２でＮｏと判断して、当該ニュース情報生成処理を終了する。

一方、処理対象（未処理）のリクエストサービスＩＤが存在すると、制御部３１は、Ｓ１５０２でＹｅｓと判断して、処理対象のリクエストサービスＩＤに対応する定期問合せ返信管理テーブル内の返信管理情報が有するサービススタート情報を、値「ＦＡＬＳＥ」に更新する（Ｓ１５０３）。

その後、当該処理対象のリクエストサービスＩＤに関連付けられてリクエストサービスＩＤ管理テーブルに記憶されている各パラメータの値が不正な値でないか否か判断し（Ｓ１５０４）、不正な値であると判断すると、エラーが生じたとして、当該処理対象のリクエストサービスＩＤに対応する定期問合せ返信管理テーブル内のサービスキャンセル情報を、値「ＴＲＵＥ」に更新する（Ｓ１５０５）。

更に、エラーの発生原因に応じたサービスステータスの値を導出し、この導出値を、当該処理対象のリクエストサービスＩＤに対応する定期問合せ返信管理テーブル内のサービスステータス情報に、反映させる（Ｓ１５０６）。その後、Ｓ１５０１に移行して、未処理のリクエストサービスＩＤを、リクエストサービスＩＤ管理テーブルから一つ選択する。

これに対し、Ｓ１５０４にて、各パラメータの値が不正な値でない（即ち、適切な値である）と判断すると、制御部３１は、Ｓ１５０７に移行し、当該処理対象のリクエストサービスＩＤに関連付けられてリクエストサービスＩＤ管理テーブルに記憶されているパラメータＡｄｄｒｅｓｓ（図７，１５参照）の値に合致する地域のローカルニュースデータを、特定のデータベース（図示せず）から取得する。また、Ｓ１５０７の処理を終えると、Ｓ１５０８に移行し、上記取得したローカルニュースデータを、パラメータＮｕｍＰａｇｅｓ（図７，１５参照）の値に合致する頁数分の提供用データ（ＰＤＦデータ等）に変換して、提供用データを生成する。その後、この提供用データを、記憶部３３に保存する。

Ｓ１５０８での処理を終えると、制御部３１は、上記保存した提供用データのダウンロード先のＵＲＬ情報を生成し（Ｓ１５０９）、上記定期問合せ返信管理テーブルにおける当該処理対象のリクエストサービスＩＤに対応するサービスＵＲＬ情報を、上記生成したダウンロード先（サービス提供先）のＵＲＬ情報に変更する（Ｓ１５１０）。

Ｓ１５１０での処理を終えると、制御部３１は、上記定期問合せ返信管理テーブルにおける当該処理対象のリクエストサービスＩＤに対応するサービススタート情報を、値「ＴＲＵＥ」に変更する（Ｓ１５１１）。その後、Ｓ１５０１に移行し、リクエストサービスＩＤ管理テーブルから、未処理のリクエストサービスＩＤを一つ選択する。そして、リクエストサービスＩＤ管理テーブルに列挙された全リクエストサービスＩＤについて、Ｓ１５０３以降の処理を実行すると、Ｓ１５０２にてＮｏと判断し、当該ニュース情報生成処理を終了する。

次に、統合返信情報を受信し、この統合返信情報に基づいてサービスを受けるために、複合機１０の制御部１１が実行する統合返信情報受信処理について、図２８を用いて説明する。尚、図２８は、複合機１０の制御部１１が実行する統合返信情報受信処理を表すフローチャートである。

統合返信情報受信処理を実行すると、制御部１１は、通信部１５を介して、機能サーバ３０から送信されてくる上記定期問合せ信号に対する応答信号（統合返信情報）を受信するまで待機し（Ｓ１６０１）、応答信号を受信すると、その応答信号に含まれる統合返信情報の中から、処理対象のリクエストサービスＩＤを一つ選択する（Ｓ１６０２）。ここで、処理対象のリクエストサービスＩＤが存在しない、即ち、Ｓ１６０４以降の処理対象となっていない未処理のリクエストサービスＩＤが存在しない場合には、Ｓ１６０３でＮｏと判断して、Ｓ１６０６に移行し、処理対象（未処理）のリクエストサービスＩＤが存在する場合には、Ｓ１６０３でＹｅｓと判断して、Ｓ１６０４に移行する。

Ｓ１６０４に移行すると、制御部１１は、上記処理対象のリクエストサービスＩＤに対応付けて、統合返信情報に記載されているＳｅｒｖｉｃｅ＿Ｓｔａｔｕｓタグに、パラメータＳｅｒｖｉｃｅ＿Ｓｔａｔｕｓの値があるか否か判断する。即ち、上記処理対象のリクエストサービスＩＤが記載されたＲｅｓｐｏｎｃｅ＿Ｓｅｒｖｉｃｅタグの間に記載されたＳｅｒｖｉｃｅ＿Ｓｔａｔｕｓタグの間に、値が記載されているか否かを判断する。

そして、パラメータＳｅｒｖｉｃｅ＿Ｓｔａｔｕｓの値がない（即ち、＜Ｓｅｒｖｉｃｅ＿Ｓｔａｔｕｓ＞＜／Ｓｅｒｖｉｃｅ＿Ｓｔａｔｕｓ＞）であると判断すると、Ｓ１６０２に移行する。一方、パラメータＳｅｒｖｉｃｅ＿Ｓｔａｔｕｓの値があると判断すると、Ｓ１６０５に移行し、パラメータＳｅｒｖｉｃｅ＿Ｓｔａｔｕｓの値に対応するステータス情報を、表示部１９のディスプレイ１９ａに表示する。その後、制御部１１は、Ｓ１６０２に移行し、未処理のリクエストサービスＩＤを一つ処理対象に選択して、再び、Ｓ１６０３以降の処理を実行する。

そして、統合返信情報内に記載された全てのリクエストサービスＩＤについて、Ｓ１６０４以降の処理を実行すると、Ｓ１６０３でＮｏと判断して、Ｓ１６０６に移行し、値「ＴＲＵＥ」が記載されたＳｅｒｖｉｃｅ＿Ｓｔａｒｔタグに関連付けられたリクエストサービスＩＤの全てについて、そのリクエストサービスＩＤに対応するサービスを、機能サーバ３０から受けたか否か判断する。

値「ＴＲＵＥ」が記載されたＳｅｒｖｉｃｅ＿Ｓｔａｒｔタグに関連付けられたリクエストサービスＩＤの中に、機能サーバ３０からサービスを受けていないリクエストサービスＩＤがある場合、制御部１１は、Ｓ１６０６でＮｏと判断して、Ｓ１６０７に移行する。そして、上記統合返信情報の中から、処理対象のリクエストサービスＩＤを一つ選択する。

ここで、処理対象のリクエストサービスＩＤが存在しない、即ち、Ｓ１６０９以降の処理対象となっていない未処理のリクエストサービスＩＤが存在しない場合には、Ｓ１６０８でＮｏと判断して、Ｓ１６０６に移行し、処理対象（未処理）のリクエストサービスＩＤが存在する場合には、Ｓ１６０８でＹｅｓと判断して、Ｓ１６０９に移行する。

Ｓ１６０９に移行すると、制御部１１は、処理対象のリクエストサービスＩＤに対応付けて、統合返信情報に記載されたＳｅｒｖｉｃｅ＿Ｓｔａｒｔタグに、値「ＴＲＵＥ」が記載されているか否か判断する。即ち、上記処理対象のリクエストサービスＩＤが記載されたＲｅｓｐｏｎｃｅ＿Ｓｅｒｖｉｃｅタグの間に記載されたＳｅｒｖｉｃｅ＿Ｓｔａｒｔタグの間に、値「ＴＲＵＥ」が記載されているか否かを判断する。

ここで、Ｓｅｒｖｉｃｅ＿Ｓｔａｒｔタグに、値「ＴＲＵＥ」が記載されていないと判断すると、制御部１１は、Ｓ１６０７に移行し、値「ＴＲＵＥ」が記載されていると判断すると、Ｓ１６１０に移行して、当該処理対象のリクエストサービスＩＤに対応するサービスを機能サーバ３０から受ける際に用いる入出力デバイス（読取部１３，記録部１４，音入力部１７，音出力部１８）が、他のプロセス（サービス）によって動作（使用）中であるか否かを、定期問合せ管理テーブルの利用デバイス情報に基づいて、判断する。

そして、上記デバイスが動作中であると判断すると、Ｓ１６０７に移行し、上記デバイスが動作中ではないと判断すると、Ｓ１６１１に移行して、処理対象のリクエストサービスＩＤに関連付けられた統合返信情報のＳｅｒｖｉｃｅ＿ＵＲＬタグの値を、を引数に設定し、サービス受信処理（図１０）のプロセスを起動する。

その後、制御部３１は、Ｓ１６０７に移行し、統合返信情報から、未処理のリクエストサービスＩＤを選択し、このリクエストサービスＩＤに対応付けて統合返信情報に記載されたＳｅｒｖｉｃｅ＿Ｓｔａｒｔタグに、値「ＴＲＵＥ」が記載されている場合には、前回起動したサービス受信処理のプロセスと並行して、更にもう一つ、サービス受信処理のプロセス起動する。但し、並行処理するのは、Ｓ１６１０でＮｏと判断された場合のみ、即ち、現在もなお受信中のサービスとは、異なる入出力デバイスを用いるサービスについてのプロセスのみである。

即ち、Ｓ１６０７〜Ｓ１６１１の過程では、Ｓｅｒｖｉｃｅ＿Ｓｔａｒｔタグに、値「ＴＲＵＥ」が記載されているリクエストサービスＩＤに対応するサービスであって、異なる入出力デバイスを利用するサービスのみのサービス受信プロセスを並行して実行する。

これに対し、同一の入出力デバイスを利用するサービスの受信プロセスについては、Ｓ１６０８にてＮｏと判断し、Ｓ１６０６にてＮｏと判断して、再び１６０７以降の処理を実行することで、シリアルに実行する。

そして、値「ＴＲＵＥ」が記載されたＳｅｒｖｉｃｅ＿Ｓｔａｒｔタグに関連付けられたリクエストサービスＩＤの全てについて、そのリクエストサービスＩＤに対応するサービスを、機能サーバ３０から受けたと判断すると（換言すると、サービス受信処理のプロセスを起動したと判断すると）、制御部１１は、Ｓ１６０６でＹｅｓと判断して、Ｓ１６０１に移行する。その後、次の統合返信情報を受信するまで待機する。

次に、機能サーバ３０で実行されるサービス提供にかかるプロセスについて説明する。複合機１０の制御部１１は、ブログ検索サービス又はローカルニュース提供サービスについてのリクエストサービスＩＤを処理した結果、Ｓ１６１１にてサービス受信処理のプロセスを起動すると、そのサービスＵＲＬ情報に基づいて、機能サーバ３０にアクセスし、機能サーバ３０に、図２９に示す定期サービス提供処理を実行させる（Ｓ３０１）。図２９は、機能サーバ３０の制御部３１が実行する定期サービス提供処理を表すフローチャートである。尚、サービスＵＲＬ情報には、ブログ検索サービス、ローカルニュース提供サービスに関して、図２９に示す定期サービス提供処理が実行される機能サーバ３０側のＵＲＬ情報（Ｓ４０５で図２９に示す定期サービス提供処理のプロセスが起動される機能サーバ３０側のＵＲＬ情報）が記載されていることとする。

定期サービス提供処理を実行すると、制御部３１は、Ｓ１７０１で、初期化処理を実行し、続くＳ１７０２で、サービス側印刷ジョブ（図３０参照。詳細後述）を起動する。続いて、Ｓ１７０３では、「印刷ジョブ起動指令」を複合機指令として出力する。具体的には、Ｓ４０５で生成したセッションＩＤに対応する返信情報格納領域に対して、「印刷ジョブ起動指令」を書き込む処理を行う。

これによって、「印刷ジョブ起動指令」は、サービス制御情報処理を介し、複合機指令として、複合機１０に送信される。尚、この「印刷ジョブ起動指令」には、Ｓ１７０２で起動したサービス側印刷ジョブについてのジョブＩＤとジョブの通信先ＵＲＬ情報とが含まれる。

Ｓ１７０３での処理を終えると、制御部３１は、Ｓ１７０４に移行し、後述するサービス側印刷ジョブから印刷準備完了の通知を受けたか否か判断し、受けていない場合には、Ｓ１７０５に移行して、上記サービス側印刷ジョブから停止の通知を受けたか否か判断する。そして、停止の通知を受けていない場合には、Ｓ１７０４に処理を戻すことで、上記サービス側印刷ジョブから印刷準備完了の通知、若しくは、停止の通知を受けるまで待機する。そして、停止の通知を受けると、Ｓ１７０５でＹｅｓと判断して、Ｓ１７０８に移行する。一方、印刷準備完了の通知を受けると、Ｓ１７０４でＹｅｓと判断して、Ｓ１７０６に移行する。

Ｓ１７０６に移行すると、制御部３１は、当該定期サービス提供処理のプロセスを起動する際に複合機１０側からＵＲＬ情報にて指定されたダウンロード対象の提供用データを、記憶部３３から読み出し、この提供用データを、複合機１０の記録部１４の能力に適合した印刷データに変換する。その後、制御部３１は、サービス側印刷ジョブに、上記変換した印刷データを提供することにより、サービス側印刷ジョブを介して、上記変換した印刷データを、アクセス元の複合機１０に向けて出力する（Ｓ１７０７）。

また、Ｓ１７０７の処理を終えると、制御部３１は、Ｓ１７０８に移行して、サービス側印刷ジョブが終了するまで待機し、印刷ジョブが終了すると、「印刷ジョブ終了指令」を複合機指令として出力する。具体的には、Ｓ４０５で生成したセッションＩＤに対応する返信情報格納領域に対して、「印刷ジョブ終了指令」を書き込む処理を行う。

これによって、「印刷ジョブ終了指令」は、サービス制御情報処理を介し、複合機指令として、複合機１０に送信される。尚、この「印刷ジョブ終了指令」には、ジョブＩＤとジョブの通信先ＵＲＬ情報とが含まれる。

また、「印刷ジョブ終了指令」の出力が終了すると、制御部３１は、Ｓ１７０９に移行し、「サービス終了指令」を、複合機指令として出力する。これにより、「サービス終了指令」は、複合機１０にて受信される。Ｓ１７０９での処理を終えると、機能サーバ３０の制御部３１は、当該定期サービス提供処理を終了する。

次に、定期サービス提供処理（図２９）のＳ１７０２にて起動されるサービス側印刷ジョブについて説明する。図３０は、機能サーバ３０の制御部３１が実行するサービス側印刷ジョブを表すフローチャートである。尚、このサービス側印刷ジョブは、他の処理と並行して実行される。

サービス側印刷ジョブの実行を開始すると、制御部３１は、まずＳ１８０１にて、複合機１０から「複合機状態情報」を受信するまで待機する。尚、「複合機状態情報」は、複合機１０の制御部１１により実行される後述の出力ジョブ（図３１）におけるＳ１９０４で送信される。

この「複合機状態情報」を受信すると、制御部３１は、Ｓ１８０２に移行して、エラーカウントを初期化し、更に、記録部１４に設定すべきパラメータを、複合機パラメータとして複合機１０へ送信する（Ｓ１８０３）。

Ｓ１８０３での処理を終えると、制御部３１は、Ｓ１８０４に移行し、複合機１０において複合機パラメータが正常に受信されたか否かを判断する。具体的には、複合機１０の制御部１１により実行される出力ジョブ（図３１）におけるＳ１９０９の処理により、「複合機受取状況」として「正常受取」が通知された場合に正常に受信されたと判断し、Ｓ１９０８の処理により、「複合機受取状況」として「異常受取」が通知された場合に正常に受信されなかったと判断する。

Ｓ１８０４で、複合機パラメータが正常に受信されなかったと判断すると、制御部３１は、Ｓ１８０５へ移行し、正常に受信されなかったと判断された回数が２回目であるか否かを判断する。具体的には、Ｓ１８０２で初期化したエラーカウントに基づき判断する。

そして、Ｓ１８０５で、２回目でない（１回目である）と判断した場合には、Ｓ１８０６へ移行し、エラーカウントをカウントアップした後、Ｓ１８０３へ移行する。
一方、Ｓ１８０５で、２回目であると判断した場合には、Ｓ１８０７へ移行し、起動元のプロセス（定期サービス提供処理（図２９）のプロセス）へ停止を通知する。その後、Ｓ１８１１にて、正常終了ではない（異常終了である）と判断し、Ｓ１８１２にて、異常終了である旨の情報を、「サービス状態情報」として複合機１０へ送信した後、当該サービス側印刷ジョブを終了する。

また、Ｓ１８０４で、複合機パラメータが正常に受信されたと判断した場合には、Ｓ１８０８へ移行し、起動元の定期サービス提供処理のプロセスへ印刷準備完了を通知する。その後、Ｓ１８０９へ移行し、上述のＳ１７０６にて生成された印刷データを順次複合機１０へ送信する。

Ｓ１８０９での処理を終えると、制御部３１は、続くＳ１８１０にて、複合機１０からの「複合機状態情報」を受信するまで待機し、「複合機状態情報」を受信すると、Ｓ１８１１に移行する。尚、「複合機状態情報」は、複合機１０の制御部１１により実行される出力ジョブ（図３１）におけるＳ１９１３の処理で送信される。

Ｓ１８１１に移行すると、制御部３１は、その後、印刷データの送信処理が正常に終了したか否か判断し、正常に終了していないと判断すると、Ｓ１８１２に移行し、正常に終了していると判断すると、Ｓ１８１３に移行して、正常終了である旨の情報を、「サービス状態情報」として複合機１０へ送信する。その後、当該サービス側印刷ジョブを終了する。

次に、定期サービス提供処理（図２９）のＳ１７０３にて出力される「印刷ジョブ起動指令」を受けて、複合機１０の制御部１１がＳ３５６にて起動する出力ジョブについて、図３１のフローチャートを用いて説明する。尚、図３１は、複合機１０の制御部１１が実行する出力ジョブを表すフローチャートである。

出力ジョブを実行すると、制御部１１は、Ｓ１９０１で、出力装置（印刷ジョブ起動指令を受けた場合には記録部１４、スピーカジョブ起動指令を受けた場合には、音出力部１８）がビジー状態であるか否かを判断する。具体的には、出力装置がビジー状態であるか否かを表すビジーフラグＦｏに基づき、ビジーフラグＦｏが立っている場合にはビジー状態であると判断し、ビジーフラグＦｏが下りている場合にはビジー状態でないと判断する。

ここで、出力装置がビジー状態であると判断すると、制御部１１は、Ｓ１９０２へ移行し、出力装置のビジー状態が解除されるまで待機した後、Ｓ１９０１へ移行する。一方、Ｓ１９０１で、ビジー状態でないと判断した場合には、Ｓ１９０３へ移行し、ビジーフラグＦｏを立てる。その後、制御部１１は、「複合機状態情報」を機能サーバ３０へ送信する（Ｓ１９０４）。尚、ここで送信される「複合機状態情報」には、セッションＩＤ、ジョブＩＤ等が含まれる。

Ｓ１９０４の処理を終えると、制御部１１は、Ｓ１９０５に移行し、上記送信した「複合機状態情報」に対する応答信号として送信される複合機パラメータを機能サーバ３０から受信する。尚、複合機パラメータは、機能サーバ３０の制御部３１により実行されるサービス側印刷ジョブのＳ１８０３で送信される。

Ｓ１９０５の処理が終了すると、制御部１１は、起動元のサービス受信処理のプロセスから、終了指示が入力されたか否かを判断する（Ｓ１９０６）。尚、終了指示は、複合機１０の制御部１１により実行されるサービス受信処理（図１０）のＳ３１０にて出力される。そして、終了指示が入力されていないと判断すると、Ｓ１９０７に移行し、Ｓ１９０５で複合機パラメータを正常に受信できたか否かを判断する。

Ｓ１９０７で正常に受信できなかったと判断すると、制御部１１は、Ｓ１９０８へ移行し、複合機１０が機能サーバ３０からの情報を正常に受け取ることができたか否かの通知である「複合機受取状況」として、「異常受取」を機能サーバ３０へ通知し、Ｓ１９０５へ移行する。尚、「複合機受取状況」には、セッションＩＤ及びジョブＩＤが含まれる。

一方、Ｓ１９０７で正常に受信できたと判断すると、制御部１１は、Ｓ１９０９へ移行し、「複合機受取状況」として正常受取である旨の「正常受取」を機能サーバ３０へ通知する。続いて、Ｓ１９１０では、出力データ（印刷データや音データ）を機能サーバ３０から受信する。尚、印刷データは、機能サーバ３０の制御部３１により実行されるサービス側印刷ジョブ処理（図３０）のＳ１８０９で送信される。

Ｓ１９１０の処理を終了すると、制御部１１は、Ｓ１９１１へ移行し、上記複合機パラメータを出力装置（記録部１４又は音出力部１８）にセットし、出力データを出力する処理を行う。

例えば、出力ジョブが、機能サーバ３０の定期サービス提供処理から出力される「印刷ジョブ起動指令」を受けて起動されたものである場合には、出力装置としての記録部１４を用いて、機能サーバ３０から提供される印刷データに基づく印刷出力処理を行う。

具体的に、定期サービス提供処理のプロセスが、ブログ検索サービスを複合機１０に提供するためのプロセスであり、当該出力ジョブが、このブログ検索サービスを受けるためのプロセスである場合には、ブログ検索処理にて検索された投稿内容を、記録部１４を通じて印刷出力する。

その他、定期サービス提供処理のプロセスが、ローカルニュース提供サービスを複合機１０に提供するためのプロセスであり、当該出力ジョブが、このローカルニュース提供サービスを受けるためのプロセスである場合には、ニュース情報生成処理にて生成されたニュースデータに基づく情報を、記録部１４を通じて印刷出力する。

Ｓ１９１１での処理を終えると、制御部１１は、Ｓ１９１１で出力装置に設定したパラメータを元の値に戻し（Ｓ１９１２）、「複合機状態情報」を機能サーバ３０に向けて送信する（Ｓ１９１３）。Ｓ１９１３の処理後には、Ｓ１９１４に移行し、「サービス状態情報」を機能サーバ３０から受信する。その後、Ｓ１９１５に移行して、Ｓ１９０３で立てたビジーフラグＦｏを下ろし、当該出力ジョブを終了する。

以上、本実施例の通信システム１について説明したが、この通信システム１では、機能サーバ３０と、クライアント装置としての複合機１０との間でＨＴＴＰ通信を行うことにより、機能サーバ３０から複合機１０に対して、複数種のサービス（ブログ検索サービスやローカルニュース提供サービス等）を提供する。

複合機１０は、機能サーバ３０が、定期的に提供する複数種のサービスの内、自装置が機能サーバ３０から受けるサービス毎に（具体的にはリクエストサービスＩＤ毎に）、そのサービスの問合せ時期を示す情報として、問合せ間隔情報及び残り時間情報と、即時処理情報とを、定期問合せ管理テーブルに記憶しており、この問合せ間隔情報及び残り時間情報並びに即時処理情報に基づいて、自装置が機能サーバ３０から受けるサービス毎に、定期問合せ信号の送信時期が到来したか否かを、Ｓ９０４〜Ｓ９０６にて判断し、送信時期が到来したと判断すると（Ｓ９０６でＹｅｓと判断すると）、Ｓ９０８にて、上記送信時期が到来したと判断したサービスの識別情報としてのリクエストサービスＩＤを、まとめて記述した統合問合せ情報を生成し、統合問合せ情報を格納した定期問合せ信号を、通信デバイスとしての通信部１５を通じ、機能サーバ３０に向けて送信する（Ｓ９１１）。

また、複合機１０は、統合返信情報受信処理にて、定期問合せ信号に対する応答信号を、通信部１５を介し機能サーバ３０から受信すると、応答信号に含まれる統合返信情報に記載のリクエストサービスＩＤのパラメータＳｅｒｖｉｃｅ＿Ｓｔａｒｔが値「ＴＲＵＥ」であるか否かを判断することにより、そのリクエストサービスＩＤに対応するサービスが、機能サーバ３０にて提供する準備が完了しているサービスであるか否かを判断し（Ｓ１６０９）、機能サーバ３０にて提供する準備が完了していると判断したサービスについては、そのサービスを受けるために必要なサービス受信処理（及び入力ジョブ／出力ジョブ）を実行して（Ｓ１６１１）、機能サーバ３０からサービスを受ける。

一方、機能サーバ３０は、複合機１０から送信されてくる上記複数種のサービスに関する定期問合せ信号を、定期問合せ応答処理にて通信部３２を介して受信する（Ｓ１１０１）と共に、定期問合せ信号を受信すると、その定期問合せ信号に含まれるリクエストサービスＩＤに基づき、問合せ対象のサービスについての返答情報である定期問合せ返信情報を生成し、この定期問合せ返信情報をまとめて統合返信情報を生成し（Ｓ１１１４）、これを格納した応答信号を、問合せ元の複合機１０に向けて送信する（Ｓ１１１５）。

このように本実施例の通信システム１では、複数の問合せ対象がある場合、これらの問合せを示す情報をまとめて定期問合せ信号に格納し、機能サーバ３０に向けて送信するので、各サービス（各リクエストサービスＩＤ）について個々に問合せ信号を生成し、これを機能サーバ３０に送信するよりも、ネットワークトラフィックを抑えることができ、効率的に問合せを行うことができる。また、複数の問合せに対する返答を、統合返信情報にまとめて記述して、複合機１０に向けて送信するので、効率的に問合せに対する返答を行うことができる。

また、本実施例では、Ｓ９０４にて、予め定められた問合せの実行猶予期間（前回の定期問合せ信号の送信時点から所定時間）が経過したか否かを判断すると共に、Ｓ９０５にて、定期問合せ管理テーブルが記憶する各サービスの即時処理情報に基づき、自装置が機能サーバ３０から受けるサービス毎に、即時の問合せが必要か否かを判断し、更に、Ｓ９０６にて、定期問合せ管理テーブルが記憶する各サービスの残り時間情報に基づき、自装置が機能サーバ３０から受けるサービス毎に、問合せ時刻が到来したか否かを判断するようにした。

そして、Ｓ９０６にて問合せ時刻が到来したと判断されたサービスが存在しない場合（即ち、残り時間がゼロ以下であるサービスが存在しない場合、又は、残り時間がゼロ以下であるサービスが存在しても、即時の問合せが必要であり残り時間がゼロ以下であるサービスが存在しない場合であって実行猶予期間が経過していない場合）には、定期問合せ信号をＳ９１１で送信しないようにし、Ｓ９０６にて問合せ時刻が到来したと判断されたサービスが存在する場合（即ち、即時の問合せが必要であり残り時間がゼロ以下であるサービスが存在する場合、又は、実行猶予期間が経過しており残り時間がゼロ以下であるサービスが存在する場合）にのみ、定期問合せ信号をＳ９１１で送信するようにした。

従って、本実施例の通信システム１によれば、問合せを効率よくまとめて実行することができると共に、即時の問合せが必要なサービスについては、直ちに、問合せを実行することができ、大変便利である。

また、本実施例の通信システム１では、問合せ対象のサービスについてのリクエストサービスＩＤを、問合せ内容を表すパラメータ（Ｒｅｑｕｅｓｔ＿Ｓｔａｔｕｓ）の値が同一であるリクエストサービスＩＤ毎にまとめて記述し、まとめて記述したリクエストサービスＩＤの一群に対し、上記パラメータの値を関連付けて記述して、統合問合せ情報を生成するようにした。従って、本実施例によれば、パラメータ（Ｒｅｑｕｅｓｔ＿Ｓｔａｔｕｓ）の値を複数回、統合問合せ情報に記述する必要がなく、統合問合せ情報のデータ量を抑えることができて、一層、ネットワークトラフィックを抑えることができる。

また同様に、本実施例の通信システム１では、返答情報としてのパラメータＳｅｒｖｉｃｅ＿Ｓｔａｒｔ，Ｓｅｒｖｉｃｅ＿ＵＲＬ，Ｓｅｒｖｉｃｅ＿Ｓｔａｔｕｓ，Ｓｅｒｖｉｃｅ＿Ｃａｎｃｅｌｅｄの値）が同一であるリクエストサービスＩＤを、まとめて記述し、まとめて記述した上記リクエストサービスＩＤの一群に対し、上記パラメータの値を関連付けて記述して、統合返信情報を生成するようにした。従って、本実施例によれば、統合返信情報のデータ量を抑えることができて、効率的にネットワークトラフィックを抑えることができる。

また、本実施例では、返信判断処理を実行することにより、特定のパラメータ値を返答するサービスについての情報（Ｒｅｓｐｏｃｅ＿Ｓｅｒｖｉｃｅタグ）のみを統合返信情報に格納して、応答信号を送信するようにし、それ以外の返答となるサービス（具体的には、返信判断処理のＳ１３０５で返信ＮＧと判断されるサービス）についての情報を、応答信号に格納しないようにしたので、効率的に、応答信号のデータ量を抑制することができ、ネットワークトラフィックを抑えることができる。

また、本実施例の通信システム１では、機能サーバ３０から提供されるサービスを、複合機１０側で、入出力デバイスとしての読取部１３（スキャナ）、記録部１４（プリンタ）、音入力部１７、音出力部１８の一つ又は複数を用いて受けるが、定期問合せ信号の送信時期が到来したサービスであっても、そのサービスを受けるために駆動が必要な入出力デバイスが動作中である場合には、Ｓ９０７でＹｅｓと判断して、そのサービスについてのリクエストサービスＩＤを統合問合せ情報に記述しないことにより、サービスを受けるために駆動が必要な入出力デバイスが動作中ではないサービスについてのみの定期問合せを選択的に行うようにした。従って、本実施例によれば、定期問合せに関し、一層の効率化を図ることができる。

その他、本実施例では、機能サーバ３０にて提供する準備が完了していると判断された各サービスを受けるために必要なサービス受信処理（及び入力ジョブ／出力ジョブ）を、夫々、利用する入出力デバイスが重複しないかぎりにおいて（即ち、Ｓ１６１０でＮｏである場合に限り）、並列に実行すると共に、利用する入出力デバイスが重複する場合には、Ｓ１６０７〜Ｓ１６１１の処理を、Ｓ１６０６でＹｅｓと判断するまで繰り返すことにより、シリアルに順次、各サービスに対応するサービス受信処理を実行するようにした。

従って、本実施例によれば、複合機１０を通じて、利用者に対し、効率的にサービスを提供することができる。
尚、上記実施例では、「スピーカジョブ起動指令」を出力する機能サーバ３０のサービス（定期サービス提供処理）について詳しく説明しなかったが、そのサービスについての定期サービス提供処理は、基本的に図２９，３０に示す処理と同様であって、図２９，３０における「印刷」との文言を「スピーカ」と置き換え、「印刷データ」の代わりに「音データ」を出力するものと解釈して差し支えない。

その他、上記実施例では、「入力ジョブ起動指令」を出力する機能サーバ３０のサービス（定期サービス提供処理）について詳しく説明しなかったが、入力ジョブ起動指令（「スキャナジョブ起動指令」又は「ボイスジョブ起動指令」）を出力する機能サーバ３０の定期サービス提供処理は、入力ジョブ起動指令（「スキャナジョブ起動指令」又は「ボイスジョブ起動指令」）を複合機１０に出力すると共に、その入力ジョブ起動指令にて複合機１０側で起動された入力ジョブに基づき入力装置（読取部１３、音入力部１７）が生成したデータを、複合機１０から取得することにより、複合機１０に対しサービスを提供するものとすることができる。

尚、本発明のサーバ装置が有する受信手段及び返信手段は、図２２に示す定期問合せ応答処理にて実現されている。また、本発明のクライアント装置が有する時期判断手段は、Ｓ９０４〜Ｓ９０６の処理にて実現されており、問合せ手段は、Ｓ９０７〜Ｓ９１１の処理にて実現されている。また、デバイス動作判断手段は、Ｓ９０７の処理にて実現されており、受信手段は、統合返信情報受信処理にて実現されている。その他、準備完了判断手段は、Ｓ１６０９の処理にて実現されている。

また、本発明の通信システム及び通信装置は、上記実施例に限定されるものではなく、種々の態様を採ることができる。
例えば、上記実施例では、パラメータの値が同一であるリクエストサービスＩＤについては、それらリクエストサービスＩＤの一群に対してパラメータの値を示したタグを共通に設け、統合問合せ情報及び統合返信情報を生成するようにしたが、上記通信システム１では、図３２及び図３３に示すように、統合問合せ情報及び統合返信情報を生成してもよい。即ち、パラメータの値が同一であるか否かに拘らず、リクエストサービスＩＤ毎に、その問合せ（返答）の内容を表すパラメータの値を記載してもよい。

本実施例の通信システム１の構成を表すブロック図である。 表示部１９に表示されるサービス選択用画面の例を表す説明図である。 トップのサービス定義情報の構成例を表す説明図である。 トップより下位のサービス定義情報２５の構成例を表す説明図である。 表示部１９に表示されるパラメータ入力用画面の例を表す説明図である。 サービスＩ／Ｆ情報３６の構成例を表す説明図である。 サービスＩ／Ｆ情報３６の構成例を表す説明図である。 複合機１０の制御部１１が行う複合機処理を表すフローチャートである。 ディレクトリサーバ２０の制御部２１が繰返し実行するディレクトリサーバ処理を表すフローチャートである。 制御部１１が実行するサービス受信処理を表すフローチャートである。 制御部１１が行う指定ジョブの起動処理を表すフローチャートである。 機能サーバ３０の制御部３１が実行する機能サーバ処理を表すフローチャートである。 制御部３１が実行するサービス制御情報処理を表すフローチャートである。 制御部３１が実行する登録処理を表すフローチャートである。 記憶部３３に記憶されたリクエストサービスＩＤ管理テーブルの構成を表す説明図（ａ）及び、定期問合せ返信管理テーブルの構成を表す説明図（ｂ）である。 記憶部１６に記憶された定期問合せ管理テーブルの構成を表す説明図である。 制御部３１が行うサービス側ＵＩジョブを表すフローチャートである。 制御部１１が実行するＵＩジョブを表すフローチャートである。 制御部１１が実行する定期問合せ処理を表すフローチャートである。 制御部１１が行う統合問合せ情報生成処理を表すフローチャートである。 統合問合せ情報の構成例を表す説明図である。 制御部３１が実行する定期問合せ応答処理を表すフローチャートである。 制御部３１が行う統合返信情報生成処理を表すフローチャートである。 制御部３１が実行する返信判断処理を表すフローチャートである。 統合返信情報の構成例を表す説明図である。 制御部３１が実行するブログ検索サービスを表すフローチャートである。 制御部３１が行うニュース情報生成処理を表すフローチャートである。 制御部１１が行う統合返信情報受信処理を表すフローチャートである。 制御部３１が行う定期サービス提供処理を表すフローチャートである。 制御部３１が行うサービス側印刷ジョブを表すフローチャートである。 制御部１１が実行する出力ジョブのフローチャートである。 変形例の統合問合せ情報の構成を表す説明図である。 変形例の統合返信情報の構成を表す説明図である。

符号の説明

１…通信システム、２，３，４…ルータ、１０…複合機、１１…制御部、１２…操作部、１３…読取部（スキャナ）、１４…記録部（プリンタ）、１５…通信部、１６…記憶部、１７…音入力部、１８…音出力部、１９…表示部、１９ａ…ディスプレイ、２０…ディレクトリサーバ、２１…制御部、２２…通信部、２３…記憶部、２４…サービス定義情報記憶部、２５…サービス定義情報、３０…機能サーバ、３１…制御部、３２…通信部、３３…記憶部、３４…サービスＩ／Ｆ情報記憶部、３５…サービスソフト記憶部、３６…サービスＩ／Ｆ情報、３７…サービスソフトウェア、４０…ＤＮＳサーバ、ＮＴ…ネットワーク

Claims (15)

1. 複数種のサービスを提供するサーバ装置と、
   前記サーバ装置と通信するための通信デバイスを有し、前記サーバ装置との通信によって、前記サーバ装置が提供するサービスを受けるクライアント装置と、
   を備えた通信システムであって、
   前記サーバ装置は、
   前記クライアント装置から送信される前記複数種のサービスに関する問合せ信号を、受信する受信手段と、
   前記受信手段が前記問合せ信号を受信すると、その問合せ信号に含まれるサービスの識別情報に基づき、問合せ対象のサービスについての返答情報を生成し、この返答情報を格納した応答信号を、問合せ元の前記クライアント装置に向けて送信する返信手段と、を有し、
   前記クライアント装置は、
   前記サーバ装置が提供する前記複数種のサービスの内、自装置が前記サーバ装置から受けるサービス毎に、そのサービスの問合せ時期を示す情報を記憶する記憶手段と、
   前記記憶手段が記憶する各サービスの問合せ時期を示す情報に基づき、自装置が前記サーバ装置から受けるサービス毎に、問合せ信号の送信時期が到来したか否かを判断する時期判断手段と、
   前記時期判断手段により送信時期が到来したと判断されると、前記送信時期が到来したと判断されたサービスの識別情報を、問合せ対象のサービスの識別情報として格納した問合せ信号を生成し、この問合せ信号を、前記サーバ装置に向けて送信する問合せ手段と、
   前記問合せ手段により送信された問合せ信号に対する応答信号を、前記サーバ装置から受信する受信手段と、を有し、
   前記問合せ手段は、前記時期判断手段により送信時期が到来したと判断されたサービスが複数ある場合、前記送信時期が到来したと判断された各サービスの識別情報を、問合せ対象のサービスの識別情報として、まとめて記述した統合問合せ情報を生成し、この統合問合せ情報を格納した問合せ信号を、前記サーバ装置に向けて送信することを特徴とする通信システム。
2. 前記記憶手段は、前記サーバ装置から受けるサービス毎に、そのサービスの問合せ時期を示す情報として、次回の問合せ時刻を表す時間情報と、即時の問合せが必要か否かを表す即時要否情報と、を記憶しており、
   前記時期判断手段は、
   前記記憶手段が記憶する各サービスの前記時間情報に基づき、自装置が前記サーバ装置から受けるサービス毎に、問合せ時刻が到来したか否かを判断する第一判断手段と、
   前記記憶手段が記憶する各サービスの前記即時要否情報に基づき、自装置が前記サーバ装置から受けるサービス毎に、即時の問合せが必要か否かを判断する第二判断手段と、
   予め定められた問合せの実行猶予期間が経過したか否かを判断する第三判断手段と、
   を有し、
   前記第一判断手段により問合せ時刻が到来したと判断されたサービスが存在しない場合、又は、前記第二判断手段により即時の問合せが必要であると判断されたサービスが存在せず、前記第三判断手段により実行猶予期間が経過していないと判断されている場合には、自装置が前記サーバ装置から受ける全サービスについて、問合せ信号の送信時期が到来していないと判断し、
   前記第一判断手段により問合せ時刻が到来したと判断され且つ前記第二判断手段により即時の問合せが必要であると判断されたサービスが存在する場合、又は、前記第一判断手段により問合せ時刻が到来したと判断されたサービスが存在し且つ前記第三判断手段により実行猶予期間が経過したと判断されている場合には、前記問合せ時刻が到来したと判断されたサービスの全てについて、問合せ信号の送信時期が到来したと判断する構成にされていることを特徴とする請求項１記載の通信システム。
3. 前記記憶手段は、前記サーバ装置から受けるサービス毎に、そのサービスの問合せ時期を示す情報に関連付けて、問合せ内容を表すパラメータの値を記憶しており、
   前記問合せ手段は、前記問合せ対象のサービスの識別情報と共に、その問合せ対象のサービスについて前記記憶手段が記憶する前記パラメータの値を、前記問合せ対象のサービスの識別情報に関連付けて、前記問合せ信号に格納する構成にされていることを特徴とする請求項１又は請求項２記載の通信システム。
4. 前記問合せ手段は、前記時期判断手段により送信時期が到来したと判断されたサービスが複数ある場合、前記問合せ対象のサービスの識別情報を、前記記憶手段が記憶する前記パラメータの値が同一であるサービスの識別情報毎にまとめて記述し、前記まとめて記述したパラメータの値が同一である前記問合せ対象のサービスの識別情報の一群に対し、前記パラメータの値を関連付けて記述して、前記統合問合せ情報を生成することを特徴とする請求項３記載の通信システム。
5. 前記クライアント装置は、前記通信デバイスの他に、複数種の入出力デバイスを有し、前記通信デバイスと、前記複数種の入出力デバイスの一つ又は複数と、を用いて、前記サーバ装置から提供されるサービスを受ける構成にされ、
   前記問合せ手段は、
   前記時期判断手段により、前記問合せ信号の送信時期が到来したと判断されたサービス毎に、そのサービスを受けるために駆動が必要な入出力デバイスが動作中であるか否かを判断するデバイス動作判断手段、
   を有し、前記デバイス動作判断手段の判断結果に基づき、前記送信時期が到来したと判断されたサービスであって、そのサービスを受けるために駆動が必要な入出力デバイスが動作していないサービスがある場合にのみ、前記入出力デバイスが動作していないサービスの識別情報を選択的に、問合せ対象のサービスの識別情報として、問合せ信号に格納し、この問合せ信号を送信する構成にされていることを特徴とする請求項１〜請求項４のいずれかに記載の通信システム。
6. 前記返信手段は、前記問合せ対象のサービスについて、そのサービスを前記問合せ元のクライアント装置に提供する準備が完了しているか否かを判断し、前記サービスを提供する準備が完了していると判断すると、その旨の返答情報を生成して応答信号に格納する構成にされ、
   前記クライアント装置は、
   自装置の受信手段が受信した前記応答信号に基づいて、前記応答信号に含まれる前記返答情報に対応するサービスが、前記サーバ装置にて提供する準備が完了しているサービスであるか否かを判断する準備完了判断手段、
   を有し、前記準備完了判断手段により、前記サーバ装置にて提供する準備が完了していると判断されると、その判断対象のサービスを受けるために必要な処理を実行することを特徴とする請求項１〜請求項５のいずれかに記載の通信システム。
7. 前記返信手段は、前記サーバ装置の受信手段が受信した問合せ信号に、前記問合せ対象のサービスの識別情報として、複数のサービスの識別情報が格納されている場合、各問合せ対象のサービスについての返答情報を、まとめて記述した統合返答情報を生成し、この統合返答情報を格納した応答信号を、問合せ元の前記クライアント装置に向けて送信することを特徴とする請求項１〜請求項５のいずれかに記載の通信システム。
8. 前記統合返答情報は、前記問合せ対象のサービス毎に、前記問合せ対象のサービスについての返答情報と、その返答情報に対応する前記問合せ対象のサービスの識別情報と、を関連付けてなる情報であることを特徴とする請求項７記載の通信システム。
9. 前記返信手段は、前記サーバ装置の受信手段が受信した問合せ信号に、前記問合せ対象のサービスの識別情報として、複数のサービスの識別情報が格納されている場合、前記返答情報が同一である前記問合せ対象のサービスの識別情報を、まとめて記述し、前記まとめて記述した前記返答情報が同一である前記問合せ対象のサービスの識別情報の一群に対し、前記返答情報を関連付けて記述して、前記統合返答情報を生成することを特徴とする請求項７又は請求項８記載の通信システム。
10. 前記返信手段は、前記問合せ対象のサービスについて、そのサービスを前記問合せ元のクライアント装置に提供する準備が完了しているか否かを判断し、前記サービスを提供する準備が完了していると判断すると、その旨の返答情報を生成して応答信号に格納する構成にされ、
    前記クライアント装置は、
    自装置の受信手段が受信した前記応答信号に基づいて、前記応答信号に含まれる前記返答情報に対応するサービスが、前記サーバ装置にて提供する準備が完了しているサービスであるか否かを判断する準備完了判断手段、
    を有し、前記準備完了判断手段により、前記サーバ装置にて提供する準備が完了していると判断されると、その判断対象のサービスを受けるために必要な処理を実行することを特徴とする請求項７〜請求項９のいずれかに記載の通信システム。
11. 前記返信手段は、問合せに対する返答が、特定の返答となるサービスについての返答情報のみを格納して、前記応答信号を生成し、送信することを特徴とする請求項７〜請求項１０のいずれかに記載の通信システム。
12. 前記クライアント装置は、
    自装置の受信手段が受信した前記応答信号に複数の返答情報が含まれ、前記準備完了判断手段により、前記サーバ装置にて提供する準備が完了していると判断されたサービスが複数存在する場合、前記サーバ装置にて提供する準備が完了していると判断された各サービスを受けるために必要な処理を、夫々、並列に実行することを特徴とする請求項１０記載の通信システム。
13. 前記クライアント装置は、
    前記通信デバイスの他に、複数種の入出力デバイスを有し、前記通信デバイスと、前記複数種の入出力デバイスの一つ又は複数と、を用いて、前記サーバ装置から提供されるサービスを受ける構成にされ、
    自装置の受信手段が受信した前記応答信号に複数の返答情報が含まれ、前記準備完了判断手段により、前記サーバ装置にて提供する準備が完了していると判断されたサービスが複数存在する場合、使用する入出力デバイスが重複しない各サービスについて、各サービスを受けるために必要な処理を、並列に実行すると共に、使用する入出力デバイスが重複する各サービスについては、順次、各サービスを受けるために必要な処理を実行することを特徴とする請求項１０記載の通信システム。
14. 前記クライアント装置は、前記複数種の入出力デバイスとして、少なくとも、記録媒体に画像を形成可能な画像形成装置、を含む二以上の入出力デバイスを備えることを特徴とする請求項５又は請求項１３記載の通信システム。
15. 複数種のサービスを提供するサーバ装置、と通信するための通信デバイスを有し、前記サーバ装置との通信によって、前記サーバ装置が提供するサービスを受ける通信装置であって、
    前記サーバ装置は、
    前記通信装置から送信される前記複数種のサービスに関する問合せ信号を、受信する受信手段と、
    前記受信手段が問合せ信号を受信すると、その問合せ信号に含まれるサービスの識別情報に基づき、問合せ対象のサービスについての返答情報を生成し、この返答情報を格納した応答信号を、問合せ元の前記通信装置に向けて送信する返信手段と、を有し、
    前記通信装置は、
    前記サーバ装置が提供する前記複数種のサービスの内、自装置が前記サーバ装置から受けるサービス毎に、そのサービスの問合せ時期を示す情報を記憶する記憶手段と、
    前記記憶手段が記憶する各サービスの問合せ時期を示す情報に基づき、自装置が前記サーバ装置から受けるサービス毎に、問合せ信号の送信時期が到来したか否かを判断する時期判断手段と、
    前記時期判断手段により送信時期が到来したと判断されると、前記送信時期が到来したと判断されたサービスの識別情報を、問合せ対象のサービスの識別情報として格納した問合せ信号を生成し、この問合せ信号を、前記サーバ装置に向けて送信する問合せ手段と、
    前記問合せ手段により送信された問合せ信号に対する応答信号を、前記サーバ装置から受信する受信手段と、を有し、
    前記問合せ手段は、前記時期判断手段により送信時期が到来したと判断されたサービスが複数ある場合、前記送信時期が到来したと判断された各サービスの識別情報を、問合せ対象のサービスの識別情報として、まとめて記述した統合問合せ情報を生成し、この統合問合せ情報を格納した問合せ信号を、前記サーバ装置に向けて送信することを特徴とする通信装置。

Images