JP2009282950A - 通信システムおよび通信方法、ならびに、クライアント装置およびその制御方法 - Google Patents

Abstract

【課題】ネットワーク上に分散的に存在するデータの更新情報を取得するタイミングを適切に制御する。
【解決手段】ユーザ側のコンピュータは、登録されたハイパーリンクが示すデータを持つサーバ装置に対してポーリングを行い、当該データの状態を示す状態情報をリクエストする。サーバ装置は、データの更新履歴に基づき状態情報を生成し、コンピュータに返す。コンピュータは、受信した状態情報に基づきデータに更新があったか否かを判断し、更新が無いと判断したら固定値をポーリング間隔に設定し、更新があったと判断したら受信した状態情報に基づきポーリング間隔を設定する。サーバ装置が有するデータの更新履歴に基づきポーリング間隔を設定するので、サーバ装置に繰り返しアクセスしてアクセス履歴やデータの更新日時を蓄積しなくても、適応的にポーリング間隔を求めることができる。
【選択図】図３

Description

本発明は、通信システムおよび通信方法、ならびに、クライアント装置およびその制御方法に関し、特には、更新されるコンテンツデータを取り扱う通信システムおよび通信方法、ならびに、クライアント装置およびその制御方法に関する。

近年では、インターネットなどネットワーク環境が広く普及しており、ネットワーク上には膨大なデータが分散的に存在している。このネットワーク上に存在する膨大なデータを効率的に収集するためには、これら分散的に存在するデータの更新情報を取得するのが有効である。更新情報の取得方法としては、例えばネットワークに接続されたコンピュータから、ネットワーク上のデータを保有しているコンピュータに対してポーリングを行って更新情報の有無を問い合わせ、更新情報を取得する方法が知られている。

このとき、ポーリング間隔を短くすれば、より高精度に更新情報を取得することができる。しかしながら、特にポーリング間隔よりも遙かに長い間隔で更新が行われるデータが多い場合、ネットワークにおけるトラフィックを無駄に消費してしまうことになる。また、ポーリング間隔が長すぎると、例えばポーリング間隔内に複数回の更新が行われるようなデータに対して、取得される更新情報の精度が低くなる。

更新情報の精度を向上させるためのポーリング間隔の制御方法として、特許文献１には、データ収集のためのアクセス履歴に基づきポーリング間隔を制御する技術が記載されている。すなわち、特許文献１によれば、データ収集を行うための通信結果に基づき、更新が行われているデータにアクセスした日時をアクセス履歴として蓄積する。そして、このアクセス履歴に基づいてデータが更新される日時に関する規則性を分析し、分析結果に基づいてポーリング間隔を制御するようにしている。

また、特許文献２には、収集データの更新情報のうち最新の更新日時の情報に基づき、ポーリング間隔を制御する技術が記載されている。すなわち、特許文献２によれば、収集データ内に最新の更新日時の情報が含まれる場合に、その最新の更新日時を抽出して蓄積する。そして、この蓄積した更新日時に基づいて情報を更新する日時に関する規則性を分析し、分析結果に基づいてポーリング間隔の制御を行うようにしている。

特開平０９−０３４８１２公報 特開平１０−０４９５５３公報

上述した特許文献１および特許文献２に記載される方法によれば、ポーリング間隔を制御するために蓄積する情報が、アクセス日時または最新の更新日時とされている。そのため、ポーリング間隔より短い間隔で収集データの更新がされていた場合に、収集データの更新日時に見合ったポーリング間隔の制御ができないという問題点があった。

例えば、収集データの更新が初期のポーリング間隔の丁度半分のタイミングで行われる場合、蓄積される更新情報がポーリング間隔（データ更新の間隔の倍）となるため、ポーリング間隔を、収集データに更新日時に応じて制御できない。

また、特許文献１および特許文献２に記載される方法によれば、更新日時に関する規則性を分析するためには、ポーリングを複数回行って、アクセス日時や更新日時の蓄積を行う必要がある。そのため、ポーリングをある程度の回数行って、アクセス日時や更新日時が分析に必要な量だけ蓄積されるまでは、収集データの更新日時に見合ったポーリング間隔の制御ができないという問題点があった。

したがって、本発明の目的は、ネットワーク上に存在するデータの更新情報を取得するタイミングを適応的に制御することができる通信システムおよび通信方法、ならびに、情報処理装置およびその制御方法を提供することにある。

第１の発明は、上述した課題を解決するために、サーバ装置とクライアント装置とがネットワークを介して通信可能に接続された通信システムであって、サーバ装置が、ネットワークを介してクライアント装置によりアクセスされるコンテンツデータの更新履歴を管理するコンテンツデータ管理手段と、コンテンツデータ管理手段が管理する更新履歴に基づいてコンテンツデータの更新の状態を示す状態情報を生成する生成手段とを備え、クライアント装置が、状態情報をサーバ装置に対して要求する要求手段と、要求手段の要求により取得した状態情報に基づいて、要求手段が次に要求を行うべきタイミングを決定する決定手段と、決定手段が決定したタイミングで要求手段に要求を行わせる制御手段とを備えることを特徴とする通信システムである。

また、第２の発明は、クライアント装置と、ネットワークを介してクライアント装置にアクセスされるコンテンツデータの更新履歴を管理するコンテンツデータ管理手段を有するサーバ装置とがネットワークを介して通信可能に接続された通信システムの通信方法であって、クライアント装置が、サーバ装置に対してコンテンツデータ管理手段が管理しているコンテンツデータの更新の状態を示す状態情報の要求を送信する要求送信ステップと、サーバ装置が、クライアント装置からの要求に応じて、コンテンツデータ管理手段が管理する更新履歴に基づきコンテンツデータの更新の状態を示す状態情報を生成する生成ステップと、サーバ装置が、クライアント装置からの要求に応じて、生成ステップで生成された状態情報をネットワークを介してクライアント装置に対して送信する送信ステップと、クライアント装置が、要求送信ステップで送信した要求に応じてサーバ装置から送信された状態情報に基づき、次に要求送信ステップで状態情報の要求を送信するタイミングを決定する決定ステップとを有することを特徴とする通信方法である。

また、第３の発明は、コンテンツの更新履歴を管理しているサーバ装置に対してネットワークを介してアクセスするクライアント装置であって、サーバ装置が管理しているコンテンツデータの更新の状態を示す状態情報をサーバ装置に対して要求する要求手段と、要求手段による要求に応答してサーバ装置が生成した状態情報を取得して、要求手段が次に要求を行うべきタイミングを決定する決定手段と、決定手段が決定したタイミングで要求手段に要求を行わせる制御手段とを有することを特徴とするクライアント装置である。

また、第４の発明は、サーバ装置に更新履歴と共に管理されるコンテンツデータに対してネットワークを介してアクセスするクライアント装置の制御方法であって、サーバ装置が管理しているコンテンツデータの更新の状態を示す状態情報をサーバ装置に対して要求する要求ステップと、要求ステップによる要求に応答してサーバ装置が生成した状態情報に基づいて、要求ステップが次に要求を行うべきタイミングを決定する決定ステップと、決定ステップが決定したタイミングで要求ステップに要求を行わせる制御ステップとを有することを特徴とする制御方法である。

本発明は、上述した構成を有するため、ネットワーク上に存在するデータの更新情報を取得するタイミングを適応的に制御することができる。

以下、本発明の実施形態について、図面を参照して説明する。図１は、本発明に適用可能な通信システムの一例の構成を示す。インターネット１００に対して、ユーザ側のコンピュータ１０１が接続される。クライアント装置としてのユーザ側のコンピュータ１０１上では、後述するブラウザソフトウェア１１０と、本発明の実施形態におけるコンピュータ１０１側の処理を行う情報取得プログラム１１１とが動作する。なお、複数台のクライアント装置１０１がインターネット１００に対して接続されるようにしてもよい。

また、インターネット１００に対して、サーバ装置１０２が接続される。図１の例では、インターネット１００に対して１台のサーバ装置１０２が接続されるように示されているが、複数台のサーバ装置１０２がインターネット１００に対して接続されるようにしてもよい。このように、サーバ装置１０２と、コンピュータ１０１とが、インターネット１００を介して通信可能に接続される。

サーバ装置１０２は、インターネット１００に対する通信機能を有するコンピュータと、当該コンピュータに接続または内蔵されるハードディスクなどの記憶媒体とを具備する。サーバ装置１０２は、コンピュータ上で動作するプログラムおよび記憶媒体上の所定領域により、コンテンツ管理部１２０、コンテンツデータベース１２１および情報データベース１２２が構成される。

サーバ装置１０２は、ＲＳＳの規定に従いリソースのメタデータをコンテンツデータとしてインターネット１００に向けて公開することができる。リソースデータは、静止画像データ、動画像データ、音声データなどのマルチメディア情報であり、コンピュータ１０１のブラウザソフトウェア１１０を用いて再生される。ＲＳＳは、RDF Site SummaryまたはReally Simple Syndicationの略称であり、バージョンにより名称が異なる。以下では、ＲＳＳがバージョンＲＳＳ１．０のRDF Site Summaryであるものとして説明する。なお、ＲＤＦは、Resource Description Frameworkの略称であって、データのメタデータを表現するための枠組みである。

ＲＳＳは、リソースのタイトルやサマリ、サマリが対象とするＵＲＩ情報などによるヘッドライン情報を、インターネット１００上で効率よく流通させるための規格の一つであり、ＸＭＬを用いて記述される。なお、ＸＭＬは、Extensible Markup Languageの略称であって、開始タグ< >および終了タグ</ >を用いてデータ毎の定義を行うことができる。ＲＳＳデータは、サーバ装置１０２においてコンテンツデータベース１２１に格納され、固有のＵＲＩ(Universal Resource Identifier)を与えられてコンテンツ管理部１２０に管理される。すなわち、サーバ装置１０２は、ＲＳＳデータをコンテンツデータとして管理する。ＲＳＳを用いてデータを提供するサービスは、一般的に、ＲＳＳフィードと呼ばれる。

ＲＳＳフィードにより提供される情報について、概略的に説明する。ＲＳＳにおいて、ＲＳＳデータは、少なくともチャンネル要素とアイテム要素とを持つ。チャンネル要素は、ＲＳＳの基本情報が記述される。チャンネル要素には、チャンネルのタイトル、ＲＳＳでサマリ対象とするＷｅｂサイトのＵＲＩ、チャンネルの概要説明、チャンネル要素内のアイテム要素に記述されるリソースの目次が含まれる。リソースの目次は、リソース毎のＵＲＩが記述されてなる。

アイテム要素には、チャンネル要素内のアイテム要素に記述されたリソース毎に、リソースのタイトル、ＵＲＩおよび要約が記述される。アイテム要素に記述されるリソース毎のＵＲＩは、基本的には、チャンネル要素内のアイテム要素に記述されるリソース毎のＵＲＩと同一の値が記述される。

ユーザは、ＲＳＳリーダと呼ばれるアプリケーションソフトウェアを用いてＲＳＳフィードのサービスを受け、ＲＳＳフィードのサービスにより提供されるＵＲＩを用いてＲＳＳデータにアクセスする。そして、ＲＳＳリーダにより、ＲＳＳデータのチャンネル要素およびアイテム要素の記述に従い、アイテム要素に記述されるリソースに関し、タイトルおよび要約が表示されると共に、リソースに対するＵＲＩが示される。ユーザは、実際にＷｅｂサイトにアクセスしなくても、ＲＳＳリーダを用いてＲＳＳフィードにより得られたＲＳＳデータに基づき、所望のリソース情報を迅速に見つけることができる。

以下では、特に記載のない限り、コンテンツデータは、ＲＳＳフィードにより提供されるＲＳＳデータを指す。また、ユーザ側のコンピュータ１０１上で動作するブラウザソフトウェア１１０は、ＲＳＳリーダであるものとする。

サーバ装置１０２において、情報データベース１２２は、コンテンツデータベース１２１に格納されるコンテンツデータの更新情報が格納される。これら情報データベース１２２に格納される更新情報は、コンテンツ管理部１２０により生成される。このコンテンツデータの更新情報が情報データベース１２２に格納される。コンテンツ管理部１２０および情報データベース１２２がコンテンツデータ管理手段に対応し、コンテンツ管理部１２０が生成手段に対応する。

一例として、コンテンツ管理部１２０は、コンテンツデータすなわちＲＳＳデータのアイテム要素に記述される各リソースについて、当該リソースのＵＲＩが示す情報に更新があると、それに応じて当該リソースの要約などを更新し、ＲＳＳデータを更新する。ＲＳＳデータの更新情報は、コンテンツ管理部１２０により情報データベース１２２に格納されると共に、情報データベース１２２内の管理情報が更新される。

なお、図１の例では、サーバ装置１０２に対して、コンテンツデータベース１２１が直接的に接続されるように示されているが、これはこの例に限定されない。すなわち、コンテンツデータベース１２１は、インターネット１００に接続される他のサーバ装置に接続されるものであってもよい。コンテンツデータベース１２１、情報データベース１２２およびコンテンツ管理部１２０を、それぞれインターネット１００上に分散的に配置することもできる。

