CN111369392A - 一种优惠方案展示方法、装置和电子设备 - Google Patents

Abstract

本申请实施例提供一种优惠方案展示方法、装置和电子设备。方法包括：获取用户当前用餐场景的用餐场景描述信息；根据所述用餐场景描述信息确认所述用户在当前用餐场景下的可用优惠方案；获取所述可用优惠方案的叠加使用规则；基于所述叠加使用规则对所述可用优惠方案进行组合，获取所述用户在当前用餐场景下的可用优惠方案组合；根据所述用餐场景描述信息，计算所述可用优惠方案组合的优惠力度；展示所述可用优惠方案组合及其对应的优惠力度。根据本申请一实施例的方法，对优惠力度进行计算并直接向用户展示最终的计算结果，使得用户可以简单直接的进行优惠力度对比，从而大大降低用户选用优惠方案的难度。

Description

一种优惠方案展示方法、装置和电子设备

技术领域

本申请涉及智能终端技术领域，特别涉及一种优惠方案展示方法、装置和电子设备。

背景技术

在日常生活中，在餐馆用餐是一种很普遍的消费应用场景。在用餐场景中，商家为了刺激消费，通常会提供优惠方案，例如，满减方案、指定菜品打折方案、限时打折方案以及发放电子/实物优惠券等等。消费者可以根据自身的实际消费情况选用合适的优惠方案。

然而，随着优惠方案发放力度的增强，优惠方案的种类不断增多，消费者手中可用的优惠方案不断积累，面对众多可用的优惠方案，消费者很难详细区分不同的优惠方案在使用条件、优惠力度等方面所存在的差别。这就导致消费者在消费时很难顺利选用最合适的优惠方案，从而最终导致消费者无法享受到最佳的优惠力度。如此一来，优惠方案不仅没有起到刺激消费的作用，反而会因为选择过程太过繁琐而降低消费者的消费体验。

发明内容

本申请提供了一种优惠方案展示方法、装置和电子设备，本申请还提供一种计算机可读存储介质，以提供一种展示优惠方案方式，以便用户能够简单直观的了解当前可用的优惠方案组合以及对应的优惠力度，从而便于用户在消费时进行优惠方案的选用。

本申请实施例采用下述技术方案：

一种优惠方案展示方法，包括：

获取用户当前用餐场景的用餐场景描述信息；

根据所述用餐场景描述信息确认所述用户在当前用餐场景下的可用优惠方案；

获取所述可用优惠方案的叠加使用规则；

基于所述叠加使用规则对所述可用优惠方案进行组合，获取所述用户在当前用餐场景下的可用优惠方案组合，每个所述可用优惠方案组合包括至少一个所述可用优惠方案；

根据所述用餐场景描述信息，计算所述可用优惠方案组合的优惠力度；

展示所述可用优惠方案组合及其对应的优惠力度。

在本申请一实施例中，根据所述用餐场景描述信息确认所述用户在当前用餐场景下的可用优惠方案，包括：

确认所述用户的可选优惠方案，其中，所述可选优惠方案包括所述用户的已持有优惠方案以及通用优惠方案；

根据所述用餐场景描述信息，从所述可选优惠方案中筛选所述可用优惠方案，其中，所述可用优惠方案包括已满足使用条件的优惠方案。

在本申请一实施例中，确认所述用户的已持有优惠方案，包括：

根据所述用户的账户信息确认所述用户的已持有优惠方案；

和/或，

根据所述用户录入的优惠方案验证信息确认所述用户的已持有优惠方案。

在本申请一实施例中，所述可选优惠方案还包括所述用户在当前用餐场景下的可获取优惠方案，确认所述用户的可获取优惠方案，包括：

获取当前正在进行当中的优惠方案活动；

从所述当前正在进行当中的优惠方案活动中确认所述用户可以参与的优惠方案活动，确认所述可获取优惠方案。

在本申请一实施例中，所述方法还包括：

向所述用户展示优惠方案获取信息，所述优惠方案获取信息用于指导所述用户获取所述可用优惠方案组合中的可获取优惠方案。

在本申请一实施例中，所述可选优惠方案还包括当前用餐场景下其他用户赠送给当前用户的转赠优惠方案，确认所述转赠优惠方案，包括：

向所述用户提供优惠方案获取请求的发起界面；

当所述用户发起优惠方案获取请求时，根据其他用户针对所述优惠方案获取请求的响应回复确认所述转赠优惠方案，其中，所述优惠方案获取请求用于在社交软件中请求他人赠送所述转赠优惠方案。

在本申请一实施例中，所述可用优惠方案还包括当前尚未满足使用条件、但在当前用餐场景下具备满足使用条件可能性的优惠方案，所述方法还包括：

向所述用户展示达成所述优惠方案组合的使用条件的指导信息。

在本申请一实施例中，所述方法还包括：

根据所述可用优惠方案组合生成对应的菜品点选推荐方案；

展示所述可用优惠方案组合及其对应的菜品点选推荐方案。

在本申请一实施例中，展示所述可用优惠方案组合及其对应的优惠力度，包括：

按照从大到小的顺序，基于所述优惠力度为所述可用优惠方案组合排序，展示前n个可用优惠方案组合及其对应的优惠力度。

本申请一实施例还提出了一种优惠方案展示装置，包括：

信息采集模块，其用于获取用户当前用餐场景的用餐场景描述信息，所述用餐场景描述信息包括用户账户信息、用餐人数、用餐地点、用餐时间、点选的菜品及菜价中的一项或多项的组合；

可用优惠方案确认模块，其用于根据所述用餐场景描述信息确认所述用户在当前用餐场景下的可用优惠方案；

叠加使用规则确认模块，其用于获取所述可用优惠方案的叠加使用规则；

优惠方案组合模块，其用于基于所述叠加使用规则对所述可用优惠方案进行组合，获取所述用户在当前用餐场景下的可用优惠方案组合，每个所述可用优惠方案组合包括至少一个所述可用优惠方案；

