CN1511290A - 用于基于规则的万维网方案与活动的系统与方法 - Google Patents

Abstract

本发明利用一种个性化系统，其使用规则以裁定并表征客户或客户动作，然后基于这些规则(图1，102、104、106、108、110、112、113、114、116、118、120)的结果个性化业务功能，如显示的页。规则可能用来生成方案——表征客户会话的潜在事件序列。方案可能形成活动的基础——可能的方案的集合，可能具有起始与终止时间，其间客户进行操作，并在其中该基于规则的系统作出决定并确定个性化。在一个实施例中，本发明提供了一种基于规则的系统，用来定制电子商务应用的内容，该系统包括：服务器，用来与规则引擎以及商业应用来往传递信息；规则引擎，用来解析规则集的内容，以对当前进程作出明智的决定，并确定动作；具有多个规则的规则集，其中每条规则定义了情况与活动；以及，用来存储所述规则的规则库。

Description

用于基于规则的万维网方案与活动的系统与方法

                           版权声明

部分本公开专利文件包含受版权保护的材料，本版权的所有人不反对任何人以传真再现如在专利与商标局的专利文件或记录中所出现的本专利文件或专利公开文本，但保留其他所有版权权利。

                            优先权

本申请要求名为“用于基于规则的万维网方案与活动的系统与方法”的临时申请优先权，申请号为No.60/283,977，于2001年4月16日提交，此处包括其内容作为参考。

技术领域

本发明涉及在线的，尤其涉及万维网驱动(Web-enabled)的系统，还有关用于为用户或用户组个性化应用的行为与内容的方法。

背景技术

在电子商务领域，存在要求企业能够改造其产品与服务以更好地适应其客户的需要与要求的需求。在企业对企业(B2B)与企业对消费者(B2C)领域都存在这种需求。这种改造企业服务的具体例子出现在个性化领域。个性化允许企业个性化或以其他方式定制其向特定客户或客户组所提供的东西。例如，在互联网/万维网环境下，B2C内容提供商可能希望部署一网站，其中，对每位访问该站点的单个的客户或对每一基于某些特征的客户类型，都将该网站的内容个性化。这种基于万维网的B2C提供商的例子包括：在线目录商品提供商；产品销售商；新闻、媒体与娱乐提供商；以及信息或参考源。

随着其业务成功变得越来越依赖于可靠的个性化服务，电子商务提供商对其个性化系统提出了更多的要求。普遍地要求一种个性化系统，其不仅能够帮助提供商提供个性化的网站，而且允许电子商务提供商在一个源点上定制其所有业务功能—营销、生产、分销等等，以及更新这些功能所依赖的信息或数据，所有这些都是以迅速、可靠、并容易修改的方式进行，需要很少或不需要系统中断时间。

用于个性化网站内容的现有系统在本质上主要是分析性的，并依赖于使用先前收集的数据，该使用数据的方式允许管理员基于对该数据的理解修改网站或电子商务应用。例如，来自如ATG与Broadbase等销售商的个性化系统(这些销售商主要提供在线分析处理(OLAP)系统)，其依赖于商业提供商收集大量的数据，大到足以用分析方式(即统计方式)表示其目标人群，然后使用该数据以对该人群的子群个性化内容。可以用传统机制收集数据，即通过标准市场调研工具，或者通过诸如保持客户的先前使用历史在线地收集数据。然而，在随后分析并使用这些数据以允许管理员更新实际的内容之前，这些数据一般存储在库中以备进一步分析。在这种方式中，数据不是被用来提供系统的实时个性化，或在运行时管理员易于修改的个性化。而是更多地使用该数据表示在较长时间段内对一大批用户的内容改变。没有人试图在用户或客户的实际会话内在单个用户级上定制数据内容。

随着当今电子商务对实时更新个性化的用户内容、和/或可供产品与服务的需求的增长，对当应用运行、甚至当客户在会话内进行有效操作时，允许管理员迅速定制呈现给客户的内容的系统的需求也不断增长。另外，允许自动实施这种修改的系统，即通过使用规则或某其他机制以改变在用户会话内向其呈现的内容的系统，尤其有用。随着最终用户愈加成熟并向内容提供商要求更高质量的服务，以及随着后端商业应用愈加复杂并灵活到能够提供此类细致的内容变化，对允许或支持向用户提供实时个性化数据内容的功能的系统的需求也不断增长。能够作到这一点并且同时在设置数据内容与营销活动时十分易于使用的系统尤其有用，这是因为这些系统允许管理员迅速地管理实际的内容与规则，向用户发送内容时依靠该规则。

发明内容

本发明提供一种系统与一种方法，用来允许电子商务提供商为每个客户、客户群或特定客户类型定制或个性化其业务功能或内容。一个简单的网站个性化的例子，以使每个到访客户能够看到也许略为不同的、为其特定需求定制的站点内容。然而该系统同样可用于任何能够从个性化中受益的业务系统。此处所指的用户或客户可能是个人或任意其他实体，如另一个组织或公司。用户访问的业务功能可能不属于在屏幕上显示的那种类型，而可能是(例如)自动方式定单检索、处理、与其他操作。本发明允许在处理过程中的任意步骤以及任意实体之间个性化应用行为与数据。

概括而言，本发明提供了一种个性化系统，其使用规则以裁定并表征客户或客户动作，然后基于这些规则的结果个性化业务功能，如数据通信或被显示的页。规则可能被用来生成方案(scenario)—表征客户会话的潜在事件序列。方案可能形成活动(campaign)的基础—可能的方案的集合，具有联合起始时间与终止时间，其间客户进行操作，并在其环境下基于该规则的系统作出其决定，并提供表征与个性化。

在一个实施例中，本发明提供了一种基于规则的系统，用来定制电子商务应用的内容，该系统包括：服务器，用来与规则引擎以及商业应用来往传递信息；具有多个规则的规则集，其中每条规则定义了潜在情况与相应动作；规则引擎，用来解析规则集的内容，以对当前进程作出明智的决定，并确定动作。

在互联网和/或网站的环境中，本发明的实施例可以被用来基于网站用户的会话信息向其展示个性化的内容。在这类实施例中，用户使用的万维网应用可能是诸如商业网站应用，如在线预定系统(例如航班定座)或目录产品订购。当用户登录进入此类应用时，生成会话，并且发生与该会话相应的事件。这些事件被用来驱动基于规则的引擎，该引擎随后被用来驱动内容的提供。可以根据用户特征集作出有关该用户特征集的推论，然后可以就该特征集运行规则，所有这些都在实时进行，并且不需要参照辅助的个性化源，如统计的或市场信息的库。

附图说明

图1示出根据本发明实施例的基于规则的个性化系统的示意图。

图2示出根据本发明实施例的基于规则的个性化系统的运行的图例。

图3示出根据本发明实施例的方案规则与动作过程的流程图。

图4示出根据本发明实施例的活动生命周期的示意图。

图5示出根据本发明实施例的方案接口的模型。

图6示出根据本发明实施例的文件接口的模型。

图7示出根据本发明实施例的活动服务的模型。

图8示出根据本发明实施例的行为跟踪监听器的模型。

图9示出根据本发明实施例的占位符确定过程的生命周期图。

图10示出根据本发明实施例的活动部署过程的生命周期图。

图11示出根据本发明实施例的广告服务过程的生命周期图。

图12示出根据本发明实施例的点击进入Servlet过程的生命周期图。

图13示出根据本发明实施例的事件服务行为跟踪监听器的示意图。

图14示出根据本发明实施例的工具框架的示意图。

图15示出根据本发明实施例的编辑器、数据、以及工具框架内的模型所处位置的示意图。

具体实施方式

在描述本发明时将用到下列术语表与名词、缩写、与简称的定义。

B2B     企业到企业(Business to Business)

B2C     企业到消费者(Business to Consumer)

CMS     内容管理服务(Content Management Service)

DASL    DAV搜索与定位(DAV Searching and Locating)(IETF草案)

