JP5193412B2 - インターネットに基づく情報への音声アクセスのためのシステム及び方法 - Google Patents

Description

【０００１】
（発明の属する技術分野）
本発明は、一般にインターネットに関連する。より具体的には、本発明は、インターネットに基づく情報への音声アクセスのためのシステム及び方法に関連する。
【０００２】
（従来の技術）
インターネットは、インターネット接続されたコンピュータを使用することにより、事実上無限量の情報にアクセスすることができるメディアへと発展してきている。インターネット経由で情報にアクセスする機能は、様々に異なる方法で提供することができる。ある場面では、情報はインターネット検索エンジンによって提供される。この検索エンジンとは、通常、キーワード又はキーフレーズを求めてインターネットを検索し、当該検索対象のワード又はフレーズをテキスト又は埋め込まれた識別子（例えば、メタタグ）として含むウェブサイトのリストを提供するものである。個別のウェブサイトからも、インターネット経由の情報アクセスは可能である。個別のウェブサイトでは、時間的にクリティカルでありかつ時間に依存しない多種多様な情報及びサービスが提供される。
【０００３】
（発明が解決しようとする課題）
しかし残念なことに、インターネットがそのユーザに対し莫大な量のインターネット情報へのアクセスの可能性を提供する一方で、有益な情報を探し出す作業は往々にして時間を浪費し、面倒でもある。さらに、複数の個別ウェブサイトから入手できる同一の情報を探し出し、比較することは困難である。なぜならば、そのような同一情報は、その構成のされ方が様々に異なり、その説明も様々に異なる形式でなされ、そして様々に異なる時期に変更が行われているからである。インターネットに関するこれらの本質的な問題に加え、インターネットサービスプロバイダ（ＩＳＰ）を介してインターネットに接続されるコンピュータ又はそれに類する電子装置なしには、人々はインターネット上の情報にアクセスできないという純然たる事実が存在する。さらに、望みのインターネット情報を効果的に見つけるには、人々は、インターネット経由で情報の存在する場所を特定する方法を学ばなければならない。そのような状況では、コンピュータを持たない者、ＩＳＰに接続していない者、適切なソフトウェアを持たない者、そしてインターネットの使用に関して経験がなく、あるいは訓練を受けたことのない者は、インターネットに基づく情報へのアクセスが制限される。業界のエキスパートらの見積もりでは、１９９９年末の時点で過去に一度でもインターネットにアクセスしたことのある、又は「ネットサーフィン」をしたことのある米国民は合衆国人口のわずか３０％のみであるが、その理由の一つとして上記の要因が挙げられる。
【０００４】
したがって、コンピュータの直接使用、ＩＳＰとの個人的接続、又はインターネットの使用に関する経験や訓練を必要とすることなく、インターネットに基づく情報へアクセスすることのできる新たなシステム及び方法が提供されることが望ましい。加えて、電話による音声など、便利かつ容易に行える手段を用いてインターネットに基づく情報を得ることができるシステム及び方法が提供されることが望ましい。
【０００５】
現在までのところ、そのようなシステム及び方法は、数多くの課題が存在するため不可能である。例えば、そのようなシステム及び方法を使用する者は、迅速な、又は少なくとも許容し得る時間内での情報の獲得を欲するであろう。そのような速さは困難である。従来からの高速コンピュータ及び高速通信接続を使用したとしても、インターネットへのアクセスにおける遅れにより、ワールドワイドウェブ（世界に広がる網）ではなく「ワールドワイド重み付け（世界に広がる待ち時間）」と呼ばれている。そのようなシステム及び方法に向けてのもう一つの課題は、音声交信の認識である。従来の音声認識技術は速度が遅くかつ不正確である。音声によるインターネット情報への便利で意味のあるアクセスでは、シンプル、迅速かつ正確な音声認識が要求される。そのようなシステム及び方法に向けての更なる課題は、財政面でのサポートを維持しつつ、いかにしてインターネット情報への無償アクセスを提供するかである。インターネットにおける従来の広告では、「バナー」などの広告情報を認識し、そして同バナーを「クリック」するなどの手作業による選択を行い、よって広告対象の製品やサービスに関するより多くの情報が得られる、というような機能が要求される。
【０００６】
したがって、上述の機能に加え、インターネットに基づく情報への迅速かつ正確な音声アクセスが無償で得られるシステム及び方法が提供されることが望ましい。さらに、電話番号を１回ダイヤルすることによって様々なインターネット情報にアクセスすることができるシステム及び方法が提供されることが望ましい。
【０００７】
（課題を解決するための手段）
本発明の実施の一態様は、インターネットに基づく情報及びサービスへの音声アクセスを提供する方法である。同方法は、交信装置のユーザによって開始された交信接続要求を示す信号を受信するステップと、ユーザの交信装置と交信接続を確立するステップと、ユーザから音声情報を受け取るステップと、ユーザから受け取った音声情報に反応する音声情報を伝達するステップとを有する。反応音声情報にはインターネットに基づく情報が含まれる。
【０００８】
簡潔には、本発明の実施のもう１つの態様は、インターネット上で入手可能な様々な情報及びサービスへのアクセスを提供する、インターネットへの単一音声ポータルである。同音声ポータルは、ユーザインターフェースと、少なくとも１つのデータベースと、更新エンジンとを有する。ユーザインターフェースは、ユーザとの音声交信を調整する。データベースは、ユーザインターフェースに結合され、ユーザとインターネットに基づく情報に関する情報を保存する。更新エンジンは、データベースに結合され、インターネットと交信し、インターネットに基づく情報を更新して提供する。
【０００９】
簡潔には、本発明の実施のもう１つの態様は、インターネットに基づく情報及びサービスへの音声アクセスを提供するシステムである。同システムは、交信接続要求を示す信号を受信するための手段と、ユーザと交信接続を確立するための手段と、ユーザへ音声によって情報を伝達するための手段と、ユーザから音声情報を受け取るための手段と、ユーザから受け取った音声情報に反応する音声情報を伝達するための手段とを有する。反応音声情報には、インターネット経由でソースから得られたインターネットに基づく情報が含まれる。
【００１０】
簡潔には、本発明の実施のもう１つの態様は、インターネットに基づく情報及びサービスへの音声アクセスを提供するための、コンピュータ可読プログラムコードを有するコンピュータプログラム製品である。同コンピュータプログラム製品中のプログラムコードは、交信装置のユーザによって開始された交信接続要求を示す信号を受信するための第１のコンピュータ可読プログラムコードと、ユーザの交信装置と交信接続を確立するための第２のコンピュータ可読プログラムコードと、ユーザへ音声によって情報を伝達するための第３のコンピュータ可読プログラムコードと、ユーザから音声情報を受け取るための第４のコンピュータ可読プログラムコードと、ユーザから受け取った音声情報に反応する音声情報を伝達するための第５のコンピュータ可読プログラムコードとを有する。反応音声情報には、インターネットを経由してソースから獲得した情報であるインターネットに基づく情報が含まれる。
【００１１】
簡潔には、本発明の実施のもう１つの態様は、ユーザインターフェースと、データベースとを有する音声ポータルである。ユーザインターフェースは、ユーザとの音声交信を調整する。音声交信には、インターネットに基づく情報が含まれる。
【００１２】
本発明の実施の態様の他の特徴及び利点は、以降の図面、詳細な説明、及び添付の請求項を参照することにより、当業者にとって明らかになるであろう。
【００１３】
（発明の実施の形態）
インターネットに基づく情報への音声アクセスのためのシステム及び方法を説明する。本発明を完璧に理解するために、以下の記載においては、説明を目的として、数々の具体的詳細事項が示されている。しかし、これらの具体的詳細事項の提示がなくとも、当業者であれば本発明を実施し得ることは明らかであろう。また場合により、本発明の例示的実施態様の説明を容易にするために、ブロック図を用いて周知の構造物及び装置類が提示される。
【００１４】
本発明の例示的実施の一態様は、インターネットに基づく情報及びサービスへのアクセスを提供するシステムを有し、同アクセスは、通信装置のユーザによって開始される通信要求を指示する信号を受信し、ユーザの通信装置と通信接続を確立し、ユーザからの音声情報を受信し、そして、ユーザからの当該音声情報に応答しつつ音声情報を伝達することにより、提供される。当該応答音声情報は、インターネットに基づく情報を有する。
【００１５】
本発明の他の態様は、インターネット上におけるトランザクションに対するアクセス、処理及び実行を行うために、電話を介しての音声使用のためのシステム及び方法に関連する。更に、本発明の他の態様は、あるウェブサイトが他のウェブサイトと同一の情報を有するか否かを決定するためのシステム及び方法に関連する。更に、本発明の他の態様は、インターネット音声ポータルを用いた広告のためのシステム及び方法に関連する。更に、本発明の他の態様は、インターネットに基づく情報の変換において使用される規則の非プログラム的開発のためのシステム及び方法に関連する。更に、本発明の他の態様は、求める項目を決定するためにインターネット音声ポータルシステムにおいてユーザの応答をファネルするためのシステム及び方法に関連する。更に、本発明の他の態様は、系統的に構成されたデータの変換及び正規化のためのシステム及び方法に関連する。
【００１６】
ある実施態様では、メモリに収納された一連の命令を実行する中央演算装置（ＣＰＵ）を備えたコンピュータシステムが使用される。より具体的には、ＣＰＵは、一連の命令の実行を通じて、以下に説明されるステップを実行する。ＣＰＵによる実行のため、大量記憶装置である読出し専用メモリ（ＲＯＭ）、又はその他の持続型記憶装置から、ランダムアクセスメモリ（ＲＡＭ）へ命令がロードされる。その他の実施態様では、ソフトウェアによる命令の代わりに機能し、あるいはそれと連携して機能する、ハードウェア的に組み込まれた回路が使用されてもよい。したがって、本明細書に記載される実施態様は、ハードウェア的回路及びソフトウェアのいかなる具体的組み合わせに限定されず、また、コンピュータシステムによって実行される命令のいかなる供給源にも限定されない。
【００１７】
図１に、音声ポータル１０とネットワーク２０との接続を示す。例示的実施態様では、ネットワーク２０はインターネット、すなわちＴＣＰ／ＩＰネットワークプロトコルを使用してデータの送受信が行われるコンピュータネットワークの全世界的ネットワークである。他の実施態様では、ネットワーク２０は、例えば仮想専用網（ＶＰＮ）等、ネットワークであればいかなるタイプのものでもよい。ネットワーク２０では、ハイパーテキストマークアップ言語（ＨＴＭＬ）によるウェブページ３０及び４０との通信が可能であることが好ましい。ウェブページ３０及び４０には、様々なウェブサーバー上に様々なデータが有されている。ネットワーク２０では非音声ポータル５０との通信も可能であり、同音声ポータルを通じてコンピュータ５２及び５４とデータベース５８を含むサービス５６とがネットワーク２０に結合される。サービス５６は、ネットワーク２０へ接続する会社、コンテンツ又はサービスプロバイダであればいかなるタイプのものでもよい。データベース５８はデータの記憶媒体であり、光学式、磁気式、その他適切な記憶媒体であればよい。
【００１８】
一般に、音声ポータル１０はサーバーのネットワークとして実現される。サーバーはソフトウェアによって構成される。これらのサーバーは、ディスクドライブやその他の記憶装置等、相当量の読出し／書込みメモリを備えていることが好ましい。一般に、ユーザは携帯電話１２又は通常の電話１４等の電話を介して音声ポータル１０にアクセスし、その際、電話番号をダイヤルすることによって当該電話と音声ポータル１０との間の通信が開始される。あるいは、これら以外の電話サービスを利用し、音声又は音声データをポータル１０へ送信することも可能である。ポータル１０は、様々な回線、ネットワーク、及び中継基地を経由して電話１２及び１４へ接続することが可能である。音声ポータル１０は、ユーザとの音声通信に備えたものであると好都合である。音声ポータル１０により、ウェブページ３０及び４０、更にはネットワーク２０上に存在する他の供給元からの情報及びサービスに対し、ユーザによるアクセスが可能となる。このようなアクセスは音声ポータル１０により迅速かつ効率的に行われ、その際、音声ポータル１０は、様々なウェブサイト及びインターネットサービスからの情報に対し、検索、系統的管理及び保存を継続的に実行する。音声ポータル１０の使用のために、他のユーザインターフェースプラットフォームが提供されてもよい。そのようなユーザインターフェースプラットフォームには、例えば、ＷＡＰ（ワイヤレスアプリケーションプロトコル）及びウェブインターフェースが含まれる。
【００１９】
図２に、音声ポータル１０によって実行される例示的機能的操作を示す。これらの機能は、多くの物理的構造を含む様々な方法によって実行される。例示的実施態様では、音声ポータル１０は、ユーザインターフェース１１０と、広告サブシステム１２０と、顧客管理システム１３０と、エグジスタントサブシステム１４０と、融合エンジン１５０と、更新エンジン１６０と、データベース１７０と、を有する。
【００２０】
ユーザインターフェース１１０は、音声ポータル１０とユーザとの間の音声通信を調整する。ユーザインターフェース１１０は、音声、インターネットもしくは『ワールドワイドウェブ』（ｗｗｗ）、ワイヤレスアプリケーションプロトコル（ＷＡＰ）インターフェース、又はその他のプラットフォームインターフェースを介するものである。例示的実施態様では、ユーザインターフェースは音声指向型である。そのような音声指向型の実施態様では、ユーザインターフェース１１０は、ユーザ入力受入れのために、可能な限り単語ベースの自動音声認識（ＡＳＲ）を使用する。ユーザインターフェース１１０には、マサチューセッツ州のＳｐｅｅｃｈ Ｗｏｒｋｓ Ｉｎｔｅｒｎａｔｉｏｎａｌ ｏｆ Ｂｏｓｔｏｎが供給するＳｐｅｅｃｈ Ｗｏｒｋｓのような音声認識ソフトウェアパッケージを使用することができる。ユーザインターフェース１１０にとって、音声認識率を高めるために、ユーザの応答を認識可能な回答のセットにファネルするファネリングプロセスを利用することは有利である。ファネリングについては、図３４を参照しつつ、更に詳しく説明される。ユーザインターフェース１１０は、単語ベースのＡＳＲが可能でない場合、ユーザ入力受入れのためにスペリングベースのＡＳＲも使用する。最後に、ユーザインターフェース１１０は、ユーザにとって好都合である場合に限り、ユーザ入力受入れのためにキーパッド入力を使用する。このキー入力では、電話１２及び１４上のキーが利用される（図４）。
【００２１】
例示的実施態様では、ユーザインターフェース１１０は次のタスクの内の１つ又はそれ以上を実行する：（１）電話番号、及びその他ユーザ固有の情報によりユーザを識別する。（２）あるユーザに対し、あるプラットフォーム上で新しいセッションを開始する。（３）あるユーザに対し、あるプラットフォーム上で新しい対話を加える。（４）音声ポータル１０内にある、対象となっている縦方向ドメインのセット内でのユーザの好み設定を更新する。（５）当該対象となっている縦方向ドメインのためユーザ好み設定を有効又は無効にする。（６）ユーザの技能レベルを、一般又は特定縦方向以内として更新する。（７）ユーザの人口統計データ又は個人的データ（クレジットカード情報を含む）を更新する。（８）ユーザインターフェース別の情報により、ユーザのセッション状態を更新する。（９）新しいクレジットカードをデータベースに加える。（１０）新しい情報により、既存のクレジットカードを更新する。（１１）クレジットカードのタイプ及び番号によりクレジットカードを特定し、同クレジットカードがデータベース内に既に存在するかチェックする。（１２）ユーザが選び得る縦方向ドメインのリスト及びそのオーダーをセットする。（１３）ユーザのセッションを正常に終了する。（１４）ユーザのセッションが異常終了し、その後定義されているステータス（例えば、発信打切り、セッション時間切れ、等）に陥ったことを、顧客管理サブシステム１３０に通知する。（１５）ある特定のプラットフォームにおけるユーザによる最も最近のセッションを決定し、よってセッションが異常終了（例えば、発信打切り、セッション時間切れ、等）した場合にもセッションをレジュームし、保存されていたセッション状態を回復することを可能とする。ユーザインターフェース１１０は、本人識別、セッション、ユーザ、支払いプロトコル等に関するその他の機能を実行することができる。
【００２２】
広告サブシステム１２０は、通信セッション中にユーザに対して提供される広告に関する各種活動を調整する。例示的実施態様では、広告サブシステム１２０は、スポンサー付き広告等の広告、特定ユーザに向けられた広告、そしてユーザからの肯定的要求が出されたときに限り提供される許諾ベースの広告、を有する。例示的実施態様では、広告サブシステム１２０は、１つ又はそれ以上の機能を提供する：（１）ユーザ、セッション、ロケーション、コンテンツ及び探索されている項目に基づき、再生する広告を選択する。（２）広告が再生されたこと、及び最後まで再生されたか否かを記録する。（３）スピークスルー（すなわち、以下に説明されるように、広告対象についてより詳しく説明を聞くことをユーザ自身が選択する広告をいう）であったことを記録する。（４）繰り返してデータベースを呼出す必要がないように、顧客情報及びセッション情報をビーン内に保存する。（５）広告を提供する会社のレコードを作成し、そのうちの一つを特定できる状態を維持する。（６）広告及びデータベースに保存しておく広告契約を作成する（システム上での使用に関し、広告毎に契約内容が異なる可能性があるため）。（７）セールス目的での広告のために、新しいセールスの従業員又は雇用者と接触する。（８）広告及び／又は当該広告の契約を更新する。（９）広告会社を更新し、接触情報及び住所情報を変更する。（１０）セールスの従業員及び雇用者の接触を更新する。（１１）有効リスト中へ広告を入れる、又は有効リストから広告を取り除く。（１２）外部情報に基づき、完全又は不完全となるべき広告契約をマークする。（１３）広告のタイプに基づき、有効な広告のリストを表示する。（１４）無効か有効か、もしくは完全か不完全かの基準に基づき、会社に関連する広告のリストを表示し、又は単にすべての広告を表示する。（１５）上記基準に基づいて、広告に関する契約のリストを表示する。（１６）上記基準に基づいて、セールスの従業員に関する契約のリストを表示する。（１７）固有の識別子を入力することにより、被雇用者、会社、広告又は広告契約の完全なリストを取り出す。（１８）データベースを検索し、従業員、会社、広告及び広告契約に関する似通った文字列の一致を求める。（１９）特定の契約において会社に払われた納品を追跡し、会社の未処理のバランスを更新できるようにしておく。（２０）更新ログを検索し、データの一貫性に関するエラーが存在しないことを確認する。（２１）特定のジャンルのための広告を保存しておくために必要な再生リストを作成・修正する。
【００２３】
これらの操作のそれぞれを実行するために、様々に異なる方法を使用してもよい。広告の操作は、図３６を参照しつつ、更に詳しく説明される。広告サブシステム１２０は、本人識別、セッション、ユーザ、そして支払いプロトコルに関する更なる機能を実行することができる。本明細書に開示される広告の技術は、従来のパーソナルコンピュータ（ＰＣ）のインターフェースによるウェブ接続においても使用することができる。
【００２４】
顧客管理システム１３０は、ユーザに関連する情報の管理とユーザによる音声ポータル１０の使用とを調整する。例示的実施態様では、顧客管理システム１３０は、好み設定、人口統計データ等のユーザに関する情報を獲得し、これらの情報は、ユーザインターフェース１１０、広告サブシステム１２０、そして音声ポータル１０のその他の機能によって選択的に使用される。顧客管理サブシステム１３０は、本人確認、セッション、ユーザ、そして支払いプロトコルに関する更なる機能を実行することができる。サブシステム１１０、１２０及び１３０は個別に説明されるが、本発明の原理から逸脱することなく、それぞれの操作を単一のユニットに統合することが可能である。
【００２５】
ユーザインターフェース（ＵＩ）１１０と顧客管理サブシステム１３０とは相互に作用し、縦方向ドメインの選択及びインターネットに基づく情報のアクセスを提供する。縦方向ドメインは様々な分野及び領域を分類し、その中からユーザは音声ポータル１０内において選択を行う。ＵＩ１１０がユーザと効果的に交信するためには、一定の好み設定及びユーザに関する事実が、消極的又は積極的に確認され、そして理解されていなければならない。顧客管理サブシステム１３０は、そのような情報をデータベース１７０に保存する。あるいは、独立したデータベースにそのような情報を維持してもよい。
【００２６】
顧客管理サブシステム１３０は、顧客の好み設定及び顧客に関する事実を決定するために必要な情報をＵＩ１１０から獲得する。ＵＩ１１０はデータを顧客管理サブシステム１３０へ送り、顧客管理サブシステム１３０は同データを処理し、少なくとも一つのデータベースへ中継する。さらに、エグジスタントサブシステム１４０において好み設定の更新があり、更なるパーズが行われる。その後、エグジスタントサブシステム１４０は、ユーザの好み設定及びユーザに関する事実のような情報をＵＩ１１０へ戻す。
【００２７】
好都合なことに、顧客管理サブシステム１３０は、応答時間を顕著に長くすることなく、修正可能及び拡張可能である。したがって、新しい縦方向ドメインを音声ポータル１１０へ追加するプロセスは、迅速かつ首尾一貫したものである。いつでも新しい縦方向ドメインが追加できるため、顧客事実のタイプ及び人口統計データを完全に定義することはできない。
【００２８】
顧客管理サブシステム１３０は、ユーザによってなされ、データベースを介して申し込まれ、あるいは取り消されたトランザクションのすべてを記録する。また顧客管理サブシステム１３０は、ユーザが形成された履歴リスト中に特定した項目を記録し、ユーザが（ウェブサイト上においてＷＡＰ装置を介しつつ）注目したコレクションを追跡する。
【００２９】
顧客管理サブシステム１３０は、可能な場合には必ず、そして可能な限り消極的に、申し込みを行った顧客を特定する。したがって、システムへ入る際の顧客の識別は、例えば電話番号やＩＤ（「ＰＩＮ（個人識別番号）」）のようなある種の本人確認キーを介して行われることが好ましい。この本人確認は、顧客に関連するある一定の好み設定、及び好み設定の各セット内における顧客の経験レベルに導かれることが好ましい。加えて、システムでは、保存されているクレジットカード情報に対してなされた購入を許可する前に、更なるレベルの本人確認（例えばパスワードによる本人確認）を行うことが許容される。
【００３０】
顧客管理サブシステム１３０は、音声ポータル１０を介したユーザの対話を促進するために、好み設定のセットを各縦方向ドメイン内に維持している。例えば、例示的実施態様では、顧客管理サブシステム１３０は、どのようなタイプの広告を顧客に提供し、そしてどのようにして顧客へのサービスを向上させるかという決定を更に支援していくために、顧客から情報を収集する。顧客管理サブシステム１３０は、サポートされた各ドメインに適切な顧客好み設定を維持し、データソースからの顧客データを動的に更新する。例えば、関心の対象となっているオークションドメインにおいて、現在の入札状況はユーザの要求を受けて更新される。音声ポータル１０は、好都合にも、ドメインに適切な通貨と共にユーザデータを提示する。例えば、関心の対象となっているオークションドメインにおいて、入札価格は常に数秒の範囲において現状での価格を示す。関心の対象となっている電子商取引ドメインにおいて、購入価格が提示された場合の価格情報は現状でのものである。
【００３１】
好都合にも、顧客管理サブシステム１３０は、報告及び分析を行い、よってどのユーザがどのサービスにアクセスしているかの決定を可能とする。さらに、顧客管理サブシステム１３０は、セッション及びトランザクション履歴について、異なる人口統計学的セグメントにしたがった報告を行い、例えば、ユーザがどのようなサービスにアクセスするのかを収入、性別、年齢等の各グループ毎に決定する。顧客管理システム１３０は、また、実際の使用状況に基づく関連について報告する（例えば、映画に関心のあるユーザが映画以外のどのようなサービスにアクセスしたかを報告する機能）。
【００３２】
絶えず付加価値を加え、ユーザによるプラットフォームから他のプラットフォームへの移行を促すために（例えば、電話からウェブ、あるいは電話からＷＡＰ）、顧客管理サブシステムは１３０にとり、顧客のサービス利用経験を向上するための個人化機能をサポートすることが有利である。個人化に加え、「執着性」（競争という観点から観た場合、特定のサービスに執着する顧客）の他の源泉には、共通の嗜好を有する友人又は家族のネットワークのような、コミュニティ機能の支持が含まれる。したがって、顧客管理サブシステム１３０に個人化機能及びコミュニティ機能が含まれる場合、顧客は特定のサービスプロバイダに対してより忠実となる。
【００３３】
サービス（又は広告）の顧客行動への適合をサポートするには、顧客管理サブシステム１３０により、サービスの利用を追跡することが有利である。さらに、インターフェース評価の領域においては、ユーザによるインターフェース階層の一般的な探索により、問題領域もしくは非常に有効な領域又は相関関係のあるサブフィーチャーのセットについて、単一セッションにおけるそれらの特定が促進され得る。音声ポータル１０のサービスに関するもう一つの重要な属性はタイミングである。例えば、「割り込み」の使用はより上級のユーザ及び単一のサブツリーに対する度重なる一連の割り込みセレクションを意味し、その理由は、特定のユーザが顧客管理サブシステム１３０によって検知され、ショートカット（一般的なもの、又は場合によっては顧客に特有のもの）の機会へと導かれることで、有利となり得るからである。
【００３４】
「執着性」の一場面として、顧客の好み設定に対してサービスを適応させることが挙げられる。これには、反復性のない「サインアップ」又は「購入」におけるデータ入力要件をサポートするための顧客情報の保持などの比較的シンプルな機能が含まれる一方、異なるフロントエンドにおける特定の対話サブツリーのナビゲーションに関する好み設定、及びサービス／ベンダーの注文又は選択に関する好み設定も含まれる。ベンダーに関する好み設定、又は注文の一例として、ユーザは「好みのベンダー」を選択してもよく、そうすることで音声ポータル１０により、見つかった製品のベンダーのリストを２つ（最も廉価なベンダー及び好みのベンダー）に制限することを可能としてもよい。
【００３５】
縦方向の好み設定は、ユーザのアクションに基づき、受動的に設定されるべきである。すなわち、特定の属性が１回以上要求された後に、受動的好み設定が設定される。あるいは、好み設定は、ユーザのアクションに基づき動的に変更される。音声インターフェース又はウェブインターフェースを介しての設定又は再設定を行うことにより、ユーザによるすべての好み設定のオーバーライドが可能であることが好ましい。
【００３６】
顧客管理サブシステム１３０は、ＭｙＹａｈｏｏ及びＭｙＥｘｃｉｔｅのような個人化されたウェブページから、株情報、天気に関する好み設定、等々のユーザ好み設定を抽出することができる。これらの個人化ウェブページは、従来のインターネット接続を介し、ユーザによって事前に制作することができる。あるいは、個人化ウェブページは、顧客管理サブシステム１３０により、ユーザの音声コマンドに応答して構築することができる。その後これらのページは、音声ポータル１０で使用できるように変換される。具体的な縦方向好み設定又は現行の発信好み設定が存在しない場合、一般的な好み設定をデフォルトの好み設定として使用することができ、好都合である。
【００３７】
以下は、例示的縦方向好み設定要件のリスト及びその説明である。各好み設定は、各インターフェースを通じて各様に使用される。例示的実施態様では、天気に関する唯一の好み設定は、顧客が要求する地点の天気である。デフォルトでは、ユーザの位置は、ユーザの郵便番号のそれである。最も一般に使用される地点は、もし可能であれば、現行の発信地点によってオーバーライドすることができる。
【００３８】
関心の対象となっているスポーツドメインでは、検討すべき様々な好み設定がいくつか存在する。第１に、好きなスポーツはオプションである。あるスポーツについてのスコア、予定及び順位をユーザに送信することもできる。ウェブサイトに対しては、独占権を行使し、あるスポーツの広告及び情報を送信しないようにすることができる。例えば、あるユーザはホッケーの試合に関する情報を聞くことを好まず、野球に関する情報を欲するかもしれない。第２に、他より好ましいとして選択されたあるチームについて、好み設定の細分化を進めることができる。これら細分化のそれぞれにおいては、限られた選択肢において最も直近に使用されたもの（ＭＲＵ）のリストを使用することにより、好み設定リストを決定することが可能である。スポーツのタイプ及びチームの好み以外にも、好ましいイベントが使用し得る。
【００３９】
関心の対象となっている映画ドメインでは、必要となる好み設定には、顧客の存在地区及び劇場の存在地区、映画のタイプ（例えば、スリラー、ホラー、アクション、等々）、映画のレーティング（ＡＡ、Ｇ、Ｒ、等々）、そして顧客の好きな男性俳優／女性俳優の登場する映画、が含まれる。これらの好み設定のそれぞれは、限られた選択肢のＭＲＵリストに表示されてもよい。
【００４０】
関心の対象となっている交通ドメインでは、使用されるメインの好み設定は、顧客が目的地に到達するために利用したい特定のルートであり、時刻が属性として加わる（デフォルトは現時点）。したがって、限られたルートからなるＭＲＵリストが、顧客の好みリストとなり得る。
【００４１】
例示的実施態様では、関心の対象となっている株ドメインにおける好み設定は、２つのレベルからなる階層構造となっている。第１に、マーケットリストについての好み設定が存在し、第２に、各マーケットにおいてどの株式及び指標に注目するかという好み設定が存在する。ここでも、マーケット及び株式のＴＢＤ選択肢のＭＲＵリストを表形式に表してもよい。関心の対象となっている他の縦方向ドメインには、レストラン、コンサート及びライブイベント、タクシー、そして航空券予約が含まれ得る。
【００４２】
引き続き図２において、エグジスタントサブシステム１４０は、ユーザインターフェース１１０、広告サブシステム１２０、顧客管理サブシステム１３０、融合エンジン１５０及び更新エンジン１６０によるデータベース１７０へのアクセスを調整する。エグジスタントサブシステム１４０は、データベース１７０に含まれるデータ構造の創造、適合及び操作を管理する。データベース１７０に含まれるデータは、更新エンジン１６０により、インターネット上の情報源から収集される。例示的実施態様では、データベース１７０で使用されるデータ構造は、「エグジスタント」又は事物の階層及びそれら相互の関係及び連携に基づいている。好都合なことに、データベース１７０中の情報の複製及び修正をより容易に実行でき、その理由は、データベース１７０はエグジスタントサブシステム１４０とのみ対話するからである。エグジスタント及びその創造については、図４から図１０を参照しつつ更に詳しく説明される。エグジスタントのための様々な構造が利用できるが、特に、エグジスタントのための例示的データ構造モデルが図４から図６を参照しつつ説明される。エグジスタントの創造及び更新については、図７から図１０を参照しつつ説明される。
【００４３】
融合エンジン１５０は２つのエグジスタントが同一であるかどうかを決定し、もしそうであるならば、その２つを融合し、第３の正規エグジスタントを形成する。融合エンジン１５０は、そのようなものとして、ある情報源から得られた情報が他の情報源からの情報と関連し、あるいは同一であるかどうかを確定する。融合エンジン１５０の機能については、図２５、図２６及び図２７を参照しつつより詳しく説明される。
【００４４】
更新エンジン１６０はインターネットから情報を引き出し、データベース１７０に含まれる情報及び属性を更新する。例示的実施態様では、更新エンジン１６０は、データベース１７０中の情報を更新するために、インターネットから情報を引き出す「スパイダ」を利用する。更新エンジン１６０の動作については、図７及び図８を参照しつつ更に詳しく説明される。
【００４５】
データベース１７０は、顧客データ、広告情報、製品及びサービス情報など、音声ポータル１０によって使用される情報を保存する。データベース１７０中の情報は、エグジスタント、エグジスタント属性、エグジスタント関係及びエグジスタント関連内へと保存される。エグジスタントとは何であるか、そしてどのようにして形成され、どのように互いに関連し、どのように音声ポータル１０の機能に関連するかは、以下に更に詳しく説明される。他の実施態様では、顧客データ、広告情報、動作記録など、特定のタイプの情報のために複数のデータベースを使用してもよい。
【００４６】
図３に、音声ポータル１０の例示的物理的レイアウトを示す。このような物理的構造は、例示目的のためのみのものである。ここに示されるものとの組合せ又はそれに代わるものとして、他の構成が用いられてもよい。例示的実施態様では、音声ポータル１０は、フロントエンドサーバー２１０、フロントトゥバックネットワーク２２０、バックエンドサーバー２３０、及びバックエンドネットワーク２４０を有する。ユーザは電話を介してフロントエンドサーバー２１０の内の１つと交信し、同フロントエンドサーバーはフロントトゥバックネットワーク２２０によってバックエンドサーバー２３０に接続される。
【００４７】
例示的実施態様では、バックエンドサーバー２３０は、プロキシマネージャー２４５、プロキシ２５０、ビーン２６０、及びデータベース２７０を有する。プロキシマネージャー２４５は、フロントトゥバックネットワーク２２０を介して、フロントエンドサーバー２１０の内の１つから情報要求を受け取る。プロキシマネージャー２４５はバックエンドネットワーク２４０を介して交信し、各プロキシマネージャー２４５における作業量レベルを決定する。適切なプロキシマネージャー２４５が一旦決定されると、適切な同プロキシマネージャー２４５は、フリープロキシ２５０の集まりの中からフリープロキシを１つ取り出し、同プロキシをビーン２６０に割り当てる。ビーン２６０は、情報の取出し、情報の挿入、エグジスタントもしくはエグジスタント関係の検索、又はデータベース２７０と連携して可能なその他の機能を実現するために、データベース２７０と関連付けされている。
【００４８】
図３に関連して説明されている仮想データベースは、インターネット２０から蓄えた情報を音声ポータル１０のユーザに対してタイミングよくかつ実用本位な態様で提供するように設計されている。人々は、様々な設定及び態様において必要な情報を利用し、音声ポータル１０はそのような状況を、様々なプラットフォーム上において都合よくサポートし、そのようなプラットフォームには、電話（例えば、音声、ＷＡＰ、又はその両者）、ウェブ、携帯端末（例えば、Ｐａｌｍ（登録商標）ＯＳ装置、ＷｉｎＣＥ（登録商標）装置、ＲＩＭペイジャー）、等々が含まれるが、これらに限定されるものではない。
【００４９】
バックエンドサーバー２３０は、データ収集及び融合など、様々な機能を有するデータベースサービスによるサポートを有する。データ収集機能にはインターネット上の情報源からのデータ蓄積が含まれ、このデータ蓄積は、図７及び図８に関連して説明されるように、特定の項目タイプ及び／又はサイトについて、別途予定される一定間隔で実行される。音声ポータル１０は、図９及び図１０に関連して説明されるように、データソースサイトにおける変化を検知し、適切なサイトルールマネージャーに知らせる。また、音声ポータル１０は、図９及び図１０に関連して説明されるように、データソースのためのデータ抽出の素人的定義もサポートする。
【００５０】
「融合」のプロセスでは、音声ポータル１０は、異なるインターネットベンダーからの同一項目を特定する。融合プロセス中、音声ポータル１０は、すべての情報の源に関するメタデータを保持する。メタデータには、データに関するデータが含まれる。例えば、メタデータは、データ要素又は属性に関するデータ（名前、サイズ、データタイプ、等々）、レコード及びデータ構造に関するデータ（長さ、フィールド、コラム、等々）、データに関するデータ（どこに位置するか、どのように関連付けられるか、所有権、等々）を記録に残す。さらに、確度が自動的に決定できない場合、音声ポータル１０は、非熟練者による融合決定又は非決定の対話式明確化をサポートする。音声ポータル１０は、新規データタイプ及びデータ要素の追加もサポートし、その際、コード変更は伴わない。さらには、音声ポータル１０は、マーケット調査、トライアル及び機会を通じて特定される、ドメインに特有の関連性コンセプトをサポートする。例えば、関心の対象となっている電子商取引ドメインにおいては、より廉価である、より優れている、しばしば同時に購入される、最も人気がある、は、重要な関連性コンセプトである。関心の対象となっている映画ドメインでは、関連する映画及び製品、ならびにカテゴリー内でのベスト映画、最も人気がある、批評家がベストに選ぶ、及び配役、が、関連性コンセプトである。音声ポータル１０は、項目に関する更なる詳細を提供するために必要な関連情報（例えば、製品説明）を収集し、保持する。融合の動作及び機能は、図２５から図２７に関連して更に詳しく説明される。
【００５１】
図４に、音声ポータル１０のデータベース１７０によって使用される例示的データ構造モデル３００を示す。同データ構造モデルでは、「エグジスタント」（又は事物）には、属性、関連及び関係が付与されている。エグジスタント間の「継承」関係は、三角形の矢印を有する実線で描かれている。エグジスタント間の「関連」関係は、通常の矢印を有する点線で描かれている。継承関係の例としては、データ構造モデル３００において、ブロック３１０は「イベント」である。「イベント」は「エグジスタント」又は事物であり、ブロック３２０へ向かう三角矢印３１５によって示される。同様に、「映画上映」（ブロック３３０）は「イベント」（ブロック３１０）であり、三角矢印３３５によって示される。関連関係の例としては、イベントは、ブロック３４０へ向かう通常矢印３４５によって示されるように「開催地」と関連する。同様に、映画上映（ブロック３３０）は、通常矢印３５５によって示されるように「映画パッケージ」（ブロック３５０）と関連する。イベントとしてはこれ以外にも、スポーツイベント、ドラマ、コンサート、コメディショー、花火大会、ダンス公演、その他の活動が可能である。
【００５２】
データ構造モデル３００には上記以外にも、ここでは説明されないが図４には示されているエグジスタント、関連及び関係が含まれる。さらに、データ構造モデル３００には図４に示されるもの以外のエグジスタント、関連及び関係が含まれてもよい。図４は例示のためだけのものである。
【００５３】
次に、図５に関連して、例示的データ構造モデル４００を示し、同データ構造モデルにおける、ユーザ又は顧客オブジェクトと異なる縦方向クラスとの間のオブジェクト指向関係を示す。継承及び関連の関係の描写は、図４に関連して説明されたデータ構造モデル３００における描写と同一である。例示的実施態様では、データ構造モデル４００内に配置されるユーザ情報はデータベース１７０に保存される。しかし、代わりとなる実施態様では、そのようなユーザ情報は、異なる別個のユーザデータベースに保存されてもよい。
【００５４】
顧客はエグジスタント（顧客エグジスタントブロック４０２）であり、トップレベルからの直接の下位オブジェクト、又は階層構造内での「エグジスタント」であり、したがってそのプロパティ及びメソッドのすべてを継承する。この構造の背後にある理由は、データベース１７０及びそのメソッドは既に創られたものであり、コードの再利用が可能な構造だからである。
【００５５】
顧客オブジェクトは様々な情報を含んでいる。一般的好み設定クラスは、「交通」、「天気」、「映画」などの好み設定に関する情報を含む。顧客が関心の対象となる新規もしくは異なる縦方向ドメインに入る毎に、縦方向ドメインの名前に対する好み設定オブジェクトのインスタンスが、好みデータが挿入された状態で創られる。縦方向ドメインが既に存在する場合、オブジェクトは更新された情報によって修正される。
【００５６】
セッションクラスは、ユーザのセッション（セッションブロック４０４）のすぐ上位に位置する情報を記録する。セッションは、発信、ウェブサイトの検索、又はＷＡＰを使った発信である場合がある。日時及び持続時間などのデータは一般的属性であるが、ユーザが行う発信が陸上通信線からのものかあるいは携帯電話からのものかは、電話セッションに特有のものである。このタイプのデータは、音声ポータル１０が誰に対してマーケティング活動を行うかの決定、ならびにパフォーマンス及びサービスの双方の向上のために有益である。加えて、顧客オブジェクトはこれらのセッションオブジェクトのそれぞれに対するリンクを有し、そのプラットフォーム上における最後のセッションが何であったかを決定する（ユーザがセッションを終了後、その時点で再接続を望む場合）。
【００５７】
電話セッションブロック４０８は、音声ポータル１０との交信で電話が使用される交信セッションに関連する情報を記録する。電話セッションブロック４０８は、現在の対話レベル、現在の関心の対象であるドメイン、インターフェースプラットフォームのタイプ（例えば、ＷＷＷ、ＷＡＰ、ＡＳＲ）、以前に訪問されたレベルなどの情報を有する。好都合なことに、電話セッションブロック４０８によって、ユーザによるセッションへの再接続が、過去のセッション又は中断されたセッションにおいてそれらのセッションを終了したところから行うことができる。クレジットカード情報エグジスタント、位置エグジスタント、好み設定エグジスタントなどの他のエグジスタントブロックには、必要に応じて、関連する属性及び記録情報が含まれる。
【００５８】
技能クラス（技能ボックス４０６）は、種々のプラットフォーム（すなわち、電話、ＷＡＰ、ＷＷＷ）における種々の操作性レベル（一般的なもの、及び異なる好み設定に関するもの）を維持するという目的に貢献する。顧客は、これらのクラスの各インスタンスへのリンクを有する。これらは好み設定クラスには含まれない。なぜならば、好み設定はプラットフォームを乗り越えて作用するが、ユーザの能力の場合、そのようなことはないからである。
【００５９】
図６に、広告関係の情報のための音声ポータル１１０のデータベース１７０によって使用される例示的データ構造モデル４５０を示す。継承及び関連の関係の描写は、図４のデータ構造モデル３００の描写の場合と同一である。例示的実施態様では、データ構造モデル４５０内に配置される広告情報は、データベース１７０に保存されている。しかし、代わりとなる実施態様では、そのような広告情報は、異なる別個の広告データベースに保存されてもよい。
【００６０】
好都合にも、データ構造モデル３００、４００及び４５０は、エグジスタント、関連及び関係に関する情報の絶え間なく拡張していく配置に備えるものである。さらに、モデル３００、４００及び４５０により、迅速かつ先に入力済みの情報を変更することなしに、関心の対象となる新規縦方向ドメインが創造される。例えば、モデル３００は、本、玩具、電子製品などの商品ばかりでなく、映画、コンサートなどのイベントに関係する情報も有する。バレーなど、いかなるイベントについても、「イベント」との継承関係及び適切な関連関係を有するエグジスタントとして、容易に追加することができる。同様に、車両など、いかなる商品についても、「製造品」との継承関係及び適切な関連関係を有するエグジスタントとして、容易に追加することができる。データ構造モデル３００、４００及び４５０の動的性質及び拡張能力により、音声ポータル１０は、広い範囲におけるインターネットに基づく情報及びサービスへの単一の音声ポータルとして有利である。
【００６１】
例示的データ構造モデル３００（図４）、データ構造モデル４００（図５）、及びデータ構造モデル４５０（図６）に示されるエグジスタントのようなエグジスタントについて、その例示的創造プロセスの流れ図７００を図７に示す。ステップ７１０において、インターネット上においてウェブページが見つけられる。例示的実施態様では、スパイダを用いることにより、事前に決定した項目カテゴリに関係する特定のウェブページを見つける。スパイダとは、文書を取出し、そしてその中で参照される文書の一部又はすべてを再帰的に取出すことにより、ワールドワイドウェブ（ＷＷＷ）に対する自動探索を実行する従来から周知のプログラムである。これとは対照的に、人が操作する通常のウェブブラウザでは、行イメージ及びＵＲＬによる転送以外、リンクの自動的追従は行われない。ステップ７１０が実行された後、ステップ７２０が実行され、そこでは、選択されたフォームを使用することによって見つけられたウェブページ上で情報が特定される。当該フォームは当該ページに重なり、特定の情報に対してフィルターをかける。ステップ７２０の後、ステップ７３０が実行され、そこでは、ステップ７２０においてフォームの重ね合わせにより抽出した情報から特徴的情報又は属性を特定するために、ルールが使用される。特徴的情報又は属性は、何がエグジスタントであるかを定義する。ルールは、エグジスタント属性の構成を定義する。例えば、映画エグジスタントは、題名、監督、配役、配給年、概要、等々の属性を有する場合がある。
【００６２】
ステップ７３０が実行された後、ステップ７４０が実行され、そこでは、エグジスタント内で属性が編成され、エグジスタントがデータベース１７０に保存される。エグジスタント内での属性の編成及び配置は、予め定義されるルールに従って構成されることが好ましい。
【００６３】
図８に、図７に関連して説明されたエグジスタントの例示的創造プロセスを示す。スパイダ８１０は、様々に異なるウェブページ上の情報を求めてインターネット２０上を縦横無尽に動き回る。スパイダ８１０によって収集された情報は、データ構造８３０に同情報を配置するために、ルール８２０に従って編成及び配置される。例示的実施態様では、スパイダ８１０は、映画に関する情報をインターネット２０より収集する。例えば、スパイダ８１０はＩＭＤＢウェブサイト上を動き回り、ある特定の映画について、題名、監督、配役、配給年、上映時間等に関する情報を収集する場合もある。映画情報がデータ構造８３０に一旦保存されると、データ構造８３０は語彙表８４０に当てはめられる。語彙表８４０は、データ構造８３０に含まれた属性を編成し、３つのコラムに情報を配置する。例示的実施態様では、語彙表８４０の第１コラムにはオリジナルデータが、第２コラムには正規化されタグが付されたフォーマットによるオリジナルデータが、そして第３コラムには検索可能でマッシュされたフォーマットによるデータが、それぞれ有される。語彙表８４０及びデータ構造８３０は、データベース１７０中のメモリ構造内に含まれる。
【００６４】
一例として、スパイダ８１０が、映画「Ｒａｉｄｅｒｓ Ｏｆ ｔｈｅ Ｌｏｓｔ Ａｒｋ」に関係する情報を求めてインターネット２０上を動き回る場合、インターネット２０から収集されたデータは、映画に対応するルールに照らして適用され、データ構造８３０内に配置される。映画についてのそのようなルールには、題名、監督、配役及び配給年が含まれてよく、これらはすべて映画の属性である。この例では、題名は「Ｒａｉｄｅｒｓ Ｏｆ ｔｈｅ Ｌｏｓｔ Ａｒｋ」、監督は「Ｓｔｅｖｅｎ Ｓｐｉｅｌｂｅｒｇ」、配役は「Ｈａｒｒｉｓｏｎ Ｆｏｒｄ及びＫａｒｅｎ Ａｌｌｅｎ」、配給年は「１９８１年」、そして上映時間は「１１５分」となる。そして、語彙表８４０に含まれるデータは、題名としては、オリジナルフォーマットの「Ｒａｉｄｅｒｓ Ｏｆ ｔｈｅ Ｌｏｓｔ Ａｒｋ」、正規化されタグが付されたフォーマットでのデータとして、＜ｔｉｔｌｅ＞Ｒａｉｄｅｒｓ Ｏｆ ｔｈｅ Ｌｏｓｔ Ａｒｋ＜／ｔｉｔｌｅ＞、そして検索可能でマッシュされたフォーマットでは、単語間のスペース及び冠詞など（例えば、ｔｈｅ、ａ、ａｎ）を省いた、ＲａｉｄｅｒｓＬｏｓｔＡｒｋ、となる。
【００６５】
図９にフローチャート９００を示す。フローチャート９００は、非プログラム的手段を用いてインターネット情報を収集する例示的プロセスを描写する。ステップ９１０において、検索ページが見つかり、パターンを用いて関連する情報を含む同ページ上の領域を分離する。ステップ９１０の後、ステップ９２０が実行され、そこでは、適切なフォームが見つかり、特別ルーチンを呼び出して実際のデータ及び情報を抽出する。ステップ９２０の後、ステップ９３０が実行され、そこでは、ある特定のページに対して、関連情報を有する複数のページが見つけられる。データ別パターンは別にして、特定ページ内のどこでデータ別パターンが動作するかを定義するエリアパターンが存在する。ステップ９３０が実行された後、ステップ９４０が実行され、そこでは、複数のページ上にある製品又はサービスの更なるリストへのリンクが見つけられる。例示的実施態様では、予測ルーチンを使用し、コードサンプルから製品リストの実際のパターンが計算される。
【００６６】
一般に、予測ルーチンは、ルールライターによって与えられる所望の出力からパターンを計算する。好都合なことに、パターン予測ルーチンはプロダクションのスピードを速める。なぜならば、ルールライターは、抽出したいテキスト部分をＨＴＭＬコードから単にペーストすればよいからであり、そのようなことが実現されるべくパターンを開発する必要はないからである。パターンを書くために現在使用される入力フィールドは、このデータを挿入するために使用される。
【００６７】
一例として、予測ルーチンは、書籍に関するデータを提供するウェブページのために作者データのパターンを作成するが、それには、まずルールライターをしてウェブページ上のサンプル作者名を作者フィールドへコピーさせる。次に、サンプルデータをウェブページ上のその位置へマッチさせるアルゴリズムが起動する。マッチしたデータに最も近い文字又はタグは、「接頭辞」及び「接尾辞」として識別される。接頭辞はマッチしたデータの前にある文字であり、接尾辞はマッチしたデータの後にある文字である。接頭辞及び接尾辞はパターン作成において使用される。
【００６８】
作成されたパターンはウェブページに当てはめられ、その他のデータとマッチされる。作成されたパターンが所望の結果と等しくないデータをピックアップした場合は、より完全で正確なパターンを得るために、パターンの作成に使用された接頭辞及び接尾辞が加えられる。この手順を繰り返すことで、パターンを改善する。
【００６９】
この例を更に明確にするために、書籍に関する製品データを提供するウェブページからの次のＨＴＭＬコードを参照する。
【００７０】
＜ｈｔｍｌ＞
＜ｔｉｔｌｅ＞Ｐｒｏｇｒａｍｍｉｎｇ Ｐｅｒｌ＜／ｔｉｔｌｅ＞
ｗｒｉｔｔｅｎ ｂｙ＜ｂ＞Ｌａｒｒｙ Ｗａｌｌ＜／ｂ＞
＜／ｈｔｍｌ＞
＜ｈｔｍｌ＞
＜ｔｉｔｌｅ＞Ｌｅａｒｎｉｎｇ Ｐｅｒｌ（＜ｂ＞２ｎｄ ｅｄｉｔｉｏｎ＜／ｂ＞）＜／ｔｉｔｌｅ＞
ｗｒｉｔｔｅｎ ｂｙ＜ｂ＞Ｒａｎｄａｌ Ｓｃｈｗａｒｔｚ＜／ｂ＞
＜／ｈｔｍｌ＞
【００７１】
ルールライターは「Ｌａｒｒｙ Ｗａｌｌ」を作者フィールドにダンプし、これが作者として抽出すべきデータであることを指示する。
【００７２】
パターン予測アルゴリズムは、大まかには次のように作動する。
【００７３】
ｎ＝１；
ｒｅｐｅａｔ
＄ｐａｇｅ＝〜ｍ／（｛．｝ｎ）Ｌａｒｒｙ＼ｓ＋Ｗａｌｌ（｛．｝ｎ）／ｘ；
＄ｐｒｅｆｉｘ＝＄１；
＄ｓｕｆｆｉｘ＝＄２；
＄ｐａｇｅ＝〜ｍ／＄ｐｒｅｆｉｘ（．＊？）＄ｓｕｆｆｉｘ／ｘ；
ｎ＝ｎ＋１
ｕｎｔｉｌ（＄１ｅｑ＜ｄｅｓｉｒｅｄ＿ｄａｔａ＞）；
【００７４】
第１番目のページ上でｎ＝１からスタートして以降、アルゴリズムは「＞Ｌａｒｒｙ Ｗａｌｌ＜」にマッチする。これは、＄ｐｒｅｆｉｘが値「＞」を獲得し、＄ｓｕｆｆｉｘが値「＜」を獲得することを意味する。次に、パターン予測アルゴリズムは、第１のステップで得た＄１及び＄２の値を用いてパターン「＞（．＊？）＜」を構築する。このパターンをウェブページにマッチさせると「＞Ｐｒｏｇｒａｍｍｉｎｇ Ｐｅｒｌ＜」という結果が得られ、これは所望の結果である「Ｌａｒｒｙ Ｗａｌｌ」と等しくはない。したがって、ｎがｎ＝２に増加され、接頭辞及び接尾辞にもう一つの文字が含まれるようにパターンが改良される。ウェブページを「（｛．｝２）Ｌａｒｒｙ＼ｓ＋Ｗａｌｌ（｛．｝２）」にマッチさせると「ｂ＞Ｌａｒｒｙ Ｗａｌｌ＜／」という結果が得られ、これは＄ｐｒｅｆｉｘが値「ｂ＞」を獲得し、＄ｓｕｆｆｉｘが値「＜／」を獲得することを意味する。次に、パターン予測アルゴリズムは、第１のステップで得た＄１及び＄２の値を用いてパターン「ｂ＞（．＊？）＜／」を構築する。このパターンをウェブページにマッチさせると所望の出力である「Ｌａｒｒｙ Ｗａｌｌ」という結果が得られる。
【００７５】
ここで、ルールライターが同一のパターンを違うウェブページに当てはめるため、ページに対して順次命令を実行していくと、同パターンは、書籍「Ｌｅａｒｎｉｎｇ Ｐｅｒｌ」に関するページ上の「第２版」、にマッチすることを見出す。すると、ルールライターは、所望の結果の第２の例を与えることによって（すなわち、ＧＵＩの入力フィールドに「Ｒａｎｄａｌ Ｓｃｈｗａｒｔｚ」をダンプする）アルゴリズムを改善し、これを契機として、パターン予測アルゴリズムは、＜ｂ＞の前に「ｙ」を実現するパターンが得られるまで、ｎを更に増加させていく。アルゴリズムの反復動作は数回にわたる場合があるが、その回数は、ウェブデータ及び必要なパターンの複雑さに依存する。
【００７６】
ステップ９４０が実行された後、ステップ９５０が実行され、そこでは、ベンダー別データ抽出ファイルが生成される。例示的実施態様では、コードサンプルから適切なＵＲＬを計算するルーチンが使用される。あるいは、ＵＲＬを計算するルーチンはフォームとしてパスされることが可能である。ステップ９５０が実行された後、ステップ９６０が実行され、そこでは、キャッシュが生成される。ステップ９６０が実行された後、ステップ９７０が実行され、そこでは、製品データの抽出のためのパターンが生成される。好ましい実施態様では、回帰テストのメカニズムが、特別なルーチンの編集をサポートする。
【００７７】
図１０に、音声ポータル１０に関連するルールの非プログラム的開発の例示的プロセスを示す。この例示的プロセスでは、ルールライターの集合１０１０からのルールライターは、データソース１０３０、１０３５もしくは１０４０又はワールドワイドウェブ（「ＷＷＷ」）１０２０に接続する他のデータソースの内の１つからの情報にアクセスするために、ＷＷＷ１０２０にアクセスする。データソースから取り出されたデータは、データ編成ツール１０２５を利用してデータ構造内に配置される。ルールライター１０１０はデータ編成ツール１０２５を使用し、多数ある可能なフォームの内の１つをＷＷＷ１０２０経由で得ることのできる情報の「ページ」に適用する。そのようなフォームにより、ページ上に存在し、特有のタグが付された適切な情報の位置を表す兆候が提供される。例えば、ＷＷＷ１０２０上のページには、同ページの左上のコーナーにデータ入力ボックスが含まれているかもしれない。さらに、パートやサービスについての適切な情報は、書籍のタイトルのための「＜ｔｉｔｌｅ＞」などの、ＨＴＭＬタグの後に位置するかもしれない。
【００７８】
本明細書で使用される「ページ」という用語は、ユーザインターフェース画面又はそれに類似する設定を含むものであり、それらは、ユーザからは診断システムと見ることができるもの、例えば、データ、メッセージ、レポート等の画像表示又は文字表示を提供する画面などを含むものである点に、留意されるべきである。さらに、そのようなページは、Ｊａｖａ（登録商標）、ｐｅｒｌ、ｊａｖａ（登録商標）ｓｃｒｉｐｔ、その他適切な言語などのマークアップ言語又はプログラミング言語によって定義される場合がある。
【００７９】
ルールライター１０１０によってデータ編成ツール１０２５から選ばれたフォームを使用しながら、データソースからのデータは、データ構造１０４５、１０５０、１０５５、又は情報保存のための類似の構造内へと整理されていく。データ構造１０４５、１０５０及び１０５５は、統一データ構造１０６０の形成において、比較され、融合され、もしくは利用される場合がある。統一データ構造１０６０はデータベース１０７０に保存される。
【００８０】
好都合なことに、図１０に示される例示的プロセスにより、非熟練的ルールライター１０１０は、データ編成ツール１０２５によって提供される様々なフォームの中から選択し、ＷＷＷ１０２０経由でアクセス可能な特定のウェブサイトの情報を取り出すことができる。そのような構成において、ウェブページ上に含まれるデータソース１０３０、１０３５及び１０４０からの情報は、ルールライター１０１０がデータ編成ツール１０２５を使用しながら選択したフォームと共にデータベース１０７０に対して絶えず更新することができる。データ構造１０４５、１０５０及び１０５５に含まれる情報に対して正確性を見るための比較が行われる際、データ編成ツール１０２５は、ウェブページがいつ、関連のウェブページ上でデータのフォーマット又は配置を変更したかを検出する。
【００８１】
図１１から図２４に、新規ルールを作成する例示的プロセスを示す。図１１から図２４は更に、ルールライター及びデータ編成ツール１０２５（図１０）間の考え得る相互作用を示す。一つの例示的ルールは既存のルール、すなわちＡｍａｓｏｎ．ｃｏｍ書籍製品についてのものに基づいている。このルールの構築においてとられるステップは、他のルールの構築においてとられるステップと類似するものである。
【００８２】
図１１に、ルール８２０（図８）の作成を開始するのに使用されるグラフィカルユーザインターフェース（ＧＵＩ）１１１０を示す。ＧＵＩ１１１０には、ベンダーウィンドウ１１２０、スパイダ選択ウィンドウ１１３０、クエリウィンドウ１１４０、ステータスウィンドウ１１５０、検索ボックスエリア１１６０、そしてコードウィンドウ１１９７が含まれる。検索ボックスエリア１１６０には、スパイダバー１１７０、右矢印セット１１８０、左矢印セット１１９０、そして検索ウィンドウ１１９５が含まれる。
【００８３】
新しいデータソースを開始するため、ルールライターはベンダーウィンドウ１１２０内のデータソース（例えば、Ａｍａｚｏｎ Ｂｏｏｋ）に入る。ルールライターは「Ｅｎｔｅｒ」を押し、「Ｎｅｗ」ボタンをクリックする。これらの操作を行った後、図１２に示されるグラフィカルユーザインターフェース（ＧＵＩ）１２００が表示される。ルールライターは、データソースが正しくリストされていることを確認し、その後で「済み」ボタンをクリックする。次に、図１３に示されるグラフィカルユーザインターフェース（ＧＵＩ）１３００が表示される。選択されたベンダー名に対応するＵＲＬが表示される。ルールライターは、正しいＵＲＬを確認することを求められる。Ａｍａｚｏｎ Ｂｏｏｋの例では、ＧＵＩ１３００のウィンドウに「ｈｔｔｐ：／／ｗｗｗ．ＡｍａｚｏｎＢｏｏｋ．ｃｏｍ」というＵＲＬが現れる。しかし、ＵＲＬのリンクは「ｈｔｔｐ：／／ｗｗｗ．Ａｍａｚｏｎ．ｃｏｍ」である。ルールライターはＵＲＬを修正し、「済み」ボタンをクリックする。
【００８４】
ここで、再び図１１において、ルールライターは、望みクエリのタイプを選択する。第１に、ルールライターはクエリウィンドウ１１４０を選び、可能なクエリのリストから選択する。例えば、関心の対象となっている書籍縦方向ドメインにおけるクエリとして、「書籍のパッケージ」が可能であるかもしれない。この検索は、ルールライターがクエリウィンドウ１１４０内の「ＳＤＥ」（検索データエディタ）をクリックしたときに開始される。ＳＤＥボタンにより検索データエディタが呼び出され、図１４に示されるグラフィカルユーザインターフェース（ＧＵＩ）１４００が提供される。ＧＵＩ１４００には、関心の対象である特定の品目についての検索において使用可能な属性のリストが表示される。例えば、書籍が検索されている場面では、ＩＳＢＮ又はＵＰＣなどの属性が表示される。他の品目についての検索である場合、当該品目に対応する属性が列挙される。「映画上映」についての検索では、映画パッケージ、時間、上映日などの属性（図４に関連して説明されたブロック３３０参照）が列挙される。
【００８５】
ルールライターは、対応するデータボックス内にＩＳＢＮ番号をタイプし、「済み」をクリックする。好都合なことに、ＧＵＩ１４００内のボタン１４３０により、ルールライターは、異なる検索における異なる検索条件を保存することができる。検索条件が入力されると、ルールライターは「済み」をクリックし、そして特定のデータソース（すなわち、Ａｍａｚｏｎ Ｂｏｏｋ）に対してルールが定義されていないので、図１５に示されるグラフィカルユーザインターフェース（ＧＵＩ）１５００が現れる。ＧＵＩ１５００は、ルールライターが新規ルールを追加し、あるいは検索データを変更したいかどうかを問いかける。この例では、ルールライターは「ａｄｄ」ボタンをクリックし、ＧＵＩ１５００は拡大されて図１６に示されるグラフィカルユーザインターフェース（ＧＵＩ）１６００となる。
【００８６】
次に図１６において、ルールライターは、正しいクエリタイプが選択されているのを確認する。この例では、ＩＳＢＮが選ばれており、ルールライターは「ｙｅｓ」ボタンをクリックする。図１７に示されるグラフィカルユーザインターフェース（ＧＵＩ）１７００が現れ、ルールライターに対し、Ａｍａｚｏｎ Ｂｏｏｋのホームページがネットスケープブラウザにロードされることが伝えられる。ルールライターは、ＩＳＢＮルールに関連するウェブページをブラウズするよう指示される。検索ページのインターネットブラウザへのロードが終わると、ルールライターは「済み」ボタンをクリックする。
【００８７】
図１８に示されるグラフィカルユーザインターフェース（ＧＵＩ）１８００には、ルールライターによって選択されるフォームのオプションが示される。フォームが正しければ、ルールライターは「済み」ボタンをクリックする。フォームのリストにルールライターが求める選択肢がない場合、ルールライターは「ｎｅｘｔ」ボタンをクリックし、ページ上の他のフォームを参照する。マッチするページが見つかると、図１９に示されるグラフィカルユーザインターフェース（ＧＵＩ）１９００が表示される。
【００８８】
データ編成ツール１０２５（図１０）が、得られたページをインターネットブラウザ上に表示する。ページが正しければ、ルールライターはＧＵＩ１９００上の「ＯＫ」をクリックする。図２０に示されるグラフィカルユーザインターフェース（ＧＵＩ）２０００が現れ、検索において複数品目のマッチがあった場合、いかにしてページ上の単一品目を検知するかを問いかける。ＧＵＩ２０００は、クエリの対象品目についての詳細事項を得ることのできるＵＲＬがどこにあるかを示すためにも使用される。単一の品目のみが見つかった場合、十分な情報が提示されず、よって正規表現が構築されないため、ルールライターは「延期」ボタンをクリックする。複数の品目が見つかった場合、データウィンドウ２０１０に正規表現が入力される。例えば、一人の作者は数冊の本を執筆している場合があるので、作者による検索では複数の品目が帰ってくる場合がある。他のケースでは、クエリによって一品目のみがマッチしたとしても、更に情報を得るためにＵＲＬリンクをたどることが必要な場合がある。
【００８９】
次に、図２１に示すグラフィカルユーザインターフェース（ＧＵＩ）２１００が現れ、複数製品のページを検知するために使用される。ルールライターが検索される品目に直接到達した場合、正規表現を構築するための情報は必要ではない。再度図１１を参照すると、コードウィンドウ１１９７は取り出されたページからのＨＴＭＬコードで一杯である。この時点で、ルールライターは属性を特定する準備ができている。属性は、その名前の横にあるボックス内へ正規表現を入力することによって特定される。正規表現は、表現の結果として、その中に一つのサブストリングを特定しなければならない（括弧を使用）。例えば、「ｔｈｉｓ（ａｌｌ）ｍａｔｃｈｅｓ」という正規表現からは、結果として「ａｌｌ」が帰ってくる（正規表現はマッチできると仮定）。例えば、書籍のタイトルを見つけるために使用されるパターンの決定では、ルールライターが検索ウィンドウ１１９５の中に書籍のタイトルをタイプすることが求められる。様々なＨＴＭＬシグナルを使用してもよい。単語間に存在し得る空白スペースを示すために、「＼ｓ＊」が要求される。検索ウィンドウ１１９５に入力された検索ストリングの第１のマッチは、ＨＴＭＬコードで見つかった第１のマッチを強調する。例えば、タイトルは、余分の情報と共に、一対の＜ｔｉｔｌｅ＞タグの内側で見つかるかもしれない。書籍のタイトルの例示的属性は、「＜ｔｉｔｌｅ＞（［＾＜］＊）＜／ｔｉｔｌｅ＞」であるかもしれない。属性が入力されると、属性に対するすべてのマッチが見つけられる。
【００９０】
再度、図１４において、検索データエディタ１４００は、タイプに依存する属性に対して値を割り当てるために使用することのできるフォームから構成される。ステータスウィンドウでは、データ編成ツール１０２５が何を行っているかが示される。例示的実施態様では、ステータス状態としては、何もしていない、インターネット上でクエリが稼動中、そして、キャッシュ使用中、がある。クエリウィンドウ１１４０により、ルールライターは、ＳＤＥボタンを使用することによって検索基準を設定するだけでなく、問題のデータソースに望まれるクエリのタイプを設定することができる。
【００９１】
スパイダ選択ウィンドウ１１３０により、ルールライターは、クエリによる検索を行わない場合、使用されるスパイダを設定することができる。例示的実施態様では、可能なスパイダのタイプは、フル、インクリメンタル、スペシャル、そして、レファレンスである。フルスパイダは、選ばれたタイプにマッチするすべての品目を対象とする。インクリメンタルスパイダは、通常、インターネットデータソースからのデータの更新を集めるために使用される。スペシャルスパイダは、通常、書籍の場合のベストセラーなど、サイトが有する特別なものを集めるために使用される。レファレンススパイダは、通常、サイトがまだ立ち上がった状態にあり、ルールが機能していることを確認するために使用される。
【００９２】
ベンダーウィンドウ１１２０により、ルールライターは、作業対象のデータソースを設定することができる。検索ウィンドウ１１９５により、ルールライターは、ＨＴＭＬコード内に検索されるべきテキストを保存することができる。コードウィンドウ１１９７には、テキスト入力の位置を示すカーソルが存在する。左矢印セット１１９０には、キャッシュから検索が行われる際の検索対象領域の開始点である第１番目のナンバーが含まれる。第２番目のナンバーはキャッシュ内の全ページ数を示す。このウィンドウの矢印のセットにより、ルールライターがキャッシュから行う場合の開始ページがコントロールされる。右矢印セット１１８０には、取り出されたページをスクロールする矢印が含まれる。
【００９３】
スパイダはクエリに類似するが、適用可能なルールが他に存在しないときに呼び出される。スパイダの役目は、特定されたタイプにマッチするウェブサイトの各オブジェクトに関する情報を得ることである。スパイダは入れ子にされた数個のループから構成され、各ループは階層を１レベル深く入るよう設計されている。図２２において、書籍スパイダの場合について、スパイダの例示的階層構造２２００が示され、そこでは、レベル２２１０は開始ページ、レベル２２２０は書籍カテゴリぺージ、レベル２２３０は書籍サブカテゴリページ、そしてレベル２２４０は書籍ページを表す。
【００９４】
次に、図２３において参照されるグラフィカルユーザインターフェース（ＧＵＩ）２３００は、スパイダルールに関連するページのＵＲＬを取り出すために使用される。スパイダ深度スライドルールにより、ルールライターは、実際の製品ページに到達するにはリンクをいくつ降りていかねばならないかについて、データ編成ツール１０２５に教えることができる。上限スライドルールにより、ルールライターは品目に対してスパイダしていける限界を特定することができる。ＵＲＬが選択され、スパイダ深度及び上限が選択されると、ルールライターは「済み」ボタンをクリックする。図２４に示されるグラフィカルユーザインターフェース（ＧＵＩ）２４００が表示される。ルールライターは、スパイダが用いる検索パターンを入力するが、その入力は、図１１に関連して説明されたクエリのために入力される検索パターンと同じように行われる。パターンが入力されると、ルールライターは「構築」ボタンをクリックし、スパイダが起動する。
【００９５】
好都合なことに、図１１から図２４に示され、かつそれらに関連して説明されるグラフィカルユーザインターフェースにより、ルールライターが非熟練者であっても、データ検索を行い、情報の取り出しのためのルールのフォームを作成することができる。フォームが作成されると、フォームは、更新された情報を収集するために頻繁に使用することができる。さらに、ベンダーのウェブサイトで入手できる多量の情報の取り出しにおいてフォームは役立つ。同ウェブサイトは、ベンダーによるウェブサイト上での情報の配置及び表示に対応する共通フォームを使用する。好都合なことに、非熟練者によるルール作成のフォームにより、ウェブサイトにおいて入手し得る情報の更新が低コストで行える。さらに、好都合なことに、フォームにより、インターネット情報の正確な取り出しが自動化される。
【００９６】
図２５に、データベース内における情報融合の例示的プロセスを示す。図２５に示される例示的実施態様では、フローチャート２５００は、融合エンジン１５０（図２）によって実行される非常に単純化された融合プロセス、又は「クイックフュージョン」を記述する。ステップ２５１０では、更新エンジン１６０がネットワーク２０から情報を受け取り、エグジスタントサブシステム１４０を介して、データベース１７０のエグジスタントデータ構造内に情報を配置する。融合エンジン１５０は、エグジスタントサブシステム１４０を介して、更新エンジン１６０からエグジスタントへアクセスでき、エグジスタントサブシステム１４０はデータベース１７０にアクセスする。ステップ２５１０が実行された後、ステップ２５１５が実行され、そこでは、融合エンジン１５０が、ステップ２５１０で取り出されたエグジスタントに対応する属性定義表から正確な融合属性を収集する。ステップ２５１５が実行された後、ステップ２５１２が実行され、そこでは、データベース１７０から取り出されたエグジスタントからの各融合属性について、容易に比較し得るフォームへの「マッシュ」を融合エンジン１５０が実行する。例示的実施態様では、「マッシュ」されたフォームでは、スペース、前置詞、その他非本質的単語は取り除かれる。「マッシュ」されたフォームでは高速検索機能が得られるので好都合である。
【００９７】
ステップ２５２０が実行された後、ステップ２５２５が実行され、そこでは、融合エンジン１５０が、データソースを「同じ」に設定し、ステータスを「正規」に設定するデータベースクエリを作成する。このクエリは、現行の情報にマッチする同じデータソースファイルからの既存の正規エグジスタントを見つけることが意図されている。ステップ２５２５が実行された後、ステップ２５３０が実行され、そこでは、データベース１７０でマッチが見つかったかどうかが決定される。ステップ２５２５のクエリによってデータベース１７０でマッチが見つかった場合、ステップ２５３５が実行され、そこでは、データベース１７０に含まれるエグジスタントが更新される。
【００９８】
ステップ２５２５のクエリからデータベース１７０内でマッチが見つからなかった場合、ステップ２５４０が実行され、そこでは、ステップ２５２５のクエリが再構成され、データソースが「同じ」に設定され、ステータスが「非正規」に設定される。このクエリは、現行の情報にマッチする同じデータソースファイルからの既存のエグジスタントを見つけることが意図されている。ステップ２５４０の後、ステップ２５４５が実行され、そこでは、ステップ２５４０の再構成されたクエリからデータベース１７０内でマッチが見つかったかどうかが決定される。マッチが見つかった場合、ステップ２５５０が実行され、そこでは、データベース１７０内のエグジスタントが更新される。
【００９９】
データベース１７０内でマッチが見つからなかった場合、ステップ２５５５が実行され、そこでは、クエリが再構成され、データソースが「任意」に設定され、ステータスが「正規」に設定される。このクエリは、現行の情報にマッチする任意のデータソースからの既存の正規エグジスタントを見つけることが意図されている。ステップ２５５５の後、ステップ２５６０が実行され、そこでは、データベース１７０内でマッチが見つかったかどうかが決定される。データベース１７０内でマッチが見つからなかった場合、ステップ２５６５が実行され、そこでは、データベース１７０にエグジスタントが加えられる。
【０１００】
データベース１７０でマッチが見つかるか、あるいはステップ２５５０が実行された場合、ステップ２５７０が実行され、そこでは、当該マッチがシステムエグジスタントであるかどうかが決定される。マッチがシステムエグジスタントであれば、ステップ２５７５が実行され、そこでは、システムエグジスタントが更新される。マッチがシステムエグジスタントでないならば、ステップ２５８０が実行され、そこでは、正規システムエグジスタントが形成される。ステップ２５８０が実行された後、ステップ２５８５が実行され、そこでは、データベース１７０にエグジスタントが加えられる。ステップ２５８５の後、ステップ２５９０が実行され、そこでは、融合表が更新される。
【０１０１】
好都合なことに、図２５に示される、データベース内での情報融合の例示的プロセスでは、複数のウェブサイトでの情報の比較が行われる。そのような動作において、あるウェブサイトが他のウェブサイトと同一の情報を含むかどうかが決定される。さらに、音声ポータル１０のデータベース１７０に含まれる情報は、インターネットに基づくソースから情報、関係、及び情報関連を絶えず加えることができ、データソースから取り出された情報の使い勝手が広がる。
【０１０２】
図２６に、融合の例示的プロセスにおいて実行されるステップを記述するフローチャート２６００を示す。図２６に関連して説明される例示的プロセスでは、図２５に関連して説明されたフローチャート２５００に描写された融合プロセスよりもより包括的な融合プロセスが示される。ステップ２６１０では、融合エンジン１５０がデータベース１７０から属性定義表を読み込む。ステップ２６１０が実行された後、ステップ２６１５が実行され、そこでは、融合エンジン１５０が、より高度な融合を要求する各エグジスタントタイプのための融合コントロール言語ファイルを読み込む。ステップ２６１５が実行された後、ステップ２６２０が実行され、そこでは、融合エンジン１５０が、融合ファイルを中間コンピュータコード内へコンパイルする。ステップ２６２０が実行された後、ステップ２６２５が実行され、そこでは、融合エンジン１５０が、先に融合されたエグジスタントをメモリ内へとホールドする。ステップ２６２５の後、ステップ２６３０が実行され、そこでは、融合エンジンが属性を等価セットにまとめる。ステップ２６３０の後、ステップ２６３５が実行され、そこでは、属性がテキストであるかどうかが決定される。融合エンジン１５０が、属性はテキストではないと決定すれば、ステップ２６４０が実行され、そこでは、値にインデックスが付される。融合エンジン１５０が、属性はテキストであると決定すれば、ステップ２６４５が実行され、そこでは、融合エンジン１５０により、属性中のサブストリングの出現にインデックスが付される。
【０１０３】
ステップ２６４５の後、ステップ２６５０が実行され、そこでは、融合エンジン１５０により、テキストが構成されているかどうかが決定される。テキストが構成されていないと決定されると、ステップ２６７０が実行される。テキストが構成されていると決定されると、融合エンジン１５０がステップ２６５５において、テキストの位置及び分離された構造セグメントを特定する。ステップ２６５５の後、ステップ２６６０が実行され、そこでは、融合エンジン１５０が分離された部分をパーズし、意味情報を特定する。ステップ２６６０の後、ステップ２６６５が実行され、そこでは、融合エンジン１５０が意味情報にインデックスを付す。ステップ２６６５の後、ステップ２６７０が実行され、そこでは、融合エンジン１５０が妥当性チェックを実施し、データベース１７０の完全性を確認する。ステップ２６７０の後、ステップ２６７５が実行され、そこでは、融合エンジン１５０が融合すべきエグジスタントを取り出す。
【０１０４】
ステップ２６７５の後、ステップ２６８０が実行され、そこでは、融合エンジン１５０により、エグジスタントのタイプに対応する融合基準及びマッチングプログラムが起動される。融合基準及びマッチングプログラムには、図１０に関連してその確立が説明されたエグジスタントルールの使用が含まれる。ステップ２６８０の後、ステップ２６８５が実行され、そこでは、融合エンジン１５０が融合基準及びマッチングプログラムからの第１の融合ルールを実行し、すべてのマッチが戻される。ステップ２６８５の後、ステップ２６９０が実行され、そこでは、許容し得るマッチが見つかったかどうかの決定がなされる。例示的実施態様では、許容し得るマッチとは、所定のパーセンテージ（例えば７０％）の属性が共通であるものである。代わりの実施態様では、許容し得るマッチは、すべての属性が同一の値であるものである。許容し得るマッチが見つかったならば、ステップ２６９７が実行され、そこでは、融合エンジン１５０がエグジスタントを融合する。許容し得るマッチが見つからなかったならば、ステップ２６９１が実行され、そこでは、次の融合ルールが実行され、すべてのマッチが戻される。
【０１０５】
ステップ２６９１の後、ステップ２６９２が実行され、そこでは、許容し得るマッチが見つかったかどうかの決定がなされる。許容し得るマッチが見つかったならば、ステップ２６９７が実行され、そこでは、融合エンジン１５０がエグジスタントを融合する。エグジスタントの融合には、融合されるエグジスタントに関連する新しいエグジスタントの作成が含まれ、その中にはすべての情報が含まれる。許容し得るマッチが見つからなかったならば、ステップ２６９３が実行され、そこでは、最終ルールがテストされているかどうかの決定がなされる。最終ルールがテストされていないならば、ステップ２６９１を再度実行する。最終ルールがテストされているならば、ステップ２６９４が実行され、そこでは、融合エンジン１５０により、強い部分マッチがあるかどうかが決定される。例示的実施態様では、強い部分マッチとは、例えば７０％等、あるパーセンテージ以内でマッチがあるものである。強い部分マッチが存在するならば、ステップ２６９８が実行され、そこでは、人による検査に従う。部分マッチが見つからないならば、ステップ２６９５が実行され、そこでは、融合エンジン１５０が作成された融合を拒絶し、更にステップ２６９９が実行され、そこでは、新しいエグジスタントが作成される。
【０１０６】
好都合なことに、データベース内での情報融合に関する図２６の例示的プロセスでは、同じ又は異なるデータソースからの情報についての自動比較が行われる。そのような状況において、データベース１７０内に保存される情報を絶えず更新し、更に他のデータソースからの情報への関連を継続的に付け加えていくことが可能である。さらに、融合により、インターネット上に個別に存在する数百万ものデータベースよりも、より完全で頑強な統合データベースの編纂が可能となる。
【０１０７】
図２７に、２つのデータ構造から正規データ構造を作成する例示的プロセスを示す。データファイル２７００は固有の識別番号によって識別され、その中に、第１データファイル２７１０、第２データファイル２７２０及び正規データファイル２７３０を含んでいる。例示的実施態様では、第１データファイル２７１０には、ＩＭＤＢ（「Ｉｎｔｅｒｎｅｔ Ｍｏｖｉｅ Ｄａｔａ Ｂａｓｅ」）ウェブサイト（ｈｔｔｐ：／／ｗｗｗ．ＩＭＤＢ．ｃｏｍ）から取り出された特定の映画に関する情報が含まれる。第２のデータファイル２７２０には、Ｒｅｅｌ．ｃｏｍウェブサイトから得られた特定の映画に関する映画情報が含まれる。図２７に示される例では、データファイル２７１０には、題名「Ｂｏｙｓ ｏｆ Ａｒｉｚｏｎａ」、監督「Ｗｉｌｔｚ」、配給年「１９９７」、そして概要「名作」、が含まれている。同様に、データファイル２７２０には、題名「Ｔｈｅ Ｂｏｙｓ ｏｆ Ａｒｉｚｏｎａ」、監督「Ｂｏｂ Ｗｉｌｔｚ」、配給年「１９９８」、そして空白の概要、が含まれている。
【０１０８】
正規データファイルの作成プロセスにおいて、ルールファイル２７４０が導入され、それには特定のタイプの情報のためのルールが含まれている。図２７に示される例では、ルールファイル２７４０には映画の属性に関する情報が含まれている。ルール２７４０を適用すると、データファイル２７１０とデータファイル２７２０から最も完全な題名、この場合は「Ｔｈｅ Ｂｏｙｓ ｏｆ Ａｒｉｚｏｎａ」、を取り出すことによって、クロニクルデータファイル２７３０が作成される。監督情報はデータファイル２７２０から得られが、その理由は、データファイル２７２０には監督の姓と名がふくまれ、データファイル２７１０よりもより完全であるからである。データファイル２７１０にある配給年とデータファイル２７２０にある配給年との間で対立が生じている。先の情報に基づき、データファイル２７２０の配給年がより正しいことを示すことにより、同対立は解消される。データファイル２７２０の概要は空白であるため、クロニクルデータファイル２７３０にはデータファイル２７１０の概要が含まれる。
【０１０９】
好都合なことに、図２７に関連して示されるクロニクルデータファイルの作成プロセスでは、より完全で正確な情報を含むデータファイルが作成される。さらに、同プロセスにより、複数のウェブサイト間での情報の比較が可能となる。さらに、クロニクルデータファイルの作成プロセスでは、データファイル間での関連及び関連関係の向上が可能となる。
【０１１０】
図２８に、ウェブから得られたデータを分離し、そしてデータベース保存のために同データを変換する際に行われる動作に関する機能図２８００を示す。例示的プロセスには、ネットワーク２０から、データが配置され、編成されるデータ構造２８１０へのデータ抽出が含まれる。例えば、インターネットから交通レポートに関するデータが抽出され、説明、主要道路、交差点、時刻、日付そして混雑度に関する情報が含められる場合がある。データ構造２８１０は、データ構造２８１０へのデータの配置及び編成を許可するテキストパターン及び説明を含むルール２８１５によって作成、編成される。データ構造２８１０は、データベース上のデータファイルに保存される。データ構造２８１０内のデータは変換され、その際、第１用語置換フォームが適用され、データ構造２８２０が作成される。データ構造２８２０を作成するための用語置換の際にルール２８２５が適用され、これには変換表への語彙入力が含まれる。交通レポートの例では、「Ｒｄ．」が「ｒｏａｄ［道路］」に、「Ｉ．」が「ｉｎｔｅｒｓｔａｔｅ［州間高速道路］」に、「Ｒｔ．」が「ｒｏｕｔｅ［ルート］」に、それぞれ変換される。
【０１１１】
データ構造２８２０に含まれるデータは、次に、転送データに対して属性フレーズグラマーを適用するルール２８３５に従い、データ構造２８３０のパーズされたフォームに入れられる。交通レポートの例では、東西南北等の「ｄｉｒｅｃｔｉｏｎ［方角］」が特定され、「Ｉｎｔｅｒｓｔａｔｅ［州間］」、「ｈｉｇｈｗａｙ［高速道路］」等の「ｈｉｇｈｗａｙ ｉｄｅｎｔｉｆｉｅｒ［高速道路識別子］」が決定される。データ構造２８３０のデータは、次に、用語配置ルール２８４５を適用することによってデータ構造２８４０の再配置フォームに入れられる。データ構造２８４０のデータは、第２用語置換フォームによって操作され、語彙変換表からのルール２８５５を適用することによってデータ構造２８５０に配置される。例えば、用語「Ｓｔ．」は、語彙変換表の位置識別子＜ｓｔｒｅｅｔ ｓｔ．＞又は＜ｃｉｔｙ ｓｔ．＞に基づいて、「ｓｔｒｅｅｔ［通り］」又は「ｓａｉｎｔ［聖人］」として判定される。
【０１１２】
語彙変換が実行された後、データは、非融合、正規化及びタグを付された形式で、データ構造２８６０に配置される。データ構造２８６０は、データベース２８５０内にあることが好ましい。正規化及びタグを付されたフォーマットとは、容易にデータを検索、比較できる均一編成とＨＴＭＬタグを含むフォーマットを指す。多くの場合、ＨＴＭＬタグにより、データのタイプ、位置及び長さに関する情報が得られる。非融合とは、データが、図２５及び図２６に関連して説明された融合プロセスを経ていないことを意味する。
【０１１３】
好都合なことに、図２８に関連して説明されたデータ分離プロセスでは、ウェブからデータが取り出され、そのデータは、データベース内の正規化されたタグ付きフォーマットに変換される。正規化され、タグが付けられたデータは、編成、操作、そして融合のために調整される。好都合なことに、データ分離プロセスは均一で、広い範囲のデータソースからのデータに対して機能する。したがって、一般に、同プロセスには、インターネットソースからデータを獲得すること、第１フォーマットの獲得データを有する第１データファイルを作成すること、そして、特定のインターフェースに関連する第２フォーマットのフレーズを獲得データから生成すること、が有される。獲得したデータを第１及び第２のフォーマットに変換するために、広い範囲のアプリケーションを使用してもよい。例えば、テキストパターン、語彙変換表、属性フレーズグラマー、及び用語配置ルールを用いて、獲得したデータを均一で検索可能なフォーマットに変換してもよく、同データはデータベース内のデータファイルに保存され、保存されたデータは、その後、インターフェース別の特定フォーマットに変換される。代わりの実施態様では、その他のパターン、表、ルール、そしてデータ操作アプリケーションが使用される場合もある。
【０１１４】
図２９に、あるユーザインターフェースプラットフォーム（例えば、ＷＡＰ、ウェブ、電話、ＡＳＲ、ＴＴＦ）経由の、音声ポータル１０のユーザに対するデータベース１７０からのデータの変換を示す機能図２９００を示す。データ構造２８６０（図２９にも示される）に含まれるデータは、ルール２９１５を適用することによって、正規化されたタグ付きデータのための属性フレーズグラマーとともに、データ構造２９１０のパーズされたフォーマットに入れられる。属性フレーズグラマーは正規化されたタグ付きデータを取り込み、特定された属性を含むセンシブルなフレーズを生成する。その後、データ構造２９１０からのデータは、語彙入力変換表を含むルール２９２５を用いて用語置換されたフォームを適用することによって、データ構造２９２０に配置される。例示的実施態様では、ルール２９２５の語彙入力変換表には、特定のインターフェースに対応するデータ出力構造が記録されている。例えば、用語「ｒｏｕｔｅ［ルート］」は、ＷＡＰアプリケーションでは「Ｒｔ．」に変換され、音声を用いた電話アプリケーションでは「ルート」に変換される。同様に、用語「Ｕ．Ｓ．」は、ＷＡＰアプリケーションでは「Ｕ．Ｓ．」に変換され、音声を用いた電話アプリケーションでは「ユーエス」に変換される。
【０１１５】
データ構造２９２０からのデータは、使用される出力装置毎に用語再配置ルールが適用されるルール２９３５を適用することによって、データ構造２９３０中の再配置フォームに入れられる。用語再配置ルールは、個別のユーザインターフェースに最もよく適合する配置となるように用語を移動する。データ構造２９３０内のデータは、その後、データ構造２９４０内に置かれ、そこでは、フレーズ生成グラマーを含むルール２９４５を適用することによってセンテンスが生成される。例えば、次のようなセンテンスが生成される：＜主要道路＞上の＜地点＞から＜地点＞の間で＜重大な＞交通事例が発生している。データがデータ構造２９４０のフォーマットに一旦変換されると、同データは、ＷＡＰ、ウェブ、電話、ＡＳＲ、等々の様々な出力インターフェースのために調整される。
【０１１６】
好都合なことに、図２９に関連して説明されるデータ変換プロセスは、データが取り込まれ、同データが広範囲のユーザインターフェースのために調整される、統一されたプロセスである。例えば、同プロセスにより、データをウェブソースから抽出し、その意味的構造を特定し、そして、音声インターフェースを介する音声送信のために調整することができる。それと同時に、同プロセスにより、ＷＡＰ装置及びウェブアプリケーションに対して、送信のために同じデータを調整することが可能となる。
【０１１７】
図３０から図３３に、ユーザと音声ポータル１０との間の例示的対話を表す動作パスのいくつかを示す。ユーザインターフェース１１０は、図３２及び図３３に関連して説明されるように、明示的なプロンプトを用いてユーザによる適切な発話を促すことが好ましい。
【０１１８】
図３０は、例示的システムの概観を表すフロー図３０００であり、音声ポータル１０の様々な機能を表すプロセスブロックを含んでいる。例示的実行パスでは、ブロック３０１０において、音声ポータル１０が、「アメリカンエキスプレスが提供するＱｕａｃｋへようこそ」と発話し、ユーザに挨拶する。音声ポータル１０は、本人確認のために送話人ＩＤを使用することが好ましい。好ましい実施態様では、電話番号が顧客属性としてデータベース１７０に保存されている。あるいは、電話番号は、顧客データベースに保存されている。音声ポータル１０による発話は次のように続く：「こんにちは、スティーブ・ウッドさん。あなたのＰＩＮ［個人識別番号］を、口頭又は数字キーパッドから入力して下さい。もしスティーブさんでなければ、あなたの電話番号を口頭又はキーパッドから入力して下さい」。すると、ユーザは「５０８２」に音声で応答し、自身のＰＩＮを与える。認証がなされると、音声ポータル１０はブロック３０２０へ進む。ブロック３０２０において、音声ポータル１０は次のように指示する：「あなたは今、Ｑｕａｃｋのランウェイにいます。次のリストの中からあなたが興味のあるカテゴリを言って下さい：映画、天気、交通、株、及びスポーツ」。ユーザはカテゴリ名で応答するか、さようならと応答する。カテゴリ名が応答されたならば、音声ポータル１０はブロック３０３０へ進む。さようならと応答されれば、音声ポータル１０は、音声ポータル１０に対し、素直に出口を提供する。例示的応答では、ユーザは「天気」と答え、音声ポータル１０はブロック３０３０へ進む。ブロック３０３０では、音声ポータル１０は、「Ｗｅａｔｈｅｒ Ｃｈａｎｎｅｌ［お天気チャンネル］が提供する天気へようこそ」と発話し、ブロック３０４０へ進む。ブロック３０４０では、一義的なエグジスタント特定サブシステムが実行される。
【０１１９】
ブロック３０４０の後、ブロック３０５０が実行され、そこでは、ブロック３０４０の一義的エグジスタント特定サブシステムでエグジスタントが見つかったかどうかについて決定がなされる。エグジスタントが見つからなかったならば、制御権はブロック３０３０へ戻る。エグジスタントが見つかったならば、ブロック３０６０が実行され、そこでは、見つかったエグジスタントサブシステム（図３３に関連して説明される）が実行される。
【０１２０】
次に、図３１において、ブロック３０４０（図３０）で実行された一義的エグジスタント特定サブシステムにはブロック３１１０が含まれ、そこでは、データベース１７０が、現在の縦方向ドメイン（例えば、天気、交通、映画）のための属性依存グラフから属性を提供する。属性依存グラフにより多くの属性が存在しないならば、制御権はブロック３１１５にパスされ、そこでエグジスタント検索の失敗が記録される。ブロック３１１５の後、制御権はブロック３０３０（図３０）へパスされる。ブロック３１１０（図３１）の後、ブロック３１２０が実行され、そこでは、データベース１７０によって提供される属性値セットから、属性ボキャブラリーが構築される。ブロック３１２０が実行された後、ブロック３１３０が実行され、そこでは、音声ポータル１０が、メソッドＮに従いつつ、自動音声認識技術（ＡＳＲ）を用い、属性値プロンプトに対するユーザの反応を取得する。例えば、音声ポータル１０は、例示的メソッドＮとしての郵便番号により、ユーザの所在地を要求してもよい。ユーザは、自身の郵便番号、例えば「５３０４５」、を答えることになる。
【０１２１】
ブロック３１４０では、音声認識が成功したかどうかについて決定がなされる。成功でないならば、ブロック３１３０が、代わりのメソッドＮ＋１に従いつつ、ＡＳＲ技術を用いて実行される。例えば、天気の縦方向ドメインでは、代わりのメソッドＮ＋１は、ユーザの所在地の州及び市を訊ねることであるかもしれない。好ましい実施態様では、代わりのメソッドには、リストから属性を選ぶこと、空間を区分することにより（例えば、州の決定、その後に市の名前）属性値セットを制限すること、そして属性値のスペルを調べること、が含まれる。音声認識が成功であれば、ブロック３１５０が実行され、そこでは、音声ポータル１０が、取得した属性をデータベース１７０内で検索する。ブロック３１５０が実行された後、フローチャート３２００（図３２）が実行される。
【０１２２】
次に、図３２に、一義的エグジスタント特定サブシステムを部分的に示すフローチャート３２００を示す。ブロック３１５０を実行した後（図３１）、ブロック３２１０が実行され、データベース１７０の検索においてマッチしたエグジスタントの数が決定される。製品データベースの検索で見つかったマッチの数により、とられるアクションが異なる。マッチが１件も見つからない場合、ブロック３２２０が実行され、そこでは、固有コンパウンドキーを捜すかどうかについての決定がなされる。固有コンパウンドキーは、データベース１７０内には含まれないが、インターネット上を所望の品目を探すために使用されるかもしれない１つ又はそれ以上の固有キー又は識別子がある際に、存在するかもしれない。
【０１２３】
マッチが１件見つかった場合、ブロック３２３０が実行され、そこでは、音声ポータル１０が、当該マッチが正しいエグジスタントであるかどうかを確認する。マッチの数が１件より多く、リストのための最大数より少ない場合、ブロック３２４０が実行され、そこでは、ユーザは、マッチのリストからエグジスタントを特定するように要求される。リスト中の想定される項目の最大数よりも多くのマッチが見つかった場合、ブロック３２５０が実行され、そこでは、属性が「拡張可能」であるかどうかが決定される。換言すれば、属性について、更なる情報を提供できるかどうかについて決定がなされる。更なる情報が提供できるのであれば、制御権はブロック３１１０（図３１）に戻され、そこでは、属性依存グラフから属性がもう１つ取得される。属性が拡張可能であれば、ブロック３２６０が実行され、そこでは、属性の拡張が試される。属性が拡張できるのであれば、制御権はブロック３１２０（図３１）へパスされ、そこでは、ボキャブラリー集合が構築され、ＡＳＲ技術及びメソッドを用いて属性値が得られる。属性が拡張できないのであれば、制御権はブロック３１１０（図３１）へパスされ、そこでは、属性依存グラフから属性がもう１つ取得される。属性の拡張の結果、品目リストが得られれば、制御権はブロック３２４０へパスされる。
【０１２４】
次に、ブロック３２２０において実行されるクエリに関連し、ＷＷＷの検索のために使用する固有コンパウンドキーが存在しないとの決定がなされた場合、制御権はブロック３１１０（図３１）へパスされる。固有コンパウンドキーが存在するかもしれないとの決定がなされた場合、制御権はブロック３２７０へパスされ、そこでは、ＷＷＷを検索するかどうかに関する決定がなされる。ＷＷＷが検索されないのであれば、制御権は、現行の縦方向ドメインのトップレベルであるブロック３０３０（図３０）へパスされる。ＷＷＷが検索されるのであれば、制御権はブロック３２８０へパスされる。次に、ブロック３２３０及びブロック３２４０において、正しいエグジスタントが見つかり、あるいは正しいエグジスタントがリストから見つかったならば、制御権はブロック３２２０へパスされる。正しいエグジスタントがブロック３２３０においても、またブロック３２４０においても見つからなければ、制御権はブロック３２２０へパスされ、品目を見つけるために検索することのできる固有コンパウンドキーが存在するかどうかの決定がなされる。ブロック３２８０では、ウェブルックアップが行われる。この時点で、顧客に対し、さまざまな長さのターゲットされた広告が提示されてもよい。広告については、図３６に関連して更に詳しく説明される。ブロック３２８０においてブロック３０６０が行われ、そこでは、見つかったエグジスタントサブシステムが実行される。
【０１２５】
次に、図３３において、見つかったエグジスタントサブシステムには、ブロック３３１０が含まれ、そこでは、見つかった品目の顧客データベースにログが記録される。好ましい実施態様では、顧客データベースはデータベース１７０に含まれる。ブロック３３１０の後、ブロック３３２０が実行され、そこでは、データベース１７０中の情報から、縦方向ドメインに適したプレゼンテーションのために情報が調整される。ブロック３３２０の後、ブロック３３３０が実行され、そこでは、関連する情報及びコマンドグラマーが構築される。例えば、映画の縦方向ドメインでは、ある特定の劇場で上映中の映画のリストが提示される場合、グラマーには映画の題名が含まれ、それによりユーザは特定の映画に関する更なる情報を要求することができる。
【０１２６】
ブロック３３４０では、ユーザから情報が戻される。好ましい実施態様では、許容し得るコマンドの可能なものには、更に詳しい情報を聞くコマンド、特定のソースから情報を聞くコマンド、関連情報（例えば、より安価な、よりよい）を聞くコマンド、そして、縦方向ドメインに適したアクションをとるコマンド（例えば、値段を上げる、ロケーションを変える）、が含まれる。ブロック３３４０の後、ブロック３３５０が実行され、そこでは、次のアクティビティが取得される。新しい縦方向ドメインが望まれる場合は、制御権はブロック３０２０へパスされる（図３０）。現行の縦方向ドメインのトップから新しい選択が望まれる場合は、制御権はブロック３０３０（図３０）へパスされる。新しいエグジスタントが望まれる場合は、制御権はブロック３０４０（図３０）へパスされる。
【０１２７】
再び、図３２において、ブロック３２８０か実行された後、ブロック３２９０が実行され、そこでは、データベース１７０を更新することによってウェブルックアップの結果が調整される。ブロック３２９０におけるウェブルックアップの結果の調整の際、ブロック３２９０においてスマートディレイハンドルが実行されてもよく、そこでは、広告、もしくはその他のディレイの扱い方が実行される。ブロック３２９５のスマートディレイハンドルは、顧客データベース及び広告データベースからの情報を使用する。好ましい実施態様では、顧客データベース及び広告データベースはデータベース１７０のサブセットである。代わりの実施態様では、顧客データベース及び広告データベースは、物理的に分離されたデータベースである。
【０１２８】
ここに説明されたインターネット情報への音声アクセスのためのシステム及びメソッドは、その動作において、消費者の関心の対象となっている縦方向ドメイン（例えば、映画、ショッピング）を特定し、その後でユーザの応答を、縦方向ドメインで可能なすべてのものの中から、消費者が欲する１つ又は数個のセットに「ファネル」することができる。縦方向ドメイン内におけるこのファネリングでは、ユーザに対する製品又はサービスの属性についての質問がシステム主導で行われ、これは、特定の品目へファネルするために事前に定義される「パス」に従って行われる。パスは、確かめるべき、そして事例を挙げて裏づけすべき製品に関する制限のオーダリングの観点から定義される。
【０１２９】
図３４に、音声ポータル１０による、ユーザ応答のファネリング、及びユーザ応答についての非常に正確な音声認識率の達成を可能とするファネリングプロセスのフロー図３４００を示す。ステップ３４１０において、ユーザは音声ポータル１０を呼び出す。ステップ３４１０の後、ステップ３４１５が実行され、そこでは、上述の適用可能な様々なメソッドを用いて発信者を特定する。ステップ３４１５の後、ステップ３４２０が実行され、そこでは、ユーザが関心の対象である縦方向ドメインを選択する。その後、ステップ３４２５が実行され、そこでは、関心の対象として選ばれた縦方向ドメインに特有の属性ファネルが実行される。ステップ３４２５の後、ステップ３４３０が実行され、そこでは、音声ポータル１０により、関心の対象である縦方向ドメインにおいてユーザの好み設定が存在するかどうかが決定される。ユーザの好み設定が存在し、それをユーザがオーバーライドしたくないならば、制御権はステップ３４６０へパスされ、そこでは、品目又はサービスが、ユーザの好み設定に基づいて見つかったものとして指示される。
【０１３０】
好み設定が存在せず、あるいはユーザが自身の好み設定をオーバーライドするならば、ステップ３４３５が実行され、そこでは、属性ボキャブラリー集合が構築される。好都合なことに、ボキャブラリー集合により、音声ポータル１０は、予想される応答を限定数保有することができ、関心の対象である縦方向ドメインにおけるこの時点でのユーザ応答の音声認識に使用される。定義されたボキャブラリー集合により、音声ポータル１０は、従来の音声認識技術を高い認識率で有利に達成する。例えば、ユーザがメジャーリーグ野球（ＭＬＢ）チームを選択し、ＭＬＢチームに関する予想されるリクエストのボキャブラリー集合が構築された後であるならば、「ブリューアーズ」というチームは認識し易いであろう。このようなボキャブラリー集合は、同一の情報に関する様々に異なるタイプのユーザ入力を含み得る。例えば、ＭＬＢチームの例では、ボキャブラリー集合は、ＭＬＢチームマスコットだけでなく、ＭＬＢチームに関連するすべての都市又は州の名前を含むかもしれない。したがって、「ミルウォーキー」と「ブリューアーズ」は、共に、ＭＬＢチームのボキャブラリー集合の一部分を形成するであろう。
【０１３１】
適切なボキャブラリー集合が構築されると、ステップ３４４０が実行され、そこでは、音声ポータル１０が、属性についての問い合わせを行う。例えば、「あなたがお聞きになりたいメジャーリーグ野球のチームはどこですか？」、のような問い合わせである。ステップ３４４０の後、ステップ３４４５が実行され、そこでは、属性が特定される。属性が特定されない場合、属性特定のための代わりの手順を行うステップ３４４７を実行してもよい。ステップ３４５０においては、音声ポータル１０は、「最終状態」に達したかどうか、もしくは品目又はサービスが見つかったかどうかが決定される。最終状態に達していないならば、ステップ３４５５が実行され、そこでは、次の属性がアクセスされ、制御権はステップ３４３０へ戻される。ここに示される野球の例では、チーム名のみで、最終状態には達していない。最近の試合結果、選手統計、チームの順位等の「より狭い」属性、又は、その他の関連情報について要求されなければならない。ステップ３４６０が実行されると、ステップ３４６５が実行され、そこでは、見つかった品目又はサービスがユーザへ報告される。
【０１３２】
例示的実施態様では、ユーザは次のような方法で品目を選択する。ユーザは、まず、関心の対象となるドメインを特定する（例えば、電子的商取引、交通情報、お天気情報、映画、等々）。ユーザは、次に、品目属性を特定することによって品目を選択する（例えば、書籍、玩具、交通情報のほしいルート、お天気情報のほしい都市、等々）。ユーザは、次に、特定された品目に関するものであって、品目のドメインに適切な詳細情報を入手する（例えば、製品、交通、天気、映画、等々）。例えば、関心の対象である電子商取引ドメインでは、価格、送料、及び在庫状況を含む情報が入手できる。関心の対象である映画ドメインでは、監督、プロデューサー、そして配役を知ることができる。関心の対象であるオークションドメインでは、現在の指値を知ることができる。
【０１３３】
好都合なことに、ユーザは、地方を特定する複数の方法（例えば、郵便番号、都市名、ボストンの北部・南部等の都市エリア）により、地方の情報（例えば、特定される製品の最も近くのベンダー、映画を上映する最も近くの劇場）を要求してもよい。例示的実施態様では、郵便番号に基づく位置特定戦略が用いられ、そこでは、都市郊外の名称が問い合わされ、都市又は場合によっては州に戻り、そして再びズームインされる。例示的実施態様では、ユーザは、自ら要求することにより、情報が最後に更新された日付及び時間を知ることができる。ユーザに提示される情報はすべて、当該ドメインに適切な通貨によるものであることが好ましい。ユーザは、情報ソース（ＸＸＸＸＸ提供）に関し、「純粋」ソース情報又は唯一のソースからの情報かを知ることができる。好ましい実施態様では、選択地点のそれぞれにおいて、「ヘルプ」又は「インストラクション」オプションを使用することができる。
【０１３４】
ユーザは、ドメインに適切な場合、品目属性に基づく品目の比較を要求してもよい。ユーザは、ドメインに適切な場合、「よりよい」、「より安い」、及び「関連する」品目の特定を要求してもよい。関心の対象であるドメインに適切な場合、ユーザにより多数のユーザ定義リストに品目を明示的に記録できれば好都合である。ユーザは自身のリストで品目の見直しを行うことができる。ユーザは、自身のリスト上の品目について、（ドメインに適切な）情報の変更を知らせる電話又は電子メールを要求してもよい。
【０１３５】
図３５に、音声ポータル１０を用いたトランザクション実行の例示的プロセスのフロー図３５００を示す。ステップ３５１０において、ユーザは音声ポータル１０にアクセスする（電話又はコール）。ステップ３５１０の後、ステップ３５１５が実行され、そこでは、ユーザが望む品目又はサービスを特定するためのファネリングプロセスが実行される。そのようなファネリングプロセスでは、フロー図３４００に示され、図３４に関連して説明される動作が実行される。
【０１３６】
ステップ３５１５の後、ステップ３５２０が実行され、そこでは、音声ポータル１０が、ユーザに、特定された品目又はサービスに関連する望みのトランザクションを特定するように要求する。ステップ３５２０が実行された後、ステップ３５２５が実行され、そこでは、音声ポータル１０が、特定されたトランザクションを実行するための適切な音声ポータルルールを特定する。ステップ３５２５の後、ステップ３５３０が実行され、そこでは、ルールが実行され、特定されたトランザクションが実施される。トランザクションには、品目又はサービスの購入、オークションでの入札、その他インターネット上において可能なトランザクションが含まれる。ステップ３５３０の後、ステップ３５３５が実行され、そこでは、音声ポータル１０がトランザクションの結果を記録する。結果はデータベース１７０に記録されることが好ましい。ステップ３５３５の後、ステップ３５４０が実行され、そこでは、トランザクションがユーザに報告される。
【０１３７】
異なるドメインにおいては、異なるトランザクション（例えば、入札、監視、購入、追跡）が適切である。例えば、関心の対象である電子商取引ドメインでは、ユーザは、選択されたベンダーから特定された製品を注文してもよい。さらに、ユーザは、後になってから、購入のため品目をショッピングカートへ追加してもよい。注文の際、ユーザは、（ユーザプロファイルから、又は手作業で）支払いを行うクレジットカード及びショッピングアドレスを特定してもよい。ユーザは、先に注文した製品のステータス情報についても要求してもよい。他の例として、関心の対象であるオークションの縦方向ドメインでは、ユーザは現在の入札値を上げてもよく、あるいは新規オークションに入札してもよい。
【０１３８】
好都合なことに、音声ポータル１０を用いたトランザクションの実行プロセスは、ユーザによるコンピュータ上でのいかなる手作業による動作を要求しない。ユーザは、品目の購入、入札、その他のインターネットトランザクションを行えるが、その際、マウスによるクリック、コンピュータキーボードからのキー入力、その他コンピュータインターフェースにおける手作業による動作（例えば、マウスクリック、キーボード入力）は必要ではない。したがって、図３５に関連して説明されるプロセスでは、「無クリック」インターネットトランザクションプロセスが可能である。ユーザは電話のタッチパッドを使用してもよく、その場合でも、「無クリック」インターネットトランザクションが可能である。
【０１３９】
図３６Ａに、音声ポータル１０を用いた広告の例示的プロセスのフロー図３６００Ａを示す。好都合なことに、広告サブシステム１２０には、特定のユーザに対し、どの広告を再生するかの決定方法が含まれる。一般に、この方法には、ユーザの人口統計、居住地の人口統計及び関心の対象である現在の縦方向ドメインなど、状況に基づく選択制約事項の設定が含まれる。選択制約事項が設定された後、メソッドは、制約に基づき広告データベースに問い合わせを行い、可能な広告のリストを取り出す。可能な広告のリストは、各広告について、セールス基準に基づいて再整理される。再整理されたリストから広告が選ばれ、ユーザに提示される。
【０１４０】
フロー図３６００Ａでは、ステップ３６１０Ａにおいて、音声ポータル１０の広告サブシステム１２０により、ユーザに提示すべき広告のための選択制約事項が設定される。ある実施態様では、選択制約事項はユーザ中心情報と広告中心情報とに基づくものであり、前者には、ユーザの人口統計、居住地の人口統計、及び関心の対象である現在選択中の縦方向ドメイン（存在する場合）が含まれ、後者には、広告セールス基準、反復の不足及びその他の広告有効ファクターが含まれる。これらの制約事項又は基準は、導入的スポンサー広告、縦方向スポンサー広告、商業的広告など、様々に異なるタイプの広告からの選択において用いられる。ステップ３５１０Ａの後、ステップ３６１５Ａが実行され、そこでは、ステップ３６１０Ａにおいて選択された制約事項に基づく可能な広告のリストを得るために、データベース１７０が照会される。
【０１４１】
ステップ３６１５Ａの後、ステップ３６２０Ａが実行され、そこでは、可能な広告のリストが、セールス基準ファクターに基づいて再整理される。ある実施態様では、セールス基準ファクターは、次を決定するために用いられる：（１）この広告の広告提示率を達成されているか？（２）この広告のターゲット提示最小値は達成されたか？好都合なことには、セールス基準は、広告の各顧客が提示のための要求を満足させることを保証するために使用される。ある実施態様では、率を計算し、どの広告を最初に提示するかの優先順位が付けられる。
【０１４２】
以下に、広告をどのように整理するかの決定ファクターとして、率を使用する例を示す。広告Ｘは、コンタクトにおいて、１００，０００回の提示が必要である。音声ポータル１０は、広告Ｘを既に７，０００回提示している。コンタクトの開始日は５月１０日で、終了日は６月７日である。現在の日付を５月１５日と仮定する。この場合、例示的率は次のように決定される。
【０１４３】
・コンタクト開始からの日数＝５。
【０１４４】
・コンタクトの長さ＝２７日間。
【０１４５】
・広告提示の必要のある日数＝２２。
【０１４６】
・再生済み広告のパーセント＝７，０００／１００，０００〜＝７％。
【０１４７】
・既に再生済み日数のパーセント＝５／２７〜＝１８．５％。
【０１４８】
こうして、例示的最終率は次式から求められる。
【０１４９】
（既に再生済み日数の％−再生済み広告の％）／コンタクトの残存日数。
【０１５０】
好都合なことに、この率は直ちに再生すべき広告（低分母は高い値になる）に相当し、既に再生済みの広告との不一致は、低い率によって押し戻される。
【０１５１】
可能な広告が再整理されるステップ３６２０Ａの後、ステップ３６２５Ａが実行され、そこでは、広告が選ばれる。ある実施態様では、可能な広告のリストにおいて得ることのできる最も高い率に基づいて、広告が選択される。ステップ３６２５Ａの後、提示されるべき広告のタイプによって、異なるアクションがとられる。ステップ３６３０Ａでは、提示できる広告がなく、更に広告のタイプが導入的スポンサー広告であるならば、ステップ３６３５Ａにおいて例外が生成される。そうでないならば、ステップ３６４０Ａが実行され、そこでは、広告があるかどうかについての決定がなされる。広告があるならば、ステップ３６４５Ａが実行され、そこでは、広告が再生される。広告がないならば、ステップ３６４０Ａが実行され、そこでは、選択制約事項がリセットされ、制御権がステップ３６２０Ａへ戻される。
【０１５２】
このような状況において、広告の各タイプのプロセスステップにおいて違いが存在し、そして、ここで言う各タイプとは、導入的スポンサー広告、縦方向スポンサー広告、及び商業的広告である。以下は、導入的スポンサー広告を選択するための例示的プロセスである。
【０１５３】
１．導入的スポンサー広告タイプのロケーションに基づいて選択制約事項をセットする（縦方向は用いられない。なぜならば、縦方向は適用されないからである）。
【０１５４】
２．制約事項に基づいてデータベースを照会し、結果を、再生する可能な広告のリストへ変換する。
【０１５５】
３．セールス基準に基づきリストを記録する。
【０１５６】
４．最も率の高いリストから広告を選ぶ。データベースに広告があるはずであり、例外を生成する。
【０１５７】
以下は、縦方向スポンサー広告を選択するための例示的プロセスである。
【０１５８】
１．ユーザの人口統計、居住地の人口統計、及び縦方向スポンサー広告タイプの縦方向タイプに基づいて制約事項をセットする。
【０１５９】
２．制約事項に基づいてデータベースを照会し、結果を再生する可能な広告のリストへ変換する。
【０１６０】
３．セールス基準に基づきリストを記録する。
【０１６１】
４．存在する場合、最も率の高いリストから広告を選び、ユーザインターフェースへ戻る。
【０１６２】
５．存在しない場合、縦方向タイプのみに基づいて制約事項をリセットし、縦方向スポンサーシップをＱｕａｃｋプロモーションのみにセットする。
【０１６３】
６．セールス基準に基づいてリストを記録する。
【０１６４】
７．存在する場合、最も率の高いリストから広告を選び、ユーザインターフェースへ戻る。
【０１６５】
８．ユーザがリストからの広告をすべて聞いたならば、ユーザに対して最後に再生された広告に戻る。何らかの理由でリストが空で広告がない場合、例外を生成する。
【０１６６】
以下は、商業的広告を選択するための例示的プロセスである。
【０１６７】
１．居住地の人口統計、顧客の人口統計及び商業的広告タイプの縦方向タイプに基づいて選択制約事項をセットする。
【０１６８】
２．これらの制約事項に基づいてデータベースを照会し、結果を再生する可能な広告のリストへ変換する。
【０１６９】
３．セールス基準に基づきリストを記録する。
【０１７０】
４．存在する場合、最も率の高いリストから広告を選び、ユーザインターフェースへ戻る。
【０１７１】
５．存在しない場合、縦方向タイプのみに基づいて選択制約事項をリセットし、コマーシャルのタイプを、Ｑｕａｃｋ（すなわち、音声ポータルシステム）のコマーシャルか、有償のコマーシャル（入力されたタイプとは無関係）にセットする。
【０１７２】
６．セールス基準に基づいてリストを記録する。
【０１７３】
７．存在する場合、最も高い率のリストから広告を選び、ユーザインターフェースへ戻る。
【０１７４】
８．ユーザがリストからの広告をすべて聞いたならば、最後の広告へ戻る。何らかの理由でリストが空で広告がない場合、例外を生成する。
【０１７５】
次に、図３６Ｂでは、フロー図３６００Ｂに、音声ポータル１０を用いた広告の第２の例示的プロセスを示す。ステップ３６１０Ｂにおいて、ユーザは音声ポータル１０にアクセスする（電話又はコール）。ステップ３６１０Ｂの後、ステップ３６１５Ｂが実行され、そこでは、ユーザを特定するためにユーザルックアップが実行される。発信人識別は様々なメソッドで行ってよく、その中のいくつかは図２及び図３０に関連して説明される。ステップ３６１５Ｂの後、ステップ３６２０Ｂにおいて、ユーザが音声ポータル１０にとって既知であるかどうかについて決定がなされる。ユーザが既知でないならば、ステップ３６２５Ｂが実行され、そこでは、ユーザのためにデフォルトのプロファイルが使用される。例示的実施態様では、デフォルトプロファイルには、ある広告についてのユーザの制約事項又は制限事項は含まれない。デフォルトプロファイルは、発信について知られるあるパラメータに照準を合わせることができ、同パラメータとは、例えば、ユーザのエリアコード、発信日の時刻、発信週の日、等々、である。ユーザが既知か、あるいはステップ３６２５Ｂが実行された後であれば、ステップ３６３０Ｂが実行され、そこでは、広告サブシステム１２０が、現在のユーザに特定のユーザ制約事項を含むインターフェースタイプ（例えば、音声、ＷＡＰ、ＷＷＷ）に基づいて広告の集合「Ｓ」を生成する。
【０１７６】
現行の動作コンテキスト（例えば、特定のユーザ、関心の対象である縦方向ドメイン）により、ステップ３６３５Ｂにおいて、広告サブシステム１２０が、広告コンテキストに基づき、広告集合Ｓのための重み付けを生成する。ステップ３６３５Ｂの後、ステップ３６４０Ｂが実行され、ユーザが最も求めるものが何であるかを正確に知るために、コンテキストが十分であるかどうかが決定される。コンテキストが十分でないならば、ステップ３６４５Ｂが実行され、そこでは、得られた部分的コンテキストに基づいて広告が選ばれる。コンテキストが十分であるならば、ステップ３６５０Ｂが実行され、そこでは、最も適する広告が再生される。
【０１７７】
好都合なことに、広告サブシステム１２０は、すべての発信者に対して、最初の一般的広告又はスポンサーシップメッセージを提供する。広告サブシステム１２０はまた、ユーザに対し、ドメインにふさわしい実用性機能に基づいて選ばれる、目標とされる音声広告も提供する。例示的実施態様では、実用的機能は次のものに関連する：広告される製品又はサービスの入手可能性、現行の品目の関連性（例えば、ＤＶＤはテレビに関連する）、ユーザに対する妥当性（例えば、人口統計に照らして）、広告者にとってのユーザの望ましさ、そして、サービスプロバイダにとっての価値（例えば、コスト／収益に照らして）。好都合なことに、広告サブシステム１２０は、ユーザに対し、ある時間フレーム内に、所定の数の広告を提供できる能力を有する。さらに、広告サブシステム１２０は、ワイヤレスアプリケーションプロトコル（ＷＡＰ）、ＷＷＷ、音声インターフェースなど、異なるプラットフォームにわたって広告を提供できる能力を有する。
【０１７８】
例えば、音声インターフェースプラットフォームでは、最初の１分以内に、スポンサー広告１つ及び目標とされる広告１つがユーザに送られる。各追加４０秒以内に、第２の目標とされた広告が送られる。ある実施態様では、スポンサーシップメッセージは３〜５秒で処理を行い、その後、目標とされる広告は１０〜２０秒を要する。
【０１７９】
この構造の実現は、導入的スポンサー広告は、システムに入った時点で提示されるという事実に基づくものである。ユーザが縦方向に入る度毎に、ユーザは「縦方向スポンサーシップ」で促される。ユーザが要求データを受け取ろうとする際に、コマーシャルがフルでユーザに提示される。好都合なことに、このモデルは、先にリストにされたスケジュールを、ユーザは情報入手前に４０秒間検索に費やすであろうものとして見積もる。
【０１８０】
広告コンテキストでは、広告を提示する際により詳細な情報を送るために、「スピークスルー」が要求される。好都合なことに、スピークスルーは、音声インターフェースだけでなく、ＷＡＰ及びＷＷＷの双方についても適用される。更なる広告を見つけるためのバナーのクリックがＷＷＷにおけるスピークスルーに対応する一方で、ＷＡＰに対しては、音声及びテキストをスピークスルーとして考えることができる。音声対話におけるスピークスルーのある実施態様は、顧客をウェブサイトアドレス又は電話番号に向けさせることである。代わりの実施態様では、スピークスルーが電子メールアドレス又は顧客の電話番号を収集して広告者へ送り、顧客に適切な情報をより多く送らせるようにする。ＷＷＷインターフェースでは、スピークスルーは、顧客情報を管理し、チェックするために、外部ソースを含んでもよい。広告サブシステム１２０は、ドメイン（例えば、ＷＷＷインターフェース）にふさわしい実用的機能に基づいて選ばれた、目標とされる「バナー」広告をユーザに提供してもよい。
【０１８１】
広告サブシステム１２０の広告送付の管理は、いくつかのファクターの組合せに基づいている。例示的実施態様では、広告は３つの場所の内の１つに送られる。まず、ユーザが新しいセッションを始めるためにシステムへ入る準備をしているときに、広告を送ってもよい。このスポンサーシップメッセージは、ユーザインターフェース１１０の音声、又は「システム音声」で流され、複数の他の広告スポンサーの間で循環させるとよい。例えば、スポンサーメッセージは、「Ｑｕａｃｋは、ウェブの通貨であるビザの提供でお送りします」、又は「Ｑｕａｃｋは、携帯電話サービスの確かな未来を築くＳｐｒｉｎｔＰＣＳの提供でお送りします」、となるかもしれない。
【０１８２】
第２に、ユーザが、映画、交通、天気など、システムのある縦方向にアクセスする直前に、もう１つのスポンサー広告（「縦方向スポンサーシップ広告」）が送られてもよい。例えば、そのような広告は、「映画情報に関する世界のオーソリティーであるＩＭＤＢの提供です」、及び「名作セレクションのためのボストンにおける唯一の選択、ＬＣＥ Ｓｏｎｙ Ｍｅｔｒｅｏｎ」、となるかもしれない。
【０１８３】
第３に、ユーザが改良された要求を受け取る直前に、広告が送られてもよい。このタイプの広告は、「コマーシャル」と定義される。このような広告は時宜を得たものであるが（すなわち、選ばれた時点に送られる）、２分毎というふうに、非常に頻繁に送られる。好都合なことに、システム音声は、ユーザのために、有用な価値の付加された状態を指摘する。例えば、ユーザがある特定の劇場における映画を選択している場合、付近のレストランが示唆される。ここでは、非スピークスルー広告も可能ではあるが、スピークスルー広告の使用が好ましい。広告のコンテンツそのものの長さは、好ましくは、約７秒である。スピークスルー広告は、最高の品質（すなわち、プロフェッショナルによる製作）であることが好ましく、約１５〜２０秒の長さであることが好ましい。例えば、ユーザがＬＣＥ Ｓｏｎｙ Ｍｅｔｒｅｏｎにおいて映画としてＡｍｅｒｉｃａｎ Ｂｅａｕｔｙを選択した場合、システム音声は次のように案内する。「Ｓｏｎｙ Ｍｅｔｒｅｏｎのリストを検索中です・・・Ｓｏｎｙ Ｍｅｔｒｅｏｎから５分の距離にあるボストン随一のイタリアンレストランである『Ｔｏｎｙ’ｓ Ｍａｔｒｉｃｉａｎａ』についてお知りになりたいならば、『Ｔｏｎｙ’ｓ』と言うか、又はあなたのリストのためにそのまましばらくお待ち下さい」。そうして、ユーザは、自動的に予約を得るようにしてもよい。目標とされる広告のために、その他の関係属性を使用してもよい。好都合なことに、これらの異なるスポットにおいて広告が送られるのは、縦方向に特定された要求は、広告を送るのに要するのと同じ時間を費やす、という現在の仮定によるものである。
【０１８４】
これらの問題と共に、ユーザはどの広告を自身宛に送らせるかについての決定がなされる。この決定に組み込まれるファクターに含まれるものは、コールの長さ、どのタイプの縦方向コンテンツが要求されているか、コンテンツとユーザプロファイル（及び／又は所在地）（すなわち、レストラン広告は顧客にとってローカルであるべき）の組合せ、収益ポテンシャル、特定情報を要求している発信者、そして、ユーザは既に広告を聞いたことがあるか、などである。例示的実施態様では、次のようなファクターに基づいて広告が循環される：広告が最後に再生されたのはいつか？現在のコール以前に、ユーザが最後に広告を聞いたのはいつか？現在のコールで、ユーザは既に広告を聞いたか？この広告について、送付レートは達成されているか？この広告について、目標とされる送付最小値は達成されたか？
【０１８５】
好都合なことに、広告は、その提示が特定の顧客に適切であり、請求レートに従って追跡されるような方法で送られる。したがって、広告は何回再生されたか、そして個人のユーザは何回広告を聞いたか、というような各広告を管理するための基本データが収集される。
【０１８６】
加えて、このような基本データがあるとして、次のようなより複雑なクエリが可能である。例えば、クエリには、広告を聞いたことのあるすべてのユーザのレポートを作成する機能が含まれ、それ以外にも次のような定義された様々なグルーピングについてレポート作成機能を有する：氏名、人口統計情報、所在地、及び関連情報（ユーザは他に何を要求しているか）。クエリには、スピークスルー情報を要求したすべてのユーザのレポートを作成する機能も含まれる。
【０１８７】
割り込み機能（すなわち、再生中の広告の停止）は、音声ポータル１０におけるその他の動作モードでは可能であるが、広告提示中は同機能を削除することができる。広告者にとっては、広告に関して取得されたデータが音声ポータル１０を通じて提供されることが保証されねばならず、そのような意味において割り込みを予防する機能は重要である。ある実施態様では、この広告データの収集は、第三者としての聴取者が行う。
【０１８８】
広告サブシステム１２０は、ユーザに出したすべての広告の記録を保管し、これには、成功した（すなわち、完了した）送付、及び不成功な（すなわち、未完了な）送付が含まれる。この記録は、データベース１７０に保存されることが好ましい。好都合なことに、広告は、関心の対象である縦方向ドメインによって、又は発信者所在地もしくはユーザによって、又はユーザの好み設定によって、又はユーザの過去の興味によって、又は広告者の関心及びユーザが収集した情報の組合せによって、目標とされる。
【０１８９】
好都合なことに、コンテキストに敏感な情報を使用し、ユーザへの広告を厳密に狙うことができる。音声ポータル１０にターゲットを定めるコンテキストに敏感な広告は、広告コマーシャルを、ほぼ厳密に、ユーザが受け取る情報に関係付ける。この機能を正しくするために、広告を再生する直前に、適切なポインタを選択アルゴリズム内へパスされる。ある実施態様では、縦方向タイプはコンテキストポインタである。
【０１９０】
他の実施態様では、エグジスタントは、より具体的なターゲットを可能とするコンテキストポインタである。このコンテキストポインタは、その属性基準を、マーケットリサーチ基準にマッチさせ、あるカテゴリにおける重み付けを決定する。これらのカテゴリ重み付けは、最初のリスト中の広告のセールス基準と共に、その中から最善の広告を選択するコンテキスト重み付けのオーダリングを定義する。この最初のリストは、人口統計及び縦方向タイプから作成され、コンテキストウェーティングのベースを形成する。数学的表記を導入し、この問題をアルゴリズムに一般化し、以降の例で説明する。
【０１９１】
まず、関連するパラメータに対して変数を定義する。アルゴリズム内へパスされるエグジスタントの属性のリストを集合｛ｅ_１， ｅ_２， ．．．， ｅ_ｍ｝によって定義する。ここで、ｍはエグジスタント内の属性の番号である。例えば、映画エグジスタントについては、サンプル属性は、ジャンル、所在地、及び上映時刻である。広告に関連する可能なカテゴリのリストは、集合｛Ｃ_１， Ｃ_２， ．．．， Ｃ_ｎ｝によって定義する。ここで、ｎはカテゴリの総数である。システム内のサンプルカテゴリは、家族、レストラン、夜の遊び、映画、及びエンタテイメントであろう。各カテゴリＣ_ｉについて、コンテキストカテゴリ重み付けをＷ_ｉとする。ここでｉ∈｛１， ．．．， ｎ｝である。コンテキストカテゴリ重み付けの目的は、以下に説明するように、コンテキストの強さを広告のカテゴリ重み付けとの比較において決定することである。
【０１９２】
すべてのエグジスタントのためのマーケットリサーチ基準は、Ｐ ＝ ｛ｐ_１， ｐ_２， ．．．， ｐ_ｔ｝によって表される。ここで、ｔはデータベース内のすべての基準の合計である。各基準ｐ_ｊは関連する重み付けｗ_ｉを有する。ここで、ｊ∈｛１， ．．．， ｔ｝である。そして、各属性ｅ_ｉは、すべてのｉ、ｊについて、すべてのｐ_ｊを満足するよう試みる。ここで、ｉ∈｛１， ．．．， ｍ｝、ｉ∈｛１， ．．．， ｔ｝である。したがって、ｅ_ｉがｐ_ｊを満足し、そしてｐ_ｊがカテゴリＣ_ｋに属するならば、Ｗ_ｋ ＝ Ｗ_ｋ ＋ ｗ_ｊである。ここで、ｉ∈｛１， ．．．， ｍ｝、ｊ∈｛１， ．．．， ｔ｝、ｋ∈｛１， ．．．， ｎ｝である。この反復法は、上述の各カテゴリのコンテキスト重み付けを定義するのに使用される。
【０１９３】
各カテゴリのための全コンテキスト重み付け、Ｗ_ｋ、が定義されると、それに関連する強さレシオ、Ｒ_ｋ、を計算しなければならない。カテゴリの強さレシオは、エグジスタントのコンテキストが、広告の選択において価値が認められだけの十分な強さであるかどうかを決定するために使用される。例えば、家族カテゴリがＰにおいて多数の基準を有する場合、エグジスタントのコンテキストに対応する重み付けが許容し得るプロポーションの範囲にあることを保証する必要がある。したがって、Ｒ_ｋ ＝ Ｗ_ｋ／Ｔ_ｋである。ここで、Ｔ_ｋは、カテゴリｋに関連するＰ内のすべての基準の全重み付けである。
【０１９４】
人口統計クエリによって生成された広告リストは、集合Ａ ＝ ｛Ａ_１， Ａ_２， ．．．， Ａ_ｒ｝によって定義される。ここで、ｒはリスト中の広告の総数である。各広告Ａ_ｉは、自身のカテゴリ重み付けｘ_ｋを有し、ここで、ｉ∈｛１， ．．．， ｒ｝及びｋ∈｛１， ．．．， ｎ｝であり、同カテゴリ重み付けは、アルゴリズムの対応するコンテキストカテゴリ重み付けレシオＲ_ｋと関連して使用される。
【０１９５】
したがって、データベース上で人口統計及び広告タイプをフィルターすることによって広告の最初のリストＡが生成されると、アルゴリズム中のステップは次のようになる。
【０１９６】
１．次のように、各カテゴリＣ_ｋについて、カテゴリ重み付けＷ_ｋを設定する。
【０１９７】
・各Ｗ_ｋ ＝ ０を初期化する。ここでｋ∈｛１， ．．．， ｎ｝である。
【０１９８】
・各ｉ∈｛１， ．．．， ｍ｝及び各ｊ∈｛１， ．．．， ｔ｝について、現行のエグジスタント｛ｅ_１， ｅ_２， ．．．， ｅ_ｍ｝の属性に基づき、ｅ_ｉがｐ_ｊを満足し、ｐ_ｊがカテゴリＣ_ｋに関連するならば、Ｗ_ｋ ＝ Ｗ_ｋ ＋ ｗ_ｊである。ここで、ｋ∈｛１， ．．．， ｎ｝である。
【０１９９】
２．次に、エグジスタントの属性とは独立して、カテゴリの全重み付けをタブュレートする。これらの全重み付けから、各カテゴリのコンテキストレシオを確立する。
【０２００】
・各ｋ∈｛１， ．．．， ｎ｝及び各ｊ∈｛１， ．．．， ｔ｝について、ｐ_ｊがカテゴリＣ_ｋに関連するならば、Ｔ_ｋ ＝ Ｔ_ｋ ＋ ｗ_ｊである。カテゴリコンテキストレシオをＲ_ｋ ＝ Ｗ_ｋ／Ｔ_ｋに設定する。
【０２０１】
３．各カテゴリｋについて、各Ｒｋを各広告Ａ_ｉのカテゴリ重み付けｘ_ｋで乗じ、その後、総計を広告Ｓ_ｉのセールス基準レシオで乗じ、コンテキスト合計Ｇ_ｉを得る
【０２０２】
・各ｉ∈｛１， ．．．， ｒ｝について、Ｇ_ｉを計算する。ここで、Ｇ_ｉ ＝ Ｓ_ｉ（Ｒ_１ｘ_１ ＋ ．．． ＋ Ｒ_ｎｘ_ｎ｝である。
【０２０３】
４．広告Ａ_ｉを選択する。ここで、ｉはｍａｘ（Ｇ_ｉ）， ｉ∈｛１， ．．．， ｒ｝によって定義される。
【０２０４】
上記アルゴリズムは、簡単な例によって示すことができる。ユーザが、関心の対象である映画ドメインにいるときに、音声ポータル１０のサービスを使用する例を考える。縦方向スポンサー広告が再生され、ユーザは、まさに映画上映に関する情報を受け取ろうとする。そして、コンテキストとして、選択には上映されるエグジスタントへ向くポインタが含まれ、説明の都合上これを「Ｍｉｓｓｉｏｎ ｔｏ Ｍａｒｓ」とする。映画上映エグジスタントの属性のいくつかは、鑑賞制限（例えば、Ｒ）、ジャンル（例えば、スリラー）、そして上映時刻（例えば、午後４時００分）であり、これらは｛ｅ_１， ｅ_２， ｅ_３｝によって表される。そして、要素Ｐ ＝ ｛ｐ_１， ｐ_２， ．．．， ｐ_ｔ｝を含むコンテキスト基準のマッチングリストが必要となる。基準のサンプルリストはデータベース中で次のように表すことができる。
【０２０５】
【表１】

