阅读说明：本技术 推荐交通出行服务的系统和方法 (System and method for recommending transportation travel service ) 是由 张凌宇 于 2019-02-03 设计创作，主要内容包括：本申请涉及用于向用户推荐服务类型的系统和方法。该方法包括在设备中获取并存储由用户发出的至少两个先前服务请求,其中,所述至少两个先前服务请求中的每一个包括订单信息,所述订单信息包括请求服务的类型以及服务时间或服务位置中的至少一个。该方法还包括使用处理器基于至少两个先前服务请求的订单信息,生成服务类型预测模型。该方法还包括从用户接收包括当前服务时间或当前服务位置中的至少一个的服务请求,并使用服务类型预测模型,预测用户的首选服务类型。(The present application relates to systems and methods for recommending service types to users. The method includes obtaining and storing, in a device, at least two previous service requests issued by a user, wherein each of the at least two previous service requests includes order information including a type of a requested service and at least one of a service time or a service location. The method also includes generating, using the processor, a service type prediction model based on the order information of the at least two previous service requests. The method also includes receiving a service request from the user including at least one of a current service time or a current service location, and predicting a preferred service type of the user using a service type prediction model.)

推荐交通出行服务的系统和方法

相关申请的交叉引用

本申请请求于2018年2月6日提交的中国专利申请No.201810118481.4、于2018年2月6日提交的中国专利申请No.201810117330.7、于2018年2月6日提交的中国专利申请No.201810117329.4的优先权，其内容通过引用的方式整体并入本文。

技术领域

本申请一般涉及在线服务，更具体地，涉及用于在在线服务中推荐交通出行类型的系统和方法。

背景技术

在一个方面，随着互联网技术的发展，用于在线汽车的智能终端的使用已变得越来越流行。根据用户请求的服务类型，服务平台为请求服务类型提供对应的用户界面，使得用户可以在对应的用户界面中下订单。

在现有技术中，为了使用户能够快速请求服务，服务平台可以预测用户此刻需要的服务类型，并且从当前用户界面切换到与请求服务对应的用户界面，以减少在应用程序中的用户界面中手动选择所需用户界面所花费的时间。

但是，通常基于用户先前订单的服务类型来预测服务类型。在实际应用中，这种预测的准确性不够高。由于预测不准确，用户总是需要手动选择所需的用户界面，并且下订单所消耗的时间将增加。

在另一方面，以提供交通出行服务的电子商务技术为例，现有的交通出行平台可为用户提供不同的出行选项，并且用户可以在他/她出行之前提前预订车辆，例如，出租车、私家车(例如快车、专车、顺风车)、自行车等，以及预留车辆的信息，例如，公共汽车、火车等的出发时间可以被发送给用户。但是，如果为交通出行服务提供更多选择，则应考虑用户可能更喜欢哪种交通出行服务，或者哪种交通出行服务可以提高效率。以用户请求服务的实际场景为例，在晚上高峰时段，用户可以选择他/她需要等待很长时间的快车服务，因为没有提供快车服务的司机接受订单。如果用户试图打电话叫出租车，并且可能发生在很长一段时间(例如，2分钟)之后没有出租车司机接受订单的情况。然后用户可能需要请求专车。三种交通出行服务有不同的价格。快车服务的价格低于出租车服务，出租车服务的价格低于专车服务。然而，在这种情况下，许多用户愿意为专车服务支付更多的钱而不是等待更长的时间。

然而，在现有技术中，由于用户不能知道他/她应该选择哪种交通出行服务以便在他/她尝试每种交通出行服务之前让司机接受订单，所以发生上述情况，这消耗更多时间。

在另一方面，在实际场景中，用户经常需要在出行路线中的不同类型的车辆之间转移。例如，当用户从A(离位置A近)到B(离位置B近)开始他/她的行程时，用户可能需要从A骑自行车到附近的地铁站，然后乘坐地铁到B附近的另一个地铁站，然后乘坐快车或出租车到B。当然，从A到B还有其他交通出行模式。例如，用户可以从A乘坐快车到附近的公交车站，然后乘坐公共汽车到B附近的另一个公交车站，然后骑自行车到B。

可以看出，随着交通出行站和交通出行模式的增加，规划行程的复杂性增加，考虑如何到达另一个交通出行站，消耗更多的能量和时间，以及采取哪种交通出行模式，导致效率低下。因此，期望一种用于提高效率并节省行程时间的系统和方法。

发明内容

根据本申请的一个方面，提供了一种用于向用户推荐服务类型的方法。该方法可以包括在设备中获取并存储由用户发出的至少两个先前服务请求，其中，每个至少两个先前服务请求包括订单信息，包括请求服务的类型以及服务时间或服务位置中的至少一个；使用处理器，根据至少两个先前服务请求的订单信息，生成服务类型预测模型；从用户接收包括当前服务时间或当前服务位置中的至少一个的服务请求；并使用服务类型预测模型，预测用户的首选服务类型。

根据本申请的另一方面，提供了一种用于向用户推荐服务类型的系统。该系统可以包括至少一个包括一组指令的存储介质；至少一个处理器被配置为与所述至少一个存储介质通信，其中，当执行所述一组指令时，所述至少一个处理器被指示在所述设备中获取并存储由用户发出的至少两个先前服务请求，其中，每个至少两个先前服务请求包括订单信息，包括请求服务的类型以及服务时间或服务位置中的至少一个；使用处理器，根据至少两个先前服务请求的订单信息，生成服务类型预测模型；从用户接收包括当前服务时间或当前服务位置中的至少一个的服务请求；并使用服务类型预测模型，预测用户的首选服务类型。

根据本申请的另一方面，提供了一种非暂时性计算机可读介质。非暂时性计算机可读介质包括至少一个用于向用户推荐服务类型的一组指令，其中，当由计算装置的至少一个处理器执行时，所述至少一个组指令使计算装置执行方法。该方法包括在设备中获取并存储由用户发出的至少两个先前服务请求，其中，每个至少两个先前服务请求包括订单信息，包括请求服务的类型以及服务时间或服务位置中的至少一个；使用处理器，根据至少两个先前服务请求的订单信息，生成服务类型预测模型；从用户接收包括当前服务时间或当前服务位置中的至少一个的服务请求；并使用服务类型预测模型，预测用户的首选服务类型。

在一些实施例中，首选服务类型具有其对应的用户界面，并且该方法还包括向用户提供首选服务类型对应的用户界面。

在一些实施例中，服务位置包括特定位置或包括特定位置的统计地理区域。

在一些实施例中，服务时间包括特定时间点或包括特定时间点的目标统计时间段。

在一些实施例中，服务类型预测模型基于马尔可夫模型、高斯模型、混合高斯模型、贝叶斯模型或其组合。

在一些实施例中，服务类型预测模型是通过基于服务时间或服务位置中的至少一个，对所请求的服务类型进行聚类分析来生成的，获取每种服务类型的混合高斯模型，并根据混合高斯模型确定每种类型服务的概率密度值，其中，基于概率密度值，预测用户的首选服务类型。

在一些实施例中，通过使用贝叶斯模型和概率密度值，预测用户的首选服务类型，确定每种服务类型的第一概率值；并指定具有最高第一概率值的服务类型作为用户的首选服务类型。

在一些实施例中，指定包括确定具有最高第一概率值，以及最高第一概率值是否大于或等于第一预设阈值的服务类型；若是，则指定并推荐具有最高第一概率值的服务类型作为用户的首选服务类型。

在一些实施例中，在实现服务类型预测模型生成步骤之前，还包括基于用户发出的至少两个先前服务请求的订单信息，确定每种服务类型的频率，生成马尔可夫模型；通过将用户请求的上一次服务类型输入马尔可夫模型，获取每种服务类型的第二概率值；确定具有最高第二概率值的服务类型，以及最高第二概率值是否大于或等于第二预设阈值；若是，则指定并推荐具有最高第二概率值的服务类型作为用户的首选服务类型，或者若否，则执行服务类型预测模型生成步骤。

根据本申请的一个方面，提供了一种用于在服务请求时间为从物理位置请求交通出行服务的用户预估不同交通出行服务的订单成功率的方法。该方法可以包括在用户感测到交通出行用户界面(界面)的开启时，在界面上向用户提供至少两种交通出行服务；获取用户的物理位置；在所述用户的物理位置处，基于预先建立的评估标准，预估所述至少两种交通出行服务中的每种的订单成功率。

根据本申请的另一方面，提供了一种用于在服务请求时间为从物理位置请求交通出行服务的用户预估不同交通出行服务的订单成功率的系统。该系统可以包括至少一个包括一组指令的存储介质；至少一个处理器被配置为与至少一个存储介质通信，其中，当执行一组指令时，所述至少一个处理器指向用户感测到交通出行用户界面(界面)的开启时，在界面上向用户提供至少两种交通出行服务；获取用户的物理位置；并且，基于预先建立的评估标准，在用户的物理位置处预估所述至少两种交通出行服务中的每种的订单成功率。

根据本申请的另一方面，提供了一种非暂时性计算机可读介质。非暂时性计算机可读介质包括至少一组指令，用于预估用户在特定服务请求时间从一个物理位置请求交通出行服务时的不同交通出行服务的订单成功率，其中，当由计算装置的至少一个处理器执行时，所述至少一个组指令使计算装置执行方法。该方法可以包括在用户感测到交通出行用户界面(界面)的开启时，在界面上向用户提供至少两种交通出行服务；获取用户的物理位置；在所述用户的物理位置处，基于预先建立的评估标准，预估所述至少两种交通出行服务中的每种的订单成功率。

在一些实施例中，该方法还包括发送与界面上各交通出行服务相匹配的预估订单成功率。

在一些实施例中，预先建立的评估标准包括统计时间段评估标准和统计地理区域评估标准，并且订单成功率预估步骤包括确定界面开启时间属于目标统计时间段；确定用户的物理位置所在的目标统计地理区域；通过对目标统计时间段内在目标统计地理区域内提供的若干可用交通出行服务和服务请求总数进行统计分析，获取目标统计时间段内在目标统计地理区域内的每种交通出行服务的历史订单成功率；基于历史订单成功率预估多种类型的交通出行服务中的每种的订单成功率。

在一些实施例中，预先建立的评估标准还包括天气状况和交通状况中的至少一个，天气状况包括特殊天气状况，并且交通状况包括交通拥堵度。该方法还包括：如果在服务时间和用户物理位置，基于每种交通出行服务的性质，存在特殊天气状况或一定交通拥堵度中的至少一个，确定由特殊天气状况或特定交通拥堵度中的至少一个对所述至少两种交通出行服务中的每种施加的影响因子，基于其对应的历史订单成功率和影响因子，预估用户物理位置处的至少两种交通出行服务中的每种的订单成功率。

在一些实施例中，该方法还包括获取服务请求的日期并基于服务请求的日期确定目标统计日期，以及确定与目标统计日期对应的日期的历史订单成功率。

在一些实施例中，该方法还包括确定两种交通出行服务中的每种的预估的订单成功率是否小于预设的订单成功率阈值；对于预估的订单成功率小于预设订单成功率阈值的交通出行服务，获取服务请求时间随后的时间段(推迟的时间段)内每种交通出行服务的历史订单成功率；并将这些交通出行服务的历史订单成功率连同其对应的推迟的时间段一起发送，分别与界面上的交通出行服务相匹配。

根据本申请的一个方面，提供了一种用于在出行路线上向用户推荐交通出行模式的方法，其中出行路线包括至少两个路段，每个路段具有路段路线。该方法可以包括在存储介质中获取并存储用户的每个路段路线的先前出行数据，其包括出发位置和时间(出发数据)、到达位置和时间(到达数据)，以及使用的交通出行模式；处理器检索和使用路段的出发数据和到达数据，确定每条路段路线之间的相关性，为用户生成个性化的出行路线，每条路线包括一条或以上路段；通过处理器检索和使用每个路段的交通出行模式，在每个个性化出行路线上确定每个路段路线上各交通出行模式的使用频率，建立交通出行模式预估模型；根据用户当前位置从个性化出行路线中选择推荐的出行路线，包括推荐路段；并且使用交通出行模式预估模型，预测每个推荐路段的交通出行模式，为每个推荐路段生成推荐交通出行模式。

根据本申请的另一方面，提供了一种用于在出行路线上向用户推荐交通出行模式的系统，其中，出行路线包括至少两个路段，每个路段具有路段路线。该系统可以包括至少一个包括一组指令的存储介质；至少一个处理器被配置为与至少一个存储介质通信，其中，当执行一组指令时，指示所述至少一个处理器在所述存储介质中获取并存储每个路段路线的用户先前出行数据，包括出发位置和时间(出发数据)、到达位置和时间(到达数据)，以及使用的交通出行模式；处理器检索并使用路段的出发数据和到达数据，确定每条路段路线之间的相关性，为用户生成个性化的出行路线，每条路线包括一条或以上路段；通过处理器检索并使用每个路段的交通出行模式，在每个个性化出行路线上确定每个路段路线上各交通出行模式的使用频率，建立预估模型的交通出行模式；根据用户的当前位置，从个性化出行路线中选择推荐的出行路线，包括推荐路段；并且使用交通出行模式预估模型，预测每个推荐路段的交通出行模式，为每个推荐路段生成推荐交通出行模式。

