具体实施方式
现在参看附图中的图1,图1中的电子交易系统包含一个具有前端接口2的优惠购物券处理系统1。术语“现金优惠购物券”在本说明书中的用法有特殊的意思。要把它明确地区别于经常由零售商用于随后的兑换的纸质优惠购物券(paper voucher)。记录代币(recordtokens)是这种纸质优惠购物券的著名例子,如同零售商根据顾客购买量发行的奖励优待券(reward coupon)一样。在本说明书中,现金优惠购物券实质上是存储在安全的主数据库中的计算机记录。将要被描述的系统有几个功能层,仅为本说明的目的,假设整个现金优惠购物券系统的参与成员是在图中分别表示为3、4和5的三个不同的零售商A、B和C。仅为本说明的目的,再假设各零售商现在是传统零售商,或者向到商店购物的个人或者向从远处订货的顾客提供商品。
图1中所示的系统1由5个功能层,分别以100、200、300、400和500表示。
第一功能层100包含用户在其上与整个系统交互的各终端。
于是将看到,零售商A有一个自助式现金优惠购物券销售终端6和一个有人值守的现金优惠购物券销售终端7。零售商B有一个优惠购物券兑换终端8,但是零售商C仅通过因特网处理现金优惠购物券的销售和兑换。
第二功能层200代表零售公司,顾客通过层100,以购买现金优惠购物券的方式或者用以前购买的现金优惠购物券兑换商品的方式,与这些零售公司做生意。
在功能层100,自助式终端6实质上包含一个诸如键盘的手动数据装置、一个显示终端和一个用于读取信用卡/借记卡或用于确认或接收现金的读卡机。它也可包括一个打印机,用于打印优惠购物券的硬拷贝。图3表示这样一例使用信用卡/借记卡的终端。希望购买现金优惠购物券的顾客将根据其PIN进行一系列动作,这些动作类似于从自动取款机取款时用到的动作。有人值守的终端7也有一个被值守人使用的手动数据输出装置,还能取得现金或者零售商可接受的任何其它支付媒介,作为交换,发行一个现金优惠购物券。值守人自然还能进行对顾客身份的验证。
标注号4所示的零售商B有一个兑换点8,此处可以用现金优惠购物券兑换现金或商品,而标注号5所示的零售商C则有一个基于因特网的系统,顾客可通过该系统在因特网上获得现金优惠购物券。为此,顾客必须能接入因特网,而这个条件很快就能以例如通过任何因特网PC或移动电话等各种方式提供。用户通常将有一个带有调制解调器的PC 9,以便能通过用户自己的因特网服务提供商(ISP)9’联系零售商C的ISP 5。
要认识到,这三个终端6、7和8纯粹是示例性的,没有必要对第二层200的零售商限制任何一种终端类型。在任何情况中,终端的功能实质上是从用户收集优惠购物券的购买和兑换信息并进行基本的确认。任何确认的量,将依赖于无人值守的数据收集终端的智能程度或在有人值守终端上的要遵守的程序。这些程序可以由零售商确定,只要它们满足系统运营者(operator)的最低要求。本说明书在后边将更详细地讨论零售商与优惠购物券系统之间的商业关系。
在总系统的第二层200中的由各个零售商在正常经营过程中所执行的正常功能,将不作详细讨论。然而在这个第二层中,在层100中的终端上被输入的新数据被零售商处理,用于传送到功能层400中的核心系统1的接口2。
刚刚描述过的零售商,都是现金优惠购物券系统的“成员”。因此,它们可拥有自己的优惠购物券方案(scheme),在这种情况中,可能持有一个银行账户,用于在现金优惠购物券系统的经营中的资金。另一方面,成员们可以让别人代表他们管理该系统。一个例子就是通用簿记优惠购物券方案(universal book voucher scheme),该方案可以有一个所有者,诸如“大簿记代币有限公司”(Big Book TokenLtd)。然后现金优惠购物券就能从任何零售商购买到,并能以适当的条件从任何接受的零售商兑换。
在本发明的一个实施例中,功能层200中的这个处理实质上是先进行一个将在后文更详细说明的第二级确认,然后将数据加密成适于向层400传输的格式。这个传输既可以通过如功能层300中的11所示的著名的银行间通信系统(Interbank Communication System)进行,也可以从零售商直接进行。即使在第二种情况中,加密的数据的格式也可以是用于银行间通信系统的标准的MTIxxxx格式。此外,零售商也能在层100或200的任何一个上引入优惠购物券的兑换的约束条件。这些约束条件相当重要,将在本说明的后文中详细讨论。
层200的其它基本功能是解密从层400接收的消息。
所示的连接层200和400的虚线12,表示层200中的零售商系统与层400之间的可选的连接,它不需要所采用的什么通信协议的格式。这个连接能被用来传输非紧急的数据,诸如额外的零售商所持有的关于现金优惠购物券的数据以及供零售商自己分析和记录之用的管理信息。因此,这个连接12不必进行当在各功能层之间传输现金优惠购物券的细节时所用的加密。
另一个连接13如图所示连接层200中的零售商14至位于层400中的核心系统1。这个连接14可传输含有要被大批分配的优惠购物券的细节的大批分配文件(bulk allocation files),因此可被用于分配可能作为顾客忠诚奖励的或用于促销计划的现金优惠购物券。
现在转至核心系统1,该系统有一个接口2,该接口有一个部件15和一个部件16,部件15用于通过连接12和13接收消息,部件16专用于通过银行间通信系统11或如未标出的从3至5的路径所示地直接从零售商或向零售商接收或发送标准格式的消息。中央处理器1的另一个主要接口如17所示,该接口由系统运行者11使用,系统运行者11是代表参与的成员管理整个系统的组织。
核心系统1的基本组成之一是数据库19,其中装有用于现金优惠购物券的处理的多个数据库表。数据库19的主要各表在附图2中表示,包括保存有效的(live)和兑换过的现金优惠购物券的数据的主表20。该表20在本发明实施例中被划分成不同的部分,包括一个保存所有尚未兑换的现金优惠购物券的详细资料的有效优惠购物券表,和一个可能保存所有已经兑换的现金优惠购物券的详细资料的历史优惠购物券表。上述“可能(may)的意思是,可能有必要在预定的时间消逝后在一个档案部分(archive section)中将历史优惠购物券的详细资料归档。此外,表20还保存无人要求的(unclaimed)优惠购物券的详细资料。数据库19的表20保存成员详细资料,即所有那些参与由系统经营者管理的现金优惠购物券处理系统的诸如零售商A、B和C等成员。所以,成员或者是零售商,或者是各个方案的业主。
表22是资金分类账表(Fund Ledger table),保存对有效购物优惠券表中列举的现金优惠购物券提供支持的资金的详细资料。表23保存当优惠购物券被发行或兑换时发生的资金分类帐交易(transaction)的详细资料。每个资金分类账实际上反映(shadow)在功能层500指示的保存在金融机构的物理银行账户。下文将更详细地说明资金的组织方式以及资金与实际银行账户交互的方式。
与资金分类账表22相关联的是优惠购物券发行人表(VoucherIssuer table)24。该表展示现金优惠购物券被发行人发行所需的条件。在这一点上这实际上是要阐明核心系统的经营者与参与顾客请求和兑换现金优惠购物券的实际过程的那些成员之间的可能关系。成员可属于一系列不同的类别(category)。
第一类别是优惠购物券发行人,有时称为业主。优惠购物券发行人是与系统的经营者签约的一方,其通过设定如何使用优惠购物券的约束条件而定义优惠购物券的特定种类(class)。
第二类别由被授权代表某优惠购物券发行人销售优惠购物券的那些成员组成,第三类别含有那些被授权兑换优惠购物券的成员。当然,某优惠购物券发行人属于其它两个类别的一个或两个也是完全可能的。由系统生成的现金优惠购物券号码包括一个优惠购物券发行人号码(VIN)。这个VIN标识优惠购物券发行人。如上文提及的那样,优惠购物券发行人能定义关于现金优惠购物券的使用的约束条件。在本实施例中,这是实现这一点的方法是在现金优惠购物券中使用一个额外的编码,使得VIN与这个额外编码的组合定义优惠购物券的使用条件。核心系统在正常操作中没有必要知道约束条件代码,这是优惠购物券发行的事情;约束条件代码将在一个优惠购物券被购买时随要求生成优惠购物券的请求一起被传送到核心系统。VIN与约束条件代码的一个特定组合被认为定义一个特定产品。它们的生成方式将在下文作说明。所以,优惠购物券发行人表24中保存的数据例如包括预优惠购物券相关联的资金账户、最小和最大优惠购物券值、优惠购物券可兑换的开始日期、优惠购物券的持续时间以及关于任何优惠购物券的销售和/或兑换的佣金费用。优惠购物券除非有到期日期,否则它就要一直保留在数据库的有效优惠购物券表中。持续期间一天数、月数和年数表示,在购买时从优惠购物券开始日期开始计算。下文将更详细地说明组织资金账户的方式。
以下的段落给除能被优惠购物券发行人设定的并且能与现金优惠购物券相关联的约束条件的种类的更详细的例子。如已经解释过的那样,这些约束条件一般是在层100或层200中生成现金优惠购物券时由相关的方案数设定的。第一,可以根据连锁店设定现金优惠购物券的购买或兑换的约束条件。这样,就能对现金优惠购物券设定约束条件,使得现金优惠购物券只能在一组零售商的某些中购买,并且能在该组的所有零售商处兑换或者在构成该组的零售商的某些零售商处兑换。销售商店和兑换商店不必相同。
第二,不管有没有上述约束条件,都可以将现金优惠购物券限定为兑换时要购买一定种类的商品。
第三,可以在包括以上两个例子的约束条件的一系列不同的零售商处购买或兑换优惠购物券。
如以上讨论的那样,优惠购物券可以是“通用的”优惠购物券,因为它能在多个零售商的任何一处兑换,但是能从在为这些零售商提供服务的意义上只与这些零售商联系的不同组织处购买。在任何情况中,现金优惠购物券都可能有地理约束条件,使得它只能在特定地区兑换,这种地区可以是城镇、城市、县或国家。
现在值得强调的是,本说明书中所用的术语“零售商”并不仅仅限于零售商店,实际上可包括任何现金优惠购物券的提供者,包括诸如DHSS的政府机构、银行和邮局。
尽管大多数零售商很可能将利用这种灵活性来定义和管理它们自己的约束条件代码(产品),VIN组经营者也可以选择向那些要求较低水平的约束条件管理的零售商提供这个功能。在这种情况中,VIN组经营者将用已经提及的约束条件表来设定和管理约束条件代码。
为了生成优惠购物券发行人表24,成员表21保存着这些商店的能被用于购买和兑换优惠购物券的详细资料。在这个上下文中,必须认识到,主要的零售商将由许多销路或商店,在某零售商的一个商店购买的优惠购物券不必在该零售商的所有商店都有效。因此这个特点也在优惠购物券发行人的控制之下。成员的表21为每个成员保存一个独有的成员标识符,使得优惠购物券只能按标识的号码被兑换。
表25专用于方案零售商并列举所有关于那些零售商能销售或兑换现金优惠购物券的详细资料。
又可能在优惠购物券发行人表24之外设置关于现金优惠购物券的使用的约束条件。这些约束条件,如果被核心系统管理,将被保存在单独的约束条件表29中。
除了刚才说明过的主表,主数据库19还保存若干将被简单描述的辅助表。首先,为了安全,将使用过的号码保存在表26中。此外,表27和28保存能被管理人员使用的关于优惠购物券的使用的统计数据。
要认识到,数据库中存储的数据对优惠购物券的使用的所有方面非常详细,这些方面诸如是媒体使用的销售和兑换的数量、地理分布。因此成员能容易地提取商业特征档案(profile),用于调节它们的宣传、生成新产品以及有用的管理统计。现在还没有手动的或半自动的系统能实现这一点。
此外,主数据库可含有一个保存所有已经过期的优惠购物券的详细资料的表。过期的优惠购物券在用户定义的过期后的时间被转移到该表中,该表的结构与用于有效现金优惠购物券的表的结构相同。
尽管本实施例明显地披露了在一个位置的一个数据库,将数据库的各种区域(areas)和表分布到不同地理位置上当然也是可能的。
再次参看附图1将看到,中央核心系统1也被划分成多个功能区域。
核心处理器1的整体功能包括优惠购物券购买和兑换的提交和处理,优惠购物券的大批分配,向接收者通知所分配的优惠购物券号码,以及优惠购物券资金的管理。
因此,与两个通信线12和13相关联的是处理优惠购物券号码的大批分配的功能区域32和处理诸如参与者信息等非紧急数据的功能区域33。这些区域通过接口部件15通信。
在本实施例中,核心处理器1的其它功能区域通过接口部件16与功能层100、200和300通信。
这些功能区域是功能区域34、35和36,它们分别涉及优惠购物券购买、优惠购物券兑换和优惠购物券发行人管理。
处理器1的其余功能区域的最重要的处理资金管理的区域37、处理费用管理的其余38、处理对帐区域39、以及处理成员管理的区域40。
在对电子处理系统的实施例作了一番概述后,现在将通过举例说明构成核心处理器1和接口2的硬件构件。
现在参看附图中的图3,该图显示能被用于图1中所示的总体系统的硬件。在图1中所描述的各功能层也出现在图3中,图中可见,层300是可选的,已经被省略。层100包括如标注号40所示的电子销售点终端,服务员可在电子销售点终端上输入要被顾客购买的现金优惠购物券的详细资料,而标注号41则表示位于发生优惠购物券交易的实际商店中的处理器。
层100中也显示有一个打印机34,用于打印发行的现金优惠购物券的号码。打印机也可以能够打印代表优惠购物券号码的条形码,以便能在配备条形码阅读器的收款柜台上兑换优惠购物券时更快地读取该优惠购物券。
零售商中央处理中心为位于层200,如标注号44所示,中央处理器1与主数据库19一起被表示在层400中。预计优惠购物券操作的数据量和交易速度将需要相当大的计算机存储和处理能力。系统也需要有较高的可用性、弹性和安全性。未满足所有这些要求,希望在使用IBM的(RTM)操作系统(MVS)、数据库(DB2)和访问控制和安全软件(RACF)的IBM主机上或相当的系统上运行优惠购物券系统。
在给出概述核对适当硬件的说明之后,现在将更详细地对图1中所示的系统的操作进行说明。已经介绍了现金优惠购物券的概念,应当明白,这些现金优惠购物券完全不同于基于纸件的优惠购物券,因为它们是“虚拟的”,就是说它们是以数据的形式存在的。实际上,现金优惠购物券只是以在安全主数据库19中存储的计算机记录的形式存在的,主数据库能被诸如大街上的零售商或基于网络的零售商的任何参与成员全局地实时访问。计算机记录被唯一性的代码标识,并且如已经说明的那样含有标识计算机记录的位置的详细资料和定义优惠购物券可兑换的方式的因素。因此,每个优惠购物券的值被存储在一个账户中,该账户只专用于与优惠购物券相关联的资金。相应地,当购买人利用功能层100购买优惠购物券时,向购买人提供一个唯一性代码。该唯一性代码又使系统能确定值、到期日以及如上文结合图2的优惠购物券发行人表所述的或者一般由VIN业主设定的约束条件。这样,现金优惠购物券的购买人在销售时就得到关于包括到期日的优惠购物券附属的约束条件的数据。
相应地,有关被购买的优惠购物券的唯一性代码相当重要。因此,有效优惠购物券号码的所有人不可能对另一个号码作出有根据的推测并使用之。例如,在一个纯粹为举例而给出的情景中,如果优惠购物券号码是顺序分配的,有一个校验位,则具有号码896657、896662和896670的优惠购物券的购买人可能合理地猜测89668x是一个有效号码。最多只需要试猜10次就能确定x的值。
所以在本实施例中,优惠购物券号码是一个唯一性的19位数。所选的长度与信用卡/借记卡产业中目前使用的最大长度相匹配,即符合ISO 8583。前六个数位构成已经被分配给系统经营者的IIN(标识号码)。
编码号码可以以表A所示的方式划分。
表A
位置1-6 |
位置7-10 |
位置11-18 |
位置19 |
IIN(6位) |
VIN/约束条件代码(4位) |
优惠购物券标识符(8位) |
校验位(1位) |
数据库标准有些VIN业主可以有自己的IIN |
由优惠购物券的卖者设定 |
由经营者系统建立 |
由经营者系统根据标准算法从其余的算出 |
因此将看到,是优惠购物券号码的位置7-10使参与成员能设定诸如说明书早先说明过的的那些约束条件。编码号码的这种划分是可以改变的。具体例如VIN约束条件代码不需要4位,例如可以是3位。
此外,优惠购物券号码的生成要使用一种保证号码不重复的算法。
在本实施例中将用以下的逻辑来分配优惠购物券号码。
获得一个随机号码。
查验该号码不在“不使用”列表中。如果在,则递增该随机号码,然后重试。在一定次数的不成功重试后,获得另一个随机号码。在一定数量的不成功随机号码之后,再初始化(reseed)随机号码生成器并再次尝试。在一定次数的不成功的再初始化之后,放弃该分配努力,停止该事务处理—在尚未达到最佳的最大分配的此时停止,表明选择了一个不好的随机号码生成器。应当保留关于成功/不成功尝试的统计资料,并要定期地报告该统计资料,已警示该管理人员潜在的问题。
查验该号码还没有被分配给所要求的产品。如果已经被分配,则如上所述地重试。
多于所有可能的号码的“绝对最大量有效分配”或“绝对最大量分配”已经被分配给特定产品是很不可能的情况,这样就不可能发行优惠购物券。
下面将更详细地讨论一个用于查验分配了的号码和发出警告的算法。
以所述的优惠购物券号码结构和预期的量为假设,这个情况仅在“最佳最大量分配”限度已经达到的警告后的若干年后才会发生,接着是更多的正在接近“绝对最大量分配”水平的警告。如果要对警告采取行动,这些警告应当给予足够的时间来调查和提出备择方案,例如对“相同”产品开始另一个产品号。
该系统所实现的一个重要特征是,为了减少无效或欺诈性交易被引入到通信网络中的可能性,每个零售商的消息将包括一个序列号(对每个零售商类别以及进入的和外出的消息有不同的序列),序列号将被接收系统验证是否是序列中的下一个。
作为针对欺诈性联系的额外的查验,系统在成员表21中保存标识例如成员网络地址或电话号码的数据,以便系统能在确认优惠购物券的兑换之前查验成员标识号码和联系源。
正如已经提及的那样,该系统的其它安全特征是监视每个产品的未兑换(有效的)优惠购物券占可能的号码总数的百分比,以及有效的优惠购物券的值的特征档案,以确定最普通的值。通过中心地监视,将使系统运营者能评估优惠购物券号码、值和到期日被猜到的风险。风险随着有效优惠购物券的百分比的增加并且有高比例的相同价值的有效优惠购物券时而增加。当特定产品的风险上升到预定阈值时,优惠购物券发行者将被警告。如果第二阈值被破,将发出一个更强烈的警告,例如请求引入一个新产品。如果第三阈值被破,则该特定的VIN/约束条件代码组合的优惠购物券的发行将被停止。在图18中,定时器99启动步骤S80,这是定期安全检查的开始。在步骤81,处理器检查某VIN的有效优惠购物券数量与可能的优惠购物券数量的比率。在步骤S82,根据所有有效优惠购物券的特征档案确定哪个是最普及的产品。步骤S83计算有效数量与可能的最流行产品数量的比率,步骤S84确定是否该比率高于第一阈值。如果答案是否定的,则不采取其它步骤,直到该检查序列再次被定时器或被管理决策启动。另一方面,如果步骤S84的答案是肯定的,则在步骤S85发出一个第一警告。在步骤S86确定在步骤S83所计算的比率是否高于第二阈值,同样,如果答案是否定的,则不采取其它步骤。然而,如果答案是肯定的,则在步骤S87发出一个更强烈的第二警告。最后,在步骤S88确定所计算的比率是否高于第三阈值,如果该确定的答案是肯定的,则在步骤S89停止该特定产品的发行。
现在转到附图4,该图表示一个在购买优惠购物券时遵守的基本程序的流程图。假设购买点是类似于图1的零售商A的大街上的零售商,具有销售终端6。这样,优惠购物券就可以与商店中的其它任何商品一起被购买,或者作为对顾客刚刚购买的量的奖励而被获得。
在图4中,步骤S1表示售货员在销售终端记下被要求的优惠购物券的详细资料以及任何本地确定的产品约束条件及任何其它确认,向本地控制器(controller)发出一个优惠购物券请求。在步骤S2,本地控制器把该请求发送到功能层200中的零售商系统。
零售商系统在步骤S2具有的主要功能是,执行额外的确认程序,确定该请求中的VIN/约束条件代码,以适当方式加密该优惠购物券请求,并把加密的优惠购物券请求发送给功能层400。
在本实施例中,零售商系统用APACS标准60发出优惠购物券购买请求。这个标准顾及私人使用消息,定义各种数据元素以及对于每类消息哪些数据元素是必需的、哪些是有条件的。APACS标准60是用于图1的功能层300中的银行间通信系统11的标准。
要清楚地明白,APACS标准60的使用对本发明构思来说并非是根本性的,因为这个标准的使用对于本发明的实现并非是不可或缺的。例如在美国的用户就可以使用不同的格式。
银行间通信系统11在图4中没有显示,也没有在类似的图5、6、7中显示。这是因为在实现本发明时,银行间通信系统只是被用作已经可得到的安全消息管道。
因此,加密的消息可以或者通过银行间通信系统发送,或者直接发送到接口2的部件16。
该接口有一种形式的确认,因为它保证请求的格式正确并且来自一个已知源。在步骤S4中,加密的优惠购物券请求被接口2接收并转发,用于步骤S5中的购买请求确认。购买请求确认程序包括检查零售商提供的4位VIN/约束条件代码是符合某个有效的优惠购物券方案。此外,所请求的优惠购物券的其它标准还要符合该特定VIN的属性。如果在该确认程序中没有发现错误,则在步骤S6中,向每个优惠购物券请求分配一个优惠购物券号码。优惠购物券号码的分配引起对已经作过说明的资金表的相应更新,这是在步骤S7中进行的。在步骤S8中,有关该优惠购物券的信息被传送到管理系统(未予示出),用于计算系统运营者所收取的费用,在步骤S9,一个响应消息被返回到通信接口2的部件16。
管理费的计算对于本发明构思来说不是主要的,可以针对逐个优惠购物券或逐项购买行为进行,也可能针对兑换而进行。另一方面,也可以按预定的间隔根据购买的或兑换的优惠购物券的总值计算管理费。
如果在上述处理期间优惠购物券请求没有得到确认,则还是APACs标准60格式的响应是否定的。在任何情况下,通信接口都通知零售商系统结果,零售商系统进而通知发起终端的本地控制器。在本例中,终端发行一个带有所分配的优惠购物券号码的打印的优惠购物券。此时,打印机能向标识唯一性优惠购物券号码的值增加一个条码。
零售商可选择打印关于优惠购物券的发行的信息。这个信息可以仅仅是优惠购物券号码,或者是额外的描述性信息,诸如价值、到期日和任何使用条件,信息被打印在它们自己选择的纸上,例如普通纸、有厂商标记的纸或礼品卡上。可以将号码印成条码,以帮助兑换零售商快速处理优惠购物券以及管理该号码标识的任何产品约束条件。
应当明白,上述描述是从顾客出现在有人值守终端的角度给出的。
如附图1中所示,这不是唯一的情景。图1的功能层100包括通过因特网购买现金优惠购物券的可能性。在这种情况中,零售商系统必须先对通过因特网提供的顾客详细资料进行验证,再为传送功能层400发出优惠购物券请求。这就是在图3的流程图中所示的过程。
现在参看图5,购买者在本实施例中用PC发出一个优惠购物券购买请求。当然,也可以用其它的因特网接入方法,诸如专用蜂窝电话或直接电视连接。在步骤S11和S12中,购买者用他的ISP连接到因特网,在步骤S13用零售商的ISP访问零售商网站。购买者然后在选择的优惠购物券发行人的零售商网站上填写一个购买表单。为了验证,购买者所提供的最少信息是所要求的优惠购物券的类型、优惠购物券的量、以及用于支付的信用/借记卡的详细资料。可能需要其它的信息,要由顾客选择提供,以便提供额外的顾客服务和/或营销信息。之后的请求路径与图5中的相同,因此哪些步骤被赋予相同的标引号,而不再加以描述。如在前一个图中那样,银行间通信系统可被用作一个安全路径。还是如前面的图中的那样,通信接口返回一个适当的消息,但是在此例中该消息被返回到零售商的ISP。在返回步骤S13中,零售商的ISP将优惠购物券购买请求的结果通知购买者ISP,在请求成功的情况下,将优惠购物券号码与其价值以及到期日期一起给到购买者。
附图6返回到处理优惠购物券的兑换的零售商A的有人值守终端7的情景。将会看到,该图中的数据的流与图4和5的非常相似。
于是在步骤S21,顾客向售货员出示优惠购物券号码,优惠购物券价值和优惠购物券到期日期。顾客并不是非要提供如图4中步骤S10中那样打印的实际优惠购物券。也要明白,到期日期的提供只是一个对于本发明构思来说不是不可或缺的额外的安全特征。优惠购物券可以用作对商品的部分付款,其余部分由现金、支票/借记卡支付;也可以用作对所购买商品的全额付款。实际上有可能这样安排系统,使得优惠购物券价值大于所需商品价值时,给购买者一个代表它们的差额的新优惠购物券。当然,如果兑换优惠购物券的特定商店并非也是优惠购物券的销售者时,这可能是不可能的。这个特征在任何其它优惠购物券方案中都没有。在步骤S22,售货员(本地控制器)响应该优惠购物券和到期日期而将该购买请求通知零售商系统。零售商助理和层200一般要执行对该请求的确认程序,这是因为,如已经所述的那样,对于优惠购物券的生成来说,它可能含有由优惠购物券发行人或有关零售商设定的对其兑换的约束条件的详细内容。
如果确认是必要的而又经过确认,零售商系统启动一个付款请求,在本实施例中构造一个MTIxxxx购买请求。在步骤S24该请求被发送到层400的通信接口,在步骤S25进行确认。有效的请求导致在步骤S26对主数据库19的优惠购物券表20的更新和在步骤S27对资金分类账的更新。在步骤S28费用信息被传送到费用生成系统,以便能够计算应付给系统运营者的费用。相同的费用考虑适用于对图4所作的说明。最后,在步骤S29,以与前面相同的格式生成响应消息并将其通过通信接口发送到零售商系统。响应消息当然可以是否定性的,如果原始请求是无效的。拒绝消息的例子可能是“无效号码”、“方案对该零售商是无效的”、“错误的价值”、“优惠购物券日期不对”、“优惠购物券已经被兑换”和“传送错误”。该响应在反向步骤S23中被传送到本地控制器,本地控制器将其传送到位于销售POS终端的售货员,售货员在终端上采取适当的行动。
附图7表示图6所示通过因特网执行的过程的对应的兑换过程。于是在步骤S31、S32和S33,兑换者用一个例如要被用于支付通过因特网购买的商品的兑换请求访问零售商ISP。零售商ISP如图4中那样把该请求传送到层400的通信接口。以后的步骤与结合图6所述的一样,因此被赋予相同的标注号,并且不再说明。
由于优惠购物券的购买和兑换涉及到向专用银行账户或从专用银行账户转移资金,现在将说明安排和管理资金的方式。正如已经说明过的那样,每个优惠购物券将属于特定的优惠购物券发行者,这也标识哪个资金账户管理优惠购物券资金。将认识到,一个资金账户能包含不同产品的资金。每个资金有一个“一个影子银行账户”,其在本实施例中与金融机构中保持的一个指定的实际银行帐户相关联。
附图8表示不同零售商和不同产品的资金分类账的总体结构。
在图8中,各个优惠购物券的集合如60、61、62和63所示。每一个优惠购物券有一个值、其唯一性号码、以及产品定义,产品定义被表示为A1、A2、A3和B6。优惠购物券60、61和62已经都被以零售商ABC商店的名义发行,A1等于能兑换白色商品的优惠购物券,A2表示杂货,A3表示在ABC商店的参与分支店的记录。优惠购物券63已经被以XYZ商店的名义发行,也许是作为一种忠诚奖励。
各个产品定义在图8的64、65、66和67处表示,如图中可见,ABC商店有两个独立的资金帐户68和69,一个用于产品A1和A2,另一个用于产品A3,而零售商XYZ则只有一个帐户70。
这些资金账户分别有在银行A的影子帐户71和72以及在银行B的影子帐户73。
本实施例中的核心系统管理7个关于资金的账户。这些账户如下所述:
1)资金银行。每个VIN有一个这样的账户。这个账户体现着保存支持有效优惠购物券的实际资金的实际外部账户(一般是银行账户)。这个帐户的余额被与实际银行账户中的余额对帐。这是一种外部对帐。这代表已经被转移到实际资金银行账户的资金部分。该资金总值是三个资金账户的总和:资金银行、资金销售暂记帐(suspense)和资金兑换暂记帐。
2)资金销售暂记帐。每个VIN也是有这些帐户中的一个账户。账户的余额是等待从功能层500中的实际资金银行账户转帐到银行总帐户中的数额。转账是通过例如BACS的银行间转账执行的。
3)资金兑换暂记帐。每个VIN也是有这些帐户中的一个账户,并且与资金销售暂记帐类似,只是仅用于兑换。
4)资金废弃(revoked)暂记帐。每个VIN也是有一个账户。账户的余额是等待从系统运营者的银行总账户转帐到VIN所有者的银行总帐户中的数额。转账将通过例如BACS的银行间转账执行。这个账户等同于到期的、无人要求的、被取消的等优惠购物券的资金兑换暂记帐户。
5)零售商销售暂记帐。每个VIN有这些帐户中的一个账户。这个账户的余额是等待从零售商银行账户转帐到系统运营者的功能层500上的银行总帐户的数额,一般代表该日由这个零售商售出的不管什么VIN的所有优惠购物券的价值。转账将通过例如BACS的银行间转账执行。
6)零售商兑换暂记帐。每个零售商VIN也是有一个账户,并且与零售商销售暂记帐账户类似。
7)资金控制。整个系统有一个这样的账户。零售商转账的相反账户。这个帐户的余额是所有资金银行账户的加总(符号相反)。
使用该系统的成员的、系统运营者的和实际银行的各种账户的实际结构,在具有适当功能层的图16中表示。以被零售商ABC售出的一个优惠购物券(90)为例。在步骤A,核心系统的暂记帐帐户在该优惠购物券被售出时被更新。此时资金没有被实际地转账。步骤B表示与零售商销售有关的日末转账。每个零售商销售暂记帐帐户的余额被转移到总的资金控制账户。将该数额从零售商银行向系统运营者银行账户转移的指令,是通过银行间清算系统给出的。最后,步骤C表示与优惠购物券的兑换有关的日末转账。每个资金销售暂记帐帐户的余额被转移到资金银行账户。将该数额从系统运营者银行账户向资金银行账户转移的指令,是通过银行间清算系统给出的。
后面的四个例子解释与优惠购物券相关联的实际现金如何能在刚刚说明的银行系统中运动。
这四个例子在图9、10、11和12中表示。在图9的表中,某顾客从在老埃德银行(Lloyds)有帐户的ABC Books购买5个10英镑优惠购物券,作为礼物送给其侄子。该购书代价券方案(book tokenscheme)是VIN34,是由Big Books经营的。持有这个VIN的资金的银行账户被以Big Books的名义保持在巴克莱银行,但是只有系统运营者才有权转入转出资金。系统运营者在RBS有一个总账户,是使用过的客户借贷。在这个50英镑例子中,零售商以销售代价券为开始,最终,40英镑在接受用优惠购物券代替现金的零售商的银行账户中,10英镑在资金银行账户中。在发行和兑换之间的期间内,整个50英镑驻留在资金银行账户中。这是通用优惠购物券的一个例子。
图10的例子是关于个体零售商的优惠购物券的。ABC商店运行它们的商店的一种优惠购物券方案,使得优惠购物券只能在实际的商店或通过因特网从ABC商店购买和兑换。某顾客从ABC商店购买5个10英镑优惠购物券,作为礼物送给其侄子,后者用40英镑从ABC商店购买商品,ABC商店持有它们自己的优惠购物券资金,但该资金在核心系统控制下的一个单独帐户中。
第三个例子如表11所示,是ABC商店运行的守法方案的例子。该方案用优惠购物券奖励顾客,优惠购物券能实际地或通过因特网在ABC商店自己的商店兑换。在特定发行日期的总分配是500英镑。某顾客用40英镑的优惠购物券购买商品。ABC商店持有在系统运营者控制下的一个单独银行帐户,内含支持所发行优惠购物券价值的资金。
图12的例子是如果某优惠购物券到期日之前没有被兑换时发生的情况。
说明过中央处理器1的处理系统实时功能的总体功能和结构后,现在将说明该系统在银行间通信系统上的应用,因为这是很可能的情形。因此在实施例中,优惠购物券购买总是由在接口2接收的MTIxxxx请求消息触发。响应这个消息,中央处理器1总是生成一个返回到该消息源的MTIxxxx响应消息。在正常情况下,该响应消息将含有优惠购物券号码,但是如果在处理过程中遇到错误,则该响应将是对购买请求的拒绝。
于是,响应优惠购物券购买请求,中央处理器1有以下功能。处于安全考虑,强调在处理器1中所有活动都必须通过接口2和17。
该过程显示在图12的流程图中。
在步骤S100,一个MTIxxxx优惠购物券购买请求消息被发送到中央处理器1,在步骤S100,该消息在部件16的接口2上被接收,在步骤S120被送去进行确认,在步骤S103被送去进行错误处理。如果后两个步骤发现该购买请求无效,则将一个表示这个意思的MTIxxxx发送回银行间通信系统11,也发送到如50处所指示的数据库MTIxxxx的审计部件。如果购买请求在步骤S101和S102被确认,购买请求就被传送到步骤S104。在流程图中的此处执行若干连接的过程,注意到购买(以及优惠购物券的兑换)总是实时地发生的,以使购买和兑换的耽搁最小化。因此在步骤S105以已经说明过的方式生成优惠购物券号码,在步骤S106将新生成的优惠购物券转移到优惠购物券表20的适当的有效优惠购物券区中,有效优惠购物券区已经结合图2中的主数据库表作过说明,在图13中在51和52处指示。类似地,优惠购物券的成功生成在步骤S108被审计处理,这个处理的结果再次被存储在主数据库的审计表中,这在50处指示。优惠购物券的成功生成的另一个后果在步骤109显示,这是一个费用处理步骤,它需要来自主数据库中的费用结构表53的数据,更新主数据库中的费用交易表54。此外,在步骤S110,中央处理器1执行资金处理,因为优惠购物券的生成要求在主数据库的资金账户交易表中建立相当的资金,也要求在主数据库的成员表中设置相应的数据,这些表分别在55和56处指示。
最后,在步骤S111,将含有优惠购物券和产品细节的优惠购物券响应发送到银行间通信系统11。
附图13是优惠购物券被兑换时在中央处理器1中执行的处理的流程图。如稍后将要说明的那样,管理费用处理实际上将在交易已经登记后在批处理中执行。
正如可能预期的那样,将看到该流程图与图12的流程图非常类似。因此对优惠购物券兑换中所涉及的步骤和数据表赋予相同的标注号。然而,在步骤S101收到的是一个兑换请求,步骤S104涉及的是兑换过程,步骤S105不是涉及优惠购物券号码生成,而是涉及优惠购物券号码确认。
此外,处理优惠购物券以便能兑换其值的步骤S106,导致在主数据库的历史数据表中登记一个给出优惠购物券信息的登记项。
一个重要特征是支持有效优惠购物券的资金余额总是等于有效优惠购物券所代表的总额。
因此刚刚说明过的系统具有一个完整性检验和对帐过程,能在预定的时间自动被触发,或者能在任何时候被人工地请求。对帐过程涉及到检查与某资金相关联的有效优惠购物券的总值与该资金分类账中的余额一致。
这些过程被表示在图14的流程图中。在步骤S50,过程被用户或定时器启动;在步骤S51,利用主数据库19的资金账户和资金账户交易表22和23中的数据执行对资金余额的对帐。在步骤S52中,利用存储在主数据库的有效优惠购物券表20中的有效优惠购物券的详细数据,执行优惠购物券余额对帐。最后,在步骤S53,发送一个用户警报或报告。
图16表示在功能层100和200的零售世界、功能层400的核心系统和功能层500中所示的实际银行账户之间的关系。假设在90某现金优惠购物券被零售商ABC售出。该销售的结果是,主数据库19的表22和23在生成一个编码号码并在优惠购物券表20中生成一个相应的表目的同时被更新。很明显,此时不需要资金的实际转移。因此在步骤A,在该优惠购物券被售出的时候更新核心系统的暂记帐账户。不对资金作实际的转移。步骤B表示日末的转账-零售商销售。每个零售商的销售暂记帐账户的余额被转移到总的资金控制账户中。将该数额从零售商的银行账户向系统运营者银行账户转移的指令,是通过银行间清算系统给出的。步骤C表示日末的转账-资金销售。每个资金销售暂记帐帐户的余额被转移到资金银行账户。将该数额从系统运营者银行账户向资金的银行账户转移的指令,是通过银行间清算系统给出的。
交易是如何被过账到各种资金的,在图17的表中表示。转移的方向是由余额转移的符号决定的,-VE的意思是资金向系统运营者的总帐户的转移,或者是从零售商或从VIN账户转出的;+VE的意思是从系统运营者的总帐户转出,转入到零售商或VIN账户。
说明了总体系统及其运行方式后,有些根本特点现在将很明显。
特别地,当某购买者利用已经描述过的过程之一获得现金优惠购物券时,该购买者所提供的资金将被转移到系统的资金账户中,但是只是以代表优惠购物券的兑换值的余额的形式被转入。优惠购物券不被个别地列举,资金账户中将只保持一个数额,该数据就是由它们的产品表与该特定资金相关联的所有有效(未兑换的)优惠购物券的兑换值的总数。
类似地,每个优惠购物券完全独立于其购买者而存在,因此可以随时转让给另一个人。特别地,可以非常简单地将优惠购物券通过因特网或者通过电话口头地进行转让,因为接收者不需要以任何方式连接到总体系统。
刚刚说明过的系统的另一个特点是,只要对已有的位于零售商处的或者用于因特网交易的普通终端做出最小的改动,就能执行优惠购物券的购买和兑换。此外,在因特网上出示要求兑换的优惠购物券的人,不需要提供信用卡/借记卡的详细内容就能购买商品。
除了操作简单和使用已有的诸如银行间通信系统等设施的这些特定优点,前面特别描述过的系统在要执行的处理的量上以及在对为数据存储分配相当大的存储器的需要方面,具有非常显著的技术优点。相信所描述的系统能应用于要进行资金转移的许多领域,如果成功的话,则系统要处理的交易的数量将极大。因此,不把优惠购物券分配给个人以及不为反映个别优惠购物券而细分支持有效优惠购物券的资金的特点,减少了要执行的处理量以及对存储空间的使用。
以上所述的系统具有高度的安全性,因为现金优惠购物券只有在资金已经随请求落实时才能使用。因此,除非资金已经被转到系统的运营者,否则优惠购物券是不能兑换的。此外,编码的优惠购物券号码内含有作为对产品的定义约束条件的方式,意味着含有无人兑换的优惠购物券的表将间接地代表一个精确定义的现金值,该现金值将反映在图2的资金分类账表22中,并在一个实际的银行账户中有一个对应的现金余额。因此,任何在优惠购物券表20中增加或减少有效优惠购物券的变化,必定反映在资金分类账表22和实际银行账户中。