JP5455432B2 - 通信システム及び方法、並びにプログラム - Google Patents

Description

本発明は、通信システム及び方法、並びにプログラムに関し、特に、複数のクライアントからのポーリングによるネットワーク負荷及びサーバへのアクセス集中を回避するための方法に関するものである。

従来、複数のクライアントからサーバにポーリングを行う通信システムでは、複数のクライアントからのアクセスが過度に集中しないように、クライアントの次回ポーリング時間をサーバから指定する方法が提案されている（例えば、特許文献１参照）。この方法では、サーバとクライアントの通信時間の総和が一定時間を超えると、クライアントからの通信要求を所定の期間だけずらすようにサーバからクライアントに対して変更を要求する。そして、クライアントは、サーバの要求に基づいて通信要求をする時刻をずらす。これにより、ネットワーク負荷集中を回避することができる。

また、サーバがアクセスタイミングテーブルを参照して各端末のアクセスタイミング情報を各端末に通知し、各端末がアクセスタイミング情報に基づいてサーバにアクセスを行ってネットワーク負荷の分散を行うシステムが提案されている（特許文献２参照）。

特開平１１−０５３２７４号公報 特開２００４−２３４６２５号公報

上記特許文献１には、ネットワーク負荷の集中が発生した後にクライアントからの通信要求を所定の期間だけずらすことが記載されているが、予め負荷が集中する時間を想定してその時間帯でのアクセスを回避する方法に関しては考慮されていない。

上記特許文献２には、端末ごとのアクセス履歴を記録し、それを基に端末ごとの次回アクセス時間を調整することは記載されているが、その指定時間に指定された端末がアクセス可能かどうかは考慮されていない。

本発明は、複数のクライアントからサーバへの問い合わせによるネットワーク負荷やサーバへのアクセス集中を回避して効率的な通信を行うことができる通信システム及びその制御方法、並びにプログラムを提供することを目的とする。

上記目的を達成するために、本発明の通信システムは、ネットワーク上の複数のクライアントからサーバに対してコンテンツの更新有無を問い合わせる通信システムにおいて、前記クライアントは、前記サーバに問い合わせを行う予定であった第１の予定日時と実際に問い合わせを行った実行日時の組み合わせが登録される履歴情報を保管する第１の保管手段と、前記サーバに対してコンテンツに関する問い合わせを行うときに前記履歴情報をあわせて送信する送信手段とを有し、前記サーバは、前記クライアントから送信された履歴情報を受信する受信手段と、前記クライアントによる次回問い合わせを行う予定となる第２の予定日時を前記コンテンツの更新履歴または現在時刻に基づき算出する算出手段と、前記第２の予定日時を前記受信手段により受信された履歴情報にしたがって調整する調整手段と、前記調整された第２の予定日時を前記クライアントへ返信する返信手段を有することを特徴とする。

本発明によれば、クライアントからの問い合わせの履歴を考慮して次回問い合わせ予定日時を調整することにより、複数のクライアントからサーバへの問い合わせによるネットワーク負荷やサーバへのアクセス集中を回避して効率的な通信を行うことができる。

本発明の第１の実施形態に係る通信システムの構成例を示す図である。 図１のユーザＰＣ及びコンテンツサイトのハードウェア構成の概略を示すブロック図である。 次回リクエスト送信日時の登録処理の一例を示すフローチャートである 図３のステップＳ３０５におけるリクエスト送信予定日時調整処理の詳細を示すフローチャートである。 図４のステップＳ４０１における週次調整処理の詳細を示すフローチャートである。 ユーザＰＣに保管されるリクエスト送信履歴テーブルの一例を示す図である。 本発明の第２の実施形態におけるリクエスト送信予定日時調整処理を示すフローチャートである。 図７のステップＳ７０１における日次調整処理の詳細を示すフローチャートである。 図８のステップＳ８０８における次回リクエスト送信予定時刻調整処理の詳細を示すフローチャートである。 ユーザＰＣに保管されるリクエスト送信履歴テーブルの他の一例を示す図である。 コンテンツサイトに保管されるリクエスト送信予定テーブルの一例を示す図である。

以下、本発明の実施形態を図面を参照して詳細に説明する。

［第１の実施形態］
図１は、本発明の第１の実施形態に係る通信システムの構成例を示す図である。

図１において、第１の実施形態における通信システムは、ユーザＰＣ１０２，１０３とコンテンツサイト１０１とがインターネット等のネットワーク１０４を介して互いに接続されている。複数のクライアントとなるユーザＰＣ１０２，１０３は、サーバとなるコンテンツサイト１０１に対してポーリングを行う。なお、本実施形態では、図示例の通信システムについて説明するが、これに限定されるものではなく、ネットワーク上に他のＰＣやプリンタ等が接続されていてもよい。また、ユーザＰＣは、図示の数に限定されるものではない。

ユーザＰＣ１０２，１０３は、ネットワーク１０４での情報転送が可能な標準プロトコルを有するブラウザ１２０を動作させることが可能である。また、ユーザＰＣ１０２，１０３は、ブラウザ１２０を動作させることにより、ＨＴＴＰ等のプロトコルを用いてコンテンツサイト１０１にアクセスし、ＨＴＭＬやＸＭＬ等の記述言語で作成されたＷｅｂページ情報を取得して解析することができる。さらに、ユーザＰＣ１０２，１０３は、解析したＷｅｂページを不図示のディスプレイ上に表示させることができる。

また、ユーザＰＣ１０２，１０３は、プログラム１３０を動作させることにより、所定の間隔で登録されたハイパーリンクの指し示すデータの状態情報の取得することができる。さらに、ユーザＰＣ１０２，１０３は、プログラム１３０を動作させることにより、ＨＴＴＰ等のプロトコルを用いてコンテンツサイト１０１にアクセスし、ＨＴＭＬやＸＭＬ等の記述言語で作成された状態情報を取得して解析することができる。そして、ユーザＰＣ１０２，１０３は、状態情報を解析した結果からデータを含む情報の更新が認められる場合には、更新があったことをディスプレイ上に表示させることができる。

