JP2010540002A - 後で統合されたコードを使用するソフトウエア・エグゼクタブルからの出力の独立に定義された変更 - Google Patents

Abstract

コンピュータ・ゲーム等の第１のエグゼクタブルは第１のエグゼクタブルを操作しているクライアント上のイベントをモニタする第２の独立操作するエグゼクタブルにより構成される。第２のエグゼクタブルは、ビジネス・ロジック・テーブルにより定義される、モニタされたイベントに応答して行われるアクションを決定する。第２のエグゼクタブルはＡＰＩ呼出しをトラップして第１のエグゼクタブルの明白な出力を変更するアクションをとる。ビジネス・ロジック・テーブルはクライアントに別々に配布することができる。第２のエグゼクタブルおよび第１のエグゼクタブルは単一ファイルに結合することができる。第２のエグゼクタブルを使用して、既存のゲームのコンテキストまたは他のソフトウエア・エグゼクタブル内の、広告を含む、付加コンテンツを提供することができる。

Description

（関連出願の相互参照）
本出願は３５Ｕ．Ｓ．Ｃ．１１９§（ｅ）に従って２００７年８月２０日出願の米国仮特許出願第６０／９５６，８３７号に優先権を請求するものであり、その出願の全体が本開示の一部としてここに組み入れられている。

（背景）
１．（分野）
本開示は、ソフトウエア・エグゼクタブルから独立して定義され、ソフトウエア・エグゼクタブルが既に定義されている後で生じるプロセス内でそれに統合される変更スキームに従って、変更された出力を提供するソフトウエア・エグゼクタブルからのオリジナル出力の変更に関連している。

２．（関連技術の説明）
クライアント・コンピュータ上にインタラクティブ・ビデオ・ディスプレーを提供するさまざまなコンピュータ・プログラム、たとえば、インタラクティブ・ゲーム・プログラムが従来技術で知られている。ゲーム・プレー中に指示されたソースから広告材料を呼び出す関数をプログラミングすることによりこのようなゲームのプレー中に広告を挿入して、ビデオ・ゲームのプレー中に広告が現れるようにすることができる。たとえば、広告はモデル化されたビデオ・ゲーム環境内に存在するモデル化掲示板上に現れるようにすることができる。広告内容は実行時に指示された更新可能なソースから呼び出すことができ、したがって、ゲーム・プログラムが配布された後で更新することができる。

ゲーム・プレーのコンテキスト内に広告またはコミュニティ・メッセージを使用することはゲーム・ユーザの確立された基盤に表示される広告に対してスポンサーにスペースを売ることにより、あるいはゲーム・プレーを介して他の収益発生機会を促進することにより継続的な収益を発生する方法と認識される。さらに、特定のゲームの価値はアチーブメント、トーナメント、メッセージング等のコミュニティ機能、および遠隔ゲーム・プレーヤ間のより大きな社会的相互関係を促進する他の機能を加える、したがって、ゲーム・プレーにより提供される興味レベルを増すことにより高められ、それにより、新しいユーザを引きつけるだけでなく、ゲーム・プレーの量およびゲームに対するユーザの関心持続時間を増すことができる。

ゲーム環境における更新可能な広告および他の通信形式のこれらの利点にもかかわらず、これらの機能をゲーム・プレーに適合させる従来の方法にはある欠点がある。従来の方法では、一般的に、通信機能をゲーム自体内にデザインする必要があり、実行可能なゲーム・コードの一部となる。このように、通信モードは新しいゲーム・バージョンをダウンロードしてインストールしない限り変えられない。さらに、特定のゲームに更新可能な通信機能を提供するのにかなりの努力を費やすことがあり、そのためゲーム開発プロセスに時間、コストおよび複雑さが加わってゲームの開発に必要な投資が増すことになる。また、ゲーム・ソフトウエアを含むソフトウエアの開発および発行はその間の通信および調整が、少なくともある程度、損なわれている異なる事業者により行われることがある。したがって、ソフトウエア開発段階中にソフトウエア発行者が所望する機能を内蔵するのが困難となることがある。また、一度ソフトウエアが開発され公開されると、変更を達成するのはさらに困難となることがある。

したがって、従来技術のこれらおよびその他の制約を克服し、新しい予期せぬ方法で適用されてゲーム・プレイにおけるユーザの関心および参加を高める新しい方法およびシステムを提供することが所望されている。

（概要）
本開示は、変更スキームに従って変更出力を提供する実行可能なソフトウエア・アプリケーションからのオリジナル出力の独立して定義された変更に関連している。ソフトウエア、たとえば、実行可能なコンピュータ・ゲームは特定のハードウェア環境内で操作する時にユーザ入力に応答してオリジナル出力を作り出すように構成される。ソフトウエアは高水準言語からコンパイルされてコンピュータ・オペレーティング・システムにより実行可能と認識される、あるいは適用可能なハードウェア環境内で実行可能な他の離散静的コード、たとえば２進コード、として認識される実行可能なファイルを含むことができる。したがって、ソフトウエアは実行可能な形式であり、ここでは、しばしば「エグゼクタブル」と呼ばれる。オリジナル出力は、たとえば、ソフトウエア・エグゼクタブルを実行しているプロセッサに接続されたオーディオ、ビデオ、または電子的出力を含むことができる。ソフトウエア・エグゼクタブルはユーザ入力に応答して特定の定義された出力を生じさせるように構成することができる。たとえば、ジョイスティックからのユーザ入力に応答して、エグゼクタブルによりレンダリングされたスプライトまたはアバターはモデル化ゲーム環境内のジョイスティックにより指示される方向へ移動されることがあり、次に、それはグラフィクス・エンジンにより出力としてレンダリングされ、ディスプレー画面上に表示される。ソフトウエア・エグゼクタブルは、たとえば、スタンドアロン・モードで作動して、遠隔ノードとのリアルタイムまたはニア・リアルタイム通信を行うことなく、クライアント・ノード上にゲーム・プレーを提供するように設計することができる。ソフトウエア・エグゼクタブルは、１つ以上の遠隔ノードとのリアルタイムまたはニア・リアルタイム通信が行われる、ネットワーク・マルチプレーヤ・モードで機能することもできる。

変更スキームはソフトウエア・エグゼクタブルが特定のバージョンで発行された後でソフトウエア・エグゼクタブルから独立して定義することができる。発行されたバージョンとしてエグゼクタブルは、たとえば、エグゼクタブル・ファイル等の符号化された情報の離散静的ボディーを含んでいる。「独立に定義する」ことはソフトウエア・エグゼクタブルが既に定義されて静的であり、変更スキームがソフトウエア・エグゼクタブルの動作から独立して作動する別個の独立したプロセス内に定義されることを意味する。しかしながら、変更スキームを定義するプロセスはソフトウエア・エグゼクタブル、またはソフトウエア・エグゼクタブルのある表現を、入力すなわち参照データとして使用することができる。したがって、変更スキームはエグゼクタブルの開発から独立して開発および応用することができ、そのため、たとえば、ゲームおよび変更スキームの別個の開発を許す。変更スキームはエグゼクタブルが開発された後、エグゼクタブルが最終形式で一般に公開される前に、統合ツールを使用して開発および応用することができる。

変更スキームはオリジナル・イベントをエグゼクタブルから指定され変更された出力へマップする。オリジナル・イベントは、たとえば、グラフィクまたはオーディオ・レンダリング・システムへのアプリケーション・プログラム・インターフェイス（ＡＰＩ）呼出し、オペレーティング・システム（ＯＳ）への呼出し、キーボードやゲーム・コントローラ、グラフィク・メモリの状態、ゲーム・スコアを超える経過時間、またはそれらの任意の組合せ等の定義された入力の受信を含むことができる。定義されたイベントが検出されると、クライアント側変更エンジンがソフトウエア・エグゼクタブルからの出力を変更する予め定義されたアクションを起こす。たとえば、変更エンジンはコマーシャル・ビデオやイン−ゲーム・メッセージ等のゲーム・グラフィクス上に重ねられた情報、新しいクリエティブ情報を有するエグゼクタブル・メモリ・スペース内のオーバライト・クリエティブ情報、オーディオ・トラックのプレイ、ユーザ追跡情報の記録、または他の所望アクションを与えることができる。

クライアント側変更エンジンは、変更されるゲーム・アプリケーション等の、発行されたエグゼクタブルを含むランチャー・エグゼクタブルに内蔵することができる。ゲーム・アプリケーションの２進コードは、アプリケーション・エントリ・ポイントにおける新しい機械語コードを含むように自動的に２進コードを更新することにより、クライアント側変更を初期化する関数呼出しを加えるように変更することができる。それゆえ、オリジナル発行コードは最初に初期化してクライアント側変更エンジンＤＬＬをロードし、次にオリジナル・コードを呼び出す新しいエグゼクタブル・コードにより置換することができる。次に、変更エンジンはトリガ・イベントを検出するオリジナル・コードの操作中にクライアント・マシン状態をモニタすることができる。変更スキームにより定義されるトリガ・イベントが検出されると、変更エンジンは変更スキームを参照してイベントによりトリガされるアクションを識別する。次に、変更エンジンによりアクションが実施される。変更スキームはオリジナル・エグゼクタブルおよび変更エンジンを実行するエグゼクタブル・コードとは別に１つ以上のデータ・ファイル内に含むことができる。このように、変更スキームはエグゼクタブル・コードの更新を必要とせずに更新することができる。

ここに記述する技術は娯楽その他の目的、たとえば、ビデオ・ゲーム・プレーのために配布されるソフトウエアへ追加機能、更新、および広告を加えるための方法として利用することができる。ゲーム（その他の）ソフトウエアが完了した後で、それは変更エンジンが前記した方法で２進ゲーム・コード内に継ぎ足されるポスト開発プロセスに利用可能とすることができる。その継ぎ足された変更エンジンの適用は複写保護のために暗号化して通常の方法で配布することができる。変更エンジンは所望する期間だけ休眠状態に留まることができ、また変更スキームが定義されてアプリケーションが作動しているクライアント・ノードに提供されない限りかつ提供されるまでアプリケーションの動作に本質的に影響を及ぼさない。

したがって、本技術によりゲーム・プログラムを操作している分散クライアント・ノードへ広告その他の情報を配布する新しい方法が可能になる。ゲーム・プログラムはビデオ・インターフェイスとして機能するクライアント・ディスプレー装置上にビデオ出力を発生し、それを介してユーザはゲームの操作状態を視覚化する。ゲームの操作状態は１人以上のプレーヤからの入力、および予め定義されたルールおよびゲーム・プログラムにより使用されるデータによって決まる。このような１つの方法に従って、変更エンジンに対する２進コードがゲーム・アプリケーションに対する定義されたエグゼクタブル上に継ぎ足される。結合された変更エンジン／ゲーム・アプリケーションがクライアント・ノードへ配布される。別個に、変更スキームが開発され、ネットワーク接続等を介して、クライアント・ノードへ自動的に配布される。ビデオ出力用の広告データを含めて、変更スキームを満たすために使用される変更データも同様に配布することができる。変更スキームおよび変更データのいずれかまたは両方を所望により修正して非常に多くのクライアントに配布することができる。それゆえ、ゲーム中に現れる広告のコンテンツ、およびゲーム中にいつどこでそれが現れるかを任意所望の時間に修正または更新することができる。したがって、広告はゲーム・プレー中にビデオ出力内に付加または交番ビデオ・データとして現れ、ゲーム・アプリケーション自体の開発とは独立して、所望により更新することができる。

この技術は広告アプリケーションに限定されない。ここに記載される技術は無数のゲームＩ／Ｏから読み出される複雑なイベントの検出に基づいてユーザのビデオ・ゲーム経験をダイナミックに追跡および／または変更するのに使用することができる。この技術はビデオ・ゲーム挙動を複雑なイベント・ストリームとして解釈し、それをイン・ゲーム（ゲーム内）・アクションをトリガするクライアント側ダイナミック・ビジネス・ロジックへの入力として使用する。この新しい技術アプローチを使用すれば、ソース・コード内への統合機能を必要とせずに、先進的な収益化およびゲーム内のコミュニティ・ビルディング機能を提供することができ、このような機能が従来技術のゲームではどのように促進されるかということとは反対である。これらの先進的な機能は基盤となるソフトウエア・エグゼクタブルに対するソース・コードへのいかなるアクセスも無しに実現することができる。

特に、前記した方法およびシステムを使用してソフトウエア・エグゼクタブルの実行およびランタイムにおけるユーザ入力により生じるさまざまな情報ストリームからイベントを検出するのに使用することができる。限定はしないが、典型的なイベントとして下記のものが含まれる。
１．テクスチュア、ジオメトリ、オーディオ・ストリーム等のグラフィカルまたはオーディオ関連ゲーム・オブジェクトの１つまたは組合せ、
２．ゲーム・スコア、健康、等の任意の参照データの値、
３．グラフィカル出力の性質、または、
４．マウス、キーボード、ウェブカム、マイクロホン、等の周辺装置の使用。

このようなイベントは、ランタイム時またはその前にユーザへダウンロードすることができる、ダイナミック・ビジネス・ロジックに従って定義されたアクションに対するトリガとして認識される。限定はしないが、典型的なハイレベル・アクション・タイプとして下記のものが含まれる。
１．イン・およびアラウンド・ゲーム広告、
２．ハイ・スコア検出等のイン・ゲーム・コミュニティ機能、または、
３．ゲーム・イン・ア・ゲーム機能、たとえば、ゲーム環境内の非表示アイテムをユーザが探すようにダイナミックに付加する。
４．先進的なゲーム解析

基盤ゲームまたは他のアプリケーションとのソース・コード統合の必要性を回避するために、本技術を使用してソフトウエア開発および発行のコスト、複雑さおよび時間を最小限に抑え、ソフトウエア発行者が最終消費者のためになる機能を容易に付加できるようにする。また、ここに記載された方法およびシステムにより、ソース・コードの修正がもはや不可能である既に開発されたゲームの収益化および強化が可能となる。

本発明は操作を支配するビジネス・ルールがエンジン内にハード・コーディングされずに、１組のパラメータにより支配され、それは、たとえば、ゲームまたは他のソフトウエアがインストールされるクライアント・ノードへのデータ接続を介していつでもスワップすることができるフラット構成ファイル内に配布することができる。時々ビジネス・ルールを更新するこの能力はここでは「ダイナミック」ルール・インプリメンテーションと呼ばれる。言い換えれば、ソフトウエア・エグゼクタブル・ファイルを更新する必要無しに、ゲームがクライアント・ノード上にインストールされた後のさまざまな時間にイベント・ツー・アクション・マッピングを変えることができる。これはゲーム・ソフトウエアの分野で未知であり、最も予期せぬ前進とみなすことができる。

同様に、アクション（たとえば、新しいテクスチュアまたはジオメトリ）の結果使用される任意の新しいクリエティブ・コンテンツも任意の時間に変化させることができる。クリエティブ・コンテンツへの変化はユーザのコンテキスト（たとえば、１日の時間、１週間の曜日、等）または統計情報（たとえば、性、年齢、等）に従って目標とすることができる。前記した方法およびシステムを使用して、ゲーム発行者またはエージェントはゲームにより作り出されるイベント・ストリームを解釈し実行後のゲーム（ｇaｍｅ ｐｏｓｔ−ｌａｕｎｃｈ）の挙動を変更するアクションをトリガする「ビジネス・ロジック」をコントロールする構成ファイルを更新することができる。これらの構成ファイルはクライアント・アプリケーションによりダウンロードされる投稿されたサーバ・サイドとすることができる。クライアントによりダウンロードされると、前の構成からのいかなる痕跡的挙動も無しに、エンジンの全体挙動をこのように変更することができる。

前記した技術を使用して、構成ファイルを配布するのに使用されるようなサーバも異なるクライアント上で実行するいくつかのゲーム・インスタンスから抽出される情報を集約するのに使用することができる。次に、この情報をホスト・レベルで適用してコミュニティ機能を促進することができる。クライアント・エンジンは特定ゲーム内のユーザの進行に関する情報、たとえば、完了レベル、達成したハイレベル、を遠隔サーバ・データベースへ送ることができる。次に、この情報は、ＨＴＭＬウェブ・ページ、ウェブ・サーバ、統一されたデータベース技術、および既知の他のネットワーク通信方法を使用して、スコアまたはリーダ・ボード、アチーブメント・リスト、または他のポスティングへ提示することができる。

ここに記載された方法およびシステムのもう１つの有用な応用はクリェティブおよび広告コンテンツの実行後（ｐｏｓｔ−ｌａｕｎｃｈ）構成である。たとえば、どこに広告を入れるか、アトホック・トーナメントのコンテンツ、どんなアチーブメントに報酬の価値があるか、等のクリェティブ・ビジネス判断はエンドユーザへのオリジナル・ゲームの配布後まで遅らせることができる。ゲームおよび他の形の娯楽ソフトウエアは非常に複雑となることがあるため、それによりクリェティブ判断を延期または変更する機会が生成され、それらはしばしば統合時間、複雑さ、およびコストの大きなドライバである。したがって、ビジネス判断を含んでいたりそれに影響を及ぼすことがある、このようなクリェティブ判断は、広告主およびゲーマー・マーケット・タイナミクスに関するより多くの情報を知っておれば、本技術によりソフトウエアが公開されるまで遅延させることができる。ゲーム・タイトル（および、特にハイレベル「ＡＡＡ」タイトル）は開発に２年以上を要し、あるクリェティブ判断を事前に行うのは非常に困難となる。また、比較的少ない公開が広範な人気を博し、そのため多くの公開で全てのワークに先行投資することは比較的少ないユーザによりプレーされるゲームに対して多くの努力が浪費されることを意味する。このように、ここに記載された方法およびシステムは、前記した他の潜在的利益の他に、実行前（ｐｒｅ−ｌａｕｎｃｈ）時間を短縮し広告またはコミュニティ技術によりゲームを可能にする関連するコスト負担を低減することができる。

当業者ならば、下記の詳細な説明を考慮することにより、付加利点および目的を実感するだけでなく本技術および方法をより完全に理解することができる。最初に簡単に記述される添付図を参照する。

