出车中接单失败原因分析方法、服务端及接单失败司机端与流程

文档序号:12478107阅读:1513来源:国知局
出车中接单失败原因分析方法、服务端及接单失败司机端与流程

本发明涉及一种分析方法,尤其涉及一种出车中接单失败原因分析方法、服务端及接单失败司机端。



背景技术:

随着移动互联网的发展,打车软件的普及,人生的打车习惯已经被深刻地改变。现行的打车系统通常采用的方式是服务端将乘客订单派发出去,有可能多个司机的移动终端同时接到该乘客订单,司机可以通过移动终端对该订单执行某些操作,例如拒绝或接收或不回应,此时,服务端会比较所有接到订单的司机的信息或状态,并根据一定的规则,将乘客订单优先配对给某一位司机的移动终端。

上述情况下,某一位司机接单成功,至少有一位司机接单失败。现有技术中,没有相应的措施来告知司机接单失败的原因,司机也不知道如何提高自身的服务质量来获取更多的乘客订单。这种情况,不利于整个智能租车领域的发展,不利于整个租车服务质量的提升。



技术实现要素:

针对以上技术不足,本发明提供了一种在司机通过移动终端接单失败时向司机展示失败原因的方法及相应的服务端、接单失败司机端。本发明的技术方案直接告知接单失败的司机没有被选中的原因,有助于司机提升自己的服务质量。

本发明是这样实现的:一种出车服务中接单失败原因的分析方法,

所述服务端根据乘客端选中的司机端信息来确定接单成功司机端和接单失败司机端,并根据接单成功司机端和接单失败司机端的响应信息和用户信息生成分析信息;

所述服务端将分析信息发送至接单失败司机端。

进一步地,服务端在确定接单成功司机端和接单失败司机端之前还包括:

服务端接收乘客端发来的打车请求并根据打车请求选取符合条件的至少两个司机端,并将打车请求发送至所述司机端;

所述服务端接收司机端发来的对打车请求的响应信息,根据响应信息获取相应司机端的用户信息并生成对比信息;

所述服务端将对比信息发送至乘客端供选择并接收乘客端返回的选中的司机端信息。

进一步地,所述分析信息包括接单成功司机端和接单失败司机端所对应司机的注册信息、信用评分、收藏次数、定位信息、对打车请求的响应时间、响应结果中的一项或几项。

本发明还提供了另一种出车服务中接单失败原因的分析方法,

所述接单失败司机端接收服务端发来的分析信息,所述分析信息由服务端根据接单成功司机端和接单失败司机端的响应信息和用户信息生成,所述接单成功司机端和接单失败司机端由服务端根据乘客端选中的司机端信息来确定。

进一步地,在接单失败司机端接收服务端发来的分析信息之前还包括:

所述接单失败司机端接收服务端发来的打车请求,并向服务端发送对打车请求的响应信息。

进一步地,所述分析信息包括接单成功司机端和接单失败司机端所对应司机的注册信息、信用评分、收藏次数、定位信息、对打车请求的响应时间、响应结果中的一项或几项。

本发明还提供一种服务端,所述服务端包括:

分析单元,用于根据乘客端选中的司机端信息来确定接单成功司机端和接单失败司机端,并根据接单成功司机端和接单失败司机端的响应信息和用户信息生成分析信息;

发送单元,用于将分析信息发送至接单失败司机端。

进一步地,所述服务端还包括:

接收单元,用于接收乘客端发来的打车请求、选中的司机端信息以及司机端发来的对打车请求的响应信息;

司机端选取单元,用于根据打车请求选取符合条件的至少两个司机端;

对比信息生成单元,用于根据响应信息获取相应司机端的用户信息并生成对比信息;

所述发送单元还用于将打车请求发送至司机端选取单元选取的司机端,将对比信息发送至乘客端。

进一步地,所述服务端还包括存储单元,所述存储单元用于存储司机的用户信息,所述用户信息包括注册信息、信用评分以及被收藏次数。

进一步地,所述分析信息包括接单成功司机端和接单失败司机端所对应司机的注册信息、信用评分、收藏次数、定位信息、对打车请求的响应时间、响应结果中的一项或几项。

本发明还提供一种接单失败司机端,所述接单失败司机端包括:

