一种共享单车开锁方法、服务器、车锁和开锁系统与流程

本申请涉及软件技术领域，具体而言，涉及一种共享单车开锁方法、服务器、车锁和开锁系统。

背景技术：

在现有技术中，共享单车开锁的方式主要为：通过手机扫描位于共享单车身上的二维码，获得单车标识(identity,id)；手机发送携带单车id的开锁请求到后台服务器；后台服务器发送开锁指令至对应单车id的共享单车的智能车锁完成开锁，或用户获取解锁密码后，按锁具上的密码盘进行解锁。

然而，申请人发现现有技术至少存在如下缺点：一方面，若共享单车上的二维码被破坏，用户就无法通过完成扫描从而无法使用共享单车；另一方面，若用户的手机遗忘或丢失，则无法使用共享单车。

技术实现要素：

本申请的目的在于提供一种共享单车开锁方法、服务器、车锁和开锁系统，以提高共享单车在公共交通领域的使用率，以及除手机客户端使用共享单车外，提供了一种更加便利的方式。

本申请实施例提供了一种共享单车开锁的方法，共享单车上设置有读卡器，所述方法包括：

共享单车服务器接收共享单车发送的由所述读卡器获取的智能卡的卡号信息；

根据所述卡号信息，判断所述智能卡是否为与用户的应用账号绑定的绑定卡；

在确定所述智能卡为绑定卡后，确认是否开锁。

可选地，所述确认是否开锁，包括：

根据所述智能卡的卡号信息，对所述智能卡的合法性进行验证；

若未验证通过，则确认不开锁；

若验证通过，则根据所述应用账号对应的支付方式，确认是否开锁。

可选的，所述根据所述智能卡的卡号信息对所述智能卡的合法行进行验证，包括：

根据所述智能卡的卡号信息生成合法性验证请求信息；

外发所述合法性验证请求信息；

基于所述合法性验证请求信息生成的合法性验证反馈信息；

基于所述合法性验证反馈信息确定对所述智能卡的合法性验证是否通过。

可选地，所述根据所述应用账号对应的支付方式，确认是否开锁，包括：

若所述支付方式为智能卡支付，则查询所述智能卡卡号的余额信息，根据所述智能卡卡号的余额信息，确定是否开锁；

若所述支付方式为应用账号支付，则查询所述应用账号的余额信息，根据所述应用账号的余额信息，确定是否开锁。

可选的，所述查询所述智能卡卡号的余额信息包括：

基于所述智能卡的卡号信息生成智能卡余额查询请求信息；

外发所述智能卡余额查询请求信息；

接收基于所述智能卡余额查询请求信息生成的智能卡的余额信息。

可选地，所述在确定所述智能卡为绑定卡后，确认是否开锁之前，还包括：

判断所述智能卡的卡号是否存在于预先存储的白名单内，若是，则确定是否开锁。

本申请实施例还提供了一种共享单车服务器，包括：

接收模块，用于接收共享单车发送的由读卡器获取的智能卡的卡号信息；

判断模块，用于根据所述卡号信息，判断所述智能卡是否为与用户的应用账号绑定的绑定卡；

开锁确认模块，用于在确定所述智能卡为绑定卡后，确认是否开锁。

可选地，所述开锁确认模块具体用于：

根据所述智能卡的卡号信息，对所述智能卡的合法性进行验证；

若未验证通过，则确认不开锁；

若验证通过，则根据所述应用账号对应的支付方式，确认是否开锁。

可选的，所述开锁确认模块具体用于：

根据所述智能卡的卡号信息生成合法性验证请求信息；

外发所述合法性验证请求信息；

接收基于所述合法性验证请求信息生成的合法性验证反馈信息；

基于所述合法性验证反馈信息确定对所述智能卡的合法性验证是否通过。

可选地，所述开锁确认模块具体用于：

若所述支付方式为智能卡支付，则查询所述智能卡卡号的余额信息，根据所述智能卡卡号的余额信息，确定是否开锁；

若所述支付方式为应用账号支付，则查询所述应用账号的余额信息，根据所述应用账号的余额信息，确定是否开锁。

可选的，所述开锁确认模块具体用于：

基于所述智能卡卡号信息生成智能卡余额查询请求信息；

外发所述智能卡余额查询请求信息；

