(57)【要約】【課題】情報の利用者の情報利用形態に応じた検索結果を得る。【解決手段】本発明の情報配信サーバは、複数のキーワード及び自らの識別情報を含む検索要求を送信する端末と複数のコンテンツ提供サイトとにネットワークを介して接続し、複数のコンテンツ提供サイトから情報を収集する情報収集部と、端末からの検索要求に応答して、収集した情報から複数キーワードを含む情報を選択し、端末の識別情報が示す分野に対応して設定してある複数のキーワードの各々の重み、及び選択した情報を収集した、複数のコンテンツ提供サイトの中のコンテンツ提供サイトに対応して設定してあるソース信憑性指数を用いて、選択した情報のスコアを求め、選択した情報と共にスコアを端末に送信する情報配信部とを有する。【選択図】図１
2010020400.tif 000002
【特許請求の範囲】
【請求項１】
複数のキーワード及び自らの識別情報を含む検索要求を送信する端末と複数のコンテンツ提供サイトとにネットワークを介して接続し、
前記複数のコンテンツ提供サイトから情報を収集する情報収集部と、
前記端末からの前記検索要求に応答して、前記収集した情報から前記複数キーワードを含む情報を選択し、前記端末の識別情報が示す分野に対応して設定してある前記複数のキーワードの各々の重み、及び前記選択した情報を収集した、前記複数のコンテンツ提供サイトの中のコンテンツ提供サイトに対応して設定してあるソース信憑性指数を用いて、前記選択した情報のスコアを求め、前記選択した情報と共に前記スコアを前記端末に送信する情報配信部とを有することを特徴とする情報配信サーバ。
【請求項２】
前記複数のキーワードの各々の重み及び前記ソース信憑性指数は前記端末から定義及び変更されることを特徴とする請求項１記載の情報配信サーバ。
【請求項３】
前記複数のキーワードの各々の重みは、前記端末の識別情報から分野を識別する分野識別子を認識し、前記認識した分野識別子に対応して設定してあることを特徴とする請求項2記載の情報配信サーバ。
【請求項４】
前記ソース信憑性指数は、前記選択した情報の情報源である前記コンテンツ提供サイトの分類コードを参照して、前記参照した分類コードのソース信憑性指数表の指数であることを特徴とする請求項3記載の情報配信サーバ。
【請求項５】
前記分類コードは、前記選択した情報の所在情報に対応していることを特徴とする請求項4記載の情報配信サーバ。
【請求項６】
前記複数のキーワードの各々の重みの平均値を用いて前記スコアを求めることを特徴とする請求項3記載の情報配信サーバ。
【請求項７】
前記選択した情報のスコアを求めるために、他の検索システムが付したローカルスコアを使用することを特徴とする請求項3記載の情報配信サーバ。
【請求項８】
前記求めたスコアの値が所定の上限値を超える場合、前記求めたスコアの値を前記上限値に制限することを特徴とする請求項3記載の情報配信サーバ。
【請求項９】
前記端末の利用者と類似度の高い他の利用者のアクセス履歴を使って前記スコアを補正することを特徴とする請求項3記載の情報配信サーバ。
【請求項１０】
前記他の利用者のアクセス履歴から、前記他の利用者と前記利用者との閲覧の差分を使って前記スコアの補正することを特徴とする請求項9記載の情報配信サーバ。
【請求項１１】
アクセスが限定される前記コンテンツ提供サイトの認証を代理で受けることを特徴とする請求項3記載の情報配信サーバ。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数のリソースから得られた情報群から、有効な記事を検索し、提供する情報配信サーバに関する。
【背景技術】
【０００２】
インターネットが普及し多くの情報が利用可能となり、さらに情報を利用する利用目的もその多様性を高めた。情報利用を高度化し、効率的かつ良質なアクセス方法を実現することは産業上極めて重要な技術課題である。その技術課題を取り巻く状況として、３つの観点がある。それは、情報の多様性、情報を整理する検索エンジンの並立、そして情報利用形態の多様性である。
【０００３】
一つめの、情報の多様性について。ネットワーク越しに入手可能な情報は、多くの情報源からによるものからなっている。これには、単に個人のブログや、ホームページ、企業のホームページ、メディア記事などのネットワークメディアとしての複数のソースのことのみではない。従来の紙媒体による出版物、論文、新聞、雑誌などの記事がデジタルアーカイブ化され、これらがネットワーク上で整理、公開され、利用者はこれをネットワークメディアの一つとして閲覧することができる。
【０００４】
これらの情報は、たとえ同じ事件や事象を扱ったものであっても、何をもって情報価値としているかは異なる場合がある。例えば、電力会社における停電事故が発生したとする。停電がなぜ起こったのかという技術的検証を記述した解説記事と、停電中の状態を示す停電マップというコンテンツまで様々である。この２例ではリアルタイム性の変化が顕著である。一方で、ブログで記載された停電に関する情報と、電力会社が発表する情報とでは信憑性という観点で後者のほうが情報価値として高いが、場合によっては停電がどこでどれくらい継続したかという情報の解像度では前者が価値として高いと評価されることもある。
【０００５】
二つ目の情報を整理する検索エンジンの並立について。ここでは、インターネットで広く普及する検索エンジンだけでなく、サイト内の全文検索のシステムも含めて考える。世界中の情報という情報は、ありとあらゆる検索サーバで管理、索引化され、ユーザへ提供されているものがほとんどである。もし、単一の検索サーバがすべての文書を管理し、ユーザが単一の検索サーバを使う環境では比較的問題は小さい。しかし、単一のユーザが複数の検索サーバを使う場合には、その結果のよい集約方法は自明ではない。現在、主流となるＷＷＷの検索は有力な検索エンジンの単一の結果を用いる場合が多いが必ずしもユーザの要求はこれだけに留まらない。現在、多くのＷＷＷ利用者は、複数の会員制ＷＷＷコンテンツのメンバシップ（ＳＮＳや有料コンテンツ、事業者内の社外秘コンテンツなどにアクセスする権利）を保持しており、それぞれで情報を利用している。
【０００６】
三つ目には情報利用の形態の多様性がある。利用者の環境や資産などにより、同じ情報であっても、要・不要の判断が異なるなど、情報利用形態が多様化している。検索エンジンは、検索要求（クエリ）でこの利用者の利用形態の多様性を吸収する形で利用が進んでいる。
【０００７】
多様な情報が入手可能である利用者にとって、有意な情報の提供をすべく実施・利用されているのが、現在の検索エンジンである。現在の検索エンジンに関する技術が、特許文献１及び特許文献２に開示されている。
【０００８】
【特許文献１】特開２００４−１１０８０８号公報
【特許文献２】特表２００７−５０７７９８号公報
【発明の開示】
【発明が解決しようとする課題】
【０００９】
背景技術に示したような情報の存在と、その検索技術の散在、そして利用者の利用形態を考えた場合、これまでの多くの情報へのアクセス手法に支障が出てくる。
【００１０】
まず情報の多様性について。情報はこのコンテンツだけで価値が決まるものではなく、その発表・出版の方法や、情報提供元である個人・法人、あるいは情報入手のタイミングなどにより、その情報の価値が変化する。このことは、実はネット上の会員限定コンテンツやメンバシップによるアクセスするコンテンツの存在と大きな関係がある。こうした限定性のあるコンテンツはその情報がそこから発せられていること自体に価値がある。一字一句同じ文章が、例えば個人のブログに記載されていたからといって同じ価値を発揮したりはしない。
【００１１】
現在のネット上の検索機能は、上記で挙げた特許文献１、特許文献２ともに、この情報の異なるソースや、アクセス制限についての問題は解決できない。なぜならば、検索要求を出したユーザを認証できず、また会員限定のコンテンツに対するスコア評価やこの他人による閲覧の仕組みが欠如しており、安易にこれを実装すると限定コンテンツの公開などコンテンツホルダへの利益阻害行為となる。よって従来の技術では利用者は公開の情報に対して検索エンジンとしての機能が利用でき、限定性のあるコンテンツは扱わない。一方限定性のあるコンテンツに対しては、別途そのサイトが提供する検索機能やユーザへの推薦機能を別途利用することとなる。このように利用者では、検索対象となるコンテンツを明示的・暗示的に分割することを意識した上で、異なる別途の検索処理を行い、これらの検索結果両方を見合わせながら有用な情報を入手せざるを得なかった。
【００１２】
このことから、単に複数の検索結果をマージすることのみならず、これらを知的に比較統合した結果を利用者に提供することが求められる。具体的には、情報の利用者側から言えば、自分の情報利用形態に応じた検索結果が得られることが望ましい。
【課題を解決するための手段】
【００１３】
本発明の情報配信サーバは、複数のキーワード及び自らの識別情報を含む検索要求を送信する端末と複数のコンテンツ提供サイトとにネットワークを介して接続し、複数のコンテンツ提供サイトから情報を収集する情報収集部と、端末からの検索要求に応答して、収集した情報から複数キーワードを含む情報を選択し、端末の識別情報が示す分野に対応して設定してある複数のキーワードの各々の重み、及び選択した情報を収集した、複数のコンテンツ提供サイトの中のコンテンツ提供サイトに対応して設定してあるソース信憑性指数を用いて、選択した情報のスコアを求め、選択した情報と共にスコアを端末に送信する情報配信部とを有する。
【００１４】
本発明の他の態様は、複数のキーワードの各々の重み及びソース信憑性指数は端末から定義及び変更される情報配信サーバである。
【００１５】
本発明のさらに他の態様は、複数のキーワードの各々の重みは、端末の識別情報から分野を識別する分野識別子を認識し、認識した分野識別子に対応して設定してある情報配信サーバである。
【発明の効果】
【００１６】
本発明により、情報の利用者は自分の情報利用形態に応じて検索機能をカスタマイズし、単なる情報自体だけの価値評価だけでなく情報源などを加味した検索を実現することができる。
【発明を実施するための最良の形態】
【００１７】
本発明の一実施形態について説明する。なお，これにより本発明が限定されるものではない。
【実施例１】
【００１８】
以下、本発明の実施例を図面により説明する。
【００１９】
図1は、利用者が情報を閲覧するためのシステムのハード構成に関する全体図である。情報を閲覧する利用者は端末１１００を使って情報を閲覧・利用する。これを実現するために、端末１１００は情報配信サーバ１３００を介して、各種デジタル情報を効率的に取得する。これらの情報は例えばウェブニュースサイト１４０１やブログサイト１４０２、電力会社サイト１４０３などのコンテンツ提供サイトから発せられる情報である。
【００２０】
端末１１００には、ＣＰＵ１１０１、メモリ１１０２、通信装置１１０３、入力装置１１０４、表示装置１１０５、記憶装置１１１０が内蔵され、記憶装置１１１０に保存された各種プログラムがメモリ１１０２にロードされ、ＣＰＵ１１０１の演算機能や入力装置１１０４、表示装置１１０５、通信装置１１０３の機能を使いながら利用者の命令を処理したり、その結果を出力したりする。
【００２１】
この端末１１００はネットワーク１２００を介して、情報配信サーバ１３００と接続し各種の情報のやりとりを行う。その処理の実態である情報取得プログラム１１１１や、端末１１００のＩＰアドレス１１１２、情報取得先ＵＲＬ１１１３が保存され、これらのプログラム、データを使って情報配信サーバ１３００と通信を行う。
【００２２】
一方、情報配信サーバ１３００も、端末１１００と同様の構成であり、ＣＰＵ１３０１，メモリ１３０２、入力装置１３０３、通信装置１３０４、表示装置１３０５、記憶装置１３１０を内蔵し、記憶装置１３１０に保存された各種プログラムがメモリ１３０２にロードされ、ＣＰＵ１３０１の演算機能や入力装置１３０３、表示装置１３０５、通信装置１３０４の機能を使いながらサーバ処理を実現する。
【００２３】
情報配信サーバ１３００がネットワーク１２００を介して行う通信処理に主に二種類ある。一つは端末１１００とのやりとり、もう一つは各種情報源とのやりとりである。各種情報源とは、ウェブニュースサイト１４０１、ブログサイト１４０２、電力会社サイト１４０３である。これら情報源から情報を収集する処理は情報収集プログラム１３１１により実現される。一方、端末１１００への情報配信処理は情報配信プログラム１３１２により実現されるが、この処理の中で、情報収集プログラム１３１１が収集したデータの加工処理を行う。その加工処理を行うのが、情報処理プログラム１３１３である。
【００２４】
これらの間でやりとりされる通信フローの典型例を示したものを図１４に示す。端末１１００は検索要求を生成し、これを情報配信サーバ１３００に渡す、情報配信サーバ１３００は利用者を認識しながら記事のスコアリング、出力の整形をし、結果を端末１１００に返す。端末１１００はこの受け取った結果を整形し利用者に表示する。
【００２５】
これとは独立に情報配信サーバ１３００はコンテンツサイト１４００１（この具体的例が、図１におけるウェブニュースサイト１４０１、ブログサイト１４０２、電力会社サイト１４０３である）への情報収集のクエリを生成し、コンテンツサイト１４００１に送信する。コンテンツサイト１４００１はクエリに応じたコンテンツを情報配信サーバ１３００へ送信する。このコンテンツを情報配信サーバ１３００は保存する。
【００２６】
図２、図３、図５、図６で各々の処理をフロー図として示している。図２の処理は端末１１００での処理である。図３、図５、図６は情報配信サーバでの処理である。
【００２７】
図２は、端末１１００で処理される情報取得プログラム１１１１の処理フローを示す図である。この処理は、利用者から入力されたクエリに対する、適切な情報を取得し表示させるものである。入力装置１１０４を介して利用者からクエリデータＫｅｙを受ける（ステップ２１０１）。記憶装置１１１０に保存されている情報取得先ＵＲＬ１１１３を利用し、入力されたＫｅｙと記憶装置１１１０に保存されている端末１１００のＩＰアドレス１１１２とを検索要求に含み情報配信サーバ１３００へ送信する（ステップ２１０２）。ＩＰアドレス１１１２は、情報配信サーバ１３００において端末１１００を識別する識別子として用いられる。サーバ１３００からの返答データＲｅｔを受信する（ステップ２１０３）。適切な文書が存在しない場合やサーバ１３００が正常な返答ができない場合には、「Ｒｅｔが正常でない」ことで判断できるので、Ｒｅｔが正常かどうかにより（ステップ２１０４）、エラーメッセージを表示するか（ステップ２１０６）、正常なＲｅｔデータとして加工のうえ表示するか（ステップ２１０５）を行い、処理を終了する。
【００２８】
図３は情報配信サーバ１３００で処理される情報収集プログラム１３１１の処理フローを示す図である。この処理では適宜情報配信サーバ１３００の記憶装置１３１０内のデータ領域１３１４の各種データを参照しながら処理を進める。これらのデータの構成を図４に示す。情報収集プログラム１３１１で実現する処理は、予めシステムで定義されたスケジュールによりバッチ処理として自動的に実行される。
【００２９】
処理を開始すると、情報収集先数ｎ４１０１をロードし（ステップ３１０１）、ループカウンタIに１をセットする（ステップ３１０２）。ループカウンタiを使いながら以下のステップ３１０４からステップ３１０８の処理をｎ回だけ繰り返す（ステップ３１０３）。各ループでは以下の処理を行う。データ領域１３１４に保存されるURLリスト４１０２の第i番目エントリをURLとして、HTTPにより情報を取得する（ステップ３１０４）。このHTTPセッションが成功すれば（ステップ３１０５）、フォーマットリスト４１０３から当該URLに対応するフォーマットデータ（For）をロードし（ステップ３１０６）、HTTPの結果に対しForを使って予備加工する（ステップ３１０７）。結果としてカウンタ値ｉと予備加工した結果データＥｌｅとを保存記事リスト４１０４の末尾（ファイルポインタｆｐで管理）に保存する。
【００３０】
処理の具体例を示す。ＨＴＴＰの結果はＸＭＬ形式であるが、実際にはそれ以上に様々なリンクやサイト情報などが付加されており、記事としては冗長である。そこで、どこからどこまでが記事であるかを定義するフォーマットを使って余分なデータの削除などをする。例えばＵ３に相当するＵＲＬへのアクセスした結果に対するフォーマットとして｛｛０，２３｝，｛-４，−７｝｝とある。これはテキスト座標｛０，２３｝と｛-４，-７｝が記事であることを示している。｛０，２３｝の書式は、第一エントリ（０）が水平座標（左が始点）、第二エントリ（２３）が垂直座標（上が始点）であり、始点が０、１文字毎に座標（文字位置）が１インクリメントする。文字位置の定義はＨＴＴＰコンテンツの文字コード指定からのバイト数で定義する。｛-４，-７｝は、この記事のフォーマットの末尾点を｛-１，-１｝としたときの始点方向へ向かった座標であり、始点方向へ一文字進む毎に小さくなる（絶対値は増える）。ｎ回のループ処理が終了すると、処理の終了となる。
【００３１】
図５も情報配信サーバ１３００で処理されるもので、情報配信プログラム１３１２の処理フローを示す図である。この処理でも適宜情報配信サーバ１３００の記憶装置１３１０内のデータ領域１３１４の各種データを参照しながら処理を進める。情報配信プログラム１３１２で実現する処理は、ネットワーク１２００に接続する端末１１００からのクエリに応じて実行される。
【００３２】
処理を開始すると、情報取得キーワードｋｅｙ、情報配信要求元のＩＰアドレスＩＰＡＤが端末１１００からのクエリという形で入力される（ステップ５１０１）。このクエリに応じてまず保存記事リストのエントリ数ｍを情報配信サーバ１３００内の記憶装置１３１０のデータ領域１３１４の保存記事リスト４１０４からロードする（ステップ５１０２）。最終的な出力データはエントリを逐次的に処理しながら追記するものであり、まずその先頭部分の定型フォーマットである、ＨｔｍＰｒｅＦｏｒを結果ファイルであるＨｔｍＴｍｐへコピーする（ステップ５１０３）。その後から各記事エントリに対する処理がループで順次処理される。ループカウンタiを初期化し（ステップ５１０４）、（ステップ５１０４）５１０６〜（ステップ５１０４）５１０９を合計ｍ回繰り返し（ステップ５１０５）、結果としてできたHtmTmpの末尾フォーマットを追記、全体を出力して処理が終了する（ステップ５１１０）。
【００３３】
個々の記事に対して以下の処理を行う。まず記事を処理するために記事本体であるＥｌｅと、その記事カテゴリＲ（Ｕ２など）を保存記事リスト４１０４からロードする（ステップ５１０６）。この記事情報と、利用者からのクエリ情報とを後で述べる情報処理プログラム１３１３へ送信し、この結果として整数値Ｓｃｒを受ける（ステップ５１０７）。この整数値Ｓｃｒは利用者にとっての本エントリの有効度を示すものであり、０の場合は（ステップ５１１１）、出力ファイルへの追記は行わずエントリ処理を終了し、なんらかの値がある場合（ステップ５１１１）、記事本体Ｅｌｅ、カテゴリＲ、そして有効度Ｓｃｒを含めてＨｔｍＴｍｐに記載し（ステップ５１０８）、エントリに対する処理が終わる。ループカウンタiをインクリメントし（ステップ５１０９）、保存記事リスト４１０４の次のエントリに対する処理に移る。
【００３４】
図６も情報配信サーバ１３００で処理されるもので、情報処理プログラム１３１３の処理フローを示す図である。この処理でも適宜情報配信サーバ１３００の記憶装置１３１０内のデータ領域１３１４の各種データを参照しながら処理を進める。情報処理プログラム１３１３で実現する処理は、同じサーバ１３００内の情報配信プログラム１３１２の処理実行中に呼び出しルーチンとして実行される。
【００３５】
処理を開始すると、呼び出し元である情報配信プログラム１３１２から、情報取得キーワードｋｅｙ、情報配信要求元のＩＰアドレスＩＰＡＤ、記事カテゴリＲ、生成データＥｌｅが入力される（ステップ６１０１）。この記事に対して加算的にスコアＳｃｒを算出してゆく。その初期値として０をセットする（ステップ６１０２）。生成（加工）データＥｌｅを対象にテキストマッチングを行い、ｋｅｙとのマッチ回数であるｈｉｔを得る（ステップ６１０３）。もしこれが０ならば（ステップ６１０４）、有効度はないとし、Ｓｃｒ＝0を出力して終了する（ステップ６１０８）が、ｈｉｔ値が非ゼロの場合（ステップ６１０４）、以下の処理によりＳｃｒを算出する（スコアリングする）。クエリ元であるＩＰＡＤに対し、分野ネットワークセグメント表４１０６を使ってこのアクセスがどの分野からのアクセスであるかを判断する（ステップ６１０５）。例えばＩＰＡＤが192.168.3.38であった場合、それが属するネットワークセグメントから分野を識別する分野識別子ｆｉｄがＦ２であることがわかる。アクセス元の分野識別子をＦ２と認識し、この情報をもとにキーワード毎に重みをつけて、記事に対するスコア計算を行う。具体的には、分野識別子ｆｉｄに相当する分野キーワード辞書（Ｆ２）４１０７を使う。ステップ６１０３でキーワード毎のカウント数が得られているので、これに辞書参照結果による重み積算を行う。その総和としてマッチ数を計算する（ステップ６１０６）。
【００３６】
例えば、検索キーワードが「障害、停電、復旧」だったとし、ある特定の記事を対象にして、それぞれのマッチ数が５、７、３だったとする。分野キーワードによると重みは「９、（未定義）、７」である。未定義は標準化（１）した重みとし、この記事のスコアは５×９＋７×１＋３×７＝７３となる。
【００３７】
その次の処理として、情報の属性である記事カテゴリＲを参考にしてさらにスコアを補正する（ステップ６１０７）。例えば対象となる記事が保存記事リスト４１０４のエントリ3だったとする。この情報源はＵ１であり、ＵＲＬリスト４１０２のエントリＵ１のソース分類コードＣ１を参照して、ソース信憑性指数表４１０８により、指数５が得られる。最終的なこの記事に対するスコアは７３×５＝３６５となる。これを出力して処理は終了する（ステップ６１０８）。
【００３８】
例示は分かり易くするために、検索キーワードとのマッチによる一致検索により説明したが、実際には、検索キーワードの同義語や類義語などの辞書も用いて、検索キーワードと同じ又は類似の意味の用語を含む検索を実行する。
【００３９】
また、キーワードごとのマッチ数と重みとの積の和とソース信憑性指数とを乗算してスコアＳｃｒを得ることを説明したが、キーワードの重みの付け方、ソース信憑性指数の定め方に応じて、所定の関数を用いて最終的なスコアＳｃｒを求めても良い。キーワードの重みの付け方、ソース信憑性指数の定め方は利用者によって異なるので、利用者が端末１１００から、それらの値や所定の関数を定義、変更する。
【００４０】
本実施例ではスコアに対する上限値がないため、評価値の表示に処理が必要となる。上限値を設けるための処理の代替方法を示す。
【００４１】
図６に示した情報処理プログラム１３１３に対して、ステップ６１０７の後に上限値による切捨て、対数表示、整数化による評価値の圧縮を行ったものであり、図７に示す。
【００４２】
ステップ６１０１からステップ６１０７までは図６と同一である。もしＳｃｒが２５５を超える場合には（ステップ７１０８）Ｓｃｒ＝２５５とする（ステップ７１１０）。そして、ｌｏｇ２（Ｓｃｒ）の整数部分を最終的にスコアとして出力する（ステップ７１０９）。
【実施例２】
【００４３】
図８は、実施例２のシステム全体のブロック図である。本実施例でも利用者が集約された情報を閲覧するが、ここでは特に限定コンテンツサイト８１００を参照し、その検索機能８１０１を使った場合を示す。
【００４４】
端末１１００は、実施例１に示した端末とハード構成は同一である。記憶装置内の情報取得先ＵＲＬ（実施例１の１１１３）があとに示す情報配信サーバ８３００となっている。この端末１１００は、ネットワーク８２００を介して情報配信サーバ８３００と情報のやりとりを行う。
【００４５】
一方、情報配信サーバ８３００も、実施例１に示したサーバ１３００とハード構成は同一であるが、逐次情報収集プログラム８３１１、情報配信プログラム８３１３、情報処理プログラム８３１４、データ領域８３１５、逐次検索結果反映プログラム８３１６がそれぞれ異なっている。これらについて以降で順次説明する。
【００４６】
情報配信サーバ８３００がネットワーク８２００を介して行う通信処理に主に二種類ある。一つは端末１１００とのやりとり、もう一つは各種情報源とのやりとりである。後者は、ウェブニュースサイト１４０１、ブログサイト１４０２の他、会員限定のコンテンツを提供するコンテンツサイト８１００がある。さらにコンテンツサイト８１００には検索機能８１０１があり、これにより保有するコンテンツの全文検索が可能である。これら情報源から情報を収集する処理は情報収集プログラム１３１１と逐次情報収集プログラム８３１１の両方により実現される。一方、端末への情報配信処理は情報配信プログラム８３１３により実現されるが、この処理の中で、情報収集プログラム１３１１、逐次情報収集プログラム８３１１が収集したデータに対して加工処理を行う。その加工処理を行うのが、情報処理プログラム８３１４である。情報配信サーバ８３００での処理である逐次情報収集プログラム８３１１、情報配信プログラム８３１３、情報処理プログラム８３１４がそれぞれ図９、図１０、図１１でフロー図として示している。
【００４７】
これらの間でやりとりされる通信フローの典型例を示したものを図１５に示す。端末１１００は検索要求を生成し（１５１０１）、これを情報配信サーバ１３００に渡す。情報配信サーバ１３００は利用者を認識しながら、別の検索サイト１５００１のためにクエリを修正し（１５１０２）、クエリを検索サイト１５００１に送信する。検索サイト１５００１はこれを受信すると、検索を実行し（１５１０３）、その結果を情報配信サーバへ返す。この結果と予めキャッシュされたデータとの両方について記事のスコアリング、出力の整形をし（１５１０４）、結果を端末１１００に返す。端末１１００はこの受け取った結果を整形し利用者に表示する（１５１０５）。
【００４８】
これとは独立に情報配信サーバ１３００はコンテンツサイト１５００２（この具体的例が、図１におけるウェブニュースサイト１４０１、ブログサイト１４０２、電力会社サイト１４０３である）に情報収集のクエリを生成し（１５１０６）、コンテンツサイト１５００２に送信する。コンテンツサイト１５００２はクエリに応じたコンテンツを情報配信サーバ１３００へ送信する（１５１０７）。このコンテンツを情報配信サーバ１３００は保存する。
【００４９】
図１０は情報配信サーバ８３００で処理される情報配信プログラム８３１３の処理フローを示す図である。この処理では、端末１１００から得られた検索クエリに対して、必要な処理をコールし、クエリの結果を端末１１００に送信するものである。このほとんどの処理は、実施例1に示した情報配信プログラム１３１２（図５）に同じであるが、最後のステップ５１１０の直前に逐次検索結果反映プログラム８３１６の実行が新しく挿入される。この逐次検索結果反映プログラム８３１６について次に説明する。
【００５０】
図１３は、情報配信サーバ８３００で処理される逐次検索結果反映プログラム８３１６の処理フローを示す図を示している。これは内部で逐次情報収集プログラム８３１１と情報処理プログラム８３１４を呼び出し、その結果を独自にスコアリングしながら、他の情報との横並びな評価が可能となる。
【００５１】
逐次検索結果反映プログラム８３１６が呼び出されると、呼び出し元から情報取得キーワードｋｅｙ、情報配信要求元ＩＰアドレスＩＰＡＤ、結果記録先のＨｔｍＴｍｐが得られる（ステップ１３１０１）。可視性を高めるために表示上の線を描画するXMLコマンドをＨｔｍＴｍｐに挿入する（ステップ１３１０２）。評価対象である記事を収集すべく、逐次情報収集プログラム８３１１をコールする。この結果としてｆｆｐに検索結果であるところの「記事、情報ソース、ローカルな検索スコア」を一つのセットとして、記事の数だけｆｆｐに記録される。その記事数をｐとする（ステップ１３１０３）。ローカル検索スコアとは、他の検索サイトで付けられたスコアｓである。ループカウンタｉを１にセットし（ステップ１３１０４）、ステップ１３１０６からステップ１３１０９までの処理を各記事に対して行う。このループが終わると（ステップ１３１０５）、この処理も終了する。
【００５２】
ループでは、ｆｆｐから第ｉ番目の保存記事として、記事Ｅｌｅ、記事カテゴリＲ，ローカル検索スコアｓをロードする（ステップ１３１０６）。ここで情報処理プログラム８３１４をコールし、記事本体、情報利用者、記事カテゴリ（記事の情報源）、ローカル検索スコアを勘案したスコアＳｃｒを得る（ステップ１３０１０７）。これが０の場合は（ステップ１３０１０８）、出力ファイルＨｔｍＴｍｐへ出力は行わず、非ゼロの場合のみ（ステップ１３０１０８）、これを出力する（ステップ１３０１０９）。ループカウンタｉをインクリメントして（ステップ１３０１１０）、ステップ１３１０５へ戻る。
【００５３】
図９は情報配信サーバ８３００で処理される逐次情報収集プログラム８３１１の処理フローを示す図である。この処理では適宜情報配信サーバ８３００の記憶装置８３１０内のデータ領域８３１５の各種データを参照しながら処理を進める。これらのデータの構成は図１２に示す。逐次情報収集プログラム８３１１で実現する処理は、逐次検索結果反映プログラム８３１６からの呼び出されて実行される。
【００５４】
処理を開始すると、情報取得キーワードｋｅｙを呼び出し元プログラムから得る（ステップ９１０１）。クエリ受信毎に情報収集を行うサイト数ｎ１２１０１をロードする（ステップ９１０２）。ループカウンタiに１をセットする（ステップ９１０３）。ループカウンタiを使いながら以下のステップ９１０５からステップ９１０９の処理をｎ回繰り返す。各ループでは以下の処理を行う。ＵＲＬリストのエントリ１２１０２を取得し、このＵＲＬが検索キーワードを埋め込むフォーマットをクエリフォーマットリスト１２１０３より取得し、これに従い、ｋｅｙを実質的に含んだ検索クエリを作成する（ステップ９１０５）。なお、コンテンツ閲覧にユーザ認証が必要な場合は、この認証をパスすべく、認証要求をクエリ要求元へ送信し認証をパスするよう実装するか、あるいは利用者の認証情報（ＩＤ，とパスワードの組）を保存しておき、代理で認証を受ける。すなわち、情報配信サーバ８３００は情報配信を目的とするアグリゲーションサーバとして認証動作を実行する。
【００５５】
例えば、検索キーワードｋｅｙが”断水”であった場合、まず情報収集先としてエントリＶ１について以下の処理を行う。ＵＲＬリスト１２１０２からＶ１に相当するＵＲＬを取得し、Ｖ１のアクセスに相当するクエリフォーマットをクエリフォーマットリスト１２１０３から“%E3%82%c”, ByteEncode(key)”を取得する。これは、ＵＲＬリスト１２１０２で参照したＵＲＬに続けて、”E2%82”というプレフィックスと文字列ｋｅｙをByteEncodeした結果を接続することを意味するフォーマット記述言語による一記述である。ByteEncode(string)はｓｔｒｉｎｇをバイト値表現した文字列へと変換する処理である。以上により、エントリＶ１に対するクエリを生成できる。
【００５６】
検索クエリのＨＴＴＰセッションが失敗すれば（ステップ９１０６）、そのエントリへのクエリ発信は終了し、次のＵＲＬを処理する。クエリが成功した場合には（ステップ９１０６）、情報収集プログラム１３１１のステップ３１０６、ステップ３１０７の処理と同様に、検索画面に対するフォーマットリストである１２１０４を使い、記事の加工、保存を行う（ステップ９１０７、ステップ９１０８）。ループカウンタｉをインクリメントして（ステップ９１０９）、ステップ９１０４へ戻る。
【００５７】
図１１で、情報配信サーバ８３００で処理される情報処理プログラム８３１４の処理フローを示す図を示している。情報処理プログラム８３１４で実現する処理は、同じサーバ内の逐次検索結果反映プログラム８３１６の処理実行中に呼び出しルーチンとして実行される。
【００５８】
処理を開始すると、呼び出し元である逐次検索結果反映プログラム８３１６から、情報取得キーワードｋｅｙ、情報配信要求元のＩＰアドレスＩＰＡＤ、記事カテゴリＲ、記事データＥｌｅ、ローカル検索スコアｓが入力される（ステップ１１１０１）。この記事に対してスコアＳｃｒを算出してゆく。その初期値としてｓをセットする（ステップ１１１０２）。情報処理プログラム１３１３のステップ６１０５と同様にこのアクセスがどの分野からのアクセスであるかを判断する（ステップ１１１０３）。ｆｉｄがＦ２であることがわかる。アクセス元をＦ２と認識し、この情報をもとに検索キーワードｋｅｙに対するスコア計算を行う（ステップ１１１０４）。
【００５９】
具体的には、ｋｅｙは複数のキーワードkey1、key2、key3などからなる。これらに対し、分野キーワード辞書（Ｆ２）４１０７を参照し、重みの平均を取る。この平均値をｔ１とする。たとえば、図４に示す分野キーワード辞書（Ｆ2）のキーワード（障害、バグ、復旧）では重みが、（９，５，７）であるので、ｔ１＝７となる。
【００６０】
その次の処理として、情報の属性であるＲを参考にしてさらにスコアを補正する（ステップ１１１０５）。例えば対象となる記事が保存記事リスト１２１０５のエントリ１だったとする。この情報源はＵ１であり、ソース信憑性指数表４１０８により、指数５が得られる。最終的なこの記事に対するスコアＳｃｒはローカル検索スコアｓにｔ１とソース信憑性指数をすべて乗じることでえられる。これを出力して（ステップ１１１０６）、処理は終了する。ここでは、ローカル検索スコアｓとキーワードの重みの平均値ｔ１とソース信憑性指数とを乗算して最終的なスコアＳｃｒを得ることを説明したが、キーワードの重みの付け方、ソース信憑性指数の定め方に応じて、所定の関数を用いて最終的なスコアＳｃｒを求めても良い。
【００６１】
実施例１及び実施例２の変形例を説明する。
【００６２】
まず、記事のスコアリングに関する変形例について説明する。ここでは、分野キーワード辞書を中心に、利用者に依存したスコアリングの例を示した。これ以外にもいくつかのスコアリングに加味することが可能な要素を説明する。
【００６３】
記事のリアルタイム性に着目しリアルタイム性の高い記事が掲載されるサイトにおける、掲載時刻と閲覧時刻との時間差を情報の有効度評価の重みづけに反映することも有効である。
【００６４】
分野キーワード辞書のみならず、複数の利用者間の類似性データや、利用者の興味データ、利用者が法人である場合の取引先、ステークホルダや、事業運営に必要な資源の供給者のリスト、アクセス履歴の類似度から類推される「類似の利用者」リストをスコアの修正に使うことができる。例えば、「類似の利用者」については、利用者自身のアクセス履歴と、「類似の利用者」のアクセス履歴との差分に着目し、相対的に「類似の利用者」の閲覧が少ないものを優先的に利用者が閲覧すべくスコアを修正することは効果的である。これは、「類似の利用者」が閲覧しない又は閲覧する機会が少ない記事の価値に着目していることになる。
【００６５】
次に記事の効率的なカテゴリ化について説明する。効率的なカテゴリ化によりユーザは効果的な検索範囲の縮小を行うことができるので、ユーザの要求を実現すべく以下のような施策を追加することでより効果的な検索結果を出力することができる。
【００６６】
各種記事に対して、活性記事と不活性記事とのカテゴリ分割を考える。例えば速報のような事実や報道の発表次第、その信憑性を犠牲にして利用者に速達することに主な価値のある記事を活性記事と呼ぶ。逆に速達性よりも事象の概要から詳細に至るまで必要な情報を網羅的かつ正確に記載することが求められる記事を不活性記事と呼ぶ。活性記事と不活性記事とを区別するには、当該記事が扱う事象の発生時刻と記事が発行された時刻との時間的差を使って判定する方法がある。もしその時間差が短い(閾値以下)ならば、活性記事であり、それ以外は不活性記事である。閾値は、事象の種類により異なる。短時間の停電であれば停電後2時間、企業のＩＴ障害であれば2日、地域の大規模災害であれば2ヶ月が例であり、これら閾値はシステムで事前に定義する。活性記事と不活性記事との判定は上記時間差のみならず、記事のURL、記事に含まれる特長語句（例、「速報」、「調査結果」）を使って判定することもできる。
【００６７】
上記時間差を算出するにあたり、事象が発生した時刻を情報提供サーバにて管理する必要がある。自動的な手法としては、記事に記載される事象発生の時刻情報を使う方法がある。しかし事象発生が頻繁でない場合には、手作業によりこの事象発生時刻のリストを管理・運用することが可能である。
【００６８】
記事のカテゴリ化には、記事を登録するコンテンツ保持者が故意にタグを記入し、これを用いる方法がある。例えば地震など事象が発生したとき、コンテンツ保持者や情報配信サーバの管理者などが「○○地震」というタグを生成し、これを各種コンテンツ保持者に配布する。コンテンツ保持者は記事のエントリ作成時、用いることができるタグ一覧に新規挿入されたタグを見つけることができ、これにより効率的な記事のカテゴリ化を実現できる。
【００６９】
次に検索キーワードの修正の変形例について説明する。実施例2では、利用者が情報提供サーバに送信する検索クエリは、修正後その他の検索サイトの検索に用いられたり、サーバ内のキャッシュされた記事のスコア付けに用いられたりするなどする。この際に、以下で述べる有用と思われる検索キーを追加することで利用者により効果的な検索結果を与えることができる。
【００７０】
追加するキーの生成方法として、当該利用者が使うキーワード辞書のうち一部の単語群（このグループはシステムで定義する「重要語句」群）の中から重みの大きいものや、以下で示す支援有意性の高い語句を選択する方法がある。支援有意性とは、ひとつの語句に対する検索の成功へ関与する可能性の高さの指標である。検索の成功とは利用者が有効な記事の閲覧を検索結果により入手できたことである。このことを絶対的指標で定量化はできないので、利用者から記事を閲覧したか、していないかを判断の一つとする。もし記事閲覧すれば検索が成功したとし、そうでなければ失敗したとする。成功したとき検索キーに含まれる語句に対し支援有意性のポイントを加算する。検索を利用し続けることで、成功した検索に含まれがちな語句を判断することができる。
【００７１】
端末では検索の結果の表示にあたり、スコアに応じて並び替える機能があるものや、スコアが合算で算出された場合その内訳を表示することは、より可視性の大きなシステムとして利用者への受容性が高まる。
【００７２】
これらの実施例適用例としては、利用者が希望する閲覧情報が限定されている企業向け、あるいは論文調査、特許調査むけの検索サービスがある。例えば、論文調査の場合、情報源としては、出版社の電子閲覧ポータル、電子論文アーカイブ、速報的なレター掲載サイト、学会などのホームページなどが対象となる。企業向けの検索サービスとしては、時事のニュースや各種インフラ企業のニュースリリース、障害情報、国家機関からの発表される公示などが対象となる。
【００７３】
対象となるポータルサイトやホームページ、データベースのリスト（たとえば、図４の情報収集先リストであるＵＲＬリスト）はメンテナンスされる必要がある。例えば、あるサイトを新規にリストに登録する場合を考えるとその可能性は3通りあり、(1)利用者が端末を通じて登録する、(2)情報配信サーバの管理者やそのサービスの運営者が登録する、(3)情報を提供するサイト運営者が登録する。これらのうち(2)(3)については、利用者に対して「リストに新規のサイトが登録された」由を連絡することにより、より利用者に対しての利便性をあげることができる。
【００７４】
さらにこのリストはユーザ毎に準備することも可能であり、ユーザ毎のリストを複数保存した情報配信サーバでは、ユーザの類似性を判断して、類似性が高いユーザ間ではお互いのリストの差分を公開する機能により、ユーザはリストの推薦を受けることができ、より有効な検索を実現することができる。
【００７５】
以上説明した実施形態は、閲覧・検索の端末、ならびに複数の情報提供元から得られる情報をキャッシュ・検索などする情報提供サーバなどに関するものである。以下、概要として纏める。
【００７６】
閲覧・検索の端末は利用者の情報利用形態を表現すべく、利用者情報を情報提供サーバに送信するなどすることで、利用者を認識させる。この情報が直接検索処理、なかでも情報に対するスコアリング、あるいはランキングへと影響するようなものとし、これにより検索結果のカスタマイズ機能を実現する。このカスタマイズ機能にはキーワード辞書の実態であるスコアリスト、リソース重み、リアルタイム性敏感指数といったように数値化されたものや、各種アクセス制限コンテンツへのアクセスに必要な認証情報などが含まれる。
【００７７】
情報提供サーバは、上記閲覧・検索端末から入力された要求から利用者を認識し、この情報を使いながらいくつかの処理を行う。この中には、必要に応じて検索要求の修正をする処理、情報を収集する処理、集められた情報にスコアリングを行う処理、そしてスコアリングした結果に基づいて出力する処理の４つが少なくとも含まれる。
【００７８】
検索要求の修正を行う処理では、利用者を認識しつつ、過去の検索履歴として（１）利用者自身の検索履歴、（２）利用者と類似する別の利用者の検索履歴などを参照し、検索の精度を向上させるために検索要求の修正を行う。
【００７９】
情報を収集する処理では、単に仲介サーバとして情報を収集するだけでなく、その情報の属性を付加し保存する。これは例えば、ブログ、メディア、解説記事のようなカテゴリであるが、このカテゴリは変化することを想定し、ＵＲＩやサーバに関連づけず、アクセス日時と記事へのユニークなインデックス（典型的にはＵＲＩだが、これをさらに分割することを想定する）毎に付与する。
【００８０】
集められた情報にスコアリングする処理では、対象となる記事に対しテキストマッチングによる頻度情報（ヒット率又はキーワードの頻出率）、ならびにキーワード辞書で定義されたキーワード重み、そして情報元であるソースの情報とから記事に対するスコアリングを行う。このスコアリングは、線形な重みつき加算型のスコアリングに、１個以上のしきい値により処理を分解しながら、スコアリングを行う。
【００８１】
スコアリングした結果に基づいて出力する処理では、利用者からの指示に応じて、「情報の属性」別の出力、「スコアの高い順」の出力などの整形（記述順序の変更と、データの構造的な変更の両方を含む）を施す。
【００８２】
これら処理が、バッチ処理による部分と、クエリに対するオンデマンド処理とに分割して処理される。利用者の検索カスタマイズと、記事の収集はバッチ処理的に行い、クエリのタイミングとは独立の処理である。クエリが送信されてから、検索、スコアリング、表示整形、出力を行う。整形の部分は過去の検索結果に対して更新的に行うことができる。言い換えると、クエリが送信されてから、検索、スコアリングした結果を全部蓄積し、整形クエリを複数回受信する処理を含む。
【００８３】
本実施形態によれば、情報の利用者は自分の情報利用形態に応じて検索機能をカスタマイズし、単なる情報自体だけの価値評価だけでなく情報源などを加味した検索を実現することができる。またその結果は公知の情報のみならず、アクセス制限のあるような情報も一元扱いされるため、可視性が高く、必要な情報へアプローチする手間が大幅に削減できる。
【００８４】
本実施形態により効果的な情報提供・情報収集の実現が可能となる。特に、多様な情報源から発せられる情報を横断的に収集し処理・利用するような情報共有体制では有効である。
【図面の簡単な説明】
【００８５】
【図１】実施例１のシステム全体のブロック図である。
【図２】情報取得プログラムの処理フローを示す図である。
【図３】情報収集プログラムの処理フローを示す図である。
【図４】データ領域に格納されるデータを示す図である。
【図５】情報配信プログラムの処理フローを示す図である。
【図６】情報処理プログラムの処理フローを示す図である。
【図７】スコアに上限値を設けるための処理フローを示す図である。
【図８】実施例２のシステム全体のブロック図である。
【図９】逐次情報収集プログラムの処理フローを示す図である。
【図１０】情報配信プログラムの処理フローを示す図である。
【図１１】情報処理プログラムの処理フローを示す図である。
【図１２】データ領域に格納されるデータを示すブロック図である。
【図１３】逐次検索結果反映プログラムの処理フローを示す図である。
【図１４】実施例1における通信フローの典型例を示した図である。
【図１５】実施例2における通信フローの典型例を示した図である。
【符号の説明】
【００８６】
１１００：端末、１１０１，１３０１：ＣＰＵ、１１０２，１３０２：メモリ、１１０３，１３０１：通信装置、１１０４，１３０３：入力装置、１１０５，１３０５：表示装置、１１１０，１３１０，８３１０：記憶装置、１２００，８２００：ネットワーク、１３００，８３００：情報配信サーバ、１４０１，１４０２，１４０３，８１００：ウェブサーバホスト。
【図１】
2010020400.tif 000003
【図２】
2010020400.tif 000004
【図３】
2010020400.tif 000005
【図４】
2010020400.tif 000006
【図５】
2010020400.tif 000007
【図６】
2010020400.tif 000008
【図７】
2010020400.tif 000009
【図８】
2010020400.tif 000010
【図９】
2010020400.tif 000011
【図１０】
2010020400.tif 000012
【図１１】
2010020400.tif 000013
【図１２】
2010020400.tif 000014
【図１３】
2010020400.tif 000015
【図１４】
2010020400.tif 000016
【図１５】
2010020400.tif 000017