接收单元,用于接收服务端发来的分析信息,所述分析信息由服务端根据接单成功司机端和接单失败司机端的响应信息和用户信息生成,所述接单成功司机端和接单失败司机端由服务端根据乘客端选中的司机端信息来确定。

进一步地,所述接单失败司机端还包括:

发送单元,用于向服务端发送对打车请求的响应信息;

所述接收单元还用于接收服务端发来的打车请求。

进一步地,所述分析信息包括接单成功司机端和接单失败司机端所对应司机的注册信息、信用评分、收藏次数、定位信息、对打车请求的响应时间、响应结果中的一项或几项。

与现有技术相比,本发明的有益效果如下:本技术方案中由服务端向接单失败的司机端发送分析信息,分析信息中包含了接单成功司机端和自身信息的对比,其中接单成功司机端与接单失败司机端收到相同的打车请求,所述分析信息中包含两个司机端对乘客订单的响应信息以及对应司机的用户信息。

接单失败的司机查看收到的分析信息,即能清楚知道自己哪些方面不如接单成功的司机了,从而有针对性提提升自己的服务质量,以便提高自己接单成功的概率。从另一个角度,也提升了整个智能打车领域的服务质量,加快整个领域的发展。

附图说明

图1为本发明实施例提供的出车中接单失败原因分析方法的流程图;

图2为本发明实施例提供的另一种出车中接单失败原因分析方法的流程图;

图3为本发明实施例提供的服务端的结构示意图;

图4为本发明实施例提供的接单失败司机端的结构示意图;

图5为本发明实施例中接单失败司机端接到分析信息后的界面示意图。

具体实施方式

为了使本发明所要解决的技术问题、技术方案及有益效果更加清楚明白,以下结合附图及实施例,对本发明进行进一步详细说明。应当理解,此处所描述的具体实施例仅用以解释本发明,并不用于限定本发明。

本发明实施例提供的一种出车中接单失败原因分析方法,如图1,该方法包括:

S104、所述服务端根据乘客端选中的司机端信息来确定接单成功司机端和接单失败司机端,并根据接单成功司机端和接单失败司机端的响应信息和用户信息生成分析信息。

S105、所述服务端将分析信息发送至接单失败司机端。

本发明技术方案中,在乘客端选定一个司机端来提供出车服务后,这个被选定的司机端即为接单成功司机端,其他未被选中的司机端即为接单失败司机端。服务端根据之前接收的接单成功司机端和接单失败司机端发回的针对打车请求的响应信息以及预先存储的用户信息生成分析信息。

作为优选,分析信息只包括接单成功司机端和接单失败司机端自身信息的对比,不包括其他接单失败司机端的信息。该信息包括影响乘客选择的信息类型,例如司机的注册信息(包括司机的ID、性别、电话号码、车型、车龄)、信用评分(以往乘客对司机服务的评价情况,服务质量越高,信用评分越高)、收藏次数(被乘客收藏的次数,一般乘客对该司机的服务满意,会收藏)、定位信息(例如GPS定位,包括经纬度和时间戳信息,从而可计算出司机端离乘客端的距离)、对打车请求的响应时间(收到打车请求后作出处理的时间)、响应结果(对打车请求采取接单或拒绝)中的一项或几项。

本发明为了克服现有技术中接单失败司机端不知道自己为何不被乘客选中,从而导致不能针对性地进行改进的缺陷,在乘客选定司机后,还将包括接单失败司机端的信息和接单成功司机端的信息的分析信息发给接单失败司机端。接单失败司机端对应的司机查看分析信息,即可知道自己是哪些方面的原因导致未被乘客选中,从而可以针对性地改进自身的服务。

为了适应乘客的需求,直接派单的方式逐渐淘汰,取而代之的是让乘客来自主选择为自己提供出车服务的司机。选择一定范围内的司机,并将司机的可能影响乘客选择的信息列出来发送给乘客供其选择。比如乘客大多都倾向于选择信用评分高的司机来提供出车服务,又有的乘客倾向于选择某种车型的司机来提供出车服务。乘客自主选择司机的方式,极大地提高了智能出车服务的人性化。

示例性地,服务端在确定接单成功司机端和接单失败司机端之前还包括如下步骤:

S101、服务端接收乘客端发来的打车请求并根据打车请求选取符合条件的至少两个司机端,并将打车请求发送至所述司机端;

