用于向用户推荐运输相关服务的一个或多个兴趣点的通信服务器装置、方法和通信系统与流程

1.本发明总体上涉及通信领域。本发明的一个方面涉及一种用于向用户推荐运输相关服务的一个或多个兴趣点的通信服务器装置。本发明的其他方面进一步涉及用于向用户推荐运输相关服务的一个或多个兴趣点的通信服务器装置、用于向用户推荐运输相关服务的一个或多个兴趣点的方法、用于向用户推荐运输相关服务的一个或多个兴趣点的通信系统以及用于向用户推荐运输相关服务的一个或多个兴趣点的通信服务器设备。其他方面涉及具有指令的计算机程序产品、计算机程序和非暂态存储介质，这些指令用于实施本文所描述的方法中的任一种方法。
2.本发明的一个方面特别但非排他地适用于向用户推荐运输相关服务的一个或多个兴趣点。例如，用户可能希望请求或预订运输相关服务，例如打车运输服务，并且所披露的技术可以为不同动作/场景或在预订的不同阶段提供一个或多个兴趣点推荐作为与运输相关服务相对应的起点位置和/或目的地位置以供预订。用户可以使用对应的应用程序或“app”进行预订，并且可以经由app向用户提供或呈现推荐的兴趣点以供考虑和/或选择。


背景技术：

3.响应于用户对运输服务的查询，执行对与该查询相关的poi(兴趣点)的搜索。然而，当前的poi服务质量并不令人满意，因为已知的运输服务方法仅根据用户的位置来筛选poi，而没有考虑其他要求或属性。


技术实现要素：

