CN108985817B

CN108985817B - 关联业务处理方法及装置、店铺推荐方法及装置

Info

Publication number: CN108985817B
Application number: CN201810612917.5A
Authority: CN
Inventors: 窦方钰
Original assignee: Koubei Shanghai Information Technology Co Ltd
Current assignee: Koubei Shanghai Information Technology Co Ltd
Priority date: 2016-12-02
Filing date: 2016-12-02
Publication date: 2021-03-23
Anticipated expiration: 2036-12-02
Also published as: CN107093095B; CN107093095A; CN108648006A; CN108985817A; CN108648006B

Abstract

本申请实施例公开了一种关联业务处理方法及装置、一种店铺推荐方法及装置。所述关联业务处理方法包括：获取业务点的支付实时数据；根据所述业务点的支付实时数据，以及保存的历史记录，确定所述业务点的热度表征值，所述历史记录包括所述业务点的支付历史数据，和/或所述业务点所属类目的支付汇总数据；根据所述业务点的热度表征值，对所述业务点所提供业务的关联业务进行处理。利用本申请实施例，可以实现根据业务点的热度表征值，用相应数量的处理资源对业务点所提供业务的关联业务进行处理，热度表征值的高低可以间接地反映业务点对于关联业务处理的具体程度或者紧要程度的要求高低，因此，本申请的关联业务处理方法有利于减少处理资源浪费。

Description

关联业务处理方法及装置、店铺推荐方法及装置

本申请为“关联业务处理方法及装置、店铺推荐方法及装置(申请日：2016年12月2 日，申请号：201611096672.2)”的分案申请。

技术领域

本申请涉及计算机软件技术领域，尤其涉及关联业务处理方法及装置、店铺推荐方法及装置。

背景技术

各类业务点为用户提供丰富的业务，极大地便利了用户的生活，这些业务点可以是实体业务点，比如，城市里的餐馆、衣饰店铺、家具店铺、便利店等，也可以是网上业务点，比如，电商平台的各种网上店铺等。

在现有技术中，业务点在为用户提供业务的同时，其所提供的业务往往存在一些关联业务需要相应的服务提供商来处理。多个业务点所提供的业务可能有相同的关联业务，并由同一家服务提供商处理，服务提供商往往按照业务点的数量将自身所有的处理资源平均分配，分别用以对各业务点所提供业务的关联业务进行相同处理。

但是，在实际应用中，各业务点存在差异，对于关联业务处理的具体程度或者紧要程度的需求可能也不相同，某些业务点所提供业务的关联业务处不处理甚至可能无关紧要。因此，现有技术中基于平均分配处理资源的关联业务处理方式容易造成处理资源浪费。

例如，以业务点为实体店铺为例，实体店铺所提供的商品售卖业务的关联业务可以是联网智能监控业务，智能监控服务器需要实时获取所监控的实体店铺的影像，并通过智能视频处理资源(中央处理器、图形处理器、高速缓存等)，对监控影像进行自动分析，以确定所监控的实体店铺内是否存在异常情况。按照现有技术则会为每个实体店铺提供相同数量的智能视频处理资源进行分析，但是，实际上有些实体店铺人流量很少，即使一段时间内不进行分析也行，因此会造成智能视频处理资源的浪费。

发明内容

本申请实施例提供关联业务处理方法及装置、店铺推荐方法及装置，用以解决现有技术中基于平均分配处理资源的关联业务处理方式容易造成处理资源浪费的技术问题。

为解决上述技术问题，本申请实施例是这样实现的：

本申请实施例提供的一种关联业务处理方法，包括：

获取业务点的支付实时数据；

根据所述业务点的支付实时数据，以及保存的历史记录，确定所述业务点的热度表征值，所述历史记录包括所述业务点的支付历史数据，和/或所述业务点所属类目的支付汇总数据；

根据所述业务点的热度表征值，对所述业务点所提供业务的关联业务进行处理。

本申请提供的一种关联业务处理装置，包括：

获取模块，获取业务点的支付实时数据；

确定模块，根据所述业务点的支付实时数据，以及保存的历史记录，确定所述业务点的热度表征值，所述历史记录包括所述业务点的支付历史数据，和/或所述业务点所属类目的支付汇总数据；

处理模块，根据所述业务点的热度表征值，对所述业务点所提供业务的关联业务进行处理。

本申请实施例提供的一种店铺推荐方法，包括：

获取店铺的支付实时数据；

根据所述店铺的支付实时数据，以及保存的历史记录，确定所述店铺的人气值，所述历史记录包括所述店铺的支付历史数据，和/或所述店铺所属类目的支付汇总数据；

根据所述店铺的人气值，对所述店铺进行推荐。

本申请实施例提供的一种店铺推荐装置，包括：

获取模块，获取店铺的支付实时数据；