乘客通过乘客端先向服务端发起打车请求,其中打车请求中携带有乘客端对应乘客的身份标识信息以及定位信息。服务端接收到打车请求后,根据打车请求中的信息,按照一定的规则选定符合要求的司机端。由于本发明是针对接单失败司机端提供分析信息的,因此至少有一个接单成功司机端和一个接单失败司机端。

本发明示例性地采用GPS定位信息,服务端选择所有离乘客端在一定距离范围内的司机端并发送打车请求。司机端接收到打车请求后,对该打车请求作出响应,例如接单或者拒绝,并将该响应信息返回至服务端。其中响应信息中携带有司机的身份信息、定位信息、对打车请求的响应时间、响应结果等。

S102、所述服务端接收司机端发来的对打车请求的响应信息,根据响应信息获取相应司机端的用户信息并生成对比信息;

所述对比信息包括各接单司机端的注册信息(包括司机的ID、性别、电话号码、车型、车龄)、信用评分(以往乘客对司机服务的评价情况,服务质量越高,信用评分越高)、收藏次数(被乘客收藏的次数,一般乘客对该司机的服务满意,会收藏)、定位信息(例如GPS定位,从而可计算出司机端离乘客端的距离)、对打车请求的响应时间(收到打车请求后作出处理的时间)、响应结果(对打车请求采取接单或拒绝)中的一项或几项。对比信息在信息的类型上与分析信息一致。

服务端接收到各司机端的响应信息后,筛选出接单的司机端并根据其身份信息,获取其存储于服务端中的用户信息,本发明示例性地包括司机的ID、性别、电话号码、车型、车龄以及信用评分、被乘客收藏的次数。

S103、所述服务端将对比信息发送至乘客端供选择并接收乘客端返回的选中的司机端信息。

服务端将各接单的司机端的响应信息和用户信息整合成对比信息发送至乘客端。乘客端根据自己的需求选择提供出车服务的司机端,并将选中的司机端返回至服务端,服务端即可确认接单成功司机端(即乘客端选中的司机端)和接单失败司机端(针对该打车请求已经接单的其他未被选中的司机端)。

基于同一发明构思,本发明实施例还提供了一种接单失败司机端侧的出车中接单失败原因分析方法,如图2所示,该方法包括:

S201、所述接单失败司机端接收服务端发来的打车请求,并向服务端发送对打车请求的响应信息。

示例性地,接单失败司机端接收服务端发来的打车请求,司机端接收到打车请求后,对该打车请求作出响应,例如接单或者拒绝,并将该响应信息返回至服务端。其中响应信息中携带有司机的身份信息、定位信息、对打车请求的响应时间、响应结果等。

此时,由于乘客端还未做出选择,因此接单失败司机端可看作普通的司机端。

S202、所述接单失败司机端接收服务端发来的分析信息,所述分析信息由服务端根据接单成功司机端和接单失败司机端的响应信息和用户信息生成,所述接单成功司机端和接单失败司机端由服务端根据乘客端选中的司机端信息来确定。

服务端接收到各司机端的响应信息后,筛选出接单的司机端并根据其身份信息,获取其存储于服务端中的用户信息,本发明示例性地包括司机的ID、性别、电话号码、车型、车龄以及信用评分、被乘客收藏的次数。

服务端将各接单的司机端的响应信息和用户信息整合成对比信息发送至乘客端。所述对比信息包括各接单司机端的注册信息(包括司机的ID、性别、电话号码、车型、车龄)、信用评分(以往乘客对司机服务的评价情况,服务质量越高,信用评分越高)、收藏次数(被乘客收藏的次数,一般乘客对该司机的服务满意,会收藏)、定位信息(例如GPS定位,从而可计算出司机端离乘客端的距离)、对打车请求的响应时间(收到打车请求后作出处理的时间)、响应结果(对打车请求采取接单或拒绝)中的一项或几项。对比信息在信息的类型上与分析信息一致。

乘客端根据自己的需求选择提供出车服务的司机端,并将选中的司机端返回至服务端,服务端即可确认接单成功司机端(即乘客端选中的司机端)和接单失败司机端(针对该打车请求已经接单的其他未被选中的司机端)。

服务端根据之前接收的接单成功司机端和接单失败司机端发回的针对打车请求的响应信息以及预先存储的用户信息生成分析信息。

