伦理审查的主要内容

附1：

伦理审查的主要内容

1. 试验方案的设计与实施

1.1 试验符合公认的科学原理，基于文献以及充分的实验室研究和动物实验。

1.2 与试验目的有关的试验设计和对照组设置的合理性。

1.3 受试者提前退出试验的标准，暂停或终止试验的标准。

1.4 试验实施过程中的监查和稽查计划，包括必要时成立独立的数据与安全监察委员会。

1.5 研究者的资格与经验、并有充分的时间开展临床试验，人员配备及设备条件等符合试验要求。

1.6 临床试验结果报告和发表的方式。

2. 试验的风险与受益

2.1 试验风险的性质、程度与发生概率的评估。

2.2 风险在可能的范围内最小化。

2.3 预期受益的评估：受试者的受益和社会的受益。

2.4 试验风险与受益的合理性：①对受试者有直接受益前景的试验，预期受益与风险应至少与目前可获得的替代治疗的受益与风险相当。试验风险相对于受试者预期的受益而言必须是合理的；②对受试者没有直接受益前景的试验，风险相对于社会预期受益而言，必须是合理的。

3. 受试者的招募

3.1 受试者的人群特征（包括性别、年龄、种族等）。

3.2 试验的受益和风险在目标疾病人群中公平和公正分配。

3.3 拟采取的招募方式和方法。

3.4 向受试者或其代表告知有关试验信息的方式。

3.5 受试者的纳入与排除标准。

4. 知情同意书告知的信息

4.1 试验目的、应遵循的试验步骤（包括所有侵入性操作）、试验期限。

4.2 预期的受试者的风险和不便。

4.3 预期的受益。当受试者没有直接受益时，应告知受试者。

4.4 受试者可获得的备选治疗，以及备选治疗重要的潜在风险和受益。

4.5 受试者参加试验是否获得报酬。

4.6 受试者参加试验是否需要承担费用。

4.7 能识别受试者身份的有关记录的保密程度，并说明必要时，试验项目申办者、伦理委员会、政府管理部门按规定可以查阅参加试验的受试者资料。

4.8 如发生与试验相关的损害时，受试者可以获得的治疗和相应的补偿。

4.9 说明参加试验是自愿的，可以拒绝参加或有权在试验的任何阶段随时退出试验而不会遭到歧视或报复，其医疗待遇与权益不会受到影响。

4.10 当存在有关试验和受试者权利的问题，以及发生试验相关伤害时，有联系人及联系方式。

5. 知情同意的过程

5.1 知情同意应符合完全告知、充分理解、自主选择的原则。

5.2 知情同意的表述应通俗易懂，适合该受试者群体理解的水平。

5.3 对如何获得知情同意有详细的描述，包括明确由谁负责获取知情同意，以及签署知情同意书的规定。

5.4 计划纳入不能表达知情同意者作为受试者时，理由充分正当，对如何获得知情同意或授权同意有详细说明。

5.5 在研究过程中听取并答复受试者或其代表的疑问和意见的规定。

6. 受试者的医疗和保护

6.1 研究人员资格和经验与试验的要求相适应。

6.2 因试验目的而不给予标准治疗的理由。

6.3 在试验过程中和试验结束后，为受试者提供的医疗保障。

6.4 为受试者提供适当的医疗监测、心理与社会支持。

6.5 受试者自愿退出试验时拟采取的措施。

6.6 延长使用、紧急使用或出于同情而提供试验用药的标准。

6.7 试验结束后，是否继续向受试者提供试验用药的说明。

6.8 受试者需要支付的费用说明。

6.9 提供受试者的补偿（包括现金、服务、和/或礼物）。

6.10 由于参加试验造成受试者的损害/残疾/死亡时提供的补偿或治疗。

6.11 保险和损害赔偿。

7. 隐私和保密

7.1 可以查阅受试者个人信息（包括病历记录、生物学标本）人员的规定。

7.2 确保受试者个人信息保密和安全的措施。

8. 涉及弱势群体的试验

8.1 唯有以该弱势人群作为受试者，试验才能很好地进行。

8.2 试验针对该弱势群体特有的疾病或健康问题。

8.3 当试验对弱势群体受试者不提供直接受益可能，试验风险一般不得大于最小风险，除非伦理委员会同意风险程度可略有增加。

8.4 当受试者不能给予充分知情同意时，要获得其法定代理人的知情同意，如有可能还应同时获得受试者本人的同意。

9. 涉及特殊疾病人群、特定地区人群/族群的试验

9.1 该试验对特殊疾病人群、特定地区人群/族群造成的影响。

9.2 外界因素对个人知情同意的影响。

9.3 试验过程中，计划向该人群进行咨询。

9.4 该试验有利于当地的发展，如加强当地的医疗保健服务，提升研究能力，以及应对公共卫生需求的能力。

如何答复审查意见

一、下发《审查意见通知书》及《补正书通知书》的情况 1、一般来讲，在专利审查过程中，审查员会针对实质性问题下发《审查意见通知书》，而针对形式问题下发《补正书通知书》； 2、《审查意见通知书》在发明专利及实用新型专利申请中比较常见，《补正通知书》在实用新型专利及外观专利申请中比较常见，在绝大部分发明专利审查过程中均会碰到《审查意见通知书》。 二、答复《审查意见通知书》及《补正书通知书》的期限 1、一般来讲，答复《第一次审查意见通知书》的期限为四个月，答复《第二次审查意见通知书》的期限为两个月，答复《补正书通知书》的期限为两个月； 2、上述期限的计算方法是：从通知书的发文日起，先向后推算15日作为文件传递时间，再以上述期进行计算。 三、如何答复《审查意见通知书》及《补正书通知书》 1、答复《审查意见通知书》及《补正书通知书》时，主要应针对审查员在通知书中所指出的问题进行答复，一般来讲，不要针对审查员通知书意见之外的事项作过多陈述； 2、在答复《审查意见通知书》及《补正书通知书》的过程中，可能会涉及到申请文件的修改，此时应严格遵循“修改不超范围”的原则，也就是说，从原始申请文件中不能明确、唯一导出的内容，均不能加入到新的申请文件中，“修改超范围”是专利审查过程中的驳回理由，也是专利授权后的无效理由； 3、在发明专利的审查过程中，最常见、最难答复的是关于专利“新颖性”及“创造性”的问题，通俗的讲（但不严谨），“新颖性”是指本申请与现有技两者在实质上不相同；“创造性”是指本申请与现有技术相比，不但在实质上不相同，而且这种区别是普通技术人员来说是不易想到的，也就是需要达到一定的创新高度。 4、如果审查员指出，本专利申请与现有技术相比，不具备新颖性或创造性，需要针对具体情况分析：

