本發(fā)明涉及智能交通技術領域，尤其涉及一種交通事故處理的方法、裝置及系統(tǒng)。

背景技術：

隨著交通運輸?shù)牟粩喟l(fā)達，車輛的日益增多，交通事故處理也逐漸增多，一旦發(fā)生交通事故，尤其是重大、特大的交通事故，往往造成交通道路堵塞，降低城市道路運營效率，給社會帶來巨大的經濟損失。在交通事故中，可快速處理的輕微事故占車損事故比例的60％以上，快速的認定交通事故的責任方可解決交通道路堵塞問題，因此如何快速的認定交通事故的責任方成為目前亟待解決的問題。

目前，對于輕微事故的處理通常有兩種情況：一種是事故雙方確認事故責任方，并填寫交通事故快速處理協(xié)議書進行快速處理；另一種情況是事故雙方對于事故的責任方不能達成一致，需要報警等待交警處理，而等待交警處理，通常需要花費較長的時間，浪費人力物力，造成輕微事故處理的效率低。

技術實現(xiàn)要素：

鑒于上述問題，本發(fā)明提供一種交通事故處理的方法、裝置及系統(tǒng)。用以解決現(xiàn)有的輕微事故處理方式效率低的問題。

為解決上述技術問題，第一方面，本發(fā)明提供了一種交通事故處理的方法，所述方法應用于客戶端，所述方法包括：

發(fā)送事故方觸發(fā)的交通事故自助辦理請求至服務端；

在接收服務端發(fā)送的獲取交通事故現(xiàn)場圖像信息的提示信息后，發(fā)送通過智能終端拍攝獲取的圖像數(shù)據至交通事故自助辦理的服務端，以使所述服務端根據所述圖像數(shù)據確定交通事故責任的認定結果。

第二方面，本發(fā)明提供了另一種交通事故處理的方法，所述方法應用于服務端，所述方法包括：

在接收到事故方觸發(fā)的交通事故自助辦理請求之后，發(fā)送用于獲取交通事故現(xiàn)場圖像信息的提示信息至客戶端；

接收客戶端通過智能終端拍攝獲取的圖像數(shù)據，根據所述圖像數(shù)據確定交通事故責任的認定結果。

第三方面，本發(fā)明提供了一種交通事故處理的裝置，所述裝置位于客戶端側，所述裝置包括：

發(fā)送單元，用于發(fā)送事故方觸發(fā)的交通事故自助辦理請求至服務端；

接收單元，用于接收服務端發(fā)送的獲取交通事故現(xiàn)場圖像信息的提示信息；

所述發(fā)送單元，還用于發(fā)送通過智能終端拍攝獲取的圖像數(shù)據至交通事故自助辦理的服務端，以使所述服務端根據所述圖像數(shù)據確定交通事故責任的認定結果。

第四方面，本發(fā)明提供了一種交通事故處理的裝置，所述裝置位于服務端側，所述裝置包括：

接收單元，用于接收事故方觸發(fā)的交通事故自助辦理請求；

發(fā)送單元，用于發(fā)送用于獲取交通事故現(xiàn)場圖像信息的提示信息至客戶端；

所述接收單元，還用于接收客戶端通過智能終端拍攝獲取的圖像數(shù)據；

確定單元，用于根據所述圖像數(shù)據確定交通事故責任的認定結果。

第五方面，本發(fā)明提供了一種交通事故處理的系統(tǒng)，所述系統(tǒng)包括客戶端以及服務端：

所述客戶端，用于發(fā)送事故方觸發(fā)的交通事故自助辦理請求至所述服務端；在接收服務端發(fā)送的獲取交通事故現(xiàn)場圖像信息的提示信息后，發(fā)送通過智能終端拍攝獲取的圖像數(shù)據至交通事故自助辦理的服務端，以使所述服務端根據所述圖像數(shù)據確定交通事故責任的認定結果；

所述服務端，用于在接收到事故方觸發(fā)的交通事故自助辦理請求之后，發(fā)送用于獲取交通事故現(xiàn)場圖像信息的提示信息至所述客戶端；接收客戶端通過智能終端拍攝獲取的圖像數(shù)據，根據所述圖像數(shù)據確定交通事故責任的認定結果。

借由上述技術方案，本發(fā)明提供的交通事故處理的方法、裝置及系統(tǒng)，與現(xiàn)有技術相比，當發(fā)生交通事故時，事故方可以通過客戶端提供的自助辦理通道，將事故現(xiàn)場的圖像信息上傳給能夠認定事故責任方的服務端，使服務端快速地將事故責任認定結果返回給客戶端，使事故方可以通過客戶端獲知事故責任認定結果，節(jié)約了警方調配警力到事故現(xiàn)場進行事故責任認定的時間和人力，提高了處理交通事故的效率。

上述說明僅是本發(fā)明技術方案的概述，為了能夠更清楚了解本發(fā)明的技術手段，而可依照說明書的內容予以實施，并且為了讓本發(fā)明的上述和其它目的、特征和優(yōu)點能夠更明顯易懂，以下特舉本發(fā)明的具體實施方式。

附圖說明

通過閱讀下文優(yōu)選實施方式的詳細描述，各種其他的優(yōu)點和益處對于本領域普通技術人員將變得清楚明了。附圖僅用于示出優(yōu)選實施方式的目的，而并不認為是對本發(fā)明的限制。而且在整個附圖中，用相同的參考符號表示相同的部件。在附圖中：

圖1示出了本發(fā)明實施例提供的一種交通事故處理的方法的流程圖；

圖2示出了本發(fā)明實施例提供的另一種交通事故處理的方法的流程圖；

圖3示出了本發(fā)明實施例提供的一種交通事故自助辦理客戶端的流程圖；

圖4示出了本發(fā)明實施例提供的又一種交通事故處理的方法的流程圖；

圖5示出了本發(fā)明實施例提供的一種服務端基于HttpServlet+mybatis的設計框架；

圖6示出了本發(fā)明實施例提供的一種自助交通事故辦理的業(yè)務流程圖；

圖7示出了本發(fā)明實施例提供的一種交通事故處理的裝置的組成框圖；

圖8示出了本發(fā)明實施例提供的另一種交通事故處理的裝置的組成框圖；

圖9示出了本發(fā)明實施例提供的又一種交通事故處理的裝置的組成框圖。

具體實施方式

下面將參照附圖更詳細地描述本公開的示例性實施例。雖然附圖中顯示了本公開的示例性實施例，然而應當理解，可以以各種形式實現(xiàn)本公開而不應被這里闡述的實施例所限制。相反，提供這些實施例是為了能夠更透徹地理解本公開，并且能夠將本公開的范圍完整的傳達給本領域的技術人員。

為解決現(xiàn)有的輕微事故處理方式效率低的問題，本發(fā)明實施例提供了一種交通事故處理的方法，該方法位于客戶端，如圖1所示，該方法包括：

101、在接收事故方觸發(fā)的交通事故自助辦理請求后，將自助辦理請求至服務端。

