JP4721740B2

JP4721740B2 - 記事又は話題を管理するためのプログラム

Info

Publication number: JP4721740B2
Application number: JP2005082859A
Authority: JP
Inventors: 宏弥稲越; 青史岡本; 達哉浅井
Original assignee: Fujitsu Ltd
Current assignee: Fujitsu Ltd
Priority date: 2005-03-23
Filing date: 2005-03-23
Publication date: 2011-07-13
Anticipated expiration: 2025-03-23
Also published as: JP2006268201A; US20060213976A1; US7331517B2

Description

本発明は、ネットワークにおいて提供される記事データを効率的に管理する技術に関する。

従来、インターネットにおける情報提供者は、高度なコンピュータ技術を有するもののみであった。しかし、テンプレートや平易なユーザ・インターフェースを有する専用の情報提供プログラムを用いることにより、一般のインターネット・ユーザも容易に情報を提供することができるようになった。その結果、近年ではインターネットによる情報提供が一般のインターネット・ユーザに広く普及し始めている。このように一般の情報提供者が増加したきっかけの１つとして、ウェブログ（Ｗｅｂｌｏｇ）またはブログ（Ｂｌｏｇ）と呼ばれるシステムがある。ウェブログとは、簡単な操作で文章を執筆し、文章データを管理するシステムである。ウェブログは当初、日記を書き、それを一部の友人が閲覧するという個人的な用途又は狭い用途のシステムとして認識されていた。しかし、ジャーナリストやライター、様々な分野の専門家などは意見を主張するためにそれを広く公開し、意見を交換し合うためにウェブログを用いた。これにより現在では、ウェブログは広用途で有用性の高いシステムとして認識されつつある。さらに、ウェブログはより即応性の高い情報提供媒体として期待されている。

このようなウェブログに対する期待を支える技術の１つに、ＲＳＳ（RDF Site Summary）がある。ウェブログのデータが比較的長い記事データであるのに対し、ＲＳＳは、日時と１行（またはたかだか数行）の記事概要、記事タイトル、リンク先ＵＲＬ等により構成されている。ＲＳＳデータはＸＭＬ（eXtensible Markup Language）形式で記述されているため、そのままではユーザにとって読みにくい。そこで、ユーザはＲＳＳリーダと呼ばれる専用のアプリケーションを用いて、ＲＳＳデータを情報として認識する。ユーザは関心のあるウェブログ・サイトをＲＳＳリーダのブックマークに登録しておく。ＲＳＳリーダはブックマークに登録されたウェブログ・サイトを定期的に巡回し、サイトが配信するＲＳＳをダウンロードし、それを表示する。これによりユーザは、自らの操作でサイトを巡回することなく、新着記事の掲載がされたことをすぐに知ることができる。また、ＲＳＳは、ウェブログ・サイトへの適用に限らず、ニュース・サイトにも適用されていて、さらにｅコマース・サイト、グループウェア等への適用も試みられている。

ＲＳＳリーダには複数の種類があるが、代表的なものとして、ティッカー型、メール・クライアント型がある。図２７では、従来のティッカー型ＲＳＳリーダによるＲＳＳデータの表示例を示している。ティッカー型ＲＳＳリーダはウェブログ・サイトから取得したＲＳＳに含まれるデータの内、限られたデータ（例えば、記事概要と更新日時のみ）を所定の時間間隔で逐次表示するものである。ティッカー型ＲＳＳリーダは、コンピュータの画面上を占有する割合が小さい点、記事を講読するためのユーザ操作が単純であり、記事概要を読むだけならば操作が不要である点において優れている。なお、ティッカー型ＲＳＳリーダで、出願時点において日本国内のＷｅｂサイトから入手可能なもののＵＲＬを以下に記す。
http://www.work-at.co.jp/rabbit/

また、メール・クライアント型ＲＳＳリーダは、メール・リーダと類似のユーザ・インタフェースを有する。メール・クライアント型ＲＳＳリーダでは、ＲＳＳに含まれる記事１部をメール１通と同様に扱い、ウェブログ・サイトからの記事を蓄積する。そして、記事の既読・未読による管理や記事の検索など、豊富な機能を提供しているのがメール・クライアント型ＲＳＳリーダの特徴である。なお、メール・クライアント型ＲＳＳリーダで、出願時点において日本国内のＷｅｂサイトから入手可能なもののＵＲＬを以下に記す。
http://www.infomaker.jp/headline/

また、文献公知の技術として、特開２００３−５８５１１号公報にはストリーミング情報表示を有する携帯情報端末に関する技術が開示されている。これによれば、携帯情報端末は、画面の限定された部分を横断して、スクロールまたは回転するティッカー・テープ形式で情報及び広告をスクロールする手段を有している。これにより、大量の情報を広告と共に表示することができる。
特開２００３−５８５１１号公報

しかしながら、従来のＲＳＳリーダには、主に、以下のような問題があった。

ＲＳＳリーダのブックマークに複数のサイトを登録しておくと、類似する２つのサイトで、重複または類似する記事が更新されることがある。特に速報性が求められるニュース・サイトからの記事において、このような傾向は多く見られる。そのため、ＲＳＳリーダが取得した記事の数の割には、ユーザが得られる知識の量は増加しない。特にティッカー型ＲＳＳリーダの場合には、記事が逐次表示されるので、一定時間に表示可能な記事の数に限界がある。このように、重複または類似する記事を表示することは、ユーザの知識獲得という側面において効率が悪い。

ＲＳＳリーダのブックマークに登録するサイトが多くなると、一定時間内に受信する記事の数は多くなる。その一方で、ユーザが記事を読むことに割り当てられる時間は限られているので、受信した全ての記事を読み切れないという問題が発生する。そのため、記事情報の重複または類似の場合と同様、ＲＳＳリーダが取得した記事の数の割に、ユーザが得られる知識の量は増加しない。例えば、ティッカー型ＲＳＳリーダでは、全ての記事を表示する前に、次々と新しい記事を受信するため、記事が一度も表示されないケースが多発する。また、ティッカー型ＲＳＳリーダは記事を逐次表示するため、離席や別作業によりユーザがＲＳＳリーダの記事表示部を見ていないときに表示された記事は、見落とした記事となる。メール・クライアント型ＲＳＳリーダでは、受信した記事は全て蓄積可能であるものの、ユーザがアプリケーションを起動し、記事を読むことに割り当てられる時間は限られている。そのため、既着記事を読み終える前に次々と新着記事を受信するので、記事の見落としが起こりうる。このように、記事の見落としはユーザの知識獲得という側面において効率が悪い。

メール・クライアント型ＲＳＳリーダには、効率よく記事情報に接するために、ブックマークに登録されたサイトをフォルダ・ツリーに従って分類し、互いに類似したカテゴリを扱う複数のサイトを１つのカテゴリ（フォルダ）にまとめておくフォルダ管理機能を提供しているものがある。このようなＲＳＳリーダでは、カテゴリに相当するフォルダを選択すると、そのフォルダに分類されたサイトから提供された記事を読むことが可能である。一見、この機能は有用に見える。しかし、（１）最適なカテゴリの分類方法は、ユーザの嗜好などにより変化する、（２）１つのサイトが複数のカテゴリを扱っている、などの理由により、フォルダ管理機能は有効に機能しないことが多い。

また、フォルダによる管理に対して、キーワード検索機能を有するＲＳＳリーダもすでに存在している。キーワード検索機能は、予め記事を管理していなくても、ユーザが目的としている記事を絞り込む手段を与えているという点で、ユーザにとって非常に有用な機能である。例えば、キーワードによる記事検索は、検索する対象が明らかで、調査対象と関連するキーワードを容易に思い出すことができる場合には役に立つ。しかし、新着記事を読むときは記事アクセスの目的が決まっていない場合が多い。そのため、キーワード検索機能を有効活用できる状況が限定されるという問題がある。

以上に述べた問題点をまとめると、従来のＲＳＳリーダの問題点は、記事の重複や類似、見落とし、管理の手間等の理由により、ユーザが効率的に情報取得や知識獲得を行うことができなかったという点である。

以上の問題に鑑み、本発明の目的は、ネットワークにおいて提供される記事をユーザが効率的に知得できるようにするための技術を提供することである。

また、本発明の他の目的は、ネットワークにおいて提供される記事データを効率的に管理する技術を提供することである。

本発明に係るプログラムは、記事記憶部に格納されている第１の記事（例えばＲＳＳ文書又は記事概要）の表示がユーザによって選択されたことを検出した場合、第１の記事と記事記憶部に格納されている第２の記事との記事関連度を算出する記事関連度算出ステップと、記事関連度が所定の条件を満たした場合、第２の記事を第１の記事に関連して抽出する抽出ステップと、記事記憶部に第１の記事を最優先に格納する最優先格納ステップと、抽出された第２の記事を、第１の記事に次いで優先的に記事記憶部に格納する優先格納ステップと、をコンピュータに実行させるものである。これにより、相互に関連する記事が、例えば１つの話題を構成するものとして抽出され、ユーザは当該話題を構成する記事を優先的に講読できるようになる。従って、記事の効率的な管理及びユーザによる記事の効率的な知得が実現される。

また、上で述べた記事記憶部が記事データベースを含み、記事データベースがフォルダ表示部に表示される１つまたは複数のフォルダに係るフォルダ情報を含む記事を格納し、第１及び第２の記事が第１のフォルダに係るフォルダ情報を含むようにしてもよい。そして、フォルダ表示部に表示された第１のフォルダをユーザが選択すると、フォルダ情報を含む第１及び第２の記事を記事データベースから取得してスプールへ格納するステップと、スプールに格納された第１及び第２の記事を記事一覧表示部に表示するステップとをさらにコンピュータに実行させてもよい。このように所定のユーザ・インタフェースを有するＲＳＳリーダ、例えば、メール・クライアント型ＲＳＳリーダの場合、フォルダ単位で処理が実施されることもある。

また、記事を優先的に格納するときには、記事記憶部に格納された第１の記事と抽出処理において抽出された第２の記事とを話題としてグループ化するステップをコンピュータに実行させ、グループ化された話題の削除がユーザによって選択された場合には、当該話題としてグループ化されている記事データを記事記憶部から削除するステップをさらに実行させてもよい。これにより、複数の関連する記事データが話題として管理されるようになり、ユーザがある話題についての記事を読む必要がないと感じたときに話題削除に係る指示を行うことにより、当該話題に係る記事データが一括削除されることとなる。従って、ユーザは効果的に別の話題に係る記事を知得できるようになる。

また、話題情報が付加されている１つの記事で又は同一の話題情報が付加されている複数の記事で構成される話題を話題データベースに格納するステップと、記事提供サイトから第３の記事を取得するステップと、第３の記事と、話題データベースに格納されている１つ又は複数の話題との話題関連度を算出するステップと、所定の第２の条件を満たしている話題関連度が存在する場合には、当該話題関連度に係る話題の話題情報を第３の記事に付加し、話題情報が付加された第３の記事を話題データベースに格納するステップと、をさらにコンピュータに実行させてもよい。また、スリープ・モードとなった場合、例えば一定時間、ユーザからの操作がされなかった場合や、プログラム・ウィンドウが最小化された場合に、上記ステップを実行させてもよい。これにより、記事データが効率的に管理されることとなる。

また、ユーザによる所定の操作指示（例えば、最小化された画面を元に戻す操作指示、選択した記事概要に係る記事全体を開く操作指示など）により、スリープ・モードから通常モードに切り替わった場合に、話題データベースに格納されている記事を取得するステップと、取得した記事に付加されている話題情報に基づき、取得記事を話題毎に表示するステップと、をさらにコンピュータに実行させてもよい。これにより、ユーザは話題毎に記事を講読することができるようになる。従って、ユーザは効率的に記事を知得できる。なお、話題を表示するときに、予め記憶された、スリープ・モードとなった日時を参照し（例えば、話題データベースの所定の領域を参照）、当該日時に基づき、スリープ・モード時にサイトから取得した記事データを新着記事とし、それ以前に既に話題データベースに格納されている記事データを関連記事として、新着記事と関連記事とに分けて表示してもよい。

本発明に係るプログラムは、例えばフレキシブル・ディスク、ＣＤ−ＲＯＭ、光磁気ディスク、半導体メモリ、ハードディスク等の記憶媒体又は記憶装置に格納される。また、ネットワークを介してディジタル信号にて頒布される場合もある。なお、処理途中のデータについては、コンピュータのメモリ等の記憶装置に一時保管される。

本発明によれば、ネットワークにおいて提供される記事データを効率的に管理することができる。

また、本発明の別の側面として、ネットワークにおいて提供される記事データをユーザが効率的に知得することができるようになる。

［本発明の第１の実施の形態］
図１乃至図４を用いて、本発明の第１の実施の形態の概要を説明する。本発明の第１の実施の形態に係るコンピュータ１は、ティッカー型のＲＳＳリーダ・プログラム３を実行させる装置であって、ＲＳＳリーダ・プログラム３並びに入出力インタフェースとしての記事表示部５、操作部７及び分類結果表示部９を含む。コンピュータ１は、例えばインターネット等のネットワーク１１を介して記事提供サイト１３に接続されている。コンピュータ１によって実行されるＲＳＳリーダ・プログラム３は、当該記事提供サイト１３からＲＳＳ文書（ＲＳＳドキュメント）と呼ばれるデータを取得し、そこに含まれる記事概要を管理し、必要に応じて１つまたは複数の記事概要を１つのグループに統合するプログラムである。つまり、ＲＳＳリーダ・プログラム３は、１件または複数の記事概要を１つの集合にグループ化して管理している。ＲＳＳリーダ・プログラム３は、記事収集部１５、ブッマーク１７、表示候補キュー１９、表示記事取得部２１、イベント受信部２３、話題抽出部２５、話題データベース２７、削除部２９、話題再構成部３１、話題分類部３３及び分類結果取得部３５を含む。

