情報検索サービス提供装置及びコンピュータプログラム
【課題】検索要求に対する情報検索サービスをビジネス上の利益に結びつけることができる情報検索サービス提供装置を提供する。
【解決手段】情報検索サービスシステム４０は、質問文コーパスを記憶する記憶装置６４と、質問文をクラスタ化し、各クラスタのプロトタイプを定めるクラスタリング処理部１００と、プロトタイプのオークションを行なうオークション実行部１０４と、質問文の各々に、その属するクラスタのプロトタイプ文の落札者を関係付ける更新部１１２と、質問文の各々について、落札者の指定するＵＲＬを記憶する質問文―ＵＲＬ対照ＤＢ６８と、検索要求を受信し、検索要求との間の距離が最も小さな質問文を検索する質問文検索部１３２と、検索された質問文に対応するＵＲＬに、検索要求から生成したクエリを送信し、得られる情報をサービス利用端末４８に送信するＵＲＬ検索部１３４、１３６、及びクエリ発行部１３８とを含む。
【解決手段】情報検索サービスシステム４０は、質問文コーパスを記憶する記憶装置６４と、質問文をクラスタ化し、各クラスタのプロトタイプを定めるクラスタリング処理部１００と、プロトタイプのオークションを行なうオークション実行部１０４と、質問文の各々に、その属するクラスタのプロトタイプ文の落札者を関係付ける更新部１１２と、質問文の各々について、落札者の指定するＵＲＬを記憶する質問文―ＵＲＬ対照ＤＢ６８と、検索要求を受信し、検索要求との間の距離が最も小さな質問文を検索する質問文検索部１３２と、検索された質問文に対応するＵＲＬに、検索要求から生成したクエリを送信し、得られる情報をサービス利用端末４８に送信するＵＲＬ検索部１３４、１３６、及びクエリ発行部１３８とを含む。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、自然言語文の発話から利用者の必要とする情報を検索して提示する情報検索サービスに関し、特に、利用者からの情報の検索要求をいずれかの情報提供サービス業者かに割当てて、当該情報提供サービス業者の提供する情報を直接利用者に提示するサービスに関する。
【背景技術】
【０００２】
いわゆるインターネットには、多くの情報があふれている。しかもその量は日々増え続けている。しかし、いかに有用な情報がインターネット上に存在していても、その情報を的確に見出すことができなければ何の意味もない。そうしたネットワーク利用者の要求に応じる形で登場したのがいわゆる検索サイトである。
【０００３】
検索サイトには大きく分けて２種類がある。第１の種類の検索サイトは、検索サイトの管理者が手作業又は自動的にＵＲＩ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ）を収集し、各ＵＲＩをその内容にしたがって分類したサイトである。利用者は、自分が利用するサイトを検索サイトの分類にしたがって探していくことになる。こうしたサイトでは、分類範囲を限定し、その中で所望の単語又は単語列を検索する仕組みが用意されていることが多い。第２の種類の検索サイトは、予め単語又は単語列に応じたサイトのインデックスを作成しておき、単語又は単語列を指定した検索要求を受けると、インデックスを使用して検索し、検索結果を返すものである。この場合、検索結果にスコアをつけ、スコアの高いサイトから順番に利用者に提示することが一般的である。したがってこの場合には、スコアの付け方が問題となる。スコアの付け方により、検索目的に応じた的確なウェブサイトが提示される可能性が高くなる。
【０００４】
第１の種類の検索サイトでは、自分が探そうとする情報について、少なくともその分類を知っておく必要がある。しかもその分類方式は、検索サイトで利用されているものと一致していなければならない。なおかつ、こうした検索サイトでは、あまり多くのウェブサイトを登録するのは難しいという問題がある。数が増えると、同じ分類したに非常に多数のウェブサイトがリストされることになり、所望のウェブサイトまでたどり着くことが極めて困難となってしまう。こうした検索サイトで、単語又は単語列によりウェブサイトを検索する場合でも、的確な単語の組合せが分からなければ所望の情報が得られない確率が高い。
【０００５】
第２の種類の検索サイトでは、単語又は単語列を検索語として入力するだけで結果が表示されるため、第１の種類の検索サイトに比べると操作が簡単である。しかしこの種の検索サイトでも、自分の所望の情報を的確に得るためには、どの様な単語又は単語列であれば的確な結果が得られるかという知識が重要になる。さもなければ、自分が必要とするものと異なるウェブサイトばかりが表示されることになる。
【０００６】
逆に、情報提供サービスを行なう業者から見ると、自分の提供するサービスが検索結果の上位に表示されなければ、そもそも利用者にサービスを知ってもらうことすらできないという問題がある。そのため、いかにして検索結果の上位にサイトを表示させるか、についての、サービスを提供する技術そのものとは次元の異なる問題に精力を注がなければならないという問題がある。
【０００７】
こうした問題に鑑み、単に利用者からの検索要求に応答するだけでなく、利用者の現在位置情報又は要求サービス内容情報に基づいた検索条件に合致するサービス提供者情報を検索するサービス情報提供装置が提案されている（後掲の特許文献１）。このサービス情報提供装置は、利用者からの要求に基づく情報提供要求を、検索されたサービス提供者に対して行ない、得られたサービス情報を利用者に対して提供する。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】特開２０１０−２８２４１０号公報
【発明の概要】
【発明が解決しようとする課題】
【０００９】
上記特許文献１に開示のサービス情報提供装置によれば、利用者の現在位置に適したサービス情報を利用者に対して提供できるとされている。しかし、このようなサービス情報提供装置では、それ自身のサービスにより利益を得ることができないという問題がある。これに限らず、インターネット上で提供されるサービスではほとんど常に、どのようにして自己の提供するサービスをビジネスに結びつけるかが問題となっている。結局、検索結果又は情報提供の画面上に広告を提示し、広告料を得るという結果になることが多い。
【００１０】
しかし、このように広告のみに頼るサービスは、ビジネスモデルとして好ましくない。サービスそのものの価値をビジネスに結びつける仕組みが求められている。
【００１１】
一方、もとのサービス提供者の立場から言うと、上記したようなサービス情報提供システムにおいては、自己の提供するサービスが、数多くのサービスの１つにすぎないという問題がある。すなわち、いずれのサービス提供者にとっても、潜在的な利用者を高い確率で自己のサービスに誘導することができないという問題がある。サービス提供者から見れば、特定の条件を満足するある種の情報提供要求に限定して、自分のサービスを検索結果として利用者に提示するような仕組みが求められている。
【００１２】
しかし従来は、そのような仕組みはなく、サービス情報提供者にとっても、サービス提供者にとっても、インターネットを利用したビジネスとしては運営が不透明だという問題があった。
【００１３】
それゆえに本発明の１つの目的は、インターネット上のサービスに関する検索要求に対する情報検索サービスを運営するにあたり、そうしたサービス自体をビジネス上の利益に結びつけることができる情報検索サービス提供装置を提供することである。
【００１４】
本発明の他の目的は、インターネット上のサービスに関する検索要求に対する情報検索サービスを運営するにあたり、特定の条件を充足する検索要求について、特定のサービス提供者のサービスを独占的に返信する仕組みを採用し、そのような仕組みをビジネスとして確立できる情報検索サービス提供装置を提供することである。
【課題を解決するための手段】
【００１５】
本発明の第１の局面に係る情報検索サービス提供装置は、機械可読な複数個の文を記憶する、機械可読な記憶手段と、記憶手段に記憶された複数個の文を、文の間に定義される距離に基づいて複数個のクラスタに分類し、各クラスタを代表する代表文を定める代表文決定手段と、代表文の各々についてオークションをオンラインで行なうことにより、代表文の落札者を決定するオークション実行手段と、複数個の文の各々に、当該文が属するクラスタの代表文の落札価格及び落札者を関係付ける価格付与手段と、複数個の文の各々について、当該文に関係付けられた落札者により指定されるＵＲＩを記憶するＵＲＩ記憶手段と、情報の検索要求文をオンラインで受信したことに応答して、記憶手段に記憶された複数個の文の中で、当該検索要求文との間の距離が最も小さな文を検索する文検索手段と、文検索手段により検索された文に対応してＵＲＩ記憶手段に記憶されたＵＲＩに、検索要求文から生成したクエリを送信することにより、当該ＵＲＩから得られる情報を検索要求文を送信した端末に送信する情報送信手段とを含む。
【００１６】
好ましくは、代表文決定手段及び文検索手段において行なわれる距離の計算は同じ計算方法による。
【００１７】
より好ましくは、情報送信手段は、ＵＲＩ記憶手段に記憶されたＵＲＩの各々について、当該ＵＲＩに送信するクエリを生成するための、単語又は単語列のマッピングルールを記憶するマッピングルール記憶手段と、文検索手段が受信した情報の検索要求文に対する構文解析を行なって各単語に属性を付与し、属性付検索要求文を出力する構文解析手段と、文検索手段により検索された文と、当該文と関連付けられたＵＲＩに対応してマッピングルール記憶手段に記憶されたマッピングルールとに基づいてクエリを生成し、文検索手段により検索された文に対応してＵＲＩ記憶手段に記憶されたＵＲＩに送信するクエリ送信手段と、クエリ送信手段により送信されたクエリに対する返信を検索要求文を送信した端末に転送する情報転送手段とを含む。
【００１８】
さらに好ましくは、代表文の各々は、属性が付与されたキーワードを含む。オークション実行手段は、属性の種類毎に、属性の値の包含関係を規定する関係情報を記憶する包含関係記憶手段と、代表文の各々について、当該代表文に含まれるキーワードの属性ごとに、その属性の値を指定した入札を入札者から受ける入札手段と、入札手段により属性の値を指定して行なわれる入札について、包含関係記憶手段に記憶された包含関係と、入札された価格とにしたがって、互いに排他的な落札範囲を指定して、各代表文の落札者を決定する落札者決定手段とを含む。
【００１９】
落札者決定手段は、同じ代表文に対し、同じキーワードの属性について異なる値を指定して行なわれた複数個の入札について、指定された属性の値によりそれぞれ定まる範囲の間の包含関係を、包含関係記憶手段にその属性について記憶された包含関係に基づいて判定する包含関係判定手段と、包含関係判定手段による包含関係の判定結果にしたがって、代表文に対して属性により指定される落札範囲を決定し、各落札範囲について、該当する属性の値を指定した入札の単価により落札者を決定する手段とを含む。
【００２０】
本発明の第２の局面に係るコンピュータプログラムは、機械可読な複数個の文を記憶する、機械可読な記憶手段に接続されるコンピュータを、記憶手段に記憶された複数個の文を、文の間に定義される距離に基づいて複数個のクラスタに分類し、各クラスタを代表する代表文を定める代表文決定手段と、代表文の各々についてオークションをオンラインで行なうことにより、代表文の落札者を決定するオークション実行手段と、複数個の文の各々に、当該文が属するクラスタの代表文の落札価格及び落札者を関係付ける価格付与手段と、複数個の文の各々について、当該文に関係付けられた落札者により指定されるＵＲＩを記憶手段に記憶させるＵＲＩ記憶手段と、情報の検索要求文をオンラインで受信したことに応答して、記憶手段に記憶された複数個の文の中で、当該検索要求文との間の距離が最も近い文を検索する文検索手段と、文検索手段により検索された文に対応してＵＲＩ記憶手段に記憶されたＵＲＩに、検索要求文から生成したクエリを送信することにより、当該ＵＲＩから得られる情報を検索要求文を送信した端末に送信する情報送信手段として機能させる。
【図面の簡単な説明】
【００２１】
【図１】本発明の１実施の形態に係る情報提供システムの全体構成を示すブロック図である。
【図２】図１に示す情報提供システムで採用される、情報検索サービスシステムのブロック図である。
【図３】第１の実施の形態において、情報検索に使用する自然言語文からどのようにプロトタイプ文を選択するかを説明するための図である。
【図４】図１に示す情報提供システムのオークション実行部及びオークションデータＤＢのより詳しい攻勢を示すブロック図である。
【図５】オークションデータＤＢの主要なテーブルのレコード構成を模式的に示す図である。
【図６】図２に示す情報提供システムにより提供される、質問文のオークションに入札するために端末に表示される画面の模式図である。
【図７】図２に示すオークションデータＤＢと更新部との構成をより詳細に示す図である。
【図８】入札処理を行なう端末に表示される画面の遷移を示す状態遷移図である。
【図９】第１の実施の形態に係る情報検索サービスシステムで、オークションの落札時に実行される、オークション落札プログラムの制御構造を示すフローチャートである。
【図１０】第１の実施の形態に係る情報検索サービスシステムで、情報検索要求を受けたときに実行されるプログラムの制御構造を示すフローチャートである。
【図１１】本発明の第２の実施の形態に係る情報検索サービスシステムの概略構成を示すブロック図である。
【図１２】第２の実施の形態におけるオークションデータＤＢのプロトタイプテーブルと入札明細テーブルとのレコード構成を模式的に示す図である。
【図１３】第２の実施の形態に係る情報検索サービスシステムにおいて、質問文を入札しようとする端末に表示される入札初期画面を模式的に示す図である。
【図１４】第２の実施の形態に係る情報検索サービスシステムにおいて、質問文を入札しようとする端末に表示される入札明細画面を模式的に示す図である。
【図１５】第２の実施の形態に係る情報検索サービスシステムにおいて、質問文を入札しようとする端末に表示される入札入力画面を模式的に示す図である。
【図１６】第２の実施の形態に係る情報検索サービスシステムにおいて、質問文を入札しようとする端末に表示される入札明細追加画面を模式的に示す図である。
【図１７】第２の実施の形態に係る情報検索サービスシステムにおいて、端末に、入札処理後に表示される入札明細画面を模式的に示す図である。
【図１８】第２の実施の形態に係る情報検索サービスシステムにおいて、入札処理を行なったサービス提供者の端末に、入札処理後に表示される入札明細画面を模式的に示す図である。
【図１９】第２の実施の形態に係る情報検索サービスシステムにおいて使用される、属性ツリーの一例の構成を示す図である。
【図２０】第２の実施の形態に係る情報検索サービスシステムのウェブサーバにおいて、入札に関する問合せに応答して実行されるプログラムの制御構造を示すフローチャートである。
【図２１】第２の実施の形態に係る情報検索サービスシステムのウェブサーバにおいて、入札に関する入力に応答して実行されるプログラムの制御構造を示すフローチャートである。
【図２２】図２１に示すプログラムの一部である、明細のチェックのためのプログラムルーチンの制御構造を示すフローチャートである。
【図２３】第２の実施の形態に係る情報検索サービスシステムにおいて、オークションの落札時に実行されるオークション落札プログラムの制御構造を示すフローチャートである。
【図２４】第２の実施の形態に係る情報検索サービスシステムにおいて、情報検索要求を受けたときに実行されるプログラムの制御構造を示すフローチャートである。
【図２５】第３の実施の形態に係る情報検索サービスシステムにおいて、質問文を入札しようとする端末に表示される入札初期画面を模式的に示す図である。
【図２６】第３の実施の形態に係る情報検索サービスシステムにおいて、質問文を入札しようとする端末に表示される入札明細画面を模式的に示す図である。
【図２７】第３の実施の形態に係る情報検索サービスシステムにおいて、質問文を入力しようとする端末に表示される入札入力画面を模式的に示す図である。
【図２８】第３の実施の形態に係る情報検索サービスシステムにおいて、質問文を入力しようとする端末に表示される、対象範囲の入力画面を模式的に示す図である。
【図２９】第３の実施の形態に係る情報検索サービスシステムにおいて、入札処理を行なったサービス提供者の端末に、入札処理後に表示される入札明細画面を模式的に示す図である。
【図３０】本発明の実施の形態に係る情報検索サービスシステムを実現するコンピュータシステムの外観を示す図である。
【図３１】図３０に外観を示すコンピュータシステムのハードウェア構成を示すブロック図である。
【発明を実施するための形態】
【００２２】
以下の説明及び図面では、同一の部品には同一の参照番号を付してある。したがって、それらについての詳細な説明は繰返さない。
【００２３】
［第１の実施の形態］
第１の実施の形態に係る情報検索サービスシステムは、多数の自然言語文をクラスタリングして一定数のプロトタイプ文を定め、これらプロトタイプ文に対してサービス提供者がオークションにより入札するシステムである。予め自然言語文がクラスタリングされているので、入札により、自然言語文の各々をサービス提供者と対応付けることができる。検索要求を受けると、その検索要求が自然言語文のいずれに最も近いかを判定し、その自然言語文と対応付けられているサービス提供者の運営する情報提供サイトに検索要求を送信する。この検索要求に対してその情報提供サイトから返信されてくる情報を、もともとの検索要求の発信者の端末に送信する。
【００２４】
一方では、情報検索サービスの提供者は、プロトタイプ文のオークションにより、システムを運営するための資金を得ることができる。さらに、検索１回について所定の検索ヒット料金が得られるので、安定したビジネスとして情報検索サービスを運営できる。
【００２５】
他方、サービスの提供者は、プロトタイプ文を落札すると、そのプロトタイプ文に類似した検索要求については独占できる。通常の検索サービスにリストされる場合のように、多数の検索結果の中に埋もれてしまうことがなく、利用者を効率よく自己のサービス提供サイトに案内することができる。
【００２６】
〈構成〉
〔全体構成〕
図１を参照して、本発明の第１の実施の形態に係るシステム３０は、サービスを利用する利用者の端末４４と、各々がサービスサイト４２を運営する複数のサイト運営者４６と、インターネットを通じて端末４４、複数のサイト運営者４６、並びにこれらサイト運営者４６の運営するサービスサイト４２の各々と通信可能で、予め複数の自然言語文のコーパスをクラスタリングして得られたプロトタイプ文をサイト運営者４６によるオークションにかけ、端末４４から受けた検索要求について、オークション結果に従って選択したサービスサイトにクエリを生成して送信し、得られたサービス情報を端末４４に返送する処理を実行する情報検索サービスシステム４０とを含む。本実施の形態では、端末４４からの検索要求３２は音声で行なわれる。サービスサイトへのクエリ３４はテキスト情報であり、サービスサイトから情報検索サービスシステム４０を経て端末４４に送信されるサービス情報３６は、応答するサービスサイトに依存する。
【００２７】
情報検索サービスシステム４０は、大きく分けると、端末４４から音声で与えられる検索要求３２に対して音声認識処理を実行し、情報検索要求文を生成する音声入力フロントエンド６０と、予め収集されていた多数の自然言語文をクラスタリングし、各クラスタを代表するプロトタイプ文を複数のサイト運営者４６の間のオークションにかけておき、情報検索要求に対してオークション結果にしたがった適切なサービスサイトを決定するために必要なデータベースを構築するためのオークションシステム６２と、音声入力フロントエンド６０の出力する検索要求に基づき、オークションシステム６２により構築されたデータベースを用いてオークション結果に従って適切に選択したサービスサイトにクエリ３４を送信し、当該サービスサイトから返信されてくるサービス情報３６を端末４４に転送する処理を行なう特定サイト検索サービス実行部６６とを含む。
【００２８】
〔情報検索サービスシステム４０の構成〕
図２を参照して、情報検索サービスシステム４０は、前述したように、端末４４からの音声による検索要求に対して音声認識を行ない、テキストベースの検索要求を生成する音声入力フロントエンド６０と、予め多数の自然言語による質問文からなる質問文コーパスを、機械可読な形式で記憶するコーパス記憶装置６４と、質問文コーパスに記憶された質問文をクラスタリングして各クラスタを代表するプロトタイプ文を決定した後、各プロトタイプ文について複数のサイト運営者４６の間でオークションを行なった結果にしたがって各質問文に対応するサービスサイトを決定し、情報検索に必要なデータを生成するオークションシステム６２とを含む。すなわち本実施の形態では、多数の質問文の各々についてオークションを行なうかわりに、それらをクラスタリングし、各クラスタを代表する質問文についてオークションを行なう。
【００２９】
オークションシステム６２により生成されるデータは、質問文とその質問文の落札者が運営するサイトのＵＲＩの１例であるＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）とを対にして記憶する質問文―ＵＲＬ対照ＤＢ６８と、入力された検索要求と、その検索要求に基づいて、質問文―ＵＲＬ対照ＤＢ６８を参照して決定されたＵＲＬに対するクエリ文を生成するためのマッピングを記憶するマッピングコーパス７０とを含む。質問文―ＵＲＬ対照ＤＢ６８及びマッピングコーパス７０はいずれも記憶装置と一般的なデータベースプログラムとからなるデータベースにより実現される。
【００３０】
質問文―ＵＲＬ対照ＤＢ６８に格納される情報は、コーパス記憶装置６４に記憶された質問文の各々と、落札者の運営するＵＲＬとの対応関係である。
【００３１】
マッピングコーパス７０に記憶されるのは、検索要求に含まれる単語から、その検索要求に対応して決定されたＵＲＬに対するクエリを生成する際の、単語に対するマッピングルールである。より具体的には、マッピングルールは、例えば予め「＜地名＞京都＜／地名＞の＜食品名＞和食＜／食品名＞の＜店名＞レストラン＜／店名＞を知りたい。」というように、タグとキーワードとを含むクエリのテンプレートである。検索要求を形態素解析し、得られた形態素列の属性を得る。テンプレート中の各タグに囲まれている部分のキーワードを、そのタグと一致する、又は類似する属性の形態素の文字列で置換する。これを全てのタグについて行なうことにより、クエリが得られる。このマッピングルールは、入札者が入札時から落札時までの間に準備しておく。落札者が決定した時点で、落札された質問文に対するマッピングルールがマッピングコーパス７０に格納される。
【００３２】
なお、上記したマッピングルールの例のうち、「京都」、「和食」など、タグで囲まれた部分のキーワードは、クエリ生成の際に検索要求から得られた単語の文字列で置換される箇所を明示するためのものであるが、そのためだけのものではない。すなわち、これらキーワードは、検索要求から得られた単語をどのキーワードと置換するかを決定する際の情報の一種としても使用される。形態素解析で得られた属性だけでなく、単語間の意味的距離をも用いてキーワードと形態素とを関係付けることにより、クエリがより高い精度で生成できる。
【００３３】
情報検索サービスシステム４０はさらに、音声入力フロントエンド６０の出力する検索要求から、コーパス記憶装置６４に記憶された質問文コーパス、質問文―ＵＲＬ対照ＤＢ６８、及びマッピングコーパス７０に記憶されたマッピングルールを用いて、その質問文が属するクラスタのプロトタイプ文の落札者の運営するサイトに対し、その質問文から生成されたクエリを送信し、得られた情報を、検索要求送信者のサービス利用端末４８（多くの場合、端末４４と一致する。）に対して送信する処理を行なう特定サイト検索サービス実行部６６と、特定サイト検索サービス実行部６６の実行したクエリの結果を検索ログとして記憶し、この検索ログと、オークションシステム６２によるオークションの結果（質問文の落札単価）とを用いてオークション落札者に対する請求処理を行なうための課金処理部７２とを含む。
【００３４】
音声入力フロントエンド６０は、端末４４においてコードブックを用いてコード化され送信された音声信号をオンラインで受信し、コードブックを用いて音声データを復元するコード受信部８０と、コード受信部８０により復元された音声データ化から、音声認識のために必要な特徴量を算出する特徴量算出部８２と、特徴量算出部８２により算出された特徴量を用いて音声認識を行ない、認識結果のテキストデータを認識結果として出力する音声認識装置８４とを含む。特徴量算出部８２が復元する特徴量は、音声認識装置８４の仕様により決定されるが、例えば所定フレーム庁及び所定シフト長のフレーム毎に算出されるＭＦＣＣ，ΔＭＦＣＣ，パワーなどである。本実施の形態では、情報検索サービスシステム４０を利用するのは、特定のものだけでなく、一般的な利用者であることが想定されている。したがって音声認識装置８４は、一般的な話者の音声認識が可能である必要がある。もちろん、利用者が特定の集団に限定されていることが分かっているならば、たとえば話者同定の仕組みを音声認識装置８４の前段に加え、音声認識装置８４ではその話者の音声の音声認識に適した音響モデルを利用するようにしてもよい。
【００３５】
オークションシステム６２は、コーパス記憶装置６４に記憶された質問文コーパスを構成する多数の質問文をクラスタリングし、クラスタごとに、その中心となるプロトタイプ文を、クラスタ番号とともに出力するクラスタリング処理部１００と、クラスタリング処理部１００から出力されるプロトタイプ文とクラスタ番号とを記憶するプロトタイプ記憶部１０２とを含む。なお、クラスタリング処理部１００は、クラスタリング時に、コーパス記憶装置６４に記憶された各質問文に、その質問文が属するクラスタ番号を付す処理も実行する。
【００３６】
オークションシステム６２はさらに、プロトタイプ記憶部１０２に記憶されたプロトタイプ文の各々を複数のサイト運営者４６によるオンラインのオークションにかける処理を実行するオークション実行部１０４と、システムの運用時刻を管理するためのタイマ１１０と、タイマ１１０から得られる時刻情報に基づき、オークション実行部１０４により実行されるオークションの開始及び終了と、オークション結果を用いた特定サイト検索サービス実行部６６による特定サイト検索サービスの運営とを管理するためのオークション管理部１０８と、オークション実行部１０４がオークションを実行するために必要なデータを記憶するオークションデータＤＢ１０６とを含む。
【００３７】
オークションシステム６２はさらに、オークションデータＤＢ１０６、オークション管理部１０８、質問文―ＵＲＬ対照ＤＢ６８、マッピングコーパス７０、及び課金処理部７２に接続され、オークション実行部１０４により実行されるオークションの終了日時に到達すると、オークション管理部１０８の管理の下、オークションデータＤＢ１０６に記憶された情報に基づいて、各プロトタイプ文の落札者と落札価格とを決定し、その結果にしたがって質問文―ＵＲＬ対照ＤＢ６８、マッピングコーパス７０、及び課金処理部７２による請求先の情報を更新する更新部１１２を含む。質問文─ＵＲＬ対照ＤＢ６８は、各質問文について、その質問文が属するクラスタの代表文を落札した落札者の運営するサイトのＵＲＬ（後述する入札者テーブルに記録されている。）と、その質問文とを関係付ける情報を記憶するためのものである。なお、オークションの落札日時と、落札結果を用いたオークションの開始日時とは通常一致しない。オークション終了後、例えば２週間後からその結果を用いた特定サイト検索サービスが開始される。したがって、更新部１１２による質問文―ＵＲＬ対照ＤＢ６８、マッピングコーパス７０及び課金処理部７２の更新結果は直ちに特定サイト検索サービスに反映されるわけではない。更新部１１２による更新は、新たなデータを作成することであり、特定サイト検索サービスの開始日時に、それらが以前のデータを置換することになる。図及び説明を簡単にするため、図面にはこうした更新と実際の運用開始との間の時間的ズレを管理するための機構は示していない。
【００３８】
特定サイト検索サービス実行部６６は、音声認識装置８４の出力する検索要求に対する形態素解析、意味辞書による意味タグの付与、及び構文解析などを行ない、意味タグ、品詞タグなどの属性がそれぞれ付された形態素列を出力する質問文解析部１３０と、これら形態素列により表される検索要求との間の距離が最も小さな質問文をコーパス記憶装置６４に記憶された質問文コーパスの中で検索し取出し、その属するクラスタ番号を解析後の検索要求とともに出力するための質問文検索部１３２とを含む。この検索では、例えば品詞、文中での出現箇所、係り受け関係、品詞などを全て考慮して、正規化された質問文特徴ベクトルを作成し、特徴ベクトル間の内積の値が最も大きな質問文を選択する、などの方法を用いればよい。本実施の形態では、質問文のクラスタリングの際に用いられた距離計算の方法と、質問文検索部１３２により用いられる距離計算の方法とは、同じ方法であるものとする。
【００３９】
特定サイト検索サービス実行部６６はさらに、質問文検索部１３２により選択された質問文のクラスタ番号に基づき、その質問文を落札したサイト運営者のサービスサイトのＵＲＬを質問文―ＵＲＬ対照ＤＢ６８において検索し、解析後の検索要求とともに出力するためのＵＲＬ検索部１３４と、ＵＲＬ検索部１３４から出力されるＵＲＬ及び解析後の検索要求、並びにマッピングコーパス７０にそのＵＲＬに対応して記憶されているマッピングルールに基づいて、クエリを生成し、ＵＲＬとともに出力するためのクエリ生成部１３６と、クエリ生成部１３６により出力されたクエリと、クエリ生成部１３６により出力されたＵＲＬとから、情報検索のためのＵＲＬ文を生成してインターネット上に送信するクエリ発行部１３８と、クエリ発行部１３８が送信したクエリに応答して、サービスサイト４２から送信されてきた情報をサービス利用端末４８に転送し、同時に検索ログを課金処理部７２に対して出力するためのクエリ結果送信部１４０とを含む。
【００４０】
課金処理部７２は、クエリ結果送信部１４０から出力される検索ログを蓄積するための検索ログ記憶部１５０と、検索ログ記憶部１５０に記憶された検索ログを定期的に読出し、検索対象となったサイトの検索回数にオークション結果にしたがった単価を乗じた金額を、各サイトの運営者（オークション落札者５０）に請求する処理を実行するための請求処理部１５２とを含む。
【００４１】
図３を参照して、クラスタリング処理部１００が実行するクラスタリング処理の概念について説明する。コーパス記憶装置６４には、主としてインターネット上から収集された多数の質問文が記憶されている。本実施の形態に係る情報検索サービスシステム４０では、音声で与えられる検索要求の各々について、これら質問文の内で最も近い距離にあるものを特定し、その質問文について予め落札していたサイト運営者のサイトにその検索要求を送信する。したがって、準備処理として、各質問文についてオークションで１検索あたりの単価を定めて、その質問文に近い検索要求が発生したときには、オークションでのその質問文の落札者の運営するサイトにその検索要求を転送する。そのような検索が発生するたびに、その質問文に付けられていた単価にしたがった料金をいわば広告料と同様にして情報検索サービスシステム４０の運営者が落札者から受取る。これが情報検索サービスシステム４０を運営していくための資金となる。
【００４２】
ただし、質問文は大量である上、時々刻々と増加する。したがって、それら質問文の各々についてオークションを行なうのは現実的ではない。そこで本実施の形態では、それら多数の質問文を予め複数のクラスタに分類する。クラスタリングの手法として使用される手法は、特に特定のものに限定されるわけではない。各質問文が必ず１つのクラスタに、かつ１つのクラスタのみに属するような手法であればどのようなものでもよい。しかし、本実施の形態では、検索要求に対して最も小さな距離にあるプロトタイプを特定する必要があるため、質問文の間の距離に相当する評価関数を何らかの形で定義し、その距離を基準に質問文をクラスタリングする手法を用いることが望ましい。なお、クラスタ数は、クラスタごとにオークションにかける関係上、予め固定されていることが望ましい。もちろん、クラスタ数が固定されていなければならないわけではなく、オークションごとに変化してもよい。要するに、情報検索サービスシステム４０の運営上で都合のよい数をクラスタの数として選択すればよい。
【００４３】
図３を参照して、これら多数の質問文の集合１６０を、１点鎖線で示されるように複数のクラスタに分割する。通常のクラスタリング手法を用いると、各クラスタについてそのセントロイド（重心）が決定される。本実施の形態では、各クラスタのセントロイドに最も近い質問文をそのクラスタのプロトタイプとし、このプロトタイプ文でそのクラスタに属する全質問文を代表させる。図２に示すクラスタリング処理部１００は、このようにしてプロトタイプを決定してプロトタイプ集合１６２を形成し、プロトタイプ記憶部１０２に記憶させる機能を持つ。各質問文には、どのクラスタに属するかを示す情報が付される。
【００４４】
図４を参照して、オークション実行部１０４は、サイトの運営者の端末からのｈｔｔｐリクエストを処理するウェブサーバ１９０と、ウェブサーバ１９０と連携し、ウェブサーバ１９０が受信したｈｔｔｐリクエストのうち、オークションに関係するリクエストについて、当該リクエストにより決定されるプログラムを読出して実行する、プログラムの実行処理系からなる実行処理部１９２とを含む。実行処理部１９２は、ＣＰＵなどの図示しないコンピュータハードウェアが、実行処理系のプログラムを実行することにより実現される。
【００４５】
オークション実行部１０４はさらに、実行処理部１９２によりｈｔｔｐリクエスト内のプログラム指定にしたがって呼出されて実行され、オークションデータＤＢ１０６内の各種のテーブルを更新したり、各テーブルからデータを読出したりして、処理結果を実行処理部１９２及びウェブサーバ１９０を介してｈｔｔｐリクエストの送信元に返信する、ログオン処理部１９４、問合処理部１９６、入札処理部１９８、登録情報保守部２００、落札情報表示部２０２、及びマッピング管理部２０４とを含む。これらの機能については後述する。
【００４６】
ウェブサーバ１９０は、サイト管理者の端末から送信されてくるｈｔｔｐリクエストを受信するためのリクエスト受信部２１０と、リクエスト受信部２１０が受信したｈｔｔｐリクエストのＵＲＬに含まれる情報を解析することにより、ログオン処理部１９４、問合処理部１９６、入札処理部１９８、登録情報保守部２００、落札情報表示部２０２及びマッピング管理部２０４のいずれを起動すべきかを決定し、実行処理部１９２にその情報を与えるための実行系呼出部２１２と、ｈｔｔｐリクエストを処理した後、ログオン処理部１９４などから送信されてくる処理結果のｈｔｍｌ書類からなるレスポンスをサイト運営者の端末に送信するレスポンス送信部２１４とを含む。
【００４７】
オークションデータＤＢ１０６は、入札者の基本的情報を記憶する入札者テーブル１７０、プロトタイプに関する情報を記憶するプロトタイプテーブル１７２、主として進行中のオークションを管理するための基本的情報を記憶するオークションマスタテーブル１７４、入札の明細を記憶する入札明細テーブル１７６、オークションの落札に関連する情報を記憶する落札情報テーブル１７８、及び、各入札者が、自己の入札したプロトタイプに関連して予め作成するマッピングルールを記憶するマッピングコーパステーブル１８０を含む。
【００４８】
図５を参照して、例えば入札者テーブル１７０のレコード２５０は、このサービスに対する入札を行なう可能性のあるサイト運営者を一意に識別するように割当てられる入札者ＩＤと、入札者の氏名又は名称と、入札者の住所と、入札者の管理するサービスサイトのＵＲＬ及びそのサービス名と、請求関係の情報（締日、請求書の宛先等）と、ログオンのためのパスワードと、落札結果などの連絡の際に用いられる電子メールアドレスとを含む。サイト運営者からログオン要求があった場合、入札者テーブル１７０の入札者ＩＤ及びパスワードによりサイト運営者のログオン情報を認証することができる。なお、図５に示す以外に、例えばサイト運営者の運営責任者、電話番号、ファクシミリ番号などを記録するようにしても良いが、本実施の形態ではそれらに関する情報を使用しないため、図５及び以後の説明ではそれらについては言及しない。
【００４９】
プロトタイプテーブル１７２のレコード２５２は、各プロトタイプに対し一意に割当てられるプロトタイプＩＤと、そのプロトタイプＩＤに対応する質問文の、質問文コーパス内におけるＩＤ（質問文ＩＤ）と、そのプロトタイプにより代表されるクラスタに含まれる質問文数と、当該クラスタに属する質問文のリストの先頭及び最後尾へのポインタからなるクラスタ文リストと、このプロトタイプが落札されたか否かを示す入札完了フラグとを含む。
【００５０】
オークションマスタテーブル１７４のレコード２５４は、各オークションに対して一意に割当てられるオークションＩＤと、オークションのウェブサイトに表示されるオークション名称と、オークションの開始時期及び終了時期と、当該オークションに基づく特定サイト検索サービスの運用開始時期及び終了時期と、このレコードに対応するオークションの入札が完了したか否かを示すオークション完了フラグと、このオークションの結果に基づく特定サイト運用サービスの運用が終了したか否かを示す運用完了フラグと、このオークションが有効か否か（現在運用されているか否か）を示す運用開始フラグとを含む。オークションの開始時期及び終了時期は、各プロトタイプに対するサイト運営者の入札許可期間の開始時期及び終了時期をそれぞれ示す。オークション完了フラグがオンの場合、このオークションの各プロトタイプが落札され、運用の準備ができたことを示す。運用完了フラグがオンの場合、このオークションの結果を用いた特定検索サービスの運用が終了したことを示す。運用完了フラグがオフの場合、このオークションの結果を用いたサービスの運用がまだ完了していないことを示す。運用開始フラグがオンのときは、このレコードにより示されるオークションの落札結果にしたがって、特定検索サービスが運用されていることを示す。仮に運用開始フラグがオフであれば、現在日時が運用開始時期及び運用終了時期の間であっても、このレコードに対応するオークションの落札結果にしたがった特定サイト検索サービスは運用されない。
【００５１】
入札明細テーブル１７６のレコード２５６は、関係するオークションのオークションＩＤと、入札対象のプロトタイプのプロトタイプＩＤと、入札日時と、入札者ＩＤと、入札単価と、落札フラグとを含む。落札フラグは、レコードが作成されるときにオフに初期化される。
【００５２】
再び図４を参照して、ログオン処理部１９４は、入札者テーブル１７０を参照して、サイト運営者がこのオークションシステムにログオンしてよいか否か、いつログオフしたか、などを管理する。ログオン処理部１９４による処理は、有料、無料を問わずユーザ登録が必要なシステムで行なわれている処理と同様である。
【００５３】
問合処理部１９６は、このオークションシステムにログオンしているサイト運営者から、進行中のオークションに関する問合せがあったことに応答して、プロトタイプテーブル１７２、オークションマスタテーブル１７４及び入札明細テーブル１７６を参照し、問合せがあった情報を示すｈｔｍｌ処理を作成して実行処理部１９２に与える処理を実行するためのものである。問合処理部１９６の処理も、データの内容に相違はあるものの、データベースを参照してダイナミックにｈｔｍｌ処理を作成するウェブサーバで通常実行されているものと同様の手法を用いて実現できる。
【００５４】
入札処理部１９８は、サイト運用者から、特定のプロトタイプを指定して入札の入力があったときに、その内容が正しいか否かを検査し、正しいときのみ入札明細テーブル１７６に入札明細レコードを新たに作成する処理を行なう。入札の入力が正しくないときには入力を拒否する。実際には、後述するように、入札処理は問合処理部１９６による問合せの後に行なわれる。問合処理部１９６が作成するｈｔｍｌ書類中に、入札データの整合性を保証するようなスクリプトを記述しておくことにより、入札処理部１９８が受取る入札データは基本的に正当なものであることが想定される。
【００５５】
図６に、問合処理部１９６により表示される入札初期画面２３０の例を示す。図６に示す画面は、サイト運営者がこのシステムにログオンした後、オークションを指定して問合処理を開始させることにより、問合処理部１９６により作成され、サイト運営者の端末のブラウザに表示される。
【００５６】
図６を参照して、質問文入札の初期画面では、プロトタイプ文がＩＤ順に表示される。既に入札があったプロトタイプ文については、「最高値」の欄に入札の最高値が表示される。特定のプロトタイプ文に対する入札を行なう場合、サイト運営者は「ビッドする」という見出しの欄に表示されるチェックボックスのうち、入札しようとするプロトタイプ文の行のチェックボックスにチェックを入れ、入札単価を入力する。プロトタイプ文の内容、プロトタイプ文により代表されるクラスタに含まれる質問文の数などを知りたいときには、「詳細」ボタン２４０を押すと、新たなウィンドウ又はタブにそのプロトタイプ文により代表されるクラスタの詳細がプロトタイプテーブル１７２の該当レコードに基づいて表示される。
【００５７】
図６の入札初期画面２３０の最も下部に表示されている「戻る」ボタンを押すと、オークション選択の画面が表示される。「入札する」ボタンを押すと、ユーザの入力が入札処理部１９８に送信され、チェックされる。チェックの結果、入力が正当であれば入札明細テーブル１７６に入力明細が追加される。チェックの結果、入力が正当でないときにはエラーメッセージと共に図６と同様の画面が再度表示される。この場合、誤りとなった箇所が例えば反転して、又は赤いフォントで、表示される。本実施の形態では、誤りがあった場合には、入力のいずれについても入札明細テーブル１７６への追加は行なわれない。
【００５８】
登録情報保守部２００は、入札者テーブル１７０に記憶されているサイト運営者の情報を保守するためのものである。サイト運営者は、当然のことながら自分に関する情報しか保守することができない。登録情報保守部２００の機能も、既存のシステムで通常実現されているものと同様である。
【００５９】
落札情報表示部２０２は、既に落札が完了したオークションの内容についての問合せを処理するためのものである。本実施の形態では、落札情報表示部２０２は発明の本質的部分とは無関係なので、その詳細についてはここでは説明しない。
【００６０】
マッピング管理部２０４は、入札者が、自分の入札したプロトタイプを処理するためのマッピングルールを入力したり、保守したりするためのものである。その処理内容は通常のデータベースのレコードの保守と同様であり、保守の対象がマッピングルールである点のみが異なる。したがってここではマッピング管理部２０４の詳細については説明しない。
【００６１】
オークション管理部１０８は、タイマ１１０の出力に応答して、定期的にオークションデータＤＢ１０６のオークションマスタテーブル１７４をチェックしており、オークション開始時期に到達したオークションであって、オークション開始フラグがオフのものがあれば、そのオークションＩＤを指定して、更新部１１２に対し、当該オークションを開始させる指示を出す。オークション管理部１０８はまた、同様にして、運用開始時期に到達したオークションであって、運用開始フラグがオフのものがあれば、そのオークションＩＤを指定して、更新部１１２に対し特定サイト検索サービスの切替を指示する機能を持つ。
【００６２】
図７を参照して、更新部１１２の構成について説明する。更新部１１２は、図２に示すオークション管理部１０８から特定のオークションを完了する指示を受けたことに応答して、指定されたオークションＩＤを持ち、オークション完了フラグがオン、運用開始フラグがオフ、運用完了フラグがオフ、かつ現在時刻が運用開始時期と運用終了時期との間にあるレコードの運用開始フラグをオンに更新するオークションマスタ更新部２６０と、オークション管理部１０８から特定のオークションを完了させる指示を受けたことに応答して、入札明細テーブル１７６を検査し、各プロトタイプに対する落札者を決定する処理と、指定されたオークションの各プロトタイプの落札者が決定されたときに、オークションマスタテーブル１７４内の、指定されたオークションに対応するレコードのオークション完了フラグをオンに更新する処理と、落札結果を落札情報テーブル１７８に出力する処理とを実行する落札処理部２６２とを含む。
【００６３】
オークションデータＤＢ１０６はさらに、落札処理部２６２による落札処理が完了したことに応答して、入札者テーブル１７０、オークションマスタテーブル１７４、及び落札情報テーブル１７８にそれぞれ記憶された情報に基づいて、各プロトタイプの落札者に対し落札結果を通知する落札通知処理部２６４と、オークション管理部１０８から、オークションＩＤを指定して、特定サイト検索サービスの運用を、当該オークションＩＤのオークションの落札結果に基づく運用に切替る指示を受けたことに応答して、質問文―ＵＲＬ対照ＤＢ６８及びマッピングコーパス７０の内容を落札情報テーブル１７８及びマッピングコーパステーブル１８０の内容にしたがって更新する運用ＤＢ更新部２６６とを含む。
【００６４】
運用ＤＢ更新部２６６は具体的には、オークション管理部１０８から運用の切替の指示を受けると、オークションマスタテーブル１７４のうち、運用開始フラグがオン、かつ運用完了フラグがオフのレコードの運用完了フラグをオンに更新する。運用ＤＢ更新部２６６はさらに、オークション管理部１０８により指定されたオークションＩＤを持ち、オークション完了フラグがオン、運用開始フラグがオフ、かつ運用完了フラグもオフであるレコードの運用開始フラグをオンに更新する処理を実行する。運用ＤＢ更新部２６６はこれに加えて、落札情報テーブル１７８に基づいて質問文―ＵＲＬ対照ＤＢ６８を落札結果にあわせて書替え、マッピングコーパステーブル１８０に記録されたマッピングルールの中から、プロトタイプ文ごとに、落札者により準備されていたマッピングルールのみを抽出してマッピングコーパス７０を書き換える。
【００６５】
図８を参照して、本実施の形態に係る情報検索サービスシステム４０によるオークションに参加するサイト運営者の端末画面は、その状態により様々な状態に遷移する。サイト運営者がこのオークションの行なわれているサイトに接続し、ログオンに成功すると、先頭ページ２８０が表示される。図示しないが、先頭ページ２８０では、オークションへの参加と、落札結果の問合せとの２つの選択肢が示される。オークションへの参加が選択されると画面はオークション選択ページ２８２に遷移する。落札結果の問合せが選択されたときにも、画面はオークション選択ページ２９２に遷移する。これらオークション選択ページ２８２及び２９２は、その名称は同じだが、前者が現在開催されているオークションを選択するものであるのに対し、後者は既に落札され、終了しているオークションを選択するものである点が異なっている。
【００６６】
オークション選択ページ２８２では、図示しないが、現在開催されているオークションの一覧が表示される。この画面はオークションマスタテーブル１７４を参照することにより作成できる。この画面では、各オークションの詳細表示の選択肢と、各オークションに含まれるプロトタイプの一覧表示との選択肢が表示される。各オークションの詳細表示が選択されると、画面はオークション詳細情報表示２８４に遷移する。プロトタイプの一覧表示が選択されるとプロトタイプ別入札情報一覧表示画面２８６が表示される。
【００６７】
オークション詳細情報表示２８４では、指定されたオークションＩＤのレコードをオークションマスタテーブル１７４から読出し、その詳細が表示される。この画面で「戻る」ボタンを押すと画面はオークション選択ページ２８２に戻る。
【００６８】
プロトタイプ別入札情報一覧表示画面２８６は、図６に示す入札初期画面２３０のことをいう。図６に示す「詳細」ボタン２４０を押すと、該当するプロトタイプに関する詳細を表示するプロトタイプ別詳細表示画面２８８に表示が遷移する。プロトタイプ別詳細表示画面２８８には、図示しない「戻る」ボタンと「オークション選択ページに戻る」ボタンとが表示される。これらを押すと、表示はプロトタイプ別入札情報一覧表示画面２８６又はオークション選択ページ２８２に遷移する。
【００６９】
図６に示すプロトタイプ別入札情報一覧表示画面２８６で「入札する」ボタンを押すと、前記したように入札内容が入札処理部１９８によりチェックされる。入札内容が正当であれば、入札更新処理２９０が実行され、入札後の情報にしたがってプロトタイプ別入札情報一覧表示画面２８６が更新される。入札内容が正当でなければ、エラーメッセージとともに、入力時のプロトタイプ別入札情報一覧表示画面２８６が再度表示される。
【００７０】
〈プログラム構造〉
─落札処理─
図４に示す各処理部は、既存の技術を転用することにより容易に実現できる。以下、図７に示す落札処理部２６２及び落札通知処理部２６４を実現するプログラムの制御構造を説明する。ここでは、オークションＩＤが指定され、特定のオークションＩＤのデータについて落札処理する場合について説明する。
【００７１】
図９を参照して、この落札処理プログラムは、入札明細テーブル１７６から、指定されたオークションＩＤを持ち、入札完了フラグがオフのプロトタイプ番号ごとに、最高入札単価の入札明細を読出すステップ３１０と、ステップ３１０で読み出された全明細に対し、以下のステップ３１４を繰返すステップ３１２とを含む。
【００７２】
ステップ３１４は、処理対象の入札明細の落札フラグをセットするステップ３４０と、プロトタイプテーブル１７２のうち、その入札明細のプロトタイプＩＤと一致するプロトタイプＩＤを持つレコードの入札完了フラグをセットするステップ３４２とを含む。
【００７３】
このプログラムはさらに、ステップ３１２に続いて実行され、入札明細テーブル１７６から落札フラグがオンの明細を入札者ＩＤ順及びプロトタイプ順で読出すステップ３１６と、落札者に対する落札結果の通知である電子メールを作成し、発送するステップ３１８と、プロトタイプテーブル１７２から、指定されたオークションＩＤを持ち、入札完了フラグがオフのレコードを全て読出すステップ３２０と、ステップ３２０で読み出されたレコードの件数が０か否かを判定し、判定結果にしたがって制御の流れを分岐させるステップ３２２とを含む。
【００７４】
ステップ３２２の判定が肯定の場合、全てのプロトタイプが落札されたということであり、制御はステップ３２４に進む。ステップ３２４では、オークションマスタテーブル１７４の、指定されたオークションＩＤのレコードのオークション完了フラグが１にセットされる。続いてステップ３２６でオークション完了のメッセージをシステム出力に出力して処理を終了する。
【００７５】
ステップ３２２の判定が否定の場合、落札されてないプロトタイプが存在するということである。ステップ３２８でオークション未完のメッセージをシステム出力に出力し、処理を終了する。システム管理者はこの場合、落札されていないプロトタイプのみについて改めてオークションを開催することができる。何度かオークションを行なっても落札されないプロトコルが存在する場合、オークション自体は完了させ、このプロトタイプにより代表されるクラスタ内の質問文に類似する検索要求を受信した場合には、特定のサイトにクエリを発行する処理を行なわず、一般的な検索サイトに検索要求をそのまま転送し、得られた検索結果を検索要求の送信者に返信するような処理を実行するようにしてもよい。
【００７６】
〔プログラム構造〕
特定サイト検索サービスを実現するプログラムの制御構造について説明する。これから説明する処理は、図２に示すＵＲＬ検索部１３４のうち、質問文解析部１３０の後に行なわれる処理に相当する。したがってこのプログラムは、検索要求のテキスト列であって、構文解析後の形態素列を受けたことに応答して起動する。
【００７７】
図１０を参照して、このプログラムは、有効フラグがオンのレコードをオークションマスタテーブル１７４において検索することにより、現在運営されているオークションを決定するステップ３６０と、受信した検索要求の形態素列と、コーパス記憶装置６４に記憶された全質問文との間の距離を算出するステップ３６２と、ステップ３６２の処理結果を受け、検索要求との距離が最も小さな質問文を選択するステップ３６４と、ステップ３６４の処理で選択された質問文が属するクラスタのプロトタイプを選択するステップ３６６と、ステップ３６４で選択された質問文又はステップ３６６で選択されたプロトタイプと関連付けられているＵＲＬを質問文―ＵＲＬ対照ＤＢ６８から、検索されたＵＲＬと関連付けられているマッピングコーパスをマッピングコーパス７０から、それぞれ検索するステップ３６８とを含む。本実施の形態では、質問文に対応するＵＲＬが質問文―ＵＲＬ対照ＤＢ６８に記憶されていればそのＵＲＬを用い、そうでない場合にはステップ３６６で選択されたプロトタイプに対応するＵＲＬを用いる。マッピングコーパス７０には、質問文―ＵＲＬ対照ＤＢ６８に記憶されているＵＲＬに対するクエリ文を作成するためのマッピングルールが記憶されていることが前提となる。
【００７８】
このプログラムはさらに、ステップ３６８に続き、ステップ３６６及びステップ３６８で検索されたＵＲＬ及びマッピングルールと、質問文解析部１３０から受けた構文解析後の検索要求とを用い、マッピングルール内のキーワード部分を検索要求内の対応する単語で置換することによりクエリ文を生成するステップ３７０と、このクエリ文とステップ３６８で検索されたＵＲＬとを組合せることによりクエリ要求をインターネット上に送出する（発行する）ステップ３７２と、ステップ３７２で発行されたクエリ要求に対するレスポンスを受信し、最初の検索要求を送信してきた端末に転送するステップ３７４と、以上の一連の処理について、請求に必要な情報を含むアクセスログを出力して一連の処理を終了するステップ３７６とを含む。本実施の形態では、検索要求が与えられるたびに図１０に示されるプログラムの実行が開始され、レスポンスを返すと終了する。
【００７９】
〈動作〉
以上に構成を説明した情報検索サービスシステム４０は以下のように動作する。この情報検索サービスシステム４０を含むシステム３０の動作は、一つのオークションについて見ると大きく３つのフェーズに分割される。第１のフェーズはオークションの準備フェーズである。第２のフェーズはオークションフェーズである。第３のフェーズはオークションの結果に基づく特定サイト検索サービスの運用フェーズである。以下、順番に説明する。
【００８０】
─オークションの準備フェーズ─
オークションを開始するに先立ち、入札者テーブル１７０及びオークションマスタテーブル１７４には、オークション開催に必要な情報が記憶される。入札者テーブル１７０には、オークションごとではなく、情報検索サービスシステム４０によるサービスによりユーザを自分のサイトに誘導しようとするサイトの運営者がウェブを通じて自己の情報を登録する。オークションマスタテーブル１７４には、情報検索サービスシステム４０の運営者がオークションを管理するために必要な情報を予めオークションごとに登録する。
【００８１】
プロトタイプテーブル１７２、入札明細テーブル１７６、落札情報テーブル１７８、及びマッピングコーパステーブル１８０はオークション開始前にクリアされる。
【００８２】
情報検索サービスシステム４０の運営者は、予め多数の質問文をインターネット上から収集し、コーパス記憶装置６４にコーパスとして記憶させる。各質問文には互いを識別するための一意名質問文ＩＤが割当てられる。クラスタリング処理部１００は、このコーパスに含まれる質問文を所定数のクラスタに分類し、各クラスタについてプロトタイプ文を決定する。クラスタにはクラスタ番号が割当てられる。決定されたプロトタイプ文は、対応するクラスタのクラスタ番号及びそのプロトタイプの質問文ＩＤとともにプロトタイプ記憶部１０２に記憶される。これらプロトタイプにアクセスするための情報は図４に示すプロトタイプテーブル１７２に記憶される。本実施の形態では、プロトタイプには、その質問文ＩＤとは別のプロトタイプＩＤが割当てられる。
【００８３】
─オークションフェーズ─
オークションの準備ができると、情報検索サービスシステム４０は何らかのメディアを通じてオークションの開始を複数のサイト運営者４６に通知する。興味を持ったサイト運営者はオークションの内容について調べることになる。これは問合処理部１９６により処理される。
【００８４】
問合処理部１９６は、図８に示す遷移図にしたがってサイト運営者４６の端末に表示される画面を制御する。図８に示す各画面のうち、プロトタイプ別入札情報一覧表示画面２８６（図６）において、サイト運営者が入札の操作をすると、入札処理部１９８により入力内容がチェックされる。入札内容が正当であれば、入札更新処理２９０が実行され、入札明細テーブル１７６に入札の明細が追加される。さらに、入札後の情報にしたがってプロトタイプ別入札情報一覧表示画面２８６が更新される。入札内容が正当でなければ、エラーメッセージとともに、入力時のプロトタイプ別入札情報一覧表示画面２８６が再度表示される。
【００８５】
なお、オークションは、オークションマスタテーブル１７４に記憶されたオークションの開始時期にならなければ開始されない。また、オークションマスタテーブル１７４に記憶された終了時期になると終了する。オークションの開催時期以外の時期には、図６に示す画面は表示されず、入札もできなくなる。仮にそのような時期に何らかの原因で入札がされたとしても、入札内容がエラーであるとして入札が拒否される。
【００８６】
このようにして、入札明細テーブル１７６には、複数のサイト運営者４６による入札明細が蓄積される。この入札処理では、あるプロトタイプについて、既に付けられている単価よりも高い単価をつけない限り、入札内容が正当でないとして拒否される。本実施の形態でのプロトタイプの入札の処理自体は、通常行なわれているオークションの技術をそのまま転用できる。
【００８７】
なお、このオークションに入札したサイト運営者は、自分が入札したプロトタイプについて、クエリ文を作成するためのマッピングルールをマッピングコーパステーブル１８０に追加できる。各マッピングルールは、入札されたプロトタイプ文のプロトタイプＩＤ及び入札者ＩＤと関連付けてマッピングコーパステーブル１８０に蓄積される。
【００８８】
開催されているオークションについて、オークションマスタテーブル１７４中の該当レコードの終了時期に到達すると、落札処理部２６２は、落札処理を開始する。
【００８９】
落札処理では落札処理部２６２は、落札情報テーブル１７８から、プロトタイプごとに最も単価の高い入札明細を抽出する（図９のステップ３１０）。抽出された全ての明細に対し、入札明細テーブル１７６内のその明細に対応するレコードの落札フラグをセットし（ステップ３４０）、プロトタイプテーブル１７２中の、その明細中のプロトタイプＩＤに対応するレコードの入札完了フラグをオンに更新する（ステップ３４２）。
【００９０】
ステップ３１０で抽出された全ての入札明細に対し、ステップ３４０及びステップ３４２の処理が完了すると、再び入札明細テーブル１７６から落札フラグがオンの明細を入札者ＩＤ順、プロトタイプＩＤ順に読出す（ステップ３１６）。これらのレコードの入札者ＩＤにより示される入札者が各プロトタイプの落札者である。ステップ３１８で、各落札者に対し、落札内容の通知メールを生成し、送信する。このとき、落札情報テーブル１７８に、落札内容のレコードを追加する。
【００９１】
続いて、プロトタイプテーブル１７２から、該当するオークションＩＤを持ち入札完了フラグがオフのレコードを読出し（ステップ３２０）、その件数が０か否かを判定する。件数が０であれば全てのプロトタイプについて落札が完了したということであるので、オークションマスタのオークション完了フラグをセットし（ステップ３２４）、オークション完了のメッセージをシステム出力に出力して処理を終了する。ステップ３２０で読出されたレコードの件数が０でなければ、有効な入札がなかったプロトタイプ文が存在するということである。この場合にはオークション未完のメッセージとともにそれらプロトタイプ文を特定する情報をシステム出力に出力して（ステップ３２８）処理を終了する。
【００９２】
オークション管理者は、オークションが未完の場合には、再度、入札がなかったプロトタイプの入札を行なうことができる。全てのプロトタイプが落札されれば問題ないが、一部のプロトタイプについて落札者が最後までない場合には、それらプロトタイプと、そのプロトタイプのクラスタに属する質問文とに特定の情報を付しておく。オークションで、それら質問文に近い検索要求が来た場合の処理については後述する。
【００９３】
落札処理が完了すると、落札情報が落札情報テーブル１７８に保持されている。
【００９４】
─運用フェーズ─
図２に示すオークション管理部１０８は、タイマ１１０の出力に基づいてオークションデータＤＢ１０６の内容を常にチェックし、オークションの運用開始時期に到達したオークションであって、オークション開始フラグ及びオークション完了フラグが共にオン、運用開始フラグ及び運用完了フラグがともにオフのものがあるか否かを調べる。そのようなオークションがあれば、オークション管理部１０８は、そのオークションについて、オークションマスタ更新部２６０及び運用ＤＢ更新部２６６に対し、オークションの運用の切替の指示を発行する。
【００９５】
オークションマスタ更新部２６０はこの指示を受けると、オークションマスタテーブル１７４の該当するレコード２５４の運用開始フラグをオンに更新する。
【００９６】
運用ＤＢ更新部２６６は、この指示を受けると、落札情報テーブル１７８の記憶内容に基づいて質問文―ＵＲＬ対照ＤＢ６８及びマッピングコーパス７０の内容を更新する。具体的には、各プロトタイプを入札したサイト運営者の、入札者テーブル１７０のレコードからＵＲＬを読出し、そのプロトタイプのクラスタに属する各質問文と、読み出されたＵＲＬとを関係付けて質問文―ＵＲＬ対照ＤＢ６８に保存する。単にプロトタイプＩＤとＵＲＬとを関係付けた情報を質問文―ＵＲＬ対照ＤＢ６８に記憶させるようにしてもよい。この場合、質問文―ＵＲＬ対照ＤＢ６８の容量を小さくできる。ただしこの場合には、検索要求を受けたときに、その検索要求との距離が最も小さな質問文を特定した後、その質問文が属するクラスタのプロトタイプを特定してからでないと質問文―ＵＲＬ対照ＤＢ６８からＵＲＬを読出すことができず、応答性が多少悪くなる可能性がある。
【００９７】
運用ＤＢ更新部２６６はまた、各プロトタイプについて、マッピングコーパステーブル１８０に各質問文に関連付けて記憶されているマッピングルールのうち、そのプロトタイプの落札者によるもののみを選択してマッピングコーパス７０に転記する。
【００９８】
なお、本実施の形態では、この転記は運用の切替時に行なわれるので、落札後、運用開始までの間にも落札者がマッピングルールを追加することができる。ただし、そのような処理を禁止することもできる。そのような場合、マッピングコーパステーブル１８０からマッピングコーパス７０への転記を、オークションの落札時に行なうようにしてもよい。
【００９９】
運用が開始されると情報検索サービスシステム４０は以下のように動作する。端末４４は本実施の形態では携帯電話であることが想定されている。端末４４のユーザは、情報検索サービスシステム４０のサービスを利用するためのウェブページにアクセスし、検索要求を音声で入力する。端末４４上は、通常の携帯電話の処理と同様、入力音声をコードブックを用いてコード化し、情報検索サービスシステム４０のコード受信部８０に送信する。
【０１００】
コード受信部８０は、受信した一連のコードからコードブックを用いてもとの音声データを復元し、特徴量算出部８２に与える。特徴量算出部８２は、この音声データをフレーム化し、各フレームから所定の音響特徴量を算出して音声認識装置８４に与える。音声認識装置８４は、通常の音声認識装置として動作し、検索要求に対応するテキストデータを生成して質問文解析部１３０に与える。
【０１０１】
質問文解析部１３０はこの検索要求のテキストデータを受けると、そのデータにより表される文章（ここでは日本語が想定している。）に対する形態素解析、構文解析、意味解析などの処理を行なって形態素列を生成し質問文検索部１３２に与える。各形態素には、質問文解析部１３０の処理の結果、品詞タグ、階層的な意味タグなど、質問文検索に必要な情報がタグとして付されている。
【０１０２】
質問文検索部１３２は、コーパス記憶装置６４に記憶されている各質問文と、質問文解析部１３０から与えられる検索要求の形態素列との間の距離を計算し、検索要求との距離が最短である質問文を特定し、その質問文ＩＤをＵＲＬ検索部１３４に検索要求とともに与える。
【０１０３】
ＵＲＬ検索部１３４は、与えられた質問文ＩＤに基づいて質問文―ＵＲＬ対照ＤＢ６８から対応するＵＲＬを読出す。クエリ生成部１３６は、この質問文又はプロトタイプ文に対応してマッピングコーパス７０に記憶されているマッピングルールを読出す。クエリ生成部１３６はさらに、検索要求、ＵＲＬ，及びマッピングルールに基づいてクエリを生成し、クエリ発行部１３８に与える。クエリ発行部１３８は、このクエリをインターネット上に送信し、当該クエリはＵＲＬにより指定されるサービスサイト４２に送信される。
【０１０４】
サービスサイト４２では、このクエリについては予め準備されていたマッピングルールに基づくものであるため、高い精度でクエリに対応する応答（ＨＴＭＬ文書）を生成し、クエリ発行部１３８に返信してくる。クエリ発行部１３８は、受信したＨＴＭＬ文書をクエリ結果送信部１４０に与える。
【０１０５】
クエリ結果送信部１４０は、クエリ発行部１３８から与えられたＨＴＭＬ文書をサービス利用端末４８に転送する。このとき転送されるＨＴＭＬ文書は、あたかもサービスサイト４２から直接サービス利用端末４８に返信されたようにサービス利用端末４８上で表示されるようにすることが望ましい。クエリ結果送信部１４０は、クエリ結果の送信をするたびに、その内容を検索ログとして検索ログ記憶部１５０に保存する。検索ログとしては、各落札者に対する請求ができる程度の情報を保存するだけでよいが、検索ログから得られる統計的情報をさらに落札者に提供する場合には、目的にあわせた情報を検索ログに記録することが望ましい。
【０１０６】
１請求期間が経過すると、請求処理部１５２は検索ログ記憶部１５０からその請求期間内に行なわれた検索の検索ログを検索ログ記憶部１５０から抽出する。請求処理部１５２はさらに、抽出された検索ログについて、その検索の際に用いられたプロトタイプＩＤから、そのプロトタイプの落札者及びその落札単価を特定し、落札者毎に集計して、検索ログから得た、請求金額の計算の基礎データとともに請求書を送付する。全ての落札者に対してこの処理が終了すると、請求処理の終了に伴う処理を行なう。
【０１０７】
以上のように本実施の形態によれば、質問文コーパスを構成する、非常に大きな数の質問文について、実質的に個別にオークションにかけることができる。落札者は、落札した質問文については、その質問文に類似した情報要求があれば、その情報要求に対して自分が運営するサイト又は自分が関係するサイトからの情報を応答として要求者の端末に返信する処理を独占的に行なうことができる。落札者は、自己のサイトで提供するサービスが利用される機会を効率的に得ることができるという効果がある。
【０１０８】
情報要求者の立場から言うと、従来のように一旦検索サイトで情報を検索した後、提示されたリストの中から自分の必要とする情報を選ぶ、というスタイルではなく、入力した情報検索のための質問文に類似した質問文の落札者の運営するサイトで提供されるサービスに直ちにアクセスできる。質問文は、質問文に含まれるキーワードの属性により異なるサイト運営者により落札されるので、情報の検索要求ごとに適切なサービスを提供するサイト運営者のサイトの情報を直接得ることができる。したがって、検索結果の一覧から情報を選択するという手間を省くことができる。
【０１０９】
［第２の実施の形態］
〈構成〉
上に説明した第１の実施の形態では、質問文が互いに重複しない複数のクラスタに分類されることを前提としている。そのようにシステムを構成することにより、システムの構造を簡略なものとすることができる。
【０１１０】
しかし、オークションでは、そのように互いに排他的な値をとる属性により質問文を分類するだけでなく、重層的な分類を許す必要が生じることも考えられる。例えば、プロトタイプ文のみを指定して入札するのではなく、プロトタイプ文にさらに情報検索要求の属性に基づいて特定サイトにその検索要求を誘導する場合である。例えば、飲食店に関する検索要求について、地域を指定せず「レストラン」を属性に選択する場合と、特定地域（例えば大阪府内、京都市内など）のみを指定して「レストラン」を属性に選択する場合とを考える。両者は一方の選択地域が他方の選択地域を包含する形となっている。この場合、地域を指定しない入札者と、特定地域のみを指定した入札者とがあれば、それらは、特定地域については互いに競合するが、それ以外の地域では特に競合はしない。だとすれば、これらの入札者の間でも何らかの形でオークションを成立させ、かつ特定サイト検索サービスの運営者にとっての利益も極大化できれば好ましい。
【０１１１】
本実施の形態ではそのような形でのオークションを可能とする。そのために本実施の形態では、意味的辞書と同様の形式で、ツリー状の属性ツリーを予め準備し、このツリーにより属性の包含関係を調べる。同じ種類の属性について、互いに包含関係にある２つの値が指定され、単価を除いた他の条件が同一の２以上の入札が発生した場合、その種類の属性の属性ツリー上で下位にある値の属性範囲についてはいずれか単価が高いものが落札することとし、属性ツリー上で上位にある値の属性範囲については、その値を指定して入札したものが落札することとする。
【０１１２】
例えば、下位の属性値を指定した入札者の入札単価の方が上位の属性値を指定した入札者の入札単価よりも高い場合、その下位の値を指定して入札者がその範囲については落札し、上位の属性値を指定した入札者はその値により指定される範囲の内、下位の値により定まる範囲を除外した部分のみ落札するようにする。上位の属性値を指定した入札者の入札単価の方が下位の属性値を指定した入札者の入札単価よりも高い場合、その属性値により定まる範囲の全体について、上位の値を指定したものが落札する。
【０１１３】
このようにすることにより、例えばビジネスとして限定された範囲を対象としているサイト運営者はある属性について、その限定された範囲のみを比較的高値で入札し落札することにより、自分のビジネスを有利に運営することができる。ビジネスとして広い範囲を対象としているサイト運営者は、広い範囲については比較的低い入札単価で落札する機会を持つことができ、かつ競合する範囲については他の入札者でより高い入札単価を示したものに譲ることも、その範囲のみを指定してより高い単価で入札することもできる。オークションに参加するサイト運営者にとって、自己のビジネスが対象とする範囲に応じた戦略にしたがって入札を行なうことができる。その結果、オークションがより活性化される可能性が高くなる。
【０１１４】
図１１に、この第２の実施の形態に係る情報検索サービスシステム４００の概略構成を示す。図１１に示す情報検索サービスシステム４００は、図２に示す情報検索サービスシステム４０に代えて用いることができる。
【０１１５】
図１１に示す情報検索サービスシステム４００が情報検索サービスシステム４０と異なるのは、オークションシステム６２に代えて上記したような重層的な属性値でのオークションを可能にする機能を持つオークションシステム４０４を含む点、及び、特定サイト検索サービス実行部６６に代えて、そうした重層的なオークションの落札結果にしたがって情報の検索要求を適切なサービスサイト４２に誘導する機能を持つ特定サイト検索サービス実行部４０６を含む点である。
【０１１６】
オークションシステム４０４はオークションシステム６２と同様の構成を持つが、上記した属性ツリーを記憶するための属性ツリー記憶部４２２を新たに含む点と、オークションシステム６２で用いられたオークション関連のデータについて、重層的な分類を許容する形式のデータとなるように修正したデータを記憶する、図２に示すオークションデータＤＢ１０６に相当するオークションデータＤＢ４２６を含む点と、同様に重層的な分類を許容する形でのオークション処理と落札処理及び特定サイト検索サービスの切替処理とをそれぞれ実行するオークション実行部４２０及び更新部４２４を含む点とにおいて、図２に示すオークションシステム６２と異なっている。なお、図１１に示すオークション実行部４２０は図２に示すオークション実行部１０４に、更新部４２４は図２に示す更新部１１２に、それぞれ相当する。
【０１１７】
図１２に、オークションデータＤＢ４２６のテーブルのうち、プロトタイプテーブルのレコード４４０と、入札明細テーブルのレコード４４２との構成を示す。
【０１１８】
プロトタイプテーブルのレコード４４０は、第１の実施の形態のプロトタイプテーブル１７２のレコード２５２（図５参照）に加え、第１及び第２の属性の値を保持する２つのフィールドを持つ。入札明細テーブルのレコード４４２は、第１の実施の形態の入札明細テーブル１７６のレコード２５６に加え、入札時に入札者がプロトタイプ文の属性についてそれぞれ選択した属性値を格納する、第１及び第２の属性特定情報フィールドを持つ。
【０１１９】
〔画面構成及び画面遷移〕
図１３を参照して、この第２の実施の形態に係る情報検索サービスシステム４００が運営するオークションに対し、入札者が質問文入札の際の問合せをしたときの入札初期画面４５０では、プロトタイプ文と、その入札に関連する簡単な情報とが明細行としてプロトタイプＩＤ順に表示される。
【０１２０】
各明細行は、プロトタイプ文に対する入札の詳細を表示させるための右向きの三角形と、プロトタイプに振られた番号（「番号」欄）と、プロトタイプ文（「代表文」欄）と、そのプロトタイプ文に対する入札数（「入札有無」欄）と、この画面を表示させているユーザによる入札がそのプロトタイプ文に対し行なわれているか否かを示す情報（「応札」欄）と、プロトタイプに関する詳細（図１２に示すプロトタイプテーブルのレコード４４０の内容）を表示させるための詳細ボタンとを含む。
【０１２１】
各明細行の左端の右向き三角をユーザがクリックすると、その明細についての入札の内容が表示される。このときの画面を図１４に示す。以下に説明する画面の画面遷移は、クライアント側のみで行なわれる処理による画面遷移と、クライアントからサーバに対してその都度入力データを送信し、サーバでの処理により生成された画面データをクライアントに返信することによる画面遷移との双方を適切に組合せて実現することができる。
【０１２２】
図１４に示す画面は、番号＝１のプロトタイプの右三角形がクリックされたときの画面である。番号＝１のプロトタイプの行の左端の右向き三角形が下向き三角形に変化し、入札内容が展開されて下部に表示される。図１４に示す例では、番号＝１のプロトタイプに対しては４つの入札がある。これらがそれぞれ別々の入札明細表示行として表示されている。
【０１２３】
このプロトタイプには２つの属性を適用するためのフィールドがある。この例では、第１の属性は「地名」であり、第２の属性は「飲食店」である。すなわち、このプロトタイプ文には属性が付与されたキーワードが２つ存在している。
【０１２４】
各入札明細表示行は、その入札明細の内で、落札の可能性があるもののみを示している。すなわちこの例では、現時点では４人のユーザが別々に落札可能である。
【０１２５】
各入札明細表示行は、その入札明細表示に割当てられた番号（「１．１」など）と、プロトタイプ文の第１及び第２の属性に対して、入札者が指定した値（「属性名１」欄及び「属性名２」欄）と、入札価格（「最高入札価格」欄）とを含む。属性の指定値が異なる場合、別々の入札者が落札できる。競合する入札者の場合には、落札可能な単価をつけたものの入札の内容のみがここに表示される。
【０１２６】
各入札明細表示行はさらに、この画面を現在操作しているユーザがこの入札明細と単価を除いて同じ条件で入札するかどうかを指定するための「応札」欄と、応札する場合の単価を入札する「単価」欄とを含む。応札欄にはプルダウンメニューがデフォルトで（応札）「しない」が表示される。このメニューで「する」を選択すると「単価」の入力が可能になる。このときの表示を、例えば図１５の画面４５４内の１番目のプロトタイプに対する４番目の入札明細行により示す。いずれかの入札明細に関する入札を行ない「入札する」ボタンを押すと、入札内容がサーバに送られ、入札明細の追加が行なわれる。
【０１２７】
なお本実施の形態では、単価として既に入札されている最高入札価格よりも高い金額でなければ入札はできないようにする。属性について、同じ値の属性でより価格の高い入札があれば、その前に表示されていた入札明細は画面上で削除される。しかし、既に属性値についてある値を指定してある単価での入札がされていたところに、属性の値としてより狭い範囲のものを指定した、より単価の高い入札があった場合には、新たな入札が追加されるが、元から存在していた入札明細も残る。新たな入札により指定された範囲以外の部分については、その前に最高価格で入札していた明細が有効と考えられるためである。属性によりどのような範囲が指定されたかについては、後述する属性ツリーにより判定する。
【０１２８】
図１４において、１番目のプロトタイプに対する１番目の入札は、第１の属性（地名）及び第２の属性の双方について指定せず、４．２円を入札単価としたものである。２番目の入札は、地名として「東京都」を指定し、飲食店として「ラーメン」を指定した、５．３０円を入札単価としたものである。この２番目の入札は１番目の入札よりも後にされたもので、１番目の入札よりも狭い範囲を指定した、より高い単価のものである。したがって２番目の入札が追加されると共に、１番目の入札も、２番目の入札により指定された範囲以外の範囲を指定したものとして、残っている。
【０１２９】
３番目の入札は、地名として霞ヶ関、飲食店の種類としてラーメンを指定した、５．３２円を入札単価とするものである。これも２番目の入札よりもより狭い範囲を指定した、より高い単価のものであるので有効である。同時に、「霞ヶ関」以外の地域で「ラーメン」を指定した部分については、２番目の入札が依然として有効なので、２番目の入札もまだ残っている。
【０１３０】
４番目の入札は、地名として「大阪市」を、飲食店の種類として「ラーメン」を、それぞれ指定した、単価４．４０円のものである。この入札は、１番目の入札とは部分的に競合するが、２番目及び３番目の入札とは競合しない。１番目の入札に対して、指定した属性により定まる範囲はこちらの方が狭い。したがってこの入札も有効である。
【０１３１】
以上から、１番目のプロトタイプ文に対する１番目の入札はこの状態でも依然として有効であるが、ただしその範囲としては、飲食店の種類としてラーメンについては地名の全範囲から東京都と大阪市とを除いた範囲で有効であり、ラーメン以外については、地名の全範囲について有効なものとして残っている。２番目の入札については、飲食店の種類としてラーメンで、かつ地名としては東京都の範囲内で、ただし霞ヶ関を除く部分についてのみ有効なものとして残っている。
【０１３２】
図１４に示す例では、１番目のプロトタイプの４番目の入札明細行（最後の入札明細行）について、その左端にプラスマークが表示されている。このプラスマークをクリックすると、新たな入札明細行が画面上に表示され、ユーザが２つの属性及び単価を指定して、このプロトタイプ文に対する新たな入札を行なうことができる。このときの表示状態を図１６の画面４５６の、１番目のプロトタイプに対する５番目の入札明細行により示す。
【０１３３】
本実施の形態では、指定できる属性の種類、及びその値については予めサーバで属性ツリーとして準備しているものに限定されていることが前提である。新たな入札の入力時には、プルダウンメニューにそれら許されるもののみが表示され、その中からユーザの希望するものを選ぶものとする。
【０１３４】
例えば図１６に示す状態で単価を指定して「入札する」ボタンを押すと、入札情報がサーバに送られ、その処理の結果の画面４５８が図１７に示すように表示される。この例では、このユーザが新たな属性を指定して第１のプロトタイプに対する入札を追加し、かつ４番目の入札明細行についてはより高い単価で入札をした。その結果、第１のプロトタイプに対する入札数は全部で５となり、その中でこのユーザによるものが２となる。したがってその内容に対応する表示が第１のプロトタイプの明細行の入札有無欄に「あり（５）」として、応札欄に「あり（２）」として、それぞれ示されている。
【０１３５】
仮に図１７に示す画面４５８で第１のプロトタイプの明細行の左端の右向きの三角形をクリックすると、図１４に示す場合と同様、第１のプロトタイプに対する入札明細行の表示画面４６０が図１８に示すように表示される。ただしこの例では、端末を操作しているユーザによる入札が２つあるため、それらは他の入札と区別して画面上、強調表示される。例えば文字色を変えたり、背景色を変えたり、反転表示したり、特定のマークを入札明細行に追加表示したりすることが考えられる。
【０１３６】
〔属性ツリー〕
図１９を参照して、図１１の属性ツリー記憶部４２２に記憶される属性ツリー４７０は、予め属性ごとに準備される。図１９に示す属性ツリー４７０は、地域に関するものである。この例では、属性ツリー４７０は、日本全体を示すルートノードと、ルートノードから分岐する、日本全体を東北・北海道、関東・甲信越、東海、北陸などの第１の階層に分割した第１階層のノードと、第１階層のノードの各々から分岐し、そのノードにより表される地域をより細かく、例えば県単位に分割した第２階層のノードと、さらに第２階層のノードの各々から分岐する第３階層のノードと、などを含む。階層の数及びどの範囲で各ノードにより表される地域を分割するかは、システムの設計により容易に定めることができる。
【０１３７】
なお、この例では地名に関する属性ツリーで、ルートノードにより日本全国が表されるものとしたが、もちろん本実施の形態の地名に属する属性ツリーがそのようなものに限定されるわけではない。より広く、アジア全体、又は世界全体を分割するような属性ツリーでもよい。
【０１３８】
この属性ツリーは、属性に関して重複する入札を許し、かつそれらについていずれが有効かを明確に判定するため、ノードの上下関係が明確になるような構成を持つ。あるノードは、ルートノードを除き必ず１つだけ親ノードを持ち、同じノードから分岐する同じ階層に属するノードは、互いに異なる範囲を指定する。
【０１３９】
このノードで、ある階層のノードを指定した入札がある場合、そのノードより下位のノードを指定した入札で、より高価な単価を指定した入札をすることが可能である。その場合、既存の入札については、新たな入札により指定された以外の範囲についてのみ有効となる。
【０１４０】
ある階層のノードを指定した入札がある場合、そのノードより上位のノードを指定した入札も可能であるが、この場合には単価は新たに指定されたノードをルートノードとする部分ツリーを指定したいずれの入札に対しても、より高い単価を指定しなければならない。そのような条件が満たされれば、新たな入札が有効となり、その下のノードを指定した入札は全て無効となる。
【０１４１】
属性ツリーでは、同じ階層のノードの間では、そのノードに対応する値により指定される範囲は重複せず、ある階層のノードの値により指定される範囲は、そのノードから分岐する全てのノードの値により指定される範囲を包含する。すなわち、属性ツリーは、ある種類の属性に付いて、その属性の値の間の包含関係をツリー形式で現したものである。
【０１４２】
〔プログラム構造〕
図２０を参照して、入札初期画面の表示要求を端末から受けたサーバで実行されるプログラムの制御構造を説明する。このプログラムは、プロトタイプＩＤ，第１の属性特定情報、及び第２の属性特定情報ごとに、最高入札単価の入札明細を入札明細テーブルで検索するステップ４８０と、現在のオークション対象となっているオークションのレコードをオークションマスタテーブルから読出し、入札初期画面のヘッダ部分を作成するステップ４８２と、以下に説明するプロトタイプ明細作成ルーチン４８６を各プロトタイプについて実行するステップ４８４と、「戻る」ボタン及び「入札する」ボタンを含むボトム部分を作成するステップ４８８とを含む。
【０１４３】
プロトタイプ明細作成ルーチン４８６は、処理対象のプロトタイプについて、プロトタイプの明細行を作成するステップ４９０と、ステップ４８０で読出された入札明細のうち、処理対象のプロトタイプのＩＤをプロトタイプＩＤとして持つ全ての入札明細について以下の入札明細行作成ルーチン４９４を実行するステップ４９２とを含む。
【０１４４】
入札明細行作成ルーチン４９４は、処理対象の入札明細行が、処理対象のプロトタイプ文に関する最後の入札明細行か否かを判定し、判定結果に応じて制御の流れを分岐させるステップ５００と、ステップ５００の判定が肯定のときに、入札明細の追加を指示するための追加ボタン（図１４などに示すプラスボタン）を作成するステップ５０２と、ステップ５００の判定が否定のとき、又はステップ５００の判定が肯定でステップ５０２の処理が完了したときに実行され、処理対象の入札明細の入札者ＩＤが、入札初期画面の表示要求を送信してきたユーザの入札者ＩＤと一致するか否かを判定し、判定結果に応じて制御の流れを分岐させるステップ５０４とを含む。
【０１４５】
入札明細行作成ルーチン４９４はさらに、ステップ５０４の判定が肯定のときに実行され、入札者用の、強調表示された入札明細行を作成してこのルーチンの実行を終了させるステップ５０８と、ステップ５０４の判定が否定のときに実行され、通常の入札明細行を作成してこのルーチンの実行を終了させるステップ５０６とを含む。
【０１４６】
図２１を参照して、ユーザが端末で「入札する」というボタンを押すことにより送信されてきた情報を処理するためのサーバプログラムは、以下のような制御構造を持つ。
【０１４７】
このプログラムは、入札処理後に表示される画面のヘッダを作成するステップ５１０と、入力される入札明細に誤りがあるか否かを判定するためのエラーフラグを０に設定するステップ５１２と、端末から送信されてきた入札明細について、以下に説明する入札チェックルーチン５１６を実行するステップ５１４と、ステップ５１４の処理の後に実行され、エラーフラグが０か否かを判定し、判定結果にしたがって制御の流れを分岐させるステップ５１８とを含む。
【０１４８】
本実施の形態では、基本的には端末での入札が過去の入札データに対して正当なものか否かについての判定を、端末での入力時点で端末において行なう。その判定結果をパスしたものが入力サーバに送信されてくる。したがって、基本的にはサーバでのこのようなチェックはしなくても、入力に誤りがある可能性は低い。しかし、端末でのチェックは、入札初期画面の表示要求をサーバが受信したときの入札明細に基づいて行なわれる。そのため、同一のプロトタイプに対して競合するような入札が２以上の入札者からほぼ同時に行なわれることもないとはいえない。そこで、本実施の形態では、念のために入札チェックルーチン５１６を実行し、万が一、互いに競合するような入札があった場合でもチェックできるようにする。
【０１４９】
入札チェックルーチン５１６は、処理対象の入札明細に対応するプロトタイプに関する情報を表示するプロトタイプ行を作成するステップ５３０と、処理対象の入札明細に関する応札が端末からなされたか否かを判定して制御の流れを分岐させるステップ５３２と、ステップ５３２の判定が肯定のときに、処理対象の入札明細をチェックするステップ５３４と、ステップ５３４での判定結果にしたがって、表示される画面の入札明細行を作成して処理を終了するステップ５３６とを含む。ステップ５３２の判定が否定のときには入札チェックルーチン５１６の実行は終了する。ステップ５３４の処理内容については図２２を参照して後述する。
【０１５０】
このプログラムはさらに、ステップ５１８の判定が肯定の時に実行され、端末から受信した、応札のあった各行について、入力内容に対応した入札明細レコードを作成し入札明細テーブルに追加するステップ５２２を実行するステップ５２０と、ステップ５１８の判定が否定のときに実行され、エラーメッセージを出力するステップ５２４と、ステップ５２２の後、及びステップ５２４の後に実行され、表示画面のボトム部分を作成して処理を終了するステップ５２６とを含む。
【０１５１】
図２２を参照して、図２１のステップ５３４で実行される入札明細行のチェック処理のルーチンは以下のような制御構造を持つ。すなわちこのルーチンは、チェック対象となっている入札明細行の第１及び第２の属性が空白か否かに応じて、制御の流れを分岐させるステップ５４０と、第１及び第２の属性がともに空白のときに実行され、処理対象の入札明細行と同一プロトタイプＩＤ，第１及び第２の属性が空白の入札明細レコードを入札明細テーブルで検索し、その最高単価を調べるステップ５４２と、第１の属性が非空白で、第２の属性が空白のときに実行され、処理対象の入札明細行と同一プロトタイプＩＤ、第２の属性が空白、第１の属性として第１の属性の入力値を包含する（属性ツリー上で第１の属性の入力値より上位のノードで、かつそのノードをルートノードとする部分木内に第１の属性の入力値に対応するノードを含むもの）ような値を持つ入札明細レコードを入札明細テーブルで検索し、その単価の最高値を取出すステップ５４４とを含む。
【０１５２】
このルーチンはさらに、第１の属性が空白で第２の属性が非空白であるときに実行され、入札明細行と同一プロトコルＩＤ，第１の属性が空白、第２の属性として第２の属性の入力値を包含する（属性ツリー上で第２の属性の入力値より上位のノードで、かつそのノードをルートノードとする部分木内に第２の属性の入力値に対応するノードを含むもの）ような値を持つ入札明細レコードを入札明細テーブルで検索し、その単価の最高値を取出すステップ５４６と、第１及び第２の属性の双方とも非空白のときに実行され、入札明細行と同一プロトコルＩＤ，第１の属性として第１の属性の入力値を包含するような値を持ち、第２の属性として第２の属性の入力値を包含するような値を持つ入札明細レコードを入札明細テーブルで検索し、その単価の最高値を取出すステップ５４８とを含む。
【０１５３】
このルーチンはさらに、ステップ５４２，５４４，５４６及び５４８に続き、入力された入札明細の入札単価が、これらステップで検索された入札明細レコードの単価より大きいか否かを判定し、判定結果により制御の流れを分岐させるステップ５５０と、ステップ５５０の判定結果が肯定のときに、処理対象の入札明細行に応じた通常行のデータを作成し出力して処理をこのルーチンの実行を終了するステップ５５２と、ステップ５５０の判定が否定の時に実行され、エラーフラグを１に設定するステップ５５４と、ステップ５５４に続き、処理対象の入札明細行に応じてエラー行のデータを作成して出力し、このルーチンの実行を終了するステップ５５６とを含む。
【０１５４】
図２３を参照して、第２の実施の形態のサーバにおいて行なわれる落札処理を実現するプログラムは以下のような制御構造を持つ。すなわち、このプログラムは入札明細テーブルから入札完了フラグがオフのレコードについて、プロトタイプＩＤ，第１及び第２の属性値の組合せごとに、最高入札単価の入札明細レコードを抽出するステップ５６０と、ステップ５６０で抽出された全明細に対して図９に示したものと同じ処理を実行するステップ３１２と、ステップ３１２に続き、入札明細テーブルから、落札フラグがオンの明細を入札者ＩＤ順及びプロトタイプＩＤ順で読出すステップ５６２とを含む。このステップ５６２で読み出された明細の各々が落札者を決定する。これら落札明細のレコードは落札情報テーブル１７８に追加される。
【０１５５】
このプログラムはさらに、ステップ５６２に読み出された入札明細により決定された落札者の各々について、落札結果を作成し発送するステップ５６４と、ステップ５６４の後、図９に示すものと同じ処理を実行して処理を終了するステップ３２２〜ステップ３２８とを含む。
【０１５６】
図２４を参照して、本実施の形態に係る特定サイト検索サービス実行部４０６が情報検索要求を受信したときに、特定サイト検索サービス実行部４０６で実行されるプログラムの制御構造について説明する。なお、以下の説明は、特定サイト検索サービス実行部４０６の内で質問文検索部１３２以後の各モジュールに関するものである。
【０１５７】
このプログラムは、図１０を参照して既に説明したものと同じ処理を実行するステップ３６０〜ステップ３６６と、ステップ３６６の後、ステップ３６６で選択されたプロトタイプについて、そのプロトタイプ中の記載に基づいて第１及び第２の属性ツリーを属性ツリー記憶部４２２から読出すステップ５８０とを含む。なお、このステップでは、入札明細行の属性の値が空白のときには属性ツリーの読出は行なわず、以下の処理でもそれらについての処理は行なわない。ただし以下の説明及び図面では説明を分かりやすくするため、属性の値が空白であったときの処理については説明しない。
【０１５８】
このプログラムはさらに、ステップ５８０に続き、選択されたプロトタイプのプロトタイプＩＤと、入札明細行の第１の属性値を包含する第１の属性値であって、ツリー内のレベルが最も低いノードに対応する値とを持つ落札明細レコードを落札情報テーブルから検索するステップ５８２と、ステップ５８２に続き、ステップ５８２で検索された落札明細の中から、選択されたプロトタイプのプロトタイプＩＤと、入札明細行の第２の属性値を包含する第２の属性値であって、ツリー内のレベルが最も低いノードに対応する値とを持つ落札明細レコードを抽出するステップ５８４と、図１０を参照して既に説明したものと同じ処理をそれぞれ実行して処理を終了するステップ３６８〜ステップ３７６とを含む。
【０１５９】
〈動作〉
上記した第２の実施の形態に係る情報検索サービスシステム４００は以下のように動作する。この情報検索サービスシステム４００の場合にも、動作フェーズは３つある。第１のフェーズはオークションの準備フェーズである。第２のフェーズはオークションフェーズである。第３のフェーズはオークションの結果に基づく特定サイト検索サービスの運用フェーズである。
【０１６０】
オークションの準備フェーズは、第１の実施の形態と基本的に同様である。ただし、プロトタイプには第１及び第２の属性の値が（もしあれば）キーワードとともにタグ付けされる。また、それら属性の各種類について、属性ツリーが予め作成され、機械可読な属性ツリー記憶部４２２に機械可読な形式で記憶される。
【０１６１】
オークション開始時になると、オークション管理部１０８の制御により、オークション実行部４２０が所定のオークションを開始する。開催中のオークションに関する入札初期画面の表示要求をオークション入札者４０２がオークションシステム４０４に与えると、オークション実行部４２０は以下のように動作する。
【０１６２】
オークション実行部４２０は、開催中のオークションに関する入札初期画面４５０（図１３参照）を作成し、入札者の端末に表示させる。この入札初期画面４５０には、以下の処理を全て実行するために必要な情報と、スクリプトとが含まれる。入札者がいずれかのプロトタイプの明細行の先頭の右向き三角をクリックすると、端末は右向き三角がクリックされたときのスクリプトを実行し、図１４に示す画面４５２と同様の画面を表示する。この画面で入札者が「戻る」を押すと画面は再び図１３に示すものに戻る。このとき、端末内での処理だけではなく、サーバで入札初期画面４５０を作り直すようにすると好ましい。
【０１６３】
図１４に示す画面４５２で入札者が応札「する」を選択したり、明細の追加を選択したりすると、端末はそれぞれ対応のスクリプトを実行し、例えば図１６の画面４５６を表示する。必要な入力を行なった後、入札者が「入札する」ボタンを押すと、入札明細行に関する情報がオークション実行部４２０に送信される。オークション実行部４２０は応札があると、その内容についてチェックし、エラーがなければ入札明細テーブルに入札内容を追加する。エラーがあれば入札内容を入札明細テーブルに追加することなく、エラー画面を端末に表示させる。
【０１６４】
このような処理を繰返しし、オークションの終了時期になるとオークション管理部１０８は、更新部４２４を制御して落札処理を行なう。落札処理では、更新部４２４は属性ツリー記憶部４２２に格納された属性ツリーを参照しながら、プロトタイプＩＤ、第１の属性値、及び第２の属性値の組合せごとに最高単価の入札明細レコードを入札明細テーブルから抽出し、落札情報テーブルに落札明細レコードとして追加する。更新部４２４は、第１の実施の場合と同様、質問文―ＵＲＬ対照ＤＢ４０８及びマッピングコーパス４１０についても落札結果に応じて更新する。落札結果はさらに、請求処理部１５２にも与えられる。請求処理部１５２は後の請求処理に必要な情報（単価情報など）を記憶する。
【０１６５】
オークションフェーズでは情報検索サービスシステム４００（特に特定サイト検索サービス実行部４０６）は以下のように凹さする。オークションについて落札処理が完了し、オークションの開始時期に到達すると、オークション管理部１０８はオークション管理部１０８はそのオークションの運用開始フラグをオンにセットする。
【０１６６】
端末４４から音声により情報の検索要求が来ると、音声入力フロントエンド６０は第１の実施の形態と同様の処理でこの検索要求を文字列に変換し質問文解析部１３０に与え、質問文解析部１３０はこの文字列に対する形態素解析などの処理を行ない、それぞれ意味的タグ及び品詞タグが付された形態素列を質問文検索部１３２に与える。質問文検索部１３２は、この形態素列とコーパス記憶装置６４に含まれる各質問文との間の距離を計算し、入力された形態素列との間の距離が最も小さな質問文を抽出し、ＵＲＬ検索部４３０に与える。ＵＲＬ検索部４３０は与えられた質問文に対応するＵＲＬを質問文―ＵＲＬ対照ＤＢ４０８から読出し、情報検索要求の形態素列と共にクエリ生成部４３２に与える。クエリ生成部４３２は、マッピングコーパス４１０から、選択された質問文に対応するマッピングコーパスを読出し、与えられた形態素列からキーワードを抽出し、マッピングコーパス内のキーワードに相当する位置に挿入してクエリを作成する。作成されたクエリはクエリ発行部１３８に与えられ、ＵＲＬ検索部４３０が読出したＵＲＬを指定してサービスサイト４２に送信される。サービスサイト４２から返信されてくる情報はクエリ発行部１３８を経てクエリ結果送信部１４０に与えられる。クエリ結果送信部１４０は、最初に情報の検索要求を送信してきたサービス利用端末４８に対し、クエリ結果を送信する。クエリ結果送信部１４０は同時に、検索ログを検索ログ記憶部１５０に書出す。
【０１６７】
情報検索サービスシステム４００は、受信した情報検索要求に対して以上のような処理を繰返す。この結果、情報検索要求の各々について、その情報検索要求に最も近い質問文がコーパス記憶装置６４から読み出され、その質問文が属するクラスタのプロトタイプを落札したサイト運営者に対する情報のクエリが行なわれる。クエリの結果は情報検索要求の発行者に戻される。その結果、情報検索要求を発行した利用者は、検索結果の単なる一覧ではなく、オークションにより落札した、情報検索要求に対する適切な情報を提供するサービス提供者のサービスに直接誘導される。その結果、利用者が必要な情報を入手する際の手間を少なくすることができる。サイトの運営者は、自分の運営するサイトにとって最も有効となるような範囲を属性として指定してプロトタイプ文を落札することで、潜在的な顧客を自己のサイトに誘導できる。狭い地域のみを対象とするようなサイトの場合には、その狭い地域について比較的高い単価でプロトタイプを落札できる。広い地域を対象とするサイトの場合、広い地域を指定して、比較的安い単価で入札することができる。
【０１６８】
なお、上記実施の形態では、先に高い単価で入札した入札明細が存在する場合には、後からたとえそれより広い範囲を指定するものであっても、より高い単価で入札しなければならない。しかし本発明はそのような実施の形態には限定されず、例えば後からある属性についてより広い範囲を指定して入札する場合、既に存在するより高い単価の入札明細により指定された範囲以外を指定して入札できるようにしてもよい。
【０１６９】
［第３の実施の形態］
上記した第１及び第２の実施の形態では、情報の検索要求（質問文）に類似する質問文、又は情報検索要求に含まれるキーワードに基づいて、その検索要求をどのサイトに転送するかを決めている。そして、その転送の仕方を、質問文コーパスをクラスタリングした結果に基づき、クラスタごとにオークションで決めている。しかし本発明はそのような実施の形態のみに限定されるわけではない。例えば属性が数値により表現される場合には、その属性の値が取りえる範囲をいくつかの数値範囲に分けてオークションにかけることが可能である。以下に説明する第３の実施の形態は、数値範囲に分けることができる属性として、情報の検索要求が発せられた端末の現在位置（ＧＰＳ位置）が属する範囲により、オークション対象を分割するというものである。
【０１７０】
なお、数値で表すことができる属性が位置情報に限定されないことは当然である。例えば温度、湿度、濃度、年齢、身長、体重、暦年、値段など、数値で表すことができる属性であれば、いずれもある範囲に分割し、それら範囲ごとにオークションにかけることができる。
【０１７１】
本実施の形態では、第２の実施の形態と同様、指定する範囲を予め属性ツリーと同様の構造に階層的なツリー構造で分類しておく。そうすることにより、第２の実施の形態と同じ論理を用いて数値範囲を指定したオークションを実現することができる。
【０１７２】
図２５に、この実施の形態における入札初期画面６００の例を示す。図２５を参照して、この入札初期画面６００は、基本的には図１３に示す入札初期画面４５０と同様である。この画面でプロトタイプの明細行の左端に表示されている右向き三角形をクリックすると画面は図２６に示す入札明細行表示画面６０２に遷移する。
【０１７３】
図２６を参照して、入札明細行表示画面６０２では、指定されたプロトタイプの明細行の左端の三角が下向きとなり、その行の下部に、その行のプロトタイプに関する入札明細行が展開して表示される。図２６に示す入札明細行表示画面６０２は、図１４に示す画面４５２と同様であるが、属性として属性名１のみが指定されている点が異なる。これは、ここでの第１のプロトタイプで指定されているのが属性名１のみであり、かつその内容が情報検索要求の位置情報となっていることによるものである。情報検索要求に付随して送信されてくる位置情報としては、端末に備えられたＧＰＳから得られるものが想定されている。
【０１７４】
本実施の形態で特徴的なのは、この第１の属性として、単語等ではなく、地図を用いた範囲による指定が行なわれている点である。図２６に示す例では、指定された範囲が地図として各入札明細行の属性の欄に表示される。これら各範囲については、その横に「範囲を確認」ボタンが表示されており、このボタンを押すと、別ウィンドウに、指定された範囲をより大きく表す地図が表示される。
【０１７５】
以下、既にある入札明細について、応札する場合の処理は既に説明したものと同様である。
【０１７６】
新たな入札を行なう場合には、このプロトコルに対応する入札明細行の内の最下行の左端に表示されたプラスマークをクリックすると、図２７に示す画面６０４に遷移する。画面６０４は、第２の実施形態の図１６に示したものと同様である。ただし、属性を指定するために「範囲を設定」ボタンが表示されている点が異なる。
【０１７７】
図２８に、「範囲を設定」ボタンを押したときに表示される画面６０６の例を示す。図２８に示す例では、画面６０６に重ねて、地図上の矩形を規定する２点（左上及び右下）を指定するウィンドウ６２０が表示される。本実施の形態では日本全図が最初に表示され、左側に示される拡大・縮小ボタン及び倍率変更ボタンと、地図のドラッグとにより自分の指定しようとする範囲を表示させ、指定して「ＯＫ」ボタンを押すことで、選択する地域を指定することができる。ただし本実施の形態では、既に説明したように、選択できる範囲は予め階層的な複数個の領域に分割されており、そのうちの一つのみした選択することはできない。このような区分の仕方を採用することで、オークションのロジックを簡単にし、第２の実施の形態と同様のプログラムで本実施の形態のシステムを実現することができる。
【０１７８】
図２８に示す画面６０６で範囲を指定して「ＯＫ」を押すと、図２７の画面と同様の画面に戻る。この画面でさらに「入札する」ボタンを押すと、第２の実施の形態と同様、サーバで入札明細のチェックが行なわれ、エラーがなければ、図２９に示すように、入札結果を反映した画面６０８が表示される。
【０１７９】
これ以外の点で、この第３の実施の形態に係るシステムの動作は第２の実施の形態と同様である。したがってここでは第３の実施の形態のシステムについての詳細は繰返さない。
【０１８０】
［コンピュータによる実現］
以上に説明した第１〜第３の実施の形態に係る情報検索サービスシステム４０及び情報検索サービスシステム４００などは、同様のハードウェア構成を持つ。例えば情報検索サービスシステム４０は、インターネットを介して他の装置と通信する機能を持つコンピュータハードウェアと、そのコンピュータハードウェアにより実行されるプログラムと、コンピュータハードウェアに格納されるデータとにより実現できる。プログラムの主要な部分の制御構造については図９及び図１０、並びに図２０〜図２４に示し、データ構造の例は図５及び図１２に示した。
【０１８１】
図３０を参照して、この情報検索サーバコンピュータ６３０は、ＦＤ（フレキシブルディスク）ドライブ６５２及びＣＤ−ＲＯＭ（コンパクトディスク読出専用メモリ）ドライブ６５０を有するコンピュータ６４０と、キーボード６４６と、マウス６４８と、モニタ６４２とを含む。
【０１８２】
図３１を参照して、コンピュータ６４０は、ＦＤドライブ６５２及びＣＤ−ＲＯＭドライブ６５０に加えて、ＣＰＵ（中央処理装置）６５６と、ＣＰＵ６５６、ＦＤドライブ６５２及びＣＤ−ＲＯＭドライブ６５０に接続されたバス６６６と、ブートアッププログラム等を記憶する読出専用メモリ（ＲＯＭ）６５８と、バス６６６に接続され、プログラム命令、システムプログラム、及び作業データ等を記憶するランダムアクセスメモリ（ＲＡＭ）６６０とを含む。情報検索サーバコンピュータ６３０はさらに、インターネットへの接続を提供するネットワークインターフェイス（Ｉ／Ｆ）６４４を含む。図示しないが、コンピュータ６４０はネットワークＩ／Ｆ６４４を介して携帯電話ネットワークと接続されており、他の端末とデータ通信を行なうことができる。
【０１８３】
情報検索サーバコンピュータ６３０に情報検索サービスシステム４０又は４００としての動作を行なわせるためのコンピュータプログラムは、ＣＤ−ＲＯＭドライブ６５０又はＦＤドライブ６５２に挿入されるＣＤ−ＲＯＭ６６２又はＦＤ６６４に記憶され、さらにハードディスク６５４に転送される。又は、プログラムは図示しないネットワークを通じてコンピュータ６４０に送信されハードディスク６５４に記憶されてもよい。プログラムは実行の際にＲＡＭ６６０にロードされる。ＣＤ−ＲＯＭ６６２から、ＦＤ６６４から、又はネットワークを介して、直接にＲＡＭ６６０にプログラムをロードしてもよい。
【０１８４】
このプログラムは、コンピュータ６４０をこの実施の形態の情報検索サービスシステム４０又は４００として機能させる複数の命令を含む。この動作を行なわせるのに必要な基本的機能のいくつかはコンピュータ６４０上で動作するオペレーティングシステム（ＯＳ）もしくはサードパーティのプログラム、又はコンピュータ６４０にインストールされる各種ツールキットのモジュールにより提供される。従って、このプログラムはこの実施の形態のシステム及び方法を実現するのに必要な機能全てを必ずしも含まなくてよい。このプログラムは、命令のうち、所望の結果が得られるように制御されたやり方で適切な機能又は「ツール」を呼出すことにより、上記した情報検索サービスシステム４０又は４００としての動作を実行する命令のみを含んでいればよい。
【０１８５】
情報検索サーバコンピュータ６３０は一般的なコンピュータにより実現される。コンピュータ一般の動作は周知であるので、ここではその詳細は繰返さない。
【０１８６】
今回開示された実施の形態は単に例示であって、本発明が上記した実施の形態のみに制限されるわけではない。本発明の範囲は、発明の詳細な説明の記載を参酌した上で、特許請求の範囲の各請求項によって示され、そこに記載された文言と均等の意味及び範囲内での全ての変更を含む。
【符号の説明】
【０１８７】
４０，４００ 情報検索サービスシステム
４２ サービスサイト
４４ 端末
４６，４０２ サイト運営者
４８ サービス利用端末
６０ 音声入力フロントエンド
６２，４０４ オークションシステム
６４ コーパス記憶装置
６６，４０６ 特定サイト検索サービス実行部
６８，４０８ 質問文―ＵＲＬ対照ＤＢ
７０，４１０ マッピングコーパス
７２ 課金処理部
１００ クラスタリング処理部
１０４，４２０ オークション実行部
１０６，オークション実行部 オークションデータＤＢ
１１２，４２４ 更新部
１３０ 質問文解析部
１３２ 質問文検索部
１３４，４３０ ＵＲＬ検索部
１３６，４３２ クエリ生成部
１３８ クエリ発行部
１４０ クエリ結果送信部
１６０ 質問文の集合
１６２ プロトタイプ集合
１７０ 入札者テーブル
１７２ プロトタイプテーブル
１７４ オークションマスタテーブル
１７６ 入札明細テーブル
１７８ 落札情報テーブル
１８０ マッピングコーパステーブル
１９６ 問合処理部
１９８ 入札処理部
２００ 登録情報保守部
２０２ 落札情報表示部
２０４ マッピング管理部
２６０ オークションマスタ更新部
２６２ 落札処理部
２６４ 落札通知処理部
２６６ 運用ＤＢ更新部
４２２ 属性ツリー記憶部
４７０ 属性ツリー
【技術分野】
【０００１】
この発明は、自然言語文の発話から利用者の必要とする情報を検索して提示する情報検索サービスに関し、特に、利用者からの情報の検索要求をいずれかの情報提供サービス業者かに割当てて、当該情報提供サービス業者の提供する情報を直接利用者に提示するサービスに関する。
【背景技術】
【０００２】
いわゆるインターネットには、多くの情報があふれている。しかもその量は日々増え続けている。しかし、いかに有用な情報がインターネット上に存在していても、その情報を的確に見出すことができなければ何の意味もない。そうしたネットワーク利用者の要求に応じる形で登場したのがいわゆる検索サイトである。
【０００３】
検索サイトには大きく分けて２種類がある。第１の種類の検索サイトは、検索サイトの管理者が手作業又は自動的にＵＲＩ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ）を収集し、各ＵＲＩをその内容にしたがって分類したサイトである。利用者は、自分が利用するサイトを検索サイトの分類にしたがって探していくことになる。こうしたサイトでは、分類範囲を限定し、その中で所望の単語又は単語列を検索する仕組みが用意されていることが多い。第２の種類の検索サイトは、予め単語又は単語列に応じたサイトのインデックスを作成しておき、単語又は単語列を指定した検索要求を受けると、インデックスを使用して検索し、検索結果を返すものである。この場合、検索結果にスコアをつけ、スコアの高いサイトから順番に利用者に提示することが一般的である。したがってこの場合には、スコアの付け方が問題となる。スコアの付け方により、検索目的に応じた的確なウェブサイトが提示される可能性が高くなる。
【０００４】
第１の種類の検索サイトでは、自分が探そうとする情報について、少なくともその分類を知っておく必要がある。しかもその分類方式は、検索サイトで利用されているものと一致していなければならない。なおかつ、こうした検索サイトでは、あまり多くのウェブサイトを登録するのは難しいという問題がある。数が増えると、同じ分類したに非常に多数のウェブサイトがリストされることになり、所望のウェブサイトまでたどり着くことが極めて困難となってしまう。こうした検索サイトで、単語又は単語列によりウェブサイトを検索する場合でも、的確な単語の組合せが分からなければ所望の情報が得られない確率が高い。
【０００５】
第２の種類の検索サイトでは、単語又は単語列を検索語として入力するだけで結果が表示されるため、第１の種類の検索サイトに比べると操作が簡単である。しかしこの種の検索サイトでも、自分の所望の情報を的確に得るためには、どの様な単語又は単語列であれば的確な結果が得られるかという知識が重要になる。さもなければ、自分が必要とするものと異なるウェブサイトばかりが表示されることになる。
【０００６】
逆に、情報提供サービスを行なう業者から見ると、自分の提供するサービスが検索結果の上位に表示されなければ、そもそも利用者にサービスを知ってもらうことすらできないという問題がある。そのため、いかにして検索結果の上位にサイトを表示させるか、についての、サービスを提供する技術そのものとは次元の異なる問題に精力を注がなければならないという問題がある。
【０００７】
こうした問題に鑑み、単に利用者からの検索要求に応答するだけでなく、利用者の現在位置情報又は要求サービス内容情報に基づいた検索条件に合致するサービス提供者情報を検索するサービス情報提供装置が提案されている（後掲の特許文献１）。このサービス情報提供装置は、利用者からの要求に基づく情報提供要求を、検索されたサービス提供者に対して行ない、得られたサービス情報を利用者に対して提供する。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】特開２０１０−２８２４１０号公報
【発明の概要】
【発明が解決しようとする課題】
【０００９】
上記特許文献１に開示のサービス情報提供装置によれば、利用者の現在位置に適したサービス情報を利用者に対して提供できるとされている。しかし、このようなサービス情報提供装置では、それ自身のサービスにより利益を得ることができないという問題がある。これに限らず、インターネット上で提供されるサービスではほとんど常に、どのようにして自己の提供するサービスをビジネスに結びつけるかが問題となっている。結局、検索結果又は情報提供の画面上に広告を提示し、広告料を得るという結果になることが多い。
【００１０】
しかし、このように広告のみに頼るサービスは、ビジネスモデルとして好ましくない。サービスそのものの価値をビジネスに結びつける仕組みが求められている。
【００１１】
一方、もとのサービス提供者の立場から言うと、上記したようなサービス情報提供システムにおいては、自己の提供するサービスが、数多くのサービスの１つにすぎないという問題がある。すなわち、いずれのサービス提供者にとっても、潜在的な利用者を高い確率で自己のサービスに誘導することができないという問題がある。サービス提供者から見れば、特定の条件を満足するある種の情報提供要求に限定して、自分のサービスを検索結果として利用者に提示するような仕組みが求められている。
【００１２】
しかし従来は、そのような仕組みはなく、サービス情報提供者にとっても、サービス提供者にとっても、インターネットを利用したビジネスとしては運営が不透明だという問題があった。
【００１３】
それゆえに本発明の１つの目的は、インターネット上のサービスに関する検索要求に対する情報検索サービスを運営するにあたり、そうしたサービス自体をビジネス上の利益に結びつけることができる情報検索サービス提供装置を提供することである。
【００１４】
本発明の他の目的は、インターネット上のサービスに関する検索要求に対する情報検索サービスを運営するにあたり、特定の条件を充足する検索要求について、特定のサービス提供者のサービスを独占的に返信する仕組みを採用し、そのような仕組みをビジネスとして確立できる情報検索サービス提供装置を提供することである。
【課題を解決するための手段】
【００１５】
本発明の第１の局面に係る情報検索サービス提供装置は、機械可読な複数個の文を記憶する、機械可読な記憶手段と、記憶手段に記憶された複数個の文を、文の間に定義される距離に基づいて複数個のクラスタに分類し、各クラスタを代表する代表文を定める代表文決定手段と、代表文の各々についてオークションをオンラインで行なうことにより、代表文の落札者を決定するオークション実行手段と、複数個の文の各々に、当該文が属するクラスタの代表文の落札価格及び落札者を関係付ける価格付与手段と、複数個の文の各々について、当該文に関係付けられた落札者により指定されるＵＲＩを記憶するＵＲＩ記憶手段と、情報の検索要求文をオンラインで受信したことに応答して、記憶手段に記憶された複数個の文の中で、当該検索要求文との間の距離が最も小さな文を検索する文検索手段と、文検索手段により検索された文に対応してＵＲＩ記憶手段に記憶されたＵＲＩに、検索要求文から生成したクエリを送信することにより、当該ＵＲＩから得られる情報を検索要求文を送信した端末に送信する情報送信手段とを含む。
【００１６】
好ましくは、代表文決定手段及び文検索手段において行なわれる距離の計算は同じ計算方法による。
【００１７】
より好ましくは、情報送信手段は、ＵＲＩ記憶手段に記憶されたＵＲＩの各々について、当該ＵＲＩに送信するクエリを生成するための、単語又は単語列のマッピングルールを記憶するマッピングルール記憶手段と、文検索手段が受信した情報の検索要求文に対する構文解析を行なって各単語に属性を付与し、属性付検索要求文を出力する構文解析手段と、文検索手段により検索された文と、当該文と関連付けられたＵＲＩに対応してマッピングルール記憶手段に記憶されたマッピングルールとに基づいてクエリを生成し、文検索手段により検索された文に対応してＵＲＩ記憶手段に記憶されたＵＲＩに送信するクエリ送信手段と、クエリ送信手段により送信されたクエリに対する返信を検索要求文を送信した端末に転送する情報転送手段とを含む。
【００１８】
さらに好ましくは、代表文の各々は、属性が付与されたキーワードを含む。オークション実行手段は、属性の種類毎に、属性の値の包含関係を規定する関係情報を記憶する包含関係記憶手段と、代表文の各々について、当該代表文に含まれるキーワードの属性ごとに、その属性の値を指定した入札を入札者から受ける入札手段と、入札手段により属性の値を指定して行なわれる入札について、包含関係記憶手段に記憶された包含関係と、入札された価格とにしたがって、互いに排他的な落札範囲を指定して、各代表文の落札者を決定する落札者決定手段とを含む。
【００１９】
落札者決定手段は、同じ代表文に対し、同じキーワードの属性について異なる値を指定して行なわれた複数個の入札について、指定された属性の値によりそれぞれ定まる範囲の間の包含関係を、包含関係記憶手段にその属性について記憶された包含関係に基づいて判定する包含関係判定手段と、包含関係判定手段による包含関係の判定結果にしたがって、代表文に対して属性により指定される落札範囲を決定し、各落札範囲について、該当する属性の値を指定した入札の単価により落札者を決定する手段とを含む。
【００２０】
本発明の第２の局面に係るコンピュータプログラムは、機械可読な複数個の文を記憶する、機械可読な記憶手段に接続されるコンピュータを、記憶手段に記憶された複数個の文を、文の間に定義される距離に基づいて複数個のクラスタに分類し、各クラスタを代表する代表文を定める代表文決定手段と、代表文の各々についてオークションをオンラインで行なうことにより、代表文の落札者を決定するオークション実行手段と、複数個の文の各々に、当該文が属するクラスタの代表文の落札価格及び落札者を関係付ける価格付与手段と、複数個の文の各々について、当該文に関係付けられた落札者により指定されるＵＲＩを記憶手段に記憶させるＵＲＩ記憶手段と、情報の検索要求文をオンラインで受信したことに応答して、記憶手段に記憶された複数個の文の中で、当該検索要求文との間の距離が最も近い文を検索する文検索手段と、文検索手段により検索された文に対応してＵＲＩ記憶手段に記憶されたＵＲＩに、検索要求文から生成したクエリを送信することにより、当該ＵＲＩから得られる情報を検索要求文を送信した端末に送信する情報送信手段として機能させる。
【図面の簡単な説明】
【００２１】
【図１】本発明の１実施の形態に係る情報提供システムの全体構成を示すブロック図である。
【図２】図１に示す情報提供システムで採用される、情報検索サービスシステムのブロック図である。
【図３】第１の実施の形態において、情報検索に使用する自然言語文からどのようにプロトタイプ文を選択するかを説明するための図である。
【図４】図１に示す情報提供システムのオークション実行部及びオークションデータＤＢのより詳しい攻勢を示すブロック図である。
【図５】オークションデータＤＢの主要なテーブルのレコード構成を模式的に示す図である。
【図６】図２に示す情報提供システムにより提供される、質問文のオークションに入札するために端末に表示される画面の模式図である。
【図７】図２に示すオークションデータＤＢと更新部との構成をより詳細に示す図である。
【図８】入札処理を行なう端末に表示される画面の遷移を示す状態遷移図である。
【図９】第１の実施の形態に係る情報検索サービスシステムで、オークションの落札時に実行される、オークション落札プログラムの制御構造を示すフローチャートである。
【図１０】第１の実施の形態に係る情報検索サービスシステムで、情報検索要求を受けたときに実行されるプログラムの制御構造を示すフローチャートである。
【図１１】本発明の第２の実施の形態に係る情報検索サービスシステムの概略構成を示すブロック図である。
【図１２】第２の実施の形態におけるオークションデータＤＢのプロトタイプテーブルと入札明細テーブルとのレコード構成を模式的に示す図である。
【図１３】第２の実施の形態に係る情報検索サービスシステムにおいて、質問文を入札しようとする端末に表示される入札初期画面を模式的に示す図である。
【図１４】第２の実施の形態に係る情報検索サービスシステムにおいて、質問文を入札しようとする端末に表示される入札明細画面を模式的に示す図である。
【図１５】第２の実施の形態に係る情報検索サービスシステムにおいて、質問文を入札しようとする端末に表示される入札入力画面を模式的に示す図である。
【図１６】第２の実施の形態に係る情報検索サービスシステムにおいて、質問文を入札しようとする端末に表示される入札明細追加画面を模式的に示す図である。
【図１７】第２の実施の形態に係る情報検索サービスシステムにおいて、端末に、入札処理後に表示される入札明細画面を模式的に示す図である。
【図１８】第２の実施の形態に係る情報検索サービスシステムにおいて、入札処理を行なったサービス提供者の端末に、入札処理後に表示される入札明細画面を模式的に示す図である。
【図１９】第２の実施の形態に係る情報検索サービスシステムにおいて使用される、属性ツリーの一例の構成を示す図である。
【図２０】第２の実施の形態に係る情報検索サービスシステムのウェブサーバにおいて、入札に関する問合せに応答して実行されるプログラムの制御構造を示すフローチャートである。
【図２１】第２の実施の形態に係る情報検索サービスシステムのウェブサーバにおいて、入札に関する入力に応答して実行されるプログラムの制御構造を示すフローチャートである。
【図２２】図２１に示すプログラムの一部である、明細のチェックのためのプログラムルーチンの制御構造を示すフローチャートである。
【図２３】第２の実施の形態に係る情報検索サービスシステムにおいて、オークションの落札時に実行されるオークション落札プログラムの制御構造を示すフローチャートである。
【図２４】第２の実施の形態に係る情報検索サービスシステムにおいて、情報検索要求を受けたときに実行されるプログラムの制御構造を示すフローチャートである。
【図２５】第３の実施の形態に係る情報検索サービスシステムにおいて、質問文を入札しようとする端末に表示される入札初期画面を模式的に示す図である。
【図２６】第３の実施の形態に係る情報検索サービスシステムにおいて、質問文を入札しようとする端末に表示される入札明細画面を模式的に示す図である。
【図２７】第３の実施の形態に係る情報検索サービスシステムにおいて、質問文を入力しようとする端末に表示される入札入力画面を模式的に示す図である。
【図２８】第３の実施の形態に係る情報検索サービスシステムにおいて、質問文を入力しようとする端末に表示される、対象範囲の入力画面を模式的に示す図である。
【図２９】第３の実施の形態に係る情報検索サービスシステムにおいて、入札処理を行なったサービス提供者の端末に、入札処理後に表示される入札明細画面を模式的に示す図である。
【図３０】本発明の実施の形態に係る情報検索サービスシステムを実現するコンピュータシステムの外観を示す図である。
【図３１】図３０に外観を示すコンピュータシステムのハードウェア構成を示すブロック図である。
【発明を実施するための形態】
【００２２】
以下の説明及び図面では、同一の部品には同一の参照番号を付してある。したがって、それらについての詳細な説明は繰返さない。
【００２３】
［第１の実施の形態］
第１の実施の形態に係る情報検索サービスシステムは、多数の自然言語文をクラスタリングして一定数のプロトタイプ文を定め、これらプロトタイプ文に対してサービス提供者がオークションにより入札するシステムである。予め自然言語文がクラスタリングされているので、入札により、自然言語文の各々をサービス提供者と対応付けることができる。検索要求を受けると、その検索要求が自然言語文のいずれに最も近いかを判定し、その自然言語文と対応付けられているサービス提供者の運営する情報提供サイトに検索要求を送信する。この検索要求に対してその情報提供サイトから返信されてくる情報を、もともとの検索要求の発信者の端末に送信する。
【００２４】
一方では、情報検索サービスの提供者は、プロトタイプ文のオークションにより、システムを運営するための資金を得ることができる。さらに、検索１回について所定の検索ヒット料金が得られるので、安定したビジネスとして情報検索サービスを運営できる。
【００２５】
他方、サービスの提供者は、プロトタイプ文を落札すると、そのプロトタイプ文に類似した検索要求については独占できる。通常の検索サービスにリストされる場合のように、多数の検索結果の中に埋もれてしまうことがなく、利用者を効率よく自己のサービス提供サイトに案内することができる。
【００２６】
〈構成〉
〔全体構成〕
図１を参照して、本発明の第１の実施の形態に係るシステム３０は、サービスを利用する利用者の端末４４と、各々がサービスサイト４２を運営する複数のサイト運営者４６と、インターネットを通じて端末４４、複数のサイト運営者４６、並びにこれらサイト運営者４６の運営するサービスサイト４２の各々と通信可能で、予め複数の自然言語文のコーパスをクラスタリングして得られたプロトタイプ文をサイト運営者４６によるオークションにかけ、端末４４から受けた検索要求について、オークション結果に従って選択したサービスサイトにクエリを生成して送信し、得られたサービス情報を端末４４に返送する処理を実行する情報検索サービスシステム４０とを含む。本実施の形態では、端末４４からの検索要求３２は音声で行なわれる。サービスサイトへのクエリ３４はテキスト情報であり、サービスサイトから情報検索サービスシステム４０を経て端末４４に送信されるサービス情報３６は、応答するサービスサイトに依存する。
【００２７】
情報検索サービスシステム４０は、大きく分けると、端末４４から音声で与えられる検索要求３２に対して音声認識処理を実行し、情報検索要求文を生成する音声入力フロントエンド６０と、予め収集されていた多数の自然言語文をクラスタリングし、各クラスタを代表するプロトタイプ文を複数のサイト運営者４６の間のオークションにかけておき、情報検索要求に対してオークション結果にしたがった適切なサービスサイトを決定するために必要なデータベースを構築するためのオークションシステム６２と、音声入力フロントエンド６０の出力する検索要求に基づき、オークションシステム６２により構築されたデータベースを用いてオークション結果に従って適切に選択したサービスサイトにクエリ３４を送信し、当該サービスサイトから返信されてくるサービス情報３６を端末４４に転送する処理を行なう特定サイト検索サービス実行部６６とを含む。
【００２８】
〔情報検索サービスシステム４０の構成〕
図２を参照して、情報検索サービスシステム４０は、前述したように、端末４４からの音声による検索要求に対して音声認識を行ない、テキストベースの検索要求を生成する音声入力フロントエンド６０と、予め多数の自然言語による質問文からなる質問文コーパスを、機械可読な形式で記憶するコーパス記憶装置６４と、質問文コーパスに記憶された質問文をクラスタリングして各クラスタを代表するプロトタイプ文を決定した後、各プロトタイプ文について複数のサイト運営者４６の間でオークションを行なった結果にしたがって各質問文に対応するサービスサイトを決定し、情報検索に必要なデータを生成するオークションシステム６２とを含む。すなわち本実施の形態では、多数の質問文の各々についてオークションを行なうかわりに、それらをクラスタリングし、各クラスタを代表する質問文についてオークションを行なう。
【００２９】
オークションシステム６２により生成されるデータは、質問文とその質問文の落札者が運営するサイトのＵＲＩの１例であるＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）とを対にして記憶する質問文―ＵＲＬ対照ＤＢ６８と、入力された検索要求と、その検索要求に基づいて、質問文―ＵＲＬ対照ＤＢ６８を参照して決定されたＵＲＬに対するクエリ文を生成するためのマッピングを記憶するマッピングコーパス７０とを含む。質問文―ＵＲＬ対照ＤＢ６８及びマッピングコーパス７０はいずれも記憶装置と一般的なデータベースプログラムとからなるデータベースにより実現される。
【００３０】
質問文―ＵＲＬ対照ＤＢ６８に格納される情報は、コーパス記憶装置６４に記憶された質問文の各々と、落札者の運営するＵＲＬとの対応関係である。
【００３１】
マッピングコーパス７０に記憶されるのは、検索要求に含まれる単語から、その検索要求に対応して決定されたＵＲＬに対するクエリを生成する際の、単語に対するマッピングルールである。より具体的には、マッピングルールは、例えば予め「＜地名＞京都＜／地名＞の＜食品名＞和食＜／食品名＞の＜店名＞レストラン＜／店名＞を知りたい。」というように、タグとキーワードとを含むクエリのテンプレートである。検索要求を形態素解析し、得られた形態素列の属性を得る。テンプレート中の各タグに囲まれている部分のキーワードを、そのタグと一致する、又は類似する属性の形態素の文字列で置換する。これを全てのタグについて行なうことにより、クエリが得られる。このマッピングルールは、入札者が入札時から落札時までの間に準備しておく。落札者が決定した時点で、落札された質問文に対するマッピングルールがマッピングコーパス７０に格納される。
【００３２】
なお、上記したマッピングルールの例のうち、「京都」、「和食」など、タグで囲まれた部分のキーワードは、クエリ生成の際に検索要求から得られた単語の文字列で置換される箇所を明示するためのものであるが、そのためだけのものではない。すなわち、これらキーワードは、検索要求から得られた単語をどのキーワードと置換するかを決定する際の情報の一種としても使用される。形態素解析で得られた属性だけでなく、単語間の意味的距離をも用いてキーワードと形態素とを関係付けることにより、クエリがより高い精度で生成できる。
【００３３】
情報検索サービスシステム４０はさらに、音声入力フロントエンド６０の出力する検索要求から、コーパス記憶装置６４に記憶された質問文コーパス、質問文―ＵＲＬ対照ＤＢ６８、及びマッピングコーパス７０に記憶されたマッピングルールを用いて、その質問文が属するクラスタのプロトタイプ文の落札者の運営するサイトに対し、その質問文から生成されたクエリを送信し、得られた情報を、検索要求送信者のサービス利用端末４８（多くの場合、端末４４と一致する。）に対して送信する処理を行なう特定サイト検索サービス実行部６６と、特定サイト検索サービス実行部６６の実行したクエリの結果を検索ログとして記憶し、この検索ログと、オークションシステム６２によるオークションの結果（質問文の落札単価）とを用いてオークション落札者に対する請求処理を行なうための課金処理部７２とを含む。
【００３４】
音声入力フロントエンド６０は、端末４４においてコードブックを用いてコード化され送信された音声信号をオンラインで受信し、コードブックを用いて音声データを復元するコード受信部８０と、コード受信部８０により復元された音声データ化から、音声認識のために必要な特徴量を算出する特徴量算出部８２と、特徴量算出部８２により算出された特徴量を用いて音声認識を行ない、認識結果のテキストデータを認識結果として出力する音声認識装置８４とを含む。特徴量算出部８２が復元する特徴量は、音声認識装置８４の仕様により決定されるが、例えば所定フレーム庁及び所定シフト長のフレーム毎に算出されるＭＦＣＣ，ΔＭＦＣＣ，パワーなどである。本実施の形態では、情報検索サービスシステム４０を利用するのは、特定のものだけでなく、一般的な利用者であることが想定されている。したがって音声認識装置８４は、一般的な話者の音声認識が可能である必要がある。もちろん、利用者が特定の集団に限定されていることが分かっているならば、たとえば話者同定の仕組みを音声認識装置８４の前段に加え、音声認識装置８４ではその話者の音声の音声認識に適した音響モデルを利用するようにしてもよい。
【００３５】
オークションシステム６２は、コーパス記憶装置６４に記憶された質問文コーパスを構成する多数の質問文をクラスタリングし、クラスタごとに、その中心となるプロトタイプ文を、クラスタ番号とともに出力するクラスタリング処理部１００と、クラスタリング処理部１００から出力されるプロトタイプ文とクラスタ番号とを記憶するプロトタイプ記憶部１０２とを含む。なお、クラスタリング処理部１００は、クラスタリング時に、コーパス記憶装置６４に記憶された各質問文に、その質問文が属するクラスタ番号を付す処理も実行する。
【００３６】
オークションシステム６２はさらに、プロトタイプ記憶部１０２に記憶されたプロトタイプ文の各々を複数のサイト運営者４６によるオンラインのオークションにかける処理を実行するオークション実行部１０４と、システムの運用時刻を管理するためのタイマ１１０と、タイマ１１０から得られる時刻情報に基づき、オークション実行部１０４により実行されるオークションの開始及び終了と、オークション結果を用いた特定サイト検索サービス実行部６６による特定サイト検索サービスの運営とを管理するためのオークション管理部１０８と、オークション実行部１０４がオークションを実行するために必要なデータを記憶するオークションデータＤＢ１０６とを含む。
【００３７】
オークションシステム６２はさらに、オークションデータＤＢ１０６、オークション管理部１０８、質問文―ＵＲＬ対照ＤＢ６８、マッピングコーパス７０、及び課金処理部７２に接続され、オークション実行部１０４により実行されるオークションの終了日時に到達すると、オークション管理部１０８の管理の下、オークションデータＤＢ１０６に記憶された情報に基づいて、各プロトタイプ文の落札者と落札価格とを決定し、その結果にしたがって質問文―ＵＲＬ対照ＤＢ６８、マッピングコーパス７０、及び課金処理部７２による請求先の情報を更新する更新部１１２を含む。質問文─ＵＲＬ対照ＤＢ６８は、各質問文について、その質問文が属するクラスタの代表文を落札した落札者の運営するサイトのＵＲＬ（後述する入札者テーブルに記録されている。）と、その質問文とを関係付ける情報を記憶するためのものである。なお、オークションの落札日時と、落札結果を用いたオークションの開始日時とは通常一致しない。オークション終了後、例えば２週間後からその結果を用いた特定サイト検索サービスが開始される。したがって、更新部１１２による質問文―ＵＲＬ対照ＤＢ６８、マッピングコーパス７０及び課金処理部７２の更新結果は直ちに特定サイト検索サービスに反映されるわけではない。更新部１１２による更新は、新たなデータを作成することであり、特定サイト検索サービスの開始日時に、それらが以前のデータを置換することになる。図及び説明を簡単にするため、図面にはこうした更新と実際の運用開始との間の時間的ズレを管理するための機構は示していない。
【００３８】
特定サイト検索サービス実行部６６は、音声認識装置８４の出力する検索要求に対する形態素解析、意味辞書による意味タグの付与、及び構文解析などを行ない、意味タグ、品詞タグなどの属性がそれぞれ付された形態素列を出力する質問文解析部１３０と、これら形態素列により表される検索要求との間の距離が最も小さな質問文をコーパス記憶装置６４に記憶された質問文コーパスの中で検索し取出し、その属するクラスタ番号を解析後の検索要求とともに出力するための質問文検索部１３２とを含む。この検索では、例えば品詞、文中での出現箇所、係り受け関係、品詞などを全て考慮して、正規化された質問文特徴ベクトルを作成し、特徴ベクトル間の内積の値が最も大きな質問文を選択する、などの方法を用いればよい。本実施の形態では、質問文のクラスタリングの際に用いられた距離計算の方法と、質問文検索部１３２により用いられる距離計算の方法とは、同じ方法であるものとする。
【００３９】
特定サイト検索サービス実行部６６はさらに、質問文検索部１３２により選択された質問文のクラスタ番号に基づき、その質問文を落札したサイト運営者のサービスサイトのＵＲＬを質問文―ＵＲＬ対照ＤＢ６８において検索し、解析後の検索要求とともに出力するためのＵＲＬ検索部１３４と、ＵＲＬ検索部１３４から出力されるＵＲＬ及び解析後の検索要求、並びにマッピングコーパス７０にそのＵＲＬに対応して記憶されているマッピングルールに基づいて、クエリを生成し、ＵＲＬとともに出力するためのクエリ生成部１３６と、クエリ生成部１３６により出力されたクエリと、クエリ生成部１３６により出力されたＵＲＬとから、情報検索のためのＵＲＬ文を生成してインターネット上に送信するクエリ発行部１３８と、クエリ発行部１３８が送信したクエリに応答して、サービスサイト４２から送信されてきた情報をサービス利用端末４８に転送し、同時に検索ログを課金処理部７２に対して出力するためのクエリ結果送信部１４０とを含む。
【００４０】
課金処理部７２は、クエリ結果送信部１４０から出力される検索ログを蓄積するための検索ログ記憶部１５０と、検索ログ記憶部１５０に記憶された検索ログを定期的に読出し、検索対象となったサイトの検索回数にオークション結果にしたがった単価を乗じた金額を、各サイトの運営者（オークション落札者５０）に請求する処理を実行するための請求処理部１５２とを含む。
【００４１】
図３を参照して、クラスタリング処理部１００が実行するクラスタリング処理の概念について説明する。コーパス記憶装置６４には、主としてインターネット上から収集された多数の質問文が記憶されている。本実施の形態に係る情報検索サービスシステム４０では、音声で与えられる検索要求の各々について、これら質問文の内で最も近い距離にあるものを特定し、その質問文について予め落札していたサイト運営者のサイトにその検索要求を送信する。したがって、準備処理として、各質問文についてオークションで１検索あたりの単価を定めて、その質問文に近い検索要求が発生したときには、オークションでのその質問文の落札者の運営するサイトにその検索要求を転送する。そのような検索が発生するたびに、その質問文に付けられていた単価にしたがった料金をいわば広告料と同様にして情報検索サービスシステム４０の運営者が落札者から受取る。これが情報検索サービスシステム４０を運営していくための資金となる。
【００４２】
ただし、質問文は大量である上、時々刻々と増加する。したがって、それら質問文の各々についてオークションを行なうのは現実的ではない。そこで本実施の形態では、それら多数の質問文を予め複数のクラスタに分類する。クラスタリングの手法として使用される手法は、特に特定のものに限定されるわけではない。各質問文が必ず１つのクラスタに、かつ１つのクラスタのみに属するような手法であればどのようなものでもよい。しかし、本実施の形態では、検索要求に対して最も小さな距離にあるプロトタイプを特定する必要があるため、質問文の間の距離に相当する評価関数を何らかの形で定義し、その距離を基準に質問文をクラスタリングする手法を用いることが望ましい。なお、クラスタ数は、クラスタごとにオークションにかける関係上、予め固定されていることが望ましい。もちろん、クラスタ数が固定されていなければならないわけではなく、オークションごとに変化してもよい。要するに、情報検索サービスシステム４０の運営上で都合のよい数をクラスタの数として選択すればよい。
【００４３】
図３を参照して、これら多数の質問文の集合１６０を、１点鎖線で示されるように複数のクラスタに分割する。通常のクラスタリング手法を用いると、各クラスタについてそのセントロイド（重心）が決定される。本実施の形態では、各クラスタのセントロイドに最も近い質問文をそのクラスタのプロトタイプとし、このプロトタイプ文でそのクラスタに属する全質問文を代表させる。図２に示すクラスタリング処理部１００は、このようにしてプロトタイプを決定してプロトタイプ集合１６２を形成し、プロトタイプ記憶部１０２に記憶させる機能を持つ。各質問文には、どのクラスタに属するかを示す情報が付される。
【００４４】
図４を参照して、オークション実行部１０４は、サイトの運営者の端末からのｈｔｔｐリクエストを処理するウェブサーバ１９０と、ウェブサーバ１９０と連携し、ウェブサーバ１９０が受信したｈｔｔｐリクエストのうち、オークションに関係するリクエストについて、当該リクエストにより決定されるプログラムを読出して実行する、プログラムの実行処理系からなる実行処理部１９２とを含む。実行処理部１９２は、ＣＰＵなどの図示しないコンピュータハードウェアが、実行処理系のプログラムを実行することにより実現される。
【００４５】
オークション実行部１０４はさらに、実行処理部１９２によりｈｔｔｐリクエスト内のプログラム指定にしたがって呼出されて実行され、オークションデータＤＢ１０６内の各種のテーブルを更新したり、各テーブルからデータを読出したりして、処理結果を実行処理部１９２及びウェブサーバ１９０を介してｈｔｔｐリクエストの送信元に返信する、ログオン処理部１９４、問合処理部１９６、入札処理部１９８、登録情報保守部２００、落札情報表示部２０２、及びマッピング管理部２０４とを含む。これらの機能については後述する。
【００４６】
ウェブサーバ１９０は、サイト管理者の端末から送信されてくるｈｔｔｐリクエストを受信するためのリクエスト受信部２１０と、リクエスト受信部２１０が受信したｈｔｔｐリクエストのＵＲＬに含まれる情報を解析することにより、ログオン処理部１９４、問合処理部１９６、入札処理部１９８、登録情報保守部２００、落札情報表示部２０２及びマッピング管理部２０４のいずれを起動すべきかを決定し、実行処理部１９２にその情報を与えるための実行系呼出部２１２と、ｈｔｔｐリクエストを処理した後、ログオン処理部１９４などから送信されてくる処理結果のｈｔｍｌ書類からなるレスポンスをサイト運営者の端末に送信するレスポンス送信部２１４とを含む。
【００４７】
オークションデータＤＢ１０６は、入札者の基本的情報を記憶する入札者テーブル１７０、プロトタイプに関する情報を記憶するプロトタイプテーブル１７２、主として進行中のオークションを管理するための基本的情報を記憶するオークションマスタテーブル１７４、入札の明細を記憶する入札明細テーブル１７６、オークションの落札に関連する情報を記憶する落札情報テーブル１７８、及び、各入札者が、自己の入札したプロトタイプに関連して予め作成するマッピングルールを記憶するマッピングコーパステーブル１８０を含む。
【００４８】
図５を参照して、例えば入札者テーブル１７０のレコード２５０は、このサービスに対する入札を行なう可能性のあるサイト運営者を一意に識別するように割当てられる入札者ＩＤと、入札者の氏名又は名称と、入札者の住所と、入札者の管理するサービスサイトのＵＲＬ及びそのサービス名と、請求関係の情報（締日、請求書の宛先等）と、ログオンのためのパスワードと、落札結果などの連絡の際に用いられる電子メールアドレスとを含む。サイト運営者からログオン要求があった場合、入札者テーブル１７０の入札者ＩＤ及びパスワードによりサイト運営者のログオン情報を認証することができる。なお、図５に示す以外に、例えばサイト運営者の運営責任者、電話番号、ファクシミリ番号などを記録するようにしても良いが、本実施の形態ではそれらに関する情報を使用しないため、図５及び以後の説明ではそれらについては言及しない。
【００４９】
プロトタイプテーブル１７２のレコード２５２は、各プロトタイプに対し一意に割当てられるプロトタイプＩＤと、そのプロトタイプＩＤに対応する質問文の、質問文コーパス内におけるＩＤ（質問文ＩＤ）と、そのプロトタイプにより代表されるクラスタに含まれる質問文数と、当該クラスタに属する質問文のリストの先頭及び最後尾へのポインタからなるクラスタ文リストと、このプロトタイプが落札されたか否かを示す入札完了フラグとを含む。
【００５０】
オークションマスタテーブル１７４のレコード２５４は、各オークションに対して一意に割当てられるオークションＩＤと、オークションのウェブサイトに表示されるオークション名称と、オークションの開始時期及び終了時期と、当該オークションに基づく特定サイト検索サービスの運用開始時期及び終了時期と、このレコードに対応するオークションの入札が完了したか否かを示すオークション完了フラグと、このオークションの結果に基づく特定サイト運用サービスの運用が終了したか否かを示す運用完了フラグと、このオークションが有効か否か（現在運用されているか否か）を示す運用開始フラグとを含む。オークションの開始時期及び終了時期は、各プロトタイプに対するサイト運営者の入札許可期間の開始時期及び終了時期をそれぞれ示す。オークション完了フラグがオンの場合、このオークションの各プロトタイプが落札され、運用の準備ができたことを示す。運用完了フラグがオンの場合、このオークションの結果を用いた特定検索サービスの運用が終了したことを示す。運用完了フラグがオフの場合、このオークションの結果を用いたサービスの運用がまだ完了していないことを示す。運用開始フラグがオンのときは、このレコードにより示されるオークションの落札結果にしたがって、特定検索サービスが運用されていることを示す。仮に運用開始フラグがオフであれば、現在日時が運用開始時期及び運用終了時期の間であっても、このレコードに対応するオークションの落札結果にしたがった特定サイト検索サービスは運用されない。
【００５１】
入札明細テーブル１７６のレコード２５６は、関係するオークションのオークションＩＤと、入札対象のプロトタイプのプロトタイプＩＤと、入札日時と、入札者ＩＤと、入札単価と、落札フラグとを含む。落札フラグは、レコードが作成されるときにオフに初期化される。
【００５２】
再び図４を参照して、ログオン処理部１９４は、入札者テーブル１７０を参照して、サイト運営者がこのオークションシステムにログオンしてよいか否か、いつログオフしたか、などを管理する。ログオン処理部１９４による処理は、有料、無料を問わずユーザ登録が必要なシステムで行なわれている処理と同様である。
【００５３】
問合処理部１９６は、このオークションシステムにログオンしているサイト運営者から、進行中のオークションに関する問合せがあったことに応答して、プロトタイプテーブル１７２、オークションマスタテーブル１７４及び入札明細テーブル１７６を参照し、問合せがあった情報を示すｈｔｍｌ処理を作成して実行処理部１９２に与える処理を実行するためのものである。問合処理部１９６の処理も、データの内容に相違はあるものの、データベースを参照してダイナミックにｈｔｍｌ処理を作成するウェブサーバで通常実行されているものと同様の手法を用いて実現できる。
【００５４】
入札処理部１９８は、サイト運用者から、特定のプロトタイプを指定して入札の入力があったときに、その内容が正しいか否かを検査し、正しいときのみ入札明細テーブル１７６に入札明細レコードを新たに作成する処理を行なう。入札の入力が正しくないときには入力を拒否する。実際には、後述するように、入札処理は問合処理部１９６による問合せの後に行なわれる。問合処理部１９６が作成するｈｔｍｌ書類中に、入札データの整合性を保証するようなスクリプトを記述しておくことにより、入札処理部１９８が受取る入札データは基本的に正当なものであることが想定される。
【００５５】
図６に、問合処理部１９６により表示される入札初期画面２３０の例を示す。図６に示す画面は、サイト運営者がこのシステムにログオンした後、オークションを指定して問合処理を開始させることにより、問合処理部１９６により作成され、サイト運営者の端末のブラウザに表示される。
【００５６】
図６を参照して、質問文入札の初期画面では、プロトタイプ文がＩＤ順に表示される。既に入札があったプロトタイプ文については、「最高値」の欄に入札の最高値が表示される。特定のプロトタイプ文に対する入札を行なう場合、サイト運営者は「ビッドする」という見出しの欄に表示されるチェックボックスのうち、入札しようとするプロトタイプ文の行のチェックボックスにチェックを入れ、入札単価を入力する。プロトタイプ文の内容、プロトタイプ文により代表されるクラスタに含まれる質問文の数などを知りたいときには、「詳細」ボタン２４０を押すと、新たなウィンドウ又はタブにそのプロトタイプ文により代表されるクラスタの詳細がプロトタイプテーブル１７２の該当レコードに基づいて表示される。
【００５７】
図６の入札初期画面２３０の最も下部に表示されている「戻る」ボタンを押すと、オークション選択の画面が表示される。「入札する」ボタンを押すと、ユーザの入力が入札処理部１９８に送信され、チェックされる。チェックの結果、入力が正当であれば入札明細テーブル１７６に入力明細が追加される。チェックの結果、入力が正当でないときにはエラーメッセージと共に図６と同様の画面が再度表示される。この場合、誤りとなった箇所が例えば反転して、又は赤いフォントで、表示される。本実施の形態では、誤りがあった場合には、入力のいずれについても入札明細テーブル１７６への追加は行なわれない。
【００５８】
登録情報保守部２００は、入札者テーブル１７０に記憶されているサイト運営者の情報を保守するためのものである。サイト運営者は、当然のことながら自分に関する情報しか保守することができない。登録情報保守部２００の機能も、既存のシステムで通常実現されているものと同様である。
【００５９】
落札情報表示部２０２は、既に落札が完了したオークションの内容についての問合せを処理するためのものである。本実施の形態では、落札情報表示部２０２は発明の本質的部分とは無関係なので、その詳細についてはここでは説明しない。
【００６０】
マッピング管理部２０４は、入札者が、自分の入札したプロトタイプを処理するためのマッピングルールを入力したり、保守したりするためのものである。その処理内容は通常のデータベースのレコードの保守と同様であり、保守の対象がマッピングルールである点のみが異なる。したがってここではマッピング管理部２０４の詳細については説明しない。
【００６１】
オークション管理部１０８は、タイマ１１０の出力に応答して、定期的にオークションデータＤＢ１０６のオークションマスタテーブル１７４をチェックしており、オークション開始時期に到達したオークションであって、オークション開始フラグがオフのものがあれば、そのオークションＩＤを指定して、更新部１１２に対し、当該オークションを開始させる指示を出す。オークション管理部１０８はまた、同様にして、運用開始時期に到達したオークションであって、運用開始フラグがオフのものがあれば、そのオークションＩＤを指定して、更新部１１２に対し特定サイト検索サービスの切替を指示する機能を持つ。
【００６２】
図７を参照して、更新部１１２の構成について説明する。更新部１１２は、図２に示すオークション管理部１０８から特定のオークションを完了する指示を受けたことに応答して、指定されたオークションＩＤを持ち、オークション完了フラグがオン、運用開始フラグがオフ、運用完了フラグがオフ、かつ現在時刻が運用開始時期と運用終了時期との間にあるレコードの運用開始フラグをオンに更新するオークションマスタ更新部２６０と、オークション管理部１０８から特定のオークションを完了させる指示を受けたことに応答して、入札明細テーブル１７６を検査し、各プロトタイプに対する落札者を決定する処理と、指定されたオークションの各プロトタイプの落札者が決定されたときに、オークションマスタテーブル１７４内の、指定されたオークションに対応するレコードのオークション完了フラグをオンに更新する処理と、落札結果を落札情報テーブル１７８に出力する処理とを実行する落札処理部２６２とを含む。
【００６３】
オークションデータＤＢ１０６はさらに、落札処理部２６２による落札処理が完了したことに応答して、入札者テーブル１７０、オークションマスタテーブル１７４、及び落札情報テーブル１７８にそれぞれ記憶された情報に基づいて、各プロトタイプの落札者に対し落札結果を通知する落札通知処理部２６４と、オークション管理部１０８から、オークションＩＤを指定して、特定サイト検索サービスの運用を、当該オークションＩＤのオークションの落札結果に基づく運用に切替る指示を受けたことに応答して、質問文―ＵＲＬ対照ＤＢ６８及びマッピングコーパス７０の内容を落札情報テーブル１７８及びマッピングコーパステーブル１８０の内容にしたがって更新する運用ＤＢ更新部２６６とを含む。
【００６４】
運用ＤＢ更新部２６６は具体的には、オークション管理部１０８から運用の切替の指示を受けると、オークションマスタテーブル１７４のうち、運用開始フラグがオン、かつ運用完了フラグがオフのレコードの運用完了フラグをオンに更新する。運用ＤＢ更新部２６６はさらに、オークション管理部１０８により指定されたオークションＩＤを持ち、オークション完了フラグがオン、運用開始フラグがオフ、かつ運用完了フラグもオフであるレコードの運用開始フラグをオンに更新する処理を実行する。運用ＤＢ更新部２６６はこれに加えて、落札情報テーブル１７８に基づいて質問文―ＵＲＬ対照ＤＢ６８を落札結果にあわせて書替え、マッピングコーパステーブル１８０に記録されたマッピングルールの中から、プロトタイプ文ごとに、落札者により準備されていたマッピングルールのみを抽出してマッピングコーパス７０を書き換える。
【００６５】
図８を参照して、本実施の形態に係る情報検索サービスシステム４０によるオークションに参加するサイト運営者の端末画面は、その状態により様々な状態に遷移する。サイト運営者がこのオークションの行なわれているサイトに接続し、ログオンに成功すると、先頭ページ２８０が表示される。図示しないが、先頭ページ２８０では、オークションへの参加と、落札結果の問合せとの２つの選択肢が示される。オークションへの参加が選択されると画面はオークション選択ページ２８２に遷移する。落札結果の問合せが選択されたときにも、画面はオークション選択ページ２９２に遷移する。これらオークション選択ページ２８２及び２９２は、その名称は同じだが、前者が現在開催されているオークションを選択するものであるのに対し、後者は既に落札され、終了しているオークションを選択するものである点が異なっている。
【００６６】
オークション選択ページ２８２では、図示しないが、現在開催されているオークションの一覧が表示される。この画面はオークションマスタテーブル１７４を参照することにより作成できる。この画面では、各オークションの詳細表示の選択肢と、各オークションに含まれるプロトタイプの一覧表示との選択肢が表示される。各オークションの詳細表示が選択されると、画面はオークション詳細情報表示２８４に遷移する。プロトタイプの一覧表示が選択されるとプロトタイプ別入札情報一覧表示画面２８６が表示される。
【００６７】
オークション詳細情報表示２８４では、指定されたオークションＩＤのレコードをオークションマスタテーブル１７４から読出し、その詳細が表示される。この画面で「戻る」ボタンを押すと画面はオークション選択ページ２８２に戻る。
【００６８】
プロトタイプ別入札情報一覧表示画面２８６は、図６に示す入札初期画面２３０のことをいう。図６に示す「詳細」ボタン２４０を押すと、該当するプロトタイプに関する詳細を表示するプロトタイプ別詳細表示画面２８８に表示が遷移する。プロトタイプ別詳細表示画面２８８には、図示しない「戻る」ボタンと「オークション選択ページに戻る」ボタンとが表示される。これらを押すと、表示はプロトタイプ別入札情報一覧表示画面２８６又はオークション選択ページ２８２に遷移する。
【００６９】
図６に示すプロトタイプ別入札情報一覧表示画面２８６で「入札する」ボタンを押すと、前記したように入札内容が入札処理部１９８によりチェックされる。入札内容が正当であれば、入札更新処理２９０が実行され、入札後の情報にしたがってプロトタイプ別入札情報一覧表示画面２８６が更新される。入札内容が正当でなければ、エラーメッセージとともに、入力時のプロトタイプ別入札情報一覧表示画面２８６が再度表示される。
【００７０】
〈プログラム構造〉
─落札処理─
図４に示す各処理部は、既存の技術を転用することにより容易に実現できる。以下、図７に示す落札処理部２６２及び落札通知処理部２６４を実現するプログラムの制御構造を説明する。ここでは、オークションＩＤが指定され、特定のオークションＩＤのデータについて落札処理する場合について説明する。
【００７１】
図９を参照して、この落札処理プログラムは、入札明細テーブル１７６から、指定されたオークションＩＤを持ち、入札完了フラグがオフのプロトタイプ番号ごとに、最高入札単価の入札明細を読出すステップ３１０と、ステップ３１０で読み出された全明細に対し、以下のステップ３１４を繰返すステップ３１２とを含む。
【００７２】
ステップ３１４は、処理対象の入札明細の落札フラグをセットするステップ３４０と、プロトタイプテーブル１７２のうち、その入札明細のプロトタイプＩＤと一致するプロトタイプＩＤを持つレコードの入札完了フラグをセットするステップ３４２とを含む。
【００７３】
このプログラムはさらに、ステップ３１２に続いて実行され、入札明細テーブル１７６から落札フラグがオンの明細を入札者ＩＤ順及びプロトタイプ順で読出すステップ３１６と、落札者に対する落札結果の通知である電子メールを作成し、発送するステップ３１８と、プロトタイプテーブル１７２から、指定されたオークションＩＤを持ち、入札完了フラグがオフのレコードを全て読出すステップ３２０と、ステップ３２０で読み出されたレコードの件数が０か否かを判定し、判定結果にしたがって制御の流れを分岐させるステップ３２２とを含む。
【００７４】
ステップ３２２の判定が肯定の場合、全てのプロトタイプが落札されたということであり、制御はステップ３２４に進む。ステップ３２４では、オークションマスタテーブル１７４の、指定されたオークションＩＤのレコードのオークション完了フラグが１にセットされる。続いてステップ３２６でオークション完了のメッセージをシステム出力に出力して処理を終了する。
【００７５】
ステップ３２２の判定が否定の場合、落札されてないプロトタイプが存在するということである。ステップ３２８でオークション未完のメッセージをシステム出力に出力し、処理を終了する。システム管理者はこの場合、落札されていないプロトタイプのみについて改めてオークションを開催することができる。何度かオークションを行なっても落札されないプロトコルが存在する場合、オークション自体は完了させ、このプロトタイプにより代表されるクラスタ内の質問文に類似する検索要求を受信した場合には、特定のサイトにクエリを発行する処理を行なわず、一般的な検索サイトに検索要求をそのまま転送し、得られた検索結果を検索要求の送信者に返信するような処理を実行するようにしてもよい。
【００７６】
〔プログラム構造〕
特定サイト検索サービスを実現するプログラムの制御構造について説明する。これから説明する処理は、図２に示すＵＲＬ検索部１３４のうち、質問文解析部１３０の後に行なわれる処理に相当する。したがってこのプログラムは、検索要求のテキスト列であって、構文解析後の形態素列を受けたことに応答して起動する。
【００７７】
図１０を参照して、このプログラムは、有効フラグがオンのレコードをオークションマスタテーブル１７４において検索することにより、現在運営されているオークションを決定するステップ３６０と、受信した検索要求の形態素列と、コーパス記憶装置６４に記憶された全質問文との間の距離を算出するステップ３６２と、ステップ３６２の処理結果を受け、検索要求との距離が最も小さな質問文を選択するステップ３６４と、ステップ３６４の処理で選択された質問文が属するクラスタのプロトタイプを選択するステップ３６６と、ステップ３６４で選択された質問文又はステップ３６６で選択されたプロトタイプと関連付けられているＵＲＬを質問文―ＵＲＬ対照ＤＢ６８から、検索されたＵＲＬと関連付けられているマッピングコーパスをマッピングコーパス７０から、それぞれ検索するステップ３６８とを含む。本実施の形態では、質問文に対応するＵＲＬが質問文―ＵＲＬ対照ＤＢ６８に記憶されていればそのＵＲＬを用い、そうでない場合にはステップ３６６で選択されたプロトタイプに対応するＵＲＬを用いる。マッピングコーパス７０には、質問文―ＵＲＬ対照ＤＢ６８に記憶されているＵＲＬに対するクエリ文を作成するためのマッピングルールが記憶されていることが前提となる。
【００７８】
このプログラムはさらに、ステップ３６８に続き、ステップ３６６及びステップ３６８で検索されたＵＲＬ及びマッピングルールと、質問文解析部１３０から受けた構文解析後の検索要求とを用い、マッピングルール内のキーワード部分を検索要求内の対応する単語で置換することによりクエリ文を生成するステップ３７０と、このクエリ文とステップ３６８で検索されたＵＲＬとを組合せることによりクエリ要求をインターネット上に送出する（発行する）ステップ３７２と、ステップ３７２で発行されたクエリ要求に対するレスポンスを受信し、最初の検索要求を送信してきた端末に転送するステップ３７４と、以上の一連の処理について、請求に必要な情報を含むアクセスログを出力して一連の処理を終了するステップ３７６とを含む。本実施の形態では、検索要求が与えられるたびに図１０に示されるプログラムの実行が開始され、レスポンスを返すと終了する。
【００７９】
〈動作〉
以上に構成を説明した情報検索サービスシステム４０は以下のように動作する。この情報検索サービスシステム４０を含むシステム３０の動作は、一つのオークションについて見ると大きく３つのフェーズに分割される。第１のフェーズはオークションの準備フェーズである。第２のフェーズはオークションフェーズである。第３のフェーズはオークションの結果に基づく特定サイト検索サービスの運用フェーズである。以下、順番に説明する。
【００８０】
─オークションの準備フェーズ─
オークションを開始するに先立ち、入札者テーブル１７０及びオークションマスタテーブル１７４には、オークション開催に必要な情報が記憶される。入札者テーブル１７０には、オークションごとではなく、情報検索サービスシステム４０によるサービスによりユーザを自分のサイトに誘導しようとするサイトの運営者がウェブを通じて自己の情報を登録する。オークションマスタテーブル１７４には、情報検索サービスシステム４０の運営者がオークションを管理するために必要な情報を予めオークションごとに登録する。
【００８１】
プロトタイプテーブル１７２、入札明細テーブル１７６、落札情報テーブル１７８、及びマッピングコーパステーブル１８０はオークション開始前にクリアされる。
【００８２】
情報検索サービスシステム４０の運営者は、予め多数の質問文をインターネット上から収集し、コーパス記憶装置６４にコーパスとして記憶させる。各質問文には互いを識別するための一意名質問文ＩＤが割当てられる。クラスタリング処理部１００は、このコーパスに含まれる質問文を所定数のクラスタに分類し、各クラスタについてプロトタイプ文を決定する。クラスタにはクラスタ番号が割当てられる。決定されたプロトタイプ文は、対応するクラスタのクラスタ番号及びそのプロトタイプの質問文ＩＤとともにプロトタイプ記憶部１０２に記憶される。これらプロトタイプにアクセスするための情報は図４に示すプロトタイプテーブル１７２に記憶される。本実施の形態では、プロトタイプには、その質問文ＩＤとは別のプロトタイプＩＤが割当てられる。
【００８３】
─オークションフェーズ─
オークションの準備ができると、情報検索サービスシステム４０は何らかのメディアを通じてオークションの開始を複数のサイト運営者４６に通知する。興味を持ったサイト運営者はオークションの内容について調べることになる。これは問合処理部１９６により処理される。
【００８４】
問合処理部１９６は、図８に示す遷移図にしたがってサイト運営者４６の端末に表示される画面を制御する。図８に示す各画面のうち、プロトタイプ別入札情報一覧表示画面２８６（図６）において、サイト運営者が入札の操作をすると、入札処理部１９８により入力内容がチェックされる。入札内容が正当であれば、入札更新処理２９０が実行され、入札明細テーブル１７６に入札の明細が追加される。さらに、入札後の情報にしたがってプロトタイプ別入札情報一覧表示画面２８６が更新される。入札内容が正当でなければ、エラーメッセージとともに、入力時のプロトタイプ別入札情報一覧表示画面２８６が再度表示される。
【００８５】
なお、オークションは、オークションマスタテーブル１７４に記憶されたオークションの開始時期にならなければ開始されない。また、オークションマスタテーブル１７４に記憶された終了時期になると終了する。オークションの開催時期以外の時期には、図６に示す画面は表示されず、入札もできなくなる。仮にそのような時期に何らかの原因で入札がされたとしても、入札内容がエラーであるとして入札が拒否される。
【００８６】
このようにして、入札明細テーブル１７６には、複数のサイト運営者４６による入札明細が蓄積される。この入札処理では、あるプロトタイプについて、既に付けられている単価よりも高い単価をつけない限り、入札内容が正当でないとして拒否される。本実施の形態でのプロトタイプの入札の処理自体は、通常行なわれているオークションの技術をそのまま転用できる。
【００８７】
なお、このオークションに入札したサイト運営者は、自分が入札したプロトタイプについて、クエリ文を作成するためのマッピングルールをマッピングコーパステーブル１８０に追加できる。各マッピングルールは、入札されたプロトタイプ文のプロトタイプＩＤ及び入札者ＩＤと関連付けてマッピングコーパステーブル１８０に蓄積される。
【００８８】
開催されているオークションについて、オークションマスタテーブル１７４中の該当レコードの終了時期に到達すると、落札処理部２６２は、落札処理を開始する。
【００８９】
落札処理では落札処理部２６２は、落札情報テーブル１７８から、プロトタイプごとに最も単価の高い入札明細を抽出する（図９のステップ３１０）。抽出された全ての明細に対し、入札明細テーブル１７６内のその明細に対応するレコードの落札フラグをセットし（ステップ３４０）、プロトタイプテーブル１７２中の、その明細中のプロトタイプＩＤに対応するレコードの入札完了フラグをオンに更新する（ステップ３４２）。
【００９０】
ステップ３１０で抽出された全ての入札明細に対し、ステップ３４０及びステップ３４２の処理が完了すると、再び入札明細テーブル１７６から落札フラグがオンの明細を入札者ＩＤ順、プロトタイプＩＤ順に読出す（ステップ３１６）。これらのレコードの入札者ＩＤにより示される入札者が各プロトタイプの落札者である。ステップ３１８で、各落札者に対し、落札内容の通知メールを生成し、送信する。このとき、落札情報テーブル１７８に、落札内容のレコードを追加する。
【００９１】
続いて、プロトタイプテーブル１７２から、該当するオークションＩＤを持ち入札完了フラグがオフのレコードを読出し（ステップ３２０）、その件数が０か否かを判定する。件数が０であれば全てのプロトタイプについて落札が完了したということであるので、オークションマスタのオークション完了フラグをセットし（ステップ３２４）、オークション完了のメッセージをシステム出力に出力して処理を終了する。ステップ３２０で読出されたレコードの件数が０でなければ、有効な入札がなかったプロトタイプ文が存在するということである。この場合にはオークション未完のメッセージとともにそれらプロトタイプ文を特定する情報をシステム出力に出力して（ステップ３２８）処理を終了する。
【００９２】
オークション管理者は、オークションが未完の場合には、再度、入札がなかったプロトタイプの入札を行なうことができる。全てのプロトタイプが落札されれば問題ないが、一部のプロトタイプについて落札者が最後までない場合には、それらプロトタイプと、そのプロトタイプのクラスタに属する質問文とに特定の情報を付しておく。オークションで、それら質問文に近い検索要求が来た場合の処理については後述する。
【００９３】
落札処理が完了すると、落札情報が落札情報テーブル１７８に保持されている。
【００９４】
─運用フェーズ─
図２に示すオークション管理部１０８は、タイマ１１０の出力に基づいてオークションデータＤＢ１０６の内容を常にチェックし、オークションの運用開始時期に到達したオークションであって、オークション開始フラグ及びオークション完了フラグが共にオン、運用開始フラグ及び運用完了フラグがともにオフのものがあるか否かを調べる。そのようなオークションがあれば、オークション管理部１０８は、そのオークションについて、オークションマスタ更新部２６０及び運用ＤＢ更新部２６６に対し、オークションの運用の切替の指示を発行する。
【００９５】
オークションマスタ更新部２６０はこの指示を受けると、オークションマスタテーブル１７４の該当するレコード２５４の運用開始フラグをオンに更新する。
【００９６】
運用ＤＢ更新部２６６は、この指示を受けると、落札情報テーブル１７８の記憶内容に基づいて質問文―ＵＲＬ対照ＤＢ６８及びマッピングコーパス７０の内容を更新する。具体的には、各プロトタイプを入札したサイト運営者の、入札者テーブル１７０のレコードからＵＲＬを読出し、そのプロトタイプのクラスタに属する各質問文と、読み出されたＵＲＬとを関係付けて質問文―ＵＲＬ対照ＤＢ６８に保存する。単にプロトタイプＩＤとＵＲＬとを関係付けた情報を質問文―ＵＲＬ対照ＤＢ６８に記憶させるようにしてもよい。この場合、質問文―ＵＲＬ対照ＤＢ６８の容量を小さくできる。ただしこの場合には、検索要求を受けたときに、その検索要求との距離が最も小さな質問文を特定した後、その質問文が属するクラスタのプロトタイプを特定してからでないと質問文―ＵＲＬ対照ＤＢ６８からＵＲＬを読出すことができず、応答性が多少悪くなる可能性がある。
【００９７】
運用ＤＢ更新部２６６はまた、各プロトタイプについて、マッピングコーパステーブル１８０に各質問文に関連付けて記憶されているマッピングルールのうち、そのプロトタイプの落札者によるもののみを選択してマッピングコーパス７０に転記する。
【００９８】
なお、本実施の形態では、この転記は運用の切替時に行なわれるので、落札後、運用開始までの間にも落札者がマッピングルールを追加することができる。ただし、そのような処理を禁止することもできる。そのような場合、マッピングコーパステーブル１８０からマッピングコーパス７０への転記を、オークションの落札時に行なうようにしてもよい。
【００９９】
運用が開始されると情報検索サービスシステム４０は以下のように動作する。端末４４は本実施の形態では携帯電話であることが想定されている。端末４４のユーザは、情報検索サービスシステム４０のサービスを利用するためのウェブページにアクセスし、検索要求を音声で入力する。端末４４上は、通常の携帯電話の処理と同様、入力音声をコードブックを用いてコード化し、情報検索サービスシステム４０のコード受信部８０に送信する。
【０１００】
コード受信部８０は、受信した一連のコードからコードブックを用いてもとの音声データを復元し、特徴量算出部８２に与える。特徴量算出部８２は、この音声データをフレーム化し、各フレームから所定の音響特徴量を算出して音声認識装置８４に与える。音声認識装置８４は、通常の音声認識装置として動作し、検索要求に対応するテキストデータを生成して質問文解析部１３０に与える。
【０１０１】
質問文解析部１３０はこの検索要求のテキストデータを受けると、そのデータにより表される文章（ここでは日本語が想定している。）に対する形態素解析、構文解析、意味解析などの処理を行なって形態素列を生成し質問文検索部１３２に与える。各形態素には、質問文解析部１３０の処理の結果、品詞タグ、階層的な意味タグなど、質問文検索に必要な情報がタグとして付されている。
【０１０２】
質問文検索部１３２は、コーパス記憶装置６４に記憶されている各質問文と、質問文解析部１３０から与えられる検索要求の形態素列との間の距離を計算し、検索要求との距離が最短である質問文を特定し、その質問文ＩＤをＵＲＬ検索部１３４に検索要求とともに与える。
【０１０３】
ＵＲＬ検索部１３４は、与えられた質問文ＩＤに基づいて質問文―ＵＲＬ対照ＤＢ６８から対応するＵＲＬを読出す。クエリ生成部１３６は、この質問文又はプロトタイプ文に対応してマッピングコーパス７０に記憶されているマッピングルールを読出す。クエリ生成部１３６はさらに、検索要求、ＵＲＬ，及びマッピングルールに基づいてクエリを生成し、クエリ発行部１３８に与える。クエリ発行部１３８は、このクエリをインターネット上に送信し、当該クエリはＵＲＬにより指定されるサービスサイト４２に送信される。
【０１０４】
サービスサイト４２では、このクエリについては予め準備されていたマッピングルールに基づくものであるため、高い精度でクエリに対応する応答（ＨＴＭＬ文書）を生成し、クエリ発行部１３８に返信してくる。クエリ発行部１３８は、受信したＨＴＭＬ文書をクエリ結果送信部１４０に与える。
【０１０５】
クエリ結果送信部１４０は、クエリ発行部１３８から与えられたＨＴＭＬ文書をサービス利用端末４８に転送する。このとき転送されるＨＴＭＬ文書は、あたかもサービスサイト４２から直接サービス利用端末４８に返信されたようにサービス利用端末４８上で表示されるようにすることが望ましい。クエリ結果送信部１４０は、クエリ結果の送信をするたびに、その内容を検索ログとして検索ログ記憶部１５０に保存する。検索ログとしては、各落札者に対する請求ができる程度の情報を保存するだけでよいが、検索ログから得られる統計的情報をさらに落札者に提供する場合には、目的にあわせた情報を検索ログに記録することが望ましい。
【０１０６】
１請求期間が経過すると、請求処理部１５２は検索ログ記憶部１５０からその請求期間内に行なわれた検索の検索ログを検索ログ記憶部１５０から抽出する。請求処理部１５２はさらに、抽出された検索ログについて、その検索の際に用いられたプロトタイプＩＤから、そのプロトタイプの落札者及びその落札単価を特定し、落札者毎に集計して、検索ログから得た、請求金額の計算の基礎データとともに請求書を送付する。全ての落札者に対してこの処理が終了すると、請求処理の終了に伴う処理を行なう。
【０１０７】
以上のように本実施の形態によれば、質問文コーパスを構成する、非常に大きな数の質問文について、実質的に個別にオークションにかけることができる。落札者は、落札した質問文については、その質問文に類似した情報要求があれば、その情報要求に対して自分が運営するサイト又は自分が関係するサイトからの情報を応答として要求者の端末に返信する処理を独占的に行なうことができる。落札者は、自己のサイトで提供するサービスが利用される機会を効率的に得ることができるという効果がある。
【０１０８】
情報要求者の立場から言うと、従来のように一旦検索サイトで情報を検索した後、提示されたリストの中から自分の必要とする情報を選ぶ、というスタイルではなく、入力した情報検索のための質問文に類似した質問文の落札者の運営するサイトで提供されるサービスに直ちにアクセスできる。質問文は、質問文に含まれるキーワードの属性により異なるサイト運営者により落札されるので、情報の検索要求ごとに適切なサービスを提供するサイト運営者のサイトの情報を直接得ることができる。したがって、検索結果の一覧から情報を選択するという手間を省くことができる。
【０１０９】
［第２の実施の形態］
〈構成〉
上に説明した第１の実施の形態では、質問文が互いに重複しない複数のクラスタに分類されることを前提としている。そのようにシステムを構成することにより、システムの構造を簡略なものとすることができる。
【０１１０】
しかし、オークションでは、そのように互いに排他的な値をとる属性により質問文を分類するだけでなく、重層的な分類を許す必要が生じることも考えられる。例えば、プロトタイプ文のみを指定して入札するのではなく、プロトタイプ文にさらに情報検索要求の属性に基づいて特定サイトにその検索要求を誘導する場合である。例えば、飲食店に関する検索要求について、地域を指定せず「レストラン」を属性に選択する場合と、特定地域（例えば大阪府内、京都市内など）のみを指定して「レストラン」を属性に選択する場合とを考える。両者は一方の選択地域が他方の選択地域を包含する形となっている。この場合、地域を指定しない入札者と、特定地域のみを指定した入札者とがあれば、それらは、特定地域については互いに競合するが、それ以外の地域では特に競合はしない。だとすれば、これらの入札者の間でも何らかの形でオークションを成立させ、かつ特定サイト検索サービスの運営者にとっての利益も極大化できれば好ましい。
【０１１１】
本実施の形態ではそのような形でのオークションを可能とする。そのために本実施の形態では、意味的辞書と同様の形式で、ツリー状の属性ツリーを予め準備し、このツリーにより属性の包含関係を調べる。同じ種類の属性について、互いに包含関係にある２つの値が指定され、単価を除いた他の条件が同一の２以上の入札が発生した場合、その種類の属性の属性ツリー上で下位にある値の属性範囲についてはいずれか単価が高いものが落札することとし、属性ツリー上で上位にある値の属性範囲については、その値を指定して入札したものが落札することとする。
【０１１２】
例えば、下位の属性値を指定した入札者の入札単価の方が上位の属性値を指定した入札者の入札単価よりも高い場合、その下位の値を指定して入札者がその範囲については落札し、上位の属性値を指定した入札者はその値により指定される範囲の内、下位の値により定まる範囲を除外した部分のみ落札するようにする。上位の属性値を指定した入札者の入札単価の方が下位の属性値を指定した入札者の入札単価よりも高い場合、その属性値により定まる範囲の全体について、上位の値を指定したものが落札する。
【０１１３】
このようにすることにより、例えばビジネスとして限定された範囲を対象としているサイト運営者はある属性について、その限定された範囲のみを比較的高値で入札し落札することにより、自分のビジネスを有利に運営することができる。ビジネスとして広い範囲を対象としているサイト運営者は、広い範囲については比較的低い入札単価で落札する機会を持つことができ、かつ競合する範囲については他の入札者でより高い入札単価を示したものに譲ることも、その範囲のみを指定してより高い単価で入札することもできる。オークションに参加するサイト運営者にとって、自己のビジネスが対象とする範囲に応じた戦略にしたがって入札を行なうことができる。その結果、オークションがより活性化される可能性が高くなる。
【０１１４】
図１１に、この第２の実施の形態に係る情報検索サービスシステム４００の概略構成を示す。図１１に示す情報検索サービスシステム４００は、図２に示す情報検索サービスシステム４０に代えて用いることができる。
【０１１５】
図１１に示す情報検索サービスシステム４００が情報検索サービスシステム４０と異なるのは、オークションシステム６２に代えて上記したような重層的な属性値でのオークションを可能にする機能を持つオークションシステム４０４を含む点、及び、特定サイト検索サービス実行部６６に代えて、そうした重層的なオークションの落札結果にしたがって情報の検索要求を適切なサービスサイト４２に誘導する機能を持つ特定サイト検索サービス実行部４０６を含む点である。
【０１１６】
オークションシステム４０４はオークションシステム６２と同様の構成を持つが、上記した属性ツリーを記憶するための属性ツリー記憶部４２２を新たに含む点と、オークションシステム６２で用いられたオークション関連のデータについて、重層的な分類を許容する形式のデータとなるように修正したデータを記憶する、図２に示すオークションデータＤＢ１０６に相当するオークションデータＤＢ４２６を含む点と、同様に重層的な分類を許容する形でのオークション処理と落札処理及び特定サイト検索サービスの切替処理とをそれぞれ実行するオークション実行部４２０及び更新部４２４を含む点とにおいて、図２に示すオークションシステム６２と異なっている。なお、図１１に示すオークション実行部４２０は図２に示すオークション実行部１０４に、更新部４２４は図２に示す更新部１１２に、それぞれ相当する。
【０１１７】
図１２に、オークションデータＤＢ４２６のテーブルのうち、プロトタイプテーブルのレコード４４０と、入札明細テーブルのレコード４４２との構成を示す。
【０１１８】
プロトタイプテーブルのレコード４４０は、第１の実施の形態のプロトタイプテーブル１７２のレコード２５２（図５参照）に加え、第１及び第２の属性の値を保持する２つのフィールドを持つ。入札明細テーブルのレコード４４２は、第１の実施の形態の入札明細テーブル１７６のレコード２５６に加え、入札時に入札者がプロトタイプ文の属性についてそれぞれ選択した属性値を格納する、第１及び第２の属性特定情報フィールドを持つ。
【０１１９】
〔画面構成及び画面遷移〕
図１３を参照して、この第２の実施の形態に係る情報検索サービスシステム４００が運営するオークションに対し、入札者が質問文入札の際の問合せをしたときの入札初期画面４５０では、プロトタイプ文と、その入札に関連する簡単な情報とが明細行としてプロトタイプＩＤ順に表示される。
【０１２０】
各明細行は、プロトタイプ文に対する入札の詳細を表示させるための右向きの三角形と、プロトタイプに振られた番号（「番号」欄）と、プロトタイプ文（「代表文」欄）と、そのプロトタイプ文に対する入札数（「入札有無」欄）と、この画面を表示させているユーザによる入札がそのプロトタイプ文に対し行なわれているか否かを示す情報（「応札」欄）と、プロトタイプに関する詳細（図１２に示すプロトタイプテーブルのレコード４４０の内容）を表示させるための詳細ボタンとを含む。
【０１２１】
各明細行の左端の右向き三角をユーザがクリックすると、その明細についての入札の内容が表示される。このときの画面を図１４に示す。以下に説明する画面の画面遷移は、クライアント側のみで行なわれる処理による画面遷移と、クライアントからサーバに対してその都度入力データを送信し、サーバでの処理により生成された画面データをクライアントに返信することによる画面遷移との双方を適切に組合せて実現することができる。
【０１２２】
図１４に示す画面は、番号＝１のプロトタイプの右三角形がクリックされたときの画面である。番号＝１のプロトタイプの行の左端の右向き三角形が下向き三角形に変化し、入札内容が展開されて下部に表示される。図１４に示す例では、番号＝１のプロトタイプに対しては４つの入札がある。これらがそれぞれ別々の入札明細表示行として表示されている。
【０１２３】
このプロトタイプには２つの属性を適用するためのフィールドがある。この例では、第１の属性は「地名」であり、第２の属性は「飲食店」である。すなわち、このプロトタイプ文には属性が付与されたキーワードが２つ存在している。
【０１２４】
各入札明細表示行は、その入札明細の内で、落札の可能性があるもののみを示している。すなわちこの例では、現時点では４人のユーザが別々に落札可能である。
【０１２５】
各入札明細表示行は、その入札明細表示に割当てられた番号（「１．１」など）と、プロトタイプ文の第１及び第２の属性に対して、入札者が指定した値（「属性名１」欄及び「属性名２」欄）と、入札価格（「最高入札価格」欄）とを含む。属性の指定値が異なる場合、別々の入札者が落札できる。競合する入札者の場合には、落札可能な単価をつけたものの入札の内容のみがここに表示される。
【０１２６】
各入札明細表示行はさらに、この画面を現在操作しているユーザがこの入札明細と単価を除いて同じ条件で入札するかどうかを指定するための「応札」欄と、応札する場合の単価を入札する「単価」欄とを含む。応札欄にはプルダウンメニューがデフォルトで（応札）「しない」が表示される。このメニューで「する」を選択すると「単価」の入力が可能になる。このときの表示を、例えば図１５の画面４５４内の１番目のプロトタイプに対する４番目の入札明細行により示す。いずれかの入札明細に関する入札を行ない「入札する」ボタンを押すと、入札内容がサーバに送られ、入札明細の追加が行なわれる。
【０１２７】
なお本実施の形態では、単価として既に入札されている最高入札価格よりも高い金額でなければ入札はできないようにする。属性について、同じ値の属性でより価格の高い入札があれば、その前に表示されていた入札明細は画面上で削除される。しかし、既に属性値についてある値を指定してある単価での入札がされていたところに、属性の値としてより狭い範囲のものを指定した、より単価の高い入札があった場合には、新たな入札が追加されるが、元から存在していた入札明細も残る。新たな入札により指定された範囲以外の部分については、その前に最高価格で入札していた明細が有効と考えられるためである。属性によりどのような範囲が指定されたかについては、後述する属性ツリーにより判定する。
【０１２８】
図１４において、１番目のプロトタイプに対する１番目の入札は、第１の属性（地名）及び第２の属性の双方について指定せず、４．２円を入札単価としたものである。２番目の入札は、地名として「東京都」を指定し、飲食店として「ラーメン」を指定した、５．３０円を入札単価としたものである。この２番目の入札は１番目の入札よりも後にされたもので、１番目の入札よりも狭い範囲を指定した、より高い単価のものである。したがって２番目の入札が追加されると共に、１番目の入札も、２番目の入札により指定された範囲以外の範囲を指定したものとして、残っている。
【０１２９】
３番目の入札は、地名として霞ヶ関、飲食店の種類としてラーメンを指定した、５．３２円を入札単価とするものである。これも２番目の入札よりもより狭い範囲を指定した、より高い単価のものであるので有効である。同時に、「霞ヶ関」以外の地域で「ラーメン」を指定した部分については、２番目の入札が依然として有効なので、２番目の入札もまだ残っている。
【０１３０】
４番目の入札は、地名として「大阪市」を、飲食店の種類として「ラーメン」を、それぞれ指定した、単価４．４０円のものである。この入札は、１番目の入札とは部分的に競合するが、２番目及び３番目の入札とは競合しない。１番目の入札に対して、指定した属性により定まる範囲はこちらの方が狭い。したがってこの入札も有効である。
【０１３１】
以上から、１番目のプロトタイプ文に対する１番目の入札はこの状態でも依然として有効であるが、ただしその範囲としては、飲食店の種類としてラーメンについては地名の全範囲から東京都と大阪市とを除いた範囲で有効であり、ラーメン以外については、地名の全範囲について有効なものとして残っている。２番目の入札については、飲食店の種類としてラーメンで、かつ地名としては東京都の範囲内で、ただし霞ヶ関を除く部分についてのみ有効なものとして残っている。
【０１３２】
図１４に示す例では、１番目のプロトタイプの４番目の入札明細行（最後の入札明細行）について、その左端にプラスマークが表示されている。このプラスマークをクリックすると、新たな入札明細行が画面上に表示され、ユーザが２つの属性及び単価を指定して、このプロトタイプ文に対する新たな入札を行なうことができる。このときの表示状態を図１６の画面４５６の、１番目のプロトタイプに対する５番目の入札明細行により示す。
【０１３３】
本実施の形態では、指定できる属性の種類、及びその値については予めサーバで属性ツリーとして準備しているものに限定されていることが前提である。新たな入札の入力時には、プルダウンメニューにそれら許されるもののみが表示され、その中からユーザの希望するものを選ぶものとする。
【０１３４】
例えば図１６に示す状態で単価を指定して「入札する」ボタンを押すと、入札情報がサーバに送られ、その処理の結果の画面４５８が図１７に示すように表示される。この例では、このユーザが新たな属性を指定して第１のプロトタイプに対する入札を追加し、かつ４番目の入札明細行についてはより高い単価で入札をした。その結果、第１のプロトタイプに対する入札数は全部で５となり、その中でこのユーザによるものが２となる。したがってその内容に対応する表示が第１のプロトタイプの明細行の入札有無欄に「あり（５）」として、応札欄に「あり（２）」として、それぞれ示されている。
【０１３５】
仮に図１７に示す画面４５８で第１のプロトタイプの明細行の左端の右向きの三角形をクリックすると、図１４に示す場合と同様、第１のプロトタイプに対する入札明細行の表示画面４６０が図１８に示すように表示される。ただしこの例では、端末を操作しているユーザによる入札が２つあるため、それらは他の入札と区別して画面上、強調表示される。例えば文字色を変えたり、背景色を変えたり、反転表示したり、特定のマークを入札明細行に追加表示したりすることが考えられる。
【０１３６】
〔属性ツリー〕
図１９を参照して、図１１の属性ツリー記憶部４２２に記憶される属性ツリー４７０は、予め属性ごとに準備される。図１９に示す属性ツリー４７０は、地域に関するものである。この例では、属性ツリー４７０は、日本全体を示すルートノードと、ルートノードから分岐する、日本全体を東北・北海道、関東・甲信越、東海、北陸などの第１の階層に分割した第１階層のノードと、第１階層のノードの各々から分岐し、そのノードにより表される地域をより細かく、例えば県単位に分割した第２階層のノードと、さらに第２階層のノードの各々から分岐する第３階層のノードと、などを含む。階層の数及びどの範囲で各ノードにより表される地域を分割するかは、システムの設計により容易に定めることができる。
【０１３７】
なお、この例では地名に関する属性ツリーで、ルートノードにより日本全国が表されるものとしたが、もちろん本実施の形態の地名に属する属性ツリーがそのようなものに限定されるわけではない。より広く、アジア全体、又は世界全体を分割するような属性ツリーでもよい。
【０１３８】
この属性ツリーは、属性に関して重複する入札を許し、かつそれらについていずれが有効かを明確に判定するため、ノードの上下関係が明確になるような構成を持つ。あるノードは、ルートノードを除き必ず１つだけ親ノードを持ち、同じノードから分岐する同じ階層に属するノードは、互いに異なる範囲を指定する。
【０１３９】
このノードで、ある階層のノードを指定した入札がある場合、そのノードより下位のノードを指定した入札で、より高価な単価を指定した入札をすることが可能である。その場合、既存の入札については、新たな入札により指定された以外の範囲についてのみ有効となる。
【０１４０】
ある階層のノードを指定した入札がある場合、そのノードより上位のノードを指定した入札も可能であるが、この場合には単価は新たに指定されたノードをルートノードとする部分ツリーを指定したいずれの入札に対しても、より高い単価を指定しなければならない。そのような条件が満たされれば、新たな入札が有効となり、その下のノードを指定した入札は全て無効となる。
【０１４１】
属性ツリーでは、同じ階層のノードの間では、そのノードに対応する値により指定される範囲は重複せず、ある階層のノードの値により指定される範囲は、そのノードから分岐する全てのノードの値により指定される範囲を包含する。すなわち、属性ツリーは、ある種類の属性に付いて、その属性の値の間の包含関係をツリー形式で現したものである。
【０１４２】
〔プログラム構造〕
図２０を参照して、入札初期画面の表示要求を端末から受けたサーバで実行されるプログラムの制御構造を説明する。このプログラムは、プロトタイプＩＤ，第１の属性特定情報、及び第２の属性特定情報ごとに、最高入札単価の入札明細を入札明細テーブルで検索するステップ４８０と、現在のオークション対象となっているオークションのレコードをオークションマスタテーブルから読出し、入札初期画面のヘッダ部分を作成するステップ４８２と、以下に説明するプロトタイプ明細作成ルーチン４８６を各プロトタイプについて実行するステップ４８４と、「戻る」ボタン及び「入札する」ボタンを含むボトム部分を作成するステップ４８８とを含む。
【０１４３】
プロトタイプ明細作成ルーチン４８６は、処理対象のプロトタイプについて、プロトタイプの明細行を作成するステップ４９０と、ステップ４８０で読出された入札明細のうち、処理対象のプロトタイプのＩＤをプロトタイプＩＤとして持つ全ての入札明細について以下の入札明細行作成ルーチン４９４を実行するステップ４９２とを含む。
【０１４４】
入札明細行作成ルーチン４９４は、処理対象の入札明細行が、処理対象のプロトタイプ文に関する最後の入札明細行か否かを判定し、判定結果に応じて制御の流れを分岐させるステップ５００と、ステップ５００の判定が肯定のときに、入札明細の追加を指示するための追加ボタン（図１４などに示すプラスボタン）を作成するステップ５０２と、ステップ５００の判定が否定のとき、又はステップ５００の判定が肯定でステップ５０２の処理が完了したときに実行され、処理対象の入札明細の入札者ＩＤが、入札初期画面の表示要求を送信してきたユーザの入札者ＩＤと一致するか否かを判定し、判定結果に応じて制御の流れを分岐させるステップ５０４とを含む。
【０１４５】
入札明細行作成ルーチン４９４はさらに、ステップ５０４の判定が肯定のときに実行され、入札者用の、強調表示された入札明細行を作成してこのルーチンの実行を終了させるステップ５０８と、ステップ５０４の判定が否定のときに実行され、通常の入札明細行を作成してこのルーチンの実行を終了させるステップ５０６とを含む。
【０１４６】
図２１を参照して、ユーザが端末で「入札する」というボタンを押すことにより送信されてきた情報を処理するためのサーバプログラムは、以下のような制御構造を持つ。
【０１４７】
このプログラムは、入札処理後に表示される画面のヘッダを作成するステップ５１０と、入力される入札明細に誤りがあるか否かを判定するためのエラーフラグを０に設定するステップ５１２と、端末から送信されてきた入札明細について、以下に説明する入札チェックルーチン５１６を実行するステップ５１４と、ステップ５１４の処理の後に実行され、エラーフラグが０か否かを判定し、判定結果にしたがって制御の流れを分岐させるステップ５１８とを含む。
【０１４８】
本実施の形態では、基本的には端末での入札が過去の入札データに対して正当なものか否かについての判定を、端末での入力時点で端末において行なう。その判定結果をパスしたものが入力サーバに送信されてくる。したがって、基本的にはサーバでのこのようなチェックはしなくても、入力に誤りがある可能性は低い。しかし、端末でのチェックは、入札初期画面の表示要求をサーバが受信したときの入札明細に基づいて行なわれる。そのため、同一のプロトタイプに対して競合するような入札が２以上の入札者からほぼ同時に行なわれることもないとはいえない。そこで、本実施の形態では、念のために入札チェックルーチン５１６を実行し、万が一、互いに競合するような入札があった場合でもチェックできるようにする。
【０１４９】
入札チェックルーチン５１６は、処理対象の入札明細に対応するプロトタイプに関する情報を表示するプロトタイプ行を作成するステップ５３０と、処理対象の入札明細に関する応札が端末からなされたか否かを判定して制御の流れを分岐させるステップ５３２と、ステップ５３２の判定が肯定のときに、処理対象の入札明細をチェックするステップ５３４と、ステップ５３４での判定結果にしたがって、表示される画面の入札明細行を作成して処理を終了するステップ５３６とを含む。ステップ５３２の判定が否定のときには入札チェックルーチン５１６の実行は終了する。ステップ５３４の処理内容については図２２を参照して後述する。
【０１５０】
このプログラムはさらに、ステップ５１８の判定が肯定の時に実行され、端末から受信した、応札のあった各行について、入力内容に対応した入札明細レコードを作成し入札明細テーブルに追加するステップ５２２を実行するステップ５２０と、ステップ５１８の判定が否定のときに実行され、エラーメッセージを出力するステップ５２４と、ステップ５２２の後、及びステップ５２４の後に実行され、表示画面のボトム部分を作成して処理を終了するステップ５２６とを含む。
【０１５１】
図２２を参照して、図２１のステップ５３４で実行される入札明細行のチェック処理のルーチンは以下のような制御構造を持つ。すなわちこのルーチンは、チェック対象となっている入札明細行の第１及び第２の属性が空白か否かに応じて、制御の流れを分岐させるステップ５４０と、第１及び第２の属性がともに空白のときに実行され、処理対象の入札明細行と同一プロトタイプＩＤ，第１及び第２の属性が空白の入札明細レコードを入札明細テーブルで検索し、その最高単価を調べるステップ５４２と、第１の属性が非空白で、第２の属性が空白のときに実行され、処理対象の入札明細行と同一プロトタイプＩＤ、第２の属性が空白、第１の属性として第１の属性の入力値を包含する（属性ツリー上で第１の属性の入力値より上位のノードで、かつそのノードをルートノードとする部分木内に第１の属性の入力値に対応するノードを含むもの）ような値を持つ入札明細レコードを入札明細テーブルで検索し、その単価の最高値を取出すステップ５４４とを含む。
【０１５２】
このルーチンはさらに、第１の属性が空白で第２の属性が非空白であるときに実行され、入札明細行と同一プロトコルＩＤ，第１の属性が空白、第２の属性として第２の属性の入力値を包含する（属性ツリー上で第２の属性の入力値より上位のノードで、かつそのノードをルートノードとする部分木内に第２の属性の入力値に対応するノードを含むもの）ような値を持つ入札明細レコードを入札明細テーブルで検索し、その単価の最高値を取出すステップ５４６と、第１及び第２の属性の双方とも非空白のときに実行され、入札明細行と同一プロトコルＩＤ，第１の属性として第１の属性の入力値を包含するような値を持ち、第２の属性として第２の属性の入力値を包含するような値を持つ入札明細レコードを入札明細テーブルで検索し、その単価の最高値を取出すステップ５４８とを含む。
【０１５３】
このルーチンはさらに、ステップ５４２，５４４，５４６及び５４８に続き、入力された入札明細の入札単価が、これらステップで検索された入札明細レコードの単価より大きいか否かを判定し、判定結果により制御の流れを分岐させるステップ５５０と、ステップ５５０の判定結果が肯定のときに、処理対象の入札明細行に応じた通常行のデータを作成し出力して処理をこのルーチンの実行を終了するステップ５５２と、ステップ５５０の判定が否定の時に実行され、エラーフラグを１に設定するステップ５５４と、ステップ５５４に続き、処理対象の入札明細行に応じてエラー行のデータを作成して出力し、このルーチンの実行を終了するステップ５５６とを含む。
【０１５４】
図２３を参照して、第２の実施の形態のサーバにおいて行なわれる落札処理を実現するプログラムは以下のような制御構造を持つ。すなわち、このプログラムは入札明細テーブルから入札完了フラグがオフのレコードについて、プロトタイプＩＤ，第１及び第２の属性値の組合せごとに、最高入札単価の入札明細レコードを抽出するステップ５６０と、ステップ５６０で抽出された全明細に対して図９に示したものと同じ処理を実行するステップ３１２と、ステップ３１２に続き、入札明細テーブルから、落札フラグがオンの明細を入札者ＩＤ順及びプロトタイプＩＤ順で読出すステップ５６２とを含む。このステップ５６２で読み出された明細の各々が落札者を決定する。これら落札明細のレコードは落札情報テーブル１７８に追加される。
【０１５５】
このプログラムはさらに、ステップ５６２に読み出された入札明細により決定された落札者の各々について、落札結果を作成し発送するステップ５６４と、ステップ５６４の後、図９に示すものと同じ処理を実行して処理を終了するステップ３２２〜ステップ３２８とを含む。
【０１５６】
図２４を参照して、本実施の形態に係る特定サイト検索サービス実行部４０６が情報検索要求を受信したときに、特定サイト検索サービス実行部４０６で実行されるプログラムの制御構造について説明する。なお、以下の説明は、特定サイト検索サービス実行部４０６の内で質問文検索部１３２以後の各モジュールに関するものである。
【０１５７】
このプログラムは、図１０を参照して既に説明したものと同じ処理を実行するステップ３６０〜ステップ３６６と、ステップ３６６の後、ステップ３６６で選択されたプロトタイプについて、そのプロトタイプ中の記載に基づいて第１及び第２の属性ツリーを属性ツリー記憶部４２２から読出すステップ５８０とを含む。なお、このステップでは、入札明細行の属性の値が空白のときには属性ツリーの読出は行なわず、以下の処理でもそれらについての処理は行なわない。ただし以下の説明及び図面では説明を分かりやすくするため、属性の値が空白であったときの処理については説明しない。
【０１５８】
このプログラムはさらに、ステップ５８０に続き、選択されたプロトタイプのプロトタイプＩＤと、入札明細行の第１の属性値を包含する第１の属性値であって、ツリー内のレベルが最も低いノードに対応する値とを持つ落札明細レコードを落札情報テーブルから検索するステップ５８２と、ステップ５８２に続き、ステップ５８２で検索された落札明細の中から、選択されたプロトタイプのプロトタイプＩＤと、入札明細行の第２の属性値を包含する第２の属性値であって、ツリー内のレベルが最も低いノードに対応する値とを持つ落札明細レコードを抽出するステップ５８４と、図１０を参照して既に説明したものと同じ処理をそれぞれ実行して処理を終了するステップ３６８〜ステップ３７６とを含む。
【０１５９】
〈動作〉
上記した第２の実施の形態に係る情報検索サービスシステム４００は以下のように動作する。この情報検索サービスシステム４００の場合にも、動作フェーズは３つある。第１のフェーズはオークションの準備フェーズである。第２のフェーズはオークションフェーズである。第３のフェーズはオークションの結果に基づく特定サイト検索サービスの運用フェーズである。
【０１６０】
オークションの準備フェーズは、第１の実施の形態と基本的に同様である。ただし、プロトタイプには第１及び第２の属性の値が（もしあれば）キーワードとともにタグ付けされる。また、それら属性の各種類について、属性ツリーが予め作成され、機械可読な属性ツリー記憶部４２２に機械可読な形式で記憶される。
【０１６１】
オークション開始時になると、オークション管理部１０８の制御により、オークション実行部４２０が所定のオークションを開始する。開催中のオークションに関する入札初期画面の表示要求をオークション入札者４０２がオークションシステム４０４に与えると、オークション実行部４２０は以下のように動作する。
【０１６２】
オークション実行部４２０は、開催中のオークションに関する入札初期画面４５０（図１３参照）を作成し、入札者の端末に表示させる。この入札初期画面４５０には、以下の処理を全て実行するために必要な情報と、スクリプトとが含まれる。入札者がいずれかのプロトタイプの明細行の先頭の右向き三角をクリックすると、端末は右向き三角がクリックされたときのスクリプトを実行し、図１４に示す画面４５２と同様の画面を表示する。この画面で入札者が「戻る」を押すと画面は再び図１３に示すものに戻る。このとき、端末内での処理だけではなく、サーバで入札初期画面４５０を作り直すようにすると好ましい。
【０１６３】
図１４に示す画面４５２で入札者が応札「する」を選択したり、明細の追加を選択したりすると、端末はそれぞれ対応のスクリプトを実行し、例えば図１６の画面４５６を表示する。必要な入力を行なった後、入札者が「入札する」ボタンを押すと、入札明細行に関する情報がオークション実行部４２０に送信される。オークション実行部４２０は応札があると、その内容についてチェックし、エラーがなければ入札明細テーブルに入札内容を追加する。エラーがあれば入札内容を入札明細テーブルに追加することなく、エラー画面を端末に表示させる。
【０１６４】
このような処理を繰返しし、オークションの終了時期になるとオークション管理部１０８は、更新部４２４を制御して落札処理を行なう。落札処理では、更新部４２４は属性ツリー記憶部４２２に格納された属性ツリーを参照しながら、プロトタイプＩＤ、第１の属性値、及び第２の属性値の組合せごとに最高単価の入札明細レコードを入札明細テーブルから抽出し、落札情報テーブルに落札明細レコードとして追加する。更新部４２４は、第１の実施の場合と同様、質問文―ＵＲＬ対照ＤＢ４０８及びマッピングコーパス４１０についても落札結果に応じて更新する。落札結果はさらに、請求処理部１５２にも与えられる。請求処理部１５２は後の請求処理に必要な情報（単価情報など）を記憶する。
【０１６５】
オークションフェーズでは情報検索サービスシステム４００（特に特定サイト検索サービス実行部４０６）は以下のように凹さする。オークションについて落札処理が完了し、オークションの開始時期に到達すると、オークション管理部１０８はオークション管理部１０８はそのオークションの運用開始フラグをオンにセットする。
【０１６６】
端末４４から音声により情報の検索要求が来ると、音声入力フロントエンド６０は第１の実施の形態と同様の処理でこの検索要求を文字列に変換し質問文解析部１３０に与え、質問文解析部１３０はこの文字列に対する形態素解析などの処理を行ない、それぞれ意味的タグ及び品詞タグが付された形態素列を質問文検索部１３２に与える。質問文検索部１３２は、この形態素列とコーパス記憶装置６４に含まれる各質問文との間の距離を計算し、入力された形態素列との間の距離が最も小さな質問文を抽出し、ＵＲＬ検索部４３０に与える。ＵＲＬ検索部４３０は与えられた質問文に対応するＵＲＬを質問文―ＵＲＬ対照ＤＢ４０８から読出し、情報検索要求の形態素列と共にクエリ生成部４３２に与える。クエリ生成部４３２は、マッピングコーパス４１０から、選択された質問文に対応するマッピングコーパスを読出し、与えられた形態素列からキーワードを抽出し、マッピングコーパス内のキーワードに相当する位置に挿入してクエリを作成する。作成されたクエリはクエリ発行部１３８に与えられ、ＵＲＬ検索部４３０が読出したＵＲＬを指定してサービスサイト４２に送信される。サービスサイト４２から返信されてくる情報はクエリ発行部１３８を経てクエリ結果送信部１４０に与えられる。クエリ結果送信部１４０は、最初に情報の検索要求を送信してきたサービス利用端末４８に対し、クエリ結果を送信する。クエリ結果送信部１４０は同時に、検索ログを検索ログ記憶部１５０に書出す。
【０１６７】
情報検索サービスシステム４００は、受信した情報検索要求に対して以上のような処理を繰返す。この結果、情報検索要求の各々について、その情報検索要求に最も近い質問文がコーパス記憶装置６４から読み出され、その質問文が属するクラスタのプロトタイプを落札したサイト運営者に対する情報のクエリが行なわれる。クエリの結果は情報検索要求の発行者に戻される。その結果、情報検索要求を発行した利用者は、検索結果の単なる一覧ではなく、オークションにより落札した、情報検索要求に対する適切な情報を提供するサービス提供者のサービスに直接誘導される。その結果、利用者が必要な情報を入手する際の手間を少なくすることができる。サイトの運営者は、自分の運営するサイトにとって最も有効となるような範囲を属性として指定してプロトタイプ文を落札することで、潜在的な顧客を自己のサイトに誘導できる。狭い地域のみを対象とするようなサイトの場合には、その狭い地域について比較的高い単価でプロトタイプを落札できる。広い地域を対象とするサイトの場合、広い地域を指定して、比較的安い単価で入札することができる。
【０１６８】
なお、上記実施の形態では、先に高い単価で入札した入札明細が存在する場合には、後からたとえそれより広い範囲を指定するものであっても、より高い単価で入札しなければならない。しかし本発明はそのような実施の形態には限定されず、例えば後からある属性についてより広い範囲を指定して入札する場合、既に存在するより高い単価の入札明細により指定された範囲以外を指定して入札できるようにしてもよい。
【０１６９】
［第３の実施の形態］
上記した第１及び第２の実施の形態では、情報の検索要求（質問文）に類似する質問文、又は情報検索要求に含まれるキーワードに基づいて、その検索要求をどのサイトに転送するかを決めている。そして、その転送の仕方を、質問文コーパスをクラスタリングした結果に基づき、クラスタごとにオークションで決めている。しかし本発明はそのような実施の形態のみに限定されるわけではない。例えば属性が数値により表現される場合には、その属性の値が取りえる範囲をいくつかの数値範囲に分けてオークションにかけることが可能である。以下に説明する第３の実施の形態は、数値範囲に分けることができる属性として、情報の検索要求が発せられた端末の現在位置（ＧＰＳ位置）が属する範囲により、オークション対象を分割するというものである。
【０１７０】
なお、数値で表すことができる属性が位置情報に限定されないことは当然である。例えば温度、湿度、濃度、年齢、身長、体重、暦年、値段など、数値で表すことができる属性であれば、いずれもある範囲に分割し、それら範囲ごとにオークションにかけることができる。
【０１７１】
本実施の形態では、第２の実施の形態と同様、指定する範囲を予め属性ツリーと同様の構造に階層的なツリー構造で分類しておく。そうすることにより、第２の実施の形態と同じ論理を用いて数値範囲を指定したオークションを実現することができる。
【０１７２】
図２５に、この実施の形態における入札初期画面６００の例を示す。図２５を参照して、この入札初期画面６００は、基本的には図１３に示す入札初期画面４５０と同様である。この画面でプロトタイプの明細行の左端に表示されている右向き三角形をクリックすると画面は図２６に示す入札明細行表示画面６０２に遷移する。
【０１７３】
図２６を参照して、入札明細行表示画面６０２では、指定されたプロトタイプの明細行の左端の三角が下向きとなり、その行の下部に、その行のプロトタイプに関する入札明細行が展開して表示される。図２６に示す入札明細行表示画面６０２は、図１４に示す画面４５２と同様であるが、属性として属性名１のみが指定されている点が異なる。これは、ここでの第１のプロトタイプで指定されているのが属性名１のみであり、かつその内容が情報検索要求の位置情報となっていることによるものである。情報検索要求に付随して送信されてくる位置情報としては、端末に備えられたＧＰＳから得られるものが想定されている。
【０１７４】
本実施の形態で特徴的なのは、この第１の属性として、単語等ではなく、地図を用いた範囲による指定が行なわれている点である。図２６に示す例では、指定された範囲が地図として各入札明細行の属性の欄に表示される。これら各範囲については、その横に「範囲を確認」ボタンが表示されており、このボタンを押すと、別ウィンドウに、指定された範囲をより大きく表す地図が表示される。
【０１７５】
以下、既にある入札明細について、応札する場合の処理は既に説明したものと同様である。
【０１７６】
新たな入札を行なう場合には、このプロトコルに対応する入札明細行の内の最下行の左端に表示されたプラスマークをクリックすると、図２７に示す画面６０４に遷移する。画面６０４は、第２の実施形態の図１６に示したものと同様である。ただし、属性を指定するために「範囲を設定」ボタンが表示されている点が異なる。
【０１７７】
図２８に、「範囲を設定」ボタンを押したときに表示される画面６０６の例を示す。図２８に示す例では、画面６０６に重ねて、地図上の矩形を規定する２点（左上及び右下）を指定するウィンドウ６２０が表示される。本実施の形態では日本全図が最初に表示され、左側に示される拡大・縮小ボタン及び倍率変更ボタンと、地図のドラッグとにより自分の指定しようとする範囲を表示させ、指定して「ＯＫ」ボタンを押すことで、選択する地域を指定することができる。ただし本実施の形態では、既に説明したように、選択できる範囲は予め階層的な複数個の領域に分割されており、そのうちの一つのみした選択することはできない。このような区分の仕方を採用することで、オークションのロジックを簡単にし、第２の実施の形態と同様のプログラムで本実施の形態のシステムを実現することができる。
【０１７８】
図２８に示す画面６０６で範囲を指定して「ＯＫ」を押すと、図２７の画面と同様の画面に戻る。この画面でさらに「入札する」ボタンを押すと、第２の実施の形態と同様、サーバで入札明細のチェックが行なわれ、エラーがなければ、図２９に示すように、入札結果を反映した画面６０８が表示される。
【０１７９】
これ以外の点で、この第３の実施の形態に係るシステムの動作は第２の実施の形態と同様である。したがってここでは第３の実施の形態のシステムについての詳細は繰返さない。
【０１８０】
［コンピュータによる実現］
以上に説明した第１〜第３の実施の形態に係る情報検索サービスシステム４０及び情報検索サービスシステム４００などは、同様のハードウェア構成を持つ。例えば情報検索サービスシステム４０は、インターネットを介して他の装置と通信する機能を持つコンピュータハードウェアと、そのコンピュータハードウェアにより実行されるプログラムと、コンピュータハードウェアに格納されるデータとにより実現できる。プログラムの主要な部分の制御構造については図９及び図１０、並びに図２０〜図２４に示し、データ構造の例は図５及び図１２に示した。
【０１８１】
図３０を参照して、この情報検索サーバコンピュータ６３０は、ＦＤ（フレキシブルディスク）ドライブ６５２及びＣＤ−ＲＯＭ（コンパクトディスク読出専用メモリ）ドライブ６５０を有するコンピュータ６４０と、キーボード６４６と、マウス６４８と、モニタ６４２とを含む。
【０１８２】
図３１を参照して、コンピュータ６４０は、ＦＤドライブ６５２及びＣＤ−ＲＯＭドライブ６５０に加えて、ＣＰＵ（中央処理装置）６５６と、ＣＰＵ６５６、ＦＤドライブ６５２及びＣＤ−ＲＯＭドライブ６５０に接続されたバス６６６と、ブートアッププログラム等を記憶する読出専用メモリ（ＲＯＭ）６５８と、バス６６６に接続され、プログラム命令、システムプログラム、及び作業データ等を記憶するランダムアクセスメモリ（ＲＡＭ）６６０とを含む。情報検索サーバコンピュータ６３０はさらに、インターネットへの接続を提供するネットワークインターフェイス（Ｉ／Ｆ）６４４を含む。図示しないが、コンピュータ６４０はネットワークＩ／Ｆ６４４を介して携帯電話ネットワークと接続されており、他の端末とデータ通信を行なうことができる。
【０１８３】
情報検索サーバコンピュータ６３０に情報検索サービスシステム４０又は４００としての動作を行なわせるためのコンピュータプログラムは、ＣＤ−ＲＯＭドライブ６５０又はＦＤドライブ６５２に挿入されるＣＤ−ＲＯＭ６６２又はＦＤ６６４に記憶され、さらにハードディスク６５４に転送される。又は、プログラムは図示しないネットワークを通じてコンピュータ６４０に送信されハードディスク６５４に記憶されてもよい。プログラムは実行の際にＲＡＭ６６０にロードされる。ＣＤ−ＲＯＭ６６２から、ＦＤ６６４から、又はネットワークを介して、直接にＲＡＭ６６０にプログラムをロードしてもよい。
【０１８４】
このプログラムは、コンピュータ６４０をこの実施の形態の情報検索サービスシステム４０又は４００として機能させる複数の命令を含む。この動作を行なわせるのに必要な基本的機能のいくつかはコンピュータ６４０上で動作するオペレーティングシステム（ＯＳ）もしくはサードパーティのプログラム、又はコンピュータ６４０にインストールされる各種ツールキットのモジュールにより提供される。従って、このプログラムはこの実施の形態のシステム及び方法を実現するのに必要な機能全てを必ずしも含まなくてよい。このプログラムは、命令のうち、所望の結果が得られるように制御されたやり方で適切な機能又は「ツール」を呼出すことにより、上記した情報検索サービスシステム４０又は４００としての動作を実行する命令のみを含んでいればよい。
【０１８５】
情報検索サーバコンピュータ６３０は一般的なコンピュータにより実現される。コンピュータ一般の動作は周知であるので、ここではその詳細は繰返さない。
【０１８６】
今回開示された実施の形態は単に例示であって、本発明が上記した実施の形態のみに制限されるわけではない。本発明の範囲は、発明の詳細な説明の記載を参酌した上で、特許請求の範囲の各請求項によって示され、そこに記載された文言と均等の意味及び範囲内での全ての変更を含む。
【符号の説明】
【０１８７】
４０，４００ 情報検索サービスシステム
４２ サービスサイト
４４ 端末
４６，４０２ サイト運営者
４８ サービス利用端末
６０ 音声入力フロントエンド
６２，４０４ オークションシステム
６４ コーパス記憶装置
６６，４０６ 特定サイト検索サービス実行部
６８，４０８ 質問文―ＵＲＬ対照ＤＢ
７０，４１０ マッピングコーパス
７２ 課金処理部
１００ クラスタリング処理部
１０４，４２０ オークション実行部
１０６，オークション実行部 オークションデータＤＢ
１１２，４２４ 更新部
１３０ 質問文解析部
１３２ 質問文検索部
１３４，４３０ ＵＲＬ検索部
１３６，４３２ クエリ生成部
１３８ クエリ発行部
１４０ クエリ結果送信部
１６０ 質問文の集合
１６２ プロトタイプ集合
１７０ 入札者テーブル
１７２ プロトタイプテーブル
１７４ オークションマスタテーブル
１７６ 入札明細テーブル
１７８ 落札情報テーブル
１８０ マッピングコーパステーブル
１９６ 問合処理部
１９８ 入札処理部
２００ 登録情報保守部
２０２ 落札情報表示部
２０４ マッピング管理部
２６０ オークションマスタ更新部
２６２ 落札処理部
２６４ 落札通知処理部
２６６ 運用ＤＢ更新部
４２２ 属性ツリー記憶部
４７０ 属性ツリー
【特許請求の範囲】
【請求項１】
機械可読な複数個の文を記憶する、機械可読な記憶手段と、
前記記憶手段に記憶された前記複数個の文を、文の間に定義される距離に基づいて複数個のクラスタに分類し、各クラスタを代表する代表文を定める代表文決定手段と、
前記代表文の各々についてオークションをオンラインで行なうことにより、前記代表文の落札者を決定するオークション実行手段と、
前記複数個の文の各々に、当該文が属するクラスタの代表文の落札価格及び落札者を関係付ける価格付与手段と、
前記複数個の文の各々について、当該文に関係付けられた落札者により指定されるＵＲＩを記憶するＵＲＩ記憶手段と、
情報の検索要求文をオンラインで受信したことに応答して、前記記憶手段に記憶された前記複数個の文の中で、当該検索要求文との間の距離が最も小さな文を検索する文検索手段と、
前記文検索手段により検索された文に対応して前記ＵＲＩ記憶手段に記憶されたＵＲＩに、前記検索要求文から生成したクエリを送信することにより、当該ＵＲＩから得られる情報を前記検索要求文を送信した端末に送信する情報送信手段とを含む、情報検索サービス提供装置。
【請求項２】
前記代表文決定手段及び前記文検索手段において行なわれる距離の計算は同じ計算方法による、請求項１に記載の情報検索サービス提供装置。
【請求項３】
前記情報送信手段は、
前記ＵＲＩ記憶手段に記憶されたＵＲＩの各々について、当該ＵＲＩに送信するクエリを生成するための、マッピングルールを記憶するマッピングルール記憶手段と、
前記文検索手段が受信した前記情報の検索要求文に対する構文解析を行なって各単語に属性を付与し、属性付検索要求文を出力する構文解析手段と、
前記文検索手段により検索された文と、当該文と関連付けられたＵＲＩに対応して前記マッピングルール記憶手段に記憶されたマッピングルールとに基づいてクエリを生成し、前記文検索手段により検索された文に対応して前記ＵＲＩ記憶手段に記憶されたＵＲＩに送信するクエリ送信手段と、
前記クエリ送信手段により送信されたクエリに対する返信を前記検索要求文を送信した端末に転送する情報転送手段とを含む、請求項１又は請求項２に記載の情報検索サービス提供装置。
【請求項４】
前記代表文の各々は、属性が付与されたキーワードを含み、
前記オークション実行手段は、
属性の種類毎に、属性の値の包含関係を規定する関係情報を記憶する包含関係記憶手段と、
前記代表文の各々について、当該代表文に含まれるキーワードの属性ごとに、その属性の値を指定した入札を入札者から受ける入札手段と、
前記入札手段により属性の値を指定して行なわれる入札について、前記包含関係記憶手段に記憶された包含関係と、入札された価格とにしたがって、互いに排他的な落札範囲を指定して、各代表文の落札者を決定する落札者決定手段とを含む、請求項１〜請求項３のいずれかに記載の情報検索サービス提供装置。
【請求項５】
前記落札者決定手段は、
同じ代表文に対し、同じキーワードの属性について異なる値を指定して行なわれた複数個の入札について、指定された属性の値によりそれぞれ定まる範囲の間の包含関係を、前記包含関係記憶手段にその属性について記憶された包含関係に基づいて判定する包含関係判定手段と、
前記包含関係判定手段による包含関係の判定結果にしたがって、前記代表文に対して属性により指定される落札範囲を決定し、各落札範囲について、該当する属性の値を指定した入札の単価により落札者を決定する手段とを含む、請求項４に記載の情報検索サービス提供装置。
【請求項６】
機械可読な複数個の文を記憶する、機械可読な記憶手段に接続されるコンピュータを、
前記記憶手段に記憶された前記複数個の文を、文の間に定義される距離に基づいて複数個のクラスタに分類し、各クラスタを代表する代表文を定める代表文決定手段と、
前記代表文の各々についてオークションをオンラインで行なうことにより、前記代表文の落札者を決定するオークション実行手段と、
前記複数個の文の各々に、当該文が属するクラスタの代表文の落札価格及び落札者を関係付ける価格付与手段と、
前記複数個の文の各々について、当該文に関係付けられた落札者により指定されるＵＲＩを前記記憶手段に記憶させるＵＲＩ記憶手段と、
情報の検索要求文をオンラインで受信したことに応答して、前記記憶手段に記憶された前記複数個の文の中で、当該検索要求文との間の距離が最も近い文を検索する文検索手段と、
前記文検索手段により検索された文に対応して前記ＵＲＩ記憶手段に記憶されたＵＲＩに、前記検索要求文から生成したクエリを送信することにより、当該ＵＲＩから得られる情報を前記検索要求文を送信した端末に送信する情報送信手段として機能させる、コンピュータプログラム。
【請求項１】
機械可読な複数個の文を記憶する、機械可読な記憶手段と、
前記記憶手段に記憶された前記複数個の文を、文の間に定義される距離に基づいて複数個のクラスタに分類し、各クラスタを代表する代表文を定める代表文決定手段と、
前記代表文の各々についてオークションをオンラインで行なうことにより、前記代表文の落札者を決定するオークション実行手段と、
前記複数個の文の各々に、当該文が属するクラスタの代表文の落札価格及び落札者を関係付ける価格付与手段と、
前記複数個の文の各々について、当該文に関係付けられた落札者により指定されるＵＲＩを記憶するＵＲＩ記憶手段と、
情報の検索要求文をオンラインで受信したことに応答して、前記記憶手段に記憶された前記複数個の文の中で、当該検索要求文との間の距離が最も小さな文を検索する文検索手段と、
前記文検索手段により検索された文に対応して前記ＵＲＩ記憶手段に記憶されたＵＲＩに、前記検索要求文から生成したクエリを送信することにより、当該ＵＲＩから得られる情報を前記検索要求文を送信した端末に送信する情報送信手段とを含む、情報検索サービス提供装置。
【請求項２】
前記代表文決定手段及び前記文検索手段において行なわれる距離の計算は同じ計算方法による、請求項１に記載の情報検索サービス提供装置。
【請求項３】
前記情報送信手段は、
前記ＵＲＩ記憶手段に記憶されたＵＲＩの各々について、当該ＵＲＩに送信するクエリを生成するための、マッピングルールを記憶するマッピングルール記憶手段と、
前記文検索手段が受信した前記情報の検索要求文に対する構文解析を行なって各単語に属性を付与し、属性付検索要求文を出力する構文解析手段と、
前記文検索手段により検索された文と、当該文と関連付けられたＵＲＩに対応して前記マッピングルール記憶手段に記憶されたマッピングルールとに基づいてクエリを生成し、前記文検索手段により検索された文に対応して前記ＵＲＩ記憶手段に記憶されたＵＲＩに送信するクエリ送信手段と、
前記クエリ送信手段により送信されたクエリに対する返信を前記検索要求文を送信した端末に転送する情報転送手段とを含む、請求項１又は請求項２に記載の情報検索サービス提供装置。
【請求項４】
前記代表文の各々は、属性が付与されたキーワードを含み、
前記オークション実行手段は、
属性の種類毎に、属性の値の包含関係を規定する関係情報を記憶する包含関係記憶手段と、
前記代表文の各々について、当該代表文に含まれるキーワードの属性ごとに、その属性の値を指定した入札を入札者から受ける入札手段と、
前記入札手段により属性の値を指定して行なわれる入札について、前記包含関係記憶手段に記憶された包含関係と、入札された価格とにしたがって、互いに排他的な落札範囲を指定して、各代表文の落札者を決定する落札者決定手段とを含む、請求項１〜請求項３のいずれかに記載の情報検索サービス提供装置。
【請求項５】
前記落札者決定手段は、
同じ代表文に対し、同じキーワードの属性について異なる値を指定して行なわれた複数個の入札について、指定された属性の値によりそれぞれ定まる範囲の間の包含関係を、前記包含関係記憶手段にその属性について記憶された包含関係に基づいて判定する包含関係判定手段と、
前記包含関係判定手段による包含関係の判定結果にしたがって、前記代表文に対して属性により指定される落札範囲を決定し、各落札範囲について、該当する属性の値を指定した入札の単価により落札者を決定する手段とを含む、請求項４に記載の情報検索サービス提供装置。
【請求項６】
機械可読な複数個の文を記憶する、機械可読な記憶手段に接続されるコンピュータを、
前記記憶手段に記憶された前記複数個の文を、文の間に定義される距離に基づいて複数個のクラスタに分類し、各クラスタを代表する代表文を定める代表文決定手段と、
前記代表文の各々についてオークションをオンラインで行なうことにより、前記代表文の落札者を決定するオークション実行手段と、
前記複数個の文の各々に、当該文が属するクラスタの代表文の落札価格及び落札者を関係付ける価格付与手段と、
前記複数個の文の各々について、当該文に関係付けられた落札者により指定されるＵＲＩを前記記憶手段に記憶させるＵＲＩ記憶手段と、
情報の検索要求文をオンラインで受信したことに応答して、前記記憶手段に記憶された前記複数個の文の中で、当該検索要求文との間の距離が最も近い文を検索する文検索手段と、
前記文検索手段により検索された文に対応して前記ＵＲＩ記憶手段に記憶されたＵＲＩに、前記検索要求文から生成したクエリを送信することにより、当該ＵＲＩから得られる情報を前記検索要求文を送信した端末に送信する情報送信手段として機能させる、コンピュータプログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【公開番号】特開２０１２−１５５３５８（Ｐ２０１２−１５５３５８Ａ）
【公開日】平成２４年８月１６日（２０１２．８．１６）
【国際特許分類】
【出願番号】特願２０１１−１１０９０（Ｐ２０１１−１１０９０）
【出願日】平成２３年１月２１日（２０１１．１．２１）
【出願人】（３０１０２２４７１）独立行政法人情報通信研究機構 (1,071)
【Ｆターム（参考）】
【公開日】平成２４年８月１６日（２０１２．８．１６）
【国際特許分類】
【出願日】平成２３年１月２１日（２０１１．１．２１）
【出願人】（３０１０２２４７１）独立行政法人情報通信研究機構 (1,071)
【Ｆターム（参考）】
[ Back to top ]