确定模块，根据所述店铺的支付实时数据，以及保存的历史记录，确定所述店铺的人气值，所述历史记录包括所述店铺的支付历史数据，和/或所述店铺所属类目的支付汇总数据；

推荐模块，根据所述店铺的人气值，对所述店铺进行推荐。

本申请实施例采用的上述至少一个技术方案能够达到以下有益效果：可以实现根据业务点的热度表征值，用相应数量的处理资源对业务点所提供业务的关联业务进行处理，热度表征值的高低可以间接地反映业务点对于关联业务处理的具体程度或者紧要程度的要求高低，因此，本申请的关联业务处理方法有利于减少处理资源浪费，可以部分或全部地解决现有技术中的问题。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请中记载的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为本申请实施例提供的一种关联业务处理方法的流程示意图；

图2为本申请实施例提供的一种店铺推荐方法的流程示意图；

图3为本申请实施例提供的一种实际应用场景下，人气值及其关联信息综合排名生成方法的流程示意图；

图4为本申请实施例提供的一种实际应用场景下，人气值及其关联信息综合排名在手机上展示的示意图；

图5为本申请实施例提供的对应于图1的一种关联业务处理装置的结构示意图；

图6为本申请实施例提供的对应于图2的一种店铺推荐装置的结构示意图。

具体实施方式

本申请实施例提供一种关联业务处理方法及装置、一种店铺推荐方法及装置。

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

图1为本申请实施例提供的一种关联业务处理方法的流程示意图。从设备角度而言，该流程的执行主体可以包括但不限于以下设备：手机、平板电脑、智能手表、车机、个人计算机、大中型计算机、计算机集群等。从程序角度而言，该流程的执行主体可以是搭载于所述设备上的程序，比如，应用的服务端、客户端等。

图1中的流程可以包括以下步骤：

S101：获取业务点的支付实时数据。

在本申请实施例中，业务点可以是实体业务点，比如，城市里的餐馆、衣饰店铺、家具店铺、便利店等，也可以是网上业务点，比如，电商平台的各种网上店铺等。

业务点所提供的业务通常需要用户支付相应的费用，由用户针对业务点所提供业务的支付行为产生相应的支付数据(比如，支付数额、支付方用户信息、被支付方用户信息、所支付的业务明细等)。本申请实施例中根据支付数据的产生时刻所属时间区间的不同，将业务点的支付数据分为：支付实时数据、支付历史数据。

其中，支付实时数据对应的时间区间为从当前时刻往前推的一段较短的时间区间(比如，最近5分钟内、最近1小时内、最近1天内等)，本申请对所述的“较短的时间区间”具体有多短并不限定，可以取决于具体实施时的具体定义，支付历史数据对应的时间区间比支付实时数据对应的时间区间更早，比如，当支付实时数据对应的时间区间为最近1天内时，则支付历史数据对应的时间区间可以为最近1个月内除了最近1天内以外的时间区间。

在本申请实施例中，支付数据是电子数据，其具体的产生方式可以有多种，列举两种作为示例。

第一种，用户使用第三方支付应用或银行应用，针对业务点所提供业务进行电子支付动作，从而产生相应的支付数据。在这种情况下，通过第三方支付应用的服务端或银行应用的服务端可以获得业务点的支付实时数据。

第二种，用户使用现金或代金券等针对业务点所提供业务进行支付动作，业务点的工作人员通过电子记账的方式记录支付数据。在这种情况下，可以从电子记账系统获得业务点的支付实时数据。

S102：根据所述业务点的支付实时数据，以及保存的历史记录，确定所述业务点的热度表征值，所述历史记录包括所述业务点的支付历史数据，和/或所述业务点所属类目的支付汇总数据。

在本申请实施例中，可以预先对业务点划分类目，本申请对业务点的类目的粒度大小并不做限定，可以根据实际应用场景选择合适的业务点类目粒度进行划分，如此有利于获得比较可靠的热度表征值。

假定要将图1中的方法针对“饮食类店铺”这类业务点进行应用，则上述业务点所属类目可以是“饮食类店铺”中的类目，比如，从“饮食类店铺”划分出的“餐馆”、“蛋糕店”、“水果店”、“蔬菜店”等类目。

假定要将图1中的方法针对“餐馆”这类业务点进行应用，则上述业务点所属类目可以是“餐馆”中的类目，比如，从“餐馆”可以划分出的“快餐餐馆”、“正餐餐馆”等类目。当然，还划分粒度还可以更小，比如，从“正餐餐馆”可以划分出“火锅店”、“面馆”、“西餐店”等类目。

在本申请实施例中，业务点的热度表征值可以是用于反映诸如业务点的用户流量、用户使用频度以及业务繁忙程度等情况的表征值，这些情况通常又可以反映关联业务处理的具体程度或者紧要程度的需求，因此，可以将热度表征值作为关联业务处理的依据之一。

