CN113763140A - 一种招投标方法及相关装置 - Google Patents

Abstract

本申请公开了一种招投标方法及相关装置，该方法包括：投标方节点获取招标方节点发布的招标要求信息，并基于招标要求信息确定保证金方案；基于保证金方案确定目标保额，并基于目标保额生成保险申请，其中，目标保额是招标方节点根据招标项目总额确定的保险投保的保额；将保险申请发送至至少一个保险服务方节点；基于保险服务方节点的反馈信息，确定目标保险服务方节点以及目标保险服务方节点提供的保险服务，其中，保险服务的保额大于或等于目标保额。本申请所提供的技术方案，可以较好地实现减少企业在投标过程中的现金占用比例。

Description

一种招投标方法及相关装置

技术领域

本申请涉及招投标技术领域，特别是涉及一种招投标方法及相关装置。

背景技术

但是在现有的投标期间以及合同执行期间，由于投标方需要大量的现金缴纳保证金，这样就会占用投标方较大比例的现金流，会使得投标方存在较大的资金风险，同时会进一步使得招标方同样面临风险。故需要一种可以解决上述技术问题的方案。

发明内容

本申请主要解决的技术问题是提供一种招投标方法及相关装置，可以实现减少企业在招投标过程中的现金占用比例。

为解决上述技术问题，本申请采用的一个技术方案是：提供一种招投标方法，所述方法包括：

投标方节点获取招标方节点发布的招标要求信息，并基于所述招标要求信息确定保证金方案；

基于所述保证金方案确定目标保额，并基于所述目标保额生成保险申请，其中，所述目标保额是所述招标方节点根据招标项目总额确定的保险投保的保额；

将所述保险申请发送至至少一个保险服务方节点；

基于所述保险服务方节点的反馈信息，确定目标保险服务方节点以及所述目标保险服务方节点提供的保险服务，其中，所述保险服务的保额大于或等于所述目标保额。

为解决上述技术问题，本申请采用的另一个技术方案是：提供一种招投标方法，所述方法包括：

接收投标方节点的保险申请；

基于所述保险申请，确定目标保额和保险要求；

根据所述目标保额和所述保险要求，生成申请答复函；

将所述申请答复函发送至投标方节点。

为解决上述技术问题，本申请采用的又一个技术方案是：提供一种招投标联盟区块链，所述联盟区块链包括：所述招标方节点、所述投标方节点和所述保险服务方节点；其中，

所述招标方节点用于发布招标要求信息；

所述投标方节点用于获取所述招标方节点发布的招标要求信息，并基于所述招标要求信息确定保证金方案；然后基于所述保证金方案确定目标保额，并基于所述目标保额生成保险申请，其中，所述目标保额是所述招标方节点根据招标项目总额确定的保险投保的保额；所述投标方节点还用于将所述保险申请发送至至少一个保险服务方节点；再基于所述保险服务方节点的反馈信息，确定目标保险服务方节点以及所述目标保险服务方节点提供的保险服务，其中，所述保险服务的保额大于或等于所述目标保额；

所述保险服务方节点用于接收投标方节点的保险申请；并基于所述保险申请，确定所述目标保额和保险要求；然后根据所述目标保额和所述保险要求，生成申请答复函，并将所述申请答复函发送至投标方节点。

为解决上述技术问题，本申请采用的又一个技术方案是：提供一种电子设备，所述电子设备包括处理器以及与所述处理器耦接的存储器和通信电路；其中，

所述存储器用于存储计算机程序；

所述通信电路用于在所述处理器的控制下与外部的电子设备交互；

所述处理器用于运行所述计算机程序以执行如上任意一项所述的方法。

为解决上述技术问题，本申请采用的再一个技术方案是：提供一种计算机可读存储介质，所述计算机可读存储介质存储有能够被处理器运行的计算机程序，所述计算机程序用于实现如上任意一项所述的方法。

本申请的有益效果是：区别于现有技术的情况，本申请所提供的技术方案中，投标方节点在进行投标时，通过获取招标方节点发布的招标要求信息，并基于招标要求信息确定保证金方案，然后基于所确定的保证金方案确定目标保额，并基于目标保额生成保险申请，并将保险申请发送至至少一个保险服务方节点，以基于保险服务方节点的反馈信息，确定目标保险服务方节点以及目标保险服务方节点提供的保险服务，即在本申请所提供的招投标过程中，通过与提供保险服务的保险服务方节点合作，实现使得投标方无需依赖繁琐的操作，也无需投入过多人力成本的情况下即可快速确定目标保险节点，进而获得目标保险服务方节点提供的保险服务；同时通过与目标保险服务方节点的合作，在整个招投标过程中引入包括保险的保证金方案，相比于现有技术单独依靠现金来向投标方提供保证金的技术方案，本申请所提供的技术方案实现降低投标节点在投标过程中对于现金的依赖，进而实现减少企业在招投标过程中的现金占用比例，起到了良好的技术效果。

附图说明

图1为本申请一种招投标联盟区块链结构示意图；

图2为本申请一种招投标方法一实施例中的流程示意图；

图3为本申请一种招投标方法另一实施例中的流程示意图；

图4为本申请一种招投标方法又一实施例中的流程示意图；

图5为本申请一种招投标方法一实施例中的流程示意图；

图6为本申请一种招投标方法另一实施例中的流程示意图；

图7为本申请一种电子设备一实施例中的结构示意图；

