JP2014119960A - クライアントサーバシステム、クライアント装置、サーバ装置、クライアントサーバシステムの制御方法及びプログラム - Google Patents

Abstract

【課題】クライアント装置からサーバ装置へのアクセスが集中した場合でも、ユーザビリティが低下しないようにする。
【解決手段】サーバ装置であるウェブサーバ１００が、ネットワーク３００を介してＭＦＰ等のクライアント装置からパケットを受信したとき、処理回路１３０がそれに識別子が付加されているか否かを判断し、そのパケットを識別子が付加されていればサブＣＰＵ１２１に、付加されていなければメインＣＰＵ１１１に振り分けて渡す。また、ウェブサーバ１００にアクセス可能な複数のクライアント装置からそれぞれ要求されることが予測されるデータを全てＨＤＤ１１４に格納しておく。そして、通信不可能な動作状態のクライアント装置から要求されることが予測されるデータを、そのＨＤＤ１１４から読み出し速度が速いＲＡＭ１１３に予めキャッシュしておく。
【選択図】 図３

Description

この発明は、ネットワークを介してアクセス可能なクライアント装置とサーバ装置とを備えたクライアントサーバシステムと、そのクライアント装置とサーバ装置、クライアントサーバシステムの制御方法及びプログラムに関する。

従来から、プリンタ機能、スキャナ機能及びコピー機能等を有するデジタル複合機であるＭＦＰ（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）及びイーサネット（登録商標）のプロトコルを用いて行う。この場合、ＣＰＵ２０１は、まずＨＴＴＰリクエストをボディとし、これにＴＣＰのヘッダ及びフッタを付加してＴＣＰパケットを作成する。

次に、ＣＰＵ２０１はそのＴＣＰパケットをボディとし、ＩＰのヘッダ及びフッタを付加してＩＰパケットを作成する。さらに、ＣＰＵ２０１は、そのＩＰパケットをデータフィールドに配置し、イーサネットのヘッダ及びフッタを付加してイーサネットフレームを作成し、このイーサネットフレームをネットワークＩ／Ｆ２０８から送信する。
図８におけるステップＳ１４及びＳ１６は、これらのうちＩＰパケットの作成までの処理と対応し、ステップＳ１７はイーサネットフレームの作成及び送信の処理と対応する。

この点について、図１０を参照しながらさらに説明する。
図１０は、ＭＦＰ２００が送信するイーサネットフレームの先頭部を示す図である。
この図１０に示すのは、図８のステップＳ１７でＭＦＰ２００が送信するイーサネットフレームのうち、イーサネットヘッダ及びフレームのデータフィールドに配置したＩＰパケットの一部である。

宛先ＭＡＣアドレスと送信元ＭＡＣアドレスとタイプとがイーサネットヘッダであり、それに続く部分がＩＰパケットを配置したデータフィールドである。その先頭にはＩＰヘッダがある。
ＩＰヘッダには、ＩＰパケットの宛先ＩＰアドレスと送信元ＩＰアドレスが含まれるが、それ以外に未使用領域がある。この実施形態では、この未使用領域に１ビットのフラグエリアを設けている。

図８のステップＳ１４でフラグを立てたり、ステップＳ１６でフラグを立てなかったりするのは、このフラグエリアに設けたフラグに関してである。
この実施形態において、ＣＰＵ２０１がＩＰヘッダのフラグエリアを「１」にすることが、ステップＳ１４におけるＩＰヘッダにフラグを立てることであり、ＩＰヘッダにフラグを立てることが識別子を付加することに相当する。
ＩＰヘッダには、送信元のＭＦＰ２００のＩＰアドレスである送信元ＩＰアドレスと、宛先であるウェブサーバ１００のＩＰアドレスである宛先ＩＰアドレスとが含まれる。

次に、ウェブサーバ１００の図３に示したネットワークＩ／Ｆ１４０がイーサネットフレームを受信したときの処理について、図１１を参照しながら説明する。
図１１は、ネットワークＩ／Ｆ１４０がイーサネットフレームを受信したときに、ウェブサーバ１００の処理回路１３０とメインＣＰＵ１１１及びサブＣＰＵ１２１が、それぞれ連係して実行する処理のフローチャートである。なお、図中の破線は処理の実行主体の区別を示している。

サーバ装置であるウェブサーバ１００において、ネットワークＩ／Ｆ１４０がイーサネットフレームを受信すると、まず処理回路１３０が、内蔵のＣＰＵによって図１１に示す処理を開始する。
なお、以下の説明では、受信したイーサネットフレームのデータフィールドには、ＩＰパケットが記載されているものとする。
処理回路１３０は、まずステップＳ２１で受信したイーサネットフレームを解析し、そのデータフィールドからＩＰパケットを取り出す。これによって、ウェブサーバ１００はＩＰパケットを受信したことを認識できる。

