CN112132692A - 保单数据处理方法及装置、存储介质及电子设备 - Google Patents

Abstract

本公开提供了一种保单数据处理方法及装置、存储介质及电子设备。该保单数据处理方法包括：接收客户端发送的待处理保单的保额递增请求；对待处理保单的保额递增请求进行核保处理，确定待处理保单递增后的保额及递减后的剩余保险期间；当核保处理成功时，通知核心系统更新待处理保单的保额为递增后的保额及更新待处理保单的剩余保险期间为递减后的剩余保险期间，并通知客户端保额递增成功；其中，在待处理保单的总保险期间内，待处理保单的保费被周期地缴纳；保额递增期次基于总保险期间与缴纳保费的周期确定；保额随着保额递增期次的增加而递增，剩余保险期间随着保额递增期次的增加而递减。

Description

保单数据处理方法及装置、存储介质及电子设备

技术领域

本公开涉及保险技术领域，尤其涉及一种保单数据处理方法及装置、存储介质及电子设备。

背景技术

随着移动互联网的不断发展，互联网保险产品形态也日益增多，但缴费方式却相对比较固定，没有随之变化，如仍采用一年或一个月等较长的缴费周期，不利于保险用户的体验。

设计相应丰富的缴费方式将有利于提升用户体验，增加保险用户的用户粘合度。然而缴费方式的变化将导致相关技术中对保险数据处理的方法也需要随之改变，否则将导致错误的保险数据处理结果。

需要说明的是，在上述背景技术部分公开的信息仅用于加强对本公开的背景的理解，因此可以包括不构成对本领域普通技术人员已知的现有技术的信息。

发明内容

本公开的目的在于提供一种保单数据处理方法及装置、存储介质及电子设备。

本公开的其他特性和优点将通过下面的详细描述变得显然，或部分地通过本公开的实践而习得。

根据本公开的一个方面，提供一种保单数据处理方法，包括：接收客户端发送的待处理保单的保额递增请求；对待处理保单的保额递增请求进行核保处理，确定待处理保单递增后的保额及递减后的剩余保险期间；当核保处理成功时，通知核心系统更新待处理保单的保额为递增后的保额及更新待处理保单的剩余保险期间为递减后的剩余保险期间，并通知客户端保额递增成功；其中，在待处理保单的总保险期间内，待处理保单的保费被周期地缴纳；保额递增期次基于总保险期间与缴纳保费的周期确定；保额随着保额递增期次的增加而递增，剩余保险期间随着保额递增期次的增加而递减。

根据本公开的一实施方式，保额递增请求包括：当前保额和/或请求递增后的保额；对待处理保单的保额递增请求进行核保处理包括：核对当前保额与记录的当前保额是否一致；和/或，核对请求递增后的保额与确定出的递增后的保额是否一致；当当前保额与记录的当前保额一致，和/或请求递增后的保额与确定出的递增后的保额一致时，确定核保处理成功；当当前保额与记录的当前保额不一致，和/或请求递增后的保额与确定出的递增后的保额不一致时，确定核保处理失败。

根据本公开的一实施方式，对待处理保单的保额递增请求进行核保处理包括：向理赔服务系统发送待处理保单的理赔查询请求；当理赔服务系统返回的待处理保单的理赔查询结果中不包含待处理保单的立案记录信息时，确定核保处理成功；当理赔服务系统返回的待处理保单的理赔查询结果中包含待处理保单的立案记录信息时，确定核保处理失败。

根据本公开的一实施方式，对待处理保单的保额递增请求进行核保处理还包括：判断当前距离上一次接收到待处理保单的保额递增请求的时间是否大于预设时长；当当前距离上一次接收到待处理保单的保额递增请求的时间不大于预设时长时，确定核保处理成功；当当前距离上一次接收到待处理保单的保额递增请求的时间大于预设时长时，确定核保处理失败；其中，预设时长是根据缴纳保费的周期确定的。

根据本公开的一实施方式，方法还包括：当核保处理失败时，通知客户端核保失败，且退还对应保额递增请求的保额递增期次已缴纳的保费。

根据本公开的一实施方式，保额随着保额递增期次的增加而指数递增，剩余保险期间随着保额递增期次的增加而线性递减。

根据本公开的一实施方式，方法还包括：在接收到客户端发送的待处理保单的保额递增请求后，向客户端返回数据接收成功消息，并将接收到的保额递增请求存储在消息队列中；异步地从消息队列中取出保额递增请求，以对保额递增请求进行核保处理。

根据本公开的一实施方式，保额递增请求在请求的保额递增期次对应的应缴保费缴纳完毕后生成。

根据本公开的又一方面，提供一种保单数据处理方法，包括：当检测到待处理保单当前期次应缴保费缴纳完毕时，向服务器系统发送待处理保单的保额递增请求；当接收到服务器系统发送的待处理保单的保额递增成功消息时，从保额递增成功消息中获取待处理保单的递增后的保额，并在用户显示界面中显示待处理保单的递增后的保额；其中，在待处理保单的总保险期间内，待处理保单的保费被周期地缴纳；对应保额递增请求的保额递增期次基于总保险期间与缴纳保费的周期确定；保额随着保额递增期次的增加而递增。

根据本公开的一实施方式，保额随着保额递增期次的增加而指数递增。

根据本公开的一实施方式，方法还包括：当接收到待处理保单的保额递增成功消息时，从保额递增成功消息中获取待处理保单的剩余保险期间，并在用户显示界面中显示待处理保单的剩余保险期间；其中，剩余保险期间随着保额递增期次的增加而递减。

根据本公开的一实施方式，剩余保险期间随着保额递增期次的增加而线性递减。

根据本公开的一实施方式，在检测待处理保单当前期次应缴保费是否缴纳完毕之前，方法还包括：当检测到用户输入的待处理保单的缴费请求时，在用户显示界面中显示待处理保单的保费缴费界面；当检测到用户在保费缴费界面输入的保费缴费指示时，发起待处理保单的保费缴纳流程。

根据本公开的再一方面，提供一种保单数据处理装置，包括：请求接收模块，用于接收客户端发送的待处理保单的保额递增请求；请求处理模块，用于对待处理保单的保额递增请求进行核保处理，确定待处理保单递增后的保额及递减后的剩余保险期间；结果通知模块，用于当核保处理成功时，通知核心系统更新待处理保单的保额为递增后的保额及更新待处理保单的剩余保险期间为递减后的剩余保险期间，并通知客户端保额递增成功；其中，在待处理保单的总保险期间内，待处理保单的保费被周期地缴纳；保额递增期次基于总保险期间与缴纳保费的周期确定；保额随着保额递增期次的增加而递增，剩余保险期间随着保额递增期次的增加而递减。