接收基于所述智能卡余额查询请求信息生成的所述智能卡的余额信息。

可选地，所述开锁确认模块具体用于：

所述在确定所述智能卡为绑定卡后，确认是否开锁之前，判断所述智能卡的卡号是否存在于预先存储的白名单内，若是，则确定是否开锁。

本实施例还提供了一种共享单车车锁，包括：锁本体和内置在所述锁本体内的读卡器、处理器和移动通信部件；

所述移动通信部件基于移动数据连接进行通信；

所述读卡器，用于读取智能卡的卡号信息，并将所述智能卡的卡号信息发送至所述处理器；

所述处理器，用于将所述卡号信息通过所述移动通信部件发送给共享单车服务器，以便所述共享单车服务器基于该卡号信息，执行开锁确认流程。

本实施例还提供了一种共享单车的开锁系统，该系统包括共享单车车锁和共享单车服务器。

本申请的有益效果：

本申请实施例通过在共享单车上安装读卡器来读取智能卡的卡号信息，共享单车的共享单车服务器在接收到该智能卡的卡号信息后，可以基于智能卡的卡号信息来执行开锁确认流程。本申请实施例中，用户即使忘记携带手机或丢失手机，或者共享单车二维码损坏，仍然可以通过智能卡刷卡进行开锁，从而使得用户在使用共享单车时多了一种更为便利的选择。

为使本申请的上述目的、特征和优点能更明显易懂，下文特举较佳实施例，并配合所附附图，作详细说明如下。

附图说明

为了更清楚地说明本发明实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本发明的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1示出了本申请实施例1所提供的一种共享单车开锁方法流程图；

图2示出了本申请实施例1所提供的智能卡用户注册流程图；

图3示出了本申请实施例2所提供的一种共享单车开锁方法流程图；

图4示出了本申请实施例3所提供的一种共享单车服务器结构示意图；

图5示出了本申请实施例5所提供的一种共享单车开锁系统结构示意图。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本申请实施例的组件可以以各种不同的配置来布置和设计。因此，以下对在附图中提供的本申请的实施例的详细描述并非旨在限制要求保护的本申请的范围，而是仅仅表示本申请的选定实施例。基于本申请的实施例，本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本申请保护的范围。

本申请实施例提供了一种共享单车开锁方法、开锁装置、开锁系统和车锁，用户无需使用手机来获取解锁密码，直接刷智能卡就可以使用共享单车，下面通过相关实施例对本申请思想作进一步说明。

实施例1

如图1所示，为本申请实施例一提供的共享单车开锁方法流程图，其中，共享单车上设置有读卡器，该方法包括以下步骤：

s101：共享单车服务器接收共享单车发送的由读卡器获取的智能卡的卡号信息。

此处，读卡器可以设置有移动通信部件，这样就可以直接由读卡器将获取到的智能卡的卡号信息发送至共享单车服务器，当然，读卡器也可以不设置有移动通信部件，在每次获取到智能卡的卡号信息后，将该智能卡的卡号信息发送至共享单车上车锁中，此处的车锁具有处理器和移动通信部件；或者共享单车上的车锁控制装置中，此处的车锁控制装置上设置有处理器和移动通信部件，由处理器通过移动通信部件将智能卡的卡号信息发送至共享单车服务器。

在实际实施中，共享单车除了向共享单车服务器发送卡号信息外，还会发送车锁id，以便于共享单车服务器后续在确认开锁后，为该车锁id对应的车锁开锁，或者将开锁密码发送至应用客户端。这里的智能卡可以是交通卡、智能电话卡等具有存储、付费功能的智能芯片卡。

这里，用户使用智能卡在共享单车的读卡器上进行刷卡，读卡器读取智能卡的卡号信息，然后将该卡号信息发送至共享单车服务器；这里，读卡器可以设置在车锁上，也可以与车锁分离，位于车身上的其他位置。比如，读卡器位于共享单车的车把上。

另外，在实施步骤s101之前，用户可以首先通过共享单车的客户端注册应用账号。如图2所示，用户可以在客户端中输入智能卡的卡号，并由客户端发送至共享单车服务器，共享单车服务器将该卡号发送至智能卡后台服务器进行合法性验证，若验证合法，共享单车服务器将该卡号和用户的应用账号进行绑定；确认上述绑定卡号后，共享单车服务器接收用户上传的支付方式并进行存储。这里，客户端在发送卡号信息给共享单车服务器时，可以同时发送上述应用账号。

