JP2001525951A - コンピュータ・ネットワークにおいて、広告を設置する方法およびシステム - Google Patents

Abstract

(57)【要約】 コンピュータ・ネットワークにおいて広告を行うシステムおよび方法。広告の収集を収容したサーバにコンピュータ・ネットワークと電子的通信を行わせる。サーバ上の広告はネットワーク上の情報を収容したいかなる特定のページとも関連していないで、むしろユーザ（１７）によりエンターされたクエリーに応答してレトリーブされ、およびクエリー（１６）に応答してリターンされたページのコンテントとダイナミックに混合される。本発明によれば、コンテント・ページを、特定のレイアウトに応じて、そのページの一部分としてフォーカスされかつ目標とされた広告をディスプレイする。広告は、広告主により要求された一組のコンストレイント（拘束）（１９）およびそのページのパブリッシャのコンストレイントを満足するようなされ得る。このシステムは、広告を特定のクエリーとリンクさせるマーケティング・ルール（１８）を特定し、広告主が特定の視聴者を目標とすることを許容し、および最上の広告スペースにある量の広告がなされることを保証する契約（２１）を用いる。契約のコンシステンシイ（首尾一貫性）をチェックするアルゴリズムを用いて、受付けられたすべての契約が適切に満足されていることを保証する。本発明は、ダウンロード遅延時間広告機能をも提供する。

Description