コンテンツサイト１０１は、制御部１０６により、ユーザＰＣ１０２，１０３からのアクセスに対して情報ＤＢ（データベース）１０７から必要なＷｅｂページ情報や状態情報を取得し、アクセス元に送信を行う。また、コンテンツサイト１０１は、制御部１０６により、後述する図示の処理を行う。

なお、本実施形態では、Ｗｅｂページ情報を表示するブラウザ１２０とデータの状態情報の取得を試行するプログラム１３０とを分けているが同一であってもよいことは云うまでもない。また、本実施形態では、プログラム１３０は、ユーザに対して更新があったことをディスプレイ上に表示させるが、表示を行わずデータの収集を行ってＤＢなどにデータを登録する自動収集ツールの機能の一部であってもよいことは云うまでもない。

図２は、図１のユーザＰＣ１０２，１０３及びコンテンツサイト１０１のハードウェア構成の概略を示すブロック図である。

ユーザＰＣ１０２，１０３、コンテンツサイト１０１は、ＣＲＴディスプレイ（ＣＲＴ）２０１、ＶＲＡＭ２０２、ＢＭＵ２０３を有する。また、キーボード２０４、ＰＤ２０５、ＣＰＵ２０６、ＲＯＭ２０７、ＲＡＭ２０８、ＨＤＤ２０９、ＦＤＤ２１０、及びネットワークＩ／Ｆ２１１を有する。

ＣＲＴ（Cathode Ray Tube）ディスプレイ２０１には、例えば、編集中の文書、図形、画像その他の編集情報、アイコン、メッセージ、メニューその他のユーザインタフェース情報が表示される。ＶＲＡＭ２０２は、ＣＲＴディスプレイ２０１に接続され、該ＣＲＴディスプレイ２０１に表示するための画像が描画される。このＶＲＡＭ２０２に生成された画像データは、所定の規定に従ってＣＲＴディスプレイ２０１に転送され、これによりＣＲＴディスプレイ２０１に画像が表示される。

ＢＭＵ（ビットムーブユニット）２０３は、例えば、メモリ間（例えば、ＶＲＡＭ２０２と他のメモリとの間）のデータ転送や、メモリと各Ｉ／Ｏデバイス（例えば、ネットワークＩ／Ｆ２１１）との間のデータ転送を制御する。キーボード２０４は、文書等を入力するための各種キーを有する。ＰＤ（ポインティングデバイス）２０５は、例えば、ＣＲＴディスプレイ２０１に表示されたアイコン、メニューその他のコンテンツを指示するために使用される。

ＣＰＵ２０６は、ＲＯＭ２０７、ＨＤＤ２０９又はＦＤＤ（フレキシブルディスクドライブ）２１０に格納された制御プログラムに基づいて、上述した各デバイスを制御する。ＲＯＭ２０７は、各種制御プログラムやデータを保存する。ＲＡＭ２０８は、ＣＰＵ２０６のワーク領域、エラー処理時のデータの退避領域、制御プログラムのロード領域等を有する。なお、図１におけるブラウザ１２０やプログラム１３０は、ＲＯＭ２０７、ＨＤＤ２０９又はＦＤＤ２１０に格納される。情報ＤＢ１０７は、ＨＤＤ２０９上に構成される。

ＨＤＤ２０９は、情報処理装置内で実行される各制御プログラムやコンテンツを格納する。ＦＤＤ２１０は、フロッピー（登録商標）ディスク等に代表されるフレキシブルディスクに対するアクセスを制御する。ネットワークＩ／Ｆ２１１は、他の情報処理装置やプリンタ等とネットワーク１０４を介して通信を行う。ＣＰＵバス２１２は、アドレスバス、データバス及びコントロールバスを含む。ＣＰＵ２０６に対する制御プログラムの提供は、ＲＯＭ２０７、ＨＤＤ２０９、ＦＤＤ２１０から行うこともできるし、ネットワークＩ／Ｆ２１１を介してネットワーク１０４経由で他の情報処理装置等から行うこともできる。

次に、図１の通信システムでユーザＰＣ１０２からコンテンツサイト１０１にポーリングリクエスト（単に「リクエスト」とも呼ぶ）を送信してから次回リクエスト送信日時を登録するまでの流れを説明する。なお、ユーザＰＣ１０３もユーザＰＣ１０２と同様に、以下の処理を実行するものとする。

図３は、図１の通信システムでユーザＰＣ１０２からコンテンツサイト１０１にリクエストを送信してから次回リクエスト送信日時を登録するまでの流れを示すフローチャートである。

ユーザＰＣ１０２は、図６（ａ）に示すようなリクエスト送信履歴テーブル６００を参照し、次回リクエスト送信予定日時になると（ステップＳ３００でＹＥＳ）、リクエスト送信履歴テーブル６００を取得する（ステップＳ３０１）。

図６（ａ）において、リクエスト送信履歴テーブル６００は、送信ＩＤ６０１と、次回リクエスト送信予定日時６０２と、調整ＩＤ６０３と、実際の送信日時６０４とで構成される。送信ＩＤ６０１は、次回リクエスト送信予定日時と調整ＩＤと実際の送信日時の組合せを識別して管理するために付与されたＩＤである。次回リクエスト送信予定日時６０２は、ユーザＰＣ１０２からコンテンツサイト１０１に次回問い合わせを行う予定日時である。調整ＩＤ６０３は、コンテンツサイト１０１が送信予定日時の調整を行ったかどうかを示す識別情報である。実際の送信日時６０４は、コンテンツの更新有無を問い合わせるためにユーザＰＣ１０２からコンテンツサイト１０１にリクエストを送信した実際の送信日時（実行日時）である。

リクエスト送信履歴テーブル６００は、ユーザＰＣ１０２固有のリクエスト送信履歴情報であり、ユーザＰＣ１０２内のＨＤＤ２０９に保管される（第１の保管手段）。なお、ユーザＰＣ１０３内のＨＤＤ２０９にも、同様に、ユーザＰＣ１０３固有のリクエスト送信履歴テーブルが保管されているものとする。

