JPH11212854A

JPH11212854A - 情報取得装置、情報取得方法および情報取得プログラムを記録した媒体

Info

Publication number: JPH11212854A
Application number: JP10011404A
Authority: JP
Inventors: Hironori Togashi; 宏規富樫; Akihiro Sato; 昭弘佐藤; Akira Mochida; 晃持田
Original assignee: AI SOFT KK
Current assignee: AI SOFT KK
Priority date: 1998-01-23
Filing date: 1998-01-23
Publication date: 1999-08-06

Abstract

(57)【要約】【課題】情報発信源は不特定多数の利用者に対して更
新情報を発信することは現実的に不可能であり、アクセ
スする側において情報が更新されたか否かを判断しなけ
ればならなかった。【解決手段】従来であれば、勘に頼って定期的な自動
運転を行ない、当てずっぽう式の手法で情報を取得する
ようにしていたが、得られた情報の中に次回の更新予定
日であるとか、更新間隔などがないか判断するととも
に、これらが無い場合には過去の更新履歴に基づいて次
回の更新を予測するようにしたため、いたずらにアクセ
ス回数を増やすことなく、可能な限り最新の情報を維持
するということが可能となる。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、情報取得装置、情
報取得方法および情報取得プログラムを記録した媒体に
関し、特に、広域ネットワークの通信回線を介して情報
発信源に対して能動的にアクセスして同情報発信源が発
信する情報を取得する情報取得装置、情報取得方法およ
び情報取得プログラムを記録した媒体に関する。

【０００２】

【従来の技術】近年、インターネットのような広域ネッ
トワークにおいては、極めて多数の情報発信源が、おの
おので情報を発信しつつある。このような情報発信源の
特徴として、一定期間毎に発信情報を更新していること
が多い。

【０００３】この場合、情報発信源は不特定多数の利用
者に対して更新情報を発信することは現実的に不可能で
あり、アクセスする側において情報が更新されたか否か
を判断しなければならない。

【０００４】

【発明が解決しようとする課題】上述した従来の情報取
得装置においては、次のような課題があった。

【０００５】アクセスする側では更新の有無が分からな
いため、自ら能動的にアクセスして更新の有無をチェッ
クしなければならない。しかしながら、頻繁にチェック
することにすれば、更新がない限りは何度も無駄にアク
セスすることが生じるし、十分な期間をおいてチェック
することにすれば最新の情報を取得できなくなってしま
う。

【０００６】本発明は、上記課題にかんがみてなされた
もので、効率よく最新の情報を得ることが可能な情報取
得装置、情報取得方法および情報取得プログラムを記録
した媒体の提供を目的とする。

【０００７】

【課題を解決するための手段】上記目的を達成するた
め、請求項１にかかる発明は、広域ネットワークの通信
回線を介して情報発信源に対して能動的にアクセスして
同情報発信源が発信する情報を取得する情報取得装置で
あって、上記通信回線を介して上記情報発信源と接続さ
れたときに当該情報発信源が発信している情報を取得す
る情報取得手段と、設定したチェック日時に上記情報取
得手段を所定の情報発信源に接続させるように自動運転
する自動運転手段と、上記情報取得手段によって取得し
た上記情報を解析することによって次回更新日時を得る
とともに当該次回更新日時後に上記情報を取得するよう
に上記自動運転手段のチェック日時を設定する次回更新
日時取得手段とを具備する構成としてある。

【０００８】上記のように構成した請求項１にかかる発
明においては、予め設定したチェック日時に自動運転手
段が情報取得手段を所定の情報発信源に接続させるよう
に自動運転すると、当該情報取得手段はその情報発信源
が発信している情報を取得する。一方、次回更新日時取
得手段は、上記情報取得手段によって取得した上記情報
を解析することにより、同情報発信源における次回更新
日時を得て、当該次回更新日時後に上記情報を取得する
ように上記自動運転手段のチェック日時を設定する。従
って、このチェック日時となると上述したような自動運
転によって再度情報を取得していくことになる。

【０００９】すなわち、アクセスして得られた情報を解
析することにより、次回更新日時を自動的に予測し、そ
の更新日時を目途にしたチェック日時にアクセスして情
報を得る。この場合、実際にアクセスするのは予測され
た次回更新日時よりも後であるべきであるから、次回更
新日時と次回チェック日時というのは異なるはずであ
る。従って、厳密に言えば１秒でも後でなければならな
いということになるが、必ずしもこのような厳密な処理
が必要であるとは言えない場合も多い。あくまでも予測
という性格があるし、発信者の側が時間まで厳密に管理
していないことも多いからである。従って、予測された
次回更新タイミングは日にち単位の予定日としてとら
え、時間はその日の正午と把握したり、夜中の１２時と
考えて処理することも可能である。

【００１０】次回更新日時取得手段が実現するのは情報
源における次回更新日時を取得することであり、これは
情報内容によってさまざまなアプローチを取ることが可
能である。その一例として、請求項２にかかる発明は、
請求項１に記載の情報取得装置において、上記次回更新
日時取得手段は、取得した上記情報を解析して次回の更
新予定日があれば当該更新予定日を次回更新日時と判断
する更新予定日取得手段を有する構成としてある。

【００１１】上記のように構成した請求項２にかかる発
明においては、取得した上記情報に基づいて次回更新日
時取得手段が解析を行なう。この解析は同情報内に次回
の更新予定日があるか否かを判定するものであり、あれ
ば当該更新予定日を次回更新日時と判断する。すなわ
ち、情報発信源が予定している更新日を公表している場
合にはこれを利用している。

【００１２】また、別のアプローチの一例として、請求
項３にかかる発明は、請求項１または請求項２のいずれ
かに記載の情報取得装置において、上記次回更新日時取
得手段は、取得した上記情報を解析して直近の更新日時
と更新間隔の情報を取得して上記直近の更新日時から当
該更新間隔後の日時を次回更新日時と判断する更新間隔
取得手段を有する構成としてある。

