基于规则的目标赠劵的生成和管理的制作方法

文档序号:6365614阅读:136来源:国知局
专利名称:基于规则的目标赠劵的生成和管理的制作方法
技术领域
本发明一般涉及顾客从他们与一个企业的商业活动中赢得的可兑换的“点数”的生成和管理,尤其是涉及在赌场或者其它博奕环境中赠券的生成和管理。
背景技术
商业性的企业经常基于企业可从客户那里获得的收入数量运用一些方法来评价他们的客户。识别能为企业获取更多收入的客户允许企业去培养与那些客户的密切关系。这样企业设法通过使他们一直忠实于这个企业来留住这些客户。这经常通过特殊的提供和交易来完成。许多公司提供了顾客从中能获取兑换为商品或服务的价值的计划。这样的系统可以在很多行业中找到,上述系统包括通过航线提供的经常飞行里程和由许多信用卡公司提供的点数系统。
赠券被用在例如赌场这样的环境中以增加客户的交易和刺激特殊的客户行为。从赌场的角度来看,赌场的顾客或游戏玩家的价值通常基于每一个游戏者的博奕活动——例如,计时博奕、平均的和总的赌注、金钱。赌场经常根据游戏者的等级把他们分类,并且因此提供特殊的奖励和其它的提供礼品给游戏者。例如,给一个经常并且大面额打赌的游戏者提供赠券,该游戏者可以赎回由企业投资的商品、服务或另外的博奕。这样就刺激了游戏者在同一赌场博奕来增进他的等级,并因此可以增加收到的赠券和其它特殊奖励。
赠券传统上用纸记录来管理,但是对于有许多资产的赌场来说,基于纸件的系统不允许游戏者的活动从一个财产追踪到另一个财产。某些系统以多种财产电子追踪游戏者的博奕,例如题为“Multi-property player tracking system”的美国专利6,302,793所公开的系统;但是,这些系统不能追踪非博奕活动,而且它们也不允许以不同组财产同时运行的多种赠券奖励。此外,这些电子系统用固定的赠券表为顾客产生赠券,其中所有参与的客户都被同样对待,并且根据他们的博奕被给予一个特定数量的赠券,其不能被轻易地改变以满足交易和奖励的要求。因此,现有的具有固定赠券表的电子系统不能精确地将顾客以及他们的被许多企业期望的活动作为目标。而且,固定的赠券表也不能允许企业职员很容易地创建新的赠券奖励和根据他们在现有赠券奖励中的活动调整为不同的顾客产生了多少赠券。

发明内容
据此,一个赠券管理系统允许横贯一个企业场所的不同组来处理多种赠券奖励。在一个赠券奖励中,一个企业的顾客从他们在企业的一个场所所进行的活动中获得赠券——或其它可兑换的“点数”。通过一组能有选择性地把客户、活动和有资格赚取赠券的场所作为目标的规则来定义赠券奖励。通过这种综合的基于规则的方法,系统监控这个顾客的活动并且为此依据规则产生赠券。对每一个奖励的规则可能是截然不同的,以允许企业用每一个奖励将顾客和顾客活动的不同组合(例如为呆在相关宾馆内经常来玩的游戏者产生赠券)作为目标。运用这种规则,系统能控制由活动的类型、数量、等级、强度或者任何其它统计度量产生的赠券。每一个赠券奖励适用于一个或多个企业的场所,以允许在单一的和多级的财产水平上都有多个同时的赠券奖励。
在一个实施例中,赠券管理系统通过各种数据获取管理系统在每一个企业场所获取关于各种类型的顾客活动的数据。该顾客活动可能包括博奕,住宿,用餐,参与一起事件和采购,并且该顾客活动可能是在一个场所中或遍布多个场所发生。利用顾客活动数据,该系统将一组规则应用到一个或多个奖励以基于他们的活动为顾客产生赠券,其中每一个奖励的规则指定产生多少赠券。用于赠券产生的规则最好包括顾客目标规则,该规则允许系统清楚地以及灵活地面向顾客和顾客活动。赢得的赠券被系统存储,然后顾客可以在遍及该企业的各种地方,例如在一个饭店处兑换他们的赠券。
在一个实施例中,一个赠券奖励有一个滚动的累积周期,其中顾客仅仅能兑换那些在一个指定时间周期内赢得的赠券。在该指定时间之前赢得的赠券到期。在另一个实施例中,一个赠券奖励可以对赠券有一个封顶,其中顾客不能赚得大于指定上限的赠券。一旦顾客在赠券奖励中达到了赠券的上限,系统将不能为该顾客产生任何附加的赠券。优选地,这个封顶可以被由企业职员进行的人工调整取而代之。在又一个实施例中,实现一个博奕/等级频率限制。由于这个限制,顾客必须在一给定时间周期内保持指定数量的赠券,否则,所有由该顾客赢得的赠券到那个点就到期了。
有利的,一个赠券奖励能和其它的奖励,包括图画奖励同时被运行。在一个实施例中,系统也管理图画奖励,其中顾客获取类似于他们如何赚取赠券的记录,然后这些记录适合于一幅或多幅图画。而且,多种赠券奖励和图画奖励可以同时运行,并且适用到不同组场所。如果两个或者更多的奖励正在运行并且适用到同样的场所,则顾客在那个场所的活动可能会导致在每一个奖励中为该顾客产生赠券。因为用于不同奖励的规则可以不同,所以企业能用不同的奖励来唯一地和明确地把特定的顾客和顾客的活动作为目标。
在本发明的一个实施例中,某些或者所有的场所都是赌场财产,其中奖励可在一组财产中或者对所有的财产(即在企业或“商标”级别)被定义。顾客活动可以包括——取决于在财产中服务的有效性——在机器和博奕桌上的博奕,入住宾馆,在饭店用餐,参加节目和购买商品。在另一个实施例中,场所或财产包括旅游客轮,饭店及其它的零售环境。在其它方面,场所可能包括虚拟的场所,例如网络站点等等。因此,该系统允许多层的多种奖励,每一个奖励与在企业中的单个财产,多个财产或所有的财产相联系。按照一实施例的另一个方面,允许对奖励的交叉场所的管理和调整。在一个或多个场所集中控制奖励易于保持并且支持成果。


