以下の説明及び図面では、同一の部品には同一の参照番号を付してある。したがって、それらについての詳細な説明は繰返さない。
[第1の実施の形態]
第1の実施の形態に係る情報検索サービスシステムは、多数の自然言語文をクラスタリングして一定数のプロトタイプ文を定め、これらプロトタイプ文に対してサービス提供者がオークションにより入札するシステムである。予め自然言語文がクラスタリングされているので、入札により、自然言語文の各々をサービス提供者と対応付けることができる。検索要求を受けると、その検索要求が自然言語文のいずれに最も近いかを判定し、その自然言語文と対応付けられているサービス提供者の運営する情報提供サイトに検索要求を送信する。この検索要求に対してその情報提供サイトから返信されてくる情報を、もともとの検索要求の発信者の端末に送信する。
一方では、情報検索サービスの提供者は、プロトタイプ文のオークションにより、システムを運営するための資金を得ることができる。さらに、検索1回について所定の検索ヒット料金が得られるので、安定したビジネスとして情報検索サービスを運営できる。
他方、サービスの提供者は、プロトタイプ文を落札すると、そのプロトタイプ文に類似した検索要求については独占できる。通常の検索サービスにリストされる場合のように、多数の検索結果の中に埋もれてしまうことがなく、利用者を効率よく自己のサービス提供サイトに案内することができる。
〈構成〉
〔全体構成〕
図1を参照して、本発明の第1の実施の形態に係るシステム30は、サービスを利用する利用者の端末44と、各々がサービスサイト42を運営する複数のサイト運営者46と、インターネットを通じて端末44、複数のサイト運営者46、並びにこれらサイト運営者46の運営するサービスサイト42の各々と通信可能で、予め複数の自然言語文のコーパスをクラスタリングして得られたプロトタイプ文をサイト運営者46によるオークションにかけ、端末44から受けた検索要求について、オークション結果に従って選択したサービスサイトにクエリを生成して送信し、得られたサービス情報を端末44に返送する処理を実行する情報検索サービスシステム40とを含む。本実施の形態では、端末44からの検索要求32は音声で行なわれる。サービスサイトへのクエリ34はテキスト情報であり、サービスサイトから情報検索サービスシステム40を経て端末44に送信されるサービス情報36は、応答するサービスサイトに依存する。
情報検索サービスシステム40は、大きく分けると、端末44から音声で与えられる検索要求32に対して音声認識処理を実行し、情報検索要求文を生成する音声入力フロントエンド60と、予め収集されていた多数の自然言語文をクラスタリングし、各クラスタを代表するプロトタイプ文を複数のサイト運営者46の間のオークションにかけておき、情報検索要求に対してオークション結果にしたがった適切なサービスサイトを決定するために必要なデータベースを構築するためのオークションシステム62と、音声入力フロントエンド60の出力する検索要求に基づき、オークションシステム62により構築されたデータベースを用いてオークション結果に従って適切に選択したサービスサイトにクエリ34を送信し、当該サービスサイトから返信されてくるサービス情報36を端末44に転送する処理を行なう特定サイト検索サービス実行部66とを含む。
〔情報検索サービスシステム40の構成〕
図2を参照して、情報検索サービスシステム40は、前述したように、端末44からの音声による検索要求に対して音声認識を行ない、テキストベースの検索要求を生成する音声入力フロントエンド60と、予め多数の自然言語による質問文からなる質問文コーパスを、機械可読な形式で記憶するコーパス記憶装置64と、質問文コーパスに記憶された質問文をクラスタリングして各クラスタを代表するプロトタイプ文を決定した後、各プロトタイプ文について複数のサイト運営者46の間でオークションを行なった結果にしたがって各質問文に対応するサービスサイトを決定し、情報検索に必要なデータを生成するオークションシステム62とを含む。すなわち本実施の形態では、多数の質問文の各々についてオークションを行なうかわりに、それらをクラスタリングし、各クラスタを代表する質問文についてオークションを行なう。
オークションシステム62により生成されるデータは、質問文とその質問文の落札者が運営するサイトのURIの1例であるURL(Uniform Resource Locator)とを対にして記憶する質問文―URL対照DB68と、入力された検索要求と、その検索要求に基づいて、質問文―URL対照DB68を参照して決定されたURLに対するクエリ文を生成するためのマッピングを記憶するマッピングコーパス70とを含む。質問文―URL対照DB68及びマッピングコーパス70はいずれも記憶装置と一般的なデータベースプログラムとからなるデータベースにより実現される。
質問文―URL対照DB68に格納される情報は、コーパス記憶装置64に記憶された質問文の各々と、落札者の運営するURLとの対応関係である。
マッピングコーパス70に記憶されるのは、検索要求に含まれる単語から、その検索要求に対応して決定されたURLに対するクエリを生成する際の、単語に対するマッピングルールである。より具体的には、マッピングルールは、例えば予め「<地名>京都</地名>の<食品名>和食</食品名>の<店名>レストラン</店名>を知りたい。」というように、タグとキーワードとを含むクエリのテンプレートである。検索要求を形態素解析し、得られた形態素列の属性を得る。テンプレート中の各タグに囲まれている部分のキーワードを、そのタグと一致する、又は類似する属性の形態素の文字列で置換する。これを全てのタグについて行なうことにより、クエリが得られる。このマッピングルールは、入札者が入札時から落札時までの間に準備しておく。落札者が決定した時点で、落札された質問文に対するマッピングルールがマッピングコーパス70に格納される。
なお、上記したマッピングルールの例のうち、「京都」、「和食」など、タグで囲まれた部分のキーワードは、クエリ生成の際に検索要求から得られた単語の文字列で置換される箇所を明示するためのものであるが、そのためだけのものではない。すなわち、これらキーワードは、検索要求から得られた単語をどのキーワードと置換するかを決定する際の情報の一種としても使用される。形態素解析で得られた属性だけでなく、単語間の意味的距離をも用いてキーワードと形態素とを関係付けることにより、クエリがより高い精度で生成できる。
情報検索サービスシステム40はさらに、音声入力フロントエンド60の出力する検索要求から、コーパス記憶装置64に記憶された質問文コーパス、質問文―URL対照DB68、及びマッピングコーパス70に記憶されたマッピングルールを用いて、その質問文が属するクラスタのプロトタイプ文の落札者の運営するサイトに対し、その質問文から生成されたクエリを送信し、得られた情報を、検索要求送信者のサービス利用端末48(多くの場合、端末44と一致する。)に対して送信する処理を行なう特定サイト検索サービス実行部66と、特定サイト検索サービス実行部66の実行したクエリの結果を検索ログとして記憶し、この検索ログと、オークションシステム62によるオークションの結果(質問文の落札単価)とを用いてオークション落札者に対する請求処理を行なうための課金処理部72とを含む。
音声入力フロントエンド60は、端末44においてコードブックを用いてコード化され送信された音声信号をオンラインで受信し、コードブックを用いて音声データを復元するコード受信部80と、コード受信部80により復元された音声データから、音声認識のために必要な特徴量を算出する特徴量算出部82と、特徴量算出部82により算出された特徴量を用いて音声認識を行ない、認識結果のテキストデータを認識結果として出力する音声認識装置84とを含む。特徴量算出部82が復元する特徴量は、音声認識装置84の仕様により決定されるが、例えば所定フレーム庁及び所定シフト長のフレーム毎に算出されるMFCC,ΔMFCC,パワーなどである。本実施の形態では、情報検索サービスシステム40を利用するのは、特定のものだけでなく、一般的な利用者であることが想定されている。したがって音声認識装置84は、一般的な話者の音声認識が可能である必要がある。もちろん、利用者が特定の集団に限定されていることが分かっているならば、たとえば話者同定の仕組みを音声認識装置84の前段に加え、音声認識装置84ではその話者の音声の音声認識に適した音響モデルを利用するようにしてもよい。
オークションシステム62は、コーパス記憶装置64に記憶された質問文コーパスを構成する多数の質問文をクラスタリングし、クラスタごとに、その中心となるプロトタイプ文を、クラスタ番号とともに出力するクラスタリング処理部100と、クラスタリング処理部100から出力されるプロトタイプ文とクラスタ番号とを記憶するプロトタイプ記憶部102とを含む。なお、クラスタリング処理部100は、クラスタリング時に、コーパス記憶装置64に記憶された各質問文に、その質問文が属するクラスタ番号を付す処理も実行する。
オークションシステム62はさらに、プロトタイプ記憶部102に記憶されたプロトタイプ文の各々を複数のサイト運営者46によるオンラインのオークションにかける処理を実行するオークション実行部104と、システムの運用時刻を管理するためのタイマ110と、タイマ110から得られる時刻情報に基づき、オークション実行部104により実行されるオークションの開始及び終了と、オークション結果を用いた特定サイト検索サービス実行部66による特定サイト検索サービスの運営とを管理するためのオークション管理部108と、オークション実行部104がオークションを実行するために必要なデータを記憶するオークションデータDB106とを含む。
オークションシステム62はさらに、オークションデータDB106、オークション管理部108、質問文―URL対照DB68、マッピングコーパス70、及び課金処理部72に接続され、オークション実行部104により実行されるオークションの終了日時に到達すると、オークション管理部108の管理の下、オークションデータDB106に記憶された情報に基づいて、各プロトタイプ文の落札者と落札価格とを決定し、その結果にしたがって質問文―URL対照DB68、マッピングコーパス70、及び課金処理部72による請求先の情報を更新する更新部112を含む。質問文─URL対照DB68は、各質問文について、その質問文が属するクラスタの代表文を落札した落札者の運営するサイトのURL(後述する入札者テーブルに記録されている。)と、その質問文とを関係付ける情報を記憶するためのものである。なお、オークションの落札日時と、落札結果を用いたオークションの開始日時とは通常一致しない。オークション終了後、例えば2週間後からその結果を用いた特定サイト検索サービスが開始される。したがって、更新部112による質問文―URL対照DB68、マッピングコーパス70及び課金処理部72の更新結果は直ちに特定サイト検索サービスに反映されるわけではない。更新部112による更新は、新たなデータを作成することであり、特定サイト検索サービスの開始日時に、それらが以前のデータを置換することになる。図及び説明を簡単にするため、図面にはこうした更新と実際の運用開始との間の時間的ズレを管理するための機構は示していない。
特定サイト検索サービス実行部66は、音声認識装置84の出力する検索要求に対する形態素解析、意味辞書による意味タグの付与、及び構文解析などを行ない、意味タグ、品詞タグなどの属性がそれぞれ付された形態素列を出力する質問文解析部130と、これら形態素列により表される検索要求との間の距離が最も小さな質問文をコーパス記憶装置64に記憶された質問文コーパスの中で検索し取出し、その属するクラスタ番号を解析後の検索要求とともに出力するための質問文検索部132とを含む。この検索では、例えば品詞、文中での出現箇所、係り受け関係、品詞などを全て考慮して、正規化された質問文特徴ベクトルを作成し、特徴ベクトル間の内積の値が最も大きな質問文を選択する、などの方法を用いればよい。本実施の形態では、質問文のクラスタリングの際に用いられた距離計算の方法と、質問文検索部132により用いられる距離計算の方法とは、同じ方法であるものとする。
特定サイト検索サービス実行部66はさらに、質問文検索部132により選択された質問文のクラスタ番号に基づき、その質問文を落札したサイト運営者のサービスサイトのURLを質問文―URL対照DB68において検索し、解析後の検索要求とともに出力するためのURL検索部134と、URL検索部134から出力されるURL及び解析後の検索要求、並びにマッピングコーパス70にそのURLに対応して記憶されているマッピングルールに基づいて、クエリを生成し、URLとともに出力するためのクエリ生成部136と、クエリ生成部136により出力されたクエリと、クエリ生成部136により出力されたURLとから、情報検索のためのURL文を生成してインターネット上に送信するクエリ発行部138と、クエリ発行部138が送信したクエリに応答して、サービスサイト42から送信されてきた情報をサービス利用端末48に転送し、同時に検索ログを課金処理部72に対して出力するためのクエリ結果送信部140とを含む。
課金処理部72は、クエリ結果送信部140から出力される検索ログを蓄積するための検索ログ記憶部150と、検索ログ記憶部150に記憶された検索ログを定期的に読出し、検索対象となったサイトの検索回数にオークション結果にしたがった単価を乗じた金額を、各サイトの運営者(オークション落札者50)に請求する処理を実行するための請求処理部152とを含む。
図3を参照して、クラスタリング処理部100が実行するクラスタリング処理の概念について説明する。コーパス記憶装置64には、主としてインターネット上から収集された多数の質問文が記憶されている。本実施の形態に係る情報検索サービスシステム40では、音声で与えられる検索要求の各々について、これら質問文の内で最も近い距離にあるものを特定し、その質問文について予め落札していたサイト運営者のサイトにその検索要求を送信する。したがって、準備処理として、各質問文についてオークションで1検索あたりの単価を定めて、その質問文に近い検索要求が発生したときには、オークションでのその質問文の落札者の運営するサイトにその検索要求を転送する。そのような検索が発生するたびに、その質問文に付けられていた単価にしたがった料金をいわば広告料と同様にして情報検索サービスシステム40の運営者が落札者から受取る。これが情報検索サービスシステム40を運営していくための資金となる。
ただし、質問文は大量である上、時々刻々と増加する。したがって、それら質問文の各々についてオークションを行なうのは現実的ではない。そこで本実施の形態では、それら多数の質問文を予め複数のクラスタに分類する。クラスタリングの手法として使用される手法は、特に特定のものに限定されるわけではない。各質問文が必ず1つのクラスタに、かつ1つのクラスタのみに属するような手法であればどのようなものでもよい。しかし、本実施の形態では、検索要求に対して最も小さな距離にあるプロトタイプを特定する必要があるため、質問文の間の距離に相当する評価関数を何らかの形で定義し、その距離を基準に質問文をクラスタリングする手法を用いることが望ましい。なお、クラスタ数は、クラスタごとにオークションにかける関係上、予め固定されていることが望ましい。もちろん、クラスタ数が固定されていなければならないわけではなく、オークションごとに変化してもよい。要するに、情報検索サービスシステム40の運営上で都合のよい数をクラスタの数として選択すればよい。
図3を参照して、これら多数の質問文の集合160を、1点鎖線で示されるように複数のクラスタに分割する。通常のクラスタリング手法を用いると、各クラスタについてそのセントロイド(重心)が決定される。本実施の形態では、各クラスタのセントロイドに最も近い質問文をそのクラスタのプロトタイプとし、このプロトタイプ文でそのクラスタに属する全質問文を代表させる。図2に示すクラスタリング処理部100は、このようにしてプロトタイプを決定してプロトタイプ集合162を形成し、プロトタイプ記憶部102に記憶させる機能を持つ。各質問文には、どのクラスタに属するかを示す情報が付される。
図4を参照して、オークション実行部104は、サイトの運営者の端末からのhttpリクエストを処理するウェブサーバ190と、ウェブサーバ190と連携し、ウェブサーバ190が受信したhttpリクエストのうち、オークションに関係するリクエストについて、当該リクエストにより決定されるプログラムを読出して実行する、プログラムの実行処理系からなる実行処理部192とを含む。実行処理部192は、CPUなどの図示しないコンピュータハードウェアが、実行処理系のプログラムを実行することにより実現される。
オークション実行部104はさらに、実行処理部192によりhttpリクエスト内のプログラム指定にしたがって呼出されて実行され、オークションデータDB106内の各種のテーブルを更新したり、各テーブルからデータを読出したりして、処理結果を実行処理部192及びウェブサーバ190を介してhttpリクエストの送信元に返信する、ログオン処理部194、問合処理部196、入札処理部198、登録情報保守部200、落札情報表示部202、及びマッピング管理部204を含む。これらの機能については後述する。
ウェブサーバ190は、サイト管理者の端末から送信されてくるhttpリクエストを受信するためのリクエスト受信部210と、リクエスト受信部210が受信したhttpリクエストのURLに含まれる情報を解析することにより、ログオン処理部194、問合処理部196、入札処理部198、登録情報保守部200、落札情報表示部202及びマッピング管理部204のいずれを起動すべきかを決定し、実行処理部192にその情報を与えるための実行系呼出部212と、httpリクエストを処理した後、ログオン処理部194などから送信されてくる処理結果のhtml書類からなるレスポンスをサイト運営者の端末に送信するレスポンス送信部214とを含む。
オークションデータDB106は、入札者の基本的情報を記憶する入札者テーブル170、プロトタイプに関する情報を記憶するプロトタイプテーブル172、主として進行中のオークションを管理するための基本的情報を記憶するオークションマスタテーブル174、入札の明細を記憶する入札明細テーブル176、オークションの落札に関連する情報を記憶する落札情報テーブル178、及び、各入札者が、自己の入札したプロトタイプに関連して予め作成するマッピングルールを記憶するマッピングコーパステーブル180を含む。
図5を参照して、例えば入札者テーブル170のレコード250は、このサービスに対する入札を行なう可能性のあるサイト運営者を一意に識別するように割当てられる入札者IDと、入札者の氏名又は名称と、入札者の住所と、入札者の管理するサービスサイトのURL及びそのサービス名と、請求関係の情報(締日、請求書の宛先等)と、ログオンのためのパスワードと、落札結果などの連絡の際に用いられる電子メールアドレスとを含む。サイト運営者からログオン要求があった場合、入札者テーブル170の入札者ID及びパスワードによりサイト運営者のログオン情報を認証することができる。なお、図5に示す以外に、例えばサイト運営者の運営責任者、電話番号、ファクシミリ番号などを記録するようにしても良いが、本実施の形態ではそれらに関する情報を使用しないため、図5及び以後の説明ではそれらについては言及しない。
プロトタイプテーブル172のレコード252は、各プロトタイプに対し一意に割当てられるプロトタイプIDと、そのプロトタイプIDに対応する質問文の、質問文コーパス内におけるID(質問文ID)と、そのプロトタイプにより代表されるクラスタに含まれる質問文数と、当該クラスタに属する質問文のリストの先頭及び最後尾へのポインタからなるクラスタ文リストと、このプロトタイプが落札されたか否かを示す入札完了フラグとを含む。
オークションマスタテーブル174のレコード254は、各オークションに対して一意に割当てられるオークションIDと、オークションのウェブサイトに表示されるオークション名称と、オークションの開始時期及び終了時期と、当該オークションに基づく特定サイト検索サービスの運用開始時期及び終了時期と、このレコードに対応するオークションの入札が完了したか否かを示すオークション完了フラグと、このオークションの結果に基づく特定サイト運用サービスの運用が終了したか否かを示す運用完了フラグと、このオークションが有効か否か(現在運用されているか否か)を示す運用開始フラグとを含む。オークションの開始時期及び終了時期は、各プロトタイプに対するサイト運営者の入札許可期間の開始時期及び終了時期をそれぞれ示す。オークション完了フラグがオンの場合、このオークションの各プロトタイプが落札され、運用の準備ができたことを示す。運用完了フラグがオンの場合、このオークションの結果を用いた特定検索サービスの運用が終了したことを示す。運用完了フラグがオフの場合、このオークションの結果を用いたサービスの運用がまだ完了していないことを示す。運用開始フラグがオンのときは、このレコードにより示されるオークションの落札結果にしたがって、特定検索サービスが運用されていることを示す。仮に運用開始フラグがオフであれば、現在日時が運用開始時期及び運用終了時期の間であっても、このレコードに対応するオークションの落札結果にしたがった特定サイト検索サービスは運用されない。
入札明細テーブル176のレコード256は、関係するオークションのオークションIDと、入札対象のプロトタイプのプロトタイプIDと、入札日時と、入札者IDと、入札単価と、落札フラグとを含む。落札フラグは、レコードが作成されるときにオフに初期化される。
再び図4を参照して、ログオン処理部194は、入札者テーブル170を参照して、サイト運営者がこのオークションシステムにログオンしてよいか否か、いつログオフしたか、などを管理する。ログオン処理部194による処理は、有料、無料を問わずユーザ登録が必要なシステムで行なわれている処理と同様である。
問合処理部196は、このオークションシステムにログオンしているサイト運営者から、進行中のオークションに関する問合せがあったことに応答して、プロトタイプテーブル172、オークションマスタテーブル174及び入札明細テーブル176を参照し、問合せがあった情報を示すhtml文書を作成して実行処理部192に与える処理を実行するためのものである。問合処理部196の処理も、データの内容に相違はあるものの、データベースを参照してダイナミックにhtml文書を作成するウェブサーバで通常実行されているものと同様の手法を用いて実現できる。
入札処理部198は、サイト運用者から、特定のプロトタイプを指定して入札の入力があったときに、その内容が正しいか否かを検査し、正しいときのみ入札明細テーブル176に入札明細レコードを新たに作成する処理を行なう。入札の入力が正しくないときには入力を拒否する。実際には、後述するように、入札処理は問合処理部196による問合せの後に行なわれる。問合処理部196が作成するhtml書類中に、入札データの整合性を保証するようなスクリプトを記述しておくことにより、入札処理部198が受取る入札データは基本的に正当なものであることが想定される。
図6に、問合処理部196により表示される入札初期画面230の例を示す。図6に示す画面は、サイト運営者がこのシステムにログオンした後、オークションを指定して問合処理を開始させることにより、問合処理部196により作成され、サイト運営者の端末のブラウザに表示される。
図6を参照して、質問文入札の初期画面では、プロトタイプ文がID順に表示される。既に入札があったプロトタイプ文については、「最高値」の欄に入札の最高値が表示される。特定のプロトタイプ文に対する入札を行なう場合、サイト運営者は「ビッドする」という見出しの欄に表示されるチェックボックスのうち、入札しようとするプロトタイプ文の行のチェックボックスにチェックを入れ、入札単価を入力する。プロトタイプ文の内容、プロトタイプ文により代表されるクラスタに含まれる質問文の数などを知りたいときには、「詳細」ボタン240を押すと、新たなウィンドウ又はタブにそのプロトタイプ文により代表されるクラスタの詳細がプロトタイプテーブル172の該当レコードに基づいて表示される。
図6の入札初期画面230の最も下部に表示されている「戻る」ボタンを押すと、オークション選択の画面が表示される。「入札する」ボタンを押すと、ユーザの入力が入札処理部198に送信され、チェックされる。チェックの結果、入力が正当であれば入札明細テーブル176に入力明細が追加される。チェックの結果、入力が正当でないときにはエラーメッセージと共に図6と同様の画面が再度表示される。この場合、誤りとなった箇所が例えば反転して、又は赤いフォントで、表示される。本実施の形態では、誤りがあった場合には、入力のいずれについても入札明細テーブル176への追加は行なわれない。
登録情報保守部200は、入札者テーブル170に記憶されているサイト運営者の情報を保守するためのものである。サイト運営者は、当然のことながら自分に関する情報しか保守することができない。登録情報保守部200の機能も、既存のシステムで通常実現されているものと同様である。
落札情報表示部202は、既に落札が完了したオークションの内容についての問合せを処理するためのものである。本実施の形態では、落札情報表示部202は発明の本質的部分とは無関係なので、その詳細についてはここでは説明しない。
マッピング管理部204は、入札者が、自分の入札したプロトタイプを処理するためのマッピングルールを入力したり、保守したりするためのものである。その処理内容は通常のデータベースのレコードの保守と同様であり、保守の対象がマッピングルールである点のみが異なる。したがってここではマッピング管理部204の詳細については説明しない。
オークション管理部108は、タイマ110の出力に応答して、定期的にオークションデータDB106のオークションマスタテーブル174をチェックしており、オークション開始時期に到達したオークションであって、オークション開始フラグがオフのものがあれば、そのオークションIDを指定して、更新部112に対し、当該オークションを開始させる指示を出す。オークション管理部108はまた、同様にして、運用開始時期に到達したオークションであって、運用開始フラグがオフのものがあれば、そのオークションIDを指定して、更新部112に対し特定サイト検索サービスの切替を指示する機能を持つ。
図7を参照して、更新部112の構成について説明する。更新部112は、図2に示すオークション管理部108から特定のオークションを完了する指示を受けたことに応答して、指定されたオークションIDを持ち、オークション完了フラグがオン、運用開始フラグがオフ、運用完了フラグがオフ、かつ現在時刻が運用開始時期と運用終了時期との間にあるレコードの運用開始フラグをオンに更新するオークションマスタ更新部260と、オークション管理部108から特定のオークションを完了させる指示を受けたことに応答して、入札明細テーブル176を検査し、各プロトタイプに対する落札者を決定する処理と、指定されたオークションの各プロトタイプの落札者が決定されたときに、オークションマスタテーブル174内の、指定されたオークションに対応するレコードのオークション完了フラグをオンに更新する処理と、落札結果を落札情報テーブル178に出力する処理とを実行する落札処理部262とを含む。
オークションデータDB106はさらに、落札処理部262による落札処理が完了したことに応答して、入札者テーブル170、オークションマスタテーブル174、及び落札情報テーブル178にそれぞれ記憶された情報に基づいて、各プロトタイプの落札者に対し落札結果を通知する落札通知処理部264と、オークション管理部108から、オークションIDを指定して、特定サイト検索サービスの運用を、当該オークションIDのオークションの落札結果に基づく運用に切替る指示を受けたことに応答して、質問文―URL対照DB68及びマッピングコーパス70の内容を落札情報テーブル178及びマッピングコーパステーブル180の内容にしたがって更新する運用DB更新部266とを含む。
運用DB更新部266は具体的には、オークション管理部108から運用の切替の指示を受けると、オークションマスタテーブル174のうち、運用開始フラグがオン、かつ運用完了フラグがオフのレコードの運用完了フラグをオンに更新する。運用DB更新部266はさらに、オークション管理部108により指定されたオークションIDを持ち、オークション完了フラグがオン、運用開始フラグがオフ、かつ運用完了フラグもオフであるレコードの運用開始フラグをオンに更新する処理を実行する。運用DB更新部266はこれに加えて、落札情報テーブル178に基づいて質問文―URL対照DB68を落札結果にあわせて書替え、マッピングコーパステーブル180に記録されたマッピングルールの中から、プロトタイプ文ごとに、落札者により準備されていたマッピングルールのみを抽出してマッピングコーパス70を書き換える。
図8を参照して、本実施の形態に係る情報検索サービスシステム40によるオークションに参加するサイト運営者の端末画面は、その状態により様々な状態に遷移する。サイト運営者がこのオークションの行なわれているサイトに接続し、ログオンに成功すると、先頭ページ280が表示される。図示しないが、先頭ページ280では、オークションへの参加と、落札結果の問合せとの2つの選択肢が示される。オークションへの参加が選択されると画面はオークション選択ページ282に遷移する。落札結果の問合せが選択されたときにも、画面はオークション選択ページ292に遷移する。これらオークション選択ページ282及び292は、その名称は同じだが、前者が現在開催されているオークションを選択するものであるのに対し、後者は既に落札され、終了しているオークションを選択するものである点が異なっている。
オークション選択ページ282では、図示しないが、現在開催されているオークションの一覧が表示される。この画面はオークションマスタテーブル174を参照することにより作成できる。この画面では、各オークションの詳細表示の選択肢と、各オークションに含まれるプロトタイプの一覧表示との選択肢が表示される。各オークションの詳細表示が選択されると、画面はオークション詳細情報表示284に遷移する。プロトタイプの一覧表示が選択されるとプロトタイプ別入札情報一覧表示画面286が表示される。
オークション詳細情報表示284では、指定されたオークションIDのレコードをオークションマスタテーブル174から読出し、その詳細が表示される。この画面で「戻る」ボタンを押すと画面はオークション選択ページ282に戻る。
プロトタイプ別入札情報一覧表示画面286は、図6に示す入札初期画面230のことをいう。図6に示す「詳細」ボタン240を押すと、該当するプロトタイプに関する詳細を表示するプロトタイプ別詳細表示画面288に表示が遷移する。プロトタイプ別詳細表示画面288には、図示しない「戻る」ボタンと「オークション選択ページに戻る」ボタンとが表示される。これらを押すと、表示はプロトタイプ別入札情報一覧表示画面286又はオークション選択ページ282に遷移する。
図6に示すプロトタイプ別入札情報一覧表示画面286で「入札する」ボタンを押すと、前記したように入札内容が入札処理部198によりチェックされる。入札内容が正当であれば、入札更新処理290が実行され、入札後の情報にしたがってプロトタイプ別入札情報一覧表示画面286が更新される。入札内容が正当でなければ、エラーメッセージとともに、入力時のプロトタイプ別入札情報一覧表示画面286が再度表示される。
〈プログラム構造〉
─落札処理─
図4に示す各処理部は、既存の技術を転用することにより容易に実現できる。以下、図7に示す落札処理部262及び落札通知処理部264を実現するプログラムの制御構造を説明する。ここでは、オークションIDが指定され、特定のオークションIDのデータについて落札処理する場合について説明する。
図9を参照して、この落札処理プログラムは、入札明細テーブル176から、指定されたオークションIDを持ち、入札完了フラグがオフのプロトタイプ番号ごとに、最高入札単価の入札明細を読出すステップ310と、ステップ310で読み出された全明細に対し、以下のステップ314を繰返すステップ312とを含む。
ステップ314は、処理対象の入札明細の落札フラグをセットするステップ340と、プロトタイプテーブル172のうち、その入札明細のプロトタイプIDと一致するプロトタイプIDを持つレコードの入札完了フラグをセットするステップ342とを含む。
このプログラムはさらに、ステップ312に続いて実行され、入札明細テーブル176から落札フラグがオンの明細を入札者ID順及びプロトタイプ順で読出すステップ316と、落札者に対する落札結果の通知である電子メールを作成し、発送するステップ318と、プロトタイプテーブル172から、指定されたオークションIDを持ち、入札完了フラグがオフのレコードを全て読出すステップ320と、ステップ320で読み出されたレコードの件数が0か否かを判定し、判定結果にしたがって制御の流れを分岐させるステップ322とを含む。
ステップ322の判定が肯定の場合、全てのプロトタイプが落札されたということであり、制御はステップ324に進む。ステップ324では、オークションマスタテーブル174の、指定されたオークションIDのレコードのオークション完了フラグが1にセットされる。続いてステップ326でオークション完了のメッセージをシステム出力に出力して処理を終了する。
ステップ322の判定が否定の場合、落札されてないプロトタイプが存在するということである。ステップ328でオークション未完のメッセージをシステム出力に出力し、処理を終了する。システム管理者はこの場合、落札されていないプロトタイプのみについて改めてオークションを開催することができる。何度かオークションを行なっても落札されないプロトコルが存在する場合、オークション自体は完了させ、このプロトタイプにより代表されるクラスタ内の質問文に類似する検索要求を受信した場合には、特定のサイトにクエリを発行する処理を行なわず、一般的な検索サイトに検索要求をそのまま転送し、得られた検索結果を検索要求の送信者に返信するような処理を実行するようにしてもよい。
〔プログラム構造〕
特定サイト検索サービスを実現するプログラムの制御構造について説明する。これから説明する処理は、図2に示すURL検索部134のうち、質問文解析部130の後に行なわれる処理に相当する。したがってこのプログラムは、検索要求のテキスト列であって、構文解析後の形態素列を受けたことに応答して起動する。
図10を参照して、このプログラムは、有効フラグがオンのレコードをオークションマスタテーブル174において検索することにより、現在運営されているオークションを決定するステップ360と、受信した検索要求の形態素列と、コーパス記憶装置64に記憶された全質問文との間の距離を算出するステップ362と、ステップ362の処理結果を受け、検索要求との距離が最も小さな質問文を選択するステップ364と、ステップ364の処理で選択された質問文が属するクラスタのプロトタイプを選択するステップ366と、ステップ364で選択された質問文又はステップ366で選択されたプロトタイプと関連付けられているURLを質問文―URL対照DB68から、検索されたURLと関連付けられているマッピングコーパスをマッピングコーパス70から、それぞれ検索するステップ368とを含む。本実施の形態では、質問文に対応するURLが質問文―URL対照DB68に記憶されていればそのURLを用い、そうでない場合にはステップ366で選択されたプロトタイプに対応するURLを用いる。マッピングコーパス70には、質問文―URL対照DB68に記憶されているURLに対するクエリ文を作成するためのマッピングルールが記憶されていることが前提となる。
このプログラムはさらに、ステップ368に続き、ステップ366及びステップ368で検索されたURL及びマッピングルールと、質問文解析部130から受けた構文解析後の検索要求とを用い、マッピングルール内のキーワード部分を検索要求内の対応する単語で置換することによりクエリ文を生成するステップ370と、このクエリ文とステップ368で検索されたURLとを組合せることによりクエリ要求をインターネット上に送出する(発行する)ステップ372と、ステップ372で発行されたクエリ要求に対するレスポンスを受信し、最初の検索要求を送信してきた端末に転送するステップ374と、以上の一連の処理について、請求に必要な情報を含むアクセスログを出力して一連の処理を終了するステップ376とを含む。本実施の形態では、検索要求が与えられるたびに図10に示されるプログラムの実行が開始され、レスポンスを返すと終了する。
〈動作〉
以上に構成を説明した情報検索サービスシステム40は以下のように動作する。この情報検索サービスシステム40を含むシステム30の動作は、一つのオークションについて見ると大きく3つのフェーズに分割される。第1のフェーズはオークションの準備フェーズである。第2のフェーズはオークションフェーズである。第3のフェーズはオークションの結果に基づく特定サイト検索サービスの運用フェーズである。以下、順番に説明する。
─オークションの準備フェーズ─
オークションを開始するに先立ち、入札者テーブル170及びオークションマスタテーブル174には、オークション開催に必要な情報が記憶される。入札者テーブル170には、オークションごとではなく、情報検索サービスシステム40によるサービスによりユーザを自分のサイトに誘導しようとするサイトの運営者がウェブを通じて自己の情報を登録する。オークションマスタテーブル174には、情報検索サービスシステム40の運営者がオークションを管理するために必要な情報を予めオークションごとに登録する。
プロトタイプテーブル172、入札明細テーブル176、落札情報テーブル178、及びマッピングコーパステーブル180はオークション開始前にクリアされる。
情報検索サービスシステム40の運営者は、予め多数の質問文をインターネット上から収集し、コーパス記憶装置64にコーパスとして記憶させる。各質問文には互いを識別するための一意名質問文IDが割当てられる。クラスタリング処理部100は、このコーパスに含まれる質問文を所定数のクラスタに分類し、各クラスタについてプロトタイプ文を決定する。クラスタにはクラスタ番号が割当てられる。決定されたプロトタイプ文は、対応するクラスタのクラスタ番号及びそのプロトタイプの質問文IDとともにプロトタイプ記憶部102に記憶される。これらプロトタイプにアクセスするための情報は図4に示すプロトタイプテーブル172に記憶される。本実施の形態では、プロトタイプには、その質問文IDとは別のプロトタイプIDが割当てられる。
─オークションフェーズ─
オークションの準備ができると、情報検索サービスシステム40は何らかのメディアを通じてオークションの開始を複数のサイト運営者46に通知する。興味を持ったサイト運営者はオークションの内容について調べることになる。これは問合処理部196により処理される。
問合処理部196は、図8に示す遷移図にしたがってサイト運営者46の端末に表示される画面を制御する。図8に示す各画面のうち、プロトタイプ別入札情報一覧表示画面286(図6)において、サイト運営者が入札の操作をすると、入札処理部198により入力内容がチェックされる。入札内容が正当であれば、入札更新処理290が実行され、入札明細テーブル176に入札の明細が追加される。さらに、入札後の情報にしたがってプロトタイプ別入札情報一覧表示画面286が更新される。入札内容が正当でなければ、エラーメッセージとともに、入力時のプロトタイプ別入札情報一覧表示画面286が再度表示される。
なお、オークションは、オークションマスタテーブル174に記憶されたオークションの開始時期にならなければ開始されない。また、オークションマスタテーブル174に記憶された終了時期になると終了する。オークションの開催時期以外の時期には、図6に示す画面は表示されず、入札もできなくなる。仮にそのような時期に何らかの原因で入札がされたとしても、入札内容がエラーであるとして入札が拒否される。
このようにして、入札明細テーブル176には、複数のサイト運営者46による入札明細が蓄積される。この入札処理では、あるプロトタイプについて、既に付けられている単価よりも高い単価をつけない限り、入札内容が正当でないとして拒否される。本実施の形態でのプロトタイプの入札の処理自体は、通常行なわれているオークションの技術をそのまま転用できる。
なお、このオークションに入札したサイト運営者は、自分が入札したプロトタイプについて、クエリ文を作成するためのマッピングルールをマッピングコーパステーブル180に追加できる。各マッピングルールは、入札されたプロトタイプ文のプロトタイプID及び入札者IDと関連付けてマッピングコーパステーブル180に蓄積される。
開催されているオークションについて、オークションマスタテーブル174中の該当レコードの終了時期に到達すると、落札処理部262は、落札処理を開始する。
落札処理では落札処理部262は、落札情報テーブル178から、プロトタイプごとに最も単価の高い入札明細を抽出する(図9のステップ310)。抽出された全ての明細に対し、入札明細テーブル176内のその明細に対応するレコードの落札フラグをセットし(ステップ340)、プロトタイプテーブル172中の、その明細中のプロトタイプIDに対応するレコードの入札完了フラグをオンに更新する(ステップ342)。
ステップ310で抽出された全ての入札明細に対し、ステップ340及びステップ342の処理が完了すると、再び入札明細テーブル176から落札フラグがオンの明細を入札者ID順、プロトタイプID順に読出す(ステップ316)。これらのレコードの入札者IDにより示される入札者が各プロトタイプの落札者である。ステップ318で、各落札者に対し、落札内容の通知メールを生成し、送信する。このとき、落札情報テーブル178に、落札内容のレコードを追加する。
続いて、プロトタイプテーブル172から、該当するオークションIDを持ち入札完了フラグがオフのレコードを読出し(ステップ320)、その件数が0か否かを判定する。件数が0であれば全てのプロトタイプについて落札が完了したということであるので、オークションマスタのオークション完了フラグをセットし(ステップ324)、オークション完了のメッセージをシステム出力に出力して処理を終了する。ステップ320で読出されたレコードの件数が0でなければ、有効な入札がなかったプロトタイプ文が存在するということである。この場合にはオークション未完のメッセージとともにそれらプロトタイプ文を特定する情報をシステム出力に出力して(ステップ328)処理を終了する。
オークション管理者は、オークションが未完の場合には、再度、入札がなかったプロトタイプの入札を行なうことができる。全てのプロトタイプが落札されれば問題ないが、一部のプロトタイプについて落札者が最後までない場合には、それらプロトタイプと、そのプロトタイプのクラスタに属する質問文とに特定の情報を付しておく。オークションで、それら質問文に近い検索要求が来た場合の処理については後述する。
落札処理が完了すると、落札情報が落札情報テーブル178に保持されている。
─運用フェーズ─
図2に示すオークション管理部108は、タイマ110の出力に基づいてオークションデータDB106の内容を常にチェックし、オークションの運用開始時期に到達したオークションであって、オークション開始フラグ及びオークション完了フラグが共にオン、運用開始フラグ及び運用完了フラグがともにオフのものがあるか否かを調べる。そのようなオークションがあれば、オークション管理部108は、そのオークションについて、オークションマスタ更新部260及び運用DB更新部266に対し、オークションの運用の切替の指示を発行する。
オークションマスタ更新部260はこの指示を受けると、オークションマスタテーブル174の該当するレコード254の運用開始フラグをオンに更新する。
運用DB更新部266は、この指示を受けると、落札情報テーブル178の記憶内容に基づいて質問文―URL対照DB68及びマッピングコーパス70の内容を更新する。具体的には、各プロトタイプを入札したサイト運営者の、入札者テーブル170のレコードからURLを読出し、そのプロトタイプのクラスタに属する各質問文と、読み出されたURLとを関係付けて質問文―URL対照DB68に保存する。単にプロトタイプIDとURLとを関係付けた情報を質問文―URL対照DB68に記憶させるようにしてもよい。この場合、質問文―URL対照DB68の容量を小さくできる。ただしこの場合には、検索要求を受けたときに、その検索要求との距離が最も小さな質問文を特定した後、その質問文が属するクラスタのプロトタイプを特定してからでないと質問文―URL対照DB68からURLを読出すことができず、応答性が多少悪くなる可能性がある。
運用DB更新部266はまた、各プロトタイプについて、マッピングコーパステーブル180に各質問文に関連付けて記憶されているマッピングルールのうち、そのプロトタイプの落札者によるもののみを選択してマッピングコーパス70に転記する。
なお、本実施の形態では、この転記は運用の切替時に行なわれるので、落札後、運用開始までの間にも落札者がマッピングルールを追加することができる。ただし、そのような処理を禁止することもできる。そのような場合、マッピングコーパステーブル180からマッピングコーパス70への転記を、オークションの落札時に行なうようにしてもよい。
運用が開始されると情報検索サービスシステム40は以下のように動作する。端末44は本実施の形態では携帯電話であることが想定されている。端末44のユーザは、情報検索サービスシステム40のサービスを利用するためのウェブページにアクセスし、検索要求を音声で入力する。端末44上は、通常の携帯電話の処理と同様、入力音声をコードブックを用いてコード化し、情報検索サービスシステム40のコード受信部80に送信する。
コード受信部80は、受信した一連のコードからコードブックを用いてもとの音声データを復元し、特徴量算出部82に与える。特徴量算出部82は、この音声データをフレーム化し、各フレームから所定の音響特徴量を算出して音声認識装置84に与える。音声認識装置84は、通常の音声認識装置として動作し、検索要求に対応するテキストデータを生成して質問文解析部130に与える。
質問文解析部130はこの検索要求のテキストデータを受けると、そのデータにより表される文章(ここでは日本語が想定している。)に対する形態素解析、構文解析、意味解析などの処理を行なって形態素列を生成し質問文検索部132に与える。各形態素には、質問文解析部130の処理の結果、品詞タグ、階層的な意味タグなど、質問文検索に必要な情報がタグとして付されている。
質問文検索部132は、コーパス記憶装置64に記憶されている各質問文と、質問文解析部130から与えられる検索要求の形態素列との間の距離を計算し、検索要求との距離が最短である質問文を特定し、その質問文IDをURL検索部134に検索要求とともに与える。
URL検索部134は、与えられた質問文IDに基づいて質問文―URL対照DB68から対応するURLを読出す。クエリ生成部136は、この質問文又はプロトタイプ文に対応してマッピングコーパス70に記憶されているマッピングルールを読出す。クエリ生成部136はさらに、検索要求、URL,及びマッピングルールに基づいてクエリを生成し、クエリ発行部138に与える。クエリ発行部138は、このクエリをインターネット上に送信し、当該クエリはURLにより指定されるサービスサイト42に送信される。
サービスサイト42では、このクエリについては予め準備されていたマッピングルールに基づくものであるため、高い精度でクエリに対応する応答(HTML文書)を生成し、クエリ発行部138に返信してくる。クエリ発行部138は、受信したHTML文書をクエリ結果送信部140に与える。
クエリ結果送信部140は、クエリ発行部138から与えられたHTML文書をサービス利用端末48に転送する。このとき転送されるHTML文書は、あたかもサービスサイト42から直接サービス利用端末48に返信されたようにサービス利用端末48上で表示されるようにすることが望ましい。クエリ結果送信部140は、クエリ結果の送信をするたびに、その内容を検索ログとして検索ログ記憶部150に保存する。検索ログとしては、各落札者に対する請求ができる程度の情報を保存するだけでよいが、検索ログから得られる統計的情報をさらに落札者に提供する場合には、目的にあわせた情報を検索ログに記録することが望ましい。
1請求期間が経過すると、請求処理部152は検索ログ記憶部150からその請求期間内に行なわれた検索の検索ログを検索ログ記憶部150から抽出する。請求処理部152はさらに、抽出された検索ログについて、その検索の際に用いられたプロトタイプIDから、そのプロトタイプの落札者及びその落札単価を特定し、落札者毎に集計して、検索ログから得た、請求金額の計算の基礎データとともに請求書を送付する。全ての落札者に対してこの処理が終了すると、請求処理の終了に伴う処理を行なう。
以上のように本実施の形態によれば、質問文コーパスを構成する、非常に大きな数の質問文について、実質的に個別にオークションにかけることができる。落札者は、落札した質問文については、その質問文に類似した情報要求があれば、その情報要求に対して自分が運営するサイト又は自分が関係するサイトからの情報を応答として要求者の端末に返信する処理を独占的に行なうことができる。落札者は、自己のサイトで提供するサービスが利用される機会を効率的に得ることができるという効果がある。
情報要求者の立場から言うと、従来のように一旦検索サイトで情報を検索した後、提示されたリストの中から自分の必要とする情報を選ぶ、というスタイルではなく、入力した情報検索のための質問文に類似した質問文の落札者の運営するサイトで提供されるサービスに直ちにアクセスできる。質問文は、質問文に含まれるキーワードの属性により異なるサイト運営者により落札されるので、情報の検索要求ごとに適切なサービスを提供するサイト運営者のサイトの情報を直接得ることができる。したがって、検索結果の一覧から情報を選択するという手間を省くことができる。
[第2の実施の形態]
〈構成〉
上に説明した第1の実施の形態では、質問文が互いに重複しない複数のクラスタに分類されることを前提としている。そのようにシステムを構成することにより、システムの構造を簡略なものとすることができる。
しかし、オークションでは、そのように互いに排他的な値をとる属性により質問文を分類するだけでなく、重層的な分類を許す必要が生じることも考えられる。例えば、プロトタイプ文のみを指定して入札するのではなく、プロトタイプ文にさらに情報検索要求の属性に基づいて特定サイトにその検索要求を誘導する場合である。例えば、飲食店に関する検索要求について、地域を指定せず「レストラン」を属性に選択する場合と、特定地域(例えば大阪府内、京都市内など)のみを指定して「レストラン」を属性に選択する場合とを考える。両者は一方の選択地域が他方の選択地域を包含する形となっている。この場合、地域を指定しない入札者と、特定地域のみを指定した入札者とがあれば、それらは、特定地域については互いに競合するが、それ以外の地域では特に競合はしない。だとすれば、これらの入札者の間でも何らかの形でオークションを成立させ、かつ特定サイト検索サービスの運営者にとっての利益も極大化できれば好ましい。
本実施の形態ではそのような形でのオークションを可能とする。そのために本実施の形態では、意味的辞書と同様の形式で、ツリー状の属性ツリーを予め準備し、このツリーにより属性の包含関係を調べる。同じ種類の属性について、互いに包含関係にある2つの値が指定され、単価を除いた他の条件が同一の2以上の入札が発生した場合、その種類の属性の属性ツリー上で下位にある値の属性範囲についてはいずれか単価が高いものが落札することとし、属性ツリー上で上位にある値の属性範囲については、その値を指定して入札したものが落札することとする。
例えば、下位の属性値を指定した入札者の入札単価の方が上位の属性値を指定した入札者の入札単価よりも高い場合、その下位の値を指定して入札者がその範囲については落札し、上位の属性値を指定した入札者はその値により指定される範囲の内、下位の値により定まる範囲を除外した部分のみ落札するようにする。上位の属性値を指定した入札者の入札単価の方が下位の属性値を指定した入札者の入札単価よりも高い場合、その属性値により定まる範囲の全体について、上位の値を指定したものが落札する。
このようにすることにより、例えばビジネスとして限定された範囲を対象としているサイト運営者はある属性について、その限定された範囲のみを比較的高値で入札し落札することにより、自分のビジネスを有利に運営することができる。ビジネスとして広い範囲を対象としているサイト運営者は、広い範囲については比較的低い入札単価で落札する機会を持つことができ、かつ競合する範囲については他の入札者でより高い入札単価を示したものに譲ることも、その範囲のみを指定してより高い単価で入札することもできる。オークションに参加するサイト運営者にとって、自己のビジネスが対象とする範囲に応じた戦略にしたがって入札を行なうことができる。その結果、オークションがより活性化される可能性が高くなる。
図11に、この第2の実施の形態に係る情報検索サービスシステム400の概略構成を示す。図11に示す情報検索サービスシステム400は、図2に示す情報検索サービスシステム40に代えて用いることができる。
図11に示す情報検索サービスシステム400が情報検索サービスシステム40と異なるのは、オークションシステム62に代えて上記したような重層的な属性値でのオークションを可能にする機能を持つオークションシステム404を含む点、及び、特定サイト検索サービス実行部66に代えて、そうした重層的なオークションの落札結果にしたがって情報の検索要求を適切なサービスサイト42に誘導する機能を持つ特定サイト検索サービス実行部406を含む点である。
オークションシステム404はオークションシステム62と同様の構成を持つが、上記した属性ツリーを記憶するための属性ツリー記憶部422を新たに含む点と、オークションシステム62で用いられたオークション関連のデータについて、重層的な分類を許容する形式のデータとなるように修正したデータを記憶する、図2に示すオークションデータDB106に相当するオークションデータDB426を含む点と、同様に重層的な分類を許容する形でのオークション処理と落札処理及び特定サイト検索サービスの切替処理とをそれぞれ実行するオークション実行部420及び更新部424を含む点とにおいて、図2に示すオークションシステム62と異なっている。なお、図11に示すオークション実行部420は図2に示すオークション実行部104に、更新部424は図2に示す更新部112に、それぞれ相当する。
図12に、オークションデータDB426のテーブルのうち、プロトタイプテーブルのレコード440と、入札明細テーブルのレコード442との構成を示す。
プロトタイプテーブルのレコード440は、第1の実施の形態のプロトタイプテーブル172のレコード252(図5参照)に加え、第1及び第2の属性の値を保持する2つのフィールドを持つ。入札明細テーブルのレコード442は、第1の実施の形態の入札明細テーブル176のレコード256に加え、入札時に入札者がプロトタイプ文の属性についてそれぞれ選択した属性値を格納する、第1及び第2の属性特定情報フィールドを持つ。
〔画面構成及び画面遷移〕
図13を参照して、この第2の実施の形態に係る情報検索サービスシステム400が運営するオークションに対し、入札者が質問文入札の際の問合せをしたときの入札初期画面450では、プロトタイプ文と、その入札に関連する簡単な情報とが明細行としてプロトタイプID順に表示される。
各明細行は、プロトタイプ文に対する入札の詳細を表示させるための右向きの三角形と、プロトタイプに振られた番号(「番号」欄)と、プロトタイプ文(「代表文」欄)と、そのプロトタイプ文に対する入札数(「入札有無」欄)と、この画面を表示させているユーザによる入札がそのプロトタイプ文に対し行なわれているか否かを示す情報(「応札」欄)と、プロトタイプに関する詳細(図12に示すプロトタイプテーブルのレコード440の内容)を表示させるための詳細ボタンとを含む。
各明細行の左端の右向き三角をユーザがクリックすると、その明細についての入札の内容が表示される。このときの画面を図14に示す。以下に説明する画面の画面遷移は、クライアント側のみで行なわれる処理による画面遷移と、クライアントからサーバに対してその都度入力データを送信し、サーバでの処理により生成された画面データをクライアントに返信することによる画面遷移との双方を適切に組合せて実現することができる。
図14に示す画面は、番号=1のプロトタイプの右三角形がクリックされたときの画面である。番号=1のプロトタイプの行の左端の右向き三角形が下向き三角形に変化し、入札内容が展開されて下部に表示される。図14に示す例では、番号=1のプロトタイプに対しては4つの入札がある。これらがそれぞれ別々の入札明細表示行として表示されている。
このプロトタイプには2つの属性を適用するためのフィールドがある。この例では、第1の属性は「地名」であり、第2の属性は「飲食店」である。すなわち、このプロトタイプ文には属性が付与されたキーワードが2つ存在している。
各入札明細表示行は、その入札明細の内で、落札の可能性があるもののみを示している。すなわちこの例では、現時点では4人のユーザが別々に落札可能である。
各入札明細表示行は、その入札明細表示に割当てられた番号(「1.1」など)と、プロトタイプ文の第1及び第2の属性に対して、入札者が指定した値(「属性名1」欄及び「属性名2」欄)と、入札価格(「最高入札価格」欄)とを含む。属性の指定値が異なる場合、別々の入札者が落札できる。競合する入札者の場合には、落札可能な単価をつけたものの入札の内容のみがここに表示される。
各入札明細表示行はさらに、この画面を現在操作しているユーザがこの入札明細と単価を除いて同じ条件で入札するかどうかを指定するための「応札」欄と、応札する場合の単価を入札する「単価」欄とを含む。応札欄にはプルダウンメニューがデフォルトで(応札)「しない」が表示される。このメニューで「する」を選択すると「単価」の入力が可能になる。このときの表示を、例えば図15の画面454内の1番目のプロトタイプに対する4番目の入札明細行により示す。いずれかの入札明細に関する入札を行ない「入札する」ボタンを押すと、入札内容がサーバに送られ、入札明細の追加が行なわれる。
なお本実施の形態では、単価として既に入札されている最高入札価格よりも高い金額でなければ入札はできないようにする。属性について、同じ値の属性でより価格の高い入札があれば、その前に表示されていた入札明細は画面上で削除される。しかし、既に属性値についてある値を指定してある単価での入札がされていたところに、属性の値としてより狭い範囲のものを指定した、より単価の高い入札があった場合には、新たな入札が追加されるが、元から存在していた入札明細も残る。新たな入札により指定された範囲以外の部分については、その前に最高価格で入札していた明細が有効と考えられるためである。属性によりどのような範囲が指定されたかについては、後述する属性ツリーにより判定する。
図14において、1番目のプロトタイプに対する1番目の入札は、第1の属性(地名)及び第2の属性の双方について指定せず、4.2円を入札単価としたものである。2番目の入札は、地名として「東京都」を指定し、飲食店として「ラーメン」を指定した、5.30円を入札単価としたものである。この2番目の入札は1番目の入札よりも後にされたもので、1番目の入札よりも狭い範囲を指定した、より高い単価のものである。したがって2番目の入札が追加されると共に、1番目の入札も、2番目の入札により指定された範囲以外の範囲を指定したものとして、残っている。
3番目の入札は、地名として霞ヶ関、飲食店の種類としてラーメンを指定した、5.32円を入札単価とするものである。これも2番目の入札よりもより狭い範囲を指定した、より高い単価のものであるので有効である。同時に、「霞ヶ関」以外の地域で「ラーメン」を指定した部分については、2番目の入札が依然として有効なので、2番目の入札もまだ残っている。
4番目の入札は、地名として「大阪市」を、飲食店の種類として「ラーメン」を、それぞれ指定した、単価4.40円のものである。この入札は、1番目の入札とは部分的に競合するが、2番目及び3番目の入札とは競合しない。1番目の入札に対して、指定した属性により定まる範囲はこちらの方が狭い。したがってこの入札も有効である。
以上から、1番目のプロトタイプ文に対する1番目の入札はこの状態でも依然として有効であるが、ただしその範囲としては、飲食店の種類としてラーメンについては地名の全範囲から東京都と大阪市とを除いた範囲で有効であり、ラーメン以外については、地名の全範囲について有効なものとして残っている。2番目の入札については、飲食店の種類としてラーメンで、かつ地名としては東京都の範囲内で、ただし霞ヶ関を除く部分についてのみ有効なものとして残っている。
図14に示す例では、1番目のプロトタイプの4番目の入札明細行(最後の入札明細行)について、その左端にプラスマークが表示されている。このプラスマークをクリックすると、新たな入札明細行が画面上に表示され、ユーザが2つの属性及び単価を指定して、このプロトタイプ文に対する新たな入札を行なうことができる。このときの表示状態を図16の画面456の、1番目のプロトタイプに対する5番目の入札明細行により示す。
本実施の形態では、指定できる属性の種類、及びその値については予めサーバで属性ツリーとして準備しているものに限定されていることが前提である。新たな入札の入力時には、プルダウンメニューにそれら許されるもののみが表示され、その中からユーザの希望するものを選ぶものとする。
例えば図16に示す状態で単価を指定して「入札する」ボタンを押すと、入札情報がサーバに送られ、その処理の結果の画面458が図17に示すように表示される。この例では、このユーザが新たな属性を指定して第1のプロトタイプに対する入札を追加し、かつ4番目の入札明細行についてはより高い単価で入札をした。その結果、第1のプロトタイプに対する入札数は全部で5となり、その中でこのユーザによるものが2となる。したがってその内容に対応する表示が第1のプロトタイプの明細行の入札有無欄に「あり(5)」として、応札欄に「あり(2)」として、それぞれ示されている。
仮に図17に示す画面458で第1のプロトタイプの明細行の左端の右向きの三角形をクリックすると、図14に示す場合と同様、第1のプロトタイプに対する入札明細行の表示画面460が図18に示すように表示される。ただしこの例では、端末を操作しているユーザによる入札が2つあるため、それらは他の入札と区別して画面上、強調表示される。例えば文字色を変えたり、背景色を変えたり、反転表示したり、特定のマークを入札明細行に追加表示したりすることが考えられる。
〔属性ツリー〕
図19を参照して、図11の属性ツリー記憶部422に記憶される属性ツリー470は、予め属性ごとに準備される。図19に示す属性ツリー470は、地域に関するものである。この例では、属性ツリー470は、日本全体を示すルートノードと、ルートノードから分岐する、日本全体を東北・北海道、関東・甲信越、東海、北陸などの第1の階層に分割した第1階層のノードと、第1階層のノードの各々から分岐し、そのノードにより表される地域をより細かく、例えば県単位に分割した第2階層のノードと、さらに第2階層のノードの各々から分岐する第3階層のノードと、などを含む。階層の数及びどの範囲で各ノードにより表される地域を分割するかは、システムの設計により容易に定めることができる。
なお、この例では地名に関する属性ツリーで、ルートノードにより日本全国が表されるものとしたが、もちろん本実施の形態の地名に属する属性ツリーがそのようなものに限定されるわけではない。より広く、アジア全体、又は世界全体を分割するような属性ツリーでもよい。
この属性ツリーは、属性に関して重複する入札を許し、かつそれらについていずれが有効かを明確に判定するため、ノードの上下関係が明確になるような構成を持つ。あるノードは、ルートノードを除き必ず1つだけ親ノードを持ち、同じノードから分岐する同じ階層に属するノードは、互いに異なる範囲を指定する。
このノードで、ある階層のノードを指定した入札がある場合、そのノードより下位のノードを指定した入札で、より高価な単価を指定した入札をすることが可能である。その場合、既存の入札については、新たな入札により指定された以外の範囲についてのみ有効となる。
ある階層のノードを指定した入札がある場合、そのノードより上位のノードを指定した入札も可能であるが、この場合には単価は新たに指定されたノードをルートノードとする部分ツリーを指定したいずれの入札に対しても、より高い単価を指定しなければならない。そのような条件が満たされれば、新たな入札が有効となり、その下のノードを指定した入札は全て無効となる。
属性ツリーでは、同じ階層のノードの間では、そのノードに対応する値により指定される範囲は重複せず、ある階層のノードの値により指定される範囲は、そのノードから分岐する全てのノードの値により指定される範囲を包含する。すなわち、属性ツリーは、ある種類の属性について、その属性の値の間の包含関係をツリー形式で表現したものである。
〔プログラム構造〕
図20を参照して、入札初期画面の表示要求を端末から受けたサーバで実行されるプログラムの制御構造を説明する。このプログラムは、プロトタイプID,第1の属性特定情報、及び第2の属性特定情報ごとに、最高入札単価の入札明細を入札明細テーブルで検索するステップ480と、現在のオークション対象となっているオークションのレコードをオークションマスタテーブルから読出し、入札初期画面のヘッダ部分を作成するステップ482と、以下に説明するプロトタイプ明細作成ルーチン486を各プロトタイプについて実行するステップ484と、「戻る」ボタン及び「入札する」ボタンを含むボトム部分を作成するステップ488とを含む。
プロトタイプ明細作成ルーチン486は、処理対象のプロトタイプについて、プロトタイプの明細行を作成するステップ490と、ステップ480で読出された入札明細のうち、処理対象のプロトタイプのIDをプロトタイプIDとして持つ全ての入札明細について以下の入札明細行作成ルーチン494を実行するステップ492とを含む。
入札明細行作成ルーチン494は、処理対象の入札明細行が、処理対象のプロトタイプ文に関する最後の入札明細行か否かを判定し、判定結果に応じて制御の流れを分岐させるステップ500と、ステップ500の判定が肯定のときに、入札明細の追加を指示するための追加ボタン(図14などに示すプラスボタン)を作成するステップ502と、ステップ500の判定が否定のとき、又はステップ500の判定が肯定でステップ502の処理が完了したときに実行され、処理対象の入札明細の入札者IDが、入札初期画面の表示要求を送信してきたユーザの入札者IDと一致するか否かを判定し、判定結果に応じて制御の流れを分岐させるステップ504とを含む。
入札明細行作成ルーチン494はさらに、ステップ504の判定が肯定のときに実行され、入札者用の、強調表示された入札明細行を作成してこのルーチンの実行を終了させるステップ508と、ステップ504の判定が否定のときに実行され、通常の入札明細行を作成してこのルーチンの実行を終了させるステップ506とを含む。
図21を参照して、ユーザが端末で「入札する」というボタンを押すことにより送信されてきた情報を処理するためのサーバプログラムは、以下のような制御構造を持つ。
このプログラムは、入札処理後に表示される画面のヘッダを作成するステップ510と、入力される入札明細に誤りがあるか否かを判定するためのエラーフラグを0に設定するステップ512と、端末から送信されてきた入札明細について、以下に説明する入札チェックルーチン516を実行するステップ514と、ステップ514の処理の後に実行され、エラーフラグが0か否かを判定し、判定結果にしたがって制御の流れを分岐させるステップ518とを含む。
本実施の形態では、基本的には端末での入札が過去の入札データに対して正当なものか否かについての判定を、端末での入力時点で端末において行なう。その判定結果をパスしたものが入力サーバに送信されてくる。したがって、基本的にはサーバでのこのようなチェックはしなくても、入力に誤りがある可能性は低い。しかし、端末でのチェックは、入札初期画面の表示要求をサーバが受信したときの入札明細に基づいて行なわれる。そのため、同一のプロトタイプに対して競合するような入札が2以上の入札者からほぼ同時に行なわれることもないとはいえない。そこで、本実施の形態では、念のために入札チェックルーチン516を実行し、万が一、互いに競合するような入札があった場合でもチェックできるようにする。
入札チェックルーチン516は、処理対象の入札明細に対応するプロトタイプに関する情報を表示するプロトタイプ行を作成するステップ530と、処理対象の入札明細に関する応札が端末からなされたか否かを判定して制御の流れを分岐させるステップ532と、ステップ532の判定が肯定のときに、処理対象の入札明細をチェックするステップ534と、ステップ534での判定結果にしたがって、表示される画面の入札明細行を作成して処理を終了するステップ536とを含む。ステップ532の判定が否定のときには入札チェックルーチン516の実行は終了する。ステップ534の処理内容については図22を参照して後述する。
このプログラムはさらに、ステップ518の判定が肯定の時に実行され、端末から受信した、応札のあった各行について、入力内容に対応した入札明細レコードを作成し入札明細テーブルに追加するステップ522を実行するステップ520と、ステップ518の判定が否定のときに実行され、エラーメッセージを出力するステップ524と、ステップ522の後、及びステップ524の後に実行され、表示画面のボトム部分を作成して処理を終了するステップ526とを含む。
図22を参照して、図21のステップ534で実行される入札明細行のチェック処理のルーチンは以下のような制御構造を持つ。すなわちこのルーチンは、チェック対象となっている入札明細行の第1及び第2の属性が空白か否かに応じて、制御の流れを分岐させるステップ540と、第1及び第2の属性がともに空白のときに実行され、処理対象の入札明細行と同一プロトタイプID,第1及び第2の属性が空白の入札明細レコードを入札明細テーブルで検索し、その最高単価を調べるステップ542と、第1の属性が非空白で、第2の属性が空白のときに実行され、処理対象の入札明細行と同一プロトタイプID、第2の属性が空白、第1の属性として第1の属性の入力値を包含する(属性ツリー上で第1の属性の入力値より上位のノードで、かつそのノードをルートノードとする部分木内に第1の属性の入力値に対応するノードを含むもの)ような値を持つ入札明細レコードを入札明細テーブルで検索し、その単価の最高値を取出すステップ544とを含む。
このルーチンはさらに、第1の属性が空白で第2の属性が非空白であるときに実行され、入札明細行と同一プロトコルID,第1の属性が空白、第2の属性として第2の属性の入力値を包含する(属性ツリー上で第2の属性の入力値より上位のノードで、かつそのノードをルートノードとする部分木内に第2の属性の入力値に対応するノードを含むもの)ような値を持つ入札明細レコードを入札明細テーブルで検索し、その単価の最高値を取出すステップ546と、第1及び第2の属性の双方とも非空白のときに実行され、入札明細行と同一プロトコルID,第1の属性として第1の属性の入力値を包含するような値を持ち、第2の属性として第2の属性の入力値を包含するような値を持つ入札明細レコードを入札明細テーブルで検索し、その単価の最高値を取出すステップ548とを含む。
このルーチンはさらに、ステップ542,544,546及び548に続き、入力された入札明細の入札単価が、これらステップで検索された入札明細レコードの単価より大きいか否かを判定し、判定結果により制御の流れを分岐させるステップ550と、ステップ550の判定結果が肯定のときに、処理対象の入札明細行に応じた通常行のデータを作成し出力して処理をこのルーチンの実行を終了するステップ552と、ステップ550の判定が否定の時に実行され、エラーフラグを1に設定するステップ554と、ステップ554に続き、処理対象の入札明細行に応じてエラー行のデータを作成して出力し、このルーチンの実行を終了するステップ556とを含む。
図23を参照して、第2の実施の形態のサーバにおいて行なわれる落札処理を実現するプログラムは以下のような制御構造を持つ。すなわち、このプログラムは入札明細テーブルから入札完了フラグがオフのレコードについて、プロトタイプID,第1及び第2の属性値の組合せごとに、最高入札単価の入札明細レコードを抽出するステップ560と、ステップ560で抽出された全明細に対して図9に示したものと同じ処理を実行するステップ312と、ステップ312に続き、入札明細テーブルから、落札フラグがオンの明細を入札者ID順及びプロトタイプID順で読出すステップ562とを含む。このステップ562で読み出された明細の各々が落札者を決定する。これら落札明細のレコードは落札情報テーブル178に追加される。
このプログラムはさらに、ステップ562において読み出された入札明細により決定された落札者の各々について、落札結果を作成し発送するステップ564と、ステップ564の後、図9に示すものと同じ処理を実行して処理を終了するステップ322〜ステップ328とを含む。
図24を参照して、本実施の形態に係る特定サイト検索サービス実行部406が情報検索要求を受信したときに、特定サイト検索サービス実行部406で実行されるプログラムの制御構造について説明する。なお、以下の説明は、特定サイト検索サービス実行部406の内で質問文検索部132以後の各モジュールに関するものである。
このプログラムは、図10を参照して既に説明したものと同じ処理を実行するステップ360〜ステップ366と、ステップ366の後、ステップ366で選択されたプロトタイプについて、そのプロトタイプ中の記載に基づいて第1及び第2の属性ツリーを属性ツリー記憶部422から読出すステップ580とを含む。なお、このステップでは、入札明細行の属性の値が空白のときには属性ツリーの読出は行なわず、以下の処理でもそれらについての処理は行なわない。ただし以下の説明及び図面では説明を分かりやすくするため、属性の値が空白であったときの処理については説明しない。
このプログラムはさらに、ステップ580に続き、選択されたプロトタイプのプロトタイプIDと、入札明細行の第1の属性値を包含する第1の属性値であって、ツリー内のレベルが最も低いノードに対応する値とを持つ落札明細レコードを落札情報テーブルから検索するステップ582と、ステップ582に続き、ステップ582で検索された落札明細の中から、選択されたプロトタイプのプロトタイプIDと、入札明細行の第2の属性値を包含する第2の属性値であって、ツリー内のレベルが最も低いノードに対応する値とを持つ落札明細レコードを抽出するステップ584と、図10を参照して既に説明したものと同じ処理をそれぞれ実行して処理を終了するステップ368〜ステップ376とを含む。
〈動作〉
上記した第2の実施の形態に係る情報検索サービスシステム400は以下のように動作する。この情報検索サービスシステム400の場合にも、動作フェーズは3つある。第1のフェーズはオークションの準備フェーズである。第2のフェーズはオークションフェーズである。第3のフェーズはオークションの結果に基づく特定サイト検索サービスの運用フェーズである。
オークションの準備フェーズは、第1の実施の形態と基本的に同様である。ただし、プロトタイプには第1及び第2の属性の値が(もしあれば)キーワードとともにタグ付けされる。また、それら属性の各種類について、属性ツリーが予め作成され、機械可読な属性ツリー記憶部422に機械可読な形式で記憶される。
オークション開始時になると、オークション管理部108の制御により、オークション実行部420が所定のオークションを開始する。開催中のオークションに関する入札初期画面の表示要求をオークション入札者402がオークションシステム404に与えると、オークション実行部420は以下のように動作する。
オークション実行部420は、開催中のオークションに関する入札初期画面450(図13参照)を作成し、入札者の端末に表示させる。この入札初期画面450には、以下の処理を全て実行するために必要な情報と、スクリプトとが含まれる。入札者がいずれかのプロトタイプの明細行の先頭の右向き三角をクリックすると、端末は右向き三角がクリックされたときのスクリプトを実行し、図14に示す画面452と同様の画面を表示する。この画面で入札者が「戻る」を押すと画面は再び図13に示すものに戻る。このとき、端末内での処理だけではなく、サーバで入札初期画面450を作り直すようにすると好ましい。
図14に示す画面452で入札者が応札「する」を選択したり、明細の追加を選択したりすると、端末はそれぞれ対応のスクリプトを実行し、例えば図16の画面456を表示する。必要な入力を行なった後、入札者が「入札する」ボタンを押すと、入札明細行に関する情報がオークション実行部420に送信される。オークション実行部420は応札があると、その内容についてチェックし、エラーがなければ入札明細テーブルに入札内容を追加する。エラーがあれば入札内容を入札明細テーブルに追加することなく、エラー画面を端末に表示させる。
このような処理を繰返し、オークションの終了時期になるとオークション管理部108は、更新部424を制御して落札処理を行なう。落札処理では、更新部424は属性ツリー記憶部422に格納された属性ツリーを参照しながら、プロトタイプID、第1の属性値、及び第2の属性値の組合せごとに最高単価の入札明細レコードを入札明細テーブルから抽出し、落札情報テーブルに落札明細レコードとして追加する。更新部424は、第1の実施の場合と同様、質問文―URL対照DB408及びマッピングコーパス410についても落札結果に応じて更新する。落札結果はさらに、請求処理部152にも与えられる。請求処理部152は後の請求処理に必要な情報(単価情報など)を記憶する。
オークションフェーズでは情報検索サービスシステム400(特に特定サイト検索サービス実行部406)は以下のように動作する。オークションについて落札処理が完了し、オークションの開始時期に到達すると、オークション管理部108はオークション管理部108はそのオークションの運用開始フラグをオンにセットする。
端末44から音声により情報の検索要求が来ると、音声入力フロントエンド60は第1の実施の形態と同様の処理でこの検索要求を文字列に変換し質問文解析部130に与え、質問文解析部130はこの文字列に対する形態素解析などの処理を行ない、それぞれ意味的タグ及び品詞タグが付された形態素列を質問文検索部132に与える。質問文検索部132は、この形態素列とコーパス記憶装置64に含まれる各質問文との間の距離を計算し、入力された形態素列との間の距離が最も小さな質問文を抽出し、URL検索部430に与える。URL検索部430は与えられた質問文に対応するURLを質問文―URL対照DB408から読出し、情報検索要求の形態素列と共にクエリ生成部432に与える。クエリ生成部432は、マッピングコーパス410から、選択された質問文に対応するマッピングコーパスを読出し、与えられた形態素列からキーワードを抽出し、マッピングコーパス内のキーワードに相当する位置に挿入してクエリを作成する。作成されたクエリはクエリ発行部138に与えられ、URL検索部430が読出したURLを指定してサービスサイト42に送信される。サービスサイト42から返信されてくる情報はクエリ発行部138を経てクエリ結果送信部140に与えられる。クエリ結果送信部140は、最初に情報の検索要求を送信してきたサービス利用端末48に対し、クエリ結果を送信する。クエリ結果送信部140は同時に、検索ログを検索ログ記憶部150に書出す。
情報検索サービスシステム400は、受信した情報検索要求に対して以上のような処理を繰返す。この結果、情報検索要求の各々について、その情報検索要求に最も近い質問文がコーパス記憶装置64から読み出され、その質問文が属するクラスタのプロトタイプを落札したサイト運営者に対する情報のクエリが行なわれる。クエリの結果は情報検索要求の発行者に戻される。その結果、情報検索要求を発行した利用者は、検索結果の単なる一覧ではなく、オークションにより落札した、情報検索要求に対する適切な情報を提供するサービス提供者のサービスに直接誘導される。その結果、利用者が必要な情報を入手する際の手間を少なくすることができる。サイトの運営者は、自分の運営するサイトにとって最も有効となるような範囲を属性として指定してプロトタイプ文を落札することで、潜在的な顧客を自己のサイトに誘導できる。狭い地域のみを対象とするようなサイトの場合には、その狭い地域について比較的高い単価でプロトタイプを落札できる。広い地域を対象とするサイトの場合、広い地域を指定して、比較的安い単価で入札することができる。
なお、上記実施の形態では、先に高い単価で入札した入札明細が存在する場合には、後からたとえそれより広い範囲を指定するものであっても、より高い単価で入札しなければならない。しかし本発明はそのような実施の形態には限定されず、例えば後からある属性についてより広い範囲を指定して入札する場合、既に存在するより高い単価の入札明細により指定された範囲以外を指定して入札できるようにしてもよい。
[第3の実施の形態]
上記した第1及び第2の実施の形態では、情報の検索要求(質問文)に類似する質問文、又は情報検索要求に含まれるキーワードに基づいて、その検索要求をどのサイトに転送するかを決めている。そして、その転送の仕方を、質問文コーパスをクラスタリングした結果に基づき、クラスタごとにオークションで決めている。しかし本発明はそのような実施の形態のみに限定されるわけではない。例えば属性が数値により表現される場合には、その属性の値が取りえる範囲をいくつかの数値範囲に分けてオークションにかけることが可能である。以下に説明する第3の実施の形態は、数値範囲に分けることができる属性として、情報の検索要求が発せられた端末の現在位置(GPS位置)が属する範囲により、オークション対象を分割するというものである。
なお、数値で表すことができる属性が位置情報に限定されないことは当然である。例えば温度、湿度、濃度、年齢、身長、体重、暦年、値段など、数値で表すことができる属性であれば、いずれもある範囲に分割し、それら範囲ごとにオークションにかけることができる。
本実施の形態では、第2の実施の形態と同様、指定する範囲を予め属性ツリーと同様の構造に階層的なツリー構造で分類しておく。そうすることにより、第2の実施の形態と同じ論理を用いて数値範囲を指定したオークションを実現することができる。
図25に、この実施の形態における入札初期画面600の例を示す。図25を参照して、この入札初期画面600は、基本的には図13に示す入札初期画面450と同様である。この画面でプロトタイプの明細行の左端に表示されている右向き三角形をクリックすると画面は図26に示す入札明細行表示画面602に遷移する。
図26を参照して、入札明細行表示画面602では、指定されたプロトタイプの明細行の左端の三角が下向きとなり、その行の下部に、その行のプロトタイプに関する入札明細行が展開して表示される。図26に示す入札明細行表示画面602は、図14に示す画面452と同様であるが、属性として属性名1のみが指定されている点が異なる。これは、ここでの第1のプロトタイプで指定されているのが属性名1のみであり、かつその内容が情報検索要求の位置情報となっていることによるものである。情報検索要求に付随して送信されてくる位置情報としては、端末に備えられたGPSから得られるものが想定されている。
本実施の形態で特徴的なのは、この第1の属性として、単語等ではなく、地図を用いた範囲による指定が行なわれている点である。図26に示す例では、指定された範囲が地図として各入札明細行の属性の欄に表示される。これら各範囲については、その横に「範囲を確認」ボタンが表示されており、このボタンを押すと、別ウィンドウに、指定された範囲をより大きく表す地図が表示される。
以下、既にある入札明細について、応札する場合の処理は既に説明したものと同様である。
新たな入札を行なう場合には、このプロトコルに対応する入札明細行の内の最下行の左端に表示されたプラスマークをクリックすると、図27に示す画面604に遷移する。画面604は、第2の実施形態の図16に示したものと同様である。ただし、属性を指定するために「範囲を設定」ボタンが表示されている点が異なる。
図28に、「範囲を設定」ボタンを押したときに表示される画面606の例を示す。図28に示す例では、画面606に重ねて、地図上の矩形を規定する2点(左上及び右下)を指定するウィンドウ620が表示される。本実施の形態では日本全図が最初に表示され、左側に示される拡大・縮小ボタン及び倍率変更ボタンと、地図のドラッグとにより自分の指定しようとする範囲を表示させ、指定して「OK」ボタンを押すことで、選択する地域を指定することができる。ただし本実施の形態では、既に説明したように、選択できる範囲は予め階層的な複数個の領域に分割されており、そのうちの一つのみしか選択することはできない。このような区分の仕方を採用することで、オークションのロジックを簡単にし、第2の実施の形態と同様のプログラムで本実施の形態のシステムを実現することができる。
図28に示す画面606で範囲を指定して「OK」を押すと、図27の画面と同様の画面に戻る。この画面でさらに「入札する」ボタンを押すと、第2の実施の形態と同様、サーバで入札明細のチェックが行なわれ、エラーがなければ、図29に示すように、入札結果を反映した画面608が表示される。
これ以外の点で、この第3の実施の形態に係るシステムの動作は第2の実施の形態と同様である。したがってここでは第3の実施の形態のシステムについての詳細は繰返さない。
[コンピュータによる実現]
以上に説明した第1〜第3の実施の形態に係る情報検索サービスシステム40及び情報検索サービスシステム400などは、同様のハードウェア構成を持つ。例えば情報検索サービスシステム40は、インターネットを介して他の装置と通信する機能を持つコンピュータハードウェアと、そのコンピュータハードウェアにより実行されるプログラムと、コンピュータハードウェアに格納されるデータとにより実現できる。プログラムの主要な部分の制御構造については図9及び図10、並びに図20〜図24に示し、データ構造の例は図5及び図12に示した。
図30を参照して、この情報検索サーバコンピュータ630は、FD(フレキシブルディスク)ドライブ652及びCD−ROM(コンパクトディスク読出専用メモリ)ドライブ650を有するコンピュータ640と、キーボード646と、マウス648と、モニタ642とを含む。
図31を参照して、コンピュータ640は、FDドライブ652及びCD−ROMドライブ650に加えて、CPU(中央処理装置)656と、CPU656、FDドライブ652及びCD−ROMドライブ650に接続されたバス666と、ブートアッププログラム等を記憶する読出専用メモリ(ROM)658と、バス666に接続され、プログラム命令、システムプログラム、及び作業データ等を記憶するランダムアクセスメモリ(RAM)660とを含む。情報検索サーバコンピュータ630はさらに、インターネットへの接続を提供するネットワークインターフェイス(I/F)644を含む。図示しないが、コンピュータ640はネットワークI/F644を介して携帯電話ネットワークと接続されており、他の端末とデータ通信を行なうことができる。
情報検索サーバコンピュータ630に情報検索サービスシステム40又は400としての動作を行なわせるためのコンピュータプログラムは、CD−ROMドライブ650又はFDドライブ652に挿入されるCD−ROM662又はFD664に記憶され、さらにハードディスク654に転送される。又は、プログラムは図示しないネットワークを通じてコンピュータ640に送信されハードディスク654に記憶されてもよい。プログラムは実行の際にRAM660にロードされる。CD−ROM662から、FD664から、又はネットワークを介して、直接にRAM660にプログラムをロードしてもよい。
このプログラムは、コンピュータ640をこの実施の形態の情報検索サービスシステム40又は400として機能させる複数の命令を含む。この動作を行なわせるのに必要な基本的機能のいくつかはコンピュータ640上で動作するオペレーティングシステム(OS)もしくはサードパーティのプログラム、又はコンピュータ640にインストールされる各種ツールキットのモジュールにより提供される。従って、このプログラムはこの実施の形態のシステム及び方法を実現するのに必要な機能全てを必ずしも含まなくてよい。このプログラムは、命令のうち、所望の結果が得られるように制御されたやり方で適切な機能又は「ツール」を呼出すことにより、上記した情報検索サービスシステム40又は400としての動作を実行する命令のみを含んでいればよい。
情報検索サーバコンピュータ630は一般的なコンピュータにより実現される。コンピュータ一般の動作は周知であるので、ここではその詳細は繰返さない。
今回開示された実施の形態は単に例示であって、本発明が上記した実施の形態のみに制限されるわけではない。本発明の範囲は、発明の詳細な説明の記載を参酌した上で、特許請求の範囲の各請求項によって示され、そこに記載された文言と均等の意味及び範囲内での全ての変更を含む。