在本申请实施例中，可以采用业务点的支付实时数据、业务点的支付历史数据、业务点所属类目的支付汇总数据这三类数据，确定业务点的热度表征值。每类数据可以分别从不同的角度反映业务点的热度的真实情况，综合这三类有利于提高确定出的热度值的可靠性。在实际应用中，业务点的支付历史数据、业务点所属类目的支付汇总数据这两类数据也可以只采用其中一类，相应地，技术效果可能不如三类数据都采用时的技术效果。

具体的，业务点的支付实时数据可以反映业务点当前的热度，业务点的支付历史数据可以反映业务点前以往的热度，业务点所属类目的支付汇总数据可以反映类似业务点的平均热度等。

若缺少以上三类中的任一类数据，可能影响确定出的热度表征值的可靠性。

比如，缺少支付实时数据时，若某业务点当前暂时停业，则确定出的热度表征值显然不可靠；

又比如，缺少支付历史数据时，若某业务点只是新开业做促销活动，则可能有短期(比如，只有几天)的高用户流量，之后便会迅速下降，则这种情况下的高用户流量实际上只是流量毛刺，不能反映该业务点的普遍情况，如此确定出的热度表征值参考价值很低，实际上也是不可靠的；

再比如，缺少业务点所属类目的支付汇总数据时，若某业务点伪造其用户流量(伪造的流量相比于类目的平均流量通常偏差很大)，而并没有支付汇总数据作为参考以修正上述“伪造”动作对热度表征值带来的影响，如此确定出的热度表征值也是不可靠的；另外，之所以采用业务点所属类目的支付汇总数据，而不采用所有业务点的支付汇总数据，是因为不同类目业务点相互之间的可参考性较差，特别是小众类目与大众类目对应的业务点差异较大，不适于相互参考(也可以称为横向参考)，而本申请的方案正可以避免这种横向参考，可以只在类目以内进行相互参考(可以称为纵向参考)。

S103：根据所述业务点的热度表征值，对所述业务点所提供业务的关联业务进行处理。

在本申请实施例中，针对上述现有技术中的问题，根据业务点的热度表征值，可以给热度越高的业务点提供越多的处理资源，以用于处理该业务所提供业务的关联业务。

当然，根据热度表征值，除了可以分配用于处理关联业务的处理资源以外，还可以差异化地对热度不同的业务点执行其他动作，这些动作可以是处理关联业务的动作，也可以是其他任何与业务点相关的动作。

通过图1的方法，可以实现根据业务点的热度表征值，用相应数量的处理资源对业务点所提供业务的关联业务进行处理，热度表征值的高低可以间接地反映业务点对于关联业务处理的具体程度或者紧要程度的要求高低，因此，本申请的关联业务处理方法有利于减少处理资源浪费，可以部分或全部地解决现有技术中的问题。

基于图1的方法，本申请实施例还提供了该方法的一些具体实施方案，以及扩展方案，下面进行说明。

在本申请实施例中，如前所述，在实际应用中，可能存在业务点伪造其用户流量的情况，针对这种情况，提供了以下对应措施。具体地，对于步骤S102，所述确定所述业务点的热度表征值前，还可以执行：根据所述业务点所属类目的支付汇总数据和/或所述业务点的支付历史数据，确定所述业务点的支付数据可信取值区间。一般地，所述支付数据可信取值区间为所述业务点的支付数据实际取值区间的子区间。

在执行了上述对应措施的情况下，对于步骤S103，所述根据所述业务点的支付实时数据，以及保存的历史记录，确定所述业务点的热度表征值，具体可以包括：根据所述业务点的支付数据可信取值区间、所述业务点的支付实时数据，以及保存的历史记录，确定所述业务点的热度表征值。

进一步地，支付数据的不同具体属性对应于不同的支付数据(所述具体属性的)可信取值区间、以及不同的支付数据实际取值区间。

支付数据常用的具体属性有：单用户支付次数(指定时间范围内)、单次支付数额等；相应地，上述的支付数据可信取值区间、支付数据实际取值区间可以包括：单用户支付次数取值区间和/或单次支付数额取值区间等。

以支付数据是单次支付数额为例。在某天内，正餐餐馆A的支付数据实际取值区间为1元～2000元，而根据正餐餐馆类目的汇总支付数据，确定大部分正餐餐馆大多数用户单次支付数额都在50元～500元范围内，而正餐餐馆A以往的大多数用户单次支付数额也在50元～500元范围内，由此可以推定该天内快餐餐馆A的支付数据内可能存在异常数据，比如，可能存在每笔1元的刷单支付数据，还可能存在某个用户点了高价酒类，导致该用户的单次支付数额达到2000元，等等。