【００１３】上記のように構成した請求項３にかかる発
明においても、取得した上記情報に基づいて次回更新日
時取得手段が解析を行なうが、ここでは同情報内に更新
間隔と直近の更新日時があるか否かを判定する。そし
て、これらがある場合には直近の更新日時から当該更新
間隔後の日時を次回更新日時と判断する。すなわち、情
報源が更新間隔を予定している場合にはこれを利用して
いる。

【００１４】さらに、別のアプローチとして、請求項４
にかかる発明は、請求項１〜請求項３のいずれかに記載
の情報取得装置において、上記次回更新日時取得手段
は、取得した上記情報の内容から得られる過去の更新日
時情報を記憶する更新履歴記憶手段と、この更新履歴記
憶手段にて記憶されている更新日時情報の履歴に基づい
て次回更新日時を予測する更新予測手段と、この予測結
果に基づく次回のチェック日時に得られる上記情報に基
づいて実更新日時を得て上記更新予測手段による次回更
新日時の予測にフィードバックをかける実更新日時フィ
ードバック手段とを有する構成としてある。

【００１５】上記のように構成した請求項４にかかる発
明においても、取得した上記情報に基づいて次回更新日
時取得手段が解析を行なう。この場合、次回更新日時取
得手段は、更新履歴記憶手段と、更新予測手段と、実更
新日時フィードバック手段とを備えており、更新履歴記
憶手段が取得した上記情報の内容から得られる過去の更
新日時情報を記憶するので、更新予測手段は記憶されて
いる更新日時情報の履歴に基づいて次回更新日時を予測
する。一方、このように予測された更新日時に対応して
次回チェック日時にアクセスされたときには、必ずしも
予測どおりとはいかないことがありえる。このため、実
更新日時フィードバック手段は、次回のチェック日時に
新たに得られる上記情報に基づいて実更新日時を得て、
上記更新予測手段による次回更新日時の予測にフィード
バックをかける。

【００１６】このフィードバックの手法は更新予測手段
による予測手法に応じて様々な態様が可能である。この
更新予測手段における更新予測の一例として、請求項５
にかかる発明は、請求項１〜請求項４のいずれかに記載
の情報取得装置において、上記更新履歴記憶手段は、直
近の更新日時とともに過去の複数回の更新履歴を記憶
し、上記更新予測手段は、上記更新履歴から更新間隔を
取得しつつ直近の更新日時に同更新間隔を加えたものを
次回更新日時と予測する構成としてある。

【００１７】上記のように構成した請求項５にかかる発
明においては、更新予測手段が過去の複数の更新履歴か
ら次回更新日時を予測するにあたって、更新履歴記憶手
段が記憶するそれぞれの更新履歴の間隔から更新間隔を
演算し、直近の更新履歴に更新間隔を加算している。

【００１８】このようにして更新日時を予測したとして
も必ずしも予定どおりにいくとは限らない。従って、こ
の更新間隔が過ぎた時点でアクセスしても更新されてい
ない場合は、実更新日時フィードバック手段がこれまで
の更新間隔の変動を解析して更新間隔の変動度合いを考
慮した次回更新日時を得ればよい。そして、このような
変動度合いを考慮に入れた新たな手法で次回更新日時を
決定させる。むろん、あまり複雑とさせることなく、単
純に次回更新日時を翌日にさせるといったものであって
も良い。

【００１９】一方、既に更新されていた場合にはその実
更新日時に基づいて更新間隔をより短くすればよい。

【００２０】また、上述した更新間隔の求め方について
も各種の手法を採用可能であり、その一例として、請求
項６にかかる発明は、請求項５に記載の情報取得装置に
おいて、上記更新予測手段は、上記更新履歴における間
隔の平均を更新間隔とする構成としてある。すなわち、
更新履歴の間隔の平均を更新間隔としている。

【００２１】また、他の一例として、請求項７にかかる
発明は、請求項５に記載の情報取得装置において、上記
更新予測手段は、上記更新履歴における間隔の最小値を
更新間隔とする構成としてある。すなわち、更新履歴の
間隔の最小値を更新間隔としている。

【００２２】以上のようにして更新間隔を利用するとし
た場合、複数の更新履歴が無いときには更新間隔を得ら
れないこともあり得る。すなわち、最初の情報取得時に
は一つしか直近の更新日時だけしか得られないことがあ
る。このような場合に好適な一例として、請求項８にか
かる発明は、請求項５に記載の情報取得装置において、
上記更新予測手段は、最初の情報取得時に直近の更新日
時と当該情報取得日時との間隔を取得して更新間隔と判
断する構成としてある。

【００２３】上記のように構成した請求項８にかかる発
明においては、上記更新予測手段が最初の情報取得時に
得た直近の更新日時と当該情報取得日時との間隔を取得
し、当該間隔を更新間隔と判断する。

【００２４】むろん、最初の情報取得時に過去の更新履
歴が複数得られればこれを利用することも可能である。

【００２５】一方、情報取得手段が広域ネットワークを
介して情報を取得する情報発信源は様々であり、特定の
ものに限られる必要はない。しかしながら、近年におい
てはインターネットによる情報発信が盛んであり、広域
ネットワークとしてインターネットを利用した情報取得
にも適用可能であることはいうまでもない。このような
場合に好適な一例として、請求項９にかかる発明は、請
求項１〜請求項８のいずれかに記載の情報取得装置にお
いて、上記情報発信源はＷＥＢサイトであり、上記情報
はＨＴＭＬ文書で構成してある。