DMS     文件管理系统(Document Management System)

DTD     文件类型定义(Document Type Definition)(用XML)

EJB     企业JavaBeans(Enterprise JavaBeans)。服务器组件体系，用于写Java服务器组件。

FIFO    先进先出(First In，First Out)

I18N    国际化(Internationalization)

J2EE    Java 2企业版(Java 2 Enterprise Edition)

JSP     JavaServer页(JavaServer Pages)。J2EE组件，用于生成动态网页内容。

JNDI    Java目录与命名接口(Java Directory and Naming Interface)。协议标准，用于查找对象与资源。

OOTB拿来即用(Out Of The Box)

RDBMS关系型数据库管理系统(Relational Database ManagementSystem)

SPI    服务提供者接口(Service Provider Interface)

TagLib  JSP标记库，包含JSP标记定义。

WLS     WebLogic服务器

UUP     统一用户特征集(Unified User Profile)

XML     可扩展标记语言(Extensible Markup Language)

本发明提供了一种基于规则的实时个性化引擎，可用来个性化并定制业务功能、应用或待交付客户或系统用户的信息内容。在本发明中，客户或用户可能是个人，如网站的个人用户，或者可能是另一组织，其使用交互式的或自动的机制来与系统通信。在用户与系统交互时，生成事件，所生成事件用来驱动基于规则的引擎。按照所使用的特定规则，个性化引擎实时地确定应该向用户传送那些内容或信息。例如，此内容可能是用户在网站显示上所看到的特定信息，或者可能是某种其他数据通信形式，例如，被自动传送给无线应用协议(Wireless Application Protocol，WAP)设备或个人数字助理(Personal Digital Assistant，PDA)设备的数据，用户未必看到该数据。根据本发明的一个实施例，用XML文件配置该基于规则的引擎的工作，这样便使管理员只需编辑XML文件的文本便能够迅速并且容易地改变该基于规则的引擎的运行。因为该基于规则的引擎可被用来控制业务功能，而不单单只是数据在屏幕上的显示，所以本发明为各组织提供了为每个客户或客户类型个性化其业务功能的能力。

该个性化系统的操作通过使用活动与方案而得到简化。在本发明中，方案是事件集合，事件引起某特定规则被触发并且引起相应的动作、业务功能或数据被显示。活动可能包括许多方案，并提供了一套简单机制，通过这套机制，管理员能够控制整个方案集合，以最恰当地反映特定用户或用户组的需求。

图1就个性化系统可以用于本发明的一个实施例，即向用户提供个性化的内容(例如在网站的情况中)，示出了个性化系统的概括示意图。如图1所示，规则引擎102解释定义方案110与活动112的规则，以选择特定的方案与活动设置集合，用于向用户显示内容。方案118与活动120可以被存储，以被将来需要时激活。规则被用来定义规则引擎102(和可选分离的方案引擎104与活动引擎106，尽管将清楚这后两个引擎的功能可以由规则引擎102独自承担)的操作，并具体地告诉规则引擎在选择与生成用于向用户116的显示114时应该使用各种方案与活动之中的哪个方案与哪个活动。

基于规则的引擎

本发明的中心部件是基于规则的引擎。该基于规则的引擎使用规则，以对当前进程作出明智的决定，并确定此后的动作。每条规则都定义了情况(“如果”子句)与动作(“那么”子句)。使用这类规则就可以将情况与动作以流程图的方式链接成方案。规则存储在一个规则集或多个规则集内。在本发明中，规则集指相关规则的汇集，这些规则捆绑在一起以便规则引擎可以将其一起使用。规则集与规则被用来指导方案与活动中事件的流动。

根据本发明的一个实施例，可以以XML格式书写规则以便于在系统间的可移植性。另外，XML模式可以被实时解析，这便允许对规则(以及业务工作流)的实时修改，而不要求系统中断时间。还有，因为用户特征或特征集可以由一系列规则计算，所以系统提供了一套机制，通过这套机制，可以在被要求时生成用户的实时“快速印象(snapshort)”，并将其用来向该用户提供个性化内容或服务。

方案

方案是情况与动作链。方案描述了与用户之间可能的交互的流程图。活动使用这类方案的集合，以为主办者达到业务目标，或者处理特定的业务功能。在网站或类似B2C的情况中，活动可以通过方案使用在线广告、电子邮件、与打折促销，以得到该目标。

方案代表抽象功能。然而，在活动中所使用的方案可能建立于任意企业到企业、企业到消费者、或电子商务平台(如BEA Systems的一系列WebLogic应用服务器商业服务器产品)之上。

根据一个实施例，方案被单独命名，并且具有类别列表，其对每一方案有效。通过方案引擎，基于诸如名称、描述或类别类型等准则搜索特定方案。该搜索可能包括全字匹配与模式匹配(如类‘*superbowl*’的表示)二者。搜索结果是匹配该搜索的方案的名称。在实时交付内容时，系统可以将当前情况与共享方案迅速匹配，并据此作出反应。

方案引擎作为方案定义库。方案定义可能以XML格式存储，以便于编辑，但也可能使用其他格式。方案引擎还能够按名称返回方案的XML定义，并且能在给出方案定义时部署方案。

方案由规则集构成，规则集具有其组成规则。每条规则定义了情况(“如果”子句)与动作(“那么”子句)。使用规则就可以将情况与动作以流程图的方式链接成方案。

方案规则集的可能输入(那些“如果”)包括，但不限于：

用户个人属性；

执行类别规则集合的结果；

用户当前会话与请求信息(这可能包括(例如)用户的购物车(ShoppingCart)或其页位置)；

在会话中发生的事件；

当前时间；或，

随机数(以允许系统进行基于概率的运算)。

使用方案规则编辑器，系统用户(例如，一般为系统管理员)能够为任意输入编写定制规则，包括(例如)用户特征集，用户会话的内容(具体为用户的购物车)，用户当前请求信息(浏览器类型、页位置等等)，特定用户历史事件(如购物历史)，事件的类型、头部、或主体(在TextMessage中文本主体等等)。规则集的可能输出(“项目”)包括动作定义—待执行的(ActionDef)—即系统为响应输入而必须实施的一个或多个动作。这可能包括交付特定内容类型。

方案只对特定用户类别(即客户分组)有效。

规则引擎自身并不执行任何功能(即其不生成动作，如投寄事件等等)。而是从规则引擎传送辩识对象给方案引擎，然后方案引擎根据其方案库执行所请求的动作。

在一般使用中，对规则的估算将声明动作定义(ActionDef)。该动作将导致发生某事，或向用户显示某物。用户将作产生事件的某事。该事件被送给方案引擎，重复此循环直到(可能)达到终止状态。

活动

活动是有发起者的方案集合，被设计用来达到特定目标。在营销的情况中，活动可能被设计来在特定时间段内促销某类商品。其他活动更概括一些，因为其只包括该公司或组织当前想实施的(一般相关的)方案的集合。每个活动都与一个或多个方案相关联。活动可被标记为有效或无效，并且一般有指定的开始与停止事件。通过活动引擎，能够基于如名称、开始和/或停止事件、类别(通过与方案的关系)、发起者名称、描述、价值提议、目标描述与有效状态等准则搜索活动。

该搜索可能包括全字匹配与模式匹配(如类似‘*superbowl*’的表示)二者。搜索结果是匹配该搜索的活动的名称。然后，与此活动相关的方案就可以通过在方案引擎上的搜索检索。

活动引擎作为活动定义库。如同方案定义，活动定义可能以XML格式存储。活动引擎还能够按名称返回活动的XML定义，并且能在给出活动定义时部署活动。

