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

本发明涉及智能交通技术领域，尤其涉及一种交通事故处理的方法、装置及系统。

背景技术：

随着交通运输的不断发达，车辆的日益增多，交通事故处理也逐渐增多，一旦发生交通事故，尤其是重大、特大的交通事故，往往造成交通道路堵塞，降低城市道路运营效率，给社会带来巨大的经济损失。在交通事故中，可快速处理的轻微事故占车损事故比例的60％以上，快速的认定交通事故的责任方可解决交通道路堵塞问题，因此如何快速的认定交通事故的责任方成为目前亟待解决的问题。

目前，对于轻微事故的处理通常有两种情况：一种是事故双方确认事故责任方，并填写交通事故快速处理协议书进行快速处理；另一种情况是事故双方对于事故的责任方不能达成一致，需要报警等待交警处理，而等待交警处理，通常需要花费较长的时间，浪费人力物力，造成轻微事故处理的效率低。

技术实现要素：

鉴于上述问题，本发明提供一种交通事故处理的方法、装置及系统。用以解决现有的轻微事故处理方式效率低的问题。

为解决上述技术问题，第一方面，本发明提供了一种交通事故处理的方法，所述方法应用于客户端，所述方法包括：

发送事故方触发的交通事故自助办理请求至服务端；

在接收服务端发送的获取交通事故现场图像信息的提示信息后，发送通过智能终端拍摄获取的图像数据至交通事故自助办理的服务端，以使所述服务端根据所述图像数据确定交通事故责任的认定结果。

第二方面，本发明提供了另一种交通事故处理的方法，所述方法应用于服务端，所述方法包括：

在接收到事故方触发的交通事故自助办理请求之后，发送用于获取交通事故现场图像信息的提示信息至客户端；

接收客户端通过智能终端拍摄获取的图像数据，根据所述图像数据确定交通事故责任的认定结果。

第三方面，本发明提供了一种交通事故处理的装置，所述装置位于客户端侧，所述装置包括：

发送单元，用于发送事故方触发的交通事故自助办理请求至服务端；

接收单元，用于接收服务端发送的获取交通事故现场图像信息的提示信息；

所述发送单元，还用于发送通过智能终端拍摄获取的图像数据至交通事故自助办理的服务端，以使所述服务端根据所述图像数据确定交通事故责任的认定结果。

第四方面，本发明提供了一种交通事故处理的装置，所述装置位于服务端侧，所述装置包括：

接收单元，用于接收事故方触发的交通事故自助办理请求；

发送单元，用于发送用于获取交通事故现场图像信息的提示信息至客户端；

所述接收单元，还用于接收客户端通过智能终端拍摄获取的图像数据；

确定单元，用于根据所述图像数据确定交通事故责任的认定结果。

第五方面，本发明提供了一种交通事故处理的系统，所述系统包括客户端以及服务端：

所述客户端，用于发送事故方触发的交通事故自助办理请求至所述服务端；在接收服务端发送的获取交通事故现场图像信息的提示信息后，发送通过智能终端拍摄获取的图像数据至交通事故自助办理的服务端，以使所述服务端根据所述图像数据确定交通事故责任的认定结果；

所述服务端，用于在接收到事故方触发的交通事故自助办理请求之后，发送用于获取交通事故现场图像信息的提示信息至所述客户端；接收客户端通过智能终端拍摄获取的图像数据，根据所述图像数据确定交通事故责任的认定结果。

借由上述技术方案，本发明提供的交通事故处理的方法、装置及系统，与现有技术相比，当发生交通事故时，事故方可以通过客户端提供的自助办理通道，将事故现场的图像信息上传给能够认定事故责任方的服务端，使服务端快速地将事故责任认定结果返回给客户端，使事故方可以通过客户端获知事故责任认定结果，节约了警方调配警力到事故现场进行事故责任认定的时间和人力，提高了处理交通事故的效率。

上述说明仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术手段，而可依照说明书的内容予以实施，并且为了让本发明的上述和其它目的、特征和优点能够更明显易懂，以下特举本发明的具体实施方式。

附图说明

通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本发明的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中：

图1示出了本发明实施例提供的一种交通事故处理的方法的流程图；

图2示出了本发明实施例提供的另一种交通事故处理的方法的流程图；

图3示出了本发明实施例提供的一种交通事故自助办理客户端的流程图；

图4示出了本发明实施例提供的又一种交通事故处理的方法的流程图；

图5示出了本发明实施例提供的一种服务端基于HttpServlet+mybatis的设计框架；

图6示出了本发明实施例提供的一种自助交通事故办理的业务流程图；

图7示出了本发明实施例提供的一种交通事故处理的装置的组成框图；

图8示出了本发明实施例提供的另一种交通事故处理的装置的组成框图；

图9示出了本发明实施例提供的又一种交通事故处理的装置的组成框图。

具体实施方式

下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。

为解决现有的轻微事故处理方式效率低的问题，本发明实施例提供了一种交通事故处理的方法，该方法位于客户端，如图1所示，该方法包括：

101、在接收事故方触发的交通事故自助办理请求后，将自助办理请求至服务端。

首先需要说明的是，客户端是为用户提供交通事故自助办理通道的程序，该程序可以设计为一个独立的应用程序(Application，APP)安装在智能终端中；也可以作为一个子应用依附在别的应用程序中，比如作为微信平台、支付宝平台等应用中的子应用。其中，智能终端包括智能手机、平板电脑ipad、车载智能终端、可穿戴设备等等。