图1是由赠券管理系统的一个实施例管理的多个同时的奖励的图;图2是在不同组场所管理同时奖励的一种方案的实例图;图3是在企业级中的赠券管理系统的一个实施例的示意图;图4是在场所或财产级别中的赠券管理系统的一个实施例的方框图;图5是用于修改一个奖励的用户界面的实施例;图6是用于手工调整功能的屏幕流程图的实施例。
具体实施例方式
图1的图说明了依据一个优选实施例如何实现多种奖励100,企业的顾客参与了顾客活动110,在一个实施例中该活动包括赌场博奕,入住宾馆,在饭店用餐,观看一场表演和购买商品。企业收集与顾客活动110有关的顾客活动数据120,该数据可由一个赠券管理系统访问。顾客活动最好为与其相关的数据能被电子收集的活动。数据能被实时或分批地(例如每夜)收集。
每一个奖励100尤其是通过一组奖励规则130定义。响应顾客的活动110,如由顾客活动数据120所代表的,赠券管理系统从一个或多个奖励100向活动数据应用奖励规则130以在奖励100中产生赠券140,其中每一个赠券140都和顾客有关并且基于该顾客活动。在一个实施例中,奖励规则130包括成组的顾客目标规则132、赠券产生规则134和其它规则136。顾客目标规则132使系统能准确地把一组有资格在特定奖励100中赚取赠券的顾客、由例如以顾客目标规则132识别的某些共享特征定义的一组顾客作为目标。赠券产生规则134响应于顾客活动110定义为一个顾客是否产生以及产生多少赠券140。此外,其它规则136被用来例如定义何种活动能被用来产生赠券140以及当兑换礼品所产生的赠券数目。
此外,赠券奖励可以包括对个别顾客在赠券积累上的限制。例如,一个赠券奖励可能有一个滚动的积累周期,其中仅仅那些在一个特定时间周期内赢得的赠券能被兑换。在滚动的积累时间周期之后,赢得的赠券到期并且不能被兑换。在另一个实施例中,一个赠券奖励可能有一个对赠券的最高限度,其中顾客不能赚得大于指定上限的赠券。一旦顾客在赠券奖励中达到了赠券的上限,系统将不能把任何另外的赠券归给顾客。更可取的是,该最高限度不适用于由赌场职员进行人工调整,其允许该最高限度被人工替换。在另一个实施例中,可以实现一个博奕频率限制。由于这个限制,顾客必须在一个给定的时间周期内赢得指定数目的赠券;否则,所有由该顾客赢得的赠券到那个点就到期了。这三个限制可以单独地或组合在一起实现,并且也能增加对于赠券积累的其它限制。这种限制使企业能更好地碉整由每一个赠券奖励产生的激励。
重要的是,同样的顾客活动(例如在一个自动售货机上的博奕)可以导致为一个顾客在一些不同的奖励100(例如在图1中的奖励1和2)中产生赠券140,包括单财产和多财产奖励100,这取决于系统的配置。这是因为多种奖励向顾客活动数据120应用它们的奖励规则130以产生和每一个奖励100有关的赠券140。
一旦顾客已经赢得了足够的赠券140,顾客就能从企业将他们的赠券兑换150为商品,服务或另外的博奕。例如,持有足够赠券的顾客可以将赠券兑换150为免费的一顿饭或在一家宾馆免费地住一晚。
图2说明了遍及不同场所保持的一些企业奖励的例子。图中的横轴代表时间,纵轴显示了将每一个奖励Pn应用到企业的五个场所Lm的适用性。在图2中显示了三个奖励两个赠券奖励P1和P3、以及一个图画奖励P2。
首先开始的奖励P1是一个特殊场所奖励的例子,如它仅仅适用于场所L5。当P1待定时,如方框P1所示,与场所L5有关的顾客活动依据奖励P1的规则导致赠券的产生(如图1所示)。奖励P2在时间上与奖励P1交迭,并且因此在重叠时间期间和那个奖励被同时管理。奖励P2是一个企业级赠券奖励,适用于企业的每一个场所。任何与该企业有关的顾客活动当P2待定时都可以按照它的规则在奖励P2中导致赠券的产生。
在奖励P1和P2同时运行的时间周期期间,如图2中由它们的重叠所显示的那样,顾客在场所L5上的活动可能导致在奖励P1和P2中都产生赠券;然而,顾客在场所L1、L2、L3和L4上的活动仅仅导致在奖励P2中产生赠券。为了使在特殊场所和多个场所的奖励都有效,系统把每一个奖励的规则应用到在该奖励适用的一组场所中所获得的顾客活动数据中。当仅仅两个赠券奖励被显示时,系统最好能够处理任意数量的当前奖励。因此,系统能管理在企业、多种财产和单一财产级别中的同时奖励。
优选实施例的另一个有益特征是系统同时管理图画奖励和赠券奖励的能力。奖励P3是一个适用于多个场所L2和L3的图画奖励,其具有四幅与之相关的图画。一个图画奖励由一组根据顾客的活动为他们分配具有资格的记录的规则定义,其中顾客可以选择性地激活他们的记录来分享一幅图画。对于奖励P3,顾客在场所L2或L3的活动能导致在该奖励中具有资格的记录。在一个实施例中,顾客因此可以在任一场所在任何活动周期AP1-4期间激活它们对一幅图画的记录,而不管导致那些记录的具有资格的顾客的活动在哪里发生。图画D1和D3被保持在场所L3,而图画D2和D4被保持在场所L2。这样奖励横越两个场所进行管理,其中在任一场所的活动都能导致具有资格的记录,其能为一幅图画在任一场所被激活。
系统结构图3是一个在企业级上的赠券管理系统的实施例的示意图。企业包括许多经由一个网络350耦接在一起的场所400。网络350可以是如互联网或企业私有网络(如WAN,VPN等)。在一个实施例中,赠券管理系统进一步耦接到互联网322上,由此顾客能用一个连接到互联网322的个人计算机324来访问赠券管理系统。
赠券管理系统通过一个赠券管理应用软件300来管理。该赠券管理应用软件300可以从一个操作员终端320来访问。应用软件300最好在一个服务器上运行,并可经由在每个终端320上的一个客户界面或应用软件来访问。在一个实施例中,操作员终端320包括一个计算机系统,其耦接到网络350上。可以有许多操作员终端320耦接到该系统上,并且,在一个优选实施例中,每一个场所400都有一个适合访问赠券管理应用软件300的操作员终端320。赠券管理应用软件300可以在企业的一个场所400或在远程位置的一个计算机系统上。可从在企业场所400的一个操作员终端320访问的企业奖励能提高系统的交叉财产管理能力。例如,一个操作者能在一个企业级的奖励中从一个在特定场所400上的操作员终端人工调整一个顾客的赠券,并且这种调整将自动地影响顾客在每一种企业财产中的帐目。
赠券管理应用软件300的功能被分成几个用于执行相关任务的模块。在一个优选实施例中,赠券管理应用软件300中的各模块包括一个奖励保持和规则处理模块302,一个顾客状态模块304,一个人工调整模块306,和一个安全及管理模块310。尽管赠券管理应用软件300在一个实施例中作为一个单独的应用软件被描述,但是它的功能可通过一个以上的应用软件来执行,该应用软件可以驻留在不同的系统中。赠券管理应用软件300被耦接到一个奖励定义数据库314和一个赠券数据库316,并且该应用软件300进一步被耦接到一个顾客数据库318。该赠券管理应用软件300也被耦接到一个用于存储和检索与过去的奖励有关的存档数据的企业数据仓库330。
奖励保持和规则处理(PMRP)模块302使奖励操作者能够创建和定义一个或多个奖励。一个操作者访问PMRP模块302以创建和定义一个奖励。每一个奖励可以适用于该奖励从其被创建的特殊场所,或者它也可以适用于企业的一些或所有场所。在一个实施例中,PMRP模块302可以从任何该企业的财产中访问,以便在一个场所创建的奖励可以适用于其它场所。这样,一个操作者能用PMRP模块302来保持适用于远程位置的奖励。PMRP模块302也能使一个操作者在奖励已被创建之后修改它们。
顾客状态(PS)模块304使顾客能存取与他们的资格、在各种奖励中他们现有的赠券和其它有关奖励的信息有关的信息。在一个实施例中,顾客能通过互联网322从一个个人计算机324、或从任何其它的连接到那儿的网络设备访问PS模块304。在另一个实施例中,一个或多个客户服务界面420位于一个财产400上,其被通信地耦接到PS模块304上以用于向顾客提供相关的信息。在一个实施例中,一个客户服务界面420包括一个具有一个输出显示终端和一个用户输入、诸如读卡机和触摸屏的计算机。顾客能通过读卡机刷卡(即,卡输入)利用客户服务界面420来存取用于他们帐目的信息。客户服务界面420可以被放在一个电话亭或其它用户可访问的房于中。
人工调整(MA)模块306能使奖励操作者实时地监控特定奖励的执行和状态信息。此外,MA模块306使操作者能观察对个别顾客的特殊信息,并且对顾客的赠券和其它顾客特定信息作调整。这个功能可以被用在例如当一个顾客抱怨时,以及当操作者希望用一个或多个赠券赊欠顾客的帐目时。当系统有技术问题,并且所产生的错误需要校正时能够做人工调整也是有益的。最好是,由操作者在一个财产方面对顾客赠券所作的调整在奖励中对该奖励适用的每一个财产都会影响顾客的赠券;因此,调整不需要由一个操作者对每一个财产分别完成。
在一个实施例中,一个安全和管理模块310通过使奖励操作者能执行常规功能,例如分配内部用户和日常内部用户设置来减少对IT人员的依赖性。用这个模块310,操作者能指定其他内部用户和他们的许可或访问级则(它可以取决于系统可从其被访问的财产),以及为不同的奖励管理改变许可级别和报告任务。
如上所述,奖励定义数据库314存储关于奖励的信息,如每一个奖励的属性和规则。依据一个优选实施例,奖励的属性包括用于当奖励正在运行时的开始和结束日期以及奖励适用的场所。奖励的规则定义了系统如何响应事件来管理奖励。例如,一个奖励的顾客目标和赠券产生规则规定根据顾客活动产生了多少赠券。当一个操作者用PMRP模块302来产生一个新的奖励或修改一个现有奖励的属性或规则时,这些增加或改变会反映在奖励定义数据库314中。
当依据奖励的赠券产生规则为每一个奖励产生赠券时,该赠券被存储在赠券数据库316中。该赠券数据库316被耦接到赠券管理应用软件300上,用于接收和由PMRP模块302为每一个奖励产生的赠券相关的数据。在系统的一个实施例中,赠券数据库316存储关于每一个奖励中的赠券及与该赠券相关的顾客的信息。赠券数据库316进一步适合于按要求提供这个信息给赠券管理应用软件300。例如,PS模块304可以被用来从赠券数据库316中检索赠券数据,而且MA模块306可以被用来观察和修改用于一个特殊顾客的赠券。
顾客数据库318适合于向赠券管理应用软件300提供与各个顾客或游戏者相关的数据。顾客数据库318包括来自所有支持的企业财产的顾客的用于顾客简介。在顾客数据库318中的顾客帐目包括详细的信息,如顾客的嗜好、兴趣、博奕或住宿历史、客户信贷分类、赠券级别、理论获胜值和积累的活动点数。一个顾客的理论获胜值按照博奕数据或在附属于该企业的任一场所中积累的其它顾客活动来确定。活动点数部分地由顾客活动来确定,但是可以通过特殊的提供和各种其它奖励计划来增加。
由管理系统(在下面描述)积累的数据被更新到顾客数据库318中,在此它们可以被工作人员在遍及网络350的任何企业场所上存取。通常,各种管理系统通过与顾客数据库318中每一个顾客帐目有关的唯一的顾客ID追踪顾客活动。在一个实施例中,顾客被发给游戏者跟踪卡,其被用来提供顾客的ID给各种管理系统。游戏者跟踪卡有一个在其上编码有顾客ID的磁条,并且该卡能在耦接到各种管理系统上的读卡机上刷取以把顾客的身份提供给系统。这样,在任一企业场所上的顾客活动最好是可经由网络350立即访问的。在企业的所有场所上在线访问一个顾客的活动和其它数据允许企业实现交叉财产奖励计划,更有效的管理客户的提供计划,并且向它的顾客提供更个性化的服务。
图4是一个在场所或财产级中的赠券管理系统的实施例的方框图。场所400是一个实际的场所(如赌场),它可以被称为一个财产;然而,赠券管理系统也能支持其它类型的企业场所,例如网络站点。每一个企业场所400包括一个顾客活动界面410以及最好包括一个或多个操作员终端320、一个或多个客户服务界面420、和一个显示系统430。在每一个财产400上具有一个操作员终端320允许当地的奖励操作者在该财产级实时地并且响应于市场状态来创建和定制奖励。正如所述的那样,财产400经由网络350彼此耦接,并且和赠券管理应用软件300相耦接。在一个实施例中,网络350是一个广域网。一个操作员终端320或另一个计算机系统可以充当从财产400到网络350的一个入口。
在财产400处是一个顾客活动界面410,在一个实施例中该界面用一个API把与当地顾客活动有关的数据通过网络350发送给赠券管理应用软件300。顾客活动界面410和一些计算机系统通信以用于监控和跟踪在一个企业,例如赌场中的操作。依赖于在财产400中提供的服务,下列系统的任何组合可以被用来收集顾客活动数据;一个赌场管理系统(CMS)440,一个住宿管理系统(LMS)450,一个事件管理系统(EMS)460,一个销售点系统(POS)470,一个跟踪监控系统(SMS)480,和一个博奕跟踪系统(PTS)490。美国专利5761647“National CustomerRecognition System and Method”解释了CMS440、LMS450、EMS460、POS470、SMS480、和PTS490是如何被用来在多个通过一个广域网通信连接的附属赌场财产中跟踪顾客的博奕和非博奕活动的。用于管理一些或所有的这些销售点操作的一个适当系统是由MICROS系统公司提供的9700 Hospitality ManagementSystem(HMS)。9700 HMS被特别地设计用来处理高利用率、多收入的中心环境,并且它在传统的销售点应用的发展过程中是灵活的。
在一个实施例中,顾客被发给跟踪卡来与赠券管理系统接口。每一个跟踪卡最好包括一磁条、微芯片或其它可用于在其上存储机器可读数据的机构。当一个顾客在一个场所执行一些活动时,该顾客用跟踪卡来和系统接口。例如,就磁条卡而言,顾客通过一个读卡机刷卡。在跟踪顾客活动的可替换的或另外的方法中,顾客或企业职员能手动输入一个顾客的ID号到一个耦接到该系统的终端。这个活动可以包括在赌场中玩一个游戏、进行预定、入住宾馆、在一个零售环境中购买东西、在餐馆用餐、和参加一场表演或其它事件。
在一个实施例中,CMS440借助于顾客在读卡机、工作站和位于遍及该财产的各种地点上的简易终端上刷取的跟踪卡来接收顾客数据并且把接收的数据耦接到顾客数据库318上。CMS440可以是在一个场所的中心LAN上支持的单一的集中式系统,包含和每一个场所的LAN有关的本地管理系统的分布式系统,或包含了集中式和分布式成的混合系统。
CMS440进一步适用于当顾客兑换提供时把数据发送到顾客活动界面410。在本发明的上下文中,一个或多个提供被发送给可能会在一个场所兑换提供的顾客。一个提供和一个提供ID相关,该提供ID被系统用来眼踪和识别被兑换的提供的类型。一个操作员可以从一个本地终端320手动输入一个兑换的提供到CMS440中。作为选择,顾客可以例如从一个通过互联网322耦接到系统的家用计算机324在一个客户服务界面420,或在一个场所400利用其它设备来兑换提供。当兑换一个提供时,CMS440把一个数据包发送给包含被兑换的提供ID和兑换它的顾客的赠券管理应用软件300。
LMS450包括用于管理赌场内宾馆操作,包含有预定、房间服务、和其它与宾馆操作有关的活动所必要的软件。在本发明的一个优选实施例中,LMS450和CMS440通信以本地查找在那个系统上可获得的所选客户信息。然而,LMS450可以包括它自己的用于客户数据的本地数据存储。当顾客登记入住宾馆和从该宾馆结账离开时,LMS450把关于顾客的住宿活动的数据传送给顾客活动界面410。此外,LMS450可以按来自顾客活动界面410的要求传送住宿数据。住宿数据包括,例如顾客入住一个宾馆的日期,房间服务活动,和由于顾客入住宾馆的计费信息。
EMS460包括用于处理票务信息、预定、和销售的软件。当顾客为一个事件(如在一个场所的一场演出)买票、为一个事件作预定、和参加这个事件时,EMS460就编译顾客活动数据。EMS460把这个数据传送给顾客活动界面410。
POS470包括用于操作在这个场所内的饭店和零售点的记账软件和用于把收费信息传送给其它管理系统的软件。例如,从POS470向LMS450传送与被收费房间的用餐相关的数据,并且从POS470向CMS440传送与兑换的用餐赠券相关的数据。顾客活动界面410从POS470接收和在一个场所顾客的购买相关的数据。在一个实施例中这个购买数据包括所购买的物品或服务、购买所在的饭店或零售点、和购买数量。
SMS480包括一个监控和跟踪由顾客在博奕机485中所作的赌注的计算机系统。博奕机485可能包括自动贩卖机、视频扑克机等。在一个优选实施例中,赌注跟踪是通过一个与自动贩卖机485有关的读卡机(未显示)完成的。一个顾客把他的跟踪卡(上文描述的)插入读卡机来开始赌注跟踪以及抽出跟踪卡来终止赌注跟踪。顾客在博奕机485上的打赌活动在SMS480中积累直到博奕期终止或者当CMS440请求一帐目状态为止,在此期间数据被传送到CMS440中。通过SMS480积累的赌注眼踪数据包括所进行博奕的识别、赢或输的次数、和顾客进行该博奕的时间期间。美国专利5,429,361描述了一个用于在博奕机上跟踪赌场顾客的打赌活动的系统。
PTS490自动地跟踪在博奕桌495上的顾客活动。PTS490通过一个把顾客活动数据传送给CMS440的计算机系统支持。在一个实施例中,PTS490使用和顾客在博奕桌495上的位置有关的读卡机来跟踪他们的打赌活动。作为选择,一个企业雇主,例如一个博奕区经理,手动地把顾客的博奕数据输入到PTS490中。在一个实施例中,和打赌活动相关的数据包括顾客在博奕桌495上的时间和这桌的最低赌注。美国专利5,613,912,描述了一个用于在赌搏桌上自动地跟踪赌场顾客的打赌活动的系统。
以上描述的每一种类型的有资格的顾客活动被传递到赠券管理应用软件300,其能导致在一个或多个应用于特定场所400的奖励中按照每一个奖励的规则产生赠券。因为顾客活动数据通过网络350传送给系统,所以在单个场所400中的顾客活动能在一些奖励中产生赠券,所述奖励可以应用于在单个场所、多个场所、或企业级的企业。
系统操作概述在一用于赌场的示范奖励中,一赠券奖励具有一组属性和规则。该赠券奖励在一个时间周期中被定义,在该时间周期内顾客、或游戏者有机会根据他们的顾客活动和用于赠券产生的奖励的规则赚得赠券。
赠券奖励的规则规定应该采取什么行动来响应各事件。例如,一个奖励有一组顾客目标、博奕合格、和赠券产生规则,它们来确定一个顾客是否并且如何在一个场所中通过该顾客的活动赚得赠券。
建立一个新的奖励赠券管理系统使一个奖励操作者能创建新的赠券奖励和修改现有的奖励。一旦该奖励操作者已经指定了一个特定的奖励,该操作者就可以用赠券管理应用软件300来创建新的奖励。在一个优选实施例中,一个奖励能从任何操作员终端320被创建。通过访问赠券管理应用软件300,一个操作者首先创建一个新的赠券奖励并且配置它的属性。在一个实施例中,该赠券奖励包括下列属性奖励开始和截止日期与该奖励有关的场所(一个或多个)关于赠券积累的限制(例如,滚动积累周期,赠券最高限度,或博奕频率限制)如图2所示,奖励可以是有关特定场所的,或者可以应用于包括一企业场所的子集的多个场所或者应用于该企业所有的场所(如,一种遍布企业的奖励)。
在奖励的基本属性被定义之后,操作者通过访问PMRP模块302定义一组应用于该奖励的规则。在一个实施例中,一个奖励的规则是以下列形式被构造的“If[条件]Then[行为]。”该规则的“If”部分包含一个或多个触发该规则的条件,并且该条件映射到用于检索和评估该条件的函数调用上。该规则的“Then”部分规定如果该组条件产生则将会被执行的一组动作。如果该组条件是真的,则采取该组动作,并且动作映射到执行那些动作的函数调用。在该赠券管理系统的上下文中,例如,如果顾客在一自动贩卖机中进行了一预先确定的次数量的博奕,那么一个赠券产生规则可能包含一个用于为该顾客产生赠券的动作“If[顾客的硬币输入>$300],then[产生10个赠券]。”在一个实施例中,PMRP模块302包括一个用来定义和处理与每一个奖励有关的规则的规则编辑器/引擎。该规则编辑器/引擎是一用来创建和处理奖励的规则的软件包。一个规则编辑器/引擎包含用于编辑规则和用于处理该规则的软件。一旦被定义,一个奖励的属性和规则就被存储在奖励定义数据库314中。规则引擎是特别有益的,在其中有大量的规则并且该规则可以经常地变化。但不论在哪种情况下,该规则引擎有益地使一用户——例如一个奖励操作者——利用一种商业用户可以很容易理解的语言编码新的规则。通过减少对技术人员的依赖,相关费用和工作周期被减少。
在赠券管理系统的一个实施例中,和每一个奖励相关的规则被分组成规则组,其中在每一个规则组中的规则触发、或被应用于不同的事件。一示范性的奖励包括下列规则组博奕合格顾客目标赠券产生提供兑换博奕合格规则组使系统能确定一个顾客的活动(例如博奕,住宿,采购,参加一个事件等)是否有资格在奖励中产生赠券。系统维持一个表明该顾客的活动在一“博奕”变量中是否合格的状态。下表列出了博奕合格规则组的规则用来评价条件的变量、以及如果条件为真则任何这些规则可以采取的动作的例子。