图8为本申请一种计算机可读存储介质一实施例结构示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述。可以理解的是，此处所描述的具体实施例仅用于解释本申请，而非对本申请的限定。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

本申请的描述中，“多个”的含义是至少两个，例如两个，三个等，除非另有明确具体的限定。此外，术语“包括”和“具有”以及它们任何变形，意图在于覆盖不排他的包含。例如包含了一系列步骤或单元的过程、方法、系统、产品或设备没有限定于已列出的步骤或单元，而是可选地还包括没有列出的步骤或单元，或可选地还包括对于这些过程、方法、产品或设备固有的其它步骤或单元。

在本文中提及“实施例”意味着，结合实施例描述的特定特征、结构或特性可以包含在本申请的至少一个实施例中。在说明书中的各个位置出现该短语并不一定均是指相同的实施例，也不是与其它实施例互斥的独立的或备选的实施例。本领域技术人员显式地和隐式地理解的是，本文所描述的实施例可以与其它实施例相结合。

为了便于理解本申请所提供的技术方案，首先阐述本申请所提供的招投标联盟区块链。请参见图1，图1为本申请一种招投标联盟区块链结构示意图。在当前实施例中，按照招投标过程中各个企业的功能进行划分，本申请所提供的招投标联盟区块链100包括：招标方节点102、投标方节点101、保险服务方节点103和平台运营方节点104。

其中，招标方节点102是招标方在招投标联盟区块链100中布置的、用于发布招标要求信息，以通知招投标联盟区块链100中的节点自身有项目正在进行招标的节点。其中，招标方是指在招标投标活动(也可以简称为招投标活动)中以择优选择中标人为目的提出招标项目、进行招标的法人或者其他组织。

投标方是响应招标、参加投标竞争的法人或其他组织，投标方节点101是投标方在招投标联盟区块链100中布置的、用于获取招标方节点102发布的招标要求信息，并基于招标要求信息确定保证金方案的节点。投标方节点101还用于基于保证金方案确定目标保额，并基于目标保额生成保险申请，投标方节点101还用于将保险申请发送至至少一个保险服务方节点103，再基于保险服务方节点103的反馈信息，确定目标保险服务方节点103以及目标保险服务方节点103所提供的保险服务。其中，目标保额是招标方节点102根据招标项目总额确定的保险投保的保额，并且投标方最终确定的目标保险服务方节点103所提供的保险服务的保额大于或等于目标保额，以选择所提供保额符合要求的目标保险服务方节点103。

保险服务方是用于为投标方提供保险服务的机构或组织，保险服务方节点103是保险服务方在招投标联盟区块链100中布置的、用于接收投标方节点101的保险申请的节点。进一步地，保险服务方节点103同时还用于基于保险申请，确定目标保额和保险要求，然后根据目标保额和保险要求，生成申请答复函，并将申请答复函发送至投标方节点101，以供投标方节点101进行挑选目标保险服务方节点103。

其中，需要说明的是，招标方节点102、投标方节点101和保险服务方节点103在加入至招投标联盟区块链100时，各个节点各自是需要将各自的营业执照、法人代表信息、企业法人和企业征信信息(其中，企业法人和企业征信信息是中国人民银行征信中心提供的)等提交到招投标联盟区块链100中的平台运营方节点104，由平台运营方节点104对各个节点所提交的信息进行信息审核。如若平台运营方节点104在审核过程中发现某一节点的信息存在问题，则不予通过；反之，如若平台运营方节点104在审核过程中未发现问题，则给予通过，此时平台运营方节点104同意当前申请的节点(此处节点包括招标方节点102、投标方节点101或保险服务方节点103中的任意一个)可作为招投标联盟区块链100的一个节点加入至其中。

进一步地，经过平台运营方节点104审核通过后的节点还需要经过第三方CA认证服务机构(其中，第三方CA认证服务机构包括中国金融认证中心)进行身份认证，如若认证通过则第三方CA认证服务机构会给通过身份认证节点颁发数字证书。其中，数字证书包括一对公私钥。另外，关于招投标联盟区块链100中的各个节点的具体功能，可以参见下文对应部分的阐述，在此不做详细阐述。其中，运营方为用于运行联盟区块链的一方，运营平台方节点为运行联盟区块链的一方在联盟区块链中的节点，如当运行联盟区块链为招标方，则对应的，平台运营方节点104和招标方节点101为同一个节点。在一些实施例中，平台运营方节点104可以是由联盟区块链中的任意一个节点所对应的企业运行和/或所有，如可以是招标方节点101，也可以是图1未示意的招标代理方节点。

请参见图2，图2为本申请一种招投标方法一实施例中的流程示意图。在当前实施例中，本申请所提供的方法包括：

S210：投标方节点获取招标方节点发布的招标要求信息，并基于招标要求信息确定保证金方案。

投标方在对某个项目进行投标时，投标方节点首先会获取招标方节点所发布的招标要求信息，然后基于所获取的招标要求信息确定保证金方案。其中，招标要求信息为招标方在对某个项目进行招标时对外发布的信息，具体至少包括招标项目的名称、项目期限、对投标方的要求、保证金方案等，保证金方案是指招标方所提出的保证金缴纳方案。其中，保证金是投标方在投标某个项目时，所需要预先缴纳的费用和/或保险，保证金具体是用于按照招标要求信息所要求的向招标方出具的、以一定金额和/或保险表示的投标责任担保。保证金的实质是为了避免因投标方在投标有效期内随意撤回、撤销投标或中标后不能提交履约保证金和签署合同等行为而给招标方造成损失。