根据本申请的另一方面，提供了一种非暂时性计算机可读介质。非暂时性计算机可读介质包括至少一个用于在出行路线上向用户推荐交通出行模式的一组指令，其中，出行路线包括至少两个路段，每个路段具有路段路线，其中，当由计算装置的至少一个处理器执行时，所述至少一个组指令使计算装置执行方法。该方法可以包括在存储介质中获取并存储用户的每个路段路线的先前出行数据，其包括出发位置和时间(出发数据)、到达位置和时间(到达数据)，以及使用的交通出行模式；处理器检索和使用路段的出发数据和到达数据，确定每条路段路线之间的相关性，为用户生成个性化的出行路线，每条路线包括一条或以上路段；通过处理器检索和使用每个路段的交通出行模式，在每个个性化出行路线上确定每个路段路线上各交通出行模式的使用频率，建立交通出行模式预估模型；根据用户当前位置从个性化出行路线中选择推荐的出行路线，包括推荐路段；并且使用交通出行模式预估模型预测每个推荐路段的交通出行模式，为每个推荐路段生成推荐交通出行模式。

在一些实施例中，该方法还包括向用户发送每个推荐的路段的推荐出行路线以及每个推荐路段的推荐交通出行模式。

在一些实施例中，通过基于S_i的到达时间和S_i+1的出发时间，确定每两个连续的路段S_i和S_i+1之间的时间间隔，生成个性化的出行路线；如果时间间隔小于或等于第一时间间隔阈值，则两个连续路段之间具有相关性；并连接相关路段，生成个性化的出行路线。

在一些实施例中，该方法还包括如果时间间隔大于第一时间间隔阈值但小于或等于第二时间间隔阈值，则根据S_i的到达位置和S_i+1的出发点，确定每两个连续的路段S_i和S_i+1之间的距离间隔；如果距离间隔小于或等于第一距离间隔阈值，则两个连续路段之间具有相关性；并连接相关路段，生成个性化的出行路线。

在一些实施例中，该方法还包括在每个路段上获取道路状况；并基于每个路段的路况，优化交通出行模式预估模型。

本申请的一部分附加特性可以在下面的描述中进行说明。通过对以下描述和相应附图的研究或者对实施例的生产或操作的了解，本申请的一部分附加特性对于本领域技术人员是明显的。本申请的特征可以通过对以下描述的具体实施例的各种方面的方法、手段和组合的实践或使用得以实现和达到。

附图说明

本申请将通过示例性实施例进行进一步描述。这些示例性实施例将通过附图进行详细描述。附图不按比例绘制。这些实施例是非限制性的示例性实施例，在这些实施例中，每个图中相同的编号表示相似的结构，其中：

图1是根据本申请的一些实施例所示的示例***通出行推荐系统的示意图；

图2是根据本申请的一些实施例所示的计算装置的示例性组件的示意图；

图3是根据本申请的一些实施例所示的示例性用户终端的示例性硬件和/或软件组件的示意图；

图4是根据本申请的一些实施例所示的预测服务类型的示例性过程的流程图；

图5是根据本申请的一些实施例所示的预测服务类型的过程500的流程图；

图6A和6B分别是根据本申请的一些实施例的请求出租车服务和快车服务的频率示意图；

图7是根据本申请的一些实施例所示的用于预测服务类型的过程700的流程图；

图8是根据本申请的一些实施例所示的服务类型预测设备的示意图；

图9是根据本申请的一些实施例所示的确定交通出行服务的订单成功率的过程900的流程图；

图10是根据本申请的一些实施例所示的用于预估交通出行服务的订单成功率的过程1000的流程图；

图11A是根据本申请的一些实施例所示的用于预估至少两种交通出行服务的订单成功率的过程1100的流程图；

图11B是根据本申请的一些实施例所示的显示交通出行服务的用户界面的示意图；

图11C是根据本申请的一些实施例所示的显示交通出行服务的用户界面的示意图；

图12是根据本申请的一些实施例的订单成功率预估设备的示意图；

图13是根据本申请的一些实施例所示的用于推荐交通出行模式的过程1300的流程图；

图14是说明根据本申请的一些实施例所示的用于推荐交通出行模式的过程1400的流程图；以及

图15是根据本申请的一些实施例的交通出行模式推荐设备的示意图。

具体实施方式

具体描述为了更清楚地说明本申请实施例的技术方案，下面将对实施例描述中所需要使用的附图作简单的介绍。显而易见地，下面描述中的附图仅仅是本申请的一些示例或实施例，对于本领域的普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图将本申请应用于其它类似情景。除非从语言环境中显而易见或另作说明，图中相同标号代表相同结构和操作。

如本申请和权利请求书中所示，除非上下文明确提示例外情形，

“一”、“一个”、“一种”和/或“该”等词并非特指单数，也可包括复数。需进一步理解的是，本申请中使用的术语“包括”和/或“包含”仅提示包括已明确标识的步骤和元素，而这些步骤和元素不构成一个排它性的罗列，还可以包括其它的步骤和元素。

虽然本申请对根据本申请的实施例的系统中的某些模块做出了各种引用，然而，任何数量的不同模块可以被使用并运行在客户端和/或服务器上。这些模块旨在说明，而不是为了限制本申请的范围。可以在系统和方法的不同方面使用不同的模块。

本申请中使用了流程图用来说明根据本申请的实施例的系统所执行的操作。应当理解的是，前面或下面的操作不一定按照顺序来精确地执行。相反，可以按照倒序或同时处理各种步骤。同时，也可以将其他操作添加到这些过程中，或从这些过程移除某一步或以上操作。

参考下面描述的附图描述本申请的实施例的技术方案。显然，所描述的实施例并非详尽无遗，并不是限制性的。在本申请的实施例中，本领域普通技术人员在没有任何创造性工作的情况下获取的其他实施例均在本申请的范围内。

本申请的一些实施例涉及可应用于例如按需服务的在线服务预测功能，其是仅在后互联网时代植根的新出现的服务或需求。它为客户提供技术解决方案，这些解决方案只能在后互联网时代兴起。在前互联网时代，无法预测用户请求的服务类型。因此，本解决方案深深植根于并且旨在解决仅在后互联网时代发生的问题。

图1示出了根据本申请的一些实施例的交通出行推荐系统的示例性网络环境。交通出行推荐系统100可以是用于提供出行相关服务的在线服务平台。交通出行推荐系统100可以包括服务器110、网络120、用户终端130、司机设备140和存储设备150。在一些实施例中，交通出行推荐系统100还可包括定位设备160(图1中未示出)。

交通出行推荐系统100可以适用于至少两种服务。示例***可包括出行计划服务、导航服务、按需服务(例如，出租车服务、司机服务、快车服务、拼车服务、公共约车服务或司机租用服务)等，或其组合。

服务器110可以处理来自交通出行推荐系统100的一个或以上组件或外部数据源(例如，云数据中心)的数据和/或信息。服务器110可以与用户终端130和/或司机设备140通信，以提供在线服务的各种功能。在一些实施例中，服务器110可以是单个服务器，也可以是服务器组。服务器组可以是经由接入点连接到网络120的集中式服务器组，或者经由一个或以上接入点分别连接到网络120的分布式服务器组。在一些实施例中，服务器110可以本地连接到网络120或者与网络120远程连接。例如，服务器110可以经由网络120访问存储在用户终端130、司机设备140和/或存储设备150中的信息和/或数据。又例如，存储设备150可以用作服务器110的后端数据存储。在一些实施例中，服务器110可以在云平台上实施。仅作为示例，该云平台可以包括私有云、公共云、混合云、社区云、分布云、内部云、多层云等或其任意组合。在一些实施例中，服务器110可以在具有本申请中的图2中所示的一个或以上组件的计算装置200中实现。

在一些实施例中，服务器110可包括处理设备112。处理设备112可以处理与本申请中描述的一个或以上功能相关的信息和/或数据。在一些实施例中，处理设备112可以执行交通出行推荐系统100的主要功能。例如，处理设备112可以处理信息以预测客户的服务类型，改善平台的用户体验以及节省请求服务的时间。在一些实施例中，处理设备112可以执行与本申请中描述的方法和系统有关的其他功能。

在一些实施例中，处理设备112可包括一个或以上处理单元(例如，单核处理设备或多核处理设备)。仅作为范例，处理设备112可包括一中央处理器(CPU)、特定应用集成电路(ASIC)、特定应用指令集处理器(ASIP)、图像处理器(GPU)、物理运算处理单元(PPU)、数字信号处理器(DSP)、现场可编程门阵列(FPGA)、可编程逻辑设备(PLD)、控制器、微控制器单元、精简指令集计算机(RISC)、微处理器等或其任意组合。

网络120可以促进信息和/或数据的交换。在一些实施例中，交通出行推荐系统100中的一个或以上组件(例如，服务器110、用户终端130、司机设备140、存储设备150)可以经由网络120将信息和/或数据发送到交通出行推荐系统100中的其他组件。在一些实施例中，网络120可为任意形式的有线或无线网络，或其任意组合。仅作为示例，网络120可以包括缆线网络、有线网络、光纤网络、远程通信网络、内部网络、互联网、局域网络(LAN)、广域网络(WAN)、无线局域网络(WLAN)、城域网(MAN)、公共交换电话网络(PSTN)、蓝牙网络、紫蜂网络、近场通信(NFC)网络等或其任意组合。在一些实施例中，网络120可以包括一个或以上网络接入点。例如，网络120可以包括有线或无线网络接入点，如基站和/或互联网交换点120-1、120-2……通过交通出行推荐系统100的一个或以上组件可以连接到网络120以交换数据和/或信息。

用户终端130和/或司机设备140可以经由网络120与服务器110通信。在一些实施例中，乘客或顾客可以是用户终端130的所有者。在一些实施例中，用户终端130的所有者可以是除乘客或顾客之外的其他人。例如，用户终端130的所有者A可以使用用户终端130来发送对乘客B的服务请求，和/或从服务器110接收服务确认和/或信息或指令。在一些实施例中，司机可以是司机设备140的用户。在一些实施例中，司机设备140的用户可以是除司机之外的其他人。例如，司机设备140的用户C可以使用司机设备140来接收对司机D的服务请求，和/或来自服务器110的信息或指令。在一些实施例中，可以指定司机使用司机设备140中的一个在至少一定的时间段。例如，当司机可用于提供按需服务时，可以指派他/她使用接收最早请求的司机终端和推荐执行按需服务类型的车辆。在一些实施例中，“乘客”、“顾客”、“用户”和“用户终端”可以互换使用。

顾客可以通过用户终端130接收出行的服务响应。在一些实施例中，用户终端130可以经由网络120从处理设备112获取出行的信息。用户终端130可以包括移动设备130-1、平板计算机130-2、膝上型计算机130-3、车辆内置设备130-4等，或其任何组合。在一些实施例中，移动设备130-1可以包括智能家居设备、可穿戴设备、智能移动设备、虚拟现实设备、增强现实设备等，或其任意组合。在一些实施例中，智能家居设备可以包括智能照明设备、智能电器控制设备、智能监控设备、智能电视、智能摄像机、对讲机等，或其任意组合。在一些实施例中，该可穿戴设备可包括智能手镯、智能鞋袜、智能眼镜、智能头盔、智能手表、智能衣服、智能背包、智能配件等或其任意组合。在一些实施例中，智能移动设备可以包括智能电话、个人数字助理(PDA)、游戏设备、导航设备、销售点(POS)等，或其任意组合。在一些实施例中，虚拟现实设备和/或增强现实设备可以包括虚拟现实头盔、虚拟现实眼镜、虚拟现实眼罩、增强现实头盔、增强现实眼镜、增强现实眼罩等，或其任意组合。例如，虚拟现实设备和/或增强现实设备可以包括Google Glass^TM、Oculus Rift^TM、Hololens^TM或Gear VR^TM等。在一些实施例中，车辆130-4中的内置设备可以包括内置计算机、车载内置电视、内置平板电脑等。在一些实施例中，用户终端130可以包括信号发送器和信号接收器，用于与定位设备170通信，用于定位乘客和/或用户终端130的位置，并确定从他/她的位置到道路的相对距离。