【００２６】上記のように構成した請求項９にかかる発
明においては、情報取得手段は広域ネットワークを介し
て情報発信源であるＷＥＢサイトにアクセスし、同ＷＥ
Ｂサイトが発信するＨＴＭＬ文書の情報を取得する。む
ろん、このＨＴＭＬ文書はドキュメントとしての文書情
報であっても良いし、図形や写真データであっても良い
し、プログラムファイルなどであっても良い。さらに
は、サーバスクリプトであってもよい。さらに、ＣＧＩ
スクリプトを実行させることによって返信されるＨＴＭ
Ｌ文書なども当然に含まれる。また、ＨＴＭＬ文書を取
得する際にはＨＴＴＰプロトコルが採用され、その過程
でも情報のやりとりが行われる。この例で言えば、本来
のＨＴＭＬ文書とともに拡張情報として最終更新日時が
「LastModified: Thu, 01 Jan 1998 10:23:00 GMT」と
いうようにして取得可能である。従って、このようにし
て取得されうる情報も広義の意味での上記情報に含まれ
ることはいうまでもない。

【００２７】これに対し、情報発信源はこのような一般
向けのＨＴＭＬ文書などに限られるものではなく、シス
テムファイルのアップデートプログラムのサーバなどに
も適用可能である。その一例として、請求項１０にかか
る発明は、請求項１〜請求項８のいずれかに記載の情報
取得装置において、上記情報発信源は、当該情報取得端
末で実行するプログラムファイルの供給サーバであり、
上記情報には、当該プログラムファイルが含まれ、実行
用プログラムファイルの最新情報を取得する構成として
ある。

【００２８】上記のように構成した請求項１０にかかる
発明においては、情報発信源が情報取得端末で実行する
プログラムファイルの供給サーバであり、いわゆる最新
のアップデータやプログラムファイルを供給している。
従って、情報取得端末の側では当該供給サーバから最新
のプログラムファイルを得られるようにその更新状況を
把握する必要がある。従って、上述したように次回更新
日時を予測してアクセスし、更新されたプログラムファ
イルがあればこれを取得することになる。

【００２９】そして、これらの場合においては広域ネッ
トワークがインターネットである場合も多く、請求項１
１にかかる発明は、請求項１〜請求項１０のいずれかに
記載の情報取得装置において、上記広域ネットワーク
が、インターネットとなっている。

【００３０】自動運転手段の構成もさまざまなものを採
用可能である。コンピュータであれば、情報取得プログ
ラムと一体的に構成され、その自動運転機能として実現
されるものであっても良い。また、コンピュータに対す
るスクリプトとして個々の情報取得プログラムの起動や
操作をコントロールするものであっても良い。さらに、
複数の情報取得端末が接続されるプロキシサーバなどに
おいては、広域ネットワークに接続して必要な情報を取
得し、取得した情報を蓄えておいて各情報取得端末に配
信するものであってもよい。

【００３１】このように、取得した情報に基づいて更新
日時を予測して自動運転のチェック日時を設定する手法
は必ずしも実体のある装置に限られる必要はなく、その
方法としても機能することは容易に理解できる。このた
め、請求項１２にかかる発明は、広域ネットワークの通
信回線を介して情報発信源に対して能動的にアクセスし
て同情報発信源が発信する情報を取得する情報取得方法
であって、設定したチェック日時に自動運転して、上記
通信回線を介して上記情報発信源と接続し、当該情報発
信源が発信している情報を取得するとともに、この取得
した情報を解析することによって次回更新日時を得て、
この更新日時後に上記情報を取得するように次回のチェ
ック日時を設定する構成としてある。

【００３２】すなわち、必ずしも実体のある装置に限ら
ず、その方法としても有効であることに相違はない。

【００３３】ところで、このような情報取得装置は単独
で存在する場合もあるし、ある機器に組み込まれた状態
で利用されることもあるなど、発明の思想としてはこれ
に限らず、各種の態様を含むものである。従って、ソフ
トウェアであったりハードウェアであったりするなど、
適宜、変更可能である。

【００３４】発明の思想の具現化例として情報取得装置
のソフトウェアとなる場合には、かかるソフトウェアを
記録した記録媒体上においても当然に存在し、利用され
るといわざるをえない。

【００３５】その一例として、請求項１３にかかる発明
は、広域ネットワークの通信回線を介して情報発信源に
対して能動的にアクセスして同情報発信源が発信する情
報を取得する情報取得プログラムを記録した媒体であっ
て、設定したチェック日時に自動運転して、上記通信回
線を介して上記情報発信源と接続し、当該情報発信源が
発信している情報を取得するとともに、この取得した情
報を解析することによって次回更新日時を得て、この更
新日時後に上記情報を取得するように次回のチェック日
時を設定する構成としてある。

【００３６】むろん、その記録媒体は、磁気記録媒体で
あってもよいし光磁気記録媒体であってもよいし、今後
開発されるいかなる記録媒体においても全く同様に考え
ることができる。また、一次複製品、二次複製品などの
複製段階については全く問う余地無く同等である。その
他、供給方法として通信回線を利用して行なう場合でも
本発明が利用されていることにはかわりない。

【００３７】さらに、一部がソフトウェアであって、一
部がハードウェアで実現されている場合においても発明
の思想において全く異なるものはなく、一部を記録媒体
上に記憶しておいて必要に応じて適宜読み込まれるよう
な形態のものとしてあってもよい。

【００３８】

【発明の効果】以上説明したように本発明は、取得した
情報を解析して次回更新日時を予測するようにしたた
め、無駄にアクセスする必要が無くなるとともに、でき
るだけ最新の情報を逃さないようにすることが可能な情
報取得装置を提供することができる。

【００３９】また、請求項２にかかる発明によれば、情
報発信源が発信する更新予定を利用するため、情報発信
源の信頼性がある限り、正確で最新の情報を無駄なく取
得することができる。

【００４０】さらに、請求項３にかかる発明によれば、
情報発信源が発信する更新間隔に基づいて次回更新日時
を推測するため、この場合も正確で最新の情報を無駄な
く取得することができる。

【００４１】さらに、請求項４にかかる発明によれば、
過去の複数の更新履歴を記憶することにより、情報発信
源が直接に更新間隔を発信していない場合でも、更新間
隔を取得することができ、効率的な情報取得が可能とな
る。

【００４２】さらに、請求項５にかかる発明によれば、
直近の更新日時に更新間隔を加えるというシンプルな手
法で次回更新日時を予測することができる。