在这种情况下，可以确定正餐餐馆A的支付数据可信取值区间为50元～500元。在确定正餐餐馆A的热度表征值时，可以将其支付实时数据中取值在50元～500元以外的数据过滤掉后再采用。

在本申请实施例中，步骤S102可以有多种具体实施方式。列举两种作为示例。

第一种，可以分别为业务点的支付实时数据、业务点的支付历史数据、业务点所属类目的汇总支付数据设定对应的权重，以计算加权值作为热度表征值；

第二种，可以根据业务点的支付历史数据、业务点所属类目的汇总支付数据判断业务点的支付实时数据中是否存在异常数据，若有，则过滤掉异常数据，再根据过滤后的支付实时数据计算热度表征值，若无，则直接根据支付实时数据计算热度表征值。

在本申请实施例中，对于图1中的步骤S101，当在指定时间内(比如，最近的两小时内，或者最近的半天内等)获取到的所述业务点的支付实时数据均为空时，其原因很可能由于业务点处于不能正常提供业务的状态，比如，停业状态、下班状态等。在这种情况下，可以确定所述业务点的热度表征值为指定下限值(比如，将业务点的热度表征值确定为0等)，或者确定所述业务点的热度表征值为不可用，以防止该业务点浪费关联业务处理资源。

在本申请实施例中，对于步骤S102，所述确定所述业务点的热度表征值后，还可以执行：保存所述业务点的热度表征值，以及所述热度表征值的关联信息；所述热度表征值的关联信息包括以下至少一种：确定所述热度表征值时的时刻信息、所述业务点的地理位置信息、所述业务点所属类目信息。本申请对具体保存形式不做限定，一般可以以数据表的形式保存，当需要使用时可以通过索引或者关键词在数据表中检索得到所需数据。

进一步地，当保存有多个业务点的热度表征值，以及所述多个业务点的热度表征值的关联信息时，对于步骤S103，根据所述业务点的热度表征值，对所述业务点的关联业务进行处理，具体可以包括：获得针对业务点的热度表征值的关联信息的条件信息；从保存的所述多个业务点的热度表征值中筛选出与所述条件信息匹配的业务点的热度表征值；根据筛选出的业务点的热度表征值，对所述筛选出的业务点所提供业务的关联业务进行处理。

其中，所述条件信息可以是预设的，也可以是用户请求中指定的。

上面对本申请实施例提供的关联业务处理方法进行了详细说明。关联业务处理方法可以应用于多种实际场景，不仅可以解决现有技术中的问题，甚至还可能解决新问题。其中一种实际场景是店铺推荐的场景，下面对该实际场景下，关联业务处理方法的实施方案，及其可解决的问题进行说明。

在该实际场景下，上述的业务点具体为店铺，业务点所提供业务具体为店铺的商品售卖业务，关联业务具体为对店铺本身或对店铺所售卖商品的推荐业务，热度表征值具体为人气值(反映店铺受用户欢迎的程度)。

在该实际场景下，如背景技术所述，存在浪费关联业务的处理资源(也即，推荐业务处理资源)的问题。不仅如此，还存在其他问题，具体地，现有技术中进行店铺推荐时，往往采用以下两种方式：第一，基于历史排行榜推荐店铺，比如，上一个月的火锅店排行榜，上一年的热门美食店铺排行榜等；第二，提供店铺好评搜索，以及根据好评数量推荐。

但是，现有技术进行店铺推荐所基于的数据都是非实时的，时效性较差，不仅如此，前面也有提到，某些店铺会刷单，如此可能导致推荐所基于的数据可信度较差。本申请实施例基于上述关联业务处理方法同样的思路，提供了一种店铺推荐方法，可以部分或全部地解决这些问题，下面进行说明。

图2为本申请实施例提供的一种店铺推荐方法的流程示意图。从设备角度而言，该流程的执行主体可以包括但不限于以下设备：手机、平板电脑、智能手表、车机、个人计算机、大中型计算机、计算机集群等。从程序角度而言，该流程的执行主体可以是搭载于所述设备上的程序，比如，应用的服务端、客户端等。

图2中的流程可以包括以下步骤：

S201：获取店铺的支付实时数据。

S202：根据所述店铺的支付实时数据，以及保存的历史记录，确定所述店铺的人气值，所述历史记录包括所述店铺的支付历史数据，和/或所述店铺所属类目的支付汇总数据。

S203：根据所述店铺的人气值，对所述店铺进行推荐(也即，处理针对所述店铺所提供商品售卖业务的推荐业务)。

通过图2中的方法，可以实时地获得店铺当前的人气状态，时效性较好；而且，通过参考店铺所属类目的支付汇总数据，以及店铺的支付历史数据，可以识别出由刷单导致的异常数据，有利于提高确定出的人气值的可信度，因此，可以部分或全部地解决上述现有技术中的问题。

