网约车和出租车的综合调度系统及方法与流程

文档序号:14716211发布日期:2018-06-16 01:24阅读:958来源:国知局
网约车和出租车的综合调度系统及方法与流程

本发明涉及车辆调度领域,具体涉及一种网约车和出租车的综合调度系统及方法。



背景技术:

随着移动互联网、智能通讯终端的兴起,网约车模式得到了出行者的广泛认可和青睐。网约车模式通过移动通讯端即可完成乘车下单、司机接单的过程,缩短了乘客叫车的时间,给人们的出行带来了极大的便利。与此同时,网约车模式也对传统出租车行业造成了很大的冲击,出租车司机收入不断减少、司机不断流失。2016年7月28日,交通部颁布了《网络预约出租汽车经营服务管理暂行办法》,随后各地陆续出台了《网约车管理执行细则》。这些管理办法的实施,在一定程度上规范了网约车行业的运行,减少了不规范竞争的现象。

网约车模式的发展正在逐步稳定发展,网约车和出租车长期共存将是未来发展的主要趋势。但目前网约车和出租车是分开进行管理的,有着各自不同的管理系统。颁布的网约车管理办法虽然要求网约车公开部分运营数据,但并没有将乘客下单、司机接单的过程纳入到统一的管理范围,网约车和出租车之间的运行还基本上处于隔离状态。如何将网约车和出租车纳入到统一的管理范围,协调出租车和网约车之间的关系,使二者有序竞争、互为补充、共同发展,是目前亟需解决的问题。



技术实现要素:

为了解决上述问题,即为了解决网约车和出租车调度系统相互隔离,不能统一调度的问题,本发明一方面,提出了一种网约车和出租车的综合调度系统,所述系统包括中心平台系统、车辆终端设备、用户终端设备,所述车辆终端设备包括第一终端设备、第二终端设备。

所述中心平台系统,用于接收车辆终端设备发送的车辆位置信息和车辆运营状态信息、以及用户终端设备发送的用车请求信息,依据所述车辆位置信息、车辆运营状态信息、用车请求信息生成并发送用车订单。

所述车辆终端设备,用于采集并发送车辆位置信息和车辆运营状态信息,并接收所述中心平台系统发送的用车订单;其中,第一终端设备与出租车计价器进行通信连接,通过所述出租车计价器获取所述车辆运营状态信息;第二终端可以通过人机交互端口更新车辆运营状态。

所述用户终端设备用于发送用车请求信息,以及接收所述中心平台系统发送的用车订单。

所述用车订单包括第一类用车订单、第二类用车订单;所述第一类用车订单为指派订单,直接由所述中心平台系统生成并发送;所述第二类用车订单为意向订单,需要经车辆终端设备确认接单后确定最终的用车订单。

优选地,所述用车请求信息包括出发位置、出行目的地、联系方式、和/或预约时间。

优选地,所述第一类用车订单、所述第二类用车订单的判断方法为:

用车请求信息输入方式为电话语音输入时,用车订单为第一类用车订单;用车请求信息输入方式为用户终端设备约车软件输入时,用车订单为第二类用车订单。

优选地,所述运营状态信息包括司机状态、载客状态。

优选地,所述运营状态信息还包括车辆牌号、和/或预设的车辆参数信息。

优选地,所述第一类用车订单在出租车计价器计价结束时结束订单。

优选地,所述第一终端设备为出租车车载终端设备,该设备设置有用于获取车辆位置信息的定位模块;所述第一终端设备与所述中心平台系统无线通信连接,用于上传车辆位置信息、以及从出租车计价器获取所述车辆运营状态信息,并获取用车订单。

优选地,所述第二终端设备为网约车终端设备,该设备设置有用于获取车辆位置信息的定位模块、用于进行运营状态管理的运营状态管理模块;所述第二终端设备与所述中心平台系统无线通信连接,用于上传车辆位置信息、以及车辆运营状态信息,并获取用车订单。

本发明的另一方面,还提供了一种网约车和出租车的综合调度方法,该方法包括:

中心平台系统实时获取车辆终端设备发送的车辆位置信息和车辆运营状态信息,并接收用户终端设备发送用车请求信息。

依据用车请求信息的输入方式确定用车订单的类型,并进一步依据所述车辆位置信息、车辆运营状态信息、用车请求信息生成用车订单。