（図面の簡単な説明）
ここに記載されている技術に従って修正する前の、ゲーム・プログラムのような、ソフトウエア・エグゼクタブルおよび典型的なアプリケーション・エントリ・ポイントを示す線図である。 ここに記載されている技術に従って付加エグゼクタブル・コードにより修正されたソフトウエア・エグゼクタブルを示す線図である。 クライアント側イベント・モニタリング・エグゼクタブルすなわち「エンジン」の典型的なトップレベル機能を示す線図である。 ゲームおよびクライアント・コンポーネントに関してクライアント側イベント・モニタリング・エンジンの典型的なコンポーネントを示すブロック図である。 フック関数呼出しライフラインを示す線図である。 ゲーム・エグゼクタブルから生じるＡＰＩ関数を置換コンテンツにより置換する方法の典型的なステップを示す線図である。 ゲーム・エグゼクタブルから生じるＡＰＩ関数を置換コンテンツにより置換する方法の典型的なステップを示す線図である。 変更エンジンをゲーム・エグゼクタブルにより構成するためのランタイム統合ツールにより発生することができるような典型的なスクリーン・ショットである。 変更エンジンをゲーム・エグゼクタブルにより構成するためのランタイム統合ツールにより発生することができるような典型的なスクリーン・ショットである。 変更エンジンをゲーム・エグゼクタブルにより構成するためのランタイム統合ツールにより発生することができるような典型的なスクリーン・ショットである。 変更エンジンをゲーム・エグゼクタブルにより構成するためのランタイム統合ツールにより発生することができるような典型的なスクリーン・ショットである。 変更エンジンをゲーム・エグゼクタブルにより構成するためのランタイム統合ツールにより発生することができるような典型的なスクリーン・ショットである。 変更エンジンをゲーム・エグゼクタブルにより構成するためのランタイム統合ツールにより発生することができるような典型的なスクリーン・ショットである。 変更エンジンをゲーム・エグゼクタブルにより構成するためのランタイム統合ツールにより発生することができるような典型的なスクリーン・ショットである。 変更エンジンをゲーム・エグゼクタブルにより構成するためのランタイム統合ツールにより発生することができるような典型的なスクリーン・ショットである。 変更エンジンをゲーム・エグゼクタブルにより構成するためのランタイム統合ツールにより発生することができるような典型的なスクリーン・ショットである。 変更エンジンをゲーム・エグゼクタブルにより構成するためのランタイム統合ツールにより発生することができるような典型的なスクリーン・ショットである。 変更エンジンをゲーム・エグゼクタブルにより構成するためのランタイム統合ツールにより発生することができるような典型的なスクリーン・ショットである。 変更エンジンをゲーム・エグゼクタブルにより構成するためのランタイム統合ツールにより発生することができるような典型的なスクリーン・ショットである。 変更エンジンをゲーム・エグゼクタブルにより構成するためのランタイム統合ツールにより発生することができるような典型的なスクリーン・ショットである。 変更エンジンをゲーム・エグゼクタブルにより構成するためのランタイム統合ツールにより発生することができるような典型的なスクリーン・ショットである。 変更エンジンをゲーム・エグゼクタブルにより構成するためのランタイム統合ツールにより発生することができるような典型的なスクリーン・ショットである。 変更エンジンをゲーム・エグゼクタブルにより構成するためのランタイム統合ツールにより発生することができるような典型的なスクリーン・ショットである。

（詳細な説明）
本出願は、コンピュータ・ゲーム等の、ソフトウエア・エグゼクタブルからの出力の独立的に定義された変更に対する異なる新しい機能について記述する。主要機能はすぐ後の節で概説され、明細書の残りにより詳細に記載されている。各機能は本技術の他の機能と組み合わせることができ、１つ以上の機能を他の機能とは独立に実現することができる。本明細書はゲームまたはゲーム・エグゼクタブルを使用する操作を参照するが、ここに記載された概念および技術は他のタイプのソフトウエア・エグゼクタブルにも応用することができる。
１．スマート・ランタイム・クライアント技術
ａ．一般
ｉ．別個のプロセスとしてではなく、ゲーム・プロセス内部のエンジン・クライアント・コードの操作を促進するための終了したゲームまたは他のソフトウエア・エグゼクタブルの準備。
ｉｉ．市場普及が判るまで広告または付加ゲーム機能の開発を遅延、変化または更新する能力。
ｂ．イベント・ストリーム ここで使用されるように、「イベント・ストリーム」は、ユーザ入力に応答してゲーム・エンジンの操作により生じる任意のクライアント・アクティビティを含む、クライアント・ノード上のゲーム出力である。イベント・ストリームは下記の機能を実施するためにクライアント側変更エンジンにより処理される。
ｉ．ゲームへの入力、たとえば、マウス、キーボード、ジョイスティック、スピーチ、その他の入力の存在および使用を検出する。
ｉｉ．ゲーム・プロセスの出力、たとえば、グラフィクス・カード、サウンド・カード、またはＯＳ（ｏｐｅｒａｔｉｎｇ ｓｙｓｔｅｍ）へ向けられる出力を解析し検出する。
ｉｉｉ．イン・ゲーム・オブジェクトに対応するメモリ場所をモニタし、特定のクリエティブ・オブジェクトがインデクスできるようにテストを行う。
ｉｖ．ゲームまたは他のエグゼクタブル・プロセスからの「イベント・ストリーム」をダイナミックにダウンロードされたビジネス・ロジックへの入力として使用する。
ｖ．任意の定義されたイベントまたはイベントのロジカル（たとえば、ブール）組合せを使用してゲーム状態またはイベントを定義する。組合せ内のイベントはコンフィギュラブル・タイム・トレランス内に生じるものに限定することができる。たとえば、イベント‘Ａ’および‘Ｂ’は互いに２ｍｓ以内に生じてアクション‘Ｃ’をトリガしなければならない。
ｖｉ．ハードウェアまたはソフトウエア・バック・バッファをサンプリングしてあるグラフィカル性質を検出し、ゲーム・イベントを定義する（たとえば、レベル・ブレークス）。
ｖｉｉ．ゲーム参照値（すなわち、スコア、健康、等）の場所を見分け、その後モニタし、ビジネス・ロジックに従って更新する。
ｖｉｉｉ．ゲーム・オブジェクトが移動しているかアニメーション化されるかを検出する。
ｉｘ．オブジェクトへの仮想カメラ近接または画面上の２つのオブジェクト間の距離を検出する。
ｘ．カメラとオブジェクト間または画面上の２つのオブジェクト間の衝突を検出する。
ｘｉ．画面上のオブジェクトのサイズ、たとえば、画面面積のパーセンテージまたは専有ピクセル数を検出する。
ｘｉｉ．カメラに対するオブジェクトの視角を検出する。
ｘｉｉｉ．オブジェクトが画面上であって閉塞されていないかを検出する。
ｘｉｖ．画面内の特定のオブジェクト、テクスチュア、またはジオメトリを検出する。
ｃ．ダイナミック・ビジネス・ロジック
ｉ．クライアント技術の挙動を支配するビジネス・ロジックは、いつでもクライアント・ノードへ配布することができる、インターネットまたは他のワイドエリア・ネットワークからダウンロードするように構成された小さな構成ファイル内に収納することができる。この構成はゲーム・エンジン操作をいつでも変化できるように（少なくとも断続的な接続を想定して）使用することができる。
ｉｉ．各クライアントの特定コンテキスト、たとえば、場所、１日の時間、曜日、等に従ってダイナミック・ビジネス・ロジックを目標とする。
ｉｉｉ．ゲーム公開後のある時間まであるクリエティブまたはビジネス決定（たとえば、イン・ゲーム広告およびコミュニティ機能イネーブルメントの選出部）を遅延させる、またはゲーム公開後にこのような決定を変えてゲーマおよび広告市場デマンドへの「ぎりぎりの時間」までの集中応答を可能にして開発出費を延期する。
ｄ．イベント・ストリームに応答しかつ予め定義されたビジネス・ロジックを使用して、ゲーム実行中にクライアント側変更エンジンにより実現されるアクション。
ｉ．イン・ゲーム・オブジェクト（たとえば、テクスチュアおよびジオメトリ）に対するメモリ場所をオーバライトしてゲーム内に表示する他のクリエティブ情報内にスワップする。
ｉｉ．支持サーバへ後でアップロードするための１つ以上の追跡ファイル内でのイベントの発生を検出し記録する。
ｉｉｉ．新しいまたは既存のオブジェクトのアニメーションまたはモーションを付加または修正する。
ｉｖ．カメラからのオブジェクトの距離に基づいて音を変調する（「３Ｄ音」）、たとえば、オーディオ広告がなされる音量はゲーム・オブジェクトがクライアントのカメラ展望からどれだけ離れているかによって決まる。
ｖ．グローバル・ゲーム・コントロールの操作を変える、たとえば、「ポーズ」、「エグジット」、等。
ｖｉ．ゲーム基準値、たとえば、プレーヤ・スコア、「健康」、武器、等を変える。
ｖｉｉ．新しいテクスチュアおよびジオメトリを含む新しいオブジェクトをゲームに付加し、新しいオブジェクトでゲーム・パフォーマンスを追跡する。
ｖｉｉｉ．広告メッセージを含む情報をゲーム・グラフィクスを介して引き出す。
ｉｘ．カスタム・マウス・テクスチュアの存在を検出し、カスタム・テクスチュアが常に全てのネイティブおよび新しいグラフィカル情報を示すことを保証する。
ｅ．ホスト−レベル機能
ｉ．クライアント上のビジネス・ロジックを支配する構成ファイルをホスティングし配布する。
ｉｉ．クライアントからアップロードされた追跡ファイルを受け入れて追跡データベース内に置く。
ｉｉｉ．デモグラフィック・データ、ユーザの嗜好、推論されたユーザ特性、クライアント場所、クライアント１日の時間、または他の個人的な特性に基づいてビジネス・ロジックを個別のユーザ・レベルへ選択的に目標として設定する。
ｉｖ．分散したゲーム・クライアントから集めた情報をゲーマ消費用集中ユーザ・インターフェイス内へ集約する。
ｖ．ポイント・ベース・システムをイン・ゲーム・イベントへ割り当て、ディスプレー用集中データベース内のポイント・スコアをゲーマのコミュニティへ集約する。
ｆ．変更エンジン用構成ツール 変更エンジンを構成するためのソフトウエア・ツールが記述される。これらのツールは限定はしないが下記する事項を含むケーパビリティおよび機能を有することができる。
ｉ．ゲーム・プレー中の潜在的な広告スポットまたはゲームの直接内側の付加ジオメトリに対するアンカー・ポイントとして使用するゲーム・テクスチュアのマーキングを促進する。
ｉｉ．ビジネス・ロジック・アクションにリンクするイベントまたはイベントの組合せを定義する。
ｉｉｉ．新しいオブジェクトに対するオフセット座標を出力する使い易いユーザ・インターフェイス内の新しいジオメトリを操作する。

ここに記述された方法およびシステムはイン・ゲーム（ゲーム内）広告市場内でソリューションを実現するのに適用することができ、随意イン・ゲーム広告の有効性をレバレッジするコミュニティ・イネーブルメント戦略を使用する。たとえば、広告主主催フォームに必要事項を記入するユーザはより多くのポイント、健康クレジット、武器、アクセサリ、またはゲームプレイのコンテキストからそれらの値を引き出す他の利点を与えられる。このように得られた情報は発行者、ポータルおよび開発者に対するイン・ゲーム解析市場に役立つように使用することができる。この技術はゲームがイン・マーケットである後でコンテンツ更新を許す、たとえば、時間経過と共にイン・ゲーム音楽を最新の状態に維持するため、ゲーム・コンテンツ管理に使用することもできる。

下記のシナリオは本技術に対する典型的な応用を示す。飲料会社は、ユーザが見つけた時にある賞の資格を与える、ゲームまたはゲームのネットワークを通して飲料の隠された３次元モデル化ボトルを埋め込むことができる。この機能を可能とするために、下記のステップがとられる、
１）ゲーム環境内でその周りに飲料のモデル化ボトルを置くビジネス／クリエティブ決定を行う。これらの決定は特定のゲームまたは利用されるゲームに精通している飲料会社のマーケッティング担当者が行う。
２）ゲームの公開されたバージョン内に飲料ボトルが置かれる全てのゲーム・シーン内の「アンカー」オブジェクト（たとえば、ゲーム・テクスチュアおよび／またはジオメトリ）を識別する。これは、一般に公開した後の任意の時間を含む、ゲーム・エグゼクタブルが完全に開発された後の任意の時間に実施することができる。アンカー・オブジェクトの識別はここに記載されている構成ツールを使用して、ここでは「オペレータ」と呼ばれるホスト・レベルにおけるゲーム・アドミニストレータまたはスペシャリストが行うことができる。
３）識別されたアンカー・オブジェクトに基づいて、オペレータは構成ツールを使用して、オブジェクトが常駐する各アンカー・オブジェクトおよびオブジェクトに対する特定のオリエンテーションからオフセット（たとえば、ゲーム環境内のｘ，ｙ，ｚオフセット）を設定することができる。これはゲーム内の飲料ボトルの各配置に対して繰り返すことができる。
４）構成ツールはホスト場所において投函される構成ファイルを発生することができ、それは前述の変化を実現する。ゲームがクライアント・ノードで実行されると、変更エンジンはファイルを得てそのイベント／アクション・マッピングを更新する。構成ツールは変更エンジンとゲーム・コードを統合して統合されたクライアント・エグゼクタブルを準備するのに使用することができる。クライアント・エグゼクタブルは適切な構成ファイルを有するクライアントへ配布することができ、あるいは構成ファイルを実行時にダウンロードすることができる。
５）更新された構成ファイルを有する各クライアント上でゲームが実行され、かつアンカー・オブジェクトがエンジンにより検出されると（すなわち、「イベント」が生じる）、エンジンはさらにグラフィクスＡＰＩ呼出しを行って、アンカー・オブジェクトおよびオフセットにより定義される適切な場所内に飲料ボトルを置くことができる（すなわち、イベントに応答してアクションがとられる）。

ユーザにより操作されるゲーム・アバターがゲーム環境内でこの飲料ボトル・オブジェクトと接すると（すなわち、衝突または接触）、エンジンはこのイベントを検出して予め定義されたアクションをトリガする、たとえば、商品ディスカウント・クーポン等のユーザの情報を、授与される賞に対する適切な場所へ送る。現在の技術を使用してこれをどのように実施できるかの特定のクライアント側詳細を以下に記述する。ホスト・レベルにおける応答コンポーネントを通常技術の人による必要以上の実験を行うことなく開発し実現することができる。

（クライアント側技術）
クライアント側技術を、この節に記述されている特定のプロセスを介して、使用してビデオ・ゲームまたは他のエグゼクタブルからの出力をその実行中にダイナミック・ビジネス・ロジックへの入力として働く「イベント・ストリーム」として解析し、次に、それはゲームのユーザ入力への明白な応答を変更するあるいはエンド・ユーザには明白であったりなかったりするイン・ゲーム・アクションをトリガする。このケーパビリティはゲーム・エグゼクタブルと協力して独立に作動するクライアント側エンジンにより提供される。クライアント側エンジンの構成はゲーム・エグゼクタブルに対するソース・コードへのアクセス、またはなんらかの変更、を必要としない。クライアント側エンジンの構成はゲーム・エグゼクタブルに対するソース・コードへのアクセス、またはなんらかの変更、を必要としない。クライアント側エンジンは、クライアント装置へゲーム・エグゼクタブルを発行または配布する前に、構成ツールを使用してゲーム・エグゼクタブル・ファイルと統合することができる。

トリガー「イベント」 ここで使用されるように、「イベント」はゲームの操作によりクライアント・ノードにおいて生じるマシン状態の変化であり、それはクライアント・ノード上で独立作動するエンジンを使用して、ランタイムにおけるゲームに対する入力または出力（Ｉ／Ｏ）の一方または組合せを介して検出することができコンアィギュラブル・タイム・ウインド内で生じる。たとえば、オブジェクト等のマシン状態の変化は同じフレーム内または指定されたタイム・トレランス内（たとえば、１ｍｓ内）とされる。

ゲーム・エグゼクタブルと独立して作動するエンジンを使用するイベント検出はゲーム・エグゼクタブル自体内で生じる検出とは異なるものと理解しなければならない。この感覚で、「独立して」作動するとは、同時作動変更エンジンを含む外部プロセスへイベントの発生を伝えるゲーム・エグゼクタブル内で規定はされないことを意味する。ゲーム・エグゼクタブルに関する限り、あたかも外部変更エンジンは存在しないかのようである。逆に、イベント検出がソース・コード・レベルにおいてゲーム・コード自体と統合されると、達成するのは簡単である。ゲーム・ソース・コードと統合されると、ゲーム・エグゼクタブルはゲーム・コンテキスト内で絶対確実に生じている何かを、ＡＰＩまたは他の同等タイプの通信を介して外部エンジンに知らせる。しかしながら、ソース・コード統合は前記した理由により望ましくないまたは非現実的である。

したがって、ここに記述されたプロセスおよび技術はゲーム・エグゼクタブルの操作により生じる予め定義されたイベントの発生を独立に検出する−推測する−ケーパビリティを有する外部エンジンを提供する。これはブール関係を有することができる、アクションまたはその組合せをトリガして高度の確実性で行うことができる。たとえば、ゲームがグラフィクスＡＰＩへＡＰＩ呼出しを行い（すなわち、Ｄｉｒｅｃｔｘ^ＴＭ、ＯｐｅｎＧＬ^ＴＭ、等）後にゲーム内で使用するためにテクスチュアをグラフィクス・カード内へディスクからメモリ・バッファへロードすると、外部エンジンはこのアクションをゲームが特定のシーンを丁度表示している、または丁度表示しようとしている信頼できる信号としてゲーム・コードにより解釈することができ、したがって、予め定義されたアクションを開始する。