【００４３】さらに、請求項６にかかる発明によれば、
採用するのが更新間隔の平均であるので、アクセスのロ
スと最新情報の取得可能性とのバランスが安定するとい
える。

【００４４】さらに、請求項７にかかる発明によれば、
採用する更新間隔が最小値であれば次回チェック日時に
未更新である確率は高いが、最新の情報を得やすくなる
と言える。

【００４５】さらに、請求項８にかかる発明によれば、
最初の情報取得時であっても更新間隔を擬似的に作り出
して実行することができる。

【００４６】さらに、請求項９にかかる発明によれば、
ＷＥＢサイトから効率よくＨＴＭＬ文書を取得すること
ができる。

【００４７】さらに、請求項１０にかかる発明によれ
ば、プログラムファイルの供給サーバから効率よく最新
のプログラムファイルを取得することができる。

【００４８】さらに、請求項１１にかかる発明によれ
ば、インターネットで様々な最新の情報を無駄なく取得
することができる。

【００４９】さらに、請求項１２にかかる発明によれ
ば、上記のような効果を奏する情報取得方法を提供で
き、請求項１３にかかる発明によれば、情報取得プログ
ラムを記録した媒体を提供することができる。

【００５０】

【発明の実施の形態】以下、図面にもとづいて本発明の
実施形態を説明する。

【００５１】図１は本発明の一実施形態にかかる情報取
得装置をクレーム対応図により示しており、図２は本情
報取得装置が広域ネットワークに接続される全体像を概
略的に示している。

【００５２】本情報取得装置１０は、広域ネットワーク
５０と通信回線６０を介して情報発信源７０に対して能
動的にアクセスして上記情報発信源７０と接続されたと
きに当該情報発信源７０が発信している情報を取得する
情報取得手段２０と、設定したチェック日時に上記情報
取得手段２０にて所定の情報発信源７０に接続させるよ
うに自動運転する自動運転手段３０と、上記情報取得手
段２０によって取得した上記情報を解析することによっ
て次回更新日時を得るとともに当該次回更新日時後に上
記情報を取得するように上記自動運転手段３０のチェッ
ク日時を設定する次回更新日時取得手段４０とを備えて
いる。

【００５３】広域ネットワーク５０はインターネットな
どが該当するし、情報発信源７０はいわゆるサーバが該
当する。すなわち、情報発信源７０は所定のＵＲＬアド
レスを割り当てられたサーバを備えており、当該ＵＲＬ
アドレスに基づいて情報取得装置１０が能動的にアクセ
スしてきた場合に必要な情報を取得させる。

【００５４】情報の発信、取得の形態はさまざまである
が、情報発信源７０がＷＥＢサイトであるとすると、発
信する情報は概ねＨＴＭＬ文書であり、この中にはテキ
スト文書の他、画像ファイル、プログラムファイル、音
声ファイルなど、各種の情報が含まれている。

【００５５】一方、このような広域ネットワーク５０に
利用される通信回線６０は電気的なものや光利用のもの
が可能であるし、各種の媒体変換装置を介して接続され
ている。インターネットであればイーサネットケーブル
６１による直接接続という手法も可能であるし、あるい
はプロバイダ６２に対して公衆電話回線６３を介してダ
イアルアップ接続することも可能であり、この場合には
プロバイダ６２や公衆電話回線６３も通信回線６０の一
部に含まれることになる。むろん社内ＬＡＮ６４を介し
て接続される場合にはこのような社内ＬＡＮ６４やルー
タ６５なども通信回線６０の一部に含まれることにな
る。

【００５６】情報取得装置１０自体は、図３に示すよう
なコンピュータ端末１００で構成することができる。コ
ンピュータ端末１００は、ＣＰＵ１１１やＲＯＭ１１２
やＲＡＭ１１３やＩ／Ｏ１１４などを備えるコンピュー
タ１１０とともに、モニタ１２０やキーボード１３０や
マウス１４０といった主構成装置とともに、フロッピー
ディスクドライブ１５０や、ハードディスクドライブ１
６０や、ＣＤ−ＲＯＭドライブ１７０といった外部記憶
装置が含まれ、さらには、上述した通信回線６０に接続
するためのモデム１８０やＬＡＮアダプタ１９０などか
ら構成されている。

【００５７】コンピュータ端末１００は上述したハード
ウェアユニットが後述するソフトウェアを実行して各種
の処理を実現するものであるから、相互に一体となって
情報取得装置１０を構成していると言える。すなわち、
上述したように用意されたハードウェア資源をソフトウ
ェアによって最大限に利用することにより、不可分一体
となって図１に示すような情報取得手段２０や自動運転
手段３０や次回更新日時取得手段４０を実現している。

【００５８】図４および図５はこの情報取得装置１０を
実現するソフトウェアの概略フローチャートと設定用画
面を示している。

【００５９】図５の設定用画面２００では、左半分程の
領域を、巡回先ＵＲＬ指定エリア２１０と、各ＵＲＬ毎
の更新履歴表示エリア２２０とが占めており、右半分程
の領域を、自動更新予測指示領域２３０と、定期運転指
示領域２４０とによって占めている。尚、定期運転指示
領域２４０には、自動運転間隔を週単位や月単位で指示
したり、一日のうちの運転時間を指示するための個別指
示領域２４１〜２４３が用意されている。例えば、週単
位個別指示領域２４１では、週単位では任意の曜日を一
つまたは複数指定できる。この例では、曜日を指定して
毎週運転するようにしているが、第１週であるとか第３
週といった指定であっても良い。次に、月単位個別指示
領域２４２では、月単位で任意の日付を四つまで指定で
きる。この例では四つまでとなっているが、３１日分の
チェックボックスを用意しておいて任意の数だけ指定で
きるようにしても良い。そして、日単位個別指示領域２
４３では、毎日指定時刻になったときにアクセスする
か、週単位や月単位でアクセスする場合の時間を指定す
る。

