JP2004504654A

JP2004504654A - ウェブに基づく情報の変換に使用されるルールのプログラミングによらない開発システムおよび方法

Info

Publication number: JP2004504654A
Application number: JP2001569657A
Authority: JP
Inventors: カリエレ　スティーブン　ジェロミー; ウッズ　スティーブン　グレゴリー; セリンク　マーティン　ピー　エイ
Original assignee: クアック．コム
Priority date: 2000-03-21
Filing date: 2001-03-16
Publication date: 2004-02-12
Also published as: CN1427971A; WO2001071538A3; WO2001071538A2; EP1287447A2; AU2001252909A1

Abstract

【課題】インターネットからの情報への迅速で正確な音声アクセスを無料で取得し得るシステムおよび方法を提供すること。
【解決手段】プログラミングによらない手段がウェブページから情報を得ることを可能にするために、識別されるものの属性に対応するルールを確立する方法は、所望のものに関する情報に対応するウェブページを発見するステップと、発見されたウェブページにかぶせる形式を選択するステップと、この形式に基づいて発見されたウェブページから情報を抽出するステップとを有する。この形式は、所望のものの属性に対応するルールにより規定される。
【選択図】図１０

Description

【０００１】
【発明が属する技術分野】
本発明は、インターネットおよび電子商取引、つまり、「ｅ−コマース」に関し、特に、ウェブに基づく情報の変換に使用されるルールのプログラムによらない開発ステムおよび方法に関する。
【０００２】
【従来の技術】
インターネットは、インターネットに接続されたコンピュータを使用する人が大量の情報にアクセスできる媒体へと発展した。インターネットを介して情報にアクセスする能力は、様々な種類の方法で提供できる。インターネット検索エンジンによって情報が提供される場合もある。インターネット検索エンジンは、通常、キーワードまたは語句でインターネットを検索し、テキストまたは組み込み識別子（例えば、メタタグ）等としてＷｅｂページに検索ワードまたは語句が含まれるＷｅｂサイトのリストを提供する。個別のＷｅｂサイトにより、インターネットを介して情報にアクセスすることもできる。個別のＷｅｂサイトでは、広範な情報およびサービスが提供されている。これには時間が重要なものと時間に依存しないものの両方がある。
【０００３】
インターネットは、特に、電子商取引に役立つ。ベンダが自分の製品またはサービスを広告および販売することを可能にする多くのインターネットサーバが、開発されている。こうした製品およびサービスには、購入者に、インターネット上で電子的に届けられる品目（音楽等）と、従来の流通チャネル（運送業者等）を通じて届けられる品目（書籍等）とがある。サービスとしては、インターネット上で入手可能な情報（天気、交通、映画、原価比較等）と、インターネット上で実行されるトランザクション（株式取引、レストラン予約等）とを提供することが出来る。
【０００４】
残念なことに、インターネットは膨大な量の情報にアクセスする潜在能力をユーザに提供するが、有益なインターネットベースの情報を見つけることは、時間がかかり面倒であることが多い。更に、多数の個別Ｗｅｂサイトから入手可能な同じ情報同士を発見して比較するのは、困難である。これは、同じ情報が多数の異なる態様で編成され、多数の異なる形態で記述され、多数の異なる時点で変更されるためである。こうしたインターネットに内在する難点に加え、コンピュータ、またはインターネットサービスプロバイダ（ＩＳＰ）を介してインターネットに接続する他の電子デバイスによらなければ、インターネットから入手可能な情報にアクセスすることができないという単純な事実も存在する。更に、希望するインターネットからの情報を効果的に発見するためには、インターネットにより情報を検索する方法を修得しなければならない。そのため、コンピュータを所有していない人、ＩＳＰに接続すことができない人、およびインターネットの使用に関する経験または訓練が乏しい人は、インターネットからの情報にアクセスすることは、制限される。こうした要素は、業界の専門家が１９９９年の終わりに、インターネットにアクセスした経験、または「ネットサーフィン」した経験のある人が米国の人口のわずか３０％であると推定した理由の一部となっている（１９９９年１０月、フォレスター　リサーチ社の統計）。
【０００５】
したがって、コンピュータを直接使用すること、個人的なＩＳＰ接続を有すること、またはインターネットの使用に関して経験または訓練したことが、無くても、人々がインターネットからの情報にアクセスすることができるシステムおよび方法が提供されることが望ましい。加えて、公衆電話の経由等、便利で容易に利用可能な手段を使用して、人々がインターネットからの情報を取得できるシステムおよび方法が、提供されることが望ましい。更に、データを、インターネットソースおよび声のようなユーザインターフェースプラットホームに、およびそれらからデータを転送出来るように意味的に構造化されたデータの変換および標準構造化（ｃａｎｏｎｉｃａｌｉｚａｔｉｏｎ）のさいに使用されるルールのプログラムによらない開発を提供するシステムおよび方法も、提供されることが望ましい。
【０００６】
多くの課題により、これまで、こうしたシステムおよび方法は、実現不可能だった。例えば、こうしたシステムおよび方法を使用する人は、情報を迅速に、または少なくとも、受容可能な程度の時間内に入手したいと考える。こうした速度は、実現困難である。従来の高速コンピュータと高速通信接続を使用した場合でも、インターネットにアクセスするには必ず遅延時間が存在する（これを「ワールドワイドウェイト」と呼ぶ人も多い）。こうしたシステムおよび方法における別の課題は、音声通信の認識である。従来の音声認識技術は、速度が遅く不正確である。インターネットからの情報に対する音声による便利で意味のあるアクセスには、シンプルで、素早く、正確な音声認識が必要になる。にもかかわらず、既知のプロセッサおよびメモリデバイスでは、人間対人間の対話で行われるような音声認識に必要な大量の語彙への迅速なアクセスおよび処理速度は実現不可能である。
【０００７】
こうしたシステムおよび方法における更に別の課題は、サービスを財政的にサポートしつつ、インターネットからの情報への無料アクセスを提供する方法である。インターネット上の従来の広告では、「バナー」等の広告情報を確認し、バナーの「クリック」等、何らかの手動選択を行い、広告の製品またはサービスに関する詳しい情報を入手する能力が必要となる。
【０００８】
このため、上で述べた能力に加え、インターネットからの情報への迅速で正確な音声アクセスを無料で取得し得るシステムおよび方法が提供されることが望ましい。更に、インターネットソースからデータを得ることが出来、かつ他のインターネットソースからの他のデータと比較し、かつスピーチおよび無線アクセスプロトコール（ＷＡＰ）を含む、様々なプラットホームのユーザに与えることが出来るシステムおよび方法が、提供されることが望ましい。
【０００９】
【課題を解決するための手段】
本発明の実施形態の一態様は、プログラミングによらない手段がウェブページから情報を得ることを可能にするために、識別されるものの属性に対応するルールを確立する方法である。この方法は、所望のものに関する情報に対応するウェブページを発見し、かつフォームに基づいて見出されたウェブページから情報を抽出することを含む。このフォームは、所望のものの属性に対応するルールによって規定される。
【００１０】
簡単に言えば、本発明の実施形態の別の態様は、ウェブに基づく情報を共通データ構造に変換するさいに使用されるルールのプログラムによらない開発のシステムに関する。このシステムは、所望のものに関連する情報に対応するウェブページを発見する手段、この発見されたウェブページをオーバーレイするフォームを選択する手段、およびこのフォームに基づいて発見されたウェブページから情報を抽出する手段を含む。このフォームは、所望のものの属性に対応するルールによって規定される。
【００１１】
簡単に言えば、本発明の実施形態の別の態様は、ウェブに基づく情報を共通データ構造に変換するさいに使用されるルールのプログラムによらない開発の方法に関する。この方法は、関連情報を含む領域を有する情報のページを発見すること、関連情報を含む領域を分離するパターンを含むフォームを認識すること、関連領域を含む領域を含むページのセット内で情報のより多くのページに対するリンクを発見すること、および関連情報を含む領域を分離させる同様なパターンによりページのセットに対して拡大ファイルを形成することを含む。
【００１２】
簡単に言えば、本発明の一実施形態の別の態様は、ウェブに基づく情報を共通データ構造に変換するさいに使用されるルールのプログラムによらない開発のシステムに関する。このシステムは、関連情報を含む領域を有する情報のページを発見する手段、関連情報を含む領域を分離するパターンを含むフォームを認識する手段、関連領域を含む領域を含むページのセット内で情報のより多くのページに対するリンクを発見する手段、および関連情報を含む領域を分離させる同様なパターンによりページのセットに対して拡大ファイルを形成する手段を含む。
【００１３】
簡単に言えば、本発明の実施形態の別の態様は、ウェブに基づく情報の変換に使用されるルールを開発するシステムである。このシステムは、データベースとデータ編成ツールを含む。このデータベースは、複数のフォームから一フォームを使用してウェブページから抽出された情報を格納する。複数のフォームは、ウェブページから求められた関連情報に関するルールを含む。データ編成ツールは、専門家でないルール作成者が、複数のフォームからそのフォームを選択することを可能にする。選択されたフォームは、ウェブページ上の情報の配置と内容を近似するように選択される。
【００１４】
簡単に言えば、本発明の実施形態の別の態様は、ウェブに基づく情報を共通データ構造に変換するさいに使用されるルールのプログラミングによらない開発のためのコンピュータ可読プログラムコードを含むコンピュータプログラム製品である。コンピュータプログラム製品内のプログラムコードは、ウェブページを発見する第一のコンピュータ可読コンピュータプログラムコードと、関連情報を含む領域を孤立させるパターンを含むフォームを識別する第二のコンピュータ可読プログラムコードとを含む。
【００１５】
本発明のその他の原則的な特徴および利点は、以下の図面と、詳細な説明と、前記特許請求の範囲とを検討することにより当業者には明らかとなろう。
【発明を実施するための形態】
【００１６】
ウェブに基づく情報の変換に使用されるルールのプログラミングによらない開発システムおよび方法について説明する。以下の説明においては、説明の目的から、本発明の完全な理解を提供するために多数の特定の詳細について述べる。しかしながら、本発明は、こうした特定の詳細なしに実施し得ることは当業者には明白であろう。また、本発明の好ましい一実施形態の説明を容易にするために、周知の構造およびデバイスはブロック図の形態で表示されている。
【００１７】
本発明の例示的実施形態の一態様は、プログラミングによらない手段が、ウェブページから情報を得ることを可能にするために、識別されるものの属性に対応するルールを確立する方法を含む。この方法は、所望のものに関する情報に対応するウェブページを発見すること、この発見されたページをオーバーレイする、この所望のものの属性に対応するルールにより規定されている、フォームを選択すること、フォームに基づいて発見されたウェブページから情報を抽出することを含む。
【００１８】
本発明の実施形態の別の態様は、インターネットからの情報およびサービスへの音声アクセスを提供するシステムに関する。本発明の実施形態の別の態様は、インターネット上でのアクセス、処理、およびトランザクションの実行のために電話上で音声を使用するシステムおよび方法に関する。本発明の実施形態の更に別の態様は、あるＷｅｂサイトが他のＷｅｂサイトと同じ情報を有するか否かを判断するシステムおよび方法に関する。本発明の実施形態の更に又別の態様は、インターネットボイスポータルを使用する宣伝システムおよび方法に関する。本発明の実施形態の別の態様は、所望の項目を決定するために、インターネットボイスポータルシステムにおけるユーザの応答をファンネリング（ｆｕｎｎｅｌｉｎｇ）するシステムおよび方法に関する。本発明の実施形態の別の態様は、体系的構造化データの変換およびカノニカル化（ｃａｎｏｎｉｃａｌｉｚａｔｉｏｎ）に関するシステムおよび方法に関する。
【００１９】
一実施形態の場合は、メモリに含まれる命令シーケンスを実行する中央演算処理装置（ＣＰＵ）を有するコンピュータシステムが使用される。更に詳しくは、命令シーケンスの実行により、ＣＰＵは、ステップを実行する（これについては以下で説明する）。この命令は、実行のために、ＣＰＵにより、読み出し専用メモリ（ＲＯＭ）、大容量記憶装置、または他の何らかの固定記憶装置から、ランダムアクセスメモリ（ＲＡＭ）にロードすることができる。他の実施形態の場合は、本発明を実施するソフトウェア命令の代わりに、またはこれと組み合わせて、ハードウェア回路を使用することができる。したがって、本明細書で説明する実施形態は、ハードウェア回路とソフトウェアとの任意の特定の組み合わせには制限されず、コンピュータシステムによって実行される命令に関する任意の特定のソースにも制限されない。
【００２０】
図１は、ボイスポータル１０とネットワーク２０との間の接続を表している。例示的な一実施形態の場合、ネットワーク２０は、インターネット、つまりデータの送信と交換を円滑に行うためにＴＣＰ／ＩＰネットワークプロトコルを使用する、コンピュータネットワークによる世界規模のネットワークである。代替実施形態の場合、ネットワーク２０は、仮想プライベートネットワーク（ＶＰＮ）のような任意のタイプのネットワークである。ネットワーク２０は、好ましくは、ハイパーテキストマークアップ言語（ＨＴＭＬ）Ｗｅｂページ３０および４０との通信を提供する。Ｗｅｂページ３０および４０は、様々なＷｅｂサーバ上の様々なデータを有する。ネットワーク２０は、コンピュータ５２および５４と、データベース５８を有するサービス５６とをネットワーク２０に結合する非ボイスポータル５０との通信を提供する。サービス５６は、ネットワーク２０に接続している任意のタイプの企業、コンテンツ、またはサービスプロバイダである。データベース５８は、データの記憶媒体であり、光学、磁気、または他の任意の適切な記憶媒体とすることができる。
【００２１】
一般に、ボイスポータル１０は、サーバのネットワークとして実施される。サーバは、ソフトウェアによって構成できる。好ましくは、サーバは、ハードディスクなどの記憶装置を有する大量の読み取り書き込みメモリを有する。一般に、ユーザは、電話とボイスポータル１０との通信を開始する電話番号をダイヤルすることにより、携帯電話１２または標準の電話１４のような電話を介して（一般電話サービス（ＰＯＴＳ）を使用して）ボイスポータル１０にアクセスする。または、他のタイプの電話サービスを使用し、音声または音声データをポータル１０に通信することができる。ポータル１０は、様々なライン、ネットワーク、ステーションを介して、電話１２および１４に接続することができる。有利なことに、ボイスポータル１０は、ユーザに音声通信を提供する。ボイスポータル１０により、ユーザは、Ｗｅｂページ３０および４０とネットワーク２０を介して利用可能な他のソースとからの情報およびサービスにアクセスできる。こうしたアクセスは、様々なＷｅｂサイトおよびインターネットサービスから継続的に情報を検索、編成、および格納するボイスポータル１０によって、迅速で効率的な形で提供される。ボイスポータルを使用するために、他のユーザインタフェースプラットフォームを提供することもできる。こうしたユーザインタフェースプラットフォームには、例えば、ＷＡＰ（ワイヤレスアプリケーションプロトコル）およびＷｅｂインタフェースが含まれる。
【００２２】
図２は、ボイスポータルによって実行される例示的な機能的動作を表している。こうした機能は、任意の数の物理構造を含め、任意の様々な方法で実行することができる。例示的な一実施形態の場合、ボイスポータル１０は、ユーザインタフェース１１０と、広告サブシステム１２０と、顧客管理サブシステム１３０と、イグジスタントサブシステム１４０と、融合エンジン１５０と、更新エンジン１６０と、データベース１７０とを有する。
【００２３】
ユーザインタフェース１１０は、ボイスポータル１０とユーザとの間での音声通信を調整する。ユーザインタフェース１１０は、発話、インターネットまたは「ワールドワイドウェブ」（ＷＷＷ）、ワイヤレスアプリケーションプロトコル（ＷＡＰ）インタフェース、または他の任意のプロットフォームインタフェースを介したもののいずれかとすることができる。例示的な一実施形態の場合、ユーザインタフェースは、発話指向のものである。こうした発話指向の実施形態の場合、ユーザインタフェース１１０は、可能な限り、ユーザ入力を受け入れるワードベースの自動言語認識（ＡＳＲ）を使用する。ユーザインタフェース１１０には、マサチューセッツ州ボストン所在のスピーチワークスインターナショナル社が提供するＳｐｅｅｃｈＷｏｒｋｓ等の言語認識ソフトウェアパッケージを使用することができる。高い確率で言語認識を行うために、ユーザインタフェース１１０は、ユーザの応答を認識可能な回答のセットに集中させるファンネリングプロセスを利用することが有利である。ファンネリングについては、図３４を参照して詳細に説明される。ユーザインタフェース１１０は、ワードベースのＡＳＲが不可能である時に、ユーザの入力を受け入れるためにスペリングベースのＡＳＲも使用する。最後に、ユーザインタフェース１１０は、ユーザにとって有利である時のみ、ユーザ入力の入力用としてキーパッド入力を使用する。このキー入力の場合、電話１２および１４のキーを利用する（図４）。
【００２４】
例示的な一実施形態の場合、ユーザインタフェース１１０は、以下のタスクの一つまたはそれ以上を実行する。（１）電話番号および他のユーザ固有情報によりユーザを識別する。（２）一定のプラットフォーム上で一定のユーザのために新しいセッションを開始する。（３）一定のプラットフォーム上で一定のユーザのために新しい対話を追加する。（４）ボイスポータル１０において利用可能な垂直的関心ドメインのセット内でユーザの嗜好を更新する。（５）垂直的関心ドメインに関するユーザの嗜好を有効化または無効化する。（６）ユーザの専門知識レベルを全般的にまたは特定の垂直領域内で更新する。（７）ユーザの人口学的情報または個人情報（およびクレジットカード情報）を更新する。（８）ユーザインタフェース固有情報によりユーザのセッション状態を更新する。（９）新しいクレジットカードをデータベースに追加する。（１０）既存のクレジットカードを新しい情報により更新する。（１１）クレジットカードの種類および番号によりクレジットカードを識別し、既にデータベースに含まれる場合はチェックする。（１２）ユーザが利用可能な垂直的ドメインのリストとその順序とを設定する。（１３）ユーザのセッションを通常通り終了させる。（１４）ユーザのセッションが異常終了し、何らかの定義済み状態（コールドロップ、セッションタイムアウト等）になったことを顧客管理サブシステム１３０に通知する。（１５）セッションが異常終了（ドロップコール、セッションタイムアウト等）した場合にセッションを再開できるように、特定のプラットフォームが与えられたユーザの最近のセッションを決定し、格納されたセッション状態に復帰させる。ユーザインタフェース１１０は、識別、セッション、ユーザ、および支払プロトコルに関する追加機能を実行することができる。
【００２５】
広告サブシステム１２０は、通信セッション中にユーザに提示する広告に関する活動を調整する。例示的な一実施形態の場合、広告サブシステム１２０は、スポンサ広告と、特定のユーザをターゲットとする広告と、ユーザからの肯定的要求の後でのみ提示される許可ベース広告等との広告を有する。例示的な一実施形態の場合、広告サブシステム１２０は、次のうちの一つ以上の機能を提供する。（１）ユーザ、セッション、場所、コンテンツ、および検討中の項目に基づいて、再生する広告を選択する。（２）広告が再生され、かつ再生が完了したか否かを記録する。（３）スピークスルー（以下で説明するように、広告対象について詳しく聞くことをユーザが選択的に選んだ広告）が行われたことを記録する。（４）データベースを繰り返し呼び出す必要がないように、ビーン内に顧客およびセッション情報を格納する。（５）広告を提供した企業の記録を作成し、これを識別可能にする。（６）データベースに格納する広告および広告の契約を作成する（広告は、システムでの使用に関して異なる契約を有する場合がある）。（７）広告販売の目的で新しい販売担当社員または雇用主の連絡先を作成する。（８）広告および／または広告の契約を更新する。（９）連絡先情報および所在地情報を変更するために広告企業を更新する。（１０）販売担当社員および雇用主の連絡先を更新する。（１１）アクティブリストで広告を追加／削除する。（１２）外部情報に基づいて、完了するまたは完了しない広告契約に印を付ける。（１３）広告のタイプに基づいて、アクティブな広告のリストを表示する。（１４）非アクティブ、アクティブ、未完了、完了、または単純に全広告のいずれかの基準に基づいて、企業に関する広告のリストを表示する。（１５）上の基準に基づいて、広告に関する契約のリストを表示する。（１６）上記基準に基づいて、販売担当社員に関する契約のリストを表示する。（１７）単純に固有の識別子を送ることにより、社員、企業、広告、または広告契約の完全なリストを検索する。（１８）社員、企業、広告、および広告契約のイグジスタントの近似文字列一致に関して、データベースを検索する。（１９）特定の契約に関して、企業のために行った配信を追跡し、その企業の残高を更新できるようにする。（２０）データの完全性のエラーが存在しないことを確認するために更新ログを検索する。（２１）特定のジャンルの広告を格納するために必要なプレイリストを作成および修正する。
【００２６】
こうした動作のそれぞれを実行するために、様々な種類の方法を使用することができる。広告の動作については、図３６を参照して詳細に説明される。広告サブシステム１２０は、識別、セッション、ユーザ、および支払プロトコルに関する追加機能を実行することができる。本明細書で開示する広告技術は、従来のパーソナルコンピュータ（ＰＣ）インタフェースＷｅｂ接続によって使用することもできる。
【００２７】
顧客管理サブシステム１３０は、ユーザと、ユーザによるボイスポータル１０の使用とに関する情報の管理を調整する。例示的な一実施形態の場合、顧客管理サブシステム１３０は、ユーザインタフェース１１０と、広告サブシステム１２０と、その他のボイスポータル１０の機能とによって選択的に使用される、嗜好および人口統計データのようなユーザに関する情報を取得する。顧客管理サブシステム１２０は、識別、セッション、支払プロトコルに関する追加機能を実行することができる。サブシステム１１０、１２０、および１３０を別個に説明したが、それぞれの動作は、本発明の原理から逸脱することなく、単一のユニットに統合することができる。
【００２８】
ユーザインタフェース（ＵＩ）１１０および顧客管理サブシステムは、垂直的ドメインから選択したものと、インターネットからの情報のアクセスとを提供するために対話する。垂直的ドメインは、ボイスポータル１０内でユーザが選択可能な様々なフィールドまたはエリアを分類する。ＵＩ１１０がユーザと効果的に通信するためには、特定の嗜好およびユーザデータを、受動的または能動的に確認および理解する必要がある。顧客管理サブシステム１３０は、こうした情報をデータベース１７０に格納する。または、別個の顧客データベースにより、こうした情報を維持することができる。
【００２９】
顧客管理サブシステム１３０は、顧客の嗜好およびデータを判断するために必要な情報をＵＩ１１０から取得する。ＵＩ１１０は顧客管理サブシステム１３０にデータを渡し、顧客管理サブシステム１３０は、このデータを処理し、少なくとも一つのデータベースに中継する。更に、更なる解析のためにイグジスタントサブシステム１４０には嗜好の更新も存在する。その後、イグジスタントサブシステム１４０は、ユーザの嗜好およびデータ等の情報をＵＩ１１０に戻す。
【００３０】
顧客管理サブシステム１３０が、応答時間を感知できるほど長くすることなく、修正および拡張することが可能であることは、有利である。このため、ボイスポータル１１０に新しい垂直的ドメインを追加するプロセスは、迅速で一貫性がある。顧客データおよび人口統計データのタイプは、決して完全に定義することができず、新しい垂直的ドメインは常に追加可能である。
【００３１】
顧客管理サブシステム１３０は、データベースを介して登録済みのユーザおよび未登録のユーザが行ったすべてのトランザクションを記録する。顧客管理サブシステム１３０は、更に、形成済み履歴リストにユーザが見つけた項目を記録し、ユーザが（Ｗｅｂサイト上でおよびＷＡＰデバイスを通じて）調べたコレクションを追跡する。
【００３２】
顧客管理サブシステム１３０は、可能な時は常に、できる限り受動的に、登録済み顧客を識別する。したがって、顧客の認識は、好ましくは、例えば、システムに入る時の電話番号およびＩＤ（「ＰＩＮ」）のような何らかの種類の識別キーを介して行われる。この識別は、顧客に関連する特性の嗜好と、嗜好の各セット内での顧客の経験レベルとに結びつくことが好ましい。加えて、このシステムでは、格納されたクレジットカード情報に対する購入の認証を行う前に、識別のレベルを追加すること（例えば、パスワードによる識別）も可能である。
【００３３】
顧客管理サブシステム１３０は、それぞれの垂直的ドメイン内で、ボイスポータル１０を介したユーザの対話を円滑にする嗜好のセットを維持する。例えば、例示的な一実施形態の場合、顧客管理サブシステム１３０は、顧客に与える広告のタイプおよび顧客のサービスを向上させる方法を判断するのを更に支援するために、顧客から情報を収集する。顧客管理サブシステム１３０は、サポートする各ドメインに応じた顧客の嗜好を維持し、データソースからの顧客データを動的に更新する。例えば、オークションの関心ドメインでは、ユーザの要求に応じて現在の入札状態が交信される。ボイスポータル１０は、有利なことに、ドメインに応じた現在性によりユーザデータを提供する。例えば、オークションの関心ドメインでは、入札は常に数秒以内に最新のものになり、ｅ−コマースの関心ドメインでは、価格状態は購入価格が提示された時に最新のものになる。
【００３４】
顧客管理サブシステム１３０が、どのユーザがどのサービスにアクセスしたかの判断を可能にする報告および分析を提供することは、有利である。更に、顧客管理サブシステム１３０は、例えば、特定の所得階層、性別、または年齢層のユーザがどのサービスにアクセスしたかを判断すること等、異なる人口統計セグメント別にセッションおよびトランザクション履歴の報告を提供する。顧客管理サブシステム１３０は、更に、実際の使用に基づく相関性の報告を提供する（例えば、映画に関心のあるユーザが他のどのようなサービスにアクセスしたかを報告する能力）。
【００３５】
継続的に価値を付加し、あるプラットフォームから別のプラットフォームへのユーザの移行（例えば、電話からＷｅｂ、または電話からＷＡＰ）を追加するために、顧客管理サブシステム１３０は、有利なことに、サービスにおける顧客の体験を向上させる個人化機能をサポートする。個人化に加え、その他の「固着性」（競合の観点における顧客のサービスへの「固着」）のソースには、友人または共通の関心を持つ人々のネットワークのようなコミュニティ機能のサポートが含まれる。したがって、顧客管理サブシステム１３０に個人化機能およびコミュニティ機能が含まれる場合、顧客が特定のサービスプロバイダに愛着を持つ傾向が強くなる。
【００３６】
顧客の行動に対し如何なるサービス（または広告）も適合化させることをサポートするために、顧客管理サブシステム１３０は、有利なことに、サービスの使用を追跡する。更に、インタフェース評価の分野においては、代表的なユーザによるインタフェース階層の調査パターンは、問題のあるエリアまたは非常に有効なエリア、または単一のセッションにおいて相関する下位機能のセットを特定するのに役立つ場合がある。ボイスポータル１０のサービスにおいて重要な属性の別の例は、タイミングである。例えば、（リストまたはプロンプトが完了する前に、ユーザが回答によって割り込み可能である）「バージイン」の使用は、上級ユーザを意味する可能性があり、かつ特定のユーザが単一のサブツリーに対して繰り返し行ったバージインの文字列の選択内容は、有利なことに、顧客管理サブシステム１３０によって検出することが可能であり、かつこれは全般的なショートカットまたはおそらくは顧客固有のショートカットへの機会をもたらすことが出来る。
【００３７】
「固着性」の態様は、顧客の嗜好に対するサービスの適合化である。これは反復されない「サインアップ」または「購入」データ入力要件のサポートにおける顧客情報の保持のような相対的に単純な機能を有するが、更に、様々なフロントエンドにおける対話での特定のサブツリーのナビゲーションに関する嗜好と、サービス／ベンダの順序付けまたは選択に関する嗜好を有することもできる。ベンダの嗜好または順序付けの例として、ユーザは「好適なベンダ」を選択することが可能であり、これによりボイスポータル１０は、発見した製品に関するベンダのリストを、最も安いものと、好適なものとの二つに限定することができる。
【００３８】
垂直的嗜好は、ユーザの行動に基づいて受動的に設定されるべきである。つまり、特定の属性が二度以上要求されると、受動的嗜好が、設定されることになる。または、嗜好は、動的であり、ユーザの行動に基づいて変化する。ユーザが、音声またはＷｅｂインタフェースを介して設定またはリセットすることにより、すべての受動的嗜好を無効にすることができることが、好ましい。
【００３９】
顧客管理サブシステム１３０は、株式情報、選択した天気のようなユーザの嗜好を、ＭｙｙａｈｏｏおよびＭｙＥｘｃｉｔｅのような個人化されたＷｅｂページから引き出すことができる。この個人化されたＷｅｂページは、ユーザが従来のインターネット接続を介して事前に作成することができる。または、個人化されたＷｅｂページは、顧客管理サブシステム１３０がユーザの音声コマンドに反応して構築することができる。こうしたページは、ボイスポータル１０で使用するために変換することができる。全般的な嗜好は、特定の垂直的嗜好または現行の通話での嗜好が存在しない場合、有利なことに、デフォルトの嗜好として使用することができる。
【００４０】
以下では、例示的な垂直的嗜好要件およびその説明が列挙されている。各嗜好は、各インタフェースの全体に渡って異なる形で使用される。例示的な一実施形態の場合、天気に関する唯一の嗜好は、顧客が要求した場所の天気である。デフォルトでは、ユーザの場所は、その郵便番号である。最も一般的に使用される場所（ＭｏｓｔＣｏｍｍｏｎｌｙＵｓｅｄＬｏｃａｔｉｏｎ）は、可能な場合、現行の通話の場所によって無効にすることができる。
【００４１】
スポーツの関心ドメインにおいて、調査する嗜好は、数種類存在する。第一に、好きなスポーツが、選択肢となる。特定のスポーツのスコア、スケジュール、および順位をユーザに送信することもできる。Ｗｅｂサイトでは、排他性を使用して、特定のスポーツの広告および情報を送信しないことができる。例えば、あるユーザは、ホッケの試合に関する情報は望んでおらず、野球の情報を求めている場合がある。第二に、他のチームより贔屓にしている特定のチームについては、嗜好の細かさを増加させることができる。こうしたそれぞれの細かさに関し、限定的な選択の直前に使用された（ＭＲＵ）リストを使用して、嗜好リストを決定することが可能である。スポーツの種類およびチームの嗜好の他に、好ましいイベントを使用することができる。
【００４２】
映画の関心ドメインにおいて、必要な嗜好には、顧客の地域および劇場の地域と、映画のタイプ（スリラ、ホラー、アクション等）と、映画の観客指定（ＡＡ、Ｇ、Ｒ等）と、顧客の好きな俳優／女優が出演している映画とが含まれる。こうしたそれぞれの嗜好は、限定的な選択のＭＲＵリストに列挙することができる。
【００４３】
交通に関する関心領域の場合、使用される主な嗜好は、時間の属性を有する（現在がデフォルトである）、ユーザが目的地に到達するために使用した特定のルートである。したがって、限定的なルートのＭＲＵリストが、顧客の嗜好リストを構成する。
【００４４】
例示的な一実施形態の場合、株式の関心ドメインにはニ段階の嗜好階層が存在する。第一に、市場リストの嗜好が存在し、第二に、各市場内で、どの株式および指数を調査するかの嗜好が存在する。ここでも、市場および株式が決定されていない選択用ＭＲＵリストを表にすることができる。他の垂直的関心ドメインには、レストラン、コンサートおよびライブイベント、タクシおよび飛行機の予約がある。
【００４５】
更に図２を参照すると、イグジスタントサブシステム１４０は、ユーザインタフェース１１０と、広告サブシステム１２０と、顧客管理サブシステム１３０と、融合エンジン１５０と、更新エンジン１６０とによるデータベース１７０へのアクセスを調整する。イグジスタントサブシステム１４０は、データベース１７０に含まれるデータ構造の作成、適合化、および操作を管理する。データベース１７０に含まれるデータは、更新エンジン１６０によって、インターネットのソースから収集される。例示的な一実施形態の場合、データベース１９０において使用されるデータ構造は、「イグジスタント」または事物とその互いの関係および連関との階層に基づいている。データベース１７０はイグジスタントサブシステム１４０とのみ対話するため、データベース１７０内の情報を複製および修正する能力は、より容易に実行されることは、有利である。イグジスタンおよびその作成については、図４乃至１０を参照してさらに説明される。特に、イグジスタントに関する例示的なデータ構造モデルについては、図４乃至６を参照して説明されるが、イグジスタントに関する他の多数の構造を利用することも可能である。イグジスタントの作成および更新については、図７乃至１０を参照して説明される。
【００４６】
融合エンジン１５０は、二つのイグジスタントが同じであるか否かを判断し、同じである場合、イグジスタントを融合し、第三のカノニカルなイグジスタントを形成する。これにより、融合エンジン１５０は、あるソースから収集した情報が別のソースから収集した情報と関連しているかまたは同じであるかを確証する。融合エンジン１５０の機能については、図２５、２６、および２７を参照して説明される。
【００４７】
更新エンジン１６０は、インターネットから情報を検索し、データベース１７０に含まれる情報および属性を更新する。例示的な一実施形態の場合、更新エンジン１６０は、データベース１７０の情報を更新するために、インターネットから情報を検索する「スパイダ」を利用する。更新エンジン１６０の動作については、図７および８を参照して説明される。
【００４８】
データベース１７０は、顧客データと、広告情報と、製品およびサービス情報等とのボイスポータル１０で使用される情報を格納する。データベース１７０内の情報は、イグジスタントと、イグジスタント属性と、イグジスタント関係と、イグジスタント連関とに格納される。イグジスタントとは何か、どのように形成されるか、互いにどのように関連するか、およびボイスポータル１０の機能とどのように関連するかについては、以下に詳しく説明する。代替実施形態の場合、顧客データ、広告情報、および動作記録等、特定のタイプの情報については、多重データベースを使用することができる。
【００４９】
図３は、ボイスポータル１０の例示的な物理的レイアウトを表している。こうした物理的構造は、例としてのみ表示されている。表示のものと組み合わせて、または表示のものの代わりに、他の構造を使用することもできる。例示的な一実施形態の場合、ボイスポータル１０は、フロントエンドサーバ２１０と、フロントトゥバック（ｆｒｏｎｔ−ｔｏ−ｂａｃｋ）ネットワーク２２０と、バックエンドサーバ２３０と、バックエンドネットワーク２４０とを有する。ユーザは、電話を介して、フロントトゥバックネットワーク２２０によってバックエンドサーバ２３０に結合されているフロントエンドサーバ２１０の一つと通信する。
【００５０】
例示的な一実施形態の場合、バックエンドサーバ２３０は、プロキシマネージャ２４５と、プロキシ２５０と、ビーン２６０と、データベース２７０とを有する。プロキシマネージャ２４５は、フロントエンドサーバ２１０の一つから、フロントトゥバックネットワーク２２０を介して、情報の要求を受領する。プロキシマネージャ２４５は、バックエンドネットワーク２４０を介して通信し、それぞれのプロキシマネージャ２４５での仕事負荷レベルを判断する。適切なプロキシマネージャ２４５が決定されると、適切なプロキシマネージャ２４５は、フリープロキシ２５０のプールからフリープロキシを引き出し、そのプロキシをビーン２６０に割り当てる。ビーン２６０は、情報を検索するため、情報を挿入するため、イグジスタントまたはイグジスタント関係を検索するため、またはデータベース２７０によって可能な他の任意の機能を実行するために、データベース２７０に関連している。
【００５１】
図３を参照して説明される仮想データベース構造は、インターネット２０から集められた情報を、時宜に適った非常に実用的な形でボイスポータル１０のユーザに配信するように設計されている。人々は様々な場面および形で情報を必要とし、これを使用するが、有利なことに、ボイスポータル１０は、電話（例えば、音声、ＷＡＰ、および両方）と、Ｗｅｂと、携帯接続コンピューティングデバイス（例えば、Ｐａｌｍ（登録商標）ＯＳデバイス、ＷｉｎＣＥ（登録商標）デバイス、ＲＩＭページャ）とを一部として有する様々なプラットフォーム上で、これをサポートする。
【００５２】
バックエンドサーバ２３０は、データ収集および融合を有する、様々な機能を有するデータベースサービスサポートを有する。データ収集は、図７および８を参照して説明するように、特定の項目の種類および／またはサイトに関してスケジュール化されている定期的な間隔で、インターネットソースからデータを蓄積する。ボイスポータル１０は、図９および１０を参照して説明されるように、データソースサイトの変更を検出し、適切なサイトルールマネージャに通知する。ボイスポータル１０は、同じく図９および１０を参照して説明されるように、データソースからのデータ抽出の非エキスパート定義をサポートする。
【００５３】
「融合」のプロセスにおいて、ボイスポータル１０は、異なるインターネットベンダから同一の項目を特定する。融合プロセス中、ボイスポータル１０は、すべての情報のソースに関するメタデータを保持する。メタデータは、データに関するデータを有する。例えば、メタデータは、データ要素または属性に関するデータ（名前、サイズ、データタイプ、その他）と、記録またはデータ構造に関するデータ（長さ、フィール否かラム、その他）と、データに関するデータ（どこに位置するか、どのように関連するか、所有者、その他）とを記録することができる。更に、ボイスポータル１０は、確実性を自動的に決定できない場合に、非エキスパートによる融合の決定または非決定の対話式分類をサポートする。ボイスポータル１０は、更に、コードを変更することなく、新しいデータタイプおよびデータ要素の追加をサポートする。更に又、ボイスポータル１０は、市場調査と、市場試験と、市場機会とを通じて特定される相関性のドメイン固有概念をサポートする。例えば、ｅ−コマースの関心ドメインにおいては、より安価と、より良質と、一緒に購入されることが多いと、最も人気が高いとが、重要な相関性概念になる。映画の関心ドメインにおいては、関連する映画および製品と、カテゴリで最高の映画と、最も人気が高いと、最高の批評と、キャストとが、重要な相関性概念になる。ボイスポータル１０は、項目に関する追加的詳細を提供するために必要な関連情報を収集および保持する（製品説明等）。融合の動作および機能については、図２５乃至２７を参照して更に説明される。
【００５４】
図４は、ボイスポータル１０のデータベース１７０によって使用される例示的なデータ構造モデル３００を表す。ここで、「イグジスタント」（または事物）には属性、連関、および関係が与えられている。イグジスタント間の「継承」関係は、先端に三角形が付いた実線で表されている。イグジスタント間の「連関」関係は、先端に開いた矢印が付いた点線で表されている。継承関係の例として、データ構造モデル３００において、ブロック３１０は、「イベント」である。「イベント」は、「イグジスタント」または事物であり、これはブロック３２０への三角形の矢印３１５によって表される。同様に、「映画上映」（ブロック３３０）は、三角形の矢印３３５によって表されるように、「イベント」（ブロック３１０）である。連関関係の例として、イベントは、ブロック３４０への開いた矢印３４５によって表されるように、「会場」に関連する。同様に、映画上映（ブロック３３０）は、開いた矢印３５５によって示されるように、「映画パッケージ」（ブロック３５０）に関連している。スポーツイベント、ドラマ、コンサート、コメディショー、花火大会、ダンスパフォーマンス、または他の如何なる活動も、イベントとすることが出来る。
【００５５】
データ構造モデル３００は、図４に例示される更に多くのイグジスタント、連関、および関係を有するが、ここでは説明しない。更に、データ構造モデル３００は、例図に含まれない更に多くのイグジスタント、連関、および関係を有することができる。図４の目的は、例示のみである。
【００５６】
次に図５には、ユーザまたは顧客オブジェクトと様々な垂直的クラスとの間のオブジェクト指向関係を示すために、例示的なデータ構造モデル４００が表示されている。継承および連関関係の表示は、図４を参照して説明したデータ構造モデル３００の表示と同じである。例示的な一実施形態の場合、データ構造モデル４００に配置されるユーザ情報は、データベース１７０に含まれる。しかしながら、代替実施形態の場合、こうしたユーザ情報は、別個の顧客データベースに含まれる場合もある。
【００５７】
顧客は、Ｅｘｉｓｔａｎｔ（顧客イグジスタントブロック４０２）であり、階層内の最上レベルの直系、または「Ｅｘｉｓｔａｎｔ」イグジスタントであるため、すべての特定およびメソッドを継承する。この構造の理由は、データベース１７０およびそのメソッドが既に作成されており、この構造によりコードの再使用が可能となるためである。
【００５８】
顧客オブジェクトは、様々な情報の断片を有する。全般的な嗜好クラスは、「交通」、「天気」、および「映画」のような嗜好に関する情報を有する。顧客が新しい種類の垂直的関心ドメインに入る度に、挿入された嗜好データにより、垂直的ドメインの名前に対する嗜好オブジェクトのインスタンスが作成される。垂直的ドメインが既に存在する場合、オブジェクトは、更新された情報により修正される。
【００５９】
セッションクラスは、ユーザのセッションに関する情報を直接的に記録する（セッションブロック４０４）。このセッションは、通話、Ｗｅｂサイトを通じた検索、またはＷＡＰを使用した呼び出しとすることができる。日時および継続時間のようなデータは、全般的な属性だが、ユーザが通話に使用したのが電話線か携帯電話かの分析は、電話セッションに固有となる。このタイプのデータは、ボイスポータル１０が（広告の目的で）誰に対してマーケティングするかを決定すること、およびパフォーマンスおよびサービスの両方を向上させることにおいて有益である。同様に、顧客オブジェクトは、（ユーザがセッションを中断し、特定の時間に再接続したい場合に）そのプラットフォームでの最後のセッションがどれであるかを決定するために、こうしたセッションオブジェクトのそれぞれとのリンクを有している。
【００６０】
電話セッションブロック４０８は、ポータル１０との通信に電話が使用された場合の通信セッションに関する情報を記録する。電話セッションブロック４０８は、現在の対話レベルと、現在の関心ドメインと、インタフェースプラットフォームのタイプ（ＷＷＷ、ＷＡＰ、ＡＳＲ等）と、前回の訪問レベル等との情報を有する。有利なことに、電話セッションブロック４０８により、ユーザは、前回のセッションを中止した場所、またはセッションが中断された場所から、セッションに再び参加することができる。クレジットカード情報イグジスタント、場所イグジスタント、および嗜好イグジスタントのような他のイグジスタントブロックは、必要に応じて関連する属性および記録情報を有する。
【００６１】
専門知識クラス（専門知識ブロック４０６）は、様々なプラットフォーム（電話、ＷＡＰ、ＷＷＷ）での（全般的、および様々な嗜好に関する）使いやすさの様々なレベルを維持する目的を果たす。顧客は、こうしたクラスインスタンスそれぞれに対するリンクを有する。嗜好はクロスプラットフォームにすることができるが、ユーザの能力はできないため、これは、嗜好クラスには含まれない。
【００６２】
図６は、広告に関する情報についてボイスポータル１１０のデータベース１７０によって使用される例示的なデータ構造モデル４５０を表している。継承および連関関係の表示は、図４のデータ構造モデル３００の表示と同じである。例示的な一実施形態の場合、データ構造モデル４５０に配置される広告情報は、データベース１７０に含まれる。しかしながら、代替実施形態の場合、こうした広告情報は、別個の広告データベースに含まれる場合もある。
【００６３】
データ構造モデル３００、４００、および４５０が、イグジスタント、連関、および関係に関する情報の継続的に拡張する配列を提供することは、有利である。更に、モデル３００、４００、および４５０は、以前に入力された情報を変化させることなく、新しい垂直的関心ドメインを迅速に作成することを可能とする。例えば、モデル３００は、映画およびコンサートのようなイベントと、書籍、玩具、および電子機器のような商品とに関連する情報を有する。バレエのような如何なるイベントも、「イベント」との継承関係と、適切な連関関係とを有するイグジスタントとして、容易に追加することができる。同様に、車のような如何なる商品も、「製造品目」との継承関係と、適切な連関関係とを有するイグジスタントとして、容易に追加することができる。データ構造モデル３００、４００、および４５０の動的な性質および拡張能力から、ボイスポータル１０は、広範なインターネットからの情報およびサービスに対する単一のボイスポータルとなる利点を有することができる。
【００６４】
図７は、例示的なデータ構造モデル３００（図４）、データ構造モデル４００（図５）、および例示的なデータ構造モデル４５０（図６）に示されるイグジスタントのようなイグジスタントの例示的な作成プロセスのフロー図７００を表している。ステップ７１０において、インターネット上のＷｅｂページが発見される。例示的な一実施形態の場合、事前に定められた項目のカテゴリに関連する特定のＷｅｂページを見つけるために、スパイダが、使用される。スパイダは、ドキュメントを検索し、その中で参照されるドキュメントの一部または全部を再帰的に検索することによりワールドワイドウェブ（ＷＷＷ）を自動的に探索する、従来から知られているプログラムである。対照的に、人間が操作するＷｅｂブラウザは、インライン画像およびＵＲＬリディレクション以外のリンクを自動的に進むことはない。ステップ７１０が実行された後、ステップ７２０が実行され、特定の情報を抜き出すためにページにオーバレイする選択フォームを使用して、発見されたＷｅｂページ上で情報が識別される。ステップ７２０の後、ステップ７３０が実行され、ステップ７２０でのフォームオーバレイによって検索された情報から特性情報または属性を識別するためにルールが使用される。特性情報または属性は、イグジスタントが何であるかを定義する。ルールは、イグジスタント属性の編成を定義する。例えば、映画イグジスタントは、タイトル、監督、キャスト、公開年、およびシノプシスの属性を有することができる。
【００６５】
ステップ７３０が実行された後、ステップ７４０が実行され、属性がイグジスタント内で編成され、イグジスタントはデータベース１７０に格納される。イグジスタント内での属性の編成および配列は、事前に定められたルールによって構造化されることが、好ましい。
【００６６】
図８は、図７を参照して説明したイグジスタントの例示的な作成プロセスを表している。スパイダ８１０は、広範な種類のＷｅｂページに格納される情報のためにインターネット２０をトラバースする。スパイダ８１０によって検索された情報は、情報をデータ構造８３０内に置くために、ルール８２０にしたがって編成および配列される。例示的な一実施形態の場合、スパイダ８１０は、映画に関するインターネット２０からの情報を検索する。例えば、スパイダ８１０は、ＩＭＤＢ　Ｗｅｂサイトをトラバースし、特定の映画のタイトル、監督、キャスト、公開年、および上映時間に関する情報を検索することができる。映画の情報がデータ構造８３０内に格納されると、データ構造８３０は、語彙テーブル８４０に加えられる。語彙テーブル８４０は、データ構造８３０に含まれる属性を編成し、情報を三つのカラムに配置する。例示的な一実施形態の場合、語彙テーブル８４０の第一のカラムは、オリジナルデータを含み、第二のカラムは、標準化されたタグ付きのフォーマットでオリジナルデータを含み、第三のカラムは、検索可能なマッシュされたフォーマットでデータを有する。語彙テーブル８４０およびデータ構造８３０は、データベース１７０のメモリ構造に含まれる。
【００６７】
一例として、スパイダ８１０が映画「レイダース失われた聖櫃（ＲａｉｄｅｒｓｏｆｔｈｅＬｏｓｔＡｒｋ）」に関連する情報についてインターネット２０をトラバースする場合、インターネット２０から検索されるデータには、映画に対応するルールが適用され、このデータはデータ構造８３０に置かれる。こうした映画に関するルールは、タイトル、監督、キャスト、および公開年を有することが可能であり、そのすべてが映画の属性である。この例において、タイトルは「レイダース失われた聖櫃」となり、監督は「スティーブン・スピルバーグ」となり、キャストは「ハリソン・フォードおよびカレン・アレン」となり、封切り年は「１９８１」となり、上映時間は「１１５分」となる。このため、語彙テーブル８４０は、オリジナルフォーマットのタイトル「ＲａｉｄｅｒｓｏｆｔｈｅＬｏｓｔＡｒｋ」と、標準化されたタグ付きフォーマットのデータ＜ｔｉｔｌｅ＞ＲａｉｄｅｒｓｏｆｔｈｅＬｏｓｔＡｒｋ＜／ｔｉｔｌｅ＞と、検索可能なマッシュされたフォーマットＲａｉｄｅｒｓＬｏｓｔＡｒｋとを、スペースまたは同定の冠詞（ｔｈｅ，ａ，ａｎ等）を付けずに有する。
【００６８】
図９は、ノンプログラミング手段を使用してインターネットからの情報を収集する例示的なプロセスを示すフロー図９００を表している。ステップ９１０において、検索ページが発見され、関連情報を有するページのエリアを分離するためにパターンが使用される。ステップ９１０が実行された後、ステップ９２０が実行され、適切なフォームが発見され、実際のデータおよび情報を抽出するために特別なルーチンが呼び出される。ステップ９２０の後、ステップ９３０が実行され、関連情報を有する多数のページが、特定のページが与えられた状態で発見される。データ固有パターン以外に、特定のページにおいてデータ固有パターンが作用する場所を定義するエリアパターンが存在する。ステップ９３０が実行された後、ステップ９４０が実行され、多数のページ上の製品またはサービスの更なるリストが発見される。例示的な一実施形態の場合、コードサンプルから実際の製品リストのパターンを計算するために、予測ルーチンが使用される。
【００６９】
一般に、予測ルーチンは、ルールライタによって与えられた望ましい出力からパターンを計算する。ルールライタが抽出したいテキストの断片をＨＴＭＬコードからペーストするのみで良いことは、これを行うためのパターンを作成する必要がないため、パターン予測ルーチンが、生産の速度を上げるので、有利である。パターンを記述するために現在使用されている入力フィールドは、このデータを挿入するために使用される。
【００７０】
一例として、最初にルールライタがＷｅｂページ上の著者名のサンプルを著者フィールドにコピーすることにより、予測ルーチンは、書籍に関するデータを提供するＷｅｂページの著者データに関するパターンを策定する。このアルゴリズムは、その後、サンプルデータをＷｅｂページ上の位置に一致させる。一致データの近くにある文字またはタグは、「接頭辞（ｐｒｅｆｉｘ）」および「接尾辞（ｓｕｆｆｉｘ）」として識別される。接頭辞は、一致データの前にある文字であり、接尾辞は、一致データの後ろにある文字である。接頭辞および接尾辞は、パターンを構築するために使用される。
【００７１】
構築されたパターンは、他のデータと一致させるためにＷｅｂページに適用される。構築されたパターンが、望ましい結果と等しくないデータを拾い上げた場合、パターンの策定に使用された接頭辞および接尾辞に追加が行われ、更に完全で正確なパターンとなる。この手順が反復され、パターンは改良される。
【００７２】
この例を更に明確にするために、書籍に関する製品データを提供するＷｅｂページからの以下のＨＴＭＬコードを取り上げる。
【００７３】
【プログラム１】