次に、処理回路１３０はステップＳ２２で、取り出したＩＰパケットのＩＰヘッダを参照し、図１０で説明したフラグエリアにフラグが立っているか否かを判断する。この処理が、受信したパケットに識別子が付加されているか否かを判断する識別子付加判断手順に相当する。
そして、ステップＳ２２でフラグが立っている（識別子が付加されている）と判断した場合は、ステップＳ２３に進んでサブＣＰＵ１２１にＩＰパケットを渡す。ステップＳ２２でフラグが立っていない（識別子が付加されていない）と判断した場合は、ステップＳ２７に進んでメインＣＰＵ１１１にＩＰパケットを渡す。
この処理が、図４における振り分け部１３１の機能、およびこの発明によるクライアントサーバシステムの制御方法における振り分け手順に相当する。

サブＣＰＵ１２１がＩＰパケットを受け取ると、サブＣＰＵ１２１はステップＳ２４でその受け取ったＩＰパケットを解析し、そのボディ部に含まれるＴＣＰパケットに含まれるＨＴＴＰリクエストを取得する。
そして、ステップＳ２５でそのＨＴＴＰリクエストにより要求された処理を実行し、ステップＳ２６でその処理結果をＨＴＴＰレスポンスとしてＨＴＴＰリクエストの送信元へ送信して、処理を終了する。

一方、メインＣＰＵ１１１がＩＰパケットを受け取ると、メインＣＰＵ１１１はステップＳ２８乃至Ｓ３０で、上述したサブＣＰＵ１２１による処理と同様の処理を行う。
すなわち、受け取ったＩＰパケットを解析し、そのボディ部に含まれるＴＣＰパケットに含まれるＨＴＴＰリクエストを取得する（Ｓ２８）。そして、そのＨＴＴＰリクエストにより要求された処理を実行し（Ｓ２９）、その処理結果をＨＴＴＰレスポンスとしてＨＴＴＰリクエストの送信元へ送信して（Ｓ３０）、処理を終了する。

ところで、前述したようにこの実施形態においては、図２のタッチパネル２０５に表示させる画面データを取得する際のアクセス先ＵＲＬを、全て図９に示したＵＲＬテーブルに登録してある。したがって、図８のフローチャート及び図９のＵＲＬテーブルによれば、ＩＰパケットのフラグエリアにフラグが立っているのは、画面データの取得を要求するＨＴＴＰリクエストを含むＩＰパケットとなる。

そして、そのフラグエリアにフラグが立っているＩＰパケットは、サブＣＰＵ１２１に渡される。それによって、サブＣＰＵ１２１は図１１におけるステップＳ２５で、ＨＴＴＰリクエストにより要求された処理として、ＨＴＴＰリクエストで指定されているＵＲＬが示す画面データを図３のＲＡＭ１１3から取得する。これが、図４における表示サービス部１５２の機能に相当する。
その後、ステップＳ２６で、その取得した画面データを含むＨＴＴＰレスポンスをＭＦＰ２００に送信する。

一方、フラグエリアにフラグが立っていないＩＰパケットは、画面データの取得を要求する以外のＨＴＴＰリクエストを含むＩＰパケットである。このようなＩＰパケットはメインＣＰＵ１１１に渡される。
それによって、メインＣＰＵ１１１は図１１におけるステップＳ２９で、ＨＴＴＰリクエストにより要求された処理として、図４におけるがロジック部１５３等の機能に相当する処理を実行し、その実行結果を含むＨＴＴＰレスポンスをＭＦＰ２００に送信する。

次に、図１２によって図１１における処理回路１３０によるステップＳ２３の処理の詳細を説明する。
図３に示した処理回路１３０は、図１１におけるステップＳ２３で図１２に示す処理を実行する。
まず、ステップＳ２３１でＭＦＰ２００から受信したパケットからＩＰパケットを抽出し、そのＩＰパケットからＭＦＰのＩＰアドレスを取得する。
処理回路１３０は次いで、ステップＳ２３２でＭＦＰのＩＰアドレスから対象ＭＦＰを識別する。さらに、ステップＳ２３３でクライアント管理テーブルを参照し、対象ＭＦＰに対応するデータ保管先アドレスを参照する。

