CN115512852A - 一种生成融合码的方法及设备 - Google Patents

Abstract

本申请公开了一种生成融合码的方法及设备，用以解决现有的用户需要频繁切换多种码种的技术问题。方法包括：大数据局后台接收用户终端针对融合码发起的申请请求，所述申请请求中至少包括用户个人信息；将所述用户个人信息作为加密信息生成初始融合码；对接待融合码种对应的数据接口，以获取所述待融合码种对应的数据信息；将所述数据信息写入所述初始融合码中，得到融合码。本申请通过上述方法实现了用户使用时只需打开融合码，即可展示所有相关信息，无需再切换其他二维码。

Description

一种生成融合码的方法及设备

技术领域

本申请涉及信息化软件系统技术领域，尤其涉及一种生成融合码的方法及设备。

背景技术

随着信息化深入，支付码、医保码、交通码等等频繁使用的背景下，人们在出入各个场所时，需要在这三个码种甚至更多码种之间进行切换，这就使得进出场所的人群需要进行排队等待，不仅给群众带来了影响，也给各个场所也带来了不便。

虽然现在一些码种实现了融合，可以在显示一个码种的页面，操作进入另一个码种页面，但这种融合仅融合了小部分码种，对于需要群众展示的所有码种并未进行融合，这就使得，群众在进出一些场所时，仍需要进行码种的频繁切换。

发明内容

本申请实施例提供了一种生成融合码的方法及设备，用以解决用户重复切换不同码种的技术问题。

一方面，本申请实施例提供了一种生成融合码的方法，所述方法包括：大数据局后台接收用户终端针对融合码发起的申请请求，所述申请请求中至少包括用户个人信息；将所述用户个人信息作为加密信息生成初始融合码；对接待融合码种对应的数据接口，以获取所述待融合码种对应的数据信息；将所述数据信息写入所述初始融合码中，得到融合码。

在本申请说明书的一个或多个实施例中，所述用户个人信息至少包括：用户姓名、用户手机号、用户身份证号以及融合码编号。

在本申请说明书的一个或多个实施例中，所述方法还包括：在所述待融合码为医保码时，将所述医保码拼接在所述初始融合码上。

在本申请说明书的一个或多个实施例中，在得到所述融合码之后，所述方法还包括：所述大数据局后台将所述融合码发送至所述用户终端上，以便于所述融合码被扫码终端进行扫描；所述扫码终端在扫描所述融合码之后，读取所述融合码的密文，并将所述密文发送至所述扫码终端对应的委办局；所述委办局与大数据局后台进行交互，获取所述融合码所包含的用户个人信息，以完成所述融合码的认证。

在本申请说明书的一个或多个实施例中，将所述密文发送至所述扫码终端对应的委办局之后，所述方法还包括：所述委办局对所述密文进行解密，以得到所述融合码包含的所述用户个人信息与所述委办局对应的待融合码种的数据信息。

在本申请说明书的一个或多个实施例中，所述委办局对所述密文进行解密，具体包括：所述委办局通过所述大数据局后台提供的接口将所述密文传输至所述大数据局后台，以便于所述大数据后台返回所述委办局对应的待融合码种的数据信息与所述用户个人信息。

在本申请说明书的一个或多个实施例中，所述方法还包括：所述委办局将其向所述大数据局后台申请的公钥，一同通过所述接口进行传输。

在本申请说明书的一个或多个实施例中，所述委办局对所述密文进行解密，具体包括：所述委办局通过其向所述大数据局后台申请的公钥，向所述大数据局后台申请调用解密工具包，以通过所述解密工具包对所述密文进行解密。

另一方面，本申请实施例还提供了一种生成融合码的设备，所述设备包括：处理器；以及，存储器，其上存储有可执行代码，当所述可执行代码被执行时，使得所述处理器执行如上述的一种生成融合码的方法。

本申请实施例提供的一种生成融合码的方法及设备，具有以下有益效果：可以极大的减轻用户的使用复杂度，提升检查通过速度，增加老人、孩童的使用友好度，节省因手机卡顿或网络延迟造成的切码等待时间。该融合码同时可以作为乘车码用以乘公交、医保码用以付药费、博物馆图书馆电子门票等等多种操作，真正实现一码通全城。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1为本申请实施例提供的一种生成融合码的方法流程图；

图2为本申请实施例提供的一种应用场景下，融合码的生成过程图；

图3为本申请实施例提供的一种应用场景下，融合码的使用过程图；

图4为本申请实施例提供的一种生成融合码的设备结构图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚，下面将结合本申请具体实施例及相应的附图对本申请技术方案进行清楚、完整地描述。显然，所描述的实施例仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

