网约车的分配方法、装置、电子设备及存储介质与流程

文档序号:26009878发布日期:2021-07-23 21:29阅读:98来源:国知局
网约车的分配方法、装置、电子设备及存储介质与流程
本申请涉及网约车
技术领域
,尤其涉及一种网约车的分配方法、装置、电子设备及存储介质。
背景技术
:伴随网络技术的飞速发展,人们出行方式不仅局限在通过出租车出行,越来越多的人选择利用网络平台在线约车的方式出行。并且通过网络平台在线约车的方式,乘客可以更好安排出行时间、服务体验也较好,可以弥补现有出行方式中不能满足的出行需求。网约车需要网约车平台、车辆终端和乘客终端的协同操作。如何优化网约车的资源配置一直是改进的方向。技术实现要素:本申请实施例提供一种网约车的分配方法、装置、电子设备及存储介质,从而提高网约车成功接驾乘客的效率。第一方面,本申请一实施例提供了一种网约车的分配方法,所述方法包括:获取满足预设条件的行车订单;所述预设条件包括:行车订单处于接驾状态、乘客的出发地之间的距离小于或等于距离阈值、派单时间差在一定阈值内;针对每个所述行车订单中的所述出发地,分别确定各行车订单中的初始接驾车辆到所述出发地的接驾成本;基于各所述行车订单的整体接驾成本最低的约束条件,对各所述接驾成本进行处理,重新确定各所述行车订单中的最终接驾车辆。可选的,所述接驾成本包括以下中的至少一种:接驾里程、接驾时长、改变初始规划路线后的路线调整时间。可选的,在所述针对每个所述行车订单中的所述出发地,分别确定各行车订单中的初始接驾车辆到所述出发地的接驾成本之后,所述方法还包括:针对每个行车订单的出发地分别执行:将所述行车订单中的初始接驾车辆到所述出发地的接驾成本确定为第一成本;将其他行车订单中的初始接驾车辆到所述出发地的接驾成本确定为第二成本;筛选出小于所述第一成本的所述第二成本。可选的,所述基于各所述行车订单的整体接驾成本最低的约束条件,对各所述接驾成本进行处理,重新确定各所述行车订单中的最终接驾车辆,包括:将每个行车订单中的所述初始接驾车辆组成的集合作为第一集合,将每个行车订单中的乘客组成的集合作为第二集合;基于所述第一集合中的车辆与所述第二集合中的乘客之间的初始接驾关系以及各所述接驾成本对应的接驾关系,构建二分图;利用所述二分图、以及为各所述对应关系关联的预设权重占比,重新确定各所述行车订单中的最终接驾车辆。可选的,在所述利用所述二分图、以及预设权重占比,重新确定各所述行车订单中的最终接驾车辆之前,所述方法还包括:若确定所述二分图不符合车辆置换条件,则调整车辆与乘客之间不存在接驾关系的权重占比,所述车辆置换条件为各所述行车订单中的乘客都有对应的所述最终接驾车辆。可选的,所述方法还包括:获取出发地在指定地理区域内、且指定时间信息在同一时间切片内的行车订单,所述指定时间信息包括下单时间点和/或派单时间点,其中,指定地理区域根据所述距离阈值确定,时间切片根据所述派单时间差对应的阈值确定。可选的,所述方法还包括:若确定任一所述行车订单中的所述初始接驾车辆为应急车辆,则对所述应急车辆的乘客重新派车。可选的,根据以下任意一种情况确定所述初始接驾车辆为所述应急车辆:所述初始接驾车辆出现故障、所述初始接驾车辆出现事故、所述初始接驾车辆出现交通堵塞、所述初始接驾车辆的司机触发应急换车请求、所述初始接驾车辆的乘客触发急需用车请求。可选的,若所述接驾成本为所述接驾里程,所述整体接驾成本为各所述行车订单的平均接驾里程或总接驾里程;若所述接驾成本为所述接驾时长,所述整体接驾成本为各所述行车订单的平均接驾时长或总接驾时长;若所述接驾成本包括所述接驾里程和所述接驾时长,则所述整体接驾成本包括以下成本中的任一种:平均接驾里程和平均接驾时长的第一组合成本;平均接驾里程和总接驾时长的第二组合成本;平均接驾时长和总接驾里程的第三组合成本。总接驾时长和总接驾里程的第四组合成本。第二方面,本申请一实施例提供了一种网约车的分配方法,所述方法包括:响应于服务端对叫车请求的派单结果,展示接驾车辆的虚拟车辆信息;接收所述服务端发送的更新消息,更新所述虚拟车辆信息为最终接驾车辆的车辆信息,其中,所述最终接驾车辆的车辆信息为基于上述第一方面中任一所述方法确定的。可选的,所述更新所述虚拟车辆信息为最终接驾车辆的车辆信息之前,所述方法还包括:确定预设时长和/或预设距离内未接收到乘客的急需用车请求,所述预设时长为乘客到达出发地所需的时长,或者为从乘客下单时间开始的指定时长,所述预设距离为所述接驾车辆与所述出发地之间的指定距离阈值。可选的,所述方法还包括:若所述预设时长和/或所述预设距离内接收到所述乘客的急需用车请求,则发送重新派车指令至服务端;并,基于重新派车结果更新接驾车辆的车辆信息。可选的,所述方法还包括:若接收到服务端发送的应急换车通知,则从所述应急换车通知中解析出新分配的车辆的车辆信息;展示所述新分配的车辆的车辆信息;其中,所述应急换车通知为基于以下触发条件中的至少一种条件触发的:司机触发的应急换车请求、车辆故障。第三方面,本申请一实施例提供了一种网约车的分配装置,所述装置包括:获取单元,用于获取满足预设条件的行车订单;所述预设条件包括:行车订单处于接驾状态、乘客的出发地之间的距离小于或等于距离阈值、派单时间差在一定阈值内;第一确定单元,用于针对每个所述行车订单中的所述出发地,分别确定各行车订单中的初始接驾车辆到所述出发地的接驾成本;第二确定单元,用于基于各所述行车订单的整体接驾成本最低的约束条件,对各所述接驾成本进行处理,重新确定各所述行车订单中的最终接驾车辆。可选的,所述接驾成本包括以下中的至少一种:接驾里程、接驾时长、改变初始规划路线后的路线调整时间。可选的,所述第一确定单元,还用于:针对每个行车订单的出发地分别执行:将所述行车订单中的初始接驾车辆到所述出发地的接驾成本确定为第一成本;将其他行车订单中的初始接驾车辆到所述出发地的接驾成本确定为第二成本;筛选出小于所述第一成本的所述第二成本。可选的,所述第二确定单元,用于:将每个行车订单中的所述初始接驾车辆组成的集合作为第一集合,将每个行车订单中的乘客组成的集合作为第二集合;基于所述第一集合中的车辆与所述第二集合中的乘客之间的初始接驾关系以及各所述接驾成本对应的接驾关系,构建二分图;利用所述二分图、以及为各所述对应关系关联的预设权重占比,重新确定各所述行车订单中的最终接驾车辆。可选的,所述第二确定单元,还用于:若确定所述二分图不符合车辆置换条件,则调整车辆与乘客之间不存在接驾关系的权重占比,所述车辆置换条件为各所述行车订单中的乘客都有对应的所述最终接驾车辆。可选的,所述装置还包括:获取出发地在指定地理区域内、且指定时间信息在同一时间切片内的行车订单,所述指定时间信息包括下单时间点和/或派单时间点,其中,指定地理区域根据所述距离阈值确定,时间切片根据所述派单时间差对应的阈值确定。可选的,所述装置还包括:若确定任一所述行车订单中的所述初始接驾车辆为应急车辆,则对所述应急车辆的乘客重新派车。可选的,根据以下任意一种情况确定所述初始接驾车辆为所述应急车辆:所述初始接驾车辆出现故障、所述初始接驾车辆出现事故、所述初始接驾车辆出现交通堵塞、所述初始接驾车辆的司机触发应急换车请求、所述初始接驾车辆的乘客触发急需用车请求。可选的,若所述接驾成本为所述接驾里程,所述整体接驾成本为各所述行车订单的平均接驾里程或总接驾里程;若所述接驾成本为所述接驾时长,所述整体接驾成本为各所述行车订单的平均接驾时长或总接驾时长;若所述接驾成本包括所述接驾里程和所述接驾时长,则所述整体接驾成本包括以下成本中的任一种:平均接驾里程和平均接驾时长的第一组合成本;平均接驾里程和总接驾时长的第二组合成本;平均接驾时长和总接驾里程的第三组合成本;总接驾时长和总接驾里程的第四组合成本。第四方面,本申请一实施例提供了一种网约车的分配装置,所述装置包括:展示单元,用于响应于服务端对叫车请求的派单结果,展示接驾车辆的虚拟车辆信息;更新单元,用于接收所述服务端发送的更新消息,更新所述虚拟车辆信息为最终接驾车辆的车辆信息,其中,所述最终接驾车辆的车辆信息为基于第一方面中任一所述方法确定的。可选的,所述更新单元之前,所述装置还包括:确定预设时长和/或预设距离内未接收到乘客的急需用车请求,所述预设时长为乘客到达出发地所需的时长,或者为从乘客下单时间开始的指定时长,所述预设距离为所述接驾车辆与所述出发地之间的指定距离阈值。可选的,所述装置还包括:若所述预设时长和/或所述预设距离内接收到所述乘客的急需用车请求,则发送重新派车指令至服务端;并,基于重新派车结果更新接驾车辆的车辆信息。可选的,所述装置还包括:若接收到服务端发送的应急换车通知,则从所述应急换车通知中解析出新分配的车辆的车辆信息;展示所述新分配的车辆的车辆信息;其中,所述应急换车通知为基于以下触发条件中的至少一种条件触发的:司机触发的应急换车请求、车辆故障。第五方面,本申请一实施例还提供了一种电子设备,包括:处理器;用于存储所述处理器可执行指令的存储器;其中,所述处理器被配置为执行所述指令,以实现如本申请第一方面或第二方面中提供的任一方法。第六方面,本申请一实施例还提供了一种计算机可读存储介质,当所述计算机可读存储介质中的指令由电子设备的处理器执行时,使得电子设备能够执行如本申请第一方面或第二方面中提供的任一方法。第七方面,本申请一实施例提供了一种计算机程序产品,包括计算机程序/指令,所述计算机程序/指令被处理器执行时实现如本申请第一方面或第二方面中提供的任一方法。本申请的实施例提供的技术方案至少带来以下有益效果:本申请提出了一种网约车的分配方法,通过获取行车订单处于接驾状态、乘客的出发地之间的距离小于或等于距离阈值、派单时间差在一定阈值内的行车订单,针对每个行车订单中的出发地,分别确定各行车订单中的初始接驾车辆到出发地的接驾成本,基于各行车订单的整体接驾成本最低的约束条件,对各接驾成本进行处理,重新确定各行车订单中的最终接驾车辆。由此,本申请实施例在派单后,还可以根据指定时间段内车辆和乘客的信息,优化一定区域内的车辆分配,进而可以提高网约车成功接驾乘客的效率,优化网约车资源的配置。应当理解的是,以上的一般描述和后文的细节描述仅是示例性和解释性的,并不能限制本公开。附图说明为了更清楚地说明本申请实施例的技术方案,下面将对本申请实施例中所需要使用的附图作简单地介绍,显而易见地,下面所介绍的附图仅仅是本申请的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。图1为本申请实施例提供的网约车的分配方法的应用场景示意图;图2为本申请一实施例提供的网约车的分配方法的流程示意图;图3为本申请一实施例提供的不同乘客的出发地位置的示意图;图4a为本申请一实施例提供的行车订单中初始接驾车辆与乘客之间的初始接驾关系的示意图;图4b为本申请一实施例提供的构建二分图的示意图;图4c为本申请一实施例提供的添加权重占比的二分图的示意图;图4d为本申请一实施例提供的最终接驾车辆关系的示意图;图4e为本申请一实施例提供的构建二分图的示意图;图5为本申请一实施例提供的确定应急车辆情况的示意图;图6为本申请一实施例提供的网约车的分配方法的流程示意图;图7a为本申请一实施例提供的终端设备展示接驾车辆虚拟信息的示意图;图7b为本申请一实施例提供的终端设备展示最终接驾车辆的示意图;图8是根据一示例性实施例示出的一种网约车的分配装置的框图;图9是根据一示例性实施例示出的一种网约车的分配装置的框图;图10是根据一示例性实施例示出的网约车的分配方法的电子设备示意图。具体实施方式为了使本领域普通人员更好地理解本申请的技术方案,下面将结合附图,对本申请实施例中的技术方案进行清楚、完整地描述。需要说明的是,本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象,而不必用于描述特定的顺序或先后次序。应所述理解这样使用的数据在适当情况下可以互换,以便这里描述的本申请的实施例能够以除了在这里图示或描述的那些以外的顺序实施。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反,它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。以下,对本申请实施例中的部分用语进行解释说明,以便于本领域技术人员理解。(1)本申请实施例中术语“多个”是指两个或两个以上,其它量词与之类似。(2)“和/或”,描述关联对象的关联关系,表示可以存在三种关系,例如,a和/或b,可以表示:单独存在a,同时存在a和b,单独存在b这三种情况。字符“/”一般表示前后关联对象是一种“或”的关系。(3)服务端,是为终端服务的,服务的内容诸如向终端提供资源,保存终端数据;服务端是与终端上安装的应用程序相对应的,与终端上的应用程序配合运行。(4)终端设备,既可以指软件类的app(application,应用程序),也可以指客户端。它具有可视的显示界面,能与用户进行交互;是与服务端相对应,为客户提供本地服务。针对软件类的应用程序,除了一些只在本地运行的应用程序之外,一般安装在普通的客户终端上,需要与服务端互相配合运行。因特网发展以后,较常用的应用程序包括了如收寄电子邮件时的电子邮件客户端,以及即时通讯的客户端等。对于这一类应用程序,需要网络中有相应的服务端和服务程序来提供相应的服务,如数据库服务,配置参数服务等,这样在客户终端和服务端,需要建立特定的通信连接,来保证应用程序的正常运行。在具体实践过程中,人们出行方式不仅局限在通过出租车出行,越来越多的人选择利用网络平台在线约车的方式出行。并且通过网络平台在线约车的方式,乘客可以更好安排出行时间、服务体验也较好,可以弥补现有出行方式中不能满足的出行需求。网约车需要网约车平台、车辆终端和乘客终端的协同操作。如何优化网约车的资源配置一直是改进的方向。为此,本申请提供了一种网约车的分配方法,首先在乘客的出发地之间的距离小于或等于距离阈值、派单时间差在一定阈值内,获取处于接驾状态的行车订单,然后针对每个行车订单中的出发地,分别确定各行车订单中的初始接驾车辆到出发地的接驾成本,最后基于各行车订单的整体接驾成本最低的约束条件,对各接驾成本进行处理,重新确定各行车订单中的最终接驾车辆。在介绍完本申请实施例的设计思想之后,下面对本申请实施例的技术方案能够适用的应用场景做一些简单介绍,需要说明的是,以下介绍的应用场景仅用于说明本申请实施例而非限定。在具体实施时,可以根据实际需要灵活地应用本申请实施例提供的技术方案。图1为根据本申请一个实施例的应用环境的示意图。如图1所示,该应用场景中例如可以包括存储系统10、服务器20以及终端(例如,图1中30_1与30_2或30_n)。终端可用来进行网络访问的任何合适的电子设备,包括但不限于计算机、笔记本电脑、智能手机、平板电脑、智能手表、智能手环或是其它类型的终端。存储系统10能够存储用户信息、用户状态、地理信息等网约车平台所需的资源。服务器20用于实现与终端的交互来完成网约车业务。如与用车用户的终端交互,实现用车用户下单、为司机派单规划路径进行导航等协助司机完成订单的业务等。实施时,每个乘客基于终端向网约车平台发起网约车请求,终端可进行定位获得每个乘客的出发地,亦或者基于每个乘客选择或手动输入的信息得到每个乘客的出发地,然后将每个乘客的出发地均携带在对应的网约车请求中发送给网约车平台(图1中以服务器20表示)。服务器20基于不同的出发地为每个乘客选择行车终点在以该出发地为基准的n公里内的车辆,然后筛选出一些车辆,将筛选出车辆的信息推送给对应的终端设备显示。并且服务器20在对每个乘客进行派单后,还可以根据指定时间段内车辆和乘客的信息,优化一定区域内的车辆分配,由此,可以提高网约车成功接驾乘客的效率,优化网约车资源的配置。在图1所示的应用场景中,终端之间(例如,30_1与30_2或30_n之间)也可以经由网络40彼此通信。网络40可以是广义上的用于信息传递的网络,可以包括一个或多个通信网络,诸如无线通信网络、因特网、私域网、局域网、城域网、广域网或是蜂窝数据网络等。本申请中的描述中仅就单个服务器或终端加以详述,但是本领域技术人员应当理解的是,示出的单个服务器20、终端和存储系统10旨在表示本申请的技术方案涉及终端、服务器以及存储系统的操作。对单个终端以及单个服务器和存储系统加以详述至少为了说明方便,而非暗示对终端和服务器的数量、类型或是位置等具有限制。应当注意,如果向图示环境中添加附加模块或从其中去除个别模块,不会改变本申请的示例实施例的底层概念。另外,虽然为了方便说明而在图1中示出了从存储系统10到服务器20的双向箭头,但本领域技术人员可以理解的是,上述数据的收发也是可以通过网络40实现的。服务器20可以是一台服务器、若干台服务器组成的服务器集群或云计算中心。服务器20可以是独立的物理服务器,也可以是多个物理服务器构成的服务器集群或者分布式系统,还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、cdn、以及大数据和人工智能平台等基础云计算服务的云服务器。当然,本申请实施例提供的方法并不限用于图1所示的应用场景中,还可以用于其它可能的应用场景,本申请实施例并不进行限制。对于图1所示的应用场景的各个设备所能实现的功能将在后续的方法实施例中一并进行描述,在此先不过多赘述。为进一步说明本申请实施例提供的技术方案,下面结合附图以及具体实施方式对此进行详细的说明。虽然本申请实施例提供了如下述实施例或附图所示的方法操作步骤,但基于常规或者无需创造性的劳动在所述方法中可以包括更多或者更少的操作步骤。在逻辑上不存在必要因果关系的步骤中,这些步骤的执行顺序不限于本申请实施例提供的执行顺序。下面结合图1所示的应用场景,对本申请实施例提供的技术方案进行说明。参考图2,本申请实施例提供一种网约车的分配方法,包括以下步骤:s201,获取满足预设条件的行车订单;预设条件包括:行车订单处于接驾状态、乘客的出发地之间的距离小于或等于距离阈值、派单时间差在一定阈值内。示例性地,如图3所示,示出了乘客1、乘客2、乘客3、乘客4、乘客5各自对应的出发地位置,假设乘客1、乘客3、乘客4、乘客5均存在对应的接驾车辆,并且乘客1的派单时间为8:00:00,乘客3的派单时间为8:00:01,乘客4的派单时间为8:00:05,乘客5的派单时间为8:30:09,乘客2不存在对应的接驾车辆,若派单时间差对应的阈值为3秒,则每间隔3秒划分出一个时间切片,该时间切片内派单成功的都属于派单时间差阈值内的行车订单,并且如图3所示,基于距离阈值确定的虚线所围成的封闭区域,位于该区域内的出发地之间的距离均小于或等于距离阈值,由图3可知,乘客4不在封闭区域内,虽然乘客5在封闭区域内,但是乘客5与其他乘客的派单时间均不在同一个时间切片内,又由于乘客2不存在对应的接驾车辆,乘客1与乘客3的派单时间在派单时间差阈值范围内,并且均在封闭区域内,因此符合预设条件的行车订单为乘客1、乘客3分别对应的行车订单。这里,虚线所围成封闭区域为预先设置好的,另外,还可以根据距离阈值将一个行车订单出发地的指定距离范围确定为上述虚线所围成的封闭区域,在此仅是举例说明基于距离阈值筛选出发地的订单的方法,并不限定基于距离阈值筛选出发地的订单的具体方法,可根据实际情况调整。或者,还可以通过获取出发地在指定地理区域内、且指定时间信息在同一时间切片内的行车订单,指定时间信息包括下单时间点和/或派单时间点,其中,指定地理区域根据距离阈值确定,时间切片根据派单时间差对应的阈值确定。例如,根据预先统计的历史交通流数据,划分出乘客下单较多或者有出行需求较多的地理区域,在该地理区域中按照距离阈值确定出至少一个指定地理区域。如上述示例所述,图3中虚线所围成的封闭区域可以是一个指定地理区域。并且,这里指定时间信息可以是早晚上下班出行高峰时间信息或者是周末、节假日等时间信息。s202,针对每个行车订单中的出发地,分别确定各行车订单中的初始接驾车辆到出发地的接驾成本。示例性地,假设存在三个行车订单,且三个行车订单如表1所示,针对行车订单1中的出发地1来说,分别确定行车订单1中的初始接驾车辆1、行车订单2中的初始接驾车辆2、行车订单3中的初始接驾车辆3到出发地1的接驾成本,如表2所示。表1行车订单初始接驾车辆乘客出发地行车订单1初始接驾车辆1乘客1出发地1行车订单2初始接驾车辆2乘客2出发地2行车订单3初始接驾车辆3乘客3出发地3表2出发地行车订单初始接驾车辆接驾成本出发地1行车订单1初始接驾车辆1接驾成本1出发地1行车订单2初始接驾车辆2接驾成本2出发地1行车订单3初始接驾车辆3接驾成本3本申请的一实施例中,若车辆可用于接驾乘客,则该车辆和该乘客之间存在潜在的接驾关系。为了提高重新分配车辆的效率,还可以对不可能使用的接驾关系进行过滤。如可实施为针对每个行车订单的出发地分别执行:将行车订单中的初始接驾车辆到出发地的接驾成本确定为第一成本;将其他行车订单中的初始接驾车辆到出发地的接驾成本确定为第二成本;筛选出小于第一成本的第二成本。示例性地,如上述示例所述,将行车订单1中的初始接驾车辆1到出发地1的接驾成本确定为第一成本。将行车订单2中的初始接驾车辆2到出发地1的接驾成本、以及行车订单3中的初始接驾车辆3到出发地1的接驾成本确定为第二成本。假设行车订单2中的初始接驾车辆2到出发地1的接驾成本大于第一成本,行车订单3中的初始接驾车辆3到出发地1的接驾成本小于第一成本,则筛选出小于第一成本的第二成本,也即得到行车订单3中的初始接驾车辆3到出发地1的接驾成本。通过筛选出小于第一成本的第二成本,可以减少对各接驾成本处理过程的计算量,过滤到不适用的接驾关系,进而可以更加准确高效的确定各行车订单中的最终接驾车辆。本申请实施例中,接驾成本可包括:接驾里程和/或接驾时长。接驾里程即初始接驾车辆从当前位置到乘客的出发地所需要驾驶的距离。接驾时长即初始接驾车辆从当前位置行驶至乘客的出发地所需要的时长。由于接驾成本包括的内容不同,整体接驾成本的确定方式不同。以下是整体接驾成本确定的多种不同方式:方式一、接驾成本为接驾里程,整体接驾成本为各行车订单的平均接驾里程或总接驾里程。方式二、接驾成本为接驾时长,整体接驾成本为各行车订单的平均接驾时长或总接驾时长。方式三、接驾成本包括接驾里程和接驾时长,整体接驾成本包括以下成本中的任一种:平均接驾里程和平均接驾时长的第一组合成本;平均接驾里程和总接驾时长的第二组合成本;平均接驾时长和总接驾里程的第三组合成本。总接驾时长和总接驾里程的第四组合成本。上述实施例中第一至第四组合成本的组合方式可以是对包含的接驾成本进行归一化后,然后加法或乘法的方式进行组合。例如,以整体接驾成本为平均接驾里程和平均接驾时长的第一组合成本为例,通过计算所有行程订单中的接驾里程的平均接驾里程、以及计算所有行程订单中的接驾时长的平均接驾时长之后,分别对平均接驾里程、平均接驾时长进行归一化,并将平均接驾里程归一化的结果与平均接驾时长归一化的结果相乘得到整体接驾成本。在此并不限定归一化的具体方法,可根据实际情况进行调整。本申请实施例中,接驾成本还可以包括:改变初始规划路线后的路线调整时间。示例性的,一种可能的方案:服务端可执行为:获取车辆当前位置和更新后的行驶路线;确定更新后的行驶路线上距离当前位置指定行驶时长内是否存在指定驾驶操作,该指定驾驶操作至少包括转弯、掉头、变道中的一种;若存在指定驾驶操作,则基于所述指定行驶时长确定路线调整时间,其中路线调整时间小于或等于该指定行驶时长;将携带指定驾驶操作、指定驾驶操作在更新后的行驶路线上的位置信息的提醒信息推送给终端设备显示。这里,终端设备既可以是加装在车辆中的车载终端,也可以是司机的智能终端,如智能手机、平板电脑等。另一种可能的方案中,可以采用指定距离来代替指定时长来确定路线调整时间,此种情况下服务端可执行为:获取车辆当前位置和更新后的行驶路线;确定更新后的行驶路线上距离当前位置指定距离内是否存在指定驾驶操作,该指定驾驶操作至少包括转弯、掉头、变道中的一种;若存在指定驾驶操作,则基于所述指定距离确定路线调整时间,其中路线调整时间小于或等于该指定距离所需的驾驶时长;将携带指定驾驶操作、指定驾驶操作在更新后的行驶路线上的位置信息的提醒信息推送给终端设备显示。如前文所述,这里的终端设备既可以是加装在车辆中的车载终端,也可以是司机的智能终端,如智能手机、平板电脑等。上述两种方案为分别利用指定行驶时长、指定距离确定路线调整时间,在此仅是举例说明路线调整时间的确定方法,并不限定路线调整时间的具体确定方法,实施时,可根据实际应用情况确定。终端设备在收到该提醒信息之后,解析出指定驾驶操作并解析出指定驾驶操作在更新后的行驶路线上的位置信息,然后可通过语音或音视频结合的方式对解析出的指定驾驶操作和位置信息进行输出,以此达到提醒司机注意到更换道路的目的,尽可能缓解临时更换乘客给司机操作带来的不便。通过设置不同的接驾成本确定方式,以及不同的整体接驾成本确定方式,可以满足不同需求的情况。例如,针对需要保证行车订单的接驾成功率的需求,可以将接驾成本定义为接驾时长,将整体接驾成本定义为平均接驾时长,通过保证整体接驾时长最短的约束条件,可以提高行车订单的接驾成功率。在此仅是举例说明,并不限定具体的需求对应具体的接驾成本或者整体接驾成本,可根据实际应用情况进行调整。在确定整体接驾成本之后,可以执行步骤s203,基于各行车订单的整体接驾成本最低的约束条件,对各接驾成本进行处理,重新确定各行车订单中的最终接驾车辆。一种可能的实施方式中,将每个行车订单中的初始接驾车辆组成的集合作为第一集合,将每个行车订单中的乘客组成的集合作为第二集合;基于第一集合中的车辆与第二集合中的乘客之间的初始接驾关系以及各接驾成本对应的接驾关系,构建二分图;利用二分图、以及为各对应关系关联的预设权重占比,重新确定各行车订单中的最终接驾车辆。示例性地,假设存在三个行车订单,且三个行车订单如上述表1所示,如图4a所示,将行车订单1中的初始接驾车辆1、行车订单2中的初始接驾车辆2、行车订单3中的初始接驾车辆3组成的集合作为第一集合,将行车订单1中的乘客1、行车订单2中的乘客2、行车订单3中的乘客3组成的集合作为第二集合。并且图4a中,连线表述存在接驾关系,如初始接驾车辆1与乘客1之间的连线、初始接驾车辆2与乘客2之间的连线、初始接驾车辆3与乘客3之间的连线为初始派单时车辆与乘客之间存在接驾关系。假设对各行车订单中的出发地对应的接驾成本进行筛选后,得到初始接驾车辆3到出发地1的接驾成本小于初始接驾车辆1到出发地1的接驾成本,初始接驾车辆2到出发地3的接驾成本小于初始接驾车辆3到出发地3的接驾成本,初始接驾车辆1到出发地2的接驾成本小于初始接驾车辆2到出发地2的接驾成本。那么经过筛选后各接驾成本对应的接驾关系为初始接驾车辆1与乘客2之间的连线、初始接驾车辆2与乘客3之间的连线、初始接驾车辆3与乘客1之间的连线。如图4b所示,展示了构建得到的二分图,通过对二分图中各接驾关系添加预设权重占比。如图4c所示,展示了对初始接驾车辆1与乘客1之间的对应关系添加权重x1,对初始接驾车辆1与乘客3之间的对应关系添加权重x2,对初始接驾车辆2与乘客2之间的对应关系添加权重x3,对初始接驾车辆2与乘客3之间的对应关系添加权重x4,对初始接驾车辆3与乘客1之间的对应关系添加权重x5,对初始接驾车辆3与乘客3之间的对应关系添加权重x6。示例性地,在将二分图中各对应关系添加预设权重占比后,可采用km算法(kuhn-munkres算法)输出各行车订单中的最终接驾车辆,如图4d所示,即初始接驾车辆1最终接驾乘客2,初始接驾车辆2最终接驾乘客3,初始接驾车辆3最终接驾乘客1。这里,km算法是用于寻找带权二分图最佳匹配的算法,主要包括以下步骤:(1)初始化预设权重占比(2)用匈牙利算法寻找最佳匹配关系(3)若未找到最佳匹配关系则调整预设权重占比(4)重复(2)(3)直到确定最终的匹配关系。在此仅是举例说明确定各行车订单中最终接驾车辆的一种方法,并不限定具体确定各行车订单中最终接驾车辆的方法,可根据实际应用情况进行调整。通过根据各行车订单中车辆与乘客之间的初始接驾关系、以及筛选后的车辆与乘客之间的接驾关系,构建二分图后,再利用权重占比可以更加准确的确定各行车订单中的最终接驾车辆。本申请的一实施例中,在利用二分图、以及预设权重占比,重新确定各行车订单中的最终接驾车辆之前,还可以确定二分图是否符合车辆置换条件,若不符合车辆置换条件,则调整车辆与乘客之间接驾关系的权重占比,车辆置换条件为各行车订单中的乘客都有对应的最终接驾车辆。示例性地,如图4e所示,假设对各行车订单中的出发地对应的接驾成本进行筛选后,得到初始接驾车辆3到出发地1的接驾成本小于第一成本。那么经过筛选后各接驾成本对应的接驾关系为初始接驾车辆3与乘客1之间的连线。这样可能会出现初始接驾车辆2对乘客2进行接驾,初始接驾车辆3对乘客1进行接驾,而初始接驾车辆1没有可以接驾的乘客,乘客3没有可以接驾的车辆,也即不符合各行车订单中的乘客都有对应的最终接驾车辆的车辆置换条件。因此需要将初始接驾车辆3与乘客1之间的连线关系的权重占比调整至无限小,使得各行车订单中的乘客都有对应的最终接驾车辆。通过车辆置换条件的判断、以及权重占比的调整,可以得到更加准确的各行车订单中乘客对应的最终接驾车辆。除了前文所述的可以重新分配车辆,优化局部区域局部时间内的资源配置节约接驾成本外,本申请实施例中还可以根据一些应急情况进行应急处理,以提高网约车资源的优化配置。如,本申请的一实施例中,若确定任一行车订单中的初始接驾车辆为应急车辆,则对应急车辆的乘客重新派车。这里,在提高网约车资源的优化配置时,并不限定车辆置换与车辆应急情况之间的执行顺序,既可以先进行应急换车,再进行车辆置换,也可以先进行车辆置换,再进行应急换车。其中,可根据以下任意一种情况确定初始接驾车辆为应急车辆:初始接驾车辆出现故障、初始接驾车辆出现事故、初始接驾车辆出现交通堵塞、初始接驾车辆的司机触发应急换车请求、初始接驾车辆的乘客触发急需用车请求。示例性地,如图5所示,确定应急车辆情况包括三种,第一种是初始接驾车辆的问题,包括初始接驾车辆出现故障、初始接驾车辆出现事故、初始接驾车辆出现交通堵塞;第二种是司机的问题,包括司机身体不适、司机临时有事;第三种是乘客的问题,包括乘客身体不适、乘客通勤时间紧急、天气变差。另外,若在重新确定各行车订单中的最终接驾车辆之前,确定任一行车订单中的初始接驾车辆为应急车辆,则对应急车辆的乘客重新派车,并将行车订单中的信息从二分图中剔除。示例性地,若在重新确定各行车订单中的最终接驾车辆之前,确定任一行车订单中的初始接驾车辆为应急车辆,则将该行车订单中初始接驾车辆的信息从二分图中剔除,该行车订单中初始接驾车辆对应的乘客是否继续参与此次车辆的重新分配,需要根据对该乘客重新派车的时间确定,并且确定后重新对其他行车订单进行车辆的重新分配。通过在乘客的出发地之间的距离小于或等于距离阈值、派单时间差在一定阈值内,获取处于接驾状态的行车订单,然后针对每个行车订单中的出发地,分别确定各行车订单中的初始接驾车辆到出发地的接驾成本,最后基于各行车订单的整体接驾成本最低的约束条件,对各接驾成本进行处理,重新确定各行车订单中的最终接驾车辆,进而可以提高网约车成功接驾乘客的效率。本申请的一实施例中,服务端在接收到终端设备发送的叫车请求后,基于叫车请求确定接驾车辆、以及接驾车辆对应的虚拟车辆信息,并将接驾车辆对应的虚拟车辆信息发送至终端设备进行展示,然后服务端还可以基于上述网约车的分配方法确定叫车请求的最终接驾车辆的车辆信息,并根据最终接驾车辆的车辆信息生成更新消息,将更新消息发送至终端设备进行展示。本申请的一实施例中,服务端在发送更新信息至终端设备之前,还需要确定预设时长和/或预设距离内未接收到终端设备发送的乘客急需用车请求,预设时长为乘客到达出发地所需的时长或者从乘客下单时间开始的指定时长,预设距离为接驾车辆与出发地之间的指定距离阈值。若预设时长和/或预设距离内接收到终端设备发送的乘客急需用车请求,则对乘客重新派车,并将重新派车结果发送至终端设备。本申请的一实施例中,服务端在发送更新信息至终端设备之前,若接收到司机端发送的应急换车通知,则对乘客重新派单,并将该应急换车通知发送至终端设备。这里,应急换车通知为基于以下触发条件中的至少一种条件触发的:司机触发的应急换车请求、车辆故障。上述实施例为服务端的网约车的分配方法,接下来从终端设备进行分析网约车的分配方法。如图6所示,包括以下步骤:s601,响应于服务端对叫车请求的派单结果,展示接驾车辆的虚拟车辆信息。s602,接收服务端发送的更新消息,更新虚拟车辆信息为最终接驾车辆的车辆信息。其中,最终接驾车辆的车辆信息为通过上述服务端网约车的分配方法中任一方法确定的。假设乘客通过终端设备进行叫车请求,在确定有车辆接单后,在终端设备展示接驾车辆的虚拟车辆信息,如图7a所示,假设接驾车辆的真实信息为:张师傅,车牌号苏a866666,那么在终端设备展示的接驾车辆的虚拟车辆信息为李师傅,车牌号苏a666666。这里,既可以在终端设备中将接驾车辆的真实信息转换为虚拟信息,也可以在服务端将接驾车辆的真实信息转换为虚拟信息。并且,在接收到服务端发送的更新消息后,如将车辆信息更新为王师傅,车牌号苏a766666,则如图7b所示,将虚拟信息更新为最终接驾车辆的车辆信息,也即更新为王师傅,车牌号苏a766666。通过对初始接驾车辆的车辆信息进行虚拟展示,并在接收到更新消息后,展示最终接驾车辆的车辆信息,可以使得用户不用知晓车辆的更换过程,只需等待接驾车辆即可,进而提高用户的体验。本申请的一实施例中,更新虚拟车辆信息为最终接驾车辆的车辆信息之前,还可以确定预设时长和/或预设距离内未接收到乘客的急需用车请求,预设时长为乘客到达出发地所需的时长,或者为从乘客下单时间开始的指定时长,预设距离为接驾车辆与出发地之间的指定距离阈值。示例性地,乘客通过终端设备进行叫车请求后,可能出现紧急情况,如:天气突然开始下雨等或者自己突然感到身体不适,则乘客可以触发急需用车请求。若接驾车辆与出发地之间的距离在指定距离阈值内,则接驾车辆可以快速对乘客进行接驾,那么乘客不需要触发急需用车请求。若预设时长内未接收到乘客的急需用车请求,则继续按照接收到的更新消息,展示最终接驾车辆的车辆信息。本申请的一实施例中,若预设时长和/或预设距离内接收到乘客的急需用车请求,则发送重新派车指令至服务端;并,基于重新派车结果更新接驾车辆的车辆信息。如上述示例描述,若乘客触发急需用车请求,则对乘客进行重新派车。这里,还可以根据乘客触发急需用车请求的具体原因确定对乘客重新派车的规则,例如,若乘客是因为自己通勤时间紧急,而触发的急需用车请求,则对乘客进行重新派车时,会适应性的提高车价。若乘客是因为突发身体不适,而触发的急需用车请求,则会将该乘客所在的出发地附近最短时间可以达到的车辆进行调配,并不做价格的变动。本申请的一实施例中,若接收到服务端发送的应急换车通知,则从应急换车通知中解析出新分配的车辆的车辆信息;展示新分配的车辆的车辆信息;其中,应急换车通知为基于以下触发条件中的至少一种条件触发的:司机触发的应急换车请求、车辆故障。并且还可以展示应急换车原因,以便于乘客可以了解换车的原因。图8是根据一示例性实施例示出的一种网约车的分配装置的框图,参照图8,该装置800包括:获取单元801、第一确定单元802、第二确定单元803。获取单元801,用于获取满足预设条件的行车订单;所述预设条件包括:行车订单处于接驾状态、乘客的出发地之间的距离小于或等于距离阈值、派单时间差在一定阈值内;第一确定单元802,用于针对每个所述行车订单中的所述出发地,分别确定各行车订单中的初始接驾车辆到所述出发地的接驾成本;第二确定单元803,用于基于各所述行车订单的整体接驾成本最低的约束条件,对各所述接驾成本进行处理,重新确定各所述行车订单中的最终接驾车辆。可选的,所述接驾成本包括以下中的至少一种:接驾里程、接驾时长、改变初始规划路线后的路线调整时间。可选的,所述第一确定单元802,还用于:针对每个行车订单的出发地分别执行:将所述行车订单中的初始接驾车辆到所述出发地的接驾成本确定为第一成本;将其他行车订单中的初始接驾车辆到所述出发地的接驾成本确定为第二成本;筛选出小于所述第一成本的所述第二成本。可选的,所述第二确定单元803,用于:将每个行车订单中的所述初始接驾车辆组成的集合作为第一集合,将每个行车订单中的乘客组成的集合作为第二集合;基于所述第一集合中的车辆与所述第二集合中的乘客之间的初始接驾关系以及各所述接驾成本对应的接驾关系,构建二分图;利用所述二分图、以及为各所述对应关系关联的预设权重占比,重新确定各所述行车订单中的最终接驾车辆。可选的,所述第二确定单元803,还用于:若确定所述二分图不符合车辆置换条件,则调整车辆与乘客之间不存在接驾关系的权重占比,所述车辆置换条件为各所述行车订单中的乘客都有对应的所述最终接驾车辆。可选的,所述装置还包括:获取出发地在指定地理区域内、且指定时间信息在同一时间切片内的行车订单,所述指定时间信息包括下单时间点和/或派单时间点,其中,指定地理区域根据所述距离阈值确定,时间切片根据所述派单时间差对应的阈值确定。可选的,所述装置还包括:若确定任一所述行车订单中的所述初始接驾车辆为应急车辆,则对所述应急车辆的乘客重新派车。可选的,根据以下任意一种情况确定所述初始接驾车辆为所述应急车辆:所述初始接驾车辆出现故障、所述初始接驾车辆出现事故、所述初始接驾车辆出现交通堵塞、所述初始接驾车辆的司机触发应急换车请求、所述初始接驾车辆的乘客触发急需用车请求。可选的,若所述接驾成本为所述接驾里程,所述整体接驾成本为各所述行车订单的平均接驾里程或总接驾里程;若所述接驾成本为所述接驾时长,所述整体接驾成本为各所述行车订单的平均接驾时长或总接驾时长;若所述接驾成本包括所述接驾里程和所述接驾时长,则所述整体接驾成本包括以下成本中的任一种:平均接驾里程和平均接驾时长的第一组合成本;平均接驾里程和总接驾时长的第二组合成本;平均接驾时长和总接驾里程的第三组合成本;总接驾时长和总接驾里程的第四组合成本。图9是根据一示例性实施例示出的一种网约车的分配装置的框图,参照图9,该装置900包括:展示单元901、更新单元902。展示单元901,用于响应于服务端对叫车请求的派单结果,展示接驾车辆的虚拟车辆信息;更新单元902,用于接收所述服务端发送的更新消息,更新所述虚拟车辆信息为最终接驾车辆的车辆信息,其中,所述最终接驾车辆的车辆信息为基于第一方面中任一所述方法确定的。可选的,所述更新单元902之前,所述装置还包括:确定预设时长和/或预设距离内未接收到乘客的急需用车请求,所述预设时长为乘客到达出发地所需的时长,或者为从乘客下单时间开始的指定时长,所述预设距离为所述接驾车辆与所述出发地之间的指定距离阈值。可选的,所述装置还包括:若所述预设时长和/或所述预设距离内接收到所述乘客的急需用车请求,则发送重新派车指令至服务端;并,基于重新派车结果更新接驾车辆的车辆信息。可选的,所述装置还包括:若接收到服务端发送的应急换车通知,则从所述应急换车通知中解析出新分配的车辆的车辆信息;展示所述新分配的车辆的车辆信息;其中,所述应急换车通知为基于以下触发条件中的至少一种条件触发的:司机触发的应急换车请求、车辆故障。在介绍了本申请示例性实施方式的网约车的分配方法和装置之后,接下来,介绍根据本申请的另一示例性实施方式的电子设备。所属
技术领域
的技术人员能够理解,本申请的各个方面可以实现为系统、方法或程序产品。因此,本申请的各个方面可以具体实现为以下形式,即:完全的硬件实施方式、完全的软件实施方式(包括固件、微代码等),或硬件和软件方面结合的实施方式,这里可以统称为“电路”、“模块”或“系统”。在一些可能的实施方式中,根据本申请的电子设备可以至少包括至少一个处理器、以及至少一个存储器。其中,存储器存储有程序代码,当程序代码被处理器执行时,使得处理器执行本说明书上述描述的根据本申请各种示例性实施方式的网约车的分配方法中的步骤。例如,处理器可以执行如网约车的分配方法中的步骤。下面参照图10来描述根据本申请的这种实施方式的电子设备130。图10显示的电子设备130仅仅是一个示例,不应对本申请实施例的功能和使用范围带来任何限制。如图10所示,电子设备130以通用电子设备的形式表现。电子设备130的组件可以包括但不限于:上述至少一个处理器131、上述至少一个存储器132、连接不同系统组件(包括存储器132和处理器131)的总线133。总线133表示几类总线结构中的一种或多种,包括存储器总线或者存储器控制器、外围总线、处理器或者使用多种总线结构中的任意总线结构的局域总线。存储器132可以包括易失性存储器形式的可读介质,例如随机存取存储器(ram)1321和/或高速缓存存储器1322,还可以进一步包括只读存储器(rom)1323。存储器132还可以包括具有一组(至少一个)程序模块1324的程序/实用工具1325,这样的程序模块1324包括但不限于:操作系统、一个或者多个应用程序、其它程序模块以及程序数据,这些示例中的每一个或某种组合中可能包括网络环境的实现。电子设备130也可以与一个或多个外部设备134(例如键盘、指向设备等)通信,还可与一个或者多个使得用户能与电子设备130交互的设备通信,和/或与使得该电子设备130能与一个或多个其它电子设备进行通信的任何设备(例如路由器、调制解调器等等)通信。这种通信可以通过输入/输出(i/o)接口135进行。并且,电子设备130还可以通过网络适配器136与一个或者多个网络(例如局域网(lan),广域网(wan)和/或公共网络,例如因特网)通信。如图所示,网络适配器136通过总线133与用于电子设备130的其它模块通信。应当理解,尽管图中未示出,可以结合电子设备130使用其它硬件和/或软件模块,包括但不限于:微代码、设备驱动器、冗余处理器、外部磁盘驱动阵列、raid系统、磁带驱动器以及数据备份存储系统等。在示例性实施例中,还提供了一种包括指令的计算机可读存储介质,例如包括指令的存储器132,上述指令可由处理器131执行以完成上述方法。可选地,计算机可读存储介质可以是rom、随机存取存储器(ram)、cd-rom、磁带、软盘和光数据存储设备等。在示例性实施例中,还提供一种计算机程序产品,包括计算机程序/指令,所述计算机程序/指令被处理器131执行时实现如本申请提供的网约车的分配方法的任一方法。在示例性实施例中,本申请提供的一种网约车的分配方法的各个方面还可以实现为一种程序产品的形式,其包括程序代码,当程序产品在计算机设备上运行时,程序代码用于使计算机设备执行本说明书上述描述的根据本申请各种示例性实施方式的一种网约车的分配方法中的步骤。程序产品可以采用一个或多个可读介质的任意组合。可读介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件,或者任意以上的组合。可读存储介质的更具体的例子(非穷举的列表)包括:具有一个或多个导线的电连接、便携式盘、硬盘、随机存取存储器(ram)、只读存储器(rom)、可擦式可编程只读存储器(eprom或闪存)、光纤、便携式紧凑盘只读存储器(cd-rom)、光存储器件、磁存储器件、或者上述的任意合适的组合。本申请的实施方式的用于图像缩放的程序产品可以采用便携式紧凑盘只读存储器(cd-rom)并包括程序代码,并可以在电子设备上运行。然而,本申请的程序产品不限于此,在本文件中,可读存储介质可以是任何包含或存储程序的有形介质,该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号,其中承载了可读程序代码。这种传播的数据信号可以采用多种形式,包括——但不限于——电磁信号、光信号或上述的任意合适的组合。可读信号介质还可以是可读存储介质以外的任何可读介质,该可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。可读介质上包含的程序代码可以用任何适当的介质传输,包括——但不限于——无线、有线、光缆、rf等等,或者上述的任意合适的组合。可以以一种或多种程序设计语言的任意组合来编写用于执行本申请操作的程序代码,程序设计语言包括面向对象的程序设计语言—诸如java、c++等,还包括常规的过程式程序设计语言—诸如“c”语言或类似的程序设计语言。程序代码可以完全地在用户电子设备上执行、部分地在用户设备上执行、作为一个独立的软件包执行、部分在用户电子设备上部分在远程电子设备上执行、或者完全在远程电子设备或服务端上执行。在涉及远程电子设备的情形中,远程电子设备可以通过任意种类的网络——包括局域网(lan)或广域网(wan)—连接到用户电子设备,或者,可以连接到外部电子设备(例如利用因特网服务提供商来通过因特网连接)。应当注意,尽管在上文详细描述中提及了装置的若干单元或子单元,但是这种划分仅仅是示例性的并非强制性的。实际上,根据本申请的实施方式,上文描述的两个或更多单元的特征和功能可以在一个单元中具体化。反之,上文描述的一个单元的特征和功能可以进一步划分为由多个单元来具体化。此外,尽管在附图中以特定顺序描述了本申请方法的操作,但是,这并非要求或者暗示必须按照该特定顺序来执行这些操作,或是必须执行全部所示的操作才能实现期望的结果。附加地或备选地,可以省略某些步骤,将多个步骤合并为一个步骤执行,和/或将一个步骤分解为多个步骤执行。本领域内的技术人员应明白,本申请的实施例可提供为方法、系统、或计算机程序产品。因此,本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且,本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程图像缩放设备的处理器以产生一个机器,使得通过计算机或其他可编程图像缩放设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。这些计算机程序指令也可存储在能引导计算机或其他可编程图像缩放设备以特定方式工作的计算机可读存储器中,使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品,该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。这些计算机程序指令也可装载到计算机或其他可编程图像缩放设备上,使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理,从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。尽管已描述了本申请的优选实施例,但本领域内的技术人员一旦得知了基本创造性概念,则可对这些实施例做出另外的变更和修改。所以,所附权利要求意欲解释为包括优选实施例以及落入本申请范围的所有变更和修改。显然,本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样,倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内,则本申请也意图包含这些改动和变型在内。当前第1页12
当前第1页1 2 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1