(57)【要約】【課題】  サービス提供装置に設定情報を送信して利用登録する必要のあるサービスについて、利用登録が抹消された場合に、利用者を煩わせることなく、再度サービスの利用登録を行うことが可能な技術を提供すること。【解決手段】  複合機は、利用登録された当該装置向けのサービスであって、サービス提供装置としての機能サーバにて提供が終了されたサービスがある場合、サービス受信処理を実行して、機能サーバ３０に登録処理のプロセスを起動させるための「サービス起動指令」を入力すると共に、記憶部が記憶する上記提供が終了されたサービスに対応する利用登録情報を読み出し（Ｓ８６１）、読み出した利用登録情報が含むパラメータ情報を、機能サーバに送信することにより、上記提供が終了されたサービスの利用登録を行う。【選択図】  図１９
2006134109.tif 000002
【特許請求の範囲】
【請求項１】
外部装置に提供するサービスの内容を決定付ける一つ又は複数のパラメータからなる設定情報を、サービス提供対象の外部装置の識別情報と関連付けて、複数個記憶可能なデータベースと、
外部装置からサービスの提供を受けるための登録を要求する旨の登録要求信号を受信すると、登録要求元の前記外部装置から、この外部装置が受けるサービスについての前記設定情報を取得し、前記取得した設定情報を、前記サービス提供対象である前記登録要求元の外部装置の前記識別情報と関連付けて、前記データベースに登録する登録手段と、
前記データベースに登録された各設定情報に従うサービスを、前記サービス提供対象の外部装置に対し、通信によって提供するサービス提供手段と、
前記データベースに登録された各設定情報に対応するサービスの終了条件が満足されたか否かを、前記データベースに登録された設定情報毎に判断する終了判断手段と、
前記終了判断手段により終了条件が満足されたと判断されたサービスの前記設定情報を、前記データベースから削除して、そのサービスの提供を終了するサービス終了手段と、
を備えるサービス提供装置、と通信可能に構成された通信装置であって、
利用者が操作可能な操作手段から登録を指示する信号が入力されると、前記サービス提供装置に向けて前記登録要求信号を送信すると共に、当該通信装置が前記サービス提供装置から受けるサービスについての前記設定情報を、前記操作手段を通じて利用者から取得し、この設定情報を、前記サービス提供装置に向けて送信して、前記サービスの利用登録を行う利用登録手段と、
前記利用登録手段が前記設定情報を前記サービス提供装置に向けて送信する際に、前記送信対象の設定情報をコピーして、当該通信装置が備える記憶手段に記憶させる設定情報記録手段と、
前記利用登録手段の動作によって前記サービス提供装置から提供されるサービスを受けて、前記サービスを利用した所定の機能を実現する機能実行手段と、
前記利用登録手段によって利用登録されたサービスであって、前記サービス提供装置にて提供が終了された当該通信装置向けのサービスを検知する検知手段と、
前記検知手段により前記提供が終了されたサービスが検知されると、前記記憶手段が記憶する前記提供が終了されたサービスに対応する設定情報を読み出し、前記読み出した設定情報を、前記登録要求信号と共に、前記サービス提供装置に送信することにより、前記提供が終了されたサービスの利用登録を行う再登録手段と、
を備えることを特徴とする通信装置。
【請求項２】
前記サービス終了手段は、前記終了条件が満足されたサービスの提供を終了する際、終了対象のサービスを受けていた外部装置に対し、前記サービスの終了を示す終了通知情報を送信する構成にされ、
前記検知手段は、前記サービス提供装置から前記終了通知情報を受信すると、前記サービス提供装置にて提供が終了された当該通信装置向けのサービスを検知することを特徴とする請求項１記載の通信装置。
【請求項３】
前記再登録手段は、
前記検知手段により検知された前記提供が終了されたサービスについての利用登録が必要か否かを判断する再登録要否判断手段、
を有し、前記提供が終了されたサービスのうち、前記再登録要否判断手段により利用登録が必要であると判断されたサービスについての利用登録を選択的に実行し、前記再登録要否判断手段により利用登録が不要であると判断されたサービスについては、利用登録を実行しない構成にされていることを特徴とする請求項１又は請求項２記載の通信装置。
【請求項４】
前記再登録要否判断手段は、前記検知手段により検知された前記提供が終了されたサービスについて、前記提供が終了された原因を判定し、その判定結果に従って、前記提供が終了されたサービスについての利用登録が必要か否かを判断することを特徴とする請求項３記載の通信装置。
【請求項５】
前記サービス終了手段は、前記終了条件が満足されたサービスの提供を終了する際、終了対象のサービスを受けていた外部装置に対し、前記終了対象のサービスについての再登録の受付可否を表す情報を送信する構成にされ、
前記再登録要否判断手段は、前記サービス提供装置から受信した前記再登録の受付可否を表す情報に従って、前記提供が終了されたサービスについての利用登録が必要か否かを判断することを特徴とする請求項３記載の通信装置。
【請求項６】
前記検知手段により前記提供が終了されたサービスが検知されると、利用者の操作により前記操作手段から入力された再登録の許可／不許可を表す情報に従って、前記提供が終了されたサービスが、再登録を許可されたサービスであるか否かを判断する許可判断手段と、
前記許可判断手段により、前記提供が終了されたサービスが、再登録を許可されたサービスではないと判断されると、再登録を許可されていない前記サービスについての前記再登録手段による利用登録を禁止する再登録禁止手段と、
を備えることを特徴とする請求項１〜請求項５のいずれかに記載の通信装置。
【請求項７】
前記利用登録手段が前記設定情報を前記操作手段を通じて取得する際に、利用者に対して、前記設定情報に対応するサービスの再登録を許可するか否かを問合せ、これに応答して前記操作手段から入力される再登録の許可／不許可を表す情報を、前記利用登録されるサービス毎に、前記記憶手段に記憶させる許可情報記録手段、
を備え、
前記許可判断手段は、前記記憶手段が記憶する前記提供が終了されたサービスに対応する前記再登録の許可／不許可を表す情報に従って、前記提供が終了されたサービスが、再登録を許可されたサービスであるか否かを判断することを特徴とする請求項６記載の通信装置。
【請求項８】
前記検知手段による検知後、前記再登録手段により利用登録されるサービスの設定情報を構成する特定パラメータの値の変更を指示するメッセージを、当該通信装置が備える表示手段に表示させるメッセージ表示手段と、
前記メッセージ表示手段の動作後、前記操作手段から、前記特定パラメータの値が入力されると、既に前記記憶手段が記憶する前記再登録手段により利用登録されるサービスの特定パラメータの値に代えて、前記メッセージ表示手段の動作後に入力された前記特定パラメータの値を用いて、前記サービスの利用登録を行うように前記再登録手段を制御する登録内容変更手段と、
を備えることを特徴とする請求項１〜請求項７のいずれかに記載の通信装置。
【請求項９】
前記終了判断手段は、前記各設定情報に対応するサービスについて、予め定められた複数種の事象のいずれかが生じると、そのサービスの終了条件が満足されたと判断し、
前記サービス終了手段は、前記終了条件が満足されたサービスの提供を終了する際、終了対象のサービスを受けていた外部装置に対し、前記サービスの提供を終了した原因を表す情報を送信する構成にされ、
当該通信装置は、
前記サービス提供装置から受信した前記サービスの提供を終了した原因を表す情報に基づいて、前記特定パラメータを決定するパラメータ決定手段、
を備えることを特徴とする請求項８記載の通信装置。
【請求項１０】
前記終了判断手段は、前記設定情報を構成するパラメータの値では、正常に、前記設定情報に対応するサービスを提供することができない場合に、その設定情報に対応するサービスの終了条件が満足されたと判断し、
前記サービス終了手段は、前記終了条件が満足されたサービスの提供を終了する際、終了対象のサービスを受けていた外部装置に対し、前記終了条件が満足される原因となった前記設定情報を構成するパラメータの値の正常な範囲を表す情報を送信し、
前記メッセージ表示手段は、前記特定パラメータの値の変更を指示するメッセージとして、前記終了条件が満足される原因となったパラメータの値の変更を指示するメッセージを前記表示手段に表示させると共に、前記サービス提供装置から受信した前記パラメータの値の正常な範囲を表す情報に基づき、前記特定パラメータの値の正常な範囲を、前記表示手段に表示させることを特徴とする請求項８記載の通信装置。
【請求項１１】
前記操作手段から削除指示信号が入力されると、前記記憶手段が記憶する設定情報を消去する消去手段、を備えることを特徴とする請求項１〜請求項１０のいずれかに記載の通信装置。
【請求項１２】
請求項１〜請求項１１のいずれかに記載の通信装置と、
記録媒体に画像を形成可能な画像形成手段と、
を備え、前記機能実行手段は、前記サービスを利用した所定機能を、前記画像形成手段を用いて実現する構成にされていることを特徴とする画像形成装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、登録された設定情報に従って、その設定情報により特徴付けられるサービスを提供するサービス提供装置と通信可能な通信装置、及び、この通信装置を内蔵する画像形成装置、に関する。
【背景技術】
【０００２】
従来より、サービス提供装置としては、サービスを受けるクライアント装置からの要求があると、クライアント装置に、その要求に応じたサービスに関するデータを送信し、サービスを提供するもの（情報提供サービス等）や、クライアント装置からサービスに関するデータを取得し、これを処理することにより、そのデータ処理に係るサービスを提供するものが知られている。
【０００３】
一方、クライアント装置としては、サーバ装置（サービス提供装置）が有するウェブデータを受信し、これを表示することにより、ウェブサービスを受けるものが知られている。また、情報提供サービスを受けるクライアント装置としては、サーバ装置にアクセスして、新しい情報がサーバ装置にあるか否かを判断し、新しい情報がある場合には、サーバ装置から、その情報を取得するものが知られている（非特許文献１参照）。
【０００４】
その他、クライアント装置へサービスを提供するシステムとしては、ディジタル複写機が備えていない機能を、ネットワークを介してディジタル複写機に接続されたホストコンピュータに設け、その機能をホストコンピュータにて実現し、処理結果をディジタル複写機に与えるようにしたシステムが知られている（特許文献１参照）。
【特許文献１】特開平９−２３８２１５号公報
【非特許文献１】”ＲＳＳリーダー  Ｒａｂｂｉｔ  Ｔｉｃｋｅｒ”、［online］、［平成１６年１０月２０日検索］、インターネット＜ＵＲＬ：http://www.work-at.co.jp/rabbit/＞
【発明の開示】
【発明が解決しようとする課題】
【０００５】
ところで、ニュース等のように、断続的に新しい情報をクライアント装置（利用者）に提供するサービス提供装置では、提供すべき情報の種類やキーワード等の設定情報を、クライアント装置から取得してサービスの利用登録を受け、この設定情報に従って、各クライアント装置に、個々のサービス（設定情報が示す種類やキーワードに合致する情報）を提供する場合がある。
【０００６】
そして、この種のサービス提供装置では、クライアント装置の電源オフ等で、サービス提供先を特定することができない期間が長く続き、サービスの提供を正常に行うことができないと、その利用登録を自動的に抹消する場合がある。その他、上記サービスが、有料サービスである場合には、プリペイドカードが無効になった際や、クレジット決済をすることができなくなった際に、サービスの利用登録を自動的に抹消する場合がある。
【０００７】
このような利用登録の抹消は、利用者が意図したものである場合もあるが、利用者が望んでいない場合もあり、望んでいない場合、利用者は、再度クライアント装置に設定情報の入力操作をし、これをクライアント装置からサービス提供装置に送信して、再度利用登録をしなければならない。しかしながら、このような入力操作は、利用者にとって非常に煩わしい。
【０００８】
本発明は、こうした問題に鑑みなされたものであり、サービス提供装置に設定情報を送信して利用登録する必要のあるサービスについて、利用登録が抹消された場合に、利用者を煩わせることなく、再度、サービスの利用登録を行うことが可能な技術（通信装置）を提供することを目的とする。
【課題を解決するための手段】
【０００９】
かかる目的を達成するためになされた請求項１記載の発明は、下記のサービス提供装置と通信可能に構成されていることを前提とした通信装置であり、利用登録手段と、設定情報記録手段と、機能実行手段と、検知手段と、再登録手段とを備えることを特徴とする。
【００１０】
前提とするサービス提供装置は、外部装置（本発明の通信装置等）に提供するサービスの内容を決定付ける一つ又は複数のパラメータからなる設定情報を、サービス提供対象の外部装置の識別情報と関連付けて、複数個記憶可能なデータベースを備え、外部装置からサービスの提供を受けるための登録を要求する旨の登録要求信号を受信すると、登録手段にて、登録要求元の外部装置から、この外部装置が受けるサービスについての設定情報を取得し、取得した設定情報を、サービス提供対象である上記登録要求元の外部装置の識別情報と関連付けて、データベースに登録する構成にされている。
【００１１】
また、このサービス提供装置は、データベースに登録された各設定情報に従うサービスを、サービス提供手段により、通信にてサービス提供対象の外部装置に提供すると共に、データベースに登録された各設定情報に対応するサービスの終了条件が満足されたか否かを、データベースに登録された設定情報毎に、終了判断手段にて判断する。
【００１２】
更に、このサービス提供装置は、上記終了判断手段により終了条件が満足されたと判断されたサービスの設定情報を、データベースから削除し、そのサービスの提供を終了するサービス終了手段を備える。
【００１３】
一方、上記サービス提供装置と通信可能な本発明の通信装置は、利用者が操作可能な操作手段から登録を指示する信号が入力されると、利用登録手段にて、サービス提供装置に向けて上記登録要求信号を送信すると共に、自装置がサービス提供装置から受けるサービスについての設定情報を、操作手段を通じて利用者から取得し、この設定情報を、サービス提供装置に向けて送信して、サービスの利用登録を行う。
【００１４】
また、設定情報記録手段は、利用登録手段が上記設定情報をサービス提供装置に向けて送信する際に、その送信対象の設定情報をコピーして、当該通信装置が備える記憶手段に記憶させる。また、機能実行手段は、利用登録手段の動作によってサービス提供装置から提供されるサービスを受けて、サービスを利用した所定の機能を実現する。
【００１５】
その他、検知手段は、利用登録手段によって利用登録されたサービスであって、サービス提供装置にて提供が終了された当該通信装置向けのサービスを検知し、再登録手段は、検知手段により上記提供が終了されたサービスが検知されると、記憶手段が記憶する上記提供が終了されたサービスに対応する設定情報を読み出し、読み出した設定情報を、登録要求信号と共に、サービス提供装置に送信することにより、上記提供が終了されたサービスの利用登録を行う。
【００１６】
この通信装置によれば、初回の利用登録時に、サービス提供装置に対して送信する設定情報を記憶し、再登録時に、これを読み出して、サービス提供装置に送信するため、再登録時に、利用者に設定情報の入力操作を行わせることなく、サービスの利用登録を行うことができる。即ち、この発明によれば、サービス終了手段にて設定情報がデータベースから削除されたサービスについての再登録を、利用者を煩わせることなく実行できる。
【００１７】
尚、サービス提供装置が有するサービス終了手段が、上記終了条件が満足されたサービスの提供を終了する際、終了対象のサービスを受けていた外部装置に対し、サービスの終了を示す終了通知情報を送信する構成にされている場合には、検知手段を、請求項２記載のように構成するとよい。
【００１８】
請求項２記載の通信装置における検知手段は、サービス提供装置から上記終了通知情報を受信すると、その終了通知情報に基づいて、サービス提供装置にて提供が終了された当該通信装置向けのサービスを検知する。この通信装置によれば、簡単な処理で、サービス提供装置にて提供が終了された当該通信装置向けのサービスを検知することができる。
【００１９】
また、再登録手段は、検知手段により検知された上記提供が終了された当該通信装置向けのサービスの全てについて、利用登録を自動で行う構成にされてもよいが、利用者やサービス提供者側が、再登録を望まない場合もあるので、上記再登録手段は、請求項３記載のように構成されるとよい。
【００２０】
請求項３記載の通信装置における再登録手段は、検知手段により検知された上記提供が終了されたサービスについての利用登録が必要か否かを判断する再登録要否判断手段、を有し、上記提供が終了されたサービスのうち、再登録要否判断手段により利用登録が必要であると判断されたサービスについての利用登録を選択的に実行し、再登録要否判断手段により利用登録が不要であると判断されたサービスについては、利用登録を実行しない構成にされている。
【００２１】
この発明によれば、再登録が不要なサービスについては、再登録手段による利用登録が行われないので、再登録を利用者やサービス提供者側が望んでいないのにもかかわらず、再登録手段が利用登録に係る処理を実行してしまうのを防止することができる。尚、再登録要否判断手段は、当該通信装置の操作手段やサービス提供装置から得られる情報、サービスの提供が終了した原因等に基づき、利用登録が必要か否かを判断することができる。
【００２２】
請求項４記載の通信装置は、再登録要否判断手段が、検知手段により検知された上記提供が終了されたサービスについて、上記提供が終了された原因を判定し、その判定結果に従って、上記提供が終了されたサービスについての利用登録が必要か否かを判断する構成にされたものである。この通信装置によれば、上記提供が終了された原因を判定して、その結果に基づき、利用登録が必要か否かを判断するので、利用者に入力操作を求めることなく、適切に再登録の実行／実行禁止を切り替えることができる。
【００２３】
その他、サービス提供装置のサービス終了手段が、上記終了条件が満足されたサービスの提供を終了する際、終了対象のサービスを受けていた外部装置に対し、終了対象のサービスについての再登録の受付可否を表す情報を送信する構成にされている場合には、請求項５記載のように再登録要否判断手段を構成するとよい。
【００２４】
請求項５記載の通信装置における再登録要否判断手段は、サービス提供装置から受信した上記再登録の受付可否を表す情報に従って、上記提供が終了されたサービスについての利用登録が必要か否かを判断する。
【００２５】
この通信装置によれば、サービス提供装置から再登録の受付可否を表す情報として「受付不可」を表す情報を取得した場合に、再登録手段による利用登録を禁止することができる。即ち、この通信装置によれば、サービス提供装置側から再登録手段の動作をコントロールすることができ、非常に便利である。
【００２６】
また、上記通信装置は、請求項６記載のように構成されてもよい。請求項６記載の通信装置は、検知手段により上記提供が終了されたサービスが検知されると、利用者の操作により操作手段から入力された再登録の許可／不許可を表す情報に従って、上記提供が終了されたサービスが、再登録を許可されたサービスであるか否かを判断する許可判断手段を有し、その許可判断手段により、上記提供が終了されたサービスが、再登録を許可されたサービスではないと判断されると、再登録を許可されていないサービスについての再登録手段による利用登録を、再登録禁止手段にて禁止する構成にされたものである。
【００２７】
この通信装置によれば、操作手段から再登録の許可／不許可を表す情報を取得するため、利用者に対して上記情報の入力操作を求めることになるが、利用者の意思に従って、再登録手段による利用登録の実行／実行禁止を切り替えることができるので、利用者の意思に関わらず再登録を行う場合よりも、利用者に不満が及ぶことがない。
【００２８】
即ち、この発明によれば、利用者に設定情報の入力操作についての煩わしさを感じさせることなく、利用者の意思に従って、適切に、上記サービス提供装置にて提供が終了されたサービスについての再利用登録を行うことができる。
【００２９】
尚、操作手段を通じて再登録の許可／不許可を表す情報を取得するタイミングは、上記検知手段により上記提供が終了されたサービスが検知された直後のタイミングでもよいが、そのタイミングでは、利用者が通信装置の操作手段を操作することができず、ただちにサービスの再利用登録を実行することができない場合がある。従って、このような問題を解消するためには、請求項７記載のように通信装置を構成するとよい。
【００３０】
請求項７記載の通信装置は、利用登録手段が設定情報を操作手段を通じて取得する際に、利用者に対して、設定情報に対応するサービスの再登録を許可するか否かを問合せ、これに応答して操作手段から入力される再登録の許可／不許可を表す情報を、利用登録手段によって利用登録されるサービス毎に、記憶手段に記憶させる許可情報記録手段、を有し、上記許可判断手段が、記憶手段が記憶する上記提供が終了されたサービスに対応する再登録の許可／不許可を表す情報に従って、上記提供が終了されたサービスが、再登録を許可されたサービスであるか否かを判断する構成にされたものである。
【００３１】
この通信装置によれば、初回のサービスの利用登録時に、操作手段を通じて利用者から再登録の許可／不許可を表す情報を取得するので、サービスの提供が終了してから操作手段を通じて上記情報を取得する場合よりも、再登録を迅速に行うことができる。
【００３２】
ところで、サービス提供装置によるサービス提供の終了は、例えば、データベースに登録された設定情報のパラメータ値が、サービス提供手段にてサービスを提供するのに適さない値を示している場合に、起こる可能性がある。
【００３３】
具体的には、サービス提供装置側で、サービス提供手段の変更が施され（ソフトウェアのバージョンアップ等）、それにより、以前の設定情報が示すパラメータ値が、変更後のサービス提供手段により実現されるサービスの内容を決定付けるには適さない値（バージョンアップ後のソフトウェアが受け付けない値）となる場合である。また、サービス提供手段が、パラメータで指定された種類の情報（ニュースや投稿内容を表す文字情報等）を提供する手段である場合には、提供する情報量が多すぎて、サービスを提供し続けることが困難になり、サービスの提供を終了する場合も考えられる。
【００３４】
その他、設定情報が、サービスに関する料金（又は、それと等価なポイント）の徴収先を表す情報（プリペイドカード番号やクレジットカード番号）を含むものである場合には、その料金徴収先の情報が無効な情報となると、サービス提供の終了は、起こる可能性がある。
【００３５】
このような場合には、以前、利用登録した設定情報を記憶手段から読み出して、サービス提供装置に送信し、サービスの再利用登録を行っても、登録が受け付けられない可能性がある。従って、上記の通信装置は、請求項８記載のように構成されるとよい。
【００３６】
請求項８記載の通信装置は、検知手段による検知後、再登録手段により利用登録されるサービスの設定情報を構成する特定パラメータの値の変更を指示するメッセージを、当該通信装置が備える表示手段に表示させるメッセージ表示手段を備え、このメッセージ表示手段の動作後、操作手段から、特定パラメータの値が入力されると、登録内容変更手段にて、既に記憶手段が記憶する再登録手段により利用登録されるサービスの特定パラメータの値に代えて、メッセージ表示手段の動作後に入力された上記特定パラメータの値を用い、サービスの利用登録を行うように再登録手段を制御する。
【００３７】
この通信装置によれば、特定パラメータの値を変更して、サービスの利用登録を行うことができるため、以前の設定情報では、サービス提供装置からサービスを受けることができない場合にも、利用者に煩わしい設定情報の入力操作をさせることなく、サービスの利用登録を実行することができる。尚、特定パラメータとしては、サービス提供装置から指示されたパラメータや、サービスの終了原因に対応したパラメータ等が挙げられる。
【００３８】
例えば、サービス提供装置において、終了判断手段が、データベースに登録された各設定情報に対応するサービスについて、予め定められた複数種の事象のいずれかが生じると、そのサービスの終了条件が満足されたと判断する構成にされ、サービス終了手段が、上記終了条件が満足されたサービスの提供を終了する際、終了対象のサービスを受けていた外部装置に対し、サービスの提供を終了した原因を表す情報（上記事象を表す情報）を送信する構成にされている場合には、請求項９記載のように、通信装置を構成するとよい。
【００３９】
即ち、上記の通信装置には、サービス提供装置から受信した上記サービスの提供を終了した原因を表す情報に基づいて、特定パラメータを決定するパラメータ決定手段を設けるとよい。この通信装置によれば、サービス提供の終了原因に応じて、値を変更する特定パラメータを変更するので、様々な終了原因に応じて、適切に設定情報を修正し、再登録を行うことができる。従って、この発明によれば、サービスの再利用登録に関し、上記通信装置を、一層使い勝手のよいものとすることができる。
【００４０】
その他、終了判断手段が、設定情報を構成するパラメータの値では、正常に、その設定情報に対応するサービスを提供することができない場合に、その設定情報に対応するサービスの終了条件が満足されたと判断する構成にされ、サービス終了手段が、上記終了条件が満足されたサービスの提供を終了する際、終了対象のサービスを受けていた外部装置に対し、終了条件が満足される原因となった上記設定情報を構成するパラメータの値の正常な範囲を表す情報を送信する構成にされている場合には、上記通信装置を、請求項１０記載のように構成するとよい。
【００４１】
請求項１０記載の通信装置は、上記メッセージ表示手段が、特定パラメータの値の変更を指示するメッセージとして、上記終了条件が満足される原因となったパラメータの値の変更を指示するメッセージを表示手段に表示させると共に、サービス提供装置から受信した上記パラメータの値の正常な範囲を表す情報に基づいて、特定パラメータの値の正常な範囲を、表示手段に表示させる構成にされたものである。
【００４２】
この通信装置によれば、修正が必要な特定パラメータの値の変更指示を、表示手段を通じて利用者に対し適切に行うことができる。従って、この発明によれば、利用者が不適切な値を、操作手段を通じて入力するのを防止することができ、サービスの再利用登録を、円滑に行うことができる。
【００４３】
また、請求項１１記載の通信装置は、操作手段から削除指示信号が入力されると、記憶手段が記憶する設定情報を消去する消去手段を備えるものである。この通信装置によれば、記憶手段が記憶する設定情報を消去することができるので、通信装置を他の者に譲渡する際などに、設定情報が含む個人情報等が漏洩するのを防止することができる。
【００４４】
尚、本発明（請求項１〜１１）は、操作キーの種類が限られ操作性に乏しい操作手段を有する通信装置に適用されると、上述の効果が一層発揮されるので、好ましい。
請求項１２記載の画像形成装置は、請求項１〜請求項１１のいずれかに記載の通信装置と、記録媒体に画像を形成可能な画像形成手段とを備え、機能実行手段が、上記サービスを利用した所定機能を、画像形成手段を用いて実現する構成にされたものである。
【００４５】
プリンタ装置等の画像形成装置では、パーソナルコンピュータ等と違って、プリンタ機能を実現するために特段複雑な入力操作が必要ないので、コスト面や装置サイズの関係から、操作手段の操作性が乏しいことが多い。従って、画像形成装置に、本発明の通信装置の概念を適用すると、サービス提供装置に設定情報を送信して利用登録する必要のあるサービスについて、利用者を煩わせることなく簡単に、そのサービスの再利用登録を行うことができる。
【００４６】
尚、サービス提供装置が備える各手段としての機能をコンピュータに実現させるためのプログラム、及び、通信装置が備える各手段としての機能をコンピュータに実現するためのプログラムは、コンピュータ読取可能な記録媒体に格納して、提供することができる。
【発明を実施するための最良の形態】
【００４７】
以下、本発明の実施例について、図面と共に説明する。図１は、本発明が適用された通信システム１の構成を表すブロック図である。
本実施例の通信システム１は、複数のディジタル複合機（以下、単に「複合機」とする）１０と、ディレクトリサーバ２０と、機能サーバ３０とを備え、これらは、広域ネットワークＮＴ（具体的にはインターネット）を介して双方向通信可能に接続されている。具体的に、複合機１０、ディレクトリサーバ２０及び機能サーバ３０は、夫々ルータ２，３，４を介して、広域ネットワークＮＴと接続されている。
【００４８】
ルータ２は、複合機１０等から構成される下位ネットワーク（サブネット）のノードと、この下位ネットワークより外部の広域ネットワークＮＴのノードとの間のデータ通信を中継するものである。このルータ２は、外部の広域ネットワークＮＴ内の装置から、下位ネットワーク内の装置（複合機１０等）へ送信されてくるパケットのうち、下位ネットワーク内から外部への要求（リクエスト）に対する返答（レスポンス）を通過させ、それ以外のパケットを遮断する構成にされており、広域ネットワークＮＴから複合機１０に対する不正なアクセスを防止するためのファイアウォールとして機能する。
【００４９】
複合機１０は、電話（音声通信）機能、スキャナ機能、プリンタ機能、コピー機能、ファクシミリ機能等を有する多機能装置として構成されており、上記機能を用いた複数種の入出力機能を、機能サーバ３０から利用可能に構成されている。
【００５０】
機能サーバ３０は、複合機１０からの要求に応じて、上記複数種のサービスの提供に必要な処理（後述する定期サービス提供処理（図３４）等）を実行し、要求元の複合機１０に対してサービスを提供する。即ち、複合機１０は、機能サーバ３０と通信して、上記複数種のサービスを受けるための処理（後述するサービス受信処理や出力ジョブ等）を実行し、機能サーバ３０からのサービスを受ける。例えば、複合機１０は、サービスの提供にかかるデータ通信で、機能サーバ３０から得た印刷データを、プリンタ機能（記録部１４）を利用して、印刷出力する。
【００５１】
また、ディレクトリサーバ２０は、各複合機１０が利用可能なサービス（機能サーバ３０が提供可能なサービス）についての情報を、複合機１０へ提供可能に構成されている。
続いて、複合機１０、ディレクトリサーバ２０及び機能サーバ３０の詳細構成を説明する。複合機１０は、制御部１１、操作部１２、読取部１３、記録部１４、通信部１５、記憶部１６、音入力部１７、音出力部１８、及び、表示部１９を備える。制御部１１は、図示しない周知のＣＰＵ、ＲＯＭ、ＲＡＭ等を備え、複合機１０を構成する各部を統括制御する。尚、ＲＯＭには、後述する各種処理をＣＰＵに実行させるためのプログラムが記憶されている。
【００５２】
操作部１２は、利用者が操作可能な複数のキーを備え（図示せず）、これらのキーを介して、利用者の操作情報を取得し、この操作情報（各種指令等）を制御部１１に入力する。また、読取部（スキャナ）１３は、原稿に記録（例えば印刷）された画像を読み取り、この画像を表す画像データを生成する構成にされている。その他、記録部（プリンタ）１４は、印刷データに基づく画像を、用紙等のシート状記録媒体に形成（印刷）する構成にされ、通信デバイスとしての通信部１５は、広域ネットワークＮＴを介して、ディレクトリサーバ２０や機能サーバ３０等のノードとデータを送受信するための電気的な処理を行う構成にされている。
【００５３】
また、記憶部１６は、図示しない不揮発性ＲＡＭを有し、この不揮発性ＲＡＭにデータを記憶する構成にされている。その他、音入力部１７は、複合機１０が備える図示しないハンドセットに設けられたマイクから集音し、その音を表す音データ（ＰＣＭデータ）を生成する構成にされ、音出力部１８は、音データ（ＰＣＭデータ）に基づく音声を、ハンドセットに設けられたスピーカ、又は、複合機１０本体に設けられた図示しないスピーカから出力する構成にされている。また、表示部１９は、ディスプレイ１９ａを備え、このディスプレイ１９ａを介して、利用者に対する情報の表示（図２参照）を行う構成にされている。
【００５４】
次に、ディレクトリサーバ２０について説明する。ディレクトリサーバ２０は、制御部２１、通信部２２、及び、記憶部２３を備える。制御部２１は、図示しない周知のＣＰＵ、ＲＯＭ、ＲＡＭ等を備え、ディレクトリサーバ２０を構成する各部を統括制御する。尚、ＲＯＭには、後述する処理をＣＰＵに実行させるためのプログラムが記憶されている。
【００５５】
通信部２２は、広域ネットワークＮＴを介してデータを送受信するための電気的な処理を行う構成にされており、記憶部２３は、図示しないハードディスクを備え、このハードディスクにデータを記憶する構成にされている。具体的に、記憶部２３には、サービス定義情報２５を記憶するためのサービス定義情報記憶部２４が設けられている。
【００５６】
サービス定義情報２５は、機能サーバ３０が実行可能なサービスについての情報（サービスの種類やサービス要求先のＵＲＬ情報等）を、複合機１０へ提供するためのものである。具体的に、複合機１０の制御部１１は、利用者が操作部１２を操作することにより、操作部１２からサービス選択用画面の表示指令が入力されると、通信部１５を通じて、ディレクトリサーバ２０からサービス定義情報２５を取得する。また、サービス定義情報２５を取得すると、制御部１１は、そのサービス定義情報２５に基づいて、表示部１９のディスプレイ１９ａにサービスの種類を示すサービス選択用画面（図２参照）を表示し、複合機１０の利用者にサービスの選択を促す。
【００５７】
ディレクトリサーバ２０において、機能サーバ３０が実行可能なサービスは、「印刷サービス」、「コピー応用サービス」、「情報提供サービス」等、複数のカテゴリに分類管理されており、サービス選択用画面においては、まず、上記複数のカテゴリが表示される（図２（ａ））。また、利用者が操作部１２を操作することにより、上記複数のカテゴリのいずれかが選択されると、次に、選択されたカテゴリに属するサービスが表示される（図２（ｂ））。
【００５８】
このような処理を実現するため、サービス定義情報記憶部２４には、カテゴリの選択を促すサービス選択用画面（図２（ａ））に対応するサービス定義情報２５（以下「トップのサービス定義情報２５」という。）と、各カテゴリに含まれるサービスの選択を促すサービス選択用画面（図２（ｂ））に対応するサービス定義情報２５とが記憶されている。
【００５９】
図３及び図４は、サービス定義情報２５の構成例を表す説明図である。具体的に、図３は、トップのサービス定義情報２５の構成例を表す図であり、図４は、上記カテゴリの一つである「情報提供サービス」についてのサービス定義情報２５の構成例を表す図である。
【００６０】
図３及び図４に示すように、サービス定義情報２５は、ＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）によって記述されている。尚、ここで用いられる各タグの定義は、表１に示すとおりである。
【００６１】
【表１】
2006134109.tif 000003
【００６２】
トップのサービス定義情報２５（図３）が複合機１０で受信されると、ディスプレイ１９ａには、図２（ａ）に示すサービス選択用画面が表示される。具体的には、タイトル（Ｔｉｔｌｅ）として「ディレクトリサービス」の文字がディスプレイ１９ａにおける上部に表示され、その下には、選択可能なカテゴリを表す項目（Ｌｉｎｋ＿Ｔｉｔｌｅ）として、「印刷サービス」、「コピー応用サービス」及び「情報提供サービス」の文字が表示される。
【００６３】
各項目には、カテゴリに対応するサービス定義情報２５のＩＤがそれぞれ対応づけられており（Ｌｉｎｋ＿Ｌｏｃａｔｉｏｎ）、図２（ａ）に示す状態で、操作部１２から項目の選択を確定する信号（操作情報）が入力されると、制御部１１は、選択が確定された項目に対応するＩＤのサービス定義情報２５に基づき、選択されたカテゴリに対応するサービス選択用画面を、表示部１９のディスプレイ１９ａに表示する。
【００６４】
例えば、図２（ａ）に示すサービス選択用画面で「情報提供サービス」が選択されると、ディスプレイ１９ａには、図２（ｂ）に示す情報提供サービスに対応するサービス選択用画面が表示される。具体的には、タイトル（Ｔｉｔｌｅ）として「情報提供サービス」の文字がディスプレイ１９ａにおける上部に表示され、その下には、選択可能なサービスを表す項目（Ｌｉｎｋ＿Ｔｉｔｌｅ）として、「ブログ検索サービス」、「ニュース提供サービス」、「Ｘ種情報提供サービス」、及び、「Ｙ種情報提供サービス」の文字が表示される。尚、ディスプレイ１９ａのサイズの都合上、すべての項目を一度に表示することができない場合には、サービス選択用画面をスクロール可能に構成し、一部の項目を表示する。
【００６５】
各項目には、サービスを呼び出すためのＵＲＬ情報がそれぞれ対応付けられており（Ｌｉｎｋ＿Ｌｏｃａｔｉｏｎ）、利用者が操作部１２を操作することにより、項目の選択が確定されると、制御部１１は、通信部１５を介して、その項目に対応するＵＲＬ先にアクセスし、ＵＲＬ先のサーバ装置（機能サーバ３０）が提供するサービスを受ける。尚、この際、複合機１０は、一旦、ＤＮＳサーバ４０にアクセスして、ＵＲＬ先のＩＰ（インターネットプロトコル）アドレスを取得し、これに基づきＵＲＬ先のＩＰアドレスを把握して、ＵＲＬ先にアクセスする。
【００６６】
次に、機能サーバ３０について説明する。機能サーバ３０は、制御部３１、通信部３２、及び、記憶部３３を備える。制御部３１は、図示しない周知のＣＰＵ、ＲＯＭ、ＲＡＭ等を備えており、機能サーバ３０を構成する各部を統括制御する。尚、ＲＯＭには、後述する各種処理をＣＰＵに実行させるためのプログラムが記憶されている。
【００６７】
通信部３２は、広域ネットワークＮＴを介してデータを送受信するための電気的な処理を行う構成にされており、記憶部３３は、図示しないハードディスクを備え、このハードディスクに、各種データを記憶する構成にされている。具体的に、記憶部３３には、サービスＩ／Ｆ（インタフェース）情報３６を記憶するためのサービスＩ／Ｆ情報記憶部３４や、サービスソフトウェア３７を記憶するためのサービスソフト記憶部３５等が設けられている。
【００６８】
サービスソフトウェア３７は、複数種のサービスを実行するためのプログラムである。サービスソフト記憶部３５には、複数種のサービスソフトウェア３７が記憶されており、制御部３１は、各サービスソフトウェア３７を実行することにより、各サービスソフトウェア３７に対応したサービスを、クライアント装置としての複合機１０に提供する。
【００６９】
また、サービスＩ／Ｆ情報３６は、サービスを実行する際に必要なパラメータ情報を複合機１０へ要求するためのものである。サービスＩ／Ｆ情報記憶部３４には、機能サーバ３０が実行可能な複数種のサービスのそれぞれに対応する複数種類のサービスＩ／Ｆ情報３６が記憶されている。
【００７０】
複合機１０は、このサービスＩ／Ｆ情報３６を受信すると、受信したサービスＩ／Ｆ情報３６に基づいて、設定すべきパラメータを示すパラメータ入力用画面（図５参照）をディスプレイ１９ａに表示し、複合機１０の利用者にパラメータの設定を促す。
【００７１】
ここで、サービスＩ／Ｆ情報３６の具体例について説明する。図６及び図７は、サービスＩ／Ｆ情報３６の構成例を表す説明図である。具体的に、図６は、特定のブログサイトに掲載された新しい投稿の中から、利用者が指定したキーワードを含む投稿を検索し、その投稿内容を表す印刷データを生成して複合機１０の記録部１４に印刷させるというサービス（ブログ検索サービス）に対応するサービスＩ／Ｆ情報３６の構成例を表す図である。また、図７は、特定のデータベースが有するニュースデータの中から、利用者が指定した地域のローカルニュースデータを取得し、この取得情報を表す印刷データを生成して複合機１０の記録部１４に印刷させるというサービス（ローカルニュース提供サービス）に対応するサービスＩ／Ｆ情報３６の構成例を表す図である。
【００７２】
図６及び図７に示すように、サービスＩ／Ｆ情報３６は、上述したサービス定義情報２５と同じマークアップ言語により記述されており、図６及び図７で用いられている各タグの定義は表２に示すとおりである。尚、表２における基本データは、上述したサービス定義情報２５の基本データ（表１）と同じである。
【００７３】
【表２】
2006134109.tif 000004
【００７４】
図６に示すサービスＩ／Ｆ情報３６が複合機１０側で受信されると、複合機１０が備えるディスプレイ１９ａには、図５（ａ）に示すパラメータ入力用画面が表示される。具体的には、表示用タイトル（Ｔｉｔｌｅ）として「ブログ検索サービス」の文字がディスプレイ１９ａにおける上部位置に表示され、その下には、入力項目（Ｄｉｓｐ＿Ｎａｍｅ）として「検索キー１」の文字が表示され、更にその下には、入力項目「検索キー１」に対応する検索キーの入力欄が表示される。また、この入力欄には、利用者が操作部１２を通じて入力した文字が表示される。
【００７５】
尚、「ブログ検索サービス」に関する入力項目（Ｄｉｓｐ＿Ｎａｍｅ）としては、「検索キー１」に加え、「検索キー２」及び「検索キー３」が存在するが（図６参照）、ディスプレイ１９ａの大きさの都合上、すべての入力項目を一度にディスプレイ１９ａに表示することができない。
【００７６】
このため、複合機１０では、ディスプレイ１９ａにおける入力項目表示位置の左右両側に左右の矢印（三角印）を表示して、パラメータ入力用画面を左右にスクロール可能に構成する。この状態で、操作部１２を通じて、スクロールの指令が入力されると、ディスプレイ１９ａには、その指令に従って、他の入力項目に対応したパラメータ入力用画面が表示される。尚、入力項目「検索キー２」及び「検索キー３」のパラメータ入力用画面の表示形態は、入力項目「検索キー１」と基本的に同様である。
【００７７】
また、図７に示すサービスＩ／Ｆ情報３６が複合機１０で受信されると、複合機１０が備えるディスプレイ１９ａには、図５（ｂ）に示すパラメータ入力用画面が表示される。
図５（ｂ）に示すパラメータ入力用画面では、表示用タイトル（Ｔｉｔｌｅ）としての「ローカルニュース提供サービス」の文字の下に、入力項目（Ｄｉｓｐ＿Ｎａｍｅ）として「地域」の文字が表示され、更にその下には、入力項目「地域」について選択可能なパラメータの値を表す項目（Ｄｉｓｐ＿Ｓｅｌｅｃｔ）として、「北海道」、「関東」、「東海」等の地域を表す文字が表示される。尚、ディスプレイ１９ａに表示できない項目がある場合には、パラメータ入力用画面を、上下方向にスクロール可能に構成する。
【００７８】
また、「ローカルニュース提供サービス」に関する入力項目（Ｄｉｓｐ＿Ｎａｍｅ）としては、「地域」に加え、「プリペイドカード番号」及び「情報を収める紙の枚数」が存在するが（図７参照）、ディスプレイ１９ａの大きさの都合上、すべての入力項目を一度にディスプレイ１９ａに表示することができない。
【００７９】
このため、複合機１０では、「ブログ検索サービス」と同様、ディスプレイ１９ａにおける入力項目表示位置の左右両側に左右の矢印（三角印）を表示して、パラメータ入力用画面を左右にスクロール可能に構成する。この状態で、操作部１２を通じて、スクロールの指令が入力されると、ディスプレイ１９ａには、その指令に従って、他の入力項目に対応したパラメータ入力用画面が表示される。具体的に、操作部１２を通じて右方向へのスクロールを指示する指令が入力されると、ディスプレイ１９ａには、図５（ｃ）に示すように、入力項目「プリペイドカード番号」についてのパラメータ入力用画面が表示される。
【００８０】
尚、入力項目「プリペイドカード番号」のパラメータ入力用画面では、プリペイドカード番号を入力するための入力欄が表示され、入力欄には、利用者が操作部１２を通じて入力した文字（プリペイドカード番号）が表示される。その他、図示しないが入力項目「情報を収める紙の枚数」のパラメータ入力用画面には、ニュースを印刷する際の紙の枚数を入力するための入力欄が表示される。
【００８１】
また、各パラメータ入力用画面において入力されたパラメータの値（入力欄に入力された文字列も含む）は、利用者の操作により操作部１２を通じて、確定信号が入力されると、これらのパラメータの値を受けて動作するＵＲＬ（Ａｃｔｉｏｎ）先のプログラム（機能サーバ３０が有するプログラム）へ送信される。
【００８２】
次に、複合機１０、ディレクトリサーバ２０及び機能サーバ３０間で行われる通信について説明する。本実施例では、複合機１０、ディレクトリサーバ２０及び機能サーバ３０が互いにデータを送受信するための通信プロトコルとして、ＨＴＴＰ１．１（ＨＴＴＰ：ＨｙｐｅｒＴｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）が採用されており、複合機１０、ディレクトリサーバ２０及び機能サーバ３０は、ＨＴＴＰリクエスト及びレスポンスに伴わせたメッセージにより、互いに指令及び指令に対する返答を行う。
【００８３】
指令は、複合機１０から各サーバ２０，３０に対する指令（サーバ指令）と、各サーバ２０，３０から複合機１０に対する指令（複合機指令）とに分類されるが、いずれの指令にかかる通信も、複合機１０が常にＨＴＴＰ通信のクライアント（ＨＴＴＰリクエストを送信する側）となるようにしている。これにより、ルータ２が介在していても、各サーバ２０，３０から複合機１０への指令が遮断されてしまうことはない。
【００８４】
具体的に、複合機１０は、ＨＴＴＰリクエストのＰＯＳＴコマンドに伴わせたメッセージによりディレクトリサーバ２０又は機能サーバ３０に対する指令を送信する。一方、各サーバ２０，３０は、複合機１０からのＨＴＴＰリクエストのＰＯＳＴコマンドに伴わせたメッセージによる問合せに対し、複合機指令があれば、上記問合せに対するＨＴＴＰレスポンスのメッセージに、複合機指令を伴わせて送信する。
【００８５】
次に、複合機１０、ディレクトリサーバ２０及び機能サーバ３０の各制御部１１，２１，３１が行う処理について説明する。最初に、複合機１０の制御部１１が行う複合機処理について、図８のフローチャートを用いて説明する。尚、この複合機処理は、複合機１０の電源が投入されると、ただちに開始される。
【００８６】
複合機処理を開始すると、制御部１１は、まずＳ１０１で、複合機１０の初期化処理を行う。続いて、Ｓ１０２では、複合機１０への指令入力を受け付ける。ここで、複合機１０への指令入力とは、複合機１０に何らかの処理を実行させるための入力であり、例えば、操作部１２からのキー入力や、図示しないパーソナルコンピュータからの指令入力等が挙げられる。
【００８７】
続いて、Ｓ１０３では、Ｓ１０２で受けた指令入力が、サービスモードへの移行を指示する指令入力であるか否かを判断する。Ｓ１０３で、サービスモードへの移行を指示する指令入力ではないと判断すると（Ｓ１０３でＮｏ）、制御部１１は、Ｓ１０４へ移行し、Ｓ１０２で受けた入力に応じたその他のモードに対応する処理（例えば、パーソナルコンピュータから入力された印刷データの出力処理）を行い、Ｓ１０２へ移行する。
【００８８】
一方、Ｓ１０３で、指令入力がサービスモードへの移行を指示する入力であると判断すると、制御部１１は、Ｓ１０５へ移行し、機能サーバ３０に要求するサービスを決定する方法として、リストから選択する方法及びサービス要求先のＵＲＬ情報を直接入力する方法のうち、いずれの方法を採用するかを利用者に問い合わせるための選択画面をディスプレイ１９ａに表示する。そして、利用者の指令が操作部１２を通じて入力されるのを待つ。そして、指令が入力されると、その内容に従って、機能サーバ３０に要求するサービスをリストから選択するか否かを判断する。
【００８９】
Ｓ１０５で、機能サーバ３０に要求するサービスをリストから選択すると判断した場合、制御部１１は、Ｓ１０６へ移行し、ディレクトリサーバ２０にサービスの一覧を要求する。具体的には、ディレクトリサーバ２０に対しトップのサービス定義情報２５（図３）の送信を要求する。尚、本実施例において、複合機１０には、トップのサービス定義情報２５を要求するためのＵＲＬ情報が記憶部１６にあらかじめ記憶されている。
【００９０】
Ｓ１０６の処理後、制御部１１は、Ｓ１０６での要求に対してディレクトリサーバ２０から送信されたトップのサービス定義情報２５を、通信部１５を介して受信する（Ｓ１０７）。更に、Ｓ１０８では、Ｓ１０７で受信したサービス定義情報２５に基づくサービス選択用画面を表示部１９のディスプレイ１９ａに表示し（図２（ａ））、Ｓ１１０へ移行する。
【００９１】
一方、Ｓ１０５で、機能サーバ３０に要求するサービスをリストから選択しないと判断した場合には、Ｓ１０９に移行し、ＵＲＬ情報を直接入力するためのアドレス入力画面（図示せず）を表示部１９のディスプレイ１９ａに表示し、Ｓ１１０へ移行する。
【００９２】
Ｓ１１０では、サービス選択用画面又はアドレス入力画面に基づいた利用者による入力操作が操作部１２を介して行われるまで待機し、操作部１２から、入力操作に基づく操作情報が入力されると、Ｓ１１１に移行して、利用者による入力操作が、リンク選択のための操作であるか否かを判断する。具体的には、Ｓ１０８で表示した情報に基づき選択操作が正常に行われた場合、又は、Ｓ１０９で表示したアドレス入力画面にＵＲＬ情報の入力が正常に行われた場合に、入力操作がリンク選択のための操作であると判断する。
【００９３】
入力操作がリンク選択のための操作でないと判断すると（Ｓ１１１でＮｏ）、制御部１１は、Ｓ１１２へ移行し、Ｓ１１０で受けた入力操作が、サービスモードを終了するための停止操作であるか否かを判断する。そして、サービスモードを終了するための停止操作であると判断すると、Ｓ１０２へ移行する。即ち、サービスモードとしての処理を終了する。一方、Ｓ１１２で、サービスモードを終了するための停止操作でないと判断すると、Ｓ１１３へ移行し、拒否音（ビープ音等）を鳴動した後、Ｓ１１０へ移行する。即ち、Ｓ１１０で受けた入力操作が、リンク選択のための操作でなく、停止操作でもない場合に、拒否音によって、操作無効を利用者に通知する。
【００９４】
また、Ｓ１１１で入力操作がリンク選択のための操作であると判断すると、制御部１１は、Ｓ１１４へ移行し、選択されたリンクが、サービスのＵＲＬ情報で表されているか否かを判断する。
【００９５】
ここで、サービスのＵＲＬ情報で表されていない（サービス定義情報２５の識別情報である又はディレクトリサーバ２０のＵＲＬ情報で表されている）と判断すると、制御部１１は、Ｓ１１５へ移行し、Ｌｉｎｋ＿Ｌｏｃａｔｉｏｎが示すサービス定義情報２５の識別情報（ＵＲＬ情報が直接入力された場合には、そのＵＲＬ情報）に基づき、ディレクトリサーバ２０に対し、該当するサービス定義情報２５の送信を要求し、要求したサービス定義情報２５をディレクトリサーバ２０から受信する。その後、Ｓ１０８に移行し、新たなサービス選択用画面を表示部１９のディスプレイ１９ａに表示する。
【００９６】
一方、Ｓ１１４で、リンクがサービスのＵＲＬ情報で表されていると判断すると、制御部１１は、Ｓ１１６へ移行し、上記選択されたリンクのＵＲＬ情報（サービス定義情報２５のＬｉｎｋ＿Ｌｏｃａｔｉｏｎに記載のＵＲＬ情報、又は、直接入力されたＵＲＬ情報）を引数に設定して、サービスを受けるためのサービス受信処理（図１０参照。詳細後述）を実行した後、Ｓ１０２に移行する。
【００９７】
ここで、サービス受信処理を説明する前に、Ｓ１０６にて送信されるサービス一覧の要求、及び、サービス定義情報２５の送信要求を受けるディレクトリサーバ２０の動作について説明する。図９は、ディレクトリサーバ２０の制御部２１が繰返し実行するディレクトリサーバ処理を表すフローチャートである。
【００９８】
ディレクトリサーバ２０の制御部２１は、ディレクトリサーバ処理を実行すると、Ｓ２０１にて、ＨＴＴＰリクエストを受信するまで待機し、ＨＴＴＰリクエストを受信すると、Ｓ２０２に移行する。Ｓ２０２では、Ｓ２０１で受信したＨＴＴＰリクエストがサービス一覧の要求であるか否かを判断し、サービス一覧の要求であると判断すると、Ｓ２０３へ移行し、記憶部２３のサービス定義情報記憶部２４からトップのサービス定義情報２５を読み出す。その後、Ｓ２０７へ移行し、読み出したサービス定義情報２５を含むＨＴＴＰレスポンスを、ＨＴＴＰリクエストの送信元へ送信する。Ｓ２０７での処理を終えると、制御部２１は、当該ディレクトリサーバ処理を終了する。
【００９９】
一方、Ｓ２０２で、サービス一覧の要求でないと判断すると、制御部２１は、Ｓ２０４へ移行し、Ｓ２０１で受信したＨＴＴＰリクエストがサービス定義情報の送信要求であるか否かを判断する。そして、サービス定義情報の送信要求であると判断すると、Ｓ２０５へ移行し、記憶部２３のサービス定義情報記憶部２４から、上記送信要求で指定されたサービス定義情報２５を読み出す。その後、Ｓ２０７へ移行し、読み出したサービス定義情報２５を含むＨＴＴＰレスポンスを、ＨＴＴＰリクエストの送信元へ送信した後、当該ディレクトリサーバ処理を終了する。
【０１００】
一方、Ｓ２０４で、ＨＴＴＰリクエストがサービス定義情報の送信要求でもないと判断すると、制御部２１は、Ｓ２０６へ移行し、Ｓ２０１で受信したＨＴＴＰリクエストに対応する所定の処理を実行し、その処理結果を示す情報を含むＨＴＴＰレスポンスを送信する（Ｓ２０７）。その後、当該ディレクトリサーバ処理を終了する。
【０１０１】
次に、複合機処理（図８）におけるＳ１１６で実行されるサービス受信処理について、図１０のフローチャートを用いて説明する。
このサービス受信処理を開始すると、制御部１１は、Ｓ３０１で、上記引数に設定されたＵＲＬ情報に従うＵＲＬ先へ、通信部１５を介して、サービス起動指令（ＨＴＴＰリクエスト）を送信し、上記ＵＲＬ情報に対応するサービス（利用者によって選択されたサービス）にかかるプロセスを、ＵＲＬ先の機能サーバ３０に起動させる。
【０１０２】
その後、Ｓ３０２に移行し、ＵＲＬ先の機能サーバ３０からセッションＩＤを受信する。尚、セッションＩＤは、機能サーバ３０の制御部３１により実行される後述の機能サーバ処理（図１２）のＳ４０５で生成され、Ｓ４０９で、指令元の当該複合機１０に送信される。
【０１０３】
続くＳ３０３では、複合機１０に対する指令（複合機指令）の有無を問い合わせるための信号である「複合機指令問合せ」を、機能サーバ３０へ送信する。尚、「複合機指令問合せ」には、Ｓ３０２で受信したセッションＩＤが含まれる。
【０１０４】
Ｓ３０３の処理後、制御部１１は、Ｓ３０３で送信した「複合機指令問合せ」に対する応答信号（ＨＴＴＰレスポンス）を受信し（Ｓ３０４）、「複合機指令問合せ」に対する返答が「ジョブ起動指令」であるか否かを判断する（Ｓ３０５）。尚、「ジョブ起動指令」は、機能サーバ３０の制御部３１により実行される後述のＳ６０３，Ｓ１７０３等の各処理で出力される。この「ジョブ起動指令」には、ジョブを特定するためのジョブＩＤと、ジョブ実行時の通信先のＵＲＬ情報である通信先ＵＲＬ情報と、が含まれる。
【０１０５】
Ｓ３０５で「ジョブ起動指令」であると判断すると、制御部１１は、Ｓ３０６へ移行し、ジョブの起動に必要なリソースを確保し、更にＳ３０７へ移行して、指定ジョブの起動処理（図１１参照。詳細後述）を実行する。その後、Ｓ３０８へ移行し、所定インターバル待機した後、Ｓ３０３へ移行する。
【０１０６】
一方、Ｓ３０５で「ジョブ起動指令」でないと判断すると、制御部１１は、Ｓ３０９へ移行し、「複合機指令問合せ」に対する返答が「ジョブ終了指令」であるか否かを判断する。尚、「ジョブ終了指令」は、機能サーバ３０の制御部３１により実行される後述のＳ６１０，Ｓ１７０８等の各処理で出力される。この「ジョブ終了指令」には、ジョブを特定するためのジョブＩＤが含まれる。
【０１０７】
Ｓ３０９で、「ジョブ終了指令」であると判断すると、制御部１１は、Ｓ３１０へ移行し、ジョブＩＤに対応するジョブに対して終了指示を入力して、そのジョブを終了し、リソースを解放する。その後、Ｓ３０８へ移行し、所定インターバル待機した後、Ｓ３０３に移行する。
【０１０８】
一方、Ｓ３０９で、「ジョブ終了指令」でないと判断した場合には、Ｓ３１１へ移行し、「複合機指令問合せ」に対する返答が「定期問合せ開始指令」であるか否か判断する。尚、「定期問合せ開始指令」は、機能サーバ３０の制御部３１により実行される後述のＳ６０９で出力される。
【０１０９】
Ｓ３１１で「定期問合せ開始指令」であると判断すると、制御部１１は、後述するＳ８５８（図１９参照）にてＲＡＭに一時記憶した格納先アドレス情報と、再登録許可情報とをＲＡＭから読み出し（Ｓ３１２）、その後Ｓ３１３に移行して、上記読み出した格納先アドレス情報と、再登録許可情報と、「定期問合せ開始指令」が含む情報とに基づき、記憶部１６が記憶する定期問合せ管理テーブル（図１６（ａ）参照）に、問合せ管理情報を書き込む。尚、Ｓ３１３の具体的な処理内容は、Ｓ６０９に関する説明と共に後述する。Ｓ３１３での処理を終えると、制御部１１は、Ｓ３０８へ移行し、所定インターバル待機した後、Ｓ３０３に移行する。
【０１１０】
また、Ｓ３１１で「定期問合せ開始指令」でないと判断すると、制御部１１は、Ｓ３１４に移行し、「複合機指令問合せ」に対する返答が「指令なし」を表すものであるか否かを判断する。
【０１１１】
Ｓ３１４で、「複合機指令問合せ」に対する返答が「指令なし」を表すものであると判断すると、制御部１１は、Ｓ３０８へ移行し、所定インターバル待機した後、Ｓ３０３へ移行する。一方、Ｓ３１４で、「複合機指令問合せ」に対する返答が「指令なし」を表すものでないと判断すると、Ｓ３１５へ移行し、「複合機指令問合せ」に対する返答が「サービス終了指令」であるか否かを判断する。尚、「サービス終了指令」は、機能サーバ３０の制御部３１により実行される後述のＳ６１１、Ｓ１７０９等で出力される。
【０１１２】
Ｓ３１５で「サービス終了指令」であると判断すると、制御部１１は、当該サービス受信処理を終了する。一方、「サービス終了指令」ではないと判断すると、Ｓ３１６に移行し、エラー処理（例えば、エラーである旨のメッセージを表示部１９のディスプレイ１９ａに表示する処理等）を実行し、その後、当該サービス受信処理を終了する。
【０１１３】
次に、Ｓ３０７にて実行される指定ジョブの起動処理について、図１１のフローチャートを用いて説明する。
指定ジョブの起動処理を開始すると、制御部１１は、まずＳ３５１で、「ジョブ起動指令」が「ＵＩ（ユーザインタフェース）ジョブ起動指令」であるか否かを判断する。尚、「ＵＩジョブ起動指令」とは、複合機１０に設けられたＵＩデバイス（操作部１２）の利用開始を通知するものである。
【０１１４】
そして、「ＵＩジョブ起動指令」であると判断すると、Ｓ３５２へ移行し、ジョブＩＤ、ジョブの通信先ＵＲＬ情報を渡してＵＩジョブ（図１８参照。詳細後述）を起動した後、当該指定ジョブの起動処理を終了する。これにより、複合機１０と機能サーバ３０との間で、ＵＩジョブの通信処理が開始される。尚、ＵＩジョブは、サービス受信処理のプロセスと並列動作する。
【０１１５】
一方、Ｓ３５１で、「ジョブ起動指令」が「ＵＩジョブ起動指令」でないと判断すると、制御部１１は、Ｓ３５３へ移行し、「ジョブ起動指令」が「入力ジョブ起動指令」であるか否かを判断する。尚、「入力ジョブ起動指令」とは、複合機１０に設けられた入力デバイス（読取部１３又は音入力部１７）の利用開始を通知するものである。
【０１１６】
具体的に、ここでは、「ジョブ起動指令」が、当該複合機１０の読取部（スキャナ）１３を用いて機能サーバ３０から提供されるサービスを受けるように指示する「スキャナジョブ起動指令」、又は、音入力部１７を用いて機能サーバ３０から提供されるサービスを受けるように指示する「ボイスジョブ起動指令」である場合に、「ジョブ起動指令」が「入力ジョブ起動指令」であると判断する。
【０１１７】
そして、「入力ジョブ起動指令」であると判断すると、Ｓ３５４へ移行し、ジョブＩＤ、ジョブの通信先ＵＲＬ情報を渡して入力ジョブを起動した後、当該指定ジョブの起動処理を終了する。尚、入力ジョブ起動の際には、入力ジョブに駆動対象の入力装置（読取部１３又は音入力部１７）を指定する。
【０１１８】
これにより、複合機１０と機能サーバ３０との間で、入力ジョブの通信処理が開始される。具体的に、入力ジョブを実行すると、制御部１１は、機能サーバ３０から指示されたデータを、入力装置（読取部１３又は音入力部１７）を用いて生成し、これを、機能サーバ３０に提供して、所定のサービス（データの公開サービス等）を受ける。尚、この入力ジョブも、サービス受信処理のプロセスと並列動作する。
【０１１９】
また、Ｓ３５３で「ジョブ起動指令」が「入力ジョブ起動指令」ではないと判断すると、制御部１１は、Ｓ３５５に移行し、「ジョブ起動指令」が「出力ジョブ起動指令」であるか否か判断する。尚、「出力ジョブ起動指令」とは、複合機１０に設けられた出力デバイス（記録部１４又は音出力部１８）の利用開始を通知するものである。
【０１２０】
具体的に、ここでは、「ジョブ起動指令」が、当該複合機１０の記録部（プリンタ）１４を用いて機能サーバ３０から提供されるサービスを受けるように指示する「印刷ジョブ起動指令」、又は、音出力部１８を用いて機能サーバ３０から提供されるサービスを受けるように指示する「スピーカジョブ起動指令」である場合に、「ジョブ起動指令」が「出力ジョブ起動指令」であると判断する。
【０１２１】
そして、「出力ジョブ起動指令」であると判断すると、Ｓ３５６に移行し、ジョブＩＤ、ジョブの通信先ＵＲＬ情報を渡して、出力ジョブ（図３６参照。詳細後述）を起動した後、当該指定ジョブの起動処理を終了する。尚、出力ジョブの起動の際には、出力ジョブに駆動対象の出力装置（記録部１４又は音出力部１８）を指定する。これにより、複合機１０と機能サーバ３０との間で、出力ジョブの通信処理が開始される。そして、この出力ジョブは、サービス受信処理のプロセスと並列動作する。
【０１２２】
一方、Ｓ３５５で、「ジョブ起動指令」が「出力ジョブ起動指令」ではないと判断すると、制御部１１は、ジョブ（ＵＩジョブ、入力ジョブ、出力ジョブ）を起動することなく、当該指定ジョブの起動処理を終了する。
【０１２３】
次に、Ｓ３０１で複合機１０が送信するサービス起動指令を受ける機能サーバ３０側のプログラムにて実現される機能サーバ処理について説明する。尚、図１２は、機能サーバ３０の制御部３１が実行する機能サーバ処理を表すフローチャートである。この機能サーバ処理を実現するためのプログラムは、サービスの種類毎に用意される。
【０１２４】
機能サーバ処理を開始すると、制御部３１は、ＨＴＴＰリクエストを受信するまで待機し（Ｓ４０１）、通信部１５を介してＨＴＴＰリクエストを受信すると、Ｓ４０２に移行し、Ｓ４０１で受信したＨＴＴＰリクエストがサービス起動指令であるか否かを判断する。Ｓ４０２で、サービス起動指令であると判断すると、制御部３１は、Ｓ４０５へ移行し、セッションＩＤを生成して、これを格納した送信データを生成すると共に、サービスを提供するためのプロセスを起動する。例えば、当該機能サーバ処理が、定期的に情報を提供するサービス（ブログ検索サービス、ローカルニュース提供サービス）の利用登録を受けるための処理である場合には、上記プロセスとして、図１４に示す登録処理を実行する（詳細後述）。その後、Ｓ４０９に移行する。
【０１２５】
また、Ｓ４０２で、ＨＴＴＰリクエストがサービス起動指令でないと判断すると、制御部３１は、Ｓ４０６に移行し、Ｓ４０１で受信したＨＴＴＰリクエストが「サービス終了指令」であるか否かを判断する。Ｓ４０６で、「サービス終了指令」であると判断すると、制御部３１は、Ｓ４０７に移行し、セッションＩＤ及び確保したリソースを解放し、Ｓ４０９へ移行する。
【０１２６】
一方、Ｓ４０６で「サービス終了指令」でないと判断すると、制御部３１は、Ｓ４０８にて、サービス制御情報処理（図１３参照。詳細後述）を実行した後、Ｓ４０９に移行する。Ｓ４０９では、Ｓ４０５，Ｓ４０７及びＳ４０８のいずれかのステップで生成した送信データを格納したＨＴＴＰレスポンスを生成し、これを通信部３２を介して、ＨＴＴＰリクエスト送信元の複合機１０に送信する。
【０１２７】
Ｓ４０９の処理後、制御部３１は、Ｓ４０８にてサービス制御情報処理を実行したか否か判断し（Ｓ４１０）、サービス制御情報処理を実行したと判断すると、Ｓ４１１にて、セッションＩＤ又はジョブＩＤに対応するメモリアドレスに「送信済み」フラグをセットした後、当該機能サーバ処理を終了する。一方、Ｓ４１０でサービス制御情報処理を実行していないと判断すると、Ｓ４１１での処理を実行することなく、当該機能サーバ処理を終了する。
【０１２８】
次に、制御部３１が、機能サーバ処理のＳ４０８にて実行するサービス制御情報処理について説明する。図１３は、サービス制御情報処理を表すフローチャートである。
サービス制御情報処理を実行すると、制御部３１は、Ｓ５０１で、サービスに送る情報が存在するか否かを判断する。具体的には、機能サーバ処理（図１２）のＳ４０１で受信したＨＴＴＰリクエストに、セッションＩＤ又はジョブＩＤにて特定されるサービスを実現するプロセスに対する情報が含まれているか否かを判断する。
【０１２９】
そして、サービス（プロセス）に送る情報が存在しないと判断すると、Ｓ５０６に移行し、サービス（プロセス）に送る情報が存在すると判断すると、Ｓ５０２に移行して、セッションＩＤ又はジョブＩＤに対応するプロセスを特定する。即ち、受信したＨＴＴＰリクエストに含まれている情報の送信先となるプロセスを特定する。
【０１３０】
ここで、プロセスを特定することができないと、制御部３１は、Ｓ５０３でＹｅｓと判断して、送信データとしてエラー通知情報を生成し（Ｓ５０４）、当該サービス制御情報処理を終了する。一方、プロセスを特定することができた場合には、Ｓ５０３でＮｏと判断し、Ｓ５０５で、特定したプロセスに、上記情報を送信した後、Ｓ５０６へ移行する。
【０１３１】
Ｓ５０６では、セッションＩＤ又はジョブＩＤに対応するプロセスにて生成された返信情報を記憶するメモリ領域（以下、「返信情報格納領域」とする。）を特定し、特定できない場合には、Ｓ５０７でＹｅｓと判断して、Ｓ５０４に移行し、ＨＴＴＰレスポンスに格納する送信データとして、エラー通信情報を生成する。その後、当該サービス制御情報処理を終了する。
【０１３２】
一方、特定できた場合には、Ｓ５０７でＮｏと判断して、Ｓ５０８に移行し、特定した返信情報格納領域に、返信情報が格納されているか否か判断する。そして、返信情報が格納されていると判断すると、Ｓ５０９へ移行し、その返信情報に基づく「複合機指令」を、送信データとして生成する。その後、当該サービス制御情報処理を終了する。
【０１３３】
一方、Ｓ５０８で、上記特定した返信情報格納領域に返信情報が格納されていないと判断すると、Ｓ５１０に移行し、送信データとして、「複合機指令無し」の情報を生成した後、当該サービス制御情報処理を終了する。
【０１３４】
次に、機能サーバ３０の制御部３１がＳ４０５で起動するプロセスについて説明する。尚、上記プロセスが行う処理の内容はサービスの種類によって異なるため、ここでは、定期的に情報を提供するサービス（ブログ検索サービス、ローカルニュース提供サービス）の利用登録を受けるためのプロセスが行う登録処理ついて説明する。尚、図１４は、制御部３１が実行する登録処理を表すフローチャートである。
【０１３５】
登録処理を実行すると、制御部３１は、Ｓ６０１で初期化処理を実行し、続くＳ６０２で、サービス側ＵＩジョブ（図１７参照。詳細後述）を起動する。続いて、Ｓ６０３では、「ＵＩジョブ起動指令」を複合機指令として出力する。具体的には、Ｓ４０５で生成したセッションＩＤに対応する返信情報格納領域に対して、「ＵＩジョブ起動指令」を書き込む処理を行う。
【０１３６】
これによって、「ＵＩジョブ起動指令」は、サービス制御情報処理を介し、複合機指令として、複合機１０に送信される。また、制御部３１は、上述の機能サーバ処理（図１２）におけるＳ４１１にて「送信済み」がセットされることで出力を確認する。尚、この「ＵＩジョブ起動指令」には、Ｓ６０２で起動したサービス側ＵＩジョブについてのジョブＩＤとジョブの通信先ＵＲＬ情報とが含まれる。
【０１３７】
Ｓ６０３での処理を終えると、制御部３１は、Ｓ６０４に移行し、パラメータの値入力が完了したか否かを判断する。尚、パラメータの値入力が完了したか否かは、後述するサービス側ＵＩジョブ（図１７）におけるＳ７１１によってパラメータ入力済みの通知が、当該登録処理のプロセスに対して入力されたか否かにより判断する。
【０１３８】
Ｓ６０４で、パラメータの値入力が完了していないと判断すると、制御部３１は、Ｓ６０５へ移行し、停止が通知されたか否かを判断する。尚、停止の通知は、後述するサービス側ＵＩジョブ（図１７）におけるＳ７０９で行われる。
【０１３９】
Ｓ６０５で、停止が通知されていないと判断すると、制御部３１は、Ｓ６０４に移行し、Ｓ６０５で停止が通知されたと判断すると、Ｓ６１０に移行する。また、Ｓ６０４で、パラメータの値入力が完了したと判断した場合には、Ｓ６０６へ移行し、リクエストサービスＩＤを生成する。
【０１４０】
尚、リクエストサービスＩＤは、入力されたパラメータの値に対応するサービスを、入力元の複合機１０に対してのみ提供するためのものである。このリクエストサービスＩＤは、サービスの利用登録毎に（即ち、パラメータ情報の入力毎に）、ユニークに生成され、後述のＳ６０９により、上記入力元の複合機１０に対してのみに通知される。
【０１４１】
Ｓ６０６での処理を終えると、制御部３１は、Ｓ６０７にて、記憶部３３に記憶されたリクエストサービスＩＤ管理テーブルに、Ｓ６０６で生成したリクエストサービスＩＤと、入力された各パラメータの値を表すパラメータ情報と、を書き込む。図１５（ａ）は、記憶部３３に記憶されたリクエストサービスＩＤ管理テーブルの構成を表す説明図である。
【０１４２】
リクエストサービスＩＤ管理テーブルは、リクエストサービスＩＤと、そのリクエストサービスＩＤの生成時にクライアント装置としての複合機１０から入力された各パラメータの値を表すパラメータ情報とが、互いに関連付けられて記憶されたものである。このリクエストサービスＩＤ管理テーブルは、サービスの種類毎に用意される登録処理のプロセスに対応して、サービスの種類毎に、記憶部３３に設けられている。例えば、記憶部３３には、ブログ検索サービス用のリクエストサービスＩＤ管理テーブルと、ローカルニュース提供サービス用のリクエストサービスＩＤ管理テーブルとが設けられている。
【０１４３】
即ち、Ｓ６０７では、当該プロセスに対応するリクエストサービスＩＤ管理テーブルに、Ｓ６０６で生成したリクエストサービスＩＤと、複合機１０から入力された各パラメータの値を表すパラメータ情報と、を記述して登録する。
【０１４４】
Ｓ６０７での処理を終えると、制御部３１は、Ｓ６０８に移行し、記憶部３３が記憶する定期問合せ返信管理テーブルに、Ｓ６０６で生成したリクエストサービスＩＤの返信管理情報を書き込む。尚、図１５（ｂ）は、記憶部３３に記憶された定期問合せ返信管理テーブルの構成を表す説明図である。
【０１４５】
図１５（ｂ）に示すように、定期問合せ返信管理テーブルは、リクエストサービスＩＤと、サービススタート情報と、サービスＵＲＬ情報と、サービスステータス情報と、問合せ日時情報と、サービスキャンセル情報と、からなる返信管理情報が、リクエストサービスＩＤ毎に、記述された構成にされている。
【０１４６】
サービススタート情報は、サービスを提供する準備が完了したか否かを表す情報であって、サービスを提供する準備が完了している場合には、値「ＴＲＵＥ」で表され、サービスを提供する準備か完了していない場合には、値「ＦＡＬＳＥ」で表される情報である。
【０１４７】
また、サービスＵＲＬ情報は、リクエストサービスＩＤに対応するサービスを提供する機能サーバ３０のＵＲＬ情報であり、サービスステータス情報は、サービスを提供する機能サーバ３０側のステータス情報である。
【０１４８】
サービスステータス情報は、リクエストサービスＩＤに対応するサービスのステータスが正常である場合には値「０」で表され、サービスのステータスが異常である場合には、その原因に対応する負値で表される。
【０１４９】
また、問合せ日時情報は、リクエストサービスＩＤを問合せ対象とした定期問合せ信号を受信した最後の日時を表す情報である。尚、Ｓ６０８での書込時における問合せ日時情報は、例外的に、その書込時の日時で表される。
【０１５０】
その他、サービスキャンセル情報は、サービスの提供が終了したか否かを表す情報であり、サービスの提供が終了している場合には、値「ＴＲＵＥ」で表され、サービスの提供が継続している場合には、値「ＦＡＬＳＥ」で表される。
【０１５１】
そして、Ｓ６０８の処理を終えると、制御部３１は、「定期問合せ開始指令」を複合機指令として出力する（Ｓ６０９）。具体的に、ここでは、Ｓ４０５で生成したセッションＩＤに対応する返信情報格納領域に対して、「定期問合せ開始指令」を書き込む処理を行う。この書き込みによって、「定期問合せ開始指令」は、サービス制御情報処理を介し、複合機指令として、複合機１０に送信される。
【０１５２】
尚、「定期問合せ開始指令」は、Ｓ６０６で生成したリクエストサービスＩＤと、複合機１０に対して指定する定期問合せの時間間隔を表す情報（問合せ間隔情報）と、その時間間隔後、即時の問合せが必要であるか否かを表す情報（即時処理情報）と、サービスの利用時に複合機１０側で動作が必要となる入出力デバイスの種類を表す情報（利用デバイス情報）と、を含むものである。
【０１５３】
複合機１０の制御部１１は、この「定期問合せ開始指令」を受信すると、Ｓ３１２，Ｓ３１３（図１０）に移行し、Ｓ３１２にてＲＡＭから読み出した再登録許可情報及び利用登録情報の格納先アドレス情報と、「定期問合せ開始指令」が含む情報と、に基づいて、記憶部１６が記憶する定期問合せ管理テーブル（図１６（ａ））に、リクエストサービスＩＤ、リクエストステータス情報、問合せ間隔情報、残り時間情報、即時処理情報、利用デバイス情報、利用登録情報の格納先アドレス情報、及び、再登録許可情報からなる問合せ管理情報を書き込む。尚、図１６（ａ）は、記憶部１６が記憶する定期問合せ管理テーブルの構成を表す説明図であり、図１６（ｂ）及び図１６（ｃ）は、記憶部１６が記憶する利用登録情報の構成を表す説明図である。
【０１５４】
ここで、定期問合せ管理テーブルに書き込まれるリクエストサービスＩＤ、問合せ間隔情報、即時処理情報、及び利用デバイス情報は、「定期問合せ開始指令」に含まれる情報と同一のものである。一方、リクエストステータス情報は、問合せに対する返答として、上述したサービスステータス情報を機能サーバ３０側から取得するか否かを表す情報であり、取得する場合には値「ＴＲＵＥ」で表され、取得しない場合には値「ＦＡＬＳＥ」で表される。
【０１５５】
尚、Ｓ３１３では、リクエストステータス情報を値「ＴＲＵＥ」として、定期問合せ管理テーブルに、その情報を書き込む。但し、本実施例の複合機１０は、操作部１２からリクエストステータス情報の値変更指令が入力されると、その指令に従って、定期問合せ管理テーブルにおける指令対象のリクエストステータス情報の値を「ＦＡＬＳＥ」（又は「ＴＲＵＥ」）に変更する。
【０１５６】
また、残り時間情報は、次回の問合せ時刻までの残り時間を表す情報である。Ｓ３１３では、問合せ間隔情報と同一の値を示す残り時間情報が、定期問合せ管理テーブルに書き込まれるが、この残り時間情報は、後述するＳ９０１の処理にて逐次更新される。
【０１５７】
その他、利用登録情報は、問合せ管理情報毎（換言すると、リクエストサービスＩＤ毎）に個別に管理されており、問合せ管理情報に対応するサービスの利用登録をする際に用いられたサービス定義情報に記述された情報であって、リンク選択（Ｓ１１１）されたサービスのＬｉｎｋ＿Ｔｉｔｌｅタグの値を示すサービス名称情報と、Ｌｉｎｋ＿Ｌｏｃａｔｉｏｎタグの値（若しくは、アドレス入力画面を通じて入力されたＵＲＬ情報）を示す利用登録先ＵＲＬ情報と、その利用登録先（Ｌｉｎｋ＿Ｌｏｃａｔｉｏｎ先）から取得したサービスＩ／Ｆ情報と、後述するパラメータ情報送信処理（図１９）でディスプレイ１９ａに表示されるパラメータ入力用画面（例えば図５の画面）を通じて利用者が入力したパラメータの値を表すパラメータ情報と、からなる。
【０１５８】
尚具体的に、図１６（ｂ）は、ブログ検索サービスについての利用登録情報の構成を表すものであり、図１６（ｃ）は、ローカルニュース提供サービスについての利用登録情報の構成を表すものである。
【０１５９】
また、定期問合せ管理テーブルに登録される利用登録情報の格納先アドレス情報は、この利用登録情報の格納先のメモリアドレスを表す情報である。その他、再登録許可情報は、後述するＳ８５６での問合せに応じて操作部１２から入力された再登録の許可／不許可を表す情報であり、再登録が許可されている場合には、値「ＴＲＵＥ」で表され、再登録が許可されていない場合には、値「ＦＡＬＳＥ」で表される。
【０１６０】
話を戻して、Ｓ６０９での出力を終えると、制御部３１は、Ｓ６１０に移行し、「ＵＩジョブ終了指令」を複合機指令として出力する（Ｓ６１０）。具体的に、ここでは、Ｓ４０５で生成したセッションＩＤに対応する返信情報格納領域に対して、「ＵＩジョブ終了指令」を書き込む処理を行う。これにより、「ＵＩジョブ終了指令」は、サービス制御情報処理を介し、複合機指令として、複合機１０に送信される。
【０１６１】
Ｓ６１０での処理を終えると、制御部３１は、Ｓ６１１に移行し、Ｓ６０３で起動したサービス側ＵＩジョブに対して終了指示を入力して、サービス側ＵＩジョブを終了すると共に、「サービス終了指令」を複合機指令として出力する。その後、当該登録処理を終了する。
【０１６２】
次に、機能サーバ３０の制御部３１がＳ６０２で起動するサービス側ＵＩジョブを、図１７を用いて説明すると共に、複合機１０の制御部１１が、Ｓ６０３で出力される「ＵＩジョブ起動指令」を受けて（Ｓ３０４）、Ｓ３５２で起動するＵＩジョブを、図１８を用いて説明する。尚、図１７は、機能サーバ３０の制御部３１が実行するサービス側ＵＩジョブを表すフローチャートであり、図１８は、複合機１０の制御部１１が実行するＵＩジョブを表すフローチャートである。
【０１６３】
サービス側ＵＩジョブを実行すると、制御部３１は、まずＳ７０１で、複合機１０から「複合機ジョブ指令問合せ」を受信する。尚、「複合機ジョブ指令問合せ」は、複合機１０の制御部１１により実行されるＵＩジョブ（図１８）のＳ８００等で送信用データに設定され、Ｓ８０６で送信される。
【０１６４】
続いて、Ｓ７０２では、サービスの実行に必要なパラメータの値を入力させるための「パラメータ要求指令」を複合機指令として複合機１０へ送信する。尚、「パラメータ要求指令」と共に、複合機１０には、記憶部３３のサービスＩ／Ｆ情報記憶部３４に記憶されているサービスＩ／Ｆ情報３６が送信される。具体的に、当該サービス側ＵＩジョブを起動した登録処理のプロセスが、ブログ検索サービスの利用登録を受けるためのプロセスである場合には、図６に示すサービスＩ／Ｆ情報３６が送信される。また、当該サービス側ＵＩジョブを起動した登録処理のプロセスが、ローカルニュース提供サービスの利用登録のためのプロセスである場合には、図７に示すサービスＩ／Ｆ情報３６が送信される。
【０１６５】
Ｓ７０２の処理後、制御部３１は、Ｓ７０３に移行し、エラーカウントを初期化する。その後、上記サービスＩ／Ｆ情報３６に基づくパラメータ入力用画面を通じて利用者から入力された各パラメータの値を表すパラメータ情報を、複合機１０から受信する（Ｓ７０４）。尚、パラメータ情報は、複合機１０の制御部１１により実行されるＵＩジョブ（図１８）のＳ８１０で送信用データとして設定され、Ｓ８０６で送信される。
【０１６６】
Ｓ７０４でパラメータ情報を受信すると、制御部３１は、Ｓ７０５に移行し、Ｓ７０４で受信したパラメータ情報が表す各パラメータの値が正常であるか否かを判断する。そして、パラメータの値が正常でないと判断すると、Ｓ７０６へ移行し、正常でないと判断された回数が２回目であるか否かを、上述のエラーカウントに基づいて判断する。
【０１６７】
Ｓ７０６で、２回目でない（１回目である）と判断した場合には、Ｓ７０７へ移行し、機能サーバ３０が複合機１０からの情報を正常に受け取ることができたか否かの通知であるサーバ受取状況として「サーバ受取ＮＧ（異常受取）」を、複合機１０のＵＩジョブに向けて出力する。
【０１６８】
Ｓ７０７の処理後、制御部３１は、エラーカウントをカウントアップし（Ｓ７０８）、Ｓ７０４に移行する。一方、Ｓ７０６で、２回目であると判断すると、制御部３１は、Ｓ７０９へ移行し、当該サービス側ＵＩジョブの起動元のプロセス（登録処理のプロセス）へ停止を通知した後、当該サービス側ＵＩジョブを終了する。
【０１６９】
また、Ｓ７０５で、パラメータの値が正常であると判断すると、制御部３１は、Ｓ７１０へ移行し、サーバ受取状況として「サーバ受取ＯＫ（正常受取）」を、複合機１０のＵＩジョブに向けて出力する。
【０１７０】
Ｓ７１０での処理を終えると、制御部３１は、Ｓ７１１に移行し、当該サービス側ＵＩジョブの起動元のプロセス（登録処理のプロセス）へ「パラメータ入力済み」を通知する。その後、制御部３１は、Ｓ７１２にて、複合機１０から「サービス状態情報要求」を受信するまで待機し、「サービス状態情報要求」を受信すると、Ｓ７１３にて、「サービス状態情報」を、複合機１０のＵＩジョブに向けて送信する。その後、Ｓ７１２へ移行する。
【０１７１】
即ち、他の処理によって、当該サービス側ＵＩジョブが終了される（Ｓ６１１）まで、複合機１０から「サービス状態情報要求」を受信し、それに応答して「サービス状態情報」を送信するという処理を繰返す。尚具体的に、「サービス状態情報」は、パラメータの値入力が正常に行われたことを示す情報である。
【０１７２】
一方、複合機１０の制御部１１は、Ｓ６０３で出力される「ＵＩジョブ起動指令」を受けて、Ｓ３５２でＵＩジョブ（図１８）を起動すると、次の処理を実行する。
ＵＩジョブを実行すると、複合機１０の制御部１１は、まずＳ８００にて、複合機１０に対する指令の問い合わせである「複合機ジョブ指令問合せ」を、送信用データに設定し、その後、Ｓ８０１で、当該ＵＩジョブ起動元のプロセス（サービス受信処理のプロセス）からの終了指示があったか否かを判断する。尚、終了指示は、Ｓ３１０で出力される。
【０１７３】
Ｓ８０１で終了指示があったと判断すると、制御部１１は、Ｓ８０２に移行し、当該ＵＩジョブ起動元のプロセス（サービス受信処理のプロセス）へ終了を通知した後、当該ＵＩジョブを終了する。
【０１７４】
一方、Ｓ８０１で終了指示がないと判断すると、制御部１１は、Ｓ８０３へ移行し、操作部１２及び表示部１９がビジー状態であるか否かを判断する。具体的には、操作部１２及び表示部１９がビジー状態であるか否かを表すビジーフラグＦｕに基づき、ビジーフラグＦｕが立っている場合にはビジー状態であると判断し、ビジーフラグＦｕが下りている場合にはビジー状態でないと判断する。
【０１７５】
そして、操作部１２及び表示部１９がビジー状態であると判断すると、Ｓ８０４へ移行し、操作部１２及び表示部１９のビジー状態が解除されるまで待機した後、Ｓ８０３へ移行する。一方、Ｓ８０３で、ビジー状態でないと判断した場合には、Ｓ８０５へ移行し、ビジーフラグＦｕを立てる。
【０１７６】
Ｓ８０５の処理を終えると、制御部１１は、Ｓ８０６に移行し、予めＳ８００等で設定した送信用データを機能サーバ３０へ送信する。送信後、制御部１１は、Ｓ８０６での送信に対する応答信号を受信し（Ｓ８０７）、受信した応答信号が「パラメータ要求指令」であるか否かを判断する（Ｓ８０８）。尚、「パラメータ要求指令」は、機能サーバ３０の制御部３１により実行されるＳ７０２の処理で送信される。
【０１７７】
Ｓ８０８で、「パラメータ要求指令」であると判断すると、制御部１１は、Ｓ８１０へ移行して、パラメータ情報送信処理（図１９参照。詳細後述）を実行し、「パラメータ要求指令」に含まれるサービスＩ／Ｆ情報３６に基づきパラメータ入力用画面を表示部１９のディスプレイ１９ａに表示して、パラメータ値についての入力操作を利用者に促すと共に、パラメータの値入力を受け付ける（Ｓ８５２）。
【０１７８】
そして、操作部１２を通じパラメータの値についての確定信号が入力されると、機能サーバ３０のサービス側ＵＩジョブに向けて、上記入力されたパラメータの値を表すパラメータ情報を送信するために、パラメータ情報を、送信用データに設定する（Ｓ８７０）。但し、当該ＵＩジョブが、後述するＳ１６３８の処理にて起動されたサービス受信処理に起因して実行されたものである場合には、当該パラメータ情報送信処理が、一度、機能サーバ３０側で利用登録が抹消されたサービスについての再登録にかかるパラメータ情報の送信を行うためのものとなるため、制御部１１は、上記定期問合せ管理テーブルに登録された利用登録情報に基づき、ディスプレイ１９ａにパラメータ入力用画面を表示することなく、パラメータ情報を生成し、これを送信用データに設定する処理を行う。その後、制御部１１は、Ｓ８１１へ移行し、ビジーフラグＦｕを下げた後、Ｓ８０１へ移行する。
【０１７９】
一方、Ｓ８０８で、「パラメータ要求指令」ではないと判断すると、制御部１１は、Ｓ８１２へ移行し、Ｓ８０７で受信した応答信号が「サービス状態情報」であるか否かを判断する。尚、「サービス状態情報」は、機能サーバ３０の制御部３１により実行されるＳ７１３の処理で送信される。
【０１８０】
Ｓ８１２で、「サービス状態情報」であると判断すると、制御部１１は、Ｓ８１３へ移行し、この「サービス状態情報」に基づく情報を、表示部１９のディスプレイ１９ａに表示する。その後、サービス状態情報を機能サーバ３０から取得するための「サービス状態情報要求」を、送信用データに設定する（Ｓ８２１）。Ｓ８２１での処理を終えると、制御部１１は、Ｓ８１１へ移行し、ビジーフラグＦｕを下げた後、Ｓ８０１へ戻る。
【０１８１】
一方、Ｓ８１２で、「サービス状態情報」でないと判断した場合には、Ｓ８１４へ移行し、Ｓ８０７で受信した応答信号が、機能サーバ３０が複合機１０からの情報を正常に受け取ることができたか否かを表す「サーバ受取状況」であるか否かを判断する。そして、「サーバ受取状況」であると判断すると、制御部１１は、Ｓ８１５へ移行し、この「サーバ受取状況」が「サーバ受取ＮＧ」を表すものであるか否かを判断する。
【０１８２】
「サーバ受取ＮＧ」を表すものであると判断すると、制御部１１は、Ｓ８１６に移行し、機能サーバ３０のサービス側ＵＩジョブに、前回送信した情報を提供するため、前回送信した情報と同一の情報である再送信情報（パラメータ情報）を、送信用データに設定する。その後、Ｓ８１１へ移行し、ビジーフラグＦｕを下げた後、Ｓ８０１へ移行する。
【０１８３】
一方、Ｓ８１５で、「サーバ受取状況」が「サーバ受取ＮＧ」を表すものではないと判断すると、制御部１１は、Ｓ８２２に移行し、「サービス状態情報要求」を、送信用データに設定する。その後、Ｓ８１１へ移行し、ビジーフラグＦｕを下げた後、Ｓ８０１へ移行する。
【０１８４】
また、Ｓ８１４で、上記応答信号が「サーバ受取状況」でないと判断すると、制御部１１は、Ｓ８１７へ移行し、Ｓ８０７で受信した応答信号が「指令なし」を表すものであるか否かを判断する。
【０１８５】
Ｓ８１７で、複合機指令が「指令なし」を表すものであると判断すると、制御部１１は、Ｓ８２３に移行し、「複合機ジョブ指令問合せ」を、送信用データに設定する。その後、Ｓ８１１へ移行し、ビジーフラグＦｕを下げた後、Ｓ８０１へ移行する。一方、Ｓ８１７で、複合機指令が「指令なし」を表すものでないと判断した場合には、Ｓ８１８へ移行し、その他の処理を実行する。尚、この際には、処理の内容に適合するデータを、送信用データに設定する。例えば、ここでは、応答信号に対応する処理の実行後に、「複合機ジョブ指令問合せ」を、送信用データに設定する。その後、Ｓ８１１へ移行し、ビジーフラグＦｕを下げた後、Ｓ８０１へ移行する。
【０１８６】
次に、上述したＳ８１０で実行されるパラメータ情報送信処理について、図１９を用いて説明する。尚、図１９は、複合機１０の制御部１１が実行するパラメータ情報送信処理を表すフローチャートである。
【０１８７】
パラメータ情報送信処理を実行すると、制御部１１は、まずＳ８５０にて、当該パラメータ情報送信処理によるパラメータ情報の送信が、定期問合せの必要なサービスについての利用登録となる送信であるか否かを判断する。
【０１８８】
そして、利用登録となる送信ではない（換言すると、定期問合せが不要な単発的なサービスについてのパラメータ情報の送信である）と判断すると（Ｓ８５０でＮｏ）、制御部１１は、Ｓ８５２に移行し、「パラメータ要求指令」に含まれるサービスＩ／Ｆ情報３６に基づき、パラメータ入力用画面を表示部１９のディスプレイ１９ａに表示して、パラメータ値についての入力操作を利用者に促すと共に、パラメータの値入力を受け付ける。
【０１８９】
そして、操作部１２を通じパラメータの値についての確定信号が入力されると、機能サーバ３０のサービス側ＵＩジョブに対する送信用データとして、上記入力された各パラメータの値を表すパラメータ情報を生成する（Ｓ８５３）。
【０１９０】
Ｓ８５３の処理を終えると、制御部１１は、Ｓ８５４に移行し、Ｓ８５０での判断と同一の判断を行う。即ち、Ｓ８５０でＮｏと判断している場合には、Ｓ８５４でもＮｏと判断し、Ｓ８５０でＹｅｓと判断している場合には、Ｓ８５４でもＹｅｓと判断する。
【０１９１】
Ｓ８５４でＮｏと判断すると、制御部１１は、Ｓ８５６〜Ｓ８５８の処理をスキップして、Ｓ８７０に移行し、Ｓ８５３で生成したパラメータ情報を、送信用データに設定する。その後、当該パラメータ情報送信処理を終了する。
【０１９２】
一方、Ｓ８５０で、当該パラメータ情報送信処理によるパラメータ情報の送信が、利用登録となる送信であると判断すると（Ｓ８５０でＹｅｓ）、制御部１１は、Ｓ８５１に移行し、利用登録が、初回の利用登録であるか否か判断する。
【０１９３】
具体的には、当該パラメータ情報送信処理を実行するに至ったサービス受信プロセスの起動元を判別する（具体的には、サービス受信処理のプロセスがＳ１１６で起動されたのか、それとも、後述するＳ１６３８（図３２参照）で起動されたのかを判別する）ことで、利用登録が、初回の利用登録であるか否か判断する。そして、サービス受信処理のプロセスがＳ１１６で起動されている場合には、初回の利用登録であると判断し、Ｓ１６３８で起動されている場合には、初回の利用登録ではない（即ち再登録である）と判断する。
【０１９４】
Ｓ８５１で初回の利用登録であると判断すると、制御部１１は、Ｓ８５２に移行して、上述したように、「パラメータ要求指令」に含まれるサービスＩ／Ｆ情報３６に基づき、パラメータ入力用画面を表示部１９のディスプレイ１９ａに表示し、操作部１２を通じパラメータの値についての確定信号が入力されると、上記入力された各パラメータの値を表すパラメータ情報を生成する（Ｓ８５３）。そして、Ｓ８５４に移行し、Ｙｅｓと判断する。
【０１９５】
Ｓ８５４でＹｅｓと判断すると、制御部１１は、Ｓ８５６に移行して、利用登録が機能サーバ３０側で抹消された場合に自動での再登録を許可するか否か（許可／不許可）を問い合わせるメッセージを、ディスプレイ１９ａに表示する。そして、この問合せに応じて操作部１２から入力される再登録の許可／不許可を表す再登録許可情報を取得する。
【０１９６】
Ｓ８５６での処理を終えると、制御部１１は、Ｓ８５７に移行し、Ｓ８５３で生成したパラメータ情報（送信対象のパラメータ情報）に基づいて、このパラメータ情報のコピー内容を含む利用登録情報を生成し、この利用登録情報を記憶部１６に保存する。
【０１９７】
Ｓ８５７での処理を終えると、制御部１１は、利用登録情報の格納先アドレス情報（Ｓ８５７で生成・保存した利用登録情報が記憶された記憶部１６のメモリアドレスを表す情報）と、Ｓ８５６で取得した再登録許可情報とを、ＲＡＭに一時記憶し（Ｓ８５８）、その後、Ｓ８７０に移行して、上記生成したパラメータ情報を、送信用データに設定する。その後、当該パラメータ情報送信処理を終了する。
【０１９８】
これに対し、Ｓ８５１で初回の利用登録ではない（再登録である）と判断すると、制御部１１は、Ｓ８６１に移行し、Ｓ１６３８でサービス受信処理のプロセスを起動する際に、ＲＡＭに保持したリクエストサービスＩＤの情報に基づき、そのリクエストサービスＩＤに対応する利用登録情報の格納先アドレス情報を、定期問合せ管理テーブルから読出し、この格納先アドレス情報に基づいて、記憶部１６から上記リクエストサービスＩＤに対応する利用登録情報を読み出す。
【０１９９】
Ｓ８６１での処理を終えると、制御部１１は、Ｓ８６２に移行して、上記Ｓ８６１で読み出した利用登録情報に含まれるサービスＩ／Ｆ情報と、「パラメータ要求指令」に含まれるサービスＩ／Ｆ情報と、を比較し、「パラメータ要求指令」に含まれるサービスＩ／Ｆ情報が、利用登録情報に含まれるサービスＩ／Ｆ情報と、一致するか否かを判断する。
【０２００】
そして、サービスＩ／Ｆ情報が一致しないと判断すると、Ｓ８５２に移行して、後続のＳ８５２からＳ８７０までの処理を実行し、パラメータ入力用画面を通じ利用者から入力された各パラメータの値を表すパラメータ情報を、送信用データに設定する。その後、当該パラメータ情報送信処理を終了する。
【０２０１】
一方、サービスＩ／Ｆ情報が一致すると判断すると、制御部１１は、Ｓ８６３に移行し、上記Ｓ８６１で読み出した利用登録情報が含むパラメータ情報をコピーして、送信対象のパラメータ情報を生成する。その後、Ｓ８７０に移行して、そのパラメータ情報（Ｓ８６３で利用登録情報に基づき生成したパラメータ情報）を、送信用データに設定する。その後、当該パラメータ情報送信処理を終了する。
【０２０２】
次に、上述の定期問合わせを実現するために、複合機１０の制御部１１が実行する定期問合せ処理について説明する。図２０は、制御部１１が実行する定期問合せ処理を表すフローチャートである。尚、この定期問合せ処理は、複合機１０の電源投入時から開始され、複合機１０の電源がオフにされるまで、継続的に実行される。
【０２０３】
定期問合せ処理を実行すると、制御部１１は、Ｓ９０１にて、定期問合せ管理テーブルの各残り時間情報を更新する。具体的には、前回の内部時計の値（時刻）と、現在の内部時計の値（時刻）との差を求めて、この差（カウントダウン量）を、残り時間情報が示す値から引き算し、残り時間情報を更新する。即ち、Ｓ９０１では、残り時間のカウントダウンと共に、内部時計の値の取得及び一時記憶を行う。
【０２０４】
尚、Ｓ９０１の処理は、後述するように（高速で）繰り返されるため、前回のカウントダウンと、今回のカウントダウンとの間に、新規に定期問合せ管理テーブルに追加された問合せ管理情報についての残り時間情報のカウントダウン量についての誤差は許容する。また、初回のＳ９０１については、前回の電源オフ時前の最後の機会に取得した内部時計の値に基づいて、カウントダウン量を算出してもよいし、現在の内部時計の値を記憶するだけで、カウントダウンの処理を行わないようにしてもよい。
【０２０５】
Ｓ９０１での処理を終えると、制御部１１は、Ｓ９０２に移行し、定期問合せ管理テーブルから、処理対象の問合せ管理情報を、一つ選択する（Ｓ９０２）。処理対象の問合せ管理情報がない場合、即ち、後述するＳ９０４以降の処理の対象となっていない未処理の問合せ管理情報が存在しない場合には、Ｓ９０３でＮｏと判断して、Ｓ９１０に移行し、処理対象の問合せ管理情報（未処理の問合せ管理情報）がある場合には、Ｓ９０３でＹｅｓと判断して、Ｓ９０４に移行し、予め定められた問合せの実行猶予期間（最後の定期問合せ信号の送信時点から所定時間）が経過しているか否か判断する。
【０２０６】
Ｓ９０４で、実行猶予期間が経過していないと判断すると、制御部１１は、Ｓ９０５に移行し、上記選択した処理対象の問合せ管理情報が有する即時処理情報に基づいて、即時の問合せが必要であるか否かを判断する。ここで、即時の問合せが必要でないと判断すると、Ｓ９０２に移行し、即時の問合せが必要であると判断すると、Ｓ９０６に移行する。
【０２０７】
Ｓ９０６では、上記選択した処理対象の問合せ管理情報が有する残り時間情報に基づき、その問合せ管理情報に対応するリクエストサービスＩＤのサービスについて、定期問合せの送信時刻が到来しているか否か判断し、送信時刻が到来していないと判断すると、Ｓ９０２に移行する。尚、Ｓ９０６では、残り時間情報の値がゼロ又は負値である場合に、送信時刻が到来していると判断し、残り時間情報の値が正値である場合には、送信時刻が到来していないと判断する。
【０２０８】
Ｓ９０６で送信時刻が到来していると判断すると、制御部１１は、上記選択した処理対象の問合せ管理情報が有する利用デバイス情報に基づき、当該問合せ管理情報に対応するサービスを受ける際に利用する入出力デバイスが、並列動作している他のプロセスによって使用されているか否かを判断する（Ｓ９０７）。
【０２０９】
具体的に、ここでは、処理対象の問合せ管理情報が有する利用デバイス情報が「Ｐｒｉｎｔｅｒ」である場合、記録部１４が使用されているか否かを判断する。また、利用デバイス情報が「Ｓｃａｎｎｅｒ」である場合、読取部１３が使用されているか否かを判断する。その他、利用デバイス情報が「Ｓｐｅａｋｅｒ」である場合には、音出力部１８が使用されているか否か判断し、利用デバイス情報が「Ｍｉｃｒｏｐｈｏｎｅ」である場合には、音入力部１７が使用されているか否か判断する。
【０２１０】
また、利用デバイス情報に複数の入出力デバイスが示されている場合には、それら複数のデバイスが使用されているか否かを判断する。そして、複数のデバイスの一つでも使用されている場合には、当該問合せ管理情報に対応するサービスを受ける際に利用する入出力デバイスが使用されていると判断する。
【０２１１】
Ｓ９０７で入出力デバイスが使用されていると判断すると、制御部１１は、Ｓ９０２に移行し、使用されていないと判断すると、Ｓ９０８に移行し、統合問合せ情報生成処理を実行する。尚、図２１は、制御部１１が実行する統合問合せ情報生成処理を表すフローチャートであり、図２２は、統合問合せ情報の構成を表す説明図である。また、統合問合せ情報は、図２２に示すように、マークアップ言語によって記述されており、この統合問合せ情報で用いられる各タグの定義は表３に示すとおりである。
【０２１２】
【表３】
2006134109.tif 000005
【０２１３】
統合問合せ情報生成処理を実行すると、制御部１１は、まずＳ１００１にて、当該統合問合せ情報生成処理の実行が、Ｓ９０１の処理後、最初の実行であるか否か判断する。そして、最初の実行であると判断すると、Ｓ１０１１に移行し、統合問合せ情報を生成するための領域をＲＡＭに確保し、その領域（空の統合問合せ情報）に、ヘッダ情報を書き込む（Ｓ１０１２）。
【０２１４】
尚、本実施例では、統合問合せ情報を、ＨＴＴＰプロトコルにおけるＰＯＳＴコマンドで送信するため、ヘッダ情報には、その旨の情報や送信先のＵＲＬ情報等が書き込まれる。尚、統合問合せ情報の送信先は、予め決められており、ヘッダ情報には、その送信先のＵＲＬ情報が書き込まれる。
【０２１５】
Ｓ１０１２の処理後、制御部１１は、パラメータＮｕｍＰａｔｔｅｒｎの値を「１」として、ＮｕｍＰａｔｔｅｒｎタグ（文字列＜ＮｕｍＰａｔｔｅｒｎ＞１＜／ＮｕｍＰａｔｔｅｒｎ＞）を生成し、これを、統合問合せ情報（統合問合せ情報生成領域）に追加する（Ｓ１０１３）。また、Ｒｅｑｕｅｓｔ＿Ｓｅｒｖｉｃｅタグを統合問合せ情報に追加する（Ｓ１０１４）。
【０２１６】
その後、Ｒｅｑｕｅｓｔ＿Ｓｅｒｖｉｃｅタグの間（即ち、＜Ｒｅｑｕｅｓｔ＿Ｓｅｒｖｉｃｅ＞と＜／Ｒｅｑｕｅｓｔ＿Ｓｅｒｖｉｃｅ＞との間）に、処理対象の問合せ管理情報のリクエストステータス情報に基づいて、Ｒｅｑｕｅｓｔ＿Ｓｔａｔｕｓタグを書き込む（Ｓ１０１５）。
【０２１７】
例えば、リクエストステータス情報の値が「ＦＡＬＳＥ」である場合には、パラメータＲｅｑｕｅｓｔ＿Ｓｔａｔｕｓの値を「ＦＡＬＳＥ」として、Ｒｅｑｕｅｓｔ＿Ｓｔａｔｕｓタグ（文字列＜Ｒｅｑｕｅｓｔ＿Ｓｔａｔｕｓ＞ＦＡＬＳＥ＜／Ｒｅｑｕｅｓｔ＿Ｓｔａｔｕｓ＞）を生成し、これを統合問合せ情報に書き込む。
【０２１８】
また、Ｓ１０１５の処理を終えると、パラメータＮｕｍ＿Ｓｅｒｖｉｃｅ＿ＩＤの値を「１」として、Ｎｕｍ＿Ｓｅｒｖｉｃｅ＿ＩＤタグ（文字列＜Ｎｕｍ＿Ｓｅｒｖｉｃｅ＿ＩＤ＞１＜／Ｎｕｍ＿Ｓｅｒｖｉｃｅ＿ＩＤ＞）を生成し、これを統合問合せ情報におけるＲｅｑｕｅｓｔ＿Ｓｅｒｖｉｃｅタグの間に書き込む（Ｓ１０１６）。
【０２１９】
また、Ｓ１０１６の処理を終えると、処理対象の問合せ管理情報が示すリクエストサービスＩＤの値を、パラメータＲｅｑｕｅｓｔ＿Ｓｅｒｖｉｃｅ＿ＩＤの値として、Ｒｅｑｕｅｓｔ＿Ｓｅｒｖｉｃｅ＿ＩＤタグ（文字列＜Ｒｅｑｕｅｓｔ＿Ｓｅｒｖｉｃｅ＿ＩＤ＞（リクエストサービスＩＤ）＜／Ｒｅｑｕｅｓｔ＿Ｓｅｒｖｉｃｅ＿ＩＤ＞）を生成し、これを統合問合せ情報におけるＲｅｑｕｅｓｔ＿Ｓｅｒｖｉｃｅタグの間に書き込む（Ｓ１０１７）。その後、当該統合問合せ情報生成処理を終了する。
【０２２０】
一方、Ｓ１００１にて、当該統合問合せ情報生成処理の実行が、Ｓ９０１の処理後、初回ではなく二回目以降の実行であると判断すると、制御部１１は、Ｓ１０２１に移行し、同じパラメータ値のタグがあるか否かを判断する。即ち、当該処理対象の問合せ管理情報が有するリクエストステータス情報の値と、同一の値を示すＲｅｑｕｅｓｔ＿Ｓｔａｔｕｓタグが、統合問合せ情報に既に書き込まれているか否か判断する。
【０２２１】
Ｓ１０２１で、同じパラメータ値（Ｒｅｑｕｅｓｔ＿Ｓｔａｔｕｓ）のタグがあると判断すると、制御部１１は、そのタグと、同一のＲｅｑｕｅｓｔ＿Ｓｅｒｖｉｃｅタグの間にあるＮｕｍ＿Ｓｅｒｖｉｃｅ＿ＩＤタグの値を更新する（Ｓ１０２２）。例えば、統合問合せ情報における更新前のＮｕｍ＿Ｓｅｒｖｉｃｅ＿ＩＤタグが、文字列＜Ｎｕｍ＿Ｓｅｒｖｉｃｅ＿ＩＤ＞１＜／Ｎｕｍ＿Ｓｅｒｖｉｃｅ＿ＩＤ＞である場合には、これを＜Ｎｕｍ＿Ｓｅｒｖｉｃｅ＿ＩＤ＞２＜／Ｎｕｍ＿Ｓｅｒｖｉｃｅ＿ＩＤ＞に更新する。
【０２２２】
Ｓ１０２２の処理を終えると、制御部１１は、処理対象の問合せ管理情報が示すリクエストサービスＩＤの値を、パラメータＲｅｑｕｅｓｔ＿Ｓｅｒｖｉｃｅ＿ＩＤの値として、Ｒｅｑｕｅｓｔ＿Ｓｅｒｖｉｃｅ＿ＩＤタグを生成し、これを統合問合せ情報におけるＲｅｑｕｅｓｔ＿Ｓｅｒｖｉｃｅタグの間に書き込む（Ｓ１０２３）。その後、当該統合問合せ情報生成処理を終了する。
【０２２３】
また、Ｓ１０２１で、同じパラメータ値（Ｒｅｑｕｅｓｔ＿Ｓｔａｔｕｓ）のタグがないと判断すると、制御部１１は、Ｓ１０３１に移行し、統合問合せ情報のＮｕｍＰａｔｔｅｒｎタグにおけるパラメータＮｕｍＰａｔｔｅｒｎの値を更新する。即ち、統合問合せ情報のＮｕｍＰａｔｔｅｒｎタグが文字列＜ＮｕｍＰａｔｔｅｒｎ＞１＜／ＮｕｍＰａｔｔｅｒｎ＞である場合には、これを、文字列＜ＮｕｍＰａｔｔｅｒｎ＞２＜／ＮｕｍＰａｔｔｅｒｎ＞に更新する。
【０２２４】
Ｓ１０３１の処理を終えると、制御部１１は、Ｓ１０３２に移行し、既に統合問合せ情報に書き込まれているＲｅｑｕｅｓｔ＿Ｓｅｒｖｉｃｅタグに続く領域に、新しいＲｅｑｕｅｓｔ＿Ｓｅｒｖｉｃｅタグを書き込み、その新しいＲｅｑｕｅｓｔ＿Ｓｅｒｖｉｃｅタグの間に、処理対象の問合せ管理情報が有するリクエストステータス情報の値に基づくＲｅｑｕｅｓｔ＿Ｓｔａｔｕｓタグを書き込む（Ｓ１０３３）。
【０２２５】
例えば、リクエストステータス情報の値が「ＴＲＵＥ」である場合には、パラメータＲｅｑｕｅｓｔ＿Ｓｔａｔｕｓの値を「ＴＲＵＥ」として、Ｒｅｑｕｅｓｔ＿Ｓｔａｔｕｓタグ（文字列＜Ｒｅｑｕｅｓｔ＿Ｓｔａｔｕｓ＞ＴＲＵＥ＜／Ｒｅｑｕｅｓｔ＿Ｓｔａｔｕｓ＞）を生成し、これを統合問合せ情報に書き込む。
【０２２６】
Ｓ１０３３の処理を終えると、制御部１１は、パラメータＮｕｍ＿Ｓｅｒｖｉｃｅ＿ＩＤの値を「１」として、Ｎｕｍ＿Ｓｅｒｖｉｃｅ＿ＩＤタグ（文字列＜Ｎｕｍ＿Ｓｅｒｖｉｃｅ＿ＩＤ＞１＜／Ｎｕｍ＿Ｓｅｒｖｉｃｅ＿ＩＤ＞）を生成し、これを統合問合せ情報における上記新しいＲｅｑｕｅｓｔ＿Ｓｅｒｖｉｃｅタグの間に書き込む（Ｓ１０３４）。
【０２２７】
また、Ｓ１０３４の処理を終えると、処理対象の問合せ管理情報が示すリクエストサービスＩＤの値を、パラメータＲｅｑｕｅｓｔ＿Ｓｅｒｖｉｃｅ＿ＩＤの値として、Ｒｅｑｕｅｓｔ＿Ｓｅｒｖｉｃｅ＿ＩＤタグを生成し、これを統合問合せ情報における上記新しいＲｅｑｕｅｓｔ＿Ｓｅｒｖｉｃｅタグの間に書き込む（Ｓ１０３５）。その後、当該統合問合せ情報生成処理を終了し、Ｓ９０２（図２０参照）に移行する。
【０２２８】
また、Ｓ９０２の処理後、Ｓ９０３で処理対象の問合せ管理情報がないと判断すると（即ち、Ｓ９０４以降の処理を、定期問合せ管理テーブルに記載された全ての問合せ管理情報に対して実行したと判断すると）、制御部１１は、Ｓ９１０に移行し、統合問合せ情報が生成されているか否かを判断する。そして、統合問合せ情報が生成されていると判断すると、ＲＡＭの統合問合せ情報生成領域に格納されている統合問合せ情報を格納した定期問合せ信号を生成し、これを通信部１５を通じて、問合せ先の機能サーバ３０に送信する（Ｓ９１１）。その後、Ｓ９０１に移行する。
【０２２９】
一方、Ｓ９１０で統合問合せ情報が生成されていない（Ｓ９０８を実行していない）と判断すると、制御部１１は、Ｓ９１１の処理を実行することなく、Ｓ９０１に移行して、再び、残り時間のカウントダウンを行う。
【０２３０】
続いて、Ｓ９１１で複合機１０から送信される定期問合せ信号を受ける機能サーバ３０側の定期問合せ応答処理について説明する。図２３は、機能サーバ３０の制御部３１が実行する定期問合せ応答処理を表すフローチャートである。この定期問合せ応答処理は、機能サーバ３０の動作中、継続して行われる。
【０２３１】
問合せ応答処理を実行すると、制御部３１は、通信部３２を介して、複合機１０から定期問合せ信号を受信するまで待機し（Ｓ１１０１）、定期問合せ信号を受信すると、その定期問合せ信号に含まれる統合問合せ情報の中から、処理対象のリクエストサービスＩＤを一つ選択する（Ｓ１１０２）。
【０２３２】
ここで、処理対象のリクエストサービスＩＤがない場合、即ち、後述するＳ１１０４以降の処理対象となっていない未処理のリクエストサービスＩＤが存在しない場合には、Ｓ１１０３でＮｏと判断して、Ｓ１１３０に移行し、処理対象（未処理）のリクエストサービスＩＤがある場合には、Ｓ１１０３でＹｅｓと判断してＳ１１０４に移行し、そのリクエストサービスＩＤについての返答を表す定期問合せ返信情報を生成するための定期問合せ返信情報生成領域を、ＲＡＭに確保し、その領域に、パラメータＲｅｑｕｅｓｔ＿Ｓｅｒｖｉｃｅ＿ＩＤの値として、上記処理対象のリクエストサービスＩＤを書き込む。
【０２３３】
その後、処理対象のリクエストサービスＩＤに対応する返信管理情報を、記憶部３３に格納された定期問合せ返信管理テーブル内で検索し（Ｓ１１０５）、検索できなかった場合には、定期問合せ返信管理テーブルに、処理対象のリクエストサービスＩＤに対する返信管理情報が登録されていないと判断して（Ｓ１１０６でＮｏ）、Ｓ１１０７に移行し、上記定期問合せ返信情報生成領域に、パラメータＳｅｒｖｉｃｅ＿Ｃａｎｃｅｌｅｄの値として、「ＴＲＵＥ」を書き込むと共に、パラメータＳｅｒｖｉｃｅ＿Ｓｔａｒｔの値として、「ＦＡＬＳＥ」を書き込む。
【０２３４】
Ｓ１１０７での処理を終えると、制御部３１は、Ｓ１１０８に移行し、上記定期問合せ返信情報生成領域に、パラメータＳｅｒｖｉｃｅ＿Ｓｔａｔｕｓの値として、「−４」を書き込む。その後、Ｓ１１２０に移行して、図２５に示す統合返信情報生成処理を実行する。尚、表４は、パラメータＳｅｒｖｉｃｅ＿Ｓｔａｔｕｓのとりえる値を表したものである。
【０２３５】
【表４】
2006134109.tif 000006
【０２３６】
これに対し、Ｓ１１０５にて、処理対象のリクエストサービスＩＤに対応する返信管理情報を、記憶部３３に格納された定期問合せ返信管理テーブルにて特定（検索）することができると、制御部３１は、Ｓ１１０６でＹｅｓと判断し、Ｓ１１０９に移行して、定期問合せ返信管理テーブルの当該処理対象のリクエストサービスＩＤに対応する問合せ日時情報を、Ｓ１１０１で上記定期問合せ信号を受信した時刻（日時）に更新する。その後、制御部３１は、上記定期問合せ返信情報生成領域に、パラメータＳｅｒｖｉｃｅ＿Ｓｔａｒｔの値として、当該処理対象のリクエストサービスＩＤに対応する返信管理情報が有するサービススタート情報の値を、書き込む（Ｓ１１１０）。
【０２３７】
Ｓ１１１０の処理を終えると、制御部３１は、Ｓ１１１１に移行し、上記定期問合せ返信情報生成領域に、パラメータＳｅｒｖｉｃｅ＿Ｃａｎｃｅｌｅｄの値として、当該処理対象のリクエストサービスＩＤに対応する返信管理情報が有するサービスキャンセル情報の値を、書き込む。
【０２３８】
Ｓ１１１１の処理を終えると、制御部３１は、Ｓ１１１２に移行し、上記定期問合せ返信情報生成領域に書き込んだパラメータＳｅｒｖｉｃｅ＿Ｓｔａｒｔの値が「ＴＲＵＥ」であるか否か判断し、「ＴＲＵＥ」であると判断すると、Ｓ１１１３に移行して、図２４に示すパラメータチェック処理を実行する。尚、図２４は、制御部３１が実行するパラメータチェック処理を表すフローチャートである。
【０２３９】
パラメータチェック処理を実行すると、制御部３１は、まずＳ１１５０にて、処理対象のリクエストサービスＩＤに対応するサービスが、有料サービスであるか否か判断し、有料サービスではないと判断すると、Ｓ１１５８に移行して、「パラメータＯＫ」と判断し、当該パラメータチェック処理を終了する。一方、Ｓ１１５０にて有料サービスであると判断すると、Ｓ１１５１に移行し、リクエストサービスＩＤ管理テーブルが記憶する処理対象のリクエストサービスＩＤのパラメータ情報に基づき、そのパラメータ情報が示すプリペイドカード番号（パラメータＰｒｅｐａｉｄの値）が、有効なプリペイドカード番号であるか否か判断する。
【０２４０】
Ｓ１１５１で有効なプリペイドカード番号であると判断すると、制御部３１は、Ｓ１１５８に移行し、「パラメータＯＫ」と判断して、当該パラメータチェック処理を終了する。一方、Ｓ１１５１で有効なプリペイドカード番号ではないと判断すると、制御部３１は、Ｓ１１５２に移行し、上記定期問合せ返信情報生成領域が記憶するパラメータＳｅｒｖｉｃｅ＿Ｃａｎｃｅｌｅｄの値を、「ＴＲＵＥ」に更新する。
【０２４１】
その後、制御部３１は、Ｓ１１５３に移行し、再度の利用登録を拒否するか否か判断し、利用登録を拒否しないと判断すると、Ｓ１１５４にて、上記定期問合せ返信情報生成領域に、パラメータＳｅｒｖｉｃｅ＿Ｓｔａｔｕｓの値として、「−２」を書き込み、Ｓ１１５６に移行する。一方、Ｓ１１５３で利用登録を拒否すると判断すると、制御部３１は、Ｓ１１５５に移行して、上記定期問合せ返信情報生成領域に、パラメータＳｅｒｖｉｃｅ＿Ｓｔａｔｕｓの値として、「−１」を書き込み、その後、Ｓ１１５６に移行する。
【０２４２】
尚、再度の利用登録を拒否するか否かは、プリペイドカード番号が無効である原因に応じて判断する。即ち、プリペイドカード番号が、不正利用されているプリペイドカード番号である場合には、再度の利用登録を拒否すると判断し、プリペイドカード番号が、不正利用されているプリペイドカード番号ではなく単にポイント切れによって無効にされたプリペイドカード番号である場合には、利用登録を拒否しないと判断する。
【０２４３】
Ｓ１１５６に移行すると、制御部３１は、上記定期問合せ返信情報生成領域に記憶されているパラメータＳｅｒｖｉｃｅ＿Ｓｔａｒｔの値を、「ＦＡＬＳＥ」に更新し、その後、Ｓ１１５７で「パラメータＮＧ」と判断して、パラメータチェック処理を終了する。
【０２４４】
上記パラメータチェック処理を終了すると、制御部３１は、Ｓ１１１４に移行し、パラメータチェック処理にて「パラメータＯＫ」との判断が下されているか否か判断し、「パラメータＯＫ」との判断が下されていると判断すると、上記定期問合せ返信情報生成領域に、パラメータＳｅｒｖｉｃｅ＿ＵＲＬの値として、当該処理対象のリクエストサービスＩＤに対応する返信管理情報が有するサービスＵＲＬ情報の値（文字列）を書き込む（Ｓ１１１５）。その後、Ｓ１１１７に移行する。
【０２４５】
一方、パラメータチェック処理で「パラメータＯＫ」との判断が下されていない（換言すると、「パラメータＮＧ」との判断が下されている）と判断すると（Ｓ１１１４でＮｏ）、制御部３１は、Ｓ１１１６に移行し、定期問合せ返信管理テーブルから、処理対象のリクエストサービスＩＤについての返信管理情報を削除すると共に、リクエストサービスＩＤ管理テーブルから、処理対象のリクエストサービスＩＤについてのパラメータ情報を削除する。その後、Ｓ１１２０に移行する。
【０２４６】
これに対し、Ｓ１１１２で上記定期問合せ返信情報生成領域に記憶されているパラメータＳｅｒｖｉｃｅ＿Ｓｔａｒｔの値が「ＴＲＵＥ」ではない（「ＦＡＬＳＥ」である）と判断すると、制御部３１は、Ｓ１１１３〜Ｓ１１１５の処理を実行することなく、Ｓ１１１７に移行する。
【０２４７】
Ｓ１１１７に移行すると、制御部３１は、統合問合せ情報における上記処理対象のリクエストサービスＩＤに関連付けられたＲｅｑｕｅｓｔ＿Ｓｔａｔｕｓタグ（処理対象のリクエストサービスＩＤが記述されたＲｅｑｕｅｓｔ＿Ｓｅｒｖｉｃｅタグの間にあるＲｅｑｕｅｓｔ＿Ｓｔａｔｕｓタグ）の値が「ＴＲＵＥ」であるか否か判断し、「ＴＲＵＥ」であると判断すると、Ｓ１１１８に移行して、上記定期問合せ返信情報生成領域に、パラメータＳｅｒｖｉｃｅ＿Ｓｔａｔｕｓの値として、当該処理対象のリクエストサービスＩＤに対応する返信管理情報が有するサービスステータス情報の値を書き込む。その後、Ｓ１１１９に移行する。
【０２４８】
一方、Ｓ１１１７にて、統合問合せ情報における上記処理対象のリクエストサービスＩＤに関連付けられたＲｅｑｕｅｓｔ＿Ｓｔａｔｕｓタグの値が「ＴＲＵＥ」ではない（「ＦＡＬＳＥ」である）と判断すると、Ｓ１１１８の処理を実行せずに、Ｓ１１１９に移行する。
【０２４９】
Ｓ１１１９に移行すると、制御部３１は、当該処理対象のリクエストサービスＩＤに対応する返信管理情報が有するサービスキャンセル情報の値が「ＴＲＵＥ」であるか否か判断し、「ＴＲＵＥ」であると判断すると、Ｓ１１１６に移行して、上述の削除処理を行った後に、Ｓ１１２０に移行する。一方、サービスキャンセル情報の値が「ＴＲＵＥ」ではない（「ＦＡＬＳＥ」である）と判断すると、Ｓ１１１６に移行することなく（即ち、上述の削除処理を行うことなく）、Ｓ１１２０に移行する。
【０２５０】
Ｓ１１２０に移行すると、制御部３１は、統合返信情報生成処理を実行する。図２５は、制御部３１が実行する統合返信情報生成処理を表すフローチャートであり、図２６は、統合返信情報生成処理で実行される返信判断処理を表すフローチャートである。また、図２７は、統合返信情報の構成を表す説明図である。その他、統合返信情報は、図２７に示すように、マークアップ言語によって記述されており、この統合返信情報で用いられる各タグの定義は表５に示すとおりである。
【０２５１】
【表５】
2006134109.tif 000007
【０２５２】
統合返信情報生成処理を実行すると、制御部３１は、まずＳ１２０１にて、当該統合返信情報生成処理の実行が、Ｓ１１０１にて定期問合せ信号を受信した後、最初の実行であるか否かを判断する。そして、最初の実行であると判断すると、Ｓ１２１１に移行し、統合返信情報を生成するための統合返信情報生成領域をＲＡＭに確保し、その領域（空の統合返信情報）に、ヘッダ情報を書き込む（Ｓ１２１２）。
【０２５３】
Ｓ１２１２の処理後、制御部３１は、パラメータＮｕｍＰａｔｔｅｒｎの値を「１」として、ＮｕｍＰａｔｔｅｒｎタグ（文字列＜ＮｕｍＰａｔｔｅｒｎ＞１＜／ＮｕｍＰａｔｔｅｒｎ＞）を生成し、これを、統合返信情報（統合返信情報生成領域）に追加する（Ｓ１２１３）。また、Ｒｅｓｐｏｎｃｅ＿Ｓｅｒｖｉｃｅタグを統合返信情報に追加する（Ｓ１２１４）。その後、返信判断処理（図２６）を実行する。
【０２５４】
返信判断処理を実行すると、制御部３１は、Ｓ１３０１にて、処理対象のリクエストサービスＩＤに対応する定期問合せ返信情報（定期問合せ返信情報生成領域に書き込まれた情報）が示すパラメータＳｅｒｖｉｃｅ＿Ｓｔａｒｔの値が「ＴＲＵＥ」であるか否かを判断し、「ＴＲＵＥ」であると判断すると、返信ＯＫと判断する（Ｓ１３０４）。
【０２５５】
一方、Ｓ１３０１で「ＴＲＵＥ」ではないと判断すると、制御部３１は、Ｓ１３０２に移行し、上記定期問合せ返信情報が示すパラメータＳｅｒｖｉｃｅ＿Ｃａｎｃｅｌｅｄの値が「ＴＲＵＥ」であるか否かを判断する。
【０２５６】
そして、パラメータＳｅｒｖｉｃｅ＿Ｃａｎｃｅｌｅｄの値が「ＴＲＵＥ」であると判断すると、制御部３１は、Ｓ１３０４に移行して、返信ＯＫと判断する。これに対し、パラメータＳｅｒｖｉｃｅ＿Ｃａｎｃｅｌｅｄの値が「ＴＲＵＥ」ではないと判断すると、制御部３１は、Ｓ１３０３にて、上記定期問合せ返信情報に、パラメータＳｅｒｖｉｃｅ＿Ｓｔａｔｕｓの値が存在するか否か判断する。そして、存在すると判断すると、Ｓ１３０４に移行して、返信ＯＫと判断する。一方、Ｓ１３０３で存在しないと判断すると、Ｓ１３０５に移行して、返信ＮＧと判断する。その後、当該返信判断処理を終了する。
【０２５７】
Ｓ１２１５での返信判断処理を終了すると、制御部３１は、Ｓ１２１６にて、返信判断処理での判断が、返信ＯＫとの判断であるか否かを判断する。そして、返信ＯＫではない（返信ＮＧである）と判断すると、当該統合返信情報生成処理を終了する。一方、返信ＯＫであると判断すると、Ｓ１２１７に移行する。
【０２５８】
Ｓ１２１７に移行すると、制御部３１は、処理対象のリクエストサービスＩＤに対応する定期問合せ返信情報（定期問合せ返信情報生成領域に書き込まれた情報）に基づいて、Ｒｅｓｐｏｎｃｅ＿Ｓｅｒｖｉｃｅタグの間（即ち、＜Ｒｅｓｐｏｎｃｅ＿Ｓｅｒｖｉｃｅ＞と＜／Ｒｅｓｐｏｎｃｅ＿Ｓｅｒｖｉｃｅ＞との間）に、Ｓｅｒｖｉｃｅ＿Ｓｔａｒｔタグを書き込む。
【０２５９】
例えば、定期問合せ返信情報におけるパラメータＳｅｒｖｉｃｅ＿Ｓｔａｒｔの値が「ＴＲＵＥ」である場合、Ｓｅｒｖｉｃｅ＿Ｓｔａｒｔタグとして、文字列＜Ｓｅｒｖｉｃｅ＿Ｓｔａｒｔ＞ＴＲＵＥ＜／Ｓｅｒｖｉｃｅ＿Ｓｔａｒｔ＞）を生成し、これを統合返信情報に書き込む。
【０２６０】
また、Ｓ１２１７の処理を終えると、制御部３１は、処理対象のリクエストサービスＩＤに対応する定期問合せ返信情報に基づいて、Ｒｅｓｐｏｎｃｅ＿Ｓｅｒｖｉｃｅタグの間に、Ｓｅｒｖｉｃｅ＿ＵＲＬタグを書き込む（Ｓ１２１８）。尚、定期問合せ返信情報に、パラメータＳｅｒｖｉｃｅ＿ＵＲＬの値が存在しない場合には、Ｓｅｒｖｉｃｅ＿ＵＲＬタグとして、文字列＜Ｓｅｒｖｉｃｅ＿ＵＲＬ＞＜／Ｓｅｒｖｉｃｅ＿ＵＲＬ＞を生成し、パラメータＳｅｒｖｉｃｅ＿ＵＲＬの値が存在する場合には、その値を記述したＳｅｒｖｉｃｅ＿ＵＲＬタグを生成して、統合返信情報に書き込む。
【０２６１】
Ｓ１２１８の処理を終えると、制御部３１は、処理対象のリクエストサービスＩＤに対応する定期問合せ返信情報に基づいて、Ｒｅｓｐｏｎｃｅ＿Ｓｅｒｖｉｃｅタグの間に、Ｓｅｒｖｉｃｅ＿Ｓｔａｔｕｓタグを書き込む（Ｓ１２１９）。
【０２６２】
この際、定期問合せ返信情報に、パラメータＳｅｒｖｉｃｅ＿Ｓｔａｔｕｓの値が存在しない場合には、Ｓｅｒｖｉｃｅ＿Ｓｔａｔｕｓタグとして、文字列＜Ｓｅｒｖｉｃｅ＿Ｓｔａｔｕｓ＞＜／Ｓｅｒｖｉｃｅ＿Ｓｔａｔｕｓ＞を生成し、パラメータＳｅｒｖｉｃｅ＿Ｓｔａｔｕｓの値が存在する場合には、その値を記述したＳｅｒｖｉｃｅ＿Ｓｔａｔｕｓタグを生成し、これを統合返信情報に書き込む。
【０２６３】
また、Ｓ１２１９の処理を終えると、制御部３１は、処理対象のリクエストサービスＩＤに対応する定期問合せ返信情報に基づいて、Ｒｅｓｐｏｎｃｅ＿Ｓｅｒｖｉｃｅタグの間に、Ｓｅｒｖｉｃｅ＿Ｃａｎｃｅｌｅｄタグを書き込む（Ｓ１２２０）。
【０２６４】
例えば、定期問合せ返信情報におけるパラメータＳｅｒｖｉｃｅ＿Ｃａｎｃｅｌｅｄの値が「ＦＡＬＳＥ」である場合、Ｓｅｒｖｉｃｅ＿Ｃａｎｃｅｌｅｄタグとして、文字列＜Ｓｅｒｖｉｃｅ＿Ｃａｎｃｅｌｅｄ＞ＦＡＬＳＥ＜／Ｓｅｒｖｉｃｅ＿Ｃａｎｃｅｌｅｄ＞）を生成し、これを統合返信情報に書き込む。
【０２６５】
Ｓ１２２０の処理を終えると、制御部３１は、パラメータＮｕｍ＿Ｓｅｒｖｉｃｅ＿ＩＤの値を「１」として、Ｎｕｍ＿Ｓｅｒｖｉｃｅ＿ＩＤタグ（文字列＜Ｎｕｍ＿Ｓｅｒｖｉｃｅ＿ＩＤ＞１＜／Ｎｕｍ＿Ｓｅｒｖｉｃｅ＿ＩＤ＞）を生成し、これを統合返信情報におけるＲｅｓｐｏｎｃｅ＿Ｓｅｒｖｉｃｅタグの間に書き込む（Ｓ１２２１）。
【０２６６】
そして、Ｓ１２２１の処理を終えるとＳ１２２２に移行し、処理対象のリクエストサービスＩＤの値を、パラメータＲｅｑｕｅｓｔ＿Ｓｅｒｖｉｃｅ＿ＩＤの値として、Ｒｅｑｕｅｓｔ＿Ｓｅｒｖｉｃｅ＿ＩＤタグ（文字列＜Ｒｅｑｕｅｓｔ＿Ｓｅｒｖｉｃｅ＿ＩＤ＞（リクエストサービスＩＤ）＜／Ｒｅｑｕｅｓｔ＿Ｓｅｒｖｉｃｅ＿ＩＤ＞）を生成し、これを統合返信情報におけるＲｅｓｐｏｎｃｅ＿Ｓｅｒｖｉｃｅタグの間に書き込む。その後、当該統合返信情報生成処理を終了する。
【０２６７】
一方、Ｓ１２０１にて、当該統合返信情報生成処理の実行が、Ｓ１１０１の処理後、初回ではなく二回目以降の実行であると判断すると、制御部３１は、Ｓ１２２５で返信判断処理（図２６）を実行し、Ｓ１２２６で、返信判断処理の判断結果が返信ＯＫであるか否かを判断する。そして、返信ＯＫではない（返信ＮＧである）と判断すると、当該統合返信処理を終了する。
【０２６８】
これに対し、Ｓ１２２６で、返信ＯＫであると判断すると、制御部３１は、Ｓ１２２７に移行し、当該処理対象のリクエストサービスＩＤの定期問合せ返信情報と同じパラメータ値のＲｅｓｐｏｎｃｅ＿Ｓｅｒｖｉｃｅタグがあるか否か判断する。即ち、当該処理対象のリクエストサービスＩＤの定期問合せ返信情報が有するリクエストサービスＩＤ以外の情報（パラメータＳｅｒｖｉｃｅ＿Ｓｔａｒｔ，Ｓｅｒｖｉｃｅ＿ＵＲＬ，Ｓｅｒｖｉｃｅ＿Ｓｔａｔｕｓ，Ｓｅｒｖｉｃｅ＿Ｃａｎｃｅｌｅｄの値）が同一であるＲｅｓｐｏｎｃｅ＿Ｓｅｒｖｉｃｅタグが存在するか否か判断する。
【０２６９】
そして、同じパラメータ値のＲｅｓｐｏｎｃｅ＿Ｓｅｒｖｉｃｅタグがあると判断すると、制御部３１は、そのＲｅｓｐｏｎｃｅ＿Ｓｅｒｖｉｃｅタグの間にあるＮｕｍ＿Ｓｅｒｖｉｃｅ＿ＩＤタグの値を更新する（Ｓ１２２８）。例えば、統合返信情報における更新前のＮｕｍ＿Ｓｅｒｖｉｃｅ＿ＩＤタグが、文字列＜Ｎｕｍ＿Ｓｅｒｖｉｃｅ＿ＩＤ＞１＜／Ｎｕｍ＿Ｓｅｒｖｉｃｅ＿ＩＤ＞である場合には、これを＜Ｎｕｍ＿Ｓｅｒｖｉｃｅ＿ＩＤ＞２＜／Ｎｕｍ＿Ｓｅｒｖｉｃｅ＿ＩＤ＞に更新する。
【０２７０】
Ｓ１２２８の処理を終えると、制御部３１は、処理対象のリクエストサービスＩＤの値を、パラメータＲｅｑｕｅｓｔ＿Ｓｅｒｖｉｃｅ＿ＩＤの値として、Ｒｅｑｕｅｓｔ＿Ｓｅｒｖｉｃｅ＿ＩＤタグを生成し、これを統合返信情報における上記パラメータ値が同一であるＲｅｓｐｏｎｃｅ＿Ｓｅｒｖｉｃｅタグの間に書き込む（Ｓ１２２９）。その後、当該統合返信情報生成処理を終了する。
【０２７１】
また、Ｓ１２２７で、同じパラメータ値のＲｅｓｐｏｎｃｅ＿Ｓｅｒｖｉｃｅタグがないと判断すると、制御部３１は、Ｓ１２３１に移行し、統合返信情報のＮｕｍＰａｔｔｅｒｎタグにおけるパラメータＮｕｍＰａｔｔｅｒｎの値を更新する。例えば、統合返信情報のＮｕｍＰａｔｔｅｒｎタグが文字列＜ＮｕｍＰａｔｔｅｒｎ＞１＜／ＮｕｍＰａｔｔｅｒｎ＞である場合には、これを、文字列＜ＮｕｍＰａｔｔｅｒｎ＞２＜／ＮｕｍＰａｔｔｅｒｎ＞に更新する。
【０２７２】
但し、Ｓ１２３１の実行時において、統合返信情報に、空のＲｅｓｐｏｎｃｅ＿Ｓｅｒｖｉｃｅタグがある場合（具体的には、Ｓ１２１６でＮｏと判断した後の、最初のＳ１２３１実行時）には、例外的に、パラメータＮｕｍＰａｔｔｅｒｎの値を更新しないこととする。
【０２７３】
Ｓ１２３１の処理を終えると、制御部３１は、Ｓ１２３２に移行し、既に統合返信情報に存在するＲｅｓｐｏｎｃｅ＿Ｓｅｒｖｉｃｅタグに続く領域に、新しいＲｅｓｐｏｎｃｅ＿Ｓｅｒｖｉｃｅタグを書き込む。但し、Ｓ１２３２の実行時において、統合返信情報に、空のＲｅｓｐｏｎｃｅ＿Ｓｅｒｖｉｃｅタグがある場合には、例外的に、新しいＲｅｓｐｏｎｃｅ＿Ｓｅｒｖｉｃｅタグの書込を実行しないこととする。
【０２７４】
Ｓ１２３２の処理を終えると、制御部３１は、Ｓ１２３３に移行し、処理対象のリクエストサービスＩＤに対応する定期問合せ返信情報に基づいて、新しいＲｅｓｐｏｎｃｅ＿Ｓｅｒｖｉｃｅタグ（空のＲｅｓｐｏｎｃｅ＿Ｓｅｒｖｉｃｅタグ）の間に、Ｓｅｒｖｉｃｅ＿Ｓｔａｒｔタグを書き込む。
【０２７５】
例えば、定期問合せ返信情報におけるパラメータＳｅｒｖｉｃｅ＿Ｓｔａｒｔの値が「ＦＡＬＳＥ」である場合、Ｓｅｒｖｉｃｅ＿Ｓｔａｒｔタグとして、文字列＜Ｓｅｒｖｉｃｅ＿Ｓｔａｒｔ＞ＦＡＬＳＥ＜／Ｓｅｒｖｉｃｅ＿Ｓｔａｒｔ＞）を生成し、これを統合返信情報に書き込む。
【０２７６】
また、Ｓ１２３３の処理を終えると、制御部３１は、処理対象のリクエストサービスＩＤに対応する定期問合せ返信情報に基づいて、上記Ｒｅｓｐｏｎｃｅ＿Ｓｅｒｖｉｃｅタグの間に、Ｓｅｒｖｉｃｅ＿ＵＲＬタグを書き込む（Ｓ１２３４）。また、処理対象のリクエストサービスＩＤに対応する定期問合せ返信情報に基づき、上記Ｒｅｓｐｏｎｃｅ＿Ｓｅｒｖｉｃｅタグの間に、Ｓｅｒｖｉｃｅ＿Ｓｔａｔｕｓタグを書き込む（Ｓ１２３５）。
【０２７７】
そして、Ｓ１２３５の処理を終えると、制御部３１は、処理対象のリクエストサービスＩＤに対応する定期問合せ返信情報に基づいて、Ｒｅｓｐｏｎｃｅ＿Ｓｅｒｖｉｃｅタグの間に、Ｓｅｒｖｉｃｅ＿Ｃａｎｃｅｌｅｄタグを書き込む（Ｓ１２３６）。この後、パラメータＮｕｍ＿Ｓｅｒｖｉｃｅ＿ＩＤの値を「１」として、Ｎｕｍ＿Ｓｅｒｖｉｃｅ＿ＩＤタグを生成し、これを統合返信情報における上記Ｒｅｓｐｏｎｃｅ＿Ｓｅｒｖｉｃｅタグの間に書き込む（Ｓ１２３７）。
【０２７８】
Ｓ１２３７の処理を終えると、制御部３１は、処理対象のリクエストサービスＩＤの値を、パラメータＲｅｑｕｅｓｔ＿Ｓｅｒｖｉｃｅ＿ＩＤの値として、Ｒｅｑｕｅｓｔ＿Ｓｅｒｖｉｃｅ＿ＩＤタグを生成し、これを統合返信情報における上記Ｒｅｓｐｏｎｃｅ＿Ｓｅｒｖｉｃｅタグの間に書き込む（Ｓ１２３８）。その後、当該統合返信情報生成処理を終了する。
【０２７９】
このようにしてＳ１１２０（図２３）で統合返信情報生成処理を実行すると、制御部３１は、Ｓ１１０２に移行して、統合問合せ情報の中から、次の処理対象（未処理のリクエストサービスＩＤ）を一つ選択する。ここで、未処理のリクエストサービスＩＤが存在しないと、制御部３１は、Ｓ１１３０に移行して、統合返信情報生成領域に記憶されている統合返信情報を格納した応答信号を生成し、これを、通信部３２を介して、定期問合せ信号送信元（問合せ元）の複合機１０に送信する。その後、Ｓ１１０１に移行して、次の定期問合せ信号を受信するまで待機する。
【０２８０】
次に、ブログ検索サービスとして、利用登録された複合機１０に対し提供する情報を生成するブログ検索処理について説明する。図２８は、機能サーバ３０の制御部３１が実行するブログ検索処理を表すフローチャートである。このブログ検索処理は、機能サーバ３０の動作中、所定期間毎に、繰返し実行される。
【０２８１】
ブログ検索処理を実行すると、制御部３１は、まずＳ１４０１にて、ブログ検索サービスに対応するリクエストサービスＩＤ管理テーブルから、処理対象のリクエストサービスＩＤを、一つ選択する。ここで、上記リクエストサービスＩＤ管理テーブルにおいて処理対象のリクエストサービスＩＤが存在しない、即ち、Ｓ１４０３以降の処理対象となっていない未処理のリクエストサービスＩＤが存在しない場合には、Ｓ１４０２でＮｏと判断して、当該ブログ検索処理を終了する。
【０２８２】
一方、処理対象（未処理）のリクエストサービスＩＤが存在すると、制御部３１は、Ｓ１４０２でＹｅｓと判断し、処理対象のリクエストサービスＩＤに対応する定期問合せ返信管理テーブル内の返信管理情報が有するサービススタート情報を、値「ＦＡＬＳＥ」に更新する（Ｓ１４０３）。
【０２８３】
その後、当該処理対象のリクエストサービスＩＤに関連付けられてリクエストサービスＩＤ管理テーブルに記憶されているパラメータの値を、キーワードに設定すると共に、予め定められた特定のブログサイトにアクセスし、そのブログサイトに掲載された新しい投稿群の中から、上記設定したキーワードを有する投稿を検索する（Ｓ１４０４）。
【０２８４】
この検索時において、上記設定したキーワードを有する投稿の数が多すぎるなどし、エラーが発生すると、制御部３１は、Ｓ１４０５でＹｅｓと判断し、当該処理対象のリクエストサービスＩＤに対応する定期問合せ返信管理テーブル内の返信管理情報が有するサービスキャンセル情報を、値「ＴＲＵＥ」に更新する（Ｓ１４０６）。
【０２８５】
また、当該処理対象のリクエストサービスＩＤに対応する定期問合せ返信管理テーブル内のサービスステータス情報を、値「−３」に更新する（Ｓ１４０７）。その後、Ｓ１４０１に移行して、未処理のリクエストサービスＩＤを、リクエストサービスＩＤ管理テーブルから一つ選択する。
【０２８６】
一方、Ｓ１４０４における検索が正常に終了すると、制御部３１は、Ｓ１４０５でＮｏと判断して、Ｓ１４０８に移行し、上記検索の結果、上記設定されたキーワードを含む新しい投稿がブログサイトから発見されたか否か判断する。そして、新しい投稿が発見されていないと判断すると、Ｓ１４０１に移行する。
【０２８７】
また、Ｓ１４０８において、上記設定されたキーワードを含む新しい投稿がブログサイトから発見されたと判断すると、制御部３１は、Ｓ１４０９に移行し、上記キーワードを含む投稿の内容を表した提供用データを生成する。そして、これを、記憶部３３に保存すると共に、Ｓ１４１０に移行し、上記保存した提供用データのダウンロード先のＵＲＬ情報（例えば、文字列”ｈｔｔｐ：／／＊＊＊＊．ｃｏ．ｊｐ／ｃｇｉ／ｂｌｏｇ？ｆ＝＊＊＊＊”等）を生成する。また、上記定期問合せ返信管理テーブルにおける当該処理対象のリクエストサービスＩＤに対応するサービスＵＲＬ情報を、上記生成したダウンロード先（即ち、サービス提供先）のＵＲＬ情報に変更する（Ｓ１４１１）。
【０２８８】
Ｓ１４１１での処理を終えると、制御部３１は、上記定期問合せ返信管理テーブルにおける当該処理対象のリクエストサービスＩＤに対応するサービススタート情報を、値「ＴＲＵＥ」に変更する（Ｓ１４１２）。その後、Ｓ１４０１に移行し、リクエストサービスＩＤ管理テーブルから、未処理のリクエストサービスＩＤを一つ選択する。そして、リクエストサービスＩＤ管理テーブルに列挙された全リクエストサービスＩＤについて、Ｓ１４０３以降の処理を実行すると、Ｓ１４０２にてＮｏと判断し、当該ブログ検索処理を終了する。
【０２８９】
次に、上記ローカルニュース提供サービスについて利用登録された複合機１０に対し提供する情報を生成するニュース情報生成処理について説明する。尚、図２９は、機能サーバ３０の制御部３１が実行するニュース情報生成処理を表すフローチャートである。このニュース情報生成処理は、機能サーバ３０の動作中、所定期間毎に、繰返し行われる。
【０２９０】
ニュース情報生成処理を実行すると、制御部３１は、まずローカルニュース提供サービスに対応するリクエストサービスＩＤ管理テーブルから、処理対象のリクエストサービスＩＤを一つ選択する（Ｓ１５０１）。ここで、処理対象のリクエストサービスＩＤが存在しない、即ち、後述するＳ１５０３以降の処理対象となっていない未処理のリクエストサービスＩＤが存在しない場合には、Ｓ１５０２でＮｏと判断して、当該ニュース情報生成処理を終了する。
【０２９１】
一方、処理対象（未処理）のリクエストサービスＩＤが存在すると、制御部３１は、Ｓ１５０２でＹｅｓと判断して、処理対象のリクエストサービスＩＤに対応する定期問合せ返信管理テーブル内の返信管理情報が有するサービススタート情報を、値「ＦＡＬＳＥ」に更新する（Ｓ１５０３）。
【０２９２】
その後、制御部３１は、Ｓ１５０４にて、リクエストサービスＩＤ管理テーブルが記憶する処理対象のリクエストサービスＩＤのパラメータ情報に基づき、そのパラメータ情報が示すプリペイドカード番号（パラメータＰｒｅｐａｉｄの値）が、有効なプリペイドカード番号であるか否か判断する。
【０２９３】
そして、Ｓ１５０４で有効なプリペイドカード番号ではないと判断すると、上記定期問合せ返信管理テーブルにおける当該処理対象のリクエストサービスＩＤに対応するサービスキャンセル情報を、値「ＴＲＵＥ」に変更すると共に（Ｓ１５０５）、サービスステータス情報を、有効でない原因に応じた値に変更する（Ｓ１５０６）。
【０２９４】
即ち、プリペイドカード番号が、不正利用されているプリペイドカード番号である場合には、サービスステータス情報を値「−１」に変更し、プリペイドカード番号が、不正利用されているプリペイドカード番号ではなく単にポイント切れによって無効にされたプリペイドカード番号である場合には、サービスステータス情報を値「−２」に変更する。このようにしてＳ１５０６での処理を終えると、制御部３１は、Ｓ１５０１に移行して、未処理のリクエストサービスＩＤを、リクエストサービスＩＤ管理テーブルから一つ選択する。その後、後続の処理を行う。
【０２９５】
一方、Ｓ１５０４で有効なプリペイドカード番号であると判断すると、制御部３１は、Ｓ１５０７に移行し、当該処理対象のリクエストサービスＩＤに関連付けられてリクエストサービスＩＤ管理テーブルに記憶されているパラメータＡｄｄｒｅｓｓ（図７，１５参照）の値に合致する地域のローカルニュースデータを、特定のデータベース（図示せず）から取得する。また、Ｓ１５０７の処理を終えると、Ｓ１５０８に移行し、当該処理対象のリクエストサービスＩＤに関連付けられてリクエストサービスＩＤ管理テーブルに記憶されているパラメータＮｕｍｐａｇｅｓ（図７，１５参照）の値が、上記Ｓ１５０７で取得したローカルニュースデータの情報量に適した値であるか否か判断する。
【０２９６】
尚、パラメータＮｕｍｐａｇｅｓは、ローカルニュースデータを表す文字情報を収める紙の枚数（頁数）を示すものであり、ここでは、ローカルニュースデータが表す文字情報を、パラメータＮｕｍｐａｇｅｓが表す枚数の紙に、収めることができない場合に、パラメータＮｕｍｐａｇｅｓの値が、上記Ｓ１５０７で取得したローカルニュースデータの情報量に適した値ではないと判断し、収めることができる場合には、パラメータＮｕｍｐａｇｅｓの値が、上記Ｓ１５０７で取得したローカルニュースデータの情報量に適した値であると判断する。
【０２９７】
Ｓ１５０８で、パラメータＮｕｍｐａｇｅｓの値が適した値ではないと判断すると、制御部３１は、Ｓ１５０９に移行し、上記定期問合せ返信管理テーブルにおける当該処理対象のリクエストサービスＩＤに対応するサービスキャンセル情報を、値「ＴＲＵＥ」に変更する。また、サービスステータス情報を、ステータス値「−３」と、キャンセルの原因となったパラメータを表す情報としての文字列「Ｎｕｍｐａｇｅｓ」と、エラーを解消可能なパラメータ（Ｎｕｍｐａｇｅｓ）の範囲（正常範囲）を表す文字列（例えば「３以上」との文字列）と、からなる情報（例えば、文字列「−３，Ｎｕｍｐａｇｅｓ，３以上」）に変更する（Ｓ１５１０）。このようにしてＳ１５１０での処理を終えると、制御部３１は、Ｓ１５０１に移行して、未処理のリクエストサービスＩＤを、リクエストサービスＩＤ管理テーブルから一つ選択する。その後、後続の処理を行う。
【０２９８】
一方、Ｓ１５０８で、パラメータＮｕｍｐａｇｅｓの値が適した値であると判断すると、制御部３１は、Ｓ１５１１に移行し、上記取得したローカルニュースデータを、パラメータＮｕｍｐａｇｅｓの値に合致する頁数分の提供用データ（ＰＤＦデータ等）に変換して、提供用データを生成する。その後、この提供用データを、記憶部３３に保存する。
【０２９９】
Ｓ１５１１での処理を終えると、制御部３１は、上記保存した提供用データのダウンロード先のＵＲＬ情報を生成し（Ｓ１５１２）、上記定期問合せ返信管理テーブルにおける当該処理対象のリクエストサービスＩＤに対応するサービスＵＲＬ情報を、上記生成したダウンロード先（サービス提供先）のＵＲＬ情報に変更する（Ｓ１５１３）。
【０３００】
Ｓ１５１３での処理を終えると、制御部３１は、上記定期問合せ返信管理テーブルにおける当該処理対象のリクエストサービスＩＤに対応するサービススタート情報を、値「ＴＲＵＥ」に変更する（Ｓ１５１４）。その後、Ｓ１５０１に移行し、リクエストサービスＩＤ管理テーブルから、未処理のリクエストサービスＩＤを一つ選択する。そして、リクエストサービスＩＤ管理テーブルに列挙された全リクエストサービスＩＤについて、Ｓ１５０３以降の処理を実行すると、Ｓ１５０２にてＮｏと判断し、当該ニュース情報生成処理を終了する。
【０３０１】
次に、機能サーバ３０の動作中に、制御部３１が繰返し実行するタイムアウト巡回処理について説明する。尚、タイムアウト巡回処理は、定期問合せのないサービスについての返信管理情報を削除して、そのサービスの利用登録を抹消するためのものである。図３０は、このタイムアウト巡回処理を表すフローチャートである。
【０３０２】
タイムアウト巡回処理を実行すると、制御部３１は、Ｓ１５５１にて、定期問合せ返信管理テーブルから、処理対象のリクエストサービスＩＤを一つ選択する。ここで、処理対象のリクエストサービスＩＤが存在しない、即ち、後述するＳ１５５３以降の処理対象となっていない未処理のリクエストサービスＩＤが存在しない場合には、Ｓ１５５２でＮｏと判断して、当該タイムアウト巡回処理を終了する。
【０３０３】
一方、処理対象（未処理）のリクエストサービスＩＤが存在すると、制御部３１は、Ｓ１５５２でＹｅｓと判断して、１５５３に移行し、所定期間（例えば、３日間）、そのリクエストサービスＩＤについての定期問合せがされていないかどうか判断する。ここでは、具体的に、上記定期問合せ返信管理テーブルが記憶する処理対象のリクエストサービスＩＤの問合せ日時情報が、現在日時から所定期間（３日間）以上前の日時を示しているかを判断することにより、所定期間（例えば、３日間）、処理対象のリクエストサービスＩＤについての定期問合せがされていないかどうか判断する。
【０３０４】
そして、所定期間、定期問合せがされていないと判断すると（Ｓ１５５３でＹｅｓ）、制御部３１は、処理対象のリクエストサービスＩＤに対応する返信管理情報を、定期問合せ返信管理テーブルから削除すると共に、上記処理対象のリクエストサービスＩＤに対応するパラメータ情報を、リクエストサービスＩＤ管理テーブルから削除する（Ｓ１５５４）。その後、Ｓ１５５１に移行して、次の処理対象（未処理のリクエストサービスＩＤ）を選択する。
【０３０５】
一方、所定期間に、定期問合せがされていると判断すると（Ｓ１５５３でＮｏ）、制御部３１は、Ｓ１５５４の処理を実行せずに、Ｓ１５５１に移行する。そして、定期問合せ返信管理テーブルに登録されている全てのリクエストサービスＩＤについてＳ１５５３以降の処理を実行すると、Ｓ１５５２でＮｏと判断して、当該タイムアウト巡回処理を終了する。
【０３０６】
次に、統合返信情報を受信し、この統合返信情報に基づいてサービスを受けるために、複合機１０の制御部１１が実行する統合返信情報受信処理について、図３１を用いて説明する。尚、図３１は、複合機１０の制御部１１が実行する統合返信情報受信処理を表すフローチャートである。
【０３０７】
統合返信情報受信処理を実行すると、制御部１１は、通信部１５を介して、機能サーバ３０から送信されてくる上記定期問合せ信号に対する応答信号（統合返信情報）を受信するまで待機し（Ｓ１６０１）、応答信号を受信すると、その応答信号に含まれる統合返信情報の中から、処理対象のリクエストサービスＩＤを一つ選択する（Ｓ１６０２）。ここで、処理対象のリクエストサービスＩＤが存在しない、即ち、Ｓ１６０４以降の処理対象となっていない未処理のリクエストサービスＩＤが存在しない場合には、Ｓ１６０３でＮｏと判断して、Ｓ１６０６に移行し、処理対象（未処理）のリクエストサービスＩＤが存在する場合には、Ｓ１６０３でＹｅｓと判断して、Ｓ１６０４に移行する。
【０３０８】
Ｓ１６０４に移行すると、制御部１１は、上記処理対象のリクエストサービスＩＤに対応付けて、統合返信情報に記載されているＳｅｒｖｉｃｅ＿Ｓｔａｔｕｓタグに、パラメータＳｅｒｖｉｃｅ＿Ｓｔａｔｕｓの値があるか否か判断する。即ち、上記処理対象のリクエストサービスＩＤが記載されたＲｅｓｐｏｎｃｅ＿Ｓｅｒｖｉｃｅタグの間に記載されたＳｅｒｖｉｃｅ＿Ｓｔａｔｕｓタグの間に、値が記載されているか否かを判断する。
【０３０９】
そして、パラメータＳｅｒｖｉｃｅ＿Ｓｔａｔｕｓの値がない（即ち、＜Ｓｅｒｖｉｃｅ＿Ｓｔａｔｕｓ＞＜／Ｓｅｒｖｉｃｅ＿Ｓｔａｔｕｓ＞）であると判断すると、Ｓ１６０２に移行する。一方、パラメータＳｅｒｖｉｃｅ＿Ｓｔａｔｕｓの値があると判断すると、Ｓ１６０５に移行し、パラメータＳｅｒｖｉｃｅ＿Ｓｔａｔｕｓの値に対応するステータス情報を、表示部１９のディスプレイ１９ａに表示する。その後、制御部１１は、Ｓ１６０２に移行し、未処理のリクエストサービスＩＤを一つ処理対象に選択して、再び、Ｓ１６０３以降の処理を実行する。
【０３１０】
そして、統合返信情報内に記載された全てのリクエストサービスＩＤについて、Ｓ１６０４以降の処理を実行すると、Ｓ１６０３でＮｏと判断して、Ｓ１６０６に移行し、値「ＴＲＵＥ」が記載されたＳｅｒｖｉｃｅ＿Ｓｔａｒｔタグに関連付けられたリクエストサービスＩＤの全てについて、そのリクエストサービスＩＤに対応するサービスを、機能サーバ３０から受けたか否か判断する。
【０３１１】
値「ＴＲＵＥ」が記載されたＳｅｒｖｉｃｅ＿Ｓｔａｒｔタグに関連付けられたリクエストサービスＩＤの中に、機能サーバ３０からサービスを受けていないリクエストサービスＩＤがある場合、制御部１１は、Ｓ１６０６でＮｏと判断して、Ｓ１６０７に移行する。そして、上記統合返信情報の中から、処理対象のリクエストサービスＩＤを一つ選択する。
【０３１２】
ここで、処理対象のリクエストサービスＩＤが存在しない、即ち、Ｓ１６０９以降の処理対象となっていない未処理のリクエストサービスＩＤが存在しない場合には、Ｓ１６０８でＮｏと判断して、Ｓ１６０６に移行し、処理対象（未処理）のリクエストサービスＩＤが存在する場合には、Ｓ１６０８でＹｅｓと判断して、Ｓ１６０９に移行する。
【０３１３】
Ｓ１６０９に移行すると、制御部１１は、処理対象のリクエストサービスＩＤに対応付けて、統合返信情報に記載されたＳｅｒｖｉｃｅ＿Ｓｔａｒｔタグに、値「ＴＲＵＥ」が記載されているか否か判断する。即ち、上記処理対象のリクエストサービスＩＤが記載されたＲｅｓｐｏｎｃｅ＿Ｓｅｒｖｉｃｅタグの間に記載されたＳｅｒｖｉｃｅ＿Ｓｔａｒｔタグの間に、値「ＴＲＵＥ」が記載されているか否かを判断する。
【０３１４】
ここで、Ｓｅｒｖｉｃｅ＿Ｓｔａｒｔタグに、値「ＴＲＵＥ」が記載されていないと判断すると、制御部１１は、Ｓ１６０７に移行し、値「ＴＲＵＥ」が記載されていると判断すると、Ｓ１６１０に移行して、当該処理対象のリクエストサービスＩＤに対応するサービスを機能サーバ３０から受ける際に用いる入出力デバイス（読取部１３，記録部１４，音入力部１７，音出力部１８）が、他のプロセス（サービス）によって動作（使用）中であるか否かを、定期問合せ管理テーブルの利用デバイス情報に基づいて、判断する。
【０３１５】
そして、上記デバイスが動作中であると判断すると、Ｓ１６０７に移行し、上記デバイスが動作中ではないと判断すると、Ｓ１６１１に移行して、処理対象のリクエストサービスＩＤに関連付けられた統合返信情報のＳｅｒｖｉｃｅ＿ＵＲＬタグの値を、を引数に設定し、サービス受信処理（図１０）のプロセスを起動する。
【０３１６】
その後、制御部３１は、Ｓ１６０７に移行し、統合返信情報から、未処理のリクエストサービスＩＤを選択し、このリクエストサービスＩＤに対応付けて統合返信情報に記載されたＳｅｒｖｉｃｅ＿Ｓｔａｒｔタグに、値「ＴＲＵＥ」が記載されている場合には、前回起動したサービス受信処理のプロセスと並行して、更にもう一つ、サービス受信処理のプロセスを起動する。但し、並行処理するのは、Ｓ１６１０でＮｏと判断された場合のみ、即ち、現在もなお受信中のサービスとは、異なる入出力デバイスを用いるサービスについてのプロセスのみである。
【０３１７】
即ち、Ｓ１６０７〜Ｓ１６１１の過程では、Ｓｅｒｖｉｃｅ＿Ｓｔａｒｔタグに、値「ＴＲＵＥ」が記載されているリクエストサービスＩＤに対応するサービスであって、異なる入出力デバイスを利用するサービスのみのサービス受信処理のプロセスを並行して実行する。これに対し、同一の入出力デバイスを利用するサービスのプロセスについては、Ｓ１６０８にてＮｏと判断し、Ｓ１６０６にてＮｏと判断して、再び１６０７以降の処理を実行することで、シリアルに実行する。
【０３１８】
そして、値「ＴＲＵＥ」が記載されたＳｅｒｖｉｃｅ＿Ｓｔａｒｔタグに関連付けられたリクエストサービスＩＤの全てについて、そのリクエストサービスＩＤに対応するサービスを、機能サーバ３０から受けたと判断すると（換言すると、サービス受信処理のプロセスを起動したと判断すると）、制御部１１は、Ｓ１６０６でＹｅｓと判断して、Ｓ１６２０に移行し、図３２に示す終了サービス分析処理を実行する。そして、この終了サービス分析処理を終了すると、Ｓ１６０１に移行し、次の統合返信情報を受信するまで待機する。尚、図３２は、制御部１１が実行する終了サービス分析処理を表すフローチャートである。
【０３１９】
終了サービス分析処理を実行すると、制御部１１は、まず１６２１にて、統合返信情報から処理対象のリクエストサービスＩＤを一つ選択する。ここで、処理対象のリクエストサービスＩＤが存在しない、即ち、後述するＳ１６２３以降の処理対象となっていない未処理のリクエストサービスＩＤが存在しない場合には、Ｓ１６２２でＮｏと判断して、当該終了サービス分析処理を終了する。
【０３２０】
一方、処理対象（未処理）のリクエストサービスＩＤが存在すると、制御部１１は、Ｓ１６２２でＹｅｓと判断して、１６２３に移行し、そのリクエストサービスＩＤに関連付けられて記述された統合返信情報のＳｅｒｖｉｃｅ＿Ｃａｎｃｅｌｅｄタグの値が「ＴＲＵＥ」であるか否か判断する。ここで、Ｓｅｒｖｉｃｅ＿Ｃａｎｃｅｌｅｄタグの値が「ＴＲＵＥ」ではない（「ＦＡＬＳＥ」である）と判断すると（Ｓ１６２３でＮｏ）、制御部１１は、Ｓ１６２１に移行して、次の処理対象（未処理のリクエストサービスＩＤ）を選択し、Ｓ１６２２以降の処理を実行する。
【０３２１】
これに対し、Ｓｅｒｖｉｃｅ＿Ｃａｎｃｅｌｅｄタグの値が「ＴＲＵＥ」であると判断すると（Ｓ１６２３でＹｅｓ）、制御部１１は、Ｓ１６２４に移行し、当該処理対象のリクエストサービスＩＤに対応する利用登録情報が記憶部１６に記憶されているか否か判断する。そして、記憶されていないと判断すると（Ｓ１６２４でＮｏ）、Ｓ１６２８に移行し、ディスプレイ１９ａに、サービスが終了したことを示すメッセージを、リクエストサービスＩＤを表す文字情報と共に、表示する。その後、Ｓ１６２１に移行する。
【０３２２】
また、Ｓ１６２４で当該処理対象のリクエストサービスＩＤに対応する利用登録情報が記憶部１６に記憶されていると判断すると、制御部１１は、Ｓ１６２５に移行し、当該処理対象のリクエストサービスＩＤに関連付けられて記述されている統合返信情報のＳｅｒｖｉｃｅ＿Ｓｔａｔｕｓタグが値（文字列）を含むものであるか否か判断する。
【０３２３】
ここで、Ｓｅｒｖｉｃｅ＿Ｓｔａｔｕｓタグが値（文字列）を含むものではなく空情報である（即ち、＜Ｓｅｒｖｉｃｅ＿Ｓｔａｔｕｓ＞＜／Ｓｅｒｖｉｃｅ＿Ｓｔａｔｕｓ＞である）と判断すると（Ｓ１６２５でＮｏ）、制御部１１は、Ｓ１６２８に移行し、ディスプレイ１９ａに、サービスが終了したことを示すメッセージを、リクエストサービスＩＤを表す文字情報と共に、表示する。その後、Ｓ１６２１に移行する。
【０３２４】
一方、Ｓｅｒｖｉｃｅ＿Ｓｔａｔｕｓタグが値（文字列）を含むものであると判断すると（Ｓ１６２５でＹｅｓ）、制御部１１は、Ｓ１６２６に移行し、上記定期問合せ管理テーブルにおける処理対象のリクエストサービスＩＤの再登録許可情報が値「ＴＲＵＥ」であるか否か判断する。
【０３２５】
そして、再登録許可情報が値「ＴＲＵＥ」ではない（即ち「ＦＡＬＳＥ」である）と判断すると、Ｓ１６２８に移行し、ディスプレイ１９ａに、サービスが終了したことを示すメッセージを表示し、この後に、Ｓ１６２１に移行する。
【０３２６】
一方、再登録許可情報が「ＴＲＵＥ」であると判断すると（Ｓ１６２６でＹｅｓ）、制御部１１は、Ｓ１６２７に移行し、処理対象のリクエストサービスＩＤに関連付けられた統合返信情報のＳｅｒｖｉｃｅ＿Ｓｔａｔｕｓタグの値が「−１」であるか否か判断する。そして、上記Ｓｅｒｖｉｃｅ＿Ｓｔａｔｕｓタグの値が「−１」であると判断すると、Ｓ１６２８に移行し、ディスプレイ１９ａに、サービスが終了したことを示すメッセージを表示し、この後に、Ｓ１６２１に移行する。
【０３２７】
また、上記Ｓｅｒｖｉｃｅ＿Ｓｔａｔｕｓタグの値が「−１」ではないと判断すると（Ｓ１６２７でＮｏ）、制御部１１は、Ｓ１６２９に移行し、上記Ｓｅｒｖｉｃｅ＿Ｓｔａｔｕｓタグの値が「−２」であるか否かを判断する。そして、上記Ｓｅｒｖｉｃｅ＿Ｓｔａｔｕｓタグの値が「−２」であると判断すると、プリペイドカード番号の再入力用画面をディスプレイ１９ａに表示し、プリペイドカード番号の入力を受け付ける（Ｓ１６３０）。
【０３２８】
そして、操作部１２から入力された入力情報（プリペイドカード番号）に従って、記憶部１６が記憶する当該処理対象のリクエストサービスＩＤに対応する利用登録情報を、更新する。即ち、記憶部１６が記憶する利用登録情報を構成するパラメータＰｒｅｐａｉｄの値を、操作部１２から入力されたプリペイドカード番号に更新する（Ｓ１６３１）。その後、Ｓ１６３５に移行する。
【０３２９】
これに対し、Ｓ１６２９で上記Ｓｅｒｖｉｃｅ＿Ｓｔａｔｕｓタグの値が「−２」ではないと判断すると、制御部１１は、Ｓ１６３２に移行し、上記Ｓｅｒｖｉｃｅ＿Ｓｔａｔｕｓタグの値が「−３」又は「−３」をステータス値として有する付属情報を備えた文字列であるか否か判断する。そして、上記Ｓｅｒｖｉｃｅ＿Ｓｔａｔｕｓタグの値が「−３」又は「−３」をステータス値として有する付属情報を備えた文字列であると判断すると、上記Ｓｅｒｖｉｃｅ＿Ｓｔａｔｕｓタグの値に基づいて、パラメータの再入力用画面を表示する（Ｓ１６３３）。
【０３３０】
具体的に、制御部１１は、上記Ｓｅｒｖｉｃｅ＿Ｓｔａｔｕｓタグの値が「−３」である場合には、処理対象のリクエストサービスＩＤに対応する利用登録情報が含むパラメータ情報に基づいて、パラメータＰｒｅｐａｉｄを除く他のパラメータの再入力用画面をディスプレイ１９ａに表示する。
【０３３１】
一方、上記Ｓｅｒｖｉｃｅ＿Ｓｔａｔｕｓタグの値が「−３」をステータス値として有する付属情報を備えた文字列である場合には、その付属情報、即ち、サービスキャンセルの原因となったパラメータを表す情報（例えば、文字列「Ｎｕｍｐａｇｅｓ」）と、エラーを解消可能なパラメータの正常範囲を表す文字列（例えば「３以上」との文字列）と、に基づいて、サービスキャンセル（即ちサービス終了）の原因となったパラメータについての再入力用画面を、ディスプレイ１９ａに表示する。尚、図３３は、上記サービスキャンセルの原因となったパラメータについての再入力用画面の表示例を示した説明図である。
【０３３２】
図３３に示すように、この再入力用画面には、上記サービスキャンセルの原因となったパラメータの名称を表す文字列（例えば「情報を収める紙の枚数」）と共に、そのパラメータについての値入力欄が設けられており、入力欄には、現在の利用登録情報に登録されている該当パラメータの値（例えば、パラメータＮｕｍｐａｇｅｓの値）が初期表示される。また、パラメータの名称を表す文字列と、入力欄との間には、そのパラメータの値の正常範囲を表す文字列（例えば、「３以上」）が表示される。尚、上記サービスキャンセルの原因となったパラメータの名称を表す文字列や、そのパラメータについての値入力欄は、利用登録情報が有するサービスＩ／Ｆ情報に基づいて表示される。
【０３３３】
Ｓ１６３３での処理を終えると、制御部１１は、Ｓ１６３４に移行し、上記再入力用画面を通じて操作部１２から入力された情報に基づき、記憶部１６が記憶する当該処理対象のリクエストサービスＩＤの利用登録情報を構成する該当パラメータ（例えば、パラメータＮｕｍｐａｇｅｓ）の値を更新する。その後、Ｓ１６３５に移行する。
【０３３４】
その他、Ｓ１６３２で上記Ｓｅｒｖｉｃｅ＿Ｓｔａｔｕｓタグの値が「−３」又は「−３」をステータス値として有する付属情報を備えた文字列ではない（即ち、上記Ｓｅｒｖｉｃｅ＿Ｓｔａｔｕｓタグの値が「−４」である）と判断すると、制御部１１は、Ｓ１６３３〜Ｓ１６３４の処理を実行せずに、Ｓ１６３５に移行する。
【０３３５】
Ｓ１６３５に移行すると、制御部１１は、記憶部１６が記憶する処理対象のリクエストサービスＩＤの利用登録情報に、パラメータＡｄｄｒｅｓｓの値が含まれているか否か判断し、パラメータＡｄｄｒｅｓｓの値が含まれていると判断すると、Ｓ１６３６に移行し、その利用登録情報に含まれるサービスＩ／Ｆ情報に基づいて（例えば、図７に示すサービスＩ／Ｆ情報の先頭のＦｏｒｍ＿Ｅｌｅｍタグの情報に基づいて）、パラメータＡｄｄｒｅｓｓについての再入力用画面をディスプレイ１９ａに表示し、パラメータＡｄｄｒｅｓｓの値入力を受け付ける。
【０３３６】
そして、操作部１２から入力された入力情報（パラメータＡｄｄｒｅｓｓの値若しくはその選択情報）に従って、記憶部１６が記憶する当該処理対象のリクエストサービスＩＤに対応する利用登録情報を、更新する。即ち、記憶部１６が記憶する利用登録情報を構成するパラメータＡｄｄｒｅｓｓの値を、操作部１２からの入力情報に一致するパラメータＡｄｄｒｅｓｓの値に更新する（Ｓ１６３７）。その後、Ｓ１６３８に移行する。
【０３３７】
一方、Ｓ１６３５にて、記憶部１６が記憶する処理対象のリクエストサービスＩＤの利用登録情報に、パラメータＡｄｄｒｅｓｓの値が含まれていないと判断すると、制御部１１は、Ｓ１６３６〜Ｓ１６３７の処理を行わずに、Ｓ１６３８に移行する。
【０３３８】
そして、Ｓ１６３８に移行すると、制御部１１は、処理対象のリクエストサービスＩＤについての上記更新後の利用登録情報に基づいて、図１０に示すサービス受信処理のプロセスを起動する。
【０３３９】
即ち、上記更新後の利用登録情報が有する利用登録（Ｌｉｎｋ＿Ｌｏｃａｔｉｏｎ）先のＵＲＬ情報を引数に設定して、サービス受信処理のプロセスを起動する。これにより制御部１１は、当該終了サービス分析処理のプロセスとは並行して、サービス受信処理のプロセスを実行し、このサービス受信処理にて、機能サーバ３０にアクセスして（Ｓ３０１）、機能サーバ３０に登録処理のプロセスを起動させる（Ｓ４０５）。また、登録処理のプロセスにて送信されてくる「ＵＩジョブ起動指令」、更にはサービス側ＵＩジョブから送信されてくる「パラメータ要求指令」に従って、図１９に示すパラメータ情報送信処理を実行する。そして、Ｓ８６１〜Ｓ８６３の処理を実行する。
【０３４０】
尚、制御部１１は、サービス受信処理のプロセスを起動した後、Ｓ１６２１に移行し、次の処理対象（未処理のリクエストサービスＩＤ）を選択し、Ｓ１６２２以降の処理を実行する。そして、統合返信情報に記載の全てのリクエストサービスＩＤについて、Ｓ１６２３以降の処理を実行すると、Ｓ１６２２でＮｏと判断して、当該終了サービス分析処理を終了する。
【０３４１】
次に、機能サーバ３０で実行されるサービス提供にかかるプロセスについて説明する。複合機１０の制御部１１は、ブログ検索サービス又はローカルニュース提供サービスについてのリクエストサービスＩＤを処理した結果、Ｓ１６１１にてサービス受信処理のプロセスを起動すると、その引数に設定されたサービスＵＲＬ情報に基づいて、機能サーバ３０にアクセスし（Ｓ３０１）、機能サーバ３０に、図３４に示す定期サービス提供処理を実行させる（Ｓ４０５）。図３４は、機能サーバ３０の制御部３１が実行する定期サービス提供処理を表すフローチャートである。
【０３４２】
尚、定期問合せ返信管理テーブルのサービスＵＲＬ情報には、ブログ検索サービス、ローカルニュース提供サービスに関して、図３４に示す定期サービス提供処理が実行される機能サーバ３０側のＵＲＬ情報（Ｓ４０５で図３４に示す定期サービス提供処理のプロセスが起動される機能サーバ３０側のＵＲＬ情報）が記載されていることとする。また、サービスＵＲＬ情報には、サービスの種類毎に、即ち、ブログ検索サービス及びローカルニュース提供サービスの夫々について、異なるＵＲＬ情報が記述されていることとする。この異なるＵＲＬ情報に基づく機能サーバ３０へのアクセスにより、ブログ検索サービスについての「サービス起動指令」に対しては、ブログ検索サービス用の定期サービス提供処理のプロセスが起動し、ローカルニュース提供サービスについての「サービス起動指令」に対しては、ローカルニュース提供サービス用の定期サービス提供処理のプロセスが起動する。
【０３４３】
定期サービス提供処理を実行すると、制御部３１は、Ｓ１７０１で、初期化処理を実行し、続くＳ１７０２で、サービス側印刷ジョブ（図３５参照。詳細後述）を起動する。続いて、Ｓ１７０３では、「印刷ジョブ起動指令」を複合機指令として出力する。具体的には、Ｓ４０５で生成したセッションＩＤに対応する返信情報格納領域に対して、「印刷ジョブ起動指令」を書き込む処理を行う。
【０３４４】
これによって、「印刷ジョブ起動指令」は、サービス制御情報処理を介し、複合機指令として、複合機１０に送信される。尚、この「印刷ジョブ起動指令」には、Ｓ１７０２で起動したサービス側印刷ジョブについてのジョブＩＤとジョブの通信先ＵＲＬ情報とが含まれる。
【０３４５】
Ｓ１７０３での処理を終えると、制御部３１は、Ｓ１７０４に移行し、後述するサービス側印刷ジョブから印刷準備完了の通知を受けたか否か判断し、受けていない場合には、Ｓ１７０５に移行して、上記サービス側印刷ジョブから停止の通知を受けたか否か判断する。そして、停止の通知を受けていない場合には、Ｓ１７０４に処理を戻すことで、上記サービス側印刷ジョブから印刷準備完了の通知、若しくは、停止の通知を受けるまで待機する。そして、停止の通知を受けると、Ｓ１７０５でＹｅｓと判断して、Ｓ１７０８に移行する。一方、印刷準備完了の通知を受けると、Ｓ１７０４でＹｅｓと判断して、Ｓ１７０６に移行する。
【０３４６】
Ｓ１７０６に移行すると、制御部３１は、当該定期サービス提供処理のプロセスを起動する際に複合機１０側からＵＲＬ情報にて指定されたダウンロード対象の提供用データを、記憶部３３から読み出し、この提供用データを、複合機１０の記録部１４の能力に適合した印刷データに変換する。その後、制御部３１は、サービス側印刷ジョブに、上記変換した印刷データを提供することにより、サービス側印刷ジョブを介して、上記変換した印刷データを、アクセス元の複合機１０に向けて出力する（Ｓ１７０７）。
【０３４７】
また、Ｓ１７０７の処理を終えると、制御部３１は、Ｓ１７０８に移行して、サービス側印刷ジョブが終了するまで待機し、印刷ジョブが終了すると、「印刷ジョブ終了指令」を複合機指令として出力する。具体的には、Ｓ４０５で生成したセッションＩＤに対応する返信情報格納領域に対して、「印刷ジョブ終了指令」を書き込む処理を行う。
【０３４８】
これによって、「印刷ジョブ終了指令」は、サービス制御情報処理を介し、複合機指令として、複合機１０に送信される。尚、この「印刷ジョブ終了指令」には、ジョブＩＤとジョブの通信先ＵＲＬ情報とが含まれる。
【０３４９】
また、「印刷ジョブ終了指令」の出力が終了すると、制御部３１は、Ｓ１７０９に移行し、「サービス終了指令」を、複合機指令として出力する。これにより、「サービス終了指令」は、複合機１０にて受信される。Ｓ１７０９での処理を終えると、機能サーバ３０の制御部３１は、当該定期サービス提供処理を終了する。
【０３５０】
次に、定期サービス提供処理（図３４）のＳ１７０２にて起動されるサービス側印刷ジョブについて説明する。図３５は、機能サーバ３０の制御部３１が実行するサービス側印刷ジョブを表すフローチャートである。尚、このサービス側印刷ジョブは、他の処理と並行して実行される。
【０３５１】
サービス側印刷ジョブの実行を開始すると、制御部３１は、まずＳ１８０１にて、複合機１０から「複合機状態情報」を受信するまで待機する。尚、「複合機状態情報」は、複合機１０の制御部１１により実行される後述の出力ジョブ（図３６）におけるＳ１９０４で送信される。
【０３５２】
この「複合機状態情報」を受信すると、制御部３１は、Ｓ１８０２に移行して、エラーカウントを初期化し、更に、記録部１４に設定すべきパラメータを、複合機パラメータとして複合機１０へ送信する（Ｓ１８０３）。
【０３５３】
Ｓ１８０３での処理を終えると、制御部３１は、Ｓ１８０４に移行し、複合機１０において複合機パラメータが正常に受信されたか否かを判断する。具体的には、複合機１０の制御部１１により実行される出力ジョブ（図３６）におけるＳ１９０９の処理により、「複合機受取状況」として「正常受取」が通知された場合に正常に受信されたと判断し、Ｓ１９０８の処理により、「複合機受取状況」として「異常受取」が通知された場合に正常に受信されなかったと判断する。
【０３５４】
Ｓ１８０４で、複合機パラメータが正常に受信されなかったと判断すると、制御部３１は、Ｓ１８０５へ移行し、正常に受信されなかったと判断された回数が２回目であるか否かを判断する。具体的には、Ｓ１８０２で初期化したエラーカウントに基づき判断する。
【０３５５】
そして、Ｓ１８０５で、２回目でない（１回目である）と判断した場合には、Ｓ１８０６へ移行し、エラーカウントをカウントアップした後、Ｓ１８０３へ移行する。
一方、Ｓ１８０５で、２回目であると判断した場合には、Ｓ１８０７へ移行し、起動元のプロセス（定期サービス提供処理（図３４）のプロセス）へ停止を通知する。その後、Ｓ１８１１にて、正常終了ではない（異常終了である）と判断し、Ｓ１８１２にて、異常終了である旨の情報を、「サービス状態情報」として複合機１０へ送信した後、当該サービス側印刷ジョブを終了する。
【０３５６】
また、Ｓ１８０４で、複合機パラメータが正常に受信されたと判断した場合には、Ｓ１８０８へ移行し、起動元の定期サービス提供処理のプロセスへ印刷準備完了を通知する。その後、Ｓ１８０９へ移行し、上述のＳ１７０６にて生成された印刷データを順次複合機１０へ送信する。
【０３５７】
Ｓ１８０９での処理を終えると、制御部３１は、続くＳ１８１０にて、複合機１０からの「複合機状態情報」を受信するまで待機し、「複合機状態情報」を受信すると、Ｓ１８１１に移行する。尚、「複合機状態情報」は、複合機１０の制御部１１により実行される出力ジョブ（図３６）におけるＳ１９１３の処理で送信される。
【０３５８】
Ｓ１８１１に移行すると、制御部３１は、その後、印刷データの送信処理が正常に終了したか否か判断し、正常に終了していないと判断すると、Ｓ１８１２に移行し、正常に終了していると判断すると、Ｓ１８１３に移行して、正常終了である旨の情報を、「サービス状態情報」として複合機１０へ送信する。その後、当該サービス側印刷ジョブを終了する。
【０３５９】
次に、定期サービス提供処理（図３４）のＳ１７０３にて出力される「印刷ジョブ起動指令」を受けて、複合機１０の制御部１１がＳ３５６にて起動する出力ジョブについて、図３６のフローチャートを用いて説明する。尚、図３６は、複合機１０の制御部１１が実行する出力ジョブを表すフローチャートである。
【０３６０】
出力ジョブを実行すると、制御部１１は、Ｓ１９０１で、出力装置（印刷ジョブ起動指令を受けた場合には記録部１４、スピーカジョブ起動指令を受けた場合には、音出力部１８）がビジー状態であるか否かを判断する。具体的には、出力装置がビジー状態であるか否かを表すビジーフラグＦｏに基づき、ビジーフラグＦｏが立っている場合にはビジー状態であると判断し、ビジーフラグＦｏが下りている場合にはビジー状態でないと判断する。
【０３６１】
ここで、出力装置がビジー状態であると判断すると、制御部１１は、Ｓ１９０２へ移行し、出力装置のビジー状態が解除されるまで待機した後、Ｓ１９０１へ移行する。一方、Ｓ１９０１で、ビジー状態でないと判断した場合には、Ｓ１９０３へ移行し、ビジーフラグＦｏを立てる。その後、制御部１１は、「複合機状態情報」を機能サーバ３０へ送信する（Ｓ１９０４）。尚、ここで送信される「複合機状態情報」には、セッションＩＤ、ジョブＩＤ等が含まれる。
【０３６２】
Ｓ１９０４の処理を終えると、制御部１１は、Ｓ１９０５に移行し、上記送信した「複合機状態情報」に対する応答信号として送信される複合機パラメータを機能サーバ３０から受信する。尚、複合機パラメータは、機能サーバ３０の制御部３１により実行されるサービス側印刷ジョブのＳ１８０３で送信される。
【０３６３】
Ｓ１９０５の処理が終了すると、制御部１１は、起動元のサービス受信処理のプロセスから、終了指示が入力されたか否かを判断する（Ｓ１９０６）。尚、終了指示は、複合機１０の制御部１１により実行されるサービス受信処理（図１０）のＳ３１０にて出力される。そして、終了指示が入力されていないと判断すると、Ｓ１９０７に移行し、Ｓ１９０５で複合機パラメータを正常に受信できたか否かを判断する。
【０３６４】
Ｓ１９０７で正常に受信できなかったと判断すると、制御部１１は、Ｓ１９０８へ移行し、複合機１０が機能サーバ３０からの情報を正常に受け取ることができたか否かの通知である「複合機受取状況」として、「異常受取」を機能サーバ３０へ通知し、Ｓ１９０５へ移行する。尚、「複合機受取状況」には、セッションＩＤ及びジョブＩＤが含まれる。
【０３６５】
一方、Ｓ１９０７で正常に受信できたと判断すると、制御部１１は、Ｓ１９０９へ移行し、「複合機受取状況」として正常受取である旨の「正常受取」を機能サーバ３０へ通知する。続いて、Ｓ１９１０では、出力データ（印刷データや音データ）を機能サーバ３０から受信する。尚、印刷データは、機能サーバ３０の制御部３１により実行されるサービス側印刷ジョブ処理（図３５）のＳ１８０９で送信される。
【０３６６】
Ｓ１９１０の処理を終了すると、制御部１１は、Ｓ１９１１へ移行し、上記複合機パラメータを出力装置（記録部１４又は音出力部１８）にセットし、出力データを出力する処理を行う。
【０３６７】
例えば、出力ジョブが、機能サーバ３０の定期サービス提供処理から出力される「印刷ジョブ起動指令」を受けて起動されたものである場合には、出力装置としての記録部１４を用いて、機能サーバ３０から提供される印刷データに基づく印刷出力処理を行う。
【０３６８】
具体的に、定期サービス提供処理のプロセスが、ブログ検索サービスを複合機１０に提供するためのプロセスであり、当該出力ジョブが、このブログ検索サービスを受けるためのプロセスである場合には、ブログ検索処理にて検索された投稿内容を、記録部１４を通じて印刷出力する。
【０３６９】
その他、定期サービス提供処理のプロセスが、ローカルニュース提供サービスを複合機１０に提供するためのプロセスであり、当該出力ジョブが、このローカルニュース提供サービスを受けるためのプロセスである場合には、ニュース情報生成処理にて生成されたニュースデータに基づく情報を、記録部１４を通じて印刷出力する。
【０３７０】
Ｓ１９１１での処理を終えると、制御部１１は、Ｓ１９１１で出力装置に設定したパラメータを元の値に戻し（Ｓ１９１２）、「複合機状態情報」を機能サーバ３０に向けて送信する（Ｓ１９１３）。Ｓ１９１３の処理後には、Ｓ１９１４に移行し、「サービス状態情報」を機能サーバ３０から受信する。その後、Ｓ１９１５に移行して、Ｓ１９０３で立てたビジーフラグＦｏを下ろし、当該出力ジョブを終了する。
【０３７１】
その他、図３７は、操作部１２を通じて利用登録情報の削除指示が入力されると、複合機１０の制御部１１が実行する利用登録情報削除処理を表すフローチャートである。
利用登録情報削除処理を実行すると、制御部１１は、まずＳ２００１にて、入力された削除指示が、全消去を表す削除指示であるか否か判断し、全消去を表す削除指示であると判断すると、記憶部１６に記憶された全ての利用登録情報を、記憶部１６から消去すると共に、定期問合せ管理テーブルに記憶されている利用登録情報の格納先アドレス情報を、全て空情報に更新する（Ｓ２００２）。その後、当該利用登録情報削除処理を終了する。
【０３７２】
一方、Ｓ２００１で削除指示が、全消去を表す削除指示ではないと判断すると、制御部１１は、Ｓ２００３に移行し、定期問合せ管理テーブルから処理対象のリクエストサービスＩＤを、一つ選択する。ここで、処理対象のリクエストサービスＩＤが存在しない、即ち、Ｓ２００５以降の処理の対象となっていない未処理のリクエストサービスＩＤが定期問合せ管理テーブルに存在しない場合には、Ｓ２００４でＮｏと判断して、当該利用登録情報削除処理を終了する。
【０３７３】
一方、未処理のリクエストサービスＩＤを処理対象に選択することができた場合には、Ｓ２００４でＹｅｓと判断し、その処理対象のリクエストサービスＩＤについての格納先アドレス情報に基づいて、処理対象のリクエストサービスＩＤについての利用登録情報が記憶部１６に記憶されているか否か判断する（Ｓ２００５）。
【０３７４】
具体的に、ここでは、格納先アドレス情報が空情報であると、利用登録情報が記憶部１６に記憶されていないと判断し、格納先アドレス情報が空情報ではないと、利用登録情報が記憶部１６に記憶されていると判断する。
【０３７５】
そして、利用登録情報が記憶部１６に記憶されていないと判断すると（Ｓ２００５でＮｏ）、制御部１１は、Ｓ２００３に移行して、次の処理対象（未処理のリクエストサービスＩＤ）を、定期問合せ管理テーブルから選択する。一方、利用登録情報が記憶部１６に記憶されていると判断すると、制御部１１は、Ｓ２００６に移行して、ディスプレイ１９ａに、処理対象のリクエストサービスＩＤについての利用登録情報を表示し、その利用登録情報を消去するか否かを問い合わせる。
【０３７６】
その後、操作部１２が利用者により操作されるまで待機し、操作部１２が利用者により操作されると、その入力情報に基づいて、利用者から操作部１２を通じて消去実行指示が入力されたか否か判断する（Ｓ２００７）。そして、消去実行指示が入力されたと判断すると（Ｓ２００７）、当該処理対象のリクエストサービスＩＤに対応する利用登録情報を記憶部１６から削除すると共に、そのリクエストサービスＩＤの問合せ管理情報を構成する格納先アドレス情報を空情報に更新する（Ｓ２００８）。そして、Ｓ２００８の処理を終えると、Ｓ２００３に移行し、次の処理対象を選択する。
【０３７７】
一方、Ｓ２００７で、消去実行指示が入力されず消去禁止指示が入力されたと判断すると、制御部１１は、Ｓ２００８の処理を実行せずに、Ｓ２００３に移行し、次の処理対象を選択する。そして、定期問合せ管理テーブルに登録されている全てのリクエストサービスＩＤについて、Ｓ２００５以降の処理を実行すると、Ｓ２００４でＮｏと判断して、当該利用登録情報削除処理を終了する。
【０３７８】
以上、本実施例の通信システム１について説明したが、この通信システム１では、サービス提供装置としての機能サーバ３０と、この機能サーバ３０と通信可能に構成された複合機１０（本発明の通信装置及び画像形成装置に相当）との間でＨＴＴＰ通信を行うことにより、機能サーバ３０から複合機１０に対して、複数種のサービス（ブログ検索サービスやローカルニュース提供サービス等）を提供する。
【０３７９】
機能サーバ３０は、複合機１０に提供するサービス（ブログ検索サービスやローカルニュース提供サービス）の内容を決定付ける一つ又は複数のパラメータの値が記述されたパラメータ情報（本発明の設定情報に相当）を、サービス提供対象の複合機１０の識別情報として機能するリクエストサービスＩＤと関連付け、リクエストサービスＩＤ管理テーブルに複数個記憶可能な構成にされている。
【０３８０】
この機能サーバ３０の制御部３１は、登録処理のプロセスに対応するＵＲＬ宛の「サービス起動指令」を複合機１０から受信すると、これをサービスの提供を受けるための登録を要求する旨の信号として解釈して、登録処理を実行し更にはサービス側ＵＩジョブを実行して、「サービス起動指令」送信元の複合機１０から、複合機１０が受けるサービスについてのパラメータ情報を取得すると共に、そのサービスの識別情報としてリクエストサービスＩＤを生成し、上記取得したパラメータ情報を、リクエストサービスＩＤと関連付け、リクエストサービスＩＤ管理テーブルに登録する（Ｓ６０７）。
【０３８１】
尚、生成したリクエストサービスＩＤは、「定期問合せ開始指令」と共に、「サービス起動指令」送信元の複合機１０のみに発行される。このため、リクエストサービスＩＤは、機能サーバ３０側で、サービス提供対象の複合機１０の識別情報としても機能する。
【０３８２】
また、この機能サーバ３０は、リクエストサービスＩＤ管理テーブルに登録された各パラメータ情報に従い、サービスに供される提供用データを、サービスの種類毎に異なるサービスソフトウェア３７（図２８に示すブログ検索処理を実現するサービスソフトウェア３７や、図２９に示すニュース情報生成処理を実現するサービスソフトウェア３７）にて生成する。そして、この提供用データのダウンロード先のＵＲＬ情報を、リクエストサービスＩＤと共に、サービス提供対象の複合機１０に通知することにより、提供用データを、図３４に示す定期サービス処理のプロセスを通じて、サービス提供対象の複合機１０に提供する。
【０３８３】
その他、機能サーバ３０は、各パラメータ情報に対応するサービスの終了条件が満足されたか否かを、リクエストサービスＩＤ管理テーブルに登録されたパラメータ情報毎に、判断する（Ｓ１４０５、Ｓ１５０４、Ｓ１５０８）。そして、終了条件が満足されたと判断されたサービス（リクエストサービスＩＤ）についてのサービスキャンセル情報を「ＴＲＵＥ」に変更する。
【０３８４】
この他、機能サーバ３０は、リクエストサービスＩＤ管理テーブルへのパラメータ情報の登録と共に、定期問合せ返信管理テーブルに登録した返信管理情報に基づいて、各パラメータ情報に対応するサービスの終了条件が満足されたか否か（最後の問合せ後、所定期間が経過したか否か）を、返信管理情報毎に、タイムアウト巡回処理にて、判断する。
【０３８５】
そして、終了条件が満足されたと判断されたサービス（リクエストサービスＩＤ）についてのパラメータ情報及び返信管理情報を、リクエストサービスＩＤ管理テーブル及び定期問合せ返信管理テーブルから削除する（Ｓ１１１６，Ｓ１５５４）ことにより、そのサービスの提供を終了する。
【０３８６】
一方、複合機１０は、利用者が操作可能な操作部１２から登録を指示する旨の信号が入力されると、Ｓ１１１及びＳ１１４でＹｅｓと判断して、サービス受信処理のプロセスを起動し、「サービス起動指令」を機能サーバ３０に送信すると共に、自装置が機能サーバ３０から受けるサービスについての各パラメータの値を表す情報を、操作部１２を通じて利用者から取得し（Ｓ８５２）、その情報を表すパラメータ情報を、機能サーバ３０に送信して（Ｓ８５３，Ｓ８７０，Ｓ８０６）、サービスの利用登録を行う。
【０３８７】
また、複合機１０は、パラメータ情報を送信する際に、その送信対象のパラメータ情報をコピーして、その情報を含む利用登録情報を生成し、記憶部１６に記憶させる（Ｓ８５７）。
【０３８８】
また、複合機１０は、この利用登録によって機能サーバ３０から提供されるサービスを、図２０に示す定期問合せ処理、図３１に示す統合返信情報受信処理を経て、図３６に示す出力ジョブにて受け、このサービスにて提供される情報を、記録部１４を用いて印刷出力する。即ち、出力ジョブにて、機能サーバ３０から提供される情報の印刷出力機能を実現する。
【０３８９】
その他、複合機１０は、利用登録された当該装置向けのサービスであって、機能サーバ３０にて提供が終了された当該通信装置向けのサービスを、統合返信情報の受信により検知する（具体的には、統合返信情報に、終了通知情報として、Ｓｅｒｖｉｃｅ＿Ｃａｎｃｅｌｅｄタグの値が「ＴＲＵＥ」となっているリクエストサービスＩＤの情報が存在する場合に、そのリクエストサービスＩＤに対応するサービスが、提供が終了されたサービスであると検知する）。
【０３９０】
そして、提供が終了されたサービスがある場合には、Ｓ１６３８にてサービス受信処理のプロセスを起動し、機能サーバ３０に登録処理のプロセスを起動させるための「サービス起動指令」を入力すると共に、記憶部１６が記憶する上記提供が終了されたサービスに対応する利用登録情報を読み出し（Ｓ８６１）、読み出した利用登録情報が含むパラメータ情報を、機能サーバ３０に送信することにより、上記提供が終了されたサービスの利用登録を行う。
【０３９１】
このように、本実施例の通信システム１においては、複合機１０が、初回の利用登録時に、機能サーバ３０に対して送信するパラメータ情報を記憶し（Ｓ８５７）、再登録時に、これを読み出して、機能サーバ３０に送信する（Ｓ８６１，Ｓ８６３，Ｓ８７０，Ｓ８０６）ため、再登録時に、利用者にパラメータの入力操作を行わせることなく、サービスの利用登録を行うことができる。即ち、この発明によれば、利用登録が抹消されたサービス（リクエストサービスＩＤ管理テーブルから削除されたサービス）についての再登録を、利用者を煩わせることなく実行できる。
【０３９２】
また、本実施例の複合機１０では、機能サーバ３０により提供が終了されたサービスについての利用登録が必要か否かを、機能サーバ３０から送信されるＳｅｒｖｉｃｅ＿Ｓｔａｔｕｓタグの値に基づいて判断し（Ｓ１６２７）、Ｓ１６２７でＮｏと判断した場合にのみＳ１６３８の処理を実行することで、上記提供が終了されたサービスのうち、利用登録が必要であると判断したサービスについての利用登録を選択的に実行し、利用登録が不要であるサービスについては、利用登録を実行しないようにしている。
【０３９３】
具体的に本実施例では、プリペイドカード番号が不正なものであるといった原因でサービスの提供を終了する場合に、Ｓｅｒｖｉｃｅ＿Ｓｔａｔｕｓタグの値を「−１」として、この情報を複合機１０に提供することで、複合機１０に対し、利用登録を自動で実行させないようにする。従って、本実施例によれば、サービス提供者側が望んでいないのにも拘わらず、複合機１０が利用登録に係る処理を実行してしまうのを防止することができる。尚、本発明でいう再登録要否判断手段が、「終了原因を判定して、利用登録が必要か否か判断する」手順、及び、「再登録の受付可否を表す情報に従って、利用登録が必要か否か判断する」手順は、本実施例におけるＳ１６２７にて実現されている。
【０３９４】
この他、本実施例では、複合機１０が、サービスの利用登録の際に、パラメータの値入力の受付と共に、利用者に対し、そのサービスの再登録を許可するか否かを問合せ、これに応答して操作部１２から入力される再登録の許可／不許可を表す再登録許可情報を取得し（Ｓ８５６，Ｓ８５８）、これを、利用登録されたサービス毎に、定期問合せ管理テーブルに記憶させる（Ｓ３１２，Ｓ３１３）。
【０３９５】
そして、上記提供が終了されたサービスを検知すると（Ｓ１６２３でＹｅｓ）、定期問合せ管理テーブルが記憶する該当サービスの再登録許可情報に従って、上記提供が終了されたサービスが、再登録を許可されたサービスであるか否かを判断し（Ｓ１６２６）、再登録を許可されたサービスではない場合には、Ｓ１６２６でＮｏと判断し、そのサービスについてのＳ１６３８の処理を行わないようにする（即ち再登録を禁止する）。
【０３９６】
このように、本実施例の複合機１０では、利用者の意思に従って、再登録の実行／実行禁止を切り替えるので、利用者の意思に関わらず再登録を行う場合よりも、利用者に不満が及ぶことがない。特に、本実施例では、再登録許可情報を予め取得しておくので、サービスの提供が終了してから操作部１２を通じて上記情報を取得する場合よりも、再登録を迅速に行うことができる。
【０３９７】
また、本実施例の複合機１０によれば、上記提供が終了されたサービスが検知された場合に、サービスの提供が終了された原因を表すＳｅｒｖｉｃｅ＿Ｓｔａｔｕｓタグの値に応じて、値の変更を推奨するパラメータを決定し、Ｓｅｒｖｉｃｅ＿Ｓｔａｔｕｓタグの値に応じたパラメータの再入力用画面を表示する（Ｓ１６３０，Ｓ１６３３）。
【０３９８】
具体的には、Ｓｅｒｖｉｃｅ＿Ｓｔａｔｕｓの値が「−２」であると、プリペイドカード番号の変更を指示するメッセージと共に、その入力欄を示したパラメータの再入力用画面を表示し（Ｓ１６３０）、Ｓｅｒｖｉｃｅ＿Ｓｔａｔｕｓの値が「−３」であると、上記サービスを終了する原因となったパラメータ（特定パラメータ）の値の変更を指示するメッセージと共に、その正常範囲を表す情報と、パラメータの値の入力欄とを示した再入力用画面（図３３参照）を、ディスプレイ１９ａに表示する（Ｓ１６３３）。
【０３９９】
そして、この再入力用画面の表示後、操作部１２から、上記パラメータの値が入力されると、記憶部１６が記憶する利用登録情報の該当パラメータの値を、その入力値に更新することにより、初回の利用登録時に登録されたパラメータの値に代えて、再入力用画面の表示後に入力された上記パラメータの値を用い、サービスの再登録を行うようにする。
【０４００】
このように、本実施例の複合機１０によれば、上記サービス提供の終了原因のパラメータの値を変更して、サービスの利用登録を行うことができるため、以前のパラメータ情報では、機能サーバ３０からサービスを受けることができない場合にも、利用者に煩わしいパラメータ情報の入力操作をさせることなく、特定パラメータの入力操作をさせるだけで、サービスの再登録を適切に実行することができる。
【０４０１】
また、本実施例では、パラメータ情報を構成するパラメータの値では、正常に、そのパラメータ情報に対応するサービスを提供することができない場合に、そのパラメータ情報に対応するサービスの終了条件が満足されたと判断し（Ｓ１５０８でＮｏ）、その原因となった上記パラメータ情報を構成するパラメータ（Ｎｕｍｐａｇｅｓ）の値の正常範囲を表す情報を送信するように、機能サーバ３０を構成し、複合機１０側では、Ｓ１６３３にて、図３３に示すように、終了条件が満足される原因となったパラメータの値の変更を指示するメッセージと共に、パラメータの値の正常範囲を、ディスプレイ１９ａに表示するようにしたので、利用者が不適切な値を、操作部１２を通じて入力するのを防止することができ、再登録を、円滑に行うことができる。
【０４０２】
また、本実施例では、操作部１２から削除指示が入力されると、記憶部１６が記憶する利用登録情報を消去するようにしたので、複合機１０を他の者に譲渡する際などに、利用登録情報が含む重要な情報等が漏洩するのを防止することができる。
【０４０３】
尚、本発明の通信装置及び画像形成装置は、上記実施例に限定されるものではなく、種々の態様を採ることができる。
例えば、上記実施例では、複合機１０側から定期的に問合せ信号を送信して、サービスを提供する準備が整ったか否かを問い合わせるシステムについて、本発明を適用した例を示したが、サービス提供装置側から、利用登録されたクライアント装置（複合機１０）に対し、一方的にサービスを提供するシステムに、本発明の概念を適用してもよい。
【図面の簡単な説明】
【０４０４】
【図１】本実施例の通信システム１の構成を表すブロック図である。
【図２】表示部１９に表示されるサービス選択用画面の例を表す説明図である。
【図３】トップのサービス定義情報の構成例を表す説明図である。
【図４】トップより下位のサービス定義情報２５の構成例を表す説明図である。
【図５】表示部１９に表示されるパラメータ入力用画面の例を表す説明図である。
【図６】サービスＩ／Ｆ情報３６の構成例を表す説明図である。
【図７】サービスＩ／Ｆ情報３６の構成例を表す説明図である。
【図８】複合機１０の制御部１１が行う複合機処理を表すフローチャートである。
【図９】ディレクトリサーバ２０の制御部２１が繰返し実行するディレクトリサーバ処理を表すフローチャートである。
【図１０】制御部１１が実行するサービス受信処理を表すフローチャートである。
【図１１】制御部１１が行う指定ジョブの起動処理を表すフローチャートである。
【図１２】機能サーバ３０の制御部３１が実行する機能サーバ処理を表すフローチャートである。
【図１３】制御部３１が実行するサービス制御情報処理を表すフローチャートである。
【図１４】制御部３１が実行する登録処理を表すフローチャートである。
【図１５】記憶部３３に記憶されたリクエストサービスＩＤ管理テーブルの構成を表す説明図（ａ）及び、定期問合せ返信管理テーブルの構成を表す説明図（ｂ）である。
【図１６】記憶部１６に記憶された定期問合せ管理テーブルの構成を表す説明図（ａ）及び利用登録情報の構成を表す説明図（ｂ，ｃ）である。
【図１７】制御部３１が行うサービス側ＵＩジョブを表すフローチャートである。
【図１８】制御部１１が実行するＵＩジョブを表すフローチャートである。
【図１９】制御部１１が行うパラメータ情報送信処理を表すフローチャートである。
【図２０】制御部１１が実行する定期問合せ処理を表すフローチャートである。
【図２１】制御部１１が行う統合問合せ情報生成処理を表すフローチャートである。
【図２２】統合問合せ情報の構成例を表す説明図である。
【図２３】制御部３１が実行する定期問合せ応答処理を表すフローチャートである。
【図２４】制御部３１が行うパラメータチェック処理を表すフローチャートである。
【図２５】制御部３１が行う統合返信情報生成処理を表すフローチャートである。
【図２６】制御部３１が実行する返信判断処理を表すフローチャートである。
【図２７】統合返信情報の構成例を表す説明図である。
【図２８】制御部３１が実行するブログ検索サービスを表すフローチャートである。
【図２９】制御部３１が行うニュース情報生成処理を表すフローチャートである。
【図３０】制御部３１が行うタイムアウト巡回処理を表すフローチャートである。
【図３１】制御部１１が行う統合返信情報受信処理を表すフローチャートである。
【図３２】制御部１１が行う終了サービス分析処理を表すフローチャートである。
【図３３】表示部１９に表示されるパラメータ再入力用画面を表す説明図である。
【図３４】制御部３１が行う定期サービス提供処理を表すフローチャートである。
【図３５】制御部３１が行うサービス側印刷ジョブを表すフローチャートである。
【図３６】制御部１１が実行する出力ジョブのフローチャートである。
【図３７】制御部１１が行う利用登録情報削除処理を表すフローチャートである。
【符号の説明】
【０４０５】
１…通信システム、２，３，４…ルータ、１０…複合機、１１…制御部、１２…操作部、１３…読取部（スキャナ）、１４…記録部（プリンタ）、１５…通信部、１６…記憶部、１７…音入力部、１８…音出力部、１９…表示部、１９ａ…ディスプレイ、２０…ディレクトリサーバ、２１…制御部、２２…通信部、２３…記憶部、２４…サービス定義情報記憶部、２５…サービス定義情報、３０…機能サーバ、３１…制御部、３２…通信部、３３…記憶部、３４…サービスＩ／Ｆ情報記憶部、３５…サービスソフト記憶部、３６…サービスＩ／Ｆ情報、３７…サービスソフトウェア、４０…ＤＮＳサーバ、ＮＴ…ネットワーク
【図１】
2006134109.tif 000008
【図２】
2006134109.tif 000009
【図３】
2006134109.tif 000010
【図４】
2006134109.tif 000011
【図５】
2006134109.tif 000012
【図６】
2006134109.tif 000013
【図７】
2006134109.tif 000014
【図８】
2006134109.tif 000015
【図９】
2006134109.tif 000016
【図１０】
2006134109.tif 000017
【図１１】
2006134109.tif 000018
【図１２】
2006134109.tif 000019
【図１３】
2006134109.tif 000020
【図１４】
2006134109.tif 000021
【図１５】
2006134109.tif 000022
【図１６】
2006134109.tif 000023
【図１７】
2006134109.tif 000024
【図１８】
2006134109.tif 000025
【図１９】
2006134109.tif 000026
【図２０】
2006134109.tif 000027
【図２１】
2006134109.tif 000028
【図２２】
2006134109.tif 000029
【図２３】
2006134109.tif 000030
【図２４】
2006134109.tif 000031
【図２５】
2006134109.tif 000032
【図２６】
2006134109.tif 000033
【図２７】
2006134109.tif 000034
【図２８】
2006134109.tif 000035
【図２９】
2006134109.tif 000036
【図３０】
2006134109.tif 000037
【図３１】
2006134109.tif 000038
【図３２】
2006134109.tif 000039
【図３３】
2006134109.tif 000040
【図３４】
2006134109.tif 000041
【図３５】
2006134109.tif 000042
【図３６】
2006134109.tif 000043
【図３７】
2006134109.tif 000044