根据本公开的再一方面，提供一种保单数据处理装置，包括：请求发送模块，用于当检测到待处理保单当前期次应缴保费缴纳完毕时，向服务器系统发送待处理保单的保额递增请求；消息处理模块，用于当接收到服务器系统发送的待处理保单的保额递增成功消息时，从保额递增成功消息中获取待处理保单的递增后的保额，并在用户显示界面中显示待处理保单的递增后的保额；其中，在待处理保单的总保险期间内，待处理保单的保费被周期地缴纳；保额递增期次基于总保险期间与缴纳保费的周期确定；保额随着保额递增期次的增加而递增。

根据本公开的再一方面，提供一种电子设备，包括：处理器；以及存储器，用于存储处理器的可执行指令；其中，处理器配置为经由执行可执行指令来执行上述任意一种保单处理方法。

根据本公开的再一方面，提供一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现上述任意一种保单处理方法。

根据本公开实施例提供的保单数据处理方法、装置、电子设备及存储介质，提供了一种对周期缴费且保额随着已经过保险期间增加而增加的保险产品的保单数据进行处理的方法，基于客户端发送的保额递增请求，根据当前期次等信息，确定递增后的保额和剩余的保险期间，并对该保额递增请求进行核保处理，避免了相关技术中使用的核保逻辑无法适用于该保险产品，导致核保结果错误等问题。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理。显而易见地，下面描述中的附图仅仅是本公开的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是根据一示例性实施例示出的本公开实施例提供的保单数据处理方法应用场景的系统架构示意图。

图2是根据一示例性实施例示出的本公开实施例提供的保单数据处理方法应用场景的交互流程图。

图3A是根据一示例示出的保额随保额递增期次增多而不断增加的示意图。

图3B是根据一示例示出的剩余保险期间随保额递增期次增多而不断减少的示意图。

图4是根据一示例性实施例示出的一种保单数据处理方法的流程图。

图5是根据一示例性实施例示出的另一种保单数据处理方法的流程图。

图6是根据一示例性实施例示出的再一种保单数据处理方法的流程图。

图7是根据一示例性实施例示出的再一种保单数据处理方法的流程图。

图8是根据一示例性实施例示出的再一种保单数据处理方法的流程图。

图9是根据一示例性实施例示出的再一种保单数据处理方法的流程图。

图10是根据一示例性实施例示出的再一种保单数据处理方法的流程图。

图11是根据一示例性实施例示出的再一种保单数据处理方法的流程图。

图12是根据一示例性实施例示出的一种保单数据处理装置的示意图。

图13是根据一示例性实施例示出的另一种保单数据处理装置的示意图。

图14是根据一示例性实施例示出的再一种保单数据处理装置的示意图。

图15是根据一示例性实施例示出的一种计算机设备的结构框图。

图16是根据一示例性实施例示出的一种可读存储介质的示意图。

图17A为根据一示例示出的保额递增请求界面示意图。

图17B是根据一示例示出的一个保额递增结果展示界面的示意图。

图17C是根据一示例示出的另一个保额递增结果展示界面的示意图。

图17D是根据一示例示出的再一个保额递增结果展示界面的示意图。

具体实施方式

现在将参考附图更全面地描述示例实施方式。然而，示例实施方式能够以多种形式实施，且不应被理解为限于在此阐述的范例；相反，提供这些实施方式使得本公开将更加全面和完整，并将示例实施方式的构思全面地传达给本领域的技术人员。所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施方式中。

此外，附图仅为本公开的示意性图解，并非一定是按比例绘制。图中相同的附图标记表示相同或类似的部分，因而将省略对它们的重复描述。附图中所示的一些方框图是功能实体，不一定必须与物理或逻辑上独立的实体相对应。可以采用软件形式来实现这些功能实体，或在一个或多个硬件模块或集成电路中实现这些功能实体，或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。

此外，在本公开的描述中，“多个”的含义是至少两个，例如两个，三个等，除非另有明确具体的限定。“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如A和/或B，可以表示单独存在A、单独存在B及同时存在A和B三种情况。

如前述，随着互联网保险产品形态的日益丰富，设计相应丰富的缴费方式将有利于提升用户体验，增加保险用户的用户粘合度。

然而缴费方式的变化将导致相关技术中对保险数据处理的方法也需要随之改变，否则将导致错误的保险数据处理结果。

图1是根据一示例性实施例示出的本公开实施例提供的保单数据处理方法应用场景的系统架构示意图。

如图1所示，在所述应用场景中将涉及如下设备：终端11、服务器系统12、理赔服务系统13及核心系统14。

终端11可以是手机、平板电脑、掌上电脑、可穿戴设备、虚拟现实(VirtualReality，VR)设备、增强现实(Augmented Reality，AR)设备、等移动终端，或者，终端11也可以是个人计算机(Personal Computer，PC)，比如膝上型便携计算机或台式计算机等等。

不同的承保渠道，对应使用的终端11的类型也不同。例如，承保的入口渠道有银行柜面、移动智能设备(包括APP、微信等)、网站等，则相应使用的终端11的类型也会不同。

终端11中可以安装有用于提供保险服务的客户端应用程序。可选地，不同的终端11中安装的客户端应用程序可以是相同的，也可以是不同控制系统平台的同一类型客户端应用程序。基于终端平台的不同，该客户端应用程序的具体形态也可以不同，比如，该客户端应用程序可以是手机客户端、微信小程序、快应用客户端、PC客户端或者全球广域网(World Wide Web，Web)客户端等。

本领域技术人员可以知晓，上述终端11的数量可以更多或更少。比如上述终端可以仅为一个，或者上述终端为几十个或几百个，或者更多数量。本公开实施例对终端的数量和设备类型不加以限定。

终端11与服务器系统12之间通过通信网络相连。可选的，通信网络是有线网络或无线网络。

可选的，通信网络是有线网络或无线网络。

可选的，上述的无线网络或有线网络使用标准通信技术和/或协议。网络通常为因特网、但也可以是任何网络，包括但不限于局域网(Local Area Network，LAN)、城域网(Metropolitan Area Network，MAN)、广域网(Wide Area Network，WAN)、移动、有线或者无线网络、专用网络或者虚拟专用网络的任何组合)。在一些实施例中，使用包括超文本标记语言(Hyper Text Mark-up Language，HTML)、可扩展标记语言(ExtensibleMarkupLanguage，XML)等的技术和/或格式来代表通过网络交换的数据。此外还可以使用诸如安全套接字层(Secure Socket Layer，SSL)、传输层安全(Transport Layer Security，TLS)、虚拟专用网络(Virtual Private Network，VPN)、网际协议安全(InternetProtocolSecurity，IPsec)等常规加密技术来加密所有或者一些链路。在另一些实施例中，还可以使用定制和/或专用数据通信技术取代或者补充上述数据通信技术。