其中，交通事故自助办理请求是指用户点击确认进入交通事故自助办理通道后生成的请求。客户端接收到该请求后，将自助办理请求至服务端，以使客户端进入自助办理交通事故流程。

102、在接收到服务端发送的获取交通事故现场图像信息的提示信息后，接收通过智能终端拍摄获取的图像数据。

自助办理交通事故流程的第一步为接收服务端发送的获取交通事故现场图像信息的提示信息，然后调用智能终端的拍摄应用使用户对交通事故现场进行拍摄，获取智能终端拍摄的图像数据。其中图像数据即为交通事故现场图像信息。

需要说明的是，图像数据可以为静态图片也可以为动态的视频。另外，为了保证用户拍摄得到的图像数据的尽可能符合交通事故图像数据采集标准，通常会在拍摄之前提示用户拍摄的要求。比如提示用户拍摄在车头位置拍摄的事故车辆的全貌的图像、在车尾位置拍摄的事故车辆的全貌的图像、接触部位或者撞击部位的局部的图像等对进行事故定责有帮助的图像。

103、将图像数据发送给交通事故自助办理的服务端。

具体的进行交通事故的处理分析是由服务端进行的，因此客户端需要将获取到的图像数据发送给交通事故自助办理的服务端。服务端接收到图像数据后，会对事故现场对应的图像数据进行分析，其中分析包括但不限于人工分析。对图像数据进行分析主要是对交通事故责任进行认定，确定责任方。在服务端确定责任方之后，会及时的将认定的结果返回到客户端。需要说明的是，服务端进行分析的图像数据是符合交通事故图像数据采集标准的图像数据。

104、接收服务端返回的交通事故责任的认定结果。

接收到认定结果后，将认定结果输出，使事故方可以获取事故的责任方。需要说明的是，本实施例中服务端位于交通管理部门，因此，认定结果具有可信度。

通过自助交通事故处理通道，从事故发生到确定责任方，速度非常快，相比于等待交警到事故现场进行事故处理的线下处理方式大大的节约了时间。另外，在将事故现场的图像数据发送给服务端后，通常汽车司机就可以及时地将车辆及时撤离现场，这样也避免了交通拥堵。

另外，实施例中客户端的设计所使用计算机语言包括(Hypertext Preprocessor，PHP)、脚本语言JavaScript、超文本标记语言(HyperText Markup Language，HTML)以及层叠样式表(Cascading Style Sheets，CSS)；服务端是基于浏览器的web端，服务端使用的计算机语言包括：Java、JavaScrip、HTML、CSS以及JavaScript。上述客户端和服务端采用的技术中具体的是通过HTML+CSS实现页面内容的表示和布局；通过PHP/Java访问数据库，取得数据，为页面表示提供数据源；通过JavaScript实现页面中的逻辑处理以及页面迁移。

本发明实施例提供的交通事故处理的方法，与现有技术相比，当发生交通事故时，事故方可以通过客户端提供的自助办理通道，将事故现场的图像信息上传给能够认定事故责任方的服务端，使服务端快速地将事故责任认定结果返回给客户端，使事故方可以通过客户端获知事故责任认定结果，节约了警方调配警力到事故现场进行事故责任认定的时间和人力，提高了处理交通事故的效率。

为了对图1所示方法的进一步细化及扩展，本实施例还提供了一种交通事故处理的方法，如图2所示：

201、在接收事故方触发的交通事故自助办理请求后，将自助办理请求至服务端。

该步骤的实现方式与图1步骤101的实现方式相同，此处不再赘述。

202、输出继续进行交通事故自助处理的标准参数确认提示信息。

其中，继续进行交通事故自助处理的标准参数为以下参数中的一项或者多项：交通事故发生时长是否在预设时间范围内；是否有人员伤亡；是否设置警示标志。当标准参数为多项时，逐个输出提示信息并接收确认信息。

203、若接收到对应标准参数提示信息的确认信息，则执行在接收到服务端发送的获取交通事故现场图像信息的提示信息后，接收通过智能终端拍摄获取的图像数据。

其中，“执行在接收到服务端发送的获取交通事故现场图像信息的提示信息后，接收通过智能终端拍摄获取的图像数据”的实现方式与图1步骤102的实现方式相同不再赘述。

若接收到对应标准参数提示信息的否认信息，则调用报警机制进行交通事故报警。

其中对应的确认信息指在交通事故发生时长在预设时间范围内、没有人员伤亡、已经设置了警示标志中的一个或多个消息。另外，预设时间范围是指服务端可以提供自助交通事故处理服务的时间。

具体的给出示例对上述情况进行说明，假设标准参数包括上述所有项。并且按照是否在预设时间范围内、是否设置警示标志、是否有人员伤亡的顺序输出对应的提示消息。若用户输入的时间在预设时间范围内，则继续输出是否设置警示标识的提示消息，若不在预设时间范围内，则调用报警机制，进行交通事故报警，结束自助交通事故办理；若已经设置了警示标志，则输出是否有人员伤亡的提示消息，若用户输入的是有人员伤亡，则调用报警机制，进行交通事故报警，结束自助交通事故办理，若用户输入的是没有人员伤亡，则执行在接收到服务端发送的获取交通事故现场图像信息的提示信息后，接收通过智能终端拍摄获取的图像数据。

需要说明的是，调用报警机制包括但不限于调用智能终端的通话功能，进行122电话报警。