次に、ステップＳ３０２にて、ユーザＰＣ１０２は、ステップＳ３０１で取得したリクエスト送信履歴テーブル６００とポーリングリクエストをコンテンツサイト１０１に送信する。このとき、ユーザＰＣ１０２は、送信するリクエスト送信履歴テーブル６００の今回の送信に対応する送信ＩＤに関連付けられた送信日時６０４に、最新のリクエスト送信日時として現在時刻をセットして送信する。

ステップＳ３０３にて、コンテンツサイト１０１は、ポーリングリクエスト及びリクエスト送信履歴テーブル６００をユーザＰＣ１０２から受信する。次に、ステップＳ３０４にて、コンテンツサイト１０１は、次回リクエスト送信予定日時を算出する。この算出方法については、例えばコンテンツの更新履歴から次回更新時を予測したり、単純に現在時刻から一定時間後を予定日時としても構わない。ステップＳ３０４は第１の算出手段の一例である。

ステップＳ３０５にて、コンテンツサイト１０１は、次回リクエスト送信予定日時の調整処理を行う。この調整処理の詳細については図４を用いて詳述する。ステップＳ３０６にて、コンテンツサイト１０１は、ポーリング結果と共に、ステップＳ３０５で調整した次回リクエスト送信予定日時の情報をユーザＰＣ１０２に返す。

ステップＳ３０７にて、ユーザＰＣ１０２は、コンテンツサイト１０１からポーリング結果と次回リクエスト送信予定日時の情報を受信する。そして、受信した次回リクエスト送信予定日時を最新のリクエスト送信予定日時としてリクエスト送信履歴テーブル６００の次回リクエスト送信予定日時６０２に登録して、本処理を終了する。

ユーザＰＣ１０２は、ステップＳ３０７で登録した次回リクエスト送信予定日時になると、改めてステップＳ３０１から処理を実行する。

図４は、図３のステップＳ３０５におけるリクエスト送信予定日時調整処理の詳細を示すフローチャートである。

ステップＳ４０１にて、コンテンツサイト１０１内のＣＰＵ２０６は週次調整処理を行う。この週次調整処理の詳細については図５を用いて詳述する。

次に、ステップＳ４０２にて、ＣＰＵ２０６は、図１１に例示するリクエスト送信予定テーブル１０００を参照し、次回リクエスト送信予定日時に既に送信予定が登録されているか否かを判定する。

図１１において、リクエスト送信予定テーブル１０００は、送信予定日時を返したユーザＰＣ１０２の端末ＩＤ１００１と、ユーザＰＣ１０２に返した次回送信予定日時１００２とで構成されている。リクエスト送信予定テーブル（予定日時情報）１０００は、コンテンツサイト１０１内のＨＤＤ２０９に作成され、ユーザＰＣ毎（クライアント毎）の送信予定日時が保存管理されている（第２の保管手段）。

ステップＳ４０２の判定の結果、次回リクエスト送信予定日時に、どのユーザＰＣからも送信予定が登録されていない場合（ステップＳ４０２でＮＯ）、ステップＳ４０５に進む。ステップＳ４０５では、ＣＰＵ２０６は、次回リクエスト送信予定日時をリクエスト送信予定テーブル１０００に登録してリターンする。

一方、次回リクエスト送信予定日時に既に他のユーザＰＣ（例えば、ユーザＰＣ１０３等）からのリクエスト送信予定が登録されていた場合（ステップＳ４０２でＹＥＳ）、ステップＳ４０３へ進む。ステップＳ４０３では、ＣＰＵ２０６は、次回リクエスト送信予定日時を一定時間シフトして、ステップＳ４０２に戻り、ずらした次回リクエスト送信予定日時に送信予定が登録されていないかを判定する。

次回リクエスト送信予定日時を一定時間シフトする場合は以下のように処理する。例えば、コンテンツサイト１０１で図１１に示すリクエスト送信予定テーブル１０００が運用されていたときは、送信予定日時の時刻が５分刻みで変動していることから、次回リクエスト送信予定日時の時刻を５分間遅らせる。

なお、コンテンツサイト１０１にアクセスするユーザＰＣの端末数が多くなれば、次回リクエスト送信予定時刻のシフト時間を短くしてもよい。

また、本実施形態では、同一時刻にリクエストを受け付けられるユーザＰＣの端末数を１台としているが、これに限定されない。同一時刻にリクエストを受け付ける端末数は、コンテンツサイト１０１の処理能力次第で変わるものであり、例えば、同一時刻に複数台の異なる端末からリクエストを受け付けることも可能である。この場合、ステップＳ４０２では、リクエスト送信予定日時に送信する端末の有無で判断をするのではなく、リクエスト送信予定日時に送信する端末が処理上限に達しているかどうかで判断することは言うまでもない。

図５は、図４のステップＳ４０１における週次調整処理の詳細を示すフローチャートである。

ステップＳ５０１にて、ＣＰＵ２０６は、図３のステップＳ３０４で算出した次回リクエスト送信予定日時から曜日を取得する。なお、この曜日の取得方法は、次回リクエスト送信予定日時に基づいて不図示のカレンダー機能により取得してもよいし、インターネット上から取得してもよい。

ステップＳ５０２では、ＣＰＵ２０６はユーザＰＣ１０２から受信したリクエスト送信履歴テーブル６００からステップＳ５０１で取得した次回リクエスト送信予定日の曜日と同じ曜日が送信予定に指定されている最後（最新）の送信履歴（送信日時）を取得する。なお、不図示であるが、該当する送信履歴が取得できなかった場合、以降の処理を行わずにリターンする。図示例では、リクエスト送信履歴テーブル６００に曜日に関する情報が登録されていないが、曜日情報を登録するように構成してもよいし、曜日情報を求めるように構成してもよい。

ステップＳ５０３にて、ＣＰＵ２０６は、ステップＳ５０２で取得した送信履歴に対応する実際のリクエスト送信日時をリクエスト送信履歴テーブル６００から取得する。このリクエスト送信履歴テーブル６００は図３のステップＳ３０２にてユーザＰＣ１０２からコンテンツサイト１０１に送付されたものであり、コンテンツサイト１０２上のＨＤＤ２０９に保存してもよいし、ＲＡＭ２０８上に保管してもよい。

