一种资源推荐方法以及装置与流程

本申请涉及数据处理技术领域，具体涉及一种资源推荐方法。本申请同时涉及一种资源推荐装置，以及一种基于用户端的资源推荐方法及装置。

背景技术：

随着网络技术的快速发展，越来越多的用户在就餐时选择通过智能手机等智能终端进行点餐，尤其是在用户旅游的过程中，用户在到达一个城市后，希望能够吃到这个城市最具有代表性或者最受欢迎的特色美食，但是对初次到达这个城市的用户来说，面对琳琅满目的菜品如何选择成为用户面临的挑战。

目前的菜品推荐方法，主要是根据餐馆、用户的位置、购买记录、浏览记录等历史数据信息分析得出用户的偏好，根据偏好挑选相应的菜品推荐给用户，但在旅游过程中，用户往往希望能够一次品尝到当地的多家美食，由于目前菜品与餐厅是绑定在一起的，不同菜品分布在不同的特色餐厅，因此用户需要分多次去不同的餐厅才能品尝到多家美食。并且菜品的评价是与餐厅的评价是相关的，但实际中菜品口味的好坏与厨师是直接相关的，与餐厅是间接的关系，如果厨师离开餐厅，则当前这个餐厅所提供菜品评价就没有太大实际意义，另一方面，对于厨师来说，离开餐厅后失去其菜品评价也存在一定的损失。

技术实现要素：

本申请提供一种资源推荐方法，以解决现有技术存在的缺陷。本申请同时涉及一种资源推荐装置，以及一种基于用户端的资源推荐方法及装置。

本申请提供一种资源推荐方法，包括：

获取用户端的地理位置；

确定从所述地理位置到资源消费节点需要的出行时间；

确定已选择的资源配送至所述资源消费节点需要的配送时间；

对所述资源消费节点对应的出行时间与配送时间进行比对；

根据比对结果向所述用户端推荐资源消费节点。

可选的，所述确定从所述地理位置到资源消费节点需要的出行时间，采用如下方式实现：

选择至少一个与所述地理位置的距离满足预设距离阈值的资源消费节点；

针对已选择的资源消费节点，执行如下操作：

确定所述地理位置与所述资源消费节点二者之间的路程；

根据所述路程确定从所述地理位置到资源消费节点需要的所述出行时间。

可选的，所述确定已选择的资源配送至所述资源消费节点需要的配送时间，采用如下方式确定：

针对已选择的资源消费节点，执行如下操作：

确定所述已选择的各个资源配送至所述资源消费节点的配送距离；

根据所述配送距离计算所述已选择的各个资源配送至所述资源消费节点各自需要的配送时间；

将所述配送时间的最大值作为所述资源全部配送至所述资源消费节点需要的配送时间。

可选的，所述对所述资源消费节点对应的出行时间与配送时间进行比对，采用如下方式实现：

对所述已选择的资源消费节点对应的出行时间和配送时间分别进行排序；

基于排序结果确定所述出行时间的最大值和最小值组成的出行时间区间，以及所述配送时间的最大值和最小值组成的配送时间区间；

判断所述出行时间区间与所述配送时间区间二者的时间范围是否存在重叠部分，若存在，执行所述根据比对结果向所述用户端推荐资源消费节点步骤。

可选的，所述根据比对结果向所述用户端推荐资源消费节点，采用如下方式实现：

计算所述资源消费节点的推荐系数；

从所述已选择的资源消费节点中筛选推荐系数满足预设推荐系数阈值的资源消费节点向所述用户端推荐，或者，按照所述推荐系数对所述已选择的资源消费节点进行排序并向所述用户端推荐。

可选的，所述资源消费节点的推荐系数，采用如下方式计算：

计算所述资源消费节点对应的出行时间与第一权重的比值，以及所述资源消费节点对应的出行时间和配送时间二者的最大值与第二权重的比值，将二者的比值之和作为所述资源消费节点的推荐系数。

可选的，如果存在至少两个推荐系数相等的资源消费节点，则优先向所述用户端推荐对应出行时间较短的资源消费节点。

可选的，若所述判断所述出行时间区间与所述配送时间区间二者的时间范围是否存在重叠部分子步骤的判断结果为否，执行如下操作：

判断所述出行时间的最大值是否小于或者等于所述配送时间的最小值，若是，执行所述根据比对结果向所述用户端推荐资源消费节点步骤。

可选的，所述根据比对结果向所述用户端推荐资源消费节点，采用如下方式实现：

优先将所述已选择的资源消费节点中对应的配送时间较短的资源消费节点向所述用户端推荐。

可选的，若所述判断所述出行时间的最大值是否小于或者等于所述配送时间的最小值子步骤的判断结果为否，执行如下操作：

判断所述出行时间的最小值是否大于所述配送时间的最大值，若是，执行所述根据比对结果向所述用户端推荐资源消费节点步骤。

可选的，所述根据比对结果向所述用户端推荐资源消费节点，采用如下方式实现：

优先将所述已选择的资源消费节点中与所述地理位置的距离较近的资源消费节点向所述用户端推荐。

可选的，所述对所述资源消费节点对应的出行时间与配送时间进行比对，采用如下方式实现：

对所述已选择的资源消费节点对应的出行时间和配送时间分别进行排序；