进一步地，在本申请所提供的技术方案中，保证金包括目标保额的保险和/或现金保证金。如在另一实施例中，招标方可以设置保证金方案为：需要投标方购买目标保额的保险，同时并缴纳与目标保额匹配的现金保证金。

再进一步地，在又一实施例中，当招标方设置保证金方案为：需要投标方购买目标保额的保险的同时，并缴纳与目标保额匹配的现金保证金时，投标方可以设置多种不同目标额度保险与现金搭配的保证金方案，以供投标方在投标时根据自身的需求在多种方案中选择。比如，保证金方案可以包括A、B和C三种方案，A方案为购买目标保额为100万的商业保险，并配合缴纳50万现金保证金；B方案为购买目标保额为80万的商业保险，并配合缴纳70万现金保证金；C方案为购买目标保额为50万的商业保险，并配合缴纳100万现金保证金。

更进一步地，根据招标方的需求，保证金包括投标保证金、履约保证金、质量保证金。则对应的，招标方节点可以根据自身的需求和招标项目的要求，为每种不同类型的保证金设置不同目标保额的保险。如，可以根据需求设置每种类型的缴纳方案均是购买目标保额及以上的商业保险，并缴纳与目标保额及以上的保险匹配的现金保证金。其中，可以设置每种类型保证金所对应的缴纳方案中的保险额度相同或不相同，在此不做限定。如，根据项目进行的各个阶段的风险不同，设置投标保证金的缴纳方案为购买目标保额为50万的商业保险，并配合缴纳20万现金保证金，设置履约保证金的缴纳方案为购买目标保额为80万的商业保险，并配合缴纳30万现金保证金，设置质量保证金的缴纳方案为购买目标保额为100万的商业保险，并配合缴纳50万现金保证金。

在另一实施例中，招标方也可以根据自身需求，部分类型保证金的缴纳方案为全部现金缴纳，部分类型保证金的缴纳方案为购买目标保额的商业保险和缴纳与目标保额的商业保险匹配的现金保证金。如，设置投标保证金和履约保证金的缴纳方案为缴纳全额现金保证金，质量保证金的缴纳方案为购买目标保额及以上的商业保险，并缴纳与目标保额及以上的商业保险所匹配的现金保证金。

如，在一些实施例中，招标方可以设置保证金方案为：只需要投标方购买目标保额的保险服务即可。其中，目标保额是招标方根据项目总标的以及项目价值确定的，也可以是由招标方以及第三方评估机构对招标项目共同评估确定的。

进一步地，招标方节点是将招标要求信息上链存储至联盟区块链上，故投标方节点是自联盟区块链上获取招标方节点发布的招标要求信息，然后再基于招标要求信息确定保证金方案。

S220：基于保证金方案确定目标保额，并基于目标保额生成保险申请。

其中，目标保额是招标方节点根据招标项目总额确定的保险投保的保额，即是招标方节点根据招标项目总额和风险确定的、需要投标方购买的保险的保额。

在投标方节点获取招标方节点发布的招标要求信息，并基于招标要求信息确定保证金方案之后，投标方节点进行一步基于保证金方案确定目标保额，并基于所获取的目标保额生成保险申请。其中，保险申请中包括投标方的基本信息、目标保额、意欲投标的项目的基本信息。

S230：将保险申请发送至至少一个保险服务方节点。

在基于目标保额生成保险申请之后，进一步将保险申请发送至至少一个保险服务方节点。

进一步地，投标方节点可以是直接点对点地将保险申请发送至联盟区块链中的至少一个保险服务方节点，以获取至少一个保险服务方节点反馈的申请答复函。

进一步地，在另一实施例中，投标方节点可以是直接将保险申请发送至平台运营方节点，以使得平台运营方节点将保险申请发送至至少一个保险服务方节点。在当前实施例中，通过将保险申请发送至平台运营方节点，使得平台运营方节点根据预先设定的规则将所接收到的保险申请发送至至少一个保险服务方节点。其中，预先设定的规则至少包括发送至信用评分排名前n名的保险服务方节点。其中，n为大于等于1的自然数。

进一步地，在又一实施例中，投标方节点可以是将保险申请发送至联盟区块链上，使得联盟区块链内的至少一个保险服务方节点通过访问联盟区块链获取到该保险申请，或者是直接利用联盟区块链的一致性特点使得至少一个保险服务方节点获取到该保险申请。

S240：基于保险服务方节点的反馈信息，确定目标保险服务方节点以及目标保险服务方节点提供的保险服务。

其中，保险服务方节点的反馈信息至少包括申请答复函。投标方节点在将保险申请发送至保险服务方节点之后，保险服务方节点获取到保险申请之后，进一步基于保险申请确定目标保额和保险要求，然后根据目标保额和保险要求生成申请答复函，然后将申请答复函发送至投标方节点，投标方节点则进一步基于申请答复函确定目标保险服务方节点以及目标保险服务方节点提供的保险服务。其中，目标保险服务方节点为最终为投标方提供保险服务的保险服务方节点。

其中，保险服务的保额大于或等于目标保额。即在本申请所提供的技术方案中，目标保险服务方节点所提供的保险服务的保额是大于或等于目标保额，以为投标方节点提供符合招标方节点要求的保险服务。