【００７４】
ルールライタは「ＬａｒｒｙＷａｌｌ」を著者フィールドにダンプし、これが著者として抽出するデータであることを示す。
【００７５】
パターン予測アルゴリズムは、大まかに以下のように機能する。
【００７６】
【プログラム２】

【００７７】
第一のページのｎ＝１から開始し、このアルゴリズムは、＄ｐｒｅｆｉｘが値「＞」を取り、＄ｓｕｆｆｉｘが値「＜」を取ることを意味する「＞ＬａｒｒｙＷａｌｌ＜」と一致する。次に、パターン予測アルゴリズムは、第一のステップから得た値＄１および＄２を使用して、パターン「＞（．^＊？）＜」を構築する。このパターンをＷｅｂページと一致させることにより、望ましい結果「ＬａｒｒｙＷａｌｌ」とは等しくない「＞ＰｒｏｇｒａｍｍｉｎｇＰｅｒｌ＜」が生じる。そのため、ｎはｎ＝２に増分され、接頭辞および接尾辞に別の文字を有するためにパターンは精緻化される。「（｛．｝２）Ｌａｒｒｙ＼ｓ＋Ｗａｌｌ（｛．｝２）」を有するＷｅｂページとの一致により、「ｂ＞ＬａｒｒｙＷａｌｌ＜／」が生じ、これは＄ｐｒｅｆｉｘが値「ｂ＞」を取り、＄ｓｕｆｆｉｘが値「＜／」を取ることを意味する。次に、このパターン予測アルゴリズムは、第一のステップから得た値＄１および＄２を使用して、パターン「ｂ＞（．＊？）＜／」を構築する。このパターンをＷｅｂページに一致させることにより、望ましい出力である「ＬａｒｒｙＷａｌｌ」が生じる。
【００７８】
次に、ルールライタは、Ｗｅｂページを進んで、同じパターンを異なるページに適用し、パターン一致として、書籍「ＬｅｒｎｉｎｇＰｅｒｌ」に関するページ上の「２ｎｄ　ｅｄｉｔｉｏｎ」を発見する。ここでルールライタは、望ましい結果の第二の例を与えることにより、アルゴリズムを改良し（つまり、ＧＵＩの入力フィールドに「ＲａｎｄａｌＳｃｈｗａｒｔｚ」をダンプする）、これによりパターン予測アルゴリズムは、＜ｂ＞の前に「ｙ」を付けるパターンが作成されるまで、ｎを更に増分する。このアルゴリズムは、Ｗｅｂデータのデータおよび必要なパターンの複雑性に応じて、何度かの反復を実行することができる。
【００７９】
ステップ９４０が実行された後、ステップ９５０が実行され、ベンダ固有データ抽出ファイルが生成される。例示的な一実施形態の場合、コードサンプルから関連するＵＲＬを計算するルーチンが使用される。または、ＵＲＬを計算するルーチンは、フォームとして渡すことができる。ステップ９５０が実行された後、ステップ９６０が実行され、キャッシュが作成される。ステップ９６０が実行された後、ステップ９７０が実行され、製品データの抽出に関するパターンが作成される。好適な実施形態の場合は、回帰試験メカニズムが、特別なルーチンの編集をサポートする。
【００８０】
図１０は、ボイスポータル１０に関連するルールのノンプログラミング策定の例示的なプロセスを表している。この例示的なプロセスにおいて、ルールライタ１０１０のセットからのルールライタは、データソース１０３０、データソース１０３５、データソース１０４０、またはＷＷＷ１０２０に接続する他の任意のデータソースのうち、いずれか一つからの情報にアクセスするために、ワールドワイドウェブ（「ＷＷＷ」）１０２０にアクセスする。データソースから検索したデータは、データ編成ツール１０２５を利用してデータ構造内に置かれる。ルールライタ１０１０は、データ編成ツール１０２５を使用して、多数の可能なフォームの一つを、ＷＷＷ１０２０を介して利用可能な情報の「ページ」に適用する。こうしたフォームは、ページ上で、何らかの示差的なタグにより標識付けされた関連情報の場所に関する表示を提供する。例えば、ＷＷＷ１０２０上で提供されるページは、ページの左上角にデータ入力ボックスを有する可能性がある。更に、部分またはサービスに関する情報は、書籍のタイトルの「＜ｔｉｔｌｅ＞」のように、ＨＴＭＬタグの後に位置する可能性がある。
【００８１】
注意すべき点として、本明細書で使用される「ページ」という用語は、ユーザインタフェーススクリーン、または診断システムのユーザが閲覧可能な同様の配列、例えば、データ、メッセージ、方向、およびその他のグラフィックまたはテキストによる表示を提供するスクリーンを有する。更に、こうしたページは、マークアップ言語、またはＪａｖａ（登録商標）、Ｊａｖａスクリプト、または他の任意の適切な言語等のプログラミング言語によって定義することができる。
【００８２】
ルールライタ１０１０によってデータ編成ツール１０２５から選択されたフォームを使用することにより、データソースからのデータは、データ構造１０４５、データ構造１０５０、データ構造１０５５、または情報を維持する同様の如何なる構造にも編成される。データ構造１０４５、１０５０、および１０５５は、統一データ構造１０６０の形成において、比較、融合、または利用することができる。統一データ構造１０６０は、データベース１０７０に格納される。
【００８３】
図１０に示す例示的なプロセスにより、非エキスパートルールライタ１０１０が、ＷＷＷ１０２０を介して利用可能な特定のＷｅｂサイトからの情報の検索に使用するために、データ編成ツール１０２５によって提供される様々なフォームからの選択を可能にすることは、有利である。これにより、データソース１０３０、１０３５、および１０４０からのＷｅｂページに含まれるデータが、データ編成ツール１０２５を使用してルールライタ１０１０によって選択されたフォームにより、データベース１０７０で継続的に更新することができる。データ構造１０４５、１０５０、１０５５に含まれ情報が精度に関して比較されるので、データ編成ツール１０２５は、Ｗｅｂページが、対応するＷｅｂページ上のデータのフォーマットまたは配列を変化させた時期を検出する。
【００８４】
図１１乃至２４は、新しいルールを作成する例示的なプロセスを表している。更に、図１１乃至図２４は、ルールライタとデータ編成ツール１０２５（図１０）との間の可能な対話を表している。例示的な一ルールは、既存のルール、Ａｍａｚｏｎ．ｃｏｍの書籍製品に基づいている。このルールを構築する際に利用するステップは、他の任意のルールを構築する際に利用するステップと同様である。
【００８５】
図１１は、ルール８２０（図８）の作成を開始するために使用されるグラフィカルユーザインタフェース（ＧＵＩ）１１１０を表している。ＧＵＩ１１１０は、ベンダウィンドウ１１２０と、スパイダ選択ウィンドウ１１３０と、クエリウィンドウ１１４０と、ステータスウィンドウ１１５０と、検索ボックスエリア１１６０と、コードウィンドウ１１９７とを有する。検索ボックスエリア１１６０は、スライダバー１１７０と、右矢印セット１１８０と、左矢印セット１１９０と、検索ウィンドウ１１９５とを有する。
【００８６】
新しいデータソースを開始するために、ルールライタは、データソース（例えば、ＡｍａｚｏｎＢｏｏｋ）をベンダウィンドウ１１２０に入力する。ルールライタは、「Ｅｎｔｅｒ」を押し、「Ｎｅｗ」ボタンをクリックする。この行動が実行された後、図１２に例示されるグラフィカルユーザインタフェース（ＧＵＩ）１２００が表示される。ルールライタは、「Ｄｏｎｅ」ボタンをクリックし、記載されたデータソースが正しいことを確認する。次に、図１３に例示されるグラフィカルユーザインタフェース（ＧＵＩ）１３００が表示される。ＵＲＬは、選択されたベンダ名に対応して表示される。ルールライタは、正しいＵＲＬを確認するように求められる。ＡｍａｚｏｎＢｏｏｋの例において、ＵＲＬとしてｈｔｔｐ：／／ｗｗｗ．ＡｍａｚｏｎＢｏｏｋ．ｃｏｍが、ＧＵＩ１３００のウィンドウに現れる。しかしながら、ＵＲＬリンクは、ｈｔｔｐ：／／ｗｗｗ．Ａｍａｚｏｎ．ｃｏｍを読むべきである。ルールライタは、ＵＲＬを訂正し、「Ｄｏｎｅ」ボタンをクリックする。
【００８７】
ここで再び図１１を参照すると、ルールライタは望まれるクエリのタイプを選択する。第一に、ルールライタは、クエリウィンドウ１１４０を選択し、可能なクエリのリストから選択を行う。例えば、「書籍パッケージ」は、書籍の垂直的関心ドメインに関するクエリとして可能である場合がある。この検索は、ルールライタがクエリウィンドウ１１４０の「ＳＤＥ」（検索データエディタ）ボタンをクリックした時に開始される。ＳＤＥボタンは、検索データエディタを呼び出し、検索データエディタは図１４に例示されるグラフィカルユーザインタフェース（ＧＵＩ）１４００を提供する。ＧＵＩ１４００は、特定の関心項目に関する検索において、使用可能な属性のリストを表示する。例えば、書籍が検索されている場合、ＩＳＢＮまたはＵＰＣのような属性が、表示される。検索が他の項目に関する場合、その項目に対応する属性が列挙される。「映画上映」に関する検索では、映画パッケージ、時間、および上映日のような属性が列挙される（図４を参照して説明したブロック３３０を参照）。
【００８８】
ルールライタは、ＩＳＢＮ番号を対応するデータボックスに打ち込み、「Ｄｏｎｅ」をクリックする。ＧＵＩ１４００のボタン１４３０により、有利なことに、ルールライタは、様々な検索中の様々な検索基準をセーブすることができる。検索基準が入力された後、ルールライタは、「Ｄｏｎｅ」をクリックし、特定のデータソース（つまりＡｍａｚｏｎＢｏｏｋ）に関してルールが定義されていないため、図１５に例示されるグラフィカルユーザインタフェース（ＧＵＩ）１５００が現れる。ＧＵＩ１５００は、ルールライタが新しいルールを追加したいか、または検索データを変更したいかをたずねる。この例において、ルールライタは、「ａｄｄ」ボタンをクリックし、ＧＵＩ１５００は、図１６に例示されるグラフィカルユーザインタフェース（ＧＵＩ）１６００へと拡張する。
【００８９】
つぎに図１６を参照すると、ルールライタは、正しいタイプのクエリが強調表示されていることを確認する。この例においては、ＩＳＢＮが強調表示され、ルールライタは、「ｙｅｓ」ボタンをクリックする。ＡｍａｚｏｎＢｏｏｋのホームページがネットスケープブラウザにロードされたことをルールライタに知らせるために、図１７に例示されるグラフィカルユーザインタフェース（ＧＵＩ）１７００が現れる。ルールライタは、ＩＳＢＮルールに関連するＷｅｂページをブラウズするように指示される。検索ページがインターネットブラウザにロードされた後、ルールライタは、「ｄｏｎｅ」ボタンをクリックする。
【００９０】
図１８に例示されるグラフィカルユーザインタフェース（ＧＵＩ）１８００は、ルールライタが選択するフォームオプションを表示する。フォームが正しい場合、ルールライタは「ｄｏｎｅ」ボタンをクリックする。記載のフォームがルールライタにとって必要な選択肢ではない場合、ルールライタは、「ｎｅｘｔ」ボタンをクリックし、ページ上で他のフォームを確認する。一致するページが見つかると、図１９に例示されるグラフィカルユーザインタフェース（ＧＵＩ）１９００が表示される。
【００９１】
データ編成ツール１０２５（図１０）は、インターネットブラウザで結果として生じたページを表示する。このページが正しい場合、ルールライタは、ＧＵＩ１９００上の「ｏｋａｙ」をクリックする。図２０に例示されるグラフィカルユーザインタフェース（ＧＵＩ）２０００が現れ、検索で多数の項目が一致した場合に、ページ上の単一の項目をどのように検出するかをたずねる。ＧＵＩ２０００は、クエリされた項目に関する詳細を得るために、どこでＵＲＬを見つけるかを示すことにも使用される。単一の項目が発見された場合、正規表現を構築するのに十分な情報が存在しないため、ルールライタは、「ｄｅｆｅｒ」ボタンをクリックする。多数の項目が発見された場合、正規表現が、データウィンドウ２０１０に入力される。例えば、一人の著者がいくつかの書籍を執筆している可能性があるため、著者検索では、多数の項目が戻る場合がある。別の場合では、クエリが一つの項目と一致した場合でも、情報を得るために追加のＵＲＬリンクを辿る必要がある場合もある。
【００９２】
図２１に例示するグラフィカルユーザインタフェース（ＧＵＩ）２１００が、次に現れ、多数の製品ページを検出するために使用される。ルールライタが検索するアイテムに直接進む場合、正規表現を構築するための情報は必要ない。再び図１１を参照すると、コードウィンドウ１１９７には、検索したページからのＨＴＭＬコードが記入される。この時点において、ルールライタは、属性を指定する準備ができている。属性は、名前の隣のボックスに正規表現を入力することにより指定される。正規表現は、その中で一つのサブストリングを表現の結果として指定する必要がある（丸括弧を使用する）。例えば、正規表現「ｔｈｉｓ（ａｌｌ）ｍａｔｃｈｅｓ」は、その結果として「ａｌｌ」を戻すことになる（正規表現が一致可能であると仮定した場合）。例えば、書籍のタイトルを見つけるのに使用されるパターンを決定するには、ルールライタは、検索ウィンドウ１１９５に書籍のタイトルを打ち込む必要がある。様々なＨＴＭＬ信号を使用することができる。「＼ｓ^＊」は、ワード間で可能なブランクスペースを示すために必要である。検索ウィンドウ１１９５に入力された検索ストリングの第一の一致により、ＨＴＭＬコードで発見された第一の一致が強調表示される。例えば、タイトルは、何らかの追加情報と共に＜ｔｉｔｌｅ＞タグのペアの中で発見される場合がある。書籍のタイトルの例示的な属性は、「＜ｔｉｔｌｅ＞（［＾＜］^＊）＜／ｔｉｔｌｅ＞」にすることができる。属性が入力された後、その属性に対するすべての一致が見出される。
【００９３】
再び図１４を参照すると、検索データエディタ１４００は、タイプ依存属性に値を割り当てるために使用可能なフォームで構成される。ステータスウィンドウは、データ編成ツール１０２５が何を行っているかを示す。例示的な一実施形態の場合、ステータス状態はアイドルであり、インターネット上でクエリを実行し、キャッシュを使用している。クエリウィンドウ１１４０により、ルールライタは、問題のデータソースに関して望ましいクエリのタイプを設定し、ＳＤＥボタンを使用して検索基準を設定することができる。
【００９４】
スパイダ選択ウィンドウ１１３０により、ルールライタは、クエリ検索を行っていない場合に使用するスパイダを設定することができる。例示的な一実施形態の場合、可能なスパイダタイプは、フルと、増分と、特別と、参照とである。フルスパイダは、選択したタイプと一致するすべての項目を取り出す。増分スパイダは、通常、インターネットデータソースからのデータの更新を拾い出すために使用される。特別スパイダは、通常、書籍のベストセラー等、サイトが有している特別な何かを拾い出すために使用される。参照スパイダは、通常、サイトが依然として稼働しており、ルールが機能していることを確認するために使用される。
【００９５】
ベンダウィンドウ１１２０により、ルールライタは、作業対象のデータソースを設定することができる。検索ウィンドウ１１９５により、ルールライタは、ＨＴＭＬコードにおいて検索するテキストを保持することができる。コードウィンドウ１１９７には、テキスト入力の位置を示すカーソルが存在する。左矢印セット１１９０は、第一の数を含み、これはキャッシュから実行する時に検索を実行する場所の開始点となる。第二の数は、キャッシュ内のページの合計数を示す。このウィンドウの矢印セットは、ルールライタがキャッシュから実行する時に開始するページを制御する。右矢印セット１１８０は、検索したページをスクロールする矢印を有する。
【００９６】
スパイダは、クエリと似ているが、他のルールが適用できない時に呼び出される。スパイダは、指定されたタイプと一致するＷｅｂサイト内のすべてのオブジェクトに関する情報を収集する。スパイダは、いくつかのネスト化したループで構成され、各ループは階層の一レベル下へと進むように設計されている。次に図２２を参照する。ここには、書籍スパイダに関する例示的なスパイダ階層２２００が表示されている。レベル２２１０は開始ページであり、レベル２２２０は書籍カテゴリページを表し、レベル２２３０は書籍サブカテゴリページを表し、レベル２２４０は書籍ページを示す。
【００９７】
図２３を参照すると、グラフィカルユーザインタフェース（ＧＵＩ）２３００は、スパイダルールに関連するページのＵＲＬを検索するために使用される。スパイダ深度スライドルールにより、ルールライタは、実際の製品ページに到達するまでに下る必要があるリンクの数をデータ編成ツール１０２５に伝えることができる。上限スライドルールにより、ルールライタは、スパイダを使う項目数の制限を指定することができる。ＵＲＬが選択され、スパイダ深度および上限が選択された後、ルールライタは、「ｄｏｎｅ」ボタンをクリックする。図２４に例示されるグラフィカルユーザインタフェース（ＧＵＩ）２４００が表示される。ルールライタは、使用するスパイダに関する検索パターンを、図１１を参照して説明したクエリに関して入力した検索パターンと同じ方法で入力する。パターンが入力された後、ルールライタは、「ｂｕｉｌｄ」ボタンをクリックし、スパイダは稼働し始める。
【００９８】
図１１乃至２４を参照して表示および説明したグラフィカルユーザインタフェースにより、非エキスパートルールライタが、データ検索を実行し、情報検索に関するルールのフォームを作成することができることは、有利である。フォームが作成された後は、このフォームを何度も利用して、更新情報を収集することができる。更に、フォームは、ベンダによるＷｅｂサイト上の情報の配列および表示に対応した共通のフォームを使用して、ベンダのＷｅｂサイトで利用可能な大量の情報を検索するのに役立つ。非エキスパートによるルール作成のフォームが、Ｗｅｂサイトで利用可能な更新情報のコストを低減させることは、有利である。更に、このフォームが、インターネットからの情報の正確な検索を自動化することも有利である。
【００９９】
図２５は、データベース内の情報を融合する例示的なプロセスを表している。図２５に示される例示的な一実施形態の場合、フローチャート２５００は、誘導エンジン１５０（図２）によって実行される単純化した融合プロセス、または「クイックフュージョン」を表している。ステップ２５１０において、更新エンジン１６０は、ネットワーク２０から情報を受領し、イグジスタントサブシステム１４０を介して、この情報をデータベース１７０内のイグジスタントデータ構造に置く。融合エンジン１５０は、データベース１７０にアクセスするイグジスタントサブシステム１４０を介して、更新エンジン１６０からイグジスタントへのアクセスを有する。ステップ２５１０が実行された後、ステップ２５１５が実行され、融合エンジン１５０は、ステップ２５１０において検索されたイグジスタントに対応する属性定義テーブルから正確な融合属性を収集する。ステップ２５１５が実行された後、ステップ２５１２が実行され、融合エンジン１５０は、データベース１７０で検索されたイグジスタントからの各融合属性の「マッシュ」を実行し、容易に比較可能なフォームにする。例示的な一実施形態の場合、「マッシュ」フォームでは、スペース、前置詞、およびその他の重要でないワードは取り除かれる。「マッシュされた」フォーマットが、迅速な検索能力をもたらすことは、有利である。
【０１００】
ステップ２５２０が実行された後、ステップ２５２５が実行され、融合エンジン１５０は、データベースクエリを策定し、この中でデータソースは「同一」に設定され、ステータスは「カノニカル」に設定される。このクエリは、現在の情報と一致する同一のデータソースから、既に存在するカノニカルなイグジスタントを発見することを意図している。ステップ２５２５が実行された後、ステップ２５３０が実行され、データベース１７０内での一致が発見されたか否かが判断される。ステップ２５２５のクエリにより、データベース１７０内での一致が発見された場合、ステップ２５３５が実行され、データベース１７０に含まれるイグジスタントが更新される。
【０１０１】
ステップ２５２５のクエリからデータベース１７０内での一致が発見されなかった場合、ステップ２５４０が実行され、ステップ２５２５のクエリが、再策定され、データソースは「同一」に設定され、ステータスは「非カノニカル」に設定される。このクエリは、現在の情報と一致する同一のデータソースから、既に存在するイグジスタントを発見することを意図している。ステップ２５４０の後、ステップ２５４５が実行され、ステップ２５４０の再策定クエリからデータベース１７０内で一致が発見されたか否かが判断される。一致が発見された場合、ステップ２５５０が実行され、データベース１７０内のイグジスタントが更新される。
【０１０２】
データベース１７０内で一致が発見されなかった場合、ステップ２５５５が実行され、データソースが「任意」に設定され、ステータスが「カノニカル」に設定されたクエリが、再策定される。このクエリは、現在の情報と一致する任意のデータソースから、既に存在するカノニカルなイグジスタントを発見することを意図している。ステップ２５５５の後、ステップ２５６０が実行され、データベース１７０内での一致が発見されたか否かが判断される。データベース内での一致が発見されない場合、ステップ２５６５が実行され、データベース１７０にイグジスタントが追加される。
【０１０３】
データベース１７内での一致が発見された場合、またはステップ２５５０が実行された後、ステップ２５７０が実行され、一致がシステムイグジスタントであるか否かが判断される。一致がシステムイグジスタントである場合、ステップ２５７５が実行され、このシステムイグジスタントが更新される。一致がシステムイグジスタントではない場合、ステップ２５８０が実行され、カノニカルなシステムイグジスタントが形成される。ステップ２５８０が実行された後、ステップ２５８５が実行され、データベース１７０にイグジスタントが追加される。ステップ２５８５の後、ステップ２５９０が実行され、融合テーブルが更新される。
【０１０４】
図２５に例示されたデータベース内の情報を融合する例示的なプロセスが、多数のＷｅｂサイト上にある情報の比較を提供することは、有利である。このため、あるＷｅｂサイトが別のＷｅｂサイトと同じ情報を含んでいるか否かを判断することができる。更に、ボイスポータル１０のデータベース１７０に含まれる情報には、インターネットベースソースからの情報、情報の関係、および情報の連関を継続的に追加可能であり、これはデータソースから検索された情報の有用性を大きくする。
【０１０５】
図２６は、融合の例示的なプロセスに含まれるステップを示すフローチャート２６００を表している。図２６を参照して説明するこの例示的なプロセスにおいては、図２５を参照して説明したフローチャート２５００に示す融合プロセスよりも包括的な融合プロセスが表示されている。ステップ２６１０において、融合エンジン１５０は、データベース１７０から属性定義テーブルを読み出す。ステップ２６１０が実行された後、ステップ２６１５が実行され、融合エンジン１５０は、高度な融合を必要とする各イグジスタントタイプに関して融合制御言語を読み出す。ステップ２６１５が実行された後、ステップ２６２０が実行され、融合エンジン１５０が、融合ファイルを中間コンピュータコードにコンパイルする。ステップ２６２０が実行された後、ステップ２６２５が実行され、融合エンジン１５０が、以前に融合されたイグジスタントをメモリに保持する。ステップ２６２５の後、ステップ２６３０が実行され、融合エンジンは、属性を収集し、等価のセットにする。ステップ２６３０の後、ステップ２６３５が実行され、属性がテキストであるか否かの判断が行われる。融合エンジン１５０が、属性はテキストではないと判断した場合、ステップ２６４０が実行され、値が、インデックス化される。融合エンジン１５０が、属性はテキストであると判断した場合、ステップ２６４５が実行され、融合エンジン１５０は、属性の中に存在するサブストリングをインデックス化する。
【０１０６】
ステップ２６４５の後、ステップ２６５０が実行され、融合エンジン１５０は、テキストが構造化されているか否かを判断する。テキストが構造化されていないと判断された場合、ステップ２６７０が実行される。テキストが構造化されていると判断された場合、融合エンジン１５０は、ステップ２６５５において、テキストの構造セグメントの位置を特定し、これを分離する。ステップ２６５５の後、ステップ２６６０が実行され、融合エンジン１５０は、分離されたパートを解析し、意味情報を識別する。ステップ２６６０の後、ステップ２６６５が実行され、融合エンジンは、意味情報をインデックス化する。ステップ２６６５の後、ステップ２６７０が実行され、融合エンジン１５０は、妥当性チェックを実行し、データベース１７０の完全性を検証する。ステップ２６７０の後、ステップ２６７５が実行され、融合エンジン１５０は、融合するイグジスタントを検索する。
【０１０７】
ステップ２６７５の後、ステップ２６８０が実行され、融合エンジン１５０は、対応するイグジスタントタイプに関する融合基準およびマッチングプログラムを起動する。融合基準およびマッチングプログラムには、図１０を参照して説明したように確立されたイグジスタントルールの使用が関係する。ステップ２６８０の後、ステップ２６８５が実行され、融合エンジン１５０は、融合基準およびマッチングプログラムから第一の融合ルールを実行し、すべての一致を戻す。ステップ２６８５の後、ステップ２６９０が実行され、許容できる一致が発見されたか否かの判断が行われる。例示的な一実施形態の場合、許容できる一致は、属性の所定のパーセンテージ（例えば、７０％）が共通なものである。代替実施形態の場合、許容できる一致は、すべての属性が同じ値を有するものである。許容できる一致が発見された場合、ステップ２６９７が実行され、融合エンジン１５０は、イグジスタントを融合する。許容できる一致が発見されなかった場合、ステップ２６９１が実行され、次の融合ルールが実行され、すべての一致が戻される。
【０１０８】
ステップ２６９１の後、ステップ２６９２が実行され、許容できる一致が発見されたか否かの判断が行われる。許容できる一致が発見された場合、ステップ２６９７が実行され、融合エンジン１５０は、イグジスタントを融合する。イグジスタントの融合には、融合されるイグジスタントに関連し、かつその中にすべての情報を包含する新しいイグジスタントの作成が、含まれる。許容できる一致が発見されなかった場合、ステップ２６９３が実行され、最後のルールがテストされたか否かの判断が行われる。最後のルールがテストされた場合、ステップ２６９１が再度実行される。最後のルールがテストされていない場合、ステップ２６９４が実行され、融合エンジン１５０は、強い部分一致が存在するか否かを判断する。例示的な一実施形態の場合、強い部分一致とは、一致が特定のパーセンテージ、例えば、７０％以内のものである。強い部分一致が存在する場合、ステップ２６９８が実行され、人間による検査が行われる。部分一致が発見されない場合、ステップ２６９５が実行され、融合エンジン１５０は、融合作成を拒否し、ステップ２６９９が実行され、新しいイグジスタントが作成される。
【０１０９】
図２６に例示されるデータベース内の情報を融合する例示的なプロセスが、同一または異なるデータソースからの情報の自動比較を提供することは、有利である。このため、データベース１７０に含まれる情報は、継続的に更新し、他のデータソースからの情報との付加的相関性を与えることができる。更に、融合によって、インターネットで個別に利用可能な無数のデータベースより完全で堅牢な統一データベースの編纂が可能となる。
【０１１０】
図２７は、二つのデータ構造からカノニカルなデータ構造を作成する例示的なプロセスを表している。データファイル２７００は、固有の識別番号によって識別され、第一のデータファイル２７１０と、第二のデータファイル２７２０と、カノニカルデータファイル２７３０とを有する。例示的な一実施形態の場合、第一のデータファイル２７１０は、ＩＭＤＢ（「ＩｎｔｅｒｎｅｒＭｏｖｉｅＤａｔａＢａｓｅ」）Ｗｅｂサイト（ｈｔｔｐ：／／ｗｗｗ．ＩＭＤＢ．ｃｏｍ）から検索した特定の映画に関する情報を有する。第二のデータファイル２７２０は、Ｒｅｅｌ．ｃｏｍＷｅｂサイトから取得した特定の映画に関する情報を有する。図２７に例示された例において、データファイル２７１０は、タイトル「ＢｏｙｓｏｆＡｒｉｚｏｎａ」と、監督「Ｗｉｌｔｚ」と、公開年「１９９７」と、シノプシス「ｇｒｅａｔｍｏｖｉｅ」とを有する。同様に、データファイル２７２０は、タイトル「ｔｈｅＢｏｙｓｏｆＡｒｉｚｏｎａ」と、監督「ＢｏｂＷｉｌｔｓ」と、公開年「１９９８」と、ブランクであるシノプシスとを有する。
【０１１１】
カノニカルデータファイルを作成するプロセス中には、特定のタイプの情報に関するルールを有するルールファイル２７４０が導入される。図２７に示す例において、ルールファイル２７４０は、映画の属性に関する情報を含む。ルール２７４０の適用により、データファイル２７１０とデータファイル２７２０とから最も完全なタイトル、この場合はデータファイル２７２０からのタイトル「ｔｈｅＢｏｙｓｏｆＡｒｉｚｏｎａ」を取り出すことにより、クロニクルデータファイル２７３０が作成される。それが、監督のファーストネームおよびラストネームを含むのでデータファイル２７１０よりも完全であると言う理由から、監督情報は、データファイル２７２０から取得される。データファイル２７１０に記載の公開年とデータファイル２７２０に記載のものとに、不一致が存在する場合がある。事前の情報に基づいて、この不一致は解消され、データファイル２７２０がより正確な公開年を有することが示される。データファイル２７２０のシノプシスはブランクであるため、クロニクルデータファイル２７３０は、データファイル２７１０のシノプシスを含む。
【０１１２】
図２７を参照して説明したクロニクルデータファイルを作成するプロセスにより、より完全で正確な情報を有するデータが作成されることは、有利である。更に、このプロセスによって、多数のＷｅｂサイト間での情報の比較が可能となる。更に又、クロニクルデータファイルを作成するプロセスによって、データファイル間の相関性および連関関係が増加する。
【０１１３】
図２８は、Ｗｅｂから取得したデータを分離し、かつデータベースでの保存のためにそのデータを変換する間に実行される動作の機能図２８００を表している。この例示的なプロセスには、ネットワーク２０からのデータをデータが配列および編成されるデータ構造２８１０に抽出することが含まれる。例えば、交通情報に関するデータは、説明と、幹線道路と、交差路と、時間と、日付と、重大性の評価とに関する情報を有するように、インターネットから抽出することができる。データ構造２８１０は、データの配列および編成によりデータ構造２８１０にすることが可能なテキストパターンおよび記述を有するルール２８１５の使用によって、作成および編成される。データ構造２８１０は、データベース上のデータファイルに格納される。データ構造２８１０のデータには、データ構造２８２０を作成するために第一の用語置換フォームが適用される変換処理が行われる。ルール２８２５は、変換テーブルの語彙登録項を含め、データ構造２８２０を作成するために用語置換中に適用される。交通情報の例では、「Ｒｄ」は「ｒｏａｄ」に変換され、「Ｉ．」は「ｉｎｔｅｒｓｔａｔｅ」に変換され、「Ｒｔ．」は「ｒｏｕｔｅ」に変換される。
【０１１４】
データ構造２８２０に含まれるデータは、その後、転送データに関する属性語句文法を適用するルール２８３５に従って、データ構造２８３０内の解析フォームの中に置かれる。交通情報の例において、北、西、南、および東のような「方角」が識別され、「ｉｎｔｅｒｓｔａｔｅ」または「ｈｉｇｈｗａｙ」のような「道路識別子」が決定される。データ構造２８３０内のデータは、その後、用語配列ルール２８４５を適用することにより、データ構造２８４０内の再配列フォームに配置される。データ構造２８４０内のデータは、第二の用語置換フォームによって操作され、語彙変換テーブルからのルール２８５５を適用することにより、データ構造２８５０内に配置される。例えば、用語「Ｓｔ．」は、語彙変換テーブルにおいて、位置識別子＜ｓｔｒｅｅｔｓｔ．＞または＜ｃｉｔｙｓｔ．＞に基づいて、「ｓｔｒｅｅｔ」または「ｓａｉｎｔ」のいずれかに決定される。
【０１１５】
語彙変換が実行された後、データは、未融合の標準化されたタグ付きフォーマットで、データ構造２８６０に配置される。データ構造２８６０は、データベース２８５０に常駐することが、好ましい。標準化されたタグ付きフォーマットとは、データを容易に検索および比較可能な均一の編成とＨＴＭＬタグとを有するフォーマットを指す。多くの場合、ＨＴＭＬタグは、データのタイプ、位置、および長さに関する情報を提供する。未融合とは、データが、図２５および２６を参照して説明した融合プロセスを通過していないことを意味する。
【０１１６】
図２８を参照して説明したデータ分離プロセスが、Ｗｅｂからデータを取り出し、データベース内の標準化されたタグ付きフォーマットに変換することは、有利である。標準化されたタグ付きデータは、編成、操作、および融合のために作成される。このデータ分離プロセスが、均一であり、広範なデータソースからのデータで機能することは有利である。したがって、一般的には、このプロセスには、インターネットソースからデータを取得することと、取得したデータにより第一のフォーマットで第一のデータファイルを作成することと、語句が特定のインタフェースに関連する第二のフォーマットになるように、取得データから語句を生成することとが、含まれる。取得データを第一および第二のフォーマットに変換するためには、広範なアプリケーションを使用することができる。例えば、テキストパターンと、語彙変換テーブルと、属性語句文法と、用語配列ルールとを使用して、取得データを、データベース内のデータファイルにセーブされる均一で検索可能なフォーマットに変換し、その後、セーブデータをインタフェース固有フォーマットに変換することが可能である。代替実施形態の場合は、その他のパターン、テーブル、ルール、およびデータ操作アプリケーションを使用することができる。
【０１１７】
図２９は、何らかのユーザインタフェースプラットフォーム（ＷＡＰ、Ｗｅｂ、電話、ＡＳＲ、ＴＴＦ等）を介した、データベース１７０からボイスポータル１０のユーザに対するデータの変換を示す機能図２９００である。（図２９にも表示される）データ構造２８６０に含まれるデータは、標準化されたタグ付きデータに関する属性語句文法を有するルール２９１５を適用することにより、データ構造２９１０内の解析フォームの中に置かれる。属性語句文法は、標準化されたタグ付きデータを取り出し、識別された属性を有する知覚可能な語句を作成する。データ構造２９１０からのデータは、その後、語彙登録項変換テーブルを有するルール２９２０を使用して、用語置換フォームを適用することにより、データ構造２９２０内に配置される。例示的な一実施形態の場合、ルール２９２０の語彙登録項変換テーブルは、特定のインタフェースに対応するデータ出力構造を列挙する。例えば、用語「ｒｏｕｔｅ」は、ＷＡＰアプリケーションに関しては「Ｒｔ．」に変換され、発話を使用した電話アプリケーションに関しては「Ｒｏｕｔｅ」に変換される。同様に、用語「Ｕ．Ｓ．」は、ＷＡＰアプリケーションに関しては「Ｕ．Ｓ．」に変換され、発話を使用した電話アプリケーションに関しては「ｙｏｕｅｓｓ」に変換される。
【０１１８】
データ構造２９２０からのデータは、ルール２９３５を適用することにより、データ構造２９３０内の再配列フォームに配置され、使用される出力デバイスに応じて用語交換ルールが適用される。用語再配置ルールは、様々なユーザインタフェースに最も適合する配列に用語を移動させる。データ構造２９３０内のデータは、その後、データ構造２９４０内に配置され、語句生成文法を有するルール２９４５を適用することにより、文が生成される。例えば、「＜幹線道路＞の＜交差点＞と＜交差点＞との間で＜重大性＞の交通事故が発生」という文を生成することができる。データがデータ構造２９４０のフォーマットになった後、ＷＡＰ、Ｗｅｂ、電話、およびＡＳＲのような様々な出力インタフェース向けに準備が行われる。
【０１１９】
図２９を参照して説明したデータ変換プロセスが、データを取り出して、広範なユーザインタフェース向けに準備を行う均一なプロセスであることは、有利である。例えば、このプロセスでは、Ｗｅｂソースからデータを抽出し、意味的に識別し、発話インタフェースを介した発話伝送向けに準備することができる。同時に、このプロセスでは、同じデータをＷＡＰデバイスまたはＷｅｂアプリケーションへの伝送向けに準備することができる。
【０１２０】
図３０乃至３３は、ユーザとボイスポータル１０との間の例示的な対話を具体的に示すいくつかの動作経路を表している。ユーザインタフェース１１０は、図３２乃至３３を参照して説明されるように、ユーザに適切な発声をさせるために、明示的な指示を使用することが好ましい。
【０１２１】
図３０は、ボイスポータル１０の様々な機能を示すプロセスブロックを有する、例示的なシステムの概要を示すフロー図３０００である。例示的な実行経路において、ブロック３０１０では、ボイスポータル１０は「Ｑｕａｃｋへようこそ、アメリカンエキスプレスが提供します」と話すことによりユーザを迎える。ボイスポータル１０は、ユーザを識別する手段として発信者ＩＤを使用することが好ましい。好適な実施形態の場合、電話番号は、データベース１７０内の顧客属性として格納される。または、電話番号は、顧客データベースに格納される。ボイスポータル１０は、続いて、「こんにちは、スティーブ・ウッズ。ＰＩＮを発声するか、テンキーを使ってそれを入力してください。あなたがスティーブではない場合は、あなたの電話番号を発声するか、それを入力してください」と述べる。ユーザは、口頭で「５０８２」と応答し、自分のＰＩＮを伝える。認証が行われた後、ボイスポータル１０は、ブロック３０２０へ進む。ブロック３０２０では、ボイスポータル１０は、「あなたはＱｕａｃｋのランウェイにいます。次のリストの中で関心のあるカテゴリの名前を言ってください。映画、天気、交通、株式、スポーツ」と知らせる。ユーザは、カテゴリ名または別れの言葉で応答する。カテゴリ名が提供された場合、ボイスポータル１０は、ブロック３０３０へ進む。別れの言葉が与えられた場合、ボイスポータル１０は、ボイスポータル１０を正常に終了させる。例示的な応答において、ユーザは「天気」と言い、ボイスポータル１０はブロック３０３０へ進む。ブロック３０３０では、ボイスポータル１０は、「Ｗｅａｔｈｅｒへようこそ、ＷｅａｔｈｅｒＣｈａｎｎｅｌが提供します」と言い、ブロック３０４０へ進む。ブロック３０４０では、識別固有イグジスタントサブシステムが実行される。
【０１２２】
ブロック３０４０の後、ブロック３０５０が実行され、ブロック３０４０の識別固有イグジスタントサブシステムにおいて、イグジスタントが発見されたか否かに関して判断が行われる。イグジスタントが発見されない場合、制御は、ブロック３０３０に戻る。イグジスタントが発見された場合、ブロック３０６０が実行され、（図３３を参照して説明される）発見されたイグジスタントサブシステムが実行される。
【０１２３】
次に図３１を参照すると、ブロック３０４０（図３０）において実行される識別固有イグジスタントサブシステムは、データベース１７０が現在の垂直的ドメイン（例えば、天気、交通、映画）に関する属性依存グラフからの属性を提供するブロック３１１０を含む。属性依存グラフに属性がなくなった場合、制御はブロック３１１５に移行し、ここでイグジスタント検索が失敗したことが記録される。ブロック３１１５の後、制御はブロック３０３０（図３０）に移行する。ブロック３１１０（図３１）の後、ブロック３１２０が実行され、データベース１７０によって提供された属性値セットから、属性語彙が構築される。ブロック３１２０が実行された後、ブロック３１３０が実行され、ボイスポータル１０は、属性値プロンプトに対するユーザの応答を得るために、方法Ｎに続いて自動言語認識（ＡＳＲ）技術を使用する。例えば、ボイスポータル１０は、例示的な方法Ｎの例として、郵便番号によってユーザの場所を要求することが可能である。ユーザは、「５３０４５」等、自分の郵便番号を伝えることにより応答できる。
【０１２４】
ブロック３１４０では、音声認識が成功したか否かについて判断が行われる。成功していない場合、予備方法Ｎ＋１に続くＡＳＲ技術により、ブロック３１３０が実行される。例えば、天気の垂直的ドメインにおいて、予備方法Ｎ＋１は、ユーザの居場所である州と都市をたずねることにできる。好適な実施形態の場合、予備方法は、リストから属性を選択することと、属性値セットを区切りスペースで制約すること（例えば、州を取得した後、都市名を取得する）と、属性値のスペリングを行うこととが含まれる。音声認識が成功すると、ボイスポータル１０は、取得された属性によりデータベース１７０を検索するブロック３１５０が実行される。ブロック３１５０が実行された後、フローチャート３２００（図３２）が実行される。
【０１２５】
図３２を参照すると、フローチャート３２００は、識別固有イグジスタントサブシステムの一部を表している。ブロック３１５０が実行された後（図３１）、データベース１７０の検索により一致したイグジスタントの数を決定するためにブロック３２１０が実行される。製品データベースの検索において発見された一致の数に応じて、様々な行動が行われる。一致が発見されなかった場合、ブロック３２２０が実行され、複合固有キーを探すか否かについて判断が行われる。データベース１７０には含まれないが、インターネット上で望ましい項目を発見するのに使用することが可能な一つ以上の固有キーまたは識別子がある場合、複合固有キーが存在する可能性がある。
【０１２６】
一致が一つ発見された場合、ブロック３２３０が実行され、ボイスポータル１０は、一致が正しいイグジスタントであるかを検証する。一致の数が１より大きいが、リストの最大数より少ない場合、ブロック３２４０が実行され、ユーザは、一致のリストからイグジスタントを特定するように要求される。リスト内で可能な登録項の最大数より多くの一致が発見された場合、ブロック３２５０が実行され、その属性が「拡張可能」であるか否かが判断される。言い換えれば、その属性について更に多くの情報を提供可能であるか否かについて判断が行われる。情報を更に提供できない場合、制御はブロック３１１０（図３１）に戻り、属性依存グラフから別の属性が取得される。属性が拡張可能である場合、ブロック３２６０が実行され、属性の拡張が試みられる。属性を拡張できる場合、制御はブロック３１２０（図３１）に移行し、語彙セットが構築され、属性値を取得するためにＡＳＲ技術および方法が使用される。属性を拡張できない場合、制御はブロック３１１０（図３１）に移行し、属性依存グラフから別の属性が取得される。属性の拡張により項目のリストが生じた場合、制御はブロック３２４０に移行する。
【０１２７】
次にブロック３２２０で実行されるクエリを参照すると、ＷＷＷ検索に使用する複合固有キーが存在しないと判断された場合、制御は、ブロック３１１０（図３１）に移行する。複合固有キーが存在する可能性があると判断された場合、制御は、ブロック３２７０に移行し、ＷＷＷを検索するか否かの判断が行われる。ＷＷＷを検索しない場合、制御は、現在の垂直的ドメインの最上レベルであるブロック３０３０（図３０）に移行する。ＷＷＷを検索する場合、制御はブロック３２８０に移行する。次にブロック３２３０およびブロック３２４０を参照すると、正しいイグジスタントが発見された場合、または正しいイグジスタントがリストから発見された場合、制御は、ブロック３２８０に移行する。ブロック３２３０およびブロック３２４０において正しいイグジスタントが発見されなかった場合、制御はブロック３２２０に移行し、項目を発見するために検索を継続することが可能な複合固有キーが存在するか否かが判断される。ブロック３２８０では、Ｗｅｂルックアップが実行される。この時点で、顧客には、様々な長さのターゲット広告を提示することができる。広告については、図３６を参照して更に詳しく説明される。ブロック３２８０中、ブロック３０６０が実行され、発見されたイグジスタントサブシステムが実行される。
【０１２８】
図３３を参照すると、発見されたイグジスタントサブシステムは、発見された項目の顧客データベースにログが作成されるブロック３３１０を含む。好適な実施形態の場合、顧客データベースは、データベース１７０に含まれる。ブロック３３１０の後、ブロック３３２０が実行され、データベース１７０の情報から、垂直的ドメインに適した提示のために、情報が準備される。ブロック３３２０の後、ブロック３３３０が実行され、関連情報およびコマンド文法が構築される。例えば、映画の垂直的ドメインにおいて、特定の劇場での映画上映のリストが再生される場合、文法には、ユーザが特定の映画に関する詳しい情報を要求できるように映画のタイトルが含まれることになる。
【０１２９】
ブロック３３４０では、ユーザから情報が戻される。好適な実施形態の場合、受け入れ可能なコマンドとして可能なものには、更に詳しい情報を聞くためのコマンドと、特定のソースからの情報を聞くためのコマンドと、関連情報（例えば、より安価、より良質）を聞くためのコマンドと、垂直的ドメインに適した行動（例えば、入札額の増加、場所の変更）を行うためのコマンドとが含まれる。ブロック３３４０の後、ブロック３３５０が実行され、次の活動が取得される。新しい垂直的ドメインが望まれる場合、制御は、ブロック３０２０（図３０）に移行する。現在の垂直的ドメインの最上部から新たに選択することが望まれる場合、制御は、ブロック３０３０（図３０）に移行する。新しいイグジスタントが望まれる場合、制御は、ブロック３０４０（図３０）に移行する。
【０１３０】
再び図３２を参照すると、ブロック３２８０が実行された後、ブロック３２９０が実行され、データベース１７０を更新することによりＷｅｂルックアップの結果が調整される。ブロック３２９０でのＷｅｂ結果の調整中、ブロック３２９５でスマート遅延処理を実行することが可能である。ここでは、広告、または遅延を処理するその他の形態が、実行される。ブロック３２９５でのスマート遅延処理は、顧客データベースおよび広告データベースからの情報を使用する。好適な実施形態の場合、顧客データベースおよび広告データベースは、データベース１７０のサブセットである。代替実施形態の場合、顧客データベースおよび広告データベースは、物理的に別個のデータベースである。
【０１３１】
動作において、本明細書で説明するインターネットからの情報への音声アクセスに関するシステムおよび方法は、顧客が関心のある垂直的ドメイン（映画、ショッピング等）を特定し、その後、垂直的ドメインにおいて可能なあらゆる事柄の範囲からのユーザの応答を、消費者がもとめる事柄の一つまたはセットへと「ファンネリング」することは、有利である。この垂直的ドメイン内でのファンネリングは、特定の項目へのファンネリングを行うために事前に定義された「経路」に従った、製品またはサービスの属性に関するユーザへのシステムの指示による質問に関係する。経路は、確認および具体化する製品に関する制約の順序付けに関して定義される。
【０１３２】
図３４は、ボイスポータル１０がユーザの応答をファンネリングすること、およびユーザの応答の音声認識において非常に高い精度を達成することを可能にするファンネリングプロセスのフロー図３４００である。ステップ３４１０において、ユーザは、ボイスポータル１０に電話をする。ステップ３４１０の後、ステップ３４１５が実行され、上で説明した可能である様々な方法を使用して、発信者が識別される。ステップ３４１５の後、ステップ３４２０が実行され、ユーザは、垂直的関心ドメインを選択する。次に、ステップ３４２５が実行され、選択した垂直的関心ドメインに対する属性ファンネリング特性が開始される。ステップ３４２５の後、ステップ３４３０が実行され、ボイスポータル１０は、この垂直的関心ドメインにおいてユーザが嗜好を有するか否かを判断する。嗜好が存在し、ユーザがこれを無効にすることを望まない場合、制御はステップ３４６０に移行し、品目またはサービスが、ユーザの嗜好に基づいて発見されたものとして示される。
【０１３３】
利用可能な嗜好がない場合、またはユーザが自分の嗜好を無効にした場合、ステップ３４３５が実行され、属性語彙セットが構築される。語彙セットにより、ボイスポータル１０が、限られた数の可能な応答を有し、この中のものを垂直的関心ドメインにおけるこの時点でのユーザの応答の音声認識に使用することができることは、有利である。定義済みの語彙セットにより、ボイスポータル１０が、高い認識率で従来の音声認識技術を達成することは、有利である。例えば、ユーザがメジャーリーグベースボール（ＭＬＢ）チームを選択し、ＭＬＢチームに関して考えられる要求の語彙セットが構築された後、「Ｂｒｅｗｅｒｓ」という用語は認識が容易になる。こうした語彙セットは、同じ情報に関する様々な異なるタイプのユーザ入力を有することができる。例えば、ＭＬＢチームの例において、語彙セットは、ＭＬＢチームに関連するすべての都市または州名と、ＭＬＢチームのマスコットとを有することができる。したがって、「Ｍｉｌｗａｕｋｅｅ」および「Ｂｒｅｗｅｒｓ」は、両方ともＭＬＢチームの語彙セットの一部となる。
【０１３４】
適切な語彙セットが構築された後、ステップ３４４０が実行され、ボイスポータル１０は、属性に関するクエリを行う。例えば、「どのメジャーリーグベースボールチームについて聞きたいですか？」等である。ステップ３４４０の後、ステップ３４４５が実行され、属性が特定される。属性が特定されない場合、ステップ３４４７を実行し、属性の特定に関する予備手順を実施することができる。ステップ３４５０において、ボイスポータル１０は、「最終状態」つまり項目又サービスが発見されたポイントに達したか否かについて判断する。「最終状態」に達していない場合、ステップ３４５５が実行され、次の属性がアクセスを受け、制御はステップ３４３０に戻る。上の野球の例では、チーム名のみでは最終状態に到達しない。最近の試合結果、選手の統計データ、チームの順位、またはその他の関連情報のような、その他の「更に狭い」属性が要求される必要がある。ステップ３４６０が実行された後、ステップ３４６５が実行され、発見された項目またはサービスが、ユーザに報告される。
【０１３５】
例示的な一実施形態の場合、ユーザは、以下の方法で項目を選択する。ユーザは、第一に、関心ドメイン（例えば、ｅ−コマース、交通情報、天気情報、映画、その他）を指定する。ユーザは、次に、項目の属性を指定することにより、項目（例えば、書籍、玩具、交通情報について関心のある路線、天気情報について関心のある都市、その他）を選択する。その後、ユーザは、項目のドメイン（例えば、製品、交通、天気、映画、その他）に応じて、特定項目に関する詳細な情報が提供される。例えば、ｅ−コマースの関心ドメインのレビューにおいては、価格、運賃、および可用性を有するベンダ情報が利用可能である。映画の関心ドメインにおいては、監督、プロデューサ、およびキャストが提供される。オークションの関心ドメインでは、未決定の入札が利用可能となる。
【０１３６】
ユーザが、現場を特定する多数の方法（例えば、郵便番号、町名、都市エリア「ボストン北部、西部」、その他）を用い、現場によって情報を要求することができることは、有利である。例示的な一実施形態の場合、郵便番号の周囲で位置を特定する戦略が使用され、これには、近郊の名前をたずねることと、都市、更には州へと後退することと、その後、再びズームインすることとが含まれる。例示的な一実施形態の場合、ユーザには、要求に応じて、情報が前回更新された日付と時間が、提供される。ユーザに提示されるすべてのデータは、そのドメインに適した現在性のものであることが、好ましい。ユーザには、「純粋な」ソースの情報または単独のソースからの情報について、情報のソースが通知される（「ＸＸＸＸＸ提供」）。好適な実施形態では、あらゆる選択ポイントにおいて、「ヘルプ」または「使用説明」のオプションを利用することができる。
【０１３７】
ユーザは、そのドメインに応じて、項目属性に基づいた項目の比較を要求することができる。ユーザは、そのドメインに応じて、「より安価」な項目、「より良質」な項目、および「関連」する項目の特定を要求することができる。ユーザが、その関心ドメインに応じて、多数のユーザ定義リストに、項目を明示的に記録することができることは、有利である。ユーザは、自分のリストから項目を再調査することができる。ユーザは、自分のリストの項目に関して、（そのドメインに応じて）情報の変化を電話または電子メールで通知することを要求できる。
【０１３８】
図３５は、ボイスポータル１０を使用してトランザクションを実行する例示的なプロセスのフロー図３５００を表している。ステップ３５１０において、ユーザは、ボイスポータル１０にアクセス（電話または発信）する。ステップ３５１０の後、ステップ３５１５が実行され、ユーザが望んでいる品目またはサービスを特定するために、ファンネリングプロセスが実行される。こうしたファンネリングプロセスは、図３４を参照して説明した、フロー図３４００に例示する動作を実行する。
【０１３９】
ステップ３５１５の後、ステップ３５２０が実行され、ボイスポータル１０は、ユーザに対して、特定した品目またはサービスに関連する希望のトランザクションを指定するように求める。ステップ３５２０が実行された後、ステップ３５２５が実行され、ボイスポータル１０は、指定されたトランザクションを実行するために、適切なボイスポータルルールを特定する。ステップ３５２５の後、ステップ３５３０が実行され、指定されたトランザクションを実行するために、このルールが実行される。トランザクションには、品目またはサービスを購入すること、オークションに入札すること、または他の任意のインターネット上で可能なタイプのトランザクションを含めることができる。ステップ３５３０の後、ステップ３５３５が実行され、ボイスポータル１０は、トランザクションの結果を記録する。好ましくは、この結果は、データベース１７０に記録される。ステップ３５３５の後、ステップ３５４０が実行され、トランザクションは、ユーザに報告される。
【０１４０】
様々なトランザクション（入札、鑑賞、購入、追跡）が、様々なドメインに対し適切となる。例えば、ｅ−コマースの関心領域において、ユーザは、選択したベンダから特定した製品を注文することができる。更に、ユーザは、後の時点で購入するために、品目をショッピングカートに追加することができる。ユーザは、注文時、請求するクレジットカードおよび届け先住所を（ユーザプロフィールから、または手動で）指定することができる。ユーザは、更に、以前に注文した製品に関するステータス情報を要求することもできる。別の例として、オークションの関心ドメインでは、ユーザは、既存の入札を増額することが可能であり、またはユーザは、新しいオークションに入札することができる。
【０１４１】
ボイスポータル１０を使用してトランザクションを実行するプロセスでは、ユーザが、コンピュータ上での手動作業を行う必要が、全くないことは、有利である。ユーザは、マウスをクリックすること、コンピュータキーボードのキーを押すこと、または他の任意のコンピュータインタフェースによる手動作業（マウスクリック、キーボード入力等）を行うことなく、品目を購入し、入札を行い、または他の任意のインターネットトランザクションを行うことができる。したがって、図３５を参照して説明したプロセスは、「ノークリック」インターネットトランザクションプロセスにすることができる。ユーザは、電話のタッチパッドを利用することが可能であり、更に「ノークリック」インターネットトランザクションを実行することもできる。
【０１４２】
図３６Ａは、ボイスポータル１０を使用して広告する例示的なプロセスのフロー図３６００Ａを表している。広告サブシステム１２０が、特定のユーザにどの広告を再生するかを決定する方法を有することは、有利である。一般に、この方法は、ユーザの人口統計データ、場所の人口統計データ、および現在の垂直的関心ドメイン等、コンテクストに基づいた選択制約の設定に関係する。選択制約が設定された後、この方法では、この制約に基づいて広告データベースをクエリし、可能な広告のリストを検索する。可能な広告のリストは、各広告の販売基準に基づいて再順序化される。広告は、この再順序化リストから選択され、ユーザに提示される。
【０１４３】
フロー図３６００Ａを参照すると、ステップ３６１０Ａにおいて、ボイスポータル１０の広告サブシステム１２０は、ユーザに提示する広告に関する選択制約を設定する。一実施形態の場合、この選択制約は、ユーザの人口統計データ、場所の人口統計データ、および現在選択されている垂直的関心ドメイン（存在する場合）のようなユーザ中心情報と、広告の販売基準、反復の欠如、およびその他の広告有効性要素のような広告中心情報とに基づく。こうした制約または基準は、紹介用スポンサシップ広告、垂直的スポンサシップ広告、およびコマーシャル広告のような、様々なタイプの異なる広告からの選択において使用される。ステップ３６１０Ａの後、ステップ３６１５Ａが実行され、データベース１７０は、ステップ３６１０Ａにおいて選択された制約に基づく可能な広告のリストに関してクエリされる。
【０１４４】
ステップ３６１５Ａの後、ステップ３６２０Ａが実行され、可能な広告のリストは、販売基準要素に基づいて、再順序化される。一実施形態の場合、販売基準は、（１）この広告に関して、広告配信率は達成されたか？　（２）この広告に関して、ターゲット配信最低限度は達成されたか？　を判断するために使用される。販売基準が、各広告顧客が配信に関する要件を満足させる状態を確保するために使用されることは、有利である。一実施形態の場合、どれを最初に配信するべきかと言う広告の優先順位を定めるために、比率が計算される。
【０１４５】
以下に、広告をどのように順序化するかの決定要素として比率を使用する例が、提供される。広告Ｘは、その契約において、１００，０００回の配信が必要である。ボイスポータル１０は、既に広告Ｘを７，０００回、配信している。契約の開始日は５月１０日で、終了日は６月７日である。現在の日付は、５月１５日とする。したがって、例示的な比率は、以下のように決定される。
・契約開始からの経過日数＝５日。
・契約の長さ＝２７日間。
・広告を再生する必要がある日数＝２２日。
・再生された広告のパーセント＝７，０００／１００，０００〜＝７％。
・既に再生した日数のパーセント＝５／２７〜＝１８．５％
このため、この例示的な最終比率は、次のようになる。
（既に再生した日数の％−再生された広告の％）／契約の残り日数
この比率が、早く再生するべき広告を明らかにし（小さい分母→高い比率）、既に再生された広告の差異が、低い比率により押し戻されることは、有利である。
【０１４６】
可能な広告のリストが再順序化されるステップ３６２０Ａの後、ステップ３６２５Ａが実行され、広告が選択される。一実施形態の場合、広告は、可能な広告のリストで得られる最高の比率に基づいて選択される。ステップ３６２５Ａの後、提示される広告のタイプに応じて、様々な行動が行われる。ステップ３６３０Ａにおいて、利用可能な広告が存在せず、広告タイプが紹介用スポンサシップ広告である場合、ステップ３６３５Ａにおいて例外が生じる。これ以外の場合には、ステップ３６４０Ａが実行され、広告が利用可能か否かについて、判断が行われる。利用可能な広告が存在する場合、ステップ３６４５Ａが実行され、広告が再生される。利用可能な広告が存在しない場合、ステップ３６４０Ａが実行され、選択制約がリセットされ、制御はステップ３６２０Ａに戻る。
【０１４７】
各タイプの広告には、プロセスステップに違いがある。これには、紹介用スポンサシップ広告と、垂直的スポンサシップ広告と、コマーシャル広告との三タイプが存在する。以下は、紹介用スポンサシップ広告を選択する例示的プロセスである。
１．紹介用スポンサシップ広告タイプに関して、場所に基づいた選択制約を設定する（垂直領域は適用されないため、垂直領域は使用しない）。
２．制約に基づいてデータベースをクエリし、結果は、再生が可能な広告のリストに変換される。
３．販売基準に基づいてリストを再順序化する。
４．リストから最高の比率を有する広告を選択する。広告はデータベースに存在する必要があり、そうでない場合には例外を発生させる。
【０１４８】
以下は、垂直的スポンサシップ広告を選択する例示的なプロセスである。
１．垂直的スポンサシップ広告タイプに関して、ユーザの人口統計データ、場所の人口統計データ、および垂直タイプに基づいて制約を設定する。
２．制約に基づいてデータベースをクエリし、結果は、再生が可能な広告のリストに変換される。
３．販売基準に基づいてリストを再順序化する。
４．利用可能である場合、リストから最高の比率を有する広告を選択し、ユーザインタフェースに戻す。
５．利用可能なものがない場合、垂直タイプのみに基づく選択制約をリセットし、Ｑｕａｃｋのプロモーションのみに関するものとなるように垂直スポンサシップのタイプを設定する。
６．販売基準に基づいてリストを再順序化する。
７．利用可能である場合、リストから最高の比率を有する広告を選択し、ユーザインタフェースに戻す。
８．ユーザがリストからのすべての広告を聞いた場合、ユーザに対して最後に再生された広告に戻る。何らかの理由でリストが空であり、利用可能な広告がない場合、例外を発生させる。
【０１４９】
以下は、コマーシャル広告を選択する例示的なプロセスである。
１．コマーシャル広告タイプに関して、場所の人口統計データ、顧客の人口統計データ、および垂直タイプに基づいて選択制約を設定する。
２．この制約に基づいてデータベースをクエリし、結果は、再生が可能な広告のリストに変換される。
３．販売基準に基づいてリストを再順序化する。
４．利用可能である場合、リストから最高の比率を有する広告を選択し、ユーザインタフェースに戻す。
５．利用可能なものがない場合、垂直タイプのみに基づく選択制約をリセットし、Ｑｕａｃｋ（つまり、ボイスポータルシステム）コマーシャルまたは（入力されたタイプに関係なく）有料コマーシャルのいずれかに関するものとなるようにコマーシャルのタイプを設定する。
６．販売基準に基づいてリストを再順序化する。
７．利用可能である場合、リストから最高の比率を有する広告を選択し、ユーザインタフェースに戻す。
８．ユーザがリストからのすべての広告を聞いた場合、最後の広告に戻る。何らかの理由でリストが空であり、利用可能な広告がない場合、例外を発生させる。
【０１５０】
次に図３６Ｂを参照すると、フローチャート３６００Ｂは、ボイスポータル１０を使用して広告する第二の例示的なプロセスを表している。ステップ３６１０Ｂにおいて、ユーザは、ボイスポータル１０にアクセス（電話または発信）する。ステップ３６１０Ｂの後、ステップ３６１５Ｂが実行され、ユーザを識別するためにユーザルックアップが実行される。発信者の識別は、様々な方法で実行可能であり、その一部については、図２および３０を参照して既に説明した。ステップ３６１５Ｂの後、ステップ３６２０Ｂにおいて、ユーザがボイスポータル１０にとって既知であるか否かについて判断が行われる。ユーザが既知でない場合、ステップ３６２５Ｂが実行され、そのユーザにデフォルトのプロフィールが使用される。例示的な一実施形態の場合、デフォルトのプロフィールは、特定の広告に関するユーザ制約または制限を含まない。デフォルトプロフィールは、例えば、ユーザの市外局番、発信の日時、曜日、およびその他のような、その発信に関して既知である特定のパラメータに合わせることができる。ユーザが既知である場合、またはステップ３６２５Ｂが実行された後、ステップ３６３０Ｂが実行され、広告サブシステム１２０は、現在のユーザに特有のユーザ制約を含め、インタフェース（例えば、発話、ＷＡＰ、ＷＷＷ）のタイプに基づく広告セット「Ｓ」を生成する。
【０１５１】
現在の動作コンテクスト（例えば、特定のユーザ、垂直的関心ドメイン）受けて、ステップ３６３５Ｂにおいて、広告サブシステム１２０は、広告コンテクストに基づく広告セットＳの加重を生成する。ステップ３６３５Ｂの後、ユーザが最も求めているものを正確に知る上でコンテクストが十分か否かを判断するために、ステップ３６４０Ｂが実行される。コンテクストが十分ではない場合、ステップ３６４５Ｂが実行され、取得された部分的なコンテクストに基づいて広告が選ばれる。コンテクストが十分である場合、ステップ３６５０Ｂが実行され、最も適合する広告が再生される。
【０１５２】
広告サブシステム１２０が、すべての発信者に初期一般広告またはスポンサシップメッセージを提供することは、有利である。広告サブシステム１２０は、更に、ドメインに適した効用関数に基づいて、ユーザにターゲット音声広告を提供する。例示的な一実施形態の場合、この効用関数は、広告される製品またはサービスの可用性と、現在の品目の相関性（例えば、ＤＶＤはテレビに関係する）と、（例えば、人口統計データによる）ユーザとの関与度と、広告主にとってのユーザの望ましさと、（例えば、コスト／収益に基づく）サービスプロバイダにとっての価値とに関する。広告サブシステム１２０が、特定の時間枠の中で特定の数の広告をユーザに配信することができることは、有利である。更に、広告サブシステム１２０は、ワイヤレスアプリケーションプロトコル（ＷＡＰ）、ＷＷＷ、および発話インタフェースのような様々なプラットフォーム上で広告を配信することができる。
【０１５３】
発話インタフェースプラットフォームを例として取り上げると、最初の１分以内に、一つのスポンサシップ広告と一つのターゲット広告とがユーザに配信される。その後の各４０秒間以内に、第二のターゲット広告が配信される。一実施形態の場合、スポンサシップメッセージは、３乃至５秒間で処理され、その後、ターゲット広告には１０乃至２０秒間を要する。
【０１５４】
この構造の実施は、システムに入った時点で紹介用スポンサシップ広告が提示される事実に基づいている。ユーザが垂直領域に入るたびに、ユーザには「垂直的スポンサシップ」が知らされる。ユーザが要求したデータを受領しようとする時点で、完全なコマーシャルがユーザに提示される。このモデルが、情報の断片を受領する前にユーザが４０秒間に渡って検索し続けると予測されるため、以前に記載したスケジュールに近いものとなることは、有利である。
【０１５５】
広告コンテクストにおいては、広告の提示時に更に詳細な情報を配信するために、「スピークスルー」が要求される。スピークスルーが、発話インタフェースだけでなく、ＷＡＰおよびＷＷＷの両方にも適用されることは、有利である。ＷＡＰでは、発話およびテキストをスピークスルーとみなすことが可能であり、一方、広告に関する詳細を見つけるためにバナーをクリックすることが、ＷＷＷでのスピークスルーとなる。音声対話でのスピークスルーの一実施形態は、顧客にＷｅｂサイトのアドレスまたは電話番号を示すことによりある。代替実施形態の場合、スピークスルーでは、電子メールアドレスまたは顧客の電話番号を取得し、広告主に提供し、詳細な関連情報を顧客に送る。ＷＷＷインタフェースにより、スピークスルーは、顧客情報を管理および検査するためにことを含むことができる。広告サブシステム１２０が、ドメイン（例えば、ＷＷＷインタフェース）に適した効用関数に基づいて選択したターゲット「バナー」広告をユーザに提供することもできることは、有利である。
【０１５６】
広告サブシステム１２０の広告配信の管理は、いくつかの要素の組み合わせに基づく。例示的な一実施形態の場合、広告は、三種類の箇所のいずれかで配信される。第一に、広告は、ユーザが新しいセッションを開始するためにシステムに入る準備をしている時に配信することができる。このスポンサメッセージは、ユーザインタフェース１１０の音声または「システムボイス」となり、いくつかの代替可能な広告スポンサで回転させるべきである。例えば、スポンサメッセージは、「Ｑｕａｃｋは、Ｗｅｂの通貨、Ｖｉｓａが提供します」または「Ｑｕａｃｋは、携帯電話サービスの確かな未来、ＳｐｒｉｎｔＰＣＳが提供します」とすることができる。
【０１５７】
第二に、別のスポンサシップ広告（「垂直的スポンサシップ広告」）は、映画、交通、または天気のようなシステムの特定の垂直領域にユーザがアクセスする直前に配信することができる。例えば、こうした広告は、「映画情報の世界的権威、ＩＭＤＢが提供します」および「ＬＣＥ　ＳｏｎｙＭｅｔｒｅｏｎ：ボストンで映画ならここしかありません」とすることができる。
【０１５８】
第三に、広告は、ユーザが精緻化された要求を受領する直前に配信することができる。このタイプの広告は、「コマーシャル」として定義される。こうした広告は、時宜に適っているが（つまり、選ばれたポイントで配信されるが）２分毎のような頻度で時折配信されるのみである。有利なことに、システムボイスは、役に立つ可能性がある、ユーザにとって付加価値のある状況を示すことができる。例えば、ユーザが特定の劇場での映画を選択した時、近くのレストランを提案することができる。ここでは、好ましくは、スピークスルー広告が使用され、ただし、非スピークスルー広告も可能である。広告コンテンツ自体は、好ましくは、約７秒の長さである。スピークスルー広告は、好ましくは、可能な最高品質のもの（つまり、プロが制作したもの）であり、好ましくは約１５乃至２０秒の長さである。例えば、ユーザがＬＣＥ　ＳｏｎｙＭｅｔｒｅｏｎでの映画としてアメリカンビューティーを選択した場合、システムボイスは「ＳｏｎｙＭｅｔｒｅｏｎの上映リストを調べてしています．．．ＳｏｎｙＭｅｔｒｅｏｎから僅か５分のボストンで一番のイタリア料理店’Ｔｏｎｙ’ｓＭａｔｒｉｃｉａｎａ’について聞きたい場合は、「Ｔｏｎｙ’ｓ！」と言ってください。または、リストをお待ちください」と言う。ユーザは、その後、自動的に予約を入れることができる。その他の相関性属性を、ターゲット広告に使用することもできる。広告が、垂直指定要求を行う際には広告を配信するだけの時間量が必要になるという現在の仮定により、こうした様々なスポットで配信されることは、有利である。
【０１５９】
こうした問題と共に、ユーザにどの広告を配信するかについて判断が行われる。この判断に組み込まれる要素には、通話の長さと、どのタイプの垂直的コンテンツが要求されたかと、コンテンツおよびユーザプロフィール（および／または場所）の組み合わせ（つまり、レストランの広告は顧客の地元で行うべきである）と、潜在的な収入と、特定の情報を要求する発信者と、その広告をユーザが既に聞いているかとが含まれる。例示的な一実施形態の場合、広告は、以下の要素、つまり、この広告が最後に再生されたのはいつか？　ユーザが、今回の通話の前に、この広告を最後に聞いたのはいつか？　ユーザが、この広告を今回の通話で既に聞いているか？　この広告に関して、広告配信率は達成されているか？　この広告に関して、ターゲット配信最低限度は達成されているか？　に基づいて回転する。
【０１６０】
広告が、提示が特定の顧客に適したものとなり、請求料率に応じて追跡されるような形で配信されることは、有利である。したがって、各広告を管理するために、その広告が再生された回数および個々のユーザがその広告を聞いた回数のような特定の基本データが収集される。
【０１６１】
その上、この基本データを与えることにより、以下の更に複雑なクエリが利用可能となる。例えば、クエリは、名前、人口統計情報、場所、および相関性情報（そのユーザが他に何を要求したか）のような様々な定義グループの中で広告を聞いたすべてのユーザの報告を作成する能力を有することができる。クエリは、更に、スピークスルー情報を要求したすべてのユーザの報告を作成する能力を有することができる。
【０１６２】
ボイスポータル１０の他の動作モード中に可能となるバージイン（つまり、広告を再生中に停止すること）の能力は、広告の提示している間には、無効にすることができる。広告主が、ボイスポータル１０を通じて与えられ広告に関して取得されたデータについて確信を持てることが必要であるという点において、バージインを阻止する能力は、重要である。一実施形態の場合、この広告データの収集は、第三者の監査人によって行われる。
【０１６３】
広告サブシステム１２０は、成功した（完全な）配信と失敗した（不完全な配信）とを含め、ユーザに供給したすべての広告の記録を維持する。この記録は、データベース１７０に格納されることが好ましい。広告が、垂直的関心ドメイン、または発信者の場所またはユーザ、またはユーザ嗜好、またはユーザの過去の関心、または広告主の関心とユーザ収集情報との他の何らかの組み合わせとによって、ターゲットを定めることができることは、好ましい。
【０１６４】
ユーザに対する広告のターゲットの幅を狭くするために、コンテクストセンシティブ情報の使用を用いることができることは、好ましい。ボイスポータル１０におけるコンテクストセンシティブ広告ターゲット化では、広告コマーシャルを、ほぼ正確にユーザがどの情報を受領するかに関連させる。この機能を正確にするために、広告が再生される直前に、選択アルゴリズムに適切なポインタを伝える。一実施形態の場合は、垂直タイプが、コンテクストポイントとなる。
【０１６５】
一実施形態の場合、イグジスタントは、更に具体的なターゲット化を可能にするコンテクストポインタとなる。このコンテクストポインタは、その属性の基準を、市場調査基準と一致させ、特定のカテゴリにおける加重を決定する。こうしたカテゴリ加重は、初期リストにおいて広告の販売基準と結合され、最適な広告を選択するために、ここからコンテクスト加重の順序を定義する。この初期リストは、人口統計データおよび垂直タイプから作成され、コンテクスト加重の基盤を形成する。この問題をアルゴリズムへと一般化するために、数学的表記が導入され、これについては以下の例において例示する。
【０１６６】
第一に、関与するパラメータに関して、変数を定義する。アルゴリズムに伝えられるイグジスタントの属性リストは、セット｛ｅ_１，ｅ_２，．．．，ｅ_ｍ｝によって定義されるものとし、ここでｍはイグジスタント内の属性の数である。例えば、映画イグジスタントでは、サンプル属性は、ジャンルと、場所と、上映時間とになる。関連する広告で利用可能なカテゴリのリストは、セット｛Ｃ_１，Ｃ_２，．．．，Ｃ_ｎ｝によって定義されるものとし、ここでｎはカテゴリの合計数である。システム内のサンプルカテゴリの一部は、ファミリと、レストランと、ナイトライフと、映画と、娯楽とになる。各カテゴリＣ_ｉに関してコンテクストカテゴリ加重Ｗ_ｉが存在するものとし、ここでｉ∈｛１，．．．，ｎ｝である。コンテクストカテゴリ加重を有する目的は、広告のカテゴリ加重と比較したコンテクストの強さを決定することによりあり、これについては以下で説明する。
【０１６７】
すべてのイグジスタントに関する市場調査基準は、Ｐ＝｛ｐ_１，ｐ_２，．．．，ｐ_ｉ｝で表され、ここでｔはデータベース内のすべての基準の合計である。各基準ｐ_ｊは、関連する加重ｗ_ｊを有し、ここでｊ∈｛１，．．．，ｔ｝であり、各属性ｅ_ｉは、すべてのｉ，ｊに関して、ｐ_ｊを満足させることを試み、ここでｉ∈｛１，．．．，ｍ｝、ｊ∈｛１，．．．，ｔ｝である。したがって、ｅ_ｉがｐ_ｊを満足させ、ｐ_ｊがカテゴリＣ_ｋに属する場合、Ｗ_ｋ＝Ｗ_ｋ＋ｗ_ｊとなり、ここでｉ∈｛１，．．．，ｍ｝、ｊ∈｛１，．．．，ｔ｝、ｋ∈｛１，．．．，ｎ｝である。この繰り返しは、前述した各カテゴリのコンテクスト加重を定義するために使用される。
【０１６８】
各カテゴリに関する合計コンテクスト加重Ｗ_ｋが定義された後、関連する強度比率Ｒ_ｋを計算する必要がある。カテゴリの強度比率は、イグジスタントのコンテクストが広告の選択に値するほど強いか否かを判断するのに使用される。例えば、ファミリカテゴリが多くの基準Ｐを有する場合は、イグジスタントのコンテクストに対応する加重が、許容可能な比率となる状態を確保する必要がある。このため、Ｒ_ｋ＝　Ｗ_ｋ／Ｔ_ｋとなり、ここでＴ_ｋは、カテゴリｋに関連するｐにおけるすべての基準の合計加重である。
【０１６９】
人口統計的なクエリによって生成される広告のリストは、セットＡ＝｛Ａ_１，Ａ_２，．．．_，Ａ_ｒ｝によって定義され、ここでｒはリスト内の広告の合計数である。各広告Ａ_ｉは、独自のカテゴリ加重ｘ_ｋを有し、ここでｉ∈｛１，．．．，ｒ｝、ｋ∈｛１，．．．，ｎ｝であり、これはアルゴリズムの対応するコンテクストカテゴリ加重Ｒ_ｋと併せて使用される。
【０１７０】
したがって、データベース上の人口統計データおよび広告タイプをフィルタリングすることにより広告Ａの初期リストが作成された後、アルゴリズム内でのステップは、次のようになる。
【０１７１】
１．各カテゴリＣ_ｋに関して、以下のようにカテゴリ加重Ｗ_ｋを設定する。
・各Ｗ_ｋ＝０に初期化し、ここでｋ∈｛１，．．．，ｎ｝である。
・各ｉ∈｛１，．．．，ｍ｝および各ｊ∈｛１，．．．，ｔ｝に関して、イグジスタントの現在の属性｛ｅ_１，ｅ_２，．．．，ｅ_ｍ｝に基づいて、ｅ_１がｐ_ｊを満足させ、ｐ_ｊがカテゴリＣ_ｋに関連する場合、Ｗ_ｋ _＝Ｗ_ｋ＋ｗ_ｋとなり、ここでｋ∈｛１，．．．，ｎ｝となる。
２．次に、イグジスタントの属性から独立したカテゴリの合計加重を表にする。こうした合計加重から、各カテゴリのコンテクスト比率を確定する。
・各ｋ∈｛１，．．．，ｎ｝および各ｊ∈｛１，．．．，ｔ｝に関して、ｐ_ｊがカテゴリＣ_ｋに関連する場合、Ｔ_ｋ＝Ｔ_ｋ＋ｗ_ｊとなる。コンテクストカテゴリのコンテクスト比率をＲ_ｋ＝Ｗ_ｋ／Ｔ_ｋに設定する。
３．各カテゴリｋに関して、各Ｒ_ｋに各広告Ａ_ｔのカテゴリ加重ｘ_ｋを乗じ、その後、その合計に広告の販売基準比率Ｓ_ｉを乗じて、コンテクスト合計Ｇ_ｉを得る。
・各ｉ∈｛１，．．．，ｒ｝に関して、以下のようにＧ_ｉを計算する。
Ｇ_ｉ＝　Ｓ_ｉ・（Ｒ_１ｘ_１＋．．．＋Ｒ_ｎｘ_ｎ）
４．広告Ａ_ｉを選択し、ここでｉはｍａｘ（Ｇ_ｉ）、ｉ∈｛１，．．．，ｒ｝により定義される。
【０１７２】
上のアルゴリズムは、単純な例によって例示することができる。ユーザが、映画の垂直的関心ドメインにおいて、ボイスポータル１０のサービスを使用している例を考える。垂直的スポンサシップ広告は再生済みであり、ユーザは、映画上映に関する情報を受領しようとしている。したがって、コンテクストとして、選択には、再生される特定のイグジスタントに対するポインタが含まれる。ここでは議論のため、このイグジスタントを「水星へのミッション（ＭｉｓｓｉｏｎｔｏＭａｒｓ）」とする。映画上映イグジスタントの属性の一部は、観客指定（例えば、Ｒ）と、ジャンル（例えば、スリラ）と、上映時刻（例えば、４：００ｐｍ）とであり、これは｛ｅ_１，ｅ_２，ｅ_３｝で示すことができる。したがって、要素Ｐ｛ｐ_１，ｐ_２，．．．，ｐ_３｝を含んだ一致するコンテクスト基準要素のリストが存在する必要がある。基準のサンプルリストは、データベース内で次のように表される可能性がある。
【表１】