ここで、「グループ化」とは、相互に関連する複数の記事概要で、または１つの記事概要のみで１つの集合を構成することである。本発明の第１の実施の形態では、このような集合を「話題集合」と呼ぶ。図２に、記事概要と話題集合との関係を示す。図２において、２００ａは「Ａ」という話題についての話題集合であり、これには、「ａ１」という話題についての記事概要２０１ａ、「ａ２」という話題についての記事概要２０２ａ、「ａ３」という話題についての記事概要２０３ａ、「ａ４」という話題についての記事概要２０４ａが含まれている。例えば、
話題集合２００ａ＝「クリスマス」という話題に関する記事概要の集合
とすると、
記事概要２０１ａ＝「ＵＳＢクリスマスツリー、今年も販売」に関する記事概要，
記事概要２０２ａ＝「ナイトメアー・ビフォー・クリスマス」に関する記事概要，
記事概要２０３ａ＝「クリスマス商戦盛り上がらず」に関する記事概要，
記事概要２０４ａ＝「サンタクロースはどこからくるの？」に関する記事概要
が、話題集合２００ａに含まれ得る。また、話題集合２００ｂについても、話題集合２００ａ同様であり、
話題集合２００ｂ＝「デスクトップ検索」という話題に関する記事概要の集合
とすると、
記事概要２０１ｂ＝「Ask Jeevesがベータ版公開」に関する記事概要，
記事概要２０２ｂ＝「M*Sサーチデスクトップ検索は．．．」に関する記事概要，
記事概要２０３ｂ＝「Go**leがデスクトップ検索一番乗り」に関する記事概要
が、話題集合２００ｂに含まれ得る。

ＲＳＳリーダ・プログラム３が、記事概要２０１ａ乃至２０４ａ、及び２０１ｂ乃至２０３ｂをグループ化された話題集合として他の記事概要と区別し、これらの記事概要を効率的に管理するために、記事概要２０１ａ乃至２０４ａ、及び２０１ｂ乃至２０３ｂに対して特定のデータを付与する。この特定のデータは、１つは後に述べる「マーカー」と呼ばれるものであり、もう１つは「話題要素」と呼ばれるものである。例えば、記事概要２０１ａ乃至２０４ａには「クリスマス」というデータが含まれ得るが、これとは別に「クリスマス」という話題に係る話題要素を記事概要２０１ａ乃至２０４ａに付与する。同様に、記事概要２０１ｂ乃至２０３ｂには「デスクトップ検索」というデータが含まれ得るが、これとは別に「デスクトップ検索」という話題に係る話題要素を記事概要２０１ｂ乃至２０３ｂに付与する。

ここで、図３（ａ）及び図３（ｂ）を用いて、ＲＳＳ文書の構造とＲＳＳ文書に含まれる要素について説明する。図３（ａ）で概略的に示すように、記事提供サイト１３から取得したＲＳＳ文書３００は、ＸＭＬ（eXtensible Markup Language）形式で記述されている。ＸＭＬにおいては、開始タグ＜…＞及び終了タグ＜／…＞の１組のタグを用いて、様々なデータを記述することができる。ＲＳＳにおいては、図３（ａ）に例示するように、＜ｉｔｅｍ／＞タグ、＜ｔｉｔｌｅ／＞タグ、＜ｌｉｎｋ／＞タグ、＜ｄｅｓｃｒｉｐｔｉｏｎ／＞タグ、＜ｃｏｎｔｅｎｔ：ｅｎｃｏｄｅｄ／＞タグ、＜ｄｃ：ｓｕｂｕｊｅｃｔ／＞タグ、＜ｄｃ：ｃｒｅａｔｏｒ／＞タグ、＜ｄｃ：ｄａｔｅ／＞タグがＲＳＳ文書３００中に記述されている。これらのタグはＲＳＳにおいて一般に用いられているタグである。

また、ＲＳＳ文書３００において例えば「ＸＹＺ新聞社」という要素の内容は、＜ｄｃ：ｃｒｅａｔｏｒ＞タグ及び＜／ｄｃ：ｃｒｅａｔｏｒ＞タグの組に挟まれて記述される。

図３（ｂ）では、ＲＳＳ文書の要素の一例を用途別に分類して示している。ただし、図３（ｂ）では、終了タグ及びタグの組に挟まれる内容については記載を省略している。記事提供サイト１３から取得したＲＳＳ文書３００の要素は、大きく２種類の記事要素に分類することができる。１つは、リンク要素３０１ａ（＜ｌｉｎｋ／＞タグ）及び更新日時要素３０１ｂ（＜ｄｃ：ｄａｔｅ／＞タグ）であり、これらを複合キー３０１として、ＲＳＳリーダ・プログラム３はＲＳＳ文書を一意に特定することができる。もう１つは、便宜上「記事抽出要素」または「記事抽出タグ」と呼ぶものであり、図３（ａ）に示される＜ｉｔｅｍ／＞タグ、＜ｔｉｔｌｅ／＞タグ等は、記事抽出要素に分類される。記事抽出タグ３０３として分類されるタグは、＜ｌｉｎｋ／＞タグ及び＜ｄｃ：ｄａｔｅ／＞タグと、以下で述べる＜ｗａｄａｉ／＞タグ以外のタグとする。

一方、話題要素３０５（＜ｗａｄａｉ／＞タグ）は、ＲＳＳ文書をグループ化したときに、グループ化されたＲＳＳ文書に付与される要素である。つまり、ＲＳＳリーダ・プログラム３は、２種類の記事要素３０１，３０３のみを含むＲＳＳ文書３００に対して、さらに話題要素３０５が付与されたＲＳＳ文書３０７を、話題集合を構成するＲＳＳ文書の１つとして認識する。なお、ＲＳＳリーダ・プログラム３において、ＲＳＳ文書３００がＸＭＬファイルで管理される場合には、話題要素３０５が当該ＸＭＬファイルの所定の領域に記述されるようにしてもよい。また、ＲＳＳ文書３００がリストやリレーショナル・データベースで管理される場合には、当該ＲＳＳ文書に対応するレコードの特定の領域に話題要素に係るデータ、例えば「話題カラム」領域上に「野球」というデータを格納してもよい。

図１に戻り、記事収集部１５は、ブックマーク１７を参照し、記事提供サイト１３からＲＳＳ文書を取得し、取得したＲＳＳ文書の記事概要を表示候補キュー１９に順次格納する。ブックマーク１７には、予めユーザが登録したリンク先に関するデータ、例えば記事提供サイト１３のＵＲＬが格納されている。記事収集部１５は、当該リンク先データに基づき、記事提供サイト１３を巡回（ポーリング）し、当該サイトのＲＳＳ文書を新着記事としてダウンロードする。サイトの巡回は定期的に行われる。また、ＲＳＳリーダ・プログラム３の動作モードがスリープ・モードの場合には、記事収集部１５は、取得したＲＳＳ文書に係る記事概要を表示候補キュー１９に格納せずに、話題分類部３３に引き渡す。

表示記事取得部２１は、後に述べるイベント受信部２３からの指示により、表示候補キュー１９の先頭に格納された記事概要を取得する。取得した記事概要は、コンピュータ１の記事表示部５に表示される。

イベント受信部２３は、イベントを受け付け、受け付けたイベントを判定して、各処理部に対し処理の実行を指示する。このようなイベントには、ユーザが操作部７（マウス、キーボード等の入力インタフェース）を用いてＲＳＳリーダ・プログラム３に対して指示することにより発生するユーザ・イベントがある。また、イベント受信部２３自身が発生させるイベントもあり、例えば、記事表示部５に表示される内容を定期的に更新（リフレッシュ）するために発生させる第１のタイマー・イベントや、一定時間ユーザからの操作がされなかったことを検出したことにより発生させる第２のタイマー・イベントがある。イベント受信部２３は、このようなタイマー・イベントを管理するためのタイマーを有する。また、処理実行を指示する際、記事表示部５に表示中の記事文書（表示された記事概要）に係るデータ、つまり先頭の記事概要を、必要に応じて表示記事取得部２１から取得する。

話題抽出部２５は、先頭の記事概要を指定した処理実行指示がイベント受信部２３を介して通知されると、表示候補キュー１９に格納されている記事概要の中から、先頭の記事概要と関連を有する記事概要を抽出する。抽出された記事概要は、先頭の記事概要と共にグループ化される。グループ化された記事概要は、話題データベース２７に登録されると同時に、当該グループ化された記事概要が、先頭の記事概要から順に記事表示部５に表示されるように、表示候補キュー１９に格納される。

削除部２９は、ユーザからの削除指示（操作部７からの指示）イベントの通知をイベント受信部２３を介して受信することにより、または上述の第１のタイマー・イベントに係る処理の指示を受信することにより、表示候補キュー１９から記事概要を削除する。記事概要の削除には２つのモードがある。１つは記事概要削除モードであり、もう１つは話題削除モードである。記事概要削除モードの場合には、１件のＲＳＳ文書を削除し、話題削除の場合には、グループ化された話題集合に係る記事概要を一括削除する。

ＲＳＳリーダ・プログラム３は、イベント受信部２３が例えば一定時間ユーザからの操作がされなかったことや、ＲＳＳリーダ・プログラム３のプログラム・ウィンドウが最小化されたことを検出した場合には、動作モードを通常モードからスリープ・モードに切り替える機能を有する。ＲＳＳリーダ・プログラム３がスリープ・モードに移行すると、記事収集部１５は、サイト巡回を一時停止する。話題再構成部３１は、スリープ・モードへの移行時に、話題データベース２７に格納されている話題集合の再構成を行う。話題集合の再構成が終わると、記事収集部１５はサイト巡回を再開する。しかし、スリープ・モード時に取得したＲＳＳ文書に係る記事概要は、表示候補キュー１９に格納されずに、話題分類部３３に引き渡される。

話題分類部３３は、取得した記事概要が話題データベース２７に格納されている話題集合のいずれかに分類可能かを判定する。分類可能な場合には、話題分類部３３は、分類先の話題集合に係る話題要素を当該記事概要に付与し、話題要素が付与された記事概要を話題データベース２７に登録する。同時に、表示候補キュー１９に当該記事概要を格納する。分類できない場合には、話題データベース２７にも表示候補キュー１９にも保存せずに記事概要を破棄する。なお、分類できない場合に、記事提供サイト１３から取得した記事概要を破棄せずに、当該記事概要について新たな話題集合を定義する方法なども考えられる。

スリープ・モードのＲＳＳリーダ・プログラム３は、イベント受信部２３がユーザからの所定の操作に係るイベントを検出した場合、例えばユーザからの記事表示の指示に係るイベントを検出した場合や、ユーザ指示により最小化されたプログラム・ウィンドウを元のサイズに戻すイベントを検出した場合には、動作モードを通常モードに切り替える。このとき、記事収集部１５の動作を通常モードの動作に切り替える。同時に、分類結果取得部３５は、イベント受信部２３からの処理実行の指示を受信することにより、話題データベース２７に格納されている記事概要の全てを取得し、当該記事概要に付与された話題要素により記事概要を話題毎に整理し、整理した結果を分類結果表示部９に表示する。記事概要の整理においては、各話題内で、さらに新着記事毎および関連記事毎に表示するのが好ましい。

図４を用いて、ＲＳＳリーダ・プログラム３のプログラム・ウィンドウ４１について説明する。プログラム・ウィンドウ４１は、記事概要表示部４３と、３つのボタン４５，４７，４９とを含む。記事概要表示部４３は、表示候補キュー１９から取得したＲＳＳ文書に係る記事概要の一部または全ての要素、詳細には開始タグ及び終了タグに挟まれた内容を表示する領域である。図４では、図３（ａ）に示したＲＳＳ文書３００のうち、＜ｔｉｔｌｅ／＞要素、＜ｄｃ：ｃｒｅａｔｏｒ／＞要素、＜ｄｃ：ｄａｔｅ／＞要素の内容を用いて表示を行っている例を示している。

＜ｔｉｔｌｅ／＞要素の内容「東京円相場、１ドル＝１０２円０５〜０７銭（１５：００現在）」は、リンク先を＜ｌｉｎｋ／＞要素の内容とするハイパーリンク５１となっている。ユーザがこのハイパーリンク５１を選択する、例えばマウスでクリックすると、ＲＳＳリーダ・プログラム３はＷｅｂブラウザを起動する。Ｗｅｂブラウザは当該表示中の記事概要に係る記事全体をリンク先から取得し、それを表示する。ＲＳＳリーダ・プログラム３は、Ｗｅｂブラウザの起動と共に、話題抽出部２５による一連の話題抽出処理を実行する。ボタン４５はハイパーリンク５１と同等の機能を提供するものであり、ユーザがボタン４５をクリックすることによって、Ｗｅｂブラウザが起動され、一連の話題抽出処理が実行される。

従来のティッカー型ＲＳＳリーダの記事概要表示部４３においては、表示候補キュー１９に格納された記事概要が所定の時間間隔で自動的に順次表示されていた。そのため、ユーザは、ティッカー型ＲＳＳリーダが表示する固定の順番でしか記事を読むことができなかった。図４に示されたプログラム・ウインドウ４１中のボタン４７は、現在表示されている記事概要のデータを１件だけ削除し、次の記事概要を表示するためのユーザ・インタフェースである。ボタン４９は、現在表示中の記事概要のデータだけでなく、当該表示中の記事概要に関連付けられた記事概要のデータも一括削除し、削除された記事概要群に続く記事概要を表示するためのユーザ・インタフェースである。

［詳細な動作の説明］
以下、図５乃至図１６を用いて、ＲＳＳリーダ・プログラム３の詳細動作について説明する。ここでは、（１）通常モード時、（２）スリープ・モード時、（３）通常モードへの復帰時の順に説明する。

（１）通常モード時の動作について
図５に示すように、ＲＳＳリーダ・プログラム３のイベント受信部２３は、ユーザによる操作部７からの操作指示についてのイベントや、イベント受信部２３自身からの処理指示についてのイベントが発生するのを待機している（ステップＳ１）。イベントが発生すると、イベント受信部２３は当該発生イベントの内容を判定し、その内容に応じて、ＲＳＳリーダ・プログラム３内の各処理部に対して処理の実行を指示する。当該処理実行指示を受けた各処理部が実行する処理は、以下の（ａ）乃至（ｅ）に述べる処理である。

