JP2016517592A - リアルタイム入札用インテリジェント・プラットフォーム - Google Patents

Abstract

リアルタイム入札（ＲＴＢ）用インテリジェント・プラットフォームは、追加的な個人情報または専用情報と自身が受け取る各入札との関連付けが可能な入札者を含み、豊富な一式の属性に基づいて広告主がインプレッションを選別することを可能にする。強化された同一入札基準を用いて多くの広告エクスチェンジにわたって入札するのに、この入札者を用いることができる。システムは、解析用のレンダリングを行う仮想ウェブブラウザを備えたクローラを含む。このクローラにより、システムは、ページ上の位置、動画のサイズ、動画の再生方法、及び動画中のコンテンツについての情報を知ることができる。クローラには、ブラウザに固有の挙動を判定可能なブラウザ固有レンダリング・クローラを含めることができる。

Description

リアルタイム入札（Ｒｅａｌ ｔｉｍｅ ｂｉｄｄｉｎｇ：ＲＴＢ）は、インプレッションごとにリアルタイムで、ウェブサイトやオンライン動画に挿入すべきコンテンツに入札する広告主の能力に関する。ウェブページを読み込んだり、映像を開始したりする際には、オンライン入札プロセスをバックグラウンドで行って、どのエンティティがユーザーに広告コンテンツを提供するかを決定することができる。プログラムガイドラインに基づいてプログラムされたコンピュータにより、そのときのスピードで入札オークションが行われる。デジタル広告を買い付けるシステムは「入札者」を利用する。この入札者は、１者以上の広告主の代わりを務めるようにプログラムされたサーバであり、ＲＴＢエクスチェンジからの入札要求に応答する。入札者は、入札要求属性を評価すると共に、広告インプレッションに入札するか否か、広告インプレッションへの入札価格をいくらにするのか、さらには落札された場合にどの広告を当該インプレッションに表示すべきかを決定する責任を負う。

入札者は、特有の技術的条件群の下で動作する。このような条件としては、自身が処理すべき大量の入札トラフィック、及び広告エクスチェンジで通常要求される低遅延などに関するものである。近年、入札者の開発においては、ユーザー及びオーディエンスの追跡やターゲッティング、並びにエクスチェンジ（または、標準化された名称及び値に対する属性のマッピングであって、単純に固定された、静的なマッピング）によって提供された属性を用いて、インプレッションに対して諸々の決定を下すことを可能にする他の方法に焦点を当てており、広告主は、これらの情報に基づき、インプレッションを選別して競争入札を行うことが可能である。

ＲＴＢは、互いに協調して個別に動作するいくつかの異なるコンピュータシステムとユーザーのウェブブラウザまたはメディア装置との連携に基づくものである。図１は、これらのシステムの典型的な連携と共に、これらがどのように協調してユーザーに広告を表示するのかを示す図である。

１．ユーザーのブラウザ、テレビ受信機または他のメディア装置が、パブリッシャーのサーバにウェブページ、映像またはアプリケーションを要求する。

２．パブリッシャーのサーバは、ページまたは他のコンテンツを広告タグと共に返す。この広告タグは、広告エクスチェンジ上で広告インプレッションを販売する目的で、当該広告エクスチェンジによってパブリッシャーに提供されたものである。この広告タグは、広告エクスチェンジに広告を要求して表示するようにユーザーの装置に指示する命令を含む。

３．広告タグは、ユーザーの装置において読み込まれ、かつ／または実行される。広告タグは、装置、ユーザー、ユーザーの場所、並びに広告が出稿される箇所の周囲のコンテンツ及びコンテキスト（例えば、ＵＲＬやページ上の位置）についての情報を収集し、１つ以上の広告を求める要求と共に、収集した情報をエクスチェンジに送る。

４．エクスチェンジは、広告タグから収集した情報の全てを集約し、処理し、ログに記録すると共に、その情報を標準フォーマットにパッケージ化し、さらに、どの入札者に入札を要求すべきかを決定（前置フィルタ）して、選定した入札者に入札要求を送る。

５．入札者は、その要求を評価し、入札するか（入札応答）、要求を無視するか、あるいは入札の辞退をエクスチェンジに知らせるかのいずれかを行う。入札応答では、入札者は通常、１者以上の広告主に代わり、入札要求に含まれる１つ以上の広告について１つ以上の入札を開示する。その入札と共に、入札者には、落札した場合にユーザーの装置で実行される広告タグ（入札ごとに１つ）が含まれている。通常、入札要求への応答には厳しい時間制限（例えば、１００ｍｓ）があり、それによってユーザーに意識させずにオークションを行うことができる。

６．エクスチェンジは、入札者から入札応答を収集し、専用オークションと同様の内部決定アルゴリズムに従って入札要求に含まれる各広告について提供すべき落札広告タグを選択する。落札者によって与えられた広告タグは、エクスチェンジにより、広告サーバへの要求に広告インプレッションの落札価格を含めるように修正される。エクスチェンジは、リアルタイムオークションで決定された広告を用いて、ユーザーの装置で動作している広告タグによってなされた元の要求（この要求は依然として応答を待っている）に応答する。エクスチェンジは、上記応答中にクッキーをその装置に置いて、各インプレッションにわたってユーザーを一意に特定する。

７．ユーザーの装置は、メディア資産の適切な場所に別の広告タグを置き、その広告タグを実行し、それによって各広告サーバに広告を要求する。

８．広告サーバは、入札者にメッセージを送ってもよく、あるいは広告インプレッションについて通信を行ってもよい。この通信には、通常、インプレッションに支払われる金額（この金額は、例えば、セカンドプライス・オークション方式の選択機構を用いて落札を決定した場合のように、入札価格と異なる場合がある）と共に、その落札に関する入札要求識別子が含まれる。次いで、入札者は、少なくとも落札価格をログに記録し、広告インプレッションの金額を見込んで自身の実行予算を調整する。

あるいは、ステップ８．１に示すように、ユーザーの装置は、この情報を入札者に直接返信（エクスチェンジから戻った広告タグによって決定されるように）してもよい。上記のように返信することは、広告サーバを経由して入札者に上記情報を返すよりも好ましい場合がある。

９．広告サーバは、広告及びユーザーの装置で用いられる関連情報を返して、広告を表示させる。広告サーバは、スクリプトまたは別の広告タグを返して、広告に伴うユーザーの体験（特に、ユーザーの装置を介した、ユーザーと広告及びパブリッシャーのウェブページとの対話）を制御するようにしてもよい。

広告サーバが返したコンテンツにより、トラッキングピクセルまたは同様の手段を利用してユーザーの装置から広告サーバにメッセージを返送させて、ユーザーと広告の対話について広告サーバにアラートしてもよい（ステップ９．１を参照）。例えば、ユーザーが広告をクリックした場合、あるいは映像広告においてユーザーがその広告の全体または一部を視聴した場合などである。