其中,所述用车订单包括第一类用车订单、第二类用车订单;所述第一类用车订单为指派订单,直接由所述中心平台系统生成并发送;所述第二类用车订单为意向订单,需要经车辆终端设备确认接单后确定最终的用车订单。

所述用车订单的类型的分类方法为:用车请求信息输入方式为电话语音输入时为第一类用车订单;用车请求信息输入方式为用户终端设备约车软件输入时为第二类用车订单。

进一步地,第一类用车订单主要面对的用户类型包括老人、儿童、孕妇等需要特殊照顾的人群。

进一步地,第二类用车订单主要面对普通用户,该方式运用灵活,是普遍采用的模式。

优选地,当用车订单为第一类用车订单时,所述“依据所述车辆位置信息、车辆运营状态信息、用车请求信息生成用车订单”的方法为:

步骤S11,统计以所述出发位置为圆心,以距离阈值K1为半径的区域内可用车辆D1的数量;如果D1大于0则执行步骤S14,否则执行步骤S12;

步骤S12,按照预设的扩大倍数对K1进行更新,若更新后的K1小于预设的距离上限K2则执行步骤S11,否则执行步骤S13;

步骤S13:如果D1的数量为0则判断累计等待时间是否大于预设的等待时间上限T2,若大于则依据预设的应急策略生成用车订单,否则延时等待时间T1后将K1进行初始化后执行步骤S11;如果D1的数量大于0则执行步骤S14;

步骤S14:判断D1中是否存在空驶时间超过空驶时间阈值K3的车辆,如果不存在则执行步骤S15,如果存在则选择空驶时间最长的车辆生成用车订单;

步骤S15:根据D1中各车辆的空驶时间F2和司机星级F4计算各车辆的派单优先级指数,并选择派单优先级指数最高的车辆生成用车订单。

优选地,所述“根据D1中各辆车的空驶时间F2和司机星级F4计算各车辆的派单优先级指数”的具体方法为:

首先对F2和F4分别通过如下公式进行归一化处理得到F2*和F4*,

其中max和min分别是待选择因素的最大值和最小值,x当前状态值,X*是归一化后的值。

然后利用如下公式计算每个司机的派单优先级指数F,

F=F2*+F4*

选择派单优先级指数F值最大的司机作为选择结果。

优选地,待选择因素是中心平台系统调度方案的重要因素,可根据系统实施地区的交通环境适时调整,可以为司机距离乘客的距离F1、司机空驶时间F2、司机接单率F3、司机星级F4,且可类比扩展其它考虑因素。

优选地,司机距离乘客距离F1计算方法为:

司机与乘客最短路线距离

优选地,司机空驶时间F2计算方法:

司机空驶时间F2等于司机距离上次订单结束时的时间差,且F2最大不超过最大阈值时间T4

优选地,司机接单率F3计算方法:

接单率F3=司机接单成功次数/司机收到订单信息次数

优选地,司机星级F4计算方法:

司机星级F4=乘客评价星级的总和/乘客评价次数

优选地,网约车和出租车司机的星级F4的原始值为一固定值,且能够动态调整,订单结束后乘客对司机进行评价,司机星级进行更新,更新算法如下:

新的星级=乘客评价星级的总和/乘客评价次数

优选地,当用车订单为第二类用车订单时,所述“依据所述车辆位置信息、车辆运营状态信息、用车请求信息生成用车订单”的方法为:

步骤S21:统计以所述出发位置为圆心,以距离阈值K1′为半径的区域内可用车辆D1′的数量;如果D1′小于一次派单数量P则执行步骤22,否则执行步骤S25;

步骤S22:按照预设的扩大倍数对K1′进行更新,若更新后的K1′小于预设的距离上限K2′则执行步骤S21,否则执行步骤S23;

步骤S23:判断累计等待时间是否大于预设的等待时间上限T2′,若大于执行步骤S24,否则延时等待时间T1′后将K1′进行初始化后执行步骤S21;

步骤S24:判断D1′中的数量,若为0则依据预设的应急策略生成用车订单,否则执行步骤S25;

步骤S25:根据D1′中各车辆的空驶时间F2、接单率F3和司机星级F4计算车辆派单优先级指数,若D1′中超过空驶时间阈值K3′的车辆数量小于P则执行步骤S27,否则执行S26;

步骤S26:选择空驶时间最长的前P个车辆,执行步骤S27;