図２は、ユーザ側のコンピュータ１０１の一例の構成を示す。図２において、バス２０１に対してＣＰＵ２１０、ＲＡＭ２１１およびＲＯＭ２１２、ならびに、グラフィクスコントローラ２１３が接続される。要求手段、決定手段、調整手段および制御手段としてのＣＰＵ２１０は、ＲＯＭ２１２に予め記憶されたプログラムに基づきＲＡＭ２１１をワークメモリとして用いてシステムを起動させる。そして、ＣＰＵ２１０は、後述するハードディスク２２２に予め記録されるプログラムデータを読み込んでＲＡＭ２１１に展開し、ＲＡＭ２１１上に展開されたプログラムデータに基づきコンピュータ１０１の各部を制御する。

グラフィクスコントローラ２１３は、表示装置２１４が接続され、ＣＰＵ２１０から出力された表示制御信号を表示装置２１４が表示可能な信号に変換して、表示装置２１４に出力する。表示装置２１４は、例えばＬＣＤ(Liquid Crystal Display)を表示素子として用いる。

バス２０１に対して、さらに、入力インターフェイス（Ｉ／Ｆ）２２０、ハードディスク２２２、ドライブ装置２２３および通信インターフェイス（Ｉ／Ｆ）２２４が接続される。入力インターフェイス２２０は、キーボード２２１Ａと、ポインティングデバイス２２１Ｂとが接続される。ポインティングデバイス２２１Ｂは、マウスやタッチパッドを適用できる。キーボード２２１Ａやポインティングデバイス２２１Ｂから出力された信号は、入力インターフェイス２２０を介してＣＰＵ２１０に渡される。

ハードディスク２２２は、記録媒体そのものであるハードディスク本体と、ハードディスクを駆動するためのドライブ装置とからなるハードディスクドライブ（ＨＤＤ）として用いられる。ハードディスク２２２には、上述した、ＣＰＵ２１０を動作させるためのプログラムが記録されると共に、このコンピュータ１０１で生成されたり、このコンピュータ１０１に入力される様々なデータを格納することができる。

ドライブ装置２２３は、記録可能なタイプのＤＶＤ(Digital Versatile Disc)やＣＤ(Compact Disc)といった記録媒体が装填可能とされ、装填された記録媒体に対するデータの読み書きを行う。勿論、ドライブ装置２２３に対して、再生専用のタイプのＤＶＤやＣＤ−ＲＯＭを装填してもよい。これに限らず、ドライブ装置２２３は、書き換え可能な不揮発性メモリを装着可能とし、この不揮発性メモリに対するデータの読み書きを行うようにしてもよい。さらに、ドライブ装置２２３は、フレキシブルディスクに対応したものでもよい。

通信Ｉ／Ｆ２２４は、所定のプロトコルを用いて外部のネットワークに接続するためのものである。この図２の例では、通信Ｉ／Ｆ２２４は、ＴＣＰ／ＩＰ(Transmission Control Protocol/Internet Protocol)に対応し、インターネット１００との接続を制御する。ＣＰＵ２１０は、この通信Ｉ／Ｆ２２４を介してインターネット１００上に接続された他の機器と通信を行うことができる。

このような構成において、上述したブラウザ１１０および情報取得プログラム１１１は、ハードディスク２２２に予め記録されるプログラムデータに基づきＣＰＵ２１０により動作される。なお、ここではブラウザ１１０と情報取得プログラム１１１とがそれぞれ独立したソフトウェアであるように説明したが、これらは単一のソフトウェア内の別の機能として実現されてもよい。また、情報取得プログラム１１１は、ＲＡＭ２１１上に常駐し、他のプログラムの実行に対してバックグラウンドで実行されてもよい。

情報取得プログラム１１１は、所定に登録されたリンク情報の指し示すデータに対してＨＴＴＰなどのプロトコルを用いてアクセスし、当該データの状態情報を取得することができる。そして、取得した状態情報を解析し、当該データの更新が認められる場合には、更新があったことを例えば表示装置２１４に対して表示させてユーザに通知することができる。これに限らず、情報取得プログラム１１１は、状態情報を解析した結果得られたデータの更新情報を、データベースなどに自動的に登録するようにしてもよい。

図３は、本発明の実施形態によるデータ状態情報の一例の取得処理を概略的に示すフローチャートである。ステップＳ１０で、ユーザ側のコンピュータ１０１において、ポーリングにより、予め登録されたリンク情報で指定されるコンテンツデータを持つサーバ装置１０２に対して要求送信がなされ、当該コンテンツデータの状態を示す状態情報がリクエスト（要求）される。予め登録されたリンク情報は、例えばＲＳＳフィードの更新情報を受けるためのＵＲＩである。

ステップＳ１１で、当該サーバ装置１０２は、リクエストに応答して状態情報生成を行い、リクエストがあったコンテンツデータの状態情報をコンピュータ１０１に返す。コンテンツデータの状態情報は、コンテンツデータの更新履歴を示す更新履歴情報を用いることができる。

サーバ装置１０２から返された状態情報は、コンピュータ１０１に受信される。コンピュータ１０１は、受信した状態情報に基づき、対応するコンテンツデータに更新があったか否かを判断する（ステップＳ１２）。例えば、コンピュータ１０１は、現在の時刻と受信した状態情報とに基づき、コンテンツデータの更新の有無を判断できる。若し、コンテンツデータに更新があったと判断されれば、処理はステップＳ１３に移行される。また、当該コンテンツデータの状態情報に対する初回の要求であった場合も、処理はステップＳ１３に移行される。

ステップＳ１３では、コンテンツデータの更新があったことが、例えばコンピュータ１０１の表示装置２１４に対する所定の表示によって、ユーザに通知される。これに限らず、コンピュータ１０１が有するデータベースなどに自動的に登録するようにしてもよい。ユーザへの更新の通知がなされると、処理はステップＳ１４に移行される。

ステップＳ１４では、コンピュータ１０１において、受信された状態情報が解析され、当該コンテンツデータの状態情報を次にリクエストするためのポーリング間隔が求められる。そして、処理はステップＳ１５に移行され、求められたポーリング間隔から、当該コンテンツデータの状態情報を次にリクエストする予定のタイミングを示す日時である、状態情報取得予定日時が求められる。

一方、上述のステップＳ１２において、コンテンツデータに更新がなかったと判断されれば、処理はステップＳ１６に移行される。ステップＳ１６では、コンピュータ１０１において、ポーリング間隔が予め決められた固定値に設定される。これに限らず、ユーザがコンピュータ１０１に対して指定した値をポーリング間隔として用いてもよい。ポーリング間隔が設定されると、設定されたポーリング間隔に基づき、状態情報を次回取得する予定の日時が求められる。こうして求められた状態情報を次回取得する予定の日時により、状態情報取得予定日時が決定される。

コンピュータ１０１は、上述のようにしてステップＳ１５またはステップＳ１６で決定された状態情報取得予定日時になったら、ステップＳ１０からの処理を再び行い、状態情報取得予定日時を更新する。

図４は、サーバ装置１０２における更新履歴の一例の管理構造を示す。コンテンツデータの更新履歴は、サーバ装置１０２が管理するコンテンツデータそれぞれを識別するためのデータ管理情報４００と、当該データ管理情報４００に管理されるコンテンツデータの更新日時を示すデータ更新情報４０１とが関連付けられて構成される。データ管理情報４００およびデータ更新情報４０１は、コンテンツ管理部１２０で生成され情報データベース１２２に格納される。

データ管理情報４００は、サーバ装置１０２が管理するコンテンツデータ毎にユニークなＩＤと、サーバ装置１０２上で管理されるコンテンツデータをクライアント（コンピュータ１０１）側が識別するための識別情報とが関連付けられてなる。なお、ＩＤは、Identificationの略称である。この識別情報は、例えば当該コンテンツデータのＵＲＩを用いることができる。データ更新情報４０１は、ＩＤと、ＩＤに対応するコンテンツデータの更新日時とが関連付けられてなり、当該コンテンツデータが更新される度に追加される。

サーバ装置１０２は、識別情報に対応するコンテンツデータの更新履歴を、ＩＤをキーとしてデータ更新情報４０１を検索することで求めることができる。

なお、図示は省略するが、データ管理情報４００に対して、コンテンツデータを識別するための識別情報に加えて、当該コンテンツデータそのものを含ませてもよいし、当該コンテンツデータへのサーバ装置１０２上でのファイルパス情報を含ませてもよい。当該コンテンツデータに関するさらに他の属性情報などをデータ管理情報４００に含ませることもできる。

図５は、コンピュータ１０１側が持つ一例のリンク管理情報５００を示す。このリンク管理情報５００は、例えばユーザがコンピュータ１０１に対して入力した情報に基づき、ＣＰＵ２１０により、コンテンツデータ毎に生成される。ここでは、１つのリンク管理情報５００は、１つのＲＳＳフィードに対応するものとする。ＣＰＵ２１０およびリンク管理情報５００により、コンテンツデータ情報管理手段が構成される。

図５の例では、リンク管理情報５００は、管理用ＩＤ５０１、名称５０２、コンテンツデータを示すリンク情報５０３、当該コンテンツデータの状態情報を示すリンク情報５０４、情報取得日時５０５および状態情報取得予定日時５０６からなる。管理用ＩＤ５０１は、コンピュータ１０１がリンク管理情報５００を識別するための、リンク管理情報５００毎にユニークなＩＤである。例えば、リンク管理情報５００の生成順に通し番号を発生させて、管理用ＩＤ５０１として用いることができる。名称５０２は、ユーザがリンク管理情報５００を識別するための情報である。

リンク情報５０３は、このリンク管理情報５００が対応するコンテンツデータのＵＲＩであって、例えば、このリンク管理情報５００に対応するＲＳＳフィードのＵＲＩである。リンク情報５０４は、サーバ装置１０２において、リンク情報５０３に示されるコンテンツデータに対して生成される状態情報のＵＲＩである。上述した図４を例にとると、データ管理情報４００のＵＲＩをリンク情報５０４として用いることができる。

情報取得日時５０５は、このリンク管理情報５００に登録されるリンク情報５０４が示す状態情報を取得した最新の日時を示す情報である。また、状態情報取得予定日時５０６は、上述した図３のフローチャートにおけるステップＳ１５またはステップＳ１６で求められた状態情報取得予定日時を示す。

一例として、ユーザは、サービスを受けたいＲＳＳフィードのＵＲＩをリンク情報５０３としてリンク管理情報５００に登録する。それと共に、ユーザは、当該コンテンツデータの状態情報のＵＲＩをリンク情報５０４としてリンク管理情報５００に登録する。なお、コンテンツデータの状態情報のＵＲＩは、例えば、ＲＳＳフィードのサービスを受ける際に、サーバ装置１０２からコンピュータ１０１に対して送信されるものとする。

また、当該リンク管理情報５００を識別するための名称を所定に付して、リンク管理情報５００に登録する。管理用ＩＤ５０１は、コンピュータ１０１において自動的に設定される。このようにして生成されたリンク管理情報５００は、例えばコンピュータ１０１のハードディスク２２２に格納される。ユーザは、サービスを受けようとするＲＳＳフィード毎に、このリンク管理情報５００に対する登録操作を繰り返す。

なお、図５の例では、リンク管理情報５００に対し、コンテンツデータを示すリンク情報５０３と、コンテンツデータの状態情報を示すリンク情報５０４とをそれぞれ登録するようにしているが、これはこの例に限定されない。例えば、データ管理情報４００がコンテンツデータを含んでいる場合、コンテンツデータを示すリンク情報５０３は、省略することができる。

このように、この実施形態によれば、サーバ装置１０２側でコンテンツデータに対してなされた更新の履歴に基づき生成した状態情報を用いて、当該状態情報を次に取得するためのポーリング間隔を求めている。そのため、例えば前回求めたポーリング間隔よりも短い間隔でコンテンツデータの更新が行われていても、コンピュータ１０１側で、当該コンテンツデータが更新されたタイミングを知ることができる。したがって、前回のポーリング間隔より短い間隔でコンテンツデータの次の更新が行われていても、次に状態情報を取得するためのタイミングを適切に求めることができる。

また、この実施形態によれば、コンピュータ１０１は、サーバ装置１０２が持つコンテンツデータが更新されたか否かを、当該サーバ装置１０２が当該コンテンツデータの更新履歴に基づき生成した状態情報を用いて判断している。そのため、コンピュータ１０１は、サーバ装置１０２に繰り返しアクセスして当該コンテンツデータに対するアクセス履歴や当該コンテンツデータの更新日時をコンピュータ１０１側に蓄積しなくても、次に状態情報を取得するためのタイミングを求めることができる。

図６〜図８を用いて、本発明の実施形態によるデータ状態情報の一例の取得処理についてより具体的に説明する。図６は、コンピュータ１０１側の一例の処理を示すフローチャートである。図７は、図６のフローチャートによる処理に対応してサーバ装置１０２側で行われる一例の処理を示すフローチャートである。また、図８は、サーバ装置１０２からコンピュータ１０１に送信される一例の状態情報を概略的に示す。

図６において、ステップＳ２０で、ＣＰＵ２１０により、コンピュータ１０１に登録されているリンク管理情報５００の数が取得されると共に、ループ変数が初期化され０とされる。ステップＳ２１で、ＣＰＵ２１０により、ループ変数とリンク管理情報５００の登録数とが比較される。比較の結果、登録数よりもループ変数の方が小さければ、処理はステップＳ２２に移行される。