司机可以通过司机设备140接收服务请求。司机设备140可包括至少两个司机设备140-1、140-2……140-n。在一些实施例中，司机设备140可以与用户终端130类似或相同。在一些实施例中，可以定制司机设备140以基于从处理设备112获取的出行相关信息来实现在线服务。

存储设备150可以存储数据和/或指令。数据可以包括地理位置信息、时间信息、司机信息、客户信息、外部环境等。仅仅出于说明的目的，与地理位置信息相关的数据可以包括服务位置(即，出发位置)、到达位置、出发位置和到达位置之间的距离等。与时间信息有关的数据可以包括服务时间(即出发时间)、订单接受时间、订单完成时间等。与司机信息相关的数据可以包括司机身份证(ID)、司机的用户简档、司机账户等。在一些实施例中，存储设备150可以存储从用户终端130和/或司机设备140获取的数据。例如，存储设备150可以存储与用户终端130相关联的日志。

在一些实施例中，存储设备150可以存储处理设备112可以执行的数据和/或指令，以预测本申请中描述的客户的服务类型。在一些实施例中，存储设备150可包括大容量存储器、可移动存储器、易失性读写内存、只读内存(ROM)等或其任意组合。示例性的大容量存储器可以包括磁盘、光盘、固态磁盘等。示例性可移动存储器可以包括闪存驱动器、软盘、光盘、内存卡、压缩盘、磁带等。示例性易失性读写内存可以包括随机存取内存(RAM)。示例性RAM可包括动态随机存取内存(DRAM)、双倍数据速率同步动态随机存取内存(DDR SDRAM)、静态随机存取内存(SRAM)、晶闸管随机存取内存(T-RAM)和零电容随机存取内存(Z-RAM)等。示例性只读内存可以包括掩模型只读内存(MROM)、可编程只读内存(PROM)、可擦除可编程只读内存(EPROM)、电可擦除可编程只读内存(EEPROM)、光盘只读内存(CD-ROM)和数字多功能磁盘只读内存等。在一些实施例中，所述存储设备150可以在云平台上实现。仅作为示例，该云平台可以包括私有云、公共云、混合云、社区云、分布云、内部云、多层云等或其任意组合。

在一些实施例中，交通出行推荐系统100中的一个或以上组件可以经由网络120访问存储设备150中存储的数据或指令。在一些实施例中，存储设备150可以作为后端存储器直接连接到服务器110。

定位设备160可以确定与对象(例如，一个或以上的用户终端130、司机设备140等)相关联的信息。例如，定位设备160可以确定用户终端130的物理位置(地理位置)。在一些实施例中，定位设备160可以是全球定位系统(GPS)、全球导航卫星系统(GLONASS)、罗盘导航系统(COMPASS)、北斗导航卫星系统、伽利略定位系统、准天顶卫星系统(QZSS)等。由定位设备160提供的信息可以包括对象的位置、高度、速度或加速度，和/或当前时间。位置可以是坐标的形式，例如纬度坐标和经度坐标等。定位设备160可以包括一个或以上卫星或与之关联。卫星可以独立地或联合地确定上述信息。定位设备160可以经由网络120将上述信息发送到用户终端130或者司机设备140。

本领域普通技术人员将理解，当交通出行推荐系统100的元件执行时，该元件可以通过电信号和/或电磁信号执行。例如，当用户终端130处理任务时，例如排列从一个地方到另一个地方的行程的顺序，用户终端130可以在其处理器中操作逻辑电路以处理这样的任务。当用户终端130向服务器110发出指令时，用户终端130的处理器可以生成编码该指令的电信号。然后，用户终端130的处理器可以将电信号发送到输出端口。若用户终端130经由有线网络与服务器110通信，则输出端口可物理连接至电缆，其进一步将电信号传输给服务器110的输入端口。如果用户终端130经由无线网络与服务器110通信，则用户终端130的输出端口可以是一个或以上天线，其将电信号转换为电磁信号。类似地，司机设备140可以通过其处理器中的逻辑电路的操作来处理任务，并且经由电信号或电磁信号从服务器110接收指令和/或信息。在电子设备内，例如用户终端130、司机设备140和/或服务器110，当处理器处理指令，发出指令和/或执行动作时，指令和/或动作通过电信号进行。例如，当处理器从存储介质(例如，存储设备150)检索数据时，它可以将电信号发送到存储介质的读取设备，该读取设备可以读取存储介质中的结构化数据。该结构化数据可以电信号的形式经由电子设备的总线传输至处理器。此处，电信号可以指一个电信号、一系列电信号和/或至少两个离散的电信号。

图2是根据本申请的一些实施例所示的计算装置的示例性组件的示意图。根据本申请的一些实施例，服务器110、用户终端130和/或司机设备140、存储设备150可以在计算装置200上实现。本实施例中的特定系统利用功能框图解释了一个包含用户界面的硬件平台。这种计算机可以是一个通用功能的计算机，也可以是一个有特定功能的计算机。根据本申请的一些实施例，两种类型的计算机可以被配置为实现任何特定系统。计算装置200可以被配置为实现执行本申请中披露的一个或以上功能的任何组件。例如，计算装置200可以实现如本文所述的交通出行推荐系统100的任何组件。在图1至2中，出于方便的目的仅示出了一个这样的计算机设备。本领域的普通技术人员将在提交本申请时理解，可以在多个类似平台上以分布式方式实现与这里描述的服务有关的计算机功能，以分配处理负荷。

例如，计算装置200可以包括与网络相连接通信端口250，以实现数据通信。计算装置200还可以包括处理器(例如，处理器220)，其形式为一个或以上处理器(例如，逻辑电路)，用于执行程序指令。例如，处理器可以包括其中的接口电路和处理电路。接口电路可以被配置为从总线210接收电信号，其***号编码用于处理电路的结构化数据和/或指令。处理电路可以进行逻辑计算，然后将结论、结果和/或指令编码确定为电信号。然后，接口电路可以经由总线210从处理电路发出电信号。

示例性计算装置可以包括内部通信总线210、程序存储和不同形式的数据存储，包括：例如，磁盘270，以及只读内存(ROM)230，或随机存取内存(RAM)240，用于由计算装置处理和/或发送的各种数据文件。示例性计算装置还可以包括存储在ROM 230，RAM 240和/或由处理器220执行的其他类型的非暂时性存储介质中的程序指令。本申请的方法和/或流程可以以程序指令的方式实现。计算装置200还包括I/O组件260，支持计算机和其他组件之间的输入/输出。计算装置200还可以经由网络通信接收编程和数据。

仅用于说明，图2中仅示出了一个处理器和/或处理器。也可以考虑多个CPU和/或处理器；因此，由本申请中描述的由一个CPU和/或处理器执行的操作和/或方法步骤也可以由多个CPU和/或处理器联合或单独执行。例如，如果在本申请中，计算装置200的CPU和/或处理器执行操作A和操作B，则应当理解，操作A和操作B也可以由计算装置200中的两个不同的CPU和/或处理器联合或分开执行(例如，第一处理器执行操作A，第二处理器执行操作B，或者第一和第二处理器共同执行操作A和B)。

图3是根据本申请的一些实施例所示的示例性请求者终端的示例性硬件和/或软件组件的框图。根据本申请的一些实施例，信息提供器130或通信平台140可以在移动设备300上实现。如图3所示，移动设备300可以包括通信模块310、显示器320、图形处理单元(GPU)330、中央处理单元(CPU)340、I/O 350、内存360和存储器390。CPU 340可以包括接口电路和类似于处理器220的处理电路。在一些实施例中，任何其他合适的组件，包括但不限于系统总线或控制器(未示出)，也可包括在移动设备300内。在一些实施例中，移动操作系统370(例如，iOS^TM、Android^TM、Windows Phone^TM等)和一个或以上应用程序380可以从存储器390加载到内存360中，以便由CPU 340执行。应用程序380可以包括浏览器或任何其他合适的移动应用程序，用于从移动设备300上的交通出行推荐系统接收和呈现与服务请求或其他信息有关的信息。用户与信息流的交互可以经由I/O设备350实现，并且经由网络150提供给处理设备112和/或交通出行推荐系统100的其他组件。

为了实现上述各种模块、单元及其功能，计算机硬件平台可以用作一个或以上元件(例如，图1中描述的服务器110的组件)的硬件平台。由于这些硬件元素，操作系统和程序语言很常见，可以假设本领域技术人员可以熟悉这些技术，并且他们可以根据本申请中描述的技术提供数据分类中所需的信息。具有用户界面的计算机可以用作个人计算机(PC)，或其他类型的工作站或终端设备。在正确编程之后，具有用户界面的计算机可以用作服务器。可以认为本领域普通技术人员也可以熟悉这种类型的计算机设备的这种结构、程序或一般操作。因此，没有针对附图描述另外的解释。

为了阐明所披露的实施例的目的，技术方案和优点，下面将结合本申请中的附图清楚，完整地描述本申请中的技术方案。

随着互联网技术的发展，在线汽车智能终端的使用越来越受欢迎。随着约车服务的不断发展，用户可以在服务平台上选择各种类型的约车服务，例如：出租车、快车、专车、拼车、汽车租赁等。

在现有技术中，由于每种服务类型的计费机制和呼叫机制的不同，不同类型的服务具有不同的排序界面。为了使用户能够更快地下订单或支付账单，服务平台预测用户的可能服务类型，并在用户登录服务平台或触发服务平台的订购界面时切换到与预测服务类型对应的订购界面。

然而，用户当前服务类型的现有预测是基于用户在先前订单中请求的服务类型确定的。以用户的先前订单与“快车”服务相关为例，当用户启动服务平台时，服务平台将自动显示“快车”界面，这与用户的实际需求不一致。也就是说，如果用户所需的服务类型不是“快车”，则用户需要切换到另一个订购界面，从而降低了请求服务的效率。因此，如何提高服务类型预测的准确性，使得预测的服务类型与用户实际需要的服务类型一致，从而提高效率已成为待解决的技术问题。

图4是根据本申请的一些实施例所示的用于预测服务类型的过程400的流程图。在一些实施例中，图4中所示的过程400可以在图1中所示的交通出行推荐系统100中实现。例如，过程400的至少一部分可以作为指令的形式存储在存储设备(例如，计算装置200的磁盘270)中，并且由服务器110(例如，计算装置200的处理器220)调用和/或执行。在一些实施例中，过程400的一部分可以在终端设备上实现。以下呈现的所示过程400的操作旨在是说明性的。在一些实施例中，过程400可以利用未描述的一个或以上附加操作，和/或没有所讨论的一个或以上操作来完成。另外，如图4所示和下面描述的过程400的操作的顺序不是限制性的。

在401中，可以获取用户的先前服务请求的订单信息。订单信息可以包括一种请求服务的类型以及服务时间或服务位置中的至少一个。在一些实施例中，订单信息可以由处理设备112获取。

在402中，可以基于先前服务请求的订单信息生成服务类型预测模型，当从用户接收到包括当前请求服务时间或当前请求服务位置中的至少一个的服务请求时，可以使用服务类型预测模型来预测首选服务类型。在一些实施例中，服务类型预测模型可以由处理设备112生成。

本申请中描述的服务类型预测方法的应当注意执行主体(例如，过程400)可以具体地是服务类型预测设备，并且服务类型预测设备可以由硬件和/或软件实现。通常，服务类型预测设备可以集成到其中实现服务平台的云服务器中，并且与其中存储各种数据库并且实现服务平台的数据服务器一起使用。另外，其中实现预测设备的服务器可以与数据服务器相同，或者与数据服务器相同的服务器集群的另一服务器，本申请不限于此。

先前服务请求是指用户在历史时间段(例如，昨天、上周、上个月、最近三个月等)中发出的服务请求。在一些实施例中，用户的先前服务请求可以涉及用户通过服务平台请求的约车服务请求。约车服务可以是实时服务或预订服务。约车服务可包括但不限于出租车服务、快车服务、司机服务、乘车共享服务、汽车租赁服务、拼车服务等。

在一些实施例中，每个先前服务请求的订单信息可以包括请求服务的类型、服务时间和/或服务位置。在一些实施例中，订单信息还可以包括订单号、价格等。在一些实施例中，服务时间可以包括特定时间点或包括特定时间点的目标统计时间段。仅作为示例，服务时间具体可以是请求服务的开始时间、请求服务的结束时间、请求服务的等待时间等，或者它们的组合。在一些实施例中，服务位置可以包括特定位置或包括特定位置的统计地理区域。仅作为示例，服务位置可以包括请求服务的出发位置、请求服务的到达位置等，或其组合。

由于先前服务请求的订单信息包括各种类型的信息，因此对信息的分析可以指示用户对服务类型的偏好/行为(即，用户在某些特定场景中选择服务类型的概率)。

