JP2004514190A - 電話による音声を用いてインターネットによる取引にアクセスし、これを処理し、実行するためのシステム及び方法 - Google Patents

Abstract

電話を使ってアイテム又はサービスに関係する取引を実行するための方法は、前記アイテム又はサービスを識別する情報を提供する段階と、取引が、識別されたアイテム又はサービスと関係付けられる、実行されることになる取引についての問合せを提供する段階と、ユーザーの回答に応答して、識別されたアイテム又はサービスに関係付けられた取引を実行するよう、要求をサーバーシステムへ送る段階とを含んでいる。ユーザーがコンピューターインタフェースで何らの操作を実行することなく、取引は実行される。
【選択図】図３５

Description

【０００１】
（発明の属する技術分野）
本発明は、一般的には、インターネット及び電子商取引、即ち「ｅコマース」に関する。より厳密には、本発明は、電話による音声を用いてインターネットによる取引にアクセスし、これを処理し、実行するためのシステム及び方法に関する。
【０００２】
（発明の背景）
インターネットは、各人がインターネットに接続されているコンピュータを使って、大量の情報にアクセスできる媒体に発展している。インターネットを通して情報にアクセスする能力は、様々な方法で提供することができる。通常は、キーワード又はキーフレーズを求めてインターネットを探索して、テキスト又は埋込み識別子（例えばメタタグ）のような、ウェブページ内の探索ワード又はフレーズを含むウェブサイトのりストを提供する、インターネットサーチエンジンによって、情報が提供されることもある。インターネットを通して個々のウェブサイトによって、情報にアクセスすることができる。個々のウェブサイトは、時間限界性且つ時間依存性の多種多様な情報とサービスを提供する。
【０００３】
インターネットは、特に電子商取引を行うのに優れている。多くのインターネットサーバーが開発されており、ベンダは、それを通して商品又はサービスを広告し、販売することができる。そのような商品又はサービスには、インターネットを通して買い手に電子的に配信されるアイテム（例えば音楽）と、従来の配送チャネル（例えば一般的な運送業者）を通じて配送されるアイテム（例えば本）が含まれる。サービスには、インターネットを通して入手できる情報（例えば天気、交通、映画、コスト比較）の提供と、インターネット上で実行される商取引（例えば株取引、レストラン予約）も含めることができる。
【０００４】
残念ながら、インターネットは大量の情報にアクセスする能力をユーザーに提供はするが、役に立つインターネットベースの情報を見つけ出すのは、時間を要し、面倒なことが多い。更に、複数の個別のウェブサイトで入手可能な同じ情報は、複数の異なる方法で編集され、複数の異なる形態で記述され、異なる様々な時間に変更されることがあるので、それを見つけ出し、比較するの難しい。インターネットに固有のこれらの難しさに加えて、インターネットサービスプロバイダ（ＩＳＰ）経由でインターネットに接続されているコンピュータ又は別の電子装置を持っていなければ、インターネットで入手可能な情報にはアクセスできないという単純な事実もある。更に、所望のインターネットベースの情報を効率的に見つけ出すためには、インターネット経由での情報の探し出し方を学習しなければならない。このように、コンピュータを持っていない人、ＩＳＰと接続していない人、適切なソフトウェアを持っていない人、インターネットの利用に関して経験又は訓練経験の無い人は、インターネットベースの情報へのアクセスが制限される。これらの要因が、１９９９年の終わりまでに、米国人口の３０パーセントしかインターネットにアクセスしたことがない、即ち「ウェブをサーフィンした」ことがない（１９９９年１０月、フォレスターリサーチからの統計）と産業の専門家たちが推定する理由となっている。
【０００５】
従って、直接コンピュータを使用しなくても、専用のＩＳＰ接続を持っていなくても、又はインターネット使用の経験又は訓練経験がなくても、インターネットベースの情報にアクセスできるシステム及び方法を提供することが望まれている。更に、例えば公衆電話からの音声のような、便利で容易に利用可能な手段を使ってインターネットベースの情報を入手できるようにするシステム及び方法を提供することが望まれている。更に、電話による音声を使って、インターネット上の取引にアクセスし、これを処理し、実行することができるシステム及び方法を提供することが望まれている。更に、そのような取引は、どの様なユーザーインタフェースプラットフォームについても可能でなくてはならない。
【０００６】
これまで、このようなシステム及び方法に向けて多くの挑戦が行われたが、不可能であった。例えば、そのようなシステム及び方法を使う人は、情報を、迅速に、又は少なくともある許容時間内に欲しがるであろう。そのような速さの実現は難しい。従来の高速コンピュータと高速通信接続を以ってしても、インターネットにアクセスするのに必要な時間遅延のせいで、多くの人に「ワールドワイドウェブ」ではなく「ワールドワイドウェイト」と呼ばせることになる。そのようなシステム及び方法へのもう１つの挑戦は、音声通信の認識である。従来の音声認識技術は、遅い上に不正確である。音声によるインターネットベースの情報への便利で有用なアクセスには、簡単、迅速且つ正確な音声認識が必要とされる。にもかかわらず、既知のプロセッサ及び記憶装置では、人対人の対話においてなされる音声認識に不可欠な大量の語彙及び処理速度への迅速なアクセスを実行できていない。
【０００７】
そのようなシステム及び方法に関するもう１つの挑戦は、サービスを財務的にサポートしながら、インターネットベースの情報への自由なアクセスをどのように提供するかということである。従来のインターネットでの広告は、「バナー」のような広告情報を見て、バナーを「クリックする」というような何らかの手動的選択を行って、広告されている商品又はサービスに関する更なる情報を得るという能力を必要としている。
【０００８】
従って、上記性能に加え、無料でインターネットベースの情報へ迅速且つ正確に音声アクセスすることのできるシステム及び方法を提供することが望まれている。更に、音声及び無線アクセスプロトコル（ＷＡＰ）を含め、インターネットベースの取引に必要な情報及び処理を、様々なプラットフォームのユーザーに提供するシステム及び方法を提供することが望まれている。
【０００９】
（発明の概要）
本発明の実施例の１つの態様は、アイテム又はサービスに関する取引を、電話を使って実行するための方法である。本方法は、アイテム又はサービスを識別する情報を提供する段階と、識別されたアイテム又はサービスに取引が関係付けられる、実行されることになる取引についての問合せを提供する段階と、ユーザーの回答に応えて、識別されたアイテム又はサービスに関係付けられた取引を実行する要求をサーバーシステムへ送る段階を含んでいる。取引は、ユーザーがコンピュータインタフェースで何らの動作も実行することなく行われる。
【００１０】
本発明の実施例のもう１つの態様は、要約すると、インターネット上で取引を処理する音声制御式取引サービスである。このサービスは、ユーザーインタフェースと、少なくとも１つのデータベースとを含んでいる。ユーザーインタフェースは、アイテム又はサービスの情報とアイテム又はサービスに関連する取引が含まれる、ユーザーとの音声通信を調整する。データベースは、ユーザーインタフェースと連結され、アイテムとサービス情報を記憶する。取引は、ユーザーがボタンを押すことなく、マウスをクリックすることなく、コンピューター装置へ何ら手動入力することなく実行される。
【００１１】
本発明の実施例の又別の態様は、要約すると、インターネットベースの情報へのアクセスとインターネットベースの取引の実行を提供するためのサービスであり、ユーザーは、電話による音声を使って、そのサービスと通信する。このサービスは、アイテム又はサービスを識別する情報を提供し、識別されたアイテム又はサービスに関係付けられる、実行されることになる取引についての問合せを提供するための手段と、提供された質問に対するユーザーの回答に応えて、識別されたアイテム又はサービスに関係付けられた取引を実行する要求を、サーバーシステムへ送るための手段を含んでいる。
【００１２】
本発明の実施例の又別の態様は、要約すると、アイテム又はサービスに関係する取引を通信装置を使って実行するための、コンピュータ読み取り可能プログラムコードを備えたコンピュータプログラム製品である。このコンピュータプログラム製品のプログラムコードは、アイテム又はサービスを識別する情報を提供するための第１コンピュータ読み取り可能プログラムコードと、識別されたアイテム又はサービスに関係付けられた、実行されることになる取引についての問合せを提供するための第２コンピュータ読み取り可能プログラムコードと、問合せに対するユーザーの応答に応えて、識別されたアイテム又はサービスに関係付けられた取引を実行する要求を、サーバーシステムへ送るための第３コンピュータ読み取り可能プログラムコードを含んでいる。取引は、ユーザーが手動操作を実行することなく行われる。
【００１３】
本発明のこの他の特徴及び利点は、添付図面、詳細な説明、及び特許請求の範囲に記載した事項を見て頂ければ、当業者には明白であろう。
【００１４】
（代表的実施例の詳細な説明）
本発明は、例を用いて説明しているが、添付図面によって何ら制限されるものではない。なお、図中、類似参照番号は類似要素を表している。
【００１５】
電話による音声を用いて、インターネットによる取引にアクセスし、これを処理し、実行するためのシステム及び方法を説明する。以下の記述では、説明を目的として、本発明を完全に理解して頂くために数多くの具体的な詳細事項について述べている。しかしながら、当業者には明らかなように、本発明はこれら具体的な詳細事項に制約されることなく実施することができる。その他の例では、本発明の好適な実施例を説明し易くするために、周知の構造及び装置をブロック図の形で示している。
【００１６】
本発明の代表的な実施例の１つの態様は、アイテム又はサービスに関係した取引を、電話を使って実行するための方法を含んでいる。本方法は、アイテム又はサービスを識別する情報を提供し、識別されたアイテム又はサービスに取引が関係付けられる、実行されることになる取引についての問合せを提供する段階と、ユーザーの回答に応えて、識別されたアイテム又はサービスに関係付けられた取引を実行する要求を、サーバーシステムに送る段階を含んでいる。取引は、ユーザーがコンピュータインタフェースで何らの動作も行うことなく実行される。
【００１７】
本システム及び方法は、消費者が、従来の商店又は電話アクセスが利用できる何処かで買い物をしている間に、オンライン小売業者から価格付け情報を入手して、注文できるようにする音声ベースの電話サービスを含んでおり、好都合である。音声ユーザーインタフェースは、ユーザーが興味を持った製品を特定的に識別できるようにする一連の質問を問い合わせることができるようになっており好都合である。これらの問い合わせのプロンプトは、製品のタイプが違えば様々に変えることができるし、実行時に設定変更することもできる。ユーザーは、回答を音声で伝えることによって、必要ならばスペリング及びＤＴＭＦ（二重トーン多重周波数、即ち、電話でのタッチトーン）に落として応答することができる。更に、音声ユーザーインタフェースは、仮想製品データベース（局所的にキャッシュされた情報とインターネットから実行時に検索された情報から構成される）と対話することができる。更に、音声ユーザーインタフェースは、様々なオンライン小売業者からの製品の価格付け及び入手可能性に関する情報を、消費者へ最小の遅延時間で戻すことができる。更に、音声ユーザーインタフェースは、ユーザーが、小売業者を選択して製品を注文できるようにする。
【００１８】
本発明のもう１つの態様は、インターネットベースの情報及びサービスへの音声アクセスを提供するシステムに関係している。本発明の更に別の態様は、１つのウェブサイトが他のウェブサイトと同じ情報を持っているかどうか判定するためのシステム及び方法に関係している。本発明の更に別の態様は、インターネットの音声ポータルを使って広告するためのシステム及び方法に関している。本発明の更に別の態様は、インターネットベース情報の変換に用いられるルールの非プログラミング開発のためのシステム及び方法に関している。本発明の更に別の態様は、所望のアイテムを決定するために、インターネット音声ポータルシステムでユーザーの応答を送るためのシステム及び方法に関係している。本発明の更に別の態様は、組織的に構築されたデータの変換及び基準化に関係している。
【００１９】
ある実施例では、メモリ内に含まれている一連の命令を実行する中央演算処理装置（ＣＰＵ）を有するコンピュータシステムが用いられている。更に特定すると、連続した命令の実行が、ＣＰＵに、以下に説明する段階を実行させる。命令は、実行に備えてＣＰＵによって、読み取り専用メモリ（ＲＯＭ）、大容量記憶装置、又は幾つかの他の恒久記憶装置から、ランダムアクセスメモリ（ＲＡＭ）内へとロードされる。他の実施例では、本発明を実施するために、ソフトウェア命令の代わりに、又はソフトウェア命令と組み合わせて、結線接続回路が用いられる。従って、ここに記載されている実施例は、ハードウェア回路とソフトウェアとの特定の組み合わせに限定されず、コンピュータシステムによって実行される命令に関する特定のソースにも限定されない。
【００２０】
図１は、音声ポータル１０とネットワーク２０の間の接続を示している。代表的実施例では、ネットワーク２０は、インターネット、即ち、ＴＣＰ／ＩＰネットワークプロトコルを使ってデータの伝送及び交換を容易にするコンピュータネットワークの世界規模のネットワークである。別の実施例では、ネットワーク２０は、バーチャル私設ネットワーク（ＶＰＮ）のような、何れかのタイプのネットワークである。ネットワーク２０は、ハイパーテキストマークアップ言語（ＨＴＭＬ）ウェブページ３０及び４０との通信を提供するのが望ましい。ウェブページ３０及び４０は、様々なウェブサーバー上の様々なデータを含んでいる。ネットワーク２０は、更に、コンピュータ５２及び５４とデータベース５８を含んでいるサービス５６とをネットワーク２０に連結する、非音声ポータル５０との通信も提供する。サービス５６は、ネットワーク２０との接続を有する、何らかのタイプの会社、コンテンツ又はサービスプロバイダである。データベース５８はデータ用の記憶媒体であり、光学的、磁気的又は他の何れかの好適な記憶媒体である。
【００２１】
一般的に、音声ポータル１０は、サーバーのネットワークとして実現される。サーバーは、ソフトウェアによって構成できる。サーバーは、ディスクドライブ及び他の記憶装置を含む大量の読み取り／書き込みメモリを備えているのが望ましい。一般に、ユーザーは、携帯電話１２又は固定電話１４のような電話で、電話と音声ポータル１０との間の通信を開始する電話番号（一般的な旧来の電話サービス（ＰＯＴＳ））を呼び出すことによって、音声ポータル１０にアクセスする。代わりに、音声又は音声データをポータル１０へ伝達するのに別のタイプの電話サービスを利用してもよい。ポータル１０は、様々なライン、ネットワーク及びステーション経由で、電話１２及び１４と接続することができる。音声ポータル１０は、ユーザーとの音声通信を提供するので好都合である。音声ポータル１０は、ユーザーが、ウェブページ３０及び４０、及びネットワーク２０経由で利用可能な他のソースからの情報及びサービスにアクセスできるようにする。そのようなアクセスは、音声ポータル１０によって迅速且つ効果的な方法で提供され、様々なウェブサイト及びインターネットサービスからの情報を継続して検索し、編成し、記憶する。他のユーザーインタフェースプラットフォームも、音声ポータル１０を使うように設けられている。そのようなユーザーインタフェースプラットフォームは、例えば、ＷＡＰ（無線アプリケーションプロトコル）及びウェブインタフェースを含んでいる。
【００２２】
図２は、音声ポータル１０によって実行される代表的な機能的オペレーションを示している。これらの機能は、任意の数の物理的な構造を含む様々な方法で実行される。代表的な実施例では、音声ポータル１０は、ユーザーインタフェース１１０と、広告サブシステム１２０と、顧客管理サブシステム１３０と、イグジスタンツサブシステム１４０と、フュージョンエンジン１５０と、更新エンジン１６０と、データベース１７０を含んでいる。
【００２３】
ユーザーインタフェース１１０は、音声ポータル１０とユーザーとの間の音声通信を調整する。ユーザーインタフェース１１０は、音声、インターネット即ち「ワールドワイドウェブ」（ＷＷＷ）、無線アプリケーションプロトコル（ＷＡＰ）インタフェースによるもの、又は何れの他のプラットフォームインタフェースであってもよい。代表的な実施例では、ユーザーインタフェースは音声指向である。そのような音声指向の実施例では、ユーザーインタフェース１１０は、可能なあらゆる場所でユーザー入力を受信するために、ワードベースの自動音声認識（ＡＳＲ）を利用する。ユーザーインタフェース１１０は、マサチューセッツ州ボストンのスピーチワークスインターナショナルから提供されているスピーチワークスのような音声認識ソフトウェアパッケージを用いることができる。高速の音声認識のために、ユーザーインタフェース１１０は、ユーザーの応答を一式の認識可能な回答に絞り込む絞り込みプロセスを利用しており好都合である。絞り込みについては、図３４と関連付けて更に説明することとする。ユーザーインタフェース１１０は、ワードベースのＡＳＲが使用不能である場合、ユーザー入力を受信するためにスペリングベースのＡＳＲを用いる。最終的に、ユーザーインタフェース１１０は、ユーザーに利点がある場合にだけ、ユーザー入力を受信するのにキーパッド入力を用いる。キー入力は、電話１２及び１４のキーを利用する（図４）。
【００２４】
代表的な実施例では、ユーザーインタフェース１１０は、下記の内の１つ又は複数のタスクを実行する。（１）電話番号と、その他のユーザー固有の情報でユーザーを確認する。（２）所与のプラットフォーム上の所与のユーザーに対し新しいセッションを開始する。（３）所与のプラットフォーム上の所与のユーザーに対し新しい命令を追加する。（４）音声ポータル１０で利用可能な関心対象の一式の垂直ドメイン内でのユーザーの嗜好を更新する。（５）関心対象の前記垂直ドメインに関するユーザーの嗜好を使用可能又は使用禁止にする。（６）ユーザーの技能レベルを全体的に、又は特定の垂直内で更新する。（７）ユーザーの人口統計上の情報、又は個人的な情報（並びにクレジットカード情報）を更新する。（８）ユーザーのセッション状態を、ユーザーインタフェース特定情報と共に更新する。（９）新しいクレジットカードをデータベースに加える。（１０）現在のクレジットカードを新しい情報と共に更新する。（１１）クレジットカードをクレジットカードのタイプと番号とで識別し、既にデータベースにあるかどうか検査する。（１２）ユーザーに利用可能な垂直ドメインのリストとその順序を設定する。（１３）ユーザーのセッションを正常に終了する。（１４）顧客管理サブシステム１３０に、ユーザーのセッションが変則的に終了してある所定の状態（例えば、対話中断、セッションタイムアウト）にあることを通知する。（１５）セッションが変則的に終了されていたら（例えば、対話中断、セッションタイムアウト）、セッションを再開できるように、所与のプラットフォームを与えられたユーザーの最近のセッションを判定し、記憶されているセッション状態を返す。ユーザーインタフェース１１０は、識別、セッション、ユーザー及び支払いプロトコルに関係した追加機能を実行することができる。
【００２５】
広告サブシステム１２０は、通信セッション中にユーザーに提示される広告に関する活動を調整する。ある代表的な実施例では、広告サブシステム１２０は、スポンサー付の広告、特定のユーザーに的を絞った広告、及びユーザーからの積極的な要求の後にだけ提示される許可ベースの広告のような広告を含んでいる。ある代表的な実施例では、広告サブシステム１２０は、以下の機能の内１つ又は複数の機能を提供する。（１）ユーザー、セッション、ロケーション、コンテンツ、及び探査されているアイテムに基づいて、上演する広告を選択する。（２）広告が上演されたこと、それが完了したか否かということを記録する。（３）スピークスルー（即ち、以下で述べるように、ユーザーが広告された対象について更に聴くことを選択的に選択する広告）が行われたことを記録する。（４）データベース呼び出しを繰り返す必要が無いように、顧客及びセッション情報をビーン内に記憶する。（５）広告を提供する会社に関する記録を作成し、それを識別できるようにする。（６）データベース内に記憶されるべき広告、及び広告契約（１つの広告が、システム上の用途によって異なる契約を有しているかもしれないので）を作成する。（７）広告販売目的の場合は、新しい販売雇人又は雇主の契約を作成する。（８）広告及び／又は前記広告の契約を更新する。（９）広告会社を更新して、契約情報及びアドレス情報を変更する。（１０）販売雇人及び雇主の契約を更新する。（１１）アクティブリスト内に広告を配置する／アクティブリストから広告を除去する。（１２）外部情報に基づいて、広告契約が完了しているか又は未完了であるかをマークする。（１３）広告のタイプに基づき、アクティブな広告のリストを表示する。（１４）非アクティブかアクティブか、未完了であるか完了しているか、又は単に全部広告かという基準に基づいて、会社に関係している広告リストを表示する。（１５）上記基準に基づいて、広告に関係している契約のリストを表示する。（１６）上記基準に基づいて、販売雇人に関係している契約リストを表示する。（１７）単に独自の識別子を通過させることにより、雇人、会社、広告又は広告契約の完成リストを検索する。（１８）雇人、会社、広告及び広告契約イグジスタンツの近似ストリング整合を求めて、データベースを探索する。（１９）特定の契約で会社に支払った受け渡しの経緯を保持し、傑出した会社のバランスを更新できるようにする。（２０）データの完全性に関するエラーが確実に存在しないようにするために、更新ログを探索する。（２１）特定ジャンルに関する広告を記憶するのに必要な上演リストを作成及び変更する。
【００２６】
これらのオペレーションそれぞれを実行するのに、多種多様な方法を用いることができる。広告オペレーションについては、図３６に関連して更に説明する。広告サブシステム１２０は、識別、セッション、ユーザー及び支払いプロトコルに関係する追加の機能を実行することができる。本明細書で開示されている広告技術は、従来型のパーソナルコンピュータ（ＰＣ）インタフェースウェブ接続を使って利用することもできる。
【００２７】
顧客管理サブシステム１３０は、ユーザー及びユーザーの音声ポータル１０の利用に関係する情報の管理を調整する。ある代表的な実施例では、顧客管理サブシステム１３０は、ユーザーインタフェース１１０、広告サブシステム１２０及び音声ポータル１０の他の機能によって選択的に利用される、嗜好及び人口統計のようなユーザーに関する情報を取得する。顧客管理サブシステム１３０は、識別、セッション、ユーザー及び支払いプロトコルに関係する追加の機能を実行することができる。サブシステム１１０、１２０、１３０は別々に記述されているが、それぞれのオペレーションは、本発明の原理から逸脱することなく、単一ユニットに統合することができる。
【００２８】
ユーザーインタフェース（ＵＩ）１１０と顧客管理サブシステム１３０は、垂直ドメインの選択とインターネットベースの情報へのアクセスを提供するために対話する。垂直ドメインは、様々な分野又は領域を類別し、ユーザーはそこから音声ポータル１０内で選択することができる。ＵＩ１１０がユーザーと効果的に通信するためには、一定の嗜好とユーザーに関する事実が、確認され、受動的にしろ能動的にしろ理解されねばならない。顧客管理サブシステム１３０は、そのような情報をデータベース１７０に記憶する。代わりに、個々の顧客のデータベースがそのような情報を保持することもできる。
【００２９】
顧客管理サブシステム１３０は、顧客の嗜好及び事実を判定するのに必要な情報をＵＩ１１０から取得する。ＵＩ１１０は、データを顧客管理サブシステム１３０へ送り、顧客管理サブシステム１３０はそれを処理して、それを少なくとも１つのデータベースへ中継する。更に構文解析するために、イグジスタンツサブシステム１４０内の嗜好の更新が行われる。その後、イグジスタンツサブシステム１４０は、ユーザーの嗜好及び事実のような情報をＵＩ１１０へ送り返す。
【００３０】
顧客管理サブシステム１３０は、応答時間をそれほど長くすることなく、修正可能であり、拡張可能であり好都合である。そのため、新しい垂直ドメインを音声ポータル１１０に加えるプロセスは迅速で、安定している。常に新しい垂直ドメインを加えることができるので、顧客の事実及び人口統計上のタイプを完全に定義することはできない。
【００３１】
顧客管理サブシステム１３０は、ユーザーによってなされた、データベースを通して契約され、契約解除された全取引を記録する。更に、顧客管理サブシステム１３０は、ユーザーが構成された履歴リスト内に配置しているアイテムを記録し、ユーザーが（ウェブサイト上やＷＡＰ装置を通じて）閲覧したコレクションを追跡する。
【００３２】
顧客管理サブシステム１３０は、契約済みの顧客を、可能なとき何時でも、可能な限り受動的に識別する。従って、顧客の認識は、例えば、電話番号及びシステム加入のＩＤ（「ＰＩＮ」）のようなある種の識別キーを通して行うのが望ましい。この識別は、顧客に関連した一定の嗜好、及び嗜好の各セット内での顧客の経験レベルに繋がることが望ましい。更に、本システムは、購入を正式に認可する前に、追加の識別のレベル（例えば、パスワードの識別）が、記憶されているクレジットカード情報に対して作られるようにする。
【００３３】
顧客管理サブシステム１３０は、各垂直ドメイン内に一式の嗜好を保持して、音声ポータル１０経由でのユーザー対話をやり易くする。例えば、ある代表的な実施例では、顧客管理サブシステム１３０は、どのタイプの広告を顧客に提供するか、どのように顧客のサービスを向上させるか決定するのを助けるために、顧客から情報を収集する。顧客管理サブシステム１３０は、それぞれサポートされているドメインに適切な顧客の嗜好を維持し、顧客データをデータソースから動的にに更新する。例えば、関心対象のオークションドメインでは、現在のビット状況は、ユーザーの要求で更新される。音声ポータル１０は、そのドメインに適切な通貨によってデータをユーザーに示すので、好都合である。例えば、関心対象のオークションドメインでは、ビットは数秒以内で常に最新状態にある。関心対象のｅコマースドメインでは、価格付け情報は、購入価格が示されている時点の最新のものである。
【００３４】
顧客管理サブシステム１３０は、どのユーザーがどのサービスにアクセスしているかを判定できるように、報告と分析を提供するので好都合である。更に、顧客管理サブシステム１３０は、例えば、一定の収入グループ、性別、又は年齢層からのユーザーによってアクセスされるのはどのサービスかを判定するような、異なる人口統計学上のセグメントによるセッション及び取引の履歴に関する報告を提供する。更に、顧客管理サブシステム１３０は、実際の利用に基づいて、関連の報告を提供する（例えば、映画に関心のあるユーザーによりアクセスされているのは、他のどのサービスであるかを報告する能力）。
【００３５】
１つのプラットフォームからもう１つのプラットフォームへ（例えば、電話からウェブへ、電話からＷＡＰへ）継続して価値を追加しユーザーと共に移行するために、顧客管理サブシステム１３０は、個人に合わせた特性をサポートし、顧客の経験をサービスによって向上させるので好都合である。個人化に加えて、他の「スティッキネス」（競争の点で顧客はサービスと「スティッキング」している）のソースは、共通の関心対象に関して友人又は家族のネットワークのようなコミュニティ特性のサポートを含んでいる。従って、個人化特性及びコミュニティ特性が、顧客管理サブシステム１３０と共に含まれているとすれば、顧客は、特定のサービスプロバイダにより忠実であろうとする。
【００３６】
サービス（又は広告）の、顧客の行動への適用をサポートするため、顧客管理サブシステム１３０は、サービスの利用を追跡するので好都合である。更に、インタフェース評価の領域では、インタフェース階層の典型的なユーザー探査が、問題領域か又は非常に有用な領域か、或いは、単一セッション内の副次的特徴の相関関係にあるセットかの識別を助ける。音声ポータル１０のサービスの重要な属性のもう１つの例はタイミングである。例えば、「バージ・イン」（ユーザーは、リスト又はプロンプトが終了する前に、回答することで中断することができる）の利用は、より進んだユーザーを示すことができ、特定のユーザーに対して繰り返される単一のサブツリーへのバージ・イン選択のストリングは、顧客管理サブシステム１３０により感知され、全体的なものか、又は可能性としては顧客特定のものである、ショートカットへの機会へ繋げられる。
【００３７】
「スティッキネス」の態様は、顧客の嗜好へのサービスの適用である。このことは、非反復的「署名」又は「購入」データ入力要件のサポートにおいて顧客情報保存のような比較的簡単な特性を含むこともできるが、異なるフロントエンドにおける特定の対話のサブツリーのナビゲーションに関する嗜好、及びサービス／ベンダ順序付け又は選択に関する嗜好を含むこともできる。ベンダ嗜好又は順序付けの例として、ユーザーは、「好適なベンダ」を選択して、音声ポータル１０に従って見つけた製品に関する売り手リストを２つ、即ち、安いものと好みのものとに限定することができる。
【００３８】
垂直的嗜好は、ユーザーの行動に基づいて受動的に設定されるべきである。即ち、受動的な嗜好は、特定の属性を２回以上要求した後で設定される。或いは、嗜好はダイナミックで、ユーザーの行動に基づいて変わる。ユーザーは、受動的な嗜好を全て、音声又はウェブインタフェースのどちらかを通じて設定又は再設定することによって、オーバーライドできるのが望ましい。
【００３９】
顧客管理サブシステム１３０は、株情報、天気の好み等のようなユーザーの嗜好を、マイヤフーやマイエキサイトの様な個人向けのウェブページから引き出すことができる。個人向けのウェブページは、従来のインターネット接続経由でユーザーが先に作成しておくことができる。代わりに、個人向けウェブページは、ユーザーの音声コマンドに応えて、顧客管理サブシステム１３０が構築することもできる。これらのページは、次に音声ポータル１０と共に用いられるように翻訳することができる。特定の垂直的嗜好又は最近の呼び出し嗜好が存在しない場合、好都合に、一般的な嗜好をデフォルト時嗜好として用いることができる。
【００４０】
以下は、代表的な垂直的嗜好要件のリストとその説明である。それぞれの嗜好は、各インタフェースを通して別々に用いられる。ある代表的な実施例では、天気に対する嗜好のみが、顧客が要求する位置に関する天気である。デフォルトにより、ユーザーの位置はそのＺＩＰコードである。最も一般的に用いられている位置は、利用可能であれば、最近の呼び出し位置によってオーバーライドすることができる。
【００４１】
関心対象のスポーツドメインでは、閲覧すべき異なる嗜好が幾つかある。あるスポーツのスコア、スケジュール、成績をユーザーに送ることもできる。ウェブサイトについては、排他的に、あるスポーツの広告及び情報を送らないように使うこともできる。例えば、あるユーザーは、ホッケーの試合の情報は聞きたくないが、野球の情報は欲しいかもしれない。第２に、あるチームが他よりも好まれるにつれて、嗜好の細分化を高めることができる。これらの細分化されたそれぞれで、限定された選択の最新使用（ＭＲＵ）リストを用いて嗜好リストを決定することもできる。更に、スポーツ及びチームの嗜好のタイプ、好みのイベントを用いてもよい。
【００４２】
関心対象の映画ドメインでは、必要な嗜好には、顧客の地域性及び映画館の地域性、映画のタイプ（例えばスリラー、ホラー、アクションなど）、映画の格付け（ＡＡ，Ｇ，Ｒなど）、顧客のお気に入りの映画俳優／映画女優が出演する映画が含まれている。これらの嗜好のそれぞれは、限定された選択であるＭＲＵリストに挙げらている。
【００４３】
関心対象の交通ドメインでは、利用される主な嗜好は、属性として時間を備えている、ユーザーが目的地に到達するのに利用したい特定のルートである（最新のものはデフォルト値）。従って、限られたルートのＭＲＵリストは、顧客の嗜好リストを構成することができる。
【００４４】
ある代表的な実施例では、関心対象の株ドメインに関する嗜好について２レベルの階層がある。先ず、マーケットリストに対する嗜好があり、次に各マーケット内で、見るべき株や指数の嗜好がある。又、マーケット及び株のＴＢＤ選択のＭＲＵリストは一覧表にしてもよい。関心対象のその他の垂直ドメインには、レストラン、コンサート、ライブイベント、タクシー、飛行機の予約が含まれる。
【００４５】
図２に示すように、イグジスタンツサブシステム１４０は、ユーザーインタフェース１１０、広告サブシステム１２０、顧客管理サブシステム１３０、フュージョンエンジン１５０及び更新エンジン１６０による、データベース１７０へのアクセスを調整する。イグジスタンツサブシステム１４０は、データベース１７０内に含まれるデータ構造の作成、適用及び操作を管理する。データベース１７０内に含まれるデータは、更新エンジン１６０によってインターネットソースから集められる。ある代表的な実施例では、データベース１９０内で利用されるデータ構造は、「イグジスタンツ」又はシングの階層、それらの関係、及びお互いの関連性に基づいている。データベース１７０は、イグジスタンツサブシステム１４０とだけ対話するので、データベース１７０内の情報を複製及び修正する機能は、容易に実行される。イグジスタンツ及びそれらの作成は、図４−１０に関連して更に説明することとする。具体的に、イグジスタンツに関するある代表的なデータ構造モデルを、図４−６に関連して説明するが、イグジスタンツに関しては、様々な別の構造を利用することもできる。イグジスタンツの作成及び更新は、図７−１０に関連して説明されている。
【００４６】
フュージョンエンジン１５０は、２つのイグジスタンツが同じか否かを判断して、同じならそれらのイグジスタンツを融合させ、第３の基準イグジスタンツを形成する。このように、フュージョンエンジン１５０は、１つのソースから集められた情報が、他のソースから集められた情報に関係しているか、又は同じであるかをはっきりさせる。フュージョンエンジン１５０の機能は、図２５、２６、２７に関連して説明することとする。
【００４７】
更新エンジン１６０は、データベース１７０内に含まれている情報及び属性を更新するため、インターネットから情報を検索する。ある代表的な実施例では、更新エンジン１６０は、データベース１７０内の情報を更新するために、インターネットから情報を検索する「スパイダ」を利用する。更新エンジン１６０のオペレーションは、図７及び８に関連して更に説明することとする。
【００４８】
データベース１７０は、顧客データ、広告情報、製品及びサービス情報のような、音声ポータル１０によって利用される情報を記憶する。データベース１７０内の情報は、イグジスタンツ、イグジスタンツの属性、イグジスタンツの関係、イグジスタンツの結びつきの中に記憶される。イグジスタンツとはどういうものか、イグジスタンツはどのように形成されるのか、イグジスタンツは互いにどのように関係しているのか、イグジスタンツは音声ポータル１０の機能性とどのように関係しているのか、ということについては、以下に説明することとする。別の実施例では、複数のデータベースが、顧客データ、広告情報及びオペレーションの記録などの特定のタイプの情報に用いられる。
【００４９】
図３は、音声ポータル１０の代表的な物理的配置を示している。これらの物理的構造は、単なる例示である。図示のものと組み合わせて、或いは、図示の代わりに、他の構造を用いてもよい。ある代表的な実施例では、音声ポータル１０には、フロントエンドサーバー２１０と、フロントツーバックネットワーク２２０と、バックエンドサーバー２３０と、バックエンドネットワーク２４０が含まれている。ユーザーは、電話を通して、フロントツーバックネットワーク２２０によってバックエンドサーバー２３０に連結されている、フロントエンドサーバー２１０と通信する。
【００５０】
ある代表的な実施例では、バックエンドサーバー２３０は、プロキシマネジャー２４５と、プロキシ２５０と、ビーン２６０と、データベース２７０を含んでいる。プロキシマネジャー２４５は、フロントツーバックネットワーク２２０を通して、フロントエンドサーバー２１０の１つからの情報に対する要求を受信する。プロキシマネジャー２４５は、バックエンドネットワーク２４０を通して通信し、各プロキシマネジャー２４５のワークロードレベルを判定する。一旦適切なプロキシマネジャー２４５が決定されると、適切なプロキシマネジャー２４５は、自由なプロシキのプール２５０から自由なプロキシを引き出して、そのプロキシをビーン２６０へ割り当てる。ビーン２６０は、情報を検索し、情報を挿入し、イグジステンツ又はイグジステンツの関係を探索し、又はデータベース２７０に関して可能な他の機能を実行するために、データベース２７０と関連付けられている。
【００５１】
図３と関連して説明されているバーチャルデータベース構造は、インターネット２０から手に入れた情報を、時間的にも技術的にも実用的な方法で音声ポータル１０のユーザーに送るように設計されている。人々は、様々な設定と方法で、情報を必要とし利用するので、好都合に、音声ポータル１０が、限定するわけではないが、電話（例えば、音声、ＷＡＰ及びその両方）、ウェブ及び携帯可能に接続された計算装置（例えば、Ｐａｌｍ（Ｒ）ＯＳデバイス、ＷｉｎＣＥ（Ｒ）デバイス、ＲＩＭページャー）を含む様々なプラットフォーム上でこれをサポートする。
【００５２】
バックエンドサーバー２３０は、データの収集及びフュージョン（融合）を含む様々な特徴を備えたデータベースサービスサポートを含んでいる。データ収集は、図７及び８と関連して説明されているように、特定のアイテムタイプ及び／又はサイトに対してスケジュールされている定期的なインターバルで、インターネットソースからデータを蓄積することを含んでいる。音声ポータル１０は、図９及び１０と関連して説明されているように、データソースサイトへの変更を感知し、適切なサイトルールマネジャーに通知する。図９及び１０と関連して説明されているように、音声ポータル１０は、更に、データソースに対して、データ抽出の一般的な定義をサポートする。
【００５３】
音声ポータル１０は、「フュージョン（融合）」のプロセスで、異なるインターネットベンダからの同じアイテムを識別する。フュージョンプロセスの間、音声ポータル１０は、全情報のソースに関するメタデータを保持する。メタデータはデータに関するデータを含んでいる。例えば、メタデータは、データ要素又は属性（名称、規模、データのタイプなど）に関するデータ、記録又はデータ構造（長さ、分野、コラムなど）に関するデータ、データに関するデータ（どこに配置されているか、どのように関連付けられているか、所有権など）に関する資料である。更に、必然性が自動的に決定されない場合、音声ポータル１０は、非専門家によるフュージョン決定又は非決定の対話的明確化をサポートする。音声ポータル１０は、更に、コード変更なしで、新しいデータのタイプ及びデータ要素を追加することをサポートする。更に、音声ポータル１０は、マーケット調査、試験及び機会を通して識別された相関性のドメイン特定の概念をサポートする。例えば、関心対象のｅコマースドメインでは、安くて、良質で、一緒に買うことが多くて、最も人気があるのは、重要な相関性の概念である。関心対象の映画ドメインでは、関係する映画及び製品、及び、あるカテゴリーでベストの映画、最も人気のある映画、なつかしのベスト映画、役者によるベスト映画は、重要な相関性概念である。音声ポータル１０は、アイテム（例えば製品説明）についての詳細事項を追加するのに必要な関連情報を集めて保持する。フュージョンのオペレーション及び機能性は、図２５−２７と関連して更に説明することとする。
【００５４】
図４は、音声ポータル１０のデータベース１７０に用いられている代表的なデータ構造モデル３００を示しており、その中で、「イグジスタンツ」（又はシング）は属性、アソシエーション、及び関係を与えられる。イグジスタンツ同士の「継承」関係は、先端に三角形が付いた実線で示されている。イグジスタンツ同士の「アソシエーション」関係は、先端が開いた矢印の点線で示されている。継承関係を例にとると、データ構造モデル３００では、ブロック３１０は「イベント」である。「イベント」は「イグジスタンツ」又はシングであり、ブロック３２０へ向かう三角形先端の矢印３１５で示されている。同様に「映画上映」（ブロック３３０）は「イベント」（ブロック３１０）であり、三角形先端矢印３３５で示されている。アソシエーション関係の例では、イベントは「行為地」と関連付けられており、ブロック３４０へ向かう先端が開いた矢印３４５で示されている。同様に、映画上映（ブロック３３０）は、先端が開いた矢印３５５で示すように、「映画パッケージ」（ブロック３３０）と関連付けられている。イベントは、スポーツイベント、ドラマ、コンサート、喜劇、花火大会、ダンス大会又は他の活動であってもよい。
【００５５】
データ構造モデル３００は、図４に示すようにもっと多くのイグジスタンツ、アソシエーション及び関係を含んでいるが、ここでは説明しない。更に、データ構造モデル３００は、この他にも図面に含まれていないイグジスタンツ、アソシエーション及び関係を含んでいる。図４は、説明のためだけのものである。
【００５６】
図５には、代表的なデータ構造モデル４００が示されており、ユーザー又は顧客オブジェクトと別の垂直クラスとの間のオブジェクト指向関係が提示されている。継承及びアソシエーション関係の説明は、図４に関連して説明したデータ構造モデル３００の説明と同じである。ある代表的実施例では、データ構造モデル４００内に配置されるユーザー情報は、データベース１７０内に含まれている。しかし、別の実施例では、そのようなユーザー情報は、個別の顧客データベースに含まれている。
【００５７】
顧客はイグジスタンツ（顧客イグジスタンツブロック４０２）であり、階層内で最高レベル直下の子孫、即ち「イグジスタンツ」イグジスタンツであり、従って、その全特性を受け継いでいる。この構造の背後にある理由は、データベース１７０及びその方法は既に作成され、構造はコードを再利用できるようになっていることである。
【００５８】
顧客オブジェクトは様々な情報の断片を含んでいる。総体的な嗜好クラスは、「交通」、「天気」及び「映画」のような嗜好に関する情報を含んでいる。顧客が関心対象の新しい別の垂直ドメインに参入する度に、垂直ドメインの名称に対する嗜好オブジェクトのインスタンスが作成され、嗜好データが挿入される。垂直ドメインが既に存在している場合、オブジェクトは、更新された情報によって修正される。
【００５９】
セッションクラスは、ユーザーのセッション（セッションブロック４０４）に関する情報を直接記録する。セッションは、呼び出しであってもよいし、ウェブサイトを通しての探索であってもよいし、ＷＡＰを用いる呼び出しであってもよい。日時及び期間のようなデータは一般的な属性であるが、ユーザーが固定電話から呼び出したか携帯電話から呼び出したかについての分析は、電話セッションに特定的なことである。このタイプのデータは、音声ポータル１０が（広告目的で）マーケティングを誰に向けるかを決定し、性能及びサービスの両方を改良するのに有用である。同様に、顧客オブジェクトは、これらのセッションのオブジェクトそれぞれにリンクしており、（ユーザーがセッションを終了し、その特定時間に再接続したい場合）そのプラットフォームの最新のセッションは何であったかを判定する。
【００６０】
電話セッションブロック４０８は、ポータル１０との通信に電話が用いられる通信セッションに関係する情報を記録する。電話セッションブロック４０８は、現在の対話のレベル、現在の関心対象のドメイン、インタフェースプラットフォ−ムのタイプ（例えばＷＷＷ、ＷＡＰ、ＡＳＲ）、閲覧した前回のレベルなどの情報を含んでいる。電話セッションブロック４０８は、ユーザーが、前回のセッションで止めたセッション又は中断したセッションに再参加できるようにするので好都合である。クレジットカード情報イグジスタンツ、場所イグジスタンツ、嗜好イグジスタンツのような他のイグジスタンツブロックは、関連した属性を含んでおり、必要に応じて情報を記録する。
【００６１】
専門技術クラス（専門技術ブロック４０６）は、異なるプラットフォーム（即ち、電話、ＷＡＰ、ＷＷＷ）を通して（総体的に、且つ異なる嗜好に対して）異なるレベルの使用適性を維持するという目的を果たす。顧客は、これらのクラスインスタンスのそれぞれにリンクしている。これらは、嗜好はプラットフォームを横断できるのに対してユーザーの機能はできないので、嗜好クラスには含まれない。
【００６２】
図６は、広告に関係した情報用の、音声ポータル１１０のデータベース１７０で用いられる代表的なデータ構造モデル４５０を示している。継承及びアソシエーション関係の説明は、図４のデータ構造モデル３００の説明と同じである。ある代表的な実施例では、データ構造モデル４５０内に配置された広告情報は、データベース１７０に含まれる。しかし、別実施例では、そのような広告情報は、個別の広告データベース内に含まれている。
【００６３】
データ構造モデル３００、４００、４５０は、イグジスタンツ、アソシエーション及び関係に関する情報の配置を連続して拡大するので好都合である。更に、モデル３００、４００、４５０は、迅速に、且つ先に入力されている情報を変更することなく、関心対象の新しい垂直ドメインの作成に配慮している。例えば、モデル３００は、本、玩具及び電子機器のような商品に関係した情報と同時に、映画及びコンサートのようなイベントに関係した情報も含んでいる。バレエのようなどんなイベントでも、「イベント」との継承関係及び適切なアソシエーション関係を有するイグジスタンツとして容易に加えることができる。同様に、車両のようなどんな商品でも、「製造済みのアイテム」との継承関係及び適切なアソシエーション関係を有するイグジスタンツとして容易に加えることができる。データ構造モデル３００、４００、４５０の動的な性質及び発展的な能力は、音声ポータル１０に、インターネットベースの情報及びサービスの広い範囲に対して統一されたポータルであるという利点を与える。
【００６４】
図７は、代表的なデータ構造モデル３００（図４）、データ構造モデル４００（図５）、データ構造モデル４５０（図６）に示されているイグジスタンツのようなイグジスタンツの代表的な作成プロセスのフローチャート７００を示している。ステップ７１０では、インターネット上のウェブページが見つけ出される。代表的な実施例では、所定のアイテムのカテゴリに関係している特定のウェブページを見つけ出すのに、スパイダが用いられる。スパイダは、文書を検索し、その中で引用されている幾つかの又は全ての文書を反復的に検索することにより、ワールドワイドウェブ（ＷＷＷ）を自動的に探査する従来式の既知のプログラムである。それに対し、人間によって操作される通常のウェブブラウザは、インライン画像及びＵＲＬリダイレクション以外のリンクに自動的に従うことはない。ステップ７１０が実行された後ステップ７２０が実行されるが、そこで情報は、ページをオーバーレイして特定の情報を濾過する選択されたフォームを用いて、見つけ出されたウェブページ上で識別される。ステップ７２０の後ステップ７３０が実行されるが、そこでは、ステップ７２０でのフォームオーバーレイによって検索された情報から特徴的な情報又は属性を識別するのに、ルールが利用される。特徴的な情報又は属性は、イグジスタンツが何であるかを定義する。ルールは、イグジスタンツ属性の構成を定義する。例えば、映画イグジスタンツは、タイトル、ディレクター、出演者、封切り年、あらすじという属性を含んでいる。
【００６５】
ステップ７３０が実行された後ステップ７４０が実行されるが、そこでは、属性はイグジスタンツ内で編成され、イグジスタンツはデータベース１７０内に記憶される。イグジスタンツ内での属性の編成と配置は、予め定義されたルールによって組み立てられる。
【００６６】
図８は、図７と関連して述べられているイグジスタンツの代表的な作成プロセスを示している。スパイダ８１０は、様々な異なるウェブページに記憶されている情報を求めてインターネット２０を点検する。スパイダ８１０によって検索された情報は、その情報をデータ構造８３０内に入れるために、ルール８２０に従って編成され配列される。ある代表的な実施例では、スパイダ８１０は、インターネット２０から映画に関する情報を検索する。例えば、スパイダ８１０はＩＭＤＢウェブサイトを点検して、特定の映画のタイトル、ディレクター、出演者、封切り年、上映時間に関する情報を検索してもよい。一旦映画情報がデータ構造８３０内に記憶されると、データ構造８３０は、辞書テーブル８４０に適用される。辞書テーブル８４０は、データ構造８３０内に含まれる属性を編成し、情報を３つの列に配置する。ある代表的な実施例では、辞書テーブル８４０の第１列はオリジナルデータを含んでおり、第２列は正規化されたタグ付きのフォーマットのオリジナルデータを含んでおり、第３列は探索可能でマッシュされたフォーマットのデータを含んでいる。辞書テーブル８４０とデータ構造８３０は、データベース１７０内のメモリ構造内に備えられている。
【００６７】
例えばスパイダ８１０が映画「レイダース、失われたアーク」に関係する情報を求めてインターネット２０を点検する場合、インターネット２０から検索されたデータは、映画に対応するルールに対して適用され、データ構造８３０内に配置されることになる。そのような映画のルールは、タイトル、ディレクター、出演者、封切り年を含んでおり、全てが映画の属性である。この例では、タイトルは「レイダース、失われたアーク」で、ディレクターは「スティーブン・スピルバーグ」で、出演者は「ハリソン・フォードとカレン・アレン」で、封切り年は「１９８１年」で、上映時間は「１１５分」である。従って、辞書テーブル８４０には、タイトルが、オリジナルフォーマットでは「Ｒａｉｄｅｒｓ　ｏｆ　ｔｈｅ　Ｌｏｓｔ　Ａｒｋ」で、正規化されたタグ付きフォーマットでは＜ｔｉｔｌｅ＞Ｒａｉｄｅｒｓ　ｏｆ　ｔｈｅ　Ｌｏｓｔ　Ａｒｋ＜／ｔｉｔｌｅ＞で、探索可能でマッシュされたフォーマットでは、スペースや識別冠詞（例えば、ｔｈｅ、ａ、ａｎ）を入れずにＲａｉｄｅｒｓＬｏｓｔＡｒｋで含まれることになる。
【００６８】
図９は、非プログラミング手段を使ってインターネットベースの情報を集める代表的なプロセスを示すフローチャート９００である。ステップ９１０では、探索ページが見つけ出され、パターンを使って関連情報を含んでいる前記ページ上の領域が分離される。ステップ９１０が実行された後ステップ９２０が実行されるが、そこでは適切なフォームが見つけ出され、特定のルーチンが呼び出されて実際のデータと情報が抽出される。ステップ９２０の後ステップ９３０が実行され、ここでは特定のページが与えられれば、関係情報を備えた複数のページが見つけ出される。データ特定のパターンとは別に、データ特定のパターンが特定のページ内のどこで作用するかを定義する領域パターンがある。ステップ９３０が実行された後ステップ９４０は実行され、複数のページ上の製品又はサービスを更にリストするためのリンクが見つけ出される。ある代表的な実施例では、予測ルーチンを使って、コードサンプルから製品リスティングする実際のパターンを計算する。
【００６９】
一般的に、予測ルーチンは、ルールライターによって与えられる所望の出力からパターンを計算する。ルールライターは、それを生じさせるためにパターンを開発する必要無しに、単に、抽出したいテキストフラグメントをＨＴＭＬコードからペーストしなければならないだけなので、パターン予測ルーチンは、生産の速度を上げ、好都合である。パターンを書き込むのに現在用いられている入力フィールドは、このデータを挿入するのに用いられる。
【００７０】
例を挙げると、予測ルーチンは、先ずルールライターにウェブページ上のサンプル著者名を著者フィールドにコピーさせることによって、本に関するデータを与えているウェブページ用の著者データのパターンを開発する。その後アルゴリズムは、サンプルデータをウェブページ上のその位置へ合わせる。照合されたデータに近接する文字又はタグは、「接頭部」及び「接尾部」として識別される。接頭部は、照合されたデータの前の文字であり、接尾部は照合されたデータの後の文字である。接頭部及び接尾部は、パターンを構成するのに用いられる。
【００７１】
構成されたパターンは、別のデータと照合させるためにウェブページに適用される。構成されたパターンが、所望の結果と異なるデータを取り上げる場合、更に完全で正確なパターンを求めて、パターンを開発するために用いられる接頭部及び接尾部が加えられる。パターンを改良するため、この手順が繰り返される。
【００７２】
この例を更に明らかにするために、本に製品データを与えているウェブページから以下のＨＴＭＬコードを取り上げる。
【００７３】