步骤S27:中心平台系统向所选择的车辆发送抢单信息,司机在等待时间T3′时间范围内进行抢单;

步骤S28:获取司机在预设时间T3′内抢单信息,如果有司机抢单,选择派单优先级指数最高的车辆生成用车订单,否则执行步骤S21。

优选地,所述“根据D1′中各司机的空驶时间F2、接单率F3和司机星级F4计算车辆派单优先级指数”,具体方法为:

首先对F2、F3、F4分别通过如下公式进行归一化处理得到F2*、F3*和F4*,

其中max和min分别是待选择因素的最大值和最小值,x当前状态值,X*是归一化后的值。

然后通过如下公式计算每个车辆派单优先级指数F,

F=F2*+F3*+F4*

优选地,司机距离乘客距离F1计算方法为:

司机与乘客最短路线距离

优选地,司机空驶时间F2计算方法:

司机空驶时间F2等于司机距离上次订单结束时的时间差,且F2最大不超过最大阈值时间T4

优选地,司机接单率F3计算方法:

接单率F3=司机接单成功次数/司机收到订单信息次数

优选地,司机星级F4计算方法:

司机星级F4=乘客评价星级的总和/乘客评价次数

优选地,网约车和出租车司机的星级F4的原始值为一固定值,且能够动态调整,订单结束后乘客对司机进行评价,司机星级进行更新,更新算法如下:

新的星级=乘客评价星级的总和/乘客评价次数

本发明通过中心平台系统、车辆终端设备和用户终端设备能够将网约车和出租车纳入统一管理框架之下,通过上述网约车和出租车综合调度方法可以实现网约车和出租车的公平竞争、相互补充、共同发展,并且该方法不影响现有网约车和出租车的工作流程,方案实施过程非常方便。同时,第一终端设备与出租车计价器相连接,获取出租车实时运营状态,可以更直接、有效的利用网络化手段对出租车进行调配,能够与现有出租车管理系统的良好配合。

附图说明

图1是本发明提出的一种出租车和网约车的综合调度系统示意图。

图2是综合调度方法中生成指定订单的流程示意图。

图3是综合调度方法中生成普通订单的流程示意图。

具体实施方式

下面结合本发明实施例中的附图,对发明实施例中的技术方案进行清楚、完整地描述,显然,所述的实施例仅仅是本发明一部分实施例,而不是全部实施例。基于本发明的实施例,本领域普通技术人员在没有创造性劳动前提下获得的所有其它实施例,都属于本发明保护范围。

为了便于对本发明技术方案进行清晰描述,需要对本发明技术方案涉及的出租车和网约车进行定义区分,出租车为包含计价器等专业出租车计价设备的车辆,网约车为网络预约的不含计价器等专业设备的车辆。

本发明的目的是将网约车和出租车纳入统一管理框架之下。图1是本发明的一种网约车和出租车的综合调度系统示意图,其中的车辆包括出租车和网约车两类,出租车上装载有车载设备,网约车上的终端设备可以为装载有司机端APP的设备;乘客可以通过电话召车或乘客端APP召车两种方式预约车辆;车辆和乘客通过中心平台系统进行关联,形成订单和用车关联。由于网约车不允许以巡游方式运营,路边召车方式不在本发明的考虑范围之内。

为了对本发明的网约车和出租车的综合调度系统进行更清晰地展示,结合图1中的示意图,本发明的网约车和出租车的综合调度系统的主要部分可以包括:中心平台系统、车辆终端设备、用户终端设备,其中,车辆终端设备可以进一步分为第一终端设备、第二终端设备。在实际应用中,第一终端设备可以为出租车上装载的车载设备,第二终端设备可以为网约车上使用的装载有司机端APP的设备,用户终端设备可以为电话或者装载有乘客端APP的终端设备。

中心平台系统,用于接收车辆终端设备发送的车辆位置信息和车辆运营状态信息、以及用户终端设备发送的用车请求信息,依据所述车辆位置信息、车辆运营状态信息、用车请求信息生成并发送用车订单。本实施例中“依据所述车辆位置信息、车辆运营状态信息、用车请求信息生成并发送用车订单”可以采用下文描述的“一种网约车和出租车的综合调度方法”,也可以采用其他方式来进行乘客与车辆的关联匹配生成订单。

本实施例中的用车请求信息包括出发位置、出行目的地、联系方式、还可以包括出发时间、乘车人数等信息。

