运力推荐方法、及网约车聚合信息服务平台与流程

1.本技术实施例涉及信息服务技术领域，尤其涉及一种运力推荐方法、及网约车聚合信息服务平台。


背景技术：

2.为方便用户出行，用户可以通过应用软件(比如地图导航应用或者生活服务应用等)集成的网约车聚合服务入口呼叫一个或多个网约车平台提供的车辆。在实际使用过程中，用户可以自行选择网约车平台，发明人发现用户通常优先选择呼叫自己熟悉的平台的车辆，但在某些情况下(如出行高峰时段)，如果用户优先选择的平台是其他用户也经常选择的平台时，用户需要等待较长时间才能呼叫到车辆，甚至会出现呼叫不到车辆，需要用户重新选择平台重新呼叫的情况，这种由用户自行选择网约车平台的方式，影响了用户的出行效率。


技术实现要素：

3.有鉴于此，本技术实施例提供一种运力推荐方案，以至少部分解决上述问题。
4.根据本技术实施例的第一方面，提供了一种运力推荐方法，包括：在接收并转发网约车呼叫请求至所述请求指示的网约车平台，并等待所述平台应答所述请求的过程中，包括：根据配置的推荐过滤规则，确定是否为所述网约车呼叫请求执行附加运力推荐；若执行附加运力推荐，则基于所述网约车呼叫请求，确定推荐网约车平台；当所述网约车呼叫请求的应答等待时间满足设定的呼叫等待时长时，获取所述推荐网约车平台的虚拟资源数据；根据所述虚拟资源数据和所述推荐网约车平台，生成附加运力推荐信息。
5.根据本技术实施例的第二方面，提供了一种网约车呼叫方法，包括：在发送网约车呼叫请求，并等待所述请求指示的网约车平台应答所述请求的过程中，包括：接收附加运力推荐信息；根据接收的附加运力推荐信息，展示附加运力推荐页面，其中，所述附加运力推荐页面中展示有与所述附加运力推荐信息中携带的推荐运力对应的运力选项和与所述推荐网约车平台对应的虚拟资源选项；响应于对至少一个所述运力选项的选择操作，发送附加运力呼叫请求至网约车聚合信息服务平台，以通过所述平台向附加运力对应的网约车平台发送相应的约车请求。
6.根据本技术实施例的第三方面，提供了一种网约车聚合信息服务平台，包括：第一确定模块，用于在接收并转发网约车呼叫请求至所述请求指示的网约车平台，并等待所述平台应答所述请求的过程中，根据配置的推荐过滤规则，确定是否为所述网约车呼叫请求执行附加运力推荐；第二确定模块，用于若执行附加运力推荐，则基于所述网约车呼叫请求，确定推荐网约车平台；获取模块，用于当所述网约车呼叫请求的应答等待时间满足设定的呼叫等待时长时，获取所述推荐网约车平台的虚拟资源数据；生成模块，用于根据所述虚拟资源数据和所述推荐网约车平台，生成附加运力推荐信息。
7.根据本技术实施例的第四方面，提供了一种网约车呼叫装置，包括：第二接收模
块，用于在发送网约车呼叫请求，并等待所述请求指示的网约车平台应答所述请求的过程中，接收附加网约车呼叫信息；展示模块，用于根据接收的附加网约车呼叫信息，展示附加网约车呼叫页面，其中，所述附加网约车呼叫页面中展示有与所述附加网约车呼叫信息中携带的推荐运力对应的运力选项和与所述推荐网约车平台对应的虚拟资源选项；发送模块，用于响应于对至少一个所述运力选项的选择操作，发送附加运力呼叫请求至网约车聚合信息服务平台，以通过所述平台向附加运力对应的网约车平台发送相应的约车请求。
8.根据本技术实施例的第五方面，提供了一种电子设备，包括：处理器、存储器、通信接口和通信总线，所述处理器、所述存储器和所述通信接口通过所述通信总线完成相互间的通信；所述存储器用于存放至少一可执行指令，所述可执行指令使所述处理器执行如第一方面或第二方面所述的运力推荐方法和网约车呼叫方法对应的操作。
9.根据本技术实施例的第六方面，提供了一种计算机存储介质，其上存储有计算机程序，该程序被处理器执行时实现如第一方面或第二方面所述的运力推荐方法和网约车呼叫方法。
10.根据本技术实施例提供的运力推荐方案，根据推荐过滤规则确定是否进行附加运力推荐，若执行附加运力推荐，则根据网约车呼叫请求确定推荐适当的推荐网约车平台，并在应答等待时间满足设定的呼叫等待时长时获取推荐网约车平台对应的虚拟资源数据。根据虚拟资源数据和推荐网约车平台生成附加运力推荐信息。这样使得可以及时确定需要附加运力的网约车呼叫请求，进而为其提供合适的推荐网约车平台和虚拟资源数据，以方便追加选择推荐网约车平台，进而提升呼叫成功率。
附图说明
11.为了更清楚地说明本技术实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本技术实施例中记载的一些实施例，对于本领域普通技术人员来讲，还可以根据这些附图获得其他的附图。
12.图1a为根据本技术实施例一的一种运力推荐方法的步骤流程图；
13.图1b为图1a所示实施例中的一种场景示例的示意图；
14.图2为根据本技术实施例二的一种运力推荐方法的步骤流程图；
15.图3a为根据本技术实施例三的一种网约车呼叫方法的步骤流程图；
16.图3b为图3a所示实施例中的一种场景示例的示意图；
17.图4为根据本技术实施例四的一种网约车信息服务平台的结构框图；
18.图5为根据本技术实施例五的一种网约车呼叫装置的结构框图；
19.图6为根据本技术实施例六的一种电子设备的结构示意图。
具体实施方式
20.为了使本领域的人员更好地理解本技术实施例中的技术方案，下面将结合本技术实施例中的附图，对本技术实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅是本技术实施例一部分实施例，而不是全部的实施例。基于本技术实施例中的实施例，本领域普通技术人员所获得的所有其他实施例，都应当属于本技术实施例保护的范围。
21.下面结合本技术实施例附图进一步说明本技术实施例具体实现。
22.实施例一
23.参照图1a，示出了本技术实施例一的运力推荐方法的步骤流程示意图。
24.在本实施例中，运力推荐方法可以配置于服务端或云端，在接收并转发网约车呼叫请求至所述请求指示的网约车平台，并等待所述平台应答所述请求的过程中，通过该方法确定是否为相应的客户端推荐附加运力，以提升呼叫网约车的成功率，并尽量减少等待时间。本实施例中的方法包括以下步骤：
25.步骤s102：根据配置的推荐过滤规则，确定是否为所述网约车呼叫请求执行附加运力推荐。
26.网约车呼叫请求可以是从客户端接收的请求，该请求用于指示其发起方(如使用者)选择希望使用的网约车平台。该请求中可以携带有下述信息中的至少之一，但不限于此：发起方的id、客户端的位置信息、行程类型(如实时用车、接送机、预约单等等)、行程起止位置、已选择网约车平台(如aa打车、bb快车、cc出行等)、已选择网约车平台的预估费用、优惠信息、客户端的历史推荐信息(如最近一次附加运力推荐信息展示时间)和历史推荐拒绝信息(如最近一次拒绝附加运力推荐信息展示请求的时间)等。基于该请求中携带的信息可以结合推荐过滤规则确定是否为该网约车呼叫请求执行附加运力推荐。
27.推荐过滤规则可以预先配置在服务端或云端。或者，推荐过滤规则可以配置在不同于服务端或云端的其他运营平台，由服务端或云端根据需要向运营平台请求而获得。
28.推荐过滤规则可以由人工设定，也可以通过对不同运力所在平台的网约车运营情况进行分析后自动生成，本实施例对此不作限制。基于推荐过滤规则可以智能地、及时地识别出难以呼叫到网约车的情况，并根据需要为难以呼叫的网约车呼叫请求确定是否为其执行附加运力推荐，从而在保证提升呼叫成功率的同时减少不必要的打扰。
29.推荐过滤规则包括但不限于：接受度过滤和已选择运力过滤等。其中，接受度过滤可以用于指示网约车呼叫请求的发起方(如使用者)是否对附加运力推荐疲劳，如果已经疲劳，则表示其对此接受度较低，可以不进行附加运力推荐，从而减少打扰。
30.已选择运力过滤可以指示网约车呼叫请求中已选择运力是否数量过少，如果过少，则进行附加运力推荐，从而提升呼叫成功率。
31.当然，推荐过滤规则可以不限于此，也可以根据需要增加新的规则或者减少已有规则。
32.若根据推荐过滤规则确定执行附加运力推荐，则执行步骤s104。或者，若根据推荐过滤规则确定不执行附加运力推荐，则可以等待网约车平台的应答结果。
33.步骤s104：若执行附加运力推荐，则基于所述网约车呼叫请求，确定推荐网约车平台。
34.为了保证为网约车呼叫请求确定的推荐网约车平台与网约车呼叫请求的适配度较高，从而提升发起方选择推荐网约车平台的概率，进而提升应答成功率。
35.例如，从候选网约车平台(在该平台中提供服务的网约车即为候选运力)中选择预估费用与已选择网约车平台的预估费用之间的差值在预设范围(其可以根据需要确定，例如为[-5,5]等)内的候选网约车平台作为推荐网约车平台，这样可以保证使用推荐网约车平台中运力的成本不会有显著增加，使推荐网约车平台更容易被选择。
[0036]
步骤s106：当所述网约车呼叫请求的应答等待时间满足设定的呼叫等待时长时，获取所述推荐网约车平台的虚拟资源数据。
[0037]
为了进一步提升对网约车呼叫难易程度判断的准确性，使虚拟资源数据能够发放到更需要的请求发起方，进而提升虚拟资源数据的利用效率，可以基于应答等待时间确定该网约车呼叫请求是否难以获得运力。
[0038]
例如，当应答等待时间满足设定的呼叫等待时长时，表示没有适当的运力应答该请求，即该请求呼叫到网约车的难度较高，需要通过分配虚拟资源(如优惠券)的方式激励发起方选择推荐网约车平台，从而增加其已选择网约车平台的数量，进而提升请求被应答的概率和减少等待时间，为此可以根据推荐网约车平台的预估费用和已选择网约车平台的预估费用的上限值之间的差值，获取虚拟资源数据。
[0039]
如，已选择网约车平台为网约车平台a、b和c，其中，网约车平台a的预估费用相较于网约车平台b和c的预估费用更高，因此以其预估费用作为上限值。针对推荐网约车平台d，将其预估费用减去上限值获得差值。若差值大于0，则获取额度与差值对应的虚拟资源数据。或者，若差值小于或等于0，则获取额度为0的虚拟资源数据。
[0040]
步骤s108：根据所述虚拟资源数据和所述推荐网约车平台，生成附加运力推荐信息。
[0041]
例如，推荐网约车平台为网约车平台d和网约车平台e。虚拟资源数据包括网约车平台d对应的虚拟资源数据和网约车平台e对应的虚拟资源数据。其中，虚拟资源数据中包括但不限于虚拟资源的额度、有效期等等。
[0042]
服务端或云端可以将生成的附加运力推荐信息发送给客户端。后续客户端根据附加运力推荐信息展示推荐网约车平台及其对应的虚拟资源，以供网约车呼叫请求的发起方选择是否追加推荐网约车平台。
[0043]
下面以一具体使用场景为例，对运力推荐方法进行说明如下：
[0044]
如图1b所示，发起方在通过客户端(如地图导航类应用程序)呼叫网约车时，可以选择网约车平台a、b和c，客户端基于已选择网约车平台、行程信息、客户端的历史推荐信息和历史推荐拒绝信息等生成网约车呼叫请求，并发送至服务端或云端。
[0045]
服务端或云端基于配置的推荐过滤规则，确定是否为网约车呼叫请求执行附加运力推荐。若确定执行附加运力推荐，则根据网约车平台呼叫请求中携带的已选择网约车平台的预估费用和优惠信息等，从候选网约车平台中选取适当的网约车平台作为推荐网约车平台。
[0046]
在网约车呼叫请求的应答等待时间满足设定的呼叫等待时长时，针对每个推荐网约车平台可以获得相应的虚拟资源数据，并基于虚拟资源数据和推荐网约车平台生成附加运力推荐信息。后续可以将附加运力推荐信息发送至客户端，以供请求的发起方根据需要选择是否追加选择推荐网约车平台。这样实现了智能地、及时地进行网约车平台推荐，在提升呼叫成功率的同时尽量避免呼叫成本的增加。
[0047]
通过本实施例，根据推荐过滤规则确定是否进行附加运力推荐，若执行附加运力推荐，则根据网约车呼叫请求确定推荐适当的推荐网约车平台，并在应答等待时间满足设定的呼叫等待时长时获取推荐网约车平台对应的虚拟资源数据。根据虚拟资源数据和推荐网约车平台生成附加运力推荐信息。这样使得可以及时确定需要附加运力的网约车呼叫请
求，进而为其提供合适的推荐网约车平台和虚拟资源数据，以方便追加选择推荐网约车平台，进而提升呼叫成功率。
[0048]
实施例二
[0049]
参照图2，示出了本技术实施例二的运力推荐方法的步骤流程示意图。
[0050]
在本实施例中，该方法包括以下步骤：
[0051]
步骤s200：接收网约车呼叫请求，并基于所述网约车呼叫请求和配置信息，确定是否满足配置信息。
[0052]
在本实施例中，配置信息配置于运营平台中。运营方可以通过运营平台的管理界面在运营平台中添加或者删除配置信息。配置信息用于确定网约车呼叫请求是否满足附加运力推荐的要求，这样可以有效地过滤掉不满足要求的网约车呼叫请求，从而降低数据处理负载，减少资源占用和浪费。
[0053]
配置信息包括但不限于：行程类型、推荐有效时间段(如周一到周五的7-10时和17-21时等高峰时段)、推荐有效地理区域(如配置部分城市有效、或者城市的部分区域有效荐)、有效订单里程(如大于1km以上的行程进行推荐)、有效发起方类型、呼叫等待时长和优惠规则等。
[0054]
一种可行方式中，呼叫等待时长可以通过智能分析呼叫数据确定，以更加准确地确定是否处于难以呼叫到网约车的状态，从而减少过分打扰到发起方。
[0055]
一种确定呼叫等待时长的可行方式例如为：通过分析网约车呼叫请求携带的位置信息对应的地理区域内的平均应答等待时间，以平均应答等待时间作为呼叫等待时长。以城市a为例，可以将其划分为n个地理区域，并获取最近一段时间(如最近一个月)内的应答等待时间，以计算出平均应答等待时间。或者，在另一种可行方式中，呼叫等待时长可以由人工配置。
[0056]
服务端或者云端接收到网约车呼叫请求时，若服务端或云端配置的推荐开关处于打开状态、发送该请求的客户端的版本满足设定版本、且该请求的行程类型满足设定类型(如为实时用车，并非代人叫车或者预约单)，则向运营平台请求配置信息，以根据配置信息确定该请求是否满足附加运力推荐的要求。
[0057]
若网约车呼叫请求的接收时间在推荐有效时间段内、行程起止位置对应的城市为配置信息中推荐有效地理区域、且行程起止位置的行程里程满足有效订单里程，且发起方类型满足有效发起方类型，则可以确定该请求满足附加运力推荐的要求，进而可以执行步骤s202。当然，本实施例中的确定方式仅是列举，在其他实施例中可以根据其中的部分条件确定该请求是否满足附加运力推荐的要求。
[0058]
反之，若确定网约车呼叫请求不满足要求，则可以不进行附加运力推荐，等待网约车平台的响应。
[0059]
步骤s202：根据配置的推荐过滤规则，确定是否为所述网约车呼叫请求执行附加运力推荐。
[0060]
配置过滤规则可以配置在服务端或云端。在一可行方式中，步骤s202可以通过下述子步骤实现：
[0061]
子步骤s2021：根据所述网约车呼叫请求对应的历史推荐信息，确定推荐接受度，若所述推荐接受度小于设定接受度，则确定执行附加运力推荐。
[0062]
例如，历史推荐信息用于指示最近一次向请求的发起方推荐附加运力的时间。历史推荐拒绝信息用于指示最近一次拒绝附加运力推荐的时间。
[0063]
若最近一次推荐附加运力的时间与网约车呼叫请求的接收时间处于同一天，也就是说一天内已经推荐了一次附加运力，则确定推荐接受度小于设定接受度。
[0064]
或者，若最近一次拒绝附加运力推荐的时间与网约车呼叫请求的接收时间之间的时长小于时长t(时长t可以根据需要确定，例如为1天或者1周)，则确定推荐接受度小于设定接受度。设定接受度可以根据需要确定，对此不作限制。
[0065]
若确定推荐接受度大于或等于设定接受度，则可以不执行附加运力推荐。
[0066]
子步骤s2022：确定所述网约车呼叫请求指示的网约车平台的数量是否小于或等于设定的数量阈值；若小于或等于设定的数量阈值，则确定执行附加运力推荐。
[0067]
设定的数量阈值可以根据需要确定，例如为1个、2个或者以上。以设定的数量阈值是1为例进行说明：若网约车呼叫请求指示的网约车平台的数量(即已选择的网约车平台数量)小于或等于1个，则可能因为选择的网约车平台数量较少而导致难以呼叫到车辆，为了提升应答成功率，执行附加运力推荐。
[0068]
若网约车呼叫请求指示的网约车平台的数量大于设定的数量阈值，则确定不执行附加运力推荐。
[0069]
需要说明的是，前述的子步骤s2021和子步骤s2022可以仅执行其中之一，也可以均执行。在两个子步骤均执行时，两者可以并行执行或者串行执行。若串行执行，则子步骤s2021和子步骤s2022中的任意一个可以在先执行，且在两个子步骤均确定执行附加运力推荐时，执行步骤s204。
[0070]
步骤s204：若执行附加运力推荐，则基于所述网约车呼叫请求，确定推荐网约车平台。
[0071]
在一可行方式中，步骤s204通过下述子步骤实现：
[0072]
子步骤2041：根据所述网约车呼叫请求中携带的位置信息，确定在所述位置信息所在地理区域正常运营的网约车平台。
[0073]
在服务端或云端中可以针对不同地理区域配置不同的可用网约车平台。基于客户端的位置信息可以确定网约车呼叫请求对应的地理区域，从而获取相应的可用网约车平台(即正常运营的网约车平台)。
[0074]
在一种可行方式中，从可用网约车平台中去除已选择的网约车平台(即请求指示的网约车平台)，以剩余的作为候选网约车平台。
[0075]
在另一种可行方式中，正常运营的网约车平台可以包括已选择的网约车平台。例如，网约车平台a提供了3种不同的车型服务(普通车型、尊享车型等等)，分别为车型服务1、2和3，在请求中指示选择了网约车平台a的车型1，则剩余的已选择的网约车平台中的车型服务2和3仍可以作为候选。此种情况中，可以将未选择的网约车平台中的所有车型服务、已选择网约车平台中未被选择的车型服务作为候选网约车平台。
[0076]
子步骤2042：从所述正常运营的网约车平台中，确定满足推荐条件的推荐网约车平台。
[0077]
一种可行方式中，子步骤s2042实现为：
[0078]
过程a：获取所述候选网约车平台的预估费用。
[0079]
该预估费用根据行程起点和行程终点确定。例如为“23元”。
[0080]
过程b：确定所述候选网约车平台的预估费用与所述网约车呼叫请求中携带的已选择的网约车平台的预估费用之间的估计比值。
[0081]
获取所述候选运力的预估费用，并确定所述候选运力的预估费用与所述车辆呼叫请求中携带的已选择运力的预估费用之间的估计比值。
[0082]
候选网约车平台的预估费用t可以通过下述方式确定：根据所述候选网约车平台的初始费用o、待获取的虚拟资源数据中的虚拟资源的额度p(例如为“减5元”)和所述请求中携带的已有优惠信息q(如7折等)确定。其可以表示为：
[0083]
预估费用t＝初始费用o-额度p-已有优惠信息q
[0084]
在此示例中，预估费用t＝(23-5)*0.7＝12.6。
[0085]
已选择网约车平台的预估费用为所有已选择的网约车平台的预估费用中作为上限的一个。估计比值为候选网约车平台的预估费用除以已选择的网约车平台的预估费用中的上限。
[0086]
为了避免推荐网约车平台的费用与已选择的网约车平台的预估费用之间的差距较大，造成追加呼叫的成本过高，本实施例中，通过计算的估计比值，对候选网约车平台进行筛选。
[0087]
过程c：选取估计比值小于设定比值的候选网约车平台作为所述推荐网约车平台。
[0088]
设定比值可以根据需要确定，例如，不同发起方的设定比值可以不同，其可以通过对其历史数据进行大数据分析确定。如发起方a的设定比值为1.25，发起方b的设定比值为1.5等。
[0089]
由于是选取估计比值小于设定比值的候选网约车平台作为推荐网约车平台，这样使得推荐网约车平台的预估费用少于已选择的网约车平台的预估费用或者是略大于，避免了使用成本过高的问题。
[0090]
需要说明的是，为提升智能性，若候选网约车平台的数量小于设定的推荐数量(其可以根据需要确定，例如为2)，则不再进行推荐，可以结束该方法并等待选择的网约车平台的应答。
[0091]
或者，若候选网约车平台的数量大于或等于设定推荐数量，则执行子步骤s2042，以从中筛选出推荐网约车平台。
[0092]
步骤s206：当所述网约车平台呼叫请求的应答等待时间满足设定的呼叫等待时长时，获取所述推荐网约车平台的虚拟资源数据。
[0093]
若应答等待时间满足呼叫等待时长(该呼叫等待时长可以根据配置信息确定，也可以配置在服务端或云端中)，则表示难以呼叫到车辆，为了促使发起方增加选择的网约车平台，从运营平台获取虚拟资源数据。
[0094]
在一可行方式中，可以从风控平台获取风控接口，并根据风控接口进行风控管控，若风控管控通过，则获取虚拟资源数据，这样可以提升稳定性和安全性，避免虚拟资源浪费。或者，在另一可行方式中，也可以直接获取虚拟资源数据。
[0095]
虚拟资源数据中包括虚拟资源的额度、使用条件、有效期及其对应的网约车平台。
[0096]
步骤s208：根据所述虚拟资源数据和所述推荐网约车平台，生成附加运力推荐信息。
[0097]
服务端或云端可以将获取的虚拟资源数据和推荐网约车平台生成附加运力推荐信息，并将附加运力推荐信息发送给客户端。
[0098]
可选地，该方法还包括步骤s210。
[0099]
步骤s210：接收所述客户端响应所述附加运力推荐信息生成并发送的附加运力呼叫请求，将所述附加运力呼叫请求发送至所述请求指示的推荐网约车平台。
[0100]
客户端在接收到附加运力推荐信息后，可以根据该信息展示附加运力推荐页面，在页面中展示有推荐网约车平台的运力选项以及虚拟资源选项。若发起方选择了至少一个运力选项，且触发了虚拟资源选项，表示希望通过选择的推荐网约车平台呼叫新的运力，因此，客户端可以生成附加运力呼叫请求，并将其发送给服务端或云端。
[0101]
服务端或云端从接收的附加运力呼叫请求中获取到选择的推荐网约车平台，并将附加运力呼叫请求转发至相应的推荐网约车平台，并等待其应答。
[0102]
该方法可以精准判断运力不足的情况，并精确确定出与发起方适配的可推荐网约车平台，使得能够在难以呼叫到车辆时增加选择的网约车平台，从而提升呼叫成功率，与此同时还可以防止过度打扰。
[0103]
通过本实施例，根据推荐过滤规则确定是否进行附加运力推荐，若执行附加运力推荐，则根据网约车呼叫请求确定推荐适当的推荐网约车平台，并在应答等待时间满足设定的呼叫等待时长时获取推荐网约车平台对应的虚拟资源数据。根据虚拟资源数据和推荐网约车平台生成附加运力推荐信息。这样使得可以及时确定需要附加运力的网约车呼叫请求，进而为其提供合适的推荐网约车平台和虚拟资源数据，以方便追加选择推荐网约车平台，进而提升呼叫成功率。
[0104]
实施例三
[0105]
参照图3a，示出了本技术实施例三的网约车呼叫方法的步骤流程图。
[0106]
在本实施例中，该方法应用于客户端，用于为发起方推荐附加运力(即额外的网约车平台)。其中，该方法包括以下步骤：
[0107]
步骤s302：接收附加运力推荐信息。
[0108]
在通过导航应用或者地图应用等进行网约车呼叫时，客户端向服务端或云端发送网约车呼叫请求，并等待应答。在此过程中客户端可以展示等待界面。在此过程中，服务端或云端可能向客户端发送附加运力推荐信息。
[0109]
步骤s304：根据接收的附加运力推荐信息，展示附加运力推荐页面。
[0110]
在接收到服务端或云端发送的附加运力推荐信息时，可以根据附加运力推荐信息展示附加运力推荐页面。
[0111]
其中，所述附加运力推荐页面中展示有与所述附加运力推荐信息中携带的推荐网约车平台对应的运力选项和对应的虚拟资源选项。
[0112]
步骤s306：响应于对至少一个所述运力选项的选择操作，发送附加运力呼叫请求。
[0113]
用户点击运力选项(也可以点击虚拟资源选项)表示希望增加新的网约车平台，并使用该虚拟资源。为此，客户端生成附加运力呼叫请求，并将其发送给服务端或云端，使得服务端或云端将附加运力呼叫请求转发至相应的推荐网约车平台。
[0114]
这种方式可以在难以叫车的情况下，适当地推荐新的网约车平台，并发放虚拟资源，从而提升呼叫成功率。
[0115]
下面结合一使用场景，对网约车呼叫方法的实现过程进行说明如下：
[0116]
客户端根据用户输入的行程起止位置和选择的网约车平台，生成网约车呼叫请求并发送至服务端或云端。在客户端可以展示呼叫等待界面，如图3b中界面1所示。
[0117]
若服务端确定进行附加运力推荐，则可以向客户端发送指示客户端展示倒计时界面的消息，客户端显示倒计时界面，如图3b中界面2所示。
[0118]
在倒计时结束时，若接收到服务端或云端发送的附加运力推荐信息，则根据附加运力推荐信息中携带的虚拟资源数据和推荐网约车平台展示附加运力推荐页面，如图3b中界面3所示。其中，展示有运力选项和虚拟资源选项。
[0119]
若用户选择其中的至少一个运力选项，则根据选择的运力选项和对应的虚拟资源数据，生成附加运力呼叫请求，并发送给服务端或云端。此外，在呼叫等待界面中展示提示信息，如图3b中界面4所示。
[0120]
在接收到服务端或云端发送的呼叫应答信息时，根据呼叫应答信息显示应答车辆的信息，如图3b中界面5所示。
[0121]
通过该方法可以在难以呼叫到车辆时推荐其他网约车平台，从而提升呼叫的成功率。
[0122]
实施例四
[0123]
参照图4，示出了本技术实施例四的网约车聚合信息服务平台的结构框图。
[0124]
本实施例网约车聚合信息服务平台，包括：
[0125]
第一确定模块402，用于在接收并转发网约车呼叫请求至所述请求指示的网约车平台，并等待所述平台应答所述请求的过程中，根据配置的推荐过滤规则，确定是否为所述网约车呼叫请求执行附加运力推荐；
[0126]
第二确定模块404，用于若执行附加运力推荐，则基于所述网约车呼叫请求，确定推荐网约车平台；
[0127]
获取模块406，用于当所述网约车呼叫请求的应答等待时间满足设定的呼叫等待时长时，获取所述推荐网约车平台的虚拟资源数据；
[0128]
生成模块408，用于根据所述虚拟资源数据和所述推荐网约车平台，生成附加运力推荐信息。
[0129]
可选地，所述第二确定模块404用于根据所述网约车呼叫请求中携带的位置信息，确定在所述位置信息所在地理区域正常运营的网约车平台；从所述正常运营的网约车平台中，确定满足推荐条件的推荐网约车平台。
[0130]
可选地，所述第一确定模块402用于根据所述网约车呼叫请求对应的历史推荐信息，确定推荐接受度；若所述推荐接受度小于设定接受度，则确定执行附加运力推荐。
[0131]
可选地，第一确定模块402用于确定所述网约车呼叫请求指示的网约车平台的数量是否小于或等于设定的数量阈值；若小于或等于设定的数量阈值，则确定执行附加运力推荐。
[0132]
可选地，第二确定模块404用于在所述从所述正常运营的网约车平台中，确定满足推荐条件的推荐网约车平台时，获取所述候选网约车平台的预估费用；确定所述候选网约车平台的预估费用与所述网约车呼叫请求中携带的已选择网约车平台的预估费用之间的估计比值；选取估计比值小于设定比值的候选网约车平台作为所述推荐网约车平台。
[0133]
可选地，所述第二确定模块404用于在获取所述候选网约车平台的预估费用时，根据所述候选网约车平台的初始费用、待获取虚拟资源数据和所述网约车呼叫请求中携带的优惠信息，确定所述候选网约车平台的预估费用。
[0134]
可选地，所述装置还包括：
[0135]
第一接收模块410，用于接收所述客户端响应所述附加运力推荐信息生成并发送的附加运力呼叫请求，将所述附加运力呼叫请求发送至所述请求指示的推荐网约车平台。
[0136]
本实施例的网约车聚合信息服务平台用于实现前述多个方法实施例中相应的运力推荐方法，并具有相应的方法实施例的有益效果，在此不再赘述。此外，本实施例的网约车聚合信息服务平台中的各个模块的功能实现均可参照前述方法实施例中的相应部分的描述，在此亦不再赘述。
[0137]
实施例五
[0138]
参照图5，示出了本技术实施例五的网约车呼叫装置的结构框图。
[0139]
在本实施例中，网约车呼叫装置包括：
[0140]
第二接收模块502，用于在发送网约车呼叫请求，并等待所述请求指示的网约车平台应答所述请求的过程中，接收附加网约车呼叫信息；
[0141]
展示模块504，用于根据接收的附加网约车呼叫信息，展示附加网约车呼叫页面，其中，所述附加网约车呼叫页面中展示有与所述附加网约车呼叫信息中携带的推荐运力对应的运力选项和与所述推荐网约车平台对应的虚拟资源选项；
[0142]
发送模块506，用于响应于对至少一个所述运力选项的选择操作，发送附加运力呼叫请求至网约车聚合信息服务平台，以通过所述平台向附加运力对应的网约车平台发送相应的约车请求。
[0143]
网约车呼叫网约车呼叫网约车呼叫网约车呼叫网约车呼叫网约车呼叫本实施例的网约车呼叫装置用于实现前述多个方法实施例中相应的网约车呼叫方法，并具有相应的方法实施例的有益效果，在此不再赘述。此外，本实施例的网约车呼叫装置中的各个模块的功能实现均可参照前述方法实施例中的相应部分的描述，在此亦不再赘述。
[0144]
实施例六
[0145]
参照图6，示出了根据本技术实施例六的一种电子设备的结构示意图，本技术具体实施例并不对电子设备的具体实现做限定。
[0146]
如图6所示，该电子设备可以包括：处理器(processor)602、通信接口(communications interface)604、存储器(memory)606、以及通信总线608。
[0147]
其中：
[0148]
处理器602、通信接口604、以及存储器606通过通信总线608完成相互间的通信。
[0149]
通信接口604，用于与其它电子设备或服务器进行通信。
[0150]
处理器602，用于执行程序610，具体可以执行上述运力推荐方法和网约车呼叫方法实施例中的相关步骤。
[0151]
具体地，程序610可以包括程序代码，该程序代码包括计算机操作指令。
[0152]
处理器602可能是中央处理器cpu，或者是特定集成电路asic(application specific integrated circuit)，或者是被配置成实施本技术实施例的一个或多个集成电路。智能设备包括的一个或多个处理器，可以是同一类型的处理器，如一个或多个cpu；也可
以是不同类型的处理器，如一个或多个cpu以及一个或多个asic。
[0153]
存储器606，用于存放程序610。存储器606可能包含高速ram存储器，也可能还包括非易失性存储器(non-volatilememory)，例如至少一个磁盘存储器。
[0154]
程序610具体可以用于使得处理器602执行前述方法实施例对应的操作。
[0155]
程序610中各步骤的具体实现可以参见上述运力推荐方法和网约车呼叫方法实施例中的相应步骤和单元中对应的描述，在此不赘述。所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的设备和模块的具体工作过程，可以参考前述方法实施例中的对应过程描述，在此不再赘述。
[0156]
本实施例还提供一种计算机程序产品，包括计算机指令，所述计算机指令指示计算设备执行如前述的运力推荐方法和网约车呼叫方法对应的操作。
[0157]
需要指出，根据实施的需要，可将本技术实施例中描述的各个部件/步骤拆分为更多部件/步骤，也可将两个或多个部件/步骤或者部件/步骤的部分操作组合成新的部件/步骤，以实现本技术实施例的目的。
[0158]
上述根据本技术实施例的方法可在硬件、固件中实现，或者被实现为可存储在记录介质(诸如cd rom、ram、软盘、硬盘或磁光盘)中的软件或计算机代码，或者被实现通过网络下载的原始存储在远程记录介质或非暂时机器可读介质中并将被存储在本地记录介质中的计算机代码，从而在此描述的方法可被存储在使用通用计算机、专用处理器或者可编程或专用硬件(诸如asic或fpga)的记录介质上的这样的软件处理。可以理解，计算机、处理器、微处理器控制器或可编程硬件包括可存储或接收软件或计算机代码的存储组件(例如，ram、rom、闪存等)，当所述软件或计算机代码被计算机、处理器或硬件访问且执行时，实现在此描述的运力推荐方法和网约车呼叫方法。此外，当通用计算机访问用于实现在此示出的运力推荐方法和网约车呼叫方法的代码时，代码的执行将通用计算机转换为用于执行在此示出的运力推荐方法和网约车呼叫方法的专用计算机。
[0159]
本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及方法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本技术实施例的范围。
[0160]
以上实施方式仅用于说明本技术实施例，而并非对本技术实施例的限制，有关技术领域的普通技术人员，在不脱离本技术实施例的精神和范围的情况下，还可以做出各种变化和变型，因此所有等同的技术方案也属于本技术实施例的范畴，本技术实施例的专利保护范围应由权利要求限定。