优惠力度计算模块，其用于根据所述用餐场景描述信息，计算所述可用优惠方案组合的优惠力度；

展示模块，其用于展示所述可用优惠方案组合及其对应的优惠力度。

本申请一实施例还提出了一种电子设备，所述电子设备包括用于存储计算机程序指令的存储器和用于执行程序指令的处理器，其中，当该计算机程序指令被该处理器执行时，触发所述电子设备执行本申请实施例所述的方法步骤。

本申请一实施例还提出了一种计算机可读存储介质，计算机可读存储介质中存储有计算机程序，当其在计算机上运行时，使得计算机执行本申请实施例的方法。

本申请实施例采用的上述至少一个技术方案能够达到以下有益效果：

根据本申请一实施例的方法，对优惠力度进行计算并直接向用户展示最终的计算结果，使得用户可以简单直接的进行优惠力度对比，从而大大降低用户选用优惠方案的难度；

根据本申请一实施例的方法，针对优惠方案的叠加使用进行优惠方案的叠加组合，针对优惠方案组合进行优惠力度计算，从而确保用户可以直接确认最优的优惠力度；

相较于现有技术的方法，根据本申请一实施例的方法，降低了用户选用优惠方案的难度，避免了用户选用优惠方案时遗漏优惠方案，并确保用户可以确认最优的优惠力度，大大提高了优惠方案的实用性，提高了用户体验。

附图说明

图1所示为根据本申请优惠方案展示方法一实施例的流程图；

图2所示为根据本申请优惠方案展示方法一实施例的部分流程图；

图3所示为根据本申请优惠方案展示方法一实施例的部分流程图；

图4所示为根据本申请优惠方案展示方法一实施例的流程图；

图5所示为根据本申请优惠方案展示方法一实施例的部分流程图；

图6所示为根据本申请优惠方案展示方法一实施例的部分流程图；

图7所示为根据本申请优惠方案展示方法一实施例的部分流程图；

图8所示为根据本申请优惠方案展示装置一实施例的结构图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚，下面将结合本申请具体实施例及相应的附图对本申请技术方案进行清楚、完整地描述。显然，所描述的实施例仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

本申请的实施方式部分使用的术语仅用于对本申请的具体实施例进行解释，而非旨在限定本申请。

针对由于优惠方案种类繁多而导致的消费者选用困难的问题，本申请一实施例提出了一种优惠方案展示方法。为了提出本申请实施例的方法，发明人首先分析优惠方案的实际使用场景。在优惠方案的实际使用场景中，优惠方案主要包含使用条件以及优惠方式两个部分。

具体的，使用条件是指，只有当前用餐场景满足优惠方案的使用条件，才能使用该优惠方案。例如，满100元减15元的满减优惠方案的使用条件就是当前消费额度大于等于100元；又例如，周末打9折的限时优惠方案的使用条件就是消费时间为周末；又例如，指定门店10元代金券的使用条件就是消费地点为代金券的指定门店。

具体的，优惠方式是指，优惠方案在被使用时是采取什么样的方式来实现优惠。例如，满100元减15元的满减优惠方案的优惠方式就是将需要支付的额度消减15元；又例如，周末打9折的限时优惠方案的优惠方式就是将需要支付的额度乘以系数0.9；又例如，指定门店10元代金券的优惠方式就是在支付时可以使用代金券抵用10元。

在优惠方案的实际使用场景中，一般的，不同的优惠方案在使用条件和/或优惠方式上存在差异，这就需要消费者需要对比不同的优惠方案，根据当前的用餐场景选择满足使用条件并且优惠方式可以实现最佳优惠力度的优惠方案。

然而，随着消费者所持有的优惠方案的不断累积，在同一用餐场景中可以使用的优惠方案不断增多，消费者在对当前用餐场景下可以使用的优惠方案进行对比时很容易遗漏可以使用的优惠方案。

例如，在一应用场景中，消费者在周六用餐消费180元，消费者确认自身可以使用满100元减15元的满减优惠方案或者指定门店10元代金券，但由于消费者忘记还存在周末打9折的限时优惠方案，这就导致在进行优惠力度对比时就没有考虑到针对周末打9折的限时优惠方案。

进一步的，不同的优惠方式对于优惠力度的计算方法不同，针对不同的用餐场景，同一优惠方式产生的优惠力度也会不同。例如，在一应用场景中，消费者在周六用餐消费180元，使用满100元减15元的满减优惠方案的优惠力度为15元，使用周末打9折的限时优惠方案的优惠力度为18元，周末打9折的限时优惠方案的优惠力度的优惠力度更优。而如果消费者在周六用餐消费120元，使用满100元减15元的满减优惠方案的优惠力度为15元，使用周末打9折的限时优惠方案的优惠力度为12元，则变成满100元减15元的满减优惠方案的优惠力度更优。

因此，消费者在进行优惠方案选用时还需要根据具体的用餐场景信息计算优惠力度，这会大大加大优惠方案选用的操作难度。

基于上述分析，优惠方案选用困难的主要原因包括难以避免可用优惠方案的遗漏以及优惠方案的优惠力度计算繁琐。因此，如果可以向消费者直接展示当前用餐场景的可用优惠方案及其对应的优惠力度，使得消费者可以直接进行优惠力度对比，就可以大大降低消费者选用优惠方案的难度并确保消费者可以选用到优惠力度最佳的优惠方案。

因此，在本申请一实施例中，首先采集用户(消费者)的用餐场景的用餐场景描述信息，根据用餐场景描述信息确认用户在该用餐场景下可使用的优惠方案(可用优惠方案)，计算每种可用优惠方案的优惠力度，向用户展示所有可用优惠方案及其对应的优惠力度。这样，用户可以直接了解当前可以使用的优惠方案并直接对比各个优惠方案的优惠力度，从而可以简单直接的进行优惠方案的选用。