204、将图像数据发送给交通事故自助办理的服务端。

具体的进行交通事故的处理分析是由服务端进行的，因此客户端需要将获取到的图像数据发送给交通事故自助办理的服务端。服务端接收到图像数据后，会对事故现场对应的图像数据进行分析。但是在实际的应用中，会存在用户拍摄的图像不符合交通事故图像数据采集标准，此时服务端会向客户端返回重新上传图像数据的提示信息，使客户端重新获取图像数据，直到接收到服务端返回的图像数据符合交通事故图像数据采集标准的通知消息。需要说明的是，采集标准为图像数据至少包括以下图像：在车头位置拍摄的事故车辆的全貌的图像、在车尾位置拍摄的事故车辆的全貌的图像以及事故车辆接触部位或者撞击部位的局部的图像。

205、接收事故方上传的证件信息以及联系方式。

在接收服务端返回的交通事故责任的认定结果之前，接收事故方上传的证件信息，其中证件信息包括驾驶证和行驶证。具体的接收的证件信息为证件照片，对应的接收证件信息的方式与前述接收事故现场的图像数据的方式是相同的，都是通过智能终端拍摄获得。另外对于智能终端中已经保存的证件照片，也可以通过文件选择的方式直接上传。

206、将证件信息以及联系方式发送给服务端。

将证件信息以及联系方式发送给服务端是为了使服务端根据证件信息以及联系方式完善认定结果，得到事故定责书。另外判断证件信息是否完整，还可以作为判断是否有无证驾驶行为的依据。

当服务端对证件信息的完整性进行判断后，向客户端返回证件信息是否完整的提示消息。若客户端接收到服务端返回的提示消息为证件信息完整的提示消息，则执行步骤207；若接收到服务器返回的提示消息为证件信息不完整的提示消息，则调用报警机制进行交通事故报警。

207、接收服务端返回的事故定责书或者提取事故定责书的路径信息。

具体的，客户端接收到的可以是以图片的形式直接展示在客户端的事故定责书，也可以是接收到一个链接，然后使用户通过该链接获取事故定责书。

208、接收服务端返回的理赔服务点信息。

接收理赔服务点信息是为了使事故方可以确定进行理赔的地点，并自行约定时间进行后续的理赔。理赔服务点是由服务端选定的服务点。

另外，在步骤205之前，通常还需要输出判断事故车辆是否能够撤离现场的提示消息，若客户端接收到车辆无法撤离的消息后，会调用报警机制进行交通事故报警，提前结束自助交通事故处理的流程；若接收到车辆可以撤离的消息，则继续步骤205。

在步骤205之前，通常还需要输出判断是否有酒驾或毒驾嫌疑的提示消息，若客户端接收到有酒驾或毒驾嫌疑的提示消息后，会调用报警机制进行交通事故报警，提前结束自助交通事故处理的流程；若接收到没有酒驾或毒驾嫌疑的提示消息，则继续步骤205。需要说明的是，由于通常用户没有专业的测试工具进行酒驾或者毒驾的测试，所以通常是通过用户自己根据酒驾或毒驾者的行为判断是否有酒驾或毒驾的嫌疑。

在实际的应用中，通常上述判断事故车辆是否能够撤离现场的提示消息与判断是否有酒驾或毒驾嫌疑的提示消息是都需要输出的，输出的顺序不做限定，当两者都输出时，步骤205需在接收到没有酒驾或毒驾嫌疑以及车辆可以撤离现场的提示消息后再执行。

本实施例提供的交通事故处理的方法，不仅可以通过线上的方式快速确定事故责任方，另外还可以提供事故定责书以及理赔服务点信息，这样实现了交通事故的快速处理和快速理赔。

另外，对应与图2中的实施例，给出一种实际应用中交通事故自助办理客户端的流程图，如图3所示，具体过程说明：事故方选择“自助办理”；然后进行判断当前时间超过受理时间范围，其中的受理时间范围对应于上述步骤202中的预设时间范围；若果在受理时间范围内则受理，并提示事故方设置警示标志；确定设置完警示标志后提示事故方查看事故现场是否有人员伤亡，若有人员伤亡则进行交通事故报警，结束交通事故自助办理流程；若没有人员伤亡，则获取事故现场图像，其中事故现场图像对应于上述的图像数据，然后等待事故图像的审核结果；若通过审核，获取事故责任认定结果，并提示将事故车辆撤离现场；若没有通过审核，则重新获取事故现场图像，直到通过审核为止；若事故车辆无法撤离现场，则进行交通事故报警，结束交通事故自助办理流程；若确定事故车辆可以撤离现场，则查看是否有酒驾或毒驾的嫌疑，若确认有酒驾或毒驾的嫌疑，则进行交通事故报警，结束交通事故自助办理流程；若没有酒驾或毒驾的嫌疑，则将获取到的事故方的驾驶证和行驶证上传给服务端，其中驾驶证和行驶证对应于上述的证件信息；若根据服务端返回的结果确定驾驶证和行驶证中缺少任一个证件，则进行交通事故报警，结束交通事故自助办理流程；若驾驶证和行驶证都有，则让事故方填写联系方式，以使服务端生成事故定责书；然后客户端接收服务端返回的事故定责书使用户可以获取到事故定责书；最后客户端可以让事故方查看理赔服务点信息，该理赔服务点信息是由服务端返回的；最后结束整个交通事故自助办理流程。

