事故的处理方法、装置及系统与流程

本申请涉及区块链技术领域，尤其涉及一种事故的处理方法、装置及系统。

背景技术：

随着车辆的普及化，道路中的车辆不断增多，使得道路交通事故也变得越来越频繁。交通事故处理不及时的话，会严重影响道路的整体交通情况。

目前，发生交通事故后的快速处理方法为：事故双方根据现场情况进行协商，例如：协商确定事故的主次责任，并对现场进行拍照取证。然后，双方将车辆移开现场，以避免对道路交通造成长时间的影响。

然而，上述快速处理方法可能会存在不认账的问题。示例性的，事故双方将车辆移开现场后，其中一方对现场协商的内容出现反悔。这时，由于现场已被破坏，根据照片可能无法准确的对主次责任进行认定，即使是专业的交警也可能很难准确地做出判断，导致交通事故的处理效率较低。

技术实现要素：

本申请提供一种事故的处理方法、装置及系统，用以避免其中一方对协商内容出现反悔的问题，提高事故的处理效率。

第一方面，本申请提供一种事故的处理方法，包括：

第一终端从第二终端接收第一事故消息，所述第一事故消息包括：事故的标识、状态、所述第一终端对应的第一用户和所述第二终端对应的第二用户之间的责任协商信息，以及所述第二用户的签名信息；

所述第一终端在对所述第二用户的签名信息验证通过，并接收到用于指示对所述责任协商信息验证通过的验证消息时，在所述第一事故消息中添加所述第一用户的签名信息，得到第二事故消息，并将所述第二事故消息发送至事故处理设备，以使所述事故处理设备将所述第二事故消息写入区块链中。

一种可能的实现方式中，所述第一终端将所述第一事故消息发送至事故处理设备之后，所述方法还包括：

所述第一终端从所述第二终端接收第一理赔消息，所述第一理赔消息包括所述事故的标识、状态和所述第一用户和所述第二用户之间的理赔协商信息，以及所述第二用户的签名信息；

所述第一终端在对所述第二用户的签名信息验证通过，并接收到用于指示对所述理赔协商信息验证通过的验证消息时，在所述第一理赔消息中添加所述第一用户的签名信息，得到第二理赔消息，并将所述第二理赔消息发送至所述事故处理设备，以使所述事故处理设备将所述事故的理赔协商信息写入区块链中。

一种可能的实现方式中，所述第一终端将所述第二理赔消息发送至所述事故处理设备之后，还包括：

所述第一终端从保险处理设备接收第一理赔结果消息

所述第一理赔结果消息中包括所述事故的标识、状态和理赔结果信息，以及保险机构的签名信息；所述第一终端在对所述第一理赔结果消息中的所述保险机构的签名信息验证通过，并接收到用于指示对所述理赔结果信息验证通过的验证消息时，在所述第一理赔结果消息中添加所述第一用户的签名信息，得到第二理赔结果消息，并将所述第二理赔结果消息发送给所述第二终端；

或者；

所述第一终端从所述第二终端接收第二理赔结果消息，所述第二理赔结果消息是所述第二终端从所述保险处理设备接收到所述第一理赔结果消息后，在所述第一理赔结果消息中添加所述第二用户的签名信息得到的；所述第一终端在对所述第二理赔结果消息中的所述保险机构的签名信息、所述第二用户的签名信息验证通过，并接收到用于指示对所述理赔结果信息验证通过的验证消息时，在所述第二理赔结果消息中添加所述第一用户的签名信息，得到第三理赔结果消息，并将所述第三理赔结果消息发送给所述保险处理设备。

一种可能的实现方式中，所述第一终端从第二终端接收第一事故消息之前，还包括：

所述第一终端生成一对公钥和私钥，所述公钥为所述第一用户的身份信息，所述私钥用于生成所述签名信息，所述公钥用于对所述签名信息进行校验；

所述第一终端将所述私钥保存在本地，并将所述公钥发送至所述事故处理设备，以使所述事故处理设备将所述公钥写入区块链中。

第二方面，本申请提供一种事故的处理方法，包括：

事故处理设备从第一终端接收第二事故消息，所述第二事故消息是所述第一终端从所述第二终端接收到第一事故消息后，在所述第一事故消息中添加第一用户的签名信息得到的，所述第一事故消息包括事故的标识、状态、所述第一终端对应的所述第一用户与所述第二终端对应的第二用户之间的责任协商信息，以及所述第二用户的签名信息；

所述事故处理设备对所述第二事故消息中的所述第一用户的签名信息和所述第二用户的签名信息进行验证，并在验证结果为通过时，通过共识协议将所述第二事故消息写入区块链中。

一种可能的实现方式中，所述事故处理设备通过共识协议将所述第二事故消息写入区块链中之后，所述方法还包括：

所述事故处理设备针对所述第二事故消息执行纠纷校验合约，所述纠纷校验合约用于对所述第一用户的签名信息、所述第二用户的签名信息以及所述责任协商信息进行校验；

在所述纠纷校验合约的执行结果指示所述第二事故消息有效时，所述事故处理设备将所述第二事故消息中的事故的状态修改为责任协商完成，得到第三事故消息，并通过共识协议将所述第三事故消息写入区块链中。

一种可能的实现方式中，所述事故处理设备通过共识协议将所述第三事故消息写入区块链中之后，还包括：

所述事故处理设备从所述第一终端接收第二理赔消息，所述第二理赔消息是所述第一终端从所述第二终端接收到第一理赔消息后，在所述第一理赔消息中添加第一用户的签名信息得到的，所述第一理赔消息包括事故的标识、状态、所述第一用户与所述第二用户之间的理赔协商信息，以及所述第二用户的签名信息；

所述事故处理设备对所述第二理赔消息中的所述第一用户的签名信息和所述第二用户的签名信息进行验证，并在验证结果为通过时，通过共识协议将所述第二理赔消息写入区块链中。

一种可能的实现方式中，所述事故处理设备通过共识协议将所述第二理赔消息写入区块链中之后，还包括：

所述事故处理设备针对所述第二理赔消息执行理赔校验合约，所述理赔校验合约用于对所述第一用户的签名信息、所述第二用户的签名信息以及所述理赔协商信息进行校验；

在所述理赔校验合约的执行结果指示所述第二理赔消息有效时，所述事故处理设备将所述第二理赔消息中的事故的状态修改为理赔协商完成，得到第三理赔消息，并将所述第三理赔消息发送给保险处理设备，以使所述保险处理设备根据所述第三理赔消息，向所述第一终端和/或所述第二终端发送第一理赔结果消息，所述第一理赔结果消息中包括所述事故的标识、状态和理赔结果信息，以及保险机构的签名信息。

