JP5308516B2 - ウェブ・ブラウザ上の広告の掲示を選択的に確保するための方法、およびシステム - Google Patents

Description

本発明は一般にデータ処理に関し、さらに具体的にはウェブ・ブラウジングのためのシステム、および方法に関する。

多くの企業のインターネットのビジネス・モデルは、ほとんどがクライアント・ウェブ・ブラウザへの広告掲示に依存している。かかる広告の遮断もしくはスキップを可能にする処理技術の台頭が、この主流の収入源を大きく脅かしている。

広告は、多くのウェブ・サイトおよび企業にとって主要な収入源となっている。広告が（大手企業の「うまく狙いを合わせた」効果的または情報提供的な広告であっても）大量に拒まれるようなことになれば、もはや無料のコンテンツまたはサービスは存在しなくなるであろう。今のところ、極めて技術的に熟達したユーザがかかる広告遮断技法を知得しているだけだが、量販ウェブ・ブラウザにかかるツールがデフォルトで組込まれれば、自社のビジネス・モデルを広告に依存している企業に対して巨大な損失をもたらすことになろう。しかして、ウェブ・ブラウザへの広告の掲示を確保し、今日のデジタル・ネットワークにおける広告が消滅する危険性、およびこれらに関連し伸張を続ける広告遮断能力を回避するための方法を見出し得ることが最重要課題である。実際に、広告遮断技法（いわゆるアドブロッカまたは広告ブロッカ）の使用の広がりとともに、広告からの全面撤退の脅威が生じている。

広告には、ウェブ・ページに組込まれた、テキスト領域、静止画像、動画、さらにはビデオがある。広告のオーディエンス（一般性を損なうことなく「視聴者」または「ユーザ」という）の一員が、これらの広告の一つをクリックして選択すると、通常、組込まれたハイパーテキスト・リンクが、視聴者を広告主のウェブ・サイトに導く（「クリックスルー」プロセス）。

押し付けがましい販売手段に益々多くの消費者がうんざりしているように見える。これら消費者は非常に気が散る広告を過剰供給されているが、一部の企業は「煩わしくなく」「情報提供的な」広告を活用しようと試みている。実際のところ、簡素で読みやすく押し付けがましさがないテキスト広告は非常に少ない。それどころか、多くの広告は、ユーザが過剰に侵害的と感じるフラッシュまたはアニメのｇｉｆバナー（時には所望のコンテンツを覆うようなポップアップ、ポップアンダなど）、および、ページの他の場所にある本来のテキストを読むのを非常に困難にしてしまう点滅グラフィックスであり、大体の場合、配信される広告も適切でなく（いわゆるターゲット広告は多くの場合失敗する）、これらはノイズとして読者の気を散らす。ユーザをターゲットするのは、ほとんどの場合個人的性向を追跡することを意味し、プライバシー侵害の恐れがある。

これら全ての理由によって、益々多くのユーザがいわゆるアドブロッカ（または広告ブロッカ）を使っている。ユーザの観点からは、広告遮断の利点には、よりクリーンに見えるウェブ・ページ、より低いリソース使用（回線容量）、およびスピード・アップするといわれるページのローディング（多くのページが最初に重量のある広告をロードするよう設計されている）が含まれる。最新の技術には、ピュア・テキスト・ブラウザ、ポップアップ（またはポップアンダ）ブロッカ、広告サーバのＵＲＬのブラックリスト、テキスト・フィルタリング・ツール（キーワードに基づくもので広告ファイルのロードを阻止する）、スクリプト・ブロッカ、ＣＳＳルールの使用（特定のＨＴＭＬおよびＸＨＴＭＬエレメントを隠す）など、ウェブ・ブラウザ上の広告をスキップまたは除去することを可能にする多くの広告遮断技法が含まれる。

広告遮断技法だけが関与しているのではない。パーソナライズド・ウェブ・ページを構築するための抽出技法の使用、ＲＳＳの使用、およびマッシュアップの使用も、広告スキップをもたらしている。パーソナライズド・ウェブ・ページの使用によって、的確なコンテンツ領域を抽出し、それら抽出されたコンテンツを個人化されたページに収集することが可能になる。それ以降は、ユーザは元のページを再び訪問する必要はなく、しかして、広告があればそれをスキップすることができる。非常によく似たある技法は、全ページをロードするが、フレームまたは＜ＤＩＶ＞タグあるいはその両方にかなうものだけを表示し、望まないコンテンツを隠すやり方を用いる。また、この後者のやり方には、（広告主からの観点からは）コンテンツがユーザには表示されないにも関わらず、固有の訪問者の数は変わらないままという不利点もある。ＲＳＳ配信（ＲＳＳは「Ｒｅａｌｌｙ Ｓｉｍｐｌｅ Ｓｙｎｄｉｃａｔｉｏｎ（とても簡単な配給）」を表す）でも類似のメカニズムが作動される。実際、ＲＳＳ配信の増加はインターネットの性質を大きく変えてしまい、インターネットは今やデータのストックでなくフローである。このＲＳＳモデルによれば、コンテント・プロバイダが配信を管理する、すなわち、プロバイダが、ＲＳＳ配信を介して自社の加入者にどのコンテントを提供するか選択できることに留意するのが重要である。さらに、これら新興メカニズムのおかげで、今やユーザは、ウェブ・コンテンツの諸部分を制限なく自由に抽出することが可能である。すなわち、ウェブ・ユーザは、もはやボトルネックになっているページ（大量の広告を包含するホーム・ページまたはポータル）を訪問する必要はない。こういった状況では、コンテント・プロバイダは、自社の事業を収益化する選択肢を非常にわずかしか持たない生データの提供者になってしまう可能性がある。例えば、（ＲＳＳジェネレータと呼ばれることもある）ある技法は、任意のウェブ・ページからの配信の抽出を可能にする。さらに他の種の技法は、ＲＳＳ配信の収集だけでなく、これらを組み合わせることも可能にする（ＲＳＳリミキサ・ツールが、フィルタ、探索、混成などを可能にする）。シンジケート化された配信にターゲット広告を組込むためのいくつかの試み（広告を、広告主が事前選定したキーワードを包含するＲＳＳアイテムまたはブログ・ポスト入れて配信するなど）がなされたが、これも（キーワード・ベースの、または他の技法を使った）テキスト・フィルタリングによって破ることが可能である。最後に、いわゆるマッシュアップの使用もまたオンライン広告に脅威を与えている。ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅｓ（アプリケーション・プログラミング・インタフェース））のおかげで、アプリケーション自体も統合可能である。具体的にいえば、コンテンツのリミキシングの過程で広告を除去することが可能である。

反対サイド（すなわち、広告掲示の確保側）には、利用可能な処理技術が非常に少ないように見える。ある周知のアプローチは、ＵＲＬブラックリストを迂回するためのＵＲＬアドレス・スクランブリング技法から成る。この処理技術は、考えられる協調フィルタリング（ピアベースの反スパム技法など）との反応性のため、必ずしも効率的なものでない。ランダム化アドレスの使用にも限界（学習能力）がある。ある種のバグ（例えばゲッコー中の）に起因して、一部のウェブ・サイトは、クローム：／／ＳＣＲＩＰＴおよびＩＭＧタグ中のアドレスにアクセスし、ブラウザにインストールされている広告遮断アドオンを検出することができる。その後、ウェブ・サイトはクライアントへの配信を拒否できるが、これらのバグは次第に修正され、アドブロッカはこれらのバグの回避策を実装する。

これらの一般的技術アプローチと別に、単なる非技術的な方法もある。例えば、パーミッション・マーケティング手法が試されている（いかにも、広告がユーザをターゲットする代わりにユーザが広告をターゲットすることができよう）が、これらの手法も大量市場にはうまく適用されない。広告主またはそのパートナによって、より心よく受け取られる形で広告が配信されるようにユーザ・プロフィールに基づく他の方法も試されているが、これはプライバシの問題がある。広告の掲示を確保するための信頼ある処理技術が出現しなければ、広告の形式は、顧客の注目を保持し、苛立ちおよび「退去」双方の最小化を助力するための、このような文脈的、双方向的、パーミッション・ベースの、ターゲット化メッセージング的なものに進展し得る。また、少数のコンテントまたはサービス・プロバイダは、自社ユーザに対し、広告遮断技法の使用が、彼らにコンテンツおよびサービスを提供するため懸命に働く人々の収入を奪うものだと論じて、これら技法の使用が意味する損害に関して警告をしようとしている。時として、これらプロバイダは自社のウェブ・サイト訪問に対して特定の使用許諾契約を要求する。結論として、これらの（非技術的）方法のいずれも、広告遮断技法、またはＲＳＳ配信の使用、またはパーソナライズド・ウェブ・ページの使用、あるいはこれらの複数への対策として効果的に機能しておらず、結局は、収入源の確保に成功していない。

ウェブ・ブラウザ上の広告の掲示の確保を可能にする方法に対する、さらに一般的にはマークアップ・ファイル・ビューアに対する差し迫った必要性がある。

本発明の実施形態により、添付の独立請求項１に従って広告の掲示を確保する方法が提供される。

本発明の別の実施形態により、添付の独立請求項１１に従って広告の掲示を確保するシステムが提供される。

概要として、本発明の実施形態は、解釈されたまたは実行されたマークアップ・ファイル中の対象となる一つまたは複数の特定領域の表示を確実にするいくつかの技法の有益な組合せを用いる。これらの技法は、ＤＯＭツリーの書換え技法と、（ＯＣＲなどの）画像認識およびテキスト解析手法の技術的限界を利用した画像生成および変更の使用と、マークアップ・ファイルの一部の修正部分に対して失われてしまう可能性のあるユーザ双方向性を保持することを可能にするスクリプト言語コードの使用である。

数ある利点のうち、本発明の実施形態は、既存のほとんどの画像認識技術を無効化し、既存のほとんどの意味解釈またはテキスト解析技法を無効化する（これら技術は、おそらくは広告を遮断またはスキップするため用いられ得る）。言葉を換えれば、本発明の実施形態は、セマンティックス技術を無効にし（画像に対して無効になる）、画像認識技術の限界（より大きな画像に組入れられた広告は検出できない）を利用して、広告の掲示を確保することを可能にする。しかし、広告だけが対象でないことも強調しておく。本発明のある実施形態は、一つまたは複数の特定の（テキストまたはグラフィックスなどの）領域を（表示データの全体性を保持する必要性から）確保する必要があるあらゆる状況を取り扱う。これについては後記でさらに詳細を説明する。