１０．通常、ユーザーが広告をクリックした場合、ユーザーの装置は、パブリッシャーのウェブページから離れ、広告サーバによって提供された（及び広告主によって指定された）ＵＲＬに移動するように誘導される。このページは、広告用「ランディングページ」と呼ばれており、トラッキングピクセルまたは広告タグを含むことにより、ユーザーとランディングページの対話についてのメッセージ（すなわち、ランディングページに購入品が完備されているかどうか、ランディングページが適切に読み込まれたかどうか、ユーザーがランディングページから広告主のサイト上の別のページに誘導されたかどうかなど）を広告サーバに返信してもよい。これらのメッセージは、トラッキングピクセルまたは広告タグを経由し、ランディングページによって起動される広告サーバに送られる。

１１．広告サーバは、例えば、ユーザーが広告をクリックして広告主のランディングページに誘導されたときに、ユーザーと広告の対話をサーバに知らせる別の通知及びアラートをユーザーの装置から受け取る。なお、広告サーバまたは装置は、リアルタイムで、あるいはオフライン同期処理の一部として、この情報を入札者に渡してもよい。

図２を参照すると、典型的な入札システム、すなわち入札者は、以下のものを備える。
・入札者エンドポイントサーバ：通常はＨＴＴＰであり、ＨＴＴＰのプロキシ規則に従って入札要求及び上流入札サーバへの応答のプロキシを行う、多数のマシンにわたって負荷分散されたリバース・プロキシ・サーバ。

・ＲＴＢターゲッティング・データベース：広告タグ、及び広告主によって定義され、入札すべき広告インプレッションを特定するためのフィルタを含むと共に、それぞれのフィルタにつき最大入札の調整及び比較入札の調整などの入札命令を含むデータベース。

・上流入札サーバ：入札者エンドポイントサーバから入札要求を受け取り、入札要求の属性に対して広告ターゲッティング・データベース内の１つ以上のフィルタを評価するカスタムサーバ、修正サーバ及び／または専用サーバ（通常はＨＴＴＰ）。各フィルタは、当該フィルタにマッチングした入札要求に対して所与の時間でどの広告タグを送出すべきかを順次判断し、あるいは決定するためのビジネスルールと共に、１つ以上の広告タグと関連付けられている。

・広告サーバ：各広告タグは、ユーザーの装置上で実行されると、広告としてレンダリングされる創作資産を実際に返す広告サーバ（通常はＨＴＴＰエンドポイント）に要求を出す。広告タグは、ユーザーの装置上で任意の計算を行って、装置、ユーザー、ユーザーの場所、メディアをレンダリングするアプリケーションなどについての種々の情報を求めてもよい。この情報を広告サーバに渡し、最も適切な広告／創作フォーマットを選択的に提供するのに用いることができる。広告サーバは、ユーザーが広告をクリックしたとき、広告が表示されたとき、あるいは映像広告の場合に、ユーザーがその映像広告の様々な部分を観ているとき、あるいはリッチメディア広告及びディスプレイ広告の場合には、広告が実際に画面上にレンダリングされ、または視野に入ったとき、あるいはユーザーが広告と対話したときなどに、ユーザーの装置から様々な情報の通知を受けてもよい。

・広告ターゲッティング・コンソール及び報告コンソール：広告主またはその代理店及び関連会社が、データベース内のフィルタ、広告タグ関連フィルタを作成または編集すると共に、予算及び入札パラメータを設定または調整することができるウェブページまたはアプリケーション。報告／ロギング・データベース：上流入札サーバ及び広告サーバからのログを記録して、特定インプレッション（または一式のインプレッション）用のデータを、ＲＴＢターゲッティング・データベースから辿って具体的な広告主／フィルタにリンクさせるデータベース。

・メンテナンス／報告サーバ：定期的（通常は１時間に１回、１日に１回など）に広告サーバ及び上流入札サーバからログファイルを収集して処理し、データを報告データベースにダンプする。これらのサーバは、広告ターゲッティング・コンソールを介して独自の報告または定期的な報告を求める広告主からの要求に応答してもよい。

インテリジェント入札プラットフォームは、相対トラフィックレート、典型的に利用可能な広告フォーマット並びに種々のウェブページ、ＵＲＬまたはメディア資産に表示される広告のコンテンツ、コンテキスト及び全体外観についての情報に関する統計結果を維持するのみならず、第三者（広告エクスチェンジによって所有されていない／広告エクスチェンジによって運用されていない）のインベントリ用のインデックスを構築及び維持するのに利用することができる。このインデックスは、ウェブページ、アプリケーション、及び広告主に適合した方法でエクスチェンジに広告を出すのに利用可能な動画を分類する。

かかるシステムを用いて、広告主は、独自のコンテンツ・トピック及びメディア資産に合わせた広告キャンペーンをターゲットとすることができる。ある動画が独自に定義されたトピックに関するものである場合、入札を行うことができ、その動画を背景にして流れるように広告主の広告が出稿されることになる。例えば、「オイル交換の仕方」という動画を見ている人は、タイヤ店向けの動画広告を得る可能性があり、またはおそらく、その動画内でオイル・ブランド向けのバナー広告を得る可能性がある。従来の入札システムでは、広告は、専らウェブページのドメイン、またはエクスチェンジもしくはパブリッシャーによって作成された一般的なトピックを分類したもの（例えば、前述のオイル交換の例では「自動車（Ａｕｔｏｍｏｔｉｖｅ）」）に基づき、あるいは、ブラウザのクッキーによって判定されるような、ユーザーが以前に訪問したメディア資産を元に、エクスチェンジ上の特定リストに属するユーザーについての観測挙動に基づいて広告が出稿される。

リアルタイム入札用インテリジェント・プラットフォームは、高度に分散され、拡張性のある耐障害性入札者を含む。この入札者は、多数の広告エクスチェンジからの入札要求トラフィックを処理することが可能であり、広告エクスチェンジの各取引場所にわたって容易に配置することが可能であり、広告主が任意の第三者データを上記入札者の入札決定プロセスに組み込むことによって拡張することもできる。さらに、このプラットフォームは、クラウド・コンピューティング・サービスによって提供される仮想ハードウェアを用いて完全に配置可能である。このようなクラウド・コンピューティング・サービスとしては、アマゾン・ウェブ・サービス（Ａｍａｚｏｎ Ｗｅｂ Ｓｅｒｖｉｃｅｓ）（登録商標）またはグーグル・クラウド・コンピューティング（Ｇｏｏｇｌｅ Ｃｌｏｕｄ Ｃｏｍｐｕｔｉｎｇ）（Ｇｏｏｇｌｅは登録商標）などがある。

この入札プラットフォームの構成及び設計は、従来のシステムよりも容易である。さらに、本プラットフォームは、入札者エンドポイントサーバにステップを追加するアルゴリズムを利用することによって上記設計を活用する。この場合、広告エクスチェンジによって与えられる入札要求を構文解析し、強化し、別個のフォーマットに書き換える。これにより、広告主によるフィルタ・マッチングに諸々の属性を利用することが可能となる。このとき、その属性には、広告主または他の第三者のデータソースによって定義された別の属性、並びに構成可能なマッピング及び広告主定義のタグ付けルールを経た広告エクスチェンジ供給の標準属性などが含まれる。このシステムは、メンテナンスサーバ及びスタンドアロンの広告サーバを不要とすることができる。さらに、このシステムは、報告データベース及び広告ターゲティング・データベースを同一の「仮想」データベースに統合することが可能であり、コンソールにリアルタイムで報告することができる。これにより本システムは、入札者に第三者データがリアルタイムで見えるようにすることができる。上流入札サーバは、効率的なハッシュベースのデータベース・クエリに入札要求を直接変換することによって排除することができる。エンドポイント・プロキシサーバから上流入札サーバへの呼び出しは、単一データベースの探索によって置き換えることができる。