【００７４】
ルールライターは、著者フィールド内の「Ｌａｒｒｙ　Ｗａｌｌ」をダンプして、これは著者を抽出するためのデータであることを示す。
【００７５】
パターン予測アルゴリズムは、おおよそ以下のように作用する。

【００７６】
１ページ目をｎ＝１で開始すると、アルゴリズムは、＄ｐｒｅｆｉｘは値「＞」を取り＄ｓｕｆｆｉｘは値「＜」を取ることを意味する「＞Ｌａｒｒｙ　Ｗａｌｌ＜」とマッチする。次に、パターン予測アルゴリズムは、第１ステップから得た＄１及び＄２の値を使って、パターン「＞（．＊？）＜」を構築する。このパターンを、ウェブページに対してマッチさせると、所望の結果「Ｌａｒｒｙ　Ｗａｌｌ」とは異なる「＞Ｐｒｏｇｒａｍｍｉｎｇ　Ｐｅｒｌ＜」という結果になる。従って、ｎがｎ＝２に増加され、パターンは、接頭部及び接尾部に別の文字を含むように改良される。ウェブページを「（｛．｝２）Ｌａｒｒｙ＼ｓ＋Ｗａｌｌ（｛．｝２）」とマッチさせると、＄ｐｒｅｆｉｘは値「ｂ＞」を取り、＄ｓｕｆｆｉｘは値「＜／」を取ることを意味する「ｂ＞Ｌａｒｒｙ　Ｗａｌｌ＜／」となる。次に、パターン予測アルゴリズムは、第１ステップから得た＄１及び＄２の値を使って、パターン「ｂ＞（．＊？）＜／」を構築する。このパターンを、ウェブページに対してマッチさせると、所望の出力である「Ｌａｒｒｙ　Ｗａｌｌ」という結果になる。
【００７７】
次に、ルールライターがウェブページを通して異なるページに同じパターンを適用するときに、彼又は彼女は、そのパターンが、本「Ｌｅａｒｉｎｇ　Ｐｅｒｌ」に関するページの「第２版」とマッチすることを発見する。次にルールライターは、第２例となる望ましい結果を与えてアルゴリズムを改良し（即ち、彼又は彼女は、「Ｒａｎｄａｌ　Ｓｃｈｗａｒｔｚ」をＧＵＩ入力フィールドへダンプする）、そのことがパターン予測アルゴリズムのトリガとなって、＜ｂ＞の前に「ｙ」を強要するパターンが作成されるまで、更にｎを増やす。アルゴリズムは、必要なウェブデータ及び必要なパターンの複雑さ次第で、幾つかの対話を実行する。
【００７８】
ステップ９４０が実行された後ステップ９５０が実行され、ベンダ特定データ抽出ファイルが作成される。ある代表的な実施例では、コードサンプルから関連ＵＲＬを計算するルーチンが用いられる。代わりに、ＵＲＬを計算するルーチンをフォームとして送ってもよい。ステップ９５０が実行された後ステップ９６０が実行され、キャッシュが作成される。ステップ９６０が実行された後ステップ９７０が実行され、製品データの抽出のためのパターンが作成される。ある好適な実施例では、回帰テスト機構が特別なルーチンの編集をサポートする。
【００７９】
図１０は、音声ポータル１０に関連するルールの非プログラミング開発に関する代表的なプロセスを示している。この代表的なプロセスでは、一式のルールライター１０１０の内の１つのルールライターは、データソース１０３０、データソース１０３５、データソース１０４０、又はＷＷＷ１０２０と接続されている他のデータソースの内の何れかからの情報にアクセスするために、ワールドワイドウェブ（「ＷＷＷ」）１０２０にアクセスする。データソースから検索されたデータは、データ編成ツール１０２５を用いてデータ構造に配置される。ルールライター１０１０は、データ編成ツール１０２５を使って、多数の可能なフォームの内の１つを、ＷＷＷ１０２０を通して入手可能な情報の「ページ」へ適用する。そのようなフォームは、ページ上に関連情報の位置を提示し何らかの特徴的なタグを付けて表示される。例えば、ＷＷＷ１０２０上に提供されたページは、ページの左上隅にデータ入力ボックスを含んでいる。更に、部品又はサービスの関連情報は、本のタイトルに対しては「＜ｔｉｔｌｅ＞」のようにＨＴＭＬタグの後に配置される。
【００８０】
なお、ここで用いる「ページ」という用語は、データ、メッセージ、レポート等の図式又はテキスト表示を提供するスクリーンのような、診断システムのユーザーが見ることのできる、ユーザーインタフェースのスクリーン又は同様の装置を含むものとする。更に、そのようなページは、Ｊａｖａ、Ｐｅｒｌ、Ｊａｖａ　Ｓｃｒｉｐｔのようなマークアップ言語又はプログラミング言語、或いは他の好適な言語によって定義することができる。
【００８１】
データソースからのデータは、ルールライター１０１０によってデータ編成ツール１０２５から選択されたフォームを使って、データ構造１０４５、データ構造１０５０、データ構造１０５５、又は、情報を維持するための同様の構造に編成される。データ構造１０４５、１０５０、１０５５は、比較、融合してもよいし、統合データ構造１０６０の形態で利用してもよい。統合データ構造１０６０はデータベース１０７０に記憶される。
【００８２】
図１０に示す代表的なプロセスでは、非専門ルールライター１０１０が、データ編成ツール１０２５により提供される多数のフォームから選択し、ＷＷＷ１０２０を通して入手可能な特定のウェブサイトからの情報の検索に利用できるようになっており、好都合である。このように、データソース１０３０、１０３５、１０４０からのウェブページ上に含まれているデータは、ルールライター１０１０によって選択されたフォームで、データ編成ツール１０２５を使って、データベース１０７０へ継続して更新することができる。データ構造１０４５、１０５０、１０５５内に含まれている情報は正確を期して比較されるので、データ編成ツール１０２５は、ウェブページが、それらの対応するウェブページ上でデータのフォーマット又は配列を何時変更したのかを検知する。
【００８３】
図１１−２４は、新しいルール作成のある代表的なプロセスを示している。更に、図１１−２４は、ルールライターとデータ編成ツール１０２５（図１０）との間で可能な対話を示している。１つの代表的なルールは、現存のルール、即ちｔｈｅ Ａｍａｚｏｎ．ｃｏｍ ｂｏｏｋ ｐｒｏｄｕｃｔｓに基づいている。このルール構築に用いられているステップは、他のルール構築に用いられているステップと同じである。
【００８４】
図１１は、ルール８２０（図８）の作成を開始するのに用いられるグラフィカルユーザーインタフェース（ＧＵＩ）１１１０を示している。このＧＵＩ１１１０は、ベンダーウインドウ１１２０と、スパイダー選択ウインドウ１１３０と、問合せウインドウ１１４０と、ステイタスウインドウ１１５０と、サーチボックスエリア１１６０と、コードウインドウ１１９７とを含んでいる。サーチボックスエリア１１６０は、スライダバー１１７０と、右セットの矢印１１８０と、左セットの矢印１１９０と、サーチウインドウ１１９５とを含んでいる。
【００８５】
新しいデータソースを開始するには、ルールライターは、ベンダーウインドウ１１２０内のデータソース（例えばアマゾン・ブック）に入る。ルールライターは、「Ｅｎｔｅｒ」を押し、「Ｎｅｗ」ボタンをクリックする。この動作が実行されると、図１２に示すグラフィカルユーザーインタフェース（ＧＵＩ）１２００が表れる。ルールライターは、データソースが正しくリストアップされていることを確かめた後、「Ｄｏｎｅ」ボタンをクリックする。次に、図１３に示すグラフィカルユーザーインタフェース（ＧＵＩ）１３００が表れる。選択されたベンダー名に対応するＵＲＬが表示される。ルールライターは、正しいＵＲＬを確認するよう求められる。アマゾン・ブックの例では、ＧＵＩのウインドウ１３００にＵＲＬ　ｈｔｔｐ：／／ｗｗｗ．ＡｍａｚｏｎＢｏｏｋ．ｃｏｍが現れる。しかし、ＵＲＬリンクは、ｈｔｔｐ：／／ｗｗｗ．ＡｍａｚｏｎＢｏｏｋ．ｃｏｍを読み取らなければならない。ルールライターはＵＲＬを訂正し、「Ｄｏｎｅ」ボタンをクリックする。
【００８６】
図１１に戻るが、ルールライターは、所望されている問合せのタイプを選択する。先ず、ルールライターは、問合せウインドウ１１４０を選択し、可能性のある問合せのリストから選ぶ。例えば、「本の包装」は、関心対象の本の垂直ドメインに関する可能性のある問合せである。この探索は、ルールライターが問合せウインドウ１１４０の「ＳＤＥ」（探索データエディタ）上のボタンをクリックすれば開始する。ＳＤＥボタンは探索データエディタを呼び出し、探索データエディタは、図１４に示すグラフィカルユーザーインタフェース（ＧＵＩ）１４００を提供する。ＧＵＩ１４００は、関心対象の特定アイテムの探索に便利な属性リストを示している。例えば、本が探索される場合、ＩＳＢＮ又はＵＰＣのような属性が示される。別のアイテムの探索である場合、そのアイテムに相当する属性がリストアップされる。「映画上映」を探索すると、映画パッケージ、時間及び封切り期日のような属性がリストアップされることになる（図４に関連して説明されているブロック３３０を参照のこと）。
【００８７】
ルールライターは、ＩＳＢＮ番号を相当するデータボックスへタイプし、「Ｄｏｎｅ」をクリックする。ＧＵＩ１４００のボタン１４３０は、ルールライターが、別の探索の間に、異なる探索基準をセーブできるようにするので好都合である。一旦探索基準が入力されると、ルールライターは「Ｄｏｎｅ」をクリックし、特定のデータソース（即ち、ＡｍａｚｏｎＢｏｏｋ）にルールが定義されていないので、図１５に示すグラフィカルユーザーインタフェース（ＧＵＩ）１５００が現れる。ＧＵＩ１５００は、ルールライターが新しいルールを追加するか、又は探索データを変更することを望んでいるかどうかをたずねる。この例では、ルールライターが「Ａｄｄ」ボタンをクリックし、ＧＵＩ１５００は拡張して、図１６に示すグラフィカルユーザーインタフェース（ＧＵＩ）１６００になる。
【００８８】
次に図１６では、ルールライターは、正しいタイプの問合せが強調表示されていることを確認する。この例では、ＩＳＢＮが強調表示され、ルールライターは「Ｙｅｓ」ボタンをクリックする。図１７に示すグラフィカルユーザーインタフェース（ＧＵＩ）１７００が現れ、アマゾン・ブックのホームページがネットスケープブラウザにロードされていることをルールライターに教える。ルールライターは、ＩＳＢＮルールに関連するウェブページをブラウズするよう指示される。一旦探索ページがインターネットブラウザにロードされると、ルールライターは「Ｄｏｎｅ」ボタンをクリックする。
【００８９】
図１８に示すグラフィカルユーザーインタフェース（ＧＵＩ）１８００は、ルールライターにより選択されるべきフォームオプションを示す。フォームが正しければ、ルールライターは「Ｄｏｎｅ」ボタンをクリックする。リストされているフォームの中に、ルールライターが必要とする選択肢がなければ、ルールライターは「Ｎｅｘｔ」ボタンをクリックして、そのページの別のフォームを見る。一旦マッチするページが見つかると、図１９に示すグラフィカルユーザーインタフェース（ＧＵＩ）１９００が表示される。
【００９０】
データ編成ツール１０２５（図１０）は、インターネットブラウザ内の結果のページを表示する。ページが正しければ、ルールライターはＧＵＩ１９００上で「ＯＫ」をクリックする。図２０に示すグラフィカルユーザーインタフェース（ＧＵＩ）２０００が現れ、探索が複数のアイテムにマッチする場合は、そのページ上の１つのアイテムをどのように検出するかを問い合わせてくる。更にＧＵＩ２０００は、問合せのアイテムについての詳細を得るのにＵＲＬの何処を探すかを示すのに用いられる。アイテムが１つしか見つからなければ、正規の表現式を構築するには情報が十分に提示されていないので、ルールライターは「Ｄｅｆｅｒ」ボタンをクリックする。複数のアイテムが見つかると、正規の表現式がデータウインドウ２０１０へ入力される。例えば、１つの著者が複数の本を書いているかもしれないので、著者探索は複数のアイテムを戻してくるかもしれない。別の場合で、問合せが１つのアイテムに合致しているだけのときでも、情報を入手するために追加のＵＲＬリンクに従うのが必要なこともある。
【００９１】
次に図２１に示すグラフィカルユーザーインタフェース（ＧＵＩ）２１００が現れ、複数の製品ページを検出するのに用いられる。ルールライターが探索されたアイテムへ直接行く場合、正規の表現式を構築するのに情報は必要ない。図１１に戻るが、コードウインドウ１１９７は、検索されたページからのＨＴＭＬコードで満たされている。この時点で、ルールライターは、属性を指定するよう準備している。属性は、正規の表現式を名前の次のボックスに入れることによって指定される。正規の表現式は、表現式の結果として、（括弧を使って）その中の１つのサブストリングを指定しなければならない。例えば、「この（全て）のマッチ」という正規の表現式は、（正規の表現式はマッチできると仮定して）その結果として「全て」を戻すことになる。例えば、本のタイトルを見つけるのに用いられるパターンを決定するには、ルールラーターは、本のタイトルを探索ウインドウ１１９５へタイプする必要がある。様々なＨＴＭＬ信号を用いることができる。「＼ｓ＊」は、単語と単語の間の可能性のあるブランクスペースを示すのに必要である。探索ウインドウ１１９５に入力された探索ストリングの第１のマッチは、ＨＴＭＬコードで見つけられた第１のマッチを強調表示するするである。例えば、タイトルは、幾つか余分な情報を備えた一対の＜ｔｉｔｌｅ＞タグの内部に見つけられる。本のタイトルの代表的な属性は、「＜ｔｉｔｌｅ＞（［＾＜］＊）＜／ｔｉｔｌｅ＞」である。一旦属性が入力されると、その属性に対する全てのマッチが見つけ出される。
【００９２】
図１４に戻るが、探索データエディタ１４００は、値をタイプ次第の属性に割り当てるのに用いられるフォームで構成されている。ステイタスウインドウは、データ編成ツール１０２５が何を行っているのかを示す。ある代表的な実施例では、ステイタスはアイドル状態で、インターネット上で問合せを実行し、キャッシュを使っている。問合せウインドウ１１４０は、ルールライターが、課題のデータソースに所望される問合せのタイプを設定し、ＳＤＥボタンを使って探索基準を設定できるようにする。
【００９３】
スパイダ選択ウインドウ１１３０は、ルールライターが、問合せ探索を行っていなければ使用すべきスパイダを設定できるようにする。ある代表的な実施例では、可能性のあるスパイダのタイプは、フル、漸増、特別及び参照である。フルスパイダは、選択されたタイプにマッチする全てのアイテムを取る。漸増スパイダは、通常、インターネットデータソースからのデータの更新をピックアップするのに用いられる。特別スパイダは、通常、本のベストセラーのような特別な、サイトが持っている何かをピックアップするのに用いられる。参照スパイダは、通常、そのサイトはまだ作動しており、ルールが作用していることを確認するのに用いられる。
【００９４】
ベンダーウインドウ１１２０は、ルールライターが、データソースを作動するよう設定できるようにする。探索ウインドウ１１９５は、ルールライターが、テキストをＨＴＭＬコードで検索できるようにする。コードウインドウ１１９７には、テキスト入力の位置を示すカーソルがある。左セットの矢印１１９０は、第１の番号を含んでおり、キャッシュから実行するときに探索が始まる開始点である。第２の番号は、キャッシュ内のページの合計数を示している。このウインドウの矢印セットは、ルールライターがキャッシュから実行する時に、開始するページを制御する。右セットの矢印１１８０は、検索されたページをスクロールする矢印を含んでいる。
【００９５】
スパイダは問合せと似ているが、どのルールも適用できない場合に呼び出される。スパイダは、指定されたタイプとマッチするウェブサイトの全オブジェクトに関する情報を集める責任を負っている。スパイダは、幾つかの入れ子ループから成り、各入れ子ループは、階層内へと１つ深いレベルへ進むように設計されている。図２２には、本のスパイダに関して代表的なスパイダ階層２２００が示されており、レベル２２１０は開始ページであり、レベル２２２０は本のカテゴリページであり、レベル２２３０は、本のサブカテゴリページであり、レベル２２４０は本のページを示す。
【００９６】
図２３に示すように、グラフィカルユーザーインタフェース（ＧＵＩ）２３００は、スパイダルールに関連付けられるページのＵＲＬを検索するのに用いられる。スパイダデプススライドルールは、ルールライターが、データ編成ツール１０２５に、実際の製品ページへ行き着くのどれほどの数のリンクが必要かを告げることができるようにする。上側境界スライドルールは、ルールライターが、スパイダに対するアイテム数の上限を指定することができるようにする。一旦ＵＲＬが選択され、スパイダデプス及び上側境界が選択されると、ルールライダーは「Ｄｏｎｅ」ボタンをクリックする。図２４に示すグラフィカルユーザーインタフェース（ＧＵＩ）２４００が現れる。ルールライターは、図１１に関連して説明した問合せに対して入力された探索パターンと同じ様式で用いるために、スパイダに探索パターンを入力する。一旦パターンが入力されると、ルールライターは、「Ｂｕｉｌｄ」ボタンをクリックし、スパイダは実行を開始する。
【００９７】
図１１−２４に関連して示し、説明したグラフィカルユーザーインタフェースは、非専門のルールライターがデータ探索を実行し、情報検索用のルールのフォームを作成することができるようにするので好都合である。一旦フォームが作成されると、そのフォームは、更新された情報を集めるのに頻繁に利用することができる。更に、フォームは、ベンダーによるウェブサイトでの情報の配列及び表示に対応する共通のフォームを使って、ベンダーのウェブサイトで入手可能な大量の情報を検索するのに役立つ。非専門家によるルール作成のフォームは、ウェブサイトで入手可能な情報を低コストで更新できるようにする。更に、このフォームは、インターネットベースの情報の正確な検索を自動化するのに好都合である。
【００９８】
図２５は、データベース内の情報を融合する代表的なプロセスを示している。図２５に示す代表的な実施例では、フローチャート２５００は、フュージョンエンジン１５０（図２）で実行される単純な融合プロセス、即ち「クイックフュージョン」を表している。ステップ２５１０では、更新エンジン１６０は、ネットワーク２０から情報を受信し、その情報を、イグジスタンツサブシステム１４０経由で、データベース１７０内のイグジスタンツデータ構造に配置する。フュージョンエンジン１５０は、イグジスタンツサブシステム１４０経由で、更新エンジン１６０からイグジスタンツへアクセスし、イグジスタンツサブシステム１４０はデータベース１７０にアクセスする。ステップ２５１０が実行された後ステップ２５１５が実行され、そこでフュージョンエンジン１５０は、ステップ２５１０で検索されたイグジスタンツに対応する属性定義テーブルから正確な融合属性を集める。ステップ２５１５が実行された後ステップ２５２０が実行され、そこでフュージョンエンジン１５０は、データベース１７０から検索されたイグジスタンツからの各融合属性の、容易に比較できるフォームへの「マッシュ」を実行する。ある代表的な実施例では、「マッシュ」フォームは、スペース、前置詞及び他の非本質的ワードを削除する。「マッシュされた」フォーマットは迅速な探索機能を提供するので好都合である。
【００９９】
ステップ２５２０が実行された後ステップ２５２５が実行され、フュージョンエンジン１５０はデータベース問合せを公式化して、そこでデータソースが「同一」に設定され、ステイタスが「標準」に設定される。この問合せは、現在の情報にマッチしている同じデータソースファイルから、すでに存在している標準イグジスタンツを見つけようとしている。ステップ２５２５が実行された後ステップ２５３０が実行され、そこで、データベース１７０でのマッチが見つかるかどうか決定される。ステップ２５２５の問合せによってデータベース１７０でのマッチが見つかれば、ステップ２５３５が実行され、そこでデータベース１７０内に含まれるイグジスタンツが更新される。
【０１００】
ステップ２５２５の問合せからデータベース１７０内にマッチが見つからなければ、ステップ２５４０が実行され、そこでステップ２５２５の問合せは再度公式化され、データソースは「同一」に設定され、ステイタスは「非標準」に設定される。この問合せは、現在の情報にマッチしている同じデータソースファイルから、すでに存在しているイグジスタンツを見つけようとしている。ステップ２５４０が実行された後ステップ２５４５が実行され、そこで、ステップ２５４０の再度公式化された問合せから、データベース１７０内でマッチが見つかるかどうか決定される。マッチが見つかれば、ステップ２５５０が実行され、そこでデータベース１７０内に含まれるイグジスタンツが更新される。
【０１０１】
データベース１７０内でマッチが見つからなければ、ステップ２５５５が実行され、そこで問合せは、データソースを「任意」に、ステイタスを「標準」に設定して再度公式化される。この問合せは、現在の情報にマッチしている何れかのデータソースから、すでに存在している標準的なイグジスタンツを見つけようとしている。ステップ２５５５が実行された後ステップ２５６０が実行され、そこで、データベース１７０内でマッチが見つかるかどうか決定される。データベース１７０内でマッチが見つからなければ、ステップ２５６５が実行され、そこでイグジスタンツがデータベース１７０に追加される。
【０１０２】
データベース１７０内でマッチが見つかるか、又はステップ２５５０が実行された後で、ステップ２５７０が実行され、そこで、マッチはシステムイグジスタンツであるかどうか決定される。マッチがシステムイグジスタンツであれば、ステップ２５７５が実行され、システムイグジスタンツが更新される。マッチがシステムイグジスタンツでなければ、ステップ２５８０が実行され、標準的なシステムイグジスタンツが形成される。ステップ２５５０が実行された後ステップ２５８５が実行され、そこでこのイグジスタンツがデータベース１７０に加えられる。ステップ２５８５が実行された後ステップ２５９０が実行され、融合テーブルが更新される。
【０１０３】
図２５に示すデータベース内の情報融合に関する代表的なプロセスは、複数のウェブサイトに情報の比較を提供する。このように、１つのウェブサイトが他のウェブサイトと同じ情報を含んでいるかどうか決定することができる。更に、音声ポータル１０のデータベース１７０内に含まれている情報は、インターネットベースのソースからの情報、関係、及びアソシエーションを継続して加えることができ、それにより、データソースから検索される情報に、より大きな利便性が提供される。
【０１０４】
図２６は、代表的な融合処理で行われるステップを描いたフローチャート２６００を示している。図２６に説明する代表的な処理では、融合処理は、図２５に関連して説明したフローチャート２５００に示す融合処理に比べ、より包括的であることが分かる。ステップ２６１０で、フュージョンエンジン１５０は、データベースから属性定義テーブルを読み出す。ステップ２６１０を実行した後ステップ２６１５が実行され、フュージョンエンジン１５０は、先行融合を要求する各イグジスタンツタイプに関しフュージョン制御言語ファイルを読み出す。ステップ２６１５を実行した後ステップ２６２０が実行され、フュージョンエンジン１５０はフュージョンファイルを中間コンピュータコードにコンパイルする。ステップ２６２０を実行した後ステップ２６２５が実行され、フュージョンエンジン１５０はこれまでに融合したイグジステンツをメモリに保持する。ステップ２６２５の後ステップ２６３０が実行され、フュージョンエンジンは属性を等価セットに収集する。ステップ２６３０の後ステップ２６３５が実行され、属性がテキスト的であるか否かを判定する。フュージョンエンジン１５０が、属性はテキスト的ではないと判定した場合は、ステップ２６４０が実行され、その値に索引をつける。フュージョンエンジン１５０が、属性はテキスト的であると判断した場合は、ステップ２６４５が実行され、フュージョンエンジン１５０は当該属性のサブストリング出現に索引をつける。
【０１０５】
ステップ２６４５の後ステップ２６５０が実行され、フュージョンエンジン１５０は、テキストが構造化されているか否かを判定する。テキストが構造化されていない場合は、ステップ２６７０が実行される。テキストが構造化されていると判定された場合、フュージョンエンジン１５０は、ステップ２６５５で、当該テキストの場所及び構造内の分離セグメントを識別する。ステップ２６５５の後ステップ２６６０が実行され、フュージョンエンジン１５０は分離部分を構文解析して意味論的情報を識別する。ステップ２６６０の後ステップ２６６５が実行され、フュージョンエンジン１５０は意味論的情報に索引づけを行う。ステップ２６６５の後ステップ２６７０が実行され、フュージョンエンジン１５０は妥当性チェックを実施し、データベース１７０の完全性を検証する。ステップ２６７０の後ステップ２６７５が実行され、フュージョンエンジン１５０はイグジスタンツを検索して融合する。
【０１０６】
ステップ２６７５の後ステップ２６８０が実行され、フュージョンエンジン１５０は、対応するイグジスタンツタイプに対しフュージョン基準及びマッチングプログラムを起動させる。フュージョン基準及びマッチングプログラムには、図１０に関連して既に説明したように確立された現存ルールを適用する。ステップ２６８０の後ステップ２６８５が実行され、フュージョンエンジン１５０はフュージョン基準及びマッチングプログラムから第１のフュージョンルールを実行してマッチしたもの全てを戻す。ステップ２６８５の後ステップ２６９０が実行され、受け入れ可能なマッチが見つかったか否かを判定する。ある代表的な実施例では、受け入れ可能なマッチとは、所定割合（例えば７０％）の属性が共通であるものとされている。別の実施例では、受け入れ可能なマッチとは、全ての属性が同じ値を有するものとなっている。受け入れ可能なマッチが見つかると、ステップ２６９７が実行され、フュージョンエンジン１５０はイグジスタンツを融合して一体化する。受け入れ可能なマッチが見つからない場合、ステップ２６９１が実行され、次のフュージョンルールを実行してマッチしたもの全てを戻す。
【０１０７】
ステップ２６９１の後ステップ２６９２が実行され、受け入れ可能なマッチが見つかったか否かを判定する。受け入れ可能なマッチが見つかった場合、ステップ２６９７が実行され、フュージョンエンジン１５０はイグジスタンツを融合して１つに纏める。イグジスタンツを融合することには、融合されるべきイグジスタンツに関連付けられ且つその中に全情報を保有している新しいイグジスタンツを作成することが含まれる。受け入れ可能なマッチが見つからなかった場合、ステップ２６９３が実行され、最後のルールを試したか否かを判定する。最後のルールを試していない場合、ステップ２６９１が再度実行される。最後のルールが試されている場合、ステップ２６９４が実行され、フュージョンエンジン１５０は、強い部分的マッチがあるか否かを判定する。ある代表的な実施例では、強い部分的マッチとは、７０％というようなある程度のパーセンテージ内にマッチがあるものとされている。強い部分的マッチが存在する場合、ステップ２６９８が実行され、差異が人的検査に委ねられる。部分的マッチが見つからない場合、ステップ２６９５が実行され、フュージョンエンジン１５０がフュージョンの作成を拒否し、ステップ２６９９が実行され、新しいイグジスタンツが作成される。
【０１０８】
図２６に示すデータベース内の代表的な情報融合処理では、同一又は異なるデータソースからの情報を自動的に比較でき好都合である。このように、データベース１７０に保有されている情報は、継続的に更新され、他のデータソースからの情報に対する関連性を付与されることになる。更に、フュージョンは、インターネット上で個別的に利用できる何百万ものデータベースよりも完全且つ頑丈に一体化したデータベースのコンパイルを配慮している。
【０１０９】
図２７は、２つのデータ構造から標準データ構造を作成する代表的処理を示している。データフィル２７００は、固有識別番号により識別され、第１のデータファイル２７１０、第２のデータファイル２７２０、及び標準データファイル２７３０を保有している。ある代表的な実施例では、第１のデータファイル２７１０は、ＩＭＤＢ（「インターネット映画データベース」）ウェブサイト（ｈｔｔｐ：／／ｗｗｗ．ＩＭＤＢ．ｃｏｍ）から検索した特定の映画に関係する情報を保有している。第２のデータファイル２７２０は、Ｒｅｅｌ．ｃｏｍウェブサイトから得た特定の映画に関する情報を含んでいる。図２７に示す例では、データファイル２７１０には、タイトル「ザ・ボーイズ・オブ・アリゾナ」、ディレクター「ウィルツ」、放映年「１９９７年」、粗筋「素晴らしい映画」が含まれている。同様に、データファイル２７２０では、タイトル「ボーイズ・オブ・アリゾナ」、ディレクター「ボブ・ウィルツ」、放映年「１９９８年」となっているが、粗筋は空欄である。
【０１１０】
標準データファイル作成処理に際しては、特定のタイプの情報についてのルールが入っているルールファイル２７４０が導入される。図２７の例では、ルールファイル２７４０には映画の属性に関する情報が入っている。ルール２７４０を適用すると、データファイル２７１０とデータファイル２７２０から最も完全なタイトル、即ちここではデータファイル２７１０のタイトル「ザ・ボーイズ・オブ・アリゾナ」、を採用することにより標準データファイルが作成される。ディレクター情報は、データファイル２７２０の方がディレクターの性と名の両方を含んでおりデータファイル２７１０よりも完全であることから、データファイル２７２０から入手される。データファイル２７１０に掲載されている放映年とデータファイル２７２０に掲載されている放映年については矛盾が存在する。以前の情報に基づき、この矛盾は、データファイル２７２０の方が正しい放映年を掲載しているというように解決される。標準データファイル２７３０には、データファイル２７２０の粗筋欄が空欄なので、データファイル２７１０の粗筋を含める。
【０１１１】
図２７に関連して説明した標準データファイル作成処理では、より完璧且つ正確な情報を備えたファイルが作成でき好都合である。更に、この処理では多数のウェブサイトの情報を互いに比較することが可能になる。更には、標準データファイルの作成処理により、データファイル同士の関連性及びアソシエーション関係が増す。
【０１１２】
図２８は、ウェブから入手したデータを分離して、データベースに記憶するため当該データを変換する際に実行されるオペレーションの機能説明図２８００を示している。代表的な処理には、データをネットワーク２０から抽出してデータ構造２８１０に入れ、データを配列して編成する段階が含まれている。例えば、交通情報に関するデータを、内容、幹線道路、交差道路、時間、日付、重大度などに関する情報を含むようにインターネットから抽出する。データがデータ構造２８１０に配列され編成されるようにするテキストパターンと記述を含んだルール２８１５を使って、データ構造２８１０を作成・編成する。データ構造２８１０はデータベースのデータファイルに記憶される。データ構造２８１０内のデータは変換され、第１の項代入形式を適用してデータ構造２８２０を作成する。項代入時はルール２８２５を用いてデータ構造２８２０を作成するが、これは変換テーブルの辞書的入力を含んでいる。交通情報の例では、“Ｒｄ”は“ｒｏａｄ（道路）”に、“Ｉ”は“ｉｎｔｅｒｓｔａｔｅ（州間高速自動車道）”に、そして“Ｒｔ”は“ｒｏｕｔｅ（路線）”に、それぞれ変換される。
【０１１３】
データ構造２８２０に入っているデータは、送られてきたデータに対して属性句文法を適用するルール２８３５に基づいて、データ構造２８３０に、構文解析済みフォームで置かれる。交通情報の例では、東西南北のような「方角」を識別し、「州間高速自動車道」や「高速道」の様な「ハイウェイ識別子」を求める。データ構造２８３０のデータは、次に項配列ルール２８４５を用いて、データ構造２８４０に、再配列フォームで入れられる。データ構造２８４０のデータは、第２の項代入形式で扱われて、辞書的変換テーブルからのルール２８５５を適用することによりデータ構造２８５０に入れられる。例えば、“Ｓｔ．”という語は、場所識別子＜ｓｔｒｅｅｔ　ｓｔ．＞又は＜ｃｉｔｙ　ｓｔ．＞に基づいて“ｓｔｒｅｅｔ（ストリート）”又は“ｓａｉｎｔ（セイント）”の何れかと判定される。
【０１１４】
辞書的変換を行った後、データは、未融合正規化済タグ付フォーマットのデータ構造２８６０に入れられる。データ構造２８６０は、データベース２８５０内にあるのが望ましい。正規化済タグ付フォーマットとは、データを容易に探索し比較できるような均質編成とＨＴＭＬタグを含んでいるフォーマットを指す。ＨＴＭＬタグは、しばしば、データのタイプ、その場所、及びその長さに関する情報を提供する。未融合とは、データが図２５及び２６に関連して説明したフュージョン処理をまだ受けていないことを意味している。
【０１１５】
図２８に関連して説明したデータ分離処理は、ウェブからデータを取り出し、それをデータベース内の正規化済タグつきフォーマットへと変換するので好都合である。正規化済タグつきデータは、編成、処理、及び融合に備えている。データ分離処理は均質であり、広範なデータソースからのデータを扱うので好都合である。このように、一般的には、本処理は、インターネットソースからデータを入手する段階と、入手したデータで第１のフォーマットを使って第１データファイルを作成する段階と、入手したデータから、特定のインターフェースに関連付けられた第２のフォーマットで表される句を生成する段階を含んでいる。入手したデータを第１及び第２のフォーマットに変換するのには、様々なアプリケーションが利用できる。例えば、テキストパターン、辞書的変換テーブル、属性句文法、及び項配列ルールを使って、入手したデータを均質且つ探索可能なフォーマットに変換し、変換したものをデータベース内のデータファイルにセーブし、次にセーブしたデータをインターフェース特定フォーマットに変換するようにしてもよい。別の実施例では、他のパターン、テーブル、及びデータ処理アプリケーションを使用することもできる。
【０１１６】
図２９は、データベース１７０から、幾つかのインターフェースプラットフォーム（例えば、ＷＡＰ、ウェブ、電話、ＡＳＲ、ＴＴＦ）を介して音声ポータル１０のユーザーまでの、データの変換を示す機能説明図２９００である。データ構造２８６０に保有されているデータ（図２９にも図示）は、正規化済タグ付データ用の属性句文法を備えたルール２９１５を適用することにより、構文解析済みフォームで、データ構造２９１０内に置かれる。属性句文法は、正規化済タグ付データを取り上げて、識別された属性を含んでいる感知可能な句を作成する。次に、データ構造２９１０からのデータは、辞書的入力変換テーブルを保有しているルール２９２０を使って項代入形式を適用することによりデータ構造２９２０内に配置される。この代表的な実施例では、ルール２９２０の辞書的入力変換テーブルには、特定のインターフェースに対応したデータ出力構造が掲載されている。例えば、“ｒｏｕｔｅ”という語は、ＷＡＰを用いる場合は“Ｒｔ．”に変換され、音声を用いる電話の場合は“Ｒｏｕｔｅ（ルート）”と変換される。同様に、“Ｕ．Ｓ．”という語は、ＷＡＰを用いる場合は“Ｕ．Ｓ．”に変換され、音声を用いる電話の場合は“ユー・エス”と変換される。
【０１１７】
データ構造２９２０からのデータは、使用出力機器にもよるが、ルール２９３５を適用して項置換えルールを用いることにより、再配列フォームで、データ構造２９３０内へ置かれる。項再配置ルールでは、項をあちこち移動させて個々のユーザーインターフェースに最も適した配置にする。次に、データ構造２９３０内のデータは、句生成文法を備えたルール２９４５を適用することにより文が生成されるデータ構造２９４０に置かれる。例えば、“ｗｅ ｈａｖｅ ａ ＜ｓｅｖｅｒｉｔｙ＞ ｔｒａｆｆｉｃ ｉｎｃｉｄｅｎｔ ｂｅｔｗｅｅｎ ＜ｃｒｏｓｓ ｌｏｃａｔｉｏｎ＞ ａｎｄ ＜ｃｒｏｓｓ ｌｏｃａｔｉｏｎ＞ ｏｎ ＜ｍａｉｎ ｒｏａｄ＞”（＜幹線道路＞の＜交差箇所＞と＜交差箇所＞との間で＜重大度＞交通事故発生）という文章が生成される。一旦、データがデータ構造２９４０のフォーマットになると、それは、ＷＡＰ、ウェブ、電話、及びＡＳＲなど各種出力インターフェースに合わせて準備される。
【０１１８】
図２９に関して説明したデータ変換処理は、データを取り出して多様なユーザーインターフェースに合わせてそれを用意する均質処理であるので好都合といえる。例えば、この処理では、ウェブソースからデータを抽出して、意味論的に識別し、音声インターフェースを介した音声送信に備えることも可能である。同時に、この処理では、同じデータをＷＡＰ機器又はウェブアプリケーションへの送信に合わせて準備することもできる。
【０１１９】
図３０から３３では、ユーザーと音声ポータル１０との間の代表的対話を例証する数通りの動作経路を示している。ユーザーインターフェース１１０は、図３２及び３３に関連して説明するように、明示的プロンプトを使用して、適切な発言を作り出すようにユーザーを導くことが望ましい。
【０１２０】
図３０は、代表的なシステムの概要を示すフローチャート３０００であり、音声ポータル１０の各種機能性を表す処理ブロックを含んでいる。ある代表的な実行経路では、ブロック３０１０で、音声ポータル１０は「アメリカンエキスプレス提供のクワックへようこそ」と言ってユーザーに挨拶する。音声ポータル１０は、ユーザーを識別する手段として発信者ＩＤを使用するのが望ましい。ある好適な実施例では、電話番号はデータベース１７０に顧客属性として記憶されている。代わりに、電話番号を顧客データベースに記憶してもよい。音声ポータル１０は、「こんにちは、スティーブ・ウッド。あなたのＰＩＮを声に出すか番号キーで入力してください。スティーブでない場合は、あなたの電話番号を声に出すか番号キーで入力してください。」と続ける。ユーザーはここで「５０８２」と言葉で応答し自分のＰＩＮを教える。認証が済むと、音声ポータル１０はブロック３０２０に進む。ブロック３０２０では、音声ポータル１０は、「ここはクワック・ランウェイです。映画、天気、交通、株式、スポーツ、のリストから興味のあるカテゴリの名前を言って下さい。」と提示する。ユーザーはカテゴリ名で応答するか、「さよなら」と告げる。カテゴリ名が与えられると、音声ポータル１０はブロック３０３０に進む。「さよなら」と言われたら、音声ポータル１０は、素直に終了する。代表的な応答では、ユーザーは「天気」と答えているので音声ポータル１０はブロック３０３０に進む。ブロック３０３０で、音声ポータル１０は「お天気チャンネル提供のお天気コーナーへようこそ。」と言って、ブロック３０４０に進む。ブロック３０４０では、固有イグジスタンツ識別サブシステムが行われる。
【０１２１】
ブロック３０４０の後ブロック３０５０が実行され、イグジスタンツがブロック３０４０の固有イグジスタンツ識別サブシステムで見つけられたか否かについて判定が行われる。イグジスタンツが見つからなかった場合、制御はブロック３０３０に戻る。イグジスタンツが見つかった場合は、ブロック３０６０が実行され、発見済みイグジスタンツサブシステム（図３３に関連して説明）が実行される。
【０１２２】
次に、図３１に示すように、ブロック３０４０（図３０）で実行される固有イグジスタンツ識別サブシステムには、データベース１７０が、現在の垂直ドメイン（例、天気、交通、映画）に関し属性従属グラフから属性を提供するブロック３１１０が含まれている。属性従属グラフにそれ以上の属性がない場合には、制御はブロック３１１５に移り、イグジスタンツサーチ失敗が告知される。ブロック３１１５の次に、制御はブロック３０３０（図３０）に移る。ブロック３１１０（図３１）の後ブロック３１２０が実行され、データベース１７０により提供された属性値から属性語彙が構築される。ブロック３１２０を実行した後ブロック３１３０が実行され、音声ポータル１０は、方法Ｎに従い自動音声認識（ＡＳＲ）技術を使って、属性値プロンプトに対するユーザーの応答を捕捉する。例えば、音声ポータル１０は、ユーザーの場所を郵便番号、即ち１つの代表的な方法Ｎ、により応答するよう要求する。ユーザーは自分の郵便番号例えば「５３０４５」を与えることによって応答する。
【０１２３】
ブロック３１４０では、音声認識が成功したか否かについて判定がなされる。成功でない場合は、フォールバック方法Ｎ＋１に従ってＡＳＲでブロック３１３０が実行される。例えば、天気の垂直ドメインでは、フォールバック方法Ｎ＋１は、ユーザーがいる州及び都市を尋ねることが考えられる。好適な実施例では、このフォールバック方法には、リストから属性を選択する段階と、区画スペースにより設定された属性値を制約する段階（例えば、州名を入手してから都市名を入手するなど）と、属性値を綴る段階が含まれている。音声認識が成功した場合は、ブロック３１５０が実行され、音声ポータル１０は、補足した属性でデータベース１７０を探索する。ブロック３１５０を行った後、フローチャート３２００（図３２）が実行される。
【０１２４】
次に図３２は、固有イグジスタンツ識別サブシステムの一部を示すフローチャート３２００である。ブロック３１５０を実行した（図３１）後、ブロック３２１０が実行され、データベース１７０の探索結果からマッチしたイグジスタンツの数が求められる。製品データベースの探索により見つかったマッチの数によって別々の行動が起こされる。マッチが見つからない場合、ブロック３２２０が実行され、複合ユニークキーを探すか否かについて決定が下される。データベース１７０内には保有されていないがインターネット上で所望のアイテムを見つけるのに使うことのできるユニークキー又は識別子が１つ又はそれ以上ある場合は、複合ユニークキーが存在するかもしれない。
【０１２５】
１つのマッチが発見された場合、ブロック３２３０が実行され、音声ポータル１０はそのマッチが正しいイグジスタンツか否かを検証する。マッチの数が１つよりは多いがリストの最大数よりも少ない場合、ブロック３２４０が実行され、ユーザーはマッチのリストからイグジスタンツを識別するように要求される。リスト内の可能なエンティティの最大数よりもマッチの数が多い場合、ブロック３２５０が実行され、属性が「拡張可能」であるか否か判定される。換言すれば、属性について情報がもっと提供できるか否かについて判定される。これ以上情報が提供できない場合は、制御はブロック３１１０（図３１）に戻り、属性従属グラフから別の属性を入手する。属性が拡張可能である場合、ブロック３２５０が実行され、属性の拡張が試みられる。属性が拡張できれば、制御はブロック３１２０（図３１）に移り、語彙セットが構築され、ＡＲＳ技術及び方法を使って属性値が入手される。属性の拡張ができない場合、制御はブロック３１１０（図３１）に移り、属性従属グラフから別の属性を入手する。属性の拡張の結果がアイテムリストとなれば、制御はブロック２４０に移る。
【０１２６】
以下、ブロック３２２０で実行される問い合わせについて説明するが、ＷＷＷ探索に使用する複合ユニークキーがないと判断された場合、制御はブロック３１１０（図３１）に移る。複合ユニークキーが存在するかもしれないと判断されると、制御はブロック３２７０に移り、ＷＷＷを探索するか否かを決める。ＷＷＷを探索しない場合、制御は現在の垂直ドメインの最上位であるブロック３０３０（図３０）に移る。ＷＷＷを探索する場合、制御はブロック３２８０に移る。次にブロック３２３０及びブロック３２４０について説明すると、正しいイグジスタンツが見つかった、又は正しいイグジスタンツがリストから見つかった場合、制御はブロック３２８０に移る。ブロック３２３０又は３２４０で正しいイグジスタンツが見つからなかった場合、制御は、アイテムを見つけるために探索できる複合ユニークキーがあるかどうかを判定するためブロック３２２０に移る。ブロック３２８０では、ウェブルックアップが行われる。この時点で、顧客には長さが様々な目標広告が提示されることになる。広告については図３６に関連して詳しく説明する。ブロック３２８０の間に、ブロック３０６０が実行され、発見済みイグジスタンツサブシステムが実行される。
【０１２７】
図３３に示すように、発見済みイグジスタンツサブシステムは、顧客データベースに発見時間のログを行うブロック３３１０を含んでいる。ある好適な実施例では、顧客データベースはデータベース１７０に含まれている。ブロック３３１０の後ブロック３３２０が実行され、データベース１７０の情報から垂直ドメインに適切なものとして提示するために情報が準備される。ブロック３３２０の後ブロック３３３０が実行され、関係する情報とコマンド文法が構築される。例えば、映画の垂直ドメインでは、特定の劇場で公開されている映画のリストを流す場合、その文法には、ユーザーが特定の映画について更に情報を求めることができるように映画のタイトルが含まれる。
【０１２８】
ブロック３３４０では、情報がユーザーから戻される。好適な実施例では、考えられる受け入れ可能なコマンドには、より詳細な情報を聞き、特定のソースから情報を聞き、関係情報（例えば、より安価、より好都合）を聞き、垂直ドメインに対して適切な行動をとる（例えば、ビット上げる、場所を変える）ためのコマンドが含まれる。ブロック３３４０の後ブロック３３５０が実行され、次のアクティビティが得られる。新しい垂直ドメインを所望する場合、制御はブロック３０２０（図３０）に移る。現在の垂直ドメインの一番上から新たに選択したほうが望ましい場合、制御はブロック３０３０（図３０）に移る。新しいイグジスタンツを所望する場合、制御はブロック３０４０（図３０）に移る。
【０１２９】
図３２に戻るが、ブロック３２８０の後ブロック３２９０が実行され、ウェブルックアップの結果が、データベース１７０を更新することにより調整される。ブロック３２９０でウェブ結果を調整中、ブロック３２９５でスマートディレイハンドルを実行し、広告又は遅延を処理する別のフォームを実行してもよい。ブロック３２９５のスマートディレイハンドルは、顧客データベース及び広告データベースからの情報を使う。ある好適な実施例では、顧客データベース及び広告データベースは、データベース１７０のサブセットである。別の実施例では、顧客データベース及び広告データベースは物理的に別個のデータベースである。
【０１３０】
作動中、ここで説明したインターネットベースの情報に音声アクセスするシステム及び方法は、顧客の関心がある垂直ドメイン（例えば、映画、買い物）を識別し、次に垂直ドメイン中の考えられる全ての範囲から顧客が求める１つのもの又は１つのセットにまでユーザー応答を「絞り込む」ことができ好都合である。垂直ドメイン内のこの絞込みには、特定のアイテムに絞り込むための事前に定義づけられた「経路」セットに従って、製品又はサービスの属性について、ユーザーにシステム主導型質問を実施することが含まれる。経路は、突き止められ例示されるべき製品についての制約を順序付ける形で定義されている。
【０１３１】
図３４は、音声ポータル１０がユーザーの応答を絞り込んで、ユーザー応答への音声認識の正確性を上げることのできる絞込み処理のフローチャート３４００を示している。ステップ３４１０で、ユーザーは音声ポータル１０を呼び出す。ステップ３４１０の後ステップ３４１５が実行され、上記の様々な方法を使って発信人が識別される。ステップ３４１５の後ステップ３４２０が実行され、ユーザーは興味のある垂直ドメインを選択する。ステップ３４２５が次に実行され、選択された関心対象の垂直ドメインに対する属性絞込み特性が開始される。ステップ３４２５の後ステップ３４３０が実行され、音声ポータル１０は、関心対象の垂直ドメイン内にユーザーの嗜好のものがあるかどうかを判定する。嗜好のものが存在しユーザーがオーバーライドしたくない場合には、制御はステップ３４６０に移り、ユーザーの嗜好に基づいて見つけられたアイテム又はサービスが表示される。
【０１３２】
嗜好のものが入手できないか又はユーザーが自分の嗜好をオーバーライドする場合、ステップ３４３５が実行され、属性語彙セットが構築される。語彙セットは、関心対象の垂直ドメイン内のこの時点でのユーザー応答の音声認識に音声ポータル１０が使用できる可能な応答の数を限定できるようにするので好都合である。定義された語彙セットを用いれば、音声ポータル１０は、従来の音声施認識技術を高認識率で実現できるので好都合である。例えば、ユーザーがメジャーリーグベースボール（ＭＬＢ）チームを選択し、ＭＢＬチームに関して要求される可能性のある語彙セットが構築された後では、「ブリュワーズ」という語の認識は容易になるはずである。このような語彙セットは、同じ情報についてユーザーが入力する多種多様なユーザー入力のタイプを含んでいる。例えば、ＭＬＢチームの例では、語彙セットは、ＭＬＢチームに関連する全ての都市名又は州名並びにＭＬＢチームのマスコットまでも含んでいる。従って、「ミルウォーキー」及び「ブリュワーズ」は両方ともＭＬＢチームの語彙セットの一部である。
【０１３３】
適切な語彙セットが構築された後、ステップ３４４０が実行され、音声ポータル１０は属性に関して問い合わせをする。例えば、「どのメジャーリーグベースボールチームについて聞きたいですか？」と問い合わせる。ステップ３４４０の後ステップ３４４５が実行され、属性が識別される。属性が識別できない場合、ステップ３４４７が実行され、属性の識別のためにフォールバック処理が実施される。ステップ３４５０では、音声ポータル１０は、「終了状態」に到ったか、或いはアテム又はサービスを発見した時点であるかを判定する。「終了状態」に到っていない場合、ステップ３４５５が実行され、次の属性にアクセスして、制御はステップ３４３０に戻る。このベースボールの例では、チーム名だけでは終了状態には至っていない。最近の試合結果、選手統計、チームの地位、又は他の関係情報というような他の「より狭義の」属性が要求されるはずである。ステップ３４６０が実行されてしまうと、ステップ３４６５が実行され、見つかったアイテム又はサービスがユーザーに報告される。
【０１３４】
ある代表的実施例では、ユーザーは次のようにアイテムを選択する。ユーザーは、最初に関心のドメイン（例えば、電子商取引、交通情報、天気予報、映画など）を指定する。次にユーザーは、１つのアイテム（例えば、本、おもちゃ、交通情報の場合は関心のある路線、天気予報の場合は関心のある都市など）を、アイテムの属性を指定することにより選定する。次にユーザーには、アイテムのドメイン（例えば、製品、交通、天気、映画など）に適切な、識別されたアイテムについての詳細な情報が提供される。例えば、電子商取引ドメインが関心対象の場合、値段、発送費用、入手可能性などを含むベンダー情報が入手可能である。関心が映画ドメインである場合は、要覧、プロデューサー、及び配役が提供される。関心がオークションドメインである場合には、目立った競り値を知ることができる。
【０１３５】
ユーザーは、場所を識別するための多様な方法（例えば、郵便番号、町名、都市区分、「ボストン北部、西部など」）を使って場所（例えば、識別された製品の場合は一番近いベンダー、映画の場合は一番近い映画館）によって情報を要求でき好都合である。ある代表的実施例では、郵便番号中心に場所を識別する戦略を使用しており、近郊の名前をたずね、都市名又は州名にまでさかのぼり、その後再度ズームインする手法をとっている。ある代表的実施例では、ユーザーは、要求すれば情報が最後に更新された日付と時刻を入手できる。ユーザーに提示されたデータは全て、当該ドメインに対して現時点で適切であることが望ましい。ユーザーは、「純粋な」ソース情報（ＸＸＸＸ提供）又は唯一の情報源からの情報の場合には情報源を通知される。ある好適な実施例では、「ヘルプ」又は「インストラクション」オプションがどの選択時点でも利用できる。
【０１３６】
ユーザーは、ドメインに適切な場合、アイテム属性に基づいてアイテム比較を要求してもよい。ユーザーは、ドメインに適切な場合、「より好都合な」「より安価な」「関係する」アイテムの識別を要求してもよい。関心対象のドメインに適切な場合、ユーザーは、ユーザーが識別した多数のリストにアイテムを明示的に記録してもよく好都合である。ユーザーは自分のリストからアイテムを検討してもよい。ユーザーは、自分のリスト上のアイテムへの、情報変更（ドメインに適切な）の電話又はＥメールによる通知を要求してもよい。
【０１３７】
図３５は、音声ポータル１０を使って取引を実行する代表的なプロセスのフローチャート３５００を示している。ステップ３５１０で、ユーザーは（電話又は呼び出し）音声ポータル１０にアクセスする。ステップ３５１０の後ステップ３５１５が実行され、ユーザーが所望するアイテム又はサービスを識別するために絞込み処理が実行される。このような絞込み処理では、フローチャート３４００に示し且つ図３４に関連して説明したオペレーションが行われる。
【０１３８】
ステップ３５１５の後ステップ３５２０が実行され、音声ポータル１０は、識別されたアイテム又はサービスに望ましく且つ関係する取引を指定するようユーザーに要求する。ステップ３５２０の後ステップ３５２５が実行され、音声ポータル１０は、指定された取引を実行するのに適切な音声ポータルルールを識別する。ステップ３５２５の後ステップ３５３０が実行され、ルールを実行して指定された取引が実行される。取引には、アイテム又はサービスを購入すること、オークションで競り値をつけること、或いはインターネット上で可能な他の何らかのタイプの取引が挙げられる。ステップ３５３０の後ステップ３５３５が実行され、音声ポータル１０は取引の結果を記録する。結果はデータベース１７０に記録されるのが望ましい。ステップ３５３５の後ステップ３５４０が実行され、取引がユーザーに報告される。
【０１３９】
異なる取引（例えば、競売する、見る、買う、追跡する）は別々のドメインに適切である。例えば、関心対象が電子商取引である場合には、ユーザーは選定したベンダーから識別した製品を注文することになる。更に、ユーザーは、後で購入する場合に備えてショッピングカートにアイテムを追加してもよい。ユーザーは、注文時に、請求先のクレジットカード及び届け先住所を（ユーザープロフィールから又は手動で）指定することになる。ユーザーは、これまでに注文した製品の状況情報を要求することもできる。別の例では、関心対象がオークションの垂直ドメインである場合、ユーザーは、現在の競り値を上げてもよいし、新しいオークションで競り値をつけてもよい。
【０１４０】
音声ポータル１０を使って取引を実行する処理では、ユーザーがコンピュータ上で手動操作をする必要がないので好都合である。ユーザーは、マウスをクリックしなくても、コンピュータキーボード上でキーを押さなくとも、或いは他のどんなコンピュータインターフェース手動操作（例：マウスクリック、キーボード入力）をしなくても、アイテムを購入し、入札に参加し、或いは他のインターネット取引を行うことができる。このように、図３５に関連して説明したプロセスは、「ノークリック」インターネット取引プロセスで行える。ユーザーは、電話のタッチパッドを利用して「ノークリック」インターネット取引を行うこともできる。
【０１４１】
図３６Ａは、音声ポータル１０を使った広告の代表的なプロセスのフローチャート３６００Ａを示す。広告サブシステム１２０は、特定ユーザーに流す広告を決める方法を含んでおり好都合である。一般的に、この方法は、ユーザー人口統計学、場所人口統計学、及び現在の関心対象ドメインなど、コンテキストに基づいて選択制約を設定することを含んでいる。選択制約が設定されると、本方法では、その制約に基づいて広告データベースに問い合わせを行い、可能な広告のリストを検索する。可能な広告のリストは、各広告の販売基準に基づいて再注文される。広告は再注文されたリストから選択されユーザーに提示される。
【０１４２】
フローチャート３６００Ａに示すように、ステップ３６１０Ａでは、音声ポータル１０の広告サブシステム１２０は、ユーザーに提示される広告の選択制約を設定する。ある実施例では、選択制約は、ユーザー人口統計学、場所人口統計学及び（仮に、あれば）現在選択されている関心対象の垂直ドメインなどのユーザー中心情報、並びに広告販売基準、反復無し及び他の広告有効性要素などの広告中心情報に基づいている。紹介スポンサー広告、垂直スポンサー広告、及び商業広告など、多種多様な広告のタイプから選択する際には、このような制約又は判断基準が使用される。ステップ３６１０Ａの後ステップ３６１５Ａが実行され、ステップ３６１０Ａで選択された制約を基に可能な広告のリストを求めてデータベース１７０に問い合わせが行われる。
【０１４３】
ステップ３６１５Ａの後ステップ３６２０Ａが実行され、可能な広告のリストが、販売基準要素に基づいて再注文される。ある実施例では、販売基準は、以下の事柄、即ち（１）当広告については引渡し率が達成されつつあるか？、（２）当広告については最小目標引渡し率は達成されたか？、を判定するために使用される。販売基準を使って、各広告顧客がそれぞれに満たされるべき引渡し要件を持っていることを確認できるので好都合ある。ある実施例では、最初に引渡されるべき広告に優先順位をつけるために比率が計算される。
【０１４４】
以下に、どのように広告を注文するかについての判断要素として比率を使った例を示す。広告Ｘは契約上１００，０００件の引渡しを要する。音声ポータル１０は、広告Ｘのインスタンスを既に７，０００件引渡し済みである。契約開始は５月１０日で、契約終了は７月７日である。現在の日付は５月１５日であると仮定する。よって代表的比率は以下のように求められる。
【０１４５】
・契約開始から数えた日数＝５
・契約期間＝２７日
・広告を流すことが必要とされる日数＝２２日
・既に流された広告の割合＝７，０００／１００，０００〜＝７％
・既に流された日数の割合＝５／２７〜＝１８．５％
以上のことから、代表的最終比率は：
（既に流された日数の割合−既に流された広告の割合）／残りの契約日数、となる。
【０１４６】
この比率は間もなく流されるはずの広告を考慮に入れており（小さい方の分母−＞大きい方の比率）、既に流されたの広告の喰い違いは、低い比率でプッシュバックされており好都合である。
【０１４７】
可能な広告のリストが再注文されるステップ３６２０Ａの次に、広告が選択されるステップ３６２５Ａが実行される。ある実施例では、広告は、可能な広告のリストの中で利用できる最も高い比率に基づいて選ばれる。ステップ３６２５Ａの後、提示されるべき広告のタイプによって異なる動作が起きる。ステップ３６３０Ａでは、利用できる広告がない場合、及び広告タイプが紹介スポンサー広告である場合には、ステップ３６３５Ａで例外が起きる。そうでなければ、ステップ３６４０Ａが実行され、広告が利用できるか否かについて決定を下す。利用できる広告がある場合は、ステップ３６４５Ａが実行され、広告が流される。利用可能な広告がなければ、ステップ３６４０Ａが実行され、選択制約がリセットされ、制御はステップ３６２０Ａに戻る。
【０１４８】
このように、広告のタイプ毎に処理段階に差があるが、広告の種類として、紹介スポンサー広告、垂直スポンサー広告、及び商業広告の３種類がある。以下、紹介スポンサー広告を選択する場合の代表的プロセスを示す。
１．紹介スポンサー広告タイプに対して、場所に基づいて選択制約を設定する（垂直は該当しないので使用しない）。
２．制約に基づいてデータベースに問い合わせを行い、結果を、流せる広告のリストに変換する。
３．販売基準に基づいてリストを再注文する。
４．リストから比率が最も高い広告を選択する。データベース内には広告が存在するはずであり、そうでなければ例外が発生する。
【０１４９】
以下に、垂直スポンサー広告を選択する場合の代表的プロセスを示す。
１．ユーザー人口統計学、場所人口統計学、垂直スポンサー広告タイプの垂直タイプに基づいて制約を設定する。
２．制約に基づいてデータベースに問い合わせを行い、結果を、流せる広告のリストに変換する。
３．販売基準に基づいてリストを再注文する。
４．広告が利用可能であればリストから比率が最も高い広告を選択し、ユーザーインターフェースに戻す。
５．利用できるものがない場合には、垂直タイプだけに基づいて選択制約をリセットし、クアック促進にだけつながる垂直スポンサーのタイプをセットする。
６．販売基準に基づいてリストを再注文する。
７．広告が利用可能であればリストから比率が最も高い広告を選択し、ユーザーインターフェースに戻す。
８．ユーザーがリストから全ての広告を聞いた場合には、最後にユーザーに対して流された広告を戻す。何らかの理由でリストが空で利用できる広告がない場合には、例外が発生する。
【０１５０】
以下に、商業広告を選択する場合の代表的プロセスを示す。
１．場所人口統計学、顧客人口統計学、及び商業広告タイプの垂直タイプに基づいて選択制約を設定する。
２．制約に基づいてデータベースに問い合わせを行い、結果を、流せる広告のリストに変換する。
３．販売基準に基づいてリストを再注文する。
４．広告が利用可能であればリストから比率が最も高い広告を選択し、ユーザーインターフェースに戻す。
５．利用できるものがない場合、垂直タイプだけに基づいて選択制約をリセットし、クアック（即ち、音声ポータルシステム）コマーシャル又は有料コマーシャル（入力タイプには無関係）の何れかにコマーシャルのタイプをセットする。
６．販売基準に基づいてリストを再注文する。
７．広告が利用可能であればリストから比率が最も高い広告を選択し、ユーザーインターフェースに戻す。
８．ユーザーがリストから全ての広告を聞いた場合には、最後の広告を戻す。何らかの理由でリストが空で利用できる広告がない場合は、例外が発生する。
【０１５１】
図３６Ｂは、音声ポータル１０を使った広告の第２の代表的なプロセスのフローチャート３６００Ｂを示す。ステップ３６１０Ｂで、ユーザーは音声ポータル１０にアクセス（電話又は呼び出し）する。ステップ３６１０Ｂの後ステップ３６１５Ｂが実行され、ユーザールックアップを行いユーザーを識別する。様々な方法で発信者識別が実施されるが、そのうちの数例を図２及び図３０に関連して説明している。ステップ３６１５Ｂの後ステップ３６２０Ｂでは、音声ポータル１０にとってそのユーザーが既知であるか否かの判定がなされる。ユーザーが知られていない場合、ステップ３６２５Ｂが実行され、そのユーザーにデフォルトプロフィールが使用される。ある代表的実施例では、ある種の広告については、デフォルトプロフィールはユーザー制約又は制限を含んでいない。デフォルトプロフィールは、例えば、ユーザーのエリアコード、呼び出しの日時、曜日など、呼び出しについて分かっているある特定のパラメータに連動する。ユーザーが既知である場合、若しくはステップ３６２５Ｂが実行された後、ステップ３６３０Ｂが実行され、広告サブシステム１２０は、現在のユーザーに特定のユーザー制約を含めインターフェース（例：音声、ＷＡＰ、ＷＷＷ）のタイプに基づいて広告のセット“Ｓ”を生成する。
【０１５２】
現在の作動コンテキスト（例：特定ユーザー、関心対象の垂直ドメイン）が与えられると、ステップ３６３５Ｂで、広告サブシステム１２０は広告コンテキストに基づいて広告セットＳに重み付けする。ステップ３６３５Ｂの後ステップ３６４０Ｂが実行され、ユーザーが最も欲しいものを正確に知るのに十分なコンテキストであるか否かが判定される。コンテキストが十分でない場合、ステップ３６４５Ｂが実行され、入手された部分的コンテキストに基づいて広告がピックアップされる。コンテキストが十分である場合、ステップ３６５０Ｂが実行され、最もふさわしい広告が流される。
【０１５３】
広告サブシステム１２０は、初期の一般的広告又はスポンサーメッセージを全発信者に提供し、好都合である。広告サブシステム１２０は、ドメインに適した効用関数に基づいて選ばれた、的を絞った音声広告もユーザーに提供する。ある代表的実施例では、効用関数は、広告対象の製品又はサービスの入手可能性、現在のアイテムの関係性（例えば、ＤＶＤならテレビに関係がある）、ユーザーに対する関連性（例えば、人口統計学による）、ユーザーの広告主への好ましさ、及びサービスプロバイダに対する価値（例えば、費用／利益に基づく）に関係がある。広告サブシステム１２０は、ある一定数の広告をある一定の時間枠内でユーザーに引き渡すことができるので好都合である。更に、広告サブシステム１２０は、無線アプリケーションプロトコル（ＷＡＰ）、ＷＷＷ及び音声インターフェースなど異なるプラットフォームを通して広告を引き渡すことが可能である。
【０１５４】
音声インターフェースプラットフォームを例に取ると、最初の１分間で１つのスポンサー広告と１つの的を絞った広告がユーザーに流される。次の４０秒以内に２番目に的を絞った広告が引き渡される。ある実施例では、スポンサーメッセージは３−５秒間で処理され、次に的を絞った広告が１０−２０秒間を使う。
【０１５５】
この構造の実施は、システムに入ったら紹介スポンサー広告が提示されるという事実に基づいている。ユーザーは垂直に入る都度、「垂直スポンサー」に促される。ユーザーが要求するデータを受信しようとすれば、コマーシャル全編がユーザーに提示される。このモデルは、これまでに掲載されたスケジュールを、ユーザーが受信まで４０秒かけて自分の情報を探索するものと見積もった上で概算しており、好都合である。
【０１５６】
広告コンテキストでは、広告が提示された際により詳細な情報を引き渡すには「スピークスルー」が必要である。スピークスルーは、音声インターフェースだけでなくＷＡＰやＷＷＷの両方にも適用できるので好都合である。ＷＡＰの場合は、音声及びテキストはスピークスルーと見なされ、一方、広告についてより深く知るためのバナー上のクリックは、ＷＷＷ上のスピークスルーとなる。音声対話でのスピークスルーのある実施例は、顧客にウェブサイトアドレス又は電話番号を指し示すものである。別の実施例では、スピークスルーはＥメールアドレス又は顧客電話番号を収集して広告主に提供し、顧客に、より関連性の高い情報を送るようにしている。ＷＷＷインタフェースでは、スピークスルーは、顧客情報を管理し監査するのに外部ソースを利用することを含んでいる。広告サブシステム１２０は、更に、ドメイン（例えば、ＷＷＷインタフェース）に適した効率関数に基づいて選択された、的を絞った「バナー」広告をユーザーに提供する。
【０１５７】
広告サブシステム１２０の広告引渡しの管理は、幾つかの要素の組合せに基づいている。ある代表的実施例では、広告は３つの場面のうちの１場面で引き渡される。第１に、広告は、ユーザーがシステムに入って新しいセッションを開始しようとしているときに引き渡される。このスポンサーメッセージはユーザーインターフェース１１０即ち「システム音声」内で流れ、数個の別の広告スポンサーの中でローテーションされる。例えば、スポンサーメッセージとしては「クアックは、ウェブの通貨「ビザ」の提供でお送りします」又は「クワックはセルラサービスをリードするスプリントＰＣＳの提供でお送りします」などである。
【０１５８】
第２に、ユーザーが、映画、交通、又は天気など、システムのある特定の垂直にアクセスする直前に、別のスポンサー広告（垂直スポンサー広告）が引き渡される。例えば、このような広告としては、「映画情報の世界的権威ＩＭＤＢがお届けします」や「ＬＣＥソニーメトレオンは、ボストンで誰もが納得する素晴らしい映画セレクションをお届けします」などがある。
【０１５９】
第３に、ユーザーが精選された要求を受け取る直前に広告が引き渡される。この種の広告は「コマーシャル」と定義される。このような広告はタイムリーではある（即ち選定された時点で引き渡される）が、２分毎といったように非常に頻繁に流れる。システム音声は、ユーザーに対して役に立ちそうな付加価値のあるコンテキストを指摘するので都合がよい。例えば、ユーザーが特定の劇場の映画を選択している場合には、近くのレストランを提案する。非スピークスルー広告が可能ではあるが、ここではスピークスルー広告を使うのが望ましい。広告内容自体は長さが約７秒であるのが望ましい。スピークスルー広告は、出来る限り最高品質であり（即ち、専門的に製作されたもの）、長さは大体１５から２０秒であるのが望ましい。例えば、ユーザーが、ＬＣＥソニーメトレオンで映画として「アメリカンビューティー」を選択する場合、システム音声は、「ソニーメトレオンのリストを見ています。ソニーメトレオンからたった５分のボストン最高のイタリア料理店「トニーズ・マトリシアーナ」について聞きたければ、「トニーズ！」と言って下さい、でなければリスト提示を維持して下さい。」と言う。ユーザーはここで自動的に予約を入れることになる。他の関係性属性を、的を絞った広告を行うために使ってもよい。垂直指定要求をすることは広告の引渡しに時間がかかるという現在の仮定のためこれら別々のスポットで広告が引き渡されるので、好都合である。
【０１６０】
これらの問題に加えて、どの広告をユーザーの元に届けるべきかの決定が行われる。この決定に組み入れられる要素としては、呼び出しの長さ、どんなタイプの垂直コンテンツが要求されるか、コンテンツとユーザープロフィール（及び／又は場所）の組合せ（即ち、レストランの広告は顧客の地元であるべき）、可能収益、発信人が要求する特定の情報、及びユーザーがその広告を既に耳にしているかどうか、などがある。ある代表的実施例では、広告は以下の要素に基づいてローテーションされる。即ち、当該広告が最後に流されたのは何時か。今回の呼び出し前にユーザーが当該広告を最後に耳にしたのは何時か。ユーザーは今回の呼び出しで既に当該広告を聞いたか。当広告について広告引渡し率は達成されつつあるか。最小引渡し目標は当広告では達成されたか。
【０１６１】
広告は、提示が特定の顧客にとって適当で、請求料金に則ったやり方で引き渡されるので好都合である。こうして、当該広告は何度流されたか、及び各ユーザーは当該広告を何度聞いたかなど、ある一定の基本データを集めて各広告を管理する。
【０１６２】
また、このような基本的なデータが与えられると、以下の更に複雑な問い合わせが可能になる。例えば、問い合わせには、定義された各種グループ、即ち、名前、人口統計学的情報、場所、及び関係性情報（これらユーザーが他に要求したもの）のグループの中の広告を聞いたことのある全ユーザーの報告書を作成する能力が含まれている。問い合わせには、スピークスルー情報を要求したことのあるユーザー全ての報告書を作成する能力も含まれる。
【０１６３】
音声ポータル１０では他のモード時には可能であるバージ・イン能力（即ち広告の上演を停止すること）を広告提示中は除外することができる。バージ・インを防止する能力は、音声ポータル１０を介して与えられた広告に関連して入手されているデータを広告主が確信しなければならない点で重要である。ある実施例では、広告用データの収集は第３者監査人により行われる。
【０１６４】
広告サブシステム１２０は、ユーザーに提供された全広告の記録を、成功（即ち完遂した）及び不成功（即ち不完全な）の引渡しを含めて全て保持している。この記録はデータベース１７０に記憶されるのが望ましい。広告は、関心対象の垂直ドメイン、又は発信人住所即ちユーザー、又はユーザーの嗜好、又はユーザーの過去の関心により、或いは広告主の利益とユーザーが収集した情報の何か別の組合せにより的を絞られ、好都合である。
【０１６５】
コンテキストに敏感な情報の使用は、ユーザーに対して広告の目標範囲を絞るのに利用できるので好都合である。音声ポータル１０でのコンテキストに敏感な広告の的絞りは、広告コマーシャルとユーザーが受信するほぼ正確な情報とを関係付ける。この機能を正しくするために、広告が流される直前に適当なポインタが選択アルゴリズムに送り込まれる。ある実施例では、垂直タイプがコンテキストポインタである。
【０１６６】
別の実施例では、イグジスタンツはより具体的な目標設定を許容するコンテキストポインタである。このコンテキストポインタは、その属性基準を市場調査基準と突き合わせて、ある特定のカテゴリーの重み付けを決定する。これらカテゴリー重み付けを初期リスト中の広告の販売基準と組み合わせてコンテキスト重み付けの順位を定義し、そこから最良の広告を選択するようにしている。人口統計学及び垂直タイプから作成されたこの初期リストはコンテキスト重み付けの基礎となる。算術的な表記法を導入してこの問題をアルゴリズムに組立てた場合の一例を以下に示す。
【０１６７】
第１に、関係するパラメータに対して変数を定義する。アルゴリズムに送り込まれるイグジスタンツの属性のリストは、セット｛ｅ_１，ｅ_２，．．．，ｅ_ｍ｝により定義されるものとし、ここにｍはイグジスタンツ内の属性の個数である。例えば、映画イグジスタンツについては、サンプル属性は、ジャンル、場所、及び放映時間である。広告と結びつけるのに利用できるカテゴリーのリストは、セット｛Ｃ_１，Ｃ_２，．．．，Ｃ_ｎ｝により定義され、ここにｎはカテゴリーの総数である。システム内のサンプルカテゴリーとして幾つか例を示すと、家族、レストラン、ナイトライフ、映画、及び娯楽などがある。コンテキストカテゴリーには各カテゴリーＣ_ｉに対し重みＷ_ｉがあるとし、ここにｉ∈｛１，．．．，ｎ｝である。コンテキストカテゴリー加重を設ける目的は、広告カテゴリー加重に比べたコンテキストの強度を判断するためであり、これについては以下に説明する。
【０１６８】
全イグジスタンツに対する市場調査基準をＰ＝｛ｐ_１，ｐ_２，．．．，ｐ_ｔ｝により表し、ここにｔはデータベース内の全ての基準の合計である。各基準ｐ_ｊには対応付けられた重みｗ_ｊがあり、ここにｊ∈｛１，．．．，ｔ｝であり、全てのｉ，ｊに対し各属性ｅ_ｉは全ｐ_ｊを満たそうとするものであり、ここにｉ∈｛１，．．．，ｍ｝、ｊ∈｛１，．．．，ｔ｝である。こうして、ｅ_ｉがｐ_ｉを満たし、ｐ_ｊがカテゴリーＣ_ｋに属するのであれば、Ｗ_ｋ＝Ｗ_ｋ＋ｗ_ｊとなり、ここにｉ∈｛１，．．．，ｍ｝、ｊ∈｛１，．．．，ｔ｝、ｋ∈｛１，．．．，ｎ｝である。この反復法を使って、各カテゴリーの上記コンテキスト加重を定義する。
【０１６９】
各カテゴリーに対し、合計コンテキスト加重Ｗ_ｋが定義されると、付随する強度比率Ｒ_ｋが計算できるはずである。カテゴリーの強度比率を使用すれば、イグジスタンツのコンテキストが広告の選択に値するほどに強力であるかどうかが判定できる。例えば、家族というカテゴリーがＰに多くの基準を有している場合、イグジスタンツのコンテキストに対応する重みが受け入れ可能な割合内にあるかを確かめたいと思う。よって、Ｒ_ｋ＝Ｗ_ｋ／Ｔ_ｋであり、ここにＴ_ｋはカテゴリーｋに関係するＰ内の全基準の加重合計である。
【０１７０】
人口統計学的問い合わせにより生成された広告のリストは、セットＡ＝｛Ａ_１，Ａ_２，．．．，Ａ_ｒ｝により定義され、ここにｒはリスト内の広告の総数である。各広告Ａ_ｉは自身のカテゴリー重みｘ_ｋを有し、ここにｉ∈｛１，．．．，ｒ｝及びｋ∈｛１，．．．，ｎ｝で、コンテキストカテゴリー加重比Ｒ_ｋに対応しているアルゴリズムに結び付けて使用される。
【０１７１】
こうして、データベース上で人口統計学と広告タイプによりフィルタリングすることにより広告Ａの初期リストが一旦作成されると、アルゴリズム内のステップは以下のようになる。
１．各カテゴリーＣｋに対しカテゴリー重みＷ_ｋを次のように設定する。
・各Ｗ_ｋ＝０に初期化し、ここにｋ∈｛１，．．．，ｎ｝
・各ｉ∈｛１，．．．，ｎ｝及び各ｊ∈｛１，．．．，ｔ｝に対し、イグジスタンツの現在の属性｛ｅ_１，ｅ_２，．．．，ｅ_ｍ｝に基づいて、ｅ_ｉがｐ_ｊを満たし、ｐ_ｊがカテゴリーＣ_ｋに対応付けられている場合、Ｗ_ｋ＝Ｗ_ｋ＋ｗ_ｊ、ここにｋ∈｛１，．．．，ｎ｝である。
２．次にイグジスタンツの属性とは別にカテゴリーの合計加重を表にする。合計加重より、各カテゴリーのコンテキスト比を確立する。
・各ｋ∈｛１，．．．，ｎ｝及び各ｊ∈｛１，．．．，ｔ｝に対し、ｐ_ｊがカテゴリーＣ_ｋに対応付けられている場合、Ｔ_ｋ＝Ｔ_ｋ＋ｗ_ｊ。コンテキストカテゴリーコンテキスト比をＲ_ｋ＝Ｗ_ｋ／Ｔ_ｋと設定する。
３．各カテゴリーｋに対し、各Ｒ_ｋに各広告Ａｉのカテゴリー加重ｘ_ｋを掛け、次にその合計に広告Ｓ^ｉの販売基準比を掛け、コンテキスト合計Ｇ_ｉを得る。
・各ｉ∈｛１，．．．，ｒ｝に対しＧ_ｉを計算し、ここに
Ｇ_ｉ＝Ｓ_ｉ・（Ｒ_ｌｘ_ｌ＋．．．＋Ｒ^ｎｘ_ｎ）である。
４．広告Ａ_ｉを選択し、ここにｉはｍａｘ（Ｇ_ｉ）、ｉ∈｛１，．．．，ｒ｝により定義される。
【０１７２】
上記アルゴリズムをサンプル例により説明する。ユーザーが、関心対象の映画の垂直ドメインで音声ポータル１０のサービスを使用している例を考察する。垂直スポンサー広告が流され、ユーザーは映画表示に関する情報を正に受信するところである。こうしてコンテキストとして、選択肢には、特定のイグジスタンツを流すためのポインタが含まれており、それは引数のための「ミッション・トゥー・マース」である。映画表示イグジスタンツの属性のうち幾つかは格付け（例えば、Ｒ）、ジャンル（例えば、スリラー）、及び放映時間（例えば、４：００ｐｍ）などであり、｛ｅ_１，ｅ_２，ｅ_３｝により表すことができる。そこで、要素Ｐ＝｛ｐ_１，ｐ_２，．．．，ｐ_ｔ｝を含んでいるマッチングコンテキスト基準のリストが必要となる。基準のサンプルリストはデータベース内で下表のように表される。
【０１７３】
【表１】