本発明のある実施形態の別の利点は、ウェブ・ブラウザに対する悪意あるコード（ある場合）の一切の実行を回避するその能力にもある。これは、悪意あるソフトウエアに対する興味深い保護を確かに提供する。今日のインターネットは危険に満ちているが、その中に悪意あるソフトウエア・コードがある。ウェブ・ブラウザを使ってウェブ・ページを訪問するユーザは、悪意あるコードを不注意に実行して、自分のローカル・マシンを（即時のまたは近い将来の）危険にさらすことがあり得る。包括的な悪意あるコードには、ウイルス、トロイの木馬の最近のダウンロード、およびキーロガー、スパイウエアなどのインストールが含まれる。しかして、個人および経済的データがリスクに曝され、遠隔から不法な目的で使用されることはないにしても、ハードウエア・デバイスが物理的損傷を被ることもあり得る。前述の方法を実装する２階層のアーキテクチャを用いることによって、ブラウザ側で悪意あるコードが実行されるのを回避することが可能になる（ウェブ・ブラウザは、信頼のおけないコードを有するマークアップ・ページを受信することなく、修正されたマークアップ・ファイルを受信する）。全く驚いたことには、マルウエアは広告とつながりがある。ビジネス関係の複雑な構造に起因して、悪意あるコードがオンライン広告を介して大量に注入されているといわれている（正当な広告配信ストリーム中への悪意あるコンテントの注入）。本発明のある実施形態は、広告の掲示を確保し、同時に悪意あるコードの実行を回避する。ウェブ・ブラウザは、いかなる悪意あるコードも実行されないことの保証を有し、一方、コンテント・プロバイダはその広告が確保されることの保証を有する。これは、多くの興味深いビジネス機会を開く両者に有利なオペレーションである。結論として、潜在的な悪意あるコードを含むマークアップ・ファイルの部分は、本開示の技法を用いて除去することができる（危険なマークアップ・ファイルを安全なマークアップ・ファイルに変換できる）。

また、本発明の実施形態は、元のマークアップ・ファイル中に符号化されたユーザ双方向性を持続することを可能にする。適合スクリプト言語コードを使うことによって、ユーザ双方向性は、一部の領域に対しては確かに可能に維持し、他の特定の領域に対しては禁止（不存在に）することができる。このバリエーションは、これが提供するユーザ双方向性に対する制御のゆえに非常に有益である。該双方向性は、未変更のままとすることも（ユーザは引き続き、例えば、コンテンツをコピー・アンド・ペーストができることになる）、部分的に変更することも、全面除去することもできる。これは大きな柔軟性を提供する。

別の利点（２階層アーキテクチャを使った場合）は、本発明の実施形態が標準的なブラウザを必要とするだけだということである。これは、クライアント側で、いかなる追加のプラグインも、コンポーネントも、ローカル・ソフトウエアも必要としない。ウェブ・ブラウザに加える何の追加ソフトウエアも必要としない。しかして、本開示は、ブラウザの変更なくして（無修正ブラウザの使用）機能する最初のアプローチである。これは、現在のブラウザで直接使用ができ、従って即時に採用することができる。

さらなる別の利点は、本開示が迅速で低コストのインターネット・アクセスを可能にすることである。これは、ウェブ・ブラウザに入来するマークアップ・ファイルの重さと複雑さとを軽減する（これは、コード・エレメントに包含されている可能性のあるバグまたはエラーを低減する）。今日では、多くのデバイス（携帯電話、タブレット型パソコン）が、限られたＣＰＵ機能を有している。修正されたマークアップ・ファイルは（悪意のないスクリプト言語に加え）その大部分が画像ファイルを包含しているので、上記のデバイスで実行されるブラウザまたはビューアは、ほとんどの場合画像表示の能力が必要性なだけである。しかして、本開示は、限定された計算およびメモリ・リソースを有する携帯デバイスが遠隔ブラウジングすることを可能にする。

最後に、本発明のある実施形態により、添付の請求項９に従ってコンピュータ・プログラムおよび請求項１０に従ってコンピュータ可読媒体が提供される。

好適な実施形態が添付の従属請求項に定義されている。

当業者は、図面および詳細な説明を検討することによって、本発明のさらなる利点を明確にすることができよう。一切の付加的な利点を本発明に組込むことが意図されている。

以下の図面を参照しながら、以降に本発明の実施形態を説明する。

マークアップ・ファイルの表示対象エレメントおよびスクリプト言語コードを示す。 マークアップ・ファイルおよびその関連ＤＯＭツリーを示す。 ＤＯＭツリーおよびその関連ノードの表現を示す。 ＤＯＭツリーに加えられた第一修正の例を示す。 ＤＯＭツリーに加えられた第二修正の例を示す。 種々のサブ画像生成モードを示す。 随意的な２階層のアーキテクチャを示す。 プロキシ内でのオペレーションを示す。 アーキテクチャの選択肢を示す。

説明を容易にするために、一つの図においてあるエレメントを識別するどの番号も、他のどの図面でも同じエレメントを表すものとする。

以下の記載で、広告遮断に関連する詳細な実施形態を提示するが、該実施形態はこの特定の分野に限定されるものでなく、例えば、コンピュータ・セキュリティ（悪意あるコードの除去、アンチ・クローリング・ツールなど）、インターネットへの接近性、コンテントの個人化および編集、データ変換、サービス配信してのソフトウエア、デジタル著作権管理、信頼できるコンピューティング、などの分野にも同様に展開されることを理解すべきである。

定義として、「ＤＯＭ」という表現は、ドキュメントのある（または所定の）論理的構造をいう方法として理解するものとする。しかして、上記の表現は、「論理的構造」または「階層構造」または「構造」などの表現で置き換えることができる。例えば、「ＤＯＭツリー」は、「論理的構造のツリー」と読取ることができる。簡潔さおよび明瞭さのため、「ＤＯＭ」および「ＤＯＭツリー」などの表現が用いられる。

図１は、マークアップ・ファイルの表示対象エレメントおよびスクリプト言語コードを示す。

ここで図１を参照すると、本開示により修正され使用される対象のオブジェクトが示されている。

該図には、一組の表示対象エレメント（１１０）およびスクリプト言語コード（１２０）を含むマークアップ・ファイル（１００）が示されている。

マークアップ・ファイル（１００）は、通常バイナリ・ファイルであるが、フォーマット済みの形とすることもできる。通常、これは、ネットワークを介し送信され、またはローカルにメモリから読み出され、あるいはその両方で得られ、これを、全体的にまたは部分的にローカル生成することができる。ある好適な実施形態において、マークアップ・ファイル（１００）は、ＨＴＭＬまたはＰＨＰまたはＸＭＬファイルである。ウェブ・ページは、実際に、（表示対象）コンテントおよび（メタ情報、ハイパーリンク・アドレス、Ｊａｖａ（Ｒ）スクリプトなどの）命令または埋め込み情報を含む。

特定の実施形態によれば、表示対象エレメント（１１０）の設定は、相対的かまたは絶対的と見なすことができる。ビューアの解釈によってもたらされる場合、その設定は相対的といわれる。例えば、あるＨＴＭＬマークアップ・ファイルの表示対象エレメントの一組は、該マークアップ・ファイルをウェブ・ブラウザ（またはウェブ・ブラウザ・インスタンス）にロードし解釈して設定されることになる。市販されているウェブ・ブラウザによって行われる種々の解釈の間には相近はあるが、異なるウェブ・ブラウザが異なる解釈（従って、表示対象エレメントの異なるセット）をもたらし得ることが観察される。この意味で、該解釈は相対的であると見なされる。別のアプローチは、ウェブ・ブラウザのいろいろな挙動を、共通のレンダリング・モデルに統合する（絶対的解釈）。簡単にいえば、これらの表示対象エレメントは、ユーザの目に届くかまたはこの最終的な表示に有用な全エレメントである。しかして、表示対象エレメント（１１０）は、画像、ビデオ領域、およびテキスト領域などのエレメントであり得る。「表示対象エレメント」という表現には、最後にユーザが見ることになるエレメントを網羅することが意図されている。従って、この表現は、本記載の方法によって遂行されるオペレーションの後で生じる可能性のある追加的な操作（例えば、フィルタリングまたはマスキングなど）を含んでいる場合をも網羅している。

ある実施形態によれば、スクリプト言語コード（１２０）に関し、「スクリプト言語コード」という表現は、マークアップ・ファイル（１００）中に含まれる、全ての命令またはソフトウエア・コードのラインを指すことが観察される。詳しく言えは、これは、上記マークアップ・ファイル解釈によるまたはこれに対する、マシンによって理解可能な命令を形成する文字の全一組みを含む。言い換えれば、該言語コードは、マークアップ・ファイルの最終ユーザまたは視聴者によって直接視聴されることを意図されていない（例えばスクリプトまたはメタ・データなどの）全データを含むが、さらには、表示対象エレメントの表示に間接的に有用な全データ（例えば＜ＤＩＶ＞ＨＴＭＬタグなど）も含む。多くの場合、スクリプト言語コード（１２０）がマークアップ・ファイルに包含される（または該ファイルに関連付けられ追加的に読み取られ得る）。コード・エレメントは、通常マークアップ・ファイルに組入れられるが必然ではない。実際、最新のプログラミング技法（例えばＡｊａｘなど）はコード・プログラムの動的な読み取りを用いることができる。従って、ある状況では、もともとマークアップ・ファイルに組入れられているコード・エレメントの組に動的に関連させて、コード・エレメントの一部を読み取ることが必要になり得る。例えば、ブラウザにおけるユーザのアクションが、マークアップ・ファイルの（例えば、ＸＭＬファイルに対し外部ファイルの全部または一部を包含する能力を定義する「Ｘｉｎｃｌｕｄｅ」を介した、サーバからの新規命令読み出しによる、またはローカル・リソースへのアクセスによる）さらなる変更を含蓄し得る。このため、最初にマークアップ・ファイルを解釈することが必要になる。マークアップ・ファイルを構文解析することによっても、ＤＯＭツリーを得ることができ、該ツリーは、本発明の実施形態によって操作され変更されることになる。この最後の点を次のセクションで説明する。

次いで、図２を参照すると、解釈されたマークアップ・ファイル（２００）、表示対象エレメント（２０１）、ＤＯＭツリー（２１０）、および、ＤＯＭツリーの特定のノード（２１１）が示されている。

いわゆるＤＯＭ（Ｄｏｃｕｍｅｎｔ Ｏｂｊｅｃｔ Ｍｏｄｅｌ（ドキュメント・オブジェクト・モデル））はエレメント（ＸＭＬまたはＨＴＭＬなど）をオブジェクトとして扱うやり方である。これは、ＨＴＭＬまたはＸＭＬ、および関連するフォーマットを表現するための、プラットフォーム非依存で言語非依存の標準オブジェクト・モデルである。具体的には、ドキュメント・オブジェクト・モデルは、ＪａｖａＳｃｒｉｐｔがＨＴＭＬページを包括的に見るやり方である。ＤＯＭは、ドキュメントの論理的構造、およびドキュメントにアクセスし操作するやり方を定義する。しかして、いわゆるＤＯＭツリーによってドキュメントの論理的構造が定義される。ＤＯＭツリーの部分はノードとして知られる。言い換えれば、ＤＯＭは、ドキュメントを、ノードとして定義されるエレメント、属性およびテキストを有するツリー構造（ノードのツリー）として表現する。ＤＯＭツリーは、各ノードがマークアップ・ファイルの言語スクリプト記述ファイルのサブセットに対応する、ノードの集合と見なすことができる（ノードは、スクリプト／プログラム、スクリプト／プログラムの小部分、または、画像のような表示対象エレメントを含む別の任意のオブジェクトを含み、あるいはこれらに対応付けることができる）。ノードのツリーは、ＸＭＬドキュメントを一組のノード群とそれらの間の連結として表現する。ＤＯＭによれば、ＸＭＬドキュメント中のあらゆるものはノードである。ドキュメント全体が、一つのドキュメント・ノードである。あらゆるＸＭＬエレメントはエレメント・ノードである。ＸＭＬエレメント中のテキストはテキスト・ノードであり、あらゆる属性は属性ノードであり、コメントはコメント・ノードである。

