一种电子投标保函服务方法

本发明属于计算机技术领域，具体地涉及一种电子投标保函服务方法。

电子保函是保证人以使用CA(Certificate Authority，证书颁发机构)证书进行电子签名的数据电文为介质，通过计算机网络向受益人开立的具有法律效力的担保凭证。电子保函一般由被保证人通过计算机网络向保证人发出申请，保证人以替被保证人提供保证为目的，使用CA证书对数据电文进行电子签名，并通过计算机网络为媒介，向受益人开立具有法律效力的保证担保电子信用凭证。电子保函是信息时代的产物，同纸质保函一样，由银行、保险公司、担保公司或其他担保人应投保人的请求，向受益人开立的一种电子化担保凭证，保证在申请人未能按双方协议履行其责任或义务时，由担保人代其履行一定金额和一定时限范围内的某种支付或经济赔偿责任。

投标保函是指在招投标交易活动中招标人为保证投标方不得撤销投标文件、中标后不得无正当理由不与招标人订立合同等，要求投标方在提交投标文件时一并提交的一般由银行出具的书面担保。但是在当前的招投标交易活动(例如公共资源交易活动)中，各投标方的投标保证主要是以现金投标保证金或由银行出具的纸质保函，如此不仅会占用投标方有限的资金流，还存在无法保证和出现纸质保函丢失的问题，有必要提供一种基于计算机技术实现电子投标保函在线开立、注销、退保和理赔等全流程服务的技术方案，以便加快推进招投标全流程电子化和改进投标担保方式。

为了解决在当前招投标交易活动中投标担保存在无法保证和出现纸质保函丢失的问题，本发明目的在于提供一种电子投标保函服务方法、装置、计算机设备及计算机可读存储介质，可以通过与招投标交易活动中心、担保机构端和银行端等的信息交互和处理，实现在线开立电子投标保函等流程线上化的目的，并采用电子保函来替代现金保证金，方便在线查核，满足无纸化应用场景需求，利于加快推进招投标全流程电子化和改进投标担保方式，便于实际应用和推广。

第一方面，本发明提供了一种电子投标保函服务方法，包括：

接收来自招投标交易中心的且由投标方发起的电子保函开立申请，其中，所述电子保函开立申请的内容包含有标段信息、投标方信息和由所述投标方指定的保函产品信息；

根据所述电子保函开立申请的内容生成保函申请订单，其中，所述保函申请订单包含有保函信息和所述投标方信息，所述保函信息包含有经办银行和保函金额，所述经办银行在所述保函产品信息中指定，所述保函金额等于所述标段信息中的担保金额；

当所述保函产品信息中指定的保函开立模式为分离式保函开立模式时，根据所述保函金额以及与所述保函产品信息中指定的担保机构对应的保费收取比率/和保费收取最低金额，计算得到保费金额；

向所述招投标交易中心推送携带有所述保费金额的第一支付请求，以便所述投标方在所述招投标交易中心响应所述第一支付请求，向所述担保机构支付等于所述保费金额的资金；

在收到来自所述招投标交易中心的且响应所述第一支付请求的支付成功信息后，将所述保函申请订单推送至与所述担保机构对应的担保机构端，以便所述担保机构端对所述保函申请订单进行审批，并在审批通过后根据所述保函申请订单生成第一待签电子文件，然后将所述保函申请订单和所述第一待签电子文件推送至与所述经办银行对应的银行端，进一步以便所述银行端对所述保函申请订单进行审批，并在审批通过后应用契约锁在所述第一待签电子文件上加盖电子签章，得到第一电子投标保函；

接收由所述银行端出具的所述第一电子投标保函；

将所述第一电子投标保函推送至所述招投标交易中心，以便反馈给所述投标方。

基于上述发明内容，提供了一种基于计算机技术实现电子投标保函在线开立、签发和下载等流程服务的技术方案，即通过与招投标交易活动中心、担保机构端和银行端等进行的信息交互和处理，可以完成电子投标保函的分离式申请、材料审批、保函签发和下载等线上化服务流程，进而可以实现在线开立电子投标保函等流程线上化的目的，并可采用电子保函来替代现金保证金，方便在线查核，满足无纸化应用场景需求，利于加快推进招投标全流程电子化和改进投标担保方式，便于实际应用和推广。

在一个可能的设计中，在根据所述保函金额以及与所述保函产品信息中指定的担保机构对应的保费收取比率/和保费收取最低金额，计算得到保费金额之前，所述方法还包括：

获取所述经办银行授予所述担保机构的当前剩余授信额度；

判断所述当前剩余授信额度是否小于所述保函金额；

若是，则向所述招投标交易中心反馈保函申请失败信息，以便所述投标方重新在所述保函产品信息中指定另一担保机构，更新所述电子保函开立申请。

在一个可能的设计中，在收到来自所述招投标交易中心的且响应所述第一支付请求的支付成功信息后且在接收由所述银行端出具的所述第一电子投标保函之前，所述方法还包括：