s102：共享单车服务器根据所述卡号信息，判断所述智能卡是否为与用户的应用账号绑定的绑定卡；若是，则进入s103，若不是，则判定卡号未绑定。

这里，共享单车服务器判断智能卡是否是为与用户的应用账号绑定的绑定卡的具体实施步骤可以是：

共享单车服务器基于预先存储的已与用户的应用账号绑定的智能卡卡号列表，判断获取的卡号信息是否位于该列表中。

在实施中，若所述智能卡不是为与用户的应用账号绑定的绑定卡，此时共享单车服务器确定该智能卡不能在共享单车上刷卡使用，并可以将指示该智能卡未绑定的指示信息发送至用户客户端，客户端可以提示用户卡号未绑定，并引导用户进入注册流程。

s103：在确定所述智能卡为绑定卡后，确认是否开锁。

在步骤s103中，包括：

(1)根据智能卡的卡号信息，对智能卡的合法性进行验证。

根据智能卡的卡号信息生成合法性验证请求信息；外发合法性验证请

求信息；接收基于合法性验证请求信息生成的合法性验证反馈信息；基于合法性验证反馈信息确定对智能卡的合法性验证是否通过。

此处，共享单车服务器在接收到智能卡的卡号信息后，生成合法性验证请求信息，并将该合法性验证请求信息发送至智能卡后台服务器，智能卡后台服务器对该智能卡进行验证，并将验证结构发送至共享单车服务器，共享单车服务器会根据该验证结果确定对智能卡的合法性验证是否通过。

(2)若未验证通过，则确定不开锁。

如果确定该智能卡为非法的，则确定不开锁。

(3)若验证通过，则根据应用账号对应的支付方式，确定是否开锁。

在步骤(3)中，包括：

若支付方式为智能卡支付，则查询智能卡卡号的余额信息，根据智能

卡卡号的余额信息，确定是否开锁。

若支付方式为应用账号支付，则查询应用账号的余额信息，根据应用账号的余额信息，确定是否开锁。

其中，查询智能卡卡号的余额信息包括：基于智能卡卡号信息生成智能卡余额查询请求信息；外发智能卡余额查询请求信息；接收智能卡余额请求信息生成的智能卡的余额信息。

这里，在确定所述智能卡为绑定卡后，在确认开锁之前，共享单车服务器应确定所述智能卡的卡号是否位于存储的白名单内，若是，则执行后续的确认开锁流程；若不是，则此时共享单车服务器将指示该智能卡卡号的已被加入黑名单和/或卡号未绑定的指示信息发送至用户客户端，客户端可以提示用户卡号已被加入黑名单和/或卡号未绑定，并提示用户如何解除黑名单，和/或引导用户进入卡号注册流程。

这里,共享单车服务器可以设有白名单与黑名单，或是只设有黑名单，或是只设有白名单；比如，若某智能卡卡号信息不存于黑名单内，则此时可以默认该卡号信息存在于白名单内。比如，在锁车流程中，由于在开锁时已经确认应用账号或智能卡内的余额充足，那么若在锁车结单时余额不足，此时则说明用户在骑行过程中将卡中的余额消费，此时可以认为该用户为非善意骑行者，此时可以将该智能卡的卡号加入黑名单。再比如，若用户对共享单车使用的信用度低于设定的信用度阈值，则该用户所对应的应用账号或智能卡卡号或同时被加入黑名单。

这里，在确定所述智能卡为绑定卡且位于存储的白名单内之后，确认是否开锁时，可以自行确认，也可以通过与智能卡后台服务器进行交互来确认。另外，根据支付方式的不同，开锁确认的流程也不同。

支付方式之一：应用账号支付；

在确定所述智能卡为绑定卡后，若确定用户选择的是应用账号支付，则可以查询应用账号的余额信息，并基于该余额信息确认是否开锁，比如余额低于设定阈值，则不开锁，否则开锁。

支付方式之二：智能卡支付；

