JP4305367B2 - 通信装置及び画像形成装置 - Google Patents

通信装置及び画像形成装置 Download PDF

Info

Publication number
JP4305367B2
JP4305367B2 JP2004322941A JP2004322941A JP4305367B2 JP 4305367 B2 JP4305367 B2 JP 4305367B2 JP 2004322941 A JP2004322941 A JP 2004322941A JP 2004322941 A JP2004322941 A JP 2004322941A JP 4305367 B2 JP4305367 B2 JP 4305367B2
Authority
JP
Japan
Prior art keywords
service
information
registration
unit
parameter
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2004322941A
Other languages
English (en)
Other versions
JP2006134109A (ja
Inventor
一磨 青木
哲 柳
雅俊 小久保
誠 松田
雅史 宮澤
清孝 大原
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Brother Industries Ltd
Original Assignee
Brother Industries Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Brother Industries Ltd filed Critical Brother Industries Ltd
Priority to JP2004322941A priority Critical patent/JP4305367B2/ja
Priority to US11/264,751 priority patent/US7865940B2/en
Priority to EP05256880A priority patent/EP1655927A1/en
Priority to CNB2005101176257A priority patent/CN100465942C/zh
Publication of JP2006134109A publication Critical patent/JP2006134109A/ja
Application granted granted Critical
Publication of JP4305367B2 publication Critical patent/JP4305367B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/14—Charging, metering or billing arrangements for data wireline or wireless communications
    • H04L12/1453—Methods or systems for payment or settlement of the charges for data transmission involving significant interaction with the data transmission network
    • H04L12/1467—Methods or systems for payment or settlement of the charges for data transmission involving significant interaction with the data transmission network involving prepayment
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/2866—Architectures; Arrangements
    • H04L67/30—Profiles
    • H04L67/303—Terminal profiles
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/2866—Architectures; Arrangements
    • H04L67/30—Profiles
    • H04L67/306—User profiles
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • H04L67/61—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources taking into account QoS or priority requirements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Facsimiles In General (AREA)
  • Information Transfer Between Computers (AREA)
  • Telephonic Communication Services (AREA)

Description

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

Claims (12)

  1. 外部装置に提供するサービスの内容を決定付ける一つ又は複数のパラメータからなる設定情報を、サービス提供対象の外部装置の識別情報と関連付けて、複数個記憶可能なデータベースと、
    外部装置からサービスの提供を受けるための登録を要求する旨の登録要求信号を受信すると、登録要求元の前記外部装置から、この外部装置が受けるサービスについての前記設定情報を取得し、前記取得した設定情報を、前記サービス提供対象である前記登録要求元の外部装置の前記識別情報と関連付けて、前記データベースに登録する登録手段と、
    前記データベースに登録された各設定情報に従うサービスを、前記サービス提供対象の外部装置に対し、通信によって提供するサービス提供手段と、
    前記データベースに登録された各設定情報に対応するサービスの終了条件が満足されたか否かを、前記データベースに登録された設定情報毎に判断する終了判断手段と、
    前記終了判断手段により終了条件が満足されたと判断されたサービスの前記設定情報を、前記データベースから削除して、そのサービスの提供を終了するサービス終了手段と、
    を備えるサービス提供装置、と通信可能に構成された通信装置であって、
    利用者が操作可能な操作手段から登録を指示する信号が入力されると、前記サービス提供装置に向けて前記登録要求信号を送信すると共に、当該通信装置が前記サービス提供装置から受けるサービスについての前記設定情報を、前記操作手段を通じて利用者から取得し、この設定情報を、前記サービス提供装置に向けて送信して、前記サービスの利用登録を行う利用登録手段と、
    前記利用登録手段が前記設定情報を前記サービス提供装置に向けて送信する際に、前記送信対象の設定情報をコピーして、当該通信装置が備える記憶手段に記憶させる設定情報記録手段と、
    前記利用登録手段の動作によって前記サービス提供装置から提供されるサービスを受けて、前記サービスを利用した所定の機能を実現する機能実行手段と、
    前記利用登録手段によって利用登録されたサービスであって、前記サービス提供装置にて、前記データベースに登録された設定情報に対応するサービスの終了条件が満足されることによって、提供が終了された当該通信装置向けのサービスを検知する検知手段と、
    前記検知手段により前記提供が終了されたサービスが検知されると、前記記憶手段が記憶する前記提供が終了されたサービスに対応する前記コピーされた設定情報を読み出し、前記読み出した設定情報を、前記登録要求信号と共に、前記サービス提供装置に送信することにより、前記提供が終了されたサービスの利用登録を再度行う再登録手段と、
    を備えることを特徴とする通信装置。
  2. 前記サービス終了手段は、前記終了条件が満足されたサービスの提供を終了する際、終了対象のサービスを受けていた外部装置に対し、前記サービスの終了を示す終了通知情報を送信する構成にされ、
    前記検知手段は、前記サービス提供装置から前記終了通知情報を受信すると、前記サービス提供装置にて提供が終了された当該通信装置向けのサービスを検知することを特徴とする請求項１記載の通信装置。
  3. 前記再登録手段は、
    前記検知手段により検知された前記提供が終了されたサービスについての利用登録が必要か否かを判断する再登録要否判断手段、
    を有し、前記提供が終了されたサービスのうち、前記再登録要否判断手段により利用登録が必要であると判断されたサービスについての利用登録を選択的に実行し、前記再登録要否判断手段により利用登録が不要であると判断されたサービスについては、利用登録を実行しない構成にされていることを特徴とする請求項１又は請求項２記載の通信装置。
  4. 前記再登録要否判断手段は、前記検知手段により検知された前記提供が終了されたサービスについて、前記提供が終了された原因を判定し、その判定結果に従って、前記提供が終了されたサービスについての利用登録が必要か否かを判断することを特徴とする請求項３記載の通信装置。
  5. 前記サービス終了手段は、前記終了条件が満足されたサービスの提供を終了する際、終了対象のサービスを受けていた外部装置に対し、前記終了対象のサービスについての再登録の受付可否を表す情報を送信する構成にされ、
    前記再登録要否判断手段は、前記サービス提供装置から受信した前記再登録の受付可否を表す情報に従って、前記提供が終了されたサービスについての利用登録が必要か否かを判断することを特徴とする請求項３記載の通信装置。
  6. 前記検知手段により前記提供が終了されたサービスが検知されると、利用者の操作により前記操作手段から入力された再登録の許可／不許可を表す情報に従って、前記提供が終了されたサービスが、再登録を許可されたサービスであるか否かを判断する許可判断手段と、
    前記許可判断手段により、前記提供が終了されたサービスが、再登録を許可されたサービスではないと判断されると、再登録を許可されていない前記サービスについての前記再登録手段による利用登録を禁止する再登録禁止手段と、
    を備えることを特徴とする請求項１〜請求項５のいずれかに記載の通信装置。
  7. 前記利用登録手段が前記設定情報を前記操作手段を通じて取得する際に、利用者に対して、前記設定情報に対応するサービスの再登録を許可するか否かを問合せ、これに応答して前記操作手段から入力される再登録の許可／不許可を表す情報を、前記利用登録されるサービス毎に、前記記憶手段に記憶させる許可情報記録手段、
    を備え、
    前記許可判断手段は、前記記憶手段が記憶する前記提供が終了されたサービスに対応する前記再登録の許可／不許可を表す情報に従って、前記提供が終了されたサービスが、再登録を許可されたサービスであるか否かを判断することを特徴とする請求項６記載の通信装置。
  8. 前記検知手段による検知後、前記再登録手段により利用登録されるサービスの設定情報を構成する特定パラメータの値の変更を指示するメッセージを、当該通信装置が備える表示手段に表示させるメッセージ表示手段と、
    前記メッセージ表示手段の動作後、前記操作手段から、前記特定パラメータの値が入力されると、既に前記記憶手段が記憶する前記再登録手段により利用登録されるサービスの特定パラメータの値に代えて、前記メッセージ表示手段の動作後に入力された前記特定パラメータの値を用いて、前記サービスの利用登録を行うように前記再登録手段を制御する登録内容変更手段と、
    を備えることを特徴とする請求項１〜請求項７のいずれかに記載の通信装置。
  9. 前記終了判断手段は、前記各設定情報に対応するサービスについて、予め定められた複数種の事象のいずれかが生じると、そのサービスの終了条件が満足されたと判断し、
    前記サービス終了手段は、前記終了条件が満足されたサービスの提供を終了する際、終了対象のサービスを受けていた外部装置に対し、前記サービスの提供を終了した原因を表す情報を送信する構成にされ、
    当該通信装置は、
    前記サービス提供装置から受信した前記サービスの提供を終了した原因を表す情報に基づいて、前記特定パラメータを決定するパラメータ決定手段、
    を備えることを特徴とする請求項８記載の通信装置。
  10. 前記終了判断手段は、前記設定情報を構成するパラメータの値では、正常に、前記設定情報に対応するサービスを提供することができない場合に、その設定情報に対応するサービスの終了条件が満足されたと判断し、
    前記サービス終了手段は、前記終了条件が満足されたサービスの提供を終了する際、終了対象のサービスを受けていた外部装置に対し、前記終了条件が満足される原因となった前記設定情報を構成するパラメータの値の正常な範囲を表す情報を送信し、
    前記メッセージ表示手段は、前記特定パラメータの値の変更を指示するメッセージとして、前記終了条件が満足される原因となったパラメータの値の変更を指示するメッセージを前記表示手段に表示させると共に、前記サービス提供装置から受信した前記パラメータの値の正常な範囲を表す情報に基づき、前記特定パラメータの値の正常な範囲を、前記表示手段に表示させることを特徴とする請求項８記載の通信装置。
  11. 前記操作手段から削除指示信号が入力されると、前記記憶手段が記憶する設定情報を消去する消去手段、を備えることを特徴とする請求項１〜請求項１０のいずれかに記載の通信装置。
  12. 請求項１〜請求項１１のいずれかに記載の通信装置と、
    記録媒体に画像を形成可能な画像形成手段と、
    を備え、前記機能実行手段は、前記サービスを利用した所定機能を、前記画像形成手段を用いて実現する構成にされていることを特徴とする画像形成装置。
JP2004322941A 2004-11-05 2004-11-05 通信装置及び画像形成装置 Expired - Fee Related JP4305367B2 (ja)

Priority Applications (4)

Application Number Priority Date Filing Date Title
JP2004322941A JP4305367B2 (ja) 2004-11-05 2004-11-05 通信装置及び画像形成装置
US11/264,751 US7865940B2 (en) 2004-11-05 2005-11-02 Service providing system and device for receiving service
EP05256880A EP1655927A1 (en) 2004-11-05 2005-11-07 Service providing system and device for receiving service
CNB2005101176257A CN100465942C (zh) 2004-11-05 2005-11-07 服务提供系统和用于接收服务的设备

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2004322941A JP4305367B2 (ja) 2004-11-05 2004-11-05 通信装置及び画像形成装置

Publications (2)

Publication Number Publication Date
JP2006134109A JP2006134109A (ja) 2006-05-25
JP4305367B2 true JP4305367B2 (ja) 2009-07-29

Family

ID=35892240

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2004322941A Expired - Fee Related JP4305367B2 (ja) 2004-11-05 2004-11-05 通信装置及び画像形成装置

Country Status (4)

Country Link
US (1) US7865940B2 (ja)
EP (1) EP1655927A1 (ja)
JP (1) JP4305367B2 (ja)
CN (1) CN100465942C (ja)

Families Citing this family (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8375088B2 (en) * 2006-08-11 2013-02-12 At&T Intellectual Property I, L.P. Customizable personal directory services
US8335825B2 (en) * 2006-08-11 2012-12-18 At&T Intellectual Property I, L.P. Personal directory services with presence indication
US8332474B2 (en) 2006-08-11 2012-12-11 At&T Intellectual Property I, L.P. Personal directory services with directed communication
JP2008123298A (ja) * 2006-11-13 2008-05-29 Canon Inc 情報処理方法及びシステム
US20090009789A1 (en) * 2007-07-05 2009-01-08 Fumiyuki Yoshida Image forming apparatus, document management method, and computer program product
US9182932B2 (en) * 2007-11-05 2015-11-10 Hewlett-Packard Development Company, L.P. Systems and methods for printing content associated with a website
US9152357B2 (en) 2011-02-23 2015-10-06 Hewlett-Packard Development Company, L.P. Method and system for providing print content to a client
US9137394B2 (en) 2011-04-13 2015-09-15 Hewlett-Packard Development Company, L.P. Systems and methods for obtaining a resource
CN102279773B (zh) * 2011-07-28 2014-07-09 迈普通信技术股份有限公司 一种双向远程调用的方法和系统
US9489161B2 (en) 2011-10-25 2016-11-08 Hewlett-Packard Development Company, L.P. Automatic selection of web page objects for printing
JP6098160B2 (ja) * 2012-03-22 2017-03-22 株式会社リコー 出力システム、画像処理装置及び出力方法
US9773214B2 (en) 2012-08-06 2017-09-26 Hewlett-Packard Development Company, L.P. Content feed printing
JP6192339B2 (ja) * 2013-04-08 2017-09-06 キヤノン株式会社 文書管理システム、管理装置、文書管理方法およびコンピュータプログラム
CN103544016A (zh) * 2013-10-28 2014-01-29 珠海许继芝电网自动化有限公司 一种基于java反射技术的服务注册配置方法及系统
US10082992B2 (en) 2014-12-22 2018-09-25 Hewlett-Packard Development Company, L.P. Providing a print-ready document
EP3366056B1 (en) * 2015-10-20 2019-06-05 Telefonaktiebolaget LM Ericsson (publ) User profiling prevention in personal area network communication
JP6976061B2 (ja) * 2017-02-09 2021-12-01 株式会社東芝 ジョブ装置、端末、認証関連情報の回復方法
JP6977673B2 (ja) * 2018-06-20 2021-12-08 沖電気工業株式会社 画像形成システム及び画像形成方法
US10769092B2 (en) * 2018-12-20 2020-09-08 Dell Products, L.P. Apparatus and method for reducing latency of input/output transactions in an information handling system using no-response commands
JP2023077861A (ja) * 2021-11-25 2023-06-06 京セラドキュメントソリューションズ株式会社 情報処理装置

Family Cites Families (23)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5946457A (en) * 1995-12-25 1999-08-31 Sharp Kabushiki Kaisha Image forming system having transfer device for communicating between image forming apparatus and image processing apparatus
JP3441038B2 (ja) 1995-12-25 2003-08-25 シャープ株式会社 画像形成システム
US5909602A (en) * 1996-09-30 1999-06-01 Sharp Kabushiki Kaisha Image forming apparatus having a specimen image judging section and an image information suitability judging section
JPH1146277A (ja) 1997-07-29 1999-02-16 Ricoh Co Ltd ファクシミリ装置を含むシステム
FI107859B (fi) 1998-03-23 2001-10-15 Nokia Networks Oy Tilauspalvelut matkaviestinjärjestelmässä
JP2001092781A (ja) 1999-09-27 2001-04-06 Fujitsu Ltd ユーザセッション自動復旧システム
US6564055B1 (en) * 2000-01-21 2003-05-13 Telecommunication Systems, Inc. Intelligent roaming database (IRDB) updating
EP1180895A1 (en) * 2000-08-18 2002-02-20 Lucent Technologies Inc. Method for providing alternative prepaid billing service
JP2002109079A (ja) 2000-09-29 2002-04-12 Casio Comput Co Ltd 教育支援方法および支援サーバ
JP2002123433A (ja) 2000-10-12 2002-04-26 Canon Inc サービス提供システム、方法及び装置、端末装置並びに記憶媒体
CA2427266C (en) * 2000-11-01 2005-03-29 Snapnames.Com, Inc. Registry-integrated internet domain name acquisition system
JP4482641B2 (ja) 2000-12-06 2010-06-16 中野 拓帆 ニュース配信システム、ニュース配信方法
JP3502048B2 (ja) * 2001-02-02 2004-03-02 パナソニック コミュニケーションズ株式会社 画情報送信システム、スキャナ装置およびユーザー端末装置、並びに画情報送信方法
JP2002245261A (ja) 2001-02-15 2002-08-30 Srp:Kk 移動通信体への音声ニュースデジタルデータ配信方法及び配信システム
JP2002312670A (ja) 2001-04-11 2002-10-25 Emiko Tsuchiya ニュース提供支援装置及びニュース提供方法
JP2003006223A (ja) 2001-06-25 2003-01-10 Sony Corp 情報提供システムおよび方法、受信装置および方法、送信装置および方法、記録媒体、並びにプログラム
US20030027549A1 (en) * 2001-07-30 2003-02-06 Msafe Inc. Prepaid communication system and method
JP2003263452A (ja) 2002-03-07 2003-09-19 Nippon Telegraph & Telephone East Corp 情報配信システム、情報配信方法、コンピュータプログラムおよびそのプログラムを記録した記録媒体
JP2003288336A (ja) * 2002-03-28 2003-10-10 Brother Ind Ltd 特定機能代行システム、及び、電子機器、記憶媒体
JP3772817B2 (ja) * 2002-09-25 2006-05-10 ブラザー工業株式会社 通信システム、インターネット端末、電話端末および端末制御プログラム
JP2004220170A (ja) 2003-01-10 2004-08-05 Olympus Corp 機器情報取得プログラム、そのプログラムを記憶した記憶媒体、機器情報取得装置、及び機器情報取得方法
JP2004220231A (ja) 2003-01-14 2004-08-05 Nec Corp サービス提供システム
US20050013423A1 (en) * 2003-07-18 2005-01-20 Eversen Carol P. Telecommunication method and apparatus with provisions to exceed usage limit

Also Published As

Publication number Publication date
EP1655927A1 (en) 2006-05-10
JP2006134109A (ja) 2006-05-25
US20060123114A1 (en) 2006-06-08
US7865940B2 (en) 2011-01-04
CN1783058A (zh) 2006-06-07
CN100465942C (zh) 2009-03-04

Similar Documents

Publication Publication Date Title
JP4305367B2 (ja) 通信装置及び画像形成装置
EP1058417B1 (en) Apparatus for searching a device on a network
JP5540644B2 (ja) 印刷システム、印刷方法
EP3203370A1 (en) System, apparatus and method for easy access to casual or guest printing
JP5841380B2 (ja) 管理サーバ及びその処理方法
EP0893760A2 (en) Context-sensitive document transactions
JP2015108940A (ja) 情報処理システム、情報処理装置、情報処理方法及びプログラム
JP6971597B2 (ja) 情報処理装置、表示制御方法、及びプログラム
JP2009020855A (ja) ジョブログ管理システム、ジョブログ管理方法、及びコンピュータプログラム
JP2013196263A (ja) 印刷システム、印刷装置、情報処理装置、印刷処理方法、およびプログラム
JP5518155B2 (ja) サーバ装置
JP4238817B2 (ja) 通信システム及び通信装置
JP4799581B2 (ja) ページカスタマイズサーバ、ページカスタマイズプログラムおよびページカスタマイズ方法
CN107111711B (zh) 信息处理系统、图像处理装置、信息处理方法和记录介质
US8125668B2 (en) Information processing device, image processing device, job processing method, and storage medium
JP2009262376A (ja) 印刷制御装置、印刷制御方法及びプログラム
JP6947068B2 (ja) 情報処理システム、端末装置、および画像処理装置
JP6226001B2 (ja) 利用制御システム及び利用制御方法
JP2002269022A (ja) ソフトウエア設定システム
JP5249477B2 (ja) プリンタ、システム、及びそれらの制御方法、プログラム
JP2011244222A (ja) データ送信装置
JP6575577B2 (ja) 利用制御システム及び利用制御方法
JP4909432B2 (ja) コンテンツマネジメントシステム
JP4239951B2 (ja) サービス提供システム及びプログラム
JP7359253B2 (ja) 情報処理装置およびプログラム

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20070530

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20080501

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20080507

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20081007

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20081127

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20090106

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20090407

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20090420

R150 Certificate of patent or registration of utility model

Ref document number: 4305367

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20120515

Year of fee payment: 3

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20120515

Year of fee payment: 3

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130515

Year of fee payment: 4

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130515

Year of fee payment: 4

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20140515

Year of fee payment: 5

LAPS Cancellation because of no payment of annual fees