（ａ）当該発生イベントが「サイト巡回」に関するイベントの場合（ステップＳ３：Ｙｅｓルート）には、記事収集部１５が「記事ダウンロード処理」を実行する（ステップＳ５）。記事ダウンロード処理が終了すると、イベント受信部２３はイベントが発生するのを待機する（ステップＳ１）。
（ｂ）当該発生イベントが「記事概要の削除」に関するイベントの場合（ステップＳ７：Ｙｅｓルート）には、削除部２９が「記事概要削除処理」を実行する（ステップＳ９）。記事概要削除処理が終了すると、イベント受信部２３はイベントが発生するのを待機する（ステップＳ１）。
（ｃ）当該発生イベントが「記事を開く」ことに関するイベントの場合（ステップＳ１１：Ｙｅｓルート）には、話題抽出部２５が「話題抽出処理」を実行する（ステップＳ１３）。話題抽出処理が終了すると、イベント受信部２３はイベントが発生するのを待機する（ステップＳ１）。
（ｄ）当該発生イベントが「話題の削除」に関するイベントの場合（ステップＳ１５：Ｙｅｓルート）には、削除部２９が「話題削除処理」を実行する（ステップＳ１７）。話題削除処理が終了すると、イベント受信部２３はイベントが発生するのを待機する（ステップＳ１）。
（ｅ）上記以外のイベントが発生した場合（ステップＳ１５：Ｎｏルート）には、端子１を介して図１１に示すスリープ・モードの処理へ移行する。

（ａ）記事ダウンロード処理について
記事収集部１５における記事ダウンロード処理は、イベント受信部２３が「サイト巡回」に関するイベントを検出し、サイト巡回という処理実行指示を記事収集部１５に通知することにより、実行される。ここで、「サイト巡回」に関するイベントとは、ティッカー型ＲＳＳリーダではそのユーザ・インタフェースの都合上、タイマー・イベントであることが望ましい。具体的には、所定のサイトの巡回を、イベント受信部２３から記事収集部１５に指示するためのイベントである。

図６では、記事ダウンロード処理の詳細を示している。記事収集部１５は、イベント受信部２３からのサイト巡回アラームに応答して、ブックマーク１７からＵＲＬを取得し、取得したＵＲＬに基づき記事提供サイト１３からＲＳＳ文書をダウンロードし（ステップＳ２１）、ダウンロードしたＲＳＳ文書に係る記事概要のデータを表示候補キュー１９の末尾に追加する（ステップＳ２３）。巡回すべき記事提供サイト１３が複数の場合には、ステップＳ２１，Ｓ２３を繰り返し、サイトから取得したＲＳＳ文書に係る記事概要を表示候補キュー１９に順次追加する。記事提供サイト１３からのＲＳＳ文書のダウンロード処理及び当該ＲＳＳ文書に係る記事概要のキューへの追加処理が終了したら、イベント受信部２３はサイト巡回に関するイベントの発生タイミングを再設定する（ステップＳ２５）。なお、当該再設定処理では、記事収集部１５が再設定処理を実行し、イベント受信部２３に再設定処理の結果を通知するようにしてもよい。図１０（ａ）では、記事提供サイト１３から取得したＲＳＳ文書に係る記事概要が表示候補キュー１９に追加される様子を示している。

（ｂ）記事概要削除処理について
削除部２９における記事概要削除処理は、イベント受信部２３が「記事概要の削除」に関するイベントを検出し、記事概要削除という処理実行指示を削除部２９に通知することにより、実行される。ここで、「記事概要の削除」に関するイベントには、主に２つのイベントがある。１つはユーザ指示によるイベントであり、例えば、図４の説明で述べたように、ユーザがボタン４７をクリックした場合に発生するイベントがある。もう１つは、イベント受信部２３自身が発生させるタイマー・イベントの一種であり、記事表示部５に表示される内容を定期的に更新するために発生させるイベントである。

図７では、記事概要削除処理の詳細を示している。削除部２９は、イベント受信部２３からの記事概要削除に関するイベントに応答して、先ず、記事概要削除に関するイベントの発生タイミングを再設定し、再設定処理の結果をイベント受信部２３に通知する（ステップＳ５１）。なお、当該再設定処理では、イベント受信部２３が、記事概要削除に関するイベントを削除部２９に通知する前に、再設定処理を実行してもよい。次いで、削除部２９は、記事表示部５に表示されている記事概要（すなわち、表示中の記事概要）を表示候補キュー１９から削除する（ステップＳ５３）。記事概要の削除が終わると、削除部２９はイベント受信部２３に対して削除完了の旨を通知し、当該削除完了通知を受けたイベント受信部２３は、表示記事取得部２１に処理実行指示を通知する。表示記事取得部２１は、イベント受信部２３からの処理実行指示に応じて、表示候補キュー１９から新たな先頭記事概要を取得し、記事表示部５に表示する（ステップＳ５５）。

なお、ステップＳ５３における記事概要の削除において、削除部２９は、表示候補キュー１９からデータそのものを削除するのではなく、当該記事概要を表示候補キュー１９の末尾に格納してもよい。また、記事概要の破棄が完了した際に、削除部２９は、削除完了通知をイベント受信部２３に通知するのではなく、表示記事取得部２１に対して処理実行の指示を通知するようにしてもよい。

（ｃ）話題抽出処理について
話題抽出部２５における話題抽出処理は、イベント受信部２３が「記事を開く」ことに関するイベントを検出し、処理実行指示を話題抽出部２５に通知することにより、実行される。ここで「記事を開く」ことに関するイベントは、例えば図４の説明で述べたように、ユーザがハイパーリンク５１またはボタン４５をクリックすることにより発生するイベントである。イベント受信部２３は、話題抽出部２５に処理実行指示を通知する際に、記事表示部５に表示された記事概要に係るデータ、すなわち表示中の記事概要のデータを表示記事取得部２１から取得し、当該表示中の記事概要のデータを話題抽出部２５に送信する。

図８は、話題抽出処理の詳細を示している。話題抽出部２５は、Ｗｅｂブラウザを起動する。その際、イベント受信部２３から送信された表示中の記事概要の＜ｌｉｎｋ／＞タグ中に記述されているＵＲＬをＷｅｂブラウザに与える（ステップＳ３１）。Ｗｅｂブラウザは、当該ＵＲＬにアクセスし、当該表示中の記事概要についての記事文書の全体を取得し、表示する。

話題抽出部２５は、Ｗｅｂブラウザの起動と共に、以下に述べるステップＳ３３乃至Ｓ４３の処理を実行する。先ず、話題抽出部２５は、当該表示中の記事概要に関連する記事概要を表示候補キュー１９から抽出する（ステップＳ３３）。

ここで、ステップＳ３３における処理の詳細について説明する。表示中の記事概要をｘとし、表示候補キュー１９をＹとし、Ｙに格納されるｘ以外の記事概要をｙとし、記事概要ｘ及びｙの類似度を算出する類似度関数Ｓｘ（ｙ）を用いて、話題集合Ｔを次式（１）で定義する。
Ｔ＝｛ｘ｝∪｛ｙ｜Ｓｘ（ｙ）≧τ，ｙ∈Ｙ｝ …（１）
ただし、τは予め定められた類似度閾値である。式（１）は、表示中の記事概要ｘと、類似度Ｓｘ（ｙ）が所定の類似度閾値τ以上となる記事概要群とを併せた集合を話題集合と定義するものである。ステップＳ３３では、このような類似度関数の数値計算を実行し、記事概要の類似の度合いを判定している。類似度関数Ｓｘ（ｙ）は様々な形で定義することができるが、ここでは２つの例を示す。

（例１：記事属性値による類似度関数）
記事概要には、タイトル、ＵＲＬ、更新日時、作者などの記事要素が含まれており、これらの記事要素は、図３（ｂ）で述べたように、複合キー３０１または記事抽出要素３０３のいずれかに属する。これらの記事要素は、記事概要に係る記事としての特徴を表現するものである。そこで、２つの記事概要ｘ，ｙについて、同一の記事要素についての類似度（部分類似度）を算出し、部分類似度に所定の重みを乗じた後、全ての記事要素についての総和を算出する。このように算出された値を記事概要ｘ，ｙ同士の類似度とするものである。これは、次式（２）のように表現できる。
Ｓｘ（ｙ）＝Σ｛ｗｉ・δｉ（ｘ，ｙ）｝ …（２）
ただし、ｗｉは記事要素ｉの重みであり、δｉ（ｘ，ｙ）は記事要素ｉについて記事概要ｘと記事概要ｙとの部分類似度を算出する関数である。関数δｉについては、各記事要素ｉに適した関数を選択する。例えば、記事要素ｉがタイトル（＜ｔｉｔｌｅ＞要素）の場合には、記事概要ｘ，ｙの部分文字列の一致、不一致により部分類似度を算出する関数を選択する。記事要素ｉが更新日時（＜ｄｃ：ｄａｔｅ＞要素）の場合には、記事概要ｘ，ｙの更新日時の間隔により部分類似度を算出する関数を選択する。また、記事概要の記事要素が長文データとなり得るもの、例えば概要（＜ｄｅｓｃｒｉｐｔｉｏｎ＞要素）については、形態素解析により幾つかのキーワードを抽出し、抽出した各キーワードの重要度をＴＦ−ＩＤＦ（Term Frequency - Inverse Document Frequency）値として算出し、算出したＴＦ−ＩＤＦ値に基づいて記事概要ｘ，ｙをそれぞれベクトル表現に変換し、当該ベクトルの内積を類似度として算出する方法が一般的である。

（例２：リンク参照に基づく類似度関数）
記事概要の＜ｌｉｎｋ／＞タグに含まれるＵＲＬから記事本文をダウンロードすると、ダウンロードした記事本文には、他の文書を参照するハイパーリンクが含まれていることが多い。そこで、ハイパーリンクを用いた類似度関数を次式（３）で定義する。
Ｓｘ（ｙ）＝｛λ｜Ｌ({ｘ})∩Ｌ({ｙ})｜−｜Ｌ({ｘ})｜｝／｛（λ−１）｜Ｌ({ｘ})｜｝…（３）
但し、｛ｘ｝は記事概要ｘの＜Ｌｉｎｋ／＞タグ値であるハイパーリンク１つを要素とするハイパーリンク集合である。Ｌはハイパーリンク集合からハイパーリンク集合への写像であり、Ｌ（Ｘ）はハイパーリンク集合Ｘの各要素が指すＷｅｂページに含まれるハイパーリンクの集合とする。すなわち、Ｌ({ｘ})は、記事概要ｘの記事本文に含まれるハイパーリンクを全て取り出すことによって得られる。また、｜Ｌ｜は、集合Ｌの要素数（すなわち、ハイパーリンクの個数）、λは所定の係数（但しλ＞１）である。式（３）によれば、λ＝２とした場合に、記事概要ｘに対応する記事本文と記事概要ｙに対応する記事本文が共通するハイパーリンクを持たないときは、類似度は−１となる。また、記事概要ｙに対応する記事本文のハイパーリンク集合が、記事概要ｘに対応する記事本文のハイパーリンク集合と完全に一致するときは、類似度は１となる。ウェブログでは、ハイパーリンクを用いて他のＷｅｂページを引用しながら記事文書を執筆することが一般的に行われているので、このような類似度関数の定義が記事概要同士の類似度の判定に役に立つことが期待される。

ここで、例１では、記事概要で類似度を算出していたのに対し、例２では、記事概要に対応する記事本文中に含まれるリンクに基づき類似度を算出している。そのため、例２では、図８の処理ステップＳ３１，Ｓ３３は、例えば以下に述べる手順となる。

（例２の場合の手順）
話題抽出部２５は、表示中の記事概要についての記事本文を表示するために、Ｗｅｂブラウザを起動し、記事概要の＜ｌｉｎｋ／＞タグに記されたＵＲＬにアクセスさせる。また、表示候補キュー１９に格納されている全記事概要に含まれるＵＲＬを読み出し、当該ＵＲＬにアクセスして、対応する記事本文を取得し、記憶装置に格納する（ステップＳ３１）。そして、話題抽出部２５は、取得した記事本文について、上の例２で示した類似度の算出を行い、ユーザが選択した記事概要と関連する記事概要を抽出する（ステップＳ３３）。

なお、例２において、ハイパーリンク集合Ｌ（ｘ）は、多階層的にハイパーリンクを含むことも可能である。すなわち、Ｘ１＝Ｌ({ｘ})に加え、Ｘ２＝Ｌ（Ｘ１），Ｘ３＝Ｌ（Ｘ２）・・・もリンク参照に基づく類似度の算出時に考慮するという方式を採用しても良い。具体的には、
Ｌ⁽ⁱ⁾(Ｘ)＝Ｌ（Ｘ）
Ｌ⁽ⁿ⁾(Ｘ)＝Ｌ（Ｌ^n-1），（ｎ≧１）
と定義し、さらに、

と定義する。式（３）においてＬ({ｘ})の代わりに

を用いる方法などである。この場合には、最初の記事概要ｘに含まれるハイパーリンク集合Ｌ({ｘ})及びさらにリンクを辿ることにより得られるＷｅｂページに含まれるハイパーリンク集合Ｌ⁽²⁾({ｘ})，Ｌ⁽³⁾({ｘ})，・・・まで辿る際のハイパーリンクの階層による重み付けが反映されるように、類似度関数Ｓｘ（ｙ）を変形することが望ましい。

（他の例）
さらに他の方法として、記事本文ｘ中の他のＷｅｂページ又は記事からの部分コピーによる引用部分を手がかりに、引用元のＷｅｂページ又は記事を同定し、これをＬ（ｘ）に含める方法や、ウェブログにおいて特徴的なトラックバック機能を用いて作成した参照を扱う方法なども可能である。

図８の説明に戻り、話題抽出部２５は、表示中の記事概要及びステップＳ３３の処理により抽出された関連記事概要に、図２、図３の説明で述べたような話題要素を付与することにより、表示中の記事概要及び関連記事概要で話題集合を生成し（ステップＳ３５）、生成された話題集合を話題データベース２７に追加登録する（ステップＳ３７）。さらに、表示中の記事概要を表示候補キュー１９の先頭に挿入し（ステップＳ３９）、挿入された先頭記事概要の次に、関連記事概要を挿入する（ステップＳ４１）。この際、当該関連ＲＳＳ文書を先頭ＲＳＳ文書との関連度に基づきソートしておけば、ユーザは、関連記事概要を連続して読むことができる。そして、挿入された関連ＲＳＳ文書の末尾にマーカーを挿入する（ステップＳ４３）。