ステップＳ５０４にて、ＣＰＵ２０６は、ステップＳ５０２で取得した送信履歴のリクエスト送信予定日時（Ｓ１）とステップＳ５０３で取得した実際のリクエスト送信日時（Ｅ１）とを比較し、送信予定日と同じ日にリクエストを送信しているかを判定する。送信予定日と同一の日にリクエストを送信していると判定したときは（ステップＳ５０４でＹＥＳ）、以降の処理を行わずにリターンする。

一方、ステップＳ５０４でリクエストを送信予定日と同じ日に送信していないと判定した場合、ＣＰＵ２０６は、リクエスト送信履歴テーブル６００から、同じ曜日が送信予定日に指定されているもう一つ前の送信履歴を取得する（ステップＳ５０５）。なお、不図示であるが、該当する送信履歴が取得できなかった場合、以降の処理を行わずにリターンする。

ステップＳ５０６にて、ＣＰＵ２０６は、ステップＳ５０５で取得したリクエスト送信履歴に対応する実際のリクエスト送信日時をリクエスト送信履歴テーブル６００から取得する。

次に、ステップＳ５０７にて、ＣＰＵ２０６は、ステップＳ５０５で取得した送信履歴のリクエスト送信予定日時（Ｓ２）とステップＳ５０６で取得した実際のリクエスト送信日時（Ｅ２）とを比較する。そして、送信予定日と同じ日にリクエストを送信しているかを判定する。送信予定日と同一の日にリクエストを送信していると判定したときは（ステップＳ５０７でＹＥＳ）、以降の処理を行わずにリターンする。

一方、ステップＳ５０７でリクエストを送信予定日と同じ日に送信していないと判定した場合、ＣＰＵ２０６は、図３のステップＳ３０４で算出した次回リクエスト送信予定日時を一定時間シフトして（ステップＳ５０８）、リターンする。例えば、ステップＳ５０２からステップＳ５０６で求めた２回の送信予定日時Ｓ１，Ｓ２と実際の送信日時Ｅ１，Ｅ２を利用し、時間差Ｅ１−Ｓ１と時間差Ｅ２−Ｓ２の小さいほうをシフト時間に決定して、次回リクエスト送信予定日時をシフト時間分ずらす。

図３のステップＳ３０６にて、コンテンツサイト１０１がユーザＰＣ１０２に次回リクエスト送信予定日時を返すときは、週次調整による時間シフトを行ったことを示す調整ＩＤに１をセットして同時に返すものとする。これは、ユーザＰＣ１０２が次回リクエスト送信時にコンテンツサイト１０１が調整ＩＤ＝１の送信履歴を含むリクエスト送信履歴テーブル６００を受信した場合、送信履歴と実際のリクエスト送信日時とを比較する。そして、比較の結果、時刻が異なるときには、例えば一定時間リクエスト送信予定日時を遅らせる等の時間調整に利用できるためである。

図６（ａ）において、最後（最新）のリクエスト送信履歴が２００８／６／１３＿９：００に送信されていることが判る（送信ＩＤ１１）。これは、コンテンツサイト１０１が毎日コンテンツの更新を行っていることから、送信予定日時が翌日の９：００に返されているためである（送信ＩＤ８〜１１）。

送信ＩＤ７では、送信予定日時として登録された２００８／６／７にはリクエストが送信されず、実際の送信日時は２００８／６／９である。また、その１週間前の送信ＩＤ２では、５／３１（土曜日）と６／１（日曜日）の２日間のリクエスト送信がなかったことを示す。これらの送信履歴から上述した図５の週次調整処理が行われると、送信ＩＤ１２に示すように、次回リクエスト送信予定日時が調整される。送信ＩＤ１２には、送信予定日時を調整したことを示すＩＤ＝１が登録されている。

上記処理により、例えば毎日曜日が休業でユーザＰＣが起動していない環境からのポーリングリクエストが翌月曜日にずれ込んで送られることを事前に想定し、月曜日のリクエスト受信量を事前に調整することで、負荷集中を避けることができる。

上記第１の実施形態によれば、クライアントからの送信履歴を考慮して次回問い合わせ予定日時を調整することにより、複数のクライアントからサーバへの問い合わせによるネットワーク負荷やサーバへのアクセス集中を回避して効率的な通信を行うことができる。

なお、本実施形態では、１週間単位（または日単位）のクライアントの稼働状態を基準に負荷調整を行ったが、例えば一か月単位などの調整を行ってもよい。また、本実施形態では、週次調整を行うために過去２回の送信履歴をもとにユーザＰＣの稼働状態を判定したが、これに限定されず、過去１回であっても３回以上であってもよい。

［第２の実施形態］
本発明の第２の実施形態は、上記第１の実施形態におけるリクエスト送信予定時間の週次調整に対して、時刻単位のクライアントの稼働状態を基準に負荷調整を行う点で相違する。以下に、上記第１の実施形態と異なる点のみを説明する。

図７は、本発明の第２の実施形態におけるリクエスト送信予定日時調整処理を示すフローチャートである。本処理は、図３のステップＳ３０５にて実行される処理である。

ステップＳ７０１にて、コンテンツサイト１０１内のＣＰＵ２０６は日次調整処理を行う。この日次調整処理の詳細については図８を用いて詳述する。

次に、ステップＳ７０２にて、ＣＰＵ２０６は、ユーザＰＣ１０２から受信したリクエスト送信履歴テーブル６００を参照して、リクエスト送信時刻（送信履歴）に一貫性があるかどうかを判定する。一貫性の有無の判定については後述する。なお、本実施形態では、リクエストの送信に要する時間で年月日時分秒が指定されている時間のことを送信日時、送信日時のうち年月日を除いた１日の中での時間帯を示す時間のことを送信時刻と呼ぶことにする。

