以下、本発明の実施例について、図面と共に説明する。図1は、本発明が適用された通信システム1の構成を表すブロック図である。
本実施例の通信システム1は、複数のディジタル複合機(以下、単に「複合機」とする)10と、ディレクトリサーバ20と、機能サーバ30とを備え、これらは、広域ネットワークNT(具体的にはインターネット)を介して双方向通信可能に接続されている。具体的に、複合機10、ディレクトリサーバ20及び機能サーバ30は、夫々ルータ2,3,4を介して、広域ネットワークNTと接続されている。
ルータ2は、複合機10等から構成される下位ネットワーク(サブネット)のノードと、この下位ネットワークより外部の広域ネットワークNTのノードとの間のデータ通信を中継するものである。このルータ2は、外部の広域ネットワークNT内の装置から、下位ネットワーク内の装置(複合機10等)へ送信されてくるパケットのうち、下位ネットワーク内から外部への要求(リクエスト)に対する返答(レスポンス)を通過させ、それ以外のパケットを遮断する構成にされており、広域ネットワークNTから複合機10に対する不正なアクセスを防止するためのファイアウォールとして機能する。
複合機10は、電話(音声通信)機能、スキャナ機能、プリンタ機能、コピー機能、ファクシミリ機能等を有する多機能装置として構成されており、上記機能を用いた複数種の入出力機能を、機能サーバ30から利用可能に構成されている。
機能サーバ30は、複合機10からの要求に応じて、上記複数種のサービスの提供に必要な処理(後述する定期サービス提供処理(図29参照)等)を実行し、要求元の複合機10に対してサービスを提供する。即ち、複合機10は、機能サーバ30と通信して、上記複数種のサービスを受けるための処理(後述するサービス受信処理や出力ジョブ等)を実行し、機能サーバ30からのサービスを受ける。例えば、複合機10は、サービスの提供にかかるデータ通信で、機能サーバ30から得た印刷データを、プリンタ機能(記録部14)を利用して、印刷出力する。
また、ディレクトリサーバ20は、各複合機10が利用可能なサービス(機能サーバ30が提供可能なサービス)についての情報を、複合機10へ提供可能に構成されている。
続いて、複合機10、ディレクトリサーバ20及び機能サーバ30の詳細構成を説明する。複合機10は、制御部11、操作部12、読取部13、記録部14、通信部15、記憶部16、音入力部17、音出力部18、及び、表示部19を備える。制御部11は、図示しない周知のCPU、ROM、RAM等を備え、複合機10を構成する各部を統括制御する。尚、ROMには、後述する各種処理をCPUに実行させるためのプログラムが記憶されている。
操作部12は、利用者が操作可能な複数のキーを備え(図示せず)、これらのキーを介して、利用者の操作情報を取得し、この操作情報(各種指令等)を制御部11に入力する。また、読取部(スキャナ)13は、原稿に記録(例えば印刷)された画像を読み取り、この画像を表す画像データを生成する構成にされている。その他、記録部(プリンタ)14は、印刷データに基づく画像を、用紙等のシート状記録媒体に形成(印刷)する構成にされ、通信デバイスとしての通信部15は、広域ネットワークNTを介して、ディレクトリサーバ20や機能サーバ30等のノードとデータを送受信するための電気的な処理を行う構成にされている。
また、記憶部16は、図示しない不揮発性RAMを有し、この不揮発性RAMにデータを記憶する構成にされている。その他、音入力部17は、複合機10が備える図示しないハンドセットに設けられたマイクから集音し、その音を表す音データ(PCMデータ)を生成する構成にされ、音出力部18は、音データ(PCMデータ)に基づく音声を、ハンドセットに設けられたスピーカ、又は、複合機10本体に設けられた図示しないスピーカから出力する構成にされている。また、表示部19は、ディスプレイ19aを備え、このディスプレイ19aを介して、利用者に対する情報の表示(図2参照)を行う構成にされている。
次に、ディレクトリサーバ20について説明する。ディレクトリサーバ20は、制御部21、通信部22、及び、記憶部23を備える。制御部21は、図示しない周知のCPU、ROM、RAM等を備え、ディレクトリサーバ20を構成する各部を統括制御する。尚、ROMには、後述する処理をCPUに実行させるためのプログラムが記憶されている。
通信部22は、広域ネットワークNTを介してデータを送受信するための電気的な処理を行う構成にされており、記憶部23は、図示しないハードディスクを備え、このハードディスクにデータを記憶する構成にされている。具体的に、記憶部23には、サービス定義情報25を記憶するためのサービス定義情報記憶部24が設けられている。
サービス定義情報25は、機能サーバ30が実行可能なサービスについての情報(サービスの種類やサービス要求先のURL情報等)を、複合機10へ提供するためのものである。具体的に、複合機10の制御部11は、利用者が操作部12を操作することにより、操作部12からサービス選択用画面の表示指令が入力されると、通信部15を通じて、ディレクトリサーバ20からサービス定義情報25を取得する。また、サービス定義情報25を取得すると、制御部11は、そのサービス定義情報25に基づいて、表示部19のディスプレイ19aにサービスの種類を示すサービス選択用画面(図2参照)を表示し、複合機10の利用者にサービスの選択を促す。
ディレクトリサーバ20において、機能サーバ30が実行可能なサービスは、「印刷サービス」、「コピー応用サービス」、「情報提供サービス」等、複数のカテゴリに分類管理されており、サービス選択用画面においては、まず、上記複数のカテゴリが表示される(図2(a))。また、利用者が操作部12を操作することにより、上記複数のカテゴリのいずれかが選択されると、次に、選択されたカテゴリに属するサービスが表示される(図2(b))。
このような処理を実現するため、サービス定義情報記憶部24には、カテゴリの選択を促すサービス選択用画面(図2(a))に対応するサービス定義情報25(以下「トップのサービス定義情報25」という。)と、各カテゴリに含まれるサービスの選択を促すサービス選択用画面(図2(b))に対応するサービス定義情報25とが記憶されている。
図3及び図4は、サービス定義情報25の構成例を表す説明図である。具体的に、図3は、トップのサービス定義情報25の構成例を表す図であり、図4は、上記カテゴリの一つである「情報提供サービス」についてのサービス定義情報25の構成例を表す図である。
図3及び図4に示すように、サービス定義情報25は、XML(eXtensible Markup Language)によって記述されている。尚、ここで用いられる各タグの定義は、表1に示すとおりである。
トップのサービス定義情報25(図3)が複合機10で受信されると、ディスプレイ19aには、図2(a)に示すサービス選択用画面が表示される。具体的には、タイトル(Title)として「ディレクトリサービス」の文字がディスプレイ19aにおける上部に表示され、その下には、選択可能なカテゴリを表す項目(Link_Title)として、「印刷サービス」、「コピー応用サービス」及び「情報提供サービス」の文字が表示される。
各項目には、カテゴリに対応するサービス定義情報25のIDがそれぞれ対応づけられており(Link_Location)、図2(a)に示す状態で、操作部12から項目の選択を確定する信号(操作情報)が入力されると、制御部11は、選択が確定された項目に対応するIDのサービス定義情報25に基づき、選択されたカテゴリに対応するサービス選択用画面を、表示部19のディスプレイ19aに表示する。
例えば、図2(a)に示すサービス選択用画面で「情報提供サービス」が選択されると、ディスプレイ19aには、図2(b)に示す情報提供サービスに対応するサービス選択用画面が表示される。具体的には、タイトル(Title)として「情報提供サービス」の文字がディスプレイ19aにおける上部に表示され、その下には、選択可能なサービスを表す項目(Link_Title)として、「ブログ検索サービス」、「ニュース提供サービス」、「X種情報提供サービス」、及び、「Y種情報提供サービス」の文字が表示される。尚、ディスプレイ19aのサイズの都合上、すべての項目を一度に表示することができない場合には、サービス選択用画面をスクロール可能に構成し、一部の項目を表示する。
各項目には、サービスを呼び出すためのURL情報がそれぞれ対応付けられており(Link_Location)、利用者が操作部12を操作することにより、項目の選択が確定されると、制御部11は、通信部15を介して、その項目に対応するURL先にアクセスし、URL先のサーバ装置(機能サーバ30)が提供するサービスを受ける。尚、この際、複合機10は、一旦、DNSサーバ40にアクセスして、URL先のIP(インターネットプロトコル)アドレスを取得し、これに基づきURL先のIPアドレスを把握して、URL先にアクセスする。
次に、機能サーバ30について説明する。機能サーバ30は、制御部31、通信部32、及び、記憶部33を備える。制御部31は、図示しない周知のCPU、ROM、RAM等を備えており、機能サーバ30を構成する各部を統括制御する。尚、ROMには、後述する各種処理をCPUに実行させるためのプログラムが記憶されている。
通信部32は、広域ネットワークNTを介してデータを送受信するための電気的な処理を行う構成にされており、記憶部33は、図示しないハードディスクを備え、このハードディスクに、各種データを記憶する構成にされている。具体的に、記憶部33には、サービスI/F(インタフェース)情報36を記憶するためのサービスI/F情報記憶部34や、サービスソフトウェア37を記憶するためのサービスソフト記憶部35等が設けられている。
サービスソフトウェア37は、複数種のサービスを実行するためのプログラムである。サービスソフト記憶部35には、複数種のサービスソフトウェア37が記憶されており、制御部31は、各サービスソフトウェア37を実行することにより、各サービスソフトウェア37に対応したサービスを、クライアント装置としての複合機10に提供する。
また、サービスI/F情報36は、サービスを実行する際に必要なパラメータ情報を複合機10へ要求するためのものである。サービスI/F情報記憶部34には、機能サーバ30が実行可能な複数種のサービスのそれぞれに対応する複数種類のサービスI/F情報36が記憶されている。
複合機10は、このサービスI/F情報36を受信すると、受信したサービスI/F情報36に基づいて、設定すべきパラメータを示すパラメータ入力用画面(図5参照)をディスプレイ19aに表示し、複合機10の利用者にパラメータの設定を促す。
ここで、サービスI/F情報36の具体例について説明する。図6及び図7は、サービスI/F情報36の構成例を表す説明図である。具体的に、図6は、特定のブログサイトに掲載された新しい投稿の中から、利用者が指定したキーワードを含む投稿を検索し、その投稿内容を表す印刷データを生成して複合機10の記録部14に印刷させるというサービス(ブログ検索サービス)に対応するサービスI/F情報36の構成例を表す図である。また、図7は、特定のデータベースが有するニュースデータの中から、利用者が指定した地域のローカルニュースデータを取得し、この取得情報を表す印刷データを生成して複合機10の記録部14に印刷させるというサービス(ローカルニュース提供サービス)に対応するサービスI/F情報36の構成例を表す図である。
図6及び図7に示すように、サービスI/F情報36は、上述したサービス定義情報25と同じマークアップ言語により記述されており、図6及び図7で用いられている各タグの定義は表2に示すとおりである。尚、表2における基本データは、上述したサービス定義情報25の基本データ(表1)と同じである。
図6に示すサービスI/F情報36が複合機10側で受信されると、複合機10が備えるディスプレイ19aには、図5(a)に示すパラメータ入力用画面が表示される。具体的には、表示用タイトル(Title)として「ブログ検索サービス」の文字がディスプレイ19aにおける上部位置に表示され、その下には、入力項目(Disp_Name)として「検索キー1」の文字が表示され、更にその下には、入力項目「検索キー1」に対応する検索キーの入力欄が表示される。また、この入力欄には、利用者が操作部12を通じて入力した文字が表示される。
尚、「ブログ検索サービス」に関する入力項目(Disp_Name)としては、「検索キー1」に加え、「検索キー2」及び「検索キー3」が存在するが(図6参照)、ディスプレイ19aの大きさの都合上、すべての入力項目を一度にディスプレイ19aに表示することができない。
このため、複合機10では、ディスプレイ19aにおける入力項目表示位置の左右両側に左右の矢印(三角印)を表示して、パラメータ入力用画面を左右にスクロール可能に構成する。この状態で、操作部12を通じて、スクロールの指令が入力されると、ディスプレイ19aには、その指令に従って、他の入力項目に対応したパラメータ入力用画面が表示される。尚、入力項目「検索キー2」及び「検索キー3」のパラメータ入力用画面の表示形態は、入力項目「検索キー1」と基本的に同様である。
また、図7に示すサービスI/F情報36が複合機10で受信されると、複合機10が備えるディスプレイ19aには、図5(b)に示すパラメータ入力用画面が表示される。
図5(b)に示すパラメータ入力用画面では、表示用タイトル(Title)としての「ローカルニュース提供サービス」の文字の下に、入力項目(Disp_Name)として「地域」の文字が表示され、更にその下には、入力項目「地域」について選択可能なパラメータの値を表す項目(Disp_Select)として、「北海道」、「関東」、「東海」等の地域を表す文字が表示される。尚、ディスプレイ19aに表示できない項目がある場合には、パラメータ入力用画面を、上下方向にスクロール可能に構成する。
また、「ローカルニュース提供サービス」に関する入力項目(Disp_Name)としては、「地域」に加え、「プリペイドカード番号」及び「情報を収める紙の枚数」が存在するが(図7参照)、ディスプレイ19aの大きさの都合上、すべての入力項目を一度にディスプレイ19aに表示することができない。
このため、複合機10では、「ブログ検索サービス」と同様、ディスプレイ19aにおける入力項目表示位置の左右両側に左右の矢印(三角印)を表示して、パラメータ入力用画面を左右にスクロール可能に構成する。この状態で、操作部12を通じて、スクロールの指令が入力されると、ディスプレイ19aには、その指令に従って、他の入力項目に対応したパラメータ入力用画面が表示される。具体的に、操作部12を通じて右方向へのスクロールを指示する指令が入力されると、ディスプレイ19aには、図5(c)に示すように、入力項目「プリペイドカード番号」についてのパラメータ入力用画面が表示される。
尚、入力項目「プリペイドカード番号」のパラメータ入力用画面では、プリペイドカード番号を入力するための入力欄が表示され、入力欄には、利用者が操作部12を通じて入力した文字(プリペイドカード番号)が表示される。その他、図示しないが入力項目「情報を収める紙の枚数」のパラメータ入力用画面には、ニュースを印刷する際の紙の枚数を入力するための入力欄が表示される。
また、各パラメータ入力用画面において入力されたパラメータの値(入力欄に入力された文字列も含む)は、利用者の操作により操作部12を通じて、確定信号が入力されると、これらのパラメータの値を受けて動作するURL(Action)先のプログラム(機能サーバ30が有するプログラム)へ送信される。
次に、複合機10、ディレクトリサーバ20及び機能サーバ30間で行われる通信について説明する。本実施例では、複合機10、ディレクトリサーバ20及び機能サーバ30が互いにデータを送受信するための通信プロトコルとして、HTTP1.1(HTTP:HyperText Transfer Protocol)が採用されており、複合機10、ディレクトリサーバ20及び機能サーバ30は、HTTPリクエスト及びレスポンスに伴わせたメッセージにより、互いに指令及び指令に対する返答を行う。
指令は、複合機10から各サーバ20,30に対する指令(サーバ指令)と、各サーバ20,30から複合機10に対する指令(複合機指令)とに分類されるが、いずれの指令にかかる通信も、複合機10が常にHTTP通信のクライアント(HTTPリクエストを送信する側)となるようにしている。これにより、ルータ2が介在していても、各サーバ20,30から複合機10への指令が遮断されてしまうことはない。
具体的に、複合機10は、HTTPリクエストのPOSTコマンドに伴わせたメッセージによりディレクトリサーバ20又は機能サーバ30に対する指令を送信する。一方、各サーバ20,30は、複合機10からのHTTPリクエストのPOSTコマンドに伴わせたメッセージによる問合せに対し、複合機指令があれば、上記問合せに対するHTTPレスポンスのメッセージに、複合機指令を伴わせて送信する。
次に、複合機10、ディレクトリサーバ20及び機能サーバ30の各制御部11,21,31が行う処理について説明する。まず最初に、複合機10の制御部11が行う複合機処理について、図8のフローチャートを用いて説明する。尚、この複合機処理は、複合機10の電源が投入されると、ただちに開始される。
複合機処理を開始すると、制御部11は、まずS101で、複合機10の初期化処理を行う。続いて、S102では、複合機10への指令入力を受け付ける。ここで、複合機10への指令入力とは、複合機10に何らかの処理を実行させるための入力であり、例えば、操作部12からのキー入力や、図示しないパーソナルコンピュータからの指令入力等が挙げられる。
続いて、S103では、S102で受けた指令入力が、サービスモードへの移行を指示する指令入力であるか否かを判断する。S103で、サービスモードへの移行を指示する指令入力ではないと判断すると(S103でNo)、制御部11は、S104へ移行し、S102で受けた入力に応じたその他のモードに対応する処理(例えば、パーソナルコンピュータから入力された印刷データの出力処理)を行い、S102へ移行する。
一方、S103で、指令入力がサービスモードへの移行を指示する入力であると判断すると、制御部11は、S105へ移行し、機能サーバ30に要求するサービスを決定する方法として、リストから選択する方法及びサービス要求先のURL情報を直接入力する方法のうち、いずれの方法を採用するかを利用者に問い合わせるための選択画面をディスプレイ19aに表示する。そして、利用者の指令が操作部12を通じて入力されるのを待つ。そして、指令が入力されると、その内容に従って、機能サーバ30に要求するサービスをリストから選択するか否かを判断する。
S105で、機能サーバ30に要求するサービスをリストから選択すると判断した場合、制御部11は、S106へ移行し、ディレクトリサーバ20にサービスの一覧を要求する。具体的には、ディレクトリサーバ20に対しトップのサービス定義情報25(図3)の送信を要求する。尚、本実施例において、複合機10には、トップのサービス定義情報25を要求するためのURL情報が記憶部16にあらかじめ記憶されている。
S106の処理後、制御部11は、S106での要求に対してディレクトリサーバ20から送信されたトップのサービス定義情報25を、通信部15を介して受信する(S107)。更に、S108では、S107で受信したサービス定義情報25に基づくサービス選択用画面を表示部19のディスプレイ19aに表示し(図2(a))、S110へ移行する。
一方、S105で、機能サーバ30に要求するサービスをリストから選択しないと判断した場合には、S109に移行し、URL情報を直接入力するためのアドレス入力画面(図示せず)を表示部19のディスプレイ19aに表示し、S110へ移行する。
S110では、サービス選択用画面又はアドレス入力画面に基づいた利用者による入力操作が操作部12を介して行われるまで待機し、操作部12から、入力操作に基づく操作情報が入力されると、S111に移行して、利用者による入力操作が、リンク選択のための操作であるか否かを判断する。具体的には、S108で表示した情報に基づき選択操作が正常に行われた場合、又は、S109で表示したアドレス入力画面にURL情報の入力が正常に行われた場合に、入力操作がリンク選択のための操作であると判断する。
入力操作がリンク選択のための操作でないと判断すると(S111でNo)、制御部11は、S112へ移行し、S110で受けた入力操作が、サービスモードを終了するための停止操作であるか否かを判断する。そして、サービスモードを終了するための停止操作であると判断すると、S102へ移行する。即ち、サービスモードとしての処理を終了する。一方、S112で、サービスモードを終了するための停止操作でないと判断すると、S113へ移行し、拒否音(ビープ音等)を鳴動した後、S110へ移行する。即ち、S110で受けた入力操作が、リンク選択のための操作でなく、停止操作でもない場合に、拒否音によって、操作無効を利用者に通知する。
また、S111で入力操作がリンク選択のための操作であると判断すると、制御部11は、S114へ移行し、選択されたリンクが、サービスのURL情報で表されているか否かを判断する。
ここで、サービスのURL情報で表されていない(サービス定義情報25の識別情報である又はディレクトリサーバ20のURL情報で表されている)と判断すると、制御部11は、S115へ移行し、Link_Locationが示すサービス定義情報25の識別情報(URL情報が直接入力された場合には、そのURL情報)に基づき、ディレクトリサーバ20に対し、該当するサービス定義情報25の送信を要求し、要求したサービス定義情報25をディレクトリサーバ20から受信する。その後、S108に移行し、新たなサービス選択用画面を表示部19のディスプレイ19aに表示する。
一方、S114で、リンクがサービスのURL情報で表されていると判断すると、制御部11は、S116へ移行し、上記選択されたリンクのURL情報(サービス定義情報25のLink_Locationタグに記載のURL情報、又は、直接入力されたURL情報)を引数に設定して、サービスを受けるためのサービス受信処理(図10参照。詳細後述)を実行した後、S102に移行する。
ここで、サービス受信処理を説明する前に、S106にて送信されるサービス一覧の要求、及び、サービス定義情報25の送信要求を受けるディレクトリサーバ20の動作について説明する。図9は、ディレクトリサーバ20の制御部21が繰返し実行するディレクトリサーバ処理を表すフローチャートである。
ディレクトリサーバ20の制御部21は、ディレクトリサーバ処理を実行すると、S201にて、HTTPリクエストを受信するまで待機し、HTTPリクエストを受信すると、S202に移行する。S202では、S201で受信したHTTPリクエストがサービス一覧の要求であるか否かを判断し、サービス一覧の要求であると判断すると、S203へ移行し、記憶部23のサービス定義情報記憶部24からトップのサービス定義情報25を読み出す。その後、S207へ移行し、読み出したサービス定義情報25を含むHTTPレスポンスを、HTTPリクエストの送信元へ送信する。S207での処理を終えると、制御部21は、当該ディレクトリサーバ処理を終了する。
一方、S202で、サービス一覧の要求でないと判断すると、制御部21は、S204へ移行し、S201で受信したHTTPリクエストがサービス定義情報の送信要求であるか否かを判断する。そして、サービス定義情報の送信要求であると判断すると、S205へ移行し、記憶部23のサービス定義情報記憶部24から、上記送信要求で指定されたサービス定義情報25を読み出す。その後、S207へ移行し、読み出したサービス定義情報25を含むHTTPレスポンスを、HTTPリクエストの送信元へ送信した後、当該ディレクトリサーバ処理を終了する。
一方、S204で、HTTPリクエストがサービス定義情報の送信要求でもないと判断すると、制御部21は、S206へ移行し、S201で受信したHTTPリクエストに対応する所定の処理を実行し、その処理結果を示す情報を含むHTTPレスポンスを送信する(S207)。その後、当該ディレクトリサーバ処理を終了する。
次に、複合機処理(図8)におけるS116で実行されるサービス受信処理について、図10のフローチャートを用いて説明する。
このサービス受信処理を開始すると、制御部11は、S301で、上記引数に設定されたURL情報に従うURL先へ、通信部15を介して、サービス起動指令(HTTPリクエスト)を送信し、上記URL情報に対応するサービス(利用者によって選択されたサービス)にかかるプロセスを、URL先の機能サーバ30に起動させる。
その後、S302に移行し、URL先の機能サーバ30からセッションIDを受信する。尚、セッションIDは、機能サーバ30の制御部31により実行される後述の機能サーバ処理(図12)のS405で生成され、S409で、指令元の当該複合機10に送信される。
続くS303では、複合機10に対する指令(複合機指令)の有無を問い合わせるための信号である「複合機指令問合せ」を、機能サーバ30へ送信する。尚、「複合機指令問合せ」には、S302で受信したセッションIDが含まれる。
S303の処理後、制御部11は、S303で送信した「複合機指令問合せ」に対する応答信号(HTTPレスポンス)を受信し(S304)、「複合機指令問合せ」に対する返答が「ジョブ起動指令」であるか否かを判断する(S305)。尚、「ジョブ起動指令」は、機能サーバ30の制御部31により実行される後述のS603,S1703等の各処理で出力される。この「ジョブ起動指令」には、ジョブを特定するためのジョブIDと、ジョブ実行時の通信先のURL情報である通信先URL情報と、が含まれる。
S305で「ジョブ起動指令」であると判断すると、制御部11は、S306へ移行し、ジョブの起動に必要なリソースを確保し、更にS307へ移行して、指定ジョブの起動処理(図11参照。詳細後述)を実行する。その後、S308へ移行し、所定インターバル待機した後、S303へ移行する。
一方、S305で「ジョブ起動指令」でないと判断すると、制御部11は、S309へ移行し、「複合機指令問合せ」に対する返答が「ジョブ終了指令」であるか否かを判断する。尚、「ジョブ終了指令」は、機能サーバ30の制御部31により実行される後述のS610,S1708等の各処理で出力される。この「ジョブ終了指令」には、ジョブを特定するためのジョブIDが含まれる。
S309で、「ジョブ終了指令」であると判断すると、制御部11は、S310へ移行し、ジョブIDに対応するジョブに対して終了指示を入力して、そのジョブを終了し、リソースを解放する。その後、S308へ移行し、所定インターバル待機した後、S303に移行する。
一方、S309で、「ジョブ終了指令」でないと判断した場合には、S311へ移行し、「複合機指令問合せ」に対する返答が「定期問合せ開始指令」であるか否か判断する。尚、「定期問合せ開始指令」は、機能サーバ30の制御部31により実行される後述のS609で出力される。
S311で「定期問合せ開始指令」であると判断すると、制御部11は、S312に移行し、「定期問合せ開始指令」が含む情報に基づいて、記憶部16が記憶する定期問合せ管理テーブル(図16参照)に、問合せ管理情報を書き込む。尚、S312の具体的な処理内容は、S609に関する説明と共に後述する。S312での処理を終えると、制御部11は、S308へ移行し、所定インターバル待機した後、S303に移行する。
また、S311で「定期問合せ開始指令」でないと判断すると、制御部11は、S313に移行し、「複合機指令問合せ」に対する返答が「指令なし」を表すものであるか否かを判断する。
S313で、「複合機指令問合せ」に対する返答が「指令なし」を表すものであると判断すると、制御部11は、S308へ移行し、所定インターバル待機した後、S303へ移行する。一方、S313で、「複合機指令問合せ」に対する返答が「指令なし」を表すものでないと判断すると、S314へ移行し、「複合機指令問合せ」に対する返答が「サービス終了指令」であるか否かを判断する。尚、「サービス終了指令」は、機能サーバ30の制御部31により実行される後述のS611、S1709等で出力される。
S314で「サービス終了指令」であると判断すると、制御部11は、当該サービス受信処理を終了する。一方、「サービス終了指令」ではないと判断すると、S315に移行し、エラー処理(例えば、エラーである旨のメッセージを表示部19のディスプレイ19aに表示する処理等)を実行し、その後、当該サービス受信処理を終了する。
次に、S307にて実行される指定ジョブの起動処理について、図11のフローチャートを用いて説明する。
指定ジョブの起動処理を開始すると、制御部11は、まずS351で、「ジョブ起動指令」が「UI(ユーザインタフェース)ジョブ起動指令」であるか否かを判断する。尚、「UIジョブ起動指令」とは、複合機10に設けられたUIデバイス(操作部12)の利用開始を通知するものである。
そして、「UIジョブ起動指令」であると判断すると、S352へ移行し、ジョブID、ジョブの通信先URL情報を渡してUIジョブ(図18参照。詳細後述)を起動した後、当該指定ジョブの起動処理を終了する。これにより、複合機10と機能サーバ30との間で、UIジョブの通信処理が開始される。尚、UIジョブは、サービス受信処理のプロセスと並列動作する。
一方、S351で、「ジョブ起動指令」が「UIジョブ起動指令」でないと判断すると、制御部11は、S353へ移行し、「ジョブ起動指令」が「入力ジョブ起動指令」であるか否かを判断する。尚、「入力ジョブ起動指令」とは、複合機10に設けられた入力デバイス(読取部13又は音入力部17)の利用開始を通知するものである。
具体的に、ここでは、「ジョブ起動指令」が、当該複合機10の読取部(スキャナ)13を用いて機能サーバ30から提供されるサービスを受けるように指示する「スキャナジョブ起動指令」、又は、音入力部17を用いて機能サーバ30から提供されるサービスを受けるように指示する「ボイスジョブ起動指令」である場合に、「ジョブ起動指令」が「入力ジョブ起動指令」であると判断する。
そして、「入力ジョブ起動指令」であると判断すると、S354へ移行し、ジョブID、ジョブの通信先URL情報を渡して入力ジョブを起動した後、当該指定ジョブの起動処理を終了する。尚、入力ジョブ起動の際には、入力ジョブに駆動対象の入力装置(読取部13又は音入力部17)を指定する。
これにより、複合機10と機能サーバ30との間で、入力ジョブの通信処理が開始される。具体的に、入力ジョブを実行すると、制御部11は、機能サーバ30から指示されたデータを、入力装置(読取部13又は音入力部17)を用いて生成し、これを、機能サーバ30に提供して、所定のサービス(データの公開サービス等)を受ける。尚、この入力ジョブも、サービス受信処理のプロセスと並列動作する。
また、S353で「ジョブ起動指令」が「入力ジョブ起動指令」ではないと判断すると、制御部11は、S355に移行し、「ジョブ起動指令」が「出力ジョブ起動指令」であるか否か判断する。尚、「出力ジョブ起動指令」とは、複合機10に設けられた出力デバイス(記録部14又は音出力部18)の利用開始を通知するものである。
具体的に、ここでは、「ジョブ起動指令」が、当該複合機10の記録部(プリンタ)14を用いて機能サーバ30から提供されるサービスを受けるように指示する「印刷ジョブ起動指令」、又は、音出力部18を用いて機能サーバ30から提供されるサービスを受けるように指示する「スピーカジョブ起動指令」である場合に、「ジョブ起動指令」が「出力ジョブ起動指令」であると判断する。
そして、「出力ジョブ起動指令」であると判断すると、S356に移行し、ジョブID、ジョブの通信先URL情報を渡して、出力ジョブ(図31参照。詳細後述)を起動した後、当該指定ジョブの起動処理を終了する。尚、出力ジョブの起動の際には、出力ジョブに駆動対象の出力装置(記録部14又は音出力部18)を指定する。これにより、複合機10と機能サーバ30との間で、出力ジョブの通信処理が開始される。そして、この出力ジョブは、サービス受信処理のプロセスと並列動作する。
一方、S355で、「ジョブ起動指令」が「出力ジョブ起動指令」ではないと判断すると、制御部11は、ジョブ(UIジョブ、入力ジョブ、出力ジョブ)を起動することなく、当該指定ジョブの起動処理を終了する。
次に、S301で複合機10が送信するサービス起動指令を受ける機能サーバ30側のプログラムにて実現される機能サーバ処理について説明する。尚、図12は、機能サーバ30の制御部31が実行する機能サーバ処理を表すフローチャートである。この機能サーバ処理を実現するためのプログラムは、サービスの種類毎に用意される。
機能サーバ処理を開始すると、制御部31は、HTTPリクエストを受信するまで待機し(S401)、通信部15を介してHTTPリクエストを受信すると、S402に移行し、S401で受信したHTTPリクエストがサービス起動指令であるか否かを判断する。S402で、サービス起動指令であると判断すると、制御部31は、S405へ移行し、セッションIDを生成して、これを格納した送信データを生成すると共に、サービスを提供するためのプロセスを起動する。例えば、当該機能サーバ処理が、定期的に情報を提供するサービス(ブログ検索サービス、ローカルニュース提供サービス)の利用登録を受けるための処理である場合には、上記プロセスとして、図14に示す登録処理を実行する(詳細後述)。その後、S409に移行する。
また、S402で、HTTPリクエストがサービス起動指令でないと判断すると、制御部31は、S406に移行し、S401で受信したHTTPリクエストが「サービス終了指令」であるか否かを判断する。S406で、「サービス終了指令」であると判断すると、制御部31は、S407に移行し、セッションID及び確保したリソースを解放し、S409へ移行する。
一方、S406で「サービス終了指令」でないと判断すると、制御部31は、S408にて、サービス制御情報処理(図13参照。詳細後述)を実行した後、S409に移行する。S409では、S405,S407及びS408のいずれかのステップで生成した送信データを格納したHTTPレスポンスを生成し、これを通信部32を介して、HTTPリクエスト送信元の複合機10に送信する。
S409の処理後、制御部31は、S408にてサービス制御情報処理を実行したか否か判断し(S410)、サービス制御情報処理を実行したと判断すると、S411にて、セッションID又はジョブIDに対応するメモリアドレスに「送信済み」フラグをセットした後、当該機能サーバ処理を終了する。一方、S410でサービス制御情報処理を実行していないと判断すると、S411での処理を実行することなく、当該機能サーバ処理を終了する。
次に、制御部31が、機能サーバ処理のS408にて実行するサービス制御情報処理について説明する。図13は、サービス制御情報処理を表すフローチャートである。
サービス制御情報処理を実行すると、制御部31は、S501で、サービスに送る情報が存在するか否かを判断する。具体的には、機能サーバ処理(図12)のS401で受信したHTTPリクエストに、セッションID又はジョブIDにて特定されるサービスを実現するプロセスに対する情報が含まれているか否かを判断する。
そして、サービス(プロセス)に送る情報が存在しないと判断すると、S506に移行し、サービス(プロセス)に送る情報が存在すると判断すると、S502に移行して、セッションID又はジョブIDに対応するプロセスを特定する。即ち、受信したHTTPリクエストに含まれている情報の送信先となるプロセスを特定する。
ここで、プロセスを特定することができないと、制御部31は、S503でYesと判断して、送信データとしてエラー通知情報を生成し(S504)、当該サービス制御情報処理を終了する。一方、プロセスを特定することができた場合には、S503でNoと判断し、S505で、特定したプロセスに、上記情報を送信した後、S506へ移行する。
S506では、セッションID又はジョブIDに対応するプロセスにて生成された返信情報を記憶するメモリ領域(以下、「返信情報格納領域」とする。)を特定し、特定できない場合には、S507でYesと判断して、S504に移行し、HTTPレスポンスに格納する送信データとして、エラー通信情報を生成する。その後、当該サービス制御情報処理を終了する。
一方、特定できた場合には、S507でNoと判断して、S508に移行し、特定した返信情報格納領域に、返信情報が格納されているか否か判断する。そして、返信情報が格納されていると判断すると、S509へ移行し、その返信情報に基づく「複合機指令」を、送信データとして生成する。その後、当該サービス制御情報処理を終了する。
一方、S508で、上記特定した返信情報格納領域に返信情報が格納されていないと判断すると、S510に移行し、送信データとして、「複合機指令無し」の情報を生成した後、当該サービス制御情報処理を終了する。
次に、機能サーバ30の制御部31がS405で起動するプロセスについて説明する。尚、上記プロセスが行う処理の内容はサービスの種類によって異なるため、ここでは、定期的に情報を提供するサービス(ブログ検索サービス、ローカルニュース提供サービス)の利用登録を受けるためのプロセスが行う登録処理ついて説明する。尚、図14は、制御部31が実行する登録処理を表すフローチャートである。
登録処理を実行すると、制御部31は、S601で初期化処理を実行し、続くS602で、サービス側UIジョブ(図17参照。詳細後述)を起動する。続いて、S603では、「UIジョブ起動指令」を複合機指令として出力する。具体的には、S405で生成したセッションIDに対応する返信情報格納領域に対して、「UIジョブ起動指令」を書き込む処理を行う。
これによって、「UIジョブ起動指令」は、サービス制御情報処理を介し、複合機指令として、複合機10に送信される。また、制御部31は、上述の機能サーバ処理(図12)におけるS411にて「送信済み」がセットされることで出力を確認する。尚、この「UIジョブ起動指令」には、S602で起動したサービス側UIジョブについてのジョブIDとジョブの通信先URL情報とが含まれる。
S603での処理を終えると、制御部31は、S604に移行し、パラメータの値入力が完了したか否かを判断する。尚、パラメータの値入力が完了したか否かは、後述するサービス側UIジョブ(図17)におけるS711によってパラメータ入力済みの通知が、当該登録処理のプロセスに対して入力されたか否かにより判断する。
S604で、パラメータの値入力が完了していないと判断すると、制御部31は、S605へ移行し、停止が通知されたか否かを判断する。尚、停止の通知は、後述するサービス側UIジョブ(図17)におけるS709で行われる。
S605で、停止が通知されていないと判断すると、制御部31は、S604に移行し、S605で停止が通知されたと判断すると、S610に移行する。また、S604で、パラメータの値入力が完了したと判断した場合には、S606へ移行し、リクエストサービスIDを生成する。
尚、リクエストサービスIDは、入力されたパラメータの値に対応するサービスを、入力元の複合機10に対してのみ提供するためのものである。このリクエストサービスIDは、サービスの利用登録毎に(即ち、パラメータ情報の入力毎に)、ユニークに生成され、後述のS609により、上記入力元の複合機10に対してのみに通知される。
S606での処理を終えると、制御部31は、S607にて、記憶部33に記憶されたリクエストサービスID管理テーブルに、S606で生成したリクエストサービスIDと、入力された各パラメータの値(パラメータ情報)と、を書き込む。図15(a)は、記憶部33に記憶されたリクエストサービスID管理テーブルの構成を表す説明図である。
リクエストサービスID管理テーブルは、リクエストサービスIDと、そのリクエストサービスIDの生成時にクライアント装置としての複合機10から入力された各パラメータの値(パラメータ情報)とが、互いに関連付けられて記憶されたものである。このリクエストサービスID管理テーブルは、サービスの種類毎に用意される登録処理のプロセスに対応して、サービスの種類毎に、記憶部33に設けられている。例えば、記憶部33には、ブログ検索サービス用のリクエストサービスID管理テーブルと、ローカルニュース提供サービス用のリクエストサービスID管理テーブルとが設けられている。
即ち、S607では、当該プロセスに対応するリクエストサービスID管理テーブルに、S606で生成したリクエストサービスIDと、複合機10から入力された各パラメータの値(パラメータ情報)と、を記述して登録する。
S607での処理を終えると、制御部31は、S608に移行し、記憶部33が記憶する定期問合せ返信管理テーブルに、S606で生成したリクエストサービスIDの返信管理情報を書き込む。尚、図15(b)は、記憶部33に記憶された定期問合せ返信管理テーブルの構成を表す説明図である。
図15(b)に示すように、定期問合せ返信管理テーブルは、リクエストサービスIDと、サービススタート情報と、サービスURL情報と、サービスステータス情報と、サービスキャンセル情報と、からなる返信管理情報が、リクエストサービスID毎に、記述された構成にされている。
サービススタート情報は、サービスを提供する準備が完了したか否かを表す情報であって、サービスを提供する準備が完了している場合には、値「TRUE」で表され、サービスを提供する準備か完了していない場合には、値「FALSE」で表される情報である。
また、サービスURL情報は、リクエストサービスIDに対応するサービスを提供する機能サーバ30のURL情報であり、サービスステータス情報は、サービスを提供する機能サーバ30側のステータス情報である。
サービスステータス情報は、リクエストサービスIDに対応するサービスのステータスが正常である場合には値「0」で表され、サービスのステータスが異常である場合には、その原因に対応する負値で表される。
その他、サービスキャンセル情報は、サービスの提供が終了したか否かを表す情報であり、サービスの提供が終了している場合には、値「TRUE」で表され、サービスの提供が継続している場合には、値「FALSE」で表される。尚、サービスキャンセル情報が値「TRUE」である返信管理情報は、機能サーバ30の定期削除プログラム(図示せず)により、一定期間後、自動削除される。また、この削除に伴って、リクエストサービスID管理テーブルの上記削除対象のリクエストサービスIDに関するパラメータ情報も、削除される。
そして、S608の処理を終えると、制御部31は、「定期問合せ開始指令」を複合機指令として出力する(S609)。具体的に、ここでは、S405で生成したセッションIDに対応する返信情報格納領域に対して、「定期問合せ開始指令」を書き込む処理を行う。この書き込みによって、「定期問合せ開始指令」は、サービス制御情報処理を介し、複合機指令として、複合機10に送信される。
尚、「定期問合せ開始指令」は、S606で生成したリクエストサービスIDと、複合機10に対して指定する定期問合せの時間間隔を表す情報(問合せ間隔情報)と、その時間間隔後、即時の問合せが必要であるか否かを表す情報(即時処理情報)と、サービスの利用時に複合機10側で動作が必要となる入出力デバイスの種類を表す情報(利用デバイス情報)と、を含むものである。
複合機10の制御部11は、この「定期問合せ開始指令」を受信すると、S312(図10)に移行し、「定期問合せ開始指令」が含む情報に基づいて、記憶部16が記憶する定期問合せ管理テーブル(図16参照)に、リクエストサービスID、リクエストステータス情報、問合せ間隔情報、残り時間情報、即時処理情報、及び、利用デバイス情報からなる問合せ管理情報を追加する。尚、図16は、記憶部16が記憶する定期問合せ管理テーブルの構成を表す説明図である。
ここで、定期問合せ管理テーブルに書き込まれるリクエストサービスID、問合せ間隔情報、即時処理情報、及び利用デバイス情報は、「定期問合せ開始指令」に含まれる情報と同一のものである。一方、リクエストステータス情報は、問合せに対する返答として、上述したサービスステータス情報を機能サーバ30側から取得するか否かを表す情報であり、取得する場合には値「TRUE」で表され、取得しない場合には値「FALSE」で表される。
尚、S312では、リクエストステータス情報を値「TRUE」として、定期問合せ管理テーブルに、その情報を書き込む。但し、本実施例の複合機10は、操作部12からリクエストステータス情報の値変更指令が入力されると、その指令に従って、定期問合せ管理テーブルにおける指令対象のリクエストステータス情報の値を「FALSE」(又は「TRUE」)に変更する。
その他、残り時間情報は、次回の問合せ時刻までの残り時間を表す情報である。S312では、問合せ間隔情報と同一の値を示す残り時間情報が、定期問合せ管理テーブルに書き込まれるが、この残り時間情報は、後述するS901の処理にて逐次更新される。
話を戻して、S609での出力を終えると、制御部31は、S610に移行し、「UIジョブ終了指令」を複合機指令として出力する(S610)。具体的に、ここでは、S405で生成したセッションIDに対応する返信情報格納領域に対して、「UIジョブ終了指令」を書き込む処理を行う。これにより、「UIジョブ終了指令」は、サービス制御情報処理を介し、複合機指令として、複合機10に送信される。
S610での処理を終えると、制御部31は、S611に移行し、S603で起動したサービス側UIジョブに対して終了指示を入力して、サービス側UIジョブを終了すると共に、「サービス終了指令」を複合機指令として出力する。その後、当該登録処理を終了する。
次に、機能サーバ30の制御部31がS602で起動するサービス側UIジョブを、図17を用いて説明すると共に、複合機10の制御部11が、S603で出力される「UIジョブ起動指令」を受けて(S304)、S352で起動するUIジョブを、図18を用いて説明する。尚、図17は、機能サーバ30の制御部31が実行するサービス側UIジョブを表すフローチャートであり、図18は、複合機10の制御部11が実行するUIジョブを表すフローチャートである。
サービス側UIジョブを実行すると、制御部31は、まずS701で、複合機10から「複合機ジョブ指令問合せ」を受信する。尚、「複合機ジョブ指令問合せ」は、複合機10の制御部11により実行されるUIジョブ(図18)のS800等で送信用データに設定され、S806で送信される。
続いて、S702では、サービスの実行に必要なパラメータの値を入力させるための「パラメータ要求指令」を複合機指令として複合機10へ送信する。尚、「パラメータ要求指令」と共に、複合機10には、記憶部33のサービスI/F情報記憶部34に記憶されているサービスI/F情報36が送信される。具体的に、当該サービス側UIジョブを起動した登録処理のプロセスが、ブログ検索サービスの利用登録を受けるためのプロセスである場合には、図6に示すサービスI/F情報36が送信される。また、当該サービス側UIジョブを起動した登録処理のプロセスが、ローカルニュース提供サービスの利用登録のためのプロセスである場合には、図7に示すサービスI/F情報36が送信される。
S702の処理後、制御部31は、S703に移行し、エラーカウントを初期化する。その後、上記サービスI/F情報36に基づくパラメータ入力用画面を通じて利用者から入力された各パラメータの値を、複合機10から受信する(S704)。尚、各パラメータの値は、複合機10の制御部11により実行されるUIジョブ(図18)のS810で送信用データに設定され、S806で送信される。
S704で各パラメータの値を受信すると、制御部31は、S705に移行し、S704で受信した各パラメータの値が正常であるか否かを判断する。そして、パラメータの値が正常でないと判断すると、S706へ移行し、正常でないと判断された回数が2回目であるか否かを、上述のエラーカウントに基づいて判断する。
S706で、2回目でない(1回目である)と判断した場合には、S707へ移行し、機能サーバ30が複合機10からの情報を正常に受け取ることができたか否かの通知であるサーバ受取状況として「サーバ受取NG(異常受取)」を、複合機10のUIジョブに向けて出力する。
S707の処理後、制御部31は、エラーカウントをカウントアップし(S708)、S704に移行する。一方、S706で、2回目であると判断すると、制御部31は、S709へ移行し、当該サービス側UIジョブの起動元のプロセス(登録処理のプロセス)へ停止を通知した後、当該サービス側UIジョブを終了する。
また、S705で、パラメータの値が正常であると判断すると、制御部31は、S710へ移行し、サーバ受取状況として「サーバ受取OK(正常受取)」を、複合機10のUIジョブに向けて出力する。
S710での処理を終えると、制御部31は、S711に移行し、当該サービス側UIジョブの起動元のプロセス(登録処理のプロセス)へ「パラメータ入力済み」を通知する。その後、制御部31は、S712にて、複合機10から「サービス状態情報要求」を受信するまで待機し、「サービス状態情報要求」を受信すると、S713にて、「サービス状態情報」を、複合機10のUIジョブに向けて送信する。その後、S712へ移行する。
即ち、他の処理によって、当該サービス側UIジョブが終了される(S611)まで、複合機10から「サービス状態情報要求」を受信し、それに応答して「サービス状態情報」を送信するという処理を繰返す。尚具体的に、「サービス状態情報」は、パラメータの値入力が正常に行われたことを示す情報である。
一方、複合機10の制御部11は、S603で出力される「UIジョブ起動指令」を受けて、S352でUIジョブ(図18)を起動すると、次の処理を実行する。
UIジョブを実行すると、複合機10の制御部11は、まずS800にて、複合機10に対する指令の問い合わせである「複合機ジョブ指令問合せ」を、送信用データに設定し、その後、S801で、当該UIジョブ起動元のプロセス(サービス受信処理のプロセス)からの終了指示があったか否かを判断する。尚、終了指示は、S310で出力される。
S801で終了指示があったと判断すると、制御部11は、S802に移行し、当該UIジョブ起動元のプロセス(サービス受信処理のプロセス)へ終了を通知した後、当該UIジョブを終了する。
一方、S801で終了指示がないと判断すると、制御部11は、S803へ移行し、操作部12及び表示部19がビジー状態であるか否かを判断する。具体的には、操作部12及び表示部19がビジー状態であるか否かを表すビジーフラグFuに基づき、ビジーフラグFuが立っている場合にはビジー状態であると判断し、ビジーフラグFuが下りている場合にはビジー状態でないと判断する。
そして、操作部12及び表示部19がビジー状態であると判断すると、S804へ移行し、操作部12及び表示部19のビジー状態が解除されるまで待機した後、S803へ移行する。一方、S803で、ビジー状態でないと判断した場合には、S805へ移行し、ビジーフラグFuを立てる。
S805の処理を終えると、制御部11は、S806に移行し、予めS800等で設定した送信用データを機能サーバ30へ送信する。送信後、制御部11は、S806での送信に対する応答信号を受信し(S807)、受信した応答信号が「パラメータ要求指令」であるか否かを判断する(S808)。尚、「パラメータ要求指令」は、機能サーバ30の制御部31により実行されるS702の処理で送信される。
S808で、「パラメータ要求指令」であると判断すると、制御部11は、S809へ移行し、「パラメータ要求指令」に含まれるサービスI/F情報36に基づきパラメータ入力用画面を表示部19のディスプレイ19aに表示し、パラメータ値についての入力操作を利用者に促すと共に、パラメータの値入力を受け付ける。
そして、操作部12を通じて、S809で受け付けたパラメータの値についての確定信号が入力されると、上記入力されたパラメータの値を、機能サーバ30のサービス側UIジョブに提供するため、これを送信用データに設定する(S810)。その後、制御部11は、S811へ移行し、ビジーフラグFuを下げた後、S801へ移行する。
一方、S808で、「パラメータ要求指令」ではないと判断すると、制御部11は、S812へ移行し、S807で受信した応答信号が「サービス状態情報」であるか否かを判断する。尚、「サービス状態情報」は、機能サーバ30の制御部31により実行されるS713の処理で送信される。
S812で、「サービス状態情報」であると判断すると、制御部11は、S813へ移行し、この「サービス状態情報」に基づく情報を、表示部19のディスプレイ19aに表示する。その後、サービス状態情報を機能サーバ30から取得するための「サービス状態情報要求」を、送信用データに設定する(S821)。S821での処理を終えると、制御部11は、S811へ移行し、ビジーフラグFuを下げた後、S801へ戻る。
一方、S812で、「サービス状態情報」でないと判断した場合には、S814へ移行し、S807で受信した応答信号が、機能サーバ30が複合機10からの情報を正常に受け取ることができたか否かを表す「サーバ受取状況」であるか否かを判断する。そして、「サーバ受取状況」であると判断すると、制御部11は、S815へ移行し、この「サーバ受取状況」が「サーバ受取NG」を表すものであるか否かを判断する。
「サーバ受取NG」を表すものであると判断すると、制御部11は、S816に移行し、機能サーバ30のサービス側UIジョブに、前回送信した情報を提供するために、前回送信した情報と同一の情報である再送信情報(パラメータ情報)を、送信用データに設定する。その後、S811へ移行し、ビジーフラグFuを下げた後、S801へ移行する。
一方、S815で、「サーバ受取状況」が「サーバ受取NG」を表すものではないと判断すると、制御部11は、S822に移行し、「サービス状態情報要求」を、送信用データに設定する。その後、S811へ移行し、ビジーフラグFuを下げた後、S801へ移行する。
また、S814で、上記応答信号が「サーバ受取状況」でないと判断すると、制御部11は、S817へ移行し、S807で受信した応答信号が「指令なし」を表すものであるか否かを判断する。
S817で、複合機指令が「指令なし」を表すものであると判断すると、制御部11は、S823に移行し、「複合機ジョブ指令問合せ」を、送信用データに設定する。その後、S811へ移行し、ビジーフラグFuを下げた後、S801へ移行する。一方、S817で、複合機指令が「指令なし」を表すものでないと判断した場合には、S818へ移行し、その他の処理を実行する。尚、この際には、処理の内容に適合するデータを、送信用データに設定する。例えば、ここでは、応答信号に対応する処理の実行後に、「複合機ジョブ指令問合せ」を、送信用データに設定する。その後、S811へ移行し、ビジーフラグFuを下げた後、S801へ移行する。
次に、上述の定期問合わせを実現するために、複合機10の制御部11が実行する定期問合せ処理について説明する。図19は、制御部11が実行する定期問合せ処理を表すフローチャートである。尚、この定期問合せ処理は、複合機10の電源投入時から開始され、複合機10の電源がオフにされるまで、継続的に実行される。
定期問合せ処理を実行すると、制御部11は、S901にて、定期問合せ管理テーブルの各残り時間情報を更新する。具体的には、前回の内部時計の値(時刻)と、現在の内部時計の値(時刻)との差を求めて、この差(カウントダウン量)を、残り時間情報が示す値から引き算し、残り時間情報を更新する。即ち、S901では、残り時間のカウントダウンと共に、内部時計の値の取得及び一時記憶を行う。
尚、S901の処理は、後述するように(高速で)繰り返されるため、前回のカウントダウンと、今回のカウントダウンとの間に、新規に定期問合せ管理テーブルに追加された問合せ管理情報についての残り時間情報のカウントダウン量についての誤差は許容する。また、初回のS901については、前回の電源オフ時前の最後の機会に取得した内部時計の値に基づいて、カウントダウン量を算出してもよいし、現在の内部時計の値を記憶するだけで、カウントダウンの処理を行わないようにしてもよい。
S901での処理を終えると、制御部11は、S902に移行し、定期問合せ管理テーブルから、処理対象の問合せ管理情報を、一つ選択する(S902)。処理対象の問合せ管理情報がない場合、即ち、後述するS904以降の処理の対象となっていない未処理の問合せ管理情報が存在しない場合には、S903でNoと判断して、S910に移行し、処理対象の問合せ管理情報(未処理の問合せ管理情報)がある場合には、S903でYesと判断して、S904に移行し、予め定められた問合せの実行猶予(保留)期間(最後の定期問合せ信号の送信時点から所定時間)が経過しているか否か判断する。
S904で、実行猶予期間が経過していないと判断すると、制御部11は、S905に移行し、上記選択した処理対象の問合せ管理情報が有する即時処理情報に基づいて、即時の問合せが必要であるか否かを判断する。ここで、即時の問合せが必要でないと判断すると、S902に移行し、即時の問合せが必要であると判断すると、S906に移行する。
S906では、上記選択した処理対象の問合せ管理情報が有する残り時間情報に基づき、その問合せ管理情報に対応するリクエストサービスIDのサービスについて、定期問合せの送信時刻が到来しているか否か判断し、送信時刻が到来していないと判断すると、S902に移行する。尚、S906では、残り時間情報の値がゼロ又は負値である場合に、送信時刻が到来していると判断し、残り時間情報の値が正値である場合には、送信時刻が到来していないと判断する。
S906で送信時刻が到来していると判断すると、制御部11は、上記選択した処理対象の問合せ管理情報が有する利用デバイス情報に基づき、当該問合せ管理情報に対応するサービスを受ける際に利用する入出力デバイスが、並列動作している他のプロセスによって使用されているか否かを判断する(S907)。
具体的に、ここでは、処理対象の問合せ管理情報が有する利用デバイス情報が「Printer」である場合、記録部14が使用されているか否かを判断する。また、利用デバイス情報が「Scanner」である場合、読取部13が使用されているか否かを判断する。その他、利用デバイス情報が「Speaker」である場合には、音出力部18が使用されているか否か判断し、利用デバイス情報が「Microphone」である場合には、音入力部17が使用されているか否か判断する。
また、利用デバイス情報に複数の入出力デバイスが示されている場合には、それら複数のデバイスが使用されているか否かを判断する。そして、複数のデバイスの一つでも使用されている場合には、当該問合せ管理情報に対応するサービスを受ける際に利用する入出力デバイスが使用されていると判断する。
S907で入出力デバイスが使用されていると判断すると、制御部11は、S902に移行し、使用されていないと判断すると、S908に移行し、統合問合せ情報生成処理を実行する。尚、図20は、制御部11が実行する統合問合せ情報生成処理を表すフローチャートであり、図21は、統合問合せ情報の構成を表す説明図である。また、統合問合せ情報は、図21に示すように、マークアップ言語によって記述されており、この統合問合せ情報で用いられる各タグの定義は表3に示すとおりである。
統合問合せ情報生成処理を実行すると、制御部11は、まずS1001にて、当該統合問合せ情報生成処理の実行が、S901の処理後、最初の実行であるか否か判断する。そして、最初の実行であると判断すると、S1011に移行し、統合問合せ情報を生成するための領域をRAMに確保し、その領域(空の統合問合せ情報)に、ヘッダ情報を書き込む(S1012)。
尚、本実施例では、統合問合せ情報を、HTTPプロトコルにおけるPOSTコマンドで送信するため、ヘッダ情報には、その旨の情報や送信先のURL情報等が書き込まれる。尚、統合問合せ情報の送信先は、予め決められており、ヘッダ情報には、その送信先のURL情報が書き込まれる。
S1012の処理後、制御部11は、パラメータNumPatternの値を「1」として、NumPatternタグ(文字列<NumPattern>1</NumPattern>)を生成し、これを、統合問合せ情報(統合問合せ情報生成領域)に追加する(S1013)。また、Request_Serviceタグを統合問合せ情報に追加する(S1014)。
その後、Request_Serviceタグの間(即ち、<Request_Service>と</Request_Service>との間)に、処理対象の問合せ管理情報のリクエストステータス情報に基づいて、Request_Statusタグを書き込む(S1015)。
例えば、リクエストステータス情報の値が「FALSE」である場合には、パラメータRequest_Statusの値を「FALSE」として、Request_Statusタグ(文字列<Request_Status>FALSE</Request_Status>)を生成し、これを統合問合せ情報に書き込む。
また、S1015の処理を終えると、パラメータNum_Service_IDの値を「1」として、Num_Service_IDタグ(文字列<Num_Service_ID>1</Num_Service_ID>)を生成し、これを統合問合せ情報におけるRequest_Serviceタグの間に書き込む(S1016)。
また、S1016の処理を終えると、処理対象の問合せ管理情報が示すリクエストサービスIDの値を、パラメータRequest_Service_IDの値として、Request_Service_IDタグ(文字列<Request_Service_ID>(リクエストサービスID)</Request_Service_ID>)を生成し、これを統合問合せ情報におけるRequest_Serviceタグの間に書き込む(S1017)。その後、当該統合問合せ情報生成処理を終了する。
一方、S1001にて、当該統合問合せ情報生成処理の実行が、S901の処理後、初回ではなく二回目以降の実行であると判断すると、制御部11は、S1021に移行し、同じパラメータ値のタグがあるか否かを判断する。即ち、当該処理対象の問合せ管理情報が有するリクエストステータス情報の値と、同一の値を示すRequest_Statusタグが、統合問合せ情報に既に書き込まれているか否か判断する。
S1021で、同じパラメータ値(Request_Status)のタグがあると判断すると、制御部11は、そのタグと、同一のRequest_Serviceタグの間にあるNum_Service_IDタグの値を更新する(S1022)。例えば、統合問合せ情報における更新前のNum_Service_IDタグが、文字列<Num_Service_ID>1</Num_Service_ID>である場合には、これを<Num_Service_ID>2</Num_Service_ID>に更新する。
S1022の処理を終えると、制御部11は、処理対象の問合せ管理情報が示すリクエストサービスIDの値を、パラメータRequest_Service_IDの値として、Request_Service_IDタグを生成し、これを統合問合せ情報におけるRequest_Serviceタグの間に書き込む(S1023)。その後、当該統合問合せ情報生成処理を終了する。
また、S1021で、同じパラメータ値(Request_Status)のタグがないと判断すると、制御部11は、S1031に移行し、統合問合せ情報のNumPatternタグにおけるパラメータNumPatternの値を更新する。即ち、統合問合せ情報のNumPatternタグが文字列<NumPattern>1</NumPattern>である場合には、これを、文字列<NumPattern>2</NumPattern>に更新する。
S1031の処理を終えると、制御部11は、S1032に移行し、既に統合問合せ情報に書き込まれているRequest_Serviceタグに続く領域に、新しいRequest_Serviceタグを書き込み、その新しいRequest_Serviceタグの間に、処理対象の問合せ管理情報が有するリクエストステータス情報の値に基づくRequest_Statusタグを書き込む(S1033)。
例えば、リクエストステータス情報の値が「TRUE」である場合には、パラメータRequest_Statusの値を「TRUE」として、Request_Statusタグ(文字列<Request_Status>TRUE</Request_Status>)を生成し、これを統合問合せ情報に書き込む。
S1033の処理を終えると、制御部11は、パラメータNum_Service_IDの値を「1」として、Num_Service_IDタグ(文字列<Num_Service_ID>1</Num_Service_ID>)を生成し、これを統合問合せ情報における上記新しいRequest_Serviceタグの間に書き込む(S1034)。
また、S1034の処理を終えると、処理対象の問合せ管理情報が示すリクエストサービスIDの値を、パラメータRequest_Service_IDの値として、Request_Service_IDタグを生成し、これを統合問合せ情報における上記新しいRequest_Serviceタグの間に書き込む(S1035)。その後、当該統合問合せ情報生成処理を終了し、S902(図19参照)に移行する。
また、S902の処理後、S903で処理対象の問合せ管理情報がないと判断すると(即ち、S904以降の処理を、定期問合せ管理テーブルに記載された全ての問合せ管理情報に対して実行したと判断すると)、制御部11は、S910に移行し、統合問合せ情報が生成されているか否かを判断する。そして、統合問合せ情報が生成されていると判断すると、RAMの統合問合せ情報生成領域に格納されている統合問合せ情報を格納した定期問合せ信号を生成し、これを通信部15を通じて、問合せ先の機能サーバ30に送信する(S911)。その後、S901に移行する。
一方、S910で統合問合せ情報が生成されていない(S908を実行していない)と判断すると、制御部11は、S911の処理を実行することなく、S901に移行して、再び、残り時間のカウントダウンを行う。
続いて、S911で複合機10から送信される定期問合せ信号を受ける機能サーバ30側の定期問合せ応答処理について説明する。図22は、機能サーバ30の制御部31が実行する定期問合せ応答処理を表すフローチャートである。この定期問合せ応答処理は、機能サーバ30の動作中、継続して行われる。
問合せ応答処理を実行すると、制御部31は、通信部32を介して、複合機10から定期問合せ信号を受信するまで待機し(S1101)、定期問合せ信号を受信すると、その定期問合せ信号に含まれる統合問合せ情報の中から、処理対象のリクエストサービスIDを一つ選択する(S1102)。
ここで、処理対象のリクエストサービスIDがない場合、即ち、後述するS1104以降の処理対象となっていない未処理のリクエストサービスIDが存在しない場合には、S1103でNoと判断して、S1115に移行し、処理対象(未処理)のリクエストサービスIDがある場合には、S1103でYesと判断してS1104に移行し、そのリクエストサービスIDについての返答を表す定期問合せ返信情報を生成するための定期問合せ返信情報生成領域を、RAMに確保し、その領域に、パラメータRequest_Service_IDの値として、上記処理対象のリクエストサービスIDを書き込む。
その後、処理対象のリクエストサービスIDに対応する返信管理情報を、記憶部33に格納された定期問合せ返信管理テーブル内で検索し(S1105)、検索できなかった場合には、定期問合せ返信管理テーブルに、処理対象のリクエストサービスIDに対する返信管理情報が登録されていないと判断して(S1106でNo)、S1107に移行し、上記定期問合せ返信情報生成領域に、パラメータService_Canceledの値として、「TRUE」を書き込むと共に、パラメータService_Startの値として、「FALSE」を書き込む。S1107での処理を終えると、制御部31は、S1114に移行し、図23に示す統合返信情報生成処理を実行する。
これに対し、S1105にて、処理対象のリクエストサービスIDに対応する返信管理情報を、記憶部33に格納された定期問合せ返信管理テーブルにて特定(検索)することができると、制御部31は、S1106でYesと判断し、上記定期問合せ返信情報生成領域に、パラメータService_Startの値として、当該処理対象のリクエストサービスIDに対応する返信管理情報が有するサービススタート情報の値を、書き込む(S1108)。
S1108の処理を終えると、制御部31は、S1109に移行し、上記定期問合せ返信情報生成領域に、パラメータService_Canceledの値として、当該処理対象のリクエストサービスIDに対応する返信管理情報が有するサービスキャンセル情報の値を、書き込む。
S1109の処理を終えると、制御部31は、S1110に移行し、上記定期問合せ返信情報生成領域に書き込んだパラメータService_Startの値が「TRUE」であるか否か判断し、「TRUE」であると判断すると、上記定期問合せ返信情報生成領域に、パラメータService_URLの値として、当該処理対象のリクエストサービスIDに対応する返信管理情報が有するサービスURL情報の値(文字列)を書き込む(S1111)。その後、S1112に移行する。
一方、上記定期問合せ返信情報生成領域に書き込んだパラメータService_Startの値が「TRUE」ではない(「FALSE」である)と判断すると、S1111の処理を実行せずに、S1112に移行する。
S1112に移行すると、制御部31は、統合問合せ情報における上記処理対象のリクエストサービスIDに関連付けられたRequest_Statusタグ(処理対象のリクエストサービスIDが記述されたRequest_Serviceタグの間にあるRequest_Statusタグ)の値が「TRUE」であるか否か判断し、「TRUE」であると判断すると、S1113に移行して、上記定期問合せ返信情報生成領域に、パラメータService_Statusの値として、当該処理対象のリクエストサービスIDに対応する返信管理情報が有するサービスステータス情報の値を書き込む。その後、S1114に移行する。
一方、S1112にて、統合問合せ情報における上記処理対象のリクエストサービスIDに関連付けられたRequest_Statusタグの値が「TRUE」ではない(「FALSE」である)と判断すると、S1113の処理を実行せずに、S1114に移行する。
S1114に移行すると、制御部31は、統合返信情報生成処理を実行する。図23は、制御部31が実行する統合返信情報生成処理を表すフローチャートであり、図24は、統合返信情報生成処理で実行される返信判断処理を表すフローチャートである。また、図25は、統合返信情報の構成を表す説明図である。その他、統合返信情報は、図25に示すように、マークアップ言語によって記述されており、この統合返信情報で用いられる各タグの定義は表4に示すとおりである。
統合返信情報生成処理を実行すると、制御部31は、まずS1201にて、当該統合返信情報生成処理の実行が、S1101にて定期問合せ信号を受信した後、最初の実行であるか否かを判断する。そして、最初の実行であると判断すると、S1211に移行し、統合返信情報を生成するための統合返信情報生成領域をRAMに確保し、その領域(空の統合返信情報)に、ヘッダ情報を書き込む(S1212)。
S1212の処理後、制御部31は、パラメータNumPatternの値を「1」として、NumPatternタグ(文字列<NumPattern>1</NumPattern>)を生成し、これを、統合返信情報(統合返信情報生成領域)に追加する(S1213)。また、Responce_Serviceタグを統合返信情報に追加する(S1214)。その後、返信判断処理(図24)を実行する。
返信判断処理を実行すると、制御部31は、S1301にて、処理対象のリクエストサービスIDに対応する定期問合せ返信情報(定期問合せ返信情報生成領域に書き込まれた情報)が示すパラメータService_Startの値が「TRUE」であるか否かを判断し、「TRUE」であると判断すると、返信OKと判断する(S1304)。
一方、S1301で「TRUE」ではないと判断すると、制御部31は、S1302に移行し、上記定期問合せ返信情報が示すパラメータService_Canceledの値が「TRUE」であるか否かを判断する。
そして、パラメータService_Canceledの値が「TRUE」であると判断すると、制御部31は、S1304に移行して、返信OKと判断する。これに対し、パラメータService_Canceledの値が「TRUE」ではないと判断すると、制御部31は、S1303にて、上記定期問合せ返信情報に、パラメータService_Statusの値が存在するか否か判断する。そして、存在すると判断すると、S1304に移行して、返信OKと判断する。一方、S1303で存在しないと判断すると、S1305に移行して、返信NGと判断する。その後、当該返信判断処理を終了する。
S1215での返信判断処理を終了すると、制御部31は、S1216にて、返信判断処理での判断が、返信OKとの判断であるか否かを判断する。そして、返信OKではない(返信NGである)と判断すると、当該統合返信情報生成処理を終了する。一方、返信OKであると判断すると、S1217に移行する。
S1217に移行すると、制御部31は、処理対象のリクエストサービスIDに対応する定期問合せ返信情報(定期問合せ返信情報生成領域に書き込まれた情報)に基づいて、Responce_Serviceタグの間(即ち、<Responce_Service>と</Responce_Service>との間)に、Service_Startタグを書き込む。
例えば、定期問合せ返信情報におけるパラメータService_Startの値が「TRUE」である場合、Service_Startタグとして、文字列<Service_Start>TRUE</Service_Start>)を生成し、これを統合返信情報に書き込む。
また、S1217の処理を終えると、制御部31は、処理対象のリクエストサービスIDに対応する定期問合せ返信情報に基づいて、Responce_Serviceタグの間に、Service_URLタグを書き込む(S1218)。尚、定期問合せ返信情報に、パラメータService_URLの値が存在しない場合には、Service_URLタグとして、文字列<Service_URL></Service_URL>を生成し、パラメータService_URLの値が存在する場合には、その値を記述したService_URLタグを生成して、統合返信情報に書き込む。
S1218の処理を終えると、制御部31は、処理対象のリクエストサービスIDに対応する定期問合せ返信情報に基づいて、Responce_Serviceタグの間に、Service_Statusタグを書き込む(S1219)。
この際、定期問合せ返信情報に、パラメータService_Statusの値が存在しない場合には、Service_Statusタグとして、文字列<Service_Status></Service_Status>を生成し、パラメータService_Statusの値が存在する場合には、その値を記述したService_Statusタグを生成し、これを統合返信情報に書き込む。
また、S1219の処理を終えると、制御部31は、処理対象のリクエストサービスIDに対応する定期問合せ返信情報に基づいて、Responce_Serviceタグの間に、Service_Canceledタグを書き込む(S1220)。
例えば、定期問合せ返信情報におけるパラメータService_Canceledの値が「FALSE」である場合、Service_Canceledタグとして、文字列<Service_Canceled>FALSE</Service_Canceled>)を生成し、これを統合返信情報に書き込む。
S1220の処理を終えると、制御部31は、パラメータNum_Service_IDの値を「1」として、Num_Service_IDタグ(文字列<Num_Service_ID>1</Num_Service_ID>)を生成し、これを統合返信情報におけるResponce_Serviceタグの間に書き込む(S1221)。
そして、S1221の処理を終えるとS1222に移行し、処理対象のリクエストサービスIDの値を、パラメータRequest_Service_IDの値として、Request_Service_IDタグ(文字列<Request_Service_ID>(リクエストサービスID)</Request_Service_ID>)を生成し、これを統合返信情報におけるResponce_Serviceタグの間に書き込む。その後、当該統合返信情報生成処理を終了する。
一方、S1201にて、当該統合返信情報生成処理の実行が、S1101の処理後、初回ではなく二回目以降の実行であると判断すると、制御部31は、S1225で返信判断処理(図24)を実行し、S1226で、返信判断処理の判断結果が返信OKであるか否かを判断する。そして、返信OKではない(返信NGである)と判断すると、当該統合返信処理を終了する。
これに対し、S1226で、返信OKであると判断すると、制御部31は、S1227に移行し、当該処理対象のリクエストサービスIDの定期問合せ返信情報と同じパラメータ値のResponce_Serviceタグがあるか否か判断する。即ち、当該処理対象のリクエストサービスIDの定期問合せ返信情報が有するリクエストサービスID以外の情報(パラメータService_Start,Service_URL,Service_Status,Service_Canceledの値)が同一であるResponce_Serviceタグが存在するか否か判断する。
そして、同じパラメータ値のResponce_Serviceタグがあると判断すると、制御部31は、そのResponce_Serviceタグの間にあるNum_Service_IDタグの値を更新する(S1228)。例えば、統合返信情報における更新前のNum_Service_IDタグが、文字列<Num_Service_ID>1</Num_Service_ID>である場合には、これを<Num_Service_ID>2</Num_Service_ID>に更新する。
S1228の処理を終えると、制御部31は、処理対象のリクエストサービスIDの値を、パラメータRequest_Service_IDの値として、Request_Service_IDタグを生成し、これを統合返信情報における上記パラメータ値が同一であるResponce_Serviceタグの間に書き込む(S1229)。その後、当該統合返信情報生成処理を終了する。
また、S1227で、同じパラメータ値のResponce_Serviceタグがないと判断すると、制御部31は、S1231に移行し、統合返信情報のNumPatternタグにおけるパラメータNumPatternの値を更新する。例えば、統合返信情報のNumPatternタグが文字列<NumPattern>1</NumPattern>である場合には、これを、文字列<NumPattern>2</NumPattern>に更新する。
但し、S1231の実行時において、統合返信情報に、空のResponce_Serviceタグがある場合(具体的には、S1216でNoと判断した後の、最初のS1231実行時)には、例外的に、パラメータNumPatternの値を更新しないこととする。
S1231の処理を終えると、制御部31は、S1232に移行し、既に統合返信情報に存在するResponce_Serviceタグに続く領域に、新しいResponce_Serviceタグを書き込む。但し、S1232の実行時において、統合返信情報に、空のResponce_Serviceタグがある場合には、例外的に、新しいResponce_Serviceタグの書込を実行しないこととする。
S1232の処理を終えると、制御部31は、S1233に移行し、処理対象のリクエストサービスIDに対応する定期問合せ返信情報に基づいて、新しいResponce_Serviceタグ(空のResponce_Serviceタグ)の間に、Service_Startタグを書き込む。
例えば、定期問合せ返信情報におけるパラメータService_Startの値が「FALSE」である場合、Service_Startタグとして、文字列<Service_Start>FALSE</Service_Start>)を生成し、これを統合返信情報に書き込む。
また、S1233の処理を終えると、制御部31は、処理対象のリクエストサービスIDに対応する定期問合せ返信情報に基づいて、上記Responce_Serviceタグの間に、Service_URLタグを書き込む(S1234)。また、処理対象のリクエストサービスIDに対応する定期問合せ返信情報に基づき、上記Responce_Serviceタグの間に、Service_Statusタグを書き込む(S1235)。
そして、S1235の処理を終えると、制御部31は、処理対象のリクエストサービスIDに対応する定期問合せ返信情報に基づいて、Responce_Serviceタグの間に、Service_Canceledタグを書き込む(S1236)。この後、パラメータNum_Service_IDの値を「1」として、Num_Service_IDタグを生成し、これを統合返信情報における上記Responce_Serviceタグの間に書き込む(S1237)。
S1237の処理を終えると、制御部31は、処理対象のリクエストサービスIDの値を、パラメータRequest_Service_IDの値として、Request_Service_IDタグを生成し、これを統合返信情報における上記Responce_Serviceタグの間に書き込む(S1238)。その後、当該統合返信情報生成処理を終了する。
このようにしてS1114(図22)で統合返信情報生成処理を実行すると、制御部31は、S1102に移行して、統合問合せ情報の中から、次の処理対象(未処理のリクエストサービスID)を選択する。ここで、未処理のリクエストサービスIDが存在しないと、制御部31は、S1115に移行して、統合返信情報生成領域に記憶されている統合返信情報を格納した応答信号を生成し、これを、通信部32を介して、定期問合せ信号送信元(問合せ元)の複合機10に送信する。その後、S1101に移行して、次の定期問合せ信号を受信するまで待機する。
次に、ブログ検索サービスとして、利用登録された複合機10に対し提供する情報を生成するブログ検索処理について説明する。図26は、機能サーバ30の制御部31が実行するブログ検索処理を表すフローチャートである。このブログ検索処理は、機能サーバ30の動作中、所定期間毎に、繰返し実行される。
ブログ検索処理を実行すると、制御部31は、まずS1401にて、ブログ検索サービスに対応するリクエストサービスID管理テーブルから、処理対象のリクエストサービスIDを、一つ選択する。ここで、上記リクエストサービスID管理テーブルにおいて処理対象のリクエストサービスIDが存在しない、即ち、S1403以降の処理対象となっていない未処理のリクエストサービスIDが存在しない場合には、S1402でNoと判断して、当該ブログ検索処理を終了する。
一方、処理対象(未処理)のリクエストサービスIDが存在すると、制御部31は、S1402でYesと判断し、処理対象のリクエストサービスIDに対応する定期問合せ返信管理テーブル内の返信管理情報が有するサービススタート情報を、値「FALSE」に更新する(S1403)。
その後、当該処理対象のリクエストサービスIDに関連付けられてリクエストサービスID管理テーブルに記憶されているパラメータの値を、キーワードに設定すると共に、予め定められた特定のブログサイトにアクセスし、そのブログサイトに掲載された新しい投稿群の中から、上記設定したキーワードを有する投稿を検索する(S1404)。
この検索時において、リクエストサービスID管理テーブルに記憶されているパラメータの値が不正な値であるなどし、エラーが発生すると、制御部31は、S1405でYesと判断し、当該処理対象のリクエストサービスIDに対応する定期問合せ返信管理テーブル内の返信管理情報が有するサービスキャンセル情報を、値「TRUE」に更新する(S1406)。
更に、エラーの発生原因に応じたサービスステータスの値を導出し、この導出値を、当該処理対象のリクエストサービスIDに対応する定期問合せ返信管理テーブル内のサービスステータス情報に、反映させる(S1407)。その後、S1401に移行して、未処理のリクエストサービスIDを、リクエストサービスID管理テーブル内から一つ選択する。
一方、S1404における検索が正常に終了すると、制御部31は、S1405でNoと判断して、S1408に移行し、上記検索の結果、上記設定されたキーワードを含む新しい投稿がブログサイトから発見されたか否か判断する。そして、新しい投稿が発見されていないと判断すると、S1401に移行する。
また、S1408において、上記設定されたキーワードを含む新しい投稿がブログサイトから発見されたと判断すると、制御部31は、S1409に移行し、上記キーワードを含む投稿の内容を表した提供用データを生成する。そして、これを、記憶部33に保存すると共に、S1410に移行し、上記保存した提供用データのダウンロード先のURL情報(例えば、文字列”http://****.co.jp/cgi/blog?f=****”等)を生成する。また、上記定期問合せ返信管理テーブルにおける当該処理対象のリクエストサービスIDに対応するサービスURL情報を、上記生成したダウンロード先(即ち、サービス提供先)のURL情報に変更する(S1411)。
S1411での処理を終えると、制御部31は、上記定期問合せ返信管理テーブルにおける当該処理対象のリクエストサービスIDに対応するサービススタート情報を、値「TRUE」に変更する(S1412)。その後、S1401に移行し、リクエストサービスID管理テーブルから、未処理のリクエストサービスIDを一つ選択する。そして、リクエストサービスID管理テーブルに列挙された全リクエストサービスIDについて、S1403以降の処理を実行すると、S1402にてNoと判断し、当該ブログ検索処理を終了する。
次に、上記ローカルニュース提供サービスについて利用登録された複合機10に対し提供する情報を生成するニュース情報生成処理について説明する。尚、図27は、機能サーバ30の制御部31が実行するニュース情報生成処理を表すフローチャートである。このニュース情報生成処理は、機能サーバ30の動作中、所定期間毎に、繰返し行われる。
ニュース情報生成処理を実行すると、制御部31は、まずローカルニュース提供サービスに対応するリクエストサービスID管理テーブルから、処理対象のリクエストサービスIDを一つ選択する(S1501)。ここで、処理対象のリクエストサービスIDが存在しない、即ち、後述するS1503以降の処理対象となっていない未処理のリクエストサービスIDが存在しない場合には、S1502でNoと判断して、当該ニュース情報生成処理を終了する。
一方、処理対象(未処理)のリクエストサービスIDが存在すると、制御部31は、S1502でYesと判断して、処理対象のリクエストサービスIDに対応する定期問合せ返信管理テーブル内の返信管理情報が有するサービススタート情報を、値「FALSE」に更新する(S1503)。
その後、当該処理対象のリクエストサービスIDに関連付けられてリクエストサービスID管理テーブルに記憶されている各パラメータの値が不正な値でないか否か判断し(S1504)、不正な値であると判断すると、エラーが生じたとして、当該処理対象のリクエストサービスIDに対応する定期問合せ返信管理テーブル内のサービスキャンセル情報を、値「TRUE」に更新する(S1505)。
更に、エラーの発生原因に応じたサービスステータスの値を導出し、この導出値を、当該処理対象のリクエストサービスIDに対応する定期問合せ返信管理テーブル内のサービスステータス情報に、反映させる(S1506)。その後、S1501に移行して、未処理のリクエストサービスIDを、リクエストサービスID管理テーブルから一つ選択する。
これに対し、S1504にて、各パラメータの値が不正な値でない(即ち、適切な値である)と判断すると、制御部31は、S1507に移行し、当該処理対象のリクエストサービスIDに関連付けられてリクエストサービスID管理テーブルに記憶されているパラメータAddress(図7,15参照)の値に合致する地域のローカルニュースデータを、特定のデータベース(図示せず)から取得する。また、S1507の処理を終えると、S1508に移行し、上記取得したローカルニュースデータを、パラメータNumPages(図7,15参照)の値に合致する頁数分の提供用データ(PDFデータ等)に変換して、提供用データを生成する。その後、この提供用データを、記憶部33に保存する。
S1508での処理を終えると、制御部31は、上記保存した提供用データのダウンロード先のURL情報を生成し(S1509)、上記定期問合せ返信管理テーブルにおける当該処理対象のリクエストサービスIDに対応するサービスURL情報を、上記生成したダウンロード先(サービス提供先)のURL情報に変更する(S1510)。
S1510での処理を終えると、制御部31は、上記定期問合せ返信管理テーブルにおける当該処理対象のリクエストサービスIDに対応するサービススタート情報を、値「TRUE」に変更する(S1511)。その後、S1501に移行し、リクエストサービスID管理テーブルから、未処理のリクエストサービスIDを一つ選択する。そして、リクエストサービスID管理テーブルに列挙された全リクエストサービスIDについて、S1503以降の処理を実行すると、S1502にてNoと判断し、当該ニュース情報生成処理を終了する。
次に、統合返信情報を受信し、この統合返信情報に基づいてサービスを受けるために、複合機10の制御部11が実行する統合返信情報受信処理について、図28を用いて説明する。尚、図28は、複合機10の制御部11が実行する統合返信情報受信処理を表すフローチャートである。
統合返信情報受信処理を実行すると、制御部11は、通信部15を介して、機能サーバ30から送信されてくる上記定期問合せ信号に対する応答信号(統合返信情報)を受信するまで待機し(S1601)、応答信号を受信すると、その応答信号に含まれる統合返信情報の中から、処理対象のリクエストサービスIDを一つ選択する(S1602)。ここで、処理対象のリクエストサービスIDが存在しない、即ち、S1604以降の処理対象となっていない未処理のリクエストサービスIDが存在しない場合には、S1603でNoと判断して、S1606に移行し、処理対象(未処理)のリクエストサービスIDが存在する場合には、S1603でYesと判断して、S1604に移行する。
S1604に移行すると、制御部11は、上記処理対象のリクエストサービスIDに対応付けて、統合返信情報に記載されているService_Statusタグに、パラメータService_Statusの値があるか否か判断する。即ち、上記処理対象のリクエストサービスIDが記載されたResponce_Serviceタグの間に記載されたService_Statusタグの間に、値が記載されているか否かを判断する。
そして、パラメータService_Statusの値がない(即ち、<Service_Status></Service_Status>)であると判断すると、S1602に移行する。一方、パラメータService_Statusの値があると判断すると、S1605に移行し、パラメータService_Statusの値に対応するステータス情報を、表示部19のディスプレイ19aに表示する。その後、制御部11は、S1602に移行し、未処理のリクエストサービスIDを一つ処理対象に選択して、再び、S1603以降の処理を実行する。
そして、統合返信情報内に記載された全てのリクエストサービスIDについて、S1604以降の処理を実行すると、S1603でNoと判断して、S1606に移行し、値「TRUE」が記載されたService_Startタグに関連付けられたリクエストサービスIDの全てについて、そのリクエストサービスIDに対応するサービスを、機能サーバ30から受けたか否か判断する。
値「TRUE」が記載されたService_Startタグに関連付けられたリクエストサービスIDの中に、機能サーバ30からサービスを受けていないリクエストサービスIDがある場合、制御部11は、S1606でNoと判断して、S1607に移行する。そして、上記統合返信情報の中から、処理対象のリクエストサービスIDを一つ選択する。
ここで、処理対象のリクエストサービスIDが存在しない、即ち、S1609以降の処理対象となっていない未処理のリクエストサービスIDが存在しない場合には、S1608でNoと判断して、S1606に移行し、処理対象(未処理)のリクエストサービスIDが存在する場合には、S1608でYesと判断して、S1609に移行する。
S1609に移行すると、制御部11は、処理対象のリクエストサービスIDに対応付けて、統合返信情報に記載されたService_Startタグに、値「TRUE」が記載されているか否か判断する。即ち、上記処理対象のリクエストサービスIDが記載されたResponce_Serviceタグの間に記載されたService_Startタグの間に、値「TRUE」が記載されているか否かを判断する。
ここで、Service_Startタグに、値「TRUE」が記載されていないと判断すると、制御部11は、S1607に移行し、値「TRUE」が記載されていると判断すると、S1610に移行して、当該処理対象のリクエストサービスIDに対応するサービスを機能サーバ30から受ける際に用いる入出力デバイス(読取部13,記録部14,音入力部17,音出力部18)が、他のプロセス(サービス)によって動作(使用)中であるか否かを、定期問合せ管理テーブルの利用デバイス情報に基づいて、判断する。
そして、上記デバイスが動作中であると判断すると、S1607に移行し、上記デバイスが動作中ではないと判断すると、S1611に移行して、処理対象のリクエストサービスIDに関連付けられた統合返信情報のService_URLタグの値を、を引数に設定し、サービス受信処理(図10)のプロセスを起動する。
その後、制御部31は、S1607に移行し、統合返信情報から、未処理のリクエストサービスIDを選択し、このリクエストサービスIDに対応付けて統合返信情報に記載されたService_Startタグに、値「TRUE」が記載されている場合には、前回起動したサービス受信処理のプロセスと並行して、更にもう一つ、サービス受信処理のプロセスを起動する。但し、並行処理するのは、S1610でNoと判断された場合のみ、即ち、現在もなお受信中のサービスとは、異なる入出力デバイスを用いるサービスについてのプロセスのみである。
即ち、S1607〜S1611の過程では、Service_Startタグに、値「TRUE」が記載されているリクエストサービスIDに対応するサービスであって、異なる入出力デバイスを利用するサービスのみのサービス受信プロセスを並行して実行する。
これに対し、同一の入出力デバイスを利用するサービスの受信プロセスについては、S1608にてNoと判断し、S1606にてNoと判断して、再び1607以降の処理を実行することで、シリアルに実行する。
そして、値「TRUE」が記載されたService_Startタグに関連付けられたリクエストサービスIDの全てについて、そのリクエストサービスIDに対応するサービスを、機能サーバ30から受けたと判断すると(換言すると、サービス受信処理のプロセスを起動したと判断すると)、制御部11は、S1606でYesと判断して、S1601に移行する。その後、次の統合返信情報を受信するまで待機する。
次に、機能サーバ30で実行されるサービス提供にかかるプロセスについて説明する。複合機10の制御部11は、ブログ検索サービス又はローカルニュース提供サービスについてのリクエストサービスIDを処理した結果、S1611にてサービス受信処理のプロセスを起動すると、そのサービスURL情報に基づいて、機能サーバ30にアクセスし、機能サーバ30に、図29に示す定期サービス提供処理を実行させる(S301)。図29は、機能サーバ30の制御部31が実行する定期サービス提供処理を表すフローチャートである。尚、サービスURL情報には、ブログ検索サービス、ローカルニュース提供サービスに関して、図29に示す定期サービス提供処理が実行される機能サーバ30側のURL情報(S405で図29に示す定期サービス提供処理のプロセスが起動される機能サーバ30側のURL情報)が記載されていることとする。
定期サービス提供処理を実行すると、制御部31は、S1701で、初期化処理を実行し、続くS1702で、サービス側印刷ジョブ(図30参照。詳細後述)を起動する。続いて、S1703では、「印刷ジョブ起動指令」を複合機指令として出力する。具体的には、S405で生成したセッションIDに対応する返信情報格納領域に対して、「印刷ジョブ起動指令」を書き込む処理を行う。
これによって、「印刷ジョブ起動指令」は、サービス制御情報処理を介し、複合機指令として、複合機10に送信される。尚、この「印刷ジョブ起動指令」には、S1702で起動したサービス側印刷ジョブについてのジョブIDとジョブの通信先URL情報とが含まれる。
S1703での処理を終えると、制御部31は、S1704に移行し、後述するサービス側印刷ジョブから印刷準備完了の通知を受けたか否か判断し、受けていない場合には、S1705に移行して、上記サービス側印刷ジョブから停止の通知を受けたか否か判断する。そして、停止の通知を受けていない場合には、S1704に処理を戻すことで、上記サービス側印刷ジョブから印刷準備完了の通知、若しくは、停止の通知を受けるまで待機する。そして、停止の通知を受けると、S1705でYesと判断して、S1708に移行する。一方、印刷準備完了の通知を受けると、S1704でYesと判断して、S1706に移行する。
S1706に移行すると、制御部31は、当該定期サービス提供処理のプロセスを起動する際に複合機10側からURL情報にて指定されたダウンロード対象の提供用データを、記憶部33から読み出し、この提供用データを、複合機10の記録部14の能力に適合した印刷データに変換する。その後、制御部31は、サービス側印刷ジョブに、上記変換した印刷データを提供することにより、サービス側印刷ジョブを介して、上記変換した印刷データを、アクセス元の複合機10に向けて出力する(S1707)。
また、S1707の処理を終えると、制御部31は、S1708に移行して、サービス側印刷ジョブが終了するまで待機し、印刷ジョブが終了すると、「印刷ジョブ終了指令」を複合機指令として出力する。具体的には、S405で生成したセッションIDに対応する返信情報格納領域に対して、「印刷ジョブ終了指令」を書き込む処理を行う。
これによって、「印刷ジョブ終了指令」は、サービス制御情報処理を介し、複合機指令として、複合機10に送信される。尚、この「印刷ジョブ終了指令」には、ジョブIDとジョブの通信先URL情報とが含まれる。
また、「印刷ジョブ終了指令」の出力が終了すると、制御部31は、S1709に移行し、「サービス終了指令」を、複合機指令として出力する。これにより、「サービス終了指令」は、複合機10にて受信される。S1709での処理を終えると、機能サーバ30の制御部31は、当該定期サービス提供処理を終了する。
次に、定期サービス提供処理(図29)のS1702にて起動されるサービス側印刷ジョブについて説明する。図30は、機能サーバ30の制御部31が実行するサービス側印刷ジョブを表すフローチャートである。尚、このサービス側印刷ジョブは、他の処理と並行して実行される。
サービス側印刷ジョブの実行を開始すると、制御部31は、まずS1801にて、複合機10から「複合機状態情報」を受信するまで待機する。尚、「複合機状態情報」は、複合機10の制御部11により実行される後述の出力ジョブ(図31)におけるS1904で送信される。
この「複合機状態情報」を受信すると、制御部31は、S1802に移行して、エラーカウントを初期化し、更に、記録部14に設定すべきパラメータを、複合機パラメータとして複合機10へ送信する(S1803)。
S1803での処理を終えると、制御部31は、S1804に移行し、複合機10において複合機パラメータが正常に受信されたか否かを判断する。具体的には、複合機10の制御部11により実行される出力ジョブ(図31)におけるS1909の処理により、「複合機受取状況」として「正常受取」が通知された場合に正常に受信されたと判断し、S1908の処理により、「複合機受取状況」として「異常受取」が通知された場合に正常に受信されなかったと判断する。
S1804で、複合機パラメータが正常に受信されなかったと判断すると、制御部31は、S1805へ移行し、正常に受信されなかったと判断された回数が2回目であるか否かを判断する。具体的には、S1802で初期化したエラーカウントに基づき判断する。
そして、S1805で、2回目でない(1回目である)と判断した場合には、S1806へ移行し、エラーカウントをカウントアップした後、S1803へ移行する。
一方、S1805で、2回目であると判断した場合には、S1807へ移行し、起動元のプロセス(定期サービス提供処理(図29)のプロセス)へ停止を通知する。その後、S1811にて、正常終了ではない(異常終了である)と判断し、S1812にて、異常終了である旨の情報を、「サービス状態情報」として複合機10へ送信した後、当該サービス側印刷ジョブを終了する。
また、S1804で、複合機パラメータが正常に受信されたと判断した場合には、S1808へ移行し、起動元の定期サービス提供処理のプロセスへ印刷準備完了を通知する。その後、S1809へ移行し、上述のS1706にて生成された印刷データを順次複合機10へ送信する。
S1809での処理を終えると、制御部31は、続くS1810にて、複合機10からの「複合機状態情報」を受信するまで待機し、「複合機状態情報」を受信すると、S1811に移行する。尚、「複合機状態情報」は、複合機10の制御部11により実行される出力ジョブ(図31)におけるS1913の処理で送信される。
S1811に移行すると、制御部31は、その後、印刷データの送信処理が正常に終了したか否か判断し、正常に終了していないと判断すると、S1812に移行し、正常に終了していると判断すると、S1813に移行して、正常終了である旨の情報を、「サービス状態情報」として複合機10へ送信する。その後、当該サービス側印刷ジョブを終了する。
次に、定期サービス提供処理(図29)のS1703にて出力される「印刷ジョブ起動指令」を受けて、複合機10の制御部11がS356にて起動する出力ジョブについて、図31のフローチャートを用いて説明する。尚、図31は、複合機10の制御部11が実行する出力ジョブを表すフローチャートである。
出力ジョブを実行すると、制御部11は、S1901で、出力装置(印刷ジョブ起動指令を受けた場合には記録部14、スピーカジョブ起動指令を受けた場合には、音出力部18)がビジー状態であるか否かを判断する。具体的には、出力装置がビジー状態であるか否かを表すビジーフラグFoに基づき、ビジーフラグFoが立っている場合にはビジー状態であると判断し、ビジーフラグFoが下りている場合にはビジー状態でないと判断する。
ここで、出力装置がビジー状態であると判断すると、制御部11は、S1902へ移行し、出力装置のビジー状態が解除されるまで待機した後、S1901へ移行する。一方、S1901で、ビジー状態でないと判断した場合には、S1903へ移行し、ビジーフラグFoを立てる。その後、制御部11は、「複合機状態情報」を機能サーバ30へ送信する(S1904)。尚、ここで送信される「複合機状態情報」には、セッションID、ジョブID等が含まれる。
S1904の処理を終えると、制御部11は、S1905に移行し、上記送信した「複合機状態情報」に対する応答信号として送信される複合機パラメータを機能サーバ30から受信する。尚、複合機パラメータは、機能サーバ30の制御部31により実行されるサービス側印刷ジョブのS1803で送信される。
S1905の処理が終了すると、制御部11は、起動元のサービス受信処理のプロセスから、終了指示が入力されたか否かを判断する(S1906)。尚、終了指示は、複合機10の制御部11により実行されるサービス受信処理(図10)のS310にて出力される。そして、終了指示が入力されていないと判断すると、S1907に移行し、S1905で複合機パラメータを正常に受信できたか否かを判断する。
S1907で正常に受信できなかったと判断すると、制御部11は、S1908へ移行し、複合機10が機能サーバ30からの情報を正常に受け取ることができたか否かの通知である「複合機受取状況」として、「異常受取」を機能サーバ30へ通知し、S1905へ移行する。尚、「複合機受取状況」には、セッションID及びジョブIDが含まれる。
一方、S1907で正常に受信できたと判断すると、制御部11は、S1909へ移行し、「複合機受取状況」として正常受取である旨の「正常受取」を機能サーバ30へ通知する。続いて、S1910では、出力データ(印刷データや音データ)を機能サーバ30から受信する。尚、印刷データは、機能サーバ30の制御部31により実行されるサービス側印刷ジョブ処理(図30)のS1809で送信される。
S1910の処理を終了すると、制御部11は、S1911へ移行し、上記複合機パラメータを出力装置(記録部14又は音出力部18)にセットし、出力データを出力する処理を行う。
例えば、出力ジョブが、機能サーバ30の定期サービス提供処理から出力される「印刷ジョブ起動指令」を受けて起動されたものである場合には、出力装置としての記録部14を用いて、機能サーバ30から提供される印刷データに基づく印刷出力処理を行う。
具体的に、定期サービス提供処理のプロセスが、ブログ検索サービスを複合機10に提供するためのプロセスであり、当該出力ジョブが、このブログ検索サービスを受けるためのプロセスである場合には、ブログ検索処理にて検索された投稿内容を、記録部14を通じて印刷出力する。
その他、定期サービス提供処理のプロセスが、ローカルニュース提供サービスを複合機10に提供するためのプロセスであり、当該出力ジョブが、このローカルニュース提供サービスを受けるためのプロセスである場合には、ニュース情報生成処理にて生成されたニュースデータに基づく情報を、記録部14を通じて印刷出力する。
S1911での処理を終えると、制御部11は、S1911で出力装置に設定したパラメータを元の値に戻し(S1912)、「複合機状態情報」を機能サーバ30に向けて送信する(S1913)。S1913の処理後には、S1914に移行し、「サービス状態情報」を機能サーバ30から受信する。その後、S1915に移行して、S1903で立てたビジーフラグFoを下ろし、当該出力ジョブを終了する。
以上、本実施例の通信システム1について説明したが、この通信システム1では、機能サーバ30と、クライアント装置としての複合機10との間でHTTP通信を行うことにより、機能サーバ30から複合機10に対して、複数種のサービス(ブログ検索サービスやローカルニュース提供サービス等)を提供する。
複合機10は、機能サーバ30が、定期的に提供する複数種のサービスの内、自装置が機能サーバ30から受けるサービス毎に(具体的にはリクエストサービスID毎に)、そのサービスの問合せ時期を示す情報として、問合せ間隔情報及び残り時間情報と、即時処理情報とを、定期問合せ管理テーブルに記憶しており、この問合せ間隔情報及び残り時間情報並びに即時処理情報に基づいて、自装置が機能サーバ30から受けるサービス毎に、定期問合せ信号の送信時期が到来したか否かを、S904〜S906にて判断し、送信時期が到来したと判断すると(S906でYesと判断すると)、S908にて、上記送信時期が到来したと判断したサービスの識別情報としてのリクエストサービスIDを、まとめて記述した統合問合せ情報を生成し、統合問合せ情報を格納した定期問合せ信号を、通信デバイスとしての通信部15を通じ、機能サーバ30に向けて送信する(S911)。
また、複合機10は、統合返信情報受信処理にて、定期問合せ信号に対する応答信号を、通信部15を介し機能サーバ30から受信すると、応答信号に含まれる統合返信情報に記載のリクエストサービスIDのパラメータService_Startが値「TRUE」であるか否かを判断することにより、そのリクエストサービスIDに対応するサービスが、機能サーバ30にて提供する準備が完了しているサービスであるか否かを判断し(S1609)、機能サーバ30にて提供する準備が完了していると判断したサービスについては、そのサービスを受けるために必要なサービス受信処理(及び入力ジョブ/出力ジョブ)を実行して(S1611)、機能サーバ30からサービスを受ける。
一方、機能サーバ30は、複合機10から送信されてくる上記複数種のサービスに関する定期問合せ信号を、定期問合せ応答処理にて通信部32を介して受信する(S1101)と共に、定期問合せ信号を受信すると、その定期問合せ信号に含まれるリクエストサービスIDに基づき、問合せ対象のサービスについての返答情報である定期問合せ返信情報を生成し、この定期問合せ返信情報をまとめて統合返信情報を生成し(S1114)、これを格納した応答信号を、問合せ元の複合機10に向けて送信する(S1115)。
このように本実施例の通信システム1では、複数の問合せ対象がある場合、これらの問合せを示す情報をまとめて定期問合せ信号に格納し、機能サーバ30に向けて送信するので、各サービス(各リクエストサービスID)について個々に問合せ信号を生成し、これを機能サーバ30に送信するよりも、ネットワークトラフィックを抑えることができ、効率的に問合せを行うことができる。また、複数の問合せに対する返答を、統合返信情報にまとめて記述して、複合機10に向けて送信するので、効率的に問合せに対する返答を行うことができる。
また、本実施例では、S904にて、予め定められた問合せの実行猶予期間(前回の定期問合せ信号の送信時点から所定時間)が経過したか否かを判断すると共に、S905にて、定期問合せ管理テーブルが記憶する各サービスの即時処理情報に基づき、自装置が機能サーバ30から受けるサービス毎に、即時の問合せが必要か否かを判断し、更に、S906にて、定期問合せ管理テーブルが記憶する各サービスの残り時間情報に基づき、自装置が機能サーバ30から受けるサービス毎に、問合せ時刻が到来したか否かを判断するようにした。
そして、S906にて問合せ時刻が到来したと判断されたサービスが存在しない場合(即ち、残り時間がゼロ以下であるサービスが存在しない場合、又は、残り時間がゼロ以下であるサービスが存在しても、即時の問合せが必要であり残り時間がゼロ以下であるサービスが存在しない場合であって実行猶予期間が経過していない場合)には、定期問合せ信号をS911で送信しないようにし、S906にて問合せ時刻が到来したと判断されたサービスが存在する場合(即ち、即時の問合せが必要であり残り時間がゼロ以下であるサービスが存在する場合、又は、実行猶予期間が経過しており残り時間がゼロ以下であるサービスが存在する場合)にのみ、定期問合せ信号をS911で送信するようにした。
従って、本実施例の通信システム1によれば、問合せを効率よくまとめて実行することができると共に、即時の問合せが必要なサービスについては、直ちに、問合せを実行することができ、大変便利である。
また、本実施例の通信システム1では、問合せ対象のサービスについてのリクエストサービスIDを、問合せ内容を表すパラメータ(Request_Status)の値が同一であるリクエストサービスID毎にまとめて記述し、まとめて記述したリクエストサービスIDの一群に対し、上記パラメータの値を関連付けて記述して、統合問合せ情報を生成するようにした。従って、本実施例によれば、パラメータ(Request_Status)の値を複数回、統合問合せ情報に記述する必要がなく、統合問合せ情報のデータ量を抑えることができて、一層、ネットワークトラフィックを抑えることができる。
また同様に、本実施例の通信システム1では、返答情報としてのパラメータService_Start,Service_URL,Service_Status,Service_Canceledの値)が同一であるリクエストサービスIDを、まとめて記述し、まとめて記述した上記リクエストサービスIDの一群に対し、上記パラメータの値を関連付けて記述して、統合返信情報を生成するようにした。従って、本実施例によれば、統合返信情報のデータ量を抑えることができて、効率的にネットワークトラフィックを抑えることができる。
また、本実施例では、返信判断処理を実行することにより、特定のパラメータ値を返答するサービスについての情報(Respoce_Serviceタグ)のみを統合返信情報に格納して、応答信号を送信するようにし、それ以外の返答となるサービス(具体的には、返信判断処理のS1305で返信NGと判断されるサービス)についての情報を、応答信号に格納しないようにしたので、効率的に、応答信号のデータ量を抑制することができ、ネットワークトラフィックを抑えることができる。
また、本実施例の通信システム1では、機能サーバ30から提供されるサービスを、複合機10側で、入出力デバイスとしての読取部13(スキャナ)、記録部14(プリンタ)、音入力部17、音出力部18の一つ又は複数を用いて受けるが、定期問合せ信号の送信時期が到来したサービスであっても、そのサービスを受けるために駆動が必要な入出力デバイスが動作中である場合には、S907でYesと判断して、そのサービスについてのリクエストサービスIDを統合問合せ情報に記述しないことにより、サービスを受けるために駆動が必要な入出力デバイスが動作中ではないサービスについてのみの定期問合せを選択的に行うようにした。従って、本実施例によれば、定期問合せに関し、一層の効率化を図ることができる。
その他、本実施例では、機能サーバ30にて提供する準備が完了していると判断された各サービスを受けるために必要なサービス受信処理(及び入力ジョブ/出力ジョブ)を、夫々、利用する入出力デバイスが重複しないかぎりにおいて(即ち、S1610でNoである場合に限り)、並列に実行すると共に、利用する入出力デバイスが重複する場合には、S1607〜S1611の処理を、S1606でYesと判断するまで繰り返すことにより、シリアルに順次、各サービスに対応するサービス受信処理を実行するようにした。
従って、本実施例によれば、複合機10を通じて、利用者に対し、効率的にサービスを提供することができる。
尚、上記実施例では、「スピーカジョブ起動指令」を出力する機能サーバ30のサービス(定期サービス提供処理)について詳しく説明しなかったが、そのサービスについての定期サービス提供処理は、基本的に図29,30に示す処理と同様であって、図29,30における「印刷」との文言を「スピーカ」と置き換え、「印刷データ」の代わりに「音データ」を出力するものと解釈して差し支えない。
その他、上記実施例では、「入力ジョブ起動指令」を出力する機能サーバ30のサービス(定期サービス提供処理)について詳しく説明しなかったが、入力ジョブ起動指令(「スキャナジョブ起動指令」又は「ボイスジョブ起動指令」)を出力する機能サーバ30の定期サービス提供処理は、入力ジョブ起動指令(「スキャナジョブ起動指令」又は「ボイスジョブ起動指令」)を複合機10に出力すると共に、その入力ジョブ起動指令にて複合機10側で起動された入力ジョブに基づき入力装置(読取部13、音入力部17)が生成したデータを、複合機10から取得することにより、複合機10に対しサービスを提供するものとすることができる。
尚、本発明のサーバ装置が有する受信手段及び返信手段は、図22に示す定期問合せ応答処理にて実現されている。また、本発明のクライアント装置が有する時期判断手段は、S904〜S906の処理にて実現されており、問合せ手段は、S907〜S911の処理にて実現されている。また、デバイス動作判断手段は、S907の処理にて実現されており、受信手段は、統合返信情報受信処理にて実現されている。
また、本発明の通信システム及び通信装置は、上記実施例に限定されるものではなく、種々の態様を採ることができる。
例えば、上記実施例では、パラメータの値が同一であるリクエストサービスIDについては、それらリクエストサービスIDの一群に対してパラメータの値を示したタグを共通に設け、統合問合せ情報及び統合返信情報を生成するようにしたが、上記通信システム1では、図32及び図33に示すように、統合問合せ情報及び統合返信情報を生成してもよい。即ち、パラメータの値が同一であるか否かに拘らず、リクエストサービスID毎に、その問合せ(返答)の内容を表すパラメータの値を記載してもよい。
1…通信システム、2,3,4…ルータ、10…複合機、11…制御部、12…操作部、13…読取部(スキャナ)、14…記録部(プリンタ)、15…通信部、16…記憶部、17…音入力部、18…音出力部、19…表示部、19a…ディスプレイ、20…ディレクトリサーバ、21…制御部、22…通信部、23…記憶部、24…サービス定義情報記憶部、25…サービス定義情報、30…機能サーバ、31…制御部、32…通信部、33…記憶部、34…サービスI/F情報記憶部、35…サービスソフト記憶部、36…サービスI/F情報、37…サービスソフトウェア、40…DNSサーバ、NT…ネットワーク