具体的，在实际应用场景中，根据优惠方案的具体设置的不同，与优惠方案相关的用餐场景描述信息也不同。例如，在一应用场景中，针对满100元减15元的满减优惠方案，与其相关的用餐场景描述信息就包括点选的菜品以及菜品单价；又例如，在一应用场景中，针对周末打9折的限时优惠方案，与其相关的用餐场景描述信息就包括用餐时间。又例如，在一应用场景中，针对指定门店10元代金券，与其相关的用餐场景描述信息就包括用餐地点。又例如，在一应用场景中，针对生日当天打9折的优惠方案，与其相关的用餐场景描述信息就包括用户信息(用户生日信息)以及用餐时间。

因此，在本申请一实施例中，在采集用餐场景描述信息时，对用餐场景描述信息不做具体限定，可以根据优惠方案的设置安排和/或数据采集条件来确定具体需要采集的用餐场景信息的内容。

具体的，在本申请一实施例中，用餐场景描述信息包括用户信息、用餐人数、用餐地点、用餐时间、点选的菜品及菜价中的一项或多项的组合。

进一步的，在本申请另一实施例中，用餐场景描述信息还可以包括上述信息以外的其他信息。

进一步的，在实际应用场景中，根据优惠方案使用条件的设置，一些优惠方案相互间是可以叠加使用的，而另一些优惠方案相互间是不可以叠加使用的。针对同一用餐场景，使用不同的优惠方案叠加组合所达成的优惠力度是不同的。例如，在一应用场景中，满100元减15元的满减优惠方案以及指定门店10元代金券被设置为可以叠加使用；周末打9折的限时优惠方案以及指定门店10元代金券被设置为可以叠加使用；周末打9折的限时优惠方案与满100元减15元的满减优惠方案被设置为不可以叠加使用。那么，如果用户在指定门店消费100元，按照上述优惠方案叠加设置，就存在两种优惠方案叠加组合，满100元减15元的满减优惠方案与指定门店10元代金券叠加使用，以及，周末打9折的限时优惠方案与指定门店10元代金券叠加使用。

基于上述分析，为了尽可能的降低用户的优惠方案选用难度，令用户可以直接对比确认最优的优惠力度，在本申请一实施例中，在进行优惠力度计算时，并不是孤立的针对每一个优惠方案进行计算，而是首先获取可用优惠方案的叠加使用规则，基于叠加使用规则对可用优惠方案进行组合，获取用户在当前用餐场景下的所有的可用的优惠方案组合(可用优惠方案组合)(具体的，一个优惠方案组合可以只包含一个优惠方案，也可以包含多个可以叠加使用的优惠方案)。针对每个可用优惠方案组合计算优惠力度并进行展示。

根据本申请一实施例的方法，对优惠力度进行计算并直接向用户展示最终的计算结果，使得用户可以简单直接的进行优惠力度对比，从而大大降低用户选用优惠方案的难度；进一步的，根据本申请一实施例的方法，针对优惠方案的叠加使用进行优惠方案的叠加组合，针对优惠方案组合进行优惠力度计算，从而确保用户可以直接确认最优的优惠力度；相较于现有技术的方法，根据本申请一实施例的方法，降低了用户选用优惠方案的难度，避免了用户选用优惠方案时遗漏优惠方案，并确保用户可以确认最优的优惠力度，大大提高了优惠方案的实用性，提高了用户体验。

以下结合附图，详细说明本申请各实施例提供的技术方案。

图1所示为根据本申请优惠方案展示方法一实施例的流程图。在本申请一实施例中，如图1所示，优惠方案展示方法包括：

步骤110，获取用户当前用餐场景的用餐场景描述信息；

步骤120，根据用餐场景描述信息确认用户在当前用餐场景下的可用优惠方案；

步骤130，获取可用优惠方案的叠加使用规则；

步骤140，基于叠加使用规则对可用优惠方案进行组合，获取用户在当前用餐场景下的可用优惠方案组合，每个可用优惠方案组合包括至少一个可用优惠方案；

步骤150，根据用餐场景描述信息，计算可用优惠方案组合的优惠力度；

步骤160，展示可用优惠方案组合及其对应的优惠力度。

进一步的，在实际应用场景中，用户在当前用餐场景下的可用优惠方案需要满足一个前提，那就是，该优惠方案必须是可以被当前用户选用的，其所有权和/或使用权归于与当前的用户。例如，在记名代金券不能转赠的应用场景中，用户A不能选用记名为用户B的代金券)。又例如，与用户账户绑定的满100元减15元的满减优惠方案，只有在对应的用户账户进行消费时才可以被选用。

因此，在本申请一实施例中，首先确认用户可以选用的优惠方案(可选优惠方案)，然后从用户所持有的优惠方案中筛选可以在当前用餐场景下使用的可用优惠方案。

具体的，由于用户自身所持有的优惠方案即为可以被该用户选用的、所有权和/或使用权归于与用户的优惠方案。因此，在本申请一实施例中，用户的可选优惠方案包括用户的已持有优惠方案。

进一步的，在实际应用场景中，存在可以被所有用户选用的通用优惠方案，例如，在一应用场景中，周末打9折的限时优惠方案是针对所有用户的。因此，在本申请一实施例中，用户的可选优惠方案还包括通用优惠方案。例如，获取商家的的优惠信息，从中提取通用优惠方案。

具体的，在本申请一实施例中，根据用餐场景描述信息确认用户在当前用餐场景下的可用优惠方案，包括：

确认用户的可选优惠方案，其中，用户的可选优惠方案包括用户的已持有优惠方案以及通用优惠方案；

根据用餐场景描述信息，从可选优惠方案中筛选可用优惠方案，其中，可用优惠方案包括已满足使用条件的优惠方案。

具体的，在本申请一实施例中，确认用户的已持有优惠方案，包括，根据用户的账户信息确认用户的已持有优惠方案。例如，在一应用场景中，用户登录自身账户，根据用户账户下的优惠方案记录确认用户名下持有的未使用优惠方案。

具体的，在本申请一实施例中，确认用户的已持有优惠方案，包括，根据用户录入的优惠方案验证信息确认用户的已持有优惠方案。例如，在一应用场景下，扫描用户持有的的优惠券上的二维码，从而将优惠券对应的优惠方案录入为该用户的已持有优惠方案。