一种可能的实现方式中，所述事故处理设备将所述第三理赔消息发送给保险处理设备之后，还包括：

所述事故处理设备从所述保险处理设备接收第三理赔结果消息，并对所述第三理赔结果消息中的所述保险机构的签名信息、所述第一用户的签名信息和所述第二用户的签名信息进行验证，在验证结果为通过时，通过共识协议将所述第三理赔结果消息写入区块链中；

所述事故处理设备针对所述第三理赔结果消息，执行理赔结果校验合约，所述理赔结果校验合约用于对所述保险机构的签名信息、所述第一用户的签名信息和所述第二用户的签名信息进行校验；

在所述理赔结果校验合约的执行结果指示所述第三理赔结果消息有效时，所述事故处理设备将所述第三理赔结果消息中的事故的状态修改为理赔完成，得到第四理赔结果消息，并通过共识协议将所述第四理赔结果消息写入区块链中。

一种可能的实现方式中，所述事故处理设备从第一终端接收第二事故消息之前，还包括：

所述事故处理设备从所述第一终端接收公钥，所述公钥为所述第一用户的身份信息；

所述事故处理设备对所述公钥进行验证，并在验证结果为通过时，通过共识协议将所述公钥写入区块链中。

第三方面，本申请提供一种事故的处理装置，包括：

接收模块，用于从第二终端接收第一事故消息，所述第一事故消息包括：事故的标识、状态、所述第一终端对应的第一用户和所述第二终端对应的第二用户之间的责任协商信息，以及所述第二用户的签名信息；

处理模块，用于在对所述第二用户的签名信息验证通过，并接收到用于指示对所述责任协商信息验证通过的验证消息时，在所述第一事故消息中添加所述第一用户的签名信息，得到第二事故消息；

发送模块，用于将所述第二事故消息发送至事故处理设备，以使所述事故处理设备将所述第二事故消息写入区块链中。

一种可能的实现方式中，所述接收模块还用于从所述第二终端接收第一理赔消息，所述第一理赔消息包括所述事故的标识、状态和所述第一用户和所述第二用户之间的理赔协商信息，以及所述第二用户的签名信息；

所述处理模块还用于在对所述第二用户的签名信息验证通过，并接收到用于指示对所述理赔协商信息验证通过的验证消息时，在所述第一理赔消息中添加所述第一用户的签名信息，得到第二理赔消息；

所述发送模块还用于将所述第二理赔消息发送至所述事故处理设备，以使所述事故处理设备将所述事故的理赔协商信息写入区块链中。

一种可能的实现方式中，所述接收模块还用于从保险处理设备接收第一理赔结果消息，所述第一理赔结果消息中包括所述事故的标识、状态和理赔结果信息，以及保险机构的签名信息；所述处理模块还用于在对所述第一理赔结果消息中的所述保险机构的签名信息验证通过，并接收到用于指示对所述理赔结果信息验证通过的验证消息时，在所述第一理赔结果消息中添加所述第一用户的签名信息，得到第二理赔结果消息；所述发送模块还用于将所述第二理赔结果消息发送给所述第二终端；

或者，

所述接收模块还用于从所述第二终端接收第二理赔结果消息，所述第二理赔结果消息是所述第二终端从所述保险处理设备接收到所述第一理赔结果消息后，在所述第一理赔结果消息中添加所述第二用户的签名信息得到的；所述处理模块还用于在对所述第二理赔结果消息中的所述保险机构的签名信息、所述第二用户的签名信息验证通过，并接收到用于指示对所述理赔结果信息验证通过的验证消息时，在所述第二理赔结果消息中添加所述第一用户的签名信息，得到第三理赔结果消息；所述发送模块还用于将所述第三理赔结果消息发送给所述保险处理设备。

一种可能的实现方式中，所述处理模块还用于生成一对公钥和私钥，所述公钥为所述第一用户的身份信息，所述私钥用于生成所述签名信息，所述公钥用于对所述签名信息进行校验；

所述处理模块还用于将所述私钥保存在本地；

所述发送模块还用于将所述公钥发送至所述事故处理设备，以使所述事故处理设备将所述公钥写入区块链中。

第四方面，本申请提供一种事故的处理装置，包括：

接收模块，用于从第一终端接收第二事故消息，所述第二事故消息是所述第一终端从所述第二终端接收到第一事故消息后，在所述第一事故消息中添加第一用户的签名信息得到的，所述第一事故消息包括事故的标识、状态、所述第一终端对应的所述第一用户与所述第二终端对应的第二用户之间的责任协商信息，以及所述第二用户的签名信息；

处理模块，用于对所述第二事故消息中的所述第一用户的签名信息和所述第二用户的签名信息进行验证，并在验证结果为通过时，通过共识协议将所述第二事故消息写入区块链中。

一种可能的实现方式中，所述处理模块还用于：

针对所述第二事故消息执行纠纷校验合约，所述纠纷校验合约用于对所述第一用户的签名信息、所述第二用户的签名信息以及所述责任协商信息进行校验；在所述纠纷校验合约的执行结果指示所述第二事故消息有效时，将所述第二事故消息中的事故的状态修改为责任协商完成，得到第三事故消息，并通过共识协议将所述第三事故消息写入区块链中。

一种可能的实现方式中，所述接收模块还用于从所述第一终端接收第二理赔消息，所述第二理赔消息是所述第一终端从所述第二终端接收到第一理赔消息后，在所述第一理赔消息中添加第一用户的签名信息得到的，所述第一理赔消息包括事故的标识、状态、所述第一用户与所述第二用户之间的理赔协商信息，以及所述第二用户的签名信息；

所述处理模块还用于对所述第二理赔消息中的所述第一用户的签名信息和所述第二用户的签名信息进行验证，并在验证结果为通过时，通过共识协议将所述第二理赔消息写入区块链中。

一种可能的实现方式中，所述处理模块还用于：

针对所述第二理赔消息执行理赔校验合约，所述理赔校验合约用于对所述第一用户的签名信息、所述第二用户的签名信息以及所述理赔协商信息进行校验；在所述理赔校验合约的执行结果指示所述第二理赔消息有效时，所述事故处理设备将所述第二理赔消息中的事故的状态修改为理赔协商完成，得到第三理赔消息；