为解决现有的轻微事故处理方式效率低的问题，本发明实施例还提供了一种交通事故处理的方法，该方法位于服务端，如图4所示，该方法包括：

301、在接收到事故方触发的交通事故自助办理请求之后，发送用于获取交通事故现场图像信息的提示信息至客户端。

交通事故自助办理请求是指用户点击确认进入交通事故自助办理通道后生成的请求。客户端接收到该请求后，将自助办理请求至服务端，服务端接收到交通事故自助办理请求后向客户端返回获取交通事故现场图像信息的提示信息，以使客户端向服务端发送事故现场的图像数据。

302、接收客户端发送的图像数据。

服务端返回获取交通事故现场图像信息的提示信息后，客户端会调用智能终端拍摄应用使用户对交通事故现场进行拍摄，获取拍摄的图像数据。客户端获取图像数据后将其发送给服务端，然后服务端接收到事故现场的图像信息。

303、根据图像数据确定交通事故责任的认定结果。

服务端接收到图像数据后，会对事故现场对应的图像数据进行分析，其中分析包括但不限于人工分析。对图像数据进行分析主要是根据交通法则对交通事故责任进行认定，确定责任方。在服务端确定责任方之后，会及时的将认定的结果返回到客户端。需要说明的是，本实施例中服务端位于交通管理部门，因此，认定结果具有可信度。

另外，实施例中客户端的设计所使用计算机语言包括(Hypertext Preprocessor，PHP)、脚本语言JavaScript、超文本标记语言(HyperText Markup Language，HTML)以及层叠样式表(Cascading Style Sheets，CSS)；服务端是基于浏览器的web端，服务端使用的计算机语言包括：Java、JavaScrip、HTML、CSS以及JavaScript。上述客户端和服务端采用的技术中具体的是通过HTML+CSS实现页面内容的表示和布局；通过PHP/Java访问数据库，取得数据，为页面表示提供数据源；通过JavaScript实现页面中的逻辑处理以及页面迁移。

本发明实施例提供的交通事故处理的方法，与现有技术相比，当发生交通事故时，事故方可以通过客户端提供的自助办理通道，将事故现场的图像信息上传给能够认定事故责任方的服务端，服务端在接收到图像数据后可以及时地进行分析判断并迅速地将事故责任认定结果返回给客户端，使事故方可以通过客户端获知事故责任认定结果，节约了警方调配警力到事故现场进行事故责任认定的时间和人力，提高了处理交通事故的效率。

下面对图4所示方法的进一步细化及扩展，如下所述：

上述步骤303中根据所述图像数据确定交通事故责任的认定结果具体的实现过程，如下：

首先，判断所述图像数据是否符合交通事故图像数据采集标准；

具体的判断方式为：服务端的后台数据服务端将接收到的图像数据发送给服务端的前台数据展示端，然后由专业的人员对图像数据进行分析，并通过前台数据展示端将判断的结果返回给后台服务端。另外在实际的应用中，也可以将交通事故图像数据的采集标准提前设置在后台数据服务端，由后台数据服务端进行自动化的判断。

需要说明的是，采集标准为获取到的图像数据至少包括以下图像：在车头位置拍摄的事故车辆的全貌的图像、在车尾位置拍摄的事故车辆的全貌的图像以及事故车辆接触部位或者撞击部位的局部的图像。在实际的应用中还可能包括对决定事故责任方有帮助的图像，具体的有帮助的图像需要根据具体的事故进行设置。

其次，根据判断结果决定是否返回认定结果至客户端。

若判断结果为图像数据符合交通事故图像数据采集标准，则对图像数据进行分析获取交通事故责任的认定结果，并将认定结果发送给客户端。

将认定结果发送给客户端，可以使事故方获知事故的责任方。

若判断结果为图像数据不符合交通事故图像数据采集标准，则服务端向所述客户端发送图像数据不符合交通事故图像数据采集标准的通知消息，以使所述客户端根据所述不符合交通事故图像数据采集标准的通知消息重新通过智能终端拍摄获取所述图像数据。直到到服务端接收的图像数据符合交通事故图像数据采集标准后，再对图像数据进行分析并确定事故责任的认定结果。

在步骤303之前，为了完善认定结果，生成完善的事故定责书，因此服务端还会向客户端返回上传事故方的证件信息以及联系方式的提示消息，然后使客户端获取事故方上传的证件信息以联系方式后发送给服务端，其中证件信息包括驾驶证和行驶证。在服务端获取证件信息以及联系方式后，服务端还需要对证件信息的完整性进行判断，若判断证件信息是完整的，则会向客户端返回证件信息完整的提示信息，并依据完整的证件信息以及联系方式完善事故定责书，然后将事故定责书或者提取事故定责书的路径返回给客户端，使客户端获取事故定责书。若判断证件信息是不完整的，则会向客户端返回证件信息不完整的提示信息，以使客户端根据证件信息不完整的提示消息及时的调用报警机制进行交通事故报警。需要说明的是，调用报警机制包括但不限于调用智能终端的通话功能，进行122电话报警。

在服务端向客户端返回事故定责书或者提取事故定责书的路径之后，为了使事故方可以及时获知理赔服务点，服务端还会向客户端返回理赔服务点信息，以使事故方可以自行约定时间进行后续的理赔。