基于排序结果确定所述出行时间的最大值和最小值组成的出行时间区间，以及所述配送时间的最大值和最小值组成的配送时间区间；

判断所述出行时间区间与所述配送时间区间二者的时间范围是否存在重叠部分，若存在，执行所述根据比对结果向所述用户端推荐资源消费节点步骤；

或者，判断所述出行时间的最大值是否小于或者等于所述配送时间的最小值，若是，执行所述根据比对结果向所述用户端推荐资源消费节点步骤；

或者，判断所述出行时间的最小值是否大于所述配送时间的最大值，若是，执行所述根据比对结果向所述用户端推荐资源消费节点步骤。

可选的，所述获取用户端的地理位置步骤执行后，且所述确定从所述地理位置到资源消费节点需要的出行时间步骤执行前，执行如下操作：

生成通过预设资源地图展示所述地理位置、所述地理位置所属区域范围内的资源消费节点以及资源组成的资源集合的地图数据；

向所述用户端发送所述地图数据。

可选的，所述根据比对结果向所述用户端推荐资源消费节点步骤执行后，执行如下操作：

根据所述用户端在推荐的资源消费节点中选择的目标资源消费节点，生成订单并向所述用户端发送；

接收所述用户端提交的结算数据对所述订单进行结算；

生成将所述资源向所述资源消费节点的配送指令，和/或生成并向所述用户端发送前往所述目标资源消费节点的提醒消息；

接收所述用户端提交的针对所述资源和/或所述资源消费节点的评价。

本申请还提供一种资源推荐装置，包括：

地理位置获取单元，用于获取用户端的地理位置；

出行时间确定单元，用于确定从所述地理位置到资源消费节点需要的出行时间；

配送时间确定单元，用于确定已选择的资源配送至所述资源消费节点需要的配送时间；

比对单元，用于对所述资源消费节点对应的出行时间与配送时间进行比对；

资源消费节点推荐单元，用于根据比对结果向所述用户端推荐资源消费节点。

本申请另外提供一种基于用户端的资源推荐方法，包括：

向服务端上传所处的地理位置；

接收所述服务端下发的所述地理位置所属区域范围内的资源集合；

向所述服务端提交在所述资源集合中选择的至少一个资源；

接收所述服务端推荐的资源消费节点。

可选的，所述接收所述服务端下发的所述地理位置所属区域范围内的资源集合步骤执行后，且所述向所述服务端提交在所述资源集合中选择的至少一个资源步骤执行前，执行如下操作：

接收用户针对所述资源集合发出的地图展示指令；

根据所述地图展示指令，通过资源地图展示所述地理位置以及所述地理位置所属区域范围内资源集合中的所有资源；

接收所述用户在所述资源地图展示的所述资源集合中的至少一个资源。

可选的，所述接收所述服务端推荐的资源消费节点步骤执行后，执行如下操作：

通过所述资源地图展示所述服务端推荐的资源消费节点；

接收所述用户在所述资源地图展示的资源消费节点中选择的资源消费节点；

向所述服务端发送所述用户已选择的资源消费节点。

可选的，所述接收所述服务端推荐的资源消费节点步骤执行后，执行如下操作：

接收所述服务端发送的订单；

针对接收到的订单进行结算，向所述服务端提交结算数据；

接收所述服务端发送的前往所述目标资源消费节点的提醒消息；

将所述用户提交的针对所述资源和/或所述资源消费节点的评价向所述服务端发送。

本申请另外提供一种基于用户端的资源推荐装置，包括：

地理位置上传单元，用于向服务端上传所处的地理位置；

资源集合下发单元，用于接收所述服务端下发的所述地理位置所属区域范围内的资源集合；

已选择资源提交单元，用于向所述服务端提交在所述资源集合中选择的至少一个资源；

资源消费节点接收单元，用于接收所述服务端推荐的资源消费节点。

本申请提供的所述资源推荐方法，包括：获取用户端的地理位置；确定从所述地理位置到资源消费节点需要的出行时间；确定已选择的资源配送至所述资源消费节点需要的配送时间；对所述资源消费节点对应的出行时间与配送时间进行比对；根据比对结果向所述用户端推荐资源消费节点。

所述资源推荐方法，在资源与资源消费节点解耦模式下，用户可自行选择资源和资源消费节点，选择更加灵活，为用户提供了方便；并通过确定用户到资源消费节点的需要的出行时间以及资源配送至资源消费节点需要的配送时间，在综合出行时间和配送时间的基础上进行推荐，使用户、资源、资源消费节点三者之间达到最优的平衡，在此基础上进行推荐更加精准和人性化。

附图说明

附图1是本申请提供的一种资源推荐方法实施例的处理流程图；

附图2是本申请提供的一种资源推荐场景的示意图；

附图3是本申请提供的一种资源推荐装置的示意图；

附图4是本申请提供的一种基于用户端的资源推荐方法实施例的处理流程图；

附图5是本申请提供的一种基于用户端的资源推荐装置的示意图。

具体实施方式

在下面的描述中阐述了很多具体细节以便于充分理解本申请。但是本申请能够以很多不同于在此描述的其他方式来实施，本领域技术人员可以在不违背本申请内涵的情况下做类似推广，因此本申请不受下面公开的具体实施的限制。

