JP2004029943A - 検索支援方法 - Google Patents
検索支援方法 Download PDFInfo
- Publication number
- JP2004029943A JP2004029943A JP2002181725A JP2002181725A JP2004029943A JP 2004029943 A JP2004029943 A JP 2004029943A JP 2002181725 A JP2002181725 A JP 2002181725A JP 2002181725 A JP2002181725 A JP 2002181725A JP 2004029943 A JP2004029943 A JP 2004029943A
- Authority
- JP
- Japan
- Prior art keywords
- search
- site
- url
- user
- keyword
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Abstract
【課題】ユーザが所望の情報を、より容易に見出すことができるような検索結果を提示する。
【解決手段】検索処理部１２および検索エンジン３０は、検索キーワードを受理すると、当該検索キーワードに関連するサイトを特定する１以上のＵＲＬの情報を取得する。検索処理部１２は、検索キーワード、ＵＲＬ、および、当該ＵＲＬのサイトにて目的が達成されたと推定されることの度合いを示す指標を記憶した検索結果ソート用ＤＢ１６を参照して、取得されたＵＲＬを、前記指標の順にソートし、ＵＲＬのソート順にしたがって、サイトを紹介するリストを含む検索結果コンテンツを生成して、クライアントマシンに提示する。
【選択図】 図１
【解決手段】検索処理部１２および検索エンジン３０は、検索キーワードを受理すると、当該検索キーワードに関連するサイトを特定する１以上のＵＲＬの情報を取得する。検索処理部１２は、検索キーワード、ＵＲＬ、および、当該ＵＲＬのサイトにて目的が達成されたと推定されることの度合いを示す指標を記憶した検索結果ソート用ＤＢ１６を参照して、取得されたＵＲＬを、前記指標の順にソートし、ＵＲＬのソート順にしたがって、サイトを紹介するリストを含む検索結果コンテンツを生成して、クライアントマシンに提示する。
【選択図】 図１
Description
【０００１】
【発明が属する技術分野】
本発明は、検索サイトにおける検索結果を提示し、ユーザによるサイト検索を支援する手法に関する。
【０００２】
【従来の技術】
インターネットの普及により、ユーザは、種々のサイトにアクセスし、その場でリアルタイムに、ユーザが求める情報を取得できるようになっている。必要な情報を含むサイトを見出すために、検索サイトの利用が最も有用である。検索サイトの使い方には、ユーザにより入力された検索キーワードに基づき、コンテンツ中に当該検索キーワードを含むようなサイトを見出すようなキーワード検索と、カテゴリを絞りつつ目的となるサイトを見出すようなディレクトリ検索とが知られている。
【０００３】
たとえば、キーワード検索の場合、ある検索キーワードを入力すると、サーバに備えられた検索エンジンが、当該検索キーワードを含むサイトを特定し、そのＵＲＬを、当該サイトの要約や、検索キーワードを含む文章などとともに、検索結果としてリスト（検索結果コンテンツ）し、クライアントマシンに返すようになっている。
【０００４】
ユーザは、それぞれのサイトの要約などを参照し、所望の情報を取得できると期待されるサイト等のリンクを指定し、そのコンテンツを取得する。ユーザは、検索結果コンテンツ中の要約などの参照、サイトへのリンク指定を繰り返して、何れかのサイトに、ユーザが所望の情報が見出された段階で、そのサイトに留まることになる。
【０００５】
【発明が解決しようとする課題】
ユーザが上記手順を繰り返して、余計な時間を費やすことなく、所望の情報が含まれるサイトに到達するためには、検索結果コンテンツ中に、ユーザが求める情報を含むサイトのリストが、より上位に位置し、或いは、より目立つ状態であるのが望ましい。
【０００６】
従来の検索エンジンにおいては、たとえば、サイト中に、どのくらい多数の検索キーワードが含まれているかに応じて、リストの配置を決定し、または、サイトの支持率、つまり、そのサイトがどのくらい他のサイトからリンクされているかにしたがって、リストの配置を決定している。たとえば、前者では、検索キーワードの出現頻度が多いものは、当該検索キーワードとの関連が深く、適切なサイトであるという仮定に基づいている。また、後者では、他のサイトからのリンクがそのサイトを評価している指標になるという仮定に基づいている。
【０００７】
また、知識ベースを利用し、ユーザが入力した検索キーワードの上位概念に対応する語句を見出し、その語句を含むサイトのリストを生成し、ユーザの検索キーワードの選択を実質的に補助するような検索サイトも知られている。
しかしながら、従来の検索サイトにおいては、主として出現頻度や支持率に基づく仮定により、リストの順位を決定しているため、実際に、ユーザには、どのサイトに、有用な情報が含まれていたかを知ることができなかった。このため、たとえば、下位にリストされているにもかかわらず、数多くのユーザがそこから所望の情報を得ているようなサイトを、ユーザに適切に紹介することができず、このため、ユーザに余分な検索時間や検索の労力を負わせることになるという問題点があった。
【０００８】
本発明は、ユーザが所望の情報を、より容易に見出すことができるような検索結果を提示することができる検索支援方法を提供することを目的とする。
【０００９】
【課題を解決するための手段】
本発明の目的は、１以上の検索キーワードを受理して、当該検索キーワードに関連するサイトの情報のリストを生成して、ユーザの操作するクライアントマシンに提示する検索支援方法であって、検索キーワードを受理し、当該検索キーワードに関連するサイトを特定する１以上のＵＲＬの情報を取得するステップと、前記検索キーワード、ＵＲＬ、および、当該ＵＲＬのサイトにて目的が達成されたと推定されることの度合いを示す指標を記憶したソート用データベースを参照して、前記取得されたＵＲＬを、前記指標の順にソートするステップと、前記ＵＲＬのソート順にしたがって、前記サイトを紹介するリストを含む検索結果コンテンツを生成し、クライアントマシンに提示するステップと、前記クライアントマシンにおける前記コンテンツ中、特定のサイトのリンク指定を受理して、前記サイトのＵＲＬを取得し、アクセスログデータベースに記憶するとともに、リダイレクトにより、前記サイトのコンテンツのクライアントマシンへの配信を求めるステップと、前記アクセスログデータベースを参照して、前記取得されたＵＲＬのうち、ある検索キーワードを用いた検索においてユーザが目的を達成したと推定されるサイトのＵＲＬを特定するステップと、前記検索キーワードに関して、目的を達成したと推定されるサイトのＵＲＬに関する指標を再計算し、前記ソート用データベースを更新するステップとを備えたことを特徴とする検索支援方法により達成される。
【００１０】
本発明によれば、検索キーワードに関連するサイトが、ユーザが目的を達成したと推定される、つまり、所望の情報が取得されたと推定される度合いを示す指標が大きいものの順にリストされた形式の検索結果コンテンツがユーザに配信される。たとえば、上記指標の大きいものから順に、サイトの紹介をリストしても良いし、或いは、指標の大きいものをより目立つような表示を施しても良い。指標の大きなサイトを閲覧することで、ユーザは所望の情報を短時間で取得できる可能性を高めることが可能となる。
【００１１】
上記ソート用データベースを更新するステップは、たとえば、夜間などのバッチ処理で実行され、その一方、他のステップは、ユーザが検索を実行している際に、リアルタイム処理で実行され得る。
【００１２】
好ましい実施態様においては、さらに、ユーザのアクセスごとに検索ＩＤを発行するステップを備え、前記検索結果コンテンツに基づくリンクの指定が維持される限り、同一の検索ＩＤを利用するとともに、前記ソート用データベースを更新するステップが、各検索ＩＤに関して指標を再計算するステップを含む。
【００１３】
また、好ましい実施態様においては、さらに、ある検索において、リンク指定の回数を、前記アクセスログデータベースに記憶するステップを備え、ユーザの検索傾向を示すアクセス回数上限値を記憶した検索傾向データベースを参照して、前記リンク指定の回数が、前記アクセス回数上限値を超えた場合に、当該検索におけるＵＲＬを、前記指標の再計算には考慮しないように構成されている。この検索傾向データベースも、アクセスログデータベースを参照して、バッチ処理にて更新されうる。これにより、上記アクセス回数上限値もダイナミックに更新され得る。
【００１４】
これは、ユーザによる検索の癖（傾向）を把握し、その傾向から逸脱しているような検索を無視している。これにより、指標の算出精度を高めることが可能となる。前記アクセス回数上限値として、当該ユーザによる検索ごとのリンク指定の回数の情報信頼限界を利用することができる。なお、検索キーワードをカテゴライズし、カテゴリごとにアクセス回数上限値を別途設定しても良い。
別の好ましい実施態様において、前記目的を達成したと推定されるサイトのＵＲＬを特定するステップにおいて、ある検索において、あるリンク指定から、一定の時間、他のリンク指定がなされていない状態である場合に、当該リンク指定にかかるＵＲＬが、前記目的を達成したと推定されるものとして特定される。
【００１５】
また、好ましい実施態様においては、前記指標が、ある検索において目的を達成したと推定されるサイトごとに加点されるポイントである。
より好ましい実施態様においては、さらに、取得されたＵＲＬの情報のうち、前記ソート用データベース中に存在しないものについて、当該ＵＲＬのサイトに含まれる検索キーワードの出現頻度や当該ＵＲＬのサイトの支持率を含む他の論理に基づく順序で、当該リストを含むコンテンツを生成するステップを備えている。
【００１６】
【発明の実施の形態】
以下、添付図面を参照して、本発明の実施の形態につき説明を加える。図１は、本発明の実施の形態にかかる検索支援サーバ（以下、「サーバ」と称する。）の構成を示すブロックダイヤグラムである。図１に示すサーバは、ネットワーク、たとえば、インターネットに接続され、クライアントマシンから与えられるキーワードを受理して、関連するサイトを検索し、サイトの情報を含む検索結果をコンテンツとしてクライアントマシンに返すようになっている。なお、本明細書において、サイトとは、ウェブページの集合体、当該集合体のトップページ、集合体を構成するそれぞれのウェブページを指すものとする。
【００１７】
図１に示すように、本実施の形態にかかるサーバ１０は、ユーザが入力したキーワードを、インターネットを介して受理し、サイト検索に関する種々の処理を実行する検索処理部１２と、アクセスしてくるユーザが、どのようなキーワードを利用したかを示す情報を記憶した検索リクエストデータベース（ＤＢ）１４と、検索結果を提示するために利用される、キーワードおよびＵＲＬの組のそれぞれについて付与されたポイントを記憶した検索結果ソート用ＤＢ１６と、ユーザがクライアントマシンを操作することにより、サーバに与えられる、他のサイトへのアクセス要求を受理し、ユーザによるアクセスログを取得するアクセスログ取得処理部１８と、ユーザによるアクセスログを記憶するサイトアクセスログＤＢ２０と、ユーザによるアクセスログやユーザが利用した検索キーワードなど、種々のアクセス履歴にしたがって、適切な検索結果の提示のために必要なデータを用意する処理を実行するバッチ処理部２２と、ユーザによる検索傾向を記憶した検索傾向ＤＢ２４とを有している。
【００１８】
また、検索処理部１２には、実際に、検索キーワードを参照して、当該検索キーワードに関連するサイトのＵＲＬを取得する検索エンジン３０が接続されている。検索エンジン３０は、サーバ１０に含まれていても良いし、サーバ１０と別体であっても良い。
【００１９】
このように構成されたサーバ１０を利用した検索およびサイトへのアクセスにつき、図２を参照して説明を加える。ユーザがクライアントマシンを操作して、検索キーワードを入力すると、当該検索キーワードがサーバに伝達される（ステップ２０１）。サーバ１０においては、後述する検索処理が実行され（ステップ２０２）、検索結果がリストされたコンテンツ（結果コンテンツ）が、クライアントマシンに返される（ステップ２０３）。
【００２０】
結果コンテンツには、サイト名や、検索キーワードを含むサイト中の文字列などが示される。本実施の形態においては、ユーザが、サイト名をクリックしても、直接、そのサイトのＵＲＬにアクセス要求が伝達されるのではなく、いったん、サーバ１０を介して、当該サイトへのアクセス要求が伝達されるようになっている。このため、サイト指定（アクセス要求）は、サーバ１０に伝えられ（ステップ２０４）、サーバ１０において、ユーザがアクセスを要求したＵＲＬを含むアクセスログが取得された後（ステップ２０５）、いわゆるリダイレクト処理により、サーバ１０から、指定された他のサイトへのアクセス要求が発せられる（ステップ２０６）。他のサイトからのコンテンツは、クライアントマシンに配信され（ステップ２０８）、クライアントマシンのブラウザにより、その表示装置の画面上にコンテンツが表示される。
【００２１】
たとえば、ユーザが入力装置を操作して、ブラウザのバックボタン（「戻る」ボタン）をオンすれば、再度、検索結果がリストされた結果コンテンツが表示される。その状態で、ユーザが、入力装置を操作してサイトを指定すると（ステップ２０９）、再度、アクセスログ取得処理（ステップ２１０）、他のサイトへのアクセス要求（ステップ２１１）が実行されて、指定されたコンテンツがクライアントマシンに配信される（ステップ２１２）。
このように、結果コンテンツにリストされたサイト名などのリンクを指定することにより、サーバ１０は、ユーザが閲覧しようとしたサイトのＵＲＬを含むアクセスログを取得し、これを蓄積することができる。
【００２２】
次に、本実施の形態にかかる検索処理をより詳細に説明する。図３は、本実施の形態にかかる検索処理を示すフローチャートである。検索処理部１２は、クライアントマシンからの検索キーワードの受理に応答して、まず、当該クライアントマシンを利用してユーザにより既にサーバにアクセスされ、ユーザに、ユーザＩＤを含むＣｏｏｋｉｅ（クッキー）が送信されているか否かを判断する（ステップ３０１）。ユーザＩＤが存在しない場合には、当該クライアントマシンを操作しているユーザに対してユーザＩＤを発番する（ステップ３０２）。
【００２３】
次いで、今回の検索行為を一意的に特定するための検索ＩＤが発番される（ステップ３０３）。この検索ＩＤは、クライアントマシンから、ある検索キーワード（単一の検索キーワード、或いは、複数の検索キーワードの組み合わせ、以後、本明細書において同様である。）がサーバ１０に与えられ、当該検索キーワードに基づく検索結果に基づいて、クライアントマシンから、サイト指定がサーバ１０に与えられる間だけ維持される。つまり、検索ＩＤと検索キーワードとは、一意的に関連付けされている。したがって、ユーザが、新たな検索キーワードを入力し、或いは、ある検索キーワードに、さらに他の検索キーワードを付加した場合には、異なる検索ＩＤが付与される。
【００２４】
次いで、ユーザが入力した検索キーワードが、それぞれ正規化され、その後、ソートされる（ステップ３０４、３０５）。ステップ３０４においては、正規化により、ユーザごとの入力によるゆらぎ（たとえば、全角入力／半角入力、英大文字／小文字など）が、一定の基準にて統一された表現とされる。また、ユーザが、複数の検索キーワードをスペース等で区切って入力する場合がある。この場合には、入力された複数の検索キーワードの「ＡＮＤ」検索となる。このように入力キーワードが複数である場合に、ステップ３０５のソート処理によりユーザが入力した語順にかかわらず、同一の検索キーワードであれば、同じ検索結果が得られるようにしている。
【００２５】
次いで、ログデータを保持するために、正規化およびソート処理が施された検索キーワードのレコードが、検索リクエストＤＢ１４に追加される。図４（ａ）は、検索リクエストＤＢ１４中に記憶されるデータの例を示す図である。図４（ａ）に示すように、検索リクエストＤＢ１４においては、検索ＩＤごとに、その検索に利用された検索キーワードが関連付けられて記憶されている。また、後述する処理により、当該検索キーワードによる検索結果を利用して、ユーザが何回、リンクを指定したかを示す検索回数が、検索ＩＤごとに算出されて記憶される。初期的には、検索回数は「０（ゼロ）」に設定される。
また、前述したように、検索キーワードの入力や追加ごとに検索ＩＤが発番されるため、あるユーザＩＤ（たとえば、ユーザＩＤ＝ＧＡＷ００２３５１４）に対して、複数の検索ＩＤが存在し得る。
【００２６】
次いで、検索エンジン３０が、正規化およびソートされた検索キーワードを利用して、当該検索キーワードに関連したサイトを検索する（ステップ３０７）。検索エンジン３０による検索結果を示すリストには、一定の順序でサイトのＵＲＬが挙げられている。この順序として、たとえば、サイトがどの程度支持されているか（そのサイトへのリンクがどのくらい存在しているか）、キーワードの出現頻度などが利用されている。
【００２７】
検索エンジン３０からの検索結果を受理すると、検索処理部１２は、検索結果ソート用ＤＢ１６を参照して、今回の検索ＩＤにかかる検索キーワードが、検索結果ソート用ＤＢ１６中に存在するか否かを判断する（ステップ３０８、３０９）。図４（ｂ）は、検索結果ソート用ＤＢ１６のデータの例を示す図である。検索ソート用ＤＢ１６においては、検索キーワードおよびＵＲＬの組み合わせと、ポイントとが関連付けられている。ここで、ポイントは、後述するポイント付与処理（図１０参照）により生成された、ある検索キーワードにて見出されるＵＲＬが、どの程度有用であるかを示す指標である。
【００２８】
ステップ３０９でイエス（Ｙｅｓ）と判断された場合には、検索処理部１２は、受理した検索結果に含まれるＵＲＬを、ポイントの高い順にソートし（ステップ３１０）、かつ、検索結果ソート用ＤＢ１６の検索キーワードに関連付けられていないＵＲＬに関しては、受理した検索結果の順序で、ＵＲＬのリストを生成する（ステップ３１１）。その一方、ステップ３０９でノー（Ｎｏ）と判断された場合には、受理した検索結果の順序で、ＵＲＬのリストを生成する（ステップ３１１）。このようにして、検索結果コンテンツが生成される。
【００２９】
前述したように、ユーザのサイト指定に応答して、サーバ１０においてアクセス取得処理が実行されて（ステップ２０５）、アクセスログが取得されるとともに、リダイレクト処理により、ユーザが指定したサイトから、クライアントマシンにコンテンツが配信される（ステップ２０６、２０７）。図５は、アクセスログ取得処理をより詳細に示すフローチャートである。
【００３０】
アクセスログ取得処理部１８は、受理した情報に基づき、サイトアクセスログＤＢ２０に、当該サイト指定にかかるレコードを追加する（ステップ５０１）。図８（ａ）は、サイトアクセスログＤＢ２０中に記憶されたデータの例を示す図である。図８（ａ）に示すように、サイトアクセスログＤＢ２０においては、検索ＩＤ、連番、ＵＲＬおよびアクセスログ日時の組からなるレコードが記憶される。本実施の形態においては、図２に示したように、ある検索結果コンテンツが提示されている状態から、サイト指定、アクセスログ取得処理、コンテンツ配信が繰り返され得る（ステップ２０４〜２０７、および、ステップ２０９〜２１２参照）。そこで、アクセスログ取得処理部１８は、ある検索ＩＤに関して、ユーザがサイト指定をするたびに、インクリメントされた連番を採番して、これを含むレコードを生成し、サイトアクセスログＤＢ２０に追加する。
【００３１】
次いで、リダイレクト処理（ステップ５０２）により、ユーザが指定したサイトに対して、クライアントマシンに対するコンテンツの配信を要求する。これに応じて、指定されたサイトからクライアントマシンにコンテンツが配信され、クライアントマシンのブラウザによりこれが表示される。
【００３２】
クライアントマシンからのアクセスに応答して、サーバ１０は、上述した処理を実行する。その一方、サーバ１０は、夜間など所定のタイミングで、バッチ処理を実行し、サイトアクセスログＤＢ２０や検索リクエストＤＢ１４からのデータを取得して、検索傾向ＤＢ２４や検索結果ソート用ＤＢ１６を更新している。図６は、バッチ処理を示すフローチャートである。バッチ処理においては、検索ＩＤ抽出処理（ステップ６０１）および検索傾向算出処理（ステップ６０２）が実行される。
【００３３】
検索ＩＤ抽出処理においては、後述する前回抽出対象日時ファイル６１１に基づいて、処理対象となるレコードを、サイトアクセスログＤＢ２０から抽出し、今回抽出サイトアクセスログファイル６１２を生成する。また、検索傾向算出処理においては、検索リクエストＤＢ１４から、各ユーザに関するレコードを取り出して、当該ユーザの検索の癖（傾向）を示す指標を算出して、検索傾向ＤＢ２４を更新するとともに、検索結果ソート用ＤＢ１６を更新する。
【００３４】
これらにつき、図７、図８および図１０を参照してより詳細に説明を加える。図７に示すように、検索ＩＤ抽出処理においては、まず、バッチ処理部２２は、前回抽出対象日時ファイル６１１から、前回抽出対象となった、サイトアクセスログＤＢ２０中のレコードのアクセス日時の上限値を取得する（ステップ７０１）。ここで、前回抽出対象日時とは、前回バッチ処理において処理対象とすべきアクセス日時の上限値（前回バッチ処理開始日時−６時間）を言う。本実施の形態においては、検索ＩＤにて特定されるある検索行為において、最も大きい連番を有するアクセスのアクセス日時が、前回抽出対象日時より大きく、かつ、今回バッチ処理開始日時からすでに６時間を経過した場合に、抽出対象となっている。したがって、アクセスログ抽出処理（ステップ７０２）においては、検索条件として、「前回抽出対象日時＜ある検索ＩＤに関して最終連番を有するレコードにおけるアクセス日時≦現在時刻−６時間」を利用し、当該検索条件を満たす検索ＩＤをもつレコードが抽出される。
【００３５】
たとえば、図１１に示すように、ある検索ＩＤ（たとえば、検索ＩＤ＝ＧＡＷ００２３５１４０００００１）に関して、連番４ないし連番６がそれぞれ付与されたアクセス（符号１１０４〜１１０６参照）があったと考える。この場合には、前回のバッチ処理開始日時（符号１１１０参照）の「現在時刻−６時間」、つまり、前回抽出対象日時（符号１１１１参照）以後に、連番５のアクセスが存在している。したがって、前回のバッチ処理時においては、当該検索ＩＤを有するアクセスは、抽出対象とはならない。その一方、当該検索ＩＤの連番６のアクセス（符号１１０６参照）は、今回のバッチ処理時において検索条件を満たすため、当該検索ＩＤを有するアクセスは、すべて抽出対象となる。同様に、他の検索ＩＤ（たとえば、検索ＩＤ＝ＧＡＷ００２３５１４０００００２）に関して、連番１が付与されたアクセス（符号１１２１参照）が、「現在時刻（今回バッチ処理開始日時）−６時間」より以前に存在するため、この検索ＩＤを有するレコードは抽出対象たり得る。
【００３６】
このように、現在時刻（今回バッチ処理開始日時）から一定の時間（本実施の形態では６時間）以前に、最終の連番が存在する場合のみ、検索ＩＤにかかるレコードを抽出する理由につき説明を加える。図２を参照して説明したように、本実施の形態においては、ユーザが、ある検索キーワードを入力し、その検索結果を受けた後、当該ユーザが、いくつかのサイトを閲覧し、閲覧したサイトに、実際にユーザが求めている情報が含まれている場合には、そのサイトに留まること、つまり、他のサイトを閲覧しないと想像される。そこで、本実施の形態においては、サイトに留まっていると判断するために、一定の時間が設定されている。
【００３７】
このようにして、今回抽出サイトのアクセスログのファイル６１２が作成されると、検索回数更新処理が実行される（ステップ７０３）。検索回数更新処理７０３においては、今回抽出サイトアクセルログファイル６１２中のレコード数を、検索ＩＤごとにカウントする。たとえば、図１１の例では、今回のバッチ処理において、検索ＩＤ＝ＧＡＷ０２３５１４０００００１のカウント値は、当該検索ＩＤの連番が６まであるため、６となる。その一方、検索ＩＤ＝００２３５１４０００００２のカウント値は１となる。このカウント値は、検索リクエストＤＢ１４中の、対応する検索ＩＤの検索回数として記憶される。
【００３８】
次に、図９を参照して、検索傾向算出処理につき説明を加える。検索傾向算出処理においては、まず、検索ＩＤをキーとして、検索リクエストＤＢ１４中のデータがソートされる（ステップ９０１）。これは、ソート後の検索リクエストＤＢ中のデータがなくなるまで繰り返される。次いで、ユーザＩＤ単位で、当該ユーザＩＤに関する全検索ＩＤのもつ検索回数の平均値と標準偏差が算出される（ステップ９０２）。その後、ユーザＩＤごとのアクセス回数上限値が算出され、これが検索傾向ＤＢ２４に、ユーザＩＤと関連付けて記憶される（ステップ９０３）。
【００３９】
本実施の形態においては、ユーザ単位で、単一の検索キーワードを利用した検索回数は正規分布すると考え、信頼係数９５パーセントとして、情報信頼限界（＝１．９６×標準偏差＋平均値）を算出し、これを当該ユーザのアクセス回数上限値とした。本実施の形態においては、このアクセス回数上限値が、ユーザの検索の癖（傾向）を示す指標となる。
【００４０】
次いで、全ユーザのアクセス回数の平均値が算出され（ステップ９０５）、これも、検索傾向ＤＢ２４に記憶される。なお、図８（ｂ）において、ユーザＩＤ＝００００００００００に対応したアクセス回数上限値が、ステップ９０５で算出された平均値である。この平均値は、サーバ１０に初めてアクセスしたため、そのアクセス回数上限値が設定されていないようなユーザのためのデフォルト値として利用することができる。
【００４１】
検索傾向ＤＢ２４の更新が終了すると、検索ＩＤ抽出処理が実行される（ステップ９０５）。ここでは、検索傾向ＤＢを参照しつつ、ユーザＩＤごとに、当該ユーザのアクセス回数上限値以内の検索回数であるような、検索ＩＤおよび検索キーワードの組を、検索リクエストＤＢ１４から抽出し、検索ＩＤおよび検索キーワードの組からなるファイル９１１が生成される。このファイル９１１を利用して、ポイント付与処理が実行される（ステップ９０６）。
【００４２】
図１０は、ポイント付与処理をより詳細に示すフローチャートである。まず、ファイル９１１について、検索キーワードをキーとしてソートし、検索キーワードおよび検索ＩＤの組からなるファイル１０１１が生成される。これは、ソートし直したファイルのデータがなくなるまで継続される（ステップ１０１１、１００２）。次いで、検索ＩＤごとに、サイトアクセスログＤＢ２０を参照して、当該検索ＩＤが最終的にアクセスしたログ（ＵＲＬ）が取得される（ステップ１００３）。これにより、検索キーワード、検索ＩＤおよびＵＲＬの組からなるファイル１０１２が生成される。このファイル１０１２を参照して、当該ファイル１０１２中のある検索キーワードおよびＵＲＬが、検索結果ソート用ＤＢ１６中に存在するか否かが判断される（ステップ１００４、１００５）。すでに上記組み合わせが存在する場合には（ステップ１００５でイエス（Ｙｅｓ））、検索結果ソート用ＤＢ１６中、対応するレコードにおけるポイントがインクリメントされる（ステップ１００６）。その一方、ステップ１００５でノー（Ｎｏ）と判断された場合には、上記検索キーワードおよびＵＲＬの組み合わせを含むレコードが、検索結果ソート用ＤＢ１６中に生成され、かつ、その対応するポイントが１に設定される（ステップ１００７）。
【００４３】
このようにして、各種ＤＢのデータを更新するバッチ処理が終了する。再度、図３を参照して、これら更新されたデータがどのように利用されるかにつき簡単に説明する。ステップ３０７において検索エンジン３０から検索結果が検索処理部１２に返される。検索処理部１２は、検索結果ソート用ＤＢ１６中、検索キーワードに関連付けられたＵＲＬであって、検索結果と一致するものを見出して、それらを、ポイントの高いものから順に並べてリストする。これにより、ポイントの高いもの、つまり、他のユーザによる検索結果の蓄積から、有用と考えられる度合いの大きいものから順に、サイトの情報がリストされることになる。これにより、ユーザは、リストの上位に位置しているものから順次、サイトを指定して、その内容を閲覧し、ユーザが求める情報が含まれるか否かを判断すれば良い。この場合にも、あまりサイト指定を繰り返すことなく、所望の情報が含まれるサイトを見出すことができる可能性が高いことが期待される。
【００４４】
このように、本実施の形態によれば、過去にユーザが検索を実行し、どのサイトで目的の情報を見出されたかを推定し、その推定から、検索キーワードおよびサイト（ＵＲＬ）にポイントを付与し、このポイントを利用して、後の検索におけるサイトの提示順序を決定している。したがって、たとえば、上位にリストされたサイトを指定すれば、ユーザが所望の情報を見出すことができる確率が高まり、ユーザが、情報を見出すために何度もサイトを行き来するような手間を減じることが可能となる。
【００４５】
また、本実施の形態によれば、検索傾向ＤＢに、各ユーザの検索の癖を示す指標である検索回数を利用し、この検索回数を超えてサイト指定を繰り返している場合には、この検索は信頼できないものとして考慮しないように構成している。これにより、上記ポイントの信頼性を高めることが可能となる。また、上記検索回数を、バッチ処理により更新することにより、データの信頼性をより高めている。
【００４６】
本発明は、以上の実施の形態に限定されることなく、特許請求の範囲に記載された発明の範囲内で、種々の変更が可能であり、それらも本発明の範囲内に包含されるものであることは言うまでもない。
たとえば、単一のユーザＩＤをもつユーザ（単一のユーザ）が、異なる検索ＩＤを付与された検索において、同一の検索キーワードを利用する場合も考えられる。この場合に、本実施の形態のように、異なる検索ＩＤであれば、異なるものとして処理しても良い。或いは、所定の時間内或いは所定のセッション内に、同一の検索キーワードが利用された場合には、アクセスログをマージして、最終的なＵＲＬのみを保持するように構成しても良い。
【００４７】
また、前記実施の形態において、サイトアクセスログＤＢには、ある検索ＩＤに関してサイト指定されたＵＲＬの全てが、一意的な連番とともに記憶されているが、これに限定されるものではなく、最新の連番および最新のＵＲＬのみを記憶するような構成としても良い。
【００４８】
さらに、前記実施の形態においては、検索結果ソート用ＤＢにおいて、単一の検索キーワード（たとえば、「Ｃ＋＋」、「Ｃ」など）、複数の検索キーワードからなる複合語（たとえば、「Ｃ＋＋およびＣ」など）のそれぞれについて、ＵＲＬおよびポイントが保持されている。しかしながら、これに限定されるものではなく、単一の検索キーワードに関して、ＵＲＬおよびポイントを保持しても良い。この場合には、ポイント付与処理において、複数の検索キーワードのそれぞれに関して、ＵＲＬにポイントを付与すればよい。また、検索処理においても、複数の検索キーワードのそれぞれに関連付けられるＵＲＬを見出し、それらのポイントの加算値、平均値などを利用して、複数の検索キーワードに関するＵＲＬのポイントを求め、そのポイントの上位から、ＵＲＬをリストしても良い。
【００４９】
また、アクセス回数上限値を、キーワードのカテゴリに応じて、別途設定しても良い。たとえば、同じユーザであっても、ビジネスユースであれば、所望の情報を得るために検索回数が上昇し、その一方、趣味など個人的な利用であれば、検索回数が少なくなる傾向がある。そこで、検索キーワードを、主としてビジネスにて利用されるものと、主として趣味で利用されるものにカテゴライズし、それぞれに応じたアクセス回数上限値を設定することもできる。
【００５０】
【発明の効果】
本発明によれば、ユーザが所望の情報を、より容易に見出すことができるような検索結果を提示することができる検索支援方法を提供することが可能となる。
【図面の簡単な説明】
【図１】図１は、本発明の実施の形態にかかる検索支援サーバの構成を示すブロックダイヤグラムである。
【図２】図２は、本実施の形態にかかるサーバを利用した検索およびサイトへのアクセスを示すフローチャートである。
【図３】図３は、本実施の形態にかかる検索処理をより詳細に示すフローチャートである。
【図４】図４は、検索リクエストＤＢ中に記憶されるデータ、および、検索結果ソート用ＤＢ中に記憶されるデータの例を示す図である。
【図５】図５は、本実施の形態にかかるアクセスログ取得処理をより詳細に示すフローチャートである。
【図６】図６は、本実施の形態にかかるバッチ処理の概略を示すフローチャートである。
【図７】図７は、本実施の形態にかかる検索ＩＤ抽出処理をより詳細に示すフローチャートである。
【図８】図８は、本実施の形態にかかるアクセスログＤＢ中に記憶されたデータ、および、検索傾向ＤＢ中に記憶されたデータの例を示す図である。
【図９】図９は、本実施の形態にかかる検索傾向算出処理をより詳細に示すフローチャートである。
【図１０】図１０は、本実施の形態にかかるポイント付与処理をより詳細に示すフローチャートである。
【図１１】図１１は、本実施の形態にかかるアクセスログ抽出処理を説明するための図である。
【符号の説明】
１０ 検索支援サーバ
１２ 検索処理部
１４ 検索リクエストＤＢ
１６ 検索結果ソート用ＤＢ
１８ アクセスログ取得処理部
２０ サイトアクセスログＤＢ
２２ バッチ処理部
２４ 検索傾向ＤＢ
３０ 検索エンジン
【発明が属する技術分野】
本発明は、検索サイトにおける検索結果を提示し、ユーザによるサイト検索を支援する手法に関する。
【０００２】
【従来の技術】
インターネットの普及により、ユーザは、種々のサイトにアクセスし、その場でリアルタイムに、ユーザが求める情報を取得できるようになっている。必要な情報を含むサイトを見出すために、検索サイトの利用が最も有用である。検索サイトの使い方には、ユーザにより入力された検索キーワードに基づき、コンテンツ中に当該検索キーワードを含むようなサイトを見出すようなキーワード検索と、カテゴリを絞りつつ目的となるサイトを見出すようなディレクトリ検索とが知られている。
【０００３】
たとえば、キーワード検索の場合、ある検索キーワードを入力すると、サーバに備えられた検索エンジンが、当該検索キーワードを含むサイトを特定し、そのＵＲＬを、当該サイトの要約や、検索キーワードを含む文章などとともに、検索結果としてリスト（検索結果コンテンツ）し、クライアントマシンに返すようになっている。
【０００４】
ユーザは、それぞれのサイトの要約などを参照し、所望の情報を取得できると期待されるサイト等のリンクを指定し、そのコンテンツを取得する。ユーザは、検索結果コンテンツ中の要約などの参照、サイトへのリンク指定を繰り返して、何れかのサイトに、ユーザが所望の情報が見出された段階で、そのサイトに留まることになる。
【０００５】
【発明が解決しようとする課題】
ユーザが上記手順を繰り返して、余計な時間を費やすことなく、所望の情報が含まれるサイトに到達するためには、検索結果コンテンツ中に、ユーザが求める情報を含むサイトのリストが、より上位に位置し、或いは、より目立つ状態であるのが望ましい。
【０００６】
従来の検索エンジンにおいては、たとえば、サイト中に、どのくらい多数の検索キーワードが含まれているかに応じて、リストの配置を決定し、または、サイトの支持率、つまり、そのサイトがどのくらい他のサイトからリンクされているかにしたがって、リストの配置を決定している。たとえば、前者では、検索キーワードの出現頻度が多いものは、当該検索キーワードとの関連が深く、適切なサイトであるという仮定に基づいている。また、後者では、他のサイトからのリンクがそのサイトを評価している指標になるという仮定に基づいている。
【０００７】
また、知識ベースを利用し、ユーザが入力した検索キーワードの上位概念に対応する語句を見出し、その語句を含むサイトのリストを生成し、ユーザの検索キーワードの選択を実質的に補助するような検索サイトも知られている。
しかしながら、従来の検索サイトにおいては、主として出現頻度や支持率に基づく仮定により、リストの順位を決定しているため、実際に、ユーザには、どのサイトに、有用な情報が含まれていたかを知ることができなかった。このため、たとえば、下位にリストされているにもかかわらず、数多くのユーザがそこから所望の情報を得ているようなサイトを、ユーザに適切に紹介することができず、このため、ユーザに余分な検索時間や検索の労力を負わせることになるという問題点があった。
【０００８】
本発明は、ユーザが所望の情報を、より容易に見出すことができるような検索結果を提示することができる検索支援方法を提供することを目的とする。
【０００９】
【課題を解決するための手段】
本発明の目的は、１以上の検索キーワードを受理して、当該検索キーワードに関連するサイトの情報のリストを生成して、ユーザの操作するクライアントマシンに提示する検索支援方法であって、検索キーワードを受理し、当該検索キーワードに関連するサイトを特定する１以上のＵＲＬの情報を取得するステップと、前記検索キーワード、ＵＲＬ、および、当該ＵＲＬのサイトにて目的が達成されたと推定されることの度合いを示す指標を記憶したソート用データベースを参照して、前記取得されたＵＲＬを、前記指標の順にソートするステップと、前記ＵＲＬのソート順にしたがって、前記サイトを紹介するリストを含む検索結果コンテンツを生成し、クライアントマシンに提示するステップと、前記クライアントマシンにおける前記コンテンツ中、特定のサイトのリンク指定を受理して、前記サイトのＵＲＬを取得し、アクセスログデータベースに記憶するとともに、リダイレクトにより、前記サイトのコンテンツのクライアントマシンへの配信を求めるステップと、前記アクセスログデータベースを参照して、前記取得されたＵＲＬのうち、ある検索キーワードを用いた検索においてユーザが目的を達成したと推定されるサイトのＵＲＬを特定するステップと、前記検索キーワードに関して、目的を達成したと推定されるサイトのＵＲＬに関する指標を再計算し、前記ソート用データベースを更新するステップとを備えたことを特徴とする検索支援方法により達成される。
【００１０】
本発明によれば、検索キーワードに関連するサイトが、ユーザが目的を達成したと推定される、つまり、所望の情報が取得されたと推定される度合いを示す指標が大きいものの順にリストされた形式の検索結果コンテンツがユーザに配信される。たとえば、上記指標の大きいものから順に、サイトの紹介をリストしても良いし、或いは、指標の大きいものをより目立つような表示を施しても良い。指標の大きなサイトを閲覧することで、ユーザは所望の情報を短時間で取得できる可能性を高めることが可能となる。
【００１１】
上記ソート用データベースを更新するステップは、たとえば、夜間などのバッチ処理で実行され、その一方、他のステップは、ユーザが検索を実行している際に、リアルタイム処理で実行され得る。
【００１２】
好ましい実施態様においては、さらに、ユーザのアクセスごとに検索ＩＤを発行するステップを備え、前記検索結果コンテンツに基づくリンクの指定が維持される限り、同一の検索ＩＤを利用するとともに、前記ソート用データベースを更新するステップが、各検索ＩＤに関して指標を再計算するステップを含む。
【００１３】
また、好ましい実施態様においては、さらに、ある検索において、リンク指定の回数を、前記アクセスログデータベースに記憶するステップを備え、ユーザの検索傾向を示すアクセス回数上限値を記憶した検索傾向データベースを参照して、前記リンク指定の回数が、前記アクセス回数上限値を超えた場合に、当該検索におけるＵＲＬを、前記指標の再計算には考慮しないように構成されている。この検索傾向データベースも、アクセスログデータベースを参照して、バッチ処理にて更新されうる。これにより、上記アクセス回数上限値もダイナミックに更新され得る。
【００１４】
これは、ユーザによる検索の癖（傾向）を把握し、その傾向から逸脱しているような検索を無視している。これにより、指標の算出精度を高めることが可能となる。前記アクセス回数上限値として、当該ユーザによる検索ごとのリンク指定の回数の情報信頼限界を利用することができる。なお、検索キーワードをカテゴライズし、カテゴリごとにアクセス回数上限値を別途設定しても良い。
別の好ましい実施態様において、前記目的を達成したと推定されるサイトのＵＲＬを特定するステップにおいて、ある検索において、あるリンク指定から、一定の時間、他のリンク指定がなされていない状態である場合に、当該リンク指定にかかるＵＲＬが、前記目的を達成したと推定されるものとして特定される。
【００１５】
また、好ましい実施態様においては、前記指標が、ある検索において目的を達成したと推定されるサイトごとに加点されるポイントである。
より好ましい実施態様においては、さらに、取得されたＵＲＬの情報のうち、前記ソート用データベース中に存在しないものについて、当該ＵＲＬのサイトに含まれる検索キーワードの出現頻度や当該ＵＲＬのサイトの支持率を含む他の論理に基づく順序で、当該リストを含むコンテンツを生成するステップを備えている。
【００１６】
【発明の実施の形態】
以下、添付図面を参照して、本発明の実施の形態につき説明を加える。図１は、本発明の実施の形態にかかる検索支援サーバ（以下、「サーバ」と称する。）の構成を示すブロックダイヤグラムである。図１に示すサーバは、ネットワーク、たとえば、インターネットに接続され、クライアントマシンから与えられるキーワードを受理して、関連するサイトを検索し、サイトの情報を含む検索結果をコンテンツとしてクライアントマシンに返すようになっている。なお、本明細書において、サイトとは、ウェブページの集合体、当該集合体のトップページ、集合体を構成するそれぞれのウェブページを指すものとする。
【００１７】
図１に示すように、本実施の形態にかかるサーバ１０は、ユーザが入力したキーワードを、インターネットを介して受理し、サイト検索に関する種々の処理を実行する検索処理部１２と、アクセスしてくるユーザが、どのようなキーワードを利用したかを示す情報を記憶した検索リクエストデータベース（ＤＢ）１４と、検索結果を提示するために利用される、キーワードおよびＵＲＬの組のそれぞれについて付与されたポイントを記憶した検索結果ソート用ＤＢ１６と、ユーザがクライアントマシンを操作することにより、サーバに与えられる、他のサイトへのアクセス要求を受理し、ユーザによるアクセスログを取得するアクセスログ取得処理部１８と、ユーザによるアクセスログを記憶するサイトアクセスログＤＢ２０と、ユーザによるアクセスログやユーザが利用した検索キーワードなど、種々のアクセス履歴にしたがって、適切な検索結果の提示のために必要なデータを用意する処理を実行するバッチ処理部２２と、ユーザによる検索傾向を記憶した検索傾向ＤＢ２４とを有している。
【００１８】
また、検索処理部１２には、実際に、検索キーワードを参照して、当該検索キーワードに関連するサイトのＵＲＬを取得する検索エンジン３０が接続されている。検索エンジン３０は、サーバ１０に含まれていても良いし、サーバ１０と別体であっても良い。
【００１９】
このように構成されたサーバ１０を利用した検索およびサイトへのアクセスにつき、図２を参照して説明を加える。ユーザがクライアントマシンを操作して、検索キーワードを入力すると、当該検索キーワードがサーバに伝達される（ステップ２０１）。サーバ１０においては、後述する検索処理が実行され（ステップ２０２）、検索結果がリストされたコンテンツ（結果コンテンツ）が、クライアントマシンに返される（ステップ２０３）。
【００２０】
結果コンテンツには、サイト名や、検索キーワードを含むサイト中の文字列などが示される。本実施の形態においては、ユーザが、サイト名をクリックしても、直接、そのサイトのＵＲＬにアクセス要求が伝達されるのではなく、いったん、サーバ１０を介して、当該サイトへのアクセス要求が伝達されるようになっている。このため、サイト指定（アクセス要求）は、サーバ１０に伝えられ（ステップ２０４）、サーバ１０において、ユーザがアクセスを要求したＵＲＬを含むアクセスログが取得された後（ステップ２０５）、いわゆるリダイレクト処理により、サーバ１０から、指定された他のサイトへのアクセス要求が発せられる（ステップ２０６）。他のサイトからのコンテンツは、クライアントマシンに配信され（ステップ２０８）、クライアントマシンのブラウザにより、その表示装置の画面上にコンテンツが表示される。
【００２１】
たとえば、ユーザが入力装置を操作して、ブラウザのバックボタン（「戻る」ボタン）をオンすれば、再度、検索結果がリストされた結果コンテンツが表示される。その状態で、ユーザが、入力装置を操作してサイトを指定すると（ステップ２０９）、再度、アクセスログ取得処理（ステップ２１０）、他のサイトへのアクセス要求（ステップ２１１）が実行されて、指定されたコンテンツがクライアントマシンに配信される（ステップ２１２）。
このように、結果コンテンツにリストされたサイト名などのリンクを指定することにより、サーバ１０は、ユーザが閲覧しようとしたサイトのＵＲＬを含むアクセスログを取得し、これを蓄積することができる。
【００２２】
次に、本実施の形態にかかる検索処理をより詳細に説明する。図３は、本実施の形態にかかる検索処理を示すフローチャートである。検索処理部１２は、クライアントマシンからの検索キーワードの受理に応答して、まず、当該クライアントマシンを利用してユーザにより既にサーバにアクセスされ、ユーザに、ユーザＩＤを含むＣｏｏｋｉｅ（クッキー）が送信されているか否かを判断する（ステップ３０１）。ユーザＩＤが存在しない場合には、当該クライアントマシンを操作しているユーザに対してユーザＩＤを発番する（ステップ３０２）。
【００２３】
次いで、今回の検索行為を一意的に特定するための検索ＩＤが発番される（ステップ３０３）。この検索ＩＤは、クライアントマシンから、ある検索キーワード（単一の検索キーワード、或いは、複数の検索キーワードの組み合わせ、以後、本明細書において同様である。）がサーバ１０に与えられ、当該検索キーワードに基づく検索結果に基づいて、クライアントマシンから、サイト指定がサーバ１０に与えられる間だけ維持される。つまり、検索ＩＤと検索キーワードとは、一意的に関連付けされている。したがって、ユーザが、新たな検索キーワードを入力し、或いは、ある検索キーワードに、さらに他の検索キーワードを付加した場合には、異なる検索ＩＤが付与される。
【００２４】
次いで、ユーザが入力した検索キーワードが、それぞれ正規化され、その後、ソートされる（ステップ３０４、３０５）。ステップ３０４においては、正規化により、ユーザごとの入力によるゆらぎ（たとえば、全角入力／半角入力、英大文字／小文字など）が、一定の基準にて統一された表現とされる。また、ユーザが、複数の検索キーワードをスペース等で区切って入力する場合がある。この場合には、入力された複数の検索キーワードの「ＡＮＤ」検索となる。このように入力キーワードが複数である場合に、ステップ３０５のソート処理によりユーザが入力した語順にかかわらず、同一の検索キーワードであれば、同じ検索結果が得られるようにしている。
【００２５】
次いで、ログデータを保持するために、正規化およびソート処理が施された検索キーワードのレコードが、検索リクエストＤＢ１４に追加される。図４（ａ）は、検索リクエストＤＢ１４中に記憶されるデータの例を示す図である。図４（ａ）に示すように、検索リクエストＤＢ１４においては、検索ＩＤごとに、その検索に利用された検索キーワードが関連付けられて記憶されている。また、後述する処理により、当該検索キーワードによる検索結果を利用して、ユーザが何回、リンクを指定したかを示す検索回数が、検索ＩＤごとに算出されて記憶される。初期的には、検索回数は「０（ゼロ）」に設定される。
また、前述したように、検索キーワードの入力や追加ごとに検索ＩＤが発番されるため、あるユーザＩＤ（たとえば、ユーザＩＤ＝ＧＡＷ００２３５１４）に対して、複数の検索ＩＤが存在し得る。
【００２６】
次いで、検索エンジン３０が、正規化およびソートされた検索キーワードを利用して、当該検索キーワードに関連したサイトを検索する（ステップ３０７）。検索エンジン３０による検索結果を示すリストには、一定の順序でサイトのＵＲＬが挙げられている。この順序として、たとえば、サイトがどの程度支持されているか（そのサイトへのリンクがどのくらい存在しているか）、キーワードの出現頻度などが利用されている。
【００２７】
検索エンジン３０からの検索結果を受理すると、検索処理部１２は、検索結果ソート用ＤＢ１６を参照して、今回の検索ＩＤにかかる検索キーワードが、検索結果ソート用ＤＢ１６中に存在するか否かを判断する（ステップ３０８、３０９）。図４（ｂ）は、検索結果ソート用ＤＢ１６のデータの例を示す図である。検索ソート用ＤＢ１６においては、検索キーワードおよびＵＲＬの組み合わせと、ポイントとが関連付けられている。ここで、ポイントは、後述するポイント付与処理（図１０参照）により生成された、ある検索キーワードにて見出されるＵＲＬが、どの程度有用であるかを示す指標である。
【００２８】
ステップ３０９でイエス（Ｙｅｓ）と判断された場合には、検索処理部１２は、受理した検索結果に含まれるＵＲＬを、ポイントの高い順にソートし（ステップ３１０）、かつ、検索結果ソート用ＤＢ１６の検索キーワードに関連付けられていないＵＲＬに関しては、受理した検索結果の順序で、ＵＲＬのリストを生成する（ステップ３１１）。その一方、ステップ３０９でノー（Ｎｏ）と判断された場合には、受理した検索結果の順序で、ＵＲＬのリストを生成する（ステップ３１１）。このようにして、検索結果コンテンツが生成される。
【００２９】
前述したように、ユーザのサイト指定に応答して、サーバ１０においてアクセス取得処理が実行されて（ステップ２０５）、アクセスログが取得されるとともに、リダイレクト処理により、ユーザが指定したサイトから、クライアントマシンにコンテンツが配信される（ステップ２０６、２０７）。図５は、アクセスログ取得処理をより詳細に示すフローチャートである。
【００３０】
アクセスログ取得処理部１８は、受理した情報に基づき、サイトアクセスログＤＢ２０に、当該サイト指定にかかるレコードを追加する（ステップ５０１）。図８（ａ）は、サイトアクセスログＤＢ２０中に記憶されたデータの例を示す図である。図８（ａ）に示すように、サイトアクセスログＤＢ２０においては、検索ＩＤ、連番、ＵＲＬおよびアクセスログ日時の組からなるレコードが記憶される。本実施の形態においては、図２に示したように、ある検索結果コンテンツが提示されている状態から、サイト指定、アクセスログ取得処理、コンテンツ配信が繰り返され得る（ステップ２０４〜２０７、および、ステップ２０９〜２１２参照）。そこで、アクセスログ取得処理部１８は、ある検索ＩＤに関して、ユーザがサイト指定をするたびに、インクリメントされた連番を採番して、これを含むレコードを生成し、サイトアクセスログＤＢ２０に追加する。
【００３１】
次いで、リダイレクト処理（ステップ５０２）により、ユーザが指定したサイトに対して、クライアントマシンに対するコンテンツの配信を要求する。これに応じて、指定されたサイトからクライアントマシンにコンテンツが配信され、クライアントマシンのブラウザによりこれが表示される。
【００３２】
クライアントマシンからのアクセスに応答して、サーバ１０は、上述した処理を実行する。その一方、サーバ１０は、夜間など所定のタイミングで、バッチ処理を実行し、サイトアクセスログＤＢ２０や検索リクエストＤＢ１４からのデータを取得して、検索傾向ＤＢ２４や検索結果ソート用ＤＢ１６を更新している。図６は、バッチ処理を示すフローチャートである。バッチ処理においては、検索ＩＤ抽出処理（ステップ６０１）および検索傾向算出処理（ステップ６０２）が実行される。
【００３３】
検索ＩＤ抽出処理においては、後述する前回抽出対象日時ファイル６１１に基づいて、処理対象となるレコードを、サイトアクセスログＤＢ２０から抽出し、今回抽出サイトアクセスログファイル６１２を生成する。また、検索傾向算出処理においては、検索リクエストＤＢ１４から、各ユーザに関するレコードを取り出して、当該ユーザの検索の癖（傾向）を示す指標を算出して、検索傾向ＤＢ２４を更新するとともに、検索結果ソート用ＤＢ１６を更新する。
【００３４】
これらにつき、図７、図８および図１０を参照してより詳細に説明を加える。図７に示すように、検索ＩＤ抽出処理においては、まず、バッチ処理部２２は、前回抽出対象日時ファイル６１１から、前回抽出対象となった、サイトアクセスログＤＢ２０中のレコードのアクセス日時の上限値を取得する（ステップ７０１）。ここで、前回抽出対象日時とは、前回バッチ処理において処理対象とすべきアクセス日時の上限値（前回バッチ処理開始日時−６時間）を言う。本実施の形態においては、検索ＩＤにて特定されるある検索行為において、最も大きい連番を有するアクセスのアクセス日時が、前回抽出対象日時より大きく、かつ、今回バッチ処理開始日時からすでに６時間を経過した場合に、抽出対象となっている。したがって、アクセスログ抽出処理（ステップ７０２）においては、検索条件として、「前回抽出対象日時＜ある検索ＩＤに関して最終連番を有するレコードにおけるアクセス日時≦現在時刻−６時間」を利用し、当該検索条件を満たす検索ＩＤをもつレコードが抽出される。
【００３５】
たとえば、図１１に示すように、ある検索ＩＤ（たとえば、検索ＩＤ＝ＧＡＷ００２３５１４０００００１）に関して、連番４ないし連番６がそれぞれ付与されたアクセス（符号１１０４〜１１０６参照）があったと考える。この場合には、前回のバッチ処理開始日時（符号１１１０参照）の「現在時刻−６時間」、つまり、前回抽出対象日時（符号１１１１参照）以後に、連番５のアクセスが存在している。したがって、前回のバッチ処理時においては、当該検索ＩＤを有するアクセスは、抽出対象とはならない。その一方、当該検索ＩＤの連番６のアクセス（符号１１０６参照）は、今回のバッチ処理時において検索条件を満たすため、当該検索ＩＤを有するアクセスは、すべて抽出対象となる。同様に、他の検索ＩＤ（たとえば、検索ＩＤ＝ＧＡＷ００２３５１４０００００２）に関して、連番１が付与されたアクセス（符号１１２１参照）が、「現在時刻（今回バッチ処理開始日時）−６時間」より以前に存在するため、この検索ＩＤを有するレコードは抽出対象たり得る。
【００３６】
このように、現在時刻（今回バッチ処理開始日時）から一定の時間（本実施の形態では６時間）以前に、最終の連番が存在する場合のみ、検索ＩＤにかかるレコードを抽出する理由につき説明を加える。図２を参照して説明したように、本実施の形態においては、ユーザが、ある検索キーワードを入力し、その検索結果を受けた後、当該ユーザが、いくつかのサイトを閲覧し、閲覧したサイトに、実際にユーザが求めている情報が含まれている場合には、そのサイトに留まること、つまり、他のサイトを閲覧しないと想像される。そこで、本実施の形態においては、サイトに留まっていると判断するために、一定の時間が設定されている。
【００３７】
このようにして、今回抽出サイトのアクセスログのファイル６１２が作成されると、検索回数更新処理が実行される（ステップ７０３）。検索回数更新処理７０３においては、今回抽出サイトアクセルログファイル６１２中のレコード数を、検索ＩＤごとにカウントする。たとえば、図１１の例では、今回のバッチ処理において、検索ＩＤ＝ＧＡＷ０２３５１４０００００１のカウント値は、当該検索ＩＤの連番が６まであるため、６となる。その一方、検索ＩＤ＝００２３５１４０００００２のカウント値は１となる。このカウント値は、検索リクエストＤＢ１４中の、対応する検索ＩＤの検索回数として記憶される。
【００３８】
次に、図９を参照して、検索傾向算出処理につき説明を加える。検索傾向算出処理においては、まず、検索ＩＤをキーとして、検索リクエストＤＢ１４中のデータがソートされる（ステップ９０１）。これは、ソート後の検索リクエストＤＢ中のデータがなくなるまで繰り返される。次いで、ユーザＩＤ単位で、当該ユーザＩＤに関する全検索ＩＤのもつ検索回数の平均値と標準偏差が算出される（ステップ９０２）。その後、ユーザＩＤごとのアクセス回数上限値が算出され、これが検索傾向ＤＢ２４に、ユーザＩＤと関連付けて記憶される（ステップ９０３）。
【００３９】
本実施の形態においては、ユーザ単位で、単一の検索キーワードを利用した検索回数は正規分布すると考え、信頼係数９５パーセントとして、情報信頼限界（＝１．９６×標準偏差＋平均値）を算出し、これを当該ユーザのアクセス回数上限値とした。本実施の形態においては、このアクセス回数上限値が、ユーザの検索の癖（傾向）を示す指標となる。
【００４０】
次いで、全ユーザのアクセス回数の平均値が算出され（ステップ９０５）、これも、検索傾向ＤＢ２４に記憶される。なお、図８（ｂ）において、ユーザＩＤ＝００００００００００に対応したアクセス回数上限値が、ステップ９０５で算出された平均値である。この平均値は、サーバ１０に初めてアクセスしたため、そのアクセス回数上限値が設定されていないようなユーザのためのデフォルト値として利用することができる。
【００４１】
検索傾向ＤＢ２４の更新が終了すると、検索ＩＤ抽出処理が実行される（ステップ９０５）。ここでは、検索傾向ＤＢを参照しつつ、ユーザＩＤごとに、当該ユーザのアクセス回数上限値以内の検索回数であるような、検索ＩＤおよび検索キーワードの組を、検索リクエストＤＢ１４から抽出し、検索ＩＤおよび検索キーワードの組からなるファイル９１１が生成される。このファイル９１１を利用して、ポイント付与処理が実行される（ステップ９０６）。
【００４２】
図１０は、ポイント付与処理をより詳細に示すフローチャートである。まず、ファイル９１１について、検索キーワードをキーとしてソートし、検索キーワードおよび検索ＩＤの組からなるファイル１０１１が生成される。これは、ソートし直したファイルのデータがなくなるまで継続される（ステップ１０１１、１００２）。次いで、検索ＩＤごとに、サイトアクセスログＤＢ２０を参照して、当該検索ＩＤが最終的にアクセスしたログ（ＵＲＬ）が取得される（ステップ１００３）。これにより、検索キーワード、検索ＩＤおよびＵＲＬの組からなるファイル１０１２が生成される。このファイル１０１２を参照して、当該ファイル１０１２中のある検索キーワードおよびＵＲＬが、検索結果ソート用ＤＢ１６中に存在するか否かが判断される（ステップ１００４、１００５）。すでに上記組み合わせが存在する場合には（ステップ１００５でイエス（Ｙｅｓ））、検索結果ソート用ＤＢ１６中、対応するレコードにおけるポイントがインクリメントされる（ステップ１００６）。その一方、ステップ１００５でノー（Ｎｏ）と判断された場合には、上記検索キーワードおよびＵＲＬの組み合わせを含むレコードが、検索結果ソート用ＤＢ１６中に生成され、かつ、その対応するポイントが１に設定される（ステップ１００７）。
【００４３】
このようにして、各種ＤＢのデータを更新するバッチ処理が終了する。再度、図３を参照して、これら更新されたデータがどのように利用されるかにつき簡単に説明する。ステップ３０７において検索エンジン３０から検索結果が検索処理部１２に返される。検索処理部１２は、検索結果ソート用ＤＢ１６中、検索キーワードに関連付けられたＵＲＬであって、検索結果と一致するものを見出して、それらを、ポイントの高いものから順に並べてリストする。これにより、ポイントの高いもの、つまり、他のユーザによる検索結果の蓄積から、有用と考えられる度合いの大きいものから順に、サイトの情報がリストされることになる。これにより、ユーザは、リストの上位に位置しているものから順次、サイトを指定して、その内容を閲覧し、ユーザが求める情報が含まれるか否かを判断すれば良い。この場合にも、あまりサイト指定を繰り返すことなく、所望の情報が含まれるサイトを見出すことができる可能性が高いことが期待される。
【００４４】
このように、本実施の形態によれば、過去にユーザが検索を実行し、どのサイトで目的の情報を見出されたかを推定し、その推定から、検索キーワードおよびサイト（ＵＲＬ）にポイントを付与し、このポイントを利用して、後の検索におけるサイトの提示順序を決定している。したがって、たとえば、上位にリストされたサイトを指定すれば、ユーザが所望の情報を見出すことができる確率が高まり、ユーザが、情報を見出すために何度もサイトを行き来するような手間を減じることが可能となる。
【００４５】
また、本実施の形態によれば、検索傾向ＤＢに、各ユーザの検索の癖を示す指標である検索回数を利用し、この検索回数を超えてサイト指定を繰り返している場合には、この検索は信頼できないものとして考慮しないように構成している。これにより、上記ポイントの信頼性を高めることが可能となる。また、上記検索回数を、バッチ処理により更新することにより、データの信頼性をより高めている。
【００４６】
本発明は、以上の実施の形態に限定されることなく、特許請求の範囲に記載された発明の範囲内で、種々の変更が可能であり、それらも本発明の範囲内に包含されるものであることは言うまでもない。
たとえば、単一のユーザＩＤをもつユーザ（単一のユーザ）が、異なる検索ＩＤを付与された検索において、同一の検索キーワードを利用する場合も考えられる。この場合に、本実施の形態のように、異なる検索ＩＤであれば、異なるものとして処理しても良い。或いは、所定の時間内或いは所定のセッション内に、同一の検索キーワードが利用された場合には、アクセスログをマージして、最終的なＵＲＬのみを保持するように構成しても良い。
【００４７】
また、前記実施の形態において、サイトアクセスログＤＢには、ある検索ＩＤに関してサイト指定されたＵＲＬの全てが、一意的な連番とともに記憶されているが、これに限定されるものではなく、最新の連番および最新のＵＲＬのみを記憶するような構成としても良い。
【００４８】
さらに、前記実施の形態においては、検索結果ソート用ＤＢにおいて、単一の検索キーワード（たとえば、「Ｃ＋＋」、「Ｃ」など）、複数の検索キーワードからなる複合語（たとえば、「Ｃ＋＋およびＣ」など）のそれぞれについて、ＵＲＬおよびポイントが保持されている。しかしながら、これに限定されるものではなく、単一の検索キーワードに関して、ＵＲＬおよびポイントを保持しても良い。この場合には、ポイント付与処理において、複数の検索キーワードのそれぞれに関して、ＵＲＬにポイントを付与すればよい。また、検索処理においても、複数の検索キーワードのそれぞれに関連付けられるＵＲＬを見出し、それらのポイントの加算値、平均値などを利用して、複数の検索キーワードに関するＵＲＬのポイントを求め、そのポイントの上位から、ＵＲＬをリストしても良い。
【００４９】
また、アクセス回数上限値を、キーワードのカテゴリに応じて、別途設定しても良い。たとえば、同じユーザであっても、ビジネスユースであれば、所望の情報を得るために検索回数が上昇し、その一方、趣味など個人的な利用であれば、検索回数が少なくなる傾向がある。そこで、検索キーワードを、主としてビジネスにて利用されるものと、主として趣味で利用されるものにカテゴライズし、それぞれに応じたアクセス回数上限値を設定することもできる。
【００５０】
【発明の効果】
本発明によれば、ユーザが所望の情報を、より容易に見出すことができるような検索結果を提示することができる検索支援方法を提供することが可能となる。
【図面の簡単な説明】
【図１】図１は、本発明の実施の形態にかかる検索支援サーバの構成を示すブロックダイヤグラムである。
【図２】図２は、本実施の形態にかかるサーバを利用した検索およびサイトへのアクセスを示すフローチャートである。
【図３】図３は、本実施の形態にかかる検索処理をより詳細に示すフローチャートである。
【図４】図４は、検索リクエストＤＢ中に記憶されるデータ、および、検索結果ソート用ＤＢ中に記憶されるデータの例を示す図である。
【図５】図５は、本実施の形態にかかるアクセスログ取得処理をより詳細に示すフローチャートである。
【図６】図６は、本実施の形態にかかるバッチ処理の概略を示すフローチャートである。
【図７】図７は、本実施の形態にかかる検索ＩＤ抽出処理をより詳細に示すフローチャートである。
【図８】図８は、本実施の形態にかかるアクセスログＤＢ中に記憶されたデータ、および、検索傾向ＤＢ中に記憶されたデータの例を示す図である。
【図９】図９は、本実施の形態にかかる検索傾向算出処理をより詳細に示すフローチャートである。
【図１０】図１０は、本実施の形態にかかるポイント付与処理をより詳細に示すフローチャートである。
【図１１】図１１は、本実施の形態にかかるアクセスログ抽出処理を説明するための図である。
【符号の説明】
１０ 検索支援サーバ
１２ 検索処理部
１４ 検索リクエストＤＢ
１６ 検索結果ソート用ＤＢ
１８ アクセスログ取得処理部
２０ サイトアクセスログＤＢ
２２ バッチ処理部
２４ 検索傾向ＤＢ
３０ 検索エンジン
Claims (7)
- １以上の検索キーワードを受理して、当該検索キーワードに関連するサイトの情報のリストを生成して、ユーザの操作するクライアントマシンに提示する検索支援方法であって、
検索キーワードを受理し、当該検索キーワードに関連するサイトを特定する１以上のＵＲＬの情報を取得するステップと、
前記検索キーワード、ＵＲＬ、および、当該ＵＲＬのサイトにて目的が達成されたと推定されることの度合いを示す指標を記憶したソート用データベースを参照して、前記取得されたＵＲＬを、前記指標の順にソートするステップと、
前記ＵＲＬのソート順にしたがって、前記サイトを紹介するリストを含む検索結果コンテンツを生成し、クライアントマシンに提示するステップと、
前記クライアントマシンにおける前記コンテンツ中、特定のサイトのリンク指定を受理して、前記サイトのＵＲＬを取得し、アクセスログデータベースに記憶するとともに、リダイレクトにより、前記サイトのコンテンツのクライアントマシンへの配信を求めるステップと、
前記アクセスログデータベースを参照して、前記取得されたＵＲＬのうち、ある検索キーワードを用いた検索においてユーザが目的を達成したと推定されるサイトのＵＲＬを特定するステップと、
前記検索キーワードに関して、目的を達成したと推定されるサイトのＵＲＬに関する指標を再計算し、前記ソート用データベースを更新するステップとを備えたことを特徴とする検索支援方法。 - さらに、ユーザのアクセスごとに検索ＩＤを発行するステップを備え、
前記検索結果コンテンツに基づくリンクの指定が維持される限り、同一の検索ＩＤを利用するとともに、
前記ソート用データベースを更新するステップが、各検索ＩＤに関して指標を再計算するステップを含むことを特徴とする請求項１に記載の方法。 - さらに、ある検索において、リンク指定の回数を、前記アクセスログデータベースに記憶するステップを備え、
ユーザの検索傾向を示すアクセス回数上限値を記憶した検索傾向データベースを参照して、前記リンク指定の回数が、前記アクセス回数上限値を超えた場合に、当該検索におけるＵＲＬを、前記指標の再計算には考慮しないことを特徴とする請求項２に記載の方法。 - 前記アクセス回数上限値が、当該ユーザによる検索ごとのリンク指定の回数の情報信頼限界に対応することを特徴とする請求項３に記載の方法。
- 前記目的を達成したと推定されるサイトのＵＲＬを特定するステップにおいて、
ある検索において、あるリンク指定から、一定の時間、他のリンク指定がなされていない状態である場合に、当該リンク指定にかかるＵＲＬが、前記目的を達成したと推定されるものとして特定されることを特徴とする請求項１ないし４の何れか一項に記載の方法。 - 前記指標が、ある検索において目的を達成したと推定されるサイトごとに加点されるポイントであることを特徴とする請求項１ないし５の何れか一項に記載の方法。
- さらに、取得されたＵＲＬの情報のうち、前記ソート用データベース中に存在しないものについて、当該ＵＲＬのサイトに含まれる検索キーワードの出現頻度や当該ＵＲＬのサイトの支持率を含む他の論理に基づく順序で、当該リストを含むコンテンツを生成するステップを備えたことを特徴とする請求項１ないし６の何れか一項に記載の方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002181725A JP2004029943A (ja) | 2002-06-21 | 2002-06-21 | 検索支援方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002181725A JP2004029943A (ja) | 2002-06-21 | 2002-06-21 | 検索支援方法 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2004029943A true JP2004029943A (ja) | 2004-01-29 |
Family
ID=31178491
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2002181725A Pending JP2004029943A (ja) | 2002-06-21 | 2002-06-21 | 検索支援方法 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP2004029943A (ja) |
Cited By (23)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2006235873A (ja) * | 2005-02-23 | 2006-09-07 | Ntt Docomo Inc | コンテンツ中継サーバ、コンテンツ配信システム及びコンテンツ中継方法 |
| JP2008146207A (ja) * | 2006-12-07 | 2008-06-26 | Yuichiro Matsuda | コンテンツ検索方法、コンテンツ検索プログラム、および記録媒体 |
| JP2008250663A (ja) * | 2007-03-30 | 2008-10-16 | Rakuten Inc | 情報検索システム、情報検索装置、検索結果画面情報生成方法及び検索結果画面情報生成処理プログラム |
| JP2008250662A (ja) * | 2007-03-30 | 2008-10-16 | Rakuten Inc | 情報検索システム、情報検索装置、検索結果画面情報生成方法及び検索結果画面情報生成処理プログラム |
| JP2008250661A (ja) * | 2007-03-30 | 2008-10-16 | Rakuten Inc | 情報検索システム、情報検索装置、履歴共有方法及び履歴共有処理プログラム |
| JP2008299655A (ja) * | 2007-05-31 | 2008-12-11 | Ntt Resonant Inc | 情報検索装置 |
| JP2009163663A (ja) * | 2008-01-10 | 2009-07-23 | Nippon Telegr & Teleph Corp <Ntt> | 集中度監視によるＷｅｂサイト推奨装置、集中度監視によるＷｅｂサイト推奨方法、集中度監視によるＷｅｂサイト推奨プログラムおよびそのプログラムを記録した記録媒体 |
| JP2009531792A (ja) * | 2006-03-28 | 2009-09-03 | エーナイン・ドット・コム インコーポレイテッド | 類似のクエリの結果に対するユーザアクティビティに基づいて現在のクエリに最も関連のある項目を識別すること |
| JP2009537913A (ja) * | 2006-05-19 | 2009-10-29 | ヨルン リセゲン | ソース検索エンジン |
| JP2010506271A (ja) * | 2006-09-29 | 2010-02-25 | エーナイン・ドット・コム インコーポレイテッド | ユーザの意図の分析に基づきクエリ結果を提供するための方法 |
| JP2010538386A (ja) * | 2007-09-06 | 2010-12-09 | エヌエイチエヌ コーポレーション | クエリ別検索コレクション生成方法およびシステム |
| JP2011154467A (ja) * | 2010-01-26 | 2011-08-11 | Ntt Docomo Inc | 検索結果順位付け方法および検索結果順位付けシステム |
| US8103649B2 (en) | 2007-02-05 | 2012-01-24 | Ntt Docomo, Inc. | Search system and search method |
| US8341135B2 (en) | 2004-09-07 | 2012-12-25 | Interman Corporation | Information search provision apparatus and information search provision system |
| KR101223792B1 (ko) * | 2011-12-23 | 2013-01-17 | 엔에이치엔(주) | 통합 검색 결과를 효율적으로 제공하는 검색 서비스 제공 방법 및 시스템 |
| WO2013018387A1 (ja) * | 2011-07-29 | 2013-02-07 | 楽天株式会社 | 情報処理装置、情報処理方法、情報処理プログラム、及び情報処理プログラムが記録された記録媒体 |
| JP2013092823A (ja) * | 2011-10-24 | 2013-05-16 | Nifty Corp | 情報処理装置、プログラム及び情報検索システム |
| JP2013092830A (ja) * | 2011-10-24 | 2013-05-16 | Nifty Corp | 情報処理装置、プログラム及び情報検索システム |
| JP2013218440A (ja) * | 2012-04-05 | 2013-10-24 | Nippon Telegr & Teleph Corp <Ntt> | 推定興味度スコアデータベース生成装置及び方法及びプログラム |
| JP2014021542A (ja) * | 2012-07-12 | 2014-02-03 | Alpine Electronics Inc | リスト表示装置、リスト表示方法およびリスト表示用プログラム |
| JP2015170179A (ja) * | 2014-03-07 | 2015-09-28 | 株式会社野村総合研究所 | 検索支援システム |
| JP2016513298A (ja) * | 2013-01-09 | 2016-05-12 | バイドゥ オンライン ネットワーク テクノロジー （ベイジン） カンパニー リミテッド | 電子文書の提供方法、システム、親本サーバ及び子本クライアント |
| JP2016129074A (ja) * | 2016-03-28 | 2016-07-14 | アルパイン株式会社 | リスト表示装置、リスト表示方法およびリスト表示用プログラム |
-
2002
- 2002-06-21 JP JP2002181725A patent/JP2004029943A/ja active Pending
Cited By (30)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8341135B2 (en) | 2004-09-07 | 2012-12-25 | Interman Corporation | Information search provision apparatus and information search provision system |
| JP2006235873A (ja) * | 2005-02-23 | 2006-09-07 | Ntt Docomo Inc | コンテンツ中継サーバ、コンテンツ配信システム及びコンテンツ中継方法 |
| JP4503464B2 (ja) * | 2005-02-23 | 2010-07-14 | 株式会社エヌ・ティ・ティ・ドコモ | コンテンツ中継サーバ、コンテンツ配信システム及びコンテンツ中継方法 |
| JP2009531792A (ja) * | 2006-03-28 | 2009-09-03 | エーナイン・ドット・コム インコーポレイテッド | 類似のクエリの結果に対するユーザアクティビティに基づいて現在のクエリに最も関連のある項目を識別すること |
| JP2009537913A (ja) * | 2006-05-19 | 2009-10-29 | ヨルン リセゲン | ソース検索エンジン |
| KR101487561B1 (ko) | 2006-05-19 | 2015-01-29 | 요른 리세그겐 | 소스 검색 엔진 |
| JP2010506271A (ja) * | 2006-09-29 | 2010-02-25 | エーナイン・ドット・コム インコーポレイテッド | ユーザの意図の分析に基づきクエリ結果を提供するための方法 |
| JP2008146207A (ja) * | 2006-12-07 | 2008-06-26 | Yuichiro Matsuda | コンテンツ検索方法、コンテンツ検索プログラム、および記録媒体 |
| US8103649B2 (en) | 2007-02-05 | 2012-01-24 | Ntt Docomo, Inc. | Search system and search method |
| JP2008250661A (ja) * | 2007-03-30 | 2008-10-16 | Rakuten Inc | 情報検索システム、情報検索装置、履歴共有方法及び履歴共有処理プログラム |
| JP2008250662A (ja) * | 2007-03-30 | 2008-10-16 | Rakuten Inc | 情報検索システム、情報検索装置、検索結果画面情報生成方法及び検索結果画面情報生成処理プログラム |
| JP2008250663A (ja) * | 2007-03-30 | 2008-10-16 | Rakuten Inc | 情報検索システム、情報検索装置、検索結果画面情報生成方法及び検索結果画面情報生成処理プログラム |
| JP2008299655A (ja) * | 2007-05-31 | 2008-12-11 | Ntt Resonant Inc | 情報検索装置 |
| JP2010538386A (ja) * | 2007-09-06 | 2010-12-09 | エヌエイチエヌ コーポレーション | クエリ別検索コレクション生成方法およびシステム |
| JP2009163663A (ja) * | 2008-01-10 | 2009-07-23 | Nippon Telegr & Teleph Corp <Ntt> | 集中度監視によるＷｅｂサイト推奨装置、集中度監視によるＷｅｂサイト推奨方法、集中度監視によるＷｅｂサイト推奨プログラムおよびそのプログラムを記録した記録媒体 |
| JP2011154467A (ja) * | 2010-01-26 | 2011-08-11 | Ntt Docomo Inc | 検索結果順位付け方法および検索結果順位付けシステム |
| WO2013018387A1 (ja) * | 2011-07-29 | 2013-02-07 | 楽天株式会社 | 情報処理装置、情報処理方法、情報処理プログラム、及び情報処理プログラムが記録された記録媒体 |
| CN103718179B (zh) * | 2011-07-29 | 2017-09-05 | 乐天株式会社 | 信息处理装置和信息处理方法 |
| CN103718179A (zh) * | 2011-07-29 | 2014-04-09 | 乐天株式会社 | 信息处理装置、信息处理方法、信息处理程序以及记录有信息处理程序的记录介质 |
| TWI465947B (zh) * | 2011-07-29 | 2014-12-21 | Rakuten Inc | Information processing apparatus, information processing method, information processing program product and recording medium with information processing program |
| US10262064B2 (en) | 2011-07-29 | 2019-04-16 | Rakuten, Inc. | Information processing apparatus, information processing method, information processing program, recording medium having stored therein information processing program |
| JP2013092830A (ja) * | 2011-10-24 | 2013-05-16 | Nifty Corp | 情報処理装置、プログラム及び情報検索システム |
| JP2013092823A (ja) * | 2011-10-24 | 2013-05-16 | Nifty Corp | 情報処理装置、プログラム及び情報検索システム |
| KR101223792B1 (ko) * | 2011-12-23 | 2013-01-17 | 엔에이치엔(주) | 통합 검색 결과를 효율적으로 제공하는 검색 서비스 제공 방법 및 시스템 |
| JP2013218440A (ja) * | 2012-04-05 | 2013-10-24 | Nippon Telegr & Teleph Corp <Ntt> | 推定興味度スコアデータベース生成装置及び方法及びプログラム |
| JP2014021542A (ja) * | 2012-07-12 | 2014-02-03 | Alpine Electronics Inc | リスト表示装置、リスト表示方法およびリスト表示用プログラム |
| JP2016513298A (ja) * | 2013-01-09 | 2016-05-12 | バイドゥ オンライン ネットワーク テクノロジー （ベイジン） カンパニー リミテッド | 電子文書の提供方法、システム、親本サーバ及び子本クライアント |
| US10587731B2 (en) | 2013-01-09 | 2020-03-10 | Baidu Online Network Technology (Beijing) Co., Ltd. | Method and system for providing electronic document, mother book server and child book client |
| JP2015170179A (ja) * | 2014-03-07 | 2015-09-28 | 株式会社野村総合研究所 | 検索支援システム |
| JP2016129074A (ja) * | 2016-03-28 | 2016-07-14 | アルパイン株式会社 | リスト表示装置、リスト表示方法およびリスト表示用プログラム |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP2004029943A (ja) | 検索支援方法 | |
| JP4638439B2 (ja) | ウェブ検索の個人化 | |
| US7260573B1 (en) | Personalizing anchor text scores in a search engine | |
| JP5632124B2 (ja) | 格付け方法、検索結果並び替え方法、格付けシステム及び検索結果並び替えシステム | |
| US7475074B2 (en) | Web search system and method thereof | |
| KR101171405B1 (ko) | 검색 결과에서 배치 내용 정렬의 맞춤화 | |
| US7487145B1 (en) | Method and system for autocompletion using ranked results | |
| US11163802B1 (en) | Local search using restriction specification | |
| US7599911B2 (en) | Method and apparatus for search ranking using human input and automated ranking | |
| US8027974B2 (en) | Method and system for URL autocompletion using ranked results | |
| US8577868B1 (en) | Bookmarks | |
| US7483885B2 (en) | System and method for query refinement to enable improved searching based on identifying and utilizing popular concepts related to users' queries | |
| US20090006388A1 (en) | Search result ranking | |
| WO2007051397A1 (fr) | Systeme d’extraction d’informations et procede d’extraction d’informations | |
| JP5084858B2 (ja) | サマリ作成装置、サマリ作成方法及びプログラム | |
| US20070239692A1 (en) | Logo or image based search engine for presenting search results | |
| JP2006099341A (ja) | 更新履歴生成装置及びプログラム | |
| JP2007034772A (ja) | Ｗｅｂサイト検索結果の最適表示システム及びその装置及びその方法及びそのプログラム | |
| US20120130974A1 (en) | Search engine for ranking a set of pages returned as search results from a search query | |
| JP2006268771A (ja) | 検索結果提供装置 | |
| JP4528203B2 (ja) | ファイル検索方法、ファイル検索装置、及びファイル検索プログラム | |
| JP4528202B2 (ja) | ファイル検索方法、ファイル検索装置、及びファイル検索プログラム | |
| JP2002157270A (ja) | 興味記事配信システム及び興味記事配信方法 | |
| KR100491254B1 (ko) | 웹사이트 디렉토리나 웹페이지에 대해 설명하는 단어들에하이퍼링크를 적용하는 검색 시스템 및 방법 | |
| JP3469528B2 (ja) | 車両情報検索装置、車両情報検索方法及び車両情報検索システム |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20050617 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20071120 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20080408 |