首先需要說明的是，客戶端是為用戶提供交通事故自助辦理通道的程序，該程序可以設計為一個獨立的應用程序(Application，APP)安裝在智能終端中；也可以作為一個子應用依附在別的應用程序中，比如作為微信平臺、支付寶平臺等應用中的子應用。其中，智能終端包括智能手機、平板電腦ipad、車載智能終端、可穿戴設備等等。

其中，交通事故自助辦理請求是指用戶點擊確認進入交通事故自助辦理通道后生成的請求?？蛻舳私邮盏皆撜埱蠛螅瑢⒆灾k理請求至服務端，以使客戶端進入自助辦理交通事故流程。

102、在接收到服務端發(fā)送的獲取交通事故現(xiàn)場圖像信息的提示信息后，接收通過智能終端拍攝獲取的圖像數(shù)據。

自助辦理交通事故流程的第一步為接收服務端發(fā)送的獲取交通事故現(xiàn)場圖像信息的提示信息，然后調用智能終端的拍攝應用使用戶對交通事故現(xiàn)場進行拍攝，獲取智能終端拍攝的圖像數(shù)據。其中圖像數(shù)據即為交通事故現(xiàn)場圖像信息。

需要說明的是，圖像數(shù)據可以為靜態(tài)圖片也可以為動態(tài)的視頻。另外，為了保證用戶拍攝得到的圖像數(shù)據的盡可能符合交通事故圖像數(shù)據采集標準，通常會在拍攝之前提示用戶拍攝的要求。比如提示用戶拍攝在車頭位置拍攝的事故車輛的全貌的圖像、在車尾位置拍攝的事故車輛的全貌的圖像、接觸部位或者撞擊部位的局部的圖像等對進行事故定責有幫助的圖像。

103、將圖像數(shù)據發(fā)送給交通事故自助辦理的服務端。

具體的進行交通事故的處理分析是由服務端進行的，因此客戶端需要將獲取到的圖像數(shù)據發(fā)送給交通事故自助辦理的服務端。服務端接收到圖像數(shù)據后，會對事故現(xiàn)場對應的圖像數(shù)據進行分析，其中分析包括但不限于人工分析。對圖像數(shù)據進行分析主要是對交通事故責任進行認定，確定責任方。在服務端確定責任方之后，會及時的將認定的結果返回到客戶端。需要說明的是，服務端進行分析的圖像數(shù)據是符合交通事故圖像數(shù)據采集標準的圖像數(shù)據。

104、接收服務端返回的交通事故責任的認定結果。

接收到認定結果后，將認定結果輸出，使事故方可以獲取事故的責任方。需要說明的是，本實施例中服務端位于交通管理部門，因此，認定結果具有可信度。

通過自助交通事故處理通道，從事故發(fā)生到確定責任方，速度非?？欤啾扔诘却痪绞鹿尸F(xiàn)場進行事故處理的線下處理方式大大的節(jié)約了時間。另外，在將事故現(xiàn)場的圖像數(shù)據發(fā)送給服務端后，通常汽車司機就可以及時地將車輛及時撤離現(xiàn)場，這樣也避免了交通擁堵。

另外，實施例中客戶端的設計所使用計算機語言包括(Hypertext Preprocessor，PHP)、腳本語言JavaScript、超文本標記語言(HyperText Markup Language，HTML)以及層疊樣式表(Cascading Style Sheets，CSS)；服務端是基于瀏覽器的web端，服務端使用的計算機語言包括：Java、JavaScrip、HTML、CSS以及JavaScript。上述客戶端和服務端采用的技術中具體的是通過HTML+CSS實現(xiàn)頁面內容的表示和布局；通過PHP/Java訪問數(shù)據庫，取得數(shù)據，為頁面表示提供數(shù)據源；通過JavaScript實現(xiàn)頁面中的邏輯處理以及頁面遷移。

本發(fā)明實施例提供的交通事故處理的方法，與現(xiàn)有技術相比，當發(fā)生交通事故時，事故方可以通過客戶端提供的自助辦理通道，將事故現(xiàn)場的圖像信息上傳給能夠認定事故責任方的服務端，使服務端快速地將事故責任認定結果返回給客戶端，使事故方可以通過客戶端獲知事故責任認定結果，節(jié)約了警方調配警力到事故現(xiàn)場進行事故責任認定的時間和人力，提高了處理交通事故的效率。

為了對圖1所示方法的進一步細化及擴展，本實施例還提供了一種交通事故處理的方法，如圖2所示：

201、在接收事故方觸發(fā)的交通事故自助辦理請求后，將自助辦理請求至服務端。

該步驟的實現(xiàn)方式與圖1步驟101的實現(xiàn)方式相同，此處不再贅述。

202、輸出繼續(xù)進行交通事故自助處理的標準參數(shù)確認提示信息。

其中，繼續(xù)進行交通事故自助處理的標準參數(shù)為以下參數(shù)中的一項或者多項：交通事故發(fā)生時長是否在預設時間范圍內；是否有人員傷亡；是否設置警示標志。當標準參數(shù)為多項時，逐個輸出提示信息并接收確認信息。

203、若接收到對應標準參數(shù)提示信息的確認信息，則執(zhí)行在接收到服務端發(fā)送的獲取交通事故現(xiàn)場圖像信息的提示信息后，接收通過智能終端拍攝獲取的圖像數(shù)據。

其中，“執(zhí)行在接收到服務端發(fā)送的獲取交通事故現(xiàn)場圖像信息的提示信息后，接收通過智能終端拍攝獲取的圖像數(shù)據”的實現(xiàn)方式與圖1步驟102的實現(xiàn)方式相同不再贅述。

若接收到對應標準參數(shù)提示信息的否認信息，則調用報警機制進行交通事故報警。

其中對應的確認信息指在交通事故發(fā)生時長在預設時間范圍內、沒有人員傷亡、已經設置了警示標志中的一個或多個消息。另外，預設時間范圍是指服務端可以提供自助交通事故處理服務的時間。

具體的給出示例對上述情況進行說明，假設標準參數(shù)包括上述所有項。并且按照是否在預設時間范圍內、是否設置警示標志、是否有人員傷亡的順序輸出對應的提示消息。若用戶輸入的時間在預設時間范圍內，則繼續(xù)輸出是否設置警示標識的提示消息，若不在預設時間范圍內，則調用報警機制，進行交通事故報警，結束自助交通事故辦理；若已經設置了警示標志，則輸出是否有人員傷亡的提示消息，若用戶輸入的是有人員傷亡，則調用報警機制，進行交通事故報警，結束自助交通事故辦理，若用戶輸入的是沒有人員傷亡，則執(zhí)行在接收到服務端發(fā)送的獲取交通事故現(xiàn)場圖像信息的提示信息后，接收通過智能終端拍攝獲取的圖像數(shù)據。

需要說明的是，調用報警機制包括但不限于調用智能終端的通話功能，進行122電話報警。

204、將圖像數(shù)據發(fā)送給交通事故自助辦理的服務端。