作为优选,分析信息只包括接单成功司机端和接单失败司机端自身信息的对比,不包括其他接单失败司机端的信息。该信息包括影响乘客选择的信息类型,例如司机的注册信息(包括司机的ID、性别、电话号码、车型、车龄)、信用评分(以往乘客对司机服务的评价情况,服务质量越高,信用评分越高)、收藏次数(被乘客收藏的次数,一般乘客对该司机的服务满意,会收藏)、定位信息(例如GPS定位,从而可计算出司机端离乘客端的距离)、对打车请求的响应时间(收到打车请求后作出处理的时间)、响应结果(对打车请求采取接单或拒绝)中的一项或几项。

本发明为了克服现有技术中接单失败司机端不知道自己为何不被乘客选中,从而导致不能针对性地进行改进的缺陷,在乘客选定司机后,还将包括接单失败司机端的信息和接单成功司机端的信息的分析信息发给接单失败司机端。接单失败司机端对应的司机查看分析信息,即可知道自己是哪些方面的原因导致未被乘客选中,从而可以针对性地改进自身的服务。

基于同一发明构思,本发明实施例还提供了一种服务端,如图3所示,所述服务端包括:

分析单元304,用于根据乘客端选中的司机端信息来确定接单成功司机端和接单失败司机端,并根据接单成功司机端和接单失败司机端的响应信息和用户信息生成分析信息。

服务端接收乘客端选中的司机端信息后,分析单元304即可确认接单成功司机端(即乘客端选中的司机端)和接单失败司机端(针对该打车请求已经接单的其他未被选中的司机端),分析单元304根据之前接收的接单成功司机端和接单失败司机端发回的针对打车请求的响应信息以及预先存储的用户信息生成分析信息。

作为优选,分析信息只包括接单成功司机端和接单失败司机端自身信息的对比,不包括其他接单失败司机端的信息。该信息的内容包括影响乘客选择的信息类型,例如司机的注册信息(包括司机的ID、性别、电话号码、车型、车龄)、信用评分(以往乘客对司机服务的评价情况,服务质量越高,信用评分越高)、收藏次数(被乘客收藏的次数,一般乘客对该司机的服务满意,会收藏)、定位信息(例如GPS定位,从而可计算出司机端离乘客端的距离)、对打车请求的响应时间(收到打车请求后作出处理的时间)、响应结果(对打车请求采取接单或拒绝)中的一项或几项。

发送单元305,用于将分析信息发送至接单失败司机端。

为了适应乘客的需求,直接派单的方式逐渐淘汰,取而代之的是让乘客来自主选择为自己提供出车服务的司机。选择一定范围内的司机,并将司机的可能影响乘客选择的信息列出来发送给乘客供其选择。比如乘客大多都倾向于选择信用评分高的司机来提供出车服务,又有的乘客倾向于选择某种车型的司机来提供出车服务。乘客自主选择司机的方式,极大地提高了智能出车服务的人性化。

为了满足上述要求,示例性地,本发明所述的服务端还包括:

接收单元301,用于接收乘客端发来的打车请求、选中的司机端信息以及司机端发来的对打车请求的响应信息;

司机端选取单元302,用于根据打车请求选取符合条件的至少两个司机端;

对比信息生成单元303,用于根据响应信息获取相应司机端的用户信息并生成对比信息;

所述发送单元305还用于将打车请求发送至司机端选取单元选取的司机端,将对比信息发送至乘客端。

存储单元306,所述存储单元用于存储司机的用户信息,所述用户信息包括注册信息、信用评分以及被收藏次数。

其中注册信息包括司机的ID、性别、电话号码、车型、车龄等;信用评分为以往乘客对司机服务的评价情况,服务质量越高,信用评分越高;收藏次数为被乘客收藏的次数,一般乘客对该司机的服务满意,会收藏。

接收单元301接收乘客端发来的打车请求,其中打车请求中携带有乘客端对应乘客的身份标识信息以及定位信息。司机端选取单元302根据打车请求中的信息,按照一定的规则选定符合要求的司机端。由于本发明是针对接单失败司机端提供分析信息的,因此至少有一个接单成功司机端和一个接单失败司机端。