图2中的各步骤以及各步骤的具体方案、扩展方案是与图1相对应的，上面针对图1已经进行了详细阐述，因此，下面对于图2仅结合实例简单说明。

在本申请实施例中，对于步骤S202，所述确定所述店铺的人气值前，还可以执行：根据所述店铺所属类目的支付汇总数据和/或所述店铺的支付历史数据，确定所述店铺的支付数据可信取值区间。一般地，所述支付数据可信取值区间为所述店铺的支付数据实际取值区间的子区间。

相应地，对于步骤S203，所述根据所述店铺的支付实时数据，以及保存的历史记录，确定所述店铺的人气值，具体可以包括：根据所述店铺的支付数据可信取值区间、所述店铺的支付实时数据，以及保存的历史记录，确定所述店铺的人气值。

其中，支付实时数据、支付历史数据、支付汇总数据可以包括：单用户支付次数和/或单次支付数额等。相应地，支付数据可信取值区间、支付数据实际取值区间可以包括：单用户支付次数取值区间和/或单次支付数额取值区间。

例如，如下表1示出了一种实际应用场景下，确定出的某两个店铺的支付数据可信取值区间。

表1

在表1中，分别确定了“正餐店铺-001”、“水果店-002”的支付数据可信取值区间，其中，“用户单价范围”即为上述的单次支付数额取值区间，“其他规则”即为上述的单用户支付次数取值区间。

通过可信取值区间的限制，可以过滤掉诸如刷单数据等异常数据，有利于提高确定出的人气值的可信度和准确度。

在本申请实施例中，对于步骤S202，店铺所属类目的支付汇总数据具体可以是该类目下的各店铺交易的平均支付情况，为了提高本申请的方案的执行效率，步骤S202中的历史记录可以通过离线清洗的方式预先处理，如此以便于在执行步骤时S202时直接使用处理后的数据。

在本申请实施例中，当在指定时间内获取到的所述店铺的支付实时数据均为空时，对于步骤S202，所述确定所述店铺的人气值，具体可以包括：确定所述店铺的人气值为指定下限值，或者确定所述店铺的人气值为不可用。

比如，若某个店铺临时停业，则从该店铺临时停业起至恢复营业，获取到的该店铺的支付实时数据均为空，可以将该店铺的人气值确定为一个较低的值，相应地，可以暂时不对该店铺进行推荐，或者推荐排序尽量靠后，以免误导用户。而现有技术由于均是采用历史数据进行推荐，因此，对于这种情况会有滞后性，容易误导用户。

在本申请实施例中，对于步骤S202，所述确定所述店铺的人气值后，还可以执行：保存所述店铺的人气值，以及所述人气值的关联信息；所述人气值的关联信息包括以下至少一种类型：确定所述人气值时的时刻信息、所述店铺的地理位置信息、所述店铺所属类目信息。

例如，如下表2示出了一种实际应用场景，以数据表形式保存的店铺的人气值及其关联信息。

在表2中，具体保存在店铺1和店铺2在两个时刻对应的人气值及其关联信息。为了提高使用时的查询效率，还可以预先为数据表中的人气值和关联信息等建立索引。

从表2中可以看出，同一个店铺在不同时刻的人气值可能会有所不同，通常取决于店铺所售卖的商品。这种特点与日常经验是相符的，比如，早餐店在早8点～早10点的人气值会高一些，而烧烤店在晚上的人气值会高一些，因此，保存同一店铺在多个时刻的人气值有利于提高店铺推荐的便利性和准确性。

在本申请实施例中，当保存有多个店铺的人气值，以及所述多个店铺的人气值的关联信息时，对于步骤S203，所述根据所述店铺的人气值，对所述店铺进行推荐，具体可以包括：获得针对店铺的热度表征值的关联信息的条件信息；从保存的所述多个店铺的人气值中筛选出与所述条件信息匹配的店铺的人气值；根据筛选出的店铺的人气值推荐店铺。

具体推荐方式可以有多种，比较直观的形式是：生成各店铺的人气值排名推荐，或者生成人气值及其关联信息综合排名等，再将生成的排名展示给用户，以作为店铺推荐信息。

图3为本申请实施例提供的一种实际应用场景下，人气值及其关联信息综合排名生成方法的流程示意图。

用户在手机上查询附近某个类目的热门店铺，初始指定周边半径1千米，通过用户的查询操作，手机向服务端发送店铺推荐请求。

服务端根据用户当前的位置，从索引中查询用户指定周边半径内的热门店铺，若查询结果为空，则扩大指定周边半径至原来的2倍并重新查询，若查询结果不为空，则可以查询出多个属于该类目的热门店铺(人气值在指定阈值以上的店铺)，并可以根据查询出的各店铺的人气值以及人气值对应的时刻、地理位置信息等，对各店铺进行综合排名。