属性及び値のリストは大規模になり得るが、このリストはコンテンツ認識（ｃｏｎｔｅｎｔ−ａｗａｒｅ）型ハッシュに基づいて格納及びインデックス化することが可能であり、広告エクスチェンジ入札者の低遅延で高トラフィックな環境の全てにおいてほぼ一定時間に、任意の入札要求属性を、属性／値のペア及び組み合わせからなるほぼ無制限のリストと照合することができる。

本明細書のシステムは、第三者コンテンツのインデックス化システムを駆動するためにインテリジェント入札プラットフォームを利用することもできる。かかるシステムは、入札者が受け取った入札要求で開示されたＵＲＬ及び部分ＵＲＬを監視することにより、広告インベントリを予測するためにエクスチェンジによって提供された情報に依存するのではなく、エクスチェンジに広告を出すのに利用可能なコンテンツのインデックスを経験的に維持する。

このようなシステムを用いることにより、エクスチェンジにおける第三者の入札者（すなわち、エクスチェンジ自体ではないが、この入札者は、入札要求で提供された情報を修正及び認可することができる）は、自身専用の、経験的に決定され、コストに優れた、広告インベントリで取引されるエクスチェンジのインデックス及びターゲティング方針を構築し、内部に保持することができる。さらに、本システムは、ターゲティング方針の重要な要素を広告エクスチェンジに明示的に開示せずにこれを行うことが可能である。第三者コンテンツのインデックス化システムは、自動化されたウェブ・クローリング・システムであって、エクスチェンジを監視することにより、エクスチェンジ上で取引されるＵＲＬのコンテンツを監視することが可能なウェブ・クローリング・システムを用いてインテリジェント入札プラットフォームを拡張し、独自の属性をＵＲＬまたは部分ＵＲＬに添付させた独自のコンテンツ分類ルールを開発・設計することができる。

このクローリング・システムは、オフラインで運用することができる（すなわち、クローラは入札者から独立して動作する）ものの、入札者から直接クエリを受ける「インデックス」と呼ばれる、共用リアルタイムの取引データベース・システムを経由したプラットフォームを介して入札者と一体化しており、本システムの上流広告サーバを置き換える。

これらのクローラは、オンライン・コンテンツ（動画など）を解析するために、あたかもコンテンツがユーザーに再生されているかのように画面またはメモリのいずれかにレンダリングしてコンテンツについての追加情報を取得するウェブブラウザを解析目的用に備えることができる。動画の場合、このレンダリング能力により、ページ上の位置、動画サイズ、動画の再生方法及び動画中のコンテンツについての情報を知ることができる。これらのクローラには、ブラウザに固有の挙動を判定可能なブラウザ固有レンダリング・クローラを含めることができる。このクローラは、互換性を知ることのみならず、デスクトップブラウザと比較してモバイル端末に動画がどのように現れるかを知るのに有用である。

顧客は、この追加情報を利用することにより、より良好な情報を得た上で、自身の広告機会について決断を下すことができる。かかる情報をコンテンツ供給者に提供する場合、供給者はこの情報を用いて、コンテンツの価格設定をより適切に行うことができる。

他の機能及び利点については、以下の説明、図面及び特許請求の範囲から明らかになるであろう。

従来のＲＴＢ入札プロセスのフロー図である。 典型的な既知の入札システムのブロック図である。 本明細書に記載された実施形態にかかるシステムを説明するブロック図である。 本明細書に記載された実施形態にかかるシステムを説明するブロック図である。 ディレクトリ・サーバ及びこのサーバへの接続を示すブロック図である。

本発明者らは、既知の入札者（上述したものなど）が従来のウェブサーバから外れた動作条件の下で動作するのを観察した。入札者と典型的なウェブサーバの動作条件の相違点を以下に記載する。

・処理すべき入札要求の数が非常に多い。今のところ、広告エクスチェンジの数は制限されているが、ある概算によれば、入札者は、インターネット全体のディスプレイ広告及び映像広告の８０％までを処理する。仮に入札者が、全ての可能なエクスチェンジから全ての可能な要求を受け取ったとした場合（今のところ、ほんの少数の広告エクスチェンジしかないことを考慮すると、この需要は考えられる）、インターネット全体に提供され、広告を表示する全てのウェブページの８０％について入札者に要求が出されることになる。エクスチェンジを用いて構成された基本的な前置フィルタがある場合でも、ＧｏｏｇｌｅのＡｄｘは、取引場所（世界中に６箇所の取引場所があるとする）ごとに毎秒５００，０００超の入札要求を入札者に出すことができる。

・大多数の入札要求は入札に貢献するとは限らないため、通常の入札者への要求はほとんど無視され、あるいは破棄される。プロキシサーバ上で、テキストまたは他の中間形式としてこれらの要求をログに記録することにより、大量のデータが生成される。これらのデータは、次いでメンテナンスサーバで処理されて有用なものとなる。このようにログ収集を行うと、運用中に収拾がつかなくなる恐れがあるため、マッチングしなかった入札要求は、破棄され、あるいは不完全なインデックス化がなされることが多い。

・通常、要求に応答するためのドロップ・デッド・タイム（ｄｒｏｐ−ｄｅａｄ ｔｉｍｅ）の制限（例えば、１００ｍｓ）が厳しく課せられている。なお、この時間には、要求と応答の往復移動時間が含まれている。通常、この制限によって上流入札サーバに十分な時間が確保される。これにより、上流入札サーバは、エクスチェンジによって提供された要求内の属性と突き合わせてフィルタを確認し、広告ターゲッティング・データベースに格納されたインデックス付きの値の明示リスト（大規模になり得る）と突き合わせて一定の属性（ユーザーＩＤ、部分ＵＲＬ、都市、郵便番号など）を確認する。典型的なリレーショナル・データベースに多数のクエリまたは複合的なクエリが発行されると（特に、連続的に発行される場合）、個々の入札要求に必要となる時間がかかりすぎる可能性があるため、データベース構造の作成、インデックス化手法及びデータベース検索手法は、どの入札者にとっても非常に重要な側面をなす。

これらの動作条件に加え、上述したような入札者の典型的な構成により、現在市販されている入札システムには諸々の制限が存在する。例えば、フィルタを構築するために広告主が利用可能な選択項目は、既定の構成ブロック（これらのブロックは、入札要求で利用可能な情報に基づくものであり、広告エクスチェンジよって与えられる）、及び上流入札者が入札要求を評価する時点で入札者にとって直接見ることができ、あるいは容易に利用可能な他の属性（時刻、広告主の利用可能な予算など）に制限される。現在市販されている入札者は、通常、エクスチェンジから与えられたユーザーＩＤによって特定された個々のユーザーを選択的に収集してターゲティングすることができる。これらの入札者は、広告ターゲティング・データベースに格納されたユーザーの定義済みリストを用いて、一意のエクスチェンジ・ユーザーＩＤを広告主に対応付けることができる。これは、クッキーマッチング（ｃｏｏｋｉｅ ｍａｔｃｈｉｎｇ）と呼ばれる処理を経て実現されるものであり、広告エクスチェンジ（クッキーマッチングのホスト）によるサービスとして提供されることが多い。