本发明示例性地采用GPS定位信息,司机端选取单元302选择所有离乘客端在一定距离范围内的司机端并通过发送单元305向其发送打车请求。司机端接收到打车请求后,对该打车请求作出响应,例如接单或者拒绝,并将该响应信息返回至接收单元301。其中响应信息中携带有司机的身份信息(例如司机的ID或者电话号码等唯一标识)、定位信息(GPS定位信息,包括经纬度和时间戳等信息)、对打车请求的响应时间(从收到打车请求到接单的时间)、响应结果(接单或拒绝)等。

对比信息生成单元303根据接单的司机端返回的响应信息(由于其中包含身份信息),从存储模块306中获取相应司机端的用户信息并生成对比信息。所述对比信息包括各接单司机端的注册信息(包括司机的ID、性别、电话号码、车型、车龄)、信用评分(以往乘客对司机服务的评价情况,服务质量越高,信用评分越高)、收藏次数(被乘客收藏的次数,一般乘客对该司机的服务满意,会收藏)、定位信息(例如GPS定位,从而可计算出司机端离乘客端的距离)、对打车请求的响应时间(收到打车请求后作出处理的时间)、响应结果(对打车请求采取接单或拒绝)中的一项或几项。对比信息在信息的类型上与分析信息一致。

发送单元305将对比信息发送至乘客端供乘客选择,接收单元301接收乘客端发来的其选中的司机信息后供分析单元304来确定接单成功司机端和接单失败司机端。

本发明为了克服现有技术中接单失败司机端不知道自己为何不被乘客选中,从而导致不能针对性地进行改进的缺陷,在乘客选定司机后,还将包括接单失败司机端的信息和接单成功司机端的信息的分析信息发给接单失败司机端。接单失败司机端对应的司机查看分析信息,即可知道自己是哪些方面的原因导致未被乘客选中,从而可以针对性地改进自身的服务。

基于同一发明构思,本发明实施例还提供了一种接单失败司机端,如图4所示,所述接单失败司机端包括:

接收单元401,用于接收服务端发来的打车请求以及服务端发来的分析信息,所述分析信息由服务端根据接单成功司机端和接单失败司机端的响应信息和用户信息生成,所述接单成功司机端和接单失败司机端由服务端根据乘客端选中的司机端信息来确定。

发送单元402,用于向服务端发送对打车请求的响应信息。

接收单元401接收服务端发来的打车请求,发送单元402向服务端发送响应信息,所述响应信息中携带有司机的身份信息(例如司机的ID或者电话号码等唯一标识)、定位信息(GPS定位信息,包括经纬度和时间戳等信息)、对打车请求的响应时间(从收到打车请求到接单的时间)、响应结果(接单或拒绝)等。

服务端接收到各司机端的响应信息后,筛选出接单的司机端并根据其身份信息,获取其存储于服务端中的用户信息,本发明示例性地包括司机的ID、性别、电话号码、车型、车龄以及信用评分、被乘客收藏的次数。

服务端将各接单的司机端的响应信息和用户信息整合成对比信息发送至乘客端。乘客端根据自己的需求选择提供出车服务的司机端,并将选中的司机端返回至服务端,服务端即可确认接单成功司机端(即乘客端选中的司机端)和接单失败司机端(针对该打车请求已经接单的其他未被选中的司机端)。

其中对比信息包括各接单司机端的注册信息(包括司机的ID、性别、电话号码、车型、车龄)、信用评分(以往乘客对司机服务的评价情况,服务质量越高,信用评分越高)、收藏次数(被乘客收藏的次数,一般乘客对该司机的服务满意,会收藏)、定位信息(例如GPS定位,从而可计算出司机端离乘客端的距离)、对打车请求的响应时间(收到打车请求后作出处理的时间)、响应结果(对打车请求采取接单或拒绝)中的一项或几项。

服务端根据之前接收的接单成功司机端和接单失败司机端发回的针对打车请求的响应信息以及预先存储的用户信息生成分析信息并将分析信息发送至接收单元401。

示例性地,分析信息只包括接单成功司机端和接单失败司机端自身信息的对比,不包括其他接单失败司机端的信息。该信息的内容包括影响乘客选择的信息类型,例如司机的注册信息(包括司机的ID、性别、电话号码、车型、车龄)、信用评分(以往乘客对司机服务的评价情况,服务质量越高,信用评分越高)、收藏次数(被乘客收藏的次数,一般乘客对该司机的服务满意,会收藏)、定位信息(例如GPS定位,从而可计算出司机端离乘客端的距离)、对打车请求的响应时间(收到打车请求后作出处理的时间)、响应结果(对打车请求采取接单或拒绝)中的一项或几项。对比信息在信息的类型上与分析信息一致。