另外，在服务端向客户端返回上传事故方的证件信息以及联系方式的提示消息之前，服务端还可以向客户端返回判断事故车辆是否能够撤离现场的提示消息，若接收到客户端返回事故车辆可以撤离现场的确认消息，则继续向客户端返回上传事故方的证件信息以及联系方式的提示消息。若接收到客户端返回事故车辆不可以撤离现场的确认消息。则使客户端执行调用报警机制进行交通事故报警，提前结束自助交通事故处理的流程。

另外，在服务端向客户端返回上传事故方的证件信息以及联系方式的提示消息之前，服务端还可以向客户端返回判断是否有酒驾或毒驾嫌疑的提示消息，若接收到客户端返回没有酒驾或毒驾嫌疑的提示消息后，则继续向客户端返回上传事故方的证件信息以及联系方式的提示消息；若接收到客户端有酒驾或毒驾嫌疑的提示消息，则使客户端执行调用报警机制进行交通事故报警，提前结束自助交通事故处理的流程。需要说明的是，因为通常用户没有专业的测试工具进行酒驾或者毒驾的测试，只能通过用户自己根据酒驾或毒驾者的行为判断是否有酒驾或毒驾的嫌疑。

在实际的应用中，通常上述判断事故车辆是否能够撤离现场的提示消息与判断是否有酒驾或毒驾嫌疑的提示消息是都需要向客户端返回的，返回的顺序不做限定，当两者都返回时，服务端在接收到没有酒驾或毒驾嫌疑以及车辆可以撤离现场的提示消息后再向客户端返回上传事故方的证件信息以及联系方式的提示消息。

另外，为了提高服务端中前台数据展示端与向后台数据服务端之间数据传输的效率，本实施例中前台数据展示端基于进行二次封装的jquery，具体的是根据本实施例中的业务需求进行jquery的二次封装，这样可以省去数据传输过程中对各种参数的设置，实现向后台数据服务端更简便地传送JSON数据。

此外，还需要说明的是后台数据服务端响应前台数据展示端的流程基于HttpServlet+mybatis框架实现的，具体的HttpServlet+mybatis框架如图5所示，其中包括三层，第一层是接口层，用于接收前台数据展示端发送的数据请求；第二层是逻辑处理层，用于为接口层提供对应的服务；第三层为数据处理层，用于为逻辑处理层提供数据服务，具体的第三层是通过从数据库MySQL获取数据来为第二层提供数据服务的。要说明的是，后台数据服务端可以支持json/xml等数据格式。需要说明的是，图5中客户端(界面)为上述前台数据展示端，服务器端(tomcat)为上述后台数据服务端。

在实际应用中，由于交通管理部门通常有对交通事故进行统计和分析的需求。因此服务端还通过后台服务端将接收到的所有图像数据以及图像数据对应的交通事故信息进行多维度分类统计，其中交通事故信息包括事故发生的时间、事故发生的地点、事故的类型、事故处理方式；这样就可以使交通管理人员通过前台数据展示端进行交通事故的多维度查询。具体是由前台数据展示端发送由交通管理人员输入的交通事故信息查询维度；然后后台服务端根据所述事故信息查询维度向所述前台数据展示端返回与所述交通事故信息查询维度对应的所有事故信息。例如，输入的查询维度为事故发生的时间，具体的时间为一个月前，则后台服务端根据所述事故信息查询维度向所述前台数据展示端返回前一个月内所有的通过自助交通事故办理通道进行办理的所有交通事故的详细信息。

最后，结合上述图1、图2以及图4中实施例的实现，给出了实际应用中实现自助交通事故办理的整体的一种业务流程图，如图6所示。其中，左侧为现有的旧业务流程，右侧为本实施例对应的新业务流程，可以看到新业务流程中，当事人对应上述的事故方，各大队指挥中心受理定责对应服务端接收当事人通过微信事故报警途径进行自助交通事故办理，省去了旧业务中当事人122事故报警、122接处警中心转接警到各大队指挥中心的过程，另外大大减少了进行调用外勤交警的情况。当当事人根据各大队指挥中心返回的理赔服务点之后进行理赔后，理赔服务点将相关的事故车辆查询以及定损的处理情况返回给各大队指挥中心。对于事故责任方没有对应保险公司的需要理赔服务点联系事故责任方索要理赔金额。综上可以看到新的业务流程更加的省时省力，实现了交通事故的快处快赔。

进一步的，作为对上述各实施例的实现，本发明实施例的另一实施例还提供了一种交通事故处理的装置，所述装置位于客户端侧，用于实现上述图1以及图2所述的方法。如图7所示，该装置包括：发送单元41以及接收单元42。

发送单元41，用于发送事故方触发的交通事故自助办理请求至服务端；

首先需要说明的是，客户端是为用户提供交通事故自助办理通道的程序，该程序可以设计为一个独立的应用程序(Application，APP)安装在智能终端中；也可以作为一个子应用依附在别的应用程序中，比如作为微信平台、支付宝平台等应用中的子应用。其中，智能终端包括智能手机、平板电脑ipad、车载智能终端、可穿戴设备等等。

其中，交通事故自助办理请求是指用户点击确认进入交通事故自助办理通道后生成的请求。客户端接收到该请求后，将自助办理请求至服务端，以使客户端进入自助办理交通事故流程。

接收单元42，用于接收服务端发送的获取交通事故现场图像信息的提示信息；

发送单元41，还用于发送通过智能终端拍摄获取的图像数据至交通事故自助办理的服务端，以使服务端根据图像数据确定交通事故责任的认定结果。