服务器系统12是一台服务器，或者由若干台服务器组成，或者是一个虚拟化平台，或者是一个云计算服务中心。服务器系统12用于为提供保险服务的客户端应用程序提供后台服务。可选地，服务器系统12承担主要计算工作，终端11承担次要计算工作；或者，服务器系统12承担次要计算工作，终端11承担主要计算工作；或者，终端11和服务器系统12之间采用分布式计算架构进行协同计算。

服务器系统12通过与终端11通信，接收终端11生成的缴费请求，并将对缴费请求的处理结果返回给终端11。

此外，服务器系统12还可以分别与理赔服务系统13及核心系统14通信，以基于与理赔服务系统13及核心系统14的交互，确定对该缴费请求的处理结果。

图2是根据一示例性实施例示出的本公开实施例提供的保单数据处理方法应用场景的交互流程图。

在说明图2所示的交互流程20之前，首先说明本公开实施例提供的保单数据处理方法中所基于的一种全新的保费缴纳方式。

在本公开实施例中，首先定义了一种短周期的缴费方式，通过缩短缴费周期，降低每次缴费的金额，使得用户无需一次支取大额的保费。相应地，还可以随着缴费期数的增加及剩余保险期间的减少，提高用户的保额，从而提升用户的体验。

以一年期保险产品且缴费周期为一周为例，一张保单的缴费方式为每周缴费预定金额，例如可以为1元钱。从首次缴费一周后开始，划分出51个保额递增期次，随着保额递增期次增多，该保单对应的保额不断地增加，而对应的剩余保险期间则相应地减少。

图3A是根据一示例示出的保额随保额递增期次增多而不断增加的示意图。图3B是根据一示例示出的剩余保险期间随保额递增期次增多而不断减少的示意图。

如图3A和图3B所示，保额例如可以随着保额递增期次增多而呈指数增长，而保险期间随保额递增期次增多而线性递减。需要说明的是，保额的指数增长仅为一种示例，而非限制本公开，例如保额也可以随着保额递增期次增多而线性递增等。

该保险产品的险类例如归属为短期健康保险，险种为重大疾病保险。该保险产品从产品生效后的第二周开始，每周缴纳保费后增加对应的保额。若未按照约定缴纳本期的保险费，合同仍然有效，但不增加对应的保额。若连续四周以上期数未按照约定交纳保险费，则该产品不再增加保额。

用户需要输入或提供的投保人信息如包括：姓名、证件类型、证件号码、性别、出生日期等。被保险人信息如包括：与投保人的关系、姓名、证件类型、证件号码、性别、出生日期、灰名单/白名单。每次缴费的信息如可以包括：保单号、缴费期次、应缴保费、实收保费、实收保费支付流水号、支付时间等。

联合参考图1和图2，该交互流程20如下：

在步骤S201中，用户通过操作终端11中的客户端，使客户端生成待处理保单的保额递增请求，并向服务器系统12发送该保额递增请求。

该保额递增请求中例如可以包含请求的期次信息、对应该期次应缴的保费金额。

此外，当终端11为诸如银行、保险代理人等渠道终端时，保额递增请求还可以包含：当前保额和/或请求递增后的保额。

图17A为根据一示例示出的保额递增请求界面示意图。如图17A所示，用户例如可以通过点击“保额递增”按钮来请求发起保额递增请求流程。此外，在该界面中，如还可以显示当前的期次信息等。

在一些实施例中，该保额递增请求例如也可以为用户在成功缴纳本期次应缴保费后，直接通过客户端生成。

在步骤S202中，服务器系统12接收到该保额递增请求后，首先向终端11返回接收数据成功的消息。

在步骤S203中，服务器系统12开始对该保额递增请求进行核保处理。

以终端11为渠道终端为例，如上述，保额递增请求中还可以包含当前保额和/或请求递增后的保额。服务器系统12可以核对保额递增请求中携带的当前保额与系统中记录的当前保额是否一致，和/或核对保额递增请求中携带的递增后的新保额与服务器系统12计算出的新保额是否一致。

服务器系统12依据保额递增期次计算该待处理保单的剩余保险期间，根据险别费率及保额递增期次等信息计算出递增后的新保额。

例如，服务器系统12可以通过下述公式来计算新的保额：

递增后的新保额＝本期次保费/险别费率/(本期次对应的已经过的保险期间天数/总保险期间天数)。

其中，险别费率例如可以通过被保人的年龄、性别、保额递增期次等因素确定。例如可以被配置在险别费率表中，在使用时供查询。

以女性为例，表1为根据一示例示出的险别费率表，但本公开不以此为限。

表1

此外，服务器系统12还可以核对保额递增请求中携带的期次信息、对应该期次应缴的保费等信息是否正确。

此外，如果服务器系统12检测到当前并非保额递增请求的时间(以缴费周期为一周为例，假设可以设定每周日为保额递增请求的时间)，用户提前进行了下一期次保额递增请求，服务器系统12也会认定信息核对失败。

此外，服务器系统12还可以判断当前距离上一次接收到该待处理保单的保额递增请求的时间是否大于预设时长。该预设时长如可以根据保费的缴纳周期确定。以保费缴纳周期为一周为例，该预设时长例如可以被设置为三周，但本公开不以此为限。如果服务器系统12判断当前距离上一次接收到该待处理保单的保额递增请求的时间大于了该预设时长，则也会认定信息核对识别，也即核保失败。例如，如果用户在第1周和第2周均对保单A进行了缴费，并相应地，通过客户端发送了保额递增请求；但中间的第3周和第4周，该用户均未缴费。当其第5周又继续缴费并通过客户端发送了保额递增请求时，服务器系统12会对两次收到保额递增请求的间隔时间进行判断，由于两次间隔期间未大于预设的三周，则认定核保成功。而如果该用户在第3周-第5周均未缴费，而是在第6周又继续缴费时，因为间隔时间大于了6周，则会认定核保失败。通过设置该预设时长的限制，可以增加用户与保险公司之间的粘性，提高用户的活跃度。

如果信息核对失败，则在步骤S204中，服务器系统12向终端11返回核保失败信息，并退还用户本期次对应缴纳的保费。

例如，如果用户缴纳的保费是从用户的银行卡里扣款，则将保费退还到扣款银行卡。如果用户缴纳的保费是从诸如微信余额等其他账户扣款，则将保费退还到该扣款账户中。

如果信息核对无误，则在步骤S205中，服务器系统12还向理赔服务系统13发送该待处理保单的理赔查询请求。

在步骤S206中，理赔服务系统13对该待处理保单的理赔情况进行查询。

在步骤S207中，理赔服务系统13将查询结果返回给服务器系统12。