所述装置还包括：发送模块，用于：将所述第三理赔消息发送给保险处理设备，以使所述保险处理设备根据所述第三理赔消息，向所述第一终端和/或所述第二终端发送第一理赔结果消息，所述第一理赔结果消息中包括所述事故的标识、状态和理赔结果信息，以及保险机构的签名信息。

一种可能的实现方式中，所述接收模块还用于从所述保险处理设备接收第三理赔结果消息；

所述处理模块还用于：对所述第三理赔结果消息中的所述保险机构的签名信息、所述第一用户的签名信息和所述第二用户的签名信息进行验证，在验证结果为通过时，通过共识协议将所述第三理赔结果消息写入区块链中；针对所述第三理赔结果消息，执行理赔结果校验合约，所述理赔结果校验合约用于对所述保险机构的签名信息、所述第一用户的签名信息和所述第二用户的签名信息进行校验；在所述理赔结果校验合约的执行结果指示所述第三理赔结果消息有效时，将所述第三理赔结果消息中的事故的状态修改为理赔完成，得到第四理赔结果消息，并通过共识协议将所述第四理赔结果消息写入区块链中。

一种可能的实现方式中，所述接收模块还用于从所述第一终端接收公钥，所述公钥为所述第一用户的身份信息；

所述处理模块还用于对所述公钥进行验证，并在验证结果为通过时，通过共识协议将所述公钥写入区块链中。

第五方面，本申请提供一种终端，包括：存储器、处理器以及计算机程序，所述计算机程序存储在所述存储器中，所述处理器运行所述计算机程序执行如第一方面任一项所述的方法。

第六方面，本申请提供一种事故处理设备，包括：存储器、处理器以及计算机程序，所述计算机程序存储在所述存储器中，所述处理器运行所述计算机程序执行如第二方面任一项所述的方法。

第七方面，本申请提供一种计算机可读存储介质，其特征在于，所述计算机可读存储介质包括计算机程序，所述计算机程序被处理器执行时实现如第一方面任一项所述的方法，或者，如第二方面任一项所述的方法。

第八方面，本申请提供一种事故处理系统，包括：如第五方面任一项所述的终端，以及如第六方面任一项所述的事故处理设备。

本申请提供的事故的处理方法、装置及系统，第一终端从第二终端接收第一事故消息，第一事故消息中包括：事故的标识、状态、第一用户和第二用户之间的责任协商信息，以及第二用户的签名信息；第一终端在对第二用户的签名信息验证通过，并接收到用于指示对责任协商信息验证通过的验证消息时，在所述第一事故消息中添加所述第一用户的签名信息，得到第二事故消息，并将所述第二事故消息发送至事故处理设备，从而事故处理设备通过共识协议将第二事故消息写入区块链中。通过上述过程，完成了事故双方的纠纷协商过程。该过程中，通过第一终端、第二终端、事故处理设备之间的交互，采用一方发送数据、多方签名的方式，将最终三方签名确认的责任协商信息写入区块链数据库中。可有效解决现有技术中其中一方反悔的问题，提高事故处理的效率。另外，由于责任协商信息是存储在分布式的区块链数据库中，能够防止数据被篡改，使得事故处理过程更加透明。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为本申请实施例适用的一种应用场景示意图；

图2为本申请一个实施例提供的事故的处理方法的交互示意图；

图3a为本申请一个实施例提供的第一事故消息的示意图；

图3b为本申请一个实施例提供的事故标识的示意图；

图3c为本申请一个实施例提供的责任协商信息的示意图；

图3d为本申请一个实施例提供的第二事故消息的示意图；

图3e为本申请一个实施例提供的第三事故消息的示意图；

图4为本申请一个实施例提供的事故的处理方法的交互示意图；

图5为本申请一个实施例提供的终端注册过程的交互示意图；

图6为本申请一个实施例提供的事故处理装置的结构示意图；

图7为本申请一个实施例提供的终端的结构示意图；

图8为本申请一个实施例提供的事故处理设备的结构示意图。

具体实施方式

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

本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”“第四”等(如果存在)是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例例如能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

如前所述，目前发生交通事故后的快速处理方法为：事故双方根据现场情况进行协商，例如：协商确定事故的主次责任，并对现场进行拍照取证。然后，双方将车辆移开现场，以避免对道路交通造成长时间的影响。然而，上述快速处理方法可能会存在不认账的问题。例如：事故双方将车辆移开现场后，其中一方对现场协商的内容出现反悔。这时，由于现场已被破坏，根据照片可能无法准确的对主次责任进行认定，即使是专业的交警也可能很难准确地做出判断，导致交通事故的处理效率较低。

为了解决上述问题，本申请实施例提供一种基于区块链的事故处理方法，通过将事故双方的协商信息记录到区块链的数据库中，能够避免其中一方对协商信息反悔的问题，提高了事故处理效率。下面结合图1的应用场景对事故处理系统进行介绍。

图1为本申请实施例适用的一种应用场景示意图。如图1所示，示例了第一车辆和第二车辆发生交通事故的场景。假设第一车辆的用户对应的终端为第一终端，第二车辆的用户对应的终端为第二终端。本实施例中，事故处理系统包括：第一终端、第二终端和事故处理设备。其中，第一终端、第二终端和事故处理设备均作为区块链网络中的节点。本实施例将事故现场和区块链结合在一起，示例性的，结合图1所示的场景，第一车辆和第二车辆发生交通事故后，在保留事故现场的情况下，事故双方根据事故现场进行责任协商和/或理赔协商，采用本实施例的事故处理方法，通过第一终端、第二终端与事故处理设备之间的交互过程，将事故双方之间的协商内容写入区块链的数据库中。然后，可以将第一车辆和第二车辆移开现场，以避免对道路交通产生长时间的影响。由于事故双方的协商内容已保存至区块链数据库中，能够避免其中一方反悔的问题，提高事故处理效率。

本实施例所述的区块链，具体可指由多个节点组成的、通过共识机制达成的、分布式存储的p2p网络系统。区块链中的每个节点都存储有一个数据库(账本)，每个数据库包括一个个区块(block)，后一个区块包含前一个区块的数据摘要。各节点之间根据具体的共识机制(例如pow、pos、dpos或pbft等)的不同，达成全部或部分节点的数据备份。由于区块链系统在共识机制下运行，已收录至区块链数据库内的数据很难被节点篡改。例如，采用pow共识的区块链，至少需要全网51％的攻击才有可能篡改已有数据，因此，区块链系统与其他中心化系统相比，具有数据安全性高、防攻击篡改的特性。由此可知，本实施例中通过将事故双方的协商数据保存入区块链的分布式数据库中，能够保证数据不被篡改，从而避免其中一方反悔的问题，提高了事故处理效率。