そして、ステップＳ２３４で画面データはＲＡＭ１１３にあるか否かを判断する。クライアント管理テーブル１７１は図５に示した構成になっているので、対象ＭＦＰに対応するデータ保管先アドレスにアドレスが保管されていれば、ＲＡＭ１１３のそのアドレスの領域に画面データが保管されていると判断できる。また、対象ＭＦＰに対応するデータ保管先アドレスにアドレスが保管されていなければ、画面データはＲＡＭ１１３にはなく、ＨＤＤ１１４に保管されていると判断できる。
なお、図７によって前述したように、ウェブサーバ１００と通信可能な状態にあるＭＦＰ２００に要求されることが予測される画面データは、殆どＲＡＭ１１３に保持されている。

そこで処理回路１３０は、ステップＳ２３４で画面データがＲＡＭ１１３にあるか否かを判断するが、殆どの場合はあると判断してステップＳ２３５へ進む。そして、サブＣＰＵ１２１へＩＰパケットを渡すと共に、ＲＡＭ１１３へのアクセス指示を送ってこの処理を終了する。
しかし、処理回路１３０がステップＳ２３４で、画面データがＲＡＭ１１３にないと判断した場合は、ステップＳ２３６へ進んでサブＣＰＵ１２１へＩＰパケットを渡すだけで、この処理を終了する。

それによって、処理回路１３０からＩＰパケットを受け取ったサブＣＰＵ１２１は、図１１におけるステップＳ２５の処理に際して、処理回路１３０からＲＡＭ１１３へのアクセス指示があったか否かを判断する。
そして、ＲＡＭ１１３へのアクセス指示があった場合は、ＨＴＴＰリクエストによって要求された画面データをＲＡＭ１１３から読み出す処理を実行する。
サブＣＰＵ１２１がＲＡＭ１１３から画面データを読み出すときには、その読み出し先のアドレスとして、図１０に示したクライアント管理テーブル１７１の対象ＭＦＰに対応するデータ保管先アドレスを使用する。
サブＣＰＵ１２１がＲＡＭ１１３へのアクセス指示がなかったと判断した場合は、ＨＴＴＰリクエストによって要求された画面データをＨＤＤ１１４から読み出す処理を実行する。

次に、ユーザが図２に示したＭＦＰ２００のタッチパネル２０５に表示されたＧＵＩ画面上で、他の画面に遷移するボタンを操作した場合を例にとって、図８から図１２に示した処理についてより具体的に説明する。
まず、ＭＦＰ２００のＣＰＵ２０１が、タッチパネル２０５に表示中のＧＵＩ画面のデータ中で、操作されたボタンのデータに対応付けられているＵＲＬを特定する（図８のステップＳ１１）。
この特定したＵＲＬが例えば「http://www.webserver.com/lcdpanel/lcdpanel1.html」だった場合は、図９に示したＵＲＬテーブルに登録されているＵＲＬであるので、図８のステップＳ１２でＹＥＳになる。

それによってＣＰＵ２０１は、上記ＵＲＬで特定されるリソースへのアクセスを要求するＨＴＴＰリクエストを送信するためのパケットを生成し、ＩＰヘッダにフラグを立ててウェブサーバ１００へ送信する。（図８のステップＳ１３，Ｓ１４及びＳ１７）。
なお、ＨＴＴＰリクエストにおいて、上記ＵＲＬは、ホスト「www.webserver.com」とパス「/lcdpanel/lcdpanel1.html」に分けて記載される。他の例においても同様である。
一方、図２に示したウェブサーバ１００が、このＨＴＴＰリクエストを含むイーサネットフレームを受信すると、その処理回路１３０はＩＰパケットを解析し、そのＩＰパケットのフラグエリアにフラグが立っていると判断する。そして、サブＣＰＵ１２１にＩＰパケットを渡す（図１１のステップＳ２２，Ｓ２３）。

このとき、処理回路１３０は、図５に示したクライアント管理テーブル１７１の対象ＭＦＰに対応するデータ保管先アドレスを参照する。そして、そこにアドレスが保管されていれば、ＲＡＭ１１３に必要な画面データが保持されているので、サブＣＰＵ１２１にＲＡＭ１１３へのアクセス指示を送る（図１２のステップＳ２３３〜Ｓ２３５）。
サブＣＰＵ１２１にＩＰパケットが渡され、ＲＡＭ１１３へのアクセス指示が送られると、そのサブＣＰＵ１２１は、受け取ったＩＰパケットを解析する。そして、ＨＴＴＰリクエストで指定されているパスが示す画面データ（ここではＨＴＭＬ文書）を、ＲＡＭ１１３から高速に読み出して取得できる（図１１のステップＳ２４，Ｓ２５）。そして、その取得した画面データを含むＨＴＴＰレスポンスをＭＦＰ２００に送信する（ステップＳ２６）。