マークアップ・ファイルのＤＯＭツリーを得るために、マークアップ・ファイルの構文解析ツールが必要である。実際は、構文解析ツールはドキュメントをコンピュータ・メモリ中にロードする。ドキュメントがロードされたならば、ＤＯＭを使って該ドキュメントのデータを操作することができ、ＤＯＭはＸＭＬドキュメントをツリーとして取り扱う。マイクロソフト（Ｒ）のＸＭＬ構文解析ツール（ＣＯＭコンポーネント）とＭｏｚｉｌｌａ（Ｒ）ブラウザで使われるＸＭＬ構文解析ツールとの間にはいくつかの違いがあるが、本記載の方法およびシステムは、あらゆるブラウザおよび構文解析ツールに適用される。

マークアップ・ファイル（２００）は表示対象エレメント（２０１）を含む。ＤＯＭツリー（２１０）はマークアップ・ファイル（２００）のＤＯＭツリーである。ＤＯＭツリー（２１０）は一組のノードを含む。ＤＯＭツリー（２１０）の特定のノード（２１１）は、マークアップ・ファイル（２００）の表示対象エレメント（２０１）に対応する。

図２では、マークアップ・ファイル（２００）はウェブ・ページとして図示されている。表示対象エレメント（２０１）は広告画像として図示されている。図２に示されるように、ＤＯＭツリー（２１０）は複数の（親および子）ノードを含む。該特定のノード（２１１）は＜ＩＭＧ＞タグを含む。これが言及している画像は該広告画像である。

図２は、例を提示しているだけであるのを強調しておく。ＤＯＭツリーおよび関連するマークアップ・ファイルは、はるかに複雑であり得る。ノードに対応する表示対象エレメントは、静止画像、動画、フラッシュまたはＳｈｏｃｋｗａｖｅ（Ｒ）オブジェクト、ビデオ・オブジェクト、テキスト領域などのエレメントとすることができる。

次に、図３の（ａ）および（ｂ）を参照する。図３（ａ）は、複数の表示対象エレメントを含むマークアップ・ファイルの一例を表しており、これらエレメントはＤＯＭツリーのノードに対応している。図３（ｂ）は、（前図２で展開された例に続く）前述のマークアップ・ファイルに対応するＤＯＭツリーの表現である。

ＤＯＭツリーでは、最上点ノードはルートと呼ばれる。ルートを除くあらゆるノードはきっかり一つの親ノードを有する。ノードは任意の数の子供を持つことができる。葉は子を持たないノードである。姉妹は同じ親を有するノードである。各ノードは、名前、値および種類（エレメント、属性、テキスト、コメント、ドキュメント）を有する。ある所与のノードから、他の関連ノード（ｃｈｉｌｄＮｏｄｅｓ（子ノード）、ｐａｒｅｎｔＮｏｄｅ（親ノード）、ｆｉｒｓｔＣｈｉｌｄ（最初の子）、ｌａｓｔＣｈｉｌｄ（最後の子）、ｎｅｘｔＳｉｂｌｉｎｇ（次の妹）、ｐｒｅｖｉｏｕｓＳｉｂｌｉｎｇ（前の姉））を得ることが可能である。

図３の（ａ）および（ｂ）の双方に展開された例では、ノード（３０００）がルート・ノードである。ノード（３１００、３２００、３３００、３４００）はルート・ノード（３０００）の子ノードである。ノード（３３１０、３３２０）はノード（３３００）の子ノードである。ノード（３３２１、３３２２）はノード（３３２０）の子ノードである。ノード（３１００、３２００、３３００、３４００）は姉妹ノードである。ノード（３３１０、３３２０）は姉妹ノードであり、ノード（３３２１、３３２２）も姉妹ノードである。

図２に示されるように、該特定のノード（３３２１）は広告画像を含む。提案の図は、一例を提示しているだけであることを強調しておく。表示が確保されることになる複数の領域があり得る。これらの領域は、解釈されたマークアップ・ファイルの何処にでも所在し得る。

次に図４の（ａ）および（ｂ）を参照すると、本開示の方法およびシステムのアプリケーションによって加えられた修正を有する、前図３のエレメントが示されている。

構文解析ツール（図１の説明を参照）は、ノード・ツリーを行き来し、ノードおよびそれらの属性値にアクセスし、ノードを挿入および削除し、ノード・ツリーをＸＭＬに再変換するための必要な全機能をサポートする。ノードを取得、設定、移動、置換、生成、追加、および複製することが可能である。ＤＯＭでは任意の修正が可能である。プログラマは、ドキュメントを構築し、それらの構造をナビゲートし、エレメントおよびコンテントを追加し、修正し、削除することができる。本発明の実施形態は、こういったメカニズムを用いて、解釈または実行されたマークアップ・ファイル中の対象となる特定の領域の表示を確保する。

本発明により、一つ以上の表示対象エレメントを含む解釈されたマークアップ・ファイルのＤＯＭツリーを変更する方法が開示され、該方法は、該解釈されたマークアップ・ファイル特定の表示領域を定義するステップと、該解釈されたマークアップ・ファイルのＤＯＭツリーを得るステップであって、該ＤＯＭツリーは少なくとも一つの親ノードおよび複数の子ノードを包含し、各ノードは該表示対象エレメントの少なくとも一つと関連付けられている、該ＤＯＭツリーを得るステップと、ＤＯＭツリーの中で、自分の表示対象エレメントが上記特定の表示領域の少なくとも一部を含む子ノードの一組を識別するステップと、ＤＯＭツリーの中で、該子ノードの一組を含む第一親ノードを識別するステップと、該識別された第一親ノードに関連する全ての表示対象エレメントをマスタ画像に変換するステップと、該マスタ画像を含む第二親ノードを生成するステップと、該子ノードの識別された一組を削除し、識別された第一親ノードを第二親ノードに置き換えることによってＤＯＭツリーを修正ＤＯＭツリーに修正するステップと、を含む。

ＤＯＭツリーまたはノードの操作は、取得、読み出し、挿入、置換、削除、添付、除去、正規化、生成、複製、読取り、有効化、無効化、クリック、選定、クリア、投入、伝播、交換などの処理または命令を網羅するよう意図されている。ノードの操作では、無効なツリー構造を形成してしまうことがあり、際どい作業となり得るが（随意的な妥当性確認ツールまたはステップ）、直接ドキュメント・ツリーに作業することによってスピードと効率とが得られる。

図３に展開された例では、解釈されたマークアップ・ファイルの特定の表示領域が定義されていて、ノード（３３２１）が広告画像を包含している（＜ＩＭＧ＞ノード）。該ＤＯＭツリーの中で、自分の表示対象エレメントが該特定の表示領域を包含している子ノードの一組が識別され、ここでは子ノード（３３２０、３３００）の組が広告画像を包含している。該子ノードの組の中の少なくとも一つのノードを含む第一親ノードがＤＯＭツリー中に識別され、ノード３３２０がそれである（ノード３３２０がノード３３２１および３３２２の親ノードであり、一方ノード３３２０はノード３３００の子ノードであることに留意）。識別された第一親ノード（３３２０）に関連する表示対象エレメントは（マスタ）画像に変換される。該（マスタ）画像を含む第二親ノード（４０００）が生成される。次いでこれに従ってＤＯＭツリーが変更され、子ノード（３３２１、３３２２、および３３２０）が削除され、生成された第二親ノード（４０００）で置き換えられる。

ノード中のデータを読み出し、置き換え、または添付するため（あるいはノード全体を変更するため）、「ｒｅｐｌａｃｅＣｈｉｌｄ（）」（または「ｎｏｄｅＶａｌｕｅ」プロパティまたは「ｒｅｐｌａｃｅＤａｔａ（）」または「ｓｅｔＡｔｔｒｉｂｕｔｅ（）」など、あるいはこれらの複数）などの方法を使うことができる。かかる方法は、大きな柔軟性を可能にする多くのパラメータを備えており、第一＜Ｘ＞エレメントを第二＜Ｙ＞エレメントで置換することを可能にする。

生成された画像は、ユーザに表示する内容を具備している。上記は、いくつかの技法を用いることによって、例えば、ビデオ・バッファにアクセスすることによって（ほとんどの場合、オペレーティング・システム自体がかかる機能を備えている）、あるいは、ブラウザ／構文解析ツールが備える機能によって、または場合によってはＪａｖａ ＡＰＩ（例えば、クラスＪＥｄｉｔｏｒＰａｎｅおよびＳｗｉｎｇ ＨＴＭＬパッケージ拡張版）が備える機能によって達成することができる。

ＤＯＭ画像オブジェクトとは埋め込み画像を表す。ＨＴＭＬドキュメント中の＜ＩＭＧ＞タグの各インスタンスに対し、画像オブジェクトが生成される。画像オブジェクトのプロパティには、ａｌｉｇｎ（周囲のテキストに従い、どのように画像を配列するかを設定するまたは返す）、ａｌｔ（ブラウザが画像を表示できない場合に表示する代替テキストを設定するまたは返す）、ｂｏｒｄｅｒ（画像の周りの境界を設定するまたは返す）、ｃｏｍｐｌｅｔｅ（ブラウザが画像のローディングを完了したかどうかを返す）、ｈｅｉｇｈｔ（画像の高さを設定するまたは返す）、ｈｓｐａｃｅ（画像の左および右側に空白スペースを設定するまたは返す）、ｉｄ（画像のｉｄを設定するまたは返す）、ｉｓＭａｐ（画像がサーバ側の画像マップかどうかを返す）、ｌｏｎｇ Ｄｅｓｃ（画像の描写を包含するドキュメントへのＵＲＬを設定するまたは返す）、ｌｏｗｓｒｃ（画像の低解像度バージョンへのＵＲＬを設定するまたは返す）、ｎａｍｅ（画像の名前を設定するまたは返す）、ｓｒｃ（画像のＵＲＬを設定するまたは返す）、ｕｓｅｍａｐ（クライアント側画像マップのｕｓｅｍａｐ属性の値を設定するまたは返す）、ｖｓｐａｃｅ（画像の最上部および底部に空白スペースを設定するまたは返す）、ｗｉｄｔｈ（画像の幅を設定するまたは返す）がある。