本申请图2所提供的技术方案，投标方节点在进行投标时，通过获取招标方节点发布的招标要求信息，并基于招标要求信息确定保证金方案，然后基于所确定的保证金方案确定目标保额，并基于目标保额生成保险申请，并将保险申请发送至至少一个保险服务方节点，以基于保险服务方节点的反馈信息，确定目标保险服务方节点以及目标保险服务方节点提供的保险服务，即在本申请所提供的招投标过程中，通过与提供保险服务的保险服务方节点合作，实现使得投标方无需依赖繁琐的操作，也无需投入过多人力成本的情况下即可快速确定目标保险节点，进而获得目标保险服务方节点提供的保险服务；同时通过与目标保险服务方节点的合作，在整个招投标过程中引入包括保险的保证金方案，相比于现有技术单独依靠现金来向投标方提供保证金的技术方案，本申请所提供的技术方案实现降低投标节点在投标过程中对于现金的依赖，进而实现减少企业在招投标过程中的现金占用比例。

请参见图3，图3为本申请一种招投标方法另一实施例中的流程示意图。在当前实施例中，本申请所提供的方法包括步骤S301至步骤S307。具体如下：

S301：投标方节点获取招标方节点发布的招标要求信息，并基于招标要求信息确定保证金方案。

S302:基于保证金方案确定目标保额，并基于目标保额生成保险申请。

在当前实施例中，步骤S301至步骤S302与上文所述的步骤S310至步骤S220相同，具体可以参见上文对应部分的阐述，在此不再赘述。在当前实施例中，在上述步骤S230将保险申请发送至至少一个保险服务方节点之前，本申请所提供的方法进一步包括步骤S303。

S303：将保险申请发送至平台运营方节点，并接收平台运营方节点根据保险申请向投标方节点推送至少一个保险服务方节点。

在当前实施例中，可以是由平台运营方节点向投标方节点推送保险服务方节点，故在投标方节点基于保证金方案确定目标保额，并基于目标保额生成保险申请之后，投标方节点进一步会将保险申请发送至平台运营方节点，以使得平台运营方节点根据投标方所发送的保险申请向投标方节点推送至少一个保险服务方节点。具体地，投标方节点可以在操作平台上生成保险申请，平台运营方节点在获取到投标方节点在操作平台上生成的保险申请之后，进一步响应保险申请为投标方节点推送至少一个保险服务方节点。其中，操作平台为用于处理业务的前端网页，具体也可以理解为是由平台运营方节点的前端网页。

投标方在发送保险申请之后，还用于接收平台运营方节点根据保险申请向投标方节点推送至少一个保险服务方节点。其中，在此对平台运营方节点推送的保险服务方节点的数量不做限定，具体依据实际的设置为准。如上所述，平台运营方节点为管理平台网页的节点，在当前实施例中平台运营方可以为运行联盟区块链的企业在联盟链中所对应的节点。

进一步地，若经过执行步骤S303，且投标方节点接收到平台运营方节点推送的多个保险服务方节点时，则上述步骤S230进一步包括S304至步骤S305。

S304：根据多个保险服务方节点的信用评分，自多个保险服务方节点中选取预设数量的候选保险服务方节点。

在投标方节点接收到平台运营方节点推送的多个保险服务方节点时，则投标方节点进一步自联盟区块链上获取多个平台运营方节点推送的多个保险服务方节点的信用评分，并根据所接收到的多个保险服务方节点的信用评分，自多个保险服务方节点中选取预设数量的候选保险服务方节点。其中，保险服务方节点的信用评分是用于评价保险服务方节点所提供保险服务的一个信用评价指标，具体可以是根据保险服务方节点的各个客户反馈获得，且可以是由平台运营方节点基于各个客户反馈计算求得保险服务方节点的信用评分。在其他实施例中，各个保险服务方节点的信用评分是存储于联盟区块链上的，以便于投标方节点或平台运营方节点获取。在其他实施例中，各个保险服务方节点的信用评分是预先设定的第三方机构基于该保险服务方节点的客户反馈计算求得并存储于平台运营方节点的。

进一步地，投标方节点是根据多个保险服务方节点的信用评分由高至低的排名，自多个保险服务方节点中选取预设数量的候选保险服务方节点，然后再执行下述步骤S305以将保险申请分别发送至各个候选保险服务方节点。其中，候选保险服务方节点为投标方节点意欲合作的保险服务方节点(在其他实施例中，也可以将候选保险服务方节点理解为接收到投标方节点所发送的保险申请的保险服务方节点)。

更进一步地，在又一实施例中，平台运营方节点在根据保险申请向投标方节点推送至少一个保险服务方节点时，同时会将所推送的保险服务方节点的信用评分打包发送给投标方节点，以使得投标方节点可以快速获取到保险服务方节点的信用评分，进而无需再额外花费时间获取各个保险服务方节点的信用评分。在当前实施例中，通过根据保险服务方节点的信用评分，选取候选保险服务方节点，可以实现较为快速地从服务更为优越的保险服务方节点中选取目标保险服务方节点。

S305：将保险申请分别发送至候选保险服务方节点。

在当前实施例中，步骤S305与上述步骤S230相同，具体可以上文对应部分的阐述，在此不再赘述。

则上述步骤S240基于保险服务方节点的反馈信息，确定目标保险服务方节点，进一步包括步骤S306至步骤S307。

S306：接收候选保险服务方节点响应于保险申请的申请答复函。