それを受信したＭＦＰ２００のＣＰＵ２０１は、図４に示したウェブブラウザ２１０の解析表示部２１３の機能により、受信したＨＴＴＰレスポンスに含まれる画面データを解析して、その内容に応じた画面を直ちにタッチパネル２０５に表示させる。
これにより、ユーザは遷移先の画面をタッチパネル２０５上で殆ど待ち時間なく確認して、操作できる状態となる。

次に、ユーザがＭＦＰ２００のタッチパネル２０５に表示されたＧＵＩ画面上で、各種アプリケーション１５４に含まれる例えばＯＣＲ処理アプリケーションの実行を指示するボタンを操作した場合について説明する。
この場合も、まずＭＦＰ２００のＣＰＵ２０１が、表示中のＧＵＩ画面のデータ中で、操作されたボタンのデータに対応付けられているＵＲＬを特定する（図８のステップＳ１１）。その特定したＵＲＬが、例えば「http://www.webserver.com/program/ocr.cgi」だった場合は、図９に示したＵＲＬテーブルに登録されていないＵＲＬであるから、図８のステップＳ１２でＮＯになる。

そこで、ＭＦＰ２００のＣＰＵ２０１は、上記ＵＲＬで特定されるリソースへのアクセスを要求するＨＴＴＰリクエストを送信するためのパケットを生成し、ＩＰヘッダにフラグを立てずにウェブサーバ１００へ送信する。（図８のステップＳ１５，Ｓ１６及びＳＳ１７）。
それを受信したウェブサーバ１００の処理回路１３０は、ＩＰパケットの解析においてフラグが立っていないと判断して、メインＣＰＵ１１１にそのＩＰパケットを渡す（図１１のＳ２２，Ｓ２７）。

ＩＰパケットが渡されたメインＣＰＵ１１１は、受け取ったＩＰパケットを解析し、ＨＴＴＰリクエストで指定されているパスの「/program/ocr.cgi」が示すプログラムを実行する。そして、必要な画面データ等をＨＤＤ１１４から取得する（図１１のステップＳ２８，２９）。その実行結果を含むＨＴＴＰレスポンスを、ＭＦＰ２００に送信する（ステップＳ３０）。

それを受信したＭＦＰ２００のＣＰＵ２０１は、ウェブブラウザ２１０の解析表示部２１３の機能により、受信したＨＴＴＰレスポンスに含まれる画面データを解析して、その内容に応じた画面をタッチパネル２０５に表示させる。これにより、ＭＦＰ２００に要求したＯＣＲの処理の実行結果をタッチパネル２０５上で確認することができる。この場合、ＯＣＲ処理の実行結果が表示されるまでに多少時間がかかっても、ユーザが故障などの不安を持ったり、待つことによるストレスを生じることは殆どない。

以上、図５と図８乃至図１２を参照しながら説明した処理によれば、ＭＦＰ２００は、ＨＴＴＰリクエストを送信する場合に、そのアクセス対象のアドレスがＵＲＬテーブルに登録されているかどうかを判断する。その結果、登録されていればＨＴＴＰリクエストを送信するためのパケット（ＩＰパケット）にフラグを立てて送信する。
そして、ウェブサーバ１００は、受信したＩＰパケットにフラグが立っていればサブＣＰＵ１２１に、立っていなければメインＣＰＵ１１１にそのＩＰパケットを渡して処理させる。

このことは、システムの管理者（又はユーザ）から見れば、ウェブサーバ１００に対する要求のうち、ＵＲＬテーブルに登録しておいたＵＲＬに係る要求はサブＣＰＵ１２１で、それ以外の要求はメインＣＰＵ１１１で処理させることができるといえる。
従って、多数の要求がウェブサーバ１００に殺到し、メインＣＰＵ１１１の処理リソースがその処理に取られてしまっているような状態であっても、ＵＲＬテーブルに登録しておいたＵＲＬに係る要求は、サブＣＰＵ１２１によって常に迅速に処理することができる。

このため、ユーザが常に速い処理結果の確認を期待するような一部の要求に係るＵＲＬを、予めＵＲＬテーブルに登録しておけばよい。そうすれば、ウェブサーバ１００に他の要求が殺到している場合でも、ＵＲＬテーブルに登録されている要求については、常に迅速に処理結果を得ることができる。
したがって、ＵＲＬテーブルに例えば画面データのＵＲＬを全て登録しておくことにより、多数の装置からウェブサーバ１００に要求が集中しているような場合でも、ＭＦＰ２００において画面表示だけは素早く行うことができる。
これにより、ウェブサーバ１００へのアクセスが集中した場合でも、ユーザビリティが低下してしまうのを防ぐことができる。