4.本发明的各方面如独立权利要求中所阐述的。一些可选的特征在从属权利要求中进行定义。
5.本文所披露的技术的实施方式可以提供重要的技术优点。这些技术可以实现基于例如可能来自多个数据源的多条数据/信息向用户推荐运输相关服务的一个或多个兴趣点(poi)。
6.在至少一些实施方式中，本文所披露的技术可以基于历史数据，例如，与对应于历史运输相关服务的一对或多对起点位置和目的地位置相关的数据，提供一个或多个兴趣点(poi)的推荐。
7.在至少一些实施方式中，本文所披露的技术允许基于历史数据和对应于地理区域(例如，城市)中的至少一个目的地类别中的排名靠前的兴趣点的数据推荐一个或多个兴趣点(poi)。
8.在至少一些实施方式中，本文所披露的技术可以基于根据指配给候选poi的多个标准的单独得分而确定的候选poi最终得分来提供一个或多个兴趣点(poi)的推荐。这些标准中的至少一些标准的这些单独得分可以基于历史数据来确定。
9.在至少一些实施方式中，本文所披露的技术可以在预订运输相关服务期间针对不
同动作/场景提供一个或多个兴趣点(poi)的推荐，其中这些动作可以按有序顺序发生。
10.在示例性实施方式中，本文所披露的技术的功能可以在如移动电话等手持通信设备上运行的软件中实施。实施本文所披露的技术的功能的软件可以包含在用户已经从在线商店下载的“app”——一种计算机程序或计算机程序产品——中。当在例如用户的移动电话上运行时，移动电话的硬件特征可以用于实施下述功能，如使用移动电话的收发器部件来建立用于向用户推荐运输相关服务的一个或多个兴趣点(poi)的安全通信通道。
附图说明
11.现在参考附图，仅仅通过示例的方式对本发明加以描述，在附图中：
12.图1是展示了涉及通信服务器装置的示例性通信系统的示意性框图。
13.图2a示出了展示用于向用户推荐运输相关服务的一个或多个兴趣点的通信服务器装置的示意性框图。
14.图2b示出了展示在用于向用户推荐运输相关服务的一个或多个兴趣点的通信服务器装置中执行的方法的流程图。
15.图2c示出了展示用于向用户推荐运输相关服务的一个或多个兴趣点的通信服务器装置的示意性框图。
16.图2d示出了展示在用于向用户推荐运输相关服务的一个或多个兴趣点的通信服务器装置中执行的方法的流程图。
17.图2e示出了展示用于向用户推荐运输相关服务的一个或多个兴趣点的通信服务器装置的示意性框图。
18.图2f示出了展示数据记录的示意性框图。
19.图2g示出了展示在用于向用户推荐运输相关服务的一个或多个兴趣点的通信服务器装置中执行的方法的流程图。
20.图2h示出了展示用于向用户推荐运输相关服务的一个或多个兴趣点的通信服务器设备的示意性框图。
21.图2i示出了展示在用于向用户推荐运输相关服务的一个或多个兴趣点的通信服务器设备中执行的方法的流程图。
22.图3a至图3d展示了各个实施例的poi(兴趣点)服务的4个主要场景。
23.图4示出了展示基于层的web服务结构的示意图。
24.图5示出了展示用于poi(兴趣点)服务的系统的概览的示意图。
25.图6示出了poi(兴趣点)的时间分布图的示例。
26.图7a至图7d分别示出了各个实施例的poi服务在预测、建议、搜索和reversegeo等场景中的性能。
具体实施方式
27.本技术可以提供实时兴趣点(poi)推荐，例如，基于golang的实时poi发现和推荐。
28.运输服务(例如，打车运输服务)的一个方面是根据用户的位置尽可能少费力地为用户提供期望的poi作为上车点和/或下车点，该费力程度可以通过用户在点击预订按钮之前在屏幕上的点击次数来测量。作为基于地理的服务，poi发现和推荐可以涉及大量几何计
算和高流量吞吐量。确保poi发现和推荐的高可用性和稳定性很重要。在本技术中，已经采用了基于golang的服务架构来确保后端系统的稳定性。可以利用弹性搜索在数据库层组织数百万个poi数据。可以使用redis来缩短每个请求作为高速缓存的响应时间。如下文将进一步描述的，可以采用基于golang的服务架构，并且可以通过根据各个场景部署如弹性搜索和redis等技术来解决在线挑战。poi服务可以帮助增加以平均很少的点击屏幕次数完成的预订的比率。
29.首先参考图1，展示了通信系统100，该通信系统可以适用于各个实施例。通信系统100包括通信服务器装置102、第一用户(或客户端)通信设备104和第二用户(或客户端)通信设备106。这些设备102、104、106通过实施了例如互联网通信协议的相应的通信链路110、112、114而连接在通信网络108(例如，互联网)中或连接到该通信网络。这些通信设备104、106能够通过如公共交换电话网络(pstn网络)等其他通信网络，包括移动蜂窝通信网络来通信，但是为了清楚起见，从图1中省略这些通信网络。应当理解，可以存在与设备104、106类似的一个或多个其他通信设备。
30.通信服务器装置102可以用于向用户推荐运输相关服务的一个或多个兴趣点(poi)。
31.通信服务器装置102可以是如图1中示意性地展示的单个服务器，或者可以具有由通信服务器装置102执行的分布在多个服务器部件上的功能。在图1的示例中，通信服务器装置102可以包括多个单独的部件，包括但不限于：一个或多个微处理器(μp)116、用于加载可执行指令120的存储器118(例如，如ram(随机存取存储器)等易失性存储器)，可执行指令120定义了服务器装置102在处理器116的控制下执行的功能。通信服务器装置102还可以包括允许服务器装置102通过通信网络108进行通信的输入/输出(i/o)模块122。用户接口(ui)124被提供用于用户控制，并且可以包括例如一个或多个外围计算设备，如显示监视器、计算机键盘等等。通信服务器装置102还可以包括数据库(db)126，该数据库的目的将通过以下讨论变得更显而易见。
32.用户通信设备104可以包括多个单独的部件，包括但不限于：一个或多个微处理器(μp)128、用于加载可执行指令132的存储器130(例如，如ram等易失性存储器，)，可执行指令132定义了用户通信设备104在处理器128的控制下执行的功能。用户通信设备104还包括允许用户通信设备104通过通信网络108进行通信的输入/输出(i/o)模块134。用户接口(ui)136被提供用于用户控制。如果用户通信设备104是例如智能电话或平板设备，则用户接口136可以具有在许多智能电话和其他手持设备中普遍存在的触摸面板显示器。替代性地，如果用户通信设备104是例如台式计算机或膝上型计算机，则用户接口可以具有例如一个或多个外围计算设备，如显示监视器、计算机键盘等等。
33.用户通信设备106可以是例如具有与用户通信设备104的硬件架构相同或类似的硬件架构的智能电话或平板设备。
34.用户通信设备104和/或用户通信设备106可以用于接收关于向用户推荐的运输相关服务的一个或多个的兴趣点(poi)的信息或数据。
35.图2a示出了展示用于向用户推荐运输相关服务的一个或多个兴趣点(poi)的通信服务器装置202a的示意性框图。通信服务器装置202a包括处理器216a和存储器218a，其中通信服务器装置202a被配置为在处理器216a的控制下执行存储器218a中的指令，以响应于
接收到包括指示用户的位置(例如，当前位置或预计位置)的数据字段的用户数据(例如，指示纬度(lat)值和经度(lng)值的数据)，并且进一步响应于通信服务器设备202a确定不存在与该用户相关联且与运输相关服务相对应的历史数据，检索表示具有该位置的地图的数据255a，并且传输表示该地图的数据255a供该用户的用户通信设备接收，以经由该用户通信设备向该用户呈现该地图，以便确定(例如，基于该用户的位置)该地图上的(单个)兴趣点作为运输相关服务的推荐起点位置(或上车位置)，以及响应于通信服务器装置202a确定在一个或多个数据记录中存在与运输相关服务相对应的历史数据，该历史数据与该用户相关联，基于该历史数据来确定(单个)第一兴趣点作为运输相关服务的推荐起点位置(或上车位置)，基于该历史数据来确定(单个)第二兴趣点作为运输相关服务的推荐目的地位置(或下车位置)，该第一兴趣点和该第二兴趣点彼此配对且对应于历史运输相关服务，并且传输指示该第一兴趣点的数据256a和指示该第二兴趣点的数据257a供该用户通信设备接收。
36.处理器216a和存储器218a可以彼此耦合(如线217a所表示的)，例如，物理联接和/或电耦合。处理器216a可以如在处理器116(图1)的上下文中所描述的，和/或存储器218a可以如在存储器118(图1)的上下文中所描述的。
37.用户数据可以进一步包括指示表示用户身份的标识符(例如，用户id)的另一数据字段。
38.在各个实施例中，响应于通信服务器设备202a确定存在该历史数据，并且进一步响应于接收到具有指示时间(点)(例如，当前时间(点)或预计时间(点)或计划时间(点))的数据字段的用户数据(其可以是具有指示该用户的位置的数据字段的相同用户数据)，为了确定该第二兴趣点作为推荐目的地位置，通信服务器装置202a可以进一步被配置为基于该历史数据来确定该第二兴趣点在包括该时间的预定时间区间(例如，一天中的几个小时)内与该第一兴趣点配对。该时间可以是例如进行预订的时间，或者是运输相关服务的开始时间。
39.作为非限制性示例，该时间可以是下午3:05，并且在过去例如在下午3:00-3:30或下午3:00-4:00的时间区间内(例如，在过去24小时或更长的时间段内)与该第一兴趣点配对的该第二兴趣点可以被确定为推荐目的地位置。
40.在各个实施例中，响应于通信服务器设备202a确定存在该历史数据，并且进一步响应于接收到包括指示该用户的位置的数据字段的用户数据，为了确定该第一兴趣点，通信服务器装置202a可以被配置为确定该历史数据中是否包括指示运输相关服务的一个或多个历史起点位置的数据，如果确定存在指示该一个或多个历史起点位置的数据，则基于指示该一个或多个历史起点位置的数据将距离该用户的位置最近的历史起点位置定义为该第一兴趣点，并且传输指示该历史起点位置的数据供该用户通信设备接收，并且如果确定不存在指示该一个或多个历史起点位置的数据，则确定指示该历史数据中所包括的一个或多个历史目的地位置(或一个或多个首次最后下车点(ldf))的数据，基于指示该一个或多个历史目的地位置的数据将距离该用户的位置最近的历史目的地位置定义为该第一兴趣点，并且传输指示该历史目的地位置的数据供该用户通信设备接收。
41.在各个实施例中，为了确定指示该一个或多个历史目的地位置的数据，通信服务器装置202a可以被配置为确定指示与预定历史时间段(例如，过去24小时)相关联的该一个
或多个历史目的地位置的数据。
42.图2b示出了展示在用于向用户推荐运输相关服务的一个或多个兴趣点的通信服务器装置中并且在通信服务器装置的处理器的控制下执行的方法的流程图250。
43.响应于接收到包括指示该用户的位置的数据字段的用户数据，并且进一步响应于确定不存在与该用户相关联且与运输相关服务相对应的历史数据，在251处，检索表示具有该位置的地图的数据，并且在252处，传输表示该地图的数据供该用户的用户通信设备接收，以经由该用户通信设备向该用户呈现该地图，以便确定该地图上的兴趣点作为运输相关服务的推荐起点位置。
44.响应于确定在一个或多个数据记录中存在与运输相关服务相对应的历史数据，历史数据与用户相关联，在255处，基于历史数据来确定第一兴趣点作为运输相关服务的推荐起点位置，在256处，基于历史数据来确定第二兴趣点作为运输相关服务的推荐目的地位置，第一兴趣点和第二兴趣点彼此配对且对应于历史运输相关服务，并且在257处，传输指示第一兴趣点的数据和指示第二兴趣点的数据供用户通信设备接收。
45.响应于确定存在该历史数据，并且进一步响应于接收到包括指示时间的数据字段的用户数据，在256处，该方法可以包括基于该历史数据来确定该第二兴趣点在包括该时间的预定时间区间内与该第一兴趣点配对。
46.在各个实施例中，在255处，响应于确定存在该历史数据，并且进一步响应于接收到包括指示该用户的位置的数据字段的用户数据，该方法可以包括确定该历史数据中是否包括指示运输相关服务的一个或多个历史起点位置的数据，如果确定存在指示该一个或多个历史起点位置的数据，则基于指示该一个或多个历史起点位置的数据将距离该用户的位置最近的历史起点位置定义为该第一兴趣点，并且传输指示该历史起点位置的数据供该用户通信设备接收，以及如果确定不存在指示该一个或多个历史起点位置的数据，则确定指示该历史数据中所包括一个或多个历史目的地位置的数据，基于指示该一个或多个历史目的地位置的数据将距离该用户的位置最近的历史目的地位置定义为该第一兴趣点，并且传输指示该历史目的地位置的数据供该用户通信设备接收。
47.在各个实施例中，为了确定指示该一个或多个历史目的地位置的数据，该方法可以包括确定指示与预定历史时间段相关联的该一个或多个历史目的地位置的数据。
48.各个实施例可以进一步提供用于向用户推荐运输相关服务的一个或多个兴趣点的通信系统，该通信系统具有通信服务器装置(例如，202a，图2a)、至少一个用户通信设备、以及通信网络设备，该通信网络设备能够操作以使该通信服务器装置和该至少一个用户通信设备通过该通信网络设备与彼此建立通信，其中，该至少一个用户通信设备包括第一处理器和第一存储器，该至少一个用户通信设备被配置为在该第一处理器的控制下执行该第一存储器中的第一指令，以便传输包括指示该用户的位置的数据字段的用户数据供该通信服务器设备接收以进行处理，并且其中，该通信服务器装置包括第二处理器和第二存储器，该通信服务器装置被配置为在该第二处理器的控制下执行该第二存储器中的第二指令，以响应于接收到指示由该至少一个用户通信设备传输的该用户数据的数据，并且进一步响应于该通信服务器装置确定不存在与该用户相关联且与运输相关服务相对应的历史数据，检索表示包括该位置的地图的数据，并且传输表示该地图的数据供该至少一个用户通信设备接收，以经由该用户通信设备向该用户呈现该地图，以便确定该地图上的兴趣点作为运输
相关服务的推荐起点位置，以及响应于该通信服务器装置确定在一个或多个数据记录中存在与运输相关服务相对应的历史数据，该历史数据与该用户相关联，基于该历史数据来确定第一兴趣点作为运输相关服务的推荐起点位置，基于该历史数据来确定第二兴趣点作为运输相关服务的推荐目的地位置，该第一兴趣点和该第二兴趣点彼此配对且对应于历史运输相关服务，并且传输指示该第一兴趣点的数据和指示该第二兴趣点的数据供该至少一个用户通信设备接收。
49.应当理解，在通信服务器装置202a的上下文中的描述、在流程图250的上下文中描述的方法以及上文所描述的对应的通信系统可以彼此适用。
50.上文在通信服务器装置202a的上下文中所披露的技术、在流程图250的上下文中描述的方法以及上文所描述的对应的通信系统可以对应于下文要进一步描述的动作/场景“预测”。进一步，所述技术可以响应于与运输相关服务相对应的(软件)应用程序(例如，“app”)的激活或启动或者对该应用程序的激活或启动的检测(或确定)来执行，或者在用户请求或预订运输相关服务的过程开始时执行。
51.图2c示出了展示用于向用户推荐用于运输相关服务的一个或多个兴趣点(poi)的通信服务器装置202c的示意性框图。通信服务器装置202c包括处理器216c和存储器218c，其中通信服务器装置202c被配置为在处理器216c的控制下执行存储器218c中的指令，以响应于接收到包括指示该用户的位置(例如，当前位置或预计位置)的第一数据字段(例如，指示纬度(lat)值和经度(lng)值的数据)和指示对应于目的地位置(或下车位置)的用户请求的第二数据字段的用户数据，访问一个或多个数据记录中与运输相关服务相对应的历史数据，该历史数据与该用户相关联，访问指示在包括该位置的地理区域(例如，城市)中的至少一个目的地类别(例如，购物目的地、餐饮场所、交通枢纽等)中的多个排名靠前的兴趣点(例如，最具人气的poi；前3个、前5个或任何其他数量)的数据，基于该历史数据和指示该多个排名靠前的兴趣点的数据来确定一个或多个第一兴趣点作为运输相关服务的推荐目的地位置，并且传输指示该一个或多个第一兴趣点的数据255c供该用户通信设备接收。
52.处理器216c和存储器218c可以彼此耦合(如线217c所表示的)，例如，物理联接和/或电耦合。处理器216c可以如在处理器116(图1)的上下文中所描述的，和/或存储器218c可以如在存储器118(图1)的上下文中所描述的。
53.用户数据可以进一步包括指示表示用户身份的标识符(例如，用户id)的另一数据字段。
54.指示对应于目的地位置的用户请求的第二数据字段可以对应于用户点击与运输相关服务相对应的(软件)应用程序(例如，“app”)的输入框或输入数据字段(例如，目的地位置的输入数据字段)。
55.在各个实施例的上下文中，该历史数据可以包括指示多个历史目的地位置的数据，和/或指示该用户的一个或多个偏好的数据。
56.在各个实施例中，该历史数据可以包括指示该用户最常去的多个历史目的地位置(例如，3个最常去的位置、5个最常去的位置或任何其他数量)的数据，其中，为了访问该历史数据，通信服务器装置202c可以进一步被配置为访问指示该用户最常去的多个历史目的地位置的数据，并且为了确定该一个或多个第一兴趣点，通信服务器装置202c可以进一步被配置为基于指示该用户最常去的多个历史目的地位置的数据和指示多个排名靠前的兴
趣点的数据来确定该一个或多个第一兴趣点。
57.通信服务器装置202c可以进一步被配置为响应于接收到包括指示与起点位置相对应(或上车位置)的用户请求的数据字段的用户数据(其可以是与上文所描述的相同的用户数据或另一用户数据)，基于该历史数据和该位置来确定一个或多个第二兴趣点作为运输相关服务的推荐目的地位置，并且传输指示该一个或多个第二兴趣点的数据供该用户通信设备接收。
58.该历史数据可以包括指示多个历史起点位置的数据，并且可以基于多个历史起点位置来确定该一个或多个第二兴趣点。
59.指示与起点位置相对应的用户请求的数据字段可以对应于用户点击与运输相关服务相对应的(软件)应用程序(例如，“app”)的输入框或输入数据字段(例如，起点位置的输入数据字段)。
60.为了确定该一个或多个第二兴趣点，通信服务器装置202c可以被配置为将相对于该用户的位置在预定距离内的该一个或多个第二兴趣点确定为推荐起点位置。
61.通信服务器装置202c可以进一步被配置为针对该一个或多个第二兴趣点中的每个第二兴趣点传输指示该第二兴趣点与该用户的位置之间的距离的数据供该用户通信设备接收。
62.图2d示出了展示在用于向用户推荐运输相关服务的一个或多个兴趣点的通信服务器装置中并且在通信服务器装置的处理器的控制下执行的方法的流程图260。
63.响应于接收到包括指示位置的第一数据字段和指示对应于目的地位置的用户请求的第二数据字段的用户数据，在262处，访问一个或多个数据记录中与运输相关服务相对应的历史数据，该历史数据与该用户相关联，在264处，访问指示在具有该位置的地理区域中的至少一个目的地类别中的多个排名靠前的兴趣点的数据，在266处，基于该历史数据和指示该多个排名靠前的兴趣点的数据来确定一个或多个第一兴趣点作为该运输相关服务的推荐目的地位置，并且在268处，传输指示该一个或多个第一兴趣点的数据供该用户通信设备接收。
64.在各个实施例中，该历史数据可以包括指示该用户最常去的多个历史目的地位置的数据。在262处，访问指示该用户最常去的多个历史目的地位置的数据，并且在266处，基于指示该用户最常去的多个历史目的地位置的数据和指示多个排名靠前的兴趣点的数据来确定该一个或多个第一兴趣点。
65.响应于接收到包括指示与起点位置相对应的用户请求的数据字段的用户数据，该方法进一步包括基于该历史数据和该位置来确定一个或多个第二兴趣点作为运输相关服务的推荐起点位置，并且传输指示该一个或多个第二兴趣点的数据供该用户通信设备接收。
66.在各个实施例中，方法可以包括将相对于该用户的位置在预定距离内的该一个或多个第二兴趣点确定为推荐起点位置。
67.在各个实施例中，方法可以进一步包括针对该一个或多个第二兴趣点中的每个第二兴趣点传输指示该第二兴趣点与该用户的位置之间的距离的数据供该用户通信设备接收。
68.各个实施例可以进一步提供用于向用户推荐运输相关服务的一个或多个兴趣点
的通信系统，该通信系统具有通信服务器装置(例如，202c，图2c)、至少一个用户通信设备、以及通信网络设备，该通信网络设备能够操作以使该通信服务器装置和该至少一个用户通信设备通过该通信网络设备与彼此建立通信，其中，该至少一个用户通信设备包括第一处理器和第一存储器，该至少一个用户通信设备被配置为在该第一处理器的控制下执行该第一存储器中的第一指令，以便传输包括指示位置的第一数据字段和指示对应于目的地位置的用户请求的第二数据字段的用户数据供该通信服务器设备接收以进行处理，并且其中，该通信服务器装置包括第二处理器和第二存储器，该通信服务器装置被配置为在该第二处理器的控制下执行该第二存储器中的第二指令，以响应于接收到指示由该至少一个用户通信设备传输的该用户数据的数据，访问一个或多个数据记录中与运输相关服务相对应的历史数据，该历史数据与该用户相关联，访问指示在包括该位置的地理区域中的至少一个目的地类别中的多个排名靠前的兴趣点的数据，基于历史数据和指示该多个排名靠前的兴趣点的数据来确定一个或多个第一兴趣点作为运输相关服务的推荐目的地位置，并且传输指示该一个或多个第一兴趣点的数据供该至少一个用户通信设备接收。
69.应当理解，在通信服务器装置202c的上下文中的描述、在流程图260的上下文中描述的方法以及上文所描述的对应的通信系统可以彼此适用。
70.上文在通信服务器装置202c的上下文中所披露的技术、在流程图260的上下文中描述的方法以及上文所描述的对应的通信系统可以对应于下文进一步要描述的动作/场景“建议”。进一步，所述技术可以在场景“预测”之后按有序顺序执行，例如，在从场景“预测”获得的结果不如预期或者令请求或预订运输相关服务的用户不满意的情况下。
71.图2e示出了展示用于向用户推荐运输相关服务的一个或多个兴趣点(poi)的通信服务器装置202e的示意性框图，而图2f示出了展示可以由通信服务器装置202e生成的数据记录240的示意性框图。
72.通信服务器装置202e包括处理器216e和存储器218e，其中通信服务器装置202e被配置为在处理器216e的控制下执行存储器218e中的指令，以响应于接收到包括指示用户的位置(例如，当前位置或预计位置)的第一数据字段(例如，指示纬度(lat)值和经度(lng)值的数据)和具有指示由该用户输入的信息的输入数据的第二数据字段的用户数据，该信息至少部分地将该用户所请求的位置描述为运输相关服务的起点位置或目的地位置，基于该输入数据生成具有多个候选数据字段242、242b、242c至242n的一个或多个数据记录240，该多个候选数据字段具有用于对应的多个候选兴趣点的数据243a、243b、243c至243n，在一个或多个数据记录240中针对多个候选数据字段242a、242b、242c至242n中的每个候选数据字段生成用于关键字、区域、人气、时间安排和距离中的至少两项标准的相应标准数据字段(作为非限制性示例，展示了候选数据字段242a的相应标准数据字段244a、246a以及候选数据字段242c的相应标准数据字段244c、246c)，在相应标准数据字段(例如，244a、246a、244c、246c)中的每个标准数据字段中生成指示与候选兴趣点的对应标准相关联的单独得分的数据(作为非限制性示例，分别展示了标准数据字段244a、246a、244c、246c的数据245a、247c、245c、247c)。
73.对于关键字，基于该信息与描述该候选兴趣点的名称的一个或多个词(例如，全名、(多个)部分名称、(多个)首字母缩略词)之间的相似度来确定单独得分。对于区域，基于包括该用户的位置的第一地理区域(例如，城市)与包括该候选兴趣点的第二地理区域(例
如，城市)之间的接近度来确定单独得分。对于人气，基于一个或多个历史数据记录中与运输相关服务相对应的历史数据，基于该候选兴趣点历史上被(例如，任何一个或多个用户，即，不仅包括请求运输相关服务的用户，还考虑其他(多个)用户的(多个)偏好)选为历史运输相关服务的请求位置的次数来确定单独得分(例如，该候选兴趣点已经被选为历史起点位置(如果请求的位置是起点位置)或历史目的地位置(如果请求的位置是目的地位置)的次数)。对于时间安排，基于对应于一个或多个历史数据记录(其可以是与上述相同的(多个)历史数据记录)中的运输相关服务的历史数据，该历史数据与该用户相关联，基于该候选兴趣点在定义的时间被用户选为请求位置(起点位置或目的地位置)的概率(例如，该候选兴趣点在早上、晚上或在限定的小时期间/内被选择的概率等)来确定单独得分。对于距离，基于该用户的位置与该候选兴趣点之间的距离来确定单独得分。
74.通信服务器装置202e可以被配置为针对每个候选数据字段242a、242b、242c至242n基于(针对该至少两项标准确定的)单独得分来生成对应候选兴趣点的最终得分，处理指示这些最终得分的数据，并且根据对指示这些最终得分的数据的处理结果，传输指示该多个候选兴趣点的数据255e供该用户通信设备接收以经由该用户通信设备呈现该多个候选兴趣点。在各个实施例中，对于要从通信服务器装置202e传输的数据255e，多个候选兴趣点可能已经根据处理结果进行了排序。
75.处理器216e和存储器218e可以彼此耦合(如线217e所表示的)，例如，物理联接和/或电耦合。处理器216e可以如在处理器116(图1)的上下文中所描述的，和/或存储器218e可以如在存储器118(图1)的上下文中所描述的。
76.用户数据可以进一步包括指示表示用户身份的标识符(例如，用户id)的另一数据字段。
77.通信服务器装置202e可以接收包括指示时间(点)(例如，当前时间(点)或预计时间(点)或计划时间(点))的数据字段的用户数据(其可以是具有第一数据字段和第二数据字段的相同用户数据)。
78.作为非限制性示例，请求的位置可以由具有8个字母的字符串的全名来表示或描述，并且输入的信息可以包括名称的一部分(例如，全部8个字母的(仅)前5个字母、全名(即8个字母)或表示请求的位置的首字母缩略词)。
79.应当理解，可以存在任何数量y的候选数据字段，其中y≥2(即，2个或更多个)。
80.为了处理指示最终得分的数据，通信服务器设备202e可以被配置为基于指示这些最终得分的数据在一个或多个数据记录240中根据多个候选兴趣点的最终得分生成指示该多个候选兴趣点的排序的排名数据(例如，最终得分的降序)，并且为了传输该数据，该通信服务器装置202e可以被配置为传输指示该多个候选兴趣点的数据255e以经由该用户通信设备按照根据该排名数据的顺序来呈现该多个候选兴趣点。在各个实施例中，对于要从通信服务器装置202e传输的数据255e，多个候选兴趣点可能已经根据排名数据进行了排序。
81.为了处理指示最终得分的数据，通信服务器装置202e可以被配置为基于指示这些最终得分的数据并且针对该多个候选兴趣点的每个候选兴趣点将这些最终得分与指示该候选兴趣点与请求的位置的匹配相关性的阈值进行比较，并且为了传输该数据，通信服务器装置202e可以被配置为传输指示最终得分被确定为等于或高于该阈值的候选兴趣点的数据255e。
82.为了生成最终得分，通信服务器装置202e可以被配置为通过单独得分的加权和来生成最终得分。
83.在各个实施例中，该至少两项标准可以包括区域，并且响应于区域的单独得分被确定为指示第一地理区域和第二地理区域在不同的国家，通信服务器装置202e可以进一步被配置为排除(或忽略)该候选兴趣点。
84.为了生成相应标准数据字段(例如，244a、246a、244c、246c)，通信服务器装置202e可以被配置为针对每个候选数据字段242a、242b、242c至242n生成关键字、区域、人气、时间安排和距离中的至少三项标准的相应标准数据字段。
85.为了生成相应标准数据字段(例如，244a、246a、244c、246c)，通信服务器装置202e可以被配置为针对每个候选数据字段242a、242b、242c至242n生成关键字、区域、人气、时间安排和距离中的至少四项标准的相应标准数据字段。
86.在各个实施例中，响应于该信息至少部分地将该请求位置描述为起点位置，为了生成相应标准数据字段(例如，244a、246a、244c、246c)，通信服务器装置202e可以被配置为针对每个候选数据字段242a、242b、242c至242n生成关键字、区域、人气、时间安排和距离中的所有标准的相应标准数据字段。
87.图2g示出了展示在用于向用户推荐运输相关服务的一个或多个兴趣点的通信服务器装置中并且在通信服务器装置的处理器的控制下执行的方法的流程图270。
88.响应于接收到包括指示该用户的位置的第一数据字段和具有指示由该用户输入的信息的输入数据的第二数据字段的用户数据，该信息至少部分地将该用户所请求的位置描述为运输相关服务的起点位置或目的地位置，在272处，基于该输入数据生成包括多个候选数据字段的一个或多个数据记录，该多个候选数据字段具有对应的多个候选兴趣点的数据。在274处，针对该多个候选数据字段中的每个候选数据字段在该一个或多个数据记录中生成关键字、区域、人气、时间安排和距离中的至少两项标准的相应标准数据字段。在276处，在相应标准数据字段中的每个标准数据字段中，生成指示与候选兴趣点的对应的标准相关联的单独得分的数据，其中，对于关键字，基于该信息与描述该候选兴趣点的名称的一个或多个词之间的相似度来确定该单独得分，对于区域，基于包括该用户的位置的第一地理区域与包括该候选兴趣点的第二地理区域之间的接近度来确定单独得分，对于人气，基于一个或多个历史数据记录中与运输相关服务相对应的历史数据，基于该候选兴趣点历史上被选为历史运输相关服务的请求位置的次数来确定单独得分，对于时间安排，基于一个或多个历史数据记录中与运输相关服务相对应的历史数据，该历史数据与该用户相关联，基于该候选兴趣点在定义的时间被该用户选为该请求位置的概率来确定单独得分，并且对于距离，基于该用户的位置与该候选兴趣点之间的距离来确定单独得分。在278处，对于每个候选数据字段，基于单独得分生成对应候选兴趣点的最终得分。在280处，处理指示这些最终得分的数据。在282处，根据对指示这些最终得分的数据的处理结果，传输指示多个候选兴趣点的数据供该用户通信设备接收以经由用户通信设备呈现该多个候选兴趣点。在各个实施例中，对于要传输的指示多个候选兴趣点的数据，多个候选兴趣点可能已经根据处理结果进行了排序。
89.在各个实施例中，在280处，可以基于指示最终得分的数据在一个或多个数据记录中根据多个候选兴趣点的最终得分生成指示该多个候选兴趣点的排序的排名数据，并且在
282处，可以传输指示该多个候选兴趣点的数据以经由该用户通信设备按照根据该排名数据的顺序来呈现该多个候选兴趣点。在各个实施例中，对于要传输的指示多个候选兴趣点的数据，多个候选兴趣点可能已经根据排名数据进行了排序。
90.在各个实施例中，在280处，可以基于指示最终得分的数据并且针对多个候选兴趣点的每个候选兴趣点将最终得分与指示候选兴趣点与请求的位置的匹配相关性的阈值进行比较，并且在282处，可以传输指示最终得分被确定为等于或高于该阈值的候选兴趣点的数据。
91.在各个实施例中，在278处，可以通过单独得分的加权和来生成最终得分。
92.在各个实施例中，该至少两项标准可以包括区域，并且响应于区域的单独得分被确定为指示第一地理区域和第二地理区域在不同的国家，该方法可以进一步包括排除该候选兴趣点。
93.在各个实施例中，在274处，可以针对每个候选数据字段生成关键字、区域、人气、时间安排和距离中的至少三项标准的相应标准数据字段。
94.在各个实施例中，在274处，可以针对每个候选数据字段生成关键字、区域、人气、时间安排和距离中的至少四项标准的相应标准数据字段。
95.在各个实施例中，响应于该信息至少部分地将该请求位置描述为起点位置，在274处，可以针对每个候选数据字段生成关键字、区域、人气、时间安排和距离中的所有标准的相应标准数据字段。
96.各个实施例可以进一步提供用于向用户推荐运输相关服务的一个或多个兴趣点的通信系统，该通信系统具有通信服务器装置(例如，202e，图2e)、至少一个用户通信设备、以及通信网络设备，该通信网络设备能够操作以使该通信服务器装置和该至少一个用户通信设备通过该通信网络设备与彼此建立通信，其中，该至少一个用户通信设备包括第一处理器和第一存储器，该至少一个用户通信设备被配置为在该第一处理器的控制下执行该第一存储器中的第一指令，以便传输包括指示该用户的位置的第一数据字段和具有指示由该用户输入的信息的输入数据的第二数据字段的用户数据供该通信服务器装置接收以进行处理，该信息至少部分地将该用户所请求的位置描述为运输相关服务的起点位置或目的地位置，并且其中，该通信服务器装置包括第二处理器和第二存储器，该通信服务器装置被配置为在该第二处理器的控制下执行该第二存储器中的指令，以响应于接收到指示由该至少一个用户通信设备传输的该用户数据的数据，基于该输入数据生成包括多个候选数据字段的一个或多个数据记录，该多个候选数据字段具有对应的多个候选兴趣点的数据，在该一个或多个数据记录中针对该多个候选数据字段中的每个候选数据字段生成关键字、区域、人气、时间安排和距离中的至少两项标准的相应标准数据字段，在相应标准数据字段中的每个标准数据字段中生成指示与候选兴趣点的对应标准相关联的单独得分的数据，其中，对于关键字，基于该信息与描述该候选兴趣点的名称的一个或多个词之间的相似度来确定单独得分，对于区域，基于包括该用户的位置的第一地理区域与包括该候选兴趣点的第二地理区域之间的接近度来确定单独得分，对于人气，基于一个或多个历史数据记录中和运输相关服务相对应的历史数据，基于该候选兴趣点历史上被选为历史运输相关服务的请求位置的次数来确定单独得分，对于时间安排，基于一个或多个历史数据记录中和运输相关服务相对应的历史数据，该历史数据与该用户相关联，基于该候选兴趣点在定义的时间被
该用户选为该请求位置的概率来确定单独得分，对于距离，基于该用户的位置与该候选兴趣点之间的距离来确定单独得分，对于每个候选数据字段，基于这些单独得分生成对应的候选兴趣点的最终得分，处理指示最终得分的数据，并且根据对指示这些最终得分的数据的处理结果，传输指示该多个候选兴趣点的数据供该用户通信设备接收以经由用户通信设备呈现该多个候选兴趣点。
97.应当理解，在通信服务器装置202e的上下文中的描述、在流程图270的上下文中描述的方法以及上文所描述的对应的通信系统可以彼此适用。
98.上文在通信服务器装置202e的上下文中所披露的技术、在流程图270的上下文中描述的方法以及上文所描述的对应的通信系统可以对应于下文进一步要描述的动作/场景“搜索”。进一步，所述技术可以在场景“建议”之后按有序顺序执行，例如，在从场景“建议”获得的结果不如预期或者令请求或预订运输相关服务的用户不满意的情况下。
99.图2h示出了展示用于向用户推荐运输相关服务的一个或多个兴趣点的通信服务器设备202h的示意性框图，通信服务器设备202h被配置为通信服务器装置202a，并且进一步被配置为通信服务器装置202c或通信服务器装置202e中的至少一个。
100.通信服务器设备202h可以被配置为通信服务器装置202a，并且此后(顺序地)进一步被配置为通信服务器装置202c。通信服务器设备202h可以此后(顺序地)进一步被配置为通信服务器装置202e。通信服务器设备202h可以此后(顺序地)进一步被配置为检索表示包括用户的位置的地图的数据，并且传输表示该地图的数据供该用户的用户通信设备接收，以经由该用户通信设备向该用户呈现该地图，以便确定(例如，基于该用户的位置)该地图上的(单个)兴趣点作为运输相关服务的推荐起点位置(或上车位置)。
101.图2i示出了展示在用于向用户推荐运输相关服务的一个或多个兴趣点的通信服务器设备中并且在通信服务器设备的处理器的控制下执行的方法的流程图290。在292处，执行如本文在流程图250的上下文中所描述的方法。在294处，执行如本文在流程图260的上下文中所描述的方法或如本文在流程图270的上下文中所描述的方法中的至少一种方法。
102.在各个实施例中，可以执行如本文在流程图250的上下文中所描述的方法，并且此后，可以执行如本文在流程图260的上下文中所描述的方法。此后，可以执行如本文在流程图270的上下文中所描述的方法。此后，可以检索表示包括用户的位置的地图的数据，并且可以传输表示该地图的数据供该用户的用户通信设备接收，以经由该用户通信设备向该用户呈现该地图，以便确定该地图上的兴趣点作为运输相关服务的推荐起点位置。
103.各个实施例可以进一步提供用于向用户推荐运输相关服务的一个或多个兴趣点的通信系统，该通信系统具有通信服务器设备(例如，202h，图2h)、包括处理器和存储器的至少一个用户通信设备、以及通信网络设备，该通信网络设备能够操作以使该通信服务器设备和该至少一个用户通信设备通过该通信网络设备与彼此建立通信，其中，该通信服务器设备被配置为通信服务器装置202a，并且其中，该至少一个用户通信设备被配置为在该处理器的控制下执行该存储器中的指令，以便传输包括指示该用户的位置的数据字段的用户数据供该通信服务器设备接收以进行处理，并且其中，该通信服务器设备进一步被配置为以下各项中的至少一项：通信服务器装置202c，其中，该至少一个用户通信设备进一步被配置为在该处理器的控制下执行该存储器中的指令，以便传输包括指示位置的第一数据字段和指示对应于目的地位置的用户请求的第二数据字段的用户数据供该通信服务器设备
接收以进行处理；或通信服务器装置202e，其中，该至少一个用户通信设备进一步被配置为在该处理器的控制下执行该存储器中的指令，以便传输包括指示该用户的位置的第一数据字段和具有指示由该用户输入的信息的输入数据的第二数据字段的用户数据供该通信服务器设备接收以进行处理，该信息至少部分地将该用户所请求的位置描述为运输相关服务的起点位置或目的地位置。
104.还可以提供具有指令的计算机程序产品，这些指令用于实施如本文在流程图250、260、270、290的上下文中所描述的方法中的至少一种方法。
105.还可以提供具有指令的计算机程序，这些指令用于实施如本文在流程图250、260、270、290的上下文中所描述的方法中的至少一种方法。
106.可以进一步提供存储有指令的非暂态存储介质，这些指令在由处理器执行时使处理器执行如本文在流程图250、260、270、290的上下文中所描述的方法中的至少一种方法。
107.在各个实施例的上下文中，历史数据可以存储在一个或多个(历史)数据记录中。
108.在各个实施例的上下文中，历史数据可以存储在一个或多个数据库中。
109.在各个实施例的上下文中，历史数据可以是预定时间段内(存储)的历史数据，例如，过去30天的历史数据。
110.在各个实施例的上下文中，用户通信设备可以包括但不限于智能电话、平板计算机、手持/便携式通信设备、台式计算机或膝上型计算机、终端计算机等。
111.在各个实施例的上下文中，运输相关服务可以包括或可以是打车运输服务。这可以包括例如汽车呼叫服务和(摩托)自行车呼叫服务。
112.在各个实施例的上下文中，运输相关服务可以涉及一个或多个自主车辆。
113.在各个实施例的上下文中，“app”或“应用程序”可以安装在用户通信设备上，并且可以包括用于在该设备上执行的处理器可执行指令。作为非限制性示例，可以经由app来执行运输相关服务的预订。
114.现在将进一步详细描述各个实施例或技术。各个实施例可以涉及作为app端(前端)的客户端和服务器端(后端)。
115.本文所披露的技术的运输服务可能需要用户的上车点和下车点以匹配司机、规划路线和计算费用。poi服务负责根据用户的位置来推荐上车点和下车点。poi服务质量的一个度量是它能为客户(用户)方节省多少精力来找到上车点和下车点的合适poi。
116.各个实施例的poi服务可以包括预订流程中的4个主要动作或场景，如图3a至图3d所示。这些场景包括“预测”、“建议”、“搜索”和“reversegeo”。
117.参考与“预测”场景相关的图3a，当用户或乘客(pax)打开对应的app时，该app调用poi预测端点以基于pax历史数据和当前位置来获得预测的上车点poi和预测的下车点poi。在图3a中，作为非限制性示例，预测的上车点poi 270示出为“塞蒂亚布迪公寓(setiabudi residence)”。
118.在各个实施例中，在打开app时执行预测动作。“预测”动作将始终执行，并且始终是打开app后或预订订单时执行的第一个动作。
119.参考与“建议”场景相关的图3b，例如，当预测的结果不如预期时，pax可以点击输入框271，并且app调用poi建议端点以基于pax历史数据、当前位置和城市人气poi来获得建议的poi列表272。
120.参考与“搜索”场景相关的图3c，例如，当建议的结果不如预期时，pax可以例如通过键入一个或多个关键字273来输入信息，并且app调用poi搜索端点以基于(多个)关键字来获得匹配的poi列表274。
121.参考与“reversegeo”场景相关的图3d，例如，当建议的/搜索结果不如预期时，pax可以前往地图275以移动pin 276，以调用poi reversegeo端点来找到poi。
122.相应poi预测、建议、搜索和reversegeo端点可以位于服务器端(例如，位于通信服务器装置处)，或者，换句话说，与预测、建议、搜索和reversegeo场景相关的处理可以在服务器端执行，然后将结果返回给app端的用户。app端可以提供包括pax id、纬度、经度等中的一个或多个的信息以供处理。
123.总而言之，上述动作或场景可以按序列提供或示出给用户，以发现其所期望的上车点和/或下车点的poi。用户需要点击屏幕的次数越少，他们就越容易获得poi以生成预订订单。作为整个运输服务的生成预订订单的部分，poi服务需要高可用性和稳定性，这可能会给系统带来许多挑战。首先，一个挑战是如何处理在每日高峰时段爆发的并发请求，同时保持整个服务在响应时间方面的稳定。一方面，这需要机器的自动缩放，以便为每天不同的时间段配置适当数量的服务器(例如，云服务器)。另一方面，每个并发请求的资源必须在具有适当分配的资源的独立线程中进行管理，以便某些故障不会影响整个服务，从而保证高可用性。其次，另一个挑战是如何利用大量的历史数据来提供可以更准确地满足客户的需求的更好的推荐性能，因为poi服务的目标是节省用户获得期望的上车点和/或下车点所需的精力。
124.为了应对这些挑战并且保持poi服务的高可用性和稳定性，可以部署一些技术，如下文将要描述的。
125.·
已经利用弹性搜索来存储poi数据和执行poi查询。已经提出了各种索引来管理如r树、k-d树等大量几何数据，或者特定于移动对象以实现各种查询。另一种广泛使用的索引方法是地理散列(geohash)，该地理散列将地理位置编码成由字母和数字组成的短字符串，并且确保附近的地点共享类似的前缀。在各个实施例中，内部提供程序利用弹性搜索来存储poi数据。当用户位置(例如，描述为纬度和经度)的请求到达时，弹性搜索利用地理散列返回靠近给定位置的靠前poi，以进行下一步处理。其可以允许从一台机器水平缩放到数百台具有千兆兆字节数据的服务器。为了保持数十亿poi数据的响应时间稳定，可以分析主要搜索表达式的时间成本，并且可以确定瓶颈以进行特定优化。
126.·
redis是快速、开源的内存数据存储，用作数据库、高速缓存、消息代理和队列。redis可以位于服务器端，例如，位于通信服务器装置处。在各个实施例中，亚马逊弹性高速缓存(amazon elasticache)可以被适配用于redis，以根据不同的场景/应用程序需求以不同的方式高速缓存poi数据并且生成高速缓存密钥。这可以有助于将每秒查询(qps)的值控制在后面的数据库可以处理的范围内。应当理解，redis一般位于相关数据库之前，例如，mysql、dynamodb和弹性搜索。通常，服务器端(后端)的逻辑在从相关数据库获得回复时可以将请求结果写入redis。当下次出现相同的请求时，可以直接从redis获得回复。
127.·
整个后端架构在golang中实施。由于其并行处理是基于goroutine和通道的，所以每个http请求都可以分配给独立的goroutine进行处理。即使它们中的一些受到损坏，整个过程也不会受到影响。goroutine非常轻量级，并且易于启动和停止，这使得golang在作
为各个实施例的后端语言的稳定性方面优于其他语言。
128.·
在分析大量历史数据之后，已经推导出可以在不同场景/应用程序中提供合理poi得分的排名模型。“冷启动”挑战也已经通过回退来解决，以便为新用户提供或保证客户体验。
129.下文将详细描述本文所披露的技术的基于golang的poi服务，包括支持在线poi推荐和发现的架构、不同场景下的poi推荐以及服务的一些结果。
130.作为2009年发布的语言，当时多核处理器已经可用，“go”是用于并发而构建的。与在java中从堆中消耗大约1mb内存的线程不同，go具有消耗约2kb内存的goroutine，因此可以旋转数百万个goroutine。此外，goroutine带有通道以在它们之间安全通信并且避免使用互斥锁。go是一种类似于c/c 的编译型语言。其还像java一样使用垃圾收集来分配和去除对象。这可以保证硬件上的运行速度，因为其可以避免java vm步骤的字节码解释，并且可以避免像c/c 等语言中释放和分配变量的烦恼。go具有良好且相当稳定的语法。这使得用go编写的代码易于维护。go中既没有类也没有继承。开发人员可以容易地理解代码，并且不同的代码部分不会相互深度影响。进一步，开发人员可以在相同的代码基础上一起工作。
131.微服务是一种软件开发技术，它将应用程序构建为松散耦合的服务的集合。在微服务架构中，服务是细粒度的，并且协议是轻量级的。在各个实施例中，poi服务是整个系统中的一种微服务。如果放大来看，像poi这样的微服务利用多层服务结构，如图4所示，展示了例如具有http服务器层472、逻辑层474和数据库层476的基于层的web服务结构470。层472的http服务器负责以负载平衡的方式将http请求从用户端发送到逻辑层474。逻辑层474起到根据http请求执行处理逻辑的作用。所有与逻辑处理相关的数据都可以存储在数据库层476中。当逻辑层474耗尽计算资源时，作为非限制性示例，可以广泛使用如亚马逊的asg(自动缩放组)等水平缩放。由于逻辑层474和数据层(即，数据库层476)是绝对分离的，因此某个逻辑层实例的故障不太可能导致用户数据的损坏或丢失。各个实施例的poi服务遵循这种服务架构。
132.对于分布式系统，由于cap(一致性、可用性和分区容忍度)可能无法同时满足，因此web服务必须能够阻止级联故障并在故障不可避免的复杂分布式系统中实现弹性。对于poi服务，作为非限制性示例，hystrix可以用于实现或保证通过设置断路器回复的服务的响应时间。
133.由于逻辑层经常需要来自数据层的用户数据，高速缓存可以广泛地用于保护后面的数据库不会由于突发工作负载而停机，并缩短每个请求的响应时间。可以存在两种可以使用的方法：一种是在数据库层之前设置高速缓存层，并且另一种是在每个逻辑实例的存储器中设置单独的高速缓存。对于各个实施例的poi服务，redis被适配为数据库层之前的高速缓存，并且根据不同的场景/应用程序需求设置高速缓存密钥和到期时间。与从头开始建立高速缓存模块相比，利用例如redis的亚马逊弹性高速缓存可以提供弹性缩放和几乎没有或最少的停机服务，这可以在服务稳定性方面提供帮助。
134.现在将通过以下非限制性示例来描述各个实施例的poi服务架构以及在线poi推荐中的高速缓存的使用。
135.图5示出了展示用于poi服务的系统570的概览的示意图。poi系统570可以分为四个部件：首先，api 571a是支持四个poi用户场景(例如，预测、建议、搜索和reversegeo)的
层，其结果来自中间件层571b。其次，调度器571c向提供程序571d分派http请求。第三，提供程序571d是从poi提供程序(例如，内部提供程序572a和/或外部提供程序572b)获得poi并将其返回到中间件层571b的层。第四，中间件571b是处理从提供程序层571d返回的poi的层。api层571a、中间件层571b、调度器571c和提供程序层571d可以位于服务器端(例如，位于通信服务器装置处)。下面将进一步描述api层571a、中间件层571b和提供程序层571d。
136.·
api 571a：有四个端点：预测、建议、搜索和reversegeo。预测和建议基于pax历史数据，该数据可以存储在基于pax 30天的历史数据被命名为预测器db的mysql db中。当用户或乘客打开对应的app时，该app调用poi预测端点以基于pax(用户)历史数据和用户的当前位置来获得预测的上车点poi和/或预测的下车点poi。当预测结果不如预期时，pax点击app中的输入框，并且app调用poi建议端点以基于历史数据、用户当前位置和城市人气poi(即，对应于上车点poi和/或下车点poi的城市中的人气poi)来获得建议的poi列表。当建议结果不如预期时，pax键入关键字，app调用poi搜索端点以基于关键字来获得匹配的poi列表。当建议结果不如预期时，pax可以前往地图以移动pin，以调用poi reversegeo端点来找到poi。在各个实施例的上下文中，术语“端点”可以意指或指可以在代码中调用的模块。这种模块可以包括一组指令。
137.·
中间件571b：存在具有如以下功能的若干中间件：将从不同提供程序571d接收的poi中的地点id(标识符或标识)归一化为统一格式的唯一地点id，将输入poi中的不良poi列入黑名单，去除输入poi中的重复poi，以及基于一些字段对输入poi进行排名，并在建议和搜索端点的响应中获得结果(预测和reversegeo仅返回一个poi，因此不需要进行排名)。
138.·
提供程序571d：基于pax位置，可以获得与对应的城市相关的数据，并且可以使用其相关联的城市配置。不同的城市可以具有用于确定应该使用哪些提供程序的不同配置。通常，可以存在两组或三组提供程序，并且在同一组中，可以并行向这些提供程序发送搜索请求。如果同一组(例如，第一组)中的所有提供程序都出现故障或没有响应，则发送请求到第二组(或后续)提供程序。作为非限制性示例，并且取决于配置，内部提供程序572a和谷歌(外部提供商572b)可以被设置为第一组，foursquare(外部提供程序572b)可以被设置为第二组，并且剩余的(多个)提供程序可以被设置为第三组。
139.关于在线poi推荐中的高速缓存，如也可以在图5中看到的，高速缓存可以部署在三个层中，即，api层571a、中间件层571b和提供程序层571d。下面将进一步描述高速缓存设置。
140.简而言之，api层571a发送请求，调度器层571c将请求分派给提供程序571d。提供程序571d发送回结果。中间件571b处理结果以获得期望的或想要的结果。最后，将结果返回给用户。高速缓存和数据库可以用于存储过去用于poi推荐的请求和结果。
141.·
api层571a：当http请求(例如，从服务器573)进入api层571a时，第一高速缓存层是将整个url作为高速缓存密钥的http高速缓存574，并且高速缓存的生存时间(ttl)可以被设置为例如30秒。对于搜索场景，该高速缓存设置可以用于附近用户在相同地点的重复试验(请参考图3c和对应的描述)。建议(请参考图3b和对应的描述)和搜索两者都利用距离高速缓存577来存储先前请求中的响应结果。建议利用paxid(或用户id)和(多个)地点(或(多个)位置)(例如，以纬度(lat)、经度(lng)的格式)作为密钥。搜索利用键入的(多个)
关键字和(多个)地点(lat/lng)作为密钥。高速缓存577的生存时间(ttl)可以被设置为例如一天。这可以允许在同一区域中的用户共享其响应。术语“生存时间(time-to-live)”可以意指数据在高速缓存中的有效时间。无效数据不能再使用。
142.存在另一个被命名为预测器高速缓存576的高速缓存，其可以存储对预测器db(即，数据库存储装置)578的每个请求的上车点或下车点。过去30天的历史数据可以存储在预测器db 578中，用于预测和建议，如下面将进一步讨论的。如果对预测器db 578的请求可以由预测器高速缓存576回答，则不需要查询后面的数据库(即，预测器db 578)。
143.在http高速缓存574、预测器高速缓存576与距离高速缓存577之间，可以存在一组服务器(例如，两个服务器被表示为575a、575b)。
144.预测器db 578可以位于微服务的数据库层(例如，图4的数据库层476)。通常，逻辑层474首先浏览预测器高速缓存层576。当未命中发生时，浏览或访问预测器db 578。
145.预测器db 578和预测器高速缓存576位于服务器端，例如，位于通信服务器装置处。
146.·
提供程序层571d：当请求进入提供程序层571d时，该请求首先尝试命中每个提供程序的高速缓存以获得响应(例如，内部提供程序高速缓存581、谷歌高速缓存583a、foursquare高速缓存583c和“其他”(或“等”)高速缓存583b(这里“其他”可以指一个或多个其他特定提供程序))。任何一个或所有外部提供程序(例如，谷歌583a、foursquare 583c以及等等583b)的ttl可以是很多天。存储来自内部提供程序572a的数据的内部提供程序高速缓存581的ttl可以是10分钟。这可能是因为内部提供程序572a中的poi数据(例如，关于发现的poi的添加和/或更新)可以被更频繁地更新，并且新的poi数据可以以更短的ttl更快地生效。应当理解，ttl时间安排可以是可变的，这取决于更新的频率。图5还示出了对应于内部提供程序572a的数据库存储装置582，以及外部提供程序谷歌、“其他”和foursquare的对应的云服务器584a、584b、584c。
147.·
中间件层(middlewares layer)571b：当提供程序571d的响应进入中间件571b以处理返回的poi时，也有各种高速缓存来帮助处理中间件功能。例如，通用高速缓存(例如，详细高速缓存579c)存储在弹性搜索中，并且当poi详细高速缓存579c包含poi详细描述(例如，poi名称、类别、位置等)时，ttl可以是一天。可以存在元高速缓存579a，其可以将ttl设置为一天以存储关于poi是否被列入黑名单的poi状态。进一步，可以存在排名579d和入口579b的相应高速缓存，以存储请求的排名和入口信息。例如，“入口”标志着大型公共设施可供上车或下车的地点，如大型购物商场和机场的门。关于这些地点的准确上车点和下车点的入口信息可以极大地改善两者的客户体验。
148.图5还示出了分别对应于元高速缓存579a、入口高速缓存579b、详细高速缓存579c的数据库存储装置580a、580b、580c。
149.总的来说，服务器可以处理(多个)请求。高速缓存可以存储(多个)结果，以避免过多的请求进入数据库。数据库存储装置可以存储用户数据。提供程序的云服务器可以回答发送给它们的请求。
150.现在将通过以下非限制性示例进一步描述各个实施例的在线poi推荐。
151.在各个实施例中，reversegeo根据移动的pin返回poi。
152.在各个实施例中，预测、搜索和建议等场景中的poi推荐可以基于历史数据来执
行。可以通过利用大量的历史数据来分别执行预测、搜索和建议，以提供可以更准确地满足用户或客户的需求的更好的推荐性能，因为poi服务的目标是节省用户获得期望的上车点和/或下车点所需的精力。对于建议和预测，历史数据可以存储在数据库中，例如，预测器db，并且数据可以在不同的表中提供和管理，并且候选poi可以通过查询获得。对于搜索，可以存在许多方面或考虑因素，例如，名称关键字、区域、人气、时间安排和距离，以计算加权和作为poi排名的组合得分。这些方面可以更好地描述poi特性，并且帮助用户更容易地找到目标poi。与仅考虑已知技术中的位置相似度相比，各个实施例的这种综合得分可以在搜索目标poi作为上车点和/或下车点的时给予用户更好的客户体验。最可能的点(包括例如上车点)的推荐将在下面描述。
153.搜索
154.在搜索场景中，用户在输入框或搜索框中键入一个或多个字，并且用户期望服务提供目标poi作为返回。为了使poi可排序，可以为每个poi分配得分，该得分可以由以下因子或标准中的一个或多个来确定：
155.·
关键字：
156.其测量搜索关键字与poi名称或poi名称的首字母缩略词之间的得分。每个poi可以具有多个首字母缩略词。作为非限制性示例，关键字匹配得分s
keyword
可以如等式1所示来计算。
157.s
keyword
＝max(sj,sa)
ꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀ
等式(1)，
158.其中，sj是poi名称和搜索关键字的jaccard相似度，并且如果搜索关键字与poi名称或首字母缩略词完全匹配，则sa返回1，否则返回0。
159.·
区域：
160.s
region
基于poi区域与pax(或用户)区域之间的接近度来测量得分。如果poi区域和pax区域相同，则s
region
的得分等于1，否则等于0，如等式2所示。
[0161][0162]
其中，getregion(.)是将任何位置(lat/lng)作为输入并返回该位置所在的对应的城市的函数。如果poi和pax在不同的国家，则poi将从结果列表中排除。因此，保证poi与pax位于同一个国家。
[0163]
·
人气：
[0164]spopularity(*)
基于poi已经被选为上车点/下车点的次数来对poi的人气进行评分。其可以定义如下：
[0165][0166][0167]
其中，count
pickup
是该poi被选为上车点的次数，count
dropoff
是该poi被选为下车点的次数，并且count
max
是结果集中的poi被选为上车点或下车点的最大次数。
[0168]
·
时间安排：
[0169]
基于在给定的某个时间pax或用户将在该poi上车和下车的概率来定义poi的得
分。例如，在早上，住宅区中的poi更有可能是上车点，而很低概率是下车点。poi的上车和上车时间分布可以离线预先计算，并且因此，poi成为上车点或上车点的概率可以自然推导出。详细的得分可以定义如下：
[0170]stiming(pickup)
＝distri
pickup
(tq)
ꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀ
等式(5)，
[0171]stiming(dropoff)
＝distri
dropoff
(tq)
ꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀ
等式(6)，
[0172]
其中，distri
*
(.)是poi的时间分布，并且tq是pax的查询时间。作为非限制性示例，在各个实施例中，poi的时间分布可以通过地图(参见图6)来实施，其中密钥是时间(从0:00到23:00的小时，表示一天中对应的24小时；参见图6的x轴)并且值(其指的是图6中的“频率”)是poi在历史中已经被选为上车点或下车点的比率，并且因此与poi在给定或限定的时间已经被选为上车点或下车点的次数相关。
[0173]
·
距离：
[0174]
其基于poi与pax的位置之间的距离来测量得分。该因子仅适用于上车点搜索。这可以由以下定义：
[0175]sdistance(pickup)
＝1/(1 e
(2*(dist-2))
)
ꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀ
等式(7)，
[0176]
其中，距离dist可以是可测量的，例如，以km(公里)为单位。
[0177]
最后得分然后可以通过加权和计算，如下所示：
[0178][0179]
其中，加权因子α
ι
由机器学习算法确定，并且f是上文标识的一组因子，即，关键字、区域、人气、时间安排、距离。然后，例如，poi可以根据其相应得分以降序进行排名。在app屏幕上仅列出推荐的poi，以呈现给用户或pax。
[0180]
建议
[0181]
在建议场景中，pax(用户)可以通过点击对应的app的输入框来获得上车点和下车点的建议的poi列表。由于上车点通常可以是pax位置附近的poi，而下车点通常可以是pax需要去的人气高的地点，因此上车点和下车点可以分开考虑。
[0182]
·
上车点：
[0183]
两个来源可以用于上车点。
[0184]
首先，可以使用数据库(例如，预测器db)，其中数据库可以通过管理关于poi偏好的表来存储30天的历史数据。该数据库存储了过去的pax id和对应的上车点。这允许通过pax id查询过去的历史上车点。
[0185]
其次，poi服务可以具有以“附近”命名的内部模块。该内部模块将pax位置(lat/lng)作为输入，并且通过根据配置调用不同的提供程序(参见例如，图5的提供程序层571d)，来根据距离返回附近的poi。在各个实施例中，配置定义了用于服务的不同提供程序的优先级以发出请求。例如，参考图5，内部提供程序572a和谷歌(作为外部提供程序572b的一部分)可以被设置为要查询的第一组提供程序，并且如果没有令人满意的结果，则可以查询第二组，例如foursquare(作为外部提供程序572b的一部分)。
[0186]
通过考虑这两个来源，可以考虑pax的个人偏好以及pax位置与poi之间的距离两者，这可以提高建议的(多个)上车点的准确性。
[0187]
·
下车点：
[0188]
两个来源可以用于下车点。
[0189]
首先，可以使用在数据库(例如，预测器db)中通过pax id存储最常使用的下车点(mfu下车点)的另一个表。这允许通过pax id查询最常使用的下车点。
[0190]
其次，可以使用redis中的靠前类别。其存储各个城市中人气靠前分类的poi(例如，食物、购物商场、机场等)，并且可以通过城市id查询。
[0191]
通过考虑这两个来源，可以建议pax的个人偏好和其他人的共同偏好两者，这可以提高建议的(多个)上车点的准确性。
[0192]
预测
[0193]
在预测场景中，可以提供预测的上车点和/或预测的下车点来填写预订订单。类似地，上车点和下车点可以分开考虑。
[0194]
·
冷启动：
[0195]
对于没有任何旧预订历史的新pax(用户)，预测可以使用位置(lat/lng)调用reversegeo作为回退来解决或克服冷启动问题。reversegeo将pax位置作为地图上的pin来为pax找到最近的poi。
[0196]
·
上车点：
[0197]
对于具有一些预订历史的pax，可以存在两个上车点预测来源，例如，首次最后下车点(ldf)和数据库(例如，预测器db)中的表。可以使用存储在数据库中的用户的先前的上车点poi。这可以通过查询pax id和wifi ssid(服务集标识符)来获得先前的上车点poi来完成。也就是说，pax过去经常出现的地点可以被推荐为预测的上车点。如果在数据库(例如，预测器db)中没有找到记录，则可以使用ldf。ldf是pax在过去24小时期间的最后一次下车点。对于预测器db和ldf两者，返回离用户位置最近的poi。如果所有的poi都在某个(或阈值)距离之外，则可以依赖reversegeo。
[0198]
ldf可以来自另一个(微)服务，该另一个服务访问不同于预测器db的数据库(例如，预订db)以获得pax的最后下车点。预订db可以位于或存储在mysql中。预订db可以位于服务器端，例如，位于通信服务器装置处。预订db可以存储预订信息，例如，预订代码、时间戳、乘客id、上车点和下车点等中的一个或多个。
[0199]
·
下车点：
[0200]
对于下车点预测，可以使用数据库(例如，预测器db)中的表，该表按一天中的小时将每个乘客(或用户)的下车点与上车点配对。给定任何pax id和时间段，通过查询可以容易地获得上车点和下车点对。与同一上车点配对的过去的下车点可以用作pax的下车点预测。也就是说，在下车点预测中，可以假设人们很可能遵循其日常生活安排。可以推荐在一天中的同一时间段期间在过去(多个)预订中pax选择的相同的下车点。
[0201]
现在将描述poi服务在生产环境中的性能。首先将描述生产环境设置和测量性能的度量，并且然后将描述根据poi服务的度量的性能结果。
[0202]
生产环境设置和测量度量
[0203]
poi服务的配置是亚马逊c5.4xlarge ec2实例。对于c5.4xlarge实例，亚马逊提供16个虚拟cpu核和32g存储器。存储装置为仅ebs，并且专用ebs带宽为3,500mbps。此外，为网络性能提供高达10gbps的带宽。高速缓存使用亚马逊的弹性高速缓存，以实施在线poi推
荐。
[0204]
为了测量poi服务在不同场景/应用程序中的稳定性，示出了往返时间(rtt)，该往返时间等于从发送请求到返回响应的持续时间。为了更好地描述rtt，根据百分之95和百分之99进行测量。高峰时段与非高峰时段之间的rtt变化越小，系统就越稳定。
[0205]
在系统中使用高速缓存的情况下，并且参考图5，高速缓存的有效性根据api 571a、中间件571b和提供程序571d层中的高速缓存命中率来测量。对于api层571a，预测场景中使用的预测器高速缓存576作为非限制性示例。对于中间件层571b，用于黑名单检查的元高速缓存579a被用作非限制性示例。对于提供程序层571f，分别代表内部提供程序572a和外部提供程序572b示出了内部提供程序和谷歌的高速缓存581、583a。
[0206]
性能结果
[0207]
poi服务的性能将根据上述测量度量从三个方面示出和描述。首先，提供一天期间的整体性能。然后，示出预测、建议、搜索和reversegeo等场景的往返时间(rtt)的性能。最后，示出高速缓存在poi服务中的使用。
[0208]
·
poi服务的整体性能：
[0209]
基于统计，poi服务的每秒查询率(qps)在一天期间变化。上午7:00至9:00和下午17:00至20:00的时段被定义为高峰时段。qps峰值一般出现在下午6:00左右。qps在午夜变得非常低。平均qps为约200每个实例。如预期的那样，cpu使用因qps而变化。每天最高cpu使用控制在60％以下。在goroutine方面，更多的qps使得生成更多的goroutine，并且导致增加cpu使用。goroutine数量的平均值为约1.2k每个实例。在一整天期间，存储器使用的值稳定在约25g每个实例。
[0210]
·
poi服务在各个场景/应用程序中的性能：
[0211]
图7a至图7d分别示出了预测、建议、搜索和reversegeo等场景的rtt。图7a至图7d中的y轴表示以“ms”为单位的往返时间(rtt)。图7a至图7d中的x轴中的标签“wed 16”指的是某个月的新的一天的开始，该标签是第16天并且这一天是星期三。
[0212]
在图7a至图7d中，表示为“警告”和“cb打开”的相应虚线分别指的是服务安全的时间阈值以及服务不能在所需时间内回复请求并且可以被视为无响应的时间阈值。
[0213]
如可以观察到的，针对图7a至图7d中的每一个示出了两条实线。上实线表示“p99”，即统计数据的百分之99，而下实线表示“p95”，即统计数据的百分之95。
[0214]
如针对图7c中的搜索可以观察到的，关于百分之95和百分之99的rtt分别为500ms和730ms。无论qps一天之内如何随时间改变，rtt都是稳定的。进一步，图7a中的预测、图7b中的建议和图7d中的reversegeo的结果在rtt方面示出了类似的稳定性。rtt的百分之95/百分之99在每种场景下变化，如下表1所示。搜索和reversegeo的逻辑涉及查询外部提供程序(例如，谷歌或foursquare)或弹性搜索，这导致了比预测和建议更长的rtt。
[0215]
表1：不同场景的rtt。
[0216][0217]
·
高速缓存在poi服务中的性能：
[0218]
表2示出了预测器db高速缓存576(对于api层571a)、元高速缓存579a(对于中间件层571b)、内部提供程序高速缓存581(作为内部提供程序572a)和谷歌高速缓存583a(作为外部提供程序572b)在一天之内的平均高速缓存命中率。如可以观察到的，预测器db高速缓存576和元高速缓存579a中的高高速缓存命中率示出了高速缓存使用在最小化或避免对数据库的重复请求方面的有效性。对于提供程序层571d，内部提供程序高速缓存581的高速缓存命中率远低于外部提供程序谷歌高速缓存583a的高速缓存命中率。这是因为内部提供程序被频繁更新，并且其高速缓存581的ttl比外部提供程序572b的ttl短得多。
[0219]
表2：高速缓存在不同层中的高速缓存命中率
[0220][0221]
如上文所描述的，可以提供一种用于实时兴趣点(poi)推荐的技术。对于运输服务(如打车服务)，例如，当(例如，通过app)产生或生成预订订单时，用户可以通过一个或多个动作来找到其所期望的上车点和/或下车点的poi。这些(多个)动作可以包括(i)“预测”，其中基于用户的历史数据或当前位置中的至少一个来产生预测的上车点poi和/或预测的下车点poi；(ii)“建议”，其中用户点击输入字段以基于用户的历史数据、当前位置或相关城市的人气poi中的至少一个来获得建议的poi列表；(iii)“搜索”，其中用户键入信息，例如，关键字，从而提供基于关键字的匹配的poi列表；以及(iv)“reversegeo”，其中用户可以前往地图以移动pin来找到poi。这些动作可以是彼此独立的。这些动作可以以任何顺序发生，或者可以以序列顺序发生，例如，可以首先执行“预测”，当预测的结果不如预期时随后执行“建议”，当建议的结果不如预期时执行“搜索”，并且当建议的/搜索结果不如预期时执行“reverse-geo”。预订流程可以以使用预测/建议/搜索/reversegeo的顺序来定义，以便找到poi作为上车点或下车点。顺序可以基于可以节省或最小化用户的精力的程度(通过在屏幕/app上的点击次数来测量)。
[0222]
然而，应该理解，对于任何一个预订订单，可能没有必要发生所有四个动作。换句话说，预测、建议、搜索、reversegeo动作中的任何一个、两个或三个或所有动作可以在用户为运输相关服务预订订单的过程期间执行。作为非限制性示例，用户可以选择跳过任何动作或步骤，以便自由地使用这些动作中的任一种，例如，在预测之后，用户可以直接跳转到reversegeo，而不经过建议和/或搜索。
[0223]
在各个实施例中，可以通过利用历史数据来分别执行预测、建议和搜索动作，以提供更好的推荐性能以获得期望的上车点和下车点。对于建议和预测，历史数据可以存储在不同表中的数据库中，例如，预测器数据库。对于搜索，可以考虑一个或多个方面/标准：名称关键字、区域、人气、时间安排和距离，以计算最终得分(例如，作为组合得分的加权和)用于poi排名。
[0224]
对于搜索，可以使用每个poi的以下标准的得分来计算加权和的最后得分，然后poi根据其得分以降序排名，随后向用户提供推荐的poi的列表：
[0225]
(i)关键字：基于搜索关键字和poi名称或poi名称的首字母缩略词来提供得分，当接近或匹配时，得分较高；
[0226]
(ii)区域：基于用户的区域(例如，国家)与poi区域之间的相关性或接近度来提供得分，当两个区域相同时，得分为“1”，否则为“0”(其中对应的poi随后从搜索列表中排除)；
[0227]
(iii)人气：基于poi被选为上车点(对于上车点搜索)或下车点(对于下车点搜索)的次数来提供得分，当poi被选择的次数较多时，得分较高；
[0228]
(iv)时间安排：基于用户在给定的某个时间在特定poi处上车或下车的概率来定义分数，在需要运输服务的特定时间，当poi是上车点(对于上车点搜索)或下车点(对于下车点搜索)的概率较高时，得分较高；
[0229]
(v)距离(仅适用于上车点搜索)：基于poi与用户的位置之间的距离来提供得分，当距离越小时，得分越高。
[0230]
对于建议，通过点击相关输入字段(例如，在app中)，提供了用于上车点和下车点的建议的poi的列表。因为上车点通常是靠近用户位置的poi，而下车点通常是用户需要去的人气高的地点，所以上车点和下车点是分开考虑的。在上车点方面，可以考虑两个来源，即：(i)存储关于poi偏好的30天历史数据的数据库(例如，预测器数据库)，该数据库位于存储用户id和过去对应的上车点的表中。这允许通过用户id查询过去的历史上车点；(ii)用户位置(纬度/经度)用作输入，并且然后根据距离提供附近的poi。因此，可以考虑用户的个人偏好以及用户pax位置与poi之间的距离两者，由此提高建议的上车点的准确性。在下车点方面，可以考虑两个来源，即：(i)通过用户id在单独的表中存储与最常使用的下车点(mfu下车点)相关的数据的数据库(例如，预测器数据库)。这允许通过用户id查询最常使用的下车点；(ii)各个城市中人气靠前分类的poi(例如，食物、购物商场、机场等)，并且可以通过城市id查询。因此，可以建议用户的个人偏好和一般的共同偏好两者，由此提高建议的下车点的准确性。
[0231]
对于预测，可以预测上车点和/或可以预测下车点以填写预订订单。类似于建议，上车点和下车点可以分开考虑。在用户具有历史预订数据的上车点方面，对于上车点预测可以考虑两个来源，即首次最后下车点(ldf)和具有数据库(例如，预测器数据库)中的数据的表。ldf是用户在24小时期间的最后一次下车点。如果pax不存在ldf，则可以使用存储在数据库(预测器db)中的用户的先前的上车点poi。这可以通过查询用户pax id和wifi ssid以获得先前上车点poi来完成。也就是说，在预测中，用户过去经常出现的地点可以被推荐为上车点。在用户具有历史预订数据的下车点方面，可以使用数据库(例如，预测器数据库)中的表，该表按一天中的小时将每个用户的下车点与上车点配对。给定用户id和时间段，通过查询可以获得上车点和下车点对。与同一上车点配对的过去的下车点可以用作用户的下车点预测。也就是说，在下车点预测中，可以假设人们很可能遵循其日常生活安排。可以推荐在一天中的同一时间段期间在过去预订中用户选择的相同的下车点。在没有任何历史预订数据的新用户“冷启动”的情况下，用户的位置(纬度/经度)可以用作地图上的pin以找到用户的最近的poi(类似于上文的“reversegeo”)。
[0232]
同样如上文所描述的，各个实施例的poi(兴趣点)服务可以用基于golang的微服务架构来构建。在线挑战可以通过根据合适的或唯一的场景或应用程序部署技术来解决。poi服务可以帮助增加完成的预订的比率，同时节省乘客寻找合适的上车点和/或下车点的精力。应当理解，预测、建议或搜索中的任何一个都可以根据用户(或乘客)的习惯或偏好来定制。进一步，可以优化系统的内部模块的时间成本。
[0233]
应当理解，仅通过示例的方式描述了本发明。在不脱离所附权利要求的精神和范围的情况下，可以对本文描述的技术进行各种修改。所披露的技术包括可以以独立方式或
彼此组合的形式提供的技术。因此，关于一种技术描述的特征也可以以与另一种技术组合来呈现。