【発明の詳細な説明】 コンピュータ・ネットワークにおいて、 広告を設置する方法およびシステム 開示における著作権保護資料の通知 本特許明細書の開示部分に著作権保護の対象となる資料を含む。著作権者は特 許商標庁のファイルや記録に現れる特許明細書、または特許の開示を何人がファ クシミリで複製することに対して異存はないが、それ以外に対してはいずれのも のについて、全ての著作権を有する。 背景技術 技術分野 本発明は、一般的に広告に関し、より詳しくは広域ネットワークあるいは都市 エリアネットワークのようなコンピュータ・ネットワークにおいて広告を設置す るための方法およびシステムに関する。 従来技術 多数の情報サービスがインターネットのような広域公共ネットワーク上で提供 されている。これらのサービスの基本モデルでは問い合わせ（またはキーリー、 ｑｕｅｒｙ）が情報処理され、１組の回答が返送される。たとえば、ディレクト リを検索可能な多数のイエローページが発達し、それらにおいてユーザは製品ま たはサービスのカテゴリーを問合せ、システムがその問い合わせを満足するベン ダーセットを返送する。 これらのサービスに伴う１つの問題は、サービスを使用するエンドユーザの費 用に対してだれが補助金を与えるかを決定することである。このような補助金を 提供する１つの方法は広告の使用を通じて行うことである。 インターネットのような公共ネットワークでは広告の乱用が見られ始めている。 たとえば、公共ネットワーク上のある検索（サーチ）エンジンのスポンサーは１ つのベンダーまたは会社である。他の検索エンジンでは固定された広告セットか らランダムに選択された広告を表示する。 １つの例として、ワールド・ワイド・ウェブ（“ＷＷＷ”）は広告のホック（ ｈｏｃ）手段を現在使用している。すなわち、ユーザが検索のためにある検索エ ンジンを使用するとき、ユーザは検索を行っている間、広告を見るであろう。こ れらの広告はときどき、ユーザがコンピュータ上の“道”を旅しているときにユ ーザが見る標識（ｂａｎｎｅｒ）になぞらえて、見出し（“ｂａｎｎｅｒ”）広 告と呼ばれる。これらの広告は典型的にはユーザが検索の間、遭遇する個々の検 索ページと結びついている。 現在の技術の状態ではユーザが検索エンジンを使用するとき、ランダムに選択 された広告はあたかも検索ページの一部分のように見える。たとえば、ユーザが 検索要求を入力してあるページの一部分をなす料理についてのホームページを見 ようすると、既存のシステムは車についての広告を表示するかもしれない。これ は１つの問題である。もちろん、広告の内容もしくは広告のメッセージとユーザ が実際に検索しようとしていることとの間には何の関係がないからである。現在 の技術に伴う他の問題は、ある回数だけ、またはそのページ上の他のデータ部分 に関連するページのある場所において、見えるであろう広告の関連性については 何の保証もないということである。これらの理由のために、インターネットのよ うなコンピュータ・ネットワーク上で広告を設置する既存のシステムでは、オン ライン・メディアの対話／要求駆動の環境の利益を受けることができない。 発明の開示 本発明の目的はコンピュータ・ネットワーク上に、詳しくは、広域ネットワー クまたは都市エリアネットワーク上に広告を設置し、上述の既存の広告システム の問題を解決する改良方法および改良システムを提供するこ とにある。 本発明のさらなる目的は、パーソナルコンピュータを持つものがだれでもコン ピュータ・ネットワーク上で広告することができる有効的な広告メディアを提供 することにある。 本発明のさらなる目的は、広告が、より多くの情報を持ち、広告される製品ま たは情報、さもなくば、広告主についての付加情報に対して直接リンクする広告 方法およびシステムを提供することにある。 本発明のさらなる目的は、広告がたとえば、システムとのユーザの対話の過去 の履歴を含むユーザの問い合わせやユーザのプロファイルによりフォーカス的で あって、ターゲットに合致したコンピュータ・ネットワーク上の広告方法および システムを提供することにある。 本発明のさらなる目的は、新しいオンライン・パブリシャー（ｏｎｌｉｎｅ ｐｕｂｌｉｓｈｅｒｓ）が少ない労力で作成することができる広告方法およびシ ステムを提供することにある。 本発明のさらなる目的は、ある回数だけ、または特別な方法で、または、特別 な環境下で広告を表示することを保証することができる広告方法およびシステム を提供することにある。 本発明のさらなる目的、利益および新規な特徴は以下に述べられている説明で 明らかにななるであろう。また、当業者であれば説明または本発明の実施形態を 読めば明らかになるであろう。本発明の目的と利益は添付の特許請求の範囲によ り実現され、得られる。 本発明はオンライン広告のための新しい処理とシステムを与える。新しい処理 を本明細書を通じては基本キーリー広告（ｑｕｅｒｙ−ｂａｓｅｄａｄｖｅｒｔ ｉｓｉｎｇ（“ＱＢＡ”）と呼ぶことにする。ＱＢＡプロセスでは広告は最初に はユーザ・キーリー（ｑｕｅｒｉｅｓ）により起動する。ここで使用されるユー ザ・キーリーはコンピュータ・ネットワークからの１またはそれ以上の情報ペー ジに関する情報消費者（ｉｎｆｏｒｍａｔｉｏｎ ｃｏｎｓｕｍｅｒ）からの要 求情報である。キーリーの結果としてユーザは本発明の広告にさらされる。 本発明によれば、集められた広告を含むサーバはコンピュータ・ネットワーク と接続する電子的なコミュニケーション中に設置される。コンピュータ・ネット ワークは好適にはインターネットまたは都市エリアネットワークのような広域ネ ットワークである。本明細書で使用されているようにフレーズ“コンピュータ・ ネットワーク”はなんらかの公共あるいは私的なデータ通信ネットワークを意味 する。 サーバ上の広告は情報を含むコンピュータ・ネットワーク上の個々のいずれの ページとも結びつけられていない。むしろ広告はサーバ上に含まれ、後で広告を 行わないページとは区別されている。このため、ページそれ自体は、広告を含ま ない。このため、上記ページは広告が全くない新聞や雑誌によく似ている。 ユーザがあるページまたはある情報トピックを要求すると関連のあるページは コンピュータ・ネットワークからレトリーブ（ｒｅｔｒｉｅｖｅ）され、ユーザ に対して表示される。本発明は、ユーザの要求の受信に応じて、ユーザのアクシ ョンに関連する広告をレトリーブし、動的に広告を個別のレイアウトに従ってペ ージの内容とミックスし、フォーカスされ、ターゲットとされたページ部分を持 つページを表示する。広告はページのパブリシャーの制約と同様にして、広告主 が要求する制約を満足するように行うことができる。 本発明の広告起動メカニズムはランダムや偶発的ではない。むしろ、前もって 規定されている。本明細書ではこのアプリケーションをコントラクト（ｃｏｎｔ ｒａｃｔ）と呼ぶことにする。コントラクトは広告を特定のキーリーとリンクさ せるマーケッティング・ルールを規定している。たとえば、ダイエット・ソフト ・ドリンクの広告はユーザが体操用器具についてのページについて問合せたとき に表示される。これらのルールは広告の“フォーカス”または“関連性”の概念 を有し、特定の視聴者を広告がターゲットとする上で助けになる。ページのオー ナーはそれらのページのフォーカスの内容をページ内の特別なタグを通じて規定 する。これらのタグは消費者に対しては表示されない。タグは消費者にによりペ ージが要求さ れたときに、どの広告を表示すべきかを決定するために使用される。 けれどもコントラクトの概念はまさにマーケッティング・ルールを超えててい る。結局、オンライン・メディア上の広告スペースは、技術的には制約がないけ れども、ユーザの注目する範囲が厳しく限定される。キーリーに対する回答で構 成する最初のページ上に広告を設置することは、後の回答のページよりも見られ る確率が非常に高い。このことは新聞のある範囲の広告、すなわち、新聞の後の ページよりも新聞の先頭のページの広告方が値段が高い広告に似ている。このた め、本発明は、ＱＢＡの一部分としてプライム・スペース（ｐｒｉｍｅ ｓｐａ ｃｅ）の概念を導入している。 プライム・スペースは原理的にはテレビのプライム・タイムのように魅了的で ある。プライム・スペースはプライム・タイムのように制約を受け、そのため、 プライム・スペース中に全ての関連のある広告を見せることは不可能である。プ ライム・スペースに対する制約に対する解決として、本発明ではコントラクトの 使用を通じて広告主に対して保証を与える。コントラクトはそのような保証を規 定したツールを提供し、それらを強制実行する。特に本発明では以下の種類の保 証（すなわち、“コントラクト”）を広告主に対して提供する。 １．基本レシオ：ａｄ（広告）はプライム・スペース中であるパセンテージの回 数以上、検索者が行ったキーリーに関連して表示される。 ２．排他的または競合的：ａｄ Ａはプライム・スペースではＢが表示されてい るときには決して表示されることはない。 ３．従属性：ａｄ Ａはａｄ Ｂがプライム・スペースで表示されているとき予 め定められた確率で表示される。 ４．ストーリー：いくつかのサブａｄで構成される１つのａｄが順次に消費者に 対してプライム・スペース中で表示される。 ５．基本周期：ａｄはプライム・スペース中である与えられた時間中にある回数 だけ表示される。 さらにコントラクトはレイアウトのタイプを規定してａｄとデータとを ミックスする。これはレイアウトタイプ等を含む。 本発明はまた、満足しないなんらかのコントラクトがあるかの判定をを行う手 段を提供する。たとえば、プライム・スペースが２つのａｄだけを保持する広さ であれば２つのａｄ以上に対しては１００％のレシオで保証を行うことは不可能 である。同様に、ａｄ Ｂが表示されているときにａｄ Ａを表示しないのであ れば、また、ａｄ Ａ およびａｄ Ｂをフォーカス・マッチングにしたがって 、同等に関連付けるのであれば、その結果、ａｄ Ａ および Ｂに対して５０ ％以上のレシオを保証することは不可能である。本発明はコントラクトに対する 一貫性をチェックするアルゴリズムを使用して受け付けられた全てのコントラク トが適切に満足することを確認する。広告主はあるコントラクトを求めることが できる。(たとえば、プライム・スペースの５％の範囲の適用)本発明はまた、コ ントラクトが満足できるかをも判定する。もし、そうでなければ、システムはそ れが提供する範囲を提案する。コントラクトが一貫していると判定された後は、 本発明はコントラクトにしたがって広告を表示することによりコントラクトを強 制実行する。 ＱＢＡの結果として、ページ上に設置されるａｄを決定するのはキーリーであ るので、ａｄはプリオリ（ｐｒｉｏｒｉ）のページには設置されない。システム 内に常駐するａｄはチェックされて質問においてどのａｄをページ上に置くこと ができるかが決定される。この決定はａｄのフォーカスとページのフォーカスと のマッチングに基づいている。スペースの制約故にページ上に全てのマッチング するａｄを設置することはできないときには、本発明のコントラクト強制実行特 徴はページ上に設置されるａｄをシステムによりサインされた広告主とのコント ラクトに一致させることを確認する点にある。 ＱＢＡの他の結果としてはページのどこに広告が設置されるかが決定されるこ とにある。現在、ＷＷＷ上のページはページ上の広告のための固定のプリオリの 同意エリアを有する。本発明は、けれども、広告をどこに設置すべきかを動的に 決定する。本発明はページのオーナーに対してページ のレイアウトを自由に構築することを許容している。ページのオーナーは広告が どこに設置されべきではないかの最終決定を行う。ページが構築されると、ペー ジのオーナーはページ上の特別のタグ（“ａｄ スペース”）の設置によりどこ に広告が設置されるべきかを規定する。フォーカス・タグのようにこのａｄスペ ース・タグは消費者にとっては見ることができない。タグが広告、として利用可 能なスペースを示すということは広告システムに対して指導性がある。すなわち 、タグは“このスペースは広告として利用可能”と述べるビルボードと考えるこ とができる。 本発明は、また、遅れて広告の特徴をダウンロードすることができる。多くの インターネットのようなコンピュータ・ネットワーク上の消費者は、彼らがペー ジを求めた時点から彼らのブラウザにダウンロードされるまでの時間が遅れる経 験を持っている。この遅れは、たとえば、ＷＷＷ上のトラフィックの混雑により 生じる。この遅延時間はダウンロード遅延時間と呼ばれる。 本発明は、ダウンロード時間を使用してａｄを消費者に対して表示する。これ をダウンロード遅延時間・広告と呼ぶ。消費者がページのためにダウンロードす るのに浪費する時間は、ａｄを消費者に見せるのに使用される。一度、ページ（ または、ページのサブパート）が消費者のブラウザに対してダウンロードされ、 表示可能になると、ａｄはページ内容と置換される。消費者は本発明により広告 によって遅延を経験することはない。前に存在する遅延時間のみが広告システム により使用される。 サマリーとして、本発明は、複数の広告を有するサーバと、サーバーをコンピ ュータ・ネットワークに電子的に結合する手段と、ネットワーク上でエンターさ れたキーリーに応じてサーバから広告を選択し、レトリーブする手段とを具えた コンピュータ・ネットワーク上の広告のための方法およびシステムを提供する。 選択手段は選択されたキーリーが広告と関連があることを確認する手段を含む。 ミキサー手段はキーリーに応答してコンピュータ・ネットワークにより返送され るページ内容(ｃｏｎｔｅｎｔ ｐａｇｅ)とレトリーブされた広告を結合するた めに与えられる。 ミキサー手段はミキサー手段はレトリーブされた広告およびページ内容を含む 結合のページの最適レイアウトを計算するための手段を含む。ミキサー手段は、 ページ内容中の特別なタグおよびＨＴＭＬルールを検出し、選択された広告をペ ージ内容のどの部分に表示できるかを決定するための印刷マネージャー(ｔｙｐ ｏｇｒａｐｈｙ ｍａｎａｇｅｒ)手段を含む。ページ内容はホームページディ スパッチャー、検索エンジン、または一般的なＨＴＭＬ コンテント・プロバイ ダーによりキーリーに応答して与えられる。 トランザクション手段は表示された広告と対話することにより広告主とユーザ がトランザクションを行うことができるように提供される。プライム・スペース ・マネージャー手段は広告がサーバー上に含まれとき、各広告と関連のある好適 なアドバータイザー・コントラクトに基づく制御を実行するために提供される。 ａｄ設置手段はサーバ上の新しい広告を設置するために提供され、ａｄ設置手 段は、サーバ上に設置された各アドバイタイザー・コントラクトをエンターする ための手段および既存のアドバータイザー・コントラクトと一貫性をもたせるた めに新しいアドバータイザー・コントラクトをチェックするための手段を有する 。ローカルクライアント手段はユーザがキーリーに応答してダウンロードすべき ページ内容を待つ間だけ、レトリーブされた広告を表示するために提供される。 ユーザが行動していない予め定められた時間の後、表示された広告をリフレッシ ュする手段およびページ内容がクライアントに受信されると同時に、示された広 告をダウンロードされたページ内容と置換する手段もまた、提供される。システ ムはキーリーに対する検索の概略時間を計算するための手段および検索概略時間 を含むページおよびレトリーブされた広告を結合するための手段を含む。システ ムはまた、ユーザの地理的な位置を決定する手段およびユーザの地理的な位置に 基づいて広告を決定する手段を有する。 図面の簡単な説明 本発明は、本発明の開示は添付の図面を参照して行われているので、本発明は より明確に理解できよう。ここで、 図１は本発明の一般的な主要コンポーネント全体を示すブロック図である。 図２はコンピュータ・ネットワークのイエロー・パブリシャーにより提供され るページ内容上に広告を設置する処理を示すフローチャートである。 図３Ａ−図３Ｄは図２のプロセス中の種々のステップの間で表示されるページ の画面出力を示す図である。 図４は本発明のレイアウトマネージャーにより実行される処理を示すフローチ ャートである。 図５は本発明のパーサーにより実行される処理を示すフローチャートである。 図６は本発明のミキサーおよびセレクターにより実行される処理を示すフロー チャートである。 図７はコンピュータ・ネットワークのホームページのパブリシャーにより与え られるオンライン・ページ中にターゲットの広告を設置するための処理を示すフ ローチャートである。 図８Ａ−８Ｃは図７に示す処理の種々のステップで表示されるページの画面出 力を示す図である。 図９Ａおよび９Ｂは本発明にしたがった為替（ｂｉｌｌｉｎｇ）システム処理を 示すフローチャートである。 図１０は本発明にしたがったａｄ設置処理手順を示すフローチャートである。 図１１は本発明にしたがったａｄ設置処理手順を示すフローチャートである。 図１２は本発明にしたがったトランザクションのアーキテクチャーを示す図で ある。 図１３Ａおよび１３Ｂは本発明のトランザクション処理中の種々のステ ップの間に表示されるページの画面出力を示す図である。 図１４は本発明にしたがったトランザクション処理の手順を示すフローチャー トである。 図１５は本発明のプライム・スペースマネージャーにより実行される処理を示 す図である。好適実施例の詳細な説明 以下、添付図面に図示されている好適実施例について詳しく説明する。 図１は、本発明のメイン・コンポーネントの全体的概要または空間的アーキテ クチャを示す図である。レイアウト・マネージャ１０は主にクライアントに表示 されるページのレイアウトの計算を担当する。システムの他のモジュールは、以 下で説明するように、表示すべき必要なデータを計算する。レイアウト・マネー ジャ１０は他のモジュールからのこのデータを受け取ると、ディスプレイ用の最 適レイアウトを計算する。 レイアウト・マネージャ１０は２つのサブコンポーネントを使用して最適レイ アウトを判断する。つまり、レイアウト・マネージャ内のルール・ベースとレイ アウト・データである（図１には、レイアウト・ルール・コンポーネント１１と 総称して示されている）。レイアウト・データ・ベースは事前に定義され、レイ アウト・データ・ベースにストアされたテンプレートのコレクションから構成さ れている。ルール・ベースはどのセットの条件のもとでどのレイアウト・テンプ レートが最良であるかを確かめるためにユーザまたはレイアウト・マネージャの プレーサ（ｐｌａｃｅｒ）によって定義されたルールのコレクションから構成さ れている。レイアウト・マネージャ１０は表示すべきデータを受信すると、レイ アウト・ルール内の種々ルールを呼び出して、どのルールをトリガすべきかを計 算し、従って、現在の条件セットのもとで最良とされるレイアウトの１つを判断 する。 ルールで使用される変数には、表示すべきデータの量、表示すべきデータの種 類、テキストの量、広告資料の量、および表示すべき種々マップとマルチメディ ア・アイコンがある。これらの変数に基づいて、ルールがチェックされ、検出で きる最良レイアウトを表すものとして１つまたは２つ以上のルールが選び出され る。この場合、レイアウト・マネージャ１０は最良と思うルールの１つを任意に 選び出し、そのレイアウトを選び出し、レイアウト・マネージャが受け取ったデ ータをレイアウト・テンプレートに挿入し、表示すべき最終的製品をクライアン トに引き渡す。 ルールの中で表現されている変数はいくつかのパラメータに基づいている。そ のようなパラメータとしては、テキストのサイズ、テキストの量、マップのサイ ズ、イメージのサイズ、および広告のサイズなどがある。原則的には、レイアウ ト・マネージャ１０を使用して達成することができるパラメータの数には制限が ない。ルールは、好ましくは、プログラミング言語で表現され、与えたいと思っ ている他のどのパラメータでも受け入れるように一般化されている。 レイアウト・ルールは種々のパラメータに基づいて構築される。構築されたレ イアウト・ルールはチェックされ、ある種のデータ状況に合わせて使用される正 確なテンプレートを突き止めるために使用される。このテンプレートはレイアウ ト・マネージャ１０によって埋め込まれ、クライアントへのディスプレイが得ら れる。 次に、セグメンタ（ｓｅｇｍｅｎｔｅｒ）１２について説明する。このセグメ ンタ１２はＨＴＭＬページを分析し、ＨＴＭＬページから関係データを抽出する ことを担当する。セグメンタ１２の目的は、別のコンポーネントまたは他のコン テント・プロバイダによって構築されたページがシステムに渡されたとき、ある 広告を動的に挿入できる、そのページ内の妥当な場所を見つけることである。 セグメンタ１２は種々のルールを使用してページ内の広告スペースを探し出し 、そのページの基本的レイアウトが混乱するのを防止する。具体的には、セグメ ンタ１２はＨＴＭＬページの設計者によって挿入されたある種の特殊タグを探し 出し、セグメンタが受け取った広告または他のタイプの情報をその特殊タグの個 所に挿入する。次に、セグメンタ１２はページを調べ、広告をどこに挿入すべき かを判断し、その情報をレイアウト・マネージャ１０に渡す。 ほとんどの場合、タイポグラフィ・マネージャ（ｔｙｐｏｇｒａｐｈｙ ｍａ ｎａｇｅｒ）１４はレイアウト・マネージャ１０への主要入力デバイスである。 これの例外については、後述する。タイポグラフィ・マネージャ１４の役割はペ ージを「レンダリング（ｒｅｎｄｅｒ）」することである。ページをレンダリン グするとは、タイポグラフィ・マネージャ１４があるページで送るべき種々の入 力を受け取り、情報のどの部分をそのページで送るべきか、情報のどの部分を実 際に削除できるかを判断することである。従って、タイポグラフィ・マネージャ １４は機能的には従来のパブリッシングの場合のタイポグラファと同じであ る。 タイポグラフィ・マネージャ１４は、どのデータをレイアウト・マネージャ１ ０に送るべきかの最終的発言権をもっている。タイプグラフィ・マネージャ１４ は、ＨＴＭＬページのマークアップがどこで起こっていると思われるかをタイポ グラフィ・マネージに指示する特殊タグと特殊ＨＴＭＬルールも検出する。最終 的には、レイアウト・マネージャ１０とタイポグラフィ・マネージャ１４は共同 してページの補充を行う。最終形式のこのページはゲート１５に渡される。 ゲート１５はページを本発明のシステムからクライアントに転送する。従って 、ゲート１５はクライアントとサーバ間のゲートの働きをする。ゲート１５は表 示しようするページをＷＷＷ Ｄａｅｍｏｎ １６に渡し、Ｄａｅｍｏｎの方は ユーザのサイトにいるクライアント１７とやりとりする。 レイアウト・マネージャ１０、セグメンタ１２、タイポグラフィ・マネージャ １４、およびゲート１５がどのような働きをするかは以上に説明した通りである 。システムの残りのコンポーネントを詳しく説明する前に、システムを通るリク エスト（要求）の流れの例を説明することにする。 最初に、ユーザはクライアント１７の１つを通して特定の情報部分を要求する 。ユーザのリクエストはＷＷＷ Ｄａｅｍｏｎ（デーモン）１６に渡され、この デーモンはその情報をゲート１５に渡す。ゲート１５はこの時点で、どの情報部 分がユーザによって要求されているかを判断し、ユーザが要求したものと混合で きる他の関係情報部分を探し出す。例えば、ユーザはあるカー・ディーラを調べ 、カー・ディーラの電話番号を探し出し、あるいは特定の雑誌のページを得るこ とをシステムに要求する場合がある。 ゲート１５はこの時点で、リクエストをマッチング・ルール・エンジン（ｍａ ｔｃｈｉｎｇ ｒｕｌｅ ｅｎｇｉｎｅ（ＭＲＥ）１８に渡す。ＭＲＥ１８の目 的はユーザのクエリー（照会）の内容を調べ、同一タイプに一致するカテゴリを そのアクティブ・インデックスＳＩＣ １９内から見つけることである。ユーザ がカー・ディラーを要求していれば、ＭＲＥ１８はそのルールを呼び出し、カー ・ディラーが輸送に関係する事物のクラスの一部であるかどうかを判 断する。ＭＲＥ１８によって判断された分類に基づき、システムはユーザがカー または輸送について、あるいはユーザが関心を持っている他の事物について尋ね ていることを知ることになる。 ＭＲＥ１８はこの時点で、ユーザのクエリーのカテゴリ・インデックスをゲー ト１５に戻す。ユーザがカーまたはファミリ・セダンについて、あるいはスポー ッカーについて尋ねていれば、この時点で、ＭＲＥ１８はユーザの関心があるカ テゴリに属することを判断している。ユーザの関心カテゴリに基づいて、システ ムはそのカテゴリに関係する広告をリトリーブ（検索）する。従って、ＭＲＥ１ ８の目的はユーザがなにを要求したかを判断し、ユーザのリクエストを分類シス テムのカテゴリ（つまり、アクティブ・インデックスＳＩＣ１９）に入れ、その 分類に基づいて、関係する広告をリトリーブすることである。この時点では、ユ ーザのリクエストを収めているカテゴリからリトリーブされた関係広告は数百に なっている可能性がある。これが問題となるのは、ユーザのリクエストに関係す る広告が最初の情報ページでユーザに表示できるよりも多くなっていることであ る。この時点で、プライム・スペース・マネージャ（ｐｒｉｍｅ ｓｐａｃｅ ｍａｎａｇｅｒ）２０が活動する。プライム・スペース・マネージャ２０の目的 はユーザに表示すべき広告に優先順位を付けることである。 例えば、５つの広告用のスペースしか残っていないで、ＭＲＥ１８が表示すべ き５００個の広告のリストを戻したとすると、システムはどの５つの広告を表示 すべきかを判断しなければならない。プライム・スペース・マネージャ２０のオ ペレーションは、広告者が広告をシステムに入れたときに受け付けた契約に基づ いている。システムは基本的契約として次の５つのタイプをサポートしている。 １．比率に基づく契約：広告は関係クエリーがサーチャによって行われる時間 の一定パーセンテージだけプライム・スペースに表示される。 ２．従属型：広告Ａは広告Ｂがプライム・スペースに表示されるとき事前に決 めた確率で表示される。 ３．排他型または競合型：広告Ａは広告Ｂが表示されるときプライム・スペー スに表示されることがない。 ４．ストーリ型：いくつかのサブ広告からなる広告はコンシューマに対して特 定のシーケンスでプライム・スペースに表示される。 ５．頻度に基づく契約：広告はある時間期間内に一定回数だけプライム・スペ ースに表示される（例えば、毎月１００回）。 上記のほかに、契約は広告をデータと一緒にミックスするために使用されるレ イアウトのタイプを指定することもできる。この中には、レイアウトのタイプそ の他が含まれる。以下では、システムによって使用される種々の契約について詳 しく説明する。 比率に基づく契約は広告者が広告を時間の一定パーセンテージだけプライム・ スペースに表示することを望んでいる場合に使用される。言い換えれば、広告者 のビジネスに関係するクエリーが受信されたときは、広告者には、広告が時間の 一定パーセンテージだけユーザに表示される最初の情報スクリーンであることが 保証される（例えば、時間の１５％）。このパーセンテージはカバレッジ保証（ ｃｏｖｅｒａｇｅ ｇｕａｒａｎｔｅｅ）と呼ばれる。比率に基づく契約は、広 告者の広告が関係するクエリーが行われるたびに時間のＸ％だけ表示されるとい うカバレッジ保証を広告者に提供する。この保証は確率的性格を持っているので 、システムが長時間稼働している間に、この確率は広告者が要求したパーセンテ ージに収束することになる。 システムがサポートする第２のタイプの契約は従属型契約と呼ばれる。従属型 契約は、ある広告者の広告が他の広告者の広告と一緒に同じスクリーンに表示さ れることを保証する。例えば、トラベル先広告（例えば、「バハマへ行こう」） はクレジットカード広告（例えば、「チケットの支払いはＶＩＳＡで」）と一緒 に最初の情報スクリーンに表示することができる。このタイプの契約によると、 システムは２またはそれ以上の広告の要求を同時に満たす契約をサポートするこ とができる。 システムがサポートする第３のタイプの契約は排他型または競合型契約と呼ば れる。このタイプの契約を使用すると、広告者の広告が競争会社の広告と同時に または同じスクリーンに表示されないことが保証される。例えば、ある飲料メー カ（例えば、コカコーラ）は競争会社の飲料メーカ（例えば、ペプシ）の広告が 自社の広告と同時に表示されるのを禁止することができる。逆の場合も同様であ る。 第４のタイプの契約はストーリ型契約と呼ばれる。このタイプの契約は２また はそれ以上の広告のシーケンスが一緒に表示される広告パッケージを保証するた めに使用される。広告は、あるユーザが広告の最初の部分を見た後、広告の第２ の部分を見、次に広告の第３の部分を見るといったように表示できる。例えば、 コーヒの広告では、最初のページの絵にはコーヒを飲んでいる人が表示され、第 ２のページの絵にはコーヒ・カップを飲みほしている人が表示され、第３のペー ジには広告者の製品の名前が表示されていることがある（例えば、“Ｍａｘｗｅ ｌｌ Ｈｏｕｓｅ ｍａｋｅｓ ａ ｇｏｏｄ ｃｕｐ ｏｆ ｃｏｆｆｅｅ” ）。 以上のように、ストーリ型契約は、広告者の広告がストーリの形で表示される ことを保証する。ストーリ型契約が望ましいとされるのは、広告群が意味を持つ ように特定の順序で一緒に表示される場合である。 第５のタイプの契約は頻度に基づく契約である。この契約が使用されるのは、 広告がある時間期間に一定の回数だけ表示されることを保証することを広告者が 望んでいる場合である（例えば、毎週１００回）。 上述したタイプの契約を数通りに組み合わせて使用することも可能である。例 えば、広告者は自社の広告が競争会社の広告が表示されるのと同時に表示されな いこと、広告が関連広告が表示されるのと同時に表示されること、および広告が 時間の一定パーセンテージだけプライム・スペースに表示されることを保証する ストーリ型契約を結ぶことができる。 プライム・スペース・マネージャ２０はユーザが要求した情報と一緒に表示で きる可能な限りの広告を判断することを担当する。次に、プライム・スペース・ マネージャ２０はどの広告を表示すべきかを、署名された特定の契約に基づいて 判断する。ある契約がその広告者の競争会社とすでに結ばれていれば、プライム ・スペース・マネージャ２０はその広告者との新しい契約を実際に待たすことが できるかどうかを確かめることになる。従って、プライム・スペース・マネージ ャ２０は表示が可能とされる広告の量と数が与えられているとき、どの広告を 表示すべきかの判断を動的に行う。プライム・スペース・マネージャ２０の計算 の最終結果は、広告がユーザに表示できることおよび表示されることをシステム に正確に知らせることである。 次に、これらの広告はゲート１５に渡される。ゲート１５はこの時点で、広告 をタイポグラフィ・マネージャ１４に渡し、タイポグラフィ・マネージャ１４は 情報を表示する最良の方法を判断する。次に、ページ情報はゲート１５に戻され 、クライアント１７に転送される。 本発明の上述した説明では、広告契約、アクティブ・インデックスＳＩＣ１９ 、レイアウト・ルール１１、セグメンタ１２、セグメント・ルール１３、レイア ウト・マネージャ１０、およびタイポグラフィ・マネージャ１４について説明し た。 広告の計算および本発明のシステムが実行する他のすべての計算の期間に、シ ステムのロギング・モジュール（ｌｏｇｇｉｎｇ ｍｏｄｕｌｅ）２２はユーザ がなにを要求したか、どの広告が表示されたか、広告がどのように表示されたか 、どの広告がどのユーザに表示されたかの、広範なロギングを行っている。その あと、ロギング・モジュール２２はこれらのログをＳＹＳログ・データベース２ ３にストアする。種々のスキャン・レポートはＳＹＳログ・データベース２３内 の情報を使用して作成し、定義することができる。 本発明のローカル・クライアント２４はダウンロード・ディレイタイム広告機 能を備えている。ダウンロード・ディレイタイムとは、あるページが表休された 瞬時からそのページがユーザのブラウザにダウンロードされる時点までにコンピ ュータ・ネットワークの多くのユーザに起こる遅延のことである。ダウンロード ・ディレイタイム広告機能はページがダウンロードされるのをコンシューマが待 っている時間を利用して、コンシューマに広告を見せる。ページ（またはページ のサブ部分）がコンシューマのブラウザにダウンロードされて、表示できるよう になると、広告はページ内容によって置き換えられる。 多くのケースでは、ユーザがあるページを要求したとき、相当のダウンロード ・ディレイタイムが発生する。ユーザは要求した後、ページが最終的にネットワ ークによってダウンロードされるまでに数秒間、場合によっては、数分間ペー ジを待たされることになる。本発明はこのディレイタイムを利用して広告を表示 すると共に、ユーザのディレイタイムが広告の表示によって増加しないように配 慮する。従って、広告が表示される唯一の時間はユーザがなんらかの理由で待た されている時間である。ユーザがページを待っている間、ユーザはローカル・ク ライアント２４で広告を見ることができる。 図１に示す情報ブローカまたはコンテント・プロバイダはホームページ・ディ スパッチャ２５、サーチ・エンジンＩＮＦＯＲＭＩＸ２６、および汎用ＨＴＭＬ ２７を含んでいる。本発明の目的上、本発明の広告機能を利用できるパブリッシ ャは３つのクラスに分類されている。「パブリッシャ」には、コンテントをネッ トワークに提供する人ならば、ほとんど誰でも含むことができる。例えば、ホー ムページ所有者であれば、誰でも汎用ＨＴＭＬ ２７として示されているカテゴ リに属するパブリッシャとなる。第２の種類のパブリッシャはサーチ・エンジン ・パブリッシャ２６であり、この中にはＮＹＮＥＸのような電話会社イエロペー ジ・プロバイダが含まれる。第３の種類のパブリッシャはホームページ・プロバ イダと呼ばれるものであり、この中にはＢｕｓｉｎｅｓｓ Ｗｅｅｋなどの従来 の雑誌や新聞が含まれる。 本発明では、これらの３種類のパブリッシャを区別している。パブリッシャが ホームページ・ディスパッチャ２５である場合は、パブリッシャは独自のコンテ ントを提供し、広告をどこに入れることができるか、どこに入れることができな いか、コンテントの焦点があるトピックのどこにあるかを示している特殊タグを コンテントの間に挿入する。これらの特殊タグは本発明のシステムであるアクシ ョンをトリガするために使用される。 本発明で使用される第２の種類のパブリッシャはサーチ・エンジン・パブリッ シャ２６である。現在、ユーザがデータベースをクエリーし、応答のセットをデ ータベースからユーザに戻せるようにする多数の会社がＷＷＷに存在している。 例えば、電話会社は、ユーザがある特定タイプのビジネスについて電話番号と企 業名のセットを入手できるようにするサイトをもっている場合がある（つまり、 イエロページ・ディレクトリ）。 本発明の目的上、サーチ・エンジン・パブリッシャ２６はホームページ・ディ スパッチャ２６と区別されているが、これは、サーチ・エンジン・パブリッシャ ２６から戻されるコンテントが、コンテントと広告のレイアウトを定義するため にパブリッシャによって挿入された特殊タグまたはメタ・コメントを含んでいな いためである。この場合には、本発明のレイアウト・マネージャ１０は上述した ように、ルールとレイアウト・テンプレートに基づいて最適レイアウトを計算す る。従って、最終結果は出力がサーチ・エンジン・パブリッシャ２６から取り出 され、ある種の関連広告で装飾されてから、ユーザに表示されることである。 第３のタイプのパブリッシャである汎用ＨＴＭＬパブリッシャ２７には、おそ らく望ましい外観を提供するように配慮して独自のホームページを設計した人で あると、本発明が想定しているパブリッシャが含まれる。これらのパブリッシャ は本発明の広告システムのガイドとなる特殊タグまたはメタ・コメントをホーム ページに挿入していないはずである。この場合には、本発明のシステムはページ の望ましい外観を侵すことなく、妥当とシステムが考えるスペースをホームペー ジから見つけることも、あるいはページの前後に広告を挿入することもできる。 つまり、セグメンタ１２は、汎用ＨＴＭＬパブリッシャ２７がすでに設計してい るページ内に適当な場所を見つけることができないと、直前または後続ページに 広告を挿入する。このようなことは、ページの所有者が特殊タグまたはメタ・コ メントを与えていないか、あるいは著作権上の配慮からある広告をページ内に挿 入することを禁止している場合に起こる可能性が多くなる。 以上を要約すると、本発明によれば、パブリッシャ（つまり、情報ブローカ） は３つのカテゴリに分けられている。つまり、ホームページ・ディスパッチャ２ ５、サーチ・エンジン・パブリッシャ２６、および汎用ＨＴＭＬホームページ・ プロバイダ２７である。これらの３つは次の点で区別されている。つまり、ホー ムページ・ディスパッチャ２５は広告をどこに挿入し、どの種類の広告を挿入す るかを本発明が判断するときに役立つ特殊タグまたはメタ・コメントをコンテン トに挿入する。サーチ・エンジン・タイプのパブリッシャ２６はクエリーの未装 飾結果を戻し、応答のセットをリフォーマットし、リレーアウトするのは本発明 の自由に任されている。汎用ＨＴＭＬホームページ・パブリッシャ２７は、通常 は特殊タグまたはメタ・コメントを付けなで独自のホームページを細心に作 成しているため、広告を挿入するための該当場所を判断するためのガイダンスが 用意されていないパブリッシャである。 セグメンタ１２は汎用ＨＴＭＬページ上のどこに広告を挿入するかを判断する ことを担当する本発明のモジュールであるが、汎用ＨＴＭＬホームページ上のス ペースを見つけることに失敗する場合がある。その場合には、広告を直前または 後続ページに挿入することになる。ＷＷＷ上のパブリッシャはすべてではなりと しても、その大部分はこれらの３カテゴリの１つまたは２つ以上に属している。 図１において、ＬＡの頭文字は広告リストを示し、Ｑはユーザのクエリーを示 し、ＣＧＩは共通ゲートウェイ・インタフェース」を表す標準ＷＷＷ略語であり 、ＨＴＭＬはハイパテキスト・マークアップ言語を表す標準略語であり、Ｌｙは レイアウト・マネージャ１０からタイポグラフィ・マネージャ１４に渡されるリ ストであり、表示する必要のあるページのリストを示している。 次に、図２を参照して説明すると、図２は、イエロページ・パブリッシャによ って提供されるコンテント・ページ上に広告を、本発明に従って挿入するプロセ スのメインフローを説明しているフローチャートである。このプロセスはクライ アントがクエリーをシステムに行ったときＳＴＡＲＴ３０から開始する。説明の 便宜上、示されているクエリーはイエロページ・クエリーであり、そこではユー ザは関心のあるアイテムを要求しており、パブリッシャはイエロページ・パブリ ッシャである（３種類のパブリッシャの説明は前述したとおりである）。 例えば、ユーザはＭｏｒｒｉｓｔｏｗｎ，Ｎｅｗ Ｊｅｒｓｅｙのすべてのカ ー・ディーラのリストを要求するクエリー・フォームを送付する場合がある。こ のクエリー・フォームはＹＰ ＱＵＥＲＹ ＦＯＲＭと名づけたボックス３１で 評価される。この評価の目的はクエリーのタイプを判断することである（つまり 、ユーザはカー、特定の地域などに関心を持っているか）。 イエロページ・パブリッシャを使用するとき、クエリーの宛先には大きく分け て２つある。クライアントはあるカテゴリのリストを要求する場合もあれば、ク ライアントは特定のベンダを要求する場合もある。例えば、ユーザはＭｏｒｒｉ ｓｔｏｗｎ、ＮＪのカー・ディーラ（つまり、あるカテゴリのリスト）を要求で きる場合もあれば、ユーザはＭｏｒｒｉｓｔｏｗｎ、ＮＪの Ｓｏｕｔｈ Ｓｔｒｅｅｔに所在するＭｏｒｒｉｓｔｏｗｎ ＢＭＷ（つまり、 特定のベンダ）を要求できる場合もある。システムは図２のボックス３２に示す ように、ユーザが２タイプのクエリーまたはサーチのどちらを要求したかを判断 する。クエリーがあるカテゴリに対するものであれば、プロセスは図２のフロー チャートの左側に進み、クエリーがあるベンダに対するものであれば、プロセス は図２のフローチャートの右側に進む。まず、フローチャートの左側について説 明する。 クエリーのタイプを判断した後、カテゴリ・サーチ・エンジン３３は次に、ど のカテゴリがユーザのリクエストに最も最良に合致しているかを判断する。ユー ザは「カー」を要求している場合でも、イエロページ・プロバイダのインデック ス内のカテゴリは実際には「オートモビル」となっている場合がある。また、ユ ーザは「スペクタクル」を要求した場合でも、イエロページ・プロバイダのカテ ゴリは「オプティシャン」と名づけられている場合がある。これらの用語の違い のマッチングはカテゴリ・サーチ・エンジン３３によって行われる。 ユーザのリクエストがどのカテゴリに属するかが判断されると、広告選択プロ セスは広告セレクタ３４で活動化する。広告セレクタ３４はユーザが要求したも のと一緒にどの広告がミックスするのに最も適しているかを判断する。カテゴリ ・サーチ・エンジン３３からのコンテントと広告セレクタ３４からの広告はミキ サ３５に渡される。ミキサ３５はサーチ・エンジンからのコンテントを、広告セ レクタ３４によって選択された広告とミックスするように働く。その結果は、ユ ーザに関心のあるページの作成である。 ユーザのカテゴリがカーに関するものであれば、この時点で広告セレクタ３４ はカーに関する広告を見つけていれば、これらの広告をステップ３６でユーザに 表示することになる。ユーザはこの時点で、リストされたまたは広告されたカー ・ディーラの１つまたは２つ以上を選択することができる。この結果、再び、追 加の広告が広告セレクタによって選択されると共に、イエロページ・パブリッシ ャが用意したベンダ・サーチ・エンジン３７のアクセスが行われ、新しいページ がユーザに表示されることになる。 図２の右側を参照して説明すると、ユーザが特定のベンダを要求していれば、 システムはまずサーチ時間推測３８を行って、ユーザが要求した情報部分を見つ けるのにどれだけ時間がかかるかを計算する。これと同時に、広告セレクタ３４ はユーザに表示すべき広告のサーチを行う。関係する広告が広告セレクタ３４に よって見つけられると、その広告はサーチ時間推測情報とミックスされ、両方が ユーザに表示される。プロセスのこの時点４０で、ユーザは推測サーチ時間が与 えられた要求サーチを続けるかどうかの確認を求められる。ユーザからの確認を 受信すると、ベンダ・サーチ・エンジン４１がアクセスされるのと同じように、 広告セレクタ３４が再びアクセスされる。広告セレクタから戻される最初の広告 セットは、ベンダ・サーチ・エンジン４１からのサーチ結果が得られるまで、ユ ーザへの表示が続けられる。 ベンダ・サーチ・エンジン４１はサーチを完了すると、サーチ結果をミキサ３ ５に戻す。同様に、広告セレクタ３４は第２の広告セットをミキサ３５に戻す。 ミキサ３５はこの広告を、ベンダ・サーチ・エンジン４１から戻されたコンテン トとミックスして、その結合ページをページ・ディスプレイ４２に転送する。 このプロセスの結果として、ユーザが提出したイエロページ照会はカテゴリ・ サーチまたはベンダ・サーチのどちらかに分類される。どちらの場合も、クエリ ーのタイプは広告のあるカテゴリとマッチングされ、サーチ結果と広告がミック スされ、ページが構築され、ユーザに表示される。ユーザから別の入力を受け取 ると、システムは第２の広告セットを選択し、それをパブリッシャのコンテント ・ページとミックスし、広告を収めている別のページが構築され、ユーザに表示 される。 図２に示す「フォーカス」矢印４３は、あるフォーカスが各カテゴリに関連づ けられていることを示している。クエリーはあるカテゴリのリストに送られる場 合もあれば、特定のベンダに送られる場合もある。どちらの場合も、「フォーカ ス」がクエリーのコンテントと関連づけられている（例えば、オートモビル、外 科医、法律家など）。さらに、フォーカスはユーザの地理的場所と関連づけられ ていて、広告者が特定の地理的場所のユーザをターゲットにすることを可能にし ている場合もある。このフォーカス・プロセスは本発明では主要な役割を果たし ている。広告がユーザが要求したもののコンテントにフォーカスまたは関係して いると判断できる場合を除き、どの広告も表示されない。 次に、図３Ａ乃至図３Ｄを参照して、図２のプロセスの期間にユーザに表示さ れるページ・ビューについて説明する。図３Ａ乃至図３Ｄは４つのフォーム・ビ ューを示し、これらはＦｏｒｍ＃ＹＰ＿１、Ｆｏｒｍ＃ＹＰ＿２、Ｆｏｒｍ＃Ｙ Ｐ＿３およびＦｏｒｍ＃ＹＰ＿４の連続番号を付けて示されている。これらのフ ォーム・ビューは図２のフローチャートで参照されている同一フォーム番号に対 応している。 ユーザにはまず、Ｆｏｒｍ＃ＹＰ＿１に似たユーザのスクリーンが表示され、 クエリーをタイプするようにユーザに指示する。例えば、ユーザはＭｏｒｒｉｓ ｔｏｗｎ、ＮＪのカー・ディーラのクエリーをタイプすることができる。このク エリーの結果として、前述したように、カテゴリまたはベンダのどちらかのタイ プのサーチが行われる。実際には、ユーザはＦｏｒｍ＃ＹＰ＿１から該当のボッ クスを選択することで一方または他方のサーチを選択することができる。この時 点では、サーチ・タイプがカテゴリであるか、ベンダであるかがシステムに知ら され、ユーザはカー・ディーラをタイプしていたので、システムにはフォーカス が知らされる。 この時点で、サーチ・タイプがベンダであれば、システムはＦｏｒｍ＃ＹＰ＿ ２に似たスクリーンを表示する。このスクリーンからユーザは、システムがユー ザに応答するまでに約３０秒かかることを知り、これでＯＫかどうかが尋ねられ る。ユーザが先に進みたければ、ユーザは”Ｓｅａｒｃｈ ｉｔ ｎｏｗ”と名 づけられたボックスをクリックすると、システムはサーチを開始する。 サーチ・タイプがカテゴリであれば、システムはＦｏｒｍ＃ＹＰ＿３に二下ス クリーンを表示する。このＦｏｒｍ＃ＹＰ＿３はカー・ディーラの見出しの個所 にカテゴリ・リストを表示する。次に、ユーザはこれらのカテゴリの１つを選択 するように要求される。同時に、システムは広告選択モードに入り、ユーザに表 示されているＦｏｒｍ＃ＹＰ＿３上に広告を挿入する。この場合、Ｆｏｒｍ＃Ｙ Ｐ＿３に示されている広告はＢｅｌｌｃｏｒｅのロゴになってい る。 次に、ユーザは表示されているサブカテゴリの１つを選択し、ボックス“Ｓｅ ａｒｃｈ ｉｔ ｎｏｗ”をクリックする。 次に、システムはＦｏｒｍ＃ＹＰ＿４に似たスクリーンを表示する。このＦｏ ｒｍ＃ＹＰ＿４に置かれている広告は広告セレクタ３４によって選択されたもの であり、このフォーム上のリストはベンダＤＢエントリ・サーチ・エンジン４１ によってサーチされ、リトリーブされたものである。 以上を要約すると、システムにおけるイエロページ・サーチ・リクエストの一 般的プロセスでは、まずユーザがクエリーを記述し、このクエリーの結果はユー ザが見ることを望んでいる可能な限りのカテゴリのセットである。次に、システ ムはこのカテゴリのリストから１つのカテゴリの選択を行い、そのカテゴリに属 する関係プロバイダをユーザに表示する。ユーザがクエリーを記述し、システム がカテゴリのリストをユーザに表示するとき、ある広告もユーザに表示される。 これは図２のフローチャートの上半分であり、そこではカテゴリ・サーチ・エン ジン３３またはサーチ・タイム・エスチメータ３８および広告セレクタ３４は２ つのコンポーネントをミキサ３５に渡し、ミキサ３５は広告とカテゴリ・リスト の両方または要する時間のサーチ・タイム推測を収めているページを補充する。 もしユーザがカテゴリーをリクエストしたなら、ユーザは広告とユーザのクエ リーに関連しているカテゴリーのリストを示されることになる。もしユーザが特 定のベンダーをリクエストしたなら、ユーザは、ユーザのクエリーのフォーカス に関連づけられた広告と、そのシステムに対してどれぐらい長くクエリーを処理 するかの積算とを示されることになる。両方のケースで、ユーザは広告とインフ ォメーションのいずれかの部分を示され、そして次にさらなる選択をするように 尋ねられる。ユーザがさらなる選択をすると、システムは再びユーザが何を求め たか、そしてこのプロセスの一部としてどの広告を示すべきかを見いだそうとす る。このように、ユーザが何かをするシステムを求める時はいつでも、システム はユーザが求めることをするし、同時に、ユーザが求めたものとミックスするこ とができる広告を見いだす。 図２のフローチャートはイエローページ発行人と関連してのみ本発明を示すが 、類似のプロセスが他のタイプの発行人と一緒に使われる。ホームページプロバ イダに広告を出す本発明のプロセスは、図７のフローチャートと関連して以下に 説明される。 図４を参照すると、本発明のレイアウト・マネージャ１０が詳細に説明されて いる。ステップ５０において、レイアウト・マネージャ１０は表示されるデータ の集りを与えられる。レイアウト・マネージャ１０はそれぞれのページに対して 最も良いレイアウトを返すことができるように評価する規則の集まりを持ってい る。レイアウト・マネージャ１０は、各規則に対してデータのパラメータをリー ドする（読む）データを受け取り（ステップ５１）、メタ・テンプレート５３を 拡張する。 上述したように、レイアウト・マネージャ１０の２つの主コンポーネントは、 レイアウト・データベースとレイアウト規則（ルール）ベースである。レイアウ ト規則は、与えられた状況のセットの下で使うべき最も良いレイアウトを決定す るために使われる所定のパラメータを説明する。レイアウト・データベースは、 ある種類のデータで完成される（filled out）必要があるフォームであると考え ることができるテンプレートの集まりである。 レイアウト・マネージャー１０は、１つのデータが与えられた時、どのテン プレートを使うべきか決定するために規則を使う。特に、レイアウト・マネージ ャー１０は、いずれの規則が所定の１つのデータに対して最も良いか理解するた めにその規則ベースでそれぞれの規則を評価する。規則はメタおよびターゲット 機能コストを計算することによってステップ５４において評価される。メタテン プレートは、レイアウトが何についてのものであるかを説明するテンプレートで ある。例えば、テンプレートは、特定のレイアウトにおける広告に対してただ５ つだけの場所があることを提供することができる。 コストはそれぞれのレイアウトの種類と関係付けしてある。レイアウトマネー ジャが直面する基本的な問題は、ある数の広告を表示するが、表示する必要のあ るユーザ要求データが存在することである。このため、評価する必要のある、客 観的な内容対主観的な内容のスペクトルが作成される。すなわち、主観的な内容 をどれぐらい供給するべきか、客観的な内容をどれぐらい供給するべきかを、決 定しなくてはならない。発行人がイエローページの発行人である場合には、レイ アウト・マネージャ１０は何人の電話リストを表示すべきか、広告でどれだけの ページを充填すべきか決定しなくてはならない。本システムは、例えば、電話リ ストを３つだけ示し、ページの残りを広告で充填することができ、あるいは、本 システムは２０個の電話リストを表示することができ、ただ１つの広告のみを表 示することができる。レイアウトデータベースの各テンプレートは、各テンプレ ートと関係付けをしたメタ属性のセットであって、表示することができる広告の 数と、表示されるコンテントの量と、当該テンプレートと関係付けをしたコスト ファンクションとを示すメタ属性のセットを有する。 要するに、レイアウトマネージャ１０はデータベースからルールをピックアッ プし、各テンプレートに対するコストファンクションを計算し、最小コストのテ ンプレートを安全な場所にストアする（ステップ５５）。このコンピュテーショ ンが終わると、レイアウトマネージャ１０は、自分自身がカレントのデータアカ ウントのために用いることができるデータベース内に、最小コストのレイアウト を見い出すことに成功する。そして、レイアウトマネージャ１０は最小コストの レイアウトを最良レイアウトとしてピックアップし、この最良レイアウトを、ユ ーザに表示するため、トポグラフィマネージャ１４に返す（ステップ ５２）。 図５を説明する。本発明のパーサ６０のフローチャートを説明する。パーサ６ ０の目的は、発行人のページに挿入された、メタコメントとメタタグを解釈する ことである。上述したように、これら発行人のページは、一般的に、雑誌または 新聞の発行人によって構成されたページであって、本システムが、特殊な方法で 解釈するため、特殊タグをページコンテンツに供給したページである。これらの ページは、図５では、拡張HTMLまたはE_HTML６１として示す。 パーサ６０は、まず、入力E_HTMLから特殊タグを探索する（ステップ６２）。 特殊タグには、２種類のタグ、すなわち、フォーカスのためのタグと、広告スペ ースのためのタグがある。フォーカスのためのタグは、本システムに、ページの フォーカスが何であるか、あるいは、ページのコンテキストまたはコンテントが 何についてであるか知らせるタグである。例えば、フォーカスタグは、そのペー ジがスポーツカーについてか、料理についてか、カリブ海の旅行先についてかを 示すことができる。他方、広告スペースタグは、多くのピクセルのマトリクスで あるページ上のスペースを示すものであって、広告のために用いることができる 。パーサ６０はこれらの特殊タグを探索し、タグ名を、フォーカスタグまたは広 告タグのいずれかとして識別する（ステップ６３）。パーサ６０が特殊タグを見 い出すことができなかった場合は、パーサ６０は自分自身がコールされたところ に戻る。 パーサ６０はもしタグのフォーカス（focus）の種類を見つけると、フォーカ ス・ワードを取り出してストアする（ステップ６４）。パーサ６０はもしタグの 広告の種類を見つけると、サイズ値を取り出してストアする（ステップ６５）。 どちらの場合にも、プロセスはフォーカスおよび広告情報をページの終わり（Ｅ ＯＰ）６６に到達した後でシステムの別のモジュールに返す（ステップ６７）。 図６を参照して、ミキサとセレクタの処理の流れを説明する。ミキサ３５（前 述した通り図２を参照）の目的は、発行物の内容と広告を受け取って両者を一緒 に結びつけ、内容と広告が同一ページでミックスされるようにすることである。 図６において、ミキサ３５が発行元から２つの入力、データ５０（内容である ）およびE-HTML６１（特別なタグを含んでいる）を受けるところが示されている 。レイアウト・マネージャ１０とパーサ６０はともにミキサ３５の一部を形成す る。前述した通りデータ５０はレイアウト・マネージャ１０に入力され、E-HTML ６１はE-HTMLパーサ６０に入力される。次にこれらサブ・モジュールはともに、 広告を発行元ページの何処に配置できるかを決定する。 広告リストは次に、アド・セレクタ３４から入力される。アド・セレクタ３４ はフォーカス入力４３を受け取り、関連広告を取り出し（ステップ７０）、主・ スペース・マネージャ２０を用いて広告リストを作成する（ステップ７１）。こ れらの広告は次に、上述した通りパーサ６０とレイアウト・マネージャ１０に配 置される（ステップ７２）。ミキサ３５は次に、全てのエッセンシャル・ビリン グと他のユーザ情報をアドバタイザの広告のシステム配置のトラックを保つため にログする（ステップ７３）。この点で、リフレッシュ・タグが挿入され（ステ ップ７４）、システムはHTMLページを出力する（ステップ７５）。 ミキサ３５からのHTMLページ出力は特別なタグを持たず、HTMLを理解できるど のクライアントによっても表示することができない。E-HTML６１は本発明に特有 である。HTML７５はコンピュータ・ネットワークで用いられる標準のHTMLである 。E-HTML６１は上述した通り広告とフォーカスのための特別なタグを持っている という意味で本発明に特有である。 ステップ７４で挿入されたリフレッシュ・タグは表示される全てのページに挿 入される特別なタグである。このタグの目的は、ユーザがもし所定期間内に行動 しなかった場合にページをリフレッシュすることである。システムはリフレッシ ュして、ページの残りは同じままなのにアド・スペースに新しい広告を示す。こ のように、ユーザがページを見ている間に、システムは所定期間以上は同じ広告 を示さずに、ユーザの注意がおよぶ限られたスパンに対して有利としている。こ れによって、システムはできるだけ多くの広告を効果的に行なえるようになる。 例えば、ユーザがオンラインマガジンページを読んでいる間、その広告は、ユ ーザが同じページを見ているのと同じ頻度毎に変更してもよい。ユーザが当該 ページに変更を行い、そのページを前後する場合、その広告は、リフレッシュタ グ機能では変更されない。リフレッシュタグ機能用のタイマーは、広告主によっ て指定するか、システムによって決定するかの何れでもよい。 上述した通り、このシステムでサポートする基本契約は５つの種類がある。そ のひとつ、歩合ベースの契約の場合、広告は、最初の情報画面上か、一定の時間 割合での主要情報スペース画面上の何れかに表示される必要がある。この契約を 満足するため、システムは、主要スペース画面をリフレッシュできなければなら ない。そうでない場合、ユーザの画面上に一度広告を設定したら、ユーザが画面 を見ている時間全体で画面上にその広告が残ってしまう。リフレッシュタグ挿入 機能７４により、ユーザには新しい広告が示されると共に、長時間に渡って同じ 広告にさらされないで済む。 図７を参照して、ホームページプロバイダに使用されている本発明のフローチ ャートを説明する。図７のフローチャートは、幾分図２のそれに類似している。 しかしながら、図２のフローチャートがイエローページ告示者（パブリッシャ） に使用されるプロセスを示すものであるのに対して、図７のそれはホームページ プロバイダの告示者に使用されるプロセスを示している。上記したように、ホー ムページプロバイダとは、本システムに供給されるメタコンテント（Metaconten t）中に特定のタグ（tag）とフォーカス(forcus)、それに広告スペースタグ（sp ace tag）等を提供している告示者を示す。 開始する（ステップ８０）にあたって、ユーザは質問事項（query）を入力 する。例えば、ユーザはその質問事項としてレストランや自動車等を入力する。 該質問事項は上記したようにフォーカスを有している。システムはフォーカスが 何であるかを決定し、また上記したように、ユーザに対して質問に関連したカテ ゴリーのリストを提供する。例えば、ユーザがレストランを要求したとすると、 中国、アメリカ、フランス、イタリア料理店等、様々なレストランの種類のリス トを示される。ユーザにより入力された質問事項は、その質問事項のフォーカス を決定するために質問形式マネージャ（query form manager）により評価される (ステップ８１)。 図８Ａに表示された画面（"Form# １"）は、質問事項を入力するための図形 的なインタフェースである。このForm# １は（"search for"という言葉のすぐ隣 の）スペースを示しており、ユーザがそこに質問事項（この場合「自動車」）を入 力する。この質問事項の結果として、図８Ｂに示すように、妥当な自動車のサブ カテゴリーのリストが示される。 再び図７を参照するが、カテゴリーサーチエンジン（category search engi ne）３３は、質問事項（例えば自動車）に対するいくつかのサブカテゴリーを出 力し、図７の広告セレクタ（ad selector）３４が自動車に関連したいくつかの 広告を探し出す。ミキサ３５はこれら２つの画面ををミックスして図８Ｂの"For m# ２"（ステップ８２）に示される画面を形成する。 この時点（ステップ８２）で、ユーザはさらなる選択を求められる。即ち、 システムがより詳細な情報を供給できるよう、ユーザは"Form# ２"に「表示」 されている１またはそれ以上のカテゴリーを選択するよう求められる。例えばユ ーザが、「新車、中古車のディーラ小売り(retail)」にカーソルを合わせ、その ボタンをクリックすることによりそれを選択することができる。そのクリック操 作により、「コンテントプロバイダサーチエンジン」（content provider search engine）８３がアクセスされる。それと同時に、広告セレクタ３４は「新車、中 古車のディーラ小売り」のカテゴリーの適当な広告を探し出すよう指示される。 コンテントプロバイダサーチエンジン８３と広告セレクタ３４は、それぞれ の出力をミキサ３５に戻す。ミキサ３５はこれら出力を混合し、合致するコンテ ントプロバイダと、広告のリストを生成する(ステップ８４)。この時点で併合さ れた表示画像は図８Ｃの"Form# ３"として示される。"Form# ３"は画面中央に異 なる自動車ディーラ群のリストと、その画面の両側に沿って５つの広告を示して いる。 ユーザは、彼が訪問を希望する特定のディーラ、（例えばマツダ６２６ディ ーラまたはフォードムスタングのディーラ等の）の選択をさらに要求される。ユ ーザは選択を行い、その選択はコンテントプロバイダディスパッチャ（content provider dispatcher）８５と広告セレクタ３４に与えられる。このコンテント プロバイダディスパッチャ８５は要求さされたホームページを追跡する際、ADセ レクタ３４は、ユーザの要求に基づいた適当な広告を再度見つけ出す。 例えば、ユーザはマツダ６２６ディーラをクリックすることによりそれを選 択できる。マツダディーラ６２６用のページが追跡されてさいる最中に、広告セ レクタ３４は、このページに挿入し得る広告を見つけ出す。マツダ６２６のホー ムページ上には広告スペースがあるかも知れないし、無いかもしれない。 ホームページ上にシステムが広告を載せるためのスペースがない時は、シス テムはそのページの前あるいは後ろに広告を挿入するか、もしくは何も広告を載 せないと決定する。いずれにしても、要求されたどんなホームページでも、広告 セレクタ３４は妥当な広告を探索し、これら広告をミキサ３５に送る。そして、 その時点でミキサ３５はコンテントプロバイダのホームページを広告付き、また は広告無しで表示する。 端的に言えば、図８Ａ−８Ｃは、それぞれ図７に関連する３つの画像表示を 、 Form#1、Form#2、Form#3として表示している。Form#1はユーザが最初に見る画面 であり、ユーザはタイプ可能なスペース内に大まかな質問事項をタイプ入力する よう期待されている。この後、ユーザはカテゴリーのリストからの選択を為すよ う求められる第２の画面（Form#2）に到達する。この第２の画面のカテゴリーの リストから選択した後、さらにサブカテゴリーのリストからの選択を要求する第 ３の画面（Form#3）がユーザに示される。本発明は、これら３つの画面を、ユー ザの要求に関連した広告を表示するためにも使用する。Form#1は、サービスプロ バイダ（例えば、この場合はBellcore）のオーナ用の２つの広告を示している。 Form#2はユーザが自動車とタイプ入力したので自動車に関連した広告を示してい る。Form#3はユーザが小売り自動車ディーラを要求したので、特定の銘柄の自動 車に関連したさらなる自動車の広告を表示している。 本発明のビリングシステム（billing system）の説明が図９Ａと９Ｂを参照 して為されている。図９Ａ，９Ｂはシステムのインフォバンク（info bank）と 広告監査（ad auditing）と呼ばれる２つのサブモジュールを示している。これ ら２つのモジュールの目的は、本発明の様々な用途のログレポートを構築するこ とである。 図９Ａは、インフォバンクサブモジュール９０用のプロセスフローである。 インフォバンクサブモジュール９０の目的は、特定の顧客のセッションの間、あ る特定の種類の情報をログすることである。ログされた情報は、その後、広告者 に、何の広告が示され、ユーザが広告を見た後、何を買ったか、等々の説明を与 えるために使用される。従って、インフォバンクのサブモジュールは、広告者た ちに、誰がシステムにアクセスし、広告はどのような成果があったか等を示すた めに情報バンクに与える。 妥当なモジュールのための画面はユーザが選択できるインフォバンクと呼ば れるリンクを含んでいる。ユーザがインフォバンクリンクをクリックすると、ユ ーザは、インフォバンクサブモジュールの開始９１を示される。この時点で、ユ ーザは、ユーザ名、個人識別番号（ｐｉｎ）などのオーセンティケーションイン フォメーション（authentication information）を要求される(ステップ９２)。 システムはその後、オーセンティケーションモード９３に入り、入力されたユー ザＩＤとＰＩＮ番号が有効なものであるかを検査する。もしオーセンティケーシ ョンに問題がなければ、システムはその後トランザクション（transaction）ロ グとフィルタをサーチし(ステップ９４)、ユーザから要求された適当なログを引 っ張る。ユーザは、顧客により為されたすべての処理動作またはユーザが買った ある種の型のすべてのものを見ることを要求することができる。結果レポート（ ステップ９５）は顧客用に自動的に出力され、表示される。 広告監査９６のサブモジュールはインフォバンクサブモジュールのそれに類 似した目的を持っている。システムにこの広告監査で広告を載せた広告者はシス テム内のどこにでも入り込み、自分の広告を誰が見たのか、広告が表示されたと き、質問事項の内容は何であったか、広告は何回表示されたか、等を見つけ出す ことができる。オーセンティケーションと他のプロセスステップ群はインフォバ ンクサブモジュール９０の当該ステップ群に類似している。 さらに詳述すれば、広告監査サブモジュール９６を使用するために、広告者 は、広告監査用リンクで画面を示される。ユーザはこの広告監査リンク上でクリ ックし、広告監査モジュールの開始９７に導入される。広告者はその後、ユーザ 名とｐｉｎ番号から成るオーセンティケーション情報をタイプ入力することを要 求される(ステップ９８)。もしｐｉｎ番号とユーザ名がチェックされ、オーセン ティケーションステップ９９で証明された場合、ユーザはそこでシステムに対し てどの広告または広告のどのサブセットを調査または監査したのかを告げるよう 要求される(ステップ１００)。ユーザが、名前により、またはシステム内のすべ ての広告群を一覧することによって、あるいはユーザがそれについＴれのレポー トを知りたい広告をクリックすることにより、一度広告を特定したならば、シス テムは、誰がその広告を見たのか、どの型のマシーンを使用していたのか、何時 に、またどのくらいの期間広告が表示されていたのか、等のログであるレポート や、またその他の希望する情報を生成する(ステップ１０１)。 インフォバンクと広告監査サブモジュールによりアクセスされたログ情報は 、単一データベース２３にログインされる(図１)。ユーザが監査情報、トランザ クション、ユーザが購買した物を、あるいはユーザのデモ画像等を探しているか 否かに係わらず、情報はすべて同じデータベース内にある。しかしながら、ある ユーザがインフォバンクサブモジュール９０を使用するときは、そのユーザはあ る特定の物にしか興味を持っていない。しかし、ユーザが広告監査サブモジュー ル９６を使用するときは、そのユーザは他のことにも興味を持っているのである 。従って、インフォバンクと広告監査サブモジュールにより生成されるレポート 群は異なるデータを有しているのである。データベースはフィルタにかけられ、 ある特定のレポートへの興味のアイテムのみ保持され、それにより残りのデータ ベースのは使用される必要がない。 図１０を参照するに、本発明に従う広告配置プロセス１１０のフローを説明す る。広告配置の目的は広告主にこのシステム内に広告をエンターすることを認め ることにある。 広告をエントリさせるために、システムは、ユーザが広告のエンターを望んで いるのかどうかをユーザに対して尋ねる表示画面を提供する。その特定の選択上 にクリックすることによってイエスをユーザが指示したならば、システムは広告 は位置モードのスタート１１１に入る。この時点で、システムはユーザーにフォ ーカス（focus：焦点、広告対象）に付いて尋ねる（ステップ１１２）。広告主 は、例えば、自動車事業、洗車業を行っているとか、医者、弁護士であるとか、 あるいは広告主が与えたいと望む何か他の種類の名称の者であるということを述 べることができる。ユーザはステップ１１２で広告の名称を尋ねることができる 。これはまさにこれから参照するものについての名称である。 ステップ１１２でのフォーカスの目的は、近いクリエ（質問）に関連が無いと 見られるものから広告を防ぐことにある。本発明のシステムはユーザが求めるこ とに関連のある広告を常に示す。それゆえ、システムが広告の背景を知ることは 最も重要なことである。従って、広告主が広告を置くと、システムはフォーカス を確立する。 本発明は、ほぼ６４，０００種類で分類しているＳＩＣコードによってこの世 界を記述する。例えば、システムはオペラ・グラスとオペレーティング・テーブ ル間に区別があるということを知っている。システムは法律家と医者間の区別、 同様に医者の色々な種類間の区別を知っている。例えば、ユーザがフォーカスと して自転車にタイプ・インした場合は、本発明はカテゴリ・サーチ・エンジン３ ３をアクセスし、自転車ビジネス（例えば、自転車修理、自転車販売、スポーツ としての自転車乗り、等）に関するサブ・カテゴリのリストに戻る。ユーザは、 ユーザの広告に関連があるリスト（表）からサブ・カテゴリの１つまたは２以上 を選択するように促される（ステップ１１４）。ユーザは、この時点でユーザあ るいはユーザ自身のカテゴリを作り出すこともできる。この結果、広告はユーザ によって選択され、あるいは創造されたカテゴリの全てに繋がれる。 ユーザは一定の人口統計学（demographic）情報あるいはグラフ・図面の情報 （プロファイル・インフォメーション）の提供を求めることもできる。例えば、 ユーザは、３０歳から４０歳のグループの人々にのみ、あるいはモリスタウン、 ニュージャジィ、あるいはその他のどこかの地理的位置に生活する人々にのみ彼 の広告を見せることを要求することができる。ユーザが指定について求める最後 のアイテムは、契約（contract）である。広告主に対して利用できる色々な契約 は上述した通りである。ユーザがこの情報の全てに対してエンタリングを終了し たならば、システムは広告情報データベースを更新する（ステップ１１５）。 システムは、その後、広告にアクセスするか（ステップ１１６）、あるいはシ ステムはそれを廃棄する。ユーザが望んだ契約がシステムによって満足させられ ることができないという理由で、システムは広告を破棄するであろう。システム は、ユーザの契約を満足させることができないとい点を決定したならば、システ ムは満足させるとの可能な次の最良の可能性のある契約をユーザに対して表示し 、ユーザはそれからその契約を選択するか、あるいはシステムによって考慮され る異なる契約を提案するかは自由である。広告の配置を確認したならば、広告は データベースの一部となる。 図１１を参照すると、本発明に基づくページ配置プロセス１２０のフローが説 明されている。ページ配置プロセスの目的は、図１０を参照して上で説明した広 告配置プロセスに類似する。ページ配置プロセス１２０は、サーチ・エンジンの 一部であるため、または誰か他の人がホーム・ページを所有しているため、ペー ジが本システムの外部に存在する場合とは異なる。ページ配置プロセスは、本シ ステムで利用するためにホーム・ページを生成することに興味のある出版者(pub lishers)に利用される。ページ配置プロセスにより、出版者はメタ・タグ（meta tags）およびメタ・コンタクト(meta contacts)を有するホーム・ページを提供 することができる。 ページ配置プロセスは、メニュー選択の１つが「ページを配置したいですか？ 」である開始スクリーン１２１を有する。ユーザがそのメニュー選択をクリック すると、ユーザに対しスクリーンが示され、ユーザはページ名、ページURL（す なわち、Universal Resource Locator）、およびフォーカス(focus)をタイプす ることを求められる。URLは、そのページが実際に存在するWWWに関す る物理アドレスである。上で説明したように、フォーカスは、そのページの内容 をキャプチャするものとユーザが信じるキーワードのリストである。 フォーカス、ページ名、およびページURLを入力すると、システムはカテゴリ ・サーチ・エンジン３３から、そのフォーカスに強く関連するサブカテゴリのリ ストをリトリーブし、ユーザにそれらのサブカテゴリを表示する（ステップ１２ ４）。ユーザはそれらのサブカテゴリの１または２以上を、そのページの内容に 適合するものとして選択する。その後、システムはそのページを本発明のページ ・データベースに格納し（ステップ１２５）、その新たなホーム・ページを適合 するカテゴリにリンクしたことの確認を返すことができる（ステップ１２６）。 図１２を参照すると、本発明の基礎をなすトランザクション・システム(trans action system)のアーキテクチャが説明されている。本発明の基本的特徴の１つ は、ユーザに表示される広告が、クライアントが広告主に対しより一層の行動を とるゲートウェイ(gateway)を提供することである。すなわち、広告は、ユーザ がその広告を見るためだけにそこにあるのではなく、インタラクティブ（intera ctive）なのである。 例えば、システムがユーザに車またはクッキーの絵を示し、ユーザが買いたい 、またはその広告された製品についてのより一層の情報を受け取りたい場合、ユ ーザはシステムとトランザクションをすることができる。トランザクションは非 常にシンプルにすることができ、例えば、ユーザが広告をクリックすると、その 特定の製品についてのすべての情報が表示されるようにすることができる。ある いは、トランザクションをより複雑なものにすることもでき、例えば、ユーザが システムに会話を実際に入力して製品を買うようにすることもできる。 図１２に示すフロー・チャートは、クライアントがある広告を見て、その広告 をクリックして実際に何かを買うことについての典型的なシナリオを説明する。 具体的には、この人が買おうとするものは何でも、多数のサーバを巻き込むこと になる。クライアントはホスト１上で動作し、クライアントが要求するトランザ クションは多数のサーバ、たぶん地理的に離れたサーバを巻き込むであろう。ホ スト４は、コンピュータ・ネットワーク上のどこかのバンク（銀行）で動作する バンク・サーバである。ホスト３はログをとり、トランザクションの焦点として 役立つトランザクション・サーバである。ホスト２は、ホスト１に収容されたク ライアントからのトランザクションの開始を受け取るサーバである。 クライアント１３０が広告を見てその広告をクリックするという典型的なトラ ンザクションを、図１２に示すトランザクション・システム・アーキテクチャ・ ダイアグラム、および図１３Ａおよび図１３Ｂに示すスクリーン表示を参照して 、ここで説明する。広告上でのクリックという行動は、ホスト２のゲート１３１ によりキャプチャされ、その後適切な情報がホスト２のトランザクション・クラ イアント１３２によりクライアントに表示される。例えば、トランザクション・ クライアント１３２は、クライアントに望ましいトランザクションの型を入力す るように促すことができる。ホスト２のトランザクション・クライアントは、ホ スト３のトランザクション・サーバ１３３のクライアントである。 図１３Ａと１３Ｂを参照すると、典型的なトランザクションで、ユーザは初め に特定の発行者によって提供される特徴リストからある項目、この場合は”イン ターネットＤＭＶ”の項目をクリックする。２番目のスクリーン表示（図１３Ｂ ）が次に現れ、そのページ中央に”Division of Motor Vehicles，Morristown， New Jersey，Automatic Renewal of Driving Licence.”とする広告が提供され る。ユーザは次に、この特定の広告をクリックすることができる。この点におい て、スクリーンはユーザが所望するトランザクションがどんなタイプかを要求す るために表示される。ホスト２でトランザクション・クライアントが生成する次 のスクリーンには、例えば、”免許を更新しますか?”、または”新規自動車登 録しますか?”と書いてある。もしユーザが、”運転免許を更新したいです.”と 答えると、このリクエストはホスト２でトランザクション・クライアント１３２ によって獲得され、ホスト３のトランザクション・サーバ１３３に与えられる。 ホスト３のトランザクション・サーバ１３３は次にこの運転免許の更新リクエス トを受けて、そのローカル・データベースから埋めるべき適当なフォームを取り 出して、このフォームをホスト２のトランザクション・クライアント１３２に渡 す。 ホスト２のトランザクション・クライアント１３２は次に、これらのフォーム を受け取ってホスト１のクライアント１３０からの助けによってクライアント情 報で埋める。このように、クライアントの名前、アドレス、自動車ＩＤ、および 、その他クライアントに重要な情報が自動的に埋められる。 クライアント１３０はトランザクションの第２パートを開始するＰＩＮ番号入 力を要求される。クライアント１３０がＰＩＮ番号を入力すると、トランザクシ ョンの第２パートが開始する。トランザクションの第２パートは、埋められて運 転免許の更新リクエストを構成するフォームがホスト１のクライアント１３０か らトランザクション・クライアント１３２へ送られること、および、ホスト２の トランザクション・クライアント１３２からホスト３のトランザクション・サー バ１３３へ送られることである。この点において、ホスト３では２つのことが起 こり得る。まず、この人間が免許を更新したというレコードを作成すること、お よびクライアントにコンファメーションを送り返すことによって運転免許の特 定更新リクエストが処理される。次に、トランザクション・サーバ１３３がこの 運転免許更新の支払いを受ける。換言すると、クライアントとＤＭＶ間で両替さ れるべき一時的な料金が発生する。 一時的に料金を両替するときには、トランザクション・サーバ１３３がホスト ４のバンク・サーバ１３５に対してトランザクション・クライアント１３４とし て振る舞うことになる。トランザクション・クライアント１３４はホスト４のバ ンク・サーバ１３５に対してメッセージを送り、クライアントのＰＩＮ番号とク ライアントの課金から一定料金を控除する許可を持っていることを知らせる。バ ンク・サーバ１３５はその情報を認め、自身のレコードにその情報を記録し、デ ビット（debit）への電子承認を送り返す。 トランザクション・クライアント１３４はこの点においてホスト３のトランザ クション・サーバ１３３に対し支払い受領を知らせる。ホスト３のトランザクシ ョン・サーバ１３３は金銭の受領、リクエストの受け取りを記録し、トランザク ション・クライアント１３２とゲート１３１を通じてコンファメーション・メッ セージをホスト１のクライアント１３０へ送り返す。コンファメーションには、 例えば、”あなたのリクエストを受け取りました。課金から１７ドルを控除しま した。あなたの免許はメールにあります。あなたの新しい運転免許番号はこれで す。どうもありがとうございました．”のように書いておく。 図１４を参照し、本発明のトランザクション・プロセスをフローチャートを引 用して説明する。ユーザがトランザクションを要求する適当な広告をクリックす ると処理（ステップ１４０）を開始する。そしてシステムはユーザをトランザク ション・サーバにリンクさせる（ステップ１４１，ステップ１４２）。トランザ クション・サーバは次に、必要とされるフォームをクライアントに返し（ステッ プ１４３）、クライアントはフォームをユーザのプロファイル情報で埋める。フ ォームはトランザクション・サーバに再びサブミットされる（ステップ１４４） 。トランザクション・サーバはバンク・サーバにアクセスして（ステップ１４５ ）、ユーザが必要な金額を持っているかと、その金額を引き出せるかを判断する 。 バンク・サーバによるオーセンティケーションでは、トランザクション・サー バはバンク・サーバから、ユーザが有効課金番号を付与したこと、およびバンク ・サーバが実際にユーザを認めてバンクからの適当な額の控除を認めたことのコ ンファメーションを受け取る（ステップ１４６）。トランザクション・サーバは 次に控除を行ない、控除額をバンク・サーバのログに入れる（ステップ１４７） 。これらのログは保持されて、ユーザはいつでもお金をいくら使ったか、または 誰がどんなものを移動させたかを探すことができる。トランザクション・サーバ はまた、トランザクション・サーバのトランザクション・タイム・ログと他の所 望トランザクションの命題（particulars）を保持する（ステップ１４８）。そ してログが完成すると、トランザクション・サーバは次にクライアントに表示さ れるトランザクションのコンファメーションを生成する（ステップ１４９）。 図１５を参照し、ここで主スペース・マネージャ（prime space manager）２ ０についてさらに詳細に説明する。上述した通り、本発明の重要な特徴は主スペ ース（ユーザに対してディスプレイされる最初の情報のスクリーン）において広 告がどのように、いつ見えるかについてコントラクト上の確かな保証を本発明が 広告に提供することである。これらコントラクト上の保証（contractual guaran tees）は周波数に基づく（frequency-based）コントラクト、比率すなわちパー センテージに基づく（percentage-based）コントラクト、排他的または競合的な コントラクト、ディペンド（depend）コントラクト、およびストーリ・コントラ クト（story contract）を含んでいる。これらのコントラクトは前述した通り個 別にあるいは様々に組み合わされて用いることができる。 主スペース・マネージャ２０は主スペース・アルゴリズム１５０を有し、これ は手元のクイアリー（query）に関連する関連の（relevant）広告リストの入力 と、全ての広告リストの入力を許容する。主スペース・マネージャ２０は次に全 ての広告コントラクトを見て、どの広告をユーザに示すべきかを決定する。主ス ペース・マネージャ２０は次にコントラクトを更新して（ステップ１５１）、ど の広告が選ばれたかを知らせる（この情報はどの広告が次に選ばれるべきかを考 慮する際に用いられる）。 主スペース・マネージャ２０は次に、主スペース広告のリストを提供して適当 なモジュールに示す。すなわち、主スペース・マネージャ２０は、そのコントラ クトに基づく出来る限り非常に長い広告のリストを受け容れ、その広告をフィル タして主スペースサイズに基づいて示し得る広告数をまさに含むより小さなリス トにする。 次の主スペース・アルゴリズムの例は本発明の主スペース・マネージャ２０の 機能と動作をさらに説明するために提供される。これらアルゴリズムの多くの変 形例が可能であり、単に説明のためだけに特定の例を提供するにすぎないことに 注意されたい。 注記 Ａ₁・・・・・・Ａ_nは本発明システムにおける広告を表すとする。 Ｐ₁・・・・・・Ｐ_nは対応する広告に関連するコントラクト値（Ｐ_iは広告Ａ₁に関連 するコントラクト値を、アトバタイザによって支払われる価格の機能として表す ）を表すとする。 Ｓは本システムにおける主スペースのサイズを表すとする。 プライム空間（ｐｒｉｍｅ ｓｐａｃｅ）： ユーザ端末におけるプライム空間とは、ユーザの質問（関連した広告を付加し て）に対する回答によって構成されたデータを示す第１のスクリーン（ｓｃｒｅ ｅｎ）を意味するものである。 これに関連して、広告者は、請求料金に対応した形で、ユーザに対して提供さ れた広告を含むデータの中で、公平な取り扱いを受けることになる。 ここで、公平な取り扱いとは、制御アクセス、すなわち、より多く支払った広 告者が、より少なく支払った広告者よりも、多くのアクセスができているかとい うことを示すアクセスのみならず、均等なアクセスのことをいう。 コントラクト（ｃｏｎｔｒａｃｔ）： コントラクトとは、関連ユーザの質問に応答した所定の広告文の表示の頻度（ ｆｒｅｑｕｅｎｃｙ）を示す仕様書のことである。 この例でのプライム空間のアルゴリズムの条件として、下記の４タイプの広告 用コントラクトを使用することができる。 １．頻度（ｆｒｅｑｕｅｎｃｙ）ベース：この内容は、関連ユーザの質問に応 答して掲示される所定の広告の表示回数を特定する。 ２．比率（ｒａｔｉｏ）ベース：この内容は、関連ユーザの質問に応答したプ ライム空間で示される所定の広告がどの程度の割合を占めるのかを特定する。 ３．従属（ｄｅｐｅｎｄｅｎｔ）：ある広告Ａｉは、他の広告ＡｊとＸ％関連 したコントラクトを有することができる。この場合、従属したコントラクトは、 広告Ａｉが広告Ａｊと少なくともＸ％一緒に表示される内容となる。 ４．独立（ｅｘｃｌｕｓｉｖｅ）：ある広告Ａｉは、他の広告Ａｊと独立した コントラクトを有することができる。この場合、独立したコントラクトは、広告 Ａｉが広告Ａｊに関連して表示されない内容となる。 頻度（ｆｒｅｑｕｅｎｃｙ）ベースとしたコントラクトに関するアルゴリズム： ＷＨＩＬＥ（スクリーン空間が一杯でない場合） ｂｅｇｉｎ １．ある広告Ａｉを選択する。Ａｉは、コントラクト値Ｐｉに基づく選択値。 ２．スクリーン空間内のＡｉを包括する。 ｅｎｄ。 比率（ｒａｔｉｏ）ベースとしたコントラクトに関するアルゴリズム： ＷＨＩＬＥ（プライム空間が一杯でない場合） ｂｅｇｉｎ １．ある広告Ａｉを選択する。Ａｉは、コントラクト値Ｐｉに基づく選択値。 ２．プライム空間内のＡｉを包括する。 ｅｎｄ。 従属のコントラクトに関するアルゴリズム： ＷＨＩＬＥ（プライム空間が一杯でない場合） ｂｅｇｉｎ １．ある広告Ａｉを選択する。Ａｉは、コントラクト値Ｐｉに基づく選択値。 ２．ＡにＡｉを割り当てる。 ３．ＷＨＩＬＥ（ある広告が選択され、かつ、プライム空間が一杯でない場合 ） − Ａの従属文の一つを選択する。Ａｊは、コントラクト値Ｐｊに基づく選 択値。 − ＡにＡｊを割り当てる。 − プライム空間内のＡを包括する。 ｅｎｄ。 排他契約に対するアルゴリズム ＷＨＩＬＥ（プライム・スペースが満たされていない） ｂｅｇｉｎ １．広告、例えばＡ_iを契約値Ｐ_iによりバイアスをかけて選択する ２．Ａ_iを対象とする排他契約を有するすべての広告Ａ_jを排除する ３．Ａ_iが有する排他契約の対象であるすべての広告Ａ_kを排除する ４．Ａ_iをプライム・スペースに含める ｅｎｄ プライム・スペース管理全体に対するアルゴリズム ＷＨＩＬＥ（プライム・スペースが満たされていない） ｂｅｇｉｎ １．契約値Ｐ_iによりバイアスをかけて広告、例えばＡ_iを選択する ２．ＡにＡ_iを割り当てる ３．ＷＨＩＬＥ（いくつかの広告が選択されているＡＮＤプライム・スペース が満たされていない） − Ａを対象とする排他契約を有するすべての広告Ａ_jを排除する − Ａが有する排他契約の対象であるすべての広告Ａ_kを排除する − Ａに従属するもの、例えばＡ_mを契約値Ｐ_mによりバイアスをかけて１つ つ選択する − ＡにＡ_mを割り当てる − Ａをプライム・スペースに含める ｅｎｄ 一貫性チェックに対するアルゴリズム 概念： Ｐ_AはノードＡのプライム・スペース契約値を示すものとする。 Ｄ（Ａ，Ｂ，Ｘ）は広告Ａから広告Ｂへの従属契約値を示すものとする（Ｂが 現れている場合のうちＸ％は、ＡもＢと一緒に現れているべきである）。 Ｅ（Ａ，Ｂ）は広告Ａから広告Ｂへの排他契約を示すものとする（排他契約に は値が結合されないことに注意されたい）。 プライム・スペース契約値Ｐ_A、従属契約の集合Ｄ（Ａ，ｌ，ｘ），．．．， Ｄ（Ａ，ｋ，ｙ）、および排他契約の集合Ｅ（Ａ，Ｂ），．．．，Ｅ（Ａ，Ｂ） を有する新たな広告Ａをシステムに導入する場合、すべての契約の一貫性をチェ ックするため、以下の基本的なチェックをする必要がある（具体的なアルゴリズ ムおよびそのアルゴリズムの実現には、より具体的なチェックが必要かもしれな い）： １．不等式（Ｉ）を満たせるか否かをチェックする ２．従属契約Ｄ（Ａ，ｉ，ｘ）のそれぞれについて、不等式（ＩＩ）を満たせ るか否かをチェックする ３．排他契約Ｅ（Ａ，ｉ）のそれぞれについて、不等式（ＩＩＩ）を満たせる か否かをチェックする 一貫性チェック・アルゴリズムは、新たな広告を対応する契約に適応させるこ とができるか否かを確認する。新たな広告を適応させることができる場合は、契 約を承認し、システムが新たな追加を反映するように更新する。そうでない場合 は、一貫性チェック・アルゴリズムは、新たな広告に適応させることができる最 高の契約を広告主に知らせる。 従属契約および排他契約をチェックするために、すべての広告を有向グラフ中 のノードとして表して、グラフを描く。従属契約「広告Ｃは、広告Ｄが現れてい る場合のうち５０％は、（一緒に）現れている」は、ノード「Ｃ」からノード「 Ｄ」へのエッジとして表される。０．５の重みをこのエッジに割り当てる。排他 契約Ｅ（Ｃ，Ｄ）のそれぞれについて、グラフ中にエッジが存在する。このよう に、グラフは形成され、ノードは広告を示し、エッジは従属および排他契約を 示す。 新たな従属契約Ｄ（Ａ，Ｂ，Ｘ）を導入する場合、一貫性のため以下のチェッ クを行う必要がある： 新たな排他契約Ｅ（Ａ，Ｂ）を導入する場合、（ｘのいかなる値に対しても） 以下の条件（ＩＩＩ）を維持すべきである： ここでＸ_(A,B)はＡからＢへの従属エッジ、すなわちＤ（Ａ，Ｂ，Ｘ_(A,B)）の重 みを示す 公平さ（Ｆａｉｒｎｅｓｓ） システムに対するアルゴリズムの公平保証により、当該広告に課される料金に 比例して広告を表示することを確実にする。頻度に基づく契約アルゴリズム、比 率に基づく契約アルゴリズム、および従属契約アルゴリズムの公平さは、契約値 の確率分配、および正確なランダム・バイアスで広告を選択するランダム数字ジ ェネレータに基づくものである。ランダム数字ジェネレータが特定の範囲で数字 を生成する確率は、その範囲の広がりに比例する。範囲が広くなるほど、その範 囲に対応する数字が選ばれる可能性は高くなる。各広告には、その広告に課され る料金に応じて値の範囲が割り当てられる。課される料金が高くなるほど、その 広告に割り当てられる範囲は広くなる。これにより、料金が高くなるほど、高い 頻度で広告が表示されることが確実になる。 排他契約は、広告の表示に関して課される制約である。排他契約を満たすこと における公平さとは、その契約を満たすことを意味する（排他契約を有する２つ の広告が一緒に表示されることはない）。広告Ａが選択されてプライム・スペー スに表示されるとすぐに、プライム・スペース管理アルゴリズム１５０により、 広告Ａと関連契約のあるすべての広告が排除される。 公平を確実にするために、契約は一貫したものでなければならない。広告主と 契約を交渉するとき、一定の一貫性チェックを行い、公平保証が実際に満たされ ることを確実にする。 ストーリー広告 ストーリー広告は、時間が進むにつれて動的に変化する広告の一種である。ス トーリー広告は、従来の静的な広告のシーケンスにより構成され、それらが一体 となってストーリーを伝える。ストーリー広告を、リフレッシュ・インサート・ タグ（ｒｅｆｒｅｓｈ−ｉｎｓｅｒｔ ｔａｇｓ）という概念を用いて表示する 。ページに結合されたリフレッシュ・タグは、ストーリー広告がリフレッシュさ れる（シーケンス中の次の広告が表示される）までの時間を示す。他のすべての 静的な広告は、リフレッシュ・タイマの影響を受けない。クライアントまたはア プリケーションにより、リフレッシュ・タグを設定することができる。このよう に、ストーリー広告は多くの広告の論理的なシーケンスであり、広告は一度に１ つずつ、それぞれのリフレッシュ・サイクルで表示される。 本発明が上で説明した、または添付図面に示した構成またはプロセス・ステッ プそのものに限定されないこと、および本発明の範囲から逸脱せずに種々の修正 および変更を行うことができることが理解されるであろう。本発明の範囲は付属 の請求の範囲によってのみ限定されることを意図するものである。