软件评审流程要点

软件产品评审流程要点 1.立项 ●市场需要（软件为用户解决什么样的问题） ●国家政策（国家是否有相关政策提出，是否有利于该软件日后的发展） ●产品定位（软件在行业中的定位） ●产品功能策划 ●市场上类似产品的功能、特点与优势 ●产品的卖点与优势 ●开发该软件对公司的（战略）意义 ●性能（效率、响应时间、资源占用、稳定性） ●重要等级（是否直接关系人员生命安全） ●工程实施复杂度和软件维护复杂度 ●开发的（技术）风险是什么 ●市场或公司允许的研发周期 ●预计成本（人力物力） ●（可验证性） 2.设计方案 概要设计： 提交概要设计文档，内容包括如下方面： ●总体设计（需求规定、运行环境、基本设计概念和处理流程、结构、功能需求与程序的 关系、人工处理过程、尚未解决的问题） ●接口设计（用户接口、外部接口、内部接口） ●运行设计（运行模块组合、运行控制、运行时间） ●系统论据结构设计（逻辑结构设计要点、物理结构设计要点、数据结构与程序的关系）●系统出错处理设计（出错信息、补救措施、系统维护设计） 详细设计： 提交详细设计文档，内容包括如下方面： ●术语定义及说明 ●详细设计方法和工具 ●系统详细需求分析（详细需要分析、接口需求分析） ●总体方案确认（系统总体结构确认、系统详细界面划分（应用系统与支撑系统的详细界 面划分、系统内部详细界面划分）） ●系统详细设计（系统结构设计及子系统划分、系统功能模块详细设计、系统界面详细设 计（外部、内部以及用户界面设计）） ●数据库系统设计（设计要求、信息模型设计、数据库设计（设计依据、数据库选型、数

据库种类及特点、数据库逻辑结构、物理结构设计、数据库安全、数据字典）） ●网络通信系统设计（设计要求、网络结构确认、网络布局设计、网络接口设计） ●信息编码设计（代码结构设计、代码编制） ●维护设计（系统的可靠性和安全性、系统及用户维护设计、系统扩充、错误处理（出错 类别、出错处理））、系统调整及再次开发问题 ●系统配置（配置原则、硬件配置、软件配置） ●关键技术（关键技术的提出、关键技术的一般说明、关键技术的实现方案） ●组织机构及人员配置 ●投资预算概算及资金规划 ●实施计划（限制、实施内容和进度安排、实施条件和措施、系统测试计划（测试策略、 测试方案、预期的测试结果、测试进度计划））、验收标准 3.技术选型 ●版权 ●是否有应用先例，是否为常用技术 ●类似的技术是否在公司内部使用过 ●使用此技术的额外风险是什么（有没有失败的案例，原因是什么，如何避免） ●此技术是否是过时的技术（技术没有发展前景，或者提供者将来不再提供技术升级等）●是否为成熟的技术（应用范围广，大公司或者标准组织提供） ●能有选择的，尽量不要用定制的技术（其它类似产品或者项目不能复用的技术尽量少用） 4.界面评审 指导原则： ●关注用户及其任务，而不是技术 ●首先考虑功能，然后才是表示 ●从用户的视角看问题，使用用户的词汇进行描述，不必向用户暴露实现细节 ●使常用的用户任务简单化，不要让用户解决额外的问题 ●促进学习，保持一致性，引导用户的使用习惯 ●保持显示惯性，传递信息，而不仅仅是数据 ●设计应满足响应需求 颜色： ●统一色调：采用标准Windows的基本色调，做到与操作系统统一，读取系统标准色表。 ●整个界面色彩尽量少的使用类别不同的颜色。除非特殊场合，杜绝使用对比强烈，让人 产生憎恶感的颜色 ●同时色调也具有一定的含义，在整个系统中应保持色调含义的一致性，避免同一中颜色 在不同的画面中表示不同的意义。 资源： ●图标资源也需要遵循统一的规则，因为不同的图标代表不同的意义。例如：我们用图标 来表示保存，因此我们在整个系统中只要涉及到保存的话，都应该使用同一个图标，不

程序开发部代码审查制度

程序开发部代码审查制度 1.文档目的 (1) 2.适用范围 (1) 3.工作制度 (1) 3.1代码审查范围 (1) 3.2代码审查标准 (1) 3.2.1所开发的代码功能是否与详细设计文档中描述的保持一致。 (1) 3.2.2代码是否符合编码规范 (1) 3.2.3代码是否正确无误，没有隐含的错误。 (1) 3.3审查执行流程 (1) 3.4代码审查活动的监督 (2) 1.文档目的 该文档的阅读者主要为部门总监、部门经理、开发组长和程序员。通过该制度来规范代码编写，从而提高代码质量。 2.适用范围 该制度适用于程序开发部部门内部。 3.工作制度 3.1代码审查范围 审查任务目标包含的所有类。 3.2代码审查标准 3.2.1所开发的代码功能是否与详细设计文档中描述的保持一致。 此项检查设计部门会做抽查，开发部门需要做为重点执行项，保证代码和设计的一致性。3.2.2代码是否符合编码规范 此项检查作为开发部重点执行项，必须和编码规范保持一致。 3.2.3代码是否正确无误，没有隐含的错误。 此项检查要保证在组件功能无误的基础上进行，需要有经验的高级程序员对具体程序片段进行检查，纠正逻辑不合理代码、垃圾代码等。此工作在现阶段可以做为次要执行项。 3.3审查执行流程 1．检查的粒度――功能组件

2．当程序员开发完成一个组件，并且告知组长可以进行审查时，由开发组长或者指定的高级程序员来做审查工作。 3．审查人必须详细检查目标的代码编写，并且需要填写《代码审查表》。 4．如果审查未能通过，被审查人按照《代码审查表》的审查意见进行修改。 5．重复执行步骤2-4，直到审查通过。 3.4代码审查活动的监督 代码审查制度为代码质量的绩效考核提供参考，作为绩效考核代码质量评分的依据。

对第一次审查意见的答复意见