このケーパビリティのパワーおよび柔軟性はゲームが実行中に無数のイベントを発生する複雑なソフトウエア・プログラムであり、２つ以上の「イベント」間のブール関係がゲーム状態をより粒度を細かく記述するようにできることを考慮すると一層明白となる。これら２つの要因を考慮すると、ゲームのほとんどどんな部分も広告および／またはコミュニティ機能の挿入をトリガするためにイネーブルすることができる。たとえば、レベル・ブレークへの特定のテクスチュアのローディング（すなわち、ステータス・バーのローディング）、新しいマップ／ファイルに対するＯＳへの呼出し、レベル・ブレーク中のみ演奏される音楽に対するＯＳへの呼出し、等のごく接近して見られるいくつかの同時サブ・イベントの存在によりレベル・ブレーク・イベントを推論することができる。

検出用外部変更エンジンに利用可能な無数のイベント・タイプをより良く例示し予め定義されたアクションに対するトリガとして使用するために、以下に検出することができる典型的なイベント・タイプを記載する。
１）ゲームからグラフィクスおよびサウンドＡＰＩへのマルチメディアＡＰＩ呼出しの存在、
２）正規動作に対するランタイム時にゲームが必要とするＯＳまたは他の関数への呼出しの存在、
３）周辺装置、キーボード、ホットキー、マウス、等の使用のようなゲーム入力、
４）エンジンにより検出される１つのオブジェクトまたはオブジェクトの組合せ（テクスチュア／ジオメトリ）のゲームによる使用、
５）ゲームブーツ以来の経過時間のようなグローバル・パラメータ、
６）グラフィクス・バッファ内のあるグラフィカル性質の存在、
７）ある予め定められた値と比べた、健康、スコア、等のメモリ内に保持された任意の基準データの値（すなわち、スコア＞＝１００ｋ）、
８）たとえば、近接および衝突等のオブジェクト間の相互作用、
９）画面上のサイズ、カメラへの入射角度、画面上の持続時間または露光時間に対する最小または最大閾値を生成する前記したものの任意の組合せ等のオブジェクトに対する追跡情報、
１０）たとえば、画面上の１つ以上の場所をサンプリングしかつ予め定められたグラフィク・サンプルと比較して決定することができる画面ビデオ・バッファ内の特定エリアのコンテンツ、および、
１１）ゲーム「状態」を定義することができる複雑な関係を生成する前記いずれかの組合せ関係。
ソース・コード統合の無いゲーム・イベントの検出を可能にする技術に関する詳細は下記の「ランタイム・クライアント側技術の概要」節に記述されている。

（クライアント側変更エンジン・アクション）
ゲーム・イベントが検出されると、クライアント側エンジンは予め定義されたアクションを起こすことができる。起こすことができる種類のアクションを駆動できるビジネス・アプリケーションに制限は無いが、今日のゲーミング産業の状態が与えられた場合、これらのアクションは最も一般的に下記の事柄に関連している。
１）広告
２）スポンサーシップ
３）コミュニティ機能
４）アドホック・トーナメント生成ケーパビリティ
５）ゲームが市場に出た後でフルパッチを行うまたはソース・コードを変更することなく、発行者がゲーム機能、マップ、レベル、ルック・アンド・フィール等を変えられるようにするゲーム・コンテンツ管理システム（たとえば、ゲーム・コミュニティからのポストランチ帰還がゲームが難しすぎることであれば、発行者はこの発明を使用してゲーマーに前進ベースでより健康を与えることができる）、および、
６）将来のゲーム開発を知らせるのに使用できるまたは前の応用で記述したコンテンツ管理システムと共に使用できる報告のような、ゲームがゲーマーによりどのようにプレーされるかを報告するゲーム解析。

変更エンジンがとることができる粒度の細かいアクションのタイプは、限定はしないが、下記する事柄を含むことができる、
１）ゲームを一時停止する、
２）コマーシャル・ビデオまたはイン・ゲーム・メッセージのようなゲーム・グラフィクスを介して情報を提示する、
３）メモリ内のオブジェクト・クリエティブ情報を新しいクリエティブ情報でオーバライトする、
４）ユーザのスコアまたは健康のようなメモリ内の基準データをオーバライトする、
５）シーンに新しいオブジェクト（テクスチュア／ジオメトリ）を加える、
６）ゲームに新しいサウンドを加える、
７）基準オブジェクトへのユーザの近接に基づいてサウンドを変調する、
８）ログに追跡情報を書き込む、
９）ゲームを最小限に抑えウェブ・ブラウザを特定のＵＲＬに起動させる（たとえば、ゲーム画面上にクリック・スルー広告を挿入することにより）

下記の例はイン・ゲーム広告に関連するゲーム・ランタイム中に変更エンジンにより行うことができるアクションに関する。共通の必要なゲーム操作はグラフィクスＡＰＩ（たとえば、Ｄｉｒｅｃｔｘ^ＴＭ）への呼出しを介したメモリ内のテクスチュアの設定である。このグラフィクスＡＰＩ呼出しはイベントとすることができ、それがトリガするアクションは対応するメモリ・バッファを新しい特定広告主クリエティブでオーバライトすることである。もう１つの例はゲームに対するスコアのメモリ場所が判れば、この値をエンジンが常に読むことができ、それがある量を超えれば（イベントを定義する過剰スコアの発生）、そのユーザに対するスコアおよび一意的識別子を中央サーバへ送信することができ、それはスコアおよび関連するプレーヤ・データをゲームをプレーする皆んなが見るために「ハイスコア」エリアへ書き込むことができる。さらなる情報に対しては、図３に関して後述するオーバライト・メモリ・モジュールの検討を見てください。

変更エンジンによるパフォーマンス時にアクションはユーザにとって必ずしも明白であったり認識可能である必要がない。たとえば、アクションはゲーム発行者に対する報告目的だけのことがあり、たとえば、どれだけ多くのユーザが「イースターエッグ」（隠された）コンテンツを開くかまたはあるゲーム・オブジェクトを達成するかを追跡することである。

変更エンジン技術によりゲームがイネーブルされるプロセス
本質的に２ステージ・プロセスを使用してゲームをここに記述された技術でイネーブルすることができる。これらのステップは同時にまたは不特定の遅延を有して行うことができる。
ステージ１ 第１のステージは変更エンジンをゲーム・コードに付けることである。この技術が既存のゲーム・コードのコンテキスト内で働くために、クライアント・エンジン・コードをゲームのプロセス・コード内に取り付ける方法が必要である。図１Ａ−Ｂに示すように、ゲーム内に取り付けることにはゲーム・ソフトウエアおよび変更エンジン・コードをクライアント・ノードへ別々に配布する必要がなく、変更エンジン・コードをゲーム・エグゼクタブルの２進操作を介してゲーム・プロセスと共に実行するという利点がある。

図１Ａは、ここに記載された技術に従って修正する前の、ゲーム・プログラム等のソフトウエア・エグゼクタブルおよび典型的なアプリケーション・エントリ・ポイント・アドレス１０２を示す線図である。ソフトウエア・エグゼクタブルはエグゼクタブル・マシンコード部１０８の始まりを示すエグゼクタブル・アドレス１０２を指すポインタ１０６を含むヘッダー１０４を含んでいる。エグゼクタブル１００もデータ部１１０を含むことができる。

図１Ｂはここに記載された技術に従って付加エグゼクタブル・コード１１２により修正されたソフトウエア・エグゼクタブル１００’ を示す線図である。エグゼクタブル１００’は新しいエントリ・ポイント・コード１１８に対するアプリケーション・エントリ・ポイント１１６を指す修正されたポインタ１１４を有する。ソフトウエア・エグゼクタブル１００’は関数呼出し（すなわち、ポインタ１１４）を加えてクライアント・エンジン・コード１１２を初期化するためにゲーム・エグゼクタブル・コード１００の２進操作により修正することができる。この方法により、ゲーム・エグゼクタブル・２進ファイル１００はプログラムのエントリ・ポイントにおいて余分の機械語コード１１２を含むように自動的に更新される。オリジナル・ヘッダー１０４は最初に初期化しクライアント・エンジンＤＬＬ１１２をロードする新しいヘッダー１０４’により修正または置換される。新しいエントリ・ポイント・コード１２０は同時に実行してゲームプレー中にイベントを検出しアクションを初期化する、要するに、ゲーム・エグゼクタブルの機能を「フック」する変更エンジン１１８を初期化する。次に、エントリ・ポイント・コードはオリジナル・アドレス１０２を使用してオリジナル・ゲーム・エグゼクタブル・コード１０８を初期化する。

エグゼクタブル・機械語コード１００の変更に伴うステップは下記の事柄を含む、
１）アプリケーション・エントリ・ポイント１０２を見つける。アプリケーション・エントリ・ポイントはエグゼクタブル・コード１０８の開始アドレスである。
２）エグゼクタブル１００の端部に新しいコード部１１２を付加する。このコード部１１２はクライアント変更エンジン１１８を初期化するのに使用されるファンクション・コード１２０および変更エンジン１１８を含んでいる。変更エンジンは１つ以上の構成ファイル１２４内に入れることができるような外部データへの呼出しを含むことができる。
３）ポインタ１１４を構成することにより、アドレス１１６にある新しいコード部１２０を指すようにエグゼクタブル・エントリ・ポイント１０６を変える。
４）初期化された後で、コードがオリジナル・エントリ・ポイント１０２へジャンプするようにクライアント・エンジン１２０を構成する。
５）結合さた修正コード１００’と付加エグゼクタブル・コード１２０を結合エグゼクタブル・ファイル１２２に書き込む。随意、この結合ファイル１２２を従来技術で知られているように暗号化または「ラップ」することができる。

結合エグゼクタブル１２２を準備した後で、変更エンジン１１８により使用されるデータ・ファイル１２４を「ステップ２」により完全に記述されているように構成することができる。

クライアント・エンジン・コードをゲーム・プロセスに添付する前記した方法は、限定はしないが、さまざまな利点を提供することができる。
１．クライアント側変更エンジン・コードは配布されてゲーム・コードが詰められ、別個のプログラムをダウンロードしてユーザ・マシン上にインストールする必要がない。
２．余分なプロセスは必要がないという事実により、クライアント・エンジン・コードを識別したりファイヤウォールその他のアドウェア／スパイウェア・ブロッキング・ツールを使用してそれをブロックするのが困難になる。

ステージ２ 特定ゲーム・ビジネス・ロジックおよびクリエティブ・パラメータの定義。
一度第１ステージが完了すると、ゲームはこの技術によりイネーブルされその時だけその操作命令が必要となる−ここではダイナミック・ビジネス・ロジックと呼ばれる。このビジネス・ロジックはそれら自体をインターネットを介した迅速な送信に適合させる小型フラット・スクリプト・ファイル（たとえば、暗号化ＸＭＬファイル）内に収容することができる。これらの構成ファイルの構造および配布はこの第２ステップの目的であり、ゲームがユーザのマシンへダウンロードされた後であっても、任意の時間または多くの時間に行うことができる。これらの構成ファイルがスワップ・アウトされると（たとえば、サーバから再ダウンロードされる）、ゲームは前の構成から残っている任意の残留挙動も無く新しいルールの元で作動する。また、構成ファイルは構成または省略して、変更エンジンがデフォールト・モードで作動するようにすることができる。ある実施例では、変更エンジンがデフォールト・モードで作動している時はゲーム出力に明白な変化はない。

ダイナミック・ビジネス・ロジックを定義する マーケッティングおよびビジネス要求条件がダイナミック・ビジネス・ロジックを定義する主要なドライバとなることがある。このビジネス・ロジックをオーサリングするのに使用されるツールは、恐らく技術的リソースによる、テキスト・エディタ内での直接オーサリング／編集、から同じ出力を行う非技術的人々に対する複雑なグラフィカル・インターフェイス手段までの、多くの形式をとることができる。フォーマットが何であれ、ダイナミック・ビジネス・ロジックの定義中に行われる主機能は興味あるイベントの識別、変更エンジンにより行われる結果として生じるアクションの定義、および変更エンジンと相互操作可能な言語またはデータ・フォーマットのこれらのイベントおよびアクションの開発法典化である。ビジネス・ロジックを定義するツール内で行われる典型的なタイプのツールの非網羅的リストを以下に示す。
１．異なるオブジェクト（広告のような）により置換することができるゲーム・オブジェクト（テクスチュア、ジオメトリ・バッチのような）をピックする。このプロセスは反復することができ（時間の経過とともに変化）、異なるグラフィカル場所に対して異なって設定することができる。
２．ゲーム内の特定の状態を識別する１つ以上のゲーム・オブジェクトのマーキングを含む、イベントの定義に使用されるゲーム状態の識別。次に、１つ以上の応力アクションを特定のイベントにリンクすることができる。たとえば、オブジェクトＡ、ＢおよびＣが同時に検出されれば（イベント）、エンジンはゲームを一時停止させ（アクション１）特定場所（すなわち、ゲームの主メニュー上）内の画面上に広告オブジェクトを表示することができる（アクション２）。

非技術的ビジネスおよびクリエティブ要求条件はオペレータが提案された技術でゲームをイネーブルする前に定義する必要がある。典型的な要求条件は、限定はしないが、下記の事柄を含むことができる。
１．ゲーム環境内のダイナミック広告に対する光学的場所を識別する、
２．特定の広告キャンペーンの特定の特性を定義する、
３．ホスト場所への報告の目的で興味あるゲーム・フレー中に生じる結果およびユーザ挙動を識別する、
４．たとえば、ユーザのスコアがある値を超える時に付加コミュニティ機能をトリガしなければならないゲーム・プレー中に生じる結果およびユーザ挙動を識別する、
５．あるイベントがもたらすべき利益の量、たとえば、ダイナミックに置かれたオブジェクトが見つかったらプレーヤの健康スコアをどれだけ増すかを定義する。
より技術的かつクリエティブな決定は、限定はしないが、下記の事柄を含むことができる。
１．配置、サイズ、透明性、アニメーション、ユーザ応答ケーパビリティおよびイン・ゲーム広告テクスチュアおよびジオメトリのクリエティブ・リフレッシュ間隔を決定する、
２．ゲーム・グラフィクスの上に描かれたアラウンド・ゲーム広告テクスチュアおよびジオメトリの配置、サイズ、透明性、アニメーション、ユーザ応答ケーパビリティおよびクリエティブ・リフレッシュ間隔を決定する、
３．シーン内に書き込まれた任意の新しいオブジェクトのサイズおよび挿入されたオブジェクトが所望の外観を有することを確認するためにシーンに加えられた任意の新しいオブジェクトに対するオフセット座標（既存のオブジェクトからの）を決定する、
４．クリエティブ回転周波数や透明性のようなダイナミック広告機能を支配することができるパラメータを決定する。

イベント・ストリームを定義する同様に、ダイナミック・ビジネス・ロジックはさまざまなアクションをトリガするイベントの定義を含むことができる。それ自体または他のイベントとの結合において、システムのオペレータがトリガとして使用することができる多くの異なるタイプのイベントがある。提案されたシステムのオペレータのような典型的なイベントは、ツールがこのタスクをどのように促進できるかに関する下記の説明で検討されているように定義することができる。さらに、開発への洞察およびダイナミック・ビジネス・ロジックを構成するツールの使用が最終節「ランタイム統合ツール」において提供される。

ダイナミック・ビジネス・ロジックを定義するのに使用することができるさまざまな機能およびステップが以下に検討される。このような１つのステップはトリガ・イベントの発生を信号で知らせるマシン状態の存在を示すのに使用されるオブジェクトのマーキングとして記述することができる。このステップにおいて、オペレータは興味あるオブジェクト（たとえば、テクスチュアまたはジオメトリ）を見つけ、将来のランタイム識別のためにこれらのオブジェクトをマークする。興味あるオブジェクトは、たとえば、ランタイムに新しいクリエティブ情報で潜在的にオーバライトされるこれらのオブジェクトか、またはトリガとしてかつエンジンによりシーンに書き込まれる新しいオブジェクトに対するアンカー・ポイントとして働く基準オブジェクトとすることができる。後者に対して、オフセット座標はいくつかの異なる方法で定義することができ、１）最も適切と見える場所に関するオペレータの主観的判断によるもの、または２）多数のアンカー・オブジェクトに関する配置の決定によるものである。後者の例として、オペレータは３Ｄカー・モデルを３つの異なるオブジェクトに関してシーン内に配置できると指定することができる。第１のオブジェクトは、たとえば、地面または舗装を定義するジオメトリ・パッチとすることができる。地面上にゼロ（０）距離オフセットを設定することにより、オペレータは車がその上に浮上するようには見えないことを保証することができる。オペレータは付加アンカー・オブジェクトを識別することができ同様にオフセットしてビジネス・ゴールに従って適切に見える配置を達成する。

任意の目的に対して、オブジェクト識別はゲームがプレーされる間に実行する別個の構成アプリケーションを使用して行うことができる。構成アプリケーションは興味あるオブジェクトに対応するシーン上の場所の視覚駆動マーキングを促進するように構成することができる。ゲーム内の各グラフィカル・オブジェクト（テクスチュア、ジオメトリ・バッチ）には構成アプリケーションにより一意的ＩＤを割り当てることができる。一意的ＩＤはオブジェクト・データの全部または一部にハッシュ関数を実施して計算することができる。

ビジネス・ロジック定義ツールは、オブジェクト・タイプに応じて、特定オブジェクトのＩＤを見つけるいくつかの方法を提供する。テクスチュア・オブジェクトのケースでは、ツールはテクスチュア自体上のテクスチュア一意的ＩＤをツール・セットのオペレータに表示することができ、要求されたテクスチュアがハイライトされるまでテクスチュアの表示中を循環し、それゆえツール・セットのオペレータにより、またはターン選出モードを使用して選出することができる。ターン選出モードにおいて、オペレータには特殊カーソル、たとえば、要求されたオブジェクト上に位置決めすることができるボックスまたは他のアウトラインが設けられる。次に、ツールはカーソルの下に位置決めされたテクスチュアに対するＩＤを自動的に見つける。ＩＤを見つけることは現在のフレーム内で使用される各テクスチュアを変え、ピクセル・バッファを最も変えたテクスチュアに対するフレーム・バッファ（マーカの下のエリア）をテストして行うことができる。