本申请提供一种资源推荐方法，本申请还提供一种资源推荐装置，以及一种基于用户端的资源推荐方法及装置。以下分别结合本申请提供的实施例的附图逐一进行详细说明。

本申请提供的一种资源推荐方法实施例如下：

参照附图1，其示出了本申请提供的一种资源推荐方法实施例的处理流程图，参照附图2，其示出了本申请提供的一种资源推荐场景的示意图。

步骤s101，获取用户端的地理位置。

本申请提供的所述资源推荐方法，提供一种新的资源生产者与资源消费场所(资源消费节点)解耦模式，一般而言，资源生产者与资源的关系是固定的，因此，资源生产者与资源消费节点解耦模式也可以看作是资源与资源消费节点解耦模式。以餐饮领域为例，资源指的是菜品资源，资源生产者指的是烹饪菜品的厨师，而用于进行资源消费的资源消费节点指的是向用户提供就餐服务的餐厅。需要说明的是，此处的“餐厅”仅仅是指就餐场所，而并非一般意义的即由厨师提供菜品又提供就餐服务的餐厅，下文提到的餐厅均是指就餐场所。相应的，资源生产者与资源消费节点解耦模式是指将厨师与餐厅的绑定关系解除，即：厨师与餐厅解耦模式；而实际中厨师与菜品二者之间的关系往往是固定的，因此，厨师与餐厅解耦模式也可以看作是菜品与餐厅解耦模式。

在菜品与餐厅解耦模式下，厨师不固定在餐厅，而是作为一个工厂端存在生产拿手的特色菜品，生产好的菜品被配送至餐厅供用户品尝；同时，餐厅不需要厨师，仅提供用餐服务(比如点餐服务、服务员、水、菜品加热等)和场地环境。用户根据菜品推荐榜单等方式选择自己喜欢的菜品，并根据评价和距离自行选择就餐的餐厅，用户选择的菜品由厨师生产完成后配送至用户选择的餐厅，由餐厅为用户安排位置就餐。在菜品与餐厅解耦模式下，用户不仅可以自行选择菜品，还可以自行选择就餐地点，选择更加灵活，用户就餐也更加方便和人性化。同时，在菜品与餐厅解耦模式下，用户对餐厅的评价体现餐厅的服务质量，用户对菜品的评价直接与厨师关联，评价更加精准。然而，在菜品与餐厅解耦模式下向用户推荐菜品或者餐厅时，不仅要考虑用户与餐厅之间的距离，还要兼顾菜品配送至餐厅的距离和时间，以及菜品和餐厅的评价，针对这种情况，通过本申请提供的所述资源推荐方法，实现在菜品与餐厅解耦模式下菜品或者餐厅的推荐。

本申请提供的所述资源推荐方法，即可以在服务端实现，也可以在用户端实现，还可以在云端实现。所述资源推荐方法在服务端实现时，与本申请提供的下述基于用户端的资源推荐方法相互配合。类似的，当所述资源推荐方法在云端实现时，同样可与本申请提供的下述基于用户端的资源推荐方法相互配合。

本申请提供的一种优选实施方式中，以菜品与餐厅解耦模式下的餐厅推荐为例，对本申请提供的所述资源推荐方法进行说明。在具体实现过程中，首先获取用户端的地理位置。该地理位置可以通过用户随身携带的智能手机等移动终端内置的定位装置来确定，比如用户旅游途径城市c，打开生活服务类app选择当地特色菜品就餐时，通过智能手机获取实时的地理位置，生活服务类app会向用户端推送该地理位置所在的城市c的菜品，比如根据菜品的评价、价格、热度以及菜品的月消费次数等，通过推荐榜单等方式向用户端推送推荐展示城市c的菜品，例如城市c的菜品榜单展示如下：

top1.李厨师的古法烤茄子人气指数10000(近7日统计)

top2.张老师的糖醋里脊人气指数9000

top3.xxx的aaa人气指数1000

······

用户端基于上述菜品榜单选择好菜品之后(可理解为将菜品加入生活服务类app的购物车)，可结合菜品配送至餐厅的时间以及用户前往餐厅所需时间(即：从用户端所处的地理位置到餐厅需要的时间)，推荐合适的餐厅供用户品尝。如附图2所示，用户端在城市c中的地理位置为p，用户通过用户端选择的菜品包括：a1、a2和a3。

除此之外，上述地理位置还可由用户指定，主要应用于预约就餐的场景，比如用户未来某天会途径城市c，可通过生活服务类app提前预约该城市的地方特色菜品，并根据在该城市预定酒店的地理位置，选择预定酒店附近的餐厅就餐。

本申请提供的另一种优选实施方式中，确定用户端所处的地理位置后，还可通过预设城市地图来展示所述地理位置、所述地理位置所属区域范围内的餐厅以及特色菜品，用户可通过用户端在城市地图中选择想要品尝的当地特色菜品，同时也可在城市地图当中选择就餐进行餐厅。具体在实施时，生成通过预设城市地图展示所述地理位置、所述地理位置所属城市内的特色菜品的地图数据，并将生成的地图数据向用户端，在用户端通过地图的方式展示所述地理位置所属城市内的特色菜品，使用户能够更加直观的观察菜品与其所处地理位置之间的距离，从而为用户选择菜品提供方便。