共享单车服务器可以预先与智能卡后台服务器进行交互来获取实时更新的智能卡余额信息，在确定所述智能卡为绑定卡后，若确定用户选择的是智能卡支付，可以本地查询该智能卡的余额信息，并基于该余额信息确认是否开锁。另外，共享单车服务器也可以不用预先存储智能卡余额信息，在确定所述智能卡为绑定卡后，若确定用户选择的是智能卡支付，可以通过与智能卡后台服务器进行交互，由智能卡后台服务器来查询余额信息，进而确认是否开锁。

在实际实施中，确定用户选择的是智能卡支付，智能卡后台服务器接收共享单车服务器发送的智能卡卡号信息并对该卡号信息进行验证，若该智能卡卡号信息未验证通过，则智能卡后台服务器可以将卡号非法指示信息发送至共享单车服务器，共享单车服务器确定不开锁，并将卡号非法指示信息发送至与应用账号对应的用户客户端，客户端显示信息不合法。若验证通过，则根据所述应用账号对应的支付方式，通过查询余额信息，确认是否开锁。比如可以反馈具体的余额信息(可以是具体的余额，也可以是指示余额充足或余额不足的指示信息)，或者可以直接反馈开锁指示信息或不开锁指示信息；比如若余额低于设定阈值，则不开锁，否则开锁。

在未对智能卡进行合法性验证，根据该智能卡的余额信息，确定是否开锁的情况下，则可以反馈开锁成功的指示信息，或由于该智能卡由于长期未使用处于休眠状态，则反馈请激活该智能卡的提示信息。再比如，若该智能卡余额大于设定阈值，但该智能卡由于损坏无法正常使用，则此时共享单车服务器反馈卡片无效的提示信息。

实施例2

下面以共享单车服务器通过与智能卡后台服务器进行交互来确认是否开锁为例，来说明本申请方案的一种实施方式。

如图3所示，为本申请实施例二提供的共享单车开锁方法流程图，包括以下步骤：

s301：读卡器读取智能卡的卡号信息，并发送给共享单车服务器。

此处的读卡器具有移动通信部件，可以由读卡器直接将卡号信息发送至共享单车服务器。

在实际实施中，共享单车服务器除了向读卡器发送卡号信息外，还会发送车锁id，以便于共享单车服务器后续在确认开锁后，为该车锁id对应的车锁开锁，或者将开锁密码发送至应用客户端。这里的智能卡可以是交通卡、智能电话卡等具有存储、付费功能的智能芯片卡。

这里，用户使用智能卡在共享单车的读卡器上进行刷卡，读卡器读取智能卡的卡号信息，然后将该卡号信息发送至共享单车服务器；这里，读卡器可以设置在车锁上，也可以与车锁分离，位于车身上的其他位置。比如，读卡器位于共享单车的车把上。

在执行步骤s301之前,用户可以首先通过共享单车的客户端注册应用账号。用户可以在客户端中输入智能卡的卡号，并由客户端发送至共享单车服务器，共享单车服务器将该卡号发送至智能卡后台服务器进行合法性验证，若验证合法，共享单车服务器将该卡号和用户的应用账号进行绑定；确认上述绑定卡号后，共享单车服务器接收用户上传的支付方式并进行存储。这里，客户端在发送卡号信息给共享单车服务器时，可以同时发送上述应用账号。

s302：共享单车服务器接收读卡器发送的智能卡的卡号信息，根据该卡号信息，判断所述智能卡是否为与用户的应用账号绑定的绑定卡，以及判断该卡号信息是否位于存储的白名单内，若该智能卡为绑定卡、且对应的卡号信息位于白名单内，则进入s303，否则，确定该智能卡不能在共享单车上刷卡使用。

这里,共享单车服务器可以设有白名单与黑名单，或是只设有黑名单，或是只设有白名单；比如，若某智能卡卡号信息不存于黑名单内，则此时可以默认该卡号信息存在于白名单内。

比如，在锁车流程中，由于在开锁时已经确认应用账号或智能卡内的余额充足，那么若在锁车结单时余额不足，此时则说明用户在骑行过程中将卡中的余额消费，此时可以认为该用户为非善意骑行者，此时可以将该智能卡的卡号加入黑名单。再比如，若用户对共享单车使用的信用度低于设定的信用度阈值，则该用户所对应的应用账号或智能卡卡号或同时被加入黑名单。

这里，共享单车服务器基于预先存储的已与用户的应用账号绑定的智能卡卡号列表，判断获取的卡号信息是否位于该列表中。