对第一次审查意见的答复意见 一、答1，关于对权利要求1不符合专利法第22条第3款有关创造性的规定的答复 ①意见1列出的对比文件1和本申请专利技术虽属于救援矿用产品范围但不属于同一技术范围是错误的认定 理由：CN202136712U救生救灾应急箱是一个没有电源没有任何智能也不防爆的普通矿用工具箱，里面装的是钳子，扳手等一应工具。里面有技术含量的是信息卡和GPS搜寻卡，但这些只是个卡片，只能在有电脑（或工控机）把卡片插在里面读取才能显示信息和功能。CN202136712U说明书和权利要求书里没有发现有电脑配置和计算机技术方案的陈述，因此该专利只能说是一个应急急救工具箱。而审查意见中描述CN202136712U《救灾逃生应急箱》同样属于便携式安全防护装置，显然是错误的。请审查。 ②意见1所列出的对比文件2和本申请专利技术不属于同一技术类别并属于法律禁止的技术方案 理由：102529619A矿用两栖救生潜艇系统是一个既是潜水艇又是可移动履带式救生舱 从产品属性讲，其技术范围属于大型传动设备，而cn202788926u（本申请专利）是精密全智能仪器仪表，两者技术不在一个技术层面。根据该技术说明书说明两栖潜水艇，其电源主要是履带传动设备和潜水桨推进机构供电，电源是RFE-16F100,电源供电电流48V,功率是100AH这样的电压和大功率锂电池是不允许在矿井下用，更不允许在矿井水下设备用！国家规定矿用紧急避险用锂电池产品电压不能超过24V,功率不能大于60Ah。而该技术是被禁止使用的技术方案。 因为对比文件不适应，所以本技术仍具有创造性、新颖性。 本技术是集安全防护系统和功能单元构成的便携式安全防护装置，本技术的关键特性不是几个系统或设备的拼凑，而是一个整体的系统包含了多个功能的子系统。作为安全防护全站仪不是一个防爆箱里集合了多个设备的工具箱。（本专利技术所说的苏生器、矿灯、温湿度计、急救器、气压计是全站仪配备的急救工具。在专利要求书中保护的意图是在安全防护全站仪中配备了这些工具而这些工具是救援人员用于施救的工具）而是一个全新的全方位的安全防护技术方案。 二、答2：关于要求2不符合专利法第22条第3款有关创造性规定 的答复 ①技术中描述的防爆箱实际是安全防护全站仪的防爆箱，属于表述误 解。应该理解为全站仪壳体，壳体材质要求权利保护是合适的，因为

代码审查规范

1. Code Revie进行检查试过现的质量保机制，通这个机制我可以代码、注一种Code Revie来确认方案计和代码的要用在软件工程程中改进码质量，Code Revie以达到如下Code Review代码审查规范1. Code Review目的 Code Review是一种用来确认方案设计和代码实现的质量保证机制，通过这个机制我们可以对代码、测试过程和注释进行检查。 Code Review主要用来在软件工程过程中改进代码质量，通过Code Review可以达到如下目的： 在项目早期就能够发现代码中的BUG。?帮助初级开发人员学习高级开发人员的经验，达到知识共享。?避免开发人员犯一些很常见，很普通的错误。?保证项目组人员的良好沟通。?项目或产品的代码更容易维护。? 2. Code Review的前提条件 代码提交审核前，开发者必须确保代码符合如下条件，审核者需要确保所有前提条件都已满足方可开始审查，同时也是审查的主要检查点。 所有代码注释清晰，语法正确，编译通过。?日志代码完整，业务日志、系统日志分开，中文描述，脱敏处理，状态变更，?全部清晰明确。 测试代码覆盖全部分支和流程，暂时统一使用工具Emma（各编译器可下载对?应插件）进行Coverage Check。 项目引用关系明确，依赖关系清晰，配置文件描述。? 的审查范围3. Code Review 代码的一致性、编码风格、代码的安全问题、脱敏问题、代码冗余、是否正确设计以符合设计要求（性能、功能）与设计文档相同等等。）完整性检查（Completeness3.1、 代码是否完全实现了设计文档中所涉及的所有流程和功能点?代码是否已包含所有所需的业务日志、系统日志、异常日志，日志内容是否完?整，日志文件配置是否正确。 代码是否使用缓存等，配置信息是否正确可配置。?代码中是否存在任何没有定义或没有引用到的变量、常数或数据类型等?一致性检查（Consistency）3.2、 代码的逻辑是否符合设计文档?代码中使用的格式、符号、结构等风格是否保持一致?）Correctness3.3、正确性检查（代码是否符合制定的标准?所有的变量都被正确定义和使用?所有的注释都是准确的?所有的程序调用都使用了正确的参数个数? Modifiability）、3.4 可修改性检查（如使用配置、定义为类常量、使用专门的常量代码涉及到的常量是否易于修改(?)类等 代码中是否包含了交叉说明或数据字典，以描述程序是如何对变量和常量进行?访问的 代码是否只有一个出口和一个入口（严重的异常处理除外）?）可预测性检查（Predictability3.5、代码所用的开发语言是否具有定义良好的语法和语义?是否代码避免了依赖于开发语言缺省提供的功能?代码是否无意中陷入了死循环?代码是否避免了无穷递归?．

审查意见答复模板

尊敬的审查员： 针对专利局于年月日就题述专利申请发出的第次审查意见通知书，对权利要求书进行了修改，申请人现陈述意见如下： 一、关于权利要求1的创造性 申请人认为权利要求1相对于对比文件1具备创造性，符合专利法第二十二条第三款的规定。理由如下： 二、关于权利要求2保护范围不清楚的问题 关于修改： 申请人将权利要求4中的附加技术特征添加到权利要求1中，该修改仅仅是权利要求的合并，并未涉及到实质内容的修改，因此该修改是能够得到说明书的支持，符合专利法第三十三条的规定，并且申请人认为修改之后的权利要求1相对于对比文件1和对比文件2是具有创造性的，符合专利法第二十二条第三款的规定。理由如下： 申请人将附加技术特征“其中，所述诊断策略包含从诊断模块运行的程序组合”添加到权利要求1中。 在本申请说明书中的第4页倒数第5段记载了“诊断策略包含从诊断模块运行的程序组合”，因此，上述修改是能够得到说明书的支持的，符合专利法第三十三条的规定，并且申请人认为修改之后的权利要求1相对于对比文件1具有创造性，符合专利法第二十二条第三款的规定。理由如下： 关于修改2： 申请人将权利要求1中记载的“确定所述第一时偏值或所述第二时偏值作为所述初始测距的时偏”修改为“根据时偏值和/或符号的峰值功率，确定所述第一时偏值或所述第二时偏值作为所述初始测距的时偏”添加到权利要求1中，在本申请说明书第9页中记载了时偏处理方法的几个公式，从这几个公式中可以直接毫无疑义确定的是在确定第一时偏值或第二时偏值作为初始测距的时偏时，是根据时偏值和/或符号的峰值功率所确定的，因此，上述修改是能够从说明记载的内容中直接毫无疑义确定的，因此，该修改是能够得到说明书的支持的，符合专利法第三十三条的规定。并且，申请人认为，修改之后的权利要求1相对于对比文件1是具备创造性的，符合专利法第二十二条第三款的规定。理由如下：