【手続補正書】特許法第１８４条の８第１項 【提出日】平成１２年２月４日（２０００．２．４） 【補正内容】 明細書 コンピュータ・ネットワークにおいて、 広告を設置する方法およびシステム開示における著作権保護資料の通知 本特許明細書の開示部分に著作権保護の対象となる資料を含む。著作権者は特 許商標庁のファイルや記録に現れる特許明細書、または特許の開示を何人がファ クシミリで複製することに対して異存はないが、それ以外に対してはいずれのも のについて、全ての著作権を保留する。背景技術 技術分野 本発明は、一般的に広告に関し、より詳しくは広域ネットワークあるいは都市 エリアネットワークのようなコンピュータ・ネットワークにおいて広告を設置(配 置)するための方法およびシステムに関する。 従来技術 多数の情報サービスがインターネットのような広域公共ネットワーク上で提供 されている。これらのサービスの基本モデルでは質問(query)が処理され、１組 の回答が返送される。たとえば、多数のイエローページ検索可能ディレクトリが 開発され、それらにおいてユーザは製品またはサービスのカテゴリーを質問する ことができ、システムがその質問を満足するベンダーセットを返送する。 これらのサービスに伴う１つの問題は、サービスを使用するエンドユーザの費 用に対してだれが補助金を与えるかを決定することである。このような補助金を 提供する１つの方法は広告の使用を通じて行うことである。インターネットのよ うな公共ネットワークでは広告のランダムな使用が見られ始めている。たとえば 、公共ネットワークにおいて用いられているいくつかの検索（サーチ）エンジン のスポンサーは１つのベンダーまたは会社である。スポンサーのベンダーまたは 会 社は、サーチエンジンの使用中、ユーザのコンピュータ・スクリーン上にしばし ば広告を表示する。他の検索エンジンでは固定された広告セットからランダムに 選択された広告を表示する。 １つの例として、多くのワールド・ワイド・ウェブ（“ＷＷＷ”）上のサービ スは広告のための特別な手段を現在使用している。すなわち、ユーザが検索のた めにある検索エンジンを使用するとき、ユーザは検索を行っている間に、広告を 見せられる。これらの広告はときどき、ユーザがコンピュータ・ネットワーク上 の“道”を旅しているときにユーザが見る標識（ｂａｎｎｅｒ）になぞらえて、 見出し（“ｂａｎｎｅｒ”）広告と呼ばれる。これらの広告は典型的にはユーザ が検索の間、遭遇する個々の検索ページと結びついている。 現在の技術の状態ではユーザが検索エンジンを使用するとき、ランダムに選択 された広告はあたかも検索ページの一部分のように見える。たとえば、ユーザは 検索要求を入力して料理についてのホームページを見ることがあり、そのページ の一部として、既存のシステムは車についての広告を表示することがある。これ は１つの問題である。もちろん、広告の内容もしくは広告のメッセージとユーザ が実際に検索しようとしていることとの間に何の関係もないからである。現在の 技術に伴う他の問題は、広告に関し、その広告がある回数だけ見せられること、 またはページ上の他のデータ部分との関連におけるページ上のある場所において 見せられることについて、何の保証もないということである。これらの理由のた めに、インターネットのようなコンピュータ・ネットワーク上で広告を設置する 既存のシステムでは、オンライン・メディアの対話／要求駆動の環境の利益を十 分に受けることができない。発明の概要 本発明の目的はコンピュータ・ネットワーク上に、詳しくは、広域ネットワー クまたは都市エリアネットワーク上に広告を設置し、上述の既存の広告システム の問題を解決する改良方法および改良システムを提供することにある。 本発明のさらなる目的は、パーソナルコンピュータを持つものがだれでもコン ピュータ・ネットワーク上で広告することができる有効的な広告媒体を提供する ことにある。 本発明のさらなる目的は、広告が、より多くの情報を持ち、広告される製品ま たは情報、さもなくば、広告主についての付加情報に対して直接リンクを提供す る広告方法およびシステムを提供することにある。 本発明のさらなる目的は、広告が例えば、ユーザによるシステムとの対話の過 去の履歴を含むユーザの質問およびユーザのプロファイルにより、より焦点が絞 られ、よりターゲットが絞られているコンピュータ・ネットワーク上の広告方法 およびシステムを提供することにある。 本発明のさらなる目的は、新しいオンライン・パブリッシャを少ない労力で作 成することができる広告方法およびシステムを提供することにある。 本発明のさらなる目的は、ある回数だけ、または特別な態様で、または、特別 な環境下で広告を表示することを広告主に保証することができる広告方法および システムを提供することにある。 本発明のさらなる目的、利益および新規な特徴については以下で説明する。そ れらについては、当業者であれば、その説明を読み、または本発明を実施するこ とにより理解できるであろう。本発明の目的と利益は、添付の請求の範囲により 実現し、達成することができる。 本発明はオンライン広告のための新しいプロセスとシステムを提供する。この 新しいプロセスを、本明細書を通じて、質問に基づく広告（“ＱＢＡ”）と呼ぶ ことにする。ＱＢＡプロセスでは、広告は最初、ユーザの質問により起動する。 ここでいうユーザの質問とは、コンピュータ・ネットワークからの１以上の情報 ページに関する情報の消費者からのリクエストのことである。質問の結果として ユーザは本発明の広告にさらされる。すなわち、質問が広告を起動する。 本発明によれば、広告の集合を含むサーバは、コンピュータ・ネットワークと 電子的な通信を行う。コンピュータ・ネットワークは、好適にはインターネット または都市エリアネットワークのような広域ネットワークである。本明細書で使 用されているように“コンピュータ・ネットワーク”というフレーズは、なんら かの公共あるいは私的なデータ通信ネットワークを意味する。 サーバ上の広告は、コンピュータ・ネットワークにおいて、情報を含むどの特 定のページとも結びつけられていない。むしろ広告はサーバ上に含まれ、後に広 告を行える、または行えないページとは区別される。ページ自体は広告を有しな い。このため、ページは広告を有しない新聞や雑誌に似ている。 ユーザがあるページまたはある情報トピックを要求すると、関連のあるページ がコンピュータ・ネットワークから取り出され、ユーザに対して表示される。本 発明は、ユーザのリクエストを受けると、ユーザのアクションに関係する広告を 取り出し、その広告を特定のレイアウトに従ってページのコンテントと動的にミ ックスし、焦点を絞られ、ターゲットを絞られた広告を一部とするページを表示 する。広告は、ページのパブリッシャの制約のみならず、広告主が要求した制約 をも満たして、行うことができる。 本発明の広告起動メカニズムはランダムや偶発的ではない。むしろ、前もって 規定されている。本明細書では、この規定を契約と呼ぶことにする。契約は、広 告を特定の質問とリンクさせるマーケティング・ルールを規定している。たとえ ば、ダイエット・ソフト・ドリンクの広告は、ユーザが体操用器具についてのペ ージを要求したときに表示させることができる。これらのルールは、広告の“フ ォーカス”または“関連性”の概念を提供する広告主により規定され、広告主が 特定の視聴者にターゲットを絞るのを助ける。ページのオーナーは、ページ内で 特殊なタグを通じてそのページのフォーカス内容を規定する。これらのタグは、 情報の消費者に対しては表示されない。タグは、消費者がページを要求したとき に、どの広告を表示できるかを決定するために使用される。 しかしながら、契約の概念は、マーケティング・ルールをはるかに超えている 。まず、オンライン媒体上の広告スペースは、技術的には制限がないけれども、 ユーザが注目する期間に強く制限される。質問に対する回答で構成された最初の ページに広告を配置する場合、後の回答のページに比べて、その広告が見られる 可能性が相当高い。このことは、新聞の広告において、新聞の最後のページで広 告を行うよりも、新聞の最初のページで広告を行う方が値段が高いことに、ある 意味で類似している。このため、本発明は、ＱＢＡの一部分としてプライム・ス ペースの概念を導入している。 プライム・スペースは、本明細書において、質問に対する回答の最初のページ 上の限られた広告スペースをいうものとして用いる。プライム・スペースは、お おむね、テレビのプライム・タイムのように魅了的である。プライム・スペース は、プライム・タイムのように制限を受け、そのため、プライム・スペース中に 全ての関連のある広告を示すことは不可能かもしれない。 プライム・スペースの制限に対する解決策として、本発明では契約の使用を通 じて広告主に対して保証を与える。契約は、そのような保証を規定し、実施する ツールを提供する。具体的には、本発明では以下のタイプの保証（すなわち、“ 契約”）を広告主に対して提供する： １．比率に基づく契約：広告は、サーチャにより関連する質問がされた場合の うち一定パセンテージ以上表示される。 ２．排他的または競合的契約：広告Ａは、広告Ｂがプライム・スペースに表示 されているときは決して表示されない。 ３．従属契約：広告Ａは、広告Ｂがプライム・スペースに表示されているとき 、予め定められた確率で表示される。 ４．ストーリー契約：いくつかのサブ広告で構成される広告を、プライム・ス ペースで順次消費者に表示する。 ５．頻度に基づく契約：広告は、プライム・スペースに、与えられた時間内に ある回数だけ表示される(例えば、１月に１００回)。 さらに、契約は、広告をデータと一緒にミックスするのに用いるレイアウトの タイプを規定できる。これには、レイアウト・タイプ等が含まれる。 本発明はまた、満足できない契約があるか否かの判定を行う手段を提供する。 たとえば、プライム・スペースが２つの広告だけを保持する広さであれば、２つ 以上の広告に対して１００％の比率を保証することは不可能である。同様に、広 告Ｂが表示されているときに広告Ａを決して表示せず、かつ、広告Ａおよび広告 Ｂがフォーカス・マッチングによると同等の関連性を有するのであれば、広告Ａ および広告Ｂに対して５０％を超える比率を保証することは不可能である。 本発明は契約の一貫性をチェックするアルゴリズムを使用して、受け付けた契 約の全てが適切に満たされることを保証する。広告主は契約（たとえば、プライ ム・スペースの５％の相対的なカバレッジ(coverage)）を求めることができ、本 発明はその契約を満たせるか否かを判断する。満たせないのであれば、システム はどのようなカバレッジを提供できるかを示す。契約に一貫性があると判断され た後、本発明は契約にしたがって広告を表示することにより契約を実施する。 ＱＢＡの結果として、ページ上に配置される広告を決定するのは質問であるの で、広告をページに前もって配置することはできない。これは動的な広告と呼ば れる。質問は、フォーカスを有するページを要求する。システム内にある広告は 、どの広告を問題となっているページ上に配置することができるかを決定するた めにチェックされる。この決定は、ページのフォーカスと広告のフォーカスとを マッチングすることに基づいて行われる。スペースの制限のためにページ上に全 てのマッチングする広告を配置することができない場合、本発明の契約実施の特 徴により、ページ上に配置される広告が、広告主のシステムとの契約と一貫する ことを保証する。 ＱＢＡの他の結果として、ページのどこに広告を配置するかを決定しなければ ならない。現在、ＷＷＷ上のページは、そのページ上に広告のための前もって同 意された固定のエリアを有する。しかしながら、本発明は、広告をどこに設置す べきかを動的に決定する。本発明は、ページのオーナーに対してページのレイア ウトを自由に構築することを許容している。ページのオーナーは、広告をどこに 設置すべきか、またはすべきでないかの最終決定を行う。ページが構築されると 、ページのオーナーは、ページ上に特殊なタグ（“広告スペース”）を配置する ことにより、どこに広告を配置できるかを規定できる。フォーカス・タグのよう に、この広告スペース・タグは消費者にとっては見ることができない。タグが広 告に利用可能なスペースを示すことは、広告システムに対して指導性がある。す なわち、タグは“このスペースは広告として利用可能”と述べる掲示板と考える ことができる。 本発明は、また、ダウンロード遅延時間広告特徴を提供する。インターネット のようなコンピュータ・ネットワーク上の多くの消費者は、彼らがページを求め た時点からそのページが彼らのブラウザにダウンロードされるまでの遅延を経験 する。この遅延は、たとえば、ＷＷＷ上のトラフィックの混雑により生じる。こ の遅延時間はダウンロード遅延時間と呼ばれる。 本発明は、ダウンロード遅延時間を使用して広告を消費者に対して表示する。 これをダウンロード遅延時間広告と呼ぶ。消費者がページのダウンロードを待つ 時間を、その消費者に広告を見せるのに利用する。一度、ページ（または、ペー ジのサブパート）が消費者のブラウザにダウンロードされ、表示可能になると、 広告はページ・コンテントに取って代わられる。消費者は、本発明による広告に より遅延を経験しない。前から存在する遅延時間のみが本広告システムにより利 用される。 要するに、本発明は、複数の広告を含むサーバと、そのサーバをコンピュータ ・ネットワークに電子的に接続する手段と、ネットワークに入力された質問に応 答して、サーバから広告を選択し、取り出す手段とを備えたコンピュータ・ネッ トワーク上で広告を行うシステムおよび方法を提供する。選択手段は、選択され た広告が質問に関連することを保証する手段を備える。取り出された広告を、質 問に応答してコンピュータ・ネットワークにより返送されたコンテント・ページ と結合するためにミキサ手段が提供される。 ミキサ手段は、取り出された広告およびコンテント・ページを含む結合された ページの最適なレイアウトを計算するレイアウト・マネージャ手段を備える。ま た、ミキサ手段は、コンテント・ページ内で特殊タグおよびＨＴＭＬルールを見 つけ、コンテント・ページのどの部分に選択された広告を表示できるかを決定す るタイポグラフィ・マネージャ手段も備える。コンテント・ページは、質問に応 答して、ホームページ・ディスパッチャ、サーチ・エンジン、またはジェネリッ クＨＴＭＬコンテント・プロバイダにより提供される。 ユーザが表示された広告とやりとりをすることにより広告主とトランザクショ ンを行えるようにするためにトランザクション手段が提供される。サーバに含ま れる広告が選択手段により選択された場合に制御を行うためにプライム・スペー ス・マネージャ手段が提供される。その制御は広告の各々に結び付けられた広告 主の契約の各々に基づいて行われる。 サーバに新しい広告を配置するために広告配置手段が提供される。広告配置手 段は、サーバに配置された各広告の広告主の契約を入力する手段と、新しい広告 主の契約について既存の広告主の契約との一貫性をチェックする手段とを有する 。 質問に応答して、ユーザがコンテント・ページがダウンロードされるのを待って いる間のみ、取り出された広告を表示するためにローカル・クライアント手段が 提供される。予め定められた期間ユーザの行動がなかった後に、表示された広告 をリフレッシュする手段と、クライアントがコンテント・ページを受け取るとす ぐに、表示された広告を該ダウンロードされたコンテント・ページに置き換える 手段とがさらに提供される。システムには、質問のサーチ時間見積りを計算する 手段と、サーチ時間見積りおよび取り出された広告を含むページを結合する手段 とが含まれる。また、システムには、ユーザの地理的位置を決定する手段と、ユ ーザの地理的位置に基づいて広告を選択する手段とが含まれる。図面の簡単な説明 本発明の開示は添付の図面を参照して行われているので、本発明をより明確に 理解できるようになるであろう。ここで、 図１は本発明の主要コンポーネントの一般的概観を示す概要図である。 図２はコンピュータ・ネットワークのイエロー・ページ・パブリシャにより提 供される、コンテント・ページ上に広告を配置する処理を示すフローチャートで ある。 図３Ａ−図３Ｄは図２のプロセス中の種々のステップの間に表示されるページ の表示内容を示す画面のプリントである。 図４は本発明のレイアウト・マネージャにより実行される処理を示すフローチ ャートである。 図５は本発明のパーサにより実行される処理を示すフローチャートである。 図６は本発明のミキサおよび広告セレクタにより実行される処理を示すフロー チャートである。 図７はコンピュータ・ネットワークのホームページのパブリシャにより与えら れるオンライン・ページ中にターゲットの広告を配置するための処理を示すフロ ーチャートである。 図８Ａ〜図８Ｃは図７に示す処理の種々のステップの間に表示されるページの 表示内容を示す画面のプリントである。 図９Ａおよび図９Ｂは本発明にしたがった請求システム処理を示すフローチャ ートである。 図１０は本発明にしたがった広告配置処理手順を示すフローチャートである。 図１１は本発明にしたがった広告配置処理手順を示すフローチャートである。 図１２は本発明にしたがったトランザクションのアーキテクチャを示す概要図 である。 図１３Ａおよび図１３Ｂは本発明のトランザクション処理中の種々のステップ の間に表示されるページの表示内容を示す画面のプリントである。 図１４は本発明にしたがったトランザクション処理の手順を示すフローチャー トである。 図１５は本発明のプライム・スペース・マネージャ・コンポーネントにより実 行される処理を示すダイアグラム・チャートである。好適実施例の詳細な説明 以下、本発明の好適実施例について詳しく説明する。その例は添付図面に示さ れている。 図１は、本発明のメイン・コンポーネントの全体的概要または空間的アーキテ クチャを示す図である。レイアウト・マネージャ１０は主にクライアントに表示 されるページのレイアウトの計算を担当する。システムの他のモジュールは、以 下で説明するように、表示すべき必要なデータを計算する。レイアウト・マネー ジャ１０は他のモジュールからのこのデータを受け取ると、ディスプレイ用の最 適レイアウトを計算する。 レイアウト・マネージャ１０は２つのサブコンポーネントを使用して最適レイ アウトを判断する。つまり、レイアウト・マネージャ内のルール・ベースとレイ アウト・データ・ベースである(図１には、レイアウト・ルール・コンポーネン ト１１と総称して示されている)。レイアウト・データ・ベースは事前に定義さ れ、レイアウト・データ・ベースにストアされたテンプレートのコレクションを 含む。ルール・ベースはどの条件セットのもとでどのレイアウト・テンプレート が最良であるかを確かめるためにユーザまたはレイアウト・マネージャのプレー サ（ｐ ｌａｃｅｒ）によって定義されたルールのコレクションを含む。レイアウト・マ ネージャ１０は表示すべきデータを受信すると、レイアウト・ルール内の種々ル ールを呼び出して、どのルールをトリガすべきかを計算し、従って、現在の条件 セットのもとで最良とされる１つのレイアウトを判断する。 ルールで使用される変数には、表示すべきデータの量、表示すべきデータの種 類、テキストの量、広告資料の量、および表示すべき種々マップとマルチメディ ア・アイコンのサイズがある。これらの変数に基づいて、ルールがチェックされ 、検出できる最良レイアウトを表すものとして１つまたは２つ以上のルールが選 び出される。この場合、レイアウト・マネージャ１０は最良と思うルールの１つ を任意に選び出し、そのレイアウトを選び出し、レイアウト・マネージャが受け 取ったデータをレイアウト・テンプレートに挿入し、表示すべき最終的製品をク ライアントに引き渡す。 ルールの中で表現されている変数はいくつかのパラメータに基づいている。そ のようなパラメータとしては、テキストのサイズ、テキストの量、マップのサイ ズ、イメージのサイズ、および広告のサイズなどがある。原則的には、レイアウ ト・マネージャ１０を使用して達成することができるパラメータの数には制限が ない。ルールは、好ましくは、プログラミング言語で表現され、与えたいと思っ ている他のどのパラメータでも受け入れるように一般化されている。 レイアウト・ルールは種々のパラメータに基づいて構築される。構築されたレ イアウト・ルールはチェックされ、ある種のデータ状況に合わせて使用される正 確なテンプレートを突き止めるために使用される。このテンプレートはレイアウ ト・マネージャ１０によって満たされ、クライアントへのディスプレイが得られ る。 次に、セグメンタ（ｓｅｇｍｅｎｔｅｒ）１２について説明する。このセグメ ンタ１２はＨＴＭＬページを分析し、ＨＴＭＬページから関係データを抽出する ことを担当する。セグメンタ１２の目的は、別のコンポーネントまたは他のコン テント・プロバイダによって構築されたページがシステムに渡されたとき、ある 広告を動的に挿入できる、そのページ内の妥当な場所を見つけることである。 セグメンタ１２は種々のルールを使用してページ内の広告スペースを探し出し 、 そのページの基本的レイアウトが混乱するのを防止する。具体的には、セグメン タ１２はＨＴＭＬページの設計者によって挿入されたある種の特殊タグを探し出 し、その特殊タグを、セグメンタが受け取った広告または他のタイプの情報に置 き換える。次に、セグメンタ１２はページを調べ、広告をどこに挿入すべきかを 判断し、その情報をレイアウト・マネージャ１０に渡す。 ほとんどの場合、タイポグラフィ・マネージャ（ｔｙｐｏｇｒａｐｈｙ ｍａ ｎａｇｅｒ）１４はレイアウト・マネージャ１０への主要入力デバイスである。 これの例外については、後述する。タイポグラフィ・マネージャ１４の役割はペ ージを「レンダリング(ｒｅｎｄｅｒ)」することである。ページをレンダリング するとは、タイポグラフィ・マネージャ１４があるページに送るべき種々の入力 を受け取り、情報のどの部分をそのページに送るべきか、情報のどの部分を実際 に削除できるかを判断することである。従って、タイポグラフィ・マネージャ１ ４は機能的には従来のパブリッシングの場合のタイポグラファと同じである。 タイポグラフィ・マネージャ１４は、どのデータをレイアウト・マネージャ１ ０に送るべきかの最終的発言権をもっている。タイプグラフィ・マネージャ１４ は、ＨＴＭＬページのマークアップがどこで起こっていると思われるかをタイポ グラフィ・マネージャ１４に指示する特殊タグと特殊ＨＴＭＬルールも検出する 。最終的には、レイアウト・マネージャ１０とタイポグラフィ・マネージャ１４ は共同してページの補充を行う。最終形式のこのページはゲート１５に渡される 。 ゲート１５はページを本発明のシステムからクライアントに転送する。従って 、ゲート１５はクライアントとサーバ間のゲートの働きをする。ゲート１５は表 示しようするページをＷＷＷデーモン(Daemon)１６に渡し、デーモンの方はユー ザのサイトにいるクライアント１７とやりとりする。 レイアウト・マネージャ１０、セグメンタ１２、タイポグラフィ・マネージャ １４、およびゲート１５がどのような働きをするかは以上に説明した通りである 。システムの残りのコンポーネントを詳しく説明する前に、システムを通るリク エスト（要求）の流れの例を説明することにする。 最初に、ユーザはクライアント１７の１つを通して特定の情報部分を要求する 。ユーザのリクエストはＷＷＷデーモン１６に渡され、このデーモンはその情報 を ゲート１５に渡す。ゲート１５はこの時点で、どの情報部分がユーザによって要 求されているかを判断し、ユーザが要求したものと混合できる他の関係情報部分 を探し出す。例えば、ユーザはあるカー・ディーラを調べ、カー・ディーラの電 話番号を探し出し、あるいは特定の雑誌のページを得ることをシステムに要求す る場合がある。 ゲート１５はこの時点で、リクエストをマッチング・ルール・エンジン（ＭＲ Ｅ：ｍａｔｃｈｉｎｇ ｒｕｌｅ ｅｎｇｉｎｅ）１８に渡す。ＭＲＥ１８の目 的はユーザの質問の内容を調べ、同ータイプに一致するカテゴリをそのアクティ ブ・インデックスＳＩＣ１９内から見つけることである。ユーザがカー・ディラ ーを要求していれば、ＭＲＥ１８はそのルールを呼び出し、カー・ディラーが乗 物に関係する事物のクラスの一部であると判断する。ＭＲＥ１８によって判断さ れた分類に基づき、システムはユーザがカーまたは乗物について、あるいはユー ザが関心を持っているであろう他のすべての事物について尋ねていることを知る ことになる。 ＭＲＥ１８はこの時点で、ユーザの質問のカテゴリ・インデックスをゲート１ ５に戻す。ユーザがカーまたはファミリ・セダンについて、あるいはスポーツカ ーについて尋ねていれば、この時点で、ＭＲＥ１８はユーザの関心があるカテゴ リに属することを判断している。ユーザの関心カテゴリに基づいて、システムは そのカテゴリに関係する広告を取り出す(retrieve)。従って、ＭＲＥ１８の目的 はユーザがなにを要求したかを判断し、ユーザのリクエストを分類システムのカ テゴリ（つまり、アクティブ・インデックスＳＩＣ１９）に入れ、その分類に基 づいて、関係する広告を取り出すことである。この時点では、ユーザのリクエス トを含むカテゴリから取り出された関係広告は数百になっている可能性がある。 これが問題となるのは、ユーザのリクエストに関係する広告が最初の情報ページ でユーザに表示できるよりも多くなっていることである。この時点で、プライム ・スペース・マネージャ（ｐｒｉｍｅ ｓｐａｃｅ ｍａｎａｇｅｒ）２０が活 動する。プライム・スペース・マネージャ２０の目的はユーザに表示すべき広告 に優先順位を付けることである。 例えば、５つの広告用のスペースしか残っていないで、ＭＲＥ１８が表示する 可能性のある５００個の広告のリストを戻したとすると、システムはどの５つの 広告を表示するかを判断しなければならない。プライム・スペース・マネージャ ２０のオペレーションは、広告主が広告をシステムに入れたときに受け付けた契 約(contracts)のセットに基づいている。システムは基本的契約として次の５つ のタイプをサポートしている。 １．比率に基づく契約：広告は関係質問がサーチャによって行われる時間の一 定パーセンテージ以上、プライム・スペースに表示される。 ２．従属型：広告Ａは広告Ｂがプライム・スペースに表示されるとき事前に決 めた確率で表示される。 ３．排他型または競合型：広告Ａは広告Ｂが表示されるときプライム・スペー スに表示されることがない。 ４．ストーリ型：いくつかのサブ広告からなる広告はコンシューマに対して特 定のシーケンスでプライム・スペースに表示される。 ５．頻度に基づく契約：広告はある期間内に一定回数だけプライム・スペース に表示される(例えば、毎月１００回)。 上記のほかに、契約は広告をデータと一緒にミックスするために使用されるレ イアウトのタイプを指定することもできる。この中には、レイアウトのタイプそ の他が含まれる。以下では、システムによって使用される種々の契約について詳 しく説明する。 比率に基づく契約は広告主が広告を時間の一定パーセンテージだけプライム・ スペースに表示することを望んでいる場合に使用される。言い換えれば、広告主 のビジネスに関係する質問が受信されたときは、広告主には、広告が時間の一定 パーセンテージだけユーザに表示される最初の情報スクリーンに表示されること が保証される(例えば、時間の１５％)。このパーセンテージはカバレッジ保証( ｃｏｖｅｒａｇｅ ｇｕａｒａｎｔｅｅ)と呼ばれる。比率に基づく契約は、広 告主の広告が関係する質問が行われるたびに時間のＸ％だけ表示されるというカ バレッジ保証を広告主に提供する。この保証は確率的性格を持っているので、シ ステムが長時間稼働している間に、この確率は広告主が要求したパーセンテージ に収束することになる。 システムがサポートする第２のタイプの契約は従属型契約と呼ばれる。従属型 契約は、ある広告主の広告が他の広告主の広告と一緒に同じスクリーンに表示さ れることを保証する。例えば、トラベル先広告（例えば、「バハマへ行こう」）は クレジットカード広告（例えば、「チケットの支払いはＶＩＳＡで」）と一緒に最 初の情報スクリーンに表示することができる。このタイプの契約によると、シス テムは２またはそれ以上の広告主の要求を同時に満たす契約をサポートすること ができる。 システムがサポートする第３のタイプの契約は排他型または競合型契約と呼ば れる。このタイプの契約を使用すると、広告主の広告が競争会社の広告と同時に または同じスクリーンに表示されないことが保証される。例えば、ある飲料メー カ（例えば、コカコーラ）は競争会社の飲料メーカ（例えば、ペプシ）の広告が 自社の広告と同時に表示されるのを防ぐことができる。逆の場合も同様である。 第４のタイプの契約はストーリ型契約と呼ばれる。このタイプの契約は２また はそれ以上の広告のシーケンスが一緒に表示される広告パッケージを保証するた めに使用される。広告は、あるユーザが広告の最初の部分を見た後、広告の第２ の部分を見、次に広告の第３の部分を見るといったように表示できる。例えば、 コーヒの広告では、最初のページの絵にはコーヒを飲んでいる人が表示され、第 ２のページの絵にはコーヒ・カップをかたづける人が表示され、第３のページに は広告主の製品の名前が表示されていることがある(例えば、「マクスウェル・ハ ウスは、よい一杯のコーヒーを作る」)。 以上のように、ストーリ型契約は、広告主の広告がストーリの形で表示される ことを保証する。ストーリ型契約が望ましいとされるのは、広告群が特定の順序 で一緒に表示されることにより意味を持つ場合である。 第５のタイプの契約は頻度に基づく契約である。この契約が使用されるのは、 広告がある期間に一定の回数だけ表示されることを保証することを広告主が望ん でいる場合である(例えば、毎週１００回)。 上述したタイプの契約を数通りに組み合わせて使用することも可能である。例 えば、広告主は自社の広告が競争会社の広告が表示されるのと同時に表示されな いこと、広告が関連広告が表示されるのと同時に表示されること、および広告が 時間の一定パーセンテージだけプライム・スペースに表示されることを保証する ストーリ型契約を結ぶことができる。 プライム・スペース・マネージャ２０はユーザが要求した情報と一緒に表示で きる可能な限りの広告を判断することを担当する。次に、プライム・スペース・ マネージャ２０はどの広告を表示すべきかを、署名された特定の契約に基づいて 判断する。ある契約がその広告主の競争会社とすでに結ばれていれば、プライム ・スペース・マネージャ２０はその契約が広告主との新しい契約を実際に満たす ことができるかどうかを確かめることになる。従って、プライム・スペース・マ ネージャ２０は表示が可能とされる広告の量と数が与えられているとき、どの広 告を表示すべきかの判断を動的に行う。プライム・スペース・マネージャ２０の 計算の最終結果は、どの広告がユーザに表示できるか、およびどの広告を表示す るかをシステムに正確に知らせることである。 次に、これらの広告はゲート１５に渡される。ゲート１５はこの時点で、広告 をタイポグラフィ・マネージャ１４に渡し、タイポグラフィ・マネージャ１４は 情報を表示する最良の方法を判断する。次に、ページ情報はゲート１５に戻され 、クライアント１７に転送される。本発明の上述した説明では、広告契約、アク ティブ・インデックスＳＩＣ１９、レイアウト・ルール１１、セグメンタ１２、 セグメント・ルール１３、レイアウト・マネージャ１０、およびタイポグラフィ ・マネージャ１４について説明した。 広告の計算および本発明のシステムが実行する他のすべての計算の期間に、シ ステムのロギング・モジュール（ｌｏｇｇｉｎｇ ｍｏｄｕｌｅ）２２はユーザ が何を要求したか、どの広告が表示されたか、広告がどのくらいの時間表示され たか、どの広告がどのユーザに表示されたかの、広範なロギングを行っている。 そのあと、ロギング・モジュール２２はこれらのログをＳＹＳログ・データベー ス２３にストアする。種々の調査レポートはＳＹＳログ・データベース２３内の 情報を使用して作成し、定義することができる。 本発明のローカル・クライアント２４はダウンロード・ディレイタイム広告機 能を備えている。ダウンロード・ディレイタイムとは、コンピュータ・ネットワ ークの多くのユーザが経験する、あるページがリクエストされた瞬間からそのペ ー ジがユーザのブラウザにダウンロードされる時点までの遅延のことである。ダウ ンロード・ディレイタイム広告機能はページがダウンロードされるのをコンシュ ーマが待っている時間を利用して、コンシューマに広告を見せる。ページ(また はページのサブ部分)がコンシューマのブラウザにダウンロードされて、表示で きるようになると、広告はページ・コンテント（ページ内容）によって置き換え られる。 多くのケースでは、ユーザがあるページを要求したとき、相当のダウンロード ・ディレイタイムが発生する。ユーザは要求した後、ページが最終的にネットワ ークによってダウンロードされるまでに数秒間、場合によっては、数分間ページ を待たされることになる。本発明はこのディレイタイムを利用して広告を表示す ると共に、ユーザのディレイタイムが広告の表示によって増加しないように配慮 する。従って、広告が表示される唯一の時間はユーザがとにかく待たざるを得な い時間である。ユーザがページを待っている間、ユーザはローカル・クライアン ト２４で広告を見ることができる。 図１に示す情報ブローカまたはコンテント・プロバイダはホームページ・ディ スパッチャ２５、サーチ・エンジン・インフォミックス２６、およびジェネリッ ク（汎用）ＨＴＭＬ２７を含んでいる。本発明の目的上、本発明の広告機能を利 用できるパブリッシャは３つのクラスに分類されている。コンテントをネットワ ークに提供する人ならば、ほとんど誰でも「パブリッシャ」に含めることができ る。例えば、ホームページ所有者であれば、誰でもジェネリックＨＴＭＬ２７と して示されているカテゴリに属するパブリッシャとなる。第２の種類のパブリッ シャはサーチ・エンジン・パブリッシャ２６であり、この中にはＮＹＮＥＸのよ うな電話会社イエロページ・プロバイダが含まれる。第３の種類のパブリッシャ はホームページ・ディスパッチャと呼ばれるものであり、この中にはビジネス・ ウィークなどの従来の雑誌や新聞が含まれる。 本発明では、これらの３種類のパブリッシャを区別している。パブリッシャが ホームページ・ディスパッチャ２５である場合は、パブリッシャは独自のコンテ ントを提供し、広告をどこに入れることができるか、どこに入れることができな いか、コンテントの焦点があるトピックのどこにあるかを示す特殊タグを用いて コンテントに変化をもたせる。これらの特殊タグは、ページに含まれるコンテン トのタイプ、およびページに配置することができる広告の種類に関し、本発明の システムにおいて、あるアクションをトリガするために使用される。 本発明とともに使用される第２の種類のパブリッシャはサーチ・エンジン・パ ブリッシャ２６である。現在、ユーザがデータベースに質問し、回答のセットを データベースからユーザに戻せるようにする多数の会社がＷＷＷに存在している 。例えば、電話会社は、ユーザがある特定タイプのビジネスについて電話番号と 企業名のセットを入手できるようにするサイトをもっている場合がある(つまり 、イエロページ・ディレクトリ)。 本発明の目的上、サーチ・エンジン・パブリッシャ２６はホームページ・ディ スパッチャ２５と区別されているが、これは、サーチ・エンジン・パブリッシャ ２６から戻されるコンテントが、コンテントと広告のレイアウトを定義するため にパブリッシャによって挿入された特殊タグまたはメタ・コメントを含んでいな いためである。この場合には、本発明のレイアウト・マネージャ１０は上述した ように、ルールとレイアウト・テンプレートに基づいて最適レイアウトを計算す る。従って、最終結果は出力がサーチ・エンジン・パブリッシャ２６から取り出 され、ある種の関連広告で装飾されてから、ユーザに表示されることである。 第３の種類のパブリッシャであるジェネリックＨＴＭＬパブリッシャ２７には 、おそらく望ましい外観を提供するように配慮して独自のホームページを設計し た人であると、本発明が想定しているパブリッシャが含まれる。これらのパブリ ッシャは本発明の広告システムのガイドとなる特殊タグまたはメタ・コメントを ホームページに挿入していないであろう。この場合には、本発明のシステムはペ ージの望ましい外観を侵すことなく、妥当とシステムが考えるスペースをホーム ページから見つけるか、あるいはページの前後に広告を挿入することができる。 つまり、セグメンタ１２は、ジェネリックＨＴＭＬパブリッシャ２７がすでに設 計しているページ内に適当な場所を見つけることができないと、前のページまた は後ろのページに広告を挿入する。このようなことは、ページの所有者が特殊タ グまたはメタ・コメントを与えていないか、あるいは著作権上の配慮からある広 告をページ内に挿入することを禁止している場合に起こる可能性が高くなる。 以上を要約すると、本発明によれば、パブリッシャ（つまり、情報ブローカ） は３つのカテゴリに分けられている。つまり、ホームページ・ディスパッチャ２ ５、サーチ・エンジン・パブリッシャ２６、およびジェネリックＨＴＭＬホーム ページ・プロバイダ２７である。これらの３つは次の点で区別されている。つま り、ホームページ・ディスパッチャ２５は、本発明が広告をどこに挿入し、どの 種類の広告を挿入するかを判断するときに役立つ特殊タグまたはメタ・コメント を用いてコンテントに変化をもたせる。サーチ・エンジン・タイプのパブリッシ ャ２６は未装飾の質問結果を戻し、本発明は、応答のセットを自由に再フォーマ ットし、リレーアウトすることができる。ジェネリックＨＴＭＬホームページ・ パブリッシャ２７は、通常は特殊タグまたはメタ・コメントを付けないで独自の ホームページを細心に作成しているため、広告を挿入するための該当場所を判断 するためのガイダンスが用意されていない。 セグメンタ１２はジェネリックＨＴＭＬページ上のどこに広告を挿入するかを 判断することを担当する本発明のモジュールであるが、ジェネリックＨＴＭＬホ ームページ上のスペースを見つけることに失敗する場合がある。その場合には、 広告を前のページまたは後ろのページに挿入することになる。ＷＷＷ上のパブリ ッシャはすべてではないとしても、その大部分はこれらの３カテゴリの１つまた は２つ以上に属している。 図１において、ＬＡの頭文字は広告リストを示し、Ｑはユーザの質問を示し、 ＣＧＩは「共通ゲートウェイ・インタフェース」を表す標準ＷＷＷ略語であり、 ＨＴＭＬはハイパーテキスト・マークアップ言語を表す標準略語であり、Ｌｙは レイアウト・マネージャ１０からタイポグラフィ・マネージャ１４に渡されるリ ストであり、表示する必要のあるページのリストを示している。 次に、図２を参照して説明すると、図２は、イエローページ・パブリッシャに よって提供されるコンテント・ページ上に広告を、本発明に従って挿入するプロ セスのメインフローを説明しているフローチャートである。このプロセスはクラ イアントが質問をシステムに行ったときＳＴＡＲＴ３０から開始する。説明の便 宜上、示されている質問はイエローページ質問であり、そこではユーザは関心の あるアイテムを要求しており、パブリッシャはイエローページ・パブリッシャで ある(３種類のパブリッシャの説明は前述したとおりである)。 例えば、ユーザはＭｏｒｒｉｓｔｏｗｎ，Ｎｅｗ Ｊｅｒｓｅｙのすべてのカ ー・ディーラのリストを要求する質問形式(フォーム)を送付する場合がある。こ の質問形式はＹＰ質問形式と名づけたボックス３１で評価される。この評価の目 的は質問のタイプを判断することである(例えば、ユーザは自動車、特定の地域 などに関心を持っているか)。 イエローページ・パブリッシャを使用するとき、質問は大きく２つに分けられ る。クライアントはあるカテゴリのリストを要求している場合もあるし、特定の ベンダを要求している場合もある。例えば、ユーザは、Ｍｏｒｒｉｓｔｏｗｎ， ＮＪのカー・ディーラ（つまり、あるカテゴリのリスト）を要求することもでき るし、Ｍｏｒｒｉｓｔｏｗｎ，ＮＪのＳｏｕｔｈ Ｓｔｒｅｅｔに所在するＭｏ ｒｒｉｓｔｏｗｎ ＢＭＷ（つまり、特定のベンダ）を要求することもできる。 図２のボックス３２に示すように、システムは、ユーザが質問、すなわちサーチ の２タイプのうち、どちらを要求したかを判断する。質問があるカテゴリに対す るものであれば、プロセスは図２のフローチャートの左側に進み、質問があるベ ンダに対するものであれば、プロセスは図２のフローチャートの右側に進む。ま ず、フローチャートの左側について説明する。 質問のタイプを判断した後、カテゴリ・サーチ・エンジン３３は次に、どのカ テゴリがユーザのリクエストに最もよく合致しているかを判断する。ユーザが「 カー」を要求している場合でも、イエローページ・プロバイダのインデックス内 のカテゴリは実際には「オートモビル」となっている場合がある。また、ユーザ は「スペクタクル」を要求した場合でも、イエローページ・プロバイダのカテゴ リは「オプティシャン」と名づけられている場合がある。これらの用語の違いの マッチングはカテゴリ・サーチ・エンジン３３によって行われる。 ユーザのリクエストがどのカテゴリに属するかが判断されると、広告選択プロ セスは広告セレクタ３４で活動化する。広告セレクタ３４はどの広告がユーザが 要求したものと一緒にミックスするのに最も適しているかを判断する。カテゴリ ・サーチ・エンジン３３からのコンテントと広告セレクタ３４からの広告はミキ サ３５に渡される。ミキサ３５はサーチ・エンジンからのコンテントを、広告 セレクタ３４によって選択された広告とミックスするように働く。その結果は、 ユーザに関心のあるページの作成である。 ユーザのカテゴリが自動車に関するものであれば、この時点で広告セレクタ３ ４は自動車に関する広告を見つけていれば、これらの広告をステップ３６でユー ザに表示することになる。ユーザはこの時点で、リストされたまたは広告された カー・ディーラの１つまたは２つ以上を選択することができる。この結果、さら なる広告が広告セレクタ３４によって再度選択されると共に、イエローページ・ パブリッシャが用意したベンダ・サーチ・エンジン３７のアクセスが行われ、新 しいページがユーザに表示されることになる。 図２の右側を参照して説明すると、ユーザが特定のベンダを要求していれば、 システムはまずサーチ時間見積り３８を行って、ユーザが要求した情報部分を見 つけるのにどれだけ時間がかかるかを計算する。これと同時に、広告セレクタ３ ４はユーザに表示すべき広告のサーチを行う。関係する広告が広告セレクタ３４ によって見つけられると、その広告はサーチ時間見積り情報とミックスされ、両 方がユーザに表示される。プロセスのこの時点４０で、ユーザは見積りサーチ時 間が与えられた要求サーチを続けるかどうかの確認を求められる。ユーザからの 確認を受信すると、ベンダ・サーチ・エンジン４１がアクセスされるのと同じよ うに、広告セレクタ３４が再びアクセスされる。広告セレクタから戻された最初 の広告セットは、ベンダ・サーチ・エンジン４１からのサーチ結果が得られるま で、ユーザへの表示が続けられる。 ベンダ・サーチ・エンジン４１はサーチを完了すると、サーチ結果をミキサ３ ５に戻す。同様に、広告セレクタ３４は第２の広告セットをミキサ３５に戻す。 ミキサ３５はこの広告を、ベンダ・サーチ・エンジン４１から戻されたコンテン トとミックスして、その結合ページをページ・ディスプレイ４２に転送する。 このプロセスの結果として、ユーザが提出したイエロページ質問はカテゴリ・ サーチまたはベンダ・サーチのどちらかに分類される。どちらの場合も、質問の タイプは広告のあるカテゴリとマッチングされ、サーチ結果と広告がミックスさ れ、ページが構築され、ユーザに表示される。ユーザから別の入力を受け取ると 、システムは第２の広告セットを選択し、それをパブリッシャのコンテント・ペ ー ジとミックスし、広告を含む別のページが構築され、ユーザに表示される。 図２に示す「フォーカス」矢印４３は、あるフォーカスが各カテゴリに関連づ けられていることを示している。質問は、あるカテゴリのリストまたは特定のベ ンダに向けられている場合がある。どちらの場合も、質問（例えば、オートモビ ル、外科医、法律家など）のコンテントと関連づけられている「フォーカス」が ある。さらに、ユーザの地理的場所と関連づけられていて、広告主が特定の地理 的場所のユーザをターゲットにすることを可能にするフォーカスがある場合もあ る。このフォーカス・プロセスは本発明では主要な役割を果たしている。広告が ユーザが要求したもののコンテントにフォーカスされ、または関連づけられてい ると判断できる場合を除き、どの広告も表示されない。 次に、図３Ａ乃至図３Ｄを参照して、図２のプロセスの期間にユーザに表示さ れるページ・ビューについて説明する。図３Ａ乃至図３Ｄは４つのフォーム・ビ ューを示し、これらはＦｏｒｍ＃ＹＰ＿１、Ｆｏｒｍ＃ＹＰ＿２、Ｆｏｒｍ＃Ｙ Ｐ＿３およびＦｏｒｍ＃ＹＰ＿４の連続番号を付けて示されている。これらのフ ォーム・ビューは図２のフローチャートで参照されている同一フォーム番号に対 応している。 ユーザにはまず、Ｆｏｒｍ＃ＹＰ＿１のような外観のユーザ・スクリーンが表 示され、ユーザは質問をタイプするように促される。例えば、ユーザは、Ｍｏｒ ｒｉｓｔｏｗｎ，ＮＪのカー・ディーラの質問をタイプすることができる。この 質問の結果として、前述したように、カテゴリまたはベンダのどちらかのサーチ ・タイプが得られる。実際には、ユーザは、Ｆｏｒｍ＃ＹＰ＿１から該当のボッ クスを選択することで一方または他方のサーチを選択することができる。この時 点で、システムは、サーチ・タイプがカテゴリであるか、ベンダであるかを知っ ており、また、ユーザがカー・ディーラをタイプしていたので、システムはフォ ーカスを知っている。 この時点で、サーチ・タイプがベンダであれば、システムはＦｏｒｍ＃ＹＰ＿ ２のような外観のスクリーンを表示する。このスクリーンはユーザに、システム がユーザに応答するまでに約３０秒かかることを知らせ、これでＯＫかどうかを 尋ねる。ユーザは、続けたければ、“Ｓｅａｒｃｈ ｉｔ ｎｏｗ”とラベル付 け されたボックスをクリックし、システムはサーチを開始する。 サーチ・タイプがカテゴリであれば、システムはＦｏｒｍ＃ＹＰ＿３のような 外観のスクリーンを表示する。このＦｏｒｍ＃ＹＰ＿３はカー・ディーラの見出 しの下にカテゴリ・リストを表示する。次に、ユーザはこれらのカテゴリの１つ を選択するように要求される。同時に、システムは広告選択モードに入り、広告 を選択し、ユーザに表示されているＦｏｒｍ＃ＹＰ＿３上に広告を配置する。こ の場合、Ｆｏｒｍ＃ＹＰ＿３に示されている広告はＢｅｌｌｃｏｒｅのロゴにな っている。 次に、ユーザは表示されているサブカテゴリの１つを選択し、ボックス“Ｓｅ ａｒｃｈ ｉｔ ｎｏｗ”をクリックする。 次に、システムはＦｏｒｍ＃ＹＰ＿４のような外観のスクリーンを表示する。 このＦｏｒｍ＃ＹＰ＿４に配置されている広告は広告セレクタ３４によって選択 されたものであり、このフォーム上のリストはベンダＤＢエントリ・サーチ・エ ンジン４１によってサーチされ、取り出されたものである。 以上を要約すると、システムにおけるイエローページ・サーチ・リクエストの 一般的プロセスでは、まずユーザが質問を指定し、この質問の結果はユーザが見 ることを望んでいる可能性のあるカテゴリのセットである。次に、システムはこ のカテゴリのリストから１つのカテゴリの選択を行い、そのカテゴリに属する関 係プロバイダをユーザに表示する。ユーザが質問を指定し、システムがカテゴリ のリストをユーザに表示するとき、ある広告もユーザに表示される。これは図２ のフローチャートの上半分であり、そこではカテゴリ・サーチ・エンジン３３ま たはサーチ時間見積り３８および広告セレクタ３４は２つのコンポーネントをミ キサ３５に渡し、ミキサ３５は、広告およびカテゴリ・リストまたはどのくらい 時間がかかるかのサーチ時間見積りの双方を含むページを作成する。 ユーザがカテゴリーをリクエストした場合、ユーザには、広告とユーザの質問 に関連するカテゴリーのリストとが示されることになる。ユーザが特定のベンダ ーをリクエストした場合、ユーザには、ユーザの質問のフォーカスに関連づけら れた広告と、システムがそのプロセスを処理するのにどのくらいの時間がかかる かの見積りとが示されることになる。どちらの場合も、ユーザには広告と情報 の何らかの部分とが示され、次にユーザはさらなる選択をするように尋ねられる 。ユーザがさらなる選択をすると、システムは、ユーザが何を求めたか、および このプロセスの一部としてどの広告を示すべきかを再び見いだそうとする。この ように、ユーザがシステムに何かをするように求めたときはいつでも、システム はユーザが求めたことをするし、同時に、ユーザがリクエストしたものとミック スすることができる広告を見いだす。 図２のフローチャートはイエローページ・パブリッシャとの関係においてのみ 本発明を示しているが、他のタイプのパブリッシャに対しても同様のプロセスが 使用される。ホームページ・プロバイダとの関係で広告を配置する本発明のプロ セスは、図７のフローチャートと関連して以下で説明する。 図４を参照すると、本発明のレイアウト・マネージャ１０がより詳細に説明さ れている。ステップ５０において、レイアウト・マネージャ１０は表示すべきデ ータの集まりを与えられる。レイアウト・マネージャ１０はルールの集まりを有 し、それらを評価して各ページに対して最も良いレイアウトを返すことができる 。レイアウト・マネージャ１０はデータを受け取ると、各ルールについてのデー タのパラメータを読み、エキスパンド・メタ・テンプレート５３を拡張（展開） する。 上述したように、レイアウト・マネージャ１０には２つの主要なコンポーネン トがある。レイアウト・データベースとレイアウト・ルールベースである。レイ アウト・ルールは、与えられた状況のセットの下で使うべき最も良いレイアウト を決定するために用いることができる所定のパラメータを記述する。レイアウト ・データベースはテンプレートの集まりであり、そのテンプレートはある種類の データで満たされる必要があるフォームと考えることができる。 レイアウト・マネージャー１０は、１つのデータが与えられると、ルールを用 いてどのテンプレートを使うべきかを決定する。具体的には、レイアウト・マネ ージャー１０は、ルールベースのすべてのルールをそれぞれ評価し、どのルール が与えられたデータに対して最良であるかを計算する。ルールはステップ５４に おいて、メタおよびターゲット関数コストを計算することによって評価される。 メタ・テンプレートは、レイアウトが何についてであるかについて記述するテン プレートである。例えば、テンプレートは、特定のレイアウトにおいて広告用の 場 所が５つのみであることを規定することができる。 レイアウトの各種類にはコストが関連づけられている。レイアウト・マネージ ャ１０が直面する基本的な問題は、表示すべきある数の広告が存在し、かつ、ユ ーザがリクエストした表示する必要のあるデータが存在することである。このた め、評価する必要のある、客観的な内容対主観的な内容のスペクトルが作成され る。すなわち、主観的な内容をどれぐらい供給するべきか、客観的な内容をどれ ぐらい供給するべきかを、決定しなくてはならない。パブリッシャがイエローペ ージ・パブリッシャである場合には、レイアウト・マネージャ１０はどれだけの 電話リストを表示すべきか、ページのどれだけを広告で充填すべきか決定しなく てはならない。システムは、例えば、電話リストを３つだけ表示し、ページの残 りを広告で充填することができる。また、２０個の電話リストと１つの広告のみ を表示することもできる。レイアウト・データベースの各テンプレートは、その テンプレートに関連づけられたメタ属性のセットを有する。そのメタ属性は、表 示することができる広告の数、表示されるコンテントの量、および当該テンプレ ートに関連づけられたコスト関数を示す。 要するに、レイアウト・マネージャ１０はデータベースからルールを取り出し 、各テンプレートに対するコスト関数を計算し、最小コストのテンプレートを安 全な場所にストアする(ステップ５５)。この計算が終わると、レイアウト・マネ ージャ１０は、データベース内で現在のデータ記述に用いることができる最小コ ストのレイアウトを見つけることができる。そして、レイアウト・マネージャ１ ０は最小コストのレイアウトを最高のレイアウトとして取り出し、その最高のレ イアウトを、ユーザに表示するため、タイポグラフィマネージャ１４に返す(ス テップ５２)。 図５を参照して、本発明のパーサ６０のフローチャートを説明する。パーサ６ ０の目的は、パブリッシャのページに挿入されたメタコメントとメタタグを解釈 することである。上述したように、これらは、一般的に、雑誌または新聞のパブ リッシャ（発行人）によって構成されたページである。それらのパブリッシャは 、本システムが特殊な方法で解釈するように自分のコンテントに特殊タグを設け る。これらのページは、図５では、強化されたHTMLまたはE_HTML６１として示 す。 パーサ６０は、まず、入力E_HTMLから特殊タグをサーチする(ステップ６２)。 特殊タグには、２種類のタグ、すなわち、フォーカスのためのタグと、広告スペ ースのためのタグがある。フォーカスのためのタグは、ページのフォーカスが何 であるか、あるいは、ページのコンテキストまたはコンテントが何についてであ るかをシステムに知らせるタグである。例えば、フォーカス・タグは、そのペー ジがスポーツカー、料理、またはカリブ海の旅行先についてであることを示すこ とができる。他方、広告スペース・タグはページ上のスペースを示し、そのスペ ースは、縦横が非常に多くのピクセルからなり、広告のために用いることができ る。パーサ６０はこれらの特殊タグをサーチし、タグ名を、フォーカス・タグま たは広告タグのいずれかとして識別する(ステップ６３)。パーサ６０が特殊タグ を見い出すことができなかった場合、パーサ６０は単に自分がコールされたとこ ろから戻る。 パーサ６０は、種類がフォーカスであるタグを見つけると、フォーカス・ワー ドを抽出し、ストアする(ステップ６４)。パーサ６０は、種類が広告であるタグ を見つけると、サイズ値を抽出し、ストアする(ステップ６５)。どちらの場合に も、プロセスはフォーカスおよび広告情報を、ページの終わり（ＥＯＦ）６６に 到達した後で、システムの別のモジュールに返す(ステップ６７)。 図６を参照して、ミキサおよび広告セレクタの処理の流れを説明する。(図２ を参照して前述したように、)ミキサ３５の目的は、パブリッシャのコンテント および広告を受け取り、両者を結合して一緒にし、コンテントおよび広告が同一 ページでミックスされるようにすることである。 図６において、ミキサ３５がパブリッシャから２つの入力、すなわち、(コン テントである)データ５０および（特殊タグを含んでいる）E-HTML６１を受ける ところが示されている。レイアウト・マネージャ１０とパーサ６０はともにミキ サ３５の一部を形成する。前述した通りデータ５０はレイアウト・マネージャ１ ０に入力され、E-HTML６１はE-HTMLパーサ６０に入力される。次にこれらサブ・ モジュールはともに、パブリッシャのページの何処に広告を配置できるかを決定 する。 次に、広告リストが広告セレクタ３４から入力される。広告セレクタ３４はフ ォーカス入力４３を受け取り、関連する広告を取り出し(ステップ７０)、プライ ム・スペース・マネージャ２０を用いて広告リストを作成する(ステップ７１)。 これらの広告は次に、上述した通りパーサ６０とレイアウト・マネージャ１０に 配置される(ステップ７２)。ミキサ３５は次に、全ての主要なビリングおよび他 のユーザ情報のログをとり(ステップ７３)、システムによる広告主の広告の配置 の進路を追う。この時点で、リフレッシュ・タグが挿入され(ステップ７４)、シ ステムはHTMLページを出力する(ステップ７５)。 ミキサ３５からのHTMLページ出力は特殊タグを持たず、HTMLを理解できるどの クライアントによっても表示することができる。E-HTML６１は本発明に特有であ る。HTML７５はコンピュータ・ネットワークで用いられる標準のHTMLである。E- HTML６１は上述した通り広告とフォーカスのための特殊タグを持っているという 意味で特有である。 ステップ７４で挿入されたリフレッシュ・タグは表示される全てのページに挿 入される特殊タグである。このタグの目的は、ユーザが所定期間内に何らの行動 もとらなかった場合にページをリフレッシュすることである。システムはリフレ ッシュして、広告スペースに新しい広告を示し、ページの残りは同じままにする 。このように、ユーザが注意を払う期間が限られていることを考慮して、ユーザ がページを見ている間、システムは所定期間以上は同じ広告を示さないようにし ている。これによって、システムはできるだけ多くの広告を効果的に行なえるよ うになる。 例えば、ユーザがオンライン・マガジン・ページを読んでいる間、広告を、ユ ーザが同じページを見ているのと同じ頻度毎に変更してもよい。ユーザがページ に変更を行い、またはページを前後する場合、広告は、リフレッシュ・タグ機能 によっては変更されない。リフレッシュ・タグ機能用のタイマーは、広告主が指 定するようにしてもよいし、システムが決定するようにしてもよい。 上述した通り、このシステムでサポートする契約には５つの基本的なタイプが ある。その１つ、比率に基づく契約の場合、広告は、情報の最初のスクリーン上 、または情報のプライム・スペース・スクリーン上に、時間の一定パーセンテー ジ だけ表示される必要がある。この契約を満足するため、システムは、プライム・ スペース・スクリーンをリフレッシュできなければならない。そうでない場合、 ユーザのスクリーン上に一度広告が配置されると、ユーザがスクリーンを見てい るすべての時間において、その広告がスクリーン上に残ってしまう。挿入リフレ ッシュ・タグ機能７４により、ユーザに新しい広告が示され、ユーザが長時間に 渡って同じ広告にさらされないことが確保される。 図７を参照して、ホームページ・プロバイダに使用されている本発明のフロー チャートを説明する。図７のフローチャートは、幾分図２のそれに類似している 。しかしながら、図２のフローチャートがイエローページ・パブリッシャに使用 されるプロセスを示すものであるのに対して、図７のそれはホームページ・プロ バイダ・パブリッシャに使用されるプロセスを示している。上記したように、ホ ームページ・プロバイダとは、本システムに供給されるメタ・コンテント中に特 殊タグとフォーカス、それに広告スペース・タグを提供するパブリッシャである 。 開始する（ステップ８０）にあたって、ユーザは質問を入力する。例えば、ユ ーザはレストランや自動車を質問として入力することができる。質問は上記した ようにフォーカスを有している。システムはフォーカスが何であるかを決定し、 また上記したように、ユーザに対して質問に関連したカテゴリーのリストを提供 する。例えば、ユーザがレストランを要求したとすると、チャイニーズ、アメリ カン、フレンチ、イタリアン等のような、レストランのタイプのリストがユーザ に示される場合がある。ユーザにより入力された質問は、質問形式マネージャに より評価され(ステップ８１)、その質問のフォーカスが決定される。 図８Ａに示すスクリーン（"Form#1"）は、質問を入力するために使用されるグ ラフィカル・インターフェースである。Form#1には（"SEARCH FOR"という句のす ぐ後に）スペースが示されており、このスペースにおいて、ユーザは質問（この 場合「自動車」）をタイプする。質問の結果は、図８Ｂ（"Form#2"）に示すように 、自動車についての関連するサブカテゴリーのリストである。 再び図７を参照するが、カテゴリー・サーチ・エンジン３３は、質問（例えば 自動車）についての多くのサブカテゴリーを生成し、広告セレクタ３４（図７） は、自動車に関連するいくつかの広告を見つけ出す。ミキサ３５はこれら２つの スクリーンをミックスして図８ＢのForm#2に示す表示を生成する(ステップ８２) 。 この時点（ステップ８２）で、ユーザはさらなる選択をするように求められる 。即ち、システムがより詳細な情報を供給できるように、ユーザはForm#2に表示 されているカテゴリーの１以上を選択するよう求められる。例えば、ユーザは、 「新車および中古車のデイーラ小売り(new and used car dealers retail)」を 、そのアイテムをハイライトさせ、サブミット(submit)・ボタンをクリックする ことにより、選択することができる。サブミット・ボタンをクリックすると、コ ンテント・プロバイダ・サーチ・エンジン８３がアクセスされる。それと同時に 、広告セレクタ３４は、カテゴリー「新車および中古車のディーラ小売り」に適 切な広告を見つけ出すよう指示される。 コンテント・プロバイダ・サーチ・エンジン８３および広告セレクタ３４は、 それぞれの出力をミキサ３５に戻す。ミキサ３５はこれら出力をミックスし、マ ッチするコンテント・プロバイダのリストに広告を加えたものを生成する(ステ ップ８４)。この時点での結合された表示を、図８ＣにForm#3として示す。Form# 3は、表示の中央に異なる自動車ディーラのリストを示し、表示の両側に沿って ５つの広告を示す。 ユーザは、さらに、訪問を希望する特定のディーラ（例えば、マツダ６２６デ ィーラまたはフォード・ムスタング・ディーラ）を選択するように求められる。 ユーザは選択を行い、その選択はコンテント・プロバイダ・ディスパッチャ８５ と広告セレクタ３４に与えられる。コンテント・プロバイダ・ディスパッチャ８ ５が要求されたホームページを取り出す際、広告セレクタ３４は、ユーザの要求 に基づいて適切な広告を再度見つけ出す。 例えば、ユーザはマツダ６２６をクリックすることによりマツダ６２６ディー ラを選択することができる。マツダ６２６ディーラのページを取り出す際、広告 セレクタ３４は、このページに挿入することができる広告を見つけ出す。マツダ ６２６ディーラのホームページ上には、広告スペースがある場合もあるし、ない 場合もある。システムが広告を配置するためのスペースがホームページ上にない 場合、システムは、そのページの前あるいは後ろに広告を挿入するか、もしくは 広告を全く配置しないと決定することもできる。いずれにせよ、要求されたいか なるホームページに対しても、広告セレクタ３４は適した広告を見つけ出し、そ れらの広告をミキサ３５に与えることを試みる。そして、この時点でミキサ３５ はコンテント・プロバイダのホームページを、広告付き、または広告なしで表示 する。 端的に言えば、図８Ａ−８Ｃは、図７おいてForm#1、Form#2およびForm#3とし て参照した３つのスクリーン表示をそれぞれ示している。Form#1はユーザが最初 に見るスクリーンであり、ユーザはタイプ可能なスペース内に大まかな質問をタ イプ入力するよう期待されている。この後、ユーザはカテゴリーのリストからの 選択を為すよう求められる第２の画面（Form#2）に到達する。この第２のスクリ ーンのカテゴリーのリストから選択した後、さらにサブカテゴリーのリストから の選択を要求する第３のスクリーン（Form#3）がユーザに示される。本発明は、 これら３つの画面を、ユーザの要求に関連した広告を表示するためにも使用する 。Form#1は、サービス・プロバイダのオーナ（例えば、この場合はBellcore）の ために２つの広告を示している。Form#2はユーザが自動車とタイプ入力したので 自動車に関連した広告を示している。Form#3はユーザが小売り自動車ディーラを 要求したので、特定の銘柄の自動車に関連したさらなる自動車の広告を表示して いる。 本発明のビリング・システムの説明が図９Ａおよび９Ｂを参照して為されてい る。図９Ａおよび９Ｂは、インフォ・バンクおよび広告監査と呼ばれる、システ ムの２つのサブモジュールを示している。これら２つのモジュールの目的は、本 発明の様々な処理のログ・レポートを構築することである。 図９Ａは、インフォ・バンク・サブモジュール９０のプロセス・フローを示す 。インフォ・バンク・サブモジュール９０の目的は、特定のクライアントのセッ ションの間、ある特定の種類の情報のログをとることである。ログをとった情報 は、その後、広告主に、何の広告が示され、ユーザが広告を見た後、何を買った か、等々の説明を与えるために使用される。従って、インフォ・バンク・サブモ ジュールは、インフォ・バンクを提供して、広告主に、誰がシステムにアクセス したか、および広告がどの程度成功したかを示す。 関連するモジュールのスクリーンは、ユーザが選択できるインフォ・バンクと 呼ばれるリンクを含んでいる。ユーザがインフォ・バンク・リンクをクリックす ると、ユーザには、インフォ・バンク・サブモジュールの開始９１が示される。 この時点で、ユーザは、ユーザ名、個人識別番号（ＰＩＮ）などの証明情報（au thentication information）を要求される(ステップ９２)。システムはその後、 証明モード９３に入り、タイプ入力されたユーザＩＤとＰＩＮ番号が有効なもの であるかを検査する。もし証明に問題がなければ、システムはその後トランザク ション（transaction）ログおよびフィルタをサーチし(ステップ９４)、ユーザ から要求された適切なログを引き出す。ユーザは、クライアントにより為された すべてのトランザクション、またはユーザが買った一定のタイプのすべてのもの を見ることを要求することができる。結果のレポート（ステップ９５）は、クラ イアントのために自動的に生成され、表示される。 広告監査９６のサブモジュールは、インフォ・バンク・サブモジュールのそれ に類似した目的を持っている。この広告監査により、本システムで広告を配置し た広告主は、どの時点でもシステムに入り込み、自分の広告を誰が見たのか、広 告が表示されたときの質問の内容は何であったか、広告は何回表示されたか、等 を見つけ出すことができる。証明および他のプロセス・ステップは、インフォ・ バンク・サブモジュール９０の対応するステップに類似している。 さらに詳述すれば、広告監査サブモジュール９６を使用するため、広告主には 、広告監査のためのリンクを有するスクリーンが示される。ユーザはこの広告監 査リンク上でクリックし、広告監査モジュールの開始９７に導かれる。広告主は その後、ユーザ名およびそれに続くＰＩＮ番号からなる証明情報をタイプ入力す るように要求される(ステップ９８)。ＰＩＮおよびユーザ名がチェックされ、証 明ステップ９９で証明された場合、ユーザは、システムに対してどの広告または 広告のどのサブセットを調査または監査したいのかを告げるよう要求される(ス テップ１００)。ユーザが、名前により、またはシステム内のすべての広告をブ ラウズし、ユーザがレポートを得たい広告をクリックすることにより、一度広告 を特定したならば、システムは、誰がその広告を見たのか、その人たちが使用し ていたマシンは何だったのか、何時に、およびどのくらいの期間広告が表示され て いたのか、ならびにその他の希望する情報についてのログであるレポートを生成 する(ステップ１０１)。 インフォ・バンクおよび広告監査サブモジュールによりアクセスされたすべて のログ情報について、単一のデータベース２３においてログがとられる(図１)。 ユーザが監査情報、トランザクション、ユーザが購買した物、あるいはユーザ・ デモグラフィを探しているか否かに係わらず、情報はすべて同じデータベース内 にある。しかしながら、ユーザがインフォ・バンク・サブモジュール９０を使用 するときは、上述のように、そのユーザはある特定の物にしか興味を持っていな い。しかし、ユーザが広告監査サブモジュール９６を使用するときは、そのユー ザは他のことに興味を持っている。従って、インフォ・バンクおよび広告監査サ ブモジュールにより生成されるレポートは、異なるデータを含んでいる。データ ベースはフィルタにかけられ、特定のレポートに関係するアイテムのみが保持さ れるので、データベースの残りは使用される必要がない。 図１０を参照して、本発明に基づく広告配置プロセス１１０のフローを説明す る。広告配置の目的は、広告主がシステムに広告を入力できるようにすることで ある。広告を入力するために、システムはユーザにスクリーンを示し、ユーザに 対して、広告の入力を望んでいるのかどうかを尋ねる。ユーザがクリックにより 特定の選択を行ってイエスを指示したならば、システムは広告配置モードのスタ ート１１１に入る。この時点で、システムはユーザーにフォーカスについて尋ね る(ステップ１１２)。広告主は、例えば、自動車事業、洗車業を行っているとか 、医者、弁護士であるとか、あるいは広告主が与えたいと望むいかなる他のカテ ゴリーの名称を述べることができる。ユーザはステップ１１２で広告名について も尋ねられる。これは単に将来の参照のための名称である。 ステップ１１２におけるフォーカスの目的は、上述したように、手元の質問に 関連がない広告を示すことを防ぐことである。本発明のシステムは、常に、ユー ザが求めたことに関連がある広告を示す。それゆえ、システムが広告のコンテキ ストを知っていることは非常に重要なことである。従って、広告主が広告を配置 すると、システムはフォーカスを確立する。 本発明は、ほぼ６４，０００カテゴリーで分類しているＳＩＣコードによって 世界を記述する。例えば、システムはオペラ・グラスとオペレーティング・テー ブルとの間に区別があるということを知っている。システムは法律家と医者との 間の区別、同様に医者の色々な種類間の区別を知っている。例えば、ユーザがフ ォーカスとして自転車をタイプ・インした場合、本発明はカテゴリ・サーチ・エ ンジン３３にアクセスし、自転車ビジネス（例えば、自転車修理、自転車販売、 スポーツとしての自転車乗り、等）に関するサブカテゴリのリストを返す。ユー ザは、ユーザの広告に関連があるリストから１以上のサブカテゴリを選択するよ うに促される(ステップ１１４)。ユーザは、この時点で独自のカテゴリを作り出 すこともできる。この結果、広告はユーザによって選択され、あるいは作成され たカテゴリの全てに結び付けられる。 ユーザに、一定の人口統計学（demographic）情報あるいはプロファイル情報 の提供を求めることもできる。例えば、ユーザは、３０歳から４０歳のグループ の人々にのみ、またはMorristown，NJあるいは他の地理的位置に住んでいる人々 にのみ広告を見せることを要求することができる。ユーザが最後に指定を求めら れるアイテムは契約である。広告主に利用可能な種々の契約については上述した 通りである。ユーザがこの情報の全てについて入力を終了すると、システムは広 告情報データベースを更新する(ステップ１１５)。 システムは、その後、広告を受け入れるか(ステップ１１６)、あるいは拒絶す るかのいずれかを行う。ユーザが望んだ契約をシステムが満足できないという理 由で、システムは広告を拒絶する場合がある。システムがこの時点でユーザの契 約を満足できないと判断すると、システムはユーザに対して、満足することがで きる次に良い契約を表示する。ユーザがその契約を選択するか、あるいは異なる 契約を提案してシステムに考慮させるかは自由である。広告の配置を確認すると 、広告はデータベースの一部となる。 図１１を参照すると、本発明に基づくページ配置プロセス１２０のフローが説 明されている。ページ配置プロセスの目的は、図１０を参照して上で説明した広 告配置プロセスに類似する。ページ配置プロセス１２０は、サーチ・エンジンの 一部としてページが本システムの外部に存在する場合、または誰か他の人がホー ム・ページを所有しているためページが本システムの外部に存在する場合とは異 なる。ページ配置プロセスは、本システムで利用するためにホーム・ページを生 成することに興味のあるパブリッシャに利用される。ページ配置プロセスにより 、パブリッシャはメタ・タグ（metatags）およびメタ・コンタクト(meta contac ts)を有するホーム・ページを提供することができる。 ページ配置プロセスは、メニュー選択の１つが「ページを配置したいですか？ 」である開始スクリーン１２１を有する。ユーザがそのメニュー選択をクリック すると、ユーザに対しスクリーンが示され、ユーザはページ名、ページURL(すな わち、Universal Resource Locator)、およびフォーカスをタイプすることを求 められる。URLは、そのページが実際に存在するWWWに関する物理アドレスである 。上で説明したように、フォーカスは、そのページの内容をキャプチャする（と らえる）ものとユーザが信じるキーワードのリストである。 フォーカス、ページ名、およびページURLを入力すると、システムはカテゴリ ・サーチ・エンジン３３から、そのフォーカスに強く関連するサブカテゴリのリ ストを取り出し、ユーザにそれらのサブカテゴリを表示する(ステップ１２４)。 ユーザはそれらのサブカテゴリの１または２以上を、そのページの内容に関連す るものとして選択する。その後、システムはそのページを本発明のページ・デー タベースに格納し(ステップ１２５)、その新たなホーム・ページを関連するカテ ゴリにリンクしたことの確認を返すことができる(ステップ１２６)。 図１２を参照すると、本発明の基礎をなすトランザクション・システムのアー キテクチャが説明されている。本発明の基本的特徴の１つは、ユーザに表示され る広告が、クライアントが広告主に対しより一層の行動をとるゲートウェイを提 供することである。すなわち、広告は、ユーザがその広告を見るためだけにそこ にあるのではなく、インタラクティブなのである。 例えば、システムがユーザに自動車またはクッキーの絵を示し、ユーザが買い たい、またはその広告された製品についてのより一層の情報を受け取りたい場合 、ユーザはシステムとトランザクションをすることができる。トランザクション は非常にシンプルにすることができ、例えば、ユーザが広告をクリックすると、 その特定の製品についてのすべての情報が表示されるようにすることができる。 あるいは、トランザクションをより複雑なものにすることもでき、例えば、ユー ザ がシステムに会話を実際に入力して製品を買うようにすることもできる。 図１２に示すフロー・チャートは、クライアントがある広告を見て、その広告 をクリックして実際に何かを買うことについての典型的なシナリオを説明する。 具体的には、この人が買おうとするものは何でも、多数のサーバを巻き込むこと になる。クライアントはホスト１上で動作し、クライアントが要求するトランザ クションは多数のサーバ、たぶん地理的に離れたサーバを巻き込むであろう。ホ スト４は、コンピュータ・ネットワーク上のどこかのバンク（銀行）で動作する バンク・サーバである。ホスト３はログをとり、トランザクションの焦点として 役立つトランザクション・サーバである。ホスト２は、ホスト１に収容されたク ライアントからのトランザクションの開始を受け取るサーバである。 クライアント１３０が広告を見てその広告をクリックするという典型的なトラ ンザクションを、図１２に示すトランザクション・システム・アーキテクチャ・ ダイアグラム、および図１３Ａおよび図１３Ｂに示すスクリーン表示を参照して 、ここで説明する。広告上でのクリックという行動は、ホスト２のゲート１３１ によりキャプチャされ、その後適切な情報がホスト２のトランザクション・クラ イアント１３２によりクライアントに表示される。例えば、トランザクション・ クライアント１３２は、クライアントに望ましいトランザクションの型を入力す るように促すことができる。ホスト２のトランザクション・クライアントは、ホ スト３のトランザクション・サーバ１３３のクライアントである。 図１３Ａおよび１３Ｂを参照すると、典型的なトランザクションにおいて、ユ ーザは、特定のパブリッシャによって提供される特徴リストからある項目(アイ テム)、この場合は「インターネットＤＭＶ」の項目を最初にクリックする。２ 番目のスクリーン表示（図１３Ｂ）が次に現れ、そのページ中央に"Division of Motor Vehicles,Morristown,New Jersey,Automatic Renewal of Driving Licen ce."という広告が提供される。ユーザは次に、この特定の広告をクリックするこ とができる。この時点で、ユーザに対してスクリーンが示され、ユーザは、どの ようなタイプのトランザクションをしたいかを尋ねられる。ホスト２においてト ランザクション・クライアントが生成する次のスクリーンには、例えば、「免許 を更新したいですか？」、または「新規自動車登録したいですか？」と示される。 もしユー ザが「私は運転免許を更新したいです」と答えると、このリクエストはホスト２ においてトランザクション・クライアント１３２によってキャプチャされ、ホス ト３のトランザクション・サーバ１３３に与えられる。ホスト３のトランザクシ ョン・サーバ１３３は次にこの運転免許の更新リクエストを受けて、そのローカ ル・データベースから埋めるべき適当なフォームを取り出して、このフォームを ホスト２のトランザクション・クライアント１３２に提供する。ホスト２のトラ ンザクション・クライアント１３２は次に、これらのフォームを受け取り、ホス ト１のクライアント１３０からの助けを受けて、これらのフォームをクライアン ト情報で埋める。このように、クライアントの名前、アドレス、自動車ＩＤ、お よび他の必要な情報がクライアントのために自動的に埋められる。 クライアント１３０がＰＩＮ番号のタイプ入力を要求されて、トランザクショ ンの第２パートが開始される。クライアント１３０がＰＩＮ番号をタイプ入力す ると、トランザクションの第２パートが開始される。トランザクションの第２パ ートは、現在埋められており、運転免許の更新リクエストを構成するフォームが ホスト１のクライアント１３０からホスト２のトランザクション・クライアント １３２へ送られ、ホスト２のトランザクション・クライアント１３２からホスト ３のトランザクション・サーバ１３３へ送られることである。この時点で、ホス ト３では２つのことが起こらなければならない。第１に、この運転免許を更新す る特定のリクエストは、この人間が免許を更新したというレコードを作成し、ク ライアントにコンファメーション（確認）を送り返すことにより処理されなけれ ばならない。第２に、トランザクション・サーバ１３３は、この運転免許更新に ついて支払いを受けなければならない。換言すると、クライアントとＤＭＶとの 間でやりとりされるべき料金が存在しなければならない。 料金のやりとりにおいて、トランザクション・サーバ１３３は、ホスト４のバ ンク・サーバ１３５に対するトランザクション・クライアント１３４としても振 る舞うことになる。トランザクション・クライアント１３４は、ホスト４のバン ク・サーバ１３５に対して、メッセージを送り、クライアントのＰＩＮ番号、お よびクライアントの預金口座から一定の料金を控除する（差し引く）権限を有す ることを示すメッセージを送る。バンク・サーバ１３５はその情報を証明し、自 身のレコードにその情報のログをとり、借方への記入について電子的な承認を送 り返す。 トランザクション・クライアント１３４は、その時点で、ホスト３のトランザ クション・サーバ１３３に対し支払い受領を知らせる。ホスト３のトランザクシ ョン・サーバ１３３は金銭の受領、リクエストの受け取りについてログをとり、 トランザクション・クライアント１３２とゲート１３１を通じてコンファメーシ ョン・メッセージをホスト１のクライアント１３０へ送り返す。コンファメーシ ョンは、例えば、「あなたのリクエストを受け取りました。あなたの預金口座か ら１７ドルを控除しました。あなたの免許はメールにあります。あなたの新しい 運転免許番号はこれです。どうもありがとうございました。」というものにする ことができる。 図１４を参照し、本発明のトランザクション・プロセスをフローチャートを引 用して説明する。ユーザがトランザクションを要求する適当な広告をクリックす ると処理（ステップ１４０）を開始する。そしてシステムはユーザをトランザク ション・サーバにリンクさせる(ステップ１４１，ステップ１４２)。トランザク ション・サーバは次に、必要とされるフォームをクライアントに返し(ステップ １４３)、クライアントはフォームをユーザのプロファイル情報で埋める。フォ ームはトランザクション・サーバに再び送られる(ステップ１４４)。トランザク ション・サーバはバンク・サーバにアクセスして(ステップ１４５)、ユーザが必 要な金額を持っているか、およびその金額を引き出せるかを判断する。 バンク・サーバにより証明されると、トランザクション・サーバはバンク・サー バから、ユーザが有効な預金口座番号を与えたこと、およびバンク・サーバが実 際にユーザを証明し、バンクからの適当な額の控除を証明したことのコンファメ ーションを受け取る(ステップ１４６)。トランザクション・サーバは次に控除を 行ない、控除された額をバンク・サーバのログに入れる(ステップ１４７)。これ らのログは保持されて、ユーザはいつでもお金をいくら使ったか、または誰がど んなものを買ったかを知ることができる。トランザクション・サーバはまた、ト ランザクション・タイムおよび所望のトランザクションの他のいかなる詳細につ いてのトランザクション・サーバ・ログを保持する(ステップ１４８)。ログを とることが完了すると、トランザクション・サーバは次にトランザクションのコ ンファメーションを生成する(ステップ１４９)。このコンファメーションはクラ イアントに表示される。 図１５を参照し、ここでプライム・スペース・マネージャ２０についてさらに 詳細に説明する。上述した通り、本発明の重要な特徴は、プライム・スペース( ユーザに対して表示される最初の情報スクリーン)において広告がどのように、 いつ表示されるかについて、契約上の一定の保証を広告主に提供することである 。これら契約上の保証には、頻度に基づく契約、比率またはパーセンテージに基 づく契約、排他的または競合的な契約、従属契約、およびストーリ契約が含まれ る。これらの契約は、上述のように、個別にあるいは様々に組み合わされて用い ることができる。 プライム・スペース・マネージャ２０は、プライム・スペース・アルゴリズム １５０を有し、これは入力として、手元の質問に関連する関連広告リスト、プラ イム・スペースのサイズ、および全ての広告契約のリストを受ける。プライム・ スペース・マネージャ２０は、次に全ての広告契約を見て、どの広告をユーザに 示すべきかを決定する。プライム・スペース・マネージャ２０は、次に契約を更 新して(ステップ１５１)、どの広告が選ばれたかを知らせる(この情報はどの広 告が次に選ばれるべきかを考慮する際に用いられる)。プライム・スペース・マネ ージャ２０は、次に適当なモジュールに示すプライム・スペース広告のリストを 提供する。すなわち、プライム・スペース・マネージャ２０は、非常に長くなる 可能性がある広告リストを受け入れ、所有する契約に基づき、その広告をフィル タしてより小さなリストにする。そのより小さなリストには、プライム・スペー スのサイズに基づき表示することが可能な数ちょうどの広告が含まれる。 次のプライム・スペース・アルゴリズムの例は、本発明のプライム・スペース・ マネージャ２０の関数と動作をさらに説明するために提供される。これらのアル ゴリズムについて多くの変形が可能であり、単に説明のためだけに特定の例を提 供するにすぎないことに注意されたい。 表記： Ａ₁・・・・・・Ａ_nは本発明システムにおける広告を表すとする。 Ｐ₁・・・・・・Ｐ_nは対応する広告に関連する契約値を表すとする(Ｐ_iは広告Ａ_iに 関連する契約値を、広告主によって支払われる価格の関数として表す)。 Ｓは本システムにおけるプライム・スペースのサイズを表すとする。 プライム・スペース： ユーザ端末上のプライム・スペースとは、ユーザの質問に対する回答（に関連 する広告を付加したもの）によって構成されたデータを示す第１のスクリーンを 意味するものである。このコンテキストにおいて、広告主は、請求料金に対応し た形で広告がターゲット・ユーザに提供されるという意味で、「公平」な取り扱い を保証される。公平とは、より多く支払った広告主が、より少なく支払った広告 主よりも、より多くアクセス可能であることを保証する制御アクセスのみならず 、平等なアクセスをも意味する。 契約： 契約とは、関連するユーザの質問に応じた所与の広告の表示頻度を示す明細の ことである。 下に示すプライム・スペース・アルゴリズム例は、以下の４タイプの広告契約 に用いることができる： １．頻度に基づく契約：この契約では、関連するユーザの質問に応答して所与 の広告が表示される回数を特定する。 ２．比率に基づく契約：この契約では、関連するユーザの質問に応答して所与 の広告がプライム・スペースにどの程度の割合で表示されるかを特定する。 ３．従属契約：ある広告Ａ_iは、他の広告Ａ_jに対してＸ％の従属契約を有する ことができる。従属契約は、広告Ａ_jが表示される場合のうち少なくともＸ％、 広告Ａ_iが広告Ａ_jと一緒に表示されることを保証する。 ４．排他的契約：ある広告Ａ_iは、他の広告Ａ_jに対して排他的契約を有するこ とができる。排他的契約は、広告Ａ_iが広告Ａ_jと一緒に表示されないことを保証 する。 頻度に基づく契約のアルゴリズム： ＷＨＩＬＥ（スクリーン・スペースが満たされていない） ｂｅｇｉｎ １．ある広告、例えばＡ_iを選択する。その選択は契約値Ｐ_iに基づく偏った 選択である。 ２．Ａ_iをスクリーン・スペースに含める。 ｅｎｄ 比率に基づく契約のアルゴリズム： ＷＨＩＬＥ（プライム・スペースが満たされていない） ｂｅｇｉｎ １．ある広告、例えばＡ_iを選択する。その選択は契約値Ｐ_iに基づく偏った 選択である。 ２．Ａ_iをプラィム・スペースに含める。 ｅｎｄ 従属契約のアルゴリズム： ＷＨＩＬＥ（プライム・スペースが満たされていない） ｂｅｇｉｎ １．ある広告、例えばＡ_iを選択する。その選択は契約値Ｐ_iに基づく偏った 選択である。 ２．ＡにＡ_iを割り当てる。 ３．ＷＨＩＬＥ（いくつかの広告が選択され、かつ、プライム・スペースが 満たされていない） − Ａに従属するものの１つ、例えばＡ_jを選択する。その選択は契約値 Ｐ_jに基づく偏った選択である。 − ＡにＡ_jを割り当てる。 − Ａをプライム・スペースに含める。 ｅｎｄ 排他的契約のアルゴリズム： ＷＨＩＬＥ（プライム・スペースが満たされていない） ｂｅｇｉｎ １．ある広告、例えばＡ_jを選択する。その選択は契約値Ｐ_iに基づく偏った 選択である。 ２．Ａ_iに対して排他的契約を有するすべての広告Ａ_jを排除する。 ３．Ａ_iの排他的契約の対象であるすべての広告Ａ_kを排除する。 ４．Ａ_iをプライム・スペースに含める。 ｅｎｄ プライム・スペース管理全体のアルゴリズム： ＷＨＩＬＥ（プライム・スペースが満たされていない） ｂｅｇｉｎ １．ある広告、例えばＡ_iを選択する。その選択は契約値Ｐ_iに基づく偏った 選択である。 ２．ＡにＡ_iを割り当てる。 ３．ＷＨＩＬＥ（いくつかの広告が選択され、かつ、プライム・スペースが 満たされていない） − Ａに対して排他的契約を有するすべての広告Ａ_jを排除する。 − Ａの排他的契約の対象であるすべての広告Ａ_kを排除する。 − Ａに従属するものの１つ、例えばＡ_mを選択する。その選択は契約値 Ｐ_mに基づく偏った選択である。 − ＡにＡ_mを割り当てる。 − Ａをプライム・スペースに含める。 ｅｎｄ 一貫性チェックのアルゴリズム： 表記： Ｐ_AはノードＡのプライム・スペース契約値を示すものとする。 Ｄ（Ａ，Ｂ，Ｘ）は広告Ａから広告Ｂへの従属契約値を示すものとする(Ｂが 現れている場合のうちＸ％は、ＡもＢと一緒に現れているべきである)。 Ｅ（Ａ，Ｂ）は広告Ａから広告Ｂへの排他的契約を示すものとする(排他的契 約には値が関係しないことに注意されたい)。 プライム・スペース契約値Ｐ_A、従属契約の集合Ｄ(Ａ，１，ｘ),...，Ｄ(Ａ， ｋ，ｙ)、および排他的契約の集合Ｅ(Ａ，１),...，Ｅ（Ａ，ｑ）を有する新た な広告Ａをシステムに導入する場合、すべての契約の一貫性をチェックするため 、以下の基本的なチェックをする必要がある(具体的なアルゴリズムおよびその アルゴリズムの実現には、より具体的なチェックが必要かもしれない)： １．不等式（Ｉ）を満たせるか否かをチェックする。 ２．従属契約Ｄ（Ａ，ｉ，ｘ）のそれぞれについて、不等式（ＩＩ）を満たせ るか否かをチェックする。 ３．排他的契約Ｅ（Ａ，ｉ）のそれぞれについて、不等式（ＩＩＩ）を満たせ るか否かをチェックする。 一貫性チェック・アルゴリズムは、新たな広告を対応する契約に適応させるこ とができるか否かを確認する。新たな広告を適応させることができる場合は、契 約を承認し、システムが新たな追加を反映するように更新する。そうでない場合 は、一貫性チェック・アルゴリズムは、新たな広告に適応させることができる最 高の契約を広告主に知らせる。 従属契約および排他的契約をチェックするために、すべての広告を有向グラフ 中のノードとして表して、グラフを描く。従属契約「広告Ｃは、広告Ｄが現れて いる場合のうち５０％は、(一緒に)現れている」は、ノード「Ｃ」からノード「Ｄ」 へのエッジとして表される。０．５の重みをこのエッジに割り当てる。排他的契 約Ｅ（Ｃ，Ｄ）のそれぞれについて、グラフ中にエッジが存在する。このように 、グラフは形成され、ノードは広告を示し、エッジは従属および排他的契約を示 す。 新たな従属契約Ｄ（Ａ，Ｂ，Ｘ）を導入する場合、一貫性のため以下のチェッ クを行う必要がある。 新たな排他的契約Ｅ（Ａ，Ｂ）を導入する場合、（ｘのいかなる値に対しても ）以下の条件（ＩＩＩ）を維持すべきである。 ここでＸ_(A,B)はＡからＢへの従属エッジ、すなわちＤ（Ａ，Ｂ，Ｘ_(A,B)）の重 みを示す。 公平さ： 本システムのアルゴリズムの公平保証により、当該広告に課される料金に比例 して広告を表示することを確実にする。頻度に基づく契約アルゴリズム、比率に 基づく契約アルゴリズム、および従属契約アルゴリズムの公平さは、契約値の確 率分配、および正確なランダム・バイアスで広告を選択するランダム数字ジェネ レータに基づくものである。ランダム数字ジェネレータが特定の範囲で数字を生 成する確率は、その範囲の広がりに比例する。範囲が広くなるほど、その範囲に 対応する数字が選ばれる可能性は高くなる。各広告には、その広告に課される料 金に応じて値の範囲が割り当てられる。課される料金が高くなるほど、その広告 に割り当てられる範囲は広くなる。これにより、料金が高くなるほど、高い頻度 で広告が表示されることが確実になる。 排他的契約は、広告の表示に関して課される制約である。排他的契約を満たす ことにおける公平さとは、その契約を満たすことを意味する(排他的契約を有す る２つの広告が一緒に表示されることはない)。広告Ａが選択されてプライム・ スペースに表示されるとすぐに、プライム・スペース管理アルゴリズム１５０に より、広告Ａと関連契約のあるすべての広告が排除される。 公平を確実にするために、契約は一貫したものでなければならない。広告主と 契約を交渉するとき、一定の一貫性チェックを行い、公平保証が実際に満たされ ることを確実にする。 ストーリー広告： ストーリー広告は、時間が進むにつれて動的に変化する広告の一種である。ス トーリー広告は、従来の静的な広告のシーケンスにより構成され、それらが一体 となってストーリーを伝える。ストーリー広告を、リフレッシュ・インサート・ タグ（ｒｅｆｒｅｓｈ−ｉｎｓｅｒｔ ｔａｇｓ）という概念を用いて表示する 。ページに結合されたリフレッシュ・タグは、ストーリー広告がリフレッシュさ れる（シーケンス中の次の広告が表示される）までの時間を示す。他のすべての 静的な広告は、リフレッシュ・タイマの影響を受けない。クライアントまたはア プリケーションにより、リフレッシュ・タグを設定することができる。このよう に、ストーリー広告は多くの広告の論理的なシーケンスであり、広告は一度に１ つずつ、それぞれのリフレッシュ・サイクルで表示される。 本発明が上で説明した、または添付図面に示した構成またはプロセス・ステッ プそのものに限定されないこと、および本発明の範囲から逸脱せずに種々の修正 および変更を行うことができることが理解されるであろう。本発明の範囲は付属 の請求の範囲によってのみ限定されることを意図するものである。 請求の範囲 １．コンピュータ・ネットワーク上で広告を行うシステムであって、 複数の広告を含むサーバと、 前記サーバをコンピュータ・ネットワークに電子的に接続する手段と、 前記ネットワーク上で入力された質問に応答して前記サーバから広告を選択し 、取り出す手段と、 前記サーバに含まれる広告が前記選択する手段により選択された場合には、前 記広告の各々に結び付けられた広告主の契約の各々に基づいて制御を行うプライ ム・スペース・マネージャ手段と を備えたことを特徴とする広告システム。 ２．請求項１に記載の広告システムであって、前記選択する手段は、選択され る広告が質問に関連することを保証する手段を有することを特徴とする広告シス テム。 ３．請求項１に記載の広告システムであって、取り出された広告を、前記質問 に応答して前記コンピュータ・ネットワークにより返送されたコンテント・ペー ジと結合するミキサ手段をさらに備えたことを特徴とする広告システム。 ４．請求項３に記載の広告システムであって、前記ミキサ手段は、前記取り出 された広告および前記コンテント・ページを含む結合されたページの最適なレイ アウトを計算するレイアウト・マネージャ手段を有することを特徴とする広告シ ステム。 ５．コンピュータ・ネットワーク上で広告を行う方法であって、 複数の広告をサーバに配置するステップと、 前記サーバを、コンピュータ・ネットワークと電子的に通信する状態にするス テップと、 前記ネットワークに入力された質問に応答して前記サーバ上の広告を選択する ステップと、 前記サーバ上の広告が選択された場合には、前記広告の各々に結び付けられた 広告主の契約の各々に基づいて制御を行うステップと、 前記選択された広告を前記サーバから取り出し、ユーザに表示するステップと を備えることを特徴とする広告方法。 ６．請求項５に記載の広告方法であって、前記取り出された広告を、前記質問 に応答して前記コンピュータ・ネットワークにより返送されたコンテント・ペー ジと結合するステップをさらに備えることを特徴とする広告方法。 ７．請求項６に記載の広告方法であって、前記取り出された広告および前記コ ンテント・ページを含む結合されたページの最適なレイアウトを計算するステッ プをさらに備えることを特徴とする広告方法。 【図１】【図２】【図６】【図７】【図９】【図１０】【図１１】【図１４】【図１５】