【０２０６】
この表から、カテゴリは、Ｃ＝｛エンタテイメント、ファミリー、夜の遊び、ティーン、アダルト｝で、ｋ＝５であることが判る。したがって、ステップ１から、Ｗ_１＝１０、Ｗ_２＝０、Ｗ_３＝５０、Ｗ_４＝８０、そしてＷ_５＝０、である。ステップ２からは、Ｒ１＝１、Ｒ２＝０、Ｒ３＝１、Ｒ４＝０．４、そしてＲ５＝０、となる（Ｐは８要素のみを有すると仮定、ただし実際はこれよりも多く、２００要素又はそれ以上である）。ここで、広告リストＡが３つの広告を有すると仮定する。広告の５つのカテゴリのウェーティングを次のように仮定する。
【０２０７】
【表２】

【０２０８】
すると、これらのウェーティング｛ｘ_１、ｘ_２、ｘ_３、ｘ_４、ｘ_５｝から、次のように、各広告Ａ_ｉについて、Ｇ_ｉの値を計算することができる。ここで、ｉ∈｛１、２、３｝である。
【０２０９】
Ｇ_ｉ ＝ Ｓ_ｉ（Ｒ_１ｘ_１ ＋ ．．． ＋ Ｒ_ｎｘ_ｎ｝
Ｇ_１ ＝ ０．８（（１）（０．９）＋０＋（１）（０．７）＋（０．４）（０．９）＋０） ＝ １．５６８
Ｇ_２ ＝ １．１（（１）（０．９）＋０＋（１）（０．９）＋（０．４）（０．９）＋０） ＝ ２．３７６
Ｇ_３ ＝ １．０（（１）（０．９）＋０＋（１）（０．７）＋（０．４）（０．９）＋０） ＝ １．９６
【０２１０】
したがって、コンテキスト及びセールスレシオの決定から、「Ｍｉｓｓｉｏｎ ｔｏ Ｍａｒｓ」の広告が最も適切である。このアルゴリズムでは、取り出される情報に対する適切性に基づいて異なるカテゴリのコンテキストが留意される。また同アルゴリズムは、セールスのために再生される必要のある広告が留意され、オーダリングへファクターされると言う事実をも取りまとめる。上記の例は、Ｐの広告、カテゴリ及び基準の短いリストの場合であった。このアルゴリズムは、更に多くのカテゴリ及び基準が存在する場合を意図している。
【０２１１】
図３７から図４３に、ユーザと音声ポータル１０との間の対話の例示的ダイアログマップを示す。図３７から図４３に関連して説明されるダイアログマップは、説明目的のためだけのものである。これらの図に示される関心の対象である縦方向ドメインは映画、天気、交通、株及びスポーツのみであるが、このようなダイアログマップに（そして、音声ポータル１０とユーザとの対話に）、これら以外の関心の対象である縦方向ドメインも含まれ得ることは明らかであり、特に、図４から図６に関連して説明されたデータ構造モデル３００、４００及び４５０に起因する拡張及び適合機能を考慮した場合はなおさらである。さらに、ユーザと音声ポータル１０との間の様々な対話を表す具体的なブロックは、例示のためだけのものである。関心の対象である可能性のある多数の縦方向ドメインのそれぞれについて、様々な対話が可能である。
【０２１２】
図３７に、ダイアログマップ３７００を示し、そこでは、ユーザにより音声ポータル１０へ電話が発信された後、歓迎を示すブロック３７１０が実行される。ブロック３７１０の後、ブロック３７２０が実行され、そこでは、サインインの手続きが行われる（図３８に関連して詳しく説明される）。ブロック３７２０のサインイン手続きの後、ユーザは、ブロック３７３０及びブロック３７４０において音声ポータル１０のサービスのイントロダクションを聞くか、あるいは、直接ランウェイ情報へ向い、ブロック３７５０において関心の対象である可能な縦方向ドメインのイントロダクションを聞くか、を選択することができる。具体的には、ブロック３７３０では、サービスプロバイダに関する紹介情報が提供される。ブロック３７５０では、サービスがどのように機能するかについての紹介情報が提供される。ブロック３７５０では、音声ポータル１０が、ユーザに対し、「ランウェイ」（例えば、映画、天気、交通、株、スポーツ）から関心の対象である縦方向ドメインを選択するよう要求する。
【０２１３】
ユーザが、関心の対象である映画ドメインを選択すると、ブロック３７６０が実行され、そこでは、映画サブシステムが実行され（図３９に関連して更に詳しく説明される）、ユーザは、映画リスト、劇場、レビューなどの映画の情報及びトランザクションへのアクセスを得る。ユーザが、関心の対象である天気ドメインを選択すると、ブロック３７７０が実行され、そこでは、天気サブシステムが実行され（図４０に関連して更に詳しく説明される）、ユーザは、好みのロケーション又は任意のロケーションにおける今日の天気又は以降何日間かの天気などの天気情報へのアクセスを得る。ユーザが、関心の対象である交通ドメインを選択すると、ブロック３７８０が実行され、そこでは、交通サブシステムが実行され（図４１に関連して更に詳しく説明される）、ユーザは、市によるレポート、あるルートに関するレポート、個人向けレポートなどの交通情報へのアクセスを得る。ユーザが、関心の対象である株ドメインを選択すると、ブロック３７９０が実行され、そこでは、株サブシステムが実行され（図４２に関連して更に詳しく説明される）、ユーザは、マーケットサマリー、株式相場、株式ニュース、個人向けの株式ニュース又はトランザクション（例えば、買い、売り）などの株情報及びトランザクションへのアクセスを得る。ユーザが、関心の対象であるスポーツドメインを選択すると、ブロック２５００が実行され、そこでは、スポーツサブシステムが実行され（図４３に関連して更に詳しく説明される）、ユーザは、スポーツスコア、スポーツニュース、スポーツイベントチケット情報、スポーツファンタジーリーグトランザクションなどのスポーツ情報及びトランザクションへのアクセスを得る。
【０２１４】
図３８に、サインインサブシステムを示す。ブロック３８１０において、発信者識別が行われる。音声ポータル１０のユーザのタイプとして未確認ユーザが挙げられる。発信してくる未確認ユーザ（おそらくは初めて）は、従来の発信者識別技術（「発信者ＩＤ」）によりその所在確認が可能であるか、あるいは不可能である。発信者ＩＤがデータベース１７０に存在しないならば、発信者はおそらく新規の発信者である。発信者ＩＤが隠されている場合、音声ポータル１０はいずれの判断もできない。ある実施態様では、音声ポータル１０は電話番号（又は、その他の識別情報）を聞き、「識別された」発信者として続ける。代わりの実施態様では、音声ポータル１０は確認作業を行うことなく続ける。この決定は、要求される情報の種類に依存するかもしれない。例えば、ある特定の縦方向ドメインにおいては、手続き（例えば、オークション）を進める前に、ユーザの身元を決定し、よってユーザを特定する必要があるかもしれない。
【０２１５】
特定されたユーザは、定期契約者又は非定期契約者のいずれかである。特定されたユーザが定期契約者であるならば、音声ポータル１０は、クレジットカード、好み設定など、そのユーザの情報をデータベース１７０に保有している。ユーザが定期契約者であり、よって音声ポータル１０は、好み設定及び興味の追跡を始めることができ、よって高度に消費者価値が付加され、満足を得ることのできるサービスが提供されることが好ましい。ユーザは、定期契約に際し、住所及びクレジットカード番号を含むプロファイル情報を明記してもよい。さらに、特定の発信者についての情報はより多く蓄積される毎に、より多くの広告がユーザに向けられたもの（すなわち、価値のあるもの）となる。
【０２１６】
発信者識別が可能であれば、ブロック３８２０が実行され、そこでは、ユーザにパスワードを問うことによりユーザ確認が行われる。パスワードが確認されると、ユーザの好み設定を行うことができ、制御権はブロック３８７０へパスされ、そして制御権は図３７へ戻され、そこでは、イントロダクション又はランウェイ選択が実行される。入力されたパスワードが無効であれば、制御権はブロック３８４０へパスされる。
【０２１７】
発信者識別が可能ではなく、又はユーザが自身のパスワードを知らない場合、制御権はブロック３８３０へパスされ、そこでは、音声ポータル１０がユーザのアカウント状況を決定する。ユーザがアカウントを持たないならば、制御権はブロック３８５０へパスされ、そこでは、ユーザはアカウントを設定する必要がある旨のアカウント設定の督促が提示される。ユーザがアカウントを持っているならば、制御権はブロック３８４０へパスされ、そこでは、音声ポータル１０はユーザのアカウント番号を取得する。ユーザがアカウント番号を忘れたならば、制御権はブロック３８５０へパスされ、そこでは、ユーザはアカウントを設定するよう求められる。ユーザが有効なアカウント番号を提供するならば、制御権はユーザ確認のためのブロック３８２０へパスされる。ユーザが無効なアカウント番号を提供するならば、制御権はブロック３８６０へパスされ、そこでは、音声ポータル１０が、アカウントが無効であり、ウェブサイトを参照するか、あるいはアシスタントを得るためにサポート番号に電話するよう、ユーザに報せる。その後、制御権はブロック３８８０へ、そして図３７へパスされ、そこでは、イントロダクション又はランウェイ選択が実行される。
【０２１８】
次に、図３９においては、映画サブシステムが実行される。ブロック３９１０において、音声ポータル１０は、関心の対象である映画ドメインのイントロダクションを再生する。ユーザは、劇場での映画、映画のリスト、映画のレビューなどのオプションを選択することができる。ユーザが劇場での映画を選択すると、制御権はブロック３９１５へパスされ、そこでは、音声ポータル１０が、ユーザが望む地理的ロケーションを決定する。ロケーションの決定には、郵便番号、州及び都市、好み設定など、様々なメソッドが採用されるかもしれない。あるロケーションの近辺に劇場がないならば、ブロック３９２０が実行され、そこでは、当該エリア内には劇場は存在しないことを報せるメッセージがユーザに対して再生される。ロケーションが決定された後、ブロック３９２５が実行され、そこでは、ロケーション内の劇場の名前がリストにされる。ブロック３９２５の後、ブロック３９３０が実行され、そこでは、エリア内の劇場で上映中の映画がリストにされる。音声ポータル１０は、ユーザに映画を選択するよう求め、制御権はブロック３９３５へバスされる。
【０２１９】
再び、関心の対象である映画ドメインへのイントロダクションが再生されるブロック３９１０において、ユーザが映画のリストを要求すれば、ブロック３９４０が実行され、そこでは、音声ポータル１０がユーザから映画の題名を求める。ブロック３９４０の後、ブロック３９４５が実行され、そこでは、ユーザが望む地理的ロケーションが得られる。上述のように、発信者のロケーションを決定するために、様々なメソッドを使用してもよい。選択された映画を上映する劇場が存在するならば、ブロック３９５０が実行され、そこでは、当該映画を上映する劇場がリストされ、ユーザはリストから選択することを求められる。その後、制御権はブロック３９３５へパスされる。選択された映画を上映する劇場が存在しないならば、ブロック３９５５が実行され、ユーザに対して、最も近くのロケーションにおける映画の時間が提供される。その後、制御権はブロック３９３５へパスされる。
【０２２０】
再び、関心の対象である映画ドメインへのイントロダクションが再生されるブロック３９１０において、ユーザが映画レビューを求めるならば、ブロック３９６０が実行され、そこでは、音声ポータル１０がユーザから映画の題名を求める。ブロック３９６０の後、ブロック３９６５が実行され、そこでは、選択された映画に関するレビューが再生される。ブロック３９６５の後、ブロック３９７０が実行され、そこでは、音声ポータル１０が、ユーザに対し、選択された映画の上映時間を知りたいかどうかを問い合わせる。ユーザが断れば、制御権はブロック３９６０へ戻され、映画レビューが求められる他の映画の題名が得られる。ユーザが受諾すると、制御権はブロック３９４５へパスされる。
【０２２１】
ブロック３９３５において、音声ポータル１０は、選択された映画及び劇場について、上映時刻を提供する。ブロック３９８０において、音声ポータル１０は次のアクションを要求する。ユーザは劇場の住所を要求することができ、その情報はブロック３９８５において提供される。ユーザは映画のレビューを要求することもでき、その情報はブロック３９９０において提供される。ユーザが関心の対象である映画ドメインからの退出を欲すると、制御権は、図３７のブロック３７５０へ戻される。
【０２２２】
次に、図４０においては、天気サブシステムが図示されるように実行される。ブロック４０１０において、音声ポータル１０は、関心の対象である天気ドメインへのイントロダクションを再生する。ブロック４０１０でイントロダクションが再生された後、制御権がブロック４０２０へパスされ、そこでは、音声ポータル１０が、関心の対象である天気ドメインにおいて使用するロケーション情報を得る。上述のように、ロケーション情報を得るために複数のメソッドが可能であり、例えば、郵便番号、都市及び州、その他のロケーションを示唆する印からロケーションが求められる。ブロック４０２０の後、制御権がブロック４０３０へパスされ、そこでは、音声ポータル１０は、ユーザが現在の天気情報を求めているか、あるいは以降の時刻における天気情報を求めているのかについて、プロンプトを提示する。以降の時刻における天気情報を聞くべくユーザが選択したならば、制御権はブロック４０４０へパスされ、そこでは、音声ポータル１０が、ユーザに対し、天気待ち期間のオプションを提供するプロンプトを再生する。ユーザが現在の天気情報を求め、あるいはブロック４０４０においてユーザが待ち期間オプションを選択したならば、制御権はブロック４０５０へパスされ、そこでは、音声ポータル１０が、望みの天気情報を提供する。
【０２２３】
ブロック４０５０が実行された後、制御権はブロック４０６０へパスされ、そこでは、音声ポータル１０がユーザに対し、数日先の期日における予報を望むかどうかを問い合わせる。数日先の期日における予報が望まれるならば、制御権はブロック４０７０へパスされ、そこでは、音声ポータル１０が数日先の期日における予報を提供する。ブロック４０７０の後、あるいはユーザが数日先の期日の予報を望まないならば、制御権はブロック４０８０へパスされ、そこでは、音声ポータル１０はユーザに対し、次のアクションを問い合わせる。ユーザが関心の対象である天気ドメインで続けたいならば、制御権はブロック４０２０へパスされる。ユーザが関心の対象である天気ドメインから退出したいならば、制御権は、図３７のブロック３７５０に関連して説明されたランウェイに対応するブロック４０９０へパスされる。
【０２２４】
次に、図４１において、交通サブシステムが実行される。ブロック４１１０において、音声ポータル１０は、関心の対象である交通ドメインへのイントロダクションを再生する。ブロック４１１０の後、制御権がブロック４１１５へパスされ、そこでは、音声ポータル１０が、ユーザのための、あるいはユーザ向けの情報のためのロケーション情報を取得する。ブロック４１１５の後、制御権はブロック４１２０へパスされ、そこでは、音声ポータル１０が都市交通情報を取得する。都市交通情報が可能でないならば、制御権はブロック４１３５へパスされ、そこでは、郵便番号交通情報が取得される。郵便番号交通情報は、都市が音声ポータル１０によって認識されない場合の予備である。都市データが見つからず、そして近くのロケーションについてデータが含まれているならば、制御権はブロック４１４０へパスされ、そこでは、音声ポータル１０が近くの都市について問い合わせる。ブロック４１２０において、いかなる交通状況も報告の価値がないならば、制御権はブロック４１２５へパスされ、そこでは、ユーザは、当該都市において交通に関し報告すべき事柄はない旨知らされる。ブロック４１２０において交通データが無いならば、制御権はブロック４１３０へパスされ、そこでは、ユーザは、他の都市について再度試みるか、あるいは関心の対象である新規ドメインの選択のためにランウェイへ向うかのオプションが与えられる。
【０２２５】
ブロック４１２０の後、制御権はブロック４１４５へパスされ、そこでは、音声ポータル１０が、具体的な交通ルート又は「全市」を要求する。ブロック４１４５の後、制御権はブロック４１５０へパスされ、そこでは、音声ポータル１０が、ルート方角情報を取得する。ブロック４１５０の後、ルート上にレポートすべき交通が無い場合、制御権はブロック４１５５へパスされる。ブロック４１５５において、ユーザは、新しい交通ルートを選択するか、「全市」を選択するか、あるいはランウェイへ出て関心の対象である新しいドメインを選択するかのオプションが与えられる。ルート交通情報があるならば、ブロック４１５０の後、制御権はブロック４１６０へパスされ、そこでは、音声ポータル１０が、選択されたルートについてのルート交通をリストする。ユーザが、ブロック４１４５において「全市」を選択したならば、制御権はブロック４１６５へパスされ、そこでは、音声ポータル１０が都市交通情報をリストする。
【０２２６】
ブロック４１６０及びブロック４１６５の後、制御権はブロック４１７０へパスされ、そこでは、音声ポータル１０がユーザに対し、望みの交通レポートを提供する。ブロック４１７０の後、制御権はブロック４１７５へパスされ、そこでは、音声ポータル１０が、関心の対象である交通ドメインにおいて次に実行すべきアクションを問い合わせる。例示的実施態様では、次のアクションには、交通レポートを繰り返す、交通情報リストを継続する、及びランウェイへ向う、が含まれるかもしれない。ブロック４１７５においてユーザが選択を行った後、制御権は適切なブロックへパスされる。例えば、ユーザの選択が交通レポートの繰り返しであるならば、制御権はブロック４１７０へパスされる。ユーザの選択がリストオプションの継続であるならば、ブロック４１４５においてなされる具体的交通ルートか「全市」かの選択に従って、制御権は、ブロック４１６０又はブロック４１６５のいずれかにパスされる。ユーザがランウェイへ向うを選択するならば、制御権は、図３７のブロック３７５０に関連して説明されたランウェイに対応するブロック４１８０へパスされる。
【０２２７】
次に、図４２において、株サブシステムが実行される。ブロック４２１０においては、音声ポータル１０は、関心の対象である株ドメインへのイントロダクションが再生される。ブロック４２１０の後、制御権はブロック４２１５へパスされ、そこでは、音声ポータル１０がユーザに対し、マーケットサマリー、株式相場、「ＭｙＱｕａｃｋ」と呼ばれる個人向けリストの選択のオプションを提供する。ユーザがマーケットサマリーを選択すると、制御権はブロック４２４０へパスされ、そこでは、ダウ・ジョーンズ工業平均株価、ナスダック、Ｓ＆Ｐ５００、ニューヨーク証券取引所出来高、ナスダック出来高、３０年債などの様々なマーケットについてのマーケットサマリーが提供される。ユーザが株式相場を選択すると、制御権はブロック４２２０へパスされ、そこでは、音声ポータル１０がユーザから株の具体的銘柄を入手する。ブロック４２２０の後、制御権はブロック４２２５へパスされ、そこでは、音声ポータル１０が、ブロック４２２０で提供された株銘柄に対応する証券取引所を得る。取引所が特定された後、制御権はブロック４２３０へパスされ、そこでは、音声ポータル１０が、株価、最終取引、株価変動、出来高、一日の最高値／最安値などの株式情報を提供する。
【０２２８】
ブロック４２３０の後、制御権はブロック４２３５へパスされ、そこでは、音声ポータル１０が、関心の対象である株ドメインにおいて実行すべき次のアクションを問い合わせる。例示的実施態様では、ユーザは、株情報を繰り返す／株情報のリスティングを継続する、新規株を得る、マーケットサマリーを聞く、ランウェイへ向う、から選択することが可能である。ブロック４２３５におけるユーザの選択に従って、制御権は、マーケットサマリーのためのブロック４２４０、新規株銘柄のためのブロック４２２０、個人向けのＭｙＱｕａｃｋＳｔｏｃｋのためのブロック４２５０、あるいはランウェイのためのブロック４２７５へ、それぞれパスされる。ブロック４２７５の前に、制御権はブロック４２７０へパスされてもよく、そこでは、音声ポータル１０がユーザに対し、個人向け情報を迅速に得るための好み設定を設定してもよい旨の好み設定リマインダを提供する。好み設定についてユーザが既にリマインドされていれば、制御権は、直接ブロック４２７５へパスされる。
【０２２９】
ブロック４２１５においてユーザが「ＭｙＱｕａｃｋ」を選択すると、制御権は、アカウント情報が特定されない場合はブロック４２４５へ、アカウント情報が特定される場合はブロック４２５０へ、それぞれパスされる。ブロック４２４５では、好み設定セットアップ及びアカウント情報が確立される。ユーザに対し、アカウントはウェブ上でセットアップできるとの示唆を行ってもよい。ブロック４２５０においては、株価、最終取引、株価変動、及び出来高などの個人向け株式情報が提供される。ブロック４２５０の動作中においては、特定の株銘柄についての情報再生中に、ユーザは、例えば、「それ」と言うことによって、具体的な株銘柄を特定してもよい。そのような選択がなされたならば、制御権はブロック４２５５へパスされ、そこでは、特定の株銘柄について株式ニュースオプションがリストされる。ブロック４２５５において、ユーザが、リストから特定のタイプの株式ニュースを選択した後は、制御権はブロック４２６０へパスされ、そこでは、音声ポータル１０が、選択された株式ニュースを再生する。ブロック４２６０の後、制御権はブロック４２６５へパスされ、そこでは、音声ポータル１０が、ユーザに対し、株式ニュースのリスト（ブロック４２５５）を得るために戻るか、あるいは株式ニュースを退出するかを問い合わせる。ユーザが、株式ニュースからの退出を選択するならば、制御権はブロック４２３５へパスされ、そこでは、株についての次のアクションが要求される。ユーザが、関心の対象である株ドメインを完了したならば、制御権は、図３７のブロック３７５０に関連して説明されたランウェイに対応するブロック４２７５へパスされる。
【０２３０】
次に、図４３において、スポーツサブシステムが実行される。ブロック４３１０において、音声ポータル１０は、関心の対象であるスポーツドメインへのイントロダクションを再生する。ブロック４３１０の後、制御権はブロック４３１５へパスされ、そこでは、音声ポータル１０がユーザの望むスポースのタイプを取得し、あるいは、ユーザは、「ＭｙＱｕａｃｋ」と言うことによって個人向けのスポーツタイプのスコアを得てもよい。ユーザが特定のスポーツを選ぶと、制御権はブロック４３２０へパスされ、そこでは、音声ポータル１０が、リストから選択されたスポーツのリーグ名を取得する。例えば、音声ポータル１０は、「ＮＦＬ、ＮＢＬ、ＮＨＬ、及びメジャーリーグ野球」をリストするかもしれない。ユーザがリーグ名の選択を行った後、制御権はブロック４３２５へパスされ、そこでは、音声ポータル１０が、ユーザが興味を持つ具体的なチームを取得する。ブロック４３２５の後、制御権はブロック４３３０へパスされ、そこでは、スポーツスコアが提供される。例えば、音声ポータル１０は次のように案内するかもしれない：「（チーム名）による最も最近の試合は（日付）の試合で、最終スコアは（チーム１）が（スコア１）で、（チーム２）が（スコア２）でした」。
【０２３１】
ブロック４３１５においてユーザが「ＭｙＱｕａｃｋ」を選択したならば、制御権はブロック４３４０へパスされる。ブロック４３４０において、音声ポータル１０は、個人向けのＭｙＱｕａｃｋスポーツチームのスポーツスコアを提供する。ブロック４３４０の後、制御権はブロック４３３５へパスされ、そこでは、音声ポータル１０が、チーム別ニュースを提供する。ブロック４３３０及びブロック４３３５の後、制御権はブロック４３４５へパスされ、そこでは、音声ポータル１０が、ユーザは今聞いたスポーツ情報を再度繰り返してほしいかどうかを問い合わせる。ユーザがそうである旨応答すると、音声ポータル１０は、提供された情報をリピートする。ユーザが情報のリピートを欲しないならば、制御権はブロック４３５０へパスされ、そこでは、音声ポータル１０が、関心の対象であるスポーツドメインにおいて実行すべき次のアクションを問い合わせる。ブロック４３５０の後、制御権は、リーグ名を選択する場合はブロック４３２０へ、Ｑｕａｃｋスポーツスコアを提供する場合はブロック４３４０へ、ランウェイ情報を求める場合はブロック４３５５へ、それぞれパスされる。ブロック４３５５は、図３７のブロック３７５０に関連して更に詳しく説明されたランウェイに対応する。図４０から図４３の各サブシステムは、例示の目的のためのみで示されたものである。
【０２３２】
図に示され、これまで説明された実施態様は、現時点で好ましいものであるが、これらの実施態様は例示目的のためのみであることを理解すべきである。他の実施態様には、音声ポータルを介してのインターネットへのアクセスを簡略化するための様々なデータ構造が含まれてもよい。本発明は特定の実施態様に限定されるものではなく、添付請求項の範囲及び精神の内にある様々な変更、組合せ及び並び替えへと発展するものである。
【図面の簡単な説明】
【図１】 インターネットに接続する音声ポータルの一般的な図式表示。
【図２】 図１の音声ポータルの機能面からの例示的実施態様の一般的な機能ブロック図。
【図３】 図１に示される音声ポータルの物理面からの例示的実施態様のより詳細なブロック図。
【図４】 図１の音声ポータルによって使用される例示的データ構造モデルの図式表示。
【図５】 ユーザ関連情報のための、図４の例示的データ構造モデルの図式表示。
【図６】 関連情報の広告のための、図４の例示的データ構造モデルの図式表示。
【図７】 図４の例示的データ構造モデルの例示的生成プロセスを示すフロー図。
【図８】 図７の例示的生成プロセスの図式表示。
【図９】 非プログラミング手段を用いたインターネット情報の例示的収集プロセスを示すフロー図。
【図１０】 図１の音声ポータルに関連するルールの非プログラミング開発の例示的プロセスの図式表示。
【図１１】 図１の音声ポータルに関連するルールの非プログラミング開発のための、例示的グラフィカルユーザインターフェース。
【図１２】 図１の音声ポータルに関連するルールの非プログラミング開発において使用される、例示的グラフィカルユーザインターフェースウィンドウ。
【図１３】 図１２のグラフィカルユーザインターフェースウィンドウの拡大図。
【図１４】 図１の音声ポータルに関連するルールの非プログラミング開発において使用される、例示的グラフィカルユーザインターフェース検索データエディタウィンドウ。
【図１５】 図１の音声ポータルに関連するルールの非プログラミング開発において使用される、例示的グラフィカルユーザインターフェースウィンドウ。
【図１６】 図１５のグラフィカルユーザインターフェースウィンドウの拡大図。
【図１７】 図１の音声ポータルに関連するルールの非プログラミング開発において使用される、例示的グラフィカルユーザインターフェースウィンドウ。
【図１８】 図１の音声ポータルに関連するルールの非プログラミング開発において使用される、ベンダーフォームオプションのための例示的グラフィカルユーザインターフェースウィンドウ。
【図１９】 図１の音声ポータルに関連するルールの非プログラミング開発における、ＵＲＬのテストのための例示的グラフィカルユーザインターフェースウィンドウ。
【図２０】 図１の音声ポータルに関連するルールの非プログラミング開発における、パターンの選択のための例示的グラフィカルユーザインターフェースウィンドウ。
【図２１】 図１の音声ポータルに関連するルールの非プログラミング開発において、複数ページ上のリンクの検出のためのパターンを特定するために使用される例示的グラフィカルユーザインターフェースウィンドウ。
【図２２】 スパイダのプログラミングにおいて用いられる階層構造の図式表示。
【図２３】 図１の音声ポータルとともに使用されるスパイダのプログラミングのための例示的グラフィカルユーザインターフェースウィンドウ。
【図２４】 図２３の例示的グラフィカルユーザインターフェースウィンドウの拡大図。
【図２５】 図１の音声ポータルの統合データベースへ情報を融合する例示的プロセスを示すフロー図。
【図２６】 図１の音声ポータルの統合データベースへ情報を融合する第２の例示的プロセスを示すフロー図。
【図２７】 ある品目に関するより完全な情報を得ることを目指した、２つのエグジスタントからの正規エグジスタントの生成の図式表示。
【図２８】 インターネットソースから図１の音声ポータルのユーザへのデータの分離及び変換の例示的プロセスの第１部分の図式表示。
【図２９】 インターネットソースから図１の音声ポータルのユーザへデータが分離され、変換される図２８の例示的プロセスの第２部分の図式表示。
【図３０】 図１の音声ポータルの例示的動作フローを示すフロー図。
【図３１】 図３０のフロー図の例示的動作サブシステムを示すフロー図。
【図３２】 図３０のフロー図の第２の例示的動作サブシステムを示すフロー図。
【図３３】 図３０のフロー図の第３の例示的動作サブシステムを示すフロー図。
【図３４】 望みの品目又はサービスを決定するための、図１の音声ポータルにおけるユーザ反応のファネリングの例示的プロセスを示すフロー図。
【図３５】 図１の音声ポータルを用いてトランザクションを行う例示的プロセスを示すフロー図。
【図３６Ａ】 図１の音声ポータルを用いた広告の例示的プロセスを示すフロー図。
【図３６Ｂ】 図１の音声ポータルを用いた広告の第２の例示的プロセスを示すフロー図。
【図３７】 図１の音声ポータルの例示的ダイアログマップを示すフロー図。
【図３８】 図３７の例示的ダイアログマップの例示的サブシステムを示すフロー図。
【図３９】 図３７の例示的ダイアログマップの第２の例示的サブシステムを示すフロー図。
【図４０】 図３７の例示的ダイアログマップの第３の例示的サブシステムを示すフロー図。
【図４１】 図３７の例示的ダイアログマップの第４の例示的サブシステムを示すフロー図。
【図４２】 図３７の例示的ダイアログマップの第５の例示的サブシステムを示すフロー図。
【図４３】 図３７の例示的ダイアログマップの第６の例示的サブシステムを示すフロー図。

