CN111612637B - 电子设备的保险实现方法和装置 - Google Patents

Abstract

说明书披露一种电子设备的保险实现方法和装置。所述方法包括：在触发电子设备投保的校验数据上传时，展示上传方式列表；响应于用户选择的上传方式，跳转到对应的上传方式指导页面，所述上传方式指导页面中展示有对应的上传入口，以供用户在触发所述上传入口后基于所述上传方式实现本设备校验数据的上传。

Description

电子设备的保险实现方法和装置

技术领域

本说明书涉及互联网技术领域，尤其涉及一种电子设备的保险实现方法和装置。

背景技术

随着互联网技术的快速发展，越来越多的保险业务可通过网络实现，例如，线上投保、线上核保、线上理赔等。如何提升线上保险业务的处理效率、处理准确度已成为亟待解决的问题。

发明内容

有鉴于此，本说明书提供一种电子设备的保险实现方法和装置。

具体地，本说明书是通过如下技术方案实现的：

一种电子设备的保险实现方法，应用于电子设备，所述方法包括：

在触发电子设备投保的校验数据上传时，展示上传方式列表；

响应于用户选择的上传方式，跳转到对应的上传方式指导页面，所述上传方式指导页面中展示有对应的上传入口，以供用户在触发所述上传入口后基于所述上传方式实现本设备校验数据的上传。

一种电子设备的保险实现装置，应用于电子设备，所述装置包括：

列表展示单元，在触发电子设备投保的校验数据上传时，展示上传方式列表；

数据上传单元，响应于用户选择的上传方式，跳转到对应的上传方式指导页面，所述上传方式指导页面中展示有对应的上传入口，以供用户在触发所述上传入口后基于所述上传方式实现本设备校验数据的上传。

一种电子设备的保险实现装置，包括：

处理器；

用于存储机器可执行指令的存储器；

其中，通过读取并执行所述存储器存储的与电子设备的保险逻辑对应的机器可执行指令，所述处理器被促使：

在触发电子设备投保的校验数据上传时，展示上传方式列表；

响应于用户选择的上传方式，跳转到对应的上传方式指导页面，所述上传方式指导页面中展示有对应的上传入口，以供用户在触发所述上传入口后基于所述上传方式实现本设备校验数据的上传。

本说明书一个实施例实现了，提供多种电子设备投保过程中校验数据的上传方式，用户可根据实际情况选择合适的方式上传校验数据，实现校验数据的线上上传，方便、快捷，大大提升了用户的投保体验。

附图说明

图1是本说明书一示例性实施例示出的一种电子设备的保险实现方法的流程示意图。

图2是本说明书一示例性实施例示出的一种标的设备属性的确定方法的流程示意图。

图3是本说明书一示例性实施例示出的另一种标的设备属性的确定方法的流程示意图。

图4是本说明书一示例性实施例示出的一种投保页面的示意图。

图5是本说明书一示例性实施例示出的一种上传校验数据的方法的流程示意图。

图6是本说明书一示例性实施例示出的一种投保方式列表页面示意图。

图7是本说明书一示例性实施例示出的一种上传方式指导页面示意图。

图8是本说明书一示例性实施例示出的一种拍摄倒计时页面示意图。

图9是本说明书一示例性实施例示出的另一种上传方式指导页面示意图。

图10是本说明书一示例性实施例示出的一种电子设备保险理赔的实现方法的流程示意图。

图11是本说明书一示例性实施例示出的一种映射关系建立方法的流程示意图。

图12是本说明书一示例性实施例示出的另一种映射关系建立方法的流程示意图。

图13是本说明书一示例性实施例示出的另一种电子设备保险理赔的实现方法的流程示意图。

图14是本说明书一示例性实施例示出的一种保险参数确定方法的流程示意图。

图15是本说明书一示例性实施例示出的一种用于电子设备的保险实现装置的一结构示意图。

图16是本说明书一示例性实施例示出的一种电子设备的保险实现装置的框图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本说明书相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本说明书的一些方面相一致的装置和方法的例子。

在本说明书使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本说明书。在本说明书和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本说明书可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本说明书范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