図４（ｂ）に示されているように、修正ＤＯＭツリーは、今や、ノード（３３００）の子ノード（３３１０）およびノード（３３００）の新しい子ノード（４０００）に加え、姉妹ノード（３１００、３２００、３３００、３４００）を包含する。さらなる画像処理ステップを後記で説明する

次に図５の（ａ）および（ｂ）を参照すると、本開示の方法のアプリケーションによって加えられたさらなる修正が示されている。今回は、新規ノード（５０００）が生成される。図５（ａ）は、ノード（５０００）が、ノード（３３００）のコンテンツ、すなわち、前図４（ａ）および（ｂ）のノード（４０００）および（３３１０）のコンテンツを具備する（マスタ）画像を包含することを示している。図５（ｂ）は、対応するＤＯＭツリーの書換えを示す。

この提案事例において、図５（ａ）のノード（３３００）に対応する（マスタ）画像の面は、図４（ａ）のノード（３３２０）に対応する先の画像の面に比べ相当に大きい。かかる拡張の影響について以下に説明する。第一は、ノード（３３２１）に対応する広告画像の包括的データが、図５（ｂ）のはるかに大きな面に描画されており、画像マッチング技法が失敗する可能性が高いことである（次のセクションの説明を参照）。第二は、ノード（３３００）中の、あり得る悪意あるコードが除去され、無害な静止画像に置き換えられることである。第三は、前述のノード中に符号化されていたユーザ双方向性が除去されることである（図８に関するセクションで、どのように、なぜ該双方向性を持続するかを説明する）。

ＤＯＭツリーの一般的階層構造は、マークアップ・ファイルの「画像フリーズ」に関する制約を含蓄し、該「フリーズ処理」は、垂直にまたは水平にあるいは両方向にだけ伝播できることが観察される。（Ｒｕｓｓｉａｎ ｄｏｌｌｓ（ロシア人形）フォームの）該構造は、非常に複雑となり得、多数のノードを必要とし得る。提案事例において、ノード（３３００）および（３４００）をより大きな画像に、または３つのノード（３１００）、（３２００）、および（３３００）を単一の画像に、さらにはルート・ノード（３０００）全体を単一の画像に再び集約することも可能であろう。

次に、図６を参照すると、各種の光学的画像生成モードが描かれている。図６の（ａ）、（ｂ）および（ｃ）は、ノード３３００および画像（６００、６１０、６２０、６３０、６４００、６４０１、６４０２、…６２６５）を示す。

図６（ａ）は、ある実施形態による、単一の画像（６００）が生成される（点線で表す）事例を示す。単一の（マスタ）画像（６００）は、子ノードを含めたノード（３３００）の表示対象エレメントの一体性を表し、これを、前述のノードに関連する「背景」画像と見なすこともできる。

図６（ｂ）は、他の実施形態による、表示対象エレメントが複数のサブ画像（６１０、６１１、６１２）に変換される事例を示す。すなわち、画像（６００）は、複数のサブ画像（元画像から得られた「画像マッピング」）にさらに分割することができる。表示対象エレメントの元の配列に対応しない（またはその複写でない）サブ画像の配置を得るのは有用であることを強調しておく。言い換えれば、画像生成の本モードは、元となるＤＯＭツリー構造を複写しないことから（マークアップ・ファイルの表示対象エレメントの見かけ上の表示構造と一致しない画像マッピングを有することによって）利点を得ることができる。これは、広告遮断（またはフィルタリング）技法に対する、提案する方法およびシステムのロバスト性を強化する。図６（ｂ）から見取れるように、画像（６１０、６２０、６３０）は、元となるＤＯＭツリーの構造とは対応していない。

図６（ｃ）には さらなる実施形態が示されており、該実施形態では、表示対象エレメントは、非常に数多くのサブ画像（６４０１、６４０２、…）に、究極的には、ランダムで（絶え間なく変わる複雑なマッピング）を使った、互いに隣接または重畳する画像群に変換される。サブ画像間のオーバーラップは、実際上あり得てむしろ望ましいものである。

特定の実施形態によれば、画像（６００）または生成されたサブ画像（６１０、６２０、６３０、６４０１、６４０２…）のいずれも、例えば、畳み込み演算、モルフォロジー演算、幾何演算、ヒストグラム演算、アルファ・チャネル演算などの演算によって、さらに修正または変更することができる。画像認識ツール（パターン・マッチング、エッジ点など）はもとより、テキスト解析ツール（セマンティクス、ＯＣＲなど）を無効化することが本発明の実施形態の利点である。例えば、生成された各画像またはサブ画像には、トリミング、ぼかし、稀有なフォーマットへの符号化、白黒画像への変換、歪曲化などを行うことができる。また、画像またはサブ画像にノイズを加えることも可能である。マークアップ・ファイルの表示対象エレメントから得られた画像またはサブ画像に対し、上記のような操作（サイズ変更、分離、分割、区分け、集約、グループ化、歪曲化、ノイズ付加、離散化、再サンプリング、スクランブリング、グレースケール化など）を幾通りものやり方で組合せ、これらの操作によって、あり得る広告遮断技法に対する提案メカニズムの構造安定性の強化を図ることができることを強調しておく。具体的には、特定の実施形態によれば、前述の操作は、表示対象エレメント全体にあるいはこれら表示対象エレメントのあるサブセットだけに選択的に適用することができる。ただし、最終ユーザの読み易さと、得られた画像またはサブ画像あるいはその両方を解析および遮蔽する困難性の高さとの間で妥協点を見出す必要がある。読み易さの評価システムが、これらの操作を行う上での助力となり得る。

図６（ａ）において、ノード（３３００）の表示対象エレメントは、点線内に示された画像（６００）の中にレンダリングされる。本発明の特定の随意的実施形態によれば、図６（ｂ）および図６（ｃ）はさまざまなサブ画像生成モードを図示している。実際に、マークアップ・ファイルの表示対象エレメントは、一つ（図６（ａ））の画像、または複数の画像、すなわち幾多のやり方によるサブ画像（図６（ｂ）および図６（ｃ））、に変換することができる。ある好適な実施形態では、単一画像（図６（ａ）の６００）の生成が広告の掲示の確保に十分であり、実現するのが迅速で容易でもあることを強く強調しておく。他の実施形態では、複数の画像（サブ画像）が生成される。これは必須でなく、単に、本方法およびシステムの構造安定性を強化するものである。かかる随意的な分割は、テキストまたは画像認識システムを無効化するのに有用であることが実際に明らかにできよう。また、この目的のため、例えば、歪曲化、グレイスケール化、再符号化、サイズ変更、ノイズ付加、離散化、再サンプリング、またはスクランブリングなどの操作によって、一つまたは複数のサブ画像を変化させることもできる。画像変更は、ランダムに、あるいは（ハードウエアまたはソフトウエア実装の）ルール判断または判断論理によって駆動することができる。かかる変更を遂行するための判断論理は、クライアント・ブラウザのプロフィールのデータベースを設定すること、市販のアドブロッカの一式をテストしてみること、処理可能容量および配信制限事項の統計を取得することなどによって向上されよう。また、（リアルタイムまたは非リアルタイムの）評価メカニズム（広告配信の成功、統計など）を実装することができる。ウェブ・ページの再フォーマットは、一定でなく変化させて行うことになり、各ページは配信する前に再設定することができよう。

かかる画像の生成の特定の利点を以下に説明する。かかる画像生成処理の抜きん出た利点は、マークアップ・ファイルに組入れた広告の掲示の確保を可能にすることである。実際に、上記処理によって、テキスト解析技法および画像認識技法を含め、いわゆるアドブロッカによって使われる全ての技法が無効化される。テキストを包含する表示対象エレメントが画像中にレンダリングされているので、その後では、どんな意味解析またはテキスト・フィルタリング・ツールでもいかなる解析もできないことになる。これらのツールに理解可能なデータは全部消去されている。それでも、ある者はＯＣＲ解析（画像を解析して組入れられたテキストを抽出する）の実行を試みるかも知れないが、これらのツールは、画像の質の影響を極めて受け易く、且つ多大のコンピューティング・リソースを費消する。適応的な画像修正は、（ユーザの読取り容易性とＯＣＲまたは他の解析ツールに対する複雑性の付加との間での妥協点を探りつつ、ノイズを付加し、または画像をわずかに歪曲化することによって）この可能性を容易に打破できる。画像認識技術については、これらは非常に早期の段階にある。ある者は、テキスト領域から画像領域を分離し、次いで画像マッチング技法の適用（すなわち、分離された画像を既知の広告画像データベースと比較し、該分離画像が広告画像かどうかを判断する）を試みるかもしれない。別のより大きな画像に組入れられた広告画像を検出することは、不可能ではないにせよ困難であると思われる。全体の面に比べて広告画像の面が小さいほど、画像認識（またはマッチング）機能が低下する。１１０％の画像に組入れられた広告は、４００％の画像に組入れられた広告よりもより容易に検出および認識できよう（認識は、平均的に閾値２５％を境として劇的に低下する）。いわゆるパターン・マッチング技法（エッジ点検出および他の技法を使って、画像内の対象オブジェクトを自動的に分離することを狙う技法）のような先進的な画像認識技術も遂行を失敗する。テキスト解析技法の使用と同様、これらの画像認識技術は、あまりにもＣＰＵおよびメモリ集約的であり、しかしてリアルタイムまたは混みあった環境では、よい処理方法の提供に失敗する。同じ解析を、映画の中のプロダクト・プレイスメントに対して実施することが可能である（映画の中へのブランドの出現の検出および削除は、今後長年に亘り不可能なままに残されることになろう）。

図６の（ａ）および（ｂ）において、同種の領域を分離することの、従って効率的な画像認識技法を遂行することの困難性から利点が生じる。図６（ｃ）では、画像認識技法およびテキスト／光学式文字認識解析の実行のため画像群を適切に収集することの困難性から利点が得られる。

このように、表示対象エレメントを一つまたは複数の画像にレンダリングすることによって多くの利点が得られる。適切なインテリジェント・マッピングによって、広告遮断技法に対するシステムの構造安定性を最適化することができ、広告の掲示を非常にうまく確保することができる。確保対象の一つまたは複数の領域に対し、一つのまたは別の画像生成モードを選択することができよう。言い換えれば、広告が配置された領域を（例えば広告主から提供されたデータによって）知れば、画像認識技法が最低レベルのパフォーマンスを呈するように、画像マッピングを最適化することが可能である。かかる特質は、広告主が追加のサービスに対し（正確には、例えば自分達の個別の広告の掲示を確保するために）代金を支払うことになり得るので、興味深いビジネス・モデルを可能にする。また、これは、画像ファイルの表示の優先付けを可能にする。（表示優先度に従ったシーケンスで画像を送信する。例えば、広告を包含する生成画像ファイルを最初に表示させることができよう。かかる特質は、回線容量パラメータなどを考えれば有用であり得る。）