接收来自所述招投标交易中心的且由所述投标方发起的电子保函退保申请，其中，所述电子保函退保申请的内容包含有与所述保函申请订单对应的退保事由材料；

将所述退保事由材料推送至所述担保机构端，以便所述担保机构端在收到所述第一电子投标保函之前，判断是否已将所述保函申请订单推送至所述银行端，若否，则中止对所述保函申请订单进行审批，然后对所述退保事由材料进行审批，并在审批通过后终止对所述保函申请订单进行审批且在完成线下退保支付动作后反馈第一退保完成指示信息，而若是，则对所述退保事由材料进行审批，并在审批通过后向所述银行端推送审批终止指示信息，进一步以便所述银行端在应用契约锁加盖电子签章前，终止对所述保函申请订单进行审批，并在审批终止后反馈终止确认指示信息；

在收到所述第一退保完成指示信息或由所述担保机构端反馈的第二退保完成指示信息后，向所述招投标交易中心反馈退保申请成功信息，其中，所述第二退保完成指示信息在所述担保机构端收到所述终止确认指示信息且完成线下退保支付动作后进行反馈。

在一个可能的设计中，在接收由所述银行端出具的所述第一电子投标保函之后，所述方法还包括：

获取所述经办银行授予所述担保机构的当前剩余授信额度；

将所述当前剩余授信额度更新为在减去所述保函金额后的新额度值；

判断所述新额度值是否小于预设的额度阈值；

若是，则向所述担保机构端推送用于指示授信额度即将不足的提示信息。

在一个可能的设计中，在将所述第一电子投标保函推送至所述招投标交易中心之后，所述方法还包括：

在所述保函信息中的保函到期时刻到达时，获取所述经办银行授予所述担保机构的当前剩余授信额度，然后将该当前剩余授信额度更新为在加上所述保函金额后的新额度值；

或者，接收来自所述招投标交易中心的且由所述投标方在开标后发起的电子保函注销申请，其中，所述电子保函注销申请的内容包含有与所述保函信息对应的注销事由材料；

将所述注销事由材料推送至所述担保机构端，以便所述担保机构端对所述注销事由材料进行审批，并在审批通过后将所述注销事由材料推送至所述银行端，进一步以便所述银行端对所述注销事由材料进行审批，并在审批通过后反馈注销完成指示信息；

在收到由所述银行端反馈的所述注销完成指示信息后，获取所述经办银行授予所述担保机构的当前剩余授信额度，然后将该当前剩余授信额度更新为在加上所述保函金额后的新额度值。

在一个可能的设计中，在将所述第一电子投标保函推送至所述招投标交易中心之后，所述方法还包括：

将所述保函申请订单的状态更新为已出函状态；

接收来自所述招投标交易中心的且由招标方在中标后发起的电子保函理赔申请，其中，所述电子保函理赔申请的内容包含有与所述保函申请订单对应的理赔事由材料；

将所述理赔事由材料推送至所述担保机构端，以便所述担保机构端对所述理赔事由材料进行审批，并在审批通过后将所述理赔事由材料推送至所述银行端，进一步以便所述银行端对所述理赔事由材料进行审批，并在审批通过且完成线下理赔支付动作后反馈理赔完成指示信息；

在收到由所述银行端反馈的所述理赔完成指示信息后，将所述保函申请订单的状态更新为已理赔状态，并向所述招投标交易中心反馈理赔申请成功信息。

在一个可能的设计中，所述方法还包括：

当所述保函产品信息中指定的保函开立模式为直开式保函开立模式时，向所述招投标交易中心推送携带有所述保函金额的第二支付请求，以便所述投标方在所述招投标交易中心响应所述第二支付请求，向所述经办银行支付等于所述保函金额的资金；

在收到来自所述招投标交易中心的且响应所述第二支付请求的支付成功信息后，将所述保函申请订单推送至与所述经办银行对应的银行端，以便所述银行端对所述保函申请订单进行审批，并在审批通过后应用契约锁在根据所述保函申请订单生成的第二待签电子文件上加盖电子签章，得到第二电子投标保函；

接收由所述银行端出具的所述第二电子投标保函；

将所述第二电子投标保函推送至所述招投标交易中心，以便反馈给所述投标方。

第二方面，本发明提供了一种电子投标保函服务装置，包括有申请接收模块、订单生成模块、保费计算模块、支付推送模块、订单推送模块、保函接收模块和保函推送模块；

所述申请接收模块，用于接收来自招投标交易中心的且由投标方发起的电子保函开立申请，其中，所述电子保函开立申请的内容包含有标段信息、投标方信息和由所述投标方指定的保函产品信息；

所述订单生成模块，通信连接所述申请接收模块，用于根据所述电子保函开立申请的内容生成保函申请订单，其中，所述保函申请订单包含有保函信息和所述投标方信息，所述保函信息包含有经办银行和保函金额，所述经办银行在所述保函产品信息中指定，所述保函金额等于所述标段信息中的担保金额；

