本发明总体来说涉及微服务与移动互联网技术应用领域，更具体涉及一种基于移动互联网技术的p2p信用互看系统及其相关方法。
背景技术
创建诚信社会是一个非常崇高且有现实意义的目标。在中国，个人、企业征信体系发展迅速，在社会经济生活中已经有很多应用场景开始使用征信系统。鉴于个人、企业征信在社会经济生活中的重要性，已经有人提出了各种技术方案，旨在创建有效的征信系统，方便个人及企业信用的获取、使用和管理。
中国专利申请公开文件cn1746920a公开了一种个人信用征信系统，其包括输入装置、中央处理装置、输出装置和中心数据库，可通过输入装置将个人信用信息输入，输入装置将个人信用信息输送到中央处理装置，中央处理装置从中心数据库中调取个人信用信息处理流程，对各种个人信用信息进行运算，最后得到个人信用结果，中央处理装置将个人信用结果输送到中心数据库得到保存或通过结果输出装置输出。cn1746920a公开的个人信用征信系统能把分散在各商业银行和社会有关方面的个人信用信息汇集起来，进行加工和存储，从而向金融等机构提供个人信用咨询服务。
中国专利申请公开文件cn101727645a公开了与cn1746920a类似的个人信用征信系统，该系统包括：个人信用信息录入组件、个人信用征信基础数据库、个人信用信息处理系统、个人信用信息输出组件。个人信用信息录入组件从各权威机构对个人的信用信息进行征信并将征集的个人信用信息传送到个人信用征信基础数据库；个人信用征信基础数据库按照一定的数据格式对征集的个人信用信息进行存储；个人信用信息处理系统从个人信用征信基础数据库取得需要的个人信用信息，并对该信息进行加工和数据变换；个人信用信息处理系统通过个人信用信息输出组件向有关机构输出个人信用信息。
中国专利申请公开文件cn102609844公开了一种评价企业信用的方法，其包括将交易伙伴对交易对方进行信用评估时的信用得分、互联网上的社会评价得分、指定政府机构的社会荣誉得分、以及其他指定的机构所提供的授信得分按照权重指数进行计算得出企业的可信度分数。
中国专利申请公开文件cn105427033a公开了一种基于大数据的个人诚信系统，其包括信息采集支系统、评分支系统、前端app显示支系统。信息采集支系统包括央行征信系统、教育部教育系统、公安部户籍系统、第三方机构评估系统以及数据输入和数据输出模块；评分支系统包括评分系统和计算系统，通过相应技术对数据进行分析，将有用的数据在数学模型下进行加权分析，将分析得出的数据存于数据库中，可通过app调用数据库中的数据。
尽管市场上已经存在有(或者已经有人提出了)如上所述的一些个人和/或企业征信系统，但这些征信系统大多是2b(面向企业或者公共政府部门)的商业模式，而不是2c(面向个人)的商业模式。与此同时，市场上还没有个人对个人或“点对点”(p2p)模式下直接、易用、安全的能够分享征信的技术解决方案。如果个人与个人之间需要互看分享信用，按照传统的实现方式，必须由信息主体以手动方式通过自己的媒介(例如手机或电脑)进行展示，或者需要将相关信息打印出来向对方出示。这种传统的实现方式存在以下问题和缺陷：
·信息获取难：由于提供征信信息的机构众多，信息主体获取自己各方面的征信信息不够容易，导致难于管理好自身的信用；
·信息易造假：当信息主体利用自己的媒介(例如手机或电脑)展示其信用信息时，特别是如果仅出示信用信息的打印件或截屏图像，存在着对这些信息篡改和造假的隐患；
·安全风险高：由于上述的信息篡改和造假隐患，对于接收信息的主体一方而言，增加了安全风险；
·易用性差：传统模式的信用互看分享很不方便于实用，导致在很多应用场景(例如找室友，结伴旅游，甚至相亲等)下，征信信息很难实际使用。
·主体参与感不强：在传统征信系统的情形下，信息主体通常对于自己的征信状况并不了解，更不清楚自己的征信信息何时发生了怎样的变化，因此没有太多参与感，也谈不上去考虑如何经营自己的信用。
·场景间无区别化：按照传统的征信模式，通常不论是什么样的场景应用，征信系统只是提供一种信用评价。然而，单纯一种信用评价很难准确反映信息主体在不同应用场景下的信用状况。比如，在财务信息方面具有良好信用的主体不见得是能与人融洽相处的好室友。
因此，目前仍需要在个人和/或企业的征信系统方面有更多的创新和改进。特别是，相对于市场上的各种2b模式的征信系统，需要提供一种同时适用于2b和2c模式的征信系统，并且可以让信息主体随时向第三方便捷、安全地展示自己的信用，而且，如果能够提供一种p2p信用互看系统，让用户更便捷和安全地向尚未与自己建立联系的第三方分享自己的信用信息，则将大大提高征信系统在很多场景下的普及程度。因此，市场上需要易用性更强，安全性更好的征信系统，一方面能进一步提高征信系统的普及程度，另一方面还可帮助信息主体更好地掌控和有效地经营自己的信用记录，从而获得更好的信用评级。
正是为了上述目的，本发明提供了一种基于移动互联网技术的p2p信用互看系统及其相关方法，同时解决了传统模式下个人与个人之间互看分享信用时出现的信息获取难、信息易造假、安全风险高，易用性较差，主体参与感不强，场景间无区别化等问题和缺陷。同时，利用本发明的p2p信用互看系统，更便于用户快捷安全地向与该用户无关的第三方分享自己的信用信息，极大地丰富了信用分享的场景应用。
技术实现要素：
本发明公开了一种用于在第一用户和第二用户的移动终端之间分享征信信息的系统，其包括服务管理平台，第一用户移动终端和第二用户移动终端，所述服务管理平台能与至少一个征信信息提供机构通信以从所述至少一个征信信息提供机构获取第一用户的征信信息，在所述第一用户移动终端和第二用户移动终端上安装有应用与所述服务管理平台通信，所述系统被配置为基于所述系统确定的审核规则以及所述第一用户移动终端和所述第二用户移动终端的交互结果，促使所述服务管理平台将第一用户的征信信息发送至第二用户移动终端。
根据本发明的一种实施方式，所述服务管理平台包括：个人信用基础信息认证模块，用于对第一用户的基础账户信息进行确认；个人征信码生成模块，可根据第一用户的基础账户信息生成第一用户征信码，用于提供查询第一用户的征信信息的授权；扫码模块，第二用户可在第二用户移动终端上调用该扫码模块扫描第一用户征信码；查询审核模块，在第二用户调用扫码模块扫描第一用户征信码后，根据系统确定的审核规则判断第一用户是否已授权第二用户查询第一用户的征信信息；聚合信用数据请求模块，用于向多个征信信息提供机构请求第一用户的多个征信数据，利用聚合算法对所述多个征信数据进行计算并做格式化处理；信用加密处理模块，其接收经聚合信用数据请求模块处理的第一用户的征信数据，并对其进行加密处理；信用报告存储模块，用于存储经信用加密处理模块加密处理过的第一用户征信数据，并可在出现授权查询请求时将加密处理过的第一用户征信数据推送至移动端解密处理模块处理；和移动端解密处理模块，其能对经过加密处理的第一用户的征信数据进行解密处理，并将经解密处理的第一用户的征信数据推送至第二用户的移动终端上展示以供第二用户查看。
根据本发明的一种实施方式，所述第一用户征信码是动态的，第二用户在不同时间扫描的第一用户征信码均不同。
根据本发明的一种实施方式，所述第一用户征信码可进行安全加锁处理且在第二用户扫描第一用户征信码时对其进行解锁处理并判断第一用户征信码的真伪。
根据本发明的一种实施方式，所述服务管理平台还包括本人征信配置信息获取模块，用于让第一用户将第一用户征信码设置为“开”或“关”的状态，其中当第一用户征信码设置为“开”的状态时，可授权第二用户查询第一用户的征信信息；当第一用户征信码设置为“关”的状态时，禁止第二用户查询第一用户的征信信息。
根据本发明的一种实施方式，所述本人征信配置信息获取模块还可用于让第一用户对第一用户的征信信息进行定价。
根据本发明的一种实施方式，所述服务管理平台还包括阅后即焚安全处理模块，用于在所述服务管理平台与第二用户的移动终端之间建立临时链接，以便在第二用户的移动终端上展示第一用户的征信数据并在建立临时链接后启动倒计时钟，当倒计时结束后，将临时链接断开，停止在第二用户的移动终端上展示第一用户的征信数据。
根据本发明的一种实施方式，所述聚合信用数据请求模块利用聚合算法对所述多个征信数据进行的计算包括根据具体场景的不同计算出针对不同场景的不同征信数值。
根据本发明的一种实施方式，所述服务管理平台还包括诚信互评模块，用于让第二用户在查看过第一用户的征信数据后对第一用户作出评价。
根据本发明的一种实施方式，所述系统还包括第三用户的移动终端，且所述服务管理平台还包括：代理认证模块，用于对第三用户的基础账户信息进行确认；代理授权请求码生成模块，用于为第三用户生成代理授权请求码；授权代理模块，用于让第一用户通过扫描所述代理授权请求码授权第三用户代理第一用户的征信数据；代理征信码生成模块，用于生成可授权查询第一用户的征信信息的临时征信码，该临时征信码可由所述系统中的扫码模块识别；和代理记录模块，用于在第三用户的移动终端上展示所述临时征信码。
根据本发明的一种实施方式，所述授权代理模块允许第一用户设置授权第三用户代理第一用户的征信数据的有效期，当有效期结束时，在第三用户的移动终端上停止展示所述临时征信码。
根据本发明的一种实施方式，所述第一用户移动终端和所述第二用户移动终端之间能以短程通信技术进行交互，并允许第二用户向服务管理平台请求获取第一用户的征信数据。
根据本发明的一种实施方式，所述系统确定的审核规则包括第二用户向第一用户支付费用后才能查询第一用户的征信信息。
本发明还公开了一种利用上述系统在第一用户和第二用户的移动终端之间分享征信信息的方法，包括以下步骤：
-所述服务管理平台与至少一个征信信息提供机构进行通信，从所述至少一个征信信息提供机构获取第一用户的征信信息；
-使所述第一用户移动终端和所述第二用户移动终端进行交互；
-基于所述系统确定的审核规则以及所述第一用户移动终端和所述第二用户移动终端的交互结果，促使所述服务管理平台将第一用户的征信信息发送至第二用户移动终端。
更具体来说，本发明公开的利用上述系统在第一用户和第二用户的移动终端之间分享征信信息的方法还可包括以下步骤：
-使用个人信用基础信息认证模块对第一用户的基础账户信息进行确认；
-基于第一用户的基础账户信息，使用个人征信码生成模块生成第一用户征信码，用于提供查询第一用户的征信信息的授权；
-第二用户在第二用户移动终端上调用扫码模块扫描第一用户征信码；
-使用查询审核模块判断第一用户是否已授权第二用户查询第一用户的征信信息；
-使用聚合信用数据请求模块向多个征信信息提供机构请求第一用户的多个征信数据，利用聚合算法对所述多个征信数据进行计算并做格式化处理；
-将经聚合信用数据请求模块处理的第一用户的征信数据发送至信用加密处理模块进行加密处理；
-将经信用加密处理模块加密处理过的第一用户征信数据存储在信用报告存储模块中，在出现授权查询请求时将加密处理过的第一用户征信数据推送至移动端解密处理模块处理；
-使用移动端解密处理模块对经过加密处理的第一用户的征信数据进行解密处理，并将经解密处理的第一用户的征信数据推送至第二用户的移动终端上展示以供第二用户查看。
在此，需要注意的是，对于本发明公开说明书中披露的在用户的移动终端之间分享征信信息的方法，在具体实现时不必遵照以上所述的各个步骤的先后顺序，而是可以采用并行的顺序或其它的顺序，或者不同的步骤还可以合并为一个步骤执行。例如，使用聚合信用数据请求模块向多个征信信息提供机构请求用户的征信数据并进行计算的操作可以在服务管理平台收到查询用户征信数据的请求之前就已经进行，例如可以在平台上独立于用户的请求以一定的频度进行。本发明的技术方案对于聚合信用数据请求模块请求用户征信数据和计算的时机和频度并不做具体限制。
此外，本发明还公开了一种用于在多个用户的移动终端之间分享征信信息的系统，其包括服务管理平台，第一用户移动终端，第二用户移动终端和第三用户移动终端，所述服务管理平台能与至少一个征信信息提供机构通信以从所述至少一个征信信息提供机构获取第一用户的征信信息，在所述第一用户移动终端、第二用户移动终端和第三用户移动终端上安装有应用与所述服务管理平台通信，所述系统被配置为基于所述系统确定的授权规则以及所述第一用户移动终端和所述第三用户移动终端的交互结果，使得第三用户移动终端能够获得第一用户的授权以向所述服务管理平台发送请求，从而将第一用户的征信信息发送至第二用户移动终端。
简而言之，利用本发明的这一系统，可以便捷地让系统的一个用户以代理的身份向第三方用户分享被代理用户的征信信息。作为代理的用户需要通过其移动端和被代理用户的移动端之间的交互来获得被代理用户的授权。根据一种实施方式，这种交互可以是利用在一个用户的移动端上生成诸如二维码之类的验证工具并通过用户移动端识别该验证工具来实现交互和授权。然而，本发明也包括利用其它方式在用户之间产生的交互，例如，因为在各个相关用户的移动端上均安装了相应的应用，一个用户可以简单地在其移动端上利用该应用搜索到其他用户，并利用与该其他用户的移动端之间的通信实现交互和代理的授权。另外，在用户的移动端之间产生交互还可以基于短程通信技术(例如nfc或者蓝牙协议)来实现。以上所述的各种交互方式仅仅是一些示例，目的是为了充分说明本发明的技术方案，但这并不意味着本发明的技术方案仅限于这些交互的具体实现方式。
附图说明
为了更清楚地理解本发明，以下将结合附图对本发明的各个示例实施方式作详细说明，其中相同的附图标记表示相同的组件。
结合附图阅读以下详细描述，将更好的理解本说明书，在附图中
图1为本发明中基于移动互联网的p2p信用互看系统的整体框架图；
图2为本发明中用户查看自己的征信系统处理流程图；
图3为本发明中用户请求查看他人征信的系统处理流程图；
图4为本发明中用户授权他人查看本人征信的系统处理流程图；
图5为本发明中用户代理他人信用报告的系统处理流程图；
图6为本发明中个人信用基础信息认证模块的构建流程图；
图7为本发明中个人征信码生成模块的构建流程图；
图8为本发明中查询审核模块的构建流程图；
图9为本发明中聚合信用数据请求模块的构建流程图；
图10为本发明中信用加密处理模块的构建流程图；
图11为本发明中移动端解密处理模块的构建流程图；
图12为本发明中阅后即焚模块的构建流程图；
图13为本发明中本人征信配置信息获取模块的构建流程图；
图14为本发明中代理认证模块的构建流程图；
图15为本发明中授权代理模块的构建流程图；
图16为本发明中代理征信码生成模块的构建流程图；
图17为本发明中代理授权请求码生成模块的构建流程图；
图18为本发明中授权本人信用给代理模块的构建流程图；
图19为本发明中不同场景信用分聚合建模模块的构建流程图；
图20为本发明中动态征信码的构建流程图；
图21为本发明中扫描征信码时的安全控制流程图。
具体实施方式
以下，将参考附图描述本发明的各种示例实施方式。针对本发明的各种示例实施方式可以做出各种变化，因此本发明可以具有多种实施方式。以下在附图中示出了本发明的一些特定示例实施方式并对其进行相关详细说明。但是，这并不意味将本发明的实施方式限定为这些特定实施方式的形式，而是应该理解为本发明包括了已公开的各种示例实施方式，还包括对其做出了修改的各种等同或备选实施方式。下面结合附图所提供的详细说明旨在作为对示例实施例的描述，但并不表示这些附图是解释或实现本发明的唯一形式。
图1示出了本发明的整体框架图。如图1所示，本发明的基于移动互联网的p2p信用互看系统包括总体以“a”表示的个人移动端和总体以“b”表示的服务管理平台。本发明的个人移动端的一种实现方式可以是智能电话，但不限于此，而是还可以包括电子书(e-book)阅读器、便携pc、上网本、个人数字助理(pda)、便携多媒体播放器(pmp)等各种移动电子设备以及可穿戴电子设备等等。用户可以在个人移动端a中安装app或小程序，通过移动互联网架构与服务管理平台上的各个服务模块进行通信，发送相应请求，接收相应的命令，从而实现与本发明的p2p信用互看系统相关的多种服务。这些服务可包括查看自己的征信报告a1，请求查看他人征信a2，授权他人查看本人征信a3，代理他人信用报告a4，授权本人信用给代理a5，个人信用预警服务a6。
本发明的服务管理平台b包括以微服务形式或其他后端响应服务形式活动在云端的多个服务模块，具体可包括：个人信用基础信息认证模块b1，个人征信码生成模块b2，查询审核模块b3，聚合信用数据请求模块b4，信用加密处理模块b5，移动端解密处理模块b6，阅后即焚安全处理模块b7，诚信互评模块b8，本人征信配置信息获取模块b9，代理认证模块b10，代理授权请求码生成模块b11，授权代理模块b12，代理征信码生成模块b13，代理记录模块b14，扫码模块b15，以及信用报告加密存储模块b16。由于这些服务模块是以微服务的形式在云端活动，根据个人移动端a中各个不同请求的需求能进行运转和自动负载均衡响应，可保证响应的及时性和稳定性。本领域技术人员可以理解，对于本发明的p2p信用互看系统，服务管理平台b不必包含以上所述的b1-b16的所有服务模块，而是可以根据实际需要在附图1中所示的服务管理平台b的基础上相应设置(例如删减或增加)各种服务模块。此外，尽管在图1中以互相分离的方式示出了各个服务模块b1-b16，但这仅仅是为了便于分别描述各模块的功能和作用，本领域技术人员完全理解，在实践中这些服务模块可以按照需要进行灵活的组合，例如可以将两个甚至更多个模块合并在一起实现多个功能，还可以将一个模块拆分开来实现其几个子功能，这样的变化并没有偏离本发明的精神实质，都属于本发明的保护范围之内。同样，本领域技术人员完全理解，在实践中这些服务模块并不一定需要用微服务的技术架构实现。理论上也可以用一个大型云端web服务器甚至其它技术实现。这样的具体实现方式也没有偏离本发明的精神实质，都属于本发明的保护范围之内。
个人信用基础认证模块b1用于对用户的基础账户信息进行确认，通常需要对用户的实名认证信息进行正确性验证。
个人征信码生成模块b2可以根据用户基础信息生成包含用户征信授权信息的征信码(例如是二维码的形式)，从而可以提供给需要查看该用户征信信息的他人进行信用互看共享。
查询审核模块b3根据系统确定的审核规则判定当前征信信息查询方是否已获得征信信息被查询方的授权。作为附加的特征，该审核规则还可以包括判定查询方是否已支付进行查询所需的费用。只有在通过审核后，才能继续进行查询流程。
聚合信用数据请求模块b4主要负责向各个征信源，即征信信息提供机构，请求对应查询人员的信用数据，并将请求得到的信用数据传输到信用加密处理模块b5处理。
移动端解密处理模块b6在用户通过查询审核模块b3的审核后，将当期需要的加密信用报告数据进行解密处理。
阅后即焚安全处理模块b7负责在征信信息查询方与服务管理平台之间建立临时链接，以便将征信信息被查询方的信用报告推送至征信信息查询方的移动端设备上。为此，阅后即焚安全处理模块b7还可设置倒计时钟，倒计时开始后，经过解密处理的信用报告通过链接推送到征信信息查询方的移动端设备上进行展示。当倒计时结束后，临时链接断开，在移动端设备上完成“阅后即焚”功能，即不再展示当前查询对象的信用报告。该“阅后即焚”功能有效地防止了在征信信息查询方与征信信息被查询方之间分享信用信息时对信用信息进行篡改和伪造，也增强了对信用信息安全性的保护。在此，需要注意的是，在本发明的公开说明书中，对于“链接”或“连接”这类术语，除非另有特别声明，其含义不仅包括用户终端、组件、单元、模块等的直接链接或连接，也包括通过其它中间部分实现的间接连接，只要能在两个“链接”或“连接”部分之间建立为其目的所需的链接或连接关系即可。
诚信互评模块b8主要用于当征信信息查询方查看过信息主体的征信后，在一定时间内可以对信息主体作出评价，例如可以给出“赞”或“踩”的评价，此评价数据可以被用作为平台聚合建模的强征信变量。在本发明的一些实施方式中，根据应用场景的不同，可以设置为点评方需要缴费才能进行评价。特别是，对于企业级的信息主体的评价，针对恶意或虚假差评可以通过建模监控和反馈机制来解决，这有利于征信信息以更透明的方式被使用，从而可增加信息主体的参与感。
本人征信配置信息获取模块b9可使用户实现对自身信用信息的控制权。例如，用户自己可以对征信码状态进行开和关的控制，可以对自己的征信报告进行自由定价。只有征信码处于开启状态时才表示同意授权他人查看自己的征信报告，当征信码状态处于关闭状态，他人通过扫码方式查看该用户的信用报告时会给出用户并未授权的告知。如果用户对自己的信用报告做了定价，他人查看该用户的信用报告时就需要支付定价的费用才能进行，这也使得信用查看更安全更透明。
代理认证模块b10的作用是完成信息主体想要代理他人信用报告时的认证。当完成认证后，代理授权请求码生成模块b11会为代理生成唯一的授权请求码，其他信息主体可以通过授权代理模块b12扫描该代理的授权请求码将自己的信用报告授权给对应代理人员。授权通过后，代理征信码生成模块b13将根据信息主体设置的授权有效期和授权对象生成临时征信码到代理移动端记录模块b14展示，当授权到期时，对应信息主体的临时征信码不再出现在代理记录模块b14内。信息主体可以通过移动端app或小程序上的扫码模块b15方便地扫描他人征信码查看他人征信报告，还可以扫描代理授权请求码将自己的征信报告授权给代理，极大地提高了个人与个人之间互看分享信用的易用性和便捷性。
信用报告加密存储模块b16的作用是将经信用加密处理模块b5加密过的用户信用报告或数据存储在服务端。当服务端接收到查询请求时，会将相应用户的加密信用报告推送给移动端解密处理模块b6处理。通过将用户的信用报告或数据以加密形式存储在服务端，可保证用户征信数据和信息的安全性。
返回到附图1中的个人移动端a，接下来对个人移动端a上的各种请求和服务加以详细说明。
a1：查看自己的征信请求需要通过调用聚合信用数据请求模块b4，信用加密处理模块b5和移动端解密处理模块b6，最后将信用报告展示在移动端app或小程序上进行查看。
a2：请求查看他人征信需要在移动端调用扫码模块b15，扫描他人提供的已授权的个人征信码，在某些具体实施方式中还需要完成付费后才能通过查询审核模块b3的审核。调用聚合信用数据请求模块b4请求他人的信用报告，通过信用加密处理模块b5将信用报告加密存储，根据阅后即焚安全模块b7生成的链接规则指向，调用移动端解密显示模块b6对加密报告进行解密后推送到请求查看方的移动端屏幕显示被查看方信用报告，并且启动倒计时，倒计时结束后执行“阅后即焚”的功能，完成信用报告的查看。随后还可形成查看记录并可进行诚信评价。
a3：授权他人查看本人征信需要展示个人征信码生成模块b2为每个信用主体生成的征信码，他人通过在移动端调用扫码模块b15扫描本人的征信码，他人移动端将调用本人征信配置信息获取模块b9，获取本人征信是否已开启授权查看的状态及信用报告的价位，他人进行付费后通过查询审核模块b3的审核，即可在移动端设备上方便地获得本人的信用报告，同时启动阅后即焚安全模块b7，在倒计时结束后，本人的信用报告不再展示在他人移动端，本人移动端将同步记录他人查看状态，当他人已经查看完成本人信用报告，会形成对应记录。如果有相应评价，本人还可以查看该评价。如果本人想要回看他人的信用报告，则同样需要征得他人同意方能查看，有时还需要在付费后查看。
a4：代理他人信用报告需要代理人通过代理认证模块b10的认证，认证通过后，会生成唯一的代理授权请求码。他人想要将征信报告给代理人时，会在他人移动端调用扫码模块b15和授权代理模块b12，授权完成后，代理征信码模块b13会为他人生成代理期限内的临时征信码，临时征信码将存储在代理记录模块b14中。当有第三方需要查看代理记录中人员的信用报告时，可以直接在代理人的移动端打开已获授权代理记录列表，第三方利用扫码模块b15对代理移动端上的临时征信码进行扫码并在付费后即可在第三方人员移动端屏幕展示被查看方信用报告。当阅后即焚计时结束后，完成信用报告的查看。当授权期限到期后，临时征信码不再出现在代理人的代理记录中，极大的保证了信用授权的安全性和便捷性。
a5：授权本人信用给代理时，会在本人移动端调用扫码模块b15和授权代理模块b12，授权完成后，随即生成记录可查看本人的信用报告已授权给哪些代理人员和授权期限。
a6：个人信用预警服务用于个人征信情况的监控和管理。根据本发明的技术方案，用户的征信数据是动态的，本发明的信用系统会定期获取信息主体新的征信数据，当发现任何一家征信机构对信息主体的征信结果有较大变化时，将发送通知到信息主体。并且，信息主体可以定义系统发送该通知的具体方式。因此，信息主体可以方便及时地了解自己信用状况的变化，可帮助信息主体更好地掌控和有效地经营自己的信用记录，从而获得更好的信用评级。
图2是利用本发明的信用系统查看自己的征信的处理流程图，包括以下步骤：
对应于附图1中个人移动端上的a1服务，用户可在移动端a上启用小程序或app查看自己的个人征信；
对应于附图1中服务管理平台上的b1模块，系统监测用户是否通过实名认证；
对应于附图1中服务管理平台上的b4模块，如果通过实名认证，则平台向第三方征信提供商发出聚合信用数据请求；
如未通过实名认证，则个人移动端上的a1服务结束本次查询(a1s2)。
平台向第三方征信提供商发出聚合信用数据请求后，对应于附图1中服务管理平台上的b5模块，平台将征信数据加密后存储在自己的数据库(例如在信用报告存储模块b16中)里；
对应于附图1中服务管理平台上的b6模块，平台将经加密的征信数据解密后传送到用户的个人移动端供用户查看；
此时个人移动端上的a1服务结束本次查询(a1s2)。
图3是利用本发明的信用系统请求查看他人征信的系统处理流程图，包括以下步骤；
对应于附图1中个人移动端上的a2服务，用户可在移动端a上启用小程序或app请求查看他人的征信；
对应于附图1中服务管理平台上的b1模块，个人基础信息认证模块对个人基本信息和实名认证信息进行验证；
在步骤a2s1处，系统判断是否通过认证。如果通过认证，则进入扫码模块；如果未通过认证，则进入认证流程；
对应于附图1中服务管理平台上的b15模块，系统调用扫码模块，可以通过代理提供的代理征信码(由代理征信码生成模块b13生成)来请求查看他人征信报告，也可以直接通过他人提供的个人征信码来请求查看他人征信报告；
对应于附图1中服务管理平台上的b3模块，系统调用查询审核模块，目的是审核被查看方的征信是否已经授权，是否已经成功完成付费审核；
在步骤a2s2处，根据审核结果判定，如果通过审核，则进入下一步，否则查找原因，继续进行审核；
在步骤a2s3处，可建立请求查看方与服务管理平台之间的临时链接；
对应于附图1中服务管理平台上的b4模块，系统调用聚合信用数据请求模块获得被查看方的信用报告数据；
在步骤a2s4处，判断是否获取报告成功；
对应于附图1中服务管理平台上的b5模块，数据获取成功后，进入信用加密处理模块，对获取到的信用报告加密后存储到数据库；
对应于附图1中服务管理平台上的b6模块，根据临时链接调用移动端解密显示模块将解密后的信用报告推送给请求查看方；
对应于附图1中服务管理平台上的b7模块，同步启动阅后即焚安全模块，开启倒计时；
在步骤a2s5处，在请求查看方的移动设备上展示被查看方的信用报告，可以继续阅读；
在步骤a2s6处，判断计时是否结束，如果结束则完成阅后即焚功能，使得查看方的设备上不再显示被查看方的信用报告；
在步骤a2s7处，在查看完成后可形成信用报告查看记录；
对应于附图1中服务管理平台上的b8模块，系统调用诚信互评模块，信用查看方可以对被查看方进行信用评价，例如给出“赞”或“踩”的评价，并将结果反馈到系统的聚合建模系统；
在步骤a2s8处，评价完成后即完成本次请求，
图4是利用本发明的信用系统授权他人查看本人征信的系统处理流程图，包括以下步骤；
对应于附图1中个人移动端上的a3服务，个人用户可授权他人查看自己的信用报告；
在步骤a3s1处，展示由个人征信码生成模块生成的唯一征信码；
在步骤a3s2处，他人可通过扫码模块扫描作为被查看方的个人展示的该征信码；
在步骤a3s3处，进入请求查看他人征信的流程(对应于附图1中个人移动端上的a2服务)，作为可选的实施方式，此时可在信用查看人向被查看人付款完成后才进行查看；
在步骤a3s4处，个人用户可记录他人的查看状态，例如待付款或者付款已完成的状态；
在步骤a3s5处，他人查看完用户本人的信用报告后，如果他人对本人的信用有评价，则本人可以查看该评价。
在步骤a3s6处，本人可以选择是否回看他人的信用。此时，本人和他人的角色互换，但具体的查看规则仍然不变。本人可点击回看功能进入回看流程，这相当于请求查看他人征信的流程(对应于附图1中个人移动端上的a2服务)。作为可选的实施方式，该流程的进行也需要付款后才能进行查看；
在步骤a3s7处，个人授权他人查看自己信用报告结束。
图5是利用本发明的信用系统代理他人信用报告的系统处理流程图，包括以下步骤：
对应于附图1中个人移动端上的a4服务，可在个人移动端a上通过app或小程序代理他人信用报告；
对应于附图1中服务管理平台上的b10模块，可启动代理认证模块，查看当前信用主体是否已通过认证(a4s1)；
在步骤a4s1处，如果通过认证，则由服务管理平台上的b11模块生成唯一代理授权请求码；
在步骤a4s2处，代理可向他人展示其授权请求码；
对应于附图1中个人移动端上的a5服务，他人通过个人移动端上的app或小程序启动授权本人信用给代理的流程；
在步骤a4s3处，判断他人是否已成功将征信授权给代理；
对应于附图1中服务管理平台上的b14模块，如果他人已成功将征信授权给代理，则将对应人员授权的代理征信码存储在已获授权列表中；
在步骤a4s4处，代理向第三方展示已获授权列表中某个人员的代理征信码；
在步骤a4s8处，第三方通过个人移动端上的app或小程序请求查看代理提供的某个人员的信用报告；
对应于附图1中服务管理平台上的b15模块，第三方启用扫码模块扫描代理提供的被查看人员的代理征信码；
对应于附图1中个人移动端上的a4服务，第三方启动请求查看他人征信码流程；
在步骤a4s9处，判断第三方是否已完成付款并查看完报告，如果完成则结束，否则继续查看；
在步骤a4s5处，第三方在启动查看他人征信流程时，代理的个人移动端会同步展示交易状态；
在步骤a4s6处，当第三方完成查看后，代理的个人移动端会生成交易记录；
在步骤a4s7处，因本次交易是由代理促成，可将产生的交易提成发送到代理端的零钱包；
在步骤a4s10处，结束完成代理他人信用报告流程。
图6是本发明的信用系统中个人信用基础信息认证模块的构建流程图，包括以下步骤：
在步骤b1s1处，用户登录/注册后可进入实名认证入口；
在步骤b1s2处，服务管理平台向用户展示上传身份证模拟图；
在步骤b1s3处，服务管理平台向用户提供隐私协议，用户可点击“隐私协议”链接，进入b1s4查看协议详细内容步骤；
在步骤b1s4处，用户点击“隐私协议”后，查看隐私协议详细内容；
在步骤b1s5处，若用户同意隐私协议，进入b1s6用户上传本人身份证步骤；若用户不同意隐私协议，返回b1s1实名认证入口；
在步骤b1s6处，用户上传本人身份证正面、反面照片；
在步骤b1s7处，用户检查/确认本人身份证照片是否正确；若用户确认本人身份证照片上传正确，进入b1s8身份证信息展示/修改步骤；若用户确认本人身份证照片上传不正确，返回b1s6用户上传本人身份证照片正反面步骤；
在步骤b1s8处，平台向用户展示上传的本人身份证照片正反面信息，用户可修改其中“姓名”，”身份证号“，”有效期“信息；
在步骤b1s9处，服务管理平台验证用户上传的本人身份证信息是否匹配；若用户上传的本人身份证信息匹配，进入b1s10个人信用基础信息认证完成步骤；若用户上传的本人身份证信息不匹配，返回b1s8身份证信息展示/修改步骤；
在步骤b1s10处，个人信用基础信息认证流程完成。
图7是本发明的信用系统中个人征信码生成模块的构建流程图，包括以下步骤：
在步骤b2s1处，获取个人信用基础信息；
在步骤b2s2处，从服务器配置文件获取个人信用报告api地址；
在步骤b2s3处，结合在步骤b2s1和b2s2获取到的数据，利用谷歌zxing进行程序编码，实现个人征信码的定制生成；
在步骤b2s4处，将程序生成的个人征信码保存到数据库；
在步骤b2s5处，个人征信码生成流程完成。
图8是本发明的信用系统中查询审核模块的构建流程图，包括以下步骤：
在步骤b3s1处，用户(例如第一用户)登录/注册后进入查询审核流程入口；
对应于附图1中服务管理平台上的b15模块，用户调用扫码模块，执行扫码模块流程；
在步骤b3s2处，平台验证被扫码用户(第二用户)个人征信码是否开启；若平台验证被扫码用户(第二用户)个人征信码是开启状态，进入步骤b3s3征信报告隐私提示和付费告知步骤；若平台验证被扫码用户(第二用户)个人征信码不是开启状态，返回步骤b3s1查询审核流程入口；
在步骤b3s3处，平台告知用户(第一用户)征信报告隐私提示和付费；
在步骤b3s4处，用户(第一用户)是否同意付费查看被扫码用户(第二用户)的个人征信报告；若用户(第一用户)同意付费查看被扫码用户(第二用户)的个人征信报告，则进入步骤b3s5，用户(第一用户)选择支付方式步骤；若用户(第一用户)不同意付费查看被扫码用户(第二用户)的个人征信报告，返回步骤b3s1查询审核流程入口；
在步骤b3s5处，用户(第一用户)选择支付方式；
在步骤b3s6处，平台验证用户(第一用户)支付是否成功；若平台验证用户(第一用户)支付成功，则调用阅后即焚安全处理模块(对应于附图1中服务管理平台上的b7模块)；若平台验证用户(第一用户)支付不成功，返回步骤b3s3征信报告隐私提示和付费告知步骤；
对应于附图1中服务管理平台上的b7模块，阅后即焚安全处理模块执行阅后即焚安全处理模块流程；
在步骤b3s7处，平台向用户(第一用户)展示被扫码用户(第二用户)的个人征信报告详情；
在步骤b3s8处，查询审核流程完成。
图9是本发明的信用系统中聚合信用数据请求模块的构建流程图，包括以下步骤：
在步骤b4s1处，获取个人信用基础信息，包含个人身份证号以及姓名等；
在步骤b4s2处，根据个人身份证号以及姓名，获取个人征信的多个征信提供商；
在步骤b4s3处，不同的征信提供商根据个人身份证号以及姓名等分别返回各自的个人征信数据；
在步骤b4s4处，将不同征信提供商提供的个人征信数据，利用聚合算法，进行格式化处理；
在步骤b4s5处，聚合信用数据请求流程完成。
图10是本发明的信用系统中信用加密处理模块的构建流程图，包括以下步骤：
在步骤b5s1处，聚合格式化后的个人信用信息；
在步骤b5s2处，程序使用加密算法(例如aes)对信用数据进行加密；
在步骤b5s3处，将加密后的个人信用数据保存到数据库；
在步骤b5s4处，信用加密处理流程完成。
图11是本发明的信用系统中移动端解密处理模块的构建流程图，包括以下步骤：
在步骤b6s1处，从数据库读取加密的个人信用数据；
在步骤b6s2处，程序使用解密算法(例如aes)对加密的信用数据进行解密；
在步骤b6s3处，解密完成后，在移动端展示解密后的个人信用报告；
在步骤b6s4处，信用解密处理流程完成。
图12是本发明的信用系统中阅后即焚模块的构建流程图，包括以下步骤：
在步骤b7s1处，个人用户请求查看他人的个人信用报告；
对应于附图1中服务管理平台上的b3模块，调用查询审核模块进行相关审核；
在步骤b7s2处，若审核成功则进入b7s3建立查看关系步骤，若不成功则进入步骤b7s1进行重新请求；
在步骤b7s3处，在服务器端建立请求人和被查看信用报告关联关系；
在步骤b7s4处，设置请求人能阅读信用报告的时长；
在步骤b7s5处，等待请求人阅读信用报告；
在步骤b7s6处，若请求人选择马上阅读信用报告，则进入步骤b7s7开始阅后即焚倒计时，若请求人不立即阅读报告，则进入步骤b7s5继续等待请求人阅读信用报告；
在步骤b7s7处，开启信用报告销毁倒计时；
在步骤b7s8处，在移动端向请求人展示被查看的信用报告；
在步骤b7s9处，若阅读倒计时已经结束，则进入步骤b7s10，将移动端信用展示界面自动销毁，若倒计时未结束继续在步骤b7s8展示他人信用报告；
在步骤b7s10处，在移动端将展示他人信用报告的界面自动销毁，页面跳转到默认首页；
在步骤b7s11处，在服务器端，设置请求人和被查看信用报告关联关系失效；
在步骤b7s12处，阅后即焚安全处理流程完成。
图13是本发明的信用系统中本人征信配置信息获取模块的构建流程图，包括以下步骤：
在步骤b9s1处，获取个人信用基础信息；
在步骤b9s2处，判断当前个人征信码设置状态为开启还是关闭。如果当前个人征信码设置状态为关闭，则说明本人未授权他人扫码查看本人征信，如果设置状态为开启，则说明本人已同意他人扫码查看本人征信；
在步骤b9s3处，获取个人征信报告当前的定价；
在步骤b9s4处，将获取的征信配置信息存储到数据库；
在步骤b9s5处，完成对本人征信信息的获取。
图14是本发明的信用系统中代理认证模块的构建流程图，包括以下步骤：
在步骤b10s1处，用户(例如第三用户)登录/注册后进入代理认证流程入口；
在步骤b10s2处，用户填写邮箱信息；
在步骤b10s3处，平台验证用户填写的邮箱信息是否通过邮箱格式验证；若用户填写的邮箱信息通过邮箱格式验证，进入步骤b10s4用户填写工作信息步骤；若用户填写的邮箱信息未通过邮箱格式验证，返回步骤b10s2用户填写邮箱信息；
在步骤b10s4处，用户填写本人工作信息；
在步骤b10s5处，用户上传本人名片/工作证件；
在步骤b10s6处，用户确认本人名片/工作证件是否正确上传；若用户确认本人名片/工作证件正确上传，进入邮箱信息/工作信息/名片/工作证件信息展示/修改步骤(b10s7)；若用户确认本人名片/工作证件上传不正确，返回用户上传本人名片/工作证件步骤(b10s5)；
在步骤b10s7处，平台向用户展示上传的本人邮箱信息/工作信息/名片/工作证件信息；
在步骤b10s8处，平台验证用户上传的本人邮箱信息/工作信息/名片/工作证件信息是否匹配；若用户上传的本人邮箱信息/工作信息/名片/工作证件信息匹配，进入代理认证流程完成步骤(b10s9)；若用户上传的本人邮箱信息/工作信息/名片/工作证件信息不匹配，返回邮箱信息/工作信息/名片/工作证件信息展示/修改步骤(b10s7)；
在步骤b10s9处，代理认证流程完成。
图15为本发明的信用系统中授权代理模块的构建流程图，包括以下步骤：
在步骤b12s1处，用户(例如第一用户)登录/注册后进入授权代理流程入口；
在步骤b15处，调用扫码模块，执行扫码模块流程；
在步骤b12s2处，进入用户本人信用报告授权页面；
在步骤b12s3处，用户选择本人信用报告授权时效并确认是否同意授权信用报告给代理(第三用户)；若用户同意授权信用报告给代理，进入平台验证是否授权成功步骤(b12s4)；若用户不同意授权信用报告给代理，返回授权代理流程入口步骤(b12s1)；
在步骤b12s4处，平台验证用户授权本人信用报告给代理是否成功；若平台验证用户授权本人信用报告给代理成功，进入授权代理流程完成步骤(b12s5)；若平台验证用户授权本人信用报告给代理不成功，返回用户本人信用报告授权页面步骤(b12s2)；
在步骤b12s5处，授权代理流程完成。
图16为本发明的信用系统中代理征信码生成模块的构建流程图，包括以下步骤：
在步骤b13s1处，获取代理人(第三用户)信息；
在步骤b13s2处，获取(第一用户的)个人信用基础信息；
在步骤b13s3处，从服务器配置文件获取代理征信码api地址；
在步骤b13s4处，结合在步骤b13s1、b13s2和b11s3获取到的数据，利用谷歌zxing进行程序编码，实现代理征信码的定制生成；
在步骤b13s5处，将程序生成的代理征信码保存到数据库；
在步骤b13s6处，代理征信码生成流程完成。
图17为本发明的信用系统中代理授权请求码生成模块的构建流程图，包括以下步骤：
在步骤b11s1处，获取代理人(第三用户)信息；
在步骤b11s2处，从服务器配置文件获取代理授权请求码api地址；
在步骤b11s3处，结合步骤b11s1和b11s2获取到的数据，利用谷歌zxing进行程序编码，实现代理授权请求码的定制生成；
在步骤b11s4处，将程序生成的代理授权请求码保存到数据库；
在步骤b11s5处，代理授权请求码生成流程完成。
图18为本发明的信用系统中授权本人信用给代理的系统流程图，包括以下步骤：
对应于附图1中个人移动端上的a5服务，用户(例如第一用户)可将本人信用授权给代理；
对应于附图1中服务管理平台上的b15模块，本人(第一用户)可以扫描代理(第三用户)展示的授权请求码；
对应于附图1中服务管理平台上的b11模块，代理可展示授权请求码让本人扫描；
对应于附图1中服务管理平台上的b12模块，本人将自己的信用授权给代理并设置授权有效期；
在步骤a5s1处，完成授权后代理在已获授权信用列表里可以查看到记录；
在步骤a5s2处，判断是否有第三方查看了本人的信用；
在步骤a5s3处，如果是，则生成查看方的查看记录以及查看方对本人信用的评价；
在步骤a5s4处，可以选择是否回看查看方的信用；
对应于附图1中个人移动端上的a2服务，点击回看则启动查看他人征信的流程，作为优选实施方式，此时需获得授权并完成相应付款方能查看；
在步骤a5s5处，本人信用授权给代理结束。
图19是本发明的信用系统中不同场景信用分聚合建模模块的构建流程图，包括以下步骤；
在步骤b16s01处，获取用户的信用基础信息，其可包含个人身份证号以及姓名等或者企业法人、企业名称以及税号等；
在步骤b16s02处，根据获得的用户信用基础信息，系统从多个征信提供商处获取个人或者企业的征信数据；
在步骤b16s03处，不同的征信提供商分别返回个人或者企业征信数据；
在步骤b16s04处，获取他人在查看信用报告后对个人或者企业的评价结果；
在步骤b16s05处，将不同的征信提供商获取到的个人或者企业征信数据，进行聚合。结合在步骤b16s04返回的评价数据，然后根据不同的特定场景进行归类建模；
在步骤b16s06处，产生不同特定场景的信用数据，对于同一个信息主体，可以针对不同场景给出不同的“场景信用分”；
在步骤b16s07处，场景信用分聚合建模流程完成。
图20是本发明的信用系统中动态征信码的构建流程图，包括以下步骤：
在步骤s01处，第一用户在其个人移动端上的app或小程序上点击个人征信码缩略图后，系统启动动态征信码生成过程，可使每次产生的征信码均不同；
在步骤s02处，获取征信码中静态参数部分，该静态参数部分属于征信码中不发生变化的部分(例如为一固定的下载地址)，系统可根据需要对其进行预先配置，这部分信息是和用户不相关的信息；
在步骤s03处，获取用户设置的征信码相关动态参数，该动态参数可以是用户设定的信息，例如征信码的有效期限；
在步骤s04处，对征信码进行安全加锁，为后续真伪验证做基础；
在步骤s05处，生成征信码相关动态信息并以二维码方式返回给第一用户同时将动态征信码相关信息存储到服务端；
在步骤s06处，在移动端显示第一用户当前生成的个人征信码。
图21是本发明的信用系统中扫描征信码时的安全控制流程，包括以下步骤：
在步骤s01处，第一用户在移动端打开扫码模块扫描第二用户的个人征信码；
在步骤s02处，第一用户的扫码端进行征信码安全解锁，进行防伪验证；
在步骤s03处，判定该征信码是否为伪造的码，如果是，则告知无法识别(步骤s04)，并退出扫码流程(步骤s07)；如果不是，判定该征信码为软件合法可识别的码，则继续进入步骤s05；
在步骤s05处，判定该征信码是否已过期，如果是，则告知用户该征信码已失效(步骤s06)，并退出扫码流程(步骤s07)；如果不是，判定该征信码当前处于有效日期内，则继续进入步骤s08；
在步骤s08处，进入扫码后续流程。本发明的信用系统通过该安全控制流程，可防止伪造及过期的征信码的使用，降低信用查看时的不安全影响因素。
以上描述了本发明的一些具体实施例，对本发明的基本原理和主要特征进行了详细的阐述。本领域技术人员理解，在不脱离本发明的范围和实质情况下，对本发明所作的改变和变化仍然属于本发明的保护范围。本发明的保护范围应该以所附的权利要求确定，而不应仅限于以上描述的具体实施方式。例如，在上述的多个实施例中，主要是针对在个人用户和个人用户之间分享互看个人征信进行说明，然而，本领域技术人员理解上述的各个实施方式同样适用于在个人用户与企业用户之间，以及在企业用户和企业用户之间分享和互看个人征信数据和/或企业征信数据。此外，在以上所述的实施例中，在用户之间分享和互看征信数据主要是利用用户移动终端上的扫码模块对被查看方提供的征信码进行扫描操作实现的。然而，对此也可以由其它替代方式，例如可以基于短程通信技术(例如nfc或者蓝牙协议)在用户的移动端之间产生互动，发送获取对方征信数据的请求以及将征信数据传送给请求方等。在实践应用中，这种用户移动终端之间的交互可以呈现为业界所知的“摇一摇”的方式。
需要注意的是，在发明的公开文本中所使用的诸如“第一”、“第二”等的措辞可以泛指本发明各实施例的各种元件和组件，其目的只是用于将相关元件与另一元件区分开，而并不限定元件的先后顺序和/或优先级别。例如，第一用户移动终端和第二用户移动终端可以表示不同用户(第一用户或第二用户)的移动终端，而与用户移动终端的顺序和重要性无关。因此，在不脱离本发明精神实质的情况下，第一用户移动终端可以被称为第二用户移动终端，同样，第二用户移动终端也可被称为第一用户移动终端。此外，根据本发明各实施例的模块或服务程序执行的操作可以不限于以上所述的具体顺序进行，而是可以采用其它的顺序或者以并行方式执行。此外，本领域技术人员理解，这些操作中的有些具体步骤可以省略，或者也可以添加其他执行步骤。