在将保险申请分别发送至候选保险服务方节点之后，投标方节点进一步接收候选保险服务方节点响应于保险申请的申请答复函。其中，申请答复函是由保险服务方节点所发送的，用以回复保险申请的信函。申请答复函中至少包括：保险服务方节点是否可以承接该目标保额的保险。

更进一步地，在另一实施例中，申请答复函中还可以包括：保险服务方节点是否可以承接该目标保额的保险、如若承接该目标保额的保险时的具体承接方案(若某一保险服务方节点不承接该目标保额的保险，则申请答复函中可以不包括该点内容)。其中，承接方案中至少包括：投标方节点在购买目标保额及以上的保险服务时，所需要付的具体价格(即购买保险所需的费用)。

进一步地，在另一实施例中，步骤S306进一步包括：等候设定时间，以接收候选保险服务方节点响应于保险申请的申请答复函。在当前实施例中，为了避免一些候选保险服务方节点迟迟没有回复而一直等待，故在当前实施例中，进一步设置投标方节点只等候设定时间长度，如若在等候了设定时间长度之后，尚未接收到一些候选保险方服务节点的申请答复函，则认为该候选保险服务方节点自动放弃答复投标方节点的保险申请，此时只需要基于所接收到的所有的申请答复函，确定目标保险服务方节点即可。

进一步地，在又一实施例中，如若等候设定时间之后，投标方节点尚未接收一个候选保险服务方节点响应于保险申请的申请答复函，则本申请所提供的方法还包括：重新将保险申请分别发送至候选保险服务方节点。

在其他实施例中，如若等候设定时间之后，投标方节点尚未接收一个候选保险服务方节点响应于保险申请的申请答复函，本申请所提供的方法还包括，投标方节点检测自身的网络是否正常，如若检测得到当前的网络正常，则重新将保险申请分别发送至候选保险服务方节点；如若检测得到当前的网络异常，则提示用户对网络进行维护检修。

在再一实施例中，如若等候设定时间之后，投标方节点尚未接收一个候选保险服务方节点响应于保险申请的申请答复函，且在自身网络正常的情况下，则本申请所提供的方法进一步包括：重新执行上述步骤S304，即重新根据多个保险服务方节点的信用评分，自多个保险服务方节点中选取候选保险服务方节点，且当前选取的候选保险服务方节点与上一轮所选取的候选保险服务方节点不同。

在其他实施例中，在重新选取候选保险服务方节点时，也可以是基于不同的选取规则选取候选保险服务方节点，以选取与上一轮不完全相同的候选保险服务方节点。其中，不同的选取规则是指的，如若第一轮是基于根据多个保险服务方节点的信用评分排名的高低顺序依次选取候选保险服务方节点，则第二轮选取时可以单纯的依据客户评价或者是赔付额度高低顺序，再或者是综合实力排序高低进行选取候选保险服务方节点。

S307：根据申请答复函，确定目标保险服务方节点。

在接收候选保险服务方节点响应于保险申请的申请答复函之后，进一步根据申请答复函，确定目标保险服务方节点。

其中，投标方节点基于各个候选保险服务方节点反馈的申请答复函，确定是有哪些候选保险服务方节点意欲与当前投标方节点合作，为当前投标方节点提供目标保额的保险服务。然后再根据意欲与投标方节点合作的候选保险服务方节点的答复函中提供的保险方案，进一步确定目标保险服务方节点。

更进一步地，可以是自所有意欲与当前投标方节点合作的候选保险服务方节点中，选取所提供的保险服务的保额最大的候选保险服务方节点作为目标保险服务方节点，即将所有意欲提供的保险服务的保额最高一个候选保险服务方节点选取作为目标保险服务方节点，并与目标保险服务节点签订保险合同。其中，目标保险服务方节点为投标方最终选取的、用于为自身提供目标保额及以上的保险服务的保险服务方节点。

在另一实施例中，也可以是自所有意欲与当前投标方节点合作的候选保险服务方节点中，选取所提供的保险服务的保额和保险价格(购买该保险的费用)综合考量，选取所提供保额大于或等于目标保额，且保险价格最低的候选保险服务方节点为目标保险服务方节点。

请参见图4，图4为本申请一种招投标方法又一实施例中的流程示意图。在当前实施例中，投标方节点所要求的保证金方案包括目标保额的保险和与目标保额的保险匹配的现金保证金。在当前实施例中，本申请所提供的方法包括步骤S401至步骤S407。

S401：投标方节点获取招标方节点发布的招标要求信息，并基于招标要求信息确定保证金方案。

在当前实施例中，步骤S401与上述步骤S210相同，具体可以参见上文对应部分的阐述，在此不再赘述，且在当前实施例中，在步骤S401中的基于招标要求确定保证金方案之后，本申请所提供的方法还包括：基于保证金方案确定现金保证金。

其中，现金保证金是招标方根据招标项目总额确定的，用于与目标保额匹配共同构成保证金。进一步地，当保证金包括多种类型保证金时，也可以设置每种类型保证金包括目标保额的保险和与目标保额的保险匹配的现金保证金。如当保证金包括投标保证金、履约保证金、质量保证金时，招标方节点可以设置投标保证金包括第一目标保额的保险和与第一目标保额的保险匹配的现金保证金，履约保证金可以包括第二目标保额的保险和与第二目标保额的保险匹配的现金保证金，质量保证金可以包括第三目标保额的保险和与第三目标保额的保险匹配的现金保证金。其中，第一目标保额、第二目标保额和第三目标保额具体是由招标方节点根据项目需求设定。