図８に示した話題抽出処理により、表示候補キュー１９の内部では記事概要の移動が発生する。このキュー移動の様子を図１０（ｂ）に示す。ユーザが表示候補キュー１９の先頭記事Ａを開いた場合、話題抽出部２５は、図１０（ｂ）の上段のように順次蓄積された記事概要Ａ，Ｚ１，Ｚ２，Ａ３，Ｚ３，Ａ１，Ｚ４，Ａ２の中から、先頭記事概要Ａに関連する記事概要を抽出する。抽出処理の結果、記事概要Ａ１が最も先頭記事概要Ａに類似し、次いで記事概要Ａ２，Ａ３の順に類似していると判定され、その他の記事概要Ｚ１，Ｚ２，Ｚ３，Ｚ４は類似しないと判定された場合、話題抽出部２５は、先ず、先頭記事概要Ａを表示候補キュー１９の先頭に配置し、次いで、Ａ１，Ａ２，Ａ３の順に記事を表示候補キュー１９に挿入する。このように、記事概要Ａ１乃至Ａ３は類似度でソートされたので、その並び順は元の並び順とは異なっている。一方、Ｚ１乃至Ｚ４の並び順は、元の並び順のままである。そして、記事概要Ａ及びＡ１乃至Ａ３が一連の話題集合であることを示すために、話題抽出部２５は、記事概要Ａ３の直後にマーカー６１を挿入している。マーカー６１は、話題集合に含まれる記事概要とその他の記事概要との境界を示すものであり、後に述べる話題削除処理では、このマーカー６１を用いて当該話題集合に含まれる記事概要を表示候補キュー１９から削除する処理が実行される。

（ｄ）話題削除処理について
削除部２９は、上で述べた記事削除処理だけでなく、話題削除処理も行う。話題削除処理は、イベント受信部２３が「話題の削除」に関するイベントを検出し、話題削除アラームという処理実行指示を削除部２９に通知することにより、実行される。ここで「話題の削除」に関するイベントは、図４の説明で述べたように、ユーザがボタン４９をクリックした場合に発生するイベントである。すなわち、ユーザがボタン４９をクリックすることにより、話題削除処理が実行される。

図９には、話題削除処理の詳細を示している。また、図１０（ｃ）に、話題削除処理による表示候補キュー１９の変化の様子を示している。図９において、削除部２９は、イベント受信部２３からの話題削除に関するイベントに応答して、表示候補キュー１９の先頭からマーカー直前までの記事概要を一括削除する（ステップＳ６１）。次いで、表示候補キュー１９の新たな先頭記事概要の直後にマーカーを挿入する（ステップＳ６３）。図１０（ｃ）には、記事概要Ａ，Ａ１，Ａ２，Ａ３が削除される様子が示されている。話題削除の際には、削除部２９は、マーカー６１の位置を確認し、当該マーカー６１の直前の記事概要Ａ３までを削除している。これにより、記事概要Ｚ１がキューの先頭に配置される。さらに表示候補キュー１９の新たな先頭記事概要Ｚ１の直後にマーカー６１が挿入されている様子が図１０（ｃ）に示されている。図９に戻り、新たな先頭記事概要の記事概要を記事表示部５に表示する（ステップＳ６５）。

なお、ステップＳ６１において、上で述べた記事削除処理と同様に、削除部２９は、必要に応じて記事概要削除に関するイベントの発生タイミングを再設定してもよい。また、表示候補キュー１９の先頭からマーカー６１直前までの記事概要の削除において、表示候補キュー１９からデータそのものを削除するのではなく、削除部２９は、当該一連の記事概要を表示候補キュー１９の末尾に格納してもよい。その際、削除部２９は、当該一連の記事概要に所定のデータ、例えば既読フラグを付与し、所定の時間が経過した後に、既読フラグが付与された記事概要を表示候補キュー１９から削除してもよい。

（ｅ）スリープ・モードへの移行について
以上の（ａ）乃至（ｄ）で述べた処理が、ＲＳＳリーダ・プログラム３の通常モードにおける処理の詳細である。イベント受信部２３は、上で述べたイベントのいずれでもないイベントを受信した場合（例えば一定時間ユーザからの操作がされなかったことに応じて発生するタイマー・イベントを検出した場合、ユーザが操作部７からＲＳＳリーダ・プログラム３のウィンドウの最小化を指示したことにより発生するユーザ・イベントを検出した場合）（ステップＳ１５：Ｎｏルート）には、端子１を介して図１１に示すスリープ・モードの処理へ移行する。

（２）スリープ・モード時の動作について
図１１では、スリープ・モード時におけるＲＳＳリーダ・プログラム３の動作の基本的な流れを示している。先ず、ＲＳＳリーダ・プログラム３は、動作モードの切り替えを行う。詳細には、イベント受信部２３は、記事収集部１５に対して、動作モードをスリープ・モードの動作に切り替える旨を通知する。記事収集部１５は当該通知に応じて、サイトの巡回処理、すなわちＲＳＳ文書の取得処理を一時停止する。さらに、一時停止された処理が再開されたときに、取得したＲＳＳ文書に係る記事概要を表示候補キュー１９に格納するのではなく、話題分類部３３に引き渡すように、動作モードを切り替える。次いで以下の（ｆ）に述べる処理が実行される。

（ｆ）話題再構成部３１は話題集合再構成処理を実行する（ステップＳ７１）。本処理については、後に詳しく述べる。なお、話題再構成部３１による話題再構成処理の実施は任意であって、実行しなくとも良い。話題集合再構成処理が終わると、イベント受信部２３は、イベントが発生するのを待機する（ステップＳ７３）。イベントが発生すると、イベント受信部２３は当該発生イベントの内容を判定し、その内容に応じて、ＲＳＳリーダ・プログラム３内の各処理部に対して処理の実行を指示する。当該処理実行指示を受けた各処理部が実行する処理は、以下の（ｇ）又は（ｈ）に述べる処理である。

（ｇ）当該発生イベントが「サイト定期巡回」に関するイベントの場合（ステップＳ７５：Ｙｅｓルート）には、記事収集部１５及び話題分類部３３が、一連の記事分類処理を実行する（ステップＳ７７乃至Ｓ９１）。一連の記事分類処理が終了すると、イベント受信部２３は、イベントが発生するのを待機する（ステップＳ７３）。

（ｈ）当該発生イベントが「通常モードへの復帰」に関するイベントの場合（ステップＳ７５：Ｎｏルート）には、分類結果取得部３５が、分類結果表示処理を実行する（ステップＳ９３）。本処理については、後に詳しく述べる。次いで、ＲＳＳリーダ・プログラム３は動作モードの第２の切り替えを行う。詳細には、イベント受信部２３が動作モードを通常モードに切り替える旨を記事収集部１５に通知し、記事収集部１５が当該通知に応じて動作モードを切り替える。すなわち、取得記事概要を話題分類部３３に引き渡していた記事収集部１５の動作が、取得記事概要を表示候補キュー１９に格納する動作へと切り替わる。そして、端子２を介して図５に示す通常モードの処理へ移行する。

（ｆ）話題集合再構成処理について
図１２では、話題集合再構成処理を模式的に示している。話題データベース２７には、図８の説明で述べた話題抽出処理によって、多くの話題集合が格納される。そこで、ＲＳＳリーダ・プログラム３の動作がスリープ・モードに移行したのを契機に、話題再構成部３１は、話題集合の再構成を行う。図１２には、話題集合Ａ（２００ａ）および話題集合Ｂ（２００ｂ）が、話題集合再構成処理によって話題集合Ｄ（２００ｄ）となった様子が示されている。例えば、話題集合Ａが「スマトラ沖地震」という話題に関する記事の集合であり、話題集合Ｂが「新潟地震」という話題に関する記事の集合である場合、これらの話題集合は、「地震」、もしくは「災害」という共通性がある。そこで、話題集合Ａ，Ｂに含まれる記事の話題要素を変更する。すなわち、話題集合Ａに含まれる記事概要に付与された話題要素「スマトラ沖地震」と、話題集合Ｂに含まれる記事概要に付与された話題要素「新潟地震」とを、新たな話題要素「災害」に更新する。これにより、複数の話題が１つの話題に縮退される。図１４（ａ）及び（ｂ）には、１番目と２番目のレコードの話題要素３０５が、話題集合再構成処理により「災害」に更新されている様子が示されている。他にも、話題集合再構成処理により、３番目と４番目のレコードの話題要素３０５が「スポーツ」に更新され、５番目と６番目のレコードの話題要素３０５が「経済」に更新されている様子が示されている。このように話題集合を上位概念の話題集合に纏める方法は、一般に、クラスタリング技術として知られている。

図１３では、話題集合再構成処理の詳細手順を示している。話題再構成部３１は、イベント受信部２３からスリープ・モードに移行した旨の通知を受信することにより、話題データベース２７から話題集合を取得し（ステップＳ１０１）、取得した複数の話題集合が相互に関連するか否かを判定し、相互に関連する話題集合を１つの話題集合に縮退させ、新たな話題集合を定義し（ステップＳ１０３）、話題データベース２７を更新する（ステップＳ１０５）。話題データベース２７の更新が終わったら、記事収集部１５がサイト巡回をすることができるようにする。ただし、スリープ・モード時に記事提供サイト１３から取得したＲＳＳ文書に係る記事概要は、表示候補キュー１９に格納されずに、話題分類部３３に引き渡される。

なお、話題集合の再構成には、主に２つの方法が考えられる。１つは、話題集合のレベルで話題集合の再構成を行う方法である。この方法は、ある話題集合に含まれる記事概要が別の話題集合に移動しない方法でもあり、図１２等の説明で述べた方法である。もう１つは、話題データベース２７を記事概要のレベルで全体的に再構成する方法であり、場合により、記事概要の話題集合間の移動が発生する。

（ｇ）記事分類処理について
図１１に戻り、一連の記事分類処理（ステップＳ７７乃至Ｓ９１）について説明する。記事収集部１５は、イベント受信部２３からのサイト巡回指示に応答して、ブックマーク１７を参照し、記事提供サイト１３からＲＳＳ文書をダウンロードし、取得したＲＳＳ文書に係る記事概要を話題分類部３３に引き渡す（ステップＳ７７）。話題分類部３３は、記事収集部１５から引き渡された記事概要を所定の領域（例えば、記憶装置の所定の領域）に記憶し、当該領域に記事概要が残っているか否かを判定することにより、分類判定していない記事概要があるか否かを判定する（ステップＳ７９）。当該領域に記事概要が残っている、すなわち分類判定していない記事概要がある場合（ステップＳ７９：Ｙｅｓルート）には、話題分類部３３は、当該領域から１つの記事概要を取得し、当該記事概要と話題データベース２７に格納されている話題集合との関連度を算出する（ステップＳ８１）。関連度の算出の結果、記事概要が話題データベース２７に格納された話題集合のいずれかに分類できると判定された場合（ステップＳ８３：Ｙｅｓルート）には、話題分類部３３は、分類先の話題集合についての話題要素を当該記事概要に付与して話題データベース２７に登録し（ステップＳ８５）、さらに当該記事概要を表示候補キュー１９に登録する（ステップＳ８７）。そして、記憶装置の所定の領域に記憶された当該記事概要を削除する。

記事概要がいずれの話題集合にも分類できない場合（ステップＳ８３：Ｎｏルート）には、話題分類部３３は、当該記事概要を破棄する（ステップＳ８９）。そして、当該記事概要を記憶装置の所定の領域から削除する。話題分類部３３は、記憶装置の所定の領域に記事概要がある限り（ステップＳ７９：Ｙｅｓルート）、ステップＳ８１乃至Ｓ８９の処理を実行し、逐次、記憶装置の所定の領域から当該記事概要を削除する。当該領域から記事概要がなくなったら、すなわち分類判定していない記事概要がなくなったら（ステップＳ７９：Ｎｏルート）、話題分類部３３はサイト巡回に関するイベントを再設定し（ステップＳ９１）、イベント受信部２３はイベントが発生するのを待機する（ステップＳ７３）。

なお、サイト巡回イベントの再設定処理については図６でも述べているので、説明を省略する。

ここで、ステップＳ８１における処理の詳細について説明する。話題データベース２７に格納されている話題集合をＣｋ（ｋ＝１，２，…，ｎ）とするとき、ＲＳＳ文書を話題集合に分類する処理では、サイトから取得したＲＳＳ文書に係る記事概要ｘを、次式（４）：
Ｃ＝ｆ（ｘ），Ｃ∈｛Ｃｋ｜ｋ＝１，２，…，ｎ｝ …（４）
によって、いずれかのＣｋに割り当てる問題を扱う。このような問題は、分類問題として知られており、ｆ（ｘ）は分類関数と呼ばれている。

また、分類関数ｆ（ｘ）を話題データベース２７から構成する技術が知られている。例えば、ＮＮ法（Nearest Neighbor Method）では、上で述べた類似度関数Ｓｘ（ｙ）を用いて、最も類似度の高い記事概要ｙが属する話題集合に記事概要ｘを割り当てる。ＮＮ法については、"S. Chakrabarti,Mining the Web--Discovering knowledge from Hypertext Data--,pp.133-136,Morgan Kaufmann Pub.(2003)"を参照のこと。

また、次のような分類関数を構成する技術も公知である。
［ｐ１，ｐ２，…，ｐｋ］＝ｆ（ｘ），
Ｃ∈｛Ｃｋ｜ｋ＝１，２，…，ｎ｝ …（５）
この分類関数ｆ（ｘ）は、記事概要ｘをＣｋに割り当てる際の確信度（すなわち、確率）ｐｋを算出するものである。そして、ｐｋが最大となるＣｋにデータｘを分類する。本実施の形態における話題分類部３３では、確信度の最大値ｐmaxが一定以下の場合には、分類の判断を保留する。すなわち、予め定められた値（σ）について、ｐmax≧σのときには記事概要をｐＫ＝ｐmaxとなるＣｋに割り当てる。一方、ｐmax＜σの場合には、記事概要はいずれの話題にも割り当てられない。

