(57)【要約】【課題】クライアントサーバシステムにおいて、ユーザビリティが低下してしまうのを防ぐ。【解決手段】  ＭＦＰ２００と、そのＭＦＰ２００からネットワークを介してアクセス可能なウェブサーバ１００とを備えたクライアントサーバシステムにおいて、ＭＦＰ２００が、ＨＴＴＰリクエストを生成するアクセス要求生成部２１１と、ＨＴＴＰリクエストに係るＵＲＬに基づき識別子の要否を判断する識別子要否判断部２１２と、識別子要と判断した場合にＨＴＴＰリクエストを送信するためのパケットに識別子を付してウェブサーバ１００へ送信するパケット生成送信部２２０とを備え、ウェブサーバ１００が、メインＣＰＵと、サブＣＰＵと、パケットを受信した場合に識別子が付されているか否か判断し、付されていると判断した場合にサブＣＰＵに受信したパケットを渡し、付されていないと判断した場合にメインＣＰＵに受信したパケットを渡す振分部１３１とを備えた。【選択図】        図４
2013225292.tif 000002
【特許請求の範囲】
【請求項１】
クライアント装置と、該クライアント装置からネットワークを介してアクセス可能なサーバ装置とを備えたクライアントサーバシステムであって、
前記クライアント装置が、
前記サーバ装置へのアクセス要求を生成するアクセス要求生成手段と、
該アクセス要求生成手段が生成するアクセス要求に係るアクセス対象のアドレスに基づき、識別子の要否を判断する識別子要否判断手段と、
該識別子要否判断手段が識別子要と判断した場合には、前記アクセス要求生成手段が生成したアクセス要求を送信するためのパケットに前記識別子を付加して、識別子否と判断した場合には該パケットに前記識別子を付加せずに、それぞれ前記サーバ装置へ送信するパケット送信手段とを有し、
前記サーバ装置が、
第１のＣＰＵと、
第２のＣＰＵと、
前記クライアント装置から前記パケットを受信した場合に、該パケットに前記識別子が付加されているか否かを判断する識別子付加判断手段と、
前記クライアント装置から受信したパケットを、前記識別子付加判断手段が前記識別子が付加されていると判断した場合には前記第２のＣＰＵに渡し、前記識別子が付加されていないと判断した場合には前記第１のＣＰＵに渡す振り分け手段とを有することを特徴とするクライアントサーバシステム。
【請求項２】
請求項１に記載のクライアントサーバシステムであって、
前記クライアント装置の前記識別子要否判断手段は、前記アクセス対象のアドレスが予め登録されたアドレスであった場合に、識別子要と判断することを特徴とするクライアントサーバシステム。
【請求項３】
請求項１又は２に記載のクライアントサーバシステムであって、
前記クライアント装置のパケット送信手段は、
前記識別子を、前記アクセス要求を送信するためのＩＰパケットのＩＰヘッダに付加することを特徴とするクライアントサーバシステム。
【請求項４】
請求項３に記載のクライアントサーバシステムであって、
前記サーバ装置の前記振り分け手段は、ネットワーク・インタフェースにおいて受信したＩＰパケットが前記第１及び第２のＣＰＵのいずれにも供給される前に処理する、該第１及び第２のＣＰＵのいずれとも異なる処理回路により実現されることを特徴とするクライアントサーバシステム。
【請求項５】
請求項２に記載のクライアントサーバシステムであって、
前記クライアント装置が、
前記サーバ装置へ表示画面データを要求する際に指定するアクセス対象のアドレスを記憶する記憶手段を備え、
前記クライアント装置の前記識別子要否判断手段が、前記アクセス対象のアドレスが前記記憶手段に記憶されているアドレスであった場合に識別子要と判断することにより、前記パケット送信手段が、前記サーバ装置へ表示画面のデータを要求するアクセス要求を送信するためのパケットに前記識別子を付加するようにしたことを特徴とするクライアントサーバシステム。
【請求項６】
請求項１から５のいずれか一項に記載のクライアントサーバシステムであって、
前記サーバ装置が、
前記第１のＣＰＵと共に動作する第１の制御部と、前記第２のＣＰＵと共に動作する第２の制御部とを備えており、
前記識別子付加判断手段による判断結果に応じて、前記第１の制御部と第２の制御部のへの電源供給を制御する電源制御手段を有することを特徴とするクライアントサーバシステム。
【請求項７】
請求項６に記載のクライアントサーバシステムであって、
前記電源制御手段は、常時は前記第１の制御部と第２の制御部への電源供給をセーブし、前記振り分け手段が前記パケットを渡す方のＣＰＵと共に動作する制御部に、少なくとも該パケットを渡す直前から該パケットに関する処理が完了するまでの間は、正規の電源を供給するように制御することを特徴とするクライアントサーバシステム。
【請求項８】
請求項６に記載のクライアントサーバシステムであって、
前記電源制御手段は、前記第２の制御部には常時正規の電源を供給し、前記第１の制御部には常時は電源供給をセーブしておき、前記振り分け手段が前記パケットを渡す際に、少なくともその直前から該パケットに関する処理が完了するまでの間は、正規の電源を供給するように制御することを特徴とするクライアントサーバシステム。
【請求項９】
ネットワークを介してサーバ装置にアクセス可能なクライアント装置であって、
前記サーバ装置へのアクセス要求を生成するアクセス要求生成手段と、
該アクセス要求生成手段が生成するアクセス要求に係るアクセス対象のアドレスに基づき、識別子の要否を判断する識別子要否判断手段と、
該識別子要否判断手段が識別子要と判断した場合には、前記アクセス要求生成手段が生成したアクセス要求を送信するためのパケットに前記識別子を付加して、識別子否と判断した場合には該パケットに前記識別子を付加させずに、それぞれ前記サーバ装置へ送信するパケット送信手段とを有することを特徴とするクライアント装置。
【請求項１０】
クライアント装置からネットワークを介してアクセス可能なサーバ装置であって、
第１のＣＰＵと、
第２のＣＰＵと、
前記クライアント装置からパケットを受信した場合に、該パケットに識別子が付加されているか否かを判断する識別子付加判断手段と、
前記クライアント装置から受信したパケットを、前記識別子付加判断手段が前記識別子が付加されていると判断した場合には前記第２のＣＰＵに渡し、前記識別子が付加されていないと判断した場合には前記第１のＣＰＵに渡す振り分け手段とを有することを特徴とするサーバ装置。
【請求項１１】
請求項１０に記載のサーバ装置において、
前記第１のＣＰＵと共に動作する第１の制御部と、前記第２のＣＰＵと共に動作する第２の制御部とを備えており、
前記識別子付加判断手段による判断結果に応じて、前記第１の制御部と第２の制御部への電源供給を制御する電源制御手段を有することを特徴とするサーバ装置。
【請求項１２】
請求項１１に記載のクライアントサーバシステムであって、
前記電源制御手段は、常時は前記第１の制御部と第２の制御部への電源供給をセーブし、前記振り分け手段が前記パケットを渡す方のＣＰＵと共に動作する制御部に、少なくとも該パケットを渡す直前から該パケットに関する処理が完了するまでの間は、正規の電源を供給するように制御することを特徴とするクライアントサーバシステム。
【請求項１３】
請求項１１に記載のクライアントサーバシステムであって、
前記電源制御手段は、前記第２の制御部には常時正規の電源を供給し、前記第１の制御部には常時は電源供給をセーブしておき、前記振り分け手段が前記パケットを渡す際に、少なくともその直前から該パケットに関する処理が完了するまでの間は、正規の電源を供給するように制御することを特徴とするクライアントサーバシステム。
【請求項１４】
クライアント装置と、該クライアント装置からネットワークを介してアクセス可能なサーバ装置とを備えたクライアントサーバシステムにおける制御方法であって、
前記クライアント装置が、
前記サーバ装置へのアクセス要求を生成するアクセス要求生成手順と、
該アクセス要求生成手順で生成するアクセス要求に係るアクセス対象のアドレスに基づき、識別子の要否を判断する識別子要否判断手順と、
該識別子要否判断手順で識別子要と判断した場合には、前記アクセス要求生成手順で生成したアクセス要求を送信するためのパケットに前記識別子を付加して、識別子否と判断した場合には該パケットに前記識別子を付加させずに、それぞれ前記サーバ装置へ送信するパケット送信手順とを実行し、
前記サーバ装置が、
前記クライアント装置から前記パケットを受信した場合に、該パケットに前記識別子が付加されているか否かを判断する識別子付加判断手順と、
前記クライアント装置から受信したパケットを、前記識別子付加判断手順で前記識別子が付加されていると判断した場合には第２のＣＰＵに渡し、前記識別子が付加されていないと判断した場合には第１のＣＰＵに渡す振り分け手順とを実行することを特徴とする制御方法。
【請求項１５】
請求項１４に記載の制御方法であって、
前記サーバ装置が、
前記第１のＣＰＵと共に動作する第１の制御部と、前記第２のＣＰＵと共に動作する第２の制御部とを備えており、
前記識別子付加判断手段による判断結果に応じて、前記第１のＣＰＵと共に動作する第１の制御部と前記第２のＣＰＵと共に動作する第２の制御部への電源供給を制御する電源制御手順も実行することを特徴とする制御方法。
【請求項１６】
コンピュータを、ネットワークを介してサーバ装置にアクセス可能なクライアント装置として機能させるためのプログラムであって、
該コンピュータに、
前記サーバ装置へのアクセス要求を生成するアクセス要求生成手順と、
該アクセス要求生成手順で生成するアクセス要求に係るアクセス対象のアドレスに基づき、識別子の要否を判断する識別子要否判断手順と、
該識別子要否判断手順で識別子要と判断した場合には、前記アクセス要求生成手順で生成したアクセス要求を送信するためのパケットに前記識別子を付加して、識別子否と判断した場合には該パケットに前記識別子を付加させずに、それぞれ前記サーバ装置へ送信するパケット送信手順とを実行させるためのプログラム。
【請求項１７】
コンピュータを、クライアント装置からネットワークを介してアクセス可能なサーバ装置として機能させるためのプログラムであって、
該コンピュータに、
前記クライアント装置からパケットを受信した場合に該パケットに識別子が付加されているか否かを判断する識別子付加判断手順と、
前記クライアント装置から受信したパケットを、前記識別子付加判断手順で前記識別子が付加されていると判断した場合には第２のＣＰＵに渡し、前記識別子が付加されていないと判断した場合には第１のＣＰＵに渡す振り分け手順とを実行させるためのプログラム。
【請求項１８】
請求項１７に記載のプログラムであって、
前記コンピュータに、
前記識別子付加判断手順での判断結果に応じて、前記第１のＣＰＵと共に動作する第１の制御部と前記第２のＣＰＵと共に動作する第２の制御部への電源供給を制御する電源制御手順も実行させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、クライアント装置と、そのクライアント装置からネットワークを介してアクセス可能なサーバ装置とを備えたクライアントサーバシステムに関する。
【背景技術】
【０００２】
従来から、プリンタ機能、スキャナ機能及びコピー機能等を有するデジタル複合機であるＭＦＰ（Multi Function Peripheral：多機能周辺装置）が広く用いられている。
近年では、そのＭＦＰをクライアント装置として、サーバ装置であるウェブサーバとネットワークを介して接続することにより、ＭＦＰの一般的な機能以外の付加機能をウェブサーバを用いて実現するクライアントサーバシステムが提供されている。
【０００３】
このクライアントサーバシステムでは、ＭＦＰがウェブブラウザを備え、このウェブブラウザを用いてウェブサーバに様々な要求を行うことができる。そして、ウェブサーバはＭＦＰのウェブブラウザからの様々な要求に基づいて処理を行う。
例えば、ウェブサーバは、データベース上のドキュメントの検索処理や、スキャンデータの文字を認識して文書に変換するＯＣＲ（Optical Character Recognition：光学文字認識）処理などを行うことができる。あるいは、ウェブサーバが、ＭＦＰの表示手段であるＬＣＤ（Liquid Crystal Display：液晶ディスプレイ）パネルに表示する画面のデータである表示画面データを、ＭＦＰに送信する処理を行うこともできる。このように、ウェブサーバは様々な処理を行うことができる。
【０００４】
このようなクライアントサーバシステムにおいて、ウェブサーバに複数のＭＦＰからアクセス可能にすることにより、１台のウェブサーバが備える上述したような処理に係るアプリケーションを、複数のＭＦＰで共有することができる。
従って、各ＭＦＰにアプリケーションを実装する場合と比較すると、実装作業に伴う人件費等のコストを抑えることができるというメリットがある。
また、このようなクライアントサーバシステムでは、ＭＦＰのＬＣＤパネル等に表示する画面のデータである表示画面データをＭＦＰ内で記憶しておく必要がないため、ＭＦＰの記憶装置の容量を節約できるというメリットもある。
【０００５】
例えば、特許文献１には、ウェブサーバ（Ｗｅｂサーバ）と情報処理装置としてのＭＦＰとからなるシステムが記載されている。そのシステムでは、ウェブサーバが適切な画面をＭＦＰに通知できるようにするために、ＭＦＰがユーザの指示による画面遷移のタイミングで自身の装置情報をウェブサーバに送信するようにしている。
【発明の概要】
【発明が解決しようとする課題】
【０００６】
ところで、ウェブサーバが複数のＭＦＰから要求を受け付け得る場合に、要求が集中すると処理に時間がかかる場合がある。
例えば、ユーザがＭＦＰのタッチパネル等からウェブサーバの各アプリケーション（例えばスキャンデータのＯＣＲ処理）の要求を行った場合を考える。このような場合は、処理に多少時間がかかったとしても、ユーザの心理として、ウェブサーバが各アプリケーションの処理を実行していると感じるため、故障などの不安あるいは待つことによるストレスを生じにくい。
【０００７】
しかし、ユーザが速い処理結果を期待するような処理の場合、ユーザとしてはすぐに処理結果が得られることを期待する。そのため、ウェブサーバの処理に時間がかかると、ユーザはＭＦＰが故障しているのではないかと不安になったり、あるいは待たされることによりストレスを生じてしまうという問題があった。
例えば、ユーザがＭＦＰのタッチパネル等を操作して表示画面を遷移させるような場合、ユーザとしてはすぐに新たな表示画面が表示されることを期待する。このような場合に、ウェブサーバが表示画面データを送信するための処理に時間がかかると、ユーザに故障の疑念やストレスを生じさせてしまうという問題があった。
【０００８】
しかしながら、ウェブサーバをサーバ装置とし、ＭＦＰをクライアント装置としたクライアントサーバシステムにおいては、ウェブサーバに要求が集中すると、ユーザが速い処理結果を期待するような処理であっても、その処理に時間がかかる場合がある。そのため、ユーザビリティ（使いやすさ）が悪くなるという問題があった。
特許文献１には、この問題を解決するための技術は開示されていない。
【０００９】
この発明は、このような問題を解決するためになされたものであり、サーバ装置とクライアント装置とを備えたクライアントサーバシステムにおいて、サーバ装置へのアクセスが集中した場合でも、ユーザビリティが低下しないようにすることを目的とする。
【課題を解決するための手段】
【００１０】
上記目的を達成するため、この発明によるクライアントサーバシステムは、クライアント装置と、該クライアント装置からネットワークを介してアクセス可能なサーバ装置とを備えたクライアントサーバシステムを、次のように構成したことを特徴とする。
上記クライアント装置が、
上記サーバ装置へのアクセス要求を生成するアクセス要求生成手段と、
そのアクセス要求生成手段が生成するアクセス要求に係るアクセス対象のアドレスに基づき、識別子の要否を判断する識別子要否判断手段と、
その識別子要否判断手段が識別子要と判断した場合には、上記アクセス要求生成手段が生成したアクセス要求を送信するためのパケットに上記識別子を付加して、識別子否と判断した場合には該パケットに上記識別子を付加せずに、それぞれ上記サーバ装置へ送信するパケット送信手段とを有する。
【００１１】
また、上記サーバ装置が、
第１のＣＰＵと、第２のＣＰＵと、
上記クライアント装置から上記パケットを受信した場合に、そのパケットに上記識別子が付加されているか否かを判断する識別子付加判断手段と、
上記クライアント装置から受信したパケットを、上記識別子付加判断手段が上記識別子が付加されていると判断した場合には上記第２のＣＰＵに渡し、上記識別子が付加されていないと判断した場合には上記第１のＣＰＵに渡す振り分け手段とを有する。
【発明の効果】
【００１２】
この発明のクライアントサーバシステムによれば、サーバ装置がクライアント装置から受信したパケットを、それに識別子が付加されているか否かによって、第１のＣＰＵと第２のＣＰＵとに振り分けて渡して処理することができる。
したがって、クライアント装置からサーバ装置へのアクセスが集中した場合でも、ユーザビリティ（使いやすさ）が低下しないようにすることができる。
【図面の簡単な説明】
【００１３】
【図１】この発明によるクライアントサーバシステムの一実施形態を示すシステム構成図である。
【図２】図１に示したＭＦＰ２００のハードウェア構成を示すブロック図である。
【図３】図１に示したウェブサーバ１００のハードウェア構成を示すブロック図である。
【図４】ウェブサーバ１００とＭＦＰ２００の機能ブロック図である。
【図５】ＭＦＰ２００のＣＰＵ２０１が実行する処理のフローチャートである。
【００１４】
【図６】ＵＲＬテーブルの例を示す図である。
【図７】ＭＦＰ２００が送信するイーサネットフレームの先頭部を示す図である。
【図８】ウェブサーバ１００における処理回路１３０とメインＣＰＵ１１１及びサブＣＰＵ１２１がそれぞれ連係して実行する処理のフローチャートである。
【図９】ＵＲＬテーブルの別の例を示す図である。
【図１０】この発明によるクライアントサーバシステムの他の実施形態におけるウェブサーバ１００′のハードウェア構成を示すブロック図である。
【００１５】
【図１１】ウェブサーバ１００′における処理回路１３０及び電源管理部とメインＣＰＵ１１１及びサブＣＰＵ１２１がそれぞれ連係して実行する処理のフローチャートである。
【図１２】図１１におけるステップＳ３１の処理の詳細を示すフローチャートである。
【図１３】図１１におけるステップＳ３２の処理の詳細を示すフローチャートである。
【図１４】ウェブサーバ１００′における処理回路１３０及び電源管理部とメインＣＰＵ１１１及びサブＣＰＵ１２１がそれぞれ連係して実行する処理の他の例を示すフローチャートである。
【発明を実施するための形態】
【００１６】
以下、この発明を実施するための形態を図面に基づいて説明する。
図１は、この発明によるクライアントサーバシステムの一実施形態を示すシステム構成図である。
このクライアントサーバシステムは、図１に示すように、複数台のＭＦＰ２００と、これらの各ＭＦＰ２００から、ネットワーク３００を介してアクセス可能なウェブサーバ１００とを備えている。
【００１７】
ウェブサーバ１００は、この発明によるサーバ装置の一実施形態であり、各ＭＦＰ２００に付加機能を提供したり、あるいは各ＭＦＰ２００のタッチパネル２０５（図２参照）に表示する画面のデータである表示画面データを提供したりするサーバ装置である。
ＭＦＰ２００は、この発明によるクライアント装置の一実施形態であって、プリンタ機能、スキャナ機能、ＦＡＸ機能、画像データの転送機能などの複数の画像処理機能を有する多機能周辺装置であり、デジタル複合機とも称される。各ＭＦＰ２００の構成及び機能は全て同じである必要はないが、ここでは説明の便宜上全て同じ構成のものとして説明する。
【００１８】
なお、ネットワーク３００としては、ＬＡＮ（ローカルエリア・ネットワーク）やインターネットなど、有線無線を問わず任意の通信ネットワークを採用可能である。また、ＭＦＰ２００の台数は図示の数に限らず、任意の台数を接続可能であり、ＭＦＰ２００以外の画像形成装置や情報処理装置等もクライアント装置として接続可能である。
【００１９】
次に図２を参照して、ＭＦＰ２００のハードウェア構成について説明する。図２は、そのＭＦＰ２００のハードウェア構成を示すブロック図である。
このＭＦＰ２００は図２に示すように、ＣＰＵ２０１、ＲＯＭ２０２、ＲＡＭ２０３、ＨＤＤ２０４、タッチパネル２０５、エンジン部Ｉ／Ｆ２０６、エンジン部２０７及びネットワークＩ／Ｆ２０８を備えている。なお、「エンジン部Ｉ／Ｆ」は「エンジン部インタフェース」の略称であり、「ネットワークＩ／Ｆ」は「ネットワーク・インタフェース」の略称である。
このうち、ＣＰＵ２０１は、ＭＦＰ２００の全体を管理および制御する中央処理装置である。ＲＯＭ２０２は、ＣＰＵ２０１が実行するプログラム及び固定データを格納している不揮発性の記憶手段である。
【００２０】
ＲＡＭ２０３は、ＣＰＵ２０１が実行するプログラムを展開したり一時的なデータ等を格納し、各種処理を行う際の作業領域として使用する読み書き可能な記憶手段である。
ＨＤＤ２０４は、各種データやＣＰＵ２０１が実行するプログラムを記憶する不揮発性の大容量記憶手段である。
タッチパネル２０５は、表示手段である液晶ディスプレイ（ＬＣＤ）上に、ユーザのタッチ操作を検出する検出手段であるタッチセンサを重ねて設けたものである。そして、表示画面データに基づいて画面を表示したり、あるいはユーザからのタッチ操作を受け付けたりする。
【００２１】
エンジン部Ｉ／Ｆ２０６は、エンジン部２０７と通信を行うためのインタフェースである。そのエンジン部２０７は、ＭＦＰ２００の画像処理に関わる各種機能（プリンタ機能、スキャナ機能、コピー機能及びＦＡＸ機能等）を実行するためのハードウェアを有している。
ネットワークＩ／Ｆ２０８は、このＭＦＰ２００が、ウェブサーバ１００とネットワーク３００を介して通信を行うためのインタフェースである。
【００２２】
そして、ＣＰＵ２０１は、ＲＯＭ２０２内の各種プログラムを読み出し、ＲＡＭ２０３に展開した後、その各種プログラムに従って動作する。それによって、この発明に係わる機能であるアクセス要求生成手段、識別子要否判断手段、パケット送信手段、および通知手段としての機能を含む各種機能を実行することができる。
【００２３】
次に図３を参照して、ウェブサーバ１００のハードウェア構成について説明する。図３は、そのウェブサーバ１００のハードウェア構成を示すブロック図である。
このウェブサーバ１００は図３に示すように、メイン制御部１１０、サブ制御部１２０、処理回路１３０及びネットワークＩ／Ｆ１４０を備えている。なお、この「ネットワークＩ／Ｆ」も「ネットワーク・インタフェース」の略称である。
このうち、メイン制御部１１０は、メインＣＰＵ１１１、ＲＯＭ１１２、ＲＡＭ１１３及びＨＤＤ１１４を備えており、メインＣＰＵ１１１と共に動作する第１の制御部である。メインＣＰＵ１１１は、ウェブサーバ１００の全体を管理および制御するとともに、図４によって後述する各種アプリケーション１５４に係る処理等を担当する第１のＣＰＵである。
【００２４】
ＲＯＭ１１２は、メインＣＰＵ１１１が実行するプログラム及び規定データを格納している不揮発性の記憶手段である。
ＲＡＭ１１３は、メインＣＰＵ１１１が実行するプログラムを展開したり一時的なデータ等を格納し、各種処理を行う際の作業領域として使用する読み書き可能な記憶手段である。
ＨＤＤ１１４は、各種データを記憶する不揮発性の大容量記憶手段である。この各種データには、表示画面データであるＨＴＭＬ（Hyper Text Markup Language）文書も含まれる。
【００２５】
一方、サブ制御部１２０は、サブＣＰＵ１２１、ＲＯＭ１２２及びＲＡＭ１２３を備えており、サブＣＰＵ１２１と共に動作する第２の制御部である。サブＣＰＵ１２１は、迅速な処理結果が要求される特定の処理、例えば表示画面データであるＨＴＭＬ文書を要求元へ提供する処理を担当する第２のＣＰＵである。
ＲＯＭ１２２は、サブＣＰＵ１２１が実行するプログラム及び固定データを格納している不揮発性の記憶手段である。
ＲＡＭ１２３は、サブＣＰＵ１２１が実行するプログラムを展開したり一時的なデータ等を格納し、各種処理を行う際の作業領域として使用する読み書き可能な記憶手段である。
【００２６】
なお、この実施形態においては、サブ制御部１２０はメイン制御部１１０のＨＤＤ１１４を共有して使用するようにしているが、サブ制御部１２０が独自にＨＤＤを備えてもよい。
処理回路１３０は、ネットワークＩ／Ｆ１４０がクライアント装置から受信するパケットを、メイン制御部１１０のメインＣＰＵ１１１とサブ制御部１２０のサブＣＰＵ１２１のいずれかに振り分ける機能を有する。この処理回路１３０も専用のＣＰＵ及びＲＯＭ、ＲＡＭ等のメモリを有しているのが望ましい。
【００２７】
ネットワークＩ／Ｆ１４０は、このウェブサーバ１００が、クライアント装置とネットワークを介して通信を行うためのインタフェースである。そのクライアント装置は、ウェブサーバ１００にネットワーク３００を介して接続されている装置であって、ＭＦＰ２００以外の図しない他の装置も含まれる。
【００２８】
次に図４を参照して、ＭＦＰ２００とウェブサーバ１００の機能について説明する。図４は、そのウェブサーバ１００とＭＦＰ２００の機能ブロック図である。
ＭＦＰ２００は、ウェブブラウザ２１０、パケット生成送信部２２０、サービスプロバイダ２３０、スキャナ処理部２４０、プリント処理部２５０及びＦＡＸ処理部２６０を備えている。なお、これら各部の機能は、図２に示したＭＦＰ２００のＣＰＵ２０１が、各種プログラムを実行して各部を制御することにより実現される。
【００２９】
まず、ウェブブラウザ２１０は、アクセス要求生成部２１１、識別子要否判断部２１２、解析表示部２１３を備えている。
このうち、アクセス要求生成部２１１は、ウェブサーバ１００へのアクセス要求であるＨＴＴＰリクエストを生成する。そのＨＴＴＰリクエストには、表示画面データを取得するための要求や、ウェブサーバ１００側で行う各種アプリケーション１５４の実行要求などが含まれる。このアクセス要求生成部２１１が、アクセス要求生成手段の機能に相当する。
【００３０】
ここで、アクセス要求生成部２１１が、ＨＴＴＰリクエストにより表示画面データの要求を行う場合は、アクセス対象である表示画面データの場所を示すパスをＵＲＬ（Uniform Resource Locator）により特定する。そして、その特定したパスを指定してデータを取得する要求を行う。
また、アクセス要求生成部２１１が、ウェブサーバ１００側での後述する各種アプリケーション１５４の実行要求を行う場合は、例えば、アクセス対象であるプログラムのパスをＵＲＩ（Uniform Resource Identifier）により特定する。そして、その特定したパスを指定して、プログラムファイルに係るプログラムの実行要求を行うことが考えられる。
【００３１】
あるいは、ＭＦＰ２００側から、ＨＴＴＰリクエストにアプリケーションを実行させるためのＳＯＡＰ（Simple Object Access Protocol）リクエストを含めて送信することもできる。その場合は、ウェブサーバ１００側で、そのＳＯＡＰリクエストで指定したアプリケーションを実行させる。
ウェブブラウザ２１０の識別子要否判断部２１２は、ＨＴＴＰリクエストに係るアクセス対象を示すＵＲＬ（又はＵＲＩ、以下特に断らない限り同様）に基づき、識別子の要否を判断する。なお、この識別子要否判断部２１２が、ＭＦＰ２００の識別子要否判断手段の機能に相当する。その詳細は後述する。
【００３２】
解析表示部２１３は、ＨＴＴＰリクエストの応答であるＨＴＴＰレスポンスを解析して、その解析した結果に基づいて、図２に示したタッチパネル２０５上に画面を表示する等の機能を有する。
具体的には、例えばＨＴＴＰレスポンスに含まれるＨＴＭＬ文書が表示画面データである場合には、解析表示部２１３はそのＨＴＭＬ文書を解析して、タッチパネル２０５に画面を表示する。
また、ＨＴＴＰレスポンスに含まれるＨＴＭＬ文書が、ＳＯＡＰレスポンスなどアプリケーションの実行結果だった場合は、解析表示部２１３はその実行結果を、レスポンスを処理すべきアプリケーションに渡す。
【００３３】
次に、パケット生成送信部２２０は、ウェブブラウザ２１０のアクセス要求生成部２１１が生成したＨＴＴＰリクエストを送信するためのパケットを生成して、ウェブサーバ１００に送信する機能を有する。
その際、ウェブブラウザ２１０の識別子要否判断部２１２が、識別子要と判断した場合には生成したパケットに所定の識別子を付加して、識別子否と判断した場合にはそのパケットに識別子を付加せずに、それぞれウェブサーバ１００へ送信する。このパケット生成送信部２２０が、パケット送信手段の機能に相当する。
【００３４】
サービスプロバイダ２３０は、ジョブ生成部２３１とジョブ実行部２３２の機能を有する。このサービスプロバイダ２３０は、ウェブサーバ１００の後述するロジック部１５３からアプリケーションの実行要求を受け付けた場合に、その実行要求に係るアプリケーションを実行して、その結果をロジック部１５３に送信する。
そのため、ジョブ生成部２３１は、実行要求に係るアプリケーションを実行するためのジョブを生成する。
【００３５】
また、ジョブ実行部２３２は、ジョブ生成部２３１が生成したジョブを実行する。ここでのジョブとしては、例えばスキャナ処理部２４０、プリント処理部２５０及びＦＡＸ処理部２６０等の機能を実行するためのジョブを含む。
そのスキャナ処理部２４０は、図２に示したエンジン部２０７が有するスキャナ部のハードウェアによって、原稿の画像を読み取るための処理を行う。
プリント処理部２５０は、同じくエンジン部２０７が有するプリンタエンジンのハードウェアによって、用紙等の記録媒体に画像を形成するための処理を行う。
【００３６】
ＦＡＸ処理部２６０は、同じくエンジン部２０７が有するスキャナ部とプリンタエンジンとＦＡＸ通信部のハードウェアによって、ファクシミリ通信を行うための処理を行う。
ファクシミリ通信を行うための処理には、原稿を読み取って相手先へファクシミリ送信する処理と、相手先から送信されたファクシミリデータを受信してプリント出力する処理とを含む。
なお、コピー処理は、スキャナ処理部２４０とプリント処理部２５０との連係処理によってなされる。また、これらのスキャナ処理部２４０、プリント処理部２５０及びＦＡＸ処理部２６０の各機能は、ジョブ実行部２３２に限らず、ユーザが図２に示したタッチパネル２０５の操作によって、直接その実行を指示してもよい。
【００３７】
一方、ウェブサーバ１００は、振分部１３１とウェブアプリケーション１５０の機能を有する。このうち、振分部１３１の機能は、図３に示した処理回路１３０によってなされる。
また、ウェブアプリケーション１５０のうち、画面データ記憶部１５１と表示サービス部１５２の各機能は、サブＣＰＵ１２１（第２のＣＰＵ）が各機能と対応するプログラムを実行することにより実現される。ロジック部１５３とその各種アプリケーション１５４の各機能は、メインＣＰＵ１１１（第１のＣＰＵ）が各機能と対応するプログラムを実行することにより実現される。
【００３８】
これらのうち、振分部１３１は、クライアント装置であるＭＦＰ２００からパケットを受信したときに、そのパケットに所定の識別子が付加されているか否か判断する機能を有する。さらに、この振分部１３１は、受信したパケットに識別子が付加されていると判断した場合には、そのパケットをサブＣＰＵ１２１に渡し、識別子が付加されていないと判断した場合には、そのパケットをメインＣＰＵ１１１に渡す機能も有する。
したがって、この振分部１３１の機能が、ウェブサーバ１００の識別子付加判断手段と振り分け手段に相当する。
【００３９】
次に、ウェブアプリケーション１５０の画面データ記憶部１５１は、ＭＦＰ２００の図２に示したタッチパネル２０５に画面を表示するための表示画面データを、ＨＤＤ１１４に記憶する機能を有している。
表示サービス部１５２は、画面データ記憶部１５１が記憶した表示画面データのうち、振分部１３１から渡されたＨＴＴＰリクエストで指定されている表示画面データを取得する。さらに、表示サービス部１５２は、その取得した表示画面データを対応するＨＴＴＰレスポンスに含めて、ＨＴＴＰリクエストの送信元のＭＦＰ２００に送信する機能を有している。
【００４０】
ロジック部１５３は、振分部１３１から渡されたＨＴＴＰリクエストに基づいて、各種アプリケーション１５４を実行して、その実行結果を対応するＨＴＴＰレスポンスとしてＭＦＰ２００に送信する機能を有している。
各種アプリケーション１５４としては、例えば、ＭＦＰ２００のユーザ認証を行うための認証アプリケーションや、ＯＣＲアプリケーションなどが含まれる。
【００４１】
以上、図１乃至図４を参照しながら説明したウェブサーバ１００とＭＦＰ２００において特徴的な点は、ウェブサーバ１００へのアクセスが集中した場合でも、ユーザビリティが低下しないようにすることである。
そのため、ＭＦＰ２００は、特定の場合にＨＴＴＰリクエストを送信するためのパケットに所定の識別子を付与する。そして、ウェブサーバ１００がパケットを受信したときに、そのパケットに識別子が付加されているか否かに応じて、ＨＴＴＰリクエストをメインＣＰＵ１１１又はサブＣＰＵ１２１の何れかに振り分けるようにした点である。
そこで、この点について以下に詳しく説明する。
【００４２】
まず、上記の点に関して、ＭＦＰ２００及びウェブサーバ１００が実行する処理について説明する。
図５は、ＭＦＰ２００の図２に示したＣＰＵ２０１が実行する処理のフローチャートである。この処理は、ウェブサーバ１００への要求送信のトリガを、ＣＰＵ２０１が検出した場合に実行する。
【００４３】
このようなトリガは、ＭＦＰ２００に対するユーザによる操作、例えば、別の画面に移動するための操作、各種アプリケーションの機能の実行を指示する操作、ウェブサーバ１００に対して各種データの取得を要求する操作などにより発生する。このような操作は、ボタンやキー等のハードウェア操作子により受け付けたものでも、ＧＵＩ（Graphical User Interface）に対する操作であってもよい。
さらに、このようなトリガには、電源投入時にウェブサーバ１００に対して自動的に初期画面の表示画面データを要求する場合のような、自動的な要求送信のトリガも含めてよい。例えば、「電源投入」あるいは「初期化処理が所定の段階まで進んだこと」がトリガとなる。
【００４４】
ＣＰＵ２０１は、上述のトリガを検出すると図５に示す処理を開始する。
そして、ＣＰＵ２０１まずステップＳ１１で、検出したトリガに応じて生成する要求に記載するアクセス対象のリソースのＵＲＬを特定する。
例えば、操作子やＧＵＩの操作に応じて要求を生成する場合、その操作子やＧＵＩの機能を示すデータに、アクセス対象のＵＲＬが含まれているか関連付けられていることが考えられる。
【００４５】
次に、ＣＰＵ２０１はステップＳ１２で、ステップＳ１１で特定したＵＲＬが予め登録されたＵＲＬか否かを判断する。この処理がクライアント装置の識別子要否判断手順に相当する。
ここでは、ＣＰＵ２０１は図６に示すＵＲＬテーブルを参照して、ステップＳ１２の判断を行う。このＵＲＬテーブルは、ウェブサーバ１００において、サブＣＰＵ１２１に処理を担当させる要求に係るＵＲＬを登録したものであり、クライアントサーバシステムの管理者等が、予めＭＦＰ２００のＨＤＤ２０４等に記憶させておく。
【００４６】
この実施形態においては、タッチパネル２０５に表示させる表示画面データを取得する際のアクセス先ＵＲＬを、全てこのＵＲＬテーブルに登録してある。
従って、表示画面データを取得するための処理（ウェブサーバ１００から見れば表示画面データを提供するための処理）は、サブＣＰＵ１２１が担当することになる。
【００４７】
ここで、ＣＰＵ２０１が図５のステップＳ１２において、ステップＳ１１で特定したＵＲＬが予め登録されたＵＲＬである（Ｙ）と判断すると、ステップＳ１３へ進む。そして、ＣＰＵ２０１はステップＳ１１で特定したＵＲＬで特定されるリソースへのアクセスを要求するＨＴＴＰリクエストを生成する。
その後ＣＰＵ２０１は、ステップＳ１４で、ステップＳ１３で生成したＨＴＴＰリクエストを送信するためのＩＰパケットを生成し、そのＩＰヘッダにフラグを立てる。このフラグを立てる処理が識別子の付加に相当する。そして、ステップＳ１７へ進んで、生成したＩＰパケットを送信して処理を終了する。
【００４８】
一方、ＣＰＵ２０１がステップＳ１２の判断において、ステップＳ１１で特定したＵＲＬが予め登録されたＵＲＬでない（Ｎ）と判断すると、ステップＳ１５の処理へ進む。ここでもＣＰＵ２０１はステップＳ１３と同様に、ステップＳ１１で特定したＵＲＬで特定されるリソースへのアクセスを要求するＨＴＴＰリクエストを生成する。
そして、ＣＰＵ２０１はステップＳ１６の処理へ進み、ステップＳ１５で生成したＨＴＴＰリクエストを送信するためのＩＰパケットを生成し、そのＩＰヘッダにフラグを立てない。
【００４９】
このようにＩＰヘッダにフラグを立てない場合、識別子の付与は行われないことになる。その後、ＣＰＵ２０１はステップＳ１７の処理へ進んで、生成したＩＰパケットを送信して処理を終了する。なお、ステップＳ１７におけるＩＰパケットの送信先は、ステップＳ１１で特定したＵＲＬのウェブサーバ１００となる。
この図５におけるステップＳ１３とステップＳ１５の処理が、クライアント装置のアクセス要求生成手順に相当し、ステップＳ１４，Ｓ１６，Ｓ１７の処理がパケット送信手順に相当する。
【００５０】
また、図５のステップＳ１２の処理は、ＭＦＰ２００の図４に示したウェブブラウザ２１０における識別子要否判断部２１２の機能に、ステップＳ１３及びＳ１５の処理は、アクセス要求生成部２１１の機能にそれぞれ相当する。さらに、ステップＳ１４，Ｓ１６，Ｓ１７の処理は、パケット生成送信部２２０の機能に相当する。
なお、この実施形態では、ＨＴＴＰリクエストの送信は、ＴＣＰ／ＩＰ（Transmission
Control Protocol／Internet Protocol）及びイーサネット（登録商標）のプロトコルを用いて行う。この場合、ＣＰＵ２０１は、まずＨＴＴＰリクエストをボディとし、これにＴＣＰのヘッダ及びフッタを付加してＴＣＰパケットを作成する。
【００５１】
次に、ＣＰＵ２０１はそのＴＣＰパケットをボディとし、ＩＰのヘッダ及びフッタを付加してＩＰパケットを作成する。さらに、ＣＰＵ２０１は、そのＩＰパケットをデータフィールドに配置し、イーサネットのヘッダ及びフッタを付加してイーサネットフレームを作成し、そのイーサネットフレームをネットワークＩ／Ｆ２０８から送信する。
図５におけるステップＳ１４及びＳ１６は、これらのうちＩＰパケットの作成までの処理と対応し、ステップＳ１７はイーサネットフレームの作成及び送信の処理と対応する。
【００５２】
この点について、図７を参照しながらさらに説明する。
図７は、ＭＦＰ２００が送信するイーサネットフレームの先頭部を示す図である。すなわち、図５のステップＳ１７で、ＭＦＰ２００が送信するイーサネットフレームのうち、イーサネットヘッダ及びフレームのデータフィールドに配置したＩＰパケットの一部である。
【００５３】
宛先ＭＡＣアドレスと送信元ＭＡＣアドレスとタイプとがイーサネットヘッダであり、それに続く部分がＩＰパケットを配置したデータフィールドである。その先頭にはＩＰヘッダがある。
ＩＰヘッダには、ＩＰパケットの宛先ＩＰアドレスと送信元ＩＰアドレスが含まれるが、それ以外に未使用領域がある。この実施形態では、この未使用領域に１ビットのフラグエリアを設けている。
【００５４】
図５のステップＳ１４でフラグを立てたり、ステップＳ１６でフラグを立てなかったりするのは、このフラグエリアに設けたフラグに関してである。
この実施形態において、ＣＰＵ２０１がＩＰヘッダのフラグエリアを「１」にすることが、ステップＳ１４におけるＩＰヘッダにフラグを立てることであり、ＩＰヘッダにフラグを立てることが識別子を付加することに相当する。
ＩＰヘッダには、送信元のＭＦＰ２００のＩＰアドレスである送信元ＩＰアドレスと、宛先であるウェブサーバ１００のＩＰアドレスである宛先ＩＰアドレスとが含まれる。
【００５５】
次に、ウェブサーバ１００の図３に示したネットワークＩ／Ｆ１４０が、ＭＦＰ２００からのイーサネットフレームを受信したときの処理について、図８を参照して説明する。
図８は、ネットワークＩ／Ｆ１４０がイーサネットフレームを受信したときに、ウェブサーバ１００の処理回路１３０とメインＣＰＵ１１１及びサブＣＰＵ１２１が、それぞれ連係して実行する処理のフローチャートである。なお、図中の破線は処理の実行主体の区別を示している。
【００５６】
サーバ装置であるウェブサーバ１００において、ネットワークＩ／Ｆ１４０がイーサネットフレームを受信すると、まず処理回路１３０が、内蔵のＣＰＵによって図８に示す処理を開始する。
処理回路１３０は、まずステップＳ２１で受信したイーサネットフレームを解析し、そのデータフィールドからＩＰパケットを取り出す。これによって、ウェブサーバ１００はＩＰパケットを受信したことを認識できる。
【００５７】
次に、処理回路１３０はステップＳ２２で、取り出したＩＰパケットのＩＰヘッダを参照し、図７に説明したフラグエリアにフラグが立っているか否かを判断する。この処理が、受信したパケットに識別子が付加されているか否かを判断する識別子付加判断手順に相当する。
【００５８】
そして、処理回路１３０がステップＳ２２で、フラグが立っている（識別子が付加されている）と判断した場合は、ステップＳ２３に進んでサブＣＰＵ１２１にＩＰパケットを渡す。処理回路１３０がステップＳ２２で、フラグが立っていない（識別子が付加されていない）と判断した場合は、ステップＳ２７に進んでメインＣＰＵ１１１にＩＰパケットを渡す。
この処理が、図４における振分部１３１の機能、およびこの発明によるクライアントサーバシステムの制御方法における振り分け手順に相当する。
【００５９】
サブＣＰＵ１２１がＩＰパケットを受け取ると、サブＣＰＵ１２１はステップＳ２４でその受け取ったＩＰパケットを解析し、そのボディ部に含まれるＴＣＰパケットに含まれるＨＴＴＰリクエストを取得する。
そして、ステップＳ２５でそのＨＴＴＰリクエストにより要求された処理を実行し、ステップＳ２６でその処理結果をＨＴＴＰレスポンスとしてＨＴＴＰリクエストの送信元へ送信して、処理を終了する。
【００６０】
一方、メインＣＰＵ１１１がＩＰパケットを受け取ると、メインＣＰＵ１１１はステップＳ２８乃至Ｓ３０で、上述したサブＣＰＵ１２１による処理と同様の処理を行う。
すなわち、メインＣＰＵ１１１は受け取ったＩＰパケットを解析し、そのボディ部に含まれるＴＣＰパケットに含まれるＨＴＴＰリクエストを取得する（Ｓ２８）。そして、そのＨＴＴＰリクエストにより要求された処理を実行し（Ｓ２９）、その処理結果をＨＴＴＰレスポンスとしてＨＴＴＰリクエストの送信元へ送信して（Ｓ３０）、処理を終了する。
【００６１】
ところで、前述したようにこの実施形態においては、図２のタッチパネル２０５に表示させる表示画面データを取得する際のアクセス先ＵＲＬを、全て図６に示したＵＲＬテーブルに登録してある。したがって、図８のフローチャート及び図６のＵＲＬテーブルによれば、ＩＰパケットのフラグエリアにフラグが立っているのは、表示画面データの取得を要求するＨＴＴＰリクエストを含むＩＰパケットとなる。
【００６２】
そして、そのフラグエリアにフラグが立っているＩＰパケットは、サブＣＰＵ１２１に渡される。それによって、サブＣＰＵ１２１は図８におけるステップＳ２５で、ＨＴＴＰリクエストにより要求された処理として、ＨＴＴＰリクエストで指定されているＵＲＬが示す表示画面データを図３のＨＤＤ１１４から取得する。これが、図４における表示サービス部１５２の機能に相当する。
その後、サブＣＰＵ１２１はステップＳ２６で、その取得した表示画面データを含むＨＴＴＰレスポンスをＭＦＰ２００に送信する。
【００６３】
一方、フラグエリアにフラグが立っていないＩＰパケットは、表示画面データの取得を要求する以外のＨＴＴＰリクエストを含むＩＰパケットである。このようなＩＰパケットはメインＣＰＵ１１１に渡される。
それによって、メインＣＰＵ１１１は図１１におけるステップＳ２９で、ＨＴＴＰリクエストにより要求された処理として、図４におけるロジック部１５３等の機能に相当する処理を実行し、その実行結果を含むＨＴＴＰレスポンスをＭＦＰ２００に送信する。
【００６４】
次に、ユーザがＭＦＰ２００のタッチパネル２０５に表示されたＧＵＩ画面上で、他の画面に遷移するボタンを操作した場合を例にとって、図５及び図８に示した処理についてより具体的に説明する。
まず、ＭＦＰ２００のＣＰＵ２０１が、タッチパネル２０５に表示中のＧＵＩ画面のデータ中の、操作されたボタンのデータに対応付けられているＵＲＬを特定する（図５のステップＳ１１）。
【００６５】
この特定したＵＲＬが、例えば「http://www.webserver.com/lcdpanel/lcdpanel1.html」だった場合は、図６に示したＵＲＬテーブルに登録されているＵＲＬである。したがって、ＣＰＵ２０１による図５におけるステップＳ１２の判断で「ＹＥＳ」になる。
それによってＣＰＵ２０１は、上記ＵＲＬで特定されるリソースへのアクセスを要求するＨＴＴＰリクエストを生成し、ＩＰヘッダにフラグを立ててウェブサーバ１００へ送信する（図５のステップＳ１３、Ｓ１４及びＳ１７）。
なお、ＨＴＴＰリクエストにおいて、上記ＵＲＬは、ホスト「www.webserver.com」とパス「/lcdpanel/lcdpanel1.html」に分けて記載される。他の例においても同様である。
【００６６】
一方、図３に示したウェブサーバ１００が、このＨＴＴＰリクエストを含むイーサネットフレームを受信すると、その処理回路１３０がＩＰパケットを解析し、そのＩＰパケットのフラグエリアにフラグが立っていると判断する。そして、処理回路１３０はサブＣＰＵ１２１にそのＩＰパケットを渡す（図８のステップＳ２２、Ｓ２３）。
ＩＰパケットが渡されたサブＣＰＵ１２１は、ＨＴＴＰリクエストで指定されているパスが示す表示画面データ（ここではＨＴＭＬ文書）をＨＤＤ１１４から取得し、その取得した表示画面データを含むＨＴＴＰレスポンスを、ＭＦＰ２００に送信する。
【００６７】
ＭＦＰ２００がそのＨＴＴＰレスポンスを受信すると、そのＭＦＰ２００のＣＰＵ２０１が、図４に示したウェブブラウザ２１０の解析表示部２１３の機能により、受信したＨＴＴＰレスポンスに含まれる表示画面データを解析する。そして、その内容に応じた画面をタッチパネル２０５に表示させる。このことにより、ユーザは遷移先の画面をタッチパネル２０５上で確認して操作できる状態になる。
【００６８】
次に、ユーザがＭＦＰ２００のタッチパネル２０５に表示されたＧＵＩ画面上で、各種アプリケーション１５４に含まれる、例えばＯＣＲ処理アプリケーションの実行を指示するボタンを操作した場合について説明する。
この場合も、まずＭＦＰ２００のＣＰＵ２０１が、表示中のＧＵＩ画面のデータ中で、操作されたボタンのデータに対応付けられているＵＲＬを特定する（図５のステップＳ１１）。その特定したＵＲＬが例えば「http://www.webserver.com/program/ocr.cgi」であった場合は、図６に示したＵＲＬテーブルに登録されていないＵＲＬであるから、図５のステップＳ１２で「ＮＯ」になる。
【００６９】
そこで、ＭＦＰ２００のＣＰＵ２０１は、上記ＵＲＬで特定されるリソースへのアクセスを要求するＨＴＴＰリクエストを送信するためのパケットを生成し、ＩＰヘッダにフラグを立てずにウェブサーバ１００へ送信する（図５のステップＳ１５、１６及びＳ１７）。
それを受信したウェブサーバ１００の処理回路１３０は、ＩＰパケットの解析においてフラグが立っていないと判断して、メインＣＰＵ１１１にＩＰパケットを渡す（図８のステップＳ２２，S２７）。
【００７０】
そのＩＰパケットが渡されたメインＣＰＵ１１１は、受け取ったＩＰパケットを解析し、ＨＴＴＰリクエストで指定されているパスの「/program/ocr.cgi」が示すプログラムを実行する。そして、必要な表示画面データ等をＨＤＤ１１４から取得する（図８のステップＳ２８、Ｓ２９）。その実行結果を含むＨＴＴＰレスポンスを、ＭＦＰ２００に送信する（ステップＳ３０）。
【００７１】
それを受信したＭＦＰ２００のＣＰＵ２０１は、ウェブブラウザ２１０の解析表示部２１３の機能により、受信したＨＴＴＰレスポンスに含まれる表示画面データを解析して、その内容に応じた画面をタッチパネル２０５に表示させる。これにより、ＭＦＰ２００に要求したＯＣＲ等の処理の実行結果をタッチパネル２０５上で確認することができる。
この場合は、ＯＣＲ処理の実行結果が表示されるまでに多少時間がかかっても、ユーザが故障などの不安を持ったり、待つことによるストレスを生じることは殆どない。
【００７２】
以上、図５乃至図８を参照しながら説明した処理によれば、ＭＦＰ２００は、ＨＴＴＰリクエストを送信する場合に、そのアクセス対象のアドレスがＵＲＬテーブルに登録されているか否かを判断する。その結果、登録されていれば、ＨＴＴＰリクエストを送信するためのパケット（ＩＰパケット）にフラグを立てて送信する。
そして、ウェブサーバ１００は、受信したＩＰパケットにフラグが立っていればサブＣＰＵ１２１に、立っていなければメインＣＰＵ１１１に、それぞれそのＩＰパケットを渡して処理させる。
【００７３】
このことは、システムの管理者（又はユーザ）から見れば、ウェブサーバ１００に対する要求のうち、ＵＲＬテーブルに登録しておいたＵＲＬに係る要求はサブＣＰＵ１２１で、それ以外の要求はメインＣＰＵ１１１で処理させることができるといえる。
従って、多数の要求がウェブサーバ１００に殺到し、メインＣＰＵ１１１の処理リソースがその処理に取られてしまうような状態であっても、ＵＲＬテーブルに登録しておいたＵＲＬに係る要求は、サブＣＰＵ１２１により安定して迅速に処理することができる。
【００７４】
このため、ユーザが安定して速い処理結果を得ることを期待するような一部の要求に係るＵＲＬを、予めＵＲＬテーブルに登録しておく。そうすれば、その要求については、ウェブサーバ１００に対して他の要求が殺到している場合でも、安定して迅速に処理結果を得ることができる。
【００７５】
したがって、ＵＲＬテーブルに、例えば表示画面データのＵＲＬを全て登録しておくことにより、多数の装置からウェブサーバ１００に要求が集中しているような場合でも、ＭＦＰ２００において画面表示だけは素早く変更することができる。これにより、ウェブサーバ１００へのアクセスが集中した場合でも、ユーザビリティが低下してしまうのを防ぐことができる。
【００７６】
特に、ウェブサーバ１００に対するＭＦＰの接続台数が多くなるほど、ウェブサーバ１００の処理負荷が増加するため、この実施形態に係る発明の効果は大きくなる。なお、この実施形態では、ＵＲＬテーブルに表示画面データのＵＲＬを登録するようにしたが、別のＵＲＬを登録して、サブＣＰＵ１２１に別の処理を担当させてもよいことは勿論である。
【００７７】
また、この実施形態においては、ＨＴＴＰリクエストを送信するためのＩＰパケットのＩＰヘッダにフラグを立てるようにしている。このことにより、処理回路１３０は、ＯＳＩ参照モデルの第３層であるネットワーク層のＩＰヘッダに設けられたフラグエリアを参照するだけで、フラグが立っているか否かを判断することができる。
従って、フラグの確認に上位層のプロトコル（例えば第７層のＨＴＴＰに係るＨＴＴＰリクエスト）に係る処理は不要であり、最低限の処理でフラグを確認できる。そのため、ウェブサーバ１００で受信した要求を、複数のＣＰＵに分配する処理の負荷を低く抑えることができる。
【００７８】
しかし、ＴＣＰパケット等のより上位のプロトコルに係るデータにフラグを設けることも、妨げられない。
なお、イーサネットフレームのヘッダにフラグを立てることも考えられる。しかし、イーサネットフレームのヘッダは、複数のネットワークをまたいでＩＰパケットが伝送される場合、ルータにおいて付け直されてしまう。従って、ＨＴＴＰリクエストの送信先までフラグを届けるためには、ルータにフラグ管理機能を設ける必要が生じてしまう。そのため、このような対応が不要なＩＰヘッダにフラグを立てるのがより好ましいといえる。
【００７９】
また、メインＣＰＵ１１１及びサブＣＰＵ１２１にＩＰパケットが供給される前に、メインＣＰＵ１１１及びサブＣＰＵ１２１の何れとも異なる処理回路１３０によって、ＩＰパケットを振り分けるようにしている。
従って、例えばメインＣＰＵ１１１のリソースが、受信した要求に係る処理の実行に大幅に割かれているような状況でも、それと無関係に、ＩＰパケットの振り分けを安定して行うことができる。そのため、メインＣＰＵ１１１の処理負荷が大きい場合でも、ＩＰパケットの振り分けが滞り、結果としてサブＣＰＵ１２１が担当する処理のレスポンスまで遅延してしまう、といった不具合を避けることができる。
【００８０】
以上でこの実施形態の説明を終了するが、ウェブサーバ１００及びＭＦＰ２００の具体的な構成や処理の内容等が上述の実施形態で説明したものに限られないことは勿論である。
例えば、図６に示したＵＲＬテーブルに代えて、図９に示すようなＵＲＬテーブルによっても、ＭＦＰ２００のＣＰＵ２０１がＩＰパケットにフラグを立てるか否かを判断することができる。
図６に示したＵＲＬテーブルでは、サブＣＰＵ１２１に処理を担当させる要求に係るＵＲＬを登録するようにした。これに対して、図９に示すＵＲＬテーブルでは、ＭＦＰ２００からウェブサーバ１００へ要求を送信する際のアクセス先として考えられるＵＲＬを全て登録するようにしている。
【００８１】
そして、クライアントサーバシステムの管理者等は、サブＣＰＵ１２１に処理をさせたい要求に係るＵＲＬについてはフラグを「１」に設定し、メインＣＰＵ１１１で処理をさせたい要求に係るＵＲＬについてはフラグを「０」に設定する。あわせて、ＵＲＬと対応する処理内容も入力することができる。
そして、ＭＦＰ２００のＣＰＵ２０１は、図５のステップＳ１２の処理において、図９のＵＲＬテーブルを参照して、特定したＵＲＬに対応付けられているフラグが「１」か「０」かを判断する。そして、ＣＰＵ２０１はその判断に応じて、ＩＰヘッダのフラグエリアにフラグを立てるか立てないかを決定する。
このようにしても、上述した実施形態の場合と同様な効果を得ることができる。
【００８２】
〔他の実施形態〕
次に、この発明の他の実施形態について説明する。
この発明においてサーバ装置として使用するウェブサーバ１００は、メインＣＰＵ１１１と共に動作するメイン制御部１１０に加えて、サブＣＰＵ１２１と共に動作するサブ制御部１２０を備えているため、ハードウェアの消費電力が余分に必要になる。
そこで、この実施形態では、ウェブサーバにおけるメイン制御部１１０とサブ制御部１２０への電源供給を最適に制御して、消費電力を低減しながら、システムパフォーマンスを低下させないようにして、ユーザビリティ（使いやすさ）を損なわないようにする。
【００８３】
そのクライアントサーバシステムとしての構成、及びクライアント装置であるＭＦＰ２００の構成及びその機能は、前述した実施形態と同様である。
この実施形態において、前述した実施形態と相違するのは、サーバ装置であるウェブサーバに、その構成及びその機能を一部追加しただけである。したがって、主にその相違点について以下に説明する。
【００８４】
図１０は、そのウェブサーバのハードウェア構成を示すブロック図である。
このウェブサーバ１００′には、処理回路１３０によって制御される電源管理部１６０と、その電源管理部によって制御されるメイン制御部電源制御部１６１及びサブ制御部電源制御部１６２が設けられている。
メイン制御部電源制御部１６１は、メイン制御部１１０への電源供給を制御し、サブ制御部電源制御部１６２は、サブ制御部１２０への電源供給を制御する。
【００８５】
メイン制御部１１０は、第１のＣＰＵであるメインＣＰＵ１１１と共に動作する第１の制御部であり、図示のＲＯＭ１１２、ＲＡＭ１１３、およびＨＤＤ１１４を含むとともに、メインＣＰＵ１１１が使用する図示していない各種のデバイスも含んでいる。
サブ制御部１２０は、第２のＣＰＵであるサブＣＰＵ１２１と共に動作する第２の制御部であり、図示のＲＯＭ１１２及びＲＡＭ１１を含むとともに、サブＣＰＵ１２１が使用する図示していない各種のデバイスも含んでいる。また、メイン制御部１１０のＨＤＤ１１４は、サブＣＰＵ１２１も使用するので第２の制御部にも含まれることになる。
サブ制御部１２０に、必要な表示画面データ等を記憶する専用のＨＤＤ等の不揮発性メモリを設けた場合は、ＨＤＤ１１４はメイン制御部１１０の専用になる。
【００８６】
このウェブサーバ１００′の処理回路１３０も、前述した実施形態と同様に、識別子付加判断手段の機能と振り分け手段の機能を有している。そのため、ネットワークＩ／Ｆ１４０がネットワーク３００を介して、前述したクライアント装置であるＭＦＰ２００からパケットを受信すると、処理回路１３０がそのパケットに識別子が付加されているか否かを判断する。フラグエリアにフラグが立っているのは、例えば表示画面データの取得を要求するＨＴＴＰリクエストを含むＩＰパケットである。
【００８７】
この処理回路１３０の識別子付加判断手段の機能による判断結果によって、受信したパケットをメインＣＰＵ１１１とサブＣＰＵ１２１のどちらに渡して処理させるかを決定するので、電源供給が必要な制御部も決まることになる。
そこで、この処理回路１３０による識別子付加の判断結果に応じて、メイン制御部１１０とサブ制御部１２０への電源供給を制御する電源制御手段として、電源管理部１６０とメイン制御部電源制御部１６１及びサブ制御部電源制御部１６２を設けている。
【００８８】
その電源制御手段によって、例えば、常時はメイン制御部１１０とサブ制御部１２０への電源供給をパワーセーブモードにしてセーブしておく。そして、ウェブサーバ１００′がパケットを受信した際に、その電源制御手段は、処理回路１３０による識別子付加の判断結果に応じて、振り分け機能によってそのパケットを渡す方のＣＰＵと共に動作する制御部に正規の電源を供給する。その制御部には、少なくともＣＰＵにパケットを渡す直前からそのパケットに関する処理が完了するまでの間は、正規の電源を供給するように制御する。
【００８９】
したがって、処理回路１３０が、受信したパケットに識別子付加されていると判断したときには、サブＣＰＵ１２１にそのパケットを渡すので、電源制御手段はサブ制御部１２０に正規の電源を供給する。処理回路１３０が、受信したパケットに識別子付加されていないと判断したときには、メインＣＰＵ１１１にそのパケットを渡すので、電源制御手段はメイン制御部１１０に正規の電源を供給する。
【００９０】
それによって、電源制御手段は、メイン制御部１１０及びサブ制御部１２０がパケットで指定された処理を実行するのに必要な期間だけ正規の電源を供給し、それ以外のときには電源供給をパワーセーブモードにしておく。パワーセーブモードでは、メイン制御部１１０及び／又はサブ制御部１２０がすぐに立ち上がれるようにするために必要な最低限の電力だけを供給にしておく。しかし、メイン制御部１１０及び／又はサブ制御部１２０がすぐに立ち上がれる状態であれば、常時は電源供給をオフにしておいてもよい。
また、メイン制御部１１０及び／又は１２０に正規の電源を供給するときには、その各制御部が正常に動作するために必要な電圧、電流及び電力を供給する。
【００９１】
そこで、この図１０に示すウェブサーバ１００′のネットワークＩ／Ｆ１４０が、ＭＦＰ２００からのイーサネットフレームを受信したときの処理について、図１１を参照して説明する。
図１１は、ネットワークＩ／Ｆ１４０がイーサネットフレームを受信したときに、ウェブサーバ１００′の処理回路１３０とメインＣＰＵ１１１及びサブＣＰＵ１２１が、それぞれ連係して実行する処理を示す、図８と同様なフローチャートである。そのため、図８のフローチャートの各ステップと同じ処理を行うステップには同じ符号を付してあり、それらのステップの説明は簡単にするか省略する。なお、図中の破線は処理の実行主体の区別を示している。
【００９２】
イーサネットフレームは、図７によって説明したように、イーサネットヘッダとそれに続くＩＰパケットを配置したデータフィールドからなり、その先頭にはフラグエリアを有するＩＰヘッダがある。
また、電源制御手段である電源管理部１６０とメイン制御部電源制御部１６１及びサブ制御部電源制御部１６２は、常時はメイン制御部１１０とサブ制御部１２０への電源供給をパワーセーブモード（又はＯＦＦ）にしてセーブしているものとする。
【００９３】
ウェブサーバ１００′のネットワークＩ／Ｆ１４０がイーサネットフレームを受信すると、まず処理回路１３０が、内蔵のＣＰＵによって図１１に示す処理を開始する。
処理回路１３０はステップＳ２１で、受信したイーサネットフレームを解析し、そのデータフィールドからＩＰパケットを取り出す。これによって、ウェブサーバ１００はＩＰパケットを受信したことを認識できる。
【００９４】
次に、処理回路１３０はステップＳ２２で、取り出したＩＰパケットのＩＰヘッダを参照し、図７に説明したフラグエリアにフラグが立っているか否かを判断する。この処理が、受信したパケットに識別子が付加されているか否かを判断する識別子付加判断手段の機能及び識別子付加判断手順に相当する。
そして、処理回路１３０がステップＳ２２で、フラグが立っている（識別子が付加されている）と判断した場合は、ステップＳ２３に進んでサブＣＰＵ１２１にＩＰパケットを渡すが、その前にステップＳ３１でサブ制御部１２０の電源復帰処理を行う。
【００９５】
また、処理回路１３０がステップＳ２２で、フラグが立っていない（識別子が付加されていない）と判断した場合は、ステップＳ２７に進んでメインＣＰＵ１１１にＩＰパケットを渡すが、その前にステップＳ３２でメイン制御部１１０の電源復帰処理を行う。
この処理が、図４における振分部１３１の機能、および識別子付加判断結果に応じて、第１の制御部であるメイン制御部１１０と、第２の制御部であるサブ制御部１２０への電源供給を制御する電源制御手段の機能及び電源制御手順に相当する。
【００９６】
識別子が付加されていた場合のステップＳ３１の処理では、図１２にその詳細を示すように、まずステップＳ３１１で処理回路１３０が電源管理部１６０にフラグ情報を伝達する。この場合は、フラグが立っている（識別子が付加されている）という情報が電源管理部１６０に伝達される。
それによって、ステップＳ３１２で電源管理部１６０がサブ制御部電源制御部１６２に電源復帰指示を行う。すると、ステップＳ３１３でサブ制御部電源制御部１６２が、サブ制御部１２０の電源をパワーセーブモードから復帰させ、サブ制御部１２０のハードウエアに正規の電源を供給させる。このとき、正規の電源が供給されるサブ制御部には、サブＣＰＵ１２１がメインＣＰＵ１１１と兼用するＨＤＤ１１４も含まれる。
【００９７】
サブ制御部１２０に正規の電源が供給されると、サブＣＰＵ１２１がサブ制御部１２０の初期化を行うので、処理回路１３０はステップＳ３１４で、サブ制御部１２０の初期化が完了するのを待って、図１１のルーチンにリターンする。そして、処理回路１３０はステップＳ２３で、サブＣＰＵ１２１にＩＰパケットを渡す。
【００９８】
ＩＰパケットを受け取ったサブＣＰＵ１２１によるステップＳ２４からＳ２６の処理は、前述の実施形態の図８によって説明した処理と同じであるから、説明を省略する。
このとき、サブＣＰＵ１２１は、図１０に示したサブ制御部１２０のＲＯＭ１２２、ＲＡＭ１２３等と、メイン制御部１１０のＨＤＤ１１４も使用するが、これらには正規の電源が供給されている。
そして、サブＣＰＵ１２１がステップＳ２６で、要求された処理結果をＨＴＴＰレスポンスとしてＨＴＴＰリクエストの送信元のＭＦＰ２００へ送信した後、処理回路１３０がステップＳ３３の処理を実行してから、ウェブサーバ１００′はこの処理を終了する。
【００９９】
処理回路１３０はステップＳ３３で、タイムアウト後にサブ制御部１２０（ＨＤＤ１１４も含む）の電源をパワーセーブモード（またはＯＦＦ）にする。この処理は、例えば処理回路１３０が、サブＣＰＵ１２１によるＨＴＴＰレスポンスの送信が完了したことを、電源管理部１６０を通してサブ制御部電源制御部１６２に伝達する。すると、サブ制御部電源制御部１６２がタイマ機能を起動して、一定時間経過後にサブ制御部１２０のハードウエアの電源をパワーセーブモード（またはＯＦＦ）に移行する。
サブ制御部電源制御部１６２のタイマ機能によるタイムアウト時間は、固定でもよいし、自由に設定できるようにしてもよい。
【０１００】
一方、識別子が付加されていなかった場合のステップＳ３２の処理では、図１３にその詳細を示すように、まずステップＳ３２１で処理回路１３０が電源管理部１６０にフラグ情報を伝達する。この場合は、フラグが立っていない（識別子が付加されていない）という情報が電源管理部１６０に伝達される。
それによって、ステップＳ３２２で電源管理部１６０がメイン制御部電源制御部１６１に電源復帰指示を行う。すると、ステップＳ３２３でメイン制御部電源制御部１６１が、メイン制御部１１０の電源をパワーセーブモードから復帰させ、メイン制御部１１０のハードウエアに正規の電源を供給させる。このときはサブＣＰＵ１２１と兼用するＨＤＤ１１４にも当然、正規の電源が供給される。
【０１０１】
メイン制御部１１０に正規の電源が供給されると、メインＣＰＵ１１１がメイン制御部１１０の初期化を行うので、処理回路１３０はステップＳ３２４で、メイン制御部１１０の初期化が完了するのを待って、図１１のルーチンにリターンする。そして、処理回路１３０はステップＳ２７で、メインＣＰＵ１１１にＩＰパケットを渡す。
【０１０２】
ＩＰパケットを受け取ったメインＣＰＵ１１１によるステップＳ２８からＳ３０の処理は、前述の実施形態の図８によって説明した処理と同じであるから、説明を省略する。
このとき、メインＣＰＵ１１１は、図１０に示したメイン制御部１１０のＲＯＭ１１２、ＲＡＭ１１３、およびＨＤＤ１１４等を使用するが、これらには正規の電源が供給されている。
そして、メインＣＰＵ１１１がステップＳ３０で、要求された処理結果をＨＴＴＰレスポンスとしてＨＴＴＰリクエストの送信元のＭＦＰ２０へ送信した後、処理回路１３０がステップＳ３４の処理を実行してから、ウェブサーバ１００′はこの処理を終了する。
【０１０３】
処理回路１３０はステップＳ３４で、タイムアウト後にメイン制御部１１０の電源をパワーセーブモード（またはＯＦＦ）にする。この処理は、例えば処理回路１３０が、メインＣＰＵ１１１によるＨＴＴＰレスポンスの送信が完了したことを、電源管理部１６０を通してメイン制御部電源制御部１６１に伝達する。すると、メイン制御部電源制御部１６１がタイマ機能を起動して、一定時間経過後にメイン制御部１１０のハードウエアの電源をパワーセーブモード（またはＯＦＦ）に移行する。
メイン制御部電源制御部１６１のタイマ機能によるタイムアウト時間も、固定でもよいし、自由に設定できるようにしてもよい。
【０１０４】
ところで、電源制御手段である電源管理部１６０とメイン制御部電源制御部１６１及びサブ制御部電源制御部１６２は、第２の制御部であるサブ制御部１２０には常時正規の電源を供給するようにしてもよい。その場合、第１の制御部であるメイン制御部１１０には常時は電源供給をセーブしておき、処理回路１３０がメインＣＰＵ１１１にパケットを渡す際に、少なくともその直前から該パケットに関する処理が完了するまでの間は、正規の電源を供給するように制御する。
【０１０５】
その場合、ウェブサーバ１００′による図１１のフローチャートに相当する処理は、図１４に示すフローチャートのようになる。この場合は、サブ制御部１２０には常時正規の電源を供給しているので、図１１におけるステップＳ３１とステップＳ３３の処理は不要になるので無くなる。
したがって、ステップＳ２２で処理回路１３０がフラグエリアにフラグが立っている（識別子が付加されている）と判断した場合の以後の処理は、前述したウェブサーバ１００による図８のフローチャートの処理と同じである。
【０１０６】
ステップＳ２２で処理回路１３０がフラグエリアにフラグが立っていない（識別子が付加されていない）と判断した場合の以後の処理は、上述した図１１及び図１３のフローチャートで説明した処理と同じである。
このようにすれば、消費電力の節減効果は幾分少なくなるが、ＭＦＰ２００から表示画面データの取得を要求された場合のような、サブ制御部１２０で担当する処理を迅速に行うことができ、ユーザビリティが低下しない。
したがって、例えばＭＦＰの画面更新をスムーズに実施できるうえに、システムとして省電力を達成できる。
【０１０７】
この実施形態では上述のように、ウェブサーバが受信したパケットに識別子が付加されているか否かの判断結果に応じて、メイン制御部とサブ制御部への電源供給を制御する。それによって、使用していない制御部の電源をセーブ又はオフする等の省電力モードへ移行させることによって、省電力化を図ることができる。
【０１０８】
また、識別子が付加されているパケットを処理するサブ制御部には、常時正規の電源を供給しておくようにすれば、操作画面のイメージ転送時等の迅速な処理が要求される場合には、省電力モードからの復帰時間を省けるので、レスポンスの低下を防止できる。
したがって、ユーザビリティと環境負荷低減の両立が可能になり、ユーザに対して大きなメリットを与えることができる。
【０１０９】
以上、この発明の各実施形態について説明したが、さらに種々の変更が可能である。
上述した各実施形態においては、ＭＦＰ２００からのアクセス先は、ウェブサーバ１００又は１００′しか示していないが、複数のサーバ装置にアクセスすることができるようにしても構わない。そのうち一部のサーバ装置だけが、上述したウェブサーバ１００と同様なパケットの振り分け機能を有していても、全ての装置が振り分け機能を有していてもよい。その場合に、振り分け機能のないサーバ装置に対して、フラグを立てたパケットを送信しても特に問題はない。受信側において単にそのフラグが読み捨てられるだけだからである。
【０１１０】
また、上述した実施形態の図５の処理においては、ＣＰＵ２０１はステップＳ１２の前に、ＨＴＴＰリクエストの送信先装置を特定する処理は行っていない。しかし、ＣＰＵ２０１がステップＳ１２の前に、ＨＴＴＰリクエストの送信先装置を特定し、ＩＰパケット振り分け機能を備えたサーバ装置が送信先である場合のみ、ＵＲＬテーブルを参照してフラグ立ての要否を判断するようにしてもよい。それ以外の場合は、フラグを立てても意味がないため、ＣＰＵ２０１は常にフラグは立てない（Ｓ１５に進む）と判断すればよい。  このようにすれば、ＵＲＬテーブルが大きい場合には特に、ＵＲＬテーブルの検索による処理負荷を低減することができる。
また、上述した実施形態においては、アクセス要求に係る通信プロトコルとしてＨＴＴＰを用いたが、ＨＴＴＰ以外の他の通信プロトコルを用いてもよい。
【０１１１】
さらに、上述した実施形態においては、クライアントサーバシステムのウェブサーバ１００又は１００′と各ＭＦＰ２００とがいずれもネットワーク３００を介して接続され、物理的に別々となっていた。しかし、ウェブサーバ１００又は１００′を特定のＭＦＰ２００と物理的に一体化させる構成も考えられる。
【０１１２】
なおまた、上述した実施形態においては、クライアント装置としてＭＦＰ２００を例にとって説明した。しかし、ＭＦＰ２００のウェブブラウザ２１０とパケット生成送信部２２０の機能を備え、かつその機能を発揮するためのハードウェアを備えた他の種類の画像形成装置、あるいはパーソナルコンピュータ（ＰＣ）等の情報処理装置を使用してもよい。その他、上記機能とウェブクライアント機能を備えた装置であれば、いかなる装置でもクライアント装置として使用可能である。
【０１１３】
また、この発明によるクライアントサーバシステムの制御方法は、前述したクライアントサーバシステムの実施形態において、各フローチャートによって説明したような各手順を実行することによって実施できる。
さらに、この発明によるプログラムは、コンピュータを、前述したＭＦＰ２００のようなクライアント装置、および前述したウェブサーバ１００又は１００′のようなサーバ装置として機能させるためのプログラムである。
【０１１４】
このようなプログラムは、はじめからコンピュータに備えるＲＯＭあるいはＨＤＤ等の記憶手段に格納しておいてもよい。あるいは、記録媒体であるＣＤ−ＲＯＭ又はフレキシブルディスク、ＳＲＡＭ、ＥＥＰＲＯＭ、メモリカード等の不揮発性記録媒体（メモリ）に記録して提供することもできる。
そのメモリに記録されたプログラムをコンピュータにインストールしてＣＰＵに実行させるか、ＣＰＵにそのメモリからこのプログラムを読み出して実行させることにより、サーバ装置又はクライアント装置の各機能を実現することができる。
【符号の説明】
【０１１５】
１００，１００′：ウェブサーバ（サーバ装置）    
１１０：メイン制御部（第１の制御部）    １１１：メインＣＰＵ（第１のＣＰＵ）  
１１２：ＲＯＭ      １１３：ＲＡＭ    １１４：ＨＤＤ    
１２０：サブ制御部（第２の制御部）    １２１：サブＣＰＵ（第２のＣＰＵ）    
１２２：ＲＯＭ      １２３：ＲＡＭ    １３０：処理回路    
１３１：振分部（識別子付加判断手段、振り分け手段）    
１４０：ネットワークＩ／Ｆ    １５０：ウェブアプリケーション    
１５１：画面データ記憶部    １５２：表示サービス部      １５３：ロジック部
１５４：各種アプリケーション    １６０：電源管理部    
１６１：メイン制御部電源制御部    １６２：サブ制御部電源制御部
【０１１６】
２００：ＭＦＰ（クライアント装置）
２０１：ＣＰＵ    ２０２：ＲＯＭ    ２０３：ＲＡＭ    ２０４：ＨＤＤ
２０５：タッチパネル    ２０６：エンジン部Ｉ／Ｆ    ２０７：エンジン部
２０８：ネットワークＩ／Ｆ    ２１０：ウェブブラウザ
２１１：アクセス要求生成部    ２１２：識別子要否判断部    ２１３：解析表示部
２２０：パケット生成送信部    ２３０：サービスプロバイダ
２３１：ジョブ生成部    ２３２：ジョブ実行部      ２４０：スキャナ処理部
２５０：プリント処理部      ２６０：ＦＡＸ処理部    
３００：ネットワーク
【先行技術文献】
【特許文献】
【０１１７】
【特許文献１】特開２０１１−６５５９３号公報
【図１】
2013225292.tif 000003
【図２】
2013225292.tif 000004
【図３】
2013225292.tif 000005
【図４】
2013225292.tif 000006
【図５】
2013225292.tif 000007
【図６】
2013225292.tif 000008
【図７】
2013225292.tif 000009
【図８】
2013225292.tif 000010
【図９】
2013225292.tif 000011
【図１０】
2013225292.tif 000012
【図１１】
2013225292.tif 000013
【図１２】
2013225292.tif 000014
【図１３】
2013225292.tif 000015
【図１４】
2013225292.tif 000016