本说明书提供一种电子设备的保险实现方案。

上述电子设备的保险可以为电子设备的屏幕保险，也可以为电子设备的全面保障险等电子设备可投保的险种。

上述电子设备可以为手机、平板电脑、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 ForAdvertising，广告标识符)、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：

在触发电子设备投保的校验数据上传时，根据预先设置的上传时段和上传方式之间的映射关系，查找当前时刻对应的上传方式；

在所述上传方式列表中区别展示查找到的所述上传方式。

上述装置中各个单元的功能和作用的实现过程具体详见上述方法中对应步骤的实现过程，在此不再赘述。

对于装置实施例而言，由于其基本对应于方法实施例，所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本说明书方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机，计算机的具体形式可以是个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件收发设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任意几种设备的组合。

与前述电子设备的保险实现方法的实施例相对应，本说明书还提供一种电子设备的保险实现装置，该装置包括：处理器以及用于存储机器可执行指令的存储器。其中，处理器和存储器通常借由内部总线相互连接。在其他可能的实现方式中，所述设备还可能包括外部接口，以能够与其他设备或者部件进行通信。

在本实施例中，通过读取并执行所述存储器存储的与电子设备的保险实现逻辑对应的机器可执行指令，所述处理器被促使：

在触发电子设备投保的校验数据上传时，展示上传方式列表；

响应于用户选择的上传方式，跳转到对应的上传方式指导页面，所述上传方式指导页面中展示有对应的上传入口，以供用户在触发所述上传入口后基于所述上传方式实现本设备校验数据的上传。

可选的，当第一上传方式的上传入口被用户触发时，调用本设备的前置摄像头采集图像，并将采集到的图像作为本设备的校验数据上传至服务器。

可选的，所述调用本设备的前置摄像头采集图像，包括：

在调用本设备的前置摄像头后，启动定时器开始计时；

在到达定时时长时，开始采集图像。

可选的，当第二上传方式的上传入口被用户触发时，生成校验图形编码，以供其他电子设备在扫描所述校验图形编码后调用自身摄像头采集图像，并将采集到的图像作为本设备的校验数据上传至服务器。

可选的，还包括：

在触发电子设备投保的校验数据上传时，根据预先设置的上传时段和上传方式之间的映射关系，查找当前时刻对应的上传方式；

在所述上传方式列表中区别展示查找到的所述上传方式。

可选的，所述上传方式列表中展示有对应上传方式所需的辅助设备。

可选的，所述电子设备投保的保险为电子设备的屏幕保险。

与前述电子设备的保险实现方法的实施例相对应，本说明书还提供一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，该程序被处理器执行时实现以下步骤：

在触发电子设备投保的校验数据上传时，展示上传方式列表；

响应于用户选择的上传方式，跳转到对应的上传方式指导页面，所述上传方式指导页面中展示有对应的上传入口，以供用户在触发所述上传入口后基于所述上传方式实现本设备校验数据的上传。

可选的，当第一上传方式的上传入口被用户触发时，调用本设备的前置摄像头采集图像，并将采集到的图像作为本设备的校验数据上传至服务器。

可选的，所述调用本设备的前置摄像头采集图像，包括：

在调用本设备的前置摄像头后，启动定时器开始计时；

在到达定时时长时，开始采集图像。

可选的，当第二上传方式的上传入口被用户触发时，生成校验图形编码，以供其他电子设备在扫描所述校验图形编码后调用自身摄像头采集图像，并将采集到的图像作为本设备的校验数据上传至服务器。

可选的，还包括：

在触发电子设备投保的校验数据上传时，根据预先设置的上传时段和上传方式之间的映射关系，查找当前时刻对应的上传方式；

在所述上传方式列表中区别展示查找到的所述上传方式。

可选的，所述上传方式列表中展示有对应上传方式所需的辅助设备。

可选的，所述电子设备投保的保险为电子设备的屏幕保险。

上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。

以上所述仅为本说明书的较佳实施例而已，并不用以限制本说明书，凡在本说明书的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本说明书保护的范围之内。

Claims (9)