ステップＳ２２では、ループ変数に対応するリンク管理情報５００が処理対象としてＣＰＵ２１０に取得される。処理はステップＳ２３に移行され、ステップＳ２２で取得されたリンク管理情報５００における状態情報取得予定日時５０６と、処理日時すなわち現在の日時とが比較される。若し、状態情報取得予定日時５０６が処理日時よりも過去を示しているか、または、状態情報取得予定日時５０６と処理日時とが一致する場合には、処理はステップＳ２４に移行される。一方、状態情報取得予定日時５０６が処理日時よりも未来を示していれば、処理は後述するステップＳ３０に移行される。

ステップＳ２４では、処理対象のリンク管理情報５００における、コンテンツデータの状態情報を示すリンク情報５０４が参照され、このリンク情報５０４が指し示すＵＲＩに対してリクエストを行う。このリクエストを受けたサーバ装置１０２は、受けたリクエストに応じて、図７に一例が示される処理を行う。

図７を参照し、サーバ装置１０２は、リクエストに基づきデータ管理情報４００を識別する（ステップＳ４０）。例えば、データ管理情報４００が有するデータ識別情報がＵＲＩであれば、リクエストを受けたＵＲＩに一致するデータ識別情報を有するデータ管理情報４００を検索する。次のステップＳ４１で、サーバ装置１０２は、識別されたデータ管理情報４００に関連付けられているデータ更新情報４０１を取得する。そして、取得したデータ更新情報４０１に基づき状態情報を生成し（ステップＳ４２）、生成された状態情報を、リクエストの送信元であるコンピュータ１０１に返す。

なお、サーバ装置１０２は、コンテンツデータの更新が行われる度に状態情報を生成するようにしてもよい。生成された状態情報は、ファイルとしてサーバ装置１０２に保持される。この場合、サーバ装置１０２は、図６のフローチャートにおけるステップＳ２４により、コンピュータ１０１から状態情報がリクエストされた際に、このファイルを参照する。

図８は、サーバ装置１０２からコンピュータ１０１に送信される状態情報の一例の構成を示す。この図８の例では、状態情報がＸＭＬを用いて記述されている。タグ<UPDATE>およびタグ</UPDATE>により、このデータがコンテンツデータの更新日時に関するものであることが示される。また、タグ<DATE>およびタグ</DATE>で挟まれた部分に、データ更新情報４０１における更新日時を示す情報が列挙される。

この図８の例では、この状態情報に対応するコンテンツデータがサーバ装置１０２に登録されて以降、最初の更新日時を２００７年１月１日の０時として、登録後に２５時間周期で４回、更新が行われていることが示されている。

なお、図８の例では、ＸＭＬを用いて状態情報を記述しているが、これはこの例に限定されず、他の形式で更新履歴を記述して状態情報としてもよい。更新履歴情報と他の情報とを纏めて状態情報としてもよいし、コンテンツデータに更新履歴情報を埋め込んでおくことも考えられる。また、更新日時のフォーマット、ＸＭＬのタグ名などは一例であって、他のフォーマット、他のタグ名を用いてもよい。

説明は図６のフローチャートに戻り、コンピュータ１０１は、サーバ装置１０２から返された状態情報を受け取る（ステップＳ２４）。コンピュータ１０１がコンテンツデータの状態情報を取得すると、処理はステップＳ２５に移行される。ステップＳ２５では、取得した状態情報と、処理対象のリンク管理情報５００における情報取得日時５０５とに基づき、情報取得日時５０５に示される日時から処理日時までの間に、当該状態情報に対応するコンテンツデータの更新が行われたか否かが判断される。

若し、コンテンツデータの更新が行われなかったと判断されれば、処理はステップＳ２９に移行される。ステップＳ２９では、コンピュータ１０１において、ポーリング間隔が予め決められた固定値に設定される。これに限らず、ユーザがコンピュータ１０１に対して指定した値をポーリング間隔として用いてもよい。ポーリング間隔が設定されると、設定されたポーリング間隔に基づき状態情報取得予定日時が決定される。そして、処理は後述するステップＳ３０に移行される。

一方、ステップＳ２５でコンテンツデータの更新が行われたと判断されれば、処理はステップＳ２６に移行される。ステップＳ２６では、コンテンツデータの更新があったことが、例えばコンピュータ１０１の表示装置２１４に対する所定の表示によって、ユーザに通知される。これに限らず、コンピュータ１０１が有するデータベースなどに自動的に登録するようにしてもよい。ユーザへの更新の通知がなされると、処理はステップＳ２７に移行される。

ステップＳ２７では、コンピュータ１０１において、受信された状態情報が解析され、当該コンテンツデータの状態情報を次に要求するためのポーリング間隔が求められる。ポーリング間隔が求められると、処理はステップＳ２８に移行される。ステップＳ２８では、求められたポーリング間隔から、当該コンテンツデータの状態情報を次に要求する予定のタイミングを示す日時である、状態情報取得予定日時が求められる。例えば、状態情報から、コンテンツデータに対してなされた最新の更新日時を示す最新更新日時を求め、この最新更新日時に対してステップＳ２７で求められたポーリング間隔が示す時間を加算して、状態情報取得予定日時を求める。求められた状態情報取得予定日時は、例えばＲＡＭ２１１に記憶される。

ステップＳ２８で状態情報取得予定日時が求められたら、処理はステップＳ３０に移行され、ループ変数がインクリメントされる。そして、処理がステップＳ２１に戻され、次のリンク管理情報５００に対して同様の処理がなされる。この処理により得られた状態情報取得予定日時は、例えばＲＡＭ２１１に順次、記憶される。

上述したステップＳ２１で、ループ変数がリンク管理情報５００の登録数以上の値になったら、処理はステップＳ３１に移行される。ステップＳ３１では、ステップＳ２８で取得された状態情報取得予定日時のうち、最も処理日時に近い日時を示す状態情報取得予定日時を選択する。選択された状態情報取得予定日時は、リンク管理情報５００における新たな状態情報取得予定日時５０６に決定される。そして、処理はステップＳ３２に移行され、この新たな状態情報取得予定日時５０６に上述のステップＳ２０からの処理を開始するように、コンピュータ１０１のタイマ設定を行う。

一例として、コンピュータ１０１において、上述した図８に例示される状態情報に対応するリンク情報の登録が、状態情報の最新の更新日時である２００７年１月５日の４時以降に行われたとする。コンピュータ１０１は、サーバ装置１０２へのこの状態情報に関する初回のアクセスで、この状態情報を取得することができる。この取得された状態情報には、対応するコンテンツデータの更新日時が履歴として記述されている。そのため、コンピュータ１０１は、取得した状態情報に基づきコンテンツデータの更新周期を算出することができる。したがって、コンピュータ１０１は、サーバ装置１０２への次回のアクセス時期を適応的に設定することができる。

更新周期は、例えば更新履歴から求めた更新間隔の平均値を用いることができる。この場合、更新履歴に記述される最新の更新日時に対して更新周期の値を加算した日時を、状態情報取得予定日時５０６として用いることができる。

更新周期の算出方法としては、他にも、更新履歴に基づく線形近似や、パターン比較が考えられる。また、最新の更新日時と最新の更新の１つ前の更新による更新日時との差分から、更新周期を求めるようにしてもよい。この場合には、最新の更新日時に対してこの差分を加算した日時を、状態情報取得予定日時５０６として用いることが考えられる。

コンピュータ１０１は、上述したようにして取得された状態情報に基づき、対応するコンテンツデータの更新の有無を判断することができる。そして、この判断結果に基づき、更新のあったコンテンツデータに選択的にアクセスすることで、インターネット１００上に分散的に存在するコンテンツデータを、効率的に収集することができる。

なお、上述では、コンテンツデータをＲＳＳフィードとして説明したが、これはこの例に限定されるものではない。例えば、ＲＳＳデータにおいてアイテム要素として記述される各リソースをコンテンツデータとして扱うことも可能である。この場合、サーバ装置１０２は、アイテム要素について、データ管理情報４００およびデータ更新情報４０１を持つことになる。同様に、コンピュータ１０１が持つリンク管理情報５００において、例えばデータのリンク情報５０３は、アイテム要素として記述されるリソースのＵＲＩとなる。

また、ＲＳＳ２．０のように、ＲＳＳのタグを拡張できる場合がある。この場合は、ＲＳＳデータ中に更新履歴を拡張して設定することで、ＲＳＳデータそのものの取得で更新履歴も取得できることになる。

さらに、上述では、コンピュータ１０１において、登録された複数のリンク管理情報５００について１つの状態情報取得予定日時を選択するように説明したが、これはこの例に限定されない。すなわち、複数のリンク管理情報５００のそれぞれについて、状態情報取得予定日時を決定することができる。例えば、ステップＳ２４からステップＳ２８またはステップＳ２９の処理を行う度に決定された状態情報取得予定日時のそれぞれについて、タイマを設定する。こうすることで、コンピュータ１０１において、コンテンツデータ毎にポーリング間隔を設定することができる。

＜第１の変形例＞
次に、本発明の実施形態の第１の変形例について説明する。第１の変形例では、コンピュータ１０１からサーバ装置１０２に対してコンテンツデータの状態情報をリクエストする際に、コンピュータ１０１がサーバ装置１０２から当該コンテンツデータの状態情報を前回取得した日時を示す情報をリクエストと共に送信する。

図９〜図１１を用いて、この第１の変形例によるデータ状態情報の一例の取得処理について説明する。図９は、この第１の変形例による、コンピュータ１０１側がリンク情報を管理するために持つ管理情報の一例の構成を示す。図１０は、コンピュータ１０１側の一例の処理を示すフローチャートである。図１１は、図１０のフローチャートによる処理に対応してサーバ装置１０２側で行われる一例の処理を示すフローチャートである。

図９に例示されるように、この第１の変形例においては、図５で説明したのと同様のリンク管理情報５００に対して、当該リンク管理情報５００の更新日時を示す管理情報更新情報５１０が関連付けられて構成される。

図１０を用いて、コンピュータ１０１側の一例の処理について説明する。図１０に例示される処理は、上述した図６のフローチャートにおけるステップＳ２４〜ステップＳ２９の処理に対応する。以下、第１の変形例によるコンピュータ１０１側の処理は、上述した図６のフローチャートによるステップＳ２４〜ステップＳ２９の処理を、図１０のフローチャートによるステップＳ１００〜ステップＳ１０９の処理で置き換えたものと見做す。

図１０のフローチャートによる処理に先立って、コンピュータ１０１において、上述した図６のフローチャートにおけるステップＳ２０〜ステップＳ２３の処理が行われる。先ず、ループ変数の初期化やリンク管理情報５００の登録数が取得される（ステップＳ２０）。さらに、リンク管理情報５００が取得され（ステップＳ２２）、取得されたリンク管理情報５００における状態情報取得予定日時５０６と、処理日時とが比較される（ステップＳ２３）。状態情報取得予定日時５０６が処理日時よりも過去を示しているか、または、状態情報取得予定日時５０６とが一致すると判断されれば、処理は図１０のステップＳ１００に移行される。

コンピュータ１０１は、ステップＳ１００で、上述した図６のステップＳ２２で取得されたリンク管理情報５００における情報取得日時５０５を取得する。すなわち、ステップＳ１００では、コンピュータ１０１は、状態情報をリクエストしようとするコンテンツデータについて、前回、状態情報のリクエストを行った日時を示す情報を取得する。

コンピュータ１０１は、情報取得日時５０５を確認し、当該コンテンツデータに関して過去に状態情報を取得したことがあると判断されれば、処理はステップＳ１０２に移行される。ステップＳ１０２では、図６のステップＳ２２で取得されたリンク管理情報５００におけるリンク情報５０４が参照され、このリンク情報５０４が指し示すＵＲＩに対して情報状態をリクエストする。このとき、リクエストに対して、ステップＳ１００で取得された情報取得日時５０５が付加されてサーバ装置１０２に送信される。

一方、ステップＳ１０１で、当該コンテンツデータに関して過去に状態情報を取得したことがないと判断されれば、処理はステップＳ１０３に移行される。ステップＳ１０３では、図６のステップＳ２２で取得されたリンク管理情報５００におけるリンク情報５０４が参照され、このリンク情報５０４が指し示すＵＲＩに対して情報状態をリクエストする。このとき、情報取得日時５０５は、付加されない。

ステップＳ１０２またはステップＳ１０３による、コンピュータ１０１からの状態情報のリクエストに応じて、サーバ装置１０２は、図１１に一例が示される処理を行う。すなわち、サーバ装置１０２は、リクエストに基づきデータ管理情報４００を識別する（ステップＳ１２０）。データ管理情報４００が有するデータ識別情報がＵＲＩであれば、リクエストを受けたＵＲＩに一致するデータ識別情報を有するデータ管理情報４００を検索する。次のステップＳ１２１で、サーバ装置１０２は、識別されたデータ管理情報４００に関連付けられているデータ更新情報４０１を取得する。

そして、次のステップＳ１２２で、コンピュータ１０１から送信された、状態情報のリクエストに情報取得日時５０５が付加されているか否かが判断される。若し、情報取得日時５０５が付加されていないと判断されれば、処理はステップＳ１２３に移行される。ステップＳ１２３では、ステップＳ１２１で取得されたデータ更新情報４０１を全て用いて、状態情報が生成される。生成された状態情報は、リクエストの送信元であるコンピュータ１０１に返される。