例如，用户在工作日(即周一至周五)的大多数先前服务请求是出租车服务，并且周六和周日的大多数先前服务请求是快车服务。通过根据服务时间分析用户的偏好/行为，可以得出结论，用户在工作日选择出租车服务的概率相对较高，并且用户在假期选择快车服务的概率也相对较高。又例如，服务位置在办公楼或靠近办公楼的大多数先前服务请求都是出租车服务，大多数先前服务请求的服务位置在社区或附近是快车服务。

通过根据服务位置分析用户的偏好/行为，办公楼可以是用户的工作场所。当用户离开他/她的工作位置到达目的地时，用户选择出租车服务的概率相对较高。社区可能是用户的家。当用户离开他/她的家到达目的地时，用户选择快车服务的概率相对较高。可以考虑服务时间和/或服务位置来全面地分析用户的行为规则或偏好，以获取用户在特定场景中选择服务类型的概率。

因此，数学模型可以表示用户的行为/偏好模式。在一些实施例中，可以构造服务类型预测模型以预测用户的实时服务请求的服务类型。服务类型预测模型可以包括但不限于马尔可夫模型、高斯模型、混合高斯模型、贝叶斯模型等。服务类型预测模型可以用于根据当前请求服务时间和/或用户的当前请求服务位置来识别与当前场景类似的历史场景，并将历史场景下的服务类型指定为用户的首选服务类型。如这里所使用的，当前请求服务时间是指当前订单的服务时间，而当前请求服务位置是指当前订单的服务位置。

本申请的流程400中提供的预测服务类型的方法根据用户先前服务请求的订单信息中的服务时间和/或服务位置，为用户建立服务类型预测模型。服务类型预测模型可用于在当前请求服务时间和/或当前请求服务位置预测实时服务请求的首选服务类型。由于使用服务类型预测模型和订单信息来预测服务类型，因此与现有技术中的方法相比，有效地提高了预测的准确性。进一步地，服务平台可以根据预测的服务类型显示订购界面，满足用户的实际需求，从而减少用户的时间，提高用户请求服务的效率。

应该注意的是，上述仅出于说明性目的而提供，并不旨在限制本申请的范围。对于本领域的普通技术人员来说，可以根据本申请的描述，做出各种每个样的变化和修改。例如，处理设备112还可以将首选服务类型发送到用户的终端设备的用户界面以供显示。然而，这些变化和修改不会背离本申请的范围。

图5是根据本申请的一些实施例所示的用于预测服务类型的过程500的流程图。在一些实施例中，可以结合过程400来描述过程500中描述的操作。

在501中，可以获取用户的先前服务请求的订单信息。订单信息可以包括一种请求服务的类型以及服务时间或服务位置中的至少一个。

在502中，可以基于服务时间和/或服务位置，对至少两个先前服务请求中的每种类型的服务执行聚类分析，以生成对应于每种服务类型的混合高斯模型。在一些实施例中，聚类分析可以由处理设备112执行。

在503中，处理设备112可以根据混合高斯模型，确定关于当前请求服务时间和/或当前请求服务位置的每种服务类型的概率密度值。关于每种服务类型的概率密度值的详细描述可以在别处披露，例如，图6A和6B。

在504中，可以基于概率密度值，预测用户的首选服务类型。

过程500中提供的实施例可以类似于过程400中的实施例。在一些实施例中，用户的先前服务请求可以涉及用户在历史时间段内通过服务平台请求的约车服务。约车服务可以是实时服务或预订服务。约车服务可能包括但不限于出租车服务、快车服务、司机服务、乘车共享服务、汽车租赁服务、拼车服务等。在一些实施例中，每个先前服务请求的订单信息可以包括请求服务的类型、服务时间和/或服务位置。在一些实施例中，订单信息还可以包括订单号、价格等。服务时间具体可以是请求服务的开始时间、请求服务的结束时间、请求服务的等待时间等，或者它们的组合。服务位置可以包括请求服务的出发位置、请求服务的到达位置等，或其组合。

过程500中描述的实施例还提供了用于预测服务类型的特定实现。在过程500中，可以根据服务时间和/或服务位置对至少两个先前服务请求中的每种类型的服务进行聚类，以生成对应于每种服务类型的混合高斯模型。仅用于说明目的，以服务时间的聚类为例。

应该注意的是，上述仅出于说明性目的而提供，并不旨在限制本申请的范围。对于本领域的普通技术人员来说，可以根据本申请的描述，做出各种每个样的变化和修改。例如，处理设备112还可以将首选服务类型发送到用户的终端设备的用户界面以供显示。然而，这些变化和修改不会背离本申请的范围。

图6A和6B分别是根据本申请的一些实施例的出租车服务和快车服务的频率的示意图。表1是用户的先前服务请求的订单信息。将结合表1描述图6A和6B。可以处理表1中的订单信息以提取先前服务请求的时间点。提取的时间点可以属于一个或以上时间段。然后，可以获取对应于每个时间段的服务类型，并以直方图的形式表示，如图6A和6B所示。从直方图可以得出结论，出租车服务的高峰时间是12点左右，快车服务的高峰时间是7点左右和18点左右。因此，考虑到服务时间，出租车服务的服务时间的聚类中心是12点，快车服务的服务时间的聚类中心是7点和18点。

在一些实施例中，聚类中心可用于确定高斯分布。高斯分布可以以聚类中心为中心。例如，用于出租车服务的高斯模型可以具有12点的中心。又一例，一种用于快速服务的混合高斯模型，由两个叠加的高斯分布组成，具有7点钟的第一中心和18点钟的第二中心。

表1

可以以各种方式实现基于服务时间建立混合高斯模型的方法。在一些实施例中，可以通过对时间点进行矢量化并计算对应于每个时间点的平均值和平方偏差，获取每种服务类型的基于服务时间的混合高斯模型。

在上述实施例中，考虑服务时间来描述预测模型。在一些实施例中，可以根据服务位置或服务时间和服务位置的组合，建立混合高斯模型。过程500中描述的方法基于服务时间的时间点，建立混合高斯模型。在一些实施例中，可以根据与服务时间相关的其他信息建立混合高斯模型，例如服务时间的日期、服务时间是否在假日等，服务位置也是如此。

关于当前请求服务时间的每种服务类型的概率密度值可以通过将当前请求服务时间合并到混合高斯模型中来确定，并且概率密度值可以用于预测用户的首选服务类型。

通过建立混合高斯模型来预测用户实时请求的服务类型，有效地提高了预测精度，使得服务平台可以使用预测的服务类型向用户显示对应的用户界面，从而提高了用户请求服务的效率。

在一些实施例中，根据过程500的504中每种服务类型的概率密度值来预测服务类型，其可以进一步包括使用贝叶斯模型确定每种服务类型的第一概率和每种服务类型的概率密度值，并且将对应于最大概率值的服务类型指定为用户的首选服务类型(即，预测的服务类型)。

贝叶斯模型可以用于表示在各种动态条件下服务类型的概率，其可以被理解为选择服务类型的概率的数学表达式。因此，每种服务类型的第一概率可以通过处理每种服务类型的概率密度值来获取。第一概率可以指示在当前请求服务时间和/或当前请求服务位置处选择服务类型的可能性。因此，指定具有最大第一概率值的服务类型可能更准确，因为预测的服务类型将进一步提高服务类型预测的准确性。

在一些实施例中，为了使预测更接近用户的实际请求，可以将具有最大第一概率值的服务类型指定为预测服务类型。在该过程期间，可以确定最大的第一概率是否大于或等于第一预设阈值。如果最大第一概率大于或等于第一预设阈值，则可以将服务类型指定为预测服务类型并输出到例如用户终端130。

由于一个用户的订单信息与其他用户的订单信息不同，因此服务类型预测模型可能不适用于其他用户，特别是对于订单数量较少的用户。因此，通过设置第一预设阈值，可以验证具有最大第一概率值的服务类型，并且可以仅在服务类型的概率值大于或等于第一预设阈值时确定用户的首选服务类型。

如果服务类型的概率值不大于或等于第一预设阈值，则可以使用其他服务类型预测模型或现有方法来预测服务类型。在一些实施例中，对于具有少量订单的用户，一旦用户的订单信息足以建立预测模型的服务类型，交通出行推荐系统100可以根据上述服务类型预测方法来预测用户的服务类型。

本申请提供了一种服务类型预测方法，用于通过分解先前服务请求的订单信息与用户请求的服务类型混合高斯模型进行预测，预测过程是有效的，并且提高了预测的准确性。

图7是根据本申请的一些实施例所示的用于预测服务类型的过程700的流程图。在一些实施例中，可以结合过程500描述过程700。

在701中，可以获取用户的先前服务请求的订单信息。订单信息可以包括一种请求服务的类型以及服务时间或服务位置中的至少一个。在一些实施例中，订单信息可以由处理设备112获取。

在702中，处理设备112可以从先前服务请求的订单信息获取每种服务类型的频率，以生成马尔可夫模型。

在703中，处理设备112可以将上一次顺序的订单信息输入到马尔可夫模型中，确定每种服务类型的第二概率。之前的订单也可能被称为最新的历史订单。

在704中，可以确定具有最大第二概率值的服务类型，并且可以确定最大第二概率值是否大于或等于第二预设阈值。

如果最大第二概率值大于或等于第二预设阈值，则该过程可以进行到705。如果最大第二概率值不大于或等于第二预设阈值，则该过程可以进行到706。

在705中，可以将与最大第二概率对应的服务类型指定为用户的首选服务类型。用户的首选服务类型可以输出到例如用户终端130。

在706中，处理设备112可以基于服务时间和/或服务位置，在订单信息中的每种服务类型上执行聚类分析，以获取用于每种服务类型的混合高斯模型。

在707中，处理设备112可以根据对应的混合高斯模型，确定当前请求服务时间和/或当前请求服务位置处的每种服务类型的概率密度值。

在708中，可以根据每种服务类型的概率密度值，预测用户请求的服务类型。

为了提高服务类型预测的效率，处理设备112可以组合马尔可夫模型和混合高斯模型以提高整个预测过程的预测效率。

在一些实施例中，可以在获取用户的先前服务请求之后使用马尔可夫模型来预测用户请求的服务类型。

表2示出了用户的先前服务请求的订单信息。表3示出了表2的先前服务请求的订单信息的统计数据。

表2

表3

在一些实施例中，可以从订单信息获取用户的上一次服务请求的服务类型，并且可以基于表3中的前一服务的服务类型和统计数据来确定跳跃矩阵。

可以获取每种服务类型的第二概率。用户请求快车服务的概率为0，用户请求出租车服务的概率为1。然后，一旦服务类型的概率值大于或等于第二预设阈值，则可以将与最大第二概率对应的服务类型指定为预测服务类型。否则，可以使用如上所述的混合高斯模型来进行服务类型预测。

在一些实施例中，马尔可夫模型对于总是请求单一服务类型的用户可能更有效。与混合高斯模型相比，马尔可夫模型的计算负荷可以更小，这有利于提高被配置的服务预测设备的处理效率，以预测用户的服务类型。在实施例中，第一/第二预设阈值是根据实际请求设定的，使得当马尔可夫模型不适合处理用户的订单信息时，可以根据混合高斯模型有效地预测用户的服务类型。

图8是根据本申请的一些实施例所示的服务类型预测设备的示意图。服务类型预测设备800可以包括信息检索模块801和服务预测模块802。

信息检索模块801可以被配置为获取用户发出的至少两个先前服务请求，其中，每个至少两个先前服务请求包括订单信息，包括所请求的服务类型以及服务时间或服务位置中的至少一个。

服务预测模块802可以被配置为基于至少两个先前服务请求的订单信息生成服务类型预测模型，并且当从用户接收到包括当前服务时间或当前服务位置中的至少一个的服务请求时，使用服务类型预测模型来预测用户的首选服务类型。

本申请中描述的服务类型预测方法的应当注意执行主体(例如，过程400)可以具体地是服务类型预测设备，并且服务类型预测设备可以由硬件和/或软件实现。通常，服务类型预测设备可以集成到其中实现服务平台的云服务器中，并且与其中存储各种数据库并且实现服务平台的数据服务器一起使用。另外，其中实现预测设备的服务器可以与数据服务器相同，或者与数据服务器相同的服务器集群的另一服务器，本申请不限于此。

先前服务请求是指用户在历史时间段(例如，昨天、上周、上个月、最近三个月等)中发出的服务请求。在一些实施例中，用户的先前服务请求可以涉及用户通过服务平台请求的约车服务请求。约车服务可以是实时服务或预订服务。约车服务可包括但不限于出租车服务、快车服务、司机服务、乘车共享服务、汽车租赁服务、拼车服务等。