所述保费计算模块，通信连接所述申请接收模块，用于当所述保函产品信息中指定的保函开立模式为分离式保函开立模式时，根据所述保函金额以及与所述保函产品信息中指定的担保机构对应的保费收取比率/和保费收取最低金额，计算得到保费金额；

所述支付推送模块，通信连接所述保费计算模块，用于向所述招投标交易中心推送携带有所述保费金额的第一支付请求，以便所述投标方在所述招投标交易中心响应所述第一支付请求，向所述担保机构支付等于所述保费金额的资金；

所述订单推送模块，通信连接所述订单生成模块，用于在收到来自所述招投标交易中心的且响应所述第一支付请求的支付成功信息后，将所述保函申请订单推送至与所述担保机构对应的担保机构端，以便所述担保机构端对所述保函申请订单进行审批，并在审批通过后根据所述保函申请订单生成第一待签电子文件，然后将所述保函申请订单和所述第一待签电子文件推送至与所述经办银行对应的银行端，进一步以便所述银行端对所述保函申请订单进行审批，并在审批通过后应用契约锁在所述第一待签电子文件上加盖电子签章，得到第一电子投标保函；

所述保函接收模块，用于接收由所述银行端出具的所述第一电子投标保函；

所述保函推送模块，通信连接所述保函接收模块，用于将所述第一电子投标保函推送至所述招投标交易中心，以便反馈给所述投标方。

第三方面，本发明提供了一种计算机设备，包括有依次通信连接的存储器、处理器和收发器，其中，所述存储器用于存储计算机程序，所述收发器用于收发消息，所述处理器用于读取所述计算机程序，执行如第一方面或第一方面中任意一种可能设计所述的电子投标保函服务方法。

第四方面，本发明提供了一种计算机可读存储介质，所述计算机可读存储介质上存储有指令，当所述指令在计算机上运行时，执行如上第一方面或第一方面中任意一种可能设计的所述电子投标保函服务方法。

第五方面，本发明提供了一种包含指令的计算机程序产品，当所述指令在计算机上运行时，使所述计算机执行如上第一方面或第一方面中任意一种可能设计的所述电子投标保函服务方法。

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本发明提供的电子投标保函服务方法的流程示意图。

图2是本发明提供的电子投标保函服务装置的结构示意图。

图3是本发明提供的计算机设备的结构示意图。

下面结合附图及具体实施例来对本发明作进一步阐述。在此需要说明的是，对于这些实施例方式的说明虽然是用于帮助理解本发明，但并不构成对本发明的限定。本文公开的特定结构和功能细节仅用于描述本发明示例的实施例。然而，可用很多备选的形式来体现本发明，并且不应当理解为本发明限制在本文阐述的实施例中。

应当理解，尽管本文可能使用术语第一、第二等等来描述各种对象，但是这些对象不应当受到这些术语的限制。这些术语仅用于区分一个对象和另一个对象。例如可以将第一对象称作第二对象,并且类似地可以将第二对象称作第一对象，同时不脱离本发明的示例实施例的范围。

应当理解，对于本文中可能出现的术语“和/或”，其仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A、单独存在B或者同时存在A和B等三种情况；对于本文中可能出现的术语“/和”，其是描述另一种关联对象关系，表示可以存在两种关系，例如，A/和B，可以表示：单独存在A或者同时存在A和B等两种情况；另外，对于本文中可能出现的字符“/”，一般表示前后关联对象是一种“或”关系。

如图1所示，本实施例第一方面提供的所述电子投标保函服务方法，可以但不限于由通信连接招投标交易中心、担保机构端和银行端等的电子设备(例如服务器、台式电脑、笔记本电脑或智能手机等)的云服务器执行，以便通过与所述招投标交易活动中心、所述担保机构端和所述银行端等进行的信息交互和处理，实现在线开立电子投标保函等流程线上化的目的。所述电子投标保函服务方法，可以但不限于包括有如下步骤S1～S7。

S1.接收来自招投标交易中心的且由投标方发起的电子保函开立申请，其中，所述电子保函开立申请的内容包含但不限于有标段信息、投标方信息和由所述投标方指定的保函产品信息等。

在所述步骤S1中，所述招投标交易中心为实现招标方线上招标和投标方线上投标等目的的现有网络设备，以便为所述招标方和所述投标方提供线上撮合交易服务，例如该网络设备为APP(应用程序，Application的缩写)服务器或Web服务器(即一种网站服务器，通过驻留于因特网上某种类型计算机的程序，可以处理浏览器等Web客户端的请求并返回相应响应)，使得用户可在登录APP客户端或Web客户端后进行线上招标或线上投标等操作。所述电子保函开立申请可由所述招标方通过在所述APP客户端或所述Web客户端上的人机交互操作来发起，具体发起方式可以但不限于包括：先在所述APP客户端或所述Web客户端上的一个预设申请模板中导入由招标方发布的所述标段信息、填写所述投标方信息和选定所述保函产品信息中的具体内容(例如选定保函开立模式、经办银行和担保机构等)，建立得到一个电子保函开立申请，然后提交该电子保函开立申请，以便将该电子保函开立申请经由所述招投标交易中心中转传送至本地云服务器。此外，所述标段信息包含但不限于有项目类型、项目名称、项目编号、标段名称、标段编号、担保金额、招标方名称、招标方的统一社会信用代码、招标方的营业地址、开标时间和期限等；所述投标方信息包含但不限于有投标方的名称、营业地址、统一信用代码、企业类型、注册资本、营业执照到期日、经办人、经办人手机号、法人代表、法人身份证号、法人手机号、营业执照图像和法人身份证正反面图像等；所述保函产品信息包含但不限于有产品名称、产品描述、保函开立模式(即分离式保函开立模式/直开式保函开立模式)、担保机构、担保机构分润比例、保费收取最低金额和保费收取比率等，所述保函产品信息中的具体内容及选取范围可以但不限于通过本地服务方与所述招投标交易中心的主办方所达成的渠道合作协议来提前约定。