なお、図１４（ｃ）に示されているレコード（すなわち、記事概要）は、ＲＳＳリーダ・プログラム３がスリープ・モードに移行した後に、図１１のステップＳ８５で示した処理が行われ、話題データベース２７に登録されたものである。後で述べる分類結果表示処理において、分類結果取得部３５が、これらのレコードをスリープ・モードに移行した後に登録されたもの（すなわち、新着記事）として認識するために、話題データベース２７の所定の領域に、スリープ・モードに移行した日時が記憶されていることが望ましい。または、話題分類部３３が話題データベース２７への登録処理を行う際に、図１４（ｃ）に示すレコードに所定のフラグ（例えば、新着フラグ）を付与する方式もある。新着フラグを付与する方式の場合には、上で述べた話題集合再構成処理で、話題再構成部３１が、新着フラグを初期化する必要がある。

図１４（ａ）乃至（ｃ）で、ＲＳＳ文書に係る記事概要を表形式で示したように、話題データベース２７では、記事概要をレコードとしてリレーショナル・データベースで管理する方法もある。図１４では、複合キーとなる＜ｌｉｎｋ／＞カラム（３０１ａ）及び＜ｄｃ：ｄａｔｅ／＞カラム（３０１ｂ）と、＜ｗａｄａｉ／＞カラム（３０５）と、＜ｔｉｔｌｅ／＞カラムのみを示している。この一方で、話題データベース２７では、図３（ａ）に示したようなＲＳＳ文書をファイル単位で管理する、すなわち、ＸＭＬファイルのまま管理する方法もある。

（３）通常モードへの復帰について
（ｈ）分類結果表示処理について
分類結果取得部３５における分類結果表示処理は、イベント受信部２３が「通常モードへの復帰」に関するイベントを検出し、処理実行指示を分類結果取得部３５に通知することにより、実行される。「通常モードへの復帰」に関するイベントは、ユーザが操作部７を用いて何らかの指示をしたことにより発生するユーザ・イベント、例えば記事表示の指示をしたことにより発生するイベントや、最小化されたプログラム・ウィンドウを元のサイズに戻す指示をしたことにより発生するイベントである。

図１５では、分類結果表示処理の詳細を示している。分類結果取得部３５は、イベント受信部２３からの処理実行指示に応じて、話題データベース２７から全ての記事概要を取得する（ステップＳ１１１）。そして、取得した記事概要に付与された話題要素に従って、話題毎にグループ化し、さらに各話題について、記事概要を新着記事と関連記事とに整理する。ここでいう「新着記事」とは、スリープ・モード中に話題データベース２７に登録された記事概要である。また、「関連記事」とは、スリープ・モードに移行する前から話題データベース２７に登録されている記事概要である。記事概要が新着記事であるか、関連記事であるかを判定する際には、話題データベース２７の所定の領域に記憶されたスリープ・モードへの移行日時を参照して判定する方式でもよいし、記事概要に付与された新着フラグを参照する方式でもよい。この際、記事概要の更新日時要素（＜ｄｃ：ｄａｔｅ／＞タグ）で記事概要をソートしてもよい（ステップＳ１１３）。そして、分類結果表示部９にその結果を表示する（ステップＳ１１５）。

なお、ステップＳ１１１で記事概要を取得する際に、分類結果取得部３５は、全ての記事概要を取得するのではなく、先ず、新着記事である記事概要を取得し、次いで、当該新着記事の関連記事である記事概要を取得してもよい。このような取得処理によって、関連記事のみで構成される話題集合については分類結果表示部９に表示されないので、ユーザはより効果的に新着記事を参照することができるようになる。

図１６では、分類結果の表示例を示している。話題データベース２７から取得した記事概要は、分類結果表示画面７１の話題表示部７３ａ，７３ｂ，７３ｃに示すように、話題毎に整理されて表示される。話題表示部の各々には、話題名が話題名表示部７５ａ，７５ｂ，７５ｃに示すように表示される。さらに、各話題表示部には、新着記事表示部７７ａ，７７ｂ，７７ｃに示すように、記事概要が新着記事として表示されている。同様に、関連記事表示部７９ａ，７９ｂ，７９ｃに示すように、記事概要が関連記事として表示されている。分類結果表示画面７１の新着記事表示部７７の各々に表示された記事概要は、図１４（ｃ）に示した記事概要に相当し、関連記事表示部７９の各々に表示された記事概要は、図１４（ｂ）に示した記事概要に相当している。

なお、記事収集部１５が表示候補キュー１９に記事概要を格納する時点においては、表示候補キュー１９における記事概要の並び順は、記事収集部１５が当該記事概要に対応するＲＳＳ文書を記事提供サイト１３から取得した順であって、記事概要の相互の関連性とは無関係である。そこで、本発明の第１の実施形態に係るＲＳＳリーダ・プログラム３は、ユーザによって、記事表示部５に表示中の記事概要についての記事本文を取得させるための操作がされたことを契機に、話題集合を生成し、さらに表示候補キュー１９に格納されている記事概要の並び順の変更を行うようにしている。この並び順の変更により、表示中の記事概要に関連する記事概要についても表示順番は前倒しになるので、ユーザは、効率的に記事概要を知得することができるようになる。

また、スリープ・モード中には、話題分類部３３の処理で話題データベース２７における話題集合のいずれにも分類されなかった記事概要は破棄されるため、ユーザは、興味のない記事概要の中から興味のある記事概要を見つける作業を行わずに済むようになる。従って、ユーザは、効率的に記事概要を知得することができるようになる。

［本発明の第１の実施の形態の変形例］
話題抽出部２５が、表示中の記事概要及びこれに関連する記事概要を話題データベース２７に登録する際に、新たな話題集合として話題データベース２７に登録するのではなく、話題データベース２７上に既に定義されている話題集合との類似度を判定し、既存の話題集合に追加登録するような構成にしてもよい。

［本発明の第２の実施の形態］
次に、図１７乃至図２７を用いて、本発明の第２の実施の形態について説明する。図１７に示すように、本発明の第２の実施の形態に係るコンピュータ１０１は、メール・クライアント型のＲＳＳリーダ・プログラム１０３を実行させる装置であって、ＲＳＳリーダ・プログラム１０３並びに入出力インタフェースとしての記事一覧表示部１０５ａ、選択記事表示部１０５ｂ、操作部１０７及び分類結果表示部１０９を含む。コンピュータ１０１は、例えばインターネット等のネットワーク１１１を介して記事提供サイト１１３に接続されている。コンピュータ１０１によって実行されるＲＳＳリーダ・プログラム１０３は、当該記事提供サイト１１３からＲＳＳ文書を取得し、さらに取得したＲＳＳ文書に係る記事概要を管理し、必要に応じて１つまたは複数の記事概要を１つのグループに統合するプログラムである。つまり、ＲＳＳリーダ・プログラム１０３は、１件または複数の記事概要を１つの集合にグループ化して管理している。ＲＳＳリーダ・プログラム１０３は、記事収集部１１５、ブッマーク１１７、表示記事取得部１２１（記事一覧取得部１２１ａ、選択記事取得部１２１ｂ）、イベント受信部１２３、話題抽出部１２５、話題データベース１２７、参照記録部１２９、話題再構成部１３１、話題分類部１３３、分類結果取得部１３５、記事データベース１３７、表示候補スプール１３９、フィルタリング部１４１及びフォルダ情報１４３を含む。なお、「グループ化」、「話題集合」、「話題要素」などの意味については、本発明の第１の実施の形態で述べたことと同様であるので、説明を省略する。

ここで、図１８を用いてＲＳＳリーダ・プログラム１０３のプログラム・ウィンドウ１５１について説明する。プログラム・ウィンドウ１５１は、フォルダ表示部１５３、記事一覧表示部１６１及び選択記事表示部１６３を含む。フォルダ表示部１５３は、さらにブックマーク１１７に登録されたサイト（ブックマーク・サイト・フォルダ１６５ａ乃至１６５ｘ）を配下に格納するサイト・フォルダ表示部１５５、ユーザ定義フォルダ１６７ａ及び１６７ｂを配下に格納するユーザ定義フォルダ表示部１５７、及び話題フォルダ１６９ｃ及び１６９ｄを配下に格納する話題フォルダ表示部１５９を含む。

ユーザがフォルダ表示部１５３からフォルダ（１６５，１６７，１６９のいずれかのフォルダ）を選択する（すなわち、クリックする）と、当該選択フォルダに属する記事概要の一覧が記事一覧表示部１６１に表示される。さらに、ユーザが記事一覧表示部１６１に表示されている記事概要の１つを選択すると、選択記事表示部１６３に当該選択に係る記事概要の詳細の一部または全てが表示される。

図１８では、ユーザがブックマーク・サイト・フォルダ１６５ｘ「ｘｙｚ．ｃｏｍ」を選択し、さらに記事一覧表示部１６１に一覧表示された最上段の記事概要を選択し、その結果、ユーザが選択した記事概要の詳細の一部が選択記事表示部１６３に表示されている様子を示している。また、記事一覧表示部１６１には、ユーザが記事概要を視認しやすいように、その上部に記事要素の要素名が表示されている。図１８では、「更新日」（１７１ａ）、「話題」（１７１ｂ）、「タイトル」（１７１ｃ）、「チャンネル」（１７１ｄ）、「カテゴリ」（１７１ｅ）と、要素名が表示されている。これらの記事要素名を表示している部分は、ユーザ指示を受け付けるボタンとなっていて、ユーザがボタン１７１ａ乃至１７１ｅのいずれか１つをクリックすることにより、記事一覧表示部１６１に表示されている記事概要がボタン・クリックに係る記事要素によりソートされる。図１８では、更新日で、新着順にソートされている様子が示されている。また、記事データに話題要素が付されている場合には、その内容が表示される。

選択記事表示部１６３には、図３（ａ）に示したＲＳＳ文書３００の内容が記事概要の詳細として表示されている。１７５にはＲＳＳ文書３００の＜ｔｉｔｌｅ／＞要素の内容がハイパーリンク表示されていて、そのリンク先は＜ｌｉｎｋ／＞要素の内容である。ユーザがハイパーリンク１７５をクリックすると、選択記事表示部１６３には、当該リンク先から取得した記事文書の全体が表示される。１７７には＜ｄｃ：ｄａｔｅ／＞要素の内容が表示されていて、１７９には＜ｄｅｓｃｒｉｐｔｉｏｎ／＞要素の内容が表示されている。当該ＲＳＳ文書３００に話題要素（＜ｗａｄａｉ／＞要素）が付与されている場合には、１７３に示すように、話題情報として「株・相場」のような文言が表示される。

なお、図１８については、プログラム・ウィンドウ１５１の表示に関する出力インタフェース、フォルダ表示部１５３に表示されたフォルダについて「フォルダの選択」をするための入力インタフェース、記事一覧表示部１６１に表示された記事概要について「記事概要の選択」をするための入力インタフェースといった一部のユーザ・インタフェースを説明しているに過ぎない。しかし、「話題を削除」するためのボタン４９と同等の機能を実現させるボタンなどのユーザ・インタフェースを提供することも可能である。

図１７に戻り、記事収集部１１５は、ブックマーク１１７を参照し、記事提供サイト１１３からＲＳＳ文書を取得し、取得したＲＳＳ文書に係る記事概要を記事データベース１３７に登録する。スリープ・モード時には、取得したＲＳＳ文書に係る記事概要を話題分類部１３３に引き渡す。その他の記事収集部１１５の機能については、本発明の第１の実施の形態で説明したことと同様であるので、説明を省略する。

表示候補スプール１３９は、記事一覧表示部１０５ａや選択記事表示部１０５ｂに記事概要が表示されるときに、表示対象の記事概要を一時的に格納するための記憶領域である。記事一覧取得部１２１ａは、表示候補スプール１３９から全ての記事概要を取得し、記事一覧表示部１０５ａに一覧表示する。その際、ＲＳＳ文書の記事要素のいずれかの要素により、記事概要がソートされるようにするのが好ましい。選択記事取得部１２１ｂは、記事一覧表示部１０５ａに表示されている記事概要から１件の記事概要が選択されたときに、当該記事概要を表示候補スプール１３９から取得し、または記事一覧取得部１２１ａが記事概要を保持している場合には、記事概要を記事一覧取得部１２１ａから取得し、図１８の説明で述べたような所定のフォーマットで記事概要の内容を選択記事表示部１０５ｂに表示する。

イベント受信部１２３は、イベントを受け付け、受け付けたイベントを判定して、各処理部に対して処理の実行を指示する。このようなイベントには、ユーザが操作部１０７を用いてＲＳＳリーダ・プログラム１０３に対して指示することにより発生するユーザ・イベントがある。また、イベント受信部１２３は、各処理部に対して処理実行を指示する際、必要に応じて、記事一覧表示部１０５ａに表示中の記事概要一覧に係るデータであって、ユーザが選択した記事概要に係るデータを記事一覧取得部１２１ａから取得する。ユーザによる選択が１件の記事概要の選択であれば、イベント受信部１２３は当該１件の記事概要に係るデータを取得し、また、ユーザによる選択が複数件の記事概要の選択であれば、イベント受信部１２３は当該記事概要の各々に対応するデータを取得する。

イベント受信部１２３が、「フォルダを選択」することに関するイベントの発生を検出し、フィルタリング部１４１に対して当該発生イベントに関する処理実行指示を通知すると、フィルタリング部１４１は、当該通知に応答してフォルダ情報１４３を参照し、選択されたフォルダ配下のブックマークフォルダに属する記事概要を、記事データベース１３７から取り出し、表示候補スプール１３９に格納する。

イベント受信部１２３が「記事を開く」ことに関するイベントの発生を検出し、話題抽出部１２５に対して当該発生イベントに関する処理実行指示の通知をすると、話題抽出部１２５は、表示候補スプール１３９に格納済みの記事概要を用いて話題抽出処理を実行する。ここでの話題抽出処理も、基本的には本発明の第１の実施の形態で述べた話題抽出処理と同様であり、話題抽出部１２５は、生成された話題集合を話題データベース１２７に登録し、ユーザにより選択された記事概要から順番に当該話題集合に含まれる記事概要が記事一覧表示部１０５ａに表示されるように、当該話題集合に含まれる記事概要のデータを表示候補スプール１３９の先頭に格納する。なお、本発明の第２の実施の形態における「記事を開く」ことに関するイベントについては、後で述べる。

