ホーム > 特許ランキング > グーグル エルエルシー
知財求人 - 知財ポータルサイト「IP Force」
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】6262795
(24)【登録日】2017年12月22日
(45)【発行日】2018年1月17日
(54)【発明の名称】ビデオ広告クリエイティブに伴う改善された広告
(51)【国際特許分類】
G06Q 30/02 20120101AFI20180104BHJP
【ＦＩ】
G06Q30/02 382
G06Q30/02 446
【請求項の数】14
【全頁数】49
(21)【出願番号】特願2016-80241(P2016-80241)
(22)【出願日】2016年4月13日
(62)【分割の表示】特願2014-39154(P2014-39154)の分割
【原出願日】2006年12月29日
(65)【公開番号】特開2016-149151(P2016-149151A)
(43)【公開日】2016年8月18日
【審査請求日】2016年4月13日
(31)【優先権主張番号】11/323,327
(32)【優先日】2005年12月30日
(33)【優先権主張国】US
(73)【特許権者】
【識別番号】502208397
【氏名又は名称】グーグル エルエルシー
(74)【代理人】
【識別番号】100108453
【弁理士】
【氏名又は名称】村山 靖彦
(74)【代理人】
【識別番号】100110364
【弁理士】
【氏名又は名称】実広 信哉
(74)【代理人】
【識別番号】100133400
【弁理士】
【氏名又は名称】阿部 達彦
(72)【発明者】
【氏名】ジェイソン・ベイヤー
(72)【発明者】
【氏名】ロノジョイ・チャクラバーティ
(72)【発明者】
【氏名】ケバル・デサイ
(72)【発明者】
【氏名】マニシュ・グプタ
(72)【発明者】
【氏名】ジル・エー．・フチタル
(72)【発明者】
【氏名】ウィラード・ラシュ
【審査官】
佐藤 裕子
(56)【参考文献】
【文献】
特開２００５−０７３００３（ＪＰ，Ａ）
【文献】
特開２００２−１４０３５９（ＪＰ，Ａ）
【文献】
特開２００２−０５６２８０（ＪＰ，Ａ）
【文献】
特開２００３−２２４８２９（ＪＰ，Ａ）
(58)【調査した分野】（Int.Cl.，ＤＢ名）
Ｇ０６Ｑ １０／００ − ９９／００
(57)【特許請求の範囲】
【請求項1】
１つまたは複数のプロセッサを有するセカンダリビデオコンテンツサーバによって、クライアントデバイスから、前記クライアントデバイスで再生されるストリーミングビデオを中断するために挿入されるべきビデオコンテンツに対する要求を受信することであって、前記要求は、前記クライアントデバイスで前記ストリーミングビデオの再生を開始することに続いて前記ストリーミングビデオ内に前記要求を生成するための埋込コードを実行することに応答して、クライアントデバイスによって送信され、前記ストリーミングビデオは、プライマリビデオコンテンツサーバによって、前記クライアントデバイスに提供される、受信することと、
前記セカンダリビデオコンテンツサーバによって、前記要求を受信することに応答して、前記クライアントデバイス上で実行されるメディアプレイヤーにおける再生のためのビデオコンテンツアイテムを提供することであって、前記メディアプレイヤーは、動作可能オブジェクトと、アプリケーションプログラミングインタフェースとを含み、前記動作可能オブジェクトのトリガは、前記メディアプレイヤーが前記クライアントデバイスで前記ビデオコンテンツアイテムの前記再生をスキップすることを引き起こすように構成され、前記アプリケーションプログラミングインタフェースは、前記動作可能オブジェクトの前記トリガを監視するために、前記セカンダリビデオコンテンツサーバにアクセス可能である、提供することと、
前記セカンダリビデオコンテンツサーバによって、前記メディアプレイヤーの前記アプリケーションプログラミングインタフェースを介して、前記メディアプレイヤーが前記ビデオコンテンツアイテムの再生をスキップすることを引き起こすために、前記動作可能オブジェクトの前記トリガを検出することと、
前記セカンダリビデオコンテンツサーバによって、前記メディアプレイヤーの前記アプリケーションプログラミングインタフェースを介して前記動作可能オブジェクトの前記トリガを検出することに応答して、前記ビデオコンテンツアイテムが前記クライアントデバイスで再生される前記ストリーミングビデオを中断する第１の時間と、前記メディアプレイヤーが前記ビデオコンテンツアイテムをスキップすることを前記動作可能オブジェクトのトリガが引き起こす第２の時間との間における時間の量に対応する時間期間を識別することと、
前記セカンダリビデオコンテンツサーバによって、前記クライアントデバイスにおける前記ビデオコンテンツアイテムの配信および再生を確認するために、前記時間期間が所定の時間しきい値よりも大きいということを判断することと、
前記セカンダリビデオコンテンツサーバによって、前記時間期間が前記所定の時間しきい値よりも大きいということを判断することに応答して、前記ビデオコンテンツアイテムに対するカウンタを更新することと
を含む、コンピュータにより実現される方法。
前記セカンダリビデオコンテンツサーバによって、前記要求を受信することに応答して、前記クライアントデバイス上で実行されるメディアプレイヤーにおける再生のためのビデオコンテンツアイテムを提供することであって、前記メディアプレイヤーは、動作可能オブジェクトと、アプリケーションプログラミングインタフェースとを含み、前記動作可能オブジェクトのトリガは、前記メディアプレイヤーが前記クライアントデバイスで前記ビデオコンテンツアイテムの前記再生をスキップすることを引き起こすように構成され、前記アプリケーションプログラミングインタフェースは、前記動作可能オブジェクトの前記トリガを監視するために、前記セカンダリビデオコンテンツサーバにアクセス可能である、提供することと、
前記セカンダリビデオコンテンツサーバによって、前記メディアプレイヤーの前記アプリケーションプログラミングインタフェースを介して、前記メディアプレイヤーが前記ビデオコンテンツアイテムの再生をスキップすることを引き起こすために、前記動作可能オブジェクトの前記トリガを検出することと、
前記セカンダリビデオコンテンツサーバによって、前記メディアプレイヤーの前記アプリケーションプログラミングインタフェースを介して前記動作可能オブジェクトの前記トリガを検出することに応答して、前記ビデオコンテンツアイテムが前記クライアントデバイスで再生される前記ストリーミングビデオを中断する第１の時間と、前記メディアプレイヤーが前記ビデオコンテンツアイテムをスキップすることを前記動作可能オブジェクトのトリガが引き起こす第２の時間との間における時間の量に対応する時間期間を識別することと、
前記セカンダリビデオコンテンツサーバによって、前記クライアントデバイスにおける前記ビデオコンテンツアイテムの配信および再生を確認するために、前記時間期間が所定の時間しきい値よりも大きいということを判断することと、
前記セカンダリビデオコンテンツサーバによって、前記時間期間が前記所定の時間しきい値よりも大きいということを判断することに応答して、前記ビデオコンテンツアイテムに対するカウンタを更新することと
を含む、コンピュータにより実現される方法。
【請求項2】
表示のために前記ビデオコンテンツアイテムを提供することは、ビデオコンテンツを含むビデオドキュメントのコンテンツスロット内に前記ビデオコンテンツアイテムを提供することを含む、請求項１のコンピュータにより実現される方法。
【請求項3】
前記ビデオコンテンツアイテムは、インターネットプロトコルを使用して、１つまたは複数の通信ネットワークを介して、前記クライアントデバイスに送信される、請求項１のコンピュータにより実現される方法。
【請求項4】
前記時間期間が所定の時間期間より少なくないということを判断することに応答して、前記ビデオコンテンツアイテムが有効なインプレッションを受信したということを判断することを更に含む、請求項１のコンピュータにより実現される方法。
【請求項5】
ビデオコンテンツアイテムが前記有効なインプレッションを受信したということを判断することに応答して、前記カウンタをインクリメントすることを更に含む、請求項４のコンピュータにより実現される方法。
【請求項6】
前記サーバによって、前記メディアプレイヤーを提供することことであって、前記メディアプレイヤーは、前記ビデオコンテンツアイテムをリプレイするように構成される第２動作可能オブジェクトを含む、提供することと、
前記サーバによって、前記第２の動作可能オブジェクト上で取得された動作を検出することと、
前記サーバによって、再生のために、前記ビデオコンテンツアイテムを提供することと、
前記第２の動作可能オブジェクト上で取得された前記動作を判断することに応答して、前記サーバによって、再生のために前記ビデオコンテンツアイテムを提供するために、前記ビデオコンテンツアイテムが有効なインプレッションを受信しなかったということを判断することと
を更に含む、請求項１のコンピュータにより実現される方法。
前記サーバによって、前記第２の動作可能オブジェクト上で取得された動作を検出することと、
前記サーバによって、再生のために、前記ビデオコンテンツアイテムを提供することと、
前記第２の動作可能オブジェクト上で取得された前記動作を判断することに応答して、前記サーバによって、再生のために前記ビデオコンテンツアイテムを提供するために、前記ビデオコンテンツアイテムが有効なインプレッションを受信しなかったということを判断することと
を更に含む、請求項１のコンピュータにより実現される方法。
【請求項7】
プロセッサ実行可能命令を記憶するメモリを具備するセカンダリビデオコンテンツサーバと、
前記メモリに結合されたプロセッサとを含み、前記プロセッサは、
クライアントデバイスから、前記クライアントデバイスで再生されるストリーミングビデオを中断するために挿入されるべきビデオコンテンツに対する要求を受信することであって、前記要求は、前記クライアントデバイスで前記ストリーミングビデオの再生を開始することに続いて前記ストリーミングビデオ内に前記要求を生成するための埋込コードを実行することに応答して、クライアントデバイスによって送信され、前記ストリーミングビデオは、プライマリビデオコンテンツサーバによって、前記クライアントデバイスに提供される、受信することと、
前記要求を受信することに応答して、前記クライアントデバイス上で実行されるメディアプレイヤーにおける再生のためのビデオコンテンツアイテムを提供することであって、前記メディアプレイヤーは、動作可能オブジェクトと、アプリケーションプログラミングインタフェースとを含み、前記動作可能オブジェクトのトリガは、前記メディアプレイヤーが前記クライアントデバイスで前記ビデオコンテンツアイテムの前記再生をスキップすることを引き起こすように構成され、前記アプリケーションプログラミングインタフェースは、前記動作可能オブジェクトの前記トリガを監視するために、前記セカンダリビデオコンテンツサーバにアクセス可能である、提供することと、
前記メディアプレイヤーの前記アプリケーションプログラミングインタフェースを介して、前記メディアプレイヤーが前記ビデオコンテンツアイテムの再生をスキップすることを引き起こすために、前記動作可能オブジェクトの前記トリガを検出することと、
前記メディアプレイヤーの前記アプリケーションプログラミングインタフェースを介して前記動作可能オブジェクトの前記トリガを検出することに応答して、前記ビデオコンテンツアイテムが前記クライアントデバイスで再生される前記ストリーミングビデオを中断する第１の時間と、前記メディアプレイヤーが前記ビデオコンテンツアイテムをスキップすることを前記動作可能オブジェクトのトリガが引き起こす第２の時間との間における時間の量に対応する時間期間を識別することと、
前記クライアントデバイスにおける前記ビデオコンテンツアイテムの配信および再生を確認するために、前記時間期間が所定の時間しきい値よりも大きいということを判断することと、
前記時間期間が前記所定の時間しきい値よりも大きいということを判断することに応答して、前記ビデオコンテンツアイテムに対するカウンタを更新することと
を行うように構成された、システム。
前記メモリに結合されたプロセッサとを含み、前記プロセッサは、
クライアントデバイスから、前記クライアントデバイスで再生されるストリーミングビデオを中断するために挿入されるべきビデオコンテンツに対する要求を受信することであって、前記要求は、前記クライアントデバイスで前記ストリーミングビデオの再生を開始することに続いて前記ストリーミングビデオ内に前記要求を生成するための埋込コードを実行することに応答して、クライアントデバイスによって送信され、前記ストリーミングビデオは、プライマリビデオコンテンツサーバによって、前記クライアントデバイスに提供される、受信することと、
前記要求を受信することに応答して、前記クライアントデバイス上で実行されるメディアプレイヤーにおける再生のためのビデオコンテンツアイテムを提供することであって、前記メディアプレイヤーは、動作可能オブジェクトと、アプリケーションプログラミングインタフェースとを含み、前記動作可能オブジェクトのトリガは、前記メディアプレイヤーが前記クライアントデバイスで前記ビデオコンテンツアイテムの前記再生をスキップすることを引き起こすように構成され、前記アプリケーションプログラミングインタフェースは、前記動作可能オブジェクトの前記トリガを監視するために、前記セカンダリビデオコンテンツサーバにアクセス可能である、提供することと、
前記メディアプレイヤーの前記アプリケーションプログラミングインタフェースを介して、前記メディアプレイヤーが前記ビデオコンテンツアイテムの再生をスキップすることを引き起こすために、前記動作可能オブジェクトの前記トリガを検出することと、
前記メディアプレイヤーの前記アプリケーションプログラミングインタフェースを介して前記動作可能オブジェクトの前記トリガを検出することに応答して、前記ビデオコンテンツアイテムが前記クライアントデバイスで再生される前記ストリーミングビデオを中断する第１の時間と、前記メディアプレイヤーが前記ビデオコンテンツアイテムをスキップすることを前記動作可能オブジェクトのトリガが引き起こす第２の時間との間における時間の量に対応する時間期間を識別することと、
前記クライアントデバイスにおける前記ビデオコンテンツアイテムの配信および再生を確認するために、前記時間期間が所定の時間しきい値よりも大きいということを判断することと、
前記時間期間が前記所定の時間しきい値よりも大きいということを判断することに応答して、前記ビデオコンテンツアイテムに対するカウンタを更新することと
を行うように構成された、システム。
【請求項8】
前記サーバは、ビデオコンテンツを含むビデオドキュメントのコンテンツスロット内に前記ビデオコンテンツアイテムを提供するように更に構成される、請求項７のシステム。
【請求項9】
前記サーバは、前記ビデオコンテンツアイテムを、インターネットプロトコルを使用して、１つまたは複数の通信ネットワークを介して、前記クライアントデバイスに送信する、請求項７のシステム。
【請求項10】
前記サーバは、前記時間期間が前記所定の時間しきい値より少なくないということを判断することに応答して、前記ビデオコンテンツアイテムが有効なインプレッションを受信するということを判断するように更に構成される、請求項７のシステム。
【請求項11】
前記サーバは、前記有効なインプレッションを受信する前記ビデオコンテンツアイテムに応答して、前記カウンタをインクリメントするように更に構成される、請求項１０のシステム。
【請求項12】
前記サーバは、
再生のために、前記メディアプレイヤーを提供することことであって、前記メディアプレイヤーは、前記メディアプレイヤーが前記ビデオコンテンツアイテムをリプレイすることを引き起こすように構成された第２の動作可能オブジェクトを含むように構成される、提供することと、
前記第２の動作可能オブジェクト上で取得された動作を検出することと、
再生のために、前記ビデオコンテンツアイテムを提供することと、
前記第２の動作可能オブジェクト上で取得された前記動作を判断することに応答して、再生のために前記ビデオコンテンツアイテムを提供するために、前記ビデオコンテンツアイテムが有効なインプレッションを受信しなかったということを判断することと
を行うように更に構成される、請求項７のシステム。
再生のために、前記メディアプレイヤーを提供することことであって、前記メディアプレイヤーは、前記メディアプレイヤーが前記ビデオコンテンツアイテムをリプレイすることを引き起こすように構成された第２の動作可能オブジェクトを含むように構成される、提供することと、
前記第２の動作可能オブジェクト上で取得された動作を検出することと、
再生のために、前記ビデオコンテンツアイテムを提供することと、
前記第２の動作可能オブジェクト上で取得された前記動作を判断することに応答して、再生のために前記ビデオコンテンツアイテムを提供するために、前記ビデオコンテンツアイテムが有効なインプレッションを受信しなかったということを判断することと
を行うように更に構成される、請求項７のシステム。
【請求項13】
コンピュータ実行可能命令を記憶する非一時的コンピュータ読取可能記憶媒体であって、前記コンピュータ実行可能命令は、コンピュータによって実行されると、前記コンピュータに、
クライアントデバイスから、前記クライアントデバイスで再生されるストリーミングビデオを中断するために挿入されるべきビデオコンテンツに対する要求を受信することであって、前記要求は、前記クライアントデバイスで前記ストリーミングビデオの再生を開始することに続いて前記ストリーミングビデオ内に前記要求を生成するための埋込コードを実行することに応答して、クライアントデバイスによって送信され、前記ストリーミングビデオは、プライマリビデオコンテンツサーバによって、前記クライアントデバイスに提供される、受信することと、
前記要求を受信することに応答して、前記クライアントデバイス上で実行されるメディアプレイヤーにおける再生のためのビデオコンテンツアイテムを提供することであって、前記メディアプレイヤーは、動作可能オブジェクトと、アプリケーションプログラミングインタフェースとを含み、前記動作可能オブジェクトのトリガは、前記メディアプレイヤーが前記クライアントデバイスでの前記ビデオコンテンツアイテムの前記再生をスキップすることを引き起こすように構成され、前記アプリケーションプログラミングインタフェースは、前記動作可能オブジェクトの前記トリガを監視するために、前記セカンダリビデオコンテンツサーバにアクセス可能である、提供することと、
前記メディアプレイヤーの前記アプリケーションプログラミングインタフェースを介して、前記メディアプレイヤーが前記ビデオコンテンツアイテムの再生をスキップすることを引き起こすために、前記動作可能オブジェクトの前記トリガを検出することと、
前記メディアプレイヤーの前記アプリケーションプログラミングインタフェースを介して前記動作可能オブジェクトの前記トリガを検出することに応答して、前記ビデオコンテンツアイテムが前記クライアントデバイスで再生される前記ストリーミングビデオを中断する第１の時間と、前記メディアプレイヤーが前記ビデオコンテンツアイテムをスキップすることを前記動作可能オブジェクトのトリガが引き起こす第２の時間との間における時間の量に対応する時間期間を識別することと、
前記クライアントデバイスにおける前記ビデオコンテンツアイテムの配信および再生を確認するために、前記時間期間が所定の時間しきい値よりも大きいということを判断することと、
前記時間期間が前記所定の時間しきい値よりも大きいということを判断することに応答して、前記ビデオコンテンツアイテムに対するカウンタを更新することと
を行わせる、非一時的コンピュータ読取可能記憶媒体。
クライアントデバイスから、前記クライアントデバイスで再生されるストリーミングビデオを中断するために挿入されるべきビデオコンテンツに対する要求を受信することであって、前記要求は、前記クライアントデバイスで前記ストリーミングビデオの再生を開始することに続いて前記ストリーミングビデオ内に前記要求を生成するための埋込コードを実行することに応答して、クライアントデバイスによって送信され、前記ストリーミングビデオは、プライマリビデオコンテンツサーバによって、前記クライアントデバイスに提供される、受信することと、
前記要求を受信することに応答して、前記クライアントデバイス上で実行されるメディアプレイヤーにおける再生のためのビデオコンテンツアイテムを提供することであって、前記メディアプレイヤーは、動作可能オブジェクトと、アプリケーションプログラミングインタフェースとを含み、前記動作可能オブジェクトのトリガは、前記メディアプレイヤーが前記クライアントデバイスでの前記ビデオコンテンツアイテムの前記再生をスキップすることを引き起こすように構成され、前記アプリケーションプログラミングインタフェースは、前記動作可能オブジェクトの前記トリガを監視するために、前記セカンダリビデオコンテンツサーバにアクセス可能である、提供することと、
前記メディアプレイヤーの前記アプリケーションプログラミングインタフェースを介して、前記メディアプレイヤーが前記ビデオコンテンツアイテムの再生をスキップすることを引き起こすために、前記動作可能オブジェクトの前記トリガを検出することと、
前記メディアプレイヤーの前記アプリケーションプログラミングインタフェースを介して前記動作可能オブジェクトの前記トリガを検出することに応答して、前記ビデオコンテンツアイテムが前記クライアントデバイスで再生される前記ストリーミングビデオを中断する第１の時間と、前記メディアプレイヤーが前記ビデオコンテンツアイテムをスキップすることを前記動作可能オブジェクトのトリガが引き起こす第２の時間との間における時間の量に対応する時間期間を識別することと、
前記クライアントデバイスにおける前記ビデオコンテンツアイテムの配信および再生を確認するために、前記時間期間が所定の時間しきい値よりも大きいということを判断することと、
前記時間期間が前記所定の時間しきい値よりも大きいということを判断することに応答して、前記ビデオコンテンツアイテムに対するカウンタを更新することと
を行わせる、非一時的コンピュータ読取可能記憶媒体。
【請求項14】
前記命令は、前記時間期間が所定の時間期間より少なくないということを判断することに応答して、前記ビデオコンテンツアイテムが有効なインプレッションを受信するということを判断することを更に含む、請求項１３の非一時的コンピュータ読取可能記憶媒体。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、例えば、オンライン広告のような広告に関連する。さらに詳細には、本発明は、例えば、インプレッション毎の費用広告のような広告のエンドユーザに対する有用性（utility）を改善することに関連する。
【背景技術】
【0002】
テレビジョン、ラジオ、新聞、および雑誌のような、従来のメディアを使用した広告がよく知られている。残念なことに、さまざまなメディア手段の典型的聴衆についての人口統計学研究および完全に適正な仮定で準備しているときでさえも、広告主は彼らの広告予算の多くが単に無駄になっていることを認識している。さらに、このような無駄を識別することや、なくすことは非常に困難である。
【0003】
近年、よりインタラクティブなメディアを通しての広告が人気となってきた。例えば、インターネットを使用する人の数が爆発的に増加したので、インターネットを通して提供されるメディアとサービスは、潜在的に強力な広告方法であるとして、広告主は理解するようになってきた。
【0004】
インタラクティブ広告は、受け取る聴衆に対して広告主の広告をターゲット付けする機会を広告主に提供する。すなわち、広告は、何らかのユーザ動作から推論されるニーズに関連性がある（例えば、検索エンジンに対するユーザの検索クエリに関連性のある、ユーザにより要求されたドキュメント中のコンテンツに関連性のある等）かもしれないので、エンドユーザにとって、ターゲット付けされた広告は、より有用であることが多い。クエリキーワードターゲット付けは、関連性のある広告を配信するために検索エンジンによって使用されてきた。例えば、カリフォルニア州、マウンテンビューのグーグル社（登録商標）（“グーグル”と呼ぶ）による、ＡｄＷｏｒｄｓ（登録商標）広告システムは、検索クエリからのキーワードに対してターゲット付けされた広告を配信する。同様に、コンテンツターゲット付けされた広告配信システムが提案されてきた。例えば、“関連性のある広告を供給する方法および装置”と題され、２００２年１２月６日に出願され、Jeffrey A. Dean氏、 Georges R. Harik氏、および Paul Buchheit氏を発明者として記載する、（ここに参照によりその全体が組み込まれ、“‘４２７出願”として呼ばれる）米国特許出願シリアル番号第10/314,427号と；“コンテンツに基づいた広告供給”と題され、２００３年２月２６日に出願され、Darrell Anderson氏、 Paul Buchheit氏、 Alex Carobus氏、 Claire Cui氏、 Jeffrey A. Dean氏、 Georges R. Harik氏、 Deepak Jindal氏、および Narayanan Shivakumar氏を発明者として記載する、（ここに参照によりその全体が組み込まれ、“‘９００出願”として呼ばれる）米国特許出願シリアル番号第10/375,900号は、例えば、ウェブページのようなドキュメントのコンテンツに関連性のある広告を提供する方法および装置を説明している。例えば、グーグルによるＡｄＳｅｎｓｅ（登録商標）広告システムのような、コンテンツターゲット付けされた広告配信システムが、ウェブページ上で広告を供給するのに使用されてきた。
【0005】
上記のことから理解できるように、テキストドキュメント中のテキスト概念に関連性のある広告を供給することと、検索クエリ中のキーワードに関連性のある広告を供給することとは有用であり、これは、おそらく、このような広告が現在のユーザの関心に関わっているためである。結果として、このようなオンライン広告は、ますます人気になってきた。さらに、他のターゲット付け技術を使用する広告や、ターゲット付けされていないオンライン広告さえも、ますます人気になってきた。
【0006】
現在、例えば、テレビジョンブロードキャストのようなビデオコンテンツとともに配信される広告は、典型的に“予約”モデルに基づいている。すなわち、広告主は、テレビで放送されたブロードキャスト中のスポットを、固定料金に対して予約する。しかしながら、残念なことに、予約モデルは、ビデオコンテンツ発行者に対する収益を必ずしも最大化させない。これは、このような広告スポットに対する契約を交渉するためのリソースを持っていない多くの広告主は、このような広告スポットに対して競合しないためである。さらに、エンドユーザ（すなわち、オーディオコンテンツの配信を受け取る人）の観点からすると、この広告は、まったく不適切であるかもしれず、または、この広告が有用になることが可能なほどには有用でないかもしれない。ビデオコンテンツ（“ビデオドキュメント”）中に広告を挿入するシステムのような、既存の広告システムを改善できる。例えば、ビデオドキュメントとともにどのように広告が供給されるか（および／または、どのようにビデオ広告が任意の文書上で供給されるか）を改善することが有用であろう。
【先行技術文献】
【特許文献】
【0007】
【特許文献1】特開２００３−２４２３７２号公報
【特許文献2】特開２００２−２５９７９０号公報
【発明の概要】
【0008】
本発明と一貫した実施形態を使用して、ビデオドキュメントとともに（例えば、ビデオドキュメント上に）広告を供給することを改善するかもしれない。例えば、本発明と一貫した少なくともいくつかの実施形態は、ａ）広告トリガに応答して、候補ビデオ広告を識別し、ｂ）候補ビデオ広告のビデオ関連の特徴に関連する１組の少なくとも１つのキーを識別し、ｃ）少なくとも１つのキーに関連している履歴データを使用して、候補広告性能を推定する。ビデオドキュメントの例は、インターネット上で発行されたビデオファイル、テレビジョン番組、ライブのまたは記録されたトークショー、ビデオ−ボイスメール、ビデオ会話のセグメント等を含む。
【図面の簡単な説明】
【0009】
【発明を実施するための形態】
【0010】
本発明は、例えば、ビデオコンテンツを含むドキュメントのような、ドキュメントに伴うビデオ広告の供給を改善するための、新規な方法、装置、メッセージフォーマット、および／またはデータ構造に関する。以下の説明は、当業者が本発明を実施および使用できるように提示し、特定の応用と特定の応用の要求の状況で提供する。したがって、本発明と一貫した実施形態の以下の説明は、図示および説明を提供するが、網羅的なものであることを意図するものではなく、または、開示する正確な形態に本発明を制限することを意図するものではない。開示する実施形態に対するさまざまな修正が当業者に明らかになり、以下に述べる一般的原則は、他の実施形態および応用に適用されてもよい。例えば、フロー図を参照して一連の動作を説明するが、１つの動作の実行が他の動作の完了に依拠していないときは、他の実施では動作の順序が異なっていてもよい。さらに、従属していない動作は並列に実行されてもよい。また、ここで使用するように、冠詞“ａ”は１つ以上のアイテムを含むことを意図している。１つだけのアイテムを意図するところでは、用語“１つの（ｏｎｅ）”または類似の言葉を使用する。以下では、“情報”は、実際の情報、あるいは、このような情報に対するポインタ、このような情報の識別子、または、このような情報のロケーションを指してもよい。詳細な説明中で使用されるどのエレメント、動作、または命令も、そうであるとして明示的に示さない限り、本発明に対して重大または不可欠であるとして解釈すべきでない。したがって、本発明は示している実施形態に制限されることを意図しておらず、発明者は、何らかの特許可能な記述された主題を含むものとして本発明を考えている。
【0011】
以下において、明細書で使用する用語の定義をセクション４．１において提供する。次に、本発明がその中で動作してよい、または本発明がそれを用いて動作してよい環境をセクション４．２において説明する。本発明の例示的な実施形態をセクション４．３において説明する。その後、本発明の例示的な実施形態の有用性を図示する特定の例をセクション４．４において提供する。最後に、本発明に関するいくつかの結論をセクション４．５において述べる。
【0012】
セクション４．１ 定義 以下に図２および３に関して説明する例示的なシステムで、または、他の任意のシステムで使用されるもののような、オンライン広告はさまざまな固有の特徴を持つことがある。このような特徴は、アプリケーションおよび／または広告主によって指定されてもよい。これらの特徴は、以下で“広告特徴”として呼ぶ。例えば、テキスト広告のケースでは、広告特徴はタイトルライン、広告テキスト、および埋め込みリンクを含んでいてもよい。画像広告のケースでは、広告特徴は、画像、実行可能コード、および埋め込みリンクを含んでいてもよい。ビデオ広告のケースでは、広告特徴は、ビデオコンテンツと、おそらくオーディオコンテンツとを含んでいてもよい。広告特徴はまた、（例えば、トーン、ピクセル等としてエンコードされる、ビデオストリームの非ビデオパケット中で提供される等の）実行可能コードを含んでもよい。オンライン広告のタイプに依拠して、広告特徴はテキスト、リンク、オーディオファイル、ビデオファイル、画像ファイル、実行可能コード、埋め込み情報等のうちの１つ以上を含んでいてもよい。１つより多いタイプのメディアをレンダリングできるデバイス（異なる出力を持つデバイス）において、いくつかの広告特徴は、１つの出力を通してユーザに対してレンダリングされる１つのタイプのメディアに属していてもよい一方、他の広告特徴は、別の出力を通してユーザに対してレンダリングされる別のタイプのメディアに属していてもよい。例えば、移動体電話機がスピーカ、ディスプレイ、およびテレフォニー手段を備える場合、このような電話機上にレンダリングされることになるビデオ広告は、オーディオ−ビデオコンポーネント、および、エンコードされた電話番号にダイアルするための実行可能コードのうちの１つ以上を持つことができる。他のタイプの広告特徴が可能であるのは当然である。
【0013】
オンライン広告が供給されるとき、１つ以上のパラメータを使用して、広告がどのように、いつ、および／またはどこで供給されたのかを記述してもよい。これらのパラメータを、以下では“供給パラメータ”と呼ぶ。供給パラメータは、例えば、以下のうちの１つ以上を含んでよい。すなわち、その上に、または、それとともに、広告が供給されているドキュメント（その上の情報を含む）の特徴；広告の供給に関係付けられた検索クエリ、または検索結果；ユーザ特性（例えば、ユーザの地理的ロケーション、ユーザによって使用される言語、使用されるブラウザのタイプ、過去のページビュー、過去の挙動、ユーザアカウント、システムにより使用される任意のウェブクッキー、ユーザデバイス特性等）；要求を開始したホストまたはアフェリエイト（例えば、アメリカオンライン(登録商標)、グーグル、ヤフー(登録商標)）のサイト；広告が供給されたページ上の広告の絶対的な位置；広告が供給された広告スポット（例えば、供給された他の広告を基準にした広告の（空間的または時間的）位置）；広告の絶対的なサイズ；他の広告を基準にした広告のサイズ；広告の絶対的／相対的な解像度；広告の絶対的／相対的なビデオフレームレート；広告の絶対的な音量；他の広告を基準にした広告の音量；広告の絶対的な時間長；広告の相対的な時間長；広告の色；他の供給された広告数；他の供給された広告のタイプ；供給時刻；供給曜日；供給時期等。本発明の状況で使用してもよい、他の供給パラメータがあるのは当然である。
【0014】
供給パラメータは、広告特徴にとっては付帯的であってよいが、これらは供給条件または制約として、広告に関係付けられてよい。供給条件または制約として使用されるとき、このような供給パラメータを、単に“供給制約”（または“ターゲット基準”）として呼ぶ。例えば、いくつかのシステムにおいては、広告主は、その広告が平日にのみ、一定の位置より高く、一定のロケーションのユーザにのみ等、供給されなければならないと指定することで、その広告を供給することをターゲット付けすることができる。他の例としては、いくつかのシステムにおいて、広告主は、ページまたは検索クエリが一定のキーワードまたはフレーズを含む場合にだけ、その広告が供給されなければならないと指定してもよい。さらに別の例としては、その上に、または、それとともに、供給されているドキュメントが一定のトピックまたは概念を含む場合、または、特定のクラスタ、もしくは他の何らかの分類（例えば、垂直型）に該当する場合にのみ、その広告が供給されなければならないと広告主が指定できるシステムもある。いくつかのシステムにおいて、広告主は、特定の特性を持つユーザデバイスのみに対して、その広告が供給されること（または供給されないこと）を特定してもよい。最後に、いくつかのシステムにおいて、特定のロケーションから発信される要求に応答して、または、特定のロケーションに関する要求に応答して、広告が供給されるように広告をターゲット付けしてもよい。
【0015】
“広告情報”は、広告特徴、広告供給制約、（“広告導出情報”として呼ばれる）広告特徴もしくは広告供給制約から導出可能な情報、および／または、（“広告関連情報”として呼ばれる）広告に関連した情報、とともにこのような情報の拡張（例えば、広告関連情報から導出される情報）を含んでいてもよい。
【0016】
広告のインプレッション数（すなわち、広告がレンダリングされる回数）に対する、広告を選択する数（例えば、クリックスルー、ダイアルスルー等）の比は、広告の“選択レート”（すなわち“クリックスルーレート”または“ＣＴＲ”）として定義される。
【0017】
“コンバージョン”は、ユーザが以前に供給された広告に関連するトランザクションを完了させるときに発生すると言われている。コンバージョンを構成する内容はケースによって異なり、さまざまな方法で決定できる。例えば、ユーザが広告をクリックし、広告主のウェブページに導かれ、そのウェブページを離れる前にそこで購入を完了するときに、コンバージョンが発生するというケースがある。代わりに、コンバージョンは、ユーザが広告を見て、予め定められた時間（例えば７日間）内に広告主のウェブページで購入することとして定義されてよい。さらに別の代替案では、コンバージョンは、例えば、白書をダウンロードする、ウェブサイトの少なくとも所定の深さまでナビゲーションする、少なくとも一定数のウェブページを見る、少なくとも予め定められた時間量をウェブサイトまたはウェブページで費やす、ウェブサイトに登録する、電話番号にダイアルする、製品もしくはサービスの問い合わせを送る等の、任意の測定可能／観察可能なユーザアクションであるとして、広告主によって定義してもよい。コンバージョンを構成するユーザアクションはこれらに制限されないが、ユーザアクションが購入の完了を示さない場合であっても、これらはセールスリードを示すことが多い。実際に、何がコンバージョンを構成するかについて他の多くの定義が考えられる。
【0018】
広告のインプレッション数（すなわち、広告がレンダリングされる回数）に対するコンバージョン数の比と、選択の数（または、他の何らかの以前のイベントの数）に対するコンバージョン数の比との両方が、“コンバージョンレート”または“ＣＲ”と呼ばれる。コンバージョンレートのタイプは、それが使用される状況から明らかになるだろう。広告の供給から予め定められた時間内に発生し得ることとコンバージョンが定義される場合、コンバージョンレートの１つの考えられる定義は、過去に、予め定められた時間より長く供給されていた広告だけを考慮するかもしれない。
【0019】
“プロパティ”は、その上に広告を提示することができる何らかのものである。プロパティはオンラインコンテンツ（例えば、ウェブサイト、ビデオ番組、ウェブキャスト、ポッドキャスト、オンラインゲーム等）、オフラインコンテンツ（例えば、新聞、雑誌、劇プロダクション、コンサート、スポーツイベント、テレビジョンブロードキャスト等）、ならびに／あるいは、オフライン物体（例えば、電光掲示板、スタジアムスコアボード、外野壁、トラックトレーラーの側面等）を含む。コンテンツ（例えば、雑誌、新聞、ウェブサイト、ｅ−メールメッセージ、テレビジョン番組等）を伴うプロパティを、“メディアプロパティ”として呼んでもよい。プロパティそれら自体は、オフラインであってもよいが、プロパティについての関係情報（例えば、属性、トピック、概念、カテゴリ、キーワード、関連性情報、サポートされる広告のタイプ等）は、オンラインで利用可能であってもよい。例えば、野外ジャズ音楽フェスティバルでは、トピック“音楽”および“ジャズ”、コンサートのロケーション、コンサートの時刻、フェスティバルに出演予定のアーティスト、ならびに、利用可能な広告スポットのタイプ（例えば、印刷されたプログラム、ステージ上のスポット、座席背面のスポット、スポンサーのオーディオアナウンス、オンサイトビデオディスプレイ等）が入力されてもよい。“ビデオプロパティ”は、見ることができるプロパティである。ビデオプロパティは、他のコンポーネント（例えば、オーディオ）を含んでいてもよいが、必ずしも含むわけではない。
【0020】
“ドキュメント”は、何らかの機械読取可能および機械記憶可能な作業生産物を含むものとして幅広く解釈すべきである。ドキュメントは、ファイル、ファイルの組み合わせ、他のファイルへのリンクが埋め込まれた１つ以上のファイル等であってもよい。ファイルは、テキスト、オーディオ、画像、ビデオ等の任意のタイプのものであってもよい。エンドユーザにレンダリングされるドキュメントの一部は、ドキュメントの“コンテンツ”と見なすことができる。ドキュメントは、コンテンツ（言葉、絵、音、会話等）とそのコンテンツの意味の何らかの表示（例えば、ｅ−メールフィールドと関連データ、ＨＴＭＬタグと関連データ、埋め込まれた番組のタイトルと関連情報等）との両方を含む“構造化されたデータ”を含んでいてもよい。ドキュメント中の広告スポットは、埋め込まれた情報または命令で定義されてもよい。インターネットの状況において、普通のドキュメントはウェブページである。ウェブページはコンテンツを含むことが多く、（メタ情報、ハイパーリンク等のような）埋め込まれた情報、および／または（Ｊａｖａ(登録商標)スクリプト等のような）埋め込まれた命令を含んでいてもよい。多くのケースでは、ドキュメントはアドレス指定可能な記憶ロケーションを有し、したがってこのアドレス指定可能なロケーションによって一意的に特定できる。ユニバーサルリソースロケータ（ＵＲＬ）は、インターネット上の情報にアクセスするために使用されるアドレスである。
【0021】
“ウェブドキュメント”はウェブ上で発行される任意のドキュメントを含む。ウェブドキュメントの例は、例えば、ウェブサイト、ウェブページ、ウェブキャスト等を含む。
【0022】
“ビデオドキュメント”は、再生またはデコードされたときに、見ることができるドキュメントである。“ビデオドキュメント”は、そのコンテンツが有体的メディア上に最終的に記憶されているか否かに関わらず、ビデオコンテンツを含んでもよい。ビデオドキュメントは、例えば、ライブのまたは記録されたテレビジョン番組、ライブのまたは記録された芝居または演劇作品、音楽ビデオ、テレビで放送されたイベント（例えば、スポーツイベント、政治的イベント、ニュースイベント等）、ビデオ−ボイスメール等を含んでもよい。同じビデオコンテンツの異なる形態またはフォーマット（例えば、オリジナルの、圧縮された、パケット化された、ストリームされた等）のそれぞれを、ビデオドキュメント（例えば、同じビデオドキュメント、または異なるビデオドキュメント）であるとみなしてもよい。本発明と一貫した実施形態は、例えば、以下のうちの１つ以上のような、さまざまなビデオおよび“コンテナ”ファイルフォーマットとともに動作してもよい。すなわち、マクロメディア(登録商標)のフラッシュビデオ（ＦＬＶ）、マイクロソフト(登録商標)のアドバンストストリーミングフォーマット（ＡＳＦ）、ウィンドウズ(登録商標)メディアオーディオ（ＷＭＡ）、ウィンドウズ（登録商標）メディアファイルオーディオ／ビデオ（“ＷＭＶ”）、オーディオ・ビデオ・インターリーブ（ＡＶＩ）、ＤｉｖＸ(登録商標)、インテル(登録商標)ビデオテクノロジー（ＩＶＦ）、クイックタイムムービーファイル拡張（ＭＯＶ）、ＭＰＥＧ、Ｒｅａｌ Ｍｅｄｉａ、Ｒｅａｌ Ａｕｄｉｏ、Ｒｅａｌ Ｐｌａｙｅｒ、Ｒｅａｌ Ｖｉｄｅｏ、Ｖｉｖｏ Ｖｉｄｅｏ（ＶＩＶ）、ＯＧＧ、Ｍａｔｒｏｓｋａ、３ｇｐ、ＮＵＴ、ＭＸＦ、ｒａｔＤＶＤ、ｓｖｉ等である。本発明と一貫した実施形態は、他のビデオファイルフォーマットとともに動作してもよい。
【0023】
“ドキュメント情報”は、ドキュメントに含まれる任意の情報、（“ドキュメント導出情報”と呼ばれる）ドキュメント中に含まれる情報から導出することができる情報、および／または（“ドキュメント関連情報”と呼ばれる）ドキュメントに関連する情報、とともに、このような情報の拡張（例えば、関連情報から導出される情報）も含んでいてもよい。ドキュメント導出情報の例は、ドキュメントのテキスト書き起こしのまたはオーディオ／ビデオのコンテンツに基づいた分類である。ドキュメント関連情報の例は、当該ドキュメントにリンクする、他のドキュメントからのドキュメント情報、とともに、当該ドキュメントがリンクする、他のドキュメントからのドキュメント情報も含む。
【0024】
ドキュメントからのコンテンツは、“コンテンツレンダリングアプリケーションまたはデバイス”上でレンダリングされてよい。コンテンツレンダリングアプリケーションの例は、インターネットブラウザ（例えば、エクスプローラ（登録商標）またはネットスケープ、オペラ（登録商標）、ファイアフォックス等）、メディアプレーヤ（例えば、ＭＰ３プレーヤ、ワシントン州、レッドモンドのマイクロソフトコーポレーションによるストリーミングメディアファイルプレーヤ、または、ワシントン州、シアトルのＲｅａｌ Ｎｅｔｗｏｒｋｓ，Ｉｎｃ．による、カリフォルニア州、キューパーティーノのアップルコンピュータ社による、カリフォルニア州、サンフランシスコのマクロメディア社によるストリーミングメディアファイルプレーヤ等）、ビューワ（例えば、アドビアクロバット（登録商標）ｐｄｆリーダ）等を含む。コンテンツレンダリングデバイスの例は、ビデオゲーム（例えば、ソニー(登録商標)プレイステーションＩＩ(登録商標)およびＰＳＰ(登録商標)、マイクロソフトＸ−Ｂｏｘ(登録商標)、任天堂(登録商標)ゲームキューブ(登録商標)等）、移動体電話機、テレビジョン、ラジオ、セットトップボックス（ＳＴＢ）等を含む。
【0025】
“コンテンツオーナ”は、メディアプロパティ（例えば、ドキュメント）のコンテンツに何らかの財産権を有する人物またはエンティティである。コンテンツオーナはコンテンツの著者であってよい。加えて、または代わりに、コンテンツオーナはコンテンツを再生する権利、コンテンツの派生作品を作成する権利、コンテンツを公表するもしくは公演する権利、および／またはコンテンツにおける他の禁止された権利を持っていてもよい。コンテンツサーバは、それが供給するドキュメントのコンテンツ中のコンテンツオーナである可能性があるが、これは必須ではない。“ウェブ発行者”は、コンテンツオーナの一例である。
【0026】
“ユーザ情報”はユーザ挙動情報、および／またはユーザプロファイル情報を含んでいてもよい。
【0027】
“ｅ−メール情報”は、（“内部ｅ−メール情報”とも呼ばれる）ｅ−メールに含まれる情報や、ｅ−メールに含まれる情報から導出することのできる情報、および／またはｅ−メールに関連する情報、とともに、このような情報の拡張（例えば、関連情報から導出される情報）も含んでいてもよい。ｅ−メール情報から導出される情報の例は、ｅ−メールの件名から抽出された用語で構成された検索クエリに応答して戻された検索結果から抽出されまたはそうでなければ導出された情報である。ｅ−メール情報に関連する情報の例は、所定のｅ−メールと同じ送信者によって送信される１つ以上の他のｅ−メールについてのｅ−メール情報、またはｅ−メール受取人についてのユーザ情報を含む。ｅ−メール情報から導出される、またはｅ−メール情報に関連する情報を“外部ｅ−メール情報”と呼ぶことがある。
【0028】
セクション４．２ その中で本発明と一貫した実施形態が動作し得る、あるいはそれを用いて本発明と一貫した実施形態が動作し得る例示的環境 図１はビデオコンテンツを配信し、受信することができるさまざまな方法を図示する図である。さまざまなクライアントロケーションにおいて、例えば、（コンピュータ、ビデオプレーヤ、テレビジョン等を含んでもよい、家庭住居、または企業のような）顧客の建物１１１、ビデオ機能を備える移動体電話機１１２、オーディオプレーヤ１１３、ラップトップコンピュータ１１４、カービデオプレーヤ１１５等のような、さまざまなデバイス１１０を使用して、ビデオコンテンツを消費することができる。例えば、衛星１４２を通して、地上波テレビジョン、（またはデータ）送信局１２０、ケーブルテレビジョン（またはデータ）送信局１３０、衛星テレビジョン（またはデータ）送信局１４０から；例えば、インターネットのようなネットワーク１６０を通して、ビデオコンテンツサーバ（例えば、ウェブキャスティングサーバ、ポッドキャスティングサーバ、ビデオストリーミングサーバ、ビデオダウンロードウェブサイト等）１５０から；例えば、公衆電話交換ネットワーク（“ＰＳＴＮ”）、およびインターネットのようなネットワーク１６０を通して、テレビ電話サービスプロバイダ１７０から；のようにさまざまな情報源からビデオコンテンツを送信してもよい。すべての接続を示しているわけではないが、１つ以上の送信局１２０、１３０、および１４０が、ネットワーク１６０に結合されていてもよい。
【0029】
図２は広告環境の図である。環境は、（単に広告サーバとして呼ぶ）広告エントリ、メンテナンス、および配信システム２２０を含む。広告主２１０は、システム２２０において、直接的にまたは間接的に広告情報を入力し、維持し、および追跡する。広告はいわゆるバナー広告のようなグラフィック広告、テキストのみの広告、画像広告、オーディオ広告、ビデオ広告、このような任意のコンポーネントの１つ以上の組み合わせの広告等の形態であってもよい。広告はまた、リンク、電話番号、ｅ−メールアドレスのような埋め込み情報、および／または、機械実行可能命令を含んでいてもよい。広告消費者２３０は、システム２２０に広告に対する要求を出してもよく、広告消費者２３０の要求に応答した広告をシステム２２０から受け入れてもよく、システム２２０に対して利用情報を提供してもよい。広告消費者２３０以外のエンティティが広告に対する要求を開始してもよい。示していないが、他のエンティティが、利用情報（例えば、広告に関連するコンバージョンまたは選択が発生したか否か）をシステム２２０に対して提供してもよい。この利用情報は、供給された広告に関連して、測定または観察されたユーザの挙動を含んでいてもよい。
【0030】
広告サーバ２２０は、‘９００出願で説明したものと類似していてもよく、‘９００出願で説明したものと類似した特徴を持っていてもよい。広告プログラムは、アカウント、キャンペーン、クリエイティブ、ターゲット等に関する情報を含んでいてもよい。用語“アカウント”は、所定の広告主に対する情報（例えば、一意的なｅ−メールアドレス、パスワード、請求書発行情報等）に関連する。“キャンペーン”または“広告キャンペーン”は、１つ以上の広告の１つ以上のグループを指し、開始日、終了日、予算情報、地理的ターゲット情報、企業組合情報等を含んでいてもよい。例えば、ホンダ（登録商標）は、その自動車ラインに対して１つの広告キャンペーンを、そして、そのオートバイラインに対して別の広告キャンペーンを持っていてもよい。その自動車ラインに対する広告キャンペーンは、それぞれが１つ以上の広告を含む、１つ以上の広告グループを持っていてもよい。それぞれの広告グループは、（例えば、１組のキーワード、１つ以上のトピックの組等の）ターゲット情報、および価格情報（例えば、（インプレッション毎、選択毎、コンバージョン毎の費用等の）費用、平均費用、または最大費用）を含んでいてもよい。したがって、単一費用、単一の最大費用、および／または単一の平均費用が、１つ以上のキーワードおよび／またはトピックに関係付けられてもよい。上に述べたように、それぞれの広告グループは１つ以上の広告または“クリエイティブ”（すなわち、エンドユーザに対して最終的にレンダリングされる広告コンテンツ）を持っていてもよい。それぞれの広告は、（例えば、広告主のホームページのようなランディングウェブページ、または、特定の製品もしくはサーバに関係付けられたウェブページ等の）ＵＲＬに対するリンクを含んでいてもよい。代わりに、または、加えて、それぞれの広告は、（例えば、製品またはサービス情報を提供するのを容易にするために、または注文を完了するのを容易にするために）電話通話を開始するための埋め込まれた情報を含んでもよい。代わりに、または、加えて、それぞれの広告は、（例えば、製品またはサービス情報を提供するのを容易にするために、または注文を完了するのを容易にするために）メッセージを開始するための情報を含んでもよい。広告情報は、より多くのまたはより少ない情報を含んでいてもよく、さまざまな異なる方法で組織化されてもよいのは当然である。
【0031】
図３は、その中で本発明を使用してもよい環境３００を図示する。（“クライアント”または“クライアントデバイス”としても呼んでもよい）ユーザデバイス３５０は、メディアプレーヤ（例えば、ＭＰ３プレーヤ、ストリーミングオーディオプレーヤ、ストリーミングビデオプレーヤ、テレビジョン、コンピュータ、移動体デバイス等）；（マイクロソフトによるエクスプローラブラウザ、ノルウェイのオペラソフトウェア(登録商標)によるオペラウェブブラウザ、またはＡＯＬ／タイムワーナー(登録商標)によるナビゲータブラウザ、モジラ(登録商標)からのファイアフォックスブラウザ等のような）ブラウザ機構；ｅ−メール機構（例えば、マイクロソフトによるアウトルック（登録商標））；テレフォニー手段等を含んでいてもよい。検索エンジン３２０は、ユーザデバイス３５０がドキュメントの収集物（例えば、ウェブページ）を検索できるようにしてもよい。コンテンツサーバ３３０は、ユーザデバイス３５０が、例えば、（グーグルビデオ（登録商標)においてホスト管理され、利用可能なビデオのような）ビデオドキュメントのようなドキュメントにアクセスするのを許容してもよい。（グーグルからのＧＭａｉｌ(登録商標)、マイクロソフトネットワークからのホットメール(登録商標)、ヤフーメール等のような）ｅ−メールサーバ３４０を使用して、ユーザデバイス３５０に対してｅ−メール機能を提供してもよい。ｅ−メールはビデオ添付物および／またはビデオメッセージを含んでもよい。広告サーバ３１０を使用して、ユーザデバイス３５０に広告を供給してもよい。検索エンジン３２０により提供される検索結果に関係して、広告を供給してもよい。しかしながら、コンテンツ関連広告は、コンテンツサーバ３３０により提供されるコンテンツ；ｅ−メールサーバ３４０、および／または、ユーザデバイスのｅ−メール機構によりサポートされるｅ−メール（もしくは、ボイスメールサーバによりサポートされるボイスメール）；ビデオサーバ３６０により供給され、および／またはユーザデバイスビデオプレーヤ機構により再生されるビデオコンテンツ；に関係して供給されてもよい。テレビ電話サービスプロバイダ機構３７０を使用して、ネットワーク３６０を通して、テレビ電話またはビデオウォーキートーキーサービスを提供してもよい。例えば、ボイスオーバーインターネットプロトコル（“ＶｏＩＰ”）サービスを提供する会社もある。
【0032】
‘９００出願で説明したように、広告はコンテンツサーバにより供給されるドキュメントにターゲット付けされていてもよい。したがって、広告消費者２３０の一例は、（例えば、記事、議論スレッド、音楽、オーディオ、ビデオ（例えば、テレビジョン番組、音楽ビデオ、ビデオメール、ストリームされたビデオファイル等）、グラフィック、検索結果、ウェブページリスト等の）ドキュメントに対する要求を受信し、要求に応答して要求されたドキュメントを取得し、そうでなければ要求に対してサービスする、一般的なコンテンツサーバ３３０である。コンテンツサーバは（例えば、要求に必ずしも対応せずに）コンテンツをブロードキャストしてもよい。コンテンツサーバは広告サーバ２２０／３１０に向けて広告に対する要求を出す。このような広告要求は、広告スポット情報（例えば、所望される広告数、継続時間、適格性のある広告のタイプ等）を含んでいてもよい。広告要求はドキュメント要求情報も含んでいてもよい。この情報は、ドキュメント自体（例えば、ページ、ビデオファイル、ビデオストリームのセグメント等）、ドキュメントのコンテンツまたはドキュメント要求に対応しているカテゴリまたはトピック（例えば、芸術、ビジネス、コンピュータ、芸術−映画、芸術−音楽等）、ドキュメント要求の一部または全部、コンテンツ経年数、コンテンツタイプ（例えば、テキスト、グラフィック、ビデオ、オーディオ、混合メディア等）、地理的ロケーション情報、ドキュメント情報等を含んでいてもよい。
【0033】
コンテンツサーバ３３０は、（例えば、要求された）ドキュメントを、広告サーバ２２０／３１０により提供される１つ以上の広告と結合してもよい。ドキュメントコンテンツと広告とを含んでいるこの結合された情報は、次に、ユーザに対して提示するために、ドキュメントを要求した、または、ドキュメントを受信するようにエンドユーザデバイス自体が構成されている、エンドユーザデバイス３５０に向けて転送される。最後に、コンテンツサーバ３３０は、広告についての情報と、広告がどのように、いつ、および／またはどこでレンダリングされたのかについての（例えば、広告スポット、位置、選択が発生したか否か、インプレッション時間、インプレッション日付、サイズ、時間長、量、コンバージョンが発生したか否か等の）情報とを広告サーバ２２０／３１０に返信してもよい。代わりに、または、加えて、他の任意の手段でこのような情報を広告サーバ２２０／３１０に戻してもよい。
【0034】
オフラインコンテンツプロバイダ３３２は、これから出てくる発行物における広告スポットについての情報、および、おそらくは発行物についての情報（例えば、コンテンツ、または、コンテンツのトピックもしくは概念）を広告サーバ３１０に対して提供してもよい。応答して、広告サーバ３１０は、少なくともいくつかの広告スポットに対して、発行物のコンテンツに関連性のある１組の広告を提供してもよい。オフラインコンテンツプロバイダ３３２の例は、例えば、雑誌発行者、新聞発行者、書籍発行者、オフラインブロードキャスト、オフライン音楽発行者、オフラインビデオゲーム発行者、劇プロダクション、コンサート、スポーツイベント等を含む。
【0035】
オフライン広告スポットプロパティ３３４のオーナは、彼らのオフラインプロパティにおける広告スポット（例えば、テキサス州、サンアントニオにおけるＮＢＡゲームのためのJumboTron(登録商標)、ProStar(登録商標)、DiamondVision(登録商標)、AstroVision(登録商標)、SmartVision(登録商標)ビデオ広告）についての情報を提供してもよい。応答して、広告サーバは、少なくともいくつかの広告スポットに対するプロパティに関連性のある１組の広告を提供してもよい。オフラインプロパティ３３４の例は、例えば、電光掲示板、スタジアムスコアボード、および外野壁、トラックトレーラーの側面等を含む。
【0036】
広告消費者２３０の別の例は、検索エンジン３２０である。検索エンジン３２０は、検索結果のためのクエリを受け取ってもよい。応答して、検索エンジンは（例えば、ウェブページのインデックスから）関連性のある検索結果を取得してもよい。例示的な検索エンジンは、S.Brin氏およびL.Page氏により、オーストラリア、ブリズベン、第７回国際ワールドワイドウェブ会議において発表された論文“大規模ハイパーテキストの検索エンジンに関する解剖”、および、米国特許第6,285,999号（これらの両方はここで参照によってその全体が組み込まれている）に説明されている。このような検索結果は、例えば、ウェブページタイトルのリスト、これらのウェブページから抽出されたテキストの一部分、および、これらのウェブページに対するハイパーテキストリンクを含んでいてもよく、予め定められた数（例えば、１０）の検索結果へとグループ化されてもよい。
【0037】
検索エンジン３２０は広告サーバ２２０／３１０に要求を出してもよい。要求は、所望される広告数を含んでいてもよい。この数は、検索結果、検索結果により占められる画面の分量またはページ空間、広告のサイズおよび形状等に依拠していてもよい。１つの実施形態では、所望される広告数は１から１０、好ましくは３から５であるだろう。広告に対する要求は、（入力され、または構文解析された）クエリ、（地理的ロケーション情報、アフェリエイトからクエリが来たか否か、およびこのようなアフェリエイトの識別子のような）クエリに基づいた情報、検索結果に関係した情報、または検索結果に基づいた情報を含んでいてもよい。このような情報は、例えば、検索結果に関連した識別子（例えば、ドキュメント識別子すなわち“ｄｏｃＩＤ”）、検索結果に関連したスコア（例えば、クエリおよびドキュメントに対応した特徴ベクトルの内積のような情報検索（“ＩＲ”）スコア、ページランクスコア、および／または、ＩＲスコアとページランクスコアの組み合わせ等）、識別されたドキュメント（例えば、ウェブページ）から抽出されたテキストの一部分、識別されたドキュメントの全文テキスト、識別されたドキュメントのトピック、識別されたドキュメントの特徴ベクトル等を含んでいてもよい。
【0038】
検索エンジン３２０は、検索結果を、広告サーバ２２０／３１０により提供される１つ以上の広告と結合してもよい。検索結果と広告とを含んでいるこの結合された情報は、次に、ユーザに対して提示するために、検索を行ったユーザに向けて転送される。有料の広告と、おそらくは中立的な検索結果との間でユーザが混乱することのないように、好ましくは、広告とは別個のものとして検索結果が維持される。
【0039】
最後に、検索エンジン３２０は、広告についての情報と、広告がいつ、どこで、および／またはどのようにレンダリングされたのかについての（例えば、位置、選択が発生したか否か、インプレッション時間、インプレッション曜日、サイズ、コンバージョンが発生したのか否か等の）情報とを広告サーバ２２０／３１０に返信してもよい。代わりに、または、加えて、他の任意の手段でこのような情報を広告サーバ２２０／３１０に提供し戻してもよい。
【0040】
ｅ−メールサーバ３４０は、一般的に、ドキュメントが供給されるコンテンツサーバとして考えられてもよいが、その場合、供給されるコンテンツは単にｅ−メールであってもよい。さらに、ｅ−メールを送受信するために、（例えば、マイクロソフトのアウトルックのような）ｅ−メールアプリケーションを使用してもよい。したがって、ｅ−メールサーバ３４０、またはアプリケーションは、広告消費者２３０として考えられてもよい。したがって、ｅ−メールはドキュメントであるとして考えてもよく、ターゲット付けされた広告がこのようなドキュメントに関係して供給されてもよい。例えば、１つ以上の広告がｅ−メール中で、ｅ−メール上で、そうでなければｅ−メールに関係して供給されてもよい。示していないが、一般的に、ビデオ−ボイスメールサーバはコンテンツサーバとして考えられてもよい。
【0041】
一般的に、ビデオサーバ３６０はコンテンツサーバとして考えられてもよく、ここで供給されるドキュメントは、単に、例えば、ビデオストリームまたはビデオファイルのようなビデオドキュメントである。さらに、（ＲｅａｌＮｅｔｗｏｒｋのリアルメディアプレーヤ、マイクロソフトのメディアプレーヤ、アップルのクイックタイムプレーヤ、マクロメディアのフラッシュプレーヤ等のような）ビデオプレーヤアプリケーションを使用して、ビデオファイルをレンダリングしてもよい。したがって、ビデオサーバ３６０またはアプリケーションは、広告消費者２３０として考えられてもよい。したがって、ビデオドキュメントに関係して、広告を供給してもよい。例えば、音楽ビデオ、番組、番組セグメントの前に、音楽ビデオ、番組、番組セグメントの間に、または音楽ビデオ、番組、番組セグメントの後等に、１つ以上の広告を供給してもよい。代わりに、音楽ビデオ、番組、番組セグメント等に関係して、１つ以上の広告を供給してもよい。
【0042】
最後に、テレビ電話サービスプロバイダ機構３７０もまた、テレビ電話の会話のトピックに関連する広告のような広告を消費してもよい。
【0043】
上記の説明は、（ｉ）広告を要求し、（ｉｉ）広告をコンテンツと結合する、としてサーバを説明したが、これらの動作のうちの１つまたは両方が、（例えばエンドユーザのコンピュータのような）クライアントデバイスによって実行されてもよい。
【0044】
セクション４．３ 例示的な実施形態 図４は、本発明と一貫した方法で実行してもよい、例示的な動作と、このような動作により使用してもよい、および／または発生させてもよい情報とのデータフロー図である。動作は、例えば、関連性情報の決定および／または抽出動作４１０、広告スポット決定動作４２０、関連広告決定動作４４０、広告主課金／請求書発行動作４５０、広告情報のエントリおよび管理動作４５５、広告ユーザフィードバック追跡動作４６０、広告アービトレーション動作４７０、ならびに、広告配信（例えば、挿入）動作４８０のうちの１つ以上を含む。情報は、ビデオドキュメント関連性情報４１５、広告スポット情報４３０、および広告情報４４５を含んでもよい。
【0045】
関連性情報の決定および／または抽出動作４１０は、ビデオコンテンツ（および、おそらくは、ビデオドキュメント識別子）４０５を受け入れてもよく、そして、ビデオドキュメント関連性情報４１５を発生させる。このような関連性情報の決定および／または抽出動作４１０を実行するための例示的な方法を、以下で図８を参照して説明する。このようなビデオドキュメント関連性情報４１５を記憶するための例示的なデータ構造を、以下で図５を参照して説明する。
【0046】
広告スポット決定動作４２０は、ビデオコンテンツ４０５および／またはビデオ発行者提供された広告スポット情報４２５を受け入れてもよく、広告スポット情報４３０を発生させてもよい。このような広告スポット決定動作４２０を実行するための例示的な方法を、以下で図９を参照して説明する。このような広告スポット情報４３０を記憶するための例示的なデータ構造を、以下で図６を参照して説明する。
【0047】
関連広告決定動作４４０は、ビデオドキュメント関連性情報４１５、広告スポット情報４３０、および広告情報４４５（および、おそらくは他の関連性情報）を使用して、１つ以上の関連広告４６５を発生させてもよい。関連広告決定動作４４０を実行するための例示的な方法を、以下で図１０を参照して説明する。広告情報を記憶するための例示的なデータ構造を、以下で図７を参照して説明する。
【0048】
広告アービトレーション動作４７０は、広告情報４４５を使用して、関連広告４６５をスコア付けし、関連広告の広告スポットに対する関連付け４７５を発生させてもよい。広告アービトレーション動作４７０を実行するための例示的な方法を、以下で図１１を参照して説明する。
【0049】
広告配信動作４８０は、広告、広告スポット関連付け４７５を受け入れてもよく、ビデオコンテンツ４０５に関連して（例えば、広告をビデオコンテンツ中に挿入して）広告を供給する。例えば、ミキサーを使用して、ビデオ広告を、ビデオドキュメントの適切な部分（例えば、広告スポット）に結合させてもよい。このような挿入は、例えば、ビデオコンテンツサーバにおいて、および／または、クライアントデバイスにおいて発生してもよい。
【0050】
広告主課金／請求書発行動作４５０、広告情報のエントリおよび管理動作４５５、ならびに、広告ユーザフィードバック追跡動作４６０は、‘４２７出願および‘９００出願において説明した技術を使用して実行されてもよく、ならびに／あるいは、当業者に周知の技術を使用してもよい。
【0051】
セクション４．３．１ 例示的な方法とデータ構造 図８は、本発明と一貫した方法で、ビデオドキュメント（または、そのセグメント）に対する関連性情報を抽出および／または決定するための例示的な方法８００のフロー図である。ビデオドキュメントからのビデオおよび／またはオーディオコンテンツを解析して、テキストの情報を導出する（ブロック８１０）。次に、テキストの情報を解析して、関連性情報を発生させ（ブロック８２０）、この後に、方法８００は終了する（ノード８３０）。
【0052】
戻って、ブロック８１０を参照すると、さまざまなオーディオ提供物上でスピーチ認識を実行すること、信頼度スコアで注釈が付けられた仮定の単語を生成すること、または、多くの仮定を含む格子を生成する（したがって、キーワードを取りそこなう可能性が低くなる）ことによって、オーディオ−ビデオドキュメント中のオーディオ情報からテキスト情報を導出する。周知の自動スピーチ認識技術によって、オーディオをテキストに変換することが達成できる。（例えば、ここで参照としてその全体が組み込まれる、Kai-Fu Lee氏による“自動スピーチ認識−−ＳＰＨＩＮＸシステムの開発”、クルワーアカデミック出版、マサチューセッツ州、ノーウェル、１９８９年を参照のこと。）一度（例えば、大まかな）書き起こしが利用可能になると、関連性情報（例えば、用語、重み付けされた用語、概念、重み付けされた概念、カテゴリ（例えば、垂直型カテゴリ）、重み付けされたカテゴリ等）が、書き起こしから導出されてもよく、そして、関連広告を選択するのに使用されてもよい。現在のスピーチ認識技術は、あるエンドユーザアプリケーションに対しては十分に正確ではないが、現在のスピーチ認識技術は、大まかな書き起こしを提供するためには十分であり、大まかな書き起こしから、オーディオドキュメントの要旨（すなわち、トピック）を決定することができる。
【0053】
代わりに、または、加えて、コンテンツオーナがそのビデオコンテンツについてのメタデータを提供してもよい。このようなメタデータは、例えば、タイトル、記述、書き起こし、トリビューンメタデータ、推奨される閲覧人口統計等を含んでもよい。
【0054】
ブロック８２０を参照すると、‘４２７および‘９００出願において説明したもののような、ならびに、以下の特許出願等において説明したもののようなさまざまな技術を使用して、テキストの情報を解析して、関連性情報を発生させてもよい。２００５年４月２２日に出願され、“カテゴリ化から導出した、タクソノミーおよびデータ構造に関して、ドキュメントおよび／またはクラスタのようなオブジェクトをカテゴリ化すること”と題され、David Gehrking 氏、Ching Law 氏、およびAndrew Maxwell氏を発明者として記載する、（ここに参照によりその全体が組み込まれ、“‘７１６出願”として呼ばれる）、米国特許出願シリアル番号第11/112,716号。関連性情報は、例えば、１つ以上の用語ベクトル、重み付けされた用語ベクトル、クラスタ、重み付けされたクラスタ、カテゴリ（例えば、垂直型カテゴリ）、重み付けされたカテゴリ等を含んでもよい。クラスタは、２００２年１０月３日に出願され、“確率論的階層推論学習者のための方法および装置”と題され、（ “‘１４４仮”として呼ばれ、ここに参照によりその全体が組み込まれる）、米国仮特許出願シリアル番号第60/416,144号；ならびに、２００３年９月３０日に出願され、“クラスタ関連単語に基づいて、ドキュメントを特徴付けするための方法および装置”と題され、Georges Herik 氏、およびNoam Shazeer氏を発明者として記載する、（“‘５７１出願”として呼ばれ、ここに参照によりその全体が組み込まれる）米国特許出願シリアル番号第10/676,571号；に説明したもののような、確率論的階層推論学習者（“ＰＨＩＬ”として呼ぶ）クラスタであってもよい。例えば、‘１４４仮および‘５７１出願において説明した技術を使用して、このようなＰＨＩＬクラスタを発生させてもよい。テキストの情報の情報源は、ブロック８１０中でのように、オーディオコンテンツの解析から導出されたものであってもよく、および／または、コンテンツオーナによって提供されたメタデータであってもよい。
【0055】
代わりに、または、加えて、ビデオ発行者（または他の何らかのエンティティ）は、テキストの情報でビデオドキュメントに注釈を付けてもよく、または、ビデオコンテンツ（例えば、パケット、パケットの一部、ストリームの一部、ヘッダ、フッタ等）中にテキストの情報をエンコードしてもよい。例えば、ビデオ放送者は、彼らのブロードキャスト中で、局識別子、番組識別子、ロケーション情報等を提供してもよい。このケースでは、ジャンルおよびロケーション情報は、ビデオブロードキャストから導出されるかもしれない。このような関連性情報を使用して、関連広告をターゲット付けしてもよい。別の例として、ビデオディスクは、映画についての情報、例えば、タイトル、俳優および女優、ディレクター、シーン等をエンコードしてもよい。このような情報を使用して、映画のテキストの書き起こしをルックアップしてもよい。さらに別の例として、ビデオに対する要求が、関係するＩＰアドレスを有していてもよく、このＩＰアドレスからロケーション情報を導出できる。さらに別の例として、番組は、キーワード、トピック等で注釈を付けてもよい。このような関連性情報を使用して、関連広告をターゲット付けしてもよい。
【0056】
代わりに、または、加えて、オーディオ−ビデオドキュメント中のオーディオ情報を解析して、他のタイプの関連性情報を発生させてもよい。例えば、オーディオ解析から、発話者の属性を決定してもよい（例えば、M.A.Siegler氏、U.Jain氏、B.Raj氏、およびR.M.Stern氏による、“ブロードキャストニュースオーディオの自動的セグメント化、分類、およびクラスタリング”第９回口語システム技術ワークショップのプロシーディング、ニューヨーク州、ハーリマン、１９９６年；ならびに、Greg Sanders氏による“耳のためのメタデータ抽出５”、リッチ書き起こしワークショップ、バージニア州、ヴィエナ、２００２年；を参照のこと（これらの両方はここで参照によりその全体が組み込まれている）。）。
【0057】
図５は、本発明と一貫した方法で、ビデオドキュメント関連性情報を記憶するための例示的なデータ構造５００を図示する。示したように、データ構造５００は、複数の行に対応する複数のエントリを含んでもよい。各エントリは、ビデオドキュメント識別子５１０と、関連性情報５２０とを含んでいてもよい。関連性情報は、用語、重み付けされた用語、概念、重み付けされた概念、クラスタ、重み付けされたクラスタ、垂直型カテゴリ、重み付けされた垂直型カテゴリ、ロケーション情報、ユーザ情報等のうちの１つ以上を含んでもよい。
【0058】
図９は、本発明と一貫した方法で、広告スポットを決定するための例示的な方法９００のフロー図である。ビデオドキュメント発行者が、広告スポット情報を提供したか否かを決定してもよい（決定ブロック９１０）。すなわち、広告スポット情報は、ドキュメントに関係付けられていてもよいが、ドキュメントとは別々に（すなわち、ドキュメント中に含まれずに）提供されてもよい。そうである場合、提供された広告スポット情報を使用してもよく、および／または後で使用するために保存してもよく（ブロック９２０）、その後、方法９００は終了する（ノード９５０）。戻って、決定ブロック９１０を参照すると、発行者、または他の何らかのエンティティが、広告スポット情報を提供しなかった場合、ビデオドキュメントを解析して、広告スポット情報を決定してもよい（ブロック９３０）。次に、決定された広告スポット情報を使用してもよく、および／または後で使用するために保存してもよく（ブロック９４０）、その後、方法９００は終了する（ノード９５０）。
【0059】
戻って、ブロック９２０を参照すると、ビデオ発行者、または、他の何らかのエンティティは、広告スポットが開始するときの絶対的または相対的時間を提供してもよい。発行者または他の何らかのエンティティは、継続時間または広告スポットが終了するときの時間をさらに提供してもよい。例えば、ビデオ発行者は、第１の広告スポットが東部標準時の午前８：２０に開始して、２分間続くことと；第２の広告スポットが東部標準時の午前８：４０に開始して、４分間続くことと；第３の広告スポットが８：５２に開始して、６分間続くこととを指定してもよい。別の例として、ビデオ発行者は、東部標準時の午前８：００に開始して、３０分毎に３分間の広告スポットが発生することを指定してもよい。さらに別の例として、ビデオ発行者は、ビデオ番組の開始後１５分毎に２分間の広告スポットが発生することと、ビデオ番組中の５０分毎に４分間の広告スポットが発生することとを指定してもよい。
【0060】
戻ってブロック９３０を参照すると、ビデオドキュメント自体を解析して、広告スポット情報を決定してもよい。すなわち、広告スポット情報は、ビデオドキュメント自体の中で搬送されてもよい。例えば、オーディオ−ビデオ番組内に埋め込まれたマーカー（例えば、オーディオトーン）は、Ｘ秒の広告スポットが、Ｙ秒に開始することをエンコードしてもよい。別の例として、ビデオストリームのパケットまたはコンテナファイル中で搬送されるデータが、広告スポット情報を指定してもよい。
【0061】
図６は、本発明と一貫した方法で、広告スポット情報を記憶するための例示的なデータ構造６００を図示する。示したように、データ構造６００は、複数の行に対応した複数のエントリを含んでもよい。各エントリは、広告スポット識別子６１０と、広告スポット情報６２０とを含んでもよい。広告スポット識別子６１０は、広告スポットが所属するビデオドキュメント識別子を含んでもよい。広告スポット情報６２０は、いつ広告スポットを発生させるかに関連する情報（例えば、開始日付、時間、および継続時間；開始日付・時間および終了日付・時間；基準時間からの、開始時間および継続時間；基準時間からの、開始時間および終了時間；等）を含んでいてもよい。さらに、広告スポット情報は、フィルタのようなポリシー情報を含んでもよい。１つのクラスのフィルタは、広告のコンテンツに基づいて、広告をフィルタするものを含んでいてもよい。例えば、健康的な生活に関するビデオ番組は、タバコのための広告をフィルタ除外するかもしれない。別の例として、子供用ビデオ番組は、わいせつな、または、きわどい言語を含む広告をフィルタ除外するかもしれない。さらに別の例として、ギャンブル依存症を取り扱うビデオ番組は、カジノのための広告をフィルタ除外してもよい。別のクラスのフィルタは、広告の情報源に基づいて、フィルタするものを含んでもよい。例えば、インターネットラジオ局は、競合するインターネットテレビジョン局の番組のための広告をブロックするかもしれない。例えば、以下の特許出願において説明したもののような、広告ポリシーを実現するための、他の技術を使用してもよい。２００３年９月５日に出願され、“ドキュメント特有の競合広告のような広告を識別および／またはブロックすること”と題され、Brian Axe氏、Rama Ranganath氏、およびNarayanan Shivakumar氏を発明者として記載する、（ここに参照によりその全体が組み込まれ、“‘９１７出願”として呼ばれる）米国特許出願シリアル番号第10/656,917号。
【0062】
広告スポット情報６２０はまた、例えば、広告スポットを含むビデオ番組の情報源ロケーション、広告スポットを含むビデオ番組を受信しているクライアントデバイスのロケーション、広告スポットを含むビデオ番組を受信しているクライアントデバイスタイプ、のうちの１つ以上のような情報も含んでもよい。
【0063】
上で説明した、いくつかの例示的な広告スポットは、明確な長さを持っていたが、広告は、固定または定められた長さを必ずしも持つ必要はない。例えば、ディスプレイ画面を有するメディアプレーヤの状況では、ビデオ番組を中断することなく（例えば、広告主によって規定された時間期間に対して、ビデオ発行者によって規定された時間の期間に対して、次の広告スポットまで等に）テキスト広告を表示してもよい。
【0064】
図１０は、本発明と一貫した方法で、ビデオドキュメント中の広告スポットに関連する広告を決定するための例示的な方法１０００のフロー図である。示したように、例えば、図５のデータ構造５００中に記憶されたもののような、ビデオドキュメント関連性情報を受け入れてもよい（ブロック１０１０）。代わりに、または、加えて、ビデオドキュメント情報源ロケーション、クライアントデバイスロケーション、クライアントデバイスタイプ、時間、日付等のような広告スポット情報を受け入れてもよい（ブロック１０２０）。代わりに、または、加えて、例えば、１つ以上のエンドユーザ情報（例えば、過去の挙動、人口統計等）、情報源情報（例えば、スポーツ局、クラシック音楽局、ニュース局等）等のような、他の関連性情報を受け入れてもよい（ブロック１０３０）。次に、広告情報を解析して、ビデオドキュメント、広告スポット、および／または、他の関連性情報に関連する候補広告を決定してもよい（ブロック１０４０）。例えば、‘４２７および‘９００特許出願において説明したもののような技術を使用してもよい。次に、方法１００は終了する（ノード１０５０）。
【0065】
戻って、ブロック１０４０を参照すると、広告情報は、広告主により提供されたターゲット情報を含んでもよい。代わりに、または、加えて、広告情報は、広告クリエイティブから導出されたターゲット情報、および／または、広告ランディングページのような、広告に関係付けられた情報を含んでもよい。このようなターゲット情報は、キーワード、垂直型カテゴリ、ジャンル、概念、ビデオ番組識別子、ビデオサーバ識別子、ユーザ識別子、言語、局、ビデオサーバ、ユーザタイプ、ロケーション、時間、日付、クライアントデバイス、他の供給制約等のうちの１つ以上を含んでもよい。
【0066】
図１１は、本発明と一貫した方法で、ビデオドキュメント中の広告スポットに対して、競合する関連広告をアービトレートするための例示的な方法１１００のフロー図である。候補広告を受け入れる（ブロック１１１０）。各候補広告に対して、価格情報、および／または、性能情報を受け入れ（ブロック１１２０）、価格情報、および／または、性能情報を使用して、候補広告のそれぞれをスコア付けしてもよい（ブロック１１３０）。代わりに、または、加えて、スコアは、ビデオドキュメント（またはそのセグメント）に対する、広告の関連性の度合いを考慮してもよい。最後に、利用可能な広告スポットを満たすために、最高スコアリングの候補広告を選択して（ブロック１０４０）、その後で、方法１１００は終了する（ノード１１５０）。
【0067】
戻って、ブロック１１２０を参照すると、価格情報は、例えば、インプレッション毎の価格、インプレッション毎の最大価格、選択毎の価格、選択毎の最大価格、コンバージョン毎の価格、コンバージョン毎の最大価格等であってもよい。性能情報は、例えば、選択レート、コンバージョンレート、エンドユーザレーティング等であってもよい。
【0068】
戻って、ブロック１１３０を参照すると、例えば、以下の特許出願において説明した技術を使用して候補広告をスコア付けしてもよい。２００２年３月２９日に出願され、“性能情報に基づいた広告順序付けのための方法および装置”と題され、Georges R. Harik氏、Lawrence E. Page氏、Jane Manning氏、およびSalar Arta Kamangar氏を発明者として記載する、（ここに参照により組み込まれ、“‘６５６出願”として呼ばれる）米国特許出願シリアル番号第10/112,656号；２００２年３月２９日に出願され、“性能情報および価格情報に基づいた広告順序付けのための方法および装置”と題され、Salar Arta Kamangar氏、Ross Koningstein氏、およびEric Veach氏を発明者として記載する、（ここに参照によりその全体が組み込まれ、“‘６５４出願”として呼ばれる）米国特許出願シリアル番号第10/112,654号；２００３年６月２日に出願され、“ユーザ要求情報およびユーザ情報を使用した広告供給”と題され、Krishna Bharat氏、Stephan Lawrence氏、Mehran Sahami氏、およびAmit Singhal氏を発明者として記載する、（ここに参照によりその全体が組み込まれ、“‘７９１出願”として呼ばれる）米国特許出願シリアル番号第10/452,791号；２００３年６月３０日に出願され、“ユーザトピック関心情報を使用して、１つ以上のトピックを持つドキュメントとともに広告をレンダリングすること”と題され、Krishna Bharat氏を発明者として記載する、（ここに参照によりその全体が組み込まれ、“‘３２２出願”として呼ばれる）米国特許出願シリアル番号第10/610,322号；２００５年６月２８日に出願され、“広告供給決定における構成のユーティリティの使用”と題され、Amit Patel氏、およびHal Varian氏を発明者として記載する、（ここに参照によりその全体が組み込まれ、“‘３２３出願”として呼ばれる）米国特許出願シリアル番号第11/169,323号；２００４年１２月３０日に出願され、“通話機能性を備えたデバイスに対する広告のような、ローカルエリア広告の発生および／または供給”と題され、Shumeet Baluja氏、およびHenry A. Rowley氏を発明者として記載する、（ここに参照によりその全体が組み込まれ、“‘５０７出願”として呼ばれる）米国特許出願シリアル番号第11/026,507号；２００５年６月１８日に出願され、“コンテンツ関連広告を選択および／またはスコアリングすること”と題され、Darrell Anderson氏、Alexander Paul Carobus氏、Giao Nguyen氏、およびNarayanan Shivakumar氏を発明者として記載する、（ここに参照によりその全体が組み込まれ、“‘０５３出願”として呼ばれる）米国特許出願シリアル番号第11/184,053号；２００５年９月１６日に出願され、“異なる価値提示を有する広告主がこのような価値提示を広告システムに対して表現することを可能にする柔軟性のある広告システム”と題され、Sumit Agarwal氏、Gregory Joseph Badros氏、およびJohn Fu氏を発明者として記載する、（ここに参照によりその全体が組み込まれ、“‘５８３出願”として呼ばれる）米国特許出願シリアル番号第11/228,583号。
【0069】
図７は、本発明と一貫した方法で、広告情報を記憶するための例示的なデータ構造７００を図示する。示したように、データ構造７００は、複数の行に対応した複数のエントリを含んでもよい。各エントリは、広告識別子７１０、広告クリエイティブ７２０、ターゲット情報７３０、価格情報７４０、および／または性能情報７５０を含んでもよい。ターゲット情報７３０は、例えば、キーワード、垂直型カテゴリ、ジャンル、概念、ビデオ番組識別子、ビデオサーバ識別子、ユーザ識別子、ユーザタイプ、言語、局、ロケーション、時間、日付、クライアントデバイス、他の供給制約等のうちの１つ以上を含んでいてもよい。ターゲット情報７３０は、広告主によって提供されてもよい。代わりに、または、加えて、ターゲット情報７３０は、広告クリエイティブ、および／または広告ランディングページのような、広告に関係付けられた情報から導出されてもよい。価格情報７４０は、例えば、インプレッション毎の価格、インプレッション毎の最大価格、選択毎の価格、選択毎の最大価格、コンバージョン毎の価格、コンバージョン毎の最大価格等であってもよい。性能情報７５０は、例えば、選択レート、コールスルーレート、メッセージスルーレート、コンバージョンレート、エンドユーザレーティング等であってもよい。
【0070】
セクション４．３．２ 例示的な装置 図１２は、本発明と一貫した方法で、少なくともいくつかの動作を実行し、少なくともいくつかの情報を記憶するのに使用してもよい装置１２００のブロック図である。装置１２００は、基本的に１つ以上のプロセッサ１２１０、１つ以上の入力／出力インターフェイスユニット１２３０、１つ以上の記憶デバイス１２２０、ならびに、結合されたエレメント間での情報の通信を容易にするための１つ以上のシステムバスおよび／またはネットワーク１２４０を含む。１つ以上の入力デバイス１２３２および１つ以上の出力デバイス１２３４が、１つ以上の入力／出力インターフェイス１２３０と結合されていてもよい。
【0071】
１つ以上のプロセッサ１２１０は、本発明の１つ以上の観点を実行するために機械実行可能命令（例えば、カリフォルニア州、パロアルトのサンマイクロシステムズ社から入手できるソラリスオペレーティングシステム上で、または、ノースカロライナ州、ダーハムのレッドハット社のような多くのベンダから幅広く入手できるリナックス (登録商標)オペレーティングシステム上で実行するＣまたはＣ＋＋）を実行してもよい。少なくとも一部の機械実行可能命令を、１つ以上の記憶デバイス１２２０に（一時的に、もしくは、より恒久的に）記憶してもよく、および／または、１つ以上の入力インターフェイスユニット１２３０により外部情報源から受け取ってもよい。
【0072】
１つの実施形態では、機械１２００は１つ以上の従来のパーソナルコンピュータであってもよい。このケースでは、処理ユニット１２１０は１つ以上のマイクロプロセッサであってもよい。バス１２４０はシステムバスを含んでいてもよい。記憶デバイス１２２０は、リードオンリーメモリ（ＲＯＭ）および／またはランダムアクセスメモリ（ＲＡＭ）のようなシステムメモリを含んでいてもよい。記憶デバイス１２２０は、ハードディスクから読み取るための、またはハードディスクに書き込むためのハードディスクドライブや、（例えば、リムーバブル）磁気ディスクから読み取るための、または（例えば、リムーバブル）磁気ディスクに書き込むための磁気ディスクドライブ、および、コンパクトディスクもしくは他の（磁気）光学メディアのようなリムーバブル（磁気）光ディスクから読み取るための、またはコンパクトディスクもしくは他の（磁気）光学メディアのようなリムーバブル（磁気）光ディスクに書き込むための光ディスクドライブも含んでいてもよい。
【0073】
ユーザは、例えばキーボードおよびポインティングデバイス（例えば、マウス）のような入力デバイス１２３２を通して、パーソナルコンピュータにコマンドと情報を入力してよい。これには、マイク、ジョイスティック、ゲームパッド、パラボラアンテナ、スキャナ、またはこれらの均等物のような他の入力デバイスも（または、代わりに）含まれてよい。これらの、および他の入力デバイスは、システムバス１２４０に結合される適切なインターフェイス１２３０を通して処理ユニット１２１０に接続されることが多い。出力デバイス１２３４は、モニタ、または、適切なインターフェイスによりシステムバス１２４０に接続され得る他のタイプの表示デバイスを含んでよい。モニタに加えて（または、代わりに）、パーソナルコンピュータは、例えばスピーカとプリンタのような、他の（示していない）（周辺）出力デバイスを含んでよい。
【0074】
戻って、図３を参照して、１つ以上の機械１２００は、エンドユーザクライアントデバイス３５０、コンテンツサーバ３３０、オーディオコンテンツサーバ３６０、電話サービスプロバイダ機構３７０、検索エンジン３２０、ｅ−メール（もしくはｖ−メール）サーバ３４０、および／または、広告サーバ３１０として使用されてもよい。
【0075】
セクション４．３．３ 改良および代替物 戻って、図４の動作４１０を参照すると、ビデオドキュメントが供給（例えば、ブロードキャスト、マルチキャスト、ユニキャスト、転送等）される前に、ビデオ発行者によって、関連性情報を提供してもよい。ビデオドキュメントが予め保存されている（例えば、予め記録されている）場合、ビデオドキュメントを供給する前に、ビデオドキュメントを解析してもよく、（および、おそらく、供給および／または再生の間に再解析してもよい）。ビデオドキュメントがライブで供給されている場合、ビデオドキュメントが供給されているときに（おそらく、クライアントデバイスにおいてビデオドキュメントがデコードされ、再生される少し前に）ビデオドキュメントを解析してもよい。
【0076】
戻って、図４の動作４２０を参照すると、ビデオドキュメントが供給される前に、ビデオ発行者によって、ビデオドキュメントとは別々に、広告スポットを提供してもよい。代わりに、または、加えて、（例えば、広告スポットの発生のかなり前に、または、広告スポットの直前に）ビデオドキュメント中にエンコードされた情報に基づいて、広告スポットを決定してもよい。したがって、例えば、ビデオドキュメントは、前もって、２０分、４０分、および５５分において、３つの２分間広告スポットがあるという事実をドキュメント中にエンコードしてもよい。別の例として、ビデオドキュメントは、１０分、１９分、および、５０分において、２分間広告スポットがあるという事実をドキュメント中にエンコードしてもよい。このようなエンコーディングは、マーカー、ビデオパケットまたはビデオストリームパケット中のテキスト情報、広告サーバを呼び出すための実行可能コード（例えば、Java（登録商標）スクリプト）等の形態であってもよい。
【0077】
いくつかのケースでは、ビデオドキュメントをオンデマンドでダウンロードすることができるので、より多くのまたはより少ない広告スポットを収容するように、ビデオドキュメントの長さを変化させてもよいということに留意すべきである。例えば、とても関連する広告がたくさんある場合、および／または、広告主がインプレッションに対して多く支出したがっている場合、より多くの広告スポット時間が提供されてもよい。したがって、（Ａ）広告関連性の度合い、（Ｂ）より多くの広告スポットを持つことの収益的利点、（Ｃ）より多くの広告スポットを持つことにおけるユーザ有用性の減少（例えば、ユーザのいらだち）、（Ｄ）コンテンツに対するユーザ需要のレベル、（Ｅ）コンテンツのエンドユーザ資金供給の範囲、等のうちの１つ以上に依拠して、ビデオコンテンツ時間−対−広告時間の比を減少させてもよく、または、増加させてもよい。このようにして、エンドユーザ有用性と広告収益とのバランスをとってもよい。
【0078】
ビデオドキュメントが予め保存されている（例えば、予め記録されている）場合、ビデオドキュメントが供給（例えば、ブロードキャスト、マルチキャスト、ユニキャスト、転送等）される前に、さまざまな広告スポット中に供給すべき広告を決定するためのアービトレーションが発生してもよい。ビデオドキュメントがライブで供給されている場合、ビデオドキュメントが供給されているときに（おそらく、クライアントデバイスにおいてビデオドキュメントがデコードされ、再生される少し前に）アービトレーションが起ってもよい。ビデオドキュメントが（例えば、ＦＴＰのような何らかの転送プロトコルを使用して）ダウンロードされる場合、ドキュメントは、ビデオドキュメントが再生されるときに（例えば、再生が開始されるときに）、広告アービトレーションを開始するための実行可能コードを含んでいてもよい。いずれのケースにおいても、アービトレーションの後に、ビデオドキュメント（例えば、ビデオコンテンツを搬送するストリーム）とともに、広告を提供（例えば、ビデオドキュメント中に挿入）してもよい。ビデオドキュメントが予め保存されている場合、そのビデオドキュメント中のすべての広告スポットが、一時でアービトレートされてもよい。このようにして、より高い需要のビデオドキュメント部分における広告スポット（例えば、ビデオドキュメントの開始）を、より高いスコアリングの広告で満たしてもよい。
【0079】
ビデオドキュメントを、それぞれが広告スポットを含むセグメントに分割してもよい。このような実施形態では、それぞれのセグメントを、ビデオドキュメント自体であるとみなしてもよい。特定のビデオセグメントのベースで、または、（例えば、より多く重み付けされた）特定のビデオセグメントと、（例えば、より少なく重み付けされた）全体としてのビデオドキュメントとの両方のベースで、関連広告を決定してもよい。同様に、セグメント内またはビデオドキュメント内の書き起こしのタイミングに基づいて、関連性情報を重み付けしてもよい。例えば、広告スポットに対して一時的により近いトピックを、広告スポットから一時的により遠い（おそらく、同じセグメント中の）トピックよりも、より多く重み付けしてもよい。
【0080】
広告情報は、広告主が、所定のビデオドキュメント（インスタンス）中で、広告主の広告を１回以上供給することを望むか否か、または１回以上供給することに同意するか否かを含んでいてもよい。例えば、広告主は、ビデオキュメントのインスタンス（例えば、ユニキャストビデオストリーム）とともに、広告主の広告をＮ回だけしか供給しないことを指定するかもしれない。代わりに、または、加えて、広告ネットワーク、および／または、ビデオドキュメント発行者は、ビデオドキュメントのインスタンスとともに、所定の広告を供給することができる回数を制限するポリシーを実現してもよい。
【0081】
多くの例を、インプレッション毎の申出（または、最大申出）の状況で説明したが、本発明と一貫した実施形態は、ユーザ選択（または通話、または、メッセージング等）毎の申出（または、最大申出）、コンバージョン（例えば、電話通話、アイテム購入、アイテム注文等）毎の申出（または、最大申出）のような他の申出を考慮してもよい。同様に、スコアリングは、１つ以上の申出の関数であってもよく、おそらく、１つ以上のユーザアクションの尤度であってもよい。広告スコアリングは、インプレッション毎の予期される費用（例えば、インプレッション毎の入札、選択＊選択レートまたは確率毎の入札、コンバージョン＊コンバージョンレートまたは確率毎の入札等）を反映させてもよく、広告をスコアリングするための他の技術を使用してもよい。このような技術は広告のエンドユーザ有用性（例えば、関連性、いらだち要因等）を考慮してもよい。
【0082】
ビデオドキュメント内にビデオ広告を挿入するとして、本発明に一貫した実施形態のいくつかのものを説明したが、広告は、他のフォーマットであってもよく、ビデオドキュメントとともに供給されてもよい。例えば、テキスト広告、画像広告、オーディオのみの広告等がビデオドキュメントとともに再生されるかもしれない。したがって、広告のフォーマットは、それとともに広告が供給されるビデオドキュメントのフォーマットに一致していてもよいが、広告のフォーマットは、必ずしもビデオドキュメントのフォーマットに一致していなくてもよい。広告は、ビデオコンテンツと同じスクリーン位置において、または、異なるスクリーン位置において（例えば、ビデオコンテンツに隣接して）、レンダリングされてもよい。ビデオ広告は、ビデオコンポーネントとともに、追加的コンポーネントを含んでもよい。このような追加的コンポーネントは、ビデオコンポーネントと同じディスプレイ上で、および／または、クライアントデバイスの、他の何らかの出力手段上で、レンダリングされてもよい。同様に、ビデオ広告は、本発明と一貫した方法で、（例えば、ウェブページのＩフレーム中で）非ビデオドキュメントとともに再生されてもよい。
【0083】
図４および１０は、所定のビデオドキュメントに対して関連広告を決定するとして説明したが、本発明に一貫した実施形態を使用して、所定の広告に関連するビデオドキュメント（またはその広告スポット）を決定してもよい。例えば、広告主には、その広告に関連すると考えられるビデオドキュメントが提示されてもよい。ドキュメントは、このような関連性を使用して順序付けされてもよい。広告主は、ビデオドキュメントとともに（または、その広告スポットとともに）、広告主の広告を供給させようとすることを選択してもよい。広告主は、このような選択を、ドキュメントとともに広告主の広告を供給させる申出として、表現してもよい。他の広告主が同様なことを行ってもよい。ビデオドキュメントが供給されるとき、ビデオドキュメントとともに供給されるのに適格性のある広告の間での競争が、（例えば、オークションを使用して）アービトレートされてもよい。
【0084】
広告供給ネットワークとビデオ発行者との間で、広告ベースの収益を分配してもよい。ビデオ発行者は、購読ベースで、ダウンロード毎ベースで、および／または、レンダリング毎ベースで、エンドユーザから金銭を収集してもよい。ビデオ発行者と分配した広告収益を使用して、ユーザ費用を補助してもよい（例えば、費用を減少させてもよく、または無くしてもよい）。実際、広告収益（例えば、広告ネットワークの分配、および／またはオーディオ発行者の分配）を使用して、広告を含むビデオドキュメントをダウンロードまたはレンダリングさせるために、ユーザに支払いを行ってもよい。例えば、ユーザが、音楽ビデオをダウンロードするために、通常は＄1.00を支払う場合、１つ以上の広告を有する音楽ビデオをダウンロードするために、より少なくチャージされるかもしれない（または、まったくチャージされず、または、実際に支払うかもしれない）。広告収益を使用して、ビデオボイスメール、ビデオライブチャット、音楽ビデオ、音楽ビデオ再生、ビデオ番組（例えば、テレビジョンショーエピソード、テレビジョンショーシーズン、映画等）ダウンロード、ビデオ番組再生、テレビ電話サービス等のような他のコンテンツおよび／またはサービスを補助してもよい。
【0085】
本発明に一貫した実施形態におけるアービトレーションは、ブロードキャスト毎（または、マルチキャスト毎）のベースで、あるいは、供給毎、またはダウンロード毎のベースで実行されてもよい。供給毎、またはダウンロード毎のベースでアービトレーションを実行することは、より多くの収益を発生させる可能性を持つ。例えば、100,000個の広告スポットを有するビデオドキュメント上で、ブロードキャスト毎の契約の下で、広告主Ａが＄50,000.00の予算制限とともに、＄5.00／インプレッションを支払うことを望み、広告主Ｂが＄60,000.00の予算制限とともに、＄2.00／インプレッションを支払うことを望み、広告主Ｃが＄100,000.00の予算制限とともに、＄1.00／インプレッションを支払うことを望む場合、広告Ｃが100,000回供給され、＄100,000.00の純益を上げるだろう。他方、広告スポット毎のアービトレーションの下では、広告Ａが10,000回供給され、広告Ｂが30,000回供給され、広告Ｃが60,000回供給され、＄170,000.00（＄50,000.00＋＄60,000.00＋＄60,000.00）の純益を上げるだろう。
【0086】
それとともに、広告が供給されてもよいビデオドキュメントの数多くの情報源があってもよいことに留意すべきである。第１の例として、広告ネットワーク自体が、ビデオサーバをホスト管理してもよい。第２の例として、ビデオコンテンツを提供する、大規模および小規模ウェブサイトが、広告ネットワークとパートナーになってもよい。第３の例として、ドキュメントの、他のプロバイダ（例えば、ウェブページ、ｅメール等）が、広告ネットワークとパートナーになって、ビデオ広告を示してもよい。これらのさまざまな状況で使用される例示的なビジネス方法を以下で説明する。
【0087】
広告ネットワーク自体が、第三者のビデオをホスト管理するビデオサーバ（例えば、グーグルビデオ）を提供してもよい。広告ネットワークホスト管理されたウェブサイト上のコンテンツプロバイダと、広告ネットワーク自体との両方が、広告収益分配を通して利益を得るだろう。別の例として、広告ネットワークが、広告収益のすべてを受け取ってもよく、コンテンツプロバイダが、無料で、または、補助もしくは減少された費用で、コンテンツプロバイダのビデオをホスト管理してもらうという利益を受け取る。
【0088】
ビデオコンテンツを提供する、大規模ウェブサイトが、広告ネットワークとパートナーになってもよい。例えば、ＡＢＣニュース．ｃｏｍ（登録商標）は、近年、頻度が増加しつつあるハリケーンに関連するニュースクリップを再生するかもしれない。ウェブサイトが広告ネットワークのパートナーであるとして仮定すると、広告ネットワークはニュースクリップに対して関連性のある広告を供給するだろう。例えば、ＲｅｄＣｒｏｓｓ（登録商標）の広告は、ロケーションに基づいて、閲覧者にターゲット付けされてもよく、最も近いＲｅｄＣｒｏｓｓのオフィスの電話番号を含んでいてもよい。このことは、ＲｅｄＣｒｏｓｓが、彼らのローカルケーブルテレビジョン広告を、ウェブ上でも使用することを許容する。このケースでは、ＡＢＣニュース．ｃｏｍは、彼ら自身のビデオコンテンツをホスト管理してもよいが、広告ネットワークの広告サーバに対するサーバ呼出があることになり、この広告サーバからビデオ広告が取得され、ＡＢＣニュース．ｃｏｍのビデオストリームに挿入されるだろう。より大規模ウェブサイトと、広告ネットワーク自体との両方が、広告収益分配を通して利益を得てもよい。
【0089】
ビデオコンテンツを提供する、小規模ウェブサイトが、広告ネットワークとパートナーになってもよい。小規模ウェブサイトは、彼ら所有のビデオをホスト管理するという面倒を経験したがらないかもしれない。広告ネットワークは、（おそらく、ビデオがさまざまな使用条件を満たすならば）小規模ウェブサイト上のビデオをホスト管理することができ、次に、小規模ウェブサイト上のＩフレーム中に、広告とともにビデオを表示させることができる。小規模ウェブサイトと、広告ネットワーク自体との両方が、広告収益分配を通して利益を得るだろう。別の例として、広告ネットワークが、広告収益のすべてを受け取ってもよく、小規模ウェブサイトが、無料で、または、補助もしくは減少された費用で、小規模ウェブサイトのビデオをホスト管理してもらうという利益を受け取る。
【0090】
本発明と一貫した実施形態は、ビデオコンテンツ以外のコンテンツとともに使用されてもよい。このケースでは、非ビデオコンテンツを使用して、ビデオ広告をターゲット付けしてもよい。例えば、車レビュー（例えば、Ｆｏｒｂｅｓ年間高級車レビュー）を取り扱うウェブページが、ＧＭ（登録商標）からの最新のキャデラック（登録商標）モデルのためのフラッシュビデオをホスト管理してもよい。
【0091】
少なくともいくつかの実施形態では、ビデオ広告は、“再生”、“停止”、および“一時停止”の機能を持つ（例えば、フラッシュ）プレーヤ中で再生されてもよい。広告主によって支払われることになる額は、さまざまなユーザ−ビデオの広告対話の際に条件付けられてもよい。例えば、ビデオ広告が最初のＮ（例えば、Ｎ＝５）秒内に停止された場合、これは、広告主がそうでなければこれに対してチャージされることになる、インプレッションであるとしては考えられないかもしれない。
【0092】
２００５年３月３０日に出願され、“広告オーサリングおよび／または広告キャンペーン管理のために広告主およびエージェントをネットワークすること”と題され、Ross Koningstein氏、およびSumit Agarwal氏を発明者として記載する、（“‘４２２出願”として呼ばれ、ここに参照によりその全体が組み込まれる）米国特許出願シリアル番号第11/093,422号に説明されたような技術を使用して、小規模で、それ程先進的でない広告主がビデオ広告を生成するのを支援してもよい。例えば、イタリア料理クッキングショーの状況で、ローカル的にターゲット付けされたそのビデオ広告を示すことを望む、ローカルイタリアンレストランについて考える。残念なことに、このレストランは小規模操業であり、テレビジョン広告を作った経験を持っていない。このレストランがビデオ広告に対して契約しに行くとき、広告ネットワークは、例えばローカルファームのようなファームとレストランとの関係を容易にしてもよく、この会社は、供給するために広告ネットワークに対してアップロードすることができるビデオクリエイティブを作るのを支援することができる。
【0093】
本発明と一貫した、少なくともいくつかの実施形態では、アップロードされたビデオファイル、および／またはビデオ広告は、自動的なスピーチ認識、トランスコーディング、サムネイル発生、認可、および／またはインデックスへの追加を受けてもよい。
【0094】
セクション４．３．３．１ ビデオ広告性能推定の発生と、このような推定の使用（以下で説明する）さまざまな“キー”を使用して、広告の予測クリックスルーレート（または、他の何らかの予測ユーザアクションレート）を決定してもよい。それに対して、ビデオ広告が再生されることになるドキュメント（例えば、ビデオ、ウェブページ等）の文脈の（contextual）エレメントを使用することに加えて、または、代わりに、ビデオ広告供給により詳細に関係する、他の１つ以上のパラメータ（例えば、供給パラメータ）、および／または、供給されたビデオ広告に関係するパラメータを使用して、予測ユーザアクション（レート）を決定してもよい。他のこのようなパラメータは、ビデオ広告選択レート、ビデオ広告ＣＰＭ、ビデオ広告再生レート、一部または全部のビデオ広告再生、再生されたビデオの継続時間の割合、ビデオ再生の時間、使用されたビデオプレーヤアプリケーション、ビデオの長さ、最初のビデオフレームの寸法（例えば、矩形ピクセルサイズ）、寸法が拡大されたか否か、寸法拡大レート、寸法が減少されたか否か、寸法減少レート、寸法の拡大または減少のサイズ、他のリサイズ動作（例えば、フルスクリーン化、最小化等）、ウィンドウ寸法に対する寸法、利用可能なスクリーンサイズに対する寸法、音声がミュートされたか否か、音量低減、音量増大、音量変更、リプレイされたか否か、リプレイレート、一時停止されたか否か、一時停止レート、時間スライドされたか否か、順方向時間スライド、逆方向時間スライド、それとともに広告が供給されたビデオのユーザレビュー、それとともに広告が供給されたビデオが友人にメールされたか否か、ユーザがビデオに関連するメーリングリストに登録したか否か等のうちの１つ以上を含んでいるかもしれない。これらのパラメータは平均であってもよく、または、平均を含んでもよい。これらのパラメータの値は、質的（はい、または、いいえ）、あるいは、量的（量）であってもよい。
【0095】
予測ユーザアクション推定を決定するために、パラメータを重み付けし、結合してもよい。（例えば、機械学習システムを使用して、）重みを調整してもよい。
【0096】
候補ビデオ広告がユーザに対して示されることになるか否か、および／または、どのように（例えば、どの順序で）候補ビデオ広告が示されることになるかを決定するときに、推定された予測ユーザアクションレート（例えば、推定された予測ＣＴＲ）を考慮してもよい。
【0097】
ユーザアクションレートを予測するための“キー”は、広告の供給をトリガする広告属性（例えば、検索クエリ、ウェブページ等）から独立した、１つ以上の（以下で説明する）“タグ”をまた含んでもよいことに留意すべきである。他のこのようなエレメントは、時刻、言語、国、（パーソナライズ化のケースでは）個人プロファイル等を含んでもよい。他のこれらのエレメントは、例えば、データマイニングを通して学習されることができる。
【0098】
推定ユーザアクションは、‘５８１出願で説明したもののような、さまざまな方法を使用して予測されてもよい。以下に説明する図２０−２３は、‘５８１出願の図５−８に対応する。例えば、上で列挙したもののようなビデオ広告パラメータを、以下で説明するように“キー”として使用してもよい。
【0099】
図２０は、本発明と一貫した方法で、（ビデオドキュメントとともに供給されるかもしれない）広告に関するユーザアクションレートを推定するための例示的な方法のフローチャートである。方法は、受け取られたユーザクエリに応答して、広告を識別し、ランク付けし、表示するように動作してもよい。最初に、リアルタイムでクエリを受け取る際に、または、過去のクエリの履歴ログから抽出されたクエリを受け取る際に、方法は（新しいクエリのケースでは）１組の候補広告、または、（過去のクエリのケースでは）１組の供給された広告のいずれかを識別する（ブロック２０００）。例えば、キーワードターゲット付け、文脈の解析等を使用して、関連性のある広告を決定してもよい。一度、１組の候補広告が識別されると、広告の特性に関連する１組のキー、クエリ、または、両方の組み合わせを識別してもよい。
【0100】
受け取られたクエリに応答して、候補広告を供給してもよいが、その上に、または、それとともに広告が表示されることになる（例えば、ウェブページ中の）ウェブドキュメントまたは他のドキュメントのコンテンツのような、非クエリ情報を使用して、候補広告を決定してもよいことを理解すべきである。このような非クエリ実現では、識別されたキーは、候補広告の特徴や、その上に広告が表示されることになるドキュメント（例えば、ウェブページ）の特徴や、および／または、ビデオ広告の供給に関係する、他の属性に関連していてもよい。集合的に、広告と受け取られたクエリとを表示するウェブドキュメントを、“広告トリガ”として呼んでもよく、それぞれの広告トリガは、ここで説明する広告性能推定プロセスを開始させる。
【0101】
ここで規定するように、“キー”は、受け取られたクエリや、供給のために識別された広告や、および／または、広告の供給に関係する属性もしくは特徴に関係付けられた、任意の識別可能な特徴、または特徴の組み合わせに関連する任意の情報のストリングであってもよい。“クエリ”は、ユーザによる検索用語入力を超えた、追加的情報を含んでいてもよいことをさらに理解すべきである。例えば、それぞれの受信クエリはまた、クエリに関係付けられた、より広いカテゴリまたはトピックに関連する情報や、クエリを開始したユーザの地理的ロケーションや、ユーザによって使用される検索の基本設定（preference）や、検索を開始するのに使用されたウェブブラウザまたは他のアプリケーションのタイプや、ユーザの言語基本設定や、ユーザのインターネットプロトコル（ＩＰ）アドレスや、ユーザおよび／またはユーザのＩＰアドレスに関係付けられた広告クリックまたはユーザアクション履歴や、ユーザの検索履歴や、クエリが受け取られた日付および時間や、あるいは、他の広告供給パラメータを含んでいてもよい。
【0102】
クエリ関連の特徴に加えて、各キーは、加えて、または、代わりに、識別された広告に関連する特徴も含む。広告関連の特徴は、広告主名称、広告のキーワードターゲット、広告のテキストまたはコンテンツ、広告の目的ＵＲＬ（ユニフォームリソースロケータ）、広告の地理的ロケーション、広告の言語等を含んでもよい。
【0103】
次に、１組のタグ−値の対としてキーを表わしてもよく、ここで、タグは、特定の特徴タイプ（例えば、供給パラメータ）を識別し、値は、対応する特徴の値を識別する。例えば、表記“ユーザ＿国：カナダ”は、ユーザの居住する国はカナダであることを示すタグ−値の対を表す。いくつかのタグ−値の対を含む（例えば、いくつかのタグ−値の対からなる）キーは、括弧で囲まれたリストとして記述されてもよい。例えば、（ユーザ＿国：“カナダ”、クエリ＿テスト：“キャンピングギア”）は、２つのタグ−値の対からなるキーを示してもよく、選択されることになる所定のキーに対する順序で、これらの両方が満たされなければならない。
【0104】
適切なキーの第１の例は、ユーザの検索クエリが単語“フリー”を含むことを示す、（クエリ＿単語：“フリー”）であってもよい。第２の例は、クエリを提出したユーザがＵＳＡに位置し、ユーザのブラウザが英語に対して設定されていることを示す、（ユーザ国＝ＵＳＡ；ユーザ言語：“英語”）であってもよい。第３の例は、広告リンクの目的ページが、フレーズ“スイミングプール”を含み、ユーザの検索が単語“プール”を含み、ユーザがサファリブラウザを使用していることを示す、（目的＿ページ＿テキスト：“スイミングプール”、クエリ＿単語：“プール”、ブラウザ：“サファリ”）であってもよい。他の数々の例が可能である。
【0105】
この追加的な情報を使用することにより、広告選択システムは、受け取られたクエリに応答して、識別された広告に対するユーザアクションレート（ＵＡＲ）の改善された推定を発生させてもよい。
【0106】
本発明の原則と一貫した１つの実現では、キーの組は、広範囲の広告および／またはクエリの特徴もしくは特性を含んでもよい。代わりに、キーの組は、予め定められたもしくは指定された、クエリの組み合わせおよび／または広告の特徴もしくは特性を含んでもよい。１つの実現では、広告トリガとの予め定められた関係付けに基づいて、キーが選択されてもよい。例えば、広告トリガが検索クエリである場合、ユーザの検索クエリ中の隣接する単語の対のそれぞれに対して、キーが選択されるだろうということを、ルールが指定してもよい。このルールにしたがって、検索クエリ“記念日 花 シアトル”は、２つのキー（クエリ＿フレーズ：“記念日 花”；クエリ＿フレーズ：“花 シアトル”）を発生させるだろう。広告のトリガに、広告自体に、および／または、他の供給パラメータに関係付けられた、他のルールによって、追加的キーが発生されてもよい。この技術は、たくさんのキーが識別されることに帰結するかもしれないが、この技術を使用して、有用であると考えられる情報のタイプ、したがって、トリガ／広告の対に対するキーの組の中に含めるのに適切な情報のタイプを示してもよい。以下の追加的な詳細で説明することになるように、ＵＡＲ推定プロセス内に、不適切な、または重複したキーが含まれる尤度を減少させるために、適用可能な、または関連性のあるキーの選択は、最初の組よりも、さらに正確にされてもよい。
【0107】
最初のキー選択に続いて、広告選択システムに関係付けられた記憶デバイスのような記憶から、各キーに関する履歴データが取得される（ブロック２００４）。本発明の原則と一貫した１つの実現では、履歴データは、キーに関係付けられたインプレッションの数、キーに関係付けられたユーザアクション（例えば、クリック、注文等）の数等に関連する情報または統計を含んでもよい。上で説明したように、用語“インプレッション”は、他のキー特徴に関連して、広告が表示された回数に関連する。さらに、用語“ユーザアクション”は、広告に関係付けられた特定のユーザアクションが発生した回数に関連する。例えば、（ユーザ＿国：“ＵＳＡ”、広告主＿国：“カナダ”）のようなキーに対して、一致する広告が１０００回表示され、３０回において動作されたことが決定されてもよく、これは、３．３３の履歴ユーザアクションレートを表わしている。１つの実施形態では、クエリログおよびユーザアクションログのような、サーバによって維持されたさまざまなログから、このような履歴情報を取得してもよい。
【0108】
ブロック２００２で識別された各キーに対する履歴情報は、（例えば、実質上リアルタイムで）コンパイルしてもよい。次に、これに対して、予測モデルを適用して、クエリ／広告の対のそれぞれに対して、推定ユーザアクションレート（ＵＡＲ）、またはユーザアクション確率を発生させてもよい（ブロック２００６）。次に、推定ＵＡＲを使用して、受け取られたクエリに応答して、ユーザに対する潜在的なレンダリングのための広告を選択し、ランク付けし、または、そうでなければ分類してもよい（ブロック２００８）。
【0109】
本発明と一貫した予測モデルは、以下のような構造を持っていてもよい。所定のトリガ／広告の対に対して、所定のユーザアクションが発生することになる推定尤度は、アクションが発生することになる事前の尤度と、所定のトリガ／広告の対に対して選択されたキーに関係付けられた１つ以上のモデルパラメータとの関数であるかもしれない。次に、訓練のために使用された実際の履歴データに対して、最も適した予測ユーザアクション確率を生成するパラメータ値を解決しようとする反復プロセスを使用して、モデルパラメータを計算してもよい。ユーザアクションの事前の尤度は、予め定められた定数に設定されてもよく、または、ＩＲ（情報取得）スコア、表示された広告の位置とサイズ等のような、トリガ／広告の対に関係付けられたさまざまな特徴のうちの１つ以上に依拠してもよい。例えば、検索結果ページの最上位に現れる広告は、検索結果ページの最下位に現れる同様の広告よりも、発生しているユーザアクションのより高い事前の尤度を割り当てられてもよい。
【0110】
各キーに関係付けられたモデルパラメータは、発生している望ましいユーザアクションの確率または見込への乗数のような、単一のパラメータを含んでもよい（例えば、単一のパラメータからなってもよい）。代わりに、各キーは、キーに関係付けられたいくつかのモデルパラメータを持っていてもよく、モデルパラメータは、より複雑な方法でユーザアクションの予測確率に影響を及ぼしてもよい。
【0111】
以下の説明において、さまざまな見込と確率を使用する。発生しているイベントの見込と、発生しているイベントの確率とは、表現：確率＝見込／（見込＋１）によって関連する。例えば、発生しているイベントの見込が１／２（すなわち、見込は“１：２”であると書かれることが多い）である場合、対応する発生しているイベントの確率は、１／３である。この規則にしたがって、見込と確率は、交換可能であるとして考えてもよい。見込は、任意の負でない値を取ってもよいが、他方、確率は０および１の間に位置しなければならないので、確率ではなく見込に関して、計算を表現することが便利である。しかしながら、もっぱら確率だけを使用して、または、ｌｏｇ（見込）のような、他のいくつかの同様の表現を使用して、以下の説明に対する最小限の変更だけを伴って、以下の実現を実行してもよいことを理解すべきである。
【0112】
図２１は、本発明と一貫した方法で、トリガ／広告の対のそれぞれに対する推定ＵＡＲを発生させる例示的な方法のフローチャートである。最終のＵＡＲは発生しているユーザアクションの確率に関して規定されるかもしれないが、所定のトリガ／広告の対に対する推定ＵＡＲは、上で説明したようにユーザアクション見込（１）として同様に表わされるかもしれない。本発明と一貫した１つの実施形態にしたがうと、事前のユーザアクション見込（ｑ０）を、選択されたキー（ｋｉ）のそれぞれに関係付けられたモデルパラメータ（ｍｉ）で乗算することにより、ユーザアクション見込を計算してもよく、今後、見込乗数として呼ぶ。このようなソリューションを以下のように表現してもよい。 ｑ＝ｑ０．ｍ１．ｍ２．ｍ３．．．．ｍｍ。
各キーに対する見込乗数は、ユーザアクションが発生したか否かを決定する際の、このキーの予測累乗（power）の統計的表現であってもよい。本発明と一貫した１つの実施形態では、各キーに対する見込乗数は、このキーを選択するトリガ／広告の対に対して、（履歴データにわたって集約された）観察されたユーザアクションレート中の変更を表わしてもよく、これは、他のキーの任意のものを使用して、モデル化または“説明”されることはできない。
【0113】
本発明と一貫した１つの実施形態では、上で説明したモデルパラメータを継続的に修正して、所定のトリガ／広告の対のそれぞれに対する推定ＵＡＲへの、各キーの相対的影響を反映させてもよい。所定のキーにかかわらず、ユーザアクションが発生することになる予測確率と、測定された履歴ユーザアクションレートとを比較することによって、このような修正を実行してもよい。このような方法で、解析されたキーの相対的値が識別され、さらに正確にされる。
【0114】
図２１に戻って、詳細には、選択されたキー（ｋｉ）のそれぞれに対して、平均自己除外（self-excluding）確率（Ｐｉ）を、最初に計算し、または、識別してもよい（ブロック２１００）。本発明と一貫した１つの実施形態では、自己除外確率（Ｐｉ）は、選択されたキーの関連性を表現する値であり、選択されたキーのモデルパラメータ（ｍｉ）が推定ＵＡＲ計算から除去されるとき、トリガ／広告の対の結果としてのユーザアクションレートを測定してもよい。例えば、キー３に対して、以下のようにこのことを表現してもよい。 Ｐ３ｎ＋（（ｑ０．ｍ１．ｍ２．ｍ３．．．．ｍｎ／ｍ３／（（（ｑ０．ｍ１．ｍ２．ｍ３．．．．ｍｎ）／ｍ３＋１）。
【0115】
本発明と一貫した１つの実施形態では、それぞれのキーに対する自己除外確率は、移動平均として維持されてもよい。このようにすることは、識別された自己除外確率が、以下の、選択されたキーのそれぞれに対するモデルパラメータの識別を、より素早く収束させることを確実にするだろう。このような移動平均は、以下のように表現してもよい。 Ｐｉｎ（ａｖｇ）＝αＰｉ（ｎ−１）（ａｖｇ）＋（１−α）Ｐｉｎ
ここで、αは、移動平均のハーフライフを制御するのに使用される、統計的に規定された、１に非常に近い変数（例えば、0.999）である。上記の表現において示したように、現在のインプレッションの数（ｎ）に対するＰｉの値は、前のインプレッション（例えば、ｎ−１）において決定されたＰｉの値によって、重み付けられ、平均されている。
【0116】
次に、平均自己除外確率（Ｐｉ（ａｖｇ））を、観察されたインプレッションの数と、観察されたインプレッションに対して観察されたユーザアクションの数とに関連している履歴情報に比較してもよい（ブロック２１０２）。次に、選択されたキーに関係付けられたモデルパラメータは、ブロック２１０２の比較に基づいて、発生または修正されてもよい（ブロック２１０４）。
【0117】
図２２は、本発明と一貫した方法で、モデルパラメータを発生させるための例示的な方法のフローチャートである。この方法を使用して、図２１のブロック２１０２−２１０４の処理を実現してもよい。最初に、ユーザアクションの見込に関連する信頼区間を決定してもよい（ブロック２２００）。信頼区間技術を使用することは、より少ない量の履歴データを持っているキーが使用されるときに、推定の正確性と安定性を改良する。本発明と一貫した１つの例示的な実施形態では、信頼区間は、下位値Ｌｉと上位値Ｕｉを含み、選択されたキーに対して観察された、インプレッション（ｎｉ）とユーザアクション（ｊｉ）の数に基づいている。例えば、信頼区間は、観察されたインプレッションとユーザアクションの数に基づいて、従来の方法で計算された、８０％信頼区間［Ｌｉ，Ｕｉ］であってもよい。
【0118】
下記の信頼区間計算で、平均自己除外確率（Ｐｉ（ａｖｇ））が区間内であるか否かを決定してもよい（ブロック２２０２）。そうである場合、選択されたキー（ｋｉ）がクリックスルーレートへの何の影響も持っていないことを決定してもよく、そのモデルパラメータ（ｍｉ）を１に設定してもよく、推定ＵＡＲ計算から、そのキーを効率的に除去する（ブロック２２０４）。しかしながら、Ｐｉ（ａｖｇ）が信頼区間の外側にあることが決定された場合、選択されたキーに対するモデルパラメータ（ｍｉ）は、平均自己除外確率（Ｐｉ（ａｖｇ））を信頼区間に入れるのに必要な最小調整に設定されてもよい（ブロック２２０６）。数学的に、この計算を以下のように表現してもよい。 ｍｉ＝［Ｌｉ（１−Ｐｉ（ａｖｇ））］／［Ｐｉ（ａｖｇ）（１−Ｌｉ）］。
【0119】
以下の例を考える。ユーザが米国におり、クエリが中古車に関連するという事実を表すキー（ｋｉ）に対して、200ユーザアクション（ｊｉ）と、10,000インプレッション（ｎｉ）とが観察されたとして仮定する。さらに、（このキーの影響を含まない）これらのインプレッションに対する、平均予測ユーザアクション確率（Ｐｉ（ａｖｇ））は、0.015であったとして仮定する。10,000インプレッションの中からの200ユーザアクションに対する８０％信頼区間は、［0.0182，0.0219］であり、このため、ｍｉは、0.015を0.0182に変換するのに要求されるモデルパラメータに設定されるだろう。上記の表現において使用したときの、この値は1.217である。言い換えると、このキーの存在は、キーの条件が満たされるときに、ユーザは測定されるアクションを、約２０％より多く実行する可能性があることを意味すると解釈される。
【0120】
ここで、図２１に戻って、一度、選択されたキーに対するモデルパラメータが計算されると、処理するための追加的キーが残っているか否か（すなわち、ｋｉ＜ｋｍであるか否か）を決定してもよい（ブロック２１０６）。処理するための追加的キーが残っている場合、カウンタ変数ｉをインクリメントし（ブロック２１０８）、処理はブロック２１００に戻って、次のキーを処理してもよい。一度、すべてのキーに対するモデルパラメータが計算または修正されると、数式ｑ＝ｑ０．ｍ１．ｍ２．ｍ３．．．．ｍｍを使用してユーザアクションの推定見込を計算してもよい（ブロック２１１０）。次に、上で説明した変換規則を使用して、見込を推定ユーザアクション確率またはユーザアクションレートに変換してもよい（ブロック２１１２）。
【0121】
本発明と一貫した１つの実施形態では、ログデータが到着するときにログデータを処理し、上で述べた統計（例えば、インプレッション、ユーザアクション、自己除外確率等）を蓄積することによって、ＵＡＲ予測モデルを訓練してもよい。追加的インプレッションが発生するとき、各キーに関係付けられた信頼区間は短縮されてもよく、パラメータ推定はより正確にされてもよい。追加的な実現において、古いログデータを再処理することによって、訓練を加速させてもよい。ログデータを再処理するとき、最近のパラメータまたは見込の乗数値を使用して、推定クリック確率を再計算してもよい。このことは、予測モデルがより素早く収束できるようにする。
【0122】
本発明と一貫した代わりの実施形態では、ベイズの推定を使用して、各キーに対するモデルパラメータを計算してもよい。ベイズの実現では、所定のキーがモデルパラメータｍを有することの事前確率を、ｇ（ｌｏｇ ｍ）が表すように、モデルパラメータの事前分布（ｇ）を最初に決定してもよい。次に、積を最大化させるｍの値になるように所定のモデルパラメータ（ｍｉ）を設定してもよい： ｆ（ｌｏｇ ｍ）＝ｇ（ｌｏｇ ｍ）ｈ（ｌｏｇ ｍ）
ここで、ｈ（ｌｏｇ ｍ）は、所定の値ｍを使用した、ｎｉインプレッションのうちでｋｉユーザアクションを観察する確率に対する比例（proportional）であり：
ｈ（ｌｏｇ ｍ）＝ｐｏｗ（ｐ，ｋｉ）ｐｏｗ（１−ｐ，ｎｉ−ｋｉ）
ここで、ｐ＝（ｍ・ｐｉ）／（１−ｐｉ＋ｍ・ｐｉ）であり、ｐｏｗ（ｘ，ｙ）は、ｘをｙの累乗に上げることを表す。分布をより対称的にするために、上記の表現は、ｍではなくｌｏｇ（ｍ）を使用することに留意すべきである。
【0123】
図２３は、本発明と一貫した方法で、ユーザから受信されたクエリに応答して、広告を選択および表示するための、例示的な広告選択システム１２５を図示するブロック図である。例示的な広告選択システムは、データ処理エンジン２３０２と、データ収集エンジン２３０４と、データ記憶装置２３０６と、広告選択サーバ２３０８と、広告サーバ２３１０とを含んでもよい。別個のシステムコンポーネントの別の数を識別したが、システムは、より多くの、より少ない、または異なる配置のコンポーネントを含んでもよいことを理解すべきである。
【0124】
動作において、データ処理エンジン２３０２は、データ収集エンジン２３０４から、データのストリームを受け取ってもよく、ここで、それぞれの更新は、少なくともキーと、キーに関係付けられた値とを含む。一度受け取られると、データ処理エンジン２３０２は、同じキーに対する複数の値をどのように結合するかに関して、データにルールを適用してもよい。例えば、受け取られた値は、インプレッションの数と、観察されたユーザアクションの数と、自己除外確率とを含んでもよい。次に、ルールを使用して、同じキーに対する複数の値を結合してもよい。例えば、インプレッションに対する値を追加してもよく、観察されたユーザアクションに対する値を追加してもよく、予め定められた方法にしたがって、自己除外確率を更新してもよい。
【0125】
データ収集エンジン２３０４は、データ記憶装置２３０６から、クエリと広告情報を収集し、データ処理エンジン２３０２に送られる更新ストリームを発生させるように動作してもよい。本発明の原則と一貫した１つの実現では、クエリと広告情報は、クエリログ、クリックログ等のような、ログファイルを含んでもよい。データ収集エンジン２３０４は、データ処理エンジン２３０２からルックアップを実行して、キーに関係付けられた事前の累積のデータを取得してもよい。次に、このデータを使用して、上で説明した方法で識別されたキーに対する、更新モデルパラメータを計算してもよい。次に、識別されたキーに対する更新を、データ処理エンジン２３０２に送る。
【0126】
広告選択サーバ２３０８を動作させて、広告サーバ２３１０から、クエリに関係付けられた１組の候補広告を取得してもよい。上で説明した予測モデルを使用して、広告選択サーバ２３０８は、クエリ／広告の組合せのそれぞれに対するＵＡＲを推定するのに使用される１組のキーを最初に識別してもよい。次に、広告選択サーバ２３０８は、データ処理エンジン２３０２から、キーに関係付けられたデータを取得する。一度、キーデータが取得されると、広告選択サーバ２３０８は、上で説明した方法で、それぞれの候補広告に対する推定ＵＡＲを計算してもよい。次に、これらの推定ＵＡＲを、広告サーバ２３１０に送って、どの広告をユーザに対して表示するかを決定する際に使用してもよい。
【0127】
広告サーバ２３１０は、推定ＵＡＲに関係付けられたランキングに基づいて、クエリに関連している検索結果と組み合わせて、選択された広告のグルーピングを供給してもよい。広告供給に応答して、1つ以上の広告に関係付けられたユーザアクションが観察されるかもしれない。クエリの受け取りと、広告供給と、観察されたユーザアクションとのそれぞれに続いて、広告サーバ２３１０は、データ記憶装置２３０６中で維持されるデータを発生させてもよく、または更新してもよい。
【0128】
本発明と一貫した１つの例示的な実施形態では、予め定められた時間期間内にアクセスされなかったキーデータは、もはや使用されていないとして考えられ、供給可能なデータから除去される。古いデータの例は、旧式の広告に対する識別子等を含んでもよい。別の実現では、キーインプレッションの総数が、予め定められた時間期間（例えば、１年）内で追跡されてもよい。時間期間の間に観察されたキーインプレッションの総数が、予め定められたしきい値よりも少ない場合、データは、統計的に、不適切であるとして考えられ、供給可能なマップファイルから除去される。使用されるデータを、ＵＡＲ予測モデルによってフィルタすることにより、モデルの性能および正確性を増加させてもよい。
【0129】
セクション４．４ 動作の例 本発明と一貫した例示的な実施形態における動作の例を、図１３−１９に関して説明する。図１３は、本発明と一貫した例示的な環境１３００を図示し、ここで、ビデオ広告がビデオドキュメントとともに供給される。環境１３００は、ビデオサーバ１３１０と、ビデオ発行者フロントエンド１３２０と、ビデオ広告サーバ１３３０と、広告主フロントエンド１３４０と、クライアントデバイス１３６０とを含み、これらのすべては、例えば、インターネットのような１つ以上のネットワーク１３５０を通して、互いに通信してもよい。ビデオコンテンツオーナ／作成者は、ビデオ発行者フロントエンド１３２０を使用して、ビデオサーバ１３１０上にビデオ情報１３１５を記憶させてもよい。広告主は、広告主フロントエンド１３４０を使用して、ビデオ広告サーバ１３３０上にビデオ広告情報１３３５を記憶させてもよい。クライアントデバイス１３６０が、ビデオ広告ネットワーク中に参加しているビデオドキュメントを（例えば、ビデオサーバ１３１０から）ロードまたは再生するとき、ビデオ広告サーバ１３３０は、ビデオドキュメントとともに供給されることになる、１つ以上のビデオ広告を決定してもよい。
【0130】
図１４は、本発明と一貫した方法で、ビデオコンテンツオーナ／作成者フロントエンドを提供するための例示的な方法１４００のフロー図である。イベントブロック１４１０によって示したように、方法１４００のさまざまな分岐は、さまざまなイベントに応答して実行されてもよい。例えば、コンテンツオーナがそのビデオファイルをビデオサーバにアップロードさせることを要求する場合、コンテンツオーナによって規定されたロケーションからビデオファイルをアップロードしてもよい（ブロック１４２０）。戻ってイベントブロック１４１０を参照して、コンテンツオーナがビデオ広告を示すことを選ぶ（または、選ばない）場合、ビデオに関係して、広告を供給してもよい（または、供給しない）ことの表示を記憶させる（ブロック１４３０）。戻ってイベントブロック１４１０を参照して、コンテンツオーナが１つ以上の広告スポットを選択または規定する場合、コンテンツオーナによって選択および／または規定された広告スポットを、ビデオに関係して記憶させる（ブロック１４４０）。戻ってイベントブロック１４１０を参照して、コンテンツオーナがメタデータを入力する場合、ビデオに関係してメタデータを記憶させる（ブロック１４５０）。
【0131】
本発明と一貫した少なくともいくつかの実施形態を、ホスト管理されたビデオを検索できるようにするサーバの状況で使用してもよい。このような実施形態は、１つ以上の下記の特徴を含んでもよい。ユーザは、アップロードされたビデオに関係付けられたウェブサイトに対して、クリックスルーすることができてもよい。例えば、コンテンツオーナは、そのアカウント中のコンテンツオーナのビデオステータスページによって、アップロードされたビデオに対して、ＵＲＬと他の情報を追加することができる。一度、ホスト管理されたウェブサイト上でビデオが利用可能になると、ユーザは、提供されたＵＲＬをクリックして、ウェブサイトを訪問することができるだろう。
【0132】
本発明と一貫した少なくともいくつかの実施形態は、例えば、ビデオステータスページを訪問して、“書き起こし追加”ボタンをクリックすることによって、ビデオコンテンツオーナが、書き起こしと追加的ビデオ情報とを追加できるようにしてもよい。アップロードされたビデオが検索可能である場合、アップロードされたビデオファイルのそれぞれに書き起こしが追加されている場合、ユーザは、より容易にビデオを見つけることができるだろう。書き起こしのフォーマットが時間コード化され、テキストファイルとして保存されていると好ましいかもしれない。時間コード化された書き起こしは、ビデオのスクリプトをセグメントに分割する。各セグメントは、ビデオ中でスクリプト中の単語が話された時間と、この時間に続くスクリプトの実際の単語とを含む。例えば、各セグメントの時間は、以下のフォーマットで列挙されてもよい：ＨＨ：ＭＭ：ＳＳ．ｍｍｍ。 ＨＨ：00において開始する時間、
ＭＭ：00において開始する分、
ＳＳ：00において開始する秒、
ｍｍｍ：000において開始するミリ秒。
【0133】
時間コード化された書き起こしがどのように出現すべきかの例を以下で提供する： 9：54：50：000
9：54：50：000と、9：54：53：000との間で話された単語
9：54：53：000
9：54：53：000と、その次のセグメントとの間で話された単語
9：54：54：000
9：54：54：000において、話された単語。
【0134】
各タイムスタンプは、関係するビデオファイルの開始に関連する。さまざまな書き起こし会社がこれをサポートしている。このような会社は、例えば、Automatic Sync Technologiesと、Talking Type Captionsと、Rhino Moon Captioningとを含む。
【0135】
ビデオフォーマットは、例えば、ＭＰ３オーディオを有するＭＰＥＧ４フォーマット、または、ＭＰ３と、クイックタイムと、ウィンドウズ（登録商標）メディアと、Ｒｅａｌ Ｖｉｄｅｏとを有するＭＰＥＧ２中の各ファイルを含んでもよい。例えば、以下のような好ましいビデオ標準規格および／または要求があってもよい： ＮＴＳＣ（４：３）サイズおよびフレームレート、デインターレースされた、ビデオコーデック：ＭＰＥＧ２またはＭＰＥＧ４（ＭＰＥＧ４が好ましい）、
ビデオビットレート：少なくとも２６０Ｋｂｐｓ（７５０Ｋｂｐｓが好ましい）、
オーディオコーデック：ＭＰ３ｖｂｒ、
オーディオビットレート：少なくとも７０Ｋｂｐｓ（１２８Ｋｂｐｓが好ましい）、
ビデオは、認識可能なビデオコンテンツを含まなければならない（ビデオを含まないビデオコンテナファイルは受け入れられないだろう）、
フレームレートは、１２フレーム毎秒以上であるべきである、
ビデオメタデータは正確で、アップロードされたコンテンツに関連性のあるものでなければならない（スパム禁止）、
ビデオは少なくとも１０秒の長さでなければならない、等。
【0136】
本発明と一貫した少なくともいくつかの実施形態では、ビデオ発行者フロントエンドは、ビデオがアップロードされた後で、そのビデオをビデオ発行者が除去できるようにしてもよい。
【0137】
本発明と一貫した少なくともいくつかの実施形態では、ビデオ発行者フロントエンドは、ビデオ発行者がそのビデオに対する任意の価格を指定できるようにしてもよい。ユーザが無料でビデオにアクセスし、再生できるように、価格をゼロに設定してもよい。
【0138】
本発明と一貫した少なくともいくつかの実施形態では、（ビデオ発行者がそのビデオに対する価格としてゼロを指定した場合、）ビデオホスト管理サーバが、ユーザに手数料を課金してもよく、または、（ビデオ発行者がそのビデオに対してゼロより多い価格を設定した場合、）ビデオホスト管理サーバが、価格のより多くの収益分配を取ってもよい。例えば、ビデオ発行者が、５００ＭＢの高精細度ファイルをアップロードし、極めて人気になった場合、ビデオホスト管理サーバは、ユーザにファイルを無料で供与する代わりに、ユーザに手数料を課金してもよく、または、ビデオ価格からのより高い割合の収益を、ビデオ発行者に求めてもよい。価格が追加される前に、またはより高い収益分配がビデオに対して課金される前に、ビデオ発行者に通知することが好ましいだろう。
【0139】
図１５は、図１４に関して説明した１４００のようなフロントエンド方法を通して、一度ビデオコンテンツオーナ／作成者が必要な情報を入力すると、ビデオ識別子とともに記録として、または、ビデオ識別子に関係してのいずれかで記憶されてもよい、例示的な１組の情報１５００である。１組の情報１５００は、ビデオ識別子を記憶するためのフィールド１５１０と、ビデオとともに広告を供給してもよいか否かの表示を記憶するためのフィールド１５２０と、１つ以上の広告スポットについての情報（例えば、絶対的または相対的時間、開始および停止時間、開始時間および継続時間等）を記憶するためのフィールド１５３０と、メタデータ１５４０を記憶するためのフィールド１５４０とを含んでもよい。より少ない、またはより多くの情報を記憶してもよく、他のデータ構造を使用してもよいのは当然である。
【0140】
図１４の方法１４００を使用して、全体のビデオのそれぞれは、コンテンツをアップロードした当事者（例えば、コンテンツオーナ）によって規定されたさまざまなブレークポイントにおいて、ビデオ中に広告を挿入させるオプションを持っていてもよい。コンテンツオーナは、ファイルアップロードの時間において、広告を示すことを選ぶことができ、また、後の時間において、コンテンツオーナフロントエンドインターフェースから、広告をイネーブルすることができる。本発明と一貫した少なくともいくつかの実施形態では、コンテンツオーナは、コンテンツの一部分に対して広告をディセーブルすることができる。
【0141】
戻って、図１４のブロック１４５０と、図１５のフィールド１５４０との両方を参照すると、本発明と一貫した少なくともいくつかの実施形態では、コンテンツオーナは、彼らがアップロードしたコンテンツに対して、以下の情報のうちのいくつかまたはすべてを提供するように求められてもよい：すなわち、タイトル；記述；書き起こし；（利用可能な場合）トリビューンメタデータ；推奨される閲覧人口統計。コンテンツオーナがまた、ビデオを供給している（例えば、テレビジョン放送者である）場合、彼らは、例えば、１つ以上のカバーされるブロードキャストロケーション、時刻、曜日、時期、人口統計のような聴衆情報等のような追加的情報を提供してもよい。
【0142】
戻って、図１４２０を参照すると、本発明と一貫した少なくともいくつかの実施形態では、サービスの条件（例えば、ポルノグラフィー禁止、アルコール禁止等）の遵守に対して、アップロードされたビデオをチェックしてもよい。
【0143】
図１６は、本発明と一貫した方法で、ビデオ広告主フロントエンドを提供するための例示的な方法１６００のフロー図である。ビデオ広告として使用されることになるクリエイティブを広告主によって識別する（ブロック１６１０）。次に、広告主の機械（例えば、パーソナルコンピュータ）からビデオ広告サーバに、識別されたビデオを転送する（例えば、アップロードする）（ブロック１６２０）。広告主から供給制約および価格情報を受け入れる（ブロック１６３０）。必要な場合、ビデオ広告を、ビデオ広告サーバに対して適切なフォーマットに変換する（ブロック１６４０）。最終的に、広告情報（例えば、供給制約および価格情報）に関係して、ビデオ広告ファイルを記憶させ（ブロック１６５０）、その後、方法１６００が終了する（ノード１６６０）。
【0144】
戻ってブロック１６３０を参照すると、供給制約は、以下のうちの１つ以上であってもよい：すなわち、（所定のビデオドキュメントのメタデータに一致する）キーワード；広告を配置させるための（そして、インプレッション毎費用のべースで広告主を課金するための）広告主からのウェブサイトターゲット付け；地理的ロケーションターゲット付け（例えば、国、地域、都市、ＺＩＰコード）；人口統計；垂直型カテゴリ等。
【0145】
戻って、ブロック１６４０を参照すると、１つのフォーマット（例えば、ＭＰＥＧ）におけるビデオ広告を別のフォーマット（例えば、フラッシュ）に変換してもよい。例えば、ゼネラルモーターズ（ＧＭ）は、ＧＭのポンティアック車の新しいラインに対して新しい広告をアップロードすることを望むかもしれず、（１）ウェブ上のＮＡＳＣＡＲクリップの次のビデオストリームと、（２）ＧＭの車の新しいラインのレビューを投稿するウェブサイトとの両方に、広告を表示させることを望むかもしれない。ＧＭは、ビデオ広告のＭＰＥＧバージョンをアップロードしてもよく、そして、広告ネットワークが、ＭＰＥＧビデオをフラッシュビデオに自動的に変換してもよい。次に、ＧＭウェブサイトターゲット付けと、ビデオに対するキーワード一致とに適した、ウェブ全体にわたってのビデオストリーム中に、ビデオ広告のＭＰＥＧバージョンを挿入してもよい。加えて、ビデオストリームでないコンテンツを有するウェブページ（例えば、静的なウェブサイト）に対して、同様の状況でフラッシュビデオ広告を使用してもよい。本発明と一貫した少なくともいくつかの実施形態では、ビデオ広告は、オーディオ音量標準化、自動的なスピーチ認識、トランスコーディング、サムネイル発生、レビュー認可、インデックスへの追加等のうちの１つ以上を受けてもよい。
【0146】
２００５年４月２２日に出願され、“例えば、ウェブサイトおよび／またはウェブサイトのカテゴリのような、広告に対するターゲット付け情報を提案すること”と題され、Sumit Agarwal氏、Brian Axe氏、David Gehrking 氏、Ching Law 氏、Andrew Maxwell氏、Gokul Rajaram氏、およびLeora Wiseman氏を発明者として記載する、（“‘７３２特許”として呼ばれ、ここに参照によりその全体が組み込まれる）米国特許出願シリアル番号第11/112,732号に説明したもののような技術を使用して、ウェブサイトを提案してもよい。本発明と一貫した少なくともいくつかの実施形態では、ツール中のすべてのウェブサイトは、ビデオ広告供給システムと互換性のあるビデオコンテンツを持っていなければならない。本発明と一貫した少なくともいくつかの実施形態では、広告主がキーワード、概念、および／または、垂直型カテゴリ等を入力した後で、発生されたウェブサイトのリストから広告主が選んでもよい。これらのキーワードは、ビデオコンテンツに対するメタデータに一致するだろう。本発明と一貫した少なくともいくつかの実施形態では、広告グループに適したビデオコンテンツを有する新しいウェブサイトがあるときはいつでも、広告主のｅ−メールボックス中にメッセージが出現するだろう。
【0147】
戻って、ブロック１６５０と図７を参照すると、ビデオ広告と、ビデオ広告情報とを、さまざまな方法で記憶させてもよい。例えば、本発明と一貫した少なくともいくつかの実施形態では、複数のビデオ広告ファイルを、より大きいビデオファイルサーバ（ＶＦＳ）“パック”中に、一緒に連結させて、ＶＦＳ性能を支援してもよい。より詳細には、小さいビデオファイルの潜在的な急増を取り扱うために、複数のビデオファイルを、“バンドル”または”パック”と呼ばれる単一のＶＦＳファイル中に記憶させることができる。ＡＶＩインデクサが、個々のビデオファイルをＶＦＳ中に記憶する場合、ＡＶＩインデクサは、ＶＦＳバンドル中に挿入し、バンドル内にビデオオフセットを記録する追加的能力を備えているべきである。（“パッカーインデクサ”として呼ばれる）コマンドラインツールで、これを実現してもよい。このツールは、複数のビデオ広告ファイルをＶＦＳパック中に詰め込み、また、インデックス中にファイル供給情報を入力する。これは、（ｉ）ファイルをパック中にコピーすることと、（ｉｉ）パック内にファイルオフセットを注釈することと、（ｉｉｉ）供給情報とともにインデックスを更新することとによって、行われてもよい。インデックスキーは、（コンテンツｉｄ、フォーマット）であってもよく、ここで、“フォーマット”は、ビデオファイル（例えば、ＡＶＩ−３２０）を見ることから導出されてもよい。インデックスは、ＶＦＳバンドルファイル名を含んでもよい。チャンクオフセットは、パック内の絶対的シーク位置を表してもよい。本発明と一貫した少なくとも１つの実施形態では、１組のＭパックが維持されてもよい。このような実施形態では、ビデオコンテンツｉｄモジュロＭをハッシュすることによって、パック名を決定してもよい。
【0148】
本発明と一貫した少なくともいくつかの実施形態では、ビデオ広告は、他のタイプの広告（例えば、テキストのみの広告）として、同じデータ構造またはデータベース中に記憶されてもよい。このような実施形態では、クリエイティブフォーマット（テキスト、画像、ビデオ、フラッシュビデオ等）を列挙する列は、ビデオクリエイティブフォーマットに対応する値を含んでいてもよい。
【0149】
本発明と一貫した少なくともいくつかの実施形態では、広告の時間期間は、アービトレーションの間に考えられてもよい。フィールド（ビデオ＿期間＿ｍｓ）を使用して、ビデオ広告に対する呼出が、戻されるビデオ広告の時間期間を制限するのを許容してもよい。アービトレーションは、広告スポット期間制約（および、おそらくは他の制約）が与えられると、値（例えば、広告スポット毎の、またはビデオドキュメント広告スポット毎の、推定収益）を最適化（例えば、最大化）してもよい。
【0150】
一度、ビデオドキュメントが供給されるのに利用可能になり、広告主がビデオ広告を入力すると、図１３の環境１３００は、ビデオドキュメントとともにビデオ広告を供給してもよい。図１７は、本発明と一貫した方法で、（例えば、ホスト管理された）ビデオコンテンツとともにビデオ広告を供給するための例示的な方法１７００のフロー図である。図１８のメッセージング図に関連付けて、図１７の動作を説明する。クライアントデバイスからドキュメントサーバにビデオドキュメントに対する要求を送信する（ブロック１７１０およびメッセージ１８５０）。応答して、ビデオドキュメントサーバは、１つ以上の広告スポットを含むビデオドキュメントを、要求しているクライアントデバイスに供給する（ブロック１７２０およびメッセージ１８６０）。ビデオドキュメントをクライアントデバイス上にロードする（ブロック１７３０）。ビデオドキュメント中に挿入されたコードを、クライアントデバイス（例えば、ブラウザまたはビデオプレーヤ）により実行して、広告要求を発生させる（ブロック１７４０）。広告要求は、（ｉ）ビデオドキュメント識別子、（ｉｉ）ビデオドキュメントについてのメタデータ、（ｉｉｉ）クライアントデバイスについてのロケーション情報（例えば、インターネットプロトコルアドレス、言語選択）、（ｉｖ）ユーザ情報、（ｖ）所望される広告の数、（ｖｉ）いつ広告が所望されるか（ｖｉｉ）所望される広告の継続時間、（ｖｉｉｉ）ビデオオーナーブロッキング情報、（ｉｘ）ビデオオーナー識別子、（ｘ）前述の任意のものをルックアップするのに使用されてもよい情報等、のうちの1つ以上のものを含んでもよい。ビデオ広告サーバに広告要求を送信する（ブロック１７５０およびメッセージ１８７０）。ビデオ広告サーバは、要求に対して、１組の１つ以上の関連性のある広告を決定する（ブロック１７６０）。次に、ビデオ広告サーバは、決定された１組の広告を、レンダリングするためにクライアントデバイスに送信してもよい（ブロック１７７０およびメッセージ１８８０）。インプレッションおよび／またはユーザ広告アクション（例えば、選択、コンバージョン等）を追跡してもよい（ブロック１７８０）。
【0151】
戻って、ブロック１７６０を参照すると、ビデオドキュメントメタデータ（例えば、タイトル、記述、書き起こし、トリビューンメタデータ、ビデオについての人口統計データ、時間／日付情報、聴衆ロケーション情報、聴衆人口統計情報等）と、さまざまな広告に関係付けられた供給制約および／または関連性情報（例えば、用語、概念、クラスタ、垂直型カテゴリ等）とを比較することによって、関連性のある広告を決定してもよい。広告スポットの数に対して、あまりにも多くの関連性のある広告がある場合、（例えば、価格、関連性、および／または、性能等の関数として）広告をスコア付けして、ビデオドキュメントとともに供給されることになる最終の１組の広告を決定してもよい。広告サーバが関連性のある広告を決定できるように、ビデオドキュメントの再生の間に、メタデータのいくつかまたはすべてのものをビデオ広告サーバに提供してもよいことを想起せよ。その上に、ビデオドキュメントがリンクされることになるウェブページを（インライン、ＸＭＬ提供物（feed）、または、他の何らかのデータ交換メカニズムのいずれか）で注釈することによって、これを行ってもよい。
【0152】
依然としてブロック１７６０を参照して、本発明と一貫した少なくともいくつかの実施形態では、一度広告がシステム中に入ると、’９００出願において説明したようなコンテンツ広告が供給される方法と同様に、広告が供給されるだろう。しかしながら、広告に対するクライアントは、フラッシュクライアント、またはケーブルヘッドエンドにおけるビデオオンデマンドサーバのいずれかであることが予期される。クライアントは、ビデオコンテンツについての情報をルックアップするのに使用されてもよい、ビデオコンテンツ識別子を送ってもよい。代わりに、または、加えて、クライアントは、ビデオコンテンツについての情報を送ってもよい。例えば、何のコンテンツ識別子もクライアントにとって利用可能でないケース（例えば、シンジケーションのケース）を可能にするために、代わりに、コンテンツおよび／または他のドキュメント情報（例えば、ビデオの書き起こし、タイトルのような埋め込まれた構造化データ、記述、ジャンル等）を、ビデオ広告サーバに送ってもよい。いずれのケースでも、ビデオコンテンツについての情報を使用して、ビデオ広告をターゲット付けしてもよい。
【0153】
依然としてブロック１７６０を参照して、本発明と一貫した少なくともいくつかの実施形態では、アップロードされたビデオ広告がトランスコード化され、および／または認可されるまで、アップロードされたビデオ広告を無視してもよい（または、アービトレーションに参加するのに適格性がないとしてみなしてもよい）。
【0154】
図１９は、本発明と一貫した実施形態において使用されてもよい、例示的なビデオプレーヤウェブページ１９００を図示する。ページは、ビデオプレーヤ制御部（例えば、再生、一時停止、スキップ、音量変更、スクリーンサイズ変更等）１９２０を備える、ビデオコンテンツ部分１９１０を含んでもよい。ページ１９００はまた、タイトルライン１９５０、関連する情報（例えば、長さ、アップロードまたはファイル作成の時間、ＵＲＬリンク）１９６０、ビデオストリームから抽出されたさまざまなフレーム１９７０、および、記述テキスト１９８０を含んでもよい。ビデオ検索ボックス１９３０と検索ボタン１９４０も示した。本発明と一貫した少なくともいくつかの実施形態では、ビデオ広告は、ビデオコンテンツと同じ部分１９１０中で再生されてもよい。代わりに、または、加えて、（例えば、ビデオ）広告を、別々の部分において示すことができる。広告がオーディオまたはビデオ広告である場合、ビデオコンテンツが再生される前、再生されている間、または、再生された後に、広告を自動的に再生してもよく、あるいは、ユーザ選択の際のみに、広告自体のプレーヤで提供されてもよい。ビデオコンテンツとともに、広告とビデオ広告を提示する、他の方法が可能であるのは当然である。
【0155】
本発明と一貫した少なくともいくつかの実施形態では、ビデオサーバから供給されたＦＬＶファイル中に埋め込まれたアクションスクリプト中で、広告供給および選択論理が発生してもよい。例えば、サーバは、（ｉ）広告が挿入されるべき場所を指図するＦＬＶ中の情報と、（ｉｉ）ビデオコンテンツｉｄとを埋め込ませてもよい。このような実施形態では、ＦＬＶはまた、実際の広告ファイルのために、ビデオサーバに対する別々の呼出を使用して、広告ＵＲＬをフェッチし、そして、次に広告ビデオを再生させることによって、この情報を解釈するアクションスクリプトコードを含んでもよい。
【0156】
本発明と一貫した代替の実施形態では、ビデオサーバは広告をビデオストリーム中に直接埋め込ませてもよい。しかしながら、このような実施形態では、サーバが、実行中のフレームレートを一致させること（アップロードされたビデオのフレームレートに、広告を一致させること）を実行する必要があるかもしれない。このことはまた、（例えば、ユーザがコンテンツを自身のローカルハードドライブにダウンロードする場合）コンテンツの一部分が再生されるたびに、異なる広告を示すことを難しくする（または、妨げさえする）かもしれない。このシナリオでは、サーバは、再生されることになる個々の広告に、メタデータを提供してもよく、広告がいつ再生されることになるかを、プレーヤに提供してもよい。このようにして、プレーヤは、広告が再生されているときに、ビデオを異なるように取り扱うことができ、ビデオが複数回再生されるときに、広告アービトレーションを再実行することができる。
【0157】
広告は、特定のウェブサイトに対してターゲット付けすることができることを想起せよ。広告とビデオコンテンツの一部分との間に、サイトターゲット付け一致がある場合、次に、ビデオストリーム内の予め定められた点（例えば、開始、中央、終了−図１５の１５３０を想起せよ）において、ビデオ中へと、その広告が挿入されてもよい。
【0158】
ブロック１７８０から、ユーザ広告アクションを追跡してもよいことを想起せよ。本発明と一貫した少なくともいくつかの実施形態では、ユーザが個々の広告をスキップするオプションを持つように、ビデオプレーヤ（例えば、マクロメディアフラッシュプレーヤ）が対応しているかもしれない。広告の開始から、協定できる時間期間（例えば、５秒）内に広告がスキップされなかった場合、次に、広告に対するインプレションは、有効なインプレッションであるとして考えられてもよい。そうでなければ、インプレッションは、無効であると考えられ、発生しなかったと仮定されるかもしれない。本発明と一貫した少なくともいくつかの実施形態では、ユーザが広告を一時停止できるように、ビデオプレーヤが対応していてもよい。このユーザ広告アクションを追跡してもよい。最後に、本発明と一貫した少なくともいくつかの実施形態では、ユーザが前の広告に戻ることができるように、ビデオプレーヤが対応していてもよい。このユーザ広告アクションを追跡してもよい。本発明と一貫した少なくともいくつかの実施形態では、ユーザが前の広告に逆戻りするとき、第１のインプレッションだけがカウントされる。
【0159】
本発明と一貫した少なくともいくつかの実施形態では、デフォルトでビデオ広告を再生するだろう。このような実施形態では、ビデオプレーヤは、広告をミュートおよび／または停止するためのユーザ制御を含んでいるかもしれず、または、含んでいないかもしれない。本発明と一貫した、他の実施形態では、ビデオ広告は、デフォルトで再生されるのではなく、エンドユーザが再生コマンドを入力した場合にのみ再生されるだろう。このような実施形態では、広告に関係付けられたサムネイルおよび／またはテキストが提供されてもよく、あるいは、エンドユーザが再生コマンドを入力することなく、ビデオ広告の一部だけが再生されてもよい。
【0160】
本発明と一貫した少なくともいくつかの実施形態では、レポーティングインターフェースを広告主に提供してもよい。広告主に対して利用可能なレポートは、供給されるインプレッションの数、選択の数、コンバージョンの数等、および／または、他の任意の追跡された情報を含んでもよい。
【0161】
本発明と一貫した少なくともいくつかの実施形態では、ビデオ広告を供給するエンティティは、（ｉ）インプレッション；（ｉｉ）選択（例えば、ビデオが再生されている間にビデオ内のエレメント上でユーザがクリックした場合）；（ｉｉｉ）コンバージョン；（ｉｖ）定期的購読等のうちの１つ以上のベースで広告主に課金してもよい。ビデオ広告が供給されるときに、インプレッションをカウントしてもよい。代わりに、クライアントデバイス上のプレーヤを使用して、インプレッションを追跡してもよい。プレーヤだけが広告が確かに再生されているか否かを決定することができるので、例えば、クライアント（またはプレーヤ）から広告供給システムに戻って、ＡＰＩが提供されてもよい。したがって、エンドユーザが広告を閲覧した（および、おそらくは、広告をスキップする機会を断った）ことをビデオプレーヤが決定した、“有効な”インプレッションに基づいて広告主を課金することができる。また、ビデオ広告のどのくらいの量が再生されたかの関数（例えば、線形関数、多項関数、または、指数関数）として、広告主を課金することができる。
【0162】
図１３の環境１３００は、ビデオサーバ１３１０上に記憶されたビデオ情報１３１５が、ビデオ発行者フロントエンド１３２０を通して、ビデオコンテンツオーナによって入力されたことを仮定する。しかしながら、本発明と一貫した実施形態は、ビデオコンテンツの他の情報源とともに（例えば、ビデオ）広告を供給するのに使用されてもよい。ビデオコンテンツの、他の情報源の例は、ビデオ広告供給システムの（ある程度技術的に先進的であるとして仮定される）大規模パートナーを含んでもよく、および、ビデオ供給システムの（それ程先進的でないとして仮定される）小規模パートナーを含んでもよい。それぞれに対する、例示的なフロントエンドユーザインターフェイスを以下で説明する。いずれのケースでも、パートナーは、ビデオ広告を再生することから発生された売り上げの収益分配を得てもよい。
【0163】
大規模パートナーサイトフロントエンドパートナー自身のウェブサイト上でビデオをホスト管理するパートナーに対して、ビデオ広告供給システムは、このようなパートナーに以下のことを要求してもよい。すなわち、（ｉ）さまざまな使用条件を遵守すること、および、（ｉｉ）パートナーが、ビデオ用広告（ＡＦＶ）を使用することを望む、ビデオコンテンツの各部分に対するインライン注釈、または、広告供給システムによってスキャンされることができ、以下のメタデータ（タイトル、記述、書き起こし、トリビューンメタデータ、ビデオについての人口統計データ）からのいくつかの情報を含むことができるＸＭＬ提供物のいずれかを含むことである。既に上で説明したように、メタデータを使用して、（ｉ）ビデオ広告サーバから適切なビデオ広告を取得してもよく、（ｉｉ）パートナーのウェブサイト上のビデオ提供物中にビデオ広告を挿入してもよい。
【0164】
本発明と一貫した少なくともいくつかの実施形態では、競合フィルタ、および／または文脈フィルタをパートナーに提供してもよい。本発明と一貫した少なくともいくつかの実施形態では、適切なビデオ広告（例えば、パートナーの供給制約のベースで、ビデオドキュメントに関連性があるとみなされる広告）がないというイベントにおいて、デフォルト広告を実行するオプションを、パートナーに提供してもよい。
【0165】
小規模パートナーサイトフロントエンド本発明と一貫した少なくともいくつかの実施形態では、パートナー自身のウェブサイト上でビデオをホスト管理しないが、代わりに第三者ビデオサーバ（例えば、ビデオ広告供給システムと提携した、またはビデオ広告供給システムによって制御されているビデオサーバ）を使用するパートナーは、Ｉフレーム内でパートナー自身のウェブサイト上でストリーミングビデオを示すことができる。ウェブページ上のインライン注釈を再区分するのではなく、ホスト管理されたビデオドキュメントに関係付けられたメタデータおよび／またはウェブページコンテンツの関連性情報（例えば、メタデータ、用語、概念、クラスタ、垂直型カテゴリ等）を使用して、関連性のある広告を決定してもよい。本発明と一貫した少なくともいくつかの実施形態では、第三者ビデオサーバにアップロードされたすべてのビデオクリエイティブは、サービス条件の遵守（すなわち、ポルノグラフィー禁止、アルコール禁止等）に対してチェックされてもよい。
【0166】
大規模パートナーウェブサイトフロントエンドでのケースでのように、本発明と一貫した少なくともいくつかの実施形態では、競合フィルタ、および／または文脈フィルタを、パートナーに提供してもよい。本発明と一貫した少なくともいくつかの実施形態では、適切なビデオ広告（例えば、パートナーの供給制約のベースで、ビデオドキュメントに関連性があるとみなされる広告）がないというイベントにおいて、デフォルト広告を実行するためのオプションを、パートナーに提供してもよい。
【0167】
テキストドキュメントに対するフラッシュビデオ広告の配信（例えば、テキストを含むウェブページ）本発明と一貫した少なくともいくつかの実施形態では、テキストドキュメントのコンテンツオーナ（例えば、テキストを含むウェブページの発行者）は、自身のドキュメント上で、ターゲット付けされたビデオ広告を再生させることを選択してもよい。例えば、ドキュメントのドキュメント情報（例えば、メタデータ概念、クラスタ、用語、キーワード、垂直型カテゴリ等）を使用して、ドキュメントの指定されたエリア中に示されることになる１つ以上のフラッシュビデオ広告をターゲット付けしてもよい。
【0168】
本発明と一貫した少なくともいくつかの実施形態では、フラッシュビデオ広告を、ドキュメントのコンテンツ（例えば、ウェブページまたはウェブサイト）に一致させてもよく、ドキュメントの指定されたエリア中に、フラッシュビデオプレーヤとともにフラッシュビデオを示すだろう。本発明と一貫した少なくともいくつかの実施形態では、フラッシュビデオ広告プレーヤは、以下のような機能のうちの１つ以上のものを持っていてもよい。すなわち、再生ボタン、一時停止ボタン、ユーザがフラッシュビデオ広告内でナビゲートすることを可能にするシークバー、音量制御、製品またはサービスについてのより多くの情報に導かれるために、ユーザがクリックしてもよい、オーバーレイボタンである。本発明と一貫した少なくともいくつかの実施形態では、フラッシュビデオ広告プレーヤは、例えば、広告主によって提供された、および／または、広告ランディングページから抽出されたテキスト情報のような、追加的広告情報を再生してもよい。
【0169】
本発明と一貫した少なくともいくつかの実施形態では、エンドユーザは、フラッシュビデオ広告が再生を開始するために再生ボタンを選択（例えば、ボタン上でクリック）しなければならないだろう。再生ボタン上でのクリックを、（レポーティング、性能追跡、および／または、課金の目的で）インプレッションの証拠として使用してもよい。より多くの情報ボタン上でのクリック、または、フラッシュビデオ自体上でのクリックを、（レポーティング、性能追跡、および／または、課金の目的で）選択（例えば、クリックスルー）の証拠として使用してもよい。
【0170】
本発明と一貫した少なくともいくつかの実施形態では、（例えば、広告主によって指定された、および／または、ビデオ広告から自動的に抽出された）最初および／または最後のサムネイル画像を、フラッシュビデオ広告に関係付けてもよい。ビデオが再生されていないとき（例えば、再生の前、または、全体の広告が再生された後）に、このようなサムネイル画像を表示させることができる。
【0171】
セクション４．５ 結論 上記のことから理解できるように、本発明と一貫した実施形態を使用して、例えば、テレビジョン、ビデオ−ボイスメール、ウェブキャスト、オンラインボイスビデオ−チャット、テレビ電話の会話等のような、ビデオメディアに対して、関連広告を配信することができる。本発明と一貫した実施形態は、ビデオドキュメント上の広告スポットに対して、より多くの広告主が競合できるようにするアービトレーションをサポートする。この増加された競合は、オーディオドキュメント発行者に対する広告収益を増加させるだろう。
【符号の説明】
【0172】
２１０……広告主２２０……広告エントリ、メンテナンス、および配信システム
２３０……広告消費者
３１０……広告サーバ
３２０……検索エンジン
３３０……コンテンツサーバ
３３２……オフラインコンテンツプロバイダ
３３４……オフライン広告スポットプロパティ
３４０……Ｅ−メールサーバ
３５０……ユーザデバイス
３６０……ビデオサーバ
３７０……テレビ電話サービスプロバイダ機構