專利名稱：用于基于規(guī)則的萬維網(wǎng)方案與活動的系統(tǒng)與方法
技術(shù)領(lǐng)域：
本發(fā)明涉及在線的，尤其涉及萬維網(wǎng)驅(qū)動(Web-enabled)的系統(tǒng)，還有關(guān)用于為用戶或用戶組個性化應用的行為與內(nèi)容的方法。
背景技術(shù)：
在電子商務領(lǐng)域，存在要求企業(yè)能夠改造其產(chǎn)品與服務以更好地適應其客戶的需要與要求的需求。在企業(yè)對企業(yè)(B2B)與企業(yè)對消費者(B2C)領(lǐng)域都存在這種需求。這種改造企業(yè)服務的具體例子出現(xiàn)在個性化領(lǐng)域。個性化允許企業(yè)個性化或以其他方式定制其向特定客戶或客戶組所提供的東西。例如，在互聯(lián)網(wǎng)/萬維網(wǎng)環(huán)境下，B2C內(nèi)容提供商可能希望部署一網(wǎng)站，其中，對每位訪問該站點的單個的客戶或?qū)γ恳换谀承┨卣鞯目蛻纛愋停紝⒃摼W(wǎng)站的內(nèi)容個性化。這種基于萬維網(wǎng)的B2C提供商的例子包括在線目錄商品提供商；產(chǎn)品銷售商；新聞、媒體與娛樂提供商；以及信息或參考源。
隨著其業(yè)務成功變得越來越依賴于可靠的個性化服務，電子商務提供商對其個性化系統(tǒng)提出了更多的要求。普遍地要求一種個性化系統(tǒng)，其不僅能夠幫助提供商提供個性化的網(wǎng)站，而且允許電子商務提供商在一個源點上定制其所有業(yè)務功能—營銷、生產(chǎn)、分銷等等，以及更新這些功能所依賴的信息或數(shù)據(jù)，所有這些都是以迅速、可靠、并容易修改的方式進行，需要很少或不需要系統(tǒng)中斷時間。
用于個性化網(wǎng)站內(nèi)容的現(xiàn)有系統(tǒng)在本質(zhì)上主要是分析性的，并依賴于使用先前收集的數(shù)據(jù)，該使用數(shù)據(jù)的方式允許管理員基于對該數(shù)據(jù)的理解修改網(wǎng)站或電子商務應用。例如，來自如ATG與Broadbase等銷售商的個性化系統(tǒng)(這些銷售商主要提供在線分析處理(OLAP)系統(tǒng))，其依賴于商業(yè)提供商收集大量的數(shù)據(jù)，大到足以用分析方式(即統(tǒng)計方式)表示其目標人群，然后使用該數(shù)據(jù)以對該人群的子群個性化內(nèi)容?？梢杂脗鹘y(tǒng)機制收集數(shù)據(jù)，即通過標準市場調(diào)研工具，或者通過諸如保持客戶的先前使用歷史在線地收集數(shù)據(jù)。然而，在隨后分析并使用這些數(shù)據(jù)以允許管理員更新實際的內(nèi)容之前，這些數(shù)據(jù)一般存儲在庫中以備進一步分析。在這種方式中，數(shù)據(jù)不是被用來提供系統(tǒng)的實時個性化，或在運行時管理員易于修改的個性化。而是更多地使用該數(shù)據(jù)表示在較長時間段內(nèi)對一大批用戶的內(nèi)容改變。沒有人試圖在用戶或客戶的實際會話內(nèi)在單個用戶級上定制數(shù)據(jù)內(nèi)容。
隨著當今電子商務對實時更新個性化的用戶內(nèi)容、和/或可供產(chǎn)品與服務的需求的增長，對當應用運行、甚至當客戶在會話內(nèi)進行有效操作時，允許管理員迅速定制呈現(xiàn)給客戶的內(nèi)容的系統(tǒng)的需求也不斷增長。另外，允許自動實施這種修改的系統(tǒng)，即通過使用規(guī)則或某其他機制以改變在用戶會話內(nèi)向其呈現(xiàn)的內(nèi)容的系統(tǒng)，尤其有用。隨著最終用戶愈加成熟并向內(nèi)容提供商要求更高質(zhì)量的服務，以及隨著后端商業(yè)應用愈加復雜并靈活到能夠提供此類細致的內(nèi)容變化，對允許或支持向用戶提供實時個性化數(shù)據(jù)內(nèi)容的功能的系統(tǒng)的需求也不斷增長。能夠作到這一點并且同時在設(shè)置數(shù)據(jù)內(nèi)容與營銷活動時十分易于使用的系統(tǒng)尤其有用，這是因為這些系統(tǒng)允許管理員迅速地管理實際的內(nèi)容與規(guī)則，向用戶發(fā)送內(nèi)容時依靠該規(guī)則。

發(fā)明內(nèi)容
本發(fā)明提供一種系統(tǒng)與一種方法，用來允許電子商務提供商為每個客戶、客戶群或特定客戶類型定制或個性化其業(yè)務功能或內(nèi)容。一個簡單的網(wǎng)站個性化的例子，以使每個到訪客戶能夠看到也許略為不同的、為其特定需求定制的站點內(nèi)容。然而該系統(tǒng)同樣可用于任何能夠從個性化中受益的業(yè)務系統(tǒng)。此處所指的用戶或客戶可能是個人或任意其他實體，如另一個組織或公司。用戶訪問的業(yè)務功能可能不屬于在屏幕上顯示的那種類型，而可能是(例如)自動方式定單檢索、處理、與其他操作。本發(fā)明允許在處理過程中的任意步驟以及任意實體之間個性化應用行為與數(shù)據(jù)。
概括而言，本發(fā)明提供了一種個性化系統(tǒng)，其使用規(guī)則以裁定并表征客戶或客戶動作，然后基于這些規(guī)則的結(jié)果個性化業(yè)務功能，如數(shù)據(jù)通信或被顯示的頁。規(guī)則可能被用來生成方案(scenario)—表征客戶會話的潛在事件序列。方案可能形成活動(campaign)的基礎(chǔ)—可能的方案的集合，具有聯(lián)合起始時間與終止時間，其間客戶進行操作，并在其環(huán)境下基于該規(guī)則的系統(tǒng)作出其決定，并提供表征與個性化。
在一個實施例中，本發(fā)明提供了一種基于規(guī)則的系統(tǒng)，用來定制電子商務應用的內(nèi)容，該系統(tǒng)包括服務器，用來與規(guī)則引擎以及商業(yè)應用來往傳遞信息；具有多個規(guī)則的規(guī)則集，其中每條規(guī)則定義了潛在情況與相應動作；規(guī)則引擎，用來解析規(guī)則集的內(nèi)容，以對當前進程作出明智的決定，并確定動作。
在互聯(lián)網(wǎng)和/或網(wǎng)站的環(huán)境中，本發(fā)明的實施例可以被用來基于網(wǎng)站用戶的會話信息向其展示個性化的內(nèi)容。在這類實施例中，用戶使用的萬維網(wǎng)應用可能是諸如商業(yè)網(wǎng)站應用，如在線預定系統(tǒng)(例如航班定座)或目錄產(chǎn)品訂購。當用戶登錄進入此類應用時，生成會話，并且發(fā)生與該會話相應的事件。這些事件被用來驅(qū)動基于規(guī)則的引擎，該引擎隨后被用來驅(qū)動內(nèi)容的提供?？梢愿鶕?jù)用戶特征集作出有關(guān)該用戶特征集的推論，然后可以就該特征集運行規(guī)則，所有這些都在實時進行，并且不需要參照輔助的個性化源，如統(tǒng)計的或市場信息的庫。