自助办理交通事故流程的第一步为接收服务端发送的获取交通事故现场图像信息的提示信息，然后调用智能终端的拍摄应用使用户对交通事故现场进行拍摄，获取智能终端拍摄的图像数据。其中图像数据即为交通事故现场图像信息。

需要说明的是，图像数据可以为静态图片也可以为动态的视频。另外，为了保证用户拍摄得到的图像数据的尽可能符合交通事故图像数据采集标准，通常会在拍摄之前提示用户拍摄的要求。比如提示用户拍摄在车头位置拍摄的事故车辆的全貌的图像、在车尾位置拍摄的事故车辆的全貌的图像、接触部位或者撞击部位的局部的图像等对进行事故定责有帮助的图像。

由于进行交通事故的处理分析是由服务端进行的，因此客户端需要将获取到的图像数据发送给交通事故自助办理的服务端。服务端接收到图像数据后，会对事故现场对应的图像数据进行分析，其中分析包括但不限于人工分析。对图像数据进行分析主要是对交通事故责任进行认定，确定责任方。在服务端确定责任方之后，会及时的将认定的结果返回到客户端。需要说明的是，服务端进行分析的图像数据是符合交通事故图像数据采集标准的图像数据。

接收到认定结果后，将认定结果输出，使事故方可以获取事故的责任方。需要说明的是，本实施例中服务端位于交通管理部门，因此，认定结果具有可信度。

通过自助交通事故处理通道，从事故发生到确定责任方，速度非常快，相比于等待交警到事故现场进行事故处理的线下处理方式大大的节约了时间。另外，在将事故现场的图像数据发送给服务端后，通常汽车司机就可以及时地将车辆及时撤离现场，这样也避免了交通拥堵。

另外，实施例中客户端的设计所使用计算机语言包括(Hypertext Preprocessor，PHP)、脚本语言JavaScript、超文本标记语言(HyperText Markup Language，HTML)以及层叠样式表(Cascading Style Sheets，CSS)；服务端是基于浏览器的web端，服务端使用的计算机语言包括：Java、JavaScrip、HTML、CSS以及JavaScript。上述客户端和服务端采用的技术中具体的是通过HTML+CSS实现页面内容的表示和布局；通过PHP/Java访问数据库，取得数据，为页面表示提供数据源；通过JavaScript实现页面中的逻辑处理以及页面迁移。

另外，在实际应用中，对于某些交通事故是必须有交警到现场进行处理的，在这种时候就不需要再通过上述自助办理交通事故的流程进行事故的定责。因此，在客户端接收服务端发送的获取交通事故现场图像信息的提示信息之前，客户端还会输出继续进行交通事故自助处理的标准参数确认提示信息。若接收到对应标准参数提示信息的确认信息，则执行在接收到服务端发送的获取交通事故现场图像信息的提示信息后，接收通过智能终端拍摄获取的图像数据；若接收到对应标准参数提示信息的否认信息，则调用报警机制进行交通事故报警，调用报警机制包括但不限于调用智能终端的通话功能，进行122电话报警。

其中，继续进行交通事故自助处理的标准参数为以下参数中的一项或者多项：交通事故发生时长是否在预设时间范围内；是否有人员伤亡；是否设置警示标志。当标准参数为多项时，逐个输出提示信息并接收确认信息。对应的确认信息指在交通事故发生时长在预设时间范围内、没有人员伤亡、已经设置了警示标志中的一个或多个消息。另外，预设时间范围是指服务端可以提供自助交通事故处理服务的时间。

另外，为了得到完善的认定结果，即事故定责书，在接收服务端返回的认定结果之前，客户端还需要接收事故方上传的证件信息以及联系方式，将证件信息以及联系方式发送给服务端，以使服务端对证件信息的完整性进行判断后，完善认定结果，生成事故定责书，并将事故定责书返回给客户端。需要说明的是，若服务端在对证件信息完整性判断后，若确定证件信息不完整性，则会返回证件信息不完整性的提示消息给客户端，使客户端调用报警机制进行交通事故报警。

其中，客户端接收到的事故定责书的形式可以是以图片的形式直接展示在客户端的事故定责书，也可以是接收到提取事故定责书的路径信息，比如一个链接，然后使用户通过该链接获取事故定责书。

在接收事故方上传的证件信息以及联系方式之前，通常还需要输出判断事故车辆是否能够撤离现场的提示消息，若客户端接收到车辆无法撤离的消息后，会调用报警机制进行交通事故报警，提前结束自助交通事故处理的流程；若接收到车辆可以撤离的消息，则继续接收事故方上传的证件信息以及联系方式。

在接收事故方上传的证件信息以及联系方式之前，还需要输出判断是否有酒驾或毒驾嫌疑的提示消息，若客户端接收到有酒驾或毒驾嫌疑的提示消息后，会调用报警机制进行交通事故报警，提前结束自助交通事故处理的流程；若接收到没有酒驾或毒驾嫌疑的提示消息，则继续接收事故方上传的证件信息以及联系方式。需要说明的是，由于通常用户没有专业的测试工具进行酒驾或者毒驾的测试，所以通常是通过用户自己根据酒驾或毒驾者的行为判断是否有酒驾或毒驾的嫌疑。在实际的应用中，通常上述判断事故车辆是否能够撤离现场的提示消息与判断是否有酒驾或毒驾嫌疑的提示消息是都需要输出的，输出的顺序不做限定，当两者都输出时，接收事故方上传的证件信息以及联系方式的动作需在接收到没有酒驾或毒驾嫌疑以及车辆可以撤离现场的提示消息后再执行。