【００６０】個別指示領域２４１〜２４３については択
一の選択が可能であり、また、自動更新予測指示領域２
３０と定期運転指示領域２４０についても択一の選択が
可能となっている。

【００６１】このような設定用画面２００での設定に基
づいて図４に示す手順に従って情報取得の処理が実行さ
れる。最初に、ステップＳ３００では択一的な指示が可
能な自動更新予測運転か定期運転かを判断する。自動更
新予測指示領域２３０と定期運転指示領域２４０とはボ
タンによって択一的な選択となっており、ここで自動更
新予測指示領域２３０の側のボタンをセットしてあると
きには、ステップＳ３１０へとすすむし、定期運転を指
示しているときにはその指示内容に応じて該当するチェ
ック日時であるか否かをステップＳ３６０にて判断し、
該当する場合にはステップＳ３７０にて該当するＵＲＬ
のＷＥＢサイトに対して能動的にアクセスし、情報を取
得する。

【００６２】ここで自動更新予測処理の実体について説
明する。本自動更新予測処理の実質は、図６に示す初回
アクセス処理と、図７に示す次回チェック日時取得処理
とから構成される。

【００６３】次回チェック日時取得処理は、最新の情報
をできる限り少ないアクセスで確保しようとするもので
あり、ＷＥＢサイトから得られるＨＴＭＬ文書を解析し
て当該ＷＥＢサイトが次回に情報を更新する日時を予測
する。この予測の手法は、概ね三種に分かれる。以下、
このＨＴＭＬ文書を単に情報と呼ぶ。

【００６４】第一の手法は、情報の中に次回更新日の開
示が有るか否かを検討する手法である。ＷＥＢサイトの
運営者が次回の更新予定日を情報中に開示することが多
い。従って、同情報中に開示されていないか判断する。
具体的には、文書データに絞り込み、「次回更新予定
日」という文字データ、あるいはこれに類似する文字デ
ータがあるか否かを判断する。そして、見つかった場合
にはそれに続く文字データとしての日付を取得する。日
付は文字データとして表すときにいくつものフォーマッ
トが考えられる。例えば、「１９９８年１月１日」も
「平成１０年１月１日」も「１９９８／１／１」も全て
同じ日付であるため、整形する処理と合わせて日付を得
る。そして、得られた日付を次回チェック日時として判
断する。

【００６５】なお、更新予定日が日にち単位でしか取得
できない場合もあるが、その場合には正午であるとか、
夜中の１２時などに統一してしまう。また、以下におい
ても、日にち単位の判断で行わなければならない場合も
あるが、必ずしも厳密に考えることなく、大まかには日
にち単位で処理すればよい。従って、内部的には時間ま
で設定しておくことにしたとしても、コンピュータ端末
１００がその時間に稼働しているとは限らないことまで
考えれば、たとえ次回更新日時が午後７時であったとし
ても、日付が一致したならば午後３時に自動運転すると
いうことも有意義だからである。むろん、原則どおり
に、時間まで踏まえて制御し、午後７時前にコンピュー
タ端末１００がオフにされたら、翌日に起動された時点
でチェックするようにしても構わない。

【００６６】この手法は図１において更新予定日取得手
段４１に該当し、図６の初回アクセス処理でのステップ
Ｓ４０５，Ｓ４１０に該当するとともに、図７の次回チ
ェック日時取得処理でのステップＳ５１０，Ｓ５１５に
対当する。

【００６７】第二の手法は、情報の中に更新間隔の開示
が有るか否かを検討する手法である。ＷＥＢサイトの運
営者が更新間隔を定めていることが多く、そのような更
新間隔の開示がないか判断する。具体的時には、情報の
中に「毎週・・更新」、「毎月・・更新」、「毎・・日
更新」といった文字データ、あるいはこれに類似する文
字データがあるか否かを判断する。そして、見つかった
場合にはその更新間隔を解析する。

【００６８】また、ＷＥＢサイトでは少なくとも発信し
ている情報の最終更新日時だけは開示していることが多
い。従って、最終更新日時も次回更新予定日と同様に解
析して取得し、最終更新日時に上述した更新間隔を加え
た日を次回チェック日時として判断する。この手法は図
１において更新間隔取得手段４２に該当し、図６の初回
アクセス処理でのステップＳ４１５，Ｓ４２０に該当す
るとともに、図７の次回チェック日時取得処理でのステ
ップＳ５２０，Ｓ５２５に対当する。

【００６９】ただし、この最終更新日時についてはＷＥ
ＢサイトからＨＴＭＬ文書を取得するときに拡張情報と
して同時に取得できる情報でもある。従って、かかる解
析によらずにＨＴＭＬ文書を取得することによって得る
ようにしても構わない。以下、情報の中から取得するこ
とを前提とし、情報の中に含まれていない場合には補助
的に同拡張情報から得ることにする。

【００７０】第三の手法は、情報の中から更新履歴を読
み取る手法である。このアプローチには更に二つの手法
があり、一つ目は情報内に過去の複数の更新履歴が更新
日時リストとして開示されている場合に、それらの間隔
を見い出す手法であり、二つ目は最終の更新日時だけが
開示されている場合にはそれを記憶して自らのデータベ
ースとしておき、複数回情報を取得したときに間隔を見
出す手法である。

【００７１】更新日時リストを得られたときには複数の
更新間隔が得られることになるが、このときには最小の
間隔をとるようにしてもよいし、平均的な間隔を演算に
よって求めるようにしても良い。最新の情報を求める希
望を優先すれば最小の間隔を採用すべきであるものの、
たまたまあるときに更新間隔が短かったという場合には
無駄なアクセスが増えることになる。一方、平均の間隔
を採用する場合には、無駄なアクセスを防止する傾向を
高めるものの、あるときから更新間隔を短くしたという
ような場合には最新の情報を逃しやすくなる。従って、
長期にわたる平均はむしろ弊害の方が大きいと考えられ
る。このため、最小の間隔としたり、直近の三回の更新
間隔から平均を算出することとしたりする手法を適宜使
い分けることにする。むろん、直近の三回がない場合に
は二回以下であっても構わない。