現在市販されている入札者は、ＵＲＬ及び／または部分ＵＲＬ（ドメイン名など）の大規模リストを選択的に対象または除外とすることができる。これらの入札者は、入札要求で自身に与えられたＵＲＬまたは部分ＵＲＬを、広告データベースに格納されたＵＲＬまたは部分ＵＲＬのリスト（大規模になり得る）と照合することができる。市販されているほとんどの入札者は、ドメイン名（単独のＵＲＬではない）を選択的に対象または除外とすることのみが可能であり、選択的に対象または除外とするリストのサイズが制限された（例えば、２０，０００程度）入札者もある。

現在市販されている入札者は、地理位置（都市、郵便番号、選挙区、州、群、国など）の大規模リストを選択的に対象または除外とすることができる。これらの入札者は、広告エクスチェンジによって与えられた地理位置を、広告主によって与えられた地理位置のリスト（大規模になり得る）と照合することができる。

クッキーマッチング、ＵＲＬのホワイトリスト化及びブラックリスト化並びにジオ・ターゲティングを経て特定された具体的なユーザーに対するリストマッチングの他に、今日の入札者は、独自の入札要求評価または分類ルールを入札意思決定プロセスに組み込むことができない。上述した典型的な入札者の構成では、少数の固有ＩＤを探索処理することが可能である。かかる構成により、ユーザーＩＤ、地理位置及びリストＩＤへのＵＲＬで構成されるテーブルを事前に算出することによって広告ターゲティング・データベースに格納されたリストと一意の値とのマッチングを行い、次いで、広告主は、これらのリストＩＤを様々な形式で自身のフィルタに取り込むことができる。

既存の入札者は、専ら広告エクスチェンジによって提供された属性に基づき、各広告インプレッションをターゲットとすることができる。広告主は、入札要求内の各属性について許容値のリストを明示的に提供することにより、インプレッションをターゲットとするためのフィルタを当該エクスチェンジ上に作成することができる。リスト化された属性を除き、ある属性に対して取り得る全ての値がフィルタを通過すべきことを入札者に示す「否定的なターゲティング・リスト」として、この許容値のリストを記すこともできる。特定の属性に基づいてインプレッションを選別することを広告主が望まない場合、広告主は、入札要求を選別する際、入札者に無視させる属性については許容値のリストを提供しない（従って、当該属性について取り得る全ての値はフィルタを通過することができる）。例えば、広告エクスチェンジは、通常、ユーザーＩＤ属性、ユーザー位置属性及びＵＲＬ属性を、入札者に送る入札要求ごとに提供する。今日の入札者では、対象もしくは除外とするＵＲＬもしくは部分ＵＲＬの明示リスト、対象もしくは除外とするユーザーＩＤの明示リスト、または対象もしくは除外とするユーザー位置の明示リストを広告主が指定することができる。

ユーザーをターゲティングする際、「クッキーマッチング」と呼ばれる技法を用いることにより、ユーザーＩＤのリストを構築することが可能となり、広告主は、広告主ウェブサイトのトラフィックに基づいた自動的な方法で、当該リストを入札システム内に保持することができる。入札者（または入札者を運用する企業）は、頻繁に使用されるＵＲＬ、ユーザーＩＤ、ユーザー位置、または広告主が自身の属性を与えることなく利用するための他の広告主向けリストを保持することにより、広告主が共通のターゲティング対象をより得やすくすることができる。例えば、いわゆるＵＲＬのブラックリスト（ポルノグラフィーまたは他の不快なコンテンツを含むことが疑われる全てのＵＲＬまたは部分ＵＲＬで構成される）は、入札者が保持してよい。広告主は、上記のように入札者によって与えられたブラックリストを用いて、一般に悪質と考えられるＵＲＬ上での動作を避けるようにしてよい。

図４を参照すると、リアルタイム入札用インテリジェント・プラットフォームは、ＲＴＢオークションに用いられる典型的な入札者（図１の「入札者」を参照）を置き換えている。このプラットフォームは、リアルタイム・データ・インデックス（Ｒｅａｌｔｉｍｅ Ｄａｔａ Ｉｎｄｅｘ：ＲＤＩ）を備える。このインデックスは複数台のサーバで構成されるクラスタであり、ＬＤＡＰまたは同様のディレクトリ・サーバを実行している。このインデックスは、クエリ、データ、信号及び構成情報を、当該プラットフォームの内部または外部、あるいはその双方にある種々の異なるデータベースに送受する交換機として機能する。

本システムは、エクスチェンジの入札者及びロガー（Ｅｘｃｈａｎｇｅ Ｂｉｄｄｅｒ ａｎｄ Ｌｏｇｇｅｒ：ＥＢＬ）を含む。このＥＢＬは、リアルタイム・データ・インデックスを用いて、入札要求についての決定をリアルタイムで行い、かつ／または入札者の挙動を制御するのに利用可能な種々のデータベースに入札者をアクセスさせる。ＥＢＬは、ＲＤＩを用いて、多数の分散データベースにわたって入札者サーバから直接データをバッファしてダンプする。この処理は、典型的な入札者が様々なマシンからテキストログを集め、報告または性能データを処理し、再フォーマットし、格納するために上記と同様の処理を行う際に必須となるメンテナンスサーバを用いずに行われる。追加的な個人情報または専用情報と入札者が受け取る各入札とを関連させるＲＤＩにアクセスすることにより、広告エクスチェンジ（またはエクスチェンジ）からの属性に基づいて広告主がインプレッションを選別することが可能となり、多数のエクスチェンジにわたって欠落している一定の属性または変則的な一定の属性を算出し、標準化する。その結果、同一入札者を利用して、多数の広告エクスチェンジにわたり、強化済みの同一入札基準を用いて入札することができる。

図５は、ローカル・キャッシュ・データベース及びローカル構成データベース、分散クラスタ・データベース、第三者と共同設置のデータベース、並びに分散クラスタ・キャッシュ・データベースと連携可能なディレクトリ・サーバを示す図である。この図は、システム内のローカル及びリモートの第三者データベースにクエリを送る際の柔軟性を示している。このシステムは、入札に要する時間（例えば、１００ｍｓ以下）内にアクセスすることが可能である。

本明細書に記載されたシステム及び方法は、入札容量を拡張して、（１）データベースに格納された推論ルール、（２）入札者システムまたは第三者システムもしくは遠隔システム内のデータベースに格納された述語及びデータ、及び（３）エクスチェンジによって与えられ、推論ルールを初めて評価する入札要求の属性に基づき、入札要求の別の属性を推論する（またはエクスチェンジによって与えられた属性を修正する）。広告主は、自身の独自フィルタを構築するために、ＵＲＬ、ユーザーＩＤまたはユーザー位置のリスト（大規模になって管理不能となり得る）を明示的に作成または保持する必要がない。また、広告主が推論ルールを編集／指定／変更して、対象とする挙動をカスタマイズできるようにすることにより、入札者は、より柔軟なターゲティングを広告主に提供することができる。