进一步的，一种可能的应用场景中，如图1所示，本实施例的事故处理系统还可以包括：保险处理设备。保险处理设备也作为区块链网络中的一个节点。通过第一终端、第二终端、事故处理设备与保险处理设备之间的交互过程，能够完成事故理赔处理流程，进一步提高事故处理效率。

需要说明的是，本实施例提供的事故处理系统，可应用于任意事故现场，包括但不限于：交通事故、生产事故、医疗事故等。为了描述方便，本实施例中仅为交通事故为例进行举例说明。

下面以具体地实施例对本申请的技术方案进行详细说明。下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例不再赘述。

图2为本申请一个实施例提供的事故的处理方法的交互示意图。本实施例的方法，可应用于发生事故的场景中，其中，该事故可以为两方事故，还可以为多方事故，本实施例对此不作限定。为了描述方便，本实施例中仅以两方事故为例进行举例说明。如图2所示，本实施例的方法，包括：

s201：第二终端生成第一事故消息，所述第一事故消息包括：事故的标识、状态、责任协商信息，以及第二用户的签名信息。

本实施例以图1所示的交通事故场景为例进行描述。假设两个车辆发生交通事故，将其中的任意一个车辆称为第一车辆，另外一个车辆称为第二车辆。第一车辆对应的用户称为第一用户，第一用户的终端称为第一终端，第二车辆对应的用户称为第二用户，第二用户的终端称为第二终端。第一终端和第二终端可以为用户的手持终端或者车载终端。

在交通事故的现场，第一用户和第二用户根据现场情况，自主进行责任协商，例如：确定主次责任、拍摄现场照片等。协商完成后，第二终端根据协商内容生成第一事故消息。其中，第二终端可以为事故中的任意一方对应的终端，也就是说，本实施例中，可以由任一方发起责任协商流程。为了描述方便，图2所示的实施例中以第二终端发起责任协商流程为例进行描述。图3a为本申请一个实施例提供的第一事故消息的示意图。如图3a所示，第一事故消息包括：事故的标识、状态、责任协商信息，以及第二用户的签名信息。

其中，事故的标识用于唯一标识一个事故。图3b为本申请一个实施例提供的事故标识的示意图。作为一种可能的实施方式，如图3b所示，事故的标识可以采用“身份标识1”+“事故发生时间”+“身份标识2”的方式表示。其中，两个身份标识分别为第一用户和第二用户的身份标识，例如，“身份标识1”为第一用户的身份证号码，“身份标识2”为第二用户的身份证号码。事故发生时间可以精确到日，还可以精确到小时或者分钟。

事故的责任协商信息是指事故双方针对主次责任协商确定的内容。图3c为本申请一个实施例提供的责任协商信息的示意图。作为一种可能的实施方式，如图3c所示，责任协商信息中可以具体记录主要责任方对应的身份标识以及次要责任方对应的身份标识。参见图3，责任协商信息中记录了主责方的身份标识和次责方的身份标识。可选的，在多方事故(例如三方事故或四方事故等)的场景中，责任协商信息中还可以记录多个次责方的身份标识(例如图3中以两个次责方为例，分别记录为次责方和次责2方的身份标识)。可选的，责任协商信息中还可以记录用于确定主次责任的其他信息，例如：现场照片、行车记录影像、录音等。

事故的状态是指事故当前处于的状态。本实施例中，第一事故消息中携带的事故的状态用于指示事故处于责任协商中。示例性的，可以采用不同的数字或者符合来表示不同的状态。在后续的交互过程中，第二终端以及事故处理设备可以根据对消息的验证情况，对事故的状态进行更新。

s202：第二终端将所述第一事故消息发送给第一终端。

其中，第二终端可以将第一事故消息在区块链网络中进行广播，从而，第一终端接收到第一事故消息。

s203：第一终端在对所述第二用户的签名信息验证通过，并接收到用于指示对所述责任协商信息验证通过的验证消息时，在所述第一事故消息中添加所述第一用户的签名信息，得到第二事故消息。

具体的，第一终端从第二终端接收到第一事故消息后，对第一事故消息中的签名信息进行验证，该过程也可以称为“验签”。并且，第一终端对应的第一用户判断第一事故消息中的责任协商信息是否与事故双方协商结果一致，若不一致，则事故双方重新进行协商；若一致，则第一终端在接收到第一用户输入的用于指示对责任协商信息验证通过的验证消息时，在第一事故消息中添加第一用户的签名信息，得到第二事故消息。示例性的，图3d为本申请一个实施例提供的第二事故消息的示意图，如图3d所示，第二事故消息中包括了第一用户和第二用户的签名信息，说明第二事故消息中的责任协商信息已得到事故双方的签名确认。

s204：第一终端将所述第二事故消息发送至事故处理设备。

具体的，第一终端得到第二事故消息后，将第二事故消息在区块链网络中进行广播，使得事故处理设备接收到第二事故消息。

s205：事故处理设备对所述第二事故消息中的所述第一用户的签名信息和所述第二用户的签名信息进行验证，并在验证结果为通过时，通过共识协议将所述第二事故消息写入区块链中。

事故处理设备接收到如图3d所示的第二事故消息后，对第二事故消息中的第一用户的签名信息和第二用户的签名信息进行验证(即验签)。在验签通过后，通过共识协议将第二事故消息写入区块链中。这样，第二事故消息被存储到了各个节点对应的区块链数据库(即各个节点对应的账本)中。

其中，本实施例对于区块链网络中的共识协议不作具体限定，可以采用现有的共识协议。

s206：事故处理设备针对所述第二事故消息执行纠纷校验合约，在所述纠纷校验合约的执行结果指示所述第二事故消息有效时，所述事故处理设备将所述第二事故消息中的事故的状态修改为责任协商完成，得到第三事故消息，并通过共识协议将所述第三事故消息写入区块链中。

本实施例中，事故处理设备通过共识协议将第二事故消息写入区块链中之后，自动触发纠纷校验合约。纠纷校验合约为部署在区块链网络中的一种智能合约。其中，所述纠纷校验合约用于对所述第一用户的签名信息、所述第二用户的签名信息以及所述责任协商信息进行校验。也就是说，纠纷校验合约需要验证是否包括事故双方的的签名信息，以及签名信息是否正确，并且，还要验证其中的责任协商信息是否合法，例如，是否符合预设的合约规则。