下面通过附图对本申请实施例提出的技术方案进行详细的说明。

图1为本申请实施例提供的一种生成融合码的方法流程图。如图1所示，本申请实施例中的方法至少包括以下执行步骤：

步骤101、大数据局后台接收用户终端的申请请求，生成初始融合码。

本申请实施例中的融合码生成方法，其执行主体是大数据局后台，也即，在用户想要申请一个融合码时，通过自身的用户终端，向大数据局后台发送一个携带有自身信息的申请请求，大数据局后台在接收到这个申请请求之后，就会生成一个包含用户个人信息的初始融合码。并且，在初始融合码中，用户的个人信息是作为加密信息存在的。

在本申请实施例的一种或多种可能实现方式中，用户个人信息至少包括：用户姓名、用户手机号、用户身份证号以及融合码编号。

步骤102、大数据局后台获取待融合码种对应的数据信息，生成融合码。

在生成初始融合码之后，大数据局后台基于要融合的码种，对接不同的委办局，获取各个待融合码种对应的数据信息，然后将这些数据信息写入初始融合码中，得到融合码。

在本申请实施例的一种或多种可能实现方式中，在所述待融合码为医保码时，将所述医保码拼接在所述初始融合码上。

进一步地，大数据局后台在生成融合码之后，将该融合码发送至申请的用户终端上，以便于用户终端进行使用。

步骤103、各委办局对融合码进行认证使用。

在用户终端使用大数据局后台生成的融合码之前，需要各委办局对该融合码进行认证。具体地，各委办局发放的扫码终端在扫描到融合码时，读取融合码的密文，并将该密文发送至委办局后台，委办局后台对该密文进行解密处理，解密后得到该融合码对应的用户个人信息与委办局对应的待融合码种的数据信息，完成融合码的认证过程。

在本申请实施例的一种或多种可能实现方式中，委办局后台对该密文进行解密处理，可以通过以下方式实现：委办局通过所述大数据局后台提供的数据传输接口，将所述密文传输至所述大数据局后台，以便于所述大数据后台返回所述委办局对应的待融合码种的数据信息与所述用户个人信息，但在此过程中，需要委办局将其向大数据局后台申请的公钥一同进行传输，以便于大数据局后台对委办局的身份进行识别。

在本申请实施例的一种或多种可能实现方式中，委办局后台对该密文进行解密处理，还可以通过以下方式实现：所述委办局通过其向所述大数据局后台申请的公钥，向所述大数据局后台申请调用解密工具包，以通过所述解密工具包对所述密文进行解密。

为了更好的解释说明本申请实施例提供的融合码的生成方法，本申请实施例还提供了一种应用场景下的，融合码的生成方法。

该应用场景下，利用融合码作为一个地区新型的“电子证件”，是通过由所在地区的大数据局统一生成下发、各委办局共同认可的方式，实现多码合一的功能，用户不再需要繁琐的申请各种各样的二维码。具体实施方案如下：

1、融合码生成：

图2为本申请实施例提供的一种应用场景下，融合码的生成过程图，如图 2所示，融合码最基础的加密信息为：姓名，手机号，身份证号，码编号。在生成融合码时，对于需要结合在融合码里的信息，进行主动对接。

进一步地，针对特殊码种(如电子医保卡)，它是由部平台统一下发，各地方医保局统一使用的，在地方医保局无法将我们的融合码纳入自身码体系的情况下，我们的方案会根据实际情况做出微调，即融合码信息里除了自身的信息外，还拼接上医保码的信息，这种融合方式在扫码枪扫描融合码时，地方医保局后台可以截取到医保码信息，以此继续完成后续的操作。

2、各委办局共同认可：

图3为本申请实施例提供的一种应用场景下，融合码的使用过程图，如图 3所示，融合码可以被不同的委办局(例如，公交公司、医保局等)进行扫码使用。

具体地，作为由大数据局统一下发的“融合码”，已有扫码终端的委办局 (比如公交、医保刷码等)可以改造升级自身的扫码终端，使其支持融合码扫码操作；无扫码终端的委办局(博物馆、美术馆、图书馆等)可以使用大数据局统一定制的终端进行扫描；终端读取到融合码的密文后可通过与大数据局后台交互以获取融合码所包含的用户信息(姓名、身份证号、编号等)。之后公交公司将该码信息(编号)加入自身数据库作为公交码(类似公交APP的电子乘车码)之一，在用户充值后可直接扫码乘公交；当地医保局同样将该码作为自身电子医保卡刷卡买药；图书馆博物馆将融合码作为预约参观凭证。

3、各委办局解密二维码信息方式：