在一些实施例中，每个先前服务请求的订单信息可以包括请求服务的类型、服务时间和/或服务位置。在一些实施例中，订单信息还可以包括订单号、价格等。在一些实施例中，服务时间可以包括特定时间点或包括特定时间点的目标统计时间段。仅作为示例，服务时间具体可以是请求服务的开始时间、请求服务的结束时间、请求服务的等待时间等，或者它们的组合。在一些实施例中，服务位置可以包括特定位置或包括特定位置的统计地理区域。仅作为示例，服务位置可以包括请求服务的出发位置、请求服务的到达位置等，或其组合。

由于先前服务请求的订单信息包括各种类型的信息，因此对信息的分析可以指示用户对服务类型的偏好/行为(即，用户在某些特定场景中选择服务类型的概率)。

例如，用户在工作日(即周一至周五)的大多数先前服务请求是出租车服务，并且周六和周日的大多数先前服务请求是快车服务。通过根据服务时间分析用户的偏好/行为，可以得出结论，用户在工作日选择出租车服务的概率相对较高，并且用户在假期选择快车服务的概率也相对较高。又例如，服务位置在办公楼或靠近办公楼的大多数先前服务请求都是出租车服务，大多数先前服务请求的服务位置在社区或附近是快车服务。通过根据服务位置分析用户的偏好/行为，办公楼可以是用户的工作场所。当用户离开他/她的工作位置到达目的地时，用户选择出租车服务的概率相对较高。社区可以是用户的家。当用户离开他/她的家到达目的地时，用户选择快车服务的概率相对较高。可以考虑服务时间和/或服务位置来全面地分析用户的行为规则或偏好，以获取用户在特定场景中选择服务类型的概率。

因此，数学模型可以表示用户的行为/偏好模式。在一些实施例中，可以构造服务类型预测模型以预测用户的实时服务请求的服务类型。服务类型预测模型可以包括但不限于马尔可夫模型、高斯模型、混合高斯模型、贝叶斯模型等。服务类型预测模型可以用于根据当前请求服务时间和/或用户的当前请求服务位置来识别与当前场景类似的历史场景，并将历史场景下的服务类型指定为用户的首选服务类型。

在一些实施例中，服务预测模块802可以被配置为执行聚类分析，在服务时间和/或服务位置的基础上，在每个类型的服务中生成对应于每种服务类型的混合高斯模型。服务预测模块802可以根据混合高斯模型，确定关于当前请求服务时间和/或当前请求服务位置的每种服务类型的概率密度值。可以基于概率密度值，预测用户的首选服务类型。在一些实施例中，服务预测模块802可以使用贝叶斯模型和每种服务类型的概率密度值来确定每种服务类型的第一概率，并指定对应于最大概率值的服务类型作为用户的首选服务类型(即预测服务类型)。在一些实施例中，可以确定最大的第一概率是否大于或等于第一预设阈值。如果最大第一概率大于或等于第一预设阈值，则可以将服务类型指定为预测服务类型并输出到例如用户终端130。

在一些实施例中，服务预测模块802可以从先前服务请求的订单信息获取每种服务类型的频率，以生成马尔可夫模型，并将先前订单的订单信息输入马尔可夫模型以确定每种服务类型的第二概率。服务预测模块802可以确定具有最大第二概率值的服务类型。可以确定最大第二概率值是否大于或等于第二预设阈值。如果最大第二概率值大于或等于第二预设阈值，则可以将与最大第二概率对应的服务类型指定为用户的首选服务类型。否则，服务预测模块802可以基于服务时间和/或服务位置，在订单信息中的每种服务类型上执行聚类分析，以获取用于每种服务类型的混合高斯模型，并根据对应的混合高斯模型，在当前请求服务时间和/或当前请求服务位置确定每种服务类型的概率密度值。可以根据每种服务类型的概率密度值，预测用户请求的服务类型。

图9是根据本申请的一些实施例所示的用于确定交通出行服务的订单成功率的过程900的流程图。在一些实施例中，图9中所示的过程900可以在图1中所示的交通出行推荐系统100中实现。例如，过程900的至少一部分可以作为指令的形式存储在存储设备(例如，计算装置200的磁盘270)中，并且由服务器110(例如，计算装置200的处理器220)调用和/或执行。在一些实施例中，过程900的一部分可以在终端设备上实现。以下呈现的所示过程900的操作旨在是说明性的。在一些实施例中，过程900可以利用未描述的一个或以上附加操作，和/或没有所讨论的一个或以上操作来完成。另外，如图9所示和下面描述的过程900的操作的顺序不是限制性的。在一些实施例中，订单成功率可以由订单成功率预估设备实现。订单成功率预估设备可以是独立设备，例如与用户客户端交互的应用服务器客户端。订单成功率预估设备还可以集成在用户的客户端在其上实现的设备中，例如，智能电话、平板电脑(便携式安卓设备)或其他电子移动设备。这些电子设备可以被称为“用户终端”。订单成功率预估设备采用应用服务器的形式。

在901中，在用户感测到交通出行用户界面的开启时，处理设备112可以在界面上向用户提供至少两种交通出行服务。当用户计划出行时，可为用户选择至少两种交通出行服务。

打开应用程序的用户操作可以由处理设备112感测为交通出行用户界面的开启(也称为“开启信息”)，其将被发送到应用服务器。打开的应用程序提供各种交通出行服务供用户选择。

交通出行服务可能包括任何类型的交通出行，例如，出租车、私家车(快车、专车、乘车共享车、带指定司机的车)、自行车等，或带固定站的公共交通工具，如公共汽车、火车、地铁等。用户可以在终端(例如，用户终端130)中安装呈现交通出行服务的应用程序(也称为“APP”)。当用户想要在出发前预订出租车时，用户可以点击终端以打开安装在终端上的应用程序。

在902中，可以获取用户的物理位置。

在一些实施例中，用户的物理位置可以是用户的当前地理位置。可以使用定位技术获取用户的当前地理位置。在一些实施例中，在获取用户的当前地理位置之前，处理设备112可以向用户的终端(例如，用户终端130)发送消息以确认是否激活终端的定位功能。如果用户同意激活定位功能，则服务器110可以通过用户的终端获取用户的当前地理位置。例如，用户的当前地理位置由终端的GPS定位设备获取。又例如，可以基于为终端提供网络信号的供应基站的位置来计算用户的当前地理位置。

在一些实施例中，处理设备112可以获取用户的请求位置而不是当前位置。例如，如果用户保留从某个位置开始的交通出行服务，则可以获取预留位置(即，请求的位置)。

在903中，处理设备112可以在物理位置处基于预先建立的评估标准，预估用于至少两种交通出行服务中的每种的订单成功率。

预先建立的评估标准是指一个或以上因素或基于其可以确定用于至少两种交通出行服务中的每种的订单成功率的视图的术语。在一些实施例中，预先建立的评估标准可包括但不限于，用户肖像(例如，用户的年龄、性别、用户帐户是否有头像、职业等)、天气状况、交通状况、城市、司机与乘客的比例、工作日或周末、物理位置是郊区或市区。在一些实施例中，根据交通出行推荐系统100的默认设置，可以由用户设置预先建立的评估标准。

处理设备112可以根据预先建立的评估标准的一个或以上，在用户的当前地理位置处，确定具有更高订单成功率的交通出行服务。

仅仅为了说明的目的，订单成功是指在用户请求出租车服务之后是否有出租车司机接受用户在预设时间段(例如，1分钟内)内下达的订单，使得用户和司机可以达成出行协议。又例如，如果用户选择骑自行车，则在用户的物理位置(例如，在50米内)的预设范围内是否有可用的自行车，使得用户可以预约自行车。

订单成功率是指服务请求者和服务提供者相匹配的可能性。仅举例来说，如果一个区域有100辆出租车，并且该区域有500名用户选择出租车服务，此时出租车服务的订单成功率可能是20％。在一些实施例中，预先建立的评估标准可能由于订单成功率评估中使用的不同算法而变化，并且订单成功率可以相应地变化。上述应当注意实施例并非旨在限制本申请的范围。本领域普通技术人员可以根据交通出行服务的属性或性质以及出行环境的应用场景来调整预先建立的评估标准。上述订单成功率预估方法可以用于从客户端应用程序获取用户的开启信息，并且客户端应用程序可为用户提供至少两种类型的交通出行服务。可以获取用户的当前地理位置。可以根据预先建立的评估标准，确定当前地理位置处的每种交通出行服务的订单成功率。本申请使得能够基于用户的当前地理位置识别具有更高订单成功率的交通出行服务，这有助于准确可靠地分析当前服务位置处的用户的订单成功率，从而为用户提供可靠的交通出行服务推荐并提高用户的出行效率。同时，有助于使交通出行服务提供者(例如司机)和交通出行服务请求者(例如乘客)之间的供需比尽可能平衡，这样可以最大限度地提高服务提供者和服务请求者的利益，提高资源利用率，并实现用户行为的便利性。

应该注意的是，上述仅出于说明性目的而提供，并不旨在限制本申请的范围。对于本领域的普通技术人员来说，可以根据本申请的描述，做出各种每个样的变化和修改。例如，处理设备112可以进一步基于每种交通出行服务的订单成功率向用户推荐合适的交通出行服务。然而，这些变化和修改不会背离本申请的范围。

图10是根据本申请的一些实施例所示的用于预估交通出行服务的订单成功率的过程1000的流程图。将结合过程900描述过程1000。过程1000中所示的订单成功率预估方法可以由服务器实现，例如，在线约车服务器、指定的驾驶服务器等。在一些实施例中，图10中所示的过程1000可以在图1中所示的交通出行推荐系统100中实现。例如，过程1000的至少一部分可以作为指令的形式存储在存储设备(例如，计算装置200的磁盘270)中，并且由服务器110(例如，计算装置200的处理器220)调用和/或执行。在一些实施例中，过程1000的一部分可以在终端设备上实现。以下呈现的所示过程1000的操作旨在是说明性的。在一些实施例中，过程1000可以利用未描述的一个或以上附加操作，和/或没有所讨论的一个或以上操作来完成。另外，如图10所示和下面描述的过程1000的操作的顺序不是限制性的。

在1001中，在用户感测到交通出行用户界面的开启时，处理设备112可以在界面上向用户提供至少两种交通出行服务。当用户计划出行时，可为用户选择至少两种交通出行服务。

在1002中，可以获取用户的物理位置。在一些实施例中，物理位置可以是用户的当前地理位置。

可以获取用于预估一个或以上可用交通出行服务中的每种的订单成功率的预先建立的评估标准。在一些实施例中，预先建立的评估标准可以包括但不限于用户肖像(例如，用户的年龄、性别、用户帐户是否具有头像、职业等)、天气状况、交通状况、城市、司机与乘客的比例、工作日或周末、物理位置是郊区或市区。在一些实施例中，预先建立的评估标准包括统计时间段和统计地理区域。

在1003a中，处理设备112可以确定交通出行用户界面的开启时间属于目标统计时间段。

统计时间段可以指具有一定长度的时间间隔。在一些实施例中，可以定义每小时是统计时间段，例如，从0点到1点的统计时间段、从8点到9点的统计时间段等。在一些实施例中，处理设备112可以在每个统计时间段中获取供需比，例如，通过使用算法(例如，聚类算法)处理至少两个先前订单(即，历史订单)。处理设备112可以基于处理的先前订单，确定统计时间段。

仅举例来说，统计时间段可以具有不同的长度。例如，在早/晚高峰时段，统计时间段可以设置为5：00～5：15、5：15～5：30、5：30～5：45……长度为15分钟。在凌晨时间，统计时间段可以设置为1：00～2：00、2：00～3：00……长度为1小时。应当注意统计时间段仅用于说明目的，并非旨在限制本申请的范围。在早晨高峰时间期间，大多数用户打算去工作、会议等，并且可以集中统计时间段，例如，可以将每2分钟设置为统计时间段。

当用户点击终端设备以激活客户端程序时，用户激活客户端的操作形成开启信息。可以将开启信息发送到应用服务器。应用服务器可以确定交通出行用户界面的开启时间落在下面的统计时间段，并且可以将所确定的统计时间段指定为目标统计时间段。例如，如果统计时间段预设为7：55～8：00、8：00～8：05、8：05～8：10……则当用户在8:02打开客户端应用程序时，可以将统计时间段8：00～8：05确定为目标统计时间段。通常，用户打开客户端应用程序的时间点与应用程序服务器接收到开启信息的时间点之间的时间差可以是毫秒或秒，这可以忽略。

在1003b中，处理设备112可以确定用户的物理位置属于目标统计地理区域。

统计地理区域是指包括用户的物理位置(例如，当前地理位置)的最小地理区域。统计地理区域的定义可以类似于上述统计时间段。