答复审查意见

在实质审查过程中，对于绝大多数发明专利申请，审查员都要采用审查意见通知书的方式将实质审查意见告知申请人。如果专利代理人和申请人能针对审查意见通知书撰写出令人信服的意见陈述书，并修改出合格的申请文件，则申请就有可能在较短的时间内被授权，大大缩短了实质审查程序；相反，提交的意见陈述书未对审查意见通知书作出满意的答复，就势必加长实质审查程序，甚至会使有可能取得专利的申请导致驳回的结果。因此，如何答复审查意见通知书是专利代理人的一项基本功，对于专利代理人和申请人来说应当通过实践积累经验，加以提高。 一审查意见通知书简介 实质审查意见通知书分为第一次审查意见通知书和再次审查意见通知书。 第一次审查意见通知书是审查员经过实质审查后首次发出的通知书，除了极少数可直接授予专利权的发明专利申请外，国家知识产权局专利局都必须发出第一次审查意见通知书。通常对于有授权前景的发明专利申请，第一次审查意见通知书在全面审查基础上指出专利申请文件存在的所有缺陷；而对于无授权前景的专利申请，第一次审查意见陈述书将充分论述该专利申请不能授予专利权的理由。由此可知，第一次审查意见通知书通常在审查意见通知书中最重要且内容最多。再次审查意见通知书是针对申请人的意见陈述书及新修改的专利申请文件继续进行实质审查后发出的，往往是对第一次审查意见通知书的补充，由再次审查意见通知书可以更清楚地得知该专利申请的前景。 审查意见通知书由标准表格（通常又称作通知书扉页）和审查意见通知书正文两部分组成。在标准表格中给出实质审查所依据的文本、引用的对比文件、对权利要求书和说明书的结论性意见、实质审查的倾向性结论意见、答复期限等，其中第一次审查意见通知书的标准表格中还给出专利申请的基本情况，如有无优先权要求、有无主动修改等。在审查意见通知书正文部分主要指出权利要求书和/或说明书的实质性缺陷，有授权前景时还指出专利申请文件所存在的其他问题，

代码审查规范

代码审查规范 1. Code Review目的 Code Review是一种用来确认方案设计和代码实现的质量保证机制，通过这个机制我们可以对代码、测试过程和注释进行检查。 Code Review主要用来在软件工程过程中改进代码质量，通过Code Review可以达到如下目的： ?在项目早期就能够发现代码中的BUG。 ?帮助初级开发人员学习高级开发人员的经验，达到知识共享。 ?避免开发人员犯一些很常见，很普通的错误。 ?保证项目组人员的良好沟通。 ?项目或产品的代码更容易维护。 2. Code Review的前提条件 代码提交审核前，开发者必须确保代码符合如下条件，审核者需要确保所有前提条件都已满足方可开始审查，同时也是审查的主要检查点。 ?所有代码注释清晰，语法正确，编译通过。 ?日志代码完整，业务日志、系统日志分开，中文描述，脱敏处理，状态变更，全部清晰明确。 ?测试代码覆盖全部分支和流程，暂时统一使用工具Emma（各编译器可下载对应插件）进行Coverage Check。 ?项目引用关系明确，依赖关系清晰，配置文件描述。 3. Code Review的审查范围 代码的一致性、编码风格、代码的安全问题、脱敏问题、代码冗余、是否正确设计以符合设计要求（性能、功能）与设计文档相同等等。

3.1、完整性检查（Completeness） ?代码是否完全实现了设计文档中所涉及的所有流程和功能点 ?代码是否已包含所有所需的业务日志、系统日志、异常日志，日志内容是否完整，日志文件配置是否正确。 ?代码是否使用缓存等，配置信息是否正确可配置。 ?代码中是否存在任何没有定义或没有引用到的变量、常数或数据类型等 3.2、一致性检查（Consistency） ?代码的逻辑是否符合设计文档 ?代码中使用的格式、符号、结构等风格是否保持一致 3.3、正确性检查（Correctness） ?代码是否符合制定的标准 ?所有的变量都被正确定义和使用 ?所有的注释都是准确的 ?所有的程序调用都使用了正确的参数个数 3.4、可修改性检查（Modifiability） ?代码涉及到的常量是否易于修改(如使用配置、定义为类常量、使用专门的常量类等) ?代码中是否包含了交叉说明或数据字典，以描述程序是如何对变量和常量进行访问的 ?代码是否只有一个出口和一个入口（严重的异常处理除外） 3.5、可预测性检查（Predictability） ?代码所用的开发语言是否具有定义良好的语法和语义 ?是否代码避免了依赖于开发语言缺省提供的功能 ?代码是否无意中陷入了死循环 ?代码是否避免了无穷递归 3.6、健壮性检查（Robustness）

答复审查意见案例分享