在具体实施中，若所述智能卡不是为与用户的应用账号绑定的绑定卡或智能卡的卡号不在白名单内，此时共享单车服务器确定该智能卡不能在共享单车上刷卡使用，则共享单车服务器将指示该智能卡未绑定或智能卡已被加入黑名单的指示信息发送至用户客户端，客户端可以提示用户卡号未绑定，并引导用户进入注册流程，或是提示用户已被加入黑名单，并提示引导用户如何解除黑名单。

s303：共享单车服务器获取与所述应用账号对应的支付方式，向所述智能卡后台服务器发送携带有卡号信息和支付方式信息的开锁验证请求。

这里，所述支付方式为智能卡支付或应用账号支付。

在实施中，共享单车服务器查询所述应用账号对应的用户选择的支付方式，并进行存储，并将预先存储的该应用账号所对应的智能卡卡号信息，一起发送至智能卡后台共享单车服务器进行验证。并根据反馈结果，确定执行后续的开锁确认流程。

s304：智能卡后台服务器接收共享单车服务器发送的开锁验证请求，首先根据所述卡号信息，以及预先存储的合法卡号列表，确定所述智能卡是否合法，并根据支付方式的不同，分别进入s305和s306的反馈过程。

这里，在具体实施中，根据所述智能卡卡号信息，以及预先存储的合法智能卡卡号列表，确定该智能卡是否合法；若非法，则智能卡后台服务器向共享单车服务器发送卡号非法指示信息，共享单车服务器将该卡号非法指示信息发送至该卡号对应的用户客户端，用户客户端显示信息不合法；若合法，则根据支付方式的不同，分别进入s305和s306的反馈过程。

s305：若支付方式为应用账号支付，向所述共享单车服务器发送卡号合法性验证结果(卡号非法指示信息或卡号合法指示信息)。

在实施中，智能卡后台服务器向共享单车服务器发送卡号合法性验证结果，若共享单车服务器接收到卡号合法指示信息，则共享单车服务器查询与智能卡的卡号绑定的应用账号的余额信息，根据余额信息，确定是否开锁，比如若该余额低于设定阈值，则不开锁，此时共享单车服务器会将余额不足或不开锁的指示信息发送至该应用账号的用户客户端，用户客户端会显示余额不足信息或是开锁失败信息。若共享单车服务器接收到卡号非法指示信息，则共享单车服务器将该卡号非法指示信息发送至应用账号对应的客户端，客户端显示信息不合法。

s306：若支付方式为智能卡支付，则查询智能卡的余额信息，根据该余额信息，反馈结果。

在实施中，若智能卡后台服务器反馈的信息为卡号合法指示信息，则智能卡后台服务器查询该智能卡的余额信息，根据余额信息，确定反馈结果，比如可以反馈具体的余额信息(可以是具体的余额，也可以是指示余额充足或余额不足的指示信息)，或者可以直接反馈开锁指示信息或不开锁指示信息；若智能卡后台服务器反馈的信息为卡号非法指示信息，则智能卡后台服务器将该卡号非法指示信息发送至共享单车服务器，共享单车服务器将再该卡号非法指示信息发送至对应账号的用户客户端，用户客户端显示信息不合法。

实施例3

如图4所示，为本申请实施例3提供的一种共享单车服务器40，用于执行实施例1中的共享单车开锁方法，其结构示意图，包括：

接收模块41，用于接收共享单车发送的由读卡器获取的智能卡的卡号信息。

判断模块42，用于根据所述卡号信息，判断所述智能卡是否为与用户的应用账号绑定的绑定卡。

开锁确认模块43，用于在确定所述智能卡为绑定卡后，确认是否开锁。

可选地，所述开锁确认模块43具体用于：

根据所述智能卡的卡号信息，对所述智能卡的合法性进行验证。

若未验证通过，则确认不开锁。

若验证通过，则根据所述应用账号对应的支付方式，确认是否开锁。

可选的，开锁确定模块43具体用于：

根据智能卡的卡号信息生成合法性验证请求信息。

外发合法性验证请求信息。

接收基于合法性验证请求信息生成的合法性验证反馈信息。

基于合法性验证反馈信息确定对所述智能卡的合法性验证是否通过。

可选地，所述开锁确认模块43具体用于：