图2示出根据本发明的实施例如何将活动方案与规则一起使用，以提供一套个性化系统。如图2所示，事件服务130用来接收特定事件，并向活动事件监听器130发送该事件的通知。事件是用来在规则引擎内触发实时改变的驱动力量，规则引擎再确定给用户的输出。例如，事件可能是用户登入事件，或在万维网应用的情况中，为来自用户的选择特定页或提交特定类型表的请求。事件不必一定触发规则使其生效，这是因为事件服务可以有意忽略某些事件。活动事件监听器132也可以用来过滤特定事件类型，将该事件送往活动服务134以进一步处理。活动服务134加载当前有效的活动，即那些管理员指定的或当前在位的活动。如果其接收的事件来自某特定活动，则活动服务加载该活动。然后其使用该活动信息以建立活动方案标识的映射集，并将此信息送往方案服务136。方案服务136作为活动服务134的子集，并被用来过滤用户已到达终止状态的方案。如果用户已到达终止状态，则意味着系统一方不需再做其他工作，并且用户负责确定下一步。然而，如果用户还未到达终止状态，则方案服务循环，以确定该事件类型对现行的特定方案规则集合是否有效。如果无效，则可忽略该方案。如果需要其他客户分组，则方案服务也可用来执行类别规则集。方案服务还可能被用来执行方案规则集，并得到动作定义列表。为进行这种处理，方案服务136使用来自规则管理器138的规则，以确定对该特定方案的现行规则。一般每条规则都指定至少一个或多个动作定义。对每个方案的每个动作定义，方案服务都从动作服务140取得动作对象。在其运行每个动作对象时，依赖于实际的实现，可能发生不同的事件。例如，如图2所示，这些事件可能驱动的动作如：终止方案动作142，其使用方案服务144来为该活动方案的用户设置终止状态；广告占位符动作146，其使用广告桶服务148来向用户桶中放入广告查询；邮件动作149，其使用邮件服务150来将给用户的邮件打包以备将来发送；以及提供折扣动作152，其使用折扣关联管理器154来在其会话上向用户提供折扣。虽然图2所示的例子示出了本发明所能提供的多种特征与服务，但本领域的技术人员应该清楚所示的事件例子并非穷尽，而只是例示了本发明可以使用的事件、方案与服务的类型。应该清楚，可以添加其他事件、方案与适当的服务类型，以最适当地满足特定组织或电子商务应用的需求。

图3示出可用于本发明的一个实施例的典型过程的流程图，该实施例向系统客户或用户提供实时的个性化内容。如图3所示，在步骤160，规则引擎一旦被启动，则确定在该情况下使用的特定规则组。在步骤162，使用“如果...那么...”子句计算规则，其中系统读入用户会话的当前状态，即“如果”部分，并从潜在方案集合中确定输出应该是什么。在步骤164，该输出被声明为动作定义，其确定系统在该特定情景下应该如何响应该特定用户，即应该采用什么动作。在步骤166，该输出(如果有的话)作为结果向用户显示。以后将清楚，系统可能决定采用不同于实现显示的动作，而是传送数据或以其他方式改变某业务功能或应用。在步骤166，在随后的任意时间点上，如果用户通过其动作引起另外事件的发生，则在步骤170，该事件被送往方案引擎(或如果使用单一引擎，规则引擎标识)。在步骤172，方案引擎将信息续传回规则引擎，以备随后的规则确定时使用，其将确定该系统应该如何响应随后的事件。

活动目标与激活

活动可以两种方式使用目标。第一，目标是可被用来更清楚地阐明活动目的的文本描述。第二，目标是活动所能达到的定量尺度。根据一个实施例，所有活动都有是否有效(is-active)规则，其接收以下输入：

活动数据对象；

对广告接触(ad exposure)与点击次数的访问；

事件；以及，

当前日期与时间。

该是否有效规则的输出为真或假。真表示此活动当前有效。假表示其无效，并且将不会有另外的处理发生。存在灭活活动的机制，不管活动的激活准则如何，管理员总能激活或灭活该活动。在计算激活或方案规则前，首先检查该状态。另外，活动可以有开始与停止时间，其确定活动的有效状态。

活动生命周期

图4示出将活动添加到运行环境中或从其中移除的过程。首先必须启动活动180。这一般发生在活动被第一次部署时，然而可以推迟启动，直至发生手动过程。本发明的某些实施例允许指明逐个方案的启动规则。在启动时，触发该活动的这些逐个方案的启动规则。输入为活动数据对象与当前时间，输出为待执行的动作定义(ActionDefs)。

在活动确实被启动后，随后变为有效182，这一般基于活动的开始时间，或显式地标记该活动为有效活动。在第一次成为有效后的任何时间，由于到达活动的预定停止时间，或者达到了活动的目标(即“如果...则是否有效”规则)，或者管理员灭活该活动，该活动都可以变为或被标示为无效184。在被灭活后，在某些情况下，该活动可以再次变为有效，这一般是通过管理员对其修改、重新部署并将其标示为有效。

在某些实施例中，在启动后的任何时间，活动也可以被关闭186。这一般是由管理员进行的手动过程。在关闭时，执行所有的逐个方案的关闭规则。对这些规则的输入为活动数据对象与当前时间。输出应该是活动引擎所要执行的活动定义(ActionDefs)。这些活动一般撤消源自启动规则的所有活动，尽管没有要求必须这样作。

活动被关闭后，其被清除188。这涉及移除所有活动相关数据(如广告接触计数、方案状态信息等等)。这也可能涉及将活动定义从活动引擎库中移除。

报告/分析

活动由事件驱动。另外，广告接触与点击进入(click-through)计数由活动服务维护以备活动使用。这些也可以被访问，以备报告使用。

动作服务

动作服务将动作的概念抽象化，动作应该由方案引擎根据规则集的结果执行。这就允许规则声明具体动作的一般化定义。该动作定义(ActionDef)可用来取得对能执行其下动作的对象的访问。这样不用重新启动服务器，新动作就可以被生成并被部署。这样作的一种途径是部署会话EJB(SessionEJB)，其可以提供具体动作对象。

方案工具可使用动作库。在一个实施例中，该动作库可用XML文件描述。方案工具使用动作库以向用户动态显示动作，并且从用户收集该动作的所有参数。为活动预先定义的动作集合可以包括如下：

在用户或全局占位符中放入广告组(查询)与权重。

从用户或全局占位符中移除广告组(查询)。

向用户提供有名折扣。

从具有主题的URI生成给用户的电子邮件。

占位符

占位符(Placeholders)表示在JSP中的位置。占位符的行为取决于具体系统的配置。这与方案的动作概念十分相似。然而，占位符的动作主要由请求驱动，而不是由事件驱动。在一般实现中，于网页上的请求来自于包含占位符JSP标记的JSP页的网络用户。该标记联系会话EJB，该会话EJB将返回描述应该发生的行为的对象。该行为可能是可显示的单元。在可显示单元的情况中，该可显示单元将包括表达器(renderer)对象，该对象知道如何显示该单元。

广告占位符(Ad Placeholders)

在那些将该发明用于广告生成的环境中，可将占位符用于显示广告。对于显示广告的占位符行为，使用用于占位符的用户广告桶(bucket)。该广告桶包含应该向用户显示的广告集合或广告组，再加基于桶项的查看计数。桶中每一项具有下列信息：用户名称；占位符名称；输入的日期与时间；广告查询(定义了待显示广告或广告组)；权重；查看计数；活动名称；方案名称。

在某些实现中，对每一个占位符都可能有一未绑定到具体用户的广告桶(即全局用户桶)。除此之外，桶中的每一项将具有相同信息。

因为广告桶可能从占位符请求(即由活动/方案引擎)外部填充，所以可以使用广告桶冲突解决机制。该冲突解决机制确定在用户的广告桶中哪项被真正使用，以找到待显示的广告。在一个实施例中，使用有效桶项的权重。如果桶项的相应活动当前有效或者未与活动关联，则该桶项有效。一单一项的权重使其被查看的可能性为(权重*100/所有权重之和)。使用随机数来确定使用哪个桶项。例如，如果桶中有四项，权重为1、2、3、4，则其安排可能为(例如)：

项          权重        公式                        被使用的可能性(％)

广告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％