最後に、歪曲化、グレースケール化、再符号化、サイズ変更、ノイズ付加、離散化、再サンプリング、またはスクランブリングによって、一つまたは複数の画像を変更するさらなる技法が提供される。

次に図７を参照すると、本発明のある実施形態の方式が示されている。

該図は、ある実施形態による、ウェブ・サーバ（７００）、プロキシ・サーバ（７１０）、およびウェブ・ブラウザ（７３０）を示す。

この図は一例を示し、この例では、ウェブ・ブラウザ（７３０）のクエリーが、ステップ（７０１）でプロキシ・サーバ（７１０）に受信される（または途中捕捉される、図７参照）。プロキシ・サーバ（７１０）は、ステップ（７０２）において、該クエリーをネットワーク（図示せず）を介してウェブ・サーバ（７００）に送信する。ウェブ・サーバは、クエリー（７０２）に応答して、ステップ（７０３）においてネットワーク（図示せず）を介しマークアップ・ファイルを送信する。プロキシはマークアップ・ファイルを受信し、マークアップ・ファイルに対し前述した本発明の実施形態による一連のオペレーションを行い、しかる後、ステップ（７０４）において、ネットワーク（図示せず）を介し修正マークアップ・ファイルをブラウザ（７３０）に送信する。ウェブ・ブラウザ（７３０）は該修正マークアップ・ファイルを解釈する。

図７は単なる一例として提示されている。多くの選択肢および代替案についてさらに説明する。具体的には、一つまたは複数のネットワークを用いることができ、これらを時間によって変更することができ、異なったプロトコルを用いる異なった種類（ＲＴＣ、ＡＤＳＬ、ファイバ、Ｔ１、Ｗｉｍａｘ、ＵＭＴＳ、Ｗｉｆｉなど）とすることができる。

図８は、プロキシ上でのオペレーションを示す。

次に図８を参照する。該図は、ある実施形態による、ブラウザ・インスタンサ（８００）、画像ファイル・ジェネレータ（８１０）、ＤＯＭジェネレータ（８２０）、およびマークアップ・ファイル・ビルダ（８３０）を示す。

特定の実施形態によれば、ウェブ・サーバ（７００）から配信されたマークアップ・ファイルは、ブラウザ・インスタンサ（８００）によって受信される。ブラウザ・インスタンサ（８００）は該マークアップ・ファイルを解釈する、すなわちビューアまたはブラウザでマークアップ・ファイルを実行する。構文解析の後、ＤＯＭジェネレータ（８２０）は該マークアップ・ファイルのＤＯＭツリーを構築する。ＤＯＭジェネレータ（８２０）は、（ノード（群）の削除、ノード（群）の置換などのオペレーションによって）ＤＯＭツリーを操作または修正あるいはその両方を行うようになされている。ＤＯＭジェネレータ（８２０）は画像ファイル・ジェネレータ（８１０）と相互交信し、該ファイル・ジェネレータは、マークアップ・ファイルのＤＯＭツリーの一つまたは複数のノードから、一つまたは複数の画像（サブ画像）をレンダリングするのに適している。言い換えれば、画像ファイル・ジェネレータは、修正されたＤＯＭツリー（すなわち、スクリプト言語コード、ＨＴＭＬ、ＰＨＰ、ＸＭＬコードまたはデータ）を出力するＤＯＭジェネレータ（８２０）と相互交信する。

特定の実施形態によれば、次いで、マークアップ・ファイル・ビルダ（８３０）が、ＤＯＭジェネレータ（８２０）の修正されたＤＯＭツリーと、付加されたスクリプト言語コードを有する、画像ファイル・ジェネレータ（８１０）により生成された画像（またはサブ画像の集合）と、から修正マークアップ・ファイルを構築する。該スクリプト言語コードは、それが実行されるユーザ端末装置に、ユーザ制御のカーソルの位置を定義する座標情報を送信させるように構成される。加えて、該スクリプト言語コードは、それが実行されるユーザ端末装置に、ユーザ制御のカーソルのクリック・アクションを定義するアクション情報を送信させるようさらに構成することができる。また、該スクリプト言語コードは、（複数のサブ画像がレンダリングされている場合）生成された画像の相対的位置を符号化する。

次に、該マークアップ・ファイルがウェブ・ブラウザ（７２０）によって受信され、解釈される。ユーザのポインタ・アクションに応答して、ブラウザ・インスタンサ（８００）は、該ユーザのアクションを再現する。言い換えれば、ブラウザ・インスタンサ（８００）は、対応するブラウジング・インスタンスまたはセッションにおける、所与の座標でのユーザ制御のアクション（クリック）を模擬する。最後に、ブラウザ・インスタンサ（８００）がウェブ・サーバ（７００）にクエリーし、それに沿ってインターネットの双方向ブラウジングのプロセスが続く。

ある実施形態によれば、ウェブ・サーバ（７００）から配信された元のマークアップ・ファイルは一組の表示対象エレメントを包含し元のＤＯＭツリーに対応している一方、プロキシ・サーバ（７１０）によって出力された修正マークアップ・ファイルは、画像ファイル・ジェネレータ（８１０）によって生成された一つの付加画像（または複数の付加画像）、マークアップ・ファイル・ビルダ（８３０）によって生成された新規の（そして軽い）スクリプト言語コードを包含する。また、修正マークアップ・ファイルは、修正されたＤＯＭツリーによって再構築されているので新しいデータ構造を有する。

特定の実施形態によれば、マークアップ・ファイル・ビルダ（８３０）によって生成されるスクリプト言語コードに関し、該コードを、それが実行されるユーザ端末装置に、該座標情報を（プリフェッチ目的のため、すなわち、マークアップ・ファイル中に存在するリンクにおいて参照されるマークアップ・ファイルの要求を予期し応答時間を加速するため）連続的にまたは（リフレッシュ・メカニズムを介して）定期ベースで送信させるように構成できることがさらに観察される。生成された画像ファイルの相対的位置が、マークアップ・ファイル・ビルダ（８３０）によって生成されたスクリプト言語コードの一部を構成していることを思い起こすことができよう。特定の実施形態によれば、カーソルの座標またはアクション（クリック）あるいはその両方に関する情報は、生成画像の任意の一つに対する相対的なもの、あるいは修正マークアップ・ファイル中の絶対的座標として定義することができる。他の実施形態によれば、マークアップ・ファイル・ビルダ（８３０）によって生成されるスクリプト言語コードは、画像ファイル・ジェネレータ（８１０）に生成される画像のあるサブセットだけに対する、さらには単一の画像（サブ画像）のある部分域だけに対する座標およびクリックを送信するようさらに構成することができる。言い換えれば、ユーザ双方向性は、一部の領域に対しては可能に維持し、他の特定領域に対しては禁止（存在しない）することができる。このバリエーションは、ユーザ双方向性に及ぼせる制御性のゆえに非常に有用である。

ある実施形態によって、図６に関連して先に説明したような、画像の生成に際しての、ウェブ・ブラウザ中で実行されるインスタンスとブラウザ・インスタンサ中で実行されるインスタンスと間のある種のミラーリングが開示される。かかるミラーリングはさらなる可能性を提供する。マークアップ・ファイルがＨＴＴＰマークアップ・ファイルである場合、ＨＴＭＬ要求が行われるとき、ブラウザ自体についての情報が送信される（種類、色、解像度…）。通常、この種の身元情報（ｆｉｎｇｅｒｐｒｉｎｔ）は一度送信されるが、この情報を定期ベースで読み出すことができる。しかして、（ｊａｖａ）スクリプト・コードを使い、ページの解像度を解析し、これに沿って画像ファイルを（画像（群）をサイズ変更して）レンダリングすることが可能になる。特定の実施形態によれば、本発明の実施形態によって生成された画像は、元のマークアップ・ファイルの表示対象エレメントのサイズと同じサイズにすることができる。しかしながら他の実施形態では、対象となるビューアまたはブラウザの表示面積によって、より大きくしたり小さくしたりすることもできる。画像ファイルが対象となるビューアまたはブラウザの表示面積よりも大きな場合には、該対象となるビューアまたはブラウザは、標準的なスクロール選択を用いて元のマークアップ・ファイルの全体画像を表示することになる。最後に、他の実施形態によれば、クッキーの使用が、ユーザ制御の座標を格納し、ウェブ・ブラウザについての情報（種類、色、解像度…）を格納し、自動リフレッシュ・メカニズムを設定するなどのために有用であり得る。

特定の実施形態によれば、ウェブ・ブラウザによってマークアップ・ファイルの表示対象エレメントの画像レンダリングがわずかに異なり得る。原則的には、ＨＴＭＬは規格なので、最終的ＨＴＭＬページのレンダリングは市販のブラウザの間では一貫性がある。しかし実際上は、各種ウェブ・ブラウザにより行われる各種レンダリングの間には違いがあり得る。開示するオペレーションは、こういった違いを考慮に入れるように設計することができる。

次に図９を参照すると、アーキテクチャ選択肢および代替案が検討されている。

この開示は、好適な２階層アーキテクチャを示し、プロキシ・サーバが本発明の特定の実施形態のステップ（ＤＯＭツリーの修正および画像生成）を遂行する。ただし、提案されたメカニズムの実装は、以降に説明するようにもっと多くのやり方によって行うことができる。

プロキシおよびブラウザ経済性についての前置きの検討が必要である。ブラウザは広義に「ビューア」として理解することができる。ブラウザは、マークアップ・ファイルをユーザに対する表示対象エレメントにレンダリングし、コード・エレメントを実行するように設計される。実際上、ウェブ・ブラウザは、デスクトップ・コンピュータまたは携帯デバイスにインストールされたソフトウエア・プログラムであり、スクリプト・プログラム（ほとんどがＪａｖａＳｃｒｉｐｔ）を実行し、構文解析し、ウェブ・ページを表示するように構成されている。技術的および法的観点からは、一部のウェブ・ブラウザはオープン・ソース（Ｆｉｒｅｆｏｘ（Ｒ）など）であり他は所有権対象（インターネット）である。このオープン・ソースと所有権対象との間の違いは、所有権対象ソフトウエアがソフトウエア・コードの開発を統制できるのに対し、オープン・ソース・ソフトウエアはそれができない点で重要である。例えば、所有権対象メディア・プレーヤは早送りを禁止し、しかしてユーザにビデオ広告（通常、ビデオ・ファイルの開始部に配置されている）の視聴を強制することができる。オープン・ソース・ソフトウエア（すなわち、アクセス可能で変更可能なソフトウエア・コード）では、ソフトウエア・コードを変更して広告のスキップを可能にできるので、上記のようなことはもはやできない。さらに一般的には、このことは、どのＤＲＭ（Ｄｉｇｉｔａｌ Ｍａｎａｇｅｍｅｎｔ Ｒｉｇｈｔ（デジタル著作権管理））システムにも当てはまり、これらは非公開ソフトウエア・コード（だれでも利用可能なオープン・ソース・コードと対照的に秘密に保護されている）の少なくとも一部を必ず必要とする。原理的には、（利用可能な特定のアドオンなど無くても）所有権対象ブラウザで、広告遮断を選択的に可能にすることができるであろう。オープン・ソース・ウェブ・ブラウザの場合はもっと簡単で、いつでも、かかる特定のアドオンを可能にするフォークが出現し得る。別の広告遮断エコノミの重要な局面は事業利益である。有名なオープン・ソース・ブラウザは大手広告会社から大きな収入を得ている（従って、自社のブラウザに広告ブロッカのデフォルト組み込みを可能にすることにはほとんどインセンチブおよび興味を持っていない）。しかし、フォーク（該オープン・ソース・ブラウザの改造品）が何時でも出現する可能性がある。所有権対象ブラウザは、それら自身の利益および契約によって、おそらく、選択的に一部の広告を実行可能にし他は実行不能にすることができるであろう。例えば、マイクロソフト（Ｒ）インターネット・エクスプローラが、グーグル・アドワーズ（商標）を遮断し、自社のプラットフォームのものだけを実行可能にすることが技術的には可能かもしれない。これら全ての理由によって、本発明の実施形態のステップを遂行するプロキシ・サーバの使用が非常に有用である（だが必須ではない）。