在纠纷校验合约验证完成后，纠纷校验合约会自动在第二事故消息中添加纠纷校验合约的签名信息。可选的，纠纷校验合约验证完成后，可以自动将校验结果推送给第一终端和第二终端，以使第一终端和第二终端获知校验结果。

若验证结果正确，则事故处理设备对事故的状态进行更新，例如，将事故的状态修改为“责任协商完成”，得到第三事故消息。图3e为本申请一个实施例提供的第三事故消息的示意图。如图3e所示，与图3d所示的第二事故消息相比，增加了“更新后的状态”字段以及“纠纷校验合约的签名信息”字段。进而，事故处理设备通过共识协议将第三事故消息写入区块链中，这样，经过三方(第一用户、第二用户、纠纷校验合约)签名确认的第三事故消息被存储到了各个节点对应的区块链数据库(即各个节点对应的账本)中。

本实施例提供的事故的处理方法，包括：第一终端从第二终端接收第一事故消息，第一事故消息中包括：事故的标识、状态、第一用户和第二用户之间的责任协商信息，以及第二用户的签名信息；第一终端在对第二用户的签名信息验证通过，并接收到用于指示对责任协商信息验证通过的验证消息时，在所述第一事故消息中添加所述第一用户的签名信息，得到第二事故消息，并将所述第二事故消息发送至事故处理设备，从而事故处理设备通过共识协议将第二事故消息写入区块链中。通过上述过程，完成了事故双方的纠纷协商过程。该过程中，通过第一终端、第二终端、事故处理设备之间的交互，采用一方发送数据、多方签名的方式，将最终三方签名确认的责任协商信息写入区块链数据库中。可有效解决现有技术中其中一方反悔的问题，提高事故处理的效率。另外，由于责任协商信息是存储在分布式的区块链数据库中，能够防止数据被篡改，使得事故处理过程更加透明。

图2和图3所示的实施例描述的是事故的责任纠纷的处理过程，类似的，对于事故的理赔过程，同样可以采用类似的过程进行处理。下面结合图4描述事故的理赔处理过程。

图4为本申请一个实施例提供的事故的处理方法的交互示意图。如图4所示，本实施例的方法，包括：

s401：第二终端生成第一理赔消息，所述第一理赔消息包括：事故的标识、状态、理赔协商信息，以及第二用户的签名信息。

示例性的，事故双方针对理赔方式进行协商后，由其中一个终端发起理赔流程。以第二终端为例，第二终端生成第一理赔消息，第一理赔消息中包括事故的标识、状态、理赔协商信息，以及第二用户的签名信息。其中，第一理赔消息的格式与第一事故消息的格式类似，此处不作赘述。理赔协商信息是指事故双方针对理赔流程协商的内容，包括但不限于：保单号、理赔方式等。所述状态用于指示所述事故处于理赔协商中。

s402：第二终端将所述第一理赔消息发送给第一终端。

s403：第一终端在对所述第二用户的签名信息验证通过，并接收到用于指示对所述理赔协商信息验证通过的验证消息时，在所述第一理赔消息中添加所述第一用户的签名信息，得到第二理赔消息。

s404：第一终端将所述第二理赔消息发送至事故处理设备。

s405：事故处理设备对所述第二理赔消息中的所述第一用户的签名信息和所述第二用户的签名信息进行验证，并在验证结果为通过时，通过共识协议将所述第二理赔消息写入区块链中。

s406：事故处理设备针对所述第二理赔消息执行理赔校验合约，在所述理赔校验合约的执行结果指示所述第二理赔消息有效时，所述事故处理设备将所述第二理赔消息中的事故的状态修改为理赔协商完成，得到第三理赔消息。

其中，所述理赔校验合约用于对所述第一用户的签名信息、所述第二用户的签名信息以及所述理赔协商信息进行校验。也就是说，理赔校验合约需要校验第二理赔消息中是否携带事故双方的签名信息，以及签名信息是否正确，并校验其中的理赔协商信息是否合法，例如，保单号是否合法等。

需要说明的是，本实施例中s401至s406的具体执行过程与图2所示的实施例类似，此处不再赘述。

s407：事故处理设备将所述第三理赔消息发送给保险处理设备。

本实施例中，保险处理设备为保险系统对应的设备，用于处理事故双方的理赔事宜。事故处理设备将经过第一用户和第二用户签名确认的第三理赔消息发送给保险处理设备，以通知保险机构开始处理理赔事宜。相应的，如图4所示，保险处理设备接收到第三理赔消息后，还可以向事故处理设备发送通知消息，进而，事故处理设备还可以将该通知消息转发给第一终端和第二终端，使得第一终端和第二终端获知到保险机构已开始处理该理赔事宜。

实际应用中，理赔处理过程可以是由保险处理设备执行，还可以是由保险机构的工作人员执行，例如，保险机构的工作人员与第一用户和第二用户取得联系，确认理赔事宜，生成理赔结果信息。

s408：保险处理设备根据所述第三理赔消息，生成第一理赔结果消息，所述第一理赔结果消息中包括所述事故的标识、状态和理赔结果信息，以及保险机构的签名信息。

其中，所述状态用于指示所述事故处于理赔处理中。

s409：保险处理设备向第一终端和/或第二终端发送第一理赔结果消息。

本实施例中，保险处理设备根据第三理赔消息中携带的理赔协商信息，生成理赔结果信息。当然，理赔处理过程还可以是由保险机构的工作人员执行，例如，保险机构的工作人员与第一用户和第二用户取得联系，确认理赔事宜，并生成理赔结果信息。

进一步的，保险处理设备生成理赔结果信息后，需要将理赔结果信息发送给第一终端和/或第二终端进行签名确认。示例性的，保险处理设备生成第一理赔结果消息，第一理赔结果消息中包括事故的标识、状态、理赔结果信息。其中，第一理赔结果消息的格式与第一事故消息的格式类似，此处不再赘述。

本实施例中，理赔结果的协商过程可以有多种，包括但不限于下述的几种可能的实施方式。

第一种协商方式中，保险处理设备生成第一理赔结果消息后，可以将第一理赔结果消息发送给第一终端，由第一终端先签名确认，生成第二理赔结果消息，再由第一终端将第二理赔结果消息发送给第二终端进行签名确认，生成第三理赔消息；然后，再由第二终端将第三理赔消息发送给保险处理设备。