1.一种电子设备的保险实现方法，应用于电子设备，所述方法包括：

在触发电子设备投保的校验数据上传时，展示上传方式列表；

响应于用户选择的上传方式，跳转到对应的上传方式指导页面，所述上传方式指导页面中展示有对应的上传入口，以供用户在触发所述上传入口后基于所述上传方式实现本设备校验数据的上传；

当第一上传方式的上传入口被用户触发时，调用本设备的前置摄像头采集图像，并将采集到的图像作为本设备的校验数据上传至服务器；

所述调用本设备的前置摄像头采集图像，包括：

在调用本设备的前置摄像头后，启动定时器开始计时；

在到达定时时长时，开始采集图像；

其中，第一上传方式的上传方式指导页面中展示屏幕对着镜子的拍摄要求，以提示用户在触发对应的上传入口后翻转本设备，将本设备屏幕对着镜子。

2.根据权利要求1所述的方法，

当第二上传方式的上传入口被用户触发时，生成校验图形编码，以供其他电子设备在扫描所述校验图形编码后调用自身摄像头采集图像，并将采集到的图像作为本设备的校验数据上传至服务器。

3.根据权利要求1所述的方法，还包括：

在触发电子设备投保的校验数据上传时，根据预先设置的上传时段和上传方式之间的映射关系，查找当前时刻对应的上传方式；

在所述上传方式列表中区别展示查找到的所述上传方式。

4.根据权利要求1所述的方法，所述上传方式列表中展示有对应上传方式所需的辅助设备。

5.根据权利要求1所述的方法，

所述电子设备投保的保险为电子设备的屏幕保险。

6.一种电子设备的保险实现装置，应用于电子设备，所述装置包括：

列表展示单元，在触发电子设备投保的校验数据上传时，展示上传方式列表；

数据上传单元，响应于用户选择的上传方式，跳转到对应的上传方式指导页面，所述上传方式指导页面中展示有对应的上传入口，以供用户在触发所述上传入口后基于所述上传方式实现本设备校验数据的上传；

所述数据上传单元：

当第一上传方式的上传入口被用户触发时，调用本设备的前置摄像头采集图像，并将采集到的图像作为本设备的校验数据上传至服务器；

所述数据上传单元：

在调用本设备的前置摄像头后，启动定时器开始计时；

在到达定时时长时，开始采集图像；

其中，第一上传方式的上传方式指导页面中展示屏幕对着镜子的拍摄要求，以提示用户在触发对应的上传入口后翻转本设备，将本设备屏幕对着镜子。

7.根据权利要求6所述的装置，所述数据上传单元：

当第二上传方式的上传入口被用户触发时，生成校验图形编码，以供其他电子设备在扫描所述校验图形编码后调用自身摄像头采集图像，并将采集到的图像作为本设备的校验数据上传至服务器。

8.根据权利要求6所述的装置，所述列表展示单元：

在触发电子设备投保的校验数据上传时，根据预先设置的上传时段和上传方式之间的映射关系，查找当前时刻对应的上传方式；

在所述上传方式列表中区别展示查找到的所述上传方式。

9.一种电子设备的保险实现装置，包括：

处理器；

用于存储机器可执行指令的存储器；

其中，通过读取并执行所述存储器存储的与电子设备的保险逻辑对应的机器可执行指令，所述处理器被促使：

在触发电子设备投保的校验数据上传时，展示上传方式列表；

响应于用户选择的上传方式，跳转到对应的上传方式指导页面，所述上传方式指导页面中展示有对应的上传入口，以供用户在触发所述上传入口后基于所述上传方式实现本设备校验数据的上传；

当第一上传方式的上传入口被用户触发时，调用本设备的前置摄像头采集图像，并将采集到的图像作为本设备的校验数据上传至服务器；

所述调用本设备的前置摄像头采集图像，包括：

在调用本设备的前置摄像头后，启动定时器开始计时；

在到达定时时长时，开始采集图像；

其中，第一上传方式的上传方式指导页面中展示屏幕对着镜子的拍摄要求，以提示用户在触发对应的上传入口后翻转本设备，将本设备屏幕对着镜子。

Images