特に、ウェブサーバ１００に対するＭＦＰの接続台数が多くなるほど、ウェブサーバ１００の処理負荷が増加するため、この実施形態に係る発明の効果は大きくなる。
なお、この実施形態では、ＵＲＬテーブルに画面データのＵＲＬを登録するようにしたが、別のデータのＵＲＬを登録して、サブＣＰＵ１２１に別のデータに関する処理を担当させるようにしてもよいことは勿論である。

また、この実施形態においては、ＨＴＴＰリクエストを送信するためのＩＰパケットのＩＰヘッダにフラグを立てるようにしている。
これによって、ウェブサーバ１００の処理回路１３０は、ＯＳＩ参照モデルの第３層であるネットワーク層のＩＰヘッダに設けられたフラグエリアを参照するだけで、フラグが立っているか否かを判断することができる。

従って、フラグの確認に、上位層のプロトコル（例えば第７層のＨＴＴＰに係るＨＴＴＰリクエスト）に係る処理は不要であり、最低限の処理でフラグの有無を確認できる。
そのため、ウェブサーバ１００において、ＭＦＰ２００から受信したパケットを複数のＣＰＵに分配する処理の負荷を低く抑えることができる。
しかし、ＴＣＰパケット等の、より上位のプロトコルに係るデータにフラグを設けることも妨げられない。

なお、イーサネットフレームのヘッダにフラグを記載することも考えられる。しかし、イーサネットフレームのヘッダは、複数のネットワークをまたいでＩＰパケットが伝送される場合、ルータにおいて付け直されてしまう。
従って、ＨＴＴＰリクエストの送信先までフラグを届けるためには、ルータにフラグ管理機能を設ける必要が生じてしまう。このため、このような対応が不要なＩＰヘッダにフラグエリアを設けるのがより好ましいといえる。

また、上述した実施形態においては、メインＣＰＵ１１１又はサブＣＰＵ１２１にＩＰパケットが供給される前に、メインＣＰＵ１１１及びサブＣＰＵ１２１の何れとも異なる処理回路１３０によって、ＩＰパケットを振り分けるようにしている。
そのため、例えばメインＣＰＵ１１１のリソースが、受信した要求に係る処理の実行に大幅に割かれているような状況でも、それと無関係にＩＰパケットの振り分けは迅速に行うことができる。
従って、メインＣＰＵ１１１の処理負荷が大きい場合に、ＩＰパケットの振り分けが滞り、結果としてサブＣＰＵ１２１が担当する処理のレスポンスまで遅延してしまうような不都合を避けることができる。

以上でこの実施形態の説明を終了するが、ウェブサーバ１００等のサーバ装置及びＭＦＰ２００等のクライアント装置の具体的な構成や処理の内容等は、上述の実施形態で説明したものに限らず、種々の変更や追加あるいは削除等が可能なことは勿論である。
例えば、図９に示したＵＲＬテーブルに代えて図１３に示すようなＵＲＬテーブルによっても、ＭＦＰ２００のＣＰＵ２０１がＩＰパケットにフラグを立てるか否か、すなわち識別子の要否を判断することができる。
図９に示したＵＲＬテーブルでは、サブＣＰＵ１２１に処理を担当させる要求に係るＵＲＬのみを登録するようにした。
しかし、図１３に示すＵＲＬテーブルでは、ＭＦＰ２００からウェブサーバ１００へ要求を送信する際のアクセス先として考えられるＵＲＬを全て登録している。

そして、クライアントサーバシステムの管理者等はサブＣＰＵ１２１に処理を担当させたい要求に係るＵＲＬについてはフラグを「１」に設定し、メインＣＰＵ１１１に処理を担当させたい要求に係るＵＲＬについてはフラグを「０」に設定する。併せて、その各ＵＲＬと対応する処理内容も記録することができる。
ＭＦＰ２００のＣＰＵ２０１は、図８のステップＳ１２の処理において、図１３のＵＲＬテーブルを参照して、特定したＵＲＬに対応付けられているフラグが「１」か「０」かを判断する。
その判断結果に応じて、生成するＩＰパケットにおけるＩＰヘッダのフラグエリアに、フラグを立てるか立てないかを決定することができる。
このようにしても、上述した実施形態の場合と同様な効果を得ることができる。