参照記録部１２９は、ユーザからの既読指示（操作部１０７からの指示）イベントが発生した旨がイベント受信部１２３から通知されたことに応じて、表示候補スプール１３９において既読指示イベントに係る記事概要に対して既読フラグを付与する。また、参照記録部１２９は、必要に応じて、記事データベース１３７において同じ記事概要に対して既読フラグを付与する。第１の実施の形態と同様に、既読フラグの付与には、記事概要への付与と共に、指定された話題に含まれる記事概要への付与をも含まれる。

話題再構成部１３１は、スリープ・モードへの移行時に、話題データベース１２７に格納されている話題集合の再構成を行い、さらに、再構成された話題集合の各々に対応する話題フォルダ１６９を生成するために、当該話題集合に係るデータ（例えば、話題要素）をフォルダ情報１４３の話題フォルダ領域に格納する。

話題分類部１３３は、記事収集部１１５から引き渡された記事概要が話題データベース１２７に格納されている話題集合のいずれかに分類可能か否かを判定する。分類可能な場合には、話題分類部１３３は、分類先の話題集合に係る話題要素を当該記事概要に付与し、話題要素が付与された記事概要を話題データベース１２７に登録する。同時に、当該話題要素が付与された記事概要を記事データベース１３７に登録する。分類できない場合には、話題分類部１３３は、話題データベース１２７には当該記事概要を登録せず、記事データベース１３７のみに登録する。

分類結果取得部１３５については、上で述べた分類結果取得部３５と全く同様であるので、説明を省略する。なお、記事の未読／既読については管理され、表示されるが、この点については従来と同じであるから、ここではこれ以上述べない。

［詳細な動作の説明］
以下、図１９乃至２７を用いて、ＲＳＳリーダ・プログラム１０３の詳細動作について説明する。ここでは、（４）通常モード時、（５）スリープ・モード時の順に説明する。なお、（６）通常モードへの復帰時の詳細な説明については、本発明の第１の実施の形態と全く同様であるので、説明を省略する。

（４）通常モード時の動作について
図１９に示すように、ＲＳＳリーダ・プログラム１０３のイベント受信部１２３は、ユーザによる操作部１０７からの操作指示についてのユーザ・イベントや、イベント受信部１２３自身からの処理指示についてのイベントが発生するのを待機している（ステップＳ１２１）。イベントが発生すると、イベント受信部１２３は当該発生イベントの内容を判定し、その内容に応じて、ＲＳＳリーダ・プログラム１０３内の各処理部に対して処理の実行を指示する。当該処理実行指示を受けた各処理部が実行する処理は、以下の（ｉ）乃至（ｎ）に述べる処理である。

（ｉ）当該発生イベントが「サイト巡回」に関するイベントの場合（ステップＳ１２３：Ｙｅｓルート）には、記事収集部１１５が「第２記事ダウンロード処理」を実行する（ステップＳ１２５）。第２記事ダウンロード処理が終了すると、イベント受信部１２３はイベントが発生するのを待機する（ステップＳ１２１）。
（ｊ）当該発生イベントが「フォルダを選択」に関するイベントの場合（ステップＳ１２６：Ｙｅｓルート）には、フィルタリング部１４１が「記事フィルタリング処理」を実行する（ステップＳ１２７）。記事フィルタリング処理が終了すると、イベント受信部１２３はイベントが発生するのを待機する（ステップＳ１２１）。
（ｋ）当該発生イベントが「選択記事概要に対する既読フラグ付与」に関するイベントの場合（ステップＳ１２８：Ｙｅｓルート）には、参照記録部１２９が「記事概要に対する既読フラグ付与処理」を実行する（ステップＳ１２９）。記事概要に対する既読フラグ付与処理が終了すると、イベント受信部１２３はイベントが発生するのを待機する（ステップＳ１２１）。
（ｌ）当該発生イベントが「記事を開く」ことに関するイベントの場合（ステップＳ１３１：Ｙｅｓルート）には、話題抽出部１２５が「第２話題抽出処理」を実行する（ステップＳ１３３）。第２話題抽出処理が終了すると、イベント受信部１２３はイベントが発生するのを待機する（ステップＳ１２１）。
（ｍ）当該発生イベントが「選択話題に対する既読フラグ付与」に関するイベントの場合（ステップＳ１３５：Ｙｅｓルート）には、参照記録部１２９が「話題に対する既読フラグ付与処理」を実行する（ステップＳ１３７）。話題に対する既読フラグ付与処理が終了すると、イベント受信部１２３はイベントが発生するのを待機する（ステップＳ１２１）。
（ｎ）上記以外のイベントが発生した場合（ステップＳ１３５：Ｎｏルート）には、端子３を介して図２５に示すスリープ・モードの処理へ移行する。
なお、本発明の第２の実施の形態における発生イベントの内容については、以下の（ｉ）乃至（ｎ）の処理手順の詳細な説明において、詳しく述べる。

（ｉ）第２記事ダウンロード処理について
記事収集部１１５における第２記事ダウンロード処理は、イベント受信部１２３が「サイト巡回」に関するイベントを検出し、サイト巡回という処理実行指示を記事収集部１１５に通知することにより、実行される。ここで、本発明の第１の実施の形態における「サイト巡回」に関するイベントがタイマー・イベントのみであったのに対し、本発明の第２の実施の形態における「サイト巡回」に関するイベントには、ユーザが操作部１０７を用いてサイト巡回を指示することにより発生するユーザ・イベントも含まれる。

図２０Ａのフローチャートに示すように、記事収集部１１５は、イベント受信部１２３からのサイト巡回に関するイベントに応答して、ブックマーク１１７からＵＲＬを取得し、取得したＵＲＬに基づき記事提供サイト１１３からＲＳＳ文書をダウンロードし（ステップＳ１４１）、ダウンロードしたＲＳＳ文書に係る記事概要を記事データベース１３７に追加する（ステップＳ１４３）。巡回すべき記事提供サイト１１３が複数の場合には、ステップＳ１４１，Ｓ１４３を繰り返す。記事提供サイト１１３からのＲＳＳ文書のダウンロード処理及びＲＳＳ文書に係る記事概要の記事データベース１３７への追加処理が終了したら、イベント受信部１２３はサイト巡回に関するイベントの発生タイミングを再設定する（ステップＳ１４５）。なお、当該再設定処理では、記事収集部１１５が再設定処理を実行し、イベント受信部１２３に再設定処理の結果を通知するようにしてもよい。また、サイト巡回に関するイベントについては、「（ａ）記事ダウンロード処理」で詳細に述べているので、説明を省略する。

（ｊ）記事フィルタリング処理について
フィルタリング部１４１により実行される記事フィルタリング処理については図２０Ｂに示す。イベント受信部１２３が「フォルダの選択」に関するイベントを検出し、ユーザによって選択された記事概要及び選択されたフォルダに関するデータを含む処理実行通知を通知することに応答して、フィルタリング部１４１は、フォルダ情報１４３を参照して、選択されたフォルダ配下のブックマークフォルダを取得する（ステップＳ１４６）。そして、フィルタリング部１４１は、取得したブックマークフォルダに属する記事概要を記事データベース１３７から取得する（ステップＳ１４７）。その後、フィルタリング部１４１は、取得した記事概要を表示候補スプール１３９に格納する（ステップＳ１４８）。

（ｋ）記事概要に対する既読フラグ付与処理について
図２１では、記事概要に対する既読フラグ付与処理として、記事概要に「既読フラグ」を付与することにより、記事概要を管理する例を示している。参照記録部１２９は、イベント受信部１２３からの選択記事概要に対する既読フラグ付与に関する処理実行指示に応答して、ユーザによって選択された記事概要に既読フラグを付与する。この場合、表示候補スプール１３９の当該記事概要について既読フラグを付与し、必要に応じて、記事データベース１３７内の当該記事概要にも既読フラグを付与する（ステップＳ１８１）。既読フラグの付与が終わったら、参照記録部１２９は、記事一覧表示部１０５ａに表示されている内容を更新（リフレッシュ）するために、記事一覧取得部１２１ａに対して、表示候補スプール１３９に格納されている記事概要を一覧表示するよう指示する（ステップＳ１８３）。記事一覧取得部１２１ａは、参照記録部１２９からの指示に応答して、表示候補スプール１３９に格納されている記事概要を記事一覧表示部１０５ａに表示する。当該記事一覧表示部１０５ａのリフレッシュは、例えば記事一覧表示部１０５ａに表示される記事概要の各々に対して既読・未読を示すアイコンが表示されているような場合や、記事一覧表示部１０５ａに表示される未読の記事概要が太字で一覧表示されるのに対して、既読の記事概要が細字で一覧表示されているような場合において、有効な処理手順である。

（ｌ）第２話題抽出処理について
話題抽出部１２５における第２話題抽出処理は、イベント受信部１２３が「記事を開く」ことに関するイベントを検出し、当該イベントに関する処理実行指示を話題抽出部１２５に通知することにより、実行される。ここで、本発明の第２の実施の形態における「記事を開く」ことに関するイベントには、本発明の第１の実施の形態と同様に、ユーザが操作部１０７を用いて指示することにより発生するユーザ・イベントであり、例えば、ユーザが記事一覧表示部１６１に表示されている記事概要をダブルクリックすることにより発生するユーザ・イベントや、ユーザが選択記事表示部１６３に表示中の記事概要に含まれる記事タイトルをクリックすることにより発生するユーザ・イベント等である。

イベント受信部１２３は、話題抽出部１２５に処理実行指示を通知する際に、記事表示部１２１により表示された記事概要に係るデータ、すなわち表示中の記事概要のデータを選択記事取得部１２１ｂから取得し、当該表示中の記事概要のデータを話題抽出部１２５に送信する。

図２２は、第２話題抽出処理の詳細を示している。話題抽出部１２５は、Ｗｅｂブラウザを起動する。その際、イベント受信部１２３から送信された表示中の記事概要の＜Ｌｉｎｋ／＞タグ中に記述されているＵＲＬをＷｅｂブラウザに与える（ステップＳ１５１）。Ｗｅｂブラウザは、当該ＵＲＬにアクセスし、当該表示中の記事概要についての記事文書全体を取得し、表示装置に表示する。なお、メールクライアント型ＲＳＳリーダでは、Ｗｅｂブラウザは独立のウインドウとして起動してもよいが、選択記事表示部１６３中に組み込む形態で起動する手段があることが望ましい。

イベント受信部１２３は、当該通知と共に、選択された記事概要に関するデータ（すなわち、選択記事表示部１０５ｂに表示中の記事概要であって、ユーザによって選択された記事概要）及び選択されたフォルダに関するデータを、表示記事取得部１２１から取得し、それらを話題抽出部１２５に通知する。話題抽出部１２５は、ユーザにより選択された表示中の記事概要に関するデータ及び選択されたフォルダに関するデータを受け取る（ステップＳ１５３）。

話題抽出部１２５は、残りの記事概要の中から表示中の記事概要に関連する記事概要を抽出する（ステップＳ１５５）。ステップＳ１５５における処理の詳細については、本発明の第１の実施の形態で述べたこと（すなわち、図８のステップＳ３３の説明で詳細に述べたこと）と同様であるので、説明を省略する。表示中の記事概要に関連する記事概要を抽出したら、話題抽出部１２５は、図２、図３の説明で述べたような話題要素＜ｗａｄａｉ／＞を付与することにより、表示中の記事概要及び関連記事概要で話題集合を生成し（ステップＳ１５７）、生成された話題集合を話題データベース２７に追加登録する（ステップＳ１５９）。さらに、当該話題集合に含まれる記事概要が一覧表示において上位に表示されるように、話題抽出部１２５は、当該話題集合に含まれる記事概要を表示候補スプール１３９の先頭に配置し（ステップＳ１６１）、記事一覧表示部１０５ａに表示されている内容を更新（リフレッシュ）するために、記事一覧取得部１２１ａに対して、表示候補スプール１３９に格納されている記事概要を一覧表示するよう指示する（ステップＳ１６３）。記事一覧取得部１２１ａは、話題抽出部１２５からの指示に応答し、表示候補スプール１３９に格納されている記事概要を記事一覧表示部１０５ａに表示する。

ここで、図２３を用いて関連記事概要が抽出される様子を示す。図２３（ａ）は第２話題抽出処理が実行される前の記事概要の構造である。この時点では、どの記事概要にも話題要素が付与されていない。ここで、ユーザが最上位の記事概要を選択した場合、最上位の記事概要を基準とし、関連する記事概要を抽出する。図２３（ｂ）には、ユーザが選択した記事概要との類似度がＡ１である記事概要が抽出された様子を示している。図２３（ｂ）に示した記事概要の並び順は、同時に、図１８の記事一覧表示部１６１に表示される記事概要の並び順でもある。図２３（ａ）及び（ｂ）にあるように、ユーザが選択した記事概要及び類似度Ａ１の記事概要には、話題要素３０５（＜ｗａｄａｉ／＞）「スマトラ沖地震」が付与され、これらの記事概要は一覧の最上位に表示されている。また、「スマトラ沖地震」という話題集合に関連しない記事概要については、並び順が変更されていない。

（ｍ）話題に対する既読フラグ付与処理について
参照記録部１２９は、上で述べた記事概要に対する既読フラグ付与処理だけでなく、話題に対する既読フラグ付与処理も実行する。ここで述べる話題に対する既読フラグ付与処理は、イベント受信部１２３が「選択話題に対する既読フラグ付与」に関するイベントを検出し、当該イベントに関する処理実行指示を参照記録部１２９に通知することにより、実行される。「選択話題に対する既読フラグ付与」に関するイベントとは、本発明の第１の実施の形態で述べた「話題を削除」することに関するイベントと同様に、ユーザ指示により発生するユーザ・イベントである。