【００７２】ところで、更新と同様の概念として掲載と
いう概念もある。例えば、ニュースなどの情報があれば
最終更新日時が分からなくても掲載日時リストがあれば
その間隔から更新間隔を実質的に把握できるということ
もある。もっとも、最終更新日時自体はＨＴＭＬ文書を
取得するのと同時に得ることも可能である。

【００７３】従って、以上のような更新日時リストや掲
載日時リストがある場合には、その間隔の中の最小を更
新間隔を求めるとともに、最終更新日時に加えて次回の
チェック日時とする。この手法は、図６においてステッ
プＳ４２５〜Ｓ４４０に該当する。

【００７４】また、前者のものであれば初めて情報を取
得したときにでも更新間隔を得られるが、後者のように
最終更新日時しか得られないような場合には更新間隔は
得られない。このため、今回チェック日時と得られた最
終更新日時との間隔を擬似的にチェック間隔と置き換
え、次回チェック日時は今回チェック日時にこのチェッ
ク間隔の半分を加える。この手法は、図６においてステ
ップＳ４４５，Ｓ４５０に該当する。

【００７５】初回アクセス処理の場合、ステップＳ４５
５にて以上のようにして得られた次回チェック日時をそ
れぞれのＵＲＬごとに記憶する。また、過去の更新履歴
が得られている場合にはそれも記憶するので、設定用画
面２００の更新履歴表示エリア２２０には各ＵＲＬ毎に
更新履歴が表示される。例えば、過去の更新日時は枠内
に四角のマーキングを行い、次回チェック日時には丸印
のマーキングを行っている。

【００７６】一方、次回以降のアクセスでは、過去三回
の更新間隔の平均をとってチェック間隔とし、このチェ
ック間隔を最終更新日時に加えて次回チェック日時とす
る。この手法をステップＳ５３０，Ｓ５３５に示してい
る。

【００７７】以上で、次回チェック日時を取得する手法
について説明した。従って、図４に示すフローチャート
に戻れば、ステップＳ３００にて自動更新予測運転と判
断されると、まず、ステップＳ３１０にて以上のような
初回アクセス処理が済んでいないかＵＲＬが登録されて
いるか否かを判断する。これは設定用画面２００では表
示しなかったもののＵＲＬを設定するのに伴って用意さ
れるフラグで判断できるようになっており、初期値は未
処理となっている。従って、ステップＳ３１０にて各Ｕ
ＲＬのフラグを判断し、未処理のものがあればステップ
Ｓ３２０にて、図６に示す初回アクセス処理を実行して
次回チェック日時を取得する。

【００７８】次に、ステップＳ３３０では各ＵＲＬごと
の次回チェック日時を参照し、本日に該当するものがあ
るか否かを判定する。次回チェック日時に該当するもの
があればステップＳ３４０にて該当するＵＲＬのＷＥＢ
サイトに対して能動的にアクセスし、情報を取得する。
必要な情報を全て取得したら通信を終了し、ステップＳ
３５０では図７に示す次回チェック日時取得処理を実行
する。

【００７９】次回チェック日時を取得する手法について
は上述したとおりであるが、この次回チェック日時取得
処理を実行したのは予め予測した更新予定日であるか
ら、実際に更新されていることもあれば実際には更新さ
れていないこともあり得る。

【００８０】従って、ステップＳ５００にて情報を取得
した後、ステップＳ５０５では情報が更新されているか
否かを判断し、情報が更新されていれば上述したような
手法で次回のチェック日時を取得するとともに、ステッ
プＳ５４５にて各ＵＲＬの次回チェック日時にセットす
る。

【００８１】これに対して、情報が更新されていない場
合の処理が問題となる。この場合は、前回に設定した次
回チェック日時が正しくないので、修正をかける。この
修正の手法もいくつか有効であるが、本実施形態におい
ては、最初にある程度の間隔を決定し、繰り返していく
につれて徐々に間隔を短くするという手法を採用してい
る。その前提として、ステップＳ５３０では過去の更新
間隔のうちの最小更新間隔を保存しておき、ステップＳ
５４０ではこの最小更新間隔を連続未更新回数（＋１）
で割り、その商を今回のチェック日時に加えることにす
る。

【００８２】また、初回アクセス処理においてステップ
Ｓ４３０，Ｓ４４０にて過去の更新日時リストなどから
最小更新間隔を取得しておくとともに、過去の更新間隔
を得られなかった場合にはステップＳ４４５にて最小更
新間隔にチェック間隔を保存している。

【００８３】このように、最小間隔を使用しながらも、
徐々にその間隔を短くしながら次回チェック日時を修正
するフィードバックをかけており、この意味ではＷＥＢ
サイトの運営者が予定を開示していない場合、過去の更
新履歴を記憶するとともに、その更新履歴に基づいて更
新予測を行い、さらには、実際の更新日時を得てフィー
ドバックを行うことになる。すなわち、更新履歴記憶手
段４３ａ、更新予測手段４３ｂ、実更新日時フィードバ
ック手段４３ｃを実現しているといえる。

【００８４】次に、上記構成からなる本実施形態の動作
を図８に示すシミュレーションを参照して説明する。

【００８５】ここで情報取得効率μｉを以下のように定
義し、本実施形態における更新予測を利用する場合と定
期運転を利用する場合とを比較してみることにする。

【００８６】 μｉ＝ｒｈ（１−ｒｐ）ｒｇ／（１＋Ｎ）＊＊２ …（１）ｒｈ：ヒット率＝情報取得回数／アクセス回数ｒｐ：ペナルティ率＝ペナルティ／監視日数（ペナルティ＝情報取得日時−最終更新日時）ｒｇ：取得率＝取得回数／更新回数Ｎ：情報喪失数以下、図８のシミュレーションを実行することにする。
あるＷＥＢサイトでの実際の更新日は「１日」「５日」
「１１日」「２２日」「２７日」であったとし、「４
日」から更新予測を行う自動設定パターンと、毎週月曜
日と金曜日に定期運転する第一の定期パターンと、毎週
火曜日に定期運転する第二の定期パターンとを対比す
る。なお、「４日」が月曜日である。