在一些实施例中，不同统计地理区域的供需比可由本领域技术人员根据诸如基于至少两个先前用户订单的聚类之类的算法获取。统计地理区域可以根据供需比来确定。以北京为例，较大的人口可能居住在第二环区域，第三环区域或某些商业区域，并且可以将具有一个或两个街区的区域设置为统计地理区域。然而，较小的人口可能居住在第五环区域，第六环区域或其他郊区，可以将较大的区域设置为统计地理区域。应当注意统计地理区域仅用于说明目的，并非旨在限制本申请的范围。

在一些实施例中，用于确定统计地理区域的特定方法可以用在特殊的地理环境中。在一些实施例中，可以考虑多个因素。这些因素可能包括道路是否是单行道，大型商业广场是否有多个出入口，道路是否有“禁止停车”标志等。可以考虑这些因素来确定统计地理区域。在确定统计地理区域之后，可以通过定位用户的物理位置从统计地理区域识别目标统计地理区域。物理位置可以属于目标统计地理区域。

在1004中，处理设备112可以获取目标统计时段内在目标统计地理区域内的，每种交通出行服务的历史订单成功率。

在一些实施例中，可以获取至少两个先前订单。处理设备可以根据统计时间段和统计地理区域对至少两个先前订单进行分类。可以获取每个统计时间段期间每个统计地理区域内的历史订单成功率。历史订单成功率是通过在统计时间段内在统计地理区域中获取先前服务请求和先前服务供应来确定的。

可以确定与每个目标统计时间段和每个目标统计地理区域对应的订单成功率，并且可以进行目标统计时间段、目标统计地理区域和订单成功率之间的映射表。映射表可以以预设间隔实时更新，例如，每隔一个月、一天等。另外，映射表可以具有其他维度。例如，映射表可以是工作日的映射表、假日映射表或周的映射表。例如，工作日(例如，从8点到9点)的订单成功率可能小于节假日(例如，从8点到9点)的订单成功率。又例如，周一(例如，从18点到19点)的订单成功率可能比星期五(例如，从18点到19点)的订单成功率大。在一些实施例中，可以获取日期信息。日期信息是指应用服务器接收开启信息的日期(即服务请求的日期)。可以根据日期信息(例如，星期一、星期二等)确定目标统计日期。因此，可以确定关于日期的历史订单成功率(例如，周一和周二的先前订单的订单成功率)。

过程1000中提供的订单成功率预估方法可以包括在感测到用户开启交通出行用户界面时在界面上向用户提供至少两种交通出行服务，考虑到预先建立的评估标准，获取交通出行用户界面的启动时间，确定交通出行用户界面开启时间下降的目标统计时间段；获取用户的物理位置；考虑到预先建立的评估标准，确定用户的物理位置属于目标统计地理区域；获取目标统计时间段内目标统计地理区域内每种交通出行服务对应的历史订单成功率。可以识别具有最大订单成功率的交通出行服务并向用户推荐，从而为用户提供关于交通出行服务的可靠选择，从而提高用户的出行效率。另外，可以建立由交通出行服务提供者(例如，司机)和交通出行服务请求者(例如，乘客)之间的供需比率表示的平衡，这样可以最大化服务提供者和服务请求者的利益，可以提高资源利用率，并且也可以提高用户的出行便利性。

图11A是根据本申请的一些实施例所示的用于预估至少两种交通出行服务的订单成功率的过程1100的流程图。可以结合过程1000来描述过程1100。

在1101中，在用户感测到交通出行用户界面的开启时，处理设备112可以在界面上向用户提供至少两种交通出行服务。当用户计划出行时，可为用户选择至少两种交通出行服务。

在1102中，可以获取用户的物理位置。在一些实施例中，物理位置可以是用户的当前地理位置。

可以获取用于预估至少两种交通出行服务中的每种的订单成功率的预先建立的评估标准。在一些实施例中，预先建立的评估标准包括统计时间段和统计地理区域。

在1103a中，处理设备112可以确定交通出行用户界面的开启时间属于目标统计时间段。

在1103b中，处理设备112可以确定用户的物理位置属于目标统计地理区域。

在1104中，处理设备112可以获取目标统计时段内在目标统计地理区域内的每种交通出行服务的历史订单成功率。

在一些实施例中，1101至1104中的操作可以与1001至1004中的操作类似或相同。

在一些实施例中，预先建立的评估标准还可以包括例如天气状况、交通状况等。天气状况可能包括特殊的天气状况。在一些实施例中，天气状况可以是实时天气状况或预报天气状况。交通状况可包括交通拥堵度。在一些实施例中，交通状况可以是实时交通状况或预测交通状况。

在1105a中，如果预先建立的评估标准包括天气状况，则处理设备112可以确定在用户界面的开启时在物理位置处是否存在特殊的天气状况。

特殊天气状况是指影响历史订单成功率的天气状况。例如，在大雨或暴风雪等天气状况下，出租车服务和私家车等交通服务的数量可能会大幅下降。由于特殊天气的影响，历史订单成功率将小得多。因此，需要根据天气状况确定是否存在影响历史订单成功率的特殊天气状况。如果存在特殊天气状况，则可以调整基于大量先前订单确定的历史订单成功率，为用户提供更准确的订单成功率。

在1105b中，如果预先建立的评估标准包括交通状况，则处理设备112可以在物理位置的预设范围内重写道路的交通拥堵度。

交通拥堵度涉及根据实时道路状况确定的道路交通流量。例如，在用户的物理位置附近发生的交通事故可能影响在交通事故的一定范围内的每个车辆的行驶速度。由于交通事故的影响，获取的历史订单成功率将小得多。因此，需要根据实时交通状况确定交通拥堵度是否影响历史订单成功率。如果交通拥堵度改变，则可以调整基于大量先前订单确定的历史订单成功率，为用户提供更准确的订单成功率。

在1106中，如果在用户界面开启时在物理位置存在特殊天气状况和/或一定交通拥堵度，处理设备112可以根据每种交通出行服务的性质，确定由特殊天气状况或一定交通拥堵度中的至少一个对每种交通出行服务施加的影响因子。在一些实施例中，一定交通拥堵度可能超过预设的交通拥堵度阈值。

在一些实施例中，可以使用诸如特殊天气状况、交通拥堵度或两者的预先建立的评估标准作为用于调整历史订单成功率的调整因子。此外，为不同的天气状况和不同的交通拥堵度设置不同的影响因子(例如，交通拥堵度越高，影响因子越小，历史订单成功率越小)。同时，影响因子的设定还需要考虑交通出行服务的性质。例如，在道路拥堵的情况下，由于公共汽车具有公交车道并且自行车具有自行车道，因此这些交通出行服务可能受道路拥堵的影响较小。因此，对于不同的交通出行服务，在相同的交通拥堵度下，影响因子可能不同

在1107中，处理设备112可以基于其对应的历史订单成功率和影响因子，预估用户物理位置处的至少两种交通出行服务中的每种的订单成功率。

在确定各种交通出行服务的订单成功率之后，用户终端可以显示与各种交通出行服务中的每种相对应的订单成功率，这样，用户可以考虑各种交通出行服务的订单成功率(即交易概率)来选择交通出行服务。

显示交通出行服务的用户界面1130可以在图11B中示出。终端设备1132的显示屏1131显示由客户端应用程序提供的各种交通出行服务(快车、出租车、专车、拼车、公共汽车、自行车等)。通过上述操作(例如，过程1100中的操作)获取各种交通出行服务的订单成功率并显示在各种交通出行服务之下，并且用户可以根据各种交通出行服务的订单成功率(即交易概率)选择交通出行服务。如图11B所示，用户选择订单成功率为50％的快车服务，并准备下订单请求快车服务。

在一些实施例中，根据用户的不同习惯或偏好，可以提供更多选择，以进一步节省用户决定选择交通出行服务的时间。例如，在实际应用场景中，即使用户等待一段时间，用户也希望更快。除非他需要等待很长时间，否则他会选择出租车或带司机的汽车。然后，可以向用户提供当前订单的订单成功率、3分钟后下订单的订单成功率、5分钟后下订单的订单成功率等。

该具体实现包括对于预估的订单成功率小于预设订单成功率阈值的那些交通出行服务，处理设备112可以获取服务请求时间随后的时间段(推迟的时间段)内每种交通出行服务的历史订单成功率。处理设备112可以发送那些交通出行服务的历史订单成功率以及它们对应的推迟时间段，分别与界面上的交通出行服务相匹配。也就是说，如果第一交通出行服务是快车，并且快车服务的订单成功率(例如，30％)小于预设的阈值(例如，50％)，然后，用户在当前时间之后的时间段期间获取快车的历史订单成功率，从而向用户显示成功请求服务所花费的时间。