オペレータはゲーム・ランタイム中に変更エンジンによりクライアント・レベルで識別できるようにあるゲーム画面をマークすることもできる。画面のこのようなマーキングを促進する１つの方法はオペレータ入力から定義ツールへのスクリーンショット（または同等のもの）を定義することである。その後、オペレータはツールを使用してゲーム内でそれを一意的に識別するこのような画面のいくつかの部分を識別することができる。これは、たとえば、オペレータが画面上のさまざまな場所で小さな（各サンプルに対して数百ピクセルなら十分）イメージサンプルを定義することができるツールを使用することである。これらのサンプルは有意義な一意的情報をキャプチャするのに十分大きく、かつランタイムに必要な参照のための情報を最小限に抑えるのに十分小さくなければならず、こうして最適変更エンジン性能を提供する。このようなツールはマークされたイメージ・ファイルを構成ファイルに書き込むことができ、あるいは、キャプチャされたイメージサンプルの、座標だけでなく、同等符号化（暗号化）を構成ファイル内に書き込むことができる。ゲーム・ランタイム中に、変更エンジンは前記した座標におけるゲームのグラフィクス出力をサンプリングされたイメージと比較して、構成可能なトレランスまで、ピクセル単位で一致が存在するかどうかを決定する。

あるゲームはそれに固有のカスタマイズされたマウス・テクスチュアを利用する。このようなカスタマイズされたマウス・テクスチュアは、イベント・ストリームから決定することができる、マウス・カーソルの場所におけるパターン・マッチングにより検出することができる。検出されると、変更エンジンはマウス・テクスチュアをレンダリングする前に任意のオーバレイされた情報（すなわち、ゲーム・グラフィクスを介して描画される変更または挿入された情報）をレンダリングすることができる。これはマウス・ポインタ・グラフィクスがエンジンによりゲーム上に描画された任意のグラフィクスの「下」へ行くようには見えないことを保証する。

トリガ・イベントを定義するもう１つのステップはゲーム・スコア、プレーヤ「健康」状態、武器状態、等の参照データに対するメモリ場所を識別することを含むことができる。参照データは論理関係に基づくイベントとしてモニタされマークされることがある。たとえば、イベントは“Ｓｃｏｒｅ＞１００ｋ”として定義することができる。変更エンジンはスコア値が格納されるメモリ・スペースを周期的にモニタし、そこに収容された番号情報を構成ツールにより定義された基準と比較することができる。

ゲーム参照データに対する適切なメモリ場所を見つける、ここに記述されている技術を使用する必要がない、ゲーム・ソース・コードへのアブセント・アクセスは反復プロセスを使用して、構成ツールを使用して実施することができる。各ステージにおいて、ツールはプロセスの完全なメモリ・スペースから開始して疑わしいメモリ・アドレスのリスト内の異なる値を検索することができる。一例はプレーヤのスコアのアドレスを見つけることである。現在のスコアは、たとえば、１０ポイントである。ここに記述された方法およびシステムはプロセスの全メモリ・スペース内の値「１０」を探し始める。結果は値「１０」を含む数百または数千の疑わしいメモリ場所のリストである。ゲームプレーが続けられプレーヤのスコアは３０となる。次に、ここに記述された方法およびシステムは前の反復において得られたメモリ場所のリスト内の値「３０」を探す。その結果、再度疑わしいメモリ場所のリストが得られるが、今回は場所数が著しく低減されている。このプロセスは最終リストが求められている唯一のメモリ場所しか含まなくなるまで続けられる。特定データ、たとえば、ゲーム・スコアに対するメモリ場所がこのように決定され、構成ファイルを介して変更エンジンを構成するのに使用することができる。

他のステップはイベントとして定義するのに関心のあるゲームからの任意の入力または出力の定義を含むことができる。これは、限定はしないが、下記の事柄のいずれかを含むことができる。
１．ユーザがキーボード上のあるキーまたはキーの組合せを押下する、
２．ゲームがＯＳにファイルを要求する、
３．ゲームがゲーム・オブジェクトの設定またはローディングを超えて関心のある任意のグラフィカル／サウンドＡＰＩ呼出しを行う、
４．たとえば、マイクロホン、カメラ、ジョイスティック、等の任意の非キーボード／マウス周辺装置の使用。

さまざまなイベントが識別された後で、オペレータは構成ツールを使用して、ブールまたはファジー・ロジックを使用するようないくつかのイベント間の関係を設定し、アクションをトリガするのに使用されるイベント組合せを定義する。たとえば、組合せイベントは多数の特定テクスチュアが画面上に同時に存在することにより定義することができる。これは、ランタイムにアクション・トリガとして目標設定することができるゲーム状態の変化を定義するのを助けることができる。オペレータはこのようなイベントのタイミング上にカラーを最適に設定することができる。たとえば、ツールは画面上のあるフレーム内にオブジェクトが現れなければならないこと、またはタイム・トレランス（たとえば、１ｍｓ以内）以内で一連のイベントが検出されなければならないことをオペレータが指定して、組合せイベントの検出を行わせるのを許す。

イベントおよび組合せイベントが定義された後で、オペレータは定義したばかりのイベントまたは組合せイベントへアクションをマッピングすることができる。一般的に、ツールはイベントＩＤおよびアクションＩＤの記録を含むリレーショナル・データベースまたはデータ・テーブル等を使用して、オペレータがそれにより１つ以上のアクションを特定のイベントまたは組合せイベントと関連付けることができるデータ構造またはインターフェイスを提供することができる。もちろん、アクションおよびアクションＩＤも定義される必要がある。典型的なアクションがどこかに定義される。いくつかのアクションは頻繁に使用されるため予め定義することができ、たとえば、下記のアクションが含まれる、
１．メモリ場所をオーバライトする（すなわち、テクスチュア情報を新しいクリエティブでオーバライトし、ユーザのスコアを増分する、等）、
２．ゲームを一時停止する、
３．マウス・テクスチュアをオーバライトする、
４．新しいグラフィクスＡＰＩ呼出しを介してシーン内に新しいオブジェクトを生成する、
５．ゲーム・プレーヤを介して情報を書き込む、または、
６．追跡ファイル内にイベントの発生をロギングする。

構成の全体プロセスはオプショナルとすることができ、そのため、特定のゲーム・タイトルはランタイム時に任意所望の時間、または永遠に変更に対してイネーブルされる必要はない。特定のタイトルがイネーブルされるまで、ゲームはユーザ経験を変えることなく正常に作動することができる。しかしながら、変更エンジンはランタイム中にまだ活性化されることがあるが、適切な構成ファイルが提供されない限りまた提供されるまでゲーム出力を変更しない。したがって、技術（たとえば、Ｑ．Ａ．）、クリエティブ・コンテンツ開発（たとえば、広告／コミュニティ機能スポッティング）およびプロジェクト管理（たとえば、関係する全てのパーティからの無数の承認）への投資はそれを正当化するのに十分な人気を特定のタイトルが得るまで遅延させることができる。

（ランタイム・クライアント側技術の概要）
クライアント側変更エンジン・コードが初期化され構成されると、それはクライアント上で作動して、エンジンにより利用される方法論に従って、関連するＡＰＩ呼出しを検出かつ「フック」する。このコンテキストにおいて、「フッキング」または「フック」するはゲーム・プロセスのメモリ・アドレス・スペース内の関数を異なる関数で置換することを意味する。ほとんどの場合、新しい関数は入力をオリジナル関数およびビジネス・ロジックへ転送して情報を処理する。予期されたゲーム挙動を維持するために、最終ステージはエンジンに対してオリジナル・フック関数を呼び出すことである。

図２はクライアント側イベント・モニタリング・エグゼクタブルすなわちエンジンの典型的なトップ・レベル機能を示す。ゲーム・コードは図の左に示す操作を行い、変更エンジン機能は右に示されている。ゲーム・プロセスはクライアント・ノードで作動するコンポーネント２０２、２０４、２０６を含んでいる。フック関数２０８は前記したコンポーネント２０２、２０６に属する関数のサブセットを含み、それは変更エンジンに対するイネーブリング構成プロセスを介して識別される。

コンポーネント２０２において、ユーザ入力はクライアント・ノードからゲーム・プロセスにより受信される。たとえば、キーボード入力、マウス入力、ジョイスティック入力、その他の入力がクライアント・ノードと電子通信している入力装置から受信される。ある入力は廃棄され、選出された入力により入力に応答するプログラム分岐を介してメモリ状態が変えられる。たとえば、ある入力が受信されるとカウンタが増分されることがあり、あるいは変数状態が一定値に設定される。入力コンポーネントとして分類されたフック関数２０３はマシン変数を増分または設定する関数、またはオペレーティング・システム関数処理入力装置とのインターフェイスとすることができる。

ユーザ入力により生じたメモリ状態の変化は、次に、ゲーム・シミュレーション・コンポーネント２０４の結果に影響を及ぼす。ゲーム・シミュレーションは計算上非常に複雑なことがあるが、一般的には、現在のゲーム状態を現わす迅速発生画面ディスプレーへ向けられる。シミュレーションは、一般的に、入力およびゲーム・スペースをシミュレートするモデル化された環境内のジオメトリック・モデルを処理する。次に、モデル化された環境はコンポーネント２０６においてレンダリングされてレンダリングされたフレームを提供する。恐らく、シミュレーション・コンポーネント２０４内に関数をフックすることもできる。しかしながら、ソース・コードの知識がなければ、これは入力および出力関数をフッキングしてマシン状態に検出可能な変化を生じるのと比べて比較的困難となる。

前記したように、シミュレーション・ロジックはフレーム・レンダリング・コンポーネント２０６の出力としてレンダリングされたグラフィクス・フレームとなる。レンダリングされたフレームはゲーム用の適用可能なグラフィクスＡＰＩを使用して表示用に出力される。これらのＡＰＩは、しばしば、発行されたベンダー標準に従って定義され、したがって、一層容易にフックされる。オーディオＡＰＩまたはオペレーティング・システムへの出力に対しても同じことがいえる。このように、フックされた関数２０８はコンポーネント２０６の出力関数も含んでいる。変更エンジン・コア２１０はＡＰＩ呼出しまたは他のフックされた関数を処理する。それは現在定義されているビジネス・ロジックに応じて、通過したデータを処理したりそのまま通すことができる。

下記のリストはクライアント側変更エンジン２１０のトップレベル関数を概説する。リストに載っているアイテムは全て下記の専用節で説明される。
ビジネス・ロジックへの入力
１）Ｉ／Ｏフィルタ、
２）クェリー・メモリおよび／またはハードウェア、
３）メモリ内のゲーム・オブジェクトを識別し解析する、
アクション
１）メモリ・バッファを新しいデータでオーバライトする、
２）新しいジオメトリを加える、
他のモジュール
１）ビジネス・ロジック
２）メディア・データベース
３）追跡データベース、および、
４）ＨＴＴＰインターフェイス。

図３はゲーム３０２およびクライアント・コンポーネント３０４に関連するクライアント側イベント・モニタリングおよび変更エンジン３００の典型的なコンポーネントを示すブロック図である。エンジンは任意適切な言語でソース・コードから編集して、エグゼクタブル・マシン・コードとして、前記したようにゲーム・コードに接続することができる。複数のモジュール３０６がビジネス・ロジックへの入力として機能する。これらのモジュールは異なるタイプの「イベント」をそれらがゲーム内に生じる時に検出する。イベントはビジネス・ロジック・レイヤへの入力として働く。イベントが生じると、それらはローカル・データ・ストア３０８にログインされ報告の目的で集中データベース３１０へアップロードされる。

Ｉ／Ｏフィルタ３１２はゲーム・イネーブルメント・プロセス中に定義されたこれらの呼出しがゲームによりなされる時にゲームからの全てのＩ／Ｏを解析して検出するように構成される。エンジンがこれらの予約された呼出しを検出すると、イベントがビジネス・ロジック・レイヤ３１４へ送られる。予約された出力呼出しの例として下記の事柄が含まれる、
１）ディスクＩ／Ｏに限定はしないが、ネットワークＩ／Ｏ、タイマおよびクロック等を含むオペレーティング・システムへの呼出し、
２）グラフィクスＡＰＩへの呼出し、および、
３）サウンドＡＰＩへの呼出し。
予約された入力呼出しの例として下記の事柄が含まれる、
１）キーボード／マウス入力、
２）ジョイスティックまたはゲーム・コントローラ、
３）オーディオ入力（たとえば、マイクロホン）、および、
４）視覚入力（たとえば、カメラからの）。

Ｉ／Ｏフィルタ・モジュール３１２はこのＩ／Ｏアクティビティの全てを解析してフィルタ・ブロック３１６で示すようにある定義されたイベントを検出するように構成することができる。見つかった任意の「イベント」をダイナミック・ビジネス・ロジック・レイヤへの入力として使用することができる。

ユーザ入力およびグラフィクス／サウンドＡＰＩのモニタリングの他に、変更エンジンはメモリ内の特定エリアへの変化もモニタすることができる。クエリ・メモリおよび／またはハードウェア・モジュール３１８は変更エンジンのこの機能的モジュールを現わす。特定のメモリ場所の変化はゲーム・ロジック内の変化を示すことがあり、ビジネス・ロジック・アルゴリズムへの入力として働く。たとえば、特定のメモリ場所はプレーヤのスコアを保持することを前もって決定することができる。モジュール３１８はプレーヤのスコアを格納するのに使用されるメモリ・エリアをモニタして、プレーヤがある量のポイントに達した時にイベントをトリガするように作動することができる。このアクションに関するさらなる詳細は前記したゲーム・コントロール・モジュール３３０に関して検討される。

変更エンジン３００は、さらに、グラフィクス・メモリがアクセスされる時はいつでもモジュール３１２、３１８および３２０に関する画像処理を行って定義されたイベントの発生を検出することができる。すなわち、エンジン３００はあるグラフィカル出力をイベントとして検出する能力を有することができる。これは、たとえば、画面上でレンダリングされる前に定められたフレームに対するイメージ・バッファをサンプリングし、定められたタイトルに対する全てのビジネスおよびクリエティブ決定がなされる時に、それがエンジン構成プロセス中にマークされた画面との一致であるかを調べて行うことができる。

全体フレームに対するグラフィクスは画像処理に対して必ずしも必要ではなく、問題とするフレームを一意的に記述する部分だけが必要である点は重要である。たとえば、レベルブレーク中に多くのゲームは予約した画面テンプレートを表示してレベル番号、恐らくはゲーム筋書きおよび背景で行われている任意のローディングの進行に関するより多くの情報、をユーザに知らせる。任意の２つのレベル間のレベルブレーク画面はしばしば互いに異なるが、通常は異なるレベルブレーク・ディスプレーにおいて一貫性を維持するまたは類似しているエレメントがある。画像処理はランタイム中にグラフィカル出力からこれらの一貫性を維持する領域だけを選出して解析しレベルブレークを検出するように構成することができる。サンプルされた領域が全体画面エリアよりも遥かに小さい（たとえば、＜１０％）ことがある、一貫性を維持するグラフィクス領域の少数の（たとえば、３−５）画面マップだけをサンプリングすることにより、ここに記述された方法およびシステムはシステム性能への影響を最小限に抑えることができる。

画面グラフィクス・データのサンプリングおよび比較は解像度の変化を考慮しなければならない。ゲームは典型的に異なる画面およびウィンド解像度で実行することがあるため、システムはゲーム解像度の変化による伸長および圧縮効果を考慮してサンプルされたエリアを比較することができる。これはゲーム準備プロセス中にキャプチャされたオリジナル・サンプルを取り出し、ゲームが実行している現在の画面解像度へそれらをリサイジングし（バイリニア・フィルタリング等の標準画像処理アルゴリズムを使用して）、現在サンプルされたエリアをオリジナル・サンプルと比較して行うことができる。オリジナル・サンプルはビジネス・ロジックをコントロールするファイルと共にランタイムにゲームへダイナミックにダウンロードされる。

サンプル間の比較は標準画像処理アルゴリズムを使用して行うことができる。たとえば、サンプルされたデータおよびオリジナル・サンプル・データ内の各ピクセルは３Ｄ色空間へ変換され、次に、サンプルされたエリアと測定されたオリジナル・サンプル・データ間の色空間偏差が測定される。偏差が十分小さければ（たとえば、ある閾値よりも小さい）、ピクセルはマッチングしていると見なすことができる。十分なマッチング・ピクセルがあれば（たとえば、全てのサンプルされたエリア内のマッチング・ピクセルの数があるコンフィギュラブル閾値よりも上である）、サンプルされたエリアはマッチと見なすことができる。

変更エンジンは、さらに、メモリ３３２内のゲーム・オブジェクトを識別し解析するように構成されたモジュール３２０を含むことができる。このモジュールは全オブジェクト・データに対するメモリ・バッファにアクセスし、画像処理を含む、多数のプロセスをコンテンツ上で実行して情報からイベントを検出する。オブジェクト・データ上でプロセスを実行して推論することができる情報のタイプは、限定はしないが、下記の番号付けした項に記述されているものを含む。