一方、ステップＳ１２２で、状態情報のリクエストに情報取得日時５０５が付加されていると判断されれば、処理はステップＳ１２４に移行される。ステップＳ１２４では、ステップＳ１２１で取得されたデータ更新情報４０１のうち、リクエストに付加された情報取得日時５０５よりも時間的に後の日時を示すデータ更新情報を用いて、状態情報が生成される。生成された状態情報は、リクエストの送信元であるコンピュータ１０１に返される。

説明は図１０のフローチャートに戻り、コンピュータ１０１は、サーバ装置１０２から返された状態情報を受け取る。そして、取得した状態情報と、リンク管理情報５００の情報取得日時５０５とに基づき、情報取得日時５０５に示される日時から処理日時までの間に、当該状態情報に対応するコンテンツデータの更新が行われたか否かが判断される（ステップＳ１０４）。

若し、コンテンツデータの更新が行われなかったと判断されれば、処理はステップＳ１０９に移行される。例えば、取得した状態情報にデータ更新を行った日時を示す情報が含まれていなければ、コンテンツデータの更新が行われなかったと判断することができる。ステップＳ１０９では、コンピュータ１０１において、ポーリング間隔が予め決められた固定値に設定される。これに限らず、ユーザがコンピュータ１０１に対して指定した値をポーリング間隔として用いてもよい。ポーリング間隔が設定されると、設定されたポーリング間隔に基づき状態情報取得予定日時が決定される。そして、処理は図１０のフローチャートによる一連の処理を抜け、図６のステップＳ３０に移行される。

一方、ステップＳ１０４でコンテンツデータの更新が行われたと判断されれば、処理はステップＳ１０６に移行される。ステップＳ１０６では、コンテンツデータの更新があったことが、例えばコンピュータ１０１の表示装置２１４に対する所定の表示によって、ユーザに通知される。これに限らず、コンピュータ１０１が有するデータベースなどに自動的に登録するようにしてもよい。ユーザへの更新の通知がなされると、処理はステップＳ１０７に移行される。

ステップＳ１０７では、コンピュータ１０１において、受信された状態情報が解析され、当該コンテンツデータの状態情報を次に要求するためのポーリング間隔が求められる。そして、処理はステップＳ１０８に移行され、求められたポーリング間隔から、当該コンテンツデータの状態情報を次に要求する予定のタイミングを示す日時である、状態情報取得予定日時が求められる。求められた状態情報取得予定日時は、例えばＲＡＭ２１１に記憶される。そして、処理は図１０のフローチャートによる一連の処理を抜け、図６のステップＳ３０に移行される。

上述したように、この第１の変形例では、コンピュータ１０１は、あるコンテンツデータについて状態情報をリクエストする際に、当該コンテンツデータに関して前回、状態情報を取得した日時を示す情報取得日時５０５をリクエストに付加する。そして、サーバ装置１０２側では、リクエストに付加された情報取得日時５０５に基づき、当該情報取得日時５０５より新しいデータ更新情報に基づき状態情報を生成するようにしている。そのため、サーバ装置１０２から送信される状態情報のデータサイズが小さくなり、インターネット１００上のトラフィックに対する負荷を軽減させることができる。

＜第２の変形例＞
次に、この実施形態の第２の変形例について、図１２および図１３を用いて説明する。この第２の変形例は、サーバ装置１０２において、コンテンツデータの更新履歴情報に基づきコンテンツデータの平均更新間隔を求め、この平均更新間隔を用いて状態情報を生成する例である。

図１２は、この第２の変形例によりサーバ装置１０２が状態情報を生成する際の一例の処理を示すフローチャートである。サーバ装置１０２は、図６のステップＳ２４によるコンピュータ１０１からのリクエストに基づき、データ管理情報４００を識別する（ステップＳ５０）。データ管理情報４００が有するデータ識別情報がＵＲＩであれば、リクエストを受けたＵＲＩに一致するデータ識別情報を有するデータ管理情報４００を検索する。次のステップＳ５１で、サーバ装置１０２は、識別されたデータ管理情報４００に関連付けられているデータ更新情報４０１を取得する。

次のステップＳ５２で、取得したデータ更新情報４０１に基づきコンテンツデータを更新した間隔の平均値を求める。そして、求められた平均更新間隔を示す情報を用いて状態情報を生成する。生成された状態情報は、サーバ装置１０２により、リクエストの送信元であるコンピュータ１０１に返される。

図１３は、図１２のフローチャートに従い生成された一例の状態情報を示す。この図１３の例では、状態情報がＸＭＬを用いて記述されている。タグ<UPDATE>およびタグ</UPDATE>により、このデータがコンテンツデータの更新情報に関するものであることが示される。また、タグ<LAST_UPDATE>およびタグ</LAST_UPDATE>で挟まれた部分に、対応するコンテンツデータのサーバ装置１０２上での最新の更新日時を示す情報が記述される。さらに、タグ<AVERAGE>およびタグ</AVERAGE>に挟まれた部分に、コンテンツデータの平均更新間隔を示す情報が記述される。

この図１３の例では、この状態情報に対応するコンテンツデータがサーバ装置１０２上で最新に更新されたのが２００７年１月５日の４時であって、平均して２５時間の間隔でコンテンツデータの更新が行われたことが示されている。

一例として、コンピュータ１０１において、上述した図１３に例示される状態情報に対応するリンク情報の登録が最新の更新日時である２００７年１月５日の４時以降に行われたとする。コンピュータ１０１は、コンピュータ１０１からサーバ装置１０２への初回のアクセスでこの状態情報を取得することができる。この取得された状態情報には、対応するコンテンツデータの最新の更新日時を示す情報と、平均の更新間隔を示す情報が記述されている。

コンピュータ１０１は、状態情報に記述される平均の更新間隔をコンテンツデータの更新周期として用いることができる。状態情報に記述される最新の更新日時に対して、この更新周期の値を加算した日時を、状態情報取得予定日時５０６として用いる。取得した状態情報に基づきコンテンツデータの更新周期を算出することができる。したがって、コンピュータ１０１は、サーバ装置１０２への次回のアクセス時期を適応的に設定することができる。

＜第３の変形例＞
次に、この実施形態の第３の変形例について、図１４および図１５を用いて説明する。この第３の変形例は、サーバ装置１０２において、コンテンツデータについて、最新の更新日時、更新回数および更新回数の基点を示す日時を示す情報を求め、これらの情報を用いて状態情報を生成する例である。

図１４は、この第３の変形例によりサーバ装置１０２が状態情報を生成する際の一例の処理を示すフローチャートである。サーバ装置１０２は、図６のステップＳ２４によるコンピュータ１０１からのリクエストに基づき、データ管理情報４００を識別する（ステップＳ６０）。例えば、データ管理情報４００が有するデータ識別情報がＵＲＩであれば、リクエストを受けたＵＲＩに一致するデータ識別情報を有するデータ管理情報４００を検索する。次のステップＳ６１で、サーバ装置１０２は、識別されたデータ管理情報４００に関連付けられているデータ更新情報４０１を取得する。

次のステップＳ６２で、取得したデータ更新情報４０１に基づき、コンテンツデータについて、最新の更新日時、更新回数および更新回数を計数する基点となる日時を示す情報をそれぞれ求める。そして、これらコンテンツデータの最新の更新日時、更新回数および更新回数の基点となる日時を示す情報を用いて状態情報を生成する。生成された状態情報は、サーバ装置１０２により、リクエストの送信元であるコンピュータ１０１に返される。

図１５は、図１４のフローチャートに従い生成された一例の状態情報を示す。この図１５の例では、状態情報がＸＭＬを用いて記述されている。タグ<UPDATE>およびタグ</UPDATE>により、このデータがコンテンツデータの更新情報に関するものであることが示される。また、タグ<LAST_UPDATE>およびタグ</LAST_UPDATE>で挟まれた部分に、対応するコンテンツデータの最新の更新日時を示す情報が記述される。さらに、タグ<BASE>およびタグ</BASE>に挟まれた部分に、更新回数の基点となる日時を示す情報が記述される。さらにまた、タグ<COUNT>およびタグ</COUNT>に挟まれた部分に、更新回数を示す情報が記述される。

この図１５の例では、この状態情報に対応するコンテンツデータの最新の更新日時が２００７年１月５日の４時であって、更新回数の基点が２００７年１月１日の０時とされている。したがって、当該コンテンツデータに対し、更新回数の基点となる日時から最新の更新日時までの間に４回の更新が行われたことが示されている。

一例として、コンピュータ１０１において、上述した図１５に例示される状態情報に対応するリンク情報の登録が最新の更新日時である２００７年１月５日の４時以降に行われたとする。コンピュータ１０１は、コンピュータ１０１からサーバ装置１０２への初回のアクセスでこの状態情報を取得することができる。この取得された状態情報には、対応するコンテンツデータの最新の更新日時、更新回数および更新回数の基点となる日時を示す情報が記述されている。

コンピュータ１０１は、状態情報に記述されるコンテンツデータの最新の更新日時と更新回数の基点となる日時との差分を更新回数で除して、これら最新の更新日時と更新回数の基点となる日時との間における平均の更新間隔を求める。この平均の更新間隔を更新周期と見做して、状態情報に記述される最新の更新日時に対してこの更新周期の値を加算した日時を、状態情報取得予定日時５０６として用いることができる。したがって、コンピュータ１０１は、サーバ装置１０２への次回のアクセス時期を適応的に設定することができる。

＜第４の変形例＞
次に、この実施形態の第４の変形例について、図１６および図１７を用いて説明する。この第４の変形例は、サーバ装置１０２において、コンテンツデータについて、最新の更新日時を示す情報と、この最新の更新日時による更新に対して１回前に行われた更新日時を示す情報とを求め、これらの情報を用いて状態情報を生成する例である。

図１６は、この第４の変形例によりサーバ装置１０２が状態情報を生成する際の一例の処理を示すフローチャートである。サーバ装置１０２は、図６のステップＳ２４によるコンピュータ１０１からのリクエストに基づき、データ管理情報４００を識別する（ステップＳ７０）。データ管理情報４００が有するデータ識別情報がＵＲＩであれば、リクエストを受けたＵＲＩに一致するデータ識別情報を有するデータ管理情報４００を検索する。次のステップＳ７１で、サーバ装置１０２は、識別されたデータ管理情報４００に関連付けられているデータ更新情報４０１を取得する。

次のステップＳ７２で、取得したデータ更新情報４０１に基づき、コンテンツデータについて、最新の更新日時を示す情報と、この最新の更新日時による更新に対して１回前に行われた更新の更新日時を示す情報とを求める。そして、これらコンテンツデータの最新の更新日時を示す情報と、最新の更新日時による更新に対して１回前に行われた更新の更新日時を示す情報とを用いて状態情報を生成する。生成された状態情報は、サーバ装置１０２により、リクエストの送信元であるコンピュータ１０１に返される。

図１７は、図１６のフローチャートに従い生成された一例の状態情報を示す。この図１７の例では、状態情報がＸＭＬを用いて記述されている。タグ<UPDATE>およびタグ</UPDATE>により、このデータがコンテンツデータの更新情報に関するものであることが示される。また、タグ<LAST_UPDATE>およびタグ</LAST_UPDATE>で挟まれた部分に、対応するコンテンツデータの最新の更新日時を示す情報が記述される。さらに、タグ<PREV_UPDATE>およびタグ</PREV_UPDATE>に挟まれた部分に、最新の更新日時による更新の１回前に行われた更新の更新日時を示す情報が記述される。

この図１７の例では、この状態情報に対応するコンテンツデータの最新の更新日時が２００７年１月５日の４時であって、この最新の更新日時による更新の１回前の更新が２００７年１月４日の３時に行われたことが示されている。これにより、当該コンテンツに対する最新の更新は、最新の更新の１回前の更新から２５時間後に行われたことが分かる。

一例として、コンピュータ１０１において、上述した図１７に例示される状態情報に対応するリンク情報の登録が最新の更新日時である２００７年１月５日の４時以降に行われたとする。コンピュータ１０１は、コンピュータ１０１からサーバ装置１０２への初回のアクセスでこの状態情報を取得することができる。この取得された状態情報には、対応するコンテンツデータの最新の更新日時を示す情報と、当該最新の更新日時の１つ前の更新日時を示す情報とが記述されている。

コンピュータ１０１は、取得した状態情報に基づき、最新の更新日時と最新の更新の１つ前の更新による更新日時との差分を求め、最新の更新日時に対してこの差分を加算した日時を、状態情報取得予定日時５０６として用いる。このように、コンピュータ１０１は、サーバ装置１０２への次回のアクセス時期を適応的に設定することができる。

＜第５の変形例＞
次に、この実施形態の第５の変形例について、図１８および図１９を用いて説明する。この第５の変形例は、サーバ装置１０２において、コンテンツデータを次に更新することが予測される日時（予測更新日時と呼ぶ）を求め、この予測更新日時を示す情報と、コンテンツデータの最新の更新日時を示す情報とを用いて状態情報を生成する例である。

