JP2004535621A - 規則に基づいたウェブ・シナリオとキャンペーン・システム及びその方法 - Google Patents

Abstract

【課題】本発明は、顧客又は顧客の行動を判断して特徴付けるために規則を使用し、これらの規則の結果に基づき表示されたページなどのビジネス機能を個性化する個性化システムを提供する。
【解決手段】本発明のシステムは、顧客のセッションを特徴付けるイベントの潜在的な一続き−シナリオを生成するために規則を使用する。シナリオはキャンペーンの基礎を形成する。１つの実施の形態では、規則エンジン及びコマース・アプリケーションから及びへ情報を送るためのサーバーと、現在の手順に関する情報を有する決定及び行動を決定するために規則組の内容を分析するための規則エンジン（１０２）と、各々が状態と行動を定義する複数の規則を含む規則組と、規則組を格納する規則記憶場所とを含むｅコマース・アプリケシーョンのコンテントをカスタマイズするための規則に基づいたシステムが提供される。
【選択図】図１

Description

【技術分野】
【０００１】
著作権表示
この特許書類の開示の一部は著作権保護を受ける内容を含む。著作権所有者は、特許商標庁の特許ファイル及び記録に現れるように特許書類のファクシミリな複製については異議を持たないが、それ以外については全ての著作権を留保する。
【０００２】
優先権主張
本出願は、ここに参照のために組み込まれた、２００１年４月１６日出願の仮出願番号６０／２８３，９７７「規則に基づいたウェブ・シナリオ及びキャンペーンのためのシステム及び方法」の優先権を主張する。
【０００３】
本発明は、オンライン及び、特に、ウェブ可能化システムに関し、ユーザ又はユーザのグループに対してアプリケーションの振舞いとコンテント（内容）を個性化するための方法に関する。
【０００４】
発明の背景
ｅコマース（電子的商業活動）の分野において、顧客のニーズ及び要求により良く合うように製品及びサービスの作り変えることが可能なビジネスについての需要が存在する。この需要は、ビジネス・ツー・ビジネス（Ｂ２Ｂ）及びビジネス・ツー・消費者（Ｂ２Ｃ）の両方の世界に等しく存在する。ビジネス・サービスをこのように作り変える特定の例が個性化の分野に存在する。個性化は、特定の顧客又は顧客のグループに対してビジネスの申込み（売込み）を個性化又はカスタマイズすることを可能にする。例えば、インターネット／ウェブ環境におけるＢ２Ｃコンテント・プロバイダは、そのウェブサイトコンテントがサイトを訪れる個別の顧客の各々に対して又はある特性に基づく顧客の各タイプに対して個性化されたウェブサイトを配備することを望むだろう。このようなウェブに基づいたＢ２Ｃプロバイダの例は、オンラインカタログ・プロバイダ、製品ベンダー（売主）、ニュース、メディア及び娯楽プロバイダ、及び情報又は参考ソースを含む。
【０００５】
彼等のビジネスの成功は頼りになる個性化されたサービスに、より依存するようになっているので、ｅコマース・プロバイダは彼等の個性化されたシステムに対してより大きな要求を持つ。主な要求は、プロバイダがウェブサイトを個性化するのを助けるのみならず、マーケテイング、生産、配達等の彼等のビジネス機能の全てを１つのソースで作り変えることを可能にし且つシステムの停止時間を必要としないか又はほとんど必要とせずに早く、頼りになり、容易に修正可能な方法で、これらの機能が依存する情報又はデータを更新することを可能にする個性化システムである。
【０００６】
ウェブ・コンテントを個性化するために使用される伝統的なシステムは、ほとんどが分析的な性質であり、管理者が理解するデータに基づきウェブサイト又はｅコマース・アプリケーションを修正することを可能にする方法で、前に収集したデータの使用に依存する。例えば、主にオンライン分析処理（ＯＬＡＰ）システムを提供するＡＴＧ及びブロードベースなどのベンダーからの個性化システムは、彼等の目標人口を分析的方法、すなわち、統計的方法で表し、そして、人口の部分に対してコンテントを個性化するデータを使用するため、コマース・プロバイダが収集した十分に大きなデータ量に依存する。データは、伝統的な機構、すなわち、標準の市場調査ツール、により収集されるか、又は、例えば、顧客の前の使用経歴を維持することによりオンラインで収集される。しかし、このようなデータは後で管理者が実際のコンテントを更新のために分析して使用する前に、典型的に分析のために記憶装置内に記憶される。この方法では、データはシステムの即時の個性化を与えるために使用されず、又は、管理者による実行時間中に容易に修正できるものでない。その代わり、データはむしろ長期間及び多数のユーザにわたるコンテントの変化を表すために使用される。実際の使用又は顧客のセッション中に、ユーザ毎にデータコンテントをカスタマイズする試みはなされていない。
【０００７】
個性化されたユーザ・コンテント及び／又は入手可能な製品及びサービスの即時の更新を必要とする今日のｅコマースに対する需要が成長しているので、アプリケーションの実行時間中、及び、ユーザが能動的にセッション中に操作している時でさえも、管理者が素早くユーザに表示されているコンテントをカスタマイズすることが可能なシステムに対する需要がさらに増大している。さらに、ユーザに彼等のセッション中に表示されているコンテントを変更するための規則又は他の機構を使用することにより、この変更を自動的に行うことを可能にするシステムが特に有用である。最終ユーザがより洗練されて彼等のコンテント・プロバイダからより良い品質のサービスを要求し、そしてバックエンド・コマース・アプリケーションがより複雑になってコンテントのこのような詳細な変化を提供できるほど十分に柔軟になると、ユーザへのデータコンテントを即時に個性化することを可能にしそしてこれを与える能力を支援するシステムに対する需要がさらに増大している。これを行うことができ、同時にデータコンテントの設定とキャンペーンのマーケテイングを容易に使用できるシステムが、管理者がユーザにコンテントを送信するための規則及びその現実のコンテントを素早く管理することが可能のため、特に有用である。
【０００８】
発明の開示
本発明は、ｅコマース・プロバイダが、各顧客、顧客のグループ、又は顧客の特定のタイプに対してカスタマイズ若しくは個性化することが可能なシステム及びその方法を提供する。これの簡単な例は、訪れる各顧客が彼等の特定のニーズに対してカスタマイズされたおそらく僅かに異なるサイト・コンテントを見ることができるような、ウェブサイトの個性化である。しかし、システムは個性化により利益を受けるどんなビジネス・システムにおいて等しく使用できる。ここで使用されるユーザ又は顧客は、個人、若しくは、組織又は会社などの他のどんなエンティテイであってよい。ユーザがアクセスするビジネス機能は画面上に表示されるタイプでなくてもよく、代わりに、例えば、自動的スタイル注文検索、処理、及び他の操作であってよい。本発明は、プロセスのどんなステップでも、及び、どんなエンティテイの間でも、アプリケーションの振舞い及びデータの個性化をすることを可能にする。
【０００９】
簡単に説明すると、本発明は、顧客又は顧客の行動を決定して特徴付けるための規則を使用し、そして、これらの規則の結果に基づいて、例えば、データ通信、又は、表示されたページなど、ビジネス機能を個性化する個性化システムを提供する。規則は、シナリオ−顧客のセッションを特徴付けるイベントの潜在的な続き、を生成するために使用できる。シナリオは、次に、キャンペーン−開始時間と終了時間を持つ可能な組合せられたシナリオの一組で、その中で顧客が操作し、そしてその環境中で規則に基づいたシステムがその決定を行い、そして特徴化と個性化を与えるもの、の基礎を形成する。
【００１０】
１つの実施の形態では、本発明はｅコマース（電子的商取引）アプリケーションのコンテントをカスタマイズするための規則に基づいたシステムであって、規則エンジンからの及びへ情報を送るためのサーバーと、複数の規則を有して各規則が潜在的な状態及び対応する行動を定義する規則組と、行動を決定するために現在の手続きに関する情報を持つ決定を決定するために規則組の内容を解析するための規則エンジンとを含む規則に基づいたシステムを提供する。
【００１１】
インターネット及び／又はウェブサイトの環境では、本発明の実施の形態はウェブユーザに彼等のセッション情報に基づいて個性化されたコンテントを表示するために使用できる。この実施の形態では、ユーザに使用されるウェブ・アプリケーションは、例えば、オンライン予約システム、例えば、飛行機予約、又は、カタログ注文などの商業ウェブサイト・アプリケーションであってよい。ユーザがこのようなアプリケーションにログインする時、セッションが生成され、そして、そのセッションに対応したイベントが発生する。これらのイベントは規則に基づいたエンジンを駆動するために使用され、次にそれはコンテントの提供を駆動するために使用される。ユーザ・プロファイルに基づいてユーザの人物像の推測が行われ、そして、規則がそのプロフアイルに対して実行される。これらの全ては、統計又はマーケテイング情報の記憶などの二次的な個性化ソースを参照する必要なく、即時に行われる。
【００１２】
詳細な説明
本発明の説明に有用な用語、略語、頭文字の定義を説明する。