図２４は、話題に対する既読フラグ付与処理の詳細を示している。参照記録部１２９は、イベント受信部１２３からの選択話題に対する既読フラグ付与イベントに関する処理実行指示に応答して、ユーザが選択した記事概要、すなわちユーザ選択に係る記事概要に付与されている話題要素（＜ｗａｄａｉ／＞タグ）の内容を参照し、同じ話題要素の内容を有する記事概要の全てについて、既読フラグを付与する。この場合、表示候補スプール１３９の当該記事概要について既読フラグを付与し、必要に応じて、記事データベース１３７内の当該記事概要にも既読フラグを付与する（ステップＳ１９１）。既読フラグの付与が終わったら、参照記録部１２９は、記事一覧表示部１０５ａに表示されている内容を更新（リフレッシュ）するために、記事一覧取得部１２１ａに対して、表示候補スプール１３９に格納されている記事概要を一覧表示するよう指示する（ステップＳ１９３）。記事一覧取得部１２１ａは、参照記録部１２９からの指示に応答して、表示候補スプール１３９に格納されている記事概要を記事一覧表示部１０５ａに表示する。当該記事一覧表示部１０５ａのリフレッシュは、例えば記事一覧表示部１０５ａに表示される記事概要の各々に対して既読・未読を示すアイコンが表示されているような場合や、記事一覧表示部１０５ａに表示される未読の記事概要が太字で一覧表示されるのに対して、既読の記事概要が細字で一覧表示されているような場合において、有効な処理手順である。

（ｎ）スリープ・モードへの移行について
以上の（ｉ）乃至（ｍ）で述べた処理が、ＲＳＳリーダ・プログラム１０３の通常モードにおける処理の詳細である。イベント受信部１２３は、上で述べたイベントのいずれでもないイベントを受信した場合（例えば一定時間ユーザからの操作がされなかったことに応じて発生するタイマー・イベントを検出した場合、ユーザが操作部１０７からＲＳＳリーダ・プログラム１０３のウィンドウの最小化を指示したことにより発生するユーザ・イベントを検出した場合）（ステップＳ１３５：Ｎｏルート）には、端子３を介して図２５に示すスリープ・モードの処理へ移行する。

（５）スリープ・モード時の動作について
図２５では、スリープ・モード時におけるＲＳＳリーダ・プログラム１０３の動作の基本的な流れを示している。先ず、ＲＳＳリーダ・プログラム１０３は、動作モードの切り替えを行う。詳細には、イベント受信部１２３は、記事収集部１１５に対して、動作モードをスリープ・モードの動作に切り替える旨を通知する。記事収集部１１５は当該通知に応じて、サイトの巡回処理、すなわちＲＳＳ文書の取得処理を一時停止する。さらに、一時停止された処理が再開されたときに、取得したＲＳＳ文書を記事データベース１３７に格納するのではなく、話題分類部１３３に引き渡すように、動作モードを切り替える。次いで以下の（ｐ）に述べる処理が実行される。

（ｐ）話題再構成部１３１は「第２話題集合再構成処理」を実行する（ステップＳ２０１）。本処理については、後に詳しく述べる。第２話題集合再構成処理が終わると、イベント受信部１２３は、イベントが発生するのを待機する（ステップＳ２０３）。イベントが発生すると、イベント受信部１２３は当該発生イベントの内容を判定し、その内容に応じて、ＲＳＳリーダ・プログラム１０３内の各処理部に対して処理の実行を指示する。当該処理実行指示を受けた各処理部が実行する処理は、以下の（ｑ）又は（ｒ）に述べる処理である。

（ｑ）当該発生イベントが「サイト定期巡回」に関するイベントの場合（ステップＳ２０５：Ｙｅｓルート）には、記事収集部１１５及び話題分類部１３３が、一連の第２記事分類処理を実行する（ステップＳ２０７乃至Ｓ２２１）。一連の第２記事分類処理が終了すると、イベント受信部１２３は、イベントが発生するのを待機する（ステップＳ２０３）。

（ｒ）当該発生イベントが「通常モードへの復帰」に関するイベントの場合（ステップＳ２０５：Ｎｏルート）には、分類結果取得部１３５が、「第２分類結果表示処理」を実行する（ステップＳ２２３）。なお、第２分類結果表示処理の詳細については、図１５及び図１６の説明で述べた本発明の第１の実施の形態の分類結果表示処理と全く同様であるので、説明を省略する。次いで、ＲＳＳリーダ・プログラム１０３は動作モードの第２の切り替えを行う。詳細には、イベント受信部１２３が動作モードを通常モードに切り替える旨を記事収集部１１５に通知し、記事収集部１１５が当該通知に応じて動作モードを切り替える。すなわち、取得ＲＳＳ文書に係る記事概要を話題分類部１３３に引き渡していた記事収集部１１５の動作が、取得ＲＳＳ文書に係る記事概要を記事データベース１３７に格納する動作へと切り替わる。そして、端子４を介して図１９に示す通常モードの処理へ移行する。

（ｐ）第２話題集合再構成処理について
図２６に、第２話題集合再構成処理の詳細手順を示す。なお、本図のステップＳ２３１乃至Ｓ２３５については、図１３の説明で詳細に述べたことと全く同様なので、説明を省略する。本発明の第２の実施の形態に係るＲＳＳリーダ・プログラム１０３においては、さらに、話題再構成部１３１が更新された話題集合の各々に対応する話題フォルダを生成する処理（ステップＳ２３７）を実行する点で、本発明の第１の実施の形態と異なる。

ここで、「話題フォルダ」とは、図１８に示すように、フォルダ表示部１５３に表示されるフォルダの１つであり、１６９ｃ，１６９ｄで示しているフォルダが話題フォルダである。話題フォルダを生成する処理では、話題フォルダを初期化し、話題データベース１２７に格納されている話題集合を参照し、当該話題集合に対応するフォルダを図１８に示すように生成する。具体的には、フォルダ情報１４３の話題フォルダに係るデータを初期化し、話題データベース１２７に格納されている話題集合の話題要素の内容を取得し、取得した話題要素の内容を、フォルダ情報１４３の話題フォルダに係るデータの格納領域に登録する。また、話題フォルダ表示部１５９にフォルダ情報１４３に登録された話題要素に対応したフォルダが表示されるようにする。図１８を見ると、話題Ｃ、話題Ｄについての話題フォルダが生成され、表示されている。図１８において、話題フォルダが「話題Ｃ」、「話題Ｄ」と記載されているのは、ユーザ定義フォルダとの区別をするためである。実際には、話題要素の内容に基づいて、例えば「災害」、「スポーツ」、「経済」などの文言が表示される。

（ｑ）第２記事分類処理について
図２５に示している一連の第２記事分類処理（ステップＳ２０７乃至Ｓ２２１）も、基本的には、図１１で示した一連の記事分類処理（ステップＳ７７乃至Ｓ９１）と同様である。図１１と異なるのは、ステップＳ２１３の判定後に行われる処理（ステップＳ２１７及びＳ２１９）であるので、ここでは、当該処理ステップについてのみ説明し、他のステップについては、説明を省略する。

（ｑ−１）処理ステップＳ２１７について
話題分類部１３３が、記事概要を話題データベース１２７に格納されている話題集合のいずれかに分類できると判定した場合（ステップＳ２１３：Ｙｅｓルート）において、話題分類部１３３が当該記事概要に話題要素を付与して、話題データベース１２７に登録する処理（ステップＳ２１５）は、図１１の処理ステップＳ８５と全く同様である。そして、本発明の第２の実施の形態の場合には、話題分類部１３３は、当該話題要素を付与した記事概要を記事データベース１３７にも登録する（ステップＳ２１７）。このような登録により、ＲＳＳリーダ・プログラム１０３が通常モードへ復帰した後に、ユーザがある話題フォルダを選択した場合、選択した話題フォルダに属する記事概要が記事一覧表示部１６１に表示されるようになる。

（ｑ−２）処理ステップＳ２１９について
話題分類部１３３が、記事概要を話題データベース１２７に格納されている話題集合のいずれにも分類できないと判定した場合（ステップＳ２１３：Ｎｏルート）には、話題分類部１３３は、当該記事概要に話題要素を付与せずに、単に記事データベース１３７に当該記事概要を登録する（ステップＳ２１９）。よりリッチなユーザインターフェースを持ち、記事概要を蓄積及び管理することを目的としたメール・クライアント型ＲＳＳリーダにおいては、記事概要を話題集合に分類することができない場合にも、記事データベース１３７に記事概要を蓄積しておく方が妥当である。

上で述べたように、従来のメール・クライアント型のＲＳＳリーダにおける記事概要の管理方法、すなわち、ユーザ定義フォルダによるフォルダ管理機能やキーワード検索機能では、情報管理コストが高いということや、情報のウォッチングという目的には不向きであるという問題点があった。そこで、本発明の第２の実施の形態に係るＲＳＳリーダ・プログラム１０３のプログラム・ウィンドウについて、図１８に示すように、従来のサイト・フォルダ表示部１５５及びユーザ定義フォルダ表示部１５７に加えて、話題フォルダ１６９ｃ及び１６９ｄを配下に有する話題フォルダ表示部１５９を配置し、ユーザが話題フォルダ１６９ｃ又は１６９ｄを選択した際には、選択された話題フォルダに含まれる記事概要が記事一覧表示部１６１に一覧表示されるようにしている。また、ＲＳＳリーダ・プログラム１０３の内部的な処理においては、話題集合の再構成が実行された後に、話題フォルダ表示部１５９に表示される話題フォルダの各々が、話題データベース１２７に格納されている新たな話題集合の各々と１対１対応して、話題フォルダ表示部１５９に表示されるようにしている。さらに、記事提供サイトから取得した記事概要を話題集合のいずれかに分類できる場合には、当該記事概要を話題集合に含めて管理するようにしている。これにより、ユーザは、ユーザ定義フォルダ等による従来の管理方法で管理をすることなく、効率的に記事概要を知得することができるようになる。

［本発明の第２の実施の形態の変形例］
ＲＳＳリーダ・プログラム１０３がスリープ・モードに移行した際に実行される一連の処理、すなわち、話題再構成部１３１が実行する話題データベース１２７の第２話題集合再構成処理や、話題分類部１３３が実行する記事概要の話題集合への分類処理は、スリープ・モード時に限らず、通常モード時にユーザからの指示により実行されるようにしてもよいし、または、ＲＳＳリーダ・プログラム１０３の起動を契機に、当該一連の処理が実行されるようにしてもよい。

以上本発明の実施の形態について説明したが、本発明はこれに限定されるものではない。例えば図１及び図１７に示した機能ブロック図の各機能ブロックは、必ずしも実際のプログラムモジュールの各々に対応しない。

また、コンピュータ１はコンピュータ装置であり、当該コンピュータ装置は、図２８に示すように、メモリ４０１（記憶装置）とＣＰＵ４０３（処理装置）とハードディスク・ドライブ（ＨＤＤ）４０５と表示装置４０９に接続される表示制御部４０７とリムーバブル・ディスク４１１用のドライブ装置４１３と入力装置４１５とネットワークに接続するための通信制御部４１７とがバス４１９で接続されている。オペレーティング・システム（ＯＳ：Operating System）及び本発明の実施の形態における処理を実施するためのアプリケーション・プログラム、すなわち、ＲＳＳリーダ・プログラム３又は１０３は、ＨＤＤ４０５に格納されており、ＣＰＵ４０３により実行される際にはＨＤＤ４０５からメモリ４０１に読み出される。必要に応じてＣＰＵ４０３は、表示制御部４０７、通信制御部４１７、ドライブ装置４１３を制御して、必要な動作を行わせる。また、処理途中のデータについては、メモリ４０１に格納され、必要があればＨＤＤ４０５に格納される。本発明の実施の形態では、上で述べた処理を実施するためのアプリケーション・プログラムはリムーバブル・ディスク４１１に格納されて頒布され、ドライブ装置４１３からＨＤＤ４０５にインストールされる。インターネットなどのネットワーク及び通信制御部４１７を経由して、ＨＤＤ４０５にインストールされる場合もある。このようなコンピュータ装置は、上で述べたＣＰＵ４０３、メモリ４０１などのハードウエアとＯＳ及び必要なアプリケーション・プログラムとが有機的に協働することにより、上で述べたような各種機能を実現する。コンピュータ１０１についても、同様である。

（付記１）
記事記憶部に格納されている第１の記事の表示がユーザによって選択されたことを検出した場合、前記第１の記事と前記記事記憶部に格納されている第２の記事との記事関連度を算出する記事関連度算出ステップと、
前記記事関連度が所定の条件を満たした場合、前記第２の記事を前記第１の記事に関連して抽出する抽出ステップと、
前記記事記憶部に前記第１の記事を最優先に格納する最優先格納ステップと、
抽出された前記第２の記事を、前記第１の記事に次いで優先的に前記記事記憶部に格納する優先格納ステップと、
をコンピュータに実行させるためのプログラム。

（付記２）
前記抽出ステップで複数の前記第２の記事が抽出された場合、前記優先格納ステップが、抽出された複数の前記第２の記事を前記記事関連度でソートするステップ
を含む、付記１記載のプログラム。

（付記３）
前記記事関連度算出ステップが、
２つの記事の類似度を算出する類似度関数を用いて、前記第１及び第２の記事の第１の記事類似度値を算出するステップと、
算出された前記第１の記事類似度値及び第１の閾値に基づき、前記第１及び第２の記事の関連有無を判定するステップと、
を含む、付記１又は２記載のプログラム。

（付記４）
前記記事記憶部が、ＦＩＦＯキューであり、
前記最優先格納ステップで、前記第１の記事を前記ＦＩＦＯキューの先頭に挿入し、
前記優先格納ステップで、前記第２の記事を、挿入された前記第１の記事の次の位置に挿入する
ことを特徴とする、付記１乃至３のいずれか１つ記載のプログラム。

（付記５）
前記記事記憶部が、記事データベースを含み、
前記記事データベースが、フォルダ表示部に表示される１つまたは複数のフォルダに係るフォルダ情報を含む記事を格納し、
前記第１及び第２の記事が、第１のフォルダに係るフォルダ情報を含み、
前記フォルダ表示部に表示された前記第１のフォルダをユーザが選択すると、前記フォルダ情報を含む前記第１及び第２の記事を前記記事データベースから取得してスプールへ格納するステップと、
前記スプールに格納された前記第１及び第２の記事を記事一覧表示部に表示するステップと、
をさらに実行させる、付記１乃至３のいずれか１つ記載のプログラム。