进一步的，在实际应用场景中，用户获取优惠方案的途径除了商家主动赠送以外，还包括用户主动获取优惠方案。例如，参加商家举办的优惠活动、主动购买代金券等。然而，由于商家优惠宣传不到位、用户没有深入了解优惠信息等原因，用户并未主动去获取优惠方案，这就导致用户当前持有的优惠方案并不是用户实际上可以选用的所有优惠方案。例如，当前存在10元购买12元代金券的活动，由于用户不知道该活动的存在，因此没有购买，用户所持有的优惠方案就不包含12元代金券。

针对上述问题，在本申请一实施例中，在确认用户的可选优惠方案时，不仅仅考虑用户的已持有优惠方案以及商家的通用优惠方案，还将当前用餐场景下用户可以获取的可获取优惠方案纳入考虑。这样，就可以最大限度地避免优惠方案被遗漏，确保用户可以确认所有的具备选用可能性的优惠方案组合，确保用户可以确认最优的优惠力度。如果用户所选定的优惠方案组合包含可获取优惠方案，用户就可以在选用该优惠方案组合时主动去获取对应的可获取优惠方案。

具体的，在本申请一实施例中，用户的可选优惠方案还包括用户在当前用餐场景下的可获取优惠方案。

具体的，在本申请一实施例中，确认用户的可获取优惠方案，包括：

获取当前正在进行当中的优惠方案活动；

从当前正在进行当中的优惠方案活动中确认用户可以参与的优惠方案活动，确认可获取优惠方案。

例如，当前存在10元购买12元代金券的活动，但用户并不知道该活动，没有购买代金券，因此用户所持有的优惠方案不包含12元代金券。但是，用户具备购买该代金券的能力。此时该12元代金券为可获取优惠方案，在进行可选优惠方案确认时，将12元代金券纳入可选优惠方案。

又例如，当前存在网络社交社区发布评论分享赠送12元代金券的活动，由于用户并未参与该活动，因此用户所持有的优惠方案不包含该活动赠送的12元代金券，但是用户具备参与该活动的能力，此时该12元代金券为可获取优惠方案，在进行可选优惠方案确认时，将12元代金券纳入可选优惠方案。

图2所示为根据本申请优惠方案展示方法一实施例的部分流程图。在本申请一实施例中，如图2所示，确认用户在当前用餐场景下的可用优惠方案包括：

步骤211，根据用户的账户信息以及用户录入的优惠方案验证信息确认用户的已持有优惠方案；

步骤212，获取当前正在进行当中的优惠方案活动；

步骤213，从当前正在进行当中的优惠方案活动中确认通用优惠方案；

步骤214，根据用餐场景描述信息，从当前正在进行当中的优惠方案活动中确认用户可以参与的优惠方案活动，确认用户的可获取优惠方案；

步骤220，根据用餐场景描述信息，从用户的已持有优惠方案、通用优惠方案以及用户的可获取优惠方案中筛选可用优惠方案。

进一步的，为了在用户选定包含可获取优惠方案的可用优惠方案组合时可以方便的获取可获取优惠方案，在本申请一实施例中，方法还包括：

向用户展示优惠方案获取信息，优惠方案获取信息用于指导用户获取可用优惠方案组合中的可获取优惠方案。

例如，在一应用场景中，当前存在网络社交社区发布评论分享赠送12元代金券的活动，由于用户并未参与该活动，因此用户所持有的优惠方案不包含该活动赠送的12元代金券，但是用户具备参与该活动的能力，此时该12元代金券为可获取优惠方案，在进行可选优惠方案确认时，将12元代金券纳入可选优惠方案。如果最终展示的可用优惠方案组合中包含12元代金券，则向用户同步展示获取该12元代金券需要在网络社交社区发布评论分享。进一步的，向用户提供在网络社交社区发布评论分享的模板。

进一步的，在实际应用场景中，某些优惠方案是可以在不同的用户间转赠的。在当前用餐场景发生之前，已完成转赠的优惠方案属于用户的已持有优惠方案。进一步的，即使在当前用餐场景之前，当前用户并未请求其他用户请求用户赠送当前用餐场景可用的优惠方案，并且，其他用户也并未主动向当前用户赠送当前用餐场景可用的优惠方案，然而，在当前用餐场景下，用户仍然可以请求其他用户请求用户赠送当前用餐场景可用的优惠方案。

因此，在本申请一实施例中，可选优惠方案还包括当前用餐场景下其他用户赠送给当前用户的转赠优惠方案。具体的，在本申请一实施例中，提示当前用户请求其他用户请求用户赠送当前用餐场景可用的优惠方案，根据其他用户的回应确认转赠优惠方案。

具体的，在本申请一实施例中，确认转赠优惠方案，包括：

向用户提供优惠方案获取请求的发起界面；

当用户发起优惠方案获取请求时，根据其他用户针对优惠方案获取请求的响应回复确认其他用户向用户赠送的转赠优惠方案，其中，优惠方案获取请求用于在社交软件中请求他人赠送转赠优惠方案。

图3所示为根据本申请优惠方案展示方法一实施例的部分流程图。在本申请一实施例中，如图3所示，确认转赠优惠方案包括：

步骤310，确认是否存在可以被转赠的优惠方案；

步骤320，当存在可以被转赠的优惠方案时，提示当前用户请求其他用户请求用户赠送当前用餐场景可用的优惠方案；

步骤330，向当前用户提供优惠方案获取请求的发起界面；

步骤340，基于发起界面采集用户的输入信息，生成优惠方案获取请求；

步骤350，在社交软件中发布优惠方案获取请求，请求他人赠送优惠方案；

步骤360，获取其他用户针对优惠方案获取请求的响应回复；

步骤370，根据其他用户针对优惠方案获取请求的响应回复确认其他用户向用户赠送的转赠优惠方案。