【０１７４】
この表から、カテゴリーはＣ＝｛娯楽、家族、ナイトライフ、１０代、アダルト｝として推断され、ここにｋ＝５である。よって、ステップ１から、Ｗ_１＝１０、Ｗ_２＝０、Ｗ_３＝５０、Ｗ_４＝８０、Ｗ_５＝０である。ステップ２より、Ｒ_１＝１、Ｒ_２＝０、Ｒ_３＝１、Ｒ_４＝０．４、Ｒ_５＝０である（これは、Ｐには８つしか要素がない場合を想定しているが、当てはまる場合はほとんどなく要素は凡そ２００以上になるはずである）。次に、広告リストＡには３つの広告があると仮定する。広告の５つのカテゴリーの重みを次のように仮定する。
【０１７５】
【表２】

【０１７６】
よって、これらの重みづけ｛ｘ_１，ｘ_２，ｘ_３，ｘ_４，ｘ_５｝から、計算を行って各広告Ａ_ｉに対しＧ_ｉの値を以下のように得るが、ここにｉ∈｛１，２，３｝である。
【０１７７】
Ｇ_ｉ＝Ｓ_ｉ・（Ｒ_ｌｘ_ｌ＋．．．＋Ｒ_ｎｘ_ｎ）
Ｇ_１＝０．８・（（１）（０．９）＋０＋（１）（０．７）＋（０．４）（０．９）＋０）＝１．５６８
Ｇ_２＝１．１・（（１）（０．９）＋０＋（１）（０．９）＋（０．４）（０．９）＋０）＝２．３７６
Ｇ_３＝１．０・（（１）（０．９）＋０＋（１）（０．７）＋（０．４）（０．９）＋０）＝１．９６
【０１７８】
この様に、コンテキスト及び販売比に基づけば、「ミッション・トゥー・マース」の広告が最も適当である。このアルゴリズムは、検索されている情報への関連性に基づいて異なるカテゴリーのコンテキストに注意する。また、販売基準に合わせて流す必要のある広告に気づきそれを順序付けの要素にするように編成を行うこともする。本例では、広告、カテゴリー、及びＰの基準の短いリストしか示していない。アルゴリズムは、もっと多くのカテゴリー及び基準を利用しようとするものである。
【０１７９】
図３７−４３は、ユーザーと音声ポータル１０との間の対話の代表的なダイアログマップを示している。図３７−４３に関連して記載されているダイアログマップは、説明のためだけの図である。関心対象である映画、天気、交通、株及びスポーツの垂直ドメインを図に示しているが、関心対象の何れの垂直ドメインでも、特に、図４−６に関連して説明したデータ構造モデル３００、４００、４５０により入手可能な、発展的で適用性のある機能に照らして、このようなダイアログマップ（及び音声ポータル１０のユーザーとの対話）に含まれ得ることは明らかである。更に、ユーザーと音声ポータル１０との間の異なる対話を示す特定のブロックは、説明するためだけのものである。関心対象の多くの可能な垂直ドメインそれぞれに対し、様々な対話が可能である。
【０１８０】
図３７はダイアログマップ３７００を示しており、ユーザーによって音声ポータル１０へ電話呼び出しが行われた後ブロック３７１０が実行され、歓迎を受ける。ブロック３７１０の後ブロック３７２０が実行され、署名手続きが続く（更に図３８に関連して記載されている）。ブロック３７２０の署名手続きの後、ユーザーは、ブロック３７３０及び３７４０で、音声ポータル１０のサービスへの案内を受けるか、又は、ブロック３７５０で、可能性のある関心対象の垂直ドメインの案内への通路情報へ直接進むか、選択することができる。具体的には、ブロック３７３０では、サービスがどの様に行われるかに関し案内情報が提供される。ブロック３７５０では、音声ポータル１０は、ユーザーに、関心対象のドメインを「通路」（例えば、映画、天気、交通、株、スポーツ）から選択するように要求する。
【０１８１】
ユーザーが関心対象の映画ドメインを選択すれば、ブロック３７６０が実行され、そこで映画サブシステムが実行され（図３９と関連して更に説明する）、ユーザーは、映画リスト、劇場及び評論のような映画情報と取引にアクセスすることになる。ユーザーが関心対象の天気ドメインを選択すれば、ブロック３７７０が実行され、そこで天気サブシステムが実行され（図４０と関連して更に説明する）、ユーザーは、好みの場所又は何れかの場所の今日の予報、又は数日先の予報のような天気情報にアクセスすることになる。ユーザーが関心対象の交通ドメインを選択すれば、ブロック３７８０が実行され、そこで交通サブシステムが実行され（図４１と関連して更に説明する）、ユーザーは、市街の報告、あるルートに関する報告、又は個人向けの報告のような交通情報にアクセスすることになる。ユーザーが関心対象の株ドメインを選択すれば、ブロック３７９０が実行され、そこで株サブシステムが実行され（図４２と関連して更に説明する）、ユーザーは、市場の動向、株の相場、株のニュース、個人向けの株ニュース又は取引（例えば、売り、買い）のような株情報及び取引にアクセスすることになる。ユーザーが関心対象のスポーツドメインを選択すれば、ブロック２５００が実行され、そこでスポーツサブシステムが実行され（図４３と関連して更に説明する）、ユーザーは、スポーツのスコア、スポーツニュース、スポーツイベントのチケット情報及びスポーツの夢のリーグ取引のようなスポーツ情報と取引にアクセスすることになる。
【０１８２】
図３８は、署名サブシステムを示している。ブロック３８１０で、発信者の識別が試みられている。音声ポータル１０のユーザーの１つのタイプは、識別されていないユーザーである。識別されていないユーザーがコールインする（恐らく初めて）と、そのユーザーは、従来式の発信者識別技術（発信者ＩＤ）によってつきとめられるか、られないかのどちらかである。発信者ＩＤがデータベース１７０内になければ、発信者は恐らく新規発信者である。発信者ＩＤが秘密にされると、音声ポータル１０はどちらの方法も通知できない。ある実施例では、音声ポータル１０は電話番号（又は他の識別子）を質問して、「識別済み」発信者と継続する。別の実施例では、音声ポータル１０は検証無しでも継続する。この判断は、要求されている情報の種類によって決まる。例えば、特定の垂直ドメインでは、ユーザーの確認は、行為（例えばオークション）の前にユーザーを確認するよう判定される必要がある。
【０１８３】
確認されたユーザーは、加入しているか、していないか何れかである。確認されたユーザーが加入している場合、音声ポータル１０は、データベース１７０からのクレジットカード及び嗜好のようなユーザーに関する情報を有している。音声ポータル１０が嗜好と関心対象の追跡を開始し、サービスに対する高い付加価値とロイヤリティを実現できるように、ユーザーは加入するのが望ましい。ユーザーは、加入に際して、住所及びクレジットカードの番号を含むプロファイル情報を指定する。更に、特定の発信者に関する情報が蓄積されるほど、送られてくる広告が多く（従って価値のあるものに）なる。
【０１８４】
発信者の識別が可能であれば、ブロック３８２０が実行され、ユーザーにパスワードを質問することにより、ユーザーの確認が行われる。一旦パスワードが検証されると、ユーザーの嗜好が設定され、制御はブロック３８７０へ移り、図３７へ戻って、案内又は通路選択が実行される。与えられたパスワードが無効であれば、制御はブロック３８４０へ移る。
【０１８５】
発信者の識別が不可能か、又はユーザーが自分のパスワードを知らない場合、制御はブロック３８３０へ移り、音声ポータル１０はユーザーの口座状況を判定する。ユーザーが口座を持っていない場合、制御はブロック３８５０へ移り、ユーザーは口座を開設すべきだという口座開設催促が与えられる。ユーザーが口座を持っている場合、制御はブロック３８４０へ移り、音声ポータル１０は、ユーザーの口座番号を入手する。ユーザーが口座番号を忘れている場合、制御はブロック３８５０へ移り、ユーザーに口座を開設することを求める。ユーザーが有効な口座番号を提供すれば、ユーザー確認のため制御はブロック３８２０へ移る。ユーザーが無効な口座番号を提供すれば、制御はブロック３８６０へ移り、音声ポータル１０は、ユーザーに口座が無効であることを通知し、ウェブサイトを訪れるか、又は助けを求めて支援番号を呼び出すよう通知する。次に制御はブロック３８８０そして図３８へ移り、そこで案内又は通路選択が実行される。
【０１８６】
図３９では、映画サブシステムが実行される。音声ポータル１０は、ブロック３９１０で、関心対象の映画ドメインへの案内を流す。ユーザーは、劇場での映画、映画のリスト、映画の批評のようなオプションを選択することができる。ユーザーが劇場での映画を選択すれば、制御はブロック３９１５へ移り、音声ポータル１０は、ユーザーが所望した地理的場所を決定する。ＺＩＰコード、州、都市のような場所又は嗜好を決定するのには、様々な方法が利用できる。所与の場所付近に劇場がない場合、ブロック３９２０が実行され、ユーザーに所与の領域内には劇場がない旨知らせるメッセージが流される。場所が決定されると、ブロック３９２５が実行され、その場所内の劇場名がリストアップされる。ブロック３９２５の後ブロック３９３０が実行され、前記領域内の劇場で上映されている映画がリストアップされる。音声ポータル１０は、ユーザーに、映画を選択するよう要求し、ブロック３９３５へ移る。
【０１８７】
関心対象の映画ドメインへの案内を流したブロック３９１０に戻り、ユーザーが映画のリストを求めれば、ブロック３９４０が実行され、音声ポータル１０は映画のタイトルをユーザーに要求する。ブロック３９４０の後ブロック３９４５が実行され、地理的場所がユーザーに求められる。上に述べたように、発信者の場所を判定するにの、様々な方法が用いられる。選択された映画を上映している劇場があれば、ブロック３９５０が実行され、その映画を上映している劇場がリストアップされ、ユーザーはそのリストから選択するよう求められる。次に制御はブロック３９３５へ移る。選択された映画を上映している劇場が無ければ、ブロック３９５５が実行され、最も近い場所での上映時間が、ユーザーに提供される。次に制御はブロック３９３５へ移る。
【０１８８】
関心対象の映画ドメインへの案内を流したブロック３９１０では、ユーザーが映画の評論を求めれば、ブロック３９６０が実行され、音声ポータル１０は映画のタイトルをユーザーに要求する。ブロック３９６０の後ブロック３９６５が実行され、選択された映画の評論が流される。ブロック３９６５の後ブロック３９７０が実行され、音声ポータル１０は、ユーザーに、選択された映画の上映を知りたいかどうか質問する。ユーザーが拒否すれば、制御はブロック３９６０へ戻り、映画評論のための別の映画タイトルを得る。ユーザーが受け入れれば、制御はブロック３９４５へ移る。
【０１８９】
ブロック３９３５では、音声ポータル１０が、選択された映画及び劇場の上映時間を提供する。音声ポータル１０は、ブロック３９８０で、次の行動を要求する。ユーザーは劇場の住所を要求することができ、そのアドレスはブロック３９８５で提供される。ユーザーは、映画の評論を要求することもでき、その評論はブロック３９９０で提供される。ユーザーが、関心対象の映画ドメインを離れたい場合、制御は図３７のブロック３７５０へ戻る。
【０１９０】
図４０では、天気サブシステムが図示のように実行される。ブロック４０１０で、音声ポータル１０は、関心対象の天気ドメインへの案内を流す。ブロック４０１０で案内が流された後、制御はブロック４０２０へ移り、音声ポータル１０は、関心対象の天気ドメインで用いる場所情報を入手する。先に述べたように、ＺＩＰコード、都市又は州、及び他の場所的証拠から場所を手に入れるように、各種の方法を使って場所情報を入手することができる。ブロック４０２０の後、制御はブロック４０３０へ移り、音声ポータル１０は、ユーザーが、現在の天気情報を欲しいのか、先の天気情報を欲しいのか応答を促す。ユーザーが先の天気情報を聴くことを選択すれば、制御はブロック４０４０へ移り、音声ポータル１０は、ユーザーに天気潜在オプションを提供するプロンプトを流す。ユーザーが現在の天気情報を欲しい場合、又はユーザーがブロック４０４０で潜在オプションを選択した後、制御はブロック４０５０へ移り、音声ポータル１０は、所望の天気情報を提供する。
【０１９１】
ブロック４０５０が実行された後、制御はブロック４０６０へ移り、音声ポータル１０は、ユーザーに、先の予報を所望するか否か質問する。先の予報が所望の場合、制御はブロック４０７０へ移り、音声ポータル１０は先の予報を提供する。ブロック４０７０の後、又はユーザーが先の予報を求めない場合、制御はブロック４０８０へ移り、音声ポータル１０は、ユーザーに次の行動をたずねる。ユーザーが関心対象の天気ドメインを継続したい場合、制御はブロック４０２０へ移る。ユーザーが関心対象の天気ドメインを離れたい場合、制御は、図３７でブロック３７５０に関連して述べた通路に相当するブロック４０９０へ移る。
【０１９２】
図４１では、交通サブシステムが実行される。ブロック４１１０で、音声ポータル１０は、関心対象の交通ドメインへの案内を流す。ブロック４１１０の後、制御はブロック４１１５へ渡り、音声ポータル１０は、ユーザーに関する場所情報又はユーザーに関する個人向け情報を入手する。ブロック４１１５の後、制御はブロック４１２０へ移り、音声ポータル１０は、市街の交通情報を入手する。市街の交通情報が不可能であれば、制御はブロック４１３５へ移り、ＺＩＰコード交通情報が入手される。都市が音声ポータル１０に認識されていなければ、ＺＩＰコード交通情報はフォールバックである。都市のデータが見つからず、データが近くの場所に含まれている場合、制御はブロック４１４０へ移り、音声ポータル１０は、付近の都市をたずねる。ブロック４１２０で交通イベントが報告できない場合、制御はブロック４１２５へ移り、ユーザーに、その都市には報告できる交通情報がない旨告げられる。ブロック４１２０で交通データが入手できない場合、制御はブロック４１３０へ移り、ユーザーには、他の都市を試すか、或いは新しい関心対象のドメインの選択に向け通路へ進むか、のオプションが提示される。
【０１９３】
ブロック４１２０の後、制御はブロック４１４５へ移り、音声ポータル１０は特定の交通ルート又は「都市全体」を要求する。ブロック４１４５の後、制御はブロック４１５０へ移り、音声ポータル１０はルート指示情報を入手する。ブロック４１５０の後、そのルートに報告すべき交通量がない場合、制御はブロック４１５５へ移る。ブロック４１５５で、ユーザーには、新しい交通ルートか「都市全体」を選択するか、通路へ行き新しい関心対象のドメインを選択するかというオプションが提示される。ルート交通情報が入手可能であれば、ブロック４１５０の後、制御はブロック４１６０へ移り、音声ポータル１０は、選択されたルートのルート交通量をリストアップする。ユーザーがブロック４１４５で「都市全体」を選択した場合、制御はブロック４１６５へ移り、音声ポータル１０は都市の交通情報をリストアップする。
【０１９４】
ブロック４１６０とブロック４１６５の後、制御はブロック４１７０へ移り、音声ポータル１０は、ユーザーに所望の交通報告を提供する。ブロック４１７０の後、制御はブロック４１７５へ移り、音声ポータル１０は、関心対象の交通ドメインで実行すべき次の行動を要求する。ある代表的実施例では、次の行動に、交通報告の反復、交通情報リストアップの継続通路への進行が含まれる。ユーザーがブロック４１７５で選択した後、制御は適切なブロックへ移る。例えば、ユーザーが交通報告の反復を選択する場合、制御はブロック４１７０へ移る。ユーザーがリスト継続のオプションを選択する場合、制御は、ブロック４１４５でなされた、特定の交通ルートか「都市全体」かの選択によって、ブロック４１６０かブロック４１６５へ移る。ユーザーが通路への進行を選択する場合、制御は、図３７のブロック３７５０に関連して説明された通路に相当するブロック４１８０へ移る。
【０１９５】
図４２では、株サブシステムが実行される。ブロック４１２０で、音声ポータル１０は、関心対象の株ドメインへの案内を流す。ブロック４２１０の後、制御はブロック４２１５へ移り、音声ポータル１０は、ユーザーに、市場の動向、株価、或いは「マイ・クワック」と呼ばれる個人向けリストを選択するオプションを提示する。ユーザーが市場の動向を選択すれば、制御はブロック４２４０へ移り、ダウジョーンズ工業平均、ナスダック、Ｓ＆Ｐ５００、ＮＹＳＥ出来高、ナスダック出来高、３０年社債などの各種市場の動向が提供される。ユーザーが株価を選択すれば、制御はブロック４２２０へ移り、音声ポータル１０はユーザーから特定の株の銘柄を入手する。ブロック４２２０の後、制御はブロック４２２５へ移り、音声ポータル１０は、ブロック４２２０で提供された株の銘柄に対応する株式取引を入手する。株式取引が識別された後、制御はブロック４２３０へ移り、音声ポータル１０は、株価、最新の取引、変動、出来高及び一日の最高値／最安値のような株の情報を提供する。
【０１９６】
ブロック４３２０の後、制御はブロック４２３５へ移り、音声ポータル１０は関心対象の株のドメインで実行すべき次の行動をたずねる。ある代表的な実施例では、ユーザーは、株情報を繰り返す／株の情報をリストアップし続ける、新しい株を入手する、市場の動向を聞く、或いは通路へ行くことを選択できる。ブロック４２３５でユーザーが行った選択によって、制御は、市場の動向を選択した場合はブロック４２４０へ、新しい株の銘柄を選択した場合はブロック４２４０へ、個人向けのマイ・クワック株を選択した場合はブロック４２５０へ移り、通路を選択した場合はブロック４２７５０へ移る、ブロック４２７５の前に、制御はブロック４２７０へ移り、音声ポータル１０は、個人向け情報をより速く入手するには嗜好を設定することができるという嗜好の催促をユーザーに提供する。ユーザーが、嗜好に関するこのコールで既に催促を受けていれば、制御は直接ブロック４２７５へ移る。
【０１９７】
ブロック４２１５でユーザーが「マイ・クワック」を選択した場合、制御は、預金口座情報が識別されなければブロック４２４５へ移り、口座情報が識別されればブロック４２５０へ移る。ブロック４２４５では、嗜好が設定され、口座情報が確立される。ユーザーに、ウェブ上に口座を設定するよう進言してもよい。ブロック４２５０では、株価、最新の取引、変動及び出来高のような個人向けの株情報が提供される。ブロック４２５０のオペレーションの間に、ユーザーは、例えば、特定の株に関する情報が流れている間に「その株」と声を出すことによって、特定の株を識別することができる。そのような選択がなされた場合、制御はブロック４２５５へ移り、特定の株に対して株のニュースオプションがリストアップされる。ユーザーが、ブロック４２５５でリストから特定のタイプの株ニュースを選択した後、制御はブロック４２６０へ移り、音声ポータル１０は、選択された株のニュースを流す。ブロック４２６０の後、制御はブロック４２６５へ移り、音声ポータル１０は、ユーザーに、戻って株のニュースのリストを入手するか（ブロック４２５５）又は株のニュースを出るかをたずねる。ユーザーが株のニュースを出ることを選択すれば、制御はブロック４２３５へ移り、株に関する次の行動が求められる。ユーザーが関心対象の株のドメインを完了すると、制御は、図３７のブロック３７５０に関連して述べられている通路に相当するブロック４２７５へ移る。
【０１９８】
図４３では、スポーツサブシステムが実行される。ブロック４３１０で、音声ポータル１０は、関心対象のスポーツドメインへの案内を流す。ブロック４３１０の後、制御はブロック４３１５へ移り、音声ポータル１０がユーザーの所望するスポーツのタイプを入手するか、又は、ユーザーが「マイ・クワック」と言って個人向けのスポーツタイプのスコアを入手する。ユーザーが特定のスポーツを選択すると、制御はブロック４３２０へ移り、音声ポータル１０は、リストから選択されたスポーツのリーグ名を入手する。例えば、音声ポータル１０は、「ＮＦＬ、ＮＢＡ、ＮＨＬ及びメジャーリーグベースボール」をリストアップする。ユーザーがリーグ名を選択すると、制御はブロック４３２５へ移り、音声ポータル１０は、ユーザーが関心を持っている特定のチームを入手する。ブロック４３２５の後、制御はブロック４３３０へ移り、スポーツのスコアが提供される。例えば、音声ポータル１０は、「ＴＥＡＭが行った最新の試合は、ＤＡＴＥで、ＴＥＡＭ１との最終的なスコアはＳＣＯＲＥ１で、ＴＥＡＭ２との最終的なスコアはＳＣＯＲＥ２である」と言う。
【０１９９】
ブロック４３１５で、ユーザーが「マイ・クワック」を選択した場合、制御はブロック４２４０へ移る。ブロック４３４０で、音声ポータル１０は、個人向けのマイ・クワックスポーツチームのスポーツのスコアを提供する。ブロック４３４０の後、制御はブロック４３３５へ移り、音声ポータル１０は、スポーツニュースにチーム特定のニュースを提供する。ブロック４３３０及びブロック４３３５の後、制御はブロック４３４５へ移り、音声ポータル１０は、ユーザーがスポーツニュースを繰り返し聞きたいかどうかたずねる。ユーザーが肯定すると、音声ポータル１０は、戻って提供された情報を繰り返す。ユーザーが情報を繰り返して欲しくなければ、制御はブロック４３５０へ移り、音声ポータル１０は、関心対象のスポーツドメインで実行すべき次の行動を求める。ブロック４３５０の後、リーグ名を選択する際には制御はブロック４３２０へ移り、マイ・クワックスポーツのスコアを提供する際には制御はブロック４３４０へ移り、通路情報の際には制御はブロック４３５５へ移る。ブロック４３５５は、図３７のブロック３７５０に関連して述べた通路に相当する。図４０−４３の各サブシステムは、単なる例として示している。
【０２００】
図面に示し、上に説明した実施例は現在のところ好適であるとして示しているが、これらの実施例は単なる例として提示している旨理解頂きたい。他の実施例は、音声ポータル経由でインターネットへのアクセスを単純化するための様々なデータ構造を含んでいる。本発明は、特定の実施例に限定されず、特許請求の範囲に述べる範囲及び精神の内にありながら、様々な修正、組み合わせ及び変更に及ぶものである。
【図面の簡単な説明】
【図１】
インターネットに接続されている音声ポータルの全体図である。
【図２】
図１の音声ポータルの代表的な機能的実施例の全体的機能ブロック図である。
【図３】
図１の音声ポータルの代表的な物理的実施例の更に詳細なブロック図である。
【図４】
図１の音声ポータルに用いられている、代表的データ構造モデルの概略図である。
【図５】
ユーザー関連情報に関する、図４の代表的データ構造モデルの概略図である。
【図６】
広告関連情報に関する、図４の代表的データ構造モデルの概略図である。
【図７】
図４の代表的データ構造モデルの代表的作成プロセスを示すフローチャートである。
【図８】
図７の代表的作成プロセスの概略図である。
【図９】
非プログラミング手段を使ってインターネットベースの情報を集める代表的プロセスを示すフローチャートである。
【図１０】
図１の音声ポータルに関連するルールの非プログラミング開発の代表的プロセスの概略図である。
【図１１】
図１の音声ポータルに関連するルールの非プログラミング開発に関する代表的グラフィカルユーザーインタフェースである。
【図１２】
図１の音声ポータルに関連するルールの非プログラミング開発に用いられる代表的グラフィカルユーザーインタフェースウインドウである。
【図１３】
図１２のグラフィカルユーザーインタフェースウインドウの拡大フォームである。
【図１４】
図１の音声ポータルに関連するルールの非プログラミング開発に用いられる、代表的グラフィカルユーザーインタフェース探索データエディタウインドウである。
【図１５】
図１の音声ポータルに関連するルールの非プログラミング開発に用いられる、代表的グラフィカルユーザーインタフェースインドウである。
【図１６】
図１５のグラフィカルユーザーインタフェースウインドウの拡大フォームである。
【図１７】
図１の音声ポータルに関連するルールの非プログラミング開発に用いられる、代表的グラフィカルユーザーインタフェースウインドウである。
【図１８】
図１の音声ポータルに関連するルールの非プログラミング開発に用いられる、ベンダーフォームオプションのための代表的グラフィカルユーザーインタフェースウインドウである。
【図１９】
図１の音声ポータルに関連するルールの非プログラミング開発におけるＵＲＬの試験のための代表的グラフィカルユーザーインタフェースウインドウである。
【図２０】
図１の音声ポータルに関連するルールの非プログラミング開発における、パターンの選択のための代表的グラフィカルユーザーインタフェースウインドウである。
【図２１】
図１の音声ポータルに関連するルールの非プログラミング開発の間に、複数のページ上でリンクを検出するためにパターンを識別するのに用いられる、代表的グラフィカルユーザーインタフェースウインドウである。
【図２２】
スパイダのプログラミングに用いられる階層構造の概略図である。
【図２３】
図１の音声ポータルと共に用いられるスパイダのプログラミングのための、代表的グラフィカルユーザーインタフェースウインドウである。
【図２４】
図２３の代表的グラフィカルユーザーインタフェースウインドウの拡大フォームである。
【図２５】
情報を図１の音声ポータルの統合データベースに融合させる、代表的プロセスを示すフローチャートである。
【図２６】
情報を図１の音声ポータルの統合データベースに融合させる、第２の代表的プロセスを示すフローチャートである。
【図２７】
所与のアイテムに関するより完全な情報を作るために、２つのイグジスタンツから規範的なイグジスタンツを作成する概略図である。
【図２８】
インターネットソースから図１の音声ポータルのユーザーへのデータ分離及び変換の代表的プロセスの第１部分の概略図である。
【図２９】
データがインターネットソースから図１の音声ポータルのユーザーへ分離及び変換される、図２８の代表的プロセスの第２部分の概略図である。
【図３０】
図１の音声ポータルの代表的オペレーションの流れを示すフローチャートである。
【図３１】
図３０のフローチャートの代表的なオペレーションサブシステムを示すフローチャートである。
【図３２】
図３０のフローチャートの第２の代表的なオペレーションサブシステムを示すフローチャートである。
【図３３】
図３０のフローチャートの第３の代表的なオペレーションサブシステムを示すフローチャートである。
【図３４】
図１の音声ポータルにおけるユーザー応答を流して所望のアイテム又はサービスを決定する、代表的プロセスを示すフローチャートである。
【図３５】
図１の音声ポータルを使って取引を実行する、代表的プロセスを示すフローチャートである。
【図３６Ａ】
図１の音声ポータルを使って広告する、代表的プロセスを示すフローチャートである。
【図３６Ｂ】
図１の音声ポータルを使って広告する、第２の代表的プロセスを示すフローチャートである。
【図３７】
図１の音声ポータルの代表的対話マップを示すフローチャートである。
【図３８】
図３７の代表的な対話マップの代表的サブシステムを示すフローチャートである。
【図３９】
図３７の代表的な対話マップの第２の代表的サブシステムを示すフローチャートである。
【図４０】
図３７の代表的な対話マップの第３の代表的サブシステムを示すフローチャートである。
【図４１】
図３７の代表的な対話マップの第４の代表的サブシステムを示すフローチャートである。
【図４２】
図３７の代表的な対話マップの第５の代表的サブシステムを示すフローチャートである。
【図４３】
図３７の代表的な対話マップの第６の代表的サブシステムを示すフローチャートである。