【００８７】自動設定では、４日に情報を取得したとこ
ろ、１日に最終更新日時があったことが分かった。従っ
て、初回アクセス処理ではステップＳ４４５にて「チェ
ック間隔＝今回のチェック日時−最終更新日時」という
計算を実行し、チェック間隔と最小更新間隔は「３日」
とするとともに、次回チェック日時はステップＳ４５０
の「次回チェック日時を今回のチェック日時＋チェック
間隔／２」という計算を実行し、「６日」という結果を
得る。なお、端数は切り上げとする。

【００８８】この６日にアクセスすると、情報は「５
日」に更新されていたため、これで二つの更新履歴を得
られる。すると、ステップＳ５３０での「更新間隔＝今
回更新日時−前回更新日時」という計算を実行すると
「４日」という結果が得られる。一方、チェック間隔は
過去三回の更新間隔の平均であるが、一回分しかないの
でそのまま利用すると「４日」となる。さらに、最小更
新間隔も同様とする。そして、ステップＳ５３５にて
「次回のチェック日時＝最終更新日時＋チェック間隔」
という計算を実行すると、「９日」となる。

【００８９】しかし、９日にアクセスしても情報は更新
されておらず、ステップＳ５４０では「次回のチェック
日時＝今回のチェック日時＋最小更新間隔／（連続未更
新回数＋１）」という計算を行うと、「１１日」が得ら
れ、この１１日では見事に一致する。ここで、次回のチ
ェック日時を検討する際には、「最小更新間隔／（連続
未更新回数＋１）」というようにして徐々にチェック間
隔を短くしている。これは、予定日を過ぎているので、
今後、更新される確率が高くなっていくことに鑑みて間
隔を短くしていっている。

【００９０】次のチェック日時は「１６日」であるが、
１４日に３日ぶりに更新されており、最小更新間隔を更
新する。

【００９１】以後、自動設定では、「１９日」、「２１
日」と空振りとなるものの、連続未更新回数のフィード
バックが功を奏して「２２日」には一致し、「２８日」
は一日遅れで情報を得られる。

【００９２】一方、第一の定期パターンでは、「８日」
において３日遅れで情報を取得し、「１１日」に一致
し、「１５日」に１日遅れで情報を取得し、「１８日」
に空振りし、「２２日」に一致し、「２５日」に空振り
する。

【００９３】また、第二の定期パターンでは、「１１
日」に一致するものの、「５日」の更新情報を取得でき
なかった。そして、「１８日」に４日遅れで情報を取得
し、「２５日」に３日遅れで情報を取得する。

【００９４】以上のシミュレーションに基づいて有効性
を検討した結果を図９に示している。アクセス回数に対
する情報取得回数をヒット率と計算し、ペナルティの合
計を加算しつつその平均を求めている。また、情報喪失
数がある場合には、それも表示している。なお、参考の
ために毎日チェックした場合も含めてある。

【００９５】さらに、図１０には最終的な情報取得効率
μｉを示しており、この更新予測を利用した場合の情報
取得効率が最も高いことが分かる。なお、（１）式の特
徴として、第二の定期パターンではヒット率が１００％
であるにもかかわらず、情報取得効率が低くなる傾向が
ある。これは、ペナルティが多かったのと情報の取りこ
ぼしがあったことを重視しているからである。また、毎
日チェックする場合にはペナルティが「０」となるもの
のアクセス数が非常に多いので効率が悪くなるという傾
向も示している。いずれの場合も、実感的な効率に基づ
いて算出していることがよく分かる。

【００９６】さて、これまではＷＥＢサイトのＨＴＭＬ
文書を取得する例について説明してきたが、このように
情報を解析して更新予測する手法はこのようなＨＴＭＬ
文書に限られるものではなく、図１１に示すような自動
的なシステムアップデート処理も適用可能である。

【００９７】このシステムアップデート処理では、ファ
ームウェアを含めた各種のシステムプログラムを自動的
にダウンロードして更新させるものである。チェック日
時の計算は前述した例に則っている。

【００９８】ステップＳ６００にて本日の日付と次回チ
ェック日時として記憶されている日付とを比較し、一致
していればステップＳ６０５にて情報を取得する。この
情報の取得は、例えばファイルサーバに対して登録され
ているプログラムファイルの一覧表を取得する処理など
が該当する。そして、各プログラムファイルのタイムス
タンプをチェックし、ステップＳ６１０にて更新されて
いるものがあるか否かを判断する。更新されているもの
があればステップＳ６１５にてそのプログラムファイル
をダウンロード後、ステップＳ６２０にてシステムアッ
プデート処理を実行する。このシステムアップデート処
理は、ダウンロードするプログラムファイルを仮の領域
に保存しつつ、システムをリセットし、イニシャル処理
においてそのプログラムファイルを本来の領域にコピー
してから起動するといった手順などが考えられる。むろ
ん、同様の処理を別の手法によって実現することも可能
であり、リセットしないで次回の起動時にロードし直す
ようにしたり、リセットのタイミングを夜中などに行う
ようにするといったことも可能である。

【００９９】更新したか否かは別のフラグなどに残して
おき、ステップＳ６２５では更新の有無などに応じて次
回チェック日時を設定する。

【０１００】このように、従来であれば、勘に頼って定
期的な自動運転を行ない、当てずっぽう式の手法で情報
を取得するようにしていたが、得られた情報の中に次回
の更新予定日であるとか、更新間隔などがないか判断す
るとともに、これらが無い場合には過去の更新履歴に基
づいて次回の更新を予測するようにしたため、いたずら
にアクセス回数を増やすことなく、可能な限り最新の情
報を維持するということが可能となる。

【図面の簡単な説明】

【図１】本発明の一実施形態にかかる情報取得装置のク
レーム対応である。