Claims (43)

1. 交信装置のユーザによって開始された交信接続要求を示す信号を受信するステップと；ユーザの交信装置と交信接続を確立するステップと；ユーザから音声情報を受け取るステップと；ユーザから受け取った音声情報に反応する音声情報を伝達し、当該反応音声情報にはインターネットに基づく情報が含まれるステップと、ソースからの情報をインターネットを経由して収集するステップと、互いに相違するデータソースからの同一情報を、正規化したデータオブジェクトにマージするステップとを有し、
   前記マージするステップは、
   前記互いに相違するデータソースの各々からの情報の属性を取得し、これらの属性は当該データソースのメタデータ中に含まれることと；
   前記属性のうち所定パーセンテージ以上の属性が共通であれば、許容し得るマッチを判定することと；
   許容し得るマッチが判定された場合に、前記互いに相違するデータソースからの情報をマージすることと
   を含む、インターネットに基づく情報への音声アクセスを提供する方法。
2. ユーザから受け取った音声情報に反応する音声情報を伝達するステップが、インターネットに関連する様々な異なるソースからのインターネットに基づく情報を応答的に提供するステップを有する、請求項１に記載の方法。
3. インターネットに基づく情報が、映画、天気、交通、株、及びスポーツに関連する情報を有する、請求項２に記載の方法。
4. ユーザから受け取った音声情報に反応する音声情報を伝達するステップが、広告を選択的に提供するステップを有する、請求項１に記載の方法。
5. 広告を選択的に提供するステップが、ユーザのプロファイルに対応する重み付けを有する広告の集合を特定するステップを有する、請求項４に記載の方法。
6. 広告を選択的に提供するステップが、許可に基づく広告を提供するステップを有し、当該許可に基づく広告は、ユーザからの要求を受け取った後に更なる広告情報を提示する、請求項４に記載の方法。
7. 広告を選択的に提供するステップが、スピークスルー広告を選択的に提供するステップを有し、前記スピークスルー広告は、広告対象についてより詳しく説明を聞くことをユーザが選択する広告である、請求項４に記載の方法。
8. 選択的に提供された広告を記録するステップを更に有する、請求項４に記載の方法。
9. ユーザが望む品目又はサービスに関連するトランザクションに関する情報をユーザに提供するステップを更に有する、請求項１に記載の方法。
10. ユーザによる音声確認と同時にトランザクションを実施するステップを更に有する、請求項９に記載の方法。
11. 音声情報を伝達するステップが、伝達すべき情報をユーザの好みに基づいて選択するステップを有する、請求項１に記載の方法。
12. 伝達すべき情報を選択するステップが、ユーザの好みを受動的に決定するステップを有する、請求項１１に記載の方法。
13. 伝達すべき情報を選択するステップが、ユーザからの好みを積極的に要求するステップを有する、請求項１１に記載の方法。
14. 交信接続の持続期間中にユーザへ伝達された情報を記録するステップを更に有する、請求項１に記載の方法。
15. 音声情報を伝達するステップが、可能性のあるユーザの反応を予想すべく、ユーザへ伝達すべき質問を動的に配列するステップを有する、請求項１に記載の方法。
16. 音声情報を伝達するステップが、望まれる品目又はサービスを確認すべく、ユーザ反応を属性に基づいて絞り込むステップを有する、請求項１に記載の方法。
17. 近似関係に従って非同一品目間の関連を提供するステップを更に有する、請求項１に記載の方法。
18. ベンダーが供給する情報を統合データベースに加えるステップを更に有する、請求項１に記載の方法。
19. 収集された情報を編成してエグジスタントデータ構造内に配置するステップを更に有する、請求項１に記載の方法。
20. 収集された情報を検索可能かつ均一なフォーマットへ変換するステップを更に有する、請求項１に記載の方法。
21. 検索可能かつ均一なフォーマットの前記収集された情報を、インターフェースに関連するフォーマットに転換するステップを更に有する、請求項２０に記載の方法。
22. 前記収集された情報をインターフェースに関連するフォーマットへ転換するステップが、前記収集された情報にフレーズグラマーを適用して、特定の属性を含むフレーズを生成するステップを有する、請求項２１に記載の方法。
23. 広範囲における様々な情報及びサービスへのアクセスを提供する、インターネットへの単一音声ポータルであって、ユーザインターフェースと；このユーザインターフェースに結合される少なくとも１つのデータベースであって、当該ユーザインターフェースはユーザとの音声交信を調整し、当該少なくとも１つのデータベースはユーザとインターネットに基づく情報に関する情報を保存する、少なくとも１つのデータベースと；当該少なくとも１つのデータベースに結合され、インターネットと交信し、インターネットに基づく情報を更新して提供する、更新エンジンと；当該少なくとも１つのデータベースに結合され、少なくとも１つのデータソースからの情報の比較を行うとともに選択的に、正規化したデータオブジェクトを形成する融合エンジンとを具え、
    この融合エンジンは、互いに相違するデータソースからの同一情報を、前記正規化したデータオブジェクトにマージし、
    このマージは、
    前記互いに相違するデータソースの各々からの情報の属性を取得し、これらの属性は当該データソースのメタデータ中に含まれ；
    前記属性のうち所定パーセンテージ以上の属性が共通であれば、許容し得るマッチを判定し；
    許容し得るマッチが判定された場合に、前記互いに相違するデータソースからの情報をマージすることによって行う、
    インターネットへの単一音声ポータル。