具體的進行交通事故的處理分析是由服務端進行的，因此客戶端需要將獲取到的圖像數(shù)據發(fā)送給交通事故自助辦理的服務端。服務端接收到圖像數(shù)據后，會對事故現(xiàn)場對應的圖像數(shù)據進行分析。但是在實際的應用中，會存在用戶拍攝的圖像不符合交通事故圖像數(shù)據采集標準，此時服務端會向客戶端返回重新上傳圖像數(shù)據的提示信息，使客戶端重新獲取圖像數(shù)據，直到接收到服務端返回的圖像數(shù)據符合交通事故圖像數(shù)據采集標準的通知消息。需要說明的是，采集標準為圖像數(shù)據至少包括以下圖像：在車頭位置拍攝的事故車輛的全貌的圖像、在車尾位置拍攝的事故車輛的全貌的圖像以及事故車輛接觸部位或者撞擊部位的局部的圖像。

205、接收事故方上傳的證件信息以及聯(lián)系方式。

在接收服務端返回的交通事故責任的認定結果之前，接收事故方上傳的證件信息，其中證件信息包括駕駛證和行駛證。具體的接收的證件信息為證件照片，對應的接收證件信息的方式與前述接收事故現(xiàn)場的圖像數(shù)據的方式是相同的，都是通過智能終端拍攝獲得。另外對于智能終端中已經保存的證件照片，也可以通過文件選擇的方式直接上傳。

206、將證件信息以及聯(lián)系方式發(fā)送給服務端。

將證件信息以及聯(lián)系方式發(fā)送給服務端是為了使服務端根據證件信息以及聯(lián)系方式完善認定結果，得到事故定責書。另外判斷證件信息是否完整，還可以作為判斷是否有無證駕駛行為的依據。

當服務端對證件信息的完整性進行判斷后，向客戶端返回證件信息是否完整的提示消息。若客戶端接收到服務端返回的提示消息為證件信息完整的提示消息，則執(zhí)行步驟207；若接收到服務器返回的提示消息為證件信息不完整的提示消息，則調用報警機制進行交通事故報警。

207、接收服務端返回的事故定責書或者提取事故定責書的路徑信息。

具體的，客戶端接收到的可以是以圖片的形式直接展示在客戶端的事故定責書，也可以是接收到一個鏈接，然后使用戶通過該鏈接獲取事故定責書。

208、接收服務端返回的理賠服務點信息。

接收理賠服務點信息是為了使事故方可以確定進行理賠的地點，并自行約定時間進行后續(xù)的理賠。理賠服務點是由服務端選定的服務點。

另外，在步驟205之前，通常還需要輸出判斷事故車輛是否能夠撤離現(xiàn)場的提示消息，若客戶端接收到車輛無法撤離的消息后，會調用報警機制進行交通事故報警，提前結束自助交通事故處理的流程；若接收到車輛可以撤離的消息，則繼續(xù)步驟205。

在步驟205之前，通常還需要輸出判斷是否有酒駕或毒駕嫌疑的提示消息，若客戶端接收到有酒駕或毒駕嫌疑的提示消息后，會調用報警機制進行交通事故報警，提前結束自助交通事故處理的流程；若接收到沒有酒駕或毒駕嫌疑的提示消息，則繼續(xù)步驟205。需要說明的是，由于通常用戶沒有專業(yè)的測試工具進行酒駕或者毒駕的測試，所以通常是通過用戶自己根據酒駕或毒駕者的行為判斷是否有酒駕或毒駕的嫌疑。

在實際的應用中，通常上述判斷事故車輛是否能夠撤離現(xiàn)場的提示消息與判斷是否有酒駕或毒駕嫌疑的提示消息是都需要輸出的，輸出的順序不做限定，當兩者都輸出時，步驟205需在接收到沒有酒駕或毒駕嫌疑以及車輛可以撤離現(xiàn)場的提示消息后再執(zhí)行。

本實施例提供的交通事故處理的方法，不僅可以通過線上的方式快速確定事故責任方，另外還可以提供事故定責書以及理賠服務點信息，這樣實現(xiàn)了交通事故的快速處理和快速理賠。

另外，對應與圖2中的實施例，給出一種實際應用中交通事故自助辦理客戶端的流程圖，如圖3所示，具體過程說明：事故方選擇“自助辦理”；然后進行判斷當前時間超過受理時間范圍，其中的受理時間范圍對應于上述步驟202中的預設時間范圍；若果在受理時間范圍內則受理，并提示事故方設置警示標志；確定設置完警示標志后提示事故方查看事故現(xiàn)場是否有人員傷亡，若有人員傷亡則進行交通事故報警，結束交通事故自助辦理流程；若沒有人員傷亡，則獲取事故現(xiàn)場圖像，其中事故現(xiàn)場圖像對應于上述的圖像數(shù)據，然后等待事故圖像的審核結果；若通過審核，獲取事故責任認定結果，并提示將事故車輛撤離現(xiàn)場；若沒有通過審核，則重新獲取事故現(xiàn)場圖像，直到通過審核為止；若事故車輛無法撤離現(xiàn)場，則進行交通事故報警，結束交通事故自助辦理流程；若確定事故車輛可以撤離現(xiàn)場，則查看是否有酒駕或毒駕的嫌疑，若確認有酒駕或毒駕的嫌疑，則進行交通事故報警，結束交通事故自助辦理流程；若沒有酒駕或毒駕的嫌疑，則將獲取到的事故方的駕駛證和行駛證上傳給服務端，其中駕駛證和行駛證對應于上述的證件信息；若根據服務端返回的結果確定駕駛證和行駛證中缺少任一個證件，則進行交通事故報警，結束交通事故自助辦理流程；若駕駛證和行駛證都有，則讓事故方填寫聯(lián)系方式，以使服務端生成事故定責書；然后客戶端接收服務端返回的事故定責書使用戶可以獲取到事故定責書；最后客戶端可以讓事故方查看理賠服務點信息，該理賠服務點信息是由服務端返回的；最后結束整個交通事故自助辦理流程。

為解決現(xiàn)有的輕微事故處理方式效率低的問題，本發(fā)明實施例還提供了一種交通事故處理的方法，該方法位于服務端，如圖4所示，該方法包括：

301、在接收到事故方觸發(fā)的交通事故自助辦理請求之后，發(fā)送用于獲取交通事故現(xiàn)場圖像信息的提示信息至客戶端。

交通事故自助辦理請求是指用戶點擊確認進入交通事故自助辦理通道后生成的請求。客戶端接收到該請求后，將自助辦理請求至服務端，服務端接收到交通事故自助辦理請求后向客戶端返回獲取交通事故現(xiàn)場圖像信息的提示信息，以使客戶端向服務端發(fā)送事故現(xiàn)場的圖像數(shù)據。

302、接收客戶端發(fā)送的圖像數(shù)據。

服務端返回獲取交通事故現(xiàn)場圖像信息的提示信息后，客戶端會調用智能終端拍攝應用使用戶對交通事故現(xiàn)場進行拍攝，獲取拍攝的圖像數(shù)據。客戶端獲取圖像數(shù)據后將其發(fā)送給服務端，然后服務端接收到事故現(xiàn)場的圖像信息。

303、根據圖像數(shù)據確定交通事故責任的認定結果。