如果服务器系统12分析理赔服务系统13返回的查询结果发现该待处理保单中包含立案记录等信息，则在步骤S208中，服务器系统12向终端11返回核保失败信息，并退还用户本期次对应缴纳的保费。

如果服务器系统12分析理赔服务系统13返回的查询结果没有发现该待处理保单中包含立案记录等信息，则在步骤S209中，服务器系统12向核心系统14发送该待处理保单本期次的保额核算信息，如本期次信息、递增后的新保额、剩余保险期间等。

在步骤S210中，核心系统14在接收到该待处理保单本期次的保额核算信息后，对其记录的该待处理保单的保额进行修改并重新记录，之后在步骤S211中，将保额修改结果返回给服务器系统12。

在步骤S212中，服务器系统12向终端11发送新保额核保结果。

终端11在接收到服务器12返回的新保额核保结果后，通过客户端界面向用户显示递增后的保额，此外还可以显示当前的期次信息等。

图17B～图17D分别是根据一示例示出的保额递增结果展示界面的示意图。如图17B～图17D所示，终端11通过用户界面向用户显示递增后的保额及当前期次信息。例如，15期次递增后的保额为1220元，33期次递增后的保额为2311元，最后一个期次(即52期次)的保额为40736元。

由上述保单数据处理方法应用场景的交互流程中可以看到，缴费方式的变化将导致系统中各设备对保单数据处理方法的改变，如需要通过几个设备间的交互，传递数据处理所需要的数据信息，并相应地需要改变设备中原有数据处理逻辑，否则将导致错误的保险数据处理结果。

下面，将结合附图及实施例对本公开示例实施例中的保单数据处理方法的各个步骤进行更详细的说明。

图4是根据一示例性实施例示出的一种保单数据处理方法的流程图。

本公开实施例提供的方法可以由任意具备计算处理能力的电子设备执行，例如如图1中的服务器系统12。在下面的举例说明中，以服务器系统12为执行主体进行示例说明。

如图4所示，保单数据处理方法40包括：

在步骤S401中，接收客户端发送的待处理保单的保额递增请求。

在待处理保单的总保险期间内，待处理保单的保费被周期地缴纳。保额递增期次基于该总保险期间与缴纳保费的周期确定。

以上述的一年期保险产品且缴费周期为一周为例，一张保单的缴费方式为每周缴费预定金额，例如可以为1元钱。总保险期间为一年，从首次缴费一周后开始，划分出51个保额递增期次，随着保额递增期次增多，该保单对应的保额不断地增加，而对应的剩余保险期间则相应地减少。

该保额递增请求中例如可以包括：请求的保额递增期次、对应该期次应缴的保费金额。

此外，如上述当客户端为渠道终端中安装的客户端时，保额递增请求中还可以包括：当前保额和/或请求递增后的保额。

该保额递增请求例如可以为用户在成功缴纳请求的保额递增期次应缴保费后，通过客户端生成。

以用户通过操作图1中所示的终端11中的客户端来缴纳保费为例，用户通过操作客户端提供的用户界面，缴纳待处理保单本期次应缴保费。缴费成功后，客户端通过用户界面向用户显示缴费成功。同时，客户端无需用户的操作，自动地直接向图1中所示的服务器系统12发送该处理保单的保额递增请求，请求服务器系统12更新该待处理保单的保额。或者，在显示缴费成功后，也可以由用户通过操作用户界面，手动通过客户端向图1中所示的服务器系统12发送该处理保单的保额递增请求，请求服务器系统12更新该待处理保单的保额。

在步骤S402中，对待处理保单的保额递增请求进行核保处理，确定待处理保单递增后的保额及递减后的剩余保险期间。

该待处理保单的保额随着保额递增期次的增加而递增，剩余保险期间随着保额递增期次的增加而递减。

在一些实施例中，分别如图3A和图3B所示，该待处理保单的保额随着保额递增期次的增加而指数递增，剩余保险期间随着保额递增期次的增加而指数递减。

在一些实施例中，递增后的保额基于下述公式计算：

递增后的新保额＝本期次保费/险别费率/(本期次对应的已经过的保险期间天数/总保险期间天数)；

其中，险别费率例如可以通过被保人的年龄、性别、保额递增期次等因素确定。例如可以被配置在险别费率表中，在使用时供查询。

递减后的剩余保险期间可以直接根据总保险期间天数减去已经过的保险期间天数确定。仍以上述一年期保险产品为例，第1期次为首次缴纳保费后的第7天起算，则对应第1期次的剩余保险期间为365天减去7天，为358天。

在步骤S403中，当所述核保处理成功时，通知核心系统更新该待处理保单的保额为该递增后的保额及更新该待处理保单的剩余保险期间为该递减后的剩余保险期间，并通知客户端保额递增成功。

核保处理成功后，通知核心系统，请求核心系统更改其记录的该待处理保单的保额及剩余保险期间。此外，通知客户端保额递增成功，其中例如还可以包含上述确定的递增后的保额、递减后的剩余保险期间，从而使得客户端可以通过用户界面显示该递增后的保额、递减后的剩余保险期间。

根据本公开实施例提供的保单数据处理方法，提供了一种对周期缴费且保额随着已经过保险期间增加而增加的保险产品的保单数据进行处理的方法，基于客户端发送的保额递增请求，根据当前期次等信息，确定递增后的保额和剩余的保险期间，并对该保额递增请求进行核保处理，避免了相关技术中使用的核保逻辑无法适用于该保险产品，导致核保结果错误等问题。

图5是根据一示例性实施例示出的另一种保单数据处理方法的流程图。与图4所示的保单数据处理方法40不同的是，图5所示的保单数据处理方法进一步提供了上述步骤S402的一种实施例，进一步说明如何对待处理保单的保额递增请求进行核保处理。在该实施例中，以客户端为渠道终端中安装的客户端为例，保额递增请求中可以包含：当前保额和/或请求递增后的保额。

参考图5，步骤S402包括：

在步骤S4021中，核对当前保额与记录的当前保额是否一致；和/或，核对请求递增后的保额与确定出的递增后的保额是否一致。

在步骤S4022中，当当前保额与记录的当前保额一致，和/或请求递增后的保额与确定出的递增后的保额一致时，确定核保处理成功。

在步骤S4023中，当当前保额与记录的当前保额不一致，和/或请求递增后的保额与确定出的递增后的保额不一致时，确定核保处理失败。

此外，在一些实施例中，还可以核对保额递增请求中携带的期次信息、对应该期次应缴的保费等信息是否正确。如果不正确，则确定核保处理失败。

此外，在一些实施例中，还可以检测当前是否为保额递增请求的应提交时间(以缴费周期为一周为例，假设可以设定每周日为保额递增请求的应提交时间)，如果用户通过客户端提前进行了下一期次保额递增请求，使得当前并非为本期次对应的保额递增请求的应提交时间，则确定该核保处理失败。

