(57)【要約】  本発明の実施形態によれば、発行者サーバ、第１コンテンツサーバ、及び第２コンテンツサーバのパフォーマンスの決定が行われる。発行者サーバのパフォーマンス、第１コンテンツサーバのパフォーマンス、及び第２コンテンツサーバのパフォーマンスに基づいて、待ち時間情報が決定される。待ち時間情報は、発行者サーバ、第１コンテンツサーバ、及び第２コンテンツサーバのそれぞれに関連したコンテンツ読み込み時間の長さを表している。
2010536100.tif 000002
【特許請求の範囲】
【請求項１】
発行者サーバのパフォーマンスを決定する段階と、
第１コンテンツサーバのパフォーマンスを決定する段階と、
第２コンテンツサーバのパフォーマンスを決定する段階と、
前記発行者サーバのパフォーマンス、前記第１コンテンツサーバのパフォーマンス、及び前記第２コンテンツサーバのパフォーマンスに基づいて、待ち時間情報を決定する段階と
を有し、
前記待ち時間情報は、前記発行者サーバ、前記第１コンテンツサーバ、及び前記第２コンテンツサーバのそれぞれに関連したコンテンツ読み込み時間の長さを表すことを特徴とする方法。
【請求項２】
前記発行者サーバのパフォーマンスが、
前記発行者サーバから発行者コンテンツを取り出すためのリクエスト時間と、
前記発行者コンテンツをレンダリングするためのレンダリング時間と
から成ることを特徴とする請求項１に記載の方法。
【請求項３】
前記発行者サーバのパフォーマンスを決定する段階が、
スクリプトを含んだドキュメントをリクエストする段階と、
前記リクエストに応答して、前記ドキュメントを受信する段階と、
受け取った指示子に応じて、前記スクリプトを実行し、前記発行者サーバのパフォーマンスを決定する段階と
を含み、
前記リクエストには、前記指示子が含まれていることを特徴とする請求項１に記載の方法。
【請求項４】
前記ドキュメントが、ユニフォームリソースロケータ（ＵＲＬ）によって特定され、
前記指示子が、前記ＵＲＬに付加された引数であることを特徴とする請求項３に記載の方法。
【請求項５】
ユーザインタフェースを表示する段階と、
前記発行者サーバのパフォーマンスを前記ユーザインタフェースに表示する段階と
をさらに有することを特徴とする請求項１に記載の方法。
【請求項６】
前記発行者サーバのパフォーマンスを表示する段階が、
前記第１コンテンツサーバに関連したコンテンツ読み込み時間の長さを表す実行時間情報を前記ユーザインタフェースに表示する段階を含むことを特徴とする請求項５に記載の方法。
【請求項７】
前記第１コンテンツサーバのパフォーマンスが、
前記第１コンテンツサーバに広告をリクエストするための第１広告リクエスト時間と、
前記第２コンテンツサーバに広告をリクエストするための第２広告リクエスト時間と
から成ることを特徴とする請求項１に記載の方法。
【請求項８】
前記第１コンテンツサーバのパフォーマンスを決定する段階が、
スクリプトを含んだドキュメントをリクエストする段階と、
前記リクエストに応答して、前記ドキュメントを受信する段階と、
受け取った指示子に応じて、前記スクリプトを実行し、前記第１コンテンツサーバのパフォーマンスを決定する段階と
を含み、
前記リクエストには、前記指示子が含まれていることを特徴とする請求項１に記載の方法。
【請求項９】
前記ドキュメントが、ユニフォームリソースロケータ（ＵＲＬ）によって特定され、
前記指示子が、前記ＵＲＬに付加された引数であることを特徴とする請求項８に記載の方法。
【請求項１０】
ユーザインタフェースを表示する段階と、
前記第１コンテンツサーバのパフォーマンスを前記ユーザインタフェースに表示する段階と
をさらに有することを特徴とする請求項８に記載の方法。
【請求項１１】
前記第１コンテンツサーバのパフォーマンスを表示する段階が、
前記第１コンテンツサーバに関連したコンテンツ読み込み時間の長さを表す実行時間情報を前記ユーザインタフェースに表示する段階を含むことを特徴とする請求項１０に記載の方法。
【請求項１２】
前記第２コンテンツサーバのパフォーマンスが、
前記第１コンテンツサーバと前記第２コンテンツサーバとのうちの少なくとも１つからの広告をレンダリングするためのレンダリング時間から成ることを特徴とする請求項１に記載の方法。
【請求項１３】
ユニフォームリソースロケータ（ＵＲＬ）によって特定されるドキュメントをリクエストする段階であって、前記ドキュメントは、スクリプトへの参照を含み、前記リクエストには、前記ＵＲＬに付加された第１引数が含まれる段階と、
前記ＵＲＬによって特定される前記ドキュメントをリクエストする段階であって、前記ドキュメントは、前記スクリプトへの参照を含み、前記リクエストには、前記ＵＲＬに付加された第２引数が含まれる段階と、
前記スクリプトを含んだ前記ドキュメントを受信する段階と、
前記第１引数及び前記第２引数に従って、前記スクリプトを実行し、発行者サーバ待ち時間及び第１コンテンツサーバ待ち時間を決定する段階と、
前記発行者サーバ待ち時間及び前記第１コンテンツサーバ待ち時間に基づいて、第２コンテンツサーバ待ち時間を決定する段階と
を有することを特徴とする方法。
【請求項１４】
前記発行者サーバ待ち時間、前記第１コンテンツサーバ待ち時間、及び前記第２コンテンツサーバ待ち時間のうちの少なくとも１つをユーザインタフェースに表示する段階をさらに有し、
前記ユーザインタフェースには、前記発行者サーバ、前記第１コンテンツサーバ、及び前記第２コンテンツサーバのうちの少なくとも１つに関連したコンテンツ読み込み時間の長さを表す実行時間情報が含まれることを特徴とする請求項１３に記載の方法。
【請求項１５】
発行者サーバ、第１コンテンツサーバ、及び第２コンテンツサーバに関連したパフォーマンスを決定するように構成されたプロセッサと、
前記発行者サーバのパフォーマンス、前記第１コンテンツサーバのパフォーマンス、及び前記第２コンテンツサーバのパフォーマンスに基づいて、待ち時間情報を決定するように構成されたクライアントデバイスと
を具備し、
前記待ち時間情報は、前記発行者サーバ、前記第１コンテンツサーバ、及び前記第２コンテンツサーバのそれぞれに関連したコンテンツ読み込み時間の長さを表すことを特徴とするシステム。
【請求項１６】
前記プロセッサが、
ユニフォームリソースロケータ（ＵＲＬ）によって特定されるドキュメントをリクエストし、ここで、前記ドキュメントは、スクリプトを含み、前記リクエストには、前記ＵＲＬに付加された第１引数が含まれ、
前記ＵＲＬによって特定される前記ドキュメントをリクエストし、ここで、前記ドキュメントは、前記スクリプトを含み、前記リクエストには、前記ＵＲＬに付加された第２引数が含まれ、
前記スクリプトを含んだ前記ドキュメントを受信し、
前記第１引数及び前記第２引数に従って、前記スクリプトを実行し、発行者サーバ待ち時間及び第１コンテンツサーバ待ち時間を決定し、
前記発行者サーバ待ち時間及び前記第１コンテンツサーバ待ち時間に基づいて、第２コンテンツサーバ待ち時間を決定するようにさらに構成されることを特徴とする請求項１５に記載のシステム。
【請求項１７】
前記クライアントデバイスが、
前記発行者サーバのパフォーマンス、前記第１コンテンツサーバのパフォーマンス、及び前記第２コンテンツサーバのパフォーマンスのうちの少なくとも１つをユーザインタフェースに表示するようにさらに構成され、
前記ユーザインタフェースには、前記発行者サーバ、前記第１コンテンツサーバ、及び前記第２コンテンツサーバのうちの少なくとも１つに関連したコンテンツ読み込み時間の長さを表す実行時間情報が含まれることを特徴とする請求項１５に記載のシステム。
【請求項１８】
１つ以上のリモートロケーションにコンテンツをリクエストするように構成されたプロセッサと、
前記プロセッサに動作可能なように接続され、待ち時間情報を表示するように構成されたインタフェースと
を具備し、
前記コンテンツには、前記リクエストに関連した前記待ち時間情報を決定するための複数のコンピュータ実行可能命令が含まれ、
前記待ち時間情報には、前記インタフェースへの前記コンテンツの前記表示に関連した前記１つ以上のリモートロケーションに関連した待ち時間が含まれることを特徴とするシステム。
【請求項１９】
複数の命令を格納したコンピュータ可読媒体であって、
前記複数の命令は、プロセッサによって実行されたとき、
発行者サーバに関連したパフォーマンスを決定する過程と、
第１コンテンツサーバに関連したパフォーマンスを決定する過程と、
第２コンテンツサーバに関連したパフォーマンスを決定する過程と、
前記発行者サーバのパフォーマンス、前記第１コンテンツサーバのパフォーマンス、及び前記第２コンテンツサーバのパフォーマンスに基づいて、待ち時間情報を決定する過程と
を前記プロセッサに実行させ、
前記待ち時間情報は、前記発行者サーバ、前記第１コンテンツサーバ、及び前記第２コンテンツサーバのそれぞれに関連したコンテンツ読み込み時間の長さを表すことを特徴とするコンピュータ可読媒体。
【請求項２０】
発行者サーバに関連したパフォーマンスを決定する手段と、
第１コンテンツサーバに関連したパフォーマンスを決定する手段と、
第２コンテンツサーバに関連したパフォーマンスを決定する手段と、
前記発行者サーバのパフォーマンス、前記第１コンテンツサーバのパフォーマンス、及び前記第２コンテンツサーバのパフォーマンスに基づいて、待ち時間情報を決定する手段と
を具備し、
前記待ち時間情報は、前記発行者サーバ、前記第１コンテンツサーバ、及び前記第２コンテンツサーバのそれぞれに関連したコンテンツ読み込み時間の長さを表すことを特徴とするシステム。
【請求項２１】
コンテンツをリクエストする段階であって、前記リクエストは、前記コンテンツを指し示すユニフォームリソースロケータ（ＵＲＬ）であり、前記ＵＲＬは、付加された引数を含む段階と、
前記コンテンツを第１ユーザインタフェース中のコンテンツページ内に読み込む段階と、
第２ユーザインタフェースを表示する段階と、
前記ＵＲＬに付加された前記引数に従って、前記コンテンツページに関連した１つ以上のコンテンツアイテムを前記第２ユーザインタフェースに表示する段階と、
前記１つ以上のコンテンツアイテムに関連した１つ以上の属性を前記第２ユーザインタフェースに表示する段階と
を有することを特徴とする方法。
【請求項２２】
前記コンテンツを第１ユーザインタフェース中のコンテンツページ内に読み込む段階が、
前記コンテンツページの一部分を前記第１ユーザインタフェースに読み込む段階を含み、
前記一部分は、発行者サーバからのコンテンツから成ることを特徴とする請求項２１に記載の方法。
【請求項２３】
前記第２ユーザインタフェースを表示する段階が、
前記コンテンツに対するリクエストに応答して、スクリプトを含んだドキュメントを受信する段階と、
受け取った前記引数に応じて、前記スクリプトを実行し、前記第２ユーザインタフェースを表示する段階と
を含むことを特徴とする請求項２１に記載の方法。
【請求項２４】
前記１つ以上のコンテンツアイテムが、１つ以上の広告から成ることを特徴とする請求項２１に記載の方法。
【請求項２５】
前記１つ以上のコンテンツアイテムを表示する段階が、
１つ以上のコンテンツサーバから受信した前記１つ以上のコンテンツアイテムのコピーを保存する段階と、
第１ユーザインタフェースへの前記コンテンツページの読み込みの間に、前記１つ以上のコンテンツアイテムを前記第２ユーザインタフェースに表示する段階と
を含むことを特徴とする請求項２１に記載の方法。
【請求項２６】
前記１つ以上のコンテンツアイテムを表示する段階が、
前記１つ以上のコンテンツアイテムに関連した１つ以上の識別子を取得する段階と、
第２ユーザインタフェースを開く段階と、
前記１つ以上の識別子を使用して、前記１つ以上のコンテンツサーバに前記１つ以上のコンテンツアイテムをリクエストする段階と、
前記１つ以上のコンテンツアイテムを前記第２ユーザインタフェースにレンダリングする段階と
を含むことを特徴とする請求項２１に記載の方法。
【請求項２７】
前記属性が、各コンテンツアイテムに関連した読み込み時間であることを特徴とする請求項２１に記載の方法。
【請求項２８】
前記属性が、前記１つ以上のコンテンツアイテムに関連した総読み込み時間であることを特徴とする請求項２１に記載の方法。
【請求項２９】
前記１つ以上のコンテンツアイテムに関連したソースコードを前記第２ユーザインタフェースに表示する段階をさらに有することを特徴とする請求項２１に記載の方法。
【請求項３０】
前記第２ユーザインタフェースに関連した前記ソースコードを保存する段階をさらに有することを特徴とする請求項２９に記載の方法。
【請求項３１】
保存した前記ソースコードをユーザインタフェースに読み込み段階と、
前記１つ以上のコンテンツアイテムを前記ユーザインタフェースにレンダリングする段階と
をさらに有することを特徴とする請求項３０に記載の方法。
【請求項３２】
コンテンツページの第１部分を第１ユーザインタフェースに読み込む段階と、
第２ユーザインタフェースを表示する段階と、
前記コンテンツページの第２部分を前記第２ユーザインタフェースに読み込む段階と、
１つ以上のコンテンツアイテムに関連した１つ以上の属性を前記第２ユーザインタフェースに表示する段階と
を有し、
前記第１部分は、発行者サーバから受信したコンテンツから成り、
前記第２部分は、１つ以上のコンテンツサーバから受信した前記１つ以上のコンテンツアイテムから成ることを特徴とする方法。
【請求項３３】
前記属性が、各コンテンツアイテムに関連した読み込み時間であることを特徴とする請求項３２に記載の方法。
【請求項３４】
前記属性が、前記１つ以上のコンテンツアイテムに関連した総読み込み時間であることを特徴とする請求項３２に記載の方法。
【請求項３５】
コンテンツページの第１部分を第１ユーザインタフェースに読み込む段階と、
第２ユーザインタフェースを表示する段階と、
前記コンテンツページの第２部分に関連したソースコードを前記第２ユーザインタフェースに表示する段階と、
前記ソースコードをファイルに保存する段階と
を有し、
前記第１部分は、発行者サーバから受信したコンテンツから成り、
前記第２部分は、１つ以上のコンテンツサーバから受信した１つ以上のコンテンツアイテムから成ることを特徴とする方法。
【請求項３６】
前記ファイルをユーザインタフェース上に開く段階をさらに有し、
前記ユーザインタフェースは、前記ファイル中の前記ソースコードをレンダリングすることを特徴とする請求項３５に記載の方法。
【請求項３７】
発行者サーバと、
１つ以上のコンテンツサーバと、
クライアントデバイスと
を具備し、
前記発行者サーバは、コンテンツページの第１部分を前記クライアントデバイスに送信するように構成され、
前記第１部分は、発行者コンテンツから成り、
前記１つ以上のコンテンツサーバは、前記コンテンツページの第２部分を前記クライアントデバイスに送信するように構成され、
前記第２部分は、１つ以上のコンテンツアイテムから成り、
前記クライアントデバイスは、
前記コンテンツページの前記第１部分を第１ユーザインタフェースに読み込み、
前記コンテンツページの前記第２部分を第２ユーザインタフェースに読み込み、
前記１つ以上のコンテンツアイテムに関連した１つ以上の属性を前記第２ユーザインタフェースに表示するように構成されることを特徴とするシステム。
【請求項３８】
クライアントデバイスと、
プロセッサと
を具備し、
前記クライアントデバイスは、１つ以上のコンテンツサーバから受信したコンテンツページに関連した１つ以上のコンテンツアイテムのコピーを保存するように構成され、
前記プロセッサは、
ユーザインタフェースを生成し、
保存された前記１つ以上のコンテンツアイテムの結合ソースコードを生成し、
前記結合ソースコードを前記ユーザインタフェースに掲載するように構成されることを特徴とするシステム。
【請求項３９】
発行者サーバと、
サーバプロセッサと
を具備し、
前記発行者サーバは、１つ以上のコンテンツアイテムに関連した１つ以上のコンテンツアイテム識別子を取得するように構成され、
前記サーバプロセッサは、
ユーザインタフェースを生成し、
コンテンツサーバへのリクエストを生成して、前記１つ以上のコンテンツアイテム識別子に関連した前記１つ以上のコンテンツアイテムをリクエストし、
前記１つ以上のコンテンツアイテムを前記ユーザインタフェースにレンダリングするように構成されることを特徴とするシステム。
【請求項４０】
コンテンツページの第１部分を第１ユーザインタフェースに読み込む手段と、
第２ユーザインタフェースを表示する手段と、
前記コンテンツページの第２部分を前記第２ユーザインタフェースに読み込む手段と、
１つ以上のコンテンツアイテムに関連した１つ以上の属性を前記第２ユーザインタフェースに表示する手段と
を具備し、
前記第１部分は、発行者サーバから受信したコンテンツから成り、
前記第２部分は、１つ以上のコンテンツサーバから受信した前記１つ以上のコンテンツアイテムから成ることを特徴とするシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、情報の取り出しに関する。
【背景技術】
【０００２】
ウェブページ上に表示されるコンテンツは、クライアントデバイスによるウェブページのレンダリングの間に生成された複数のコンテンツアイテムリクエストに応答して、１つ以上のコンテンツアイテムサーバによって生成されることがある。複数のコンテンツアイテムリクエストは、ウェブページのレンダリングと同期して生成される。同様に、複数のコンテンツアイテムリクエストに応答して受信された複数のコンテンツアイテムは、ウェブページのレンダリングと同期して処理される。例えば、ウェブページがレンダリングされる際、ＪａｖａＳｃｒｉｐｔが実行され、第１コンテンツサーバに広告をリクエストする。同様に、第１コンテンツサーバは、第２コンテンツサーバに広告をリクエストする。広告が同時に取り出された場合、ウェブページのレンダリングは、リクエストした広告がコンテンツサーバから受信されるまで待たされる。広告が受信され、レンダリング、例えば、ウェブページ上に広告が表示されると、ウェブページの残りの部分のレンダリングが再開される。
【０００３】
同期的なコンテンツアイテム取り出しの欠点は、コンテンツアイテムサーバの処理が遅い場合に、ウェブページの残りの部分のレンダリングが遅れることである。同期的なコンテンツアイテム処理の潜在的な影響を軽減するために、ウェブページ発行者は、遅延源、すなわち、低速な又は一時的に動作不能なコンテンツアイテムサーバを特定するとともに、総待ち時間を算出することを試みている。しかしながら、異なるサーバに関連した複数の待ち時間を算出するために、ウェブページのレンダリングから複数のＨＴＴＰリクエスト及びレスポンスをコンパイルすることは、多くの場合、複雑な作業となる。例えば、複数のＨＴＴＰリクエスト及びレスポンスは、第１コンテンツサーバによって返されるが、ウェブページ自体には現れないので、それらを扱い慣れていない。さらに、特定のサーバ、例えば、第２コンテンツサーバ、が遅延源であると判断できたとしても、第２コンテンツサーバの運用者にその遅延を説明することは困難である。
【発明の概要】
【課題を解決するための手段】
【０００４】
いくつかの実施態様によれば、発行者サーバ、第１コンテンツサーバ、及び第２コンテンツサーバのパフォーマンスの決定が行われる。発行者サーバのパフォーマンス、第１コンテンツサーバのパフォーマンス、及び第２コンテンツサーバのパフォーマンスに基づいて、待ち時間情報が決定される。待ち時間情報は、発行者サーバ、第１コンテンツサーバ、及び第２コンテンツサーバのそれぞれに関連したコンテンツ読み込み時間の長さを表す。
【０００５】
いくつかの実施態様によれば、第１動作に対するスクリプトへの参照を含んだドキュメントのユニフォームリソースロケータ（ＵＲＬ）が指定される。ＵＲＬには、第１引数が付加される。第２動作に対するスクリプトへの参照を含んだドキュメントのＵＲＬが指定される。ＵＲＬには、第２引数が付加される。リクエストに応答して、スクリプトを含んだドキュメントが受信される。第１動作に対するスクリプトが実行され、発行者サーバ待ち時間が決定される。第２動作に対するスクリプトが実行され、第１コンテンツサーバ待ち時間が決定される。発行者サーバ待ち時間及び第１コンテンツサーバ待ち時間に基づいて、第２コンテンツサーバ待ち時間が決定される。
【０００６】
いくつかの実施態様によれば、システムは、発行者サーバ、第１コンテンツサーバ、及び第２コンテンツサーバに関連したパフォーマンスを決定するように構成されたプロセッサと、発行者サーバのパフォーマンス、第１コンテンツサーバのパフォーマンス、及び第２コンテンツサーバのパフォーマンスに基づいて、待ち時間情報を決定するように構成されたクライアントデバイスとを具備する。待ち時間情報は、発行者サーバ、第１コンテンツサーバ、及び第２コンテンツサーバのそれぞれに関連したコンテンツ読み込み時間の長さを表す。いくつかの実施態様によれば、システムは、１つ以上のリモートロケーションにコンテンツをリクエストするように構成されたプロセッサと、該プロセッサに動作可能なように接続され、待ち時間情報を表示するように構成されたインタフェースとを具備する。コンテンツには、リクエストに関連した待ち時間情報を決定するための複数のコンピュータ実行可能命令が含まれる。待ち時間情報には、インタフェースへのコンテンツの表示に関連した１つ以上のリモートロケーションに関連した待ち時間が含まれる。
【０００７】
いくつかの実施態様によれば、コンテンツのリクエストが行われる。ここで、リクエストは、コンテンツを指し示すユニフォームリソースロケータ（ＵＲＬ）であり、該ＵＲＬは、付加された引数を含む。リクエストされたコンテンツは、第１ユーザインタフェース中のコンテンツページ内に読み込まれる。次いで、第２ユーザインタフェースが表示される。次いで、ＵＲＬに付加された引数に従って、コンテンツページに関連した１つ以上のコンテンツアイテムが、第２ユーザインタフェースに表示される。さらに、１つ以上のコンテンツアイテムに関連した１つ以上の属性が、第２ユーザインタフェースに表示される。
【０００８】
いくつかの実施態様によれば、コンテンツページの第１部分が、第１ユーザインタフェースに読み込まれる。ここで、第１部分は、発行者サーバから受信したコンテンツから成る。次いで、第２ユーザインタフェースが表示される。コンテンツページの第２部分が、第２ユーザインタフェースに読み込まれる。ここで、第２部分は、１つ以上のコンテンツサーバから受信した１つ以上のコンテンツアイテムから成る。さらに、１つ以上のコンテンツアイテムに関連した１つ以上の属性が、第２ユーザインタフェースに表示される。
【０００９】
いくつかの実施態様によれば、システムは、発行者サーバと、１つ以上のコンテンツサーバと、クライアントデバイスとを具備する。発行者サーバは、コンテンツページの第１部分をクライアントデバイスに送信するように構成される。ここで、第１部分は、発行者コンテンツから成る。さらに、１つ以上のコンテンツサーバは、コンテンツページの第２部分をクライアントデバイスに送信するように構成される。ここで、第２部分は、１つ以上のコンテンツアイテムから成る。クライアントデバイスは、コンテンツページの第１部分を第１ユーザインタフェースに読み込み、コンテンツページの第２部分を第２ユーザインタフェースに読み込み、１つ以上のコンテンツアイテムに関連した１つ以上の属性を第２ユーザインタフェースに表示するように構成される。
【００１０】
いくつかの実施態様によれば、システムは、クライアントデバイスと、プロセッサと
を具備する。クライアントデバイスは、１つ以上のコンテンツサーバから受信したコンテンツページに関連した１つ以上のコンテンツアイテムのコピーを保存するように構成される。さらに、プロセッサは、ユーザインタフェースを生成し、保存された１つ以上のコンテンツアイテムの結合ソースコードを生成し、結合ソースコードをユーザインタフェースに掲載するように構成される。
【００１１】
いくつかの実施態様によれば、システムは、発行者サーバと、サーバプロセッサとを具備する。発行者サーバは、１つ以上のコンテンツアイテムに関連した１つ以上のコンテンツアイテム識別子を取得するように構成される。サーバプロセッサは、ユーザインタフェースを生成し、１つ以上のコンテンツアイテム識別子に関連した１つ以上のコンテンツアイテムをリクエストする第１コンテンツサーバへのリクエストを生成し、１つ以上のコンテンツアイテムをユーザインタフェースにレンダリングするように構成される。
【図面の簡単な説明】
【００１２】
【図１】コンテンツサーバにコンテンツをリクエストするための例示的なシステムの構成図である。
【図２】待ち時間寄与率を決定するための例示的なプロセスである。
【図３】待ち時間寄与率を決定するための別の例示的なプロセスである。
【図４】ＮｏＦｅｔｃｈモードの出力を表示する例示的なインタフェースを図示する。
【図５】ＮｏＲｅｎｄｅｒモードの出力を表示する例示的なインタフェースを図示する。
【図６】待ち時間発生源を決定するための例示的なプロセスである。
【図７】１つ以上のコンテンツサーバに関連した待ち時間を決定するための例示的なプロセスである。
【図８】１つ以上のコンテンツサーバに関連した待ち時間を決定するための別の例示的なプロセスである。
【図９】１つ以上のコンテンツサーバに関連した待ち時間を決定するための別の例示的なプロセスである。
【図１０】例示的なユーザインタフェースを図示したものである。
【発明を実施するための形態】
【００１３】
図１は、１つ以上のコンテンツサーバにコンテンツをリクエストするための例示的なシステム１０の構成図である。一実施形態において、コンテンツは、広告であってよく、コンテンツサーバは、コンテンツサーバであってよい。また、異なるタイプのコンテンツがリクエストされてもよい。
【００１４】
一実施形態において、クライアントシステム１００は、ネットワーク、例えば、インターネットを介してアクセス可能なコンテンツ（例えば、訪問したウェブページ）を表示するように構成される。クライアントシステム１００は、例えば、ウェブブラウザ、又は、ネットワークナビゲーションソフトウェアを実行する演算デバイスなどであってよい。クライアントシステム１００が訪問したウェブアドレス（例えば、ユニフォームリソースロケータ（ＵＲＬ））は、対応するウェブページをホスティングする発行者１０２、例えば、サーバ、を特定するために解析される。この実施例では、クライアントシステム１００は、ウェブページコンテンツ１０６のために、発行者１０２にウェブページコンテンツリクエスト１０４を送信する。発行者１２０は、リクエトに応答して、ウェブページコンテンツ１０６を、例えば、ＪａｖａＳｃｒｉｐｔを含むＨＴＭＬドキュメントとして、クライアントシステム１００に提供する。ウェブページコンテンツ１０６は、１つ以上のコンテンツ表示を含んでよい。一実施形態では、コンテンツ表示は、コンテンツサーバによって供給される広告のための広告スロットを有する。また、その他のコンテンツ表示が用いられてもよい。
【００１５】
発行者１０２によって提供されるウェブページコンテンツ１０６は、一連の命令群１０８への参照を含む。一実施形態では、命令群１０８は、格納命令１０８ａと、タイミング命令１０８ｂと、リクエスト命令１０８ｃとを含む。それらの命令は、リクエストしたコンテンツ、例えば、広告をレンダリング及び表示するために使用される。一実施形態では、命令群１０８は、第１コンテンツサーバ１３４、例えば、コンテンツサーバ、によって提供されるとともに、クライアントシステム１００において、例えば、ウェブブラウザに関連したキャッシュなどに格納される。
【００１６】
ウェブページコンテンツ１０６は、１つ以上のコンテンツサーバからのコンテンツを表示するように構成された複数のコンテンツスロット１１２〜１２０を定義してよい。一実施形態では、複数のコンテンツスロット１１２〜１２０は、ＨＴＭＬタグで定義される広告スロットである。命令群１０８は、複数のコンテンツリクエスト１２２〜１３０を生成する。複数のコンテンツリクエスト１２２〜１３０は、複数のコンテンツスロット１１２〜１２０を満たすコンテンツをリクエストするために発行される。一実施形態では、複数のリクエスト１２２〜１３０は、データ格納部１３２、例えば、バッファ１３２、に格納され、次いで、１つ以上のリクエスト１３６としてコンテンツサーバ１３４に送信される。
【００１７】
一実施形態では、第１コンテンツサーバ１３４は、受信した個々の又は結合されたリクエスト１３６を処理し、特定したコンテンツ１３８をクライアントシステム１００に返す。別の実施形態では、第１コンテンツサーバ１３４は、クライアントシステム１００から受信した個々の又は結合されたリクエスト１３６を処理し、結合されたレスポンス１３７をクライアントシステム１００に送信する。例えば、レスポンスは、ＨＴＭＬ又はＪａｖａＳｃｒｉｐｔであってよい。第１コンテンツサーバ１３４からクライアントシステム１００への結合されたレスポンス１３７は、コンテンツアイテムをリクエストする１つ以上のリクエスト１４０を第２コンテンツサーバ１４２に送信するように、クライアントシステム１００に命令する。次いで、第２コンテンツサーバ１４２は、例えば、特定したコンテンツ１４４をクライアントシステム１００に返す。次いで、特定されたコンテンツ１３８及び／又は特定されたコンテンツ１４４は、対応するコンテンツスロット、例えば、複数のコンテンツスロット１１２，１１４，１１６に発行者のウェブページの一部分として表示される。
【００１８】
第１コンテンツサーバ１３４の一例として、Ｇｏｏｇｌｅ（登録商標）コンテンツサーバが挙げられる。リクエストは、Ｇｏｏｇｌｅコンテンツサーバに、ウェブページ上のコンテンツスロットを広告で埋めるよう求める。続いて、Ｇｏｏｇｌｅコンテンツサーバは、広告を特定及び提供するか、又は、第２コンテンツサーバ１４２、例えば、第三者のコンテンツサーバ、に広告をリクエストする。２つのコンテンツサーバ１３４，１４２だけに言及したが、１つのウェブページに対して、２つ以上のコンテンツサーバがコンテンツを提供してもよい。
【００１９】
クライアントシステム１００が発行者１０２、第１コンテンツサーバ１３４、及び／又は第２コンテンツサーバ１４２にコンテンツをリクエストした際、待ち時間による遅延が生じることがある。例えば、待ち時間遅延は、低いネットワーク速度、発行者サーバ１０２の遅れ、第１コンテンツサーバの遅れ、及び／又は、第２コンテンツサーバの遅れなどのさまざまな問題に関係している。クライアントシステム１００のユーザは、ウェブページの読み込みに要する総待ち時間しか認識できない。したがって、発行者サーバ１０２、第１コンテンツサーバ１３４、及び第２コンテンツサーバ１４２に起因する待ち時間遅延寄与率を決定することは、実証困難である。
【００２０】
以上の例で説明したように、ウェブページを表示するための総待ち時間（Ｌ）は、ネットワークの速度と、ネットワークの待ち時間を含む発行者サーバ１０２の速度（Ｌ１）と、第１コンテンツサーバ１３４の速度（Ｌ２）と、第２コンテンツサーバ１４２の速度（Ｌ３）とに起因する。したがって、例えば、総待ち時間の算出は、式Ｌ＝Ｌ１＋Ｌ２＋Ｌ３によって行うことができる。
【００２１】
図２を参照すると、いくつかの実施形態によれば、待ち時間寄与率を決定するための例示的なプロセス２００は、発行者サーバのパフォーマンスの決定から始まる（ステップ２０２）。発行者サーバ１２０のパフォーマンスを決定するために、発行者サーバ１０２へのコンテンツのリクエストは、引数（又は、その他の指示子）を含むように生成される。例えば、「http://www.webpage.com?google_nofetch」のように、引数「google_nofetch」がウェブページコンテンツ所在地のＵＲＬに付加される。この場合、ＮｏＦｅｔｃｈモードが実行される。
【００２２】
リクエストしたＵＲＬに関連したドキュメントが、コンテンツの所在地から受信される。ドキュメントは、ウェブページコンテンツ、メディア、テキスト、ダウンロード可能なファイル等であってよい。発行者サーバ１０２に関連したパフォーマンス、すなわち、待ち時間が決定される。いくつかの実施形態では、ウェブページコンテンツ１０６内のコンテンツサービング（例えば、ＪａｖａＳｃｒｉｐｔ）タグは、診断ロジックを実行する。例えば、ウェブページコンテンツ１０６内のスクリプトファイルは、発行者サーバ１０２に関連した待ち時間などのさまざまな条件についてテストを行い、ユーザインタフェースに情報を書き出す。
【００２３】
ＮｏＦｅｔｃｈモードでは、ウェブページコンテンツ１０６内のスクリプトファイルは、第１コンテンツサーバ１３４からのコンテンツアイテムの読み込み、すなわち、広告のために第１コンテンツサーバ１３４になされるリクエストを止めさせる。例えば、第１コンテンツサーバ１３４に送信されたすべてのリクエストは、ＮＯ−ＯＰ命令に置き換えられ、それらのリクエストは、（デバッグトレースを除き、）何も行わない。したがって、ＮｏＦｅｔｃｈモードでの動作は、ウェブページに対する発行者サーバ１０２のベースラインパフォーマンス、すなわち、発行者がウェブページに１つも広告を追加しなかった場合にユーザが体験するＮｏＦｅｔｃｈ待ち時間（Ｌ１）を確定する。
【００２４】
次に、第１コンテンツサーバ１３４に関連したパフォーマンスが決定される（ステップ２０４）。第１コンテンツサーバ１３４のパフォーマンスを決定するために、引数（又は、その他の指示子）がウェブページ所在地のＵＲＬに含められる。例えば、「http://www.webpage.com?google_norender」のように、引数「google_norender」がウェブページコンテンツ所在地のＵＲＬに追加される。この場合、ＮｏＲｅｎｄｅｒモードが実行される。
【００２５】
いくつかの実施形態では、ウェブページコンテンツ１０６内のコンテンツサービング（例えば、ＪａｖａＳｃｒｉｐｔ）タグは、診断ロジックを実行する。例えば、ウェブページコンテンツ１０６内のスクリプトファイルは、第１コンテンツサーバ１３４に関連したパフォーマンス、すなわち、待ち時間などのさまざまな条件をテストするとともに、ユーザインタフェースに情報を書き出す。
【００２６】
ＮｏＲｅｎｄｅｒモードでは、ウェブページコンテンツ１０６内のスクリプトファイルは、第１コンテンツサーバ１３４がコンテンツアイテムを返すこと、すなわち、リクエストが第１コンテンツサーバ１３４に送信され、広告が取り出されることは許可する。しかしながら、第１コンテンツサーバ１３４が広告を取り出した後、スクリプトファイルは、ウェブページ上に広告をレンダリングさせない。例えば、ウェブページ上の複数のコンテンツスロット１１２，１１４，１１６に実際の広告をレンダリングする代わりに、複数のコンテンツスロット１１２，１１４，１１６中の広告に関連したコードが表示されてもよい。したがって、ＮｏＲｅｎｄｅｒモードの動作は、広告を取り出すがそれをレンダリングしない場合の第１コンテンツサーバ１３４のパフォーマンス、すなわち、待ち時間を確定する。第１コンテンツサーバ１３４に関連した待ち時間は、ＮｏＲｅｎｄｅｒ待ち時間からＮｏＦｅｔｃｈ待ち時間を差し引くこと、すなわち、Ｌ２＝ＮｏＲｅｎｄｅｒ待ち時間−ＮｏＦｅｔｃｈ待ち時間（Ｌ１）によって算出できる。
【００２７】
ステップ２０６において、第２コンテンツサーバ１４２のパフォーマンスが決定される。第２コンテンツサーバ１４２のパフォーマンスを決定するために、第１コンテンツサーバ１３４へのコンテンツのリクエストは、ウェブページコンテンツ所在地のＵＲＬを、「http://www.webpage.com」のように、引数なしでリクエストすることによって生成される。ＵＲＬのリクエスト及びレンダリングに関連したページ読み込み総時間は、総待ち時間（Ｌ）に相当する。故に、第２コンテンツサーバ１４２に関連した待ち時間は、総待ち時間からＮｏＲｅｎｄｅｒ待ち時間を差し引くこと、すなわち、Ｌ３＝総待ち時間（Ｌ）−ＮｏＲｅｎｄｅｒ（Ｌ２）によって算出できる。
【００２８】
発行者サーバ、第１コンテンツサーバ、及び第２コンテンツサーバのパフォーマンスが決定された後、発行者サーバのパフォーマンス、第１コンテンツサーバのパフォーマンス、及び第２コンテンツサーバのパフォーマンスに基づき、待ち時間情報が決定される（ステップ２０８）。待ち時間情報は、発行者サーバ、第１コンテンツサーバ、及び第２コンテンツサーバのそれぞれに関連したコンテンツ読み込み時間の長さを表す。例えば、ユーザインタフェースが生成され、かつ異なる構成要素に起因した待ち時間に関する情報が、そのユーザインタフェースに書き出される。いくつかの実施形態では、ユーザインタフェースは、ＪａｖａＳｃｒｉｐｔコードによって生成され、単独のブラウザウィンドウを提供する。
【００２９】
図３は、待ち時間寄与率を決定するための別の例示的なプロセス３００である。待ち時間寄与率を決定するための例示的なプロセス３００は、スクリプトへの参照を含んだドキュメントをリクエストするために、ＵＲＬ（Uniform Resource Locator）を提示することから始まる（ステップ３０２）。上記リクエストには、ＵＲＬに付加された第１引数が含まれる。例えば、第１引数「google_nofetch」が、「http://www.webpage.com?google_nofetch」のように、ウェブページコンテンツの所在地のＵＲＬに付加される。この場合、ＮｏＦｅｔｃｈモードが実行される。
【００３０】
次に、プロセス３００は、スクリプトへの参照を含んだドキュメントをリクエストするためのＵＲＬを提示する（ステップ３０４）。上記リクエストには、ＵＲＬに付加された第２引数が含まれる。例えば、引数「google_norender」が、「http://www.webpage.com?google_norender」のように、ウェブページコンテンツの所在地のＵＲＬに付加される。この場合、ＮｏＲｅｎｄｅｒモードが実行される。
【００３１】
ステップ３０２及びステップ３０４でのリクエストに応答して、スクリプトを含んだドキュメントが取り出される（ステップ３０６）。ドキュメントを受信した後、スクリプトは、第１引数及び第２引数に従って、発行者サーバの待ち時間及び第１コンテンツサーバの待ち時間を決定するために実行される。例えば、スクリプトは、第１引数に従って、ＮｏＦｅｔｃｈモードを実行するとともに、第２引数に従って、ＮｏＲｅｎｄｅｒモードを実行する。発行者サーバの待ち時間及び第１コンテンツサーバの待ち時間に基づいて、第２コンテンツサーバの待ち時間が決定される（ステップ３１０）。
【００３２】
図４は、ＮｏＦｅｔｃｈモードを実行するスクリプトの第１動作の出力を表示する例示的なインタフェース４００を示す。図４の列４０２は、ＮｏＦｅｔｃｈモードで実行される命令に関連した待ち時間を示す。例えば、待ち時間は、スクリプト実行に応じて増大する実行時間として表される。図２の列４０４は、ＮｏＦｅｔｃｈモードを実行するスクリプトによって処理される命令のメッセージタイプを提供する。図４の列４０６は、ＮｏＦｅｔｃｈモードを実行するスクリプトによって処理される命令を示す要約メッセージを提供する。ＮｏＦｅｔｃｈモードでは、ウェブページコンテンツ１０６内のスクリプトファイルの実行は、１つ以上のコンテンツサーバからの広告の取り出しを止めさせる。図４に符号４０８で示すように、スクリプトが広告（ads）のフェッチを抑制することによって、ＮｏＦｅｔｃｈモードでの待ち時間情報は、発行者サーバに依存したものとなる。
【００３３】
スクリプトの第１動作を実行した後、スクリプトの第２動作が、第１コンテンツサーバの待ち時間を決定するために実行される（ステップ３１０）。スクリプトの第２動作は、ＮｏＲｅｎｄｅｒモードを実行する。図５は、ＮｏＲｅｎｄｅｒモードの出力を表示する例示的なインタフェース５００を示す。図５の列５０２は、ＮｏＲｅｎｄｅｒモードを実行するスクリプトに関連した待ち時間を示す。例えば、待ち時間は、スクリプトの実行とともに増大する実行時間として表される。図５の列５０４は、ＮｏＲｅｎｄｅｒモードを実行するスクリプトによって処理される命令のメッセージタイプを提供する。図５の列５０６は、ＮｏＲｅｎｄｅｒモードを実行するスクリプトによって処理される命令を示す要約メッセージを提供する。ＮｏＲｅｎｄｅｒモードの実行は、図５に符号５０８で示すように、広告を取り出すが、それをレンダリングしない場合の第１コンテンツサーバ１３４のパフォーマンスを確定する。第１コンテンツサーバ１３４に関連した待ち時間は、ＮｏＲｅｎｄｅｒ待ち時間からＮｏＦｅｔｃｈ待ち時間を差し引くこと、すなわち、Ｌ２＝ＮｏＲｅｎｄｅｒ待ち時間−ＮｏＦｅｔｃｈ待ち時間（Ｌ１）によって算出できる。
【００３４】
ＮｏＦｅｔｃｈ及びＮｏＲｅｎｄｅｒモードでのドキュメント実行の後、発行者サーバの待ち時間及び第１コンテンツサーバの待ち時間に基づいて、第２コンテンツサーバの待ち時間が決定される。第２コンテンツサーバ１４２のパフォーマンスを決定するために、ウェブページコンテンツの所在地のＵＲＬを、「http://www.webpage.com」のように、引数なしで発行者サーバ１０２に提示することによって、第１コンテンツサーバ１３４へのコンテンツリクエストが生成される。ＵＲＬのリクエスト及びレンダリングに関連したページ読み込み総時間は、総待ち時間（Ｌ）に実質的に等しい。故に、第２コンテンツサーバ１４２に関連した待ち時間は、総待ち時間からＮｏＲｅｎｄｅｒ待ち時間を差し引くこと、すなわち、Ｌ３＝総待ち時間（Ｌ）−ＮｏＲｅｎｄｅｒ待ち時間（Ｌ２）によって算出できる。
【００３５】
図６は、待ち時間の発生源を決定するための例示的なプロセス６００である。発行者サーバ、第１コンテンツサーバ、及び第２コンテンツサーバに関連した待ち時間の決定に基づき、コンテンツページに関連した読み込み時間遅延源が決定される。判断ステップ６０２においてＬ１が低速であると判断された場合、待ち時間源は、発行者サーバ１０２に起因する可能性が最も高い（ステップ６０４）。しかしながら、判断ステップ６０２においてＬ１が高速であると判断された場合、プロセス６００は判断ステップ６０６に進む。判断ステップ６０６においてＬ２が低速であると判断された場合、待ち時間源は、第１コンテンツサーバ１３４に起因する可能性が最も高い（ステップ６０８）。判断ステップ６０６においてＬ２が高速であると判断された場合、プロセス６００は判断ステップ６１０に進む。判断ステップ６１０においてＬ３が高速であると判断された場合、コンテンツページ読み込み待ち時間は小さいとみなされる（Ｌ１、Ｌ２、及びＬ３はすべて高速であると判断される）（ステップ６１２）。しかしながら、判断ステップ６１０においてＬ３が低速であると判断された場合、待ち時間源は、第２コンテンツサーバ１４２に起因する可能性が最も高い（ステップ６１４）。
【００３６】
上記の例示的なプロセスに基づき、待ち時間源が第２コンテンツサーバ１４２に起因する可能性が最も高いと判断されたとする。この判断に基づき、第２コンテンツサーバ１４２など、１つ以上のコンテンツサーバに関連した待ち時間を決定するための例示的なプロセス７００が図７に示される。最初に、コンテンツがリクエストされる（ステップ７０２）。ここで、リクエストは、コンテンツを指し示すユニフォームリソースロケータ（ＵＲＬ）であり、ＵＲＬには、付加された引数が含まれる。リクエストに応答して受信したコンテンツは、第１インタフェースのコンテンツページに読み込まれる（ステップ７０４）。一実施形態では、コンテンツページに読み込まれたコンテンツは、コンテンツの第１部分である。ここで、コンテンツの第１部分は、発行者サーバ１０２からのコンテンツのみを含む。
【００３７】
次に、第２ユーザインタフェースが表示される（ステップ７０６）。第２ユーザインタフェースを表示するために、スクリプトを含んだドキュメントがリクエストされる。ここで、リクエストには、指示子が含まれる。例えば、リクエストは、ドキュメントを受信するよう指示するユニフォームリソースロケータ（ＵＲＬ）であり、指示子は、ＵＲＬに付加された引数である。次いで、ドキュメントは、例えば、リクエストに応答して受信される。次いで、指示子の受信に応答して第２ユーザインタフェースを表示するように、スクリプトが実行される。例えば、第２ユーザインタフェースは、コンテンツページを表示するブラウザウィンドウとは別個のブラウザウィンドウであってよい。
【００３８】
別の実施形態では、第１及び第２ユーザインタフェースは、同一のインタフェースに表示される。第１及び第２ユーザインタフェースは、共通のクライアントデバイス上の共通のブラウザによってレンダリングされる。例えば、第１及び第２ユーザインタフェースは、クライアントデバイス上で実行されるブラウザウィンドウのような１つのユーザインタフェース中にレンダリングされる。
【００３９】
続いて、コンテンツページに関連した１つ以上のコンテンツアイテム、例えば、広告が、ＵＲＬに付加された引数に従って、第２ユーザインタフェースに表示される（ステップ７０８）。さらに、第２ユーザインタフェース中のコンテンツアイテム毎に１つ以上の属性が表示される（ステップ７１０）。例えば、表示される属性は、各コンテンツアイテムに関連した読み込み時間及び総読み込み時間である。
【００４０】
一実施形態では、１つ以上のコンテンツアイテムの表示は、クライアント側の処理系を使用することによって達成される。例えば、コンテンツアイテムスロットに挿入するための１つ以上のコンテンツアイテムのコピーが、１つ以上のコンテンツサーバから受信され、保存される。次いで、読み込み時コールバックが、コンテンツページに対して登録される。読み込み時コールバックの間、第２ユーザインタフェースが表示され、かつコンテンツアイテムスロットのスキャンが行われる。コンテンツアイテムスロットのスキャンが行われた後、コンテンツアイテムに関連したすべてのコード、例えば、ＨＴＭＬコードが結合される。次いで、結合されたＨＴＭＬコードは、第２ユーザインタフェースに挿入され、かつすべてのコンテンツアイテムが生成される。
【００４１】
別の実施形態では、第２ユーザインタフェースへの１つ以上のコンテンツアイテムの表示は、サーバ側処理系を使用することによって達成される。例えば、１つ以上のコンテンツアイテムに関連した１つ以上のコンテンツアイテム識別子は、ＪａｖａＳｃｒｉｐｔを用いて取得される。次いで、第２ユーザインタフェースが開かれ、かつ１つ以上の広告識別子を使用することによって、１つ以上のコンテンツアイテムのためのリクエストが、１つ以上のコンテンツサーバに対して生成される。次いで、１つ以上のコンテンツサーバから受信した１つ以上のコンテンツアイテムが、例えば、第２ユーザインタフェースにレンダリングされる。ある実施形態では、各コンテンツアイテムに関連した読み込み時間が、第２ユーザインタフェースに表示される。ある実施形態では、総読み込み時間が、第２ユーザインタフェースに表示される。
【００４２】
いくつかの実施形態では、第２ユーザインタフェースに関連したソースコードが保存される。例えば、ユーザは、第２ユーザインタフェース中のページのソースコードを閲覧及び保存できる。ソースコードの保存は、１つ以上のコンテンツアイテムの待ち時間を、待ち時間の原因であるコンテンツサーバの運用者に説明するために有用である。特に、ソースコードは、どの（複数の）コンテンツアイテム、すなわち、（複数の）広告が読み込み時間の最も大きい遅れを生み出しているのかを特定するために使用される。ソースコードは、例えば、コンテンツサーバの運用者に、直接、電子メールできる。次いで、ソースコードは、ユーザインタフェース、例えば、ブラウザ、に読み込まれ、特定の（複数の）コンテンツアイテムの待ち時間を説明する。
【００４３】
第２コンテンツサーバ１４２などの１つ以上のコンテンツサーバに関連した待ち時間を決定するための別の例示的なプロセス８００が図８に示される。コンテンツページに関連した待ち時間源が決定された後、コンテンツページの第１部分が、第１ユーザインタフェースに読み込まれる（ステップ８０２）。ここで、第１部分は、発行者サーバから受信したコンテンツを含む。例えば、コンテンツの第１部分は、１つ以上のコンテンツサーバからの１つ以上のコンテンツアイテムを含まない。
【００４４】
次に、第２ユーザインタフェースが表示される（ステップ８０４）。続いて、コンテンツページの第２部分に関連したソースコード、すなわち、ＨＴＭＬコードが、第２ユーザインタフェースに表示される（ステップ８０６）。ここで、第２部分は、１つ以上のコンテンツサーバから受信した１つ以上のコンテンツアイテムを含む。１つ以上のコンテンツアイテムに関連したソースコード、すなわち、ＨＴＭＬコードを第２ユーザインタフェースに表示するために、スクリプトを含んだドキュメントがリクエストされる。ここで、リクエストは、指示子を含む。例えば、リクエストは、ドキュメントを受信するように指示するユニフォームリソースロケータ（ＵＲＬ）であり、指示子は、ＵＲＬに付加された引数である。次いで、ドキュメントは、例えば、リクエストに応答して受信される。次いで、指示子の受信に応答して、１つ以上のコンテンツアイテムに関連したソースコードを含んだ第２ユーザインタフェースを表示するように、スクリプトが実行される。
【００４５】
例えば、「http://www.webpage.com?google_capture_norender」のように、引数「google_capture_norender」がウェブページコンテンツ所在地のＵＲＬに付加される。それに応答して、１つ以上のコンテンツアイテムに関連したソースコードを含んだ第２ユーザインタフェースが表示される。次いで、ソースコードは、例えば、コピーされ（ステップ８０８）、エディタにペーストされ（ステップ８１０）、次いで、ローカルＨＴＭＬファイルなどのファイルに保存される（ステップ８１２）。その後、インタフェース、例えば、ブラウザ又はその他のユーザインタフェースは、ファイル、例えば、ローカルＨＴＭＬファイル、を開くために使用される（ステップ８１４）。ファイルには、１つ以上のコンテンツアイテムに関連したソースコードが含まれる。ファイルを開いたとき、ファイルは、コンテンツページに関連した１つ以上のコンテンツアイテムをユーザインタフェースにレンダリングする（ステップ８１６）。さらに、１つ以上のコンテンツアイテムに関連した１つ以上の属性が、ユーザインタフェースに表示される（ステップ８１８）。例えば、属性は、各コンテンツアイテムに関連した読み込み時間及び１つ以上のコンテンツアイテムに関連した総読み込み時間を含む。
【００４６】
図９は、第２コンテンツサーバ１４２などの１つ以上のコンテンツサーバに関連した待ち時間を決定するための別の例示的なプロセス９００である。プロセス９００は、コンテンツページの第１部分を第１ユーザインタフェースに読み込むことから開始される（ステップ９０２）。ここで、第１部分は、発行者サーバから受信したコンテンツを含む。例えば、第１ユーザインタフェースに読み込まれたコンテンツページの第１部分は、１つ以上のコンテンツサーバからのコンテンツを含まない。次に、第２ユーザインタフェースが表示される（ステップ９０４）。例えば、第２ユーザインタフェースは、ポップアップウィンドウのようなウィンドウであり、第１ユーザインタフェースに追加的に表示される。
【００４７】
次いで、コンテンツページの第２部分が、例えば、第２ユーザインタフェースに表示される（ステップ９０６）。ここで、第２部分は、１つ以上のコンテンツサーバから受信した１つ以上のコンテンツアイテムを含む。さらに、１つ以上のコンテンツアイテムに関連した１つ以上の属性が、第２ユーザインタフェースに表示される（ステップ９０８）。例えば、属性は、各コンテンツアイテムに関連した読み込み時間と、１つ以上のコンテンツアイテムに関連した総読み込み時間とを含む。
【００４８】
図１０は、上記のプロセスで説明した例示的な第２ユーザインタフェース１０００を示す。先に記載したように、１つ以上のコンテンツアイテムに関連した１つ以上の属性が、第２ユーザインタフェース１０００に表示される。一実施形態では、各コンテンツアイテムに関連した位置及びサイズ情報１００２が、第２ユーザインタフェース１０００に表示される。別の実施形態では、コンテンツアイテム１００４が、第２ユーザインタフェース１０００に表示される。別の実施形態では、各広告に関連した読み込み時間１００６が、第２ユーザインタフェース１０００に表示される。例えば、個々の読み込み時間１００６は、位置及びサイズ情報１００２と共に表示される広告１００４に関連する。別の実施形態では、総読み込み時間１００６が、第２ユーザインタフェース１０００に表示される。
【００４９】
本明細書に記載された装置、方法、フロー図、及び構成図は、コンピュータ処理システムによって実行可能な複数のプログラム命令から成るプログラムコードを含んだコンピュータ処理システムで実現されてよい。また、他の実施形態が用いられてもよい。さらにまた、特定の方法、及び／又は、複数のステップをサポートする対応する動作及び記載された構造的手段をサポートする対応する機能を説明した本明細書に記載されたフロー図及び構成図は、対応するソフトウェアストラクチャ及びアルゴリズム、並びにその均等物を実現するために使用されてもよい。
【００５０】
明細書中の記載は、発明の最良の形態を示すとともに、発明を説明するための、かつその発明を当業者が実施及び利用できるようにするための実施例を提供する。明細書中の記載は、そこに示された詳細な条件に発明を限定するものではない。故に、発明は上記に示された実施例を参照して詳細に説明されるが、当業者は、発明の範囲から逸脱することなく、そのような実施例に置換、修正、及び変更を行うことができる。
【符号の説明】
【００５１】
１０  コンテンツリクエストシステム
１００  クライアントシステム
１０２  発行者
１０４  ウェブページコンテンツリクエスト
１０６  ウェブページコンテンツ
１０８，１１０  命令群
１０８ａ，１１０ａ  格納命令
１０８ｂ，１１０ｂ  タイミング命令
１０８ｃ，１１０ｃ  リクエスト命令
１１２，１１４，１１６，１１８，１２０  コンテンツスロット
１２２，１２４，１２６，１２８，１３０  コンテンツリクエスト
１３２  データ格納部（バッファ）
１３４  第１コンテンツサーバ
１３６，１４０  リクエスト
１３７  レスポンス
１３８，１４４  特定されたコンテンツ
１４２  第２コンテンツサーバ
【図１】
2010536100.tif 000003
【図２】
2010536100.tif 000004
【図３】
2010536100.tif 000005
【図４】
2010536100.tif 000006
【図５】
2010536100.tif 000007
【図６】
2010536100.tif 000008
【図７】
2010536100.tif 000009
【図８】
2010536100.tif 000010
【図９】
2010536100.tif 000011
【図１０】
2010536100.tif 000012
【国際調査報告】
2010536100.tif 000013
2010536100.tif 000014
2010536100.tif 000015