具体的，在根据本申请一实施例的应用场景中，在生成优惠方案获取请求的过程中，生成包含用户信息、菜品信息相关的分享链接，将该链接发送至第三方社交软件，获取相关的优惠折扣。

进一步的，在根据本申请一实施例的应用场景中，在优惠方案获取请求已发布但未得到有效回应的等待时间中，显示优惠正在索取中。如果等待时间超过预设时长，提示用户优惠方案索取失败。

进一步的，在根据本申请一实施例的应用场景中，在发布优惠方案获取请求前，获取用户当前位置信息，并搜索当前位置设定范围内的在线用户，显示并供用户分享，实现与周围在线用户的互动和优惠共享的获取。

进一步的，在根据本申请一实施例的应用场景中，在发布优惠方案获取请求前，获取用户当前位置信息，并搜索当前位置设定范围内的在线用户，查询该范围内的在线用户，查询是否具有选择了相同菜品，且优惠折扣组合条数大于等于2的用户，界面显示并供用户选择进行定向的优惠方案获取请求发送，以提高获取精准率。

进一步的，在根据本申请一实施例的应用场景中，在发布优惠方案获取请求前，向该范围内的在线用户，查询是否具有选择了相同菜品，且优惠折扣组合条数大于等于2的用户。主动向该用户推送优惠方案获取请求。

进一步的，在实际应用场景中，只有满足了优惠方案的使用条件时才可以使用该优惠条件。例如，周末打9折的限时优惠方案只有在周末才可以被使用。但是，针对某些优惠方案，即使当前未满足其使用条件，用户也可以通过自身的主动行为去主动满足其使用条件。例如，针对满100元减15元的满减优惠方案，当用户消费在100元以下时，无法使用该优惠方案，但是，用户可以通过点选更多的菜品来满足该优惠方案的使用条件。

因此，在本申请一实施例中，在从可选优惠方案中筛选可用优惠方案时，可用优惠方案还包括当前尚未满足使用条件、但在当前用餐场景下具备满足使用条件可能性的优惠方案。这样，用户就可以根据自身的具体情况，决定是否要主动去满足优惠方案的使用条件，从而给用户更多的自主选择权。

进一步的，在本申请一实施例中，为了便于用户决定是否要主动去满足优惠方案的使用条件，方法还包括：

向用户展示达成优惠方案组合的使用条件的指导信息。

进一步的，在本申请一实施例中，为了便于用户选定优惠方案组合并达成优惠方案组合的使用条件，方法还包括：

根据可用优惠方案组合生成对应的菜品点选推荐方案；

展示可用优惠方案组合及其对应的菜品点选推荐方案。

进一步的，在本申请一实施例中，对优惠方案组合及其对应的优惠力度的具体展示形式不做具体限定。可以根据实际需求确定优惠方案组合及其对应的优惠力度的具体展示形式。

具体的，考虑到过多的优惠方案组合展示会影响用户的选择，在本申请一实施例中，展示可用优惠方案组合及其对应的优惠力度，包括：

按照从大到小的顺序，基于优惠力度为可用优惠方案组合排序，展示前n(n为根据实际展示需求而定的预设值)个可用优惠方案组合及其对应的优惠力度。

进一步的，在本申请一实施例中，方法还包括优惠组合选定步骤，用户可以选定所需的可用优惠方案组合。在用户选定可用优惠方案组合后返回到订单支付页面，页面会显示用户选择的优惠信息和优惠金额以及用户需要支付的总金额。

进一步的，在本申请一实施例中，方法还包括分享步骤，在用户选定可用优惠方案组合并成功支付后，提示让用户分享到社交软件。

图4所示为根据本申请优惠方案展示方法一实施例的流程图。在根据本申请一实施例的应用场景中，如图4所示，优惠方案展示流程包括：

步骤410，获取用户点选的菜品以及菜品原价；

步骤420，遍历优惠方案数据库，根据菜品以及菜品原价，筛选出针对已点选的菜品的可用优惠方案；

步骤430，确认可用优惠方案的叠加使用规则，基于叠加使用规则对可用优惠方案进行组合，生成所有的可用优惠方案组合；

步骤440，计算各个可用优惠方案组合的优惠金额；

步骤450，对优惠金额进行排序，根据排序结果进行可用优惠方案组合及其对应的优惠金额的展示。

具体的，在根据本申请一实施例的应用场景中，在步骤410中，调用点餐平台的后台接口，传入用户已选择菜品和数量，并从点餐平台的后台接口查询相关数据获取到菜品的原价。

图5所示为根据本申请优惠方案展示方法一实施例的部分流程图。在根据本申请一实施例的应用场景中，如图5所示，用户前端下单流程包括：

步骤510，接收用户的点选菜品操作；

步骤520，当用户点选菜品并确认后进入确认购买页面；

步骤530，在确认购买页面显示此次购买的最优可用优惠方案组合以及对应的优惠金额；

步骤540，判断用户是否确认选用最优可用优惠方案组合；

当用户选用最优可用优惠方案组合时，执行步骤550；

当用户拒绝最优可用优惠方案组合时，步骤560，进入可用优惠方案组合列表展示页面；

步骤570，确认用户选用的可用优惠方案组合；

步骤550，进入支付确认页面。

具体的，在根据本申请一实施例的应用场景中，在步骤420中，查询获取当前正在进行当中的优惠折扣活动，然后再根据用户信息查询其可用的优惠方案列表，在查询优惠方案时，对于针对某些菜品的优惠方案，根据用户已选择的菜品进行筛选。

具体的，在根据本申请一实施例的应用场景中，在步骤430中，将能够组合在一起的优惠方案进行组合、判断和处理。通过对各种优惠方案进行排列，得到当前所有可用的所有组合。

例如：当前有满100减10的活动1，有满120减1折的活动2，以及可用的优惠券3，优惠券不能与活动同时使用，可能的组合有：一，活动1；二，活动2；三，优惠券3；四，活动1和2。

图6所示为根据本申请优惠方案展示方法一实施例的部分流程图。在根据本申请一实施例的应用场景中，如图6所示，生成所有的可用优惠方案组合的流程包括：