服務端接收到圖像數(shù)據后，會對事故現(xiàn)場對應的圖像數(shù)據進行分析，其中分析包括但不限于人工分析。對圖像數(shù)據進行分析主要是根據交通法則對交通事故責任進行認定，確定責任方。在服務端確定責任方之后，會及時的將認定的結果返回到客戶端。需要說明的是，本實施例中服務端位于交通管理部門，因此，認定結果具有可信度。

另外，實施例中客戶端的設計所使用計算機語言包括(Hypertext Preprocessor，PHP)、腳本語言JavaScript、超文本標記語言(HyperText Markup Language，HTML)以及層疊樣式表(Cascading Style Sheets，CSS)；服務端是基于瀏覽器的web端，服務端使用的計算機語言包括：Java、JavaScrip、HTML、CSS以及JavaScript。上述客戶端和服務端采用的技術中具體的是通過HTML+CSS實現(xiàn)頁面內容的表示和布局；通過PHP/Java訪問數(shù)據庫，取得數(shù)據，為頁面表示提供數(shù)據源；通過JavaScript實現(xiàn)頁面中的邏輯處理以及頁面遷移。

本發(fā)明實施例提供的交通事故處理的方法，與現(xiàn)有技術相比，當發(fā)生交通事故時，事故方可以通過客戶端提供的自助辦理通道，將事故現(xiàn)場的圖像信息上傳給能夠認定事故責任方的服務端，服務端在接收到圖像數(shù)據后可以及時地進行分析判斷并迅速地將事故責任認定結果返回給客戶端，使事故方可以通過客戶端獲知事故責任認定結果，節(jié)約了警方調配警力到事故現(xiàn)場進行事故責任認定的時間和人力，提高了處理交通事故的效率。

下面對圖4所示方法的進一步細化及擴展，如下所述：

上述步驟303中根據所述圖像數(shù)據確定交通事故責任的認定結果具體的實現(xiàn)過程，如下：

首先，判斷所述圖像數(shù)據是否符合交通事故圖像數(shù)據采集標準；

具體的判斷方式為：服務端的后臺數(shù)據服務端將接收到的圖像數(shù)據發(fā)送給服務端的前臺數(shù)據展示端，然后由專業(yè)的人員對圖像數(shù)據進行分析，并通過前臺數(shù)據展示端將判斷的結果返回給后臺服務端。另外在實際的應用中，也可以將交通事故圖像數(shù)據的采集標準提前設置在后臺數(shù)據服務端，由后臺數(shù)據服務端進行自動化的判斷。

需要說明的是，采集標準為獲取到的圖像數(shù)據至少包括以下圖像：在車頭位置拍攝的事故車輛的全貌的圖像、在車尾位置拍攝的事故車輛的全貌的圖像以及事故車輛接觸部位或者撞擊部位的局部的圖像。在實際的應用中還可能包括對決定事故責任方有幫助的圖像，具體的有幫助的圖像需要根據具體的事故進行設置。

其次，根據判斷結果決定是否返回認定結果至客戶端。

若判斷結果為圖像數(shù)據符合交通事故圖像數(shù)據采集標準，則對圖像數(shù)據進行分析獲取交通事故責任的認定結果，并將認定結果發(fā)送給客戶端。

將認定結果發(fā)送給客戶端，可以使事故方獲知事故的責任方。

若判斷結果為圖像數(shù)據不符合交通事故圖像數(shù)據采集標準，則服務端向所述客戶端發(fā)送圖像數(shù)據不符合交通事故圖像數(shù)據采集標準的通知消息，以使所述客戶端根據所述不符合交通事故圖像數(shù)據采集標準的通知消息重新通過智能終端拍攝獲取所述圖像數(shù)據。直到到服務端接收的圖像數(shù)據符合交通事故圖像數(shù)據采集標準后，再對圖像數(shù)據進行分析并確定事故責任的認定結果。

在步驟303之前，為了完善認定結果，生成完善的事故定責書，因此服務端還會向客戶端返回上傳事故方的證件信息以及聯(lián)系方式的提示消息，然后使客戶端獲取事故方上傳的證件信息以聯(lián)系方式后發(fā)送給服務端，其中證件信息包括駕駛證和行駛證。在服務端獲取證件信息以及聯(lián)系方式后，服務端還需要對證件信息的完整性進行判斷，若判斷證件信息是完整的，則會向客戶端返回證件信息完整的提示信息，并依據完整的證件信息以及聯(lián)系方式完善事故定責書，然后將事故定責書或者提取事故定責書的路徑返回給客戶端，使客戶端獲取事故定責書。若判斷證件信息是不完整的，則會向客戶端返回證件信息不完整的提示信息，以使客戶端根據證件信息不完整的提示消息及時的調用報警機制進行交通事故報警。需要說明的是，調用報警機制包括但不限于調用智能終端的通話功能，進行122電話報警。

在服務端向客戶端返回事故定責書或者提取事故定責書的路徑之后，為了使事故方可以及時獲知理賠服務點，服務端還會向客戶端返回理賠服務點信息，以使事故方可以自行約定時間進行后續(xù)的理賠。

另外，在服務端向客戶端返回上傳事故方的證件信息以及聯(lián)系方式的提示消息之前，服務端還可以向客戶端返回判斷事故車輛是否能夠撤離現(xiàn)場的提示消息，若接收到客戶端返回事故車輛可以撤離現(xiàn)場的確認消息，則繼續(xù)向客戶端返回上傳事故方的證件信息以及聯(lián)系方式的提示消息。若接收到客戶端返回事故車輛不可以撤離現(xiàn)場的確認消息。則使客戶端執(zhí)行調用報警機制進行交通事故報警，提前結束自助交通事故處理的流程。

另外，在服務端向客戶端返回上傳事故方的證件信息以及聯(lián)系方式的提示消息之前，服務端還可以向客戶端返回判斷是否有酒駕或毒駕嫌疑的提示消息，若接收到客戶端返回沒有酒駕或毒駕嫌疑的提示消息后，則繼續(xù)向客戶端返回上傳事故方的證件信息以及聯(lián)系方式的提示消息；若接收到客戶端有酒駕或毒駕嫌疑的提示消息，則使客戶端執(zhí)行調用報警機制進行交通事故報警，提前結束自助交通事故處理的流程。需要說明的是，因為通常用戶沒有專業(yè)的測試工具進行酒駕或者毒駕的測試，只能通過用戶自己根據酒駕或毒駕者的行為判斷是否有酒駕或毒駕的嫌疑。

在實際的應用中，通常上述判斷事故車輛是否能夠撤離現(xiàn)場的提示消息與判斷是否有酒駕或毒駕嫌疑的提示消息是都需要向客戶端返回的，返回的順序不做限定，當兩者都返回時，服務端在接收到沒有酒駕或毒駕嫌疑以及車輛可以撤離現(xiàn)場的提示消息后再向客戶端返回上傳事故方的證件信息以及聯(lián)系方式的提示消息。

另外，為了提高服務端中前臺數(shù)據展示端與向后臺數(shù)據服務端之間數(shù)據傳輸?shù)男?，本實施例中前臺數(shù)據展示端基于進行二次封裝的jquery，具體的是根據本實施例中的業(yè)務需求進行jquery的二次封裝，這樣可以省去數(shù)據傳輸過程中對各種參數(shù)的設置，實現(xiàn)向后臺數(shù)據服務端更簡便地傳送JSON數(shù)據。