本文分享了本公司处理的答复意见，希望与大家一起学习。相关材料可在国知局网站检索到，在此不再添加原始文件。第二次审查意见发出后，客户改变了之前的意见，决定努力尝试，通过与客户沟通并且集合公司的电气工程师的才智做出了第二次审查意见的回复，并获得了授权。有材有料、有理有据、清楚明了，是本公司答复审查意见的原则，在此跟大家分享。根据原始记载（有材有料）说明本案的突出的实质性特点和显著的进步，结合技术特征和相关法条（有理有据）逐一答复审查意见中的问题，将问题和原理解释清楚，还是可以获得了审查员认可的。以下为答复意见的原文，供参考： 第一次审查意见的意见陈述 尊敬的审查员： 首先感谢您对本申请所作的认真而细致的审查，以及您在审查过程中所付出的辛勤劳动！申请人认真阅读了您的第一次审查意见，申请号为201610345579.4,名称为一种局域用电网络在线相位调制数字通信控制系统，审查员认为本申请存在以下问题： 权利要求1-7不具备专利法第22条第三款的规定的创造性。 对于以上问题，本申请人对申请文件做出陈述意见如下： 审查员认为在对比文件一中，“电流传感器、两路过零比较器接微控制器的捕获中断引脚”的功能和本发明“电网同步信号提取电路”的功能相同。但是本发明的电网同步信号提取电路比对比文件一中的相关电路有更好的效果。并且在对比文件一中，说明书并没有具体说明其功能及其工作原理。 由说明书附图可知，本发明的电网同步提取电路的并接于控制开关的前端，对比文件一中的电流传感器、两路过零比较器位于控制开关的后端。 其有益效果为： 本发明可以通过供电线路接收上一级的信号，主控制器不仅作为主控终端可以作为从终端接收上级的信息。 本发明的电网同步信号提取电路由于位于控制开关的前端，因此在接收上级的信号时不会对从网络控制器产生影响。而对比文件一无法避免该情况的发生。 因此本发明相对于对比文件一具有实质性的进步和创造性。 综上所述，修改后的申请文件已经克服了审查意见所记载的缺陷。 以上意见陈述希望得到审查员的认同，若仍有不足之处，申请人非常愿意对文件进行再次修改，并希望本申请早日获得专利权。

前端审核岗工作职责及作业流程培训手册

财务共享中心教材 一、课程目标 通过本课程学习，熟悉审核岗的工作职责，掌握审核作业流程的基本操作步骤和方法，能独立进行审核的工作。 二、适用对象 本课程适用于审核岗上岗前学习、综合业务处内其他岗位了解前端业务学习用。 三、编写依据 本课程依据《财务共享中心单据管理工作规范》、《会计基础工作规范管理程序》编写完成。 四、主要内容 1、审核岗工作职责； 2、基础知识讲解； 3、审核岗作业流程基本操作步骤和方法； 4、日常工作中的注意事项；

5、UPM凭证匹配表的应用。 第一部份审核岗工作职责 一、负责与共享单位日常接口业务的协调、问题反馈； 二、对收到的单据进行审查、核对、发票鉴定、上传、保管等； 三、按要求整理、匹配实物单据，按指定渠道和时间做好速递、登记、出库管理，负责跟踪实物单据流转；对传递的时间和路线提出建议； 四、对影像问题的退单流程进行处理，对各类回单等进行传递和补扫描； 五、负责扫描点各项资产设备的安全和保管；负责扫描设施的参数调整等； 第二部份基础知识讲解 一、共享中心四大系统 共享中心目前在用的有四大系统，分别为：影像系统（IDC系统）、UPM系统（审批系统）、SAP系统（账务系统）、拜特系统（支付系统）。 本课程讲解的系统只涉及影像系统和UPM系统。这两大系统都通过IE浏览器登录进入，影像系统登录的网址为：，UPM系统的网址为：，登录网页后可以直接使用；影像系统首次登录后要先进行设备及系统的安装才能进行影像上传的操作，安装步骤和方法参照影像系统网页右上角外挂的安装说明进行安装。 安装说明文件位置如图：

二、共享中心服务热线 集团内IP电话机直拨118，非IP话机拨8。 三、常用字符串编号规则 流程条码号：每个UPM流程表单都有唯一的条码号，条码号为表单左上角条形码下的14位数字串，该数字串的编号规则为：前4位为费用所属公司代码，5-10位表示流程发起日期（年月日），后4位为当天发起流程的序号。例如：1,表示为集团公司13年6月5日发起的第1个流程。 索引号：流程影像上传之后会生成一个索引号，未扫描上传的流程没有索引号，索引号为13位的数字串，前3位为各扫描点的代码，4-7位表示年月，后6位为当月的扫描顺序号。例如张三，他在影像系统的代码为101，那么他在13年6月份扫描上传的第一个流程生成的索引号为：。 第三部份审核岗作业流程基本操作步骤和方法 第一步：单据登记或补登记 在网页地址栏输入，进入“扫描管理”→“票据登记”模块

如何进行代码审查

如何进行代码审查 开始代码审查 从一开始，开发者就会互相帮助，如果测试中遇到了问题或是有新人加入到了团队，领导或是资深开发者就会审查他们的代码。除此之外，我们还聘请了外部专家进行安全代码审查。 系统发布后，我们决定更加主动一些，开始了基于风险的审查：项目中有人会编写一些风险较高的代码（比如说框架与安全代码、APIs、核心业务逻辑或是之前曾经出现过问题的地方），我们会审查他们的代码。在这个过程中，代码审查体现出了它的价值，我们收获颇丰。即便如此，我们还是更进一步，让代码审查成为一个标准的实践。 这并不是一夜之间就形成的。让团队相信代码审查的价值并不是什么难事，他们已经通过基于风险的审查获得了收益。不过要想改变人们的工作方式就不是那么简单的事情了，还要确保他们有足够的时间进行代码审查，理解并对反馈作出响应。此外，设计一个高效的代码审查流程也是需要花时间的。 一开始，我们让开发者选择好搭档并安排审查，但结果却有些混乱。有时，开发者会寻找那些好说话或是比较忙的人，这样审查就比较容易通过了；此外，两个开发者还有可能事先商量好，因此审查过程就会很快结束。由于人们并不知道要花费多少时间才能完成代码审查，因此审查经常会拖得很久，常常在代码已经完成测试甚至是发布后才完成。 由于大多数人并没有太多的代码审查经验，因此他们并不确定在审查时应该看什么，如何给出有意义的反馈等信息。开发者常常会被负面的批评搞得很沮丧，有时甚至会心烦意乱。 最后，我们决定由领导来完成大部分审查工作。虽然这会增加领导的工作量，也意味着他们没有太多时间编写代码了，不过这么做却是很有效果的。通常情况下，主开发者会对需求有着更好的理解，对代码的行为有着清晰的认识，这也意味着他们更有可能发现代码中的错误。由于是同一个人完成了大部分的代码审查，因此被审查的开发者会收到一致的反馈信息。 如何进行代码审查 在过去的几年间，我们进行代码审查的方式几乎没有发生过什么大的变化。 无论是谁编写的，无论代码的功能是什么，重要的代码变更是一定要审查的。我们并没有一个正式的审查会议，也没发现使用诸如Code Collaborator、Crucible等工具有什么必要性，不过现在看起来使用这些工具来管理和追踪审查有助于团队更好的起步。 有时，审查是面对面完成的，不过大多数时候都是离线进行的。审查者与开发者会交换信息，也许通过邮件发送文件，因为我们觉得这种方式更加便捷，也更加方便每一个人安排自己的时间。 随着时间的流逝，审查中的变化之处是审查者该看什么，以及看到的结果。

