一种电子凭证的发放方法及装置
技术领域
本申请涉及互联网技术领域,尤其涉及一种电子凭证的发放方法及装置。
背景技术
随着互联网的普及,电子凭证逐渐取代纸质凭证,成为一种新型的身份核实手段。在互联网上通过发放端(如智能设备、电子凭证发放服务器)发放电子凭证的单位或者个人(发放者),可以在线上或线下根据领取到发放的电子凭证的单位或个人(用户)通过用户端(如智能终端)所出示的电子凭证,核实该用户端的身份,并根据电子凭证上标明的使用规则为该用户端对应的用户提供服务。
现有的电子凭证的发放方法是,发放者将电子凭证的使用规则输入到发放端器,由发放端根据接收到的使用规则生成标明该使用规则的电子凭证,并将电子凭证发放给用户端。
在互联网上发放电子凭证的发放者有很多,如电商、线下经销商、旅游景点、博物馆、公益机构、画展举办人等。但是,各发放者通过各自的发放端发放电子凭证的行为是彼此独立的,某个电子凭证上标明的使用规则仅是发放该电子凭证的发放者提供的服务所根据的规则,倘若领取到该电子凭证的用户并不需要该电子凭证的发放者提供的服务,那么该电子凭证就被浪费掉了。实际上,基于统计经验,最终被用户使用的电子凭证的数量在发放出的电子凭证的总数量中所占的比重是较低的。正是因为如此,发放者为了提升被用户使用的电子凭证的数量,往往不惜通过发放端发放海量的电子凭证,但这会给发放端造成很大的压力。
因此,如何设计一种电子凭证的发放方法,以有效减轻电子凭证的发放端的压力,成为本领域丞待解决的技术问题。
发明内容
本申请实施例的目的是提供一种电子凭证的发放方法及装置,以减轻电子凭证的发放端的压力。
为解决上述技术问题,本申请实施例是这样实现的:
本申请实施例提供的一种电子凭证的发放方法,预设与至少两个发放端相关联的电子凭证信息,所述方法包括:
接收第一发放端发送的电子凭证信息调用请求;
根据所述电子凭证信息调用请求,将所述电子凭证信息发送给所述第一发放端,以使所述第一发放端根据所述电子凭证信息生成与所述第一发放端和至少一个第二发放端相关联的电子凭证,并将所述电子凭证发放给用户端。
本申请实施例提供的一种电子凭证的发放方法,在联合控制服务器上预设与至少两个发放端相关联的电子凭证信息,所述方法包括:
第一发放端接收用户端发送的电子凭证领取请求;
根据所述电子凭证领取请求,向联合控制服务器发送电子凭证信息调用请求;
接收联合控制服务器返回的电子凭证信息;
根据所述电子凭证信息生成与所述第一发放端和至少一个第二发放端相关联的电子凭证;
将所述电子凭证发放给所述用户端。
本申请实施例提供的一种电子凭证的验证方法,预设与至少两个发放端相关联的电子凭证信息,所述方法包括:
接收发放端发送的电子凭证,所述电子凭证是预先根据所述电子凭证信息生成的,所述电子凭证与所述至少两个发放端相关联;
判断所述发放端是否与所述电子凭证相关联;
若是,根据所述电子凭证信息,对所述电子凭证进行验证;
否则,验证不通过。
本申请实施例提供的一种电子券的发放方法,预设与至少两个商家终端相关联的电子券信息,所述方法包括:
接收第一商家终端发送的电子券信息调用请求;
根据所述电子券信息调用请求,将所述电子券信息发送给所述第一商家终端,以使所述第一商家终端根据所述电子券信息生成与所述第一商家终端和至少一个第二商家终端相关联的电子券,并将所述电子券发放给用户端。
本申请实施例提供的一种电子券的发放方法,包括:在联合控制服务器上预设与至少两个商家终端相关联的电子券信息,所述方法包括:
第一商家终端接收用户端发送的电子券领取请求;
根据所述电子券领取请求,向联合控制服务器发送电子券信息调用请求;
接收联合控制服务器返回的电子券信息;
根据所述电子券信息生成与所述第一商家终端和至少一个第二商家终端相关联的电子券;
将所述电子券发放给所述用户端。
本申请实施例提供的一种电子券的验证方法,预设与至少两个商家终端相关联的电子券信息,所述方法包括:
接收商家终端发送的电子券,所述电子券是预先根据所述电子券信息生成的,所述电子券与所述至少两个商家终端相关联;
判断所述商家终端是否与所述电子券相关联;
若是,根据所述电子券信息,对所述电子券进行验证;
否则,验证不通过。
本申请实施例提供的一种电子凭证的发放装置,预设与至少两个发放端相关联的电子凭证信息,所述装置包括:
接收模块,接收第一发放端发送的电子凭证信息调用请求;
发送模块,根据所述电子凭证信息调用请求,将所述电子凭证信息发送给所述第一发放端,以使所述第一发放端根据所述电子凭证信息生成与所述第一发放端和至少一个第二发放端相关联的电子凭证,并将所述电子凭证发放给用户端。
本申请实施例提供的一种电子凭证的发放装置,在联合控制服务器上预设与至少两个发放端相关联的电子凭证信息,所述装置包括:
第一接收模块,第一发放端接收用户端发送的电子凭证领取请求;
第一发送模块,根据所述电子凭证领取请求,向联合控制服务器发送电子凭证信息调用请求;
第二接收模块,接收联合控制服务器返回的电子凭证信息;
电子凭证生成模块,根据所述电子凭证信息生成与所述第一发放端和至少一个第二发放端相关联的电子凭证;
第二发送模块,将所述电子凭证发放给所述用户端。
本申请实施例提供的一种电子凭证的验证装置,预设与至少两个发放端相关联的电子凭证信息,所述装置包括:
接收模块,接收发放端发送的电子凭证,所述电子凭证是预先根据所述电子凭证信息生成的,所述电子凭证与所述至少两个发放端相关联;
验证模块,判断所述发放端是否与所述电子凭证相关联;若是,根据所述电子凭证信息,对所述电子凭证进行验证;否则,验证不通过。
本申请实施例提供的一种电子券的发放装置,预设与至少两个商家终端相关联的电子券信息,所述装置包括:
接收模块,接收第一商家终端发送的电子券信息调用请求;
发送模块,根据所述电子券信息调用请求,将所述电子券信息发送给所述第一商家终端,以使所述第一商家终端根据所述电子券信息生成与所述第一商家终端和至少一个第二商家终端相关联的电子券,并将所述电子券发放给用户端。
本申请实施例提供的一种电子券的发放装置,在联合控制服务器上预设与至少两个商家终端相关联的电子券信息,所述装置包括:
第一接收模块,第一商家终端接收用户端发送的电子券领取请求;
第一发送模块,根据所述电子券领取请求,向联合控制服务器发送电子券信息调用请求;
第二接收模块,接收联合控制服务器返回的电子券信息;
电子券生成模块,根据所述电子券信息生成与所述第一商家终端和至少一个第二商家终端相关联的电子券;
第二发送模块,将所述电子券发放给所述用户端。
本申请实施例提供的一种电子券的验证装置,预设与至少两个商家终端相关联的电子券信息,所述装置包括:
接收模块,接收商家终端发送的电子券,所述电子券是预先根据所述电子券信息生成的,所述电子券与所述至少两个商家终端相关联;
验证模块,判断所述商家终端是否与所述电子券相关联;若是,根据所述电子券信息,对所述电子券进行验证;否则,验证不通过。
由以上本申请实施例提供的技术方案可见,本申请实施例通过使电子凭证信息与至少两个发放端相关联,并且使第一发放端根据所述电子凭证信息生成的电子凭证与至少一个第二发放端相关联,从而使得领取到该电子凭证的用户可以要求与该电子凭证相关联的各发放端对应的发放者根据该电子券为其提供服务。这样以来,采用本技术方案可以扩宽电子凭证的适用范围,提高被使用的电子凭证的数量在发放端所发放的电子凭证的数量中所占的比重,发放者不必再发送过多的电子凭证,有效缓解了发放端的压力。
附图说明
为了更清楚地说明本申请实施例或现有技术中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本申请中记载的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动性的前提下,还可以根据这些附图获得其他的附图。
图1是本申请实施例提供的现有的电子凭证的发放方法的示意图;
图2是本申请实施例提供的本申请所要求保护的技术方案的示意图;
图3是本申请实施例提供的发放端、用户端、联合控制服务器的交互示意图;
图4a~4b是本申请实施例提供的一种电子凭证的示意图;
图5是本申请实施例提供的一种电子凭证的发放方法的流程图;
图6是本申请实施例提供的电子凭证信息示意图;
图7是本申请实施例提供的一种电子凭证的发放方法的流程图;
图8是本申请实施例提供的一种电子凭证的验证方法的流程图;
图9是本申请实施例提供的一种电子券的发放方法及验证方法的总流程示意图;
图10a~10c是本申请实施例提供的一种电子券的示意图;
图10d是本申请实施例提供的,在联合营销场景下,预设电子券信息的示意图;
图10e是本申请实施例提供的,在联合营销场景下的联合营销电子券系统示意图;
图11是本申请实施例提供的一种电子凭证的发放装置示意图;
图12是本申请实施例提供的一种电子凭证的发放装置示意图;
图13是本申请实施例提供的一种电子凭证的验证装置示意图;
图14是本申请实施例提供的一种电子券的发放装置示意图;
图15是本申请实施例提供的一种电子券的发放装置示意图;
图16是本申请实施例提供的一种电子券的验证装置示意图。
具体实施方式
本申请实施例提供一种电子凭证的发放方法及装置。
为了使本技术领域的人员更好地理解本申请中的技术方案,下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本申请一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例,都应当属于本申请保护的范围。
在本申请实施例中,电子凭证可以是这样一种电子数据,即领取了该电子数据的单位或个人可以要求任何承认该电子数据效力的单位或个人,根据该电子数据的内容或该电子数据所对应的内容为其提供服务。并且,该电子数据可以是经过加密的,也可以是未经过加密的。总之,凡是满足上述描述的电子数据,如电子票、电子证明、电子二维码、电子券等,都可以本申请所述的电子凭证,本申请对此不做限制。
在本申请实施例中,所述用户可以是领取电子凭证的单位和个人,所述用户端可以是所述用户使用的智能终端,如电脑、手机等。所述发放端可以是发放电子凭证的单位或个人(发放者)使用的智能设备,也可以是代理各发放者统一发放电子凭证的电子凭证发放服务器。所述发放端的作用可以是生成电子凭证并发放给用户端。
图1是现有的电子凭证的发放方法的示意图。如图1所示,现有的电子凭证的发放方法会对发放端造成较大的压力,是由以下原因导致的:用户领取到的电子凭证只会被发放该电子凭证的发放者所承认,在此前提下,由于电子凭证适用范围过窄,最终被使用的电子凭证的数量在发放端所发放的电子凭证的数量中所占的比重较低,而面对这一情况,发放者往往会不惜通过发放端发放海量的电子凭证,用“量”去弥补“质”的不足。
而本申请所要求保护的技术方案,通过预设与至少两个发放端相关联的电子凭证信息(所述电子凭证信息是用于生成电子凭证的信息,可以包括电子凭证的排版信息、通用规则等)使得所述至少两个发放端中的任一发放端根据电子凭证信息发放的电子凭证都与所述至少两个发放端相关联,从而扩宽了电子凭证的适用范围,也就提高了最终被使用的电子凭证的数量在发放端所发放的电子凭证的数量中所占的比重,发放者不必要再通过发放端发放海量的电子凭证,发放端的压力也得以减轻,如图2所示。
所述电子凭证信息可以由联合控制服务器的管理方预先设置在联合控制服务器上,也可以是由联合控制服务器依据联合控制服务器的管理方设计的规则预先设置的。所述联合控制服务器的作用可以是执行电子凭证信息的发送和对电子凭证进行验证。
此外,预设所述电子凭证信息与至少两个发放端的关联关系的方式,可以是在联合控制服务器上存储有所述电子凭证信息与至少两个发放端的发放端标识的对应关系。实际上,对服务器而言,识别和区分发放端、用户端、电子凭证的方式,都可以是依据发放端的发放端标识、用户端的用户标识、电子凭证的凭证标识。为了描述的方便,下文中对于发放端标识、用户标识、凭证标识不做提及,但这并不说明在技术上服务器不是依据各种标识对不同的主体进行识别和区分的。
图3是本申请实施例提供的发放端、用户端、联合控制服务器的交互示意图。
在本申请实施例的一种应用场景下,发放端线上发放电子凭证,用户端线上领取电子凭证,领取到电子凭证的用户在线下向发放者出示用户端领取到的电子凭证,所述发放端可以具体是发放者管理的,与联合控制服务器进行网络交互的智能设备。例如,在电子票发放的应用场景下,剧场方控制智能设备发放电子票,领取到电子票的观众在线下凭电子票入场。
在本申请实施例的另一种应用场景下,发放端线上发放电子凭证,用户端线上领取电子凭证,领取到电子凭证的用户通过用户端在线上与发放端进行交互,完成电子凭证的验证,所述发放端可以具体是联合控制服务器的管理方一并管理的,与联合控制服务器交互的电子凭证发放服务器。例如,在电子商务场景下,需要发放电子凭证的商家可以授权电商平台管理方通过电子凭证发放服务器代理发放各商家所要发放的电子凭证,由电子凭证发放服务器与联合控制服务器进行交互。
本申请实施例中的电子凭证是在各发放者处通用的电子凭证,所述电子凭证可以显示有所述电子凭证信息;也可以通过数据加密形式或其他数据封装形式封装有所述电子凭证信息,待需要对电子凭证进行验证时,由发放端自电子凭证中读取出电子凭证信息;也可以显示部分电子凭证信息,封装剩余的电子凭证信息。此外,对于封装的电子凭证信息,领取到电子凭证的用户可以在用户端上触发电子凭证上的特定按钮,查看封装的电子凭证信息,例如,图4a~4b。图4a是本申请实施例提供的一种电子凭证的示意图。如图4a所示,用户触发电子凭证上的“详情”按钮,可以查看如图4b所示的部分封装的电子凭证信息。
在本申请实施例中,电子凭证信息可以包括电子凭证通用规则,如使用期限、使用方式、例外情况等;也可以包括电子凭证关联的至少两个发放端分别对应的各电子凭证特殊规则,即仅适用于某个发放端对应的发放者处的服务信息,如观影座次、参加画展、进入博物馆中的任一种,还可以既包括电子凭证的通用规则,也包括所述各电子凭证特殊规则。
各电子凭证特殊规则可以作为封装的电子凭证信息,经用户触发特定按钮而显示,如图4b。
以下结合附图,详细说明本申请各实施例提供的技术方案。
图5是本申请实施例提供的一种电子凭证的发放方法的流程图,包括以下步骤:
S501:接收第一发放端发送的电子凭证信息调用请求。
本方法的执行主体是联合控制服务器。所述联合控制服务器可以是单个服务器,也可以是分布式服务器群,本申请对此不做限制。
在本申请实施例中,发放电子凭证的发放端是第一发放端,第一发放端向请求领取电子凭证的用户端发放电子凭证之前,需要向联合控制服务器发送电子凭证信息调用请求,以获取关联有至少两个发放端的电子凭证信息。所述电子凭证信息调用请求可以是不携带有内容的指令,用于触发联合控制服务器执行后续步骤;也可以是携带有用户端的用户标识的指令。
在本申请实施例中,第一发放端可以响应于用户端的电子凭证领取请求,向联合控制服务器发送电子凭证信息调用请求,也可以根据特定规则,如特定间隔时间、特定触发条件等,向联合控制服务器发送电子凭证信息调用请求。
当第一发放端响应于用户端的电子凭证领取请求,向联合控制服务器发送电子凭证信息调用请求时,所述电子凭证领取请求可以携带有用户端的用户标识。当所述电子凭证领取请求携带有用户端的用户标识时,所述电子凭证信息调用请求也携带有所述用户端的用户标识。
在本申请实施例中,想要领取电子凭证的用于通过用户端可以向第一发放端发送电子凭证领取请求,随后第一发放端根据电子凭证领取请求,向联合控制服务器发送电子凭证信息调用请求,最后,联合控制服务器接收到电子凭证信息调用请求。
例如,在电子票的应用场景下,想要观看演出的观众通过手机登陆剧场的电子票发放界面,向剧场的发放端发送携带有该观众的用户标识的电子凭证领取请求,随后剧场的发放端根据接收到的电子凭证领取请求,向联合控制服务器发送携带有该观众的用户标识的电子凭证信息调用请求。
S502:根据所述电子凭证信息调用请求,将所述电子凭证信息发送给所述第一发放端。
在本申请实施例中,联合控制服务器将所述电子凭证信息发送给所述第一发放端之后,所述第一发放端根据所述电子凭证信息生成与所述第一发放端和至少一个第二发放端相关联的电子凭证,并将所述电子凭证发放给用户端。
其中,所述第二发放端区别于所述第一发放端,可以是在与所述电子凭证信息关联的各发放端中,除所述第一发放端外的其他发放端。虽然该电子凭证不是所述第二发放端发放的,但是该电子凭证同样适用于所述第二发放端。待领取到该电子凭证的用户向所述第二发放端对应的发放者出示该电子凭证时,所述第二发放端可以接收领取到该电子凭证的用户的用户端发送的电子凭证,与联合控制服务器进行交互,使联合控制服务器对该电子凭证进行验证,以方便第二发放端对应的发放者根据返回的验证结果提供服务。
此外,在实际应用场景下,有必要对同一用户领取电子凭证的数量进行限制,防止同一用户领取不止一张电子凭证,造成电子凭证的浪费,加大发放端的压力。
在本申请实施例中,当所述电子凭证领取请求和所述电子凭证信息调用请求都携带有用户端的用户标识时,在联合控制服务器将所述电子凭证信息发送给所述第一发放端之前,可以确定所述用户端的用户标识不在历史记录中;在联合控制服务器将所述电子凭证信息发送给所述第一发放端之后,可以将所述用户端的用户标识记录在所述历史记录中。
具体而言,所述历史记录可以是由联合控制服务器记录的,历史上领取过电子凭证的用户端的用户标识的记录。联合控制服务器确定所述用户端的用户标识不在历史记录中,说明该用户端在历史上没有领取过电子凭证,可以将所述电子凭证信息发送给所述第一发放端,以使所述第一发放端生成电子凭证并发放给该用户端。随后,联合控制服务器将该用户端的用户标识记录在所述历史记录中,防止该用户端再次领取电子凭证。
进一步地,在实际的应用场景下,由于关联所述电子凭证信息的各发放端对应的发放者所提供的服务千差万别,即使是同一类服务,具体的服务信息也往往并不一致。因此,本方法还支持各发放者预先设置仅适用于自身的服务信息。
具体而言,所述电子凭证信息可以是电子凭证通用规则,所述电子凭证通用规则可以是由联合控制服务器的管理方设置的电子凭证的使用规则,也可以是各发放者达成共识的电子凭证的使用规则。例如,时间期限、有效次数、例外条款等就可以是电子凭证的通用规则。
除此之外,所述电子凭证信息还可以是与所述至少两个发放端分别对应的各电子凭证特殊规则,所述电子凭证特殊规则可以是各发放者预先设置仅适用于自身的服务信息。例如,免费入场、前排座位、不同的优惠方式等。
图6是本申请实施例提供的电子凭证信息示意图。如图6所示,电子凭证通用规则为“2016年5月1日至2017年5月1日有效,法定节假日例外”,各电子凭证特殊规则为“发放端A:免费入场;发放端B:九折优惠;发放端C:贵宾席”。
通过图5所示的方法,可以使得领取到该电子凭证的用户可以要求与该电子凭证相关联的各发放端对应的发放者根据该电子券为其提供服务。这样以来,采用本技术方案可以扩宽电子凭证的适用范围,提高被使用的电子凭证的数量在发放端所发放的电子凭证的数量中所占的比重,发放者不必再发送过多的电子凭证,有效缓解了发放端的压力。
图7是本申请实施例提供的一种电子凭证的发放方法的流程图,包括以下步骤:
S701:第一发放端接收用户端发送的电子凭证领取请求。
S702:根据所述电子凭证领取请求,向联合控制服务器发送电子凭证信息调用请求。
S703:接收联合控制服务器返回的电子凭证信息。
S704:根据所述电子凭证信息生成与所述第一发放端和至少一个第二发放端相关联的电子凭证。
S705:将所述电子凭证发放给所述用户端。
本方法的执行主体是第一发放端,图7所示方法为图5所示方法在第一发放端一侧执行的流程,与图5所示方法属于同一个实施例,不再赘述。
图8是本申请实施例提供的一种电子凭证的验证方法的流程图,包括以下步骤:
S801:接收发放端发送的电子凭证。
本方法的执行主体是联合控制服务器。
S802:判断所述发放端是否与所述电子凭证相关联,若是,则执行步骤S803,否则,执行步骤S804。
在实际应用场景下,用户领取电子凭证后,到与电子凭证关联的任一发放端对应的发放者处要求服务时,需要先确定该电子凭证是与该发放者关联的,然后才能对电子凭证的电子凭证信息进行验证。若用户出示的电子凭证并不是与该发放者关联的,则该发放者无须提供服务。
在本申请实施例中,联合控制服务器可以判断所述电子凭证的凭证标识的数据形式是否符合预设规则,若是,则确定所述电子凭证与所述发放端相关联。
例如,倘若所述与所述电子凭证信息关联的各发放端生成的电子凭证的标识的数据形式可以是特定位数的二进制数或特定规则的编码。
也可以在接收发放端发送的电子凭证后,确定与所述电子凭证相关联的各发放端标识和发送所述电子凭证的发放端的发放端标识;判断发送所述电子凭证的发放端的发放端标识是否在与所述电子凭证相关联的各发放端标识中;若是,则确定发送所述电子凭证的发放端与所述电子凭证相关联;否则,确定发送所述电子凭证的发放端与所述电子凭证不相关联。
进一步地,确定与所述电子凭证相关联的各发放端标识的方式可以是,确定所述电子凭证的凭证标识;根据所述凭证标识,确定与所述凭证标识相关联的各发放端标识。
S803:根据所述电子凭证信息,对所述电子凭证进行验证。
S804:验证不通过。
在本申请实施例中,当所述电子凭证信息是电子凭证通用规则是,在确定所述发放端与所述电子凭证相关联之后,可以根据所述电子凭证通用规则,对所述电子凭证进行验证。
例如,倘若电子凭证通用规则具体是“法定节假日不能使用”,则联合控制服务器查阅日历,若当天不是法定节假日,则验证通过,若当天是法定节假日,则验证不通过。当发放端接收到内容是通过的验证结果是时,发放者才会提供服务。
进一步地,当所述电子凭证信息还包括与所述至少两个发放端分别对应的各电子凭证特殊规则时,联合控制服务器还可以确定所述发放端对应的电子凭证特殊规则;根据确定出的电子凭证特殊规则,确定所述发放端对应的服务信息;将所述服务信息返回给所述发放端。
例如,倘若该发放端对应的电子凭证特殊规则“黄金观影区”,则联合控制服务器查阅该发放端对应的发放者预先提供的座位表,将处于黄金观影区中的空位的编号作为服务信息,返回给该发放端,用户根据返回的空位的编号入座。
此外,作为本申请实施例的技术方案适用的一种应用场景,电子凭证可以是电子券。所述电子券是商家发放给用户的具有优惠权限的券。用户持有电子券到商家处(线上线下均可),可以凭电子券享受相应的优惠。
图9是本申请实施例提供的一种电子券的发放方法及验证方法的流程示意图,包括以下步骤:
S901:第一商家终端接收用户端发送的电子券领取请求。
S902:第一商家终端根据所述电子券领取请求,向联合控制服务器发送电子券信息调用请求。
S903:联合控制服务器根据接收到的电子券信息调用请求,将所述电子券信息发送给所述第一商家终端。
S904:第一商家终端根据所述电子券信息生成与所述第一商家终端和至少一个第二商家终端相关联的电子券。
S905:第一商家终端将所述电子券发放给所述用户端。
S906:第二商家终端接收用户端发送的电子券,并将所述电子券发送给联合控制服务器。
S907:联合控制服务器接收第二商家终端发送的电子券。
S908:联合控制服务器验证接收到的电子券。
S909:向第二商家终端返回验证结果。
所述电子券信息可以是电子券通用规则,如有效期限、有效次数、例外规则等;也可以是与至少两个商家终端分别对应的各电子券特殊规则。
在本申请实施例中,当第二商家终端对应的电子券特殊规则为第二商家终端的优惠规则时,联合控制服务器可以接收所述商家终端发送的应付金额,以及确定所述商家终端对应的电子券特殊规则;根据确定出的电子券特殊规则,确定所述商家终端对应的优惠规则;根据所述应付金额和确定出的优惠规则,确定用户端的实付金额;将确定出的实付金额返回到所述商家终端。
图10a是本申请实施例提供的电子券的示意图。如图10a所示,超市A的发放端A与加油站B的发放端B都关联有电子券信息,超市A向用户X发放电子券Y,电子券Y上标明有电子券的通用规则“三天内有效”,在电子券的右下角有按钮“详情”,用户触发该按钮,可以查看与至少两个商家终端分别对应的各电子券特殊规则,详情中列明了该电子券对应的各发放端的发放者及其特殊规则,其中加油站B对应的特殊规则是“10元代金券”,见图10b。待用户X到加油站B进行消费时,加油站B的发放端B将该电子券Y和用户X的应付金额250元发送给联合控制服务器,联合控制服务器对电子券Y进行验证,确定电子券Y在有效期内,然后返回给发放端B用户X的应付金额240元,见图10c。
值得说明的是,所述电子券适用于与所述电子券关联的各发放端对应的发放者,并且所述电子券既可应用于线上场景,如电商平台上各网店商家的联合营销,也可应用于线下场景,如线上发券的各线下商家的联合营销。
图10d是本申请实施例提供的,在联合营销场景下,预设电子券信息的示意图。
如图10d所示,联合控制服务器的管理方可以发起联合营销活动,各商家可以报名参加该营销活动,共同确认电子券通用规则(如消费后领可领券、活动时间、出资方式、例外条款等)和分别独立配置仅适用于自身的电子券特殊规则(如参与活动的商品、折扣方式、指定门店、指定分销商等)。
图10e是本申请实施例提供的,在联合营销场景下的联合营销电子券系统示意图。
如图10e所示,联合营销系统由活动匹配模块、电子券发放模块、电子券验证模块、电子券核销模块。用户可以通过用户端登陆到联合营销系统中的活动匹配模块,在活动匹配模块下选择参与该活动的商家后,界面跳转进入商家终端的电子券发放模块下,用户在电子券发放模块下领取电子券后,可以进入电子券验证模块进行验证,验证通过后,可以在电子券核销模块下支付价款。
基于图5所示的电子凭证的发放方法,本申请实施例还对应提供一种电子凭证的发放装置,如图11所示,预设与至少两个发放端相关联的电子凭证信息,所述装置包括:
接收模块1101,接收第一发放端发送的电子凭证信息调用请求;
发送模块1102,根据所述电子凭证信息调用请求,将所述电子凭证信息发送给所述第一发放端,以使所述第一发放端根据所述电子凭证信息生成与所述第一发放端和至少一个第二发放端相关联的电子凭证,并将所述电子凭证发放给用户端。
所述电子凭证信息调用请求携带有用户端的用户标识,所述装置还包括:
确定模块1103,在所述发送模块1102将所述电子凭证信息发送给所述第一发放端之前,确定所述用户端的用户标识不在历史记录中;
记录模块1104,在所述发送模块1102将所述电子凭证信息发送给所述第一发放端之后,将所述用户端的用户标识记录在所述历史记录中。
所述电子凭证信息,具体包括:电子凭证通用规则,和/或,与所述至少两个发放端分别对应的各电子凭证特殊规则。
基于图7所示的电子凭证的发放方法,本申请实施例还对应提供一种电子凭证的发放装置,如图12所示,在联合控制服务器上预设与至少两个发放端相关联的电子凭证信息,所述装置包括:
第一接收模块1201,第一发放端接收用户端发送的电子凭证领取请求;
第一发送模块1202,根据所述电子凭证领取请求,向联合控制服务器发送电子凭证信息调用请求;
第二接收模块1203,接收联合控制服务器返回的电子凭证信息;
电子凭证生成模块1204,根据所述电子凭证信息生成与所述第一发放端和至少一个第二发放端相关联的电子凭证;
第二发送模块1205,将所述电子凭证发放给所述用户端。
所述第一发送模块1202,提取所述电子凭证领取请求中携带的所述用户端的用户标识;将提取的所述用户端的用户标识携带在电子凭证信息调用请求中;将携带有所述用户端的用户标识的电子凭证信息调用请求发送给所述联合控制服务器。
所述电子凭证信息,具体包括:电子凭证通用规则,和/或,与所述至少两个发放端分别对应的各电子凭证特殊规则。
基于图8所示的电子凭证的验证方法,本申请实施例还对应提供一种电子凭证的验证装置,如图13所示,预设与至少两个发放端相关联的电子凭证信息,所述装置包括:
接收模块1301,接收发放端发送的电子凭证,所述电子凭证是预先根据所述电子凭证信息生成的,所述电子凭证与所述至少两个发放端相关联;
验证模块1302,判断所述发放端是否与所述电子凭证相关联;若是,根据所述电子凭证信息,对所述电子凭证进行验证;否则,验证不通过。
所述验证模块1302,确定与所述电子凭证相关联的各发放端标识和发送所述电子凭证的发放端的发放端标识;判断发送所述电子凭证的发放端的发放端标识是否在与所述电子凭证相关联的各发放端标识中;若是,则确定发送所述电子凭证的发放端与所述电子凭证相关联;否则,确定发送所述电子凭证的发放端与所述电子凭证不相关联。
所述验证模块1302,确定所述电子凭证的凭证标识;根据所述凭证标识,确定与所述凭证标识相关联的各发放端标识。
所述电子凭证信息具体包括电子凭证通用规则;
所述验证模块1302,根据所述电子凭证通用规则,对所述电子凭证进行验证。
所述电子凭证信息还包括:与所述至少两个发放端分别对应的各电子凭证特殊规则;
所述装置还包括:
服务确定模块1303,当所述验证模块根据所述电子凭证通用规则,对所述电子凭证验证通过时,确定所述发放端对应的电子凭证特殊规则;根据确定出的电子凭证特殊规则,确定所述发放端对应的服务信息;将所述服务信息返回给所述发放端。
基于图9所示的电子券的发放及验证方法,本申请实施例还对应提供了电子券的发放装置和验证装置,如图14~16所示,
一种电子券的发放装置,预设与至少两个商家终端相关联的电子券信息,所述装置包括:
接收模块1401,接收第一商家终端发送的电子券信息调用请求;
发送模块1402,根据所述电子券信息调用请求,将所述电子券信息发送给所述第一商家终端,以使所述第一商家终端根据所述电子券信息生成与所述第一商家终端和至少一个第二商家终端相关联的电子券,并将所述电子券发放给用户端。
所述电子券信息调用请求携带有用户端的用户标识,所述装置还包括:
确定模块1403,在所述发送模块1402将所述电子券信息发送给所述第一商家终端之前,确定所述用户端的用户标识不在历史记录中;
记录模块1404,在所述发送模块1402将所述电子券信息发送给所述第一商家终端之后,将所述用户端的用户标识记录在所述历史记录中。
所述电子券信息,具体包括:电子券通用规则,和/或,与所述至少两个商家终端分别对应的各电子券特殊规则。
一种电子券的发放装置,在联合控制服务器上预设与至少两个商家终端相关联的电子券信息,所述装置包括:
第一接收模块1501,第一商家终端接收用户端发送的电子券领取请求;
第一发送模块1502,根据所述电子券领取请求,向联合控制服务器发送电子券信息调用请求;
第二接收模块1503,接收联合控制服务器返回的电子券信息;
电子券生成模块1504,根据所述电子券信息生成与所述第一商家终端和至少一个第二商家终端相关联的电子券;
第二发送模块1505,将所述电子券发放给所述用户端。
所述第一发送模块1502,提取所述电子券领取请求中携带的所述用户端的用户标识;将提取的所述用户端的用户标识携带在电子券信息调用请求中;将携带有所述用户端的用户标识的电子券信息调用请求发送给所述联合控制服务器。
所述电子券信息,具体包括:电子券通用规则,和/或,与所述至少两个商家终端分别对应的各电子券特殊规则。
一种电子券的验证装置,预设与至少两个商家终端相关联的电子券信息,所述装置包括:
接收模块1601,接收商家终端发送的电子券,所述电子券是预先根据所述电子券信息生成的,所述电子券与所述至少两个商家终端相关联;
验证模块1602,判断所述商家终端是否与所述电子券相关联;若是,根据所述电子券信息,对所述电子券进行验证;否则,验证不通过。
所述验证模块1602,确定与所述电子券相关联的各商家终端标识和发送所述电子券的商家终端的商家终端标识;判断发送所述电子券的商家终端的商家终端标识是否在所述电子券相关联的各商家终端标识中;若是,则确定发送所述电子券的商家终端与所述电子券相关联;否则,确定发送所述电子券的商家终端与所述电子券不相关联。
所述验证模块1602,确定所述电子券的券标识;根据所述券标识,确定与所述券标识相关联的各商家终端标识。
所述电子券信息具体包括电子券通用规则;
所述验证模块1602,根据所述电子券通用规则,确定所述电子券的有效期限、有效次数中的至少一种;根据确定出的所述电子券的有效期限、有效次数中的至少一种对所述电子券进行验证。
所述电子券信息还包括:与所述至少两个商家终端分别对应的各电子券特殊规则;
所述装置还包括:
服务确定模块1603,当所述验证模块根据所述电子券通用规则,对所述电子凭证验证通过时,接收所述商家终端发送的应付金额,以及确定所述商家终端对应的优惠规则;根据所述应付金额和确定出的优惠规则,确定用户端的实付金额;将确定出的实付金额返回到所述商家终端。
最后,需要强调的是,图10e所示的联合营销电子券系统中的活动匹配模块的功能可以由图15中的第一接收模块实现1501;电子券发放模块的功能可以由图15中的第一发送模块1502、第二发放模块1503、电子券生成模块1504、第二发送模块1505共同实现;电子券验证模块的功能可以由图16中的接收模块1601和验证模块1602共同实现;电子券核销模块的功能可以通过对图16所示的装置新增核销模块实现。
在20世纪90年代,对于一个技术的改进可以很明显地区分是硬件上的改进(例如,对二极管、晶体管、开关等电路结构的改进)还是软件上的改进(对于方法流程的改进)。然而,随着技术的发展,当今的很多方法流程的改进已经可以视为硬件电路结构的直接改进。设计人员几乎都通过将改进的方法流程编程到硬件电路中来得到相应的硬件电路结构。因此,不能说一个方法流程的改进就不能用硬件实体模块来实现。例如,可编程逻辑器件(Programmable Logic Device,PLD)(例如现场可编程门阵列(Field Programmable GateArray,FPGA))就是这样一种集成电路,其逻辑功能由用户对器件编程来确定。由设计人员自行编程来把一个数字系统“集成”在一片PLD上,而不需要请芯片制造厂商来设计和制作专用的集成电路芯片。而且,如今,取代手工地制作集成电路芯片,这种编程也多半改用“逻辑编译器(logic compiler)”软件来实现,它与程序开发撰写时所用的软件编译器相类似,而要编译之前的原始代码也得用特定的编程语言来撰写,此称之为硬件描述语言(Hardware Description Language,HDL),而HDL也并非仅有一种,而是有许多种,如ABEL(Advanced Boolean Expression Language)、AHDL(Altera Hardware DescriptionLanguage)、Confluence、CUPL(Cornell University Programming Language)、HDCal、JHDL(Java Hardware Description Language)、Lava、Lola、MyHDL、PALASM、RHDL(RubyHardware Description Language)等,目前最普遍使用的是VHDL(Very-High-SpeedIntegrated Circuit Hardware Description Language)与Verilog。本领域技术人员也应该清楚,只需要将方法流程用上述几种硬件描述语言稍作逻辑编程并编程到集成电路中,就可以很容易得到实现该逻辑方法流程的硬件电路。
控制器可以按任何适当的方式实现,例如,控制器可以采取例如微处理器或处理器以及存储可由该(微)处理器执行的计算机可读程序代码(例如软件或固件)的计算机可读介质、逻辑门、开关、专用集成电路(Application Specific Integrated Circuit,ASIC)、可编程逻辑控制器和嵌入微控制器的形式,控制器的例子包括但不限于以下微控制器:ARC 625D、Atmel AT91SAM、Microchip PIC18F26K20以及Silicone Labs C8051F320,存储器控制器还可以被实现为存储器的控制逻辑的一部分。本领域技术人员也知道,除了以纯计算机可读程序代码方式实现控制器以外,完全可以通过将方法步骤进行逻辑编程来使得控制器以逻辑门、开关、专用集成电路、可编程逻辑控制器和嵌入微控制器等的形式来实现相同功能。因此这种控制器可以被认为是一种硬件部件,而对其内包括的用于实现各种功能的装置也可以视为硬件部件内的结构。或者甚至,可以将用于实现各种功能的装置视为既可以是实现方法的软件模块又可以是硬件部件内的结构。
上述实施例阐明的系统、装置、模块或单元,具体可以由计算机芯片或实体实现,或者由具有某种功能的产品来实现。一种典型的实现设备为计算机。具体的,计算机例如可以为个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任何设备的组合。
为了描述的方便,描述以上装置时以功能分为各种单元分别描述。当然,在实施本申请时可以把各单元的功能在同一个或多个软件和/或硬件中实现。
本领域内的技术人员应明白,本发明的实施例可提供为方法、系统、或计算机程序产品。因此,本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且,本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器,使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中,使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品,该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上,使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理,从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
在一个典型的配置中,计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。
内存可能包括计算机可读介质中的非永久性存储器,随机存取存储器(RAM)和/或非易失性内存等形式,如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括,但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带,磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质,可用于存储可以被计算设备访问的信息。按照本文中的界定,计算机可读介质不包括暂存电脑可读媒体(transitorymedia),如调制的数据信号和载波。
还需要说明的是,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。
本领域技术人员应明白,本申请的实施例可提供为方法、系统或计算机程序产品。因此,本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且,本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本申请可以在由计算机执行的计算机可执行指令的一般上下文中描述,例如程序模块。一般地,程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本申请,在这些分布式计算环境中,由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中,程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。
本说明书中的各个实施例均采用递进的方式描述,各个实施例之间相同相似的部分互相参见即可,每个实施例重点说明的都是与其他实施例的不同之处。尤其,对于系统实施例而言,由于其基本相似于方法实施例,所以描述的比较简单,相关之处参见方法实施例的部分说明即可。
以上所述仅为本申请的实施例而已,并不用于限制本申请。对于本领域技术人员来说,本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等,均应包含在本申请的权利要求范围之内。