最后，服务端将排名发送给用户的手机进行展示。

进一步地，本申请实施例还提供了一种实际应用场景下，人气值及其关联信息综合排名在手机上展示的示意图，如图4所示。在图4中，用户查询的店铺类目是火锅店类目，手机上当前展示的排名中包含5个火锅店，依次为火锅店1～5，可以看到，排名优点考虑火锅店的人气值，当人气值相同，再考虑确定人气值的时刻信息，时刻越晚排名越高，此外，还考虑了火锅店与用户之间的距离。

需要说明的是，图4、图5中的方案仅是示例性的，并非对本申请的限定。

在本申请实施例中，上述店铺推荐方法可以在包含多个模块的系统中实现，本申请对该系统中模块功能的划分并不做限定。比如，该系统可以划分为4个模块：

店铺支付实时数据收集模块，用于获取店铺的支付实时数据，以及对支付实时数据进行过滤等；

人气值计算模块，用于实时地或定时地根据店铺的支付实时数据，以及保存的历史记录，计算店铺当前的人气值等；

人气值相关数据保存模块，用于保存人气值及其关联数据，以及为这些数据建立索引，响应针对这些数据的查询请求等；

人气值排名展示模块，用于基于店铺的人气值及其关联数据，对店铺进行排名以及展示，以推荐给用户。

上面对本申请实施例提供的关联业务处理方法、店铺推荐方法进行了说明，进一步地，本申请实施例还提供了对应的装置，如图5、图6所示。

图5为本申请实施例提供的对应于图1的一种关联业务处理装置的结构示意图，该装置可以位于图1中流程的执行主体上，包括：

获取模块501，获取业务点的支付实时数据；

确定模块502，根据所述业务点的支付实时数据，以及保存的历史记录，确定所述业务点的热度表征值，所述历史记录包括所述业务点的支付历史数据，和/或所述业务点所属类目的支付汇总数据；

处理模块503，根据所述业务点的热度表征值，对所述业务点所提供业务的关联业务进行处理。

可选地，所述确定模块502确定所述业务点的热度表征值前，根据所述业务点所属类目的支付汇总数据和/或所述业务点的支付历史数据，确定所述业务点的支付数据可信取值区间；

所述确定模块502根据所述业务点的支付实时数据，以及保存的历史记录，确定所述业务点的热度表征值，具体包括：

所述确定模块502根据所述业务点的支付数据可信取值区间、所述业务点的支付实时数据，以及保存的历史记录，确定所述业务点的热度表征值。

可选地，所述支付实时数据、所述支付历史数据、所述支付汇总数据包括：单用户支付次数和/或单次支付数额；

所述支付数据可信取值区间包括：单用户支付次数取值区间和/或单次支付数额取值区间。

可选地，当在指定时间内获取到的所述业务点的支付实时数据均为空时，所述确定模块502确定所述业务点的热度表征值，具体包括：

所述确定模块502确定所述业务点的热度表征值为指定下限值，或者确定所述业务点的热度表征值为不可用。

可选地，所述确定模块502确定所述业务点的热度表征值后，保存所述业务点的热度表征值，以及所述热度表征值的关联信息；

所述热度表征值的关联信息包括以下至少一种：确定所述热度表征值时的时刻信息、所述业务点的地理位置信息、所述业务点所属类目信息；

当保存有多个业务点的热度表征值，以及所述多个业务点的热度表征值的关联信息时，所述处理模块503根据所述业务点的热度表征值，对所述业务点的关联业务进行处理，具体包括：

所述处理模块503获得针对业务点的热度表征值的关联信息的条件信息，从保存的所述多个业务点的热度表征值中筛选出与所述条件信息匹配的业务点的热度表征值，根据筛选出的业务点的热度表征值，对所述筛选出的业务点所提供业务的关联业务进行处理。

图6为本申请实施例提供的对应于图2的一种店铺推荐装置的结构示意图，该装置可以位于图2中流程的执行主体上，包括：

获取模块601，获取店铺的支付实时数据；

确定模块602，根据所述店铺的支付实时数据，以及保存的历史记录，确定所述店铺的人气值，所述历史记录包括所述店铺的支付历史数据，和/或所述店铺所属类目的支付汇总数据；

推荐模块603，根据所述店铺的人气值，对所述店铺进行推荐。

可选地，所述确定模块602确定所述店铺的人气值前，根据所述店铺所属类目的支付汇总数据和/或所述店铺的支付历史数据，确定所述店铺的支付数据可信取值区间；

所述确定模块602根据所述店铺的支付实时数据，以及保存的历史记录，确定所述店铺的人气值，具体包括：