また、上述した実施形態においては、クライアント装置である各ＭＦＰ２００からのアクセス先のサーバ装置として、１台のウェブサーバ１００しか示していない。
しかし、ネットワークに接続された各クライアント装置から、複数のサーバ装置にアクセスすることができるようにしてもよい。
そのうち一部のクライアント装置が、上述したウェブサーバ１００と同様なパケットの振り分け機能を有していても、全てのクライアント装置が振り分け機能を有していてもよい。その場合に、振り分け機能のないサーバ装置に対して、フラグを立てたパケットを送信してしまっても、特に問題はない。それは、受信したサーバ装置において、単にそのフラグが読み捨てられるだけだからである。

また、クライアント装置における上述した実施形態の図８と同様な処理において、ステップＳ１２に相当する判断の前に、ＨＴＴＰリクエストの送信先のサーバ装置を特定する処理を行ってもよい。そして、前述したウェブサーバ１００のように、ＩＰパケット振り分け機能を備えたサーバ装置が送信先である場合にのみ、ＵＲＬテーブルを参照してフラグを立てることの要否を判断するようにしてもよい。
それ以外の場合は、フラグを立てても意味がないため、常にフラグは立てないと判断すればよい。

このようにすれば、ＵＲＬテーブルが大きい場合には特に、ＵＲＬテーブルの検索による処理負荷を低減することができる。
また、前述した実施形態においては、アクセス要求に係る通信プロトコルとしてＨＴＴＰを用いたが、ＨＴＴＰ以外の他の通信プロトコルを用いてもよい。

さらに、前述した実施形態においては、クライアントサーバシステムを構成するウェブサーバ１００と複数台のＭＦＰ２００とが、ネットワーク３００を介して接続され、物理的に別々な構成になっていた。
しかし、ウェブサーバ１００を特定のＭＦＰ２００あるいは他のクライアント装置と物理的に一体に構成してもよい。

また、前述した実施形態においては、クライアント装置としてＭＦＰ２００を例にとって説明した。
しかし、ＭＦＰ２００のウェブブラウザ２１０とパケット生成送信部２２０の機能を備え、かつその機能を発揮するためのハードウェアを備えた他の種類の画像形成装置、あるいはパーソナルコンピュータ（ＰＣ）等の情報処理装置を使用してもよい。その他、ウェブクライアント機能を備えた装置であれば、いかなる装置でもクライアント装置として使用可能である。

また、この発明によるクライアントサーバシステムの制御方法は、前述したクライアントサーバシステムの実施形態において、各フローチャートによって説明したような各手順を実行することによって実施できる。
さらに、この発明によるプログラムは、コンピュータを、前述したＭＦＰ２００のようなクライアント装置から、ネットワークを介してアクセス可能なサーバ装置として機能させるためのプログラムである。

そして、コンピュータに、例えば前述した図７、図１１及び図１２によって説明した、ウエブサーバ１００における処理回路１３０及びメインＣＰＵ１１１とサブＣＰＵ１２１による各処理手順を実行させるプログラムである。
このようなプログラムは、はじめからコンピュータに備えるＲＯＭあるいはＨＤＤ等の記憶手段（メモリ）に格納しておいてもよい。
また、可搬の記録媒体であるＣＤ−ＲＯＭあるいはフレキシブルディスク、ＳＲＡＭ、ＥＥＰＲＯＭ、メモリカード等の不揮発性記録媒体（メモリ）に記録して提供することもできる。

そのメモリに記録されたプログラムをコンピュータにインストールしてＣＰＵに実行させるか、ＣＰＵにそのメモリからこのプログラムを読み出して実行させることにより、ウェブサーバ１００又はＭＦＰ２００の各機能を実行させることができる。
これらの制御方法及びプログラムにおける各処理手順も、前述した実施形態で説明したものに限るものではない。

１００：ウェブサーバ（サーバ装置） １１０：メイン制御部
１１１：メインＣＰＵ（第１のＣＰＵ） １１２：ＲＯＭ
１１３：ＲＡＭ（第２の記憶部） １１４：ＨＤＤ（第１の記憶部）
１２０：サブ制御部 １２１：サブＣＰＵ（第２のＣＰＵ） １２２：ＲＯＭ
１２３：ＲＡＭ １３０：処理回路 １３１：振り分け部
１４０：ネットワークＩ／Ｆ １５０：ウェブアプリケーション
１５１：画面データ記憶部 １５２：表示サービス部 １５３：ロジック部
１５４：各種アプリケーション １５５：高速記憶部（第２の記憶部）
１５６：低速記憶部（第１の記憶部） １７０：クライアント情報管理部
１７１：クライアント管理テーブル １７２：記憶部管理部
１７３：アクセス頻度解析部 １７４：ステータス通知パケット受信部