本发明为了克服现有技术中接单失败司机端不知道自己为何不被乘客选中,从而导致不能针对性地进行改进的缺陷,在乘客选定司机后,还将包括接单失败司机端的信息和接单成功司机端的信息的分析信息发给接单失败司机端。接单失败司机端对应的司机查看分析信息,即可知道自己是哪些方面的原因导致未被乘客选中,从而可以针对性地改进自身的服务。

在此提供的算法和显示不与任何特定计算机、虚拟系统或者其它设备固有相关。各种通用系统也可以与基于在此的示教一起使用。根据上面的描述,构造这类系统所要求的结构是显而易见的。此外,本发明也不针对任何特定编程语言。应当明白,可以利用各种编程语言实现在此描述的本发明的内容,并且上面对特定语言所做的描述是为了披露本发明的最佳实施方式。

在此处所提供的说明书中,说明了大量具体细节。然而,能够理解,本发明的实施例可以在没有这些具体细节的情况下实践。在一些实例中,并未详细示出公知的方法、结构和技术,以便不模糊对本说明书的理解。

类似地,应当理解,为了精简本公开并帮助理解各个发明方面中的一个或多个,在上面对本发明的示例性实施例的描述中,本发明的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而,并不应将该公开的方法解释成反映如下意图:即所要求保护的本发明要求比在每个权利要求中所明确记载的特征更多的特征。更确切地说,如下面的权利要求书所反映的那样,发明方面在于少于前面公开的单个实施例的所有特征。因此,遵循具体实施方式的权利要求书由此明确地并入该具体实施方式,其中每个权利要求本身都作为本发明的单独实施例。

本领域那些技术人员可以理解,可以对实施例中的设备中的模块进行自适应性地改变并且把它们设置在与该实施例不同的一个或多个设备中。可以把实施例中的模块或单元或组件组合成一个模块或单元或组件,以及此外可以把它们分成多个子模块或子单元或子组件。除了这样的特征和/或过程或者单元中的至少一些是相互排斥之外,可以采用任何组合对本说明书(包括伴随的权利要求、摘要和附图)中公开的所有特征以及如此公开的任何方法或者设备的所有过程或单元进行组合。除非另外明确陈述,本说明书(包括伴随的权利要求、摘要和附图)中公开的每个特征可以由提供相同、等同或相似目的的替代特征来代替。

此外,本领域的技术人员能够理解,尽管在此所述的一些实施例包括其它实施例中所包括的某些特征而不是其它特征,但是不同实施例的特征的组合意味着处于本发明的范围之内并且形成不同的实施例。例如,在下面的权利要求书中,所要求保护的实施例的任意之一都可以以任意的组合方式来使用。

本发明的各个部件实施例可以以硬件实现,或者以在一个或者多个处理器上运行的软件模块实现,或者以它们的组合实现。本领域的技术人员应当理解,可以在实践中使用微处理器或者数字信号处理器(DSP)来实现根据本发明实施例的打车系统服务器中的一些或者全部部件的一些或者全部功能。本发明还可以实现为用于执行这里所描述的方法的一部分或者全部的设备或者装置程序(例如,计算机程序和计算机程序产品)。这样的实现本发明的程序可以存储在计算机可读介质上,或者可以具有一个或者多个信号的形式。这样的信号可以从因特网网站上下载得到,或者在载体信号上提供,或者以任何其他形式提供。

应该注意的是上述实施例对本发明进行说明而不是对本发明进行限制,并且本领域技术人员在不脱离所附权利要求的范围的情况下可设计出替换实施例。在权利要求中,不应将位于括号之间的任何参考符号构造成对权利要求的限制。单词“包含”不排除存在未列在权利要求中的元件或步骤。位于元件之前的单词“一”或“一个”不排除存在多个这样的元件。本发明可以借助于包括有若干不同元件的硬件以及借助于适当编程的计算机来实现。在列举了若干装置的单元权利要求中,这些装置中的若干个可以是通过同一个硬件项来具体体现。单词第一、第二、以及第三等的使用不表示任何顺序。可将这些单词解释为名称。

显然,本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样,倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内,则本发明也意图包含这些改动和变型在内。

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