此外，還需要說明的是后臺數(shù)據服務端響應前臺數(shù)據展示端的流程基于HttpServlet+mybatis框架實現(xiàn)的，具體的HttpServlet+mybatis框架如圖5所示，其中包括三層，第一層是接口層，用于接收前臺數(shù)據展示端發(fā)送的數(shù)據請求；第二層是邏輯處理層，用于為接口層提供對應的服務；第三層為數(shù)據處理層，用于為邏輯處理層提供數(shù)據服務，具體的第三層是通過從數(shù)據庫MySQL獲取數(shù)據來為第二層提供數(shù)據服務的。要說明的是，后臺數(shù)據服務端可以支持json/xml等數(shù)據格式。需要說明的是，圖5中客戶端(界面)為上述前臺數(shù)據展示端，服務器端(tomcat)為上述后臺數(shù)據服務端。

在實際應用中，由于交通管理部門通常有對交通事故進行統(tǒng)計和分析的需求。因此服務端還通過后臺服務端將接收到的所有圖像數(shù)據以及圖像數(shù)據對應的交通事故信息進行多維度分類統(tǒng)計，其中交通事故信息包括事故發(fā)生的時間、事故發(fā)生的地點、事故的類型、事故處理方式；這樣就可以使交通管理人員通過前臺數(shù)據展示端進行交通事故的多維度查詢。具體是由前臺數(shù)據展示端發(fā)送由交通管理人員輸入的交通事故信息查詢維度；然后后臺服務端根據所述事故信息查詢維度向所述前臺數(shù)據展示端返回與所述交通事故信息查詢維度對應的所有事故信息。例如，輸入的查詢維度為事故發(fā)生的時間，具體的時間為一個月前，則后臺服務端根據所述事故信息查詢維度向所述前臺數(shù)據展示端返回前一個月內所有的通過自助交通事故辦理通道進行辦理的所有交通事故的詳細信息。

最后，結合上述圖1、圖2以及圖4中實施例的實現(xiàn)，給出了實際應用中實現(xiàn)自助交通事故辦理的整體的一種業(yè)務流程圖，如圖6所示。其中，左側為現(xiàn)有的舊業(yè)務流程，右側為本實施例對應的新業(yè)務流程，可以看到新業(yè)務流程中，當事人對應上述的事故方，各大隊指揮中心受理定責對應服務端接收當事人通過微信事故報警途徑進行自助交通事故辦理，省去了舊業(yè)務中當事人122事故報警、122接處警中心轉接警到各大隊指揮中心的過程，另外大大減少了進行調用外勤交警的情況。當當事人根據各大隊指揮中心返回的理賠服務點之后進行理賠后，理賠服務點將相關的事故車輛查詢以及定損的處理情況返回給各大隊指揮中心。對于事故責任方沒有對應保險公司的需要理賠服務點聯(lián)系事故責任方索要理賠金額。綜上可以看到新的業(yè)務流程更加的省時省力，實現(xiàn)了交通事故的快處快賠。

進一步的，作為對上述各實施例的實現(xiàn)，本發(fā)明實施例的另一實施例還提供了一種交通事故處理的裝置，所述裝置位于客戶端側，用于實現(xiàn)上述圖1以及圖2所述的方法。如圖7所示，該裝置包括：發(fā)送單元41以及接收單元42。

發(fā)送單元41，用于發(fā)送事故方觸發(fā)的交通事故自助辦理請求至服務端；

首先需要說明的是，客戶端是為用戶提供交通事故自助辦理通道的程序，該程序可以設計為一個獨立的應用程序(Application，APP)安裝在智能終端中；也可以作為一個子應用依附在別的應用程序中，比如作為微信平臺、支付寶平臺等應用中的子應用。其中，智能終端包括智能手機、平板電腦ipad、車載智能終端、可穿戴設備等等。

其中，交通事故自助辦理請求是指用戶點擊確認進入交通事故自助辦理通道后生成的請求?？蛻舳私邮盏皆撜埱蠛?，將自助辦理請求至服務端，以使客戶端進入自助辦理交通事故流程。

接收單元42，用于接收服務端發(fā)送的獲取交通事故現(xiàn)場圖像信息的提示信息；

發(fā)送單元41，還用于發(fā)送通過智能終端拍攝獲取的圖像數(shù)據至交通事故自助辦理的服務端，以使服務端根據圖像數(shù)據確定交通事故責任的認定結果。

自助辦理交通事故流程的第一步為接收服務端發(fā)送的獲取交通事故現(xiàn)場圖像信息的提示信息，然后調用智能終端的拍攝應用使用戶對交通事故現(xiàn)場進行拍攝，獲取智能終端拍攝的圖像數(shù)據。其中圖像數(shù)據即為交通事故現(xiàn)場圖像信息。

需要說明的是，圖像數(shù)據可以為靜態(tài)圖片也可以為動態(tài)的視頻。另外，為了保證用戶拍攝得到的圖像數(shù)據的盡可能符合交通事故圖像數(shù)據采集標準，通常會在拍攝之前提示用戶拍攝的要求。比如提示用戶拍攝在車頭位置拍攝的事故車輛的全貌的圖像、在車尾位置拍攝的事故車輛的全貌的圖像、接觸部位或者撞擊部位的局部的圖像等對進行事故定責有幫助的圖像。

由于進行交通事故的處理分析是由服務端進行的，因此客戶端需要將獲取到的圖像數(shù)據發(fā)送給交通事故自助辦理的服務端。服務端接收到圖像數(shù)據后，會對事故現(xiàn)場對應的圖像數(shù)據進行分析，其中分析包括但不限于人工分析。對圖像數(shù)據進行分析主要是對交通事故責任進行認定，確定責任方。在服務端確定責任方之后，會及時的將認定的結果返回到客戶端。需要說明的是，服務端進行分析的圖像數(shù)據是符合交通事故圖像數(shù)據采集標準的圖像數(shù)據。

接收到認定結果后，將認定結果輸出，使事故方可以獲取事故的責任方。需要說明的是，本實施例中服務端位于交通管理部門，因此，認定結果具有可信度。

通過自助交通事故處理通道，從事故發(fā)生到確定責任方，速度非?？欤啾扔诘却痪绞鹿尸F(xiàn)場進行事故處理的線下處理方式大大的節(jié)約了時間。另外，在將事故現(xiàn)場的圖像數(shù)據發(fā)送給服務端后，通常汽車司機就可以及時地將車輛及時撤離現(xiàn)場，這樣也避免了交通擁堵。

另外，實施例中客戶端的設計所使用計算機語言包括(Hypertext Preprocessor，PHP)、腳本語言JavaScript、超文本標記語言(HyperText Markup Language，HTML)以及層疊樣式表(Cascading Style Sheets，CSS)；服務端是基于瀏覽器的web端，服務端使用的計算機語言包括：Java、JavaScrip、HTML、CSS以及JavaScript。上述客戶端和服務端采用的技術中具體的是通過HTML+CSS實現(xiàn)頁面內容的表示和布局；通過PHP/Java訪問數(shù)據庫，取得數(shù)據，為頁面表示提供數(shù)據源；通過JavaScript實現(xiàn)頁面中的邏輯處理以及頁面遷移。

