基于区块链的通信加密检索方法和系统与流程

1.本技术涉及业务信息管理技术领域，具体涉及一种基于区块链的通信加密检索方法和系统。


背景技术：

2.相关技术中，通信加密检索系统按规定获得电信业务接入号码和语音中继线路资源、短信通道资源，提供以接受用户主动呼入为主的信息咨询服务，确有需要的，通过合同、协议约定等方式，经用户同意后，方可提供即时回访和信息咨询等通信服务。对于需要进行用户呼叫或者下发短信的企业，通信加密检索应先进行企业备案，将用户授权的许可授权凭证进行记录。现有的通信加密检索系统加密检索手段较差，在转接企业对用户的通信行为时，很少考虑用户意愿，影响了用户体验。


技术实现要素：

3.为至少在一定程度上克服相关技术中通信加密检索系统加密检索手段较差的问题，本技术提供一种基于区块链的通信加密检索方法和系统。
4.根据本技术实施例的第一方面，提供一种基于区块链的通信加密检索方法，包括：
5.接收通信发起端向用户发送的通信请求；
6.判断所述通信请求的请求类型；
7.通过通信授权服务平台查询所述用户和所述通信发起端的许可状态；其中，所述许可状态记录在所述通信授权服务平台的区块链中；
8.根据所述请求类型和所述许可状态执行预设的通信方案。
9.进一步地，在所述接收通信发起端向用户发送的通信请求之前，所述方法还包括：
10.接收所述通信发起端和所述用户的通信许可数据；
11.调用所述通信授权服务平台业务接口，将所述通信许可数据上传到所述通信授权服务平台的区块链中进行记录；
12.根据所述通信许可数据生成存证哈希，并将所述存证哈希反馈给对应的通信发起端或用户。
13.进一步地，查询所述许可状态的步骤包括：
14.通信平台通过通信授权服务平台的查询接口，根据所述通信发起端的身份标识，查询对应的备案情况、业务备案情况；
15.根据所述用户的身份标识和存证哈希查询该存证哈希的状态，并返回给通信平台；
16.所述存证哈希的状态包括：是否允许、允许通信类型、是否有效。
17.进一步地，所述通信请求的请求类型包括：营销型通信服务和用户关怀型通信服务；
18.所述通信请求的请求类型，是所述通信发起端通过请求接口发起通信请求时，在
请求接口中选择的。
19.进一步地，所述根据所述请求类型和所述许可状态执行预设的通信方案，包括：
20.若所述请求类型为营销型通信服务，且所述许可状态为未许可，则拒绝执行所述通信请求；
21.若所述请求类型为营销型通信服务，且所述许可状态为已许可，则允许执行所述通信请求。
22.进一步地，所述根据所述请求类型和所述许可状态执行预设的通信方案，还包括：
23.若所述请求类型为用户关怀型外呼，则默认所述许可状态为已许可；
24.判断所述通信请求是否携带存证哈希；所述存证哈希是所述通信发起端和所述用户进行许可时生成的；
25.若所述通信请求中未携带所述存证哈希，则拒绝执行所述通信请求；
26.若所述通信请求中携带所述存证哈希，则允许执行所述通信请求。
27.进一步地，所述方法还包括：
28.在执行所述通信请求后，对所述通信请求中携带的所述存证哈希进行真实性查验，生成验真结果并记录；
29.根据各通信发起端的验真结果确定各个通信发起端的验真比例；
30.对所述验真比例低于预设验真比例值的通信发起端进行通信行为加密检索。
31.进一步地，真实性查验的步骤包括：
32.通信请求查询接口中携带所述通信发起端的身份标识、用户的身份标识、存证哈希；
33.根据通信发起端的身份标识，查询通信发起端的备案情况、业务备案情况；
34.根据用户的身份标识和存证哈希查询该存证哈希的状态，所述存证哈希的状态包括：是否允许、允许通信类型、是否有效；
35.若查询不到存证哈希，或者存证哈希的状态为不允许，或者允许通信类型不一致，或者存证哈希无效，则判断所属存证哈希为不真并记录在平台中。
36.进一步地，通信行为加密检索的步骤包括：
37.通信请求查询接口中携带所述通信发起端的身份标识、用户的身份标识、存证哈希；
38.根据通信发起端的身份标识，查询通信发起端的备案情况、业务备案情况；
39.根据用户的身份标识和存证哈希查询该存证哈希的状态，所述存证哈希的状态包括：是否允许、允许通信类型、是否有效；
40.若查询不到存证哈希，或者存证哈希的状态为不允许，或者允许通信类型不一致，或者存证哈希无效，则判断不允许执行通信请求，并将结果返回给通信平台；
41.查询过程通过https接口进行请求，保证网络安全。
42.根据本技术实施例的第二方面，提供一种基于区块链的通信加密检索系统，包括：
43.通信平台和通信授权服务平台；
44.所述通信平台包括：接收模块，判断模块，查询模块和执行模块；
45.所述接收模块用于接收通信发起端向用户发送的通信请求；
46.所述判断模块用于判断所述通信请求的请求类型；
47.所述查询模块用于通过通信授权服务平台查询所述用户和所述通信发起端的许可状态；其中，所述许可状态记录在所述通信授权服务平台的区块链中；
48.所述执行模块用于根据所述请求类型和所述许可状态执行预设的通信方案。
49.本技术的实施例提供的技术方案具备以下有益效果：
50.本技术的方案中，许可状态是根据记录在通信授权服务平台的区块链中的许可授权凭证得到的，区块链的特性可以保证许可授权凭证的安全性和保密性；本技术中根据不同的请求类型，用户和企业的许可状态来执行对应的预设通信方案，增强了通信加密检索系统的加密检索手段，可以充分提升用户体验。
51.应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本技术。
附图说明
52.此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本技术的实施例，并与说明书一起用于解释本技术的原理。
53.图1是本技术一个实施例提供的一种基于区块链的通信加密检索方法的流程示意图；
54.图2是本技术一个实施例提供的一种基于区块链的通信加密检索方法中执行预设的通信方案的流程示意图；
55.图3是本技术一个实施例提供的一种基于区块链的通信加密检索系统的结构程示意图；
56.图4是本技术一个实施例提供的一种基于区块链的通信加密检索设备的结构程示意图。
57.附图标记：21-通信平台；211-接收模块；212-判断模块；213-查询模块；214-执行模块；22-通信授权服务平台；31-处理器；32-存储器。
具体实施方式
58.这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本技术相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本技术的一些方面相一致的方法和系统的例子。
59.图1是根据一示例性实施例示出的一种基于区块链的通信加密检索方法的流程图。该方法可以包括以下步骤：
60.步骤s1、接收通信发起端向用户发送的通信请求；
61.步骤s2、判断所述通信请求的请求类型；
62.步骤s3、通过通信授权服务平台查询所述用户和所述通信发起端的许可状态；其中，所述许可状态记录在所述通信授权服务平台的区块链中；
63.步骤s4、根据所述请求类型和所述许可状态执行预设的通信方案。
64.一些实施例中，通信发起端可以是企业，或者其它类型的商户等。
65.本技术基于区块链的通信加密检索方法，许可状态是根据记录在通信授权服务平
台的区块链中的许可授权凭证得到的，区块链的特性可以保证许可授权凭证的安全性和保密性。且本技术的方案根据不同的请求类型，用户和企业的许可状态来执行对应的预设通信方案，增强了通信加密检索系统的加密检索手段，可以充分提升用户体验。
66.应当理解的是，虽然图1的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，这些步骤可以以其它的顺序执行。而且，图1中的至少一部分步骤可以包括多个子步骤或者多个阶段，这些子步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，这些子步骤或者阶段的执行顺序也不必然是依次进行，而是可以与其它步骤或者其它步骤的子步骤或者阶段的至少一部分轮流或者交替地执行。
67.为了使本发明的目的、技术方案和优点更加清楚，下面结合附图对本发明的实施例作进一步详细描述。
68.一些实施例中，在所述接收通信发起端向用户发送的通信请求之前，所述方法还包括：
69.接收所述通信发起端和所述用户的通信许可数据；
70.调用所述通信授权服务平台业务接口，将所述通信许可数据上传到所述通信授权服务平台的区块链中进行记录；
71.根据所述通信许可数据生成存证哈希，并将所述存证哈希反馈给对应的通信发起端或用户。
72.用户可以在企业app，企业小程序或线下签订是否同意企业对其号码发起语音通信或者短信的合约。企业与用户许可后，调用通信授权平台业务接口，将许可数据上传到区块链，保证许可数据可溯源、不可篡改。利用区块链的块链式数据结构来验证与存储数据，利用区块链的分布式节点共识算法来生成和更新数据，利用区块链的密码学的方式保证数据传输和访问的安全。
73.具体地，存证哈希是通过哈希算法生成的。sha256是安全散列算法sha(secure hash algorithm)系列算法之一，其摘要长度为256bits，即32个字节，故称sha256。主要适用于数字签名标准(digitalsignature standard dss)里面定义的数字签名算法(digital signature algorithm dsa)。下面介绍该算法计算消息摘要的原理。
74.对于任意长度(按bit计算)的消息，sha256都会产生一个32个字节长度数据，称作消息摘要。当接收到消息的时候，这个消息摘要可以用来验证数据是否发生改变，即验证其完整性。在传输的过程中，数据很可能会发生变化，那么这时候就会产生不同的消息摘要。
75.sha算法有如下特性：1、不可以从消息摘要中复原信息；2、两个不同的消息不会产生同样的消息摘要。
76.sha256算法中用到了8个哈希初值以及64个哈希常量，这些初值是对自然数中前8个质数(2,3,5,7,11,13,17,19)的平方根的小数部分取前32bit而来。
77.信息预处理：sha256算法中的预处理就是在想要hash的消息后面补充需要的信息，使整个消息满足指定的结构。信息的预处理分为两个步骤：附加填充比特和附加长度。
78.step1，附加填充比特：在报文末尾进行填充，使报文长度在对512取模以后的余数是448填充是这样进行的：先补第一个比特为1，然后都补0，直到长度满足对512取模后余数是448。需要注意的是，信息必须进行填充，也就是说，即使长度已经满足对512取模后余数
是448，补位也必须要进行，这时要填充512个比特。因此，填充是至少补一位，最多补512位。
79.step2、附加长度值：附加长度值就是将原始数据(第一步填充前的消息)的长度信息补到已经进行了填充操作的消息后面。sha256用一个64位的数据来表示原始消息的长度。因此，通过sha256计算的消息长度必须要小于264，当然绝大多数情况这足够大了。长度信息的编码方式为64-bit big-endian integer。
80.逻辑运算：sha256散列函数中涉及的操作全部是逻辑的位运算。
81.首先：将消息分解成512-bit大小的块。假设消息m可以被分解为n个块，于是整个算法需要做的就是完成n次迭代，n次迭代的结果就是最终的哈希值，即256bit的数字摘要。
82.一个256-bit的摘要的初始值h0，经过第一个数据块进行运算，得到h1，即完成了第一次迭代。h1经过第二个数据块得到h2，
……
，依次处理，最后得到hn，hn即为最终的256-bit消息摘要。
83.将每次迭代进行的映射用$map(h_{i-1})＝h_{i}$表示，于是迭代可以更形象地展示为：图中256-bit的hi被描述8个小块，这是因为sha256算法中的最小运算单元称为“字”(word)，一个字是32位。
84.此外，第一次迭代中，映射的初值设置为前面介绍的8个哈希初值。
85.下面开始介绍每一次迭代的内容，即映射$map(h_{i-1})＝h_{i}的具体算法：
86.step1、构造64个字(word)：对于每一块，将块分解为16个32-bit的big-endian的字，记为w[0],
…
,w[15]；也就是说，前16个字直接由消息的第i个块分解得到。
[0087]
step2、进行64次循环：映射map(h_{i-1})＝h_{i}包含了64次加密循环；即进行64次加密循环即可完成一次迭代。
[0088]
一些实施例中，查询所述许可状态的步骤包括：
[0089]
通信平台通过通信授权服务平台的查询接口，根据所述通信发起端的身份标识，查询对应的备案情况、业务备案情况；
[0090]
根据所述用户的身份标识和存证哈希查询该存证哈希的状态，并返回给通信平台；所述存证哈希的状态包括：是否允许、允许通信类型、是否有效。
[0091]
一些实施例中，所述通信请求的请求类型包括：营销型通信服务和用户关怀型通信服务；
[0092]
所述通信请求的请求类型，是所述通信发起端通过请求接口发起通信请求时，在请求接口中选择的。
[0093]
通信请求的请求类型，是通信平台要求企业在通信请求中进行备注的。
[0094]
其中，通信发起端的身份标识可以是通信发起端的主叫号码/短信发送号码，用户的身份标识可以是用户的被叫号码/短信接收号码。
[0095]
本实施例中，营销型通信行为属于未考虑用户意愿的通信行为，所以将营销型通信行为归类为未校验用户意愿的通信行为。用户关怀型通信行为是指企业对已许可用户的用户关怀回访(比如银行、保险等对已有的用户进行用户关怀回访)，该类通信行为的前提是企业和用户已经进行了许可，并且通信的目的是对用户进行关怀回访，所以将用户关怀型外呼归类为已校验用户意愿的通信行为。
[0096]
参照图2，一些实施例中，所述根据所述请求类型和所述许可状态执行预设的通信方案，包括：
[0097]
若所述请求类型为营销型通信服务，且所述许可状态为未许可，则拒绝执行所述通信请求；
[0098]
若所述请求类型为营销型通信服务，且所述许可状态为已许可，则允许执行所述通信请求。
[0099]
其中，执行通信请求可以是呼叫或发送短信。
[0100]
在另一些实施例中，若请求类型为营销型外呼，且许可状态为已许可，则进一步校验用户意愿：
[0101]
若用户意愿为同意，则进行呼叫或者下发短信；
[0102]
若用户意愿为不同意，则不进行呼叫或者下发短信。
[0103]
用户可以在进行许可时，在用户意愿选项签署是否愿意接收营销型呼叫或者短信。
[0104]
本实施例中的请求类型为营销型通信，在请求类型为营销型通信时，首先要考虑企业和用户的许可状态，若企业和用户未许可，考虑到大多数用户不喜欢接陌生营销短信或者呼叫，所以在企业和用户未许可时，直接不对用户进行呼叫或者下发短信。若企业和用户已许可，考虑到大多数用户不喜欢接营销短信或者呼叫，则校验用户意愿，若用户意愿为同意，则进行呼叫或者下发短信，若用户意愿为不同意，则不进行呼叫或者下发短信。
[0105]
参照图2，一些实施例中，所述根据所述请求类型和所述许可状态执行预设的通信方案，还包括：
[0106]
若所述请求类型为用户关怀型外呼，则默认所述许可状态为已许可；
[0107]
判断所述通信请求是否携带存证哈希；所述存证哈希是所述通信发起端和所述用户进行许可时生成的；
[0108]
若所述通信请求中未携带所述存证哈希，则拒绝执行所述通信请求；
[0109]
若所述通信请求中携带所述存证哈希，则允许执行所述通信请求。
[0110]
其中，执行通信请求可以是呼叫或发送短信。本实施例中的请求类型为用户关怀型，在请求类型为营用户关怀型外呼或者下发短信时，由于是企业对已许可用户的用户关怀回访，所以默认许可状态为已许可。
[0111]
但是由于存在企业以用户关怀型的名义作假的可能性，所以在求类型为用户关怀型时，判断通信请求是否携带存证哈希作为第一次真实性查验。若通信请求中未携带存证哈希，则不进行呼叫或者下发短信，若通信请求中携带存证哈希，则进行呼叫或者下发短信。通过查验通信请求是否携带存证哈希可以对作假的企业进行第一轮筛选，从而保证用户体验。
[0112]
一些实施例中，所述方法还包括：
[0113]
在执行所述通信请求后，对所述通信请求中携带的所述存证哈希进行真实性查验，生成验真结果并记录；
[0114]
根据各通信发起端的验真结果确定各个通信发起端的验真比例；
[0115]
对所述验真比例低于预设验真比例值的通信发起端进行通信行为加密检索。
[0116]
由于企业进行呼叫(下发短信)时候并发数据很多，区块链的特性是不支持高并发的，所以在企业对用户进行用户关怀型通信行为时，无法直接去判断该存证哈希的真实性。所以，本实施例中，在进行呼叫或者下发短信后，再对通信请求中携带的存证哈希进行真实
性查验，生成验真结果并记录，可以对作假的企业进行第二轮筛选，从而保证用户体验。
[0117]
本实施例中，根据各企业的验真结果生成各企业的验真比例，验真比例低于预设验真比例值的企业即为多次作假的企业，将该类企业归类为行为不好的企业，并进行通信行为加密检索，从而保证用户体验。
[0118]
一些实施例中，真实性查验的步骤包括：
[0119]
通信请求查询接口中携带所述通信发起端的身份标识、用户的身份标识、存证哈希；
[0120]
根据通信发起端的身份标识，查询通信发起端的备案情况、业务备案情况；
[0121]
根据用户的身份标识和存证哈希查询该存证哈希的状态，所述存证哈希的状态包括：是否允许、允许通信类型、是否有效；
[0122]
若查询不到存证哈希，或者存证哈希的状态为不允许，或者允许通信类型不一致，或者存证哈希无效，则判断所属存证哈希为不真并记录在平台中。
[0123]
一些实施例中，通信行为加密检索的步骤包括：
[0124]
通信请求查询接口中携带所述通信发起端的身份标识、用户的身份标识、存证哈希；
[0125]
根据通信发起端的身份标识，查询通信发起端的备案情况、业务备案情况；
[0126]
根据用户的身份标识和存证哈希查询该存证哈希的状态，所述存证哈希的状态包括：是否允许、允许通信类型、是否有效；
[0127]
若查询不到存证哈希，或者存证哈希的状态为不允许，或者允许通信类型不一致，或者存证哈希无效，则判断不允许执行通信请求，并将结果返回给通信平台；
[0128]
查询过程通过https接口进行请求，保证网络安全。
[0129]
如图3所示，本技术的实施例还提供一种基于区块链的通信加密检索系统，包括：
[0130]
通信平台21和通信授权服务平台22；
[0131]
所述通信平台21包括：接收模块211，判断模块212，查询模块213和执行模块214；
[0132]
所述接收模块211用于接收通信发起端向用户发送的通信请求；
[0133]
所述判断模块212用于判断所述通信请求的请求类型；
[0134]
所述查询模块213用于通过通信授权服务平台查询所述用户和所述通信发起端的许可状态；其中，所述许可状态记录在所述通信授权服务平台的区块链中；
[0135]
所述执行模块214用于根据所述请求类型和所述许可状态执行预设的通信方案。
[0136]
一些实施例中，所述基于区块链的通信加密检索系统还包括：调用模块、存证模块；
[0137]
所述接收模块211还用于接收所述通信发起端和所述用户的通信许可数据；
[0138]
所述调用模块用于调用所述通信授权服务平台业务接口，将所述通信许可数据上传到所述通信授权服务平台的区块链中进行记录；
[0139]
所述存证模块用于根据所述通信许可数据生成存证哈希，并将所述存证哈希反馈给对应的通信发起端或用户。
[0140]
一些实施例中，所述查询模块213用于：通过通信授权服务平台的查询接口，根据所述通信发起端的身份标识，查询对应的备案情况、业务备案情况；根据所述用户的身份标识和存证哈希查询该存证哈希的状态，并返回给通信平台。其中，所述存证哈希的状态包
括：是否允许、允许通信类型、是否有效。
[0141]
一些实施例中，所述通信请求的请求类型包括：营销型通信服务和用户关怀型通信服务。所述通信请求的请求类型，是所述通信发起端通过请求接口发起通信请求时，在请求接口中选择的。
[0142]
一些实施例中，所述执行模块214具体用于：
[0143]
若所述请求类型为营销型通信服务，且所述许可状态为未许可，则拒绝执行所述通信请求；
[0144]
若所述请求类型为营销型通信服务，且所述许可状态为已许可，则允许执行所述通信请求。
[0145]
一些实施例中，所述执行模块214还用于：
[0146]
若所述请求类型为用户关怀型外呼，则默认所述许可状态为已许可；
[0147]
判断所述通信请求是否携带存证哈希；所述存证哈希是所述通信发起端和所述用户进行许可时生成的；
[0148]
若所述通信请求中未携带所述存证哈希，则拒绝执行所述通信请求；
[0149]
若所述通信请求中携带所述存证哈希，则允许执行所述通信请求。
[0150]
一些实施例中，所述基于区块链的通信加密检索系统还包括：查验模块、加密检索模块；
[0151]
所述查验模块用于在执行所述通信请求后，对所述通信请求中携带的所述存证哈希进行真实性查验，生成验真结果并记录；
[0152]
所述加密检索模块用于根据各通信发起端的验真结果确定各个通信发起端的验真比例；对所述验真比例低于预设验真比例值的通信发起端进行通信行为加密检索。
[0153]
一些实施例中，所述查验模块具体用于：
[0154]
通信请求查询接口中携带所述通信发起端的身份标识、用户的身份标识、存证哈希；
[0155]
根据通信发起端的身份标识，查询通信发起端的备案情况、业务备案情况；
[0156]
根据用户的身份标识和存证哈希查询该存证哈希的状态，所述存证哈希的状态包括：是否允许、允许通信类型、是否有效；
[0157]
若查询不到存证哈希，或者存证哈希的状态为不允许，或者允许通信类型不一致，或者存证哈希无效，则判断所属存证哈希为不真并记录在平台中。
[0158]
一些实施例中，所述加密检索模块具体用于：
[0159]
通信请求查询接口中携带所述通信发起端的身份标识、用户的身份标识、存证哈希；
[0160]
根据通信发起端的身份标识，查询通信发起端的备案情况、业务备案情况；
[0161]
根据用户的身份标识和存证哈希查询该存证哈希的状态，所述存证哈希的状态包括：是否允许、允许通信类型、是否有效；
[0162]
若查询不到存证哈希，或者存证哈希的状态为不允许，或者允许通信类型不一致，或者存证哈希无效，则判断不允许执行通信请求，并将结果返回给通信平台；
[0163]
查询过程通过https接口进行请求，保证网络安全。
[0164]
关于上述实施例中的系统，其中各个模块执行操作的具体步骤已经在有关该方法
的实施例中进行了详细描述，此处不再详细阐述说明。上述通信加密检索系统中的各个模块可全部或部分通过软件、硬件及其组合来实现。上述各模块可以硬件形式内嵌于或独立于计算机设备中的处理器中，也可以以软件形式存储于计算机设备中的存储器中，以便于处理器调用执行以上各个模块对应的操作。
[0165]
如图4所示，本技术的实施例还提供一种基于区块链的通信加密检索设备，包括：
[0166]
处理器31和存储器32；
[0167]
处理器31与存储器32通过通信总线相连接：
[0168]
其中，处理器31，用于调用并执行存储器32中存储的程序；
[0169]
存储器32，用于存储程序，程序至少用于执行如上任意一种实施例所述基于区块链的通信加密检索方法。
[0170]
本技术的实施例还提供一种存储介质，所述存储介质存储有计算机程序，所述计算机程序被处理器执行时，实现如上任意一种实施例所述基于区块链的通信加密检索方法。
[0171]
可以理解的是，上述各实施例中相同或相似部分可以相互参考，在一些实施例中未详细说明的内容可以参见其他实施例中相同或相似的内容。
[0172]
需要说明的是，在本技术的描述中，术语“第一”、“第二”等仅用于描述目的，而不能理解为指示或暗示相对重要性。此外，在本技术的描述中，除非另有说明，“多个”的含义是指至少两个。
[0173]
流程图中或在此以其他方式描述的任何过程或方法描述可以被理解为，表示包括一个或更多个用于实现特定逻辑功能或过程的步骤的可执行指令的代码的模块、片段或部分，并且本技术的优选实施方式的范围包括另外的实现，其中可以不按所示出或讨论的顺序，包括根据所涉及的功能按基本同时的方式或按相反的顺序，来执行功能，这应被本技术的实施例所属技术领域的技术人员所理解。
[0174]
应当理解，本技术的各部分可以用硬件、软件、固件或它们的组合来实现。在上述实施方式中，多个步骤或方法可以用存储在存储器中且由合适的指令执行系统执行的软件或固件来实现。例如，如果用硬件来实现，和在另一实施方式中一样，可用本领域公知的下列技术中的任一项或他们的组合来实现：具有用于对数据信号实现逻辑功能的逻辑门电路的离散逻辑电路，具有合适的组合逻辑门电路的专用集成电路，可编程门阵列(pga)，现场可编程门阵列(fpga)等。
[0175]
本技术领域的普通技术人员可以理解实现上述实施例方法携带的全部或部分步骤是可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，该程序在执行时，包括方法实施例的步骤之一或其组合。
[0176]
此外，在本技术各个实施例中的各功能单元可以集成在一个处理模块中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。所述集成的模块如果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。
[0177]
上述提到的存储介质可以是只读存储器，磁盘或光盘等。
[0178]
在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示
例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本技术的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不一定指的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任何的一个或多个实施例或示例中以合适的方式结合。
[0179]
尽管上面已经示出和描述了本技术的实施例，可以理解的是，上述实施例是示例性的，不能理解为对本技术的限制，本领域的普通技术人员在本技术的范围内可以对上述实施例进行变化、修改、替换和变型。