第二种协商方式中，保险处理设备生成第一理赔结果消息后，可以将第一理赔结果消息发送给第二终端，由第二终端先签名确认，生成第二理赔结果消息，再由第二终端将第二理赔结果消息发送给第一终端进行签名确认，生成第三理赔消息；然后，再由第一终端将第三理赔消息发送给保险处理设备。

第三种协商方式中，保险处理设备生成第一理赔结果消息后，可以将第一理赔结果消息分别发送给第一终端和第二终端。然后，由第二终端先签名确认，生成第二理赔结果消息，再由第二终端将第二理赔结果消息发送给第一终端。这样，第一终端会从保险处理设备接收到第一理赔结果消息，并从第二终端接收到第二理赔结果消息，第一终端可以根据第一理赔结果消息，对第二理赔结果消息进行签名确认，生成第三理赔消息；然后，再由第一终端将第三理赔消息发送给保险处理设备。

第四种协商方式中，保险处理设备生成第一理赔结果消息后，可以将第一理赔结果消息分别发送给第一终端和第二终端。然后，由第一终端先签名确认，生成第二理赔结果消息，再由第一终端将第二理赔结果消息发送给第二终端。这样，第二终端会从保险处理设备接收到第一理赔结果消息，并从第一终端接收到第二理赔结果消息，第二终端可以根据第一理赔结果消息，对第二理赔结果消息进行签名确认，生成第三理赔消息；然后，再由第二终端将第三理赔消息发送给保险处理设备。

另外，上述各种协商方式中，可以由第一终端先签名确认，还可以由第二终端先签名确认。保险处理设备在生成第一保险理赔结果消息时，还可以将签名确认的顺序携带第一理赔结果消息中，这样，各终端接收到第一理赔结果消息后，根据其中携带的签名确认的顺序进行协商。

本实施例的s410至s413，是以上述的第三种协商方式为例进行描述的，其他协商方式的协商过程是类似的。

s410：第二终端在对所述第一理赔结果消息中的保险机构的签名信息验证通过，并接收到用于指示对理赔结果信息验证通过的验证消息时，在第一理赔结果消息中添加第二用户的签名信息，得到第二理赔结果消息。

s411：第二终端将第二理赔结果消息发送给第一终端。

具体的，第二终端接收到第一理赔结果消息后，对第一理赔结果消息中的保险机构的签名信息进行验证，并且由第二用户判断其中的理赔结果信息是否与事故双方协商的理赔信息一致。若一致，则在第二终端接收到第二用户输入的用于指示对理赔结果信息验证通过的验证消息时，在第一理赔结果消息中添加第二用户的签名信息，得到第二理赔结果消息，并将第二理赔结果消息发送给第一终端。

s412：第一终端在对所述第二理赔结果消息中的所述保险机构的签名信息、所述第二用户的签名信息验证通过，并接收到用于指示对所述理赔结果信息验证通过的验证消息时，在所述第二理赔结果消息中添加所述第一用户的签名信息，得到第三理赔结果消息。

s413：第一终端将所述第三理赔结果消息发送给保险处理设备。

本实施例中，第一终端会从保险处理设备接收到第一理赔结果消息，还会从第二终端接收到第二理赔结果消息。第二终端对接收到的两个理赔结果消息进行验签，并且，第一用户判断这两个理赔结果消息中的理赔结果信息是否与事故双方协商的理赔信息一致。若一致，则在第一终端接收到第一用户输入的用于指示对理赔结果信息验证通过的验证消息时，在第二理赔消息中添加第一用户的签名信息，得到第三理赔结果消息，并将第三理赔结果消息发送给保险处理设备。

s414：保险处理设备对所述第三理赔结果消息进行验证后发送给事故处理设备。

具体的，保险处理设备接收到第三理赔结果消息后，对所述第三理赔结果消息中的所述第一用户的签名信息、所述第二用户的签名信息、所述保险机构的签名信息以及理赔结果信息进行验证。也就是说，验证第三理赔结果消息中是否携带三方的签名信息，并且签名信息是否正确；并且，验证其中的理赔结果信息是否与自己生成的理赔结果信息一致。若上述验证通过，则保险处理设备将第三理赔结果消息发送给事故处理设备。

s415：事故处理设备对所述第三理赔结果消息中的所述保险机构的签名信息、所述第一用户的签名信息和所述第二用户的签名信息进行验证，在验证结果为通过时，通过共识协议将所述第三理赔结果消息写入区块链中。

s416：事故处理设备针对所述第三理赔结果消息，执行理赔结果校验合约，在所述理赔结果校验合约的执行结果指示所述第三理赔结果消息有效时，所述事故处理设备将所述第三理赔结果消息中的事故的状态修改为理赔完成，得到第四理赔结果消息，并通过共识协议将所述第四理赔结果消息写入区块链中。

本实施例中，事故处理设备通过共识协议将第三理赔结果消息写入区块链之后，自动触发执行理赔结果校验合约。其中，所述理赔结果校验合约用于对所述保险机构的签名信息、所述第一用户的签名信息和所述第二用户的签名信息进行校验。

另外，理赔结果校验合约执行完成后，还可以将执行结果推送给第一终端、第二终端和保险处理设备，以使上述三方获取理赔处理的结果。在理赔结果校验合约的执行结果为有效的情况下，事故处理设备将第三理赔结果消息中的事故的状态修改为理赔完成，得到第四理赔结果消息，并通过共识协议将第四理赔结果消息写入区块链中。这样，事故的理赔结果被记录到各个节点对应的区块链数据库中。

本实施例提供的事故的处理方法，通过将区块链系统与事故管理系统、保险系统结合起来，实现了事故的纠纷协商、理赔协商的完整处理流程。通过第一终端、第二终端、事故处理设备、保险处理设备之间的交互，采用一方发送数据、多方签名的方式，将最终多方签名确认的协商信息写入区块链数据库中。可有效解决现有技术中其中一方反悔的问题，提高事故处理的效率。另外，由于协商信息是存储在分布式的区块链数据库中，能够防止数据被篡改，使得事故处理过程更加透明。

上述图2和图4所示的实施例中，每个节点在接收到其他节点发送的消息时，都会对消息中的签名信息进行验证。其中，对签名信息进行验证的过程可以理解为对用户的身份信息进行验证的过程。本实施例为了实现验签过程，事先将用户的身份信息写入区块链中。

图5为本申请一个实施例提供的终端注册过程的交互示意图。本实施例的方法可以在图2和图4所示实施例之前执行。如图5所示，本实施例的方法包括：

s501：终端生成以用户的身份信息为公钥的一对公钥和私钥。