步骤s102，确定从所述地理位置到资源消费节点需要的出行时间。

上述步骤s101确定用户端的地理位置，本步骤在此基础上确定从所述地理位置到餐厅需要的出行时间。本申请提供的一种优选实施方式中，通过如下方式确定从所述地理位置到餐厅需要的出行时间：

选择至少一个与所述地理位置的距离满足预设距离阈值的餐厅；

针对已选择的每个餐厅，执行如下操作：确定所述地理位置与所述餐厅二者之间的路程；根据所述路程确定从所述地理位置到餐厅需要的所述出行时间。

本申请实施例所述已选择的餐厅，可以由用户通过用户端来主动选择，比如用户通过用户端手动在城市c中选择一个或者多个可能回去的就餐地点；此外，还可以根据用户端所处的地理位置p，将与地理位置p的距离小于5km的所有餐厅都作为已选择的餐厅，或者将当前所在城市c中的所有餐厅作为已选择的餐厅。

如附图2所示，已选择的餐厅包括：s1、s2、s3和s4，计算地理位置p与餐厅s1、s2、s3和s4之间距离分别为：ps1、ps2、ps3和ps4，根据用户的出行方式(步行或者驾车等方式)计算从地理位置p前往餐厅s1、s2、s3和s4所需的时间分别为：ps_t1、ps_t2、ps_t3和ps_t4。

步骤s103，确定已选择的资源配送至所述资源消费节点需要的配送时间。

本申请提供的一种优选实施方式中，确定已选择的菜品配送至所述已选择的餐厅需要的配送时间，具体实现如下：

针对已选择的每个餐厅，执行如下操作：确定已选择的各个菜品配送至所述餐厅的配送距离；根据所述配送距离计算已选择的各个菜品配送至所述餐厅各自需要的配送时间；将所述配送时间的最大值作为所述菜品全部配送至所述餐厅需要的配送时间。

如附图2所示，用户通过用户端在城市c中选择的菜品包括：a1、a2和a3，其中，菜品a1、a2和a3配送至餐厅s1各自的配送距离分别为：a1s1、a2s1和a3s1，配送时间分别为：a1s1_t、a2s1_t和a3s1_t，由于a2s1_t>a3s1_t>a1s1_t，可见，菜品a3最后一个配送至餐厅s1，则所有菜品都到达餐厅s1所需时间为菜品a1、a2和a3各自对应配送时间的最大值为a2s1_t，即：所有菜品在餐厅s1配齐所需的配送时间为：a2s1_t。类似的，菜品a1、a2和a3配送至餐厅s2配送时间排序为：a3s2_t>a1s2_t>a2s2_t，则所有菜品在餐厅s2配齐所需的配送时间为：a3s2_t。菜品a1、a2和a3配送至餐厅s3配送时间排序为：a2s3_t>a1s3_t>a3s3_t，则所有菜品在餐厅s3配齐所需的配送时间为：a2s3_t。菜品a1、a2和a3配送至餐厅s4配送时间排序为：a1s4_t>a2s4_t>a3s4_t，则所有菜品在餐厅s4配齐所需的配送时间为：a1s4_t。

需要说明的是，上述实施方式计算配送时间的过程中并未考虑菜品烹饪所需要的烹饪时间，这样计算的前提是：工厂端的厨师的加工时间尽可能的短，对于厨师而言，如果只做拿手的菜，食材都是提前预备好的，实际烹饪时间比较短。但在本申请提供的另一种优选实施方式中，在计算所述配送时间的过程中，还可以将菜品的烹饪时间也加入考量因素，每个菜品配送至餐厅需要的总配送时间等于配送时间与烹饪时间二者之和。此外，为了确保用户用餐质量，还可以加入菜品时效的检测操作，判断每个菜品配送至餐厅需要的总配送时间是否超出预先设定的时效阈值，如果没有超出时效阈值，则直接配送即可；如果超出时效阈值，可能是当前菜品的烹饪时间比较长，或者当前菜品距离餐厅较远，如果菜品的总配送时间较长，一方面可能影响菜品的口感，另一方面，如果用户在餐厅等待菜品的时间较长，而这两个方面都会导致用户就餐体验不佳，因此，如果菜品的总配送时间超出预先设定的时效阈值，可通过用户端提醒用户或者将当前菜品从已选择的菜品中剔除。

步骤s104，对所述资源消费节点对应的出行时间与配送时间进行比对。

本申请提供的一种优选实施方式中，对所述餐厅对应的出行时间与配送时间进行比对，具体实现如下：

对所述已选择的餐厅对应的出行时间和配送时间分别进行排序；

基于排序结果确定所述出行时间的最大值和最小值组成的出行时间区间，以及所述配送时间的最大值和最小值组成的配送时间区间；

判断所述出行时间区间与所述配送时间区间二者的时间范围是否存在重叠部分，若存在，执行下述步骤s105，根据比对结果向所述用户端推荐餐厅；若不存在，执行如下操作：

判断所述出行时间的最小值是否大于所述配送时间的最大值，若大于，执行下述步骤s105，根据比对结果向所述用户端推荐餐厅；若不大于，判断所述出行时间的最小值是否大于所述配送时间的最大值，若是，执行下述步骤s105，根据比对结果向所述用户端推荐餐厅；若否，不作处理即可。