技术特征：
1.一种基于区块链的通信加密检索方法，其特征在于，包括：接收通信发起端向用户发送的通信请求；判断所述通信请求的请求类型；通过通信授权服务平台查询所述用户和所述通信发起端的许可状态；其中，所述许可状态记录在所述通信授权服务平台的区块链中；根据所述请求类型和所述许可状态执行预设的通信方案。2.根据权利要求1所述的方法，其特征在于，在所述接收通信发起端向用户发送的通信请求之前，所述方法还包括：接收所述通信发起端和所述用户的通信许可数据；调用所述通信授权服务平台业务接口，将所述通信许可数据上传到所述通信授权服务平台的区块链中进行记录；根据所述通信许可数据生成存证哈希，并将所述存证哈希反馈给对应的通信发起端或用户。3.根据权利要求1所述的方法，其特征在于，查询所述许可状态的步骤包括：通信平台通过通信授权服务平台的查询接口，根据所述通信发起端的身份标识，查询对应的备案情况、业务备案情况；根据所述用户的身份标识和存证哈希查询该存证哈希的状态，并返回给通信平台；所述存证哈希的状态包括：是否允许、允许通信类型、是否有效。4.根据权利要求1-3任一项所述的方法，其特征在于，所述通信请求的请求类型包括：营销型通信服务和用户关怀型通信服务；所述通信请求的请求类型，是所述通信发起端通过请求接口发起通信请求时，在请求接口中选择的。5.根据权利要求4所述的方法，其特征在于，所述根据所述请求类型和所述许可状态执行预设的通信方案，包括：若所述请求类型为营销型通信服务，且所述许可状态为未许可，则拒绝执行所述通信请求；若所述请求类型为营销型通信服务，且所述许可状态为已许可，则允许执行所述通信请求。6.根据权利要求4所述的方法，其特征在于，所述根据所述请求类型和所述许可状态执行预设的通信方案，还包括：若所述请求类型为用户关怀型外呼，则默认所述许可状态为已许可；判断所述通信请求是否携带存证哈希；所述存证哈希是所述通信发起端和所述用户进行许可时生成的；若所述通信请求中未携带所述存证哈希，则拒绝执行所述通信请求；若所述通信请求中携带所述存证哈希，则允许执行所述通信请求。7.根据权利要求6所述的方法，其特征在于，还包括：在执行所述通信请求后，对所述通信请求中携带的所述存证哈希进行真实性查验，生成验真结果并记录；根据各通信发起端的验真结果确定各个通信发起端的验真比例；
对所述验真比例低于预设验真比例值的通信发起端进行通信行为加密检索。8.根据权利要求7所述的方法，其特征在于，真实性查验的步骤包括：通信请求查询接口中携带所述通信发起端的身份标识、用户的身份标识、存证哈希；根据通信发起端的身份标识，查询通信发起端的备案情况、业务备案情况；根据用户的身份标识和存证哈希查询该存证哈希的状态，所述存证哈希的状态包括：是否允许、允许通信类型、是否有效；若查询不到存证哈希，或者存证哈希的状态为不允许，或者允许通信类型不一致，或者存证哈希无效，则判断所属存证哈希为不真并记录在平台中。9.根据权利要求7所述的方法，其特征在于，通信行为加密检索的步骤包括：通信请求查询接口中携带所述通信发起端的身份标识、用户的身份标识、存证哈希；根据通信发起端的身份标识，查询通信发起端的备案情况、业务备案情况；根据用户的身份标识和存证哈希查询该存证哈希的状态，所述存证哈希的状态包括：是否允许、允许通信类型、是否有效；若查询不到存证哈希，或者存证哈希的状态为不允许，或者允许通信类型不一致，或者存证哈希无效，则判断不允许执行通信请求，并将结果返回给通信平台；查询过程通过https接口进行请求，保证网络安全。10.一种基于区块链的通信加密检索系统，其特征在于，包括：通信平台和通信授权服务平台；所述通信平台包括：接收模块，判断模块，查询模块和执行模块；所述接收模块用于接收通信发起端向用户发送的通信请求；所述判断模块用于判断所述通信请求的请求类型；所述查询模块用于通过通信授权服务平台查询所述用户和所述通信发起端的许可状态；其中，所述许可状态记录在所述通信授权服务平台的区块链中；所述执行模块用于根据所述请求类型和所述许可状态执行预设的通信方案。

技术总结
本申请涉及一种基于区块链的通信加密检索方法和系统；所述方法包括：接收通信发起端向用户发送的通信请求；判断所述通信请求的请求类型；通过通信授权服务平台查询所述用户和所述通信发起端的许可状态；其中，所述许可状态记录在所述通信授权服务平台的区块链中；根据所述请求类型和所述许可状态执行预设的通信方案。本申请的方案中，许可状态是根据记录在通信授权服务平台的区块链中的许可授权凭证得到的，区块链的特性可以保证许可授权凭证的安全性和保密性；本申请中根据不同的请求类型，用户和企业的许可状态来执行对应的预设通信方案，增强了通信加密检索系统的加密检索手段，可以充分提升用户体验。可以充分提升用户体验。可以充分提升用户体验。


技术研发人员：李静波 王涛 邵灵光 林凤
受保护的技术使用者：北京承启通科技有限公司
技术研发日：2022.03.11
技术公布日：2022/5/25