车辆终端设备,用于采集并发送车辆位置信息和车辆运营状态信息,并接收所述中心平台系统发送的用车订单。

第一终端设备与出租车计价器进行通信连接,通过所述出租车计价器获取所述车辆运营状态信息,可以实时获取出租车的空车、载客状态,并在出租车计价器计价结束时基于计价器信息来实现本系统中的结束订单操作。同时第一终端设备中设置定位模块,以实现车辆的位置定位。第一终端设备与所述中心平台系统无线通信连接,可以上传车辆位置信息、以及从出租车计价器获取所述车辆运营状态信息,并获取用车订单;这样能够完美的实现本发明的综合调度系统与现有出租车调度系统的完美结合。

第二终端可以通过人机交互端口更新车辆运营状态,具体的第二终端设备可以为网约车司机移动通讯端,该设备设置有用于获取车辆位置信息的定位模块、用于进行运营状态管理的运营状态管理模块;所述第二终端设备与所述中心平台系统无线通信连接,用于上传车辆位置信息、以及车辆运营状态信息,并获取用车订单。运营状态管理模块在实际应用中用于通过人工输入的方式来录入车辆运营状态。

本实施例中的车辆运营状态信息包括司机状态、载客状态,还可以包括车辆牌号、和/或预设的车辆参数信息。司机状态包括接受网络订单状态、不接受网络订单状态,载客状态包括空闲、载客两种状态,车辆参数信息包括车辆品牌等预设调取的车辆信息。

用户终端设备,用于发送用车请求信息,以及接收所述中心平台系统发送的用车订单;所述用车请求信息可以包括乘客位置信息、出行目的地、联系方式、人数、和/或乘客预约时间信息。用车订单包括第一类用车订单、第二类用车订单;所述第一类用车订单为指派订单,直接由所述中心平台系统生成并发送;所述第二类用车订单为意向订单,需要经车辆终端设备确认接单后确定最终的用车订单。

第一类用车订单、第二类用车订单可以通过以下方法进行判断和区分:

当用车请求信息输入方式为电话语音输入时,用车订单为指派订单,直接由所述中心平台系统生成并发送;当用车请求信息输入方式为用户终端设备约车软件输入时,用车订单为意向订单,需要经车辆终端设备确认接单后确定最终的用车订单。

本发明的网约车和出租车的综合调度系统,可以通过人工开启网约调度功能的方式,灵活的可以实现网约车和出租车的网约调度状态、非网约调度状态的灵活切换,网约调度状态可以接受本发明综合系统的调度,非网约调度状态可以进行车辆的正常使用。对于出租车,还可以在网约状态下,没有用车订单下发的情况下,可以通过巡游的方式进行乘客的寻找,并在乘客上车开始计时后向中心平台系统上传载客状态,这样就可以实现出租车巡游方式和网约方式的完美融合。

本发明还提供了一种网约车和出租车的综合调度方法,该方法包括:

步骤1,中心平台系统实时获取车辆终端设备发送的车辆位置信息和车辆运营状态信息,并接收用户终端设备发送用车请求信息;

步骤2,依据用车请求信息的输入方式确定用车订单的类型,并进一步依据所述车辆位置信息、车辆运营状态信息、用车请求信息生成用车订单;用车订单包括第一类用车订单、第二类用车订单。

本实施例中用车订单的类型的分类方法为:用车请求信息输入方式为电话语音输入时为第一类用车订单,用车请求信息输入方式为用户终端设备约车软件输入时为第二类用车订单。

附图2给出了综合调度方法中生成指定订单的流程示意图,如图2所示,当用车订单为第一类用车订单时,“依据车辆位置信息、车辆运营状态信息、用车请求信息生成用车订单”的方法:

步骤S11,统计以所述出发位置为圆心,以距离阈值K1为半径的区域内可用车辆D1的数量;如果D1大于0则执行步骤S14,否则执行步骤S12;

步骤S12,按照预设的扩大倍数对K1进行更新,若更新后的K1小于预设的距离上限K2则执行步骤S11,否则执行步骤S13;

步骤S13:如果D1的数量为0则判断累计等待时间是否大于预设的等待时间上限T2,若大于则依据预设的应急策略生成用车订单,否则延时等待时间T1后将K1进行初始化后执行步骤S11;如果D1的数量大于0则执行步骤S14;