S2.根据所述电子保函开立申请的内容生成保函申请订单，其中，所述保函申请订单包含但不限于有保函信息和所述投标方信息等，所述保函信息包含但不限于有经办银行和保函金额等，所述经办银行在所述保函产品信息中指定，所述保函金额等于所述标段信息中的担保金额。

在所述步骤S2中，所述保函申请订单还可包含但不限于有订单编号、订单状态和/或申请时刻等内容，以便对所述保函申请订单进行全周期管理和查询展示，其中，所述订单编号用于唯一标记所述保函申请订单，可以通过常规方法生成得到，所述订单状态用于标记所述保函申请订单的当前状态，可在生成时初始为准入状态，所述申请时间可以即为所述电子保函开立申请的提交时刻或收到时刻。所述保函信息还可包含但不限于有保函号码、担保机构、银行手续费费率、保费金额、风险敞口条件、保函开立时刻和/或保函到期时刻等内容，以便对开立的电子投标保函进行详情记录，这些内容可在所述保函申请订单生成时为空，并在后续得到电子投标保函后，根据该电子投标保函的实际内容进行更新。此外，在所述步骤S2之前，可基于预设审核规则对所述电子保函开立申请的内容进行自动化审核，若发现关键信息欠缺等情况，可将相应提示信息反馈给所述招投标交易中心，以便所述投标方在线更新所述电子保函开立申请的内容，直到审核通过后，再根据所述电子保函开立申请的内容生成所述保函申请订单。

S3.当所述保函产品信息中指定的保函开立模式为分离式保函开立模式时，根据所述保函金额以及与所述保函产品信息中指定的担保机构对应的保费收取比率/和保费收取最低金额，计算得到保费金额。

在所述步骤S3中，分离式保函是指被担保方通过第三方担保(即担保公司或担保机构等)向银行申请的保函，因此所述保函产品信息中必须指定有所述担保机构。所述保费金额的计算方式为常规方式，即当不存在所述保费收取最低金额时，所述保函金额和所述保费收取比率的乘积结果即为所述保费金额；而当存在所述保费收取最低金额时，若所述保函金额和所述保费收取比率的乘积结果大于所述保费收取最低金额，则所述保函金额和所述保费收取比率的乘积结果即为所述保费金额，否则所述保费收取最低金额即为所述保费金额。此外，基于同样的计算方式，还可以根据所述保函金额和与所述经办银行对应的银行手续费费率，计算得到手续费金额。

在所述步骤S3中，考虑在担保机构与经办银行预先达成的担保合作协议中确定了有限的授信额度，而随着担保机构所承接担保业务的增多，会使授信额度逐渐减少，为了确保当前所选的担保机构能够承接本次投标担保，提升后续保函申请成功率，优选的，在根据所述保函金额以及与所述保函产品信息中指定的担保机构对应的保费收取比率/和保费收取最低金额，计算得到保费金额之前，所述方法还包括但不限于有如下步骤S31～S33。

S31.获取所述经办银行授予所述担保机构的当前剩余授信额度。

在所述步骤S31中，所述当前剩余授信额度的初始值可在登记所述担保机构的基本信息时，根据所述担保合作协议输入得到，然后在本地云服务器上根据与所述担保机构对应的所有保函申请订单的订单状态进行实时更新。

S32.判断所述当前剩余授信额度是否小于所述保函金额。

S33.若是，则向所述招投标交易中心反馈保函申请失败信息，以便所述投标方重新在所述保函产品信息中指定另一担保机构，更新所述电子保函开立申请。

在所述步骤S33中，由于所述当前剩余授信额度小于所述保函金额，表明当前所选的担保机构在承接本次投标担保后，极可能因授信额度过度耗尽而违背所述担保合作协议，导致后续保函申请失败，因此通过反馈所述保函申请失败信息，可以及时更换担保机构，保障后续步骤有意义的进行。

S4.向所述招投标交易中心推送携带有所述保费金额的第一支付请求，以便所述投标方在所述招投标交易中心响应所述第一支付请求，向所述担保机构支付等于所述保费金额的资金。