例如，对餐厅s1、s2、s3和s4各自对应的出行时间排序如下：ps_t1<ps_t2<ps_t4<ps_t3，其最大值和最小值组成的出行时间区间为：【ps_t1，ps_t3】；对餐厅s1、s2、s3和s4对应的配送时间排序如下：a2s1_t>a2s3_t>a3s2_t>a1s4_t，其最大值和最小值组成的配送时间区间为：【a1s4_t，a2s1_t】，并对获得的出行时间区间和配送时间区间进行比对，比对结果分为如下三种：出行时间区间与配送时间区间二者的时间范围存在重叠部分，出行时间的最大值小于或者等于配送时间的最小值，以及出行时间的最小值大于配送时间的最大值。

除此之外，本申请提供的另一种优选实施方式中，还可采用下述提供的任意一种实现方式或者任意两种实现方式的结合，实现对所述餐厅对应的出行时间与配送时间进行比对：

1)对所述已选择的餐厅对应的出行时间和配送时间分别进行排序；

基于排序结果确定所述出行时间的最大值和最小值组成的出行时间区间，以及所述配送时间的最大值和最小值组成的配送时间区间；

判断所述出行时间区间与所述配送时间区间二者的时间范围是否存在重叠部分，若是，执行下述步骤s105，根据比对结果向所述用户端推荐餐厅。

2)判断所述出行时间的最大值是否小于或者等于所述配送时间的最小值，若是，执行下述步骤s105，根据比对结果向所述用户端推荐餐厅。

3)判断所述出行时间的最小值是否大于所述配送时间的最大值，若是，执行下述步骤s105，根据比对结果向所述用户端推荐餐厅。

步骤s105，根据比对结果向所述用户端推荐资源消费节点。

本步骤根据上述步骤s104对所述餐厅对应的出行时间与配送时间进行比对的比对结果，向用户端推荐餐厅。本申请提供一种优选实施方式中，该优选实施方式在上述步骤s104提供的第一种优选实施方式的基础上实现。以下分别针对上述步骤s104中对所述出行时间区间与所述配送时间区间进行比对获得的三种比对结果进行说明：

第一种：如果所述出行时间区间与所述配送时间区间二者的时间范围存在重叠部分，则本步骤根据比对结果向用户端推荐所述餐厅具体实现如下：

计算所述餐厅的推荐系数；

从所述已选择的餐厅中筛选推荐系数满足预设推荐系数阈值的餐厅向所述用户端推荐，或者，按照所述推荐系数对所述已选择的餐厅进行排序并向所述用户端推荐。其中，所述餐厅对应的出行时间对应的出行时间与第一权重的比值，所述餐厅对应的出行时间和配送时间二者的最大值与第二权重的比值，二者的比值之和为所述餐厅的推荐系数。

例如，出行时间区间【ps_t1，ps_t3】与配送时间区间【a1s4_t，a2s1_t】二者存在重叠部分，即：a1s4_t<ps_t1<a2s1_t，或者a1s4_t<ps_t3<a2s1_t，此时，分别计算每一个餐厅的推荐系数：餐厅s1的推荐系数choice(s1)＝(0.3/ps_t1)+(0.7/max(ps_t1，a2s1_t))，餐厅s2的推荐系数choice(s2)＝(0.3/ps_t2)+(0.7/max(ps_t2，a3s2_t))，餐厅s3的推荐系数choice(s3)＝(0.3/ps_t3)+(0.7/max(ps_t3，a2s3_t))，餐厅s4的推荐系数choice(s4)＝(0.3/ps_t4)+(0.7/max(ps_t4，a1s4_t))。

上述推荐系数与已选择的菜品配送至餐厅的时间和用户到餐厅的时间成反比，菜品配送至餐厅的时间和用户到餐厅的时间越大，计算获得的推荐系数越小，这种情况对用户来说不是最优选择；反之，菜品配送至餐厅的时间和用户到餐厅的时间越小，计算获得的推荐系数越大，这种情况下，用户可以较快的品尝到相应菜品，因此是优选的推荐方式。在具体实施时，可以根据上述推荐系数的计算结果，向用户端推荐推荐系数最高的3个餐厅供用户挑选；此外，还可以根据上述推荐系数的计算结果对餐厅进行排序，按照推荐系数从大到小的顺序进行排序，优先向用户端推荐展示推荐系数较大的餐厅。

此外，在计算所述餐厅的推荐系数时，还可以考虑餐厅的评价和/或菜品的评价，比如，通过计算所述餐厅对应的出行时间与对应权重的比值、配送时间与对应权重的比值以及所述餐厅的评价与对应权重的比值之和，作为所述餐厅的推荐系数。

需要说明的是，在上述推荐系数的计算过程中，如果存在至少两个推荐系数相等的餐厅，则优先向用户端推荐对应的出行时间较短的餐厅，即：优先向用户端推荐距离较近的餐厅。例如，假设用户通过用户端选择了一个菜品a和两个餐厅s1和s2，菜品a配送至餐厅s1的配送时间为20min，用户从用户端所处的地理位置到餐厅s1所需的出行时间为10min，菜品a配送至餐厅s2的配送时间为10min，用户到餐厅s2所需的出行时间为20min，在这种情况下，由于用户到餐厅s1的时间明显比到餐厅s2的时间短，因此优先向用户端推荐到达所需要的时间比较短的餐厅，即餐厅s1。