步骤S14:判断D1中是否存在空驶时间超过空驶时间阈值K3的车辆,如果不存在则执行步骤S15,如果存在则选择空驶时间最长的车辆生成用车订单;

步骤S15:根据D1中车辆的空驶时间F2和司机星级F4计算各车辆的派单优先级指数,并选择派单优先级指数最高的车辆生成用车订单;

本实施例的步骤S15中,所述“根据D1中车辆的空驶时间F2和司机星级F4计算各车辆的派单优先级指数”的具体方法为:

首先对F2和F4分别通过公式(1)进行归一化处理得到F2*和F4*,

其中max和min分别是待选择因素的最大值和最小值,x当前状态值,X*是归一化后的值。

然后利用公式(2)计算每个司机的优先级指数F,

F=F2*+F4* (2)

例如,D1的数量为5,对应的空驶时间分别为F2-1、F2-2、F2-3、F2-4、F2-5,对应的空驶时间分别为1小时、1.5小时、1.2小时、2小时、3小时,则此时公式(1)中的min取值为1小时、max取值为3小时,对F2-2归一化的公式为:

例如,D1的数量为5,对应的司机星级分别对应F4-1、F4-2、F4-3、F4-4、F4-5,对应的司机星级分别为1星级、3星级、4星级、4星级、5星级,则此公式(1)中的min取值为1星级、max取值为5星级,对F4-2归一化的公式为:

本实施例中的归一出处理的公式还可以采用其他归一化方法,可以达到同样的技术效果,由于归一化方法较为成熟,此处不再赘述。

待选择因素是中心平台系统调度方案的重要因素,可根据系统实施地区的交通环境适时调整,可以为司机距离乘客的距离F1、司机空驶时间F2、司机接单率F3、司机星级F4,且可类比扩展其它考虑因素。

司机距离乘客距离F1计算方法可以为:

司机距离乘客距离F1=司机与乘客最短路线距离

司机空驶时间F2计算方法可以为:

司机空驶时间F2等于司机距离上次订单结束时的时间差,且F2最大不超过最大阈值时间T4

司机接单率F3计算方法可以为:

接单率F3=司机接单成功次数/司机收到订单信息次数

司机星级F4计算方法可以为:

司机星级F4=乘客评价星级的总和/乘客评价次数

网约车和出租车司机的星级F4的原始值为一固定值,且能够动态调整,订单结束后乘客对司机进行评价,司机星级进行更新,更新算法如下:

新的星级=乘客评价星级的总和/乘客评价次数

本实施例中K1预设为5公里,步骤S12中预设的扩大倍数为1.2,K2预设为10公里,T1预设为30秒,T2预设为5分钟,K3预设为2小时。在实际使用中,上述参数可以根据具体情况进行调整。

步骤S11,统计以出发位置为圆心,以5公里为半径的区域内可用车辆D1的数量;如果D1大于0则执行步骤S14,否则执行步骤S12;步骤S12,对K1扩大1.2倍进行更新,若更新后的K1小于10公里则执行步骤S11,否则执行步骤S13;

步骤S13:如果D1的数量为0则判断累计等待时间是否大于5分钟,若大于则依据预设的应急策略生成用车订单,否则延时30秒后将K1进行初始化后执行步骤S11;如果D1的数量大于0则执行步骤S14;

步骤S14:判断D1中是否存在空驶时间超过2小时的车辆,如果不存在则执行步骤S15,如果存在则选择空驶时间最长的车辆生成用车订单;

步骤S15:根据D1中车辆的空驶时间F2和司机星级F4对司机进行派单优先级指数,并选择派单优先级指数最高的车辆生成用车订单。

接合附图3,描述当用车订单为第二类用车订单时,“依据所述车辆位置信息、车辆运营状态信息、用车请求信息生成用车订单”的方法为:

步骤S21:统计以所述出发位置为圆心,以第一距离阈值K1′为半径的区域内可用车辆D1′的数量;如果D1′小于一次派单数量P则执行步骤S22,否则执行步骤S25;

步骤S22:按照预设的扩大倍数对K1′进行更新,若更新后的K1′小于预设的距离上限K2′则执行步骤S21,否则执行步骤S23;

步骤S23:判断累计等待时间是否大于预设的等待时间上限T2′,若大于执行步骤S24,否则延时第一等待时间T1′后将K1′进行初始化后执行步骤S21;

步骤S24:判断D1′中的数量,若为0则依据预设的应急策略生成用车订单,否则执行步骤S25;