Claims (22)

1. 電話を使ってアイテム又はサービスに関係する取引を実行するための方法において、
   前記アイテム又はサービスを識別する情報を提供し、前記識別されたアイテム又はサービスと関係付けられている、実行されることになる取引に関する問合せを提供する段階と、
   ユーザーの回答に応えて、前記識別されたアイテム又はサービスに関係付けられた前記取引を実行するように、サーバーシステムに要求を送る段階とを備えており、
   前記取引は、前記ユーザーがコンピューターインタフェース上で何ら操作を行うことなく実行されることを特徴とする方法。
2. 前記アイテム又はサービスを識別する情報を提供する前記段階は、アイテム又はサービスの類別を選択的に識別する段階を備えていることを特徴とする、請求項１に記載の方法。
3. 前記アイテム又はサービスの類別を選択的に識別する前記段階は、アイテム又はサービスの類別の属性を選択的に識別する段階を備えていることを特徴とする、請求項２に記載の方法。
4. 前記実行される取引は購入であることを特徴とする、請求項１に記載の方法。
5. 前記実行される取引は入札であることを特徴とする、請求項１に記載の方法。
6. 前記取引の実行中に、前記識別されたアイテム又はサービスに関係する広告を選択的に提供する段階を更に備えていることを特徴とする、請求項１に記載の方法。
7. 広告を選択的に提供する前記段階は、前記識別されたアイテム又はサービスとは異なるアイテム又はサービスに関する広告を提供する段階を備えていることを特徴とする、請求項６に記載の方法。
8. 実行されることになる取引について、前記広告されたアイテム又はサービスに関連する問合せを提供する段階を更に備えていることを特徴とする、請求項７に記載の方法。
9. インターネット上での取引を処理できるようになっている音声制御式取引サービスにおいて、
   ユーザーインタフェースと、
   前記ユーザーインタフェースと連結されている少なくとも１つのデータベースとを備えており、前記ユーザーインタフェースは、ユーザーとの音声通信を調整し、前記音声通信は、アイテム又はサービスの情報と、前記アイテム又はサービスに関連する取引とを含み、前記少なくとも１つのデータベースはアイテム及びサービスの情報を記憶しており、
   従って、前記ユーザーがボタンを押すことなく、マウスをクリックすることなく、或いは計算装置へ手動で入力することなく、取引が実行されることを特徴とするサービス。