步骤610，获取所有的可用优惠方案，建立可用优惠方案数组，可用优惠方案数组中的每一条记录对应一个可用优惠方案；

步骤620，从可用优惠方案数组取出一条记录；

步骤630，判断步骤620是否可以取到记录；

如果步骤620不可以取到记录，可用优惠方案组合的生成流程结束；

如果步骤620可以取到记录，执行步骤640，将步骤620取出的可用优惠方案记录添加到可用优惠方案组合；

步骤650，从剩余的可用优惠方案数组取出一条记录；

步骤660，判断步骤650是否可以取到记录；

如果步骤650不可以取到记录，返回步骤620；

如果步骤650可以取到记录，执行步骤670，判断步骤650取出的可用优惠方案记录与可用优惠方案组合中的可用优惠方案记录是否矛盾；

如果矛盾，返回步骤650；

如果不矛盾，执行步骤680，将步骤650取出的可用优惠方案记录添加到可用优惠方案组合；

步骤690，递归处理后面的数据。

图7所示为根据本申请优惠方案展示方法一实施例的部分流程图。在根据本申请一实施例的应用场景中，如图7所示，计算各个可用优惠方案组合的优惠金额并对优惠金额进行排序的流程包括：

步骤711，获取所有的可用优惠方案组合，构建可用优惠方案组合数组，可用优惠方案组合数组中每一条记录对应一个可用优惠方案组合；

步骤712，获取已点选的菜品以及原价；

步骤720，从可用优惠方案组合数组中取出一条可用优惠方案组合记录；

步骤730，判断是否可以取到记录；

步骤740，当可以取到记录时，基于取到的可用优惠方案组合记录，根据已点选的菜品以及原价计算优惠金额，返回步骤720；

步骤750，当不可以取到记录时，对计算获取到的优惠金额进行排序。

可以理解的是，上述实施例中的部分或全部步骤骤或操作仅是示例，本申请实施例还可以执行其它操作或者各种操作的变形。此外，各个步骤可以按照上述实施例呈现的不同的顺序来执行，并且有可能并非要执行上述实施例中的全部操作。

进一步的，基于本申请一实施例中提出的优惠方案展示方法，本申请一实施例还提出了一种优惠方案展示装置。图8所示为根据本申请优惠方案展示装置一实施例的结构图。在本申请一实施例中，如图8所示，在本申请一实施例中，优惠方案展示装置800包括：

信息采集模块810，其用于获取用户当前用餐场景的用餐场景描述信息，所述用餐场景描述信息包括用户账户信息、用餐人数、用餐地点、用餐时间、点选的菜品及菜价中的一项或多项的组合；

可用优惠方案确认模块820，其用于根据所述用餐场景描述信息确认所述用户在当前用餐场景下的可用优惠方案；

叠加使用规则确认模块830，其用于获取所述可用优惠方案的叠加使用规则；

优惠方案组合模块840，其用于基于所述叠加使用规则对所述可用优惠方案进行组合，获取所述用户在当前用餐场景下的可用优惠方案组合，每个所述可用优惠方案组合包括至少一个所述可用优惠方案；

优惠力度计算模块850，其用于根据所述用餐场景描述信息，计算所述可用优惠方案组合的优惠力度；

展示模块860，其用于展示所述可用优惠方案组合及其对应的优惠力度。

图8所示的本申请一实施例提供的装置可用于执行本申请实施例的方法实施例的技术方案，其实现原理和技术效果可以进一步参考方法实施例中的相关描述。

进一步的，在20世纪90年代，对于一个技术的改进可以很明显地区分是硬件上的改进(例如，对二极管、晶体管、开关等电路结构的改进)还是软件上的改进(对于方法流程的改进)。然而，随着技术的发展，当今的很多方法流程的改进已经可以视为硬件电路结构的直接改进。设计人员几乎都通过将改进的方法流程编程到硬件电路中来得到相应的硬件电路结构。因此，不能说一个方法流程的改进就不能用硬件实体模块来实现。例如，可编程逻辑器件(Programmable Logic Device,PLD)(例如现场可编程门阵列(FieldProgrammable Gate Array，FPGA))就是这样一种集成电路，其逻辑功能由访问方对器件编程来确定。由设计人员自行编程来把一个数字装置“集成”在一片PLD上，而不需要请芯片制造厂商来设计和制作专用的集成电路芯片。而且，如今，取代手工地制作集成电路芯片，这种编程也多半改用“逻辑编译器(logic compiler)”软件来实现，它与程序开发撰写时所用的软件编译器相类似，而要编译之前的原始代码也得用特定的编程语言来撰写，此称之为硬件描述语言(Hardware Description Language，HDL)，而HDL也并非仅有一种，而是有许多种，如ABEL(Advanced Boolean Expression Language)、AHDL(Altera HardwareDescription Language)、Confluence、CUPL(Cornell University ProgrammingLanguage)、HDCal、JHDL(Java Hardware Description Language)、Lava、Lola、MyHDL、PALASM、RHDL(Ruby Hardware Description Language)等，目前最普遍使用的是VHDL(Very-High-Speed Integrated Circuit Hardware Description Language)与Verilog。本领域技术人员也应该清楚，只需要将方法流程用上述几种硬件描述语言稍作逻辑编程并编程到集成电路中，就可以很容易得到实现该逻辑方法流程的硬件电路。

控制器可以按任何适当的方式实现，例如，控制器可以采取例如微处理器或处理器以及存储可由该(微)处理器执行的计算机可读程序代码(例如软件或固件)的计算机可读介质、逻辑门、开关、专用集成电路(Application Specific Integrated Circuit，ASIC)、可编程逻辑控制器和嵌入微控制器的形式，控制器的例子包括但不限于以下微控制器：ARC 625D、Atmel AT91SAM、Microchip PIC18F26K20以及Silicone Labs C8051F320，存储器控制器还可以被实现为存储器的控制逻辑的一部分。本领域技术人员也知道，除了以纯计算机可读程序代码方式实现控制器以外，完全可以通过将方法步骤进行逻辑编程来使得控制器以逻辑门、开关、专用集成电路、可编程逻辑控制器和嵌入微控制器等的形式来实现相同功能。因此这种控制器可以被认为是一种硬件部件，而对其内包括的用于实现各种功能的装置也可以视为硬件部件内的结构。或者甚至，可以将用于实现各种功能的装置视为既可以是实现方法的软件模块又可以是硬件部件内的结构。