S402：基于保证金方案确定目标保额和现金保证金，并基于目标保额生成保险申请，并缴纳现金保证金。

在投标方节点获取招标方节点发布的招标要求信息，并基于招标要求信息确定保证金方案之后，进一步基于保证金方案确定目标保额和现金保证金，然后再基于目标保额生成保险申请，并向招标方节点缴纳现金保证金。

在其他实施例中，现金保证金也可以是在确定了目标保险服务方节点，并与目标保险服务方节点签订保险合同之后，再执行缴纳现金保证金的步骤，以避免在无法确定合适的目标保险服务方节点时放弃购买保险服务这一保证金方案，并更改为全额缴纳现金保证方案时，还需要重新更改缴纳现金保证金的额度。

S403：将保险申请发送至至少一个保险服务方节点。

S404：基于保险服务方节点的反馈信息，确定目标保险服务方节点以及目标保险服务方节点提供的保险服务。

在当前实施例中，步骤S403之步骤S404与上述步骤S230至步骤S240相同，具体可以参见上文对应部分的阐述，在此再重复赘述。

进一步地，在基于保险服务方节点的反馈信息，确定目标保险服务方节点以及目标保险服务方节点提供的保险服务之后，本申请所提供的方法还包括：步骤S405至步骤S406。

S405：获取缴纳现金保证金的交易记录和目标保险服务方节点提供保险服务的投标保险合同。

其中，缴纳现金保证金的交易记录为缴纳现金保证金的交易记录，具体可以包括银行转账凭证，缴纳现金保证金的交易记录是由银行或者是投标方提供并上传至联盟区块链上，投标保险合同包括目标保险服务方节点与投标方节点之间的保险合同和目标保险服务方节点与其他保险服务方节点之间的再保险合同。具体地，再保险合同为目标保险服务方节点在投标保险合同的基础上，与其他保险服务方节点之间签订的用于对自身所承担的风险进行投保的保险合同。

进一步地，目标保险服务方节点在为投标方提供大于或等于目标保额的保险服务之后，可以为了降低自身的风险，进一步为该保险服务购买保险，具体是通过向其他保险服务方节点购买保险服务。

再保险合同是保险服务方节点在自身与招标方节点之间的保险合同的基础上，与其他保险服务方节点所签订分保合同，具体是用于将其所承保的部分风险和责任向其他服务方节点进行保险的行为，这样就可以将一项招投标业务所面临的风险进行分摊，极大地降低了自身的风险。在再保险交易中，分出保险业务的保险服务方节点也可以被称为原保险人或分出公司，接受业务的其中保险服务方节点被称为再保险人或分保接受人或分入公司，再保险转嫁风险责任支付的保费称分保费或再保险费；原保险人在对外分出保险业务的过程中支出了一定的费用，由再保险人支付给原保险人的费用报酬称分保佣金或分保手续费。更进一步地，再保险人还可以将其接受的再保险业务再分保出去，这种再保险的分保合同叫做转分保合同，分出公司叫做转分人，接受公司叫做转分接受人，转分人收取的费用叫做转分手续费。如若，再保险人将其接受的再保险业务再分保出去，则对应的，步骤S406中获取的目标保险服务方节点提供保险服务的投标保险合同进一步包括：目标保险服务方节点与投标方节点之间的保险合同、目标保险服务方节点与其他保险服务方节点之间的再保险合同和转分保合同。

S406：基于现金保证金的交易记录和投标保险合同，向招标方节点发起投标。

在投标方节点确定了目标保险服务方节点，并与目标保险服务方节点之间签订了保险合同之后，投标方节点还会进一步获取缴纳现金保证金的交易记录和目标保险服务方节点提供保险服务的投标保险合同，然后基于投标方案、所获取的交易记录和投标保险合同，向招标方节点发起投标。其中，投标方案是投标方节点基于招标方的要求，所出具的针对项目的技术方案，具体可以包括项目设计方案、项目计划、投标金额、项目承办团队信息、项目原材料信息等等。

进一步地，本申请所提供的方法，在基于现金保证金的交易记录和投标保险合同，向招标方节点发起投标之后，本申请所提供的方法还包括：将现金保证金的交易记录和投标保险合同存储至联盟区块链，联盟区块链包括招标方节点、投标方节点、保险服务方节点和平台运营方节点。在当前实施例中，通过将现金保证金的交易记录和投标保险合同存储至联盟区块链，可以实现使得联盟区块链中任意节点在需要查阅现金保证金的交易记录和投标保险合同时，均可以通过直接访问联盟区块链直接获取到，同时联盟区块链的特性也可以较好地保证现金保证金的交易记录和投标保险合同被安全地存储。

请参见图5，图5为本申请一种招投标方法一实施例中的流程示意图。在当前实施例中，执行主体是保险服务方节点，本申请所提供的方法包括步骤S510至步骤S540。

S510：接收投标方节点的保险申请。

保险服务方节点接收到投标方节点发送的保险申请。其中，投标方节点的保险申请可以是投标方节点直接点对点发送至保险服务方节点的，也可以是通过平台运营方节点转发至保险服务方节点的，具体依据预先设定为准，在此不做特别限定。

其中，保险申请中包括期望申请的保险保额、申请保险的项目名称、申请保险的项目类型、申请保险的项目的参与方。项目的参与方至少包括投标方的名称、投标方承办该项目时的供应方、招标方的名称、项目总额等。其中，与投标方关联的供应方至少包括投标方完成该项目时所需要采购物资和/或服务的供应商。