显示交通出行服务的用户界面1160和对应的订单成功率可以在图11C中示出。用户终端1162的显示屏1161显示由客户端应用程序提供的各种交通出行服务(快车、出租车、专车、乘车共享、公共汽车、自行车等)。各种交通出行服务的订单成功率显示在各种交通出行服务之下。如果预设阈值为50％，则可以向用户显示交通出行服务的订单成功率(如图11所示，可以在出租车服务、司机服务和拼车服务下方显示各种情况。目前快车服务的订单成功率为50％，目前的出租车服务订单成功率为30％，2分钟后增加到60％，5分钟后增加到80％。用户可以根据显示的订单成功率选择交通出行服务。如图11C所示，当用户点击出租车服务时，用户在2分钟内成功呼叫出租车的概率为30％，2分钟后概率增加到60％，5分钟后概率增加到80％。

图12是根据本申请的一些实施例的订单成功率预估设备的示意图。订单成功率预估设备1200可以包括接收模块1201、获取模块1202、确定模块1203和传输模块1204。

接收模块1201可以在感测到用户开启交通出行用户界面时在界面上向用户提供至少两种交通出行服务。当用户计划出行时，可为用户选择至少两种交通出行服务。

获取模块1202可以获取用户的物理位置。

确定模块1203可以在物理位置处基于预先建立的评估标准，预估至少两种交通出行服务中的每种的订单成功率。

上述订单成功率预估设备可以被配置为从客户端应用程序获取用户的开启信息，并且客户端应用程序可为用户提供至少两种类型的交通出行服务。可以获取用户的当前地理位置。可以根据预先建立的评估标准，确定当前地理位置处的每种交通出行服务的订单成功率。本申请使得能够基于用户的当前地理位置识别具有更高订单成功率的交通出行服务，这有助于准确可靠地分析当前服务位置用户的订单成功率，从而为用户提供可靠的交通出行服务推荐，提高用户的出行效率。同时，有助于使交通出行服务提供者(例如司机)和交通出行服务请求者(例如乘客)之间的供需比尽可能平衡，这样可以最大限度地提高服务提供者和服务请求者的利益，提高资源利用率，并实现用户行为的便利性。

在一些实施例中，确定模块还可以包括统计时间段确定子模块。统计时间段确定子模块可以确定交通出行用户界面的开启时间属于目标统计时间段。

在一些实施例中，确定模块还可以包括统计地理区域确定子模块。统计地理区域确定子模块可以确定用户的物理位置属于目标统计地理区域。

在一些实施例中，确定模块还可以包括历史订单成功率获取子模块。历史订单成功率获取子模块可以获取目标统计时段内在目标统计地理区域内的每种交通出行服务的历史订单成功率。在一些实施例中，历史订单成功率可以通过在统计时间段期间在统计地理区域中获取先前服务请求和先前服务供应来确定。

在一些实施例中，确定模块还可以包括天气确定子模块。如果预先建立的评估标准包括天气状况，则天气确定子模块可以确定在用户界面开启时在物理位置处是否存在特殊天气状况。

在一些实施例中，确定模块还可以包括交通状况确定子模块。如果预先建立的评估标准包括交通状况，则交通状况确定子模块在物理位置的预设范围内重写道路的交通拥堵度。

在一些实施例中，确定模块还可以包括影响因子确定子模块。如果在用户界面开启时在物理位置存在特殊天气状况和/或一定交通拥堵度，影响因子确定子模块可以根据每种交通出行服务的性质，确定由特殊天气状况或一定交通拥堵度中的至少一个施加的影响因子。

在一些实施例中，确定模块还可以包括订单成功率确定子模块。订单成功率确定子模块可以基于其对应的历史订单成功率和影响因子，预估用户物理位置处的至少两种交通出行服务中的每种的订单成功率。

在一些实施例中，获取模块1202可以进一步被配置为获取日期信息。日期信息是指应用服务器接收开启信息的日期(即服务请求的日期)。因此，确定模块还可以包括统计日期确定子模块。统计日期确定子模块可以根据日期信息(例如，星期一、星期二等)确定目标统计日期。因此，历史订单成功率获取子模块可以获取关于日期的历史订单成功率(例如，周一和周二的先前订单的订单成功率)。

传输模块1204可以被配置为向用户发送目标统计时段内在目标统计地理区域内的至少两种出行服务的订单成功率。

图13是根据本申请的一些实施例所示的用于推荐交通出行模式的过程1300的流程图。在一些实施例中，图13中所示的过程1300可以在图1中所示的交通出行推荐系统100中实现。例如，过程1300的至少一部分可以作为指令的形式存储在存储设备(例如，计算装置200的磁盘270)中，并且由服务器110(例如，计算装置200的处理器220)调用和/或执行。在一些实施例中，过程1300的一部分可以在终端设备上实现。以下呈现的所示过程1300的操作旨在是说明性的。在一些实施例中，过程1300可以利用未描述的一个或以上附加操作，和/或没有所讨论的一个或以上操作来完成。另外，如图13所示和下面描述的过程1300的操作的顺序不是限制性的。

如图13所示，交通出行模式推荐方法可以在交通出行模式推荐设备中实施。交通出行模式推荐设备可以由硬件和/或软件实现。在实际应用中，交通出行模式推荐设备可以是独立设备，例如与用户客户端交互的应用服务器客户端。交通出行模式推荐设备也可以集成在提供交通出行服务的网络平台(以下称为“平台”)所基于的云服务器，并且与存储提供交通出行服务的网络平台所基于的各种类型的数据库的数据服务器结合使用。另外，交通出行模式推荐设备所基于的服务器可以是数据服务器，也可以是与数据服务器相同的服务器集群的不同服务器，但不限于此。交通出行模式推荐设备还可以集成在由提供交通出行服务的网络平台交互的用户的客户支持的设备中。可以通过与提供交通出行服务的网络平台执行信息交互和数据更新，实现交通出行模式推荐方法。用户客户端支持的设备可以是例如智能手机，平板电脑(便携式安卓设备)或其他电子移动设备。这些电子设备可以被称为“用户终端”。交通出行模式推荐设备可以是应用服务器的形式。

在1301中，处理设备112可以获取用于每个路段路线的用户的先前出行数据，其包括出发位置和时间(出发数据)、到达位置和时间(到达数据)，以及所使用的交通出行模式。

先前出行数据是指在出行路线上收集的数据。出行路线可包括至少两个路段。先前出行数据可包括在出行路线的每个路段上使用的出发数据、到达数据和交通出行模式。出发数据可以包括例如出发位置(即出发位置)和出行路线的每个路段的出发时间。到达数据可以包括到达位置(即到达位置)和出行路线的每个路段的到达时间。先前出行数据可以由提供交通出行服务的网络平台获取，并通过网络平台收集用户的订单。在出行路线的每个路段中使用的交通出行模式可以是任何类型，例如，出租车、私家车(快车、专车、拼车等)、自行车、或带固定站的公共交通工具，如公共汽车、火车、地铁等。用户可以在终端中安装呈现各种出行服务的应用程序(APP)。以实际应用场景为例，用户可以在出发前通过平台安排出租车。平台可以将乘坐出租车的用户的该出行记录存储为用户的先前出行数据。

在1302中，处理设备112可以检索并使用路段的出发数据和到达数据来确定每个路段路线之间的相关性，为用户生成每个包括一个或以上路段路线的个性化出行路线。

出行路线的路段之间的相关性是指用户在一定时间段内的离散行程可以形成个性化的出行轨迹。在一些实施例中，第一行程的到达位置的坐标和第二行程的出发位置的坐标可以沿着用户的出行方向连接。例如，如果用户从位置A出发，则穿过位置B，然后到达位置C，最后到达位置D，顺序连接四个地理位置A、B、C和D，以获取用户的出行轨迹。出发位置和出行路线上的每个路段的到达位置意味着，例如，当用户在位置A处乘坐共用自行车时，平台将位置A记录为出行路线上的第一路段的出发位置；当用户骑自行车到位置B并转移到地铁时，平台将位置B记录为出行路线上第一路段的到达位置，第一路段是从A到B。用户通过在位置B购买机票或进入附近的地铁站，在出行路线的第二路段开始出行。当用户到达地铁上的位置C并通过平台请求快速服务时，可以记录从B到C的第二路段。在第二路段，平台将位置B记录为出发位置，将位置C记录为到达位置。类似地，如果用户在位置C乘坐快车，则位置C可以是出行路线上的第三路段的出发位置。如果用户到达位置D，则平台可以将位置D记录为第三路段的到达位置。从位置A到位置D，用户使用不同的交通出行模式。位置A、B、C和D不是孤立的地理位置，而是形成完整的出行轨迹。因此，上述A、B、C、D等每个地理位置相关联，形成包含上述三段路线的个性化出行路线(例如，从A到B的第一路段、从B到C的第二路段、从C到D的第三路段)。

另外，可以根据每个路段的出发时间和每个路段的到达时间来确定用户的个性化出行路线。例如，平台记录用户之前从A到D的出行数据，然而，从A到C的行程发生在早上，从C到D的行程发生在下午，那么从A到D的行程可能不被视为用户的个性化出行路线。因此，个性化的出行路线可能需要满足时间条件。也就是说，用户从位置A出发到位置D，位置B和位置C是位置A和位置D之间的中转站。因此，从A到C的行程可以是用户的个性化出行路线，并且从C到D的行程可以是用户的另一个个性化出行路线。本领域技术人员可以通过模拟用户的先前出行数据和/或使用统计分析方法来理解个性化出行路线的确定。例如，可以使用机器-学习算法或其他统计算法。

在1303中，处理设备112可以检索并使用每个路段的交通出行模式，在每个个性化出行路线上确定每个路段路线上各交通出行模式的使用频率，建立预估模型的交通出行模式。

交通出行模式预测模型可用于确定用户在个性化出行路线上选择每个路段路线中的每种交通出行模式的概率。建立模型的方式可以包括但不限于使用数学模型来表示每个用户的个性化出行路线。构造的数学模型用于预测用户在个性化出行路线的每个路段路线上使用的最可能的交通出行模式。交通出行模式预测模型可以包括但不限于马尔可夫模型、高斯模型、混合高斯模型、贝叶斯模型等，或其组合。

在1304中，处理设备112可以基于用户的当前位置从个性化出行路线中选择包括推荐路段的推荐出行路线。

在一些实施例中，可以在用户打开提供交通出行服务的平台的用户界面时获取用户的当前位置。在获取用户的当前位置之前，该方法还可以包括向用户的终端设备发送查询消息，以查询是否在终端设备上开启定位设备。如果用户同意开启定位设备，则可以通过终端设备获取用户的当前位置并将其发送到平台的应用服务器。可以通过经由GPS设备定位终端设备的位置，或者基于终端设备的信号计算终端设备的当前位置，或者获取终端设备的IP地址来获取当前位置。

可以获取用户的当前位置。在应用服务器分析用户先前出行数据之后，可以确定用户的多于一条的个性化出行路线。可以选择包括当前位置的个性化出行路线作为用户的推荐出行路线。在不同的情况下，根据用户的当前位置，在个性化出行路线中确定用户的推荐出行路线的方法也可以不同。例如，如果获取用户的当前位置，则可以根据1302中确定的个性化出行路线确定推荐的出行路线。还可能根据用户输入的目的地和当前位置的组合，更准确地确定两个位置之间的直通或转移路线。

此外，可以基于用户的当前位置，选择多个可能的个性化出行路线。然后，可以向用户推荐最可能推荐的出行路线，或者可以向用户推荐几个可能的推荐出行路线，其频率是根据先前出行数据选择每个个性化出行路线。处理设备112可以从用户接收确认消息，从几个可能的推荐出行路线中选择一个，以此确定推荐的出行路线。

在1305中，处理设备112可以使用交通出行模式预估模型，预测每个推荐路段的交通出行模式，为每个推荐路段生成推荐交通出行模式。

在1306中，处理设备112可以向用户发送推荐的出行路线以及每个推荐路段的推荐交通出行模式。

在一些实施例中，根据用户的当前位置确定推荐的出行路线后，如果推荐的出行路线包括多条路段路线，则可以根据交通出行模式预测模型，预测每个推荐路段上使用的交通出行模式，并推荐给用户。在一些实施例中，交通出行模式预测模型可以与道路状况相结合来预测合适的交通出行模式，从而提供一种新的交通出行模式预测模型，结合用户的偏好(交通出行模式预测模型)和实际的出行环境，以进一步提高用户的出行效率，有利于用户的出行体验。

所提供的出行服务推荐方法可以包括获取用于每个路段路线的用户的先前出行数据，其包括出发位置和时间(出发数据)、到达位置和时间(到达数据)，以及使用的交通出行模式；检索和使用路段的出发数据和到达数据，确定每条路段路线之间的相关性，为用户生成个性化的出行路线，每条路线包括一条或以上路段；检索并使用每个路段的交通出行模式，在每个个性化出行路线上，确定每个路段路线上各交通出行模式的使用频率，建立交通出行模式预估模型；根据用户当前位置从个性化出行路线中选择推荐的出行路线，包括推荐路段；使用交通出行模式预估模型预测每个推荐路段的交通出行模式，为每个推荐路段生成推荐交通出行模式；并将推荐的出行路线及其推荐的交通出行模式发送给用户。

图14是根据本申请的一些实施例所示的用于推荐交通出行模式的过程1400的流程图。在一些实施例中，可以结合过程1300来描述过程1400。

在1401中，处理设备112可以获取用于每个路段路线的用户的先前出行数据，其包括出发位置和时间(出发数据)、到达位置和时间(到达数据)，以及所使用的交通出行模式。

在1402中，处理设备112可以确定每两个连续的路段S_i和S_i+1之间的时间间隔是否小于第一时间间隔阈值。

如这里所使用的，时间间隔是指用户在路段上的到达时间与用户在连续路段上的出发时间之间的时间段。如果每两个连续的路段S_i和S_i+1之间的时间间隔小于或等于第一时间间隔阈值，则该过程可以进行到1403。如果每两个连续的路段S_i和S_i+1之间的时间间隔大于第一时间间隔阈值，则该过程可以进行到1404。

在一些实施例中，如果第一路段的到达时间在第二路段的出发时间之前，则第一路段与第二路段之间的关系可以是出行路线的两个路段。第一路段的到达时间与第二路段的出发时间之间的时间间隔定义了第一路段的末端和第二路段的开始之间的时间长度。例如，用户在位置A处使用共享自行车，在他/她到达位置B后转移到地铁。用户乘坐地铁到达位置C，然后请求快车到达位置D。如果在B位置乘坐共用自行车的时间是t₁(第一路段的到达时间)，在位置B进入地铁站的时间是t₂(第二路段的出发时间)，t₂-t₁可以表示第一路段的到达时间与第二路段的出发时间之间的时间间隔。

第一时间间隔阈值可以是阈值，其与基于大量先前出行数据的用户的一般行程规则一致。例如，如果用户从共享自行车停放的位置走到地铁站，则可能需要3分钟。如果第一时间间隔阈值是10分钟，则位置B可以被认为是转移站，并且从A到B以及B到C的行程可以被确定为用户的个性化出行路线。

在1403中，处理设备112可以确定出行路线的两个路段具有相关性，并且将每个具有相关性的两个路段连接起来以形成用户的个性化出行路线。

在一些实施例中，具有相关性的路段可以从1402识别，并且彼此连接，从而形成用户的个性化出行路线。

在1404中，如果每两个连续的路段S_i和S_i+1之间的时间间隔大于第一时间间隔阈值但小于第二时间间隔阈值，则处理设备112可以确定每两个连续的路段S_i和S_i+1之间的距离间隔是否在预设距离内，如果确定距离在预设距离内，则连接相关路段以生成个性化出行路线。

如果仅使用第一时间间隔阈值来确定两个路段是否具有相关性，则在许多实际应用中可能会错过用户的大量个性化出行路线。因此，有必要考虑地理范围阈值来确定个性化的出行路线。例如，用户将位置A的地铁乘坐到位置B，然后步行到位置C，然后从位置C到位置D呼叫快车。其中，位置A是用户的工作场所，位置D是用户的家。很明显，从A到D的行程是用户的个性化出行路线。然而，由于用户从位置B走到位置C的时间长于第一时间间隔阈值(例如，10分钟)，平台可能无法确定从A到B的行程和从C到D的行程具有相关性。

在这种情况下，可以使用预设距离阈值，确定位置B和位置C之间的距离间隔是否超过预设距离阈值(例如，1千米)。预设距离阈值可以是根据先前出行数据确定的距离。如果距离间隔没有超过预设距离阈值，则可以认为用户从位置B走到位置C，并且可以形成用户的个性化出行路线。另外，由于某些原因，用户在位置B转移，例如，在超市购买一瓶水等，第一路段的到达时间与第二路段的出发时间之间的时间间隔可能超过第一时间阈值。然而，可以确定用户靠近位置B，从而根据预设距离阈值，确定从A到B的行程和从B到C的行程具有相关性。此外，可以使用其他方法或技术来确定两个连续路段是否具有相关性。例如，可以获取由用户终端的加速度传感器或步行检测传感器测量的数据以确定用户是否从B走到C。

在一些实施例中，可以考虑具有大于第一时间间隔阈值的时间间隔的路段，结合预设距离阈值。因此，需要定义一个大于第一时间间隔阈值但小于或等于第二时间间隔阈值的时间间隔(例如，半小时、在一个地方短暂停留，或在超市买一瓶水)。另外，在用户长时间停留在某个地方然后开始另一个行程的情况下，通常不被认为是连贯的出行路线。例如，在早晨，用户从位置A到达位置B，然后出发去位置C，其中位置A是用户的家，位置C是用户的工作位置，位置B是转移站。在下午，用户从位置C到达位置D，然后返回到位置A，这意味着用户从不同路线上的工作位置回家。在这种情况下，从A到B到C到D，然后从D到A的行程将不被视为用户的个性化出行路线。相反，从A到C的行程是用户的个性化出行路线，从C到A的行程是用户的另一个个性化的出行路线。

在1405中，处理设备112可以基于每个路段上的用户的交通出行模式和在每个路段上的下一个交通出行模式的使用频率，根据先前交通出行模式，根据马尔可夫模型生成与每个路段上的每种交通出行模式相关联的概率矩阵，基于与每个路段上的每种交通出行模式相关联的概率矩阵，构建交通出行模式预测模型。

在1406中，处理设备112可以基于用户的当前位置从个性化出行路线中选择包括推荐路段的推荐出行路线。

在1407中，处理设备112可以在每个路段上获取用户的交通出行模式，并且基于概率矩阵，根据用户的先前交通出行模式确定每个路段上的下一个交通出行模式的使用频率。

在1408中，处理设备112可以基于下一个交通出行模式的使用频率，确定在个性化出行路线的每个路段上的各交通出行模式的概率，并且，确定与每个路段上的最大概率对应的交通出行模式，作为每个路段上的推荐交通出行模式。

在1409中，处理设备112可以向用户发送推荐的出行路线以及每个推荐路段的推荐交通出行模式。

在1405到1409中，马尔可夫模型遵循马尔可夫原理，并且是统计模型，其可以确定每个状态序列的状态序列的规律性，通过该状态序列，每个状态依赖于有限数量的状态。对于预测每个个性化出行路线中使用的车辆类型的过程，可以通过上述用户先前出行数据的统计确定来获取用户的历史出行路线；然后，可以基于在每个个性化出行路线上的先前出行中使用的交通出行模式来确定下一个交通出行模式的频率。也就是说，在个性化的出行路线中，在最后一次出行使用车辆之后，下一次出行使用各种车辆的数量分布。这推断出用户将在下一次出行中使用的车辆类型。为了简化操作，对于第一级马尔可夫模型，假设用户在个性化出行路线的一部分中使用的车辆记录如表3所示。

表3

时间	车辆
		2017/5/30 18:36	出租车
2017/6/2 17:58	出租车
		2017/6/12 12:04	出租车
2017/6/20 20:07	快车
		2017/6/27 9:43	出租车
2017/6/28 13:06	出租车
		2017/6/28 14:56	出租车
2017/6/28 17:40	出租车
		2017/6/29 9:10	出租车
2017/6/29 11:16	出租车
		2017/6/29 16:44	出租车
2017/7/3 10:26	出租车
		2017/7/4 18:58	出租车
2017/7/4 22:18	出租车
		2017/7/6 10:01	出租车
2017/7/7 15:06	出租车
		2017/7/7 19:27	出租车
2017/7/11 9:30	出租车
		2017/7/13 11:36	快车
2017/7/15 15:25	出租车
		2017/7/17 9:00	出租车
2017/7/18 11:42	出租车
		2017/7/18 20:58	出租车

根据1405的操作，基于马尔可夫模型，它可以得出表4的概率矩阵，

表4

	下次出租车时间	下次快车时间
			上次出租车时间	18	2
上次快车时间	2	0

从表4的概率矩阵可以看出，当将出行中使用的交通出行模式通知给用户时，表4的跳跃矩阵可用于预测下次出行中将使用哪种交通出行模式。统计获取的条件概率如下：

P(Y＝A│X＝A)＝0.9,

P(Y＝B│X＝A)＝0.1,

P(Y＝A│X＝B)＝1,

P(Y＝B│X＝B)＝0,

其中X代表上次使用的交通出行模式，Y代表下次使用的交通出行模式，A代表交通出行模式是出租车，B代表交通出行模式是快车。

假设用户的直接使用的交通出行模式是在路段中的快车B，通过马尔可夫矩阵，可以获取在下一段路段中的快车B的概率为0，并且使用出租车A的概率为1，平台将推荐出租车为用户选择出租车A解决方案。以上仅以个性化出行路线的一部分的马尔可夫矩阵为例进行描述，并且根据不同的个性化出行路线建立不同的马尔可夫模型，并根据每条个性化出行路线中包含的多路段行程频率，建立不同维度的马尔可夫模型，从而确定用户最可能在每个路段路线中采取的交通出行模式，例如位置A到位置B、位置B到位置C、位置C到位置D，并且向用户推荐。

图15是根据本申请的一些实施例的交通出行模式推荐设备的示意图。交通出行模式推荐设备1500可以包括获取模块1501、确定模块1502、构建模块1503、查询模块1504、预测模块1505和推荐模块1506。

获取模块1501可以获取每个路段路线的用户的先前出行数据，其包括出发位置和时间(出发数据)、到达位置和时间(到达数据)，以及使用的交通出行模式。

确定模块1502可以检索并使用路段的出发数据和到达数据来确定每个路段路线之间的相关性，为用户生成每个包括一个或以上路段路线的个性化出行路线。

构建模块1503可以检索并使用每个路段的交通出行模式，在每个个性化出行路线上确定每个路段路线上各交通出行模式的使用频率，建立交通出行模式预估模型。

查询模块1504可以基于用户的当前位置，从个性化出行路线中选择包括推荐路段的推荐出行路线。

预测模块1505可以使用交通出行模式预估模型，预测每个推荐路段的交通出行模式，为每个推荐路段生成推荐交通出行模式。

推荐模块1506可以向用户发送推荐的出行路线以及每个推荐路段的推荐交通出行模式。

本申请中披露的交通出行模式推荐设备可以获取用于每个路段路线的用户的先前出行数据，其包括出发位置和时间(出发数据)、到达位置和时间(到达数据)，以及使用的交通出行模式；检索并使用路段的出发数据和到达数据，确定每条路段路线之间的相关性，为用户生成个性化的出行路线，每条路线包括一条或以上路段；检索并使用每个路段的交通出行模式，在每个个性化的出行路线中，确定每个路段路线中各交通出行模式的使用频率，建立预估模型的交通出行模式；根据用户的当前位置，从个性化出行路线中选择推荐的出行路线，包括推荐路段；使用交通出行模式预估模型，预测每个推荐路段的交通出行模式，为每个推荐的路段生成推荐的交通出行模式；并将推荐的出行路线及其推荐的交通出行模式发送给用户。

在一些实施例中，确定模块1502还可以包括第一确定子模块。第一确定子模块可以基于S_i的到达时间和S_i+1的出发时间来确定每两个连续的路段S_i和S_i+1之间的时间间隔。如果时间间隔小于或等于第一时间间隔阈值，则第一确定子模块可以在两个连续路段之间生成相关性，并且连接相关路段以生成个性化出行路线。

在一些实施例中，确定模块1502还可以包括第二确定子模块。如果时间间隔大于第一时间间隔阈值但小于或等于第二时间间隔阈值，第二确定子模块可以基于S_i的到达位置和S_i+1的出发位置来确定每两个连续的路段S_i和S_i+1之间的距离间隔。如果距离间隔小于或等于第一距离间隔阈值，则第二确定子模块可以确定两个连续路段之间具有相关性；并连接相关路段以生成个性化的出行路线。

在一些实施例中，构建模块1503可以基于每个路段上的用户的交通出行模式和每个路段上的下一个交通出行模式的使用频率，根据先前交通出行模式，根据马尔可夫模型生成与每个路段上的每种交通出行模式相关联的概率矩阵，并根据每个路段上与每种交通出行模式相关的概率矩阵，构建交通出行模式预测模型。

在一些实施例中，预测模块1505还可以包括获取子模块、确定子模块、计算子模块和选择子模块。

获取子模块可以在每个路段上获取用户的先前传输模式；

确定子模块可以基于概率矩阵，根据用户的先前交通出行模式，确定每个路段上的下一个交通出行模式的使用频率；

计算子模块可以基于下一个交通出行模式的使用频率，确定个性化出行路线的每个路段上的每种交通出行模式的概率；以及

选择子模块可以将与每个路段上的最大概率对应的交通出行模式确定为每个路段上的推荐交通出行模式。

上文已对基本概念做了描述，显然，对于阅读此申请后的本领域的普通技术人员来说，上述发明披露仅作为示例，并不构成对本申请的限制。虽然此处并未明确说明，但本领域的普通技术人员可能会对本申请进行各种修改、改进和修正。该类修改、改进和修正在本申请中被建议，所以该类修改、改进、修正仍属于本申请示范实施例的精神和范围。

同时，本申请使用了特定词语来描述本申请的实施例。此外，本申请使用了特定术语来描述本申请的实施例。例如，术语“一个实施例”、“一实施例”以及“一些实施例”意指与本申请的至少一个实施例相关的某一特征、结构或特性。因此，应当强调并注意的是，本说明书中在不同位置两次或以上提及的“一实施例”或“一个实施例”或“一替代性实施例”并不一定是指同一实施例。此外，本申请的一个或以上实施例中的某些特征、结构或特点可以进行适当的组合。

此外，本领域的普通技术人员可以理解，本申请的每个方面可以通过若干具有可专利性的种类或情况进行说明和描述，包括任何新的和有用的过程、机器、产品或物质的组合，或对其任何新的和有用的改进。相应地，本申请的每个个方面可以完全由硬件实施、可以完全由软件(包括韧体、常驻软件、微代码等)实施、也可以由硬件和软件组合实施，上述硬件或软件均可以被称为“模块”、“单元”、“组件”、“设备”或“系统”。此外，本申请的每个方面可以采取体现在一个或以上计算机可读介质中的计算机程序产品的形式，其中计算机可读程序代码包含在其中。

计算机可读信号介质可能包含一个内含有计算机程序代码的传播数据信号，例如在基带上或作为载波的一部分。此类传播信号可以有多种形式，包括电磁形式、光形式等或任何合适的组合。计算机可读信号介质可以是除计算机可读存储介质之外的任何计算机可读介质，该介质可以通过连接至一个指令执行系统、装置或设备以实现通信、传播或传输供使用的程序。位于计算机可读信号介质上的程序代码可以通过任何合适的介质进行传播，包括无线电、电缆、光纤电缆、RF等，或任何上述介质的组合。

本申请每个部分操作所需的计算机程序编码可以用任意一种或以上程序语言编写，包括面向主体编程语言如Java、Scala、Smalltalk、Eiffel、JADE、Emerald、C++、C#、VB.NET、Python等，常规程序化编程语言如C语言、Visual Basic、Fortran 2003、Perl、COBOL 2002、PHP、ABAP，动态编程语言如Python、Ruby和Groovy，或其他编程语言等。该程序代码可以完全在用户计算机上运行、或作为独立的软件包在用户计算机上运行、或部分在用户计算机上运行部分在远程计算机运行、或完全在远程计算机或服务器上运行。在后种情况下，远程计算机可以通过任何网络形式与用户计算机连接，比如局域网(LAN)或广域网(WAN)，或连接至外部计算机(例如通过因特网)，或在云计算环境中，或作为服务使用如软件即服务(SaaS)。

此外，除非权利请求中明确说明，本申请所述处理元素和序列的顺序、数字字母的使用、或其他名称的使用，并非用于限定本申请流程和方法的顺序。尽管上述披露中通过各种示例讨论了一些目前认为有用的发明实施例，但应当理解的是，该类细节仅起到说明的目的，附加的权利请求并不仅限于披露的实施例，相反，权利请求旨在覆盖所有符合本申请实施例实质和范围的修正和等价组合。例如，虽然以上所描述的系统组件可以通过硬件设备实现，但是也可以只通过软件的解决方案得以实现，如在现有的服务器或移动设备上安装所描述的系统。

同理，应当注意的是，为了简化本申请披露的表述，从而帮助对一个或以上发明实施例的理解，前文对本申请实施例的描述中，有时会将多种特征归并至一个实施例、附图或对其的描述中。然而，本申请的该方法不应被解释为反映所声称的待扫描对象物质需要比每个权利请求中明确记载的更多特征的意图。实际上，申请专利范围的特征要少于上述披露的单个实施例的全部特征。