在所述步骤S4中，所述投标方的具体支付方式为常规的线下支付方式，例如基于支付宝平台或平台等第三方支付平台完成支付动作。为了实时且准确地更新所述保函申请订单的订单状态，可在推送所述第一支付请求后，将所述订单状态更新为待支付状态。此外，若计算得到有所述手续费金额，还可以在所述第一支付请求中携带有所述手续费金额，以便所述投标方还向所述担保机构支付等于所述手续费金额的资金。

S5.在收到来自所述招投标交易中心的且响应所述第一支付请求的支付成功信息后，将所述保函申请订单推送至与所述担保机构对应的担保机构端，以便所述担保机构端对所述保函申请订单进行审批，并在审批通过后根据所述保函申请订单生成第一待签电子文件，然后将所述保函申请订单和所述第一待签电子文件推送至与所述经办银行对应的银行端，进一步以便所述银行端对所述保函申请订单进行审批，并在审批通过后应用契约锁在所述第一待签电子文件上加盖电子签章，得到第一电子投标保函。

在所述步骤S5中，所述担保机构端为所述担保机构的工作人员操作端，以便通过与工作人员的人机交互操作，完成审批和待签电子文件生成等手续；当本地云服务器为APP服务器或Web服务器时，所述担保机构端为APP客户端或Web客户端，以便所述工作人员在登录后可以进行人机交互操作。在所述担保机构端对所述保函申请订单进行审批的具体过程，可以是根据预设风控模型进行的流程化自动审批，也可以是人工审批，并在审批通过后，调用常规的生成协议接口，根据所述保函申请订单生成所述第一待签电子文件。具体的，所述第一待签电子文件可以但不限于包括有委托合同、保函申请书和保函协议等。

在所述步骤S5中，所述银行端为所述经办银行的业务员操作端，以便通过与业务员的人机交互操作，完成审批和待签电子文件盖章等手续；当本地云服务器为APP服务器或Web服务器时，所述银行端为APP客户端或Web客户端，以便所述业务员在登录后可以进行人机交互操作。在所述银行端对所述保函申请订单进行审批的具体过程，也可以是根据预设风控模型进行的流程化自动审批或人工审批，并在审批通过后，应用契约锁在所述第一待签电子文件上加盖电子签章，得到第一电子投标保函。所述契约锁是一个电子合同签署云平台，主要面向B端客户提供电子合同，且提供的电子合同具有与纸质合同一样的法律效力，其大体的流程是：由合同发起方上传需签署的合同文档，文档会进入“契约锁”的数据库，以加密形式存储；选择好所发对象后，会通过包含链接的短信、等方式进行提醒，签署方点击链接后可用手机完成签名操作，或者直接用“契约锁”App端完成该流程。至于所述电子签章，可经三方确认采用“俩俩签”的方式，即所述投标方与所述担保机构达成双方协议，所述担保机构与所述经办银行达成双方协议，其中，由于所述投标方与所述担保机构所使用的电子签章存在互认问题，可转交银行CA供应商的“契约锁”进行确定解决。此外，为了实时且准确地更新所述保函申请订单的订单状态，可在收到所述支付成功信息后，将所述订单状态更新为已支付状态，以及在推送所述保函申请订单后，将所述订单状态更新为审批中状态。

S6.接收由所述银行端出具的所述第一电子投标保函。

在所述步骤S6中，所述第一电子投标保函可从所述银行端直接传来，也可以经由所述担保机构端中转而来。所述担保机构端在收到所述第一电子投标保函后，可将等于所述手续费金额的资金支付给所述经办银行。此外，为了实时且准确地更新所述保函申请订单的订单状态，可在收到所述第一电子投标保函后，将所述订单状态更新为已出函状态。

在所述步骤S6之后，为了及时提醒所述担保机构可能存在授信额度即将不足的情况，所述方法还包括但不限于有如下步骤S61～S64：S61.获取所述经办银行授予所述担保机构的当前剩余授信额度；S62.将所述当前剩余授信额度更新为在减去所述保函金额后的新额度值；S63.判断所述新额度值是否小于预设的额度阈值；S64.若是，则向所述担保机构端推送用于指示授信额度即将不足的提示信息。所述额度阈值可以但不限于为零值或大于零的数值，以便将所述新额度值与所述额度阈值的比较结果作为提示依据，及时提醒所述担保机构进行授信额度的提升(例如采用充值提升等方式)。

S7.将所述第一电子投标保函推送至所述招投标交易中心，以便反馈给所述投标方。

在所述步骤S7中，所述第一电子投标保函可以在收到后自动推送，也可以应所述投标方的请求进行响应推送，从而可以完成电子投标保函的最终下载目的。此外，若收到来自所述担保机构端或所述银行端的审批未通过指示信息时，可向所述招投标交易中心反馈该审批未通过指示信息，以便及时告知所述投标方，本次电子保函开立申请失败；以及所述担保机构端在发出或收到来自所述银行端的所述审批未通过指示信息时，可进行线下退保支付动作，将等于所述保费金额/和所述手续费金额的资金退还给所述投标方。