S520：基于保险申请，确定目标保额和保险要求。

保险服务方节点在接收到投标方节点的保险申请之后，进一步基于所接收到的保险申请，从保险申请中确定目标保额和保险要求。其中，保险要求中至少包括保险服务方的资质要求、保险赔付形式等。

S530：根据目标保额和保险要求，生成申请答复函。

保险服务方基于保险申请确定目标保额和保险要求之后，如若判断得到自身符合保险要求中的资质要求，则进一步根据目标保额和保险要求生成申请答复函。

其中，申请答复函包括：是否承接保险申请和/或保险方案，保险方案包括以下至少一者：保险服务方节点为招标方节点出具的保险方案和其他保险服务方节点对保险服务方节点出具的针对保险方案的再保险方案。

进一步地，其他保险服务方节点对保险服务方节点出具的针对保险方案的再保险方案是基于再保险业务产生的。如若，保险服务方节点没有为当前的保险方案进行投保，则申请答复函中的保险方案可以不包括再保险方案。

S540：将申请答复函发送至投标方节点。

在生成申请答复函之后，进一步将申请答复函发送至投标方节点。

进一步地，在另一实施例中，保险服务方节点在生成申请答复函之后，保险服务方节点会将申请答复函发送至平台运营方节点，以使得平台运营方节点将申请答复函转发至投标方节点，以供投标方节点进行选择。

请参见图6，图6为本申请一种招投标方法另一实施例中的流程示意图。在当前实施例中，会进一步对投标方拟投保的项目进行风险评估，并基于评估所得的风险系数生成申请答复函。在当前实施例中，上述步骤S530根据目标保额和保险要求，生成申请答复函，进一步包括：步骤S601至步骤S603。

S601：获取投标方节点的经营信息。

保险服务方节点在基于保险申请，确定目标保额和保险要求之后，进一步获取投标方节点的经营信息。其中，经营信息至少包括：投标方的行业属性、投标方的企业性质、投标方的法人代表的个人征信情况、投标方的企业征信情况、投标方的净利润增长率、投标方的净资产收益率、投标方的流动比率、投标方的资产负债率、投标方所承办的项目的评价、投标方所承办的项目数量、投标方意欲投标项目的要求、投标方意欲投标项目的难度。

S602：根据经营信息，并结合目标保额和保险要求，计算保险申请的风险系数。

获取投标方节点的经营信息之后，保险服务方节点进一步根据经营信息，并结合目标保额和保险要求，计算保险申请的风险系数。其中，保险申请的风险系数是用于评价投标方承办当前项目的风险大小。

进一步地，保险申请的风险系数可以是基于经营信息中的各个信息，以及目标保额和保险要求的评分并求和获得。

进一步地，在另一实施例中，也可以是对经营信息中的各个信息，以及目标保额和保险要求按照预先设定的评分标准进行评分，然后对各项信息评分进行加权求和，经营信息中的各个信息，以及目标保额和保险要求评分的加权求和结果即输出为风险系数。

S603：根据风险系数、目标保额和保险要求，生成申请答复函。

在计算求得保险申请的风险系数之后，保险服务方节点进一步根据风险系数、目标保额和保险要求确定是否承接该保险申请，为投标方提供保险服务，并生成申请答复函。

如若根据风险系数、目标保额和保险要求，确定可以为投标方提供所需的保险服务，则进一步确定保险方案，并将保险方案和是否承接该保险申请打包至申请答复函中，然后将申请答复函发送至投标方节点。

同时需要说明的是，在上述各个实施例中所包括的各个技术特征不矛盾的情况下，可以根据实际的需求将各个实施例中的技术特征进行结合叠加，进而提供功能更为全面丰富的招投标方法。

请参见图7，图7为本申请一种电子设备一实施例中的结构示意图。在当前实施例中，本申请所提供的电子设备700包括处理器701以及与处理器701耦接的存储器702和通信电路703。电子设备700可以执行图2至图6及其对应的任意一个实施例中的方法。

其中，存储器702包括本地储存(图未示)，且存储有计算机程序，计算机程序被执行时可以实现图2至图6及其所对应的任意一个实施例中的方法。

处理器701与存储器702耦接，处理器701用于运行计算机程序，以执行如上图2至图6及其对应的任意一个实施例中的方法。

通信电路703在处理器701的控制下，用于与外部其他电子设备进行通信，以发送或接收数据。

进一步地，在一些实施例中，电子设备700可包括移动终端、电脑终端、计算机、具备计算存储能力的对讲设备，服务器等中的任意一种。更进一步地，电子设备700也可以是图1及其所对应的任意一个实施例所述的任意一个节点。

参见图8，图8为本申请一种计算机可读存储介质一实施例结构示意图。该计算机可读存储介质800存储有能够被处理器运行的计算机程序801，该计算机程序801用于实现如上图2至图6及其对应的任意一个实施例中所描述的方法。具体地，上述计算机可读存储介质800可以是存储器、个人计算机、服务器、网络设备，或者U盘等其中的一种，具体在此不做任何限定。

以上所述仅为本申请的实施方式，并非因此限制本申请的专利范围，凡是利用本申请说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本申请的专利保护范围内。

Claims (11)

1.一种招投标方法，其特征在于，所述方法包括：

投标方节点获取招标方节点发布的招标要求信息，并基于所述招标要求信息确定保证金方案；

