本申请涉及网约车技术领域，尤其涉及网约车订单分派方法、筛选规则生成或设置方法、装置、服务器、终端及介质。
背景技术：
随着技术的进步和互联网的兴起，网约车出行已经深入人们的生活，不仅为人们的生活带来了便利，也降低了出行的成本。
在司机和乘客使用网约车运营平台的过程中，需要通过技术手段来撮合网约车司机和乘客达成快速、精准的匹配，以实现高效的订单分派及履约。
但是，目前网约车运营平台的派单系统在网约车司机和乘客匹配的维度上，往往只是以司机和乘客的距离以及一些常规限制等为单一的考虑因素，而忽略了实际情况中涉及司机和乘客体验相关的信息，反而不利于网约车订单履约达成，导致履约成功率的降低。
技术实现要素：
鉴于以上所述现有技术的缺点，本申请的目的在于提供网约车订单匹配及相关方法、装置、服务器、终端及介质，从而解决现有技术的问题。
本申请第一方面提供一种网约车订单分派方法，包括：接收至少一个乘客的网约车订单；其中，每个乘客对应具有乘客信息；获取所述至少一个乘客的预设距离范围内的各网约车司机的司机信息；基于筛选规则、乘客信息和司机信息，筛选与乘客匹配的司机并分派网约车订单；其中，所述筛选规则至少包括：基于网约车司机的司机偏好信息筛选匹配的乘客。
在一些实施例中，所述获取所述至少一个乘客的预设距离范围内的各网约车司机的司机信息，包括：在所述至少一个乘客的预设距离范围内的各网约车司机中，筛选活跃状态的网约车司机，以供与乘客匹配。
在一些实施例中，所述网约车订单包括出发位置和目的位置；所述基于网约车司机的司机偏好信息筛选匹配的乘客，包括以下至少一种：1)基于网约车司机的顺路偏好与乘客的目的位置之间的匹配度来筛选；2)基于网约车订单的运载路线避开网约车司机的屏蔽位置来筛选；其中，所述运载路线基于网约车订单的出发位置及目的位置所产生。
在一些实施例中，所述筛选规则还包括以下中的一种或多种组合：1)基于乘客偏好信息匹配网约车司机；2)基于限行政策筛选网约车司机；3)基于乘客和/或司机安全策略进行乘客信息和司机信息的匹配，以筛选网约车司机；4)基于网约车司机群体的全局收益筛选网约车司机；5)基于网约车司机及乘客的新老用户程度所对应优先级筛选匹配的乘客和网约车司机；6)基于网约车司机的历史评价得分高低筛选网约车司机。
在一些实施例中，所述基于网约车司机群体收益筛选网约车司机，包括：基于各网约车司机完成所参与活动的优先级筛选网约车司机。
本申请第二方面提供一种筛选规则生成方法，包括：接收网约车司机的司机偏好信息；基于司机偏好信息生成用于筛选与乘客匹配的网约车司机的筛选规则。
本申请第三方面提供一种筛选规则设置方法，包括：响应于网约车司机的司机偏好选项的设置，形成司机偏好信息；发送司机偏好信息，以供生成用于筛选与乘客匹配的网约车司机的筛选规则。
本申请第四方面提供一种网约车订单分派装置，包括：订单接收模块，用于接收至少一个乘客的网约车订单；其中，每个乘客对应具有乘客信息；司机获取模块，用于获取所述至少一个乘客的预设距离范围内的各网约车司机的司机信息；订单匹配模块，用于基于筛选规则、乘客信息和司机信息，筛选与乘客匹配的司机并分派网约车订单；其中，所述筛选规则至少包括：基于网约车司机的司机偏好信息筛选匹配的乘客。
在一些实施例中，所述司机获取模块，包括：活跃筛选模块，用于在所述至少一个乘客的预设距离范围内的各网约车司机中，筛选活跃的网约车司机，以供与乘客匹配。
在一些实施例中，所述网约车订单包括出发位置和目的位置；所述基于网约车司机的司机偏好信息筛选匹配的乘客，包括以下至少一种：1)基于网约车司机的顺路偏好与乘客的目的位置之间的匹配度来筛选；2)基于网约车订单的运载路线避开网约车司机的屏蔽位置来筛选；其中，所述运载路线基于网约车订单的出发位置及目的位置所产生。
在一些实施例中，所述筛选规则还包括以下中的一种或多种组合：1)基于乘客偏好信息匹配网约车司机；2)基于限行政策筛选网约车司机；3)基于乘客和/或司机安全策略进行乘客信息和司机信息的匹配，以筛选网约车司机；4)基于网约车司机群体的全局收益筛选网约车司机；5)基于网约车司机及乘客的新老用户程度所对应优先级筛选匹配的乘客和网约车司机；6)基于网约车司机的历史评价得分高低筛选网约车司机。
在一些实施例中，所述基于网约车司机群体收益筛选网约车司机，包括：基于各网约车司机完成所参与活动的优先级筛选网约车司机。
本申请第五方面提供一种筛选规则生成装置，包括：接收模块，用于接收网约车司机的司机偏好信息；规则生成模块，用于基于司机偏好信息生成用于筛选与乘客匹配的网约车司机的筛选规则。
本申请第六方面提供一种筛选规则设置装置，包括：设置模块，用于响应于网约车司机的司机偏好选项的设置，形成司机偏好信息；发送模块，用于发送司机偏好信息，以供生成用于筛选与乘客匹配的网约车司机的筛选规则。
本申请第七方面提供一种服务器，包括：通信器、存储器及处理器；所述通信器用于与外部通信；所述存储器存储有程序指令；所述处理器用于运行所述程序以执行第一方面任一项所述的网约车订单分派方法；或者，执行如第二方面任一项所述的筛选规则生成方法。
本申请第八方面提供一种用户终端，包括：通信器、存储器及处理器；所述通信器用于与外部通信；所述存储器存储有程序指令；所述处理器用于运行所述程序以执行如第三方面任一项所述的筛选规则设置方法。
本申请第九方面提供一种计算机可读存储介质，存储有程序指令，所述程序指令被运行时执行如第一方面任一项所述的网约车订单分派方法；或者，执行如第二方面任一项所述的筛选规则生成方法；或者，执行如第三方面任一项所述的筛选规则设置方法。
综上，本申请提供的网约车订单匹配及相关方法、装置、服务器、终端及介质，分派方法包括：接收至少一个乘客的网约车订单；其中，每个乘客对应具有乘客信息；获取所述至少一个乘客的预设距离范围内的各网约车司机的司机信息；基于筛选规则、乘客信息和司机信息，筛选与乘客匹配的司机并分派网约车订单；其中，所述筛选规则至少包括：基于网约车司机的司机偏好信息筛选匹配的乘客。本申请通过设置包含更符合实际体验的司机偏好信息的筛选规则考虑，并进一步还能从乘客偏好、限制、单方或双方安全、司机群体利益、新老程度、历史评价等等方面中的一或多种来形成筛选规则，从而实现更精细、准确、人性化的筛选规则，有效提升乘客和司机之间的撮合成功率。
附图说明
图1展示本申请实施例中网约车服务的应用场景的结构示意图。
图2展示本申请实施例中计算机装置的结构示意图。
图3展示本申请实施例中网约车订单分派方法的流程示意图。
图4展示本申请实施例中活跃的网约车司机筛选的原理示意图。
图5a展示本申请实施例中基于网约车司机的顺路偏好的筛选规则进行筛选的原理示意图。
图5b展示本申请实施例中基于网约车司机的屏蔽地点偏好的筛选规则进行筛选的原理示意图。
图6展示本申请实施例中全局最优筛选匹配的乘客和司机组合的原理示意图。
图7展示本申请实施例中根据司机偏好设置形成基于司机偏好信息的筛选规则的流程示意图。
图8展示本申请实施例中网约车订单分派装置的模块示意图。
图9展示本申请实施例中筛选规则生成装置的模块示意图。
图10展示本申请实施例中筛选规则设置装置的模块示意图。
具体实施方式
以下通过特定的具体实例说明本申请的实施方式，本领域技术人员可由本说明书所揭露的内容轻易地了解本申请的其他优点与功效。本申请还可以通过另外不同的具体实施方式加以实施或应用系统，本说明书中的各项细节也可以基于不同观点与应用系统，在没有背离本申请的精神下进行各种修饰或改变。需说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。
下面以附图为参考，针对本申请的实施例进行详细说明，以便本申请所属技术领域的技术人员能够容易地实施。本申请可以以多种不同形态体现，并不限定于此处说明的实施例。
为了明确说明本申请，省略与说明无关的器件，对于通篇说明书中相同或类似的构成要素，赋予了相同的参照符号。
在通篇说明书中，当说某器件与另一器件“连接”时，这不仅包括“直接连接”的情形，也包括在其中间把其它元件置于其间而“间接连接”的情形。另外，当说某种器件“包括”某种构成要素时，只要没有特别相反的记载，则并非将其它构成要素排除在外，而是意味着可以还包括其它构成要素。
当说某器件在另一器件“之上”时，这可以是直接在另一器件之上，但也可以在其之间伴随着其它器件。当对照地说某器件“直接”在另一器件“之上”时，其之间不伴随其它器件。
虽然在一些实例中术语第一、第二等在本文中用来描述各种元件，但是这些元件不应当被这些术语限制。这些术语仅用来将一个元件与另一个元件进行区分。例如，第一接口及第二接口等描述。再者，如同在本文中所使用的，单数形式“一”、“一个”和“该”旨在也包括复数形式，除非上下文中有相反的指示。应当进一步理解，术语“包含”、“包括”表明存在所述的特征、步骤、操作、元件、组件、项目、种类、和/或组，但不排除一个或多个其他特征、步骤、操作、元件、组件、项目、种类、和/或组的存在、出现或添加。此处使用的术语“或”和“和/或”被解释为包括性的，或意味着任一个或任何组合。因此，“a、b或c”或者“a、b和/或c”意味着“以下任一个：a；b；c；a和b；a和c；b和c；a、b和c”。仅当元件、功能、步骤或操作的组合在某些方式下内在地互相排斥时，才会出现该定义的例外。
此处使用的专业术语只用于言及特定实施例，并非意在限定本申请。此处使用的单数形态，只要语句未明确表示出与之相反的意义，那么还包括复数形态。在说明书中使用的“包括”的意义是把特定特性、区域、整数、步骤、作业、要素及/或成份具体化，并非排除其它特性、区域、整数、步骤、作业、要素及/或成份的存在或附加。
表示“下”、“上”等相对空间的术语可以为了更容易地说明在附图中图示的一器件相对于另一器件的关系而使用。这种术语是指，不仅是在附图中所指的意义，还包括使用中的装置的其它意义或作业。例如，如果翻转附图中的装置，曾说明为在其它器件“下”的某器件则说明为在其它器件“上”。因此，所谓“下”的示例性术语，全部包括上与下方。装置可以旋转90°或其它角度，代表相对空间的术语也据此来解释。
虽然未不同地定义，但包括此处使用的技术术语及科学术语，所有术语均具有与本申请所属技术领域的技术人员一般理解的意义相同的意义。普通使用的字典中定义的术语追加解释为具有与相关技术文献和当前提示的内容相符的意义，只要未进行定义，不得过度解释为理想的或非常公式性的意义。
通常，在网约车技术领域，在进行乘客和网约车司机的撮合时，主要关注的是时间和地点，以期望于快速促成订单网约车订单履约达成。然而，即使被撮合的乘客和网约车司机双方虽然在地理位置上相近而匹配到一起，但最终仍然可能由于其它方面的不适配而最终导致网约车订单履约失败，尤其是经常被忽略的网约车司机自身的因素。
如图1所示，展示本申请实施例中网约车应用场景的结构示意图。
在该应用场景中，展示了需求网约车服务的乘客具有第一用户终端101。所述第一用户终端101可以搭载有用于与网约车运营平台通信的应用程序(app)，或通过网络浏览器访问网约车运营平台103所提供的乘客服务网络页面。乘客可在第一用户终端101所提供的图形用户界面通过其乘客身份id登录，并输入例如出发位置、目的位置等信息以生成网约车订单，并由第一用户终端101通过网络102发送到网约车运营平台103。
所述网约车运营平台103已存储有预先注册的各个用户的用户信息，其中的用户类型包括网约车司机、可能会存在网约车服务需求的乘客等。网约车运营平台103可以为产生网约车订单的乘客进行网约车司机的筛选，以确定匹配的目标网约车司机，进而将所述网约车订单分派给所述目标网约车司机的第二用户终端104。
所述第二用户终端104可以搭载有用于与网约车运营平台通信的应用程序，或通过网络浏览器访问网约车运营平台103所提供的网约车司机服务网络页面。网约车司机可以通过其网约车司机身份id进行登录。并且，可以在其第二用户终端104对所分派的网约车订单选择接单或不接单。当网约车司机接单，则前往乘客的出发位置进行履约。其中，
在一些实施例中，所述第一用户终端101可以实现为例如笔记本电脑、个人台式电脑、智能手机、平板电脑、智能手环、智能手表等。示例性地，所述第二用户终端104可以实现为例如智能手机、平板电脑、或车载多媒体终端等。示例性地，所述网络102可以是有线或无线网络，例如移动互联网络等。示例性地，所述网约车运营平台103可以包括服务器131、服务器组，以提供远端服务。
在可能示例中，所述网约车运营平台103的服务类型可以是以下中的任意一种：saas(软件即服务)，paas(平台即服务)，iaas(信息即服务)。
在一些实施例中，所述第一用户终端101、第二用户终端104和网约车运营平台103的服务器131可以通过计算机装置实现。例如，所述第一用户终端101、第二用户终端104和服务器131中可以具有计算机装置。
如图2所示，展示本申请实施例中计算机装置的结构示意图。
所述计算机装置200包括总线201、处理器202、通信器203和存储器204。处理器202、存储器204和通信器203之间可以通过总线201通信。所述存储器204中可以存储有程序指令，所述处理器202通过运行程序指令来实现第一用户终端、第二用户终端、服务器上执行的方法步骤。例如，在第一用户终端中，通过处理器通过运行程序指令以执行例如呼叫网约车产生网约车订单的方法；在网约车运营平台的服务器中，处理器运行程序指令以执行例如网约车订单分派方法；在第二用户终端中，处理器运行程序指令以执行例如对网约车订单接单的方法等。
总线201可以是外设部件互连标准(peripheralcomponentinterconnect，pci)总线或扩展工业标准结构(extendedindustrystandardarchitecture，eisa)总线等。总线可以分为地址总线、数据总线、控制总线等。为便于表示，虽然图2中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。
在一些实施例中，处理器202可以为中央处理器(centralprocessingunit，cpu)、微处理单元(mcu)、片上系统(systemonchip)、或现场可编程逻辑阵列(fpga)等实现。存储器204可以包括易失性存储器(volatilememory)以用于运行程序时的数据暂存使用，例如随机存取存储器(randomaccessmemory，ram)。存储器204还可以包括非易失性存储器(non-volatilememory)以用于数据存储，例如只读存储器(read-onlymemory，rom)，快闪存储器，硬盘驱动器(harddiskdrive，hdd)或固态盘(solid-statedisk，ssd)。
通信器203用于与外部通信。在具体实例中，所述通信器203可以包括一个或多个有线和/或无线通信电路模块。举例来说，所述通信器203可以包括例如有线网卡、usb模块、串行接口模块等中的一种或多种。无线通信模块所遵循的无线通信协议包括：例如近距离无线通信(nearfieldcommunication，nfc)技术、红外(infared，ir)技术、全球移动通讯系统(globalsystemformobilecommunications，gsm)、通用分组无线服务(generalpacketradioservice，gprs)、码分多址引入(codedivisionmultipleaccess，cdma)、宽带码分多址(widebandcodedivisionmultipleaccess，wcdma)、时分码分多址(time-divisioncodedivisionmultipleaccess，td-scdma)、长期演进(longtermevolution，lte)、蓝牙(bluetooth，bt)、全球导航卫星系统(globalnavigationsatellitesystem，gnss)等中的一种或多种。
如图3所示，展示本申请实施例中网约车订单分派方法的流程示意图。所述网约车订单分派方法可以由例如图1场景中的网约车运营平台的服务器所执行。
在此实施例中，所述方法具体包括如下步骤：
步骤s301：接收至少一个乘客的网约车订单。
在一些实施例中，所述网约车订单中还可以包含乘客的身份信息，以及乘客的出发位置和目的位置等信息。
每个乘客对应具有乘客信息。所述网约车订单中的出发位置和目的位置等可被认为是所述乘客信息中的一部分。示例性地，所述乘客信息可以包括乘客的基础信息，例如姓名、性别、年龄、身份证号、手机号等中的一或多种。示例性地，所述乘客信息还可以包括乘客偏好信息，例如车型选择、是否携带宠物、是否愿意拼车、是否愿意额外付高速费等。示例性地，所述乘客信息还可以包括乘客在网约车运营平台的历史服务记录、评价、新老用户等级(可以根据比如乘客的注册时间、叫车次数等来判断)。
可以理解的，所述乘客信息可以是由乘客在第一用户终端提供的人机交互接口(如图形用户接口、语音输入等)输入，进而由网约车运营平台与第一用户终端交互以获取，也可以是从所采集的部分乘客信息中提取得到另外部分乘客信息。
步骤s302：获取所述至少一个乘客的预设距离范围内的各网约车司机的司机信息。
在一些实施例中，根据乘客的第一用户终端提供的所在地点的地理位置信息(如gps信息或者基站定位信息)，通过地理位置服务(lbs)来适配该地点预设距离范围内的各个网约车司机，各个网约车司机的所在地点的地理位置信息可以由网约车司机的第二用户终端所提供。在另一些实施例中，也可以根据乘客在第一用户终端生成网约车订单时所输入的出发位置为基础，在出发位置的预设距离范围内筛选各个网约车司机。
在一些实施例中，所述预设距离范围实际上是乘客的呼叫距离范围。所述预设距离范围的大小可以根据一定的策略所设置，例如运营策略。举例来说，所述运营策略可以根据地理位置而设置不同呼叫的预设距离范围，包括地区运营策略、城市运营策略等，如在上海和哈尔滨的呼叫距离范围不同等。所述预设距离范围的大小可以是1、2、3、4、5、6、7公里或其它大小，也可以是根据不同的场景条件(如时间)而动态变化。
在一些实施例中，所述司机信息包括司机偏好信息。所述司机偏好信息例如包括：司机的住所位置，可用于通过lbs服务以根据网约车司机当前所在的位置和住所位置生成返回住所路线，以用于和乘客的目的位置之间进行顺路度匹配。可选的，所述司机偏好信息还可以包括屏蔽位置等，以用于筛选过滤与其匹配的乘客。
在一些实施例中，所述网约车司机的司机信息可以包括司机的基础信息。示例性地，所述司机信息可以包括司机的基础信息，例如网约车司机的姓名、性别、年龄、身份证号、驾驶证号、行驶证号、车辆信息(如车牌号、车型、行驶公里数中的一或多种)、手机号等中的一或多种；所述基础信息可以是在网约车司机在网约车运营平台注册时通过适配于司机人群的人机交互接口(如图形用户接口、语音输入等)输入获得，或者在其它应用场景下通过人机交互接口输入，或者从预先存储的数据中提取。示例性地，所述司机信息还可以包括：对应于乘客偏好选项的选项所设置的信息，例如对应是否携带宠物设置“否”等。示例性地，所述司机信息还可以包括司机在网约车运营平台的历史服务记录、评价、新老用户等级(可以根据比如网约车司机的注册时间、订单达成次数等来设置)。
可以理解的，所述司机信息可以是由网约车司机在第二用户终端提供的人机交互接口(如图形用户接口、语音输入等)输入，进而由网约车运营平台与第二用户终端交互以获取，也可以是从所采集的部分司机信息中提取得到另外部分的司机信息。
在一些实施例中，步骤s302中所获得预设距离范围内的各网约车司机，可以进行“活跃度”的筛选，以筛选出活跃的网约车司机，以在后续步骤中为乘客匹配活跃的网约车司机。示例性地，“活跃”的判断标准可以是网约车司机的第二用户端保持与网约车运营平台通信的在线状态。可能的，第二用户终端可以通过按一定时间频率进行所在位置的上报信号，来保持在线状态；反之，则表明第二用户终端离线而处于不倾向于接单的“非活跃状态”。
举例来说，在图4所示例的场景中，乘客x的第一用户终端401通过网络403发送网约车订单给网约车运营平台402，网约车运营平台402向乘客x获取其位置信息x1，同以x1为中心的预设距离范围r内的多个网约车司机y1、y2、y3、y4的第二用户终端403通信，如果其中只有y1、y2每隔10秒在上报其所在位置，而y3、y4均未上报，则认为y1和y2为活跃的网约车司机，而y3和y4不活跃。
进而，在之后与乘客x匹配时，排除y3和y4而只采用y1和y2。只有当y3、y4恢复在线而被判断为活跃时，才考虑将其与乘客匹配及派单。
通过筛除“不活跃”的网约车司机，也能有效提高网约车订单的履约成功率。
接续之前图3中的步骤s302，继续执行步骤s303：基于筛选规则、乘客信息和司机信息，筛选与乘客匹配的司机并分派网约车订单；其中，所述筛选规则至少包括：基于网约车司机的司机偏好信息筛选匹配的乘客。
在一些实施例中，所述司机偏好信息可以是关于网约车订单的顺路偏好、网约车订单避开屏蔽位置的。
在一些实施例中，可以基于网约车司机的顺路偏好与乘客的目的位置之间的匹配度，来为网约车司机筛选合适的乘客的网约车订单，顺路度越高则越匹配，具体可以通过比较从出发位置到目的位置再到网约车司机顺路偏好的地点或路线的总距离来判断。如图5a所示，展示根据顺路度匹配的一种示例。某个网约车司机d在网约车运营平台预先设置了偏好载客路线对其住所地a顺路，现有待载的乘客b和乘客c的网约车订单，待载的乘客b的网约车订单中出发位置为b1而目的位置为b2，待载的乘客c的网约车订单中出发位置为c1而目的位置为c2，网约车司机d当前所在地为d1位置，与c1、b1的距离之间比较接近。然而，对应网约车订单可以规划c1到c2的导航路线，b1到b2的导航路线，计算b1-b2-a和c1-c2-a的距离差，可以发现运送乘客c要比运送乘客b更加绕路，则单纯从顺路偏好的维度来匹配时，更优先将乘客b匹配给网约车司机d。
在可能的实例中，所述网约车司机的顺路偏好可以在预设条件下触发启用。比如，根据预先设置的每个网约车司机的单量上限，当达到最后一单时触发启用网约车司机的顺路偏好的筛选规则；又或者，根据预先设置的每天的下班时间触发启用等。
在一些实施例中，可以基于网约车订单的运载路线避开网约车司机的屏蔽位置来筛选；其中，所述运载路线基于网约车订单的出发位置及目的位置所产生。示例性的，所述屏蔽位置可以关于高速收费站/路段、拥堵路段、限行路段等，不同类型的屏蔽位置之间也可以设置不同的优先级。在具体实例中，如图5b所示，某个网约车司机e在网约车运营平台预先设置了不经过高速收费站f，拥堵路段g；乘客h的网约车订单从出发位置h1到目的位置h2，其所对应的运载路线需要经过f走高速；乘客i的网约车订单对应从触发位置i1到目的位置，其所对应的运载路线需要经过g，如果拥堵路段优先级高于高速收费路段，则单从屏蔽位置偏好的维度来匹配时，可以把i优先于h匹配于e，当然如果存在某个乘客j的运载路线j1～j2不经过f和g，则更优先地匹配给e。
需说明的是，为便于理解，在上述图示中的行进路线示意性地通过直线表示，但实际上可以是对应于任何实际道路中的行进路线的。另外，对应每个乘客的网约车订单中出发位置到目的位置的运载路线也并非限于图示中的一条，而可能是多条，则可以通过在本申请教示的思想下，对每一条运载路线均进行偏好匹配并得到匹配结果。
在上述示例中，展示从司机偏好的维度筛选匹配的乘客和网约车司机的原理，从而考虑了网约车司机的偏好而提升订单履约成功率。在其它实施例中，本申请还可以提供更多信息维度的筛选规则，以进一步提升乘客和网约车司机匹配的精准度、效率和履约成功率。
在可选的实例中，所述筛选规则还包括以下中的一种或多种组合：
在一些实施例中，所述筛选规则可以包括：基于乘客偏好信息筛选网约车司机。在具体实例中，所述乘客偏好信息包括：车型选择、是否携带宠物、是否愿意拼车、是否愿意额外付高速费等中的一种或多种。例如，在进行匹配的网约车司机的筛选时，可以根据司机信息中的车型信息来与乘客在“车型选择”选项上所设置的车型信息，比如出租车或私家车，新能源车或汽油车，a级或b级车，商务车，5人座或7人座等，此处不作展开；再例如，乘客在是否携带宠物上选择携带，而司机信息中对应是否允许携带宠物选择“否”，则此项不匹配；又例如，乘客选择愿意拼车，而司机信息中设置同意拼车，则此项相匹配；又例如，乘客选择愿意额外付高速费，则即使某个网约车司机的司机信息中设置屏蔽地点为“高速收费站”，仍然可能可以实现此示例中的乘客和网约车司机的匹配，并可选地随分派给网约车司机的此乘客网约车订单附相应提醒消息，以提醒乘客的偏好可能可以覆盖其屏蔽“高速收费站”的原因。
在一些实施例中，所述筛选规则可以包括：基于限行政策筛选网约车司机。举例来说，不同城市的会存在不同的交通限行政策。比如限制高架路在预定时段不对外地车牌的车辆开放等，或者悬挂专用于郊区车牌(例如“沪c”)的车辆，限制进上海外环以内等。在根据乘客的网约车订单获得其可能的运载路线时，判断运载路线是否经过限行区域而需要什么类型的车牌来匹配，从而与司机信息中基础信息中的车牌信息进行匹配以筛选网约车司机。
在一些实施例中，所述筛选规则可以包括：基于乘客和/或司机安全策略进行乘客信息和司机信息的匹配，以筛选网约车司机。关于乘客、司机的安全策略，可以在例如乘客和司机的性别、乘客的出行时间、乘客的目的位置、乘客是单人或多人(可以在乘客填写网约车订单时设置选项以采集)中的一或多个考量维度的组合下进行安全层面的筛选，比如乘客和司机之间是异性、乘客出行时间为深夜(可以定义时段，比如凌晨1～5点等)、比如乘客的目的位置偏僻(可以通过对地图上区域定义)、乘客单人、乘客多人而司机单人等组合对应一定的危险情况，则基于安全策略筛选匹配的乘客和司机时，避开此类组合。
在一些实施例中，所述筛选规则可以包括：基于网约车司机群体的全局收益筛选网约车司机。在一些实施例中，网约车运营平台可以发布面向网约车司机的活动，比如对应上、下班高峰时段的接单活动等，参与活动的网约车司机会对应进行接单量的积累统计。考虑到网约车司机群体的收益，可以根据网约车司机的活动完成度进行派单，比如优先给即将完成(如离完成活动目标还差n单，n达到预设阈值以下)活动目标的网约车司机派单；举例来说，网约车司机k和l，网约车司机k还差1单完成接单活动，网约车司机l还差2单完成接单活动，则可对k优先于l进行乘客匹配及派单。
示例性地，所述筛选规则可以包括：基于网约车司机及乘客的新老用户程度所对应优先级筛选匹配的乘客和网约车司机。例如，对于网约车运营平台的新、老乘客而言，可以优先给老乘客派单；例如，对于网约车运营平台的新、老网约车司机而言，可以优先给新网约车司机派单，以有效帮助新司机熟悉系统。
示例性地，所述筛选规则可以包括：基于网约车司机的历史评价得分高低筛选网约车司机。举例来说，每个网约车司机对于其履约完成的网约车订单均会收到得分，这些得分会综合成所述网约车司机总的历史评价得分，比如5分、4.9分、4.8分等。对于其它条件相近的两个网约车司机而言，可以优先将优质(比如相对收益较高)的网约车订单分配给历史评价得分高的网约车司机。
需说明的是，以上的各种筛选规则可以不同组合方式来组合使用，在组合使用时，可以对于各种筛选规则按其重要性分配不同权重，根据综合各个筛选规则的筛选结果来最终确认对于每个乘客匹配的各个网约车司机的优先级排序，并可以选择优先级最高的网约车司机进行匹配的乘客的网约车订单的派单。
另外，在一些实施例中，筛选每个乘客匹配的网约车司机的过程，可以并非是独立地按每个乘客逐一执行，如此可能达到局部个体的乘客利益最优，但导致其它乘客利益受损。因此，可以批量地对某个区域内产生网约车订单的乘客集合同这些乘客所在地理位置预设距离范围内活跃的网约车司机集合进行全局最优的匹配。
以图6所展示，存在网约车订单的乘客示例性地有两位，分别为乘客m和乘客n，在他们所在地理位置为中心的预设距离范围内，存在活跃的网约车司机p1～p7，其中p1和p2只匹配m，p7只匹配n，其它的p3、p4、p5、p6既可以匹配于m又可以匹配于n，则基于m和n之间的利益平衡，可以全局性地进行p1～p7与m、n的匹配，以实现与乘客集合(m，n)匹配能实现最大收益的网约车司机集合(此示例中可以为从p1到p7中选择的2个网约车司机)。
如图7所示，展示本申请实施例中根据司机偏好设置形成基于司机偏好信息的筛选规则的流程示意图。所述流程可以由例如图1中的网约车运营平台和第二用户终端之间的通信交互实现。
本实施例中的流程包括：
步骤s701：第二用户终端响应于网约车司机的司机偏好选项的设置，形成司机偏好信息。
在一些实施例中，第二用户终端可以显示用于司机偏好选项设置的图形用户界面(通过网约车相关app显示，或者通过网约车运营平台提供的网络页面所显示)，网约车司机可以通过操作第二用户终端(可以是手动操作或者语音操作)，以设置司机偏好选项形成司机偏好信息，即例如前述偏好的顺路、屏蔽位置相关的信息。
步骤s702：第二用户终端发送司机偏好信息给网约车运营平台。
步骤s703：基于司机偏好信息生成用于筛选与乘客匹配的网约车司机的筛选规则。
如图8所示，展示本申请实施例中的网约车订单分派装置。所述网约车订单分派装置的具体实现可以参考之前网约车订单分派方法的实施例，此处不再对相同技术细节进行重复赘述。
所述网约车订单分派装置800包括：
订单接收模块801，用于接收至少一个乘客的网约车订单；其中，每个乘客对应具有乘客信息；
司机获取模块802，用于获取所述至少一个乘客的预设距离范围内的各网约车司机的司机信息；
订单匹配模块803，用于基于筛选规则、乘客信息和司机信息，筛选与乘客匹配的司机并分派网约车订单；其中，所述筛选规则至少包括：基于网约车司机的司机偏好信息筛选匹配的乘客。
在一些实施例中，所述司机获取模块可以包括：活跃筛选模块804，用于在所述至少一个乘客的预设距离范围内的各网约车司机中，筛选活跃的网约车司机，以供与乘客匹配。
在一些实施例中，所述网约车订单包括出发位置和目的位置；所述基于网约车司机的司机偏好信息筛选匹配的乘客，包括以下至少一种：1)基于网约车司机的顺路偏好与乘客的目的位置之间的匹配度来筛选；2)基于网约车订单的运载路线避开网约车司机的屏蔽位置来筛选；其中，所述运载路线基于网约车订单的出发位置及目的位置所产生。
在一些实施例中，所述筛选规则还包括以下中的一种或多种组合：1)基于乘客偏好信息匹配网约车司机；2)基于限行政策筛选网约车司机；3)基于乘客和/或司机安全策略进行乘客信息和司机信息的匹配，以筛选网约车司机；4)基于网约车司机群体的全局收益筛选网约车司机；5)基于网约车司机及乘客的新老用户程度所对应优先级筛选匹配的乘客和网约车司机；6)基于网约车司机的历史评价得分高低筛选网约车司机。
在一些实施例中，所述基于网约车司机群体收益筛选网约车司机，包括：基于各网约车司机完成所参与活动的优先级筛选网约车司机。
如图9所示，展示本申请实施例中的筛选规则生成装置的模块示意图。所述筛选规则生成装置的具体实现，可以参考之前图7的根据司机偏好设置形成筛选规则的流程中网约车运营平台的执行步骤，此处不再对相同技术细节进行重复赘述。
所述筛选规则生成装置900，包括：
接收模块901，用于接收网约车司机的司机偏好信息；
规则生成模块902，用于基于司机偏好信息生成用于筛选与乘客匹配的网约车司机的筛选规则。
如图10所示，展示本申请实施例中筛选规则设置装置的模块示意图。所述筛选规则设置装置的具体实现，可以参考之前图7的根据司机偏好设置形成筛选规则的流程中第二用户终端的执行步骤，此处不再对相同技术细节进行重复赘述。
所述筛选规则设置装置1000，包括：
设置模块1001，用于响应于网约车司机的司机偏好选项的设置，形成司机偏好信息；
发送模块1002，用于发送司机偏好信息，以供生成用于筛选与乘客匹配的网约车司机的筛选规则。
本申请实施例中还可以提供计算机可读存储介质，其上存储有程序指令，所述程序指令运行时执行例如图3所示的网约车订单分派方法中的各步骤、图7所示的流程中的网约车运营平台中服务器所执行的各步骤、或图7所示的流程中的第二用户终端所执行的各步骤。
即上述方法步骤被实现为可存储在记录介质(诸如cdrom、ram、软盘、硬盘或磁光盘)中的软件或计算机代码，或者被实现通过网络下载的原始存储在远程记录介质或非暂时机器可读介质中并将被存储在本地记录介质中的计算机代码，从而在此描述的方法可被存储在使用通用计算机、专用处理器或者可编程或专用硬件(诸如asic或fpga)的记录介质上的这样的软件处理。
在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以程序指令产品的形式实现。程序指令产品包括一个或多个程序指令。在计算机上加载和执行程序指令指令时，全部或部分地产生按照本申请的流程或功能。计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。程序指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输。
例如，图8、图9、图10实施例中的各个功能模块可以是软件实现；或者也可以是软硬件配合实现，例如通过计算机设备实施例中的处理器运行存储器的程序指令实现；或者，也可以是通过硬件电路实现。
此外，在本申请各个实施例中的各功能模块可以动态在一个处理部件中，也可以是各个模块单独物理存在，也可以两个或两个以上模块动态在一个部件中。上述动态的部件既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。上述动态的部件如果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读存储介质中。该存储介质可以是只读存储器，磁盘或光盘等。
例如，图8、图9、图10实施例中各个功能模块可以是独立、单一的程序实现，也可以是一程序中的不同程序段分别实现，在某些实施场景中，这些功能模块可以位于一个物理设备，也可以位于不同的物理设备但相互通信耦合。
在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包括于本申请的至少一个实施例或示例中。而且，描述的具体特征、结构、材料或者特点可以在任一个或多个实施例或示例中以合适的方式结合。此外，在不相互矛盾的情况下，本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。
此外，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或隐含地包括至少一个该特征。在本申请的描述中，“多个”的含义是两个或两个以上，除非另有明确具体的限定。
流程图中或在此以其他方式描述的任何过程或方法描述可以被理解为，表示包括一个或更多个用于实现特定逻辑功能或过程的步骤的可执行指令的代码的模块、片段或部分。并且本申请的优选实施方式的范围包括另外的实现，其中可以不按所示出或讨论的顺序，包括基于所涉及的功能按基本同时的方式或按相反的顺序，来执行功能。
例如，图3、图7等方法实施例中各个步骤的顺序可能可以在具体场景中加以变化，并非以上述描述为限。
在本申请所提供的几个实施例中，应该理解到，所揭露的装置，可通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如所述模块的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个模块或组件可以结合或者可以动态到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或模块的间接耦合或通信连接，可以是电性或其它的形式。
上述实施例仅例示性说明本申请的原理及其功效，而非用于限制本申请。任何熟悉此技术的人士皆可在不违背本申请的精神及范畴下，对上述实施例进行修饰或改变。因此，举凡所属技术领域中具有通常知识者在未脱离本申请所揭示的精神与技术思想下所完成的一切等效修饰或改变，仍应由本申请的权利要求所涵盖。