【図２】本情報取得装置が広域ネットワークに接続され
る全体像を示す概略図である。

【図３】情報取得装置を実現するコンピュータ端末の概
略構成図である。

【図４】情報取得装置を実現するソフトウェアの概略フ
ローチャートである。

【図５】情報取得装置の設定用画面を示す図である。

【図６】初回アクセス処理のフローチャートである。

【図７】次会チェック日時取得処理のフローチャートで
ある。

【図８】シミュレーションを示す図である。

【図９】シミュレーションの結果を示す図である。

【図１０】シミュレーションの結果に伴う情報取得効率
を示す図である。

【図１１】システムアップデート処理を示すフローチャ
ートである。

【符号の説明】

１０…情報取得装置２０…情報取得手段３０…自動運転手段４０…次回更新日時取得手段４１…更新予定日取得手段４２…更新間隔取得手段４３ａ…更新履歴記憶手段４３ｂ…更新予測手段４３ｃ…実更新日時フィードバック手段５０…広域ネットワーク６０…通信回線７０…情報発信源

───────────────────────────────────────────────────── フロントページの続き (51)Int.Cl.⁶ 識別記号ＦＩＧ０６Ｆ 15/74 ３２０Ｄ

Claims

【特許請求の範囲】

【請求項１】広域ネットワークの通信回線を介して情
報発信源に対して能動的にアクセスして同情報発信源が
発信する情報を取得する情報取得装置であって、上記通信回線を介して上記情報発信源と接続されたとき
に当該情報発信源が発信している情報を取得する情報取
得手段と、設定したチェック日時に上記情報取得手段を所定の情報
発信源に接続させるように自動運転する自動運転手段
と、上記情報取得手段によって取得した上記情報を解析する
ことによって次回更新日時を得るとともに当該次回更新
日時後に上記情報を取得するように上記自動運転手段の
チェック日時を設定する次回更新日時取得手段とを具備
することを特徴とする情報取得装置。
【請求項２】上記請求項１に記載の情報取得装置にお
いて、上記次回更新日時取得手段は、取得した上記情報を解析して次回の更新予定日があれば
当該更新予定日を次回更新日時と判断する更新予定日取
得手段を有することを特徴とする情報取得装置。
【請求項３】上記請求項１または請求項２のいずれか
に記載の情報取得装置において、上記次回更新日時取得
手段は、取得した上記情報を解析して直近の更新日時と更新間隔
の情報を取得して上記直近の更新日時から当該更新間隔
後の日時を次回更新日時と判断する更新間隔取得手段を
有することを特徴とする情報取得装置。
【請求項４】上記請求項１〜請求項３のいずれかに記
載の情報取得装置において、上記次回更新日時取得手段
は、取得した上記情報の内容から得られる過去の更新日時情
報を記憶する更新履歴記憶手段と、この更新履歴記憶手段にて記憶されている更新日時情報
の履歴に基づいて次回更新日時を予測する更新予測手段
と、この予測結果に基づく次回のチェック日時に得られる上
記情報に基づいて実更新日時を得て上記更新予測手段に
よる次回更新日時の予測にフィードバックをかける実更
新日時フィードバック手段とを有することを特徴とする
情報取得装置。
【請求項５】上記請求項１〜請求項４のいずれかに記
載の情報取得装置において、上記更新履歴記憶手段は、直近の更新日時とともに過去
の複数回の更新履歴を記憶し、上記更新予測手段は、上記更新履歴から更新間隔を取得
しつつ直近の更新日時に同更新間隔を加えたものを次回
更新日時と予測することを特徴とする情報取得装置。
【請求項６】上記請求項５に記載の情報取得装置にお
いて、上記更新予測手段は、上記更新履歴における間隔
の平均を更新間隔とすることを特徴とする情報取得装
置。
【請求項７】上記請求項５に記載の情報取得装置にお
いて、上記更新予測手段は、上記更新履歴における間隔
の最小値を更新間隔とすることを特徴とする情報取得装
置。
【請求項８】上記請求項５に記載の情報取得装置にお
いて、上記更新予測手段は、最初の情報取得時に直近の
更新日時と当該情報取得日時との間隔を取得して更新間
隔と判断することを特徴とする情報取得装置。
【請求項９】上記請求項１〜請求項８のいずれかに記
載の情報取得装置において、上記情報発信源はＷＥＢサ
イトであり、上記情報はＨＴＭＬ文書であることを特徴
とする情報取得装置。
【請求項１０】上記請求項１〜請求項８のいずれかに
記載の情報取得装置において、上記情報発信源は、当該
情報取得端末で実行するプログラムファイルの供給サー
バであり、上記情報には、当該プログラムファイルが含
まれ、実行用プログラムファイルの最新情報を取得する
ことを特徴とする情報取得装置。
【請求項１１】上記請求項１〜請求項１０のいずれか
に記載の情報取得装置において、上記広域ネットワーク
が、インターネットであることを特徴とする情報取得装
置。
【請求項１２】広域ネットワークの通信回線を介して
情報発信源に対して能動的にアクセスして同情報発信源
が発信する情報を取得する情報取得方法であって、設定したチェック日時に自動運転して、上記通信回線を
介して上記情報発信源と接続し、当該情報発信源が発信
している情報を取得するとともに、この取得した情報を
解析することによって次回更新日時を得て、この更新日
時後に上記情報を取得するように次回のチェック日時を
設定することを特徴とする情報取得方法。
【請求項１３】広域ネットワークの通信回線を介して
情報発信源に対して能動的にアクセスして同情報発信源
が発信する情報を取得する情報取得プログラムを記録し
た媒体であって、設定したチェック日時に自動運転して、上記通信回線を
介して上記情報発信源と接続し、当該情報発信源が発信
している情報を取得するとともに、この取得した情報を
解析することによって次回更新日時を得て、この更新日
時後に上記情報を取得するように次回のチェック日時を
設定することを特徴とする情報取得プログラムを記録し
た媒体。