図１８は、この第５の変形例によりサーバ装置１０２が状態情報を生成する際の一例の処理を示すフローチャートである。サーバ装置１０２は、図６のステップＳ２４によるコンピュータ１０１からのリクエストに基づき、データ管理情報４００を識別する（ステップＳ８０）。データ管理情報４００が有するデータ識別情報がＵＲＩであれば、リクエストを受けたＵＲＩに一致するデータ識別情報を有するデータ管理情報４００を検索する。次のステップＳ８１で、サーバ装置１０２は、識別されたデータ管理情報４００に関連付けられているデータ更新情報４０１を取得する。

次のステップＳ８２で、サーバ装置１０２は、取得したデータ更新情報４０１に基づき予測更新日時を求める。一例として、サーバ装置１０２は、取得したデータ更新情報４０１から更新間隔の平均値を求め、この更新間隔の平均値を最新の更新日時に加算した日時を、予測更新日時とすることが考えられる。データ更新情報４０１から線形近似を用いて、予測更新日時を求めるようにしてもよい。

これに限らず、データ更新情報４０１からコンテンツデータの更新パターンを求め、求められた更新パターンに基づき予測更新日時を求めるようにもできる。この場合、求められた更新パターンと予め用意されたパターンとを比較して予測更新日時を求めることが考えられる。また、最新の更新日時と、最新の更新日時による更新に対して１回前に行われた更新の更新日時とを比較して、これらの差分に基づき予測更新日時を求めるようにしてもよい。

サーバ装置１０２は、求められた予測更新日時を示す情報と、コンテンツデータの最新の更新日時を示す情報とを用いて状態情報を生成する（ステップＳ８３）。生成された状態情報は、サーバ装置１０２により、リクエストの送信元であるコンピュータ１０１に返される。

図１９は、図１８のフローチャートに従い生成された一例の状態情報を示す。この図１９の例では、状態情報がＸＭＬを用いて記述されている。タグ<UPDATE>およびタグ</UPDATE>により、このデータがコンテンツデータの更新情報に関するものであることが示される。また、タグ<LAST_UPDATE>およびタグ</LAST_UPDATE>で挟まれた部分に、対応するコンテンツデータの最新の更新日時を示す情報が記述される。さらに、タグ<PREDICTION_DATE>およびタグ</PREDICTION_UPDATE>に挟まれた部分に、予測更新日時を示す情報が記述される。

この図１９の例では、この状態情報に対応するコンテンツデータの最新の更新日時が２００７年１月５日の４時であって、次の更新が２００７年１月６日の５時に行われると予測されることが示されている。

一例として、コンピュータ１０１において、上述した図１９に例示される状態情報に対応するリンク情報の登録が最新の更新日時である２００７年１月５日の４時以降に行われたとする。コンピュータ１０１は、コンピュータ１０１からサーバ装置１０２への初回のアクセスでこの状態情報を取得することができる。この取得された状態情報には、対応するコンテンツデータが次に更新が行われると予測される、予測更新日時を示す情報が記述されている。そのため、コンピュータ１０１は、サーバ装置１０２への次回のアクセス時期を適切に設定することができる。

＜第６の変形例＞
次に、この実施形態の第６の変形例について説明する。この第６の変形例では、サーバ装置１０２において、ポーリングを行う間隔として、第１の間隔および第１の間隔より長い間隔の第２の間隔またはこれらのうち何れか一方を予め定める。第１の間隔は、ポーリングを行う最短の間隔を示し、第２の間隔は、ポーリングを行う最長の間隔を示す。以下、第１の間隔を最短間隔、第２の間隔を最長間隔として説明を行う。サーバ装置１０２は、このポーリングの最短間隔や最長間隔を示す情報を、コンピュータ１０１からのリクエストに応じて生成した状態情報に付加してコンピュータ１０１に返す。

コンピュータ１０１は、サーバ装置１０２から取得された状態情報に基づきポーリング間隔を求め、求められたポーリング間隔が、状態情報に付加された最短間隔より短ければ、当該最短間隔をポーリング間隔に再設定する。同様に、状態情報に基づき求められたポーリング間隔が、状態情報に付加された最長間隔より長ければ、当該最長間隔をポーリング間隔に再設定する。コンテンツデータの更新間隔が極端に短い場合や、極端に長い場合でも、ポーリング間隔を設定することができる。

図２０は、この第６の変形例によるコンピュータ１０１側の一例の処理を示すフローチャートである。図２０に例示される処理は、上述した図６のフローチャートにおけるステップＳ２４〜ステップＳ２９の処理に対応する。以下では、第６の変形例でのコンピュータ１０１側の処理は、上述した図６のフローチャートによるステップＳ２４〜ステップＳ２９の処理を、図２０のフローチャートによるステップＳ１３０〜ステップＳ１３９の処理で置き換えたものと見做す。

図２０のフローチャートによる処理に先立って、コンピュータ１０１において、上述した図６のフローチャートにおけるステップＳ２０〜ステップＳ２３の処理が行われる。先ず、ループ変数の初期化やリンク管理情報５００の登録数が取得される（ステップＳ２０）。さらに、リンク管理情報５００が取得され（ステップＳ２２）、取得されたリンク管理情報５００における状態情報取得予定日時５０６と、処理日時とが比較される（ステップＳ２３）。状態情報取得予定日時５０６が処理日時よりも過去を示しているか、または、状態情報取得予定日時５０６とが一致すると判断されれば、処理は図２３のステップＳ１３０に移行される。

コンピュータ１０１は、ステップＳ１３０で、上述のステップＳ２２で取得されたリンク管理情報５００における、コンテンツデータの状態情報を示すリンク情報５０４を参照する。そして、このリンク情報５０４が指し示すＵＲＩに対してリクエストを行う。サーバ装置１０２は、このリクエストに対して、図７を用いて説明したような処理により状態情報を生成する。そして、生成された状態情報に対して、ポーリングの最短間隔および最長間隔またはこれらのうち何れか一方の情報を付加してリクエストの送信元であるコンピュータ１０１に送信する。

図２１は、この第６の変形例においてサーバ装置１０２からコンピュータ１０１に対して送信される状態情報の一例の構成を示す。タグ<UPDATE>およびタグ</UPDATE>により、これらのタグで挟まれた部分にコンテンツデータの更新情報に関する情報が記述されることが示される。そして、タグ<DATE>およびタグ</DATE>で挟まれた部分に、データ更新情報４０１における更新日時を示す情報が列挙される。また、タグ<UPDATE>およびタグ</UPDATE>に対して、タグ<POLLING>およびタグ</POLLING>が付加される。このタグ<POLLING>およびタグ</POLLING>により、これらのタグで挟まれた部分にポーリングに関する情報が記述されることが示される。そして、タグ<MAX>およびタグ</MAX>で挟まれた部分に、ポーリングの最長間隔を示す情報が記述される。そして、タグ<MIN>およびタグ</MIN>で挟まれた部分に、ポーリングの最短間隔を示す情報が記述される。

この図２１の例では、この状態情報に対応するコンテンツデータがサーバ装置１０２に登録されて以降、最初の更新日時を２００７年１月３日の２時として、登録後に２５時間周期で３回、更新が行われていることが示されている。また、ポーリングの最長間隔および最短間隔がそれぞれ４８時間および１０分とされていることが示されている。

コンピュータ１０１は、サーバ装置１０２から返された状態情報を受け取ると、処理をステップＳ１３１に移行させる。ステップＳ１３１では、取得した状態情報と、リンク管理情報５００の情報取得日時５０５とに基づき、情報取得日時５０５に示される日時から処理日時までの間に、当該状態情報に対応するコンテンツデータの更新が行われたか否かが判断される。

若し、コンテンツデータの更新が行われなかったと判断されれば、処理はステップＳ１３９に移行され、コンピュータ１０１において、ポーリング間隔が予め決められた固定値に設定される。これに限らず、ユーザがコンピュータ１０１に対して指定した値をポーリング間隔として用いてもよい。ポーリング間隔が設定されると、設定されたポーリング間隔に基づき状態情報取得予定日時が決定される。そして、処理は図２０による一連の処理を抜け、図６のステップＳ３０に移行される。

一方、ステップＳ１３１でコンテンツデータの更新が行われたと判断されれば、処理はステップＳ１３２に移行される。ステップＳ１３２では、コンテンツデータの更新があったことが、例えばコンピュータ１０１の表示装置２１４に対する所定の表示によって、ユーザに通知される。これに限らず、コンピュータ１０１が有するデータベースなどに自動的に登録するようにしてもよい。ユーザへの更新の通知がなされると、処理はステップＳ１３３に移行される。

ステップＳ１３３では、コンピュータ１０１において、受信された状態情報が解析され、当該コンテンツデータの状態情報を次に要求するためのポーリング間隔が求められる。そして、処理はステップＳ１３４に移行され、受信した状態情報に付加されたポーリング最短間隔と、ステップＳ１３３で求められたポーリング間隔とが比較される。比較の結果、若し、ステップＳ１３３で求められたポーリング間隔が、状態情報に付加されたポーリング最短間隔よりも短い間隔であると判断されたら、処理はステップＳ１３６に移行される。ステップＳ１３６では、ポーリング間隔が、状態情報に付加されたポーリング最短間隔に再設定される。ポーリング間隔が設定されると、処理は後述するステップＳ１３８に移行される。

一方、ステップＳ１３４で、ステップＳ１３３で求められたポーリング間隔が、状態情報に付加されたポーリング最短間隔よりも長い間隔であると判断されたら、処理はステップＳ１３５に移行される。ステップＳ１３５では、状態情報に付加されたポーリング最長間隔と、ステップＳ１３３で求められたポーリング間隔とが比較される。比較の結果、若し、ステップＳ１３３で求められたポーリング間隔が、状態情報に付加されたポーリング最長間隔よりも長いと判断されたら、処理はステップＳ１３７に移行される。ステップＳ１３７では、ポーリング間隔が、状態情報に付加されたポーリング最長間隔に再設定される。ポーリング間隔が設定されると、処理はステップＳ１３８に移行される。

ステップＳ１３８では、ステップＳ１３４〜ステップＳ１３７の処理で求められたポーリング間隔から、当該コンテンツデータの状態情報を次に要求する予定のタイミングを示す日時である、状態情報取得予定日時が求められる。例えば、前回、状態情報を取得した日時に対してポーリング間隔が示す日時を加算することで、状態情報取得予定日時を求めることができる。求められた状態情報取得予定日時は、例えばＲＡＭ２１１に記憶される。そして、処理は図２０のフローチャートによる一連の処理を抜け、図６のステップＳ３０に移行される。

なお、この第６の変形例は、上述した実施形態および実施形態の第１乃至第５の変形例と組み合わせて実施することが可能である。

＜第７の変形例＞
次に、この実施形態の第７の変形例について、図２２および図２３を用いて説明する。この第７の変形例は、コンピュータ１０１が持つ時刻情報と、サーバ装置１０２が持つ時刻情報とを比較し、これらの差分の時間情報に応じてポーリング間隔を調整する例である。

コンピュータ１０１側とサーバ装置１０２側との間の時間差分を考慮しないと、サーバ装置１０２側で実際にコンテンツデータの更新がなされた時刻と、コンピュータ１０１側でリンク管理情報５００で管理する日時との間で矛盾が生じる可能性がある。例えばサーバ装置１０２側の時刻がコンピュータ１０１側の時刻よりも遅いと、状態情報に基づきポーリング間隔を制御しても、ポーリングを行った時点ではサーバ装置１０２側でコンテンツデータの更新が行われていないという事態が起こり得る。

図２２は、この第７の変形例によりサーバ装置１０２が状態情報を生成する際の一例の処理を示すフローチャートである。コンピュータ１０１は、図６のステップＳ２４によりサーバ装置１０２に対して状態情報をリクエストする際に、コンピュータ１０１側の時刻を示す時刻情報をリクエストに付加する。時刻情報は、例えばコンピュータ１０１が持つ時計が示す情報を用いることができる。

サーバ装置１０２は、コンピュータ１０１から送信された、コンピュータ１０１側の時刻情報が付加された状態情報のリクエストを受け取ると、受け取ったリクエストからコンピュータ１０１側の時刻情報を取り出す。そして、取り出した時刻情報と、サーバ装置１０２側の時刻を示す時刻情報とを比較して、差分を算出する（ステップＳ９０）。

次のステップＳ９１で、サーバ装置１０２は、コンピュータ１０１からのリクエストに基づき、データ管理情報４００を識別する。データ管理情報４００が有するデータ識別情報がＵＲＩであれば、リクエストを受けたＵＲＩに一致するデータ識別情報を有するデータ管理情報４００を検索する。次のステップＳ９２で、サーバ装置１０２は、識別されたデータ管理情報４００に関連付けられているデータ更新情報４０１を取得する。

サーバ装置１０２は、ステップＳ９２で取得されたデータ更新情報４０１と、ステップＳ９０で算出されたコンピュータ１０１側とサーバ装置１０２側との時刻の差分を示す差分時刻情報とから、状態情報を生成する（ステップＳ９３）。生成された状態情報は、サーバ装置１０２からリクエストの送信元であるコンピュータ１０１に返される。