图6是根据一示例性实施例示出的再一种保单数据处理方法的流程图。与图4所示的保单数据处理方法40不同的是，图6所示的保单数据处理方法进一步提供了上述步骤S402的另一种实施例，进一步说明如何对待处理保单的保额递增请求进行核保处理。

参考图6，步骤S402还可以包括：

在步骤S4024中，判断当前距离上一次接收到待处理保单的保额递增请求的时间是否大于预设时长。

在步骤S4025中，当当前距离上一次接收到待处理保单的保额递增请求的时间不大于预设时长时，确定核保处理成功。

在步骤S4026中，当当前距离上一次接收到待处理保单的保额递增请求的时间大于预设时长时，确定核保处理失败。

其中，预设时长是根据缴纳保费的周期确定的。

以保费缴纳周期为一周为例，该预设时长例如可以被设置为三周，但本公开不以此为限。如果服务器系统12判断当前距离上一次接收到该待处理保单的保额递增请求的时间大于了该预设时长，则也会认定信息核对识别，也即核保失败。例如，如果用户在第1周和第2周均对保单A进行了缴费，并相应地，通过客户端发送了保额递增请求；但中间的第3周和第4周，该用户均未缴费。当其第5周又继续缴费并通过客户端发送了保额递增请求时，服务器系统12会对两次收到保额递增请求的间隔时间进行判断，由于两次间隔期间未大于预设的三周，则认定核保成功。而如果该用户在第3周-第5周均未缴费，而是在第6周又继续缴费时，因为间隔时间大于了6周，则会认定核保失败。通过设置该预设时长的限制，可以增加用户与保险公司之间的粘性，提高用户的活跃度。

图7是根据一示例性实施例示出的再一种保单数据处理方法的流程图。与图4所示的保单数据处理方法40不同的是，图7所示的保单数据处理方法进一步提供了上述步骤S402的再一种实施例，进一步说明如何对待处理保单的保额递增请求进行核保处理。

参考图7，步骤S402还可以包括：

在步骤S4027中，向理赔服务系统发送待处理保单的理赔查询请求。

在步骤S4028中，当理赔服务系统返回的待处理保单的理赔查询结果中不包含待处理保单的立案记录信息时，确定核保处理成功。

在步骤S4029中，当理赔服务系统返回的待处理保单的理赔查询结果中包含待处理保单的立案记录信息时，确定核保处理失败。

对于包含了立案记录的待处理保单，本次核保处理失败，退还本期次的已缴纳保费。如果之后立案成功，则该保单终止；而如果立案失败，则该保单有效，可以继续缴费并请求递增保额。

图8是根据一示例性实施例示出的再一种保单数据处理方法的流程图。与图4所示的保单数据处理方法40不同的是，图8所示的保单数据处理方法80还进一步包含：

在步骤S801中，当核保处理失败时，通知客户端核保失败，且退还对应该请求的保额递增期次已缴纳的保费。

例如，如果用户缴纳的保费是从用户的银行卡里扣款，则将保费退还到扣款银行卡。如果用户缴纳的保费是从诸如微信余额等其他账户扣款，则将保费退还到该扣款账户中。

图9是根据一示例性实施例示出的再一种保单数据处理方法的流程图。与图4所示的保单数据处理方法40不同的是，图9所示的保单数据处理方法90在接收到客户端发送的待处理保单的保额递增请求后，还包括步骤S901和S902。

参考图9，保单数据处理方法90包括：

在步骤S401中，接收客户端发送的待处理保单的保额递增请求。

在步骤S901中，向客户端返回数据接收成功消息，并将接收到的保额递增请求存储在消息队列(MQ)中。

在将接收到的保额递增请求存储在消息队列中之前，还可以对接收到的保额递增请求进行幂等校验，以及对相同保单、相同期次的请求进行去重处理，仅将未处理过的请求加入到MQ中；而对于相同保单且相同期次处理过的请求，直接返回成功消息。

此外，在一些实施例中，也可以将接收到的保额递增请求存储在CMQ(CloudMessage Queue，云消息队列)中。当对保额递增请求处理失败时，CMQ队列会自动对其中存储的保额递增请求进行重试及监控查看。

在步骤S902中，异步地从消息队列中取出所述保额递增请求。

在步骤S402中，对待处理保单的保额递增请求进行核保处理，确定待处理保单递增后的保额及递减后的剩余保险期间。

在步骤S403中，当所述核保处理成功时，通知核心系统更新该待处理保单的保额为该递增后的保额及更新该待处理保单的剩余保险期间为该递减后的剩余保险期间，并通知客户端保额递增成功。

在步骤S801中，当核保处理失败时，通知客户端核保失败，且退还对应该请求的保额递增期次已缴纳的保费。

根据本公开实施例提供的保单数据处理方法，在接收到保额递增请求后，立即向终端返回数据接收成功消息，可以提高对各渠道接口的响应的时效性，提升用户体验。而将该保额递增请求存储在消息队列中，则可以异步地对其进行处理，避免了当大量客户端同时提交请求时，高并发业务对系统服务器的冲击。

图10是根据一示例性实施例示出的再一种保单数据处理方法的流程图。

本公开实施例提供的方法可以由任意具备计算处理能力的电子设备执行，例如如图1中的终端11。在下面的举例说明中，以终端11为执行主体进行示例说明。

如图10所示，保单数据处理方法100包括：

在步骤S1001中，当检测到待处理保单当前期次应缴保费缴纳完毕时，向服务器系统发送待处理保单的保额递增请求。

在步骤S1002中，当接收到服务器系统发送的待处理保单的保额递增成功消息时，从保额递增成功消息中获取待处理保单的递增后的保额，并在用户显示界面中显示待处理保单的递增后的保额。

其中，在待处理保单的总保险期间内，待处理保单的保费被周期地缴纳；对应保额递增请求的保额递增期次基于总保险期间与缴纳保费的周期确定；保额随着保额递增期次的增加而递增。

在一些实施例中，保额随着保额递增期次的增加而指数递增。

在一些实施例中，保单数据处理方法100还包括：当接收到待处理保单的保额递增成功消息时，从保额递增成功消息中获取待处理保单的剩余保险期间，并在用户显示界面中显示待处理保单的剩余保险期间；其中，剩余保险期间随着保额递增期次的增加而递减。

在一些实施例中，剩余保险期间随着保额递增期次的增加而线性递减。

