【一】前言

在申请计算机软件著作权时，经常会因为提交的材料存在缺陷或错误被下发“补正通知”。
我们根据多年的申报经验，总结了在“使用手册/开发文档”和“源代码”两大鉴别材料中经常出现的补正原因和处理建议，供参考。

【二】《使用手册》常见补正原因

一、出现无法判定权利归属的logo
【情形01】logo确实归申请人所有，但该logo与申请人名称没有显著的关联关系，导致审核员无法判断该logo的权利归属，因而也无法判定该软件的权利归属。
【建议】若该logo已申请商标或作品著作权，应主动提交相关证书。若未申请，则应主动解释该logo的创作过程及含义。

【情形02】logo明显不归申请人所有（例如可以直观看出该logo是其他企业的商业字号），且在使用手册中频繁出现，导致审核员认为该软件可能是申请人“受托开发”，其著作权一般应当归“委托方”。
【建议】若“委托开发合同”中有条款规定该软件的著作权归“受托方”（申请人），则应主动提交该合同并显著标注出“权利归属条款”。若著作权确属“委托方”，则“受托方”不应申请软著登记。

【情形03】图片被刻意模糊/打码，且该区域通常是软件界面中放置logo的区域，导致审核员认为申请人刻意隐瞒“软件是受托研发、权利归委托方”的事实。
【建议】不应对“能够帮助审核员判断权利归属”的内容进行打码，仅可对部分涉及商业秘密的区域（比如各类报表中的真实数据等）进行局部打码。若存在上文“情形2”中的情况，应当按上文相关建议进行处理。

二、截图不符合要求导致无法判断软件真实性
【情形04】截图不全，包括没有浏览器外观或操作系统自带的窗口外观/标题栏/菜单栏等，导致审核员无法判断该图片是软件的真实界面，还是利用Photoshop或其他图像/原型设计软件临时做出的图片。
【建议】在前几张图片中，需要截取浏览器/操作系统桌面/操作系统窗口的完整截图。在后续功能介绍中，若出现“截图过大、不便演示功能使用方法”时，可以截取局部图片。

【情形05】图片模糊不清，导致审核员无法识别其内容，进而也无法判断该图片是否是软件的真实界面。
【建议】截图时应截取高清图片，插入word后，横向版式的图片宽度一般在10-14厘米为宜，不要对图片过度压缩，否则会因尺寸过小或压缩严重导致图片模糊不清。

【情形06】图片中显示的软件版本号与《申请表》中所填写的软件版本号不一致。
【建议】撰写前，撰写人员应明确知晓自己需要撰写该软件哪一个版本的使用手册。

【三】《源代码》常见补正原因

【情形07】此次提交的代码与已申请过的软著代码存在重复。
【建议】自2023年6月版权保护中心采用无纸化申请后，所提交的手册和代码都会经过系统比对（类似论文查重），因此在准备源代码时应当与先前已经申请的软著错开提取（尤其是按“版本升级”方式申请时）。

【情形08】源代码所实现的功能，未在操作手册中体现。
【建议】应当对照操作手册，提取与之相对应的源代码，尽量不要出现“手册中描述的是前端功能应用，而提交的却是后端数据和逻辑处理的源代码”的情况，以及“手册中描述的是功能A\B\C，但提交的却是功能A\D\E的代码”。

【情形09】最后一行代码不是结束语句。
【建议】最后一行代码应当是一个完整的程序结束语句，以html为例，结尾处应当是。其他编程语言，结束语句通常以} )等符号结尾。

【情形10】代码排版格式不符合要求，包括代码缩进不符合常见规范（含有大量空白行或空格）、加入了编程工具自带的行号等。
【建议】在整理软件代码时，先通过编程工具自带的“代码格式化”功能对代码重新排版。在插入到word文档时，不要包含编程工具生成的行号及颜色。建议先将代码拷贝到txt中去除字体/字号/颜色等属性后，再插入到word中。

【四】结语

除了上述常见的补正原因之外，我们还积累了其他偶发性的补正情况，并系统性地写成文字，放在了我们的“软著申请模板”中。因此，使用我们的模板撰写手册和提取代码的软件工程师，可以提前阅读并注意规避。

同时，我们也会将所代理并下发的软著证书集中保存在我们的NAS服务器中，以方便日后调阅。

【声明】本文核心内容是基于官方政策并根据实务经验总结而来，仅代表作者个人观点，实际应用时应以官方政策为准。如有漏误，欢迎批评指正。

业务合作：杨经理 131-2288-1414（微信同）

咨询交流：刘经理 139-1805-1433（微信同）

若您想使用微信收藏本文，可以查看我们官方公众号中的原始文稿：点此查看