本明細書に記載された本システム及び方法では、データ・プラットフォームは、リアルタイム入札（ＲＴＢ）用の高容量入札サーバ及びプログラマティック広告バイイングを備える。本システムは、オンライン動画向けにコンテンツ・ベースのターゲティングを行うことに焦点を当てており、多数のエクスチェンジにわたり、リアルタイムでＵＲＬレベルの入札及びターゲティングを処理することが可能である。本システムは、エクスチェンジによって取引されるウェブページ及び動画のコンテンツをクロールし、分類し、インデックス化することができる。また、本システムは、利用可能であり、かつ適切に構成されたものであれば、外部及び第三者のＡＰＩ及びデータソースを組み込むことができる。本システムは、仮想ハードウェア上で動作する分散クラスタ構成として実装することが可能であり、ターンキー方式でグローバル展開を図ると共に、必要に応じて容量を活用し、クラウド・ベースのデータストレージを用いて同期することができるように企画及び設計されており、分散コンピューティング及び分散データ構造を利用して、データベースをペタバイトレベルに拡大することができる。

図３を参照すると、本システムの別の表現が３つの主要モジュールに示されている。すなわち、消火ホース利用の入札者及びロガー（ｆｉｒｅ ｈｏｓｅ ｂｉｄｄｅｒ ａｎｄ ｌｏｇｇｅｒ：ＦＢＬ）、インデックス及びレンダリング・クローラ（ｒｅｎｄｅｒｉｎｇ ｃｒａｗｌｅｒ：ＲＣ）である。本システムは、インベントリ・ソースと連携するが、このインベントリは、広告に利用可能なコンテンツのインベントリを有するエンティティである。顧客には、広告コンテンツを提供しようとする種々のエンティティ、広告エクスチェンジを用いた入札技法を自身に代わって運用する種々のエンティティ、及び種々の類似した本システム向けの商業用途を有する関連エンティティが含まれる。

インデックスは、可用性が高く、遅延が低く、分散された、クラスタ・ベースのディレクトリ・サーバ及びデータベース並びにＡＰＩである。このインデックスは、外部のデータソースに対してリアルタイムの「交換機」として機能するのみならず、マシンごとにテラバイトのデータを処理し、ソートし、格納することが可能であり、入札者によるリアルタイム・アクセスに対して、任意のデータを不明瞭な方法でキャッシュ／インデックス化することができる。インデックスは、オンライン・コンテンツについてのメタデータと共に、ウェブページ、動画及び他のオンライン・コンテンツについての情報を格納することができる。インデックスは、（ａ）入札者／ロガーによって収集されたＵＲＬ／動画のトラフィックデータ、及び（ｂ）レンダリング・クローラ（ＲＣ）によって収集されたクロールデータを格納することができる。収集可能な情報としては、ユニフォーム・リソース・ロケータ（ｕｎｉｆｏｒｍ ｒｅｓｏｕｒｃｅ ｌｏｃａｔｏｒ：ＵＲＬ）、チャンネル・レベル及びドメイン・インベントリ・レベル、動画プレーヤの位置、動画プレーヤのサイズ、動画及び／または動画広告を視聴するために必要とされるユーザーの関与、動画の題名及び抽出情報、利用可能な（動画及びページ内で）広告位置の数、動画の長さ、ページテキスト、並びに他のコンテキスト構成要素が挙げられる。本システムは、どのような動画情報を収集するか、及びどのくらいの頻度でページをクロールするかを優先付けるアルゴリズムを保持することができる。

消火ホース利用の入札者及びロガーは、インデックスの上部にある高スループットの入札者及び広告サーバであり、クラスタ内のマシンごとに数万の同時接続を処理することができる。ＦＢＬは、基本的なエクスチェンジ入札機能及び広告提供機能を実装しており、インデックス（第三者の入札者による製品用途に適したもの）へのリアルタイム・アクセスを提供し、エクスチェンジのログと共にインデックスへの広告トラフィックのログをリアルタイムで記録して、報告及び監視をきめ細かく行う。ＦＢＬは、利用可能な動画（または広告を挿入可能な他のコンテンツ）のインベントリをＵＲＬによって監視し、関連動画を広告する機会を特定するための中心的な導管として機能する。ＦＢＬは供給元に依存しない。ＦＢＬは、広告エクスチェンジ、ＤＳＰ供給者、パブリッシャー及び他の供給元と接続している。

レンダリング・クローラは、オフラインデータを収集し、インデックスの上部に構築されたシステムをスクレイピングする。レンダリング・クローラは、特定のＵＲＬを訪問するウェブスパイダーとして機能し、ページ及び自動起動するオブジェクト（フラッシュ及び他のアイテム）についての情報を収集して、追加情報を収集する。ユーザーが実際に動画と対話する仕方と同様に、ページ及び動画を「レンダリング」することができる。ＲＣは、ページ上のＵＲＬまたは動画に関する有用な第三者データをフェッチして統合することも可能であり、ＵＲＬをキーにした単一レコードに情報を集結する。この処理は、例えば、モジラ（Ｍｏｚｉｌｌａ）ブラウザなどのブラウザに導入されたプラグインを用いて行うことができる。このレンダリングにより、「ブラックボックス」のプレース・ホルダ（ウェブサイト内に動画を表示する場所）からは明らかでない情報をシステムに収集させることができる。例えば、動画の実サイズは、上記ボックスのサイズとは異なる場合がある。また、動画の開始方法（自動再生またはクリックして開始）は、単にボックスからは明らかでない場合がある。さらに、レンダリングは、広告主が望ましいまたは望ましくないと思うコンテンツを特定するのに用いることができる。

より具体的には、階層構造をとった複数のクローラとして上記クローラを機能させることができる。これらのクローラは、種々の能力を備えるが、連携できるように共通データベース、インデックス及びジョブ・キューを共有している。機能及びオーバーヘッド（コスト）を少なくして、種々のクローラを高速化することが可能であり、あるいは低速化し得るものの、より多くの費用をかけてより多くの機能を統合することもできる。

プレーンテキスト・クローラは、低機能で最も高速である。このクローラは、任意のＵＲＬのコンテンツを抜き出し、そのデータのフォーマット（ＨＴＭＬ、ＪＳＯＮ、テキストなど）を特定し、当該コンテンツを構文解析し、当該コンテンツについてのデータをインデックス内に格納する。このクローラにはコンテンツ・ハンドラが登録されており、ＵＲＬ及びコンテンツの種類に基づいてマッチングを行う。クローラがＵＲＬを訪問すると、クローラは、構文解析されて読み込まれたコンテンツを任意のコンテンツ・ハンドラに渡す。このコンテンツ・ハンドラにより、ＵＲＬ／データフォーマットのマッチング（すなわち、［／／ｙｏｕｔｕｂｅ．ｃｏｍ／ｗａｔｃｈ＊］から任意のＨＴＭＬ）が行われるため、システムは、独自の構文解析／データ抽出を行うことができる。このクローラは、特に、静的なコンテンツ、ＡＰＩ、供給者などに対して、必要とされる作業に良好な速度を提供し、優れた価値を発揮する。このクローラは、ＵＲＬが存在するかどうかの確認、リンクのマイニング、ページからのテキストの抜き出し、及びページが変化したかどうかの確認においても十分に機能する。