根据本公开实施例提供的保单数据处理方法，提供了一种对周期缴费且保额随着已经过保险期间增加而增加的保险产品的保单数据进行处理的方法，基于客户端发送的保额递增请求，接收递增后的保额和剩余的保险期间，其中递增后的保额和剩余的保险期间是根据当前期次等信息确定的，避免了相关技术中使用的核保逻辑无法适用于该保险产品，导致核保结果错误等问题。

图11是根据一示例性实施例示出的再一种保单数据处理方法的流程图。与图10所示的保单数据处理方法100不同的是，图11所示的保单数据处理方法110在步骤S1001之前还包括：

在步骤S1101中，当检测到用户输入的待处理保单的缴费请求时，在用户显示界面中显示待处理保单的保费缴费界面。

在步骤S1102中，当检测到用户在保费缴费界面输入的保费缴费指示时，发起待处理保单的保费缴纳流程。

需要注意的是，上述附图仅是根据本公开示例性实施例的方法所包括的处理的示意性说明，而不是限制目的。易于理解，上述附图所示的处理并不表明或限制这些处理的时间顺序。另外，也易于理解，这些处理可以是例如在多个模块中同步或异步执行的。

下述为本公开装置实施例，可以用于执行本公开方法实施例。对于本公开装置实施例中未披露的细节，请参照本公开方法实施例。

图12是根据一示例性实施例示出的一种保单数据处理装置的示意图。本公开实施例提供的保单数据处理装置可以应用于任意具备计算处理能力的电子设备执行，例如如图1中的服务器系统12。

参考图12，保单数据处理装置120包括：请求接收模块1201、请求处理模块1202及结果通知模块1203。

其中，请求接收模块1201用于接收客户端发送的待处理保单的保额递增请求。

保额递增请求中例如可以包括：请求的保额递增期次、对应请求的保额递增期次已缴纳的保费、当前保额和/或请求递增后的保额。

请求处理模块1202用于对待处理保单的保额递增请求进行核保处理，确定待处理保单递增后的保额及递减后的剩余保险期间。

结果通知模块1203用于当核保处理成功时，通知核心系统更新待处理保单的保额为递增后的保额及更新待处理保单的剩余保险期间为递减后的剩余保险期间，并通知客户端保额递增成功。

其中，在待处理保单的总保险期间内，待处理保单的保费被周期地缴纳；保额递增期次基于总保险期间与缴纳保费的周期确定；保额随着保额递增期次的增加而递增，剩余保险期间随着保额递增期次的增加而递减。

根据本公开实施例提供的保单数据处理装置，提供了一种对周期缴费且保额随着已经过保险期间增加而增加的保险产品的保单数据进行处理的方法，基于客户端发送的保额递增请求，根据当前期次等信息，确定递增后的保额和剩余的保险期间，并对该保额递增请求进行核保处理，避免了相关技术中使用的核保逻辑无法适用于该保险产品，导致核保结果错误等问题。

在一些实施例中，请求处理模块1202可以包括：信息核对单元和结果确定单元。其中，信息核对单元用于核对当前保额与记录的当前保额是否一致；和/或，核对请求递增后的保额与确定出的递增后的保额是否一致；结果确定单元用于当当前保额与记录的当前保额一致，和/或请求递增后的保额与确定出的递增后的保额一致时，确定核保处理成功；当当前保额与记录的当前保额不一致，和/或请求递增后的保额与确定出的递增后的保额不一致时，确定核保处理失败。

在一些实施例中，请求处理模块1202还可以包括：理赔查询单元，用于向理赔服务系统发送待处理保单的理赔查询请求。结果确定单元还用于当理赔服务系统返回的待处理保单的理赔查询结果中不包含待处理保单的立案记录信息时，确定核保处理成功；当理赔服务系统返回的待处理保单的理赔查询结果中包含待处理保单的立案记录信息时，确定核保处理失败。

在一些实施例中，请求处理模块1202还可以包括：时间判断单元，用于判断当前距离上一次接收到待处理保单的保额递增请求的时间是否大于预设时长。结果确定单元还用于当当前距离上一次接收到待处理保单的保额递增请求的时间不大于预设时长时，确定核保处理成功；当当前距离上一次接收到待处理保单的保额递增请求的时间大于预设时长时，确定核保处理失败；其中，预设时长是根据缴纳保费的周期确定的。

在一些实施例中，结果通知模块1203还可以用于当核保处理失败时，通知客户端核保失败，且退还对应请求的保额递增期次已缴纳的保费。

在一些实施例中，保额随着保额递增期次的增加而指数递增，剩余保险期间随着保额递增期次的增加而线性递减。

在一些实施例中，递增后的保额基于下述公式计算：

递增后的新保额＝本期次保费/险别费率/(本期次对应的已经过的保险期间天数/总保险期间天数)；

其中，险别费率基于被保人的年龄、性别及保额递增期次确定。

在一些实施例中，保额递增请求在请求的保额递增期次对应的应缴保费缴纳完毕后生成。

图13是根据一示例性实施例示出的另一种保单数据处理装置的示意图。本公开实施例提供的保单数据处理装置可以应用于任意具备计算处理能力的电子设备执行，例如如图1中的服务器系统12。

参考图13，保单数据处理装置130包括：请求接收模块1201、请求存储模块1301、请求提取模块1302、请求处理模块1202及结果通知模块1203。

其中，请求接收模块1201用于接收客户端发送的待处理保单的保额递增请求。

保额递增请求中包括：请求的保额递增期次、对应请求的保额递增期次已缴纳的保费、当前保额和/或请求递增后的保额。

请求存储模块1301用于向客户端返回数据接收成功消息，并将接收到的保额递增请求存储在消息队列中。

请求提取模块1302用于异步地从消息队列中取出保额递增请求。

请求处理模块1202用于对取出的待处理保单的保额递增请求进行核保处理，确定待处理保单递增后的保额及递减后的剩余保险期间。

结果通知模块1203用于当核保处理成功时，通知核心系统更新待处理保单的保额为递增后的保额及更新待处理保单的剩余保险期间为递减后的剩余保险期间，并通知客户端保额递增成功。

其中，在待处理保单的总保险期间内，待处理保单的保费被周期地缴纳；保额递增期次基于总保险期间与缴纳保费的周期确定；保额随着保额递增期次的增加而递增，剩余保险期间随着保额递增期次的增加而递减。

图14是根据一示例性实施例示出的再一种保单数据处理装置的示意图。本公开实施例提供的装置可以应用于任意具备计算处理能力的电子设备中，例如如图1中的终端11。在下面的举例说明中，以应用于终端11中进行示例说明。

参考图14，保单数据处理装置140包括：请求发送模块1401、消息处理模块1402。

请求发送模块1401用于当检测到待处理保单当前期次应缴保费缴纳完毕时，向服务器系统发送待处理保单的保额递增请求。

