本申请涉及互联网领域,尤其是涉及一种乘车信息共享方法及系统。
背景技术:
随着移动互联网的飞速发展,通过移动终端叫车/打车,已经应用得相当普遍。例如,乘车用户可在移动终端的“快的”APP上输入出发地和目的地,移动终端通过服务器向发出广播,当出租车驾驶员通过相应的APP抢单成功后,服务器会向乘车用户的移动终端反馈其租车信息,例如车牌,驾驶员姓名等,以在APP上显示。如此,乘车用户即可根据该租车信息在出发地等待已呼叫到的出租车。
然而,目前的叫车/打车应用却无任何渠道可管控乘车用户的行车过程,即便乘车用户在行车途中发生意外,也难以获得快速有效的急救,乘车安全得不到保障。
技术实现要素:
本申请的目的在于提供一种乘车信息共享方法及系统。
为实现上述申请目的之一,本申请一实施方式提供了一种乘车信息共享方法,所述方法包括:
接收出发地位置信息和目的地位置信息并发起招车请求;
接收招车成功信息,并获取对应车辆的基础信息,所述基础信息包括车牌号和/或司机身份信息;
接收出发指令,并至少将所述基础信息、出发地位置信息、目的地位置信息发送给指定联系人对应的第三方终端。
作为本申请一实施方式的进一步改进,所述方法还包括:
根据所述出发地位置信息和所述目的地位置信息计算预计行车时间,并在接收到出发指令时开始计时;
若在预计行车时间+预设误差时间内未接收到到达指令,则向所述第三方终端发出警告信息。
作为本申请一实施方式的进一步改进,所述方法还包括:
根据所述出发地位置信息和所述目的地位置信息计算预计行车路线及相应的预计行车路程;
计算当前坐标至目的地的剩余行车路程,若所述剩余行车路程大于或等于预计行车路程与预设误差路程之和,则向所述第三方终端发出警告信息。
作为本申请一实施方式的进一步改进,所述方法还包括:将实时坐标信息发送给指定联系人对应的第三方终端。
为实现上述申请目的之一,本申请另一实施方式提供了一种乘车信息共享方法,所述方法包括:
招车终端接收出发地位置信息和目的地位置信息并发起招车请求;
招车终端接收招车成功信息,并获取对应车辆的基础信息,所述基础信息包括车牌号和/或司机身份信息;
招车终端接收出发指令,并至少将所述基础信息和出发指令发送给指定联系人对应的第三方终端。
作为本申请另一实施方式的进一步改进,在接收到出发指令后,所述招车终端还将计算的预计行车时间发送给指定联系人对应的第三方终端,所述方法还包括:
第三方终端根据所述出发指令开始计时;
若在预计行车时间+预设误差时间内未收到招车终端发出的到达信息,则所述第三方终端创建警告信息。
作为本申请另一实施方式的进一步改进,在接收出发指令后,所述招车终端还将计算的预计行车路程、当前坐标下距离目的地的剩余行车路程发送给指定联系人对应的第三方终端,所述方法还包括:
若所述剩余行车路程大于或等于预计行车路程与预设误差路程之和,则所述第三方终端创建警告信息。
作为本申请另一实施方式的进一步改进,在接收出发指令后,所述招车终端还将计算的预计行车路线、预计行车路程、实时坐标信息发送给指定联系人对应的第三方终端,所述方法还包括:
所述第三方终端根据所述招车终端的实时坐标信息确定其当前坐标,计算所述招车终端的当前坐标至目的地的剩余行车路程,若所述剩余行车路程大于或等于预计行车路程与预设误差路程之和,则创建警告信息。
为实现上述申请目的之一,本申请一实施方式提供了一种乘车信息共享系统,所述系统包括招车终端,以及指定联系人对应的第三方终端,所述招车终端用于:
接收出发地位置信息和目的地位置信息并发起招车请求;
接收招车成功信息,并获取对应车辆的基础信息,所述基础信息包括车牌号和/或司机身份信息;
接收出发指令,并至少将所述基础信息、出发地位置信息、目的地位置信息发送给指定联系人对应的第三方终端。
作为本申请一实施方式的进一步改进,所述招车终端还用于:
根据所述出发地位置信息和所述目的地位置信息计算预计行车时间,并在接收到出发指令时开始计时;
若在预计行车时间+预设误差时间内未接收到到达指令,则向所述第三方终端发出警告信息。
作为本申请一实施方式的进一步改进,所述招车终端还用于:
根据所述出发地位置信息和所述目的地位置信息计算预计行车路线及相应的预计行车路程;
计算当前坐标至目的地的剩余行车路程,若所述剩余行车路程大于或等于预计行车路程与预设误差路程之和,则向所述第三方终端发出警告信息。
作为本申请一实施方式的进一步改进,所述招车终端还用于:将实时坐标 信息发送给指定联系人对应的第三方终端。
为实现上述申请目的之一,本申请另一实施方式提供了一种乘车信息共享系统,所述系统包括招车终端,以及指定联系人对应的第三方终端,所述招车终端用于:
接收出发地位置信息和目的地位置信息并发起招车请求;
接收招车成功信息,并获取对应车辆的基础信息,所述基础信息包括车牌号和/或司机身份信息;
接收出发指令,并至少将所述基础信息和出发指令发送给指定联系人对应的第三方终端。
作为本申请另一实施方式的进一步改进,所述招车终端还用于:
在接收到出发指令后,将计算的预计行车时间发送给指定联系人对应的第三方终端;
所述第三方终端用于:
根据所述出发指令开始计时;
若在预计行车时间+预设误差时间内未收到招车终端发出的到达信息,则所述创建警告信息。
作为本申请另一实施方式的进一步改进,所述招车终端还用于:
在接收出发指令后,将计算的预计行车路程、当前坐标下距离目的地的剩余行车路程发送给指定联系人对应的第三方终端;
所述第三方终端用于:
若所述剩余行车路程大于或等于预计行车路程与预设误差路程之和,则创建警告信息。
作为本申请另一实施方式的进一步改进,所述招车终端还用于:
在接收出发指令后,将计算的预计行车路程、实时坐标信息发送给指定联系人对应的第三方终端,
所述第三方终端用于:
根据所述招车终端的实时坐标信息确定其当前坐标,计算所述招车终端的 当前坐标至目的地的剩余行车路程,若所述剩余行车路程大于或等于预计行车路程与预设误差路程之和,则创建警告信息。
相对于现有技术,本申请的技术效果在于:本申请可将乘车用户乘车的相关信息共享给第三方,并可通过这些相关信息监控乘车用户乘车过程,保证乘车用户乘车安全。
附图说明
图1是本申请一实施方式中乘车信息共享方法的流程图;
图2a~2c是本申请一实施方式中乘车信息共享方法及系统的应用场景示意图;
图3是本申请另一实施方式中乘车信息共享方法的流程图;
图4是本申请实施方式中乘车信息共享系统的模块图。
具体实施方式
以下将结合附图所示的具体实施方式对本申请进行详细描述。但这些实施方式并不限制本申请,本领域的普通技术人员根据这些实施方式所做出的结构、方法、或功能上的变换均包含在本申请的保护范围内。
如图1所示,在本申请一实施方式中,所述乘车信息共享方法,包括:
S101、接收出发地位置信息和目的地位置信息并发起招车请求;
S102、接收招车成功信息,并获取对应车辆的基础信息,所述基础信息包括车牌号和/或司机身份信息;
S103、接收出发指令,并至少将所述基础信息、出发地位置信息、目的地位置信息发送给指定联系人对应的第三方终端。
一般地,通过打车软件叫车时,需要先在招车终端(例如手机、平板等)的相应打车软件(例如快的、滴滴等)上输入出发地位置信息和目的地位置信息。招车终端在接收到出发地位置信息和目的地位置信息后,可通过服务器向同样运行有对应打车软件的接单终端广播招车请求。
接单终端可通过打车软件接收招车请求,并可在打车软件上选择接受该招车请求,以提供租车服务。当有接单终端接受该招车请求后,服务器可向招车终端发送招车成功信息。
招车终端在接收到所述招车成功信息时,可获取提供本次租车服务的对应车辆的基础信息,在本实施方式中,该基础信息包括车牌号和/或司机身份信息,该司机身份信息只要可追查到司机身份即可,例如,司机姓名、身份证号、上岗证号、联系电话等至少其中之一。
在本实施方式中,当乘车用户上车后,可向招车终端输入出发指令,招车终端在接收到该出发指令后,可至少将上述提供租车服务的对应车辆的基础信息,以及出发地位置信息、目的地位置信息发送给指定联系人对应的第三方终端,如图2a、2b所示意,如此,指定联系人可获知乘车用户上了哪辆出租车且大概需要多久时间从出发地到达目的地,以便后续确认乘车用户状况(例如电话乘车用户询问是否到达目的地)及追查出租车。
进一步地,在本实施方式中,所述方法还包括:
根据所述出发地位置信息和所述目的地位置信息计算预计行车时间,并在接收到出发指令时开始计时;
若在预计行车时间+预设误差时间内未接收到到达指令,则向所述第三方终端发出警告信息。
一般地,招车终端在发起招车请求时,还可根据出发地位置信息和目的地位置信息计算预计行车时间。在本实施方式中,当所述招车终端的打车软件接收到出发指令时,即刻开始对行车时间进行计时,以计算实际行车时间。实际行车时间的计时由出发指令触发,由到达指令终止。该到达指令可为单独的到达指令,也可为乘车用户下车时的结账指令。
在本实施方式中,所述招车终端的打车软件还会判断所述实际行车时间是否超过预计行车时间+预设误差时间,设定预设误差时间可避免堵车、事故、车辆行驶速度等原因造成的在预计行车时间内未到达目的地,若在预计行车时间+预设误差时间内未接收到到达指令,例如图2c所示意,原本预计行车时间为17 分钟,但经过了120分钟招车终端仍未收到到达指令,这表示乘车用户乘车处于非正常状态,此时,即通过所述招车终端向所述第三方终端发出警告信息,以通知指定联系人。指定联系人在收到该警告信息后,可通过联系乘车用户以判断其是否安全,若出现任何乘车用户不安全的征兆,该指定联系人即可通过上述车辆的基础信息对车辆进行追查。
当然,若实际行车时间未超过预计行车时间+预计误差时间,即是在预计行车时间+预设误差时间内接收到到达指令,则表示乘车用户安全到达,无须发出警告信息。
上述是通过实际行车时间来判断是否发出警告信息给第三方终端,在本实施方式中,还可通过剩余行车路程来判断是否发出警告信息给第三方终端。当然,也可既通过实际行车时间,也可通过剩余行车路程综合的判断是否发出警告信息给第三方终端。
通过剩余行车路程判断是否发出警告信息,具体包括:
根据所述出发地位置信息和所述目的地位置信息计算预计行车路线及相应的预计行车路程;
计算当前坐标至目的地的剩余行车路程,若所述剩余行车路程大于或等于预计行车路程与预设误差路程之和,则向所述第三方终端发出警告信息。
一般地,招车终端在发起招车请求时,还可根据出发地位置信息和目的地位置信息计算预计行车路线及相应的预计行车路程。可以理解的是,当由出发地向目的地行车后,理论上招车终端的当前坐标与目的地之间的剩余行车路程应当逐渐变小,当然,也可能出现因交通情况、道路情况等因素导致的当前坐标与目的地之间的剩余行车路程会稍微变大,但这个变大的幅度应该是有限的,故设置了预设误差路程,若剩余行车路程大于或等于预计行车路程与预设误差路程之和,例如,图2c所示意,原本预计行车路程为7.11公里,而当前的剩余行程路程远远超过了7.11公里,这表示乘车用户乘车处于非正常状态,此时,即通过所述招车终端向所述第三方终端发出警告信息,以通知指定联系人。指定联系人在收到该警告信息后,可通过联系乘车用户以判断其是否安全,若出 现任何乘车用户不安全的征兆,该指定联系人即可通过上述车辆的基础信息对车辆进行追查。
当然,若剩余行车路程小于预计行车路程与预设误差路程之和,则表示乘车用户处于正常乘车状态,无须发出警告信息。
进一步地,在本实施方式中,所述方法还包括:将实时坐标信息发送给指定联系人对应的第三方终端。如此,即可实现招车终端的打车软件和第三方终端的打车软件实时同步乘车用户的乘车过程。在此情况下,指定联系人可通过主动观察该乘车过程以判断乘车用户是否安全。当然,即便第三方终端接收到所述招车终端的实时坐标信息,亦可不实时观察乘车用户的乘车过程,而是通过上述方式(实际行车时间、剩余行车路程)了解乘车用户是否安全。
如图3所示,在本申请另一实施方式的乘车信息共享方法,其和上述实施方式的区别点在于,对实际行车时间、剩余行车路程的判断是由第三方终端处理的,警报信息也是由第三方终端创建的,招车终端只需向第三方终端提供需要的信息即可。以下仅对本实施方式与上述实施方式的区别进行说明,其他内容可参上述实施方式,在此不再赘述。
在本实施方式中,所述乘车信息共享方法包括:
S301、招车终端接收出发地位置信息和目的地位置信息并发起招车请求;
S302、招车终端接收招车成功信息,并获取对应车辆的基础信息,所述基础信息包括车牌号和/或司机身份信息;
S303、招车终端接收出发指令,并至少将所述基础信息和出发指令发送给指定联系人对应的第三方终端。
进一步地,在本实施方式中,在接收到出发指令后,所述招车终端还将计算的预计行车时间发送给指定联系人对应的第三方终端,所述方法还包括:
第三方终端根据所述出发指令开始计时;
若在预计行车时间+预设误差时间内未收到招车终端发出的到达信息,则所述第三方终端创建警告信息。
上述是第三方终端通过实际行车时间来判断是否创建警告信息的,在本实 施方式中,还可通过剩余行车路程来判断是否创建警告信息。当然,所述第三方终端也可既通过实际行车时间,也可通过剩余行车路程综合的判断是否创建警告信息。
通过剩余行车路程判断是否创建警告信息,具体包括:
在接收出发指令后,所述招车终端还将计算的预计行车路程、当前坐标下距离目的地的剩余行车路程发送给指定联系人对应的第三方终端,所述方法还包括:
若所述剩余行车路程大于或等于预计行车路程与预设误差路程之和,则所述第三方终端创建警告信息。
当然,在本实施方式的另一种情况下,计算剩余行程路程也由第三方终端完成:
在接收出发指令后,所述招车终端还将计算的预计行车路线、预计行车路程、实时坐标信息发送给指定联系人对应的第三方终端,所述方法还包括:
所述第三方终端根据所述招车终端的实时坐标信息确定其当前坐标,计算所述招车终端的当前坐标至目的地的剩余行车路程,若所述剩余行车路程大于或等于预计行车路程与预设误差路程之和,则创建警告信息。
如图4所示,在本申请一实施方式中,所述乘车信息共享系统对应于如图1所示的乘车信息共享方法,其包括:招车终端100,以及指定联系人对应的第三方终端200,当然,所述系统还可包括服务器300和接单终端400,所述服务器300可实现招车终端100、第三方终端200、接单终端400之间的通信;所述接单终端400可接受所述招车终端100发出的招车请求。
具体地,所述招车终端100用于:
接收出发地位置信息和目的地位置信息并发起招车请求;
接收招车成功信息,并获取对应车辆的基础信息,所述基础信息包括车牌号和/或司机身份信息;
接收出发指令,并至少将所述基础信息、出发地位置信息、目的地位置信息发送给指定联系人对应的第三方终端。
一般地,通过打车软件叫车时,需要先在招车终端100(例如手机、平板等)的相应打车软件(例如快的、滴滴等)上输入出发地位置信息和目的地位置信息。招车终端100在接收到出发地位置信息和目的地位置信息后,可通过服务器300向同样运行有对应打车软件的接单终端400广播招车请求。
接单终端400可通过打车软件接收招车请求,并可在打车软件上选择接受该招车请求,以提供租车服务。当有接单终端400接受该招车请求后,服务器300可向招车终端发送招车成功信息。
招车终端100在接收到所述招车成功信息时,可获取提供本次租车服务的对应车辆的基础信息,在本实施方式中,该基础信息包括车牌号和/或司机身份信息,该司机身份信息只要可追查到司机身份即可,例如,司机姓名、身份证号、上岗证号、联系电话等至少其中之一。
在本实施方式中,当乘车用户上车后,可向招车终端100输入出发指令,招车终端100在接收到该出发指令后,可至少将上述提供租车服务的对应车辆的基础信息,以及出发地位置信息、目的地位置信息发送给指定联系人对应的第三方终端200,如图2a、2b所示意,如此,指定联系人可获知乘车用户上了哪辆出租车且大概需要多久时间从出发地到达目的地,以便后续确认乘车用户状况(例如电话乘车用户询问是否到达目的地)及追查出租车。
进一步地,在本实施方式中,所述招车终端100还用于:
根据所述出发地位置信息和所述目的地位置信息计算预计行车时间,并在接收到出发指令时开始计时;
若在预计行车时间+预设误差时间内未接收到到达指令,则向所述第三方终端发出警告信息。
一般地,招车终端100在发起招车请求时,还可根据出发地位置信息和目的地位置信息计算预计行车时间。在本实施方式中,当所述招车终端100的打车软件接收到出发指令时,即刻开始对行车时间进行计时,以计算实际行车时间。实际行车时间的计时由出发指令触发,由到达指令终止。该到达指令可为单独的到达指令,也可为乘车用户下车时的结账指令。
在本实施方式中,所述招车终端100的打车软件还会判断所述实际行车时间是否超过预计行车时间+预设误差时间,设定预设误差时间可避免堵车、事故、车辆行驶速度等原因造成的在预计行车时间内未到达目的地,若在预计行车时间+预设误差时间内未接收到到达指令,例如图2c所示意,原本预计行车时间为17分钟,但经过了120分钟招车终端仍未收到到达指令,这表示乘车用户乘车处于非正常状态,此时,即通过所述招车终端100向所述第三方终端200发出警告信息,以通知指定联系人。指定联系人在收到该警告信息后,可通过联系乘车用户以判断其是否安全,若出现任何乘车用户不安全的征兆,该指定联系人即可通过上述车辆的基础信息对车辆进行追查。
当然,若实际行车时间未超过预计行车时间+预计误差时间,即是在预计行车时间+预设误差时间内接收到到达指令,则表示乘车用户安全到达,无须发出警告信息。
上述是通过实际行车时间来判断是否发出警告信息给第三方终端200,在本实施方式中,还可通过剩余行车路程来判断是否发出警告信息给第三方终端200。当然,也可既通过实际行车时间,也可通过剩余行车路程综合的判断是否发出警告信息给第三方终端200。
通过剩余行车路程判断是否发出警告信息,所述招车终端100还用于:
根据所述出发地位置信息和所述目的地位置信息计算预计行车路线及相应的预计行车路程;
计算当前坐标至目的地的剩余行车路程,若所述剩余行车路程大于或等于预计行车路程与预设误差路程之和,则向所述第三方终端200发出警告信息。
一般地,招车终端100在发起招车请求时,还可根据出发地位置信息和目的地位置信息计算预计行车路线及相应的预计行车路程。可以理解的是,当由出发地向目的地行车后,理论上招车终端100的当前坐标与目的地之间的剩余行车路程应当逐渐变小,当然,也可能出现因交通情况、道路情况等因素导致的当前坐标与目的地之间的剩余行车路程会稍微变大,但这个变大的幅度应该是有限的,故设置了预设误差路程,若剩余行车路程大于或等于预计行车路程 与预设误差路程之和,例如,图2c所示意,原本预计行车路程为7.11公里,而当前的剩余行程路程远远超过了7.11公里,这表示乘车用户乘车处于非正常状态,此时,即通过所述招车终端100向所述第三方终端200发出警告信息,以通知指定联系人。指定联系人在收到该警告信息后,可通过联系乘车用户以判断其是否安全,若出现任何乘车用户不安全的征兆,该指定联系人即可通过上述车辆的基础信息对车辆进行追查。
当然,若剩余行车路程小于预计行车路程与预设误差路程之和,则表示乘车用户处于正常乘车状态,无须发出警告信息。
进一步地,在本实施方式中,所述招车终端100还用于:将实时坐标信息发送给指定联系人对应的第三方终端。如此,即可实现招车终端100的打车软件和第三方终端200的打车软件实时同步乘车用户的乘车过程。在此情况下,指定联系人可通过主动观察该乘车过程以判断乘车用户是否安全。当然,即便第三方终端200接收到所述招车终端的实时坐标信息,亦可不实时观察乘车用户的乘车过程,而是通过上述方式(实际行车时间、剩余行车路程)了解乘车用户是否安全。
在本申请另一实施方式中,所述乘车信息共享系统对应于如图3所示的乘车信息共享方法,其和上述实施方式的区别点在于,对实际行车时间、剩余行车路程的判断是由第三方终端200处理的,警报信息也是由第三方终端200创建的,招车终端100只需向第三方终端200提供需要的信息即可。以下仅对本实施方式与上述实施方式的区别进行说明,其他内容可参上述实施方式,在此不再赘述。
在本实施方式中,所述招车终端用于:
接收出发地位置信息和目的地位置信息并发起招车请求;
接收招车成功信息,并获取对应车辆的基础信息,所述基础信息包括车牌号和/或司机身份信息;
接收出发指令,并至少将所述基础信息和出发指令发送给指定联系人对应的第三方终端。
进一步地,在本实施方式中,所述招车终端100还用于:
在接收到出发指令后,所述招车终端还将计算的预计行车时间发送给指定联系人对应的第三方终端,所述第三方终端200用于:
根据所述出发指令开始计时;
若在预计行车时间+预设误差时间内未收到招车终端发出的到达信息,则创建警告信息。
上述是第三方终端200通过实际行车时间来判断是否创建警告信息的,在本实施方式中,还可通过剩余行车路程来判断是否创建警告信息。当然,所述第三方终端200也可既通过实际行车时间,也可通过剩余行车路程综合的判断是否创建警告信息。
通过剩余行车路程判断是否创建警告信息,具体地,所述招车终端100还用于:
在接收出发指令后,所述招车终端还将计算的预计行车路程、当前坐标下距离目的地的剩余行车路程发送给指定联系人对应的第三方终端;
所述第三方终端200用于:
若所述剩余行车路程大于或等于预计行车路程与预设误差路程之和,则创建警告信息。
当然,在本实施方式的另一种情况下,计算剩余行程路程也由第三方终端200完成,具体地,所述招车终端100还用于:
在接收出发指令后,将计算的预计行车路线、预计行车路程、实时坐标信息发送给指定联系人对应的第三方终端200,
所述第三方终端200用于:
根据所述招车终端的实时坐标信息确定其当前坐标,计算所述招车终端的当前坐标至目的地的剩余行车路程,若所述剩余行车路程大于或等于预计行车路程与预设误差路程之和,则创建警告信息。
综上所述,本申请可将乘车用户乘车的相关信息共享给第三方,并可通过这些相关信息监控乘车用户乘车过程,保证乘车用户乘车安全。
所属领域的技术人员可以清楚地了解到,为描述的方便和简洁,上述描述的装置,装置和模块的具体工作过程,可以参考前述方法实施方式中的对应过程,在此不再赘述。
在本申请所提供的几个实施方式中,应该理解到,所揭露的装置,装置和方法,可以通过其它的方式实现。例如,以上所描述的装置实施方式仅仅是示意性的,例如,所述模块的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式,例如多个模块或组件可以结合或者可以集成到另一个装置,或一些特征可以忽略,或不执行。另一点,所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口,装置或模块的间接耦合或通信连接,可以是电性,机械或其它的形式。
所述作为分离部件说明的模块可以是或者也可以不是物理上分开的,作为模块显示的部件可以是或者也可以不是物理模块,即可以位于一个地方,或者也可以分布到多个网络模块上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施方式方案的目的。
另外,在本申请各个实施方式中的各功能模块可以集成在一个处理模块中,也可以是各个模块单独物理存在,也可以2个或2个以上模块集成在一个模块中。上述集成的模块既可以采用硬件的形式实现,也可以采用硬件加软件功能模块的形式实现。
上述以软件功能模块的形式实现的集成的模块,可以存储在一个计算机可读取存储介质中。上述软件功能模块存储在一个存储介质中,包括若干指令用以使得一台计算机装置(可以是个人计算机,服务器,或者网络装置等)或处理器(processor)执行本申请各个实施方式所述方法的部分步骤。而前述的存储介质包括:U盘、移动硬盘、只读存储器(Read-Only Memory,ROM)、随机存取存储器(Random Access Memory,RAM)、磁碟或者光盘等各种可以存储程序代码的介质。
最后应说明的是:以上实施方式仅用以说明本申请的技术方案,而非对其限制;尽管参照前述实施方式对本申请进行了详细的说明,本领域的普通 技术人员应当理解:其依然可以对前述各实施方式所记载的技术方案进行修改,或者对其中部分技术特征进行等同替换;而这些修改或者替换,并不使相应技术方案的本质脱离本申请各实施方式技术方案的精神和范围。