図９には、さまざまな構成のウェブ・サーバ（７００）、プロキシ・サーバ（７１０）、およびウェブ・ブラウザ（７２０）が示されている。論理的には、プロキシ・サーバ（７１０）は、ウェブ・サーバ（７００）とウェブ・ブラウザとの間に配置される。物理的には、例えば図９（ａ）に示されるように、プロキシ・サーバ（７１０）とウェブ・サーバ（７００）とを同一の物理的マシンで実行することができる。しかしながら、ウェブ・ブラウザ（７２０）自体を実行するローカル・マシン上のバーチャル・マシンを使うことは必ずしも可能ではなく、図９（ｂ）は、プロキシ・サーバ（７１０）およびウェブ・ブラウザ（７２０）が同一の物理的マシンで実行されている状況を示す。最後に、図９（ｃ）は、ウェブ・サーバ（７００）、プロキシ・サーバ（７１０）、およびウェブ・ブラウザ（７２０）が３台の異なる物理的マシンで実行されている状況を示す。

プロキシは通常ハードウエア実装であるが、ソフトウエア実装することもできる。従って、本発明の実施形態のステップは、一部をウェブ・ブラウザ（７２０）に、一部をプロキシ・サーバ（７１０）に、一部をウェブ・サーバ（７００）（またはこれらの組合せに）実装することができる。

特定の実施形態によれば、プロキシ・サーバはウェブ・サーバへの全てのクエリーを見ることになるので（ウェブ・ブラウザのアカウント番号、パスワードおよび訪問ページが、ウェブ・ブラウザのクエリーを介してプロキシ・サーバに送信されることになる）、プロキシが信頼できる当事者によって実行されるよう強く勧告する（ただし、オープンＩＤまたは他の匿名化メカニズムが使われている場合を除く）。（厳しい認証から単純な登録までの範囲の）認証メカニズムを用いることができる（画像ファイルの配信に対してハッシュ値を使うことができる）。

ウェブ・サーバの管理者（コンテント・プロバイダ）と広告主との間の契約の面から、図９（ａ）が簡単で容易な実装と予想される。ある好適な実施形態において、ウェブ・ブラウザはこの実装モードについては何も気付かない（遂行されるオペレーションは見えない、すなわち、クエリーはプロキシ・サーバによって容易に途中捕捉され、ブラウザは修正されたマークアップ・ファイルを受信するだけとなる）。かかる構成の利点は、ウェブ・ブラウザは悪意あるコードが一切実行されない保証を有し、コンテント・プロバイダはその広告を確保する保証を得ることである。これは、多くの興味あるビジネス機会を開く両者ともに有利なオペレーションである。

図９（ｂ）は、ある実施形態によるさらなるやり方を示す。本発明の実施形態を実装するプログラムは、ウェブ・ブラウザよりも高度なレベル（例えば、オペレーティング・システム）で実行することができる。あるいは、これをプラグインまたはアドオンの形で実装することもできる。かかるプログラムの実行または存在を、例えばウェブ・サーバによって要求させることもできる（例えば、不適合ブラウザには配信しないなどして）。ブラウザは前述したステップを設けることに同意してもしなくてもよい。例えば、ウェブ・ページの配信を許可するため、広告主が（市販の「広告確保」ブラウザ・アドオンを介しての）かかるプログラムの存在または実行を要求することができる（この場合、ブラウザのユーザは、例えばかかるアドオンのインストールに同意すればよい）。また、特定の実施形態によれば、これをマルウエアの形で実施することもでき、該マルウエアはブラウザのユーザの同意なしでこれらのステップを実行することになる。他の実施形態によれば、これによって、所有権対象ブラウザ（これに対しユーザは全くでないにせよほとんどコントロールを持たない）中への本発明の実施形態の実装に対応することもできる。

図９（ｃ）はもっと複雑なケースを示している。というのは、プロキシ・サーバが、例えばマルウエアとして行動することができるからである（広告掲示の確保のための介入アタック、最終的にはブラウザの意思に反しまたはその同意なしで）。また、特定の実施形態によれば、これは、ネットワークを介したプロキシ・サーバ群の相互依存の可能性、あるいはプロキシが、ウェブ・サーバのためのオンデマンド・リソースとしての役割を果たし、ウェブ・ブラウザに対してはインターネットへの信頼できるアクセスを提供することをも示している。

提案した２階層アーキテクチャについてさらなる見方を形成することができる。すなわち、修正マークアップ・ファイルに（一部の状況において）コンテント・サーバのアドレス（前述の方法を実装していない外部ウェブ・サーバのＵＲＬ）を排他的に含めることができ、この場合、ウェブ・ブラウザは、修正マークアップ・ファイルを解釈する際に、これらのコンテント・サーバに直接クエリーすることになる（例えばＨＴＴＰのＧＥＴ要求）。これはオープン・システムである。例えば、前述の方法のかかる使用のシナリオは、ウェブ・ページの表示を確保するための単発の「オンデマンド」方式に相当する。しかしながら、修正マークアップ・ファイルには、前述の方法を実装しているプロキシ群のアドレスを排他的に含めることもでき、この場合、これらプロキシは、要求されるコンテンツを検索するためのアドレス変換ツールをさらに備えることになろう。これはクローズド・システムであり、ウェブ・ブラウザに前述のシステムを実装しているプロキシだけにクエリーするよう強制する。ウェブ・ブラウザが、かかるプロキシにクエリーしたならば、それは捕捉され、（本方法または他方法によって）再処理されたコンテンツだけを見ることになる。最後のやり方は、修正マークアップ・ファイルに、コンテント・サーバ（直接クエリーのため）およびプロキシ（間接的クエリーのため）の双方のアドレスを含めることである。これらの３つのやり方は、決定される方針（前述のシステムをクローズドにするかオープンにするか、あるいはどの点で部分にオープンにするかまたはクローズドにするかを決める方針）の如何による。

次に、別の実施形態について説明する。

本発明の特定の実施形態は、見かけ上は関係のない技術の間、すなわち画像生成の技法とＤＯＭツリー修正メカニズムとの間の相乗効果であると見ることができる。言い換えれば、本発明の実施形態は、画像生成処理メカニズムに加えＤＯＭツリー修正メカニズムを組み合わせている。

特定の実施形態によって、広告の掲示を（選択的に、他に加えて）確保するためのシステムが提供される。該システムは、ウェブ・サーバ、プロキシ・サーバ、およびクライアント・ブラウザを含む。クライアント・ブラウザの最初のクエリーに応答して、プロキシ・サーバは、ウェブ・サーバに対応するマークアップ・ファイルを要求し、上記マークアップ・ファイルを受信次第、プロキシ・サーバはブラウザ中で上記マークアップ・ファイルを解釈し、ＤＯＭツリーを取得し、解釈された（実行された）マークアップ・ファイルの一部をグラフィカル画像に変換する。次いでプロキシ・サーバは、修正されたＤＯＭツリーからの上記グラフィカル画像（並びに、随意的に再設計され、ユーザ制御のカーソルの位置を定義する座標情報および該ユーザ制御カーソルの（クリックなどの）アクション情報を送信するように構成された、軽量のスクリプト言語コード）を含む修正マークアップ・ファイルを構築する。最後に、クライアントのウェブ・ブラウザが、修正マークアップ・ファイルを表示し解釈する。

本発明の特定の実施形態によれば、ビューアまたはブラウザにおいてマークアップ・ファイルを解釈する（またはレンダリングする）ことによって、該マークアップ・ファイルの表示対象エレメントを定義する（またはレンダリングする）。解釈されたマークアップ・ファイルを、全体的にまたは部分的に、ある画像の中に「凍結」することができる。言い換えれば、解釈されたマークアップ・ファイルの一部の領域または下位区分をそれに関連する画像（群）で置き換え、該画像（群）を、これに沿ってマークアップ・ファイルのスクリプト言語コードを変更することによって、または変更しながら、修正マークアップ・ファイル中に含めることができる。元のおよび修正後のマークアップ・ファイルの両方は、解釈された（レンダリングされた）とき、同じように見えるが、スクリプト言語コードは大きく異なることになる。修正マークアップ・ファイルは、レンダリングされた画像に関連する、変更され（および簡素化され）たスクリプト言語コードを確かに包含する。加えて、該画像をさらに変形することができる（画像をランダムにまたは非ランダムに分割したり、グレースケールしたりなどできる）。このフレキシブルな「凍結化」はマークアップ・ファイルのＤＯＭツリーの操作によって達成される。「凍結」対象の、解釈済みマークアップ・ファイルの下位区分を考慮しながら、マークアップ・ファイルのＤＯＭツリーが解析される。この下位区分に対応する子ノード群が定義される。次いで、これら子ノードを含む親ノード群も定義される。一つの親ノードが選択されこの親ノードに対応する表示対象エレメントの一組が画像に変換される。該選択された親ノードは該画像を含むノードによって置き換えられ、しかして、解釈されたマークアップ・ファイルのレイアウトはそのまま変わらない。

本発明の別の実施形態によって、インターネット・コンテントを視聴する方法が提供され、該コンテントは、遠隔プロキシ・サーバが要求に応答してインターネットから読み出したウェブ・ページを該遠隔プロキシ・サーバにおいてレンダリングした画像であり、該ウェブ・ページはテキストおよびグラフィックスを包含する。

特定の実施形態によって、ロバストなプロキシ・インターネット・ブラウジング方法が開示され、該方法により、プロキシ・サーバは、ブラウザ対象サイトを表現する画像データを、ユーザ・マシン上の標準的ウェブ・ブラウザに表示のため送信し、該ブラウザで実行されるスクリプトを使ってマウスの命令を捕捉する。