由此基于前述步骤S1～S7所描述的电子投标保函服务方法，提供了一种基于计算机技术实现电子投标保函在线开立、签发和下载等流程服务的技术方案，即通过与招投标交易活动中心、担保机构端和银行端等进行的信息交互和处理，可以完成电子投标保函的分离式申请、材料审批、保函签发和下载等线上化服务流程，进而可以实现在线开立电子投标保函等流程线上化的目的，并可采用电子保函来替代现金保证金，方便在线查核，满足无纸化应用场景需求，利于加快推进招投标全流程电子化和改进投标担保方式，便于实际应用和推广。

本实施例在前述第一方面的技术方案基础上，还提供了一种如何中途在线申请退保的可能设计一，即在收到来自所述招投标交易中心的且响应所述第一支付请求的支付成功信息后且在接收由所述银行端出具的所述第一电子投标保函之前，所述方法还包括但不限于有如下步骤S501～S503。

S501.接收来自所述招投标交易中心的且由所述投标方发起的电子保函退保申请，其中，所述电子保函退保申请的内容包含有与所述保函申请订单对应的退保事由材料。

在所述步骤S501中，所述退保事由材料可以但不限于包含有所述保函申请订单的订单编号，以便实现与所述保函申请订单的绑定对应。

S502.将所述退保事由材料推送至所述担保机构端，以便所述担保机构端在收到所述第一电子投标保函之前，判断是否已将所述保函申请订单推送至所述银行端，若否，则中止对所述保函申请订单进行审批，然后对所述退保事由材料进行审批，并在审批通过后终止对所述保函申请订单进行审批且在完成线下退保支付动作后反馈第一退保完成指示信息，而若是，则对所述退保事由材料进行审批，并在审批通过后向所述银行端推送审批终止指示信息，进一步以便所述银行端在应用契约锁加盖电子签章前，终止对所述保函申请订单进行审批，并在审批终止后反馈终止确认指示信息。

在所述步骤S502中，所述担保机构端或所述银行端对所述退保事由材料进行的审批，同样可以是根据预设风控模型进行的流程化自动审批或人工审批。若审批通过，可由所述担保机构端进行线下退保支付动作，将等于所述保费金额/和所述手续费金额的资金退还给所述投标方；而若审批未通过或已应用契约锁加盖电子签章，将反馈退保失败指示信息，此时将不进行任何形式的线下退保支付动作。

S503.在收到所述第一退保完成指示信息或由所述担保机构端反馈的第二退保完成指示信息后，向所述招投标交易中心反馈退保申请成功信息，其中，所述第二退保完成指示信息在所述担保机构端收到所述终止确认指示信息且完成线下退保支付动作后进行反馈。

由此基于前述步骤S501～S503所描述的可能设计一，可以在审批过程中进行中途在线申请退保的流程服务，进一步利于实现在线开立电子投标保函等流程线上化的目的。此外，为了实时且准确地更新所述保函申请订单的订单状态，可在收到所述第一退保完成指示信息或所述第二退保完成指示信息后，将所述订单状态更新为已退保状态。

本实施例在前述第一方面或可能设计一的技术方案基础上，还提供了一种如何被动注销分离式电子投标保函的可能设计二，即在将所述第一电子投标保函推送至所述招投标交易中心之后，所述方法还包括但不限于有如下步骤：在所述保函信息中的保函到期时刻到达时，获取所述经办银行授予所述担保机构的当前剩余授信额度，然后将该当前剩余授信额度更新为在加上所述保函金额后的新额度值。通过前述具体方式，可以在被动注销所述第一电子投标保函时，自动释放所述担保机构的授信额度，以便承接下一个投标担保业务，保障所述担保机构的正常营业。此外，为了实时且准确地更新所述保函申请订单的订单状态，可在所述保函信息中的保函到期时刻到达时，将所述订单状态更新为已注销状态。

由此基于前述步骤所描述的可能设计二，可以在被动注销所述第一电子投标保函时，自动释放所述担保机构的授信额度，以便承接下一个投标担保业务，保障所述担保机构的正常营业。

本实施例在前述第一方面或可能设计一的技术方案基础上，还提供了另一种如何主动注销分离式电子投标保函的可能设计三，即在将所述第一电子投标保函推送至所述招投标交易中心之后，所述方法还包括但不限于有如下步骤S81～S83。

S81.接收来自所述招投标交易中心的且由所述投标方在开标后发起的电子保函注销申请，其中，所述电子保函注销申请的内容包含有与所述保函信息对应的注销事由材料。

在所述步骤S81中，所述注销事由材料可以但不限于包含有所述保函申请订单的订单编号或所述保函信息的保函编号，以便实现与所述保函信息的绑定对应。

S82.将所述注销事由材料推送至所述担保机构端，以便所述担保机构端对所述注销事由材料进行审批，并在审批通过后将所述注销事由材料推送至所述银行端，进一步以便所述银行端对所述注销事由材料进行审批，并在审批通过后反馈注销完成指示信息。