ビジネス・ロジックへ送るべきイベントをトリガするオブジェクトの予め定義されたリストと相互参照するランタイムの各オブジェクトに対する一意的ＩＤを発生する。巡回冗長コードまたは同様なアルゴリズム（ＭＤ５のような）をメモリ内のオブジェクトを構成する一部または全てのデータ上に適用して一意的識別子を計算することができる。たとえば、ゲームテクスチュアに対して、このアルゴリズムをテクスチュア・イメージ・データ（ピクセル）上に適用することができる。３Ｄジオメトリ・オブジェクトのケースでは、このアルゴリズムをオブジェクトの頂点およびインデクス・バッファ上に適用することができる。次に、アルゴリズムからの出力は構成中にイベントに対するマーカとしてマークされているランタイム時のオブジェクトを識別するのに使用できるキーとして使用することができる。
（２）モデル化されたゲーム・スペース内のオブジェクト場所間の定量的距離を計算する。各ジオメトリ・バッチに対して、好ましい計算方法は３Ｄスペース内のバッチの場所を見つけることである。これは３Ｄスペース内でジオメトリを位置決めまたは回転させるのに使用されるモデル・マトリクスを検索して（たとえば、ＤｉｒｅｃｔＸ ＩＤ３ＤＸＥｆｆｅｃｔ：：ＳｅｔＭａｔｒｉｘ関数呼出しをフッキングして）、またはジオメトリ・バッチを表示するのに使用される頂点シェーダから情報を検索して行うことができる。３Ｄスペース内の所望のオブジェクトの場所が決定されると、各オブジェクトのバウンディング・ボックスの中心間距離、または他の興味ある距離を計算するのは容易である。３Ｄスペース内の特定のオブジェクトとカメラの現在の場所（ユーザ視点）間の距離も計算することができる。多くのゲームにおいて、カメラの場所は３Ｄ環境内のプレーヤの場所を示す。たとえば、ゲームのメイン・キャラクタ（それはゲーム・ストーリ−すなわち、車、人間、外国人、等に基づいていくつかの形をとることができる）とゲーム内の「ピックアップ」３Ｄオブジェクト（ゲームに対してネイティブであるかまたはここに記述された方法およびシステムにより加えられる）間のこの推定距離を知ることにより、ビジネス・ロジックはゲーム状態数を評価することができる。たとえば、このようなアイテムは下記の事柄を含むことができる。
（３）衝突検出−これによりここに記述された方法およびシステムは２つ以上のオブジェクトが世界で衝突するか検出することができる。この情報はいくつかの応用を有することができる。たとえば、ゲーム・キャラクタと挿入されたオブジェクト間の衝突が検出されると、エンジンは挿入されたオブジェクトがピックアップされたか選出されたか考え、それに基づいてアクションをとることができる。たとえば、エンジンはメモリ内のユーザのスコアまたは健康情報を更新してユーザへの利益を生じることができる。同様に、ユーザが車を看板に衝突させると、エンジンはゲーム・プレーヤに見えるアクションをとる、またはこの相互作用をその看板に対する広告主により見られる報告書に単純に記録する。
（４）近接検出 これによりエンジンは、実際に衝突することなく、ユーザがマークされたオブジェクトに「近い」時を検出することができる。たとえば、ユーザのゲーム・アバターが予め定義されたイン・ゲーム・モデル化された距離（すなわち、＜ゲーム・モデル内５フィート）内で動く公開される映画に対する静止看板に近づくと、アクションをとることができる。１つのこのようなアクションは隣接オブジェクトを新しいクリエティブでリフレッシュすることであり、たとえば、その対応するサウンド音量が看板からのユーザのアバターの看板からの距離の関数として変調されるビデオ移動トレーラである。
（５）オブジェクト・モーション／アニメーション 画面上のその動きに関して決定するためにオブジェクトの動きまたは外観の変化を検出する。
（６）可視オブジェクトに対する視角を計算する 所望オブジェクトの場所およびバウンシング・ボックスが突き止められると、ユーザが挿入された広告のような可視オブジェクト上にあるコンテンツを見る視角を決定することができる。視角を決定するために、広告の正面を表す表面から表面方法線を計算することができる。次に、法線およびカメラが直面している方向を表すベクトル間の角度を決定することができる。この角度はイン・ゲーム広告を見るユーザの機会を推定するのに有用である。カメラから情報の表示までの角度が非常に高い入射角度であれば、ユーザはデータを吸収するのが困難となることがあり、したがって、広告主はこのような露呈に対して低料金を課せられることがある。
（７）オクルージョン確認 グラフィクスＡＰＩへ送られる全てのオブジェクトが画面上にレンダリングされるわけではない。どのオブジェクトをユーザが見る機会があるかを検出する能力は、特に、広告を表示するのに重要である。このような検出はグラフィクス・ハードウェア・オクルージョン・クエリ呼出し（ＤｉｒｅｃｔＸＩＤｉｒｅｃｔ３ＤＱｕｅｒｙ９）、または他の適切な方法を使用してオクルージョン・カリング（ｏｃｃｌｕｓｉｏｎ ｃｕｌｌｉｎｇ）により行うことができる。
（８）オブジェクト・サイズ 画面上のオブジェクトのサイズはさまざまな理由から重要となることがある。たとえば、ディスプレー広告と共に、プライシング・モデルはしばしばユーザへのオブジェクトのサイズの関数である。実世界における看板広告と同様に、メッセージが大きいほど広告主にとってより価値があり、そのスペースのオーナーにより多く課金することができる。本システムは任意適切な方法を使用してオブジェクトのサイズを決定することができ、たとえば、
（ａ）グラフィクス・カードにオクルージョン・クエリを使用して特定のオブジェクトが画面上で占める正確なピクセル数を引き出す、および／または
（ｂ）オブジェクトのバウンシング・ボックスおよび３Ｄスペース内の変換／回転マトリクスを使用して、オブジェクトを２Ｄ画面へカメラ投影マトリクスを使用して投影し、次に、投影されたオブジェクトが画面上で占有する面積を計算する。

前記したイベントの単一発生、または他のイベントと組み合わせたその発生によりビジネス・ロジック・モジュール３１４により支配される適切なアクションとなることがある。要するに、変更エンジンはゲーム実行中にキャプチャされたイベント・ストリームをゲーム準備中に構成されたダイナミック・ビジネス・ロジック内に定義されたアクション・ツー・イベント・マッピングと比較してアクションが適切である時を、予め定義されたロジックに従って、独立して決定するように構成することができる。アクションが適切であるという決定に応答して、変更エンジンはオーディオ、ビジュアルまたはキャラクタ・データを予め定められたメモリ場所に書き込んで、ゲーム・エンジンにより出力されるものだけ、またはそれに加えて、変更されるそのディスプレー画面またはオーディオ出力装置からクライアントが出力を提供するようにする。変更エンジンはゲーム・エンジンにより前に書き込まれたメモリ場所内のデータをオーバライトする、または異なる場所にデータを書き込んで付加出力を作り出す、たとえば、ゲーム・エンジンだけではプレーされなかったであろうサウンド・クリックをプレーする。

アクション Ｉ／Ｏフィルタ３１２、クエリ・メモリ／ハードウェア３１８および識別オブジェクト・モジュール３２０により入力が集められた後で、それらはビジネス・ロジック・レイヤ３１４へ送られそこでルールの予め定義されたセットとマッチングされる。イベントが検出されると、ビジネス・ロジック・モジュール３１４は後続するモジュールの１つを呼び出してゲームを操作しているクライアント上でアクションを行うことができる。オペレータはイベントへアクションを割り当てる必要がなく、こうしてデファクト報告オンリー・イベントも可能である。

変更エンジンはオーバライティング・メモリにより予め識別されているサイトの補足、変化または強化情報を更新するために集められた情報を使用するオーバライト・メモリ・モジュール３２２を含むこともできる。代わりに、またはさらに、本システムは予めアドレス指定されていない場所に新しいコンテンツを補強または挿入することもできる。テクスチュアおよびジオメトリ・オブジェクトは定められたオブジェクトに対するクリエティブ情報を格納するバッファをオーバライトすることによりゲーム内で置き換えられることがある。変更エンジンは全てのＡＰＩ呼出しをインターセプトすることがあるため、ランタイムに書き込まれたテクスチュア／ジオメトリ情報に対するメモリ場所を決定することができる。構成ステップ中に置換のために構成されるクリエティブ・オブジェクトに対して、対応するバッファ情報をオブジェクトがレンダリングされる前に置換することができる。置換データは、たとえば、広告クリエティブ・オブジェクトまたはあるコミュニティ機能に対応することができる。

また、ゲーム・ロジックまたは「筋書き」パラメータが同様に変更エンジンを使用してコントロールまたは変化することができる。たとえば、ランタイムにメモリへ書き込まれただけの値であるゲームのスコアは増加または減少することがあり、あるいは同様に適切なメモリ場所をオーバライトすることにより余分の寿命またはより多くの健康をプレーヤに与えることができる。このプロセスを使用して見つけられかつ変更されまたはオーバライトされることがある可能なゲーム・パラメータのリストは、たとえば、下記の事柄を含むことができる。
１．ゲーム・スコア、
２．健康、
３．パワー、
４．速度、
５．アイテム在庫、
６．スペル、
７．寿命、または
８．トラクション（レーシング・ゲームに対する）

変更エンジン３００は、さらに、メモリ内に存在する情報をオーバライトするのとは反対に、主コンテンツへ新しい情報を加えるモジュール３２４を含んでいる。新しいオブジェクトを加える典型的な方法が以下に記述される。

必要ならば、グラフィクスＡＰＩに適切な呼出しを送ることにより新しいジオメトリをゲームに加えることができる。任意の新しいジオメトリはできるだけシームレスにシーン内にフィットするように設計しなければならない。新しいコンテンツのフィッティングはゲーム準備ツールに関連する方法により、一意的参照オブジェクトを見つけクライアント・ディスプレー画面上に表示される時に任意の新しいジオメトリを適切に見せる（たとえば、適切な展望で）シーン内の参照オブジェクトの位置に関してオフセットを設定して達成することができる。ここに記述された方法およびシステムは、好ましくは、新しいオブジェクトが望まれない場所で現れないように一意的テクスチュアを識別する。

代わりに、またはさらに、モジュール３２４は、ゲームがアニメートしないオブジェクトを含むシーン内の任意のオブジェクト、既存および付加オブジェクト共、をアニメートするように作動することができる。これは頂点座標内の増分変化により、または３Ｄスペース内のオブジェクトを位置決めおよび方向付けするのに使用される変換マトリクスを変えて達成することができる。ライティングおよびシェーディングは同様にこれらのオブジェクトの頂点および面法線を操作してコントロールすることができる。

変更エンジンは、さらに、ゲーム・プレイ中にゲーム・グラフィクスを介してグラフィカル情報を描画するモジュールを含むことができる。これはゲームまたは他のエグゼクタブルの主コンテンツに新しいオブジェクトまたは情報を加えるのに使用することができる。ゲーム・グラフィクスを介して情報を描画することは新しいオブジェクトがゲームに加えられるのとほぼ同じ方法で、すなわち、グラフィクスＡＰＩになされる新しい呼出しを介して達成することができる。しかしながら、ゲーム・プレイの上のゲーム・グラフィクスを介して書き込まれた情報は特定のルールセットに従ってコントロールすることができる。たとえば、ゲーム内でイベントを検出することができ（入力モジュール内で検出された１つの入力または入力の組合せを介して）それはコマーシャル・ブレーク・ビデオを３０秒間プレイするようにトリガする。

ゲーム上にデータを描画する特殊なケースはマウス・テクスチュアである。システム・マウスを使用せずゲーム内のマウス・ポインタに対する新しいテクスチュアを定義するゲームに対して、クライアントはこの呼出しをトラップしてマウス・ポインタがいつもゲームに加えられた任意の新しい情報よりも上であることを保証する。好ましい実施例では、これはここに記述された方法を使用してマウス・テクスチュアを検出し、マウス・テクスチュアをレンダリングする前に全てのオーバレイをレンダリングして行われる。正規のケースでは（マウス・テクスチュア検出が無い）オーバレイはＩＤｉｒｅｃｔ３ＤＤｅｖｉｃｅ９：：Ｐｒｅｓｅｎｔ（ビデオ・バッファ・フリッピング）または他のグラフィクスＡＰＩと同等の方法でレンダリングすることができる。これはマウス・ポインタが画面上に描画された任意の付加イメージの下にレンダリングされないことを保証する。

付加オーディオ出力はゲーム・エグゼクタブルから生じるオーディオ出力の代わり、またはそれに加わる出力であることもある。オーディオＡＰＩ（たとえば、Ｄｉｒｅｃｔ Ｓｏｕｎｄ）をフッキングすることにより、ここに記述された方法およびシステムはゲーム・エグゼクタブルから生じる全てのサウンド・ストリームの開始をトラップすることができる。次に、このシステムはサウンド・ストリームをプレイし続けるかあるいは前記した方法を使用して異なるものと置換するかを選択することができる。また、ゲームの任意のポイントにおいて現在プレイしているサウンド・ストリームは、その音量を０に変えるかまたはそれらを全て一緒に停止することにより、ミュートすることができ、それにはもう１つのサウンド・ストリームのプレイが続くことができる。さらに、このシステムは付加ストリーム内にミックスすることができ、たとえば、ゲーム・アバターがオブジェクトをピックアップする時に音響効果を加える。

オーディオを加えるケーパビリティはいくつかの可能な応用を有し、たとえば、（ａ）販売に利用可能な曲を演奏する（たとえば、ｉＴｕｎｅｓ）、（ｂ）ビデオ広告オブジェクトまでのユーザの距離の関数として変調するビデオ広告と共にサウンドを再生する等の、他のオブジェクト・データにサウンド情報をリンクする、（ｃ）たとえば、毎週Ｂｉｌｌｂｏａｒｄ Ｔｏｐ ４０曲しか演奏しない、変化する市場嗜好に基づいてその場でゲーム音楽を変える。

変更エンジンは、さらに、ゲーム一時停止等のユーザのゲーム経験を変更するイン・ゲーム・イベントへの非グラフィカル応答をコントロールするゲーム・コントロール・モジュール３３０を含んでいる。非グラフィカル、非オーディオ・アクションは、限定はしないが、（ａ）ゲームを最小限に抑えウェブ・ブラウザ等の異なるプロセスを開始する、（ｂ）ゲームを一時停止してコマーシャル・ブレーク広告（ストリーミング・ビデオ）、リーダー・ボード、チャット・ルーム、オンライン・ショップ等のコミュニティ機能、等の情報をユーザに表示する、（ｃ）スコア用特定メモリ・エリア等をビジネス・ロジックにより決定される特定値に変える、ことができる。を含んでいる。

ゲームの一時停止はフック関数からのリターンを遅らせて達成することができる。グラフィカルＡＰＩはゲーム・グラフィクスをグラフィクス・カードへリフレッシュするためにフレーム・バイ・フレーム・ベースで呼び出される必要がある関数を特徴的に含んでいる。たとえば、ＤｉｒｅｃｔＸグラフィクスＡＰＩはＰｒｅｓｅｎｔ（）関数を使用してゲーム・グラフィクスをリフレッシュしディスプレーを更新する。これはフレーム・バイ・フレーム・ベースで行われる。Ｐｒｅｓｅｎｔ（）関数上にフックを置くことによりクライアント・エンジンはＰｒｅｓｅｎｔ（）関数からのリターンを遅らせてゲームを効率的に一時停止することができる。殆どのビジネス・ロジック・コードをＰｒｅｓｅｎｔ関数、または他のグラフィクＡＰＩ内の類似関数、のコンテキスト内で実行することができる。

変更エンジン３００は、ゲームがブーツする時に接続されたネットワーク・ホスト３３４からその作動しているロジックをビジネス・ロジック・モジュール３１４がダイナミックに得るように構成することができる。ランタイム時にゲーム内へシームレスに挿入されることがある任意のメディア・ファイルをゲームのブートアップ後に同様にダウンロードすることができる。

ビジネス・ロジックは特定のゲームに対してグローバルに設定することができ、あるいはユーザ（たとえば、登録データ）により提供されるまたはユーザのＨＴＴＰヘッダー情報（たとえば、ＩＰアドレスに基づいたジオ・ターゲティング）から推論されるデータから、ユーザに関する既知の情報に基づいて個別に目標とすることができる。ターゲティングの例は、今日のウェブ・ブラウザにおけるオンライン広告サービスでは常識である、地理的場所に基づいて目標とされる広告を促進することである。

ここに記述された方法およびシステムの実施例では、ビジネス・ロジック・レイヤ３１４はターゲティング基準の同じセットと同じ仮想「在庫」場所内に記録された潜在的な競合広告の中から最も好ましいコンテンツを選択するようにイネーブルされる。これは完了、引き渡されずに残っている在庫の量、収益最大化、反応率、または他の要因をキャンペーンする時間を考慮し、任意の定められた時間ベースで予め定められた基準を最も満たす広告を選出する１つ以上のアルゴリズムにより達成することができる。

状態検出 ここに記述された方法およびシステムを使用して、たとえば、テクスチュア、ジオメトリ・バッチ、画像処理出力、プレーされるオーディオ・データ等の検出された入力の一つまたは組合せの存在に基づいてゲームをさまざまな「状態」に分割することができる。これらの入力は粒度状態定義を提供するためにイベントの任意のロジカル組合せをサポートすることができる。たとえば、テクスチュアは多くの場所におけるゲーム・プレー全体にわたって何回も生じることがある。ゲーム内のそのいくつかのコンテキストの１つにおけるこのようなテクスチュアはゲームを一時停止する場所を完全に定義しビデオ広告を示すことができる。複数であるため、このテクスチュアだけではゲーム・プレー内の定義されたポイントを一意的に記述するのに十分ではないことがある。ゲームのこの領域をマークするために、変更エンジンによるこの複数のテクスチュアの検出を１つ以上の他のタイプのオブジェクト・イベントとロジカルに組み合わせて、ロジカル「ＡＮＤ」ステートメントを使用する等により、組合せイベントを定義することができる。さらに、２つ以上のイベントの組合せはゲーム全体を通して一意的に選出して望まれないスペース内でビデオ広告をトリガするのを防止しなければならない。ここに記述された方法およびシステムにはオブジェクトの一意的組合せを見つけるのを助けるアドミニストレータ・ツールを設けるのが最適である。

変更エンジンは、さらに、ビジネス・プロセスをサポートするバックエンド・サーバ３１０、３３４との通信をコントロールするように構成された通信コントロール・モジュール３３６を含んでいる。通信は、好ましくは、双方向、ハッシュで暗号化されている。任意の通信プロトコルはこのようにサポートすることができ（ＨＴＴＰＳ、ＵＤＰ等）図３に示すＨＴＴＰに限定する必要はない。

変更エンジンはその挙動を支配する全てのビジネス・ロジックをホスト３３４からダウンロードすることができる。エンジン３００は、たとえば、ゲーム・ブーツから初めていつでもこの情報をクライアント・ノードへダウンロードすることができる。したがって、変更エンジンにより使用されるビジネス・ロジックは初期構成および特定のクライアント上へのインストール後の任意所望の時間に変えることができる。変更エンジンは適切な機能、たとえば、ビデオ、サードパーティ広告サーバへのインターネット・ウェブ・アドレス、スタティック・クリエティブ、および他のコンテンツに必要な任意のファイルの場所を得ることもできる。