ステップＳ７０２の判定の結果、送信履歴に一貫性がないと判定した場合、ＣＰＵ２０６は、ステップＳ７０１で調整した次回リクエスト送信予定日時をリクエスト送信予定テーブル１０００に登録せずに処理を終了する。これは、コンテンツサイト１０１内のＣＰＵ２０６が、ユーザＰＣ１０２から受信したリクエスト送信履歴テーブル６００に基づいて、当該ユーザＰＣ１０２がランダムな時間に起動したり終了したりする稼働状態であると判断するためである。また、ＣＰＵ２０６は、次回リクエスト送信予定日時をリクエスト送信予定テーブル１０００に登録しても、その時間帯にユーザＰＣ１０２が稼働中でないおそれがあり、予定通りにユーザＰＣ１０２からリクエストが送信されないと判断するためである。

ステップＳ７０２の判定の結果、送信履歴に一貫性があると判定した場合はステップＳ７０３へ進む。ステップＳ７０３では、ＣＰＵ２０６は、リクエスト送信予定テーブル１０００を参照し、次回リクエスト送信予定日時に既に送信予定が登録されているか否かを判定する。

ステップＳ７０３の判定の結果、次回リクエスト送信予定日時に、どのユーザＰＣからも送信予定が登録されていない場合（ステップＳ７０３でＮＯ）、ステップＳ７０５へ進む。ステップＳ７０５では、ＣＰＵ２０６は、次回リクエスト送信予定日時をリクエスト送信予定テーブル１０００に登録してリターンする。

一方、次回リクエスト送信予定日時に既に他のユーザＰＣ（例えば、ユーザＰＣ１０３）からのリクエスト送信予定が登録されていた場合（ステップＳ７０３でＹＥＳ）、ステップＳ７０４へ進む。ステップＳ７０４では、ＣＰＵ２０６は、次回リクエスト送信予定日時を一定時間シフトして、ステップＳ７０３に戻り、ずらした次回リクエスト送信予定日時に送信予定が登録されていないかを判定する。

次回リクエスト送信予定日時を一定時間シフトする場合、以下のように処理する。例えば、コンテンツサイト１０１で図１１に示すリクエスト送信予定テーブル１０００が運用されていたときは、送信予定日時の時刻が５分刻みで変動していることから、次回リクエスト送信予定日時の時刻を５分間遅らせる。

なお、コンテンツサイト１０１にアクセスするアクセスするユーザＰＣの端末数が多くなれば、次回リクエスト送信予定時刻のシフト時間を短くしてもよい。

また、本実施形態では、同一時刻にリクエストを受け付けられるユーザＰＣの端末数を１台としているが、これに限定されない。同一時刻にリクエストを受け付ける端末数は、コンテンツサイト１０１の処理能力次第で変わるものであり、例えば、同一時刻に複数台の異なる端末からリクエストを受け付けることも可能である。この場合、ステップＳ７０３では、リクエスト送信予定日時に送信する端末の有無で判断をするのではなく、リクエスト送信予定日時に送信する端末が処理上限に達しているかどうかで判断することは言うまでもない。

図８は、図６のステップＳ７０１における日次調整処理の詳細を示すフローチャートである。

ステップＳ８０１にて、ＣＰＵ２０６は、図３のステップＳ３０４で算出した次回リクエスト送信予定日時から次回リクエスト送信予定時刻を取得する。ステップＳ８０２にて、ＣＰＵ２０６は、ユーザＰＣ１０２から受信したリクエスト送信履歴テーブル６００から、ステップＳ８０１で取得した次回リクエスト送信予定時刻と同じ時刻（日が異なって時、分が同じ）の最後（最新）の送信履歴を取得する。なお、不図示であるが、該当する送信履歴が取得できなかった場合、以降の処理を行わずにリターンする。

ステップＳ８０３にて、ＣＰＵ２０６は、ステップＳ８０２で取得した送信履歴に対応する実際のリクエスト送信日時および送信時刻をリクエスト送信履歴テーブル６００から取得する。

ステップＳ８０４にて、ＣＰＵ２０６は、ステップＳ８０２で取得した送信履歴のリクエスト送信予定時刻（ＳＴ１）とステップＳ８０３で取得した実際のリクエスト送信時刻（ＥＴ１）を比較する。そして、送信予定時刻と同一の時刻にリクエストを送信しているかを判定する。送信予定時刻と同一の時刻にリクエストを送信していると判定したときは（ステップＳ８０４でＹＥＳ）、以降の処理を行わずにリターンする。

一方、ステップＳ８０４でリクエストを送信予定時刻と同一の時刻に送信していないと判定した場合、ＣＰＵ２０６は、リクエスト送信履歴テーブル６００から、同じ時刻が送信予定時刻に指定されているもう一つ前の送信履歴を取得する（ステップＳ８０５）。なお、不図示であるが、該当する送信履歴が取得できなかった場合、以降の処理を行わずにリターンする。

ステップＳ８０６にて、ＣＰＵ２０６は、ステップＳ８０５で取得したリクエスト送信履歴に対応する実際のリクエスト送信時刻をリクエスト送信履歴テーブル６００から取得する。

次に、ステップＳ８０７にて、ＣＰＵ２０６は、ステップＳ８０５で取得した送信履歴のリクエスト送信予定時刻（ＳＴ２）とステップＳ８０６で取得した実際のリクエスト送信時刻（ＥＴ２）とを比較する。そして、送信予定時刻と同一の時刻にリクエストを送信しているかを判定する。送信予定時刻と同一の時刻にリクエストを送信していると判定したときは（ステップＳ８０７でＹＥＳ）、以降の処理を行わずにリターンする。

一方、ステップＳ８０７でリクエストを予定時刻と同じ時刻に送信していないと判定した場合、ＣＰＵ２０６は、次回リクエスト送信予定日時の時刻をシフトするための次回リクエスト送信予定時刻調整処理を行う（ステップＳ８０８）。この次回リクエスト送信予定時刻調整処理の詳細については図９を用いて詳述する。

なお、図８におけるステップＳ８０４，Ｓ８０７でリクエスト送信予定時刻と実際のリクエスト送信時刻とが同じかどうかの判断を行ったが、時刻がまったく一致している場合に限らない。例えば、両時刻の差が一定時間以内（例えば２分以内等）であれば、同じであると判断しても構わない。

