夜雨聆风一套证据，两场官司，法律上到底行不行？
在软件知识产权维权中，权利人往往同时拥有两件“武器”：一件是软件的著作权，保护的是代码本身不被抄袭；另一件是软件所实现方法的发明专利权，保护的是背后的技术方案不被非法实施。
当发现被告的软件既“长得像”又“跑得一样”，一个很自然的策略问题就冒了出来：我在著作权侵权官司里辛辛苦苦拿到的证据，尤其是源代码比对的结果，能不能直接用来证明对方也侵犯了我的方法专利？
这个问题不能简单回答“能”或“不能”。我们不妨顺着法律的逻辑，一步步把它说清楚。
法律是怎么规定的？
要回答这个问题，首先得把两类侵权的法律规则分清楚。
软件著作权侵权，看的是“表达”。 《世界知识产权组织版权条约》第2条写得明白：版权保护延及表达，而不延及思想、过程、操作方法或数学概念本身。我国加入该条约的决定也确认了这一原则。落实到国内法，《计算机软件保护条例》第2条和第6条进一步明确，软件著作权保护的是计算机程序及其有关文档。判断侵权的标准，是看被告的软件与原告的软件在代码、结构、组织等方面是否构成“实质性相似”，再加上是否有“接触”的可能。
软件方法专利侵权，看的是“技术方案”。 《最高人民法院关于审理侵犯专利权纠纷案件应用法律解释》第7条规定，判断是否落入专利保护范围，必须审查权利要求记载的全部技术特征。也就是说，被告软件是不是用了专利里描述的每一个步骤、每一种算法、每一层逻辑。而且根据《最高人民法院关于审理专利纠纷案件适用法律问题的若干规定》第13条，这个保护范围不仅包括相同的技术特征，还包括等同的特征——即“以基本相同的手段，实现基本相同的功能，达到基本相同的效果”。
把这两套规则放在一起看，就能发现一个有意思的关系：代码是技术方案的载体。一份源代码，既是著作权保护的对象（表达），也是专利技术方案的“说明书”。如果两份软件的代码相同或实质性相似，那么它们实现的技术方案相同的概率就极高。反过来，代码不同，不等于技术方案不同——可能只是换了一种写法，但手段、功能、效果实质相同，这在专利法上叫“等同侵权”。
所以法律上的大方向是明确的：源代码证据在著作权案件中是核心，在专利案件中同样具有极高的证据价值。但不能简单地把“代码相似”等同于“专利侵权成立”，专利侵权需要独立的技术特征比对。
司法实践中是怎么做的？
光有法律条文还不够，我们得看看法院在实际案件里是怎么操作的。
最典型的是“百度输入法”案（（2018）沪民终134号）。 原告主张百度输入法的“隐式自造词”功能侵犯了其“建立用户多元库”的方法专利。原告首先通过一系列实验，证明百度输入法在运行过程中表现出了专利限定的全部功能效果。这时候，法院认为原告已经完成了初步举证责任，举证责任转移到了被告一方——百度需要证明自己虽然实现了相似的功能，但采用的是不同的技术方案。
百度是怎么证明的？主动向法院提交了被控侵权软件的源代码进行勘验。 法院通过审阅源代码，确认了百度输入法“隐式自造词”技术方案中的源程序和算法，最终认定其与专利技术特征所采用的手段不同，不构成侵权。
这个案子告诉我们两件事：第一，源代码是证明软件内部技术方案最直接、最有力的证据；第二，在软件专利侵权案件中，权利人不需要一开始就拿到对方的源代码——只要能证明被控软件具备了专利的全部功能，举证责任就会转移到被告，被告往往不得不拿出自己的源代码来自证清白。
另一个值得关注的是最高法指导性案例“石鸿林案”（（2007）苏民三终字第0018号）。 这个案子本身是著作权侵权，但它的逻辑可以迁移到专利场景。原告无法获得被告软件的源代码，于是委托鉴定机构对两款软件进行运行测试。结果发现，两款软件存在相同的系统软件缺陷——连续加工程序段超过2048条后都无法正常执行，这在正常独立开发的软件中几乎不可能出现。法院据此认定，结合其他外围证据，可以形成高度盖然性优势，推定两款软件的源代码构成实质性相似。
这个逻辑在专利侵权中同样有效：如果被告软件存在与专利方法实现过程中特有的、非公知的缺陷或运行特征，这不仅是著作权侵权的有力证据，也是推断其采用了相同技术方案的强有力线索。
法律依据上，《最高人民法院关于知识产权民事诉讼证据的若干规定》第19条给了我们一个明确的制度接口。 该条规定，法院可以就“被诉侵权技术方案与专利技术方案在手段、功能、效果等方面的异同”以及“被诉侵权作品与主张权利的作品的异同”委托鉴定。两个问题并列规定，意味着在竞合案件中，完全可以委托同一家鉴定机构、基于同一套检材（源代码），同时出具关于著作权相似性和专利技术特征等同性的鉴定意见。
落实到实务中，应该怎么操作？
基于以上法律规则和司法实践，我们可以得出一个务实的结论：软著侵权证据，尤其是源代码比对结果，完全可以用于支持软件方法专利侵权的主张。 但这种支持不是自动发生的，需要一套精心设计的诉讼策略和证据体系。
首先，证据的收集要“一证两用”。
一份完整的证据清单应该包括四个层面：
权利证明类，包括软件著作权登记证书、专利证书，以及最能体现专利方法技术细节的源代码和开发文档。这些材料既是著作权权属的证明，也是解释专利权利要求、证明“该方法可以由软件实现”的基础。
接触可能类证据，比如被告关键技术人员曾在权利人处任职的证明、双方曾经的合作文件、系统日志显示的代码库访问记录等。这类证据在著作权侵权中用于满足“接触”要件，在专利侵权中则为“非法实施”的主观状态提供背景事实。
技术比对类证据是核心中的核心。最理想的是通过法院证据保全直接获得被控软件的源代码，进行逐行或模块化比对——既能证明著作权层面的表达相似，也能直接分析其算法流程是否落入专利保护范围。在无法获得源代码的情况下，可以对目标程序进行反编译，获得汇编或中间代码进行比对，就像“美摄诉抖音案”中所做的那样。此外，还可以通过公证保全记录被控软件的运行输入输出，证明其具备了专利限定的全部功能；或者寻找双方软件共有的、非公知的缺陷或特殊运行特征，作为推定源代码同一性、进而推定技术方案同一性的间接证据。
损害赔偿类证据，如被告的财务账簿、销售合同、宣传材料、上市公司年报等，在两类侵权诉讼中都可以用于计算侵权获利，证据完全通用。
其次，诉讼程序上要善用举证责任转移。
在软件专利侵权诉讼中，权利人不需要一开始就拿到被告的源代码。正确的打法是：先通过公证、实验等方式，证明被控软件在运行时表现出了专利方法所限定的全部功能和效果。这完成了初步举证责任。根据“百度输入法”案确立的规则，此时举证责任转移至被告——被告如果主张其采用了不同的技术方案，就应当提交其源代码或充分的技术资料进行反证。如果被告无正当理由拒不提供，法院可以根据现有证据作出对其不利的推定。
最后，有几个风险点不能忽视。
第一，不能忽视“表达方式有限”抗辩。《计算机软件保护条例》第29条规定，如果被控侵权软件的相似是因为可供选用的表达方式有限，则不构成著作权侵权。但这一抗辩不影响专利侵权判定——即使表达方式有限，技术方案仍然可能落入专利保护范围，两者需要分别判断。
第二，不能忽视证据的合法性与清洁度。最高人民法院在（2021）最高法知民终1295号案中明确指出，如果检材来源不明、取证程序存在重大瑕疵，鉴定意见将不被采信。权利人应当优先通过公证购买、法院证据保全或具有资质的第三方存证平台（如可信时间戳、区块链存证）来获取侵权软件。
第三，不能忽视等同侵权的可能性。即使被告的源代码与原告不同，但如果其采用了与专利技术特征“基本相同的手段，实现基本相同的功能，达到基本相同的效果”，仍可能构成等同侵权。这需要鉴定机构和法院进行专业判断，而不能仅凭代码是否相同来下结论。
总结
回到最初的问题：软著侵权证据，能不能用来证明软件方法专利侵权？
答案是：能，但要有方法。
法律规则告诉我们，代码是技术方案的载体，源代码比对对两类侵权都有证明价值。司法实践告诉我们，法院已经在“百度输入法”案中明确将源代码勘验作为查明技术事实的核心方法，在“石鸿林案”中认可了通过运行缺陷推定源代码同一性的逻辑。实务策略告诉我们，只要证据收集得当、程序运用合理，完全可以实现“一套证据、两场官司”的目标。
对于权利人来说，这意味着在启动软件著作权侵权诉讼之初，就应当以专利侵权的最终证明标准来规划和固定证据。一个规范的公证购买、一次完整的源代码保全、一份精心设计的鉴定委托，可能会同时决定两场战役的胜负。
对于律师来说，这意味着不仅要懂著作权法的“形”，更要懂专利法的“神”，更要懂得如何让“形”为“神”服务。