一旦确定了项，则执行该项的查询以产生广告集合(即广告组)。组中的每一广告都将有自己的权重。采用类似的算法确定使用组中的哪个广告。如果发生某事使广告组的大小为零，则系统选择使用新桶项，而忽略先前选择的桶项。如果不存在用户桶项，则用类似方式检查全局用户桶。一般全局用户桶通过活动启动规则填充。

在本发明的一个用于具有广告的网站的实施例中，向用户显示特定广告可以生成事件，对广告的点击进入也会可以生成事件。在两种情况中，将该广告放入广告桶中的活动与方案的标识都与该事件一起被传送。这就使系统将“看到”与“点击进入”事件反向绑定到广告与活动两者之上，以备随后的分析与报告目的。

广告服务

广告服务提供广告元数据与内容，以备随后向用户显示。该服务能基于广告的唯一标识符或基于对广告元数据的搜索检索该广告。广告可能包括(例如)：具有可选点击进入的URL的单一图像、替换文本、边界规范、宽度、高度、鼠标悬停文本；HTML文本块(其可能包括点击进入的URL)、再加该HTML块引用的任何补充媒体；或者对嵌入JSP页的引用。

所有广告都有相关的相对权重，该相对权重可能是整数。特定广告的权重可用来解决广告显示冲突。

在一个实施例中，广告服务记录广告后印象(following ad impression)(用户看到了什么)，以及逐个广告的点击进入事件计数：全局计数；与逐个活动计数。

该信息用来处理活动目标评估。另外其还可用于报告。逐个用户的广告计数可通过事件服务处理。

在某些实施例中，可能有机制来查询广告服务以查看、增大、以及减小这些计数。这些信息随后立刻被活动或方案引擎使用，因此这些信息必须在以上细节水平上可检索。

电子邮件服务

电子邮件服务可用来支持基于电子邮件的活动。基于电子邮件的活动允许系统将个性化的电子邮件内容指向用户或用户组。在一个实施例中，电子邮件服务基于配置支持两种运行模式：批量模式或通过模式。通过模式使该服务立刻发送电子邮件请求。批量模式使该服务将电子邮件请求存储于数据库，可以在以后的时间从该数据库发送该请求。可以使用管理员界面或命令行程序以启动打包的电子邮件。电子邮件服务所要求的信息为：标准电子邮件头部信息(如，To，From，Subject)，MIME电子邮件头部信息(如Content-Type，Content-Length，Content-Disposition，其中某些可能从电子邮件主体确定)，电子邮件主体，发起电子邮件的活动与方案的标识，以及电子邮件多长时间有效(即，如果5天内还没有发送，则不用再管)。

活动与方案的部署

在活动与方案运行前，必须将其部署到服务器上。在一个实施例中，可以使用能够将XML定义传送给适当部署服务的Servlet(小服务程序)。

活动与方案服务从XML文件取得输入，而这些XML文件可以由管理员工具集生成。使用了用于活动与方案定义的模式，也使用了用于方案规则的模式。

管理员可以使用这些管理工具来产生并部署活动与方案定义。这些工具生成表示这些定义的XML文件，并通过部署器Servlet部署这些新定义。该Servlet接收XML数据流，并调用适当的服务以处理该数据。活动、方案、及其相关规则可以分别部署。一般先部署规则，随后是使用它们的方案，最后是由方案构成的活动。当部署活动或方案时，相关服务将XML定义保存在中心数据库或库中。

EJB实现

以上描述的服务可以作为无状态服务集合实现—在一个实施例中，例如，作为一组符合EJB规范的无状态会话Bean。下面各节详细描述本发明的实施例，其使用EJB的以提供支持方案与活动所必须的服务与功能。将会清楚可以使用其他类型的资源，以替代或补充EJB。

方案服务(Scenario Service)

方案服务被设计用来允许系统与用户间的交互流程被定义为规则与动作集合。

方案会话Bean(Scenario Session Bean)

方案会话Bean为方案功能的外部接口。当由方案服务收到事件时，其确定系统中是否有任何方案应该相应该事件。如果有，则该服务将该事件传递给每一个感兴趣的方案，然后让这些方案在该事件所包含的信息上运行各自的规则。该会话Bean还提供功能以重新部署方案，并将现存方案以XML导出。

方案对象(Scenario Objects)

方案作为规则集(RuleSet)的包裹程序，包含某些附加的业务逻辑。当方案从方案服务中接收到事件时，先作检查以保证该事件对本方案有意义。如果没有意义，则该方案立即返回。否则，如果有意义，则其将事件中包含的信息以及本方案中包含的规则集一并传递给规则服务。方案规则在启动时产生动作定义。在执行完规则集后，方案将使用动作服务以执行所产生的动作定义对象(如果有的话)。这就防止了由规则产生的动作在规则引擎线程中执行。

动作对象(Action Objects)

当方案为其所收到的事件运行一组规则时，通常将执行某些动作以作为这些规则的结果。为达此目的，规则创建并初始化动作定义(ActionDef)对象。这些对象必须用其所代表的动作的名称及该动作运行时所需要的参数的映射集来初始化。它们负责实例化动作接口的实际实现，该实际实现作实际的工作。该接口包含使用有名参数的映射集的init(初始化)方法，以及执行该动作的run(运行)方法。规则被设计用来指挥规则引擎用来自事件、当前用户、或任何其他可用资源的数据正确地初始化动作定义。例如，一发送电子邮件的方案将包含规则，该规则返回由适当参数的映射集初始化的动作定义，所述参数如接收方电子邮件地址及消息的文本，以及该动作的名称，即SendEmailAction(发送邮件动作)等等。在这些规则执行完毕后，方案将使所返回的动作定义对象检索实际的动作实现。当调用该动作的运行方法时，其将使用初始化参数来完成其任务，在本例中为启动电子邮件服务以发送消息。

EJB广告服务(EJB Ad Service)

广告服务提供了基于系统的当前用户来检索广告的途径。其包括广告桶服务会话Bean(AdBucketService session Bean)以及较低级的广告服务(AdService)会话Bean，其中前者负责管理应该向哪些用户显示那些广告，后者作为到内容管理服务的直通通路。

广告桶服务(Ad Bucket Service)

广告桶服务(AdBucketService)是无状态会话EJB，用来向占位符提供广告内容。这是通过查看指向占位符的广告并生成有效广告集合来完成的。然后，该集合被传送给广告冲突解决器(AdConflictResolver)，其用来挑选出实际待提供的广告并更新广告信息。来源于此的广告查询被送往广告服务以挑选实际的广告。如果没有找到有效广告，则检查全局广告桶以查找广告。广告桶服务还提供了向用户广告桶添加广告的方法。一般在来自方案的事件引起了添加广告动作(AdAction)的触发时，该方法被调用。广告桶服务还提供了接口，其允许清理活动状态。更一般地，该接口将基于方案容器的名称从用户桶中移除内容。活动只是方案容器的一种实现。

广告信息(Ad Info)

广告信息(AdInfo)是包含输入到数据库中的信息的某些子集的数据结构。用于用户广告信息的数据库表项可能包括以下：

userName—用户的名称；

placeholderName—该广告将指向的占位符名称；

scenarioContainerName—生成该广告的方案容器(活动)的名称；

enterDate—该广告的输入日期/时间；

adQuery—传送给广告服务以生成该广告实际内容的查询；

expirationDate—该广告失效日期；

weight—权重与查看计数(viewCount)被用来挑选广告；

viewCount—；以及，

scenarioName—将该广告添加到活动中的方案的名称；

广告冲突解决器(AdConflictResolver)

广告冲突解决器负责选择向用户显示的“最佳”广告，并更新数据库中的广告。该方法向广告集合使用选择所显示的“最佳”广告的算法。然后根据该算法更新权重与查看计数(ViewCount)。

广告服务(AdService)

广告服务(AdService)是独立部署的无状态会话EJB，其实现文件管理器(DocumentManager)接口并代理文件管理器。广告对象可以是在文件管理器中部署的文件对象。

点击进入Servlet(Click-Thru Servlet)