（付記６）
前記最優先格納ステップで、前記第１の記事が記事一覧表示部に最優先で表示されるように、前記第１の記事を前記スプールに格納し、
前記優先格納ステップで、前記第１の記事に次いで、抽出された前記第２の記事が前記一覧表示部に優先的に表示されるように、抽出された前記第２の記事を前記スプールに格納する
ことを特徴とする、付記５記載のプログラム。

（付記７）
前記優先格納ステップが、
前記記事記憶部に格納された前記第１及び第２の記事を話題としてグループ化するステップ
を含み、
グループ化された前記話題の削除がユーザによって選択されたことを検出した場合、前記話題としてグループ化されている記事を前記記事記憶部から削除するステップ
をさらに実行させる、付記１乃至３のいずれか１つ記載のプログラム。

（付記８）
前記挿入ステップが、
前記ＦＩＦＯキューに挿入された前記第２の記事の末尾にマーカーを挿入することにより、前記ＦＩＦＯキューに挿入された前記第１及び第２の記事を話題としてグループ化するステップ
を含み、
グループ化された前記話題の削除がユーザによって選択されたことを検出した場合、前記ＦＩＦＯキューの先頭から前記マーカーの直前までの記事を前記ＦＩＦＯキューから削除するステップ
をさらに実行させる、付記４記載のプログラム。

（付記９)
前記優先格納ステップが、
前記スプールに格納された前記第１及び第２の記事に話題情報を付加することにより、前記スプールに格納された前記第１及び第２の記事を話題としてグループ化するステップ
を含み、
グループ化された前記話題の削除がユーザによって選択されたことを検出した場合、前記話題情報が付加された記事を前記スプールから削除するスプール削除ステップ
をさらに実行させる、付記６記載のプログラム。

（付記１０）
前記スプール削除ステップが、
前記スプールから削除された前記記事に相当し、前記記事データベースに格納されている記事を削除するステップ
を含む、付記９記載のプログラム。

（付記１１）
話題情報が付加されている１つの記事で又は同一の話題情報が付加されている複数の記事で構成される話題を話題データベースに格納するステップと、
記事提供サイトから第３の記事を取得する記事取得ステップと、
前記第３の記事と、前記話題データベースに格納されている１つ又は複数の話題との話題関連度を算出する話題関連度算出ステップと、
所定の第２の条件を満たしている話題関連度が存在する場合には、当該話題関連度に係る話題の話題情報を前記第３の記事に付加し、前記話題情報が付加された前記第３の記事を前記話題データベースに格納するステップと、
をさらに実行させる、付記１乃至３のいずれか１つ記載のプログラム。

（付記１２）
前記記事取得ステップが、
スリープ・モードとなったことを検出したことにより実行される
ことを特徴とする、付記１１記載のプログラム。

（付記１３）
話題情報が付加されている１つの記事で又は同一の話題情報が付加されている複数の記事で構成される話題を話題データベースに格納するステップと、
記事提供サイトから第３の記事を取得するステップと、
前記第３の記事と、前記話題データベースに格納されている１つ又は複数の話題との話題関連度を算出する話題関連度算出ステップと、
所定の第２の条件を満たしている話題関連度が存在する場合には、前記第３の記事を前記ＦＩＦＯキューに格納し、さらに当該話題関連度に係る話題の話題情報を前記第３の記事に付加し、前記話題情報が付加された前記第３の記事を前記話題データベースに格納するステップと、
前記第２の条件を満たす話題関連度が存在しない場合、前記第３の記事を破棄するステップと、
をさらに実行させる、付記４記載のプログラム。

（付記１４）
話題情報が付加されている１つの記事で又は同一の話題情報が付加されている複数の記事で構成される話題を話題データベースに格納するステップと、
記事提供サイトから第３の記事を取得するステップと、
前記第３の記事と、前記話題データベースに格納されている１つ又は複数の話題との話題関連度を算出する話題関連度算出ステップと、
所定の第２の条件を満たしている話題関連度が存在する場合には、当該話題関連度に係る話題の話題情報を前記第３の記事に付加し、前記話題情報が付加された前記第３の記事を前記話題データベースに格納し、さらに前記話題情報が付加された前記第３の記事を前記記事データベースに格納するステップと、
前記第２の条件を満たす話題関連度が存在しない場合、１つ又は複数の前記話題に係る話題情報を前記第３の記事に付加することなく、前記第３の記事を前記記事データベースに格納するステップと、
をさらに実行させる、付記５又は６記載のプログラム。

（付記１５）
前記話題関連度算出ステップが、
記事と話題との話題類似度を算出する話題類似度関数を用いて、前記第３の記事と前記話題データベースに格納されている前記話題との話題類似度値を算出するステップと、
算出された前記話題類似度値および第２の閾値に基づき、前記第３の記事が前記話題との所定の第１の関連を有することを判定するステップと、
複数の前記話題が前記第１の関連を有すると判定された場合、判定された複数の前記話題の中から前記第３の記事との関連がもっとも高い話題を判定するステップと、
を含む、付記１１乃至１４のいずれか１つ記載のプログラム。

（付記１６）
前記話題関連度算出ステップが、
２つの記事の類似度を算出する類似度関数を用いて、前記第３の記事と前記話題データベースに格納されている第４の記事との第２の記事類似度値を算出するステップと、
算出された前記第２の記事類似度値及び第３の閾値に基づき、前記第３の記事が前記第４の記事との所定の第２の関連を有することを判定するステップと、
複数の前記第４の記事が前記第２の関連を有すると判定された場合、判定された複数の前記第４の記事の中から前記第３の記事との関連が最も高い記事を判定するステップと、
を含む、付記１１乃至１４のいずれか１つ記載のプログラム。

（付記１７）
前記話題データベースに格納されている第１の話題を取得する話題取得ステップと、
前記第１の話題と前記話題データベースに格納されている第２の話題との関連度に基づき、前記第１及び第２の話題から新たな話題を生成するステップと、
前記新たな話題を前記話題データベースに格納するステップと、
をさらに実行させる、付記１１乃至１６のいずれか１つ記載のプログラム。

（付記１８）
ユーザによって所定の指示がされたことを検出した場合、前記話題データベースに格納されている記事を取得するステップと、
取得した前記記事に付加された話題情報に基づき、取得した前記記事を前記話題情報毎に表示するステップと、
をさらに実行させる、付記１１乃至１７のいずれか１つ記載のプログラム。

（付記１９）
記事記憶部に格納されている第１の記事の表示がユーザによって選択されたことを検出した場合、前記第１の記事と前記記事記憶部に格納されている第２の記事との記事関連度を算出するステップと、
前記記事関連度が所定の条件を満たした場合、前記第２の記事を前記第１の記事に関連して抽出する抽出ステップと、
前記記事記憶部に前記第１の記事を最優先に格納する最優先格納ステップと、
抽出された前記第２の記事を、前記第１の記事に次いで優先的に前記記事記憶部に格納する優先格納ステップと、
を含み、コンピュータにより実行される情報処理方法。

（付記２０）
記事記憶部に格納されている第１の記事の表示がユーザによって選択されたことを検出した場合、前記第１の記事と前記記事記憶部に格納されている第２の記事との記事関連度を算出する手段と、
前記記事関連度が所定の条件を満たした場合、前記第２の記事を前記第１の記事に関連して抽出する抽出手段と、
前記記事記憶部に前記第１の記事を最優先に格納する最優先格納手段と、
抽出された前記第２の記事を、前記第１の記事に次いで優先的に前記記事記憶部に格納する優先格納手段と、
を含む、情報処理装置。

本発明の第１の実施の形態の概要を示した機能ブロック図である。記事概要と話題集合との関係を示した図である。（ａ）はＲＳＳ文書のデータ構造を示し、（ｂ）はＲＳＳ文書の記事要素を示した図である。ティッカー型ＲＳＳリーダのプログラム・ウィンドウを例示した図である。通常モード時におけるプログラムの基本動作手順を示した図である。記事ダウンロード処理の詳細手順を示した図である。記事概要削除処理の詳細手順を示した図である。話題抽出処理の詳細手順を示した図である。話題削除処理の詳細手順を示した図である。（ａ）乃至（ｃ）は、表示候補キューの構造を示した図である。スリープ・モード時におけるプログラムの基本動作手順を示した図である。話題集合再構成の概要を示した図である。話題集合再構成処理の詳細手順を示した図である。（ａ）乃至（ｃ）は、話題データベースの構造を示した図である。分類結果表示処理の詳細手順を示した図である。分類結果が表示される様子を例示した図である。本発明の第２の実施の形態の概要を示した機能ブロック図である。メール・クライアント型ＲＳＳリーダのプログラム・ウィンドウを例示した図である。通常モード時におけるプログラムの第２基本動作手順を示した図である。第２記事ダウンロード処理の詳細手順を示した図である。記事フィルタリング処理の詳細手順を示した図である。記事概要に対する既読フラグ付与処理の詳細手順を示した図である。第２話題抽出処理の詳細手順を示した図である。（ａ）乃至（ｃ）は、関連記事概要の抽出の様子を示した図である。話題に対する既読フラグ付与処理の詳細手順を示した図である。スリープ・モード時におけるプログラムの第２基本動作手順を示した図である。第２話題集合再構成処理の詳細手順を示した図である。従来のティッカー型ＲＳＳリーダのプログラム・ウィンドウを例示した図である。コンピュータの構成図である。

符号の説明

１，１０１コンピュータ３ティッカー型ＲＳＳリーダ・プログラム
１０３メール・クライアント型ＲＳＳリーダ・プログラム
５記事表示部
１０５ａ記事一覧表示部１０５ｂ選択記事表示部
７，１０７操作部９，１０９分類結果表示部
１１，１１１ネットワーク１３，１１３記事提供サイト
１５，１１５記事収集部１７，１１７ブックマーク
１９表示候補キュー
２１，１２１表示記事取得部２３，１２３イベント受信部
２５，１２５話題抽出部２７，１２７話題データベース
２９削除部３１，１３１話題再構成部
３３，１３３話題分類部３５，１３５分類結果取得部
１３７記事データベース１３９表示候補スプール
１４１フィルタリング部１４３フォルダ情報
４１ティッカー型ＲＳＳリーダのプログラム・ウィンドウ
４３記事概要表示部
４５，４７，４９ボタン５１，１７５ハイパーリンク
６１マーカー７１分類結果表示画面
７３話題表示部７５話題名表示部
７７新着記事表示部７９関連記事表示部
１２９参照記録部
１５１メール・クライアント型ＲＳＳリーダのプログラム・ウィンドウ
１５３フォルダ表示部１５５サイト・フォルダ表示部
１５７ユーザ定義フォルダ表示部１５９話題フォルダ表示部
１６１記事一覧表示部１６３選択記事表示部
１６５ブックマーク・サイト・フォルダ１６７ユーザ定義フォルダ
１６９話題フォルダ１７１記事要素名表示ボタン
１７３話題内容表示部
２００話題（話題集合）
２０１，２０２，２０３，２０４記事（記事概要）
３００ＲＳＳ文書３０１複合キー（キー・タグ）
３０１ａリンク要素３０１ｂ更新日時要素
３０３記事抽出要素３０５話題要素
３０７話題要素が付与されたＲＳＳ文書

Claims

ティッカー型の記事表示プログラムであって、
コンピュータに、
複数の記事を格納している表示候補キューに格納されている第１の記事が利用者により選択されると、前記第１の記事と前記表示候補キューにおいて前記第１の記事よりも後に格納されている第２の記事との類似度を求めて、前記類似度が第１の閾値以上である前記第２の記事を前記類似度の順にソートし、ソートされた前記第２の記事を前記表示候補キューにおいて前記第１の記事の直後に移動させ、移動させられた前記第２の記事である第３の記事の末尾に、記事についての話題の境界を表すマーカーを挿入する挿入ステップと、
前記利用者から前記話題の削除の指示を受け付けると、前記マーカーの直前までの記事を前記表示候補キューから削除するステップと、
を実行させるためのティッカー型の記事表示プログラム。
前記挿入ステップが、
前記第１及び第３の記事から当該第１及び第３の記事に共通する語句を抽出し、当該語句を話題情報として当該第１及び第３の記事に付加するステップ、
を含む、請求項１記載のプログラム。
前記話題情報が付加されている１つの記事で又は同一の話題情報が付加されている複数の記事で構成される話題データを話題データベースに格納するステップと、
記事提供サイトから第４の記事を取得する記事取得ステップと、
前記第４の記事と、前記話題データベースに格納されている１つ又は複数の話題データとの話題類似度を算出する話題類似度算出ステップと、
前記第４の記事との話題類似度が所定の条件を満たす話題データが存在する場合には、前記第４の記事を前記表示候補キューに格納し、さらに当該話題類似度に係る話題データの話題情報を前記第４の記事に付加し、前記話題情報が付加された前記第４の記事を前記話題データベースに格納するステップと、
前記第４の記事との話題類似度が所定の条件を満たす話題データが存在しない場合には、前記第４の記事を破棄するステップと、
をさらに実行させる、請求項２記載のプログラム。
前記所定の条件が、
算出された前記話題類似度が第２の閾値以上であることと、
前記第２の閾値以上である前記話題類似度が複数存在する場合には、複数の前記話題類似度の中で最も高い値であることと、
を含む、請求項３記載のプログラム。
ティッカー型の記事表示を行う情報処理装置であって、
複数の記事を格納している表示候補キューに格納されている第１の記事が利用者により選択されると、前記第１の記事と前記表示候補キューにおいて前記第１の記事よりも後に格納されている第２の記事との類似度を求めて、前記類似度が第１の閾値以上である前記第２の記事を前記類似度の順にソートし、ソートされた前記第２の記事を前記表示候補キューにおいて前記第１の記事の直後に移動させ、移動させられた前記第２の記事である第３の記事の末尾に、記事についての話題の境界を表すマーカーを挿入する手段と、
前記利用者から前記話題の削除の指示を受け付けると、前記マーカーの直前までの記事を前記表示候補キューから削除する手段と、
を有する情報処理装置。