在本申请实施例的描述中，为了描述的方便，描述装置时以功能分为各种模块/单元分别描述，各个模块/单元的划分仅仅是一种逻辑功能的划分，在实施本申请实施例时可以把各模块/单元的功能在同一个或多个软件和/或硬件中实现。

具体的，本申请实施例所提出的装置在实际实现时可以全部或部分集成到一个物理实体上，也可以物理上分开。且这些模块可以全部以软件通过处理元件调用的形式实现；也可以全部以硬件的形式实现；还可以部分模块以软件通过处理元件调用的形式实现，部分模块通过硬件的形式实现。例如，检测模块可以为单独设立的处理元件，也可以集成在电子设备的某一个芯片中实现。其它模块的实现与之类似。此外这些模块全部或部分可以集成在一起，也可以独立实现。在实现过程中，上述方法的各步骤或以上各个模块可以通过处理器元件中的硬件的集成逻辑电路或者软件形式的指令完成。

例如，以上这些模块可以是被配置成实施以上方法的一个或多个集成电路，例如：一个或多个特定集成电路(Application Specific Integrated Circuit，ASIC)，或，一个或多个数字信号处理器(Digital Singnal Processor，DSP)，或，一个或者多个现场可编程门阵列(Field Programmable Gate Array，FPGA)等。再如，这些模块可以集成在一起，以片上装置(System-On-a-Chip，SOC)的形式实现。

本申请一实施例还提出了一种电子设备，电子设备包括用于存储计算机程序指令的存储器和用于执行程序指令的处理器，其中，当该计算机程序指令被该处理器执行时，触发电子设备执行本申请实施例所述的方法步骤。

本申请实施例阐明的电子设备、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机，例如可以为台式电脑、笔记本电脑、平板电脑、手机、个人数字助理、媒体播放器、导航设备、游戏控制台、可穿戴设备或者这些设备中的任何设备的组合。具体的，在本申请一实施例中，上述电子设备可以为是终端设备，例如，移动终端(手机、平板电脑、笔记本电脑)、本地终端(个人/工业电脑)、云端服务器等设备；也可以是内置于上述终端设备的电路设备。

进一步的，在本申请一实施例中，电子设备的处理器可以是片上装置SOC，该处理器中可以包括一个或多个处理单元，例如：处理器可以包括中央处理器(CentralProcessing Unit，CPU)、DSP、微控制器、应用处理器(Application Processor，AP)、图形处理器(Graphics Processing Unit，GPU)、嵌入式神经网络处理器(Neural-networkProcess Units，NPU)、图像信号处理器(Image Signal Processing，ISP)、调制解调处理器、视频编解码器、基带处理器、脉冲宽度调制(Pulse width modulation，PWM)控制器，还可以进一步包括其他类型的处理器。其中，不同的处理单元可以是独立的器件，也可以集成在一个或多个处理器中。处理器中的控制器可以根据指令操作码和时序信号，产生操作控制信号，完成取指令和执行指令的控制。

进一步的，在本申请一实施例中，处理器还可包括必要的硬件加速器或逻辑处理硬件电路，如ASIC，或一个或多个用于控制本申请技术方案程序执行的集成电路等。此外，处理器可以具有操作一个或多个软件程序的功能，软件程序可以存储在存储介质中。

进一步的，在本申请一实施例中，电子设备的存储器包括永久性和非永久性、可移动和非可移动的可以由任何方法或技术来实现信息存储的计算机可读介质。存储器的计算机可读介质存储的信息可以是计算机可读指令、数据结构、程序的模块或其他数据。

用于构造存储器的计算机可读介质例子包括但不限于：只读存储器(Read-OnlyMemory，ROM)、可存储静态信息和指令的其它类型的静态存储设备、随机存取存储器(Random Access Memory，RAM)、电可擦可编程只读存储器(Electrically ErasableProgrammable Read-Only Memory，EEPROM)、相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、快闪记忆体或其他内存技术的记忆体、只读光盘(Compact Disc Read-Only Memory，CD-ROM)、数字多功能光盘(DVD)或其他光学存储(包括压缩光碟、激光碟、光碟、数字通用光碟、蓝光光碟等)、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质等各种可以存储程序代码的、可以被计算设备访问的介质。

进一步的，在本申请一实施例中，处理器可以和存储器可以合成一个处理装置，更常见的是彼此独立的部件，处理器用于执行存储器中存储的程序代码来实现本申请实施例方法。具体实现时，该存储器也可以集成在处理器中，或者，独立于处理器。处理器中还可以设置存储器，用于存储指令和数据。在一些实施例中，处理器中的存储器为高速缓冲存储器。该存储器可以保存处理器刚用过或循环使用的指令或数据。如果处理器需要再次使用该指令或数据，可从存储器中直接调用。

进一步的，在一些实施例中，处理器可以包括一个或多个接口。接口可以包括集成电路(Inter-Integrated Circuit，I2C)接口，集成电路内置音频(Inter-IntegratedCircuit Sound，I2S)接口，脉冲编码调制(Pulse Code Modulation，PCM)接口，通用异步收发传输器(universal asynchronous receiver/transmitter，UART)接口，移动产业处理器接口(Mobile Industry Processor Interface，MIPI)，通用输入输出(General-PurposeInput/Output，GPIO)接口，用户标识模块(Subscriber Identity Module，SIM)接口，和/或USB接口等。

本领域内的技术人员应明白，本申请实施例可提供为方法、装置、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质上实施的计算机程序产品的形式。

在本申请所提供的几个实施例中，任一功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例方法的全部或部分步骤。