図２３は、図２２のフローチャートに従い生成された一例の状態情報を示す。この図２３の例では、状態情報がＸＭＬを用いて記述されている。タグ<UPDATE>およびタグ</UPDATE>により、このデータがコンテンツデータの更新情報に関するものであることが示される。また、タグ<DATE>およびタグ</DATE>で挟まれた部分に、データ更新情報４０１における更新日時を示す情報が列挙される。また、タグ<UPDATE>およびタグ</UPDATE>にに対して、タグ<DIFFERENCE_TIME>およびタグ</DIFFERENCE_TIME>が付加される。このタグ<DIFFERENCE_TIME>およびタグ</DIFFERENCE_TIME>で挟まれた部分に、差分時刻情報が記述される。

この図２３の例では、この状態情報に対応するコンテンツデータがサーバ装置１０２に登録されて以降、最初の更新日時を２００７年１月１日の０時として、登録後に２５時間周期で４回、更新が行われていることが示されている。また、コンピュータ１０１側の時刻とサーバ装置１０２側の時刻とで９時間の時間差があることが示されている。この状態情報を受け取ったコンピュータ１０１は、状態情報を解析して求められた状態情報取得予定日時を、この差分時刻情報に基づき調整することができる。

なお、この第７の変形例では、コンピュータ１０１からのリクエストに対しサーバ装置１０２から状態情報を返す際に差分時刻情報を送信することで、コンピュータ１０１とサーバ装置１０２との間の時刻の調整を行うようにしている。これはこの例に限られず、例えばＮＴＰ(Network Time Protocol)を用いて、コンピュータ１０１が、リンク情報５０４の示すサーバ装置１０２毎に差分時刻情報を求めるようにしてもよい。

また、この第７の変形例は、上述した実施形態および実施形態の第１乃至第６の変形例と組み合わせて実施することが可能である。

＜第８の変形例＞
次に、本実施形態の第８の変形例について、図２５〜図２８を用いて説明する。上述した実施形態および実施形態の第１〜第７の変形例は、サーバ装置１０２では常に同じ情報を管理し、ポーリングを行う複数のクライアント（コンピュータ１０１）に対して同じ情報を送信することを前提としている。

これに対して、本第８の変形例では、サーバ装置１０２から送信された状態情報に基づき、複数のクライアントがポーリング間隔および次回のポーリング時間を算出することを前提としている。そして、算出されたポーリング間隔および時間に応じて、当該複数のクライアントが同一の時間にポーリングを行うことによって発生する、サーバ装置１０２へのアクセスの集中を避けるようにしている。

図２５は、本第８の変形例に係る更新履歴の一例の管理構造を示す。本第８の変形例によるシステムでは、サーバ装置１０２が管理するコンテンツデータそれぞれを識別するためのデータ管理情報６００と、当該データ管理情報６００とＩＤ情報で関連付けられるデータ更新情報６１０とを持つ。データ管理情報６００は、管理用のＩＤ６０１、名称、コンテンツデータを識別する識別情報としてのリンク情報、当該コンテンツデータの状態情報を示すリンク情報、情報取得日時および状態情報取得予定日時からなる。

一方、データ更新情報６１０は、ＩＤ６１１と、当該ＩＤ６１１に対応するコンテンツデータの更新日時６１２と、ポーリング回数６１３とが関連付けられる。ＩＤ６１１は、データ管理情報６００における管理用のＩＤ６０１と対応する。データ更新情報６１０は、当該コンテンツデータが更新される度に追加される。ポーリング回数６１３は、コンテンツデータが更新されてからクライアントからポーリングのためのアクセスのあった回数を示す。すなわち、ポーリング回数６１３は、クライアントからサーバ装置１０２に対してなされた、状態情報の要求回数である。サーバ装置１０２は、コンピュータ１０１、１０１、…からポーリングのためのアクセスがあると、更新のあった最新にコンテンツデータに対応するデータ更新情報６１０について、ポーリング回数６１３を１ずつ加算する。

なお、図示は省略するが、データ管理情報６００に対してコンテンツデータを識別するための識別情報に加えて、当該コンテンツデータそのものを含ませてもよいし、当該コンテンツデータへのパスなどの情報を含ませることもできる。データ管理情報６００およびデータ更新情報６１０の生成や削除は、サーバ装置１０２において行われる。

図２６は、本発明の実施形態の第８の変形例によるデータ状態情報の一例の取得処理を概略的に示すフローチャートである。ステップＳ１５０で、ユーザ側のコンピュータ１０１において所定の日時になると、ポーリングにより、予め登録されたリンク情報で指定されるコンテンツデータを持つサーバ装置１０２に対して要求送信がなされる。これにより、当該コンテンツデータの状態を示す状態情報がリクエスト（要求）される。

このリクエストを受けたサーバ装置１０２は、要求のあった最新のコンテンツデータに対応するデータ更新情報６１０のポーリング回数６１３に対して、１を加算する（ステップＳ１５１）。そして、次のステップＳ１５２で、当該リクエストがあったコンテンツデータの状態情報を、当該リクエストを行ったコンピュータ１０１に返す。この状態情報は、図２５を用いて説明したように、ポーリング回数６１３を含む。

コンピュータ１０１は、受信した状態情報に基づき、対応するコンテンツデータに更新があったか否かを判断する（ステップＳ１５３）。若し、コンテンツデータに更新があったと判断されたら、処理はステップＳ１５４に移行される。また、当該コンテンツデータの状態情報に対する初回の要求であった場合も、処理はステップＳ１５４に移行される。

ステップＳ１５４では、コンテンツデータの更新があったことが、例えばコンピュータ１０１の表示装置２１４に対する所定の表示によって、ユーザに通知される。これに限らず、コンピュータ１０１が有するデータベースなどに自動的に登録するようにしてもよい。ユーザへの更新の通知がなされると、処理はステップＳ１５５に移行される。

ステップＳ１５５では、コンピュータ１０１において、受信された状態情報が解析され、当該コンテンツデータの状態情報を次にリクエストするためのポーリング間隔が求められる。そして、次のステップＳ１５６で、ステップＳ１５５で求められたポーリング間隔と、ステップＳ１５２でサーバ装置１０２から返された状態情報に含まれるポーリング回数とに基づき、次回のポーリングを行うポーリング間隔を調整する。この次回ポーリング間隔の調整処理の詳細は、後述する。

ステップＳ１５６で次回のポーリング間隔の調整が行われると、処理はステップＳ１５７に移行される。ステップＳ１５７では、調整されたポーリング間隔から、当該コンテンツデータを次にリクエストする予定のタイミングを示す日時である、状態情報取得予定日が求められる。

一方、上述のステップＳ１５３において、コンテンツデータに更新がなかったと判断されれば、処理はステップＳ１５８に移行される。ステップＳ１５８では、コンピュータ１０１において、ポーリング間隔が予め決められた固定値に設定される。これに限らず、ユーザがコンピュータ１０１に対して指定した値をポーリング間隔として用いてもよい。ポーリング間隔が設定されると、設定されたポーリング間隔に基づき、状態情報を次回取得する予定の日時が求められる。こうして求められた状態情報を次回取得する予定の日時により、状態情報取得予定日時が決定される。

コンピュータ１０１は、上述のようにしてステップＳ１５７またはステップＳ１５８で決定された状態情報取得予定日時になったら、ステップＳ１５０からの処理を再び行い、状態情報取得予定日時を更新する。

図２７は、上述したステップＳ１５６で説明した、コンピュータ１０１（クライアント）において行われるポーリング間隔の調整処理を示す一例のフローチャートである。先ず、ステップＳ１７０で、予測コンテンツ更新間隔Ｔを取得する。この予測コンテンツ更新間隔Ｔは、上述のステップＳ１５５で求められたポーリング間隔である。

次のステップＳ１７１で、予測コンテンツ更新間隔Ｔの間に予測される予測ポーリング回数Ｃを求める。この予測ポーリング回数Ｃは、例えばコンピュータ１０１において、過去に確認されたコンテンツデータの更新の履歴と、各更新間隔内になされたポーリング回数とを保持しておき、各更新間隔内のポーリング回数の平均値として求めることが考えられる。これに限らず、予測ポーリング回数Ｃは、コンテンツデータの最新の更新が行われるまでの、直前の更新からのポーリング回数を用いてもよい。

さらに、次のステップＳ１７２で、最新のコンテンツデータに対するポーリング回数Ｎ、すなわち、コンピュータ１０１が最新のコンテンツデータに対してポーリングを行った何番目のクライアントであるかを取得する。これは、ステップＳ１５２でサーバ装置１０２から返された状態情報に含まれるポーリング回数６１３に基づき取得できる。

次のステップＳ１７３で、上述の予測コンテンツ更新間隔Ｔに予測ポーリング回数Ｃ回のアクセスがあると想定して、次式（１）により、予測コンテンツ更新間隔Ｔにおいて均等にポーリングを行う場合の時間間隔Ｕを取得する。
時間間隔Ｕ＝予測コンテンツ更新間隔Ｔ／予測ポーリング回数Ｃ …（１）

次のステップＳ１７４で、最新のコンテンツデータに対するポーリング回数Ｎが予測ポーリング回数Ｃを越えているか否かが判断される。若し、越えていないと判断されれば、処理はステップＳ１７５に移行され、ポーリング回数Ｎと、ステップＳ１７３で求められた時間間隔Ｕとから、次式（２）により、ポーリング間隔の調整量Ａを求める。この調整量Ａを、ステップＳ１５５で求められたポーリング間隔に対して、例えば加算する。
調整量Ａ＝時間間隔Ｕ×ポーリング回数Ｎ …（２）

一方、ステップＳ１７４で、ポーリング回数Ｎが既に予測ポーリング回数Ｃを越えていると判断されたら、処理はステップＳ１７６に移行される。ステップＳ１７６では、ポーリング回数Ｎが予測ポーリング回数Ｃで除され、その剰余Ｒがポーリング回数Ｎと置換される。換言すれば、剰余Ｒが新たなポーリング回数Ｎとして用いられる。そして、処理はステップＳ１７５に移行され、剰余Ｒに置換されたポーリング回数Ｎを用いて、式（２）により調整量Ａが算出される。

このようにして、コンピュータ１０１毎のポーリング間隔の調整量Ａが求められる。各コンピュータ１０１、１０１、…のそれぞれにおいて、最新のコンテンツデータに対する当該コンピュータ１０１のポーリング回数Ｎに基づき調整量Ａを求めている。そのため、例えば各コンピュータ１０１、１０１、…において予測コンテンツ更新間隔Ｔが同一であっても、実際にポーリングが行われる時間は、予測コンテンツ更新間隔Ｔ内で均一的に分散され、サーバ装置１０２へのアクセスの集中が抑えられる。

なお、上述では、予測コンテンツ更新間隔Ｔをそのまま用いて調整間隔Ａを求めたが、これはこの例に限定されない。例えば、ステップＳ１５５で求められたポーリング間隔の一部の期間を予測コンテンツ更新間隔Ｔとして用いることができる。

図２８は、本第８の変形例において、サーバ装置１０２からコンピュータ１０１（クライアント）に対して送信される状態情報の一例の構成を示す。タグ<UPDATE>およびタグ</UPDATE>により、これらのタグで挟まれた部分にコンテンツデータの更新情報に関する情報が記述されることが示される。タグ<DATE ACCESS=xxxx>およびタグ</DATE>で挟まれた部分に、データ更新情報６１０における更新日時６１２を示す情報が記述される。なお、タグ<DATE ACCESS=xxxx>内の「xxxx」は、ポーリング回数６１３を示す。すなわち、タグ<DATE ACCESS=xxxx>の属性である「ACCESS=xxxx」は、当該タグで示される更新から次の更新までの間に、コンピュータ１０１、１０１、…からリクエストされた回数（ポーリング回数６１３）を示す。

図２８の例では、登録後に２５時間周期で４回データの更新が行われていることが分かる。また、コンピュータ１０１、１０１、…からのリクエストが、１回目の更新が行われるまでに１２００回、１回目と２回目の更新の間に１２２８回、２回目と３回目の更新の間に１３１２回、３回目と４回目の更新の間に１２８０回あったことが分かる。さらに、あるコンピュータ１０１からのポーリングが、４回目の更新以降の第６２５番目のリクエストであることが分かる。

この図２８の状態情報の例を用いて、このデータで、２００７年０１月０５日の４時以降に、コンピュータ１０１において、当該状態情報に対応するコンテンツデータの登録を行った場合について考える。この場合、図２６のステップＳ１５３の判断により、この状態情報をサーバ装置１０２に対する初回のアクセスで取得できる。したがって、コンピュータ１０１は、サーバ装置１０２への次回のアクセス時期を適切に設定することができる。

また、過去４回の更新に関するポーリング実績から、コンテンツデータの更新と更新の間に平均１２５５回のポーリングがあると予測できる。そこで、式（１）により、略７１秒毎（２５時間／１２５５回）にポーリングを行うよう分散すればよいことが算出できる。そのため、調整量Ａは、式（３）から、１２時間１９分３５秒と算出できる（７１秒×６２５回）。したがって、当該コンピュータ１０１からの次回ポーリング予定時間は、２００７年０１月０６日の１７時１９分３５秒となる。

なお、本第８の変形例におけるコンピュータ１０１側の処理には、図６を用いて説明した処理を適用することができる。この場合、図６のステップＳ１４とステップＳ１５の間に、図２６のフローチャートにおけるステップＳ１５６による、ポーリング間隔の調整処理が行われることになる。