所述确定模块602根据所述店铺的支付数据可信取值区间、所述店铺的支付实时数据，以及保存的历史记录，确定所述店铺的人气值。

可选地，当在指定时间内获取到的所述店铺的支付实时数据均为空时，所述确定模块602确定所述店铺的人气值，具体包括：

所述确定模块602确定所述店铺的人气值为指定下限值，或者确定所述店铺的人气值为不可用。

可选地，所述确定模块602确定所述店铺的人气值后，保存所述店铺的人气值，以及所述人气值的关联信息；

所述人气值的关联信息包括以下至少一种类型：确定所述人气值时的时刻信息、所述店铺的地理位置信息、所述店铺所属类目信息；

当保存有多个店铺的人气值，以及所述多个店铺的人气值的关联信息时，所述推荐模块603根据所述店铺的人气值，对所述店铺进行推荐，具体包括：

所述推荐模块603获得针对店铺的热度表征值的关联信息的条件信息，从保存的所述多个店铺的人气值中筛选出与所述条件信息匹配的店铺的人气值，根据筛选出的店铺的人气值推荐店铺。

本申请实施例提供的装置、系统与方法是一一对应的，因此，装置、系统也具有与其对应的方法类似的有益技术效果，由于上面已经对方法的有益技术效果进行了详细说明，因此，这里不再赘述对应装置、系统的有益技术效果。

本申请实施例中所述支付涉及的技术载体，例如可以包括近场通信(Near FieldCommunication，NFC)、WIFI、3G/4G/5G、POS机刷卡技术、二维码扫码技术、条形码扫码技术、蓝牙、红外、短消息(Short Message Service，SMS)、多媒体消息(Multimedia MessageService，MMS)等。

在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)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

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

本领域技术人员应明白，本申请的实施例可提供为方法、系统或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

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

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

以上所述仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。

Claims

1.一种关联业务处理方法，其特征在于，包括：

获取业务点的支付实时数据，所述支付实时数据是对所述业务点提供业务进行支付产生的；

根据所述业务点的支付实时数据，以及保存的历史记录，确定所述业务点的热度表征值，所述历史记录包括所述业务点的支付历史数据，所述支付历史数据对应的时间区间比所述支付实时数据对应的时间区间更早；

根据所述业务点的热度表征值，向所述业务点提供处理资源，以用于对所述业务点所提供业务的关联业务进行处理；

在所述确定所述业务点的热度表征值前，所述方法还包括：

根据所述业务点所属类目的支付汇总数据和/或所述业务点的支付历史数据，确定所述业务点的支付数据可信取值区间；

所述根据所述业务点的支付实时数据，以及保存的历史记录，确定所述业务点的热度表征值，具体包括：

根据所述业务点的支付数据可信取值区间、所述业务点的支付实时数据，以及保存的历史记录，确定所述业务点的热度表征值；

其中，所述支付实时数据、所述支付历史数据、所述支付汇总数据包括：单用户支付次数和/或单次支付数额；

2.如权利要求1所述的方法，其特征在于，当在指定时间内获取到的所述业务点的支付实时数据均为空时，所述确定所述业务点的热度表征值，具体包括：

确定所述业务点的热度表征值为指定下限值，或者确定所述业务点的热度表征值为不可用。

3.如权利要求1所述的方法，其特征在于，所述确定所述业务点的热度表征值后，所述方法还包括：

保存所述业务点的热度表征值，以及所述热度表征值的关联信息；

当保存有多个业务点的热度表征值，以及所述多个业务点的热度表征值的关联信息时，所述根据所述业务点的热度表征值，对所述业务点的关联业务进行处理，具体包括：

获得针对业务点的热度表征值的关联信息的条件信息；

从保存的所述多个业务点的热度表征值中筛选出与所述条件信息匹配的业务点的热度表征值；

根据筛选出的业务点的热度表征值，对所述筛选出的业务点所提供业务的关联业务进行处理。

4.一种店铺推荐方法，其特征在于，包括：

获取店铺的支付实时数据，所述支付实时数据是对所述店铺提供业务进行支付产生的；

根据所述店铺的支付实时数据，以及保存的历史记录，确定所述店铺的人气值，所述历史记录包括所述店铺的支付历史数据，所述支付历史数据对应的时间区间比所述支付实时数据对应的时间区间更早；

根据所述店铺的人气值，向所述店铺提供推荐业务处理资源，以用于对所述店铺进行推荐；

在所述确定所述店铺的人气值前，所述方法还包括：

根据所述店铺所属类目的支付汇总数据和/或所述店铺的支付历史数据，确定所述店铺的支付数据可信取值区间；

所述根据所述店铺的支付实时数据，以及保存的历史记录，确定所述店铺的人气值，具体包括：

根据所述店铺的支付数据可信取值区间、所述店铺的支付实时数据，以及保存的历史记录，确定所述店铺的人气值；

