- 背景
专利是一个公司的核心的竞争力，专利的多少，侧面代表着核心价值的多少。在另一种方面，申请专利也可是保护知识产权的一种途径。在国外，对专利尤为重视，所以提炼各自领域的核心技术，并沉淀到专利里面，也是我们一直在提倡的。那么如何更好的提炼一份专利，下面分享几点心得。
- 如何去开始一份专利提炼
也许很多同学也和我一样有过困扰，如何开始起手写一个专利，一头雾水。这个和我们平时的开发有很多不同，我们平时从产品那边去评审需求，需求确定后，我们开始开发。其实这个时候，我们的目标方向已经有了，需要做什么，我们也都比较清楚了，那么我们的工作开展，相对来说就比较容易。开发的过程无非只因个人的开发经验不同，最终也只是bug 的多少，考虑的充不充分而已。
所以去提炼一个专利的思维过程，就有点想产品的思维，我们需要自己去发现一个需求（确定专利的名字），然后提练需求的价值（分析罗列专利的三要素），然后最终去落地（专利的说明书），最终去说服我们的客户买单（进行技术讲解，让专利专员认可你的专利创新点，并提交专利）。
所以从这个思维角度来说，这个和我们日常的开发的思维习惯有所区别。那下面重要的问题来了，知道了思维逻辑的区别后，那下一步，我们该如何展开工作。
- 我们可以先怎么做
3.1. 广撒网
首先，我们可以广泛的收集各个方向的idea ，无论从业务的代码，还是基础的架构代码，还是需要等待优化的需求等等。下文会详解介绍这几个方向，这里先讲思路，拿个不太恰当的比喻（如下比喻听听就好，不代表个人的价值观），比如你要找个女朋友，把专利就当成你想要找的女朋友，那么有时候孤注一掷只去追求一个，可能也不是很适合你的，可能大部分情况下你会以失败告终，但是你只要保持一个心态，这个不行下一个会更好，去广撒网，那么总有一天，你会找一个适合你的。那么问题来了，结合我们的专利，我们怎么开展呢，我们需要列一个专利汇总表，去广泛收集我们的待确认对象（专利名称），然后对每一个对象进行全方位的分析优缺点（创新点的三要素 新颖性，创造性，实用性）。这样我们就可以收集到很多，可以有提炼的点，从中挑选比较感兴趣的点，一步一步去挖里面的优化点，和些技术创新。专利的收集表可以参考下图
3.2. 重点突破
有了上面一个广撒网的操作以后，我们就有了一个目标池，我们可以先挑选自己感兴趣或者自己把握度高的idea 去深挖里面的创新点，不过开始不需要理解太仔细，我们可以先确认一个idea的大致的方向，名字，以及创新点的描述。比如 一种基于配置化动态添加权限申请的打包方案 ，这样的一个名字，然后我们去专利的检索的网上去做专利的搜索，有没有之前有人申请过，或者已经存在类似的专利。因为这一阶段自己搜索也不一定特别的全，所以如果自己大致搜索没有问题，就可以在企业微信的审批中提交一个专利的申请说明，主要可以写对应的名字，以及对应的idea的创新点，这样我们专业的专利小伙伴可以给你做一个全面的评估，这样如果评估通过 ，我们就可以开始安安心心写专利技术文档了。
3.3 意外之喜
相对于前两个按部就班，逐一去发现我们可以提炼的点之外，我们可以从实际项目抱怨中去寻找灵感，这个是一个很奇妙的事情，当有人在抱怨，这个没有时间，那其实这个话语中就透露着一些优化的细节，这个工具是不是可以更加的完善，是不是可以更加的高效，所以下次听到有人抱怨的时候，在责备的时候，我们可以静下心来去想想，是否有改进的点，而不是以怨抱怨。毕竟抱怨人人都会，但是从抱怨中总结高效的优化点，才是更有益自己和他人。
- 专利提炼方向有那几个 4.1. 业务型
这个方向其实是比较好的方向，我们可以借此机会，比较仔细去了解业务模块的代码，以及逻辑，从而去提炼业务模块的一些思想。这个对代码和业务的理解要比较深，才能提炼出比较有新颖的业务创新点。这个适合所有熟悉业务的同学，借此机会，也可以站在产品的角度去思考，提炼业务相关的一些创新点和一些价值点。其实在这个寻找过程中，你可能也有很多意想不到的收获。
举一个列子：
4.2. 架构设计型
这个方向是我们项目中沉淀下来的一些基础的组件，和一些基础的工具类，比如一些Ci 的打包平台工具，maven 的库的管理脚本，一些Appshell 的基础组件，以及一些可配置的oem 架构方案，等等。我个人感觉这块的专利是特别容易写的，相对于业务型的专利更容易一些，因为我们在这个方向上可以找到很多资料。因为这些东西都是为了去解决一些实际困难，就拿一个方案来说，之前我们的工程细分功能的颗粒度比较细，然后我们引用功能的时候会引入很多的库，然后造成了打包的时间比较长，后面就有个pin 的组合模式优化，减少库 的数量从而增加了打包的效率，所以这块的东西都是为了增加开发效率，工作效率，增强用户体验等等角度去思考的话，相对比较容易找到方向。
4.3. 预言设计型
这个方向，其实感觉会比较有挑战性，这个针对的是目前没有的功能，或者有优化的空间的架构或者工具等等方面上，进行优化。因为本身目前的代码是未支持的，我们需要通过自己的想法，去提需求或者自己去推进这个项目的优化改进，然后最终将这个优化的创新性进行提炼。这个方向相对于前两个方向有所不同，前两个方向基本都是现成可以拿来写的，我们不需要要去关心具体如何去落地，所以这个方向的风险会比较大，有可能也有落地不下去的情况，但是一但成功从0到1的整体去体验下来，我感觉不管是对个人的成长，还是公司提效角度来说都是有很大收益的。可以值得去尝试，但是这个类型的专利，为保证质量的情况下，应该要控制下数量。
- 从我的角度分享几点我感觉可以提炼专利的点（价值一万块）
5.1. 一种稳定的maven 版本管理解决方案（架构设计型）
创新点说明：
目前，开源maven 管理仓库对于版本的管理都比较开放，我们在使用maven 仓库做组件的版本管理的时候都比较随意，这个就决定了规范管理版本就比较不可控。基于这个问题，我们在maven 仓库的上传做了一定的限制，比如版本不能覆盖，（这个减少我们一部分老的版本，引用库被恶意的覆盖造成版本不稳定，会有一定浅在的风险），还有对maven 上传的名字的做了一定的规则限制，方便我们更好管理的maven上组件版本，提高组件版本的可维护性，及版本的稳定性，和规范性。
5.2. 一种动态配置面板的设计方案（架构设计型）
创新点说明：
目前，项目中对设备的控制面板，大部分使用的rn 的面板，我们各个业务线的定制的需求都有所差异。不同的设备，不同的品类，不同定制的app， 需求都不一样。那么一个新的定制面板使用的范围，以及在哪个设备，哪个app 上使用，如何维护这套关系链路，就是成了一个问题，我们基于一个定制面板生成唯一的一个uuid ，将设备的productiD 做设备纬度的区分，而app 有唯一的AppiD作为区分 将二者组合维护在后台动态配置管理。有效的管理二者之间动态切换的一个效果，减少了切换面板的成本，和时间成本，增加了定制面板切换的效率。
5.3. 一种快速查找插件负责人的解决方案（预言设计型）
创新点说明：
目前，我们开发过程中，使用了各种各样现成的轮子。有的来自中台的，有的来自公版的，在引用他们的基础库的时候难免会遇到一些问题和疑惑，有时候就想快速找到对应的轮子的负责人。而目前我们使用的轮子，都统一维护在ci 后台，我们可以根据组件库名字和组件使用的版本，在ci 中查询到对应的负责人。这样我们在ide中就使用插件快速查找到对应的负责人，从而提供工作的效率。
5.4. 一种继承式的多语言配置设计方案（预言设计型）
创新点说明：
目前，我们使用的多语言配置平台，支持配置复制某个版本的多语言，通通拷贝到目标版本里。比如在第一次没有全部导出所有语种，我们想要在第二次进行多语言支持的时候，就需要进行手工导出新增语种再重新再导入目标版本进行增量添加。又比如使用公版的基线版本进行了升级，也需要做手工导出导入的操作目标版本的多语言配置。假设采用了继承式父类的方式，我们业务的版本只需要维护本业务新增的多语言，这样看起来会比较清晰，也显得不像之前那么臃肿。在前面两种操作下，我们如果采用继承式管理多语言版本，就不存在第一次选择支持哪种语言，默认父类支持的我们也支持，我们只需配置自己业务版本的多语言。所以第一次直接继承某一个版本的公版就好，后续基线版本修改，只需要换下父类基线版本就好，无需再去重复导出导入操作，增加后期增加语言支持而增加操作上的工作量，从而提高产品在配置多语言的工作效率。
5.5. 一种快速检索智能场景的设计方案（预言设计型）
创新点说明：
目前，我们家用场景对一些场景的配置有比较通用的一键执行的场景。比如用户的家里有了门磁、空调、电视、入户灯、窗帘等等。我们普通家庭的一些通用方案其实比较复用，所以当用户输入回家，后台可以去检索当前用户家庭下面设备，基于这些设备的类型，自动去匹配符合这些设备的一些离家的通用方案。比如门禁开，灯开了，然后窗帘打开，电视打开，香薰打开，等等。这样，可以减少通用的方案的配置时间，降低通用方案的使用门槛，减少用户的重复配置的复杂度，增强用户体验。
- 那我们花这么多时间去写专利有什么作用呢
6.1 通过申请外围专利扩大专利保护范围。
6.2 总结技术创新点，为研发指明方向。
6.3 保护企业的研发投入和成果。
6.4 保证市场独占地位，减少卷入纠纷的损失（苹果和google 去打专利官司）。
6.5 从转让/许可 中获益 优惠政策，资格认证。
7.总结
我们不一定是专利的发明者，但可以成为专利的搬运工。