【００１３】
本発明は、システムのユーザ又は顧客へ配達するためにビジネス機能、アプリケーション、又は、情報コンテントをカスタマイズ及び個性化するために使用できる規則に基づいた実時間個性化エンジンを提供する。本発明の文脈中、顧客又はユーザは個人、例えば、ウェブサイトの個人ユーザ、であってよく、又は、システムと通信するために相互作用又は自動式機構を使用する別の組織であってよい。ユーザがシステムと相互作用する時、規則に基づいたエンジンを駆動するために使用されるイベントが生成される。使用される特定の規則によると、個性化エンジンは実時間（即時）に、いずれのコンテント又は情報がユーザに送信されるべきかを決定する。例えば、このコンテントはユーザがウェブサイト画面上に見る特定の情報であってよく、又は、それはデータ通信の他の形式であることができる。例えば、無線アプリケーション・プロトコル（ＷＡＰ）装置又はパーソナル・デジタル・アシスタント（ＰＡＤ）に自動的に通信される必ずしもユーザに見られないデータである。本発明の１つの実施の形態によると、ＸＭＬファイルが、規則に基づいたエンジンの動作を構成するために使用されており、管理者が単にＸＭＬファイルの文章を編集することにより規則に基づいたエンジンの操作を容易且つ素早く修正することを可能にする。規則に基づいたエンジンが単にデータをスクリーン上に表示する以外のビジネス機能を制御するために使用できるため、本発明は組織に対して各顧客又は顧客のタイプについて彼等のビジネス機能とアプリケーションを個性化する能力を与える。
【００１４】
個性化システムの操作は、キャンペーン及びシナリオの使用により容易になる。本発明の文脈で使用されるように、シナリオは特定の規則の引き金を引いて特定の行動、ビジネス機能、又はデータを表示するイベントの組である。キャンペーンは、多くのシナリオを含むことができ、そして、管理者が特定のユーザ又はユーザのグループのニーズに最も反映するためシナリオの全体の組を制御できる簡単な機構を提供する。
【００１５】
図１は、例えば、ウェブ環境で、ユーザに個性化されたコンテントを提供するため、本発明の１つの実施の形態により使用される個性化システムの概略的な全体図を示す。図１に示すように、規則エンジン１０２は、ユーザにコンテントを表示する際に使用するシナリオ及びキャンペーン設定の特定の組を選択するために、シナリオ１１０及びキャンペーン１１２を定義する規則１００を解釈する。シナリオ１１８及びキャンペーン１２０は必要な時に後で活性化するために記憶できる。規則は規則エンジン１０２（及び、選択的に別個のシナリオ・エンジン１０４とキャンペーン・エンジン１０６、これら後者の２つのエンジンの機能は規則エンジン１０２のみにより実行可能であることは明らかであるけれど）の操作を定義するため使用され、そして、特に、ユーザ１１６へディスプレイ１１４で表示するためのコンテントを選択し生成する際に可変なシナリオ及びキャンペーンの内、いずれのシナリオ及びいずれのキャンペーンを使用すべきかを規則エンジンに知らせる。
【００１６】
規則に基づいたエンジン
本発明の中心部分は規則に基づいたエンジンである。規則に基づいたエンジンは、現在の進行について知る決定及びそこからの行動を決定するために規則を使用する。各規則は状態（条件（ｉｆ）節）及び行動（結果（ｔｈｅｎ）節）を定義する。このような規則の使用は、シナリオ中に状態と行動のフローチャート・スタイルの連鎖を可能にする。規則は１つの規則組又は複数の規則組内に記憶される。ここで使用される規則組とは、規則エンジンが一緒に使用できるように束ねられた関連する規則の集まりである。規則組及び規則は、シナリオ及びキャンペーン内でイベントの流れを指示するために使用される。
【００１７】
本発明の１つの実施の形態では、規則はシステム間のポータビリテイを容易にするためにＸＭＬフォーマットで書かれてよい。さらに、ＸＭＬ体系は即時に解析でき、システムの停止時間を必要とすることなく、規則（及びビジネスの作業流れ）を即時に修正することを可能にする。さらに、ユーザの特性又は人物像は規則の一続きにより計算できるため、システムは要求時に生成できるユーザの即時の「スナップショット」を提供する機構を与え、そのユーザの個性化されたコンテント又はサービスを提供するために使用できる。
【００１８】
シナリオ
シナリオは条件及び行動の鎖である。シナリオはユーザの可能な相互作用のフローチャートを記述する。キャンペーンは、広告主のビジネス目的を達成するため、又は、特定のビジネス機能を行うために一組のこのようなシナリオを使用する。ウェブサイト又は同様なＢ２Ｃのアプリケーションの文脈では、キャンペーンはこれらの目的を達成するためにシナリオを通じて、オンライン広告、電子メール、及び消費者割引販売促進を使用する。
【００１９】
シナリオは、抽象的な機能を表す。しかし、キャンペーンの文脈中に使用されるシナリオは、ＢＥＡシステムからのウェブロジック・アプリケーション・サーバー・コマース・サーバー製品など、どんなビジネス・ツー・ビジネス、ビシネス・ツー・コンシュマー、又は、ｅコマースのプラットホーム上に作ることができる。
【００２０】
１つの実施の形態では、シナリオは個別に名前が付けられて、各シナリオが有効であるための分類リストを維持する。シナリオ・エンジンにより、名前、記述、又は分類のタイプなどの基準に基づいて、特定のシナリオを探索できる。この探索は、全体言葉一致及びパターン一致（例えば、「スーパーボウル」のような記述）の両方を含んでよい。探索の結果は、探索と一致したそれらシナリオの名前である。コンテキストの即時の配達中に、システムは素早く現在の状態を分担されたシナリオと一致でき、よって反応できる。
【００２１】
シナリオ・エンジンはシナリオ定義の記憶場所として動作する。シナリオ定義は編集の際の使用の容易さのため、ＸＭＬフォーマットで記憶してよいが、他のフォーマットも使用できる。シナリオ・エンジンはまたシナリオのＸＭＬ定義を名前で戻してもよく、与えられたシナリオをシナリオ定義で配備できる。
【００２２】
シナリオは、規則から構成された規則組からなる。各規則は、状態（条件（ｉｆ）節）及び行動（結果（ｔｈｅｎ）節）を定義する。規則の使用は、シナリオに状態及び行動のフローチャート形式の連鎖を可能とする。
【００２３】
シナリオ規則組への可能な入力（ｉｆ）は、限定的ではなく、以下を含む。
ユーザの個人の特性、
分類規則のネットの実行の結果、
ユーザの現在のセッション及び要求情報（これは、例えば、彼等の買物かご、又は、ページ位置を含んでよい）、
セッション中に発生したイベント、
現在時間、又は
ランダム数（システムが確率に基づいた計算を実行することを可能にするため）である。
【００２４】
シナリオ規則エデイターを使用して、システム・ユーザ（典型的に、例えば、システム管理者）は、例えば、ユーザ・プロフアイルに対して、ユーザのセッション（特に、買物かご）のコンテントに対して、ユーザの現在の要求情報（ブラウザ・タイプ、ページ位置、等）に対して、あるユーザの履歴イベント（例えば、購入履歴）に対して、イベント・タイプ、ヘッダー、又は本体（テキストメッセージ等中の文章本体）に対してを含むどんな入力に対して、カスタム規則を書くことができる。規則組からの可能な出力（「項目」）は、すなわち、システムが入力に対して応答しなければならない１つ又は複数の行動を実行するための行動定義（ＡｃｔｉｏｎＤｅｆ）を含む。これはコンテントの特定のタイプを配達することを含んでよい。
【００２５】
シナリオはあるユーザ分類（すなわち、顧客階層）に対してのみ有効である。
【００２６】
規則エンジン自身は、どんな機能も実行しない（すなわち、イベントを配置する等、行動を発生しない）。その代わりに、規則エンジンから識別されたオブジェクトがシナリオ・エンジンに送られて、それが要求された行動をそのシナリオの記憶場所に従って実行する。
【００２７】
通常の使用では、規則の評価がＡｃｔｉｏｎＤｅｆを主張する。この行動はユーザに対して何かを発生し又は表示する。ユーザは、イベントを生ずる何かを行う。イベントはシナリオ・エンジンへ送られて、おそらく、終了状態に達するまでサイクルが繰返される。
【００２８】
キャンペーン
キャンペーンは、特定の目標を達成するように設計されたシナリオの広告主の付いた組である。マーケテイングの文脈では、キャンペーンはある期間中にある範囲の商品を販売促進するために設計される。他のキャンペーンはより一般的に、会社又は組織が現在実施したいシナリオ（典型的に関連した）の組を単に含む。各キャンペーンは、１つ又は複数のシナリオと関連される。キャンペーンは活動又は非活動のいずれかの印を付けることができ、そして典型的にそれらが開始及び停止する指定された日付／時間を持つ。キャンペーン・エンジンを通じて、キャンペーンは、名前、開始及び／又は停止時間、分類（シナリオに対する関係を経由）、広告主名、記述、価値前提、目標記述、及び活動状態などの基準に基づいて探索できる。
【００２９】
探索は、全体言葉一致及びパターン一致（例えば、「スーパーボウル」のような記述）の両方を含むことができる。探索結果は、探索に一致したこれらのキャンペーンの名前である。そして、キャンペーンに関連したシナリオがシナリオ・エンジン上での探索により検索できる。
【００３０】
キャンペーン・エンジンは、キャンペーン定義の貯蔵場所として動作する。シナリオ定義と同様に、キャンペーン定義はＸＭＬフォーマットで記憶できる。キャンペーン・エンジンは、キャンペーンのＸＭＬ定義を名前で戻し、そして、与えられたキャンペーンをキャンペーン定義に配置できる。
【００３１】
図２は、本発明の１つの実施の形態に従いどのようにキャンペーン・シナリオ及び規則が個性化システムを提供するために一緒に使用されるかを示す。図２に示すように、イベント・サービス１３０が特定のイベントを受取り、そして、このイベントをキャンペーン・イベント・リスナー１３２へ送るために使用される。イベントは、規則エンジン内で即時の変化の引き金を引くために使用される駆動力であり、そして規則エンジンはユーザに対して与えられる出力を決定する。例えば、イベントはユーザのログイン・イベント、又は、ウェブ・アプリケーションの場合、ユーザからの特定のページを選択する又はフォームのあるタイプを提出するための要求であってよい。いくつかのイベントはイベント・サービスにより意図的に無視できるので、イベントは必ずしも規則を実行するために引き金を引く必要はない。キャンペーン・イベント・リスナー１３２もまた、あるイベントのタイプをフィルター除去するために使用でき、そして、さらなる処理のためにイベントをキャンペーン・サービス１３４へ送る。キャンペーン・サービス１３４は、現在活動的なキャンペーン、すなわち、管理者により指定された又は現在置かれているキャンペーンをロードする。もし、イベントが特定のキャンペーンから受取られた場合、キャンペーン・サービスはそのキャンペーンをロードする。そして、このキャンペーン情報を使用してキャンペーン・シナリオ識別の地図を作成して、この情報と一緒にシナリオ・サービス１３６へ送る。シナリオ・サービス１３６は、キャンペーン・サービス１３４の小組として動作し、ユーザが終了状態に到達したシナリオをフィルター除去するために使用される。もし、ユーザが終了状態に到達した場合、これはシステム側においてなすべき作業がなく、ユーザに次のステップを決定する権限があることを意味する。しかし、ユーザが終了状態に到達していない時は、シナリオ・サービスはループして実施中のシナリオ規則の特定組に対してイベント・タイプが有効であるかどうかを決定する。もし、有効でなければ、シナリオは無視される。もし、追加の顧客階層が必要とされる場合、シナリオ・サービスも階層規則組を実行するために使用できる。シナリオ・サービスはまた、シナリオ規則組を実行して行動定義のリストを得るためにも使用できる。この処理を実行するため、シナリオ・サービス１３６はその特定のシナリオに対して実施中の規則を決定するために規則マネージャ１３８からの規則を使用する。典型的に、各規則ルールは少なくとも１つ又は複数の行動定義を特定する。各シナリオからの各行動定義に対して、シナリオ・サービスはアクション・サービス１４０からアクション・オブジェクトを得る。それが各アクション・オブジェクトを実行する時、実際の実現に依存して、異なるイベントが発生してもよい。例えば、図２に示すように、これらのイベントはこのような行動をシナリオ終了行動１４２として強制し、シナリオ・サービス１４０をそのキャンペーン・シナリオについてユーザを終了状態に設定するために使用する。広告プレイスホルダー行動１４６はユーザのバケツ内に広告質問を置くためにバケツ・サービス１４８を使用する。メール行動１４８は後でユーザに電子メールを一括処理して送信するためにメール・サービス１５０を使用する。そして、売込み割引行動１５２はユーザに彼等のセッション中に割引を与えるために割引関連マネージャ１５４を使用する。図２に示された例は、本発明により提供できるさまざまな特徴とサービスを示すけれど、当業者には明らかなように、示されたイベント例は網羅的ではなく、本発明と共に使用できるイベント、シナリオ及びサービスのタイプを説明するだけのものである。特定の組織又はｅコマース・アプリケーションの必要性に最良に合うように他のタイプの規則、イベント、及び適当なサービスを追加できることは明らかである。
【００３２】
図３は、システムの顧客又はユーザに対して即時に個性化されたコンテントを提供するために、本発明の１つの実施の形態により使用できる典型的なプロセスのフローチャートを示す。図３に示すように、ステップ１６０で、一旦、呼び出された規則エンジンがこの状態で使用するための特定の規則組を決定する。ステップ１６２で、規則が「ｉｆ ｔｈｅｎ」節を使用して評価されて、システムがユーザのセッションの現在状態、すなわち、ｉｆ部分を読み、そして、潜在的なシナリオの組から出力が何であるべきかを決定する。ステップ１６４で、この出力が行動定義として主張される。この行動定義は、システムがこの特定の文脈中でこの特定のユーザに対してどのように応答すべきかを決定する。すなわち、システムがどんな行動を取るべきかを決定する。ステップ１６６で、もしあれば、出力が結果としてユーザに表示される。明らかなように、システムは表示をしないがデータを通信する又はある方法であるビジネス機能又は応用を変更する他の行動を取ることを決定できる。ステップ１６６で、後の時間のポイントにおいて、もし、ユーザが彼等の行動により追加のイベントを発生した場合、ステップ１７０で、このイベントはシナリオ・エンジン（又は、もし単一エンジンが使用される場合は、規則エンジン）へ送られる。ステップ１７２で、このシステムがその後のイベントにどのように応答すべきかを決定する、その後の規則決定の使用のため、シナリオ・エンジンは規則エンジンに情報をリレーして戻す。
【００３３】
キャンペーン目標及び活性化
キャンペーンは目標を２つの方法で使用できる。目標は、キャンペーンの目的をより明確にするために使用できる文章的記述である。二番目に、目標は、キャンペーンにより達成できる定量的な測定である。１つの実施の形態によれば、全てのキャンペーンは、次の入力を受け取る現在活動的な規則を持つ。
【００３４】
キャンペーン・データ・オブジェクト、
広告露出とクリック計数へのアクセス、
イベント、及び
現在日付と時間である。
【００３５】
現在活動的な規則の出力は、真又は偽のいずれかである。真はキャンペーンが現在活動的であることを示す。偽は活動的でないことを示し、さらなる処理は発生しない。キャンペーンを非活動的にするための機構が存在する。キャンペーンの活動基準に関係なく、キャンペーンは管理者により常に活動的又は非活動的にできる。この状態は活動又はシナリオ規則を評価する前に最初に検査される。さらに、キャンペーンはキャンペーンの活動状態を決定する開始及び停止時間を持つことができる。
【００３６】
キャンペーン・ライフサイクル
図４は、キャンペーンが実行時間環境から追加又は除去されるプロセスを示す。キャンペーンは最初に開始されなければならない１８０。これは典型的に最初に配備されたときに生ずるが、開始は手動プロセスが発生するまで遅延できる。本発明のいくつかの実施の形態では、シナリオごとの開始規則を指定できる。開始時、キャンペーンのこれらシナリオごとの開始規則が実行される。入力はキャンペーン・データ・オブジェクト及び現在時刻である。出力は実行される行動定義（ＡｃｔｉｏｎＤｅｆ）である。
【００３７】
キャンペーンが実際に開始された後、一般に、キャンペーンの開始時間に基づいて、又は、明示的にそれを活動的キャンペーンとして印を付けることにより、その後に活動的１８２になる。最初に活動的になった後、何時でも、キャンペーンの所定の停止時間に到達することにより、キャンペーンの目標が満足されることにより（すなわち、「現在活動的なｉｆ」規則）、又は、管理者がキャンペーンを非活動的にすることにより、キャンペーンは非活動的１８４になる又は印を付けることができる。非活動的にされた後、一般に、管理者がそれを修正し、それを再配備し、そしてそれを活動的と印を付けることにより、キャンペーンはある場合に再び活動的になることができる。
【００３８】
いくつかの実施の形態では、開始された後、何時でも、キャンペーンは停止できる１８６。これは一般に管理者による手動プロセスである。停止の際、全てのシナリオごとの停止規則が実行される。これらの規則への入力はキャンペーン・データ・オブジェクト及び現在時刻である。出力はキャンペーン・エンジンが実行するための行動定義（ＡｃｔｉｏｎＤｅｆ）である。これらの行動は典型的には開始規則からのいずれの行動も取り消すが、しかし、そのように必ずしなければならない必要性はない。
【００３９】
キャンペーンが停止された後、それは消去される１８８。これは、全てのキャンペーン関連データ（例えば、広告露出計数、シナリオ状態情報等）を除去することを含む。それはまた、キャンペーン・エンジン記憶場所からキャンペーン定義を除去することも含む。
【００４０】
報告／分析
キャンペーンは、イベントにより駆動される。さらに、広告露出及びクリック・スルー計数がキャンペーンの使用のためにキャンペーン・サービスにより維持される。これらは、報告のためもアクセスできる。
【００４１】
行動サービス
行動サービスは、規則エンジンが規則組の結果に基づいて実行すべき行動の概念を抽出する。これは、規則が具体的な行動の一般的な定義を主張することを可能にする。このＡｃｔｉｏｎＤｅｆは、下位の行動を実行することができるオブジェクトへのアクセスを得るために使用できる。従って、新行動を生成でき、サーバーを再スタートすることなく配備できる。これをするための１つの方法は、具体的な行動オブジェクトをサービスするセッションＥＪＢを配備することである。
【００４２】
行動記憶場所がシナリオ・ツール中に利用可能である。１つの実施の形態では、この行動記憶場所はＸＭＬドキュメンにより記述できる。シナリオ・ツールはこれを使用して行動を動的にユーザに表示し、そして、ユーザからその行動に対する全てのパラメータを集める。キャンペーンの行動の所定の組は以下を含む。
【００４３】
広告グループ（質問）をユーザ又は重み付けをもってグローバル・プレイスホルダー内に置く。
広告グループ（質問）をユーザ又はグローバル・プレイスホルダーから除去する。
ユーザに名前の付いた割引きを売出す。
ユーザに対してＵＲＩから主題を持つ電子メールを生成する。
【００４４】
プレイスホルダー
プレイスホルダーは、ジャバ・サーブレット・ページ（ＪＳＰ）内の位置を表す。プレイスホルダーの行動は、特定のシステム構成により決定される。これはシナリオの行動概念に大変似ている。しかし、プレイスホルダーの行動は、イベント駆動ではなく、大変に要求駆動である。典型的な実現では、要求がプレイスホルダーＪＳＰタグを含むＪＳＰページについてのウェブユーザからウェブページに入って来る。タグは、発生すべき行動を記述したオブジェクトを戻すセッションＥＪＢにコンタクトする。行動は選択的に表示可能なユニットであることができる。表示可能なユニットの場合、表示可能なユニットはそのユニットをどのよう表示するかを知っている描写オブジェクトを含む。
【００４５】
広告プレイスホルダー
広告生成のために本発明を使用する環境では、プレイスホルダーは広告を表示するために使用できる。広告を表示するプレイスホルダーの行動については、プレイスホルダーに対するユーザの広告バケツが使用される。広告バケツは、バケツ・エントリイに基づいた表示計数に加えて、ユーザに表示されるべき広告又は広告グループの組を含む。バケツの各エントリイは、次の情報を含む。ユーザ名、プレイスホルダー名、入力された日付及び時間、広告質問（表示すべき広告又は広告グループを定義）、重み付け、表示計数、キャンペーン名、シナリオ名である。
【００４６】
いくつかの実施の形態では、特定のユーザに結び付けられていない各プレイスホルダーに対して広告バケツが存在できる。そうでなければ、バケツの各エントリイは同じ情報を持つであろう。
【００４７】
広告バケツはプレイスホルダー要求（すなわち、キャンペーン／シナリオ・エンジンにより）からの外部的に居住されるために、広告バケツ衝突を解決する機構が使用できる。この衝突解決機構は、ユーザの広告バケツ中のどのエントリイが表示される広告を見つけるために実際に使用される決定する。１つの実施の形態では、有効なバケツ・エントリイの重み付けが使用される。バケツ・エントリイは、もし、その対応するキャンペーンが現在活動的ならば、又は、キャンペーンに関連しないならば、有効である。単一のエントリイの重み付けは、それに見られるチャンスの（重み付け＊１００／（全ての重み付けの和））パーセントを与える。ランダム数が、どのバケツ・エントリイが使用されるかを決定するために使用される。例えば、もし、重み付け１、２、３及び４を持つ４つのエントリイがバケツ内にある場合、レイアウトは例えば次の通りである。
【００４８】