好適な実施形態において、マークアップ・ファイルは、ＨＴＭＬ（ハイパーテキスト・マークアップ言語）またはＰＨＰページであるが、もっと広範囲な状況を想定できると観察される。実際に、本開示は、ワールド・ワイド・ウェブ以外の環境にも同様に適用される。しかして、本発明の範囲は、電気通信の全形態を網羅することが意図されている。

本質的には、開示された技法は、環境が何であれ、任意の種類のマークアップ・ファイルに適用される。例えば、該技法は、移動／無線環境における、ＷＭＬページに適用される。本本発明は、ＸＨＴＭＬ（改良されたＸＭＬ）、ＤｏｃＢｏｏｋ、ＭａｔｈＭＬ、ＳＶＧ、Ｏｐｅｎ ｅＢｏｏｋ、ＴＥＩ、ＸＢＡ、ＳＧＭＬ、ＸＭＬなどの周知の全てのマークアップ言語、並びに、記述マークアップ言語をサポートするよう明示的に設計された他のシステムを網羅する。ほとんどのブラウザは、ＨＴＭＬに加えさまざまなフォーマットをネイティブにサポートしており、プラグインの使用を介してさらに多くをサポートするよう拡張することができると観察される。同様に、本開示は、最新のウェブ・インタフェース進展を含めた多くの技術に対し適用することができる。すなわち、ＪＶＭ（Ｊａｖａ Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅ（Ｊａｖａ仮想マシン））によってウェブ・ページで実行が可能な、Ｊａｖａのアップレットを含むウェブ・ページに対して、ＡＪＡＸ（Ａｓｙｎｃｈｒｏｎｏｕｓ ＪａｖａＳｃｒｉｐｔ ａｎｄ ＸＭＬ（非同期ジャバスクリプトおよび拡張マークアップ言語））において、または、ＦｌａｓｈないしＷＰＦ／Ｅのような技術（適応プラグインが必要）を使って、あるいはその両方によって展開可能なＲＩＡ（Ｒｉｃｈ Ｉｎｔｅｒｎｅｔ Ａｐｐｌｉｃａｔｉｏｎｓ（リッチ・インターネット・アプリケーション））を含むウェブ・ページなどに対して適用することができる。さらに最後に、仮想マシンを必要とするＲＤＡ（Ｒｉｃｈ Ｄｅｓｋｔｏｐ Ａｐｐｌｉｃａｔｉｏｎｓ）を現在使用しているウェブ・インタフェース（例：Ｅｃｌｉｐｓｅ ＲＣＰ、ＮｅｔＢｅａｎｓ、Ｊａｖａ Ｗｅｂ Ｓｔａｒｔ、Ｍｏｚｉｌｌａ ＸＵＬＲｕｎｎｅｒ、Ａｄｏｂｅ ＡＩＲ、またはＭｉｃｒｏｓｏｆｔ ＳｍａｒｔＣｌｉｅｎｔ）、あるいは、Ｆｌａｓｈ／Ｆｌｅｘ／ＡｃｔｉｏｎＳｃｒｉｐｔまたはＨＴＭＬ／Ｊａｖａｓｃｒｉｐｔ／ＣＳＳ／ＡＪＡＸなどの技術を用いて作動するウェブ・インタフェースに対して適用することができる。ここで、ＸＵＬは、Ｗ３Ｃ規格ＸＭＬ １．０に基づくＸＭＬ言語であることを思い起こす。ＸＵＬで書かれたアプリケーションは、ＨＴＭＬ ４．０を特徴付ける追加されたＷ３Ｃ規格の技術、すなわちカスケード・スタイル・シート（ＣＳＳ：Ｃａｓｃａｄｉｎｇ Ｓｔｙｌｅ Ｓｈｅｅｔｓ）１および２、ドキュメント・オブジェクト・モデル（ＤＯＭ：Ｄｏｃｕｍｅｎｔ Ｏｂｊｅｃｔ Ｍｏｄｅｌ）レベル１および２、ＥＣＭＡ−２６２バージョン３（ＥＣＭＡｓｃｒｉｐｔ）を含めＪａｖａＳｃｒｉｐｔ １．５、ＸＭＬ １．０に基づいている。

特定の実施形態によれば、前述のアプローチは、純粋なウェブ環境に限定されるものでなく、例えば、電子メッセージングは本発明の実施形態を実装することができる（ｅメールクライアントは多くの広告を受信しており、これらの効果的掲示の確保が送信者によって意図される）。ｅメール（電子メッセージ）はＨＴＭＬフォーマットにすることが可能であり、それらも網羅される。また、他の実施形態によれば、本開示は、単なるウェブ・ブラウザでなく、アプリケーション・パッケージに適用し、アプリケーションにも広告を組込むことができる。例えば、広告をｐｄｆビューアに組込むことができる（ｐｄｆはデファクト・スタンダードであり、広告は、ｐｄｆファイルの他のパラメータとともに、そのコンテキストおよびコンテンツに沿って、最終ユーザに合わせたものにすることができる）。ＳａａＳ（Ｓｏｆｔｗａｒｅ ａｓ ａ Ｓｅｒｖｉｃｅ（サービスとしてのソフトウエア））パラダイムによれば、ソフトウエアはインターネットを介して配信され、どのソフトウエア・アプリケーションも、マークアップ・ファイル（ＨＴＭＬページ）として出現し得る。同様に、ゲーム環境にも益々多くの組込み広告が提供されている。こういった環境で、広告遮断技法が出現してくる可能性があり、本開示が広告の掲示の確保を可能にすることができよう。特定の実施形態によれば、本開示は、実際に（「コンテント・レンダリング・アプリケーションまたはデバイス」でドキュメントのコンテントがレンダリング可能な）全てのビューアを対象とする。コンテント・レンダリング・アプリケーションの例には、インターネット・ブラウザ（例、エクスプローラまたはネットスケープ）、メディア・プレーヤ（例、ＭＰ３プレーヤ、Ｒｅａｌｎｅｔｗｏｒｋｓのストリーミング・オーディオ・ファイル・プレーヤなど）、ビューア（例、Ａｄｏｂｅ（Ｒ）アクロバットｐｄｆリーダなど）が含まれる。

また、特定の実施形態によれば、本開示はいわゆるマッシュアップを保護するためにも非常に有用である。マッシュアップは、ユーザのブラウザにおいて複数のコンテント・プロバイダからのコンテンツ（データおよびコード）を混成、融合し、高価値のウェブ・アプリケーションを提供する。ウェブ・アプリケーションは、手軽に利用できるクライアント側のＪａｖａＳｃｒｉｐｔライブラリ（およびＡＪＡＸなどのプログラミング・パラダイム）使った、クライアント側（ブラウザ）での拡張スクリプト記述に益々頼るようになっている。マッシュアップ・ディベロッパは、通常、ウェブ・アプリケーション・プロキシ・サーバを用い、該サーバは異なったサーバからコンテントを採取し、または異なる供給元からのコードを直接含めて、それをマッシュアップに配信する。コンテンツを分離したり集合したりすることにより、組入れられたまたは添付された広告が除去されたりスキップされたりするリスクがある。通常のブラウザ・プラットフォームのネイティブのセキュリティ・モデルは、コンテントを分離すること、すなわち広告を除去することを可能にする。本開示の画像生成メカニズムを用いることによって、コンテントを分離不能にすること（コンテンツのカプセル化）が可能で、これによりこれらマッシュアップ環境における広告の掲示を確保することもできる。これらの画像生成技法に関連し、さらなるコード書換えメカニズムに、統計的解析および動的コード書換えの組合せが可能なＪａｖａＳｃｒｉｐｔ書換え（ＪａｖａＳｃｒｉｐｔの自己修正的性質に起因する）を用い、オペレーションを書換え作業プロキシに行わせることができる。

さらに一般的には、前述のスクリプト言語コードの再処理のメカニズム並びに画像の生成は、視覚化とプログラミングとの間の区分が可能ないかなる状況にも適用される。画像マッピング／生成は、アナログ・キャプチャまたはビデオ・バッファによるアクセスを介して常に可能であろう。次に、本記載により、下層にあるプログラミング・コードにアクセスが可能なあらゆる場合に適用できる技法を開示する（該技法は収入源の確保を可能にするので、こういった場合の方が多そうである）。コード・エレメント（下層のプログラムおよび命令）へのアクセスが可能な場合（例えば、ＡＰＩによって）、これらは（リアルタイムであっても）修正することができ、提案のメカニズムが広告掲示の確保を可能にする。下層のプログラムにアクセスができない場合であっても、該プログラムを突き止め、シミュレートし、予測し、計算することなどができる。続いて、再プログラミングに到達することも可能である（処理技術の現在範囲に、突き止めるためのステップを加える必要がある）。

以降に、本発明の実施形態と随意的に組み合わせが可能な高度な機能について説明する。

ＤＯＭ検査ツールが市販されている。かかるツールは、本発明の実施形態を実装することによって大きな利点を得ることになろう。例えば、本発明の実施形態により、Ｍｏｚｉｌｌａ ＤＯＭ検査ツールは（一つまたは複数のノードのコンテンツを一つまたは複数の画像に変換し、ＤＯＭツリーを修正し、生成された画像（群）を直接修正マークアップ・ファイルに含めることによって）マークアップ・ファイルを直接に修正し、保存することを可能にできよう。かかる展開は、ユーザが、編集作業の間、自分のドキュメントの部分を（画像中に）「凍結」することを可能にする。多くの利点と併せ、これは、ユーザが自分のコンテンツの画像変換された部分のクローリングおよびインデキシングを防止することを可能にする（なぜならば、スパイダまたはボットは画像のピクセルを解析しないからである）。また、これは、（マークアップ・ファイルが配信されたとき）コンテンツの最終視聴者によるいかなるコピー／ペースト・オペレーションも禁止をすることを可能にするであろう。

本発明の実施形態の別の可能な用途は、エラーを包含するマークアップ・ファイルを修復することにあろう。エラーが（例えばスクリプト中に）検出された場合、エラーを包含するノード（群）のコンテントを、本発明の実施形態によって画像に変換することにより、エラーなしのマークアップ・ファイルを生成することが可能になる。

画像生成の使用は、それがマークアップ・ファイル上の出力制御可能性を含蓄するので、多くの興味深い機会を提供する。例えば、レンダリングされたノードに対応する画像に対し、該画像を安全なサーバにホストし、該対象画像にアクセスするための認証または支払いあるいはその両方を要求することが可能であろう。このとき、十分な柔軟性を持って、所与のファイルの部分を選択的に保護することができよう。同様なメカニズムによって、ユーザまたはマシンに対し前もって認可されている権利に従って、コンテンツまたはコンテンツの一部への条件付アクセスを実施できよう。

画像生成に加えて、＜ｕｓｅｍａｐ＞タグの使用が有用である。ｕｓｅｍａｐ属性は、画像の諸部分を画定するマップをポイントする。これは、ＵＲＬおよびリンクの再符号化、およびドキュメントの双方向性制御の追跡を可能にする。