基于所述保证金方案确定目标保额，并基于所述目标保额生成保险申请，其中，所述目标保额是所述招标方节点根据招标项目总额确定的保险投保的保额；

将所述保险申请发送至至少一个保险服务方节点；

基于所述保险服务方节点的反馈信息，确定目标保险服务方节点以及所述目标保险服务方节点提供的保险服务，其中，所述保险服务的保额大于或等于所述目标保额。

2.根据权利要求1所述的方法，其特征在于，所述将所述保险申请发送至至少一个保险服务方节点之前，所述方法还包括：

将所述保险申请发送至平台运营方节点，并接收所述平台运营方节点根据所述保险申请向投标方节点所推送的至少一个所述保险服务方节点。

3.根据权利要求2所述的方法，其特征在于，若接收所述平台运营方节点推送的多个所述保险服务方节点；所述将所述保险申请发送至至少一个保险服务方节点，进一步包括：

根据多个所述保险服务方节点的信用评分，自所述多个保险服务方节点中选取预设数量的候选保险服务方节点；

将所述保险申请分别发送至所述候选保险服务方节点；

所述基于所述保险服务方节点的反馈信息，确定目标保险服务方节点，包括：

接收所述候选保险服务方节点响应于所述保险申请的申请答复函；

根据所述申请答复函，确定目标保险服务方节点。

4.根据权利要求1所述的方法，其特征在于，所述将所述保险申请发送至至少一个保险服务方节点，进一步包括：

将所述保险申请发送至所述平台运营方节点，以使得所述平台运营方节点将所述保险申请发送至至少一个保险服务方节点。

5.根据权利要求1所述的方法，其特征在于，所述保证金方案包括所述目标保额的保险和与所述目标保额的保险匹配的现金保证金；

所述基于所述招标要求确定保证金方案之后，所述方法还包括：

基于所述保证金方案确定所述现金保证金，其中，所述现金保证金是所述招标方根据所述招标项目总额确定的；

所述基于所述保险服务方节点的反馈信息，确定目标保险服务方节点以及所述目标保险服务方节点提供的保险服务之后，所述方法还包括：

获取缴纳所述现金保证金的交易记录和所述目标保险服务方节点提供所述保险服务的投标保险合同；

基于所述现金保证金的交易记录和所述投标保险合同，向所述招标方节点发起投标。

6.根据权利要求5所述的方法，其特征在于，所述投标保险合同包括所述目标保险服务方节点与所述投标方节点之间的保险合同和所述目标保险服务方节点与其他保险服务方节点之间的再保险合同，其中，所述再保险合同为所述目标保险服务方节点在所述投标保险合同的基础上，与其他保险服务方节点之间签订的用于对自身所承担的风险进行投保的保险合同；

和/或，所述基于所述现金保证金的交易记录和所述投标保险合同，向所述招标方节点发起投标之后，所述方法还包括：将所述现金保证金的交易记录和所述投标保险合同存储至联盟区块链，所述联盟区块链包括所述招标方节点、所述投标方节点、所述保险服务方节点和平台运营方节点。

7.一种招投标方法，其特征在于，所述方法包括：

接收投标方节点的保险申请；

基于所述保险申请，确定目标保额和保险要求；

根据所述目标保额和所述保险要求，生成申请答复函；

将所述申请答复函发送至投标方节点。

8.根据权利要求7所述的方法，其特征在于，所述申请答复函包括：是否承接所述保险申请和/或保险方案，所述保险方案包括以下至少一者：所述保险服务方节点为所述招标方节点出具的保险方案和其他保险服务方节点对所述保险服务方节点出具的针对所述保险方案的再保险方案；

和/或，所述根据所述目标保额和所述保险要求，生成申请答复函，进一步包括：

获取投标方节点的经营信息；

根据所述经营信息，并结合所述目标保额和所述保险要求，计算所述保险申请的风险系数；

根据所述风险系数、所述目标保额和所述保险要求，生成所述申请答复函。

9.一种招投标联盟区块链，其特征在于，所述联盟区块链包括：所述招标方节点、所述投标方节点和所述保险服务方节点；其中，

所述招标方节点用于发布招标要求信息；

所述投标方节点用于获取所述招标方节点发布的招标要求信息，并基于所述招标要求信息确定保证金方案；然后基于所述保证金方案确定目标保额，并基于所述目标保额生成保险申请，其中，所述目标保额是所述招标方节点根据招标项目总额确定的保险投保的保额；所述投标方节点还用于将所述保险申请发送至至少一个保险服务方节点；再基于所述保险服务方节点的反馈信息，确定目标保险服务方节点以及所述目标保险服务方节点提供的保险服务，其中，所述保险服务的保额大于或等于所述目标保额；

所述保险服务方节点用于接收投标方节点的保险申请；并基于所述保险申请，确定所述目标保额和保险要求；然后根据所述目标保额和所述保险要求，生成申请答复函，并将所述申请答复函发送至投标方节点。

10.一种电子设备，其特征在于，所述电子设备包括处理器以及与所述处理器耦接的存储器和通信电路；其中，

所述存储器用于存储计算机程序；

所述通信电路用于在所述处理器的控制下与外部的电子设备交互；

所述处理器用于运行所述计算机程序以执行权利要求1至8任意一项所述的方法。

11.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有能够被处理器运行的计算机程序，所述计算机程序用于实现权利要求1至8任一项所述的方法。

Images