【０１７３】
このテーブルから、カテゴリは、Ｃ＝｛娯楽，ファミリ，ナイトライフ，ティーン，アダルト｝として推論することが可能であり、ｋ＝５となる。そのためステップ１から、Ｗ_１＝１０、Ｗ_２＝０、Ｗ_３＝５０、Ｗ_４＝８０、およびＷ_５＝０となる。ステップ２から、Ｒ_１＝１、Ｒ_２＝０、Ｒ_３＝１、Ｒ_４＝０．４、およびＲ_５＝０となる（ここではＰが８つの要素のみを有すると仮定しており、実際にはこうなる可能性は低く、約２００以上の要素となる。）。ここで、広告リストＡが、三種類の広告を有すると仮定する。広告の五カテゴリの加重は、以下の通りであると仮定する。
【表２】

【０１７４】
そのため、これらの加重｛ｘ_１，ｘ_２，ｘ_３，ｘ_４，ｘ_５｝から、広告Ａ_ｉに関するＧ_ｉの値を得るために、以下のように計算を行うことが可能であり、ここでｉ∈｛１，２，３｝となる。
【式１】

【０１７５】
したがって、コンテクストおよび販売比率による判断に基づき、「ＭｉｓｓｉｏｎｔｏＭａｒｓ」の広告が、最適となる。このアルゴリズムでは、検索されている情報の断片との関与度に基づいて、様々なカテゴリのコンテクストに注目する。更に、販売基準に関して再生する必要のある広告が注目され、因数分解され順序付けされるという事実を系統化する。この例では、広告、カテゴリ、およびＰの基準の短いリストのみを例示している。このアルゴリズムは、更に多くのカテゴリおよび基準を取り上げることを意図したものである。
【０１７６】
図３７乃至４３は、ユーザとボイスポータル１０との間の対話の例示的なダイアログマップを表している。図３７乃至４３を参照して説明されるダイアログマップは、例示的な目的のみを有する。これらの図では、映画と、天気と、交通と、株式と、スポーツとの垂直的関心ドメインのみが表示されているが、特に、図４乃至６を参照して説明したデータ構造モデル３００、４００、および４５０により利用可能となる拡張性および適合性機能の観点から、こうしたダイアログマップ（およびボイスポータル１０のユーザとの対話）に任意の垂直的関心ドメインを含めることが可能であるのは明白である。更に、ユーザとボイスポータル１０との間の様々な対話を示す特定のブロックは、例示的な目的のみを有する。可能な多くの垂直的関心ドメインのそれぞれについて、広範な対話が可能である。
【０１７７】
図３７は、ダイアログマップ３７００を表しており、ここではユーザがボイスポータル１０に電話をかけた後、ブロック３７１０が実行され、歓迎の言葉が提供される。ブロック３７１０の後、ブロック３７２０が実行され、サインイン手続きが進められる（図３８を参照して更に説明される）。ブロック３７２０のサインイン手続きの後、ユーザは、ブロック３７３０および３７４０において、ボイスポータル１０のサービスの紹介を聞くこと、または、ブロック３７５０において、可能な垂直的関心ドメインの紹介のためにランウェイ情報へ直接進むことが選択できる。具体的には、ブロック３７３０では、サービスプロバイダに関して、紹介情報が提供される。ブロック３７４０では、サービスがどのように機能するかに関して、紹介情報が提供される。ブロック３７５０では、ボイスポータル１０は、ユーザに対して、「ランウェイ」から関心ドメイン（例えば、映画、天気、交通、株式、スポーツ）を選択するように要求する。
【０１７８】
ユーザが映画の関心ドメインを選択した場合、ブロック３７６０が実行され、ここで映画サブシステムが実行され（図３９を参照して更に説明される）、ユーザは、映画リスト、劇場、およびレビューのような、映画情報およびトランザクションへのアクセスを有する。ユーザが天気の関心ドメインを選択した場合、ブロック３７７０が実行され、ここで天気サブシステムが実行され（図４０を参照して更に説明する）、ユーザは、好適な場所または任意の場所に関する今日の予報または長期予報のような、天気情報へのアクセスを有する。ユーザが交通の関心ドメインを選択した場合、ブロック３７８０が実行され、ここで交通サブシステムが実行され（図４１を参照して更に説明される）、ユーザは、都市による報告、特定のルートに関する報告、または個人化された報告のような、交通情報へのアクセスを有する。ユーザが株式の関心ドメインを選択した場合、ブロック３７９０が実行され、ここで株式サブシステムが実行され（図４２を参照して更に説明される）、ユーザは、市場概況、株式市況、株式ニュース、および個人化された株式ニュースまたはトランザクション（例えば、購入、売却）のような、株式情報およびトランザクションへのアクセスを有する。ユーザがスポーツの関心ドメインを選択した場合、ブロック２５００が実行され、ここでスポーツサブシステムが実行され（図４３を参照して更に説明する）、ユーザは、スポーツのスコア、スポーツニュース、スポーツイベントのチケット情報、およびスポーツ・ファンタジ・リーグ・トランザクションのような、スポーツ情報へのアクセスを有する。
【０１７９】
次に図３８を参照すると、ここには、サインインサブシステムが表示されている。ブロック３８１０では、発信者識別が試行される。ボイスポータル１０のユーザの一タイプは、未確認ユーザである。未確認ユーザは、（おそらく初めての）着信後、従来の発信者識別技術（「発信者ＩＤ」）により場所を確認可能であるか、またはこうした確認は不可能である。発信者ＩＤがデータベース１７０に存在しない場合、発信者は、新しい発信者である可能性がある。発信者ＩＤが非通知にされている場合、ボイスポータル１０は、どちらにせよ識別ができない。一実施形態の場合、ボイスポータル１０は、電話番号（またはその他の識別子）を要求し、「確認済み」発信者として先に進む。代替実施形態の場合、ボイスポータル１０は、検証を行わずに先に進む。この判断は、要求されている情報の種類に応じて変化させることができる。例えば、特定の垂直的ドメインでは、手続きの前に、ユーザを識別するために、ユーザのＩＤを決定する必要がある（オークション等の場合）。
【０１８０】
確認済みユーザは、登録済みまたは未登録の一方である。確認済みユーザが登録済みである場合、ボイスポータル１０は、クレジットカードおよび嗜好のようなユーザに関する情報をデータベース１７０に有する。ボイスポータル１０が嗜好および関心の追跡を開始し、高い度合いの消費者付加価値と、これによるサービスへの愛着とを達成できるように、ユーザが、登録を行うことが、好ましい。ユーザは、登録時、住所およびクレジットカード番号を有するプロフィール情報を記入することができる。更に、特定の発信者に関して多くの情報が蓄積されると、方向付けされた（したがって価値のある）広告も蓄積される。
【０１８１】
発信者の識別が可能である場合、ブロック３８２０が実行され、ユーザにパスワードを求めることにより、ユーザの確認が実行される。パスワードが検証されると、ユーザ嗜好を設定することが可能となり、制御はブロック３８７０に移行し、更に制御は図３７に戻り、紹介またはランウェイの選択が実行される。与えられたパスワードが無効である場合、制御はブロック３８４０に移行する。
【０１８２】
発信者の識別が不可能である場合、またはユーザが自分のパスワードを知らなかった場合、制御はブロック３８３０に移行し、ボイスポータル１０は、ユーザのアカウントステータスを決定する。ユーザがアカウントを有しない場合、制御はブロック３８５０に移行し、ユーザがアカウントを設定するべきであるというアカウント設定リマインダが提示される。ユーザがアカウントを有している場合、制御はブロック３８４０に移行し、ボイスポータル１０は、ユーザのアカウント番号を取得する。ユーザがアカウント番号を忘れていた場合、制御はブロック３８５０に移行し、ユーザは、アカウントを設定するように求められる。ユーザが有効なアカウント番号を提供した場合、制御は、ユーザ確認のため、ブロック３８２０に移行する。ユーザが無効なアカウント番号を提示した場合、制御はブロック３８６０に移行し、ボイスポータル１０は、ユーザに対して、アカウントが無効であり、Ｗｅｂサイトを訪問するか、またはサポート番号に電話をして、支援を受けるように通知する。その後、制御はブロック３８８０および図３７に移行し、紹介またはランウェイの選択が実行される。
【０１８３】
次に図３９を参照すると、ここでは、映画サブシステムが実行される。ブロック３９１０では、ボイスポータル１０が、映画の関心ドメインの紹介を再生する。ユーザは、劇場での映画、映画リスト、および映画レビューのようなオプションを選択することができる。ユーザが劇場での映画を選択した場合、制御はブロック３９１５に移行し、ボイスポータル１０は、ユーザが希望する地理的な場所を決定する。場所の決定には、郵便番号、州および都市、または嗜好のような、様々な方法を利用することができる。与えられた場所の近くに劇場がない場合、ブロック３９２０が実行され、与えられたエリア内に位置する劇場がないことをユーザに通知するメッセージが再生される。場所が決定されると、ブロック３９２５が実行され、その場所にある劇場名が列挙される。ブロック３９２５の後、ブロック３９３０が実行され、エリア内の劇場で上映されている映画が列挙される。ボイスポータル１０は、ユーザに映画を選択することを要求し、制御はブロック３９３５に移行する。
【０１８４】
次にブロック３９１０を参照すると、ここでは、映画の関心ドメインの紹介が再生され、ユーザが映画リストを要求すると、ブロック３９４０が実行され、ボイスポータル１０は、映画タイトルをユーザに要求する。ブロック３９４０の後、ブロック３９４５が実行され、ユーザが希望する地理的な場所が決定される。上で説明したように、発信者の場所の決定には、様々な方法を使用することができる。選択した映画を上映している劇場が存在する場合、ブロック３９５０が実行され、その映画を上映している劇場が列挙され、ユーザは、リストから選択するように求められる。制御は、その後、ブロック３９３５に移行する。選択した映画を上映している劇場が存在しない場合、ブロック３９５５が実行され、最も近い場所での映画の時間が、ユーザに提供される。制御は、その後、ブロック３９３５に移行する。
【０１８５】
次にブロック３９１０を参照すると、ここでは、映画の関心ドメインの紹介が再生され、ユーザが映画レビューを要求すると、ブロック３９６０が実行され、ボイスポータル１０は、映画タイトルをユーザに要求する。ブロック３９６０の後、ブロック３９６５が実行され、選択された映画に関するレビューが再生される。ブロック３９６５の後、ブロック３９７０が実行され、ボイスポータル１０は、選択した映画の上映について知りたいか否かをユーザにたずねる。ユーザが拒否した場合、映画レビューに関する別の映画タイトルを取得するために、制御は、ブロック３９６０に戻る。ユーザが受け入れた場合、制御は、ブロック３９４５に移行する。
【０１８６】
ブロック３９３５の後、ボイスポータル１０は、選択した映画および劇場に関する映画上映時間を提供する。ブロック３９８０では、ボイスポータル１０は、次の行動を要求する。ユーザは、劇場の住所を要求することが可能であり、この場合、ブロック３９８５が提供される。ユーザは、更に、映画レビューを要求することが可能であり、この場合、ブロック３９９０が提供される。ユーザが映画の関心ドメインを中止することを希望すると、制御は、図３７のブロック３７５０に戻る。
【０１８７】
次に図４０を参照すると、図示されているように、天気サブシステムが実行される。ブロック４０１０では、ボイスポータル１０は、天気の関心ドメインの紹介を再生する。ブロック４０１０で紹介が再生された後、制御はブロック４０２０に移行し、ボイスポータル１０は、天気の関心ドメインにおけるユーザの場所情報を取得する。上で説明したように、場所情報の取得には、郵便番号、都市または州、およびその他の場所の指示による場所の取得のような、多数の方法が可能である。ブロック４０２０の後、制御はブロック４０３０に移行し、ボイスポータル１０は、ユーザが現在の天気情報を求めるか、または後の期間に関する天気情報を求めるかについて、プロンプトを提供する。ユーザが後の期間に関する天気情報を聞くことを選択した場合、制御はブロック４０４０に移行し、ボイスポータル１０は、ユーザに対して、天気に関する待ち時間オプションを提供するプロンプトを再生する。ユーザが現在の天気情報を求めた場合、またはユーザがブロック４０４０で待ち時間オプションを選択した後、制御はブロック４０５０に移行し、ボイスポータル１０は、希望する天気情報を提供する。
【０１８８】
ブロック４０５０が実行された後、制御はブロック４０６０に移行し、ボイスポータル１０は、ユーザに対して、長期予報を希望するか否かをたずねる。長期予報が希望される場合、制御はブロック４０７０に移行し、ボイスポータル１０は、長期予報を提供する。ブロック４０７０の後、またはユーザが長期予報を希望しない場合、制御はブロック４０８０に移行し、ボイスポータル１０は、ユーザに次の行動を要求する。ユーザが天気の関心領域を継続したい場合、制御は、ブロック４０２０に移行する。ユーザが天気関心領域を中止したい場合、制御は、ブロック４０９０に移行し、これはブロック３７５０として図３７を参照して説明したランウェイに対応する。
【０１８９】
次に図４１を参照すると、ここでは、交通サブシステムが実行される。ブロック４１１０では、ボイスポータル１０は、交通の関心ドメインの紹介を再生する。ブロック４１１０の後、制御はブロック４１１５に移行し、ボイスポータル１０は、ユーザからの場所情報またはユーザに関する個人化情報を取得する。ブロック４１１５の後、制御はブロック４１２０に移行し、ボイスポータル１０は、都市交通情報を取得する。都市交通情報が利用できない場合、制御はブロック４１３５に移行し、郵便番号交通情報が取得される。郵便番号交通情報は、ボイスポータル１０が都市を認識しなかった場合の予備である。都市データが発見されず、近くの場所に関するデータが含まれる場合、制御はブロック４１４０に移行し、ボイスポータル１０は、近くの都市を求める。ブロック４１２０において、報告すべき交通イベントが存在しない場合、制御はブロック４１２５に移行し、ユーザは、報告すべき交通状況がその都市に存在しないことを通知される。ブロック４１２０において、交通データが利用できない場合、制御はブロック４１３０に移行し、ユーザには、別の都市を試すオプション、または新しい関心ドメインを選択するためにランウェイへ進むオプションが提供される。
【０１９０】
ブロック４１２０の後、制御はブロック４１４５に移行し、ボイスポータル１０は、特定の交通ルートまたは「全市」を要求する。ブロック４１４５の後、制御はブロック４１４５に移行し、ボイスポータル１０は、ルート指示情報を取得する。ブロック４１４５の後、ルート上で報告すべき交通情報が存在しない場合、制御は、ブロック４１５５に移行する。ブロック４１５５では、ユーザは、新しい交通ルートまたは「全市」を選択するオプションと、ランウェイへ進み、新しい関心ドメインを選択するオプションとが与えられる。ルート交通情報が入手可能である場合、ブロック４１５０の後、制御はブロック４１６０に移行し、ボイスポータル１０は、選択されたルートに関するルート交通情報を列挙する。ブロック４１４５においてユーザが「全市」を選択した場合、制御はブロック４１６５に移行し、ボイスポータル１０は、都市交通情報を列挙する。
【０１９１】
ブロック４１６０およびブロック４１６５の後、制御はブロック４１７０に移行し、ボイスポータル１０は、希望された交通レポートをユーザに提供する。ブロック４１７０の後、制御はブロック４１７５に移行し、ボイスポータル１０は、交通の関心ドメインにおいて実行する次の行動を求める。例示的な一実施形態の場合、次の行動には、交通レポートの繰り返しと、交通情報の列挙の継続と、ランウェイへ進むこととが含まれる。ブロック４１７５でユーザが選択を行った後、制御は、適切なブロックに移行する。例えば、ユーザが交通レポートの繰り返しを選択した場合、制御は、ブロック４１７０に移行する。ユーザが列挙の継続のオプションを選択した場合、制御は、ブロック４１４５で行われた特定の交通ルートまたは「全市」の選択に応じて、ブロック４１６０またはブロック４１６５のいずれかに移行する。ユーザがランウェイへ進むことを選択した場合、制御は、ブロック４１８０に移行し、これはブロック３７５０として図３７を参照して説明したランウェイに対応する。
【０１９２】
次に図４２を参照すると、ここでは、株式サブシステムが実行される。ブロック４２１０において、ボイスポータル１０は、株式の関心ドメインの紹介を再生する。ブロック４２１０の後、制御はブロック４２１５に移行し、ボイスポータル１０は、ユーザに、市場概況、株式市況、または「ＭｙＱｕａｃｋ」と呼ばれる個人化されたリストを選択するオプションを提供する。ユーザが市場概況を選択した場合、制御はブロック４２４０に移行し、ダウ工業株平均、ＮＡＳＤＡＱ、Ｓ＆Ｐ５００、ＮＹＳＥ出来高、ＮＡＳＤＡＱ出来高、および３０年債のような市場概況が様々な市場に関して提供される。ユーザが株式市況を選択した場合、制御はブロック４２２０に移行し、ボイスポータル１０は、ユーザから特定の株式銘柄を取得する。ブロック４２２０の後、制御はブロック４２２５に移行し、ボイスポータル１０は、ブロック４２２０において提供された株式銘柄に対応する株式市場を取得する。株式市場を特定した後、制御はブロック４２３０に綿入り、ボイスポータル１０は、株価、最終取引、変化、出来高、および一日の高値／安値のような株式情報を提供する。
【０１９３】
ブロック４２３０の後、制御はブロック４２３５に移行し、ボイスポータル１０は、株式の関心ドメインにおいて実行する次の行動を要求する。例示的な一実施形態の場合、ユーザは、株式情報の繰り返し／株式情報の列挙の継続、新しい株式の取得、市場概況を聞くこと、またはランウェイへ進むことを選択できる。ブロック４２３５でユーザが行った選択に応じて、制御は、市場概況の場合はブロック４２４０に、新しい株式銘柄の場合はブロック４２２０に、個人化されたｍｙＱｕａｃｋ株式の場合はブロック４２５０に、またはランウェイの場合はブロック４２７５に移行する。ブロック４２７５の前に、制御はブロック４２７０に移行することが可能であり、ここでボイスポータル１０は、ユーザに、個人化された情報を迅速な形で取得するために嗜好を設定することが可能であることを伝える嗜好リマインダを提供する。今回の通話で、ユーザに嗜好について既に指摘している場合、制御は、直接ブロック４２７５に移行する。
【０１９４】
ブロック４２１５において、ユーザが「ＭｙＱｕａｃｋ」を選択した場合、制御は、アカウント情報が特定されていない場合はブロック４２４５に移行し、アカウント情報が特定されている場合はブロック４２５０に移行する。ブロック４２４５において、嗜好設定およびアカウント情報が確定される。Ｗｅｂ上でアカウントが設定されたことを、ユーザに対して忠告することができる。ブロック４２５０では、株価、最終取引、変化、および出来高のような個人化された株式情報が提供される。ブロック４２５０の動作中、ユーザは、特定の株式に関する情報の再生中に、例えば「ｔｈａｔｏｎｅ」と言うことにより、特定の株式を特定することができる。こうした選択が行われた場合、制御はブロック４２５５に移行し、特定の株式に関して、株式ニュースオプションが列挙される。ユーザがブロック４２５５のリストから特定のタイプの株式ニュースを選択した後、制御はブロック４２６０に移行し、ボイスポータル１０は、選択された株式ニュースを再生する。ブロック４２６０の後、制御はブロック４２６５に移行し、ボイスポータル１０は、ユーザに、株式ニュースのリストを取得するか（ブロック４２５５）、または株式ニュースを終了するかをたずねる。ユーザが株式ニュースの終了を選択した場合、制御はブロック４２３５に移行し、株式に関する次の行動が要求される。ユーザが株式の関心ドメインを完了すると、制御はブロック４２７５に移行する。これはブロック３７５０として図３７を参照して説明したランウェイに対応する。
【０１９５】
次に図４３を参照すると、ここでは、スポーツサブシステムが実行される。ブロック４３１０では、ボイスポータル１０は、スポーツの関心ドメインの紹介を再生する。ブロック４３１０の後、制御はブロック４３１５に移行し、ボイスポータル１０は、ユーザが希望するスポーツのタイプを取得し、または、ユーザは、「ＭｙＱｕａｃｋ」と発声し、個人化されたスポーツタイプのスコアを得ることができる。ユーザが特定のスポーツを選択した場合、制御はブロック４３２０に移行し、ボイスポータル１０は、選択したスポーツのリーグ名をリストから取得する。例えば、ボイスポータル１０は、「ＮＦＬ、ＮＢＡ、ＮＨＬ、およびメジャーリーグベースボール」を列挙することができる。ユーザがリーグ名を選択した後、制御はブロック４３２５に移行し、ボイスポータル１０は、ユーザが関心を有する特定のチームを取得する。ブロック４３２５の後、制御はブロック４３３０に移行し、スポーツのスコアが提供される。例えば、ボイスポータル１０は、「ＴＥＡＭの前回の試合はＤＡＴＥに行われ、最終結果は、ＴＥＡＭ１、ＳＣＯＲＥ１、ＴＥＡＭ２、ＳＣＯＲＥ２でした」と伝えることができる。
【０１９６】
ブロック４３１５において、ユーザが「ＭｙＱｕａｃｋ」を選択した場合、制御は、ブロック４３４０に移行する。ブロック４３４０では、ボイスポータル１０は、個人化されたＭｙｙＱｕａｃｋスポーツチームのスポーツスコアを提供する。ブロック４３４０の後、制御はブロック４３３５に移行し、ボイスポータル１０は、チーム限定のニュースとして、スポーツニュースを提供する。ブロック４３３０およびブロック４３３５の後、制御はブロック４３４５に移行し、ボイスポータル１０は、直前に聞いたスポーツ情報をユーザが繰り返したいか否かをたずねる。ユーザが肯定的な反応を示した場合、ボイスポータル１０は、元に戻って、提供した情報を繰り返す。ユーザが情報の繰り返しを望まなかった場合、制御はブロック４３５０に移行し、ボイスポータル１０は、スポーツの関心ドメインにおいて実行する次の行動を求める。ブロック４３５０の後、制御は、リーグ名を選択するためにブロック４３２０に、ｍｙＱｕａｃｋスポーツのスコアを提供するためにブロック４３４０に、またはランウェイ情報のためにブロック４３５５に移行する。ブロック４３５５は、ブロック３７５０として図３７を参照して更に説明したランウェイに対応する。図４０乃至４３の各サブシステムは、例としてのみ表示されている。
【０１９７】
各図に例示し且つ上で説明した実施形態は現在において好適なものであるが、こうした実施形態は、例示としてのみ提供されていることは理解されよう。他の実施形態は、ボイスポータルを介したインターネットへのアクセスを単純化する様々なデータ構造を有することができる。本発明は、特定の実施形態に限定されず、前記特許請求の範囲および趣旨になお含まれる様々な変形例、組み合わせ、および置換例とを包含する。
【図面の簡単な説明】
本発明は、同様の参照記号が類似する要素を示す添付図面の各図において、例示的且つ非限定的に示されている。
【図１】インターネットに接続するボイスポータルを示す全体概略図である。
【図２】図１のボイスポータルの例示的な機能的実施形態を示す全体機能ブロック図である。
【図３】図１のボイスポータルの例示的な物理的実施形態を示す更に詳細なブロック図である。
【図４】図１のボイスポータルで使用される例示的なデータ構造モデルを示す概略図である。
【図５】ユーザ関連情報に関する図４の例示的なデータ構造モデルを示す概略図である。
【図６】広告関連情報に関する図４の例示的なデータ構造モデルを示す概略図である。
【図７】図４の例示的なデータ構造モデルの例示的な作成プロセスを示すフロー図である。
【図８】図７の例示的な作成プロセスを示す概略図である。
【図９】ノンプログラミング手段を使用してインターネットからの情報を収集する例示的なプロセスを示すフロー図である
【図１０】図１のボイスポータルに関連するルールのノンプログラミング策定の例示的なプロセスを示す概略図である。
【図１１】図１のボイスポータルに関連するルールのノンプログラミング策定に関する例示的なグラフィカルユーザインタフェースを示す。
【図１２】図１のボイスポータルに関連するルールのノンプログラミング策定において使用される例示的なグラフィカルユーザインタフェースウィンドウを示す。
【図１３】図１２のグラフィカルユーザインタフェースウィンドウの拡張形態を示す。
【図１４】図１のボイスポータルに関連するルールのノンプログラミング策定において使用される例示的なグラフィカルユーザインタフェース検索データエディタウィンドウを示す。
【図１５】図１のボイスポータルに関連するルールのノンプログラミング策定において使用される例示的なグラフィカルユーザインタフェースウィンドウを示す。
【図１６】図１５のグラフィカルユーザインタフェースウィンドウの拡張形態を示す。
【図１７】図１のボイスポータルに関連するルールのノンプログラミング策定において使用される例示的なグラフィカルユーザインタフェースウィンドウを示す。
【図１８】図１のボイスポータルに関連するルールのノンプログラミング策定において使用されるベンダ形態オプションに関する例示的なグラフィカルユーザインタフェースウィンドウを示す。
【図１９】図１のボイスポータルに関連するルールのノンプログラミング策定におけるＵＲＬのテストに関する例示的なグラフィカルユーザインタフェースウィンドウを示す。
【図２０】図１のボイスポータルに関連するルールのノンプログラミング策定におけるパターンの選択に関する例示的なグラフィカルユーザインタフェースウィンドウを示す。
【図２１】図１のボイスポータルに関連するルールのノンプログラミング策定中に、多数のページのリンクの検出に関するパターンを特定するために使用される例示的なグラフィカルユーザインタフェースウィンドウを示す。
【図２２】スパイダのプログラミングにおいて使用される階層構造を示す概略図である。
【図２３】図１のボイスポータルにより使用されるスパイダのプログラミングに関する例示的なグラフィカルユーザインタフェースウィンドウを示す。
【図２４】図２３の例示的なグラフィカルユーザインタフェースウィンドウの拡張形態を示す。
【図２５】図１のボイスポータルの統一データベースに情報を融合する例示的なプロセスを示すフロー図である。
【図２６】図１のボイスポータルの統一データベースに情報を融合する第二の例示的なプロセスを示すフロー図である。
【図２７】より完全な一定の項目に関する情報のための二つのイグジスタントからのカノニカルなイグジスタントの作成を示す概略図である。
【図２８】インターネットソースから図１のボイスポータルのユーザに対するデータの分離および変換の例示的なプロセスの第一の部分を示す概略図である。
【図２９】インターネットソースから図１のボイスポータルのユーザに対してデータが分離および変換される図２８の例示的なプロセスの第二の部分を示す概略図である。
【図３０】図１のボイスポータルの例示的な動作フローを示すフロー図である。
【図３１】図３０のフロー図の例示的な動作サブシステムを示すフロー図である。
【図３２】図３０のフロー図の第二の例示的な動作サブシステムを示すフロー図である。
【図３３】図３０のフロー図の第三の例示的な動作サブシステムを示すフロー図である。
【図３４】希望する品目またはサービスを決定するために図１のボイスポータルにおけるユーザの応答をファンネリングする例示的なプロセスを示すフロー図。
【図３５】図１のボイスポータルを使用してトランザクションを実行する例示的なプロセスを示すフロー図である。
【図３６Ａ】図１のボイスポータルを使用して広告する例示的なプロセスを示すフロー図である。
【図３６Ｂ】図１のボイスポータルを使用して広告する第二の例示的なプロセスを示すフロー図である。
【図３７】図１のボイスポータルの例示的なダイアログマップを示すフロー図である。
【図３８】図３７の例示的なダイアログマップの例示的なサブシステムを示すフロー図である。
【図３９】図３７の例示的なダイアログマップの第二の例示的なサブシステムを示すフロー図である。
【図４０】図３７の例示的なダイアログマップの第三の例示的なサブシステムを示すフロー図である。
【図４１】図３７の例示的なダイアログマップの第四の例示的なサブシステムを示すフロー図である。
【図４２】図３７の例示的なダイアログマップの第五の例示的なサブシステムを示すフロー図である。
【図４３】図３７の例示的なダイアログマップの第六の例示的なサブシステムを示すフロー図である。
【符号の説明】
１０ボイスポータル
１２携帯電話
１４標準電話
２０ネットワーク
３０Ｗｅｂページ
４０Ｗｅｂページ
５２コンピュータ
５４コンピュータ
５５データベース
５８データベース
５９ユーザインタフェース
１１０ユーザインタフェース
１２０広告サブシステム
１３０顧客管理サブシステム