なお、本第８の変形例は、上述した第７の変形例と組み合わせて実施することが可能である。

＜第９の変形例＞
次に、本実施形態の第９の変形例について、図２９を用いて説明する。本第９の変形例は、コンピュータ１０１によるポーリング間隔を、サーバ装置１０２の側から決めるようにした例である。

図２９は、この第９の変形例によりサーバ装置１０２が状態情報を生成する際の一例の処理を示すフローチャートである。ステップＳ１８０で、サーバ装置１０２は、上述した図６のステップＳ２４によるコンピュータ１０１からのリクエストに基づき、データ管理情報６００を識別する。次のステップＳ１８１で、識別したデータ管理情報６００に関連付けられているデータ更新情報６１０における、リクエストのあった最新のコンテンツデータに対するポーリング回数６１３に、１を加算する。

ステップＳ１８１でポーリング回数６１３の更新が行われたら、処理はステップＳ１８２に移行され、ステップＳ１８０で識別されたデータ管理情報６００に関連付けられたデータ更新情報６１０から、更新日時６１２を取得する。そして、次のステップＳ１８３で、取得した更新日時６１２から、線形近似などを用いて当該コンテンツデータの更新間隔を予測する。

更新間隔を求める方法は、線形近似による方法の他にも、更新日時６１２から更新パターンを求め、マッチするパターンから更新の予測を行う方法が考えられる。また、更新間隔を求める方法は、前回の更新日時と今回の更新日時だけを単純に比較するような方法などでもよい。

次のステップＳ１８４で、ステップＳ１８３で求めた更新間隔と、ステップＳ１８１で更新されたポーリング回数６１３とに基づき、調整量Ａを算出する。ここでの調整量Ａの算出方法は、図２７を用いて説明した方法と同一であるので、詳細な説明を省略する。例えば、ステップＳ１８３で求めた更新間隔を予測コンテンツ更新間隔Ｔとし、予想ポーリング回数Ｃを、最新以外の更新日時６１２に対応するポーリング回数６１３に基づき求める。また、最新の更新日時６１２に対応するポーリング回数６１３を、ポーリング回数Ｎとする。これらに基づき上述した式（２）の計算を行い、調整量Ａを算出する。

調整量Ａが算出されたら、処理はステップＳ１８５に移行し、ステップＳ１８３で求めた更新間隔と、ステップＳ１８４で求めた調整量Ａとに基づき、予測更新日時を求める。例えば、データ更新情報６１０における最新の更新日時６１２に対して調整量Ａを加えた日時を、予測更新日時とする。サーバ装置１０２は、求められた予測更新日時と最新の更新日時６１２とにより状態情報を生成する。この状態情報は、例えば、図１９を用いて説明したような構造とすることができる。生成されたこの状態情報は、サーバ装置１０２から、リクエストの送信元であるコンピュータ１０１に返される。

コンピュータ１０１は、コンピュータ１０１からサーバ装置１０２への初回のアクセスでこの状態情報を取得することができる。この取得された状態情報には、対応するコンテンツデータの更新が次に行われると予測される、予測更新日時を示す情報が記述されている。そのため、コンピュータ１０１は、サーバ装置１０２への次回のアクセス時期を適切に設定することができる。

このように、本第９の変形例によれば、コンピュータ１０１のポーリング間隔を、サーバ装置１０２側で求めた調整量Ａに基づき決めることができる。

本第９の変形例によれば、予測更新日時は、コンピュータ１０１からのリクエストに応じて加算されたポーリング回数Ｎを予測ポーリング回数Ｃで除した際の剰余Ｒに基づき求めた調整量Ａを用いて生成される。そのため、例えば各コンピュータ１０１、１０１、…において予測コンテンツ更新間隔Ｔが同一であっても、実際にポーリングが行われる時間は、予測コンテンツ更新間隔Ｔ内で均一的に分散され、サーバ装置１０２へのアクセスの集中が抑えられる。

なお、本第９の変形例は、上述した第７の変形例と組み合わせて実施することが可能である。

なお、上述の実施形態および各変形例において、コンピュータ１０１が複数のリンク管理情報５００を有している場合に、状態情報を取得する処理に対して、リンク管理情報５００毎に優先順位を設定することができる。より具体的には、上述した図６におけるステップＳ２０の処理を行うに先立って、図２４のステップＳ９５に例示されるように、リンク管理情報５００に対し、情報取得日時５０５で降順、すなわち、現在から過去の順となるように順序を設定する。図６のステップＳ２１以下の処理は、このステップＳ９５で設定された順序に従い、複数のリンク管理情報５００に対して順次、処理を行うようにする。

また、上述では、本発明がＲＳＳフィードに対応し、ＲＳＳフィードの更新情報を取得するように説明したが、これはこの例に限定されない。すなわち、本発明は、インターネット上に分散的に存在する他のデータの更新情報を取得する際にも、用いて好適なものである。

具体的な例としては、インターネット上のＷｅｂサイトの更新情報を取得する際に、本発明を適用することができる。この場合、Ｗｅｂサイトそのもの、Ｗｅｂサイトを構成する各Ｗｅｂページ、Ｗｅｂページ内に表示される画像データやテキストデータなど、Ｗｅｂサイトの様々な階層のデータを更新情報の取得対象とすることができる。

＜他の実施形態＞
上述の実施形態および実施形態の各変形例においては、サーバ装置１０２およびコンピュータ１０１がそれぞれ単独の機器から構成されるように説明したが、これはこの例に限定されない。例えば、本発明のコンピュータ１０１やサーバ装置１０２と同等の機能を、それぞれ複数の機器から構成されるシステムによって実現しても良い。

さらに、上述の各実施形態をコンピュータで実現するために、該コンピュータに供給されるコンピュータプログラム自体も本発明を実現するものである。つまり、上述の実施形態の機能を実現するためのコンピュータプログラム自体も本発明の一つである。

なお、上述の実施形態を実現するためのコンピュータプログラムは、コンピュータで読み取り可能であれば、どのような形態であってもよい。例えば、オブジェクトコード、インタプリタにより実行されるプログラム、ＯＳに供給するスクリプトデータ等で構成することができるが、これらに限るものではない。

上述の実施形態を実現するためのコンピュータプログラムは、記憶媒体又は有線／無線通信によりコンピュータに供給される。プログラムを供給するための記憶媒体としては、例えば、フレキシブルディスク、ハードディスク、磁気テープ等の磁気記憶媒体、ＭＯ、ＣＤ、ＤＶＤ等の光／光磁気記憶媒体、不揮発性の半導体メモリなどがある。

有線／無線通信を用いたコンピュータプログラムの供給方法としては、コンピュータネットワーク上のサーバを利用する方法がある。この場合、本発明を形成するコンピュータプログラムとなりうるデータファイル（プログラムファイル）をサーバに記憶しておく。プログラムファイルとしては、実行形式のものであっても、ソースコードであっても良い。

そして、このサーバにアクセスしたクライアントコンピュータに、プログラムファイルをダウンロードすることによって供給する。この場合、プログラムファイルを複数のセグメントファイルに分割し、セグメントファイルを異なるサーバに分散して配置することも可能である。

つまり、上述の各実施形態を実現するためのプログラムファイルをクライアントコンピュータに提供するサーバ装置も本発明の一つである。

また、上述の各実施形態を実現するためのコンピュータプログラムを暗号化して格納した記憶媒体を配布し、所定の条件を満たしたユーザに、暗号化を解く鍵情報を供給し、ユーザの有するコンピュータへのインストールを許可してもよい。鍵情報は、例えばインターネットを介してホームページからダウンロードさせることによって供給することができる。

また、上述の各実施形態を実現するためのコンピュータプログラムは、すでにコンピュータ上で稼働するＯＳの機能を利用するものであってもよい。

さらに、上述の実施形態を実現するためのコンピュータプログラムは、その一部をコンピュータに装着される拡張ボード等のファームウェアで構成してもよいし、拡張ボード等が備えるＣＰＵで実行するようにしてもよい。

本発明に適用可能なシステムの一例の構成を示す略線図である。 ユーザ側のコンピュータの一例の構成を示すブロック図である。 実施形態によるデータ状態情報の一例の取得処理を概略的に示すフローチャートである。 実施形態による、サーバ装置における更新履歴の一例の管理構造を示す略線図である。 実施形態による、コンピュータ側が持つ一例のリンク管理情報を示す略線図である。 実施形態により状態情報を取得するコンピュータ側の一例の処理を示すフローチャートである。 実施形態によりコンピュータ側の処理に対応してサーバ装置側で行われる一例の処理を示すフローチャートである。 実施形態による、サーバ装置からコンピュータに送信される一例の状態情報を概略的に示す略線図である。 実施形態の第１の変形例による、コンピュータ側がリンク情報を管理するために持つ管理情報の一例の構成を示す略線図である。 第１の変形例により状態情報を取得するコンピュータ側の一例の処理を示すフローチャートである。 第１の変形例によりコンピュータ側の処理に対応してサーバ装置側で行われる一例の処理を示すフローチャートである。 実施形態の第２の変形例によりサーバ装置が状態情報を生成する際の一例の処理を示すフローチャートである。 第２の変形例により生成された一例の状態情報を示す略線図である。 実施形態の第３の変形例によりサーバ装置が状態情報を生成する際の一例の処理を示すフローチャートである。 第３の変形例により生成された一例の状態情報を示す略線図である。 実施形態の第４の変形例によりサーバ装置が状態情報を生成する際の一例の処理を示すフローチャートである。 第４の変形例により生成された一例の状態情報を示す略線図である。 実施形態の第５の変形例によりサーバ装置が状態情報を生成する際の一例の処理を示すフローチャートである。 第５の変形例により生成された一例の状態情報を示す略線図である。 実施形態の第６の変形例によるコンピュータ側の一例の処理を示すフローチャートである。 第６の変形例においてサーバ装置からコンピュータに対して送信される状態情報の一例の構成を示す略線図である。 実施形態の第７の変形例によりサーバ装置が状態情報を生成する際の一例の処理を示すフローチャートである。 第７の変形例により生成された一例の状態情報を示す略線図である。 状態情報を取得する処理に対してリンク管理情報毎に優先順位を設定することを説明するためのフローチャートである。 本発明の実施形態の第８の変形例に係る更新履歴の一例の管理構造を示す略線図である。 本発明の実施形態の第８の変形例によるデータ状態情報の一例の取得処理を概略的に示すフローチャートである。 クライアントにおいて行われるポーリング間隔の調整処理を示す一例のフローチャートである。 本発明の実施形態の第８の変形例において、サーバ装置からクライアントに対して送信される状態情報の一例の構成を示す略線図である。 本発明の実施形態の第９の変形例によりサーバ装置が状態情報を生成する際の一例の処理を示すフローチャートである。

符号の説明

１００ インターネット
１０１ コンピュータ
１０２ サーバ装置
４００ データ管理情報
４０１ データ更新情報
５００ リンク管理情報
５０４ コンテンツデータの状態情報を示すリンク情報
５０５ 情報取得日時
５０６ 状態情報取得予定日時

Claims (30)

1. サーバ装置とクライアント装置とがネットワークを介して通信可能に接続された通信システムであって、
   前記サーバ装置が、
   前記ネットワークを介して前記クライアント装置によりアクセスされるコンテンツデータの更新履歴を管理するコンテンツデータ管理手段と、
   前記コンテンツデータ管理手段が管理する前記更新履歴に基づいて前記コンテンツデータの更新の状態を示す状態情報を生成する生成手段と
   を備え、
   前記クライアント装置が、
   前記状態情報を前記サーバ装置に対して要求する要求手段と、
   前記要求手段の要求により取得した前記状態情報に基づいて、前記要求手段が次に前記要求を行うべきタイミングを決定する決定手段と、
   前記決定手段が決定した前記タイミングで前記要求手段に前記要求を行わせる制御手段と
   を備える
   ことを特徴とする通信システム。
2. 前記サーバ装置の前記生成手段は、前記要求に応じて、前記更新履歴を前記状態情報として生成し、
   前記クライアント装置の前記決定手段は、前記更新履歴に含まれる更新日時の間隔に基づき前記タイミングを決定する
   ことを特徴とする請求項１に記載の通信システム。
3. 前記要求手段は、前記状態情報を前回取得した日時を示す情報取得日時を付加して前記要求を行い、
   前記生成手段は、前記更新履歴のうち、前記情報取得日時より後の更新日時を示す更新履歴を前記状態情報として生成する
   ことを特徴とする請求項２に記載の通信システム。
4. 前記サーバ装置の前記生成手段は、前記要求に応じて、前記更新履歴に基づき前記コンテンツデータの更新間隔の平均値を求めると共に該コンテンツデータの最新の更新日時を求め、求められた該更新間隔の平均値と該最新の更新日時とを前記状態情報として生成し、
   前記クライアント装置の前記決定手段は、前記最新の更新日時に前記更新間隔の平均値を加算した結果に基づき前記タイミングを決定する
   ことを特徴とする請求項１に記載の通信システム。