具体的，本申请一实施例中还提供一种计算机可读存储介质，该计算机可读存储介质中存储有计算机程序，当其在计算机上运行时，使得计算机执行本申请实施例提供的方法。

本申请一实施例还提供一种计算机程序产品，该计算机程序产品包括计算机程序，当其在计算机上运行时，使得计算机执行本申请实施例提供的方法。

本申请中的实施例描述是参照根据本申请实施例的方法、设备(装置)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

还需要说明的是，本申请实施例中，“至少一个”是指一个或者多个，“多个”是指两个或两个以上。“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示单独存在A、同时存在A和B、单独存在B的情况。其中A，B可以是单数或者复数。字符“/”一般表示前后关联对象是一种“或”的关系。“以下至少一项”及其类似表达，是指的这些项中的任意组合，包括单项或复数项的任意组合。例如，a，b和c中的至少一项可以表示：a，b，c，a和b，a和c，b和c或a和b和c，其中a，b，c可以是单个，也可以是多个。

本申请实施例中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括要素的过程、方法、商品或者设备中还存在另外的相同要素。

本申请可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本申请，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。

本申请中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于装置实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

本领域普通技术人员可以意识到，本申请实施例中描述的各单元及算法步骤，能够以电子硬件、计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的装置、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

以上，仅为本申请实施例的具体实施方式，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。本申请的保护范围应以权利要求的保护范围为准。

Claims (12)

1.一种优惠方案展示方法，其特征在于，包括：

获取用户当前用餐场景的用餐场景描述信息；

根据所述用餐场景描述信息确认所述用户在当前用餐场景下的可用优惠方案；

获取所述可用优惠方案的叠加使用规则；

基于所述叠加使用规则对所述可用优惠方案进行组合，获取所述用户在当前用餐场景下的可用优惠方案组合，每个所述可用优惠方案组合包括至少一个所述可用优惠方案；

根据所述用餐场景描述信息，计算所述可用优惠方案组合的优惠力度；

展示所述可用优惠方案组合及其对应的优惠力度。

2.根据权利要求1所述的方法，其特征在于，根据所述用餐场景描述信息确认所述用户在当前用餐场景下的可用优惠方案，包括：

确认所述用户的可选优惠方案，其中，所述可选优惠方案包括所述用户的已持有优惠方案以及通用优惠方案；

根据所述用餐场景描述信息，从所述可选优惠方案中筛选所述可用优惠方案，其中，所述可用优惠方案包括已满足使用条件的优惠方案。

3.根据权利要求2所述的方法，其特征在于，确认所述用户的已持有优惠方案，包括：

根据所述用户的账户信息确认所述用户的已持有优惠方案；

和/或，

根据所述用户录入的优惠方案验证信息确认所述用户的已持有优惠方案。

4.根据权利要求2所述的方法，其特征在于，所述可选优惠方案还包括所述用户在当前用餐场景下的可获取优惠方案，确认所述用户的可选优惠方案，包括：

获取当前正在进行当中的优惠方案活动；

从所述当前正在进行当中的优惠方案活动中确认所述用户可以参与的优惠方案活动，确认所述可获取优惠方案。

5.根据权利要求4所述的方法，其特征在于，所述方法还包括：

向所述用户展示优惠方案获取信息，所述优惠方案获取信息用于指导所述用户获取所述可用优惠方案组合中的可获取优惠方案。

6.根据权利要求2所述的方法，其特征在于，所述可选优惠方案还包括当前用餐场景下其他用户赠送给当前用户的转赠优惠方案，确认所述转赠优惠方案，包括：

向所述用户提供优惠方案获取请求的发起界面；

当所述用户发起优惠方案获取请求时，根据其他用户针对所述优惠方案获取请求的响应回复确认所述转赠优惠方案，其中，所述优惠方案获取请求用于在社交软件中请求他人赠送所述转赠优惠方案。

7.根据权利要求2所述的方法，其特征在于，所述可用优惠方案还包括当前尚未满足使用条件、但在当前用餐场景下具备满足使用条件可能性的优惠方案，所述方法还包括：

向所述用户展示达成所述优惠方案组合的使用条件的指导信息。

8.根据权利要求1所述的方法，其特征在于，所述方法还包括：

根据所述可用优惠方案组合生成对应的菜品点选推荐方案；

展示所述可用优惠方案组合及其对应的菜品点选推荐方案。

9.根据权利要求1～8中任一项所述的方法，其特征在于，展示所述可用优惠方案组合及其对应的优惠力度，包括：

按照从大到小的顺序，基于所述优惠力度为所述可用优惠方案组合排序，展示前n个可用优惠方案组合及其对应的优惠力度。

10.一种优惠方案展示装置，其特征在于，包括：

信息采集模块，其用于获取用户当前用餐场景的用餐场景描述信息，所述用餐场景描述信息包括用户账户信息、用餐人数、用餐地点、用餐时间、点选的菜品及菜价中的一项或多项的组合；

可用优惠方案确认模块，其用于根据所述用餐场景描述信息确认所述用户在当前用餐场景下的可用优惠方案；

叠加使用规则确认模块，其用于获取所述可用优惠方案的叠加使用规则；

优惠方案组合模块，其用于基于所述叠加使用规则对所述可用优惠方案进行组合，获取所述用户在当前用餐场景下的可用优惠方案组合，每个所述可用优惠方案组合包括至少一个所述可用优惠方案；

优惠力度计算模块，其用于根据所述用餐场景描述信息，计算所述可用优惠方案组合的优惠力度；

展示模块，其用于展示所述可用优惠方案组合及其对应的优惠力度。

11.一种电子设备，其特征在于，所述电子设备包括用于存储计算机程序指令的存储器和用于执行程序指令的处理器，其中，当该计算机程序指令被该处理器执行时，触发所述电子设备执行如权利要求1～9中任一项所述的方法步骤。

12.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有计算机程序，当其在计算机上运行时，使得计算机执行如权利要求1-9任一项所述的方法。

Images