図９は、図８のステップＳ８０８における次回リクエスト送信予定時刻調整処理の詳細を示すフローチャートである。

ステップＳ９０１にて、ＣＰＵ２０６は、図８のステップＳ８０２で取得した送信予定時刻ＳＴ１から新たな送信予定時刻ＳＴ３を算出する。この送信予定時刻ＳＴ３は、例えば、上述した送信予定時刻ＳＴ１の１５分前とする。なお、送信予定時刻ＳＴ３には、送信予定時刻ＳＴ１の近傍で当該送信予定時刻ＳＴ１とは異なる時刻を設定できれば、どのような方法で算出しても構わない。そのため、送信予定時刻ＳＴ３は、ステップＳ８０２，Ｓ８０３で取得した送信予定時刻ＳＴ１と実際の送信時刻ＥＴ１及びステップＳ８０５、Ｓ８０６で求めた送信予定時刻ＳＴ２と実際の送信時刻ＥＴ２から算出するようにしてもよい。

具体的には、例えば、送信予定時刻ＳＴ１より時刻ＳＴ１とＥＴ１の差分の２分の１の時間だけ後ろにずらした時刻を設定してもよい。逆に、送信予定時刻ＳＴ２より時刻ＳＴ２とＥＴ２の差分の２分の１の時間だけ前にずらした時刻を設定してもよい。また、ＥＴ１，ＥＴ２それぞれより前の時刻であれば、一定時間（例えば、１０分等）だけＳＴ１をずらしても構わない。ステップＳ９０１は第２の算出手段の一例である。

ステップＳ９０２にて、ＣＰＵ２０６は、リクエスト送信履歴テーブル６００から、リクエスト送信予定日時ＳＴ１以降に送信予定時刻がＳＴ３に調整されている送信履歴を検索する。ステップＳ９０３にて、ＣＰＵ２０６は、ステップＳ９０２の条件に合う送信履歴があったかどうかを判定し、履歴がなかった場合には（ステップＳ９０３でＮＯ）、送信予定時刻をＳＴ３としてリターンする。

一方、ステップＳ９０３の判定の結果、ＳＴ３を送信予定時刻とした送信履歴が存在した場合（ステップＳ９０３でＹＥＳ）、ＣＰＵ２０６は、その送信履歴の実際のリクエスト送信時刻ＥＴ３を取得する（ステップＳ９０４）。

ステップＳ９０５にて、ＣＰＵ２０６は、送信予定時刻ＳＴ３と実際の送信時刻ＥＴ３とを比較し、送信予定時刻ＳＴ３と同一の時刻にリクエストが送信されていた場合には、送信予定時刻をＳＴ３として、リターンする。

一方、送信予定時刻ＳＴ３と同一の時刻にリクエストが送信されていなかった場合、ＣＰＵ２０６は、実際のリクエスト送信時刻ＥＴ１、ＥＴ２、ＥＴ３に一貫性があるかどうかを判定する（ステップＳ９０６）。ここでは、それぞれの送信時刻に１時間以上の差があれば一貫性はないと判断する。なお、一貫性の判断時間は、予め規定されている時間であれば何でもよく、１時間に固定されるものでないことは言うまでもない。

ステップＳ９０６の判定の結果、リクエスト送信時刻ＥＴ１、ＥＴ２、ＥＴ３に一貫性がないと判断した場合、ＣＰＵ２０６は、時間調整処理をリセットし、ステップＳ３０４で算出した次回リクエスト送信予定日時を予定日時とする（ステップＳ９０７）。この場合、図７で説明したとおり、ユーザＰＣ１０２がランダムな時間にリクエストを送信してくるものと判断して、ＣＰＵ２０６は、リクエスト送信予定テーブル１０００には次回送信予定日時を登録しない。

一方、ステップＳ９０６の判定の結果、リクエスト送信時刻ＥＴ１，ＥＴ２，ＥＴ３に一貫性があると判断した場合、ＣＰＵ２０６は、ステップＳ９０８にて、リクエスト送信時刻ＥＴ３に送信予定時刻ＳＴ３の効果があったかどうかを判定する。送信予定時刻ＳＴ３の効果がなかった場合（Ｓ９０８でＮＯ）、つまりＳＴ３として、ＳＴ１，ＳＴ２より前の時刻にリクエスト送信予定時刻を設定したにも関わらず、ＥＴ３がＥＴ１，ＥＴ２と大差ない時刻であった場合、ユーザＰＣ１０２は以下を実行する。すなわち、ユーザＰＣ１０２は、ＥＴ１，ＥＴ２，ＥＴ３の時刻前後まで停止しているとみなす。そして、ステップＳ９０９にて、次回リクエスト送信予定時刻ＳＴ４としてＥＴ１，ＥＴ２，ＥＴ３の中間時刻をもった次回送信予定日時をリクエスト送信予定テーブル１０００に登録する。

一方、ステップＳ９０８の判定の結果、送信予定時刻ＳＴ３の効果があった場合（ステップＳ９０８でＹＥＳ）、つまりＳＴ１，ＳＴ２からＳＴ３に時間をずらしただけＥＴ１，ＥＴ２からＥＴ３に時間がずれた場合、以下となる。すなわち、ユーザＰＣ１０２は何らかの理由で負荷の大きな処理をしているため、予定時刻通りにリクエストが出せないと判断することができる。この場合、ステップＳ９１０にて次回リクエスト送信予定時刻をＳ１，Ｓ３の近傍から大幅にずらした時間（例えば、１時間後）に再調整する。

図６（ｂ）は、図９のステップＳ９０７で調整をリセットした場合のリクエスト送信履歴テーブルの一例を示す図である。

図６（ｂ）において、リクエスト送信履歴テーブル７００は、リクエスト送信履歴テーブル６００と同様に、送信ＩＤ６０１と、次回リクエスト送信予定日時６０２と、調整ＩＤ６０３と、実際の送信日時６０４とで構成される。