另外，在實際應用中，對于某些交通事故是必須有交警到現(xiàn)場進行處理的，在這種時候就不需要再通過上述自助辦理交通事故的流程進行事故的定責。因此，在客戶端接收服務端發(fā)送的獲取交通事故現(xiàn)場圖像信息的提示信息之前，客戶端還會輸出繼續(xù)進行交通事故自助處理的標準參數(shù)確認提示信息。若接收到對應標準參數(shù)提示信息的確認信息，則執(zhí)行在接收到服務端發(fā)送的獲取交通事故現(xiàn)場圖像信息的提示信息后，接收通過智能終端拍攝獲取的圖像數(shù)據；若接收到對應標準參數(shù)提示信息的否認信息，則調用報警機制進行交通事故報警，調用報警機制包括但不限于調用智能終端的通話功能，進行122電話報警。

其中，繼續(xù)進行交通事故自助處理的標準參數(shù)為以下參數(shù)中的一項或者多項：交通事故發(fā)生時長是否在預設時間范圍內；是否有人員傷亡；是否設置警示標志。當標準參數(shù)為多項時，逐個輸出提示信息并接收確認信息。對應的確認信息指在交通事故發(fā)生時長在預設時間范圍內、沒有人員傷亡、已經設置了警示標志中的一個或多個消息。另外，預設時間范圍是指服務端可以提供自助交通事故處理服務的時間。

另外，為了得到完善的認定結果，即事故定責書，在接收服務端返回的認定結果之前，客戶端還需要接收事故方上傳的證件信息以及聯(lián)系方式，將證件信息以及聯(lián)系方式發(fā)送給服務端，以使服務端對證件信息的完整性進行判斷后，完善認定結果，生成事故定責書，并將事故定責書返回給客戶端。需要說明的是，若服務端在對證件信息完整性判斷后，若確定證件信息不完整性，則會返回證件信息不完整性的提示消息給客戶端，使客戶端調用報警機制進行交通事故報警。

其中，客戶端接收到的事故定責書的形式可以是以圖片的形式直接展示在客戶端的事故定責書，也可以是接收到提取事故定責書的路徑信息，比如一個鏈接，然后使用戶通過該鏈接獲取事故定責書。

在接收事故方上傳的證件信息以及聯(lián)系方式之前，通常還需要輸出判斷事故車輛是否能夠撤離現(xiàn)場的提示消息，若客戶端接收到車輛無法撤離的消息后，會調用報警機制進行交通事故報警，提前結束自助交通事故處理的流程；若接收到車輛可以撤離的消息，則繼續(xù)接收事故方上傳的證件信息以及聯(lián)系方式。

在接收事故方上傳的證件信息以及聯(lián)系方式之前，還需要輸出判斷是否有酒駕或毒駕嫌疑的提示消息，若客戶端接收到有酒駕或毒駕嫌疑的提示消息后，會調用報警機制進行交通事故報警，提前結束自助交通事故處理的流程；若接收到沒有酒駕或毒駕嫌疑的提示消息，則繼續(xù)接收事故方上傳的證件信息以及聯(lián)系方式。需要說明的是，由于通常用戶沒有專業(yè)的測試工具進行酒駕或者毒駕的測試，所以通常是通過用戶自己根據酒駕或毒駕者的行為判斷是否有酒駕或毒駕的嫌疑。在實際的應用中，通常上述判斷事故車輛是否能夠撤離現(xiàn)場的提示消息與判斷是否有酒駕或毒駕嫌疑的提示消息是都需要輸出的，輸出的順序不做限定，當兩者都輸出時，接收事故方上傳的證件信息以及聯(lián)系方式的動作需在接收到沒有酒駕或毒駕嫌疑以及車輛可以撤離現(xiàn)場的提示消息后再執(zhí)行。

另外，在客戶端接收事故定責書或提取事故定責書的路徑信息后，還會接收服務端返回的理賠服務點信息。接收理賠服務點信息是為了使事故方可以確定進行理賠的地點，并自行約定時間進行后續(xù)的理賠。理賠服務點是由服務端選定的服務點。

本發(fā)明實施例提供的交通事故處理的方法，與現(xiàn)有技術相比，當發(fā)生交通事故時，事故方可以通過客戶端提供的自助辦理通道，將事故現(xiàn)場的圖像信息上傳給能夠認定事故責任方的服務端，使服務端快速地將事故責任認定結果返回給客戶端，使事故方可以通過客戶端獲知事故責任認定結果，節(jié)約了警方調配警力到事故現(xiàn)場進行事故責任認定的時間和人力，提高了處理交通事故的效率。

進一步的，作為對上述各實施例的實現(xiàn)，本發(fā)明實施例的另一實施例還提供了一種交通事故處理的裝置，所述裝置位于服務端側，用于實現(xiàn)上述圖4所述的方法。如圖8所示，該裝置包括：接收單元51、發(fā)送單元52以及確定單元53。

接收單元51，用于接收事故方觸發(fā)的交通事故自助辦理請求；

交通事故自助辦理請求是指用戶點擊確認進入交通事故自助辦理通道后生成的請求。

發(fā)送單元52，用于發(fā)送用于獲取交通事故現(xiàn)場圖像信息的提示信息至客戶端；

接收單元51，還用于接收客戶端通過智能終端拍攝獲取的圖像數(shù)據；

服務端返回獲取交通事故現(xiàn)場圖像信息的提示信息后，客戶端會調用智能終端拍攝應用使用戶對交通事故現(xiàn)場進行拍攝，獲取拍攝的圖像數(shù)據?？蛻舳双@取圖像數(shù)據后將其發(fā)送給服務端，然后服務端接收到事故現(xiàn)場的圖像信息。

確定單元53，用于根據圖像數(shù)據確定交通事故責任的認定結果。

服務端接收到圖像數(shù)據后，會對事故現(xiàn)場對應的圖像數(shù)據進行分析，其中分析包括但不限于人工分析。對圖像數(shù)據進行分析主要是根據交通法則對交通事故責任進行認定，確定責任方。在服務端確定責任方之后，會及時的將認定的結果返回到客戶端。需要說明的是，本實施例中服務端位于交通管理部門，因此，認定結果具有可信度。

如圖9所示，裝置進一步包括：

判斷單元54，用于判斷圖像數(shù)據是否符合交通事故圖像數(shù)據采集標準；

具體的判斷方式為：服務端的后臺數(shù)據服務端將接收到的圖像數(shù)據發(fā)送給服務端的前臺數(shù)據展示端，然后由專業(yè)的人員對圖像數(shù)據進行分析，并通過前臺數(shù)據展示端將判斷的結果返回給后臺服務端。另外在實際的應用中，也可以將交通事故圖像數(shù)據的采集標準提前設置在后臺數(shù)據服務端，由后臺數(shù)據服務端進行自動化的判斷。

