(57)【要約】【課題】操作負担を軽減する。【解決手段】複数の領域を含む所定の構造化文書の中から、主要な領域を判定する情報処理装置において、前記構造化文書中の各領域または、各領域の管理情報を時系列に複数回、取得する読み込み部と、当該読み込み部が取得した領域または管理情報を記憶する記憶部と、当該読み込み部が取得した対応する領域の間または管理情報の間で比較を行い、当該比較結果に基づいて各領域の更新の有無を検査する比較検査部と、　当該比較検査部による検査結果の履歴をもとに、各領域ごとに、所定の更新頻度対応情報を算出する更新頻度算出部と、当該更新頻度対応情報に基づいて、前記構造化文書中の複数の領域の中から主要な領域を判定する主要領域判定部とを備える。【選択図】　図１
2004086841.tif 000002
【特許請求の範囲】
【請求項１】
複数の領域を含む所定の構造化文書の中から、主要な領域を判定する情報処理装置において、
前記構造化文書中の各領域または、各領域の管理情報を時系列に複数回、取得する読み込み部と、
当該読み込み部が取得した領域または管理情報を記憶する記憶部と、
当該読み込み部が取得した対応する領域の間または管理情報の間で比較を行い、当該比較結果に基づいて各領域の更新の有無を検査する比較検査部と、
当該比較検査部による検査結果の履歴をもとに、各領域ごとに、所定の更新頻度対応情報を算出する更新頻度算出部と、
当該更新頻度対応情報に基づいて、前記構造化文書中の複数の領域の中から主要な領域を判定する主要領域判定部とを備えたことを特徴とする情報処理装置。
【請求項２】
請求項１の情報処理装置において、
前記構造化文書中の各領域を、画面表示上の領域間の境界を示す境界情報に基づいて分割する境界分割部を備え、
前記読み込み部は、当該境界分割部と連携することによって、前記各領域または管理情報の読み込みを行うことを特徴とする情報処理装置。
【請求項３】
請求項１の情報処理装置において、
前記構造化文書中の各領域が、予め領域間の論理的な構造を示す領域間構造を定義されている場合には、その領域間構造を利用して各領域を識別する領域管理部を備え、
前記読み込み部は、当該領域管理部と連携することによって、前記各領域または管理情報の読み込みを行うことを特徴とする情報処理装置。
【請求項４】
請求項１の情報処理装置において、
前記比較検査部は、
前記読み込み部が今回、取得した領域と当該領域に対応する前回、取得した領域とを比較することによって更新の有無を検査することを特徴とする情報処理装置。
【請求項５】
請求項１の情報処理装置において、
前記比較検査部は、
前記読み込み部が今回、取得した管理情報と当該管理情報に対応する前回、取得した管理情報とを比較することによって更新の有無を検査することを特徴とする情報処理装置。
【請求項６】
請求項１の情報処理装置において、
前記領域または管理情報を、誤り検出のため、より小さなサイズの変換データに変換する変換部を備え、
当該変換部が出力する変換データを、前記記憶部に記憶することを特徴とする情報処理装置。
【請求項７】
請求項１の情報処理装置において、
前記更新頻度算出部は、
前回の更新頻度対応情報と、今回、前記比較検査部が出力した検査結果に基づいて、今回の更新頻度対応情報を算出することを特徴とする情報処理装置。
【請求項８】
複数の領域を含む所定の構造化文書の中から、主要な領域を判定する情報処理方法において、
読み込み部が、前記構造化文書中の各領域または、各領域の管理情報を時系列に複数回、取得し、
当該読み込み部が取得した領域または管理情報を、記憶部が記憶し、
比較検査部が、当該読み込み部の取得した対応する領域の間または管理情報の間で比較を行い、当該比較結果に基づいて各領域の更新の有無を検査し、
当該比較検査部による検査結果の履歴をもとに、更新頻度算出部が、各領域ごとに所定の更新頻度対応情報を算出し、
当該更新頻度対応情報に基づいて、主要領域判定部が、前記構造化文書中の複数の領域の中から主要な領域を判定することを特徴とする情報処理方法。
【発明の詳細な説明】
【０００１】
本発明は情報処理装置および方法に関し、例えば、ＷＷＷ（Ｗｏｒｌｄ　Ｗｉｄｅ　Ｗｅｂ）サイトから構造化文書を取得する場合などに適用し得るものである。
【０００２】
【従来の技術】
ＷＷＷサイトに存在する構造化文書を取得し閲覧するためのツールとして、ＷＷＷブラウザがある。一般的に、構造化文書はその文書のページのレイアウト、文字の大きさなどを柔軟に指定することができるようになっている。特に、図１のように、タイトル（領域Ａ）、他の構造化文書へのリンク（領域Ｂ）、本文（領域Ｃ）、など、ページがいくつかの領域（フレーム）に分割されて、ＷＷＷブラウザに表示されるような構造化文書が多く見られる。ＷＷＷブラウザを用いて、このような構造化文書から必要な情報を得るためには、ユーザは、目的の構造化文書のＵＲＬを指定し、その文書がＷＷＷブラウザ上に表示された後に、文書をスクロールしながら目視により検索したり（人手による検索）、あるいは文字列検索機能を利用するといった作業を行なう必要がある。例えば、図１の領域Ｃが、ユーザの必要とする文書であったとし、こういった構造化文書が多数ある場合には、そのユーザが必要とする情報のみを複数の構造化文書から自動的にスクラップし、１つの文書にまとめてユーザに提示することが、人手による作業を簡略化する上で望ましくなる。このようなＷＷＷ情報抽出システムが、次の特許文献１に示されている。
【０００３】
【特許文献１】
特開平１０−１８７７５３号公報
【０００４】
【発明が解決しようとする課題】
しかしながら、上記におけるＷＷＷ情報抽出システムでは、ユーザが構造化文書中で自分が必要とするデータの開始箇所と終了箇所をあらかじめ手入力により指定することが必要である。このため、大量の構造化文書に対して実施するにはユーザの操作負担が大きく現実的ではなかった。
【０００５】
【課題を解決するための手段】
かかる課題を解決するために、第１の発明では、複数の領域を含む所定の構造化文書の中から、主要な領域を判定する情報処理装置において、（１）前記構造化文書中の各領域または、各領域の管理情報を時系列に複数回、取得する読み込み部と、（２）当該読み込み部が取得した領域または管理情報を記憶する記憶部と、（３）当該読み込み部が取得した対応する領域の間または管理情報の間で比較を行い、当該比較結果に基づいて各領域の更新の有無を検査する比較検査部と、（４）当該比較検査部による検査結果の履歴をもとに、各領域ごとに、所定の更新頻度対応情報を算出する更新頻度算出部と、（５）当該更新頻度対応情報に基づいて、前記構造化文書中の複数の領域の中から主要な領域を判定する主要領域判定部とを備えたことを特徴とする。
【０００６】
また、第２の発明では、複数の領域を含む所定の構造化文書の中から、主要な領域を判定する情報処理方法において、（１）読み込み部が、前記構造化文書中の各領域または、各領域の管理情報を時系列に複数回、取得し、（２）当該読み込み部が取得した領域または管理情報を、記憶部が記憶し、（３）比較検査部が、当該読み込み部の取得した対応する領域の間または管理情報の間で比較を行い、当該比較結果に基づいて各領域の更新の有無を検査し、（４）　当該比較検査部による検査結果の履歴をもとに、更新頻度算出部が、各領域ごとに所定の更新頻度対応情報を算出し、（５）当該更新頻度対応情報に基づいて、主要領域判定部が、前記構造化文書中の複数の領域の中から主要な領域を判定することを特徴とする。
【０００７】
【発明の実施の形態】
（Ａ）実施形態
以下、本発明にかかる情報処理装置および方法の実施形態について説明する。
【０００８】
（Ａ−１）第１の実施形態の構成
本実施形態で、主要領域を判定し抽出する機能を有する領域処理部２５（図１６参照）の機能は、通信機能を有するパソコンその他の情報処理装置によって実現され得、ＷＷＷサーバ側に配置すること等も可能であるが、ここでは、通信端末（クライアント）側に配置する場合を例に説明する。
【０００９】
本実施形態にかかる通信システム１０の全体構成例を図１５に示す。
【００１０】
図１５において、当該通信システム１０は、ネットワーク１１と、通信端末１２と、ＷＷＷサーバ１３とを備えている。
【００１１】
このうちネットワーク１１は、ＬＡＮ（ローカルエリアネットワーク）などであってもかまわないが、ここでは、インターネットであるものとする。
【００１２】
ＷＷＷサーバ１３は、通信端末１２からの要求（ＨＴＴＰリクエスト）を受信すると、その要求に応じた応答（ＨＴＴＰレスポンス）としてＷＷＷページを構成するファイルなどを返送する機能を持つサーバである。多くの場合、ＷＷＷサーバ１３は、予め生成したＷＷＷページ等を蓄積しておくためのデータベース（図示せず）、そのデータベースを直接管理するデータベースサーバを伴う。また、これらＷＷＷサーバ１３やデータベースサーバなどの周辺には、ルータやファイアウールなどの各種のネットワーク機器やＤＮＳサーバなどのサーバ類が配置されてＷＷＷサイトを構成するのが普通である。
【００１３】
通信端末１２は上述した領域処理部２５を備えた情報処理装置で、具体的には、ネットワーク機能を有するパーソナルコンピュータなどであってよい。本実施形態の構成上、当該通信端末１２は、ＷＷＷページを閲覧するためのプログラムであるＷＷＷブラウザＢ１（図１６参照）を搭載していることが必要である。
【００１４】
当該通信端末１２の内部構成例を図１６に示す。
【００１５】
（Ａ−１−１）通信端末の内部構成例
図１６において、当該通信端末１２は、通信部２０と、制御部２１と、操作部２２と、記憶部２３と、表示部２４と、領域処理部２５とを備えている。
【００１６】
このうち通信部２０は、前記ネットワーク１１を介してＷＷＷサーバ１３と通信する機能を持つ部分である。
【００１７】
制御部２１は、ハードウエア的には当該通信端末１２の中央処理装置（ＣＰＵ）に相当する部分であり、ソフトウエア的には、オペレーティングシステム（ＯＳ）や上述したＷＷＷブラウザＢ１などに相当する部分である。
【００１８】
操作部２２は当該通信端末１２のユーザＵ１が操作して制御部２１に指示を伝えるための部分で、例えば、キーボードや、ポインティングデバイスなどを有する。
【００１９】
表示部２４は例えば液晶ディスプレイなどの表示画面を有する部分である。ユーザＵ１がＷＷＷページを閲覧する場合には、ＷＷＷブラウザＢ１がＷＷＷページのタグを解釈し処理した結果として、ＷＷＷページの内容が当該表示部２４に画面表示され、ユーザＵ１に閲覧され得る。このとき画面表示されるＷＷＷページは、一例として、図１に示したＤＰ１であってよい。ＤＰ１のようなフレームのページ（フレームページ）を表示するためには、ＷＷＷブラウザＢ１はフレームに対応したものであることを要する。フレームとは、図１の各領域Ａ〜Ｃに画面表示されている内容のことではなく、その内容を収容している枠のことを指す。図１のフレームページは、例えば、図４（Ａ）〜（Ｄ）のＨＴＭＬファイルをもとに生成される。
【００２０】
通常、１つのＷＷＷページは、基本となる１つのＨＴＭＬファイルと、必要に応じて１または複数の各種ファイル（画像ファイルなど）から構成されるが、ＤＰ１のようなフレームページは、これよりファイル数も多く、複雑な構造を有する。
【００２１】
すなわちフレームページは、そのＷＷＷページ全体の構成（すなわち、フレーム構造）を規定するＨＴＭＬファイル（フレーム規定ファイル）と、内容として各フレームに配置される複数のＨＴＭＬファイルが最低限、必要であり、これに加えて、各ＨＴＭＬファイルにリンクされた各種ファイル（画像ファイルなど）が適宜、追加されることになる。
【００２２】
したがって、簡単のために各種ファイルがないと仮定しても、図１に示したフレームページＤＰ１は、図４（Ａ）のＨＴＭＬファイル（フレーム規定ファイル）と、領域Ａに配置される図４（Ｂ）のＨＴＭＬファイルと、領域Ｂに配置される図４（Ｃ）のＨＴＭＬファイルと、領域Ｃに配置される図４（Ｄ）のＨＴＭＬファイルの、合計４つのＨＴＭＬファイルから構成されることになる。
【００２３】
通常のＷＷＷページは、１つのＨＴＭＬファイルの内部でのみ構造化されているが、フレームページでは、各ＨＴＭＬファイルの内部で構造化されているだけでなく、１つのフレームページに含まれる複数のＨＴＭＬファイルのあいだでも構造化されている。
【００２４】
なお、図１では、各領域Ａ〜Ｃのあいだの境界線（スクロールバーなども含む）Ｌ１，Ｌ２が表示されているが、実際のフレームページでは、視覚的な効果などとの関連で、意図的にこのような境界線が表示されないようにし、異なる領域間でまったく地の色が同じになるようにしたり、まったく切れ目のない連続的な背景模様を表示したりすることも多い。したがって、境界線の表示の有無は、領域分割（フレーム構造）の本質とは関係ない。
【００２５】
フレーム構造、すなわち、１つの画面をいくつのフレームに分割し、各フレームの辺の長さの割合（この割合は、各フレームの面積に対応）をどのように設定するか等（境界線の表示、非表示も含む）は、前記フレーム規定ファイル（例えば、ＤＰ１１）の記述によって決まる。
【００２６】
当該フレームページＤＰ１の閲覧を希望する場合、ユーザＵ１が通信端末１２のＷＷＷブラウザＢ１に入力するのは、フレーム規定ファイルＤＰ１１のＵＲＬ（ここでは、ＵＲＬ１１とする）である。したがってこのとき、当該フレーム規定ファイルＤＰ１１の返送を要求するＨＴＴＰリクエストが通信端末１２からＷＷＷサーバ１３へ送信され、そのＨＴＴＰレスポンスとして、各種ＨＴＴＰヘッダ（エンティティヘッダも含む）とともに、エンティティボディとして当該フレーム規定ファイルＤＰ１１が返送される。
【００２７】
エンティティボディ、すなわち、ＨＴＭＬファイルや画像ファイルなどのファイルの返送を要求する場合、ＨＴＴＰリクエストはＧＥＴメソッドを使用するＧＥＴリクエストになる。
【００２８】
その他のＨＴＭＬファイルＤＰ１２〜ＤＰ１４は、当該フレーム規定ファイルＤＰ１１が通信端末１２に受信されたあと、当該フレーム規定ファイルＤＰ１１中の記述（ＵＲＬ１２〜ＵＲＬ１４）に基づいて、ＷＷＷブラウザＢ１が順次、自動的に送信する各ＨＴＴＰリクエストに応じた各ＨＴＴＰレスポンスとして、通信端末１２に受信される。
【００２９】
そして、これら４つのＨＴＭＬファイルを処理し、整形した結果として、例えば、図１に示すような画面が、前記表示部２４に表示されることになる。
【００３０】
ここで、ＨＴＭＬファイルＤＰ１２のＵＲＬを前記ＵＲＬ１２とし、ＨＴＭＬファイルＤＰ１３のＵＲＬを前記ＵＲＬ１３とし、ＨＴＭＬファイルＤＰ１４のＵＲＬを前記ＵＲＬ１４とすると、ＵＲＬ１２は図４（Ａ）の行ＴＧ１２中の「ｔｉｔｌｅ．ｈｔｍｌ」であり、ＵＲＬ１３は行ＴＧ１３中の「ｍｅｎｕ．ｈｔｍｌ」であり、ＵＲＬ１４は行ＴＧ１４中の「ｍａｉｎ．ｈｔｍｌ」である。
【００３１】
通常、１つのフレームページを構成する複数のＨＴＭＬファイルは、フレーム規定ファイルと同じＷＷＷサーバ（ここでは、１３）に置かれ、しかも同じフォルダ内に置かれるため、ＦＱＤＮを含まないこのようなローカルなＵＲＬ（ここでは、ファイル名だけから成るＵＲＬ）によって指定することができる。
【００３２】
必要ならば、１つのフレームページを構成する複数のＨＴＭＬファイルを別なＷＷＷサーバに置くこともでき、その場合には、例えば、前記ＵＲＬ１２〜ＵＲＬ１４の全部または一部が、ＦＱＤＮを含むＵＲＬに変わる。なお、ユーザＵ１によって入力され得るフレーム規定ファイルＤＰ１１を指定する前記ＵＲＬ１１は、ＦＱＤＮを含むＵＲＬであることは当然である。
【００３３】
このＵＲＬ１１は、ユーザＵ１が操作部２２を用いて行う手作業によって入力され得るほか、例えば、前記特許文献１に記載されたオートパイロットツールのようなソフトウエアを利用し、予めユーザＵ１が設定した日時や時間間隔で自動的に入力させることができる。
【００３４】
図１のようなメニューを有するフレームページの場合、メニューのファイルが図４（Ｃ）に示すような内容（ターゲット（ｔａｒｇｅｔ）がすべて、ｍａｉｎ（領域Ｃのフレーム名）になっている）であると、メニュー内でユーザＵ１がハイパーリンクを選択することにより、そのハイパーリンクのリンク先のファイルが、領域Ｃに置き換わって表示されることになる。
【００３５】
したがって、典型的な使用方法では、メニューを有するフレームページの場合、他のフレームの内容（ここでは、領域Ａ、領域Ｂ）は同じでターゲットのフレームの内容（領域Ｃ）だけが置き換わった複数のＷＷＷページが重層的に存在しているとみることができる。
【００３６】
図１６に示す前記記憶部２３は、例えば、ＲＡＭ（ランダムアクセスメモリ）などの揮発性記憶装置や、ハードディスクなどの不揮発性記憶装置によって構成される。
【００３７】
通信端末１２が前記ＷＷＷサーバ１３からＷＷＷページを構成する各ファイル（例えば、前記ＤＰ１１やＤＰ１２など）を受信すると、それらのファイルは、当該記憶部２３のハードディスク上に確保されたキャッシュ領域に一時的に蓄積される。
【００３８】
当該キャッシュ領域は、通常、ＷＷＷブラウザＢ１の管理下に置かれ、ＷＷＷブラウザＢ１から自由にアクセスすることが可能である。
【００３９】
当該キャッシュ領域におけるファイルの記憶は可能なかぎり維持されるが、キャッシュ領域の記憶容量には上限があるため、この上限を越えて新たなＷＷＷページを閲覧し、新たなファイルを蓄積するときには、すでに記憶されているファイルを例えば古いものから順番に削除することによって、必要な記憶容量を確保することになる。
【００４０】
例えばＵＲＬの入力などにより、ユーザＵ１が操作部２２からＷＷＷページの閲覧を指示した場合、そのＵＲＬで指定されるＷＷＷページに関連するファイルがキャッシュ領域に記憶されていればＷＷＷブラウザＢ１は、インターネット１１経由ではなく、当該キャッシュ領域から当該ファイルを取得し、表示部２４に当該ファイルの内容を画面表示する。これによりネットワーク１１上の通信トラフィックや、ＷＷＷサーバ１３側の負荷の増大を抑制し、ユーザＵ１から見た応答時間（指示を出してからＷＷＷページが表示されるまでの時間）を短縮することができる。
【００４１】
前記制御部２１に接続された領域処理部２５は、主要領域を判定し抽出する機能を有する部分であるが、その内部構成は、例えば、図２に示すようになる。
【００４２】
主要領域とは、ＷＷＷページ上の複数の領域のうちユーザ（ここでは、Ｕ１）にとって最も重要であると推定できる１つの領域のことである。本実施形態では、基本的に、更新の頻度が最も高い領域が主要領域であるものと想定している。したがって、例えば、図１に示したフレームページの場合なら、領域Ａ〜Ｃのうち、ユーザＵ１にとって最も重要であると推定できる（最も更新の頻度が高い）いずれか１つの領域が主要領域となる。また、メニューを有するフレームページの典型的な使用方法に対応して、ターゲットのフレームの内容（例えば、領域Ｃ）だけが置き換わった複数のフレームページごとに、主要領域を決定するようにしてもよい。
【００４３】
（Ａ−１−２）領域処理部の内部構成例
図２において、当該領域処理部２５は、読み込み部１０１と、バッファ部１０２と、分割部１０３と、分割結果記憶部１０４と、領域内容比較部１０５と、更新頻度算出部１０６と、更新頻度記憶部１０７と、判定部１０８とを有する。
【００４４】
読み込み部１０１は、定期的にあるいは不定期（ユーザＵ１が読み込みを指示した時など）に指定されたＵＲＬ（例えば、前記ＵＲＬ１１）のフレームページに関する情報Ｎ１０をバッファ部１０２に読み込む部分である。この読み込みは、記憶部２３内の前記キャッシュ領域などから行うようにしてもよいが、通常は、インターネット１１経由でＷＷＷサーバ１３から行うことになる。
【００４５】
このようなインターネット１１経由の読み込みを可能にするため、当該読み込み部１０１は、前記ＷＷＷブラウザＢ１の一部として機能するか、前記ＷＷＷブラウザＢ１と連携するか、あるいは、ＷＷＷブラウザＢ１と独立したＨＴＴＰクライアントとしての機能を備える必要がある。
【００４６】
読み込み部１０１が読み込んだ時点のファイルの内容は、一例として、図５に示す複合ファイルＳＰ１のようなものであってもよい。
【００４７】
図５において、複合ファイルＳＰ１は、図４（Ａ）〜（Ｄ）に示すＨＴＭＬファイルＤＰ１１〜ＤＰ１４の内容を合成したものとなっている。ただしフレーム規定ファイルＤＰ１１の内容は、４つの部分ＰＴ１〜ＰＴ４に分割されて配置されている。
【００４８】
ＷＷＷサーバ１３側でファイルＤＰ１１〜ＤＰ１４が１つのフレームページに対応するファイルであることを管理しておき、フレーム規定ファイルＤＰ１１に対するＨＴＴＰリクエストが受信された時点で４つのファイルＤＰ１１〜ＤＰ１４をもとに１つの合成ファイルＳＰ１を生成して返送するようにすれば、合成ファイルＳＰ１のようなファイルを１つのＨＴＴＰレスポンスのエンティティボディとして返送することも可能であるが、ＷＷＷサーバ１３の負荷や、キャッシュシステムとの親和性などを考慮すると、不利であるため、ＷＷＷサーバ１３側でそのような処理は行わないほうが望ましい。
【００４９】
ＷＷＷサーバ１３側でそのような処理を行わない場合、図１に示すフレームページＤＰ１を閲覧するには、全部で４回のＨＴＴＰリクエストが通信端末１２から送信され、それにこたえて、順次、４回のＨＴＴＰレスポンスがＷＷＷサーバ１３から返されることになり、そのうち３回のＨＴＴＰレスポンスのエンティティボディが、ファイルＤＰ１２〜ＤＰ１４である。
【００５０】
したがって、ＳＰ１のようなファイルは、多くの場合、通信端末１２がすべてのファイルＤＰ１１〜ＤＰ１４を受信したあとの処理（整形処理）によって、はじめて得られるものである。
【００５１】
バッファ部１０２は、読み込み部１０１が読み込んだ内容や分割部１０３が処理した結果を一時的に記憶する部分である。当該バッファ部１０２や、分割結果記憶部１０４，更新頻度記憶部１０７などの記憶機能を実現するための記憶資源は、前記記憶部２３とは別個に確保してもよいが、前記記憶部２３内で確保するようにしてもよい。
【００５２】
分割部１０３は、バッファ部１０２に読み込まれたフレームページを解析することによって、予め指定された文書構造に基づいて、バッファ部１０２の記憶内容を領域に分割する部分である。ただしフレームページの場合、フレームページ上の各領域（例えば、領域Ａ〜領域Ｃ）は異なるＨＴＭＬファイルに対応し、最初から（すなわち、前記整形処理を行う前は）別ファイルに分割されているため、通常のファイル管理を行うことのできるファイルシステムを搭載していれば、分割は省略できる可能性がある。ファイル管理は通常、ＯＳの役割であるから、分割部１０３はＯＳに対して、例えば、バッファ部１０２上の次のファイルを渡すように要求しその応答としてのファイルを受け取る処理を繰り返すだけでよい。
【００５３】
ただし前記ＷＷＷブラウザＢ１と当該領域処理部２５（読み込み部１０１）のインタフェースなどとの関係で、整形処理前のファイルＤＰ１１〜ＤＰ１４を受け取ることができず、整形処理後の合成ファイルＳＰ１しか受け取ることができない場合などには、分割が必要になる。
【００５４】
分割は、例えば図５に示す合成ファイルＳＰ１から、部分ＰＴ１〜ＰＴ４を除外して図６に示す３つのファイルＤＰ１２，ＤＰ１３，ＤＰ１４を得る処理である。
【００５５】
分割部１０３が分割した（ＯＳから受け取った）ファイル（例えば、ＤＰ１２〜ＤＰ１４）は、分割結果記憶部１０４へ供給する。
【００５６】
分割結果記憶部１０４は、分割部１０３から前回、供給を受けたファイルＮ１１を記憶しておく部分である。前回、供給を受けたファイルＮ１１は、今回、供給を受けバッファ部１０２内に格納した該当するファイルＮ１２と比較するために記憶するものであるから、前回と今回で、各ファイルの対応関係がわかるような形で記憶しておく必要があることは当然である。例えば、前回の領域ＣのＨＴＭＬファイルと、今回の領域ＣのＨＴＭＬファイルＤＰ１４が、他のＨＴＭＬファイル（例えば、領域ＢのＨＴＭＬファイルＤＰ１３など）と混同されないようにしておく必要がある。
【００５７】
この対応付けには、例えば、各ＨＴＭＬファイルのファイル名（例えば、ＵＲＬ１２〜１４）を利用することもでき、システム内部で各ＨＴＭＬファイルに付与した固有のファイル識別子（領域番号）を利用することもできる。
【００５８】
領域内容比較部１０５は、分割結果記憶部１０４が記憶している前回、供給を受けた各ファイルＮ１１とバッファ部１０２が記憶している今回、供給を受けた各ファイルとを、ファイルごとに（すなわち、領域ごとに）内容を比較して更新の有無を検出する部分で、検出結果として、更新有無情報Ｎ１６を出力する。更新とは、ファイルの内容の一部または全部が、追加、削除、または、変更されることである。
【００５９】
更新頻度算出部１０６は、当該更新有無情報Ｎ１６の内容と前回までの更新頻度から所定の式に基づいて今回の更新頻度Ｓを算出し更新頻度Ｓに応じた更新頻度情報Ｎ１７を出力する部分である。更新頻度Ｓの算出は、ファイルごと（領域ごと）に行う。更新頻度は、ファイルの更新の頻度が増加するほどその値が増加するものであってもよいが、本実施形態では、ファイルの更新の頻度が増加するほどその値が減少するものを用いる。
【００６０】
また、前記式としては様々な形の式を用いることが可能であるが、本実施形態では、指数平均による次の式（１）を用いるものとする。
【００６１】
Ｓ＝Ｓ０α＋Ｐ（１−α）　　…（１）
ここで、Ｓ０は、前回までの更新頻度であり、αは０＜α＜１の定数であるが、ここではα＝０．８とする。また、Ｐは得点であり、１００または０のいずれかの値を持つ。後述するように、更新が行われた場合には得点Ｐを０とし、更新が行われていない場合には１００とするため、更新頻度Ｓの値は、（Ｓ０を正の値とすると）更新が行われるたびに小さくなる。
【００６２】
なお、ＧＥＴリクエストに対するＨＴＴＰレスポンスでは、エンティティボディ（ファイル）のほかに、各種ＨＴＴＰヘッダも返送されるため、更新頻度算出部１０６の処理において、ＨＴＴＰヘッダ中の情報を利用することも望ましい。
【００６３】
例えば、ＨＴＴＰヘッダの１つであるエンティティヘッダに含まれる更新日情報や有効期限情報を利用することも望ましい。
【００６４】
更新日情報は、ＷＷＷサーバ１３側でファイルが更新された日付を示す情報である。
【００６５】
また、有効期限情報は、ファイルを（前記キャッシュ領域やキャッシュサーバなどに）キャッシュする際の有効期限を設定するための情報で、提供するファイルの内容の最新性を維持するために使用される。有効期限情報は、通常、ファイルの作成者（ＷＷＷページの作成者）など、ＷＷＷサーバ１３側の都合に合わせて設定される。有効期限が経過すれば、たとえ記憶容量に余裕があっても、通信端末１２（あるいは、通信端末１２とＷＷＷサーバ１３のあいだに介在する前記キャッシュサーバ）は、当該ファイルをキャッシュ領域から削除し、オリジナルのファイルをＷＷＷサーバ（ここでは、１３）から取得することになる。したがって、有効期限を短く設定すれば高頻度の更新が行われても最新の内容を持つファイルをユーザ（ここでは、Ｕ１）に提供できる可能性が高まる利点があるが、有効期限を短く設定するとキャッシュの利点が小さくなりＷＷＷサーバ１３側の負荷も増大するため、通常は、できるだけ長い有効期限を設定しようとする。
【００６６】
このため、有効期限情報は、ＷＷＷページの作成者などが、当該ファイルをどの程度の頻度で更新する予定であるか、あるいは、どの程度の頻度で更新される（例えば、電子掲示板（ＣＧＩ掲示板）など、第３者によってファイルの更新が行われるＷＷＷページの場合（ただし、普通、電子掲示板はキャッシュ禁止とする））と予想しているかを示す情報（更新予定情報）であるとみることもできる。ＷＷＷページの作成者等は、通常、ユーザＵ１などからは知ることのできない、自身の予定やＷＷＷページの性質などを熟知しているはずだから、更新予定情報としての有効期限情報の信頼度は高いといえる。
【００６７】
前記更新頻度算出部１０６がこのような有効期限情報を利用する方法には様々なものがあり得るが、例えば、更新頻度Ｓを算出する際、有効期限情報が示す有効期限が短いほど、更新頻度Ｓが高頻度側に変更されるように重み付けを施すことも望ましい。
【００６８】
当該更新頻度算出部１０６から当該更新頻度Ｓに応じた更新頻度情報Ｎ１７を受け取る更新頻度記憶部１０７は、領域ごとに、当該更新頻度情報Ｎ１７を記憶する部分である。
【００６９】
判定部１０８は、更新頻度記憶部１０７の記憶する更新頻度情報Ｎ１７に基づいて最も頻繁に内容が変化している領域を主要領域と判定し、バッファ部１０２から該当領域の内容を取り出してそれを出力する部分である。主要領域の出力先には様々なものが考えられるが、例えば、ＷＷＷブラウザＢ１であってよい。ＷＷＷブラウザＢ１が当該主要領域を表示部２４に画面表示するために必要であれば、前記フレーム規定ファイルＤＰ１１も、当該主要領域とともにＷＷＷブラウザＢ１へ出力するとよい。
【００７０】
一方、前記ＨＴＴＰリクエストにこたえてＨＴＴＰレスポンスを返すＷＷＷサーバ１３の内部構成例は、図１７に示す。
【００７１】
（Ａ−１−３）ＷＷＷサーバの内部構成例
図１７において、当該ＷＷＷサーバ１３は、通信部３０と、制御部３１と、記憶部３２とを備えている。
【００７２】
このうち通信部３０は前記通信部２０に対応し、制御部３１は前記制御部２１に対応し、記憶部３２は前記記憶部２３に対応するので、その詳しい説明は省略する。
【００７３】
ただし制御部３１は、ＷＷＷブラウザ（Ｂ１など）を搭載することはなくＷＷＷサーバソフトを搭載している。
【００７４】
また、ＷＷＷサーバ１３が、予め生成したＷＷＷページ等を蓄積しておくためのデータベースを伴う場合には、必要に応じて、ＤＢＭＳも、当該制御部３１に搭載され得る。
【００７５】
さらに、前記フレームページＤＰ１を提供するため、当該記憶部３２には、少なくとも、ＨＴＭＬファイルＤＰ１１〜ＤＰ１４が格納されている。
【００７６】
以下、上記のような構成を有する本実施形態の動作について、図３，図７、図８の各フローチャートを参照しながら説明する。
【００７７】
図３は更新頻度情報Ｎ１７などの情報を更新するためのフローチャートで、Ｓ１０１〜Ｓ１０４の各ステップを備えている。同様に、図７は更新頻度情報Ｎ１７などをもとに、主要領域の内容を判定し出力するためのフローチャートで、Ｓ１０１、Ｓ１０２，Ｓ１０５の各ステップを備えている。
【００７８】
また、図８は更新頻度Ｓの算出またはその近傍の処理を示すフローチャートで、Ｓ１５１〜Ｓ１６０の各ステップを備えている。図８のフローチャートは、図３中のステップＳ１０３の詳細な動作を示すものである。
【００７９】
（Ａ−２）第１の実施形態の動作
ユーザＵ１が操作部２２を操作することによって、または、前記オートパイロットツールなどの機能によって、ＵＲＬ１１がＷＷＷブラウザＢ１に入力されると、ＷＷＷブラウザＢ１が当該ＵＲＬ１１に対応したＨＴＴＰリクエスト（ＧＥＴリクエスト）を送信する。
【００８０】
ただし前記読み込み部１０１に前記ＷＷＷブラウザＢ１と独立したＨＴＴＰクライアントとしての機能を持たせる場合には、この入力はＷＷＷブラウザＢ１ではなく、当該読み込み部１０１に対して行うことは当然である。
【００８１】
通信端末１２から送信されたこのＨＴＴＰリクエストをインターネット１１経由で受信すると、ＷＷＷサーバ１３（およびサーバＯＳ）は、前記記憶部３２から当該ＵＲＬ１１によって指定されるフレーム規定ファイルＤＰ１１を取り出し、当該フレーム規定ファイルＤＰ１１をエンティティボディとして含むＨＴＴＰレスポンスを返送する。
【００８２】
フレームページＤＰ１を構成するその他のＨＴＭＬファイルＤＰ１２〜ＤＰ１４は、上述したように、当該フレーム規定ファイルＤＰ１１が通信端末１２に受信されたあと、当該フレーム規定ファイルＤＰ１１中の記述（ＵＲＬ１２〜ＵＲＬ１４）に基づいて、ＷＷＷブラウザＢ１が順次、自動的に送信する各ＨＴＴＰリクエストに応じた各ＨＴＴＰレスポンスのエンティティボディとして、通信端末１２に受信されるから、これらを、前記読み込み部１０１が読み込むことになる。
【００８３】
ただしＷＷＷサーバ１３側で前記合成ファイルＳＰ１を生成する場合には、この合成ファイルＳＰ１をエンティティボディとして含むＨＴＴＰレスポンスが返されることになる。
【００８４】
図３に示すように、通信端末１２の領域処理部２５に含まれる読み込み部１０１は単独で、またはＷＷＷブラウザＢ１と連携して当該ファイル（ＤＰ１１またはＳＰ１）を読み込んでバッファ部１０２へ格納することになる（Ｓ１０１）。単独で読み込む場合には、ＨＴＴＰレスポンスのエンティティボディがそのまま読み込み部１０１に読み込まれ、ＷＷＷブラウザＢ１と連携して読み込む場合には、ＷＷＷブラウザＢ１側で処理を施された結果が、読み込み部１０１に読み込まれることになる。
【００８５】
いずれの場合も、このとき読み込み部１０１に読み込まれるファイルには、図４（Ａ）に示すフレーム規定ファイルＤＰ１１と図５に示す合成ファイルＳＰ１の２通りがあり得る。
【００８６】
このとき読み込み部１０１に読み込まれるファイルが合成ファイルＳＰ１である場合には分割する（Ｓ１０２）が、フレーム規定ファイルＤＰ１１である場合には、分割する必要はない。
【００８７】
ただしフレーム規定ファイルＤＰ１１である場合には、上述した３つのＨＴＭＬファイルＤＰ１２〜ＤＰ１４を取得するために、逐次、通信端末１２からＨＴＴＰリクエストを送信する必要があり、順次、受信されるＨＴＴＰファイルを読み込む必要がある。
【００８８】
合成ファイルＳＰ１を用いる場合も用いない場合も、各ＨＴＭＬファイルＤＰ１２〜ＤＰ１４は、前記ファイル名のほか、前記領域番号によって識別し対応付けることが可能である。
【００８９】
ここでは一例として、ＨＴＭＬファイルＤＰ１２には領域番号１を付与して領域１とし、ＨＴＭＬファイルＤＰ１３には領域番号２を付与して領域２とし、ＨＴＭＬファイルＤＰ１４には領域番号３を付与して領域３とする。
【００９０】
次に、ステップＳ１０３では、前記領域内容比較部１０５が、今回、読み込んだ（必要に応じて、分割された）ファイルと前回、読み込んだファイルとを比較して更新の有無を検出し、それをもとに更新頻度算出部１０６が更新頻度Ｓを算出し、さらに、算出した更新頻度Ｓを更新頻度記憶部１０７が記憶する。
【００９１】
そして、今回、読み込んだ（分割された）ファイルＤＰ１２〜ＤＰ１４の内容は、前回、読み込んだファイルに置き換える形で、分割結果記憶部１０４に格納し、次回の新たな読み込みに備える（Ｓ１０４）。
【００９２】
このようなステップＳ１０１〜１０４の処理は、必要に応じて、複数回、繰り返される。わずかの回数（例えば、１回）、更新が検出されただけでは、偶然、そのタイミングでそのファイルが更新されただけかもしれないので、このような偶然性を排除して真に更新の頻度が高いか否かを見極め所期の効果を得るためには、繰り返しの回数が多いほうが望ましく、更新の有無の検出は長期間にわたって行うほうが望ましいことは当然である。
【００９３】
なお、必要に応じて、前記有効期限情報（更新予定情報）を活用することにより、繰り返しの回数が比較的すくなく、更新の有無を検出する期間が比較的みじかい場合でも、偶然性を排除できる可能性がある。
【００９４】
また、繰り返しの回数が少なく、更新の有無の検出期間が短い場合、最近、更新が行われたファイルほど主要領域として選ばれる確率が高まる。ユーザＵ１にとって最も重要な領域は、最も近い過去に更新された領域であると想定することができるとするなら、繰り返しの回数が少なく、更新の有無の検出期間が短くても、重要な領域を選択できる。
【００９５】
前記ステップＳ１０３の詳細を示す図８では、前記領域番号を利用して、各ファイルＤＰ１２〜ＤＰ１４を識別している。
【００９６】
図８において、ステップＳ１５２〜Ｓ１５９は、バッファ部１０２に格納されている各ファイルＤＰ１２〜ＤＰ１４に付与された領域番号をもとに、ファイルごとに（領域番号ごとに）繰り返される。
【００９７】
このうちステップＳ１５２では、前回、読み込んだ（前回、分割した）ファイルと、今回、読み込んだ（今回、分割した）ファイル、すなわち、分割結果記憶部１０４に格納されているファイルとバッファ部１０２に格納されているファイルを、前記領域番号をもとに対応付けて比較する（Ｓ１５３）。
【００９８】
比較の結果、内容が同じであれば、すなわちファイルが更新されていなければ、ステップＳ１５３はＹｅｓ側に分岐し、前記式（１）の得点Ｐに１００を設定し（Ｓ１５５）、当該式（１）に基づいて更新頻度Ｓを算出する（Ｓ１５７）。ここで算出された更新頻度Ｓにより、前回、算出され更新頻度記憶部１０７に記憶されていた更新頻度Ｓ０が置換される。
【００９９】
比較の結果、前記領域１の内容が前回と同じであり、領域１の前回の更新頻度Ｓ０をＳ０＝７３とすると、図９に示すように、前記式（１）にしたがって、領域１の今回の更新頻度Ｓは、７８（≒７３×０．８＋１００×（１−０．８））となる。
【０１００】
また、前記領域２の内容が前回と同じであり、領域２の前回の更新頻度Ｓ０をＳ０＝７３とすると、領域１の今回の更新頻度Ｓも、７８となる。
【０１０１】
一方、前記ステップＳ１５３における比較の結果、内容が同じでなければ、すなわちファイルが更新されていれば、ステップＳ１５３はＮｏ側に分岐し、分割数が同じであるか否かを検査する（Ｓ１５４）。分割数とは、前記フレームページＤＰ１を構成するフレーム規定ファイルＤＰ１１以外のファイルの数であるから、このステップＳ１５４では、前記フレーム構造（特に、フレームの数）そのものが変化しているか否かを検査していることになる。
【０１０２】
なお、フレーム構造の変化の有無は、このように分割数を調べなくても、直接、前記フレーム規定ファイルＤＰ１１の記述内容を解析（例えば、「＜ＦＲＡＭＥ　ｓｒｃ」という文字列の数をカウントする）することによっても、検査することが可能である。
【０１０３】
また、フレーム構造の概念には上述したように、フレームの数だけでなく、各フレームの辺の長さの割合なども含まれるが、ステップＳ１５４では、フレームの数だけを問題にしている。したがって、フレーム規定ファイルＤＰ１１の記述が変化し各フレームの辺の長さの割合などが変化したとしても、フレームの数が同じであればステップＳ１５４はＹｅｓ側に分岐する。もちろん、必要ならば、フレーム規定ファイルＤＰ１１の記述が少しでも変化したらステップＳ１５４をＮｏ側に分岐させるようにしてもよい。
【０１０４】
例えば、行ＴＧ１２〜ＴＧ１４に記述されているＵＲＬ１２〜ＵＲＬ１４のいずれかが変化した場合には、同じファイルの内容が更新されたのではなく、そのフレームに配置されるファイルが別ファイルに変更されたことを意味するため、ステップＳ１５４をＹｅｓ側に分岐させるようにしてもよい。
【０１０５】
一例として、それまで領域１〜領域３の３つの領域しか存在しなかったフレームページＤＰ１に、図１０に示す領域４（領域番号４を付与した領域）のような新たな領域が出現した場合には、ステップＳ１５４はＮｏ側に分岐し、当該領域４の更新頻度Ｓには０が設定され（Ｓ１５８）、処理は前記ステップＳ１５９に進む。この場合、当該０は更新頻度の初期値であり、フレームページＤＰ１のフレーム構造そのものが変化してしまったため、比較すべき領域がなくなったとみなして、更新頻度を初期値にリセットしたものである。
【０１０６】
また、分割数が同じであってステップＳ１５４がＹｅｓ側に分岐すると、その領域には、前記得点Ｐに０を設定して（Ｓ１５６）、処理をステップＳ１５７に進める。
【０１０７】
ここで、図９に示すように、領域３に対する処理でステップＳ１５４がＹｅｓ側に分岐し、領域３の前回の更新頻度Ｓ０をＳ０＝４６とすると、前記式（１）にしたがって、領域３の今回の更新頻度Ｓは、３７（≒４６×０．８＋０×（１−０．８））となる。
【０１０８】
以上のようにして、更新頻度記憶部１０７に記憶されている各領域１〜領域３の更新頻度Ｓの更新は、１または複数回おこなわれるが、更新頻度Ｓをもとに、前記主要領域を判定し、当該主要領域を出力する場合は、図７のようなフローチャートとなる。
【０１０９】
図７において、図３と同じ符号Ｓ１０１，Ｓ１０２を付与した各ステップの処理は図３と同じである。
【０１１０】
したがって、図７が図３と相違する点は、ステップＳ１０５だけである。
【０１１１】
ステップＳ１０５では、前記判定部１０８が、その時点で更新頻度記憶部１０７に記憶されている更新頻度Ｓに基づいてフレームページＤＰ１上から主要領域を判定し、出力する。例えば、前記領域３に対応するＨＴＭＬファイルＤＰ１４の更新頻度Ｓが最も更新の頻度が高い値を有する場合には、当該ＨＴＭＬファイルＤＰ１４が主要領域として選ばれ、出力されることになる。
【０１１２】
なお、必要ならば、更新の頻度が同じ値の領域が複数、存在する場合、前記有効期限情報などをもとに、１つの主要領域を特定するようにしてもよい。また、必要ならば、複数の領域を主要領域として出力したり、主要領域としては１つの領域を出力するが、更新の頻度が当該主要領域と同じ値を示す領域がほかに存在することをユーザＵ１に伝えるようにしてもよい。
【０１１３】
また、前記オートパイロットツールのようなソフトウエアに、前記日時や時間間隔のほか、前記ＵＲＬ１１のようなフレーム規定ファイルを指定するためのＵＲＬを複数設定しておけば、同時進行で、多数のフレームページに対して同様な処理を行うことができる。これにより、多数のフレームページから主要領域だけを選択して出力させることが可能になり、ユーザＵ１は少ない労力と時間で、効率的に、多くのフレームページの要点を認識することができる。
【０１１４】
ただしその場合には、分割結果記憶部１０４、更新頻度記憶部１０７はフレームページごとに整理して情報を記憶する必要がある。
【０１１５】
また、本実施形態では、特許文献１のように、ユーザＵ１が、データの開始箇所と終了箇所をあらかじめ手入力により指定する必要がないため、ユーザＵ１の操作負担が軽減できる。
【０１１６】
なお、本実施形態では、自動的に主要領域を判定できるので、（ｉ）指定ウェブページの更新時の通知（主要領域以外の更新は通知しない、など）、（ｉｉ）検索（主要領域以外は検索対象としない、など）、（ｉｉｉ）要約（主要領域のみを要約対象とする、など）等のサービスやシステムを容易に構築することが可能となる。
【０１１７】
（Ａ−３）第１実施形態の効果
本実施形態によれば、フレームページから選択した主要領域を出力するためのユーザ（Ｕ１）の操作負担を軽減することが可能である。特に、多数のフレームページから主要領域だけを選択して出力させる場合に有効である。
【０１１８】
また、本実施形態は、基本的に自然言語処理を用いることなく実行可能であるため、記述言語に依存せずに主要領域を判定することができる。
【０１１９】
さらに、本実施形態では、フレームページの解析を実施するが、予め指定した文書構造だけを処理すればよいので、全ての解析をするよりも処理量が少ない。
【０１２０】
（Ｂ）第２の実施形態
以下では、本実施形態が第１の実施形態と相違する点についてのみ説明する。
【０１２１】
第１の実施形態ではファイルの内容そのものを記憶し比較することで更新の有無の検出などを行ったが、本実施形態では、ファイルの内容の替わりに、ファイルの内容のチェックサムを用いる。
【０１２２】
（Ｂ−１）第２の実施形態の構成および動作
本実施形態と第１の実施形態は、前記領域処理部２５の内部構成が相違するだけであるから、図１５，図１６，図１７に示した構成は本実施形態でもそのまま用いることができる。本実施形態の領域処理部には符号３５を付与して第１の実施形態の領域処理部２５と区別する。
【０１２３】
領域処理部３５の内部構成例は図１２に示す通りである。
【０１２４】
図１２において、当該領域処理部３５は、読み込み部１０１と、バッファ部１０２と、分割部１０３と、更新頻度算出部１０６と、更新頻度記憶部１０７と、判定部１０８と、チェックサム算出部２０１と、チェックサム記憶部２０２と、チェックサム比較部２０３とを有する。
【０１２５】
このうち図２と同じ符号１０１〜１０３，１０６〜１０８、Ｎ１０〜Ｎ１２，Ｎ１７〜Ｎ１９を付与した各構成要素および各信号（各情報）の機能は第１の実施形態と同じであるので、その詳しい説明は省略する。
【０１２６】
また、前記チェックサム記憶部２０２は前記分割結果記憶部１０４に対応し、チェックサム比較部２０３は前記領域内容比較部１０５に対応する部分である。
【０１２７】
チェックサム記憶部２０２は、ファイルの内容（分割結果）の替わりに、チェックサム算出部２０１が当該ファイルの内容をもとに算出したチェックサムを示すチェックサム情報Ｎ３０を記憶する部分である。ファイルの内容に比べると、通常、そのチェックサムははるかにサイズが小さいため、チェックサム記憶部２０２の記憶容量は、分割結果記憶部１０４の記憶容量よりも小さくてよい。
【０１２８】
したがって、チェックサム比較部２０３は、前回、読み込んだファイルのチェックサムと、今回、読み込んだファイルのチェックサムを比較することによって、各ファイルの更新の有無を検出し、検出結果に応じた更新有無情報Ｎ３３を出力する。
【０１２９】
今回、読み込んだファイルのチェックサムを示すチェックサム情報Ｎ３１も、今回、読み込まれバッファ部１０２内に格納されたファイルの内容をもとに、前記チェックサム算出部２０１が算出する。
【０１３０】
チェックサムをもとにファイルの更新の有無を検出すると、実際には更新されているのに更新されていないものとする誤検出が発生する可能性があるが、チェックサムのサイズ（ビット数）を長くすること等により、このような誤検出の発生確率を抑制することが可能である。
【０１３１】
本実施形態の動作を示すフローチャートは図７，図１３，図１４に示す通りである。このうち図７のフローチャートは、第１の実施形態と同じものを本実施形態でも用いる。
【０１３２】
また、図１３のフローチャートは図３のフローチャートに対応し、同じ符号Ｓ１０１，Ｓ１０２を付与した各ステップの処理内容は第１の実施形態と同じであるので、その詳しい説明は省略する。
【０１３３】
図１３において、ステップＳ２０１は図３のステップＳ１０３に対応し、ステップＳ２０２は図３のステップＳ１０４に対応する。
【０１３４】
ステップＳ２０１はＳ１０３と比べ、ファイルの内容ではなくチェックサムに基づいて更新の有無を検出する点が相違するだけである。
【０１３５】
また、ステップＳ２０２では、今回、読み込んだファイルのチェックサムを、次回の新たなファイルの読み込みに備えて、前記チェックサム記憶部２０２に格納する。
【０１３６】
一方、図１４のフローチャートは図８のフローチャートに対応し、同じ符号Ｓ１５４〜Ｓ１６０を付与した各ステップの処理内容は第１の実施形態と同じであるので、その詳しい説明は省略する。
【０１３７】
また、ステップＳ２５１〜Ｓ２５３でも、すでに述べたように、ファイルの内容の替わりにそのチェックサムを用いる点が第１の実施形態と相違するだけである。
【０１３８】
（Ｂ−３）第２の実施形態の効果
本実施形態では第１の実施形態の効果と同等な効果を得ることができる。
【０１３９】
加えて、本実施形態では、チェックサム記憶部（２０２）に相当する部分の記憶容量が、第１の実施形態よりも少ないため、記憶資源を節約することができる。
【０１４０】
また、チェックサムのサイズがファイルのサイズよりも小さければ、メモリなどの記憶資源に対する読み書きアクセスのための時間も短いため、処理時間を短縮できる可能性がある。
【０１４１】
（Ｃ）他の実施形態
上記第１の実施形態で、前回との比較を実施するために分割した結果を記憶しておくように構成したが、読み込んだ内容をそのまま記憶しておき、比較する前に改めて分割するようにしてもよい。
【０１４２】
なお、分割した領域に対して合成ファイルＳＰ１の記述の順番に従って対応付けを実施したが、フレームページの内部でそれぞれの領域を識別することができる情報（例えば、前記ＵＲＬ１２〜ＵＲＬ１４）が付加されているので、その情報を使うように構成してもよいことはすでに述べた通りである。
【０１４３】
また、上記第２の実施形態ではチェックサムを使うと説明したが、チェックサム以外の誤り検出方式に対応する符号を利用することもできる。また、ハッシュ関数を用いてファイルの内容を変換した値（ハッシュ値）を、前記チェックサムの替わりに利用するようにしてもよい。
【０１４４】
なお、上記第１および第２の実施形態では、ＨＴＴＰリクエストとしてＧＥＴリクエスト（ＧＥＴメソッド）を用いる場合についてのみ説明したが、ＨＥＡＤリクエスト（ＨＥＡＤメソッド）を利用してもよい。
【０１４５】
ＨＥＡＤリクエストに対するＨＴＴＰレスポンスは、エンティティボディ（ファイル）が含まれていないこと以外、ＧＥＴリクエストに対するＨＴＴＰレスポンスと同じである。したがって通信端末１２は、当該ＨＥＡＤリクエストを送信しても、前記ＷＷＷサーバ１３から前記エンティティヘッダに含まれる有効期限情報や更新日情報などを取得することができる。
【０１４６】
この場合、通信端末１２では更新日情報などをもとに各ファイルの更新の有無を検出することが可能である。また、ＨＥＡＤリクエストによれば、サイズの大きなファイル本体を取り扱わなくて済むため、ＷＷＷサーバ１３側でも通信端末１２側でも負荷が小さく、通信トラフィックも少ない。また、レスポンスタイムも短いため、高速な処理が実行可能である。
【０１４７】
さらに、更新日情報による更新の有無の検出と上記第１（または第２）の実施形態で述べたようなファイル本体（あるいは、そのチェックサム等）を比較することによる更新の有無の検出を混在させてもよい。例えば、ユーザＵ１がフレームページの閲覧を希望してＵＲＬ１１を入力した場合にはＧＥＴリクエストを用いて、ファイル本体を比較し、オートパイロットツールなどが自動的に更新の有無を検出する場合などには、ＨＥＡＤリクエストを用いて、更新日情報による更新の有無の検出を行うようにしてもよい。
【０１４８】
なお、更新日情報などＨＴＴＰヘッダに含まれる各種情報は、ＷＷＷサーバ１３側で収集された管理情報に基づいて記述されるため、ＷＷＷサーバ１３側でファイルの管理が適正に行われていない場合などには、誤った情報となる可能性がある。例えば、実際にはまったく内容が変更されたいないのに、ファイルの更新日が書き換えられ、更新が行われたかのうような更新日情報が生成される可能性もある。
【０１４９】
ファイル本体の内容（やそのチェックサム等）を比較することによる更新の有無の検出などでは、このような誤りが混入しない点で、信頼性が高いといえる。
【０１５０】
なお、図４（Ａ）〜（Ｄ）の例では、トップページがフレームページになっているが、トップページ以外のページをフレームページとしてもよいことは当然である。
【０１５１】
また、フレームページの場合、図１に示したように、領域Ｂのような狭いフレームにメニューを置き、領域Ｃのような広いフレームにそのメニューの選択に応じて変わる内容を置く構成が典型例であるが、メニューのないフレームページにも、本発明が適用できることは当然である。
【０１５２】
さらに、フレームページ以外のＷＷＷページに対しても本発明は適用可能であり、ＨＴＭＬ以外の言語（ＸＭＬやＳＧＭＬなど）による記述にも適用可能である。何らかの意味で、論理的に識別可能な複数の領域が含まれていればよいからである。
【０１５３】
例えば、複数の画像（画像ファイル）を含むＷＷＷページならば、各画像ファイルの更新頻度をもとにいずれかの画像ファイルを主要領域として判定してもよい。また、基本になるＨＴＭＬファイルとそのＨＴＭＬファイルに対応したＷＷＷページ上に表示される画像（画像ファイル）のあいだで更新頻度をもとに主要領域を判定することも可能である。この場合、主要領域として画像（画像ファイル）が選択されると画像だけを表示し、ＨＴＭＬファイルが選択されると画像を含まないＨＴＭＬファイルだけを表示してもよい。
【０１５４】
また、ファイル以外の単位をもとに領域を識別してもよいことは当然である。
【０１５５】
さらに、使用する通信プロトコルは必ずしもＨＴＴＰでなくてもかまわない。
【０１５６】
なお、上記第１、第２の実施形態では通信端末（クライアント）１２側に領域処理部２５（または３５）を配置したが、当該領域処理部の機能は、ＷＷＷサーバ１３側に配置したり、ＷＷＷサーバ１３と通信端末１２の中間に介在し得る例えばプロキシサーバなどに配置することも可能である。
【０１５７】
ＷＷＷサーバ１３側に配置した場合には、必ずしもＨＴＴＰによる通信を行わなくてもよいため、ＷＷＷサーバ１３のサーバＯＳが管理しているファイル管理の情報をそのまま活用し、更新の有無の検出などに利用することができる。
【０１５８】
また、第１および第２の実施形態では、フレームページがＷＷＷサーバ１３上に公開されたものであることを前提としているが、ＣＤ−ＲＯＭなどの記録媒体から得たフレームページ等にも本発明は適用できるので、対象とするフレームページ等は、必ずしもネットワーク経由で入手されるものでなくてもかまわない。
【０１５９】
さらに、本発明で使用する式は前記式（１）に限定する必要はないことはすでに述べた通りである。例えば、更新されたことが検出されるたびに更新頻度の値がインクリメント（あるいは、デクリメント）されるような単純な式を利用することも可能である。
【０１６０】
以上の説明では主としてハードウエア的に本発明を実現したが、本発明はソフトウエア的に実現することも可能である。
【０１６１】
【発明の効果】
本発明によれば、構造化文書の中から主要な領域を判定するために必要なユーザの操作負担を軽減することができる。
【図面の簡単な説明】
【図１】第１および第２の実施形態で使用する構造化文書の構成例である。
【図２】第１の実施形態で使用する領域処理部の構成例を示す概略図である。
【図３】第１の実施形態の「情報更新」時の動作を示すフローチャートである。
【図４】第１の実施形態の動作説明に用いる構造化文書の例を示す説明図である。
【図５】図４に示す構造化文書の各ファイルを読み込んだ結果の一例を示す説明図である。
【図６】図５の構造化文書を分割した結果の一例を示す説明図である。
【図７】第１の実施形態の「主要領域の内容出力」時の動作を示すフローチャートである。
【図８】第１の実施形態の更新頻度Ｓの算出方法を示すフローチャートである。
【図９】第１の実施形態の更新頻度Ｓの算出の具体例である。
【図１０】第１の実施形態の更新頻度Ｓの算出の具体例である。
【図１１】第１の実施形態の「情報更新」時の動作と「主要領域の内容出力」時の動作とまとめた場合のフローチャートである。
【図１２】第２の実施形態の領域処理部の構成例を示す概略図である。
【図１３】第２の実施形態の「情報更新」時の動作を示すフローチャートである。
【図１４】第２の実施形態の更新頻度Ｓの算出方法を示すフローチャートである。
【図１５】第１および第２の実施形態の通信システムの全体構成例を示す概略図である。
【図１６】第１および第２の実施形態で使用する通信端末の構成例を示す概略図である。
【図１７】第１および第２の実施形態で使用するＷＷＷサーバの構成例を示す概略図である。
【符号の説明】
１０１…読み込み部、１０２…バッファ部、１０３…分割部、１０４…分割結果記憶部、１０５…領域内容比較部、１０６…更新頻度算出部、１０７…更新頻度記憶部、１０８…判定部、２０１…チェックサム算出部、２０２…チェックサム記憶部、２０３…チェックサム比較部。
【図１】
2004086841.tif 000003
【図２】
2004086841.tif 000004
【図３】
2004086841.tif 000005
【図４】
2004086841.tif 000006
【図５】
2004086841.tif 000007
【図６】
2004086841.tif 000008
【図７】
2004086841.tif 000009
【図８】
2004086841.tif 000010
【図９】
2004086841.tif 000011
【図１０】
2004086841.tif 000012
【図１１】
2004086841.tif 000013
【図１２】
2004086841.tif 000014
【図１３】
2004086841.tif 000015
【図１４】
2004086841.tif 000016
【図１５】
2004086841.tif 000017
【図１６】
2004086841.tif 000018
【図１７】
2004086841.tif 000019