図示例では、送信ＩＤ２のリクエスト送信予定日時が２００８／６／２＿８：２０になっているが、実際の送信日時は２００８／６／２＿８：３３である。翌日の６／３も同じ時刻がリクエスト送信予定時刻になっているが、実際の送信日時は２００８／６／３＿１０：１６である（送信ＩＤ３）。そこで、ステップＳ９０１における時刻調整がなされた送信ＩＤ４のリクエスト送信予定日時は２００８／６／４＿８：０５となっている。

しかし、実際の送信日時は２００８／６／４＿１４：１０となっていて、３回のリクエスト送信時刻に一貫性がないと判断され、次のリクエスト送信予定時刻は２００８／６／５＿８：２０（送信ＩＤ５）と調整前の時刻に戻っている。この場合、調整ＩＤには、調整リセットを示す調整ＩＤ＝９９がセットされている。

図６（ｃ）は、図９のステップＳ９０９で送信予定日時の調整をした場合のリクエスト送信履歴テーブルの一例を示す図である。

図６（ｃ）において、リクエスト送信履歴テーブル８００は、リクエスト送信履歴テーブル６００と同様に、送信ＩＤ６０１と、次回リクエスト送信予定日時６０２と、調整ＩＤ６０３と、実際の送信日時６０４とで構成される。

図示例では、送信ＩＤ２のリクエスト送信予定日時が２００８／６／２＿９：２０になっているが、実際の送信日時は２００８／６／２＿９：３３である。翌日の６／３も同じ時刻がリクエスト送信予定時刻になっているが、実際の送信日時は２００８／６／３＿９：３２である（送信ＩＤ３）。そこで、ステップＳ９０１における時刻調整がなされた送信ＩＤ４のリクエスト送信予定日時は２００８／６／４＿９：０５となっている。

しかし、実際の送信日時は２００８／６／４＿９：３４となっていて、リクエスト送信予定時刻を調整したにも関わらず、実際のリクエスト送信時刻にはその影響が出ていない。この場合、毎日９：３０頃にユーザＰＣ１０２が起動すると想定して過去３回の送信履歴から２００８／６／５＿９：３３が次回リクエスト送信予定日時になり、５分単位で丸められた時刻９：３５がセットされている。なお、送信ＩＤ４には、時刻調整を行ったことを示す調整ＩＤ＝２がセットされている。

図１０（ａ）は、図９のステップＳ９１０で送信予定日時の再調整した場合のリクエスト送信履歴テーブルの一例を示す図である。

図１０（ａ）において、リクエスト送信履歴テーブル９００は、リクエスト送信履歴テーブル６００と同様に、送信ＩＤ６０１と、次回リクエスト送信予定日時６０２と、調整ＩＤ６０３と、実際の送信日時６０４とで構成される。

図示例では、送信ＩＤ２のリクエスト送信予定日時が２００８／６／２＿８：３０になっているが、実際の送信日時は２００８／６／２＿８：３８である。翌日の６／３も同じ時刻がリクエスト送信予定時刻になっているが、実際の送信日時は２００８／６／３＿８：３９である（送信ＩＤ３）。そこで、ステップＳ９０１における時刻調整がなされた送信ＩＤ４のリクエスト送信予定日時は２００８／６／４＿８：１５となっている。

しかしながら、送信ＩＤ４の実際の送信日時は２００８／６／４＿８：２３となっていて、リクエスト送信予定時刻を調整した時間だけ実際のリクエスト送信時刻が早くなっている。この場合、毎日同時間帯にはユーザＰＣ１０２が何らかの重い処理を実行していて、リクエストが送信できない状態にあると判断し、送信ＩＤ５に示すように次回リクエスト送信日時を１時間繰り下げている。送信ＩＤ５の調整ＩＤには、時刻再調整を行ったことを示す調整ＩＤ＝３がセットされている。

上記処理により、例えば、毎日同じ時間に起動するユーザＰＣに対して、そのユーザＰＣが起動する時刻よりも前に次回リクエスト送信予定時刻がセットされてしまうという問題を回避することができる。

また、リクエスト送信予定時刻にリクエストを送信してこないユーザＰＣの次回リクエスト送信予定日時を調整し、予定外の時間にリクエストを送信するユーザＰＣを極力減らすことでリクエスト負荷の均質化を図ることができる。

なお、本実施形態では、日次調整処理を行うために過去２回の送信履歴をもとにユーザＰＣの稼働状態を判定したが、これに限定されず、過去１回であっても３回以上であってもよい。

［第３の実施形態］
本発明の第３の実施形態は、上記第２の実施形態に対して、リクエスト送信予定時間の日次調整を別の方法で実行する点において相違する。以下に、上記第２の実施形態と異なる点のみを説明する。

図９のステップ９１０では、例えば、ユーザＰＣ１０２が何らかの処理を実行することによってリクエスト送信時刻が常に予定時刻より一定時間遅れている場合について、ＣＰＵ２０６が次回リクエスト送信予定日時の再調整を行っている。しかし、このような場合、コンテンツサイト１０１への負荷を分散させるには別の方法があるので、その内容を説明する。

ステップＳ９１０においてＥＴ３がＳＴ３の影響を受けている場合、ステップＳ９０７と同様に調整をリセットしても構わない。この場合、引き続き行われるステップＳ７０３〜Ｓ７０５にて、ステップＳ３０４で算出した送信予定日時にＥＴ３とＳＴ３の時差を考慮した送信予定日時をリクエスト送信予定テーブル１０００に登録する。または、ステップＳ３０４で算出した送信予定日時にユーザＰＣ１０２から送られてくる時間の差分を考慮した送信予定日時をリクエスト送信予定テーブル１０００に登録する。

図１０（ｂ）は、本発明の第３の実施形態におけるリクエスト送信履歴テーブルの一例を示す図である。

図１０（ｂ）において、リクエスト送信履歴テーブル１１００は、リクエスト送信履歴テーブル６００と同様に、送信ＩＤ６０１と、次回リクエスト送信予定日時６０２と、調整ＩＤ６０３と、実際の送信日時６０４とで構成される。リクエスト送信履歴テーブル１１００は、ステップＳ９１０で送信予定日時の再調整をリセットした場合のリクエスト送信履歴情報である。