消息处理模块1402用于当接收到服务器系统发送的待处理保单的保额递增成功消息时，从保额递增成功消息中获取待处理保单的递增后的保额，并在用户显示界面中显示待处理保单的递增后的保额。

其中，在待处理保单的总保险期间内，待处理保单的保费被周期地缴纳；对应保额递增请求的保额递增期次基于总保险期间与缴纳保费的周期确定；保额随着保额递增期次的增加而递增。

在一些实施例中，保额随着保额递增期次的增加而指数递增。

在一些实施例中，消息处理模块1402还用于当接收到待处理保单的保额递增成功消息时，从保额递增成功消息中获取待处理保单的剩余保险期间，并在用户显示界面中显示待处理保单的剩余保险期间；其中，剩余保险期间随着保额递增期次的增加而递减。

在一些实施例中，剩余保险期间随着保额递增期次的增加而线性递减。

在一些实施例中，装置140还包括：指示检测模块和指示处理模块；其中，指示检测模块用于在检测待处理保单当前期次应缴保费是否缴纳完毕之前，当检测到用户输入的待处理保单的缴费请求时，在用户显示界面中显示待处理保单的保费缴费界面。指示处理模块用于当检测到用户在保费缴费界面输入的保费缴费指示时，发起待处理保单的保费缴纳流程。

所属技术领域的技术人员能够理解，本公开的各个方面可以实现为系统、方法或程序产品。因此，本公开的各个方面可以具体实现为以下形式，即：完全的硬件实施方式、完全的软件实施方式(包括固件、微代码等)，或硬件和软件方面结合的实施方式，这里可以统称为“电路”、“模块”或“系统”。

下面参照图15来描述根据本公开的这种实施方式的电子设备800。图15显示的电子设备800仅仅是一个示例，不应对本公开实施例的功能和使用范围带来任何限制。

如图15所示，电子设备800以通用计算设备的形式表现。电子设备800的组件可以包括但不限于：上述至少一个处理单元810、上述至少一个存储单元820、连接不同系统组件(包括存储单元820和处理单元810)的总线830。

其中，所述存储单元存储有程序代码，所述程序代码可以被所述处理单元810执行，使得所述处理单元810执行本说明书上述“示例性方法”部分中描述的根据本公开各种示例性实施方式的步骤。例如，所述处理单元810可以执行如图4中所示的S401，接收客户端发送的待处理保单的保额递增请求；S402，对待处理保单的保额递增请求进行核保处理，确定待处理保单递增后的保额及递减后的剩余保险期间；S403，当所述核保处理成功时，通知核心系统更新该待处理保单的保额为该递增后的保额及更新该待处理保单的剩余保险期间为该递减后的剩余保险期间，并通知客户端保额递增成功。

存储单元820可以包括易失性存储单元形式的可读介质，例如随机存取存储单元(RAM)8201和/或高速缓存存储单元8202，还可以进一步包括只读存储单元(ROM)8203。

存储单元820还可以包括具有一组(至少一个)程序模块8205的程序/实用工具8204，这样的程序模块8205包括但不限于：操作系统、一个或者多个应用程序、其它程序模块以及程序数据，这些示例中的每一个或某种组合中可能包括网络环境的实现。

总线830可以为表示几类总线结构中的一种或多种，包括存储单元总线或者存储单元控制器、外围总线、图形加速端口、处理单元或者使用多种总线结构中的任意总线结构的局域总线。

电子设备800也可以与一个或多个外部设备700(例如键盘、指向设备、蓝牙设备等)通信，还可与一个或者多个使得用户能与该电子设备800交互的设备通信，和/或与使得该电子设备800能与一个或多个其它计算设备进行通信的任何设备(例如路由器、调制解调器等等)通信。这种通信可以通过输入/输出(I/O)接口850进行。并且，电子设备800还可以通过网络适配器860与一个或者多个网络(例如局域网(LAN)，广域网(WAN)和/或公共网络，例如因特网)通信。如图所示，网络适配器860通过总线830与电子设备800的其它模块通信。应当明白，尽管图中未示出，可以结合电子设备800使用其它硬件和/或软件模块，包括但不限于：微代码、设备驱动器、冗余处理单元、外部磁盘驱动阵列、RAID系统、磁带驱动器以及数据备份存储系统等。

通过以上的实施方式的描述，本领域的技术人员易于理解，这里描述的示例实施方式可以通过软件实现，也可以通过软件结合必要的硬件的方式来实现。因此，根据本公开实施方式的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM，U盘，移动硬盘等)中或网络上，包括若干指令以使得一台计算设备(可以是个人计算机、服务器、终端装置、或者网络设备等)执行根据本公开实施方式的方法。

在本公开的示例性实施例中，还提供了一种计算机可读存储介质，其上存储有能够实现本说明书上述方法的程序产品。在一些可能的实施方式中，本公开的各个方面还可以实现为一种程序产品的形式，其包括程序代码，当所述程序产品在终端设备上运行时，所述程序代码用于使所述终端设备执行本说明书上述“示例性方法”部分中描述的根据本公开各种示例性实施方式的步骤。

参考图16所示，描述了根据本公开的实施方式的用于实现上述方法的程序产品900，其可以采用便携式紧凑盘只读存储器(CD-ROM)并包括程序代码，并可以在终端设备，例如个人电脑上运行。然而，本公开的程序产品不限于此，在本文件中，可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。

所述程序产品可以采用一个或多个可读介质的任意组合。可读介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以为但不限于电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。

计算机可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了可读程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。可读信号介质还可以是可读存储介质以外的任何可读介质，该可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。

可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于无线、有线、光缆、RF等等，或者上述的任意合适的组合。

可以以一种或多种程序设计语言的任意组合来编写用于执行本公开操作的程序代码，所述程序设计语言包括面向对象的程序设计语言—诸如Java、C++等，还包括常规的过程式程序设计语言—诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算设备上执行、部分地在用户设备上执行、作为一个独立的软件包执行、部分在用户计算设备上部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。在涉及远程计算设备的情形中，远程计算设备可以通过任意种类的网络，包括局域网(LAN)或广域网(WAN)，连接到用户计算设备，或者，可以连接到外部计算设备(例如利用因特网服务提供商来通过因特网连接)。

应当注意，尽管在上文详细描述中提及了用于动作执行的设备的若干模块或者单元，但是这种划分并非强制性的。实际上，根据本公开的实施方式，上文描述的两个或更多模块或者单元的特征和功能可以在一个模块或者单元中具体化。反之，上文描述的一个模块或者单元的特征和功能可以进一步划分为由多个模块或者单元来具体化。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本公开的其它实施方案。本公开旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本公开的真正范围和精神由所附的权利要求指出。

Claims (17)

1.一种保单数据处理方法，其特征在于，包括：

接收客户端发送的待处理保单的保额递增请求；