在所述步骤S82中，所述担保机构端或所述银行端对所述注销事由材料进行的审批，同样可以是根据预设风控模型进行的流程化自动审批或人工审批。若审批未通过，将反馈注销审批未通过指示信息，以便告知所述投标方，本次注销申请失败。

S83.在收到由所述银行端反馈的所述注销完成指示信息后，获取所述经办银行授予所述担保机构的当前剩余授信额度，然后将该当前剩余授信额度更新为在加上所述保函金额后的新额度值。

由此基于前述步骤S81～S83所描述的可能设计三，不但可以在出函后进行主动的电子投标保函注销流程服务，进一步利于实现在线开立电子投标保函等流程线上化的目的，还可以在主动注销所述第一电子投标保函时，自动释放所述担保机构的授信额度，以便承接下一个投标担保业务，保障所述担保机构的正常营业。此外，为了实时且准确地更新所述保函申请订单的订单状态，可在收到所述注销完成指示信息时，将所述订单状态更新为已注销状态。

本实施例在前述第一方面、可能设计一、二或三的技术方案基础上，还提供了一种如何对分离式电子投标保函进行理赔的可能设计四，即在将所述第一电子投标保函推送至所述招投标交易中心之后，所述方法还包括但不限于有如下步骤S91～S94。

S91.将所述保函申请订单的状态更新为已出函状态。

S92.接收来自所述招投标交易中心的且由招标方在中标后发起的电子保函理赔申请，其中，所述电子保函理赔申请的内容包含有与所述保函申请订单对应的理赔事由材料。

在所述步骤S92中，所述理赔事由材料可以但不限于包含有所述保函申请订单的订单编号或所述保函信息的保函编号，以便实现与所述保函申请订单的绑定对应。

S93.将所述理赔事由材料推送至所述担保机构端，以便所述担保机构端对所述理赔事由材料进行审批，并在审批通过后将所述理赔事由材料推送至所述银行端，进一步以便所述银行端对所述理赔事由材料进行审批，并在审批通过且完成线下理赔支付动作后反馈理赔完成指示信息。

在所述步骤S93中，所述担保机构端或所述银行端对所述理赔事由材料进行的审批，同样可以是根据预设风控模型进行的流程化自动审批或人工审批。若审批通过，可由所述银行端进行线下理赔支付动作，将等于所述保函金额的资金赔付给所述招标方；而若审批未通过，将反馈理赔失败指示信息，此时将不进行任何形式的线下理赔支付动作。

S94.在收到由所述银行端反馈的所述理赔完成指示信息后，将所述保函申请订单的状态更新为已理赔状态，并向所述招投标交易中心反馈理赔申请成功信息。

由此基于前述步骤S91～S94所描述的可能设计四，还可以在出函后进行电子投标保函理赔流程服务，进一步利于实现在线开立电子投标保函等流程线上化的目的。此外，在收到由所述银行端反馈的所述理赔完成指示信息后，由于是理赔动作的成功完成，此时将不释放所述担保机构的授信额度，以保障银行方的利益。

本实施例在前述第一方面、可能设计一、二、三或四的技术方案基础上，还提供了一种如何对直开式电子投标保函进行出函的可能设计五，即所述方法还包括但不限于有如下步骤S101～S104。

S101.当所述保函产品信息中指定的保函开立模式为直开式保函开立模式时，向所述招投标交易中心推送携带有所述保函金额的第二支付请求，以便所述投标方在所述招投标交易中心响应所述第二支付请求，向所述经办银行支付等于所述保函金额的资金。

S102.在收到来自所述招投标交易中心的且响应所述第二支付请求的支付成功信息后，将所述保函申请订单推送至与所述经办银行对应的银行端，以便所述银行端对所述保函申请订单进行审批，并在审批通过后应用契约锁在根据所述保函申请订单生成的第二待签电子文件上加盖电子签章，得到第二电子投标保函。

S103.接收由所述银行端出具的所述第二电子投标保函。

S104.将所述第二电子投标保函推送至所述招投标交易中心，以便反馈给所述投标方。

前述步骤S101～S104的具体过程可参考前述步骤S3～S7直接推导得到，于此不再赘述。针对所述第二电子投标保函进行的中途在线退保和理赔的具体过程，也可以参考前述可能设计一和四的技术方案推导得到，于此不再赘述。此外，所述本地云服务器还可以响应所述担保机构端或所述银行端的查询请求和/或统计请求等请求，向其反馈所查询保函申请订单的订单详情及基于所有订单详细的统计结果；以及还可以针对所述招投标交易中心进行渠道信息(具体包含但不限于有渠道编码、渠道名称、渠道类型、渠道状态、经办银行、联系人姓名及手机号和保函产品信息等)的管理以及针对所述招标方或所述投标方进行客户信息(具体包含但不限于有企业名称、企业地址、统一信用代码、企业类型、注册资本、营业执照到期日、经办人姓名、经办人手机号、法人代表姓名、法人身份证号，法人手机号、营业执照图像和法人身份证正反面图像等)的管理；以及还可以为所述担保机构端或所述银行端进行权限角分配，从而提升本实施例所述电子投标保函服务方法的实用性。