【００４９】
一旦、エントリイが決定されると、そのエントリイの質問は広告の組（すなわち、広告グループ）を生ずるために実行される。グループ内の各広告はそれ自身の重み付けを持つ。同様なアルゴリズムが、その広告グループからどの広告が使用されるかを決定するために適用される。もし、広告グループの大きさをゼロにする何かが発生した場合、システムは、前に選んだバケツ・エントリイを無視して、使用するために新しいバケツ・エントリイを選ぶ。もし、ユーザ・バケツ・エントリイが無ければ、グローバル・ユーザ・バケツ・エントリイが同様に検査される。グローバル・ユーザ・バケツは一般にキャンペーン開始規則を介して住まれる。
【００５０】
広告を持つウェブサイトと共に使用するため、本発明の１つの実施の形態では、特定の広告をユーザに表示することは、広告のクリック・スルーと同様に、イベントを発生できる。両方の場合において、広告バケツ内に広告を置いたキャンペーン及びシナリオの識別（ｉｄ）は、イベントと共に送られる。これは、システムが、その後の分析及び報告の目的のために、「見る」及び「クリック・スルー」イベントを広告とキャンペーンの両方に結び付けることを可能にする。
【００５１】
広告サービス
広告サービスは、ユーザにその後に表示するための広告メタデータ及びコンテントを提供する。サービスは広告をその独特の識別子に基づいて又は広告メタデータに対する探索に基づいて広告を検索できる。広告は、例えば、オプショナルのクリック・スルーＵＲＬを持つ単一のイメージ、代替的な文章、境界仕様、幅、高さ、文章上マウス、ＨＴＭＬ文章のブロック（クリック・スルーＵＲＬを含むことができる）、さらにＨＴＭＬブロックにより参照されるどんな補足的なメディア、又はインラインＪＳＰページへの参照を含むことができる。
【００５２】
全ての広告は、整数であることができる関連する相対的重み付けを有する。特定の広告の重み付けは広告表示衝突を解決するために使用される。
【００５３】
１つの実施の形態では、広告サービスは、次の広告印象（ユーザが何を見るか）及び広告ごとのクリック・スルー・イベント計数を含む。グローバル計数及びキャンペーンごとの計数。
【００５４】
この情報は、キャンペーン目標評価を処理するために使用される。それはさらに報告にも使用できる。ユーザ毎の広告計数はイベント・サービスにより処理できる。
【００５５】
いくつかの実施の形態では、計数を見る、増加又は減少するための広告サービスを質問する機構が存在する。そして、この情報はキャンペーン及びシナリオ・エンジンにより直接的に使用されるので、上記レベルの詳細さで検索可能でなければならない。
【００５６】
電子メール・サービス
電子メール・サービスが、電子メールに基づいたキャンペーンを支援するために使用できる。電子メールに基づいたキャンペーンは、システムがユーザ又はユーザのグループに対して電子メール内容の個性化を指示することを可能にする。１つの実施の形態では、電子メール・サービスは、構成に基づいて２つの操作モードを支援する。バッチ・モード及びパススルー・モードである。パススルー・モードは、サービスが直ちに電子メール要求を送る。バッチ・モードは、サービスが後で送信できるように電子メール要求をデータ記憶に格納する。管理用インターフェイス又は命令行プログラムがバッチされた電子メールを送信するために使用できる。電子メール・サービスに必要な情報は、標準の電子メール・ヘッダー情報（例えば、宛先、送信元、件名）、ＭＩＭＥ電子メール・ヘッダー情報（例えば、内容タイプ、内容長さ、内容配置、これらのいくつかは電子メール本体から決定できる）、電子メール本体、電子メールを送信するキャンペーン及びシナリオの識別、及び、どれだけ長く電子メールが有効か（すなわち、もし、５日以内に送信されなければ、廃棄）である。
【００５７】
キャンペーン及びシナリオの配備
キャンペーン及びシナリオは、それらが操作される前にサーバーに配備されなければならない。１つの実施の形態では、配備のためにＸＭＬ定義を適当なサービスに送ることのできるサーブレットが使用できる。
【００５８】
キャンペーン及びシナリオ・サービスは、ＸＭＬファイルから入力を取り、そして、ＸＭＬファイルは一組の管理者用ツールにより生成される。シナリオ規則のためのスキームと同じく、キャンペーン及びシナリオ定義のためのスキームが使用される。
【００５９】
管理者は、キャンペーン及びシナリオ定義を作成して配備するためにこれら管理者用ツールを使用できる。このツールは、これらの定義を表すＸＭＬファイルを生成して、配備用サーブレットにより新しい定義を配備する。このサーブレットは、ＸＭＬデータのストリームを受け取り、データを処理するために適当なサービスを呼び出す。キャンペーン、シナリオ、及び、これらに関連する規則は別々に配備できる。普通、規則が最初に配備されて、その後にそれらを使用するシナリオが続き、そして最後にシナリオから構成されるキャンペーンが続く。キャンペーン又はシナリオが「配備される」時、関連するサービスが中央データベース又は記憶場所のＸＭＬ定義に存続する。
【００６０】
ＥＪＢ実現
上述したサービスは、状態の無いサービスの組として実現できる。１つの実施の形態では、例えば、エンタープライズ・ジャバ・ビーンズ（ＥＪＢ）使用に従う一組の状態の無いセッション・ビーンズとして実現できる。以下に、シナリオ及びキャンペーンを支援するのに必要なサービス及び機能を提供するためにＥＪＢを利用する本発明の実現が詳細に説明される。ＥＪＢに加えて又は代わりに、他のタイプの資源も使用できることは明らかである。
【００６１】
シナリオ・サービス
シナリオ・サービスは、システムとユーザの間の相互作用の流れを規則と行動の一組として定義することが可能なように設計される。
【００６２】
シナリオ・セッション・ビーン
シナリオ・サービス・セッション・ビーンは、シナリオ機能の外部インターフェイスである。イベントがシナリオ・サービスにより受信される時、それはシステム内のいずれかのシナリオがそのイベントに対して反応すべきかを決定する。もし、そうであるならば、サービスはイベントを興味のある各シナリオに送り、そして、イベント内に含まれる情報についてそれらの規則を実行させる。このセッション・ビーンはまた、シナリオを再配備しそしてＸＭＬとして既存のシナリオを輸出するための機能を提供する。
【００６３】
シナリオ・オブジェクト
シナリオは、いくつかの追加のビジネス論理を含んだ規則組の回りの包装として動作する。シナリオがシナリオ・サービスからイベントを受け取る時、それは最初にそのイベントがシナリオに対して意味があるかを確認するために検査する。もし、無ければ、シナリオは即座に戻す。それ以外で、もし、意味があれば、それはイベント内に含まれた情報を規則サービスへ、シナリオ内に含まれた規則組と共に送る。シナリオ規則はそれらが実行される時に行動定義を生成する。規則組の実行後、シナリオは行動サービスを使用して、もしあれば、結果の行動定義オブジェクトを実行する。これは、規則により生成された行動が規則エンジン・スレッド内で実行されることを防止する。
【００６４】
行動オブジェクト
シナリオが受け取ったイベントに対して規則組を実行する時、普通ある種の行動がこれらの規則の結果として実行される。これを達成するため、規則は行動定義オブジェクトを生成し、初期化する。これらのオブジェクトは、それらが代表する行動名により初期化されなければならず、そして、行動が実行されるために必要なパラメータのマップで初期化されなければならない。これらは、実際の作業を実行する行動インターフェイスの実際の実現を具体化するための責任を持つ。このインターフェイスは、指定されたパラメータのマップを取る初期メソッド及び行動を実行する実行メソッドを含む。規則は行動定義をイベント、現在ユーザ、又は、その他の利用可能な資源からのデータで正しく初期化することを規則エンジンに指示するよう設計される。例えば、電子メールを送信するシナリオは、電子メールの受取人のアドレス及びメッセージの文章、及び行動、電子メール送信行動の名前などの適当なパラメータのマップで初期化された行動定義を戻す規則を含む。規則の実行が終了した後、シナリオは戻された行動定義オブジェクトに実際の行動実現を検索させる。実行メソッドが行動の際に呼び出される時、それは初期化されたパラメータを使用してその仕事を達成する。この場合、仕事はメッセージを送信するために電子メール・サービスを呼び出すことである。
【００６５】
ＥＪＢ広告サービス
広告サービスは、システムの現在のユーザに基づいて広告を検索するための方法を提供する。それは、どの広告がどのユーザに表示されるべきかを管理する責任を持つ広告バケツ・サービス・セッション・ビーン及び内容管理サービスへのパススルーとして作用する下位レベルの広告サービス・セッション・ビーンからなる。
【００６６】
広告バケツ・サービス
広告バケツ・サービスは、広告内容をプレイスホルダーに与える状態の無いセッションＥＪＢである。これは、どのプレイスホルダーを目的としているか広告を見て、そして有効な広告の組を生成することにより行われる。そして、この組は、広告情報をサービスし更新するために実際の広告を取り出す広告衝突解決に送られる。これからの広告質問は実際の広告を選択するために広告サービスに送られる。もし、有効な広告が見つからなければ、グローバル広告バケツが広告を探すため検査される。広告バケツ・サービスはまた、ユーザ広告バケツに広告を追加するためのメソッドを提供する。普通、これはシナリオからのイベントが広告行動を実行する時に呼び出される。それはまた、キャンペーン状態を消去することができるインターフェイスを提供する。より一般的に、インターフェイスはシナリオ・コンテイナーの名前に基づいてユーザ・バケツからコンテントを除去する。キャンペーンはシナリオ・コンテイナーの１つの実現にすぎない。
【００６７】
広告情報
広告情報は、データベースに入力される情報のある小組を含むデータ構造である。ユーザ広告情報のためのデータベース・エントリイは以下を含むことができる。
ユーザ名――ユーザの名前、
プレイスホルダー名――広告が目的とするプレイスホルダーの名前、
シナリオ・コンテイナー名――広告を生成したシナリオ・コンテイナー（キャンペーン）の名前、
入力日付――広告が入力された日付／時間、
広告質問――広告のために実際のコンテントを生成するために広告サービスに送られる質問、
消滅日付――広告が消滅する日付、
重み付け――広告を選択するために使用される重み付け及びビュウー計数、
ビュウー計数――及び
シナリオ名――広告をキャンペーンに加えたシナリオの名前。
【００６８】
広告衝突解決
広告衝突解決は、ユーザに対して表示される「最良」の広告を選択する及びデータベース内の広告を更新する責任を持つ。このメソッドは表示する「最良」のものを選択するために広告の組にアルゴリズムを適用する。そして、このアルゴリズムに基づいて重み付け及びビュウー計数を更新する。
【００６９】
広告サービス
広告サービスは、ドキュメント・マネージャ・インターフェイスを実現してドキュメント・マネージャを代表する別途に配備された状態の無いセッションＥＪＢである。広告オブジェクトはドキュメント・マネージャ内に配備されたドキュメント・オブジェクトであってよい。
【００７０】
クリック・スルー・サーブレット
このサーブレットは、広告クリック・スルー・イベントを追跡するために使用される。広告バケツ・サービスからのコンテント出力は広告を包み、そして、それをこのサーブレットに向かわせる。クリック・スルー・サーブレットはユーザの広告上でのクリックを記憶するための中心場所である。これは、キャンペーン・イベントを立ち上げるであろう。サーブレットはユーザをクリック・スルー・イベントの処理後に目標ページにリダイレクトする。
【００７１】
ＥＪＢプレイスホルダー・サービス
プレイスホルダーは、コマース・サーバーによりコンテントを置くことができるＪＳＰページ内の指定された場所を表す。それは、プレイスホルダーＪＳＰタグにより表される。プレイスホルダー・タグの背後に、状態の無いセッションＥＪＢのプレイスホルダー・サービスがある。プレイスホルダー・サービスはコンテントをＪＳＰページに送り戻す責任を持つ。
【００７２】
コンテントは、コンテント・バケツ・インターフェイスを実現するコンテント処理ＥＪＢから検索される。コンテント処理はプレイスホルダーが定義される時に指定されたプレイスホルダーと共に登録される。
【００７３】
プレイスホルダー・タグ
プレイスホルダー・タグは、プレイスホルダー・サービスからのコンテントをＪＳＰタグ内に置くために使用される。プレイスホルダーは名前の付いた存在である。プレイスホルダー・タグは、次を含む４つの属性を定義する。名前−システム内のプレイスホルダーの名前、高さ−コンテントの選択的な高さ、幅−コンテントの選択的な幅、及び、描写−コンテント・バケツから出力されたコンテントをプレイスホルダー・タグにより送り戻す前に変形できる選択的な指定されたＥＪＢである。
【００７４】
プレイスホルダー・サービス
プレイスホルダー・サービスは、コンテントをプレイスホルダー・タグに戻すことを主な責任とする状態の無いセッションＥＪＢである。さらに、それはプレイスホルダーを定義するメソッド及びプレイスホルダーの質問のメソッドを提供する。質問メソッドはドロップ・ダウン・リスト等を生成するためにツールにより使用され。プレイスホルダー定義メソッドはシステムのために新しいプレイスホルダーを定義する。名前は独特でなければならず、コンテント・バケツ名はコンテント・バケツ・インターフェイスを定義するＥＪＢでなければならない。プレイスホルダーは、次の情報を含むデータベース・テーブル内で定義される。名前−プレイスホルダーについて独特な名前、タイプ−生成する現在バケツを表すＥＪＢの名前、及び、プレイスホルダーのためのコンテントである。
【００７５】
コンテント・バケツ
コンテント・バケツ・インターフェイスは、プレイスホルダー・サービスがコンテントを受け取るために使用するインターフェイスを定義する。このインターフェイスは、「バケツ」により実現される。割引バケツもまた、コンテント・バケツである。
【００７６】
コンテント変形
これは、コンテント・バケツ出力をプレイスホルダー・タグに送り戻す前に変形を実行する抽象ベース・クラスであり、システムがコンテント・バケツの出力に対してＸＳＬＴタイプの変形を実行する接続ポイントとして動作する。
【００７７】
ＥＪＢ電子メール・サービス
電子メール・サービス・セッション・ビーンは、電子メールを送信する能力を与えるための一般的なプラットホーム・レベル・サービスである。これは即時電子メール能力及び一括電子メール能力を与える。最も簡単な場合は、電子メールは送り先アドレス、件名、及びメッセージ文章を与えることで送信できる。デフォルトの送信元アドレスはサーバー構成で指定できる。
【００７８】
電子メール一括処理
電子メール・サービスはまた、後で送信されるべき電子メール組をバッチする能力を与える。キャンペーンの文脈中、これはユーザがイベントを生成する時に販売促進又は特別の売込みに関する電子メールを徐々に蓄積し、そして販売促進が開始する時にこれら全てを一度に送信するために使用できる。電子メールのバッチはストリング識別で識別できる。キャンペーンの文脈では、これはキャンペーンの名前であろう。各バッチは、開始日付前にバッチに加えられる電子メールは一括処理され、そしてある日付範囲内に加えられた電子メールは直ちに送信されるように、それが何時送信されるかを決定する日付又は可能なら日付範囲を持つ。
【００７９】
ＥＪＢキャンペーン・サービス
キャンペーン・サービスは、この書類でカバーされる最高レベルのサービスである。キャンペーンは目標を達成するために設計されたシナリオの広告主のついた組である。
【００８０】
キャンペーン・サービス・セッション・ビーン
キャンペーン・サービス・セッション・ビーンは、キャンペーンと残りのシステムとの間のインターフェイスである。それは、キャンペーンを構成するシナリオにより処理されるべきイベントを受け取ることができるように、イベント・リスナーを実現する。このセッション・ビーンは、ＸＭＬとして定義されたキャンペーンを検索し、新しいキャンペーンを配備するためのツールの機能を提供する。
【００８１】
キャンペーン・オブジェクト
キャンペーンは、シナリオの組及び開始と終了日などのキャンペーン自身に関するある情報を含む。
【００８２】
キャンペーン・ブーツストラップ
いくつかの実施の形態では、キャンペーンが配備された時又はサーバーが開始され時に実行されるブーツストラップ規則をキャンペーンは含んでも良い。このブーツストラップ規則は、キャンペーンのシナリオの１つにより認識されるイベントの引き金を引く必要なくユーザにキャンペーンのための広告内容を見せるために、グローバル広告バケツ内の場所エントリイのようなものを行うことができる。
【００８３】
キャンペーン定義の一部は、キャンペーンが活動的な時間範囲及び日付時間の組である。これらの範囲はまた、否定であることができる。例えば、１２月１８日から１２月２５日までの日付範囲で午前８時から午前１１時までの時間範囲で非活動的である。これは、これはキャンペーン自身が１２月１８日と２５日の間では活動的であるが、午前８時から午前１１時までの時間範囲はそうでないと考えるようにさせる。「現在活動的」のキャンペーンの呼び出しの最初の部分は、呼び出しが規則エンジンを実行することなく短絡できるようにするため、現在の日付／時間に対してこれらの日付範囲を検査する。
【００８４】
さらに、いくつかの実施の形態では、キャンペーンについて活動化規則を定義できる。活動化規則は、真又は偽のいずれかを戻すことができ、そして活動日付範囲が有効になった後で呼び出される。これはキャンペーンのシナリオに属する全ての規則組を実行する前に呼び出しを短絡する代替的なメソッドを提供する。活動化規則はまた、目標状態を検査するための規則を有しそれがもし満足されたならば偽を返すことにより、一旦、「目標」が満足されたらキャンペーンの実行を停止する方法を提供する。
【００８５】
イベントの受け取り
キャンペーンがキャンペーン・サービスを通じてイベントを受け取る時、それは最初にその開始及び終了日付範囲といずれの定義された時間範囲を見ることによりそれが活動的であるかを確認するために検査し、その後、多分その活動化規則を実行する。もし、いずれの検査においても失敗したならば、キャンペーンは非活動的であるとみなされ、そしてこれ以上は実行されない。もし、キャンペーンがそれが活動的であると決定すると、それはイベントをそのシナリオの各々に送り、彼等の全てが彼等の規則組を実行しそこから結果するどんな行動も実行することにより、イベントに作用することができるようにする。
【００８６】
キャンペーン後の消去
本発明の１つの実施の形態では、キャンペーン定義はまた、キャンペーンが配備されない時に実行される「消去規則」を含むことができる。これはキャンペーンにその実行時に生成された広告バケツ内の広告質問などのいずれの情報も削除するための機会を与える。シナリオ中の規則に似て、この規則は消去をするために実行できるゼロ又はそれ以上の行動オブジェクトを戻す。消去のための代替的な方法が使用できることは明らかである。
【００８７】
配備サービス
配備部品のインターフェイスは配備サーブレットである。これは、配備するデータを含んだＸＭＬのストリームを受け取り、そのストリームを適当なヘルパー・クラスへ配達する標準のサーブレットである。このサーブレットの構成情報は、ＸＭＬドキュメント・タイプを配備ヘルパー・インターフェイスにマッピングする情報を含む。サーブレットがＸＭＬデータ・ストリームを受信する時、ドキュメント・タイプを検査して、それを処理するために正しい配備ヘルパー実現を具体化する。各配備ヘルパー実現はＸＭＬストリームからのデータをどのようにして配備するかを知る。これは個別の部品により決まる。実際の配備を処理するためにセッション・ビーンを呼び出すことができ、又は、データをデータベース内に直接に入力することができる。
【００８８】
ＥＪＢイベント・サービス
キャンペーン及びシナリオは、潜在的な同期的なイベント処理を有し、追加的にＪＭＳを介して非同期的なイベント処理を有する要求を持つ。イベント特性組タイプでは、各特性組の名前がイベント・タイプに対応する。この機構は我々又は我々の顧客が新しいイベント・タイプを追加する時にエデイターが拡張できることを可能にする。次のイベント・タイプ及び特性組が支援されるが、本発明の範囲と精神の中で追加のイベント・タイプが支援できることは明らかである。
【００８９】