另外，在客户端接收事故定责书或提取事故定责书的路径信息后，还会接收服务端返回的理赔服务点信息。接收理赔服务点信息是为了使事故方可以确定进行理赔的地点，并自行约定时间进行后续的理赔。理赔服务点是由服务端选定的服务点。

本发明实施例提供的交通事故处理的方法，与现有技术相比，当发生交通事故时，事故方可以通过客户端提供的自助办理通道，将事故现场的图像信息上传给能够认定事故责任方的服务端，使服务端快速地将事故责任认定结果返回给客户端，使事故方可以通过客户端获知事故责任认定结果，节约了警方调配警力到事故现场进行事故责任认定的时间和人力，提高了处理交通事故的效率。

进一步的，作为对上述各实施例的实现，本发明实施例的另一实施例还提供了一种交通事故处理的装置，所述装置位于服务端侧，用于实现上述图4所述的方法。如图8所示，该装置包括：接收单元51、发送单元52以及确定单元53。

接收单元51，用于接收事故方触发的交通事故自助办理请求；

交通事故自助办理请求是指用户点击确认进入交通事故自助办理通道后生成的请求。

发送单元52，用于发送用于获取交通事故现场图像信息的提示信息至客户端；

接收单元51，还用于接收客户端通过智能终端拍摄获取的图像数据；

服务端返回获取交通事故现场图像信息的提示信息后，客户端会调用智能终端拍摄应用使用户对交通事故现场进行拍摄，获取拍摄的图像数据。客户端获取图像数据后将其发送给服务端，然后服务端接收到事故现场的图像信息。

确定单元53，用于根据图像数据确定交通事故责任的认定结果。

服务端接收到图像数据后，会对事故现场对应的图像数据进行分析，其中分析包括但不限于人工分析。对图像数据进行分析主要是根据交通法则对交通事故责任进行认定，确定责任方。在服务端确定责任方之后，会及时的将认定的结果返回到客户端。需要说明的是，本实施例中服务端位于交通管理部门，因此，认定结果具有可信度。

如图9所示，装置进一步包括：

判断单元54，用于判断图像数据是否符合交通事故图像数据采集标准；

具体的判断方式为：服务端的后台数据服务端将接收到的图像数据发送给服务端的前台数据展示端，然后由专业的人员对图像数据进行分析，并通过前台数据展示端将判断的结果返回给后台服务端。另外在实际的应用中，也可以将交通事故图像数据的采集标准提前设置在后台数据服务端，由后台数据服务端进行自动化的判断。

需要说明的是，采集标准为获取到的图像数据至少包括以下图像：在车头位置拍摄的事故车辆的全貌的图像、在车尾位置拍摄的事故车辆的全貌的图像以及事故车辆接触部位或者撞击部位的局部的图像。在实际的应用中还可能包括对决定事故责任方有帮助的图像，具体的有帮助的图像需要根据具体的事故进行设置。

分析单元55，用于对图像数据进行分析获取交通事故责任的认定结果，并将认定结果发送给客户端。

若判断结果为图像数据符合交通事故图像数据采集标准，则对图像数据进行分析获取交通事故责任的认定结果，并将认定结果发送给客户端。

将认定结果发送给客户端，可以使事故方获知事故的责任方。

若判断结果为图像数据不符合交通事故图像数据采集标准，则服务端向所述客户端发送图像数据不符合交通事故图像数据采集标准的通知消息，以使所述客户端根据所述不符合交通事故图像数据采集标准的通知消息重新通过智能终端拍摄获取所述图像数据。直到到服务端接收的图像数据符合交通事故图像数据采集标准后，再对图像数据进行分析并确定事故责任的认定结果。

判断单元54中的采集标准为图像数据至少包括以下图像：

在车头位置拍摄的事故车辆的全貌的图像、在车尾位置拍摄的事故车辆的全貌的图像以及事故车辆接触部位或者撞击部位的局部的图像。

为了完善认定结果，生成完善的事故定责书，因此服务端还会向客户端返回上传事故方的证件信息以及联系方式的提示消息，然后使客户端获取事故方上传的证件信息以联系方式后发送给服务端，其中证件信息包括驾驶证和行驶证。在服务端获取证件信息以及联系方式后，服务端还需要对证件信息的完整性进行判断，若判断证件信息是完整的，则会向客户端返回证件信息完整的提示信息，并依据完整的证件信息以及联系方式完善事故定责书，然后将事故定责书或者提取事故定责书的路径返回给客户端，使客户端获取事故定责书。若判断证件信息是不完整的，则会向客户端返回证件信息不完整的提示信息，以使客户端根据证件信息不完整的提示消息及时的调用报警机制进行交通事故报警。需要说明的是，调用报警机制包括但不限于调用智能终端的通话功能，进行122电话报警。

在服务端向客户端返回事故定责书或者提取事故定责书的路径之后，为了使事故方可以及时获知理赔服务点，服务端还会向客户端返回理赔服务点信息，以使事故方可以自行约定时间进行后续的理赔。

另外，在服务端向客户端返回上传事故方的证件信息以及联系方式的提示消息之前，服务端还可以向客户端返回判断事故车辆是否能够撤离现场的提示消息，若接收到客户端返回事故车辆可以撤离现场的确认消息，则继续向客户端返回上传事故方的证件信息以及联系方式的提示消息。若接收到客户端返回事故车辆不可以撤离现场的确认消息。则使客户端执行调用报警机制进行交通事故报警，提前结束自助交通事故处理的流程。