专利审查意见回复模板

竭诚为您提供优质文档/双击可除专利审查意见回复模板 篇一：专利意见陈述书模板 意见陈述书 尊敬的审查员： 本意见陈述是对×年×月×日发出的第×次审查意见 通知书的答复，随此意见陈述书附上新修改的权利要求书全文。 （一）修改说明 申请人仔细研究了审查意见及其所引用的对比文件后，对权利要求书修改如下： 将技术特征“xxx”补入权利要求1中。 该技术特征记载在（原说明书什么位置或权利要求几中），因此修改未超出原说明书和权利要求书记载的范围。该修改是为了克服审查意见通知书指出的权利要求1（不具

备新颖性）的缺陷。因此上述修改既符合《专利法》第33条的规定，也符合《专利法实施细则》第51条第3款的规定。 （二）关于新颖性和创造性 1.修改后的权利要求1具备《专利法》第22条第2款规定的新颖性。 修改后的权利要求1与对比文件1相比，具有区别技术特征a，因此，权利要求1请求保护的技术方案不同于对比文件1公开的技术方案，权利要求1相对于对比文件1具备新颖性。 2.修改后的权利要求1具备《专利法》第22条第3款规定的创造性。 （a.确定最接近的现有技术。） 对比文件1与本申请的技术领域相同，且公开的技术特征最多，因此，对比文件1是本申请最接近的现有技术。 （b.确定区别特征和实际解决的技术问题） 修改后的权利要求1与对比文件1相比，具有区别特征a，由此本发明实际要解决的技术问题是

(c．判断要求保护的发明对本领域技术人员是否显而易见) 对比文件2虽然公开了上述区别技术特征a，但a在对 比文件2中所起的作用为,而由本申请说明书可知，a在本发明中所起的作用为，由此可知，a在对比文件2中所起的作 用与其在本发明中的作用是不一样的。本领域技术人员看到对比文件2时，不可能很容易的想到将a应用到最接近的现有技术中来解决本发明的技术问题，也就是说对比文件2未给出将a与对比文件1相结合来解决本发明技术问题的启示。 上述区别特征a也不是本领域的技术人员的惯用技术手段。因此修改后的权利要求1具有突出的实质性特点。 采用权利要求1的技术方案，（产生了什么样的技术效果）。因而改权利要求1具有显著的进步。 综上所述，修改后权利要求1相对于现有技术具有突出的实质性特点和显著的进步，具备《专利法》第22条第3 款规定的创造性。 3.从属权利要求也具备《专利法》第22条第3款规定 的创造性。 在独立权利要求1具备创造性时，其从属权利要求也具备创造性。

代码审查规范

代码审查规范 LG GROUP system office room 【LGA16H-LGYY-LGUA8Q8-LGA162】

代码审查规范 1. Code Review目的 Code Review是一种用来确认方案设计和代码实现的质量保证机制，通过这个机制我们可以对代码、测试过程和注释进行检查。 Code Review主要用来在软件工程过程中改进代码质量，通过Code Review可以达到如下目的：在项目早期就能够发现代码中的BUG。 帮助初级开发人员学习高级开发人员的经验，达到知识共享。 避免开发人员犯一些很常见，很普通的错误。 保证项目组人员的良好沟通。 项目或产品的代码更容易维护。 2. Code Review的前提条件 代码提交审核前，开发者必须确保代码符合如下条件，审核者需要确保所有前提条件都已满足方可开始审查，同时也是审查的主要检查点。 所有代码注释清晰，语法正确，编译通过。 日志代码完整，业务日志、系统日志分开，中文描述，脱敏处理，状态变更，全部清晰明确。 测试代码覆盖全部分支和流程，暂时统一使用工具Emma（各编译器可下载对应插件）进行Coverage Check。 项目引用关系明确，依赖关系清晰，配置文件描述。 3. Code Review的审查范围 代码的一致性、编码风格、代码的安全问题、脱敏问题、代码冗余、是否正确设计以符合设计要求（性能、功能）与设计文档相同等等。 、完整性检查（Completeness） 代码是否完全实现了设计文档中所涉及的所有流程和功能点 代码是否已包含所有所需的业务日志、系统日志、异常日志，日志内容是否完整，日志文件配置是否正确。 代码是否使用缓存等，配置信息是否正确可配置。 代码中是否存在任何没有定义或没有引用到的变量、常数或数据类型等 、一致性检查（Consistency）

代码审查(Code Review)

代码审查(Code Review) 一、概述 代码审查（Code Review)是软件开发中常用的手段，和QA测试相比，它更容易发现和架构以及时序相关等较难发现的问题，还可以帮助团队成员提高编程技能，统一编程风格等，目前监控团队虽然提倡代码审查，也有相关的辅助工具，但是一直没有真正的推行起来，这半年的时间里，一些线上的bug如果经过代码审查，基本上可以避免的，大家也逐渐认识到代码审查可以有效地提高代码质量。 二、代码审查的作用 1、提高代码质量。 通过代码审查来发现bug及代码中的不规范，这是不容置疑的，通过代码审查，代码将更加整洁，有更好的注释，更好的程序结构。 2、提高开发者开发水平。 开发者知道自己编写的代码会被同事审查，将会更加认真的编写代码，也将会督促开者不断地学习、向有经验的同事请教。 3、提高程序的可维护性。 一份程序代码将会有更多的同事熟悉，更好的代码质量，自