ＨＴＭＬページ向けにＪａｖａスクリプト・クローラ（Ｊａｖａは登録商標）が提供される。このクローラは、ウェブブラウザに導入したプラグインを用いて、解析目的用の仮想ウェブブラウザ内のページを構文解析して読み込むことができる。このウェブブラウザを用いて、上記クローラは、全ての画像、画素及びスクリプトファイルをダウンロードし、そのページからＪａｖａスクリプトを実行して、当該ページの完全なＤＯＭオブジェクトを作成することができる。このクローラには、より多くの費用がかかる。なぜなら、このクローラは、ページのインデックス化が可能になる前に、ページごとにより多くの情報をダウンロードし、コンテンツの全てが読み込まれるのを待機する必要があるためである。このクローラは、仮想ブラウザを用いるため、実際にはページをレンダリングせずにスクリーンショット、フラッシュ・コンテンツを取得し、あるいは種々のＨＴＭＬ構成要素が現れるページ上の箇所（スクロールせずに閲覧可能な領域（ａｂｏｖｅ ｔｈｅ ｆｏｌｄ）またはスクロールしなければ閲覧できない領域（ｂｅｌｏｗ ｔｈｅ ｆｏｌｄ））について正確な数を取得する。

「ヘッドレス・レンダリング（ｈｅａｄｌｅｓｓ ｒｅｎｄｅｒｉｎｇ）」クローラは、スクリーンショット、フラッシュ・コンテンツ及びページ上の構成要素の確実な位置を取得するのに用いる。このクローラは、ページを画面ではなくメモリにレンダリングするため、より完全な機能を備えた仮想ブラウザを使用し、これを「ヘッドレス」ブラウザとして参照する。ヘッドレス・レンダリング・クローラを用いると、ページが完全に読み込まれ、メモリへのレンダリングが完全に行われるため、全てのレイアウト及びプラグインのコンテンツが機能する。さらに、このクローラは実際に動作しているブラウザを使用するため、コンテンツを読み込んで当該ページをテストしている間でも、例えば、スクリプトを介してそのページとやり取りすることができる。

ブラウザ固有レンダリング・クローラは、ブラウザに固有のコンテンツまたはページの挙動を判定することができる。例えば、ユーザーがデスクトップブラウザに対してモバイルブラウザにページを読み込ませた場合、そのコンテンツは両ブラウザ間で異なる可能性がある。また、ウェブページを読み込んでも、あるブラウザではエラーが発生し、別のブラウザではエラーが発生しない場合があることから、広告タグ及びターゲティングにより、ブラウザに基づいたこれらの挙動を変化させることができる。モバイルページをクロールするために、ブラウザに特有の挙動についてウェブページをテストするために、あるいはブラウザに特有のスクリーンショットを取得するために、このクローラを用いることが好ましい。このクローラは、仮想画面を作成することによって動作する。

上記の各クローラは、パイプラインで使用可能である。プレーンテキスト・クローラは、最初にＵＲＬを取り込み、一部の基本的なインデックス化を行い、必要に応じてそのコンテンツをＪａｖａスクリプト・クローラに送出する。ＵＲＬにエラーがある場合、そのＵＲＬはログに記録されて破棄される。次いで、Ｊａｖａスクリプト・クローラは、完全に読み込まれたページからコンテンツを提供する。スクリーンショットが必要な場合は、あるいはフラッシュまたは他の動画コンテンツがページ上にある場合には、ヘッドレス・レンダリング・クローラにそのコンテンツが渡される。モバイルコンテンツをスキャンし、または広告タグをテストする必要がある場合、ブラウザ固有クローラを別個に用いる。

クローラからのデータは、インデックスに戻して提供される。このインデックスでは、タグへのページの割り当てがロジックによって検討される。例えば、ユーチューブ（ＹｏｕＴｕｂｅ）（登録商標）の場合、本システムは、クロールデータから公式の分類を直接スクレイピングする。他のコンテンツの場合、この分類はキーワードに基づいており、本システムは、フリーベース（Ｆｒｅｅｂａｓｅ）（登録商標）のトピックＩＤに全ての分類／タグを対応付ける。

クローラによってＵＲＬ及び部分ＵＲＬに割り当てられたタグ及び属性は、入札要求を強化することにより、ターゲティングの際に入札者（及びフィルタを構築する広告主）にとって利用可能となる。この強化された入札要求では、ＵＲＬまたは部分ＵＲＬを、ＵＲＬまたは部分ＵＲＬに属性を割り当てるためにクローラが用いた分類ルールによって特定された別の属性とマッチングする。例えば、広告主が主にピンク色の広告を持っており、同様に主にピンク色のページにその広告を表示させることを望んでいるとする。広告主は、主にピンク色のウェブページにマッチングさせるクローラ・ルールを作成するであろう。このクローラ・ルールは、Ｊａｖａスクリプトによって実装することが可能であり、ヘッドレス・レンダリング・クローラを用いて、タグ「主にピンク色（ＭｏｓｔｌｙＰｉｎｋ）」を、当該ルールがマッチングする任意のＵＲＬ上の属性「ＵＲＬＣｏｌｏｒ」に割り当てる。

入札者が、このルールにマッチングしているとしてクローラが特定したＵＲＬを有する入札要求を強化すると、その入札要求は、ＭｏｓｔｌｙＰｉｎｋに設定されたＵＲＬＣｏｌｏｒ属性を有するようになる。ＭｏｓｔｌｙＰｉｎｋにマッチングしたＵＲＬＣｏｌｏｒ属性を要求するフィルタを広告主が構築した場合、入札者は、クローラによって訪問され、広告主自身のルールに従ってピンク色であると判定された入札要求にのみ入札する。

今日の入札システムは、独自データの管理及びターゲティングを上記レベルで行う能力を持たず、さらに、新たに定義されたデータソースを直接入札システムに途切れなく組み込む能力も、上記のようなＲＴＢ向けの第三者データを利用できる能力もない。

本システムは、上記のように３つの構成要素を含むことが可能であり、アクション可能な動画広告及びモバイル広告の買い付けに用いる自然入札データベースを作成するように設計されている。この機能に加えて、特にブラウザ・プラグインを利用することにより、画面にレンダリングしようとメモリにレンダリングしようと、多くの場合に行われる処置を凌ぐことができる。例えば、広告を提供しようとしている一部の顧客は、動画が再生されるブラックボックスのサイズについての情報に制限を受ける場合がある。上述したように、動画をレンダリングすることにより、動画を自動的に再生するかどうかにかかわらず、さらには動画内のコンテンツにもよらず、顧客は、実際の動画がどの程度の大きさかを知ることができる（ボックスのサイズではなく）。この能力により、顧客はより多くの情報を得た上で決定を下すことができる。

動画及び他のコンテンツのメタデータで構成されたデータベースを構築するために、上記のクローリング及びレンダリングは前もって行うことが可能であるが、インプレッションの機会が顧客に提供される際にリアルタイムで情報を引き出すこともできる。