需要說明的是，采集標準為獲取到的圖像數(shù)據至少包括以下圖像：在車頭位置拍攝的事故車輛的全貌的圖像、在車尾位置拍攝的事故車輛的全貌的圖像以及事故車輛接觸部位或者撞擊部位的局部的圖像。在實際的應用中還可能包括對決定事故責任方有幫助的圖像，具體的有幫助的圖像需要根據具體的事故進行設置。

分析單元55，用于對圖像數(shù)據進行分析獲取交通事故責任的認定結果，并將認定結果發(fā)送給客戶端。

若判斷結果為圖像數(shù)據符合交通事故圖像數(shù)據采集標準，則對圖像數(shù)據進行分析獲取交通事故責任的認定結果，并將認定結果發(fā)送給客戶端。

將認定結果發(fā)送給客戶端，可以使事故方獲知事故的責任方。

若判斷結果為圖像數(shù)據不符合交通事故圖像數(shù)據采集標準，則服務端向所述客戶端發(fā)送圖像數(shù)據不符合交通事故圖像數(shù)據采集標準的通知消息，以使所述客戶端根據所述不符合交通事故圖像數(shù)據采集標準的通知消息重新通過智能終端拍攝獲取所述圖像數(shù)據。直到到服務端接收的圖像數(shù)據符合交通事故圖像數(shù)據采集標準后，再對圖像數(shù)據進行分析并確定事故責任的認定結果。

判斷單元54中的采集標準為圖像數(shù)據至少包括以下圖像：

在車頭位置拍攝的事故車輛的全貌的圖像、在車尾位置拍攝的事故車輛的全貌的圖像以及事故車輛接觸部位或者撞擊部位的局部的圖像。

為了完善認定結果，生成完善的事故定責書，因此服務端還會向客戶端返回上傳事故方的證件信息以及聯(lián)系方式的提示消息，然后使客戶端獲取事故方上傳的證件信息以聯(lián)系方式后發(fā)送給服務端，其中證件信息包括駕駛證和行駛證。在服務端獲取證件信息以及聯(lián)系方式后，服務端還需要對證件信息的完整性進行判斷，若判斷證件信息是完整的，則會向客戶端返回證件信息完整的提示信息，并依據完整的證件信息以及聯(lián)系方式完善事故定責書，然后將事故定責書或者提取事故定責書的路徑返回給客戶端，使客戶端獲取事故定責書。若判斷證件信息是不完整的，則會向客戶端返回證件信息不完整的提示信息，以使客戶端根據證件信息不完整的提示消息及時的調用報警機制進行交通事故報警。需要說明的是，調用報警機制包括但不限于調用智能終端的通話功能，進行122電話報警。

在服務端向客戶端返回事故定責書或者提取事故定責書的路徑之后，為了使事故方可以及時獲知理賠服務點，服務端還會向客戶端返回理賠服務點信息，以使事故方可以自行約定時間進行后續(xù)的理賠。

另外，在服務端向客戶端返回上傳事故方的證件信息以及聯(lián)系方式的提示消息之前，服務端還可以向客戶端返回判斷事故車輛是否能夠撤離現(xiàn)場的提示消息，若接收到客戶端返回事故車輛可以撤離現(xiàn)場的確認消息，則繼續(xù)向客戶端返回上傳事故方的證件信息以及聯(lián)系方式的提示消息。若接收到客戶端返回事故車輛不可以撤離現(xiàn)場的確認消息。則使客戶端執(zhí)行調用報警機制進行交通事故報警，提前結束自助交通事故處理的流程。

另外，在服務端向客戶端返回上傳事故方的證件信息以及聯(lián)系方式的提示消息之前，服務端還可以向客戶端返回判斷是否有酒駕或毒駕嫌疑的提示消息，若接收到客戶端返回沒有酒駕或毒駕嫌疑的提示消息后，則繼續(xù)向客戶端返回上傳事故方的證件信息以及聯(lián)系方式的提示消息；若接收到客戶端有酒駕或毒駕嫌疑的提示消息，則使客戶端執(zhí)行調用報警機制進行交通事故報警，提前結束自助交通事故處理的流程。需要說明的是，因為通常用戶沒有專業(yè)的測試工具進行酒駕或者毒駕的測試，只能通過用戶自己根據酒駕或毒駕者的行為判斷是否有酒駕或毒駕的嫌疑。

在實際的應用中，通常上述判斷事故車輛是否能夠撤離現(xiàn)場的提示消息與判斷是否有酒駕或毒駕嫌疑的提示消息是都需要向客戶端返回的，返回的順序不做限定，當兩者都返回時，服務端在接收到沒有酒駕或毒駕嫌疑以及車輛可以撤離現(xiàn)場的提示消息后再向客戶端返回上傳事故方的證件信息以及聯(lián)系方式的提示消息。

另外，為了提高服務端中前臺數(shù)據展示端與向后臺數(shù)據服務端之間數(shù)據傳輸?shù)男?，本實施例中前臺數(shù)據展示端基于進行二次封裝的jquery，具體的是根據本實施例中的業(yè)務需求進行jquery的二次封裝，這樣可以省去數(shù)據傳輸過程中對各種參數(shù)的設置，實現(xiàn)向后臺數(shù)據服務端更簡便地傳送JSON數(shù)據。

此外，還需要說明的是后臺數(shù)據服務端響應前臺數(shù)據展示端的流程基于HttpServlet+mybatis框架實現(xiàn)的，具體的HttpServlet+mybatis框架如圖5所示，其中包括三層，第一層是接口層，用于接收前臺數(shù)據展示端發(fā)送的數(shù)據請求；第二層是邏輯處理層，用于為接口層提供對應的服務；第三層為數(shù)據處理層，用于為邏輯處理層提供數(shù)據服務，具體的第三層是通過從數(shù)據庫MySQL獲取數(shù)據來為第二層提供數(shù)據服務的。要說明的是，后臺數(shù)據服務端可以支持json/xml等數(shù)據格式。需要說明的是，圖5中客戶端(界面)為上述前臺數(shù)據展示端，服務器端(tomcat)為上述后臺數(shù)據服務端。

在實際應用中，由于交通管理部門通常有對交通事故進行統(tǒng)計和分析的需求。因此服務端還通過后臺服務端將接收到的所有圖像數(shù)據以及圖像數(shù)據對應的交通事故信息進行多維度分類統(tǒng)計，其中交通事故信息包括事故發(fā)生的時間、事故發(fā)生的地點、事故的類型、事故處理方式；這樣就可以使交通管理人員通過前臺數(shù)據展示端進行交通事故的多維度查詢。具體是由前臺數(shù)據展示端發(fā)送由交通管理人員輸入的交通事故信息查詢維度；然后后臺服務端根據所述事故信息查詢維度向所述前臺數(shù)據展示端返回與所述交通事故信息查詢維度對應的所有事故信息。例如，輸入的查詢維度為事故發(fā)生的時間，具體的時間為一個月前，則后臺服務端根據所述事故信息查詢維度向所述前臺數(shù)據展示端返回前一個月內所有的通過自助交通事故辦理通道進行辦理的所有交通事故的詳細信息。