然地也增加程序的可维护性。 4、提高开发者的对编码的责任感。 如果你在编程，而且知道将会有同事检查你的代码，你编程态度就完全不一样了。你写出的代码将更加整洁，有更好的注释，更好的程序结构——因为你知道，那个你很在意的人将会查看你的程序。没有代码审查，你知道人们最终还是会看你的程序。但这种事情不是立即发生的事，它不会给你带来同等的紧迫感，它不会给你相同的个人评判的那种感受。 5、传播知识 在很多的开发团队里，经常每一个人负责一个核心模块，每个人都只关注他自己的那个模块。除非是同事的模块影响了自己的程序，他们从不相互交流。这种情况的后果是，每个模块只有一个人熟悉里面的代码。如果这个人休假或——但愿不是——辞职了，其他人则束手无策。通过代码审查，至少会有两个人熟悉这些程序——作者，以及审查者。审查者并不能像程序的作者一样对程序十分了解——但他会熟悉程序的设计和架构，这是极其重要的。 三、代码审查的执行障碍 1、缺少代码审查的标准 缺少代码审查的标准，往往审查人员习惯性地根据自身开发经验去进行代码审查，容易变成去挑毛病，找bug，容易产生

答复审查意见通知书通用格式

答复审查意见通知书通用格式 尊敬的审查员先生/女士： 首先感谢您对本申请的认真审查。对于审查员的意见，申请人进行了认真的研读，（简述审查员的意见，表明同意或者不同意查员的建议，）申请人对申请文件做出了修改并陈述意见如下： 1.修改说明 （针对新修改的独立权利要求和从属权利要求逐一分析，说明出处。） 以上修改均未超出原始说明书和权利要求书所记载的范围，符合《专利法》三十三条的规定，具体内容参见修改后的权利要求书。 新修改后的独立权利要求为： 1．本发明涉及…… 2.关于新颖性 对比文件1涉及(简述对比文件1的发明要点)。 （与新修改后的独立权利要求对比，阐明不同，可用例句如下： （1）对比文件1披露了新修改独立权利要求1前叙部分的内容，但未披露“本发明区别技术特征”； （2）与对比文件1相比，本发明具有***的区别技术特征) 所以新修改后的独立权利要求1与文件1对比符合《专利法》二十二条二款和《审查指南》规定的新颖性的要求。 对本文件2涉及（简述对比文件2的发明要点）。 （与新修改后的独立权利要求对比，阐明不同）所以新修改后的独立权利要求1与文件2相比符合《专利法》二十二条二款和《审查指南》规定的新颖性的要求。 权利要求2～*是对独立权利要求1进一步限定的从属权利要求，由于修改后的权利要求1具有新颖性，因而其从属权利要求2～*也具备新颖性。 3．关于创造性（“三步法”（确定最接近的现有技术→确定发明的区别特征和发明实际解决的技术问题→指出现有技术中不存在相应的技术启示）） （第一步：确定最接近现有技术）

在审查意见通知书所提供的对比文件中，由于对比文件*与本发明技术领域相同，要解决的技术问题相近，且公开本文中的相同技术特征也比较多，，所以，确定对比文件*为最接近现有技术。 （第二步：与最接近现有技术对比） 与最接近现有技术对比文件*相比，修改后的独立权利要求1所述的技术方案与它之间的区别技术特征是（论述区别技术特征）。由此可知，本发明要解决的技术问题是。最接近现有技术对比文件*并没有给出解决此技术问题的技术手段，也没有给出解决此问题的相关启示。 （第三步：将最接近现有技术与其他文件结合对比） （其后的论述分两种情况：第一种，修改后权利要求1中的区别技术特征没有在其他对比文件中披露；第二种，该区别技术特征虽在其他对比文件中披露，但它们在该篇对比文件中起到的作用与为解决本发明针对的技术问题所起到的作用不同。） （第一种） 修改后权利要求1中的区别技术特征没有在其他对比文件中披露，也不是本领域技术人员解决所述技术问题的公知常用手段，对本领域的技术人员来说是非显而易见的，具有突出的实质性特点； （第二种） 修改后权利要求1中的区别技术特征虽在对比文件*中披露，但它们在该篇对比文件中起到的作用是，与为解决本发明针对的技术问题所起到的作用不同。从而该篇对比文件以及其他对比文件和公知常识没有给出将上述区别技术特征应用到最接近现有技术上以解决此本发明中要解决的（具体技术问题）问题的启示，由此可知从上述对比文件和公知常识得到该独立权利要求的技术方案对本领域的技术人员是非显而易见的，具有突出的实质性特点； 修改后权利要求1所提到的技术方案，（解决的技术问题和有益效果），具有显著进步。 综上所述，修改后的独立权利要求1相对于最接近现有技术对比文件*或者其同*的结合，都具有突出的特点和显著的进步，符合《专利法》22条3款关于

代码审查规范

代码审查规范

目录 引言 (3) 目的 (3) 说明 (3) 代码审查 (3) 检查点 (3) 审查流程图 (4) 流程概述 (5) 具体流程 (5) 建立任务 (5) 桌面检查 (5) 团体评审 (5) Bug修复 (5) Bug复检 (5)

引言 目的 检查开发/前端人员是否遵守开发规范中的规定 检查开发/前端人员是否代码审定表中的错误 检查代码是否存在逻辑错误或安全问题 说明 代码检查每月进行一次，根据《代码审查表》的内容进行检查，结果计入绩效考核-开发质量项。代码审查 检查点 参见《代码审查表》。

审查流程图 类型

流程概述 1.建立任务：建立代码检查任务，指定需评审的项目或代码文件范围、参与评审的人员、定义问题类型及 严重级别等。 2.桌面检查阶段：开始各审查人独自评审，将可能出现的问题加入代码管理的Bug列表。 3.团队评审阶段：合并上步审查结果，统一讨论桌面检查阶段的问题，实施交叉检定，确定是否Bug，需 要修复的分配解决人员。 4.问题修复阶段：修改人修复分配给自己的问题，修复后修改Bug状态，审查人复查无误后，关闭Bug。具体流程 建立任务 1.选择一个要检查的项目。 2.确定此次检查的重点内容和主要关注的Bug类型。 3.新建OA流程发起新的检查任务，告知相关人员。 4.定义错误严重级别，划分各审查人检查范围，指定Bug文档位置。 桌面检查 1.获取要检查的源代码更新，使用分析工具寻找Bug。 2.简单的风格类Bug如缩进、换行格式等，可直接修改后等待发布。 3.人工检查代码，查找使用工具无法找到的错误。 4.使用文档记录Bug。标记问题类型及严重性，出现位置和操作场景。 5.桌面检查完毕后，所有审查人将Bug文档合并至到源码管理工具。 团体评审 1.审查成员在一起，从源码管理工具获取更新的Bug文档。 2.按照文档交叉检定其他人提交的Bug是否存在，Bug描述是否完整。 3.Bug文档在集体确认后，一起讨论代码中的Bug存在问题及处理优先级。 4.对高优先级的Bug优先分配人手，并制定解决方案。 5.团队评审完毕后，更新Bug文档，并将确定需要处理的Bug分发给指定修改人。 Bug修复 1.个人回到自己的工位，更新最新的Bug文档，并获取指定给自己的Bug。 2.将分配给自己的问题，按解决方案的指定逐一修复，并进行测试。 3.将修改后的源代码提交至管理工具，修改指定给自己的Bug状态，修改Bug文档说明。 Bug复检 1.审查人更新最新的Bug文档，依据文档逐一检查Bug修改。 2.如有功能变动或逻辑变化，需要加入测试人员的黑盒测试，进行二次确认。 3.Bug修改未完成的，退回到Bug修复。 4.已修复的Bug，将复检结果更新至Bug文档。 5.所有Bug修复、复检完成后，联同风格类Bug合并进行发布部署。 6. 7. 8.