図示例では、送信ＩＤ２のリクエスト送信予定日時が２００８／６／２＿８：３０になっているが、実際の送信日時は２００８／６／２＿８：３８である。翌日の６／３も同じ時刻が送信予定時刻になっているが、実際の送信日時は２００８／６／３＿８：３９である（送信ＩＤ３）。そこで、ステップＳ９０１における時刻調整がなされた送信ＩＤ４のリクエスト送信予定日時は２００８／６／４＿８：１５となっている。

しかしながら、送信ＩＤ４の実際の送信日時は２００８／６／４＿８：２３となっていて、リクエスト送信予定時刻を調整した時間だけ実際のリクエスト送信時刻が早くなっている。この場合、毎日同時間帯にはユーザＰＣ１０２が何らかの重い処理を実行していて、リクエストが送信できない状態にあると判断し、送信ＩＤ５に示すように次回リクエスト送信日時が８：３０にリセットされている。送信ＩＤ５の調整ＩＤには、時刻再調整を行ったことを示す調整ＩＤ＝４がセットされている。このとき、コンテンツサイト１０１に保管されるリクエスト送信予定テーブル１０００には、２００８／６／５＿８：３０が登録されるのではない。すなわち、リクエスト送信履歴テーブル１１００にある誤差８分を５分単位で丸めた時差１０分を考慮した２００８／６／５＿８：４０が登録されることになる。

［第４の実施形態］
上記第１〜第３の実施形態では、リクエスト送信履歴テーブルがユーザＰＣ１０２側で保存管理される構成について説明したが、本発明の第４の実施形態として、コンテンツサイト１０１側でユーザＰＣ毎に保存管理される構成であってもよい。この場合、不図示であるが、リクエスト送信履歴テーブルには、送信ＩＤ６０１、次回リクエスト送信予定日時６０２、調整ＩＤ６０３、実際の送信日時６０４に加えて、各ユーザＰＣの一意に特定するための端末ＩＤが登録管理される。

また、第４の実施形態では、図３のステップＳ３０２でユーザＰＣ１０２がポーリングリクエストを送信するときに、コンテンツサイト１０１に対してリクエストの送信日時を送付する必要がある。そして、コンテンツサイト１０１は、ステップＳ３０３にてポーリングリクエストと共にリクエストの送信日時を受信する。この場合、上記第１の実施で送信されたリクエスト送信履歴テーブル６００は、コンテンツサイト１０１で保管されているリクエスト送信履歴テーブル６００からユーザＰＣ１０２の端末ＩＤを用いて検索することができることは言うまでもない。

本発明の実施形態は、ネットワーク又は各種記憶媒体を介して取得したソフトウェア（プログラム）をパーソナルコンピュータ（ＣＰＵ，プロセッサ）にて実行することでも実現できる。

１０１ コンテンツサイト（サーバ）
１０２，１０３ ユーザＰＣ（クライアント）
１０４ ネットワーク
１０６ 制御部
１０７ 情報ＤＢ
２０６ ＣＰＵ
２０７ ＲＯＭ
２０８ ＲＡＭ
６００ リクエスト送信履歴テーブル
１１００ リクエスト送信予定テーブル

Claims (5)

1. ネットワーク上の複数のクライアントからサーバに対してコンテンツの更新有無を問い合わせる通信システムにおいて、
   前記クライアントは、
   前記サーバに問い合わせを行う予定であった第１の予定日時と実際に問い合わせを行った実行日時の組み合わせが登録される履歴情報を保管する第１の保管手段と、
   前記サーバに対してコンテンツに関する問い合わせを行うときに前記履歴情報をあわせて送信する送信手段とを有し、
   前記サーバは、
   前記クライアントから送信された履歴情報を受信する受信手段と、
   前記クライアントによる次回問い合わせを行う予定となる第２の予定日時を前記コンテンツの更新履歴または現在時刻に基づき算出する算出手段と、
   前記第２の予定日時を前記受信手段により受信された履歴情報にしたがって調整する調整手段と、
   前記調整された第２の予定日時を前記クライアントへ返信する返信手段を有することを特徴とする通信システム。
2. 前記サーバは、前記調整された第２の予定日時を前記クライアント毎に保管する第２の保管手段をさらに備え、
   前記調整手段は、さらに、前記調整された第２の予定日時を、前記保管された他のクライアントの第２の予定日時にしたがって調整することを特徴とする請求項１記載の通信システム。
3. 前記算出手段により算出された第２の予定日時と同じ曜日または同じ時間帯の、前記第１の予定日時を有する前記履歴情報を取得する取得手段と、
   前記取得された履歴情報における少なくとも１組の前記第１の予定日時と前記実行日時とを比較する比較手段をさらに備え、
   前記調整手段は、前記比較結果にしたがって前記第２の予定日時を調整することを特徴とする請求項１または２に記載の通信システム。
4. ネットワーク上の複数のクライアントからサーバに対してコンテンツの更新有無を問い合わせる通信システムの通信方法において、
   前記クライアントによって、
   前記サーバに問い合わせを行う予定であった第１の予定日時と実際に問い合わせを行った実行日時の組み合わせが登録される履歴情報を保管する保管工程と、
   前記サーバに対してコンテンツに関する問い合わせを行うときに前記履歴情報をあわせて送信する送信工程と、
   前記サーバによって、
   前記クライアントから当該サーバに送信された履歴情報を受信する受信工程と、
   前記クライアントによる次回問い合わせを行う予定となる第２の予定日時を前記コンテンツの更新履歴または現在時刻に基づき算出する算出工程と、
   前記第２の予定日時を前記受信工程で受信された履歴情報にしたがって調整する調整工程と、
   前記調整された第２の予定日時を前記クライアントへ返信する返信工程と、
   を有することを特徴とする通信方法。
5. 請求項４記載の通信方法をコンピュータに実行させるためのコンピュータで読み取り可能なプログラム。