5.如权利要求4所述的方法，其特征在于，当在指定时间内获取到的所述店铺的支付实时数据均为空时，所述确定所述店铺的人气值，具体包括：

确定所述店铺的人气值为指定下限值，或者确定所述店铺的人气值为不可用。

6.如权利要求4所述的方法，其特征在于，所述确定所述店铺的人气值后，所述方法还包括：

保存所述店铺的人气值，以及所述人气值的关联信息；

当保存有多个店铺的人气值，以及所述多个店铺的人气值的关联信息时，所述根据所述店铺的人气值，对所述店铺进行推荐，具体包括：

获得针对店铺的人气值的关联信息的条件信息；

从保存的所述多个店铺的人气值中筛选出与所述条件信息匹配的店铺的人气值；

根据筛选出的店铺的人气值推荐店铺。

7.一种关联业务处理装置，其特征在于，包括：

获取模块，获取业务点的支付实时数据，所述支付实时数据是对所述业务点提供业务进行支付产生的；

确定模块，根据所述业务点的支付实时数据，以及保存的历史记录，确定所述业务点的热度表征值，所述历史记录包括所述业务点的支付历史数据，所述支付历史数据对应的时间区间比所述支付实时数据对应的时间区间更早；

处理模块，根据所述业务点的热度表征值，向所述业务点提供处理资源，以用于对所述业务点所提供业务的关联业务进行处理；

在所述确定模块确定所述业务点的热度表征值前，根据所述业务点所属类目的支付汇总数据和/或所述业务点的支付历史数据，确定所述业务点的支付数据可信取值区间；

所述确定模块根据所述业务点的支付实时数据，以及保存的历史记录，确定所述业务点的热度表征值，具体包括：

所述确定模块根据所述业务点的支付数据可信取值区间、所述业务点的支付实时数据，以及保存的历史记录，确定所述业务点的热度表征值；

8.如权利要求7所述的装置，其特征在于，当在指定时间内获取到的所述业务点的支付实时数据均为空时，所述确定模块确定所述业务点的热度表征值，具体包括：

所述确定模块确定所述业务点的热度表征值为指定下限值，或者确定所述业务点的热度表征值为不可用。

9.如权利要求7所述的装置，其特征在于，所述确定模块确定所述业务点的热度表征值后，保存所述业务点的热度表征值，以及所述热度表征值的关联信息；

当保存有多个业务点的热度表征值，以及所述多个业务点的热度表征值的关联信息时，所述处理模块根据所述业务点的热度表征值，对所述业务点的关联业务进行处理，具体包括：

所述处理模块获得针对业务点的热度表征值的关联信息的条件信息，从保存的所述多个业务点的热度表征值中筛选出与所述条件信息匹配的业务点的热度表征值，根据筛选出的业务点的热度表征值，对所述筛选出的业务点所提供业务的关联业务进行处理。

10.一种店铺推荐装置，其特征在于，包括：

获取模块，获取店铺的支付实时数据，所述支付实时数据是对所述店铺提供业务进行支付产生的；

确定模块，根据所述店铺的支付实时数据，以及保存的历史记录，确定所述店铺的人气值，所述历史记录包括所述店铺的支付历史数据，所述支付历史数据对应的时间区间比所述支付实时数据对应的时间区间更早；

推荐模块，根据所述店铺的人气值，向所述店铺提供推荐业务处理资源，以用于对所述店铺进行推荐；

在所述确定模块确定所述店铺的人气值前，根据所述店铺所属类目的支付汇总数据和/或所述店铺的支付历史数据，确定所述店铺的支付数据可信取值区间；

所述确定模块根据所述店铺的支付实时数据，以及保存的历史记录，确定所述店铺的人气值，具体包括：

所述确定模块根据所述店铺的支付数据可信取值区间、所述店铺的支付实时数据，以及保存的历史记录，确定所述店铺的人气值；

11.如权利要求10所述的装置，其特征在于，当在指定时间内获取到的所述店铺的支付实时数据均为空时，所述确定模块确定所述店铺的人气值，具体包括：

所述确定模块确定所述店铺的人气值为指定下限值，或者确定所述店铺的人气值为不可用。

12.如权利要求10所述的装置，其特征在于，所述确定模块确定所述店铺的人气值后，保存所述店铺的人气值，以及所述人气值的关联信息；

当保存有多个店铺的人气值，以及所述多个店铺的人气值的关联信息时，所述推荐模块根据所述店铺的人气值，对所述店铺进行推荐，具体包括：

所述推荐模块获得针对店铺的人气值的关联信息的条件信息，从保存的所述多个店铺的人气值中筛选出与所述条件信息匹配的店铺的人气值，根据筛选出的店铺的人气值推荐店铺。