圖1示出根據(jù)本發(fā)明實施例的基于規(guī)則的個性化系統(tǒng)的示意圖。
圖2示出根據(jù)本發(fā)明實施例的基于規(guī)則的個性化系統(tǒng)的運行的圖例。
圖3示出根據(jù)本發(fā)明實施例的方案規(guī)則與動作過程的流程圖。
圖4示出根據(jù)本發(fā)明實施例的活動生命周期的示意圖。
圖5示出根據(jù)本發(fā)明實施例的方案接口的模型。
圖6示出根據(jù)本發(fā)明實施例的文件接口的模型。
圖7示出根據(jù)本發(fā)明實施例的活動服務的模型。
圖8示出根據(jù)本發(fā)明實施例的行為跟蹤監(jiān)聽器的模型。
圖9示出根據(jù)本發(fā)明實施例的占位符確定過程的生命周期圖。
圖10示出根據(jù)本發(fā)明實施例的活動部署過程的生命周期圖。
圖11示出根據(jù)本發(fā)明實施例的廣告服務過程的生命周期圖。
圖12示出根據(jù)本發(fā)明實施例的點擊進入Servlet過程的生命周期圖。
圖13示出根據(jù)本發(fā)明實施例的事件服務行為跟蹤監(jiān)聽器的示意圖。
圖14示出根據(jù)本發(fā)明實施例的工具框架的示意圖。
圖15示出根據(jù)本發(fā)明實施例的編輯器、數(shù)據(jù)、以及工具框架內(nèi)的模型所處位置的示意圖。
具體實施例方式
在描述本發(fā)明時將用到下列術(shù)語表與名詞、縮寫、與簡稱的定義。
B2B 企業(yè)到企業(yè)(Business to Business)B2C 企業(yè)到消費者(Business to Consumer)CMS 內(nèi)容管理服務(Content Management Service)DASLDAV搜索與定位(DAV Searching and Locating)(IETF草案)DMS 文件管理系統(tǒng)(Document Management System)DTD 文件類型定義(Document Type Definition)(用XML)EJB 企業(yè)JavaBeans(Enterprise JavaBeans)。服務器組件體系，用于寫Java服務器組件。
FIFO先進先出(First In，F(xiàn)irst Out)I18N國際化(Internationalization)J2EEJava 2企業(yè)版(Java 2 Enterprise Edition)JSP JavaServer頁(JavaServer Pages)。J2EE組件，用于生成動態(tài)網(wǎng)頁內(nèi)容。
JNDIJava目錄與命名接口(Java Directory and Naming Interface)。協(xié)議標準，用于查找對象與資源。
OOTB拿來即用(Out Of The Box)RDBMS關(guān)系型數(shù)據(jù)庫管理系統(tǒng)(Relational Database ManagementSystem)SPI服務提供者接口(Service Provider Interface)
TagLib JSP標記庫，包含JSP標記定義。
WLS WebLogic服務器UUP 統(tǒng)一用戶特征集(Unified User Profile)XML 可擴展標記語言(Extensible Markup Language)本發(fā)明提供了一種基于規(guī)則的實時個性化引擎，可用來個性化并定制業(yè)務功能、應用或待交付客戶或系統(tǒng)用戶的信息內(nèi)容。在本發(fā)明中，客戶或用戶可能是個人，如網(wǎng)站的個人用戶，或者可能是另一組織，其使用交互式的或自動的機制來與系統(tǒng)通信。在用戶與系統(tǒng)交互時，生成事件，所生成事件用來驅(qū)動基于規(guī)則的引擎。按照所使用的特定規(guī)則，個性化引擎實時地確定應該向用戶傳送那些內(nèi)容或信息。例如，此內(nèi)容可能是用戶在網(wǎng)站顯示上所看到的特定信息，或者可能是某種其他數(shù)據(jù)通信形式，例如，被自動傳送給無線應用協(xié)議(Wireless Application Protocol，WAP)設(shè)備或個人數(shù)字助理(Personal Digital Assistant，PDA)設(shè)備的數(shù)據(jù)，用戶未必看到該數(shù)據(jù)。根據(jù)本發(fā)明的一個實施例，用XML文件配置該基于規(guī)則的引擎的工作，這樣便使管理員只需編輯XML文件的文本便能夠迅速并且容易地改變該基于規(guī)則的引擎的運行。因為該基于規(guī)則的引擎可被用來控制業(yè)務功能，而不單單只是數(shù)據(jù)在屏幕上的顯示，所以本發(fā)明為各組織提供了為每個客戶或客戶類型個性化其業(yè)務功能的能力。
該個性化系統(tǒng)的操作通過使用活動與方案而得到簡化。在本發(fā)明中，方案是事件集合，事件引起某特定規(guī)則被觸發(fā)并且引起相應的動作、業(yè)務功能或數(shù)據(jù)被顯示?；顒涌赡馨ㄔS多方案，并提供了一套簡單機制，通過這套機制，管理員能夠控制整個方案集合，以最恰當?shù)胤从程囟ㄓ脩艋蛴脩艚M的需求。
圖1就個性化系統(tǒng)可以用于本發(fā)明的一個實施例，即向用戶提供個性化的內(nèi)容(例如在網(wǎng)站的情況中)，示出了個性化系統(tǒng)的概括示意圖。如圖1所示，規(guī)則引擎102解釋定義方案110與活動112的規(guī)則，以選擇特定的方案與活動設(shè)置集合，用于向用戶顯示內(nèi)容。方案118與活動120可以被存儲，以被將來需要時激活。規(guī)則被用來定義規(guī)則引擎102(和可選分離的方案引擎104與活動引擎106，盡管將清楚這后兩個引擎的功能可以由規(guī)則引擎102獨自承擔)的操作，并具體地告訴規(guī)則引擎在選擇與生成用于向用戶116的顯示114時應該使用各種方案與活動之中的哪個方案與哪個活動。
基于規(guī)則的引擎本發(fā)明的中心部件是基于規(guī)則的引擎。該基于規(guī)則的引擎使用規(guī)則，以對當前進程作出明智的決定，并確定此后的動作。每條規(guī)則都定義了情況(“如果”子句)與動作(“那么”子句)。使用這類規(guī)則就可以將情況與動作以流程圖的方式鏈接成方案。規(guī)則存儲在一個規(guī)則集或多個規(guī)則集內(nèi)。在本發(fā)明中，規(guī)則集指相關(guān)規(guī)則的匯集，這些規(guī)則捆綁在一起以便規(guī)則引擎可以將其一起使用。規(guī)則集與規(guī)則被用來指導方案與活動中事件的流動。
根據(jù)本發(fā)明的一個實施例，可以以XML格式書寫規(guī)則以便于在系統(tǒng)間的可移植性。另外，XML模式可以被實時解析，這便允許對規(guī)則(以及業(yè)務工作流)的實時修改，而不要求系統(tǒng)中斷時間。還有，因為用戶特征或特征集可以由一系列規(guī)則計算，所以系統(tǒng)提供了一套機制，通過這套機制，可以在被要求時生成用戶的實時“快速印象(snapshort)”，并將其用來向該用戶提供個性化內(nèi)容或服務。
方案方案是情況與動作鏈。方案描述了與用戶之間可能的交互的流程圖?；顒邮褂眠@類方案的集合，以為主辦者達到業(yè)務目標，或者處理特定的業(yè)務功能。在網(wǎng)站或類似B2C的情況中，活動可以通過方案使用在線廣告、電子郵件、與打折促銷，以得到該目標。
方案代表抽象功能。然而，在活動中所使用的方案可能建立于任意企業(yè)到企業(yè)、企業(yè)到消費者、或電子商務平臺(如BEA Systems的一系列WebLogic應用服務器商業(yè)服務器產(chǎn)品)之上。
根據(jù)一個實施例，方案被單獨命名，并且具有類別列表，其對每一方案有效。通過方案引擎，基于諸如名稱、描述或類別類型等準則搜索特定方案。該搜索可能包括全字匹配與模式匹配(如類‘*superbowl*’的表示)二者。搜索結(jié)果是匹配該搜索的方案的名稱。在實時交付內(nèi)容時，系統(tǒng)可以將當前情況與共享方案迅速匹配，并據(jù)此作出反應。
方案引擎作為方案定義庫。方案定義可能以XML格式存儲，以便于編輯，但也可能使用其他格式。方案引擎還能夠按名稱返回方案的XML定義，并且能在給出方案定義時部署方案。
方案由規(guī)則集構(gòu)成，規(guī)則集具有其組成規(guī)則。每條規(guī)則定義了情況(“如果”子句)與動作(“那么”子句)。使用規(guī)則就可以將情況與動作以流程圖的方式鏈接成方案。
方案規(guī)則集的可能輸入(那些“如果”)包括，但不限于用戶個人屬性；執(zhí)行類別規(guī)則集合的結(jié)果；用戶當前會話與請求信息(這可能包括(例如)用戶的購物車(ShoppingCart)或其頁位置)；在會話中發(fā)生的事件；當前時間；或，隨機數(shù)(以允許系統(tǒng)進行基于概率的運算)。
使用方案規(guī)則編輯器，系統(tǒng)用戶(例如，一般為系統(tǒng)管理員)能夠為任意輸入編寫定制規(guī)則，包括(例如)用戶特征集，用戶會話的內(nèi)容(具體為用戶的購物車)，用戶當前請求信息(瀏覽器類型、頁位置等等)，特定用戶歷史事件(如購物歷史)，事件的類型、頭部、或主體(在TextMessage中文本主體等等)。規(guī)則集的可能輸出(“項目”)包括動作定義—待執(zhí)行的(ActionDef)—即系統(tǒng)為響應輸入而必須實施的一個或多個動作。這可能包括交付特定內(nèi)容類型。
方案只對特定用戶類別(即客戶分組)有效。
規(guī)則引擎自身并不執(zhí)行任何功能(即其不生成動作，如投寄事件等等)。而是從規(guī)則引擎?zhèn)魉娃q識對象給方案引擎，然后方案引擎根據(jù)其方案庫執(zhí)行所請求的動作。
在一般使用中，對規(guī)則的估算將聲明動作定義(ActionDef)。該動作將導致發(fā)生某事，或向用戶顯示某物。用戶將作產(chǎn)生事件的某事。該事件被送給方案引擎，重復此循環(huán)直到(可能)達到終止狀態(tài)。
活動活動是有發(fā)起者的方案集合，被設(shè)計用來達到特定目標。在營銷的情況中，活動可能被設(shè)計來在特定時間段內(nèi)促銷某類商品。其他活動更概括一些，因為其只包括該公司或組織當前想實施的(一般相關(guān)的)方案的集合。每個活動都與一個或多個方案相關(guān)聯(lián)?；顒涌杀粯擞洖橛行Щ驘o效，并且一般有指定的開始與停止事件。通過活動引擎，能夠基于如名稱、開始和/或停止事件、類別(通過與方案的關(guān)系)、發(fā)起者名稱、描述、價值提議、目標描述與有效狀態(tài)等準則搜索活動。
該搜索可能包括全字匹配與模式匹配(如類似‘*superbowl*’的表示)二者。搜索結(jié)果是匹配該搜索的活動的名稱。然后，與此活動相關(guān)的方案就可以通過在方案引擎上的搜索檢索。
活動引擎作為活動定義庫。如同方案定義，活動定義可能以XML格式存儲。活動引擎還能夠按名稱返回活動的XML定義，并且能在給出活動定義時部署活動。
圖2示出根據(jù)本發(fā)明的實施例如何將活動方案與規(guī)則一起使用，以提供一套個性化系統(tǒng)。如圖2所示，事件服務130用來接收特定事件，并向活動事件監(jiān)聽器130發(fā)送該事件的通知。事件是用來在規(guī)則引擎內(nèi)觸發(fā)實時改變的驅(qū)動力量，規(guī)則引擎再確定給用戶的輸出。例如，事件可能是用戶登入事件，或在萬維網(wǎng)應用的情況中，為來自用戶的選擇特定頁或提交特定類型表的請求。事件不必一定觸發(fā)規(guī)則使其生效，這是因為事件服務可以有意忽略某些事件?；顒邮录O(jiān)聽器132也可以用來過濾特定事件類型，將該事件送往活動服務134以進一步處理?；顒臃?34加載當前有效的活動，即那些管理員指定的或當前在位的活動。如果其接收的事件來自某特定活動，則活動服務加載該活動。然后其使用該活動信息以建立活動方案標識的映射集，并將此信息送往方案服務136。方案服務136作為活動服務134的子集，并被用來過濾用戶已到達終止狀態(tài)的方案。如果用戶已到達終止狀態(tài)，則意味著系統(tǒng)一方不需再做其他工作，并且用戶負責確定下一步。然而，如果用戶還未到達終止狀態(tài)，則方案服務循環(huán)，以確定該事件類型對現(xiàn)行的特定方案規(guī)則集合是否有效。如果無效，則可忽略該方案。如果需要其他客戶分組，則方案服務也可用來執(zhí)行類別規(guī)則集。方案服務還可能被用來執(zhí)行方案規(guī)則集，并得到動作定義列表。為進行這種處理，方案服務136使用來自規(guī)則管理器138的規(guī)則，以確定對該特定方案的現(xiàn)行規(guī)則。一般每條規(guī)則都指定至少一個或多個動作定義。對每個方案的每個動作定義，方案服務都從動作服務140取得動作對象。在其運行每個動作對象時，依賴于實際的實現(xiàn)，可能發(fā)生不同的事件。例如，如圖2所示，這些事件可能驅(qū)動的動作如終止方案動作142，其使用方案服務144來為該活動方案的用戶設(shè)置終止狀態(tài)；廣告占位符動作146，其使用廣告桶服務148來向用戶桶中放入廣告查詢；郵件動作149，其使用郵件服務150來將給用戶的郵件打包以備將來發(fā)送；以及提供折扣動作152，其使用折扣關(guān)聯(lián)管理器154來在其會話上向用戶提供折扣。雖然圖2所示的例子示出了本發(fā)明所能提供的多種特征與服務，但本領(lǐng)域的技術(shù)人員應該清楚所示的事件例子并非窮盡，而只是例示了本發(fā)明可以使用的事件、方案與服務的類型。應該清楚，可以添加其他事件、方案與適當?shù)姆疹愋?，以最適當?shù)貪M足特定組織或電子商務應用的需求。
圖3示出可用于本發(fā)明的一個實施例的典型過程的流程圖，該實施例向系統(tǒng)客戶或用戶提供實時的個性化內(nèi)容。如圖3所示，在步驟160，規(guī)則引擎一旦被啟動，則確定在該情況下使用的特定規(guī)則組。在步驟162，使用“如果...那么...”子句計算規(guī)則，其中系統(tǒng)讀入用戶會話的當前狀態(tài)，即“如果”部分，并從潛在方案集合中確定輸出應該是什么。在步驟164，該輸出被聲明為動作定義，其確定系統(tǒng)在該特定情景下應該如何響應該特定用戶，即應該采用什么動作。在步驟166，該輸出(如果有的話)作為結(jié)果向用戶顯示。以后將清楚，系統(tǒng)可能決定采用不同于實現(xiàn)顯示的動作，而是傳送數(shù)據(jù)或以其他方式改變某業(yè)務功能或應用。在步驟166，在隨后的任意時間點上，如果用戶通過其動作引起另外事件的發(fā)生，則在步驟170，該事件被送往方案引擎(或如果使用單一引擎，規(guī)則引擎標識)。在步驟172，方案引擎將信息續(xù)傳回規(guī)則引擎，以備隨后的規(guī)則確定時使用，其將確定該系統(tǒng)應該如何響應隨后的事件。
活動目標與激活活動可以兩種方式使用目標。第一，目標是可被用來更清楚地闡明活動目的的文本描述。第二，目標是活動所能達到的定量尺度。根據(jù)一個實施例，所有活動都有是否有效(is-active)規(guī)則，其接收以下輸入活動數(shù)據(jù)對象；對廣告接觸(ad exposure)與點擊次數(shù)的訪問；事件；以及，當前日期與時間。
該是否有效規(guī)則的輸出為真或假。真表示此活動當前有效。假表示其無效，并且將不會有另外的處理發(fā)生。存在滅活活動的機制，不管活動的激活準則如何，管理員總能激活或滅活該活動。在計算激活或方案規(guī)則前，首先檢查該狀態(tài)。另外，活動可以有開始與停止時間，其確定活動的有效狀態(tài)。
活動生命周期圖4示出將活動添加到運行環(huán)境中或從其中移除的過程。首先必須啟動活動180。這一般發(fā)生在活動被第一次部署時，然而可以推遲啟動，直至發(fā)生手動過程。本發(fā)明的某些實施例允許指明逐個方案的啟動規(guī)則。在啟動時，觸發(fā)該活動的這些逐個方案的啟動規(guī)則。輸入為活動數(shù)據(jù)對象與當前時間，輸出為待執(zhí)行的動作定義(ActionDefs)。
在活動確實被啟動后，隨后變?yōu)橛行?82，這一般基于活動的開始時間，或顯式地標記該活動為有效活動。在第一次成為有效后的任何時間，由于到達活動的預定停止時間，或者達到了活動的目標(即“如果...則是否有效”規(guī)則)，或者管理員滅活該活動，該活動都可以變?yōu)榛虮粯耸緸闊o效184。在被滅活后，在某些情況下，該活動可以再次變?yōu)橛行?，這一般是通過管理員對其修改、重新部署并將其標示為有效。
在某些實施例中，在啟動后的任何時間，活動也可以被關(guān)閉186。這一般是由管理員進行的手動過程。在關(guān)閉時，執(zhí)行所有的逐個方案的關(guān)閉規(guī)則。對這些規(guī)則的輸入為活動數(shù)據(jù)對象與當前時間。輸出應該是活動引擎所要執(zhí)行的活動定義(ActionDefs)。這些活動一般撤消源自啟動規(guī)則的所有活動，盡管沒有要求必須這樣作。
活動被關(guān)閉后，其被清除188。這涉及移除所有活動相關(guān)數(shù)據(jù)(如廣告接觸計數(shù)、方案狀態(tài)信息等等)。這也可能涉及將活動定義從活動引擎庫中移除。
報告/分析活動由事件驅(qū)動。另外，廣告接觸與點擊進入(click-through)計數(shù)由活動服務維護以備活動使用。這些也可以被訪問，以備報告使用。
動作服務動作服務將動作的概念抽象化，動作應該由方案引擎根據(jù)規(guī)則集的結(jié)果執(zhí)行。這就允許規(guī)則聲明具體動作的一般化定義。該動作定義(ActionDef)可用來取得對能執(zhí)行其下動作的對象的訪問。這樣不用重新啟動服務器，新動作就可以被生成并被部署。這樣作的一種途徑是部署會話EJB(SessionEJB)，其可以提供具體動作對象。
方案工具可使用動作庫。在一個實施例中，該動作庫可用XML文件描述。方案工具使用動作庫以向用戶動態(tài)顯示動作，并且從用戶收集該動作的所有參數(shù)。為活動預先定義的動作集合可以包括如下在用戶或全局占位符中放入廣告組(查詢)與權(quán)重。
從用戶或全局占位符中移除廣告組(查詢)。
向用戶提供有名折扣。
從具有主題的URI生成給用戶的電子郵件。
占位符占位符(Placeholders)表示在JSP中的位置。占位符的行為取決于具體系統(tǒng)的配置。這與方案的動作概念十分相似。然而，占位符的動作主要由請求驅(qū)動，而不是由事件驅(qū)動。在一般實現(xiàn)中，于網(wǎng)頁上的請求來自于包含占位符JSP標記的JSP頁的網(wǎng)絡用戶。該標記聯(lián)系會話EJB，該會話EJB將返回描述應該發(fā)生的行為的對象。該行為可能是可顯示的單元。在可顯示單元的情況中，該可顯示單元將包括表達器(renderer)對象，該對象知道如何顯示該單元。
廣告占位符(Ad Placeholders)在那些將該發(fā)明用于廣告生成的環(huán)境中，可將占位符用于顯示廣告。對于顯示廣告的占位符行為，使用用于占位符的用戶廣告桶(bucket)。該廣告桶包含應該向用戶顯示的廣告集合或廣告組，再加基于桶項的查看計數(shù)。桶中每一項具有下列信息用戶名稱；占位符名稱；輸入的日期與時間；廣告查詢(定義了待顯示廣告或廣告組)；權(quán)重；查看計數(shù)；活動名稱；方案名稱。
在某些實現(xiàn)中，對每一個占位符都可能有一未綁定到具體用戶的廣告桶(即全局用戶桶)。除此之外，桶中的每一項將具有相同信息。
因為廣告桶可能從占位符請求(即由活動/方案引擎)外部填充，所以可以使用廣告桶沖突解決機制。該沖突解決機制確定在用戶的廣告桶中哪項被真正使用，以找到待顯示的廣告。在一個實施例中，使用有效桶項的權(quán)重。如果桶項的相應活動當前有效或者未與活動關(guān)聯(lián)，則該桶項有效。一單一項的權(quán)重使其被查看的可能性為(權(quán)重*100/所有權(quán)重之和)。使用隨機數(shù)來確定使用哪個桶項。例如，如果桶中有四項，權(quán)重為1、2、3、4，則其安排可能為(例如)項 權(quán)重公式被使用的可能性(％)廣告1 1 (1*100)/(1+2+3+4) 10％廣告2 2 (2*100)/(1+2+3+4) 20％廣告3 3 (3*100)/(1+2+3+4) 30％廣告4 4 (4*100)/(1+2+3+4) 40％
一旦確定了項，則執(zhí)行該項的查詢以產(chǎn)生廣告集合(即廣告組)。組中的每一廣告都將有自己的權(quán)重。采用類似的算法確定使用組中的哪個廣告。如果發(fā)生某事使廣告組的大小為零，則系統(tǒng)選擇使用新桶項，而忽略先前選擇的桶項。如果不存在用戶桶項，則用類似方式檢查全局用戶桶。一般全局用戶桶通過活動啟動規(guī)則填充。
在本發(fā)明的一個用于具有廣告的網(wǎng)站的實施例中，向用戶顯示特定廣告可以生成事件，對廣告的點擊進入也會可以生成事件。在兩種情況中，將該廣告放入廣告桶中的活動與方案的標識都與該事件一起被傳送。這就使系統(tǒng)將“看到”與“點擊進入”事件反向綁定到廣告與活動兩者之上，以備隨后的分析與報告目的。
廣告服務廣告服務提供廣告元數(shù)據(jù)與內(nèi)容，以備隨后向用戶顯示。該服務能基于廣告的唯一標識符或基于對廣告元數(shù)據(jù)的搜索檢索該廣告。廣告可能包括(例如)具有可選點擊進入的URL的單一圖像、替換文本、邊界規(guī)范、寬度、高度、鼠標懸停文本；HTML文本塊(其可能包括點擊進入的URL)、再加該HTML塊引用的任何補充媒體；或者對嵌入JSP頁的引用。
所有廣告都有相關(guān)的相對權(quán)重，該相對權(quán)重可能是整數(shù)。特定廣告的權(quán)重可用來解決廣告顯示沖突。
在一個實施例中，廣告服務記錄廣告后印象(following ad impression)(用戶看到了什么)，以及逐個廣告的點擊進入事件計數(shù)全局計數(shù)；與逐個活動計數(shù)。
該信息用來處理活動目標評估。另外其還可用于報告。逐個用戶的廣告計數(shù)可通過事件服務處理。
在某些實施例中，可能有機制來查詢廣告服務以查看、增大、以及減小這些計數(shù)。這些信息隨后立刻被活動或方案引擎使用，因此這些信息必須在以上細節(jié)水平上可檢索。
電子郵件服務電子郵件服務可用來支持基于電子郵件的活動?；陔娮余]件的活動允許系統(tǒng)將個性化的電子郵件內(nèi)容指向用戶或用戶組。在一個實施例中，電子郵件服務基于配置支持兩種運行模式批量模式或通過模式。通過模式使該服務立刻發(fā)送電子郵件請求。批量模式使該服務將電子郵件請求存儲于數(shù)據(jù)庫，可以在以后的時間從該數(shù)據(jù)庫發(fā)送該請求?？梢允褂霉芾韱T界面或命令行程序以啟動打包的電子郵件。電子郵件服務所要求的信息為標準電子郵件頭部信息(如，To，F(xiàn)rom，Subject)，MIME電子郵件頭部信息(如Content-Type，Content-Length，Content-Disposition，其中某些可能從電子郵件主體確定)，電子郵件主體，發(fā)起電子郵件的活動與方案的標識，以及電子郵件多長時間有效(即，如果5天內(nèi)還沒有發(fā)送，則不用再管)。
活動與方案的部署在活動與方案運行前，必須將其部署到服務器上。在一個實施例中，可以使用能夠?qū)ML定義傳送給適當部署服務的Servlet(小服務程序)。
活動與方案服務從XML文件取得輸入，而這些XML文件可以由管理員工具集生成。使用了用于活動與方案定義的模式，也使用了用于方案規(guī)則的模式。
管理員可以使用這些管理工具來產(chǎn)生并部署活動與方案定義。這些工具生成表示這些定義的XML文件，并通過部署器Servlet部署這些新定義。該Servlet接收XML數(shù)據(jù)流，并調(diào)用適當?shù)姆找蕴幚碓摂?shù)據(jù)?；顒?、方案、及其相關(guān)規(guī)則可以分別部署。一般先部署規(guī)則，隨后是使用它們的方案，最后是由方案構(gòu)成的活動。當部署活動或方案時，相關(guān)服務將XML定義保存在中心數(shù)據(jù)庫或庫中。
EJB實現(xiàn)以上描述的服務可以作為無狀態(tài)服務集合實現(xiàn)—在一個實施例中，例如，作為一組符合EJB規(guī)范的無狀態(tài)會話Bean。下面各節(jié)詳細描述本發(fā)明的實施例，其使用EJB的以提供支持方案與活動所必須的服務與功能。將會清楚可以使用其他類型的資源，以替代或補充EJB。
方案服務(Scenario Service)方案服務被設(shè)計用來允許系統(tǒng)與用戶間的交互流程被定義為規(guī)則與動作集合。
方案會話Bean(Scenario Session Bean)方案會話Bean為方案功能的外部接口。當由方案服務收到事件時，其確定系統(tǒng)中是否有任何方案應該相應該事件。如果有，則該服務將該事件傳遞給每一個感興趣的方案，然后讓這些方案在該事件所包含的信息上運行各自的規(guī)則。該會話Bean還提供功能以重新部署方案，并將現(xiàn)存方案以XML導出。
方案對象(Scenario Objects)方案作為規(guī)則集(RuleSet)的包裹程序，包含某些附加的業(yè)務邏輯。當方案從方案服務中接收到事件時，先作檢查以保證該事件對本方案有意義。如果沒有意義，則該方案立即返回。否則，如果有意義，則其將事件中包含的信息以及本方案中包含的規(guī)則集一并傳遞給規(guī)則服務。方案規(guī)則在啟動時產(chǎn)生動作定義。在執(zhí)行完規(guī)則集后，方案將使用動作服務以執(zhí)行所產(chǎn)生的動作定義對象(如果有的話)。這就防止了由規(guī)則產(chǎn)生的動作在規(guī)則引擎線程中執(zhí)行。
動作對象(Action Objects)當方案為其所收到的事件運行一組規(guī)則時，通常將執(zhí)行某些動作以作為這些規(guī)則的結(jié)果。為達此目的，規(guī)則創(chuàng)建并初始化動作定義(ActionDef)對象。這些對象必須用其所代表的動作的名稱及該動作運行時所需要的參數(shù)的映射集來初始化。它們負責實例化動作接口的實際實現(xiàn)，該實際實現(xiàn)作實際的工作。該接口包含使用有名參數(shù)的映射集的init(初始化)方法，以及執(zhí)行該動作的run(運行)方法。規(guī)則被設(shè)計用來指揮規(guī)則引擎用來自事件、當前用戶、或任何其他可用資源的數(shù)據(jù)正確地初始化動作定義。例如，一發(fā)送電子郵件的方案將包含規(guī)則，該規(guī)則返回由適當參數(shù)的映射集初始化的動作定義，所述參數(shù)如接收方電子郵件地址及消息的文本，以及該動作的名稱，即SendEmailAction(發(fā)送郵件動作)等等。在這些規(guī)則執(zhí)行完畢后，方案將使所返回的動作定義對象檢索實際的動作實現(xiàn)。當調(diào)用該動作的運行方法時，其將使用初始化參數(shù)來完成其任務，在本例中為啟動電子郵件服務以發(fā)送消息。
EJB廣告服務(EJB Ad Service)廣告服務提供了基于系統(tǒng)的當前用戶來檢索廣告的途徑。其包括廣告桶服務會話Bean(AdBucketService session Bean)以及較低級的廣告服務(AdService)會話Bean，其中前者負責管理應該向哪些用戶顯示那些廣告，后者作為到內(nèi)容管理服務的直通通路。
廣告桶服務(Ad Bucket Service)廣告桶服務(AdBucketService)是無狀態(tài)會話EJB，用來向占位符提供廣告內(nèi)容。這是通過查看指向占位符的廣告并生成有效廣告集合來完成的。然后，該集合被傳送給廣告沖突解決器(AdConflictResolver)，其用來挑選出實際待提供的廣告并更新廣告信息。來源于此的廣告查詢被送往廣告服務以挑選實際的廣告。如果沒有找到有效廣告，則檢查全局廣告桶以查找廣告。廣告桶服務還提供了向用戶廣告桶添加廣告的方法。一般在來自方案的事件引起了添加廣告動作(AdAction)的觸發(fā)時，該方法被調(diào)用。廣告桶服務還提供了接口，其允許清理活動狀態(tài)。更一般地，該接口將基于方案容器的名稱從用戶桶中移除內(nèi)容。活動只是方案容器的一種實現(xiàn)。
廣告信息(Ad Info)廣告信息(AdInfo)是包含輸入到數(shù)據(jù)庫中的信息的某些子集的數(shù)據(jù)結(jié)構(gòu)。用于用戶廣告信息的數(shù)據(jù)庫表項可能包括以下userName—用戶的名稱；placeholderName—該廣告將指向的占位符名稱；scenarioContainerName—生成該廣告的方案容器(活動)的名稱；enterDate—該廣告的輸入日期/時間；adQuery—傳送給廣告服務以生成該廣告實際內(nèi)容的查詢；expirationDate—該廣告失效日期；weight—權(quán)重與查看計數(shù)(viewCount)被用來挑選廣告；viewCount—；以及，scenarioName—將該廣告添加到活動中的方案的名稱；廣告沖突解決器(AdConflictResolver)廣告沖突解決器負責選擇向用戶顯示的“最佳”廣告，并更新數(shù)據(jù)庫中的廣告。該方法向廣告集合使用選擇所顯示的“最佳”廣告的算法。然后根據(jù)該算法更新權(quán)重與查看計數(shù)(ViewCount)。
廣告服務(AdService)廣告服務(AdService)是獨立部署的無狀態(tài)會話EJB，其實現(xiàn)文件管理器(DocumentManager)接口并代理文件管理器。廣告對象可以是在文件管理器中部署的文件對象。
點擊進入Servlet(Click-Thru Servlet)此Servlet用來跟蹤廣告點擊進入事件。從廣告桶服務輸出的內(nèi)容將包裹廣告并將其指向此Servlet。點擊進入Servlet(ClickThruServlet)是記錄用戶在廣告上的點擊的中心所在。這可能引發(fā)活動事件。在處理完點擊進入事件后，此Servlet將用戶重定向到目標頁。
EJB占位符服務(EJB Placeholder Service)
占位符表示JSP頁中的命名的位置，在其上可由商業(yè)服務器放置內(nèi)容。其由占位符JSP標記表示。在該占位符標記之后是占位符服務(PlaceholderService)，為無狀態(tài)會話EJB。占位符服務負責將內(nèi)容返回給JSP頁。
內(nèi)容從內(nèi)容處理器EJB檢索而來，該內(nèi)容處理器EJB實現(xiàn)內(nèi)容桶(ContentBucket)接口。當定義占位符時，為有名占位符登記內(nèi)容處理器。
占位符標記(PlaceholderTag)占位符標記用來將來自占位符服務的內(nèi)容放入JSP頁中。占位符是有名實體。占位符標記定義四個屬性名稱—系統(tǒng)內(nèi)該占位符的名稱；高度—可選的內(nèi)容高度；寬度—可選的內(nèi)容寬度；表達器—可選的有名EJB，其可以對從內(nèi)容桶輸出的內(nèi)容在通過該占位符標記返回之前進行轉(zhuǎn)換。
占位符服務(PlaceholderService)占位符服務是無狀態(tài)會話EJB，其主要職責是將內(nèi)容返回給占位符標記。另外，它提供用于占位符定義、以及用于占位符查詢的方法。查詢方法可由工具使用來生成下拉列表等等。占位符定義方法為系統(tǒng)定義新占位符。名稱必須唯一，并且內(nèi)容桶名稱(ContentBucketName)必須為定義內(nèi)容桶(ContentBucket)接口的EJB。占位符將在數(shù)據(jù)庫表中定義，其包含以下信息名稱—占位符的唯一名稱；類型—表示內(nèi)容桶生成的EJB的名稱；以及占位符的內(nèi)容。
內(nèi)容桶(ContentBucket)內(nèi)容桶接口定義了占位符服務用來接收內(nèi)容的接口。該接口將由“桶”實現(xiàn)。折扣桶(DiscountBucket)也是內(nèi)容同。
內(nèi)容轉(zhuǎn)換(ContentTransform)這是一抽象基類，其實現(xiàn)對內(nèi)容桶的輸出在返回給占位符標記之前進行的轉(zhuǎn)換，并作為其中系統(tǒng)可以對內(nèi)容桶輸出執(zhí)行XSLT類型轉(zhuǎn)換的連結(jié)點。
EJB電子郵件服務(EJB Email Service)電子郵件服務會話Bean為通用平臺級服務以提供發(fā)送電子郵件的功能。它提供實時電子郵件功能，也提供批量電子郵件功能。在最簡單的情況中，通過提供接收方地址，主題與消息文本就可以發(fā)送電子郵件?？梢栽诜掌鞑渴鹬兄付J的發(fā)送方地址。
電子郵件打包(Email Batching)
電郵件服務還提供將電子郵件集合打包以備以后發(fā)送的功能。在活動的情景中，可使用這一功能來在用戶生成事件時逐漸累積有關(guān)促銷或特別報價的電子郵件，然后在促銷開始后將其一次發(fā)送。電子郵件包可由字符串標識確定。在活動的情景中，這可以是活動的名稱。每個包都有日期，用來確定其何時被發(fā)送，或者可能是范圍，以便使在開始日期前加入包中的電子郵件被打包，而日期范圍內(nèi)加入的電子郵件被馬上發(fā)送。
EJB活動服務(EJB Campaign Service)活動服務是本文件所涉及的最高級別的服務?；顒邮前l(fā)起者的被設(shè)計用來達到某目標的方案集合。
活動服務會話Bean(Campaign Service Session Bean)活動服務會話Bean是活動與系統(tǒng)其余部分之間的接口。其實現(xiàn)事件監(jiān)聽器接口，以便其能接收應該由組成活動的方案所處理的事件。該會話Bean還提供功能，使工具能部署新活動，并且以XML檢索活動定義。
活動對象(Campaign Object)活動包含一組方案，還有一些有關(guān)活動本身的信息，如開始與終止日期。
活動自舉(Campaign Bootstrap)在有些實施例中，活動可能還包含自舉規(guī)則，當部署活動或服務器啟動時，執(zhí)行該自舉規(guī)則。自舉規(guī)則可作的事情如將項放入全局廣告桶中以便向用戶顯示活動的廣告內(nèi)容，而不用觸發(fā)由活動方案之一所識別的事件。
部分活動定義為日期-時間集合與時間范圍，其間該活動有效。這些范圍也可以為負；例如，可能有日期范圍從12月18號到12月25號，以及無效時間范圍上午8點至上午11點。這使活動在12月18號到12月25號之間而非上午8點至上午11點之間認為自身有效。對活動的“是否有效”(isActive)的第一次調(diào)用中有一部分將檢查這些日期范圍與當前日期/時間，以便不用啟動規(guī)則引擎而短路該調(diào)用。
另外，在某些實施例中，可以為活動定義激活規(guī)則。激活規(guī)則可能返回真或假，并在驗證了有效日期范圍后被調(diào)用。這提供了在運行所有屬于活動方案的規(guī)則集前短路該調(diào)用的另一種方法。激活規(guī)則還提供了一種途徑，通過使該規(guī)則檢查目標條件并且如果已達到目標則返回假，以在達到“目標”時停止活動執(zhí)行。
接收事件(Receiving an Event)
當活動通過活動服務接收事件時，通過查看自己的開始與終止日期范圍，以及所定義的任何時間范圍，然后還可能運行自己的激活規(guī)則，活動先檢查確認自身有效。如果任意一項檢查失敗，則認為活動無效，并且不再進一步執(zhí)行。如果活動確定自身有效，則其將事件傳送給其每一個方案，以便它們都能夠通過運行自己的規(guī)則集，并執(zhí)行由此產(chǎn)生的任何動作來對該事件作出反應。
活動后的清理(Cleaning Up After a Campaign)根據(jù)一個實施例，活動定義還可以包含“清理規(guī)則”，其在活動被撤消時執(zhí)行。這就給活動一次機會，以便刪除在其運行時可能創(chuàng)建的任何信息，如廣告桶中的廣告查詢。如同方案中的規(guī)則，此規(guī)則將返回零或更多個動作對象，這些對象被執(zhí)行以進行清理。將會清楚，也可以采用其他清理方法。
部署器服務(Deployer Service)部署器組件的接口為部署器(DeployerServlet)。這是標準Servlet，其接收包含待部署數(shù)據(jù)的XML流，并將該流轉(zhuǎn)接到適當?shù)墓ぞ哳?helperclass)。該Servlet的配置信息將包含將XML文件類型映射集到部署器工具接口的實現(xiàn)的信息。當該Servlet接收XML數(shù)據(jù)流時，其將檢查文件類型，并且初始化部署器工具的正確的實現(xiàn)以處理該類型。每個部署器工具的實現(xiàn)都將知道如何部署來自XML流的數(shù)據(jù)。這由各個組件負責；其可能調(diào)用會話Bean以處理實際的部署，或者可能直接將該數(shù)據(jù)輸入到數(shù)據(jù)庫中。
EJB事件服務(EJB Event Service)除通過JMS的異步事件處理之外，活動與事件要求具備處理可能同步的事件的能力。在事件特征集合類型中，每個特征集的名稱將對應一事件類型。在我們或我們的客戶添加新事件類型時，此機制將允許擴展編輯器。支持下列事件類型與特征集合，然而顯然在本發(fā)明的精神與范圍內(nèi)還支持其他事件類型。
登入事件(Login Event)特征名稱 類型 描述User 用戶 登入用戶userId 字符串 登入用戶的標識applicationBase 字符串 應用的基本URI(如
“/portal/application/exampleportal”)。
這可以為空。
登出事件(Logout Event)特征名稱 類型 描述User 用戶 登入用戶userId 字符串登入用戶的標識applicationBase字符串應用的基本URI(如“/portal/application/exampleportal”)。
這可以為空。
廣告印象事件(Ad Impression Event)特征名稱 類型 描述User 用戶 登入用戶userId 字符串登入用戶的標識campaignName 字符串為其顯示廣告的活動的名稱scenarioName 字符串廣告顯示所源自的方案的名稱adId 字符串廣告的標識符placeholderName字符串廣告顯示所在的占位符的名稱。這可以為空。
廣告點擊事件(Ad Clicked Event)特征名稱 類型 描述User 用戶 登入用戶userId 字符串登入用戶的標識campaignName 字符串為其顯示廣告的活動的名稱scenarioName 字符串廣告顯示所源自的方案的名稱adId 字符串廣告的標識符placeholderName字符串廣告顯示所在的占位符名稱?？蔀榭?。
結(jié)帳事件(Checkout Event)特征名稱 類型 描述User 用戶 登入用戶userId 字符串登入用戶的標識shoppingCart 購物車在結(jié)算時用戶的購物車對象向購物車添加事件(Add to Shopping Cart Event)特征名稱類型 描述User用戶 登入用戶userId 字符串登入用戶的標識Item產(chǎn)品項目 所添加的產(chǎn)品項目quantity整數(shù) 所添加的數(shù)目從購物車移除事件(Remove from Shopping Cart Event)特征名稱類型 描述User用戶 登入用戶userId 字符串登入用戶的標識Item產(chǎn)品項目 所移除的產(chǎn)品項目quantity整數(shù) 所移除的數(shù)目典型實現(xiàn)以下小節(jié)描述根據(jù)本發(fā)明的一個實施例的個性化系統(tǒng)的典型實現(xiàn)。將會清楚在本發(fā)明的精神與范圍內(nèi)可以使用替換實現(xiàn)。
圖5示出方案服務的一個實現(xiàn)的模型圖，顯示了方案服務如何使用名稱或搜索模式訪問方案。如圖5所示，該方案服務包括了用于處理事件，以及用于按名稱查找或檢索方案的機制，方案服務190使用方案接口192以按名稱、描述、類別名稱、長描述、方案規(guī)則集名稱、或分類器規(guī)則集名稱來查找或保存方案。XML接口允許方案服務從XML文件中讀出方案，并且將修改后的方案保存到XML文件。方案容器接口194用來指明方案是否有效。
圖6示出在本發(fā)明的一個實施例中如何使用內(nèi)容管理器來向用戶提供內(nèi)容。如圖6所示，內(nèi)容管理器200使用內(nèi)容接口206，從文件管理器202與廣告服務204檢索所輸入的數(shù)據(jù)。文件接口208允許存儲和/或編輯有關(guān)文件的其他信息，包括作者版本號等等。
圖7示出用來在事件發(fā)生時對其響應的活動服務的一個實現(xiàn)的模型。如圖7所示，活動服務220與方案服務190使用經(jīng)活動接口224來自規(guī)則集的信息?；顒咏涌?24將信息送入方案容器194以備顯示內(nèi)容時使用。事件監(jiān)聽器228將有關(guān)所發(fā)生的事件(重新登入、頁命中、點擊進入等等)的信息送入活動監(jiān)聽器230以備活動服務220使用。活動接口224使用規(guī)則信息232與基于規(guī)則的方案鏈接234來訪問方案接口192。
圖8示出事件服務240的模型，其使用事件監(jiān)聽器接口228以接收事件242的通知。該信息被活動監(jiān)聽器230截收，以確定系統(tǒng)和當前用戶當下感興趣的事件。在一個實現(xiàn)中，事件服務可被行為跟蹤監(jiān)聽器224修改，該監(jiān)聽器使用關(guān)于用戶行為的信息來幫助確定將被監(jiān)聽的可能的事件類型?？梢允褂脴藴蔎ava JMS方法246，以向行為跟蹤監(jiān)聽器244發(fā)布事件。
圖9示出示生命周期，表示在一個實施例中如何使用占位符標記來為隨后的用戶屏幕上的顯示檢索內(nèi)容。如圖9所示，當在用戶屏幕上占位符標記或JSP標記250被激活時，其引起對占位符服務EJB 252的調(diào)用。占位符服務EJB隨后基于占位符的名稱調(diào)用內(nèi)容桶254，之后是對獲取內(nèi)容的請求。然后該內(nèi)容被返回給用戶，一般作為用戶屏幕上的顯示。可以可選地向表達器對象EJB 256發(fā)送請求，以將內(nèi)容桶的輸出向用戶返回或向用戶顯示前轉(zhuǎn)換為某種其他格式。
圖10示出生命周期，表示如何使用管理與編輯工具(包括圖形用戶界面)以編輯活動與方案，然后在活動服務上部署活動，以備隨后為用戶個性化網(wǎng)頁內(nèi)容使用。如圖10所示，可以使用工具260直接或通過圖形用戶界面來編輯活動方案，或者可以使用工具260生成新的定義活動的活動XML文件。當活動被令人滿意地配置時，向部署器Servlet 262提出請求以部署實際活動。該部署功能使用部署配置信息來決定使用哪個部署器工具類型264(如存在許多的話)。然后將活動部署給活動服務266。在隨后的任意時間點上，活動268都能自動或手動地由自舉規(guī)則或例程激活，然后可以由系統(tǒng)在個性化內(nèi)容時使用。
圖11示出生命周期，其中占位符服務EJB 252使用廣告桶EJB 284與廣告沖突解決EJB 286，以向用戶提供廣告。如圖11所示，對廣告桶EJB 284調(diào)用“getContent”被用來基于用戶的當前信息、特征集、或會話與廣告占位符從數(shù)據(jù)庫選擇廣告。然后系統(tǒng)基于活動規(guī)則去除非法廣告，并產(chǎn)生合法規(guī)則集合以傳送給用戶。如需要，使用廣告沖突解決EJB 286以挑選優(yōu)先級最高的廣告。然后“getAd”方法將基于廣告查詢的實際廣告返還給廣告服務288。
圖12示出一點擊進入Servlet的生命周期，顯示在點擊特定廣告時用戶300如何向點擊進入Servlet 302發(fā)送方法。點擊進入Servlet聯(lián)系廣告桶服務284，其使用活動服務266，活動服務266查找提供該廣告的活動并為該活動調(diào)用適當?shù)狞c擊進入方法。然后基于該點擊進入使用廣告桶服務將用戶重新定向。
行為跟蹤本發(fā)明的某些實施例對跟蹤用戶在網(wǎng)站上的動作，并使用該跟蹤信息以對網(wǎng)站內(nèi)容作相應修改尤其有用。為跟蹤用戶與網(wǎng)站的交互，可以使用行為跟蹤系統(tǒng)，以存儲該數(shù)據(jù)以備將來分析。將事件機制一般化涉及兩個主要任務。
事件類型必須被解除耦合并以其將在其中被使用的情景定義。必須為一般頁查看、產(chǎn)品查看、與廣告查看定義顯示事件。對點擊事件也是如此。另外，其他事件的定義必須明確并最終確定；以及事件服務必須被一般化，以將事件內(nèi)容與該機制解除耦合。在一個實施例中，所有的事件都被存儲在一單一數(shù)據(jù)庫表中。一單一監(jiān)聽器將從事件服務接收事件并將該事件傳送給單一保存器。該單一保存器將調(diào)用工具方法以生成將被存儲到數(shù)據(jù)庫中的XML串；然后該數(shù)據(jù)被存儲到該單一數(shù)據(jù)庫表中。
可被跟蹤的事件包括SessionBeginEvent—標示任意用戶會話的開始。用戶不必登錄就可進入會話。然而，如果用戶登錄了，他們還保持其在登入前的會話標識。匿名用戶將具有會話標識，但直到其登錄(驗證)后，才會有用戶標識。在用戶會話開始時生成。
SessionEndEvent—標示任意用戶會話的終止，不管該用戶登錄與否。在會話超時或用戶登出時生成。
SessionLoginEvent—標示用戶已被驗證。我們認為此時我們可以訪問用戶特征集信息。將使用與用戶登入前相同的會話標識。當用戶提供登入信息時產(chǎn)生。
UserRegistrationEvent—表示新用戶何時在站點注冊。當用戶成功地完成注冊表格時產(chǎn)生。
AddToCartEvent—客戶向購物車添加產(chǎn)品。當客戶向其購物車添加產(chǎn)品時產(chǎn)生。
BuyEvent—客戶購買產(chǎn)品。當客戶進入結(jié)算時產(chǎn)生；每件產(chǎn)品一個事件。
RemoveFromCartEvent—客戶從購物車移除產(chǎn)品。當客戶從其購物車移除產(chǎn)品時產(chǎn)生。
RuleEvent—啟動了規(guī)則。通常在方案的情景下生成(參見以上描述)。然而，也可以獨立于方案地啟動規(guī)則。
DisplayContentEvent—獨立于活動地向屏幕顯示圖像。當顯示“帶標記的”(”tagged”)內(nèi)容時生成。
ClickContentEvent—獨立于活動地點擊屏幕上的圖像。當點擊帶標記的內(nèi)容時生成。
DisplayProductEvent—在屏幕上顯示產(chǎn)品。注意產(chǎn)品沒有綁定在活動上。當顯示帶標記的產(chǎn)品時生成。
ClickProductEvent—點擊屏幕上的產(chǎn)品。當點擊帶標記的產(chǎn)品時生成。
DisplayCampaignEvent—向屏幕顯示與活動有關(guān)的圖像。方案可能與多個顯示相關(guān)。當活動/方案指明此特定內(nèi)容與方案相關(guān)，并且應該在方案有效時顯示時生成此事件。
ClickCampaignEvent—點擊與活動有關(guān)的圖像。方案可能與多個點擊事件相關(guān)。當活動/方案指明此特定內(nèi)容與方案相關(guān)，并且被點擊時生成此事件。
CampaignUserActivityEvent—在活動情景內(nèi)捕捉用戶活動的通用事件。被用來記錄用戶接觸了特定活動。如果不存在DisplayCampaignEvent或ClickCampaignEvent，則使用此事件。
圖13示出一個實現(xiàn)，即如何使用事件系統(tǒng)傳送事件供該系統(tǒng)使用，以個性化內(nèi)容或業(yè)務功能。如圖13所示，使用事件服務BEAN 310將事件312的通知送入一個或更多個可插入的異步監(jiān)聽器314，在本系統(tǒng)的一個實施例中包含行為跟蹤或監(jiān)聽器模塊316。每個監(jiān)聽器都有其所監(jiān)聽的事件類型列表。當行為跟蹤JMS監(jiān)聽器(BehaviorTrackingJMSListerner)接收該類型事件(例如，foo)時，將該類型為foo的事件傳送給每一個監(jiān)聽器，所述監(jiān)聽器將foo列入從對其getTypes()調(diào)用返回的字符串數(shù)組中(由行為跟蹤JMS監(jiān)聽器啟動該調(diào)用)。使用Java消息服務(JMS)318將單個的事件消息傳遞給JMS監(jiān)聽器與可插入的異步監(jiān)聽器322集合。各監(jiān)聽器不知道JMS。例如，為插入只對活動事件感興趣的監(jiān)聽器，必須將該監(jiān)聽器的類名作為行為跟蹤監(jiān)聽器列入特征文件，該監(jiān)聽器必須實現(xiàn)空handleEvent(Event e)，并且該監(jiān)聽器的getTypes()調(diào)用需要返回包含{“ClickCampaignEvent”，“DisplayCampaignEvent”，”CampaighUserActivityEvent”}的數(shù)組。然后將到達該三類事件之一，并在該監(jiān)聽器的handleEvent(Event e)接口處理。該行為跟蹤JMS監(jiān)聽器訂閱JMS主題，從同步的了解JMS的監(jiān)聽器向該主題發(fā)送事件。然后其將事件發(fā)送給對特定類型事件感興趣的可插入的異步監(jiān)聽器?？梢跃彺?24這些事件，然后將其存儲進數(shù)據(jù)庫(DBMS)326以備生成內(nèi)容時使用。將清楚可以使用其他方法來向系統(tǒng)傳送事件。
事件表在一個實施例中，跟蹤事件表結(jié)構(gòu)使用了單一表，用來存儲從所有事件類型來的數(shù)據(jù)。該表的實施例具有五列，如下所示，但可以使用其他可替換形式EVENT_ID(事件標識)EVENT_DATE(事件日期)EVENT_TYPE(事件類型)WLS_SESSION_ID(WLS會話標識)USER_ID(用戶標識)XML_DEFINITION(XML定義)前五項為被捕獲并存儲在數(shù)據(jù)庫中的所有事件類型所共有。最后一項XML_DEFINITION表示作為CLOB存儲在表中的XML文件。XML_DEFINITION存儲以上前五項以及事件特有數(shù)據(jù)，該數(shù)據(jù)可能在所有事件類型中都不相同。為每一事件類型逐一生成該XML文件。
管理工具與編輯器管理工具功能可以分為幾個主要組件。圖14顯示管理工具集合的一個實施例，其允許管理員修改規(guī)則和/或活動方案規(guī)則集，并允許管理員編輯動作類型，包括(例如)可以由本發(fā)明使用的折扣定義。如圖14所示，管理軟件作為工具框架330，并且可以包括活動編輯器332、方案編輯器334、規(guī)則編輯器336、以及折扣定義編輯器338。如必要可以添加其他規(guī)則編輯器。使用這些編輯器來修改系統(tǒng)庫340，其包括與活動模型342、方案模型344、規(guī)則模型346、以及折扣定義模型348有關(guān)的數(shù)據(jù)。該庫通過保存層352與服務器端的數(shù)據(jù)庫350連接，該保存層允許在此個性化引擎運行時動態(tài)地更新數(shù)據(jù)。
編輯器—管理員將與之交互以生成活動、方案、規(guī)則集、或折扣定義的實際的窗口部件、圖標、以及其他用戶界面功能。它獨立于任何工具框架，這使編輯器盡可能地可復用。工具框架將創(chuàng)建并監(jiān)聽模型以促進在用戶界面中的呈現(xiàn)與其下對象(underlying objects)的保存。編輯器還可訪問庫對象，該庫對象包含來自外部世界的信息，如呈現(xiàn)模板列表、可使用特征等等。
呈現(xiàn)—有關(guān)如何以對管理員可讀并可理解的方式顯示活動、方案或規(guī)則的信息。該呈現(xiàn)信息由編輯器使用，并且可能對場所唯一(unique to alocale)(甚或?qū)I(yè)務唯一)。
模型—編輯器與“世界“交互的方式。每個編輯器的模型都負責向該編輯器提供其所需的東西，如數(shù)據(jù)的DOM。模型還監(jiān)聽DOM上的事件，并且具備適當機制以啟動自己的事件，該事件由工具框架監(jiān)聽(例如，用來提醒需要保存規(guī)則集)。
工具框架—容納具體編輯器的外圍基本構(gòu)架。工具框架顯示活動、方案、規(guī)則集、以及折扣定義的列表。還借助工具條、菜單、或類似界面(通過模型與保存層)處理對在編輯器內(nèi)部所產(chǎn)生的東西的保存、加載、以及刪除。
數(shù)據(jù)—有關(guān)實際的規(guī)則、方案、活動、以及在工具內(nèi)編輯的其他構(gòu)件的信息。這些數(shù)據(jù)存在于從XML生成的一個或多個DOM中。
保存—如何將數(shù)據(jù)載入模型以及如何在編輯器中生成或編輯后保存數(shù)據(jù)。
規(guī)則編輯器規(guī)則編輯器是大多數(shù)其他管理工具的基礎(chǔ)?；顒优c方案由規(guī)則(在規(guī)則集中)構(gòu)成。因此，為編輯方案與活動中的規(guī)則，必須使用規(guī)則編輯器。
規(guī)則集當啟動規(guī)則編輯器時，“工作單位”為規(guī)則集。規(guī)則集是相關(guān)規(guī)則的匯集，被捆綁在一起以便規(guī)則引擎能夠一起使用它們。
分類器分類器規(guī)則集是個特例。因為類別(例如，用戶是“金成員”這一事實)需要在任意活動、方案、或規(guī)則中重復使用，所以對每一應用具有單一規(guī)則集能使事情(對我們)更好辦，該單一規(guī)則集存儲了所有將被重復使用的類別。因此，就有只包含分類器規(guī)則的特殊的分類器規(guī)則集。請注意分類器與類別之間的區(qū)別。分類器是規(guī)則類型，其右側(cè)聲明類別對象。例如，在分類器“如果來訪者的家鄉(xiāng)為柯羅拉多州，則將其歸類為滑雪者”中，類別“滑雪者”將在其他規(guī)則(“如果來訪者是滑雪者，則在左邊的廣告占位符中顯示Vail的廣告”)中復用。分類器規(guī)則不在其他規(guī)則中使用一只有類別在其他規(guī)則中使用。
XML到類HTML閱讀器模型在規(guī)則編輯器啟動時向其提供了其所使用的規(guī)則集DOM。當從規(guī)則集中選擇了某規(guī)則時，規(guī)則編輯器必須能夠顯示包含在該規(guī)則集DOM中的規(guī)則的數(shù)據(jù)，以及正確顯示該規(guī)則所必須的呈現(xiàn)信息DOM。規(guī)則編輯器需要能夠?qū)⑦@兩類DOM信息轉(zhuǎn)換為可讀的規(guī)則，其具有用于可參數(shù)化節(jié)段的超級鏈接。
短語編輯器當在規(guī)則中點擊超級鏈接(可參數(shù)化區(qū)域)時，呈現(xiàn)DOM需要知道打開哪個短語編輯器。短語編輯器是一對話，用來取得具體值以備規(guī)則中使用。例如，日期或時間選擇器，或特征挑選器。
方案編輯器方案編輯器如同規(guī)則編輯器一樣編輯規(guī)則集。兩者間的唯一區(qū)別在于方案始于模板(例如“廣告方案“模板)，并且方案有些關(guān)于自己的元數(shù)據(jù)(例如描述)。換而言之，在方案編輯器中使用的大部分規(guī)則都嵌套在內(nèi)置的規(guī)則編輯器中。方案實質(zhì)上是規(guī)則集與一些元數(shù)據(jù)。方案數(shù)據(jù)包含該元數(shù)據(jù)及指向規(guī)則集的鏈接。方案數(shù)據(jù)還包含指向分類器規(guī)則集的鏈接，以便在分類器規(guī)則中生成的類別可以在方案規(guī)則中使用。
活動編輯器活動編輯器可以內(nèi)含多個方案，以及開始與終止條件的規(guī)則集。還有活動元數(shù)據(jù)，如發(fā)起者、描述、以及搜索信息(起始與終止日期等等)。在活動編輯器添加或修改方案時，其使用方案編輯器以及規(guī)則編輯器。活動數(shù)據(jù)有指向內(nèi)部所使用的每一規(guī)則集(包括方案)的鏈接，包括方案、起始/終止條件規(guī)則集、以及分類器規(guī)則集。
折扣定義編輯器折扣定義編輯器只在以下意義上與活動、方案、與規(guī)則編輯器有關(guān)在規(guī)則編輯器中產(chǎn)生的規(guī)則可以引用在折扣定義編輯器中產(chǎn)生的折扣(折扣類型規(guī)則)。
呈現(xiàn)如“如果來訪者的性別為男性，則將來訪者歸類為啤酒飲用者”之類的分類器不僅具有如“性別”、“男性”、“啤酒飲用者”等等數(shù)據(jù)，還有關(guān)于如何顯示分類器的呈現(xiàn)信息(“如果來訪者的...”)。該呈現(xiàn)信息存儲在編輯器自身之外，以便可以插入不同的呈現(xiàn)以供不同用途(如不同的場所或為某業(yè)務或垂直市場的具體呈現(xiàn))。
模式對每一編輯器(活動、方案、規(guī)則、以及可能的折扣定義)，都有XML模式，控制著任何用于該編輯器的呈現(xiàn)XML必須如何構(gòu)成。
呈現(xiàn)XML有了模式，每一編輯器都需要默認的呈現(xiàn)XML。這包括用于每種規(guī)則類型的規(guī)則文本(分類器、內(nèi)容選擇器、占位符內(nèi)容選擇器、發(fā)送電子郵件、折扣)，以及用于方案與活動的顯示信息(可能只有元數(shù)據(jù)名稱，也可能更多)。
模型盡管每一編輯器知道如何處理具體的數(shù)據(jù)類型與呈現(xiàn)DOM(活動、規(guī)則集等等)，但每一編輯器并不一定需要對該DOM作所有的遍歷、更新、以及其他動作。每一編輯器都有相關(guān)聯(lián)的模型，此模型處理大部分“低級工作”，其向編輯器提供有用的方法。
便利方法用于每一編輯器的模型提供便利方法，該編輯器可以使用這些方法以取得或設(shè)置來自DOM的值。例如，活動模型可能提供方法String getSponsor()，其遍歷數(shù)據(jù)DOM以取得活動的發(fā)起者。
事件每一編輯器的模型還提供事件監(jiān)聽與啟動機制，從而由模型負責根據(jù)從該編輯器啟動的事件通知工具框架如數(shù)據(jù)“變臟”(指使能了保存按扭)等事情。
庫用于每一編輯器的模型都具有與該編輯器相關(guān)的信息的庫。該庫包含如模板列表等信息，并且還可能保存對用于每一編輯器的呈現(xiàn)DOM的引用。
工具框架工具框架是GUI的外層，并且容納了其中的各種編輯器。工具框架負責顯示活動、方案、規(guī)則集以及折扣定義集合。工具框架還執(zhí)行保存、打開、以及搜索(例如活動查找)任務。工具框架從不直接與編輯器通信—其總是通過編輯器的模型。
數(shù)據(jù)在本文件中，名詞“數(shù)據(jù)”指管理員用戶通過使用工具所試圖創(chuàng)建、更新、或刪除的信息。數(shù)據(jù)可能是規(guī)則集、方案、活動、或折扣定義。
模板模板概念對管理員工具至關(guān)重要。通過在每一級(活動、方案、規(guī)則、以及規(guī)則子句)上提供模板，工具使管理員用戶易于迅速創(chuàng)建自己所需生成的任何東西。通過使模板可插入(可以以后創(chuàng)建新模板)，可以提供大量功能與很高的靈活性。
模板就是方案、活動、或規(guī)則(或規(guī)則子句)的參數(shù)未定的版本。模板提供了基本結(jié)構(gòu)，但編輯器應該允許將始自模板的活動、方案或規(guī)則修改為管理員用戶所希望的任何形式。例如，用戶可以以電子郵件方案模板開始，通過添加與移除規(guī)則，最終得到的模板對產(chǎn)品進行折扣而且根本不發(fā)送電子郵件。
折扣本發(fā)明的某些實施例允許用戶(例如在萬維網(wǎng)環(huán)境下)向特定客戶提供折扣。在這些實施例中，所有的折扣都有唯一的標識符。通過方案，有可能將折扣與用戶相關(guān)聯(lián)。
折扣是促銷功能的一部分，其履行通過活動服務或可能還未開發(fā)的功能向客戶作出的金錢上的促銷承諾。打折包括定義折扣，以及通過批價服務執(zhí)行這些折扣，該批價服務對定單或購物車內(nèi)容進行計算。具體地，批價服務將向產(chǎn)品集合執(zhí)行折扣集合，以將客戶在金錢上的收益最大化。商業(yè)服務器所提供的許多其他服務將與折扣功能交互，因此與這些服務存在大量的相關(guān)性并對其有較大的影響。
客戶—基于瀏覽器的用戶，其與商業(yè)站點交互。還包括與商業(yè)站點交互的計算機系統(tǒng)。
開發(fā)人員—對任何在商業(yè)服務器上操作、配置、維護或開發(fā)人員的統(tǒng)稱。
商業(yè)工程師，商業(yè)經(jīng)理—負責管理業(yè)務功能的高級開發(fā)人員。
折扣工具—用來定義折扣的工具。
本發(fā)明的實施例提供了在商業(yè)服務器內(nèi)部署的軟件設(shè)施，以促進向客戶提供折扣?？梢韵蛩锌蛻艋蛑粚μ囟蛻舴纸M提供折扣。折扣可以總是有效或者可以帶有條件，指明何時或在哪種情況下有折扣。在一些實施例中，系統(tǒng)包括動態(tài)批價服務，其對特定產(chǎn)品或產(chǎn)品集合執(zhí)行折扣以生成在特定時間上對特定客戶該產(chǎn)品或產(chǎn)品集合的費用。雖然促銷功能(不通過產(chǎn)品目錄而向客戶呈現(xiàn)報價)在折扣系統(tǒng)之外，但該動態(tài)批價服務可以遵守通過促銷功能提出的報價。
折扣系統(tǒng)包括與購物車、目錄、結(jié)算、以及定單管理系統(tǒng)之間的依賴性與互操作性。該系統(tǒng)可以獨立存在，或者允許第三方的開發(fā)人員提供其自己的目錄與定單系統(tǒng)組合?？梢允褂霉ぞ呔S護折扣定義。
折扣系統(tǒng)有兩個主要用例。第一個有關(guān)開發(fā)人員與折扣配置系統(tǒng)的接口。第二個有關(guān)客戶與目錄、購物車、結(jié)算之間，以及與批價服務的間接接口。第三個用例存在于開發(fā)人員與批價服務接口以執(zhí)行未指明的任務。
本發(fā)明的實施例提供一套機制，允許折扣系統(tǒng)遵守通過促銷系統(tǒng)向客戶呈現(xiàn)的報價。該機制稱為折扣指示機制。
促銷設(shè)施基于用戶屬性對所有關(guān)于特定用戶折扣是否應用于該用戶的問題作出決定。在作出此決定后，該促銷設(shè)施用用戶標識符與折扣標識符更新折扣指示機制。在本文中的剩余部分，折扣指示機制被稱為客戶折扣關(guān)聯(lián)。
折扣系統(tǒng)提供資格形式的客戶定標折扣(customer targeteddiscounting of a qualification style)。資格折扣的基本前提是折扣定義描述了獲得折扣資格所需的項目(資格項目)(以及數(shù)量)，以及將接受折扣的項目(目標項目)。一般地，資格項目可以是或不是與目標項目相同的項目。為簡便計，在一個實施例中，資格項目與目標項目可能要求是一組相同的項目。
折扣在對象(定單、購物車等等)匯集的情景中執(zhí)行。當將折扣應用到該匯集上時，匹配折扣定義的對象集合被從該匯集中移除，并對每一折扣定義在目標項目上打折。進行其他折扣，直到再沒有折扣、池中對象或匹配剩余匯集對象的折扣。更具體地，批價服務將在給定對象匯集上執(zhí)行折扣以最大化客戶在金錢上的節(jié)省。
折扣系統(tǒng)可能還提供一套機制，用來將銷售折扣與特定產(chǎn)品項目或目錄相關(guān)聯(lián)。銷售折扣可在所有資格折扣之前使用。
其他特征由本發(fā)明的各種實施例所提供的其他特征包括下列各項。本領(lǐng)域的技術(shù)人員將清楚，以下列表是用來顯示本發(fā)明提供的個性化系統(tǒng)所能夠使用的各種特征，并且在本發(fā)明的精神與范圍內(nèi)顯然有許多修改與變化。
依據(jù)歷史數(shù)據(jù)或當前執(zhí)行數(shù)據(jù)對活動進行預測建模。
將活動/方案數(shù)據(jù)分析直接綁定回活動/方案開發(fā)環(huán)境。
方案驗證規(guī)則此規(guī)則采用與基本方案規(guī)則相同的輸入，然而其輸出為真或假標識符。真將表示該用戶對方案有效，并且應該執(zhí)行正常的方案規(guī)則。假將表示該用戶對方案無效，并且不應該再發(fā)生其他事情。
廣告空間清單與調(diào)度(除非間接地通過方案的使用)高級廣告沖突解決，包括交叉占位符解決(即在同一頁上的兩個占位符)。
廣告接觸限定(Ad exposure limits)。
拒收電子郵件處理(Email bounced handling)。
被保證與被驗證的電子郵件投送。
電子郵件收據(jù)。
以上對本發(fā)明的描述用于顯示與說明目的。其并非窮盡，也非用來將本發(fā)明限定于所公開的具體形式中。顯然，對本領(lǐng)域的普通技術(shù)人員來講，明顯可有許多改進與變化。選擇并描述實施例是為了最清楚地解釋本發(fā)明的原理及其實際的應用，以使本領(lǐng)域其他技術(shù)人員能夠理解本發(fā)明，其可應用于與所構(gòu)想的特定用途相適應的各種實施例與各種修改。本發(fā)明的范圍由所附權(quán)利要求界定。
權(quán)利要求
1.一種定制軟件應用功能的系統(tǒng)，包括服務器，被配置用來允許用戶或自動過程訪問或使用應用，以及生成描述對此應用的使用的事件，作為規(guī)則引擎的輸入；規(guī)則集，包括多條規(guī)則，其中每條規(guī)則定義了為響應特定事件所要采取的一個或多個動作；以及規(guī)則引擎，被配置用來使用規(guī)則，以及關(guān)于當前事件的信息，以確定將由軟件應用采用的動作。
2.如權(quán)利要求1所述的系統(tǒng)，還包括規(guī)則庫，用來存儲所述規(guī)則。
3.如權(quán)利要求2所述的系統(tǒng)，其中所述規(guī)則作為XML文件存儲在規(guī)則庫中。
4.如權(quán)利要求1所述的系統(tǒng)，其中所述規(guī)則可以在實時被更新并應用于規(guī)則引擎，以產(chǎn)生對軟件應用的實時改變。
5.如權(quán)利要求1所述的系統(tǒng)，其中所述規(guī)則的子集可以被用來定義將被軟件應用理解的事件的方案。
6.如權(quán)利要求5所述的系統(tǒng)，其中該系統(tǒng)包括多個方案，從中可以由規(guī)則引擎基于作為輸入所接收的事件選擇任何一個方案。
7.如權(quán)利要求6所述的系統(tǒng)，其中方案的子集形成可被應用理解的活動。
8.如權(quán)利要求7所述的系統(tǒng)，其中存在多個活動。
9.如權(quán)利要求1所述的系統(tǒng)，其中所述應用被用來為網(wǎng)站提供功能。
10.如權(quán)利要求9所述的系統(tǒng)，其中規(guī)則可以被用來確定網(wǎng)站的內(nèi)容。
11.如權(quán)利要求9所述的系統(tǒng)，其中規(guī)則可以被用來確定網(wǎng)站客戶的當前訪問行為。
12.如權(quán)利要求9所述的系統(tǒng)，其中規(guī)則可以被用來在實時確定所述網(wǎng)站的客戶快速印象。
13.一種用來定制電子商務軟件應用的內(nèi)容或功能的方法，包括允許用戶或自動過程訪問或使用在服務器上的應用，以及生成描述對此應用的使用的事件，作為規(guī)則引擎的輸入；讀取規(guī)則集，包括多條規(guī)則，其中每條規(guī)則定義了為響應特定事件所要采取的一個或多個動作；以及使用規(guī)則引擎，其被配置用來使用規(guī)則，以及關(guān)于當前事件的信息，以確定將由軟件應用采用的動作。
14.如權(quán)利要求13所述的方法，還包括將所述規(guī)則存儲到規(guī)則庫中。
15.如權(quán)利要求14所述的方法，其中所述規(guī)則作為XML文件存儲在規(guī)則庫中。
16.如權(quán)利要求13所述的方法，其中所述規(guī)則可以在實時被更新并應用于規(guī)則引擎，以產(chǎn)生對軟件應用的實時改變。
17.如權(quán)利要求13所述的方法，其中所述規(guī)則的子集可以被用來定義將被軟件應用理解的事件的方案。
18.如權(quán)利要求17所述的方法，其中該方法包括多個方案，從中可以由規(guī)則引擎基于作為輸入所接收的事件選擇任何一個方案。
19.如權(quán)利要求18所述的方法，其中方案的子集形成可被應用理解的活動。
20.如權(quán)利要求19所述的方法，其中存在多個活動。
21.如權(quán)利要求20所述的方法，其中所述應用被用來為網(wǎng)站提供功能。
22.如權(quán)利要求21所述的方法，其中規(guī)則可以被用來確定網(wǎng)站的內(nèi)容。
23.如權(quán)利要求21所述的方法，其中規(guī)則可以被用來確定網(wǎng)站客戶的當前訪問行為。
24.如權(quán)利要求21所述的方法，其中規(guī)則可以被用來在實時確定所述網(wǎng)站的客戶快速印象。
25.一種處理器可讀的介質(zhì)，包括其上存儲的指令，該指令在執(zhí)行時使處理器執(zhí)行以下步驟允許用戶或自動過程訪問或使用在服務器上的應用，以及生成描述對此應用的使用的事件，作為規(guī)則引擎的輸入；讀取規(guī)則集，包括多條規(guī)則，其中每條規(guī)則定義了為響應特定事件所要采取的一個或多個動作；以及使用規(guī)則引擎，其被配置用來使用規(guī)則，以及關(guān)于當前事件的信息，以確定將由軟件應用采用的動作。
全文摘要
本發(fā)明利用一種個性化系統(tǒng)，其使用規(guī)則以裁定并表征客戶或客戶動作，然后基于這些規(guī)則(圖1，102、104、106、108、110、112、113、114、116、118、120)的結(jié)果個性化業(yè)務功能，如顯示的頁。規(guī)則可能用來生成方案——表征客戶會話的潛在事件序列。方案可能形成活動的基礎(chǔ)——可能的方案的集合，可能具有起始與終止時間，其間客戶進行操作，并在其中該基于規(guī)則的系統(tǒng)作出決定并確定個性化。在一個實施例中，本發(fā)明提供了一種基于規(guī)則的系統(tǒng)，用來定制電子商務應用的內(nèi)容，該系統(tǒng)包括服務器，用來與規(guī)則引擎以及商業(yè)應用來往傳遞信息；規(guī)則引擎，用來解析規(guī)則集的內(nèi)容，以對當前進程作出明智的決定，并確定動作；具有多個規(guī)則的規(guī)則集，其中每條規(guī)則定義了情況與活動；以及，用來存儲所述規(guī)則的規(guī)則庫。
文檔編號G06Q30/00GK1511290SQ02810730
公開日2004年7月7日 申請日期2002年4月16日 優(yōu)先權(quán)日2001年4月16日
發(fā)明者格雷格·史密斯, 達里爾·奧蘭德, 湯姆·施塔姆, 羅伯特·伯格曼, 伯格曼, 奧蘭德, 施塔姆, 格雷格 史密斯 申請人:Bea系統(tǒng)公司