Claims

プログラムによらない手段がウェブページから情報を得ることを可能にするために、識別されるものの属性に対応するルールを確立する方法であって、
所望のものに関する情報に対応するウェブページを発見するステップと、
前記発見されたウェブページにオーバーレイするフォームを選択するステップであって、前記フォームが、前記所望のものの属性に対応するルールにより規定されているステップと、
前記フォームに基づいて前記発見されたウェブページから情報を抽出するステップとを、有する方法。
前記発見されたウェブページにオーバーレイするフォームを選択する前記ステップが、グラフィカルユーザーインタフェース（ＧＵＩ）によりリストされるフォームを選択することを有する請求項１の方法。
フォームを選択する前記ステップが、前記フォームをさらに規定するルールを加えることを有する請求項１の方法。
前記フォームに基づいて前記発見されたウェブページから情報を抽出する前記ステップが、その情報を、前記発見されたウェブページに位置させることができるパターンを識別することを有する請求項１の方法。
所定の属性に一致する項目を含むウェブページに対する前記インターネットをサーチすることを、さらに、有する請求項１の方法。
ウェブページに対して前記インターネットをサーチする前記ステップが、スパイダを実施することを有する請求項５の方法。
前記発見されたウェブページから情報を抽出する前記ステップが、ＨＴＭＬタグを使用している情報のパターンを識別することを有する請求項１の方法。
前記発見されたウェブページにオーバーレイするフォームを選択する前記ステップが、検索される情報に関する属性を含むフォームを生成することを有する請求項１の方法。
前記選択されたフォームおよび抽出された情報を他のウェブページに適用することを、更に、有する請求項１の方法。
ウェブページから情報を得るために識別されるものの属性に対応するルールを確立するシステムであって、
所望のものに関連した情報に対応するウェブページを発見する手段と、
前記発見されたウェブページにオーバーレイするフォームを選択する手段であって、前記フォームが、前記所望のものの属性に対応するルールにより規定されている手段と、
前記フォームに基づいて前記発見されたウェブページから情報を抽出する手段とを、有するシステム。
フォームを選択する前記手段が、さらに、前記フォームを規定するルールを加える手段を有する請求項１０のシステム。
前記フォームに基づいて前記発見されたウェブページから情報を抽出する前記手段が、情報が前記発見されたウェブページへの位置することができるパターンを識別する手段を有する請求項１０のシステム。
所定の属性に一致する項目を含むウェブページに対する前記インターネットをサーチする手段を、さらに、有する請求項１０のシステム。
前記発見されたウェブページにオーバーレイするフォームを選択する前記手段が、検索される情報に関する属性を含むフォームを生成する手段を有する請求項１０のシステム。
ウェブに基づく情報を共通データ構造に変換するさいに使用されるルールをプログラミングによらずに開発する方法であって、
情報の、関連した情報を含む領域を有するページを発見するステップと；
関連した情報を含む記領域を孤立させるパターンを含むフォームを識別するステップと、
関連した情報を含む領域を含むページのセット内でより多くの情報のページへのリンクを発見するステップと、
関連した情報を含む領域を孤立させるために同様のパターンによりページのセットに対し抽出ファイルを生成するステップとを、有する方法。
データを抽出することをさらに有する請求項１５の方法。
抽出ファイルを生成する前記ステップが、ベンダーのウェブサイトへの情報表示のパターンを識別することを有し、
前記ベンダーのウェブサイトが、マルチプルウェブページを含む請求項１５の方法。
ウェブに基づく情報を共通データ構造に変換するさいに使用されるルールをプログラミングによらないで開発するシステムであって、
関連情報を含む領域を有する、情報のページを発見する手段と、
関連情報を含む前記領域を孤立させるパターンを含むフォームを識別する手段と、
関連情報を含む領域を含むページのセットの範囲内で、情報のより多くのページへのリンクを発見する手段と、
関連情報を含む領域を孤立させるために同様のパターンによりページのセットに対して抽出ファイルを生成する手段とを、有するシステム。
データを抽出する手段を更に有する請求項１８のシステム。
前記抽出ファイルを他のウェブページに適用する手段を更に有する請求項１８のシステム。
ウェブに基づく情報の前記変換において使用されるルールを開発するシステムであって、
複数のフォームの内の一フォームを使用するウェブページから抽出される情報を格納するデータベースであって、ルールからなる複数のフォームが、前記ウェブページから求められた関連情報に関係するデータベースと、
フォームの前記フォームを前記複数から選択するために非エキスパートルールメーカーを可能にするツールを編成しているデータであって、前記選択されたフォームが、前記ウェブページへの情報の構成およびコンテクストを近似するように選択されているデータとを、有するシステム。
共通データ構造にウェブに基づく情報を変換するさいに使用されるルールをプログラミングによらないで開発するコンピュータ読取り可能なプログラムコードを有するコンピュータプログラム製品であって、
ウェブページを発見する第一のコンピュータ読取り可能なプログラムコードと、
関連情報を含む前記領域を孤立させるパターンを含むフォームを識別する第二のコンピュータ読取り可能なプログラムコードとを、有するコンピュータプログラム製品。
前記フォームに基づいて前記発見されたウェブページから情報を抽出する第三のコンピュータ読取り可能なプログラムコードを、更に、有する請求項２２のコンピュータープログラムコード。
前記抽出された選択されたフォームと抽出された情報を他のウェブページに適用する第四のコンピュータ読取り可能なプログラムコードを、更に、有する請求項２２のコンピュータープログラムコード。
グラフィカルユーザーインタフェースを実施する第五のコンピュータ読取り可能なプログラムコードを、更に、有する請求項２２のコンピュータープログラムコード。