第二种：如果所述出行时间的最大值小于或者等于所述配送时间的最小值，即：所述出行时间区间的上限值小于或者等于所述配送时间区间的下限值，例如，ps_t3<＝a1s4_t，表明用户到达任意一个餐厅的时间均小于用户选择的所有菜品被配送至该餐厅的时间，实际情形可能是用户端所处的地理位置距离所有的餐厅都比较近，即使选择距离最远的餐厅就餐，也比用户选择的菜品在该餐厅配齐所用的时间短。在这种情况下，根据比对结果向用户端推荐所述餐厅可采用如下方式实现：优先将所述已选择的餐厅中对应的配送时间较短的餐厅向所述用户端推荐，即向用户端推荐菜品全部配送至餐厅所用时间比较短的餐厅，从而来缩短用户在餐厅的等待时间，提升用户的就餐体验。

第三种：如果所述出行时间的最小值大于所述配送时间的最大值，例如，ps_t1>a2s1_t，即：所述出行时间区间的下限值大于所述配送时间区间的上限值，表明用户到达任意一个餐厅的时间均大于已选择的所有菜品被配送至该餐厅的时间，实际情形可能是用户端所处的地理位置距离所有的餐厅都比较远，而菜品的生成地点集中在餐厅附近，不管选择哪个餐厅进行就餐，已选择的菜品也会在用户到达之前配齐。在这种情况下，根据比对结果向用户端推荐所述餐厅可采用如下方式实现：优先向用户端推荐与其地理位置的距离较近的餐厅，从而使用户能尽快到达餐厅就餐，进一步提升用户的就餐体验。

对于一个生活服务类app而言，在执行完上述步骤s101至步骤s105之后，实际并未完成最后的生成订单和结算操作，只是根据用户在购物车中添加的菜品，向用户端推荐了最优的就餐餐厅，而在此基础上，本申请提供的另一种优选实施方式中，用户通过用户端从推荐的餐厅中选定就餐的目标餐厅后，生成相应的订单并向用户端发送，生成的订单中包含每个菜品的数目和价格，还可能包含每个菜品的配送费用以及配送时间，此后，根据接收到的用户端提交的结算数据对所述订单进行结算，订单结算完成之后，会根据订单中计算的配送时间向资源的生产者发生配送指令，并同时向用户端发送相应提醒，提醒用户前往目标餐厅就餐，就餐完成后，还可以通过用户端接收用户针对菜品和/或当前就餐的目标餐厅的评价。

综上所述，所述资源推荐方法在菜品与餐厅解耦模式下，用户可通过用户端可自行选择菜品和餐厅，选择更加灵活，为用户提供了方便；并通过确定用户到餐厅的需要的出行时间以及菜品配送至餐厅需要的配送时间，在综合出行时间和配送时间的基础上进行推荐，使用户、菜品、餐厅三者之间达到最优的平衡，在此基础上进行推荐更加精准和人性化，提升了用户的就餐体验。

本申请提供的一种资源推荐装置实施例如下：

在上述的实施例中，提供了一种资源推荐方法，与之相对应的，本申请还提供了一种资源推荐装置，下面结合附图进行说明。

参照附图3，其示出了本申请提供的一种资源推荐装置实施例的示意图。

由于装置实施例基本相似于方法实施例，所以描述得比较简单，相关的部分请参见上述提供的方法实施例的对应说明即可。下述描述的装置实施例仅仅是示意性的。

本申请提供一种资源推荐装置，包括：

地理位置获取单元301，用于获取用户端的地理位置；

出行时间确定单元302，用于确定从所述地理位置到资源消费节点需要的出行时间；

配送时间确定单元303，用于确定已选择的资源配送至所述资源消费节点需要的配送时间；

比对单元304，用于对所述资源消费节点对应的出行时间与配送时间进行比对；

资源消费节点推荐单元305，用于根据比对结果向所述用户端推荐资源消费节点。

可选的，所述出行时间确定单元302，包括：

资源消费节点选择子单元，用于选择至少一个与所述地理位置的距离满足预设距离阈值的资源消费节点；

以及针对已选择的资源消费节点运行的路程确定子单元和出行时间确定子单元；

其中，所述路程确定子单元，用于确定所述地理位置与所述资源消费节点二者之间的路程；

所述出行时间确定子单元，用于根据所述路程确定从所述地理位置到资源消费节点需要的所述出行时间。

可选的，所述配送时间确定单元303，包括：

针对已选择的资源消费节点运行的配送距离确定子单元、配送时间计算子单元以及配送时间确定子单元；

其中，所述配送距离确定子单元，用于确定所述已选择的各个资源配送至所述资源消费节点的配送距离；

所述配送时间计算子单元，用于根据所述配送距离计算所述已选择的各个资源配送至所述资源消费节点各自需要的配送时间；

所述配送时间确定子单元，用于将所述配送时间的最大值作为所述资源全部配送至所述资源消费节点需要的配送时间。

可选的，所述比对单元304，包括：