２００：ＭＦＰ（クライアント装置） ２０１：ＭＦＰのＣＰＵ ２０２：ＲＯＭ
２０３：ＲＡＭ ２０４：ＨＤＤ ２０５：タッチパネル
２０６：エンジン部Ｉ／Ｆ ２０７：エンジン部 ２０８：ネットワークＩ／Ｆ
２１０：ウェブブラウザ ２１１：アクセス要求生成部
２１２：識別子要否判断部 ２１３：解析表示部 ２２０：パケット生成送信部
２３０：サービスプロバイダ ２３１：ジョブ生成部 ２３２：ジョブ実行部
２４０：スキャナ処理部 ２５０：プリント処理部 ２６０：ＦＡＸ処理部
２７０：ステータス通知パケット生成送信部 ３００：ネットワーク

特開２０１１−６５５９３号公報

Claims (9)

1. クライアント装置と、該クライアント装置からネットワークを介してアクセス可能なサーバ装置とを備えたクライアントサーバシステムであって、
   前記クライアント装置が、
   前記サーバ装置へのアクセス要求を生成するアクセス要求生成手段と、
   該アクセス要求生成手段が生成するアクセス要求に係るアクセス対象のアドレスに基づき、識別子の要否を判断する識別子要否判断手段と、
   該識別子要否判断手段が識別子要と判断した場合には、前記アクセス要求生成手段が生成したアクセス要求を送信するためのパケットに前記識別子を付加して、識別子否と判断した場合には該パケットに前記識別子を付加せずに、それぞれ前記サーバ装置へ送信するパケット送信手段と、
   自己のステータスに関連する情報を前記サーバ装置へ通知する通知手段とを有し、
   前記サーバ装置が、
   第１のＣＰＵと、
   第２のＣＰＵと、
   前記クライアント装置から前記パケットを受信した場合に、該パケットに前記識別子が付加されているか否かを判断する識別子付加判断手段と、
   前記クライアント装置から受信したパケットを、前記識別子付加判断手段が前記識別子が付加されていると判断した場合には前記第２のＣＰＵに渡し、前記識別子が付加されていないと判断した場合には前記第１のＣＰＵに渡す振り分け手段と、
   当該サーバ装置にアクセス可能な複数の前記クライアント装置からそれぞれ要求されることが予測されるデータを全て格納する不揮発性の第１の記憶部と、
   該第１の記憶部より読み出し速度が速い第２の記憶部と、
   前記クライアント装置の前記通知手段から通知される前記情報に基づいて、ステータスが通信可能な動作状態であると判断したクライアント装置から要求されることが予測されるデータを、前記第１の記憶部から前記第２の記憶部へキャッシュするクライアント情報管理手段とを有することを特徴とするクライアントサーバシステム。
2. 前記クライアント装置の前記通知手段は、自己のステータスが前記サーバ装置と通信可能な動作状態である場合には、前記サーバ装置に定期的に通知パケットを送信する手段であり、
   前記サーバ装置の前記クライアント情報管理手段は、前記クライアント装置が通信可能な動作状態か否かを、前記クライアント装置から定期的に送信される前記通知パケットに基づいて判断することを特徴とする請求項１に記載のクライアントサーバシステム。
3. 前記サーバ装置の前記クライアント情報管理手段は、前記第２の記憶部にキャッシュしたデータを前記クライアント装置ごとに管理するためのクライアント管理テーブルと、該クライアント管理テーブルの管理情報を更新する手段とを有することを特徴とする請求項１又は２に記載のクライアントサーバシステム。
4. 前記サーバ装置の前記クライアント情報管理手段は、アクセス要求があった各クライアント装置ごとに、そのアクセス頻度の情報を前記クライアント管理テーブルに保持させ、前記第２の記憶部の記憶容量が不足した場合には、該第２の記憶部にキャッシュされているデータを、前記管理テーブルを参照してアクセス頻度が最も低いクライアント装置に対するデータから順に削除することを特徴とする請求項３に記載のクライアントサーバシステム。
5. 前記サーバ装置の前記クライアント情報管理手段は、アクセス要求があった各クライアント装置ごとに、その最終アクセス日時の情報を前記クライアント管理テーブルに保持させ、前記第２の記憶部の記憶容量が不足した場合には、該第２の記憶部にキャッシュされているデータを、前記管理テーブルを参照して最終アクセス日時が最も古いクライアント装置に対するデータから順に削除することを特徴とする請求項３に記載のクライアントサーバシステム。
6. ネットワークを介してサーバ装置にアクセス可能なクライアント装置であって、
   前記サーバ装置へのアクセス要求を生成するアクセス要求生成手段と、
   該アクセス要求生成手段が生成するアクセス要求に係るアクセス対象のアドレスに基づき、識別子の要否を判断する識別子要否判断手段と、
   該識別子要否判断手段が識別子要と判断した場合には、前記アクセス要求生成手段が生成したアクセス要求を送信するためのパケットに前記識別子を付加して、識別子否と判断した場合には該パケットに前記識別子を付加させずに、それぞれ前記サーバ装置へ送信するパケット送信手段と、
   自己のステータスに関連する情報を前記サーバ装置へ通知する通知手段とを有することを特徴とするクライアント装置。