24. ユーザインターフェースに結合される顧客管理サブシステムを更に具え、当該顧客管理サブシステムは、ユーザの好み及び事実を決定するために必要な情報を獲得するように構成される、請求項２３に記載の音声ポータル。
25. 前記ユーザインターフェースに結合される広告サブシステムを更に具え、当該広告サブシステムは、ユーザに提示される広告を調整するように構成される、請求項２３に記載の音声ポータル。
26. ユーザに提示される広告が、スポンサーシップ広告、ターゲット広告、及び許可に基づく広告のうちの任意の１つを有する、請求項２５に記載の音声ポータル。
27. 交信接続要求を示す信号を受信するための手段と；ユーザと交信接続を確立するための手段と；ユーザへ音声によって情報を伝達するための手段と；ユーザから音声情報を受け取るための手段と；ユーザから受け取った音声情報に反応する音声情報を伝達し、当該音声情報に反応する音声情報には、インターネット経由でソースから得られたインターネットに基づく情報が含まれる手段と；インターネット経由でソースから情報を収集するための手段と；互いに相違するデータソースからの同一情報を、正規化したデータオブジェクトにマージするための手段を具え、
    このマージは、
    前記互いに相違するデータソースの各々からの情報の属性を取得し、これらの属性は当該データソースのメタデータ中に含まれ；
    前記属性のうち所定パーセンテージ以上の属性が共通であれば、許容し得るマッチを判定し；
    許容し得るマッチが判定された場合に、前記互いに相違するデータソースからの情報をマージすることによって行う、
    インターネットに基づく情報及びサービスへの音声アクセスを提供するシステム。