10. 少なくとも１つのデータベースと連結されているネットワークインタフェースを更に備えており、前記ネットワークインタフェースは、前記インターネット上で前記アイテム及びサービスの情報にアクセスし、前記アイテム及びサービス情報に関係付けられた要求を処理し、前記識別されたアイテム又はサービスに伴う取引を実行するよう構成されていることを特徴とする、請求項９に記載のサービス。
11. 少なくとも１つのウェブサイトから得られた情報を比較して、複数のウェブサイトから集められた情報に対応する標準的なデータファイルを選択的に確立するよう構成されているフュージョンエンジンを更に備えていることを特徴とする、請求項１０に記載のサービス。
12. 前記サービスに関係付けられたユーザーの嗜好及びユーザーの行動と関連するユーザー情報を記録するように構成されている顧客マネジャーを更に備えていることを特徴とする、請求項９に記載のサービス。
13. 前記顧客マネジャーは、ユーザーインタフェースが特定のユーザーに対しサービスを個人向けにするように、ユーザー情報をユーザーインタフェースに提供するよう構成されていることを特徴とする、請求項１２に記載のサービス。
14. 前記ユーザーインタフェースに広告を選択的に提供するよう構成されている広告サブシステムを更に備えていることを特徴とする、請求項９に記載のサービス。
15. 前記広告サブシステムは、ユーザーに関する情報に基づいて特定のユーザーに的を絞った広告を、前記ユーザーインタフェースに提供することを特徴とする、請求項１４に記載のサービス。
16. 前記少なくとも１つのデータベースと連結されているイグジスタンツサブシステムを更に備えており、前記イグジスタンツサブシステムは前記少なくとも１つのデータベースに出入りする全情報を管理するよう構成されていることを特徴とする、請求項９に記載のサービス。
17. インターネットベースの情報へのアクセスと、ユーザーが電話による音声を使ってサービスと通信するインターネットベースの取引の実行とを提供するためのサービスにおいて、
    アイテム又はサービスを識別する情報を提供し、前記識別されたアイテム又はサービスに関係付けられている、実行されることになる取引についての問合せを提供するための手段と、
    前記提供された質問に対するユーザーの回答に応えて、前記識別されたアイテム又はサービスに関係付けられた前記取引を実行するよう、要求をサーバーシステムに送るための手段とを備えていることを特徴とするサービス。