また、「ノード制御」については、きめ細かなメカニズム（あるノードが有効か無効かの判定、ノード・イベントの再符号化など）を実装することも可能になろう。「ＤＯＭツリー制御」については、興味深い可能性について考えることができる。例えば、デーモンまたはソフトウエア・プログラムが、ユーザに対する最終表示を可能にする（またはしない）ため、修正されたまたは構文解析されたマークアップ・ファイルのＤＯＭツリーの完全性を点検する。かかるＤＯＭツリー・プロフィールは、例えば文字または数字の一組などの「署名」を使用することができよう。（フィルタリング技法に対して）堅牢なＤＯＭツリーを包含する「最良実施の」データベースを構築することも可能であろう。ＤＯＭパスの制御も同様な利点を提供する。

次に、他の考察事項を説明する。

第一に、本発明の実施形態と組み合わされた、データ・センタのソフトウエア・コードの非常に頻繁な更新が効果的であり得る。本発明の実施形態を実装している広告主は、実際に非常に頻繁に、（例えばウェブメールで）コンテンツおよびサービスを顧客に配信するデータ・センタのソフトウエア・コードを更新することができよう。これを追って、広告ブロッカは、学習し、それに応じてアドブロッカ・プラグインまたはアドオンのコードを更新して適合を試みることができようが、該変更の頻度が広告遮断を思いとどまらせることができよう。

第二に、本発明の実施形態と組み合わせて、暗号化ブラウジング・セッション（例えばＳＳＬ）による取り扱いを行うことが興味あるやり方と思われる。考え方は、コンテンツの配信を受諾するため、サービス・プロバイダが配信されるコンテンツの完全性を点検できるようにすることである（しかして、広告を含む全コンテンツの表示が保証されることになろう）。そのために、ハッシュ値の使用を含めいくつかのメカニズムを用いることができる。アドブロッカは、それでも、かかる環境（例えば、ｈｔｔｐｓ下でのウェブメール）において広告をスキップすることに成功するように観察される。その理由は、クライアントにおいて、コンテンツを解読した後、ユーザに最終の視覚レンダリングの前にアドオンおよびプラグインが作動することにある（データ転送層だけが関与する）。言い換えれば、ユーザ・マシンの最終点での制御が設定されていない限り、クライアント・ブラウザのごく終端まで、追加的なフィルタリング・ステップによる変更が常に可能なことになる。言い方を変えれば、暗号化メカニズムを、前述の本発明の実施形態に組み合わせるのは興味深い仕方（画像暗号化など）である。

第三に、本発明の実施形態は、信頼できるコンピューティング・メカニズムに端を発する配信パラメータまたは配信制約と組み合わせることができる。例えば、特定のネットワークは、不適合ブラウザへのウェブ・ページの配信を拒否することができる。これは、例えば、オペレーティング・システムの更新に対するメカニズムなどに関連している。承認または認証されたクライアントが使用していることの検証によって、ウェブ・サイトは、ユーザにある特定数の広告を見ることを強制していることへの満足を得ることができよう（なし得るシステムが認証されたＤＯＭツリーの完全性を確認することになろう）。これと反対に、ブラックリスト・メカニズム（禁止されたプロキシ、スパイダ、あるいは、無許可での抽出、フィルタリング、またはＤＯＭ変更のメカニズムもしくは技法を使用しているとして識別されたプロキシには配信しない）を用いることも可能であろう。しかしこれに対し、プロキシ回し（ｐｒｏｘｙ−ｂｏｕｎｃｉｎｇ）（またはデータ捕捉）技法が、これらブラックリスト・アプローチを破ることを可能にできよう。まださらなる対策は、コンテンツ配信に対する正確な経路の要求から成ることになろう。具体的には、ユーザは、関係コンテンツの受信を可能にするため、リンクの所定の経路（これはボットまたはスパイダが正確に追跡することが不可能なものとされよう）をたどらなければならないことになろう（そうしなければ、所望のコンテンツは配信されないことになる）。ＤＯＭツリーの修正は、このような局面およびルールを考慮に入れるように設計することができる。同様に、「承認された」ソフトウエアだけが読取り可能で、そのため、ネットワーク・サーバから解読キー（該キーは、リバース・エンジニアリングによって再生するのが極度に困難）を取得しなければならない、専有の暗号化ファイル・フォーマット生成することも可能であろう。信頼できるコンピューティング・パラダイムに関連する発展は、コンピュータ・デバイスの制御に向かう傾向があり、ＯＳ（深い）レベルが、広告の配信を可能にする最後のレベルとなり得る。

第四に、ＤＯＭの書換えは、多くの興味深い機会を提供する。例えば、単一の画像（および関連する非常に単純なＤＯＭツリー）を生成し、それを背景画像として使いながら、可能なビデオ域を（マークアップ・ファイルがＨＴＭＬマークアップ・ファイルすなわち適合ＤＯＭツリーであったならば、＜ＤＩＶ＞タグを使って最前面に）重畳するのは有用であろう。最前面に画像を用い、内蔵ビデオ・プレーヤ中の早送りボタンへのアクセスを不能にし、ユーザがビデオの中の広告をスキップするのを阻止する（このオペレーションは、例えばリフレッシュによる一時的なもの、あるいは恒久的なものにされる）など、広範囲の間接的応用を考えることができる。

本発明は、全体がハードウエアの実施形態、全体がソフトウエアの実施形態、または、ハードウエアおよびソフトウエア・エレメントの両方を包含する実施形態の形を取ることができる。好適な実施形態において、本発明はソフトウエアに実装され、これには、以下に限らないが、ファームウエア、常駐ソフトウエア、マイクロコードなどが含まれる。例えば、高パフォーマンス・システムへの、画像生成処理と抱き合わせた視覚化メカニズムのハードウエア実装が有益であることが実証できよう。

さらに、本発明は、コンピュータまたは任意の命令実行システムによって又はこれに関連させて使われるプログラム・コードを備えた、コンピュータ可用またはコンピュータ可読の媒体からアクセス可能なコンピュータ・プログラム製品の形を取ることもできる。この説明の目的の上で、コンピュータ可用またはコンピュータ可読の媒体は、命令実行システム、装置、またはデバイスによって又はこれに関連させて使われるプログラムを、包含、格納、通信、伝播、または伝送できる任意の装置であり得る。

ＦｉｒｅｆｏｘはＭｏｚｉｌｌａ Ｆｏｕｎｄａｔｉｏｎの商標である。インターネット・エクスプローラはＭｉｃｒｏｓｏｆｔ Ｃｏｒｐ．の商標である。グーグルはＧｏｏｇｌｅ Ｉｎｃ．の商標である。他の会社、製品、またはサービスの名称は、他社の商標またはサービスマークであり得る。

Claims (11)

1. コンピュータが一つ以上の表示対象エレメントを含む解釈されたマークアップ・ファイルのＤＯＭツリーを修正する方法であって、
   前記コンピュータが実行する、
   前記解釈されたマークアップ・ファイルの特定の表示領域を定義するステップと、
   前記解釈されたマークアップ・ファイルの前記ＤＯＭツリーを得るステップであって、前記ＤＯＭツリーは少なくとも一つの親ノードおよび複数の子ノードを含み、各ノードは前記表示対象エレメントの少なくとも一つと関連付けられている、前記ＤＯＭツリーを得るステップと、
   前記ＤＯＭツリーの中で、対応する表示対象エレメントが前記特定の表示領域の少なくとも一部を含む前記子ノードの一組を識別するステップと、
   前記ＤＯＭツリーの中で、前記子ノードの一組を含む第一親ノードを識別するステップと、
   前記識別された第一親ノードに関連する全ての表示対象エレメントをマスタ画像に変換するステップと、
   前記マスタ画像を含む第二親ノードを生成するステップと、
   前記識別された子ノードの一組を削除し、前記識別された第一親ノードを前記第二親ノードに置き換えることによって、前記ＤＯＭツリーを修正ＤＯＭツリーに修正するステップと、
   を含む前記方法。
2. 前記修正ＤＯＭツリーに従って修正マークアップ・ファイルを構築するステップをさらに含む、請求項１に記載の方法。
3. 前記マスタ画像を提供し、前記修正マークアップ・ファイルを解釈するステップをさらに含む、請求項２に記載の方法。
4. 前記修正マークアップ・ファイルは、スクリプト言語コードが実行されるユーザ端末装置にユーザ制御カーソルの位置を定義する座標情報を送信させるように構成された前記スクリプト言語コード、をさらに含む、請求項２又は３に記載の方法。
5. 前記スクリプト言語コードは、それが実行されるユーザ端末装置にユーザ制御カーソルのクリック・アクションを定義するアクション情報を送信させるようにさらに構成されている、請求項４に記載の方法。
6. 前記マスタ画像は複数のサブ画像にさらに分割される、請求項１乃至５のいずれかに記載の方法。
7. 歪曲化、グレイスケール化、再符号化、サイズ変更、ノイズ付加、離散化、再サンプリング、またはスクランブリングなどの操作によって、前記マスタ画像、または前記サブ画像の少なくとも一つを変化させるステップをさらに含む、請求項６に記載の方法。
8. 前記マークアップ・ファイルはＨＴＭＬ、ＰＨＰ、またはＸＭＬファイルである、請求項１乃至７のいずれかに記載の方法。
9. コンピュータ・デバイスで実行されたとき、前記コンピュータ・デバイスに請求項１乃至８のいずれかに記載の前記方法を実施させる、コンピュータ・プログラム。
10. 請求項９に記載のコンピュータ・プログラムが格納されるコンピュータ可読媒体。
11. 一つ以上の表示対象エレメントを含む解釈されたマークアップ・ファイルのＤＯＭツリーを修正するコンピュータであって、
    前記解釈されたマークアップ・ファイルの特定の表示領域を定義するステップと、
    前記解釈されたマークアップ・ファイルの前記ＤＯＭツリーを得るステップであって、前記ＤＯＭツリーは少なくとも一つの親ノードおよび複数の子ノードを含み、各ノードは前記表示対象エレメントの少なくとも一つと関連付けられている、前記ＤＯＭツリーを得るステップと、
    前記ＤＯＭツリーの中で、自分の表示対象エレメントが前記特定の表示領域の少なくとも一部を含む前記子ノードの一組を識別するステップと、
    前記ＤＯＭツリーの中で、前記子ノードの一組を含む第一親ノードを識別するステップと、
    前記識別された第一親ノードに関連する全ての表示対象エレメントをマスタ画像に変換するステップと、
    前記マスタ画像を含む第二親ノードを生成するステップと、
    前記識別された子ノードの一組を削除し、前記識別された第一親ノードを前記第二親ノードに置き換えることによって、前記ＤＯＭツリーを修正ＤＯＭツリーに修正するステップと、
    を実行するコンピュータ。

Images