這裡將詳細地對示例性實施例進行說明，其示例表示在圖式中。下面的描述涉及圖式時，除非另有表示，不同圖式中的相同數字表示相同或相似的要素。以下示例性實施例中所描述的實施方式並不代表與本說明書相一致的所有實施方式。相反，它們僅是與如所附申請專利範圍中所詳述的、本說明書的一些方面相一致的裝置和方法的例子。
在本說明書使用的術語是僅僅出於描述特定實施例的目的，而非旨在限制本說明書。在本說明書和所附申請專利範圍中所使用的單數形式的「一種」、「所述」和「該」也旨在包括多數形式，除非上下文清楚地表示其他含義。還應當理解，本文中使用的術語「和/或」是指並包含一個或多個相關聯的列出專案的任何或所有可能組合。
應當理解，儘管在本說明書可能採用術語第一、第二、第三等來描述各種資訊，但這些資訊不應限於這些術語。這些術語僅用來將同一類型的資訊彼此區分開。例如，在不脫離本說明書範圍的情況下，第一資訊也可以被稱為第二資訊，類似地，第二資訊也可以被稱為第一資訊。取決於語境，如在此所使用的詞語「如果」可以被解釋成為「在……時」或「當……時」或「回應於判定」。
本說明書提供一種電子設備的保險實現方案。
上述電子設備的保險可以為電子設備的螢幕保險，也可以為電子設備的全面保障險等電子設備可投保的險種。
上述電子設備可以為手機、平板電腦、PDA(Personal Digital Assistant，掌上型電腦)等終端設備，上述電子設備也可以為攝影機、智慧型電視等多媒體設備，本說明書對此不作特殊限制。
上述電子設備的保險實現方案可由電子設備和伺服器配合實現。所述伺服器可由提供保險服務的服務提供者部署，例如保險公司、第三方保險銷售平台等。
在實現保險業務的過程中，電子設備和伺服器可通過有線、無線等傳輸方式進行交流互動。電子設備和伺服器之間的交流互動通常指電子設備中裝載的用戶端軟體和伺服器之間的交流互動，例如用戶在用戶端中使用已註冊的用戶帳號登錄後和伺服器進行交流互動，也可稱之為用戶和伺服器之間的交流互動。
下面分別通過電子設備的投保、核保、理賠和保險參數判定四個方面來描述本說明書的具體實現過程。
一、電子設備的投保
圖1是本說明書一示例性實施例示出的一種電子設備的保險實現方法的流程示意圖。
請參考圖1，所述電子設備的保險實現方法可應用於伺服器，包括有以下步驟：
步驟102，回應於用戶發起的電子設備投保請求，獲取所述用戶的行為資料。
在本實施例中，用戶可通過電子設備保險的售賣入口發起所述電子設備投保請求，例如，用戶端可在用戶觸發支付結果頁面的指定入口後發送所述電子設備投保請求，所述電子設備投保請求中攜帶有用戶帳號。
伺服器在接收到所述電子設備投保請求後，根據所述用戶帳號獲取對應用戶的行為資料。
所述行為資料可包括：用戶的歷史交易資料、用戶的歷史登錄資料、用戶的當前登錄資料等。
在其他例子中，伺服器在接收到電子設備投保請求後，可先判斷用戶是否命中黑名單，若未命中，則可執行獲取用戶行為資料的步驟。
所述黑名單可預先設置。
例如，可將歷史上識別出的騙保用戶添加到所述黑名單中。
再例如，也可將電子設備維修行業的從業人員添加到黑名單中。
又例如，還可將3C行業的從業人員添加到黑名單中。
通過黑名單的過濾，可有效過濾掉騙保高風險人群，提高線上投保的安全性，降低保險提供方的資損風險。
步驟104，根據所述行為資料判定所述投保請求的標的設備的屬性。
基於前述步驟102，伺服器在獲取到用戶的行為資料後，可根據所述行為資料判定用戶本次投保的標的電子設備(後續簡稱標的設備)的屬性。例如，針對不同的行為資料，可採用不同的方式判定所述標的設備的屬性。
其中，所述標的設備的屬性可包括：新機和老機。
步驟106，根據所述屬性對應的核保策略對所述投保請求進行核保。
在本實施例中，可預先配置並保存不同標的設備屬性和對應投保策略之間的映射關係，在前述步驟104中判定所述標的設備的屬性之後，可在所述映射關係中搜尋對應的核保策略，然後採用對應的核保策略對所述電子設備投保請求進行核保。
若標的設備的屬性是新機，可免去驗機流程，直接判定核保通過，進而提高核保效率，提升用戶的投保體驗。
若標的設備的屬性是老機，則可提示用戶上傳標的設備的校驗資料，伺服器進而可以根據校驗資料進行驗機核保。
由以上描述可以看出，本實施例伺服器在接收到電子設備投保請求後，可獲取用戶的行為資料，進而根據所述行為資料判定電子設備的屬性，並根據所述屬性對應的核保策略對投保請求進行核保，通過差異化的核保策略進行核保，可在確保核保準確性的同時，提高核保效率，進而提升用戶的投保體驗。
下面通過若干實施例詳細介紹標的設備屬性的判定方式。
圖2是本說明書一示例性實施例示出的一種標的設備屬性的判定方法的流程示意圖。
請參考圖2，所述標的設備屬性的判定方法可包括以下步驟：
步驟202，獲取用戶在預定時間段內的歷史交易資料。
在本實施例中，伺服器在接收到用戶發送的電子設備投保請求後，可獲取發起用戶的用戶帳號，然後基於所述用戶帳號從若干電商平台獲取對應用戶在預定時間段內的歷史交易資料。
例如，伺服器可基於所述用戶帳號判定用戶的身份資訊，然後基於該身份資訊進行歷史交易資料的獲取。
在本實施例中，每條歷史交易資料均可包括：訂單號、訂單時間、所購買的物品標識、物品類型、商家標識等資訊。所述預定時間段可由開發人員預先設置，例如10天內、15天內等。
步驟204，判斷所述歷史交易資料中是否包括電子設備的購買交易資料。
步驟206，若是，則判定標的設備的屬性是新機。
基於前述步驟202，伺服器在獲取到用戶在預定時間段內的歷史交易資料後，可根據所述歷史交易資料判斷用戶在所述預定時間段內是否購買過可投保的電子設備。
若是，則可推測用戶想要投保的是新購買的電子設備，進而可以將標的設備的屬性判定為新機。
舉例來說，小白在其手機中裝載的用戶端中登錄小白的帳號，然後向伺服器發送手機螢幕保險的投保請求，伺服器在接收到該投保請求後，可根據小白的帳號判定小白的身份資訊，例如唯一身份標識等。然後根據小白的身份資訊從電商平台獲取小白最近15天的交易資料，並基於這15天的交易資料判斷小白是否購買過手機，若是，則可推測小白想要投保的是新購買的手機，進而可以將所述投保請求的標的設備的屬性判定為新機。
在其他例子中，若所述歷史交易資料中包括多個電子設備的購買交易資料時，伺服器可發送對應的電子設備清單給用戶，以讓用戶選擇想要投保的標的設備。伺服器在接收到用戶基於所述電子設備清單發送的選擇指令後，可將用戶選擇的電子設備判定為本次投保的標的設備。
仍以小白為例，假設小白最近15天的交易資料中包括兩部手機的購買記錄，則可發送包括這兩部手機的清單給小白。所述清單中可包括手機型號、購買日期、購買價格、商家資訊等資料。小白可在該清單中選擇想要投保的手機，伺服器在接收到小白的選擇指令後，可以將小白選擇的手機判定為本次投保請求的標的設備。
值得注意的是，若根據用戶的歷史交易資料判定用戶購買的多個電子設備型號均相同時，也可以不發送電子設備清單給用戶。例如，小白購買了兩部相同的手機，則可不發送清單給小白，伺服器可確認小白想要投保的是該型號的新手機。
在本實施例中，除電商平台之外，伺服器也可以從其他途徑獲取用戶的歷史交易資料，例如，可從實體商場的伺服器獲取用戶在該實體商場內的線下交易資料等，本說明書對此不作特殊限制。
在本實施例中，伺服器可通過用戶的歷史交易資料判定保險標的設備的屬性是否為新機，一方面無需用戶上傳購買證明，可大大簡化用戶的投保操作，進而提高投保效率；另一方面，也突破了新機只能在購買的時候投保的限制，大大提升了用戶的投保體驗。
圖3是本說明書一示例性實施例示出的另一種標的設備屬性的判定方法的流程示意圖。
請參考圖3，所述標的設備屬性的判定方法可包括以下步驟：
步驟302，獲取電子設備投保請求發起設備的設備標識，作為發起標識。
在本實施例中，用戶在用戶端中基於用戶帳號登錄伺服器後，用戶端可獲取用戶使用的電子設備的設備標識，並將所述設備標識上報給伺服器。所述設備標識可由用戶端單獨上報，所述設備標識也可由用戶端攜帶在業務請求中上報給伺服器，例如，用戶端可將所述設備標識攜帶在用戶發送的電子設備投保請求中發送給伺服器，本說明書對此不作特殊限制。
所述設備標識可包括：Android ID(安卓ID)、IDFV
(IdentifierForVendor，應用開發商標識)、IMEI
(International Mobile Equipment Identity，國際移動設備識別碼)等。
在本實施例中，伺服器在接收到電子設備投保請求後，可通過用戶端獲取到發起所述電子設備投保請求的發起設備的設備標識，並可將其作為發起標識。
步驟304，搜尋用戶歷史登錄設備的設備標識，作為歷史標識。
在本實施例中，伺服器還可基於用戶帳號查詢資料庫，獲取對應用戶的歷史登錄設備的設備標識。所述資料庫中儲存有各用戶歷史上登錄伺服器時使用的電子設備的設備標識。
在一個例子中，伺服器可從資料庫中獲取所述用戶最近若干次登錄伺服器時使用的電子設備的設備標識，作為歷史標識，所述歷史標識有多個。
在另一個例子中，考慮到用戶通常不會無故頻繁更換電子設備，伺服器也可以從資料庫中獲取用戶最近一次登錄伺服器時使用的電子設備的設備標識，作為歷史標識。
步驟306，判斷所述發起標識與所述歷史標識是否相同。
步驟308，若不相同，則判定所述標的設備的屬性是新機。
基於前述步驟302和304，伺服器可判斷所述發起標識和所述歷史標識是否相同。
當伺服器獲取用戶最近一次登錄伺服器時使用的電子設備的設備標識作為歷史標識時，若發起標識和歷史標識不同，則可說明用戶更換了的電子設備，可推測用戶為新更換的電子設備投保，進而可將標的設備的屬性判定為新機。
若伺服器獲取多個歷史標識時，則可分別判斷所述發起標識與每個歷史標識是否相同，若均不相同，則可說明用戶更換了的電子設備，可推測用戶為新更換的電子設備投保，進而可將標的設備的屬性判定為新機。
在其他例子中，在採用設備標識進行標的設備屬性的判定時，還可以判斷用戶是否為可信用戶，若用戶不是可信用戶，即便發起標識和歷史標識不相同，也不會將標的設備的屬性判定為新機，而是將標的設備的屬性判定為老機，進而提高後續核保結果的準確性，降低直接跳過驗機通過核保所帶來的騙保風險。
若用戶是可信用戶，當發起標識和歷史標識不相同時，可將標的設備的屬性判定為新機。
在本實施例中，可根據用戶的註冊時長、登錄頻率等判定用戶是否為可信用戶。
在一個例子中，可判斷用戶的註冊時長是否小於時長臨限值，若小於時長臨限值，則可判定所述用戶不是可信用戶。
所述時長臨限值可預先設置，例如，1個月、3個月等。
在另一個例子中，可判斷用戶是否在近期登錄過用戶帳號，若未登錄過，則可判定用戶不是可信用戶。
例如，可判斷用戶是否在近1個月/3個月登錄過用戶帳號等。
與之相反，若用戶的註冊時長大於等於時長臨限值，並且近期登錄過用戶帳號，則可判定用戶是可信用戶。
在本實施例中，伺服器可根據用戶登錄設備的設備標識判定用戶投保的標的設備是否為新機，可解決歷史交易資料獲取不全面所導致的新機標的設備識別不準確的問題，同時無需用戶上傳購買證明，可大大簡化用戶的投保操作，提高投保效率。
值得注意的是，在本說明書並不限制圖2和圖3所示實施例標的設備屬性判定方法的執行順序。並且，在上述標的設備屬性判定的實現方案中，若通過歷史交易資料、設備標識等途徑無法判定標的設備的屬性是新機時，可將標的設備的屬性判定為老機，後續基於用戶上傳的校驗資料進行核保，進而確保核保的準確性。
此外，伺服器在判定標的設備的屬性後，還可將標的設備的屬性發送給用戶端，以供用戶確認，用戶可根據實際情況進行調整。
仍假設小白最近15天的購買過新手機，伺服器判定標的設備的屬性是「新機」，進而可將「新機」作為預設的屬性返回給用戶端，若小白想要投保的不是新機，則可選擇其他屬性。
在實際實現中，為便於用戶理解，以手機螢幕保險為例，用戶端可展示圖4所示的投保頁面，其中保障手機專案中的「新購手機」和「本手機」指的是用戶想要投保的標的手機是不是本手機。
若用戶選擇「新購手機」，伺服器可獲取用戶的歷史交易資料，進而根據所述歷史交易資料判斷用戶近期是否購買過新手機，若是，則可判定標的設備的屬性是新機，進而可直接判定核保通過。
若用戶選擇「本手機」，說明用戶想要投保的是當前正在使用的手機。而用戶當前正在使用的手機，可能是用戶購買的新手機，即標的設備的屬性是新機；用戶當前正在使用的手機也可能是用戶原來的舊手機，即標的設備的屬性是「老機」。在這種情況下，伺服器可獲取歷史標識和發起標識，以確認標的設備的屬性，並可採用判定的屬性對應的核保策略進行核保。
當然，在其他例子中，若用戶投保的電子設備是攝影機、智慧型電視等多媒體設備，用戶可能仍會使用手機投保，但「保障設備」不可能是手機，開發人員可開發其他樣式的用戶介面，本說明書對此不作特殊限制。
二、核保
在判定標的設備的屬性是老機時，伺服器向用戶發送上傳校驗資料的提示資訊，所述校驗資料可以是標的設備的照片、視頻等資料，伺服器在接收到校驗資料之後，可通過所述校驗資料進行驗機，判定標的設備是否完好、無損壞，進而判定核保結果。
本說明書提供多種校驗資料的上傳方式，用戶可根據實際情況進行選擇。
圖5是本說明書一示例性實施例示出的一種上傳校驗資料的方法的流程示意圖。
請參考圖5，上傳校驗資料的方法可應用在電子設備中，包括有以下步驟：
步驟502，在觸發電子設備投保的校驗資料上傳時，展示上傳方式清單。
在本實施例中，用戶在接收到上傳校驗資料的提示資訊後，可在方便的時候上傳校驗資料。
當用戶觸發校驗資料上傳時，電子設備的用戶端可展示上傳方式清單，所述上傳方式清單中可展示對應上傳方式所需的輔助設備，用戶可根據實際情況選擇上傳方式。
以手機螢幕保險為例，校驗資料為手機螢幕的照片或視頻。請參考圖6所示的投保方式清單頁面示意圖，圖6提供兩種手機螢幕拍攝方式，一種是他人協助拍攝，需要另一部手機；若用戶無法找到另一部手機，也可以選擇另一種拍攝方式，即自行對著鏡子拍攝。
其中，他人協助拍攝的方式所需的輔助設備是另一部手機；自行拍攝所需的輔助設備是一面鏡子。
步驟504，回應於用戶選擇的上傳方式，跳轉到對應的上傳方式指導頁面，所述上傳方式指導頁面中展示有對應的上傳入口，以供用戶在觸發所述上傳入口後基於所述上傳方式實現本設備校驗資料的上傳。
基於前述步驟502中展示的上傳方式清單，用戶可選擇合適的上傳方式，用戶端進而可跳轉到對應上傳方式的指導頁面。所述指導頁面中展示有對應上傳方式的詳情介紹，並展示有上傳入口，用戶可觸發該上傳入口，進行校驗資料的拍攝。
由以上描述可以看出，本實施例提供多種電子設備投保過程中校驗資料的上傳方式，用戶可根據實際情況選擇合適的方式上傳校驗資料，實現校驗資料的線上上傳，方便、快捷，大大提升了用戶的投保體驗。
下面分別對這兩種上傳方式進行詳細說明。
1、對著鏡子拍攝
仍以手機螢幕保險為例，若用戶在圖6所示的頁面中觸發「對著鏡子拍攝本機」的上傳方式，用戶端可跳轉到圖7所示的上傳方式指導頁面，所述上傳方式指導頁面中展示有上傳入口「開始拍攝」，還展示有該上傳方式的示例圖像以及拍攝要求。
用戶觸發該上傳入口後可調用電子設備的前置攝影鏡頭，通過前置攝影鏡頭進行圖片、視頻等圖像採集，並可在採集到圖像後將所述圖像作為校驗資料上傳至伺服器。
在其他例子中，用戶觸發該上傳入口後，也可以默認調用後置攝影鏡頭，由用戶手動切換到前置攝影鏡頭進行圖像採集，本說明書對此不作特殊限制。
在其他例子中，請參考圖8所示的用戶介面，由於對著鏡子拍攝需要用戶翻轉手機，將手機螢幕對著鏡子，當用戶觸發所述上傳入口後，還可啟動計時器開始計時，給客戶留出翻轉手機的準備時間，在到達計時時長時，才開始進行圖像的採集。所述計時時長可以為3秒鐘。為便於用戶理解，用戶端可通過倒計時的方式顯示所述計時時長。
本實施例為用戶提供對著鏡子拍攝的校驗資料上傳方式，一方面可確保校驗資料的真實性，另一方面實現簡單、便捷，用戶體驗較好。
2、使用其他手機拍攝
仍以手機螢幕保險為例，若用戶在圖6所示的頁面中觸發「使用其他手機拍攝本機」的上傳方式，用戶端可跳轉到圖9所示的上傳方式指導頁面，所述上傳方式指導頁面中展示有上傳入口「開始拍攝」，也展示有該上傳方式的示例圖像以及拍攝要求。
用戶觸發該上傳入口後用戶端可展示用於上傳校驗資料的校驗圖形編碼，例如校驗二維碼。所述校驗二維碼中可攜帶校驗標識、用戶帳號、投保資訊、設備標識等資料。
用戶或者協助用戶的人可使用其他手機掃碼所述校驗二維碼，並對所述校驗二維碼進行解析，若解析得到校驗標識，則可調用本機攝影鏡頭進行圖像採集，並可在完成採集後，將採集到的圖像以及二維碼中解析得到的用戶帳號、投保資訊、設備標識等資料發送給伺服器，伺服器可根據這些資訊判定對應的投保請求，並進行核保。
在本實施例中，所述校驗圖形編碼為動態的圖形編碼，例如，可每分鐘刷新1次。採用動態的圖形編碼，可有效防止用戶作弊，例如用戶通過截取螢幕等方式保留該校驗圖形編碼，並將該校驗圖像編碼發送至相同型號的手機，後續採集該相同型號手機的圖像作為校驗資料等。
在上述兩種上傳方式中，均可採用無感拍攝，即無需用戶手動觸發拍攝開始/拍攝結束的按鈕，調用攝影鏡頭之後自動拍攝上傳，簡化用戶操作，提升用戶的使用體驗。
此外，上述兩種方式均以手機螢幕保險為例進行描述，若用戶投保的是全面保障險等其他險種，校驗資料可能還需包括手機側面、背面的圖像，用戶端可輸出相應引導，本說明書在此不再一一贅述。
在其他例子中，由於上述兩種上傳方式所需的輔助設備不同，伺服器可預先儲存上傳方式和上傳時段之間的映射關係。
一方面，伺服器可在判定標的設備的屬性是老機時，基於所述映射關係搜尋當前時刻對應的上傳方式，並將所述上傳方式攜帶在上傳校驗資料的提示資訊中發送給用戶。伺服器也可以將所有上傳方式攜帶在該提示資訊中發送給用戶，並優先推薦當前時刻對應的上傳方式，本說明書對此不作特殊限制。
另一方面，在用戶觸發校驗資料上傳時，伺服器也可根據所述映射關係搜尋當前時刻對應的上傳方式，然後將所述上傳方式返回給用戶端，用戶端可在上傳方式清單中區別顯示所述上傳方式，例如將所述上傳方式標注為推薦等。
當然，在這個例子中，所述映射關係也可保存在電子設備本地，當用戶觸發校驗資料上傳時，用戶端從本地獲取所述映射關係，並進行當前時刻對應上傳方式的搜尋，本說明書對此不作特殊限制。 上傳時段 上傳方式
8:00-18:00 使用其他手機拍攝
18:00-8:00 對照鏡子拍攝
表1
請參考表1，一種上傳時段和上傳方式之間映射關係的示例。其中，8:00-18:00這個時段，用戶較大機率是在上班，可優先推薦使用其他手機拍攝的上傳方式，例如，用戶可以讓同事幫忙拍攝。18:00至第二天8:00這個時段，用戶較大機率是在家中，可優先推薦使用對照鏡子拍攝的上傳方式。
當然，表1所示的映射關係只是一種示例，在實際應用中，還可設置更複雜的映射關係，例如區分工作日和休息日等，本說明書對此不作特殊限制。
三、理賠
圖10是本說明書一示例性實施例示出的一種電子設備保險理賠的實現方法的流程示意圖。
請參考圖10，所述理賠的實現方法可應用於伺服器，包括以下步驟：
步驟1002，接收出險設備發送的理賠確認申請，所述理賠確認申請由所述出險設備在掃描指定圖形編碼後發送，所述理賠確認申請中攜帶所述出險設備的若干標識因子。
在本實施例中，伺服器在判定核保通過後，可保存保單和用戶投保的電子設備的若干標識因子之間的映射關係。
用戶在理賠時，可使用需要理賠的電子設備(後續稱為出險設備)掃描用於理賠的圖形編碼，例如理賠二維碼，電子設備進而可以獲取本設備的若干標識因子，然後基於所述若干標識因子構造理賠確認申請，並將該理賠確認申請發送至伺服器。
例如，電子設備的維修人員在拿到需要維修及理賠的電子設備後，可在用戶端中使用自己的用戶帳號登錄伺服器，然後掃描理賠二維碼，用戶端解析所述理賠二維碼，若從解析得到指定的理賠標識，則可獲取本設備的若干標識因子，並執行構造理賠確認申請的步驟。
在本實施例中，所述電子設備的標識因子可包括IDFA(Identifier For Advertising，廣告識別字)、IDFV、Android ID等設備標識。
步驟1004，根據所述映射關係，判斷能否搜尋到所述出險設備的若干標識因子對應的保單。
步驟1006，若搜尋到對應的保單，則向所述出險設備返回允許理賠的消息。
伺服器在接收到所述理賠確認申請後，可在所述映射關係中搜尋理賠確認申請中攜帶的若干標識因子對應的保單。
若搜尋到對應的保單，則可說明出險的電子設備之前購買過保險，可以返回允許理賠的消息，後續維修人員可直接找保險公司來支付維修費用。
若未搜尋到對應的保單，可能存在兩種情況，一種是出險設備未購買過保險，另一種是用戶未使用出險設備購買保險，需要進行進一步判斷。
由以上描述可以看出，本實施例伺服器可保存標的設備若干標識因子和保單之間的映射關係，後續根據出險設備的標識因子判斷出險設備是否投保過保險，以對理賠進行驗證。一方面採用IDFA等若干標識因子組合的方式來標識電子設備，可有效解決應用提供方無法獲取UDID (Unique Device Identifier)來標識電子設備的問題；另一方面，整個過程也無需用戶手動上傳UDID等設備標識，大大簡化用戶操作，提升用戶投保體驗。
下面分別從映射關係的建立、理賠流程的實現來進行詳細描述。
1、映射關係的建立
請參考圖11，上述映射關係的建立過程可包括以下步驟：
步驟1102，當電子設備投保請求核保通過後，判斷所述投保請求的標的設備是否為所述電子設備投保請求的發起設備。
步驟1104，若是，則獲取所述發起設備的若干標識因子，並建立所述若干標識因子和所述發起設備保單之間的映射關係。
在本實施例中，伺服器在判定電子設備投保請求核保通過後，可判斷投保請求的標的設備是否為電子設備投保請求的發起設備。即，伺服器判斷用戶投保的是否為本機設備。
若是，伺服器可通過用戶端獲取所述發起設備的若干標識因子，並建立所述若干標識因子和對應保單之間的映射關係。例如，建立所述若干標識因子和保單標識之間的映射關係。 序號 IDFA IDFV 保單
1 15dfa35g4 h41f6afg 123
2 4d5adffs5 Ghrte15f3 124
3 D4f3ad4fc Er5tjkb88 125
表2
表2示出了一種設備標識因子和保單之間映射關係的示例，需要說明的是，表2僅僅是一種示例，在實際實現中，也可不組織這樣的表格，本說明書對此不作特殊限制。
上述過程中，伺服器可通過以下方法判定標的設備是否為電子設備投保請求的發起設備。
方法一：基於標的設備屬性進行判斷
伺服器可在判定標的設備的屬性是老機時，判定標的設備為電子設備投保請求的發起設備。即，投保用戶最近未購買過新的電子設備，並且用戶曾經也使用過發起設備登錄。
伺服器在判定標的設備的屬性是新機時，可獲取新機屬性的判斷途徑。
若判斷途徑是設備標識判斷途徑時，也可判定標的設備為電子設備投保請求的發起設備。
所述新機屬性的判斷途徑可參考前述圖2-圖3所示的實施例，本說明書在此不再一一贅述。
方法二：基於用戶的選擇進行判斷
請再次參考圖4所示的投保頁面，若用戶通過圖4所示的投保頁面進行投保，伺服器可直接獲取用戶選擇的保障手機，若用戶選擇的是「本手機」，則可直接判定標的設備為電子設備投保請求的發起設備。
在其他例子中，若標的設備不是電子設備投保請求的發起設備，則伺服器可保存保單和標的設備購買訂單之間的映射關係，以便後續理賠時進行驗證。
例如，若標的設備屬性「新機」的判斷途徑是歷史交易資料途徑時，可判定標的設備不是投保請求的發起設備。
再例如，仍以圖4為例，若用戶選擇的是「新購手機」，則也可判定標的設備不是投保請求的發起設備。
在這種情況下，伺服器可在用戶的歷史交易資料中獲取標的設備的訂單標識，並建立訂單標識和保單標識之間的映射關係，以供後續理賠時驗證使用。
一般而言，當標的設備不是電子設備投保請求的發起設備時，通常包括兩種情況，下面以手機為例進行說明。
第一種情況是用戶為自己購買新手機，但使用舊手機為新手機投保。
請參考圖12，在這種情況下，前述映射關係的建立過程可包括以下步驟：
步驟1202，在檢測到新機登錄時，判斷是否存在登錄用戶對應的電子設備保單。
在這種情況下，用戶在使用新手機後，通常會使用新手機登錄伺服器，伺服器可在用戶登錄後，獲取登錄手機的標識，然後判斷用戶是否首次使用該手機登錄，即是否為新機登錄。
若是，則可根據用戶帳號判斷是否存在登錄用戶對應的電子設備保單，即搜尋用戶是否購買過手機保險。
步驟1204，若存在，則判斷所述新機的型號是否匹配標的設備型號。
步驟1206，若匹配，則獲取所述新機的若干標識因子，並建立所述若干標識因子和所述登錄用戶的電子設備保單之間的映射關係。
基於前述步驟1102的判斷結果，若用戶購買過手機保險，則可根據保單標識搜尋標的設備的型號。
在本實施例中，伺服器可判斷用戶使用的新手機的型號是否標的設備的型號。
若匹配，則可說明用戶當前使用的新手機就是用戶之前投保的手機，進而可通過用戶端獲取所述新手機的若干標識因子，並建立所述若干標識因子和保單之間的映射關係。
後續伺服器在接收到針對該新手機的理賠請求時，就可根據若干標識因子和保單之間的映射關係來進行理賠驗證，進而提高理賠驗證準確性。
第二種情況是用戶為他人購買新手機，然後使用自己的手機為新手機投保。
在這種情況下，用戶使用購買的新手機登錄自身用戶帳號的機率極低，伺服器較難自動獲取到該新手機的若干標識因子，可僅建立訂單標識和保單標識之間的映射關係，也可提示用戶使用新手機登錄，還可提示用戶主動上傳新手機的標識因子。
2、理賠流程
在前述圖10所示的實施例中，用戶電子設備損壞需要理賠時，可直接到指定的維修中心，由維修人員使用出險設備登錄伺服器之後掃描二維碼進行驗證。
可選的，在其他例子中，在電子設備損壞需要理賠時，用戶也可以先線上提交理賠請求，例如，用戶可先使用投保的電子設備發送理賠申請，伺服器在接收到該理賠申請後，將對應保單的狀態標記為理賠中，並可向用戶返回指定的維修中心清單。
用戶可通過面交、快遞等方式將出險設備送至指定維修中心，指定維修中心的維修人員可使用自己的用戶帳號登錄伺服器之後掃描二維碼以進行驗證。
在這樣的實現方式中，伺服器在接收到理賠確認申請後，可在狀態為理賠中的保單與標識因子之間的映射關係中搜尋出險設備對應的保單，可大大減少比對數量，提高理賠驗證的效率。
在其他例子中，伺服器在接收到出險設備發送的理賠確認申請後，若根據出險設備的若干標識因子未搜尋到對應的保單，則可獲取出險設備的登錄資料，例如歷史上使用所述出險設備第一次登錄的時間點，然後計算所述第一次登錄的時間點距今的時長，作為第一時長，該第一時長可表示伺服器可判定的所述出險設備的使用時長。
伺服器還可根據訂單標識和保單標識之間的映射關係，獲取狀態為理賠中的保單對應的訂單，然後計算所述訂單的產生時間點距今的時長，作為第二時長，該第二時長表示具有保單的電子設備的購買時長。
然後，伺服器可判斷第一時長和各第二時長的大小關係。若第一時長大於所有第二時長，則可說明出險設備使用的時長大於各具有保險的電子設備的購買時長，存在騙保嫌疑，可向所述出險設備返回禁止理賠的消息。
若第一時長小於所有第二時長，則可向出險設備返回允許理賠的消息。
值得注意的是，在時長判斷的過程中，還可判斷標的設備型號與出險設備型號是否匹配等，本說明書在此不再一一贅述。
由以上描述可以看出，本實施例提供的理賠方案，在用戶為新手機投保時，可保存新手機購買訂單和保單之間的映射關係，後續可根據新手機的購買時長和出險手機的使用時長來進行理賠驗證，在簡化投保/理賠的操作時，還可確保理賠驗證的準確性。
圖13是本說明書一示例性實施例示出的另一種電子設備保險理賠的實現方法的流程示意圖。
請參考圖13，所述理賠的實現方法可應用於電子設備，包括以下步驟：
步驟1302，在掃描圖形編碼後，判斷所述圖形編碼中是否攜帶指定的理賠標識。
步驟1304，若攜帶，則獲取本設備的若干標識因子。
步驟1306，基於所述標識因子構造理賠確認申請，並將所述理賠確認申請發送給伺服器，以供伺服器搜尋所述若干標識因子對應的保單。
步驟1308，接收伺服器在搜尋到所述若干標識因子對應的保單後發送的允許理賠的消息。
本實施例中理賠的實現方法可參考前述實施例，本說明書在此不再一一贅述。
四、保險參數的判定
本說明書提供一種動態保險參數的判定方案，可靈活判定不同用戶的保險參數，實現簡單、便捷，還可有效提升用戶的投保體驗。
所述保險參數可包括保額、保障期限、保障範圍、保障險種中的一種或多種。
圖14是本說明書一示例性實施例示出的一種保險參數判定方法的流程示意圖。
請參考圖14，所述保險參數判定方法可應用於伺服器，包括以下步驟：
步驟1402，在核保通過後，獲取所述用戶的若干累加保險參數。
在本實施例中，在判定電子設備保險核保通過後，可基於用戶和累加保險參數之間的映射關係，判斷所述用戶是否存在對應的累加保險參數。
若存在，則可獲取所述用戶對應的累加保險參數。
若不存在，則可將用戶本次投保的保險參數判定為缺省保險參數。
步驟1404，基於所述累加保險參數和相同類型的缺省保險參數判定本次投保的當前保險參數。
基於前述步驟1402，在獲取到用戶的累加保險參數之後，可將累加保險參數和相同類型的缺省保險參數相加，得到本次投保對應類型的保險參數。
以電子設備的螢幕保險為例，假設缺省保額是1000元，缺省保證期限是1年。
若用戶對應的累加保額是20元，累加保障期限是1個月，則可將用戶本次投保的保額判定為1020元，保障期限判定為1年零1個月。
若用戶對應的累加保額是10元，無對應的累加保障期限，則可將用戶本次投保的保額判定為1010元，保障期限判定為1年。
若不存在用戶對應的累加保額和累加保障期限，則可將用戶本次投保的保額判定為缺省保額1000元，保障期限判定為缺省保障期限1年。
在本實施例中，伺服器可在成功執行用戶的支付請求後，向所述用戶發送獲取累加保險參數的消息。即伺服器在用戶成功完成支付後，向其發送所述消息。用戶端在獲取到該消息後，可在支付結果頁面中展示所述累加保險參數的獲取入口。
所述累加保險參數的類型可由伺服器指定，並可由伺服器攜帶在所述消息中。
例如，伺服器可指定累加保險參數的類型為保障期限，用戶端進而可以在支付結果頁面中展示累加保障期限的獲取入口。
再例如，伺服器可指定累加保險參數的類型為保額和保障期限，用戶端進而可以在支付結果頁面中展示累加保額的獲取入口和累加保障期限的獲取入口。
在本實施例中，用戶可通過所述支付結果頁面觸發所述獲取入口，用戶端可發送對應類型的累加保險參數獲取請求至伺服器。
以累加保額獲取請求為例，伺服器在接收到所述累加保額獲取請求後，可判斷所述用戶是否存在對應的電子設備保單。
若存在，可說明用戶投保過電子設備保險，伺服器可獲取對應保單的當前保額，然後計算累加保額和當前保額的和值，並用所述和值更新所述保單的當前保額。
其中，不同用戶的累加保額的具體數值可相同，例如所有用戶的累加保額都是10元；
不同用戶的累加保額的具體數值也可不同，伺服器可以根據用戶的支付金額判定其累加保額的具體數值，例如，支付金額越高的用戶的累加保額的具體數值越高，或者支付金額大於等於臨限值的用戶的累加保額是20元，而支付金額小於所述臨限值的用戶的累加保額是10元等，本說明書對此不作特殊限制。
若不存在用戶對應的電子設備保單，則可說明用戶尚未投保過電子設備保險，伺服器可保存用戶和累加保額及其數值之間的映射關係，後續用戶投保電子設備保險時，可基於所述映射關係判定保單的保額。
在本實施例中，所述累加保險參數可具有有效時長。
以保額為例，所述有效時長可預先設置，小於等於保障期限。假設所述有效時長是6個月，則在到達6個月的有效時長時，若保單尚未超過保障期限，則可還原保單的保額，例如計算所述保單的當前保額和對應累加保額具體數值的差值，並將該差值更新為所述保單的當前保額。
以保障期限為例，保障期限的有效時長往往是針對未投保的用戶，在到達所述有效時長時，如果用戶仍未投保電子設備保險，則可判定所述保障期限無效。
在其他例子中，所述累加保險參數也可以僅為投保過電子設備保險的用戶提供。
例如，在成功執行用戶的支付請求後，可判斷是否存在所述用戶對應的保單，若存在，則可向所述用戶發送獲取累加保險參數的消息，用戶端進而在支付結果頁面中展示所述累加保險參數的獲取入口。
當用戶觸發所述獲取入口時，伺服器執行保險參數的更新。
若不存在用戶對應的保單，伺服器不向用戶發送獲取累加保險參數的消息，用戶端也不會展示累加保險參數的獲取入口。
由以上描述可以看出，本實施例可在支付結果頁面展示累加保險參數的獲取入口，用戶可基於該獲取入口觸發保險參數的更新，通過技術創新實現了保險的投保簡單、便捷，為用戶提供快捷、便利的保險服務推薦，降低用戶操作的繁瑣度，節省用戶的操作時間。
與前述電子設備的保險實現方法的實施例相對應，本說明書還提供了電子設備的保險實現裝置的實施例。
本說明書電子設備的保險實現裝置的實施例可以應用在電子設備上。裝置實施例可以通過軟體實現，也可以通過硬體或者軟硬體結合的方式實現。以軟體實現為例，作為一個邏輯意義上的裝置，是通過其所在電子設備的處理器將非揮發性記憶體中對應的電腦程式指令讀取到記憶體中運行形成的。從硬體層面而言，如圖15所示，為本說明書電子設備的保險實現裝置所在電子設備的一種硬體結構圖，除了圖15所示的處理器、記憶體、網路介面、以及非揮發性記憶體之外，實施例中裝置所在的電子設備通常根據該電子設備的實際功能，還可以包括其他硬體，對此不再贅述。
圖16是本說明書一示例性實施例示出的一種電子設備的保險實現裝置的方塊圖。
請參考圖16，所述電子設備的保險實現裝置1500可以應用在前述圖15所示的電子設備中，包括有：清單展示單元1501和資料上傳單元1502。
其中，清單展示單元1501，在觸發電子設備投保的校驗資料上傳時，展示上傳方式清單；
資料上傳單元1502，回應於用戶選擇的上傳方式，跳轉到對應的上傳方式指導頁面，所述上傳方式指導頁面中展示有對應的上傳入口，以供用戶在觸發所述上傳入口後基於所述上傳方式實現本設備校驗資料的上傳。
可選的，所述資料上傳單元1502：
當第一上傳方式的上傳入口被用戶觸發時，調用本設備的前置攝影鏡頭採集圖像，並將採集到的圖像作為本設備的校驗資料上傳至伺服器。
可選的，所述資料上傳單元1502：
在調用本設備的前置攝影鏡頭後，啟動計時器開始計時；
在到達計時時長時，開始採集圖像。
可選的，所述資料上傳單元1502：
當第二上傳方式的上傳入口被用戶觸發時，產生校驗圖形編碼，以供其他電子設備在掃描所述校驗圖形編碼後調用自身攝影鏡頭採集圖像，並將採集到的圖像作為本設備的校驗資料上傳至伺服器。
可選的，所述清單展示單元1501：
在觸發電子設備投保的校驗資料上傳時，根據預先設置的上傳時段和上傳方式之間的映射關係，搜尋當前時刻對應的上傳方式；
在所述上傳方式清單中區別展示搜尋到的所述上傳方式。
上述裝置中各個單元的功能和作用的實現過程具體詳見上述方法中對應步驟的實現過程，在此不再贅述。
對於裝置實施例而言，由於其基本對應於方法實施例，所以相關之處參見方法實施例的部分說明即可。以上所描述的裝置實施例僅僅是示意性的，其中所述作為分離部件說明的單元可以是或者也可以不是物理上分開的，作為單元顯示的部件可以是或者也可以不是物理單元，即可以位於一個地方，或者也可以分佈到多個網路單元上。可以根據實際的需要選擇其中的部分或者全部模組來實現本說明書方案的目的。本領域普通技術人員在不付出創造性勞動的情況下，即可以理解並實施。
上述實施例闡明的系統、裝置、模組或單元，具體可以由電腦晶片或實體實現，或者由具有某種功能的產品來實現。一種典型的實現設備為電腦，電腦的具體形式可以是個人電腦、筆記型電腦、蜂窩電話、相機電話、智慧型電話、個人數位助理、媒體播放機、導航設備、電子郵件收發設備、遊戲控制台、平板電腦、可穿戴設備或者這些設備中的任意幾種設備的組合。
與前述電子設備的保險實現方法的實施例相對應，本說明書還提供一種電子設備的保險實現裝置，該裝置包括：處理器以及用於儲存機器可執行指令的記憶體。其中，處理器和記憶體通常借由內部匯流排相互連接。在其他可能的實現方式中，所述設備還可能包括外部介面，以能夠與其他設備或者部件進行通訊。
在本實施例中，通過讀取並執行所述記憶體儲存的與電子設備的保險實現邏輯對應的機器可執行指令，所述處理器被促使：
在觸發電子設備投保的校驗資料上傳時，展示上傳方式清單；
回應於用戶選擇的上傳方式，跳轉到對應的上傳方式指導頁面，所述上傳方式指導頁面中展示有對應的上傳入口，以供用戶在觸發所述上傳入口後基於所述上傳方式實現本設備校驗資料的上傳。
可選的，當第一上傳方式的上傳入口被用戶觸發時，調用本設備的前置攝影鏡頭採集圖像，並將採集到的圖像作為本設備的校驗資料上傳至伺服器。
可選的，所述調用本設備的前置攝影鏡頭採集圖像，包括：
在調用本設備的前置攝影鏡頭後，啟動計時器開始計時；
在到達計時時長時，開始採集圖像。
可選的，當第二上傳方式的上傳入口被用戶觸發時，產生校驗圖形編碼，以供其他電子設備在掃描所述校驗圖形編碼後調用自身攝影鏡頭採集圖像，並將採集到的圖像作為本設備的校驗資料上傳至伺服器。
可選的，還包括：
在觸發電子設備投保的校驗資料上傳時，根據預先設置的上傳時段和上傳方式之間的映射關係，搜尋當前時刻對應的上傳方式；
在所述上傳方式清單中區別展示搜尋到的所述上傳方式。
可選的，所述上傳方式清單中展示有對應上傳方式所需的輔助設備。
可選的，所述電子設備投保的保險為電子設備的螢幕保險。
與前述電子設備的保險實現方法的實施例相對應，本說明書還提供一種電腦可讀儲存媒體，所述電腦可讀儲存媒體上儲存有電腦程式，該程式被處理器執行時實現以下步驟：
在觸發電子設備投保的校驗資料上傳時，展示上傳方式清單；
回應於用戶選擇的上傳方式，跳轉到對應的上傳方式指導頁面，所述上傳方式指導頁面中展示有對應的上傳入口，以供用戶在觸發所述上傳入口後基於所述上傳方式實現本設備校驗資料的上傳。
可選的，當第一上傳方式的上傳入口被用戶觸發時，調用本設備的前置攝影鏡頭採集圖像，並將採集到的圖像作為本設備的校驗資料上傳至伺服器。
可選的，所述調用本設備的前置攝影鏡頭採集圖像，包括：
在調用本設備的前置攝影鏡頭後，啟動計時器開始計時；
在到達計時時長時，開始採集圖像。
可選的，當第二上傳方式的上傳入口被用戶觸發時，產生校驗圖形編碼，以供其他電子設備在掃描所述校驗圖形編碼後調用自身攝影鏡頭採集圖像，並將採集到的圖像作為本設備的校驗資料上傳至伺服器。
可選的，還包括：
在觸發電子設備投保的校驗資料上傳時，根據預先設置的上傳時段和上傳方式之間的映射關係，搜尋當前時刻對應的上傳方式；
在所述上傳方式清單中區別展示搜尋到的所述上傳方式。
可選的，所述上傳方式清單中展示有對應上傳方式所需的輔助設備。
可選的，所述電子設備投保的保險為電子設備的螢幕保險。
上述對本說明書特定實施例進行了描述。其它實施例在所附申請專利範圍的範圍內。在一些情況下，在申請專利範圍中記載的動作或步驟可以按照不同於實施例中的順序來執行並且仍然可以實現期望的結果。另外，在圖式中描繪的過程不一定要求示出的特定順序或者連續順序才能實現期望的結果。在某些實施方式中，多工處理和並行處理也是可以的或者可能是有利的。
以上所述僅為本說明書的較佳實施例而已，並不用以限制本說明書，凡在本說明書的精神和原則之內，所做的任何修改、等同替換、改進等，均應包含在本說明書保護的範圍之內。Exemplary embodiments will be described in detail herein, examples of which are illustrated in the drawings. When the following description refers to the drawings, the same numerals in different drawings represent the same or similar elements unless otherwise indicated. The implementations described in the illustrative examples below are not intended to represent all implementations consistent with this specification. Rather, they are merely examples of apparatus and methods consistent with some aspects of this specification as detailed in the appended claims. The terms used in this specification are for the purpose of describing particular embodiments only and are not intended to limit the specification. As used in this specification and the appended claims, the singular forms "a,""the," and "the" are intended to include plural forms as well, unless the context clearly dictates otherwise. It should also be understood that the term "and/or" as used herein refers to and includes any and all possible combinations of one or more of the associated listed items. It should be understood that although the terms first, second, third, etc. may be used in this specification to describe various information, such information should not be limited by these terms. These terms are only used to distinguish information of the same type from one another. For example, the first information may also be referred to as the second information, and similarly, the second information may also be referred to as the first information without departing from the scope of the present specification. Depending on the context, the word "if" as used herein can be interpreted as "at the time of" or "at the time of" or "in response to the determination". This specification provides an insurance implementation solution for electronic equipment. The insurance for the above electronic equipment may be the screen insurance of the electronic equipment, or may be a type of insurance that can be insured for the electronic equipment, such as the comprehensive protection insurance for the electronic equipment. The above-mentioned electronic devices may be terminal devices such as mobile phones, tablet computers, and PDAs (Personal Digital Assistant, handheld computers), and the above-mentioned electronic devices may also be multimedia devices such as cameras and smart TVs, which are not particularly limited in this specification. The insurance implementation scheme of the above electronic device can be realized by the cooperation of the electronic device and the server. The server may be deployed by service providers that provide insurance services, such as insurance companies, third-party insurance sales platforms, and the like. In the process of realizing insurance business, electronic devices and servers can communicate and interact through wired, wireless and other transmission methods. The communication and interaction between the electronic device and the server usually refers to the communication and interaction between the client software loaded in the electronic device and the server. For example, the user interacts with the server after logging in with the registered user account in the client. Also known as the interaction between the user and the server. The specific implementation process of this specification is described below through the four aspects of insurance application, underwriting, claim settlement and insurance parameter determination of electronic equipment. 1. Insurance Application for Electronic Equipment FIG. 1 is a schematic flowchart of a method for implementing insurance for electronic equipment according to an exemplary embodiment of this specification. Referring to FIG. 1 , the method for implementing insurance for an electronic device can be applied to a server, and includes the following steps: Step 102 , in response to an electronic device insurance request initiated by a user, obtain behavior data of the user. In this embodiment, the user can initiate the electronic device insurance request through the electronic device insurance sales portal. The insurance request carries the user account number. After receiving the electronic device insurance request, the server obtains the behavior data of the corresponding user according to the user account. The behavior data may include: the user's historical transaction data, the user's historical log-in data, the user's current log-in data, and the like. In other examples, after receiving the electronic device insurance application request, the server may first determine whether the user hits the blacklist, and if not, the server may perform the step of acquiring the user behavior data. The blacklist can be preset. For example, historically identified fraudulent users may be added to the blacklist. For another example, practitioners in the electronic equipment repair industry can also be added to the blacklist. For another example, practitioners in the 3C industry can also be added to the blacklist. Through the filtering of the blacklist, it can effectively filter out the high-risk groups of fraudulent insurance, improve the security of online insurance, and reduce the risk of capital loss of the insurance provider. Step 104: Determine the attribute of the target device of the insurance request according to the behavior data. Based on the foregoing step 102, after acquiring the behavior data of the user, the server may determine the attributes of the target electronic device (hereinafter referred to as the target device) that the user applies for insurance this time according to the behavior data. For example, for different behavior data, the attributes of the target device can be determined in different ways. Wherein, the attributes of the target device may include: a new machine and an old machine. Step 106 , underwrite the insurance application request according to the underwriting policy corresponding to the attribute. In this embodiment, the mapping relationship between the attributes of different target devices and the corresponding insurance policies can be pre-configured and saved. After determining the attributes of the target device in the aforementioned step 104, the corresponding core can be searched in the mapping relationship. An insurance policy is adopted, and then a corresponding underwriting policy is used to underwrite the electronic device insurance application request. If the attribute of the target device is a new device, the inspection process can be omitted, and the underwriting can be directly determined to be passed, thereby improving the underwriting efficiency and improving the user's insurance experience. If the attribute of the target device is an old machine, the user can be prompted to upload the verification data of the target device, and the server can then perform verification and underwriting according to the verification data. It can be seen from the above description that, after receiving the electronic device insurance request, the server in this embodiment can obtain the behavior data of the user, and then determine the properties of the electronic device according to the behavior data, and according to the underwriting policy corresponding to the properties Underwriting insurance requests and underwriting through differentiated underwriting strategies can not only ensure the accuracy of underwriting, but also improve the efficiency of underwriting, thereby enhancing the user's insurance experience. The method for determining the attributes of the target device will be described in detail below through several embodiments. FIG. 2 is a schematic flowchart of a method for determining an attribute of a target device according to an exemplary embodiment of the present specification. Referring to FIG. 2 , the method for determining the attribute of the target device may include the following steps: Step 202 , acquiring historical transaction data of the user within a predetermined time period. In this embodiment, after receiving the electronic device insurance request sent by the user, the server may obtain the user account of the initiating user, and then obtain historical transactions of the corresponding user within a predetermined period of time from several e-commerce platforms based on the user account. material. For example, the server may determine the user's identity information based on the user account, and then acquire historical transaction data based on the identity information. In this embodiment, each piece of historical transaction data may include: order number, order time, purchased item identification, item type, merchant identification and other information. The predetermined time period may be preset by the developer, for example, within 10 days, 15 days, and the like. Step 204: Determine whether the historical transaction data includes purchase transaction data of an electronic device. Step 206, if yes, it is determined that the attribute of the target device is a new device. Based on the foregoing step 202, after acquiring the historical transaction data of the user within a predetermined time period, the server may determine whether the user has purchased an insurable electronic device within the predetermined time period according to the historical transaction data. If so, it can be inferred that what the user wants to insure is a newly purchased electronic device, and then the attributes of the target device can be determined as a new device. For example, Xiaobai logs in Xiaobai's account in the client installed in his mobile phone, and then sends an insurance request for mobile phone screen insurance to the server. After receiving the insurance request, the server can determine according to Xiaobai's account number. Xiaobai's identity information, such as a unique ID, etc. Then, according to Xiaobai's identity information, obtain Xiaobai's transaction data in the last 15 days from the e-commerce platform, and based on the 15-day transaction data to determine whether Xiaobai has purchased a mobile phone, if so, it can be inferred that Xiaobai wants to insure it is a new The purchased mobile phone can further determine the attributes of the target device of the insurance application as a new phone. In other examples, if the historical transaction data includes purchase transaction data of multiple electronic devices, the server may send a list of corresponding electronic devices to the user, so that the user can select the target device to be insured. After receiving the selection instruction sent by the user based on the electronic device list, the server may determine the electronic device selected by the user as the target device for this insurance application. Still taking Xiaobai as an example, if Xiaobai's transaction data in the last 15 days includes the purchase records of two mobile phones, you can send a list including the two mobile phones to Xiaobai. The list may include information such as mobile phone model, purchase date, purchase price, and business information. Xiaobai can select the mobile phone he wants to apply for insurance in the list. After receiving the selection instruction from Xiaobai, the server can determine the mobile phone selected by Xiaobai as the target device of this insurance request. It is worth noting that, if it is determined according to the user's historical transaction data that the multiple electronic devices purchased by the user are of the same model, the electronic device list may not be sent to the user. For example, if Xiaobai buys two identical mobile phones, he does not need to send the list to Xiaobai, and the server can confirm that Xiaobai wants to insure a new mobile phone of this model. In this embodiment, in addition to the e-commerce platform, the server can also obtain the historical transaction data of the user from other channels. For example, the offline transaction data of the user in the physical shopping mall can be obtained from the server of the physical shopping mall. The manual does not make any special restrictions on this. In this embodiment, the server can determine whether the property of the insurance subject device is a new device through the user's historical transaction data. On the one hand, the user does not need to upload the purchase certificate, which can greatly simplify the user's insurance application operation, thereby improving the insurance application efficiency; on the other hand It also breaks through the limitation that new phones can only be insured at the time of purchase, which greatly improves the user's insurance experience. FIG. 3 is a schematic flowchart of another method for determining an attribute of a target device shown in an exemplary embodiment of the present specification. Referring to FIG. 3 , the method for determining the attribute of the target device may include the following steps: Step 302 , obtain the device identifier of the device initiating the insurance application request of the electronic device as the initiator identifier. In this embodiment, after the user logs in to the server based on the user account in the client terminal, the client terminal can obtain the device identification of the electronic device used by the user, and report the device identification to the server. The device identifier can be reported by the client alone, and the device identifier can also be carried by the client and reported to the server in the service request. For example, the client can carry the device identifier in the electronic device insurance request sent by the user. Send to the server, this manual does not make any special restrictions. The device identification may include: Android ID (Android ID), IDFV (IdentifierForVendor, application developer identification), IMEI (International Mobile Equipment Identity, International Mobile Equipment Identity) and the like. In this embodiment, after receiving the electronic device insurance application request, the server can obtain the device identifier of the initiating device that initiates the electronic device insurance application request through the client, and can use it as the initiating identifier. Step 304 , searching for the device identifier of the user's historical login device as the historical identifier. In this embodiment, the server may also query the database based on the user account to obtain the device identifier of the historical login device corresponding to the user. The database stores the device identifiers of the electronic devices used by each user to log in to the server in the history. In one example, the server may acquire, from the database, the device identifiers of the electronic devices used by the user when logging in to the server several times recently, as historical identifiers, where there are multiple historical identifiers. In another example, considering that the user usually does not frequently change electronic devices for no reason, the server may also obtain the device ID of the electronic device used by the user when logging in to the server last time from the database, as a historical ID. Step 306, judging whether the originating identifier and the historical identifier are the same. Step 308, if they are not the same, determine that the attribute of the target device is a new device. Based on the aforementioned steps 302 and 304, the server can determine whether the originating identifier and the historical identifier are the same. When the server obtains the device ID of the electronic device used by the user when logging in to the server last time as a historical ID, if the originating ID and the historical ID are different, it can indicate the electronic device that the user has replaced, and it can be presumed that the user is a newly replaced electronic device Insured, and then the attributes of the target equipment can be judged as a new machine. If the server obtains multiple historical identifiers, it can respectively determine whether the originating identifier is the same as each historical identifier. If they are different, it can indicate that the user has replaced the electronic device, and it can be presumed that the user is a newly replaced electronic device. Insured, and then the attributes of the target equipment can be judged as a new machine. In other examples, when using the device identifier to determine the attributes of the target device, it is also possible to determine whether the user is a trusted user. The attribute is determined as a new machine, but the attribute of the target device is determined as an old machine, thereby improving the accuracy of the subsequent underwriting results and reducing the risk of fraudulent insurance caused by directly skipping the inspection machine and passing the underwriting. If the user is a trusted user, when the originating identification and the historical identification are different, the attribute of the target device can be determined as a new device. In this embodiment, whether the user is a trusted user may be determined according to the user's registration duration, login frequency, and the like. In one example, it can be determined whether the user's registration duration is less than the duration threshold value, and if it is less than the duration threshold value, it can be determined that the user is not a trusted user. The duration threshold value can be preset, for example, 1 month, 3 months, and the like. In another example, it can be determined whether the user has logged into the user account recently, and if not, it can be determined that the user is not a trusted user. For example, it can be determined whether the user has logged in to the user account in the past one month/three months. On the contrary, if the user's registration duration is greater than or equal to the duration threshold, and the user has recently logged in to the user account, it can be determined that the user is a trusted user. In this embodiment, the server can determine whether the target device insured by the user is a new device according to the device identifier of the user's login device, which can solve the problem of inaccurate identification of the new device's target device caused by incomplete acquisition of historical transaction data. The user uploads the proof of purchase, which can greatly simplify the user's insurance application operation and improve the insurance application efficiency. It is worth noting that this specification does not limit the execution order of the method for determining the device attribute of the embodiments shown in FIG. 2 and FIG. 3 . In addition, in the above implementation scheme for determining the attribute of the target device, if the attribute of the target device cannot be determined to be a new device through historical transaction data, device identification, etc., the attribute of the target device can be determined to be an old device, and the follow-up is based on the user uploaded data. The verification data is underwritten to ensure the accuracy of the underwriting. In addition, after determining the properties of the target device, the server can also send the properties of the target device to the client for confirmation by the user, and the user can make adjustments according to the actual situation. It is still assumed that Xiaobai has purchased a new mobile phone in the last 15 days. The server determines that the attribute of the target device is "new phone", and then "new phone" can be returned to the user as the default attribute. If Xiaobai wants to insure If it is not a new machine, other properties can be selected. In the actual implementation, in order to facilitate the user's understanding, taking the mobile phone screen insurance as an example, the user terminal can display the insurance application page shown in Figure 4, in which "newly purchased mobile phone" and "this mobile phone" in the mobile phone insurance Whether the target mobile phone to be insured is this mobile phone. If the user selects "Newly Purchased Mobile Phone", the server can obtain the user's historical transaction data, and then determine whether the user has recently purchased a new mobile phone according to the historical transaction data. Directly determine that the underwriting has passed. If the user selects "this mobile phone", it means that the mobile phone that the user wants to insure is the mobile phone currently in use. The mobile phone that the user is currently using may be a new mobile phone purchased by the user, that is, the attribute of the target device is a new phone; the mobile phone that the user is currently using may also be the old mobile phone of the user, that is, the attribute of the target device is "old phone" . In this case, the server can obtain the historical ID and the originating ID to confirm the properties of the target device, and can use the underwriting strategy corresponding to the determined properties to underwrite. Of course, in other cases, if the electronic device insured by the user is a multimedia device such as a video camera or a smart TV, the user may still use a mobile phone to insure, but the "insured device" cannot be a mobile phone, and developers can develop other styles of user interface , this manual does not make any special restrictions. 2. Underwriting When it is determined that the attribute of the target device is an old machine, the server sends a prompt to the user to upload the verification data. The verification data can be photos, videos and other data of the target device. After the verification data, the machine can be inspected through the verification data to determine whether the target equipment is in good condition and not damaged, and then determine the underwriting result. This manual provides a variety of uploading methods for verification data, and users can choose according to the actual situation. FIG. 5 is a schematic flowchart of a method for uploading verification data according to an exemplary embodiment of the present specification. Referring to FIG. 5 , the method for uploading verification data can be applied to an electronic device, and includes the following steps: Step 502 , when uploading the verification data triggering the electronic device to apply for insurance, a list of uploading methods is displayed. In this embodiment, after receiving the prompt information for uploading the verification data, the user can upload the verification data at a convenient time. When the user triggers the upload of the verification data, the user end of the electronic device can display the upload method list, and the upload method list can display the auxiliary equipment required for the corresponding upload method, and the user can select the upload method according to the actual situation. Taking mobile phone screen insurance as an example, the verification data is the photos or videos of the mobile phone screen. Please refer to the schematic diagram of the insurance application list page shown in Figure 6. Figure 6 provides two mobile phone screen shooting methods. One is to shoot with the help of others, which requires another mobile phone; if the user cannot find another mobile phone, he can also choose another kind of shooting. way, that is, take pictures in front of the mirror yourself. Among them, the auxiliary device required for the way others assisted shooting is another mobile phone; the auxiliary device required for self-shooting is a mirror. Step 504, in response to the uploading method selected by the user, jump to a corresponding uploading method guidance page, where the uploading method guidance page displays a corresponding uploading entry for the user to implement based on the uploading method after triggering the uploading entry Upload of calibration data of this equipment. Based on the list of uploading methods shown in the foregoing step 502, the user can select an appropriate uploading method, and the user terminal can then jump to a guide page corresponding to the uploading method. The guidance page displays the detailed introduction of the corresponding uploading method, and displays an uploading entry, and the user can trigger the uploading entry to photograph the verification data. It can be seen from the above description that this embodiment provides a variety of uploading methods for verification data during the process of applying for insurance of electronic equipment. Users can choose an appropriate method to upload verification data according to the actual situation, so as to realize online upload of verification data, which is convenient and fast. Greatly improve the user's insurance experience. The two uploading methods are described in detail below. 1. Taking the mobile phone screen insurance as an example when shooting in the mirror, if the user triggers the upload method of "shooting the camera in front of the mirror" on the page shown in Figure 6, the user terminal can jump to the upload method guide shown in Figure 7 The upload method guide page displays the upload entry "Start Shooting", as well as sample images of the upload method and shooting requirements. After triggering the upload portal, the user can call the front camera lens of the electronic device, and collect pictures, videos and other images through the front camera lens, and upload the image as verification data to the servo after collecting the image. device. In other examples, after the user triggers the uploading entry, the rear camera lens can also be called by default, and the user manually switches to the front camera lens for image acquisition, which is not limited in this specification. In other examples, please refer to the user interface shown in FIG. 8 , since the user needs to turn the phone over to take pictures in the mirror, and turn the phone screen to the mirror, when the user triggers the uploading entry, the timer can also be started to start timing, giving the The customer leaves the preparation time for flipping the mobile phone, and only starts to collect the image when the timing time is reached. The timing duration may be 3 seconds. To facilitate the user's understanding, the user terminal may display the timing duration in a countdown manner. This embodiment provides a method for uploading verification data photographed in front of a mirror for the user, on the one hand, the authenticity of the verification data can be ensured, and on the other hand, the implementation is simple and convenient, and the user experience is better. 2. Using other mobile phones to shoot still take the mobile phone screen insurance as an example. If the user triggers the upload method of "Use other mobile phones to shoot this camera" on the page shown in Figure 6, the client can jump to the upload method guide shown in Figure 9 page, the upload method guide page displays the upload entry "Start Shooting", as well as sample images and shooting requirements for the upload method. After the user triggers the uploading portal, the client can display the verification graphic code for uploading verification data, such as verification QR code. The verification two-dimensional code can carry information such as verification identification, user account, insurance information, and equipment identification. The user or the person assisting the user can use other mobile phones to scan the verification QR code, and parse the verification QR code. If the verification mark is obtained from the analysis, the camera lens of the camera can be called for image acquisition. , and after the collection is completed, the collected images and the user account, insurance information, equipment identification and other information obtained by parsing the QR code are sent to the server, and the server can determine the corresponding insurance request based on these information, and Underwriting. In this embodiment, the verification graphic code is a dynamic graphic code, for example, it can be refreshed once per minute. The use of dynamic graphic coding can effectively prevent users from cheating. For example, users can save the verification graphic coding by intercepting the screen, etc., and send the verification image coding to the mobile phone of the same model, and then collect the image of the mobile phone of the same model. as verification data, etc. In the above two uploading methods, non-sensing shooting can be adopted, that is, the user does not need to manually trigger the shooting start/shooting end buttons, and the shooting lens is automatically shot and uploaded, which simplifies the user operation and improves the user experience. In addition, the above two methods are described by taking the mobile phone screen insurance as an example. If the user is insured with other types of insurance such as comprehensive protection insurance, the verification data may also include the images on the side and back of the mobile phone, and the user terminal can output corresponding guidance. This specification will not repeat them one by one here. In other examples, since the auxiliary devices required for the above two uploading methods are different, the server may pre-store the mapping relationship between the uploading method and the uploading time period. On the one hand, when determining that the attribute of the target device is an old machine, the server may search for the uploading method corresponding to the current moment based on the mapping relationship, and send the uploading method to the user in the prompt information for uploading the verification data. The server can also carry all the uploading methods in the prompt information and send it to the user, and recommend the uploading method corresponding to the current moment first, which is not limited in this manual. On the other hand, when the user triggers the upload of the verification data, the server can also search for the upload method corresponding to the current moment according to the mapping relationship, and then return the upload method to the client, and the client can distinguish the upload method in the list of upload methods. The uploading method is displayed, for example, the uploading method is marked as recommended, etc. Of course, in this example, the mapping relationship can also be stored locally on the electronic device. When the user triggers the upload of the verification data, the client terminal obtains the mapping relationship locally, and searches for the upload method corresponding to the current moment. There is no special restriction on this. upload period upload method
8:00-18:00 Shot with another phone
18:00-8:00 Shooting in the mirror
Table 1 Please refer to Table 1, an example of the mapping relationship between upload time period and upload method. Among them, during the period of 8:00-18:00, users are more likely to be at work, and other uploading methods for shooting with mobile phones can be recommended first. For example, users can ask colleagues to help with shooting. During the period from 18:00 to 8:00 the next day, users are more likely to be at home, and it is recommended to use the uploading method of mirror shooting. Of course, the mapping relationship shown in Table 1 is just an example, and in practical applications, more complex mapping relationships can be set, such as distinguishing working days and rest days, etc., which are not specially limited in this specification. 3. Claim Settlement FIG. 10 is a schematic flowchart of a method for realizing an electronic device insurance claim set forth in an exemplary embodiment of the present specification. Referring to FIG. 10 , the method for realizing claims can be applied to the server, including the following steps: Step 1002 , receiving a claim confirmation application sent by the accident equipment, the claim confirmation application is sent by the accident equipment after scanning the designated graphic code , and the claim confirmation application carries a number of identification factors of the emergency equipment. In this embodiment, after judging that the underwriting is approved, the server may save the mapping relationship between the insurance policy and several identification factors of the electronic device insured by the user. When making a claim, the user can use the electronic device that needs to settle the claim (hereinafter referred to as the accident device) to scan the graphic code used for claim settlement, such as the claim QR code, and the electronic device can then obtain several identification factors of the device, and then based on the The identification factor constructs a claim confirmation application, and sends the claim confirmation application to the server. For example, after obtaining the electronic equipment that needs to be repaired and claimed, the maintenance personnel of electronic equipment can log in to the server with their user account in the client, and then scan the QR code for claim settlement, and the client parses the QR code for claim settlement, If the specified claim settlement identification is obtained from the analysis, several identification factors of the device can be obtained, and the steps of constructing a claim settlement confirmation application can be performed. In this embodiment, the identification factor of the electronic device may include device identifications such as IDFA (Identifier For Advertising, advertising identifier), IDFV, Android ID, and the like. Step 1004: According to the mapping relationship, it is judged whether the insurance policies corresponding to several identification factors of the emergency equipment can be found. Step 1006 , if the corresponding insurance policy is found, return a message allowing claim settlement to the insurance device. After receiving the claim confirmation application, the server may search the mapping relationship for insurance policies corresponding to several identification factors carried in the claim confirmation application. If the corresponding insurance policy is found, it can indicate that the electronic device in danger has purchased insurance before, and can return a message that allows claims to be settled, and subsequent maintenance personnel can directly find the insurance company to pay for the maintenance cost. If the corresponding insurance policy is not found, there may be two situations, one is that the device has not purchased insurance, and the other is that the user has not used the device to purchase insurance, and further judgment is required. It can be seen from the above description that the server in this embodiment can save the mapping relationship between several identification factors of the target equipment and the insurance policy, and then judge whether the equipment in danger has been insured according to the identification factors of the equipment in danger, so as to verify the claim. On the one hand, the combination of several identification factors such as IDFA is used to identify electronic devices, which can effectively solve the problem that application providers cannot obtain UDID (Unique Device Identifier) to identify electronic devices; on the other hand, the whole process does not require users to manually upload UDIDs, etc. Device identification greatly simplifies user operations and improves user insurance experience. The following is a detailed description from the establishment of the mapping relationship and the realization of the claim settlement process. 1. Please refer to FIG. 11 for the establishment of the mapping relationship. The process of establishing the mapping relationship may include the following steps: Step 1102, when the insurance application request of the electronic device is underwritten, determine whether the target device of the insurance application request is insured for the electronic device The originating device of the request. Step 1104, if yes, acquire several identification factors of the initiator device, and establish a mapping relationship between the several identification factors and the initiating device insurance policy. In this embodiment, after determining that the insurance application request of the electronic device is underwritten, the server may determine whether the target device of the insurance application request is the initiating device of the electronic device insurance application request. That is, the server determines whether the user is insured for a local device. If so, the server may obtain several identification factors of the initiating device through the client, and establish a mapping relationship between the several identification factors and the corresponding insurance policies. For example, a mapping relationship between the several identification factors and policy identifications is established. serial number IDFA IDFV policy
1 15dfa35g4 h41f6afg 123
2 4d5adffs5 Ghrte15f3 124
3 D4f3ad4fc Er5tjkb88 125
Table 2 Table 2 shows an example of the mapping relationship between equipment identification factors and insurance policies. It should be noted that Table 2 is only an example. In actual implementation, such a table may not be organized, and this specification does not make any special limit. In the above process, the server can use the following method to determine whether the target device is the initiating device of the electronic device insurance request. Method 1: Judging based on the attribute of the target device, when the server determines that the attribute of the target device is an old machine, the server can determine that the target device is the initiating device of the electronic device insurance request. That is, the insured user has not recently purchased a new electronic device, and the user has also logged in using the initiating device. When the server determines that the attribute of the target device is a new device, it can obtain the judgment method of the attribute of the new device. If the judgment path is the device identification judgment path, it can also be determined that the target device is the initiating device of the electronic equipment insurance request. For the method of determining the attributes of the new machine, reference may be made to the embodiments shown in FIG. 2 to FIG. 3 , which will not be repeated in this specification. Method 2: Judging based on the user's selection, please refer to the insurance application page shown in Figure 4 again. If the user applies for insurance through the insurance application page shown in Figure 4, the server can directly obtain the insurance mobile phone selected by the user. This mobile phone”, you can directly determine that the target device is the initiating device of the electronic device insurance request. In other examples, if the target device is not the initiating device of the electronic device insurance request, the server may save the mapping relationship between the insurance policy and the target device purchase order for verification in subsequent claims. For example, if the method for judging the attribute "new machine" of the target device is the historical transaction data method, it can be determined that the target device is not the initiating device of the insurance request. For another example, still taking FIG. 4 as an example, if the user selects "newly purchased mobile phone", it can also be determined that the target device is not the initiating device of the insurance request. In this case, the server can obtain the order ID of the target device from the user's historical transaction data, and establish a mapping relationship between the order ID and the policy ID for verification and use in subsequent claims. Generally speaking, when the target device is not the initiating device of the electronic device insurance request, there are usually two cases, and the following is an example of a mobile phone for description. The first scenario is when the user buys a new phone for himself, but uses the old phone to insure the new phone. Referring to FIG. 12 , in this case, the process of establishing the aforementioned mapping relationship may include the following steps: Step 1202 , when a new machine login is detected, determine whether there is an electronic device insurance policy corresponding to the login user. In this case, after the user uses a new mobile phone, he usually uses the new mobile phone to log in to the server. The server can obtain the logon of the logged-in mobile phone after the user logs in, and then determine whether the user logs in with the mobile phone for the first time, that is, whether it is a new mobile phone. machine login. If so, it can be determined according to the user account whether there is an electronic device insurance policy corresponding to the logged-in user, that is, whether the user has purchased mobile phone insurance. Step 1204, if it exists, determine whether the model of the new machine matches the model of the target device. Step 1206, if there is a match, obtain several identification factors of the new device, and establish a mapping relationship between the several identification factors and the electronic device insurance policy of the logged-in user. Based on the judgment result of the foregoing step 1102, if the user has purchased mobile phone insurance, the model of the target device can be searched according to the policy identifier. In this embodiment, the server can determine whether the model of the new mobile phone used by the user is the model of the target device. If it matches, it means that the new mobile phone currently used by the user is the mobile phone that the user has insured before, and then several identification factors of the new mobile phone can be obtained through the user terminal, and the mapping relationship between the several identification factors and the insurance policy can be established. When the subsequent server receives a claim request for the new mobile phone, it can perform claim verification according to the mapping relationship between several identification factors and insurance policies, thereby improving the accuracy of claim verification. The second scenario is when a user buys a new phone for someone else and then uses their own phone to insure the new phone. In this case, the probability of the user using the purchased new mobile phone to log in to his user account is extremely low, and it is difficult for the server to automatically obtain several identification factors of the new mobile phone. It can only establish the mapping relationship between the order identification and the policy identification. The user can also be prompted to log in with the new mobile phone, and the user can also be prompted to actively upload the identification factor of the new mobile phone. 2. Claims Settlement Process In the embodiment shown in Figure 10 above, when a user needs to settle a claim for damage to his electronic device, he can go directly to a designated maintenance center, and the maintenance personnel log in to the server using the emergency device and scan the QR code for verification. Optionally, in other examples, when a claim needs to be settled for damage to an electronic device, the user may also submit a claim request online. Marks the status of the corresponding policy as in claims and can return a list of designated repair centers to the user. Users can send the equipment in danger to the designated maintenance center by face-to-face delivery, express delivery, etc. The maintenance personnel of the designated maintenance center can log in to the server with their user account and scan the QR code for verification. In such an implementation manner, after receiving the claim confirmation application, the server can search for the insurance policy corresponding to the accident device in the mapping relationship between the insurance policy in the claim status and the identification factor, which can greatly reduce the number of comparisons and improve the claim settlement. Efficiency of verification. In other examples, after receiving the claim confirmation application sent by the accident equipment, if the corresponding insurance policy is not found according to several identification factors of the accident equipment, the server can obtain the log information of the accident equipment, such as the historical use of the accident equipment. The time point of the device's first login, and then calculate the time period from the first login time point to the present, as the first time period, the first time period can represent the use of the emergency equipment that the server can determine duration. The server can also obtain the order corresponding to the policy whose status is in claim settlement according to the mapping relationship between the order ID and the policy ID, and then calculate the duration from the point of time when the order was generated, as the second duration, the first duration. The second period represents the purchase period of the electronic device with the policy. Then, the server can determine the magnitude relationship between the first duration and each of the second durations. If the first duration is longer than all the second durations, it means that the out-of-risk device has been used for longer than the purchase duration of each electronic device with insurance, and there is suspicion of insurance fraud, and a claim prohibition message can be returned to the out-of-risk device. If the first duration is less than all of the second durations, a message allowing the claim settlement may be returned to the accident device. It is worth noting that, in the process of judging the duration, it is also possible to judge whether the model of the target device matches the model of the device in danger, etc., which will not be repeated here in this manual. It can be seen from the above description that the claim settlement scheme provided in this embodiment can save the mapping relationship between the purchase order of the new mobile phone and the insurance policy when the user insures the new mobile phone. Use time duration for claim verification, which can also ensure the accuracy of claim verification while simplifying the operation of insurance/claims. FIG. 13 is a schematic flowchart of another method for realizing an electronic device insurance claim according to an exemplary embodiment of the present specification. Referring to FIG. 13 , the method for realizing claim settlement can be applied to an electronic device, including the following steps: Step 1302 , after scanning a graphic code, determine whether the graphic code carries a specified claim settlement logo. Step 1304, if it is carried, obtain several identification factors of the device. Step 1306: Construct a claim confirmation application based on the identification factors, and send the claim confirmation application to the server for the server to search for insurance policies corresponding to the identification factors. Step 1308: Receive a message allowing claims settlement sent by the server after finding the insurance policies corresponding to the several identification factors. For the implementation method of claim settlement in this embodiment, reference may be made to the foregoing embodiments, which will not be repeated here in this specification. IV. Determination of Insurance Parameters This manual provides a dynamic insurance parameter determination scheme, which can flexibly determine the insurance parameters of different users, is simple and convenient to implement, and can effectively improve the user's insurance experience. The insurance parameters may include one or more of the insured amount, the insured period, the insured scope, and the insured type of insurance. FIG. 14 is a schematic flowchart of a method for determining an insurance parameter according to an exemplary embodiment of the present specification. Referring to FIG. 14 , the insurance parameter determination method can be applied to a server, including the following steps: Step 1402 , after the underwriting is approved, obtain several accumulated insurance parameters of the user. In this embodiment, after it is determined that the insurance underwriting of the electronic device has passed, it can be determined whether the user has the corresponding accumulated insurance parameter based on the mapping relationship between the user and the accumulated insurance parameter. If it exists, the accumulated insurance parameters corresponding to the user can be acquired. If it does not exist, the insurance parameters applied for by the user this time may be determined as the default insurance parameters. Step 1404, based on the accumulated insurance parameters and the default insurance parameters of the same type, determine the current insurance parameters for the current insurance application. Based on the foregoing step 1402, after the accumulated insurance parameters of the user are acquired, the accumulated insurance parameters and the default insurance parameters of the same type may be added to obtain the insurance parameters of the corresponding type of the current insurance application. Taking the screen insurance of electronic equipment as an example, suppose the default insurance amount is 1,000 yuan, and the default guarantee period is 1 year. If the accumulated insurance amount corresponding to the user is 20 yuan, and the accumulated insurance period is 1 month, the insurance amount that the user has purchased this time can be determined as 1020 yuan, and the protection period is determined as 1 year and 1 month. If the user's corresponding accumulated insurance amount is 10 yuan, and there is no corresponding accumulated insurance period, the user's insurance amount can be determined to be 1010 yuan this time, and the guarantee period is determined to be 1 year. If there is no accumulated insurance amount and accumulated insurance period corresponding to the user, the insurance amount applied for by the user this time can be determined as the default insurance amount of 1,000 yuan, and the guarantee period is determined as the default guarantee period of 1 year. In this embodiment, the server may send a message for acquiring the accumulated insurance parameters to the user after successfully executing the user's payment request. That is, the server sends the message to the user after the user successfully completes the payment. After acquiring the message, the user terminal can display the acquisition entry of the accumulated insurance parameters on the payment result page. The type of cumulative insurance parameter may be specified by the server and may be carried in the message by the server. For example, the server can specify the type of the accumulated insurance parameter as the guarantee period, and the client can then display the entry for obtaining the accumulated guarantee period on the payment result page. For another example, the server can specify the type of the accumulated insurance parameters as the amount of insurance and the period of protection, and the client can then display the entry for acquiring the accumulated amount of insurance and the entry for acquiring the accumulated guarantee period on the payment result page. In this embodiment, the user can trigger the acquisition portal through the payment result page, and the user terminal can send a corresponding type of cumulative insurance parameter acquisition request to the server. Taking the request for obtaining the accumulated insurance amount as an example, after receiving the request for obtaining the accumulated insurance amount, the server may determine whether the user has a corresponding electronic device insurance policy. If it exists, it means that the user has insured for electronic equipment. The server can obtain the current insurance amount of the corresponding insurance policy, calculate the sum of the accumulated insurance amount and the current insurance amount, and update the current insurance amount of the insurance policy with the sum value. Among them, the specific value of the accumulated insurance amount of different users can be the same, for example, the accumulated insurance amount of all users is 10 yuan; the specific value of the accumulated insurance amount of different users can also be different, and the server can determine the accumulated amount according to the user's payment amount. The specific value of the insured amount, for example, the specific value of the cumulative insured amount of the user with a higher payment amount is higher, or the cumulative insured amount of the user whose payment amount is greater than or equal to the threshold value is 20 yuan, but the payment amount is less than the threshold value. The accumulated insured amount of the user with the highest value is 10 yuan, etc., which is not limited in this manual. If there is no electronic equipment insurance policy corresponding to the user, it means that the user has not taken out electronic equipment insurance, and the server can save the mapping relationship between the user and the accumulated insurance amount and its value. The above mapping relationship determines the insured amount of the policy. In this embodiment, the accumulated insurance parameter may have a valid duration. Taking the insured amount as an example, the effective period can be preset, and is less than or equal to the guarantee period. Assuming that the effective period is 6 months, when the effective period of 6 months is reached, if the policy has not exceeded the guarantee period, the insured amount of the policy can be restored, for example, the current insured amount of the policy and the corresponding accumulated amount can be calculated. The difference between the specific value of the sum assured and the difference is updated to the current sum assured of the policy. Taking the guarantee period as an example, the effective period of the guarantee period is often for uninsured users. When the effective period is reached, if the user has not insured for electronic equipment insurance, it can be determined that the guarantee period is invalid. In other examples, the cumulative insurance parameters may also be provided only for users who have purchased electronic equipment insurance. For example, after the user's payment request is successfully executed, it can be determined whether there is an insurance policy corresponding to the user, and if so, a message for obtaining the accumulated insurance parameters can be sent to the user, and the user terminal will then display the insurance policy on the payment result page. Access to the accumulated insurance parameters. When the user triggers the acquisition entry, the server executes the update of the insurance parameters. If there is no insurance policy corresponding to the user, the server will not send the user a message to obtain the cumulative insurance parameters, and the client will not display the entry for obtaining the cumulative insurance parameters. It can be seen from the above description that in this embodiment, the acquisition entry of the accumulated insurance parameters can be displayed on the payment result page, and the user can trigger the update of the insurance parameters based on the acquisition entry. Fast and convenient insurance service recommendation, reducing the complexity of user operation and saving user operation time. Corresponding to the foregoing embodiments of the method for implementing insurance for electronic equipment, the present specification also provides embodiments of an apparatus for implementing insurance for electronic equipment. The embodiments of the apparatus for implementing insurance for electronic equipment in this specification can be applied to electronic equipment. The apparatus embodiment may be implemented by software, or may be implemented by hardware or a combination of software and hardware. Taking software implementation as an example, as a logical device, it is formed by reading the corresponding computer program instructions in the non-volatile memory into the memory through the processor of the electronic device where it is located. From the perspective of hardware, as shown in FIG. 15, it is a hardware structure diagram of the electronic equipment where the insurance implementation device of the electronic equipment of this specification is located, except for the processor, memory, network interface, and non- In addition to the volatile memory, the electronic device in which the apparatus in the embodiment is located may also include other hardware according to the actual function of the electronic device, which will not be repeated here. FIG. 16 is a block diagram of an apparatus for realizing insurance of an electronic device according to an exemplary embodiment of the present specification. Referring to FIG. 16 , the apparatus 1500 for implementing insurance for electronic equipment can be applied to the electronic equipment shown in FIG. 15 , including: a list display unit 1501 and a data uploading unit 1502 . Wherein, the list display unit 1501 displays a list of uploading methods when triggering the upload of the verification data for insurance application of the electronic device; the data uploading unit 1502, in response to the uploading method selected by the user, jumps to the corresponding uploading method guidance page, and the uploading method A corresponding upload entry is displayed on the guidance page, so that the user can upload the verification data of the device based on the upload method after triggering the upload entry. Optionally, the data uploading unit 1502: when the uploading entry of the first uploading mode is triggered by the user, call the front camera lens of the device to collect images, and use the collected images as the verification data of the device. Upload to server. Optionally, the data uploading unit 1502: after calling the front camera lens of the device, start a timer to start timing; when the timing period is reached, start capturing images. Optionally, the data uploading unit 1502: when the uploading entry of the second uploading mode is triggered by the user, generate a verification graphic code for other electronic devices to call their own photographic lens to capture the image after scanning the verification graphic code. image, and upload the collected image to the server as the verification data of the device. Optionally, the list display unit 1501: when triggering the upload of the verification data for insurance application of the electronic device, according to the preset mapping relationship between the upload period and the upload method, search for the upload method corresponding to the current moment; In the method list, the searched upload methods are displayed differently. For details of the implementation process of the functions and functions of each unit in the above device, please refer to the implementation process of the corresponding steps in the above method, which will not be repeated here. For the apparatus embodiments, since they basically correspond to the method embodiments, reference may be made to the partial descriptions of the method embodiments for related parts. The device embodiments described above are only illustrative, wherein the units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in One place, or it can be distributed over multiple network elements. Some or all of the modules can be selected according to actual needs to achieve the purpose of the solution in this specification. Those of ordinary skill in the art can understand and implement it without creative effort. The systems, devices, modules or units described in the above embodiments may be specifically implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer, and the specific form of the computer can be a personal computer, a notebook computer, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email sending and receiving device, a game console , tablets, wearables, or a combination of any of these devices. Corresponding to the foregoing embodiments of the method for implementing insurance for electronic equipment, the present specification further provides a device for implementing insurance for electronic equipment, the device comprising: a processor and a memory for storing machine-executable instructions. Among them, the processor and the memory are usually connected to each other by means of internal bus bars. In other possible implementations, the device may also include an external interface to be able to communicate with other devices or components. In this embodiment, by reading and executing the machine-executable instructions stored in the memory and corresponding to the insurance implementation logic of the electronic device, the processor is prompted to: Display the list of uploading methods; In response to the uploading method selected by the user, jump to the corresponding uploading method guidance page, where the uploading method guidance page displays the corresponding uploading entry for the user to use the uploading entry after triggering the uploading entry. The method realizes the uploading of the calibration data of the device. Optionally, when the upload portal of the first upload mode is triggered by the user, the front camera lens of the device is called to collect images, and the collected images are uploaded to the server as the verification data of the device. Optionally, the invoking the front camera lens of the device to capture images includes: starting a timer to start timing after invoking the front camera lens of the device; and starting to capture images when the timer period is reached. Optionally, when the uploading entry of the second uploading method is triggered by the user, a verification graphic code is generated, so that other electronic devices can call their own photographic lens to collect images after scanning the verification graphic code, and use the collected images. The image is uploaded to the server as the verification data of the device. Optionally, it also includes: when triggering the upload of the verification data for insurance application of the electronic device, searching for the upload method corresponding to the current moment according to the preset mapping relationship between the upload time period and the upload method; distinguishing between the upload method list Display the searched upload method. Optionally, auxiliary equipment required for the corresponding uploading method is displayed in the uploading method list. Optionally, the insurance purchased for the electronic device is a screen insurance of the electronic device. Corresponding to the foregoing embodiments of the insurance implementation method for electronic equipment, this specification also provides a computer-readable storage medium, where a computer program is stored on the computer-readable storage medium, and the program is executed by the processor to implement the following steps: When the verification data that triggers the electronic device to be insured is uploaded, a list of uploading methods will be displayed; in response to the uploading method selected by the user, it will jump to the corresponding uploading method guidance page, and the uploading method guidance page will display the corresponding uploading entry for the user After triggering the uploading entry, uploading the verification data of the device is realized based on the uploading method. Optionally, when the upload portal of the first upload mode is triggered by the user, the front camera lens of the device is called to collect images, and the collected images are uploaded to the server as the verification data of the device. Optionally, the invoking the front camera lens of the device to capture images includes: starting a timer to start timing after invoking the front camera lens of the device; and starting to capture images when the timer period is reached. Optionally, when the uploading entry of the second uploading method is triggered by the user, a verification graphic code is generated, so that other electronic devices can call their own photographic lens to collect images after scanning the verification graphic code, and use the collected images. The image is uploaded to the server as the verification data of the device. Optionally, it also includes: when triggering the upload of the verification data for insurance application of the electronic device, searching for the upload method corresponding to the current moment according to the preset mapping relationship between the upload time period and the upload method; distinguishing between the upload method list Display the searched upload method. Optionally, auxiliary equipment required for the corresponding uploading method is displayed in the uploading method list. Optionally, the insurance purchased for the electronic device is a screen insurance of the electronic device. The foregoing describes specific embodiments of the present specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims can be performed in a different order than in the embodiments and still achieve desirable results. Additionally, the processes depicted in the figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some embodiments, multiplexing and parallel processing are also possible or may be advantageous. The above descriptions are only preferred embodiments of this specification, and are not intended to limit this specification. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of this specification shall be included in this specification. within the scope of protection.