28. ユーザから受け取った音声情報に反応する音声情報の伝達手段が、様々に異なるソースからの情報を応答的に提供するための手段を具える、請求項２７に記載のシステム。
29. ユーザから受け取った音声情報に反応する音声情報の伝達手段が、広告を選択的に提供するための手段を具える、請求項２７に記載のシステム。
30. 広告を選択的に提供するための手段が、ユーザのプロファイルに対応する重み付けを有する広告の集合を特定するための手段を具える、請求項２９に記載のシステム。
31. ユーザが望む品目又はサービスに関連するトランザクションに関する情報をユーザに提供するための手段を更に具える、請求項２７に記載のシステム。
32. ユーザによる音声確認と同時にトランザクションを実施するための手段を更に具える、請求項３１に記載のシステム。
33. ユーザへ音声によって情報を伝達するための手段が、伝達すべき情報をユーザの好みに基づいて選択するための手段を具える、請求項２７に記載のシステム。
34. 伝達すべき情報を選択するための手段が、ユーザの好みを受動的に決定するための手段を具える、請求項３３に記載のシステム。
35. 交信接続の持続期間中にユーザへ伝達された情報を記録するための手段を更に具える、請求項２７に記載のシステム。
36. ユーザへ音声によって情報を伝達するための手段が、可能性のあるユーザの反応を予想すべく、ユーザへ伝達すべき質問を動的に配列するための手段を具える、請求項２７に記載のシステム。
37. ユーザへ音声によって情報を伝達するための手段が、望まれる品目又はサービスを確認すべく、ユーザ反応を属性に基づいて絞り込むための手段を具える、請求項２７に記載のシステム。
38. 近似関係に従って非同一品目間の関連を提供するための手段を更に具える、請求項２７に記載のシステム。
39. ベンダーが供給する情報を統合データベースに加えるための手段を更に具える、請求項２７に記載のシステム。
40. 収集された情報を編成してエグジスタントデータ構造内に配置するための手段を更に具える、請求項２７に記載のシステム。
41. 前記収集された情報を、検索可能かつ均一なフォーマットへ変換するための手段を更に具える、請求項２７に記載のシステム。
42. インターネットに基づく情報及びサービスへの音声アクセスを提供するための、コンピュータ可読プログラムコードを有するコンピュータプログラムであって、当該コンピュータプログラム中のプログラムコードは：交信装置のユーザによって開始された交信接続要求を示す信号を受信するための第１のコンピュータ可読プログラムコードと；ユーザの交信装置と交信接続を確立するための第２のコンピュータ可読プログラムコードと；ユーザへ音声によって情報を伝達するための第３のコンピュータ可読プログラムコードと；ユーザから音声情報を受け取るための第４のコンピュータ可読プログラムコードと；ユーザから受け取った音声情報に反応する音声情報を伝達するためのプログラムコードであって、当該反応する音声情報にはインターネットを経由してソースから獲得した情報であるインターネットに基づく情報が含まれる、第５のコンピュータ可読プログラムコードとを具え、前記音声情報は、互いに相違するデータソースからの同一情報を、正規化したデータオブジェクトにマージして成り、
    このマージは、
    前記互いに相違するデータソースの各々からの情報の属性を取得し、これらの属性は当該データソースのメタデータ中に含まれ；
    前記属性のうち所定パーセンテージ以上の属性が共通であれば、許容し得るマッチを判定し；
    許容し得るマッチが判定された場合に、前記互いに相違するデータソースからの情報をマージすることによって行われる、コンピュータプログラム。
43. ユーザインターフェースと；ユーザインターフェースに結合されるデータベースであって、当該ユーザインターフェースがユーザとの音声交信を調整する、データベースとを具え、音声交信にはインターネットに基づく情報が含まれ、前記情報は、互いに相違するデータソースからの同一情報を、正規化したデータオブジェクトにマージして成り、
    このマージは、
    前記互いに相違するデータソースの各々からの情報の属性を取得し、これらの属性は当該データソースのメタデータ中に含まれ；
    前記属性のうち所定パーセンテージ以上の属性が共通であれば、許容し得るマッチを判定し；
    許容し得るマッチが判定された場合に、前記互いに相違するデータソースからの情報をマージすることによって行われる、音声ポータル。

Images