其中，本实施例中的终端可以为第一终端或第二终端，即，每个终端均可以通过执行图5所示的方法，注册到区块链系统中。

示例性的，终端可以采用密钥算法生成一对公钥和私钥。公钥为用户的身份信息。例如，假设n为用户的身份证号码，则可以将用户的身份信息f(n)作为公钥。

s502：终端将所述公钥发送至事故处理设备。

s503：事故处理设备对所述公钥进行验证，并在验证结果为通过时，通过共识协议将所述公钥写入区块链中。

s504：终端将所述私钥保存在本地。

本实施例中，终端将用户的身份信息(即公钥)发送给事故处理设备，事故处理设备对用户的身份信息进行验证，确定用户身份信息的真实性。在验证通过时，通过共识协议将用户的身份信息写入区块链中。这样，各个节点在进行验签时，均可以通过区块链数据库获取用户的身份信息，利用该身份信息对消息中的签名信息进行验证。

在公钥入链后，终端将对应的私钥保存在本地。示例性的，终端将私钥存储在终端钱包，后续在需要进行签名时，使用该私钥生成签名信息。

以第二终端向第一终端发送第一事故消息为例，第二终端在第一事故消息中携带第二用户的签名信息，其中，第二用户的签名信息是根据第二用户的私钥生成的。第一终端接收到第一事故消息时，可以从区块链数据库中获取第二用户的公钥，根据第二用户的公钥对第一事故消息中的签名信息进行验证。

本实施例中，通过将用户的身份信息作为公钥，并将公钥上传到区块链数据库中，用于在后续交互流程中进行验签，能够使得后续交互流程的身份验证过程更加快速和方便。

图6为本申请一个实施例提供的事故处理装置的结构示意图。如图6所示，本实施例的事故处理装置可以设置于第一终端中，还可以设置于事故处理设备中。如图6所示，本实施例的事故处理装置600，包括：接收模块601、处理模块602和发送模块603。

当事故处理装置600应用于第一终端中时，接收模块601，用于从第二终端接收第一事故消息，所述第一事故消息包括：事故的标识、状态、所述第一终端对应的第一用户和所述第二终端对应的第二用户之间的责任协商信息，以及所述第二用户的签名信息，所述状态用于指示所述事故处于责任协商中；

处理模块602，用于在对所述第二用户的签名信息验证通过，并接收到用于指示对所述责任协商信息验证通过的验证消息时，在所述第一事故消息中添加所述第一用户的签名信息，得到第二事故消息；

发送模块603，用于将所述第二事故消息发送至事故处理设备，以使所述事故处理设备将所述第二事故消息写入区块链中。

一种可能的实现方式中，所述接收模块601还用于从所述第二终端接收第一理赔消息，所述第一理赔消息包括所述事故的标识、状态和所述第一用户和所述第二用户之间的理赔协商信息，以及所述第二用户的签名信息，所述状态用于指示所述事故处于理赔协商中；

所述处理模块602还用于在对所述第二用户的签名信息验证通过，并接收到用于指示对所述理赔协商信息验证通过的验证消息时，在所述第一理赔消息中添加所述第一用户的签名信息，得到第二理赔消息；

所述发送模块603还用于将所述第二理赔消息发送至所述事故处理设备，以使所述事故处理设备将所述事故的理赔协商信息写入区块链中。

一种可能的实现方式中，所述接收模块601还用于从保险处理设备接收第一理赔结果消息，所述第一理赔结果消息中包括所述事故的标识、状态和理赔结果信息，以及保险机构的签名信息；所述处理模块602还用于在对所述第一理赔结果消息中的所述保险机构的签名信息验证通过，并接收到用于指示对所述理赔结果信息验证通过的验证消息时，在所述第一理赔结果消息中添加所述第一用户的签名信息，得到第二理赔结果消息；所述发送模块603还用于将所述第二理赔结果消息发送给所述第二终端；

或者，

所述接收模块601还用于从所述第二终端接收第二理赔结果消息，所述第二理赔结果消息是所述第二终端从所述保险处理设备接收到所述第一理赔结果消息后，在所述第一理赔结果消息中添加所述第二用户的签名信息得到的；所述处理模块602还用于在对所述第二理赔结果消息中的所述保险机构的签名信息、所述第二用户的签名信息验证通过，并接收到用于指示对所述理赔结果信息验证通过的验证消息时，在所述第二理赔结果消息中添加所述第一用户的签名信息，得到第三理赔结果消息；所述发送模块603还用于将所述第三理赔结果消息发送给所述保险处理设备。

一种可能的实现方式中，所述处理模块602还用于生成一对公钥和私钥，所述公钥为所述第一用户的身份信息，所述私钥用于生成所述签名信息，所述公钥用于对所述签名信息进行校验；

所述处理模块602还用于将所述私钥保存在本地；

所述发送模块603还用于将所述公钥发送至所述事故处理设备，以使所述事故处理设备将所述公钥写入区块链中。

本实施例的事故处理装置可用于执行上述方法实施例中的第一终端侧的事故处理方法，其实现原理和技术效果类似，此处不再赘述。

当本实施例的事故处理装置应用于事故处理设备中时，接收模块601，用于从第一终端接收第二事故消息，所述第二事故消息是所述第一终端从所述第二终端接收到第一事故消息后，在所述第一事故消息中添加第一用户的签名信息得到的，所述第一事故消息包括事故的标识、状态、所述第一终端对应的所述第一用户与所述第二终端对应的第二用户之间的责任协商信息，以及所述第二用户的签名信息，所述状态用于指示所述事故处于责任协商中；

处理模块602，用于对所述第二事故消息中的所述第一用户的签名信息和所述第二用户的签名信息进行验证，并在验证结果为通过时，通过共识协议将所述第二事故消息写入区块链中。

一种可能的实现方式中，所述处理模块602还用于：

针对所述第二事故消息执行纠纷校验合约，所述纠纷校验合约用于对所述第一用户的签名信息、所述第二用户的签名信息以及所述责任协商信息进行校验；在所述纠纷校验合约的执行结果指示所述第二事故消息有效时，将所述第二事故消息中的事故的状态修改为责任协商完成，得到第三事故消息，并通过共识协议将所述第三事故消息写入区块链中。

一种可能的实现方式中，所述接收模块601还用于从所述第一终端接收第二理赔消息，所述第二理赔消息是所述第一终端从所述第二终端接收到第一理赔消息后，在所述第一理赔消息中添加第一用户的签名信息得到的，所述第一理赔消息包括事故的标识、状态、所述第一用户与所述第二用户之间的理赔协商信息，以及所述第二用户的签名信息，所述状态用于指示所述事故处于理赔协商中；

