(57)【要約】【課題】ユーザ全体の利用状況に基づき、各ユーザが、リンク切れ等で利用価値のないフィードやより良質なフィードを容易に知ることができ、フィードリストのメンテナンス作業の負荷を軽減できる。【解決手段】フィードリスト管理ＤＢが、ユーザ毎のフィードリストを管理する。変更検出部は、ユーザ端末装置から送信されるフィードＵＲＬの変更データを受信すると、そのユーザのフィードリストを更新する。通知判別部は、ルール管理ＤＢのルールに基づいて、変更したフィードと同一もしくは関連するフィードリストを持つ他のユーザ（通知対象ユーザ）の端末装置に、フィードＵＲＬの変更を通知するか否か判別する。通知する場合、通知情報選択部が、通知対象ユーザが利用する端末装置に対し、フィードＵＲＬの変更および他ユーザの利用傾向等の付加情報等の通知内容を作成して、ウィンドウ情報作成部が通知する。【選択図】図４
2008146422.tif 000002
【特許請求の範囲】
【請求項１】
コンピュータを、
ユーザが購読を希望した文書の位置情報と前記文書の概要の位置を示す概要位置情報とを有するユーザリストを、前記ユーザ毎に管理するリスト管理ＤＢと、
あるユーザが利用する端末装置から送信される前記概要位置情報の変更に関する変更データを受信し、当該ユーザの前記ユーザリストの前記概要位置情報を変更する変更手段と、
所定の判別ルールに基づいて、変更した前記概要位置情報もしくは変更した前記概要位置情報に対応する前記文書の位置情報を前記ユーザリストに有する他のユーザが利用する前記端末装置に、前記概要位置情報の変更を通知すべきか否かを判別する通知判別手段と、
前記通知判別手段が通知すべきと判別したとき、前記他のユーザが利用する前記端末装置に対し、前記概要位置情報の変更を含む通知情報を通知する通知手段、
として機能させることを特徴とするリンク情報管理プログラム。
【請求項２】
前記通知手段は、前記変更の内容を補足する補足情報を前記通知情報に付加して通知することを特徴とする請求項１記載のリンク情報管理プログラム。
【請求項３】
前記コンピュータを、前記他のユーザが利用する前記端末装置から送信される前記通知情報に応答する応答情報を受信すると、前記他のユーザの前記ユーザリストの前記概要位置情報を、当該ユーザが利用する前記端末装置から送信された前記概要位置情報に変更する応答管理手段、として機能させることを特徴とする請求項１記載のリンク情報管理プログラム。
【請求項４】
あるユーザが利用する端末装置から送信される前記ユーザが購読を希望した文書の概要の位置を示す概要位置情報の変更に関する変更データを受信すると、前記文書の位置情報と前記概要位置情報とを有するユーザリストを前記ユーザ毎に管理するリスト管理ＤＢの、当該ユーザの前記ユーザリストの前記概要位置情報を変更し、
所定の判別ルールに基づいて、変更した前記概要位置情報もしくは変更した前記概要位置情報に対応する前記文書の位置情報を前記ユーザリストに有する他のユーザが利用する前記端末装置に、前記概要位置情報の変更を通知すべきか否かを判別し、
通知すべきと判別したとき、前記他のユーザが利用する前記端末装置に対し、前記概要位置情報の変更を含む通知情報を通知する、
ことを特徴とするリンク情報管理方法。
【請求項５】
ユーザが購読を希望した文書の位置情報と前記文書の概要の位置を示す概要位置情報とを有するユーザリストを、前記ユーザ毎に管理するリスト管理ＤＢと、
あるユーザが利用する端末装置から送信される前記概要位置情報の変更に関する変更データを受信し、当該ユーザの前記ユーザリストの前記概要位置情報を変更する変更手段と、
所定の判別ルールに基づいて、変更した前記概要位置情報もしくは変更した前記概要位置情報に対応する前記文書の位置情報を前記ユーザリストに有する他のユーザが利用する前記端末装置に、前記概要位置情報の変更を通知すべきか否かを判別する通知判別手段と、
前記通知判別手段が通知すべきと判別したとき、前記他のユーザが利用する前記端末装置に対し、前記概要位置情報の変更を含む通知情報を通知する通知手段と、
を有することを特徴とするリンク情報管理装置。
【請求項６】
コンピュータを、
ユーザが購読を希望した文書に関する位置を記録した位置情報を有するユーザリストを、前記ユーザ毎に管理するリスト管理ＤＢ、
あるユーザが利用する端末装置から送信される前記位置情報の変更に関する変更データを受信し、当該ユーザの前記ユーザリストの前記位置情報を変更する変更手段と、
所定の判別ルールに基づいて、変更した前記位置情報に対応する位置情報を前記ユーザリストに有する他のユーザが利用する前記端末装置に、前記位置情報の変更を通知すべきか否かを判別する通知判別手段と、
前記通知判別手段が通知すべきと判別したとき、前記他のユーザが利用する前記端末装置に対し、前記位置情報の変更を含む通知情報を通知する通知手段、
として機能させることを特徴とするリンク情報管理プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はリンク情報管理プログラム、リンク情報管理装置およびリンク情報管理方法に関する。
【背景技術】
【０００２】
Ｗｅｂページを閲覧する際に用いるアプリケーションソフトの一つであるＷｅｂブラウザには、所望のＷｅｂページを容易に閲覧するための種々の機能が設けられている。この機能の一つとして頻繁に閲覧するＷｅｂページの位置（ＵＲＬ）を保存するブックマークが利用される。
【０００３】
ブックマークにＵＲＬを保存することでユーザは、ＵＲＬを入力したり、検索したりする手間を省くことができる。
ブックマークにＵＲＬを保存するには、例えばブックマークに追加したいＷｅｂページを開いた状態で、ブラウザに設けられたブックマーク追加機能を操作する。これにより、ブックマークにＷｅｂページのＵＲＬとともに、そのＷｅｂページのタイトルが保存される。
【０００４】
そして、ユーザが保存したＷｅｂページの閲覧を希望するときは、ブックマークに保存されているタイトルをマウス等で選択する。これにより迅速にそのＷｅｂページに移動することができる。
【０００５】
ところで、近年、所望のＷｅｂページを容易に閲覧する他のアプリケーションソフトとしてフィードリーダが広まりつつある。
フィードリーダは、あるＷｅｂページの概要情報が記載されるフィードの位置（以下、フィードＵＲＬという）を保存するフィードリストを有している。
【０００６】
フィードは、Ｗｅｂページから提供されるＲＳＳ（Rich Site Summary）やＡｔｏｍといったＸＭＬフォーマットで記述されており、例えばニュースに関するＷｅｂページのフィードは、概要情報として各ニュース記事のタイトル、日付、要約（description）、各記事のＵＲＬ等を有している。
【０００７】
このフィードリーダは、フィードリストに保存されているフィードＵＲＬを定期的に自動で巡回し、前述した概要情報を取得する。また、ユーザによる記事の未読・既読を管理する機能を有しており、取得してきた概要情報の中に未読記事があった場合、Ｗｅｂページの更新があったと判断して、ユーザに報知する。これにより、ユーザは、自ら定期的にサイトを巡回して更新の有無をチェックする必要がなく、更新された情報だけを効率よく閲覧することができる。
【０００８】
ここで、フィードの配信方法（作成方法）としては、以下のものが存在する。
１）Ｗｅｂページの管理者が公式的に配信する。
管理者側でフィードを用意し配信しているＷｅｂページの場合、ページ内にフィードアイコンが設置され、ユーザに利用を促していることが多い。このページの購読を希望するユーザは、例えばそのアイコンをフィードリーダにドラッグ＆ドロップすること等により、各自のフィードリストにフィードＵＲＬを保存することができる。
【０００９】
２）Ｗｅｂページ管理者とは別個の第三者が配信する。
管理者側でフィードを配信していないＷｅｂページ等に対して第三者が自動フィード作成プログラム等を用いてＷｅｂページから概要情報を作成し、配信する。多くの場合、この概要情報は元のＷｅｂページとは別サーバで配信される。
【００１０】
ところが、このように購読を希望したＷｅｂページやフィードをブックマークやフィードリストに登録しておいても、Ｗｅｂページの移動や、フィード配信サービスの停止等の原因により、ＷｅｂページやフィードのＵＲＬが変更されることがある。この場合にはユーザが気づいたときにＷｅｂページやフィードの新たなＵＲＬを探しなおしてその変更をブックマークやフィードリストに再登録する必要がある。しかし、こういったメンテナンス作業には大変手間がかかるという問題がある。
【００１１】
このような問題に対し、例えば、ブックマークを管理する管理サーバがブックマークに保存されているＵＲＬを巡回し、アクセス不能なものを検出することにより、リンク切れを起こしているＵＲＬを発見し、自動的に新たなＵＲＬに更新する方法が知られている（例えば、特許文献１参照）。
【特許文献１】特開２００１−２７３１８５号公報
【発明の開示】
【発明が解決しようとする課題】
【００１２】
しかしながら、フィードリストにはブックマークとは異なる特有の問題が存在する。
まず、フィードは、更新された情報だけを閲覧するという性質上、次の課題１が存在する。
【００１３】
［課題１］リンク切れしていなくても、更新が止まったページのフィードは不要になり、フィードリストから削除すべきである。例えば、自動生成フィードを利用している際に頻発する課題だが、「２００５年度新着情報」のページから自動生成したフィードを登録して利用している場合、２００６年度に変わると、そのページは更新されなくなり、不要となる。そして、「２００６年度新着情報」のページが新たに存在することが多く、そちらを登録しなおす必要がある。このとき、システムは、再登録先が２００６年度のページであることを自動判断しなければならない。このように、機能しなくなったフィードの検出は、従来のように単にリンク切れを検出するだけでは不十分である。例に挙げた年度の変更に限らず、フィードが機能しなくなる現象とその再登録先には様々なタイプがあり、ルール指定によってこれらすべてに自動対応することは容易ではない。
【００１４】
また、同じＷｅｂページに対し、公式フィードと第三者による自動生成フィード等、複数のフィードが同時に存在する（同じＷｅｂページを閲覧するのに、複数の経由方法がある）性質上、次の課題２、３が存在する。
【００１５】
［課題２］例えば公式フィードがないＷｅｂページに対し、自動生成フィードを利用している場合、公式フィードの配信が始まったら、そちらに乗り換える作業を行いたい。しかし、公式フィードが出ても、これまで利用してきた自動生成フィードが機能停止するわけではなくそのまま継続的に利用することができるため、リンク切れを含め機能停止したフィードの検出だけをトリガとした方法では、公式フィードの出現に気がつかない。
【００１６】
［課題３］フィードが複数存在している場合に、どのフィードが最も良質か（どのフィードを各自のフィードリストに登録して利用するべきか）、自動で判断するのは難しい（そもそも、人手で判断するにしても、スキルの低い初心者が、継続的に利用する前に一目で判断することは容易ではない）。
【００１７】
本発明はこのような点に鑑みてなされたものであり、ユーザがより良質な未知のフィードを容易に知ることができ、フィードリストのメンテナンス作業の負荷を軽減できるリンク情報管理プログラム、リンク情報管理装置およびリンク情報管理方法を提供することを目的とする。
【課題を解決するための手段】
【００１８】
本発明では上記問題を解決するために、図１に示すような処理をコンピュータに実行させるためのリンク情報管理プログラムが提供される。
リンク情報管理プログラムを実行するコンピュータ１は以下の機能を有する。
【００１９】
リスト管理ＤＢ（データベース）２が、ユーザが購読を希望した文書の位置情報とこの文書の概要の位置を示す概要位置情報とを有するユーザリストを、ユーザ毎に管理する。
変更手段３が、あるユーザが利用する端末装置４から送信される概要位置情報の変更に関する変更データを受信し、このユーザのユーザリストの概要位置情報を変更する。
【００２０】
通知判別手段５が、所定の判別ルールに基づいて、変更した概要位置情報もしくは変更した概要位置情報に対応する文書の位置情報をユーザリストに有する他のユーザが利用する端末装置に、概要位置情報の変更を通知すべきか否かを判別する。
【００２１】
通知判別手段５が通知すべきと判別したとき、通知手段７が、他のユーザが利用する端末装置６に対し、概要位置情報の変更を含む通知情報を通知する。
このようなリンク情報管理プログラムによれば、リスト管理ＤＢ２により、ユーザリストが、ユーザ毎に管理される。変更手段３により、あるユーザが利用する端末装置４から送信される概要位置情報の変更に関する変更データが受信され、このユーザのリストの概要位置情報が変更される。通知判別手段５により、所定の判別ルールに基づいて、変更した概要位置情報もしくは変更した概要位置情報に対応する文書の位置情報をユーザリストに有する他のユーザが利用する端末装置に、概要位置情報の変更を通知すべきか否かが判別される。通知判別手段５により通知すべきと判別されたとき、通知手段７により、他のユーザが利用する端末装置６に対し、概要位置情報の変更を含む通知情報が通知される。
【００２２】
また、上記課題を解決するために、あるユーザが利用する端末装置から送信される前記ユーザが購読を希望した文書の概要の位置を示す概要位置情報の変更に関する変更データを受信すると、前記文書の位置情報と前記概要位置情報とを有するユーザリストを前記ユーザ毎に管理するリスト管理ＤＢの、当該ユーザの前記ユーザリストの前記概要位置情報を変更し、所定の判別ルールに基づいて、変更した前記概要位置情報もしくは変更した前記概要位置情報に対応する前記文書の位置情報を前記ユーザリストに有する他のユーザが利用する前記端末装置に、前記概要位置情報の変更を通知すべきか否かを判別し、通知すべきと判別したとき、前記他のユーザが利用する前記端末装置に対し、前記概要位置情報の変更を含む通知情報を通知することを特徴とするリンク情報管理方法が提供される。
【００２３】
このようなリンク情報管理方法によれば、変更データが受信されると、リスト管理ＤＢの、変更データを送信したユーザのユーザリストの概要位置情報が変更される。そして、所定の判別ルールに基づいて、変更した概要位置情報に対応する文書の位置情報をユーザリストに有する他のユーザが利用する端末装置に、概要位置情報の変更を通知すべきか否かが判別される。通知すべきと判別されたとき、他のユーザが利用する端末装置に対し、概要位置情報の変更を含む通知情報が通知される。
【００２４】
また、上記課題を解決するために、ユーザが購読を希望した文書の位置情報と前記文書の概要の位置を示す概要位置情報とを有するユーザリストを、前記ユーザ毎に管理するリスト管理ＤＢと、あるユーザが利用する端末装置から送信される前記概要位置情報の変更に関する変更データを受信し、当該ユーザの前記ユーザリストの前記概要位置情報を変更する変更手段と、所定の判別ルールに基づいて、変更した前記概要位置情報もしくは変更した前記概要位置情報に対応する前記文書の位置情報を前記ユーザリストに有する他のユーザが利用する前記端末装置に、前記概要位置情報の変更を通知すべきか否かを判別する通知判別手段と、前記通知判別手段が通知すべきと判別したとき、前記他のユーザが利用する前記端末装置に対し、前記概要位置情報の変更を含む通知情報を通知する通知手段とを有することを特徴とするリンク情報管理装置が提供される。
【００２５】
このようなリンク情報管理装置によれば、上記リンク情報管理プログラムを実行するコンピュータと同様の処理が実行される。
【発明の効果】
【００２６】
本発明では、所定の判別ルールに基づいて、あるユーザの行ったフィードの変更が、他のユーザが利用する端末装置に通知される。これにより、ユーザは、あるフィードが機能し続けている場合でも、関連する未知のフィードの存在を容易に知ることができる。また、同じＷｅｂページに対し複数のフィードが存在している場合に、システムは、ユーザ全体の利用状況を使って、フィードの質を自動判定することができ、ユーザにより良いフィードへの変更を通知することができる。よって、ユーザは、リンク切れの修正に限らず、フィードリストの質をより向上させることを目的としたメンテナンス作業が容易に可能となる。初心者のユーザでも、利用当初から、スキルの高いユーザと同様のメンテナンス作業を行うことができる。
【００２７】
特に、変更の内容を補足する補足情報（他のユーザの利用状況等）を通知情報に明示的に付加して通知した場合には、ユーザ自身が通知された変更を自分のユーザリストに反映させるべきか判断するための材料を併せて得ることができる。
【発明を実施するための最良の形態】
【００２８】
以下、本発明の実施の形態を、図面を参照して詳細に説明する。
まず、実施の形態に適用される発明の概要について説明し、その後、実施の形態の具体的な内容を説明する。
【００２９】
図１は、実施の形態に適用される発明を示す概要図である。
リンク情報管理プログラムは、コンピュータ１に対して図１に示すような処理を実行させることができる。
【００３０】
リスト管理ＤＢ２が、各ユーザが購読を希望した文書（Ｗｅｂページ）の位置情報（ホームＵＲＬ）と、この文書の概要（フィード）の位置を示す概要位置情報（フィードＵＲＬ）とを有するユーザリスト（フィードリスト）を、ユーザ毎（ユーザＩＤ毎）に管理する。
【００３１】
変更手段３が、あるユーザが利用する（あるユーザがユーザＩＤを用いてログインしている）端末装置４から送信される概要位置情報の変更に関する変更データを受信し、このユーザのユーザリストの概要位置情報を変更する。
【００３２】
通知判別手段５が、所定の判別ルールに基づいて、変更した概要位置情報に対応する（位置情報に記載された）文書の位置情報をユーザリストに有する他のユーザが利用する端末装置に、概要位置情報の変更を通知すべきか否かを判別する。
【００３３】
通知判別手段５が通知すべきと判別したとき、通知手段７が、他のユーザが利用する端末装置６に対し、概要位置情報の変更を含む通知情報を通知する。
なお、図１では２つの端末装置４、６が図示されているが、本発明では端末装置の数は特に限定されない。
【００３４】
このようなリンク情報管理プログラムによれば、リスト管理ＤＢ２により、ユーザリストが、ユーザ毎に管理される。変更手段３により、あるユーザが利用する端末装置４から送信される概要位置情報の変更に関する変更データが受信され、あるユーザのリストの概要位置情報が変更される。通知判別手段５により、所定の判別ルールに基づいて、変更した概要位置情報に対応する文書の位置情報をユーザリストに有する他のユーザが利用する端末装置に、概要位置情報の変更を通知すべきか否かが判別される。通知判別手段５により通知すべきと判別されたとき、通知手段７により、他のユーザが利用する端末装置６に対し、概要位置情報の変更を含む通知情報が通知される。
【００３５】
以下、本発明の実施の形態を具体的に説明する。
図２は、実施の形態の情報管理システムを示すブロック図である。
情報管理システムは、サーバ２０と、複数の端末装置４０ａ、４０ｂ、４０ｃ、４０ｄとがネットワーク１０を介して接続されている。
【００３６】
サーバ２０は、ユーザ毎のフィードリストを管理している。
端末装置４０ａ、４０ｂ、４０ｃ、４０ｄはそれぞれ、サーバ２０にアクセスし、フィードリストを参照する。また、インターネット１４に接続しており、フィードリストにもとづいて、インターネット１４上のＷｅｂページからフィードを取得する。
【００３７】
サーバ２０は、あるユーザが利用する端末装置４０ａからフィードＵＲＬの登録、更新または削除に関する変更データを受信すると、その変更をそのユーザのフィードリストに反映させる。そして、その変更を必要に応じて他のユーザが利用する端末装置４０ｂ、４０ｃ、４０ｄに通知する。そして他のユーザがフィードＵＲＬの変更を承諾すると、その変更が他のユーザのフィードリストに反映される。このようにすることで、１人のユーザのフィードＵＲＬの変更を他のユーザとの間で共有することができる。
【００３８】
図３は、端末装置のハードウェア構成例を示す図である。
サーバ２０は、ＣＰＵ（Central Processing Unit）１２１によって装置全体が制御されている。ＣＰＵ１２１には、バス１２７を介してＲＡＭ（Random Access Memory）１２２、ハードディスクドライブ（ＨＤＤ:Hard Disk Drive）１２３、グラフィック処理装置１２４、入力インタフェース１２５、および通信インタフェース１２６が接続されている。
【００３９】
ＲＡＭ１２２には、ＣＰＵ１２１に実行させるＯＳ（Operating System）のプログラムやアプリケーションプログラムの少なくとも一部が一時的に格納される。また、ＲＡＭ１２２には、ＣＰＵ１２１による処理に必要な各種データが格納される。ＨＤＤ１２３には、ＯＳやアプリケーションプログラムが格納される。また、ＨＤＤ１２３内には、プログラムファイルが格納される。
【００４０】
グラフィック処理装置１２４には、モニタ１１が接続されている。グラフィック処理装置１２４は、ＣＰＵ１２１からの命令に従って、画像をモニタ１１の画面に表示させる。入力インタフェース１２５には、キーボード１２とマウス１３とが接続されている。入力インタフェース１２５は、キーボード１２やマウス１３から送られてくる信号を、バス１２７を介してＣＰＵ１２１に送信する。
【００４１】
通信インタフェース１２６は、ネットワーク１０に接続されている。通信インタフェース１２６は、ネットワーク１０を介して、他のサーバや端末装置との間でデータの送受信を行う。
【００４２】
以上のようなハードウェア構成によって、本実施の形態の処理機能を実現することができる。なお、図３にはサーバ２０のハードウェア構成を示したが端末装置４０ａ、４０ｂ、４０ｃ、４０ｄについても同様のハードウェア構成で実現することができる。このようなハードウェア構成のシステムにおいて情報管理を行うために、サーバ２０内には、以下のような機能が設けられる。
【００４３】
図４は、サーバおよび端末装置の機能を示すブロック図である。
なお、図４では、端末装置４０ｃおよび端末装置４０ｄの図示を省略している。
サーバ２０は、フィードリスト管理ＤＢ２１と変更履歴管理ＤＢ２２とルール管理ＤＢ２３と変更検出部２４と通知判別部２５と通知情報選択部２６とウィンドウ情報作成部２７と応答管理部２８とを有している。
【００４４】
フィードリスト管理ＤＢ２１には、情報管理システムを利用しているユーザのフィードリストが格納されている。
変更履歴管理ＤＢ２２には、フィードＵＲＬを変更する変更データによって変更されたフィードＵＲＬの履歴を管理する変更履歴管理テーブルが格納されている。
【００４５】
ルール管理ＤＢ２３には、変更検出部２４と通知判別部２５と通知情報選択部２６とウィンドウ情報作成部２７と応答管理部２８との動作（処理）条件が定められたルールテーブルと、ユーザ毎の動作条件が定められるユーザルールテーブルとが格納されている。なお、フィードリストと変更履歴管理テーブルとルールテーブルとユーザルールテーブルの内容については後述する。
【００４６】
変更検出部２４は、各端末装置から変更データを受信する。そして、ルールテーブルに基づいて受信した変更データが検出対象の変更データであることを確認し、フィードリスト管理ＤＢ２１内のフィードリストを更新する。更新内容は変更データに応じて異なる。そして、変更データを通知判別部２５に渡す。
【００４７】
通知判別部２５は、変更データを受け取るとフィードリストおよびルールテーブルを参照し、変更が他のユーザに通知すべき変更か否かを判別する。
通知情報選択部２６は、変更が他のユーザに通知すべき変更である場合に変更を通知するユーザ（以下、「通知対象ユーザ」という）を選択し、変更履歴管理テーブルに必要な情報を記録する。
【００４８】
ウィンドウ情報作成部２７は、変更履歴管理テーブルに基づいて、通知対象ユーザ毎のウィンドウ情報を作成し、通知対象ユーザが利用している端末装置に送信する。なお、ウィンドウ情報については後述する。
【００４９】
応答管理部２８は、ウィンドウ情報に応じて通知対象ユーザが利用している端末装置から送信される応答情報を受信すると、その応答情報に含まれる応答内容をフィードリストおよび変更履歴管理テーブルに反映させる。そして、必要に応じてユーザルールテーブルを用いてウィンドウ情報作成部２７にウィンドウ情報を作成させる。
【００５０】
端末装置４０ａ、４０ｂは、それぞれ変更通知部４１ａ、４１ｂと更新候補受信部４２ａ、４２ｂと応答情報送信部４３ａ、４３ｂと、アプリケーション実行部４４ａ、４４ｂを有している。以下代表的に、端末装置４０ａの各機能について説明する。
【００５１】
変更通知部４１ａは、例えばユーザの操作等により作成された変更データをサーバ２０に通知する。
更新候補受信部４２ａは、ウィンドウ情報を受信し、そのウィンドウ情報をアプリケーション実行部４４ａに渡す。
【００５２】
応答情報送信部４３ａは、アプリケーション実行部４４ａから応答情報を受け取ると、その応答情報を応答管理部２８に送信する。
アプリケーション実行部４４ａは、ＧＵＩ（Graphical User Interface）を有しており、ユーザの端末装置４０ａの操作に応じてフィードリーダを起動し、端末装置４０ａが有するモニタに表示させる。また、ユーザの端末装置４０ａの操作に応じて応答情報を作成し、応答情報送信部４３ａに送る。
【００５３】
図５は、フィードリーダを示す図である。
フィードリーダ４５は、フィードリスト表示部４６とヘッドライン表示部４７と内容表示部４８とを有している。
【００５４】
フィードリスト表示部４６には、フィードリストに格納されているフィードのＷｅｂページタイトル４６１（図５では「Ｆ２プレスリリース」等）が表示される。
フィードリーダ４５は、フィードリスト上の各フィードＵＲＬに定期的にアクセスを行い、フィードを取得する。また、フィードリーダ４５側で、フィードの記事の未読および既読を管理しており、未読の記事があれば、新着イベント通知として、Ｗｅｂページタイトル４６１を太字にし、タイトルの右側に未読の記事の数を表示する。
【００５５】
ヘッドライン表示部４７には、Ｗｅｂページの記事のヘッドライン４７１が表示される。ヘッドライン表示部のヘッダ部分にはＷｅｂページタイトルと同じタイトルが表示される。新着の記事は例えば記号４７２等を表示することにより他の記事と区別される。
【００５６】
ユーザが、マウスを用いてクリックすること等によりヘッドライン４７１を選択すると、内容表示部４８にＷｅｂページの内容が表示される。そして、そのヘッドライン４７１は既読となる。
【００５７】
ユーザは、フィードリスト表示部４６上で、新規フィードの追加、不要になったフィードの削除、既存フィードのプロパティ情報の編集等、各自のフィードリストを自由に編集できる。
【００５８】
図６は、フィードのプロパティ編集画面を示す図である。本画面は、例えばフィードリスト表示部４６のＷｅｂページタイトルをマウスで選択（右クリック）すること等によって表示させる。
【００５９】
プロパティ４６１ａには、フィードＵＲＬとタイトルとＷｅｂページホームＵＲＬの欄が設けられている。
フィードＵＲＬの欄には、概要位置情報であるフィードＵＲＬが格納されている。
【００６０】
タイトルの欄には、フィードリスト表示部４６に表示されるＷｅｂページのタイトルが格納されている。フィードＵＲＬおよびタイトルは、ユーザが任意に編集することができる。
【００６１】
ＷｅｂページホームＵＲＬの欄には、Ｗｅｂページのホーム（トップページ）のＵＲＬが格納されている。
ユーザがＯＫボタンを押下することにより、編集内容が確定する。また、キャンセルボタンを押下することにより、編集内容がキャンセルされる。編集により変更が生じた場合、アプリケーション実行部４４ａは、この変更内容を変更データとして変更通知部４１ａに渡す。
【００６２】
次に、変更データとフィードリストと変更履歴管理テーブルとルールテーブルの内容について説明する。
図７は、変更データを示す図である。
【００６３】
変更データ３１１ａには、左側からパラメータ、変更前、変更後およびユーザＩＤの欄がこの順番に設けられている。パラメータの欄は、変更状態を識別するために設けられている。ユーザＩＤの欄は、変更データを送信したユーザＩＤが設定される。各欄の横方向に並べられた情報同士が互いに関連づけられている。
【００６４】
変更前および変更後の欄には、それぞれさらに、変更データを識別するためのタイトル、ホームＵＲＬ、フィードＵＲＬの欄が設けられている。
パラメータの欄には、変更データの属性（追加、編集、削除）が設定される。
【００６５】
変更前の欄には、変更前のＷｅｂページのタイトル、ホームＵＲＬおよびフィードＵＲＬが設定される。
パラメータの欄が「追加」の場合には、変更前の各項目にはいずれも「ｎｕｌｌ」が設定される。なお、パラメータの欄に「編集」または「削除」が設定される場合、変更前の欄には、それぞれ変更すべきまたは削除すべきデータが設定される。
【００６６】
変更後の欄には、変更後のＷｅｂページのタイトル、ホームＵＲＬおよびフィードＵＲＬが設定される。
ユーザＩＤの欄には、変更を行ったユーザＩＤが設定される。
【００６７】
図８は、フィードリストを示す図である。
フィードリスト２１ａには、ユーザＩＤ毎のリスト（ユーザリスト）が格納されている。各ユーザＩＤのリストには、１つのフィードのプロパティ情報としてフィードＵＲＬ（ｘｍｌＵｒｌ＝・・・）とＷｅｂページのタイトル（ｔｉｔｌｅ＝・・・）とホームＵＲＬ（ｈｔｍｌＵｒｌ＝・・・）とが関連づけられており、各フィードを図５の表示のようにフォルダ分けする構成の情報が、ＸＭＬ形式で記述されている。
【００６８】
図９は、変更履歴管理テーブルを示す図である。
変更履歴管理テーブル２２ａには、Ｎｏ．、通知先（ユーザＩＤ）、通知情報、通知Ｎｏ．、反応日時、反応、処理の欄が設けられている。通知情報の欄には、さらに旧タイトル、旧ホームＵＲＬ、旧フィードＵＲＬ、新タイトル、新ホームＵＲＬ、新フィードＵＲＬ、付加情報の欄が設けられており、各欄の横方向に並べられた情報同士が互いに関連づけられて、個々の管理情報を構成している。
【００６９】
Ｎｏ．の欄には、全通知の通し番号（１人の通知対象ユーザに対する１回の通知を識別する番号）が設定される。
通知先（ユーザＩＤ）の欄には、通知対象ユーザのユーザＩＤが設定される。
【００７０】
通知情報の欄には、通知対象ユーザがこれまで登録していた旧タイトル、旧ホームＵＲＬ、旧フィードＵＲＬおよびこれらにそれぞれ対応する新タイトル、新ホームＵＲＬ、新フィードＵＲＬが記録される。
【００７１】
付加情報の欄には、ユーザが通知された変更を自分のフィードリストに反映させるべきか判断する際に参考になる情報として、ＵＲＬとともにユーザに送信する、後述のルールテーブルで定められた付加情報が設定される。
【００７２】
通知Ｎｏ．の欄には、１回のフィード発見に対応して行われる通知すべてに共通の、発見を識別する番号と、その発見について同一の通知対象ユーザに通知される１回の通知を識別する番号の組み合わせが設定される。
【００７３】
反応日時の欄には、通知対象ユーザが利用する端末装置からの応答情報を受信したときの日時が設定される。
反応の欄には、通知対象ユーザが利用する端末装置からの応答内容（更新／棄却／保留）が設定される。
【００７４】
処理の欄には、応答内容が更新または棄却の場合、および通知先に対する新たな管理情報が作成されたときに「済」が設定される。
図１０は、ルールテーブルを示す図である。
【００７５】
ルールテーブル２３ａには、検出対象（該当対象）、通知判別対象、通知対象ユーザ、通知対象データおよび付加情報の欄が設けられており、各欄の横方向に並べられた情報同士が互いに関連づけられている。このルールテーブル２３ａには、変更データを受信したときに適用すべきルール２３０ａが定義されている。
【００７６】
検出対象の欄には、変更検出部２４の検出対象となるフィードに関する情報、例えば「フィード追加の変更データ」、「フィード編集の変更データ」、「フィード削除の変更データ」等が設定される。
【００７７】
通知判別対象の欄には、通知判別部２５の判別基準に関する情報、例えば「変更データの新フィードＵＲＬが、同一のホームＵＲＬを指定するフィードＵＲＬの中で未知のものだった場合」等が設定される。
【００７８】
通知対象ユーザの欄には、通知対象となるユーザの種類、例えば「変更データと同じホームＵＲＬを持つフィードＵＲＬを登録している全ユーザ」等が設定される。
通知対象データの欄には、通知対象となるユーザに送信するデータ、例えば「通知対象ユーザが現在登録している旧フィードＵＲＬと新たに発見された（変更データの）新フィードＵＲＬ」等が設定される。
【００７９】
付加情報の欄には、通知対象データとともに送信する情報、例えば「発見者のユーザＩＤ」等が設定される。
付加情報としては、他にも様々なものが考えられる。サーバで取れる各種のログ情報を利用したユーザ全体の利用状況の統計情報や、ユーザ自身が登録しているプロファイル情報（例えば興味のあるキーワードや信頼するユーザのユーザＩＤ等）との関連ポイント、また、外部のインターネットサービスやメール等から得られる情報（旬のキーワード）等、ＵＲＬ変更に関してユーザの判断に参考になりそうな情報ならば、なんでもよい。
【００８０】
次に、情報管理システムにおけるサーバ２０の動作を説明する。
なお、以下では端末装置４０ａが送信した変更データをサーバ２０が受信し、通知対象ユーザが端末装置４０ｂを利用している場合の動作について説明する。
【００８１】
図１１は、サーバの動作を示すフローチャートである。
まず、変更検出部２４が、検出処理を行う（ステップＳ１）。
次に、通知判別部２５が、判別処理を行う（ステップＳ２）。
【００８２】
次に、通知情報選択部２６が、データ作成処理を行う（ステップＳ３）。
次に、ウィンドウ情報作成部２７が、データ送信処理を行う（ステップＳ４）。
次に、応答管理部２８が、端末装置４０ｂからの応答情報を受信したか否かを判断する（ステップＳ５）。端末装置４０ｂからの応答情報を受信していない場合（ステップＳ５のＮｏ）、応答情報を待機する。端末装置４０ｂからの応答情報を受信した場合（ステップＳ５のＹｅｓ）、応答管理部２８が、応答反映処理を行う（ステップＳ６）。以上で、サーバ２０の動作を終了する。なお、図１１のフローチャートは、各処理が途中で終了しない場合の処理を示しており、処理が途中で終了する場合等については、以下の各処理の説明の中で詳述する。
【００８３】
次に、変更検出部２４が行う検出処理について説明する。
図１２は、検出処理を示すフローチャートである。
まず、端末装置４０ａからの変更データを受信する（ステップＳ１１）。
【００８４】
次に、変更データに基づいて、フィードリスト２１ａの該当するユーザＩＤのリストを書き換える（ステップＳ１２）。例えば図８に新たに図７の変更データを追加する場合は、図８の最後部に＜ｏｕｔｌｉｎｅ  ｔｅｘｔ＝”Ａニュース”ｔｉｔｌｅ＝”Ａニュース”ｘｍｌＵｒｌ＝”ｈｔｔｐ：／／ａ−ｎｅｗｓ．ｊｐ／ｎｅｗｓ．ｒｓｓ”ｈｔｍｌＵｒｌ＝”ｈｔｔｐ：／／ａ−ｎｅｗｓ．ｊｐ／ｉｎｄｅｘ．ｈｔｍｌ＞を追加する。
【００８５】
次に、ルールテーブル２３ａの検出対象の欄を参照し、変更データが検出対象に一致するか否かを判断する（ステップＳ１３）。
変更データが検出対象に一致しない場合（ステップＳ１３のＮｏ）、動作を終了する。例えば図１０に示すルールテーブルのみが格納されている場合に、変更データのパラメータの欄に「編集」または「削除」が設定されている場合は、動作を終了する。
【００８６】
一方、変更データが検出対象に一致する場合（ステップＳ１３のＹｅｓ）、変更データを通知判別部２５に渡す（ステップＳ１４）。例えば図１０に示すルールテーブルが格納されている場合に、変更データのパラメータの欄に「追加」が設定されている場合はこの変更データを通知判別部２５に渡す。以上で検出処理を終了する。
【００８７】
次に、通知判別部２５が行う判別処理について説明する。
図１３は、判別処理を示すフローチャートである。
例えば図１０に示すルールテーブル２３ａの通知判別対象は、「変更データの新フィードＵＲＬが、同一のホームＵＲＬを指定するフィードとして未知のものだった場合」であるため、まず、変更データのホームＵＲＬ、フィードＵＲＬおよびユーザＩＤを抽出し、変更データのホームＵＲＬ「ｈｔｔｐ：／／ａ−ｎｅｗｓ．ｊｐ／ｉｎｄｅｘ．ｈｔｍｌ」をフィードリスト２１ａに備えるすべてのユーザのユーザＩＤと対応するフィードＵＲＬとを抽出して、通知対象ユーザデータを作成する（ステップＳ２１）。
【００８８】
図１４は、通知対象ユーザデータを示す図である。
通知対象ユーザデータ２５ａには、Ｎｏ．、タイトル、ホームＵＲＬ、フィードＵＲＬおよびユーザＩＤの欄が設けられており、各欄の横方向に並べられた情報同士が互いに関連づけられている。
【００８９】
Ｎｏ．の欄には、処理の順番を識別する番号が設定される。
タイトル、ホームＵＲＬ、フィードＵＲＬの欄には、それぞれ各ユーザのフィードリスト２１ａから抽出したタイトル、ホームＵＲＬ、フィードＵＲＬが記録される。
【００９０】
ユーザＩＤの欄には、ユーザＩＤが記録される。
再び図１３に戻って説明する。
次に、通知条件を満たしているかを判断する（ステップＳ２２）。作成した通知対象ユーザデータ２５ａ内に、変更データのフィードＵＲＬ「ｈｔｔｐ：／／ａ−ｎｅｗｓ．ｊｐ／ｎｅｗｓ．ｒｓｓ」と同じものが（変更データのユーザＩＤ「ｋａｗａｆｕｊｉ」以外のユーザＩＤのデータで）存在するか否かを判断する。
【００９１】
通知条件を満たさない場合（ステップＳ２２のＮｏ）、サーバ２０の動作を終了する。一方、通知条件を満たす場合（ステップＳ２２のＹｅｓ）、例えばホームＵＲＬ「ｈｔｔｐ：／／ａ−ｎｅｗｓ．ｊｐ／ｉｎｄｅｘ．ｈｔｍｌ」に対する既知のフィードＵＲＬはこれまで「ｈｔｔｐ：／／ｈｔｍｌ２ｒｓｓ．ｊｐ／ＲＳＳ．ｊｓｐ？ｕｒｌ=ｈｔｔｐ：／／ａ−ｎｅｗｓ．ｊｐ／ｉｎｄｅｘ．ｈｔｍｌ」だけであり、変更データのフィードＵＲＬ「ｈｔｔｐ：／／ａ−ｎｅｗｓ．ｊｐ／ｎｅｗｓ．ｒｓｓ」は初めて出現したＵＲＬであることがわかった場合、通知対象ユーザデータを通知情報選択部２６に渡す（ステップＳ２３）。以上で判別処理を終了する。
【００９２】
次に、通知情報選択部２６が行うデータ作成処理について説明する。
図１５は、データ作成処理を示すフローチャートである。
まず、ルールテーブル２３ａの通知対象ユーザの欄を参照し、ユーザを選択する（ステップＳ３１）例えば図１０に示すルールテーブル２３ａの通知対象ユーザは、「変更データと同じホームのフィードを登録している全ユーザ」であるため、図１４に示す通知対象ユーザデータでは、ユーザＩＤ「ｋｅｒｏｒｏｎ」を有するユーザと、ユーザＩＤ「ｔａｓｃａｌ」を有するユーザを選択する。
【００９３】
次に、変更履歴管理テーブル２２ａに選択したユーザのユーザＩＤを格納する（ステップＳ３２）。
次に、通知対象ユーザデータ２５ａの内容を変更履歴管理テーブル２２ａの通知情報の欄に反映させる（ステップＳ３３）。また、付加情報の欄には、図１０に示すルールテーブル２３ａの付加情報が「発見者のユーザＩＤ」であるため、「発見者のユーザＩＤ＝ｋａｗａｆｕｊｉ」を格納する（ステップＳ３４）。以上でデータ作成処理を終了する。
【００９４】
次に、ウィンドウ情報作成部２７が行うデータ送信処理について説明する。
図１６は、データ送信処理を示すフローチャートである。
まず、変更履歴管理テーブル２２ａを参照し、通知対象ユーザ毎に、旧タイトル、旧ホームＵＲＬ、旧フィードＵＲＬ、新タイトル、新ホームＵＲＬ、新フィードＵＲＬ、付加情報を有する通知情報を作成する（ステップＳ４１）。
【００９５】
次に、ステップＳ４１で作成した情報を表示するウィンドウ情報を作成する（ステップＳ４２）。
そして、端末装置４０ｂ（通知対象ユーザが利用している各端末装置）への送信タイミングを見計らい、ウィンドウ情報を送信する（ステップＳ４３）。この送信タイミングについては特に限定されないが、例えば端末装置４０ｂがフィードリーダを起動している場合は即座に送信する。また、端末装置４０ｂがフィードリーダを起動していない場合は、フィードリーダの起動時に送信する。以上でデータ送信処理を終了する。
【００９６】
アプリケーション実行部４４ｂがウィンドウ情報を受け取ると、端末装置４０ｂが備えるモニタに通知情報を表示するための更新通知ウィンドウを表示させる。
図１７は、更新通知ウィンドウを示す図である。
【００９７】
更新通知ウィンドウ５１は、コメント表示部５２と、現在のプロパティ情報表示部５３と、更新情報表示部５４と、更新ボタン５５と、棄却ボタン５６と、保留ボタン５７とを有している。
【００９８】
コメント表示部５２には、付加情報の内容が表示される。図１７では、発見者のユーザＩＤが所定の文章とともに表示されている。このとき、ユーザＩＤは、リンク表示になっていて、ユーザがマウス等を用いてそのリンクをクリックすると、端末装置４０ｂが、サーバ２０のユーザプロファイルＤＢ（図示せず）にアクセスし、そのユーザのプロファイル情報を参照するようになっていてもよい。
【００９９】
現在のプロパティ情報表示部５３には、現在（変更前）のタイトル、ホームＵＲＬおよびフィードＵＲＬが表示される。また、更新情報表示部５４には、変更後のタイトル、ホームＵＲＬおよびフィードＵＲＬが表示される。これらのうちの変更対象となった部分（図１７では一例としてフィードＵＲＬという文字部分）は、色彩やフォントの大きさ等が変化して表示されており、ユーザへの報知性を高めている。
【０１００】
現在のプロパティ情報表示部５３および更新情報表示部５４の各タイトル、ホームＵＲＬおよびフィードＵＲＬは、それぞれリンク表示になっていて、ユーザがマウス等を用いてそのリンクをクリックすると、リンク先にアクセスし、リンクに関連づけられた情報、例えばホームＵＲＬであればリンク先のホームＵＲＬを表示するよう構成されている。
【０１０１】
ユーザは、現在のプロパティ情報表示部５３に表示された情報を更新情報表示部５４に表示された情報に更新する場合には、更新ボタン５５を押下する。また、現在のプロパティ情報表示部５３に表示された情報を更新情報表示部５４に表示された情報に変更しない場合には、棄却ボタン５６を押下する。また、決定を保留する場合には、保留ボタン５７を押下する。これら各ボタンのうちのいずれかが押下されることにより、アプリケーション実行部４４ｂが、更新、棄却または保留のうちのいずれか１つの応答種別を含む応答情報を応答情報送信部４３ｂに送る。
【０１０２】
ここで、保留ボタンが押下された場合、再通知条件が応答情報に付加される。再通知条件は１つでも複数でもよく、その中から１つまたは複数を選択することができる。なお、複数の場合にはボタンをプルダウンメニュー方式とし、その中から選択するようにしてもよい。
【０１０３】
なお、本実施の形態では、３つの選択肢（更新／棄却／保留）を設けたが、これに限らず、他の選択肢を設けてもよい。
次に、応答管理部２８が行う応答反映処理について説明する。
【０１０４】
図１８は、応答反映処理を示すフローチャートである。
まず、応答情報送信部４３ｂから応答情報を受信すると、その応答情報の応答種別を特定する。すなわち、応答種別が更新か棄却か保留かを判断する（ステップＳ５１）。
【０１０５】
応答種別が更新である場合（ステップＳ５１の更新）、フィードリスト２１ａを更新する（ステップＳ５２）。そして、変更履歴管理テーブル２２ａの反応日時、反応、処理の欄にそれぞれ必要事項を記録する（ステップＳ５３）。
【０１０６】
応答種別が棄却である場合（ステップＳ５１の棄却）、フィードリスト２１ａを更新することなく変更履歴管理テーブル２２ａの反応日時、反応、処理の欄にそれぞれ必要事項を記録する（ステップＳ５４）。
【０１０７】
応答種別が保留である場合（ステップＳ５１の保留）、変更履歴管理テーブル２２ａの反応日時、反応の欄にそれぞれ必要事項を記録（ステップＳ５５）。再通知用データを保持して、次に、再通知処理を行う（ステップＳ５６）。
【０１０８】
以上で、応答反映処理を終了する。
次に、再通知処理について説明する。
図１９は、再通知処理を示すフローチャートである。
【０１０９】
まず、応答管理部２８が、再通知の条件が設定された再通知ルールテーブルを参照して、変更履歴管理テーブル２２ａを監視し、再通知条件を満たしたか否かを判断する（ステップＳ６１）。再通知条件は、例えば「本変更について、通知対象ユーザの半数が通知に従い、新ＵＲＬを登録した」等、全ユーザに共通のルールでもよいし、各ユーザが個別に設定できてもかまわない。再通知条件を満たしていない場合（ステップＳ６１のＮｏ）、再通知条件を満たすまで待機する。再通知条件を満たしている場合（ステップＳ６１のＹｅｓ）、応答管理部２８が、フィードリスト２１ａの再通知対象ユーザのリストをチェックして、変更前のフィードＵＲＬが変更されているか否かを判断する（ステップＳ６２）。変更前のフィードＵＲＬが変更されている場合（ステップＳ６２のＹｅｓ）、再通知は中止し、変更履歴管理テーブル２２ａの処理欄に「済」を埋めて（ステップＳ６２ａ）、動作を終了する。変更前のフィードＵＲＬが変更されていない場合（ステップＳ６２のＮｏ）、変更履歴管理テーブル２２ａの通知Ｎｏ．の欄を更新した新たな管理情報を作成する（ステップＳ６３）。図９に示す例では、Ｎｏ．１の通知が保留され、Ｎｏ．６がその再通知である。通知Ｎｏ．は、同一のＵＲＬの通知の２回目の通知であるため、前回の通知Ｎｏ「１−０」に対して、再通知は「１−１」となっている。Ｎｏ．１の処理の欄は、Ｎｏ．６の再通知を作成した時点で「済」が格納される。
【０１１０】
その後、通知情報をウィンドウ情報作成部２７に渡す（ステップＳ６４）。
以上で再通知処理を終了する。
次に再通知ルールテーブルについて説明する。
【０１１１】
再通知ルールテーブル２３ｂには、再通知条件、再通知内容、付加情報の欄が設けられている。設定される内容については、ルールテーブル２３ａと同様であるのでその説明を省略する。なお、再通知ルールは、全通知で共通でもよく、各ユーザが通知ごとに指定できてもかまわない。
【０１１２】
次に、前述した各処理について具体例を用いて説明する。
本例は、従来公式フィードがなく、各ユーザが自動生成フィードを登録して利用していた「Ａニュース」というＷｅｂページにおいて、公式フィードの配信が開始され、ユーザＩＤ「ｋａｗａｆｕｊｉ」のユーザが、公式フィードを発見し登録した場合の例である。この発見に基づき、自動生成フィードを利用していた他のユーザに、公式フィードの存在が通知される。
【０１１３】
「Ａニュース」のホームＵＲＬは「ｈｔｔｐ：／／ａ−ｎｅｗｓ．ｊｐ／ｉｎｄｅｘ．ｈｔｍｌ」、自動生成フィードのフィードＵＲＬは「ｈｔｔｐ：／／ｈｔｍｌ２ｒｓｓ．ｊｐ／ＲＳＳ．ｊｓｐ？ｕｒｌ=ｈｔｔｐ：／／ａ−ｎｅｗｓ．ｊｐ／ｉｎｄｅｘ．ｈｔｍｌ」、公式フィードのフィードＵＲＬは「ｈｔｔｐ：／／ａ−ｎｅｗｓ．ｊｐ／ｎｅｗｓ．ｒｓｓ」であるとする。また、ルールテーブルは、図１０のルールテーブル２３０ａのとおりに設定されているものとする。
【０１１４】
ユーザＩＤ「ｋａｗａｆｕｊｉ」のユーザがサーバ２０に送信する今回の変更データは、図７に示す変更データ３１１ａのとおりとなる。
次に、本具体例の動作を説明する。
【０１１５】
端末装置４０ａを操作して追加した場合に、変更通知部４１ａが図７に示した変更データ３１１ａをサーバ２０に送信したときのサーバ２０の動作について説明する。
変更検出部２４が、端末装置４０ａからの変更データを受信すると、ユーザＩＤ「ｋａｗａｆｕｊｉ」のフィードリストを書き換える。
【０１１６】
図２０は、具体例のフィードリストを示す図である。
フィードリスト２１ａには、変更データに基づいて下線部２１１ｂが追記されている。
次に、変更検出部２４が、変更データがルール２３１ａに則した変更か否かを判断する。本具体例では、ルール２３０ａに則した変更であるため、変更データを通知判別部２５に渡す。
【０１１７】
そして、通知判別部２５が、ルール２３０ａを参照して変更データとフィードリスト２１ａとからホームＵＲＬ「ｈｔｔｐ：／／ａ−ｎｅｗｓ．ｊｐ／ｉｎｄｅｘ．ｈｔｍｌ」の通知対象ユーザデータを作成する。以下、図１４に示す通知対象ユーザデータ２５ａが作成されたものとして説明する。
【０１１８】
次に、通知判別部２５が、通知対象ユーザデータ２５ａ内に、変更データのフィードＵＲＬ「ｈｔｔｐ：／／ａ−ｎｅｗｓ．ｊｐ／ｎｅｗｓ．ｒｓｓ」が既出であるか否かを判断する。本具体例では、「ｈｔｔｐ：／／ａ−ｎｅｗｓ．ｊｐ／ｎｅｗｓ．ｒｓｓ」は既出ではないため、通知情報選択部２６に通知対象ユーザデータ２５ａを渡す。
【０１１９】
次に、通知情報選択部２６が、ルール２３０ａを参照してユーザＩＤ「ｋａｗａｆｕｊｉ」以外の全ユーザを選択し、変更履歴管理テーブル２２ａの通知情報の欄に、通知対象ユーザデータ２５ａの情報を記録する。
【０１２０】
図２１は、データ作成処理終了時の変更履歴管理テーブルを示す図である。
変更履歴管理テーブル２２ａの通知先（ユーザＩＤ）の欄、および通知情報の欄には、図９に示す内容が記録される。
【０１２１】
その後、ウィンドウ情報作成部２７がウィンドウ情報を作成し、送信する。
そして、応答管理部２８が、通知対象ユーザが利用する端末装置からの応答情報を受信する度に、応答種別（更新、棄却、保留）を判断し、前述した処理を行う。
【０１２２】
図２２は、応答情報を受信したときの変更履歴管理テーブルを示す図である。
ユーザＩＤ「ｔａｓｃａｌ」のユーザは、更新を選択しているので、処理が終了している。
【０１２３】
ユーザＩＤ「ｋｅｒｏｒｏｎ」のユーザは、保留を選択しているので、応答管理部２８は、再通知ルールテーブルを参照して、変更履歴管理テーブル２２ａを監視する。
図２３は、再通知ルールテーブルを示す図である。
【０１２４】
再通知ルールテーブル２３ｂによれば、再通知条件は、「通知情報をもとに更新したユーザが過半数」である。再通知の内容は、前回と同じＵＲＬ変更の通知情報に、付加情報として何人中何人が更新したかの情報を付加する。
【０１２５】
その後、応答管理部２８が、変更履歴管理テーブル２２ａの通知対象ユーザのうちの過半数のユーザの反応の欄が更新になったと判断すると、ユーザＩＤ「ｋｅｒｏｒｏｎ」の現在のフィードリストをチェックし、旧フィードＵＲＬ「ｈｔｔｐ：／／ｈｔｍｌ２ｒｓｓ．ｊｐ／ＲＳＳ．ｊｓｐ？ｕｒｌ=ｈｔｔｐ：／／ａ−ｎｅｗｓ．ｊｐ／ｉｎｄｅｘ．ｈｔｍｌ」と同一のままであることを確認した後、変更履歴管理テーブル２２ａに、ユーザＩＤ「ｋｅｒｏｒｏｎ」の通知Ｎｏ．「１−１」の新たな管理情報を作成し、付加情報の欄には、「更新人数＝３８人／５０人」を記録する。また、Ｎｏ．「１」（前回の通知Ｎｏ．「１−０」）の管理情報の処理の欄には「済」を記入する。
【０１２６】
その後、前回、ユーザＩＤ「ｋｅｒｏｒｏｎ」に通知した通知情報に、再通知条件を満たした旨の付加情報（例えば「再通知：このフィードＵＲＬを５０人中３８人が更新しました」等）を付加したウィンドウ情報をユーザＩＤ「ｋｅｒｏｒｏｎ」のユーザが利用している端末装置に送信する。
【０１２７】
図２４は、再通知処理実行後の変更履歴管理テーブルを示す図である。
その後、ユーザＩＤ「ｋｅｒｏｒｏｎ」の端末装置から応答があった場合、応答反応処理を継続して行う。
【０１２８】
全てのユーザの処理の欄が「済」になった場合は、動作を終了する。
図２５は、再通知処理終了後の変更履歴管理テーブルを示す図である。
以上説明したように、本実施の形態の情報管理システムによれば、あるユーザのフィードＵＲＬの変更が他のユーザが利用する端末装置に通知される。これにより、ユーザ間で、フィードＵＲＬの変更の情報を共有することができ、ユーザは自分にとって未知のフィードの存在も容易に知ることができる。人手による変更に基づくため、従来の自動検出手法に比べ、信頼性も高い。また、従来手法では、サーバによりフィードＵＲＬの変更を自動検出する場合、リンク切れではなく機能しているフィードを対象とすることは難しいが、本実施の形態では、あるＷｅｂページに対するフィードがすでにフィードリストに登録されており、そのフィードが機能している場合であっても、ユーザは、そのフィードについての新しいフィードＵＲＬを容易に知ることができる。よって、自動生成フィードから公式フィードへの乗り換え等も容易に可能になる。
【０１２９】
また、このフィードＵＲＬの変更をフィードリストの各自のリストに反映させることにより、メンテナンス作業の負荷を低減させることができる。また、各ユーザがフィードＵＲＬの変更（更新、削除）をフィードリストの各自のリストに反映させる場合には、更新通知ウィンドウ５１上でボタン（更新ボタン５５、棄却ボタン５６）を押下するだけでよいので、容易にフィードリストの更新を行うことができる。
【０１３０】
また、ルールテーブル２３ａを設け、ルールに適合する情報を通知対象の情報とすることで、ユーザは、多くの変更の中から自分に必要な変更の情報のみを受け取ることができる。また、ユーザ毎にルールを別途設定して、変更検出部２４の検出対象とさせることで、例えばユーザが所望した特定の（スキルの高い）ユーザからのフィードＵＲＬの変更の場合のみ、フィードＵＲＬの変更の情報を受け取る等、ユーザ毎の詳細なカスタマイズをすることもできる。
【０１３１】
また、同じＷｅｂページに対し複数のフィードが存在している場合、ユーザ全体でのフィードの登録状況や変更通知の受理率等、一人の判断ではなく大勢の判断を利用することで、「より利用されているフィードが質の良いフィード」といったフィードの質の判定を行うことができる。
【０１３２】
さらに、ユーザに通知するウィンドウ情報に、ユーザ全体の利用状況等の付加情報を付加することにより、ユーザは通知されたフィードＵＲＬの更新が必要か否かをより容易に判断することができる。例えば、本実施の形態のように、情報の発信源であるユーザＩＤ等の情報を付加することにより、通知情報の信頼性が向上し、更新を促進させることができる。
【０１３３】
また、本実施の形態は、ユーザリストがフィードリストの場合について説明したが、本情報管理システムはブックマークにも適用することができる。
図２６は、第１の実施の形態の情報管理システムをブックマークに適用した場合の変更データを示す図である。
【０１３４】
ブックマークの変更データ５１１ａは、変更前、変更後ともにフィードＵＲＬの欄には「ｎｕｌｌ」が設定される。
図２７は、第１の実施の形態の情報管理システムをブックマークに適用した場合のルールテーブルを示す図である。
【０１３５】
ブックマークのルールテーブル２３ｃの検出対象の欄には、変更検出部２４の検出対象となるブックマークに関する情報、例えば「ブックマークに追加の変更データ」、「ブックマーク変更の変更データ」、「ブックマーク削除の変更データ」等が設定される。
【０１３６】
通知判別対象の欄には、通知判別部２５の判別基準に関する情報、例えば「同じタイトルに対するホームＵＲＬとして未知」等が設定される。
通知対象ユーザの欄には、通知対象となるユーザの種類、例えば「同じタイトルのブックマークを登録している全ユーザ」等が設定される。
【０１３７】
このような変更データ５１１ａ、ルールテーブル２３ｃを本実施の形態の情報管理システムに適用することで、前述した効果と同様の効果が得られる。
次に、第２の実施の形態の情報管理システムについて説明する。前述した第１の実施の形態との相違点を中心とし、同様の事項については、説明を省略する。
【０１３８】
第２の実施の形態の情報管理システムは、ユーザがあるフィードＵＲＬからあるフィードＵＲＬへ明示的な変更を行ったプロパティの「編集」（プロパティ編集画面上でのフィードＵＲＬ変更）を検知の対象とする。そして、あるフィードＵＲＬからあるフィードＵＲＬへの編集を行った人数が所定人数以上になった場合に、他のユーザに対して通知情報を送信する点が第１の実施の形態と異なっている。
【０１３９】
以下では、「２００５年度新着ページ」の自動生成フィードを登録していたが、年度が変わって「２００６年度新着ページ」の自動生成フィードに登録し直す必要があり、あるユーザがその編集作業を行った場合を例にとって説明する。
【０１４０】
図２８は、第２の実施の形態のサーバを示すブロック図である。
第２の実施の形態のサーバ２０ａは、あるホームＵＲＬに対してフィードＵＲＬの変更を行った人数をカウントする人数カウンタテーブルが格納されているカウンタ管理ＤＢ２９を有している。
【０１４１】
図２９は、人数カウンタテーブルを示す図である。
人数カウンタテーブル２９ａには、変更前フィード、変更後フィードおよびカウンタの欄が設けられている。
【０１４２】
変更前フィードの欄には、変更データの変更前のフィードＵＲＬの欄のＵＲＬ（図２９では「ｈｔｔｐ：／／ｈｔｍｌ２ｒｓｓ．ｊｐ／ＲＳＳ．ｊｓｐ？ｕｒｌ＝ｈｔｔｐ：／／・・・／ｎｅｗｓ／２００５」）が記録される。
【０１４３】
変更後フィードの欄には、変更データの変更後のフィードＵＲＬの欄のＵＲＬ（図２９では「ｈｔｔｐ：／／ｈｔｍｌ２ｒｓｓ．ｊｐ／ＲＳＳ．ｊｓｐ？ｕｒｌ＝ｈｔｔｐ：／／・・・／ｎｅｗｓ／２００６」）が記録される。
【０１４４】
カウンタの欄には、変更前フィードの欄に設定されているフィードＵＲＬから変更後フィードの欄に設定されているフィードＵＲＬに変更を行ったユーザの人数（カウンタ値）が設定される。
【０１４５】
図３０は、第２の実施の形態のルールテーブルを示す図である。
ルールテーブル２３ａには、ルール２３２ａが定義されている。
ルール２３２ａの検出対象の欄には、「フィード編集の変更データ」というルールが定義されている。
【０１４６】
ルール２３２ａの通知判別対象の欄には、「同じフィードＵＲＬ編集を行った人数が１５人を超えたら」というルールが定義されている。これにより、通知判別部２５は、同一のフィード編集の変更データの受信数が１５人（所定人数）を超えたか否かを通知判別の対象とする。
【０１４７】
ルール２３２ａの通知対象ユーザの欄には、「旧フィードＵＲＬを登録している全ユーザ」というルールが定義されている。これにより、通知情報選択部２６は、変更データに含まれる旧フィードＵＲＬを各自のフィードリスト２１ａに登録している全ユーザを通知情報の通知先とする。
【０１４８】
ルール２３２ａの通知対象データの欄には、「新旧のフィードＵＲＬ」というルールが定義されている。これにより、通知情報選択部２６は、新旧のフィードＵＲＬを通知情報の内容とする。
【０１４９】
ルール２３２ａの付加情報の欄には、「編集したユーザの人数」というルールが定義されている。これにより、通知情報選択部２６は、「編集者が１５人を超えました」という付加情報を作成する。
【０１５０】
次に、第２の実施の形態の情報管理システムの動作について説明する。
まず、変更検出部２４ａが、端末装置４０ａからの変更データを受信すると、ルール２３２ａに則した変更か否か、すなわち編集の変更データか否かを判断する。
【０１５１】
図３１は、変更データの具体例を示す図である。
変更データは、旧フィードＵＲＬ「ｈｔｔｐ：／／ｈｔｍｌ２ｒｓｓ．ｊｐ／ＲＳＳ．ＪＳＰ？ｕｒｌ＝ｈｔｔｐ：／／・・・／ｎｅｗｓ／２００５」から新フィードＵＲＬ「ｈｔｔｐ：／／ｈｔｍｌ２ｒｓｓ．ｊｐ／ＲＳＳ．ＪＳＰ？ｕｒｌ＝ｈｔｔｐ：／／・・・／ｎｅｗｓ／２００６」への編集であり、該当する変更である。
【０１５２】
そこで、変更データに基づいてフィードリスト２１ａの、変更データを送信したユーザのリストを書き換える。
次に、通知判別部２５が、人数カウンタテーブル２９ａのカウンタ値をインクリメントする。その後、カウンタ値をカウントし、カウンタ値が１５より大きくなると、通知情報選択部２６に通知対象ユーザデータを渡す。
【０１５３】
通知情報選択部２６は、通知対象ユーザデータを参照し、フィードＵＲＬ「ｈｔｔｐ：／／ｈｔｍｌ２ｒｓｓ．ｊｐ／ＲＳＳ．ｊｓｐ？ｕｒｌ＝ｈｔｔｐ：／／・・・／ｎｅｗｓ／２００５」を登録している通知者以外の全ユーザを選択する。そして、新旧のフィードＵＲＬを有する通知情報と、「編集者が１５人を超えました」という付加情報とを有するウィンドウ情報を作成し、該当するユーザが利用している端末装置に送信する。
【０１５４】
この第２の実施の形態の情報管理システムによれば、第１の実施の形態の情報管理システムと同様の効果が得られる。２００６年度になり、２００５年度のページから自動生成しているフィードが機能しなくなっても、あるユーザの気づきが他ユーザとの間で共有され、全ユーザが２００６年度のフィードに置き換えることができる。人手による変更に基づくため、従来の自動検出手法に比べ、変更のカバー範囲も広い。
【０１５５】
次に、第３の実施の形態の情報管理システムについて説明する。前述した第１の実施の形態との相違点を中心とし、同様の事項については、その説明を省略する。
第３の実施の形態の情報管理システムは、サーバがフィードＵＲＬのリンク切れ等を検出した場合、新たなフィードＵＲＬの発見を優良ユーザに依頼し、その結果を他のユーザに通知する点が第１の実施の形態と異なっている。
【０１５６】
図３２は、第３の実施の形態のサーバを示すブロック図である。
第３の実施の形態のサーバ２０ｂは、リンク切れ検出部３０と、優良ユーザランキング計算部３１と、代替フィード調査依頼部３２と、ユーザプロファイルテーブルが格納されたユーザプロファイル管理ＤＢ３３とを有している。
【０１５７】
リンク切れ検出部３０は、フィードリスト２１ａの各ユーザのリストを定期的にチェックし、リンク切れの有無を検出する。
優良ユーザランキング計算部３１は、フィードリストのメンテナンス作業に長けた優良ユーザのランキングを定期的に計算し、ユーザプロファイルテーブルに格納する。ランキングは、例えばユーザＩＤ毎のウィンドウ情報の受理率（そのユーザの発見により他のユーザに通知されたウィンドウ数のうち、「更新」の応答情報を返された割合）で計算する。受理率の計算に必要な情報は、変更履歴管理テーブル２２ａから得ることができる。
【０１５８】
代替フィード調査依頼部３２は、受理率に基づいて、代替フィードの調査を依頼するユーザＩＤを特定し、代替フィードの調査を依頼する。具体的には、受理率が最も高いユーザを検索し、そのユーザＩＤのユーザが利用する端末装置に代替フィードの調査を依頼する依頼情報を送信する。ユーザが見つからなければ次に受理率が高いユーザを検索し、そのユーザに代替フィードの調査を依頼する。以下依頼するユーザが見つかるまで同様の動作を繰り返す。
【０１５９】
図３３は、ユーザプロファイルテーブルを示す図である。
ユーザプロファイルテーブル３３ａには、ユーザＮｏ．、通知先（ユーザＩＤ）、パスワード、氏名、メールアドレス、および優良ユーザランキングの欄が設けられており、各欄の横方向に並べられた情報同士が互いに関連づけられている。
【０１６０】
ユーザＮｏ．の欄には、ユーザプロファイルテーブル３３ａに登録された順番を識別する番号が設定される。
ユーザＩＤの欄には、ユーザＩＤが設定される。
【０１６１】
パスワードの欄には、ユーザＩＤ毎のパスワードが設定される。
氏名の欄には、ユーザＩＤを使用するユーザの氏名が設定される。
メールアドレスの欄には、ユーザ毎のメールアドレスが設定される。
【０１６２】
優良ユーザランキングの欄には、受理率の高い順番に順位が記録される。
図３４は、第３の実施の形態のルールテーブルを示す図である。
ルールテーブル２３ａには、ルール２３３ａが定義されている。
【０１６３】
ルール２３３ａの検出対象の欄には、「リンク切れ発見依頼に対する応答」というルールが定義されている。これにより、変更検出部２４は、代替フィード調査依頼部３２が依頼したユーザが利用する端末装置から送信される変更データのパラメータ欄が「発見依頼に対する応答」のものを検出対象とする。
【０１６４】
ルール２３３ａの通知判別対象の欄には、「代替フィードの発見」というルールが定義されている。これにより、通知判別部２５は、依頼したユーザからの応答の変更データに新フィードＵＲＬ欄の記載があるか、そのリンクに接続可能であるかを判別対象とする。
【０１６５】
ルール２３３ａの通知対象ユーザの欄には、「リンク切れしている旧フィードＵＲＬを登録している全ユーザ」というルールが定義されている。これにより、通知情報選択部２６は、旧フィードＵＲＬを登録している全てのユーザを選択対象とする。
【０１６６】
ルール２３３ａの通知対象データの欄には、「新旧のフィードＵＲＬ」というルールが定義されている。これにより、通知情報選択部２６は、新旧のフィードＵＲＬを通知情報の内容とする。
【０１６７】
ルール２３３ａの付加情報の欄には、「発見者のユーザＩＤと優良ユーザランキングの順位」というルールが定義されている。これにより、通知情報選択部２６は、代替フィード調査依頼部３２が依頼したユーザのユーザＩＤと、ユーザプロファイルテーブル３３ａの優良ユーザランキングの欄に記録されたランキングを挿入した付加情報を作成する。
【０１６８】
次に、第３の実施の形態の情報管理システムの動作について説明する。
まず、リンク切れ検出部３０が、全ユーザのフィードリスト２１ａ内のＵＲＬに定期的にアクセスし、リンク切れしたＵＲＬを検出する。ここでは、ｈｔｔｐ：／／ａ．ｒｓｓのリンク切れを発見したとする。
【０１６９】
次に、優良ユーザランキング計算部３１が、受理率を定期的に計算し、ユーザプロファイルテーブル３３ａに格納する。
次に、代替フィード調査依頼部３２が、受理率に基づいて代替フィードの調査を依頼するユーザが利用する端末装置を特定し、代替フィードの調査を依頼する。
【０１７０】
その後、変更検出部２４が、代替フィードの調査を依頼したユーザが利用する端末装置からの変更データを受信すると、ルール２３３ａに則した変更か否か、すなわちフィードＵＲＬ「ｈｔｔｐ：／／ａ．ｒｓｓ」のリンク切れ発見依頼に対する応答か否かを判断する。
【０１７１】
図３５は、変更データの具体例を示す図である。
この場合、フィードＵＲＬ「ｈｔｔｐ：／／ａ．ｒｓｓ」のリンク切れ発見依頼に対する応答であるので、変更データに基づいてフィードリスト２１ａの調査を依頼したユーザのリストを書き換える。
【０１７２】
次に、通知判別部２５が、変更データに代替の新フィードＵＲＬが含まれているか否かを判断する。この場合、代替フィードＵＲＬ「ｈｔｔｐ：／／ｂ．ｒｓｓ」が含まれているので、「ｈｔｔｐ：／／ｂ．ｒｓｓ」に接続できることを確認後、通知情報選択部２６に通知対象ユーザデータを渡す。
【０１７３】
通知情報選択部２６は、フィードＵＲＬ「ｈｔｔｐ：／／ａ．ｒｓｓ」を登録している全ユーザＩＤを選択する。
そして、ウィンドウ情報作成部２７が、フィードＵＲＬ「ｈｔｔｐ：／／ａ．ｒｓｓ」がリンク切れしており代替ＵＲＬとして「ｈｔｔｐ：／／ｂ．ｒｓｓ」があることと、付加情報として優良ユーザランキング１位のユーザ「ｋａｗａｆｕｊｉ」による発見であることを通知するウィンドウ情報を、該当するユーザの端末装置に送信する。
【０１７４】
この第３の実施の形態の情報管理システムによれば、第１の実施の形態の情報管理システムと同様の効果が得られる。フィードＵＲＬのリンク切れにユーザが気づかなくとも、システムの発見に基づき、フィードリストのメンテナンスに長けた優良ユーザにリンク切れを通知することができ、その優良ユーザがメンテナンスした結果を初心者のユーザも共有することができる。
【０１７５】
次に、第４の実施の形態の情報管理システムについて説明する。前述した第１の実施の形態との相違点を中心とし、同様の事項については、その説明を省略する。
第４の実施の形態の情報管理システムは、あるユーザがフィードＵＲＬを追加したときに、各ユーザの利用状況に基づき、他によりよいフィードＵＲＬがあれば、追加したユーザに通知する点が第１の実施の形態と異なっている。
【０１７６】
図３６は、第４の実施の形態のルールテーブルを示す図である。
ルールテーブル２３ａには、新たなルール２３４ａが定義されている。
ルール２３４ａの検出対象の欄には、「フィード追加の変更データ」というルールが定義されている。これにより、変更検出部２４は、ユーザの新たなフィードＵＲＬの追加を検出対象とする。
【０１７７】
ルール２３４ａの通知判別対象の欄には、「変更データと同一のホームＵＲＬに対し、８０％以上のユーザが変更データと異なるフィードＵＲＬを登録している」というルールが定義されている。これにより、通知判別部２５は、追加されたフィードのホームＵＲＬについて、他のフィードを登録しているユーザが存在するか否か、存在する場合、そのホームＵＲＬについて、他のフィードの占める割合が一定以上か否かを判別対象とする。
【０１７８】
ルール２３４ａの通知対象ユーザの欄には、「検出元ユーザ」というルールが定義されている。これにより、通知情報選択部２６は、フィードＵＲＬを追加し変更データを送付したユーザを選択対象とする。
【０１７９】
ルール２３４ａの通知対象データの欄には、「ユーザが追加した旧フィードＵＲＬと、既存ユーザの間でよりメジャーな新フィードＵＲＬ」というルールが定義されている。また、ルール２３４ａの付加情報の欄には、「既存ユーザの間で新フィードＵＲＬを登録しているユーザの割合」というルールが定義されている。これにより、通知情報選択部２６は、例えば「フィードｈｔｔｐ：／／ａ．ｒｓｓについては、ｈｔｔｐ：／／ａｘ．ｒｓｓの方がメジャー（ユーザの８０％が利用）です。」という通知情報を作成する。
【０１８０】
次に、変更データを受け取った場合の通知判別部２５の動作について説明する。
図３７は、変更データの具体例を示す図であり、図３８は、変更データを受け取った場合の通知判別部の動作を示すフローチャートである。
【０１８１】
まず、ホームＵＲＬ「ｈｔｔｐ：／／ａａ．ｈｔｍｌ」のフィードＵＲＬとして登録している通知対象ユーザデータを作成する（ステップＳ８１）。そして、通知対象ユーザデータから、フィードＵＲＬ毎の登録者数の割合を計算する（ステップＳ８２）。そして、変更データの「ｈｔｔｐ：／／ａ．ｒｓｓ」以外のフィードＵＲＬで８０％以上のユーザが登録している別のＵＲＬがあるか否かを判断する（ステップＳ８３）。８０％以上のユーザが登録している別のフィードＵＲＬがない場合（ステップＳ８３のＮｏ）、動作を終了する。一方、８０％以上のユーザがフィードＵＲＬ「ａｘ．ｒｓｓ」をホームＵＲＬ「ｈｔｔｐ：／／ａａ．ｈｔｍｌ」のフィードとして登録している場合（ステップＳ８３のＹｅｓ）、通知情報選択部２６に通知対象ユーザデータを渡す（ステップＳ８４）。
【０１８２】
この第４の実施の形態の情報管理システムによれば、第１の実施の形態の情報管理システムと同様の効果が得られる。新規フィードの追加の際、他のユーザの利用状況を使って、より良い未知のフィードの存在をユーザにフィードバックすることができる。これにより、初心者でスキルの低いユーザでも、利用開始時から質の良いフィードを使うことができる。
【０１８３】
次に、第５の実施の形態の情報管理システムについて説明する。前述した第１の実施の形態との相違点を中心とし、同様の事項については、その説明を省略する。
第５の実施の形態の情報管理システムは、サーバが定期的にフィードリストの各ユーザのリストをチェックし、全ユーザの利用状況を加味して、利用価値の低いフィードの削除を勧める点が第１の実施の形態と異なっている。
【０１８４】
図３９は、第５の実施の形態のサーバを示すブロック図である。
第５の実施の形態のサーバ２０ｃは、各ユーザがアクセスしたフィードＵＲＬの履歴が記録されたアクセスログを保管するアクセスログ管理ＤＢ３４を有している。
【０１８５】
図４０は、アクセスログを示す図である。
アクセスログ３４ａには、ログＮｏ．、ユーザＩＤ、時間およびフィードＵＲＬの欄が設けられており、各欄の横方向に並べられた情報同士が互いに関連づけられている。
【０１８６】
ログＮｏ．の欄には、アクセスログ３４ａに登録された順番を識別する番号が設定される。
ユーザＩＤの欄には、ユーザＩＤが記録される。
【０１８７】
時間の欄には、フィードＵＲＬにアクセスした時間が記録される。
フィードＵＲＬの欄には、ユーザがアクセスしたフィードＵＲＬが記録される。
次に、第５の実施の形態の情報管理システムの動作について説明する。
【０１８８】
まず、変更検出部２４ｂが、フィードリスト２１ａとアクセスログ３４ａとを比較し、一定期間アクセスのないフィードＵＲＬを抽出する。そして、通知判別部２５は、発見したフィードＵＲＬについて、通知対象ユーザデータを作成し、各ユーザのアクセス状況もチェックする。一定期間アクセスのないユーザが一定割合以上の場合、フィードリストからの削除を勧める通知を行う。
【０１８９】
この第５の実施の形態の情報管理システムによれば、第１の実施の形態の情報管理システムと同様の効果が得られる。あるユーザ個人的にアクセスしなくなったフィードを通知することで、不要なフィードを削除してフィードリストの質を高めることが容易にできるだけでも有用だが、本実施の形態の情報管理システムでは、さらに「あるユーザだけではなく多数のユーザが利用していない」等、他のユーザの利用状況に基づいてフィードの利用価値の低さを判定することができる。
【０１９０】
以上、本発明の好適な実施の形態について詳述したが、本発明は、その特定の実施の形態に限定されるものではない。
なお、前述した各実施の形態では、フィードリスト２１ａを管理する場合について説明したが、本発明はこれに限らず、例えばブラウザのブックマークを管理する場合についても適用することができる。
【０１９１】
なお、上記の処理機能は、コンピュータによって（コンピュータに所定のリンク情報管理プログラムを実行させることにより）実現することができる。その場合、サーバが有すべき機能の処理内容を記述したプログラムが提供される。そのプログラムをコンピュータで実行することにより、上記処理機能がコンピュータ上で実現される。処理内容を記述したプログラムは、コンピュータで読み取り可能な記録媒体に記録しておくことができる。コンピュータで読み取り可能な記録媒体としては、例えば、磁気記録装置、光ディスク、光磁気記録媒体、半導体メモリ等が挙げられる。磁気記録装置としては、例えば、ハードディスク装置（ＨＤＤ）、フレキシブルディスク（ＦＤ）、磁気テープ等が挙げられる。光ディスクとしては、例えば、ＤＶＤ（Digital Versatile Disc）、ＤＶＤ−ＲＡＭ、ＣＤ−ＲＯＭ（Compact Disc Read Only Memory）、ＣＤ−Ｒ（Recordable）／ＲＷ（ReWritable）等が挙げられる。光磁気記録媒体としては、例えば、ＭＯ（Magneto-Optical disk）等が挙げられる。
【０１９２】
プログラムを流通させる場合には、例えば、そのプログラムが記録されたＤＶＤ、ＣＤ−ＲＯＭ等の可搬型記録媒体が販売される。また、プログラムをサーバコンピュータの記憶装置に格納しておき、ネットワークを介して、サーバコンピュータから他のコンピュータにそのプログラムを転送することもできる。
【０１９３】
リンク情報管理プログラムを実行するコンピュータは、例えば、可搬型記録媒体に記録されたプログラムもしくはサーバコンピュータから転送されたプログラムを、自己の記憶装置に格納する。そして、コンピュータは、自己の記憶装置からプログラムを読み取り、プログラムに従った処理を実行する。なお、コンピュータは、可搬型記録媒体から直接プログラムを読み取り、そのプログラムに従った処理を実行することもできる。また、コンピュータは、サーバコンピュータからプログラムが転送される毎に、逐次、受け取ったプログラムに従った処理を実行することもできる。
【０１９４】
（付記１）  コンピュータを、
ユーザが購読を希望した文書の位置情報と前記文書の概要の位置を示す概要位置情報とを有するユーザリストを、前記ユーザ毎に管理するリスト管理ＤＢ、
あるユーザが利用する端末装置から送信される前記概要位置情報の変更に関する変更データを受信し、当該ユーザの前記ユーザリストの前記概要位置情報を変更する変更手段、
所定の判別ルールに基づいて、変更した前記概要位置情報もしくは変更した前記概要位置情報に対応する前記文書の位置情報を前記ユーザリストに有する他のユーザが利用する前記端末装置に、前記概要位置情報の変更を通知すべきか否かを判別する通知判別手段、
前記通知判別手段が通知すべきと判別したとき、前記他のユーザが利用する前記端末装置に対し、前記概要位置情報の変更を含む通知情報を通知する通知手段、
として機能させることを特徴とするリンク情報管理プログラム。
【０１９５】
（付記２）  前記通知手段は、前記変更の内容を補足する補足情報を前記通知情報に付加して通知することを特徴とする付記１記載のリンク情報管理プログラム。
（付記３）  前記補足情報は、前記概要位置情報の変更を促進する情報であることを特徴とする付記２記載のリンク情報管理プログラム。
【０１９６】
（付記４）  前記コンピュータを、前記他のユーザが利用する前記端末装置から送信される前記通知情報に応答する応答情報を受信すると、前記他のユーザの前記ユーザリストの前記概要位置情報を、当該ユーザが利用する前記端末装置から送信された前記概要位置情報に変更する応答管理手段、として機能させることを特徴とする付記１記載のリンク情報管理プログラム。
【０１９７】
（付記５）  前記応答管理手段が、前記他のユーザのうちの前記通知情報の再通知を希望する再通知希望ユーザが利用する前記端末装置から送信された前記再通知希望ユーザの希望する再通知条件とともに前記通知情報の再通知を希望する応答情報を受信すると、前記コンピュータを更に、前記再通知条件を格納する再通知条件管理ＤＢ、として機能させ、
前記応答管理手段は、前記再通知条件が満たされたか否かを判断し、前記再通知条件が満たされた場合、前記通知手段に前記再通知希望ユーザが利用する前記端末装置への前記通知情報の再通知を依頼することを特徴とする付記４記載のリンク情報管理プログラム。
【０１９８】
（付記６）  前記通知手段は、前記通知情報を再通知する際、前記概要位置情報の変更を促す補足情報を付加することを特徴とする付記５記載のリンク情報管理プログラム。
（付記７）  前記通知手段は、所定の通知ルールに基づいて、前記文書の位置情報を前記ユーザリストに有するユーザから通知対象のユーザを特定し、前記通知情報を前記通知対象のユーザが利用する前記端末装置に通知することを特徴とする付記１記載のリンク情報管理プログラム。
【０１９９】
（付記８）  前記通知判別手段は、前記リスト管理ＤＢを参照して前記変更データに含まれる前記概要位置情報の変更内容に一致する変更を行っている前記他のユーザが所定人数以上か否かを判断し、前記概要位置情報の変更内容に一致する変更を行っている前記他のユーザが所定人数以上の場合に通知すべきと判別することを特徴とする付記１記載のリンク情報管理プログラム。
【０２００】
（付記９）  前記コンピュータを更に、前記各ユーザリストを定期的にチェックして前記文書の位置情報にアクセスできなくなった前記概要位置情報を検出するリンク切れ検出手段、
前記文書の位置情報にアクセスできなくなった前記概要位置情報に替えた新たな概要位置情報への変更を依頼する依頼情報を所定のユーザが利用する前記端末装置に送信する依頼手段、として機能させることを特徴とする付記１記載のリンク情報管理プログラム。
【０２０１】
（付記１０）  前記依頼手段は、前記通知手段が通知した前記通知情報に応じて前記概要位置情報の変更を行ったユーザの割合を計算したユーザプロファイルに基づいて、前記割合の最も高い前記通知情報の送信者が利用する前記端末装置に前記依頼情報を送信することを特徴とする付記９記載のリンク情報管理プログラム。
【０２０２】
（付記１１）  前記通知判別手段は、当該ユーザが利用する前記端末装置から送信される前記変更データの前記概要位置情報が、前記他のユーザの前記ユーザリストの前記概要位置情報と異なっているか否かを判断し、異なっている場合、前記通知手段が、前記変更データを送信したユーザが利用する前記端末装置に対して前記他のユーザの前記ユーザリストの、前記概要位置情報を通知することを特徴とする付記１記載のリンク情報管理プログラム。
【０２０３】
（付記１２）  前記コンピュータを、前記ユーザ毎の前記概要位置情報へのアクセスログを保管するアクセスログ保管ＤＢとして機能させ、
前記検出手段は、前記ユーザリストと前記アクセスログとに基づいて、所定期間アクセスされていない前記概要位置情報を検出し、
前記通知手段は、前記通知判別手段が通知すべきと判別したとき、前記概要位置情報を前記ユーザリストに有するユーザを通知対象のユーザとし、前記概要位置情報を前記通知対象のユーザが利用する前記端末装置に通知することを特徴とする付記９記載のリンク情報管理プログラム。
【０２０４】
（付記１３）  前記概要位置情報は、フィード情報であることを特徴とする付記１記載のリンク情報管理プログラム。
（付記１４）  あるユーザが利用する端末装置から送信される前記ユーザが購読を希望した文書の概要の位置を示す概要位置情報の変更に関する変更データを受信すると、前記文書の位置情報と前記概要位置情報とを有するユーザリストを前記ユーザ毎に管理するリスト管理ＤＢの、当該ユーザの前記ユーザリストの前記概要位置情報を変更し、
所定の判別ルールに基づいて、変更した前記概要位置情報もしくは変更した前記概要位置情報に対応する前記文書の位置情報を前記ユーザリストに有する他のユーザが利用する前記端末装置に、前記概要位置情報の変更を通知すべきか否かを判別し、
通知すべきと判別したとき、前記他のユーザが利用する前記端末装置に対し、前記概要位置情報の変更を含む通知情報を通知する、
ことを特徴とするリンク情報管理方法。
【０２０５】
（付記１５）  ユーザが購読を希望した文書の位置情報と前記文書の概要の位置を示す概要位置情報とを有するユーザリストを、前記ユーザ毎に管理するリスト管理ＤＢと、
あるユーザが利用する端末装置から送信される前記概要位置情報の変更に関する変更データを受信し、当該ユーザの前記ユーザリストの前記概要位置情報を変更する変更手段と、
所定の判別ルールに基づいて、変更した前記概要位置情報もしくは変更した前記概要位置情報に対応する前記文書の位置情報を前記ユーザリストに有する他のユーザが利用する前記端末装置に、前記概要位置情報の変更を通知すべきか否かを判別する通知判別手段と、
前記通知判別手段が通知すべきと判別したとき、前記他のユーザが利用する前記端末装置に対し、前記概要位置情報の変更を含む通知情報を通知する通知手段と、
を有することを特徴とするリンク情報管理装置。
【０２０６】
（付記１６）  コンピュータを、
ユーザが購読を希望した文書に関する位置を記録した位置情報を有するユーザリストを、前記ユーザ毎に管理するリスト管理ＤＢ、
あるユーザが利用する端末装置から送信される前記位置情報の変更に関する変更データを受信し、当該ユーザの前記ユーザリストの前記位置情報を変更する変更手段、
所定の判別ルールに基づいて、変更した前記位置情報に対応する位置情報を前記ユーザリストに有する他のユーザが利用する前記端末装置に、前記位置情報の変更を通知すべきか否かを判別する通知判別手段、
前記通知判別手段が通知すべきと判別したとき、前記他のユーザが利用する前記端末装置に対し、前記位置情報の変更を含む通知情報を通知する通知手段、
として機能させることを特徴とするリンク情報管理プログラム。
【図面の簡単な説明】
【０２０７】
【図１】実施の形態に適用される発明を示す概要図である。
【図２】実施の形態の情報管理システムを示す図である。
【図３】端末装置のハードウェア構成例を示す図である。
【図４】サーバおよび端末装置の機能を示すブロック図である。
【図５】フィードリーダを示す図である。
【図６】フィードのプロパティ編集画面を示す図である。
【図７】変更データを示す図である。
【図８】フィードリストを示す図である。
【図９】変更履歴管理テーブルを示す図である。
【図１０】ルールテーブルを示す図である。
【図１１】サーバの動作を示すフローチャートである。
【図１２】検出処理を示すフローチャートである。
【図１３】判別処理を示すフローチャートである。
【図１４】通知対象ユーザデータを示す図である。
【図１５】データ作成処理を示すフローチャートである。
【図１６】データ送信処理を示すフローチャートである。
【図１７】更新通知ウィンドウを示す図である。
【図１８】応答反映処理を示すフローチャートである。
【図１９】再通知処理を示すフローチャートである。
【図２０】具体例のフィードリストを示す図である。
【図２１】データ作成処理終了時の変更履歴管理テーブルを示す図である。
【図２２】応答情報を受信したときの変更履歴管理テーブルを示す図である。
【図２３】再通知ルールテーブルを示す図である。
【図２４】再通知処理実行後の変更履歴管理テーブルを示す図である。
【図２５】再通知処理終了後の変更履歴管理テーブルを示す図である。
【図２６】第１の実施の形態の情報管理システムをブックマークに適用した場合の変更データを示す図である。
【図２７】第１の実施の形態の情報管理システムをブックマークに適用した場合のルールテーブルを示す図である。
【図２８】第２の実施の形態のサーバを示すブロック図である。
【図２９】人数カウンタテーブルを示す図である。
【図３０】第２の実施の形態のルールテーブルを示す図である。
【図３１】変更データの具体例を示す図である。
【図３２】第３の実施の形態のサーバを示すブロック図である。
【図３３】ユーザプロファイルテーブルを示す図である。
【図３４】第３の実施の形態のルールテーブルを示す図である。
【図３５】変更データの具体例を示す図である。
【図３６】第４の実施の形態のルールテーブルを示す図である。
【図３７】変更データの具体例を示す図である。
【図３８】変更データを受け取った場合の通知判別部の動作を示すフローチャートである。
【図３９】第５の実施の形態のサーバを示すブロック図である。
【図４０】アクセスログを示す図である。
【符号の説明】
【０２０８】
１  コンピュータ
２  リスト管理ＤＢ
３  変更手段
４、６、４０ａ〜４０ｄ  端末装置
５  通知判別手段
７  通知手段
２０、２０ａ〜２０ｃサーバ
２１  フィードリスト管理ＤＢ
２１ａ  フィードリスト
２２  変更履歴管理ＤＢ
２２ａ  変更履歴管理テーブル
２３  ルール管理ＤＢ
２３ａ  ルールテーブル
２３ｂ  ユーザルールテーブル
２４、２４ａ、２４ｂ  変更検出部
２５  通知判別部
２５ａ  通知対象ユーザデータ
２６  通知情報選択部
２７  ウィンドウ情報作成部
２８  応答管理部
２９  カウンタ管理ＤＢ
２９ａ  人数カウンタテーブル
３０  リンク切れ検出部
３１  メンテ者ランキング計算部
３２  代替フィード調査依頼部
３３  ユーザプロファイル管理ＤＢ
３３ａ  ユーザプロファイルテーブル
３４  アクセスログ管理ＤＢ
３４ａ  アクセスログ
４１ａ、４１ｂ  変更通知部
４２ａ、４２ｂ  更新候補受信部
４３ａ、４３ｂ  応答情報送信部
４４ａ、４４ｂ  アプリケーション実行部
４５  フィードリーダ
５１  更新通知ウィンドウ
２３０ａ〜２３４ａ  ルール
３１１ａ  変更データ
【図１】
2008146422.tif 000003
【図２】
2008146422.tif 000004
【図３】
2008146422.tif 000005
【図４】
2008146422.tif 000006
【図５】
2008146422.tif 000007
【図６】
2008146422.tif 000008
【図７】
2008146422.tif 000009
【図８】
2008146422.tif 000010
【図９】
2008146422.tif 000011
【図１０】
2008146422.tif 000012
【図１１】
2008146422.tif 000013
【図１２】
2008146422.tif 000014
【図１３】
2008146422.tif 000015
【図１４】
2008146422.tif 000016
【図１５】
2008146422.tif 000017
【図１６】
2008146422.tif 000018
【図１７】
2008146422.tif 000019
【図１８】
2008146422.tif 000020
【図１９】
2008146422.tif 000021
【図２０】
2008146422.tif 000022
【図２１】
2008146422.tif 000023
【図２２】
2008146422.tif 000024
【図２３】
2008146422.tif 000025
【図２４】
2008146422.tif 000026
【図２５】
2008146422.tif 000027
【図２６】
2008146422.tif 000028
【図２７】
2008146422.tif 000029
【図２８】
2008146422.tif 000030
【図２９】
2008146422.tif 000031
【図３０】
2008146422.tif 000032
【図３１】
2008146422.tif 000033
【図３２】
2008146422.tif 000034
【図３３】
2008146422.tif 000035
【図３４】
2008146422.tif 000036
【図３５】
2008146422.tif 000037
【図３６】
2008146422.tif 000038
【図３７】
2008146422.tif 000039
【図３８】
2008146422.tif 000040
【図３９】
2008146422.tif 000041
【図４０】
2008146422.tif 000042