典型的なワークフローは、以下のようにして進めることができる。ＵＲＬクエリ、インプレッション・ビーコンまたはＲＴＢのトラフィックにより、インベントリ・ソースからＦＢに要求が送出される。この要求がＲＴＢの要求である場合、かつ、動画がクローラによって以前に解析されていた場合、そのメタデータがインデックスから検索され、顧客によって確立された基準に基づいて適切な入札が返される。このインプレッションは、要求で送出された別のデータ項目と共に、インデックス内のログに記録される。

ＵＲＬが新規である場合、または以前のレコードが期限切れである場合、そのＵＲＬがＲＣに送出され、さらに、修正済みのウェブブラウザがそのページに送られてコンテンツ情報が抽出される。第三者のＡＰＩは、ＵＲＬについての追加情報のクエリを受ける。クライアントのＵＲＬまたは動画はタグ付けルールを実行させて、その結果に基づいてレコードが更新される。インデックスデータは、ホワイトリスト化及び優先買い付けのためにタグ付けされる。

顧客と連携する代理店、取引デスク及び他の顧客側ユーザーの場合、本システムにより、彼らが顧客のニーズ（動画レベルのカテゴリー化、コンテンツ属性、及び状況的関連性を含む）にマッチングする動画チャンネルを作成することを可能にし、さらに彼らが、ページ内のコンテンツ（動画など）プレーヤの位置（例えば、ユーザーが動画にたどり着くのにスクロールする必要があるかどうかを示す、アバブ・ザ・フォールド（ａｂｏｖｅ ｔｈｅ ｆｏｌｄ）またはビロウ・ザ・フォールド（ｂｅｌｏｗ ｔｈｅ ｆｏｌｄ））、プレーヤのサイズ、プレーヤの種類、自動再生を実装するか、それともクリック・トゥ・プレイ（ｃｌｉｃｋ−ｔｏ−ｐｌａｙ）とするか、どのようなコンテンツが動画に隣接しているか、ブラウザの種類（例えば、モバイル型ブラウザ対デスクトップ型ブラウザ）、周囲の動画広告、フレームの数及びサイズなどの基準を設定することを可能にする。このようにして、本システムは、モバイル端末を対象として、人口統計的要因及び地理的要因により、バイラル共有に基づいて広告購入を支援し、さらにはテレビ受信機を介した利用を支援する。

上記は、主に広告機会の購入者である顧客に焦点を当てているが、本システムはコンテンツ供給者（パブリッシャーまたは供給側プラットフォームなど）にも使用することができる。本システムにより、パブリッシャーは、コンテンツが入札されるエクスチェンジに当該コンテンツが入る前に、自身のコンテンツをスキャンしてタグ付けすることができる。これにより、関連し得る広告入札者／購入者に情報を提供することが可能となる。このような情報としては、動画サイズの確認、動画をクリック・トゥ・プレイとするかどうか、どのコンテンツが隣接しているか、及び通常であれば一般的に利用できないと思われる他の情報などがある。このプロセスは自動的に行うことが可能であるため、一定のパラメータについてコンテンツを確認することができる。これにより、パブリッシャーは、自身のコンテンツ・インベントリ上で自動化されたプロセスを実行することによってプレミアム・コンテンツを提供することができる。

拡張可能な入札プラットフォームは、典型的な入札システムを構成する機能部分の全てを備える。このプラットフォームを用いることにより、１つ以上の広告エクスチェンジに入札することが可能となり、広告主は広告ターゲティングに複合的な決定ルールを使用することができる。この複合的な決定ルールでは、エクスチェンジによって提供された入札要求属性に対してある程度の推論（論理的または発見的）を行う必要がある。あるいは、複合的な決定ルールは、単独で、または広告主もしくは第三者によって提供され、特定された他のデータと組み合わせて、入札要求属性に対してある程度の推論を行うことを要し、さらに、手動で入札者と同期される。あるいは、複合的な決定ルールは、単独で、または広告主もしくは第三者によって提供され、特定された他のデータと組み合わせて、入札要求属性に対してある程度の推論を行うことを要し、さらに、入札プラットフォームから離れたシステム上に常駐し、入札プラットフォームによって自動的に同期され得る。

広告主は、広告サーバを用いて、新たな入札要求属性をカスタマイズし、定義し、かつ／または実装することが可能であり、その後、この入札要求属性を自身のターゲティングに用いることができる。これは、入札システムによって解釈される複合的な決定ルールを記載するための形式言語を利用することにより、かつ／またはウェブコンソールのユーザーインターフェースを利用することによって実現可能である。広告主は、入札要求属性の強化に用いられるリモート型データベースまたはホスト型データベースを定義することが可能であり、次いでこれを、入札システムによって解釈される複合的な決定ルールを記載するための形式言語を利用することにより、かつ／またはウェブコンソールのユーザーインターフェースを利用することによって自身のターゲティングに用いることができる。

広告主は、自身が利用するために、または他のユーザーがプラットフォームを利用するために、データソース、推論ルールまたは属性を定義することにより、あるいはプラットフォームの機能を拡張して広告主に付与するためにプラットフォームによってコンパイル及び実行されるソースコード（コードの履歴を取ってもよく、取らなくてもよい）をプラットフォームに提供することにより、あるいは適切なマークアップ言語で書かれ、プラットフォームのユーザーインターフェースを通じてプラットフォームの機能または能力を広告主に提示するユーザーインターフェース・ウィジェットをプラットフォームに提供することにより、プラットフォームに対して諸々の機能を実装し、修正し、導入することができる。

ＲＴＢ向けのコンテンツ・インデックス化システム及びコンテンツ・ターゲティング・システムは、広告エクスチェンジの入札要求を監視し、ログに記録する。これにより、有用な統計データまたはメタデータを生成してインベントリ予測またはＲＴＢの広告ターゲティングに利用し、広告エクスチェンジによって明示的に提供されたもの以外のデータを組み込む（すなわち、オフラインデータ収集を行う）ことができる。このシステムは、広告エクスチェンジによって当該システムに与えられたユニークＵＲＬ及び部分ＵＲＬを追跡することが可能であり、自動的にＵＲＬを訪問し、メタデータを収集し、ＵＲＬについての分類を生成するクローリング・システム、あるいは、ＲＴＢ環境において広告インプレッションをターゲットとするのに直接的もしくは間接的に用いられるクローリング・システムを運用することができる。本システムは、クローリング・システムによって生成されたデータを格納及び管理することにより、入札者が入札要求に応答することを決定する際、入札者がそのデータをＲＴＢ動作条件において利用できるようにする。広告主は、自身のソースコードを用いて、本システムをカスタマイズすることができる。本システムは、多数の異なるクローラを用いて異なる種類のデータを収集することができる。このとき、それぞれのクローラは制御部によって管理されており、この制御部は、各ＵＲＬにわたる情報収集を統合し、種々のクローラからの結果を単一のＵＲＬレコードにまとめる。