对所述待处理保单的保额递增请求进行核保处理，确定所述待处理保单递增后的保额及递减后的剩余保险期间；

当所述核保处理成功时，通知核心系统更新所述待处理保单的保额为所述递增后的保额及更新所述待处理保单的剩余保险期间为所述递减后的剩余保险期间，并通知所述客户端保额递增成功；

其中，在所述待处理保单的总保险期间内，所述待处理保单的保费被周期地缴纳；对应所述保额递增请求的保额递增期次基于所述总保险期间与缴纳所述保费的周期确定；所述保额随着所述保额递增期次的增加而递增，所述剩余保险期间随着所述保额递增期次的增加而递减。

2.根据权利要求1所述的方法，其特征在于，所述保额递增请求包括：当前保额和/或请求递增后的保额；对所述待处理保单的保额递增请求进行核保处理包括：

核对所述当前保额与记录的当前保额是否一致；和/或，

核对所述请求递增后的保额与确定出的所述递增后的保额是否一致；

当所述当前保额与记录的当前保额一致，和/或所述请求递增后的保额与确定出的所述递增后的保额一致时，确定所述核保处理成功；

当所述当前保额与记录的当前保额不一致，和/或所述请求递增后的保额与确定出的所述递增后的保额不一致时，确定所述核保处理失败。

3.根据权利要求1或2所述的方法，其特征在于，对所述待处理保单的保额递增请求进行核保处理包括：

向理赔服务系统发送所述待处理保单的理赔查询请求；

当所述理赔服务系统返回的所述待处理保单的理赔查询结果中不包含所述待处理保单的立案记录信息时，确定所述核保处理成功；

当所述理赔服务系统返回的所述待处理保单的理赔查询结果中包含所述待处理保单的立案记录信息时，确定所述核保处理失败。

4.根据权利要求3所述的方法，其特征在于，对所述待处理保单的保额递增请求进行核保处理还包括：

判断当前距离上一次接收到所述待处理保单的保额递增请求的时间是否大于预设时长；

当当前距离上一次接收到所述待处理保单的保额递增请求的时间不大于所述预设时长时，确定所述核保处理成功；

当当前距离上一次接收到所述待处理保单的保额递增请求的时间大于所述预设时长时，确定所述核保处理失败；

其中，所述预设时长是根据缴纳所述保费的周期确定的。

5.根据权利要求1所述的方法，其特征在于，还包括：

当所述核保处理失败时，通知所述客户端核保失败，且退还对应所述保额递增请求的保额递增期次已缴纳的保费。

6.根据权利要求1所述的方法，其特征在于，所述保额随着所述保额递增期次的增加而指数递增，所述剩余保险期间随着所述保额递增期次的增加而线性递减。

7.根据权利要求1所述的方法，其特征在于，还包括：

在接收到所述客户端发送的所述待处理保单的保额递增请求后，向所述客户端返回数据接收成功消息，并将接收到的所述保额递增请求存储在消息队列中；

异步地从消息队列中取出所述保额递增请求，以对所述保额递增请求进行所述核保处理。

8.根据权利要求1所述的方法，其特征在于，所述保额递增请求在所述保额递增期次对应的应缴保费缴纳完毕后生成。

9.一种保单数据处理方法，其特征在于，包括：

当检测到待处理保单当前期次应缴保费缴纳完毕时，向服务器系统发送所述待处理保单的保额递增请求；

当接收到所述服务器系统发送的所述待处理保单的保额递增成功消息时，从所述保额递增成功消息中获取所述待处理保单的递增后的保额，并在用户显示界面中显示所述待处理保单的递增后的保额；

其中，在所述待处理保单的总保险期间内，所述待处理保单的保费被周期地缴纳；对应所述保额递增请求的保额递增期次基于所述总保险期间与缴纳所述保费的周期确定；所述保额随着所述保额递增期次的增加而递增。

10.根据权利要求9所述的方法，其特征在于，所述保额随着所述保额递增期次的增加而指数递增。

11.根据权利要求9或10所述的方法，其特征在于，还包括：

当接收到所述待处理保单的保额递增成功消息时，从所述保额递增成功消息中获取所述待处理保单的剩余保险期间，并在用户显示界面中显示所述待处理保单的剩余保险期间；

其中，所述剩余保险期间随着所述保额递增期次的增加而递减。

12.根据权利要求11所述的方法，其特征在于，所述剩余保险期间随着所述保额递增期次的增加而线性递减。

13.根据权利要求9所述的方法，其特征在于，在检测所述待处理保单当前期次应缴保费是否缴纳完毕之前，所述方法还包括：

当检测到用户输入的所述待处理保单的缴费请求时，在所述用户显示界面中显示所述待处理保单的保费缴费界面；

当检测到用户在所述保费缴费界面输入的保费缴费指示时，发起所述待处理保单的保费缴纳流程。

14.一种保单数据处理装置，其特征在于，包括：

请求接收模块，用于接收客户端发送的待处理保单的保额递增请求；

请求处理模块，用于对所述待处理保单的保额递增请求进行核保处理，确定所述待处理保单递增后的保额及递减后的剩余保险期间；

结果通知模块，用于当所述核保处理成功时，通知核心系统更新所述待处理保单的保额为所述递增后的保额及更新所述待处理保单的剩余保险期间为所述递减后的剩余保险期间，并通知所述客户端保额递增成功；

其中，在所述待处理保单的总保险期间内，所述待处理保单的保费被周期地缴纳；对应所述保额递增请求的保额递增期次基于所述总保险期间与缴纳所述保费的周期确定；所述保额随着所述保额递增期次的增加而递增，所述剩余保险期间随着所述保额递增期次的增加而递减。

15.一种保单数据处理装置，其特征在于，包括：

请求发送模块，用于当检测到待处理保单当前期次应缴保费缴纳完毕时，向服务器系统发送所述待处理保单的保额递增请求；

消息处理模块，用于当接收到所述服务器系统发送的所述待处理保单的保额递增成功消息时，从所述保额递增成功消息中获取所述待处理保单的递增后的保额，并在用户显示界面中显示所述待处理保单的递增后的保额；

其中，在所述待处理保单的总保险期间内，所述待处理保单的保费被周期地缴纳；对应所述保额递增请求的保额递增期次基于所述总保险期间与缴纳所述保费的周期确定；所述保额随着所述保额递增期次的增加而递增。

16.一种电子设备，其特征在于，包括：

处理器；以及

存储器，用于存储所述处理器的可执行指令；

其中，所述处理器配置为经由执行所述可执行指令来执行权利要求1-8任一项所述的方法，或者执行权利要求9-13任一项所述的方法。

17.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求1-8任一项所述的方法，或者实现权利要求9-13任一项所述的方法。

Images