例如,一个不允许顾客在星期六通过玩一个特殊的博奕而赢得赠券的博奕合格规则是“If[博奕ID=12345]并且[星期几=星期六],Then[设置博奕为不合格]。”类似地,顾客目标规则组能使系统确定顾客在奖励或图画中是否是合格的。系统维持一个表明每一个顾客是否有资格赢得赠券的状态,其可以被存储在顾客数据库318中。下表列出了顾客目标规则组的规则用来评价条件的变量、以及如果条件为真则任何这些规则可以采取的动作的例子。

这些变量是对顾客特定的,并且在一个实施例中,该变量被存储在顾客数据库318中并且可以从该数据库进行检索。一个用于仅当顾客的保持百分比大于一预定值时才允许该顾客赢得赠券的顾客目标规则的例子是“If[顾客X的保持百分比>Y],Then[设置顾客X为合格]。”赠券人目标规则组有利地允许企业明确地把用于每一个奖励的顾客作为目标。正如可被理解的那样,规则组允许企业规定一组定义哪些顾客可以分享一特别奖励的条件或属性。在一个实施例中,企业可通过在一目标列表中放置那些个体来明确地标识可以分享一奖励的顾客。目标列表最好是一个存储在赠券管理系统中或可由其访问的数据文件。该目标列表允许企业职员使用任何外部的顾客目标机构(例如数据筛选)来构造一个对于一特别奖励是合格的顾客的列表。如在上表中所示的,一顾客目标规则可以基于是否一个顾客被包括在目标列表中。除了为顾客目标产生规则之外,这还给予了企业一个非常高的控制级别以用一个奖励来对准顾客。
当奖励待定时赠券产生规则组能使系统基于顾客的活动为该顾客在一个奖励中产生赠券。下表列出了赠券产生规则组的规则用于评价条件的变量、以及如果条件为真则任何这些规则可以采取的动作的例子。