インデックスは、サーバ及びＲＴＢ動作要件に対応可能なデータベースを構成する記憶装置の集まりを含む。インデックスは、リモート・データソースを解決してローカルキャッシュを維持すると共に、リモート・データソースに同期し、リモート・データソースが修正されたときには従属システムにアラートを送る。さらに、インデックスは、ユーザーに意識させずに計算を行い、そのエントリにおいてコンテンツに基づいたシグネチャを格納及び管理することにより、ＲＴＢ動作条件の要求を満たしつつ、複合的な決定ルールに対して高速な応答を実現することができる。本システムは、動的スキーマを用いて更新処理を行うことが可能であり、広告主によって与えられたオブジェクト・ライブラリまたは他のコンパイル済みコードを動的に読み込んで、システムのインデックス化能力またはデータアクセス能力を拡張することができる。インデックスは、他の言語で書かれたソースコード及び／またはスキーマを構文解析することによって解釈可能なスキーマ及び他のデータベース構成を自動的に生成することができる。

ＲＴＢシステムは、暗号通貨プロトコルを用いて、各マシン及び各入札者の予算並びにＲＴＢ支出を追跡することができる。ＲＴＢシステムは、入札要求で提供された地理位置情報に基づき、人口統計的情報を推論することができる。

本システムは全体として、様々な形式のロジック（このロジックはソフトまたはハードであってよい）として、ハードウェア及びソフトウェアによって実装される。マイクロプロセッサ、マイクロプロセッサ群、ＡＳＩＣ、ＤＳＰ、マイクロコントローラまたは命令を実行可能な他の専用または汎用のハードウェアを含む各種プロセッサを用いることができる。命令は、非一過性の形態でメモリに格納することができる。このようなメモリとしては、固体メモリ、磁気メモリ、光学メモリまたは他の好適な形態のメモリを挙げることができる。本システムの構成要素は、有線通信または無線通信を提供する通信インターフェース（必要に応じて送信機、受信機、ＲＦ回路、ネットワークインターフェース、及び構成要素とインターフェースを行う他の形態のハードウェア及びソフトウェアを含む）を介して上述した図面において特定されるウェブサイト、サーバ、ネットワーク及びプラットフォームと共に動作するインターフェースを含む。

１つ以上の具体的な実施態様では、本システムは、レプリケーション機能（Ｇｅｏｇｒａｐｈｉｃ Ｒｅｐｌｉｃａｔｉｏｎ）を用いて、多数のデータベース・ノードに接続されたＭｙＳＱＬサーバで構成されるＭｙＳＱＬクラスタを利用する。

Claims (15)

1. エンドユーザーに提供される広告エクスチェンジと共に使用し、前記エンドユーザーに表示するコンテンツを用いて広告するためのリアルタイム入札（ＲＴＢ）システムであって、
   前記広告表示に入札するための入札要求を受け取る広告エクスチェンジへのインターフェースを有するＲＴＢ入札者であって、エンドユーザーについての情報に応答し、広告エクスチェンジからの前記コンテンツに関するコンテンツ属性に応答して、前記ユーザー情報及びコンテンツ属性に基づいてクエリを生成する入札者と、
   前記クエリに応答するディレクトリ・サーバであって、前記クエリを１つ以上のデータベースに提供し、前記エンドユーザー及びコンテンツ属性についての前記情報に基づいて入札情報を取得するディレクトリ・サーバと、
   どの程度の入札がなされるかを前記入札情報に基づいて判断するために、前記入札情報に対する前記応答を用いる前記入札者と、を含むＲＴＢシステム。
2. 前記ＲＴＢ入札者が顧客要求の推論から受け取ったルールに応答する、請求項１に記載のＲＴＢシステム。
3. 前記入札者及びディレクトリ・サーバは、１００ｍｓ以内に入札を提供するように構成されている、請求項１に記載のＲＴＢシステム。
4. 入札要求のＵＲＬを格納するデータベースをさらに含む、請求項１に記載のＲＴＢシステム。
5. ユーザーに表示させるオンライン・コンテンツに関するメタデータであって、ユニフォーム・リソース・ロケータ（ＵＲＬ）を含むメタデータのデータベースと、
   異なる能力を備えた複数の種類のクローラを備えるクローラ・システムであって、前記クローラが、オンライン・コンテンツを特定し、前記複数のクローラのいずれを用いて前記データベースに格納するために前記コンテンツについての情報を抽出するかを決定するクローラ・システムと、を含むリアルタイム入札（ＲＴＢ）システム。
6. 前記クローラは、任意のＵＲＬのコンテンツを取得し、前記データのフォーマットを特定し、前記コンテンツを構文解析して、前記コンテンツについてのデータを前記データベースに格納するプレーンテキスト・クローラを含む、請求項５に記載のシステム。
7. ＨＴＭＬページ用のＪａｖａスクリプト・クローラをさらに含み、前記Ｊａｖａスクリプト・クローラは、解析用の仮想ウェブブラウザ内のページを構文解析して読み込む、請求項５に記載のシステム。
8. 前記ページをメモリにレンダリングするための仮想ブラウザを用いて、スクリーンショット、フラッシュ・コンテンツ及びウェブページ上の構成要素の相対位置を取得するレンダリング・クローラをさらに含む、請求項５に記載のシステム。
9. ブラウザに固有のコンテンツまたはページの挙動を判定するブラウザ固有レンダリング・クローラをさらに含む、請求項５に記載のシステム。
10. 前記ブラウザ固有レンダリング・クローラは、デスクトップブラウザに読み込むコンテンツとモバイルブラウザに読み込むコンテンツとの差異を判定するように構成されている、請求項９に記載のシステム。
11. 前記クローラは、ＵＲＬで動作し、インデックス化を行うプレーンテキスト・クローラを含み、前記システムは、レンダリング用の仮想ブラウザを含む第２のクローラに前記コンテンツを提供すべきかどうかを決定する、請求項５に記載のシステム。
12. データベースと、
    ウェブサイトを訪問するように構成されたウェブ・クローラであって、前記ウェブサイト上の動画の仮想レンダリングを行い、レンダリング時に前記動画の特徴を特定し、前記動画の特徴に関するメタデータを前記データベースに格納するウェブ・クローラと、を含むシステム。
13. 前記特徴は、前記動画の再生時のサイズを判定すること、前記動画が自動的に再生されるか、それともクリックして再生されるかを判定すること、及び前記動画中のコンテンツについての情報の１つ以上を含む、請求項１２に記載のシステム。
14. 前記データベースは、１つ以上の広告エクスチェンジから経時的に受け取った入札要求に応答する、請求項１２に記載のシステム。
15. エンドユーザーに提供される広告エクスチェンジと共に使用し、前記エンドユーザーに表示するコンテンツを用いて広告するためのリアルタイム入札（ＲＴＢ）方法であって、
    前記広告表示に入札するための入札要求を受け取ること、
    ユーザー情報及びコンテンツ属性に基づいてクエリを生成すること、
    前記クエリに応答するディレクトリ・サーバであって、前記クエリを１つ以上の第三者データベースに提供し、前記エンドユーザー及びコンテンツ属性についての前記情報に基づいて入札情報を取得するディレクトリ・サーバに前記クエリを提供すること、及び
    どの程度の入札がなされるかを前記入札情報に基づいて判断するために、前記入札情報に対する前記応答を用いること、を含むシステム。

Images