本發(fā)明實施例提供的交通事故處理的裝置，與現(xiàn)有技術相比，當發(fā)生交通事故時，事故方可以通過客戶端提供的自助辦理通道，將事故現(xiàn)場的圖像信息上傳給能夠認定事故責任方的服務端，服務端在接收到圖像數(shù)據后可以及時地進行分析判斷并迅速地將事故責任認定結果返回給客戶端，使事故方可以通過客戶端獲知事故責任認定結果，節(jié)約了警方調配警力到事故現(xiàn)場進行事故責任認定的時間和人力，提高了處理交通事故的效率。

進一步的，本發(fā)明的最后一個實施例還提供了一種交通事故處理的系統(tǒng)，用以實現(xiàn)圖1、圖2以及圖4所示的方法。本系統(tǒng)實施例與前述方法實施例對應，能夠實現(xiàn)前述方法實施例中的全部內容。為便于閱讀，本系統(tǒng)實施例僅對前述方法實施例中的內容進行概要性描述，不對方法實施例中的細節(jié)內容進行逐一贅述。該系統(tǒng)包括客戶端以及服務端，其中，客戶端包括上述圖7所示的裝置，所述服務端包括上述圖8或圖9所示的裝置。具體的：

客戶端，用于發(fā)送事故方觸發(fā)的交通事故自助辦理請求至服務端；在接收服務端發(fā)送的獲取交通事故現(xiàn)場圖像信息的提示信息后，發(fā)送通過智能終端拍攝獲取的圖像數(shù)據至交通事故自助辦理的服務端，以使服務端根據圖像數(shù)據確定交通事故責任的認定結果；

服務端，用于在接收到事故方觸發(fā)的交通事故自助辦理請求之后，發(fā)送用于獲取交通事故現(xiàn)場圖像信息的提示信息至客戶端；接收客戶端通過智能終端拍攝獲取的圖像數(shù)據，根據圖像數(shù)據確定交通事故責任的認定結果。

本發(fā)明實施例提供的交通事故處理的系統(tǒng)，與現(xiàn)有技術相比，當發(fā)生交通事故時，事故方可以通過客戶端提供的自助辦理通道，將事故現(xiàn)場的圖像信息上傳給能夠認定事故責任方的服務端，服務端在接收到圖像數(shù)據后可以及時地進行分析判斷并迅速地將事故責任認定結果返回給客戶端，使事故方可以通過客戶端獲知事故責任認定結果，節(jié)約了警方調配警力到事故現(xiàn)場進行事故責任認定的時間和人力，提高了處理交通事故的效率。

在上述實施例中，對各個實施例的描述都各有側重，某個實施例中沒有詳述的部分，可以參見其他實施例的相關描述。

可以理解的是，上述方法及裝置中的相關特征可以相互參考。另外，上述實施例中的“第一”、“第二”等是用于區(qū)分各實施例，而并不代表各實施例的優(yōu)劣。

所屬領域的技術人員可以清楚地了解到，為描述的方便和簡潔，上述描述的系統(tǒng)，裝置和單元的具體工作過程，可以參考前述方法實施例中的對應過程，在此不再贅述。

在此提供的算法和顯示不與任何特定計算機、虛擬系統(tǒng)或者其它設備固有相關。各種通用系統(tǒng)也可以與基于在此的示教一起使用。根據上面的描述，構造這類系統(tǒng)所要求的結構是顯而易見的。此外，本發(fā)明也不針對任何特定編程語言。應當明白，可以利用各種編程語言實現(xiàn)在此描述的本發(fā)明的內容，并且上面對特定語言所做的描述是為了披露本發(fā)明的最佳實施方式。

在此處所提供的說明書中，說明了大量具體細節(jié)。然而，能夠理解，本發(fā)明的實施例可以在沒有這些具體細節(jié)的情況下實踐。在一些實例中，并未詳細示出公知的方法、結構和技術，以便不模糊對本說明書的理解。

類似地，應當理解，為了精簡本公開并幫助理解各個發(fā)明方面中的一個或多個，在上面對本發(fā)明的示例性實施例的描述中，本發(fā)明的各個特征有時被一起分組到單個實施例、圖、或者對其的描述中。然而，并不應將該公開的方法解釋成反映如下意圖：即所要求保護的本發(fā)明要求比在每個權利要求中所明確記載的特征更多的特征。更確切地說，如下面的權利要求書所反映的那樣，發(fā)明方面在于少于前面公開的單個實施例的所有特征。因此，遵循具體實施方式的權利要求書由此明確地并入該具體實施方式，其中每個權利要求本身都作為本發(fā)明的單獨實施例。

本領域那些技術人員可以理解，可以對實施例中的設備中的模塊進行自適應性地改變并且把它們設置在與該實施例不同的一個或多個設備中。可以把實施例中的模塊或單元或組件組合成一個模塊或單元或組件，以及此外可以把它們分成多個子模塊或子單元或子組件。除了這樣的特征和/或過程或者單元中的至少一些是相互排斥之外，可以采用任何組合對本說明書(包括伴隨的權利要求、摘要和附圖)中公開的所有特征以及如此公開的任何方法或者設備的所有過程或單元進行組合。除非另外明確陳述，本說明書(包括伴隨的權利要求、摘要和附圖)中公開的每個特征可以由提供相同、等同或相似目的的替代特征來代替。

此外，本領域的技術人員能夠理解，盡管在此所述的一些實施例包括其它實施例中所包括的某些特征而不是其它特征，但是不同實施例的特征的組合意味著處于本發(fā)明的范圍之內并且形成不同的實施例。例如，在下面的權利要求書中，所要求保護的實施例的任意之一都可以以任意的組合方式來使用。

本發(fā)明的各個部件實施例可以以硬件實現(xiàn)，或者以在一個或者多個處理器上運行的軟件模塊實現(xiàn)，或者以它們的組合實現(xiàn)。本領域的技術人員應當理解，可以在實踐中使用微處理器或者數(shù)字信號處理器(DSP)來實現(xiàn)根據本發(fā)明實施例的發(fā)明名稱(如交通事故處理的裝置)中的一些或者全部部件的一些或者全部功能。本發(fā)明還可以實現(xiàn)為用于執(zhí)行這里所描述的方法的一部分或者全部的設備或者裝置程序(例如，計算機程序和計算機程序產品)。這樣的實現(xiàn)本發(fā)明的程序可以存儲在計算機可讀介質上，或者可以具有一個或者多個信號的形式。這樣的信號可以從因特網網站上下載得到，或者在載體信號上提供，或者以任何其他形式提供。

應該注意的是上述實施例對本發(fā)明進行說明而不是對本發(fā)明進行限制，并且本領域技術人員在不脫離所附權利要求的范圍的情況下可設計出替換實施例。在權利要求中，不應將位于括號之間的任何參考符號構造成對權利要求的限制。單詞“包含”不排除存在未列在權利要求中的元件或步驟。位于元件之前的單詞“一”或“一個”不排除存在多個這樣的元件。本發(fā)明可以借助于包括有若干不同元件的硬件以及借助于適當編程的計算機來實現(xiàn)。在列舉了若干裝置的單元權利要求中，這些裝置中的若干個可以是通過同一個硬件項來具體體現(xiàn)。單詞第一、第二、以及第三等的使用不表示任何順序。可將這些單詞解釋為名稱。