這裡將詳細地對示例性實施例進行說明,其示例表示在附圖中。下面的描述涉及附圖時,除非另有表示,不同附圖中的相同數字表示相同或相似的要素。以下示例性實施例中所描述的實施方式並不代表與本說明書相一致的所有實施方式。相反,它們僅是與如所附申請專利範圍中所詳述的、本說明書的一些態樣相一致的裝置和方法的例子。
在本說明書使用的術語是僅僅出於描述特定實施例的目的,而非旨在限制本說明書。在本說明書和所附申請專利範圍中所使用的單數形式的“一種”、“所述”和“該”也旨在包括多數形式,除非上下文清楚地表示其他含義。還應當理解,本文中使用的術語“和/或”是指並包含一個或多個相關聯的列出項目的任何或所有可能組合。
應當理解,儘管在本說明書可能採用術語第一、第二、第三等來描述各種資訊,但這些資訊不應限於這些術語。這些術語僅用來將同一類型的資訊彼此區分開。例如,在不脫離本說明書範圍的情況下,第一資訊也可以被稱為第二資訊,類似地,第二資訊也可以被稱為第一資訊。取決於語境,如在此所使用的詞語“如果”可以被解釋成為“在……時”或“當……時”或“反應於確定”。
本說明書提供一種電子設備投保的校驗實現方案。
上述電子設備投保的保險可以為電子設備的螢幕保險,也可以為電子設備的全面保障險等電子設備可投保的險種。
上述電子設備可以為手機、平板電腦、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、他人輔助拍攝
圖9是本說明書一示例性實施例示出的一種投保校驗資料採集方法的流程示意圖。
圖9所示的採集方法可應用於本次投保的標的設備,包括以下步驟:
步驟902,在觸發電子設備投保的輔助校驗時,生成校驗許可證和校驗圖形編碼。
仍以手機螢幕保險為例,若用戶在圖6所示的頁面中觸發“使用其他手機拍攝本機”的上傳方式,客戶端可跳轉到圖10所示的上傳方式指導頁面,所述上傳方式指導頁面中展示有上傳入口“開始拍攝”,也展示有該上傳方式的示例影像以及拍攝要求。
用戶觸發該上傳入口視為觸發電子設備投保的輔助校驗,客戶端可生成校驗許可證和校驗圖形編碼。
其中,所述校驗圖形編碼可以為校驗條形碼、校驗二維碼等,例如,客戶端可根據校驗標識、用戶帳號、投保資訊、設備標識等資料生成校驗二維碼。
所述校驗許可證可以為一串字符,例如6位數字、8位字母、10位數字和字母的組合等。
在一個例子中,在生成校驗許可證時,可獲取當前時刻,然後基於所述當前時刻,採用MD5(MD5 Message-Digest Algorithm,消息摘要算法)、SHA-1(Secure Hash Algorithm 1,安全散列算法1)等算法生成校驗許可證。
在另一個例子中,在生成校驗許可證時,可基於當前時刻和設備標識,採用MD5等算法生成校驗許可證。
在其他例子中,還可以基於其他資訊和算法生成校驗許可證,本說明書對此不作特殊限制。
步驟904,展示所述校驗許可證和所述校驗圖形編碼,以供輔助設備基於所述校驗圖形編碼呼叫自身攝像頭採集本設備的設備影像,基於所述校驗許可證進行有效性檢測,並在通過有效性檢測後,將所述設備影像確定為本設備的投保校驗資料。
在本實施例中,在觸發電子設備投保的輔助校驗後,可展示投保校驗頁面。
在一個例子中,所述投保校驗頁面中僅包括所述校驗圖形編碼,輔助設備掃描所述校驗圖形編碼後標的設備可進行頁面跳轉,進而展示所述校驗許可證;或者,標的設備在頁面跳轉後也可同時展示所述校驗圖形編碼和所述校驗許可證。
在另一個例子中,所述投保校驗頁面中可同時包括所述校驗圖形編碼和所述校驗許可證(即所述校驗許可證和所述校驗圖形編碼展示在同一頁面中),例如可參考圖11。輔助設備掃描所述校驗圖形編碼後,標的設備可不進行頁面跳轉,本說明書對此不作特殊限制。
圖12是本說明書一示例性實施例示出的另一種投保校驗資料採集方法的流程示意圖。
圖12所示的採集方法可應用於輔助設備,包括以下步驟:
步驟1202,採集標的設備的投保校驗頁面影像,所述投保校驗頁面中展示有校驗圖形編碼。
步驟1204,基於所述校驗圖形編碼呼叫自身攝像頭採集所述標的設備的設備影像。
在本實施例中,當標的設備展示投保校驗頁面後,可使用輔助設備採集標的設備的投保校驗頁面影像。
例如,用戶可打開輔助設備中裝載的客戶端,然後開啟“掃一掃”以採集投保校驗頁面影像。
在一個例子中,輔助設備在採集到所述投保校驗頁面影像後,可解析所述投保校驗頁面中展示的校驗圖形編碼,若解析到所述校驗圖形編碼中攜帶有預設的校驗標識,則可呼叫自身攝像頭進行影像採集,用戶可調整標的設備或輔助設備的位置,使得輔助設備採集到標的設備的設備影像,即標的設備的螢幕影像。
在另一個例子中,輔助設備在採集到所述投保校驗頁面影像後,可將所述投保校驗頁面影像中的校驗圖形編碼發送給碼平台,例如將所述校驗圖形編碼的碼值發送給碼平台。由碼平台對所述校驗圖形編碼進行解析,並在解析到所述預設的校驗標識後,向輔助設備回傳採集指令,輔助設備基於所述採集指令呼叫自身攝像頭採集標的設備的設備影像。
其中,所述碼平台具有解析圖形編碼的功能,在接收到客戶端發送的圖形編碼後,基於解析結果向客戶端回傳不同的指令,例如呼叫攝像頭的採集指令,跳轉到支付頁面的跳轉指令等。
步驟1206,識別出所述標的設備展示的校驗許可證,並基於所述校驗許可證進行有效性檢測。
在本實施例中,輔助設備還可從採集到的影像中識別出校驗許可證,例如輔助設備可基於OCR(Optical Character Recognition,光學字符識別)識別技術識別出校驗許可證,然後基於校驗許可證進行有效性檢測。
在一個例子中,輔助設備可從所述投保校驗頁面中識別出校驗許可證。
例如,標的設備展示的投保校驗頁面中同時展示有校驗圖形編碼和校驗許可證,輔助設備透過“掃一掃”採集到投保校驗頁面影像後,基於校驗圖形編碼確定當前處於電子設備投保的輔助拍攝校驗場景(例如,從所述校驗圖形編碼中解析得到預設的校驗標識,或接收到碼平台回傳的採集指令等),然後可基於OCR技術識別出所述投保校驗頁面影像中展示的校驗許可證。
在另一個例子中,輔助設備可從所述設備影像中識別出所述校驗許可證。在該例子中,並不限定投保校驗頁面中是否展示有校驗許可證。輔助設備在採集到投保校驗頁面影像後,基於校驗圖形編碼採集標的設備的設備影像,然後可採用OCR技術從所述設備影像中識別出所述校驗許可證。
例如,投保校驗頁面中僅包括校驗圖形編碼,輔助設備掃描校驗圖形編碼後標的設備進行頁面跳轉,跳轉到展示有校驗許可證的頁面,輔助設備採集標的設備的設備影像中就會包括有校驗許可證,進而進行校驗許可證的識別。
再例如,投保校驗頁面中同時展示有校驗圖形編碼和校驗許可證,輔助設備基於投保校驗頁面中的校驗圖形編碼呼叫攝像頭採集影像,標的設備可不執行頁面跳轉,輔助設備採集到的設備影像中依然包括所述投保校驗頁面,進而可在所述設備影像中識別出校驗許可證。
在實際應用中,輔助設備在採集到設備影像後,可為該設備影像添加解析標識,後續可基於該解析標識觸發校驗許可證的識別。例如,針對掃碼後採集到的影像,若確定該影像攜帶解析標識,則可採用OCR技術進行校驗許可證的識別。透過解析標識的添加,可準確確定出需要進行校驗許可證識別的影像,無需對所有影像進行校驗許可證的識別,可大大節省設備的處理資源,提高識別效率。
在其他例子中,標的設備也可以基於其他策略展示校驗許可證,相應的輔助設備也可以從其他影像中識別出校驗許可證,本說明書對此不作特殊限制。
在本說明書中,輔助設備在識別出校驗許可證後,可採用相應算法解析所述校驗許可證,從所述校驗許可證中解析得到所述校驗許可證的生成時刻,然後基於該生成時刻進行有效性檢測。
在一個例子中,輔助設備可獲取校驗許可證所在影像的採集時刻,然後計算採集時刻和校驗許可證生成時刻的時間差。
若時間差大於預設第一時長,說明校驗許可證所在影像的採集時刻距離校驗許可證的生成時刻時間較長,即標的設備展示校驗許可證後過了一段時間輔助設備才採集影像,可能存在校驗許可證被翻拍、拍攝的投保校驗影像是偽造資料等風險,進而可確定校驗失敗。
若時間差小於等於所述第一時長,可確定通過有效性檢測。
其中,所述第一時長可以是2秒、4秒等。
在另一個例子中,輔助設備可將識別出的校驗許可證發送給伺服器,由伺服器解析得到校驗許可證的生成時刻,然後計算所述生成時刻和所述校驗許可證的發送時刻之間的時間差。
若該時間差大於預設第二時長,說明校驗許可證發送時刻距離校驗許可證的生成時刻時間較長,也可能存在校驗許可證被翻拍、拍攝的投保校驗影像是偽造資料等風險,進而可確定校驗失敗。
若該時間差小於等於所述第二時長,可確定通過有效性檢測。
其中,所述第二時長大於所述第一時長,例如可以是10秒、15秒等。
當然,在其他例子中,輔助設備也可解析得到校驗許可證的生成時刻後將該生成時刻發送給伺服器;伺服器也可以校驗許可證的接收時刻為基準,計算生成時刻和校驗許可證接收時刻之間的時間差,然後進行判斷,本說明書對此不作特殊限制。
在本實施例中,在基於校驗許可證生成時刻進行有效性檢測的基礎上,還可結合設備標識進行有效性檢測。
例如,標的設備基於設備標識和當前時刻生成校驗許可證,輔助設備一態樣可從校驗許可證中解析得到設備標識,另一態樣還可從校驗圖形編碼中解析得到設備標識,然後可判斷這兩個設備標識是否相同,若相同,可確定設備標識通過有效性檢測,若時間差也通過有效性檢測,則可確定最終通過有效性檢測,進而執行後續步驟。若兩個設備標識不相同,即便時間差通過有效性檢測,也可以確定最終未通過有效性檢測,可向用戶回傳檢測識別的提示資訊。
步驟1208,在通過有效性檢測後,將所述設備影像確定為標的設備的投保校驗資料。
基於前述步驟1206,在確定通過有效性檢測後,可將採集到的設備影像確定為標的設備的投保校驗資料。
在本實施例中,輔助設備還可從校驗圖形編碼中解析得到標的設備的設備標識、投保資訊、用戶帳號等資訊,然後將這些資訊和投保校驗資料發送給伺服器,伺服器進而可以確定對應的投保請求,並進行核保。例如,根據投保校驗資料確定標的設備螢幕是否完好等。
在本實施例中,標的設備可週期性的動態更新校驗圖形編碼和校驗許可證。所述校驗許可證的更新週期往往小於所述校驗圖形編碼的更新週期。例如,為確保用戶的掃碼體驗,可每3分鐘更新1次校驗圖形編碼,為防止用戶作弊,可每2秒更新1次校驗許可證。例如用戶透過截屏等方式保留該校驗圖形編碼和校驗許可證,並將該校驗圖形編碼和校驗許可證發送至相同型號的手機,後續使用輔助設備採集該相同型號手機的影像偽造投保校驗資料等。
由以上描述可以看出,本實施例在採集投保校驗資料的過程中使用校驗許可證來進行有效性檢測,可有效識別出翻拍、截屏等作弊操作,識別出偽造的投保校驗資料,防止電子設備“帶病投保”,進而有效降低保險公司的資損風險,利於線上保險業務的推廣。
在其他實施例中,標的設備可在投保校驗頁面中同時展示校驗圖形編碼和校驗許可證,輔助設備在透過“掃一掃”採集投保校驗頁面影像後,可先識別出校驗許可證進行有效性檢測,當確定通過有效性檢測後,再基於校驗圖形編碼呼叫攝像頭進行設備影像的採集,並將採集到的設備影像確定為投保校驗資料,本說明書對此不作特殊限制。
在上述兩種上傳方式中,均可採用無感拍攝,即無需用戶手動觸發拍攝開始/拍攝結束的按鈕,呼叫攝像頭之後自動拍攝上傳,簡化用戶操作,提升用戶的使用體驗。
此外,上述兩種方式均以手機螢幕保險為例進行描述,若用戶投保的是全面保障險等其他險種,校驗資料可能還需包括手機側面、背面的影像,客戶端可輸出相應引導,本說明書在此不再一一贅述。
在其他例子中,由於上述兩種上傳方式所需的輔助設備不同,伺服器可預先儲存上傳方式和上傳時段之間的映射關係。
一態樣,伺服器可在確定標的設備的屬性是老機時,基於所述映射關係查找當前時刻對應的上傳方式,並將所述上傳方式攜帶在上傳校驗資料的提示資訊中發送給用戶。伺服器也可以將所有上傳方式攜帶在該提示資訊中發送給用戶,並優先推薦當前時刻對應的上傳方式,本說明書對此不作特殊限制。
另一態樣,在用戶觸發校驗資料上傳時,伺服器也可根據所述映射關係查找當前時刻對應的上傳方式,然後將所述上傳方式回傳給客戶端,客戶端可在上傳方式列表中區別顯示所述上傳方式,例如將所述上傳方式標注為推薦等。
當然,在這個例子中,所述映射關係也可保存在電子設備本地,當用戶觸發校驗資料上傳時,客戶端從本地獲取所述映射關係,並進行當前時刻對應上傳方式的查找,本說明書對此不作特殊限制。
上傳時段 | 上傳方式 |
8:00-18:00 | 使用其他手機拍攝 |
18:00-8:00 | 對照鏡子拍攝 |
表1
請參考表1,一種上傳時段和上傳方式之間映射關係的示例。其中,8:00-18:00這個時段,用戶大概率是在上班,可優先推薦使用其他手機拍攝的上傳方式,例如,用戶可以讓同事幫忙拍攝。18:00至第二天8:00這個時段,用戶大概率是在家中,可優先推薦使用對照鏡子拍攝的上傳方式。
當然,表1所示的映射關係只是一種示例,在實際應用中,還可設置更複雜的映射關係,例如區分工作日和休息日等,本說明書對此不作特殊限制。
三、理賠
圖13是本說明書一示例性實施例示出的一種電子設備保險理賠的實現方法的流程示意圖。
請參考圖13,所述理賠的實現方法可應用於伺服器,包括以下步驟:
步驟1302,接收出險設備發送的理賠確認申請,所述理賠確認申請由所述出險設備在掃描指定圖形編碼後發送,所述理賠確認申請中攜帶所述出險設備的若干標識因子。
在本實施例中,伺服器在確定核保通過後,可保存保單和用戶投保的電子設備的若干標識因子之間的映射關係。
用戶在理賠時,可使用需要理賠的電子設備(後續稱為出險設備)掃描用於理賠的圖形編碼,例如理賠二維碼,電子設備進而可以獲取本設備的若干標識因子,然後基於所述若干標識因子構造理賠確認申請,並將該理賠確認申請發送至伺服器。
例如,電子設備的維修人員在拿到需要維修及理賠的電子設備後,可在客戶端中使用自己的用戶帳號登錄伺服器,然後掃描理賠二維碼,客戶端解析所述理賠二維碼,若從解析得到指定的理賠標識,則可獲取本設備的若干標識因子,並執行構造理賠確認申請的步驟。
在本實施例中,所述電子設備的標識因子可包括IDFA(Identifier For Advertising,廣告標識符)、IDFV、Android ID等設備標識。
步驟1304,根據所述映射關係,判斷能否查找到所述出險設備的若干標識因子對應的保單。
步驟1306,若查找到對應的保單,則向所述出險設備回傳允許理賠的消息。
伺服器在接收到所述理賠確認申請後,可在所述映射關係中查找理賠確認申請中攜帶的若干標識因子對應的保單。
若查找到對應的保單,則可說明出險的電子設備之前購買過保險,可以回傳允許理賠的消息,後續維修人員可直接找保險公司來支付維修費用。
若未查找到對應的保單,可能存在兩種情況,一種是出險設備未購買過保險,另一種是用戶未使用出險設備購買保險,需要進行進一步判斷。
由以上描述可以看出,本實施例伺服器可保存標的設備若干標識因子和保單之間的映射關係,後續根據出險設備的標識因子判斷出險設備是否投保過保險,以對理賠進行驗證。一態樣採用IDFA等若干標識因子組合的方式來標識電子設備,可有效解決應用提供方無法獲取UDID (Unique Device Identifier)來標識電子設備的問題;另一態樣,整個過程也無需用戶手動上傳UDID等設備標識,大大簡化用戶操作,提升用戶投保體驗。
下面分別從映射關係的建立、理賠流程的實現來進行詳細描述。
1、映射關係的建立
請參考圖14,上述映射關係的建立過程可包括以下步驟:
步驟1402,當電子設備投保請求核保通過後,判斷所述投保請求的標的設備是否為所述電子設備投保請求的發起設備。
步驟1404,若是,則獲取所述發起設備的若干標識因子,並建立所述若干標識因子和所述發起設備保單之間的映射關係。
在本實施例中,伺服器在確定電子設備投保請求核保通過後,可判斷投保請求的標的設備是否為電子設備投保請求的發起設備。即,伺服器判斷用戶投保的是否為本機設備。
若是,伺服器可透過客戶端獲取所述發起設備的若干標識因子,並建立所述若干標識因子和對應保單之間的映射關係。例如,建立所述若干標識因子和保單標識之間的映射關係。
序號 | IDFA | IDFV | 保單 |
1 | 15dfa35g4 | h41f6afg | 123 |
2 | 4d5adffs5 | Ghrte15f3 | 124 |
3 | D4f3ad4fc | Er5tjkb88 | 125 |
表2
表2示出了一種設備標識因子和保單之間映射關係的示例,需要說明的是,表2僅僅是一種示例,在實際實現中,也可不組織這樣的表格,本說明書對此不作特殊限制。
上述過程中,伺服器可透過以下方法確定標的設備是否為電子設備投保請求的發起設備。
方法一:基於標的設備屬性進行判斷
伺服器可在確定標的設備的屬性是老機時,確定標的設備為電子設備投保請求的發起設備。即,投保用戶最近未購買過新的電子設備,並且用戶曾經也使用過發起設備登錄。
伺服器在確定標的設備的屬性是新機時,可獲取新機屬性的判斷途徑。
若判斷途徑是設備標識判斷途徑時,也可確定標的設備為電子設備投保請求的發起設備。
所述新機屬性的判斷途徑可參考前述圖2-圖3所示的實施例,本說明書在此不再一一贅述。
方法二:基於用戶的選擇進行判斷
請再次參考圖4所示的投保頁面,若用戶透過圖4所示的投保頁面進行投保,伺服器可直接獲取用戶選擇的保障手機,若用戶選擇的是“本手機”,則可直接確定標的設備為電子設備投保請求的發起設備。
在其他例子中,若標的設備不是電子設備投保請求的發起設備,則伺服器可保存保單和標的設備購買訂單之間的映射關係,以便後續理賠時進行驗證。
例如,若標的設備屬性“新機”的判斷途徑是歷史交易資料途徑時,可確定標的設備不是投保請求的發起設備。
再例如,仍以圖4為例,若用戶選擇的是“新購手機”,則也可確定標的設備不是投保請求的發起設備。
在這種情況下,伺服器可在用戶的歷史交易資料中獲取標的設備的訂單標識,並建立訂單標識和保單標識之間的映射關係,以供後續理賠時驗證使用。
一般而言,當標的設備不是電子設備投保請求的發起設備時,通常包括兩種情況,下面以手機為例進行說明。
第一種情況是用戶為自己購買新手機,但使用舊手機為新手機投保。
請參考圖15,在這種情況下,前述映射關係的建立過程可包括以下步驟:
步驟1502,在檢測到新機登錄時,判斷是否存在登錄用戶對應的電子設備保單。
在這種情況下,用戶在使用新手機後,通常會使用新手機登錄伺服器,伺服器可在用戶登錄後,獲取登錄手機的標識,然後判斷用戶是否首次使用該手機登錄,即是否為新機登錄。
若是,則可根據用戶帳號判斷是否存在登錄用戶對應的電子設備保單,即查找用戶是否購買過手機保險。
步驟1504,若存在,則判斷所述新機的型號是否匹配標的設備型號。
步驟1506,若匹配,則獲取所述新機的若干標識因子,並建立所述若干標識因子和所述登錄用戶的電子設備保單之間的映射關係。
基於前述步驟1502的判斷結果,若用戶購買過手機保險,則可根據保單標識查找標的設備的型號。
在本實施例中,伺服器可判斷用戶使用的新手機的型號是否標的設備的型號。
若匹配,則可說明用戶當前使用的新手機就是用戶之前投保的手機,進而可透過客戶端獲取所述新手機的若干標識因子,並建立所述若干標識因子和保單之間的映射關係。
後續伺服器在接收到針對該新手機的理賠請求時,就可根據若干標識因子和保單之間的映射關係來進行理賠驗證,進而提高理賠驗證準確性。
第二種情況是用戶為他人購買新手機,然後使用自己的手機為新手機投保。
在這種情況下,用戶使用購買的新手機登錄自身用戶帳號的概率極低,伺服器較難自動獲取到該新手機的若干標識因子,可僅建立訂單標識和保單標識之間的映射關係,也可提示用戶使用新手機登錄,還可提示用戶主動上傳新手機的標識因子。
2、理賠流程
在前述圖13所示的實施例中,用戶電子設備損壞需要理賠時,可直接到指定的維修中心,由維修人員使用出險設備登錄伺服器之後掃描二維碼進行驗證。
可選的,在其他例子中,在電子設備損壞需要理賠時,用戶也可以先在線提交理賠請求,例如,用戶可先使用投保的電子設備發送理賠申請,伺服器在接收到該理賠申請後,將對應保單的狀態標記為理賠中,並可向用戶回傳指定的維修中心列表。
用戶可透過面交、快遞等方式將出險設備送至指定維修中心,指定維修中心的維修人員可使用自己的用戶帳號登錄伺服器之後掃描二維碼以進行驗證。
在這樣的實現方式中,伺服器在接收到理賠確認申請後,可在狀態為理賠中的保單與標識因子之間的映射關係中查找出險設備對應的保單,可大大減少比對數量,提高理賠驗證的效率。
在其他例子中,伺服器在接收到出險設備發送的理賠確認申請後,若根據出險設備的若干標識因子未查找到對應的保單,則可獲取出險設備的登錄資料,例如歷史上使用所述出險設備第一次登錄的時間點,然後計算所述第一次登錄的時間點距今的時長,作為第一時長,該第一時長可表示伺服器可確定的所述出險設備的使用時長。
伺服器還可根據訂單標識和保單標識之間的映射關係,獲取狀態為理賠中的保單對應的訂單,然後計算所述訂單的生成時間點距今的時長,作為第二時長,該第二時長表示具有保單的電子設備的購買時長。
然後,伺服器可判斷第一時長和各第二時長的大小關係。若第一時長大于所有第二時長,則可說明出險設備使用的時長大於各具有保險的電子設備的購買時長,存在騙保嫌疑,可向所述出險設備回傳禁止理賠的消息。
若第一時長小於所有第二時長,則可向出險設備回傳允許理賠的消息。
值得注意的是,在時長判斷的過程中,還可判斷標的設備型號與出險設備型號是否匹配等,本說明書在此不再一一贅述。
由以上描述可以看出,本實施例提供的理賠方案,在用戶為新手機投保時,可保存新手機購買訂單和保單之間的映射關係,後續可根據新手機的購買時長和出險手機的使用時長來進行理賠驗證,在簡化投保/理賠的操作時,還可確保理賠驗證的準確性。
圖16是本說明書一示例性實施例示出的另一種電子設備保險理賠的實現方法的流程示意圖。
請參考圖16,所述理賠的實現方法可應用於電子設備,包括以下步驟:
步驟1602,在掃描圖形編碼後,判斷所述圖形編碼中是否攜帶指定的理賠標識。
步驟1604,若攜帶,則獲取本設備的若干標識因子。
步驟1606,基於所述標識因子構造理賠確認申請,並將所述理賠確認申請發送給伺服器,以供伺服器查找所述若干標識因子對應的保單。
步驟1608,接收伺服器在查找到所述若干標識因子對應的保單後發送的允許理賠的消息。
本實施例中理賠的實現方法可參考前述實施例,本說明書在此不再一一贅述。
四、保險參數的確定
本說明書提供一種動態保險參數的確定方案,可靈活確定不同用戶的保險參數,實現簡單、便捷,還可有效提升用戶的投保體驗。
所述保險參數可包括保額、保障期限、保障範圍、保障險種中的一種或多種。
圖17是本說明書一示例性實施例示出的一種保險參數確定方法的流程示意圖。
請參考圖17,所述保險參數確定方法可應用於伺服器,包括以下步驟:
步驟1702,在核保通過後,獲取所述用戶的若干累加保險參數。
在本實施例中,在確定電子設備保險核保通過後,可基於用戶和累加保險參數之間的映射關係,判斷所述用戶是否存在對應的累加保險參數。
若存在,則可獲取所述用戶對應的累加保險參數。
若不存在,則可將用戶本次投保的保險參數確定為缺省保險參數。
步驟1704,基於所述累加保險參數和相同類型的缺省保險參數確定本次投保的當前保險參數。
基於前述步驟1702,在獲取到用戶的累加保險參數之後,可將累加保險參數和相同類型的缺省保險參數相加,得到本次投保對應類型的保險參數。
以電子設備的螢幕保險為例,假設缺省保額是1000元,缺省保證期限是1年。
若用戶對應的累加保額是20元,累加保障期限是1個月,則可將用戶本次投保的保額確定為1020元,保障期限確定為1年零1個月。
若用戶對應的累加保額是10元,無對應的累加保障期限,則可將用戶本次投保的保額確定為1010元,保障期限確定為1年。
若不存在用戶對應的累加保額和累加保障期限,則可將用戶本次投保的保額確定為缺省保額1000元,保障期限確定為缺省保障期限1年。
在本實施例中,伺服器可在成功執行用戶的支付請求後,向所述用戶發送獲取累加保險參數的消息。即伺服器在用戶成功完成支付後,向其發送所述消息。客戶端在獲取到該消息後,可在支付結果頁面中展示所述累加保險參數的獲取入口。
所述累加保險參數的類型可由伺服器指定,並可由伺服器攜帶在所述消息中。
例如,伺服器可指定累加保險參數的類型為保障期限,客戶端進而可以在支付結果頁面中展示累加保障期限的獲取入口。
再例如,伺服器可指定累加保險參數的類型為保額和保障期限,客戶端進而可以在支付結果頁面中展示累加保額的獲取入口和累加保障期限的獲取入口。
在本實施例中,用戶可透過所述支付結果頁面觸發所述獲取入口,客戶端可發送對應類型的累加保險參數獲取請求至伺服器。
以累加保額獲取請求為例,伺服器在接收到所述累加保額獲取請求後,可判斷所述用戶是否存在對應的電子設備保單。
若存在,可說明用戶投保過電子設備保險,伺服器可獲取對應保單的當前保額,然後計算累加保額和當前保額的和值,並用所述和值更新所述保單的當前保額。
其中,不同用戶的累加保額的具體數值可相同,例如所有用戶的累加保額都是10元;
不同用戶的累加保額的具體數值也可不同,伺服器可以根據用戶的支付金額確定其累加保額的具體數值,例如,支付金額越高的用戶的累加保額的具體數值越高,或者支付金額大於等於閾值的用戶的累加保額是20元,而支付金額小於所述閾值的用戶的累加保額是10元等,本說明書對此不作特殊限制。
若不存在用戶對應的電子設備保單,則可說明用戶尚未投保過電子設備保險,伺服器可保存用戶和累加保額及其數值之間的映射關係,後續用戶投保電子設備保險時,可基於所述映射關係確定保單的保額。
在本實施例中,所述累加保險參數可具有有效時長。
以保額為例,所述有效時長可預先設置,小於等於保障期限。假設所述有效時長是6個月,則在到達6個月的有效時長時,若保單尚未超過保障期限,則可還原保單的保額,例如計算所述保單的當前保額和對應累加保額具體數值的差值,並將該差值更新為所述保單的當前保額。
以保障期限為例,保障期限的有效時長往往是針對未投保的用戶,在到達所述有效時長時,如果用戶仍未投保電子設備保險,則可確定所述保障期限無效。
在其他例子中,所述累加保險參數也可以僅為投保過電子設備保險的用戶提供。
例如,在成功執行用戶的支付請求後,可判斷是否存在所述用戶對應的保單,若存在,則可向所述用戶發送獲取累加保險參數的消息,客戶端進而在支付結果頁面中展示所述累加保險參數的獲取入口。
當用戶觸發所述獲取入口時,伺服器執行保險參數的更新。
若不存在用戶對應的保單,伺服器不向用戶發送獲取累加保險參數的消息,客戶端也不會展示累加保險參數的獲取入口。
由以上描述可以看出,本實施例可在支付結果頁面展示累加保險參數的獲取入口,用戶可基於該獲取入口觸發保險參數的更新,透過技術創新實現了保險的投保簡單、便捷,為用戶提供快捷、便利的保險服務推薦,降低用戶操作的繁瑣度,節省用戶的操作時間。
本說明書還提供了電子設備投保的校驗裝置的實施例。
本說明書電子設備投保的校驗裝置的實施例可以應用在電子設備上。裝置實施例可以透過軟體實現,也可以透過硬體或者軟硬體結合的方式實現。以軟體實現為例,作為一個邏輯意義上的裝置,是透過其所在電子設備的處理器將非揮發性記憶體中對應的計算機程式指令讀取到內存記憶體中運行形成的。從硬體層面而言,如圖18所示,為本說明書電子設備投保的校驗裝置所在電子設備的一種硬體結構圖,除了圖18所示的處理器、內存記憶體、網路介面、以及非揮發性記憶體之外,實施例中裝置所在的電子設備通常根據該電子設備的實際功能,還可以包括其他硬體,對此不再贅述。
圖19是本說明書一示例性實施例示出的一種電子設備投保的校驗裝置的框圖。
請參考圖19,所述電子設備投保的校驗裝置1900可以應用在前述圖18所示的電子設備中,該電子設備作為輔助設備,包括有:第一採集單元1901、第二採集單元1902、有效性檢測單元1903和資料確定單元1904。
其中,第一採集單元1901,採集標的設備的投保校驗頁面影像,所述投保校驗頁面中展示有校驗圖形編碼;
第二採集單元1902,基於所述校驗圖形編碼呼叫自身攝像頭採集所述標的設備的設備影像;
有效性檢測單元1903,識別出所述標的設備展示的校驗許可證,並基於所述校驗許可證進行有效性檢測;
資料確定單元1904,在通過有效性檢測後,將所述設備影像確定為所述標的設備的投保校驗資料。
可選的,所述有效性檢測單元1903:
從所述校驗許可證中解析出所述校驗許可證的生成時刻;
獲取投保校驗頁面影像的採集時刻;
判斷所述採集時刻與所述生成時刻之間的時間差是否小於等於第一時長;
若是,則確定通過有效性檢測。
可選的,所述有效性檢測單元1903:
將所述校驗許可證發送給伺服器,以供伺服器解析出所述校驗許可證的生成時刻,並判斷所述生成時刻與所述校驗許可證的發送時刻之間的時間差是否小於等於第二時長;
接收伺服器回傳的通過有效性檢測消息,所述通過有效性檢測消息由伺服器在確定所述時間差小於等於所述第二時長時發送;
所述第二時長大於所述第一時長。
可選的,所述有效性檢測單元1903:
從所述校驗許可證中解析出第一設備標識;
從所述校驗圖形編碼中解析出第二設備標識;
所述基於所述校驗許可證進行有效性檢測包括:
判斷所述第一設備標識和所述第二設備標識是否相同;
若相同,則確定有效性檢測。
可選的,所述有效性檢測單元1903:
採用OCR技術從所述投保校驗頁面影像中識別出所述校驗許可證。
可選的,所述有效性檢測單元1903:
採用OCR技術從所述設備影像中識別出所述校驗許可證。
可選的,第二採集單元1902:
在採集到所述投保校驗頁面影像後,將所述校驗圖形編碼發送給碼平台;
反應於碼平台在解析所述校驗圖形編碼後回傳採集指令,呼叫自身攝像頭採集所述標的設備的設備影像。
圖20是本說明書一示例性實施例示出的另一種電子設備投保的校驗裝置的框圖。
請參考圖20,所述電子設備投保的校驗裝置2000可以應用在前述圖18所示的電子設備中,該電子設備作為標的設備,包括有:生成單元2001、展示單元2002和更新單元2003。
其中,生成單元2001,在觸發電子設備投保的輔助校驗時,生成校驗許可證和校驗圖形編碼;
展示單元2002,展示所述校驗許可證和所述校驗圖形編碼,以供輔助設備基於所述校驗圖形編碼呼叫自身攝像頭採集本設備的設備影像,基於所述校驗許可證進行有效性檢測,並在通過有效性檢測後,將所述設備影像確定為本設備的投保校驗資料。
可選的,所述生成單元2001:
基於當前時刻生成校驗許可證。
可選的,所述生成單元2001:
基於當前時刻和本設備的設備標識生成校驗許可證。
更新單元2003,週期性的更新展示的校驗許可證。
可選的,所述校驗許可證的更新週期小於所述校驗圖形編碼的更新週期。
可選的,所述校驗許可證和所述校驗圖形編碼展示在同一頁面中。
上述裝置中各個單元的功能和作用的實現過程具體詳見上述方法中對應步驟的實現過程,在此不再贅述。
對於裝置實施例而言,由於其基本對應於方法實施例,所以相關之處參見方法實施例的部分說明即可。以上所描述的裝置實施例僅僅是示意性的,其中所述作為分離部件說明的單元可以是或者也可以不是物理上分開的,作為單元顯示的部件可以是或者也可以不是物理單元,即可以位於一個地方,或者也可以分佈到多個網路單元上。可以根據實際的需要選擇其中的部分或者全部模組來實現本說明書方案的目的。本領域普通技術人員在不付出創造性勞動的情況下,即可以理解並實施。
上述實施例闡明的系統、裝置、模組或單元,具體可以由計算機晶片或實體實現,或者由具有某種功能的產品來實現。一種典型的實現設備為計算機,計算機的具體形式可以是個人計算機、膝上型計算機、蜂巢式電話、相機電話、智慧電話、個人數位助理、媒體播放器、導航設備、電子郵件收發設備、遊戲控制台、平板計算機、可穿戴設備或者這些設備中的任意幾種設備的組合。
本說明書還提供一種電子設備投保的校驗裝置,該裝置包括:處理器以及用於儲存機器可執行指令的記憶體。其中,處理器和記憶體通常借由內部匯流排相互連接。在其他可能的實現方式中,所述設備還可能包括外部介面,以能夠與其他設備或者部件進行通信。
在本實施例中,透過讀取並執行所述記憶體儲存的與電子設備投保的校驗邏輯對應的機器可執行指令,所述處理器被促使:
採集標的設備的投保校驗頁面影像,所述投保校驗頁面中展示有校驗圖形編碼;
基於所述校驗圖形編碼呼叫自身攝像頭採集所述標的設備的設備影像;
識別出所述標的設備展示的校驗許可證,並基於所述校驗許可證進行有效性檢測;
在通過有效性檢測後,將所述設備影像確定為所述標的設備的投保校驗資料。
可選的,所述基於所述校驗許可證進行有效性檢測包括:
從所述校驗許可證中解析出所述校驗許可證的生成時刻;
獲取投保校驗頁面影像的採集時刻;
判斷所述採集時刻與所述生成時刻之間的時間差是否小於等於第一時長;
若是,則確定通過有效性檢測。
可選的,所述基於所述校驗許可證進行有效性檢測包括:
將所述校驗許可證發送給伺服器,以供伺服器解析出所述校驗許可證的生成時刻,並判斷所述生成時刻與所述校驗許可證的發送時刻之間的時間差是否小於等於第二時長;
接收伺服器回傳的通過有效性檢測消息,所述通過有效性檢測消息由伺服器在確定所述時間差小於等於所述第二時長時發送;
所述第二時長大於所述第一時長。
可選的,還包括:
從所述校驗許可證中解析出第一設備標識;
從所述校驗圖形編碼中解析出第二設備標識;
所述基於所述校驗許可證進行有效性檢測包括:
判斷所述第一設備標識和所述第二設備標識是否相同;
若相同,則確定有效性檢測。
可選的,所述識別出所述校驗許可證,包括:
採用OCR技術從所述投保校驗頁面影像中識別出所述校驗許可證。
可選的,所述識別出所述校驗許可證,包括:
採用OCR技術從所述設備影像中識別出所述校驗許可證。
可選的,所述基於所述校驗圖形編碼呼叫自身攝像頭採集所述標的設備的設備影像,包括:
在採集到所述投保校驗頁面影像後,將所述校驗圖形編碼發送給碼平台;
反應於碼平台在解析所述校驗圖形編碼後回傳採集指令,呼叫自身攝像頭採集所述標的設備的設備影像。
本說明書還提供一種電子設備投保的校驗裝置,該裝置包括:處理器以及用於儲存機器可執行指令的記憶體。其中,處理器和記憶體通常借由內部匯流排相互連接。在其他可能的實現方式中,所述設備還可能包括外部介面,以能夠與其他設備或者部件進行通信。
在本實施例中,透過讀取並執行所述記憶體儲存的與電子設備投保的校驗邏輯對應的機器可執行指令,所述處理器被促使:
在觸發電子設備投保的輔助校驗時,生成校驗許可證和校驗圖形編碼;
展示所述校驗許可證和所述校驗圖形編碼,以供輔助設備基於所述校驗圖形編碼呼叫自身攝像頭採集本設備的設備影像,基於所述校驗許可證進行有效性檢測,並在通過有效性檢測後,將所述設備影像確定為本設備的投保校驗資料。
可選的,所述生成校驗許可證,包括:
基於當前時刻生成校驗許可證。
可選的,所述生成校驗許可證,包括:
基於當前時刻和本設備的設備標識生成校驗許可證。
可選的,還包括:
週期性的更新展示的校驗許可證。
可選的,所述校驗許可證的更新週期小於所述校驗圖形編碼的更新週期。
可選的,所述校驗許可證和所述校驗圖形編碼展示在同一頁面中。
本說明書還提供一種計算機可讀儲存媒體,所述計算機可讀儲存媒體上儲存有計算機程式,該程式被處理器執行時實現以下步驟:
採集標的設備的投保校驗頁面影像,所述投保校驗頁面中展示有校驗圖形編碼;
基於所述校驗圖形編碼呼叫自身攝像頭採集所述標的設備的設備影像;
識別出所述標的設備展示的校驗許可證,並基於所述校驗許可證進行有效性檢測;
在通過有效性檢測後,將所述設備影像確定為所述標的設備的投保校驗資料。
可選的,所述基於所述校驗許可證進行有效性檢測包括:
從所述校驗許可證中解析出所述校驗許可證的生成時刻;
獲取投保校驗頁面影像的採集時刻;
判斷所述採集時刻與所述生成時刻之間的時間差是否小於等於第一時長;
若是,則確定通過有效性檢測。
可選的,所述基於所述校驗許可證進行有效性檢測包括:
將所述校驗許可證發送給伺服器,以供伺服器解析出所述校驗許可證的生成時刻,並判斷所述生成時刻與所述校驗許可證的發送時刻之間的時間差是否小於等於第二時長;
接收伺服器回傳的通過有效性檢測消息,所述通過有效性檢測消息由伺服器在確定所述時間差小於等於所述第二時長時發送;
所述第二時長大於所述第一時長。
可選的,還包括:
從所述校驗許可證中解析出第一設備標識;
從所述校驗圖形編碼中解析出第二設備標識;
所述基於所述校驗許可證進行有效性檢測包括:
判斷所述第一設備標識和所述第二設備標識是否相同;
若相同,則確定有效性檢測。
可選的,所述識別出所述校驗許可證,包括:
採用OCR技術從所述投保校驗頁面影像中識別出所述校驗許可證。
可選的,所述識別出所述校驗許可證,包括:
採用OCR技術從所述設備影像中識別出所述校驗許可證。
可選的,所述基於所述校驗圖形編碼呼叫自身攝像頭採集所述標的設備的設備影像,包括:
在採集到所述投保校驗頁面影像後,將所述校驗圖形編碼發送給碼平台;
反應於碼平台在解析所述校驗圖形編碼後回傳採集指令,呼叫自身攝像頭採集所述標的設備的設備影像。
本說明書還提供一種計算機可讀儲存媒體,所述計算機可讀儲存媒體上儲存有計算機程式,該程式被處理器執行時實現以下步驟:
在觸發電子設備投保的輔助校驗時,生成校驗許可證和校驗圖形編碼;
展示所述校驗許可證和所述校驗圖形編碼,以供輔助設備基於所述校驗圖形編碼呼叫自身攝像頭採集本設備的設備影像,基於所述校驗許可證進行有效性檢測,並在通過有效性檢測後,將所述設備影像確定為本設備的投保校驗資料。
可選的,所述生成校驗許可證,包括:
基於當前時刻生成校驗許可證。
可選的,所述生成校驗許可證,包括:
基於當前時刻和本設備的設備標識生成校驗許可證。
可選的,還包括:
週期性的更新展示的校驗許可證。
可選的,所述校驗許可證的更新週期小於所述校驗圖形編碼的更新週期。
可選的,所述校驗許可證和所述校驗圖形編碼展示在同一頁面中。
上述對本說明書特定實施例進行了描述。其它實施例在所附申請專利範圍的範圍內。在一些情況下,在申請專利範圍中記載的動作或步驟可以按照不同於實施例中的順序來執行並且仍然可以實現期望的結果。另外,在附圖中描繪的過程不一定要求示出的特定順序或者連續順序才能實現期望的結果。在某些實施方式中,多任務處理和並行處理也是可以的或者可能是有利的。
以上所述僅為本說明書的較佳實施例而已,並不用以限制本說明書,凡在本說明書的精神和原則之內,所做的任何修改、等同替換、改進等,均應包含在本說明書保護的範圍之內。