所述处理模块602还用于对所述第二理赔消息中的所述第一用户的签名信息和所述第二用户的签名信息进行验证，并在验证结果为通过时，通过共识协议将所述第二理赔消息写入区块链中。

一种可能的实现方式中，所述处理模块602还用于：

针对所述第二理赔消息执行理赔校验合约，所述理赔校验合约用于对所述第一用户的签名信息、所述第二用户的签名信息以及所述理赔协商信息进行校验；在所述理赔校验合约的执行结果指示所述第二理赔消息有效时，所述事故处理设备将所述第二理赔消息中的事故的状态修改为理赔协商完成，得到第三理赔消息；

所述发送模块603，用于将所述第三理赔消息发送给保险处理设备，以使所述保险处理设备根据所述第三理赔消息，向所述第一终端和/或所述第二终端发送第一理赔结果消息，所述第一理赔结果消息中包括所述事故的标识、状态和理赔结果信息，以及保险机构的签名信息，所述状态用于指示所述事故处于理赔处理中。

一种可能的实现方式中，所述接收模块601还用于从所述保险处理设备接收第三理赔结果消息；

所述处理模块602还用于：对所述第三理赔结果消息中的所述保险机构的签名信息、所述第一用户的签名信息和所述第二用户的签名信息进行验证，在验证结果为通过时，通过共识协议将所述第三理赔结果消息写入区块链中；针对所述第三理赔结果消息，执行理赔结果校验合约，所述理赔结果校验合约用于对所述保险机构的签名信息、所述第一用户的签名信息和所述第二用户的签名信息进行校验；在所述理赔结果校验合约的执行结果指示所述第三理赔结果消息有效时，将所述第三理赔结果消息中的事故的状态修改为理赔完成，得到第四理赔结果消息，并通过共识协议将所述第四理赔结果消息写入区块链中。

一种可能的实现方式中，所述接收模块601还用于从所述第一终端接收公钥，所述公钥为所述第一用户的身份信息；

所述处理模块602还用于对所述公钥进行验证，并在验证结果为通过时，通过共识协议将所述公钥写入区块链中。

本实施例的事故处理装置可用于执行上述方法实施例中的事故处理设备侧的事故处理方法，其实现原理和技术效果类似，此处不再赘述。

图7为本申请一个实施例提供的终端的结构示意图。如图7所示，本实施例的终端700，包括：处理器701以及存储器702；其中，存储器702，用于存储计算机程序；处理器701，用于执行存储器存储的计算机程序，以实现上述实施例中由第一终端执行的事故处理方法。具体可以参见前述方法实施例中的相关描述。

可选地，存储器702既可以是独立的，也可以跟处理器701集成在一起。

当所述存储器702是独立于处理器701之外的器件时，所述终端700还可以包括：总线703，用于连接所述存储器702和处理器701。

本实施例提供的终端，可用于执行上述任一方法实施例中的终端侧执行的技术方案，其实现原理和技术效果类似，本实施例此处不再赘述。

图8为本申请一个实施例提供的事故处理设备的结构示意图。如图8所示，本实施例提供的事故处理设备800，包括：处理器801以及存储器802；其中，存储器802，用于存储计算机程序；处理器801，用于执行存储器存储的计算机程序，以实现上述实施例中由事故处理设备执行的事故处理方法。具体可以参见前述方法实施例中的相关描述。

可选地，存储器802既可以是独立的，也可以跟处理器801集成在一起。

当所述存储器802是独立于处理器801之外的器件时，所述事故处理设备800还可以包括：总线803，用于连接所述存储器802和处理器801。

本实施例提供的事故处理设备，可用于执行上述任一方法实施例中的由事故处理设备执行的技术方案，其实现原理和技术效果类似，本实施例此处不再赘述。

本申请实施例还提供一种计算机可读存储介质，所述计算机可读存储介质包括计算机程序，所述计算机程序用于实现如上任一方法实施例中的第一终端侧的技术方案，或者事故处理设备侧的技术方案。

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

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

另外，在本申请各个实施例中的各功能模块可以集成在一个处理单元中，也可以是各个模块单独物理存在，也可以两个或两个以上模块集成在一个单元中。上述模块成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。

上述以软件功能模块的形式实现的集成的模块，可以存储在一个计算机可读取存储介质中。上述软件功能模块存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器(英文：processor)执行本申请各个实施例所述方法的部分步骤。

应理解，上述处理器可以是中央处理单元(英文：centralprocessingunit，简称：cpu)，还可以是其他通用处理器、数字信号处理器(英文：digitalsignalprocessor，简称：dsp)、专用集成电路(英文：applicationspecificintegratedcircuit，简称：asic)等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合申请所公开的方法的步骤可以直接体现为硬件处理器执行完成，或者用处理器中的硬件及软件模块组合执行完成。

存储器可能包含高速ram存储器，也可能还包括非易失性存储nvm，例如至少一个磁盘存储器，还可以为u盘、移动硬盘、只读存储器、磁盘或光盘等。

总线可以是工业标准体系结构(industrystandardarchitecture，isa)总线、外部设备互连(peripheralcomponent，pci)总线或扩展工业标准体系结构(extendedindustrystandardarchitecture，eisa)总线等。总线可以分为地址总线、数据总线、控制总线等。为便于表示，本申请附图中的总线并不限定仅有一根总线或一种类型的总线。

上述存储介质可以是由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(sram)，电可擦除可编程只读存储器(eeprom)，可擦除可编程只读存储器(eprom)，可编程只读存储器(prom)，只读存储器(rom)，磁存储器，快闪存储器，磁盘或光盘。存储介质可以是通用或专用计算机能够存取的任何可用介质。

一种示例性的存储介质耦合至处理器，从而使处理器能够从该存储介质读取信息，且可向该存储介质写入信息。当然，存储介质也可以是处理器的组成部分。处理器和存储介质可以位于专用集成电路(applicationspecificintegratedcircuits，简称：asic)中。当然，处理器和存储介质也可以作为分立组件存在于电子设备或主控设备中。

本领域普通技术人员可以理解：实现上述各方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成。前述的程序可以存储于一计算机可读取存储介质中。该程序在执行时，执行包括上述各方法实施例的步骤；而前述的存储介质包括：rom、ram、磁碟或者光盘等各种可以存储程序代码的介质。

最后应说明的是：以上各实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述各实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的范围。