───────────────────────────────────────────────────── 【要約の続き】 するアルゴリズムを用いて、受付けられたすべての契約 が適切に満足されていることを保証する。本発明は、ダ ウンロード遅延時間広告機能をも提供する。

Claims (1)

1. 【特許請求の範囲】 １．コンピュータ・ネットワーク上で広告を行うシステムであって、 複数の広告を収容したサーバと、 そのサーバをコンピュータ・ネットワークに電子的に接続する手段と、 前記ネットワークにエンターされたクエリーに応答して、前記サーバから広告 を選択しおよびレトリーブする手段と を具えたことを特徴とする広告システム。 ２．請求項１記載の広告システムにおいて、前記選択手段は、選択された広告が クエリーに適切であることを保証する手段を有することを特徴とする広告システ ム。 ３．請求項１記載の広告システムにおいて、クエリーに応答して、レトリーブさ れた広告をコンピュータ・ネットワークによりリターンされたコンテント・ペー ジと組合せるミキサー手段をさらに具えたことを特徴とする広告システム。 ４．請求項１記載の広告システムにおいて、前記サーバ上に収容されている広告 が前記選択手段によって選択されたときに制御を行うプライム・スペース・マネ ジャー手段をさらに具え、前記制御は前記広告の各々に関連する各広告主の契約 に基づくものであることを特徴とする広告システム。 ５．請求項１記載の広告システムにおいて、クエリーに応答してダウンロードす べきコンテント・ページをユーザが待っているダウンロード遅延時間期間中にお いてのみレトリーブされた広告をディスプレイするローカル・クライアント手段 をさらに具えたことを特徴とする広告システム。 ６．請求項１記載の広告システムにおいて、クエリーに対するサーチ時間の見積 りを計算する手段と、当該サーチ時間の見積りを含んだページとレトリーブされ た広告とを組合せる手段とをさらに具えたことを特徴とする広告システム。 ７．請求項１記載の広告システムにおいて、クエリーにエンターしたユーザの地 理的位置を決定するための手段と、ユーザの地理的位置に基づいて広告を選択す る手段とをさらに具えたことを特徴とする広告システム。 ８．コンピュータ・ネットワーク上で広告を行う方法であって、 サーバ上に複数の広告を設けるステップと、 そのサーバにコンピュータ・ネットワークと電子的通信を行わせるステップと 、 前記ネットワーク上にエンターしたクエリーに応答して、前記サーバ上の広告 を選択するステップと、 その選択された広告を前記サーバからレトリーブしてユーザへのディスプレイ に供するステップとを具えたことを特徴とする広告方法。 ９．請求項２４記載の広告方法において、クエリーに応答して、レトリーブされ た広告をコンピュータ・ネットワークによりリターンされたコンテント・ページ と組合せるステップをさらに具えたことを特徴とする広告方法。 １０．請求項２４記載の広告方法において、広告の各々に関連する各広告主の契 約に基づいてサーバ上の広告が選択されたときに制御を行うステップをさらに具 えたことを特徴とする広告方法。 １１．請求項２４記載の広告方法において、クエリーに応答してダウンロードす べきコンテント・ページをユーザが待っているダウンロード遅延時間期間中にお いてのみレトリーブされた広告をディスプレイするステップをさらに具えたこと を特徴とする広告方法。