5. 前記サーバ装置の前記生成手段は、前記要求に応じて、前記更新履歴に基づき前記コンテンツデータの更新回数を計数する基点となる日時と、該基点となる日時から該コンテンツデータが更新された更新回数と、該コンテンツデータの最新の更新日時とを求め、該基点となる日時と該更新回数と該最新の更新日時とを前記状態情報として生成し、
   前記クライアント装置の前記決定手段は、前記基点となる日時と前記更新回数と前記最新の更新日時とから更新間隔の平均値を求め、該更新間隔の平均値を該最新の更新日時に加算した結果に基づき前記タイミングを決定する
   ことを特徴とする請求項１に記載の通信システム。
6. 前記サーバ装置の前記生成手段は、前記要求に応じて、前記更新履歴に基づき、前記コンテンツデータの最新の更新日時と、該最新の更新日時による更新に対して１回前に行った更新の更新日時とを求め、求められた該最新の更新日時と該１回前に行った更新の更新日時とを前記状態情報として生成し、
   前記クライアント装置の前記決定手段は、前記最新の更新日時と前記１回前に行った更新の更新日時との差分を求め、該差分を該最新の更新日時に加算した結果に基づき前記タイミングを決定する
   ことを特徴とする請求項１に記載の通信システム。
7. 前記サーバ装置の前記生成手段は、前記要求に応じて、前記更新履歴に基づき次に前記コンテンツデータを更新すると予測される予測更新日時を求め、求められた該予測更新日時を前記状態情報として生成し、
   前記クライアント装置の決定手段は、前記予測更新日時を前記タイミングとして決定する
   ことを特徴とする請求項１に記載の通信システム。
8. 前記サーバ装置の前記生成手段は、前記要求に応じて前記状態情報を生成すると共に、第１の間隔および該第１の間隔より長い第２の間隔またはこれらのうち何れか一方を設定して該状態情報に付加し、
   前記クライアント装置の前記決定手段は、前記要求手段で前記要求を行ったタイミングと、前記状態情報に基づき決定された前記次に要求を行うべきタイミングとの間隔が、前記第１の間隔より短い場合には該第１の間隔を前記要求手段で前記要求を行ったタイミングが示す時間に加算した結果に基づき前記次に要求を行うべきタイミングを再び決定し、該次に要求を行うべきタイミングとの間隔が前記第２の間隔より長い場合には該第２の間隔を前記要求手段で前記要求を行ったタイミングが示す時間に加算した結果に基づき前記次に要求を行うべきタイミングを再び決定する
   ことを特徴とする請求項１乃至請求項７の何れか１項に記載の通信システム。
9. 前記サーバ装置の前記コンテンツデータ管理手段は、前記更新履歴を、前記コンテンツデータの更新が行われた更新日時と、該更新から次の更新が行われるまでに前記要求があった要求回数とを関連付けて管理し、
   前記サーバ装置の前記生成手段は、前記要求に応じて、該要求に対応する前記要求回数を含む前記更新履歴を前記状態情報として生成し、
   前記クライアント装置は、
   前記決定手段で決定された前記タイミングを、前記状態情報に含まれる前記要求回数に基づき調整する調整手段をさらに有し、
   前記クライアント装置の前記制御手段は、前記タイミングを前記調整手段で調整したタイミングで前記要求手段に前記要求を行わせる
   ことを特徴とする請求項１に記載の通信システム。
10. 前記クライアント装置の前記調整手段は、前記更新履歴に含まれる前記更新日時と前記要求回数とから前記要求の時間間隔を予測し、該予測された該時間間隔と前記要求に対応する要求回数とに基づき前記調整を行う
    ことを特徴とする請求項９に記載の通信システム。
11. 前記サーバ装置の前記コンテンツデータ管理手段は、前記更新履歴を、前記コンテンツデータの更新が行われた更新日時と、該更新から次の更新が行われるまでに前記要求があった要求回数とを関連付けて管理し、
    前記サーバ装置の前記生成手段は、前記要求に応じて、該要求の直前に行われた更新から該要求までの前記要求回数を含む前記更新履歴に基づき前記コンテンツデータの更新間隔を予測し、該更新間隔と該要求回数とに基づき前記コンテンツデータの予測更新日時を求め、求められた該予測更新日時を前記状態情報として生成し、
    前記クライアント装置の前記決定手段は、前記予測更新日時を前記タイミングとして決定する
    ことを特徴とする請求項１に記載の通信システム。
12. 前記サーバ装置の前記生成手段は、
    前記更新履歴に含まれる前記更新日時と前記要求回数とから、前記要求の時間間隔を予測すると共に、該予測された該時間間隔と前記要求の直前に行われた更新から要求までの要求回数とに基づき前記予測更新日時を求める
    ことを特徴とする請求項１１に記載の通信システム。
13. 前記クライアント装置の前記要求手段は、該クライアント装置の側の時刻を示す時刻情報を付加して前記要求を行い、
    前記サーバ装置の生成手段は、前記要求に応じて前記状態情報を生成し、前記クライアント装置の側の時刻を示す時刻情報と前記サーバ装置の側の時刻を示す時刻情報との差分の時間情報を該状態情報に付加し、
    前記クライアント装置の前記制御手段は、前記状態情報に付加された前記差分の時間情報を用いて、該状態情報に基づき決定された前記次に要求を行うべきタイミングを調整する
    ことを特徴とする請求項１乃至請求項１２の何れか１項に記載の通信システム。
14. 前記コンテンツデータは、前記ネットワークを介して前記クライアント装置にアクセスされるリソースデータの概要が記述されるメタデータであって、
    前記サーバ装置は、前記コンテンツデータ管理手段により、前記リソースデータの更新に応じて前記コンテンツデータおよび前記コンテンツデータに対応する更新履歴の更新を行う
    ことを特徴とする請求項１乃至請求項１３の何れか１項に記載の通信システム。
15. クライアント装置と、ネットワークを介して該クライアント装置にアクセスされるコンテンツデータの更新履歴を管理するコンテンツデータ管理手段を有するサーバ装置とが該ネットワークを介して通信可能に接続された通信システムの通信方法であって、
    前記クライアント装置が、前記サーバ装置に対して前記コンテンツデータ管理手段が管理しているコンテンツデータの更新の状態を示す状態情報の要求を送信する要求送信ステップと、
    前記サーバ装置が、前記クライアント装置からの前記要求に応じて、前記コンテンツデータ管理手段が管理する前記更新履歴に基づきコンテンツデータの更新の状態を示す状態情報を生成する生成ステップと、
    前記サーバ装置が、前記クライアント装置からの前記要求に応じて、前記生成ステップで生成された前記状態情報を前記ネットワークを介して前記クライアント装置に対して送信する送信ステップと、
    前記クライアント装置が、前記要求送信ステップで送信した前記要求に応じて前記サーバ装置から送信された前記状態情報に基づき、次に前記要求送信ステップで前記状態情報の要求を送信するタイミングを決定する決定ステップと
    を有する
    ことを特徴とする通信方法。
16. コンテンツデータの更新履歴を管理しているサーバ装置に対してネットワークを介してアクセスするクライアント装置であって、
    前記サーバ装置が管理しているコンテンツデータの更新の状態を示す状態情報を前記サーバ装置に対して要求する要求手段と、
    前記要求手段による要求に応答して前記サーバ装置が生成した前記状態情報を取得して、前記要求手段が次に前記要求を行うべきタイミングを決定する決定手段と、
    前記決定手段が決定した前記タイミングで前記要求手段に前記要求を行わせる制御手段と
    を有する
    ことを特徴とするクライアント装置。
17. 前記決定手段は、
    前記要求に応じて前記サーバ装置で前記状態情報として生成された前記更新履歴に含まれる更新日時の間隔に基づき前記タイミングを決定する
    ことを特徴とする請求項１６に記載のクライアント装置。
18. 前記要求手段は、前記状態情報を前回取得した日時を示す情報取得日時を付加して前記要求を行い、
    前記決定手段は、
    前記要求に応じて前記サーバ装置で前記状態情報として生成された、該要求と共に送信された前記情報取得日時に基づき前記更新履歴のうち該情報取得日時より後の更新日時を示す更新履歴を用いて前記タイミングを決定する
    ことを特徴とする請求項１７に記載のクライアント装置。
19. 前記決定手段は、
    前記要求に応じて前記サーバ装置で前記状態情報として生成された、前記コンテンツデータの更新間隔の平均値と該コンテンツデータの最新の更新日時とを用いて、該最新の更新日時に該更新間隔の平均値を加算した結果に基づき前記タイミングを決定する
    ことを特徴とする請求項１６に記載のクライアント装置。
20. 前記決定手段は、
    前記要求に応じて前記サーバ装置で前記状態情報として生成された、前記コンテンツデータの更新回数を計数する基点となる日時と、該基点となる日時から該コンテンツデータが更新された更新回数と、該コンテンツデータの最新の更新日時とを用いて、該基点となる日時と該更新回数と該最新の更新日時とからコンテンツデータの更新間隔の平均値を求め、該更新間隔の平均値を該最新の更新日時に加算した結果に基づき前記タイミングを決定する
    ことを特徴とする請求項１６に記載のクライアント装置。
21. 前記決定手段は、
    前記要求に応じて前記サーバ装置で前記状態情報として生成された、前記コンテンツデータの最新の更新日時と、該最新の更新日時による更新に対して１回前に行った更新の更新日時とを用いて、該最新の更新日時と該１回前に行った更新の更新日時との差分を求め、該差分を該最新の更新日時に加算した結果に基づき前記タイミングを決定する
    ことを特徴とする請求項１６に記載のクライアント装置。
22. 前記決定手段は、
    前記要求に応じて前記サーバ装置から前記状態情報として生成された、次に前記コンテンツデータを更新すると予測される予測更新日時を前記タイミングとして決定する
    ことを特徴とする請求項１６に記載のクライアント装置。
23. 前記決定手段は、
    前記要求に応じて、前記サーバ装置で生成された、前記状態情報と、該状態情報に付加された該要求に対する第１の間隔および該第１の間隔より長い第２の間隔またはこれらのうち何れか一方とに基づき、
    前記要求手段で前記要求を行ったタイミングと、前記状態情報に基づき決定された前記次に要求を行うべきタイミングとの間隔が、前記第１の間隔より短い場合には該第１の間隔を前記要求手段で前記要求を行ったタイミングが示す時間に加算した結果に基づき前記次に要求を行うべきタイミングを再び決定し、該次に要求を行うべきタイミングとの間隔が前記第２の間隔より長い場合には該第２の間隔を前記要求手段で前記要求を行ったタイミングが示す時間に加算した結果に基づき前記次に要求を行うべきタイミングを再び決定する
    ことを特徴とする請求項１６乃至請求項２２の何れか１項に記載のクライアント装置。
24. 前記決定手段で決定された前記タイミングを、前記要求に応じて前記サーバ装置で前記状態情報として生成された、前記コンテンツデータの更新が行われた更新日時と、該更新から次の更新が行われるまでに前記要求があった要求回数とが関連付けられた更新履歴の、該要求回数に基づき調整する調整手段をさらに有し、
    前記制御手段は、前記タイミングを前記調整手段で調整したタイミングで前記要求手段に前記要求を行わせる
    ことを特徴とする請求項１６に記載のクライアント装置。
25. 前記調整手段は、
    前記更新履歴に含まれる前記更新日時と前記要求回数とから、前記要求の時間間隔を予測すると共に、該予測された該時間間隔と、前記サーバ装置に前記状態情報を前記生成させるために前記要求手段が行った前記要求の直前の前記更新から該要求までの要求回数とに基づき前記調整を行う
    ことを特徴とする請求項２４に記載のクライアント装置。
26. 前記要求手段は、現在の時刻を示す時刻情報を付加して前記要求を行い、
    前記要求に応じて前記サーバ装置で生成された前記状態情報に付加された、前記現在の時刻を示す時刻情報と、該サーバ装置の側の時刻を示す時刻情報との差分の時間情報を用いて、該状態情報に基づき決定された前記次に要求を行うべきタイミングを調整する
    ことを特徴とする請求項１６乃至請求項２５の何れか１項に記載のクライアント装置。
27. 前記コンテンツデータは、前記ネットワークを介してアクセスされるリソースデータの概要が記述されるメタデータであって、
    前記サーバ装置により前記リソースデータの更新に応じて前記コンテンツデータの更新が行われ、該リソースデータの更新に応じてなされた該コンテンツデータの更新の履歴が管理される
    ことを特徴とする請求項１６乃至請求項２６の何れか１項に記載のクライアント装置。
28. サーバ装置に更新履歴と共に管理されるコンテンツデータに対してネットワークを介してアクセスするクライアント装置の制御方法であって、
    前記サーバ装置が管理しているコンテンツデータの更新の状態を示す状態情報を前記サーバ装置に対して要求する要求ステップと、
    前記要求ステップによる要求に応答して前記サーバ装置が生成した前記状態情報に基づいて、前記要求ステップが次に前記要求を行うべきタイミングを決定する決定ステップと、
    前記決定ステップが決定した前記タイミングで前記要求ステップに前記要求を行わせる制御ステップと
    を有する
    ことを特徴とする制御方法。
29. コンピュータを請求項１乃至請求項１４の何れか１項に記載のサーバ装置として機能させるためのプログラム。
30. コンピュータを請求項１乃至請求項１４および請求項１６乃至請求項２７の何れか１項に記載のクライアント装置として機能させるためのプログラム。

Images