关于数据解密，方案一是大数据局可以通过向各个委办局提供接口的方式，委办局调用接口时，除了需传输融合码的密文之外，还需附加该委办局从大数据局申请的公钥，公钥匹配不成功则无法获取用户的信息；方案二则是大数据局提供一个封装好的解密工具包，该方案无需进行互联网传输，委办局后台可自行调用该工具包获取到融合码所包含的用户信息，同样的，调用该工具包时也需传入该委办局从大数据局申请到的公钥，解密包验证公钥成功后返回融合码对应的用户信息。

4、委办局与大数据局之间的公钥存在唯一性，为各委办局解密融合码信息时所使用的公钥各不相同，获取到的解密信息除用户基本信息外也不尽相同，例如电子医保卡信息只有医保局在使用对应的公钥解密时才会返回。

以上为本申请实施例提供的方法实施例，基于同样的发明构思，本申请实施例还提供了一种生成融合码的设备，其结构如图4所示。

图4为本申请实施例提供的一种生成融合码的设备结构图。如图4所示，设备包括：处理器；以及，存储器，其上存储有可执行代码，当所述可执行代码被执行时，使得所述处理器执行如上述的一种生成融合码的方法。

在本申请实施例的一种或多种可能实现方式中，处理器用于，大数据局后台接收用户终端针对融合码发起的申请请求，所述申请请求中至少包括用户个人信息；将所述用户个人信息作为加密信息生成初始融合码；对接待融合码种对应的数据接口，以获取所述待融合码种对应的数据信息；将所述数据信息写入所述初始融合码中，得到融合码。

本申请实施例提供的一种融合码的生成方法及设备，具有以下有益效果：

1、极大的提升了用户体验，解决了用户因各种名目的二维码而不得不重复申请、重复切换的窘境，提高了通行效率，缓解了用户在使用时因操作失误、网络延迟、手机卡顿等原因造成的排队、拥堵的情况，缓解了用户的焦虑心理。

2、提升了市民对政府的好感度。

本申请中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于设备实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

以上所述仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。

Claims (9)

1.一种生成融合码的方法，其特征在于，所述方法包括：

大数据局后台接收用户终端针对融合码发起的申请请求，所述申请请求中至少包括用户个人信息；

将所述用户个人信息作为加密信息生成初始融合码；

对接待融合码种对应的数据接口，以获取所述待融合码种对应的数据信息；

将所述数据信息写入所述初始融合码中，得到融合码。

2.根据权利要求1所述的一种生成融合码的方法，其特征在于，所述用户个人信息至少包括：用户姓名、用户手机号、用户身份证号以及融合码编号。

3.根据权利要求1所述的一种生成融合码的方法，其特征在于，所述方法还包括：

在所述待融合码为医保码时，将所述医保码拼接在所述初始融合码上。

4.根据权利要求1所述的一种生成融合码的方法，其特征在于，在得到所述融合码之后，所述方法还包括：

所述大数据局后台将所述融合码发送至所述用户终端上，以便于所述融合码被扫码终端进行扫描；

所述扫码终端在扫描所述融合码之后，读取所述融合码的密文，并将所述密文发送至所述扫码终端对应的委办局；

所述委办局与大数据局后台进行交互，获取所述融合码所包含的用户个人信息，以完成所述融合码的认证。

5.根据权利要求4所述的一种生成融合码的方法，其特征在于，将所述密文发送至所述扫码终端对应的委办局之后，所述方法还包括：

所述委办局对所述密文进行解密，以得到所述融合码包含的所述用户个人信息与所述委办局对应的待融合码种的数据信息。

6.根据权利要求5所述的一种生成融合码的方法，其特征在于，所述委办局对所述密文进行解密，具体包括：

所述委办局通过所述大数据局后台提供的接口将所述密文传输至所述大数据局后台，以便于所述大数据后台返回所述委办局对应的待融合码种的数据信息与所述用户个人信息。

7.根据权利要求6所述的一种生成融合码的方法，其特征在于，所述方法还包括：

所述委办局将其向所述大数据局后台申请的公钥，一同通过所述接口进行传输。

8.根据权利要求5所述的一种生成融合码的方法，其特征在于，所述委办局对所述密文进行解密，具体包括：

所述委办局通过其向所述大数据局后台申请的公钥，向所述大数据局后台申请调用解密工具包，以通过所述解密工具包对所述密文进行解密。

9.一种生成融合码的设备，其特征在于，所述设备包括：

处理器；以及，

存储器，其上存储有可执行代码，当所述可执行代码被执行时，使得所述处理器执行如权利要求1-8任一项所述的一种生成融合码的方法。

Images