ゲームがプレーされると、短期メモリ内またはディスク上に常駐することがある、追跡データベース３０８に実質的にローカルに記録される追跡イベントをトリガすることができるさまざまなイベントおよびイン・ゲーム・アクションがある。ビジネス・ロジック・モジュールは全ての検出されたイベントおよび１つ以上のホスト場所へ周期的にアップロードされるローカル・データベース３０８内での任意の媒体使用を記録するように構成することができる。これらは請求書作成および追跡の目的に使用され標準暗号化方法論を利用するが、当業者ならば他の方法も理解できる。追跡ログは、報告の目的で（たとえば、請求書作成）、生または要約形式でサーバ３１０へ定期的にアップロードすることができる。サーバ３１０は多数のクライアントから受信した追跡情報を受信し集計することができる。

変更エンジンは、さらに、新しいダイナミック媒体ファイルのマッピングのためのローカル・キャンペーン情報データベース３３８およびこれらの媒体ファイルがどのようにゲーム・コンテキスト内で使用されるかを支配するメタデータを含むことができる。たとえば、システムは定義された場所および／または時間内のクライアントに対する定義されたオブジェクト上（たとえば、「オブジェクトｉｄ１２３」上）でテクスチュア・ファイルを使用する命令を有するテクスチュア・ファイル「ｇｒｅｅｎ．ｊｐｇ」をダウンロードすることができる。たとえば、テクスチュアの使用はカリフォルニア・クライアントに対するＩＰアドレス特性を有するクライアントに限定することができ、プライム時間だけとすることができる。

変更エンジン３００は構成ツールを介したそれとの組合せを介してゲーム・コンテキスト内で実行するように構成することができる。この意味で、つまり、エンド・ユーザとクライアント・オペレーティング・システムに関する限り、変更エンジンはゲーム自体から見分けがつかないことがある。したがって、アドウェアやスパイウェアとは異なり、その存在またはクライアント上での動作はブロッキング・アプリケーションにより検出または妨害されることはない。変更エンジンを実行するのにエンド・ユーザは別個のクライアント・コードを必要とせず、そのためそれは軽量でクライアント・ノード上でシームレスである。同時に、ゲーム開発者には、変更エンジンは別個の無関係なアプリケーションである。主要なソフトウエア・エグゼクタブル（たとえば、ゲーム）の開発者はそれ故本質的にさらには完全に変更エンジンの相互作用や動作の促進には関心が無い。それ故、ここに記述された方法およびシステムは新しい予期せぬ利点を提供し、エンド・ユーザおよび開発者の両方を変更エンジンに対する別々の懸念から開放する。

一般的に、Ｉ／Ｏ呼出しはさまざまな異なるソースから生じることは明らかである。図４は、一般的に図３に示すアーキテクチュアに従って、呼出しをグラフィカルＡＰＩにフックして戻すのに使用することができるような典型的なフック関数呼出し生命線４００を示す。説明に役立つ例はＤｉｒｅｃｔＸ^ＴＭ Ｐｒｅｓｅｎｔ（）関数に基づいており、それは装置が所有するバック・バッファのシーケンス内の次のバッファのコンテンツを有する表示を与える。ゲーム・エグゼクタブル４０２はｐｒｅｓｅｎｔ（ｘ）関数呼出しを発行し、それはフッキングＡＰＩ関数４０４の操作を介してＩ／Ｏフィルタにより検出される。フッキングＡＰＩ関数は元々意図するグラフィクスＡＰＩ４０６に対するサロゲートとして呼出しを受信する。フッキングＡＰＩ関数はビジネス・ロジック・レイヤ４０８を呼び出し、それは、もしあれば、どんなアクションを呼出しのコンテンツおよび予め定義されたビジネス・ロジックに基づいて実施するかを決定することができる。任意の指示されたアクションが実施され、コントロールはフッキングＡＰＩ関数４０４へ渡し戻される。アクションはメモリ・オーバライト・アクションを介して呼出しのコンテンツを変更することを含む。フッキングＡＰＩ関数４０４はコントロールをグラフィクＡＰＩ４０６へ渡し戻し、それは呼出しを正規に処理する。したがって、コントロールはゲーム・エグゼクタブル４０２へ返される。

さらなる詳細が図５Ａに提供され、それはフッキング方法５００により実施される典型的なステップを示すフロー図である。第１のステップ５０２は、オリジナル関数５０８の第１のバイト５０６が格納されるコード場所を指すメモリ・アドレス５０４を有する、フックＡＰＩ関数をゲームが呼び出す時に開始される。この呼出しが検出されると、変更システムは第１のバイト５０６と置換する関数ポインタ５１０を選出する。前記したように、関数ポインタ５１０の選出は変更エンジンのビジネス・ロジック・モジュールにより実施されるイベント・ツー・アクション・マッピングによりコントロールされる。オリジナル呼出しの検出はトリガリング・イベントとすることができ、またはいくつかの他のイベントも生じて組合せイベントを構成することもできる。図５Ａに示す特定のアドレスは単なる代表例にすぎず、任意のメモリ・アドレスを検出または使用することができる。

第２のステップ５１２において、オリジナル関数内の第１のバイト５０６は新しい関数のアドレス５１０へジャンプするように変えられ、それはゲーム機能を変更する。置換される情報５０６は一時的スペース内に格納される。このように、関数が実行されると、それは置換関数の場所へジャンプする。次に何が起こるかは、置換関数の実行が終了した後でオリジナル関数コード５０８を実行することが望ましいまたは必要かどうかによって決まる。オリジナル関数を実行することが必要または望ましくなければ、置換関数はオリジナル関数を呼び出すことなく完了するまで単純に実行される。置換関数の後でオリジナル関数を実行することが望ましければ、置換関数は終了した後でオリジナル関数を呼び出す。

したがって、第２のケースでは、置換（新しい）関数の呼出しが完了した後で、ステップ５１４に示すように、オリジナル関数５０８の第１のバイト５０６が格納される。前記したステップは図５Ｂによりコンパクトに図示されている。もちろん、置換アクションが完全であるほど新しい関数ロジックがステップ５１６において実行される。随意、ビジネス・ロジックにより指定されれば、ステップ５１８に示すように、次にオリジナル関数を実行することができる。

（技術のいくつかのビジネス応用）
本技術は今日のゲーミング市場で直面する問題を解決して新しい機会を提供する。オンライン・ゲーム発行はしばしば熾烈な競争によりマークされる。多くのゲームが互いに非常に似ている機構および筋書きを有するだけでなく、発行者（またはポータルのような類似の他のアグリゲータ）さえも全く同じゲームを有し、そのユーザにそのライバルとして提供する。したがって、発行者はゲーム・プレーの収益を上げる代替方法を見つける動機を与えられることがある。これらの代替方法はゲーマに売り込む製品およびサービス（すなわち、イン・ゲーム商品販売）またはユーザにより資金供給されないもの（すなわち、広告）とすることができる。

本技術は、驚くべきことにゲーム開発者を伴うことなく、このような代替収益方法を可能とする。これは付加価値コミュニティ機能およびさもなくば閉じられていることがある代替収益オプションへの内容物を開く。これは確かにバック・カタログ・ゲームを有するケースであり、開発者へのアクセスは不可能なことがあり、より一般的でもある。

現在の技術を使用して、広告の配置および定義、スポンサーシップまたはコミュニティ機能を、たとえそれがダウンロードされエンド・ユーザによりプレーされた後であっても、その時の任意のビジネス・ニーズに従っていつでもいかなるゲームに対しても変えることができる。これにより多くの望ましい結果、たとえば、ユーザのマシンに既にダウンロードされているゲームに対するリアルタイムの広告の定義および展開が可能になる。このような変更はビジネス・ロジック・モジュールを介してエンジンの挙動をコントロールするゲーム・ブーツにおいてサーバからダウンロードされるキャンペーン情報を変えてダイナミックに実現することができる。変化または異なるキャンペーンは、ビジネス・ニーズが生じる時に、所望により頻繁に実施することができる。このケーパビリティによりこの技術を使用する組織がゲーマの好みおよび広告主のその日の要求に従って特定のゲーム内にどの広告機能を展開するかのビジネス決定を行うことができる。これは、数か月さらには１年もかかることがある、ゲーム開発中にこれらの機能を需要に先立って定義するのに勝る非常な利点である。言うまでもないが、遥かに前もって最善のビジネス決定を行うのは非常に困難である。

さらに、複雑なコード・レベル統合を必要とする従来の方法論に比べて本技術はお金と時間を節約することができる。これはゲーム開発者がこれらの機能をゲーム内に実現することを発行者が要求することを意味する。発行者がプログラマにプロジェクト要求条件を教育し、コード開発プロジェクトを管理しかつ開発したコードの品質保証を行うことは、特にコミュニケーション・バリアが高いことがあるより低廉な海外現場でコード開発がアウトソーシングされる場合に、複雑で費用がかかることが実証されている。したがって、開発者の関与を必要とせずにこれらの機能が可能になれば、ゲームに対するこれらの機能を市場において最適化し、それらをゲーマに対してできるだけ面白くしあるいは広告主にとってできるだけ価値のあるものとする柔軟性が与えられるだけでなく、お金と時間を著しく節約することができる。

本技術のもう１つの利点は特定のユーザについて既知の任意数のデータ・ポイントによりビジネス・ロジックをカスタマイズする能力である。今日バナー広告がインターネット上で目標とされる方法（地理、日時、等を介して）と同様に、ユーザのコンテンツに応じてゲーム公開後にビジネス・ロジックを変えることができる。これは、ゲームがプレーされる時にユーザによりダウンロードされるビジネス・ロジックを収容するファイルを単純に変更するだけで個別のユーザ・レベルまで下げて最適化される構成に対するケーパビリティをたとえ提供しても、ゲームのコンテンツを定められたユーザに対してできるだけ適切なものとするのを助けることができる。たとえば、仏国でプレーされるゲームはブジョーがスポンサである「５０ｋポイント」と呼ばれるアチーブメントを有することができ、恐らくはゲーマが日常的にスコアをより高くすることができる米国では、アチーブメント・バーをより高く「１００ｋポイント」とすることができる。この米国向けアチーブメントは仏国とは異なる、または同じ広告主がスポンサとなることができる。

本技術はコミュニティ・ビルディング機能に対するアドホック定義も可能にする。オンライン・ゲーム発行者はしばしばユーザ獲得および維持は挑戦的であることを知る。これを混合すると同じゲームがしばしば、さまざまなオンラインおよびオフライン・オプションを含む、さまざまなチャネルを介して配布されることがある。この文書に記述されている技術は発行者その他にいつでも公開されたゲームに機能を付加して、自分等の提供をオンラインおよびオフライン競争から区別してタイトルへの投資をより効率的に最適化する能力を提供する。

本技術により提供される機能のいくつかの実例は役に立つかもしれない。発行者は、たとえば、自分等のゲームをユーザにとってより楽しくするために自分等のユーザに提供されるアチーブメントを最適化することができる。このようなアチーブメントは、（ａ）ＯＳへの呼出しをフッキングしてあるレベルに達し任意の定められたレベルに対応するデータをロードする、（ｂ）イースタ・エグが見つかる時だけ表示する一意的テクスチュアを追跡するか、またはエンジンにオブジェクト全体をそれ自体に加えさせることによりある解錠可能な「イースタ・エグ」を見つける、（ｃ）スコアに対応するメモリ内の場所を見つけてその数値をモニタすることにより特点層を達成する、または（ｄ）もう１つのより直接的なモダン化形式を加えるためにやはり広告主がスポンサとなることができるアドホック・トーナメントまたはゲーム・イン・ア・ゲーム機能のような付加機能を加える、等のゲーム・コンテキスト内のさまざまな事柄を含むことができる。

ここで提案される技術は発行者に２つのステップ・プロセスを与えることができる。
１）クライアント・エンジン・ファイルを有するゲームをイネーブルし市場に流通する前に実行可能なオリジナル・ゲームを変更することによりその起動を可能にする。
２）ビジネス・ニーズに従って（広告挿入注文、アチーブメントの追加要望、等）エンジニアではないオペレータがルール−ベース・ツールを使用して定められたタイトルに追加するように注意する正確な機能を定義することができる。これらのツールによりユーザは地理ごとに異なる機能、曜日、一日の時間、または定められたユーザについて知ることができる任意他の情報を、必要ではないが必要に応じて、定義することができる。これらのルールが定義されると、ビジネス・ロジックおよび任意のクリエティブ・ファイルの場所を収容するダウンロード可能なデータベースが準備され、割り当てられていることがある任意のターゲティングに従って展開される。

クライアント・エンジンは、一度市場で、ゲーム・プレーに関する基本的情報を中央サーバ・ファームへ報告し戻すことができ、それにより発行者は一意的ユーザ数、ゲーム・セッション数および総プレー時間に関して自分等のゲームがどのように使用されているかを理解することができる。本技術を使用して、あるユーザがこの技術によりイネーブルされたゲームのネットワーク両端間で生じていることがある全てのアチーブメントの中央データベースを有することができる。各アチーブメントは、ユーザがコミュニティ内の他の人々はどんなアチーブメントに達しているかを知ることができかつ／またはこれらの予約されたアチーブメントを得るのにある形式のクレジットを集めることができるように格納することができる。これらのポイントは単純に権利を自慢するのに使用することができ、またはある固有の値を有するある形式のロヤルティ・プログラムとして使用されることもある。さらなる機会はアドホック生成、最高スコアを得るまたは最も短い期間内にレベルをビートするような既存のゲーム・プレー・メカニクス周りのダイナミック・トーナメントを含んでいる。これらのトーナメントもスポンサになることがある。また、３Ｄオブジェクトをゲーム・プレー内のどこにでも追加できる能力を有するため、エンジンはスカベンジャ・ハント機能を生成する目的でダイナミック・アイテムを埋め込むことができる。一度見つかると、ユーザはこれらのアイテムを介して報酬を受けるかより多くの使用ポイントを獲得することができる。一般的に、本技術はマーケッテイング、発行、およびコンピュータ・ゲームの使用を変換する可能性の豊富な配列（ｒｉｃｈ ａｒｒａｙ）を開く。

ランタイム統合（ＲＴＩ）ツール
ランタイム統合ツールは未熟練オペレータが、ゲームのコードを実際に変える必要なしに、ビデオまたはオーバレイ等のオブジェクトをゲーム中に迅速かつ容易にインプリメントすることができるようにするために提供することができる。統合ツールは変更エンジンを構成する必要がある全てのステップを実施し、それを統合された組合せエグゼクタブル内のゲーム・エグゼクタブルと統合することができる。また、このツールはビジネス・ロジック・ファイルへの更新を構成するオペレータをアシストすることができる。この節は適切なツールの典型的な操作について記述する。

図６Ａはランタイム統合ツールに対する入門（すなわち、ホーム）ウィンドウ６００の典型的なスクリーンショットを示す。ウィンドウはメニュー・バー６０２、ツール・バー６０４、プロジェクト・エクスプローラ６０６、タブバー６０８およびメインパネル６１０を提供する。図６Ｂは典型的なツール・バー６０４の詳細図を示す。ツール・バーは下記の典型的なアイコンを含んでいる。
Ａ．Ｎｅｗ Ｐｒｏｊｅｃｔ ６１２−新しいプロジェクトを生成する。
Ｂ．Ｏｐｅｎ Ｐｒｏｊｅｃｔ ６１４−既存のプロジェクトを開く。
Ｃ．Ｓａｖｅ Ｐｒｏｊｅｃｔ ６１６−プロジェクトをセーブする。
Ｄ．Ｓａｖｅ Ｐｒｏｊｅｃｔ ａｓ．．．６１８−プロジェクトを新しい名称でセーブする。
Ｅ．Ｄｅｌｅｔｅ ６２０−プロジェクトを削除する。
Ｆ．Ｌａｕｎｃｈ ６２２−選出されたランチ・モードを使用してゲームを起動する。
Ｇ．Ｓｔｏｐ ｇａｍｅ ６２４−ゲーム・プレーを停止する。
Ｈ．Ｃｌｅａｎ ｇａｍｅ ６２６−ゲームをクリーンなオリジナル非注入状態へ戻す。
Ｉ．Ｏｐｅｎ ｔｅｘｔｕｒｅ ｃｏｎｔｒｏｌｌｅｒ ６２８。

図７はビジネス・ロジックを配布するまたはクライアント・ノードからの追跡情報を受信するホスト・サーバによりゲームのコンプライアンス・テストおよび登録を行うツールにより表示される典型的なウィンドウ７００を示す。このウィンドウは新しいプロジェクト・アイコン６１２を使用して新しいプロジェクトを開くことに応答して、またはメニュー・バー６０２を使用してウィンドウを要求することにより提供することができる。

画面７００の目的はその中へ統合機能（ここでは「ラップ」機能と呼ばれる）がそのコードを注入するエグゼクタブル・ゲーム・ファイルの選出をイネーブルすることである。殆どのゲームにはゲームをロードする１つのエグゼクタブル・ファイルしかない。しかしながら、いくつかのゲームは２つのエグゼクタブルを有することができ、第１のエグゼクタブルはリアル・エグゼクタブルを呼び出す目的を有し、それがゲームをロードする。いずれのケースでもシーンにより適切なエグゼクタブルの選出ができる。ゲーム・エグゼクタブルの選出後、オペレータはランタイム・プロジェクト・ファイルをセーブして「Ｎｅｘｔ」を選出すべきパスを選出する。

図８はコンプライアンス・テストに対して構成されるウィンドウ８００の典型的なスクリーン・ショットを示す。選出されたゲーム・エグゼクタブルが統合ツールとコンパチブルであることが判っておれば、このステップは不要である。本技術のさまざまなインプリメンテーションは全てのゲームにおいて適切に作動はしないことがあり、そのためこの画面は選出されたゲームが技術インプリメンテーションとコンパチブルであるかどうかを決定する能力をオペレータに提供する。コンプライアンス・テストを開始するために、オペレータは第１のオプションを選択し「Ｎｅｘｔ」をクリックする。統合ツールはゲームを起動させテスト・ビデオ広告およびアニメーション化されたオーバレイを表示する。広告が正しく表示されれば、ゲームは技術とコンパチブルであると仮定するのが安全である。広告が歪んでいるか、あるいは全然示されなければ、ゲームはコンパチブルではない。ゲームがコンプライアンス・テストに失敗するいくつかの理由がある。たとえば、ゲーム・エグゼクタブルは暗号化またはそれ以外の保護をされたり、既に変更エンジンと統合されていることがある。それにより、恐らくコンプライアンス・テストは迅速に終結する。もう１つの共通エラーは間違ったエグゼクタブルを選出するために生じることがあり、その場合ゲームはいかなる追加挿入コンテンツも表示することなくコンプライアンス・テスト中は正しく実行される。いくつかのＡＰＩはコンパチブルではないことがある、たとえば、いくつかのＤｉｒｅｃｔｘバージョンは現在のインプリメンテーションにおいてコンプライアンス・テストをパスしない。一度ゲームがコンパチビリティ・テストにパスすると、オペレータはオプションを選出することによりこれを表示しゲームを登録する準備が完了する。