若所述支付方式为智能卡支付，则查询所述智能卡卡号的余额信息，根据所述智能卡卡号的余额信息，确定是否开锁。

若所述支付方式为应用账号支付，则查询所述应用账号的余额信息，根据所述应用账号的余额信息，确定是否开锁。

可选的，开锁确定模块43具体用于：

基于所述智能卡卡号信息生成智能卡余额查询请求信息。

外发所述智能卡余额查询请求信息。

接收基于所述智能卡余额查询请求信息生成的所述智能卡的余额信息。

可选地，所述开锁确认模块43具体用于：

在确定所述智能卡为绑定卡后，确认是否开锁之前，判断智能卡的卡号是否存在于预先存储的白名单内，若是，则确定是否开锁。

实施例4

本申请实施例4提供了一种共享单车车锁，包括：

锁本体和内置在所述锁本体内的读卡器、处理器和移动通信部件。

移动通信部件基于移动数据连接进行通信，能够与共享单车服务器进行数据通信。

读卡器，用于读取智能卡的卡号信息，并将智能卡的卡号信息发送至处理器。

处理器，用于将卡号信息通过移动通信部件发送给共享单车服务器，以便共享单车服务器基于该卡号信息，执行开锁确认流程。

实施例5

如图5所示，为本申请实施例5提供的一种共享单车开锁系统50结构示意图，包括实施例3提供的共享单车服务器52和实施例4提供的共享单车车锁51。

共享单车车锁51，用于读取智能卡的卡号信息，将所述智能卡的卡号信息发送给共享单车的共享单车服务器52。

共享单车服务器52，用于接收读卡器发送的智能卡的卡号信息；根据所述卡号信息，判断所述智能卡是否为与用户的应用账号绑定的绑定卡；在确定所述智能卡为绑定卡后，通过与智能卡后台服务器进行交互，执行开锁确认流程。

基于同一发明构思，本申请上述实施例中提供的一种智能卡开锁系统与所述共享单车开锁方法及服务器对应，由于该系统解决问题的原理与本申请实施例智能卡卡开锁方法及装置相似，因此该系统的实施可以参见方法及装置的实施，重复之处不再赘述。

基于上述分析可知，与相关技术中的扫描车身上的二维码开锁的方法相比，本申请实施例提供的开锁方法是基于智能卡的卡号信息来执行开锁确认流程的；其中，智能卡的卡号信息是通过安装在共享单车上的读卡器来读取获得的。本申请实例中，在用户忘记携带手机或丢失手机，或是在共享单车二维码损坏的情况下，仍然可以通过智能卡刷卡开锁使用共享单车，这为用户在使用共享单车时提供了一种更为便捷的选择。

本申请实施例所提供的进行一种共享单车开锁的计算机程序产品，包括存储了程序代码的计算机可读存储介质，所述程序代码包括的指令可用于执行前面方法实施例中所述的方法，具体实现可参见方法实施例，在此不再赘述。

本申请实施例所提供的智能卡刷卡开锁的装置可以为设备上的特定硬件或者安装于设备上的软件或固件等。本申请实施例所提供的装置，其实现原理及产生的技术效果和前述方法实施例相同，为简要描述，装置实施例部分未提及之处，可参考前述方法实施例中相应内容。所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，前述描述的系统、装置和单元的具体工作过程，均可以参考上述方法实施例中的对应过程，在此不再赘述。

在本申请所提供的实施例中，应该理解到，所揭露装置和方法，可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，又例如，多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些通信接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请提供的实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。

所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：u盘、移动硬盘、只读存储器(rom，read-onlymemory)、随机存取存储器(ram，randomaccessmemory)、磁碟或者光盘等各种可以存储程序代码的介质。

应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释，此外，术语“第一”、“第二”、“第三”等仅用于区分描述，而不能理解为指示或暗示相对重要性。

最后应说明的是：以上所述实施例，仅为本申请的具体实施方式，用以说明本申请的技术方案，而非对其限制，本申请的保护范围并不局限于此，尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，其依然可以对前述实施例所记载的技术方案进行修改或可轻易想到变化，或者对其中部分技术特征进行等同替换；而这些修改、变化或者替换，并不使相应技术方案的本质脱离本申请实施例技术方案的精神和范围。都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应所述以权利要求的保护范围为准。