排序子单元，用于对所述已选择的资源消费节点对应的出行时间和配送时间分别进行排序；

时间区间确定子单元，用于基于排序结果确定所述出行时间的最大值和最小值组成的出行时间区间，以及所述配送时间的最大值和最小值组成的配送时间区间；

时间范围判断子单元，用于判断所述出行时间区间与所述配送时间区间二者的时间范围是否存在重叠部分，若存在，运行所述资源消费节点推荐单元305。

可选的，所述资源消费节点推荐单元305，包括：

推荐系数计算子单元，用于计算所述资源消费节点的推荐系数；

第一推荐子单元，用于从所述已选择的资源消费节点中筛选推荐系数满足预设推荐系数阈值的资源消费节点向所述用户端推荐，或者，按照所述推荐系数对所述已选择的资源消费节点进行排序并向所述用户端推荐。

可选的，所述资源消费节点的推荐系数，采用如下方式计算：计算所述资源消费节点对应的出行时间与第一权重的比值，以及所述资源消费节点对应的出行时间和配送时间二者的最大值与第二权重的比值，将二者的比值之和作为所述资源消费节点的推荐系数。

可选的，如果存在至少两个推荐系数相等的资源消费节点，则优先向所述用户端推荐对应出行时间较短的资源消费节点。

可选的，若所述时间范围判断子单元输出的判断结果为所述出行时间区间与所述配送时间区间二者的时间范围不存在重叠部分，运行第一时间判断子单元；其中，所述第一时间判断子单元，用于判断所述出行时间的最大值是否小于或者等于所述配送时间的最小值，若是，运行所述资源消费节点推荐单元305。

可选的，所述资源消费节点推荐单元305，包括：

第二推荐子单元，用于优先将所述已选择的资源消费节点中对应的配送时间较短的资源消费节点向所述用户端推荐。

可选的，若所述第一时间判断子单元输出的判断结果为所述出行时间的最大值大于所述配送时间的最小值运行第二时间判断子单元；其中，所述第二时间判断子单元，用于判断所述出行时间的最小值是否大于所述配送时间的最大值，若是，运行所述资源消费节点推荐单元305。

可选的，所述资源消费节点推荐单元305，包括：

第三推荐子单元，用于优先将所述已选择的资源消费节点中与所述地理位置的距离较近的资源消费节点向所述用户端推荐。

可选的，所述资源推荐装置，包括：

地图数据生成单元，用于生成通过预设资源地图展示所述地理位置、所述地理位置所属区域范围内的资源消费节点以及资源组成的资源集合的地图数据；

地图数据发送单元，用于向所述用户端发送所述地图数据。

可选的，所述资源推荐装置，包括：

订单生成单元，用于根据所述用户端在推荐的资源消费节点中选择的目标资源消费节点，生成订单并向所述用户端发送；

订单结算单元，用于接收所述用户端提交的结算数据对所述订单进行结算

执行提醒单元，用于生成将所述资源向所述资源消费节点的配送指令，和/或生成并向所述用户端发送前往所述目标资源消费节点的提醒消息；

接收评价单元，用于接收所述用户端提交的针对所述资源和/或所述资源消费节点的评价。

本申请提供的一种基于用户端的资源推荐方法实施例如下：

在上述的实施例中，提供了一种资源推荐方法，除此之外，本申请还提供了一种基于用户端的资源推荐方法，与所述资源推荐方法相互配合。下面结合附图进行说明。

参照附图4，其示出了本申请提供的一种基于用户端的资源推荐方法实施例的处理流程图。

由于本实施例与上述提供的所述资源推荐方法实施例相互配合，所以描述得比较简单，相关的部分请参见上述提供的所述资源推荐方法实施例的对应说明即可。下述描述的基于用户端的资源推荐方法实施例仅仅是示意性的。

本申请提供的一种基于用户端的资源推荐方法实施例如下：

步骤s401，向服务端上传所处的地理位置。

本申请提供的所述基于用户端的资源推荐方法基于用户端实现，上述实施例提供的所述资源推荐方法基于服务端实现，用户端与服务端二者在实现过程中相互配合。

本实施例中，以汽车维修保养领域为例对所述基于用户端的资源推荐方法进行说明，在汽车维修保养所需的配件与维修保养场所的解耦模式下，用户可自行选择维修保养所需的配件，还可以自行选择选择维修保养的地点或者门店，例如用户选择保养汽车所需的配件，并选择在住所附近的门店进行保养，选择好配件和门店之后，用户所选配件被配送到门店，用户驱车前往门店即可进行汽车保养。

在实际应用中，所述基于用户端的资源推荐方法并不限于汽车维修保养领域，还可以应用于其他领域，比如按摩理发等服务领域，对提供按摩理发的技师与按摩理发门店二者进行解耦，在这种解耦模式下，用户可根据评价自行选择技师进行服务，还可以自行选择门店，选择好技师和门店后，技师会在规定时间内赶往门店，用户前往门店即可。

本步骤中，用户端首先获取其当前所处的地理位置，实际中用户端与用户往往是同时存在的，用户端所处的地理位置也可以理解为用户当前所处的地理位置，用户端获取到所述地理位置后，将获取到的地理位置上传至所述服务端。