図９は統合ツールの登録画面９００に対する典型的なスクリーン・ショットを示す。登録はゲームを統合されたエグゼクタブルとして変更エンジンにより公開するかどうかを決める前に、オペレータが統合ツールをテストできるようにするオプションとすることができる。その場合、「Ｒｅｇｉｓｔｅｒ Ｇａｍｅ」チェック・ボックスはチェックされないことがありオペレータが「Ｎｅｘｔ」をクリックすることがある。ゲームが登録される時は、オペレータはユーザ名およびパスワードを提供し、それはホスト・オペレータにより決定されることがある。さらに、オペレータはこの画面において一意的なゲーム名を提供する。「Ｎｅｘｔ」をクリックすることによりツールはこの情報をホスト・サーバに伝え、それはゲームをそのデータベース内に登録する。

次のステップは統合されたゲーム／変更エンジンが使用するデジタル権利管理（ＤＲＭ）保護タイプの統合プロセスを通知することである。図１０に示すように、これは選出画面１０００を使用して行うことができる。画面１０００はさまざまな異なるＤＲＭスキームまたはＤＲＭ無しに対する選択を示す。オペレータは適切な選択を選出し、選択が完了すると「Ｎｅｘｔ」をクリックする。次に、プロジェクトが初期化されオペレータは所望によりその構成を進めることができる。さまざまな構成選択が以下に例示されている。

図１１は、プロジェクト生成手順から来た、一般的なゲーム情報を含む典型的なウィンドウ１１００のスクリーン・ショットを示す。このセクション内のほとんどのフィールドはこの画面から変えられない。これらのフィールドは、ゲーム名（Ｇａｍｅ Ｎａｍｅ）（ゲームを登録する時にオペレータにより入力される）、ゲームＩＤ（Ｇａｍｅ Ｉｄ）（登録プロセス中にサーバから受信される）、オリジナル・エグゼクタブル（Ｏｒｉｇｉｎａｌ Ｅｘｅｃｕｔａｂｌｅ）（統合ツールにより注入される前のオリジナル・ゲーム・エグゼクタブル）、ランチャー・エグゼクタブル（Ｌａｕｎｃｈｅｒ Ｅｘｅｃｕｔａｂｌｅ）（統合後にゲームを起動させるのに使用されるエグゼクタブル・ファイル、それは変更エンジンを含んでいる）、ゲーム・フォルダ（Ｇａｍｅ Ｆｏｌｄｅｒ）（フォルダはゲーム・ファイルを含んでおり、それはオペレータにより変えられる）、ＤＲＭ Ｔｙｐｅ（統合プロセス中の早期に選出される）、グラフィクスＡＰＩ（Ｇｒａｐｈｉｃｓ ＡＰＩ）（ゲームが使用するグラフィクスＡＰＩのタイプ）、サウンドＡＰＩ（Ｓｏｕｎｄ ＡＰＩ）（ゲームが使用するサウンドＡＰＩのタイプ）を含むことができる。

画面１１００はいくつかのゲームが正しく実行するのに必要なさまざまな技術的パラメータを主として設定するのにも使用することができる。１つのパラメータはＵＲＬランチ上のゲームを最小限に抑えるかどうかである。「真」であれば、これはクリエティブをクリック・オンする時にゲームを最小限に抑え、それにはＵＲＬが添付されている。ＵＲＬがクリックされる時にゲーム・ウィンドウが最小限に抑えられなければ、いくつかのゲームはクラッシュすることがあり、このオプションは「真」である必要がある。もう１つのパラメータはＵＲＬクリックの後待機するか否かとすることができる。いくつかのゲームはそれらのウィンドウが最小限に抑えられる時に実行し続ける。このオプションはプレーヤがクリエティブをクリック・オンする時にそれらが実行し続けるのを防止する。もう１つのパラメータはコマーシャル・ブレークにおいてゲーム・ウィンドウ手順を無視するかどうかとすることができる。ＡＬＴ＋ＴＡＢをクリックする、あるいはビデオ・クリエティブをクリック・オンすることによりゲーム・ウィンドウが最小限に抑える時にいくつかのゲームはクラッシュすることがある。このオプションの値が「真」であれば、これらのゲームはクラッシュしない。しかしながら、フルスクリーン・モードでゲームをプレーしこのオプションが使用される間にＡＬＴ＋ＴＡＢを押す時は、ゲーム・ウィンドウはデスクトップまで最小限に抑えられることはない。したがって、それらのウィンドウが最小限に抑えられる時にクラッシュするゲームでしかこのオプションを使用しないことが勧められる。もう１つのパラメータはマクロメディアＦｌａｓｈ要求条件を定義することである。一部のプレーヤにはＦｌａｓｈ Ｐｌａｙｅｒのより古いバージョンしか無く、それによりコマーシャル・ビデオのプレー中にゲームはクラッシュまたはフリーズすることがある。この問題を防止するために、オペレータはビデオ広告を表示するためにクライアントが持つべきＦｌａｓｈプレーヤの最小バージョンを定義することができる。たとえば、プレーヤがより古いバージョンを有する場合、ビデオ・コマーシャルは表示されない。

画面１１００はｊｕｓｔ−ｉｎ−ｔｉｍｅパラメータを設定するのにも使用することができ、それはクライアント上の変更エンジンを作動させるビジネス・ルールを変えるためのダウンロード可能な構成ファイルの使用を意味する。「Ｕｓｅ Ｊｕｓｔ ｉｎ Ｔｉｍｅ」の選出によりＪＩＴオプションの使用が可能となる。「ＪＩＴ Ｕｐｄａｔｅ Ｔｉｍｅｏｕｔ」の選出により、オペレータはビジネス・ロジック・ファイルの新しいバージョンがあるかどうか決定するためにサーバをチェックする時に、クライアントがＪＩＴプロセス中にサーバとのその接続を放棄する前にどれだけ多くのアイドル時間が過ぎるかを定義することができる。

画面１１００は作業モード・パラメータを設定するのに使用することもでき、それはゲームを実行する方法を定義する。たとえば、編集モードはゲームをプロファイルＤＦＥｎｇｉｎｅ．ｄｌｌで実行する。このモードを使用してクリエティブ・ストラテジーを定義かつインプリメントすることができ、それはランタイム・モードにおいてディセーブルされるスキッピング・ビデオ・コマーシャル等の多くの機能をイネーブルするためである。公開モードは正規のＤＦＥｎｇｉｎｅ．ｄｌｌを使用してゲームを実行する。このモードを使用して、ゲームが一般に公開される時に、広告オブジェクトがどのように現れ挙動するかを見ることができる。オリジナル・モードはＲＴＩエンジン無しでゲームを実行する。このモードはデバッギングに使用して、ＲＴＩエンジンがエラーに対して責任があるかあるいはそれがオリジナル・ゲーム内でも生じるかを調べることを勧める。Ｆｏｒｃｅウィンドウ・モードはたとえこのようなオプションがゲームのランタイム・オプション内で利用不能であっても、ゲームを強制的にウィンドウ・モードで実行する。このオプションはゲーム・ウィンドウおよびテクスチュア・コントローラ・ツールの両方を表示するテクスチュア・キャプチャー・プロセス中に特に有用である。

画面１１００は異なる広告オブジェクトの外観をコントロールする広告外観パラメータを設定するのにも使用される。オーバレイ・フレームを使用して、デフォールトが「フレーム無し」である、オーバレイ広告オブジェクトに対するフレームを定義することができる。さまざまな他のディスプレー・パラメータを広告またはビデオに対するフレームの外観をコントロールするように設定することができる。図１２はフレーム・パラメータを設定する典型的な画面１２００を示す。

いくつかのゲームは異なるチャネルを介して配布され、ＲＴＩツールはオペレータが各チャネルに対して異なるキャンペーンを定義できるようにする。図１３はこれらのチャネルを定義する典型的なウィンドウ１３００を示す。Ａｒｍａｄｉｌｌｏラッパーはゲームのチャネルを定義するために環境変数を変える。このプロパティによりオペレータはＲＴＩエンジンに対するこのチャネルを定義することができる。「Ａｄｄ Ｒｕｌｅ」ボタンを選出してチャネルの名称を書き込み、コマーシャルを示すか否かを決定するためにこのチャネルからの値を使用する、ＲＴＩエンジンおよび／または異なるビジネス・ロジック・ファイルの更新を担当するサーバへこのキーが送られるかどうかを選択することができる。ターゲティング・ルールを使用して異なるゲーム・チャネルを定義することができ、それは変更エンジン・ファイル内へハード・コーディングされる。

異なるパラメータを使用してＲＴＩクライアントおよびクライアント更新サーバ間の通信を管理することができる。Ｍａｓｔｅｒ Ｓｅｒｖｅｒ ＵＲＬは、ビジネス・ロジック・ファイルのクリエティブまたはより新しいバージョン等の、必要な全ての情報をクライアントがそれからダウンロードするサーバを識別する。Ｃａｍｐａｉｎ Ｕｐｄａｔｅ ＩｎｔｅｒｖａｌパラメータはＲＴＩクライアントがサーバを呼び出す間隔（分）をオペレータが定義できるようにする。デフォールト値は−１であり、それはＲＴＩクライアントがゲーム・セッション内で一度サーバにコンタクトすることを意味する。Ａｄ Ｉｍｐｒｅｓｓｉｏｎ Ｓａｖｅ Ｉｎｔｅｒｖａｌは追跡データをプレーヤのハードドライブに保存する前に過ぎる分数をオペレータが定義できるようにする。Ａｄ Ｉｍｐｒｅｓｓｉｏｎ Ｒｅｐｏｒｔｉｎｇ Ｉｎｔｅｒｖａｌは追跡データをサーバへ送る前に過ぎる分数をオペレータが定義できるようにする。Ｓｈｕｔｄｏｗｎ Ｎｅｔｗｏｒｋ Ｔｉｍｅｏｕｔは、接続試行を終結する前に、サーバに接続できるようにすることなく、過ぎた分数をオペレータが定義できるようにする。

このツールはオペレータが異なるアクションに対するキーを定義できるようにもする。次に、オペレータはキーの組合せ、たとえば、Ｓｈｉｆｔ＋Ｗ、を定義することができ、それはアクションをトリガする。

マウス位置検出パラメータはオペレータが画面上のマウス位置を検出できるようにする。これは、カーソルがその上にある時にオーバレイをハイライティングする等の、「マウス・オーバ」オプションをオペレータが使用したい時に有用である。「Ｘ−オフセット」および「Ｙ−オフセット」パラメータはゲーム内のカーソルの位置を決定し、それがカーソル・テクスチュアの一部であることを確認するのに使用される。「Ｉｎｖｅｒｔ Ｙ−Ａｘｉｓ」はゲーム・カーソルが実のカーソルに対して反転される場合に使用される。オペレータはこれを使用してマウスおよびカーソルが一緒に移動することを確認することができる。

ＲＴＩツールは異なるゲーム状態トリガリング・イベントを定義するプロセスをイネーブルすることができる。状態は同じクリエティブ・ストラテジーを共有するイン・ゲーム・ポイント（画面、ゲーム・レベル等）のセットとすることができる。これを単純化するために、各プロジェクトには当初予め定義された下記の状態を提供することができる。
ＧａｍｅＢｅｇｉｎ−ゲームの第１のフレームがゲーム・エンジンによりレンダリングされる時にアクティブとなる状態。この状態はプリゲーム・コマーシャル・ブレークを表示するのに最も使用される。
ＧａｍｅＥｎｄ−プレーヤがゲームを去る時にアクティブとなる状態。それはポストロール・コマーシャル・ブレークを表示するのに使用される。
Ｉｄｌｅ−これはデフォールト状態であり、他の状態がイナクティブである時にアクティブとなる。
この状態はオペレータがコマーシャルをゲーム中に常に現れるようにしたい時に有用である。

オペレータはＴｅｘｔｕｒｅ ＤｅｔｅｃｔｉｏｎまたはＳａｍｐｌｅ Ｄｅｔｅｄｃｔｉｏｎを使用して「Ｔａｉｌｏｒ Ｍａｄｅ」を定義することができる。

テクスチュア検出および抽出のメイン・ツールはテクスチュア・コントローラである。オペレータはゲームのウィンドウおよびテクスチュア・コントローラ・ウィンドウの両方を見られる状態でゲームを実行することができる。オペレータはゲームをウィンドウ・モードで実行することにより、あるいは、一方がゲームを示し他方はテクスチュア・コントローラ・ウィンドウを示す、２つのモニタを使用してこれを行うことができる。図１４はゲーム・ウィンドウ１４０２およびテクスチュア・コントローラ・ウィンドウ１４０４を含む典型的なスクリーン・ショット１４００を示す。

次に、さらなるゲーム・プレーによりオペレータは広告オブジェクトをインプリメントしたい画面に達することができる。このポイントにおいて、オペレータは「Ｃａｐｔｕｒｅ」ボタンを押すことができゲーム・テクスチュア・コントローラは画面内の全ての利用可能なテクスチュアをキャプチュアする。図１４に示すように、この例ではゲーム・テクスチュア・コントローラはこの画面内で４つの異なるテクスチュアを見つけている。テクスチュアを検出した後で、オペレータは状態を定義するのに使用されるテクスチュアを選出することができる。ゲーム・テクスチュア・コントローラはオペレータが、所望のテクスチュアの「Ｍａｒｋ Ｔｅｘｔｕｒｅ」チェックボックスをクリックすることにより、各テクスチュアが画面内でどの役割を演じるのかを理解するのを助ける。たとえば、テクスチュア番号３がマークされると、ＲＴＩエンジンはメイン・メニュー内の全てのテキストを青で塗り、それはゲーム・テクスチュア・コントローラがこのテクスチュアに割り当てた色である。状態を定義するためにどのテクスチュアを使用するかを決定した後で、オペレータはテクスチュアを単に左クリックして「Ｅｘｔｒａｃｔ」ボタンをクリックすることができる。

全ての必要なテクスチュアを抽出した後で、オペレータは新しい状態を定義することができる。オペレータはプロジェクト・エクスプローラ内の「Ｇａｍｅ Ｓｔａｔｅ」フォルダを右クリックし「Ｎｅｗ Ｇａｍｅ Ｓｔａｔｅ」をクリックすることによりこのプロセスを開始することができる。図１５はその時現れることがある典型的なウィンドウ１５００の一部を示す。オペレータは状態のデフォールト名を有意なものに変えることができる。たとえば、オペレータがメイン・メモリにしか現れない状態を定義したければ、それは「Ｍａｉｎ Ｍｅｎｕ」と命名することができる。このウィンドウは２つの重要なフィールド、検出スコアおよび最大検出カウントを示し、つぎにそれについて説明する。

状態が定義された後で、オペレータは状態検出ルールを定義することができる。オペレータはプロジェクト・エクスプローラ内の状態を右クリックしＮｅｗ Ｄｅｔｅｃｔｉｏｎ Ｒｕｌｅを選択してこれらのルールを定義するためのウィンドウを開くことができる。オペレータは「Ｄｅｔｅｃｔｉｏｎ Ｏｂｊｅｃｔ」コンボ ボックスを使用して検出ルールに使用したいテクスチュアを選択することができる。その後、オペレータは下記の事柄を定義することができる、（ａ）Ｍａｔｃｈ Ｓｃｏｒｅ、特定の検出ルールによりスコアに加えられる量であり、スコアに達すると状態はアクティブである、（ｂ）Ｃｏｎｓｔｒａｉｎｔ、特定の検出ルールのＭａｔｃｈ Ｓｃｏｒｅがゲーム状態の全体のＤｅｔｅｃｔｉｏｎ Ｓｃｏｒｅに加えられるために満たす必要がある、（ｃ）Ｅｘａｃｔｌｙ、テクスチュアの既存のインスタンスがＡｐｐｌｙ Ｃｏｕｎｔ内に定義されたものと正確に一致しなければならない数、（ｄ）Ａｎｙ、テクスチュアの少なくとも１つのインスタンスが存在する限り制約は満たされることを意味する、（ｅ）Ｎｏｎｅ、テクスチュアが存在しない間だけ制約は満たされることを意味する、（ｆ）Ａｐｐｌｙ Ｃｏｕｎｔ、そこから抽出された画面内でテクスチュアが使用される回数。

オペレータがルールを沢山加えるほど、状態検出は一層正確になる。テクスチュア検出ルールの定義を終えた後で、オペレータはＤｅｔｅｃｔｉｏｎ ＳｃｏｒｅおよびＭａｘ検出カウント・フィールドを更新することができる。各検出ルールがＭａｔｃｈ Ｓｃｏｒｅを有する。検出スコアに達すると、状態は検出されたと見なされることがある。たとえば、オペレータが４つのテクスチュア検出ルールを有する場合、各々のＭａｔｃｈ Ｓｃｏｒｅは１に等しくオペレータはＤｅｔｅｃｔｉｏｎ Ｓｃｏｒｅ値を４に設定し、これは全てのルールが一致する場合だけ状態は検出されたと見なされることを意味する。さらなる例として、オペレータが４つのテクスチュア検出ルールを有する場合、各々のＭａｔｃｈ Ｓｃｏｒｅは１に等しくオペレータはＤｅｔｅｃｔｉｏｎ Ｓｃｏｒｅ値を３に設定し、これは少なくとも３つのルールが一致する場合だけ状態は検出されたと見なされることを意味する。