如图2所示，本实施例第二方面提供了一种实现第一方面或第一方面中任意可能设计的所述电子投标保函服务方法的虚拟装置，包括有申请接收模块、订单生成模块、保费计算模块、支付推送模块、订单推送模块、保函接收模块和保函推送模块；

所述申请接收模块，用于接收来自招投标交易中心的且由投标方发起的电子保函开立申请，其中，所述电子保函开立申请的内容包含有标段信息、投标方信息和由所述投标方指定的保函产品信息；

所述订单生成模块，通信连接所述申请接收模块，用于根据所述电子保函开立申请的内容生成保函申请订单，其中，所述保函申请订单包含有保函信息和所述投标方信息，所述保函信息包含有经办银行和保函金额，所述经办银行在所述保函产品信息中指定，所述保函金额等于所述标段信息中的担保金额；

所述保费计算模块，通信连接所述申请接收模块，用于当所述保函产品信息中指定的保函开立模式为分离式保函开立模式时，根据所述保函金额以及与所述保函产品信息中指定的担保机构对应的保费收取比率/和保费收取最低金额，计算得到保费金额；

所述支付推送模块，通信连接所述保费计算模块，用于向所述招投标交易中心推送携带有所述保费金额的第一支付请求，以便所述投标方在所述招投标交易中心响应所述第一支付请求，向所述担保机构支付等于所述保费金额的资金；

所述订单推送模块，通信连接所述订单生成模块，用于在收到来自所述招投标交易中心的且响应所述第一支付请求的支付成功信息后，将所述保函申请订单推送至与所述担保机构对应的担保机构端，以便所述担保机构端对所述保函申请订单进行审批，并在审批通过后根据所述保函申请订单生成第一待签电子文件，然后将所述保函申请订单和所述第一待签电子文件推送至与所述经办银行对应的银行端，进一步以便所述银行端对所述保函申请订单进行审批，并在审批通过后应用契约锁在所述第一待签电子文件上加盖电子签章，得到第一电子投标保函；

所述保函接收模块，用于接收由所述银行端出具的所述第一电子投标保函；

所述保函推送模块，通信连接所述保函接收模块，用于将所述第一电子投标保函推送至所述招投标交易中心，以便反馈给所述投标方。

本实施例第二方面提供的前述装置的工作过程、工作细节和技术效果，可以参见第一方面或第一方面中任意可能设计的所述电子投标保函服务方法，于此不再赘述。

如图3所示，本实施例第三方面提供了一种执行第一方面或第一方面中任意可能设计的所述电子投标保函服务方法的计算机设备，包括有依次通信连接的存储器、处理器和收发器，其中，所述存储器用于存储计算机程序，所述收发器用于收发消息，所述处理器用于读取所述计算机程序，执行如第一方面或第一方面中任意可能设计的所述电子投标保函服务方法。具体举例的，所述存储器可以但不限于包括随机存取存储器(Random-AccessMemory，RAM)、只读存储器(Read-Only Memory，ROM)、闪存(Flash Memory)、先进先出存储器(First Input First Output，FIFO)和/或先进后出存储器(First Input Last Output，FILO)等等；所述收发器可以但不限于为WiFi(无线保真)无线收发器、蓝牙无线收发器、GPRS(General Packet Radio Service，通用分组无线服务技术)无线收发器和/或ZigBee(紫蜂协议，基于IEEE802.15.4标准的低功耗局域网协议)无线收发器等；所述处理器可以但不限于采用型号为STM32F105系列的微处理器。此外，所述计算机设备还可以但不限于包括有电源模块、显示屏和其它必要的部件。

本实施例第三方面提供的前述计算机设备的工作过程、工作细节和技术效果，可以参见第一方面或第一方面中任意可能设计的所述电子投标保函服务方法，于此不再赘述。

本实施例第四方面提供了一种存储包含第一方面或第一方面中任意可能设计的所述电子投标保函服务方法的指令的计算机可读存储介质，即所述计算机可读存储介质上存储有指令，当所述指令在计算机上运行时，执行如第一方面或第一方面中任意可能设计的所述电子投标保函服务方法。其中，所述计算机可读存储介质是指存储数据的载体，可以但不限于包括软盘、光盘、硬盘、闪存、优盘和/或记忆棒(Memory Stick)等，所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。

本实施例第四方面提供的前述计算机可读存储介质的工作过程、工作细节和技术效果，可以参见第一方面或第一方面中任意可能设计的所述电子投标保函服务方法，于此不再赘述。

本实施例第五方面提供了一种包含指令的计算机程序产品，当所述指令在计算机上运行时，使所述计算机执行如第一方面或第一方面中任意可能设计的所述电子投标保函服务方法。其中，所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。

最后应说明的是，本发明不局限于上述可选的实施方式，任何人在本发明的启示下都可得出其他各种形式的产品。上述具体实施方式不应理解成对本发明的保护范围的限制，本发明的保护范围应当以权利要求书中界定的为准，并且说明书可以用于解释权利要求书。