另外，在服务端向客户端返回上传事故方的证件信息以及联系方式的提示消息之前，服务端还可以向客户端返回判断是否有酒驾或毒驾嫌疑的提示消息，若接收到客户端返回没有酒驾或毒驾嫌疑的提示消息后，则继续向客户端返回上传事故方的证件信息以及联系方式的提示消息；若接收到客户端有酒驾或毒驾嫌疑的提示消息，则使客户端执行调用报警机制进行交通事故报警，提前结束自助交通事故处理的流程。需要说明的是，因为通常用户没有专业的测试工具进行酒驾或者毒驾的测试，只能通过用户自己根据酒驾或毒驾者的行为判断是否有酒驾或毒驾的嫌疑。

在实际的应用中，通常上述判断事故车辆是否能够撤离现场的提示消息与判断是否有酒驾或毒驾嫌疑的提示消息是都需要向客户端返回的，返回的顺序不做限定，当两者都返回时，服务端在接收到没有酒驾或毒驾嫌疑以及车辆可以撤离现场的提示消息后再向客户端返回上传事故方的证件信息以及联系方式的提示消息。

另外，为了提高服务端中前台数据展示端与向后台数据服务端之间数据传输的效率，本实施例中前台数据展示端基于进行二次封装的jquery，具体的是根据本实施例中的业务需求进行jquery的二次封装，这样可以省去数据传输过程中对各种参数的设置，实现向后台数据服务端更简便地传送JSON数据。

此外，还需要说明的是后台数据服务端响应前台数据展示端的流程基于HttpServlet+mybatis框架实现的，具体的HttpServlet+mybatis框架如图5所示，其中包括三层，第一层是接口层，用于接收前台数据展示端发送的数据请求；第二层是逻辑处理层，用于为接口层提供对应的服务；第三层为数据处理层，用于为逻辑处理层提供数据服务，具体的第三层是通过从数据库MySQL获取数据来为第二层提供数据服务的。要说明的是，后台数据服务端可以支持json/xml等数据格式。需要说明的是，图5中客户端(界面)为上述前台数据展示端，服务器端(tomcat)为上述后台数据服务端。

在实际应用中，由于交通管理部门通常有对交通事故进行统计和分析的需求。因此服务端还通过后台服务端将接收到的所有图像数据以及图像数据对应的交通事故信息进行多维度分类统计，其中交通事故信息包括事故发生的时间、事故发生的地点、事故的类型、事故处理方式；这样就可以使交通管理人员通过前台数据展示端进行交通事故的多维度查询。具体是由前台数据展示端发送由交通管理人员输入的交通事故信息查询维度；然后后台服务端根据所述事故信息查询维度向所述前台数据展示端返回与所述交通事故信息查询维度对应的所有事故信息。例如，输入的查询维度为事故发生的时间，具体的时间为一个月前，则后台服务端根据所述事故信息查询维度向所述前台数据展示端返回前一个月内所有的通过自助交通事故办理通道进行办理的所有交通事故的详细信息。

本发明实施例提供的交通事故处理的装置，与现有技术相比，当发生交通事故时，事故方可以通过客户端提供的自助办理通道，将事故现场的图像信息上传给能够认定事故责任方的服务端，服务端在接收到图像数据后可以及时地进行分析判断并迅速地将事故责任认定结果返回给客户端，使事故方可以通过客户端获知事故责任认定结果，节约了警方调配警力到事故现场进行事故责任认定的时间和人力，提高了处理交通事故的效率。

进一步的，本发明的最后一个实施例还提供了一种交通事故处理的系统，用以实现图1、图2以及图4所示的方法。本系统实施例与前述方法实施例对应，能够实现前述方法实施例中的全部内容。为便于阅读，本系统实施例仅对前述方法实施例中的内容进行概要性描述，不对方法实施例中的细节内容进行逐一赘述。该系统包括客户端以及服务端，其中，客户端包括上述图7所示的装置，所述服务端包括上述图8或图9所示的装置。具体的：

客户端，用于发送事故方触发的交通事故自助办理请求至服务端；在接收服务端发送的获取交通事故现场图像信息的提示信息后，发送通过智能终端拍摄获取的图像数据至交通事故自助办理的服务端，以使服务端根据图像数据确定交通事故责任的认定结果；

服务端，用于在接收到事故方触发的交通事故自助办理请求之后，发送用于获取交通事故现场图像信息的提示信息至客户端；接收客户端通过智能终端拍摄获取的图像数据，根据图像数据确定交通事故责任的认定结果。

本发明实施例提供的交通事故处理的系统，与现有技术相比，当发生交通事故时，事故方可以通过客户端提供的自助办理通道，将事故现场的图像信息上传给能够认定事故责任方的服务端，服务端在接收到图像数据后可以及时地进行分析判断并迅速地将事故责任认定结果返回给客户端，使事故方可以通过客户端获知事故责任认定结果，节约了警方调配警力到事故现场进行事故责任认定的时间和人力，提高了处理交通事故的效率。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。

可以理解的是，上述方法及装置中的相关特征可以相互参考。另外，上述实施例中的“第一”、“第二”等是用于区分各实施例，而并不代表各实施例的优劣。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统，装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

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

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

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

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

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

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

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