Ｍａｘ Ｄｅｔｅｃｔｉｏｎ Ｃｏｕｎｔプロパティはどれだけ多くの回数検出された状態が現れるかを定義することができる。デフォールト値は「ｕｎｌｉｍｉｔｅｄ」であり、それは十分な状態テクスチュア検出ルールが一致すれば、状態は常に現れることを意味する。しかしながら、オペレータはしばしば状態が限定された回数しか現れないことを好むことがある。たとえば、メイン・メニュー画面内に１回しか現れないプリ・ゲーム・ビデオを生成したい時に、オペレータはそのＭａｘ Ｄｅｔｅｃｔｉｏｎ Ｃｏｕｎｔが１である状態を生成することができる。

オペレータが状態を定義した後で、ゲームをテストして状態が正しく検出されるかを調べることができる。オペレータはゲームをＲＴＩツールから起動させて状態がアクティブでなければならない画面へ行くことができる。状態がアクティブであれば、画面の上部レベルにキャプション「Ｄｅｔｅｃｔｅｄ ｓｔａｔｅ：＜Ｔｈｅ ｓｔａｔｅ’ｓ ｎａｍｅ＞」が現れることがある。その例を図１６、画面１６００に示す。

テクスチュア検出が有効でない時、たとえば、ゲームが直接描画技術を使用するまたはｄｉｒｅｃｔｘ ７またはそれ以下を使用する時に、サンプル検出を使用することができる。たとえば、サンプル検出を使用する時に予め定義された画面サンプルが現れる時を検出することができる。サンプル・グループを生成するために、オペレータはＲＴＩツール内からゲームをプレーして関連する画面のスクリーン・ショットをとることができる。スクリーン・ショットが取られた後で、オペレータはＲＴＩツールを使用してスクリーン・サンプルを定義することができる。図１７Ａ−Ｂはこのプロセス内の異なる時間における典型的なウィンドウを示す。たとえば、オペレータはサンプル・グループを右クリックしてＮｅｗＳｃｒｅｅｎ Ｓａｍｐｌｅを選択することができる。次に、オペレータは画面上にボックスをドラグして関連するパラメータ（Ｔｏｐ、ＬｅｆｔおよびＲｉｇｈｔ）を選択されたサンプルに自動的に加えることができる。サンプルを定義した後で、オペレータは下記のフィールドに記入することができる。
（１）Ｕｐｄａｔｅ ＤＴ、エンジンが画面内のサンプルの検出を試みる前に過ぎる時間の量を表す値、秒または他の単位。
（２）Ｍｉｎ Ｍａｔｃｈ Ｔｉｍｅ、エンジンがどれだけ長くゲーム画面をスクリーン・ショット・サンプルと比較するかを決定するのに使用される値、秒または他の単位。
（３）Ｍｉｎ Ｍａｔｃｈ Ｐｅｒｃｅｎｔａｇｅ、ゲーム画面および画面サンプル間でエンジンにより行われる比較の精度を決定するのに使用される値。オペレータが意図していなかった場所で状態が検出される場合にはより高いパーセンテージを使用することができる。

全てのサンプルをグループに加え終わると、オペレータはその検出に対するサンプル・グループを使用する状態を定義することができる。このプロセスは新しい状態を定義するのに使用されるデータを除いてテクスチュア検出を使用する時の状態定義プロセスに類似している。

異なるゲーム状態およびそれらの検出ルールを定義した後で、広告オブジェクトまたは他のクリエティブ・オブジェクトを加えることができる。ＲＴＩエンジンによりオペレータは３つのタイプの広告オブジェクト、Ｏｖｅｒｌａｙｓ、ＶｉｄｅｏｓおよびＴｅｘｔｕｒｅｓを加えることができる。

Ｏｖｅｒｌａｙｓ（オーバーレイ）は画面上に表示されるフローティング広告である。ＲＴＩアプリケーションはフローティング広告を準備し完了した広告をシステム内に統合するためのさまざまな編集およびプロダクション・ツールを提供することができる。特定の広告配置に割り当てられたキャンペーンが無ければ、ディスプレーに対してデフォールト・クリエティブを指定することができる。

Ｖｉｄｅｏｓ（ビデオ）はさまざまなゲーム・ブレーク中に表示することができる。ビデオ広告オブジェクトを加えるために、オペレータはプロジェクト・ツリー内の「Ｖｉｄｅｏ Ｂｒｅａｋ Ａｄｓ」フォルダーを右クリックして「Ｎｅｗ Ｖｉｄｅｏ Ｂｒｅａｋ」を選択することができる。ＲＴＩツールはビデオ・プロパティおよびゲーム・グラフィクスとの統合を定義するためのインターフェイスを提供することもできる。また、オペレータはビデオまたはオーバレイのプレーをトリガするイベントを識別する。

ＲＴＩにより提供される最も強力な機能の１つはゲーム・テクスチュアまたはその一部を広告配置に変える能力である。テクスチュア変化を使用する２つの利点がある。第１の利点はゲームの当初書かれた部分に似ているように広告を構成できることである。第２の利点は変化したイン・ゲーム・テクスチュアを状態検出に使用することによりオペレータが状態を定義する必要がなくなり、誤った状態定義ゆえにゲームの誤ったセクションに広告配置が現れる危険性が除去されることである。

テクスチュア広告はテクスチュア編集ツールを使用して生成することができる。テクスチュアを生成した後で、下記のフィールドを指定することによりそれを変更エンジン内に統合することができる。
（１）Ｔａｒｇｅｔ Ｔｅｘｔｕｒｅ、広告オブジェクトにより、全部または一部、置換されるイン・ゲーム・テクスチュアに対する識別子、
（２）Ｎａｍｅ 広告オブジェクトに対して割り当てられた名称、
（３）Ｄｅｓｃｒｉｐｔｉｏｎ （オプショナル）広告オブジェクトのテクスチュアルな記述、
（４）Ｕｓｅ Ｄｅｆａｕｌｔ Ｃｒｅａｔｉｖｅ 広告オブジェクトにキャンペーンが割り当てられていない時にデフォールト・クリエティブ（テクスチュア）が表示されるか否かを決定するのに使用される変数。
（５）Ｄｅｆａｕｌｔ Ｃｒｅａｔｉｖｅ デフォールト・クリエティブ（テクスチュア）に対する識別子。

他のデータも表示または指定することができ、限定はしないが、デフォールト・クリエティブおよび広告オブジェクトに対する他の特性およびアドレスが含まれる。他のタイプの広告と同様に、オペレータは広告テクスチュア配置に割り当てられたキャンペーンが無い時に表示されるデフォールト・テクスチュアの指定を許可されることがある。図１８ＡはＲＴＩツールに対する典型的なスクリーンショット内のデフォールト・テクスチュア１８００を示す。図１８Ｂはデフォールト・テクスチュアと置換することができる典型的な広告テクスチュア１８０２を示す。インターフェイスは、さらに、置換されるテクスチュアの一部、テクスチュア・オリエンテーション、およびゲーム・プレー中に広告テクスチュアの外観をコントロールする他のパラメータを指定することができる。

クリエティブ戦略のインプリメンテーションを終えた後で、オペレータはゲーム・ビルドを開始することができる。ＲＴＩツールを使用して、オペレータはその中にこれらのファイルがエクスポートされるフォルダーを選択することができる。「エクスポート」または類似のコマンドをメニューからを選出することによりＲＴＩツールは、変更エンジンに対するＤＬＬファイル、ビジネス・ロジック構成ファイル、および組合せゲーム・エグゼクタブル／変更エンジン・エグゼクタブルを含む統合ゲーム／変更エンジンをここに記載されている方法を使用して発生することができる。

ゲーム・エグゼクタブルに対する変更エンジンの好ましい実施例について記述してきたが、当業者ならばシステム内のある利点が達成されていることが自明であろう。本技術の範囲および精神から逸脱することなくさまざまな修正、適応、および代替実施例が考えられることを評価しなければならない。たとえば、コンピュータ・ゲーム・エグゼクタブルを有する変更エンジンの使用を例示してきたが、前記した新しい概念は普通の技量の人が他のソフトウエア・エグゼクタブルに応用してここに記述された予期せぬ利益を実感することができる。下記の特許請求の範囲は特許請求されるものの範囲を規定する。

Claims (25)

1. ゲーム・プログラムを操作している分散されたクライアント・ノードから広告を出力させる方法であって、
   ゲーム・アプリケーション内に含まれる定義されたエグゼクタブル・ファイルを受信するステップであって、前記ゲーム・アプリケーションは前記定義されたエグゼクタブル・ファイルにより定義されるクライアント入力に応答してクライアント・ノード上にビデオ出力を提供するように構成され、前記定義されたエグゼクタブル・ファイルは前記クライアント・ノード上で独立操作を行ってコンピュータ・ゲームを実行することができるステップと、
   前記定義されたエグゼクタブル・ファイルの受信に応答して、前記定義されたエグゼクタブル・ファイルを前記クライアント・ノード上の前記定義されたエグゼクタブル・ファイルの操作中に生じるイベントを検出しかつ前記イベントに応答して各定義されたアクションを実施するように操作できる付加エグゼクタブル・コードと統合するステップであって、前記各定義されたアクションは前記ゲーム・アプリケーションの操作中の広告情報を含むステップと、
   前記ゲーム・アプリケーション、前記付加エグゼクタブル・コード、および前記広告情報を前記クライアント・ノードに提供するステップであって、前記広告情報はその上の前記定義されたエグゼクタブル・ファイルの操作中に前記クライアント・ノードの出力装置から出力されるステップと、
   を含む方法。
2. 請求項１記載の方法であって、前記定義されたエグゼクタブル・ファイルを前記付加エグゼクタブル・コードと統合するステップは、前記定義されたエグゼクタブル・ファイルを操作して前記付加エグゼクタブル・コードに関数呼出しを加え、前記定義されたエグゼクタブル・ファイルの前に前記クライアント・ノードにおいて操作するように前記付加エグゼクタブル・コードを構成するステップを含む方法。
3. 請求項２記載の方法であって、前記定義されたエグゼクタブル・ファイルを統合するステップは、さらに、統一されたエグゼクタブル・ファイル内の前記定義されたエグゼクタブル・ファイルと共に前記付加エグゼクタブル・コードを含む方法。
4. 請求項１記載の方法であって、さらに、前記クライアント・ノードに変更スキーム・データを提供するステップを含み、前記変更スキーム・データは前記付加エグゼクタブル・コードにより使用され、前記イベントに応答して前記クライアント・ノードにおいて自動的に行われる前記各定義されたアクションを識別するように構成される方法。
5. 請求項４記載の方法であって、前記クライアント・ノードに前記変更スキーム・データを提供するステップは、前記付加エグゼクタブル・コードとは別個で、それにより参照されることがあるファイル内の前記変更スキーム・データを提供して達成される方法。
6. 請求項１記載の方法であって、さらに、前記定義されたエグゼクタブル・ファイルと付加エグゼクタブル・コードの統合をコントロールするのに使用される入力を受信するように操作する統合ツールを提供するステップを含む方法。
7. ユーザ入力に応答して、
   エグゼクタブル・ゲーム・ファイルを選出するステップと、
   広告コントロール・コードに使用するため、前記エグゼクタブル・ゲーム・ファイルの操作中に生じると予期される少なくとも１つのゲーム状態を定義するステップと、
   前記広告コントロール・コードに使用するため、少なくとも１つのゲーム状態の発生を検出する基準を定義するステップと、
   前記広告コントロール・コードに使用するため、少なくとも１つのゲーム状態を広告に対する定義された出力モードと関連付けるステップと、
   前記エグゼクタブル・ゲーム・ファイルと前記広告コントロール・コードを統合して統合されたエグゼクタブル・ファイルとするステップと、
   前記統合されたエグゼクタブル・ファイルをクライアント・コンピュータへ配布するために出力するステップと、
   をコンピュータに実施させるようにされた命令でエンコードされたコンピュータ読取可能メモリ。
8. 請求項７記載のコンピュータ読取可能メモリであって、さらに、前記エグゼクタブル・ゲーム・ファイルは前記エグゼクタブル・ゲーム・ファイルを前記広告コントロール・コードと統合するための選出された方法とコンパチブルであることを検証するための命令でエンコードされるメモリ。
9. 請求項７記載のコンピュータ読取可能メモリであって、さらに、ゲーム情報を配布するように構成されたサーバに前記エグゼクタブル・ゲーム・ファイルを登録するための命令でエンコードされるメモリ。
10. 請求項７記載のコンピュータ読取可能メモリであって、さらに、前記エグゼクタブル・ゲーム・ファイルにより使用されるグラフィクスＡＰＩを識別するための命令でエンコードされるメモリ。
11. 請求項７記載のコンピュータ読取可能メモリであって、さらに、前記統合されたファイルに対する動作パラメータを設定するための命令でエンコードされるメモリ。
12. 請求項７記載のコンピュータ読取可能メモリであって、さらに、前記広告コントロール・コードにより呼び出される広告の前記表示をコントロールする外観パラメータを定義するための命令でエンコードされるメモリ。
13. 請求項７記載のコンピュータ読取可能メモリであって、さらに、それを介して前記統合されたファイルがクライアント・ノードに配布される配布チャネルを定義するための命令でエンコードされるメモリ。
14. 請求項７記載のコンピュータ読取可能メモリであって、さらに、前記統合されたファイルとゲーム情報を配布するように構成されたサーバ間の通信モードをコントロールする通信パラメータを定義するための命令でエンコードされるメモリ。
15. ソフトウエア・エグゼクタブルからの出力の独立定義された変更を提供するシステムであって、
    コンピュータ読取可能メモリ内にエンコードされユーザ入力に応答するコンピュータ・ゲーム出力を決定するように操作可能なソフトウエア・エグゼクタブルと、
    前記コンピュータ読取可能メモリ内に前記ソフトウエア・エグゼクタブルでエンコードされ前記ソフトウエア・エグゼクタブルと協力するようにされたイベント・モニタリング・エグゼクタブルであって、前記ソフトウエア・エグゼクタブルが操作している間に生じる定義されたマシン・イベントを定義するように操作可能で、独立コンピュータ出力を前記定義されたマシン・イベントの検出に応答して前記ソフトウエア・エグゼクタブルにより決定されるものとは異なるようにするイベント・モニタリング・エグゼクタブルと、
    を含むシステム。
16. 請求項１５記載のシステムであって、さらに、前記ソフトウエア・エグゼクタブルおよび前記イベント・モニタリング・エグゼクタブルとは別個のファイル内の前記コンピュータ読取可能メモリ内にエンコードされた相互参照データを含み、前記相互参照データは前記定義されたマシン・イベントおよび異なるタイプの前記独立コンピュータ出力間の関連を定義するシステム。
17. 請求項１６記載のシステムであって、前記相互参照データ内の独立コンピュータ出力の前記異なるタイプはグラフィカルゲーム出力を介して表示するように構成されたディスプレーを含むシステム。
18. 請求項１６記載のシステムであって、前記相互参照データ内の独立コンピュータ出力の前記異なるタイプは前記ソフトウエア・エグゼクタブルにより選出されたグラフィカル・レンダリング・テクスチュアの代わりに表示するように構成されたグラフィカル・レンダリング・テクスチュアを含むシステム。
19. 請求項１５記載のシステムであって、前記イベント・モニタリング・エグゼクタブルは、前記ソフトウエア・エグゼクタブルの操作に応じて、グラフィカルＡＰＩ呼出し、オーディオＡＰＩ呼出し、およびグラフィクス出力内の定義されたグラフィクス・テクスチュアの存在から選出された少なくとも１つのタイプのマシン・イベントを検出するようにされているシステム。
20. 請求項１５記載のシステムであって、前記イベント・モニタリング・エグゼクタブルは、独立コンピュータ出力に付加情報に対するネットワーク・アドレスを参照させるように構成されているシステム。
21. 請求項２０記載のシステムであって、さらに、前記イベント・モニタリング・エグゼクタブルを操作している遠隔クライアントからの要求に応答して前記付加情報を提供するようにされているサーバを含むシステム。
22. 請求項２０記載のシステムであって、さらに、時々前記ソフトウエア・エグゼクタブルおよび前記イベント・モニタリング・エグゼクタブルとは別個のファイル内の前記コンピュータ読取可能メモリ内でエンコードするための更新された相互参照データを提供するサーバを含み、前記相互参照データは前記定義されたマシン・イベントおよび前記独立コンピュータ出力の異なるタイプ間の関連を定義するシステム。
23. コンピュータに、
    クライアント・コンピュータ上でコンピュータ・ゲームの操作を開始させ、
    前記コンピュータ・ゲームの操作により生じるコンピュータ出力イベントを検出させ、
    各検出されたコンピュータ出力イベントに応答して行われる定義された応答アクションを選出させ、前記定義された応答アクションは前記コンピュータ出力イベントとは異なり前記クライアント・コンピュータによる広告材料の出力を含み、かつ、
    前記クライアント・コンピュータに前記定義された応答アクションを行わせて前記コンピュータ・ゲームの操作中に前記クライアント・コンピュータから前記広告材料のビデオ出力を生じさせる、
    ように操作可能な命令でエンコードされるコンピュータ読取可能メモリ。
24. 修正可能なイベント定義に応答してコンピュータ・ゲームの操作中に修正可能な広告の表示を検出トリガする方法であって、
    コンピュータ・ゲームの操作により生じるコンピュータ・出力をモニタリングして修正可能なイベント定義に適合するコンピュータ・出力イベントの発生を検出するステップと、
    各検出されたコンピュータ出力イベントに応答して行われる定義された応答アクションを選出し、前記定義された応答アクションは前記コンピュータ・ゲームの操作により生じる前記コンピュータ出力とは別の応答出力を生じ、かつ、
    前記クライアント・コンピュータに前記定義された応答アクションを行わせて前記コンピュータ・ゲームの操作中に前記クライアント・コンピュータから修正可能な広告材料のビデオ出力を生じさせる、
    ステップを含む方法。
25. 請求項２４記載の方法であって、さらに、前記修正可能なイベント定義、前記応答アクションを定義するデータ、および遠隔ソースからの前記修正可能な広告材料から選出されたデータを時々前記クライアント・コンピュータに提供して、ダイナミックで独立して決定されたロジックに従って前記コンピュータ・ゲームの明白な操作を変更するステップを含む方法。

Images