此Servlet用来跟踪广告点击进入事件。从广告桶服务输出的内容将包裹广告并将其指向此Servlet。点击进入Servlet(ClickThruServlet)是记录用户在广告上的点击的中心所在。这可能引发活动事件。在处理完点击进入事件后，此Servlet将用户重定向到目标页。

EJB占位符服务(EJB Placeholder Service)

占位符表示JSP页中的命名的位置，在其上可由商业服务器放置内容。其由占位符JSP标记表示。在该占位符标记之后是占位符服务(PlaceholderService)，为无状态会话EJB。占位符服务负责将内容返回给JSP页。

内容从内容处理器EJB检索而来，该内容处理器EJB实现内容桶(ContentBucket)接口。当定义占位符时，为有名占位符登记内容处理器。

占位符标记(PlaceholderTag)

占位符标记用来将来自占位符服务的内容放入JSP页中。占位符是有名实体。占位符标记定义四个属性：名称—系统内该占位符的名称；高度—可选的内容高度；宽度—可选的内容宽度；表达器—可选的有名EJB，其可以对从内容桶输出的内容在通过该占位符标记返回之前进行转换。

占位符服务(PlaceholderService)

占位符服务是无状态会话EJB，其主要职责是将内容返回给占位符标记。另外，它提供用于占位符定义、以及用于占位符查询的方法。查询方法可由工具使用来生成下拉列表等等。占位符定义方法为系统定义新占位符。名称必须唯一，并且内容桶名称(ContentBucketName)必须为定义内容桶(ContentBucket)接口的EJB。占位符将在数据库表中定义，其包含以下信息：名称—占位符的唯一名称；类型—表示内容桶生成的EJB的名称；以及占位符的内容。

内容桶(ContentBucket)

内容桶接口定义了占位符服务用来接收内容的接口。该接口将由“桶”实现。折扣桶(DiscountBucket)也是内容同。

内容转换(ContentTransform)

这是一抽象基类，其实现对内容桶的输出在返回给占位符标记之前进行的转换，并作为其中系统可以对内容桶输出执行XSLT类型转换的连结点。

EJB电子邮件服务(EJB Email Service)

电子邮件服务会话Bean为通用平台级服务以提供发送电子邮件的功能。它提供实时电子邮件功能，也提供批量电子邮件功能。在最简单的情况中，通过提供接收方地址，主题与消息文本就可以发送电子邮件。可以在服务器部署中指定默认的发送方地址。

电子邮件打包(Email Batching)

电邮件服务还提供将电子邮件集合打包以备以后发送的功能。在活动的情景中，可使用这一功能来在用户生成事件时逐渐累积有关促销或特别报价的电子邮件，然后在促销开始后将其一次发送。电子邮件包可由字符串标识确定。在活动的情景中，这可以是活动的名称。每个包都有日期，用来确定其何时被发送，或者可能是范围，以便使在开始日期前加入包中的电子邮件被打包，而日期范围内加入的电子邮件被马上发送。

EJB活动服务(EJB Campaign Service)

活动服务是本文件所涉及的最高级别的服务。活动是发起者的被设计用来达到某目标的方案集合。

活动服务会话Bean(Campaign Service Session Bean)

活动服务会话Bean是活动与系统其余部分之间的接口。其实现事件监听器接口，以便其能接收应该由组成活动的方案所处理的事件。该会话Bean还提供功能，使工具能部署新活动，并且以XML检索活动定义。

活动对象(Campaign Object)

活动包含一组方案，还有一些有关活动本身的信息，如开始与终止日期。

活动自举(Campaign Bootstrap)

在有些实施例中，活动可能还包含自举规则，当部署活动或服务器启动时，执行该自举规则。自举规则可作的事情如：将项放入全局广告桶中以便向用户显示活动的广告内容，而不用触发由活动方案之一所识别的事件。

部分活动定义为日期-时间集合与时间范围，其间该活动有效。这些范围也可以为负；例如，可能有日期范围从12月18号到12月25号，以及无效时间范围上午8点至上午11点。这使活动在12月18号到12月25号之间而非上午8点至上午11点之间认为自身有效。对活动的“是否有效”(isActive)的第一次调用中有一部分将检查这些日期范围与当前日期/时间，以便不用启动规则引擎而短路该调用。

另外，在某些实施例中，可以为活动定义激活规则。激活规则可能返回真或假，并在验证了有效日期范围后被调用。这提供了在运行所有属于活动方案的规则集前短路该调用的另一种方法。激活规则还提供了一种途径，通过使该规则检查目标条件并且如果已达到目标则返回假，以在达到“目标”时停止活动执行。

接收事件(Receiving an Event)

当活动通过活动服务接收事件时，通过查看自己的开始与终止日期范围，以及所定义的任何时间范围，然后还可能运行自己的激活规则，活动先检查确认自身有效。如果任意一项检查失败，则认为活动无效，并且不再进一步执行。如果活动确定自身有效，则其将事件传送给其每一个方案，以便它们都能够通过运行自己的规则集，并执行由此产生的任何动作来对该事件作出反应。

活动后的清理(Cleaning Up After a Campaign)

根据一个实施例，活动定义还可以包含“清理规则”，其在活动被撤消时执行。这就给活动一次机会，以便删除在其运行时可能创建的任何信息，如广告桶中的广告查询。如同方案中的规则，此规则将返回零或更多个动作对象，这些对象被执行以进行清理。将会清楚，也可以采用其他清理方法。

部署器服务(Deployer Service)

部署器组件的接口为部署器(DeployerServlet)。这是标准Servlet，其接收包含待部署数据的XML流，并将该流转接到适当的工具类(helperclass)。该Servlet的配置信息将包含将XML文件类型映射集到部署器工具接口的实现的信息。当该Servlet接收XML数据流时，其将检查文件类型，并且初始化部署器工具的正确的实现以处理该类型。每个部署器工具的实现都将知道如何部署来自XML流的数据。这由各个组件负责；其可能调用会话Bean以处理实际的部署，或者可能直接将该数据输入到数据库中。

EJB事件服务(EJB Event Service)

除通过JMS的异步事件处理之外，活动与事件要求具备处理可能同步的事件的能力。在事件特征集合类型中，每个特征集的名称将对应一事件类型。在我们或我们的客户添加新事件类型时，此机制将允许扩展编辑器。支持下列事件类型与特征集合，然而显然在本发明的精神与范围内还支持其他事件类型。