18. アイテム又はサービスを識別する情報をデータベースから検索するための手段を更に備えていることを特徴とする、請求項１７に記載のサービス。
19. アイテム又はサービスを識別する情報をデータベースから検索するための前記手段は、インターネットから情報を検索するための手段を備えていることを特徴とする、請求項１８に記載のサービス。
20. 通信装置を使って、アイテム又はサービスに関係する取引を実行するためのコンピューター読み取り可能プログラムコードを備えているコンピュータプログラム製品において、前記コンピュータプログラム製品のプログラムコードは、
    前記アイテム又はサービスを識別する情報を提供するための第１コンピューター読み取り可能プログラムコードと、
    前記識別されたアイテム又はサービスに関係して実行されることになる取引についての問合せを提供するための第２コンピューター読み取り可能プログラムコードと、
    前記問合せに対するユーザーの返答に応えて、前記識別されたアイテム又はサービスに関係する取引を実行するよう、サーバーシステムへ要求を送るための第３コンピューター読み取り可能プログラムコードとを備えており、従って、ユーザーが手動操作を行うことなく、前記取引が実行されることを特徴とするコンピュータプログラム製品。
21. インターネットから情報を収集するための第４コンピュータープログラムコードを更に備えていることを特徴とする、請求項２０に記載のコンピュータプログラム製品。
22. 最適な取引を選択するために、複数の取引の間で比較を実行するための第５コンピュータープログラムコードを更に備えていることを特徴とする、請求項２０に記載のコンピュータプログラム製品。

Images