审查意见答复模板

次审查意见通日就题述专利申请发出的第针对专利局于年月知书，对权利要求书进行了修改，申请人现陈述意见如下：1的创造性一、关于权利要求具备创造性，符合专利法第二相对于对比文件1 申请人认为权利要求1十二条第三款的规定。理由如下： 2保护范围不清楚的问题二、关于权利要求关于修改：该修改仅仅1中，申 请人将权利要求4中的附加技术特征添加到权利要求因此该修改是能够得到说明是权利要求的合并，并未涉及到实质内容的修改，并且申请人认为修改之后的权利要书的支持，符合专利法第三十三条的规定，符合专利法第二十二条是具有创造性的，1和对比文件2求1相对于对比文件第三款的规定。理由如下：所述诊断策略包含从诊断模块运行的程序“其中，申请人将附加技术特征中。组合”添加到权利要求1“诊断策略包含从诊断模块5段记载了在本申请说明书中的第4页倒数第，因此，上述修改是能够得到说明书的支持的，符合专利法运行的程序组合”1相对于对比文件第三十三条的规定，并且申请人认为修改之后的 权利要求1具有创造性，符合专利法第二十二条第三款的规定。理由如下：关于修改2： 申请人将权利要求1中记载的“确定所述第一时偏值或所述第二时偏值作为所述初始测距的时偏”修改为“根据时偏值和/或符号的峰值功率，确定所1”添加到权利要求述第一时偏值或所述第二时偏值作为所述初始测距的时偏 从这几个公式页中记载了时偏处理方法的几个公式，中，在本申请说明书第9 中可以直接毫无疑义确定的是在确定第一时偏值或第二时偏值作为初始测距或符号的峰值功率所确定的，因此，上述修改是/的时偏时，是根据时偏值和该修改是能够得到说明能够从说明记载的内容中直接毫无疑义确定的，因此，书的支持的，符合专利法第三十三条的规定。并且，申请人认为，修改之后的符合专利法第二十二条第三款权利要求1相对于对比文件1是具备创造性的，的规定。 理由如下：评创造性时结尾套话所述电子业务指南系统按照电子业务指综上所述，“权利要求1中记载的 得到南格式对所述待发布的广告 信息与电子业务指南节目提示信息进行封装， （争辩的技术特征）并没有被对比封装后的所述电子业务指南节目提示信息” 移动多媒的基础上无法得到解 决1所公开。本领域技术人员在对比文件1文件的技术问题的任何技术启系统目前不能融入广告信息体广播业务系统的ESG 是非显而易见的，具备突出的实质性特1相对于对比文件示，即，权利要求1系统利润的持续ESG1可以达到有效开展增值业务并保证点。此外，权利要求 增长的效果，具备显著的进步。因此，权利要求1相对于对比文件1具有突出的实质性特点和显著的进

对技术性审查意见回复要求细则(最新)

对技术性审查意见回复的要求细则 一、技术性审查意见回复要求： 济宁市建筑工程施工图审查中心对建筑工程施工图设计文件进行了技术性审查，所提出的《技术性审查意见》，设计单位应以《对XXX工程施工图技术性审查意见的回复意见》文件形式,并附必要的修改或补充图纸、及相关设计变更予以逐条答复,返回审查中心。该《回复意见》将作为审查中心编制该项目施工图审查报告的重要依据,有关要求如下： 1、图幅：回复意见应采用A4。回复意见及设计变更（一式五份），修改后的施工图（三套）。 2、文字：应打印,不得采用手写。 3、具体要求：首先把报告中的问题列出,然后进行答复，要说明修改的内容具体在哪一张图纸中,如另补变更图或变更书,应说明图纸或变更编号。 4、具体格式举例： 对XXX工程施工图技术性审查意见的回复意见 济宁市建筑工程施工图审查中心： 我院于XX年X月X日收到建设单位提供的你中心对XXX工程的施工图技术性审查意见,现对审查意见中提出的问题逐条答复如下： （一）、建筑专业： 1、审查意见中第1条：楼梯所选用栏杆水平段长度大于500mm,其高度小于1.05m，不符合《住宅建筑规范》GB50386-2005第5.2.3条的规定。 答复：根据强制性规范条文的要求,已在建筑设计说明中进行修改,同时在建施06中楼梯剖面图中加注高度。 2、审查意见第2条：楼梯入口处洞口高度小于2.l m,不符合山东省标准《住宅建筑设计标准》DBJ14-SI-2000中第4.2.2条的规定。 答复：根据规定,已在建施07剖面图中修改尺寸，同时结施08中雨蓬梁已修改标高。 3、…… （二）、结构专业： 1、审查意见中第1条,结施08中通向屋面M9上口雨蓬板缺少配筋详图. 答复：已在结施08中进行修改。（或在XXX年X月X设计变更第6条中进行变更并补画配筋详图） 2、…… （三）、水、电、暖专业：略 设计人审核人 建筑：签字签字 结构：签字签字 电气：签字签字 暖通：签字签字 给排水：签字签字 XXX建筑设计院（公章） XX年X月X日 二、设计单位修改后的施工图（三套）及出具的设计变更书（一式五份）、设计单位填写的《节能备 案登记表》（应由设计单位及建设单位盖章）（一式三份），一并返回审图中心收发室复查。