登入事件(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        字符串        广告显示所在的占位符名称。可为空。

结帐事件(Checkout Event)

特征名称               类型          描述

User                   用户          登入用户

userId                 字符串        登入用户的标识

shoppingCart           购物车        在结算时用户的购物车对象

向购物车添加事件(Add to Shopping Cart Event)

特征名称        类型          描述

User            用户          登入用户

userId          字符串        登入用户的标识

Item            产品项目      所添加的产品项目

quantity        整数          所添加的数目

从购物车移除事件(Remove from Shopping Cart Event)

特征名称        类型          描述

User            用户          登入用户

userId          字符串        登入用户的标识

Item            产品项目      所移除的产品项目

quantity        整数          所移除的数目

典型实现

以下小节描述根据本发明的一个实施例的个性化系统的典型实现。将会清楚在本发明的精神与范围内可以使用替换实现。

图5示出方案服务的一个实现的模型图，显示了方案服务如何使用名称或搜索模式访问方案。如图5所示，该方案服务包括了用于处理事件，以及用于按名称查找或检索方案的机制，方案服务190使用方案接口192以按名称、描述、类别名称、长描述、方案规则集名称、或分类器规则集名称来查找或保存方案。XML接口允许方案服务从XML文件中读出方案，并且将修改后的方案保存到XML文件。方案容器接口194用来指明方案是否有效。

图6示出在本发明的一个实施例中如何使用内容管理器来向用户提供内容。如图6所示，内容管理器200使用内容接口206，从文件管理器202与广告服务204检索所输入的数据。文件接口208允许存储和/或编辑有关文件的其他信息，包括作者版本号等等。

图7示出用来在事件发生时对其响应的活动服务的一个实现的模型。如图7所示，活动服务220与方案服务190使用经活动接口224来自规则集的信息。活动接口224将信息送入方案容器194以备显示内容时使用。事件监听器228将有关所发生的事件(重新登入、页命中、点击进入等等)的信息送入活动监听器230以备活动服务220使用。活动接口224使用规则信息232与基于规则的方案链接234来访问方案接口192。

图8示出事件服务240的模型，其使用事件监听器接口228以接收事件242的通知。该信息被活动监听器230截收，以确定系统和当前用户当下感兴趣的事件。在一个实现中，事件服务可被行为跟踪监听器224修改，该监听器使用关于用户行为的信息来帮助确定将被监听的可能的事件类型。可以使用标准Java JMS方法246，以向行为跟踪监听器244发布事件。

图9示出示生命周期，表示在一个实施例中如何使用占位符标记来为随后的用户屏幕上的显示检索内容。如图9所示，当在用户屏幕上占位符标记或JSP标记250被激活时，其引起对占位符服务EJB 252的调用。占位符服务EJB随后基于占位符的名称调用内容桶254，之后是对获取内容的请求。然后该内容被返回给用户，一般作为用户屏幕上的显示。可以可选地向表达器对象EJB 256发送请求，以将内容桶的输出向用户返回或向用户显示前转换为某种其他格式。

图10示出生命周期，表示如何使用管理与编辑工具(包括图形用户界面)以编辑活动与方案，然后在活动服务上部署活动，以备随后为用户个性化网页内容使用。如图10所示，可以使用工具260直接或通过图形用户界面来编辑活动方案，或者可以使用工具260生成新的定义活动的活动XML文件。当活动被令人满意地配置时，向部署器Servlet 262提出请求以部署实际活动。该部署功能使用部署配置信息来决定使用哪个部署器工具类型264(如存在许多的话)。然后将活动部署给活动服务266。在随后的任意时间点上，活动268都能自动或手动地由自举规则或例程激活，然后可以由系统在个性化内容时使用。

图11示出生命周期，其中占位符服务EJB 252使用广告桶EJB 284与广告冲突解决EJB 286，以向用户提供广告。如图11所示，对广告桶EJB 284调用“getContent”被用来基于用户的当前信息、特征集、或会话与广告占位符从数据库选择广告。然后系统基于活动规则去除非法广告，并产生合法规则集合以传送给用户。如需要，使用广告冲突解决EJB 286以挑选优先级最高的广告。然后“getAd”方法将基于广告查询的实际广告返还给广告服务288。

图12示出一点击进入Servlet的生命周期，显示在点击特定广告时用户300如何向点击进入Servlet 302发送方法。点击进入Servlet联系广告桶服务284，其使用活动服务266，活动服务266查找提供该广告的活动并为该活动调用适当的点击进入方法。然后基于该点击进入使用广告桶服务将用户重新定向。

行为跟踪

本发明的某些实施例对跟踪用户在网站上的动作，并使用该跟踪信息以对网站内容作相应修改尤其有用。为跟踪用户与网站的交互，可以使用行为跟踪系统，以存储该数据以备将来分析。将事件机制一般化涉及两个主要任务。

事件类型必须被解除耦合并以其将在其中被使用的情景定义。必须为一般页查看、产品查看、与广告查看定义显示事件。对点击事件也是如此。另外，其他事件的定义必须明确并最终确定；以及

事件服务必须被一般化，以将事件内容与该机制解除耦合。在一个实施例中，所有的事件都被存储在一单一数据库表中。一单一监听器将从事件服务接收事件并将该事件传送给单一保存器。该单一保存器将调用工具方法以生成将被存储到数据库中的XML串；然后该数据被存储到该单一数据库表中。

可被跟踪的事件包括：

SessionBeginEvent—标示任意用户会话的开始。用户不必登录就可进入会话。然而，如果用户登录了，他们还保持其在登入前的会话标识。匿名用户将具有会话标识，但直到其登录(验证)后，才会有用户标识。在用户会话开始时生成。

SessionEndEvent—标示任意用户会话的终止，不管该用户登录与否。在会话超时或用户登出时生成。

SessionLoginEvent—标示用户已被验证。我们认为此时我们可以访问用户特征集信息。将使用与用户登入前相同的会话标识。当用户提供登入信息时产生。

UserRegistrationEvent—表示新用户何时在站点注册。当用户成功地完成注册表格时产生。

AddToCartEvent—客户向购物车添加产品。当客户向其购物车添加产品时产生。

BuyEvent—客户购买产品。当客户进入结算时产生；每件产品一个事件。

RemoveFromCartEvent—客户从购物车移除产品。当客户从其购物车移除产品时产生。

RuleEvent—启动了规则。通常在方案的情景下生成(参见以上描述)。然而，也可以独立于方案地启动规则。

DisplayContentEvent—独立于活动地向屏幕显示图像。当显示“带标记的”(”tagged”)内容时生成。

ClickContentEvent—独立于活动地点击屏幕上的图像。当点击带标记的内容时生成。

DisplayProductEvent—在屏幕上显示产品。注意产品没有绑定在活动上。当显示带标记的产品时生成。

ClickProductEvent—点击屏幕上的产品。当点击带标记的产品时生成。

DisplayCampaignEvent—向屏幕显示与活动有关的图像。方案可能与多个显示相关。当活动/方案指明此特定内容与方案相关，并且应该在方案有效时显示时生成此事件。

ClickCampaignEvent—点击与活动有关的图像。方案可能与多个点击事件相关。当活动/方案指明此特定内容与方案相关，并且被点击时生成此事件。

CampaignUserActivityEvent—在活动情景内捕捉用户活动的通用事件。被用来记录用户接触了特定活动。如果不存在DisplayCampaignEvent或ClickCampaignEvent，则使用此事件。

图13示出一个实现，即如何使用事件系统传送事件供该系统使用，以个性化内容或业务功能。如图13所示，使用事件服务BEAN 310将事件312的通知送入一个或更多个可插入的异步监听器314，在本系统的一个实施例中包含行为跟踪或监听器模块316。每个监听器都有其所监听的事件类型列表。当行为跟踪JMS监听器(BehaviorTrackingJMSListerner)接收该类型事件(例如，foo)时，将该类型为foo的事件传送给每一个监听器，所述监听器将foo列入从对其getTypes()调用返回的字符串数组中(由行为跟踪JMS监听器启动该调用)。使用Java消息服务(JMS)318将单个的事件消息传递给JMS监听器与可插入的异步监听器322集合。各监听器不知道JMS。例如，为插入只对活动事件感兴趣的监听器，必须将该监听器的类名作为行为跟踪监听器列入特征文件，该监听器必须实现空handleEvent(Event e)，并且该监听器的getTypes()调用需要返回包含{“ClickCampaignEvent”，“DisplayCampaignEvent”，”CampaighUserActivityEvent”}的数组。然后将到达该三类事件之一，并在该监听器的handleEvent(Event e)接口处理。该行为跟踪JMS监听器订阅JMS主题，从同步的了解JMS的监听器向该主题发送事件。然后其将事件发送给对特定类型事件感兴趣的可插入的异步监听器。可以缓存324这些事件，然后将其存储进数据库(DBMS)326以备生成内容时使用。将清楚可以使用其他方法来向系统传送事件。

事件表

在一个实施例中，跟踪事件表结构使用了单一表，用来存储从所有事件类型来的数据。该表的实施例具有五列，如下所示，但可以使用其他可替换形式：

EVENT_ID(事件标识)

EVENT_DATE(事件日期)

EVENT_TYPE(事件类型)

WLS_SESSION_ID(WLS会话标识)

USER_ID(用户标识)

XML_DEFINITION(XML定义)

前五项为被捕获并存储在数据库中的所有事件类型所共有。最后一项XML_DEFINITION表示作为CLOB存储在表中的XML文件。XML_DEFINITION存储以上前五项以及事件特有数据，该数据可能在所有事件类型中都不相同。为每一事件类型逐一生成该XML文件。

管理工具与编辑器

管理工具功能可以分为几个主要组件。图14显示管理工具集合的一个实施例，其允许管理员修改规则和/或活动方案规则集，并允许管理员编辑动作类型，包括(例如)可以由本发明使用的折扣定义。如图14所示，管理软件作为工具框架330，并且可以包括活动编辑器332、方案编辑器334、规则编辑器336、以及折扣定义编辑器338。如必要可以添加其他规则编辑器。使用这些编辑器来修改系统库340，其包括与活动模型342、方案模型344、规则模型346、以及折扣定义模型348有关的数据。该库通过保存层352与服务器端的数据库350连接，该保存层允许在此个性化引擎运行时动态地更新数据。

编辑器—管理员将与之交互以生成活动、方案、规则集、或折扣定义的实际的窗口部件、图标、以及其他用户界面功能。它独立于任何工具框架，这使编辑器尽可能地可复用。工具框架将创建并监听模型以促进在用户界面中的呈现与其下对象(underlying objects)的保存。编辑器还可访问库对象，该库对象包含来自外部世界的信息，如呈现模板列表、可使用特征等等。

呈现—有关如何以对管理员可读并可理解的方式显示活动、方案或规则的信息。该呈现信息由编辑器使用，并且可能对场所唯一(unique to alocale)(甚或对业务唯一)。

模型—编辑器与“世界“交互的方式。每个编辑器的模型都负责向该编辑器提供其所需的东西，如数据的DOM。模型还监听DOM上的事件，并且具备适当机制以启动自己的事件，该事件由工具框架监听(例如，用来提醒需要保存规则集)。

工具框架—容纳具体编辑器的外围基本构架。工具框架显示活动、方案、规则集、以及折扣定义的列表。还借助工具条、菜单、或类似界面(通过模型与保存层)处理对在编辑器内部所产生的东西的保存、加载、以及删除。

数据—有关实际的规则、方案、活动、以及在工具内编辑的其他构件的信息。这些数据存在于从XML生成的一个或多个DOM中。

保存—如何将数据载入模型以及如何在编辑器中生成或编辑后保存数据。

规则编辑器

规则编辑器是大多数其他管理工具的基础。活动与方案由规则(在规则集中)构成。因此，为编辑方案与活动中的规则，必须使用规则编辑器。

规则集

当启动规则编辑器时，“工作单位”为规则集。规则集是相关规则的汇集，被捆绑在一起以便规则引擎能够一起使用它们。

分类器

分类器规则集是个特例。因为类别(例如，用户是“金成员”这一事实)需要在任意活动、方案、或规则中重复使用，所以对每一应用具有单一规则集能使事情(对我们)更好办，该单一规则集存储了所有将被重复使用的类别。因此，就有只包含分类器规则的特殊的分类器规则集。请注意分类器与类别之间的区别。分类器是规则类型，其右侧声明类别对象。例如，在分类器“如果来访者的家乡为柯罗拉多州，则将其归类为滑雪者”中，类别“滑雪者”将在其他规则(“如果来访者是滑雪者，则在左边的广告占位符中显示Vail的广告”)中复用。分类器规则不在其他规则中使用一只有类别在其他规则中使用。

XML到类HTML阅读器

模型在规则编辑器启动时向其提供了其所使用的规则集DOM。当从规则集中选择了某规则时，规则编辑器必须能够显示包含在该规则集DOM中的规则的数据，以及正确显示该规则所必须的呈现信息DOM。规则编辑器需要能够将这两类DOM信息转换为可读的规则，其具有用于可参数化节段的超级链接。

短语编辑器

当在规则中点击超级链接(可参数化区域)时，呈现DOM需要知道打开哪个短语编辑器。短语编辑器是一对话，用来取得具体值以备规则中使用。例如，日期或时间选择器，或特征挑选器。

方案编辑器

方案编辑器如同规则编辑器一样编辑规则集。两者间的唯一区别在于方案始于模板(例如“广告方案“模板)，并且方案有些关于自己的元数据(例如描述)。换而言之，在方案编辑器中使用的大部分规则都嵌套在内置的规则编辑器中。方案实质上是规则集与一些元数据。方案数据包含该元数据及指向规则集的链接。方案数据还包含指向分类器规则集的链接，以便在分类器规则中生成的类别可以在方案规则中使用。

活动编辑器

活动编辑器可以内含多个方案，以及开始与终止条件的规则集。还有活动元数据，如发起者、描述、以及搜索信息(起始与终止日期等等)。在活动编辑器添加或修改方案时，其使用方案编辑器以及规则编辑器。活动数据有指向内部所使用的每一规则集(包括方案)的链接，包括方案、起始/终止条件规则集、以及分类器规则集。

折扣定义编辑器

折扣定义编辑器只在以下意义上与活动、方案、与规则编辑器有关：在规则编辑器中产生的规则可以引用在折扣定义编辑器中产生的折扣(折扣类型规则)。

呈现

如“如果来访者的性别为男性，则将来访者归类为啤酒饮用者”之类的分类器不仅具有如“性别”、“男性”、“啤酒饮用者”等等数据，还有关于如何显示分类器的呈现信息(“如果来访者的...”)。该呈现信息存储在编辑器自身之外，以便可以插入不同的呈现以供不同用途(如不同的场所或为某业务或垂直市场的具体呈现)。

模式

对每一编辑器(活动、方案、规则、以及可能的折扣定义)，都有XML模式，控制着任何用于该编辑器的呈现XML必须如何构成。

呈现XML

有了模式，每一编辑器都需要默认的呈现XML。这包括用于每种规则类型的规则文本(分类器、内容选择器、占位符内容选择器、发送电子邮件、折扣)，以及用于方案与活动的显示信息(可能只有元数据名称，也可能更多)。

模型

尽管每一编辑器知道如何处理具体的数据类型与呈现DOM(活动、规则集等等)，但每一编辑器并不一定需要对该DOM作所有的遍历、更新、以及其他动作。每一编辑器都有相关联的模型，此模型处理大部分“低级工作”，其向编辑器提供有用的方法。

便利方法

用于每一编辑器的模型提供便利方法，该编辑器可以使用这些方法以取得或设置来自DOM的值。例如，活动模型可能提供方法String getSponsor()，其遍历数据DOM以取得活动的发起者。

事件

每一编辑器的模型还提供事件监听与启动机制，从而由模型负责根据从该编辑器启动的事件通知工具框架如数据“变脏”(指使能了保存按扭)等事情。

库

用于每一编辑器的模型都具有与该编辑器相关的信息的库。该库包含如模板列表等信息，并且还可能保存对用于每一编辑器的呈现DOM的引用。

工具框架

工具框架是GUI的外层，并且容纳了其中的各种编辑器。工具框架负责显示活动、方案、规则集以及折扣定义集合。工具框架还执行保存、打开、以及搜索(例如活动查找)任务。工具框架从不直接与编辑器通信—其总是通过编辑器的模型。

数据

在本文件中，名词“数据”指管理员用户通过使用工具所试图创建、更新、或删除的信息。数据可能是规则集、方案、活动、或折扣定义。

模板

模板概念对管理员工具至关重要。通过在每一级(活动、方案、规则、以及规则子句)上提供模板，工具使管理员用户易于迅速创建自己所需生成的任何东西。通过使模板可插入(可以以后创建新模板)，可以提供大量功能与很高的灵活性。

模板就是方案、活动、或规则(或规则子句)的参数未定的版本。模板提供了基本结构，但编辑器应该允许将始自模板的活动、方案或规则修改为管理员用户所希望的任何形式。例如，用户可以以电子邮件方案模板开始，通过添加与移除规则，最终得到的模板对产品进行折扣而且根本不发送电子邮件。

折扣

本发明的某些实施例允许用户(例如在万维网环境下)向特定客户提供折扣。在这些实施例中，所有的折扣都有唯一的标识符。通过方案，有可能将折扣与用户相关联。

折扣是促销功能的一部分，其履行通过活动服务或可能还未开发的功能向客户作出的金钱上的促销承诺。打折包括定义折扣，以及通过批价服务执行这些折扣，该批价服务对定单或购物车内容进行计算。具体地，批价服务将向产品集合执行折扣集合，以将客户在金钱上的收益最大化。商业服务器所提供的许多其他服务将与折扣功能交互，因此与这些服务存在大量的相关性并对其有较大的影响。

客户—基于浏览器的用户，其与商业站点交互。还包括与商业站点交互的计算机系统。

开发人员—对任何在商业服务器上操作、配置、维护或开发人员的统称。

商业工程师，商业经理—负责管理业务功能的高级开发人员。

折扣工具—用来定义折扣的工具。

本发明的实施例提供了在商业服务器内部署的软件设施，以促进向客户提供折扣。可以向所有客户或只对特定客户分组提供折扣。折扣可以总是有效或者可以带有条件，指明何时或在哪种情况下有折扣。在一些实施例中，系统包括动态批价服务，其对特定产品或产品集合执行折扣以生成在特定时间上对特定客户该产品或产品集合的费用。虽然促销功能(不通过产品目录而向客户呈现报价)在折扣系统之外，但该动态批价服务可以遵守通过促销功能提出的报价。

折扣系统包括与购物车、目录、结算、以及定单管理系统之间的依赖性与互操作性。该系统可以独立存在，或者允许第三方的开发人员提供其自己的目录与定单系统组合。可以使用工具维护折扣定义。

折扣系统有两个主要用例。第一个有关开发人员与折扣配置系统的接口。第二个有关客户与目录、购物车、结算之间，以及与批价服务的间接接口。第三个用例存在于开发人员与批价服务接口以执行未指明的任务。

本发明的实施例提供一套机制，允许折扣系统遵守通过促销系统向客户呈现的报价。该机制称为折扣指示机制。

促销设施基于用户属性对所有关于特定用户折扣是否应用于该用户的问题作出决定。在作出此决定后，该促销设施用用户标识符与折扣标识符更新折扣指示机制。在本文中的剩余部分，折扣指示机制被称为客户折扣关联。

折扣系统提供资格形式的客户定标折扣(customer targeteddiscounting of a qualification style)。资格折扣的基本前提是：折扣定义描述了获得折扣资格所需的项目(资格项目)(以及数量)，以及将接受折扣的项目(目标项目)。一般地，资格项目可以是或不是与目标项目相同的项目。为简便计，在一个实施例中，资格项目与目标项目可能要求是一组相同的项目。

折扣在对象(定单、购物车等等)汇集的情景中执行。当将折扣应用到该汇集上时，匹配折扣定义的对象集合被从该汇集中移除，并对每一折扣定义在目标项目上打折。进行其他折扣，直到再没有折扣、池中对象或匹配剩余汇集对象的折扣。更具体地，批价服务将在给定对象汇集上执行折扣以最大化客户在金钱上的节省。

折扣系统可能还提供一套机制，用来将销售折扣与特定产品项目或目录相关联。销售折扣可在所有资格折扣之前使用。

其他特征

由本发明的各种实施例所提供的其他特征包括下列各项。本领域的技术人员将清楚，以下列表是用来显示本发明提供的个性化系统所能够使用的各种特征，并且在本发明的精神与范围内显然有许多修改与变化。

依据历史数据或当前执行数据对活动进行预测建模。

将活动/方案数据分析直接绑定回活动/方案开发环境。

方案验证规则：此规则采用与基本方案规则相同的输入，然而其输出为真或假标识符。真将表示该用户对方案有效，并且应该执行正常的方案规则。假将表示该用户对方案无效，并且不应该再发生其他事情。

广告空间清单与调度(除非间接地通过方案的使用)

高级广告冲突解决，包括交叉占位符解决(即在同一页上的两个占位符)。

广告接触限定(Ad exposure limits)。

拒收电子邮件处理(Email bounced handling)。

被保证与被验证的电子邮件投送。

电子邮件收据。

以上对本发明的描述用于显示与说明目的。其并非穷尽，也非用来将本发明限定于所公开的具体形式中。显然，对本领域的普通技术人员来讲，明显可有许多改进与变化。选择并描述实施例是为了最清楚地解释本发明的原理及其实际的应用，以使本领域其他技术人员能够理解本发明，其可应用于与所构想的特定用途相适应的各种实施例与各种修改。本发明的范围由所附权利要求界定。

Claims (25)

1.一种定制软件应用功能的系统，包括：

服务器，被配置用来允许用户或自动过程访问或使用应用，以及生成描述对此应用的使用的事件，作为规则引擎的输入；

规则集，包括多条规则，其中每条规则定义了为响应特定事件所要采取的一个或多个动作；以及

规则引擎，被配置用来使用规则，以及关于当前事件的信息，以确定将由软件应用采用的动作。

2.如权利要求1所述的系统，还包括规则库，用来存储所述规则。

3.如权利要求2所述的系统，其中所述规则作为XML文件存储在规则库中。

4.如权利要求1所述的系统，其中所述规则可以在实时被更新并应用于规则引擎，以产生对软件应用的实时改变。

5.如权利要求1所述的系统，其中所述规则的子集可以被用来定义将被软件应用理解的事件的方案。

6.如权利要求5所述的系统，其中该系统包括多个方案，从中可以由规则引擎基于作为输入所接收的事件选择任何一个方案。

7.如权利要求6所述的系统，其中方案的子集形成可被应用理解的活动。

8.如权利要求7所述的系统，其中存在多个活动。

9.如权利要求1所述的系统，其中所述应用被用来为网站提供功能。

10.如权利要求9所述的系统，其中规则可以被用来确定网站的内容。

11.如权利要求9所述的系统，其中规则可以被用来确定网站客户的当前访问行为。

12.如权利要求9所述的系统，其中规则可以被用来在实时确定所述网站的客户快速印象。

13.一种用来定制电子商务软件应用的内容或功能的方法，包括：

允许用户或自动过程访问或使用在服务器上的应用，以及生成描述对此应用的使用的事件，作为规则引擎的输入；

读取规则集，包括多条规则，其中每条规则定义了为响应特定事件所要采取的一个或多个动作；以及

使用规则引擎，其被配置用来使用规则，以及关于当前事件的信息，以确定将由软件应用采用的动作。

14.如权利要求13所述的方法，还包括将所述规则存储到规则库中。

15.如权利要求14所述的方法，其中所述规则作为XML文件存储在规则库中。

16.如权利要求13所述的方法，其中所述规则可以在实时被更新并应用于规则引擎，以产生对软件应用的实时改变。

17.如权利要求13所述的方法，其中所述规则的子集可以被用来定义将被软件应用理解的事件的方案。

18.如权利要求17所述的方法，其中该方法包括多个方案，从中可以由规则引擎基于作为输入所接收的事件选择任何一个方案。

19.如权利要求18所述的方法，其中方案的子集形成可被应用理解的活动。

20.如权利要求19所述的方法，其中存在多个活动。

21.如权利要求20所述的方法，其中所述应用被用来为网站提供功能。

22.如权利要求21所述的方法，其中规则可以被用来确定网站的内容。

23.如权利要求21所述的方法，其中规则可以被用来确定网站客户的当前访问行为。

24.如权利要求21所述的方法，其中规则可以被用来在实时确定所述网站的客户快速印象。

25.一种处理器可读的介质，包括其上存储的指令，该指令在执行时使处理器执行以下步骤：

允许用户或自动过程访问或使用在服务器上的应用，以及生成描述对此应用的使用的事件，作为规则引擎的输入；

读取规则集，包括多条规则，其中每条规则定义了为响应特定事件所要采取的一个或多个动作；以及

使用规则引擎，其被配置用来使用规则，以及关于当前事件的信息，以确定将由软件应用采用的动作。

Images