(57)【要約】      （修正有）【課題】Ｗｅｂサイトから収集したデータの更新処理の効率化を図り、検索サービスの品質向上を実現する方法及び情報収集装置を提供する。【解決手段】通信ネットワーク３０を介してＷｅｂサイト２０と接続可能な情報収集装置１０が、収集したＷｅｂサイト２０の情報を再収集する日時を再収集予定データとしてＷｅｂサイト２０の特定情報と関連付けてリクロールＤＢ６０に記憶し、リクロールＤＢ６０の記憶内容に基づいて、当該再収集予定データが示す日時が現在日時に達しているか否かを判定し、現在日時に達していると判定された場合に、前記再収集予定データに関連付けられた特定情報に基づいたＷｅｂサイト２０の情報を再収集し、現在日時に達していないと判定された場合に、前記情報の再収集を一時的に停止する。【選択図】図１
2008257695.tif 000002
【特許請求の範囲】
【請求項１】
通信ネットワークを介してＷｅｂサイトと接続可能な情報収集装置が前記Ｗｅｂサイトの情報を収集する情報収集方法であって、
前記収集した前記Ｗｅｂサイトの情報を再収集する日時を再収集予定データとして当該Ｗｅｂサイトの特定情報と関連付けてデータベースに記憶する記憶ステップと、
前記データベースの記憶内容に基づいて、当該再収集予定データが示す日時が現在日時に達しているか否かを判定する判定ステップと、
前記判定ステップにおいて現在日時に達していると判定された場合に、前記再収集予定データに関連付けられた特定情報に基づいた前記Ｗｅｂサイトの情報を再収集する再収集ステップと、
前記判定ステップにおいて現在日時に達していないと判定された場合に、前記情報の再収集を一時的に停止する一時停止ステップと、
を含む方法。
【請求項２】
請求項１に記載の方法であって、
前記一時停止ステップは、
前記判定ステップにおいて現在日時に達していないと判定された再収集予定データが示す日時までの間、前記Ｗｅｂサイトの情報の再収集を一時的に停止した後に当該情報の再収集を再開する方法。
【請求項３】
請求項１又は請求項２に記載の方法であって、
前記記憶ステップは、前記再収集予定データを前記再収集する日時の順番にソートして記憶する方法。
【請求項４】
請求項１から請求項３のいずれか一項に記載の方法であって、
前記記憶ステップは、前記Ｗｅｂサイトの情報を収集した日時に所定の期間を加算して前記再収集予定データを決定する方法。
【請求項５】
請求項４に記載の方法であって、
前記記憶ステップは、前記再収集予定データの決定の度に、前記所定の期間を変化させる方法。
【請求項６】
請求項１から請求項５のいずれか一項に記載の方法であって、
前記記憶ステップは、前記再収集する日時のデータに前記Ｗｅｂサイトの特定情報を連結したものを前記再収集予定データとして記憶する方法。
【請求項７】
請求項１から請求項６のいずれか一項に記載の方法であって、
前記Ｗｅｂサイトの情報の収集の成否を判定する成否判定ステップを更に含み、
前記記憶ステップは、前記成否判定ステップにおいて前記情報の収集が失敗したと判定された場合に、前記Ｗｅｂサイトの情報の収集を行った日時を基準として、前記情報の収集が成功した場合より相対的に短い期間経過後の日時を前記再収集予定データとして決定する方法。
【請求項８】
請求項１から請求項７のいずれか一項に記載の方法であって、
前記情報を収集された前記Ｗｅｂサイトの情報を再収集するか否かを所定条件に基づいて判定する再収集要否判定ステップを更に含み、
前記記憶ステップは、前記再収集要否判定ステップにおいて再収集すると判定された場合にのみ、前記再収集予定データを前記データベースに記憶する方法。
【請求項９】
通信ネットワークを介してＷｅｂサイトと接続可能であり、前記Ｗｅｂサイトの情報を収集する情報収集装置であって、
前記収集した前記Ｗｅｂサイトの情報を再収集する日時を再収集予定データとして当該Ｗｅｂサイトの特定情報と関連付けてデータベースに記憶する記憶手段と、
前記データベースの記憶内容に基づいて、当該再収集予定データが示す日時が現在日時に達しているか否かを判定する判定手段と、
前記判定手段が現在日時に達していると判定された場合に、前記再収集予定データに関連付けられた特定情報に基づいた前記Ｗｅｂサイトの情報を再収集する再収集手段と、
前記判定手段が現在日時に達していないと判定された場合に、前記情報の再収集を一時的に停止する一時停止手段と、
を備える情報収集装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報収集方法及び情報収集装置に関する。
【背景技術】
【０００２】
従来、インターネットの検索サイトでは、ユーザによるキーワード入力等の検索要求に応じて、検索結果をリストとしてユーザに提供するサービスが行われている。このような検索サイトの運営側は、通常、クローラ或いはロボット型検索エンジン等と呼ばれるプログラムを用いて、インターネット上のＷｅｂサイトにある文書や画像等のデータを収集している。そして、当該収集したデータに索引（インデクス）等をつけてデータベースに記憶し、ユーザによる検索要求に応じた検索結果リストを、当該データベースを参照して作成し、ユーザの端末に送信している。
【０００３】
このように、検索サイトは、ユーザの端末から検索要求があったときに、インターネット上のＷｅｂサイトを検索するのではなく、収集したデータを保存したデータベースを検索して検索結果をユーザに返すことが出来る。
【０００４】
ところで、現在世界中のＷｅｂサイトは次々に更新され、また新たなサイトが追加されているため、上述のような予め収集したデータベースの内容と実際のＷｅｂサイトの内容との間には差異が生じることになる。従って、検索サイトの運営者にとって、上述のデータの収集の頻度を高め、データベースに記憶したデータの「鮮度」を保つことにより、最新のデータに基づいた検索結果をユーザに提供することが、検索サービスの品質向上を図るための重要な課題となっている。
【０００５】
このような状況において、特許文献１に記載の技術によれば、Ｗｅｂサイトの情報を現在時刻の経過に応じて収集することができる。具体的には、サイト情報登録部には、アクセスすべき特定サイトに関する情報、収集を開始する日時を示す情報等を記憶しておき、サイト管理部が、情報収集開始時刻を読み出して現在時刻が情報収集開始時刻と一致するものがあると判定した場合に情報収集を開始する。
【特許文献１】特開２００４−３１８７４６号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
しかしながら、特許文献１に記載の技術によって、Ｗｅｂサイトから収集した膨大なデータを、効率よく更新することはできない。より具体的には、インターネット上のＷｅｂサイトの情報を収集するとコンテンツＤＢには膨大な量のデータが記憶されるため、一度、収集したデータを更新するには、そのデータ量に比例した処理時間を要する。このため、コンテンツＤＢのデータ更新にも膨大な処理時間がかかり、最新のデータに基づいた検索結果をユーザに提供することが困難であった。
【０００７】
ここで、図に基づき、従来の技術について説明する。図１０は、従来の情報収集装置によるデータ更新処理のシステム概要を示す図である。図１１は、従来のデータ更新処理を示すフローチャートである。
【０００８】
まず、検索サイトのクローラが、Ｗｅｂサイト２０上のコンテンツのデータを収集して（ステップＳ５０１）、そのコンテンツの情報にその情報収集した日時（最終クロール日時）やＵＲＬ等を関連付けて、コンテンツＤＢ５０に記憶する（ステップＳ５０２）。
【０００９】
次に、クロールキッカーが、コンテンツＤＢ５０から１レコード読み込み、情報収集したデータを更新するか否かを判定する（ステップＳ５０３）。その後、当該判定の結果に応じてキューイング（ステップＳ５０４）、ディスパッチ（ステップＳ５０５）を行って、再びＷｅｂサイト２０を参照して同様の処理を繰り返し行う（ステップＳ５０１）。
【００１０】
ステップＳ５０３におけるクロールキッカーは、コンテンツＤＢ５０から１レコード読み込み（ステップＳ６０１）、その読み込んだレコードから最終クロール日時を抽出する（ステップＳ６０２）。そして、最終クロール日時にクロール間隔（例えば、２週間）を加算した日時が、現在日時に達しているかどうか判定する（ステップＳ６０３）。
【００１１】
ここで、最終クロール日時にクロール間隔を加算した日時が、現在日時に達していないと判定した場合（ステップＳ６０３：ＮＯ）は、クロールキッカーが、コンテンツＤＢ５０から次のレコードを読み込み（ステップＳ６０１）、現在日時に達していると判定した場合（ステップＳ６０３：ＹＥＳ）は、読み出したレコードからＵＲＬを抽出して、スケジューラにキューイングする（ステップＳ６０５）。
【００１２】
そして、コンテンツＤＢ５０の全レコードに対して処理が終わると、クロールキッカーは検索サイトの運営者が設定する所定期間の間、適時スリープした後に（ステップＳ６０４）、再起動してデータ更新処理を行う。
【００１３】
以上のような処理でクロールキッカーは、Ｗｅｂサイト２０上のコンテンツのデータの再収集を行う。しかし、コンテンツＤＢ５０は、クローラにより上書き更新されて検索用のインデクスの作成やクロールの履歴管理のため等に用いられるので、レコードが時系列には並んでいない。そのため、クロールキッカーは、当該コンテンツＤＢ５０の全レコードについて最終クロール日時を抽出して、更新するか否かを判定する必要がある。
【００１４】
更に、コンテンツＤＢ５０は、新しいＷｅｂサイト２０のデータを記憶する処理や、ユーザからの検索要求に応じてデータを送信する処理等が並行して行われるため、頻繁にアクセスされて負荷となってしまう。このため、このコンテンツＤＢ５０に対するアクセス頻度を少なくして負荷を軽減させることが課題となっている。
【００１５】
そこで、本発明は、Ｗｅｂサイトから収集したデータの更新処理の効率化を図り、検索サービスの品質向上を実現することを目的とする。
【課題を解決するための手段】
【００１６】
より具体的には、本発明は、次のようなものを提供する。
【００１７】
（１）  通信ネットワークを介してＷｅｂサイトと接続可能な情報収集装置が前記Ｗｅｂサイトの情報を収集する情報収集方法であって、
前記収集した前記Ｗｅｂサイトの情報を再収集する日時を再収集予定データとして当該Ｗｅｂサイトの特定情報と関連付けてデータベース（例えば、リクロールＤＢ６０）に記憶する記憶ステップと、
前記データベース（例えば、リクロールＤＢ６０）の記憶内容に基づいて、当該再収集予定データが示す日時が現在日時に達しているか否かを判定する判定ステップと、
前記判定ステップにおいて現在日時に達していると判定された場合に、前記再収集予定データに関連付けられた特定情報に基づいた前記Ｗｅｂサイトの情報を再収集する再収集ステップと、
前記判定ステップにおいて現在日時に達していないと判定された場合に、前記情報の再収集を一時的に停止する一時停止ステップと、
を含む方法。
【００１８】
本発明のこのような構成によれば、前記情報収集装置は、前記収集した前記Ｗｅｂサイトの情報を再収集する日時を再収集予定データとして当該Ｗｅｂサイトの特定情報と関連付けてデータベースに記憶し、
前記データベースの記憶内容に基づいて、当該再収集予定データが示す日時が現在日時に達しているか否かを判定し、
前記判定ステップにおいて現在日時に達していると判定された場合に、前記再収集予定データに関連付けられた特定情報に基づいた前記Ｗｅｂサイトの情報を再収集する再収集し、
前記判定ステップにおいて現在日時に達していないと判定された場合に、前記情報の再収集を一時的に停止する。
【００１９】
このことにより、前記情報収集装置は、前記データベースから読み出した前記再収集予定データに基づいて、当該再収集予定データが示す日時が現在日時に達している場合にのみ、前記Ｗｅｂサイトの情報を再収集することができる。従って、２回目以降の前記Ｗｅｂサイトの参照時において、効率的に前記Ｗｅｂサイトの情報を収集することができる。ここで、更にＷｅｂサイトの情報の再収集を行った再収集予定データをデータベースから削除してもよい。この場合、当該データベースを参照することで、再収集の必要なＷｅｂサイトを確認することができる。
【００２０】
（２）  （１）に記載の方法であって、
前記一時停止ステップは、
前記判定ステップにおいて現在日時に達していないと判定された再収集予定データが示す日時までの間、前記Ｗｅｂサイトの情報の再収集を一時的に停止した後に当該情報の再収集を再開する方法。
【００２１】
本発明のこのような構成によれば、前記情報収集装置は、前記判定ステップにおいて現在日時に達していないと判定された再収集予定データが示す日時までの間、前記Ｗｅｂサイトの情報の再収集を一時的に停止した後に当該情報の再収集を再開する。
【００２２】
このことにより、前記情報収集装置は再収集を行う予定ではない日時の再収集予定データの読み込みを回避することができる。その結果、前記情報収集装置の前記データベースへのアクセス回数を削減することができる。
【００２３】
（３）  （１）又は（２）に記載の方法であって、
前記記憶ステップは、前記再収集予定データを前記再収集する日時の順番にソートして記憶する方法。
【００２４】
本発明のこのような構成によれば、前記情報収集装置は、前記再収集予定データを前記再収集する日時の順番にソートして記憶する。
【００２５】
このことにより、前記情報収集装置は、前記Ｗｅｂサイトの情報を再収集する予定の日時の順序で再収集予定データをデータベースから逐次読み出すことができる。その結果、前記情報収集装置は、前記データベースの全てを必ずしも参照することなく、前記Ｗｅｂサイトの情報の再収集を行うことができる。従って、前記情報収集装置は、データベースへのアクセスの際のシステム負荷を更に削減することができる。
【００２６】
（４）  （１）から（３）のいずれか一項に記載の方法であって、
前記記憶ステップは、前記Ｗｅｂサイトの情報を収集した日時に所定の期間を加算して前記再収集予定データを決定する方法。
【００２７】
本発明のこのような構成によれば、前記情報収集装置は、前記Ｗｅｂサイトの情報を収集した日時に所定の期間を加算して前記再収集予定データを決定する。
【００２８】
このことにより、前記情報収集装置は、前記所定の期間毎に前記再収集予定データに関連付けられた前記Ｗｅｂサイトを参照することができる。
【００２９】
（５）  (４）に記載の方法であって、
前記記憶ステップは、前記再収集予定データの決定の度に、前記所定の期間を変化させる方法。
【００３０】
本発明のこのような構成によれば、前記情報収集装置は、前記再収集予定データの決定の度に、前記所定の期間を変化させる。
【００３１】
このことにより、前記情報収集装置は、前記再収集予定データの決定の度に、異なる期間を前記所定期間として設定することができる。
【００３２】
その結果、前記情報収集装置が、前記Ｗｅｂサイトの情報を再収集する際に、毎回異なる期間の経過後に当該再収集処理を行うことができる。
【００３３】
このようにすることにより、前記Ｗｅｂサイトの管理者等が、次回の情報の再収集時期を予測してタイミングを合わせて前記Ｗｅｂサイトの更新を行ったりすることで、恣意的に最新情報を反映させる、といった運用を防ぐことができる。
【００３４】
（６）  （１）から（５）のいずれか一項に記載の方法であって、
前記記憶ステップは、前記再収集する日時のデータに前記Ｗｅｂサイトの特定情報を連結したものを前記再収集予定データとして記憶する方法。
【００３５】
本発明のこのような構成によれば、前記情報収集装置は、前記再収集する日時のデータに前記Ｗｅｂサイトの特定情報を連結したものを前記再収集予定データとして記憶する。
【００３６】
このことにより、前記情報収集装置は、前記再収集予定データから再収集する日時のデータを抽出することにより当該日時を確認し、Ｗｅｂサイトの情報の再収集を行うことができる。
【００３７】
その結果、前記情報収集装置は、前記再収集予定データを読み込むだけで、その後の一連の処理を行うことができるので、データベースへのアクセスに要するシステム負荷をより低減することができる。
【００３８】
（７）  （１）から（６）のいずれか一項に記載の方法であって、
前記Ｗｅｂサイトの情報の収集の成否を判定する成否判定ステップを更に含み、
前記記憶ステップは、前記成否判定ステップにおいて前記情報の収集が失敗したと判定された場合に、前記Ｗｅｂサイトの情報の収集を行った日時を基準として、前記情報の収集が成功した場合より相対的に短い期間経過後の日時を前記再収集予定データとして決定する方法。
【００３９】
本発明のこのような構成によれば、前記情報収集装置は、前記Ｗｅｂサイトの情報の収集の成否を判定し、
更に、前記情報の収集が失敗したと判定された場合に、前記Ｗｅｂサイトの情報の収集を行った日時を基準として、前記情報の収集が成功した場合より相対的に短い期間経過後の日時を前記再収集予定データとして決定する。
【００４０】
このことにより、前記情報収集装置は、前記Ｗｅｂサイトの情報の収集に失敗した場合に、より短い期間の経過後に当該Ｗｅｂサイトの情報を収集することができる。その結果、前記情報収集装置は、何らかの理由により情報の収集に失敗したＷｅｂサイトについて、収集した情報が古いまま放置される長くなることを防止できる。
【００４１】
（８）  （１）から（７）のいずれか一項に記載の方法であって、
前記情報を収集された前記Ｗｅｂサイトの情報を再収集するか否かを所定条件に基づいて判定する再収集要否判定ステップを更に含み、
前記記憶ステップは、前記再収集要否判定ステップにおいて再収集すると判定された場合にのみ、前記再収集予定データを前記データベースに記憶する方法。
【００４２】
本発明のこのような構成によれば、前記情報収集装置は、前記情報を収集された前記Ｗｅｂサイトの情報を再収集するか否かを所定条件に基づいて判定し、
前記再収集要否判定ステップにおいて再収集すると判定された場合にのみ、前記再収集予定データを前記データベースに記憶する。
【００４３】
このことにより、前記データベースには所定条件を満たすＷｅｂサイトについての再収集予定データが記憶されるため、データベースへのアクセスに要するシステム負荷をより低減することができる。
【００４４】
（９）  通信ネットワークを介してＷｅｂサイトと接続可能であり、前記Ｗｅｂサイトの情報を収集する情報収集装置であって、
前記収集した前記Ｗｅｂサイトの情報を再収集する日時を再収集予定データとして当該Ｗｅｂサイトの特定情報と関連付けてデータベースに記憶する記憶手段と、
前記データベースの記憶内容に基づいて、当該再収集予定データが示す日時が現在日時に達しているか否かを判定する判定手段と、
前記判定手段が現在日時に達していると判定された場合に、前記再収集予定データに関連付けられた特定情報に基づいた前記Ｗｅｂサイトの情報を再収集する再収集手段と、
前記判定手段が現在日時に達していないと判定された場合に、前記情報の再収集を一時的に停止する一時停止手段と、
を備える情報収集装置。
【００４５】
本発明のこのような構成によれば、前記情報収集装置は（１）と同様の作用及び効果を有する。
【発明の効果】
【００４６】
本発明によれば、前記情報収集装置は、前記データベースから読み出した前記再収集予定データに基づいて、再収集する日時が現在日時に達している場合にのみ、前記Ｗｅｂサイトの情報の収集を行うことができる。このため、２回目以降の前記Ｗｅｂサイトの参照時において、効率的に前記Ｗｅｂサイトの情報を収集することができる。従って、Ｗｅｂサイトから収集したデータの更新処理の効率化を図り、検索サービスの品質向上を実現することができる。
【発明を実施するための最良の形態】
【００４７】
以下、図面を参照しながら本発明の最良の実施形態の一例について述べる。
【００４８】
図１は、本実施形態の一例に係るシステム１の全体構成を示す図である。図２は、本実施形態の一例に係る情報収集装置１０の構成を示す図である。図３は、本実施形態の一例に係る情報収集装置１０の機能ブロック図である。図４は、本実施形態の一例に係る情報収集装置１０によるリクロール処理の概要を示す図である。図５は、本実施形態の一例に係るコンテンツＤＢ５０を示す図である。図６は、本実施形態の一例に係るリクロールＤＢ６０を示す図である。図７は、本実施形態の一例に係るクロールキッカーによる処理のフローチャートである。図８は、本実施形態の一例に係るリクロールＤＢ６０の先頭レコードに対する処理を示す図である。図９は、本実施形態の一例に係るクローラによるクロール処理のフローチャートである。図９Ａは、本実施形態の一例に係るクローラによるクロール処理におけるＸ±αの計算処理を示すフローチャートである。
【００４９】
［システムの全体構成］
図１は、本実施形態の一例に係るシステム１の全体構成を示す図である。
【００５０】
システム１は、情報収集装置１０が、通信ネットワーク３０を介してＷｅｂサイト２０と接続可能な状態で構成される。
【００５１】
Ｗｅｂサイト２０は、文書や画像等の情報（Ｗｅｂページともいう）を蓄積しており、通信ネットワーク３０、例えば、インターネット等のネットワークを通じて、これらの情報を端末に送信する機能を有している。更に、現在では動画やゲーム等の動的な情報等を、ネットワークを通じて提供するサービスもある。これらの情報を総称して、以下「コンテンツデータ」という。なお、個人や会社のホームページ等のコンテンツデータ群、又はコンテンツデータ群が置いてあるインターネット上の場所を、Ｗｅｂサイトという。
【００５２】
通信ネットワーク３０は、情報収集装置１０とＷｅｂサイト２０とを接続する。ここで、通信ネットワーク３０は、有線により実現するものだけではなく、携帯電話等のように、基地局を介して一部を無線により実現するもの、アクセスポイントを介して無線ＬＡＮにより実現するもの等、本発明の技術的思想に合致するものであれば様々な通信ネットワークにより実現してよい。
【００５３】
情報収集装置１０は、コンテンツＤＢ５０とリクロールＤＢ６０とを備えて構成されている。情報収集装置１０は、インターネット上のＷｅｂサイト２０をクロールして、収集したコンテンツデータの中から、ユーザが所望するコンテンツデータをリストにする機能等を有している。なお、クロールとは、クローラが、Ｗｅｂサイト２０を参照し、コンテンツデータを収集することである。クローラについては、図３で詳述する。
【００５４】
コンテンツＤＢ５０は、コンテンツデータ、最終クロール日時等を記憶するデータベースである。ここで、最終クロール日時は、コンテンツデータをコンテンツＤＢ５０に記憶した日時を示す。なお、コンテンツデータは所定の期間後にリクロールして更新する。リクロールとは、コンテンツＤＢ５０に記憶したコンテンツデータのＷｅｂサイト２０に再びアクセスして再収集することである。リクロールすることでコンテンツデータが最新の情報に更新される。
【００５５】
なお、管理者がリクロールをさせたい「所定の期間」を設定することで、「最終クロール日時」＋「所定の期間」によりリクロール予定日時が決まる。ここで、「所定の期間」は複数設定してもよい。例えば、コンテンツデータが正常に収集された場合には「２週間」、収集に失敗したと判定される場合には「５日間」と設定する。このようにして、クロール先のＷｅｂサイト２０に異常が発生した場合等の何らかの理由によりコンテンツデータの収集が失敗した場合は、当該コンテンツデータの収集を、正常に収集されたコンテンツデータの次回の収集より優先させてもよい。
【００５６】
リクロールＤＢ６０は、再収集予定データ等を記憶するデータベースである。ここで、再収集予定データとは、コンテンツＤＢ５０に記憶されたコンテンツデータの再収集を行う日時を示すデータであり、更新するリクロール予定日時等を含む。
【００５７】
［情報収集装置１０のハードウェア構成］
図２は、図１で説明した本実施形態の一例に係る情報収集装置１０のハードウェア構成の一例を示す図である。
【００５８】
情報収集装置１０は、制御部１１０を構成するＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）１１１（マルチプロセッサ構成ではＣＰＵ１１２等複数のＣＰＵが追加されてもよい）、バスライン１０５、通信部１４０、メインメモリ１５０、ＢＩＯＳ（Ｂａｓｉｃ  Ｉｎｐｕｔ  Ｏｕｔｐｕｔ  Ｓｙｓｔｅｍ）１６０、ＵＳＢポート１９０、Ｉ／Ｏコントローラ１３０、並びにキーボード及びマウス１８１等の入力部１８０や表示部１２０を備える。
【００５９】
ＢＩＯＳ１６０は、情報収集装置１０の起動時に制御部１１０が実行するブートプログラムや、情報収集装置１０のハードウェアに依存するプログラム等を格納する。
【００６０】
Ｉ／Ｏコントローラ１３０には、テープドライブ１７２、ハードディスク１７３、光ディスクドライブ１７５、半導体メモリ１７６等の記憶手段を接続することができる。
【００６１】
記憶部１７０を構成するハードディスク１７３は、情報収集装置１０が情報収集装置として機能するための各種プログラム及び本実施形態を実行するプログラムを記憶しており、更に必要に応じて各種データベースを構成可能である。
【００６２】
光ディスクドライブ１７５としては、例えば、ＤＶＤ−ＲＯＭドライブ、ＣＤ−ＲＯＭドライブ、ＤＶＤ−ＲＡＭドライブ、ＣＤ−ＲＡＭドライブを使用することができる。この場合は各ドライブに対応した光ディスク１７４を使用する。光ディスク１７４から光ディスクドライブ１７５によりプログラム又はデータを読み取り、Ｉ／Ｏコントローラ１３０を介してメインメモリ１５０又はハードディスク１７３に提供することもできる。また、同様にテープドライブ１７２に対応したテープメディア１７１を主としてバックアップのために使用することもできる。
【００６３】
情報収集装置１０に提供されるプログラムは、ハードディスク１７３、光ディスク１７４、又はメモリーカード等の記録媒体に格納されて提供される。このプログラムは、Ｉ／Ｏコントローラ１３０を介して記録媒体から読み出され、又は通信部１４０を介してダウンロードされることによって、情報収集装置１０にインストールされ実行されてもよい。
【００６４】
また、当該プログラムは、内部又は外部の記憶媒体に格納されてもよい。この記憶部１７０を構成する記憶媒体としては、ハードディスク１７３、光ディスク１７４、又はメモリーカードの他に、ＭＤ等の光磁気記録媒体、テープ媒体を用いることができる。また、専用通信回線やインターネットに接続されたサーバに設けたハードディスク１７３又は光ディスクライブラリー等の記憶装置を記録媒体として使用し、通信回線を介してプログラムを情報収集装置１０に提供してもよい。
【００６５】
表示部１２０は、情報収集装置１０の運営者にデータの入力を受け付ける画面を表示したり、情報収集装置１０による演算処理結果の画面を表示したりするものであり、ブラウン管表示装置（ＣＲＴ）、液晶表示装置（ＬＣＤ）等のディスプレイ装置を含む。
【００６６】
入力部１８０は、情報収集装置１０の運営者による入力の受け付けを行うものであり、キーボード及びマウス１８１等により構成してよい。
【００６７】
また、通信部１４０は、情報収集装置１０を専用ネットワーク又は公共ネットワークを介して端末と接続できるようにするためのネットワーク・アダプタである。通信部１４０は、モデム、ケーブル・モデム及びイーサネット（登録商標）・アダプタを含んでよい。
【００６８】
以上の例は、情報収集装置１０について主に説明したが、コンピュータに、プログラムをインストールして、そのコンピュータをサーバ装置として動作させることにより上記で説明した機能を実現することもできる。従って、本実施形態として説明した情報収集装置１０により実現される機能は、上述の方法を当該コンピュータにより実行することにより、或いは、上述のプログラムを当該コンピュータに導入して実行することによっても実現可能である。
【００６９】
［システムの機能構成］
図３は、本実施形態の一例に係る情報収集装置１０の機能ブロック図である。
【００７０】
情報収集装置１０は、通信部１４０、制御部１１０、及び記憶部１７０を含んで構成される。そして、通信部１４０は、送受信手段を有している。また、制御部１１０は、クローラ、コンテンツＤＢ更新手段、リクロールＤＢ登録手段、クロールキッカー、及びスケジューラを有している。更に、記憶部１７０は、コンテンツＤＢ５０及びリクロールＤＢ６０を格納する。
【００７１】
通信部１４０が有する送受信手段は、Ｗｅｂサイト２０からコンテンツデータを受信する。
【００７２】
情報収集装置１０のクローラは、Ｗｅｂサイト２０を参照し、コンテンツデータを収集する。なお、クローラとは一般的に検索ロボットともいわれ、通信ネットワーク３０を通じて、Ｗｅｂサイト２０からコンテンツを収集するプログラムである。なお、クローラが、Ｗｅｂサイトを探し出す手段や、対象とするコンテンツデータの種類は様々であり、クローラの管理者の設定により、収集されるコンテンツデータの種類や分野も異なる。
【００７３】
コンテンツＤＢ更新手段は、クローラが収集したコンテンツデータを、コンテンツＤＢ５０に記憶する。或いはコンテンツデータを上書き更新する。また、リクロールＤＢ登録手段は、コンテンツデータをコンテンツＤＢ５０に記憶したことに応じて、当該コンテンツデータのリクロール予定日時を含む再収集予定データ等を、リクロールＤＢ６０に登録する。
【００７４】
クロールキッカーは、リクロールＤＢ６０を参照して、リクロール予定日時を基に、クロールすべきＷｅｂサイト２０のＵＲＬをスケジューラに送信する役割を持ったプログラムである。クロールキッカーは、リクロールＤＢ６０からのデータの読み出しを適宜一時停止することで情報収集装置１０の処理能力を他のプロセスの処理に分散させることができる。ここで、他のプロセスとは、例えば情報収集装置１０のクローラが、コンテンツＤＢ５０にコンテンツデータを記憶する処理等である。
【００７５】
スケジューラは、クローラに対してリクロールの予定をディスパッチする役割を持ったプログラムである。
【００７６】
記憶部１７０のコンテンツＤＢ５０は、クローラにより収集されたコンテンツデータに、当該コンテンツデータのＵＲＬ、初回クロール日時、及び最終クロール日時等を関連付けて記憶する。ここで、初回クロール日時は、当該コンテンツデータを初めてコンテンツＤＢ５０に記憶した日時を示す。
【００７７】
このコンテンツＤＢ５０に記憶するコンテンツデータは、コンテンツデータの書式やアクセス方法といった情報等を含む。また、コンテンツデータの書式とは、ファイルの形式等であり、例えば、ＪＰＥＧ、ＧＩＦ等の画像データの形式がある。アクセス情報とは、例えば、携帯電話だけからアクセスできるＷｅｂサイトといった、コンテンツデータへのアクセス経路を特定する情報等である。
【００７８】
記憶部１７０のリクロールＤＢ６０は、再収集予定データ等を記憶する。ここで、再収集予定データは、リクロール予定日時を付加した当該コンテンツデータのＵＲＬ、当該コンテンツデータのＵＲＬ、ＩＰアドレス等を含む。このＵＲＬやＩＰアドレス等のＷｅｂサイト２０を特定する情報を「特定情報」という。
【００７９】
［リクロール処理の概要］
図４は、本発明の好適な実施形態の一例に係る情報収集装置１０によるリクロール処理の概要を示す図である。ステップＳ１０１はコンテンツデータのコピー、ステップＳ１０２並びにステップＳ１０３はデータの記憶、ステップＳ１０４は再収集予定データの読み出し、ステップＳ１０６はディスパッチ、ステップＳ１０５並びにステップＳ１０７はキューイングの各ステップを示す。
【００８０】
まず、情報収集装置１０のクローラが、通信部１４０を介して、Ｗｅｂサイト２０を参照し、コンテンツデータを収集する（ステップＳ１０１）。
【００８１】
次に、クローラが、収集したコンテンツデータに、ＵＲＬ、最終クロール日時等を関連付けて、記憶部１７０のコンテンツＤＢ５０に記憶する（ステップＳ１０２）。ここで、具体的なコンテンツＤＢ５０の一例として、図５を参照しながら説明する。
【００８２】
図５は、クローラが、Ｗｅｂサイト２０をクロールして、Ｗｅｂサイト２０のコンテンツデータをコンテンツＤＢ５０に記憶した状態の一例を示す。ここで、コンテンツＤＢ５０は、Ｗｅｂサイト２０のＵＲＬをＫＥＹとして、最終クロール日時、初回クロール日時、及びコンテンツデータを格納している。例えば、先頭のレコードにおいては、クローラが‘ｈｔｔｐ：／／ｗｗｗ．ａａａ０１．ｃｏｍ’をクロールし、最終クロール日時、初回クロール日時とコンテンツそのままのデータ（ＨＴＭＬ等）が、ＵＲＬをＫＥＹとして関連付けられて１レコードで格納されている。
【００８３】
また、次のレコードは、‘ｈｔｔｐ：／／ｗｗｗ．ｂｂｂ０２．ｃｏｍ’に係るデータが同様に格納されている。なお、最終クロール日時が初回クロール日時より更新されている場合は、リクロールして更新されていると捉えてよい。
【００８４】
次に、図４に戻り、情報収集装置１０のリクロールＤＢ登録手段により、クローラが収集したコンテンツデータをコンテンツＤＢ５０に記憶する、上述のステップＳ１０２と共に、当該コンテンツデータのリクロール予定日時を付加したＵＲＬ、ＩＰアドレス、及びリンクの深さ等をリクロールＤＢ６０に記憶する（ステップＳ１０３）。具体的なリクロールＤＢ６０の一例として、図６を参照しながら説明する。
【００８５】
図６は、クローラが、Ｗｅｂサイト２０をクロールして、Ｗｅｂサイト２０のコンテンツデータをコンテンツＤＢ５０に記憶した際の、当該コンテンツデータのリクロール予定日時がリクロールＤＢ６０に登録されている状態を示す。ここで、リクロールＤＢ６０は、Ｗｅｂサイト２０のリクロール予定日時を示す文字列にＷｅｂサイト２０のＵＲＬを示す文字列を付加したもの（ＤＡＴＥ＋ＵＲＬ）をＫＥＹとして、ＵＲＬ、ＩＰ、リンクの深さ等を格納している。
【００８６】
まず、クローラが‘ｈｔｔｐ：／／ｗｗｗ．ａａａ０１．ｃｏｍ’をクロールし、当該クロールした日時に所定の期間を足したリクロール予定日時を示す文字列にＵＲＬを示す文字列を付加して、「２００７０２２３２２５８４５ｈｔｔｐ：／／ｗｗｗ．ａａａ０１．ｃｏｍ」をＫＥＹとして、ＵＲＬ、ＩＰ、リンクの深さ：１００等を１レコードに格納している。また、‘ｈｔｔｐ：／／ｗｗｗ．ｂｂｂ０２．ｃｏｍ’についても同様に格納している。
【００８７】
なお、Ｗｅｂサイト２０のリクロール予定日時を示す文字列にＷｅｂサイト２０のＵＲＬを示す文字列を付加した文字列（ＤＡＴＥ＋ＵＲＬ）をＫＥＹとすることで、リクロール予定日時とＵＲＬを一つのまとまったデータで記憶しておくことができる。また、Ｗｅｂサイト２０のＵＲＬは当該Ｗｅｂサイトを一意に識別することができるユニークな情報であるため、リクロール予定日時に付加することで、ユニークなＫＥＹを作成することができる。
【００８８】
また、このように記憶したレコードを予定日時（ＫＥＹに含まれる）の時系列にソートしておいてもよい。すなわち、レコードを予定日時でソートして記憶しておくことにより、クロールキッカーがリクロールＤＢ６０の先頭レコードを読み出すことで、リクロールするＵＲＬをリクロールＤＢ６０から逐次検索するという処理を省くことができる。なお、ここではＫＥＹにＵＲＬを含めることでユニークなＫＥＹを作成することとしたが、この目的に合致する限りにおいて、付加する文字列はＵＲＬに限られない。
【００８９】
そして、図６のリンク先の深さとは、Ｗｅｂサイト２０のコンテンツの階層数をいう。例えば、「リンク先の深さ：１００」と設定される場合は、ＷｅｂサイトのＴＯＰページをゼロとし、当該ＴＯＰページにリンクされたページを深さ１として、リンク先の１００ページ目までをリクロールの対象としている。このように、Ｗｅｂサイトのリンクを辿っていく階層の限度を、リンク先の深さとして設定できるようにしている。
【００９０】
次に、図４に戻り、情報収集装置１０が、クロールキッカーを起動する。そして、情報収集装置１０のクロールキッカーが、リクロールＤＢ６０の先頭からレコードを読み込む（ステップＳ１０４）。リクロールＤＢ６０には、リクロールする予定日時が時系列で記憶されている。従って、先頭レコードはリクロールする予定日時が最も早いものとなる。
【００９１】
そして、クロールキッカーが、リクロールＤＢ６０から取得したレコードのリクロール予定日時を参照する（ステップＳ１０５）。現在日時がリクロール予定日時に達している場合には、スケジューラに、取得したレコードのＵＲＬを送信する（キューイング）。更に、逐次リクロールＤＢ６０に記憶されているレコードを参照して、現在日時がリクロール予定日時に達していないと判定した場合は、それ以降のリクロールＤＢ６０の読み込みを一時的に停止してクロールキッカーは所定時間待機する。
【００９２】
このようにしてリクロールを一時停止するのは、リクロールＤＢ６０にリクロール予定日時が時系列に記憶されているために、それ以降のレコードがリクロール予定日時に達していないことが明らかであるからである。
【００９３】
そして、クロールキッカーが、ステップＳ１０７でキューイングしたＵＲＬを含むレコードをリクロールＤＢ６０から削除する。これにより、その削除したレコードの次のレコードがリクロールＤＢの先頭レコードになる。すなわち、そのリクロールＤＢの先頭になったレコードは、リクロールＤＢ６０の中でリクロール予定日時が最も早いレコードとなる。
【００９４】
次に、スケジューラが、次にクロールするタスクをクローラに割り当てる（ディスパッチ）。すなわち、スケジューラが、クロールキッカーから受信して保持しているＵＲＬについて、次にクロールを実行する対象としてクローラに命令する（ステップＳ１０６）。
【００９５】
次に、情報収集装置１０のクローラが、スケジューラにクロールの予定をキューイングする（ステップＳ１０７）。このようにステップＳ１０１乃至ステップＳ１０７により、クローラは、クロール及びリクロールを繰り返して、コンテンツＤＢ５０及びリクロールＤＢ６０を更新する。
【００９６】
［クロールキッカーの処理］
図７は、本実施形態の一例に係るクロールキッカーによる処理のフローチャートである。
【００９７】
まず、情報収集装置１０が、クロールキッカーを起動する。そして、情報収集装置１０のクロールキッカーが、リクロールＤＢ６０から先頭のレコードを読み込む（ステップＳ２０１）。
【００９８】
次に、クロールキッカーが、読み出したレコードのＫＥＹを、リクロール予定日時とＵＲＬとに分割する（ステップＳ２０２）。
【００９９】
そして、現在日時がリクロール予定日時に達していないと判定した場合（ステップＳ２０３：ＮＯの場合）には、クロールキッカーは当該リクロール予定日時までの間スリープ状態に移行される。そして、現在日時がリクロール予定日時に達したと判定すると、クロールキッカーを再起動して、上述のステップＳ２０１からの処理を再開する（ステップＳ２０４）。
【０１００】
又、ステップＳ２０３において現在日時がリクロール予定日時に達していると判定した場合（ステップＳ２０３：ＹＥＳの場合）には、クロールキッカーはスケジューラにＵＲＬ等をキューイングする（ステップＳ２０５）。スケジューラは、クローラの現在の処理が終わると、キューイングされたＵＲＬのコンテンツをクロールするタスクをディスパッチする（図４参照）。
【０１０１】
次に、クロールキッカーが、リクロールＤＢ６０の先頭レコードが、スケジューラにＵＲＬをキューイングされたことに応じて、リクロールＤＢ６０の当該先頭レコードを削除する（ステップＳ２０６）。
【０１０２】
そして、クロールキッカーが、リクロールＤＢ６０から先頭のレコードを抽出する（ステップＳ２０１）。このようにして、リクロールＤＢ６０の逐次更新される先頭レコードに対する処理を繰り返す。具体的なリクロールＤＢ６０の先頭レコードに対する処理の一例として、図８を参照しながら説明する。
【０１０３】
図８の（ａ）において、まず、クロールキッカーが、リクロールＤＢ６０の先頭レコードＡを読み込む。ここで、先頭レコードＡは、現在日時がリクロール予定日時に達していると判定した場合、クロールキッカーがスケジューラにレコードＡのＵＲＬをキューイングする。次に、クロールキッカーは、リクロールＤＢ６０からレコードＡを削除する。これにより、リクロールＤＢ６０は先頭レコードがＢになる。
【０１０４】
次に、クロールキッカーが、先頭レコードＢを読み込む。ここで、先頭レコードＢは、レコードＡと同様に、現在日時がリクロール予定日時に達していると判定された場合、クロールキッカーがスケジューラにレコードＢのＵＲＬをキューイングする。次に、クロールキッカーは、リクロールＤＢ６０からレコードＢを削除する。これにより、リクロールＤＢ６０は先頭レコードがＣになる。
【０１０５】
次に、クロールキッカーが、先頭レコードＣを読み込む。ここで、先頭レコードＣが、現在日時がリクロール予定日時に達していないと判定された場合、クロールキッカーは、レコードＣのリクロール予定日時までの間スリープ状態に移行して待機する（図８の（ｂ））。その後、クロールキッカーは、現在日時がレコードＣのリクロール予定日時になると再起動する。
【０１０６】
次に、図８の（ｃ）において、クロールキッカーが、リクロールＤＢ６０の先頭レコードＣを読み込む。ここで、先頭レコードＣは、現在日時がリクロール予定日時に達していると判定した場合、クロールキッカーがスケジューラにレコードＣのＵＲＬをキューイングする。次に、クロールキッカーは、リクロールＤＢ６０からレコードＣを削除する。これにより、リクロールＤＢ６０は先頭レコードがＤになる。
【０１０７】
次に、クロールキッカーが、の先頭レコードＤを読み込む。ここで、先頭レコードＤは、現在日時がリクロール予定日時に達していないと判定された場合に、クロールキッカーは、レコードＤのリクロール予定日時までの間スリープ状態に移行して待機する（図８の（ｄ））。その後、現在日時がレコードＤのリクロール予定日時に達し再起動したクロールキッカーが、リクロールＤＢ６０（図８の（ｅ））の先頭レコードＤを読み込む。このようにしてクロールキッカーは実行と待機を繰り返してリクロールしてリクロールＤＢ６０を更新する。
【０１０８】
このように、クロールキッカーが、リクロールＤＢ６０の先頭レコードを逐次読み出し、当該レコード内のリクロール予定日時に基づいてクロールキッカーのプロセスを起動させる。そして、リクロールを行って、次のリクロール予定日時が未来である場合には予定日時までの間スリープ状態に移行してクロールキッカーのプロセスを再起動させる。従って、クロールキッカーが、現在日時においてリクロールするドキュメントの数だけを処理をすることで、無駄のない処理となる。そして、情報収集装置１０の処理効率を向上させることができる。
【０１０９】
なお、クロールキッカーは、ハードウェアタイマーにより、スリープ、又は再起動するようにしてもよい。ここで、ハードウェアタイマーは、制御部１１０（メインＣＰＵ）とは別に配置されるカウンターで、例えば、制御部１１０が他のプログラムによって占有されているときにも、クロールキッカーを、リクロール予定日時に再起動させることができる。
【０１１０】
［クロール実行処理］
図９は、本実施形態の一例に係るクローラによるクロール処理のフローチャートである。
【０１１１】
まず、クローラが、スケジューラから投入されたＵＲＬのＷｅｂサイト２０にアクセスし、送受信手段を介して、Ｗｅｂサイト２０のコンテンツデータを取得する。そして、その取得したコンテンツデータを、コンテンツＤＢ５０に書き込む（ステップＳ４０１及びステップＳ４０２）。
【０１１２】
次に、クローラが、Ｗｅｂサイト２０のコンテンツデータのチェックを行う（ステップＳ４０３）。このコンテンツデータのチェックでは、必要なコンテンツデータと、不必要なコンテンツとを判定する。そして、クローラが、不必要なコンテンツデータと判定した場合は、上述のステップＳ４０１に戻り、別のコンテンツデータに対する処理を行う。
【０１１３】
なお、不必要なコンテンツデータとは、例えば、クローラが収集しているコンテンツデータの分野が異なる場合である。携帯電話向けのＷｅｂサイトをクロールするクローラが、パソコンのブラウザで閲覧可能なＷｅｂサイトをクロールしてしまった場合、当該Ｗｅｂサイトを不必要なコンテンツデータと判定する。また、クロール先のＷｅｂサイトに異常（ＨＴＴＰステータス）が発生して、コンテンツデータが正常に得られない場合にも不要と判定してもよい。
【０１１４】
次に、情報収集装置１０のクローラが、必要なコンテンツと判定した場合（上述のステップＳ４０３）は、リクロールＤＢ登録手段が、当該必要なコンテンツデータのリクロール予定日時、ＵＲＬ等をリクロールＤＢ６０のレコードに追加する（ステップＳ４０４）。このようにして、一つのコンテンツのクロール処理が完了すると、クローラは、スケジューラから新しいＵＲＬを取得して、ステップＳ４０１乃至ステップＳ４０４の処理を行う。
【０１１５】
ここで、ステップＳ４０４において、リクロール予定日時の計算は、現在日時に所定の期間Ｘ（例えば、１週間）を加算することで行う。具体的には、この加算の際に、図9に示す所定の期間Ｘを毎回変化させると、より好適である。即ち、図９Ａに示すように、クローラは、所定の期間Ｘを計算する度に、乱数αを発生させて（ステップＳ４０４ａ）、その乱数αをＸに加減算することで±αの範囲でランダムにＸを変化させてもよい（ステップＳ４０４ｂ）。例えば、次回のスクロールに予定日時として７日後を設定する場合には、発生させた乱数に基づいて、５日から９日の間でランダムに変化させる。同様に、１５日後を設定する場合には、１２日から１８日の間でランダムに変化させる。
【０１１６】
このようにすることにより、クロール先のＷｅｂサイトが、次回リクロール予定日時を予測してタイミングを合わせて更新を行ったりすることで、恣意的に最新情報を反映させる、といった運用を防ぐことができる。
【０１１７】
［本実施形態による作用及び効果］
図１０及び図１１で示すように、従来のクロールキッカーは、コンテンツＤＢ５０の全レコードの処理が終わるまで、１レコードずつ読み込んで処理をすることによりリクロールを行っており、コンテンツＤＢのレコード数によっては、クロールキッカーが、コンテンツＤＢ５０にアクセスする回数は、膨大なものとなる。例えば、クロールキッカーがｘ回起動するとして、コンテンツＤＢ５０にアクセスする回数を計算すると次のようになる。すなわち、従来の技術によれば、コンテンツＤＢ５０へのアクセス回数は、
【数１】
2008257695.tif 000003
となる（Ｍ：コンテンツＤＢ５０に記憶した総ＵＲＬ数）。
【０１１８】
これに対し、本実施形態のクロールキッカーがｘ回起動して、リクロールＤＢ６０にアクセスする回数は、
【数２】
2008257695.tif 000004
となる（Ｎ：リクロールＤＢ６０におけるリクロール対象のＵＲＬ数）。
【０１１９】
次に、本実施形態において、コンテンツＤＢ５０に記憶された全てのＵＲＬを各１回リクロールするために必要なＤＢアクセス回数は、
【数３】
2008257695.tif 000005
となる。尚、リクロールＤＢ６０からのレコードの削除もＤＢへのアクセスとして捉えると２Ｍとなる。
【０１２０】
これに対し、従来の技術によれば、コンテンツＤＢ５０に記憶された全てのＵＲＬを各１回クロールするために必要なＤＢアクセス回数は、
【数４】
2008257695.tif 000006
となる（Ａ：リクロールの間にキッカーが起動する回数（リクロール最大間隔／クロールキッカーの起動間隔））。
【０１２１】
例えば、リクロールの最大間隔が２週間で、クロールキッカーの起動間隔が１時間であった場合、本実施形態によれば、
【数５】
2008257695.tif 000007
ただし、リクロールＤＢ６０からの削除もＤＢへのアクセスとすると２Ｍ
であるのに対し、従来の技術によれば、
【数６】
2008257695.tif 000008
となる。
【０１２２】
この例で示すように、リクロールＤＢ６０を用いてコンテンツＤＢ５０にアクセスする場合は、ＵＲＬに１回アクセスするだけであるが、リクロールＤＢ６０を用いず、コンテンツＤＢ５０だけでリクロールをする場合は、コンテンツＤＢ５０にアクセスする回数は３３６倍となる。本実施形態は、このように、コンテンツＤＢ５０へのアクセス回数を減らして時間的なロスを削減し、ディスクＩ／Ｏの負担も軽減することができる。
【０１２３】
なお、実際の運用時においては、通常コンテンツＤＢ５０には億単位の件数のデータ（レコード）が記憶されている。従って、前記コンテンツＤＢ５０のレコード件数が例えば約５億件であった場合、１回のアクセスで０．１ミリ秒を要するとすれば、全てのレコードにアクセスするためには５．７８日を要する。その結果、従来のように、前記Ｗｅｂサイトが次回参照時に達しているか否かを確認するために前記コンテンツＤＢ５０を参照する場合には、一連のプロセスを完了するために５．７８日（確認のためのアクセス）＋５．７８日（記憶のためのアクセス）＝１１．５６日を要することになる。
【０１２４】
ところで、画像データ等を含む前記Ｗｅｂサイトの情報がコンテンツデータとして記憶されているコンテンツＤＢ５０と比較して、再収集予定データが前記Ｗｅｂサイトの特定情報と関連付けて記憶されているリクロールＤＢ６０は、日時やＵＲＬ等で構成されているためにそのデータサイズは、コンテンツＤＢ５０よりもはるかに小さなものとなる。
【０１２５】
従って、例えば、リクロールＤＢ６０の１回のアクセスに０．０１ミリ秒を要したとすると、本実施形態の構成のようにコンテンツＤＢ５０の代わりにリクロールＤＢ６０を参照することにより、一連のプロセスを完了するために要する日数は０．５８日（確認のためのリクロールＤＢ６０へのアクセス）＋５．７８日（記憶のためのコンテンツＤＢ５０へのアクセス）＝６．３６日となり、５．２０日（約４５％）短縮することができる。
【０１２６】
通常、Ｗｅｂサイトの参照は数日から数週間に１回の割合で行われており、上述のアクセス時間を想定した場合、従来、２週間近くを要する一連のプロセスを、本実施形態の構成によれば、１週間以内に終了させることができる。
【０１２７】
なお、コンテンツＤＢ５０は、Ｗｅｂサイトの一部でもあるため、外部からの検索エンジンからアクセスされることもあり得る。従来のクロール方法の場合、コンテンツＤＢ５０は、クローラによる書き込み、検索エンジンによる検索、クロールキッカーによるリクロールするかどうかの判定をするプロセス等が競合することになる。このことにより、コンテンツＤＢ５０を使用中のプロセスから、次のプロセスがコンテンツＤＢ５０を使用できるまでの待ち時間が発生する。
【０１２８】
従って、従来の技術においては、クロールキッカーにより、リクロールするかどうかの判定をコンテンツＤＢ５０のリクロールがまだ必要のないレコードを含む全レコードを読み込んで行うので、リクロールの効率が悪くなる。本実施形態は、リクロールの際にコンテンツＤＢ５０の読み込みを行わないため、効率的にリクロールを実施することができる。そして、クロールキッカーによるコンテンツＤＢ５０を用いたリクロールするかどうかの判定をするプロセスを必要としないので、その分、クロール処理にかかるプロセス以外の他のプロセスに待ち時間を与えることがなくなる。
【０１２９】
このため、コンテンツＤＢ５０が更に巨大化した場合においても、本実施形態によれば、そのデータサイズに影響されることなく、リクロールの管理を容易に行うことができる。
【０１３０】
具体的には、Ｍ×１レコードの処理時間がクロールキッカーの起動間隔よりも大きくなった場合に、本実施形態は特に好適である。なぜなら、従来の技術によれば、コンテンツＤＢ５０を全部読み込むまで、次のキッカーを起動することができないため、必然的にクロールキッカーの起動がコンテンツＤＢ５０の処理が終わるまで延長されてしまうことになるからである。更に、仮に次のキッカーが起動できたとしても、すでにその時点で遅延が発生しているため、コンテンツＤＢ５０に対して２つのキッカーから重複アクセスをすることになり、更に遅延の悪化が進むことになる。本実施形態はこのような事態を回避することができる。
【０１３１】
このように、本実施形態によれば、クロールキッカーをクロール予定日時までの間、スリープさせることにより、プロセスの処理効率を向上させることができる。具体的には、コンテンツＤＢ５０を変更することなく、リクロールＤＢ６０によってリクロールの管理を高速化できる。更に、リクロールＤＢ６０に必要と判定したＵＲＬを追加することで、リクロール時の処理工程を少なくすることができる。更に、リクロール予定日時をリクロールＤＢ６０のＫＥＹの先頭とすることにより、リクロールＤＢ６０のソートを容易に行うことができる。特に、本実施形態は、リンク巡回型の大規模なクローラ、リアルタイムに近いリクロールが必要になる場合、特定のコンテンツ（例えば、モバイル、画像といったＷｅｂ検索用コンテンツ）のみをクロールする場合等に好適である。
【０１３２】
以上、本発明の実施形態について説明したが、本発明は上述した実施形態に限るものではない。また、本発明の実施形態に記載された効果は、本発明から生じる最も好適な効果を列挙したに過ぎず、本発明による効果は、本発明の実施例に記載されたものに限定されるものではない。
【図面の簡単な説明】
【０１３３】
【図１】本実施形態の一例に係るシステム１の全体構成を示す図である。
【図２】本実施形態の一例に係る情報収集装置１０の構成を示す図である。
【図３】本実施形態の一例に係る情報収集装置１０の機能ブロック図である。
【図４】本実施形態の一例に係る情報収集装置１０によるリクロール処理の概要を示す図である。
【図５】本実施形態の一例に係るコンテンツＤＢ５０を示す図である。
【図６】本実施形態の一例に係るリクロールＤＢ６０を示す図である。
【図７】本実施形態の一例に係るクロールキッカーによる処理のフローチャートである。
【図８】本実施形態の一例に係るリクロールＤＢ６０の先頭レコードに対する処理を示す図である。
【図９】本実施形態の一例に係るクローラによるクロール処理のフローチャートである。
【図９Ａ】本実施形態の一例に係るクローラによるクロール処理におけるＸ±αの計算処理を示すフローチャートである。
【図１０】従来の情報収集装置によるデータ更新処理のシステム概要を示す図である。
【図１１】従来のデータ更新処理を示すフローチャートである。
【符号の説明】
【０１３４】
１  システム
１０  情報収集装置
２０  Ｗｅｂサイト
３０  通信ネットワーク
５０  コンテンツＤＢ
６０  リクロールＤＢ
【図１】
2008257695.tif 000009
【図２】
2008257695.tif 000010
【図３】
2008257695.tif 000011
【図４】
2008257695.tif 000012
【図５】
2008257695.tif 000013
【図６】
2008257695.tif 000014
【図７】
2008257695.tif 000015
【図８】
2008257695.tif 000016
【図９】
2008257695.tif 000017
【図９Ａ】
2008257695.tif 000018
【図１０】
2008257695.tif 000019
【図１１】
2008257695.tif 000020