【００９０】
典型的な実現
以下に、本発明の１つの実施の形態による個性化システムの典型的な実現を説明する。本発明の精神と範囲内で代替的な実現が使用できることは明らかであろう。
【００９１】
図５は、シナリオ・サービスが名前又は探索パターンのいずれかを使用してどのようにシナリオにアクセスできるかを説明するシナリオ・サービスの１つの実現のモデルを示す。図５に示すように、シナリオ・サービスは、イベントを処理し、そして名前によりシナリオを見つける又は検索するための機構を有する。シナリオ・サービス１９０は、シナリオを名前、記述、分類名、長い記述、シナリオ規則組、又は、規則組名分類子により探索し又は格納するためのシナリオ・インターフェイス１９２を使用する。ＸＭＬインターフェイスはシナリオ・サービスがＸＭＬファイルからシナリオを読み出し及び修正されたシナリオをＸＭＬファイルに格納することを可能にする。シナリオ・コンテイナー・インターフェイス１９４はシナリオが活動的か否かどうかを特定するために使用される。
【００９２】
図６は、本発明の１つの実施の形態において、どのようにコンテント・マネージャがユーザにコンテントを提供するために使用されるかを示す図である。図６に示すように、コンテント・マネージャ２００は、コンテント・インターフェイス２０６を使用して、ドキュメント・マネージャ２０２及び広告サービス２０４からデータ入力を検索する。ドキュメント・インターフェイス２０８は、著者バージョン番号等のドキュメントに関する追加の情報を格納及び／又は編集することを可能にする。
【００９３】
図７は、イベントが発生した時に応答するために使用されるキャンペーン・サービスの１つの実現のモデルを示す。図７に示すように、キャンペーン・サービス２２０及びシナリオ・サービス１９０はコンテントの表示に使用するために、シナリオ・コンテイナー２２６へ情報を供給するキャンペーン・インターフェイス２２４を介して規則組からの情報を使用する。イベント・リスナー２２８は、発生したイベント（再ログイン、ページ・ヒット、クリック・スルー等）に関する情報をキャンペーン・サービス２２０による使用のためにキャンペーン・リスナー２３０へ供給する。キャンペーン・インターフェイス２２４は、シナリオ・インターフェイス１９２へアクセスするため規則に基づくシナリオ・リンク２３４及び規則情報２３２を使用する。
【００９４】
図８は、イベント２４２の通知を受け取るためにイベント・リスナー・インターフェイス２２８を使用するイベント・サービス２４０のモデルを示す。この情報はイベントがシステム及び現在のユーザに対して現在興味があるかを決定するため、キャンペーン・リスナー２３０により捕らえられる。１つの実現では、イベント・サービスは、監視される可能なイベントの決定を助けるためにユーザの振舞いに関する情報を使用する振舞い追跡リスナー２４４により修正できる。標準のシャバＪＭＳメソッド２４６がイベントを行動追跡リスナー２４４へ発行するために使用できる。
【００９５】
図９は、１つの実施の形態で、どのようにしてプレイスホルダー・タグがユーザの画面上にひき続いて表示するためのコンテントを検索するために使用できるかを示すライフサイクルを示す。図９に示すように、ユーザ画面上でプレイスホルダー・タグ又はＪＳＰタグ２５０が活動化される時、それはプレイスホルダー・サービスＥＪＢ２５２に対する呼び出しを生ずる。プレイスホルダー・サービスＥＪＢは次にプレイスホルダーの名前に基づいてコンテント・バケツ２５４に対する呼び出しを行い、その後にコンテントを得るための要求が続く。そして、このコンテントは典型的にユーザの画面上の表示としてユーザへ戻される。描写オブジェクトＥＪＢ２５６への選択的な要求が、コンテント・バケツの出力をユーザに表示するために戻す前に他のあるフォーマットに変形するために行うことができる。
【００９６】
図１０は、どのようにして管理及び編集ツール（グラフイカル・ユーザ・インターフェイスを含む）がキャンペーン及びシナリオを編集し、そしてユーザに対しウェブ・コンテント上のデータを引き続いて個性化する際に使用するためにキャンペーン・サービスにキャンペーンを配備するために使用されるかを示すライフサイクルを示す。図１０に示すように、ツール２６０は、キャンペーン・シナリオを直接に又はＧＵＩインターフェイスを介して編集するために使用でき、又は、キャンペーンを定義する新しいキャンペーンＸＭＬフイラーを生成するために使用できる。キャンペーンが成功的に構成された時、実際のキャンペーンを配備するために配備サーブレット２６２に対する要求が作られる。配備機能は、もし多数存在するならば、どの配備ヘルパー・タイプ２６４を使用するかを決定するために配備構成情報を使用する。そして、キャンペーンはキャンペーン・サービス２６６へ配備される。その後のいずれの時点で、キャンペーン２６８は自動的に又は手動的にブーツストラップ規則又はルーチンにより活動化でき、そしてシステムによりコンテントを個性化する際に使用できる。
【００９７】
図１１は、ユーザに広告を提供するために、プレイスホルダー・サービスＥＪＢ２５２が広告バケツＥＪＢ２８４、及び広告衝突解決ＥＪＢ２８６を使用するライフサイクルを示す。図１１に示すように、ユーザの現在情報、人物像、又はセッション及び広告プレイスホルダーに基づいてデータベースから広告の選択を得るため、広告バケツＥＪＢ２８４に対して「コンテントを得る」呼び出しが使用される。そして、システムはキャンペーン規則に基づいて無効な広告を削除して、ユーザへ通信するための有効な広告組を生成する。もし、必要ならば、広告衝突解決ＥＪＢ２８６が最高の優先度の広告を選ぶために使用される。そして、広告を得るメソッドは広告質問の結果に基づいて実際の広告を広告サービス２８８へ戻す。
【００９８】
図１２は、ユーザ３００がどのようにして特定の広告上でクリックする際にメソッドをクリック・スルー・サーブレット３０２へ送るかを示す、サーブレット・ライフサイクルを通したクリックを示す。クリック・スルー・サーブレットは、広告をサービスしたキャンペーンを探すキャンペーン・サービス２６６を使用する広告バケツ・サービス２８４に連絡して、そのキャンペーンのために適当なクリック・スルー・メソッドを呼び出す。そして、広告バケツ・サービスがクリック・スルーに基づいてユーザをリダイレクトするために使用される。
【００９９】
振舞い追跡
本発明のいくつかの実施の形態は、ウェブサイト上でユーザの行動を追跡し、及び、ウェブサイトコンテントを修正するためこの追跡情報を使用するのに特に有用である。ユーザのウェブサイトとの相互作用を追跡する目的のために、振舞い追跡システムが将来の分析のためこのデータを記憶するのに使用できる。一般化されたイベント機構は２つの大きな仕業を含む。
【０１００】
イベント・タイプは、切り離されて、そしてそれらが使用される文脈中の観点で定義されなければならない。表示イベントは一般ビュー、製品ビュー、及び広告ビューについて定義されなければならない。クリック・イベントにも同じことが真である。さらに、その他のイベントの定義も鋭くされて最終化されなければならない。
【０１０１】
イベント・サービスは、イベントのコンテントを機構から切り離すために一般化されなければならない。１つの実施の形態では、全てのイベントが単一のデータベース・テーブル内に格納される。単一のリスナーがイベント・サービスからイベントを受け取り、そしてそのイベントを単一のパーシスターに送る。単一のパーシスターがデータベースに格納されるＸＭＬストリングを生成するためにヘルパー・メソッドを呼び出す。そして、データは単一のデータベース・テーブルに格納される。
【０１０２】
追跡できるイベントは次を含む。
セッション開始イベント−どんなユーザのセッションの開始を記録する。ユーザがセッションにログインするためにユーザはログオンする必要がない。しかし、もし、ユーザがログオンした場合、彼等が前にログインした同じセッションＩＤを彼等は維持する。匿名のユーザはセッションＩＤを持つが、彼等がログオン（認証）するまではユーザＩＤを持たない。
セッション終了イベント−ユーザがログオンしたかどうかにかかわらず、いずれのユーザのセッションの終了を記録する。セッションの時間切れ又はユーザのログアウトのいずれかにより生成される。
セッション・ログイン・イベント−ユーザが認証されたことを表示する。我々はこの時点でユーザ・プロフアイル情報にアクセスすると仮定する。ユーザが前にログインした同じセッションＩＤが使用される。ユーザがログイン情報を供給した時に生成される。
ユーザ登録イベント−新しいユーザがサイトに登録したことを表す。ユーザが成功的に登録フォームを完成した時に生成される。
買物かごに加えるイベント−顧客が買物かごに製品を加える。顧客が彼等の買物かごに製品を加える時に生成される。
購入イベント−顧客が製品を購入する。顧客がチェックアウトに入るときに、製品ごとに１つ生成される。
買物かごから除去するイベント−顧客が買物かごから製品を除去する。顧客が彼等の買物かごから製品を除去する時に生成される。
規則イベント−規則が実行される。普通は、シナリオの文脈中で生成される（上述参照）。しかし、規則はシナリオと独立に実行してもよい。
コンテント表示イベント−キャンペーンとは独立に、画面にイメージが表示される。「タグ」が付けられたコンテントが表示される時に生成される。
クリック計数イベント−キャンペーンとは独立に、画面上のイメージがクリックされる。「タグ」が付けられたコンテントがクリックされる時に生成される。
製品表示イベント−製品が画面上に表示される。製品はキャンペーンに結び付けられていないことに注意する。「タグ」が付けられた製品が表示される時に生成される。
製品クリック・イベント−画面上の製品がクリックされる。「タグ」が付けられた製品がクリックされる時に生成される。
キャンペーン表示イベント−画面にキャンペーンに関連するイメージが表示される。シナリオはそれと関連した複数の表示を有するであろう。キャンペーン／シナリオがこの特定のコンテントがシナリオに関連があり、シナリオが活動的なときに表示されることを指定した時に生成される。
キャンペーン・クリック・イベント−キャンペーンに関連したイメージがクリックされる。シナリオはそれと関連した複数のクリック・イベントを有するであろう。キャンペーン／シナリオがこの特定のコンテントがシナリオに関連があると指定し、クリックされた時に生成される。
キャンペーン・ユーザ行動イベント−キャンペーンの文脈中でユーザの行動を捕まえるための一般的なイベント。ユーザに対して特定のキャンペーンが表示されたことを記録するために使用される。もし、キャンペーン表示イベント又はキャンペーン・クリック・イベントが無ければ使用される。
【０１０３】
図１３は、コンテント又はビジネス機能を個性化するためこのシステムにイベントを供給するのにどのようしてイベント・システムが使用できるかの１つの実現を示す。図１３に示すように、１つのイベント・サービス・ビーンがイベント３１２の通知を、１つのシステムの実施の形態では振舞い追跡又はリスナー・モジュール３１６を含む１つ又は複数のプラグ可能非同期リスナー３１４へ供給するために使用される。各リスナーはそれが聞くためのイベント・タイプのリストを持つ。振舞い追跡ＪＭＳリスナーがそのタイプ（例えば、ｆｏｏ）のイベントを受け取る時、それはイベント・タイプｆｏｏをリスナー上のｇｅｔＴｙｐｅｓ（）呼び出しから返されたストリング配列中にｆｏｏをリストする各リスナーへ送信する（この呼び出しは振舞い追跡ＪＭＳリスナーにより呼び出される）。ジャバ・メッセージング・サービス（ＪＭＳ）３１８が個別のイベント・メッセージをＪＭＳリスナー３２０及びプラグ可能非同期リスナー３２２へ配達するのに使用される。リスナーはＪＭＳの知識を持たない。例えば、リスナーの興味あるキャンペーン・イベントのみをプラグインするため、リスナーのクラス名が特性ファイル内に振舞い追跡リスナーとしてリストされていなければならない。リスナーは無効処理イベント（Ｅｖｅｎｔ ｅ）を実現しなければならず、そしてリスナーのＳｔｒｉｎｇ］ｇｅｔＴｙｐｅｓ（）呼び出しは、｛“クリック・キャンペーン・イベント”、“キャンペーン表示イベント”、“キャンペーン・ユーザ活動イベント”｝を含む配列を戻す必要がある。これらの３つのタイプの１つのイベントはリスナーの処理イベント（Ｅｖｅｎｔ ｅ）インターフェイスに到着して処理される。振舞い追跡ＪＭＳリスナーは、同期ＪＭＳ検知リスナーから送信されたイベントが送信ＪＭＳトピックにサブスクライブする。そして、それはイベントをあるタイプのイベントに興味を持つプラグ可能非同期リスナーへ送信する。イベントはキャッシュ３２４されてよく、そしとコンテントを生成する際に使用するためにデータベース（ＤＢＭＳ）３２６内に格納される。イベントをシステムに通信するための他の手段も使用できることは明らかである。
【０１０４】
イベント・テーブル
１つの実施の形態では、イベント追跡テーブル構造は全てのイベント・タイプからのデータを格納することを容易にする単一テーブルを使用する。テーブルのこの実施の形態は以下に示すように５つの列を含む。代替的な変更も使用できる。
・ＥＶＥＮＴ＿ＩＤ
・ＥＶＥＮＴ＿ＤＡＴＥ
・ＥＶＥＮＴ＿ＴＹＰＥ
・ＷＬＳ＿ＳＥＳＳＩＯＮ＿ＩＤ
・ＵＳＥＲ＿ＩＤ
・ＸＭＬ＿ＤＥＦＩＮＩＴＩＯＮ
【０１０５】
最初の５つの項目は獲得されてデータベース内に格納されるイベントの全てのタイプについて共通である。最後の項目、ＸＭＬ＿ＤＥＦＩＮＩＴＩＯＮ、はテーブルにＣＬＯＢとして格納されるＸＭＬドキュメントを表す。ＸＭＬ＿ＤＥＦＩＮＩＴＩＯＮは上記の最初の５つの項目及び全てのイベント・タイプ間で異なるイベント特有データを格納する。このＸＭＬドキュメントは各イベント・タイプに対して特別に生成される。
【０１０６】
管理用ツール及びエデイター
管理用ツール特徴は、いくつかの主な部品に分割できる。図１４は、管理者が規則及び／又はキャンペーン・シナリオ規則組を修正することを可能にし、そして本発明と共に使用できる例えば割引定義を含む行動タイプを編集することを可能にする管理用ツール組の１つの実現を示す。図１４に示すように、管理用ソフトウェアはツール・フレームワーク３３０として動作して、キャンペーン・エデイター３３２、シナリオ・エデイター３３４、規則エデイター３３６、及び割引定義エデイター３３８を含む。他の規則エデイターも必要ならば含むことができる。エデイターは、キャンペーン・モデル３４２、シナリオ・モデル３４４、規則モデル３４６、及び割引定義モデル３４８に関連したデータを含むシステム記憶場所３４０を修正するために使用される。記憶場所はサーバー側データベース３５０に、データを個性化エンジンの実行時間中に動的に更新することが可能なパーシステンス層３５２により接続されている。
【０１０７】
エデイター−管理者がキャンペーン、シナリオ、規則組、又は割引定義を作成するために相互作用する実際の道具、アイコン、及び他のＵＩ特徴。これは他のツール・フレームワークとは独立であり、エデイターをできる限り再使用可能に保つ。ツール・フレームワークは、ＵＩの内側の表示及び下位にあるオブジェクトの持続性を容易にするためモデルを作成して聞く。エデイターはまた、表示ひな型、利用可能な特性等のリストなど、外界からの情報を含んだ記憶場所オブジェクトにアクセスする。
【０１０８】
プレゼンテーション−どのようにキャンペーン、シナリオ、又は規則が管理者に対して判読及び理解できる形式で表示されるべきかに関する情報。プレゼンテーション・データはエデイターにより使用され、そしてシーンについて独特であることが可能である（又は、ビジネスについて等しく）。
【０１０９】
モデル−エデイターが「世界」と相互作用する方法。各エデイターのモデルは、データのＤＯＭなどそれが必要とするものをエデイターに与える。モデルはＤＯＭに関するイベントを聞き、そしてツール・フレームワークにより聞かれるそれ自身のイベントを実行するための適当な機構を持つ（例えば、記憶組を記憶する必要性を警告するため）。
【０１１０】
ツール・フレームワーク−特定のエデイターを収容するための環境下部構造。ツール・フレームワークは、キャンペーン、シナリオ、規則組、及び割引定義のリストを表示する。それはまた、ツールバー、メニュー、又は他の同様なインターフェイスによりエデイター（モデル及びパーシステンス層を介して）内に生成されたものの格納、ロード及び削除の処理をする。
【０１１１】
データ−実際の規則、シナリオ、キャンペーン、及び、ツール内で編集された構造物に関する情報。データのこれらの部分はＸＭＬから作成されたＤＯＭ（又は、複数のＤＯＭ）内に存在する。
【０１１２】
パーシステンス−データがどのようにしてモデル内にロードされ、そして、どのようにしてそれが生成又は編集後にエデイター内に格納されるか。
【０１１３】
規則エデイター
規則エデイターは、大部分の他の管理用ツールの基礎である。キャンペーン及びシナリオは規則（規則組内）から構成される。従って、シナリオ及びキャンペーン内で規則を編集するために、規則エデイターが使用されなければならない。
【０１１４】
規則組
規則エデイターが呼び出された時の「作業単位」が規則組である。規則組は、関連規則の集まりで、規則エンジンがそれらを一緒に使用できるように束ねられている。
【０１１５】
分類子
分類子規則組は、特別な場合である。分類（例えば、ユーザが多分「ゴールド会員」である事実）は、いずれのキャンペーン、シナリオ、又は規則で再使用される必要があり、再使用される全ての分類を格納するアプリケーション毎の単一の規則組は（我々の）人生を簡単にする。従って、分類子規則のみを含んだ特別な分類子規則組が存在する。分類子と分類の間の違いに注意する。分類子は、その右側が分類オブジェクトを主張する規則タイプである。例えば、分類子では、「もし、訪問者のふるさとの州がコロラドならば、訪問者をスキーヤーとして分類する」。分類「スキーヤー」は他の規則で再使用されるものである。（「もし、訪問者がスキーヤーならば、左広告ホルダーにベール広告を表示する。」）分類子規則は、他の規則内では使用されない。分類だけである。
【０１１６】
ＸＭＬ−＞ＨＴＭＬ様リーダー
モデルは、規則エデイターが開始された時に作業するための規則組ＤＯＭを規則エデイターに与える。規則組内の規則が選択される時、規則エデイターは規則組ＤＯＭ内に含まれる規則のデータ、及び、規則特性を示すのに必要なプレゼンテーション情報ＤＯＭを表示できなければならない。規則エデイターは、両ＤＯＭの情報をパラメータ化可能部分に対してハイパーリンクにより判読可能規則に変更できることが必要である。
【０１１７】
フレーズ・エデイター
ハイパーリンク（パラメータ化可能領域）が規則内でクリックされる時、プレゼンテーションＤＯＭはどのフレーズ・エデイターが開かれるかを知る必要がある。フレーズ・エデイターは規則内で使用するために特別な値を得るために使用されるダイアローグである。例えば、日付及び時間セレクター、又は、特性ピッカー。
【０１１８】
シナリオ・エデイター
シナリオ・エデイターは、ちょうど規則エデイターがするように規則組を編集する。これら２つの違いは、シナリオはひな型（例えば、「広告シナリオ」ひな型）から開始され、そしてシナリオはそれに関するメタデータを少し持つ（例えば、記述）。換言すると、シナリオ・エデイター内で使用される大部分の機能（規則）は、埋め込まれた規則エデイター内に入れ子構造される。シナリオは本質的に規則組及びいくらかのメタデータである。シナリオ・データはこのメタデータと規則組へのリンクを含む。シナリオ・データはまた、分類子規則内で生成された分類がシナリオの規則内で使用できるように、分類子規則組へのリンクも含む。
【０１１９】
キャンペーン・エデイター
キャンペーン・エデイターは、その中に複数のシナリオ及び開始と終了条件の規則組を持つことができる。また、広告主、記述などのキャンペーン・メタデータ及び探索情報（開始及び終了日付、等）がある。キャンペーン・エデイターは、シナリオを加え又は修正する時にシナリオ・エデイター及び規則エデイターを使用する。キャンペーン・データは、シナリオ、開始／終了条件規則組及び分類子規則組を含むその中で使用される各規則組へのリンクを持つ。
【０１２０】
割引定義エデイター
割引定義エデイターは、キャンペーン、シナリオ、及び、その規則エデイター内で生成された規則が割引定義エデイター内で生成された割引を参照できる規則エデイター（割引タイプ、規則）だけに関連する。
【０１２１】
プレゼンテーション
「もし、訪問者の性別が男なら、訪問者をビール飲みとして分類する。」などの分類子は、「性別」、「男」、「ビール飲み」などのデータのみならず、どのように分類子が表示されるべきか（「もし、訪問者の・・・」）に関するプレゼンテーション情報も有する。このプレゼンテーション情報は、異なるプレゼンテーションが異なる用途（ビジネス又は垂直マーケットための特定のプレゼンテーション又は異なるシーンなど）のためにプラグインできるように、エデイター自身の外側に格納される。
【０１２２】
設計
各エデイター（キャンペーン、シナリオ、規則、及び多分割引定義）に対して、どのようにプレゼンテーションＸＭＬがそのエデイターについて構成されなければならないかを決めるＸＭＬ設計が存在する。
【０１２３】
プレゼンテーションＸＭＬ
設計が与えられると、各エデイターはデフォルトのプレゼンテーションＸＭＬが必要である。これは規則（分類子、コンテント・セレクタ、プレイスホルダー・コンテント・セレクタ、電子メール送信、割引）の各タイプについての規則文章及びシナリオとキャンペーンについての表示情報（多分、メタデータ名のみ、多分、それ以上）を含む。
【０１２４】
モデル
各エデイターは、特定の種類のデータ及びプレゼンテーションＤＯＭ（キャンペーン、規則組等）をどのように処理するかを知っているが、必ずしもＤＯＭの全ての横断的な更新と他の活動をする必要はない。各エデイターは、エデイターに有用な方法を与え、「嫌な作業」の大部分を処理する関連したモデルを有する。
【０１２５】
便利なメソッド
各エデイターについてのモデルは、エデイターがＤＯＭからの値を得て設定するのに使用できる便利なメソッドを提供する。例えば、キャンペーン・モデルはキャンペーンから広告主を得るためにデータＤＯＭを横断するメソッド・ストリングｇｅｔＳｐｏｎｓｏｒ（）を提供する。
【０１２６】
イベント
各エデイター・モデルはまた、エデイターから実行されたイベントに基づいて、データを「汚す」ようなもの（格納ボタンが可能化されたことを意味する）をツール・フレームワークに知らせることがモデルの仕業とするため、イベント・リステイングと実行機構を提供する。
【０１２７】
記憶場所
各エデイターについてのモデルは、エデイターに関する情報の記憶場所を持つ。記憶場所はひな型リストなどの情報を含み、また、各エデイターに対するプレゼンテーションＤＯＭへの参照を保持する。
【０１２８】
ツール・フレームワーク
ツール・フレームワークは、ＧＵＩの外側層であり、さまざまなエデイターをその中に含む。ツール・フレームワークはキャンペーン、シナリオ、規則組、及び割引定義の表示の組を表示する責任を持つ。ツール・フレームワークはまた、格納、開く、及び探索（例えば、キャンペーン探索）の作業を実行する。ツール・フレームワークはエデイターと直接には通信しない。それは常にエデイター・モデルを通じて行われる。
【０１２９】
データ
言葉「データ」は、本明細書では管理者ユーザがツールを使用して生成、更新、又は使用しようとする情報をいう。データは、規則組、シナリオ、キャンペーン、又は割引定義であることができる。
【０１３０】
ひな型
ひな型の概念は、管理用ツールのキーである。各レベル（キャンペーン、シナリオ、規則、又は規則節）でひな型を提供することにより、ツールは管理者ユーザが彼等の行う必要があるものを生成することを大変容易にする。ひな型をプラグ可能にすることにより（新しいひな型を後で生成できる）、大きなパワーと柔軟性が提供される。
ひな型はシナリオ、キャンペーン、又は規則（又は規則節）のパラメータ化されていないバージョンである。ひな型は基本的な構造を提供するが、エデイターがひな型から出発したキャンペーン、シナリオ、又は規則を修正して管理者ユーザの望むものにすることを可能にする。例えば、ユーザは、電子メール・シナリオひな型から出発して、規則を追加及び除去して、製品を割引して電子メールを全く送信しないシナリオにすることができる。
【０１３１】
割引
本発明のいくつかの実施の形態は、例えば、ユーザがウェブ環境においてある顧客に割引を提供することを可能にする。これらの実施の形態では、全ての割引は独特な識別子を持つ。シナリオを通じて、割引をユーザに関連付けることが可能である。
【０１３２】
割引は、キャンペーン・サービス又は多分まだ配備されていない機能により、顧客へ拡張される金銭的な販売促進を行う販売促進機能性の部分である。割引は、割引を定義すること及びこれらの割引を注文又は買物かごコンテントに作用する価格サービスを通じて適用することを含む。特に、価格サービスは、顧客に対する金額的利益を最大にするために製品組について割引組を適用する。コマース・サービスにより提供される多くの他のサービスは割引機能と相互作用する。従って、これらのサービスに関していくつかの依存性と影響が存在する。
【０１３３】
顧客−コマース・サイトと相互作用するブラウザに基づいたユーザ。コマース・サイトと相互作用するコンピュータ・システムも含む。
開発者−コマース・サイトを開発、維持、構成、又は操作するどんな人についての総称。
コマース技術者、コマース管理者−ビジネス機能の管理に対して責任を有する高度のレベルの開発者。
割引ツール−割引を定義するためのツール。
【０１３４】
本発明の実施の形態は、顧客に対して割引を提供することを容易にするためコマース・サーバー内に配備されたソフトウェア要素を設ける。割引は全ての顧客に対して又は顧客の特定の階層に対して提供できる。割引は、常に有効であってよく、又は、割引が利用可能になる環境又は時を指定する条件を有してよい。いくつかの実施の形態では、システムは、製品のコスト又は特定の時間に特定の顧客に対する製品のコストを生成するために、特定の製品又は製品の組に対して割引を実行する動的価格サービスを含む。販売促進機能（製品カタログを通ずる以外の顧客への売込みの表示）は割引システムの外部であるが、動的価格サービスは販売促進機能を通じて作られた売込みを与えることができる。
【０１３５】
割引システムは、買物かご、カタログ、チェックアウト、及び注文管理システムとの依存性及び相互操作性を含む。システムはスタンドアロンとすることができ、又は、第三者開発者に対して彼等自身のカタログ及び注文システムの統合を与えることを可能にできる。ツールは割引定義を維持するために使用できる。
【０１３６】
割引定義は、主な２つの使用ケースを有する。第１は、開発者が割引構成システムとインターフェイスすることを含む。第２は、顧客がカタログ、買物かご、チェックアウトとインターフェイスし、そして価格サービスと間接的にインターフェイスすることを含む。第３の使用ケースは、開発者が特定されていない作業を実行するために価格サービスとインターフェイスする場合に存在する。
【０１３７】
本発明の実施の形態は、割引システムが販売促進システムを介して顧客へ表示された売込みを与えることを可能にする機構を提供する。この機構は、割引指示機構と呼ばれる。
【０１３８】
販売促進機能は、特定のユーザ割引がユーザに適用されるかどうか、ユーザ属性に基づいて全ての決定を行う。この決定がなされた後、販売促進機能は、割引指示機構をユーザ識別子及び割引識別子により更新する。この割引指示機構は、本明細書の残りで、顧客割引関連と呼ばれる。
【０１３９】
割引システムは、資格付与スタイルで目標の顧客に割引を与える。割引の資格付与の基本的前提は、割引定義が割引資格（資格項目）に必要な項目（及びどれだけの量）及び割引を受ける項目（目標項目）を記述することである。一般的に、資格項目は目標項目と同じであっても又は同じでなくてもよい。簡潔のため、１つの実施の形態では、資格及び目標項目は同じ項目の組であることを要求してよい。
【０１４０】
割引の適用は、オブジェクト（注文、買物かご等）の収集の文脈中で実行される。割引が収集に対して適用される時、割引定義と一致したオブジェクトの組が収集から取り出され、そして目標項目が割引定義ごとに割引かれる。割引が無くなるまで、プール内にオブジェクトが無くなるまで、又は、残りのオブジェクトの収集と一致する割引が無くなるまで、追加の割引が適用される。より詳細には、価格サービスが顧客の金額節約を最大にする態様で与えられたオブジェクトの収集に対して割引を適用する。
【０１４１】
割引システムは、販売割引を特定の製品項目又はカテゴリーと関連付けるための機構を提供する。販売割引は、どんな割引資格付与の前に適用できる。
【０１４２】
追加の特徴
本発明のさまざまな実施の形態により提供される追加の特徴は以下にリストされたものを含む。当業者には明らかなように、以下のリストは本発明の個性化システムと共に使用できるさまざまな特徴を示すために提供され、そして本発明の精神と範囲内で多くの修正と変形が明白である。
・履歴データ又は現在の実行データのいずれかに基づくキャンペーンの予想的なモデル化。
・キャンペーン／シナリオ・データ分析を直接にキャンペーン／シナリオ開発環境に戻して結びつける。
・シナリオ有効化規則：この規則は基礎シナリオ規則と同じ入力を取るが、その出力は真又は偽識別子である。真は、ユーザがそのシナリオに対して有効であり、そして通常のシナリオ規則が実行されるべきことを指示する。偽は、ユーザがそのシナリオに対して無効であり、何もそれ以上は発生しないことを指示する。
・広告スペース在庫及びスケジューリング（シナリオ使用による間接的なものを除く）。
・クロス・プレイスホルダー解決（すなわち、同じページ上の２つのプレイスホルダー）を含む高度の広告衝突解決。
・広告露出制限。
・返却電子メール処理。
・電子メール配達の確認と保証。
・電子メール受信。
【０１４３】
以上に本発明の説明が、説明目的のためになされた。本発明を開示された正確な形に限定する意図又は網羅的な説明の意図はない。明らかに、当業者には多くの修正と変形が明白である。実施の形態は本発明の原理とその実際的な応用を最良に説明し、これにより当業者がさまざまな実施の形態に対して考える特定の使用に適したさまざまな修正を持つ本発明を理解するために選ばれて記述された。本発明の範囲は特許請求の範囲とその均等物により定義されることを意図している。
【図面の簡単な説明】
【０１４４】
【図１】本発明の１つの実施の形態による規則に基づいて個性化するシステムを示す概略図。
【図２】本発明の１つの実施の形態による規則に基づいて個性化するシステムの動作を示す図。
【図３】本発明の１つの実施の形態によるシナリオ規則と行動プロセスのフローチャートを示す図。
【図４】本発明の１つの実施の形態によるキャンペーンのライフサイクルを示す概略図。
【図５】本発明の１つの実施の形態によるシナリオ・インターフェイスのモデルを示す図。
【図６】本発明の１つの実施の形態によるドキュメント・インターフェイスのモデルを示す図。
【図７】本発明の１つの実施の形態によるキャンペーン・サービスのモデルを示す図。
【図８】本発明の１つの実施の形態による振舞い追跡リスナーのモデルを示す図。
【図９】本発明の１つの実施の形態によるプレイスホルダー決定プロセスのライフサイクルを示す図。
【図１０】本発明の１つの実施の形態によるキャンペーン配備プロセスのライフサイクルを示す図。
【図１１】本発明の１つの実施の形態による広告サービス・プロセスのライフサイクルを示す図。
【図１２】本発明の１つの実施の形態によるクリック・スルー・サーブレット・プロセスのライフサイクルを示す図。
【図１３】本発明の１つの実施の形態によるイベント・サービス振舞い追跡リスナーを示す概略図。
【図１４】本発明の１つの実施の形態によるツール・フレームワークを示す概略図。
【図１５】本発明の１つの実施の形態によるツール・フレームワーク内のエデイター、データ、及びモデルの位置を示す概略図。

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