{"text_format":"2","workbook":"xlsx","n_sheets":15,"sheets":["2.19-2.23","2.26-3.1","3.4-3.8","3.11-3.15","3.18-3.22","3.25-4.03","4.8-4.19","4.22-4.30","5.6-5.17","5.20-6.14","6.17-7.18","7.19-8.2","8.5-8.29","8.30~","WpsReserved_CellImgList"],"not_rendered":{"charts":0,"images":3,"macros":0,"external_links":0,"defined_names":3,"comments":0,"pivot_tables":0},"unopened":[],"bounds":{"document_bytes":16777216,"sheet_cells":100000,"run_cost":"one","rows_first":2000,"rows_last":500,"rows_between":2000,"halvings":0,"cell_chars":16384,"cell_head_chars":4096},"cells_cut":0,"cells_raw":0,"read":"whole","date_system":"1900"}

{"sheet":"2.19-2.23","index":0,"n_rows":47,"n_cols":13,"rows_kept":47,"cut":false,"hidden":false,"merged":[[0,0,0,6],[0,7,0,12]]}
["招商银行 专利挖掘清单",{"$nulls":6},"代理人填写"]
["序号","建议申请类型","专利名称（暂定名称）","主要发明点/方案简述","解决技术问题及效果","发明人","中心/团队/室","检索的最接近对比文件","检索分析\n（与对比文件相比的区别点）","待发明人补充内容\n（挖掘现场代理人提出需要发明人补充的内容）","检索结果\n如：补充内容后建议申请XX专利\n建议拆分专利（说明拆分内容）\n不建议申请，说明原因","建议申请类型","检索人"]
[1,"发明","一种基于多轨道周期调度算法的栏目检测方案","1.回检任务周期划分\n2.触发器控制\n3.周期起止计算\n4.月份偏移处理\n5.栏目检测问题闭环处理","问题：官网栏目众多、运维责任方遍布全行，仅仅依靠制度规则和人为回检难免出现疏漏\n效果：\n1. 根据各个栏目设定的运维频率（如每月、每季度、每半年）自动触发回检，检查最近一次更新时间\n2. 按照不同回检结果，以邮件或招乎形式发送相应提示信息至负责行部或人员\n3.减轻总行业务部门对于官网栏目的人工督办效率，为银行提升内部管理效率。","钟婷/80274938","零售应用研发中心/网络应用开发团队/网上银行二室(杭州)"," CN114186570A 集成读卡器设备运维方法、装置、计算机设备和存储介质","本申请根据各个栏目设定的运维频率（如每月、每季度、每半年）自动触发回检，通过周期起止计算与月份偏移来实现周期调度算法，与对比文件中的预设设备采集时间不同。\n基于上述区别点，本申请具备新颖性和一定的创造性。","建议补充有关适应业务需求以进行周期划分以及月份偏移计算的具体过程","补充内容后建议申请发明专利","发明","潘远帆"]
[2,"发明","一种基于流量分析的敏感信息筛查方案","1.通过用户行为驱动+定时任务补偿的组合架构，实现网站内容遍历时间和空间上的降级处理。\n2.通过内容分类过滤、数据去重、分批存储、MySQL+HBase组合存储，实现疑似敏感信息内容分类解析。\n3.分级跑批任务、引入消息队列进行内容送审形成初筛结果。\n4.针对初筛结果中的高频词进行语义分析与组合词分析，降低敏感信息误报率。","问题：普通爬虫遍历网站只能触达3级目录，也无法爬取专属链接页面内容。全量内容送审引发审核服务数据库压力过载。\n效果：\n1.从遍历时空复杂度上降级为一维线性遍历搜索。\n2.轻量化对接流量监测即可进行敏感信息筛查。\n3.保障数据库安全，可以杜绝全表扫描带来的生产安全隐患。\n4.引入消息队列异步获取文件审核结果，避免对结果的轮询，降低审核服务的底层数据库压力。\n5.降低敏感信息误判率，提升二次人工确认的工作效率。","杨剑/80274649","零售应用研发中心/网络应用开发团队/网上银行二室(杭州)","CN110069686A 用户行为分析方法、装置、计算机装置及存储介质 ","不同于对比文件，本申请对于发出敏感词的用户身份并不过度关注，而是关注用户的历史行为，以确定其偏好，结合用户行为驱动和定时任务补偿，通过内容分类过滤、数据去重、分批存储、MySQL+HBase组合存储，实现疑似敏感信息内容分类解析且对敏感词进行初步筛选，以降低敏感词误报率，区别点在于：\n1.通过用户行为驱动+定时任务补偿的组合架构，实现网站内容遍历时间和空间上的降级处理\n2.针对初筛结果中的高频词进行语义分析与组合词分析，降低敏感信息误报率。\n基于上述区别点，本申请具备新颖性和一定的创造性。","建议补充组合架构的架构图以及流量分析的具体流程图","补充内容后建议申请发明专利","发明","潘远帆"]
[3,"发明","一种基于接口特征集筛选方法的网点接口编排方案","1)提出了一种基于特征集匹配的接口自动生成映射方案\n2)接口新生成后，通过一次性部署的两个微服务模块，可以实现无需部署，直接调用，即配即用。\n3)接口权限控制一体化，在自动生成接口的同时可以配置发布、暂停、删除接口等权限。\n4)支持高度定制化的接口需求，如接口名定制、接口路径定制、接口生命周期管理、接口响应数据分类定制。\n5)接口服务实现了线程安全的事务性缓存，保证所有动态数据同步更新。","问题：每新增一个接口就需要一整个项目开发周期的时间，费事费力。\n效果：\n提供了一种基于接口特征集筛选方法的接口自动生成方案，该方案先通过接口管理微服务模块收集接口各维度特征集矩阵，再基于网点接口微服务，从数据库获取全量数据，存入一个定时刷新的事务性缓存；从该缓存中获取数据，先根据结果集的特征值序列筛选出一阶段储数集合，将中各叶子结点字段添加一阶映射标记；再以为基础，根据过滤集的特征值序列过滤出二阶段储数集合，将中各叶子字段添加二阶映射标记，此时中包含有m乘n个响应结果字段。最后通过各叶子字段的映射标记进行映射溯源处理，将同一维度的网点数据分组排列，返回最终响应数据。","郭春明/80296567","零售应用研发中心/网络应用开发团队/网上银行二室(杭州)"," CN117036008A 一种多源数据的自动化建模方法及系统 ","对比文件描述了一种多源数据自动化建模方法，包括获取样本、数据加工、生成数据表、划分数据、特征工程、建立模型和模型配置等步骤。本申请则提出了一种基于特征集匹配的接口自动生成映射方案，并能够自动实现调用接口生成。相比之下，区别点在于：1.接口权限控制一体化，在自动生成接口的同时可以配置发布、暂停、删除接口等权限。2.支持高度定制化的接口需求，如接口名定制、接口路径定制、接口生命周期管理、接口响应数据分类定制。\n基于上述区别点，本申请具备新颖性和一定的创造性。","建议补充接口特征集筛选方法的具体流程","补充内容后建议申请发明专利","发明","潘远帆"]
[4,"发明","一种基于增量更新的clickhouse关联表维护方法","针对关联表可以获取增量更新数据的场景，提出一种基于增量更新的clickhouse关联表维护方法。首先由关联右表分批进行Distributed hash join构造初始的连接结果表。在后续连接表更新的过程中使用关联表增量数据关联的方式,获取关联结果的增量更新数据。再利用ReplacingMergeTree表引擎删除排序键值相同的重复项的特性，删除增量结果和初始结果表中的重复项，实现clickhouse关联表的增量维护。","问题：目前clickhouse在join的主要是单机的hash join。具体做法是将右表作为build表构建hash表，左表作为probe表，按照block遍历左表来实现join。但对两张分布式大表join会存在乘数放大等问题，当前的解决方案主要是构建分布式join，需要按照hash key列来进行全局的数据重分布，然后在每个节点进行join，最后merge各个节点上的结果。上述的方案存在以下问题：1)由于需要由右表在内存全量构造hash，存在OOM风险。2)对于关联表和关联结果都需要全量更新入库，耗费大量机器资源与时间。\n效果：\n1)对于增量数据关联操作，无需在内存全量构建hash表，降低OOM失败风险\n2)增量更新关联表和关联结果表，减少入库数据，提升更新效率","徐角","零售应用研发中心/网络应用开发团队/网上银行二室(杭州)","CN112966188A 收藏商品状态更新方法及其装置、设备与介质 ","对比文件根据商品增量状态表更新该用户收藏表，借助内存操作实现海量商品的收藏关系的维护处理，提升了电商平台的运行效率及响应速度，本申请针对关联表可以获取增量更新数据的场景，提出一种基于增量更新的clickhouse关联表维护方法。相比之下，区别点在于：1.应用场景不同；2.利用ReplacingMergeTree表引擎删除排序键值相同的重复项的特性，删除增量结果和初始结果表中的重复项，实现clickhouse关联表的增量维护。\n基于上述区别点，本申请具备新颖性和一定的创造性。","建议补充数据关联表增量更新的具体流程以及示意图","补充内容后建议申请发明专利","发明","潘远帆"]
[5,"发明","分布式统一接触管控方案","利用分布式内存网格和管控规则，实现客户接触频次和额度的多维管控","目前我们系统（营销统一接触）主要功能是用来集中管理、控制营销信息的投放，防止营销信息过度打扰客户，实现以“一个银行”的形式对客户提供营销内容服务。其中接触管控主要基于分布式内存网格，利用管控规则，实现客户接触频次和额度的多维管控，有效的避免客户打扰和","张雷/80374520","零售应用研发中心/零售客户经营开发团队/零售信息应用开发六室(杭州)","CN113423075A 短信发送的控制方法、装置、电子设备、存储介质及产品 ","对比文件在不对用户进行骚扰的前提下，通过对手机号码添加预设盐值，然后对添加盐值后的手机号对第一服务器的总个数取余，并根据余数选择对应编号的第一服务器，最后，将手机号码和待发短信的内容到选择的第一服务器，避免了对用户的打扰。本申请则利用分布式内存网格和管控规则，实现客户接触频次和额度的多维管控。区别在于：接触管控主要基于分布式内存网格，利用管控规则，实现客户接触频次和额度的多维管控。\n基于上述区别点，本申请具备新颖性和一定的创造性。","建议补充分布式内存网格和管控规则的具体内容","补充内容后建议申请发明专利","发明","潘远帆"]
[6,"发明","通用权限中心服务方案","1.中心化的授权机制与零业务代码侵入的接口权限控制\n2.系统可视化配置界面低代码外输共享\n3.智能权限审计策略\n4.权限API接口高可用与稳定性","问题：\n1)系统间权限模块重复建设，权限模块与业务模块耦合太深，难以实现配置即生效，权限易混乱，缺乏灵活的权限治理方案\n2)权限接口的高并发\n3)权限的回检策略\n4)缺乏可共享的前端可视化配置方案\n效果：\n1)通过权限模型对系统权限进行抽象解耦，通过对资源（菜单，按钮等）、角色、岗位的抽象，提炼权限相关服务以接口的形式服务于业务场景，以满足接入方的二次开发\n2)通过引入缓存、降级、熔断及高性能灰度网关，提供高性能的权限API中心服务，助力于接入方二次开发权限应用及高效接入\n3)平台每日根据用户订阅规则例如：离职人员清理、人员异常登录、数据权限与机构不匹配和权限重复等进行治理，并且提供权限操作的日志级的记录以满足后续审计需求\n4)提供可视化的前台配置中心，实现配置即更新的热更新能力，支撑业务场景的权限动态调整，提供前端页面及后端组件的外输服务，接入方可一行代码即实现系统权限能力复用","文传勇/80256963","总行/信息技术部/零售应用研发中心/零售客户经营开发团队/零售基础客群经营开发室(成都)","CN117472543A 一种基于容器云平台的标准化发布方法 ","对比文件通过容器云中原生的权限控制系统RBAC进行角色的分离与权限的控制，而本申请通过中心化的授权机制与零业务代码侵入的接口权限控制提供通用权限中心服务，区别点在于：1.通过权限模型对系统权限进行抽象解耦，通过对资源（菜单，按钮等）、角色、岗位的抽象，提炼权限相关服务以接口的形式服务于业务场景，以满足接入方的二次开发 2.通过引入缓存、降级、熔断及高性能灰度网关，提供高性能的权限API中心服务，助力于接入方二次开发权限应用及高效接入。\n基于上述区别点，本申请具备新颖性和一定的创造性。","建议补充权限模型对系统权限进行抽象解耦的具体流程以及示意图","补充内容后建议申请发明专利","发明","潘远帆"]
[7,"发明","开箱即用的通用智能搜索引擎方案","1. 搜索功能丰富，可扩展性强                                 2. 搜索精度高、分词模式多                                   3. 开箱即用的搜索组件                                       4. 词库实时热更新                                         5. 自定义ES数据源扩展","问题：                                                     1. 搜索精度低，搜索体验差                                  2. 功能单一，扩展性差                                      3. 业务功能耦合，可移植性差                                 4. 不支持自定义数据源                                      效果：                                                     1、相比IK、Ansj等ES分析器，本方案自研的ES分析器提供多达七种分词模式，其中极速词典分词速率高达2000万字/秒，分词速度极快，CRF分词能达到96%的分词精度，精确度极高，充分满足各种搜索场景下对于速度和精度的要求。                                          2、与IK、Ansj等ES分析器更新词库存在时延或需重启ES服务器不同，本平台基于JDK WatchService和Nacos监听的方案能够做到实时热更新词库，及时更新及时生效、无时延，更不需要重启ES服务器，极大提升了用户搜索体验和服务可用性。                                 3、使用我们提供的JS SDK，只需要极简的几行代码，在五分钟内，即可为系统接入完整的站内搜索功能，与业务逻辑完全解耦合，具备极高的可移植性和易用性。                                        4、与传统搜索方案只支持通过REST API、爬虫等方式获取文档数据不同，本方案支持自定义ES数据源扩展，接入方可以使用自己的ES数据源，提高了数据的安全性。","陈强/80280631","总行/信息技术部/零售应用研发中心/零售客户经营开发团队/零售基础客群经营开发室(成都)\n","CN115718795A 一种搜索违禁词的红名单实现方法、系统、设备及终端 ","对比文件结合了检索人员的红名单权限等级，实现违禁词与检索人员权限等级相关联，以Elasticsearch搜索引擎为核心，利用其倒排索引、分析器等特性实现违禁词精准匹配、快速检索，而本申请的ES分析器为自主研发的搜索引擎，相比之下，区别点在于：1.本方案自研的ES分析器提供多达七种分词模式，其中极速词典分词速率高达2000万字/秒，分词速度极快，CRF分词能达到96%的分词精度，精确度极高；2.本平台基于JDK WatchService和Nacos监听的方案能够做到实时热更新词库，及时更新及时生效、无时延，更不需要重启ES服务器 3.本方案支持自定义ES数据源扩展。\n基于上述区别点，本申请具备新颖性和一定的创造性。","建议补充ES分析器具体的应用场景以及具体实施例","补充内容后建议申请发明专利","发明","潘远帆"]
[8,"发明","跨技术栈的前端代码工程质量提升工具","1、重复代码识别准确率高\n2、无代码侵入、开箱即用的工具\n3、可视化的代码重构建议\n4、支持所有通用前端文件库\n5、智能化统计报告","问题：\n1、代码负债率持续升高，需求交付时长增加\n2、开发及线上代码性能降低，降低开发人员效能\n3、代码影响分析识别困难，重构成本高\n效果：\n1、代码复杂度可控：持续代码质量监控，避免工程代码变成巨无霸，保持较低的复杂度，便于维护与开发，为业务发展铺平道路。\n2、组件复用率提升：代码优化过程中，提炼多个业务组件，使前端能力能够组件化输出。不仅提高了单个系统的开发效率，还为其他系统提供组件服务。\n3、重构成本降低：通过全链路的辅助，可快速定位前端代码工程存在的问题，并给出解决方案和影响分析。在重构实践过程中，时间成本降低了50%，并且未造成线上问题。","唐文飞/80327443","总行/信息技术部/零售应用研发中心/零售客户经营开发团队/零售基础客群经营开发室(成都)\n","CN113190269A 一种基于编程上下文信息的代码重构方法 ","对比文件根据编程项目的上下文信息，对编程项目的需求文档、设计文档、缺陷报告和代码结构进行分析，形成编程上下文模型，对于给定的标识符通过编程上下文模型，重构来源列表，本申请则提供一种跨技术栈的前端代码工程质量提升工具，也即一种代码辅助插件，相比之下，区别在于：\n1.无代码侵入、开箱即用的工具\n2.可视化的代码重构建议。\n基于上述区别点，本申请具备新颖性和一定的创造性。","建议结合具体的实施场景补充代码监控、重构的实现过程","补充内容后建议申请发明专利","发明","潘远帆"]
[9,"发明","大数据集群HDFS小文件治理方案","\n1.采用FSImage文件代替传统HDFS Api方式对HDFS文件统计，在不影响集群性能的情况下实现无入侵式的小文件检测.\n2.每日自动化生成报表帮助开发人员快速定位小文件产生原因并提供相应解决方案.\n3.基于小文件数量及分区对冷数据进行自动化小文件合并.\n4.提供开箱即用的功能帮助开发人员快速处理小文件.","问题：\n1.原厂商未提供小文件治理方案.\n2.过多的小文件将占用更多namenode节点内存.\n3.小文件数量较多，运行时耗费大量集群资源，可能导致应用启动/执行失败.\n\n效果：\n1.小文件数量总计减少约40%.\n2.namenode内存占用减少约30%.\n3.因小文件导致的HDFS服务故障率降为0.\n4.HDFS查询性能提升一倍以上.","欧阳龙/80331357","总行/信息技术部/零售应用研发中心/网络应用开发团队/互联网支付室","CN117520270A 一种HDFS小文件优化及分析处理的方法及装置 ","对比文件从Hadoop文件系统中获取FSImage元数据文件并解析得到文件信息，从而实现对小文件进行合并并处理，而本申请采用FSImage文件代替传统HDFS Api方式对HDFS文件统计，在不影响集群性能的情况下实现无入侵式的小文件检测，区别在于：\n1.每日自动化生成报表帮助开发人员快速定位小文件产生原因并提供相应解决方案。\n2.提供开箱即用的功能帮助开发人员快速处理小文件。\n基于上述区别点，本申请具备新颖性和一定的创造性。","建议补充结合实际的业务需求，快速定位小文件产生原因以及相应解决方案的具体实施过程","补充内容后建议申请发明专利","发明","潘远帆"]
[10,"发明","高性能速率可控活动营销发奖方案","1）通过将名单分组归并批量插入和异步线程池等方式，提升了整个批量发奖系统的吞吐率，可支撑千万级多批次大名单实时发放。\n2）根据名单数量级区分不同的发奖流程，保证发奖流程中各处理节点的设计思路和名单数量级精准匹配，提高系统整体名单发放速度。\n3）针对不同活动的发放特点，进行参数设置调优，最大化利用发奖接口能力，达到资源利用的最大化，即系统吞吐率的提升。\n4) 发奖进度监控可观测。系统对整个发奖业务流转过程，进行了可视化的发放进度展示。","问题：\n1．批量发奖速度不稳定，难以维持高速率发放，出现尖刺现象。\n2. 核心发奖流程冗长效率低。\n3. 批量发奖时效性较差，活动时间段较为集中，造成大批量活动在排队。\n4．发奖名单数量级超大型活动配置成本较高。\n\n效果：\n1. 可保证恒定的发奖速率进行发放，且保持较高TPS，TPS峰值为1万。\n2. 精简业务流程，保证活动上线到发放的最短业务路径，路径缩短了40%。\n3. 提示系统吞吐率，活动排队等待时间下降30%。\n4. 提升名单数量级上限，由100W提升到500W，远期可横向扩展。","王心阳/80254359","总行/信息技术部/零售应用研发中心/网络应用开发团队/互联网活动开发室","CN111612469A 签约方法、支付系统及移动电子设备 ","对比文件描述了一种由所述支付系统执行的签约方法，将签约运营信息以及发奖情况进行可视化展示。本申请通过将名单分组归并批量插入和异步线程池等方式，基于名单数量级进行分类，并根据业务需求进行参数动态调整，相比之下，区别点在于：\n1.将名单分组归并批量插入和异步线程池等方式，提升了整个批量发奖系统的吞吐率，可支撑千万级多批次大名单实时发放\n2.根据名单数量级区分不同的发奖流程，保证发奖流程中各处理节点的设计思路和名单数量级精准匹配\n3.针对不同活动的发放特点，进行参数设置调优。\n基于上述区别点，本申请具备新颖性和一定的创造性。","建议补充据名单数量级区分不同的发奖流程的具体实现过程，并提供有关针对不同活动的发放特点，进行参数设置调优的实例","补充内容后建议申请发明专利","发明","潘远帆"]
[11,"发明","外发灰度解决方案","外发类系统全流程灰度方案\n1、数据+应用灰度\n2、多种灰度策略\n3、自动检测灰度过程，自动异常处理和熔断","问题：外发类应用目前没有健全的全流程灰度方案，每次发布只能部分灰度，有较大的发布风险\n效果：通过完整的全流程灰度方案，确保发布过程的充分验证和逐渐切流，降低发布导致的生产事故的风险","丁小龙/80274815","零售应用研发中心/零售客户经营开发团队/零售信息应用开发六室(杭州)","CN111580855B 一种基于全流程灰度发布的策略发布方法、系统和电子设备 ","对比文件在生产系统中自动灰度发布待发布的策略，配合预设的影子系统，根据预定的灰度发布规则将所述待发布的策略发布到所述生产系统中。本申请对全流程灰度方案进一步完善，通过完整的全流程灰度方案，确保发布过程的充分验证和逐渐切流，降低发布导致的生产事故的风险。相比之下，区别点在于：数据+应用的灰度。\n基于上述区别点，本申请具备新颖性和一定的创造性。\n","建议补充完善全流程灰度方案在具体生产过程中的具体实施方式","补充内容后建议申请发明专利","发明","潘远帆"]
[12,"发明","会话意图识别全流程自动化建模解决方案","1. 通过模型+策略实现自动化的会话意图识别，准确率高，覆盖面广\n2. 分层设计，数据模型解耦，开箱即用的规则/模型算子\n3. 自动化的机器标注\n4. 一键式的模型训练/部署\n5. 实时热更新的配置化知识库","问题：\n电/面访途径的文本/音频等非结构化数据繁杂冗长，通过人工无法全面、快速获取其中关键信息，费时费力，导致数据无法发挥其价值。\n\n效果：\n提供了一种自动化的会话意图识别建模方案，它能够支持人员快速、便捷的完成标注-数据处理-训练/验证-部署整套流程，实现建模的自动化、配置化、可视化，大大减少工作量，降低建模门槛，缩短建模周期","李嘉南/80269932","零售应用研发中心/网络应用开发团队/互联网运营开发一室(杭州)","CN112069302A 会话意图识别模型的训练方法、会话意图识别方法及装置 ","对比文件按照时间顺序分配样本权重，使用标记了权重的样本进行模型训练，而本申请提供了一种自动化的会话意图识别建模方案，支持用户实现建模的自动化、配置化、可视化，其区别在于：通过模型+策略实现自动化的会话意图识别。\n基于上述区别点，本申请具备新颖性和一定的创造性。","建议补充模型+策略的具体结合方式以及其对应的具体应用场景","补充内容后建议申请发明专利","发明","潘远帆"]
[13,"发明","基于HarmonyOS构建的消息列表框架","1.消息框架分级设计：\n对于仅单区域块的消息：消息列表-消息体-消息内容。\n对于多区域块的消息：消息列表-消息体-消息块-块内容。\n消息列表指整个消息列表，负责消息滑动，下拉刷新等业务逻辑。\n消息体指仅承载多框架样式的消息主体，不冗余消息内容。\n消息块指消息多区域展示时每块区域的样式框架，不冗余消息内容。\n消息内容和块内容指具体消息的具体内容\n2.消息刷新降级设计：\n消息列表整体刷新-消息体单独刷新-消息内容局部刷新。\n3.消息缓存多级设计：\n列表-消息两级缓存，避免在消息多次解析耗时。部分图片内容设有独立全局缓存。","问题：\n1.增加新消息导致新增很多框架层面的业务代码，容易影响其他原有消息逻辑。不利于代码版本控制。\n2.消息内部一些图片内容会随着消息刷新闪动。\n3.消息列表滑动卡顿。\n\n效果：\n1.支持文本，图片，web等多种消息类型展示。\n2.支持单个消息多样式和分块展示，丰富展示效果。\n3.支持消息内容局部刷新，单个消息刷新，消息列表整体刷新，提升刷新效率和减少消息内容闪动。\n4.构建消息-列表两级缓存机制，提高滑动性能。","吴姚远/80280714","零售应用研发中心/网络应用开发团队/可视柜台二室(杭州)/基础业务二组","CN108279939A 一种Android插件框架支持新增广播接收者的方法、装置及设备 ","对比文件所提供的Android插件框架解决现有的插件框架在支持新增广播接收者的方案存在程序执行效率低、影响广播的正常使用及影响系统性能等问题，而本申请则应用于HarmonyOS系统，构建消息列表框架，其区别点在于：1.应用场景不同；2.本申请还解决了消息内部一些图片内容会随着消息刷新闪动以及消息列表滑动卡顿的技术问题。\n基于上述区别点，本申请具备新颖性和一定的创造性。","建议结合具体的应用场景，补充该消息列表框架对于不同的消息如何处理的具体实施方式","补充内容后建议申请发明专利","发明","潘远帆"]
[14,"发明","一种基于账户的网关建设方案","1. API生命周期管理维护API的创建、变更、下线等功能，用户账户管理将用户和账户信息关联，通过赋权操作将用户和API信息关联\n1. API账户维度监控，通过sparksql和sparkStreaming实时统计聚合API不同账户维度的TPS、调用量、峰值及调用趋势等信息\n2. API账户鉴权，可以根据账户状态、绑定关系进行鉴权","问题：网关监控无法监控不同调用方的调用情况，API变更、异常排查无法关联调用方，API维护、问题排查困难，API变更无法通知调用方\n效果：\n1. 可以根据账户信息监控调用方对于同一API或者不同API的调用情况\n2. API变更、异常排查可以方便的关联到调用方，提高响应速度和异常处理效率\n3. API账户维度监控，可以根据用户维度的调用信息对服务资源进行维护，避免资源浪费，提高资源使用效率","刘奇/80326865","零售应用研发中心/网络应用开发团队/网上银行二室(杭州)","CN114979103A 开放API集成整合及管理方法及计算机设备 ","对比文件以账户为单位对API的调用权限进行控制，构建API开放平台生态，而本申请文件则根据账户信息监控调用情况，并具备API账户鉴权功能。相比之下，区别点在于：API账户维度监控，通过sparksql和sparkStreaming实时统计聚合API不同账户维度的TPS、调用量、峰值及调用趋势等信息。\n基于上述区别点，本申请具备新颖性和一定的创造性。","建议补充在获取不同账户维度的TPS、调用量、峰值及调用趋势等信息后，基于上述信息进行分析的具体实施过程。","补充内容后建议申请发明专利","发明","潘远帆"]
[15,"发明","一种基于分批处理的准实时高性能查询方案","发明点\n1. 批处理查询请求，对于方法内的多次数据源查询全部采用批量一次完成\n2. 请求数据预处理，将原始数据根据聚合逻辑把多表查询、复杂计算、数据聚合等处理完成后，将中间数据结果存入中间表\n3. 请求后置处理，将查询结果拆分为用户数据和通用数据，通过md5摘要算法计算方法入参摘要，入参摘要作为通用数据的key将数据存入缓存，用户数据根据用户id存入缓存\n4. 查询首先根据用户id和入参摘要查询缓存，数据存在直接返回，数据不存在查询中间表，经过业务逻辑处理和数据聚合后返回查询结果\n5. 数据更新策略包含定时刷新和实时更新，数据每天凌晨刷新一遍，实时更新时数据更新后会直接把中间表及缓存中的关联数据删除","问题：查询服务数据庞大、关联表较多、处理逻辑复杂等问题造成服务查询性能比较低\n\n效果：提高服务查询性能","刘奇/80326865","零售应用研发中心/网络应用开发团队/网上银行二室(杭州)","CN108833109A 身份认证方法、装置以及电子设备 ","对比文件基于摘要计算参数提高身份认证的安全性，而本申请则通过md5摘要算法计算方法入参摘要，入参摘要作为通用数据的key将数据存入缓存，用户数据根据用户id存入缓存，从而实现高性能查询，相比之下，区别点在于：\n1.查询首先根据用户id和入参摘要查询缓存，数据存在直接返回，数据不存在查询中间表\n2.数据更新策略包含定时刷新和实时更新，数据每天凌晨刷新一遍，实时更新时数据更新后会直接把中间表及缓存中的关联数据删除。\n基于上述区别点，本申请具备新颖性和一定的创造性。","建议补充有关通过md5摘要算法计算方法入参摘要，入参摘要作为通用数据的key将数据存入缓存，用户数据根据用户id存入缓存的具体实施过程以及流程示意图","补充内容后建议申请发明专利","发明","潘远帆"]
[16,"发明","宝宝类产品快赎混合垫资方案","混合垫资是优先使用他行垫资，我行垫资兜底的一种全新垫资模式，\n并对原有的请款流程进行了改良优化，由快赎额度不足再发起请款调整为每隔一段时间按交易分批请款","问题和弊端：\n他行垫资：\n1.存在客诉风险，他行垫资余额不足\n2.存在合规风险，客户交易和他行垫资转账交易无法勾连\n3.需要额外垫付，每个工作日切后，剩余垫付的资金还需要回退\n4.只能配置一家垫资行\n我行垫资：\n1.需要招行垫资\n2.每日额度有限\n3.受资债管控，极端情况下可能会关停快赎业务\n\n效果：\n混合垫资模式下，当他行垫资余额不足时，才由我行垫资兜底，不仅极大减少了每日需要我行垫资的额度，而且大大降低了客诉风险\n由于是按交易批次请款，客户交易也可以和他行垫资转账交易一一对应，无合规问题，也不存在额外垫资的情况\n支持配置多家垫资行\n","王鹏/80274158","总行/信息技术部/零售应用研发中心/投资理财开发团队/投资业务五室","CN107742251A 一种汽车物流运输垫资发车担保交易运作系统及方法 ","对比文件提及一种汽车物流运输垫资发车担保交易运作系统及方法，包括二网车商、撮合平台优品车商城、上游资金提供方、卖方供车平台和第三方物流公司。而本申请仅涉及我行，他行以及客户公司，区别点在于：\n1.实施混合垫资\n2.对原有的请款流程进行了改良优化，由快赎额度不足再发起请款调整为每隔一段时间按交易分批请款。\n基于上述区别点，本申请具备新颖性和一定的创造性。","建议结合业务流程与实际的系统运行流程对该方案具体实施过程进行补充","补充内容后建议申请发明专利","发明","潘远帆"]
[17,"发明","基于HarmonyOS构建的富文本组件","基于n叉树的思想，将一段可能包含特定图片编码，url链接，手机号，邮箱的字符文本作为n叉树的根节点，递归解析，找到所有没有子节点的子节点，将其从左到右串联组合进行富文本展示：\n图片内容解析后作为n叉树树的第一层的子节点（从左到右按文本原顺序，子节点分别标识为图片和非图片节点），从左到右，再将每个非图片子节点作为根节点进行url链接解析，找到第二层分为url链接和非url链接所有子节点，再按顺序对非url链接进行手机号码解析，找到第三层所有手机号码节点和非手机号码节点。再将非手机号码节点进行邮箱解析找到第四层所有邮箱节点和普通文本节点。从左到右即按文本原顺序将所有没有子节点的子节点串联分类展示表情，url链接，手机号码，邮箱链接以及普通文本。","问题：\nHarmonyOS系统文本组件无法支持图片及多种链接解析并展示。\n效果：\n支持图片，url链接,手机号码链接，邮箱链接识别展示的富文本组件。","吴姚远/80280714","零售应用研发中心/网络应用开发团队/可视柜台二室(杭州)/基础业务二组","CN114003330A 富文本发布方法及装置 ","对比文件公开了一种富文本发布方法，保证了富文本信息可以在多种不同的终端上进行发布，而本申请文件不同于对比文件，本申请应用于HarmonyOS系统，构建富文本组件以进行展示。相比之下，区别点在于：\n1.应用于HarmonyOS系统\n2.结合n叉树的思想\n3.富文本展示的优先级为从左到右即按文本原顺序将所有没有子节点的子节点串联分类展示表情，url链接，手机号码，邮箱链接以及普通文本。\n基于上述区别点，本申请具备新颖性和一定的创造性。","建议补充富文本发布的流程示意图","补充内容后建议申请发明专利","发明","潘远帆"]
[18,"发明","一种酒店行业不同尺寸的酒店外观图自适应裁切展示的解决方案","1)提出了一种基于纯前端实现的快捷、高效、低成本的不同尺寸酒店外观图排版解决方案\n2)原始图片本身不需要事先编辑，兼容性好\n3)加载展示时根据当前页面所需展示尺寸，自动对图片进行裁切\n4)保持图片质量，可以保证图片在适应容器大小的同时，尽可能地保持其原有的宽高比和视觉质量","问题：现阶段，酒店行业存在不同的酒店供应商，比如艺龙、锦江、如家、亚朵、美团等，每个供应商提供的酒店图片尺寸各异，如何才能在一个页面上统一展示，常见的做法是设置固定长宽比，带来的问题是图片展示上会有拉伸或压缩现象，视觉效果不佳，影响转换率。\n\n效果：\n1、不同尺寸的原始图片在同一个页面固定展示，用户看到的是整齐划一的尺寸一致图片\n2、响应式设计：很好地适应不同屏幕尺寸和分辨率，使图片在各种设备上都能保持良好的显示效果。\n3、保持图片质量：可以保证图片在适应容器大小的同时，尽可能地保持其原有的宽高比和视觉质量。\n4、易于实现：纯前端效果，就可以实现图片的响应式展示，不需要复杂的计算和编程。\n5、兼容性好：支持大多数现代浏览器，包括Chrome、Firefox、Safari等，兼容性好。\n6、灵活性强：调整方便，方案可移植，应用范围广泛。\n7、提升用户体验：通过保持图片的宽高比和视觉质量，可以提升用户的浏览体验，使页面更加美观和专业。","毛航航/80274878","零售应用研发中心/零售客户经营开发团队/商旅业务开发室(杭州)/移动应用组","CN117294804A 广告素材自适应生成方法、装置、设备及存储介质 ","对比文件提供广告素材自适应生成方法，用户仅需编排设计好的一个尺寸的广告素材，即可根据广告屏不同尺寸，自适应编排前景设计元素位置，生成新广告素材；而本申请提出了一种基于纯前端实现的快捷、高效、低成本的不同尺寸酒店外观图排版解决方案，相比之下，区别点在于：\n1.易于实现：纯前端效果，就可以实现图片的响应式展示，不需要复杂的计算和编程。\n2.兼容性好：支持大多数现代浏览器，包括Chrome、Firefox、Safari等，兼容性好。\n基于上述区别点，本申请具备新颖性和一定的创造性。","建议结合酒店外观图的自身固有特性补充相关的自适应裁切展示的具体流程","补充内容后建议申请发明专利","发明","潘远帆"]
[19,"发明","ES数据稳定加载切换方案","1 提出了一种基于MYSQL+JAVA应用的ES数据加载方案\n2 加载速率可控制\n3 ES数据版本切换稳定","问题: 一般会将海量数据, 从文件加载到ES中,提供搜索服务. 但是如果数据量很大, 且数据源每日有更新, 此时如何保证数据的稳定加载以及稳定使用.\n\n效果: 每日加载大量数据到ES, 加载成功后切换到最新索引","杨栋/80291354","零售应用研发中心/零售客户经营开发团队/电话银行二室(杭州)/经营数据开发组","CN114925138A 基于Hadoop的ES数据同步方法、装置、设备及介质 ","对比文件在预设的Hadoop系统上部署预构建的虚拟ES实例，以生成待同步数据的索引文件，并发送到预设的ES集群进行待同步数据的加载；而本申请提出了一种基于MYSQL+JAVA应用的ES数据加载方案，具备加载速率可控制和ES数据版本切换稳定的优点。相比之下，其区别在于：\n每日加载大量数据到ES, 加载成功后切换到最新索引，以保证数据的稳定加载以及稳定使用。\n基于上述区别点，本申请具备新颖性和一定的创造性。","建议补充MYSQL+JAVA的框架以及ES数据稳定加载切换的具体流程步骤","补充内容后建议申请发明专利","发明","潘远帆"]
[20,"发明","一种低耦合的工作流管理平台解决方案","方案：\r\n各业务模块间，业务模块与平台侧在前后端、数据层解耦，避免了相互间的影响和问题传导。\r\n平台与各模块间在部署、灰度发布层解耦，使平台可以保持持续稳定提供服务的同时，新场景接入、已有场景变更可以在精准范围内切指定用户快速灰度验证。\r\n工作流流转分发可精细化管理，个性化内容呈现可灵活扩展。","问题：\n很多系统都有大量工作流类任务需要处理，如果每个工作流单独开发，资源消耗较大。一般系统都会将系统内的工作流进行统一管理，怎么使统一管理的成本较低，工作流间互不影响，工作流差异化内容又可保留呢？\n效果：\n1、系统内工作流统一集约化管理；\n2、工作流间，工作流与平台间高内聚、低耦合，应用和数据间物理解耦，均可独立发布，问题物理级隔离；\n3、工作流个性化内容可在平台内灵活私有定制和处理。","马岭/80318248","零售应用研发中心/零售客户经营开发团队/零售客群集中经营室(成都)/应用开发三组","CN111160704B 一种基于RESTful架构的工作流引擎系统 ","对比文件公开了一种基于RESTful架构的工作流引擎系统，包括流程模板管理模块、流程实例管理模块、进度查询与统计模块、流程与任务跟踪模块，有效的降低系统之间的耦合度，提高代码复用度，降低数字化电站建设的软件开发成本；而本申请实现系统内工作流统一集约化管理，相比之下，区别点在于：\n平台与各模块间在部署、灰度发布层解耦，使平台可以保持持续稳定提供服务的同时，新场景接入、已有场景变更可以在精准范围内切指定用户快速灰度验证。\n基于上述区别点，本申请具备新颖性和一定的创造性。","建议补充工作流间，工作流与平台间高内聚、低耦合的逻辑示意图","补充内容后建议申请发明专利","发明","潘远帆"]
[21,"发明","基于链路追踪技术的微服务日志输出优化方案","1)基于进程内缓存框架EhCache实现低价值日志过滤\n2)对异常日志自动获取上下游链路信息\n3)基于慢接口调用统计构建微服务慢日志输出能力","问题：\n1)普通流程日志被检索的可能性极低，但是占用了大量网络带宽和存储空间，造成资源浪费\n2)异常日志被淹没在正常流程日志中，不易被快速定位与发现\n效果：\n1)对正常业务流程日志过滤，可节省大量带宽与存储资源\n2)异常或重要日志全量输出，可使开发聚焦于线上问题或重要业务\n3)为微服务实现了类似数据库的慢查询日志的功能，使得用户可以更准确更快速的发现问题并解决问题","陈家祥/80280256","总行/信息技术部/零售应用研发中心/零售客户经营开发团队/零售客群集中经营室(成都)/基础数据开发组","CN113918426A 一种实现Redis访问全链路跟踪的方法、系统及设备 ","对比文件通过Redis节点创建可执行接口，实现了自行选择链路跟踪对象，以及实现了快速跟踪以及及时捕获异常日志的技术效果。而本申请过滤正常业务流程日志，为微服务实现了类似数据库的慢查询日志的功能，相比之下，区别点在于：\n1.基于进程内缓存框架EhCache实现低价值日志过滤。\n2.基于慢接口调用统计构建微服务慢日志输出能力。\n基于上述区别点，本申请具备新颖性和一定的创造性。","建议补充低价值日志过滤以及构建微服务慢日志输出能力的具体实施步骤嫩内容","补充内容后建议申请发明专利","发明","潘远帆"]
[22,"发明","海量数据下Redis存储资源高效利用解决方案","\n1) 基于桶规整Hash算法的Redis Key存储优化\n2) 基于统计规律的桶空间规划\n3) 基于抽样算法的自定义过期策略\n4) 多功能监控管理中心","问题：\n海量数据存储于Redis时，带来以下问题\n1) 内存膨胀率高\n2) 内存碎片多\n3) 单机内存有上限\n4) 数据持久化时间长\n效果：\n形成了一套超大规模的存储方案，在保证业务可接受延迟的前提下，大量缩短内存消耗，最多可支持百亿级的数据缓存，至多可节省原有80%的内存占用","贾建/80258059","总行/信息技术部/零售应用研发中心/零售客户经营开发团队/零售客群集中经营室(成都)/应用开发一组","CN110895524A redis满载时键的复合过期方法、装置、服务器及存储介质 ","对比文件提出一种redis满载时键的复合过期方法，全面、复合的采用两种算法结合的策略删除redis的key，保证redis稳健运行，而本申请基于桶规整Hash算法的Redis Key存储优化以及基于统计规律的桶空间规划，在保证业务可接受延迟的前提下，大量缩短内存消耗，节省内存占用；相比之下，区别点在于：\n1.基于抽样算法的自定义过期策略。\n2.多功能监控管理中心。\n基于上述区别点，本申请具备新颖性和一定的创造性。","建议补充自定义过期策略的具体内容，以及多功能监控管理中心的功能模块示意图或相关文字描述","补充内容后建议申请发明专利","发明","潘远帆"]
[23,"发明","企业微信用户无感认证解决方案","1.识别客户打开活动或素材的场景，分别在招商银行APP、浏览器、微信场景、微信小程序场景收集客户授权信息，联合企微客户unionId信息进行客户实名认证\n2.提出一种基于canal+kafka的实名认证同步方案，解耦认证成功后备注修改及打认证标签等动作，并控制消费速率，防止过度调用腾讯接口导致调用超限，同时增加接口重试机制，同时保证消费的幂等性及漏损补数\n3.识别客户号合并客户，更新客户实名认证中的客户号信息\n4.结合一网通登录的微信授权数据，通过unionId连接行内账户和微信账号，完成实名认证","问题：企业微信实名认证数据是客户运营的基础，只有正确识别客户身份才能进行准确运营。如果能在营销过程中提高客户自动认证率，将大大减少客户经理手工认证的工作量，同时可以做到更准确的运营行为；同时在认证成功后准实时通知客户经理，也能带来更多运营收益。\n\n效果：\n客户通过参加各种营销活动、首面经营、扫描活码等，实现自动认证；客户经理准实时地在企微聊天工具中看到客户的身份，得到更确切的客户信息，给予更准确的客户运营。\n","陈河军/80374578","总行/信息技术部/零售应用研发中心/网络应用开发团队/互联网运营开发二室(杭州)/企业微信一组","对比文件1（CN105764051A）提供了认证方法、认证装置、移动设备和服务器，其中，一种认证方法应用于移动设备的终端认证装置上，该方法包括：响应于当前用户触发的认证请求，获取所述移动设备的认证参数，所述认证参数用于唯一标识认证参数在哪一个移动设备上触发；将所述认证参数发送至服务器，以便服务器根据所述认证参数生成加密的认证码；响应于服务器返回的所述加密的认证码，对所述当前用户的身份进行认证。采用本申请实施例，可以增加互联网数据处理的安全性，进而也能更好的提升用户认证体验。进一步的，还能保证用户的经济利益不受损失。","与对比文件相比，本案的区别在于：1，通过多种途径的客户授权信息收集场景，收集到的客户授权信息为客户号或手机号等，根据收集到的客户授权信息进行客户实名认证的过程；2、认证成功后的备注修改及打认证标签的过程；3、合并客户与更新客户实名认证中的客户号信息，内账户和微信账号进行死码认证的过程","请步骤：1.识别客户打开活动或素材的场景，分别在招商银行APP、浏览器、微信场景、微信小程序场景收集客户授权信息，联合企微客户unionId信息进行客户实名认证\n2.解耦认证成功后备注修改及打认证标签等动作，并控制消费速率，防止过度调用腾讯接口导致调用超限，同时增加接口重试机制，同时保证消费的幂等性及漏损补数\n3.识别客户号合并客户，更新客户实名认证中的客户号信息\n4.结合一网通登录的微信授权数据，通过unionId连接行内账户和微信账号，完成实名认证；      上述各个步骤的详细实现过程。       ","补充资料后建议申请发明","发明","苗广冬"]
[24,"发明","一种低内存多场景可自适应调整流量的实时流数关联解决方案","1.各模块参数个性化配置 \n2.数据双查机制降低state内存占用，降低时延\n3.多场景多参数自调整回推模式\n4.可配置式异常数据监控","问题：\n目前多流关联依赖Flink的State状态存储，可存储大小和时间均受资源限制严重；同时随着业务量增长，checkpoint异常风险提高，数据一致性得不到保障，造成数据延迟严重甚至出现数据错误的情况。\n效果：\n通过应用自适应调整回推时间的回推的方式进行数据流关联，同时所有参数均根据不同业务需求进行个性化配置，可以降低流关联当中对内存资源的消耗和依赖，流数据之间的关联时长可随数据的业务特点按需拉长","谢秀坤/80251924","/零售应用研发中心/零售客户经营开发团队/零售信息应用开发二室(杭州)/实时数据开发组","对比文件1cn114238415a，公开了一种基于Flink的实时规则引擎控制方法、系统及介质，包括实时接收事件源并为所述事件源配置实时规则；采用Flink流式实时计算引擎将所述事件源进行内部存储，且事件流与规则流数据均以key?value形式存储；采用Flink流式实时计算引擎连接事件流和规则流，对每一条事件流：根据接收的规则流及规则流中需要分组的字段，利用Java反射机制得出具体的value值，形成新的事件发送到下游的算子处理；下游收到新事件，根据这个value值进行动态keyBy分组，分组成功后，再次调用算子连接规则流，对具体的规则进行规则计算并存储；根据分组后的各组规则，若事件流触发了某一个规则，则进行告警输出。","与对比文件相比，本案的区别在于：将辅助流存储与外部数据库，采用双查询机制进行事件流的查询，自适应调整回推时间的回推机制",null,"建议申请发明","发明","苗广冬"]
[25,"发明","加密机集群故障检测隔离方案","1、定时检测加密机集群IP\n2、定时检测单台加密机IP\n3、根据1和2的检测结果，按照特定的算法和规则进行隔离\n4、远程实现加密机一键检测、一键隔离、一键恢复","问题：\n1、由于网络抖动、延迟、丢包，网络设备异常等原因，导致应用连接加密机容易出现超时，影响业务连续性\n2、加密机本身出现故障时，也会导致应用无法使用加密机，影响业务可用性\n\n效果：\n1、网络波动时，自动隔离有网络问题地区的加密机\n2、加密机故障时，自动隔离故障加密机\n3、采用两地部署，当某一地区过多加密机被隔离时，借用异地加密机使用\n4、加密机故障或网络故障时，应用受影响时间大幅度降低，最慢5分钟恢复","罗昌凯/80310851","总行/信息技术部/零售应用研发中心/网络安全开发团队/安全基础室/密码应用开发组","对比文件CN109729064A公开了一种加密机故障处理方法及信息处理系统，其中，方法包括：多台代理机中的一台代理机探测对应加密机的故障状态，当一台代理机确定对应加密机处于故障状态时，禁用与业务系统之间的接口，当业务系统监听到一台代理机禁用接口时，将对应一台代理机的安全调用，发送至多台代理机中未禁用接口的另一代理机。通过代理机对对应加密机进行故障探测，对处于故障状态的加密机对应的代理机进行接口禁用，实现通过代理机接口禁用，实现对故障加密机的隔离，解决了现有技术中，当有加密机出现故障时，无法对故障加密机进行隔离，使得安全调用失败，造成业务系统对加密机调用的成功率较低的技术问题。","与对比文件相比，本案的区别在于：通过新增的监测系统对f5以及加密机进行监测以及故障隔离，所有f5故障时采用异地加密机进行及时处理","建议补充：1，对f5以及加密机进行监测以及故障隔离的详细过程。2，在f5全部故障时，调用异地加密机的过程，以及在存在多个异地f5时如何进行选择，例如，深圳全部故障，如何在上海/广州等多个异地中进行选择，选择上海时，如何在上海的多个f5中进行选择？","补充资料后建议申请发明","发明","苗广冬"]
[26,"发明","一种基于Timeline写扩散模型的高性能消息处理实现方案","1、基于TimeLine构建消息写扩散模型。\n2、采用hash/一致性hash算法将用户消息负载均衡的映射到绑定的线程，基于无锁算法并发处理消息。\n3、自定义通用的消息格式和底层协议设计消息通道。\n4、消息序列自增和消息推送绑定为原子操作，保证分布式多实例推送消息的有序性\n5、自定义设计高性能分布式延迟队列，支持延迟消息有序和唯一性处理。","问题：                                              在前后端分离的开发模式中，消息交互异常频繁，且消息类型、业务模式千差万别。需要构建一种兼容多协议、多语义，绝对有序且支持实时发送和自动离线存储的高性能消息处理方案，可让客户端零成本的快速接入、按需精准拉取，满足各类业务的有效请求，节省网络带宽，提升消息交互效率和I/O性能。                                                                                                                                                                                                                                                                                                                                                                                                                                         效果：                                              1、提出一种基于TimeLine构建实现消息写扩散模型的方案，支持多客户端零成本扩展和高性能消息处理。\n2、支持动态调节消息队列的最大长度，控制批量拉取的大小，批量操作可以大幅度提高消费速度，减少网络io。\n3、协议上支持实时的websocket长/http短轮询/SSE模式，也支持基于event事件的延迟消息调用模式；业务模式上支持实时/延迟/定时消息处理，新增/撤销/修改，文本/图片/文件，单发/群发/广播，在线/离线等；\n4、消息序列自增和消息推送绑定为原子操作，单用户维度的全局有序性，不依赖于机器时间戳，支持分布式拓展。\n5、支持实时/延迟消息双模式处理，支持消息离线重发，消息续传和精准消费。","伍斌/80234858","总行/信息技术部/零售应用研发中心/零售客户经营开发团队/电话银行应用室/应用开发一组","对比文件（CN115633102A）公开了一种多类型协议消息处理系统、方法及可读存储介质，系统包括：协议消息处理单元，用于接收多个通讯协议设备发送的多个协议消息，根据多个协议消息和预设的通用协议格式进行格式转换，得到多个不同的目标消息数据；协议消息存储单元，用于根据多个目标消息数据和预设的通用存储格式进行格式转换，得到多个不同的目标存储数据并存储；消息队列；逆转换处理单元，用于根据消息提取指令从消息队列中调取多个目标存储数据并进行逆格式转换，得到多个协议消息并发送至客户端。本发明实施例的多类型协议消息处理系统，能够灵活应对不同协议类型的通讯协议设备，提升设备接入效率，降低开发成本，提高系统软件的灵活度。","与对比文件相比，本案的区别在于：消息队列的动态调节，并发消费消息的过程，以及延迟队列消息的处理","建议补充：1，消息发送的详细流程","补充资料后建议申请发明","发明","苗广冬"]
[27,"发明","一种基于数据库管理的ES索引切换和降级实现方案","1、基于Mysql数据库管理ES索引信息\n2、ES索引版本化管理\n3、支持页面化管理查看当前生效和其他就绪ES索引\n4、支持页面化降级切换生效ES索引\n5、数据同步完成后自动切换更新ES索引","问题：\n1、依赖于接口同步更新大量数据到ES，频率较高，同步时会影响到客户搜索效率和搜索结果的准确性\n2、缺少针对异常数据、场景进行降级的策略，无法保证搜索服务的高可用\n效果：\n1、可自由配置数据同步的频率，同步完成后才会修改状态，切换搜索服务内的生效的ES索引，不影响客户搜索\n2、支持页面化管理当前生效的ES索引，出现异常数据时，可以切换旧版本索引，保证搜索服务的正常可用\n3、提高了我们酒店智能搜索服务的整体可用性、准确性","侯昊彤/80328721","总行/信息技术部/零售应用研发中心/零售客户经营开发团队/商旅业务开发室(杭州)/运营业务组","对比文件（CN109800222A）公开了一种HBase二级索引自适应优化方法和系统。该方法的步骤包括：1)将客户端对HBase的变更操作通过观察者协处理器组件同步映射到分布式搜索引擎ES的索引中，并由ES维护HBase中数据对应的倒排索引，作为HBase的二级索引；2)对所述二级索引进行增量更新，包括增量更新本地索引、增量更新全局索引、增量更新ES索引；3)将跨表、跨库更新HBase索引表和ES索引表的索引更新请求同步到所述二级索引；4)接收客户端发出的数据查询请求，通过本地索引、全局索引和ES索引获得查询结果，并返回给客户端。本发明支持单列索引、联合索引、全文索引等多种索引模式，能够极大地提高检索效率。","与对比文件相比，本案的区别在于：通过定时任务触发es索引的版本更新，es索引的页面化管理，在es索引异常时，可回退至之前版本的es索引","建议补充：1，es索引进行版本更新的详细过程，以及es索引版本回退的流程。","补充资料后建议申请发明","发明","苗广冬"]
[28,"发明","基于静态分析的java应用方法间调用链监控及调用树生成方法","1、基于静态代码分析构建方法间调用关系\n2、基于调用关系绘制时序图","问题：\n1、应用内方法较多，一个方法的改动无法快速定位影响点\n2、问题发生时，无法快速定位调用链\n效果：\n1、可直观展示方法间调用关系，快速定位问题发生点","杨雁峰/80374585","总行/信息技术部/零售应用研发中心/零售客户经营开发团队/商旅业务开发室(杭州)/基础服务组","对比文件（CN115858329A）提供一种交互组件测试方法、装置、电子设备及存储介质，通过获取变更函数，所述变更函数表征应用内发生代码变更的函数；根据函数调用链，确定所述变更函数对应的目标函数，其中，所述函数调用链用于表征所述应用内各函数之间的调用关系，所述目标函数为函数内部调用了所述变更函数的函数，所述目标函数为所述应用响应活动界面内目标交互组件的触发动作而调用的函数；根据所述目标函数与所述目标交互组件之间的映射关系，确定所述目标交互组件；生成所述目标交互组件对应的目标测试用例，并基于所述目标测试用例对所述目标交互组件进行测试，生成测试结果，实现对变更函数的精准测试，提高测试效率和测试效果。","与对比文件相比，本案的区别在于：本方案通过分析应用方法之间的调用关系形成调用链，并绘制调用关系的时序图；","建议补充：1，分析应用方法之间的调用关系形成调用链的详细过程；                       2，绘制调用关系的时序图，根据时序图快速定位问题发生点的详细流程。","补充资料后建议申请发明","发明","苗广冬"]
[29,"发明","数据智能诊断文档自动化生成方案","1、基于规则引擎实现的数据诊断结论自动生成\n2、提供可视化工具供用户在线自定义编辑文档内容\n3、支持导出可编辑的Office文件（PPT和WORD）\n4、采用批量合成的方式提供毫秒级访问体验","问题：\n1、常规报告仅呈现数据并没有对数据进行分析及给出结论，同时总分行一些线下会议材料需要耗费大量人力进行数据整理后形成汇报材料\n效果：\n 1、支持用户按规则预置分析逻辑，待数据就绪后直接输出结论；\n 2、实现数据报告的导出，生成PPT或者WORD类型材料供会议场景直接使用；\n 3、在线打开时实现毫秒级响应；","江凯/80258149","零售应用研发中心/零售客户经营开发团队/零售信息应用开发六室(杭州)","对比文件（CN111667894A）公开了一种基于RETE算法规则引擎与疾病知识库的医院电子病历质量监控和管理系统，包括医学本体的构件、自然语言处理技术、机器学习构件知识图谱、RETE算法规则引擎、全院概览、质控规则、质控分析报告、病案数据统计和环节质控。该发明通过构建疾病知识图谱，理解病历内涵，并进行缺陷筛查，判断疾病诊疗的合理性，提高病历质控工作效率，解决现行质控业务中的病历和缺陷覆盖不足的痛点，系统建立统一的质控标准，实现自动质控，减少了人工质控的工作量及质控人员的主观因素，系统可根据医院需求，灵活地与院内现有信息系统进行对接或者整合。","与对比文件相比，本案的区别在于：规则引擎的配置过程，批量合成的方式，视化工具","请补充，1，规则引擎的配置以及根据配置的规则输出结论的详细流程；2，批量合成实现的具体流程；3可视化工具在线自定义编辑文档内容的流程；","补充资料后建议申请发明","发明","苗广冬"]
[30,"发明","移动设备上声纹密码识别多算法集成方案","1. 自研环境噪声监测，语音检测，降噪和回声消除，提升声纹样本采集质量\n2. 利用规则引擎融合各算法规则，智能控制数字位置和权重\n3. 语音差异化分析，整合生成全方位覆盖的融合特征\n4. 基于声纹特征向量相似度运算，提供声纹识别决策\n5. 多识别算法集成，确保系统高可用","问题：\n客户身份鉴别是银行业务办理中的重要步骤，风险敏感性高，业务场景复杂多样，\n安全性极为重要。为丰富客户核身手段，提升系统安全等级，提出声纹识别方案，满足多样化的业务核身需求。\n效果：\n声纹识别服务涉及了应用层面、数据层面、不同网络之间数据的安全传输，客户数据加密与验签算法，增加了系统自适应性，支持链路还原与不同版本和算法之间的流量分发。\n同时声纹可以做到无感知零接触，客户戴口罩或特殊客户群体可选择声纹识别作为校验方式，隐私性也相对较好，用户接受程度高。","王书剑/80258304","零售应用研发中心/网络应用开发团队/移动银行三室(杭州)/生物识别应用组","对比文件（CN111161746A）公开了一种声纹注册方法。该方法包括：通过语音交互将声纹注册流程播放给用户进行声纹注册引导，在声纹注册引导的同时采集环境音频，当采集的环境音频的时长满足预设阈值时，提示用户说出注册文本；对采集的环境音频进行回声消除，识别用户输入的注册文本语音；将信噪比、语速和截幅确定为评分因子，通过评分因子确定注册文本语音的综合评分；当综合评分达到预设评分阈值时，将声纹注册引导时采集的环境音频存储至环境音频数据库，对注册文本语音声纹注册。本发明实施例还提供一种声纹注册系统。本发明实施例提高声纹注册时的音频识别性，和信噪比计算的精确度，把环境音的采集隐藏在不断地语音引导之中，防止用户对环境音频的干扰。","与对比文件相比，本案的区别在于：4次音频采集过程，字符串生成过程，特征对比过程",null,"补充资料后建议申请发明","发明","苗广冬"]
[31,"发明","Android应用图片资源监控方案","监测应用运行时图片资源的占用情况以及检测这些图片的合理性的效果，需要实现获取到两方面的数据，内存中所有图片对象的数据，和用于显示这些图片的控件信息。\n1.获取APP中创建的图片对象从而获得应用运行时加载的所有图片信息\n2.获取图片显示控件的信息","问题：\nAndroid应用中普遍都会用到大量的图片资源，显示的图片会占用大量运行内存，缓存的图片文件也会占用手机存储空间，因此优化图片资源对提升应用性能和用户体验具有重要意义。但实际开发者难以掌握图片资源的内存消耗，无法找出消耗较大的图片，或可能存在内存泄漏的图片，以及尺寸不合适的图片等\n效果：\n1、通过hook native层创建Bitmap对象的代码，获取应用运行期间的图片信息，避免了通常以修改字节码方式在加载图片的地方注入代码可能遇到的复杂性与兼容性问题，完全适用于使用Glide、Picasso等第三方图片加载框架的情况，能够获得的图片信息全面，效果稳定。\n2、提供了特定地对图片资源进行监控的能力，让开发者能够对应用中图片内存占用的峰谷状态做到心中有数，为排查因图片造成的内存泄露，内存溢出等问题起到相当积极的作用\n","滕兵/80374842","零售应用研发中心/网络应用开发团队/\n可视柜台二室(杭州)/基础业务二组","对比文件（CN112199250A）公开了一种图片的监控方法、装置、电子设备及存储介质，其中，所述方法包括：在每个终端的预设位置处添加预设的监控工具，所述监控工具用于拦截图片创建操作；根据所述监控工具获取目标应用程序在所属的终端中创建的各图片的相关信息；根据所述相关信息从各所述图片中筛选出内存空间的占用量不符合预设的内存空间占用条件的目标图片，生成所述目标图片的监控提示信息。本公开在监控得到内存空间的占用量不合理的目标图片的过程中，避免了修改目标应用程序的代码，不破坏目标应用程序的原有逻辑完整性，既可以监控得到内存空间的占用量不合理的目标图片，又可以保证目标应用程序正常运行。","与对比文件相比，本案的区别在于：1，图片泄露问题的检测；2，获取图片显示控件的信息，判断图片是否过大；","与对比文件相比，本案的区别在于：图片泄露问题的检测的详细流程；2，判断图片是否过大的详细流程；","补充资料后建议申请发明","发明","苗广冬"]
[32,"发明","一种基于多集群的ES数据同步方案","1、将Elasticsearch客户端进行封装，形成一个新的客户端框架，并提供数据同步功能\n2、故障检测服务、消息中间件和策略算法实时检测ES的可用性\n3、数据同步错误补偿\n","问题：\n目前大部分系统应用通过异地多活、双写数据的方式保证ES的高可用，但发生异常情况时，ES双写失败，难以保障系统应用的可用性，对用户体验影响较大，事后手动恢复写入失败的数据也有一定的难度。\n效果：\n1）数据同步引入通用组件jar包即可快速实现，将ES的数据同步功能与业务功能解耦，对代码无侵入。\n2）通过探测线程+策略算法实时检测ES集群的可用性，可快速检测集群异常，极大的提高了数据同步的高可用性，避免了集群异常持续往异常集群写入数据，减少资源浪费。\n3）数据同步支撑大数据量的同步，同步出错也能快速回溯，进行数据补偿，使集群间数据同步稳定可靠。","章明芳/80311143","零售应用研发中心/网络应用开发团队/网上银行二室(杭州)","对比文件（CN112559628A）公开了一种多集群消息的同步方法、装置、介质及电子设备。该方法包括：若监听到对多个ES集群的数据更新事件，获取数据生产者的对象ID；根据所述对象ID，确定更新数据的发送的目标消息队列；对所述目标消息队列，控制多个ES集群的消费者组按照顺序消费的规则进行消费；其中，每个ES集群设置有一个消费者组。通过执行本方案，可以在多集群中进行消息更新的情况下，保持数据的一致性。","与对比文件相比，本案的区别在于：1、将Elasticsearch客户端进行封装，形成一个新的客户端框架，并提供数据同步功能\n2、故障检测服务、消息中间件和策略算法实时检测ES的可用性、数据同步错误补偿","请补充；数据同步的详细流程，异常检测流程，回溯同步错误补偿的流程","补充资料后建议申请发明","发明","苗广冬"]
[33,"发明","一种基于专家规则与自适应算法的电话客服人力资源实时调度方案","1. 专家规则定义与集成：设计并集成一套专家规则系统，用于识别和定义电话客服人力资源调度的关键参数和条件。\n2. 规则数据实时收集，转换与标签化；这些规则基于电话队列排队情况，接通率等实时统计数据、客服当前可接听的业务技能、个人特质以及客服的日常排班情况。\n3. 自适应算法的开发与应用：该算法能够根据实时规则数据执行策略判断，动态调整客服的技能条线分配，自动识别客服资源的最优配置，以实现高效的调度决策和快速响应服务需求的变化。\n4. 实时调度执行与反馈循环：不仅根据专家规则和自适应算法的输出执行客服人力资源的调度决策，而且还收集调度执行的结果和客服服务的实时反馈数据用于优化策略，形成闭环。","问题：\n效率低下：目前电话客服在高峰时段容易出现的资源分配不均和效率低下的问题，部分电话条线排队过长而部分队列空闲，部分客服过载而其他客服空闲的问题，目前通过手工调整人力资源，效率低下且容易出错。\n个性化服务不足：考虑客服个人特质对接听某些类型电话的适应性，提升服务的个性化和顾客满意度。\n效果:\n1.提升客服中心运营效率：通过实时自适应调整，确保客服人员的技能和资源得到最优分配，减少顾客等待时间，提高处理速度。\n2.增加顾客满意度：通过智能匹配最适合的客服人员处理特定问题，提高解决问题的效率和质量，从而提升顾客的整体满意度。\n3.优化人力资源配置：通过动态调整，实现人力资源的高效利用，减少因技能不匹配导致的时间浪费和顾客不满。\n增强服务个性化：根据客服人员的个人特质和技能，为顾客提供更加个性化和贴心的服务体验。","刘先/80234987","零售应用研发中心/零售客户经营开发团队/零售客群集中经营室(成都)","对比文件（CN111539601A）提供了一种话务资源的调度方法及装置。其中，该方法包括：获取目标客服业务在目标时间段的人工客服话务预测量和当前时间段人工客服的人力排班话务量；根据上述话务预测量和上述人力排班话务量，判断目标时间段的人工客服预测接通率是否达到人工客服目标接通率；若人工客服预测接通率未达到人工客服目标接通率，则根据人工客服预测接通率和人工客服目标接通率，按照设定的策略调度规则对目标客服业务的流转链路中各个业务环节所对应的接通率优化策略进行调度。","与对比文件相比，本案的区别在于：专家规则系统；规则数据实时收集；根据实时规则数据执行策略判断，动态调整客服的技能条线分配， 实时调度执行与反馈循环","请补充，1，专家规则系统相关的详细内容。\n2. 规则数据实时收集的详细过程。\n3. 根据实时规则数据执行策略判断，动态调整客服的技能条线分配，自动识别客服资源的最优配置，的详细过程。\n4. 实时调度执行与反馈循环的细节。","补充资料后建议申请发明","发明","苗广冬"]
[34,"发明","酒店推荐方法、系统、设备及介质","1、针对个性化的预订流程实现统一数据采集方案\n2、基于酒店预订用户行为操作图的入度特征构建方案\n3、基于滑窗法酒店预订用户行为的特征构建方案\n4、基于aix的模型训练及在线推荐服务生成方案\n5、一种多策略、可配置的AB测试方案及效果评估方案","问题：\n1、酒店预订业务会在不同应用、不同渠道、不同产品线进行个性化实现，这导致酒店预订的流程、功能存在不同特征，对于数据采集和推荐存在挑战。\n2、当前酒店预订的用户行为特征多为基于历史信息及统计方法构建，缺少用户对于在酒店流程上的深度及不同酒店之间关联特征输入。\n3、AB测试及效果评估往往难以针对不同的场景快速响应。\n效果：\n1、对酒店预订的功能特征、业务流程、行为类别等分析并构建推荐的特征统一采集的方案，以减少个性化的数据埋点开发及提高数据采集效果及稳定性。\n2、通过基于酒店预订的用户行为的深度、及酒店关联的操作图，构建用户预订行为入度特征。\n3、推荐应用通过在线服务输出，便于快速对接搜索推荐、相似推荐、首页推荐等\n4、构造效果策略配置、分组列表同步、及AB埋点及可视化处理，实现多策略、可配置的效果评估。","吴博/80329236","总行/信息技术部/零售应用研发中心/零售客户经营开发团队/商旅业务开发室(杭州)/运营业务组","对比文件1（CN104391847A）提供一种基于用户行为的酒店排序方法、云端服务器及系统，所述方法包括：获取收集的电商领域酒店预订产品的用户行为数据；对所述用户行为数据进行分布式数据处理，获取分布式处理后的酒店排序结果；将所述分布式处理后的酒店排序结果发送给电商领域酒店预订产品的搜索用户。本技术发明的计算周期可以为一天，完全自动化，不需要任何人工干预；其数据计算方式为分布式，较之之前的单点数据库，具有良好的水平扩展性。同时中间数据层和抽象模型的构造为后续的其他数据挖掘工作提供了方便的数据接口，取得了转化率的大幅提升。                          对比文件2（CN111429204A）公开了一种酒店推荐方法、系统、电子设备和存储介质。其中，酒店推荐方法包括：根据多个待推荐酒店的酒店标识训练转换模型，转换模型用于将酒店标识转换成词向量；利用转换模型将每个待推荐酒店的酒店标识转换成待推荐酒店向量；获取目标用户的历史行为序列，历史行为序列包括目标用户历史点击的若干酒店的酒店标识；利用转换模型将历史行为序列转换成用户行为向量，用户行为向量与待推荐酒店向量的长度相同；获取用户行为向量与每个待推荐酒店向量的目标相似度；根据目标相似度向目标用户推荐若干待推荐酒店。本发明可以在实现的千人千面的基础上，能够提高酒店的订单转化率并有效减少目标用户的在线浏览时间。","与对比文件相比，本案的区别在于：通过基于酒店预订的用户行为的深度、及酒店关联的操作图，构建用户预订行为入度特征，基于入度特征进行模型训练，","请补充，1，通过基于酒店预订的用户行为的深度、及酒店关联的操作图，构建用户预订行为入度特征的详细步骤；2，请补充模型训练的具体步骤，","补充资料后建议申请发明","发明","苗广冬"]
[35,"发明","业绩数据智能播报方案","1、支持用户个性化编排推送内容，支持与多种数据源结合；\n2、实现数据与喜报的智能结合，自动按数据生成个性化喜报；\n3、支持实时数据源（KFK）和批量数据源（CK、GAUSS）的可插拔接入；","问题：\n 总分行客户经理业绩数据通报涉及到数据统计和内容整理等步骤，而且实时性无法得到保证。\n效果：\n 1、单笔业绩通知秒级推送；\n 2、支持定时和循环推送榜单数据；\n 3、重点业绩的喜报秒级自动生成与推送；","江凯/80258149","零售应用研发中心/零售客户经营开发团队/零售信息应用开发六室(杭州)","对比文件（CN116402036A）开了喜报自动生成方法、系统、计算机设备及存储介质，涉及信息处理技术领域，其中，所述方法包括：接收用户的操作指令，开启并进入喜报自动生成界面；基于所述喜报自动生成界面，选择生成目标喜报的目标喜报数据；基于所述喜报自动生成界面，选择生成目标喜报的目标喜报模板；将所述目标喜报数据绘制进所述目标喜报模板内，自动化生成目标喜报并展示。通过本发明的方法可快速自动化的生成目标喜报并展示，节约了大量的人力资源与沟通成本，并可及时快速的达到银行机构的宣传目的和效果。","与对比文件相比，本案的区别在于：自动按数据生成个性化喜报；单笔业绩通知秒级推送；定时和循环推送榜单数据；","请补充，1，自动按数据生成个性化喜报的详细流程；2，单笔业绩通知秒级推送的详细流程；3，定时和循环推送榜单数据的详细流程；","补充资料后建议申请发明","发明","苗广冬"]
[36,"发明","稳健高效的OLTP联机数据加载工具","一款专门为OLTP场景设计的批量数据加载工具，它提供了直观的可视化界面来配置数据加载任务，并且能够即时生效快速响应业务需求。该工具能高效完成亿级大表数据加载任务，支持多种关系型数据库，并且对数据加载全流程进行监控管理。","问题：\n1、OLTP场景的联机数据通常需24小时对外提供访问，数据更新不能影响外部访问。\n2、业务系统对联机数据的时效性要求高。\n3、联机数据通常存储于异构数据库，需要满足不同品种的数据库批量数据更新需求。\n4、数据加载需求多，需要快速上线，及时响应业务需求。\n效果：\n1、提供直观的可视化界面快速配置数据加载任务，即时生效，快速响应业务需求。\n2、使用“AB库+AB表”核心加载方案，数据批量更新不影响外部访问。\n3、支持MySQL、TDSQL、TIDB多种关系型数据库的数据加载任务配置\n4、提供数据加载任务实时监控、异常告警推送、数据质量校验，实现数据加载的全流程监控管理。\n5、使用分布式高并发加载方案，分钟级完成千万级大表加载，保障数据时效性。","伍世海/80374070","零售应用研发中心/零售客户经营开发团队/零售信息应用开发四室/财富管理数据中台组","未检索到采用“AB库+AB表”的方案进行数据加载的对比文件，",null,"请补充，1、可视化界面快速配置数据加载任务的流程。\n2、使用“AB库+AB表”进行数据加载的流程。\n3、加载任务实时监控、异常告警推送、数据质量校验的相关流程。","补充资料后建议申请发明","发明","苗广冬"]
[37,"发明","一种基于链路日志的微服务环状调用、循环调用实时监控方法","主要发明点：\n1、实时监控：利用Flink流式处理技术，对链路日志做实时归集，并借助自研算子，完成对环状调用、循环调用的实时监控。\n2、精准监控：直接对每一个调用链做分析，避免调用关系分段入库再分析时产生的虚假调用问题。\n3、不依赖三方存储：借助链路日志加工、中间结果转换、差集找头、迭代找路径、分解为单链等步骤，在不依赖三方存储的前提下，完成监控。\n\n与现有技术的区别：\n1、现有技术一般先将调用关系写入图数据库后再做分析，无法做到实时监控；而本方法使用Flink流式处理技术，可以做到实时监控；\n2、现有技术一般将调用关系两两成对分段入库，会产生虚假调用的问题；而本方法直接对每一个调用链做分析，可以做到精准监控；\n3、现有技术一般要借助图数据库等三方存储；而本方案直接进行流式计算，无需三方存储；","解决的问题：\n1、链路日志实时归集\n2、链路日志加工\n3、中间结果转换\n4、差集找头\n5、迭代找路径\n6、分解为单链\n7、环状调用和循环调用识别\n\n预计达到的效果：\n实现一种基于链路日志的微服务环状调用、循环调用监控方法，达到实时监控、精准监控的效果","朱雷坚/80274917","零售应用研发中心/零售信贷开发团队/个人信贷二室(杭州)","对比文件（CN116800597A）公开了一种链路日志监控方法、监控平台及计算机可读存储介质，其中，所述方法包括：基于卡夫卡消费线程，定时轮询所述卡夫卡消费中间件接收到的业务信息；在所述业务信息为客户端日志时，通过中转服务器将所述客户端日志中的客户端链路日志发送至所述分析模块；在确定分析模块获取到所述客户端链路日志关联的服务器链路日志时，基于所述客户端链路日志和所述服务器链路日志，确定客户端与服务器之间的业务链路的监控结果。本发明旨在提高监控业务链路全面性，提高系统的可用性。","与对比文件相比，本案的区别在于：链路日志的加工，中间结果转换，差集找头、迭代找路径、分解为单链、环状调用和循环调用识别","请补充.                     1、链路日志实时归集\n2、链路日志加工\n3、中间结果转换\n4、差集找头\n5、迭代找路径\n6、分解为单链\n7、环状调用和循环调用识别        上述各步骤的详细流程，建议根据沟通时的附图进行描述。","补充资料后建议申请发明","发明","苗广冬"]
[38,"发明","金融交易云日终高保障低时延解决方案","主要发明点：\n1. 新增基于个贷大数据融合平台的数据处理链路—SPARK数据链路，去除仓内加工逻辑，避免大量数仓依赖导致的链路不可靠性及低时效性。\n2. 双链路并行，由业务系统自动识别较快链路作为数据源，提升执行效率的同时，双链路互为备份增加系统健壮性，双链路互相校验，增加数据准确性。\n3. 提供弱云环境下降级策略，为日终提供坚强服务保障。\n\n与现有技术的区别：\n1.现有技术由仓内完成数据加工，仓内数据加工执行效率无法满足业务要求\n2.现有技术仓内加工依赖多，链路可靠性差。\n3.现有技术保障性低，故障降级策略缺失","解决的问题：\n1.数据加工全链路加工耗时长，日终时效无法满足业务预期\n2.仓内加工依赖多，链路可靠性差\n3.保障性低，故障降级策略缺失\n预计达到的效果：\n1.新增基于个贷大数据融合平台的SPARK数据链路，提升全链路执行效率\n2.双链路并行，择优者取，提供保障链路","李晓洁/80258038","零售应用研发中心/零售信贷开发团队/个人信贷四室(成都)","未检索到在进行日终数据传输时采用双链路传输的对比文件。",null,"请补充. 1，双链路并行处理的详细流程；2，双链路互为备份增加系统健壮性，双链路互相校验的流程。","补充资料后建议申请发明","发明","苗广冬"]
[39,"发明","基于SparkSQL的流批一体并发ETL方案","主要发明点：\n1、批流一体化处理：在下载时对拆分文件进行分片处理，使分片尽早进入流加载转换阶段，从而实现下载、加载过程几乎同时进行，在充分利用资源的同时，缩短数据处理耗时。\n2、双流加载处理：应用Structed Streaming，应用双流加载模型,解耦奇偶分片处理流程，使每一批次分片在加载转换过程中不受上一批次阻塞影响，保证全流程核心满载工作，。\n3、两阶段小文件合并：分两阶段执行小文件合并,先异步后同步，减少小文件合并整体耗时，秒级完成所有小文件的合并。\n4、高容错的检核机制：在下载和加载阶段均提供了检核机制，减少重启作业的重试成本。\n5、分片下载与分区加载:将下载文件分片处理，加载阶段应用Spark内存模型实施分区算法，最大化提升资源利用率。\n\n与现有技术的区别：\n1、现有技术没有融合批处理下载与流式处理加载的并发一体化\n2、现有技术未对ETL处理后产生的小文件做合并处理\n3、现有技术没有根据Spark内存模型实现内存分区算法，最大化利用资源。\n4、现有技术在应用Structed Streaming流式处理时，没有实施双流加载处理。\n5、现有技术实施的下载和加载阶段的完整校验中，未考虑减少重试成本、对已下载资源进行检查点机制管理。","解决的问题：\n1.大文件入Hive采用单线程下载至HDFS，耗时长且不稳定。\n2.大文件下载报错后重试机制为简单删除本地文件后重试，重试成本高，下载耗时翻倍。\n3.大文件入Hive产生大量小文件，影响下游作业取数加工耗时，增加HDFS元数据管理成本。\n预计达到的效果：\n1.大文件入Hive处理效率提升，全流程并发处理且稳定。\n2.大文件下载过程中失败，将应用检核机制对已下载资源做保留，减少重试成本。\n3.大文件入Hive后，对产生的小文件进行合并，解决Hive小文件过多问题。","熊均文/80255073","零售应用研发中心/零售信贷开发团队/个人信贷四室(成都)","对比文件（CN108256115A）提供了一种面向SparkSql的HDFS小文件实时合并的实现方法，属于大数据处理技术领域。定期筛选HDFS中待合并的小文件，对得到的待合并小文件，生成合并小文件的Spark任务，并提交至Yarn上执行；对完成小文件合并的结果信息放置于待替换列表中；结合Zookeeper保持SparkSql在使用合并后文件替换被合并文件时维持正常运行；根据SparkSql实时检索数据库表的情况，在Zookeeper中注册和注销相应数据库表的读状态；在文件替换时，通过网络在SparkSql中进行文件元数据缓存增量更新。本发明可以在保持SparkSql正常运行的情况下，实现实时合并HDFS小文件，有效的提高SparkSql的检索效率，在大数据处理领域具有很强的实用性和应用范围，具有很广泛的应用前景。","与对比文件相比，本案的区别在于：1、批流一体化处理；\n2、双流加载处理：\n3、分片下载与分区加载。","请补充：按照沟通时的附图，对图中的各个步骤进行详细描述。","补充资料后建议申请发明","发明","苗广冬"]
[40,"发明","一种通用的web白屏优化解决方案","主要发明点:\n1、提出针对不同渲染模式下的web白屏优化方案，根据实践结果验证不同渲染模式的web都有较好的优化效果\n2、结合客户端的请求拦截功能进行静态文件缓存，html自动缓存刷新，使用户在访问阶段能极快的速度拿到静态资源文件","解决的问题：\n1、在复杂的网络环境中，多样的浏览器版本下，不同渲染模式下优化方案不一\n效果：\n1、通过客户端静态缓存方案，有效解决二次访问的资源加载速度问题，使页面更快加载完毕，有效减少白屏时间\n2、通过自动内联CSS工具进行在html中内联css，使客户端渲染模式下的html页面尽可能提前渲染出预备好的样式内容，有效减少白屏时间\n3、客户端渲染模式下在html中提供渲染前的预备内容，或进行预渲染，使html提早有内容可渲染，有效减少白屏时间\n4、客户端离线包功能，以直接打开本地文件的形式对html进行加载，使html的加载耗时直接为0","郑轩/80231441","零售应用研发中心/网络应用开发团队/互联网内容开发室(杭州)/内容业务一组","对比文件（CN114969592A）公开了：一种web前端首页的白屏优化系统、方法及设备，系统包括：可视单元、webpack功能单元、资源获取单元、白屏反馈单元、性能监控单元、优化策略单元；资源获取单元，用于在web前端页面的首页文件中插入对应的链接，以通过对应的链接获取到所述首页文件的VUE资源；白屏反馈单元用于确定白屏状态数据；可视单元用于构成可视化界面；webpack功能单元用于对待加载数据进行压缩打包，获得目标打包文件；性能监控模块用于获取web前端页面加载过程中组件间的依赖；优化策略模块用于确定所述系统的待优化组件，根据组件间的依赖关系与预设组件的依赖关系确定待调整组件，基于待优化组件与待调整组件生成待优化信息，对待优化组件与待调整组件进行调整。","与对比文件相比，本案的区别在于：heml页面的缓存，根据缓存进行展示；页面渲染；","请补充：1，页面缓存以及根据缓存的页面进行展示的流程；","补充资料后建议申请发明","发明","苗广冬"]
[41,"发明","一种基于Vue和HTML5实现的HTML页面编辑方案","主要发明点：\n1、通过加载外部系统HTML页面内容，基于HTML5 API实现了任意页内元素的拖拽、删除等操作。\n2、通过Drop事件监听器，完成表单画布的动态添加，将HTML页面转换为另类的表单画布，实现了平台组件在HTML页面的添加编辑。","问题：\n1、常见前端低代码平台的设计编辑仅能针对于平台内的内容实现编辑预览，缺少对于已有页面的编辑能力。\n效果\n2、通过加载任意的HTML，可对于已有的任意HTML做页面内容编辑、并可将平台组件适用与此页面，直接编辑出目标UI样式，解决已有大量HTML页面场景下的设计需求。  \n","帅志鹏/80331243","零售应用研发中心/零售客户经营开发团队/零售客群集中经营室(成都)","对比文件1（CN115904349A）公开了一种基于vue模板的布局构建方法及系统，涉及软件开发技术领域，方法包括如下步骤：建立组件库，新建画布，将需要使用的组件从组件库中拖拽到画布中；添加样式，配置各自组件的样式属性；添加事件，针对成型的交互组件，直接编辑逻辑函数来满足项目需求；布局预览，确认组件的逻辑事件可执行交互；解析下载，当保存或下载触发时，调用系统标签解析，完成template标签下的html代码生成、vuejs和css样式表的生成，导出成型的单个vue模板布局文件，并嵌入到项目工程中使用，系统包含工具栏、组件库、画布、属性配置、事件配置、逻辑编写六个模块构成；本发明具备易操作性、快速性、准确性，实现导出即可用，大大提高了vue前端项目的开发速度。              对比文件2（CN107957868A）提供了一种HTML用户界面可视化编辑方法及装置，该方法包括：为HTML用户界面生成显示层遮罩容器和交互层遮罩容器，其中，交互层遮罩容器中存在HTML用户界面上各元素对应的交互遮罩；在捕获到外部针对任一元素对应的交互遮罩的触发操作时，控制显示层遮罩容器中的该元素对应的显ji yu示遮罩的显示效果，以为编辑HTML用户界面提供视觉线索；在利用交互层遮罩容器捕获到外部针对该元素的编辑操作时，根据相应操作类型对该元素执行相应处理。经交互遮罩以收集操作信息，并提供给系统以用来编辑元素，这一可视化编辑方法无需改变元素运行时代码。因此，本发明能够不侵入运行时代码而实现HTML用户界面的可视化编辑。","对比文件1公开了基于vue模板进行页面布局，对比文件2公开了基于TML进行可视化编辑。","请补充：本案在页面元素编辑以及表单画布编辑中与对比文件之间的区别。","若补充后的资料与对比文件之间存在区别，则建议申请发明","发明","苗广冬"]
[42,"发明","一种基于规则与自适应算法的调度策略价值回检方案","策略调度是基于标签可配置化的流程处理系统，主要用于规则配置。\n\n主要发明点：\n1）现有策略配置后，增加结果回检流程，形成闭环\n2）通过配置化回检目标：用户可以根据实际需求,对回检目标进行配置,使规则的回检更加适应实际需求\n3）预期价值是否达标实时查看：用户可以查看回检目标的预期价值是否达标,及时发现规则的问题,进行优化。\n4）价值回检目标可配置：用户可以根据回检目标的配置,使规则的回检更加全面和细致\n5）价值指标自动收集：回检更加快捷和高效，用户可以设置价值指标的自动收集规则,使规则的回检更加快捷和高效\n6）策略变更点前后详情对比：用户可以查看策略变更点前后的详情对比,了解规则变更的影响,进行决策","问题：\n1）策略的修改前后变更不能明确查看，不能及时追踪变更信息\n2）策略配置后没有效果回检流程，不能为策略优化提供数据支持\n3）没有统一平台查看策略的调度效果\n\n效果：\n效果：\n1）量化指标可配置:系统可以配置量化指标,使得规则更加具体、可量化和可比较\n2）实时监控,辅助策略配置人员及时持续优化策略:系统可以实时监控规则的执行情况,并提供数据支持,辅助策略配置人员及时持续优化策略\n3）变更前后详情清晰显示,出现问题可快速定位:系统可以清晰显示规则变更前后的详情,帮助用户快速定位问题,及时解决问题","杨冬/80316631","零售应用研发中心/零售客户经营开发团队/零售客群集中经营室(成都)","未检索到策略回检相关的对比文件。",null,"请按照沟通时界面图详细描述相关的步骤。","补充资料后建议申请发明","发明","苗广冬"]
[43,"发明","一种基于数据库的MQ消息队列降级方案","1、提供开箱即用的工具和自动化配置\n2、发送消息自动落库，MQ挂掉也能自动落库\n3、消费方检测到存在异常消息，自动从数据库读取消息消费\n4、自动化实现MQ降级方案","问题：\n1、MQ出现问题，导致消息发送失败，阻断业务流程\n2、MQ集群出现脑裂消息丢失现象\n3、缺少MQ降级手段\n效果：\n1、提供了工具jar包，引入后简单配置后即可实现消息落库\n2、提供注解的方式快捷的启用MQ降级功能，不需要服务方单独实现降级逻辑","侯昊彤/80328721","总行/信息技术部/零售应用研发中心/零售客户经营开发团队/商旅业务开发室(杭州)/运营业务组","对比文件1（CN113961372A）提供了一种MQ多实例消息发送方法和装置，属于大数据，该方法包括：配置多个MQ队列管理器加入MQ队列管理器组；在应用系统发来消息时，通过MQ队列管理器组选取MQ队列管理器，确定可用MQ队列管理器列表并缓存；通过MQ队列接收应用系统发来的消息，利用MQ队列管理器组从缓存中选取MQ队列管理器，将消息通过选取的MQ队列管理器发送至对应的通道；监测消息发送结果，在消息发送异常时，根据异常处理机制更换新的MQ队列管理器重新发送消息。本发明从应用角度对多个MQ实例进行统一管理，给出了一个MQ多实例的高可用解决方案，应用实现了多MQ队列管理器的配置和消息发送。","与对比文件相比，本案的区别在于：发送消息自动落库，消息消费后在库中删除；检测到存在异常消息，自动从数据库读取消息消费；","请补充：1，发送消息自动落库的详细步骤；2，消息消费后在库中删除的详细步骤；3，检测到存在异常消息，自动从数据库读取消息消费的详细步骤；","补充资料后建议申请发明","发明","苗广冬"]
[44,"发明","一种基于多维特征向量聚合的表单填写流失风险识别方法","发明点：\n1、针对用户表单行为可以实时识别用户离开表单的风险。\n2、拥有处理多维特征向量的能力。  \n3、数据样本兼容数值型和符号型特征向量。","问题：表单完成的过程中往往需要填写大量个人资料及相关信息，可能导致客户在填写表单的中途放弃表单填写\n效果：先在前端页面进行埋点，采集用户表单行为，通过关联性分析筛选出影响用户离开表单的用户行为特征作为样本，将其中数值型特征向量离散化，结合构建出特征因子分布曲线，聚合符号型特征向量，得到不同特征因子的条件概率和结果的先验概率。从而可以计算识别出在当前特征向量矩阵情况下用户离开表单的风险。","吴晓亮/80374720","零售应用研发中心/网络应用开发团队/网上银行二室(杭州)","对比文件1（CN117034859A）公开了一种表单填写页面动态调整方法、装置、设备及存储介质，涉及信息处理技术领域。所述方法是先根据当前填表设备的屏幕特性信息，生成当前待填表单的初始填表页面，并输出展示该初始填表页面，然后当检测到用户在所述当前待填表单的某个输入控件元素上触发有输入事件时，获取在触发所述输入事件前的最近用户行为数据，再然后根据所述最近用户行为数据，采用机器学习算法预测得到用户的下一步输入快慢程度，最后当所述下一步输入快慢程度过慢时，调整当前填表页面，使调整后所得的新填表页面能够帮助用户更快输入内容，如此不但可以使调整前后的填表页面适配设备特性，还可提高用户填表效率和优化用户填表体验。","与对比文件相比，本案的区别在于：对用户行为数据进行关联性分析筛选与离开表单相关的行为特征，根据行为特征进行模型训练，以及根据训练后的模型以及当前采集的用户行为，预测用户离开表单的概率","请补充：1，关联性分析筛选与离开表单相关的行为特征的相关流程；2，根据行为特征进行模型训练的详细步骤；3，根据当前的行为特征进行模型预测的过程。","补充资料后建议申请发明","发明","苗广冬"]
[45]

{"sheet":"2.26-3.1","index":1,"n_rows":16,"n_cols":13,"rows_kept":16,"cut":false,"hidden":false,"merged":[[0,0,0,6],[0,7,0,12]]}
["发明人填写",{"$nulls":6},"代理人填写"]
["序号","中心/团队/室","专利名称（暂定名称）","主要发明点/方案简述及与现有技术的区别","解决的技术问题及预计达到效果","所属技术领域","发明人","检索的最接近对比文件","检索分析\n（与对比文件相比的区别点）","待发明人补充内容\n（挖掘现场代理人提出需要发明人补充的内容）","检索结果\n如：补充内容后建议申请XX专利\n建议拆分专利（说明拆分内容）\n不建议申请，说明原因","建议申请类型","检索人"]
[1,"零售客户经营开发团队/互联网客户经营开发室（杭州）","一种适用于freeswitch集群的自定义负载均衡方案","主要发明点：\n1. 自定义客户端负载均衡器。针对由freeswitch esl服务发起的呼叫，实现自定义的负载均衡器。\n2. 支持freeswitch节点的在线扩容和故障节点自动摘除。通过在线扩容和故障节点自动摘除，支持freeswitch集群的高并发，高可用。\n\n与现有技术的区别：\n1. 传统freeswitch集群负载均衡方案一般是使用Session Border Controller(SBC)或SIP代理进行前端负载均衡，适用于由sip客户端发起的呼叫。而本方案适用于由freeswitch esl服务发起呼叫的freeswitch集群负载均衡，可以不是sip客户端发起。\n2. 传统的freeswitch集群，一般采用热备份的方案，当主实例宕机的时候，切换到备用节点。本方案通过freeswitch节点注册和故障探测技术，自动维护freeswitch实例可用列表，实现freeswitch实例的在线扩容和故障节点自动摘除。","解决的技术问题：\n1. 实现自定义的客户端负载均衡器，适用于freeswitch esl服务集群到freeswitch集群的负载均衡。\n2. Freeswitch注册与发现。基于zookeeper和freeswitch的启动脚本，实现freeswitch的注册与发现。\n3. 灵活的负载均衡策略。客户端负载均衡器提供多种负载均衡策略，以满足不同场景下的负载均衡流量调度需求，同时也支持用户自定义负载均衡策略。\n4. 故障节点自动摘除。通过探活机制，可以智能过滤掉集群中暂时无法提供服务的节点，从而避免对业务产生影响。\n\n预计达到的效果：\n1. 通过freeswitch esl服务对freeswitch集群发起呼叫，能够实现集群的负载均衡。\n2. 当freeswitch集群并发较高时，可以实现不停服务的在线扩容。\n3. 当freeswitch节点故障时，负载均衡器能够自动将故障节点摘除，不影响在线业务。",null,"高学勇等","CN114338343B、CN115623005A","对比文件1中集群服务管理节点根据负载均衡策略,从集群服务系统中选择不同于第一代理服务器的至少一个第二代理服务器,可以理解为:集群服务管理节点根据能实现代理服务器之间的负载均衡的规则,从集群服务系统中选择不同于第一代理服务器的至少一个第二代理服务器。对比文件2中所述集群部署在公有云上,包括:主控节点、运算节点、负载均衡器,其中,所述负载均衡器用于实现运算节点和主控节点之间的流量的负载均衡转发。但是本方案中的负载均衡针对于Java服务，因此具体的策略与对比文件不同。","建议补充负载均衡的示例","建议申请","发明","彭江峰"]
[2,"零售应用研发中心/网络安全开发团队/安全产品室（成都）","一种基于内核代码检测的Chrome内核安全防护方案","主要发明点：\n1、内核函数增强：采用InLineHook的方式对资源加载函数进行增强，增加调试检测与反调试功能，避免资源泄露，且不影响内核函数的调用。\n2、重点函数多途径检测：对于多种主流的HOOK手段进行针对性检测，避免重点内核函数被攻击者利用造成应用安全性降低。  \n3、采用CRC全量检测内核代码：初始化时采用CRC计算出内核代码的值，在进行重要操作前再次计算当前内核代码值，防止内核代码被修改。","问题：\n1）基于Chromium内核（Chromium Embedded Framework，文后简称CEF）的客户端程序加载Web资源访问通常采用本地资源加载，通过File协议实现加载Web资源，缺点是资源文件放在本地存在泄露问题。\n2）CEF内核使用的V8 JavaScript 引擎用于内部JavaScript实现。CEF暴露了很多JS特性可以和客户端程序进行交互。而攻击者也能利用这些特性实现注入任意攻击脚本，实现监听客户与客户端的交互过程，注入恶意代码等恶意操作进而带来敏感信息泄露等严重安全风险。\n3）CEF内核相当于一个最小功能的Chrome浏览器，攻击者可以使用Chrome自带的调试工具分析整个页面的框架。\n\n效果：\n1）页面加载速度提升:CEF内核安全策略不再直接附加到窗口过程，不会在窗口事件触发后立即触发，不存在重复触发安全策略的情况，进而减少了页面的卡顿。\n2）安全防护能力提升：CEF内核安全防护从资源加载、动态代码检测与页面防调三个维度对CEF内核进行防护，采用多种HOOK检测方案对于大部分的攻击手段都能准确地识别，可以有效防止脚本注入与页面伪造的问题，采用HOOK增强的方式可以有效防止资源泄露与页面调试的问题",null,"刁晨曦/80331161","CN106709357A","CN106709357A公开了内核态通讯模块和内核态监测模块依次交互实现内核内存及内核函数指针变化的监测；内核态监测模块、内核态通讯模块、用户态通讯模块和监测规则模块依次交互，完成异常信息反馈，监测规则模块、用户态通讯模块和数据存储模块依次交互，实现疑似内核漏洞利用行为的记录。但是对比文件并未公开在初始化以及接受风控系统的指令时重新计算内核代码的代码值",null,"建议申请","发明","彭江峰"]
[3,"零售应用研发中心/投资理财开发团队/投资业务七室（成都）","一种分布式数据文件报送方法","主要发明点：\n1、将数据转换流程前置，把业务数据传输和数据转换并行化。\n2、自适应报送速率和流量控制，减少因网络带宽的限制导致异常的出现。\n3、实现报送流程的透明化管理以及自动化异常处理。\n\n与现有技术的区别：\n1、现有报送方案需要对报送数据进行统一抽取，并存储，再进行数据转换，这使得报送系统存储过多冗余数据，并且流程串行化，处理耗费的时间较长。\n2、现有系统对接不同监管机构以及业务系统时没有考虑到网络带宽限制，没有自适应控制，在数据量超过网络带宽限制后，会出现异常情况。\n3、数据报送中间过程的状态不可见，对数据报送流程的监控管理都聚焦在报送失败异常的告警上，并且出现告警后则由人工进行排查处理，这种监控方式存在很大的时间滞后性，影响整体报送效率。\n","解决的技术问题：\n1、将数据转换规则前置，对数据传输和数据转换进行解耦。\n2、充分利用分布式系统各个节点的处理能力，提高整体数据处理吞吐量，将数据报送流程并行化，提高数据报送效率。\n3、对数据报送速率和流量进行自适应控制，以解决因为网络带宽有限情况下异常的产生。\n4、对报送流程进行全程监控管理，支持设置异常管理规则，减少异常场景下对人工处理的依赖，实现报送流程可视化管理，提高数据报送效率。\n\n预计达到的效果：\n实现一种可以横向扩展、报送流程可视化、具备报送速率和流量控制的数据报送系统。",null,"肖章艳","CN103200621A","CN103200621A引入一个低通滤波器计算平滑的包丢失率；2、根据接收端反馈的网络丢包率将网络带宽划分为拥塞、空闲、满载三种状态；3、判断网络状态实时调整发送速率；若是拥塞则减小发送速率；若是空闲则增加发送速率，则重新计算当前时刻通过低通滤波器的平滑包丢失率，准备下次网络状态的判断。但是对比文件并未公开本方案中的业务数据传输和数据转换并行化，也为公开本方案中的具体速率控制策略","建议补充针对不同的网络场景以及运行场景，对自适应流量控制方案进行变更；以及业务数据传输和数据转换并行化对整个流程的影响；以及具体时如何做到流程前置的。","建议申请","发明","彭江峰"]
[4,"零售应用研发中心/投资理财开发团队/投资业务七室（成都）","一种解决个人养老金提取与税费代缴交易一致性方案","主要发明点：\n1、提出一种新的针对微服务架构下，两笔关联转账交易结果一致性的方案。提供两笔关联交易过程中出现结果不一致场景的对应策略，并根据策略执行以保持交易一致性。\n2、交易前进行预检查、冻结操作，保证第二笔交易余额充足，避免了第一笔转账成功，第二笔由于余额不足转账失败的情况。优化系统流程，提高总体成功率。\n3、解决为保持交易一致性时，需冲正交易，冲正交易失败的异常业务场景。当第一笔转账失败时，流程结束。第二笔转账失败时，余额足够，可通过重试保证业务成功。避免执行冲正操作。\n\n与现有技术的区别：\n1.现有技术缺乏两笔关联交易一致性的解决方案。目前交易一致性解决方案，主要应对单笔转账场景，仅解决单机、微服务中单笔交易结果一致性问题。不能满足两笔关联交易，例如个人养老金提取与税费代缴交易关联交易转账结果的一致性。\n2.目前保证交易一致性的方案，通过发现交易不一致时现有技术通过冲正方案处理异常交易。但冲正交易仍然存在失败的可能性，破坏了交易的一致性。","解决的技术问题：\n1.提出一种联机交易场景下，两笔关联交易跨微服务转账保持一致性的方法。该方法针对两笔关联交易在微服务架构下转账交易过程中出现结果不一致的情况，提供针对各种场景的解决策略，以保证两笔关联交易同时成功或同时失败。\n2.解决当单笔跨微服务交易存在部分失败，需冲正转账交易时，冲正转账交易失败的问题。\n\n预计达到的效果：\n对于个人养老金提取服务，需要支持客户联机提取养老金请求的同时，完成税费代缴；即同时完成个人养老金提取与税费代缴转账的联机交易，并保证两笔关联转账结果的一致性，实现个人养老金提取与税费代缴转账交易同时成功或者同时失败。",null,"陶文元","CN109523378B、CN112001801A","CN109523378B在跨系统转账交易过程中检测是否存在转出方与转入方交易不一致的情况,若检测到存在转出方与转入方交易不一致的情况,则根据转出方与转入方交易不一致的情况确定与之对应的策略,并根据策略执行预定操作以保持交易一致性。由于本实施例根据不同的情况采用不同的策略以保持交易一致性,提高了在各种情况下转出方与转入方交易的一致性,进而减轻了业务调账的压力。CN112001801A中，如果账户余额小于转出数额,则终止进行转账处理,并返回转账失败。在本说明书实施例的账户A的余额分布在区块链1~区块链3的情况中,在单条链中执行转账交易时,无法对多条链的余额进行汇总以进行交易合法性检查。因此,在本说明书实施例中,可以由区块链平台11在向区块链发送转账交易之前就对该转账交易进行合法性检查,为了进行该合法性检查,需要获取该转账交易执行时的转出账户的余额。但是并未公开本方案中的将第一次交易数据冻结，以抵扣第二次交易数据。","建议将养老金等上位成交易数据，避免出现申请主体的问题","建议申请",null,"彭江峰"]
[5,"零售应用研发中心/投资理财开发团队/投资业务七室(成都)","一种灵活高可用的消息指令通用转发方案","主要发明点：\n多业务系统消息指令转发的场景中，当指令是一组具有先后顺序和关联性报文，不同类型的指令对应的是不同通信协议的下游业务系统时，本发明提供了一种灵活、高可用的消息指令通用转发方案。创新点如下：\n1.可以对不同通信的下游系统配置不同消息指令的转换、通信、处理，实现对通用指令的灵活转发，不需要为接入不同的业务系统框架做二次开发，灵活性和复用性高。\n2.对具有先后顺序和关联性报文的成组指令，可保证一组相关报文能被下游业务系统同一库处理，保障业务的完整性、连续性。\n3.在消息指令转发系统的部分数据库异常时，提供了一种可以切换到指定分库的路由策略，实现多分库随时切换，保障报文转发的高可用性。\n\n与现有技术的区别：\n1.现有技术缺乏对不同通信协议的下游业务系统处理的多类型消息指令的灵活配置、处理、转发。\n2.现有技术对于具有先后顺序、关联性、连续性，且仅第一跳包含下游业务系统路由信息的一组消息指令，缺乏保证其路由到下游业务系统的同一分库处理的方案。\n3.在满足同一组指令业务系统能连续性处理的前提下，现有技术不能达到高可用，缺乏中间件或数据库发生异常时的处理方案。","解决的技术问题：\n1.多业务系统消息指令转发的场景中，适配不通信协议的下游业务系统的不同类型的消息指令解析与报文转换，实现对消息指令的灵活转发。\n2.在具有先后顺序和关联性一组消息指令的转发场景中，保证同组消息指令能被下游业务系统的同一库处理。\n3.在消息指令转发系统的部分数据库异常时，可切换到正常分库，保证转发不中断，不影响业务系统。\n\n预计达到的效果：\n1.多业务系统消息指令转发的场景中，针对不同通信协议下游业务系统，可以对不同指令进行配置、处理，实现消息指令的灵活转发，不需要为接入不同的业务系统框架做二次开发。\n2.在具有先后顺序和关联性一组报文的转发场景中，能保证同组指令能被下游业务同一库的处理，无需业务系统再次路由，保障金融业务的完整性、连续性；\n3.在消息指令转发系统的部分数据库异常时，提供了一种可以切换到指定分库的路由策略，实现多分库随时切换，保障报文转发的高可用性。",null,"谭雅兰","CN112866268B、CN114020488A","CN112866268B提供了一种报文处理方法及系统，可用于金融领域或其他技术领域，该方法包括：接收待处理交易报文信息，该待处理交易报文信息包括：服务私有报文数据、待处理产品服务标识和待处理路由前置标识；根据本地内存中的上下游报文结构配置表、报文交互配置表、所述待处理产品服务标识和待处理路由前置标识，确定所述待处理交易报文信息对应的公区报文数据；根据所述服务私有报文数据和公区报文数据，组装得到目标交易报文信息；将所述目标交易报文信息输出至所述待处理路由前置标识对应的路由前置层微服务群组。CN114020488A中，该业务信息获取指令包含下游业务执行时需要上游业务提供的业务信息,例如可以是,业务信息编号、业务信息条数、业务信息类型等。与本申请中将第一跳报文的相关信息进行存储存在区别。",null,"建议申请",null,"彭江峰"]
[6,"零售应用研发中心/投资理财开发团队/投资业务七室（成都）","一种联机服务集群的信创数据库迁移方法","主要发明点：\n1、本方案对数据库交易数据进行按照客户维度进行切片，迁移过程按照切片后的交易数据进行多批次数据迁移。\n2、本方案在数据库迁移过程中不关闭数据库，通过联机服务集群控制迁移客户的交易写请求，保证迁移过程中无增量数据的写入，以此保证迁移前后数据一致性。\n3、本方案对切片后交易数据进行分类分步迁移，步骤一先迁移数据量小的客户活跃交易数据，步骤二再迁移数据量大的客户历史交易数据；只在步骤一关闭联机服务集群迁移客户的写请求，步骤二恢复迁移客户的写请求。\n\n与现有技术的区别：\n1、传统方案都是大规模数据迁移，需要同时考虑数据迁移的一致性、迁移的时效问题，极大地增加迁移时间。\n2、传统方案未能考虑迁移过程中增量数据的写入，导致迁移途中数据丢失，迁移前后无法保证数据一致性。\n3、传统方案通过关闭待迁移数据库，保证迁移前后的数据一致性，但是迁移过程中整个联机服务集群无法对外提供服务。\n4、传统方案数据迁移对数据整体一起迁移，增加了数据迁移时间，数据库停机耗时长，联机服务中断时间长。","解决的问题：\n1、通过对交易数据进行切片迁移，减少大规模数据的整体迁移，极大优化了迁移时间，解决了数据迁移大事务的问题。\n2、通过关闭联机服务集群的交易写请求，保证迁移过程中迁移客户交易数据无增量数据的写入，保证数据库迁移前后数据的一致性。\n3、在迁移过程中，通过联机服务集群只控制迁移客户的交易写请求，只影响迁移部分客户这一小部分用户的交易，不影响整个联机服务集群用户的交易。\n4、整个数据库迁移过程不影响联机服务集群所有用户的读请求，极大提升了数据迁移过程中联机服务集群的可用性。\n5、通过对交易数据进行分类分步迁移，极大减少了迁移中客户交易中断的时间。\n\n预计达到的效果：\n1、在保障数据库迁移前后数据一致性的前提下，避免数据迁移大事务的问题，减少整体数据库的迁移时间，降低迁移过程对联机服务集群用户交易的影响。",null,"乔飞","CN109634635B、CN115237449A","CN109634635B中，执行第一次数据迁移,将旧系统的数据迁入到新系统中,在第一次数据迁移过程中所述旧系统正常执行交易,其中,在所述第一次数据迁移过程中所述旧系统不提供客户账户数量增减的交易。所述第一次数据迁移至所述第二次 数据迁移前期间所产生的数据量小于第一次数据迁移的数据量。CN115237449A中，在双集群数据库切换过程中,在预设时间内(秒级)拦截并缓存用户交易数据,以保证同一时间客户交易的变化只在单一的集群数据库上运行,避免由于数据库升级而引起的客户交易不一致问题。但是具体的迁移方式与本方案存在区别，且并未公开本方案中的根据客户维度进行切片等特征。",null,"建议申请",null,"彭江峰"]
[7,"零售应用研发中心/投资理财开发团队/投资业务七室（成都）","一种业务无感的多系统结算数据及流量迁移方案","主要发明点：\n1、基于动态配置的方式，实现多系统数据流量多粒度可控迁移方案；\n2、基于微服务调用，实现收付交易数据交叉检查和实时核对机制，保障资金交易安全；\n3、基于数据异步同步和步骤控制，实现业务的全局唯一，多端处理，保证新旧系统无感切换。\n\n与现有技术的区别：\n1、现有技术大多采用手动或软件进行大粒度或全量迁移，无法适配结算系统迁移需要保证的灵活性和可靠性；\n2、现有技术在迁移过程中，仅保证数据的一致性，并未保证资金交易的唯一性，可能发生重复交易的重大安全隐患；\n3、现有技术在迁移后仅支持单轨运行，回退成本巨大，出现问题时无法及时响应，与结算系统所要求的及时性相悖。","解决的技术问题：\n1、与上下游多个系统的迁移解耦，保证结算系统的独立性和可用性；\n2、新旧系统并行处理业务，保证业务在迁移阶段平滑过渡和唯一性；\n3、迁移期间新系统出现不可用时，可快速回退到旧系统进行业务处理，保证业务的连续性。\n\n预期达到的效果：\n1、上下游多个系统同时迁移时，结算系统可以通过动态配置的方式，适配新老接口，实现多系统数据流量多粒度可控的迁移，无需为适配上下游新接口而进行二次开发；\n2、兼容业务操作习惯的同时，确保新旧系统同时在线运行，在确保全行出款速度的前提下，保证业务数据的唯一性和可靠性；\n3、在迁移期间出现系统不可用时，提供了便捷、快速的回退策略，以确保业务的连续性和时效性。",null,"李思宁","CN117492820A","CN117492820A在新旧系统并行期间，接收旧系统发送的业务请求；获取所述业务请求在新系统中对应的路由地址和业务群组唯一标识，将所述业务请求、路由地址和业务群组唯一标识存储在浏览器窗口中；应用所述新系统的桥接层从所述浏览器窗口中获得所述业务请求、路由地址和业务群组唯一标识；基于所述业务请求、路由地址和业务群组唯一标识，加载所述业务群组，以完成所述业务请求对应的业务处理过程。但是对比文件并未公开数据异步以及数据交叉核验等技术特征。",null,"建议申请",null,"彭江峰"]
[8,"零售客户经营开发团队/互联网客户经营开发室（杭州）","一种高可用的直播系统多云架构建设方案","（1）多云互备方案：实现了直播间维度对接多家云服务商的功能，支持观众端通过智能调度策略优选最佳直播厂商；\n（2）自研云厂商的质量评价模型：云厂商质量QoS建模建立了关键指标与主观测试结果的关系，为后续的流量精准调度提供了可能；\n（3）基于监控实现线上问题自愈功能：在异常唤起时依赖于现有的聊天室功能，实现直播中用户无感知切换至正常云厂商功能。","问题：\n（1）新增厂商无法快速接入：目前直播系统涉及的组件有50多个，部署实例上百个，先前的直播框架新引入云厂商的改造代价过大，每每云厂商接入改动动辄改动多个组件和存储结构，费时费力；\n（2）实现单场直播动态调整调度比例：在大型直播中，多家CDN厂商提供的容量、质量会各不相同，需要构建动态调整调度流量比例的功能，精确化按比例分配流量，以及尽可能地确保体验。\n（3）云厂商监控盲区：先前直播业务中经常遇到服务商的CDN节点下行速度较慢，CDN转码服务出错，或者CDN节点存储的直播流有问题等故障，此类问题只有在生产上大面积出现或者等到客户报障信息过来我们才能发现，没有完备的监控告警功能，更无法提前预知可能存在的问题。\n（4）缺乏客观的质量评价体系：要提升终端用户的观看体验，需要依赖具备全面、客观、可靠的评价体系，才能实现精细化流量分配调度，优先选择质量较好的厂商线路。\n效果：\n（1）进行多云架构扩展性提升的改造，实现直播间多云互备的方案；\n（2）设计一套针对多家云厂商的质量评价体系；\n（2）利用全链路的监控报警提前预知可能的云厂商故障，并实现了快速发现、快速修复的高可用直播架构。",null,"於慧敏","CN113347039B、CN116993188A","接收虚拟化网络功能网元的业务请求，其中，业务请求用于请求虚拟化网络功能网元进行对应的业务功能；将业务请求对应的数据结构发送至消息平台，其中，不同的业务功能对应不同的数据结构；虚拟化网络功能网元从消息平台获取数据结构的业务请求，以执行业务处理。即对比文件可以视为在接入多种云厂商时的一种架构改进，但是与本方案中的架构改进并不相同，同时，也并未公开本方案中的质量评价体系。CN116993188A获取维护厂商的评价数据并构建所述维护厂商的特征向量集合；该特征向量集合中包括多个第一特征向量；任一第一特征向量由维护厂商提供的维护服务的一个或多个评价指标值构成；对特征向量集合进行主成分分析，得到维护厂商的关键指标数据集；根据关键指标数据集确定维护厂商类型；结合厂商类型确定维护厂商的服务评分。但是与本方案中的质量评价不相同。","建议可以将直播的质量评价与招商app中直播间的个性化组件进行结合，例如跳转到不同的模块等功能","建议申请",null,"彭江峰"]
[9,"零售客户经营开发团队/互联网客户经营开发室（杭州）","一种流量智能均衡调度的消息推送方案、存储和装置","（1）多种限流方式，可以单场直播间设置独立的限流阈值，也可以设置大直播，小直播类型的限流阈值，还可以根据消息量和在线人数计算自动设置限流阈值，相比现有的一刀切式的限流方案，提供了多种选择策略。\n（2）比较高的智能化程度，前期可以根据大类设置限流，比如大直播间，小直播间，后期会根据监控指标计算后自动调整限流值，相比现有没法动态调整的限流方式，体现出了更高的智能化。\n（3）完善的实时监控，提供多种指标数据的实时监控，给智能均衡调度系统投喂数据，实时计算，实时调整限流阈值。\n（4）高效的不停机发布能力，相比现有的停机发布模式，真正做到了高可用性。","解决技术问题：\n（1）现有的限流方案比较单一，所有直播间共享一个限流阈值，一刀切式的限流对小型直播间不太友好：当触发限流时，小型直播间会出现弹幕冷清的状况。\n（2）智能化程度低，只能根据预期规划的流量去设定限流值，激增时没法自动调低限流阈值，平稳后也没法调高限流阈值。\n（3）监控告警盲区：没法监控主要的指标，在线人数及趋势、消息下发量、发言互动频率、网络带宽以及硬件资源使用情况等，所以就没法智能化去动态调整限流参数。\n（4）系统没法做到不停机发布，需要升级系统时只能等当天所有的直播结束后才能停机发布更新，无法做到真正的高可用性。\n\n预期达到的效果：\n（1）实现基于指标化的流量智能均衡调度方案，不依赖人力干预，系统自动完成。\n（2）系统拥有不停机发布能力，无需在系统流量低谷时发布升级，随时更新，随时发布，真正做到高可用性。",null,"李游","CN112615790A、CN111262791A","CN112615790A配置中心的qps阈值可实时修改,修改后同步到应用服务对应接口的限流阈值,从而达到动态调整限流策略的效果。CN111262791A在基于当前服务指标数据计算得到第一限流阈值,以及基于历史服务指标数据计算得到第二限流阈值后,根据第一限流阈值和第二限流阈值计算目标限流阈值。其中,目标限流阈值用于限制访问服务器的访问请求的数量。但是对比文件与本方案中的流量调度存在区别，并且未公开不停机发布的相关内容。",null,"建议申请",null,"彭江峰"]
[10,"零售应用研发中心/网络应用开发团队/网上银行二室(杭州)","一种敏感日志处理方案","1. 敏感日志记录规则配置，数据库表中保存敏感日志记录规则，包括服务名、接口名、匹配参数、统计时间（202402291206-202402291207）、规则生效状态\n2. 定时任务读取敏感日志记录规则信息，根据服务名、接口名称、规则生效状态查询敏感日志记录规则，将规则写入缓存；校验缓存中敏感日志规则是否过期，删除过期数据\n3. 通过过滤器读取缓存中的敏感日志统计规则，当请求接口路径、请求参数、请求时间符合敏感日志记录规则，将请求的服务名、接口名、入参、返回数据、请求时间记录到缓存，\n当匹配规则不符合则不记录敏感日志\n4. 异步读取缓存中的敏感日志记录，每秒钟或者每100条将数据写入数据库的敏感日志记录表中","问题\n1. 设计敏感日志的业务功能异常无法排查，问题无法处理\n2. 敏感日志记录到数据库，数据量庞大，浪费存储资源，方案可行性较低\n\n效果\n1. 通过将敏感日志通过规则配置的方式筛选少部分敏感日志记录到数据库可以通过接口匹配、入参匹配、时间校验，将较少的数据写入到数据，减少数据库资源浪费\n2. 敏感日志记录到数据库就可以进行异常排查，提高问题解决效率\n3. 统计规则可以实时变更，灵活高效",null,"刘奇/80326865","CN116738489A","CN116738489A公开了根据日志查询指令查询对应的原始日志,从敏感规则数据库中查询数据敏感规则,依次使用敏感规则对原始日志进行匹配,将原始日志的敏感信息替换成脱敏后的信息。但是并未公开本方案中的规则可配置以及异步读取。","建议扩展根据系统运行中的正常以及异常数据，生成筛选规则的建议信息，以在规则配置时根据建议筛选高风险的日志","建议申请",null,"彭江峰"]
[11,"零售应用研发中心/零售客户经营开发团队/电话银行二室(杭州)/经营业务开发组","客群经营背景数据集中缓存系统","主要发明点：\n1、相似数据自动识别，提升复用度：SimRank图相似度算法计算节点间相似度，在新增任务审批阶段，快速识别出完全相同来源或高度相似的数据，推动下游进行数据复用，减少硬件资源浪费。\n2、配置简单，易用：系统内部建设了任务分配、资源调度、查询切换、鉴权流控、数据溯源、配置中心、监控中心等保证整体稳定性与健壮性，开发人员只需在前端管理平台进行加载作业相关配置，无需编码，即可完成背景数据加载，调用系统提供的统一对外服务即可使用背景数据。开发人员可在管理平台直接对加载任务进行控制，通过监控中心可查看任务执行情况。这使得开发人员能够更加专注于业务逻辑的开发，开发难度大大降低，开发效率提升。\n3、完备的故障自愈：背景数据会全量加载到HBase中，仅热点数据存储在Redis集群，资源调度服务监测到集群故障，无需人工操作，系统自动实现集群迁移，同时查询切换服务降级到查询HBase，迁移完成后自动切换到新集群。另外对重要数据进行多Redis集群备份，对外服务多区部署，降低底层存储故障造成业务影响的风险。","问题：\n1、硬件/人力资源浪费、重复建设：各个开发团队各自进行背景数据加载作业开发，导致了一些高频率背景数据被加载多次，浪费了大量的Redis缓存资源。各个开发团队各自进行背景数据加载作业开发，开发工作量大且能重复，浪费了大量的开发人力资源。同时还需要投入不少精力去运维。\n2、数据治理困难：同一份背景数据，加载后的存储格式，选取的字段等等也会存在差异，如未在加载前统一存储格式，后续很难再通过缓存的背景数据去识别是否重复数据，后期就算识别出重复数据，因为存储格式不一致也存在改造的成本以及风险，造成了数据治理困难。\n\n效果：\n1、开发人员只需在前端管理平台进行加载作业相关配置，无需编码，即可完成背景数据加载，调用系统提供的统一对外服务即可使用背景数据。\n2、系统内部建设了任务分配、资源调度、查询切换、鉴权流控、数据溯源、配置中心、监控中心等保证整体稳定性与健壮性，降低了开发、运维、管理的成本。\n3、通过数据溯源、相似度计算等技术手段，在新增加载作业时进行重复性识别，推动下游进行数据复用，也避免了重复的背景数据导致的资源浪费。",null,"丁天骜/80296700","未找到足够相似的申请文件",null,null,"建议申请",null,"彭江峰"]
[12,"零售应用研发中心/网络应用开发团队/网上银行二室(杭州)","抢购活动库存高并发处理方案","主要发明点：\n1、通过本地缓存和RabbitMQ，解决多数据源中库存数据一致性问题的同时还保证库存扣减和回退的高性能；\n2、通过RabbitMQ死信队列，延迟库存消费至MongoDB时间，避免高峰期使用Redisson分布式锁消耗Redis资源，将Redis资源更多的利用在库存扣减和回退接口上\n","解决的技术问题：\n1、在高并发抢购场景中，库存属于高频变化的数据，并且对响应时间要求极高，极易出现的少量请求响应时间较长的问题\n2、使用RabbitMQ虽然可以解耦库存数据的生产和消费，但受限于RabbitMQ自身处理消息的性能瓶颈，无法进一步提高抢购期间库存处理性能\n\n预计达到效果：\n提高高并发抢购场景中，库存扣减与回退的性能\n",null,"陈晓/80374728","CN116339979A、CN117035611A","CN116339979A公开了根据所述订单数据变更库存数据的同时使用分布式锁保证库存数据的一致性。CN117035611A公开了基于所述Redis库进行分布式库存数据的库存扣减,若本地库存数据和Redis库中的分布式库存数据也不足以支持本次库存扣减请求,则生成库存扣减失败结果作为所述第二处理结果;若本地库存数据对应的本地库足够支持本次库存扣减请求或者在本地库存扣减后,对分布式库存进行扣减,Redis库也能支持本地库存扣减相较于所述目标库存扣减阈值的差额,则生成库存扣减成功结果作为所述第二处理结果。但是对比文件并未公开利用RabbitMQ死信队列等技术特征解决抢购时高并发的性能问题。",null,"建议申请",null,"彭江峰"]
[13,"零售客户经营开发团队/互联网客户经营开发室（杭州）","一种基于注册发现的消息队列全链路灰度方案","主要发明点：\n1、灰度消息队列应用部署、灰度流量调控、灰度应用转为正式应用都无需重启应用，实现对调用方的无感;\n2、一键执行灰度部署、流量调控及灰度转正，聚焦于消息队列应用的灰度功能和流量调配，无需关心内部实现细节;\n3、基于注册发现的灰度方案，模拟消息队列节点行为，可以快速响应消息队列变更及流量切换;\n4、适配于全链路灰度，消息队列层支持上下游的灰度流量传输及调控，消息队列层透传灰度标志，用于上下游的灰度通讯;","解决的技术问题：\n1、消息队列应用往往涉及到生产者和消费者，对于需要灰度功能的消息队列应用，往往流量从灰度变更到正式，需要修改配置、重新部署服务或启动服务，同时变更的过程中，会对生产者应用的生产效率和消费者应用的实时能力产生较大影响。\n2、在多个服务组件的应用系统中，正常灰度流量通过服务间调用传递，但是通过消息队列解耦的服务间调用，往往无法很好传递灰度标志，使得消息队列应用无法很好的进行灰度验证；同时，消息队列消费者应用的下游也无法继续进行灰度流量的传递。\n\n预计达到效果\n1、消息队列应用的灰度部署、流量调控和灰度转成正式等一系列流程一键化，同时无需配置更改、应用重启，快速进行消息队列生产者、消费者对正式流量和灰度流量的角色转换;\n2、在多个服务组成的应用系统中，消息队列应用可以上下承接消费者和生产者应用的灰度流量，从而实现应用系统的全链路灰度功能。",null,"魏森炳/80280743","CN114884915A、CN112015563B","CN114884915A公开了以对多个应用实例中的应用实例a和应用实例b进行灰度发布为例,灰度应用实例a'、灰度应用实例b'和灰度应用实例c组成调用链路B。网关120可以将获取到的用户请求流量划分为灰度流量和基线流量,将灰度流量输入调用链路B,来验证新发布的灰度应用实例a'和灰度应用实例b'。并且公开了通过第一应用实例的消息生产者，生成第一消息，该第一消息包括灰度属性字段，该灰度属性字段包括于指示消息自定义属性的字段，且该灰度属性字段的值用于指示该第一消息属于灰度消息，该第一应用实例为目标调用链路中运行于灰度环境的应用实例，并通过该第一应用实例的消息生产者，将该第一消息发送至MQ，再基于该MQ中的第一消息，运行至少一个第二应用实例，得到该目标调用链路的运行结果，该至少一个第二应用实例包括该目标调用链路中在该第一应用实例之后被调用的应用实例。CN112015563B公开了消息服务器将第一消息数据添加到第一消息队列,执行第一消息队列中的消息,由生产端通过消息服务器将数据发送到第一消息队列中,由消费端从第一消息队列中获取数据。但是并未公开本方案中的基于生产者和消费者两种角度来看待灰度策略。",null,"建议申请",null,"彭江峰"]
[14,"零售应用研发中心/网络应用开发团队/网上银行二室(杭州)","一种基于多级联补偿和改进型桶算法的接口流量调控方案","发明点：\n1、多级控流，分为第一级别异常限流器识别用户维度异常流量，第二级别性能限流器控制接口层面流量。防止异常流量干扰正常流量。\n2、多级限流器级联失败补偿方法。\n3、改进型token桶算法，基于权重的令牌桶token限流方案，每个请求根据接口类型/参数/用户级别消耗不同数量的令牌token，实现精准控流的目的。\n4、基于历史窗口数据和实时系统参数的桶大小自动调整。","问题:\n1、传统的桶限流算法多适用于数据链路层面，但在应用接口层面不够灵活，无法区分不同接口不同用户之间的差异，无法精准控流\n2、单一维度的域名或接口限流只能控制流量波峰，无法识别异常流量，在大量异常流量访问时可能会影响正常请求\n3、传统流量调控阈值设置死板，不能自适应调整\n\n效果：\n1、通过多个redis队列实现多级限流器设计，可以阻止外部扫描等异常流量，并平缓正常业务请求流量。对于异常流量直接拒绝，对于正常流量平缓波峰访问。\n2、改进型token桶算法，根据请求接口类型/参数/用户级别消耗不同的令牌token，精准控流。\n3、通过守护线程自动定时调整限流器参数。第一级异常限流器根据历史窗口请求数据自动调整桶大小，第二级性能限流器根据实时系统参数调整桶大小。",null,"陈永亮/80252026","CN117376263A、CN111726303B","CN117376263A公开了业务请求所需的资源令牌数量可以根据业务请求所需的流量以及每个资源令牌对应的流量确定。即公开了令牌的数量可变。CN111726303B公开了根据设备端发送的业务请求，确定请求的业务场景；根据所述请求的业务场景从所述多个限流器中匹配出目标限流器，其中，所述请求的业务场景包含于与所述目标限流器所关联的业务场景中；通过所述目标限流器对所述业务请求进行限流处理。但是对比文件并未公开本方案中的补偿方案，也并未公开本方案中针对一级和二级筛选有不同的令牌权重消耗方案。","建议补充详细示例","建议申请",null,"彭江峰"]

{"sheet":"3.4-3.8","index":2,"n_rows":29,"n_cols":13,"rows_kept":29,"cut":false,"hidden":false,"merged":[[0,0,0,6],[0,7,0,12]]}
["发明人填写",{"$nulls":6},"代理人填写"]
["序号","中心/团队/室","专利名称（暂定名称）","主要发明点/方案简述及与现有技术的区别","解决的技术问题及预计达到效果","所属技术领域","发明人","检索的最接近对比文件","检索分析\n（与对比文件相比的区别点）","待发明人补充内容\n（挖掘现场代理人提出需要发明人补充的内容）","检索结果\n如：补充内容后建议申请XX专利\n建议拆分专利（说明拆分内容）\n不建议申请，说明原因","建议申请类型","检索人"]
[1,"零售应用研发中心/零售客户经营开发团队/零售信息应用开发一室","一种针对弱云环境分布式集群数据库的高可用解决方案","发明点：\n1、搭建分布式数据库集群是双活集群提升系统可用性。\n2、搭建数据加工链路双活、建立通过交叉镜像同步\n3、应用并行查询及比较双边返回结果，比较时间戳使用最新的数据。单边正常返回、另一边报错返回或超时未返时，使用正常返回的单边数据\n4、应用侧引入云平台熔断组件，并根据分布式环境定制。","问题:\n1、分布式集群数据库节点故障常态化、故障恢复时间长\n2、分布式集群数据库存在短期间内处理能力急剧下降情况\n\n\n效果：\n1、数据双活以及接口应用双读的全链路双活方案保障在双活集群下数据最终一致性，保障数据快速一致，形成高可用基础\n\n3、通过实现自定义熔断的策略，包括熔断范围最小化，建立合理熔断退出机制解决解决熔断时长不稳定问题，实现双活双边的熔断互斥策略。最终保障只要单边服务可用情况下服务不受大的影响。",null,"魏晓/80374038","检索式（链路双活 AND 数据 AND 节点）58条\n对比文件1（CN111045966A）\n对比文件2（CN110278106B）\n","对比文件1公开了一种基于对等结构的多节点数据交互方法。该方法采用多节点对等结构、高速串行总线方式和双端口存储模式，提供多处理器间或处理器与I/O接口高速传输能力，在有限任务周期内完成多节点间数据交互，多节点间通信相互独立，构建一个多处理器组成的容错计算机。多个容错计算机间可灵活配置余度模式，实现具有高可靠性、高安全性和可配置的容错计算机系统。\n对比文件2公开了一种用于Oracle数据库长距双活网络高可用的方法，包括以下步骤：S1)在正常情况下保证一条链路active，另外一条backup；S2)在active链路发生故障后，backup链路切换为active，接替原有的链路，保证网络通信的连续性；S3)在两条长距链路发生故障后，保证本地机房内部的节点能够正常通信。本发明弥补了HAIP方案在一条中间长距链路发生故障，无法感知到，不会发生故障切换，业务会发生中断的缺陷，在两条链路都发生故障后，同机房内能正常通信。\n对比文件1和对比文件2均为公开本发明“自定义熔断策略”，的技术特征。","请补充更加完整的技术方案，如执行逻辑，实现过程等，若有流程图或效果图也可进行补充","对比文件1和对比文件2均涉及到链路双活保证数据库数据可用的技术方案，但其具体方案与本申请并不相同。故本发明具备新颖性。\n建议申请发明专利","发明专利","彭江峰"]
[2,"零售应用研发中心/网络安全开发团队/风控服务开发一室","一种PL/SQL脚本转java执行文件解决方案","发明点：\n1、根据PL/SQL脚本逻辑转译为java变量、常量、表达式\n2、根据PL/SQL脚本逻辑判断转译为java判断表达式\n3、根据PL/SQL脚本SELECT语句转译为java调度SQL查询语句，并输出结果到表达式\n4、提供PLSQL语法校验","问题：\n1、业务变量规则变更，需要修改java实现，耗时过长。\n2、PL/SQL语法与java语法兼容性问题\n效果：\n1、业务规则支持PL/SQL脚本修改规则，在线修改java实现逻辑，即时改变java规则\n2、通过固化的上下文，与PL/SQL支持复杂的业务逻辑表现",null,"黄艺文/80274437","检索式（脚本 AND 转换 AND Java ）35条\n对比文件1（CN102929680A）\n","对比文件1公开了一种将TTCN-3脚本转换为Java源代码的方法、装置及系统，以进行针对于TTCN-3脚本的编译。首先，构建TTCN-3脚本的翻译器，该翻译器在对测试目标文件进行分析验证后，将TTCN-3脚本按照预定义的翻译规则翻译成Java文件。结合翻译器的翻译规则，构建Java运行支持库，该支持库实现翻译方案中引用到的基础类，并完成对翻译生成的代码的执行和执行结果的记录等工作。通过结合翻译器翻译后的代码以及运行支持库代码，即可获得完整的符合TTCN-3语义的Java源代码。\n","请补充方案的具体执行逻辑，请着重补充与现有技术的区别所在，若有效果图或其他图表也请补充","对比文件1并未公开本发明对于java语法的转换规则，以及如何处理兼容性问题的技术特征，且对比文件1并不支持在线修改。本发明具备新颖性，建议申请发明专利","发明专利","彭江峰"]
[3,"零售应用研发中心/网络安全开发团队/风控服务开发一室","一种FLINK长窗口增量计算提升精度解决方案","发明点：\n1、处理FLINK按处理时间退窗至延迟事件计算不准确问题\n2、处理延迟事件时间按需实际退窗，提升FLINK 作业到数据库精度","问题：\n1、FLINK OVER 窗口退窗不触发自动计算，致计算结果无法更新\n2、FLINK OVER 计算存在数据延迟到达，致结算结果异常问题\n效果:\n1、退窗时触发计算，计算结果无异常\n2、数据延迟到达不影响数据计算精度，与数据库保持一致",null,"黄艺文/80274437","检索式（flink AND 窗口 AND 时间 AND 数据 AND 触发）8条\n对比文件1（CN116841511A）\n对比文件2（CN113742004A）","对比文件1公开了一种Flink动态窗口的实现方法及装置、存储介质及电子设备。该方法包括，读取关联数据流，其中，关联数据流包括Main数据流和Rule控制流；增删Rule流里的数据到广播变量；根据广播变量中的数据注册定时器触发时间，确定滑动窗口；根据滑动窗口，处理Main流。通过增删Rule流里的数据到广播变量设置定时器的触发时间，定时器根据广播变量形成窗口，实现广播流实时动态更新Flink滚动窗口大小。\n对比文件2公开了一种基于flink框架的数据处理方法和装置。该方法的一具体实施方式包括：flink框架中的窗口在接收到数据后，调用触发器中处理数据的方法，获取当前触发计算操作的触发状态；若所述触发状态为触发，则从窗口算子中调用业务处理逻辑处理所述数据，并将本次处理结果汇总至历史处理结果中，得到汇总结果；在到达定时器的时间后，基于预定方式将所述汇总结果传输至下游算子。该实施方式分离处理数据和发送汇总结果操作并分别触发，避免在大数据场景下，出现短时间内窗口积压大量数据对算子的存储状态造成压力的情况，保证了业务系统的平稳运行。\n","请补充详细的技术方案，若有流程图或其他图表也请补充到交底书当中","对比文件1和对比文件2所解决的技术问题以及采用的技术手段与本发明并不相同，且对比文件1和对比文件2并未公开本发明中对于flink底层进行改进的相关技术特征。本发明具备新颖性，建议申请发明专利","发明专利","彭江峰"]
[4,"零售应用研发中心/网络应用开发团队/网上银行二室(杭州)","一种步进式全景vr解决方案","发明点：\n1、通过世界坐标系内三点确定两个向量\n2、两个向量进行归一化后通过点乘运算计算得到两个向量的夹角弧度\n3、按以上规则依次计算观察者所在球面映射点的经度和维度位置，从而实现热点定位","问题：\n步进式全景浏览过程中，场景切换的热点不在平面上，是在观察者球面的映射点，计算比较困难",null,"杨剑/80274649","检索式（(vr OR 虚拟现实) AND 场景 AND 切换 AND 热点）5条\n对比文件1（CN107817895B）\n对比文件2（CN117409125A）","对比文件1提供了一种场景切换方法及装置，所述场景切换方法包括：获取目标视角朝向；获取各待选可跳转场景在当前场景内的相对视角朝向；分别计算各待选可跳转场景在当前场景内的相对视角朝向与目标视角朝向的差值；获取多个差值中的最小差值，并判断最小差值是否小于预设阈值，若是，则从当前场景切换至最小差值对应的待选可跳转场景。本发明提供的场景切换方法，无需在实拍场景中添加特定的热点对象，降低了对实拍场景图像的破坏；同时采用本发明的场景切换方法使得在VR模式下无需找到并凝视特定的热点对象，提高了易用性。\n对比文件2公开了计算虚拟空间内热点就近最优的全景图场景点位的方法，能够快速实时计算到最优位置点，用户在点击热点时可以立即得到响应，全景图可以迅速切换到最佳观看位置，通过快速的BVH运算速度，可以有效避免当运算时间过长时，最优角度排序和快速BVH运算的结合，确保了用户在虚拟环境中的无缝体验，用户可以自由地探索和互动，而不会受到性能瓶颈的限制，用户可以更流畅地与虚拟环境中的热点互动，因为他们可以立即到达临近热点的最优全景图点位，而不需要等待漫长的运算过程，提高用户在虚拟空间中的舒适度和，本发明在虚拟现实、网络漫游、虚拟旅游等领域具有广泛的应用前景。","请补充完整的技术方案，以及沟通过程中展示的ppt视图","对比文件1和对比文件2并未公开本发明通过点积运算经纬度确定热点的技术特征，故本发明具备新颖性，建议申请发明专利","发明专利","彭江峰"]
[5,"零售应用研发中心/网络应用开发团队/网上银行二室(杭州)","一种redis集群数据实时同步方案","发明点：\n1、redis集群间数据持续性实时数据同步。\n2、实时数据同步任务自动恢复。\n3、数据同步补偿机制。","问题：\n1、目前市面上没有较为成熟，高可用的持续性增量redis集群间数据同步的工具。\n效果：\n1、可以进行持续性redis集群间数据同步并具备完善的数据同步任务恢复，数据补偿机制，拥有较高可用性。",null,"于洋/80308123","检索式（redis集群 AND 主 AND 备 AND 同步）17条\n对比文件1（CN113190620A）","对比文件1公开了Redis集群之间数据的同步方法、装置、设备及存储介质，用于提高两个Redis集群之间同步数据的同步效率。Redis集群之间数据的同步方法包括：基于主从协议同步第一Redis集群内的原始数据，复制得到同步数据；通过第一Redis集群的备用节点向第二Redis集群发送同步请求；获取第二Redis集群响应的返回数据指令，并对返回数据指令进行判断；当返回数据指令为同步全量数据指令时，利用多线程和批处理的操作方法向第二Redis集群传输同步数据对应的全量数据；当返回数据指令为同步增量数据指令时，通过多线程和批提交的操作方法向第二Redis集群传输同步数据中的更新数据。","请根据沟通内容补充完整的技术方案，若可以的话，请集各个场景补充一个整体的实施过程","对比文件1的技术方案，此外暂未检索到其他相关技术文件，本发明具备新颖性，建议申请发明专利","发明专利","彭江峰"]
[6,"零售应用研发中心/网络应用开发团队/网上银行二室(杭州)","一种基于RabbitMQ的抢购分级流程和异常重试方案","发明点:\n1.多重分级的四层高并发抢购方案\n2.异常流程发起自动幂等重试，降低用户抢购成本","问题：\n1.传统高并发抢购限流方案采用限流一刀切的方式，未真正达到系统瓶颈\n2.限流用户反复抢购，用户体验差\n效果：\n1.提升系统最大并发处理能力；\n2可根据系统承载能力动态调整多个分级阈值，显著提升用户体验。\n3.异常流程幂等重试，流量削峰，提升系统稳定性。\n",null,"俞富强/80234618","检索式（高并发 AND 分流 AND 分级）1条\n对比文件1（CN104836680A）","对比文件1公开了一种FOTA升级的处理方法和系统，所述方法包括步骤：策略服务器接收客户端的升级请求，根据预设的升级策略判断是否满足升级条件；当满足所述升级条件时，策略服务器将所述升级请求发送给FOTA服务器进行FOTA升级；当不满足所述升级条件时，策略服务器不予发送所述升级请求至FOTA服务器。从而，通过负荷保护策略、区域分级策略、设备分级策略等升级策略对客户端发起的升级请求进行过滤，有效分流了并发的升级请求，防止同时出现大量的升级请求而使得FOTA服务器因超负荷工作而导致卡死、宕机、无响应等情况，保证了FOTA服务器的稳定性。","请根据沟通内容补充完整的技术方案。","对比文件1与本发明的技术方案并不相同，此外暂未检索到其他相关技术文件，本发明具备新颖性，建议申请发明专利","发明专利","彭江峰"]
[7,"零售应用研发中心/网络应用开发团队/网上银行二室(杭州)","一种针对文档文件转换任务的拆分和调度处理方案","发明点：\n1、文件跨多实例分治处理，提高系统整体吞吐性能及资源利用率。\n2、一个综合了文件处理粒度拆分，动态任务监控，实例运行负载计算的调度算法处理平台，提高了系统的运转效率。\n3、提供开箱即用配置化快速接入处理能力。\n","问题:\n1、请求体过大，影响系统稳定性：文档转换耗费内存/cpu资源较多，对于较大文件的转换类任务，占据了较多系统资源，可能会导致内存溢出或影响其他接口的服务响应速度。\n2、资源分配不均衡：文档转换类服务存在分发不均，单实例接受多个转换请求导致负载过大，多实例忙闲不均的情况，导致系统资源利用率低。\n3、任务调度效率低：现有设计基于多线程加速处理文件转换流程对转换优先级，文件处理粒度，实例负载，转换进度等因素没有很好地均衡，影响系统整体的任务执行效率。\n\n\n效果：\n1、系统可以根据拆分策略做到文件粒度的合理拆分，均衡实例间的处理能力，实现系统整体吞吐性能的最大化。\n2、通过构建文件转换处理中心，接收客户端的在线/离线转换请求，通过监听获取子实例健康检查状态及实例系统运行负载等多维信息任务构建调度算法，\n实现任务异步编排处理，文件转换进度监控，失败调度重试，文件合并等流程，提高任务处理速度和整体资源利用率。\n3、设计了一套针对文件处理转换的任务监控调度处理机制。\n",null,"陈曦/80328021","检索式（文件 AND 粒度 AND 调度 AND 负载）4条\n对比文件1（CN101571813B）","对比文件1公开了一种多机集群中主从调度方法。在多机集群环境中进行进程主从状态的指定，在多个服务器上部署同样的应用系统，通过对应用系统进程进行分组，实现在多台主机上对进程组的主从状态的均衡分配。在多机集群出现单点故障时，将该主机上运行为主态的进程迁移到其他主机上运行。当某个服务器上某个主态应用进程退出时，将其功能迁移到负载相对较低的其他主机上。具体是在每台集群主机上安装一个集群控制软件、开发接口库和集群配置文件。主机间通过心跳报文进行信息传递，调度的粒度是进程组，每个进程组根据对CPU的占用率配置负载因子，集群调度满足集群负载均衡调度算法。","请补充完整的技术方案，包括如何计算文件颗粒度优先级，以及调度算法的执行逻辑","对比文件1并未公开本发明的相关技术特征，此外未检索到其他与本发明较为相似的专利文件，故本发明具备新颖性。建议申请发明专利","发明专利","彭江峰"]
[8,"零售应用研发中心/网络应用开发团队/互联网活动开发室(杭州)","一种针对云原生环境长连接的高可用消息保序聚合方案","发明点：\n1.云环境中长连接的消息保序设计\n2.长连接消息聚合方案，节省带宽，提高资源利用率","问题：\n1.云环境下原生长连接消息稳定性难以保证，网络波动导致消息乱序，影响客户端\n2.如弹幕等海量消息场景，不聚合的情况下投递消息造成带宽资源的严重浪费\n\n效果：\n1.在云环境下网络波动情况下仍能保证消息有序\n2.可以支持消息聚合，在海量消息场景下也不会引发性能问题",null,"郑虹雨/80234770","检索式（云 AND 长链接 AND 心跳）4条\n对比文件1（CN112187899B）","对比文件1涉及一种云托管通信方法、装置、系统、计算机设备和存储介质。所述方法应用于服务端代理服务器，所述方法包括：接收用户端代理服务器发送的当前周期的心跳上报信息；根据所述用户端代理服务器发送的当前周期的心跳上报信息，判断是否需要建立长链接；若需要建立长链接，则发送长链接建立请求至对应的用户端代理服务器；接收所述对应的用户端代理服务器发送的长链接建立响应，所述长链接建立响应用于指示所述用户端代理服务器同意建立长链接；建立与所述对应的用户端代理服务器之间的长链接。","请根据沟通内容补充完整技术方案","对比文件1所解决的技术问题和采用的技术手段与本发明并不相同，古本发明具备新颖性，此外未检索到其他相似专利。建议申请发明专利","发明专利","彭江峰"]
[9,"零售应用研发中心/网络应用开发团队/网上银行二室(杭州)","一种语音合成的多级缓存方案","发明点：\n1、音频文件上传到ECS生成音频链接，文本通过Hash散列算法生成Key。\n2、基于内存和Hbase数据库多级存储方法。","问题：\n1、语音合成速度较慢，应用对实时性要求较高，客户触发后需快速对一段未知文本进行语音合成。\n效果：\n1、语音合成服务平均响应时间从秒级提升到毫秒级，满足准实时语音播放的需求。",null,"叶学明/80291387","检索式（音频 AND 存储 AND 哈希 AND 文件）16条\n对比文件1（CN108763425B）\n对比文件2（CN107844483B）","对比文件1提供了一种存储和读取音频文件的方法和装置，属于计算机技术领域。所述方法包括：接收终端发送的目标音频文件的存储请求；获取所述目标音频文件的元数据、音频数据和文件名；对所述音频数据进行哈希，得到所述目标音频文件的摘要信息；对所述文件名和所述元数据进行对应存储，并对所述元数据和所述摘要信息进行对应存储，并在确定执行所述方法的设备未存储有所述摘要信息时，对所述音频数据和摘要信息进行对应存储，在确定所述设备存储有所述摘要信息时，不对所述音频数据进行存储。\n对比文件2公开了一种文件管理方法及装置。所述方法包括：获取与待存储的音频文件匹配的文本数据的文本长度值；根据所述文本长度值，在创建的至少一个索引文件中确定第一索引文件，所述第一索引文件用于存储与所述文本长度值匹配的音频文件的索引数据；将所述文本数据的哈希标识写入所述第一索引文件；将所述音频文件写入与所述第一索引文件对应的数据文件，将所述音频文件的存储地址写入所述第一索引文件。通过将索引文件按照文本数据的文本长度值进行划分和对音频文件的文本数据进行哈希运算，实现了基于文本数据的文本长度值和哈希标识对音频文件进行存储管理，编程操作方便且支持分布式访问，文件处理效率较高","请补充完整的技术方案","对比文件1和对比文件2涉及利用哈希对音频文件进行存储，但其应用场景与本发明并不相同，且对比文件并不涉及语音合成的相关特征，本发明具备新颖性，建议申请发明专利","发明专利","彭江峰"]
[10,"零售应用研发中心/零售基础开发团队/基础开发七室(成都)","一种自适应的多数据源查询方法","主要发明点:\n1.在多数据源的查询过程中引入缓存机制,动态维护各数据源的可用状态,提高整个查询系统的可维护性和稳定性\n\n与现有技术的区别:\n本专利旨在针对多数据源查询场景中,可维护性低、稳定性差的问题,设计了一套自适应的查询方法,该方法通过引入缓存机制,使得查询系统可以在不停止对外服务的情况下,实现数据源的增加或删除.此外当部分数据源出现故障时,该缓存机制也可以保证查询系统尽可能地对外提供服务,减少系统故障带来的损失","解决的问题:在海量交易数据的场景下,受限于单数据库的存储、性能瓶颈,系统对外提供查询的交易数据不可避免得被保存在多个数据源中.查询时系统访问多个数据源的数据,根据业务规则对这些数据进行加工处理后返回给客户.随着业务扩展演进,查询系统必须面对数据源的新增或删除,或部分数据源的系统故障,如果每次事件都要导致查询系统停机维护,将导致客户的使用体验不佳,进而导致客户投诉.\n\n预计达到的效果:查询系统在使用缓存后,可以不受数据源新增或删除的影响,保证返回当前所有可用数据源中的交易数据;当部分数据源出现故障时,查询系统可以自行忽略故障数据源,正常返回其他数据源的数据",null,"党文杰","检索式（数据源 AND 状态 AND 缓存 AND 查询)4条\n对比文件1（CN112734064A）","对比文件1提供一种数据处理方法、设备及存储介质，在接收到数据查询请求的情况下，可基于各种属性参数与缓存数据的时效性之间存在的影响关系以及数据查询请求所请求查询的目标缓存数据对应的至少一个属性参数值，确定目标缓存数据当前是否处于有效状态，若目标缓存数据当前处于有效状态，则将目标缓存数据作为查询结果输出。据此，可在接收到数据查询请求的情况下，实时地确定目标缓存数据在查询时刻是否有效，这使得目标缓存数据的时效性更加灵活，不再受到固定有效期的局限，从而可在保证缓存准确度的前提下，尽量减少对数据源端的接口的调用次数","请根据沟通内容补充完整的技术方案，包括如何确定数据源状态等","对比文件1的技术方案公开了本发明的部分技术特征，如查询数据源状态是否可用，但并未公开其他技术特征，本发明具备新颖性，建议申请发明专利","发明专利","彭江峰"]
[11,"零售应用研发中心/零售基础开发团队/基础开发七室(成都)","一种基于分布式路由高并发交易系统的分表方案","主要发明点：\n本发明提供了一种交易系统基于分布式路由的动态时间片分表方案\n（1）该方案引入了分布式路由存储交易请求中若干唯一key值到对应处理分库和分表的映射，以便后续关联请求能准确定位具体分库分表\n（2）提出了一种可动态配置分表数量以及分表时间片的方案，支持未来根据交易量增长趋势动态扩分表\n\n与现有技术的区别：\n当下交易系统主流分表方案主要有hash切分和时间片切分，两个方案都有明显的缺陷：\n（1）hash分表，在动态扩、缩分表时，涉及繁琐的数据迁移工作，而且hash分表意味着同时使用多套表，在数据清理时也要清理多套表，清理若占用过多资源会影响联机交易\n（2）传统时间片分表，相比hash分表天然支持水平扩展，容易控制单表数据量，且方便数据清理，但问题是，首先，不可能所有业务场景都有时间属性，其次，多笔报文交易场景下，后续报文不一定会带第一笔报文的时间，会导致计算分表失败，因此，部分交易系统引入中间路由层存放分库分表健值到具体库表的映射，这样做，涉及多笔报文交易会写入多笔路由记录，路由表的数据量比交易表多好几倍，若要做到分库随机多活，路由还需要在同逻辑分组分库内互备，数据量远多于交易表，TDSQL表数据量不建议超过1000万，路由表成为了时间片划分瓶颈所在。\n本方案旨在对以上问题进行优化，实现一套灵活、优雅、可拓展、数据清理友好的分表架构","解决的问题：\n信创改造使用TDSQL，单表数据量建议控制在1000万以下，基于此背景和上述问题，我们提出一种基于分布式路由的动态时间片分表方案，针对交易表和路由表数据量增长速度差异，提出两套分表策略：\n（1）交易表按照时间片动态划分且支持自适应切换，多套表循环使用，解决hash分表不方便动态扩展问题\n（2）路由表按照时间片分表+hash分子表，这样路由与交易在同一套表，数据清理按照时间维度，也能避免跨多分表清理影响到当前表联机交易业务。\n\n\n预计达到的效果：\n实现一套灵活、优雅、可拓展、数据清理友好的交易系统分表架构，可为诸多系统提供工程参考",null,"王彦鑫","未检索到相关对比文件","无","建议完善方案的各个步骤的实施细节及实施流程","建议申请发明专利","发明","周智毅"]
[12,"零售应用研发中心/零售基础开发团队/基础开发七室(成都)","一种编译期的高性能对象比较方法","主要发明点：\n(1) 编译期生成对象比较逻辑\n\n与现有技术的区别：\n现有技术都是在运行期反射java对象的元信息，补充对象比较逻辑，进而完成对象的对比。本方案在编译期完成对象对比逻辑的生成，避免了对象的动态反射，在性能上会有一定的提升。","解决的问题：\n在一些需要比较对象的场景中，如果对性能有一定要求，那么利用对象反射特性完成对象比较则不再是一种最佳选择。为了解决此问题，提出本方案。\n\n预计达到的效果：\n实现一个灵活、通用、优雅、高性能的java对象比较插件（sdk）",null,"陈安旭","对比文件1-CN110716715A-一种应用程序开发方法、装置、设备及介质","对比文件1公开了一种应用程序开发方法，包括：获取待编译的Java源码文件，所述Java源码文件包括源码程序和源码注解，通过Java源码编译器对所述Java源码文件中的源码程序进行编译，并通过注解解析器对所述Java源码文件中的源码注解进行编译，将针对所述Java源码文件编译所得的语法树编译成可执行的字节码，将所述可执行的字节码打包生成应用程序。其在运行期间直接运行字节码，一方面通过注解解决了编码效率低下的问题，另一方面通过在编译阶段编译所述注解生成字节码，使得运行期间直接运行字节码，避免了解析注解导致运行效率降低的问题.可以看出，对比文件1的代码队形，是在运行期完成编译处理的，而本方案则是在编译期处理，因此，与现有方案相比，本方案具有新颖性。","建议撰写交底时，补充方案的详细实施案例，如沟通到的从clash文件获取字段、进行异或比较，上下文比较处理等详细实现过程","建议申请发明专利","发明","周智毅"]
[13,"零售应用研发中心/零售基础开发团队/基础开发七室(成都)","一种基于影响因子的表单联动校验以及UI呈现方案","主要发明点：\n多模块中的表单项互相牵连，校验结果互相影响，如若只能按照步骤填写，严重影响填写体验，\n构建特殊数据结构，结合特定UI呈现，支持用户无需关注填写步骤，达到自动完成关联校验的方案。\n\n与现有技术的区别：\n对大表单数据因担心http请求体大小的限制，采用分模块提交，然多模块之间存在相互校验关系，元素互相影响。\n虽然按模块做个提交，能满足准确校验的目的。但是无法满足用户随意跳转填写，尤其是无法满足用户想暂存中间段信息。\n给用户表单收集的体验大大折扣。所以提出基于影响因子的联动方案以及结合特定的UI提示达到支持随意跳转，同时校验准确的目的。","解决的问题：\n解决分模块提交表单，只能按步骤校验，无法支持中间段暂存，提出的基于影响因子的联动方案以及结合特定的UI提示达到支持随意跳转，同时校验准确的技术方案以及优雅的UI呈现方案。",null,"王丽丽","对比文件2-CN113673961A- 一种基于工作流的档案调度方法","对比文件2记载了“基于工作流的档案调度方法应用于分布式异构处理系统,采用SOA的体系架构采用SOA的体系架构，通过采用工作流引擎，至少支持顺序、并行、选择和重复执行多种工作流工作方式，实现各种流程的灵活配置，可图形化的维护工作流控制数据和相关数据，实现对各种工作流的监控、管理，满足文件特殊处理要求；将分散、异构的应用和信息档案进行聚合，通过统一的访问入口，实现结构化、非结构化档案和互联网档案、各种应用系统跨数据库、跨系统平台的无缝接入和集成，提供支持信息访问、传递、协作的集成化环境，实现个性化业务应用的高效开发、集成、部署与管理，实现业务的服务化、构件化、定制化管理”。虽然对比文件2记载了能够基于不同的顺序对工作流进行处理（类似于不按照顺序填写表单），但是对比文件2记载的方案中并未说明各个工作流至今啊是有联系因子，且工作流之间能够进行跳转处理等内容，因而本方案具有新颖性。","建议本方案的具体实现过程时，例如输入框之间的关联关系，考虑引入多个页面表单之间具有关联的输入框","建议申请发明专利","发明","周智毅"]
[14,"零售应用研发中心/零售基础开发团队/基础开发七室(成都)","一种基于http cookie机制的安全灰度方案","主要发明点：\n1.基于单页面应用的Cookie的nginx高性能灰度转发的方案。\n2.安全的Cookie安全防护机制，有效预防xss，csrf的攻击。\n3.优雅的灰度和正式实时转换方案。\n\n与现有的技术区别:\n1.基于前端单页面内容hash文件系统，只对几kb的html文件进行获取，css和js文件进行缓存，二次获取高性能。\n2.抛弃传统的js cookie填入方式，采用http cookie写入，更安全。\n3.灰度和正式的转换过程实时且优雅。","解决的问题：\n1.基于前端单页面内容hash文件系统，只对几kb的html文件进行获取，css和js文件进行缓存，二次获取高性能。\n2.抛弃传统的js cookie填入方式，采用http cookie写入，更安全。\n3.灰度和正式的转换过程实时且优雅。",null,"王丽丽","对比文件3-CN115412359A- Web应用安全防护方法和装置、电子设备、存储介质","对比文件3公开一种Web应用安全防护方法和装置、电子设备、存储介质；涉及网络安全技术领域。该方法包括：响应于接收到用户在Web页面的访问请求，确定访问请求是否包括独立访客Cookie；提取访问请求中的一组或多组报文特征；若访问请求包括独立访客Cookie，统计预设时间窗口内报文特征对应的独立访客Cookie信息；根据报文特征对应的独立访客Cookie信息，确定报文特征相关的访问请求为攻击行为，并采用配置的安全处理策略处理所述攻击行为。本公开可以解决传统的网络安全设备在Web应用的安全防护过程中存在的响应处理速度慢和防护准确率低的问题。对比文件3记载的是接收到cookie信息时，根据cookie信息判断当前是否存在攻击行为，而本方案则是通过接http输入的cookie信息进行系统的安全防护，因而两者属于解决不同技术问题的方案。故本方案具有新颖性。","结合常规的web应用使用流程，举例说明","建议申请发明专利","发明","周智毅"]
[15,"零售应用研发中心/零售基础开发团队/基础开发七室(成都)","一种面向海量数据的商户对账单生成方法","主要发明点：\n1）采用流批相结合的模式提升账单生成时效性。\n2）账单生成过程流水线化提升业务扩展性：将账单文件生成过程“流水线化”，以商户作为数据聚合的最小个体编排账单生成过程各个阶段的任务。既兼顾了账单数据完备性要求，也提升了账单生成时效性的同时，也能快速支持后续业务扩展。\n3）引入无中心的负载均衡策略，有效提升系统资源利用率。\n\n与现有技术的区别：\n本专利旨在针对海量数据场景下的商户对账单文件完备性、时效性方面存在的问题，设计出了一套流水线管理模式的商户对账单生成方案，通过统一的服务聚合账单所需的各类数据，实现单一商户数据就绪后立即生成其账单文件。","解决的问题：商户对账单作为收单路径的末端产物，具备了数据量庞大、数据来源众多、数据结构不一、文件模式多样、处理时效高的特点。常规的方法是由每个渠道基于订单生成一份账单文件后再由一系统聚合生成统一的账单文件，这就造成了系统资源的浪费，更为严重的是因缺少了多方数据的一致性核对环节导致账单漏数、错数问题未得到解决。当订单规模达千万级、商户数达十万级或更多的情况下，如何快速生成商户对账单则极为棘手。\n\n预计达到的效果：账单生成时效性显著提升（商户数据就绪后立即生成其账单文件），账单漏数、错数问题充分解决，云上资源得到充分利用，抽象出数据聚合类需求的“流水线”管理范式，可为诸多系统提供工程参考。",null,"刘建平","对比文件4-CN110007836A-一种账单生成方法及移动终端","对比文件4提供了一种账单生成方法及移动终端，所述方法包括：在统计不同目标应用程序的账单信息的情况下（不同的应用程序，相当于不同的系统），接收用户对不同目标应用程序界面的触控操作；针对每个目标应用程序界面，根据触控操作确定目标应用程序界面的目标区域；识别目标区域中的文本内容；在文本内容为账单信息的情况下，提取文本内容中的各账单参数；根据各账单参数，生成目标账单信息，能够实现对于不同的支付应用程序，自动根据用户的账单信息提取到账单参数，并生成目标账单信息，便于用户对消费记录进行统计、查询等操作，操作简单，提升用户的使用体验。对比文件4记载了能够针对不同程序（不同系统）进行账单的数据生成，但是对比文件4中的账单生成过程并非是流水线方式，同时各个程序（系统）之间的数据并不存在交互过程。因此本方案具有新颖性。","请根据沟通内容提供详细资料，最好举例子说明","建议申请发明专利","发明","周智毅"]
[16,"零售应用研发中心/零售基础开发团队/基础开发七室(成都)","一种面向海量交易数据的核对方案","主要发明点：\n1. 将数据划分成块，使用merkel tree进行数据核对提升核对效率\n\n\n与现有技术的区别：\n本专利旨在针对海量数据场景下的静态数据核对，传统方案将多个数据源的原始数据进行数据核对比较，这种方式在海量数据场景下，会严重浪费网络带宽，效率低下，本专利设计出一种基于块的核对方式，大幅度提升核对效率。","解决的问题：海量交易数据场景下的核对带来的高带宽开销，低效率问题\n\n预计达到的效果：减少核对时网络带宽开销，提升数据核对效率",null,"张先卓","对比文件5-CN111309523A- 数据读写方法、数据远程复制方法及装置、分布式存储系统","对比文件5公开了一种数据读写方法、数据远程复制方法及装置、分布式存储系统，所述数据读写和远程复制方法包括：将分布式存储系统中的逻辑卷进行划分，获取多个数据块（相当于将数据划分成块），计算每个数据块的哈希值，将其作为签名；将各个数据块的签名保存在默克尔树的叶子节点上（相当于根据数据块构建树），计算每个叶子节点的哈希值，并其作为签名，将各个叶子节点的签名保存在其上层父节点上，直到将逻辑卷的签名保存到默克尔树的根节点上；根据需要读写的数据块的逻辑地址，计算该数据块的签名在默克尔树各层中的位置，并获取该数据块的签名，在读取时，根据签名通过索引获取该数据块中的内容，在写入时，更新该数据块中的内容，并更新默克尔树各层中相应位置的签名，在远程复制时，从默克尔树根节点开始，递归的比较各层节点的签名，并且只对有改动的签名及其子树进行远程复制。虽然对比文件5记载了将数据划分成块，并根据数据块构造树的过程，但是对比文件5并未记载能够根据树进行数据核对处理的过程。因此本方案具有新颖性。","请根据沟通内容提供详细资料，最好举例子说明","建议申请发明专利","发明","周智毅"]
[17,"零售应用研发中心/零售基础开发团队/基础开发七室(成都)","一种基于改良型布隆过滤器的海量数据精准定位机制","主要发明点：\n1）将本地缓存布隆过滤器和Redis布隆过滤器两种方式进行结合，同时对二者存在的一些共性问题进行解决，如重建时效以及数据倾斜等\n2）提出一种布隆过滤器一致性校验的辅助方案，本方案采用了异或和与运算结合的位运算方式，以此校验两个本地布隆过滤器与Redis布隆过滤器之间是属于一致、包含还是被包含的关系，从而作为一种辅助手段，利用该结论该进一步明确本地布隆过滤器与Redis布隆过滤器之间的包含关系后进一步对同步过程进行完善。\n\n与现有技术的区别：\n本专利旨在针对本地缓存布隆过滤器与Redis布隆过滤器各自的优劣，如何在保留布隆过滤器设计方案的前提下、对布隆过滤器使用方案进行改良。把本地缓存和Redis布隆过滤器进行结合的，以Redis布隆过滤器作为备份，让整体设计同时拥有两种载体的优点，使得整个数据定位过程可以进一步保证高效与实时。","解决的问题：当目标数据无规律可寻的情况下，系统如何能大海捞针式地在海量数据中快速精准定位并监听到目标数据以便进行后续操作？ \n\n预计达到的效果：能在空间与时间上相较于现有的方案进行优化，并抽象出技术方案，可为诸多系统提供工程参考。",null,"蒋岚","对比文件6-CN110162529B- 一种数据处理方法、业务服务器及数据处理系统","对比文件6公开了一种数据处理方法、业务服务器及数据处理系统，当接收到用户请求时，基于布隆过滤器BloomFilter和预先存储于业务服务器内存中的白名单指纹数据确定所述用户请求对应的用户是否存在于白名单数据中，若否，向用户发送不能处理业务的提示信息，若是，则查询分布式内存缓存Redis中是否存在用户，若存在，则向用户反馈用户请求响应信息。通过上述方法，当用户不存在白名单数据中时，不查询分布式内存缓存Redis中是否存在用户，当用户存在白名单数据中时，查询分布式内存缓存Redis中是否存在用户，从而减少向分布式内存缓存Redis发送查询请求的过程，实现降低分布式内存缓存Redis的资源消耗的目的。对比文件6记载了结合布隆过滤器和redis过滤器进行同时处理的方案，但是本方案中，redis过滤器是用于数据北非处理的，并非是判断是否存在用户，同时对比文件6并未记载两个过滤器基于异或方式进行交互处理的过程。因此本方案具有新颖性。","请根据沟通内容提供详细资料，最好举例子说明","建议申请发明专利","发明","周智毅"]
[18,"零售应用研发中心/零售基础开发团队/基础开发五室(杭州)","候选特征相关指数分类排序的故障点定位技术","主要发明点：\n通过抽象候选特征处理，并对候选特征排序，以便对多维度故障因素进行快速定位。\n候选特征支持快速扩展。\n\n与现有技术的区别：\n现有监控代码都是对固定特征进行监控，扩展监控特征时需要针对性开发。","解决的问题：\n目前ATM业务高可用受诸多因素制约。\n如设备机型（传统机型&信创机型）、卡片银行、底层系统部署（Oracle、TDSQL；FTC、ACS）。任何一个部分出现问题都影响整体成功率，需要对故障快速识别并隔离恢复服务。\n传统排查故障依赖人工统计数据，或者对单一指标进行监控，效率比较低下。\n\n预计达到的效果：\n通过灵活扩展候选特征，可以快速扩展故障定位效果。",null,"诸伟","对比文件7-CN106095659A- 一种非结构化事件日志数据的实时监控方法与装置","对比文件7提供了一种非结构化事件日志数据的实时监控方法与装置，此存储装置包括：事件分类器、指标计算器、指标内存数据库、事件分片与存储模块、监控平台、指标历史数据库、分布文件系统，此方法步骤包括：事件初筛：将收集的数据信息进行初步筛选；事件分类：利用事件分类器根据事件的内容进行初步的探查，根据事件的类别进行划分；指标计算：分类后的事件通过指标计算器根据一系列指标进行计算；事件划分：计算后的事件按事件类型及ID进行Hash划分，便于后续存储；事件存储：将划分好的事件保存到分布式文件系统。本发明实现了对事件的实时监控，及时处理事件日志数据，防止数据丢失.对比文件7的方案是收集到数据后将数据进行分类划分，这与本方案的收集到数据后进行归类划分的过程类似，但是对比文件7解决的技术问题提高存储效率，这与本方案中的为了对故障进行定位的目的不同，因此本方案具有新颖性。",null,"建议申请发明专利","发明","周智毅"]
[19,"零售应用研发中心/零售基础开发团队/基础开发五室(杭州)","对根据用户ID分流的分布式双活部署的系统解决手机登陆不能分流的方案","主要发明点:\n1、通过对微服务中心另一分库的探活来决定是否执行Saga分布式事务管理这样当一分库宕机时仍能保证双活部署的高可用性。\n2、手机号登录时通过使用Saga 分布式事务管理对双活部署系统不同数据库中用户登录信息做同步，这样保证了系统的实时性和一致性，提高用户体验。\n\n与现有技术区别:\n现有技术方案包括1、将用户系统独立成单独的应用，通过查询手机号和用户ID的映射来分流，这样整体系统的可靠性严重依赖用户系统，本方案相比不会降低系统可靠性。2、通过实时或者异步的方式在分库间同步数据，对于实时同步的方式要考虑两边事物失败回滚的问题，而对于异步的方式则需要考虑失败兜底同时会存在一定的延时影响用户体验，而本方案则不存在该种影响。","解决的问题：\n对于按用户ID维度分流的分布式双活系统当用手机号登录时，会存在因为不知道用户ID导致无法分流的问题。\n\n预计达到的效果：\n对于分布式双活部署可以在输入无分流因子的情况下不借助白名单或调用外部接口查询分流因子的情况下也能使双活部署系统的正常使用。",null,"刘一龙","对比文件8-CN108040072A-分布式网络下移动互联网APP单点登录的系统和方法","对比文件8提供了分布式网络下移动互联网APP单点登录的系统和方法，以此提高用户在不同应用之间互信访问，实现分布式网络环境下应用相互集成授信访问，完成登录一次，全局访问，用户端向EAPP服务器发送登录请求，EAPP服务器向数字认证中心SSO发送用户端的登录请求进行SSO单点登录认证，认证通过用户端即在EAPP服务器完成单点登录，用户端能够访问所有与EAPP服务器通讯的APP服务器。对比文件8记载了分布式网络夏根据用户的登录请求完成单点验证的过程，并未记载登录过程跟用户id以及进行双活部署登录的内容。因此与对比文件8相比，本方案具有新颖性。",null,"建议申请发明专利","发明","周智毅"]
[20,"零售应用研发中心/零售基础开发团队/基础开发五室(杭州)","一种多数据库分库联机系统单库宕机时降级为部分数据库多活的方案","主要发明点：\n联机业务为了保障高可用性，采用多库多应用组成集群提供，按照指定的因子路由到指定数据库提供服务。当某一个数据库宕机时，路由模式改为多数据库随机分发，减少业务受影响时长。在多库随机分发时，需要保证业务全局唯一，需要防重处理，反向交易需要路由回对应的分库。","解决的问题：\n业务系统基于云服务（数据库、应用）提供服务，云服务比起传统主机，层级复杂，故障率高。在应用正常工作，数据库异常的情况下，仍需要保证系统正常提服务，无需等待数据库恢复，即可切换到其他分库继续提供服务，解决了数据库不稳定环境下系统高可用性",null,"马敬川","对比文件9-CN114443768A- 分布式数据库的主备切换方法、装置及可读存储介质","对比文件9提供了分布式数据库的主备切换方法、装置、系统及可读存储介质，该分布式数据库包括一个或多个代理以及与代理连接的多个数据节点，该方法包括：当第一数据节点发生宕机时，对第一数据节点进行主备切换；在对第一数据节点进行主备切换过程中，代理将原本路由到第一数据节点的交易切换路由至第二数据节点；以及，当第一数据节点的主备切换完成后，代理将路由到第二数据节点的交易切换路由至第一数据节点。也即对比文件9记载方案是数据库宕机后，将数据存储到其他节点的技术方案，直到该库恢复，但是并未涉及到多个后备库时的防重处理。因此本方案具有新颖性。",null,"建议申请发明专利","发明","周智毅"]
[21,"零售应用研发中心/零售基础开发团队/基础开发二室(杭州)","快速获取额度的方法","主要发明点：\n将联机计算多维度模型额度的流程，变更为提前计算额度，实时查询获取。\n\n与现有技术的区别：\n现有技术通过联机分析数据得到产品额度，会存在耗时长并发度低等问题；而新技术提前获取并验算惰性数据后，将计算结果缓存到对应产品，客户分别获取额度时只需查询数据库即可，等待时间少并发度高","解决的问题：\n客户在非柜面渠道止付限额超限后，无法快速获取中非额度，不能及时解除断卡限制，客户体验差的问题。\n\n预计达到的效果：\n快速获取中非额度，及时跳转手机银行进行额度调整，快速完成支付。",null,"李曾阳\n（联：高鸿程）","对比文件10-CN115760369A-授信额度确定方法及装置","对比文件10公开了一种授信额度确定方法及装置，涉及人工智能技术领域，该方法包括：接收目标商户的授信额度确定请求，根据授信额度确定请求，获得目标商户的授信额度数据；根据授信额度数据和预设的商户分类模型，确定目标商户的商户类型；根据授信额度数据和预设的授信额度评价模型，确定目标商户的授信额度评价等级，预设的授信额度评价模型是根据批量历史商户的历史授信额度数据和真实授信额度评价等级对第二分类算法进行训练得到的；根据授信额度评价等级和商户类型，确定目标商户的授信额度。对比文件10记载了接收到额度请求后，通过模型算法对请求进行处理，得到相关额度信息，但是本方案并非是接收到请求才进行额度的查询的，因而与对比文件10相比，本方案具有新颖性。",null,"建议申请发明专利","发明","周智毅"]
[22,"零售应用研发中心/零售基础开发团队/基础开发二室(杭州)","通过配置计算支付限额的方法","主要发明点：\n支付限额模型的所有因子的限额计算规则通过配置的方式体现，调整单个因子的计算规则无需修改作业脚本，只需要修改配置即可生效。\n\n与现有技术的区别：\n计算支付限额的模型通过代码实现，调整规则需要修改代码。","解决的问题：\n限额计算模型迭代较快，规则变化比较频繁，原有技术不能快速响应规则的变化，不能及时上线生效。\n\n预计达到的效果：\n通过配置调整模型，可以快速开发迭代，能够及时生效。",null,"李曾阳\n（联：高鸿程）","对比文件11-CN108573443A-额度审批方法和装置","对比文件11公开了一种额度审批方法，该方法包括步骤：当接收到用户的额度审批请求时，额度审批系统通过工作流引擎获取所述额度审批请求中与所述用户对应的标识信息；根据所述标识信息在预置信息库中获取对应的审批信息；根据所述审批信息，通过预设规则确定所述用户的审批额度。可以看出，对比文件11记载了能够通过预设规则进行额度的计算的过程。为提高方案的新创性，建议将该方案与“快速获取额度的方法”方案合并成一个方案。",null,"建议将该方案与“快速获取额度的方法”方案合并成同一方案。","发明","周智毅"]
[23,"零售应用研发中心/网络应用开发团队/互联网运营开发一室(杭州","一种针对实时交互场景下客户多品类财富产品持仓分析与资产配置建议的解决方案","主要发明点：\n结合规则引擎和客户收益预期量化的方程开放性求解过程，在给出开放性持仓优化建议过程中，追求配置安全、效率提升以适用于客户实时交互场景。\n\n与现有技术的区别：\nKIE规则引擎的决策过程意图清晰、执行高效，但对客户资产配置优化建议这样结论开放的场景应用比较困难；而完全的数学条件约束对客户多品类、长年限的财富资产配置优化过程又过于复杂，难以直接应用于客户实时交互场景；配置发布过程匹配银行业发布安全机制上相对欠缺。","解决的问题：\n结合规则引擎和客户收益预期量化的方程开放性求解过程，实现完成的业务知识承载、展示与应用的同时，使包括给定数学约束下最优化求解过程在内的复杂逻辑，能够在客户实时交互场景下安全、高效执行。\n\n预期达到的效果：\n定义决策规则，定义业务约束，匹配规则执行与约束下最优化求解执行过程，相关业务配置发布过程可验证、可灰度、可回滚。",null,"鲁厶语/80296844","对比文件12-CN115496599A- 持仓分析方法及其系统、计算机设备","对比文件12提供了一种持仓分析方法，包括：获取若干金融产品的交易数据；根据预设分类规则对所述交易数据进行分类处理以得到若干数据组，其中，所述预设分类规则包括若干交易类型，每一所述数据组与一种交易类型相对应；根据所述交易类型从规则库中调取持仓分析规则，其中，所述规则库包括与所述交易类型一一对应的持仓分析规则；以及根据所述持仓分析规则对所述数据组进行分析以得到若干持仓结果。对比文件12虽然记载了通过预设的规则对金融交易数据进行分析处理，的都持仓结果，与本方案的对持仓数据进行分析预测的内容不同。因此本方案具有新颖性。","建议抽象出金融规则，方案不体现具体的金融计算规则","建议申请发明专利","发明","周智毅"]
[24,"零售应用研发中心/零售客户经营开发团队/零售信息应用开发一室","一种针对亿万级文件数据快速入联机库的高可用解决方案","\n发明点：\n1 采用消息中间件，支持跨AZ运行的问题，并且通过动态调整各种组件执行的并发度，提高资源的利用效率；\n2 通过拖拉组件和注册组件的方式，灵活地实现复杂工作流的配置，快速支持数据迁移、数据统计和数据校验,保证了数据的准确性；\n","问题:\n1 批处理联机加载架构存在问题，服务单元无法支持跨AZ运行\n2 批处理联机加载主要是面向C端客户，对数据的校验、任务执行的并发度等要求特别高，还需支持不同数据源的加载和数据的迁移等，包括复杂的分库分表等场景；\n\n\n效果：\n1、可以用“平台化”的方式进行建设，实现工具和业务分离，让开发人员更聚焦业务功能；\n2、可以用“工作流”的方式进行调度，并以“组件”的方式具体执行和扩展，支持开源共建；\n3、可以用“模块化”的方式拆分不同的组件，支持文件、MySQL、ES、Redis、HBase等数据源，还支持增量、全量、AB表、年表、月表、日表等多种模式以及多分库的加载；\n4、通过拖拉组件和注册组件的方式，灵活地实现复杂工作流的配置，快速支持数据迁移、统计和校验；\n5、支持动态调整各种组件执行的并发度，提高资源的利用效率；\n6、采用消息中间件，解决不支持跨AZ运行的问题；",null,"曾照雄/80374224","对比文件13-CN117235053A-一种基于NIFI的简单大数据去重入库方法","对比文件13公开了一种基于NIFI的简单大数据去重入库方法。本发明提出一种基于NIFI的简单大数据去重入库的方法，该方法利用nifi组件DetectDuplicate设置redis为缓存工具对流里面的数据先进行去重，然后利用ExecuteSQL执行sql把外表的数据插入到要插入的数据库中，并且使用两级的sql执行机制，降低数据库再大数据并行时候的压力和提高数据入库的稳定性。这样的方式数据不会产生延迟，库中的数据也不会存在重复数据，并且NiFi提供了直观的可视化界面，使用户能够轻松设计、配置和管理复杂的数据流程。通过拖拽和连接预先定义的处理器，用户可以快速构建数据流程，而无需编写复杂的代码.对比文件13虽然记载了通过可视化界面进行数据的处理，但是对比文件13并未记载通过中间件跨AZ运行的内容。因此本方案具有新颖性。","建议补充具体的动态调整组件执行并发的规则","建议申请发明专利","发明","周智毅"]
[25,"零售应用研发中心/零售信贷开发团队/个人信贷六室(杭州)","一种基于数据库记录状态的服务端分布式事务处理方法","主要发明点：\n1. 设计了一套于数据库状态机，定义服务端关键系统关键交易的执行状态\n2. 基于这一状态机，实现服务端幂等，错误重试，客户端查验等能够帮助实现分布式事务全局一致性的功能\n\n与现有技术的区别：\n1. 不使用开源分布式事务框架，对客户端的技术实现无硬性要求\n2. 方案实现成本较低，除数据库外不依赖其他第三方中间件\n3. 支持服务端失败重试和自定义重试策略","解决的问题\n1. 保证服务端侧与客户端的分布式事务全局一致性，保证服务端接口的幂等性，帮助客户端更容易协调各服务端的分布式全局事务\n2. 使用分布式中间件实现分布式事务保障级别低，服务中断后数据需要人工介入恢复，运维成本较高\n3. 无需客户端接入特定框架或中间件，对客户端的实现不做要求\n\n预计达到的效果\n1. 服务端功能可靠性大幅提高，避免客户端重试导致服务端异常，\n2. 重试保证系统短时间异常恢复后，不丢失客户端请求，同时基本无需开发人员过多介入\n3. 能够帮助客户端协调各方的分布式事务，保证客户端与服务端的分布式事务一致性",null,"胡雨桐/80234734","对比文件14-CN112527473A- 一种分布式事务处理方法及装置","对比文件14记载了一种分布式事务处理方法及装置，基于分布式事务处理系统，该分布式事务处理系统包括多个存储器，各个存储器中的任意一个，对应于唯一的一个事务协调器。由于事务协调器与存储器一一对应，则根据该目标事务协调器得到的事务数据，均写入该目标事务协调器对应的存储器中。若后续步骤中需要向该事务处理请求对应的各个分支发起提交或滚回，仅需基于该存储器中的事务数据即可实现，无需调用除该目标存储器之外的其他存储器中的数据。在分布式事务处理系统的数据处理能力出现过剩的现象时，可以适当的减少接入分布式事务处理系统的中的事务协调器和存储器。对比文件14记载了通过服务器","建议补充更详细的例子，结合服务端和客户端的数据或者指令交互。","建议结合方案26的客户端的部分内容申请发明，并且和方案26同日递交。",null,"周智毅"]
[26,"零售应用研发中心/零售信贷开发团队/个人信贷六室(杭州)","一种基于数据库记录状态的客户端分布式事务处理方法","主要发明点：\n1.通过查证、查验机制驱动客户端状态机的状态流转，利用状态流转，解决客户端在服务协调过程中多服务之间数据状态一致的功能。\n2.各个服务方操作互不影响，当其中之一失败，客户端主动协调服务方数据回滚操作，保障数据一致性。\n3.在弱网环境上，通过调度触发兜底机制，实现系统自愈，无需人为干涉。\n4.方案易扩展，不同服务各自实现提交和回滚操作，不受平台限制。\n\n与现有技术的区别：\n1. 现有技术未通过状态驱动，存在依赖第三方框架，方案实现受到平台限制。\n2. 现有技术基本上都是串型执行，无法实现多方服务各自协调，互不影响。\n3. 现有技术未考虑运维成本，无法实现数据上自愈。","解决的问题：\n1,降低客户端调用多服务方数据协调成本。\n2.解决服务串型化过程中长事务资源占用，实现服务中最小事务切面。\n3.无需服务端触发，通过自动化调度+各自服务状态，实现协调层对多方服务的数据最终一致性的保证。\n\n预计达到的效果：\n1.开发人员只需关注业务逻辑实现。\n2.实现各个服务方数据上的最终一致性。\n",null,"谭宏鹏/80272942","对比文件15-CN112596867A- 一种悬挂事务处理方法及一种分布式数据库系统","对比文件15提供了一种悬挂事务处理方法及一种分布式数据库系统，涉及分布式事务技术领域。该方法可以应用于分布式数据库系统中的悬挂事务处理节点，分布式数据库系统还包括多个数据存储节点；该方法包括：检测各个数据存储节点中是否记录有悬挂事务；在检测到任一数据存储节点中记录有悬挂事务时，遍历各个数据存储节点中是否记录有悬挂事务所属的分布式事务的目标事务标识；如果至少一个数据存储节点中记录有目标事务标识，则提交悬挂事务；否则，回滚悬挂事务",null,"建议申请发明专利",null,"周智毅"]
[27,"零售应用研发中心/零售信贷开发团队/个人信贷六室(杭州)","微应用本地与服务端访问统一代理动态切换方法","主要发明点：\n本地应用访问动态切换：当开发人员在应用本地服务启动、停止后，自动实现访问目标在本地与服务端的切换\n\n与现有技术的区别：\n现有技术通过nginx等进行统一域名代理，当关闭或启动本地服务后，需要手动修改配置后，重启代理服务，无法动态进行切换","解决的问题：\n应用开发需要单独配置代理地址，本地应用服务启停后，每次都需要修改代理配置后重启代理服务，影响开发效率\n\n预计达到的效果：\n开发人员只需关注功能开发，应用启停后，自动进行访问切换，无需重启代理服务，提高开发效率",null,"孙韶辰/80254358","对比文件16-CN115242874B-应用开发阶段的网络请求代理优化方法、系统及存储介质.对比文件17-CN111427766A-请求处理方法","对比文件16记载了一种应用开发阶段的网络请求代理优化方法、系统及存储介质，所述方法包括：获取浏览器业务开发域名对应的流量；根据前端项目的代理规则配置文件对所获取的流量进行匹配；将匹配到的本地文件或远端文件返回至所述浏览器业务开发域名，完成对业务开发域名的资源替换，用以实现当前端研发人员对本地代码进行对应功能上的变更、保存时，刷新浏览器，当前域名下的资源即被替换为当前研发阶段的资源。对比文件16记载了服务端与本地资源的切换。对比文件17记载了一种请求处理方法，在代理服务器中执行，包括：接收用户发送的接口请求，并提取该接口请求的域名和路径；从预先配置好的配置文件中查找接口请求的域名和路径，该配置文件存储有多个回源接口的域名，以及接口管理平台中多个测试接口的域名、路径和对应的响应内容；若接口请求的域名或路径匹配某测试接口，或者，接口请求的域名和路径均不匹配任何测试接口、且域名也不匹配任何回源接口，则返回代理服务器的IP地址和端口，以进行mock的请求处理；若接口请求的域名和路径均不匹配任何测试接口、但该域名匹配某回源接口，则将该请求转发给所匹配上的回源接口进行请求处理。对比文件17记载了通过接口进行进行访问地址的切换，但是对比文件17并未记载在各大系统里进行微应用同一调用的过程。",null,"建议申请发明专利","发明","周智毅"]

{"sheet":"3.11-3.15","index":3,"n_rows":23,"n_cols":13,"rows_kept":23,"cut":false,"hidden":false,"merged":[[0,0,0,6],[0,7,0,12]]}
["发明人填写",{"$nulls":6},"代理人填写"]
["序号","中心/团队/室","专利名称（暂定名称）","主要发明点/方案简述及与现有技术的区别","解决的技术问题及预计达到效果","所属技术领域","发明人","检索的最接近对比文件","检索分析\n（与对比文件相比的区别点）","待发明人补充内容\n（挖掘现场代理人提出需要发明人补充的内容）","检索结果\n如：补充内容后建议申请XX专利\n建议拆分专利（说明拆分内容）\n不建议申请，说明原因","建议申请类型","检索人"]
[1,"零售应用研发中心/零售客户经营开发团队/零售基础客群经营开发室(成都)","灯塔（自助数据分析平台）","1. 零编码数据应用平台，改变报表开发模式，解放开发人力并实现快速响应业务需求。\n2. 面向业务提供自助数据分析环境，改变报表应用模式，提升业务洞察效果。\n3. 模型配置化，提升数据价值发现、决策能力。\n4. 多数据源支持，提升各种异构数据快速接入能力。\n5. 数据权限管理精细化，保障用数安全性。\n6. 系统运行告警自动化，保障平台稳定运行。\n7. 平台架构组件化及微服务化，提升平台可用性、扩展性和维护性。","问题:   \n1、报表需求规则无法个性化定制，业务规则变动引起的工作量巨大； \n2、报表需求变化快，实时性要求高，使得开发人员长期面对繁冗的机房维护工作；\n3、经营/运营报表需求旺盛，传统开发模式无法快速响应；\n4、集中于描述型数据分析，缺乏对数据诊断、预测更高阶的价值挖掘；\n5、数据在营销活动催化下的爆发式增长，造成数据库性能问题，无法预测及告警；\n6、异构数据源大量存在，使开发人员陷入枯燥的ETL工作，无法高效提升数据价值。\n效果：\n1、降低了业务用数壁垒；\n2、零编码，节约了数据分析报表开发时间，实现数据分析应用的快速构建；\n3、提升了数据价值挖掘的能力；\n4、提高了业务需求响应度；\n5、使开发人员专注于平台、框架和模型的开发，避免陷入繁冗的机房提数，提高工作效能。",null,"张兆坤/80256998","CN113885859A 一种基于SIS生产运行数据的低代码报表实现方法","本申请提出的数据应用平台能够极大地提升数据处理和分析的效率，降低技术门槛，同时保障数据的安全性和系统的稳定性，对比文件则公开了一种基于SIS生产运行数据的低代码报表实现方法，具体公开了基于SIS生产运行数据构建数据仓库，按分层理念设计，明确了数据表的作用域和数据定位，规范统一数据出入口，采用B/S结构，通过Web可视化表单设计器，实现报表数据集与表单网格进行数据绑定，零编码，拖拽操作，轻松完成中国式复杂的数据报表的相关内容，本申请与对比文件的区别在于：\n1、面向业务提供自助数据分析环境，改变报表应用模式，提升业务洞察效果\n2、自研的告警机制","建议补充有关自主数据分析平台在实际业务场景中工作的流程以及步骤示意图","建议补充后申请发明专利","发明","潘远帆"]
[2,"零售应用研发中心/零售基础开发团队/基础开发六室(杭州)","一种商户额度管控性能优化方案","主要发明点：\n通过特定算法识别商户流量变化，在高并发情况下为商户借记额度管控增加异步交易记录表的方式，降低热点数据的行锁竞争，降低请求的响应时间，提升系统的稳定性；且仅在高并发情况下增加异步控制记录，避免所有借记额度累加请求都增加异步控制记录，有效降低数据库存储压力。\n\n与现有技术的区别：\n现有解决数据库热点数据问题一般会采用Redis中间件的方案，这类方案需要系统额外增加中间件依赖，如何保证数据库和Redis之间的数据一致性会导致程序的复杂度变大；\n而新方案基于算法实时识别特定时间内热点商户的请求量变化，高并发时会异步进行商户借记额度批量累加，在降低热点数据竞争的同时，又满足了额度累计的准确性，且避免引入对于其他中间件技术的依赖。","解决的问题：\n通过流量监测识别高并发场景和普通场景，在高并发场景下采用异步批量累加商户借记额度方案，保证在高并发支付情况下系统的稳定性，解决了数据库热点问题。\n",null,"徐猛/80263584","CN110022229A 一种电网跨区传输通信系统及方法 ","本申请通过特定算法识别商户流量变化，在高并发时采用异步交易记录表管控借记额度，降低行锁竞争和响应时间，提升系统稳定性，同时避免非高并发情况下的额外存储压力。而对比文件则公开了一种电网跨区传输通信系统及方法，具体公开了流量监测实时感知通道流量的状态，包括累计传输量、当前传输量、传输速率等，自适应控制；根据流量监测数据与传输数据量，利用贝叶斯机器学习算法预测当前通道传输态势，选择最优通道作为下一次传输通道，负载均衡；当并发传输数据量时，根据流量监测与通道传输态势分配传输任务的相关内容。本申请与对比文件的区别在于：\n1、新方案基于算法实时识别特定时间内热点商户的请求量变化，高并发时会异步进行商户借记额度批量累加，在降低热点数据竞争的同时，又满足了额度累计的准确性，且避免引入对于其他中间件技术的依赖；\n2、应用场景不同，本申请用于商户额度管控，对比文件则用于电网传输","建议结合商户额度管控等应用场景补充具体实施例","建议补充后申请发明专利","发明","潘远帆"]
[3,"零售应用研发中心/零售基础开发团队/基础开发六室(杭州)","一种ETC欠款后轮询补扣方案","主要发明点：\n对于欠款的黑名单客户，定期轮询补扣客户名下所有卡，尝试进行自动补扣，保证及时收回银行的损失。\n\n\n与现有技术的区别：\n现有方案，对于ETC欠款往往需要用户主动进行补缴或者需要只能固定从某一张卡中进行扣款，发生欠款后容易产生坏账；\n而新方案会定期自动进行补扣，并且补扣用户免密协议下的所有卡，提高了补扣成功率，在用户卡余额充足后就能自动完成补扣，提示了用户体验，降低了坏账风险。","解决的问题：\n对于我行ETC保付垫资类欠款交易，定期自动进行补扣，解决ETC客户欠款问题，减少坏账记录。",null,"徐猛/80263584","CN115423458A 一种基于可配置结算时间的结算方法和系统 ","本申请提出了一种有关银行与用户事先建立协议后，对ETC欠款定期轮询补扣客户名下所有卡，尝试进行自动补扣的方案，而对比文件则提出了一种于可配置结算时间的结算方法，具体公开了提供商户结算信息配置功能，商户可以根据个人的结算时间和结算频率需求配置多个商户结算时间，然后通过定时轮询查询获取到符合结算条件商户的结算信息，并根据商户结算信息对满足结算条件的商户按指定的结算时间时的账户余额进行结算的相关内容，本申请与对比文件的区别在于：\n本申请针对用户的银行卡进行轮询，轮询对象与对比文件不同","建议在轮询补扣这一应用场景中，补充轮询的具体业务步骤","建议补充后申请发明专利","发明","潘远帆"]
[4,"零售应用研发中心/零售基础开发团队/基础开发六室(杭州)","一种分布式下基于实例成功率和响应时间的路由方案","主要发明点:\n目前分布式架构下，上游应用与下游应用之间主要通过微服务中心交互。下游系统可能是多分库的架构，在负载均衡的架构下，可能部分分库正常，而部分分库底层硬件等问题，出现网络拥堵，丢包等可用性波动。如果是直接不可用，服务中心探测可以发现，但是可用性波动情况下，只有上游应用可以感知。所以需要在上游应用按照实例维度，统计下游实例的请求应答耗时、成功率等。路由到成功率高、响应快的实例。根据下游实例的健康状况，及时调整路由策略，控制下游实例的流量比例，达到避免下游实例负载过高造成宕机，合理利用资源的目的\n\n与现有技术的区别：\n现有技术大多通过路由因子固定到某个分库下的实例，没有鉴别下游实例的亚健康状态，只有在应用不可用的情况下路由到其他实例，这类方案在下游实例亚健康情况下，容易给下游亚健康实例造成过量负载，极端情况下使得下游实例宕机。而新方案是根据下游实例的健康状况动态调整下游的入口流量，不仅合理使用下游资源，也提高了用户的使用体验","解决的问题：\n通过检测下游实例健康状况，动态调整下游路由流量。解决了现有方案在下游实例亚健康状况下对下游实例负载过高，响应慢的问题",null,"徐猛/80263584","CN114785861B 一种服务请求转发系统、方法、计算机设备和存储介质 ","本申请提供了一种服务实例路由方法，通过检测下游实例健康状况，动态调整下游路由流量，而对比文件则公开了一种服务请求转发，具体公开了服务器通过探活模块主动检测服务实例的状态，在服务实例不可用前配置不可用的状态，使服务器提前获知该服务实例即将不可用，便不再向该服务实例转发客户请求，避免不可用的服务实例超时等待造成的的服务时延的相关内容。本申请与对比文件的区别在于：\n1、鉴别下游实例的亚健康状态\n2、根据下游实例的健康状况动态调整下游的入口流量","建议补充从上游到下游服务实例的业务流程以及相关附图，结合具体的业务请求补充有关实施例","建议补充后申请发明专利","发明","潘远帆"]
[5,"零售应用研发中心/零售基础开发团队/基础开发六室(杭州)","一种订单数据按频率分类存储方案","主要发明点：\n随着互联网支付的业务发展，订单支付系统的交易量日益增长，关系型数据库（Oracle、MySQL）中数据存储的压力越来越大。本发明旨在：将交易系统中订单按照日期分类，划分活跃订单与不活跃订单，活跃订单存储在关系型数据库，不活跃订单存储在非关系型数据库。同时交易系统支持非关系型数据库处理非活跃订单的功能。以此解决互联网支付业务飞速发展情况下交易系统的数据存储压力\n\n与现有技术的区别：\n现有技术主要是采取定期删除数据，或者非活跃订单存储到关系型数据库历史表的方式，但是关系型数据库的存储压力依然很大。现有方案的区别在于：\n1：将非活跃数据存储到非关系型数据库，减轻了关系型数据库的存储压力，提高了关系型数据库的性能\n2：交易系统需要支持非关系型数据库的交易处理能力","解决的问题：\n通过组合关系型数据库与非关系型数据，分别存储活跃订单与非活跃订单，降低现有方案下交易系统关系型数据库的存储压力及提高交易系统的数据库性能",null,"徐猛/80263584"," CN105577411B 基于服务起源的云服务监控方法和装置 ","本申请提出了一种数据分类存储方法，通过组合关系型数据库与非关系型数据，分别存储活跃订单与非活跃订单，而对比文件则公开了有关使用非关系数据库存储起源日志文件的相关内容，本申请与对比文件的区别在于：\n本申请用非关系数据库来存储非活跃订单，所解决的技术问题与对比文件不同","建议补充具体的订单数据频率分类的方式以及相关的数据走向示意图","建议补充后申请发明专利","发明","潘远帆"]
[6,"零售应用研发中心/零售基础开发团队/基础开发三室","一种基于191账户实现的福利发放联动支付交易方案","主要发明点：\n1.采用1企业1账户管理福利资金\n2.福利资金自动转存\n3.福利资金在联机交易发生时自动发放至客户活期完成支付交易\n4.自动化对账核对\n\n与现有的技术区别：\n1.银行内部户+限额账户的模式采用的是一个资金池子，无法详细区分不同企业的资金，有资金挪用风险\n2.内部户、限额账户申请流程复杂，审批环节多，不便于业务扩展","解决的问题：\n1.客户支付交易可自动使用福利完成支付\n，支付体验同普通一致。\n2.按接入企业分配191账户，资金专用\n3.配置化管理，新企业入驻无需开发，便于业务扩展。\n",null,"王洪涛/80274386","CN111091346A 一种员工福利通用消费支付方法及系统 ","本申请提出了一种福利发放联动支付交易方案，采用1企业1账户管理福利资金，而对比文件则公开了一种员工福利通用消费支付方法，具体公开了让用户在选定商品需要支付时，就可以将自己公司发放的福利通过支付控件的形式支付给消费公司，将自己在公司发放的福利通过自己的需求支付，从而达到方便快捷的消费自己的公司福利的相关内同，本申请与对比文件的区别在于：\n1、本申请按接入企业分配191账户，资金专用\n2、配置化管理，新企业入驻无需开发，便于业务扩展","建议结合具体的用户福利支付场景补充相关实施例","建议补充后申请发明专利","发明","潘远帆"]
[7,"零售应用研发中心/零售基础开发团队/基础开发三室","一种多应用订阅同一参数的管理方案","主要发明点：\n1.订阅关系独立进行管理\n2.订阅关系按需推送订阅方，由订阅方按需拉取订阅参数到本地\n3.参数变更主动通知所有订阅方\n4.参数订阅\n\n与现有的技术区别：\n1.更加精细化，精确到具体一条被订阅的参数\n2.订阅方应用仅能将自己订阅的参数拉取至本地，参数空间下其他未订阅的参数不会同步至订阅方","解决的问题：\n1.订阅关系同步至订阅方应用\n2.订阅方应用仅能访问自己订阅的参数，不会访问到其他未订阅参数\n3.参数修改后，所有订阅方都可以接到修改内容的通知\n4.",null,"骆明亮/80174856、傅银城/80296415","CN111752245A 数据访问及处理方法、装置、设备及可读存储介质 ","本申请提出了一种订阅参数管理方法，对订阅关系独立进行管理，并且用户按需拉取订阅参数到本地，而对比文件则公开了一种数据访问及处理方法，具体公开了有关判断预设的订阅表中的项，是否被数据访问请求中的参数命中的内容，本申请与对比文件的区别在于：\n本申请定义了参数空间，并且订阅方应用仅能将自己订阅的参数拉取至本地，参数空间下其他未订阅的参数不会同步至订阅方","建议补充参数空间的逻辑示意图并结合订阅的参数所关联的应用或者服务实例补充具体业务流程","建议补充后申请发明专利","发明","潘远帆"]
[8,"零售应用研发中心/零售基础开发团队/基础开发三室","一种基于审批流程的参数变更方案","主要发明点：\n在参数管理平台上维护参数，不会直接修改参数，而是会按以下流程完成变更：\n1.参数变更自动生成申请单；2.变更申请单由管理员审批及复核人员复核后，通过或驳回申请单；3.申请单通过后，申请人员点击发布，完成参数变更\n\n与现有的技术区别：\n1、现有技术无参数变更审批流程，容易存在误修改的风险，且无法提前告知参数负责人","解决的问题：\n1、确保审批过程中数据一致性\n",null,"骆明亮/80174856、傅银城/80296415","CN115689497A 一种轻量智能无代码流程审批方法、装置和终端 ","本申请提出了一种参数变更方案，自动生成申请单，由管理员审批及复核人员复核后，通过或驳回申请单，申请单通过后，申请人员点击发布，完成参数变更；而对比文件则公开了一种轻量智能无代码流程审批方法，以提高增删改接口效率，本申请与对比文件的区别在于：\n本申请关注流程审批中的参数变更问题，是为了确保审批过程中的数据一致性，与对比文件中所要解决的技术问题不同","建议结合具体的业务流程补充相关实施例以及附图","建议补充后申请发明专利","发明","潘远帆"]
[9,"零售应用研发中心/零售基础开发团队/基础开发六室(杭州)","一种高可用、高并发、可扩展的库存管理方案","本方案通过使用多Redis集群并且按需分配的方式，比单点Redis性能更好；请求不均衡时，对库存的扣减无影响；动态横向扩展时，无需重新均衡已切分的库存。","在现有的Redis单集群方案中，容易出现性能瓶颈以及Redis宕机后无法对外提供服务的问题。而使用多Redis集群均分库存的方式，虽然可以提高可扩展性和容错性，但也会导致横向扩展困难以及Redis宕机时大量库存丢失的问题。鉴于此，本方案采用多Redis集群，并且结合数据库，实现了库存的按需分配。",null,"赵 勇/80263681","CN116051003A 库存处理方法、装置、电子设备及存储介质 ","本申请提出了一种库存管理方案，通过使用多Redis集群并且按需分配的方式对库存进行管理，而对比文件则公开了有关接收业务端的资源创建需求；其中，资源创建需求中包括资源需求类型和需求量；根据资源创建需求、关系型数据库以及Redis数据库，确定目标资源提供者；其中，关系型数据库中存储有云计算管理平台中资源提供者的数据信息，数据信息包括资源类型和每个资源类型对应的资源总量；Redis数据库中存储有资源提供者中每个资源类型对应的资源剩余量；目标资源提供者为资源剩余量大于或等于需求量的资源提供者；向业务端返回目标资源提供者的相关内容，本申请与对比文件的区别在于：\n本申请专注于库存管理，通过使用多Redis集群并按需分配的方式来管理库存，主要目标是高效地处理库存变动，确保库存数据的实时性和准确性，并降低高并发情况下的系统压力，而对比文件关注的是云计算管理平台中的资源创建和分配，两者的应用场景以及所要解决的技术问题不同。","建议结合具体的应用场景补充业务流程的具体步骤","建议补充后申请发明专利","发明","潘远帆"]
[10,"零售应用研发中心/零售基础开发团队/基础开发六室(杭州)","一种基于LRU算法的高频数据缓存方案","本方案通过将键值压缩映射到固定长度的方式，将缓存数据散射到指定个数的队列中，并在队列中实现LRU算法。以实现在指定最大存储空间下的高频数据缓存。","依靠Redis的回收策略来淘汰数据的方法会导致数据存储量一直维持在Redis的最大内存容量，可能会影响Redis的性能，使用本方案对最大内存容量无依赖。",null,"陈恭哲/80331337","CN116594689A 缓存LRU算法实现方法、缓存控制器及缓存系统 ","本申请提出了一种数据缓存方法，具体通过将键值压缩映射到固定长度的方式，将缓存数据散射到指定个数的队列中，并在队列中实现LRU算法，以实现高频数据缓存，而对比文件则公开了有关缓存LRU算法实现方法，首先对多路组相连结构缓存中每一个缓存组设置对应的索引寄存器，索引寄存器中保存有用于表示对应缓存组的索引值，能够直接输出寄存器中的值作为缓存组的索引；然后，每个人索引寄存器都具有编号，且互不相同，同来表示索引寄存器对应的缓存数据的新旧程度，对缓存更新时，直接根据索引寄存器的编号，更新索引寄存器中保存的索引值，提升了缓存更新效率的内容，本申请与对比文件的区别在于：\n本申请专注于对缓存过程中最大内存容量无依赖，而不是对比文件中的提升缓存效率，两者的应用场景以及解决的技术问题不同。","建议补充将键值压缩映射到固定长度的方式的具体步骤以及逻辑示意图","建议补充后申请发明专利","发明","潘远帆"]
[11,"零售应用研发中心/零售基础开发团队/基础开发六室(杭州)","一种转异步防止客户记账并发的方案","主要发明点：\n将同一用户的异步请求分流到同一kafka 分区。在同一消费者实例中通过内存级别的并发控制，实现不同用户间并行、同一用户间串行记账 \n\n与现有的技术区别：\n同一钱包的多笔异步记账请求随机分发到不同实例，多实例间未做同一钱包的并发控制\n","解决的问题：\n在业务系统层面实现多钱包并行记账、单钱包串行记账，降低账务核心同一钱包的并发压力",null,"虞曾明/80322681","CN105447604A 一种账户处理方法及装置 ","本申请提出了一种防并发方法，将同一用户的异步请求分流到同一kafka 分区。在同一消费者实例中通过内存级别的并发控制，实现不同用户间并行、同一用户间串行记账 ，而对比文件则公开了一种账户处理方法，具体公开了将主账户拆分成了多个子账户，应用系统可以对该主账户的多个子账户并行执行记账操作的相关内容，本申请与对比文件的区别在于：\n1、本申请关注于防止同一用户的并发请求导致的记账冲突，确保记账的一致性和准确性，而对比文件侧重于提高记账操作的效率和吞吐量，通过账户拆分实现并行处理，对于同一用户并发请求的处理要求不那么严格；\n2、本申请还利用了Kafka的消息队列和分区机制，以及消费者实例的内存级并发控制来实现防并发。\n","建议结合客户记账的业务流程补充相关的具体实施例","建议补充后申请发明专利","发明","潘远帆"]
[12,"零售应用研发中心/零售基础开发团队/基础开发三室","一种分布式架构中路由支付关联交易的方案","主要发明点：\n以单点的路由标识查询为基础，解决绝大部分关联交易请求的路由处理，辅以大数据量关系数据库和全分库查询的兜底手段，解决远期或异常关联交易的路由处理，既保证关联交易的整体处理性能，也保证了少数场景下的处理高保障性\n与现有的技术区别：\n1-综合多种方式进行关联交易的路由处理，根据交易特征选择更具效率的路由选择策略，保证更好的处理性能和保障","解决问题：\n1-分布式架构下的关联交易路由处理",null,"张盛/01129530","CN114238411A 交易数据的处理方法、装置、电子设备和存储介质 ","本申请提出了一种路由支付关联交易方法，通过以单点的路由标识查询为基础，解决绝大部分关联交易请求的路由处理，辅以大数据量关系数据库和全分库查询的兜底手段，解决远期或异常关联交易的路由处理，而对比文件则公开了一种交易数据的处理方法，具体公开了接收当前交易的交易数据，确定当前交易为关联交易类型，获取交易数据中的交易索引标识，以向集群缓存层发送查询请求；接收集群缓存层发送的原交易信息，调用预设的路由决策模块，以确定原交易信息中包括目标集群标识，查询目标集群标识对应的目标集群信息，进而确定当前交易对应的交易业务处理程序，对当前交易进行处理的相关内容，本申请与对比文件的区别在于：\n本申请适用于适用于复杂且多变的关联交易场景，采用了以单点的路由标识查询为基础的路由处理机制，还辅以大数据量关系数据库和全分库查询作为兜底手段，而对比文件更侧重于利用集群缓存层进行快速查询和路由决策，两者所取得的技术效果不同","建议补充路由标识的具体设定过程，以及路由标识对应的映射关系","建议补充后申请发明专利","发明","潘远帆"]
[13,"零售应用研发中心/零售基础开发团队/基础开发三室","一种支付交易质量评价方案","主要发明点：\n基于层次分析法，从技术、业务、客户体验、客服工作负荷等方面制定准则，利用判断矩阵计算相关支付通道的交易质量评分，从而横向综合比较支付通道。\n与现有的技术区别：\n交易质量监控的指标比较单一或集中，无法全面评价交易质量","解决问题：\n1-定量分析支付交易质量，比较各类支付通道",null,"张盛/01129530","CN117273507A 需求侧分布式交易的综合评价方法、系统、介质和设备 ","本申请提出了一种支付交易质量评价方案，基于层次分析法，从技术、业务、客户体验、客服工作负荷等方面制定准则，利用判断矩阵计算相关支付通道的交易质量评分，而对比文件则公开了一种需求侧分布式交易的综合评价方法，具体公开了基于待评价系统的运行质量标准，确定了各指标相应的灰度区间和灰度评价值后，再结合各指标的值和综合权重对系统实现了准确的综合评价的相关内容，本申请与对比文件的区别在于：\n本申请用于交易质量评价的指标更多维化更全面，且采用判断矩阵计算相关支付通道的交易质量评分，而对比文件则侧重于需求侧分布式交易，两者的应用场景不同，其用于评价的指标体系也不同。\n","建议充分说明所有可用于评价交易质量的指标，还可以选择拓展判断矩阵根据交易日志自适应调节权重参数的技术内容","建议补充后申请发明专利","发明","潘远帆"]
[14,"零售应用研发中心/零售基础开发团队/基础开发五室(杭州)","一种解决关联交易非顺序到达的处理方案","主要发明点：\n以Visa/Master境外银行卡交易为基础，解决交易通讯中原交易和与之相关的冲正交易可能并非顺序到达的问题。","解决问题：\n1-解决关联交易非顺序到达的处理",null,"于涛/80274154、张迪/80274835"," CN112070497B 基于智能合约设计的关联交易重排方法、系统及介质 ","本申请提出了一种交易顺序处理的方法，以Visa/Master境外银行卡交易为基础，解决交易通讯中原交易和与之相关的冲正交易可能并非顺序到达的问题；而对比文件则公开了一种基于智能合约设计的关联交易重排方法，具体公开了交易的双向链表和交易结果映射表两种结构，其中通过交易的双向链表结构我们可以很清楚的知道关联交易中的前后置关系，从而达到交易重排的机制，使得关联交易的顺序得到保证的相关内容，本申请与对比文件的区别在于：\n本申请以Visa/Master境外银行卡交易为基础，两者的应用场景不同。","建议根据境外银行卡交易补充具体的流程步骤，并且尽量完善技术细节","建议补充后申请发明专利","发明","潘远帆"]
[15,"零售应用研发中心/网络安全开发团队/移动安全室","一种发现APP内容爬虫漏洞的方案","主要发明点：\n1、覆盖面广。适用于APP里的任意场景，发现各场景里潜在的内容爬虫漏洞风险；\n2、无侵入性。用户安装插件装置后，在使用APP过程中，后台自动开启漏洞识别；\n3、精确率高。后台对APP回传的API报文进行过滤、清洗和关联分析后，通过设置可配规则，实现自动化方式发现，精确率高。","问题：\n1、APP里的部分场景，其内容商业价值高，容易被黑客瞄准并采取自动化方式爬取，一旦被大量窃取会造成重大损失；\n2、针对超级APP，其场景众多，人工方式难以理清所有功能，容易造成风险遗漏；\n3、采取人工方式测试发现，耗时耗力。\n\n效果：\n1、提升场景覆盖率，全面发现APP里的内容爬虫类漏洞；\n2、提高漏洞发现效率，通过后台监控分析，自动化发现漏洞。",null,"邹航/80230515","CN109600272B 爬虫检测的方法及装置 ","本申请提出了一种爬虫漏洞检测的方法，通过本申请提供的插件可以全面发现APP里的内容爬虫类漏洞，而对比文件则公开了一种爬虫检测方法，具体公开了有关接收访问者对网站的访问请求后，获取所述访问请求中访问的目标链接；判断所述目标链接是否为预设陷阱链接；若所述目标链接为预设陷阱链接，则判断所述访问请求中是否携带有访问来源参考refer字段；根据判断的结果确定所述访问者是否为爬虫的内容。本申请与对比文件的区别在于：\n1、本申请适用于APP里的任意场景，发现各场景里潜在的内容爬虫漏洞风险；\n2、后台对APP回传的API报文进行过滤、清洗和关联分析后，通过设置可配规则，实现自动化方式发现，精确率高\n","建议补充本申请中爬虫检测插件的具体工作流程以及相应的步骤示意图","建议补充后申请发明专利","发明","潘远帆"]
[16,"零售应用研发中心/网络安全开发团队/移动安全室","一种监测Web应用内容安全的方案","主要发明点：\n1、通用性强。适用于任意Web应用，无需针对特定页面进行适配性开发。\n2、监测面全。涵盖了Web页面内容安全的多个方面，包括：页面私自变动、敏感信息泄露、出现违规内容、页面发生异常等。\n3、无侵入式。采取扩展插件方式，用户安装插件后，在访问页面过程中，通过后台方式异步监测，对用户无感。\n4、准实时监测。通过后台调用无头模式访问Web页面，无需人工介入，实现准实时性监控。","问题：\n1、Web应用内容安全问题频发，缺乏长效监控机制；\n2、缺少对内容安全方面的综合性监测，针对性监测。\n\n效果：\n1、全天候监测，及时发现页面内容安全问题，并进行预警，无需人工干预；\n2、页面内容安全问题一站式发现，避免重复建设。",null,"邹航/80230515"," CN106209863A 一种基于全站扫描的网站安全监测方法 ","本申请提供了一种WEB内容安全的监测方法，全天候监测，及时发现页面内容安全问题，并进行预警，并且能够实现页面内容安全问题一站式发现；而对比文件公开了一种基于全站扫描的网站安全监测方法，具体公开了从检测任务表中取出要检测的任务网站属性，包括url地址、调度频率；并利用DNS缓存技术，取出url对应的网络地址；如果状态存在异常，则进行报警；向服务器构造HTTP请求，并下载网页页面；对网页内容进行分析，对网页内容进行编码识别，利用中英文分词识别算法，对转码后的内容进行中文分词；并对暗链进行报警；对错别字进行报警。本申请与对比文件的区别在于：\n本申请强调全天候监测，旨在及时发现页面内容安全问题并进行预警，同时实现页面内容安全问题的一站式发现。也即本申请的监测方法相比对比文件更加全面和深入。\n","建议补充对Web应用内容安全进行监测的有关业务场景以及具体的流程步骤","建议补充后申请发明专利","发明","潘远帆"]
[17,"零售应用研发中心/信用卡开发团队/客卡开发一室","一种指标预测在弹性伸缩中的的实践方法","设计开发了一套指标预测模型并最终在弹性伸缩场景落地使用，提前预测应用CPU资源的使用情况进而指导后续资源的弹性伸缩操作。","1.更合理的弹性伸缩：以往开发申请实完全依赖于经验和感觉缺少依据，扩缩主要依赖人工操作，采用本方案后减少了人工进行资源扩缩的风险，\n2.系统资源提前准备：以往资源扩容都是交易量过来了被动的触发资源扩容操作，是一种事后性的风险规避策略。通过测整个周期的资源使用情况，提前完成资源的扩容，甚至整条链路的扩容，降低冲击性风险。",null,"陈曦/80274005","CN117453346A 资源转移量预测模型的确定方法和分布式系统的扩容方法 ","本申请提出了一种资源预测方法，设计开发了一套指标预测模型并最终在弹性伸缩场景落地使用，提前预测应用CPU资源的使用情况进而指导后续资源的弹性伸缩操作，而对比文件则公开了一种资源转移量预测模型的确定方法，具体公开了获取金融系统的历史资源转移数据；所述历史资源转移数据包括多个时间点的资源转移量；对所述历史资源转移数据进行序列划分处理，得到多个历史资源转移序列；基于所述多个历史资源转移序列，对预先构建的资源转移量预测模型进行训练，得到训练完成的资源转移量预测模型的相关内容。本申请与对比文件的区别在于：\n本申请预测的是应用CPU资源的使用情况，这需要收集和分析与应用运行相关的数据，而对比文件预测的是资源转移量，这通常涉及金融系统中不同部分或组件之间的资源流动数据，两者所要解决的技术问题不同，且对应的技术方案也不同\n","建议补充模型建立的具体过程，并结合实际业务流程补充具体的实施例","建议补充后申请发明专利","发明","潘远帆"]
[18,"零售应用研发中心/信用卡开发团队/信用卡客户经营开发四室/风控一组","低代码实现指标计算方案","提供一种低代码的形式完成指标开发， 支持kafka、SFTP、HIVE、mysql、Oracle、ES等数据源的指标自动化完成指标计算，能有效提升指标开发效能","以低代码的形式完成指标配置，从而实现指标计算自动化，指标查询通用化，有效提升指标开发的效率，对比传统模式的指标开发，效能提升4倍",null,"林文敏/80375227","CN114358596A 指标计算方法及装置 ","本申请提出了一种指标计算方法，提供一种低代码的形式完成指标开发， 支持kafka、SFTP、HIVE、mysql、Oracle、ES等数据源的指标自动化完成指标计算，而对比文件则公开了一种指标计算方法，具体公开了存储电子表格软件生成的多个目标指标组各自对应的可配置文件；其中，可配置文件表示多个原始指标各自的值确定对应的目标指标组中各业务指标各自的值的计算规则；确定指标计算请求；其中，指标计算请求携带目标指标组或目标指标组的标识；确定目标指标组匹配的多个原始指标各自的值；调用数据库引擎基于目标指标组匹配的可配置文件指示的计算规则对匹配的多个原始指标各自的值进行计算，确定目标指标组中各业务指标各自的值。本申请与对比文件的区别在于：\n本申请支持kafka、SFTP、HIVE、mysql、Oracle、ES等数据源，其通用性较强\n","建议结合具体的业务场景对指标计算的流程细节进行补充","建议补充后申请发明专利","发明","潘远帆"]
[19,"零售应用研发中心/信用卡开发团队/信用卡客户经营开发四室/风控二组","高易用性、高文件完成度的SFTP下载工具","提供一种具备易用性、可移植、高文件完整性的SFTP下载工具","通过对工具的封装，把功能全部集成在工具内，无需引入其他依赖，可快速移植部署在多台虚机；极简参数，易用性高；通过对远程文件及本地文件的大小、记录数、hash值进行比对，不一致时可自动重新下载，确保下载完整性",null,"何蓓杰/80249546","CN116614494A 一种文件下载转发智能系统及方法 ","本申请提出了一种SFTP下载工具，通过对远程文件及本地文件的大小、记录数、hash值进行比对，不一致时可自动重新下载，确保下载完整性，而对比文件则公开了一种文件下载转发方法，具体公开了通过对文件下载模块定时遍历发送方指定文件夹获取文件列表信息，将文件存入本地，避免重复取文件，并记录入库；分布式定时文件处理模块对本地文件的大小与对应数据库表记录进行一致性校验，确认文件是否已经接收完毕，或者是否需要重新下载，形成特征参数记录入库的相关内容，本申请与对比文件的区别在于：\n本申请提出了一种SFTP下载工具，专门针对SFTP协议下的文件下载场景，确保SFTP下载的文件完整性，通过一系列比对机制实现这一目标。两者的技术问题与取得的技术效果均不同。\n","建议从易用性、可移植、高文件完整性三个方面详细说明技术细节，并补充对应的具体实施例","建议补充后申请发明专利","发明","潘远帆"]
[20,"零售应用研发中心/信用卡开发团队/信用卡客户经营开发四室/风控二组","低复杂度高可用的数据保障方案","利用Kafka进行数据传递，便于数据双写：将数据存储到Oracle再同步到Hive及通过Flink直接传输到Hive表中，这等同于为系统提供了两份数据源，在使用时，利用Hadoop的大数据处理能力，对两份数据进行合并及去重，只需核对最终结果与源系统是否一致即可，降低过程数据的校验成本。","降低重要场景下，单一数据源单节点故障的风险，并且以低复杂度的形式解决多备数据源场景下的数据源切换、数据重复、数据完整性的问题",null,"何蓓杰/80249546","CN115329016B 一种金融资产交易数据处理方法、系统及可读介质 ","本申请提出了一种数据保障方法，将数据存储到Oracle再同步到Hive及通过Flink直接传输到Hive表中，这等同于为系统提供了两份数据源，在使用时，利用Hadoop的大数据处理能力，对两份数据进行合并及去重，只需核对最终结果与源系统是否一致即可，而对比文件则公开了一种金融资产交易数据处理方法，具体公开了获取金融资产交易数据；离线交易数据以及日初对应在途交易数据，从交易系统的备库ORACLE同步数据到缓存层，再到关系型数据库中,将离线交易数据以及日初对应在途交易数据进行贴源层处理和数据细节层处理；对于日初对应在途交易数据，批处理日初对应在途交易数据的基础数据到REDIS缓存中；实时基础数据流、实时业务数据流的实时变更采用CDC消息变更，通过消息中间件KAFKA至FLINK平台进行相应操作，并将业务标准转化后的接口数据根据不同业务转发到消息中间件KAFKA对应的主题下的相关内容，本申请与对比文件的区别在于：\n本申请将数据存储到Oracle再同步到Hive及通过Flink直接传输到Hive表中，以低复杂度的形式解决多备数据源场景下的数据源切换、数据重复、数据完整性的问题，而对比文件则关注数据计算性能，并没有考虑单一数据源单节点故障的风险。\n","建议结合具体的业务流程补充相关实施例以及附图","建议补充后申请发明专利","发明","潘远帆"]
[21,"零售应用研发中心/网络安全开发团队/移动安全室","基于多模态融合的交易特征衍生方案","1. 对交易序列数据的多通道表征：通过正弦位置编码以及多类型核函数对历史交易序列时间特征进行多通道嵌入\n2. 对交易序列特征的深层挖掘：采用层归一化对历史交易序列数值特征无量纲化处理，并结合注意力机制编码历史交易特征\n3. 交易序列和基础特征数据的多模态融合和衍生：基于低秩模态融合计算表格型交易特征与历史交易特征的交互，实现不同模态交易特征的衍生","解决的技术问题：\n\n1. 基于专家知识的基础特征无法完全覆盖交易深层特点，需要交易序列等多模态数据补充；\n2. 交易序列中交易行为模式复杂多变难以捕捉；\n2. 基于特征间排列组合衍生方式效率低下且无法挖掘隐式衍生特征，基础特征和交易序列等多模态数据难以统一建模；\n\n\n效果：\n1. 通过多通道时间特征编码以及基于注意力机制的历史交易序列编码，建模历史交易行为对当前交易行为影响的周期性与时变性。\n2. 通过低秩模态融合能够自动挖掘表格型交易特征与序列交易特征间的深层衍生特征，从更高维融合基础特征和交易序列等多模态数据，同时降低特征间交互计算的复杂度。",null,"陈昊冉/80362878","CN115510995A 用户留存预测方法及装置 ","本申请提出了一种交易特征衍生方法，通过多通道时间特征编码以及基于注意力机制的历史交易序列编码，建模历史交易行为对当前交易行为影响的周期性与时变性，并过低秩模态融合能够自动挖掘表格型交易特征与序列交易特征间的深层衍生特征，从更高维融合基础特征和交易序列等多模态数据，而对比文件则公开了有关根据用户数据生成用户登录行为序列、用户交易行为序列和衍生特征数据；所述衍生特征数据包括根据用户登录数据确定的用户特征数据的内容。本申请与对比文件的区别在于：\n1、本申请主要关注于交易特征衍生方法，特别是通过多通道时间特征编码和基于注意力机制的历史交易序列编码来建模历史交易行为对当前交易行为的影响。其技术重点在于通过周期性与时变性的建模以及低秩模态融合来挖掘深层衍生特征，适用于交易行为的深度分析和预测。对比文件则对用户数据进行获取与处理，包括用户个人数据、登录数据和交易数据，并利用这些数据生成行为序列和衍生特征数据。\n2、本申请应用于反诈场景，与对比文件的应用场景不同","建议结合反诈场景对流程步骤进行补充，也可以考虑补充在获取到模型输出结果后进行相应的告警的相关技术内容","建议补充后申请发明专利","发明","潘远帆"]

{"sheet":"3.18-3.22","index":4,"n_rows":18,"n_cols":13,"rows_kept":18,"cut":false,"hidden":false,"merged":[[0,0,0,6],[0,7,0,12]]}
["发明人填写",{"$nulls":6},"代理人填写"]
["序号","中心/团队/室","专利名称（暂定名称）","主要发明点/方案简述及与现有技术的区别","解决的技术问题及预计达到效果","所属技术领域","发明人","检索的最接近对比文件","检索分析\n（与对比文件相比的区别点）","待发明人补充内容\n（挖掘现场代理人提出需要发明人补充的内容）","检索结果\n如：补充内容后建议申请XX专利\n建议拆分专利（说明拆分内容）\n不建议申请，说明原因","建议申请类型","检索人"]
[1,"零售应用研发中心/零售客户经营开发团队/零售基础客群经营开发室(成都)","灰度环境下的流量覆盖验证方案","主要发明点：\n1、提供了灰度环境切换正式环境的流量覆盖报表，包括：变动方法及api流量覆盖率及详情等\n2、基于多种维度排除代码中的干扰项，包括：僵尸方法及接口等\n与现有技术的区别：\n1.灰度环境的整体验证从之前的业务口头反馈，具象为具体的验证指标数据\n2.之前灰度环境切换正式判断时，根据开发的经验和业务的反馈，提高为具体的数据指标，辅助判别是否达到切换标准","解决的问题：\n1.灰度环境发布后，业务和研发人员未在灰度时间窗口进行功能验证，或仅验证了主要业务功能、流程，未覆盖到所有功能和逻辑分支，以至问题在切流至正式环境后暴露\n2.正式环境投产时，未将灰度环境的验证结果作为能否投产的准则，即灰度验证不全、甚至功能有异常时，研发人员仍然可以无视问题进行正式环境发布。\n预计达到的效果：\n1.零侵入实现变更代码链路分析\n2.提供具体的灰度环境流量覆盖指标数据报告，并以此作为切换正式环境的依据",null,"张钊/80245343 \n邓全波/80306348","CN116931993A 灰度发布方法、装置、设备及存储介质 ","本申请公开了一种流量覆盖验证方法，主要通过提供了灰度环境切换正式环境的流量覆盖报表，并基于多种维度排除代码中的干扰项，实现零侵入实现变更代码链路分析并提供具体的灰度环境流量覆盖指标数据报告为切换正式环境的依据；而对比文件则公开了一种灰度发布方法：在用户流量进入生产环境或灰度环境时，对公共数据库进行读写，得到参考公共数据库；在用户流量进入生产环境时，对生产环境数据库和灰度环境数据库进行生产读写，更新生产环境数据库和或灰度环境数据库；在用户流量进入灰度环境时，对灰度环境数据库和生产环境数据库进行灰度读写，得到更新生产环境数据库和或灰度环境数据库；获取灰度环境的验证结果，对目标数据库进行调整，完成灰度发布的方案。上述两者的区别在于：\n所解决的技术问题不同，本申请提供具体的灰度环境流量覆盖指标数据报告，用于验证灰度环境的流量覆盖情况，为切换正式环境提供依据，而对比文件则侧重于灰度发布过程中数据库的读写操作和调整。","建议针对排除代码干扰项的每个维度进行举例说明","补充内容后建议申请发明专利","发明","潘远帆"]
[2,"零售应用研发中心/零售信贷开发团队/个人信贷三室(杭州)","基于数据流处理的多场景、大数据量数据对接方法","主要发明点：\n1、不同场景的数据仅新增配置即可完成数据对接与标准化，对接成本低\n2、对接海量数据时进行多次削峰操作保证数据无损接收\n3、关键节点具有数据保障机制及数据消费幂等机制，容错率高\n\n与现有技术的区别：\n现有技术在对接不同上游时需要针对每个上游开发单独的接口。对接大量数据时容易出现数据处理过慢导致数据丢失的情况","解决的问题：\n1、上游数据来源众多，数据格式各不相同，每次对接新来源重新开发工作量太大且不稳定。\n2、对接海量数据容易出现应用压力大、数据丢失等情况\n预计达到的效果：\n1、新对接数据来源时，通过简单的配置即可完成数据接收、数据清洗及数据标准化，对接成本低，稳定安全\n2、通过场景区分数据对接渠道，不同场景之间数据互不影响，同时进行多次削峰处理，保证各数据处理节点处于低压力状态，配合数据保障机制及幂等机制，确保数据正常无损落地",null,"邵帅/80291467","CN114298003A 一种标准化文件输出方法和装置 ","本申请公开了一种数据对接方法，具体通过简单的场景配置区分不同的数据对接渠道、数据削峰处理以及数据保障机制、幂等机制确保数据无损对接，而对比文件则公开了有关根据各个渠道模板所配置的文件模型，调用数据库中对应的数据写入所述文件模型，生成标准化文件；检测和处理异常的标准化文件的内容；上述两者的区别在于：本申请侧重于数据对接的稳定性和无损性；而对比文件则侧重于数据的格式化和标准化处理。","建议根据具体的业务流程补充实施例","补充内容后建议申请发明专利","发明","潘远帆"]
[3,"零售应用研发中心/零售信贷开发团队/个人信贷二室(杭州)","一种数据库抽数丢数的解决方法","主要发明点：\n1、通过“游标哨兵”机制解决抽数时定位游标漂移导致的丢数问题；\n2、通过“游标回退”机制解决抽数时长短事务错配导致的丢数问题；\n\n与现有技术的区别：\n现有技术在数据库抽数出现定位游标漂移、长短事务错配时，会出现丢数问题","解决的问题：\n在数据库抽数出现定位游标漂移、长短事务错配时，出现的丢数问题\n\n预计达到的效果：\n在数据库抽数出现定位游标漂移、长短事务错配时，抽数功能任然正常",null,"朱雷坚/80274917","CN117056126A Postgresql数据库的数据抽取方法及装置 ","本申请通过设置抽取提前量，通过“游标哨兵”机制解决抽数时定位游标漂移导致的丢数问题，通过“游标回退”机制解决抽数时长短事务错配导致的丢数问题，而对比文件则公开了有关基于Postgresql存储原理和表数据文件结构，检测表数据文件是否损坏和存有坏块，再通过对比计算，自动识别出各类数据及将二进制数据格式化为友好的数据格式，抽取到文件，减少数据丢失的可能性的内容；上述两者的区别在于：\n对比文件没有公开有关“游标哨兵”机制和“游标回退”机制的内容，也即本申请解决数据丢失的技术方案并未被公开。\n","建议将“游标哨兵”机制和“游标回退”机制从计算机程序步骤的层面详细解释","补充内容后建议申请发明专利","发明","潘远帆"]
[4,"零售应用研发中心/零售信贷开发团队/个人信贷三室(杭州)","流量无损的数据库迁移方案","主要发明点：\n1、基于自研插件+DataX框架实现了MongoDB与关系型数据库的配置化迁移(关系型数据库之间的迁移由框架自带的支持能力)\n2、使用FLINK SQL对源表及目标表的迁移数据进行流式比对，实现数据核对功能，确保数据迁移的正确性\n3、设计了缓存回放策略和机制，保障业务流量无损\n\n与现有技术的区别：\n1、现有技术在迁移数据库时，需要针对不同业务场景写迁移逻辑，数据高效、无损迁移无法保障；\n2、现有技术在迁移时，业务流量可能有损失；\n3、现有技术在MongoDB迁移关系型数据库时经验空白","解决的问题：\n1、数据库迁移无标准化方案\n2、人员开发能力的差异性，会导致项目开发耗时、数据迁移正确性、投产流程准确性无法保障，增加项目投产风险\n\n预计达到的效果：\n实现数据库迁移过程的标准化，达到了开发人员开箱即用的效果，保证迁移过程中业务流量无损",null,"王琛浩/80272476","CN110019140A 数据迁移方法、装置、设备以及计算机可读存储介质 ","本申请公开了自研插件+DataX框架、使用FLINK SQL对源表及目标表的迁移数据进行流式比对、缓存回放策略和机制，而对比文件则公开了有关将所述快照中的第一数据全量迁移到所述目标数据表中；向所述源数据节点发送增量日志获取指令，接收所述源数据节点返回的增量日志；确定所述增量日志中的属于第二数据的子日志；向所述目标数据节点发送日志幂等回放指令的内容，上述两者的区别在于：本申请提出了自研插件+DataX框架，并设计了缓存回放策略和机制。","建议根据实际业务需求补充具体的业务流程图","补充内容后建议申请发明专利","发明","潘远帆"]
[5,"零售应用研发中心/零售信贷开发团队/个人信贷五室(深圳)","个贷日期切换方案","主要发明点：\n1、核心账务系统的记账日期切换后及时切换个贷日期\n2、日期切换在分库间独立，出现日期切换失败会及时电话告警，不影响到其他分库\n3、日期切换失败、日期查询链路故障或日期数据失准等情况提供降级方案输出核心账务系统的记账日期，保证个贷日期查询功能正常、正确运行\n\n与现有技术的区别：\n1、通过任务调度平台执行日期切换代替定时任务，监控告警功能完善，可以实时观察任务执行情况。\n2、多分库保存、维护个贷日期，防止过分依赖单库\n3、提供更完善的降级方案，保证日期数据准确，不影响日终批次执行","解决的问题：\n1、解决了个贷日期功能过度依赖单库应用的问题，通过多分库实现高保障\n2、完善个贷日期切换监控预警功能\n3、日期切换故障及时感知，保障日终批次准确执行\n\n预计达到的效果：\n1、日期切换过程中出现故障，及时感知并通知负责人，并阻断日终批次执行\n2、基于多分库的优势，有部分分库出现故障时上游应用也能正常查询到个贷日期",null,"李梓阳/80308390","CN115760406A 交易核算处理方法、装置、核算服务器及存储介质 ","本申请公开了多分库切换个贷日期的方法，而对比文件则公开了有关针对不同交易类型的交易数据确定不同的记账方式的内容，两者的区别在于：\n本申请通过任务调度平台执行日期切换代替定时任务，用多分库来维护个贷日期，且提供了降级方案，技术方案并未被对比文件公开，且应用场景也不同。","建议结合具体的业务场景补充本申请的技术效果","补充内容后建议申请发明专利","发明","潘远帆"]
[6,"零售应用研发中心/零售信贷开发团队/个人信贷五室(深圳)","个贷借贷卡日终扣划转贷保障方案","主要发明点：\n1、根据借贷卡协议对活期账户进行扣划失败时通过发放贷款保障透支额度回收\n\n与现有技术的区别：\n1、借贷卡消费收回不再严格按活期扣划/转贷单一方案，活期扣划不足可以改为使用转贷方案","解决的问题：\n1、解决优先借贷卡协议优先扣活期资金但扣划失败时透支额度无法回收问题\n\n预计达到的效果：\n1、保障60几万消费户其小额消费都能正常收回",null,"李梓阳/80308390","CN117455409A 基于征信信息为金融机构续贷、转贷提供征信服务的方法、装置、设备及存储介质 ","本申请公开了一种根据借贷卡协议对活期账户进行扣划失败后通过发放贷款保障透支额度回收的方案，而对比文件则公开了有关简化操作流程，降低业务操作繁琐程序的基于征信信息为金融机构续贷、转贷提供征信服务的方法的内容，上述两者的区别在于：本申请聚焦于透支额度回收的保障机制，而对比文件则侧重于通过征信服务优化贷款业务流程。","建议结合计算机数据交互的步骤对方案进行补充，可以针对实际的转贷过程中如何保持数据一致性对技术进行补充","补充内容后建议申请发明专利","发明","潘远帆"]
[7,"零售应用研发中心/投资理财开发团队/投资业务七室(成都)","一种自研双数据源实时读写的数据库迁移方案","1.双数据源数据实时一致，在数据库迁移过程中，若流量在目标库上验证不通过，则可快速将流量回切到源库，而无需将目标库增量的流量数据回迁到源库。\n2.双库数据实时一致，且冗余备份，无论流量分发到哪个库，都可以独立支撑原应用所有复杂查询场景。\n3.使用SQL维度来切流，使用主库SQL执行结果来支撑上层业务，流量切换过程无需再关注业务数据是否含有分库标识，该方案能支持的数据库迁移场景更加广阔。","双数据源实时读写的数据库迁移方案，通过应用同时持有源库和目标库数据源，一条SQL会同时在源库和目标库上执行，并通过监控手段，实时比对双库SQL的执行结果，保证双库数据实时一致。这样，我们有以下几个创新点：\n1.系统改造点仅控制在应用的持久层，影响面小，风险降低，无需系统业务逻辑层做代码适配改造。\n2.双库数据实时一致且冗余备份，无需再额外实现双库数据增量同步功能，对于流量回退和聚合查询功能，无需额外做功能实现。\n3.无需关注业务数据是否有分库因子，支持SQL级的流量热切换，对数据库迁移系统具备普适性。",null,"席刚涛/80252396","CN117573492A 一种数据库迁移场景下的应用性能检测方法及装置 ","本申请与对比文件的区别在于：本申请与对比文件的区别主要在于数据一致性和流量控制机制。本申请实现双数据源数据实时一致，并支持快速流量回切，无需回迁数据；同时，双库均可独立支撑复杂查询。而对比文件则聚焦于数据库迁移场景下的应用性能检测，通过采集和分析SQL执行效率、负载信息等方式，模拟源库负载并回放业务核心SQL，以提高应用性能检测的真实性和对比的有效性。综上所述，本申请着重于数据一致性和流量管理，而对比文件则关注应用性能检测。","建议结合实际的应用场景补充业务流程步骤示意图","补充内容后建议申请发明专利","发明","潘远帆"]
[8,"零售应用研发中心/投资理财开发团队/投资业务七室(成都)","一种基于客户白名单额度的理财产品购买额度控制方案","主要发明点：\n1.白名单标签：为实现多个客户共享额度资源，设置白名单产品标签及白名单客户标签。具有白名单标签的产品可分配白名额度池，白名单客户在购买白名单产品时，可优先占用白名单额度，提升抢购体验。\n\n2.额度实时划拨：为实现细粒度额度控制，便于总分行销售人员对额度实时定向分配，方案提供了基于机构树及客户内部预留的额度管理方案。\n总行可下划额度给分行机构，由分行机构根据销售策略实时进行额度分配，将额度分配给公开额度池、内部预留额度池、白名单额度池，同时支持额度划拨至下级机构或下级机构指定客户。\n\n3.额度抢占方案：提供一种基于最小权限的智能额度占用方式，客户发生购买时，通过锁对应机构额度记录，实现额度占用。设置额度占用顺序，首先占用内部预留额度，再按照客户所在机构树占用客户所在机构及其上级机构的额度，实现可用额度的最大使用。额度抢占成功后，登记额度占用信息，并通过异步方式同步交易状态，当交易失败时及时更新额度占用信息状态，完成占用额度回收。\n\n与现有技术的区别：\n1.现有额度分配机制大多是将产品额度预留给指定客户，未做到指定客群共享机构白名单资源池。\n2.现有额度管理机制未实现多种维度额度管理模式，实时监控额度抢占情况进行额度分配。","解决的技术问题：\n1.解决客户抢购产品时，实现额度动态配置及额度最大化占用。\n预期达到的效果：\n1.根据客户白名单标签及产品白名单标签，为白名单客群分配白名单额度，提升白名单客户抢购体验。\n2.营销人员实时掌握所在机构额度使用情况，按照各自营销策略进行额度池动态分配，最大程度完成额度使用。\n3.通过额度抢占机制完成最大化额度占用，异步处理机制能适应公司客户抢购并发。",null,"雷入一/80296425","CN109102386A 基于大数据的风险控制方法及装置 ","本申请与对比文件的区别在于： 本申请则主要聚焦于额度管理和额度抢占的方案。首先，通过设立白名单标签，实现了多个客户共享额度资源的功能，提升了客户的抢购体验。其次，通过额度实时划拨机制，实现了细粒度的额度控制，使总分行销售人员能够实时定向分配额度，增强了销售策略的灵活性和实时性。最后，通过额度抢占方案，提供了一种基于最小权限的智能额度占用方式，确保了可用额度的最大使用，并在交易失败时及时回收占用额度，确保了额度管理的有效性和准确性。而对比文件主要关注基于大数据的风险控制方法及装置，具体涉及到接收白名单用户的贷款申请，获取其财务数据，并通过预设风险模型分析风险承受能力，进而决定是否发放贷款以及贷款的额度。\n综上所述，对比文件主要关注贷款申请的风险控制及额度确定，而本申请则更侧重于额度资源的共享、实时划拨及智能抢占管理。两者在技术方案上存在差异，各自解决了不同的技术问题。","建议系统内部数据交互的层面补充具体的实施例以及流程图","补充内容后建议申请发明专利","发明","潘远帆"]
[9,"零售应用研发中心/投资理财开发团队/投资业务七室（成都）","一种支持私募理财产品提前起息的理财文件交互方案","主要发明点：\n1、业务人员在上架私募产品时可根据私募理财产品目标客户的实际资金情况灵活选择当前私募产品的文件交互模式；\n2、私募产品T+1日起息文件交互模式支持提前将客户的申请发送给管理人入库，24小时冷静期结束后程序自动处理发送冷静期期间客户的撤单数据，管理人接收撤单数据后实时处理客户申请和撤单数据进行提前确认，并将资金进行投资提前开始起息；\n3、支持按文件尾号进行批次清算，将私募T+1产品和其他产品处理批次进行拆分，放在不同时段进行清算处理，并且能够支持灵活的清算批次处理，支持拆分成更多批次。\n\n与现有技术的区别：\n1、非提前起息的私募产品，在开放期结束之后的下一个工作日发送申请，管理人在T+1收到申请，在T+2进行确认。提前起息的私募产品，在开放期结束当天发送申请，T+1日发送客户撤单数据，管理人总和T日申请和T+1日撤单数据即可进行交易确认，做到提前一个工作日完成业务全流程，提前起息。\n2、接收文件时支持处理多个批次文件，普通产品没有冷静期限制，在确认日上午即可进行确认，作为一个批次。私募T+1产品由于冷静期24小时限制，一般在下午才可确认，需要单独一批次。支持在文件上增加批次号，进行多个批次逐个进行清算处理，并且支持灵活的增加更多批次的文件交互，管理人可以根据不同产品的清算速度灵活安排产品所属批次。","解决的技术问题：\n1、私募产品只能在T+1日收市之后发送申请，T+2进行确认。\n2、每家管理人的文件只能交互一个批次。\n\n预期达到的效果：\n1、客户购买私募产品可以在T+1日进行确认，提前一天开始计算收益\n2、销售端支持灵活的批次清算处理，管理人可以根据自身产品的处理进度，灵活安排产品处理时间，不必等到所有产品都处理完成才能给客户进行交易确认",null,"柏港/80325741","CN110930252A 一种数字货币交易数据处理方法、装置及系统 ","本申请主要关注私募产品的文件交互模式与清算处理。业务人员在上架私募产品时，可以根据目标客户的实际资金情况灵活选择文件交互模式。特别是，它提到了T+1日起息文件交互模式，允许提前发送客户申请给管理人，并在冷静期结束后自动处理撤单数据，实现资金的提前起息。此外，本申请还支持按文件尾号进行批次清算，能够将私募T+1产品与其他产品的处理批次拆分，并支持灵活的清算批次处理。相比之下，对比文件则专注于数字货币交易数据的处理。它涉及确定待交易币对的可能成交价，判断该成交价是否在基于最新成交价确定的价格波动区间内。如果不在，会启动冷静期，并在冷静期结束后调整计价值，重新确定价格波动区间，并重复此过程，直到找到位于价格波动区间内的可能成交价，进而撮合交易。\n综上所述，两者的区别在于：本申请主要关注的是私募产品的文件交互和清算处理，而对比文件则是关于数字货币交易数据的处理与价格稳定机制，也即两者的应用场景不同。","建议结合计算机数据交互的步骤对方案进行补充，以避免出现客体问题","补充内容后建议申请发明专利","发明","潘远帆"]
[10,"零售应用研发中心/信用卡开发团队/信用卡客卡开发三室(杭州)","一种高性能易复用的数据质量保障技术","主要发明点：\n1）将数据校验逻辑抽象为规则表达式，并持久化存储到数据库，实现逻辑复用。\n2）校验逻辑支持图形化配置，使用简单，易用性强。\n3）逻辑校验采用应用本地化缓存，保证了数据校验的高性能和高吞吐量，同时也降低了数据库访问负载。\n4）实现了分布式环境下各应用校验逻辑的实时刷新，能够大幅降低生产环境逻辑变更成本。\n\n方案简述：\n将硬编码的数据校验逻辑抽象为规则表达式，并基于Aviator表达式求值引擎实现校验逻辑的实时解析和执行；通过Redis发布订阅模式实现分布式应用校验逻辑的实时更新；支持图形化配置方式，快捷生成校验逻辑表达式，并提供丰富的自定义Aviator校验函数库，提高工具易用性；实现了一款支持校验逻辑持久化、多实例实时刷新、校验逻辑可复用、低侵入高性能的数据质量保障工具。\n","解决技术问题：\n1、校验逻辑固化，无法实时修改的问题；\n2、校验逻辑分散，无法重复利用的问题；\n3、校验逻辑实现复杂，易用性差的问题；\n\n效果：\n1.数据校验逻辑抽象成规则表达式，持久化存储到数据库，统一管理，方便复用。\n2.校验逻辑支持图形化配置，使用简单，易用性强。\n3.校验逻辑采用本地化缓存，数据校验性能高。\n4.数据校验逻辑支持实时更新。",null,"刘振友/80310931","CN114238381A 数据质量校验方法、设备及计算机可读存储介质 ","对比文件中数据校验逻辑是通过封装好的规则表达式进行实现的，并配置出适配于数据表字段的描述信息的规则信息定义表。也即对比文件中的校验逻辑主要是基于表结构的描述信息来生成相应的规则表达式。而本申请则进一步将数据校验逻辑抽象为规则表达式，并持久化存储到数据库中，实现逻辑复用，易于管理和复用。\n综上所述，本申请与对比文件在数据质量校验方法上，虽然都采用了规则表达式的方式来实现校验逻辑，但在逻辑抽象、存储、图形化配置、性能优化、分布式环境支持以及工具功能扩展等方面存在明显的区别。两者的具体实现方法不同。","建议根据实际业务需求补充具体的业务流程图","补充内容后建议申请发明专利","发明","潘远帆"]
[11,"零售应用研发中心/网络应用开发团队/移动银行二室(杭州)","一种面向分布式微服务健康管理的自动摘机方案","主要发明点：\n1）通过对1个完整服务单元（包含多个微服务应用）下所有微服务实时健康探测，以应对当某个微服务出现故障时，能将整个服务单元摘机掉。\n方案描述：\n数据服务：同步互联网资源数据，维护摘机决策配置数据；\n探测服务：kafka消费探测数据； \n决策服务：整合探测数据和摘机决策配置，判断当前机器是否需要摘机；\n摘机服务：利用UCD接口实现自动化摘机操作。","解决技术问题：\n1、F5心跳检测受限：探测程序负责监控每个微服务的状态，但受限于F5只能探测一个微服务（GLogin），无法支持遍历所有微服务探测的现状，因此当生产上某台服务器，出现某个非GLogin微服务发生故障时，F5无法做到摘机处理，易造成微服务不可用问题。\n2、微服务应用池故障：手机银行面向互联网24小时开放服务，因外部依赖、IIS服务器等原因导致微服务故障或在凌晨时间重启失败时，开发人员无法及时知晓，无法准确定位微服务故障原因，从而存在用户操作易受影响，微服务不可用问题，导致客户投诉和生产事故。\n3、人工介入问题：在发现某一微服务不可用时，运维人员去机房执行人工摘机操作，从而存在人工操作上的运维风险。\n效果：",null,"赵佳力80234548","CN111078688A 微服务健康检查的方法、存储介质 ","对比文件主要关注的是如何通过特定的数据结构（treeset结构的new表）和排序方式（按key值升序排序）来优化微服务心跳包的接收和处理过程，以减少遍历次数、提高检查效率和节约资源。该方法的核心在于对单个微服务的健康状态进行实时监控，并通过心跳包的接收和超时判断来维护一个有序的健康状态列表。相比之下，本申请的焦点在于对整个服务单元（包含多个微服务应用）的健康状态进行实时探测和整体管理。本申请提出了一个包含多个服务组件（数据服务、探测服务、决策服务、摘机服务）的完整解决方案，这些服务组件协同工作以实现对服务单元的整体健康监控和自动化摘机操作。\n综上上述，两者的区别在于：对比文件主要关注单个微服务的健康状态检查和优化，而本申请则侧重于对整个服务单元的健康状态进行实时监控和自动化管理，包括健康探测、决策和摘机操作等多个环节。","建议根据实际的业务流程步骤补充具体的实施例","补充内容后建议申请发明专利","发明","潘远帆"]
[12,"零售应用研发中心/零售客户经营开发团队/零售基础客群经营开发室(成都)","研发工具箱","1. 提供研发工具集成门户入口，整合行内工具资源统一管控，提升研发效能，快速实现需求。\n2. 提供工具的上传、共享入口，助力全行工具体系建设，共建共享。\n3. 无缝集成行外第三方工具与行内自研工具,使用简便，功能强大。\n4. 多种类工具支持，打通研发过程中的工具链孤岛，覆盖研发全流程。                   5.支持工具快速自主管理","问题:   \n1、行内开发教程以及开发工具众多，但缺少统一入口； \n2、缺乏工具共享平台，行内个人自研工具难以推广；\n3、难以快速检索到开发工具；           4、工具管理、维护困难              效果：\n1、一站式研发工具平台，整合行内工具资源，降低了使用壁垒；\n2、包含行内行外众多种类工具，功能强大，使用便捷；\n3、便于工具维护、管理，保证工具的规范性、安全性、可靠性；\n4、助力开发人员低成本、高效率地使用工具，使开发人员能专注于业务开发。",null,"王洋/80311159"," CN117422429A 一种基于互联网的研发机构协同服务平台 ","对比文件的服务范围较为广泛，涵盖了科研服务、数字化运营、网络化协同创新等多个方面，旨在实现整个研发机构的全面协同。\n本申请则更专注于研发工具链的整合与管理，通过打通研发过程中的工具链孤岛，覆盖研发全流程，从而提升研发效率和质量。\n总而言之，对比文件与本申请在数字化管理技术领域虽然有所交集，但在平台定位、功能重点、工具集成与管理以及服务范围等方面存在明显的差异，也即两者的应用场景不同。","建议根据不同的业务功能入口进行功能聚合的角度进行技术内容的扩展","补充内容后建议申请发明专利","发明","潘远帆"]
[13,"零售应用研发中心/信用卡开发团队/信用卡客卡开发三室(杭州)","（OverMock）自研微服务mock增强工具","主要发明点：\n1)实现异步模式的微服务模拟\n2)提供capture录制模式、modify修改模式、spy模拟穿透模式、diff差异比对模式功能的全功能可视化工具\n3)提供modify修改模式的动态修改基础插件\n\n方案简述：\nOverMock服务端主要支持四种模式：capture、modify、spy、diff，这四种模式能够灵活一键切换。ücapture录制模式：作为代理服务器实现无侵拦截并记录真实服务之间的请求和响应，减少人工造数的成本。\nmodify修改模式：基于python插件实现对响应报文动态修改，OverMock提供了常用的字段映射、动态时间戳等基础插件，也支持自定义扩展插件。可以动态地根据不同的参数获取不同的数据，比如可以去动态获取当前系统的时间返回，而不是返回固定的时间。\nspy模拟穿透模式：根据请求和匹配器来判断使用桩数据还是真实数据。\ndiff差异比对模式：比对不同接口返回的差异，可以用来发现外部服务发生的变化。\n此外，目前了解到现有的虚拟化工具仅支持同步调用的场景，而实际很多服务调用是异步形式，OverMock进行了改造从而支持异步调用的模拟。\nOverMock也提供一套友好的工具页面支持，支持录制报文可视化展示和修改、虚拟化规则配置、命中规则测试等","解决技术问题：\n目前的stub和mock工具是常见的微服务模拟工具，但是这两种不能应对灵活的实际业务场景，要么全部使用真实服务要么全部使用虚拟服务，且无法支持异步调用场景的模拟。\n\n效果：\n本系统实现了灵活的微服务模拟，可以根据请求的不同来走到真实/虚拟的微服务，能支持异步调用场景的模拟并且提供友好的工具页面和插件。",null,"吴晶晶/80234669","CN116627800A 一种可热插拔的mock测试方法、装置及存储介质 ","对比文件主要关注于通过独立划分接入微服务的方式实现服务A和服务B的解耦，并提供可热插拔的mock桩来提高测试的覆盖率和效率。其核心在于根据测试场景需求（真实返回或模拟返回）来切换mock开关。\n而本申请（OverMock）则设计了一个功能更为丰富和灵活的mock服务端，支持capture、modify、spy、diff四种模式，并提供了相应的工具页面支持。其目标不仅仅是提高测试效率，还包括实现请求的录制、响应的修改、模拟穿透和差异比对等功能。此外，本申请还支持异步调用。\n综上所述，两者在所要解决的技术问题以及解决该技术问题的技术方案上均存在区别。","建议结合实际的异步调用场景补充具体实施例","补充内容后建议申请发明专利","发明","潘远帆"]
[14,"零售应用研发中心/信用卡开发团队/信用卡收单开发室","自研文件传输工具","主要发明点：\n1.实现异步文件加密传输\n2.支持多并发传输\n3.支持超大文件传输，不限文件大小\n4.支持远程调起传输\n5.实现文件传输后的自动回调\n6.支持本地向异地传输文件和本地从异地拉取文件\n7.支持负载均衡模式传输\n\n\n方案简述：\n自研文件传输工具提供接口，用户调用接口生成传输任务，传输任务可指定传输模式，目标节点名，目标文件名，回调名等，后台异步处理传输任务。\n传输任务分为两种模式：\nPUT模式：将本地文件传输至目标服务器\nGET模式：从目标服务器拉取文件至本地\n后台根据配置的并发数获取相应数量的待处理传输任务，根据传输任务获取目标节点名，与目标节点建立加密连接，执行相应模式的文件传输，将文件传输至指定路径，传输结束后根据回调名回调配置的接口。","解决技术问题：\n目前文件传输工具多为同步调用，需要同步等待，浪费资源；对文件大小有限制，无法处理超大文件；明文传输，存在安全隐患；无负载均衡策略。\n\n效果：\n本发名解决了文件传输的大部分问题，原生支持异步传输，节省时间和资源；不限制文件大小，支持超大文件传输；加密传输更安全可靠；支持负载均衡策略，支持高可用。",null,"董豪/80374236"," CN111953784B 基于异步通信框架的文件传输方法、装置及系统 ","对比文件通过控制台发送传输任务信息给节点管理模块，进而执行文件传输。而本申请中，用户通过调用自研文件传输工具的接口生成传输任务，这些任务在后台进行异步处理。用户还可以指定传输模式（PUT或GET）、目标节点名、目标文件名以及回调名等参数。对比文件与本申请在文件传输模式上也不同。此外，本申请中，在文件传输结束后，会根据回调名回调配置的接口。而对比文件中并未提及有关回调机制的内容。","建议补充文件异步传输的数据交互示意图","补充内容后建议申请发明专利","发明","潘远帆"]
[15,"总行/信息技术部/零售应用研发中心/信用卡开发团队/信用卡收单开发室","一种基于网关数据跟账一致性保证方法","主要发明点：\n1)支持跟账模式、跟账切量模式以及单发模式\n2)采用本地路由注册表机制，减少数据中间件依赖\n3)链路故障快速处置\n\n方案简述：\n为了商管平台国产化改造过程平稳过度，适配改造现有接口网关。在现有网关路由转发功能基础上，增加跟账模式、跟账切量模式以及单发模式。三种模式支持一键切换，实时生效。\n跟账模式：请求同步分发至多个服务端，从而满足数据异构一致性、服务端功能验证等个性化需求\n跟账切量模式:跟账模式验证通过后可根据多种自定义配置进行流程切量\n单发模式：跟账流量全量切换以后就可一键转换为单发模式，从而实现在数据异构、服务升级等过程中的流量平稳过度\n此外，为了保证模式切换、路由转发的高效稳定减少对外部环境的依赖，采用了本地路由注册表，本地路由注册采用支持主动、异步线程扫描以及过期策略等多种刷新方式","解决技术问题：\n1）如何避免本地路由注册表数据膨胀问题及保障数据一致性\n2）如何支持跟账模式动态调整并进行数据校验\n3）如何避免异步通信对数据跟账比对影响\n\n效果：\n本系统支持灵活配置，跟账模式、跟账切量模式以及单发模式一键切换，流量高效稳定分发，并且采用死信队列方式，屏蔽异步场景影响，跟账结果可视化查看",null,"付滨瑞/80374367","CN115328680A 消息队列消费异常的辅助方法、装置和电子设备 ","对比文件的应用场景主要集中在消息队列的消费异常处理上，重点在于提高处理效率和标准化程度。\n本申请的应用场景是商管平台国产化改造过程中的接口网关适配，重点在于确保改造过程的平稳过渡和数据一致性。两者的应用场景不同。\n此外，对比文件主要关注于消息队列消费异常的辅助处理，通过一种特定的方法、装置和电子设备对消费异常消息进行分析和处理，包括将其分配至死信处理器或延迟队列，以实现消息的再次处理或人工介入。其目的在于提升消息队列消费异常的处理效率和标准化程度，并实现不同类型消息队列之间的混合使用。而本申请则聚焦于商管平台国产化改造过程中的接口网关适配。通过在现有网关路由转发功能的基础上增加跟账模式、跟账切量模式以及单发模式，并支持一键切换，旨在实现平台改造过程的平稳过渡和数据一致性保障。两者所要解决的技术问题也不同。","建议结合具体的跟帐业务场景补充流程步骤示意图","补充内容后建议申请发明专利","发明","潘远帆"]
[16,"总行/信息技术部/零售应用研发中心/信用卡开发团队/信用卡收单开发室","一种基于滑动窗口分布式ID生成方法","主要发明点：\n1)双滑动窗口交替工作，数据库等服务不可用仍可对外服务\n2)采用模式选择，普适业务场景\n3)采用熔断、降级机制避免异常流量对服务影响\n\n方案简述：\n采用高度自定义方式，进而做到普适业务场景。可配置参数如滑动窗口大小、ID序列模式、阈值、初始化信息以及降级方案等等\n双滑动窗口可根据流量情况动态调节大小，有效避免容量浪费也减少网络波动对服务稳定性的影响\n此外，对请求分类统计同历史情况比对，偏差过大会主动预警反馈至业务方，从而起到异常情况可感知可预防的作用","解决技术问题：\n1）如何降低对数据库等外部服务的依赖\n2）如何普适业务场景ID、保证ID高效稳定生成\n3）如何识别异常流量并做到异常防控\n\n效果：\n本系统可高效稳定生成业务ID且可普适业务场景，统计分析流量并结合告警机制、可视化工具，做到异常防控作用，存量业务场景只需要简单配置就可以快速适配支持",null,"付滨瑞/80374367","CN103812784A 一种基于双向滑动窗口的内容网络的拥塞控制方法 ","本申请的应用场景更为广泛，不仅关注网络拥塞问题，还强调了服务的连续性和稳定性，特别是在数据库等服务不可用时仍能对外提供服务的能力。此外，本申请还考虑到了异常流量对服务的影响，并为此设计了熔断、降级机制。它高度自定义，可以配置各种参数以适应不同的业务场景。\n对比文件则专注于内容网络的拥塞控制，特别是兴趣包请求过快和数据流量持续增长导致的网络拥塞问题。它利用双向滑动窗口来优化网络的可靠性和有效性。\n综上所述，本申请与对比文件的主要区别在于其应用场景更为广泛，具体的实现方式也不同。","建议补充双滑动窗口配置参数的具体实施例","补充内容后建议申请发明专利","发明","潘远帆"]

{"sheet":"3.25-4.03","index":5,"n_rows":17,"n_cols":13,"rows_kept":17,"cut":false,"hidden":false,"merged":[[0,0,0,6],[0,7,0,12]]}
["发明人填写",{"$nulls":6},"代理人填写"]
["序号","中心/团队/室","专利名称（暂定名称）","主要发明点/方案简述及与现有技术的区别","解决的技术问题及预计达到效果","所属技术领域","发明人","检索的最接近对比文件","检索分析\n（与对比文件相比的区别点）","待发明人补充内容\n（挖掘现场代理人提出需要发明人补充的内容）","检索结果\n如：补充内容后建议申请XX专利\n建议拆分专利（说明拆分内容）\n不建议申请，说明原因","建议申请类型","检索人"]
[1,"零售应用研发中心/投资理财团队/投资业务七室(成都)","一种稳定生成24时点历史资产数据的处理方案","创新点：\n1、 基于Oracle主备库按事务提交顺序同步的机制，通过主动在Oracle主库写入数据就绪信息然后在备库识检查数据就绪信息是否存在判定备库数据的完整性。\n2、 基于实时的持仓表中的实时以及上日持仓快照数据结合24时点产品净值数据计算24时点历史资产数据。\n","问题：\n1. 传统方案，通过上游各业务系统提供24时点历史资产的数据加工口径，在数仓内通过加工口径计算出24时点历史资产，各业务系统的加工口径不一致且加工口径复杂，需要使用持仓表，交易表，产品表以及账户表等计算得到历史资产数据，上游业务系统逻辑变更影响口径时，无法及时更新口径，导致历史资产数据不准确。\n2. 传统方案，通过定时抽取业务系统备库的源数据下载离线数据，然后基于离线数据加工历史资产数据，但是因主备延迟的问题过大的情况导致数据不完整。",null,"吴洁峰/80273215","1、CN115375160A 基于投资风险的数据监控方法、装置、设备及存储介质\n2、CN115131151A 基于投资数据的交易监控方法、装置、设备及存储介质","对比文件1提供一种基于投资风险的数据监控方法、装置、设备及存储介质。该方法包括：获取在预设的统计时间所统计的资产估值数据表，以及在统计时间至当前时间之间的投资交易明细；资产估值数据表包括从预设的起始时间起，至统计时间为止，所投资的各投资品的历史持仓数据；确定资产估值数据表中，各投资品的历史持仓数据，并确定投资交易明细中，各投资品的交易明细数据；根据各投资品的历史持仓数据和交易明细数据，确定各投资品的当前持仓数据；根据各投资品的当前持仓数据，对各投资品的交易数据进行交易风险监控处理，并生成监控信息。本申请结合资产估值数据表和投资交易明细，提高数据监控精度，实现对数据的实时监控。\n对比文件2提供一种基于投资数据的交易监控方法、装置、设备及存储介质。该方法包括：采用QuartzJob的定时任务监听器，获取资管计划组合中资产管理计划的历史持仓数据和在途交易数据；资管计划组合中包括多个预设的资产管理计划，资产管理计划中包括多个底层资产；根据历史持仓数据和在途交易数据，确定在在途交易数据的交易日期内，资管计划组合中各资产管理计划的在途份额占比；根据在途份额占比和资产管理计划中各底层资产的预设投资占比，确定在在途交易数据的交易日期内，底层资产的底层投资明细；根据底层投资明细，对资管计划组合中的交易进行监控。本申请的方法，结合历史持仓数据和在途交易数据，提高交易监控的准确性和实时性。\n本申请与对比文件1的区别在于，本申请专注于利用Oracle主备库同步机制确保数据完整性，并通过实时持仓表与产品净值数据结合计算历史资产数据，实现了对数据准确性和实时性的提升。而对比文件1则主要关注通过资产估值数据表和投资交易明细进行交易风险监控，重点在于风险管理和监控精度的提升。\n\n本申请与对比文件2的区别在于，本申请强调通过Oracle主备库同步机制确保数据完整性，并利用实时持仓数据与产品净值数据计算历史资产，实现对数据的实时监控。而对比文件2则聚焦于资管计划组合的交易监控，利用定时任务监听器获取历史持仓和在途交易数据，更侧重于交易层面的监控和准确性提升。","深入说明Oracle主备库同步机制的具体实现细节，包括数据就绪信息的写入与检查策略，以确保备库数据的完整性和一致性。补充关于实时持仓表与上日持仓快照数据的详细结构、更新频率以及与其他数据表（如交易表、产品表、账户表等）的关联关系等。此外，还有关于业务系统逻辑变更时如何更新数据加工口径的具体流程和策略，以应对上游业务系统的变化。补充关于主备库延迟问题的解决方案和应对策略。","建议申请发明专利","发明专利","孙德龙"]
[2,"零售应用研发中心/网络应用开发团队/互联网内容开发室（杭州）","一种基于行为数据及binlog数据的热点统计可预警运营系统","发明点：\n1. 使用canal同步数据到kafka，消费行为数据和部分业务表数据进行热点统计，热点统计完全与业务流程解耦\n2. 细粒度热点预警，预警细化到具体的内容（某篇文章、某个帖子），帮助开发人员在分布式系统下评估当前热点对系统的影响并针对性响应。\n3. 兼具通用性与个性化数据统计\n4. 实时的多指标数据统计分析，数据报表永久存储，协助观察内容运营效果\n\n","解决的问题：\n1. 以往的热度预警主要是针对某一个功能模块进行告警，没有细粒度到数据级别。在分布式系统中，因不知道具体的热点数据，不能快速定位流量上升对系统的影响，需要对基础设备、应用日志逐步排查分析，评估影响范围，响应慢。\n2. 运营效果分析通常是T+1产出，且观测指标较少，报表每次都需要人工去生成缺少连续的维护。\n\n预期效果：\n1. 通过热点预警快速定位数据落地设备及相关链路，分析资源使用情况及时进行调整，避免可用性事件发生，节约日常服务运行的资源。\n2. 实时的、多指标的、个性化的、持久化的运营效果报表，协助分析运营效果，方便后续数据回检。",null,"伍娇/80374717","CN117333051A 基于消费Kafka+离线补偿机制的实时业绩计算系统","对比文件公开了一种基于消费Kafka+离线补偿机制的实时业绩计算系统。该系统包括多个业务系统、CRM系统和大数据Flink平台；通过Kafka的方式抛给银行CRM系统，CRM系统根据抛过来的Kafka消息，匹配到对应的客户经理数据后，再抛给大数据Flink平台进行实时计算，大数据平台计算好的数据，实时写入管理驾驶舱平台和银行内部APP端，用于展示客户经理实时业绩数据指标。该系统基于消费Kafka消息队列的方式，可以实现较低的延迟，准实时地处理和计算客户经理的业绩数据；客户经理可以及时了解自己的业绩情况，及时调整策略和行动；通过对实时业绩数据的分析，及时识别业务机会和问题，做出相应的决策和调整。\n本申请与对比文件的区别点在于：对比文件关注于基于Kafka的实时业绩计算系统，旨在准实时处理和展示客户经理业绩数据。而本申请则侧重于使用Canal同步数据到Kafka，实现消费行为与业务数据的热点统计，提供细粒度预警及多指标实时统计分析，旨在快速响应系统热点并持续观察运营效果，为分布式系统管理和内容运营提供有力支持。","详细阐述Canal同步数据到Kafka的具体实现机制，包括数据同步的准确性、稳定性和实时性保障措施；深入说明热点统计算法的原理及优化策略，确保预警的准确性和及时性；补充多指标数据统计分析的具体指标和计算方法，以及数据报表的生成和存储机制，以满足不同用户的个性化需求。","建议申请发明专利","发明专利","孙德龙"]
[3,"零售应用研发中心/零售信贷开发团队/个人信贷三室(杭州)","一种在线客户维度切片数据库分库迁移方法","主要发明点：\n1、本方案对源数据库联机交易数据按照客户维度构建迁移状态表，按照客户切片维度分别执行被动迁移和主动迁移；\n2、步骤一先小批量流量交易后触发客户维度被动迁移验证分库系统可用性；步骤二验证无误后开启大流量主动迁移（可控制速率），且在迁移过程中，若有实时流量则轮询等待该客户迁移完提供新分库实例交易服务；\n3、解决从单库到多分库数据库的大批量数据迁移，控制迁移过程中无联机交易流量损失，且保证迁移前后数据一致性，做到可回退可停止。\n\n与现有技术的区别：\n1、迁移过程实时联机交易服务流量无损失，无跨库不一致场景；\n2、迁移过程可验证，可小批量被动迁移验证，可验证完成大批量开启主动分布迁移；\n3、迁移过程平稳可控，结合运行日志或链路日志监控和预警，出现任何问题可随时停止；","解决的问题： \n1、通过对交易数据客户维度切片迁移，解决从单库到多分库数据库的大批量数据迁移，做到可小批量被动迁移流量验证和开启主动迁移并控制速率。\n2、迁移过程中，联机服务无流量损失，也不会产生因新交易数据导致迁移后数据不一致问题；\n\n\n预计达到的效果： \n1、在实时交易流量无损失前提下，保障数据库迁移前后数据一致性，做到可控和可验证，减少整体数据库的迁移时间，降低迁移过程对联机服务用户交易的影响。",null,"张婷/80234780","CN117667896A 一种业务迁移方法、装置、设备、存储介质及系统","对比文件公开了一种业务迁移方法、装置、设备、存储介质及系统，所述方法包括：基于预先设置的迁移流程和目标数据库中的数据状态，控制被迁移应用端对待迁移数据库和目标数据库的操作权限，以将业务数据由所述待迁移数据库迁移至所述目标数据库；当所述目标数据库中的数据与所述待迁移数据库中的数据一致时，控制所述目标应用端逐步接入流量，以使所述目标应用端在接收到业务请求时，基于所述目标数据库执行所述业务请求。本发明实施例通过数据、业务的逐步迁移解决了现有技术中业务迁移需要停机，影响业务连续性的技术问题，实现不停机情况下的业务迁移。\n本申请与对比文件相比，核心在于按客户维度构建迁移状态表，结合被动与主动迁移策略，确保迁移过程无流量损失与数据一致，且迁移可验证、可回退。对比文件则侧重于整体业务迁移方法与系统，未具体涉及客户维度迁移及验证机制。\n","完善迁移状态表的详细构建流程与更新机制，阐明被动与主动迁移的具体实现细节与优势分析，探讨迁移过程中的监控与预警策略，并评估迁移效果，如迁移时间、数据一致性及用户交易影响等。","建议申请发明专利","发明专利","孙德龙"]
[4,"零售应用研发中心/零售信贷开发团队/个人信贷五室","一种高保障的贷款批扣方案","主要发明点：\n1、过滤出当日应扣划贷款时按照贷款还款特质划分，划分后各类贷款还款无交集，提高并发度进而提升效率；\n2、还款异常白名单配置，可以快速恢复非异常情况的批扣断点处理；\n3、批量还款交易的中间内部户非标准化设计，通过限额账户生成规则与批次保持一致，可快速定位问题；\n4、批扣期间联机交易封锁逻辑，可以细化到每一笔贷款。\n\n与现有技术的区别：\n1、现有技术一般将贷款按照交易一致性划分批次处理，未考虑到贷款间的关联性；\n2、现有技术一般对非异常情况的流程不中断处理，后续经由手工确认，没有沉淀出规律；\n3、现有技术一般使用标准限额账户的内部户做资金流转，无法将账号与交易显示对应，不利于数据分析与问题排查；\n4、现有技术一般限制贷款在整个批扣期间无法做联机还款；本方案可以按照每笔贷款的实际还款结束时间做个性化的封锁","解决的问题：\n1.从数据层面解耦，降低升级维护成本。\n2.减低系统从异常恢复时间，减少风险。\n3.无需服务端触发，通过自动化调度+各自服务状态，实现协调层对多方服务的数据最终一致性的保证。\n\n预计达到的效果：\n1.开发人员只需关注新增业务场景实现，向下兼容性高。\n2.异常处理高速便捷，系统稳定性提高。\n3.减少客户不必要的等待时间，提高客户对于个贷系统的使用满意度",null,"吴夏乐/01188116","CN113888305A 一种机构互联网贷款产品统一额度管控系统及其实现方法","对比文件提出了一种机构互联网贷款产品统一额度管控系统及其实现方法，与前端业务系统连接，所述管控系统包括联机服务模块、额度服务模块、智能调度模块和数据库，所述额度服务模块用于对贷款产品、条线额度进行管控，其包括多个服务子单元，所述联机服务模块用于接收来自前端业务系统的额度请求，调用额度服务模块中相应服务子单元，以实现额度的管控，所述智能调度模块用于监控额度变化结果并对外发布，所述数据库与联机服务模块、额度服务模块和智能调度模块相连，用于存储各模块数据。本发明避免了同一授信主体以个人名义或自身经营的小微或个贷工商户同时申请贷款，发生过度授信的风险。\n本申请与对比文件的区别点在于：对比文件主要关注机构互联网贷款产品统一额度管控系统的实现，通过额度服务、联机服务、智能调度等模块进行额度管控。而本申请则聚焦于贷款还款流程的优化，通过贷款还款特质划分、异常白名单配置、非标准化内部户设计以及联机交易封锁逻辑细化等方式，提升还款效率与稳定性。","可进一步阐述贷款还款特质划分的具体标准与操作流程，说明异常白名单配置的实现细节及其对批扣断点处理的影响，探讨非标准化内部户设计的优势及其在数据分析与问题排查中的应用，并深入分析联机交易封锁逻辑细化对每笔贷款处理的具体作用。同时，可补充关于本申请实施效果的具体案例或数据，以证明其在提升还款效率与稳定性方面的实际效果。","建议申请发明专利","发明专利","孙德龙"]
[5,"零售应用研发中心/网络安全开发团队/安全产品室","一种基于Xcode编译器的visionOS应用代码混淆解决方案","主要发明点:\n1、基于LLVM编译器框架制作opt优化器，对visisonOS项目工程源码进行混淆\n2、拦截Xcode原生编译命令，将编译命令进行拆分和重组，在编译中间步骤插入opt优化器的代码混淆逻辑\n\n与现有技术的区别：\n常规的visionOS代码混淆主要是对原生Xcode编译器进行替换，该方案只是对原生Xcode编译器进行功能拓展，增加代码混淆的功能","解决的问题：\n1、该方案只是对Xcode原生编译器做了一层包装和功能拓展，最终还是通过调度Xcode原生编译器完成代码的编译，使用风险大幅度降低，具有较高的稳定性\n2、该方案只需要依赖于开源的LLVM源码, LLVM项目较小且开源程度较高，编译生成opt工具流程较为简单，大幅度降低了后期的升级运维的难度\n\n预计达到的效果：\n1、该visionOS代码混淆方案对Xcode具有无侵入的特性，能够保证APP代码混淆后整体运行的稳定性\n2、该visionOS应用代码混淆方案后期升级运维较为简单",null,"陈涛/80308178","CN117056881A 代码混淆方法、装置、设备以及存储介质","对比文件公开了一种代码混淆方法、装置、设备以及存储介质，属于代码混淆技术领域，该方法包括：获取目标应用的多个源码文件，以及与各所述源码文件相对应的混淆参数；利用Xcode编译器以及所述混淆参数，对各所述源码文件进行编译混淆，得到编译文件。本申请在对目标应用的源码文件进行代码混淆时，可以确定与多个源码文件相对应的混淆参数，利用Xcode编译器以及相对应的混淆参数对多个源码文件进行混淆编译，得到编译文件，也即是本申请通过在多个源码文件中，分别添加多个不同的混淆参数的方式，实现多种混淆函数的随机搭配，进一步实现混淆效果的多样性和随机性，增加对目标应用的逆向分析的难度。\n对比文件为发明人已申请且已公开专利，需注意本申请与已申请专利间的区别点。","注意与已申请专利的区别，尽量体现出不一样的发明点","建议申请发明专利","发明专利","孙德龙"]
[6,"零售应用研发中心/网络安全开发团队/安全产品室","一种将PL/SQL存储过程转换java方法的解决方案","发明点：\n基于javacc解析器进行语法分析得到AST,基于AST转换为执行逻辑，并根据特定规则进行优化，得到可调用的java方法。如将voltdb的plsql执行脚本转换为ignite可调用部署的方法。\n与现有技术的区别：\n轻量化执行，针对存储过程进行转换；\n支持元数据校验","问题：\n PL/SQL存储过程与ignite数据库支持的java方法的兼容性问题\n效果：\n1、业务人员无需学习成本，可将原先使用plsql存储过程后台转换为java可调用方法，部署在其他数据库如ignite\n2、轻量化程序，支持转换前后的语法校验",null,"赵辉/80319283","CN114791812A PLSQL代码的JAVA转换方法、装置、电子设备及存储介质","对比文件提供了一种PLSQL代码的JAVA转换方法、装置、电子设备及存储介质，包括：获取待转换的PLSQL代码文本；对所述PLSQL代码文本进行识别处理，识别出所述PLSQL代码文本的文本类型，其中，所述文本类型包括如下之一：变量命名类型、基础数据类型、自定义结构类型、数组类型、package类型；根据所述文本类型对预设的多个语法树进行筛选处理，筛选出与所述文本类型对应的语法树，其中，不同所述文本类型所对应的所述语法树具有不同的处理节点；采用筛选得到的所述语法树中的所述处理节点对所述PLSQL代码文本进行翻译处理，得到文本信息；对所述文本信息进行转换处理，得到JAVA代码文本。本发明实施例能够在不需要人工介入的情况下顺利对等地将PLSQL代码翻译成JAVA代码。\n对比文件关注PLSQL到JAVA代码的文本转换，通过识别文本类型并筛选语法树实现。本申请则基于javacc解析器构建AST，并优化为可调用的java方法，解决PL/SQL存储过程与java方法的兼容问题，实现轻量化执行与元数据校验。","可补充javacc解析器构建AST的具体步骤和算法；展示AST到执行逻辑的转换过程，并说明优化策略；提供PL/SQL存储过程到ignite java方法转换的实例；分析转换过程中的语法校验机制，确保转换的准确性；评估转换效率及对业务人员的友好性。","建议申请发明专利","发明专利","孙德龙"]
[7,"零售应用研发中心/零售客户经营开发团队/电话银行应用室","一种个性化互备机制的数据缓存集群系统","发明点：\n1.本方案设计了一套个性化的基于内存的多节点数据互备（同步）和清理机制；\n2.本方案设计了一套节点互为主备的集群组合方案。","解决的问题：\n基于内存处理的多节点数据缓存集群，可以作为多系统之间实时传递数据的通道。本方案基于内存处理，并提供简单高效的节点间数据互备（同步）机制，解决传统数据缓存方案redis或消息传递方案kafka逻辑结构复杂，运行不稳定，无法保证数据完整性的问题。\n\n预期达到的效果：\n1.灵活可扩展性：集群由一个或多个节点组成，可通过配置灵活扩展新的节点；\n2.数据完备性：提供了一套节点之间数据实时互备（同步）机制，保证每个节点的数据都是完整的：\n3.灵活访问性：集群节点之间地位完全等同，客户端可以从任意节点存储或获取数据；\n4.其他特性：提供了历史数据清理机制，并提供数据持久化保存机制（可选项）。",null,"王伟/80274405","US9317384B2 使用具有可配置模式的缓存集群进行缓存数据处理 ","对比文件处理缓存数据包括向包括多个缓存服务节点的缓存集群中的主缓存服务节点发送缓存处理请求，所述高速缓存集群可配置为主动集群配置模式，其中所述多个高速缓存服务节点全部处于工作状态并且在所述多个高速缓存服务节点中选择主高速缓存服务节点，或者可配置为备用集群配置模式，其中，所述主缓存服务节点是所述多个缓存服务节点中处于工作状态的唯一节点。它还包括等待来自主缓存服务节点的响应，确定主缓存服务节点是否失败；如果主缓存服务节点发生故障，则选择备份缓存服务节点。\n对比文件处理缓存数据关注缓存集群配置模式与主缓存服务节点的故障处理。本申请则创新设计了基于内存的多节点数据互备（同步）和清理机制，以及节点互为主备的集群组合方案，解决了传统数据缓存方案逻辑复杂、运行不稳定、数据完整性问题。","可补充本申请中多节点数据互备（同步）机制的具体实现细节，包括数据同步的算法、同步频率以及同步过程中的异常处理机制。同时，可进一步阐述节点互为主备的集群组合方案的设计原理与优势，以及如何实现集群的灵活扩展和配置。此外，还可探讨历史数据清理机制的实现方式及效果评估，以及数据持久化保存机制的可选方案。","建议申请发明专利","发明专利","孙德龙"]
[8,"零售应用研发中心/零售基础开发团队/基础开发四室","一种基于分库双活高可用路由方案","主要发明点：\n本方案由路由应用、交易应用组成。路由应用根据路由参数和交易应用实例存活情况等确定一笔交易的交易应用分库路由，交易应用将每两个分库分为一组，交易应用使用路由表登记交易的路由信息，每笔交易需同时在共为一组的两个分库登记路由信息，当交易应用某个分库故障时交易流量能安全的转发到所在组另一个分库处理。","实现交易幂等防重，且解决单库物理故障时的业务高可用。",null,"李兵/80274304","CN110324403A 动态分库路由方法、装置、服务器及存储介质","对比文件提供一种动态分库路由方法，包括：设置一个路由配置表，其中，所述路由配置表用于记录多个平台与多个服务组之间的对应关系，及记录所述多个服务组中的每个服务组所对应的端口；当接收到所述多个平台中的其中某个平台发送过来的业务请求时，根据所述某个平台检索所述路由配置表，从所述多个服务组中确定一个目标服务组以及所述目标服务组所对应的端口，所述目标服务组为所述路由配置表所记录的多个服务组中，与所述某个平台对应的服务组；及将所接收到的业务请求发送到所述目标服务组所对应的端口。本发明还提供一种实现所述动态分库路由方法的装置、服务器和存储介质。本发明解决了不能灵活处理量大的交易的技术问题。\n本申请与对比文件的区别点在于，对比文件通过路由配置表实现平台到服务组的动态路由，解决灵活处理大量交易问题。而本申请创新性地引入交易应用，通过分库路由和路由表设计，确保每笔交易在共为一组的两个分库登记路由信息，实现交易幂等防重，并在单库故障时确保业务高可用。","可深入阐述交易应用与路由应用间的交互机制，详细描述分库路由策略的具体实现，包括如何确定交易应用分库路由、如何根据路由参数和实例存活情况进行路由决策等。同时，可进一步探讨交易幂等防重的实现细节，以及面对单库故障时，如何确保交易流量安全转发至所在组的另一个分库进行处理。","建议申请发明专利","发明专利","孙德龙"]
[9,"零售应用研发中心/零售基础开发团队/基础开发四室","一种金融业务防范短款风险的解决方案","主要发明点：\n贷记交易流程由同步入账拆分为预检查和异步入账，通过预检查的方式避免产生差错交易。","现有的贷记交易处理方式存在银行资金短款或产生差错长款的风险，本方案提出通过异步入账的方式，在保证交易质量的同时实现避免银行资金短款和差错长款",null,"李宏谋/80275120","CN116188190B 一种高并发支付系统多批次半实时对账方法及系统","对比文件公开了一种高并发支付系统多批次半实时对账方法及系统，属于数据处理技术领域，用于统一对账平台下，核心记账系统与下游支付结算系统之间的对账。方法包括：触发半实时对账任务；统一对账平台解析统一对账平台标准输出文件，完成流水勾兑，产生小时级终差错或者存疑，生成多个对账结果文件，记录在统一对账平台的页面；统一对账平台将多个对账结果文件发送给调用支付系统后，调用支付系统对对账结果文件进行解析并完成对账；将对账结果向业务人员预警后，业务人员对对账结果进行处理并向统一对账平台反馈；基于多个批次号利用定时脚本设置定时任务，在每个预定时间间隔后，发起对上一个时间间隔内的对账任务，重复实现多批次半实时对账。\n本申请与对比文件的区别点在于，对比文件主要关注高并发支付系统多批次半实时对账方法及系统，通过统一对账平台实现核心记账系统与下游支付结算系统之间的对账。而本申请则聚焦于贷记交易流程的优化，将同步入账拆分为预检查和异步入账，通过预检查的方式避免产生差错交易，降低银行资金短款或差错长款的风险。","本申请内容补充方向可以包括：详细阐述预检查和异步入账的具体实现过程，以及如何通过这种方式提升交易质量并避免资金风险；同时，分析预检查和异步入账机制在实际应用中的效果，如差错交易减少的比例、资金短款或长款的改善情况等；此外，还可以探讨该方案在不同支付场景下的适用性，以及可能遇到的挑战和解决方案。","建议申请发明专利","发明专利","孙德龙"]
[10,"零售应用研发中心/信用卡开发团队/信用卡客户经营开发三室(杭州)/征审三组","一种涉及MQ应用的灰度发布技术","通过自动创建MQ生产者组件,消费者原始或灰度Q/Topic自动绑定的方式,实现了单Q或单Topic级别的应用消息队列灰度发布,支持复杂生产消费关系的自定义白名单、流量比灰度切量验证","解决了应用灰度发布时消息生产者与消费者灰度流量分发的问题",null,"王红刚/80234784","CN117311794A 基于灰度发布的服务处理方法及装置","对比文件提供了一种基于灰度发布的服务处理方法及装置，可用于金融领域或其他领域，该方法包括：接收目标终端设备发送的服务请求；根据服务请求和灰度发布脚本，确定服务请求的服务版本，服务版本为灰度服务版本或旧服务版本；将服务请求发送至服务版本的生产者服务器，以使该生产者服务器根据负载均衡策略，确定服务请求的分布式消息队列以及该服务请求在该分布式消息队列中的分区，将服务请求存储至分区中；若分区的消费者服务器处于空闲状态，则将分区中的服务请求经由消费者服务器转发至服务版本的服务所在的服务器，完成服务请求的服务处理。本申请能够在基于灰度发布的服务处理的并发量较高时，提高服务处理的可靠性。\n本申请与对比文件的区别点在于，对比文件关注基于灰度发布的服务处理方法，通过负载均衡策略确定服务请求的分布式消息队列及分区，实现服务处理。而本申请则聚焦于应用消息队列的灰度发布，通过自动创建MQ生产者组件及自动绑定消费者原始或灰度Q/Topic，实现单Q或单Topic级别的灰度发布，并支持自定义白名单和流量比灰度切量验证。","可深入探讨本申请中自动创建MQ生产者组件及自动绑定的具体实现方式和技术细节；分析本申请如何确保灰度发布过程中的数据一致性和稳定性；讨论自定义白名单和流量比灰度切量验证在实际应用中的效果及优化策略；研究本申请在复杂生产消费关系场景下的适用性和扩展性。","建议申请发明专利","发明专利","孙德龙"]
[11,"零售应用研发中心/网络安全开发团队/风控服务开发二室(杭州)","一种海量数据异构迁移解决方案","主要发明点:\n本方案基于Elasticsearch原生API以及Kafka等技术设计了一套支持将海量数据从CTBASE清洗迁移至ES的配套工具以及解决方案。\n与现有技术的区别：\n占用资源相对较少,支持分批次迁移；\n迁移效率高，支持并发多任务迁移；\n迁移稳定性高，通过日志记录监控及时发现并纠正迁移过程中的问题。\n","解决的问题:\n1. 降低对外部场景的依赖\n2. 降低了数据存储冗余\n3. 减少了后续的运维成本",null,"宋佳伦/80307430","CN111984621B 一种异构数据库迁移方法、装置及存储介质","对比文件提供一种异构数据库迁移方法、装置及存储介质，用于解决异构数据库迁移效率低、不稳定等技术问题。本公开基于源表之间的依赖关系及数据量对源表进行分组，并通过多个迁移任务并行执行源数据库的导出及向目的数据库的导入步骤。在数据导出和导入过程中迁移的数据不落地，直接通过内存缓存分批导入，提高了迁移的效率。在迁移中断的情况下，可查找到中断时迁移的偏移量，重新迁移时基于偏移量增量迁移，提高了迁移的稳定性。\n本申请与对比文件的区别点在于，对比文件关注异构数据库迁移方法，通过并行迁移任务和内存缓存提高迁移效率和稳定性。而本申请则利用Elasticsearch原生API和Kafka等技术，设计了一套将海量数据从CTBASE清洗迁移至ES的配套工具与解决方案，具有资源占用少、支持分批次迁移、并发多任务迁移以及高迁移稳定性等优势。\n\n","可进一步阐述本申请中利用Elasticsearch原生API和Kafka实现海量数据清洗和迁移的具体过程；分析本申请在降低外部场景依赖、减少数据存储冗余以及降低运维成本方面的实际效果；探讨本申请在数据迁移领域的适用性和推广价值。","建议申请发明专利","发明专利","孙德龙"]
[12,"零售应用研发中心/网络安全开发团队/风控服务开发一室","一种高可用双擎实时风控方案","主要发明点：\n1. 本方案创新性的提出了一种双引擎实时风控方案。\n2. 方案中双引擎按重要性分为主引擎和副引擎，两套决策引擎共同组成双引擎实时风控方案。\n3. 主引擎和副引擎采用异构技术方案，达到经济和安全的目的。主引擎采用PL/SQL和VoltDB数据库并采用物理机部署，而副引擎采用Drools和云上Redis数据库，以降低成本。\n4. 主引擎和副引擎并行运行，可灵活配置，实现联动风险决策。一般情况下99.9%的交易由主引擎提供实时决策，剩余交易由副引擎提供，而当主引擎完全故障后才由副引擎提供所有决策。也可根据不同业务场景，在决策引擎之间进行灵活设置。甚至可通过统计决策引擎异常情况进行动态设置。\n\n与现有技术的区别：\n1. 传统实时风控系统主要采用单引擎架构，而本方案中率先引入了双引擎的实时风控方案。\n2. 传统架构在版本发布或故障时无法对外提供决策服务，导致遗漏风险和影响客户体验。","解决的问题：\n1.传统单引擎风控系统在版本发布或日常维护时不可用问题。\n2.双引擎之间如何实现灵活切换，联动决策问题。\n3.引入双引擎后的经济成本和安全问题。 \n\n预计达到的效果：\n1.双引擎不会同时故障，系统整体可用性由99.9%提升至99.999%。\n2.双引擎之间可灵活切换，联动决策。\n3.引入双引擎后未带来成本得到有效控制，未大幅上升。\n",null,"秦春来/80375004","CN109840838B 风控规则模型双引擎系统、控制方法及服务器","对比文件提供一种风控规则模型双引擎系统、控制方法及服务器，所述风控规则模型双引擎系统包括：在线规则模型平台，用于控制在线规则；模拟规则模型引擎平台，用于根据风控特征数据生成模拟规则，并获取实时生产数据、根据所述实时生产数据对所述模拟规则进行训练优化，生成并更新符合生产需求的所述在线规则。本发明通过机器学习方式生成模拟规则，利用计算出的特征和关联关系等中间数据生产模拟规则，实现利用真实的生产数据，不断训练预上线的模拟规则，利用真实的生产数据达到预判和调整训练模拟规则，实时、自主的学习和优化现有规则的阈值，避免每次需要通过人工根据经验和一段时间运行效果人工调整对应的阀值，规则更精准、人性化。\n本申请与对比文件的区别点在于，对比文件关注风控规则模型双引擎系统，通过模拟规则引擎优化在线规则，实现自动化学习和优化。而本申请则创新性地提出双引擎实时风控方案，主副引擎异构设计，实现经济和安全平衡，并灵活配置联动风险决策，提升系统整体可用性和客户体验。","可深入阐述主副引擎异构设计的实现细节，包括PL/SQL、VoltDB与Drools、Redis的集成方式；探讨双引擎之间灵活切换和联动决策的具体机制，如切换策略、决策协同等；分析引入双引擎后的经济成本和安全性的实际效果，以及如何进一步优化成本和安全性平衡。","建议申请发明专利","发明专利","孙德龙"]
[13,"零售应用研发中心/网络安全开发团队/安全基础室","一种基于设备风险指数的动态调控方案","主要发明点：\n1、根据设备风险量化风险评估，可有效衡量不法分子利用技术手段攻击的风险程度。\n2、根据风险指数生成动态阈值，实时下发风险管控策略，自动化完成风险调控，从而降低人工维护成本。","解决的问题：\n1.解决现有不法分子利用技术风险（如越狱root、动态注入等），攻击移动金融app的风险程度无法有效衡量。\n2.风险攻击感知滞后\n3.人工维护下发风险管控策略时效性差、成本高\n\n预期达到的效果：\n1.有效评估当前不法分子利用技术手段攻击的风险情况\n2.实时动态下发风险管控策略",null,"郭庆松/80290261","CN115170332A 风险调控方法、装置、存储介质及设备","对比文件公开了风险调控方法、装置、存储介质及设备，可应用于金融领域，该方法包括：获取第一风险程度和第二风险程度；将第一风险程度和第二风险程度，输入至风险模型中，并利用粒子群算法对风险模型中的目标参数进行求解，得到目标参数的最优值后，并向用户反馈最优值，与现有技术相比，用户可将反馈的目标函数的最优值作为参考依据，调整金融市场的调控力度，以确保金融市场正常运作时，金融系统不会发生金融风险。\n本申请与对比文件的区别点在于，对比文件关注金融领域风险调控方法，利用粒子群算法求解风险模型参数，用户参考最优值调整调控力度。而本申请针对移动金融App的技术风险，通过设备风险量化评估风险程度，并生成动态阈值自动下发风险管控策略，实现实时风险调控，降低人工维护成本。","可深入研究设备风险量化的具体方法和实现过程，包括风险指标的选取、量化模型的构建等；探讨如何根据风险指数生成动态阈值，并实时下发风险管控策略；分析本申请在降低人工维护成本和提高风险调控效率方面的实际效果和优势。","建议申请发明专利","发明专利","孙德龙"]
[14,"零售应用研发中心/网络安全开发团队/风控服务开发二室(杭州)","一种基于元数据的文件数据接入方案","主要发明点：\n\n1. 通过模板思想分离文件数据接入类任务的共性内容和个性化内容，根据元数据配置及任务配置信息等自动获取文件连接信息、文件任务字段常规处理逻辑，自动进行文件接入逻辑处理，无需额外硬编码，大大缩小了开发周期，降低了开发成本。\n2. 根据配置重试次数，在文件接入失败后自动重试执行，从而降低人工维护成本。\n3. 支持前端托拉拽配置数据转换、流程处理、数据删除、数据查询等个性化处理，适配不同文件接入任务的个性化处理，增强文件处理能力，提高对外赋能能力。\n4. 支持文件接入前、接入中、接入后个性化处理，适配不同文件接入任务的特定需求。\n5. 支持文件接入到不同数据源，例如MYSQL、ES、KAFKA等\n6. 准实时监控文件接入情况，出现文件未执行、文件执行结果不符合预期配置结果等情况则会触发告警，使得文件接入问题在无需人工验证的情况下提前暴露，加快文件接入问题提前解决。\n\n与现有技术区别：\n1. 一次编码，到处使用：现有文件接入基本都是针对特定需求进行硬编码，存在相同处理逻辑不断重复开发的情况。本方案将重复执行逻辑抽取出来，通过配置选择需要的执行逻辑，无需重复编码。\n2. 低代码支持个性化：现有技术之所以需要重复硬编码，是因为不同文件接入总会存在个性化部分（如将某个时间字段进行格式转化等）。本方案将这部分使用低代码技术封装起来，使用者只需简单托拉拽配置即可实现。\n3. 自动重试：文件未到达或者文件接入失败时，本方案可支持自动重试，减少人工运维。","解决的问题：\n1. 减少文件接入需求重复硬编码，降低了开发成本，缩小了需求周期。\n2. 文件接入失败自动重试，减少人工运维。\n\n预期达到的效果：\n1. 文件接入需求到达时，无需硬编码，只需数小时的文件任务配置、监控配置、应用部署等即可完成文件接入开发。\n2. 文件未达到或者文件执行失败时，自动进行重试\n3. 可在文件接入前、文件接入中、文件接入后，进行个性化处理\n4. 重试配置次数之后，文件接入仍然异常时触发告警，及早发现问题解决问题。",null,"郑兰芳/80296829","CN113517985B 文件数据处理方法、装置、电子设备及计算机可读介质","对比文件公开了文件数据处理方法、装置、电子设备及计算机可读介质，涉及大数据技术领域，一具体实施方式包括接收客户端发送的上传规则请求，调用规则引擎基于上传规则请求中的客户端信息和待上传文件属性信息，生成网点规则配置信息并返回；接收客户端根据网点规则配置信息发送的文件上传请求，查询文件上传请求中的元数据，以执行新增文件的上传，返回上传进度和新增文件地址信息。从而，本发明实施方式能够解决现有文件管理效率低、安全性差的问题。\n本申请与对比文件的主要区别点在于，对比文件关注文件上传及处理的流程优化，而本申请则重点通过模板思想分离文件数据接入任务的共性及个性化内容，实现自动文件接入逻辑处理，降低开发成本，减少硬编码。同时，本申请支持自动重试、个性化处理及实时监控告警，提升文件接入的效率和稳定性。","可进一步探讨模板思想在文件数据接入任务中的具体应用和实现方式；分析自动重试机制在不同场景下的效果及优化策略；研究个性化处理的具体配置方式和处理逻辑；探讨实时监控告警系统的架构和告警触发机制，以及如何更有效地解决文件接入问题。","建议申请发明专利","发明专利","孙德龙"]
[15,"零售应用研发中心/网络安全开发团队/风控服务开发二室(杭州)","一种可动态配置的实时图计算方案","主要发明点：\n1、支持动态编写图规则语句，计算应用动态加载新规则\n2. 基于kafka消息触发规则的实时计算，\n3. 实时动态下发图规则计算结果。\n","解决的问题\n1. 解决了业务规则验证周期的问题\n2. 解决离线图计算时效慢的问题。\n\n预期达到的效果\n1. 可以自由编写业务规则，并对数据进行验证",null,"蒋涯/80276358","CN115249148A 业务处理流程的配置方法、装置及电子设备","对比文件提供的业务处理流程的配置方法、装置及电子设备，涉及数据处理技术领域。在本申请中，对数据来源进行配置处理。对输入数据的业务处理规则进行配置，电子设备用于依据业务处理规则对输入数据进行处理，以输出目标输出数据，其中，电子设备在依据业务处理规则对输入数据进行处理的过程中，还输出至少一条中间处理数据，目标输出数据通过电子设备依据业务处理规则对至少一条中间处理数据进行处理以得到。对业务处理规则的验证规则进行配置，电子设备用于依据验证规则提取到至少一条中间处理数据，以验证业务处理规则。基于上述方法，可以改善现有技术中业务处理流程的管控效果不佳的问题。\n本申请与对比文件的区别点在于，对比文件关注业务处理流程的配置，通过配置数据来源、业务处理规则和验证规则来优化业务处理。而本申请则创新性地提出实时图计算方案，通过可视化页面实现数据导入配置和业务规则编写，无需硬编码，降低开发门槛和周期。","可深入研究实时图计算方案的具体实现机制，包括图数据库的构建、应用层程序的设计等；探讨可视化页面在数据导入配置和业务规则编写中的应用和优化；分析本申请在提升图谱数据实时性和业务规则即时响应性方面的实际效果和优势。","建议申请发明专利","发明专利","孙德龙"]

{"sheet":"4.8-4.19","index":6,"n_rows":11,"n_cols":13,"rows_kept":11,"cut":false,"hidden":false,"merged":[[0,0,0,6],[0,7,0,12]]}
["发明人填写",{"$nulls":6},"代理人填写"]
["序号","中心/团队/室","专利名称（暂定名称）","主要发明点/方案简述及与现有技术的区别","解决的技术问题及预计达到效果","所属技术领域","发明人","检索的最接近对比文件","检索分析\n（与对比文件相比的区别点）","待发明人补充内容\n（挖掘现场代理人提出需要发明人补充的内容）","检索结果\n如：补充内容后建议申请XX专利\n建议拆分专利（说明拆分内容）\n不建议申请，说明原因","建议申请类型","检索人"]
[1,"零售应用研发中心/投资理财团队/投资业务七室(成都)","一种准实时多源DB至GaussDB的数据增量同步方案","主要发明点：\n1、在使用较少资源(仅WEB容器应用)的前提下，通过配置实现准实时(分钟级)从多源数据库(MySQL、ORACLE、TDSQL等)抽取增量数据。\n2、利用批量MERGE预编译模板，动态从缓存队列中取数拼接实际SQL执行。\n\n与现有技术区别：\n1、支持自动读取多源DB增量数据，并通过内存拼接SQL执行MERGE入库，减少临时表创建。\n2、不依赖中间件达到准实时同步，同时支持停止及重试。","目前DB至DB数据同步大致有两者方式：（1）全量数据ETL，最多支持到小时级后性能会有问题（2）利用数据库binlog及kafka实现准实时数据采集，资源开销大且不可控。\n本方案可以不利用数据库日志、中间件、临时表等资源的前提下，高效实现分钟级增量同步数据。",null,"章思沛/80311048"]
[2,"零售应用研发中心/零售信贷开发团队/个人信贷一室\n","一种基于字节码和语法树分析的风险变量关联分析方法\n","主要发明点：\n1. 本方案采用字节码和语法树分析风险变量的加工代码，自动化地获取风险变量间的关联关系\n2. 本方案将分析代码的动作嵌入到代码发布的过程中，无需手工维护\n3. 本方案使用图数据库存储代码分析结果，实时可查，支持其他功能扩展\n\n与现有技术的区别：\n1. 现有技术一般采用单一技术栈，分析一个模态的代码。本方案结合了语法树分析和字节码分析的优势，对源码和字节码两个模态的代码进行分析\n2. 现有技术一般服务于代码审计、调用图分析等通用场景，本方案服务于具体的业务场景，进行了大量的定制化。\n3. 现有技术未对目前风险变量加工的系统架构进行兼容，接入需要变更系统。本方案对系统无入侵，无需对原系统进行改动，避免了变更原系统需要消耗的巨大人力和需要承担的变更风险。","解决的问题：\n1. 风险变量数量庞大，彼此间关系复杂，手工梳理变量间的关联关系费时费力\n2. 风险变量的加工逻辑经常变更，手工梳理的变量间的关联关系无法作为资产沉淀下来\n3. 风险变量关联分析需求大，业务人员和测试人员常常需要相关的服务，开发方没有充足的人力提供相应的支持\n\n预计达到的效果：\n1. 对原系统无入侵，无需对风险变量加工组件进行改动\n2. 免维护，无需开发人员手工运维\n3. 支持7x24小时对风险变量的关联关系进行分析\n4. 提供风险变量关系的图形化展示",null,"朱星龙/80323937"]
[3,"零售应用研发中心/零售信贷开发团队/个人信贷二室(杭州)","一种数据库事务嵌套的实时监控方法","主要发明点：\n1、结合接口调用链信息和数据库事务操作信息的数据库日志格式设计；\n2、通过实时识别数据库日志中事务时间重叠发现事务嵌套的技术；\n3、排除异常调用影响的技术；\n\n与现有技术的区别：\n1、现有的数据库监控较多关注全表扫、长事务等单次数据库操作，本发明通过通过联合分析接口调用链中所有的数据库操作，来发现事务嵌套\n2、现有的数据库监控较多为事后监控，本发明通过实时监控方式提升时效性","解决的问题：\n实时识别数据库事务嵌套\n\n预计达到的效果：\n通过日志中接口调用链信息和数据库事务操作信息，实时识别事务嵌套",null,"朱雷坚/80274917"]
[4,"零售应用研发中心/零售信贷开发团队/个人信贷二室(杭州)","一种Flink任务异常的自动化监控运维方案","主要发明点：\n1、基于Flink任务状态对比的自动化监控；\n2、基于Flink Checkpoint心跳机制的自动化监控；\n3、Flink任务异常自动化运维机制；\n\n与现有技术的区别：\n1、现有技术一般依赖Flink异常重试，在Flink集群整个异常时无效，本发明在Flink集群异常时仍然有效；\n2、现有技术一般依赖Flink异常重试，在任务假死时无效，本发明可以发现任务假死；","解决的问题：\nFlink任务异常监控和自动化运维\n\n预计达到的效果：\n通过状态对比和心跳监控实现Flink任务的异常监控，并且实现自动重启功能",null,"张豫坤/80256859"]
[5,"零售应用研发中心/零售信贷开发团队/个人信贷一室\n","一种基于生产历史数据进行策略预警和后督方案","主要发明点：\n1.本方案通过注解的形式自动采集数据指标，无需手工维护；\n2.根据数据采集指标进行动态预警；\n3.预警信息可链路追踪及可视化;\n\n与现有技术的区别：\n1.现有技术的监控指标需要手动维护保鲜；\n2.现有技术通过总体表现形式，例如：通过率，额度以及利率等基本要素来反推是否正常，比较笼统、不能精准到具体的指标；\n3.现有技术发现异常比较滞后，不能及时主动的发现问题，异常问题不好排查；\n","解决的问题\n1.能够清晰的定位到每个指标是否正常，降低运维成本；\n2.当问题出现时，能及时发现并快速解决，缩短异常时间；\n3.无需关注是否新增指标，实现自动化监控预警；\n\n预计达到的效果\n1.出现新指标的时候，进行自动化监控，无需手工维护；\n2.支持指标个性化自动预警；\n3.当某个指标出现异常的时候，并且能够根据预警数据进行链路追踪，快速排查；",null,"朱兰兰/80320949"]
[6,"零售应用研发中心/零售信贷开发团队/个人信贷二室(杭州)","一种高频查询场景下数据库异常的高可用解决方案","主要发明点：\n1.使用Flink窗口滑动机制，按照指定规则聚合计算高频查询请求的响应结果；\n2.可配置的阈值规则，动态定义数据库健康状态；\n3.自动隔离异常数据库，并重新对健康数据库进行负载均衡;\n\n与现有技术的区别：\n1.不依赖数据库自身的主备切换；\n2.对数据库是否健康有更加准确的定义；\n2.更快的速度完成自动隔离不健康的数据库；","解决的问题\n1.数据库自身主备切换失效；\n2.数据库是否健康判断不够及时和准确；\n3.数据库不可用时，对于业务的影响；\n\n预计达到的效果\n1.准实时定义数据库是否健康；\n2.自动隔离不健康数据库；\n3.对健康数据库进行重新分配，达到负载均衡，减轻单个数据库压力；",null,"张少斌/80274725"]
[7,"零售应用研发中心/零售信贷开发团队/个人信贷二室(杭州)","一种高可用下的分库异常监测及数据无感恢复解决方案","主要发明点：\n1.数据库自动化监测及高可用切换，支持数据库有状态（避免脏读、脏写、数据不一致）。\n2.数据迁移恢复与新订单业务可并行，无需业务等待时间，保证7*24业务连续性。\n3.规则配置化，自动触发异常监控和止血任务触发。\n\n与现有技术的区别：\n1.目前市面上的高可用，要求用户数据无状态，场景要求苛刻。\n2.目前市面上，迁移通常采用双写双读策略，对于资源消耗更高。而本次数据无感恢复方案无需双写双读，通过状态控制，可直接迁移。\n3.目前数据迁移，一般需要事先做预处理，人工干预；本地数据迁移及异常恢复，通过日志窗口监控，做到自动检测数据库状态，进行高可用及恢复。","\n解决的问题:\n1.分库架构中，如果存在某个分库异常场景下，能够继续保证业务连续性。\n2.分库异常恢复后，如何将异常数据动态平衡回源数据库。\n3.数据库高可用状态中，如何保证数据的一致性，避免脏读、脏写、数据不一致；\n\n预计达到的效果:\n1.分库实时高可用。实时监控数据库状态，在某分库异常情况下，切换\n2.异常数据，分库无感恢复。异常分库恢复后，自动将异常数据动态平衡回源数据库，且不影响业务连续性。\n3.数据一致性性保证。分库高可用或异常恢复期间，保证数据一致性，不产生脏读，脏写现象。",null,"盛意林/80258171"]
[8,"零售应用研发中心/网络安全开发团队/安全基础室","一种安全的密钥(国密)明文导入方案","主要发明点：\n1.自研SM4密钥明文导入方案\n2.自研SM2密钥明文导入方案                    与现有技术的区别：\n1.目前市面上的密钥导入方案，在进行网络传输时存在明文信息，容易造成密钥泄露。\n2.有些密钥导入方案需要到机房进行手工导入，效率比较低，且专业性要求比较高，本方案可以远程导入，无需学习加密机操作知识。","解决的问题：\n1.提供统一密钥操作平台，只需在网页界面输入密钥明文，剩下的复杂操作，都由后台自动完成，提升工作效率\n2.网络全链路无明文信息传输，避免敏感信息泄露",null,"罗昌凯/80310851"]
[9,"零售应用研发中心/零售客户经营开发团队/零售信息应用开发二室(杭州）","一种千亿级历史数据高性能查询及恢复方案","主要发明点：\n1.数据降维及加载，纵转横以及采用putlist动态列的方式加载数据\n2.数据提前封装及毛刺数据处理\n3.极端情况下的HBASE集群全年数据的快速恢复方案\n与现有技术区别：\n1.目前市面上时间会作为数据的一个维度，造成数据总量较多，查询效率较低\n2.数据未提前封装，增加解析成本，增加额外耗时\n3.极端情况下千亿数据全量恢复耗时严重","解决的问题：\n1.针对大数据量带来的数据复杂度，采用纵转横方式减少数据总量，用自定义PUTLIST动态列方式进行数据加载，降低数据维度，提升了读取及加载效率\n2.将数据提前封装JSON串，同时针对毛刺数据进行提前预处理，提升解析效率、降低数据溢出风险\n3.在集群极端不可用且数据恢复难的情况下，将线上全量千亿数据在较短时间内重新抽取加载，进行全盘初始化恢复，降低影响。\n\n预计达到的效果：\n1.数据总量从千亿降至2亿\n2.平均响应时长100ms左右\n3.集群全年数据初始化控制在10小时以内",null,"周逊/80374833"]

{"sheet":"4.22-4.30","index":7,"n_rows":13,"n_cols":13,"rows_kept":13,"cut":false,"hidden":false,"merged":[[0,0,0,6],[0,7,0,12]]}
["发明人填写",{"$nulls":6},"代理人填写"]
["序号","中心/团队/室","专利名称（暂定名称）","主要发明点/方案简述及与现有技术的区别","解决的技术问题及预计达到效果","所属技术领域","发明人","检索的最接近对比文件","检索分析\n（与对比文件相比的区别点）","待发明人补充内容\n（挖掘现场代理人提出需要发明人补充的内容）","检索结果\n如：补充内容后建议申请XX专利\n建议拆分专利（说明拆分内容）\n不建议申请，说明原因","建议申请类型","检索人"]
[1,"零售应用研发中心/投资理财团队/投资业务七室(成都)","一种灵活的跨品类投资理财产品一键下单解决方案","主要发明点:\n1.实现了不同品类投资理财产品一键交易下单,包含的品类有:基金,理财,存款,黄金，并且汇总各个品类交易的结果\n2.灵活的扩展，方便接入新的品类\n\n\n与现有技术的区别:\n1.目前市面上的客户投资理财产品的交易大多为单笔下单\n2.支持多笔交易下单的一般为同类型的理财产品，没有跨不同品类的交易，不满足当下投顾、客户经理给客户推多品类订单等场景","解决的技术问题:\n1.支持多品类,每个品类多笔明细交易指令.总共的交易笔数能达到几十笔.\n2.提供标准的接口接入，方便接入新的品类\n\n预计达到效果:\n在投资理财品类下单交易时,实现跨品类跨系统的客户交易订单执行",null,"王利强/80275430","对比文件1（CN106991611A）公开了一种智能理财投资顾问机器人的工作方法及其系统，其中方法包括：A获取与处理用户数据、B生成投资策略、C投资策略与用户匹配、D一键下单购买功能、E维护与调整投后投资策略，本申请利用移动互联网技术，向用户提供陪伴式的理财顾问服务，最大限度地了解用户的需求，最合理地并且最大效率地将最适合用户的理财产品推荐给用户，并在用户购买产品后不断跟踪用户在理财领域的成长以及投资组合的变化，不断提供投资组合策略的调整服务，使策略能够适合用户不同的成长阶段以及不同的市场环境，同时提供投资组合的业绩分析跟踪分析工具，使用户能够随时方便地查看投资业绩。","对比文件1公开了理财产品组合的一键下单，与对比文件的区别在于，本案的一键交易中可包括多个品类的产品，各个产品可对应不同的系统。","请补充，1，不同品类投资理财产品一键交易下单时,与各个系统之间详细的交互过程；2，在接入新的品类的详细过程.","补充资料后建议申请发明专利","发明","苗广冬"]
[2,"零售应用研发中心/投资理财团队/投资业务七室(成都)","一种代销系统交易明细资金和信托机构账户金额双向核对的解决方案","主要发明点:\n1、交易明细和信托公司资金账户核对以及信托公司资金账户反向核对交易明细资金\n2、交易明细及多分库汇总多维度核对，核对不一致直接阻断，保证各方资金安全\n3、赎回资金到账先核对，资金核对无误后打款给客户\n\n与现有技术的区别:\n1、市面大多数交易明细单向核对资金账户，基于此基础新增资金账户反向核对交易明细\n2、先给打款给客户，后和信托公司结算方才发现资金不匹配，资金释放前核对确保结算资金一致\n3、无法感知信托公司资金账户资金是否到账，到账之后是否被其他途径挪用\n","解决技术问题：\n1、交易明细和资金账户双向核对，多明细多分库多家信托公司多维度交易明细汇总核对\n2、资金释放前阻断式资金核对，核对不通过不资金释放终止\n\n预期达到效果：\n资金释放给客户前已完成交易明细和信托公司资金账户的全量核对确保后续代销系统和信托公司结算的时候资金一致",null,"自龙彩/80308310","对比文件1（CN114880335A）公开了一种信息处理方法、装置、设备及存储介质，响应于接收到的事件信息，根据事件信息，确定事件信息对应的待核对交易事件的核对规则，并根据核对规则，以事件信息中的基准信息为基准，核对事件信息中的待核对信息。其中，接收到的事件信息包括交易信息和账户信息中的至少一种，即接收到交易信息或接收到账户信息均可触发核对，获得核对结果。可见，这种既支持资金变更触发核对，也支持交易发生触发核对的双向核对方式，对交易成功但资金未产生变更的资金风险，以及资金产生变更但交易未成功的资金风险均可以进行核对，更加全面的发现资金风险，保障资金安全。","与对比文件的区别在于，交易明细和资金账户双向核对，多明细多分库多家信托公司多维度交易明细汇总核对。","请补充，1，易明细和资金账户双向核对的详细过程，2多明细多分库多家信托公司多维度交易明细汇总核对的详细过程.3，资金释放前阻断式资金核对的过程。","补充资料后建议申请发明专利","发明","苗广冬"]
[3,"零售应用研发中心/投资理财团队/投资业务七室(成都)","一种代销系统和信托机构之间在途资金的解决方案","主要发明点:\n1、客户购买信托产品已经扣款但是份额还未到账，客户赎回份额已经扣除但是资金还会给到客户账户，这部分在途资金准确的在账户资产总览展示\n2、客户交易确认周期中资金和持仓变动记录在途的资金，短时间存在，交易完成到账在途资金消失\n3、在途变动保留历史、历史资产展示可追溯\n\n与现有技术的区别:\n1、市面现有展示总资产需要去交易历史记录寻找是否存在在途并实时计算出在途的资金合并到总资产展示\n2、单独记录存储在途资金，账户总资产查询直接获取存储的在途资金\n","解决技术问题：\n1、解决客户总资产展示短时间不准确问题\n2、解决总资产查询遍历所有交易历史计算出在途资金耗时过长问题\n3、解决总资产展示及历史资产展示查询历史交易复杂繁琐的计算未到账在途资金问题\n\n预期达到效果：\n1、准确的查询展示总资产在途资金\n2、快速响应持仓总资产查询，响应时间控制在50ms以内",null,"自龙彩/80308310","对比文件1（CN113298607A）公开了订单信息处理方法、装置及电子设备，所述方法包括：接收关于第一账户产生在途资金数据的通知消息；所述在途资金数据包括第一账户以及第二账户的信息，所述第一账户为所述在途资金数据的目标转入账户，所述第二账户为所述在途资金数据的转出账户；确定所述在途资金数据关联的交易订单的标识；将所述交易订单修改为支付中状态，以便基于所述支付中状态对所述交易订单进行履约处理。通过本申请实施例，有利于交易订单的缩短履约处理时间。","与对比文件的区别在于，1、客户购买产品以及赎回产品的在途资金与总资产的展示方式；2、通过在途变动历史可追溯历史资产。","请补充：1，客户购买产品以及赎回产品的在途资金与总资产的进行展示的详细过程；2，通过在途变动历史可追溯历史资产的详细过程。","补充资料后建议申请发明专利","发明","苗广冬"]
[4,"零售应用研发中心/投资理财团队/投资业务七室(成都)","一种数据库单库拆分多分库的无损切换移植方案","主要发明点：\n1、按照客户转让的标的编号进行分库，客户交易跟随标的，分库策略与客户无关，单个分库异常时可以及时进行交易异常处置，将异常分库流量切换到其他分库\n2、流量切换过程中，不强依赖移植客户数据，通过网关路由逻辑控制客户新进交易逐步切换到分库，不影响客户正常交易，单库无新增交易后，再将历史数据移植到指定分库，避免了流量切换与数据移植相互依赖引发的额外风险\n3、由于转让是双方交易，按照转让标的编号分库、客户交易跟随转让标的的方式可以降低分布式事务次数，降低程序的复杂度\n\n与现有技术的区别：\n1、区别于一般的固定分库的策略，多个分库可以互为备库，若单个分库异常，可以通过调整路由配置，将异常分库的交易流量切换到其他分库，降低对客户交易的影响\n2、区别于按客户分库的方式，按照转让标的编号分库的方式，可以使转让方与购买方的交易在同一个分库，同时避免复杂事务管理，降低状态不一致等程序风险和成本\n3、在切换流量过程中，无需终止客户交易移植历史数据，通过路由逻辑将交易逐步切换到分库后，再统一移植历史数据数据，保证切换迁移过程对客户无感知\n\n\n","解决技术问题：\n1、解决在流量切换和数据移植过程中，不影响客户正常交易与交易查询，实现对客户无感知\n2、解决在某个分库异常的情况下，可以具备一定容灾能力，将异常分库的交易流量切换到其他正常分库，降低对客户交易的影响\n3、按照转让标的编号分库、客户交易跟随转让标的的方式的方式，解决转让方与购买方的交易数据割裂问题，使双方数据在同一分库，避免复杂事务管理问题，降低程序风险和成本\n\n\n预计达到的效果：\n在系统单库拆分多分库的流量切换和数据移植过程中，不影响客户正常交易与查询，实现整个过程对客户无感知",null,"胡峥/80374119","对比文件1（CN111930741A）公开了一种数据库分库方法、装置及交易请求数据读写系统，该方法包括：以预设的数据库指标，对多个数据库进行监听，得到多个数据库的指标数据；所述数据库指标用于显示数据库的性能和执行业务的状态；在任一数据库的任一指标数据超出预设数据范围时，从预设的分库类型中，选出对应该指标数据的分库类型；其中，分库类型包括不同指标数据对应的数据库分库类型，用于为数据库进行不同类型的分库；以选出的分库类型，重新对数据库分库。本发明可根据数据库的指标数据，动态进行数据库分库，在任一指标数据超过预设阈值时，可重新对数据库分库，实现了数据库分库类型的灵活切换，与现有技术对比，不需临时增加硬件，节约了成本。","与对比文件的区别在于，本案按照客户转让的标的编号进行分库，客户交易跟随标的\n2、通过网关路由逻辑控制客户新进交易逐步切换到分库\n","请补充：1/按照客户转让的标的编号进行分库的详细过程；\n2、通过网关路由逻辑控制客户新进交易逐步切换到分库的详细过程","补充资料后建议申请发明专利","发明","苗广冬"]
[5,"零售应用研发中心/信用卡开发团队/信用卡客户经营开发二室(杭州)","前端功能配置化解决方案","通过识别页面的语法树和元素结构，提供配置化修改埋点字段配置和操作顺序与取值，减少埋点成本，提高操作效率，从监控和执行两个方面提升复杂操作页面的使用效率。","提升前端自动化配置程度，降低开发成本和使用成本，提高复杂页面使用效率。",null,"杨晨/80280498","对比文件1（CN112799946A）提供一种埋点和数据采集方法、设备及存储介质。在本申请实施例中，可显示针对网页显示针对网页进行操作的多个页面行为；响应于针对多个页面行为的选择操作，显示被选中的目标页面行为的埋点参数；用户可自主设置目标页面行为的埋点参数值；对于计算机设备来说，可根据目标页面行为的设置顺序及目标页面行为对应的埋点参数值，生成对网页所在的应用进行埋点的行为路径；并至少基于行为路径，生成埋点用文件，进一步，在用户访问应用时，可将埋点用文件提供给发起访问请求的客户端，客户端便可至少按照行为路径对应用进行埋点。本申请实施例中，开发人员可根据测试需求，灵活配置埋点，有助于提高埋点灵活性。","本案与对比文件1的区别在于：通过识别页面的语法树和元素结构，配置化修改埋点字段配置和操作顺序与取值。","请补充：1，结合页面图，阐述通过识别页面的语法树和元素结构，配置化修改埋点字段配置和操作顺序与取值的详细过程；                         2，结合执行过程，分析如何产生“减少埋点成本，提高操作效率，提升复杂操作页面的使用效率”的效果的。","补充资料后建议申请发明专利","发明","苗广冬"]
[6,"零售应用研发中心/投资理财团队/投资业务四室","基于双活模型应用高保障方案","主要发明点：\n1）在按照特定标志分库基础上，新增逻辑分组，分组内的分库随机多活。但为了问题排查确定性，在随机多活的基础上，固定分库因子，即分组热备模式\n2）支持灰度验证场景灰度样本支持在线新增，实现平稳验证。\n3）支持动态扩库\n4）以上1）2）3）均为配置式\n与现有技术区别：\n1）灰度验证样本可以在线新增，增加验证充分性\n2）新增分组分库热备概念，不仅在支持应用高可用的前提下，还大大降低了事后问题的排查困难","解决技术问题：\n1、解决个别库宕机的情况下，能够较快切流到备库，提升应用对外服务能力，增加应用高可用。\n2、解决生产验证样本固定，导致验证不全面问题。在线扩展灰度验证样本，使验证广度更深更充分，发布更有信息\n3、支持在线扩库，对于有突发冲击事件，需要分担流量，可进行动态在线扩库\n\n\n预计达到的效果：\n数据库异常场景，能较快恢复对外服务能力，在提升应用高可用性的前提下，不增加排查问题的难度，更好地支持灰度发布，使验证更充分，可以动态进行在线扩库应对冲击性事件。",null,"李娜/80274463","对比文件1（CN113111070A）提供了一种基于分组进行数据分库分表的方法，所述方法为：步骤S1、设置一分组概念，即组中包括多个的分库和多个的分表的集合，每个组均对应多个的订单库，每个订单库均对应多个的订单表；步骤S2、根据数据范围，将数据进行定位分组；步骤S3、分组后，根据哈希取模的方式进行定位到具体的订单库；步骤S4、根据数据的ID范围进行定位到具体的订单表，从而完成分库分表操作；能更加充分地利用服务器的性能。","与对比文件1相比，本案的区别在于：分组内的分库随机多活，固定分库因子。支持灰度验证场景灰度样本支持在线新增。动态扩库;","请补充：1，多个分库进行分组的详细过程，以及组内分库随机多活的设置过程。 2，分库宕机的情况下，切流到备库的流程。3、在线扩展灰度验证样本的验证过程；4、在线扩库的详细过程。\n","补充资料后建议申请发明专利","发明","苗广冬"]
[7,"零售应用研发中心/投资理财团队/投资业务四室","多应用多实例序列号唯一生成方案","主要发明点：\n1）为每个实例命名，每个实例都会去监控中心注册或注销实例，来获取自己的编号，保证唯一性\n2）引入资源池技术器概念，采取轮盘度转法，解决单实例并发时资源竞争问题。\n3）引入进制转换，大大降低序列码位数。\n与现有技术区别\n1）位数比雪花算法64位少很多，引入了36进制换算\n2）有监控中心，保证序列的可控性。","解决技术问题：\n1、解决应用迁移等，多应用序列号重复性问题\n2、解决当前序列号位数码过长问题\n\n预计达到效果\n多应用多实例保证应用实例唯一性。",null,"李娜/80274463","未检索到通过计数器进行多应用实例序列号生成的相关技术。",null,"请补充:多应用多实例的序列号生成的详细过程。","补充资料后建议申请发明专利","发明","苗广冬"]
[8,"零售应用研发中心/零售客户经营开发团队/零售信息应用开发二室(杭州）","历史资产中台质量保障方案","主要发明点：\n1.事前备份：最小代价全链路数据冗余备份，定制化修数通道，\n2.事中跟踪：自定义监控预警及渠道端差异化输出，快速定位问题\n3.事后回检：抽样实时数据进行落地，与日终数据进行数据准确性对比。因场景的复杂性，涉及交易抹平、净值抹平、汇率抹平、数据缓存等相关技术问题解决。\n通过上述闭环保障，极大程度上发现问题，提升数据质量及运维效率，降低运维成本。\n\n与现有技术区别：\n1.现有告警解决方案是现场定位运维并跟踪解决，本提案常规问题直接自动输出原因，运维效率提升高。\n2.提案采用一种历史与实时对比的方案进行数据采集校验，并解决相关技术问题，最大限度识别生产误差。","解决的问题：\n1.历史资产中台数据质量的保障及恢复\n\n预计达到的效果：\n1.自动化识别线上问题，缩短运维时长\n2.自定义回检系统，通过闭环最大化实现数据质量的监控及保障",null,"周逊/80374833","对比文件1（CN104636352A）公开了一种基于质量戳的SCADA系统历史数据补数与查询处理方法，属于计算机技术领域。利用SCADA系统中数据的质量戳域标识系统通信中断的状态，SCADA系统服务器端根据中断时间从前置通信设备存储的历史数据中召唤中断缺失数据，实现基于质量戳的历史数据补数处理，并在客户端进行历史数据查询时，将历史数据基于质量戳进行插值处理并返回给客户端，使处理的结果能够正确反映通信中断时间内的数据值与状态，为SCADA系统监控提供真实、准确的数据。","与对比文件1的区别在于，本案包括事前备份/事中跟踪/事后回检三个质量保障过程。","请补充：1，事前备份的详细过程；\n2.事中跟踪的详细过程；           3.事后回检的详细过程。","补充资料后建议申请发明专利","发明","苗广冬"]
[9,"零售应用研发中心/零售基础开发团队/基础开发一室","一种自定义的企业红包金额分配方案","主要发明点：\n本方案提出在企业发放红包时，支持企业在一个红包活动中自定义组合指定金额红包和随机金额红包的发放形式，并且支持个性化的设置各类红包数量和设置随机金额的上限和下限，通过该方案增加了企业红包活动的丰富性，提高了用户体验，解决了传统红包活动金额分配方案单一问题。","解决问题：\n1-传统红包活动金额分配方案单一问题",null,"熊山毓","对比文件1（CN106157005A）关于一种红包金额的分配方法及装置，其中，方法包括：根据红包总金额和人数计算平均红包金额；确定所述平均红包金额对应的最大红包金额和最小红包金额；根据所述最大红包金额、所述最小红包金额、所述人数和所述红包总金额，为每个用户分别分配对应的红包金额，其中，每个用户对应的红包金额小于或者等于所述最大红包金额且大于或等于所述最小红包金额。通过该技术方案，保证每个用户的红包金额不会过多或者过少，解决了以往红包算法不灵活的问题，可以控制生成的红包的金额不会超过一定的范围，为用户提供最大的灵活性和可控制性，提升用户的使用体验。","区别在于：随机金额红包，指定金额红包以及特殊金额红包的组合。",null,"不建议申请。                                        对比文件1公开了设置随机金额的上限和下限，指定金额红包以及特殊金额红包均为现有技术，在此基础上，将三者进行组合形成一个组合红包，是本领域技术人员很容易想到的，因此，本案新创性较低，不建议申请。",null,"苗广冬"]
[10,"零售应用研发中心/零售基础开发团队/基础开发一室","分布式环境下的数据实时同步及异常监测告警方案","主要发明点：\n本发明提出一个在分布式环境下跨数据库、跨集群实时同步数据的可靠方案；旨在解决数据跨库、跨集群同步延迟、丢失等典型问题，通过有效的数据核对机制确保数据同步的正确性，同时兼具数据异常监测告警能力。","解决分布式环境数据跨数据库、跨集群同步延迟、丢失等问题，数据异常监测告警。",null,"王诗宇","对比文件1（CN103825930A）公开了一种分布式环境下的实时数据同步方法，该方法首先建立分中心实时数据中心和总中心实时数据中心，采集数据实时交换进入数据中心，按配置存入数据中心的融合库、落选库；然后同步总中心和分中心的数据，在同步过程中，分中心负责发起同步操作及维护历次同步操作间的增量一致性，总中心负责响应分中心发起的同步及按照配置完成同步过程；应用本发明的方法，可有效解决分布环境下各部门实时数据不一致导致的冲突及业务无法运作等问题，同时该方法可以提高数据同步的准确性及效率。","与对比文件相比，本案的区别在于：跨数据库、跨集群实时同步数据的方式不同。","请补充：1,分布式环境下跨数据库、跨集群实时同步数据的详细过程；2，数据同步过程中重要数据核对的过程；3日终全量数据核对的过程.","补充资料后建议申请发明专利","发明","苗广冬"]
[11,"零售应用研发中心/零售基础开发团队/基础开发七室(成都)","一种基于缓存的多数据源分页查询方法","主要发明点:\n在使用定长报文格式的系统中,因分页接口的长度不可变,本发明使用缓存,解决多数据源分页查询过程中无法记录多数据源查询位置的问题","在使用定长报文格式的系统中,报文解析依赖于接口长度,如果生产环境时刻有交易,新增接口字段或修改字段长度将导致接口长度变化,导致报文解析失败.\n在使用上述格式的查询系统中,当查询的数据源个数扩展时,分页接口因长度限制无法记录所有数据源的当前查询位置,导致无法实现分页查询,本发明引入缓存,使用缓存保存多数据源的当前查询位置,在不修改接口总长度的基础上实现多数据源的分页查询",null,"党文杰","对比文件1（CN117370476A）提供了一种支持多数据源排序的数据分页查询方法，其特征在于，包括：\n根据预接收的数据分页查询请求确定数据源标识、排序字段、起始偏移量以及查询数据量；\n根据预生成的接口模版从多个数据源中获取对应数据；\n按照所述数据源标识、排序字段、起始偏移量、查询数据量以及预设的每页数据量对所述对应数据进行整合，以生成整合结果；\n根据所述整合结果对所述多个数据源中的数据进行分页查询。                     4.根据权利要求1所述的数据分页查询方法，其特征在于，在根据所述整合结果对所述多个数据源中的数据进行分页查询之前，还包括：\n根据预设时间以及随机数生成缓存时间；\n将所述整合结果在缓存中存储至所述缓存时间。","对比文件1公开了将数据源的标识以及起始偏移量在缓存中存储。本案缓存的是数据源的位置信息。",null,"由于对比文件1数据源的标识以及起始偏移量，即本案已被对比文件1所公开，在此基础上，不建议申请。                       建议发明人老师可根据对比文件进行相应的修改，下次再提。",null,"苗广冬"]

{"sheet":"5.6-5.17","index":8,"n_rows":13,"n_cols":13,"rows_kept":13,"cut":false,"hidden":false,"merged":[[0,0,0,6],[0,7,0,12]]}
["发明人填写",{"$nulls":6},"代理人填写"]
["序号","中心/团队/室","专利名称（暂定名称）","主要发明点/方案简述及与现有技术的区别","解决的技术问题及预计达到效果","所属技术领域","发明人","检索的最接近对比文件","检索分析\n（与对比文件相比的区别点）","待发明人补充内容\n（挖掘现场代理人提出需要发明人补充的内容）","检索结果\n如：补充内容后建议申请XX专利\n建议拆分专利（说明拆分内容）\n不建议申请，说明原因","建议申请类型","检索人"]
[1,"零售应用研发中心/零售基础开发团队/基础开发四室","一种大数据量清算批处理解决方案","主要发明点：\n基于清算系统数据量大的特点，发明了分布式批处理调度系统，根据调度系统配置的路由因子进行文件、批量数据的拆分，并自动生成处理任务，对数据进行对账、累算、核对、清分处理。","解决清算系统单点数据量过大，处理效率慢的问题",null,"郑柳东/80374080","CN105912401B 一种分布式数据批处理系统和方法","对比文件公开了一种分布式数据批处理系统和方法，该系统和方法中，主节点中的任务扫描模块能够计算每个任务的耗重，并且主节点中的任务调度分发模块能够根据单批次任务列表中的任务耗重、服务节点列表中的队列长度描述和耗重速率，计算得到分配到各个服务节点上的任务之间的特定任务耗重分配比例，该特定任务耗重分配比例能够使各个服务节点的资源得到充分利用并且使各个服务节点处理完分配到自身任务所消耗的时间基本一致。因此，按照该特定任务耗重分配比例将任务分配给各个服务节点，能够使得各个服务节点在处理这些任务时，其各自资源均得到充分利用，不会造成资源的浪费，并且各个服务节点能够基本上同一时间点处理完分配到自身的任务。\n对比文件与本申请的主要区别在于其应用场景和调度机制。对比文件公开的是一个通用的分布式数据批处理系统和方法，其焦点在于根据任务的耗重和节点的资源状态进行任务调度，以优化资源利用和处理时间。而本申请则专注于清算系统，针对清算系统数据量大的特点，发明了分布式批处理调度系统，并引入路由因子进行文件和数据的拆分，自动生成处理任务。因此，本申请更具针对性，解决了清算系统特有的问题。","本申请方案内容中关于清算系统的分布式批处理调度系统，可以进一步补充以下细节：首先，明确路由因子的具体配置方法和策略，例如如何根据历史数据、系统负载等因素动态调整路由因子；其次，详细描述文件和数据拆分的具体过程，包括如何根据路由因子将数据划分为不同的批次或子集；再次，阐述自动生成处理任务的逻辑和规则，包括任务的类型、优先级、依赖关系等；最后，可以考虑如何通过监控和日志记录等手段，确保分布式批处理系统的稳定性和可靠性。","建议申请发明专利","发明","孙德龙"]
[2,"零售应用研发中心/零售基础开发团队/基础开发四室","一种分布式多数据源数据可靠准实时同步异构多系统方案","主要发明点：\n解决复杂环境分布式场景下多个数据源准实时同步异构多系统的可靠性问题。\n通过使用准实时中间件和基于时间分片的异步兜底核对机制保证数据最终一致性。\n\n与现有技术的区别：\n1.核对源数据有轻量级的读操作，避免对源数据源有额外的写操作，也不需要将源数据进行搬迁融合或设置是否已同步等重型IO操作。\n","解决数据同步最常见的丢数问题,保证数据最终一致性",null,"汪郧/80302821","CN117708148A 一种数据同步方法、数据同步装置及存储介质","对比文件公开了一种数据同步方法、数据同步装置及存储介质，用于数据同步技术领域。该方法包括：获取源数据库的数据变更日志；对同步到第三方数据库的数据进行一致性修复，以使在第三方数据库中删除源数据库中所有发生变更的数据；基于数据变更日志，对第三方数据库中修复后的数据进行增量同步，以使增量同步后第三方数据库中包含源数据库中所有变更后的数据；通过对同步到第三方数据库的数据进行一致性修复，在第三方数据库中删除源数据库中所有发生变更的数据，再通过增量同步，即可实现源数据库与第三方数据库的数据一致性，无需在全量同步时对源数据库进行加锁，确保了源数据库的正常运行。\n对比文件与本申请在数据同步的方法和目标上有所不同。对比文件主要关注的是在数据同步过程中，如何通过一致性修复和增量同步来确保源数据库与第三方数据库的数据一致性，同时避免在全量同步时对源数据库进行加锁。而本申请则专注于解决复杂环境分布式场景下多个数据源准实时同步异构多系统的可靠性问题，通过引入准实时中间件和基于时间分片的异步兜底核对机制，确保数据最终一致性，且其核对源数据的方式更加轻量级，避免了额外的写操作和重型IO操作。","补充准实时中间件的架构和工作原理，包括其如何实时捕获数据变更、缓存变更数据，并如何将这些变更数据异步地同步到目标系统；详细描述基于时间分片的异步兜底核对机制的具体实现，包括如何根据时间分片对源数据和目标数据进行比对，并如何处理比对结果中的差异；如何通过监控和日志记录等手段，确保数据同步过程的稳定性和可靠性，以及如何处理可能出现的异常情况。","建议申请发明专利","发明","孙德龙"]
[3,"零售应用研发中心/零售基础开发团队/基础开发四室","一种基于大模型的告警分析辅助方案","主要发明点：通过搭建知识库收集历史告警与相关系统信息，利用大语言模型的分析与生成能力，在系统发出告警时通过提取告警实体借助相关知识分析可能原因及生成解决方案建议。","辅助开发人员在系统发生告警时定位及处理问题",null,"尚碧瑶/01190636","CN117544397A 基于大语言模型的告警日志分析方法及系统","对比文件基于大语言模型的告警日志分析方法及系统，涉及人工智能技术领域，通过预处理确保告警日志的一致性和可用性，利用大语言模型研判告警日志的风险值，如果风险值超过阈值，判断为入侵威胁事件，并生成处置建议，安全运营人员对入侵威胁事件进行处置，将处置结果反馈至大语言模型进行实时增量训练，定期学习历史运营分析报告内容，生成离线大语言模型模型，以热启动方式更新预设的大语言模型，以此，通过大语模型处理海量告警日志，解决了处理告警日志效率低下的问题，本发明适用于告警日志分析。\n对比文件与本申请在利用大语言模型处理告警日志上虽有相似之处，但侧重点不同。对比文件侧重于告警日志的风险研判和入侵威胁事件的处置，通过实时增量训练大语言模型以提升其处理告警日志的效率。而本申请则专注于通过搭建知识库收集历史告警与相关信息，利用大语言模型在系统告警时分析原因并生成解决方案，辅助开发人员定位及处理问题。本申请更侧重于通过知识库和告警实体的结合，提高告警处理的准确性和效率。","详细描述知识库的构建过程，包括如何收集、整理和分析历史告警与相关系统信息，以及如何建立告警实体与知识库中信息的关联；阐述如何利用大语言模型对告警实体进行深度分析，并结合知识库中的信息，生成针对性的解决方案建议；考虑如何根据开发人员的反馈不断优化和完善知识库，提升大语言模型在告警处理中的准确性和实用性。","建议申请发明专利","发明","孙德龙"]
[4,"零售应用研发中心/零售基础开发团队/基础开发一室","一个基于开放组件的轻量批处理管理方案","主要发明点：\n以quartz批处理、Kafka消费等组件为基础，提供轻量的批处理集合管理功能，支持跨组件依赖关系管理、启用停用设置、咨询作业重试和中止，以及查看执行日志等。","解决的问题：原生云应用开发时，开发人员按需使用各种开放组件处理批处理业务（定时作业、Kafka作业等），这些组件都能支持业务功能处理，但是存在管理功能较弱、可视性较差等问题。\n\n预计达到的效果：提供轻量的批处理作业管理功能，业务应用引入依赖后做简单修改即可获得较为完整的管理能力，实现步骤依赖关系管理、步骤启停设置，执行作业重试、中止等，并支持执行状态可视化、执行告警、执行结果登记查询、执行总览报表等。",null,"何华创/80074315","未找到相关对比文件","未找到相关对比文件，请根据方案内容撰写交底书后供代理人进一步检索","对于本申请方案内容的细节补充，可以聚焦于现有功能的具体实现和细节优化。例如，在跨组件依赖关系管理方面，可以详细说明如何设置和查看任务之间的依赖关系，包括依赖链的可视化展示和依赖冲突的解决策略等（视方案具体情况而定）。在执行日志查看方面，可以进一步补充日志的分类、筛选和导出功能，以便用户更便捷地分析和利用日志数据。此外，对于作业重试和中止操作，可以具体描述其触发条件和操作流程，确保用户能够精准控制作业的执行状态。","建议申请发明专利","发明","孙德龙"]
[5,"零售应用研发中心/零售基础开发团队/基础开发一室","一种基于布隆过滤器的风险反诈防控方案","主要发明点：\n本发明提出一个在分布式环境下实时进行转账交易反诈拦截的可靠方案；旨在解决如何在不影响交易系统性能的情况下，在海量交易中精准匹配涉诈交易的问题。通过提前对大量可疑账户生成布隆过滤器并推送到所有交易服务器上，赋予交易流程中快速过滤正常交易的能力，并对疑似命中涉诈交易进行进一步的涉诈交易识别和拦截。通过该方案，在不影响性能的情况下(前后平均响应时间误差在1%以内)，达到了对全量转账交易进行反诈防控的效果。","不影响交易系统性能的情况下，对海量交易进行精准的反诈防控",null,"余思佳/80275046","CN109446276B 基于关系数据模型的订单拦截方法、装置、设备及介质","对比文件公开了一种基于关系数据模型的订单拦截方法、装置、设备及介质，包括：获取员工的职员基本信息和职员亲属信息，基于员工的职员基本信息和职员亲属信息，形成一级关系网络，基于员工之间的亲密度，将相应的职员基本信息建立二级关系网络，基于一级关系网络和二级关系网络，建立关系数据模型，获取风险订单，获取交易对象信息的关系对比度，判断风险订单是否违规，若风险订单违规，则调用拦截接口对违规的风险订单进行拦截。通过将职员基本信息和职员亲属信息之间以及职员基本信息之间进行关联，以建立关系数据模型，使得关系数据模型覆盖范围更大，从而便于对违规的风险订单进行查询和拦截，提升了风险订单拦截的效率。\n对比文件主要侧重于利用关系数据模型对订单进行拦截，特别是基于员工和职员亲属信息建立的关系网络来识别风险订单。而本申请则聚焦于分布式环境下的转账交易反诈拦截，通过布隆过滤器实现海量交易的快速过滤和涉诈交易的精准识别。两者在应用场景、数据模型和拦截策略上存在显著差异。","本申请中提到的“提前对大量可疑账户生成布隆过滤器并推送到所有交易服务器上”这一步骤，可以进一步补充布隆过滤器的生成频率和更新机制，以确保数据的实时性和准确性。同时，可以详细阐述涉诈交易识别过程中的算法或策略，以及拦截接口的具体实现方式，如拦截后的通知机制、数据记录等，使方案更加完整和可操作。","建议申请发明专利","发明","孙德龙"]
[6,"零售应用研发中心/网络应用开发团队/互联网运营开发一室(杭州)","一种基金产品组合策略回测解决方案","主要发明点：\n1、方式灵活：支持3种方式（手动构建、基金配置、自上而下）构建基金组合，满足投资者多类需求\n2、智能计算：通过大类配置模型、权重配置优化模型等工具，智能化生成组合中基金产品的权重，并支持调整\n3、实时回测：构建分布式、高并发、可容错的组合回测计算平台，保证回测计算平台的高可用性，建立长连接实时返回回测数据计算进度和回测指标数据结果，并提供多维度的组合分析\n\n与现有技术的区别：\n在方式的多样性、模型的智能性、回测结果的及时性和准确性上，本方案具有明显的优势。\n1、目前市面上的回测方法大多针对单个金融产品，不支持对基金产品组合进行回测分析\n2、不仅支持用户自定义组合产品权重，还支持多种策略目标下的多种资产配置模型智能化构建产品权重\n3、分布式架构和长连接通讯保证回测平台的高可用性，快速提供准确且全面的组合分析结果","解决的问题：\n针对输入的基金产品池，通过大类配置模型、权重配置优化模型等工具计算参考调仓权重，基于调仓时间、持仓配比等设置，通过高度准确的历史市场数据，模拟近似真实的投资交易过程，以可靠的结果呈现丰富专业的回测指标数据报告，通过组合的历史表现情况衡量投资策略的风险和收益，为用户提供投资参考。\n\n预计达到的效果：\n能够支持多种投资策略的分布式、高并发、可容错基金组合回测计算平台，以便于投资者评估策略有效性、辅助投资决策。",null,"张国民/80234782","CN106067083A 基于海量金融数据的智能投资系统数据处理方法","对比文件公开了基于海量金融数据的智能投资系统数据处理方法，步骤包括：金融产品交易的历史数据存入数据库；所述历史数据序列平稳化处理；使用图表分析模块对处理后的历史数据进行结果统计、得出所投资的金融产品的种类、投资金额与其收益的相对应图表；根据选择的金融产品种类和投资金额构建金融产品的收益模型；运行构建的模型；仿真软件根据构建的模型得出购买的金融产品种类和最大的收益额。本发明根据构建的模型和仿真软件的计算结果，得出准确的收益值，避免了只考虑历史数据进行金融分析预测的僵化性，确保用户在交易过程中能够获取最大的收益和最小的风险。\n本申请与对比文件的主要区别在于其提供的投资辅助工具的功能性和灵活性。对比文件主要侧重于基于海量金融数据的智能投资系统数据处理方法，该方法通过历史数据分析构建收益模型并预测最大收益。而本申请则专注于基金组合的构建与回测分析，不仅支持多种方式构建基金组合，还通过智能计算工具和实时回测平台，为投资者提供更为灵活和全面的投资策略评估工具。此外，本申请还强调了分布式架构和长连接通讯技术的应用，确保了回测平台的高可用性和回测结果的准确性。","关于基金组合回测计算平台的细节可以进一步补充。例如，可以详细描述分布式架构的具体实现方式，包括如何确保数据的一致性和高并发处理的能力；还可以说明长连接通讯技术的应用如何降低通讯延迟和提高数据传输效率。此外，关于回测指标数据报告的生成，可以进一步说明报告中包含的具体指标和数据维度，以及这些指标如何帮助投资者评估投资策略的有效性和风险。最后，对于投资策略的评估和辅助投资决策的过程，可以给出具体的案例或示例，以更直观地展示本申请的应用效果。","建议申请发明专利","发明","孙德龙"]
[7,"零售应用研发中心/投资理财开发团队/投资业务七室(成都)","一种产品定价自动测算解决方案","主要发明点：\n1、贵金属定价系统自动化测算（针对于浮动产品及固定产品）提供产品价格测算，计算其：运保费、中收率、加价率、手续费、产品每克售价等\n2、提供价格测算横向对比，通过测算结果勾选需要对比结果，快速横向对比，获取随着零售价\\零售加价变动其中收率、加价率、产品每克售价等变化关系\n\n\n与现有技术区别：\n1) 避免人工核对的风险：通过系统录入基础数据，及可视化的定价测算管理，避免了人工取数、人工计算的误差和风险\n2) 价格可视化管理：通过系统可视化管理各种集采价格目录，方便随时存储和查看，同时针对数据能够多次测算，通过不同测算历史结果进行对比，达最佳预期销售价格。\n","本产品主要针对现有黄金价格测算复杂，人工测算慢，容易出错，试算成本高等问题，通过智能匹配测算及分区计算方式，快速采集价格，并对黄金产品进行价格测算个完整解决方案。",null,"周鹏/80328122","无相关方案","本领域多见贵金属价格预测的相关方案，根据已有数据进行各种费率或数据的计算属于常规技术手段，故未见相关申请",null,"不建议申请，单纯的贵金属价格及相关数据计算，借助计算机实现自动化测算这一手段比较常规，准确且快速的数据计算借助计算机和常规设置自然而然可以做到，可以考虑将方案更改为价格预测或价格分析方法，基于规则/策略的预测或分析，基于模型，基于大数据的价格预测或分析都可形成技术方案。","发明","孙德龙"]
[8,"零售应用研发中心/投资理财开发团队/投资业务七室(成都)","一种基于基金产品概要文件的参数自动检测及修正方案","发明点：本发明基于基金产品概要文件，利用XML解析技术实现准实时的系统自动化识别基金产品参数，与系统参数做对比后，对差异参数可以自动化进行调整，解决因参数错误带来的风险以及降低产品参数管理的运营成本。\n\n与现有技术的区别：目前市场上大多是靠线下人工收集变化，人工进行系统参数调整","解决的问题：基金公司变更产品信息发布概要文件后，代销机构无法及时感知产品参数的变化，从而无法及时作出调整，可能存在影响产品管理、客户交易以及手续费管理等风险。\n \n预计达到的效果：基金公司发布新的产品概要后，代销机构能够及时完成参数变化解析，并自动化完成参数的调整",null,"马灯灿/80256950","无对比文件","对概要文件进行识别，获取基金产品参数，与系统参数做对比后，对差异参数自动化进行自动化调整，未见相关对比文件公开","补充方案具体实现细节，如何利用OCR文件识别以及XML解析技术实现准实时的系统自动化识别基金产品参数，以及如何进行产品参数的调整，方案完整后做进一步评估","建议补充交底书后进一步检索是否有申请必要","发明","孙德龙"]
[9,"零售应用研发中心/信用卡开发团队/信用卡支付开发室","应用异常检测降级处理机制","问题：\n作为金融服务提供方，授权系统需要24小时稳定提供服务，而实际场景下，很可能由于数据库宕机等极端场景导致应用服务不可用，导致对客业务中断，对我行业务、声誉造成极大影响。\n解决方案：\n（1）增加无状态网关层，集群式部署，单一节点宕机不会对整体造成影响\n（2）网关层通过分布式锁选举探测主节点，通过接口健康探测、系统级成功率的方式对下游应用进行异常检测。\n（3）通过读库 + 极少数据临时存储数据库的模式，同等搭建与主库逻辑相同的降级处理应用\n（4）网关层在检测到下游系统应用异常后，自动将交易由主库应用切换到降级处理应用进行处理，保障业务不中断、可靠运行\n（5）待主库应用恢复正常后，降级处理应用将异常期间发生的交易重发主库应用，主库应用做简单处理后，将数据落到主库","解决数据库等极端情况下，仍能保证授权系统稳定可靠的对外提供服务",null,"林泽鹏/80280410","CN117540325B 基于数据变化量捕获的业务数据库异常检测方法及系统","对比文件涉及数据异常检测技术领域，具体涉及基于数据变化量捕获的业务数据库异常检测方法及系统，本发明根据用户的每个数据操作类型的业务使用变化值的变化情况以及不同用户之间业务使用变化值的整体相似情况，得到参考显著程度；结合当前采样时刻下的参考显著程度的相对差异以及时序差异，得到调整必要性；进一步地对根据调整必要性筛选出调整数据操作类型的业务使用变化值通过对应的调整必要性进行加权，输入到LOF算法后得到更加准确的加权局部离群因子，使得根据加权局部离群因子筛选出实际异常用户更加准确，也即对业务数据库异常检测效果更好。\n本申请主要关注的是在金融服务提供方背景下，如何通过系统架构设计和异常处理策略来保障授权系统在数据库宕机等极端情况下的稳定服务。它强调的是通过无状态网关层、分布式锁选举、接口健康探测等技术手段来实时检测和处理潜在的系统异常，确保业务的连续性和可靠性。而对比文件则侧重于数据异常检测技术领域，特别是通过用户数据操作的变化情况和相似度分析，结合时序差异来检测业务数据库中的异常用户。两者在技术领域和解决问题的方式上存在显著区别。","根据方案实际情况补充实现方式及细节即可","建议申请发明专利","发明","孙德龙"]
[10,"零售应用研发中心/信用卡开发团队/信用卡支付开发室","一种多分库的对账批处理方案","问题：\n交易对账是确保资金交易一致性的必要手段，随着交易类型、交易量的不断增加，批量对账处理的效率及对账功能可维护性、可扩展性要求也逐步提高，在分库架构下对账处理还面临多分库并行处理控制、异常恢复等问题。\n解决方案：\n（1）自研对账批处理框架，结合动态数据源管理实现分库对账并行化，极大提升对账效率；支持数据库的横向扩展，增加分库只需添加分库配置即可\n（2）基于领域驱动设计思想抽取对账业务核心逻辑，分离技术和业务复杂度，应用层和领域层提供丰富的业务逻辑扩展点，方便不同类型交易对账逻辑扩展和定制化\n（3）对账健壮性及异常恢复增强，逐笔核对交易过程中记录对账差错的临时信息，后对差错情况进行合理性检查，检查通过后才基于对账结果更新本地状态，以避免对账数据异常误更新本地交易数据，该过程若因异常中断，支持重试并从中断处继续处理","解决分库架构下批量交易对账处理效率及可扩展性、健壮性和异常恢复等问题，保障了对账高效稳定运行",null,"张浩清/80234875","CN113450220A 一种基于分散批处理的处理方法和装置","对比文件公开了一种基于分散批处理的处理方法和装置，涉及计算机技术领域。该方法的一具体实施方式包括：对账户数据进行联机交易处理；对账户数据进行分散批处理，并且在分散批处理期间，对账户数据进行联机交易处理；进行联机日切，同步联机交易所使用的数据快照以及批量处理所使用的数据快照，并且在数据同步期间，对账户数据进行联机交易处理；进行批量日切，基于批量处理所使用的数据快照进行卸数。该实施方式能够解决批处理耗时长导致影响用户体验的技术问题。\n本申请与对比文件的主要区别在于，对比文件专注于分散批处理和联机交易处理的技术实现，旨在解决批处理耗时长对用户体验的影响。而本申请则专注于解决分库架构下批量交易对账处理的问题，包括对账效率、可扩展性、健壮性及异常恢复等方面。本申请通过自研对账批处理框架和基于领域驱动设计的思想，实现了对账业务的高效稳定运行和灵活扩展。","在本申请的解决方案中，可以进一步补充对账批处理框架的具体设计和实现细节，如框架的架构图、核心组件的功能描述、数据流的走向等。此外，对于领域驱动设计思想的实践，可以详细描述如何根据业务场景抽取对账业务核心逻辑，以及如何在应用层和领域层提供业务逻辑扩展点的具体实现方式。","建议申请发明专利","发明","孙德龙"]
[11,"零售应用研发中心/信用卡开发团队/信用卡客户经营开发三室(杭州)/征审一组","基于Redis失效监听的业务流程消息可靠消费方法","随着业务系统对于时效性及并发性需求的提升，业务流程消息队列脱颖而出。与传统的批次任务处理模式相比，它在极大的提升处理时效的同时，还增强了系统的灵活性及可扩展性，但消息队列也面临着故障场景下无法确保可靠消费的问题。\n目前的业务流程消息队列确保可靠消费的方法一般是采用持久化消息、镜像队列方法。但消息队列采用定时刷盘的持久化策略，如果在刷盘期间发生故障仍然会面临消息丢失无法恢复的问题。","本发明基于Redis失效监听和动态代理技术，采用被动监听的方式检索遗漏的业务流程消息并发送至运维平台，运维人员依据流程链路及修复建议执行重新投递或忽略异常操作，提升了问题的处理时效也避免了误筛、漏筛风险。\n本发明相比持久化消息、镜像队列方法，在消息队列整体彻底故障的情况下仍然能确保消息不丢失，对于高风险重要业务，避免了消息丢失导致的客诉及资损风险。此外，自动化的异常告警在提升处理时效的同时也避免了误筛、漏筛的风险。",null,"孙天骁/80291166","CN114331782A 业务流程监控方法、装置、设备及介质","对比文件公开了一种业务流程监控方法、装置、设备及介质，获取基于业务流程中初始任务产生的任务缓解信息；对任务缓解信息进行监听，确定任务缓解信息中状态消息的完成情况；若状态消息的完成情况为完成，则确定初始任务已完成，对初始任务进行标定，得到第一标定结果；获取基于业务流程中目标任务产生的新的任务缓解信息，并执行对任务缓解信息进行监听，确定任务缓解信息中状态消息的完成情况的步骤，直至确定目标任务已完成，对目标任务进行标定，得到第二标定结果；根据第一标定结果与第二标定结果对业务流程进行标定，得到并展示第三标定结果。本申请可以实现对业务流程的监控，便于对业务流程进行溯源，提高业务流程的处理效率。\n本申请与对比文件的主要区别在于处理业务流程消息队列的方式。对比文件专注于业务流程的监控和标定，通过监听任务缓解信息来实现对业务流程的溯源和效率提升。而本申请则针对业务流程消息队列在故障场景下无法确保可靠消费的问题，提出了基于Redis失效监听和动态代理技术的解决方案。本申请通过被动监听的方式检索遗漏的消息，并发送至运维平台，确保了消息在队列故障时仍不丢失，从而提高了处理时效和降低了风险。","无需补充，按现有交底提交即可","建议申请发明专利","发明","孙德龙"]

{"sheet":"5.20-6.14","index":9,"n_rows":9,"n_cols":13,"rows_kept":9,"cut":false,"hidden":false,"merged":[[0,0,0,6],[0,7,0,12]]}
["发明人填写",{"$nulls":6},"代理人填写"]
["序号","中心/团队/室","专利名称（暂定名称）","主要发明点/方案简述及与现有技术的区别","解决的技术问题及预计达到效果","所属技术领域","发明人","检索的最接近对比文件","检索分析\n（与对比文件相比的区别点）","待发明人补充内容\n（挖掘现场代理人提出需要发明人补充的内容）","检索结果\n如：补充内容后建议申请XX专利\n建议拆分专利（说明拆分内容）\n不建议申请，说明原因","建议申请类型","检索人"]
[1,"零售应用研发中心/零售基础开发团队/基础开发七室(成都)","一种多数据源分页查询中的缓存重建方案","主要发明点:\n在多数据源查询过程中,可以使用缓存保存当前多数据源的查询位置,方便后续查询时从各数据源继续向后查询数据,为避免缓存空间无限增长,使用缓存保存多数据源查询位置时必须设置超时时间,如果缓存过期,将丢失各数据源的查询位置,下次查询时客户只能从头开始重新查询.本发明引入缓存重建方法,在缓存过期后,可以根据分页键值重建缓存信息,使得客户可以继续从已查询的位置开始向后查询","解决多数据源查询过程中,缓存过期时客户必须从头开始重新查询的问题,通过缓存重建,使得客户可以在当前查询到的位置继续向后查询",null,"党文杰/80258267","CN118113726A","CN118113726A公开了初始页面查询结果是基于初始查询条件，从初始查询结果集中确定的，初始查询结果集是基于更改由分页查询页面触发的第一预设页面查询请求后得到的初始页面查询请求，从与第一预设页面查询请求关联的第一数据源获取后存储于第二数据源的；在确定缓存中存储的数据源为第二数据源的情况下，基于第二预设页面查询请求，调用目标数据源接口，从第二数据源中获取目标查询结果，其中，目标数据源接口是在初始查询结果集存储于第二数据源的情况下预先配置的。即对比文件公开了基于缓存更新查询的起始参数。但是与本方案中的根据最后一笔流水作为分页键值存在明显区别。",null,"建议申请","发明","彭江峰"]
[2,"零售应用研发中心/信用卡开发团队/信用卡支付开发室","应用读服务高可用方案","问题：\n授权额度应用日均查询交易量约5.8亿笔，峰值13,000TPS。即便秒级异常也会导致大量查询损失，影响客户使用体验。\n解决方案：\n（1）数据库探测：使用数据库探测功能探测主库可用性，使用亮白旗功能探测备库延迟时间。\n（2）数据源切换：主备架构下读应用实例配置了主库的R2节点和备库，两个动态数据源。实例状态正常时，使用默认数据源（主库）；实例状态转为异常时，切换动态数据源主库R2节点；主库R2节点也不可用时，再切换到备库，并对备库进行延迟探测，这样可实现对两个动态数据源的分层降级。\n（3）实例数据源切换实时控管：通过实时开关配置，支持人工切换与系统自动切换以适应计划内和计划外停机。","解决数据库主库极端异常场景下，保证授权额度应用读服务高可用性。",null,"李梦琰/80280581","CN111723066A、CN118113548A","CN118113548A公开了针服务以边车形式运行在pod中，采用就绪探针，根据探测配置，调用探测接口，若数据库实例出现异常，接口返回失败，则代理组件产生通知事件。CN111723066A公开了判断操作日志中是否存在被插入的切换标记；若存在，则停止日志捕获服务，并向目标端数据同步系统发送主备切换命令；目标端数据同步系统在接收到主备切换命令后，将当前未同步事务同步至目标端数据库；将源端数据库切换为备用数据库，将目标端数据库切换为主数据库。即对比文件公开了探针以及主备切换，但是具体切换方案与本方案存在区别，并且对比文件并未公开主数据库R2节点",null,"建议申请","发明","彭江峰"]
[3,"零售应用研发中心/零售客户经营开发团队/零售基础客群经营开发室(成都)","（架构守护）云服务架构问题的量化闭环检测机制","1.全面覆盖重大架构问题，首创云服务中间件故障降级检测机制，准确定位到未降级的代码行，实现云服务故障降级量化检测\n2.基于字节码增强的流量录制与重放机制，实现问题的闭环管理\n3.引入插件化机制，显著降低开发成本\n4. 自研高性能缓存技术，显著提升检测性能","在我行乃至互联网企业中，发生了大量的由于数据库、中间件相关代码设计不规范导致的生产事件。目前行内的云平台仅能在问题出现后感知到，且分散在不同的平台，其他现有的检测工具只能检测出小部分架构问题且准确度难以保证。为了解决此问题，我们自研了首个高准确性、高鲁棒性的开发态系统架构守护框架。",null,"王博闻/80296199","CN104883369A","CN104883369A公开了对包括IaaS层、Paas层和Saas层在内的各层服务架构的递阶层次结构中的安全问题及安全证据进行定性和定量分析；步骤(2)、对云平台各层服务架构的安全性进行评估；步骤(3)、对云平台整体的安全性进行评估，采用基于自适应神经网络的Sugeno模糊推理系统建立一级云安全评估模型，分析云平台整体的安全性。即对比文件是主动评估，本方案能够及时响应问题","建议补充缓存方面的技术细节","建议分案，分为闭环检测过程，还有缓存提升性能的方案","发明","彭江峰"]
[4,"零售应用研发中心/信用卡开发团队/信用卡账务开发二室","一种基于交易特征的账务计算功能验证方法","通过对影响账务金额计算的账务行为进行监听，实现交易特征提取、账务数据自动化采集和存储，在进行账务计算新功能验证时，可以复现还原交易场景，实现以较小的成本完成新功能验证。","银行账务系统提供诸多复杂账务计算服务，在进行功能迭代更新时，为验证新功能有效性及准确性，往往需要大量业务场景进行回归验证。本方案提供一种自动化采集真实交易数据，生成新功能验证案例的方法，能够以较小的存储成本和时间成本还原交易场景，完成新功能的验证",null,"董毅博/80374339","CN114971831A、CN116645184A","CN114971831A公开了联机交易成功且所述联机交易为金融交易时，调起账务拆分；根据交易流水以及账务参数进行账务拆分。CN116645184A公开了用加入的虚拟账务数据，能够补齐业务账务数据与参考业务账务数据之间的差值，得到的更新后的业务账务数据较为准确。利用业务账务数据进行数据分析后得到的分析结果更为准确。即对比文件公开了基于参数特征对数据进行拆分，而本方案包括一个整体的架构，对比文件并未公开本方案其余内容，并且对比文件的数据拆分流程与本方案中不相同。","建议交底书附上沟通时的流程图","建议申请","发明","彭江峰"]
[5,"零售应用研发中心/信用卡开发团队/信用卡账务开发二室","一种长链路批量账务交易处理过程中数据检核方法","批量账务交易处理过程中，以数据库提交事务为单位，进行交易数据收集，以处理任务为核对单元进行数据实时总分核对的任务检核方法","在账务交易处理过程中，由于处理数据量大，业务逻辑复杂，处理链路长，一般采用小批量数据分批、异步处理的方式，由于系统环境等多因素影响，可能导致数据处理过程中出现不可预知的异常。\n为了保证交易处理过程的准确，我们系统采用以数据库提交事务为单位，进行交易数据收集，以处理任务为核对单元进行数据实时总分核对。确保交易批处理过程中，交易数据不重不漏。",null,"乔红光/80274204","CN116883164A","CN116883164A公开了获取目标交易对应的交易数据，其中，交易数据用于表征目标交易完成交易处理后所生成的交易流水信息；依据交易数据确定目标交易对应的核算码，其中，核算码为目标交易对应的账务处理场景的唯一标识信息；依据核算码确定目标交易对应的会计科目，其中，会计科目用于表征与账务处理场景相对应的核算项目；基于会计科目对目标交易对应的交易数据进行会计核算，得到核算结果。但是对比文件与本方案中以数据库事务为交易数据等处理过程存在明显区别。",null,"建议申请","发明","彭江峰"]
[6,"零售应用研发中心/信用卡开发团队/信用卡账务开发二室","一种通用的交易手续费算费模型","交易费用计算模型分为三个模块：费率模块，计算模块，账务模块。模型可以轻松扩展手续费费用类型，计算方式，生效周期等。\n费率模块：开发前端页面，配置各类费用费率，生效范围；\n计算模块：根据需要匹配不同的费率类型，计算不同的费用，可同时多种费用。\n账务模块：记账，冲账，对账，销账；从机构的费用完成记账开始，到机构偿还费用销账，完整的账务周期；","目前很多交易手续费算费模型是耦合严重，每当新增加机构或者新增加手续费类型，都会改动很多代码。修改手续费费率的配置，算费的逻辑，以及账务层面的改动。\n1.解决了算费模型不易拓展的问题；原算费逻辑混合到一起，不能很好的运维拓展。现拆分为三种模块，便于应用到新场景，新机构。\n2.解决了计算复杂的问题；费率模块统一管理费率的生效周期，费率大小等，比采用配置的方式去配置可以应用到更加广泛的场景。\n3.记账结果准确；多步骤验证，跟踪记账结果，避免错误记账的可能。",null,"董明明/80311054","CN113935821A、CN115774545A","CN113935821A公开了接收针对待结算银行业务的手续费的结算请求；其中，结算请求中包括业务类型、银行信息和交易金额；根据业务类型确定手续费类型；基于手续费类型，确定与银行信息对应的至少一个结算策略；每个结算策略中包括针对不同金额的结算子策略；根据交易金额，从结算子策略中选取目标结算子策略；根据目标结算子策略计算得到待结算银行业务应收取的手续费。CN115774545A公开了实现了将主业务流程与手续费交易流程进行解耦，从而无需在主业务流程考虑交易手续费的收取逻辑，只需要关心主业务逻辑实现，交易手续费收取由另一业务流程处理，由此简化了主业务程的处理。即对比文件公开了将结算策略进行封装，还有业务流程剥离等。但是对比文件各个部分并没有分模块执行，与本方案存在本质区别。",null,"建议申请","发明","彭江峰"]
[7,"零售应用研发中心/信用卡开发团队/信用卡账务开发二室","一种基于副本以及隔离的信用卡自扣金额计算公式切换验证比对方法","通过用户副本以及隔离方式，实现信用卡自扣金额计算公式切换量阶段功能，跟账阶段完成全量客户比对分析，流量阶段完成客户逐步可控过渡，最终实现客户计算公式平稳切换，减少人为操作，大幅降低生产运维风险。","随着信用卡业务发展，客户的还款金额计算公式经常需要调整，旧有的调整方式验证需要人工参与多，风险高，曾经引发P3级事故，为了解决自扣计算公式切换高风险问题，设计了一种基于用户副本以及隔离的验证比对方式，将公式切换分为两个阶段，第一阶段为跟账阶段，建立用户副本运行新公式产出结果，与用户旧公式的计算结果进行自动比对，生成差异报表供业务分析调整；第二阶段采用用户隔离方式，将用户规划成若干群体，小部分行内员工群体先切换新公式，观察运行效果，符合预期后，再逐步切换其他群体，最终实现全部客户切入新公式。通过新方式，自扣公式已经平稳变更多次，未出生产事故，同时提升了自动化水平，降低了业务人员工作量，解决了长久以来的痛点。",null,"梁栋/80174850","CN108076242B","CN108076242B公开了在交易时变更多种计费规则，但是对比文件的计费规则不涉及到退款等复杂场景，并且其是简单的函数计算，与本方案完全不同。",null,"建议申请","发明","彭江峰"]

{"sheet":"6.17-7.18","index":10,"n_rows":7,"n_cols":13,"rows_kept":7,"cut":false,"hidden":false,"merged":[[0,0,0,6],[0,7,0,12]]}
["发明人填写",{"$nulls":6},"代理人填写"]
["序号","中心/团队/室","专利名称（暂定名称）","主要发明点/方案简述及与现有技术的区别","解决的技术问题及预计达到效果","所属技术领域","发明人","检索的最接近对比文件","检索分析\n（与对比文件相比的区别点）","待发明人补充内容\n（挖掘现场代理人提出需要发明人补充的内容）","检索结果\n如：补充内容后建议申请XX专利\n建议拆分专利（说明拆分内容）\n不建议申请，说明原因","建议申请类型","检索人"]
[1,"零售应用研发中心/零售客户经营开发团队/零售信息应用开发六室(杭州)","数据智能诊断文档自动化生成方案","1、基于规则引擎实现的数据诊断结论自动生成\n2、提供可视化工具供用户在线自定义编辑文档内容\n3、支持导出可编辑的Office文件（PPT和WORD）\n4、采用批量合成的方式提供毫秒级访问体验","问题：\n1、常规报告仅呈现数据并没有对数据进行分析及给出结论，同时总分行一些线下会议材料需要耗费大量人力进行数据整理后形成汇报材料\n效果：\n 1、支持用户按规则预置分析逻辑，待数据就绪后直接输出结论；\n 2、实现数据报告的导出，生成PPT或者WORD类型材料供会议场景直接使用；\n 3、在线打开时实现毫秒级响应；",null,"江凯/258149","CN113377746B、CN113378560B","CN113377746B公开了一种试验报告数据库构建和智能诊断分析系统，包括试验报告数据库构建模块和试验报告智能诊断分析模块，试验报告数据库构建模块用于构建标准试验数据库；试验报告智能诊断分析模块用于根据构建标准试验数据库进行试验报告智能诊断分析。CN113378560B公开了利用预设的规则对收集到的数据进行处理。但是该规则倾向于文本处理规则。但是本方案是可视化工具来编辑诊断结论自动生成，表格数据的基于规则引擎进行预分析，并生成可编辑office文件（导出工具和编辑工具是配套的）。还包括低延迟输出。（线下会议场景）。因此与对比文件存在明显区别。","建议补充规则的示例，以及生成可编辑office文件的技术点，沟通时说导出工具与编辑工具适配点还较为复杂，建议补充","建议申请","发明","彭江峰"]
[2,"零售应用研发中心/零售客户经营开发团队/零售信息应用开发六室(杭州)","业绩数据智能播报方案","1、支持用户个性化编排推送内容，支持与多种数据源结合；\n2、实现数据与喜报的智能结合，自动按数据生成个性化喜报；\n3、支持实时数据源（KFK）和批量数据源（CK、GAUSS）的可插拔接入；","问题：\n 总分行客户经理业绩数据通报涉及到数据统计和内容整理等步骤，而且实时性无法得到保证。\n效果：\n 1、单笔业绩通知秒级推送；\n 2、支持定时和循环推送榜单数据；\n 3、重点业绩的喜报秒级自动生成与推送；",null,"江凯/258149","CN114254959A","CN114254959A公开了业务数据导入模块，用于将业务数据导入到数据仓库；业绩单转换模块，用于对业务数据进行清洗和信息转换；业绩单模块，用于生成对应的业绩单；业务目标导入模块，用于对员工业绩目标进行导入；分配方案管理模块，用于根据员工ID和分配比例生成分配模板，自动将分配模板分配给对应的业绩单；个人业绩明细模块，用于记录计算出的个人业绩明细；个人业绩统计模块，用于实时计算所有员工的业绩完成率，将业绩完成率按照数据权限对用户进行呈现和反馈。\n同时，编辑通知模板，然后将处理好的数据填充至模板中，为常规技术手段。但是本方案是多种数据源结合，即时输出（个性化编排内容），前期还有数据加工，因此与对比文件存在明显区别。","建议补充前期的数据处理，即将数据从签单确定，到业绩报告输出全流程说明。","建议申请","发明","彭江峰"]
[3,"零售应用研发中心/零售客户经营开发团队/零售信息应用开发一室","百亿级资格/规则数据实时落地方案","发明点：\n1、采用列式数据库存储资格/规则数据\n2、采用批流结合的方式进行实时资格计算，及数据自动修复\n3、采用配置方式实现快速迭代","问题：\n1、当前客户量超过一亿，生效规则数量近2万，产生的规则结果数据量在百亿级别以上。且随着规则的个数增加，产生的规则结果数据量呈指数上升，难以全部存储。\n2、kafka存在数据丢失的情况，如果采用人工校验的方式，成本非常高，效果也较差。\n\n效果：\n1、随着规则数量的增加，规则结果数据量不会激增。\n2、实现T+1自动数据修复，无需人工干预。",null,"罗洋/274413","CN117950804A、CN110019651A","CN117950804A公开了种面向核工程大数据分析的流批一体化分布式方法及系统，在分布式环境中，部署Kafka集群，进行模拟数据源的数据传输；部署Flink流处理平台，对数据流进行流数据处理；部署Kubernetes集群，通过网络策略和防火墙规则实现集群的网络隔离和数据传输安全；部署HBase数据库，对流处理后的数据进行列式存储；提供一数据回归预测模型，对输入数据进行异常实时预测；对存储数据进行批处理，并结合历史数据对模型进行更新。CN110019651A公开了一种流式规则引擎及业务数据处理方法。该流式规则引擎：包括业务规则配置模块和处理模块；其中，所述业务规则配置模块部署在Flink框架平台中的一设备上，用于配置业务规则数据；所述处理模块部署在Flink框架平台中的其他分布式设备上。但是本方案中是专用规则结果分别通用入库以及指标入库。触发规则层计算topic，规则计算API以及指标入库。因此，与对比文件存在明细区别","建议将沟通时的流程图补充至技术交底书","建议申请","发明","彭江峰"]
[4,"/零售应用研发中心/信用卡开发团队/信用卡客户经营开发五室(杭州)","面向网络基础设施的故障定界方法及装置","物理机、交换机、负载均衡器等网络基础设施是业务应用运行的底座，一旦发生故障，将导致大范围的业务异常，因此面向网络基础设施的快速且精准的故障定界方法显得尤为重要。\n本发明对骨干网和数据中心网络建模，开展常态化全局拨测，通过全局拓扑耦合分析等算法收敛风暴式告警事件，实现面向网络基础设施的故障定界与影响分析。","1）全局化网络态势感知：可视化展示与检测骨干网、数据中心网络的通信健康状态。\n2）面向网络基础设施故障的快速爆点定界：通过FullMesh分析、分层抽样分析、拓扑关联分析等，快速锁定异常基础设施网元。\n3）面向网络基础设施故障的精准影响分析：已知异常基础设施网元，通过资源节点视图，实现精准影响范围分析。\n",null,"陈志礼/80280500","CN114528554A","CN114528554A公开了一种信息安全运行场景监控展示平台，包括以下内容：自动化收集网络中的设备运行信息和机房基础设施的环境信息，并进行集中整理、分析后展示；开发Bootstrap前端开源框架；研发监控展示平台的后端业务逻辑流程；设计收集的运行数据信息策略模型；研判告警信息的机器学习模型；以集中展示公司信息系统和网络安全运行情况为目标，研制出信息安全运行场景监控展示平台，该平台能够对系统和网络运行状态进行实时安全监控，预判危及网络安全运行指标的安全风险点。即对比文件公开了通过网络架构以及对网络数据的收集，确定终端设备的故障点。但是本方案针对的是基础设备，并且对比文件做不到本方案中的高效。","建议补充一至两个故障定界的示例，并说明完整的网络架构图是如何绘制的，绘制完整网络架构图是否会影响故障定界的效率，是否有替代方案来提升故障定界的速度","建议申请","发明","彭江峰"]
[5,"/零售应用研发中心/信用卡开发团队/信用卡客户经营开发五室(杭州)","故障管理场景下的运维图谱分析方法","目前监控运维系统多着力于事中的故障检测、定界等能力建设，对事前的故障预防、事后的故障处置及知识沉淀等却表现乏力。\n本发明搭建了一套面向故障管理场景的运维图谱，在CI/CD阶段整理应用、人员、项目等依赖，在事后阶段沉淀事故知识，并使用图谱进行深度关联，对外提供异常影响范围分析、精准告警至代码修改人、智能决策、知识闭环、服务架构治理等功能。","1）服务治理：支持检测系统架构异味，保障了系统自身质量。\n2）异常精准告警及智能决策：一旦应用/存储介质存在异常，可锁定影响范围及代码提交人，并智能检索解决方案，提升了故障处置效率。",null,"陈志礼/80280500","CN113037549A、CN108829558A","CN113037549A公开了一种运维环境告警方法。该运维环境告警方法，借助Prometheus服务器端、Prometheus客户端、推入口、探针和告警管理器组件，建立可视化的运维系统；在线设置并维护告警规则内容项、告警指标内容项和接收人信息，实现对资源的在线监测以及告警功能；将在可视化的运维系统中定义的告警规则内容项与告警指标内容项推送到Prometheus服务器端；Prometheus服务器端根据告警规则内容项与告警指标内容项过滤从探针中收集的各项指标，通过告警管理器实现告警规则与告警指标的消息推送。CN108829558A公开了种数据中心告警智能运维管理方法及系统。该方法包括：获取告警信息；对告警信息进行压缩、关联和过滤处理，生成预测告警数据；根据预测告警数据，对数据中心智能运维人力进行排班管理，获取告警处理结果；将告警信息、预测告警数据和告警处理结果生成报表；对告警信息、预测告警数据和告警处理结果进行实时告警。但是对比文件的应用场景与本方案存在区别，并且对比文件并未构建运维图谱，也并未基于历史处理数据提供处理建议等，因此本方案与对比文件存在较大区别。",null,"建议申请","发明","彭江峰"]

{"sheet":"7.19-8.2","index":11,"n_rows":7,"n_cols":13,"rows_kept":7,"cut":false,"hidden":false,"merged":[[0,0,0,6],[0,7,0,12]]}
["发明人填写",{"$nulls":6},"代理人填写"]
["序号","中心/团队/室","专利名称（暂定名称）","主要发明点/方案简述及与现有技术的区别","解决的技术问题及预计达到效果","所属技术领域","发明人","检索的最接近对比文件","检索分析\n（与对比文件相比的区别点）","待发明人补充内容\n（挖掘现场代理人提出需要发明人补充的内容）","检索结果\n如：补充内容后建议申请XX专利\n建议拆分专利（说明拆分内容）\n不建议申请，说明原因","建议申请类型","检索人"]
[1,"零售应用研发中心/零售基础开发团队/基础开发一室","基于实时决策引擎的动态数据移植方案","1、设计了一种全新的动态数据移植和同步方案。其核心模块是“实时决策引擎”，实时决策引擎是部署在按客户分库的应用上的一段应用程序，其按客户、业务类型维护着一份移植控制记录数据，保存着客户的移植状态。其发挥着两个作用：一是提供决策分析结果，即客户是否已移植完成信息给联机应用；二是移植调度模块在移植数据时会基于实时决策引擎的移植控制记录数据进行数据的移植和重试移植，移植全程对客户无感。\n2、数据同步采用的是交易重放模式的同步，传统的数据层面的同步的缺点是无法验证到新流程的正确性，而交易重放可以。","解决的问题：\n1. 动态数据批量移植过程中，不用暂停客户交易。\n2. 移植调度模块完全解除与业务逻辑的依赖。\n3. 移植完成后的同步阶段已提前验证了新业务的流程，降低了切量阶段带来的业务风险。",null,"林衡/80274387","CN117931941A","CN117931941A公开了公开了一种数据同步方法、系统及电子设备，应用于数据库侧，方法包括：接收作用于数据库的操作指令；将操作指令存储至任务表；响应于查询任务表，将操作指令封装为同步数据；同步数据被配置为发送至业务系统侧，以实现业务系统与数据库的数据同步；响应于接收数据同步的完成信息，消除任务表中的操作指令。本申请提供的数据同步方法，能够获取对数据库的任何操作指令，并将操作指令存储至任务表中以提高数据同步的匹配度；同时，通过对任务表中的操作指令进行查询、封装后发送至业务系统，提高了数据库侧与业务系统侧的数据交互能力，避免了出现数据孤岛问题，实现了数据的实时更新。但是本方案总很纯粹，只有移植功能，不用停止交易，移植模块没有对业务进行适配改造，因此具备新颖性。","建议补充具体的示例","建议申请发明专利","发明","彭江峰"]
[2,"零售应用研发中心/零售基础开发团队/基础开发一室","支持多业务场景的通用批量资金归集方案","主要发明点：\n本发明提供一套通用的批量资金归集方案，上游业务场景通过鉴权接入通用系统后，批量上传交易明细，由通用归集系统发起资金转入并完成记账处理，同时提供批次结果查询。该通用方案可支持多业务场景直接接入，提供标准资金归集全流程处理，实现其无法批量资金划扣的问题。","解决问题：\n1.助力业务场景实现批量资金归集转入。\n2.批次数量可通过配置调节，方便不同规模的业务场景接入。",null,"刘倩/80274388","CN117151705A、CN116128649A","CN117151705A公开了一种批量归集处理方法、系统、存储介质及电子设备，可用于大数据领域或金融领域。获取签约后的多账户批量归集合约的合约信息，多账户批量归集合约用于使多个账户的资金同时向目标账户进行批量资金归集，通过预设顺序和合约信息，依次生成各个批量归集指令，若合约信息符合预设批量归集条件，通过各个批量归集指令，触发多账户批量归集合约中的签约账户进行批量资金归集操作。CN116128649A公开了响应于批量交易处理请求，获取批量交易请求中携带的交易文件，其中，交易文件中包括多条交易指令；将交易文件登记到数据库中，并为登记到数据库中的交易文件赋予待处理状态标识；在待处理状态标识能够修改为处理状态标识的情况下，处理多条交易指令，得到多条交易处理结果。但是本方案为通用性方案，可以随意接入多种业务，包括但不限于掌上生活的账单提取、养老金的支取等。多业务场景接入通用方案。因此具备新颖性。","建议补充内部业务和外部业务接入本方案的示例，并且说明相比于内部业务，外部系统的业务接入有何特殊改进","建议申请发明专利","发明","彭江峰"]
[3,"零售应用研发中心/零售基础开发团队/基础开发一室","一种基于大模型的红包祝福语生成方案","主要发明点：\n将大规模语言模型(LLM)与发红包的场景相结合，运营人员可以通过大模型批量生成特定场景（如营销活动、节假日等场景）的红包祝福语，同时也支持运营人员自定义增加红包祝福语。\n当用户在发红包时，红包祝福语栏则会随机出现之前通过大模型生成的祝福语信息，如果用户不满意还可以选择随机更换一条或者自行输入祝福语。\n\n与现有技术的区别：\n目前市场上的红包祝福语大多都是使用的默认值，如“恭喜发财，大吉大利”等，比较单一。用户除了使用默认的祝福语，就只能通过自行输入的方式自定义祝福语。","解决问题：\n使用大模型根据节假日等信息生成推荐的红包祝福语，同时支持运营人员配置自定义祝福语，避免默认祝福语的千篇一律，提升用户发红包时的体验。",null,"孔叶豪/80296363","CN116561352A","CN116561352A公开了电子红包生成方法、装置、计算机可读介质和电子设备。该方法包括：响应发送方对红包封面生成控件的触发操作，获取所述发送方与接收方之间的目标对象关系；根据所述目标对象关系和预设检索条件在数据库中进行检索，以获取目标多媒体信息；根据所述目标多媒体信息生成红包封面，并根据所述红包封面和红包金额生成电子红包。而基于大模型生成祝福语是模型的常规应用。但是本方案还可以扩展应用场景，具备新颖性。","进一步落实场景，例如根据红包接收方的具体信息，年龄、工作、性别等，对大模型生成的祝福语再次优化，以加深个性化","建议申请发明专利","发明","彭江峰"]
[4,"零售应用研发中心/零售客户经营开发团队/零售信息应用开发一室","一种基于多模型融合的机器学习实时分类方案","主要发明点：\n1、提出一种借助机器学习模型应用于实时分类的方案，应用只需提供简单参数即可实时计算结果。\n2、使用多模型概率融合方式选取概率最高的分类作为最优分类。\n3、模型的迭代与优化独立进行，不影响正常实时交易计算。\n\n","解决问题：\n基于机器学习模型融合计算结果用于实时用户分类，同时用户实时交易计算与机器学习计算互相独立，迭代与优化互不影响，提升用户体验",null,"李亮/80280645","CN112769752A、CN112561530A","CN112769752A公开了其次本发明使用多个机器学习模型的融合，实现了对网络中流量的识别与分类。CN112561530A公开了一种基于多模型融合的交易流水处理方法及系统，在所述S3预测的一级标签的基础上，利用卷积神经网络模型完成待分类交易流水二级标签的预测。即对比文件1公开了多模型融合用于分类.对比文件2公开了多模型用于交易场景。但是对比文件1与对比文件2的结合并未完全公开本方案，本方案具备新创性。","建议补充一个分类的例子，例如怎么根据多模型概率融合","建议申请发明专利","发明","彭江峰"]
[5,"零售应用研发中心/零售客户经营开发团队/互联网客户经营开发室(杭州)","结合DAST和IAST进行安全漏洞探测识别的方案","主要发明点：\n本发明在Web网络安全领域开创性地整合了动态应用安全测试（DAST）与交互式应用安全检测（IAST）技术，构建了一种全新的混合安全评估策略。通过实现IAST云端、插桩技术、漏洞分析引擎、自定义检测库这一套方案，做到了代码级的深度漏洞探测，为Web应用服务提供更全面、更无缝的安全检测和漏洞防护机制。","解决问题：\n1、IAST可以深入应用程序进行代码级漏洞探测，填补了DAST仅黑盒探测的局限性。\n2、极准确的漏洞定位和更低的误报误检率。\n\n预计效果：\n通过实时采集程序运行期间与安全漏洞相关的关键节点的请求调用链、数据流等信息。并实时在动态分析引擎端分析探针捕获的数据，识别潜在的安全漏洞。与DAST相结合准确识别出更多的安全漏洞。",null,"刘宇/80328724","CN117061222B","CN117061222B公开了一种漏洞数据获取方法及漏洞验证方法，涉及网络信息安全技术领域，解决了DAST与IAST在关联过程中，难以提供有效的漏洞整合信息，不利于漏洞的修复的技术问题。该方法包括：通过IAST对被测应用插入IAST代理，向DAST扫描器和已插桩应用发送测试请求数据；DAST扫描器接收测试请求数据，扫描生成DAST漏洞数据，通过转换器发送给已插桩应用的IAST代理；IAST代理接收所述测试请求数据，在ISAT的响应体里增加对应的IAST请求ID；根据IAST请求ID、DAST请求ID，将IAST漏洞数据和DAST漏洞数据进行关联。本发明能够直观的给开发人员提供漏洞整合信息，便于漏洞的修复。但是本方案中的DAST和IAST的结合方式与对比文件存在区别。","详细说明一下与对比文件的区别","建议申请发明专利","发明","彭江峰"]

{"sheet":"8.5-8.29","index":12,"n_rows":6,"n_cols":13,"rows_kept":6,"cut":false,"hidden":false,"merged":[[0,0,0,6],[0,7,0,12]]}
["发明人填写",{"$nulls":6},"代理人填写"]
["序号","中心/团队/室","专利名称（暂定名称）","主要发明点/方案简述及与现有技术的区别","解决的技术问题及预计达到效果","所属技术领域","发明人","检索的最接近对比文件","检索分析\n（与对比文件相比的区别点）","待发明人补充内容\n（挖掘现场代理人提出需要发明人补充的内容）","检索结果\n如：补充内容后建议申请XX专利\n建议拆分专利（说明拆分内容）\n不建议申请，说明原因","建议申请类型","检索人"]
[1,"零售应用研发中心/零售基础开发团队/基础开发二室(杭州)","多分库系统对外请求流量控制方法及系统","主要发明点：\n对多分库系统对外请求流量进行控制。\n\n与现有技术的区别：\n无网关，也无先进先出队列，通过相邻分库间通信组织流量控制系统","解决的问题：\n在无网关和外置队列的多分库系统中，解决对外请求流量限制的问题。\n\n预计达到的效果：\n简单高效地解决多分库系统对外请求流量限制，而且能够兼容多分库系统扩容缩容，有去中心化设计，能够避免单点失效。",null,"高鸿程","CN106156064B 对数据库进行流量控制的方法及装置","对比文件公开一种对数据库进行流量控制的方法及装置。其中，该方法包括：接收来自客户端的数据访问请求，为数据访问请求加载对应的规则集合，其中，规则集合中包括至少一个规则项；以及根据规则集合判断是否执行对应的数据访问请求，若是，则执行对应的数据访问请求，并向客户端返回执行结果，若否，则向客户端返回拒绝响应。本申请实施例的对数据库进行流量控制的方法及装置，在数据库内部实现了对数据库的流量控制，缓解了数据库的访问压力，避免了数据库崩溃情况的发生。\n对比文件公开一种流量控制方法，主要通过规则集合对请求进行验证，符合规则的请求可以执行，不符合则拒绝访问，与本方案根据本地算法对请求进行校验存在类似，但方案实际实现上并不一定相同，是否被公开要根据方案细节确定。此外对比文件并未涉及本方案有关分库的概念，更未涉及分库状态以及分库间通信的相关内容，因而判断本方案具备新颖性，建议申请发明专利。","无","建议申请发明专利","发明专利","孙德龙"]
[2,"零售应用研发中心/零售基础开发团队/基础开发五室(杭州)","一种结合分库与动态多活切换的高可用联机交易系统实现方案","主要发明点：引入故障切换机制，跟据数据库状态的调整的分库模式，在正常情况下，确保负载均衡，出现故障时，又能提高系统的可用性。\n","解决的问题：\n现有的分库部署形式，当某一个分库宕机，这个分库存储的用户就无法进行交易，依赖此分库恢复。\n预期效果：\n有某一个分库宕机自动由分库部署转为剩余存活分库随机多活的模式，系统可以继续提供全量服务，提高系统的可用性。即某一或多个分库宕机时，系统仍可以对外提供完整服务。",null,"马敬川","CN115016985A 数据分库方法及系统 ","对比文件公开了一种数据分库方法及系统，包括：配置中心监听多个数据库的工作状态，并在监听到任一数据库处于异常状态时，将任一数据库的容灾配置项修改为第一容灾状态；应用系统监听到任一数据库的容灾配置项被修改为第一容灾状态后，当存在与任一数据库匹配的待存储数据时，对待存储数据添加容灾标识；数据分类系统获取到附带容灾标识的待存储数据后，将待存储数据存储至容灾数据库中。通过应用系统将与异常状态的数据库匹配的待存储数据中添加容灾标识，数据分类系统将带有容灾标识的待存储数据存储至容灾数据库，使得与处于异常状态的数据库匹配的待存储数据也能被正常存储，应用系统正常运行，不造成数据丢失和系统瘫痪，提高了数据分库可靠性。\n对比文件公开了一种数据库分库方法，其分库方法主要通过系统监听数据库的工作状态并对异常状态下的数据库时，将该数据库对应的数据添加容灾标识，保证数据的正常存储提高可用性，对比可知该对比文件在效果上和本方案比较类似，但实现方案与本方案相关性不高，因此本方案具备新颖性，可以申请发明专利。","无","建议申请发明专利","发明专利","孙德龙"]
[3,"零售应用研发中心/零售基础开发团队/基础开发四室","一种联机系统间交易状态一致性保障方案","主要发明点：\n一笔订单存在多种关联业务操作，比如交易请求、交易查询等。系统A接收到交易请求并转发至下游系统B，当系统A在通讯锁允许的时间范围内未收到下游响应，则不允许对这笔订单发起其他的业务操作，从而保证单笔订单在同一时间只有一种业务操作在与下游系统进行通讯。系统B收到交易查询操作时，如果系统B不存在这笔订单，则写一笔交易状态为失败的订单记录；后续再收到这笔订单的交易请求时直接拒绝。\n\n\n与现有技术的区别：\n1、使用带时间的通讯锁来控制同一笔订单的不同业务操作在通讯锁的时间范围内或下游响应前不允许发起其他业务操作\n2、收到不存在订单的交易查询操作，写一笔交易状态为失败的订单记录，拒绝这笔订单的其他业务操作（交易请求）","解决的问题：\n系统A对同一笔订单的不同业务操作，因网络拥堵等问题导致系统B收到的业务操作与系统A实际请求的顺序不同，系统B响应顺序也不同。例如系统A发出顺序为：交易请求、交易查询，系统B响顺序为：交易查询，交易请求，系统A先收到查询响应反馈-系统B中记录不存在，直接更新交易状态为失败，而系统B最终将交易请求处理成功，交易状态为成功。这就导致系统A、B间交易状态不一致的问题\n\n预计达到的效果：\n1、系统A对同一笔订单的业务操作（交易请求）增加通讯锁，在通讯锁时间范围内未收到下游响应，不允许对这笔订单发起其他业务操作（交易查询）；\n2、系统B收到一笔订单的交易查询操作，如果系统B不存在这笔订单，则记录一笔交易状态为失败的订单，后续收到该笔订单的交易请求时直接拒绝",null,"黄显荣","CN117237113A 跨系统交易状态一致性的保持方法、中间系统和电子设备\nCN116342129A 一种基于医保支付的交易状态同步方法及装置\nCN114140247A 基于规则引擎的分布式应用系统交易状态一致化方法和系统","三篇对比文件都是有关跨系统的交易或账目状态同步方案，但均未涉及本方案通讯锁的相关或相似技术特征，而通讯锁的设置 也是本方案的核心发明点，因此本方案具备新颖性，建议申请发明专利。","无","建议申请发明专利","发明专利","孙德龙"]
[4,"零售应用研发中心/零售基础开发团队/基础开发二室(杭州)","多线程任务响应方法及系统","主要发明点：\n对需要向外部获取结果的位阶相同的API并行处理，并在部分API返回确定结果后，直接丢弃其他API的处理线程，快速进行后续处理。\n\n与现有技术的区别：\n1、对位阶相同的资源并行处理，而不是顺序调用逐个处理；\n2、在部分资源返回确定结果后，直接唤醒主进程进行处理，而不是等待所有结果都返回后处理。","解决的问题：\n提高在预检查等场景的效率，同时对多个检查点并行检查，并缩短反馈时间。\n\n预计达到的效果：\n可以协调多个线程之间的同步，当所有的线程执行完毕或其中一个线程执行失败时，主动唤醒主线程恢复执行后续任务，在特定的联机交易场景下，可以有效的降低响应时间。",null,"吴皓\n联系高鸿程","CN111475300A 一种多线程多任务管理方法及终端","对比文件公开了一种多线程多任务的管理方法及终端，根据任务个数创建对应个数的任务线程，初始状态为阻塞，并为每个任务线程创建对应的任务队列；为每个任务队列建立对应的任务队列指针以存放所述任务队列；接收任务处理请求，根据所述任务处理请求中的任务标识确定对应的任务队列指针以获取对应的任务队列，根据所获取的对应的任务队列的状态对所述任务处理请求进行响应；线程的初始状态为阻塞，能够快速对任务进行响应；采用任务ID进行标识，方便任务的写入和读取，进一步提高了任务的处理效率，保证了数据的时效性和无人驾驶操作的即时性，确保车辆的安全。\n对比文件的多线程任务管理方法，未每个任务线程创建对应的任务队列从而保证任务处理请求的时效，与本方案的核心发明点不同，本方案重点在于多线程并行处理请求/任务时，若有请求/任务响应失败，则及时结束其他线程的处理进度以提高整体失效，因此本方案具备新颖性，建议申请发明专利。","建议内容补充充实以明确范围，过于概括可能导致范围过大容易被审查员找到对比文件","建议申请发明专利","发明专利","孙德龙"]

{"sheet":"8.30~","index":13,"n_rows":3,"n_cols":13,"rows_kept":3,"cut":false,"hidden":false,"merged":[[0,0,0,6],[0,7,0,12]]}
["发明人填写",{"$nulls":6},"代理人填写"]
["序号","中心/团队/室","专利名称（暂定名称）","主要发明点/方案简述及与现有技术的区别","解决的技术问题及预计达到效果","所属技术领域","发明人","检索的最接近对比文件","检索分析\n（与对比文件相比的区别点）","待发明人补充内容\n（挖掘现场代理人提出需要发明人补充的内容）","检索结果\n如：补充内容后建议申请XX专利\n建议拆分专利（说明拆分内容）\n不建议申请，说明原因","建议申请类型","检索人"]
[1,"零售应用研发中心/零售客户经营开发团队/零售信息应用开发四室","\n基于地理位置校验的二维码应用解决方案","主要发明点：\n1、二维码生成时，预设地理位置信息，并对预设信息进行加密处理，防止二维码信息被复制、篡改。\n2、应用端在用户扫码时获取扫码方地理位置信息，并与二维码中预设的地理位置信息进行动态对比校验，从而实现业务场景中的扫码校验防伪需求。\n\n与现有技术的区别：\n现有二维码应用主要用来进行静态信息或地址的存储，本方案主要实现了二维码信息的加密处理，以及将扫码方信息与二维码内预设信息的动态对比校验。","解决的问题：\n目前在较多业务中都有应用二维码进行登记签到的场景，如客户到访银行网点扫码签到、员工外出拜访客户扫码签到、客户参加沙龙活动现场扫码签到等等。但二维码本身可以截图或拍照转发，如果不能进行有效的动态校验，很容易产生虚假扫码签到问题，影响客户权益、员工绩效的认定。\n\n\n预计达到的效果：\n1、在获取扫码方地理位置授权的前提下，实现扫码方地理位置与业务场景预设的地理位置的动态校验，有效实现了签到登记等业务场景的扫码防伪。\n2、将二维码中预设信息与扫码方识别信息进行动态对比校验，该方案在扫码防伪方面具有创新型、普适性、通用性。",null,"冯乾宜"]

{"sheet":"WpsReserved_CellImgList","index":14,"n_rows":0,"n_cols":0,"rows_kept":0,"cut":false,"hidden":true,"merged":[]}