步骤s402，接收所述服务端下发的所述地理位置所属区域范围内的资源集合。

上述步骤s401将所述地理位置上传至服务端之后，服务端要做的工作是根据用户端上传的所述地理位置，向用户端推动或者下面该地理位置所属区域范围内的资源集合，比如用户端当前所处地理位置所处的区域范围时城市c，则通过推荐榜单的方式向用户端推送城市c评价、热度或者销量比较高的汽车维修保养所需配件清单。

本申请提供的一种优选实施方式中，本步骤接收到所述服务端下发的所述地理位置所属区域范围内的配件清单之后，并且在下述步骤s403执行前，执行如下操作：接收用户针对所述配件清单发出的地图展示指令；根据所述地图展示指令，通过地图的方式展示所述地理位置以及所述地理位置所属区域范围内配件清单中的所有配件；接收所述用户在地图的方式展示的所述配件清单中的至少一个配件。

步骤s403，向所述服务端提交在所述资源集合中选择的至少一个资源。

用户端在接收到服务端推送的汽车维修保养所需配件的榜单数据之后，想用户展示该汽车维修保养所需配件的榜单，用户可在榜单中选择合适的配件并加入购物车，由用户端将用户选择的配件提交至服务端，由服务端根据用户选择的配件进行分析计算，分析计算的目的是向用户推荐合适的汽车维修保养门店，服务端根据地理位置和用户已选择的配件进行分析计算的过程请参见上述提供的所述资源推荐方法实施例，在此不再赘述。

步骤s404，接收所述服务端推荐的资源消费节点。

本申请提供的一种优选实施方式中，本步骤接收到所述服务端推荐的汽车维修保养门店后，执行如下操作：通过地图的方式展示所述服务端推荐的汽车维修保养门店；接收所述用户在地图的方式的汽车维修保养门店中选择的门店；向所述服务端发送所述用户已选择的汽车维修保养门店。

此外，本申请提供的另一种优选实施方式中，本步骤接收到所述服务端推荐的汽车维修保养门店后，执行如下操作：接收所述服务端发送的订单；针对接收到的订单进行结算，向所述服务端提交结算数据；接收所述服务端发送的前往所述汽车维修保养门店的提醒消息；将所述用户提交的针对所述配件和/或所述汽车维修保养门店的评价向所述服务端发送。

本申请提供的一种基于用户端的资源推荐装置实施例如下：

在上述的实施例中，提供了一种基于用户端的资源推荐方法，与之相对应的，本申请还提供了一种基于用户端的资源推荐装置，下面结合附图进行说明。

参照附图5，其示出了本申请提供的一种基于用户端的资源推荐装置实施例的示意图。

由于装置实施例基本相似于方法实施例，相关的部分请参见上述提供的基于用户端的资源推荐方法实施例的对应说明即可。下述描述的装置实施例仅仅是示意性的。

本申请提供一种基于用户端的资源推荐装置，包括：

地理位置上传单元501，用于向服务端上传所处的地理位置；

资源集合下发单元502，用于接收所述服务端下发的所述地理位置所属区域范围内的资源集合；

已选择资源提交单元503，用于向所述服务端提交在所述资源集合中选择的至少一个资源；

资源消费节点接收单元504，用于接收所述服务端推荐的资源消费节点。

可选的，所述基于用户端的资源推荐装置，包括：

地图展示指令接收单元，用于接收用户针对所述资源集合发出的地图展示指令；

资源展示单元，用于根据所述地图展示指令，通过资源地图展示所述地理位置以及所述地理位置所属区域范围内资源集合中的所有资源；

资源选择单元，用于接收所述用户在所述资源地图展示的所述资源集合中的至少一个资源。

可选的，所述基于用户端的资源推荐装置，包括：

资源消费节点展示单元，用于通过所述资源地图展示所述服务端推荐的资源消费节点；

资源消费节点选择单元，用于接收所述用户在所述资源地图展示的资源消费节点中选择的资源消费节点；

资源消费节点发送单元，用于向所述服务端发送所述用户已选择的资源消费节点。

可选的，所述基于用户端的资源推荐装置，包括：

订单接收单元，用于接收所述服务端发送的订单；

订单结算单元，用于针对接收到的订单进行结算，向所述服务端提交结算数据；

提醒消息接收单元，用于接收所述服务端发送的前往所述目标资源消费节点的提醒消息；

评价发送单元，用于将所述用户提交的针对所述资源和/或所述资源消费节点的评价向所述服务端发送。

本申请虽然以较佳实施例公开如上，但其并不是用来限定本申请，任何本领域技术人员在不脱离本申请的精神和范围内，都可以做出可能的变动和修改，因此本申请的保护范围应当以本申请权利要求所界定的范围为准。

在一个典型的配置中，计算设备包括一个或多个处理器、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(ram)和/或非易失性内存等形式，如只读存储器(rom)或闪存(flashram)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(pram)、静态随机存取存储器(sram)、动态随机存取存储器(dram)、其他类型的随机存取存储器(ram)、只读存储器(rom)、电可擦除可编程只读存储器(eeprom)、快闪记忆体或其他内存技术、只读光盘只读存储器(cd-rom)、数字多功能光盘(dvd)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括非暂存电脑可读媒体(transitorymedia)，如调制的数据信号和载波。

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