JP2006134112A - ファイル取得システムおよび端末装置 - Google Patents

ファイル取得システムおよび端末装置 Download PDF

Info

Publication number
JP2006134112A
JP2006134112A JP2004322947A JP2004322947A JP2006134112A JP 2006134112 A JP2006134112 A JP 2006134112A JP 2004322947 A JP2004322947 A JP 2004322947A JP 2004322947 A JP2004322947 A JP 2004322947A JP 2006134112 A JP2006134112 A JP 2006134112A
Authority
JP
Japan
Prior art keywords
file
terminal
storage means
information
server
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.)
Granted
Application number
JP2004322947A
Other languages
English (en)
Other versions
JP4513509B2 (ja
Inventor
Kiyotaka Ohara
清孝 大原
Kazuma Aoki
一磨 青木
Makoto Matsuda
誠 松田
Masafumi Miyazawa
雅史 宮澤
Chol Yoo
哲 柳
Masatoshi Kokubo
雅俊 小久保
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 JP2004322947A priority Critical patent/JP4513509B2/ja
Priority to US11/266,586 priority patent/US7778495B2/en
Priority to EP05256881.3A priority patent/EP1655945B1/en
Publication of JP2006134112A publication Critical patent/JP2006134112A/ja
Application granted granted Critical
Publication of JP4513509B2 publication Critical patent/JP4513509B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Landscapes

  • Information Transfer Between Computers (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

【課題】 より効率的なキャッシュ機構を備えたファイル取得システム等を提供する。
【解決手段】 第一種グループＩＤ（メイングループＩＤのみから構成されるもの）と第二種グループＩＤ（メイングループＩＤとサブグループＩＤとから構成されるもの）との２種類に分けキャッシュを管理し、削除ファイル決定処理１（Ｓ１６１）によって決定された条件（ＵＲＬ単位またはグループＩＤ単位の条件）に合致するファイルをキャッシュから削除する（Ｓ１６５）。
【選択図】図１９

Description

本発明は、蓄積されているファイルを取得して利用することができるファイル取得システム等に関する。
広く知られているように、ファイル取得システムの一つであるＷＷＷ（World Wide Web）は、インターネット上のサーバにＨＴＭＬ（HyperText Markup Language）等によって記述されたページファイルを蓄積されていて、端末装置からの要求にしたがいサーバから端末装置へページファイルが送信され、端末装置のディスプレイ等にそのページファイルの内容が表示されるという仕組みを備えたものである。
ところが、端末装置からの要求がある都度そのページファイルをサーバが送信するようになっていると、サーバの処理負荷の増大やネットワークの帯域の圧迫という問題をもたらすことにつながるため、キャッシュ機構と呼ばれるこれらの問題を軽減する仕組みが利用されることが多い。このキャッシュ機構というのは、端末装置とホストコンピュータの間に位置するＨＴＴＰ（HyperText Transfer Protocol）プロキシサーバや端末装置自体が備える仕組みであり、一度アクセスしたページファイルとそのページファイルのＵＲＬとを対にしてハードディスク等に記憶しておき、再度同じページファイルを利用する必要が生じた場合にサーバからそのページファイルを再度取得するのではなく、ハードディスク等から読み出して利用するものである（例えば特許文献１参照）。
しかし、このようなキャッシュ機構を実現するためのハードディスク等には容量的な制限があるためアクセスした全てのページファイル等を記憶し続けることは不可能である。このため、ハードディスク等からページファイル等を削除する仕組みが備わっている。その仕組みの代表的なものの一つとして、ページファイルをサーバから取得した時間、または記憶させておいたページファイルに最後にアクセスした時間を記憶しておき、ハードディスク等の容量制限に達したときに、その記憶しておいた時間の最も古いページファイルから順に削除するような仕組みが知られている。
特開平６−２９００９０号公報
ところが、このような仕組みでページファイル等を削除するようになっていると次のような問題が生じる場合がある。例えば、閲覧者には頻繁にアクセスする好みのＷｅｂサイトがある場合が多い。しかし、そのＷｅｂサイトを構成するページのうちある特定のページには頻繁にアクセスするが、そのＷｅｂサイトを構成する別のページにはときどきしかアクセスしないようなケースがでは、上述した仕組みでページファイル等を削除するようになっていると、そのときどきしかアクセスされないページのページファイル等が新たにアクセスされた別のＷｅｂサイトのページファイルが記憶される際に削除されてしまうことが考えられる。
しかし、閲覧者が時々しかアクセスしないページであっても好みのＷｅｂサイトを構成するページであるため、新たにアクセスした別のＷｅｂサイトのページよりも再表示される可能性が高いことが十分に考えられる。
したがって、上述したような仕組みでページファイル等を削除するようになっていることは、このようなケースではページファイルの再取得が行われ、必ずしもサーバの処理負荷の増大やネットワーク帯域の圧迫という問題を効率的に解決しているとは言い難い。また、閲覧者にとっても、過去にアクセスしたことがある同一のＷｅｂサイト内で閲覧時のレスポンスにばらつきが生じ、閲覧者の使い勝手を阻害する原因の一つとなり得る。
本発明はこのような問題に鑑みなされたものであり、より効率的なキャッシュ機構を備えたファイル取得システム等を提供することを目的とする。
上記課題を解決するためになされた請求項１に記載のファイル取得システムは、ファイルを蓄積しているサーバと、そのサーバからファイルを取得して利用する端末装置とから少なくとも構成される。サーバは、ファイルをグルーピング情報に関連づけて記憶するサーバ側記憶手段と、端末装置と通信を行うサーバ側通信手段と、サーバ側通信手段を介して端末装置から要求されたファイルをサーバ側記憶手段から読み出し、その読み出したファイルをそのファイルに関連づけられたグルーピング情報と共に要求元の端末装置へサーバ側通信手段を介して送信するサーバ側制御手段と、を備える。一方、端末装置は、サーバと通信を行う端末側通信手段と、ファイルをグルーピング情報に関連づけて記憶する端末側記憶手段と、ファイルが必要となった際、その必要なファイルが端末側記憶手段に記憶されているか否かを判定し、その必要なファイルが端末側記憶手段に記憶されている場合にはその記憶されているファイルを利用し、その必要なファイルが端末側記憶手段に記憶されていない場合にはサーバに要求を行い、サーバから端末側通信手段を介して送られてきたファイルをそのファイルのグルーピング情報に関連づけて端末側記憶手段に記憶させる端末側制御手段と、を備える。そして、端末側制御手段は、送られてきたファイルをそのファイルのグルーピング情報に関連づけて端末側記憶手段に記憶させる際、予め定められた記憶上限に端末側記憶手段が達しているか否かを判定し、記憶上限に端末側記憶手段が達している場合には、端末側記憶手段が記憶しているファイルのうち、所定の条件を満たすグルーピング情報に対応するファイルを端末側記憶手段から検索し、検索されたファイルを端末側記憶手段から削除すると共に、送られてきたファイルをそのファイルのグルーピング情報に関連づけて端末側記憶手段に記憶させ、一方、記憶上限に端末側記憶手段が達していない場合には、端末側記憶手段からファイルを削除することなく送られてきたファイルをそのファイルのグルーピング情報に関連づけて端末側記憶手段に記憶させる。
なお、ここで言う「グルーピング情報」というのは、所定の規則や条件等によって分けられたファイルのグループを識別するための情報であり、例えば文字列や数値等から構成されるものである。また、ここで言うグループというのは、同階層の集まりだけを表すものだけではなく、複数階層に渡る関係を表すものも意味する。例えば、第一階層にはＡというファイルがあり、第二階層にはＢ，Ｃ，Ｄというファイルがあり、第三階層にはＥ，Ｆ，Ｇというファイルがある場合に、Ｂ，Ｃ，ＤはＡに属し、Ｅ，Ｆ，ＧはＣに属するという情報も表す。
このようなファイル取得システムによれば、グルーピング情報単位で削除対象か否かが判断されてファイルの削除が行われるため、例えばＷｅｂサイト単位でグルーピング情報を設定すれば、お気に入りのＷｅｂサイト内に前回のアクセス時間が古いページやアクセス頻度の低いページがあったとしてもＷｅｂサイト単位で他のＷｅｂサイトよりも所定の条件に該当しづらいのであればその前回のアクセス時間が古いページやアクセス頻度の低いページのページファイルは削除されない。
したがって、たまたま一度だけ取得したファイルによって再利用可能性の高いファイルが端末側記憶手段から削除される可能性が減り、ファイルの再取得が行われる確率も低減する。つまり、サーバの処理負荷の軽減やネットワーク帯域の使用率の軽減につながる。また、端末装置の使用者にとっても、過去に利用したことがある同一のグルーピング情報を有するファイル同士の利用時におけるレスポンスの差が軽減され、端末装置の使用者の使い勝手も向上する。
ところで、サーバ側記憶手段は、全てグルーピング情報に関連づけられたファイルのみを記憶するようになっていてもよいが、グルーピング情報に関連づけられていないファイルも記憶するようになっていてもよい。そして、サーバ側制御手段は、送信を行う際、対象のファイルが何れのグルーピング情報にも関連づけられていないファイルであった場合にはそのファイルをサーバ側記憶手段から読み出し、サーバ側通信手段を介して端末装置に送信するようになっているとよい。また、端末側制御手段は、サーバから何れのグルーピング情報にも関連づけられていないファイルが送られてきた場合には、その送られてきたファイルを端末側記憶手段に記憶させるが、その際、予め定められた記憶上限に端末側記憶手段が達しているか否かを判定し、記憶上限に端末側記憶手段が達している場合には、端末側記憶手段が記憶しているファイルのうち、所定の条件を満たすファイルまたはその所定の条件を満たすグルーピング情報に対応するファイルを端末側記憶手段から検索し、その検索したファイルを端末側記憶手段から削除すると共に、送られてきたファイルを端末側記憶手段に記憶させ、一方、記憶上限に端末側記憶手段が達していない場合には、端末側記憶手段からファイルを削除することなく送られてきたファイルを端末側記憶手段に記憶させるようになっているとよい（請求項２）。
このようになっていれば、サーバ管理者がサーバ側記憶手段の記憶するファイルのグルーピング情報付けを、非設定も含む形で適切に行うことにより、端末装置にキャッシュファイル（端末側記憶手段が記憶しているファイル）の削除をより柔軟に行わせることができる。つまり、端末装置にグルーピング情報単位でキャッシュファイルを削除させたり、ファイル単位でキャッシュファイルを削除させたりすることができる。
また、グルーピング情報は、メイングルーピング情報（例えば”ＡＡＡ”）のみからなる第一種グルーピング情報と、メイングルーピング情報およびサブグルーピング情報（例えば”００１”）の結合からなる第二種グルーピング情報（例えば”ＡＡＡ−００１”）とに分類できるようになっているとよい。そして、端末側制御手段は、検索の際、所定の条件を満たすグルーピング情報が第一種グルーピング情報であった場合には、その第一種グルーピング情報のメイングルーピング情報を有する第二種グルーピング情報に関連づけられたファイルが端末側記憶手段に記憶されているか否かを判定し、端末側記憶手段に該当ファイルが記憶されている場合には、所定の条件を満たす第一種グルーピング情報を所定の条件から除外して再度検索を行うようにするとよい（請求項３）。なお、端末側記憶手段に該当ファイルが記憶されていない場合には、そのまま後続の処理を続けるようにすればよい。
このようになっていれば、削除対象の第一種グルーピング情報のメイングルーピング情報を有する第二種グルーピング情報に関連づけられたファイルが端末側記憶手段に１つでも存在すれば、削除対象である第一種グルーピング情報に関連づけられたファイルが端末側記憶手段から削除されることがなくなる。つまり、サーバ側記憶手段に記憶されているファイルが階層構造の関係を有するファイルである場合に、端末装置において、下位階層（第二種グルーピング情報に関連づけられたグループ）のファイルが端末側記憶手段に記憶されているにもかかわらず上位階層（第一種グルーピング情報に関連づけられたグループ）のファイルが端末側記憶手段から削除されるということがなくなる。一般的に、下位階層のファイルの後に上位階層のファイルが利用される場合は非常に多いため、そのような場合に上位階層のファイルが端末側記憶手段に記憶されておらずサーバから再取得が行われるというケースを減らすことができる。
ところで、端末側制御手段は、サーバから端末側通信手段を介して送られてきたファイルを記憶させたときに予め定められた記憶上限に端末側記憶手段が達するか否かに基づき、記憶上限に端末側記憶手段が達しているか否かの判定を行うようになっていてもよい（請求項４）。
このようになっていても、端末側記憶手段の記憶量を適切に保つことができる。
次に、上述した「所定の条件」について言及する。
端末側制御手段は、ファイルが必要となった時の時刻の情報をファイルまたはグルーピング情報に対応させて端末側記憶手段に記憶させるようになっており、時刻情報を所定の条件として、グルーピング情報によって関連づけられたファイルを検索するようになっているとよい（請求項５）。なお、既に端末側記憶手段に記憶されているファイルについては、新たに時刻情報を記憶させるのではなく更新記憶させる。
このようになっていれば、例えば最終利用時刻に基づき、古いキャッシュファイルから削除を行うことができるため、端末側記憶手段には比較的新しい時刻に利用されたファイルが残るようにすることができる。
また、「所定の条件」は次のようなものでもよい。つまり、端末側記憶手段は、ファイルが必要となった頻度の情報をファイルまたはグルーピング情報に対応させて端末側記憶手段に記憶させるようになっており、頻度情報を所定の条件として、グルーピング情報によって関連づけられたファイルを検索するようになっていてもよい（請求項６）。
このようになっていれば、利用頻度に基づき、例えば利用頻度が少ないキャッシュファイルから削除を行うことができるため、端末側記憶手段には比較的利用頻度の高いファイルが残るようにすることができる。
ところで、所定の条件として、「対応する頻度が最も低いもの」という条件を用いて検索を行うようになっている場合には、次のような不適切なケースが発生することが考えられる。例えば、端末側記憶手段に記憶されているファイルまたはグルーピング情報に対する上記頻度のうち最も頻度が少ないものが１０回／日であるような場合（つまり最も頻度が少ないと言っても十分に頻度が高いような場合）、たまたま一度だけ利用したファイルを端末側制御手段に記憶するために、既に端末側記憶手段に記憶されている高頻度に利用されているファイルを削除することはファイルの再取得を防ぐという意味において不適切な場合も多い。このため、端末側記憶手段は、削除を行う際、削除対象のファイルに対応する頻度が所定値以上の場合には削除を行わず、サーバから送られてきたファイルを端末側記憶手段に記憶させることも行わないようになっていてもよい（請求項７）。
このようになっていれば、上述したような不適切なケースを防止することができ、よりサーバの処理負荷の軽減やネットワーク帯域の使用率の軽減につながる。また、端末装置の使用者にとっても、過去に利用したことがある同一のグルーピング情報を有するファイル同士の利用時におけるレスポンスの差がより軽減され、端末装置の使用者の使い勝手も向上する。
なお、端末側制御手段は、頻度情報を過去のものほど値を減少させて扱うようになっているとよい（請求項８）。このようになっていれば、最近はほとんどアクセスしないものの過去に多量にアクセスしていたような場合についても、削除するか否かの判断を適切に行うことができる。
ところで、端末装置は、さらに、情報を印刷媒体に印刷する印刷手段を備えることによりプリンタ装置として機能し、その機能を実現する際のユーザーインターフェースの少なくとも一部をサーバから送られてきたファイルに基づいて構成するようになっていてもよい（請求項９）。また、端末側装置は、さらに、印刷媒体に印刷された情報を読み取り、その読み取った情報を外部に送信するスキャナ手段を備えることによりスキャナ装置として機能し、その機能を実現する際のユーザーインターフェースの少なくとも一部をサーバから送られてきたファイルに基づいて構成するようになっていてもよい（請求項１０）。また、端末側装置は、さらに、情報を電話回線を介して他の端末装置に送信するファクシミリ手段を備えることによりファクシミリ装置として機能し、その機能を実現する際のユーザーインターフェースの少なくとも一部をサーバから送られてきたファイルに基づいて構成するようになっていてもよい（請求項１１）。
なお、ここで言う「ユーザーインターフェースの少なくとも一部をサーバから送られてきたファイルに基づいて構成する」というのは、ユーザーインターフェースの構成に関するデータ（例えばディスプレイの表示内容やタッチパネルの感知領域に関するデータ等）がサーバから送られてきたファイルに含まれており、そのデータにしたがってユーザインターフェース（ディスプレイ等）を構成することを意味する。
端末装置がこのような装置として機能するようになっていれば、サーバ側に記憶させておいたファイルを変更することによって各機能のユーザーインターフェースを変更することができる。つまり、サーバの管理者の意向によってこのような機能を有する端末装置のユーザーインターフェースを容易に変更することができる。しかし、一般論としてサーバ側に記憶させておいたファイルを変更することによって端末装置のユーザーインターフェースを変更するような場合は、端末装置の利用者の操作に対する端末装置のレスポンスにばらつきが起きやすい。例えば、トップメニューおよびサブメニューＡのファイルは端末装置に記憶されているが、サブメニューＢのファイルは以前に端末装置から消されてしまっていたとする。このような場合、端末装置の利用者は、サブメニューＢを表示させようとした際に通信待ちを強いられることになる。このことは、特に使い勝手の悪さを利用者に印象づける結果となりやすいと推測される。
このため、本発明のファイル取得システムにおけるサーバ側記憶手段に、例えば同一グルーピング情報を機能毎のユーザーインターフェースに対応させてファイルを設定して記憶させておけば、その機能における各サブ機能のユーザーインターフェースが呼び出されるまでの時間が従来より均一化され、端末装置の利用者に使い勝手の良さを印象づけることができる。上記例で言えば、トップメニューとサブメニューＡとサブメニューＢとが機能的な観点からセットで使われることが多い場合それらのファイルに同一グルーピング情報を設定しておけば、端末装置にこれらのファイルが記憶された後はトップメニューとサブメニューＡとサブメニューＢとを表示させる際の時間が均一化される。すなわち、グルーピング情報単位でキャッシュファイルの削除を行うということは、上述したようなプリンタ装置、スキャナ装置、ファクシミリ装置として端末装置が機能する場合に特に有効である。
また、請求項１２に記載のような、サーバと通信を行う端末側通信手段と、ファイルをグルーピング情報に関連づけて記憶する端末側記憶手段と、ファイルが必要となった際、その必要なファイルが端末側記憶手段に記憶されているか否かを判定し、その必要なファイルが端末側記憶手段に記憶されている場合にはその記憶されているファイルを利用し、その必要なファイルが端末側記憶手段に記憶されていない場合にはサーバに要求を行い、サーバから端末側通信手段を介して送られてきたファイルをそのファイルのグルーピング情報に関連づけて端末側記憶手段に記憶させる端末側制御手段と、を備えた端末装置であって、端末側制御手段は、送られてきたファイルをそのファイルのグルーピング情報に関連づけて端末側記憶手段に記憶させる際、予め定められた記憶上限に端末側記憶手段が達しているか否かを判定し、記憶上限に端末側記憶手段が達している場合には、端末側記憶手段が記憶しているファイルのうち、所定の条件を満たすグルーピング情報に対応するファイルを端末側記憶手段から検索し、検索されたファイルを端末側記憶手段から削除すると共に、送られてきたファイルをそのファイルのグルーピング情報に関連づけて端末側記憶手段に記憶させ、一方、記憶上限に端末側記憶手段が達していない場合には、端末側記憶手段からファイルを削除することなく送られてきたファイルをそのファイルのグルーピング情報に関連づけて端末側記憶手段に記憶させる端末装置は、上述した各ファイル取得システムの一部を構成することができ、所定のサーバと組み合わせることにより上述した効果を導くことができる。
なお、上述した請求項２〜請求項１１の何れかに記載のファイル取得システムが備える端末装置も、上述した請求項２〜請求項１１の何れかに記載のファイル取得システムが備えるサーバと組み合わせることによって、それぞれ上述した各ファイル取得システムと同様の効果を得ることができる。
以下、本発明が適用された実施形態について、［構成および動作］、［効果］、［変形例］、［本発明との対応関係］の順に説明する。
［構成および動作］
（１）全体構成
本発明が適用された、ネットワークを介したサービスの提供が行われるサービス提供システムは、図１に示すように、複合機１０，ディレクトリサーバ２０，機能サーバ３０などからなり、これらがネットワーク（本実施形態ではインターネット等の広域ネットワーク）１を介してデータ通信可能に接続されている。具体的にいうと、複合機１０，ディレクトリサーバ２０および機能サーバ３０は、それぞれルータ（Ｒ；周知のブロードバンドルータ）２〜４を介してネットワーク１と接続されている。
複合機１０は、制御部１１，操作部１２，読取部１３，記録部１４，通信部１５，記憶部１６，音入力部１７および音出力部１８などを備えている。
これらのうち、制御部１１は、ＣＰＵ，ＲＯＭ，ＲＡＭ等を備え、このＣＰＵが、ＲＯＭに記憶されているプログラムに従って複合機１０全体を統括制御する。
また、操作部１２は、図２に示すように、コピーキー４１，スキャナキー４２，ＦＡＸキー４３，サービスキー４４，設定キー４５，上下左右の方向キー４６〜４９，ＯＫキー５０およびキャンセルキー５１，ディスプレイ５２などからなるユーザーインターフェースとして構成されている。
図１に説明を戻し、また、読取部１３は、スキャナとしての機能を実現するための入力デバイスであり、用紙等のシート状記録媒体に記録（例えば印刷）された画像を読み取り、その画像を表す画像データを生成する。
また、記録部１４は、プリンタとしての機能を実現するための出力デバイスであり、画像データの表す画像を用紙等のシート状記録媒体に印刷する。
また、通信部１５は、複合機１０をネットワーク１に接続すると共に、このネットワーク１を介してデータを送受信するための処理を行う。
また、記憶部１６は、図示しないハードディスク等の不揮発性の記憶媒体を備えており、入出力したデータ等を記憶することができる。なお、その記憶媒体にはキャッシュ領域が確保されており、そのキャッシュ領域には通信部１５を介して受信したデータ等を一時保存（いわゆるキャッシュ）することができるようになっている。このキャッシュ領域には、キャッシュしているファイルを管理するためのキャッシュ管理情報と、キャッシュしているファイルと、が関連づけられて記憶されている。ここでキャッシュ管理情報について、図３１を用いて説明する。図３１に示すように、キャッシュ管理情報は、要求先のアドレスであるＵＲＬ（Uniform Resource Locator）と、そのアドレスのグルーピング情報であるグループＩＤ（Group ID）と、キャッシュファイルのファイル名称（Filename）と、キャッシュにファイルを保存した時刻または再取得の指令があった時刻である時間情報（Time）とから構成される。なお、グループＩＤは任意項目である。また、グループＩＤは、第一種グループＩＤと第二種グループＩＤとに分類され、第一種グループＩＤはメイングループＩＤ（図３１に例示したデータでは二つ目のダブルスラッシュ（//）より前の文字列）のみからなり、第二種グループＩＤはメイングループＩＤとサブグループＩＤ（図３１に例示したデータでは二つ目のダブルスラッシュ（//）より後の文字列）とからなる。
図１に説明を戻し、また、音入力部１７は、本複合機１０が備える図示しないハンドセット（受話器）に設けられたマイクから音を入力し、その音を表す音データ（ＰＣＭデータ）を生成する。
そして、音出力部１８は、音データ（ＰＣＭデータ）の表す音を、図示しないハンドセットに設けられたスピーカ、又は、複合機１０本体に設けられた図示しないスピーカから出力する。
ディレクトリサーバ２０は、制御部２１，通信部２２および記憶部２３を備えている。
これらのうち、制御部２１は、ＣＰＵ，ＲＯＭ，ＲＡＭ等を備え、このＣＰＵが、ＲＯＭに記憶されているプログラムに従ってディレクトリサーバ２０全体を統括制御する。
また、通信部２２は、ディレクトリサーバ２０をネットワーク１に接続すると共に、このネットワーク１を介してデータを送受信するための処理を行う。
そして、記憶部２３は、図示しないハードディスクを備えており、このハードディスクにデータを記憶する。この記憶部２３には、後述するサービス定義情報２５を記憶するためのサービス定義情報記憶部２４が設けられている。このサービス定義情報２５は、ＸＭＬ（eXtensible Markup Language）により記述されたデータであり、この記述内容に従って後述するサービス選択用画面を表示することで（図１０（ａ）参照）、機能サーバ３０が提供可能なサービス一覧（各サービスの種類及び要求先アドレス（ＵＲＬ）を提供することができる。なお、このサービス定義情報２５における各タグの定義付けを図３に示す。
機能サーバ３０は、制御部３１，通信部３２および記憶部３３などを備えている。
これらのうち、制御部３１は、ＣＰＵ，ＲＯＭ，ＲＡＭ等を備え、このＣＰＵが、ＲＯＭに記憶されているプログラムに従って機能サーバ３０全体を統括制御する。なお、この制御部３１は、複合機１０の制御部１１に比べて充分に高性能な構成とされており、複合機１０の制御部１１では実行困難な処理についても行うことができる。
また、通信部３２は、機能サーバ３０をネットワーク１に接続すると共に、このネットワーク１を介してデータを送受信するための処理を行う。
そして、記憶部３３は、図示しないハードディスクを備えており、このハードディスクにデータを記憶する。この記憶部３３は、後述するサービスＩ／Ｆ情報３６を記憶するためのサービスＩ／Ｆ情報記憶部３４と、それぞれ異なるサービスを提供するための処理を実行するサービスソフトウェア３７を記憶するためのサービスソフト記憶部３５と、からなる。このサービスＩ／Ｆ情報３６は、ＸＭＬにより記述されたデータであり、この記述内容に従って後述するパラメータ入力用画面が複合機１０に表示されることで（図１６参照）、機能サーバ３０に対してサービスの提供を要求するための情報（サービスの詳細内容等）の設定を行うインターフェースが実現される。
なお、このサービスＩ／Ｆ情報３６における各タグの定義付けを図４に示す。
ここで、複合機１０と機能サーバ３０との間で行われる通信の一例について、図５のラダーチャートを用いて説明する。
複合機１０と機能サーバ３０とは、サービス起動からサービス終了までの間、一連の通信処理（セッション）を行う。このセッションにおいて、まず、複合機１０は、機能サーバ３０に対し、サービス起動を要求する。すると、機能サーバ３０は、複合機１０に対しセッションＩＤを送信する。ここで、セッションＩＤとは、機能サーバ３０においてセッションを特定するための識別子であり、以降の通信において、複合機１０はリクエストに伴いセッションＩＤを送信し、機能サーバ３０はそのセッションＩＤに基づきセッションを特定する。これにより、機能サーバ３０は、複数のセッションを同時に処理することが可能となる。
複合機１０は、セッションＩＤを受信すると、以降は、本複合機１０に対する指令の問い合わせである複合機指令問合せを定期的に行い、これに対する機能サーバ３０からの返答という形で指令を受ける。なお、機能サーバ３０は、複合機指令問合せに対して送信すべき指令がない場合には、指令がない旨の送信（複合機指令無し）を行う。
この例において、機能サーバ３０は、まず、ＵＩ（ユーザーインターフェース）ジョブ起動指令を複合機１０へ送信する。ここで、ＵＩジョブ起動指令とは、複合機１０に設けられるＵＩデバイス（操作部１２）の利用開始を通知するものである。これにより、複合機１０と機能サーバ３０との間で、ＵＩジョブの通信処理が開始される。このＵＩジョブの通信処理は、セッションと並行して行われる。また、機能サーバ３０から複合機１０へは、ＵＩジョブ起動指令に伴い、機能サーバ３０においてジョブを特定するためのジョブＩＤ（セッションにおいて固有の識別子）が送信される。そして、複合機１０は、ＵＩジョブの通信処理において、リクエストに伴いセッションＩＤ及びジョブＩＤを送信し、機能サーバ３０は、そのセッションＩＤ及びジョブＩＤに基づきジョブを特定する。これにより、機能サーバ３０は、複数のジョブを同時に処理することが可能となる。なお、ＵＩジョブの通信処理の内容については後述する。
続いて、機能サーバ３０は、所定のタイミングで、入力ジョブ起動指令を複合機１０へ送信する。ここで、入力ジョブ起動指令とは、複合機１０に設けられる入力デバイス（読取部１３又は音入力部１７）の利用開始を通知するものである。これにより、複合機１０と機能サーバ３０との間で、入力ジョブの通信処理が開始される。そして、この入力ジョブの通信処理も、ＵＩジョブと同様、セッションと並行して行われる。また、機能サーバ３０から複合機１０へは、入力ジョブ起動指令に伴いジョブＩＤが送信される。そして、複合機１０は、入力ジョブの通信処理において、リクエストに伴いセッションＩＤ及びジョブＩＤを送信し、機能サーバ３０は、そのセッションＩＤ及びジョブＩＤに基づきジョブを特定する。なお、入力ジョブの通信処理の内容については後述する。
続いて、機能サーバ３０は、所定のタイミングで、出力ジョブ起動指令を複合機１０へ送信する。ここで、出力ジョブ起動指令とは、複合機１０に設けられる出力デバイス（記録部１４又は音出力部１８）の利用開始を通知するものである。これにより、複合機１０と機能サーバ３０との間で、出力ジョブの通信処理が開始される。そして、この出力ジョブの通信処理も、ＵＩジョブや入力ジョブと同様、セッションと並行して行われる。また、機能サーバ３０から複合機１０へは、出力ジョブ起動指令に伴いジョブＩＤが送信される。そして、複合機１０は、出力ジョブの通信処理において、リクエストに伴いセッションＩＤ及びジョブＩＤを送信し、機能サーバ３０は、そのセッションＩＤ及びジョブＩＤに基づきジョブを特定する。なお、出力ジョブの通信処理の内容については後述する。
続いて、機能サーバ３０は、所定のタイミングで、出力ジョブを終了することの通知である出力ジョブ終了指令を複合機１０へ送信する。
続いて、機能サーバ３０は、所定のタイミングで、入力ジョブを終了することの通知である入力ジョブ終了指令を複合機１０へ送信する。
続いて、機能サーバ３０は、所定のタイミングで、ＵＩジョブを終了することの通知であるＵＩジョブ終了指令を複合機１０へ送信する。
続いて、機能サーバ３０は、所定のタイミングで、サービスを終了することの通知であるサービス終了指令を複合機１０へ送信する。
以上が、セッションの内容である。
次に、ＵＩジョブの通信処理について説明する。
ＵＩジョブの通信処理において、まず、複合機１０は、機能サーバ３０にサービスＩ／Ｆ情報３６を送信してもらうための要求である「サービスＩ／Ｆ情報送信要求」を機能サーバ３０に対して行う。すると、機能サーバ３０は、複合機１０に対しサービスＩ／Ｆ情報３６を送信する。
複合機１０は、サービスＩ／Ｆ情報３６を受信すると、そのサービスＩ／Ｆ情報３６に基づいてパラメータ入力用画面を操作部１２のディスプレイ５２に表示させる（例えば図１６）。
そして、複合機１０は、機能サーバ３０に対し複合機ジョブ指令問合せを行う。すると機能サーバ３０は、複合機１０に対しパラメータ要求を送信する。ここで、パラメータ要求とは、サービスの実行に必要なパラメータを複合機１０の利用者に設定させるためのものである。
複合機１０は、機能サーバ３０からパラメータ要求を受信すると、利用者により設定されたパラメータを、機能サーバ３０へ送信する。
機能サーバ３０は、複合機１０からパラメータを受信すると、機能サーバ３０が複合機１０からの情報を正常に受け取ることができたか否かを表す通知であるサーバ受取状況を送信する。
そして、複合機１０は、機能サーバ３０から受信したサーバ受取状況により機能サーバ３０がパラメータを正常に受信したことを確認すると、機能サーバ３０に対し、サービスの状態に関する情報の要求であるサービス状態情報要求を行う。
機能サーバ３０は、複合機１０からサービス状態情報要求を受信すると、機能サーバ３０及びサービスの状態の通知であるサービス状態情報を複合機１０へ送信する。
以降は、サービス状態情報要求と、これに対するサービス状態情報の送信が繰り返される。
次に、入力ジョブの通信処理について説明する。
入力ジョブの通信処理において、まず、複合機１０は、機能サーバ３０に対し、本複合機１０の状態に関する情報である複合機状態情報を送信する。すると、機能サーバ３０は、複合機１０に対し複合機パラメータを送信する。ここで、複合機パラメータとは、ＵＩジョブの通信処理で複合機１０の利用者に設定させた入力デバイスのパラメータである。
複合機１０は、機能サーバ３０から複合機パラメータを受信すると、複合機１０が機能サーバ３０からの情報を正常に受け取ることができたか否かを表す通知である複合機受取状況を送信する。
そして、機能サーバ３０は、複合機１０からの複合機受取状況により複合機１０が情報を正常に受信したことを確認すると、複合機１０に対し、ジョブに対応した入力データの要求である入力データ要求を送信する。ここで、ジョブに対応した入力データとは、スキャンジョブ（読取部１３で生成された画像データに関するサービスで実行されるジョブ）であれば読取部１３で生成された画像データ、音声入力ジョブ（音入力部１７により出力される音を表す音データに関するサービスで実行されるジョブ）であればＰＣＭデータである。
複合機１０は、機能サーバ３０から入力データ要求を受信すると、入力操作（画像の読み取り操作や音声入力操作）を利用者に促す表示等を行い、その結果生成した入力データを機能サーバ３０へ送信する。
機能サーバ３０は、複合機１０から入力データを受信すると、機能サーバ３０及びサービスの状態の通知であるサービス状態情報を複合機１０へ送信する。
次に、出力ジョブの通信処理について説明する。
出力ジョブの通信処理において、まず、複合機１０は、機能サーバ３０に対し、複合機１０の状態に関する情報である複合機状態情報を送信する。すると、機能サーバ３０は、複合機１０に対し複合機パラメータを送信する。ここで、複合機パラメータとは、ＵＩジョブの通信処理で複合機１０の利用者に設定させた出力デバイスのパラメータである。
複合機１０は、機能サーバ３０から複合機パラメータを受信すると、複合機１０が機能サーバ３０からの情報を正常に受け取ることができたか否かを表す通知である複合機受取状況を送信する。
そして、機能サーバ３０は、複合機１０からの複合機受取状況により複合機１０が情報を正常に受信したことを確認すると、複合機１０に対し、出力データを送信する。ここで、出力データとは、印刷ジョブ（記録部１４で印刷する画像を表す画像データに関するサービスで実行されるジョブ）であれば画像データ、音声出力ジョブ（音出力部１８で出力する音声を表すＰＣＭデータに関するサービスで実行されるジョブ）であればＰＣＭデータである。
複合機１０は、機能サーバ３０から出力データを受信すると、出力データに基づく出力処理（画像の印刷や音声の出力）を行う。そして、複合機１０は、複合機１０の状態に関する情報である複合機状態情報を機能サーバ３０へ送信する。
機能サーバ３０は、複合機１０から複合機状態情報を受信すると、機能サーバ３０及びサービスの状態の通知であるサービス状態情報を複合機１０へ送信する。
次に、複合機１０、ディレクトリサーバ２０および機能サーバ３０の各制御部１１，２１，３１が行う処理について説明する。
（２）ディレクトリサーバ２０による処理
まず、ディレクトリサーバ２０の制御部２１により実行されるディレクトリサーバ処理を図６に基づいて説明する。
このディレクトリサーバ処理は、複合機１０からＨＴＴＰ１．１に基づくＨＴＴＰリクエスト（以降、単に「ＨＴＴＰリクエスト」という。）があると実行が開始される。まず、ＨＴＴＰリクエストを受信し（Ｓ７１）。そのＨＴＴＰリクエストの内容がサービスの一覧を照会するものであるか否かをチェックする（Ｓ７２）。ここでＨＴＴＰリクエストの内容がサービスの一覧を照会するものであれば（Ｓ７２：ＹＥＳ）、トップのサービス定義情報２５をサービス定義情報記憶部２４から読み出し（Ｓ７３）、Ｓ７７に移行する。
一方、Ｓ７２で、ＨＴＴＰリクエストの内容がサービスの一覧を照会するものでなければ（Ｓ７２：ＮＯ）、ＨＴＴＰリクエストの内容がサービスの照会であるか否かをチェックする（Ｓ７４）。ここでＨＴＴＰリクエストの内容がサービスを照会するものであれば（Ｓ７４：ＹＥＳ）、指定されたサービス定義情報２５をサービス定義情報記憶部２４から読み出し（Ｓ７５）、Ｓ７７に移行する。
一方、Ｓ７４で、ＨＴＴＰリクエストの内容がサービスを照会するものでなければ（Ｓ７４：ＮＯ）、エラー情報をセットし（Ｓ７６）、Ｓ７７に移行する。
Ｓ７７では、サービス定義情報２５またはエラー情報をＨＴＴＰ１．１に基づくＨＴＴＰレスポンス（以降、単に「ＨＴＴＰレスポンス」という。）として要求もとの複合機１０に送信し、本ディレクトリサーバ処理を終了する。
（３）複合機１０による処理
次に複合機１０の制御部１１により実行される各種処理について説明する。
（３−１）複合機処理
まず、複合機１０が起動された以降、繰り返し実行される処理である複合機処理を図７に基づいて説明する。
この複合機処理が起動されたら、まず、初期化処理を行う（Ｓ１０２）。
この初期化処理を終えた後、外部からの指令，例えば、操作部１２への入力操作やネットワーク１を介した指令信号の入力などが発生したら（Ｓ１０４）、この入力が動作モードをサービスモードへ移行させるための内容であるか否かをチェックする（Ｓ１０６）。ここでは、Ｓ１０４による入力が操作部１２のサービスキー４４を押下する操作であれば、サービスモードへ移行させるための内容であると判定する。なお、この「サービスモード」とは、以下の処理で示すように、機能サーバ３０に対してサービスの提供を要求するための処理を実行するための動作モードである。
Ｓ１０６で、サービスモードへ移行させるための内容でないと判定されたら（Ｓ１０６：ＮＯ）、その入力内容に応じて他の動作モードに対する処理（その他のモードの処理）を行った後（Ｓ１０８）、Ｓ１０４へ戻る。
一方、Ｓ１０６で、サービスモードへ移行させるための内容であると判定されたら（Ｓ１０６：ＹＥＳ）、機能サーバ３０に要求すべきサービスを指定する方法をユーザに指定させる（Ｓ１１０）。ここでは、図８に示す方法選択画面をディスプレイ５２に表示させ、サービスをリストから指定するか（図８における「リストから選択」）、要求先アドレスを直接入力により指定するか（図８における「直接入力」）の選択を促す。この選択画面が表示された後、ユーザは、操作部１２により、いずれにより指定するかの選択を行うことができる。
このＳ１１０で、リストから指定する旨が選択されたら（Ｓ１１０：ＹＥＳ）、ディレクトリサーバ２０にトップのサービス一覧の照会を要求して取得する（Ｓ１１２）。ここでは、ディレクトリサーバ２０に対してサービス定義情報２５の送信を要求するためのアドレスとして、あらかじめ記憶部１６に記憶されたアドレス宛にＨＴＴＰリクエストを送信することにより、サービス一覧の照会を要求する。このアドレスに基づいてアクセスを受けたディレクトリサーバ２０は、後述するようにトップのサービス定義情報２５をＨＴＴＰレスポンスにより返信してくる。なお、このＨＴＴＰリクエストの送信またはＨＴＴＰレスポンス受信は、後述するファイル取得処理がコールされ、そのファイル取得処理の中で必要に応じて行われる。
こうして、トップのサービス一覧の照会を要求した後、ディレクトリサーバ２０から返信されたサービス定義情報２５を受信したら、このサービス定義情報２５に基づいてサービス選択用画面をディスプレイ５２に表示させた後（Ｓ１１６）、次の処理（Ｓ１２０）へ移行する。このＳ１１６の処理がトップのサービス定義情報２５を受信した後に行われる場合には、図９に示すようなトップのサービス定義情報２５（ＸＭＬの記述）に従って、図１０（ａ）に示すように、表示用タイトル（Ｔｉｔｌｅ）として「ディレクトリサービス」の文字がディスプレイ５２の表示領域上部に配置され、選択可能なカテゴリを表す項目（Ｌｉｎｋ＿Ｔｉｔｌｅ）である「データ保存サービス」，「印刷サービス」および「コピー応用サービス」の文字が表示領域下部に配置されてなるサービスのカテゴリ選択画面の表示を行う。なお、この場合のサービスのカテゴリ選択画面には、カテゴリに対応する別のサービス定義情報２５のＩＤがリンク先として割り当てられており（図９における「Ｌｉｎｋ＿Ｌｏｃａｔｉｏｎ」参照）、いずれかの項目が選択された際に、その項目に対応するＩＤのサービス定義情報２５がディレクトリサーバ２０に要求されることになる。
また、Ｓ１１６の処理がトップ以外のサービス定義情報２５を受信した後に行われる場合，具体的な例として、「コピー応用サービス」に関するサービス定義情報２５を受信した場合には、図１１に示すようなサービス定義情報２５（ＸＭＬの記述）に従って、図１０（ｂ），図１０（ｃ）に示すように、表示用タイトル（Ｔｉｔｌｅ）として「コピー応用サービス」の文字が表示領域上部に配置され、選択可能なサービスを表す項目（Ｌｉｎｋ＿Ｔｉｔｌｅ）である「すかし入りコピー」，「翻訳コピー」，「原稿読み上げ」および「音声テキスト変換」の文字が表示領域下部に配置されてなるサービス選択画面の表示を行う。なお、本実施形態において、表示領域の制約上、すべての項目を一度に表示することができない場合には、画面をスクロールさせることで各項目の配置が上下に移動するように構成されており、図１０（ｂ），図１０（ｃ）では、そのようなスクロール前後の状態を示している。また、この場合のサービス選択画面には、サービスに対応する別のサービス定義情報２５のＩＤがリンク先として割り当てられており（図１１における「Ｌｉｎｋ＿Ｌｏｃａｔｉｏｎ」参照）、いずれかの項目が選択された際に、その項目に対応するＩＤのサービスの提供が機能サーバ３０に要求されることになる。また、図１１に例示するサービス定義情報２５にはグループＩＤ（ＧＩＤ）として「ｈｔｔｐ：／／ｃｏｐｙ−ｓｖｃ．ｃｏｍ」が定義されている。
また、上述したＳ１１０で、要求先アドレスを直接入力により指定する旨が選択された場合には（Ｓ１１０：ＮＯ）、要求先アドレスを入力するための図示しないアドレス入力画面をディスプレイ５２に表示させた後（Ｓ１１８）、次の処理（Ｓ１２０）へ移行する。
こうして、サービス選択画面またはアドレス入力画面が表示された以降、ユーザは、操作部１２により、いずれかの項目を選択する操作（アドレスを入力する操作），または，サービスモードを終了する操作（停止操作）を行うことができる。
次に、ユーザによる操作部１２への入力操作を受け付け（Ｓ１２０）、こうして行われた入力操作がリンクを選択する操作であるか否かをチェックする（Ｓ１２２）。ここでは、Ｓ１１６にて表示されたサービス選択画面における項目を選択する操作，または，Ｓ１１８にて表示されたアドレス入力画面にアドレスを入力する操作が入力操作として行われた場合に、リンクを選択する操作であると判定する。
このＳ１２２で、リンクを選択する操作でないと判定された場合（Ｓ１２２：ＮＯ）、その入力操作が停止操作であれば（Ｓ１２４：ＹＥＳ）、Ｓ１０４へ戻ることによりサービスモードとしての処理を終了する。一方、入力操作が停止操作でなければ（Ｓ１２４：ＮＯ）、拒否音（ブザー音など）を鳴動させた後（Ｓ１２６）、Ｓ１２０へ戻る。
また、Ｓ１２２で、入力操作がリンクを選択する操作であると判定された場合（Ｓ１２２：ＹＥＳ）、その選択されたリンクがサービスへのリンク，つまり機能サーバ３０にサービスの提供を要求するためのＩＤであるか否かをチェックする（Ｓ１２８）。
このＳ１２８で、サービスへのリンクでないと判定された場合，つまり別のサービス定義情報２５のＩＤである場合には（Ｓ１２８：ＮＯ）、ディレクトリサーバ２０に対してサービス一覧の照会を要求し、該当するサービス定義情報２５を受信した後（Ｓ１３０）、Ｓ１１６へ戻ってサービス選択用画面をディスプレイ５２に表示させる。このＳ１３０においてなされる処理も後述するファイル取得処理がコールされ、そのファイル取得処理の中で必要に応じて行われる。
そして、Ｓ１２８で、サービスへのリンクであると判定された場合には（Ｓ１２８：ＹＥＳ）、後述するセッション処理（図１２）を行った後（Ｓ１３２）、Ｓ１０４へ戻ることによりサービスモードとしての処理を終了する。
（３−２）セッション処理
続いて、図７におけるＳ１３２であるセッション処理の詳細な処理手順を図１２，図１３に基づいて説明する。
このセッション処理では、まず、利用するサービスを選択し、サービス定義情報２５のＬｉｎｋ＿Ｌｏｃａｔｉｏｎ（アドレスを直接入力した場合には、そのアドレス）に基づきサービスを起動する（Ｓ２０２）。つまり、サービスのアドレス宛にサービス起動指令をＨＴＴＰリクエストにより送信することで、ユーザに選択されたサービスを機能サーバ３０側において起動させる。このサービス起動指令を受信した機能サーバ３０からは、セッションＩＤがＨＴＴＰレスポンスにより返信されてくる。
次に、Ｓ２０４によるサービス起動指令に応じて機能サーバ３０から返信されてくるセッションＩＤを受信する（Ｓ２０４）。なお、以降の処理で送信するＨＴＴＰリクエストおよびＨＴＴＰレスポンスには、特に明示しない限り、全てセッションＩＤが含まれた状態で送信されることとし、このＨＴＴＰリクエストを受信した機能サーバ３０側では、このセッションＩＤに基づいて通信中のデバイスを管理（周知のセッション管理）するように構成されている。
次に、複合機１０に対する指令の有無を問い合わせるための「複合機指令問合せ」をＨＴＴＰリクエストにより機能サーバ３０へ送信する（Ｓ２０６）。この「複合機指令問合せ」を受信した機能サーバ３０は、複合機１０に対する指令が発生していれば、その内容を示す指令（指令が発生していない場合には「指令なし」を示す指令）をＨＴＴＰレスポンスにより返信してくる。
次に、Ｓ２０６による問い合わせにより返信されてくる指令（複合機指令）を受信したら（Ｓ２０８）、その指令がジョブ起動指令であるか否かを判定する（Ｓ２１０）。この「ジョブ起動指令」とは、後述のように、Ｓ２０２にてサービス起動指令を送信した以降、機能サーバ３０側で発生する指令であり、そのタイミングやサービスの内容に応じて「ＵＩジョブ」，「入力ジョブ（スキャンジョブまたはボイスジョブ）」，「出力ジョブ（プリントジョブまたはスピーカジョブ）」のいずれかの起動を指令する内容となっている。なお、このジョブ起動指令には、起動すべきジョブのジョブＩＤ、ジョブの種類（ＵＩジョブ、入力ジョブ（スキャンジョブまたはボイスジョブ）、出力ジョブ（プリントジョブまたはスピーカジョブ））およびジョブの通信先アドレスが付加されている。
このＳ２１０で、ジョブ起動指令であると判定された場合（Ｓ２１０：ＹＥＳ）、ジョブの起動に必要なリソースを確保した後（Ｓ２１２）、以下に示すＳ２５２〜Ｓ２６６によりジョブ起動指令で指令されたジョブの起動を行う。
以下に、このＳ２５２〜Ｓ２６６について図１３に基づいて説明する。
ここでは、まず、ジョブ起動指令で指令されたジョブがＵＩジョブであるか否かをチェックし（Ｓ２５２）、ＵＩジョブであると判定された場合には（Ｓ２５２：ＹＥＳ）、ジョブ起動指令に付加されたジョブＩＤおよび通信先アドレスに基づいてＵＩジョブを起動した後（Ｓ２５４）、次の処理（図１２におけるＳ２１４）へ移行する。このＵＩジョブは、このＳ２５４の処理で起動された以降、他の処理と並行して実行されるものであり、これについては、後述する「ＵＩジョブ」（図１４）において詳述する。
また、ジョブ起動指令で指令されたジョブがＵＩジョブでないと判定された場合（Ｓ２５２：ＮＯ）、その指令されたジョブが入力ジョブの一種であるスキャンジョブ（Ｓ２５６：ＹＥＳ）またはボイスジョブ（Ｓ２５６：ＮＯ，Ｓ２６２：ＹＥＳ）であれば、ジョブ起動指令に付加されたジョブＩＤおよび通信先アドレスに基づいて入力ジョブを起動した後（Ｓ２６０）、次の処理（図１２におけるＳ２１４）へ移行する。この入力ジョブは、このＳ２６０の処理で起動された以降、他の処理と並行して実行されるものであり、これについては、後述する「入力ジョブ」（図１７）において詳述する。
また、ジョブ起動指令で指令されたジョブが上述したいずれのジョブでないと判定された場合（Ｓ２５８：ＮＯ）、その指令されたジョブが出力ジョブの一種であるプリントジョブ（Ｓ２６２：ＹＥＳ）またはスピーカジョブ（Ｓ２６２：ＮＯ，Ｓ２６４：ＹＥＳ）であれば、ジョブ起動指令に付加されたジョブＩＤおよび通信先アドレスに基づいて出力ジョブを起動した後（Ｓ２６６）、次の処理（図１２におけるＳ２１４）へ移行する。この出力ジョブは、このＳ２６６の処理で起動された以降、他の処理と並行して実行されるものであり、これについては、後述する「出力ジョブ」（図１８）において詳述する。
なお、ジョブ起動指令で指令されたジョブが上述したいずれのジョブでもないと判定された場合（Ｓ２６４：ＮＯ）、ジョブの起動を行うことなく、次の処理（図１２におけるＳ２１４）へ移行する。
こうして、ジョブの起動を行った後、図１２へ戻り、所定インターバル待機した後（Ｓ２１４）、Ｓ２０６へ戻る。
また、上述したＳ２１０で、ジョブ起動指令でないと判定された場合（Ｓ２１０：ＮＯ）、Ｓ２０８で受信した指令がジョブ終了指令であるか否かをチェックする（Ｓ２１６）。この「ジョブ終了指令」とは、後述のように、図１３における各処理でジョブを起動した以降、このジョブが終了した際に機能サーバ３０側で発生する指令である。なお、このジョブ終了指令には、その終了したジョブのジョブＩＤが付加されている。
このＳ２１６で、ジョブ終了指令であると判定された場合（Ｓ２１６：ＹＥＳ）、このジョブ終了指令に付加されたジョブＩＤのジョブを停止させる（該当するジョブに対して終了指示を渡す）と共に、このジョブを起動する前にＳ２１２にて確保したリソースを解放した後（Ｓ２１８）、Ｓ２１４へ移行する。
また、上述したＳ２１６で、ジョブ終了指令でないと判定された場合（Ｓ２１６：ＮＯ）、「指令なし」を示すものであるか否かをチェックし（Ｓ２２０）、「指令なし」を示すものであれば（Ｓ２２０：ＹＥＳ）、Ｓ２１４へ移行する。一方、「指令なし」を示すものでなければ（Ｓ２２０：ＮＯ）、セッション終了指令であるか否かを判定する（Ｓ２２２）。この「セッション終了指令」とは、この複合機１０に対するサービスの提供が終了した際に機能サーバ３０側で発生する処理である。
そして、このＳ２２２で、セッション終了指令であると判定された場合（Ｓ２２２：ＹＥＳ）、本セッション処理を終了する。一方、Ｓ２０８で受信した指令が上述したいずれの指令でもない場合、エラーを報知するための処理（指令エラーの処理）を行った後（Ｓ２２４）、本セッション処理を終了する。このＳ２２４では、エラーである旨のメッセージをディスプレイ５２に表示させることによりエラーを報知する。
（３−３）ＵＩジョブ
続いて、図１３におけるＳ２５４にて起動されるＵＩジョブの処理手順を図１４に基づいて説明する。
このＵＩジョブが開始されると、まず、機能サーバ３０にサービスＩ／Ｆ情報３６を送信してもらうための要求である「サービスＩ／Ｆ情報送信要求」およびその要求対象を特定するＵＲＬを送信用データとして所定領域へ書き込む。この送信用データは、後述するＳ３１５やＳ３２１の処理で利用される情報であり、このデータとして書き込まれている情報がセッションＩＤ及びジョブＩＤとともに機能サーバ３０へ送信される。なお、送信用データの格納領域は、複合機１０の制御部１１内に備えられた図示しないＲＡＭの所定領域に設けられている（Ｓ３０１）。
続いて、上述したセッション処理からの終了指示（図１２のＳ２１８において出力される指示）があったか否かを判定する（Ｓ３０３）。
このＳ３０３で、セッション処理からの終了指示があったと判定された場合には（Ｓ３０３：ＹＥＳ）、セッション処理に対してＵＩジョブの終了を通知した後（Ｓ３０５）、本ＵＩジョブを終了する。なお、このセッション終了指令は、上述した図１２のセッション処理のＳ２１８における処理の中で受信される。Ｓ２１８の内部ではこの指令を受信することによりジョブが完全に停止したと判断し、以降の手順を実施する。
一方、セッション処理からの終了指示がないと判定された場合には（Ｓ３０３：ＮＯ）、操作部１２がビジー状態であるか否かを判定する（Ｓ３０９）。ここでは、各ジョブの起動中に立つ（「１」がセットされる）ように設定されたビジーフラグＦｕに基づき、ビジーフラグＦｕが立っていればビジー状態であると判定し、ビジーフラグＦｕが下りて（「０」がセットされて）いればビジー状態でないと判定する。
このＳ３０９で、ビジー状態であると判定された場合には（Ｓ３０９：ＹＥＳ）、操作部１２のビジー状態が解除されるまで，つまりビジーフラグＦｕが下りるまで待機した後（Ｓ３０７）、Ｓ３０９へ戻る。一方、ビジー状態でないと判定した場合には（Ｓ３０９：ＮＯ）、ビジーフラグＦｕを立てて（Ｓ３１１）、本ＵＩジョブにより操作部１２がビジー状態になっているものとする。
次に、上述した送信用データは「サービスＩ／Ｆ情報送信要求」であるか否かを判定する（Ｓ３１３）。なお、Ｓ３０１を経て最初にこのＳ３１３を処理する場合は、送信用データは「サービスＩ／Ｆ情報送信要求」であるが、それ以降にＳ３１３を処理する場合は、送信用データはサービスＩ／Ｆ情報送信要求でないこともある。送信用データが「サービスＩ／Ｆ情報送信要求」であると判定した場合は（Ｓ３１３：ＹＥＳ）、後述するファイル取得処理を実行し（Ｓ３１５）、サービスＩ／Ｆ情報３６を得る。そして、複合機１０に対する指令の問い合わせである「複合機ジョブ指令問合わせ」を送信用データとして格納領域へ書き込み（Ｓ３１５）、ビジーフラグＦｕを下げて（Ｓ３１９）、上述したＳ３０３に処理を戻す。
一方、Ｓ３１３において、送信用データが「サービスＩ／Ｆ情報送信要求」でないと判定した場合は（Ｓ３１３：ＮＯ）、送信用データとして格納領域に書き込まれている情報をセッションＩＤおよびジョブＩＤを伴わせて機能サーバ３０へＨＴＴＰリクエストにより送信する（Ｓ３２１）。このＨＴＴＰリクエストを受信した機能サーバ３０は、本ＵＩジョブに対する指令があれば、その内容を示す複合機指令をＨＴＴＰレスポンスにより返信してくる。なお、本ＵＩジョブに対する指令がなければ、「指令なし」を示す複合機指令をＨＴＴＰレスポンスにより返信してくる。
次に、ＨＴＴＰレスポンスにより返信されてくる複合機指令を受信すると（Ｓ３２３）、その指令がパラメータ要求であるか否かを判定する（Ｓ３２５）。この「パラメータ要求」とは、機能サーバ３０で実行される後述のＵＩジョブ処理（図２８）におけるＳ９１４の処理で送信される要求であり、このパラメータ要求に付加されたサービスＩ／Ｆ情報３６に基づいて、サービスの利用に必要なパラメータの指定要求がユーザに対してなされる。
このＳ３２５で、パラメータ要求であると判定された場合（Ｓ３２５：ＹＥＳ）、サービスＩ／Ｆ情報３６に基づきパラメータ入力用画面を操作部１２のディスプレイ５２に表示させ、パラメータの設定するための入力操作を利用者に促す（Ｓ３２７）。
ここで、サービスＩ／Ｆ情報３６のうち、翻訳コピーサービスに対応するサービスＩ／Ｆ情報３６を例示してパラメータ入力画面が表示される様子について説明する。なお、翻訳コピーサービスとは、複合機１０における読取部１３で読み取られた画像データに基づき、機能サーバ３０が、この画像データで表される画像に対してＯＣＲ（Optical Character Recognition ）処理でテキストを認識し、そのテキストを所定の言語に翻訳した内容の画像を表す画像データを生成して提供することにより、この画像を複合機１０における記録部１４に印刷させるサービスである。
まず、図１５に示すようなＸＭＬの記述内容に従って、図１６（ａ）に示すように、表示用タイトル（Ｔｉｔｌｅ）として「翻訳コピー」の文字が表示領域上部に配置され、その下に入力項目（Ｄｉｓｐ＿Ｎａｍｅ）として「言語選択」の文字が配置され、さらにその下に入力項目「言語選択」について選択可能なパラメータを表す項目（Ｄｉｓｐ＿Ｓｅｌｅｃｔ）である「英語→日本語」及び「日本語→英語」の文字が配置されたパラメータ入力用画面を表示させる。ここで、「翻訳コピー」に関する入力項目（Ｄｉｓｐ＿Ｎａｍｅ）としては、上記表示されている「言語選択」に加え、「スキャナ設定」，「印刷設定」及び「コメント」があるが、この時点では、「言語選択」についての入力項目のみが表示される。これは、単にディスプレイ５２の大きさの制限によるものであり、この状態から操作部１２を操作する（左右の方向キー４８，４９）ことで、図１６（ｂ）〜図１６（ｅ）に示すように、表示領域下部に表示される入力項目を、「スキャナ設定」，「印刷設定」及び「コメント」を含む４種類の中から切り替えることができる。
なお、これら入力項目について選択可能なパラメータについて説明すると、「スキャナ設定」について選択可能なパラメータを表す項目（Ｄｉｓｐ＿Ｓｅｌｅｃｔ）としては、「普通の文字」及び「細かい文字」の文字が表示されることとなる（図１６（ｂ）参照）。ここでいう「普通の文字」とは、読取部１３のパラメータである解像度（読取解像度）を３００×３００ｄｐｉに設定することを意味し、「細かい文字」とは、解像度を６００×６００ｄｐｉに設定することを意味する。
また、「印刷設定」について選択可能なパラメータを表す項目（Ｄｉｓｐ＿Ｓｅｌｅｃｔ）としては、「印刷速度優先」，「普通」及び「高精細」の文字が表示されることとなる。なお、ディスプレイ５２の大きさの制限により、「高精細」については、初めは表示されていないが（図１６（ｃ）参照）、画面をスクロールさせることで表示される（図１６（ｄ）参照）。ここでいう「印刷速度優先」とは、記録部１４のパラメータである解像度（印刷解像度）を２００×２００ｄｐｉに設定することを意味し、「普通」とは、解像度を３００×３００ｄｐｉに設定することを意味し、「高精細」とは、解像度を６００×６００ｄｐｉに設定することを意味する。
そして、「コメント」については、「コメント」の文字の下に、コメントの入力欄が表示され、設定されている文字列（Ｄｅｆａｕｌｔ＿Ｓｔｒｉｎｇ）が入力された状態となる（図１６（ｅ）参照）。こうして、コメントとして入力欄に入力された文字列は、例えば、印刷画像のヘッダやフッタに記載されるという形で利用される。
なお、図１５に示すＸＭＬには、グループＩＤ（ＧＩＤ）として「ｈｔｔｐ：／／ｃｏｐｙ−ｓｖｃ．ｃｏｍ／／００１」が定義されている。
こうして、パラメータ入力用画面を表示させた後、ユーザにより、各入力項目に対するパラメータの指定，入力欄への文字列の入力，および，指定内容を確定するための操作などが行われると、これらの入力情報（パラメータ）を送信用データとして格納領域へ書き込む（Ｓ３２９）。そして、ビジーフラグＦｕを下げて（Ｓ３１９）、Ｓ３０３へ処理を戻す。
次に、上述したＳ３２３において受信した複合機指令が、パラメータ要求でないと判定された場合には（Ｓ３２５：ＮＯ）、Ｓ３２３にて受信した複合機指令がサービス状態情報の表示指令であるか否かを判定する（Ｓ３３１）。ここで言う「サービス状態情報の表示指令」とは、機能サーバ３０側で発信される指令（図２８におけるＳ９３６で送信される指令）であり、機能サーバ３０において問題なくサービスに関わる処理が実行されていること、または、問題がありサービスを停止することなどを報知するための指令である。
このＳ３３１で、サービス状態情報の表示指令であると判定されたら（Ｓ３３１：ＹＥＳ）、このサービス状態情報に基づく表示をディスプレイ５２に行わせた後（Ｓ３３３）、機能サーバ３０で稼働するサービスの稼働状態の新たな情報を要求する「サービス状態情報要求」を送信用データとして格納領域へ書き込む（Ｓ３３５）。そして、ビジーフラグＦｕを下げて（Ｓ３１９）、Ｓ３０３へ処理を戻す。
また、Ｓ３３１において、サービス状態情報の表示指令でないと判定されたら（Ｓ３３１：ＮＯ）、Ｓ３２３にて受信した複合機指令が状態情報要求であるか否かをチェックする（Ｓ３３７）。この「状態情報要求」とは、複合機１０の状態に関する情報送信を要求するための指令である。
このＳ３３７で、状態情報要求であると判定されたら（Ｓ３３７：ＹＥＳ）、複合機１０の状態に関する情報（例えば、用紙なし、カバーオープンなどを示す情報）を送信用データとして格納領域を書き込む（Ｓ３３９）。そして、ビジーフラグＦｕを下げて（Ｓ３１９）、Ｓ３０３へ処理を戻す。
また、Ｓ３３７で、状態情報要求でないと判定されたら（Ｓ３３７：ＮＯ）、Ｓ３２３にて受信した複合機指令がサーバ受取状況を表す指令であるか否かをチェックする（Ｓ３４１）。この「サーバ受取状況」とは、機能サーバ３０が複合機１０からの情報を正常に受け取ることができたか否かを通知するために送信する指令である。
このＳ３４１で、サーバ受取状況であると判定されたら（Ｓ３４１：ＹＥＳ）、このサーバ受取状況の内容が異常受取（ＮＧ）を表すものである場合（Ｓ３４３：ＹＥＳ）、このサーバ受取状況を送信する契機となった情報を送信用データとして格納領域へ書き込む（Ｓ３４６）。そして、ビジーフラグＦｕを下げて（Ｓ３１９）、Ｓ３０３へ処理を戻す。一方、異常受取（ＮＧ）を表すものでない場合（Ｓ３４３：ＮＯ）、上述した「サービス状態情報要求」を送信用データとして格納領域へ書き込み（Ｓ３４５）、ビジーフラグＦｕを下げて（Ｓ３１９）、Ｓ３０３へ処理を戻す。
一方、Ｓ３４１において、Ｓ３２３で受信した複合機指令が「サーバ受取状況」でないと判定されたら（Ｓ３４１：ＮＯ）、Ｓ３２３にて受信した複合機指令が「指令なし」を示すものか否かをチェックし（Ｓ３３８）、「指令なし」を示すものであれば（Ｓ３３８：ＹＥＳ）、複合機１０に対する指令の問い合わせである「複合機指令ジョブ指令問合わせ」を送信用データとして格納領域へ書き込み（Ｓ３４９）、ビジーフラグＦｕを下げて（Ｓ３１９）、Ｓ３０３へ処理を戻す。一方、「指令なし」を示すものでなければ（Ｓ３３８：ＮＯ）、エラー処理を行った後（Ｓ３４７）、ビジーフラグＦｕを下げて（Ｓ３１９）、Ｓ３０３へ処理を戻す。このエラー処理の具体的な内容は、エラーが発生した旨を表す情報を送信用データとして格納領域に書き込んだり、ディスプレイ５２にエラー発生の旨を表示させること等である。
（３−４）入力ジョブ
続いて、図１３におけるＳ２６０にて起動される入力ジョブの処理手順を図１７に基づいて説明する。この入力ジョブは、上述したセッション処理およびＵＩジョブと並列動作する処理である。
この入力ジョブが開始されると、まず、入力デバイスがビジー状態であるか否かを判定する（Ｓ４０２）。ここでは、入力デバイスがビジー状態である場合に立つ（「１」がセットされる）ように設定されたビジーフラグＦｉに基づき、ビジーフラグＦｉが立っていればビジー状態であると判定し、ビジーフラグＦｉが下りて（「０」がセットされて）いればビジー状態でないと判定する。なお、ここでいう「入力デバイス」とは、読取部１３で生成された画像データに関するサービスの提供を受ける場合であれば読取部１３であり、音入力部１７により出力される音を表す音データに関するサービスを受ける場合であれば音入力部１７のことである。
このＳ４０２で、入力デバイスがビジー状態であると判定された場合には（Ｓ４０２：ＹＥＳ）、入力デバイスのビジー状態が解除されるまで待機した後（Ｓ４０４）、Ｓ４０２の処理へ戻る一方、入力デバイスがビジー状態ではないと判定された場合には（Ｓ４０２：ＮＯ）、ビジーフラグＦｉを立てる（Ｓ４０６）。
次に、複合機１０の状態に関する情報である複合機状態情報を、セッション処理におけるＳ２６０にて渡されたジョブＩＤと共に、ＨＴＴＰリクエストにより機能サーバ３０へ送信する（Ｓ４０８）。この複合機状態情報を受信した機能サーバ３０は、後述のように、図１４におけるＳ３２１にて機能サーバ３０に送信しておいたパラメータに基づく情報である複合機パラメータをＨＴＴＰレスポンスにより返信してくる。
次に、Ｓ４０８にて送信した複合機状態情報に対して複合機パラメータが返信されてきたら（Ｓ４１０）、セッション処理から終了指示が渡されたか否か（セッションからの終了指示があるか）を判定する（Ｓ４１２）。この終了指示は、図１２におけるＳ２１８により終了するジョブが入力ジョブである場合において、セッション処理から本入力ジョブに渡される指示である。
このＳ４１２で、セッション処理から終了指示が渡されていないと判定された場合には（Ｓ４１２：ＮＯ）、Ｓ４１０にて返信されてきた複合機パラメータを正常に受信できていなければ（Ｓ４１４：ＮＯ）、機能サーバ３０からの情報を正常に受け取ることができない旨（異常受取（ＮＧ）である旨）を通知するための複合機受取状況を、セッション処理におけるＳ２６０にて渡されたジョブＩＤと共に、ＨＴＴＰリクエストにより機能サーバ３０へ送信する（Ｓ４１６）。この複合機受取状況を受信した機能サーバ３０は、後述のように、再度、複合機パラメータをＨＴＴＰレスポンスとして返信してくるため、このＳ４１６の後、Ｓ４１０へ戻る。
一方、Ｓ４１０にて複合機パラメータを正常に受信できていれば（Ｓ４１４：ＹＥＳ）、機能サーバ３０からの情報を正常に受け取ることができた旨（正常受取（ＯＫ）である旨）を通知するための複合機受取状況を、セッション処理におけるＳ２６０にて渡されたジョブＩＤと共に、ＨＴＴＰリクエストにより機能サーバ３０へ送信する（Ｓ４１８）。この複合機受取状況を受信した機能サーバ３０は、後述のように、機能サーバ３０側で処理すべきデータの送信を要求するための入力データ要求を返信してくる。
次に、複合機受取状況を受信した機能サーバ３０から入力データ要求が返信されてきたら（Ｓ４２０）、Ｓ４１２と同様に、セッション処理から終了指示が渡されたか否かを判定する（Ｓ４２２）。
このＳ４２２で、セッション処理から終了指示が渡されていないと判定された場合には（Ｓ４２２：ＮＯ）、Ｓ４２０にて返信されてきた入力データ要求を正常に受信できていなければ（Ｓ４２４：ＮＯ）、Ｓ４１６と同様に、異常受取（ＮＧ）である旨を通知するための複合機受取状況を機能サーバ３０へ送信する（Ｓ４２６）。この複合機受取状況を受信した機能サーバ３０は、後述のように、再度、入力データ要求を返信してくるため、このＳ４２６の後、Ｓ４２０へ戻る。
一方、Ｓ４２０にて返信されてきた入力データ要求を正常に受信できていれば（Ｓ４２４：ＹＥＳ）、機能サーバ３０側で処理させるべき入力データを、セッション処理におけるＳ２６０にて渡されたジョブＩＤと共に、ＨＴＴＰリクエストにより機能サーバ３０へ送信する（Ｓ４２８）。ここでは、まず、入力デバイスの設定値をＳ４１０にて受信した複合機パラメータで示されるパラメータに変更した後、機能サーバ３０側で処理させるべきデータの入力を促すためのデータ入力画面をディスプレイ５２に表示させることにより、データを複合機１０に入力するための操作をユーザに促す。その後、ユーザによりデータを入力するための操作が行われることにより取得したデータ（入力データ）を、セッション処理におけるＳ２６０にて渡されたジョブＩＤと共に、ＨＴＴＰリクエストにより機能サーバ３０へ送信する。具体的な例としては、例えば、「原稿をセットしてＯＫキーを押してください」，「受話器をとって音声を入力してください」などのメッセージをディスプレイ５２に表示し、この後、読取部１３または音入力部１７により取得されるデータを機能サーバ３０へ順次送信する。この入力データを受信した機能サーバ３０は、この入力データに基づくデータ処理が正常に終了したか否かを通知するためのサービス状態情報を返信してくる、といった構成が考えられる。
なお、この処理におけるデータの取得方法については、図示されないメモリカードスロットにセットされたメモリーカードから読み出したり、記憶部１６における特定の記憶領域から読み出すといった方法であってもよく、その場合には、データの取得先となる記憶領域を指定すべきメッセージをディスプレイ５２に表示させればよい。
こうして、入力データを機能サーバ３０へ送信した後、Ｓ４２８の処理で変更された入力デバイスの設定値を元に戻し（Ｓ４３０）、その後、機能サーバ３０から返信されるサービス状態情報を受信する（Ｓ４３２）。
そして、Ｓ４３２にてサービス情報を受信した後、または、Ｓ４１２，Ｓ４２２でセッション処理から終了指示が渡されていると判定された場合には（Ｓ４１２：ＹＥＳ，Ｓ４２２：ＹＥＳ）、Ｓ４０６にて立てたビジーフラグＦｉを下ろした後（Ｓ４３４）、セッション処理におけるＳ２６０にて渡されたジョブＩＤと共にセッション処理へ入力ジョブの終了を通知して（Ｓ４３６）、本入力ジョブを終了する。この入力ジョブの終了の通知は、上述した図１２のセッション処理のＳ２１８における処理の中で受信される。Ｓ２１８内部ではこの指令を受信することでジョブが完全に停止したと判断し、以降の処理手順を実施する。
（３−５）出力ジョブ
次に、図１３におけるＳ２６６にて起動される出力ジョブの処理手順を図１８に基づいて説明する。この入力ジョブは、上述したセッション処理およびＵＩジョブと並列動作する処理である。
この出力ジョブが開始されると、まず、出力デバイスがビジー状態であるか否かを判定する（Ｓ５０２）。ここでは、出力デバイスがビジー状態である場合に立つ（「１」がセットされる）ように設定されたビジーフラグＦｏに基づき、ビジーフラグＦｏが立っていればビジー状態であると判定し、ビジーフラグＦｏが下りて（「０」がセットされて）いればビジー状態でないと判定する。なお、ここでいう「出力デバイス」とは、記録部１４で印刷する画像データに関するサービスの提供を受ける場合であれば記録部１４であり、音出力部１８により出力される音を表す音データに関するサービスの提供を受ける場合であれば音出力部１８のことである。
このＳ５０２で、出力デバイスがビジー状態であると判定された場合には（Ｓ５０２：ＹＥＳ）、出力デバイスのビジー状態が解除されるまで待機した後（Ｓ５０４）、Ｓ５０２の処理へ戻る一方、出力デバイスがビジー状態ではないと判定された場合には（Ｓ５０２：ＮＯ）、ビジーフラグＦｏを立てる（Ｓ５０６）。
次に、複合機１０の状態に関する情報である複合機状態情報を、セッション処理におけるＳ２６６にて渡されたジョブＩＤと共に、ＨＴＴＰリクエストにより機能サーバ３０へ送信する（Ｓ５０８）。この複合機状態情報を受信した機能サーバ３０は、後述のように、図１４におけるＳ３２１にて機能サーバ３０に送信しておいたパラメータに基づく情報である複合機パラメータをＨＴＴＰレスポンスにより返信してくる。
次に、Ｓ５０８にて送信した複合機状態情報に対して複合機パラメータが返信されてきたら（Ｓ５１０）、セッション処理から終了指示が渡されたか否か（セッションからの終了指示があるか）を判定する（Ｓ５１２）。この終了指示は、図１２におけるＳ２１８により終了するジョブが出力ジョブである場合において、セッション処理から本出力ジョブに渡される指示である。
このＳ５１２で、セッション処理から終了指示が渡されていないと判定された場合には（Ｓ５１２：ＮＯ）、Ｓ５１０にて返信されてきた複合機パラメータを正常に受信できていなければ（Ｓ５１４：ＮＯ）、機能サーバ３０からの情報を正常に受け取ることができない旨（異常受取（ＮＧ）である旨）を通知するための複合機受取状況を、セッション処理におけるＳ２６６にて渡されたジョブＩＤと共に、ＨＴＴＰリクエストにより機能サーバ３０へ送信する（Ｓ５１６）。この複合機受取状況を受信した機能サーバ３０は、後述のように、再度、複合機パラメータを返信してくるため、このＳ５１６の後、Ｓ５１０へ戻る。
一方、Ｓ５１０にて複合機パラメータを正常に受信できていれば（Ｓ５１４：ＹＥＳ）、機能サーバ３０からの情報を正常に受け取ることができた旨（正常受取（ＯＫ）である旨）を通知するための複合機受取状況を、セッション処理におけるＳ２６６にて渡されたジョブＩＤと共に、ＨＴＴＰリクエストにより機能サーバ３０へ送信する（Ｓ５１８）。この複合機受取状況を受信した機能サーバ３０は、後述のように、図１７におけるＳ４２８にて送信した入力データに基づいて処理してなるデータ（出力データ）を返信してくる。
次に、複合機受取状況を受信した機能サーバ３０から出力データが返信されてきたら（Ｓ５２０）、Ｓ５１２と同様に、セッション処理から終了指示が渡されたか否かを判定する（Ｓ５２２）。
このＳ５２２で、セッション処理から終了指示が渡されていないと判定された場合には（Ｓ５２２：ＮＯ）、Ｓ５２０にて返信されてきた出力データを正常に受信できていなければ（Ｓ５２４：ＮＯ）、Ｓ５１６と同様に、異常受取（ＮＧ）である旨を通知するための複合機受取状況を機能サーバ３０へ送信する（Ｓ５２６）。この複合機受取状況を受信した機能サーバ３０は、後述のように、再度、出力データを返信してくるため、このＳ５２６の後、Ｓ５２０へ戻る。
一方、Ｓ５２０にて返信されてきた出力データを正常に受信できていれば（Ｓ５２４：ＹＥＳ）、この出力データを出力デバイスにより出力する（Ｓ５２８）。ここでは、まず、出力デバイスの設定値をＳ５１０にて受信した複合機パラメータで示されるパラメータに変更した後、この出力デバイスにより出力データを出力（例えば、画像データが表す画像の印刷や、音データが表す音声の出力）する。
こうして、出力データの出力デバイスによる出力を終えた後、Ｓ５２８で変更された出力デバイスの設定値を元に戻し（Ｓ５３０）、複合機１０の状態に関する情報である複合機状態情報を、セッション処理におけるＳ２６６にて渡されたジョブＩＤと共に、ＨＴＴＰリクエストにより機能サーバ３０へ送信する（Ｓ５３２）。この複合機状態情報を受信した機能サーバ３０は、後述のように、サービス状態情報を返信してくる。
そして、機能サーバ３０から返信されるサービス状態情報を受信した後（Ｓ５３４）、または、Ｓ５１２，Ｓ５２２でセッション処理から終了指示が渡されていると判定された場合には（Ｓ５１２：ＹＥＳ，Ｓ５２２：ＹＥＳ）、Ｓ４０６にて立てたビジーフラグＦｏを下ろした後（Ｓ５３６）、セッション処理におけるＳ２６６にて渡されたジョブＩＤと共にセッション処理へ入力ジョブの終了を通知して（Ｓ５３８）、本入力ジョブを終了する。この入力ジョブの終了の通知は、上述した図１２のセッション処理のＳ２１８における処理の中で受信される。Ｓ２１８内部ではこの指令を受信することでジョブが完全に停止したと判断し、以降の手順を実施する。
（３−６）ファイル取得処理
次に、図７におけるＳ１１２，Ｓ１３０、図１４のＳ３１５において起動されるファイル取得処理について図１９に基づいて説明する。なお、本ファイル取得処理を終了した場合は起動もとの各処理に戻る。
このファイル取得処理が起動されると、まず、要求されているファイルが記録部１４のキャッシュ領域に存在するか否かをチェックする（Ｓ１５１）。具体的にはキャッシュ管理情報のＵＲＬ項目に記憶されているデータの中に、要求されているＵＲＬが存在するか否かをチェックする（図３１参照）。この結果、要求されているＵＲＬがキャッシュ管理情報の中に存在する場合（Ｓ１５１：ＹＥＳ）、後述するキャッシュ管理情報更新処理１を実行する（Ｓ１５３）。そして、キャッシュから該当ファイルを読み込み（Ｓ１５５）、本ファイル取得処理を終了する。
一方、上述したＳ１５１において、要求されているＵＲＬがキャッシュ管理情報の中に存在しない場合は（Ｓ１５１：ＮＯ）、指定されたファイルを実際に該当サーバから取得する（Ｓ１５７）。そして、その取得したファイルをキャッシュ領域へ記憶させることを試みる。
具体的には、まず、キャッシュ領域が不足しているか否かをチェックする（Ｓ１５９）。キャッシュ領域が不足している場合には（Ｓ１５９：ＹＥＳ）、後述する削除ファイル決定処理１を実行し（Ｓ１６１）、キャッシュ領域から削除するファイルを決定する。その後、削除ファイル決定処理１の実行結果が「削除不可」であるか否かをチェックし（Ｓ１６３）、実行結果が「削除不可」である場合には（Ｓ１６３：ＹＥＳ）、本ファイル取得処理を終了し、一方、実行結果が「削除不可」でない場合には（Ｓ１６３：ＮＯ）、キャッシュから削除ファイル決定処理１（Ｓ１６５）によって決定したファイルをキャッシュ領域から削除する。なお、この際にはキャッシュ管理情報からも該当レコードを削除する。キャッシュ領域からファイルを削除し終えると（Ｓ１６５）、上述したＳ１５９へ処理を戻す。
一方、キャッシュ領域が不足していない場合には（Ｓ１５９：ＮＯ）、後述するキャッシュ登録処理１を実行し（Ｓ１６７）、取得したファイルをキャッシュ領域に記憶させ、本ファイル取得処理を終了する。
（３−７）キャッシュ管理情報更新処理１
次に、図１９のＳ１５３において起動されるキャッシュ管理情報更新処理１について図２０に基づいて説明する。なお、本キャッシュ管理情報更新処理１を終了した場合は起動もとの処理（図１９のＳ１５３以降）に戻る。
キャッシュ管理情報更新処理１の実行を開始すると、上述したキャッシュ管理情報（図３１参照）の該当レコード、つまり、既に記憶されている要求ファイルに対応するレコードの時間情報（Time）を現在時刻で更新する（Ｓ５５３）。更新が終わると、本キャッシュ管理情報更新処理１を終了する。
（３−８）削除ファイル決定処理１
次に、図１９のＳ１６１において起動される削除ファイル決定処理１について図２１および図２２に基づいて説明する。なお、本削除ファイル決定処理１を終了した場合は起動もとの処理（図１９のＳ１６１以降）に戻る。
この削除ファイル決定処理１が起動されると、まず変数Ｎに０（ゼロ）をセットすると共にテンポラリリストを初期化する（Ｓ３５１）。そして、変数Ｎに１だけ足し（Ｓ３５３）、この変数Ｎを用いて上述したキャッシュ管理情報にＮ番目のレコードが存在するか否かをチェックする（Ｓ３５５）。
そして、キャッシュ管理情報にＮ番目のレコードが存在する場合には（Ｓ３５５：ＹＥＳ）、そのＮ番目のレコードにグループＩＤが存在するか否かをチェックする（Ｓ３５７）。そのＮ番目のレコードにグループＩＤが存在する場合には（Ｓ３５７：ＹＥＳ）、そのグループＩＤがテンポラリリストに存在するか否かをさらにチェックし（Ｓ３６１）、一方、そのＮ番目のレコードにグループＩＤが存在しない場合には（Ｓ３５７：ＮＯ）、テンポラリリストにＮ番目のレコードのＵＲＬと時間のペアをコピーし（Ｓ３５９）、上述したＳ３５３に処理を戻す。なお、ここで言うテンポラリリストというのは、制御部１１のＲＡＭ内に設けられた一時的な記憶領域であり、ＵＲＬと時間情報のペア、または、グループＩＤと時間情報のペアを複数記憶することができる記憶領域である。
Ｎ番目のレコードのグループＩＤがテンポラリリストに存在するか否かをチェックした結果（Ｓ３６１）、Ｎ番目のレコードのグループＩＤがテンポラリリストに存在する場合には（Ｓ３６１：ＹＥＳ）、Ｎ番目のレコードの時間情報とテンポラリリストの該当レコードの時間情報とを比較してＮ番目のレコードの時間情報の方が新しいか否かをチェックする（Ｓ３６５）。一方、Ｎ番目のレコードのグループＩＤがテンポラリリストに存在しない場合には（Ｓ３６１：ＮＯ）、テンポラリリストにＮ番目のレコードのグループＩＤと時間情報のペアをコピーし（Ｓ３６３）、上述したＳ３５３に処理を戻す。
Ｎ番目のレコードの時間情報とテンポラリリストのレコードの時間情報とを比較してＮ番目のレコードの時間情報の方が新しいか否かをチェックした結果（Ｓ３６５）、Ｎ番目のレコードの時間情報の方が新しい場合には（Ｓ３６５：ＹＥＳ）、テンポラリリストの該当レコードをキャッシュ管理情報のＮ番目のレコードの時間情報によって更新し（Ｓ３６７）、上述したＳ３５３に処理を戻す。一方、Ｎ番目のレコードの時間情報の方が古い場合には何もせずに上述したＳ３５３に処理を戻す。
また、上述したＳ３５５で、キャッシュ管理情報にＮ番目のレコードが存在しない場合（Ｓ３５５：ＮＯ）には、変数Ｎが１であるか否かをチェックする（図２２のＳ３６９）。そして、変数Ｎが１である場合には（Ｓ３６９：ＹＥＳ）、キャッシュ領域に記憶されているファイルは全て削除することができない旨を結果とし（Ｓ３７３）、本削除ファイル決定処理１を終了する。
一方、変数Ｎが１でない場合には（Ｓ３６９：ＮＯ）、キャッシュ領域から削除する対象ファイルとして、テンポラリリストの中で最も古い時間情報であるレコードのＵＲＬまたはグループＩＤに関連づけられたファイルを決定結果とする（Ｓ３７１）。そして、グループＩＤに関連づけられたファイルを決定結果とした場合には、そのグループＩＤが第一種グループＩＤであるか否かをチェックする（Ｓ３７５）。そのグループＩＤが第一種グループＩＤでない場合には（Ｓ３７５：ＮＯ）、本削除ファイル決定処理１を終了するが、そのグループＩＤが第一種グループＩＤである場合には（Ｓ３７５：ＹＥＳ）、さらに、テンポラリリストにその第一種グループＩＤに対応する第二種グループＩＤが存在するか否かをチェックする（Ｓ３７７）。つまり、第一種グループＩＤのメイングループＩＤをメイングループＩＤとして持つ第二種グループＩＤを検索する。テンポラリリストの中に対応する第二種グループＩＤが存在しない場合には本削除ファイル決定処理１を終了するが、テンポラリリストの中に対応する第二種グループＩＤが存在する場合にはテンポラリリストから上記第一種グループＩＤを削除すると共に変数Ｎから１を引く（Ｓ３７９）。そして、Ｓ３６９に移行し、Ｓ３６９以降の処理を繰り返す。
（３−９）キャッシュ登録処理１
次に、図１９のＳ１６７において起動されるキャッシュ登録処理１について図２３に基づいて説明する。なお、本キャッシュ登録処理１を終了した場合は起動もとの処理（図１９のＳ１６７以降）に戻る。
キャッシュ登録処理１の実行を開始すると、取得したファイルをキャッシュに記憶させると共に、キャッシュ管理情報に新たにレコード（ＵＲＬ、（あればグループＩＤ（Group ID））、ファイル名（Filename）、現時時刻（Time）によって構成されるレコード）を作成する（Ｓ５５１）。更新が終わると本キャッシュ登録処理１を終了する。
（４）機能サーバ３０による処理
次に、機能サーバ３０の制御部３１により実行される各種処理について説明する。
（４−１）機能サーバ処理
はじめに、ＨＴＴＰリクエストが受信される毎に行われる機能サーバ処理の処理手順を図２４，図２５に基づいて説明する。
この機能サーバ処理が起動されると、まず、受信したＨＴＴＰリクエストがサービス起動指令であるか否かをチェックする（Ｓ７０２）。この「サービス起動指令」は、図１２におけるＳ２０２にて複合機１０により送信されるものである。
このＳ７０２で、サービス起動指令であると判定された場合には（Ｓ７０２：ＹＥＳ）、セッションＩＤを生成し、このセッションＩＤを示す送信データを生成すると共に、サービスの実行のためのリソースを確保して該当するプロセスを起動した後（Ｓ７０８）、次の処理（Ｓ７３４）へ移行する。ここで起動するプロセスとは、後述するセッション処理（図２６）のことである。
また、Ｓ７０２で、サービス起動指令でないと判定された場合には（Ｓ７０２：ＮＯ）、ＨＴＴＰリクエストがサービス終了指令であるか否かをチェックする（Ｓ７１０）。
このＳ７１０で、サービス終了指令であると判定された場合には（Ｓ７１０：ＹＥＳ）、セッションＩＤおよびＳ７０８にて確保されたリソースを解放し、サービス終了を表す送信データを作成した後（Ｓ７１２）、次の処理（図２５のＳ７３４）へ移行する。一方、サービス終了指令ではないと判定された場合には（Ｓ７１０：ＮＯ）、サービス（セッション又はジョブ）に関する情報が含まれているか否か，具体的には複合機１０がセッション処理またはジョブ（ＵＩジョブ，入力ジョブ，出力ジョブ）において送信してきたＨＴＴＰリクエストであるか否かをチェックする（Ｓ７１４）。
このＳ７１４で、サービスに関する情報が含まれていると判定された場合には（Ｓ７１４：ＹＥＳ）、そのＨＴＴＰリクエストを送信してきたプロセス（セッション処理，ＵＩジョブ，入力ジョブ，出力ジョブのいずれか）を特定する（Ｓ７１６）。
このＳ７１６によりプロセスを特定できなければ（Ｓ７１８：ＹＥＳ）、エラーを通知するための情報（エラー通知情報）を生成した後（Ｓ７２０）、次の処理（Ｓ７３４）へ移行する。
一方、Ｓ７１６によりプロセスを特定できれば（Ｓ７１８：ＮＯ）、その特定したプロセスにＨＴＴＰリクエストにて送信されてきた情報を渡す（Ｓ７２２）。
こうして、Ｓ７２２を終えた後、または、Ｓ７１４にてサービスに関する情報が含まれていないと判定された場合（Ｓ７１４：ＮＯ）、セッションＩＤまたはジョブＩＤに対応する情報の記憶領域を特定する（Ｓ７２４）。
このＳ７２４により記憶領域を特定できなければ（Ｓ７２６：ＹＥＳ）、Ｓ７２０へ移行してエラー通知情報を生成して次の処理（Ｓ７３４）へ移行する。一方、記憶領域を特定できれば（Ｓ７２６：ＮＯ）、この記憶領域に複合機１０へ返信すべき情報が存在しているか否かをチェックする（Ｓ７２８）。
そして、このＳ７２８で、返信すべき情報が存在していないと判定されたら（Ｓ７２８：ＮＯ）、「指令なし」の情報を生成した後（Ｓ７３０）、次の処理（Ｓ７３４）へ移行する。一方、送信すべき情報が存在していると判定されたら（Ｓ７２８：ＹＥＳ）、その返信情報に基づいて複合機制御指令を生成した後（Ｓ７３２）、次の処理（Ｓ７３４）へ移行する。
こうして、Ｓ７０８，Ｓ７１２，Ｓ７２０．Ｓ７３０，Ｓ７３２にて生成した情報をＨＴＴＰレスポンスとして複合機１０へ返信する（Ｓ７３４）。ここで返信されるＨＴＴＰレスポンスのうち、Ｓ７０８にて生成された送信データは、図１２におけるＳ２０４にて複合機１０が受信するものである。また、Ｓ７１２にて生成されたサービス終了を表す送信データは、図１２におけるＳ２０８にて複合機１０が受信し、Ｓ２２２にてＹＥＳで判定されるものである。また、Ｓ７２０にて生成されたエラー通知情報は、図１２におけるＳ２０８にて複合機１０が受信し、Ｓ２２２にてＮＯと判定され、Ｓ２２４の処理が実施されるものである。また、Ｓ７３０にて生成された「指令なし」の情報は、図１２におけるＳ２０８にて複合機１０が受信し、Ｓ２２０にてＹＥＳと判定されるものである。そして、Ｓ７３２にて生成された複合機制御指令は、後述する各ジョブにおいて異なる内容のものとなり、それぞれ複合機１０側で対応するジョブにおいて受信されるものである。
そして、サービス制御情報処理（Ｓ７１４〜Ｓ７３２）が実施されたのであれば（Ｓ７３６：ＹＥＳ）、セッションＩＤ又はジョブＩＤに対応するメモリアドレスに「送信済み」をセットした後（Ｓ７３８）、本機能サーバ処理を終了する。一方、サービス制御情報処理が実施されていなければ（Ｓ７３６：ＮＯ）、メモリアドレスのセットを行うことなく、本機能サーバ処理を終了する。
（４−２）セッション処理
続いて、機能サーバ処理と並行して実行されるセッション処理の処理手順を図２６，図２７に基づいて説明する。なお、本実施形態においては、翻訳コピーのサービスについてのセッション処理を例に説明する。
このセッション処理が開始されると、まず、初期化処理を行う（Ｓ８０２）。
次に、サービス側ＵＩジョブを起動する（Ｓ８０４）。このＵＩジョブは、本セッション処理と並行して実行される処理であって、詳細な処理手順は後述する。
次に、ＵＩジョブの起動指令を複合機指令として出力する（Ｓ８０６）。ここでは、ジョブＩＤおよび通信先アドレスと共にＵＩジョブの起動指令を、返信情報を格納する記憶領域に書き込む処理を行う。これに基づいて、図２４におけるＳ７３２にて複合機制御指令が生成され、図２５におけるＳ７３４にて複合機１０側に起動指令として送信されることとなる。この起動指令は、図１２におけるＳ２０８にて複合機１０側で受信され、これに基づいて、複合機１０側においてＵＩジョブが起動されることとなる（図１３のＳ２５４）。
次に、複合機１０側からのパラメータの入力が完了したか否かをチェックする（Ｓ８０８）。上述したＳ８０４にて起動したＵＩジョブにおいては、後述のように、複合機１０側からパラメータを取得し、その旨を本セッション処理に対して通知してくるように構成されている。そのため、このＳ８０８では、このＵＩジョブからのパラメータ取得の通知がなされた場合に、複合機１０側からのパラメータの入力が完了したと判定する。
このＳ８０８で、パラメータの入力が完了していないと判定された場合には（Ｓ８０８：ＮＯ）、ＵＩジョブが停止したか否かをチェックする（Ｓ８１０）。上述したＳ８０４にて起動したＵＩジョブにおいては、後述のように、複合機１０側からのパラメータの取得が正常に行われなかった場合に、ＵＩジョブ自体を停止（終了）すると共に、その旨を本セッション処理に対して通知してくるように構成されている。そのため、このＳ８１０では、このＵＩジョブからの停止の通知がなされた場合に、ＵＩジョブが停止したと判定する。
このＳ８１０で、ＵＩジョブが停止していないと判定された場合（Ｓ８１０：ＮＯ）、Ｓ８０８へ戻る一方、ＵＩジョブが停止していると判定された場合（Ｓ８１０：ＹＥＳ）、後述するＳ８４８へ移行する。
また、Ｓ８０８で、パラメータの入力が完了していると判定された場合には（Ｓ８０８：ＹＥＳ）、サービス側入力ジョブの一種であるスキャンジョブを起動する（Ｓ８１２）。このスキャンジョブは、本セッション処理と並行して実行される処理であって、詳細な処理手順は後述する。
次に、スキャン（入力）ジョブの起動指令を複合機指令として出力する（Ｓ８１４）。ここでは、ジョブＩＤおよび通信先アドレスと共にスキャンジョブの起動指令を、返信情報を格納する記憶領域に書き込む処理を行う。これに基づいて、図２４におけるＳ７３２にて複合機制御指令が生成され、図２５におけるＳ７３４にて複合機１０側に起動指令として送信されることとなる。この起動指令は、図１２におけるＳ２０８にて複合機１０側で受信され、これに基づいて、複合機１０側において入力ジョブが起動されることとなる。
次に、複合機１０側でスキャナ（読取部１３）の準備が完了したか否かをチェックする（Ｓ８１６）。上述したＳ８１２にて起動したスキャンジョブにおいては、後述のように、複合機１０側においてスキャナの準備が完了したことの通知を受け、その旨を本セッション処理に通知してくるように構成されている。そのため、このＳ８１６では、このスキャンジョブからのスキャナの準備が完了したことの通知がなされた場合に、複合機１０側でスキャナの準備が完了したと判定する。
このＳ８１６で、複合機１０側でスキャナの準備が完了していないと判定された場合には（Ｓ８１６：ＮＯ）、スキャンジョブが停止したか否かをチェックする（Ｓ８１８）。上述したＳ８１２にて起動したスキャンジョブにおいては、後述のように、複合機１０側からスキャナの準備が完了したことの通知を正常に受けられなかった場合に、スキャンジョブ自体を停止（終了）すると共に、その旨を本セッション処理に対して通知してくるように構成されている。そのため、このＳ８１８では、このスキャンジョブからの停止の通知がなされた場合に、スキャンジョブが停止したと判定する。
このＳ８１８で、スキャンジョブが停止していないと判定された場合（Ｓ８１８：ＮＯ）、Ｓ８１６へ戻る一方、スキャンジョブが停止していると判定された場合（Ｓ８１８：ＹＥＳ）、後述するＳ８４４へ移行する。
また、Ｓ８１６で、スキャナの準備が完了していると判定された場合には（Ｓ８１６：ＹＥＳ）、サービス側出力ジョブの一種である印刷ジョブを起動する（Ｓ８２０）。この印刷ジョブは、本セッション処理と並行して実行される処理であって、詳細な処理手順は後述する。
次に、印刷（出力）ジョブの起動指令を複合機指令として出力する（Ｓ８２２）。ここでは、ジョブＩＤおよび通信先アドレスと共に印刷ジョブの起動指令を、返信情報を格納する記憶領域に書き込む処理を行う。これに基づいて、図２４におけるＳ７３２にて複合機制御指令が生成され、図２５におけるＳ７３４にて複合機１０側に起動指令として送信されることとなる。この起動指令は、図１２におけるＳ２０８にて複合機１０側で受信され、これに基づいて、複合機１０側において出力ジョブが起動されることとなる（図１３のＳ２６６）。
次に、複合機１０側で印刷準備（記録部１４）の準備が完了したか否かをチェックする（Ｓ８２４）。上述したＳ８２０にて起動した印刷ジョブにおいては、後述のように、複合機１０側において印刷準備が完了したことの通知を受け、その旨を本セッション処理に通知してくるように構成されている。そのため、このＳ８２４では、この印刷ジョブからの印刷準備が完了したことの通知がなされた場合に、複合機１０側で印刷準備が完了したと判定する。
このＳ８２４で、複合機１０側で印刷準備が完了していないと判定された場合には（Ｓ８２４：ＮＯ）、印刷ジョブが停止したか否かをチェックする（Ｓ８２６）。上述したＳ８２０にて起動した印刷ジョブにおいては、後述のように、複合機１０側から印刷準備が完了したことの通知を正常に受けられなかった場合に、印刷ジョブ自体を停止（終了）すると共に、その旨を本セッション処理に対して通知してくるように構成されている。そのため、このＳ８２６では、この印刷ジョブからの停止の通知がなされた場合に、印刷ジョブが停止したと判定する。
このＳ８２６で、印刷ジョブが停止していないと判定された場合（Ｓ８２６：ＮＯ）、Ｓ８２４へ戻る一方、印刷ジョブが停止していると判定された場合（Ｓ８２６：ＹＥＳ）、後述するＳ８４０へ移行する。
また、Ｓ８２４で、印刷準備が完了していると判定された場合には（Ｓ８２４：ＹＥＳ）、複合機１０側から取得された入力データを読み出す（Ｓ８２８）。上述したＳ８１２にて起動したスキャンジョブにおいては、後述のように、複合機１０から、この複合機１０の読取部１３にて読み取られた画像データを取得するように構成されているため、このＳ８２８では、こうして取得されて所定の記憶領域に格納されたデータ（入力データ）のうち、１頁分に相当するデータ領域を読み出す。
次に、Ｓ８２８にて読み出された入力データに対してＯＣＲ，翻訳，印刷レイアウトなどの処理を施してなる画像データを生成する（Ｓ８３０）。ここでは、まず、Ｓ８２８にて読み出された入力データに対してＯＣＲ処理を施すことにより、この入力データで表される画像に含まれるテキスト部分を認識する。次に、このテキスト部分に対して翻訳処理を行うことによりテキスト部分を所定の言語で表現されたテキストに変換する。なお、ここでの翻訳処理は、上述したＳ８０４にて起動したＵＩジョブにおいて取得されるパラメータに基づいて行われるものであり、このパラメータで示される言語への変換が行われることとなる。そして、こうして認識されたテキスト部分について、所定の印刷レイアウトを設定してなる印刷用の画像データを生成する。
次に、Ｓ８３０にて生成された画像データを出力する（Ｓ８３２）。ここでは、ジョブＩＤおよび通信先アドレスと共にＳ８３０にて生成された画像データを、返信情報を格納する記憶領域に書き込む処理を行う。これに基づいて、図２４におけるＳ７３２にて複合機制御指令が生成され、図２５におけるＳ７３４にて複合機１０側に出力データとして送信されることとなる。この出力データは、図１８におけるＳ５２０にて複合機１０側で受信され、これに基づいて出力データで示される画像の記録部１４による記録が行われる。
次に、Ｓ８２８にて全ての入力データ（全ページ分のデータ領域）についての読み出しが完了したか否かをチェックし（Ｓ８３４）、完了していなければ（Ｓ８３４：ＮＯ）、Ｓ８２８へ戻る一方、完了していれば（Ｓ８３４：ＹＥＳ）、Ｓ８３２による出力データの出力（記憶領域への書き込み）が終了したか否かをチェックする（Ｓ８３６）。
このＳ８３６で、出力データの出力が完了していなければ（Ｓ８３６：ＮＯ）、Ｓ８２８へ戻る一方、出力データの出力が完了していれば（Ｓ８３６：ＹＥＳ）、印刷（出力）ジョブの終了指令を複合機指令として出力する（Ｓ８３８）。ここでは、ジョブＩＤと共に印刷ジョブの終了指令を、返信情報を格納する記憶領域に書き込む処理を行う。これに基づいて、図２４におけるＳ７３２にて複合機制御指令が生成され、図２５におけるＳ７３４にて複合機１０側に終了指令として送信されることとなる。この終了指令は、図１２におけるＳ２０８にて複合機１０側で受信され、これに基づいて、複合機１０側において出力ジョブが停止（終了）されることとなる（図１２のＳ２１８）。
こうして、印刷ジョブの終了指令を出力した後、または、上述したＳ８２６で印刷ジョブが停止されたと判定された場合（Ｓ８２６：ＹＥＳ）、Ｓ８２０で起動させたサービス側印刷ジョブを終了させる（Ｓ８４０）。
次に、スキャン（入力）ジョブの終了指令を複合機指令として出力する（Ｓ８４２）。ここでは、ジョブＩＤと共にスキャンジョブの終了指令を、返信情報を格納する記憶領域に書き込む処理を行う。これに基づいて、図２４におけるＳ７３２にて複合機制御指令が生成され、図２５におけるＳ７３４にて複合機１０側に終了指令として送信されることとなる。この終了指令は、図１２におけるＳ２０８にて複合機１０側で受信され、これに基づいて、複合機１０側において入力ジョブが停止（終了）されることとなる（図１２のＳ２１８）。
こうして、スキャンジョブの終了指令を出力した後、または、上述したＳ８１８でスキャンジョブが停止されたと判定された場合（Ｓ８１８：ＹＥＳ）、Ｓ８１２で起動させたサービス側スキャンジョブを終了させる（Ｓ８４４）。
次に、ＵＩジョブの終了指令を複合機指令として出力する（Ｓ８４６）。ここでは、ジョブＩＤと共にスキャンジョブの終了指令を、返信情報を格納する記憶領域に書き込む処理を行う。これに基づいて、図２４におけるＳ７３２にて複合機制御指令が生成され、図２５におけるＳ７３４にて複合機１０側に終了指令として送信されることとなる。この終了指令は、図１２におけるＳ２０８にて複合機１０側で受信され、これに基づいて、複合機１０側においてＵＩジョブが停止（終了）されることとなる（図１２のＳ２１８）。
そして、各ジョブにおいて確保されていたリソースを解放するなどの終了処理を行った後（Ｓ８５０）、本セッション処理を終了する（Ｓ８５２）。このＳ８５２では、サービスの終了指令を、返信情報を格納する記憶領域に書き込む処理を行う。これに基づいて、図２５におけるＳ７３２にて複合機制御指令が生成され、図２５におけるＳ７３４にて複合機１０側に終了指令として送信されることとなる。この終了指令は、図１２におけるＳ２０８にて複合機１０側で受信され、これに基づいて、複合機１０側においてセッション処理が終了されることとなる（図１２のＳ２２２）。
（４−３）ＵＩジョブ
続いて、図２６におけるＳ８０４にて起動されるＵＩジョブの処理手順を図２８に基づいて説明する。
このＵＩジョブが開始されると、まず、複合機１０からサービスＩ／Ｆ情報取得要求をＨＴＴＰリクエストにより受信するまで待機し、このサービスＩ／Ｆ情報取得要求を受信したら（Ｓ９０２）、サービスＩ／Ｆ情報３６を複合機１０へＨＴＴＰレスポンスにより送信する（Ｓ９０４）。なお、Ｓ９０４にて送信するサービスＩ／Ｆ情報３６は、図１４におけるＳ３２３にて複合機１０で受信される。
続いて、複合機１０から複合機ジョブ指令問合わせをＨＴＴＰリクエストにより受信するまで待機し、この複合機ジョブ指令問合わせを受信したら（Ｓ９０６）、サービスの実行に必要なパラメータの設定を要求するためのパラメータ要求指令を複合機指令として複合機１０へ返信する（Ｓ９１４）。なお、Ｓ９１４にて送信する複合機指令とは、図１４におけるＳ３２３にて複合機１０に受信されるＨＴＴＰレスポンスであり、サービスＩ／Ｆ情報３６（例えば、翻訳コピーのサービスに対応するもの）が付加されたものである。この複合機指令を受信した複合機１０は、パラメータを図１４のＳ３２１にてＨＴＴＰリクエストを送信してくる。
次に、エラーカウントを初期化する（Ｓ９１６）。ここでは、後述のようにパラメータを正常に受信できない自体が連続して発生した回数をカウントするためのカウンタをリセット（「０」をセット）する。
次に、Ｓ９１４にて送信した複合機指令を受信した複合機１０からパラメータが送信されてくるまで待機し、パラメータを受信したら（Ｓ９１８）、このパラメータを正常に受信できているか否かをチェックする（Ｓ９２０）。
このＳ９２０にてパラメータが正常に受信できていないと判定された場合には（Ｓ９２０：ＮＯ）、このような正常に受信できない状況が所定の回数（本実施形態においては２回）連続して発生しているか否かをエラーカウントによるカウント値に基づいてチェックし（Ｓ９２２）、所定の回数連続して発生していなければ（Ｓ９２２：ＮＯ）、パラメータを正常に受信できなかった旨（サーバ受取ＮＧ；異常受取）を通知するためのサーバ受取状況を出力し（Ｓ９２４）、エラーカウントをカウントアップした後（Ｓ９２６）、Ｓ９１８へ戻る。このＳ９２４では、サーバ受取状況を、返信情報を格納する記憶領域に書き込む処理を行う。これに基づいて、図２４におけるＳ７３２にて複合機制御指令が生成され、図２５におけるＳ７３４にて複合機１０側にサーバ受取状況として送信されることとなる。このサーバ受取状況は、図１４におけるＳ３２３にて複合機１０側で受信され、これに基づいて、複合機１０側においてパラメータの再送信が行われることとなる（図１４のＳ３４１，Ｓ３４３等）。
また、Ｓ９２２で、正常に受信できない状況が所定の回数連続して発生していたら（Ｓ９２２：ＹＥＳ）、セッション処理に対してＵＩジョブの停止（終了）を通知した後（Ｓ９２８）、本ＵＩジョブを終了する。このＳ９２８による通知は、図２６におけるＳ８１０にてセッション処理が受けるものである。
また、上述したＳ９２０で、パラメータが正常に受信できていると判定された場合には（Ｓ９２０：ＹＥＳ）、パラメータを正常に受信できた旨（サーバ受取ＯＫ；正常受取）を通知するためのサーバ受取状況を出力する（Ｓ９３０）。ここでは、サーバ受取状況を、返信情報を格納する記憶領域に書き込む処理を行う。これに基づいて、図２４におけるＳ７３２にて複合機制御指令が生成され、図２５におけるＳ７３４にて複合機１０側にサーバ受取状況として送信されることとなる。このサーバ受取状況は、図１４におけるＳ３２３にて複合機１０側で受信され、これに基づいて、複合機１０側においてパラメータの再送信が必要ないことが確認される（図１４のＳ３４１，Ｓ３４３））。
次に、セッション処理に対してパラメータの入力が完了（パラメータを取得）した旨を通知する（Ｓ９３２）。ここでの通知は、図２６におけるＳ８０８にてセッション処理が受けるものである。
そして、このＳ９３２を終えた以降、複合機１０からサービス状態情報要求を受信するまで待機し、このサービス状態情報要求を受信したら（Ｓ９３４）、サービス状態情報を出力する（Ｓ９３６）。そして、このような処理を、他の処理（例えば、図２７におけるＳ８４４）により本ＵＩジョブが停止（終了）されるまで繰り返し行う。このＳ９３６では、サービス状態情報を、返信情報を格納する記憶領域に書き込む処理を行う。これに基づいて、図２４におけるＳ７３２にて複合機制御指令が生成され、図２５におけるＳ７３４にて複合機１０側にサービス状態情報として送信されることとなる。
（４−４）スキャンジョブ
続いて、図２６におけるＳ８１２にて起動されるスキャンジョブの処理手順を図２９に基づいて説明する。
このスキャンジョブが開始されると、まず、複合機１０から複合機状態情報を受信するまで待機し、この複合機状態情報を受信したら（Ｓ１００２）、図２８におけるＳ９０６と同様にエラーカウントを初期化した後（Ｓ１００４）、複合機パラメータを出力する（Ｓ１００６）。このＳ１００２にて受信される複合機状態情報は、図１７におけるＳ４０８にて複合機１０から送信されてくるＨＴＴＰリクエストであり、これに応答する形でＳ１００６にて複合機パラメータをＨＴＴＰレスポンスとして返信する。この複合機パラメータは、図２８におけるＳ９０８にて受信されたものであって、Ｓ１００２にて受信された複合機状態情報の送信元である複合機１０に対応するパラメータである。
この複合機パラメータを受信した複合機１０からは、この複合機パラメータを正常に受信できたか否かを示す複合機受取状況が送信されてくるため、この複合機受取状況に基づいて複合機１０側で正常に受け取ることができたか否かをチェックする（Ｓ１００８）。具体的には、複合機受取状況が、異常受取（ＮＧ）である旨の内容であれば正常に受け取ることができていないと判定し、正常受取（ＯＫ）である旨の内容であれば正常に受け取ることができていると判定する。
このＳ１００８で、複合機１０側で複合機パラメータを正常に受け取ることができていないと判定された場合（Ｓ１００８：ＮＯ）、このような正常に受信できない状況が所定の回数（本実施形態においては２回）連続して発生しているか否かをエラーカウントによるカウント値に基づいてチェックし（Ｓ１０１０）、所定の回数連続して発生していなければ（Ｓ１０１０：ＮＯ）、エラーカウントをカウントアップした後（Ｓ１０１２）、Ｓ１００６へ戻る。
また、Ｓ１０１０で、正常に受信できない状況が所定の回数連続して発生していたら（Ｓ１０１０：ＹＥＳ）、セッション処理に対してスキャンジョブの停止（終了）を通知した後（Ｓ１０１４）、異常終了を通知するための通知指令をサービス状態情報として出力する（Ｓ１０１６）。このＳ１０１４による通知は、図２６におけるＳ８１８にてセッション処理が受けるものである。また、Ｓ１０１６では、通知指令を、返信情報を格納する記憶領域に書き込む処理を行う。これに基づいて、図２４におけるＳ７３２にて複合機制御指令が生成され、図２５におけるＳ７３４にて複合機１０側に通知指令として送信されることとなる。この通知指令は、図１７におけるＳ４１０にて複合機１０側で受信される。
また、上述のＳ１００８で、複合機１０側で複合機パラメータを正常に受け取ることができていると判定された場合（Ｓ１００８：ＹＥＳ）、複合機パラメータの受信をもって複合機１０側でスキャナ（読取部１３）の準備が完了しているものとし、セッション処理に対してスキャナの準備完了を通知する（Ｓ１０１８）。この通知は、図２６におけるＳ８１６にてセッション処理が受けるものである。
次に、機能サーバ３０側で処理すべきデータの送信を要求するための入力データ要求を出力する。ここでは、入力データ要求を、返信情報を格納する記憶領域に書き込む処理を行う（Ｓ１０２０）。これに基づいて、図２４におけるＳ７３２にて複合機制御指令が生成され、図２５におけるＳ７３４にて複合機１０側に入力データ要求として送信されることとなる。この入力データ要求は、図１７におけるＳ４２０にて複合機１０側で受信され、これにより、ユーザの操作を受けて入力データが送信されてくる。
こうして、入力データ要求を受信した複合機１０から入力データを受信したら（Ｓ１０２２）、この入力データの受信が正常に終了していれば（Ｓ１０２４：ＹＥＳ）、正常終了を通知するための通知指令をサービス状態情報として出力した後（Ｓ１０２６）、本スキャンジョブを終了する。このＳ１０２６では、通知指令を、返信情報を格納する記憶領域に書き込む処理を行う。これに基づいて、図２４におけるＳ７３２にて複合機制御指令が生成され、図２５におけるＳ７３４にて複合機１０側に通知指令として送信されることとなる。この通知指令は、図１７におけるＳ４３２にて複合機１０側で受信される。
一方、入力データの受信が正常に終了しなければ（Ｓ１０２４：ＮＯ）、Ｓ１０１６へ移行し、異常終了を通知するための通知指令をサービス状態情報として出力した後、本スキャンジョブを終了する。この通知指令は、図１７におけるＳ４３２にて複合機１０側で受信される。
（４−５）印刷ジョブ
続いて、図２６におけるＳ８２０にて起動される印刷ジョブの処理手順を図３０に基づいて説明する。
この印刷ジョブが開始されると、まず、複合機１０から複合機状態情報を受信するまで待機し、この複合機状態情報を受信したら（Ｓ１１０２）、図２８におけるＳ９０６と同様にエラーカウントを初期化した後（Ｓ１１０４）、複合機パラメータを出力する（Ｓ１１０６）。このＳ１１０２にて受信される複合機状態情報は、図１８におけるＳ５０８にて複合機１０から送信されてくるＨＴＴＰリクエストであり、これに応答する形でＳ１１０６にて複合機パラメータをＨＴＴＰレスポンスとして返信する。この複合機パラメータは、図２８におけるＳ９０８にて受信されたものであって、Ｓ１１０２にて受信された複合機状態情報の送信元である複合機１０に対応するパラメータである。
この複合機パラメータを受信した複合機１０からは、この複合機パラメータを正常に受信できたか否かを示す複合機受取状況が送信されてくるため、図２９におけるＳ１００８と同様、この複合機受取状況に基づいて複合機１０側で正常に受け取ることができたか否かをチェックする（Ｓ１１０８）。
このＳ１１０８で、複合機１０側で複合機パラメータを正常に受け取ることができていないと判定された場合（Ｓ１１０８：ＮＯ）、このような正常に受信できない状況が所定の回数（本実施形態においては２回）連続して発生しているか否かをエラーカウントによるカウント値に基づいてチェックし（Ｓ１１１０）、所定の回数連続して発生していなければ（Ｓ１１１０：ＮＯ）、エラーカウントをカウントアップした後（Ｓ１１１２）、Ｓ１１０６へ戻る。
また、Ｓ１１１０で、正常に受信できない状況が所定の回数連続して発生していたら（Ｓ１１１０：ＹＥＳ）、セッション処理に対して印刷ジョブの停止（終了）を通知した後（Ｓ１１１４）、異常終了を通知するための通知指令をサービス状態情報として出力する（Ｓ１１１６）。このＳ１１１４による通知は、図２６におけるＳ８２６にてセッション処理が受けるものである。また、Ｓ１１１６では、通知指令を、返信情報を格納する記憶領域に書き込む処理を行う。これに基づいて、図２４におけるＳ７３２にて複合機制御指令が生成され、図２５におけるＳ７３４にて複合機１０側に通知指令として送信されることとなる。この通知指令は、図１８におけるＳ５１０にて複合機１０側で受信される。
また、上述のＳ１１０８で、複合機１０側で複合機パラメータを正常に受け取ることができていると判定された場合（Ｓ１１０８：ＹＥＳ）、複合機パラメータの受信をもって複合機１０側で印刷（記録部１４）の準備が完了しているものとし、セッション処理に対して印刷の準備完了を通知する（Ｓ１１１８）。この通知は、図２６におけるＳ８２４にてセッション処理が受けるものである。セッション処理では、この通知を受けて、図２７におけるＳ８２８〜Ｓ８３６を行い、印刷データの送信を行うこととなる。
次に、セッション処理にて生成された印刷データ（図２７におけるＳ８３２）を複合機１０が処理可能な印刷データに変換して送信情報を格納する記憶領域に書き込む処理を行う（Ｓ１１２０）。これに基づいて図２４におけるＳ７３２にて複合機制御指令が生成され、図２５におけるＳ７３４にて複合機１０側に通知指令として送信される。この通知指令は図１８におけるＳ５２０にて複合機１０側で受信される。
こうして、送信される印刷データを受信した複合機１０は、図１８におけるＳ５３２にて複合機状態情報をＨＴＴＰリクエストにより送信してくる。
こうして、印刷データを受信した複合機１０から複合機状態情報を受信したら（Ｓ１１２２）、この複合機状態情報の受信が正常に終了していれば（Ｓ１１２４：ＹＥＳ）、正常終了を通知するための通知指令をサービス状態情報として出力した後（Ｓ１１２６）、本印刷ジョブを終了する。このＳ１１２６では、通知指令を、返信情報を格納する記憶領域に書き込む処理を行う。これに基づいて、図２４におけるＳ７３２にて複合機制御指令が生成され、図２５におけるＳ７３４にて複合機１０側に通知指令として送信されることとなる。この通知指令は、図１８におけるＳ５３４にて複合機１０側で受信される。
一方、複合機状態情報の受信が正常に終了しなければ（Ｓ１１２４：ＮＯ）、Ｓ１１１６へ移行し、異常終了を通知するための通知指令をサービス状態情報として出力した後、本印刷ジョブを終了する。この通知指令は、図１８におけるＳ５３４にて複合機１０側で受信される。
［効果］
このように構成されたサービス提供システムにおいて、複合機１０は、機能サーバ３０によるサービスの提供を受けて機能を実現することとなるが、これに先立ち、ディレクトリサーバ２０からサービス定義情報２５のファイルを取得する。また、機能サーバ３０からもサービスＩ／Ｆ情報３６のファイルを取得する。これらのファイルの取得は、上述したファイル取得処理（図１９参照）によって行われ、その処理の中で、取得しようとしているファイルがキャッシュ領域に存在すれば、実際にサーバからのファイル取得を行わずにキャッシュ領域に存在するファイルを代わりに用いる。そして、キャッシュ領域にファイルが存在せずに新たにサーバからファイルを取得した場合には、キャッシュ領域にファイルを記憶させておく。しかし、無限にキャッシュ領域にファイルを記憶させておくことはできないため、キャッシュ領域に記憶されているファイルを適切に削除する必要がある。
そこで、本サービス提供システムでは、削除すべきファイルか否かの判断をグループＩＤ単位で行う（図２１、図２２参照）。このため、例えばたまたま一度だけ取得したサービスＩ／Ｆ情報３６のファイルによって再利用可能性の高いサービス定義情報２５のファイルがキャッシュ領域から削除される可能性が減り、ファイルの再取得を行う確率も低減する。つまり、サーバの処理負荷の軽減やネットワーク帯域の使用率の軽減につながる。また、複合機１０の使用者にとっても、過去に利用したことがある同一のグループＩＤを有するファイル同士の利用時におけるレスポンスの差が軽減され、複合機１０の使用者の使い勝手も向上する。
また、本サービス提供システムでは、キャッシュからファイルを削除する条件として、最も過去に利用されたファイルから削除するようになっているため（図２２のＳ３７５）、より利用頻度が高いと推測される新しいファイルがキャッシュに残るため、キャッシュの利用効率が高い。
また、グループＩＤは、第一種グループＩＤ（メイングループＩＤのみから構成されるもの）と第二種グループＩＤ（メイングループＩＤとサブグループＩＤとの結合から構成されるもの）との２種類に分けて設定することもできるようになっている。そして、共通のメイングループＩＤを有する第一種グループＩＤと第二種グループＩＤとにおいては、両ＩＤそれぞれに対応するファイルがキャッシュ領域に記憶される場合には削除に制限が課される。具体的には、このような場合に第一種グループＩＤに対応するファイルが先にキャッシュ領域から削除されることが制限される（図２２のＳ３７５〜Ｓ３７９）。
このため、上記実施形態で言えば、図１５に示したサービスＩ／Ｆ情報３６よりも図１１に示したサービス定義情報２５が先にキャッシュ領域から削除されることがない。したがって、より使用頻度の高い図１５に示したサービスＩ／Ｆ情報３６がキャッシュ領域に長く残り、上記効果が得られる。
［変形例］
以上、本発明の実施の形態について説明したが、本発明は、上記実施形態に何ら限定されることはなく、本発明の技術的範囲に属する限り種々の形態をとり得ることはいうまでもない。
例えば、上記実施形態においては、本発明における端末装置として、複合機１０に適用した構成を例示したが、機能サーバ３０により提供されるサービスを受けて機能を実現できる端末装置であれば、複合機以外の装置として、例えば、プリンタ装置，スキャナ装置，ファクシミリ装置などに適用することも可能である。
また、サービスＩ／Ｆ情報３６が設定を要求するパラメータとしては、上記実施形態で例示したもの（解像度等）に限らず、サービスの内容に応じて様々なものが考えられる。例えば、モノクロ／カラーの選択、トナーの濃さ（印刷濃度）、音声のボリューム（音量）等が挙げられる。
また、上記実施形態のサービス提供システムでは、複合機１０、ディレクトリサーバ２０及び機能サーバ３０をそれぞれ１台ずつ備えた構成を例示しているが、このような構成はあくまでも説明を容易にするための構成例にすぎず、サービス提供システムは、これ以外にも様々な構成をとることが可能である。例えば、本発明が適用されたサービス提供システムにおいて、複合機１０は複数設けられていてもよい。具体的には、複数の複合機１０が、共通のディレクトリサーバ２０からのサービス定義情報２５を受信し、共通の機能サーバ３０にサービスを要求するようにすることができる。
また、本発明が適用されたサービス提供システムにおいて、ディレクトリサーバ２０は複数設けられていてもよい。具体的には、例えば、トップのサービス定義情報２５を送信するディレクトリサーバ２０と、各カテゴリのサービス定義情報２５を送信するディレクトリサーバ２０とを、別々のサーバで構成することも可能である。
また、本発明が適用されたサービス提供システムにおいて、機能サーバ３０は複数設けられていてもよい。具体的には、例えば、サービスＩ／Ｆ情報３６を送信する機能サーバ３０と、サービスを実行する機能サーバ３０とを、別々のサーバで構成することも可能である。また、サービスを実行する機能サーバ３０についても、例えば、セッション処理を実行する機能サーバ３０と、ジョブ処理を実行する機能サーバ３０とを、別々のサーバで構成することも可能である。一方、例えば、複数種類のサービスについて、サービスＡを実行する機能サーバ３０、サービスＢ〜Ｄを実行する機能サーバ３０、サービスＥ，Ｆを実行する機能サーバ３０、というように、複数の機能サーバ３０が各自のサービスを実行するというように構成することもできる。この場合、サービスＩ／Ｆ情報３６は、例えば、サービスを実行する機能サーバ３０がそのサービスに対応するサービスＩ／Ｆ情報３６を送信するようにしてもよく、サービスを実行する機能サーバ３０とは別の機能サーバ３０が送信するようにしてもよい。
また、ディレクトリサーバ２０またはディレクトリサーバ２０の一部構成要素，および，機能サーバ３０または機能サーバ３０の一部構成要素が、単一の装置として構成されていてもよい。
また、ディレクトリサーバ２０（またはディレクトリサーバ２０の一部構成要素）や機能サーバ３０（または機能サーバ３０の一部構成要素）が、本サービス提供システムを構成する複合機１０に備えられた構成としてもよい。
また、キャッシュ領域に記憶するファイルを管理するキャッシュ管理情報について上記実施形態では、要求先のアドレスであるＵＲＬ（Uniform Resource Locator）と、そのアドレスのグルーピング情報であるグループＩＤ（Group ID）と、キャッシュファイルのファイル名称（Filename）と、キャッシュにファイルを保存した時刻または再取得に指令があった時刻を時間情報（Time）とによって構成されていたが（図３１参照）、時間情報（Time）の代わりに、指令の頻度（Frequency）を用いるようになっていてもよい（図３２参照）。
以下、この場合における、キャッシュ管理情報更新処理１の代わりに実行されるキャッシュ管理情報更新処理２、削除ファイル決定処理１の代わりに実行される削除ファイル決定処理２、キャッシュ登録処理１の代わりに実行されるキャッシュ登録処理２、そして、新たに追加される頻度更新処理について相違点を中心に説明する。
（ａ）キャッシュ管理情報更新処理２
まず、図１９のＳ１５３において起動されるキャッシュ管理情報更新処理２について図３３に基づいて説明する。なお、本キャッシュ管理情報更新処理２を終了した場合は起動もとの処理（図１９のＳ１５３以降）に戻る。
キャッシュ管理情報更新処理２の実行を開始すると、上述したキャッシュ管理情報（図３２参照）の該当レコード、つまり、既に記憶されている要求ファイルに対応するレコードの頻度（Frequency）に１００を足す（Ｓ５５７）。更新が終わると、本キャッシュ管理情報更新処理２を終了する。
（ｂ）削除ファイル決定処理２
次に、図１９のＳ１６１において起動される削除ファイル決定処理２について図３３および図３４に基づいて説明する。なお、本削除ファイル決定処理２を終了した場合は起動もとの処理（図１９のＳ１６１以降）に戻る。
この削除ファイル決定処理１が起動されると、まず変数Ｎに０（ゼロ）をセットすると共にテンポラリリストを初期化する（Ｓ４５１）。そして、変数Ｎに１だけ足し（Ｓ３５３）、この変数Ｎを用いて上述したキャッシュ管理情報にＮ番目のレコードが存在するか否かをチェックする（Ｓ４５５）。
そして、キャッシュ管理情報にＮ番目のレコードが存在する場合には（Ｓ４５５：ＹＥＳ）、そのＮ番目のレコードにグループＩＤが存在するか否かをチェックする（Ｓ４５７）。そのＮ番目のレコードにグループＩＤが存在する場合には（Ｓ４５７：ＹＥＳ）、そのグループＩＤがテンポラリリストに存在するか否かをさらにチェックし（Ｓ４６１）、一方、そのＮ番目のレコードにグループＩＤが存在しない場合には（Ｓ４５７：ＮＯ）、テンポラリリストにＮ番目のレコードのＵＲＬと頻度のペアをコピーし（Ｓ４５９）、上述したＳ４５３に処理を戻す。なお、ここで言うテンポラリリストというのは、制御部１１のＲＡＭ内に設けられた一時的な記憶領域であり、ＵＲＬと頻度のペア、または、グループＩＤと頻度のペアを複数記憶することができる記憶領域である。
Ｎ番目のレコードのグループＩＤがテンポラリリストに存在するか否かをチェックした結果（Ｓ４６１）、Ｎ番目のレコードのグループＩＤがテンポラリリストに存在する場合には（Ｓ４６１：ＹＥＳ）、Ｎ番目のレコードの頻度とテンポラリリストの該当レコードの頻度とを比較してＮ番目のレコードの頻度の方が新しいか否かをチェックする（Ｓ４６５）。一方、Ｎ番目のレコードのグループＩＤがテンポラリリストに存在しない場合には（Ｓ４６１：ＮＯ）、テンポラリリストにＮ番目のレコードのグループＩＤと頻度のペアをコピーし（Ｓ４６３）、上述したＳ４５３に処理を戻す。
Ｎ番目のレコードの頻度とテンポラリリストのレコードの頻度とを比較してＮ番目のレコードの頻度の方が新しいか否かをチェックした結果（Ｓ４６５）、Ｎ番目のレコードの頻度の方が新しい場合には（Ｓ４６５：ＹＥＳ）、テンポラリリストの該当レコードをキャッシュ管理情報のＮ番目のレコードの頻度によって更新し（Ｓ４６７）、上述したＳ４５３に処理を戻す。一方、Ｎ番目のレコードの頻度の方が古い場合には何もせずに上述したＳ４５３に処理を戻す。
また、上述したＳ４５５で、キャッシュ管理情報にＮ番目のレコードが存在しない場合（Ｓ４５５：ＮＯ）には、変数Ｎが１であるか否かをチェックする（図３４のＳ４６９）。そして、変数Ｎが１である場合には（Ｓ４６９：ＹＥＳ）、キャッシュ領域に記憶されているファイルは全て削除することができない旨を結果とし（Ｓ４７７）、本削除ファイル決定処理２を終了する。
一方、変数Ｎが１でない場合には（Ｓ４６９：ＮＯ）、キャッシュ領域から削除する対象ファイルとして、テンポラリリストの中で頻度の値が最も小さいレコードのＵＲＬまたはグループＩＤに関連づけられたファイルを決定結果とする（Ｓ４７１）。しかし、その頻度というのが１００より大きい場合は決定結果をキャンセルして（Ｓ４７３）、Ｓ４７７に移行する。一方、その頻度というのが１００より小さい場合はＳ４７５に移行する。
Ｓ４７５では、決定結果としたグループＩＤ（ＵＲＬだった場合は本ステップをキャンセル（Ｓ４７６：ＮＯ））が第一種グループＩＤであるか否かをチェックする（Ｓ４７５）。そのグループＩＤが第一種グループＩＤでない場合には（Ｓ４７５：ＮＯ）、本削除ファイル決定処理２を終了するが、そのグループＩＤが第一種グループＩＤである場合には（Ｓ４７５：ＹＥＳ）、さらに、テンポラリリストにその第一種グループＩＤに対応する第二種グループＩＤが存在するか否かをチェックする（Ｓ４７９）。つまり、第一種グループＩＤのメイングループＩＤをメイングループＩＤとして持つ第二種グループＩＤを検索する。テンポラリリストの中に対応する第二種グループＩＤが存在しない場合には本削除ファイル決定処理２を終了するが、テンポラリリストの中に対応する第二種グループＩＤが存在する場合にはテンポラリリストから上記第一種グループＩＤを削除すると共に変数Ｎから１を引く（Ｓ４８１）。そして、Ｓ４６９に移行し、Ｓ４６９以降の処理を繰り返す。
（ｃ）キャッシュ登録処理２
次に、図１９のＳ１６７において起動されるキャッシュ登録処理２について図３６に基づいて説明する。なお、本キャッシュ登録処理２を終了した場合は起動もとの処理（図１９のＳ１６７以降）に戻る。
キャッシュ登録処理２の実行を開始すると、取得したファイルをキャッシュに記憶させると共に、キャッシュ管理情報（図３２参照）に新たにレコード（ＵＲＬ、（あればグループＩＤ（Group ID））、ファイル名（Filename）、頻度（Frequency）＝１００によって構成されるレコード）を作成する（Ｓ５５５）。更新が終わると本キャッシュ登録処理２を終了する。
（ｄ）頻度更新処理
次に、複合機１０の電源投入と同時に起動して実行を開始する頻度更新処理について図３７に基づいて説明する。なお、頻度更新処理は電源が投入されている間、実行され続ける。
頻度更新処理の実行を開始すると、まず、キャッシュ管理情報（図３２参照）の全レコードの頻度（Frequency）を２で割る（Ｓ５５９）。なお、小数点以下は切り捨てる。
そして、２４時間、本頻度更新処理は待機し、２４時間が経過すると再びＳ５５９のステップを実行する。
以上が、キャッシュ管理情報のおける時間情報（Time）の代わりに頻度（Frequency）を用いた場合の キャッシュ管理情報更新処理２、削除ファイル決定処理２、キャッシュ登録処理２、頻度更新処理についての説明である。
また、他の変形例としては、例えば、一般的にＷｅｂの仕組みに適用してもよい。具体的には、図３９に示すようなリンク構造を有するＷｅｂページにおいて、図４０に示すように、メインページのＨＴＭＬにおいてＭＥＴＡタグを用いてＧＲＯＵＰＩＤ（第一種グループＩＤ）を設定し、図４１に示すように、交通案内ページのＨＴＭＬにおいてＭＥＴＡタグを用いてＧＲＯＵＰＩＤ（第二種グループＩＤ）を設定する。このように設定すれば、メインページと交通案内ページとがキャッシュ領域に記憶されている場合、メインページのみがキャッシュ領域から削除されてしまうということが発生しない。つまり、キャッシュに登録された以降は、新たにキャッシュに他のページが登録されたとしても、メインページにアクセスする際のレスポンスの方が交通案内ページにアクセスする際のレスポンスよりも劣ることがなくなる。
［本発明との対応関係］
以上説明した実施形態において、複合機１０が本発明における端末装置であり、ディレクトリサーバ２０および機能サーバ３０が本発明におけるサーバである。
また、通信部２２，通信部３２が本発明におけるサーバ側通信手段であり、記憶部１６，３３が本発明におけるサーバ側記憶手段であり、制御部２１，３１が本発明おけるサーバ側制御手段であり、通信部１５が本発明の端末側通信手段であり、記憶部１６が本発明の端末側記憶手段であり、制御部１１が本発明の端末側制御手段である。
また、グループＩＤが本発明のグルーピング情報に相当する。
サービス提供システムの構成を示すブロック図 操作部の構成を示す図 サービス定義情報における各タグの定義付けを示す図 サービスＩ／Ｆ情報における各タグの定義付けを示す図 複合機と機能サーバとの通信の一例を表すラダーチャート ディレクトリサーバによるディレクトリサーバ処理 複合機による複合機処理 指定方法選択画面を示す図 サービス定義情報のデータ例を示す図（１） サービス選択用画面 サービス定義情報のデータ例を示す図（２） 複合機によるセッション処理（１／２） 複合機によるセッション処理（２／２） 複合機によるＵＩジョブ サービスＩ／Ｆ情報のデータ例を示す図 パラメータ入力画面を示す図 複合機による入力ジョブ 複合機による出力ジョブ 複合機によるファイル取得処理 複合機によるキャッシュ管理情報更新処理１ 複合機による削除ファイル決定処理１（１／２） 複合機による削除ファイル決定処理１（２／２） 複合機によるキャッシュ登録処理１ 機能サーバによる機能サーバ処理（１／２） 機能サーバによる機能サーバ処理（２／２） 機能サーバによるセッション処理（１／２） 機能サーバによるセッション処理（２／２） 機能サーバによるＵＩジョブ 機能サーバによるスキャンジョブ 機能サーバによる印刷ジョブ キャッシュ管理情報の一例を示す図（１） キャッシュ管理情報の一例を示す図（２） 複合機によるキャッシュ管理情報更新処理２ 複合機による削除ファイル決定処理２（１／２） 複合機による削除ファイル決定処理２（２／２） 複合機によるキャッシュ登録処理２ 複合機による頻度更新処理 リンク構造を示す図 メインページのＨＴＭＬファイルの一例を示す図 交通案内ページのＨＴＭＬファイルの一例を示す図
符号の説明
１０…複合機、１１…制御部、１２…操作部、１３…読取部、１４…記録部、１５…通信部、１６…記憶部、１７…音入力部、１８…音出力部、２０…ディレクトリサーバ、２１…制御部、２２…通信部、２３…記憶部、２４…サービス定義情報記憶部、２５…サービス定義情報、３０…機能サーバ、３１…制御部、３２…通信部、３３…記憶部、３４…サービスＩ／Ｆ情報記憶部、３５…サービスソフト記憶部、３６…サービスＩ／Ｆ情報、３７…サービスソフトウェア、４１…コピーキー、４２…スキャナキー、４３…ＦＡＸキー、４４…サービスキー、４５…設定キー、４６…方向キー、４８…方向キー、４９…右キー、５０…ＯＫキー、５１…キャンセルキー、５２…ディスプレイ。

Claims (12)

  1. ファイルを蓄積しているサーバと、そのサーバからファイルを取得して利用する端末装置とから少なくとも構成されるファイル取得システムにおいて、
    前記サーバは、
    ファイルをグルーピング情報に関連づけて記憶するサーバ側記憶手段と、
    前記端末装置と通信を行うサーバ側通信手段と、
    前記サーバ側通信手段を介して前記端末装置から要求されたファイルを前記サーバ側記憶手段から読み出し、その読み出したファイルをそのファイルに関連づけられたグルーピング情報と共に要求元の前記端末装置へ前記サーバ側通信手段を介して送信するサーバ側制御手段と、
    を備え、
    前記端末装置は、
    前記サーバと通信を行う端末側通信手段と、
    ファイルをグルーピング情報に関連づけて記憶する端末側記憶手段と、
    ファイルが必要となった際、その必要なファイルが前記端末側記憶手段に記憶されているか否かを判定し、その必要なファイルが前記端末側記憶手段に記憶されている場合にはその記憶されているファイルを利用し、その必要なファイルが前記端末側記憶手段に記憶されていない場合には前記サーバに要求を行い、前記サーバから前記端末側通信手段を介して送られてきたファイルをそのファイルのグルーピング情報に関連づけて前記端末側記憶手段に記憶させる端末側制御手段と、
    を備え、
    前記端末側制御手段は、前記送られてきたファイルをそのファイルのグルーピング情報に関連づけて前記端末側記憶手段に記憶させる際、予め定められた記憶上限に前記端末側記憶手段が達しているか否かを判定し、前記記憶上限に前記端末側記憶手段が達している場合には、前記端末側記憶手段が記憶している前記ファイルのうち、所定の条件を満たすグルーピング情報に対応する前記ファイルを前記端末側記憶手段から検索し、検索された前記ファイルを前記端末側記憶手段から削除すると共に、前記送られてきたファイルをそのファイルのグルーピング情報に関連づけて前記端末側記憶手段に記憶させ、一方、前記記憶上限に前記端末側記憶手段が達していない場合には、前記端末側記憶手段から前記ファイルを削除することなく前記送られてきたファイルをそのファイルのグルーピング情報に関連づけて前記端末側記憶手段に記憶させること、
    を特徴とするファイル取得システム。
  2. 請求項１に記載のファイル取得システムにおいて、
    前記サーバ側記憶手段は、何れのグルーピング情報にも関連づけられていないファイルも記憶し、
    前記サーバ側制御手段は、前記送信を行う際、対象のファイルが何れのグルーピング情報にも関連づけられていないファイルであった場合にはそのファイルを前記端末側記憶手段から読み出し、前記サーバ側通信手段を介して前記端末装置に送信し、
    前記端末側制御手段は、前記サーバから何れのグルーピング情報にも関連づけられていないファイルが送られてきた場合には、その送られてきたファイルを前記端末側記憶手段に記憶させるが、その際、予め定められた記憶上限に前記端末側記憶手段が達しているか否かを判定し、前記記憶上限に前記端末側記憶手段が達している場合には、前記端末側記憶手段が記憶している前記ファイルのうち、所定の条件を満たす前記ファイルまたはその所定の条件を満たすグルーピング情報に対応する前記ファイルを前記端末側記憶手段から検索し、その検索した前記ファイルを前記端末側記憶手段から削除すると共に、前記送られてきたファイルを前記端末側記憶手段に記憶させ、一方、前記記憶上限に前記端末側記憶手段が達していない場合には、前記端末側記憶手段から前記ファイルを削除することなく前記送られてきたファイルを前記端末側記憶手段に記憶させること、
    を特徴とするファイル取得システム。
  3. 請求項１または請求項２に記載のファイル取得システムにおいて、
    前記グルーピング情報は、メイングルーピング情報のみからなる第一種グルーピング情報と、メイングルーピング情報およびサブグルーピング情報の結合からなる第二種グルーピング情報とに分類でき、
    前記端末側制御手段は、前記検索の際、前記所定の条件を満たすグルーピング情報が第一種グルーピング情報であった場合には、その第一種グルーピング情報のメイングルーピング情報を有する第二種グルーピング情報に関連づけられた前記ファイルが前記端末側記憶手段に記憶されているか否かを判定し、前記端末側記憶手段に該当ファイルが記憶されている場合には、前記所定の条件を満たす前記第一種グルーピング情報を前記所定の条件から除外して再度前記検索を行うこと、
    を特徴とするファイル取得システム。
  4. 請求項１〜請求項３の何れかに記載のファイル取得システムにおいて、
    前記端末側制御手段は、前記サーバから前記端末側通信手段を介して送られてきたファイルを記憶させたときに前記予め定められた記憶上限に前記端末側記憶手段が達するか否かに基づき、前記記憶上限に前記端末側記憶手段が達しているか否かの判定を行うこと、
    を特徴とするファイル取得システム。
  5. 請求項１〜請求項４の何れかに記載のファイル取得システムにおいて、
    前記端末側制御手段は、ファイルが必要となった時の時刻の情報を前記ファイルまたはグルーピング情報に対応させて前記端末側記憶手段に記憶させるようになっており、前記時刻情報を前記所定の条件として、前記グルーピング情報によって関連づけられた前記ファイルを検索すること、
    を特徴とするファイル取得システム。
  6. 請求項１〜請求項４の何れかに記載のファイル取得システムにおいて、
    前記端末側制御手段は、ファイルが必要となった頻度の情報を前記ファイルまたはグルーピング情報に対応させて前記端末側記憶手段に記憶させるようになっており、前記頻度情報を前記所定の条件として、前記グルーピング情報によって関連づけられた前記ファイルを検索すること、
    を特徴とするファイル取得システム。
  7. 請求項６に記載のファイル取得システムにおいて、
    前記端末側制御手段は、前記削除を行う際、削除対象の前記ファイルに対応する前記頻度が所定値以上の場合には削除を行わず、前記サーバから送られてきた前記ファイルを前記端末側記憶手段に記憶させることも行わないこと、
    を特徴とするファイル取得システム。
  8. 請求項６または請求項７に記載のファイル取得システムにおいて、
    前記端末側制御手段は、前記頻度情報を過去のものほど値を減少させて扱うこと、
    を特徴とするファイル取得システム。
  9. 請求項１〜請求項８の何れかに記載のファイル取得システムにおいて、
    前記端末装置は、さらに、情報を印刷媒体に印刷する印刷手段を備えることによりプリンタ装置として機能し、その機能を実現する際のユーザーインターフェースの少なくとも一部を前記サーバから送られてきた前記ファイルに基づいて構成すること、
    を特徴とするファイル取得システム。
  10. 請求項１〜請求項９の何れかに記載のファイル取得システムにおいて、
    前記端末側装置は、さらに、印刷媒体に印刷された情報を読み取り、その読み取った前記情報を外部に送信するスキャナ手段を備えることによりスキャナ装置として機能し、その機能を実現する際のユーザーインターフェースの少なくとも一部を前記サーバから送られてきた前記ファイルに基づいて構成すること、
    を特徴とするファイル取得システム。
  11. 請求項１〜請求項１０の何れかに記載のファイル取得システムにおいて、
    前記端末側装置は、さらに、情報を電話回線を介して他の端末装置に送信するファクシミリ手段を備えることによりファクシミリ装置として機能し、その機能を実現する際のユーザーインターフェースの少なくとも一部を前記サーバから送られてきた前記ファイルに基づいて構成すること、
    を特徴とするファイル取得システム。
  12. サーバと通信を行う端末側通信手段と、
    ファイルをグルーピング情報に関連づけて記憶する端末側記憶手段と、
    ファイルが必要となった際、その必要なファイルが前記端末側記憶手段に記憶されているか否かを判定し、その必要なファイルが前記端末側記憶手段に記憶されている場合にはその記憶されているファイルを利用し、その必要なファイルが前記端末側記憶手段に記憶されていない場合には前記サーバに要求を行い、前記サーバから前記端末側通信手段を介して送られてきたファイルをそのファイルのグルーピング情報に関連づけて前記端末側記憶手段に記憶させる端末側制御手段と、
    を備え、
    前記端末側制御手段は、前記送られてきたファイルをそのファイルのグルーピング情報に関連づけて前記端末側記憶手段に記憶させる際、予め定められた記憶上限に前記端末側記憶手段が達しているか否かを判定し、前記記憶上限に前記端末側記憶手段が達している場合には、前記端末側記憶手段が記憶している前記ファイルのうち、所定の条件を満たすグルーピング情報に対応する前記ファイルを前記端末側記憶手段から検索し、検索された前記ファイルを前記端末側記憶手段から削除すると共に、前記送られてきたファイルをそのファイルのグルーピング情報に関連づけて前記端末側記憶手段に記憶させ、一方、前記記憶上限に前記端末側記憶手段が達していない場合には、前記端末側記憶手段から前記ファイルを削除することなく前記送られてきたファイルをそのファイルのグルーピング情報に関連づけて前記端末側記憶手段に記憶させること、
    を特徴とする端末装置。
JP2004322947A 2004-11-05 2004-11-05 ファイル取得システムおよび端末装置 Expired - Fee Related JP4513509B2 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
JP2004322947A JP4513509B2 (ja) 2004-11-05 2004-11-05 ファイル取得システムおよび端末装置
US11/266,586 US7778495B2 (en) 2004-11-05 2005-11-04 System and device for image processing
EP05256881.3A EP1655945B1 (en) 2004-11-05 2005-11-07 System and device for image processing

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2004322947A JP4513509B2 (ja) 2004-11-05 2004-11-05 ファイル取得システムおよび端末装置

Publications (2)

Publication Number Publication Date
JP2006134112A true JP2006134112A (ja) 2006-05-25
JP4513509B2 JP4513509B2 (ja) 2010-07-28

Family

ID=36727602

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2004322947A Expired - Fee Related JP4513509B2 (ja) 2004-11-05 2004-11-05 ファイル取得システムおよび端末装置

Country Status (1)

Country Link
JP (1) JP4513509B2 (ja)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH07182220A (ja) * 1993-12-21 1995-07-21 Hitachi Ltd 分散ファイルシステムおよびそのファイルキャッシング方法
JPH09305473A (ja) * 1996-05-16 1997-11-28 Fuji Xerox Co Ltd 検索システムにおけるキャッシング方式
JP2000082039A (ja) * 1998-06-30 2000-03-21 Internatl Business Mach Corp <Ibm> 表示制御情報生成方法及びコンピュ―タ
JP2000122832A (ja) * 1998-10-13 2000-04-28 Canon Inc プリンティングジョブ管理装置およびプリンティングジョブ管理方法並びにプリンティングジョブ管理プログラムを記憶した記憶媒体
JP2003022211A (ja) * 2001-07-10 2003-01-24 Nec Corp キャッシュ制御方法及びキャッシュ装置

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH07182220A (ja) * 1993-12-21 1995-07-21 Hitachi Ltd 分散ファイルシステムおよびそのファイルキャッシング方法
JPH09305473A (ja) * 1996-05-16 1997-11-28 Fuji Xerox Co Ltd 検索システムにおけるキャッシング方式
JP2000082039A (ja) * 1998-06-30 2000-03-21 Internatl Business Mach Corp <Ibm> 表示制御情報生成方法及びコンピュ―タ
JP2000122832A (ja) * 1998-10-13 2000-04-28 Canon Inc プリンティングジョブ管理装置およびプリンティングジョブ管理方法並びにプリンティングジョブ管理プログラムを記憶した記憶媒体
JP2003022211A (ja) * 2001-07-10 2003-01-24 Nec Corp キャッシュ制御方法及びキャッシュ装置

Also Published As

Publication number Publication date
JP4513509B2 (ja) 2010-07-28

Similar Documents

Publication Publication Date Title
JP4241577B2 (ja) サービス登録システム、サーバ、端末装置および周辺装置
EP1667419B1 (en) System, device and program for image processing
EP1655949B1 (en) Network system, directory server and terminal device
US20060126110A1 (en) Image processing system, image processing device, server and program
JP2011124956A (ja) 情報処理装置、その制御方法、プログラム、及び記憶媒体
JP2004171515A (ja) 画像形成装置、画像データ転送方法
US20060294182A1 (en) Service providing system, and client, server, and program for the same
JP4297034B2 (ja) サービス提供システムおよびサーバ
JP4867196B2 (ja) 画像処理システム，画像処理装置，サーバおよびプログラム
JP4513509B2 (ja) ファイル取得システムおよび端末装置
JP4168997B2 (ja) 画像処理システム、画像処理装置、サーバ及びプログラム
JP4238587B2 (ja) 画像ファイル管理装置および画像ファイル管理プログラム
JP4239951B2 (ja) サービス提供システム及びプログラム
JP2010177958A (ja) 画像形成システム、画像形成装置および受信ｆａｘ管理サーバ装置
JP4605021B2 (ja) 文書管理装置
JP2006135695A (ja) 画像処理システム，画像処理装置，サーバおよびプログラム
JP4922836B2 (ja) 画像形成装置及びアプリケーション構築方法
JP4631643B2 (ja) 通信装置
JP2006134108A (ja) 通信システム、情報処理装置及びサーバ
JP2003333251A (ja) 画像処理装置
JP4297035B2 (ja) サービス提供システム
JP4258461B2 (ja) 複合機及びプログラム
JP2006189953A (ja) コンテンツ提供システム，クライアントデバイス，サーバおよびプログラム
JP2006197325A (ja) マルチファンクションデバイス、ネットワークストレージサーバ、スキャンストレージシステム
JP2005102248A (ja) ネットワーク接続イメージスキャナ装置

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20070510

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20100122

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20100202

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20100329

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: 20100420

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: 20100503

R150 Certificate of patent or registration of utility model

Ref document number: 4513509

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: 20130521

Year of fee payment: 3

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

Free format text: PAYMENT UNTIL: 20130521

Year of fee payment: 3

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

Free format text: PAYMENT UNTIL: 20140521

Year of fee payment: 4

LAPS Cancellation because of no payment of annual fees