为进行一场博奕而给予一个顾客赠券的赠券产生规则的一个例子是“If[博奕代码=Y],Then[为顾客Z产生X赠券]。”提供兑换规则组规定当一个顾客兑换一商家优惠卷时执行的规则。下表列出了提供兑换规则组的规则用来评价条件的变量、以及如果条件为真则任何这些规则可以采取的动作的例子。

PMRP模块302被编程用来响应于特殊的事件评价为所有待定的奖励而定义的规则。对一个实施例来说,触发每一个奖励的规则组的处理的事件在下表中进行描述。当这些事件中的一个产生并且和奖励应用的一个场所相关时,PMRP模块302处理如下表所示的奖励的相应规则组中的每一个规则。


在系统上实现一个新的奖励之前,操作者可以测试该奖励以查看它将如何对一样本数据集作出反应,并且查看它的操作是否与该奖励设计相一致。一旦奖励在系统上被执行,由于系统从上述的事件中接收数据,因此规则引擎被异步地调用。例如,该数据从一个特定场所400的顾客活动界面410传送,或者经由一个操作员终端320被输入到MA模块306中。在赠券管理应用软件300收集数据并且用于处理之后,应用软件300加载一个所有可利用的奖励的列表,该奖励在那个周期内是激活的,并且对于数据来自于其中的财产是有效的。每一个奖励的规则对如上描述的数据进行操作,并且如果在该规则中规定的条件经过评价是真的,则执行相关的动作。
如上所述,一个操作者可以同时定义和运行多个奖励,并且该多个奖励可以应用于一个特定的财产。在这样的一个环境中,仅仅一个奖励的规则应用于一个财产中的一个特殊事件是所希望的。例如,当有一个企业级和财产级的奖励时,一个顾客的博奕活动可以在这两个奖励中都产生赠券。然而企业可能不想要一个顾客从多个奖励中接收双重的赠券。在这种情况下,赠券管理应用软件300包括按优先次序列出奖励的代码。例如,应用软件300可编程为响应于单一的等级关闭事件不在多于一个的奖励中为一个顾客给出赠券。这能通过编程赠券管理应用软件300以在系统已经为一个特定奖励把一个赠券给予顾客之后不为任何其他奖励处理赠券产生规则来实现。替代地,这也能通过合并一个或多个奖励中的规则以避免在多于一个的奖励中产生赠券来实现。
除一规则引擎之外,许多其它的实施例也可能用于为一个新的奖励创建规则。例如,为了更灵活,可按照一预定的程序设计语言规则将产生器配置为直接接受正文(straight text)。在把规则添加到奖励中之前,规则产生器将会对它进行语法错误的检测。这将给予操作者一个用于创建奖励的高标准的灵活性。
替代地,奖励模板能被用在希望由企业进行更多控制的方面——例如企业级操作者想要限制本地财产级操作者定制奖励的能力的方面。在此情况下,企业级操作者为本地操作者提供奖励模板,其中该模板有大部分或所有的被定义的规则。该模板将只允许定制某些规则参数,如用于奖励的日期范围。本地操作者通过使用经模板允许的有限的基础规则组而使用PMRP模块302来创建奖励。
修改一个奖励使用在PMRP模块302中的一个规则引擎允许操作者有效地动态改变奖励的规则。而且,很容易理解的商业语言使商业用户从对IT人员的依赖性中被解放。在一个实施例中,规则引擎可通过一个web启用的编辑器访问,这样就允许从远程场所对该规则引擎进行全球访问。除产生奖励之外,一个操作者也能用赠券管理应用软件300修改一个现有的奖励。
图5说明了一个用PMRP模块302来创建或修改一个奖励的屏幕500的实施例。奖励编辑屏幕500可经由一个操作员终端320来访问。在屏幕500的左边是一个规则浏览器面板505,其显示了每一个规则组和用于奖励的相关规则。为了修改一个规则,用户选择其中一条规则。在图5中,博奕合格规则组中的规则2被选取,其通过高亮框510来显示。当选取了一个规则时,条件if/then规则语句显示在规则编辑面板515的右边,规则能在该编辑面板中进行编辑。显示在图5中的规则编辑面板515是上文所述的规则引擎实施例的一个例子。在这个例子中,一个用户能通过改变在条件变量下拉菜单520中的条件变量、条件值输入框525中的值、或动作下拉菜单530中的动作来修改规则。条件变量下拉菜单520包含每一个适用于在规则浏览面板505中选择的规则组的变量的列表。另外,动作下拉菜单530包含每一个适用于该规则组的动作的列表。(对一个实施例而言适用于每一个规则组的变量和动作已在上述表中提供。)用户能保存规则,添加新的规则,删除现有的规则,或检测(例如就适当范围)规则。
一旦一个奖励的规则被修改并且存储,这种改变就会被反映到奖励定义数据库314中,该数据库存储用于奖励的现在的规则。因此,如果在一个场所一操作者编辑了应用于多个场所的奖励的规则组,这些改变会影响该奖励在其应用的每一个其它场所如何执行。这就允许远程创建和保持多个可应用于一个企业的一个、多个或所有奖励的多个奖励的保持。
人工调整在某些环境中,一个操作者可能希望能记入贷方或赊欠一顾客的帐目。这个问题可以会因为下列的理由出现,例如客户服务问题,服务恢复,系统故障,以及一个顾客需要被增加一个奖励。MA模块306使一个操作者能观察和修改就一特殊奖励有资格的顾客列表,以及能改变在一个特定奖励中顾客的赠券数。
图6说明了用于从一操作员终端320访问MA模块306的屏幕流程图。从一个选择奖励屏幕610,用户首先选择希望在其中进行人工调整的奖励。然后,在一个选项菜单屏幕620中向该用户呈现选项列表。在该实施例中,有两个选项可利用给奖励增加一个顾客和向一个顾客的用于该奖励的帐目上增加赠券。
在一个实施例中,在顾客能基于他们的博奕活动赚得用于奖励的赠券之前,该顾客必须明确地有资格获得该奖励。添加顾客屏幕630使用户能观察一个有资格获得该奖励的顾客列表。用户能把顾客添加到该列表中和把顾客从列表中删除。添加赠券屏幕640使用户能调整一个顾客在该奖励中的赠券。在这个屏幕中,用户可观察所有有资格获得该奖励的顾客的列表,选择一个特定的顾客,并且为该顾客添加或删除赠券。
顾客状态PS模块304允许个别顾客使用例如一个在场所400处的客户服务界面420来观察他们赢得的赠券。在一个实施例中,一顾客通过例如刷取一游戏者跟踪卡或通过在一客户服务界面420的键盘或触摸屏上键入对顾客特定的信息来登录PS模块304。在另一个实施例中,顾客也可以用一个人电脑324或其它web启用的设备经由互联网112访问PS模块304。在顾客登录到系统之后,该顾客能观察他的赠券,并且最好是能观察关于企业想要的其他任何信息,例如顾客的统计擞据及其它奖励。
赠券的兑换赢得的赠券被系统存储,顾客后来能这些赠券兑换成商品、服务、或其它的由该企业投资的博奕。在一个实施例中,赠券被存储在赠券数据库316中。依赖于系统的应用,预想了各种允许顾客兑换赠券的方法。例如,在一个顾客希望把赠券兑换为看一场演出的赌场环境中,该顾客要首先把他们的希望表达给一赌场职员。优选地,企业有一个或多个顾客可去兑换赠券的指定区。响应于一个兑换赠券的要求,一职员手动或通过使用一个读卡机刷取顾客的跟踪卡来把顾客的信息输入到系统中。利用该系统,职员检验顾客有足够的赠券并且,如果是这样的话,则把用于所请求演出的票或者顾客可以抵价购票的赠券纸条提供给顾客。然后该职员使用MA模块306从顾客帐目中手动地扣除所花费的赠券(如以上结合图3和6描述的那样)。
在另一个实施例中,赠券交易被自动执行,不需要一个操作者访问系统并且手动地扣除所花费的赠券。例如,一个顾客可以把赢得的赠券兑换成在和企业有关的餐馆中的一顿饭。顾客向服务器提供顾客的标识(例如通过给与服务器该顾客的跟踪卡),这样服务器就能进入系统。有利地,服务器通过刷取顾客的跟踪卡可把顾客的标识输入到和系统耦接的读卡机。已知顾客的标识和提供的商品、服务或提供的其它博奕,该系统计算要从顾客的帐目中扣除的赠券数目。
在另一个实施例中,顾客通过互联网连接到系统上来远程地兑换赠券。如图3中所示,顾客能在家用他们的计算机系统324通过互联网322耦接到赠券管理应用软件300。例如,一个顾客可以通过访问一个网络站点来进行预定,正如本领域中公知的那样,以便入住和企业相关的宾馆。然后顾客提供给系统一些标识(例如,一个顾客跟踪ID最好伴随一个安全密码或其它个人信息),系统能用其确定顾客是否有足够的赠券。然后系统从顾客的帐目上扣除预定数量的赠券以换取宾馆的预定。
仅仅通过举例提供了上述兑换赠券的方法。因此,能够预见在本发明范围内任何许多兑换方案能被用来赠券兑换为商品、服务、或其他博奕。
总结已经按照把企业奖励具体应用到赌场上下文中而描述了本发明的最优方案。系统被有利地应用于产生和管理用于赌场和其它博奕企业的赠券;然而,本发明可以广泛地适用于许多其它的企业以产生和管理任何类型的顾客能赚得和兑换的“点数”。例如,本发明能被用来在信用卡、航线经常飞行里程、娱乐、用餐服务、购物和在线活动领域来管理可兑换点数。
此外,多个奖励能应用于一组实际场所,或例如应用于虚拟场所如网络站点。实际的场所包括赌场,旅游客船,饭店和其它的零售环境。在企业场所是一个网络站点时,顾客能在一个或多个赠券奖励中经由某些合格的在线活动产生赠券。依赖于一个奖励的赠券产生规则,合格的在线活动包括在该网络站点的用户注册、登录和访问该网络站点、在该网络站点上查看具体的页面和广告、在线游戏、回答在线的调查表、和从该网络站点购买商品或服务。一奖励可以被配置为适用于该网络站点以及一组该企业的场所,其中顾客可通过他们的在线活动和在一个或多个该企业的财产中赢得奖励中的赠券。然后顾客能兑换于线和财产中赢得的赠券。
已经为了说明和描述的目的给出了上述发明实施例的描述。但是并不是想穷举或限制本发明为所公开的准确形式。相关领域的技术人员能够理解,按照上述教导多种修改和变化是可能的。尤其是,许多变化和特定的设计选择在不脱离本发明构思的情况下能被用到在此描述的赠券管理系统的特定实施例中。所以意图使本发明的范围不只局限于这里的详细说明,而是由附后的权利要求所限定。
权利要求
1.一种用于为企业管理赠券的计算机执行方法,该方法包括监控顾客活动,该顾客活动与企业和一个或多个顾客之间的交易相关;以及使用一组顾客目标规则和一组赠券产生规则为一个或多个顾客产生赠券,该顾客目标规则确定每一个顾客是否有资格拥有为此产生的赠券,并且如果该顾客是合格的,则赠券产生规则根据顾客活动确定为每一个顾客所产生的赠券数量。
2.如权利要求1中所述的方法,其特征在于监控顾客活动包括在和企业相关的多个场所监控顾客活动。
3.如权利要求1中所述的方法,其特征在于顾客活动包括在一个赌场环境中博奕。
4.如权利要求1中所述的方法,其特征在于顾客活动包括非博奕活动。
5.如权利要求1中所述的方法,其特征在于该组顾客目标规则包括一个如果顾客被包含在一个顾客目标列表中则允许该顾客赢得赠券的规则,该顾客目标列表标识一组顾客。
6.如权利要求1中所述的方法,其特征在于该组赠券产生规则包括一个根据顾客的投币产生赠券的规则。
7.如权利要求1中所述的方法,进一步包括接收来自于顾客的要将赠者兑换为商品,服务或其它博奕的请求;并且响应来自于一个顾客要兑换赠券的请求;从该顾客的赠券中扣除一预定数;并且把所请求的商品、服务或其它博奕提供给该顾客。
8.如权利要求7中所述的方法,进一步包括响应来自于一个顾客要兑换赠券的请求,确定该顾客是否拥有预定数目的赠券用于满足该顾客的请求。
9.如权利要求7中所述的方法,其特征在于接收请求包括通过互联网从顾客那里接收请求。
10.如权利要求1中所述的方法,进一步包括修改顾客目标规则或赠券产生规则。
11.如权利要求10中所述的方法,其特征在于修改包括使用一规则引擎。
12.如权利要求1中所述的方法,进一步包括使不是在一个预定的滚动积累周期内产生的任何赠券到期,其中到期的赠券不能被兑换。
13.如权利要求1中所述的方法,进一步包括如果一个顾客在一个预定的时间周期中没有赢得预定数目的赠券,则使和该顾客相关的所有赠券到期,其中到期的赠券不能被兑换。
14.如权利要求1中所述的方法,其特征在于产生赠券包括只有当顾客拥有少于一预定上限的赠券时才为每一个顾客产生一个赠券。
15.一种用于在一个企业的多个场所管理多种赠券奖励的计算机执行方法,其中每一个赠券奖励适用于一个或多个场所,该方法包括在每一个场所监控顾客活动,该顾客活动与该企业和一个或多个顾客之间的交易相关;以及使用一组顾客目标规则和一组赠券产生规则为顾客在适用于该场所的每一个赠券奖励中产生赠券,该顾客目标规则确定每一个顾客是否有资格拥有为此产生的赠券,并且如果该顾客是合格的,则赠券产生规则根据顾客活动确定为每一个顾客产生的赠券数。
16.如权利要求15中所述的方法,其特征在于第一个赠券奖励适用于与第二个赠券奖励不同的一组场所。
17.如权利要求15中所述的方法,进一步包括接收来自于顾客要将和一个奖励相关的赠券兑换为商品、服务、或其它博奕的请求;并且响应来自于一个顾客兑换赠券的请求;从该顾客的和奖励相关的赠券中扣除一预定数;和把请求的商品、服务、或其它博奕提供给该顾客。
18.如权利要求15中所述的方法,其特征在于顾客活动包括在一个赌场环境中博奕。
19.如权利要求15中所述的方法,其特征在于顾客活动包括非博奕活动。
20.一种用于为具有多个场所的企业同时管理多个赠券奖励的企业奖励系统,该系统包括一个或多个管理系统,适用于在各场所中监控顾客活动并且根据顾客活动创建顾客活动数据;一个赠券奖励数据库,用于存储和多个赠券奖励中的每一个相关的规则,用于至少一个奖励的规则包括用于确定是否每一个顾客可以赢得赠券的顾客目标规则和用于确定从每一个合格的顾客活动中赢得的赠券数的赠券产生规则;和一个耦接到赠券奖励数据库的保持模块,该保持模块适用于从管理系统中接收顾客活动数据,以及就任何应用于相应顾客活动所发生的场所的赠券奖励来说,适用于按照奖励的规则在赠券奖励中为每一个顾客产生赠券。
21.如权利要求20中所述的系统,进一步包括一个耦接到赠券奖励数据库的保持模块,该保持模块适用于响应来自于一个操作者的请求添加与赠券奖励相关的顾客目标和赠券产生规则。
22.如权利要求20中所述的系统,进一步包括一个耦接到赠券奖励数据库的保持模块,该保持模块适用于响应来自于一个操作者的请求修改与赠券奖励相关的顾客目标和赠券产生规则。
23.如权利要求22中所述的系统,其特征在于保持模块耦接到一个用于接收来自于一个操作者要修改顾客目标和赠券产生规则的请求的规则引擎。
24.如权利要求20中所述的系统,其特征在于顾客活动包括在一个赌场环境中博奕。
25.如权利要求20中所述的系统,其特征在于顾客活动包括非博奕活动。
26.一种用于为一个企业定义一种赠券奖励的方法,该方法包括定义一组和企业相关的、赠券奖励可以在其中应用的场所;提供一组用于确定每一个顾客是否有资格拥有为此产生的赠券的顾客目标规则;以及提供一组用于如果顾客是合格的则根据顾客活动确定为每一个顾客产生的赠券数量的赠券产生规则。
27.如权利要求26中所述的方法,其特征在于该组顾客目标规则包括如果顾客被包含在一个顾客目标列表中则允许该顾客赢得赠券的规则,该顾客目标列表标识一组顾客。
28.如权利要求26中所述的方法,其特征在于该组赠券产生规则包括根据顾客的投币产生赠券的规则。
29.如权利要求26中所述的方法,其特征在于提供一组顾客目标规则和提供一组赠券产生规则,它们均包括使用一规则引擎。
30.如权利要求26中所述的方法,进一步包括定义一个滚动积累周期,其中不是在该滚动积累周期内产生的任何赠券到期。
31.如权利要求26中所述的方法,进一步包括定义一个频率限制,如果顾客在一个预定的时间周期内没有赢得一预定数量的赠券,则该频率限制使得和该顾客相关的所有赠券到期。
32.如权利要求26中所述的方法,进一步包括定义一个赠券上限,其中只有当顾客拥有少于该上限的赠券时该顾客才可以赢得赠券。
全文摘要
一个基于规则的赠券管理系统通过把顾客和/或某些顾客活动作为目标来为顾客产生赠券。在一个实施例中,该系统方便了多个同时的赠券奖励,每一个赠券奖励可定义为由用于一企业的单一场所、多个场所、或所有的场所。利用顾客活动数据,该系统在一个或多个奖励中根据每一个奖励的规则产生赠券。该系统在顾客赢得赠券并且兑换它们时跟踪赠券。
文档编号G06Q30/00GK1480887SQ03138458
公开日2004年3月10日 申请日期2003年4月1日 优先权日2002年4月1日
发明者蒂穆·斯坦利, 蒂穆 斯坦利, J 里夫斯, 蒂莫西·J·里夫斯, 克斯, 本·帕克斯, W 诺顿, 戴维·W·诺顿 申请人:哈拉斯营业公司
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1