步骤S25:根据D1′中各车辆的空驶时间F2、接单率F3、和司机星级F4计算车辆派单优先级指数,若D1′中超过空驶时间阈值K3′的车辆小于P则执行步骤S27,否则执行S26;

步骤S26:选择空驶时间最长的前P个车辆,执行步骤S27;

步骤S27:中心平台向所选择的车辆发送订单信息,司机在第二等待时间T3′时间范围内进行抢单;

步骤S28:获取司机在预设时间T3′内的抢单信息,如果有司机抢单,选择派单优先级指数最高的车辆生成用车订单,否则执行步骤S21。

本实施例的步骤S25中,所述“根据D1′中各司机的空驶时间F2、接单率F3、和司机星级F4计算车辆派单优先级指数”的具体方法为:

首先对F2、F3、F4分别通过公式(1)进行归一化处理得到F2*、F3*、F4*,

然后利用公式(3)计算每个车辆的派单优先级指数F,

F=F2*+F3*+F4* (3)

例如,如果计算得到F2*值为0.25,F3*值为0.1,F4*值为0.5,则车辆的派单优先级指数为:F=0.25+0.1+0.5=0.85。

归一化处理的过程中的待选择因素可根据实际应用进行调整,可以为司机距离乘客的距离F1、司机空驶时间F2、接单率F3、司机星级F4,且可类比扩展其它考虑因素。

本实施例中K1′预设为3公里,步骤S12中预设的扩大倍数为1.5,K2′预设为8公里,T1′预设为10秒,T2′预设为3分钟,T3′预设为30秒,K3′预设为2小时,预设一次派单数量为3。在实际使用中,上述参数可以根据具体情况进行调整。

步骤S21:统计以所述出发位置为圆心,以3公里为半径的区域内可用车辆D1′的数量;如果D1′小于3则执行步骤S22,否则执行步骤S25;

步骤S22:将K1′扩大1.5倍进行更新,若更新后的K1′小于8公里则执行步骤S21,否则执行步骤S23;

步骤S23:判断累计等待时间是否大于3分钟,若大于执行步骤S24,否则延时10秒后将K1′进行初始化后执行步骤S21;

步骤S24:判断D1′中的数量,若为0则依据预设的应急策略生成用车订单,否则执行步骤S25;

步骤S25:根据D1′中各车辆的空驶时间F2、接单率F3、和司机星级F4计算车辆派单优先级指数,若D1′中超过2小时的车辆小于3则执行步骤S27,否则执行S26;

步骤S26:选择空驶时间最长的前3个车辆,执行步骤S27;

步骤S27:中心平台向所选择的车辆发送订单信息,司机在30秒内进行抢单;

步骤S28:获取司机在30秒内的抢单信息,如果有司机抢单,选择派单优先级指数最高的车辆生成用车订单,否则执行步骤S21。

结合本文中所公开的实施例描述的方法或算法的步骤可以用硬件、处理器执行的软件模块,或者二者的结合来实施。软件模块可以置于随机存储器(RAM)、内存、只读存储器(ROM)、电可编程ROM、电可擦除可编程ROM、寄存器、硬盘、可移动磁盘、CD-ROM、或技术领域内所公知的任意其它形式的存储介质中。

本领域技术人员应该能够意识到,结合本文中所公开的实施例描述的各示例的系统及方法步骤,能够以电子硬件、计算机软件或者二者的结合来实现,为了清楚地说明电子硬件和软件的可互换性,在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以电子硬件还是软件方式来执行,取决于技术方案的特定应用和设计约束条件。本领域技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能,但是这种实现不应认为超出本发明的范围。

术语“第一”、“第二”等是用于区别类似的对象,而不是用于描述或表示特定的顺序或先后次序。

术语“包括”或者任何其它类似用语旨在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、物品或者设备/装置不仅包括那些要素,而且还包括没有明确列出的其它要素,或者还包括这些过程、方法、物品或者设备/装置所固有的要素。

至此,已经结合附图所示的优选实施方式描述了本发明的技术方案,但是,本领域技术人员容易理解的是,本发明的保护范围显然不局限于这些具体实施方式。在不偏离本发明的原理的前提下,本领域技术人员可以对相关技术特征作出等同的更改或替换,这些更改或替换之后的技术方案都将落入本发明的保护范围之内。

当前第1页1 2 3 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1