7. クライアント装置からネットワークを介してアクセス可能なサーバ装置であって、
   第１のＣＰＵと、
   第２のＣＰＵと、
   前記クライアント装置からパケットを受信した場合に、該パケットに識別子が付加されているか否かを判断する識別子付加判断手段と、
   前記クライアント装置から受信したパケットを、前記識別子付加判断手段が前記識別子が付加されていると判断した場合には前記第２のＣＰＵに渡し、前記識別子が付加されていないと判断した場合には前記第１のＣＰＵに渡す振り分け手段と、
   当該サーバ装置にアクセス可能な複数のクライアント装置からそれぞれ要求されることが予測されるデータを全て格納する不揮発性の第１の記憶部と、
   該第１の記憶部より読み出し速度が速い第２の記憶部と、
   前記クライアント装置から通知されるステータスに関連する情報に基づいて、ステータスが通信可能な動作状態であると判断したクライアント装置から要求されることが予測されるデータを、前記第１の記憶部から前記第２の記憶部へキャッシュするクライアント情報管理手段とを有することを特徴とするサーバ装置。
8. クライアント装置と、該クライアント装置からネットワークを介してアクセス可能なサーバ装置とを備えたクライアントサーバシステムの制御方法であって、
   前記クライアント装置が、
   前記サーバ装置へのアクセス要求を生成するアクセス要求生成手順と、
   該アクセス要求生成手順で生成するアクセス要求に係るアクセス対象のアドレスに基づき、識別子の要否を判断する識別子要否判断手順と、
   該識別子要否判断手順で識別子要と判断した場合には、前記アクセス要求生成手順で生成したアクセス要求を送信するためのパケットに前記識別子を付加して、識別子否と判断した場合には該パケットに前記識別子を付加させずに、それぞれ前記サーバ装置へ送信するパケット送信手順と、
   自己のステータスに関連する情報を前記サーバ装置へ通知する通知手順とを実行し、
   前記サーバ装置が、
   前記クライアント装置から前記パケットを受信した場合に、該パケットに前記識別子が付加されているか否かを判断する識別子付加判断手順と、
   前記クライアント装置から受信したパケットを、前記識別子付加判断手順で前記識別子が付加されていると判断した場合には第２のＣＰＵに渡し、前記識別子が付加されていないと判断した場合には第１のＣＰＵに渡す振り分け手順と、
   当該サーバ装置にアクセス可能な複数のクライアント装置からそれぞれ要求されることが予測されるデータを全て不揮発性の第１の記憶部に格納しておく手順と、
   前記クライアント装置から通知されるステータスに関連する情報に基づいて、ステータスが通信可能な動作状態であると判断したクライアント装置から要求されることが予測されるデータを、前記第１の記憶部から該第１の記憶部より読み出し速度が速い第２の記憶部へキャッシュする手順とを実行する
   ことを特徴とするクライアントサーバシステムの制御方法。
9. コンピュータを、クライアント装置からネットワークを介してアクセス可能なサーバ装置として機能させるためのプログラムであって、
   該コンピュータに、
   前記クライアント装置からパケットを受信した場合に該パケットに識別子が付加されているか否かを判断する識別子付加判断手順と、
   前記クライアント装置から受信したパケットを、前記識別子付加判断手順で前記識別子が付加されていると判断した場合には第２のＣＰＵに渡し、前記識別子が付加されていないと判断した場合には第１のＣＰＵに渡す振り分け手順と、
   当該サーバ装置にアクセス可能な複数のクライアント装置からそれぞれ要求されることが予測されるデータを全て不揮発性の第１の記憶部に格納しておく手順と、
   前記クライアント装置から通知されるステータスに関連する情報に基づいて、ステータスが通信可能な動作状態であると判断したクライアント装置から要求されることが予測されるデータを、前記第１の記憶部から該第１の記憶部より読み出し速度が速い第２の記憶部へキャッシュする手順とを実行させるためのプログラム。

Images