使用逆向工程来发现软件专利侵权

为什么软件逆向工程是专利诉讼中的重要工具，即使源代码也同样可用。

想象一个发生了一些事件的建筑工地，并想象一些关于该事件的诉讼。双方都在盯着图纸，但奇怪的是，没有人参观过建筑工地。当然，蓝图提供了很多从建筑物或工地看不到的信息。但由于“竣工”施工与原始蓝图有很大不同，更根本的是，由于建筑物和它的蓝图是两个不同的东西，如果不调查实际工地，很难想象施工诉讼。

许多软件诉讼可以类比为建筑纠纷，其中只咨询蓝图，而不查看建筑物。

在涉及计算机软件的专利侵权案件中，深入的事实调查往往等待对手在发现其密切持有的源代码时进行生产。一旦生成了源代码，调查的重点仍然是那里——即使产品本身可以在eBay上以50美元的价格购买。

与建筑物的蓝图大体相似，源代码包含了基于软件的产品的计划——但它不是产品本身。软件产品——例如Microsoft Windows、网站Flash动画、佳能相机内的“固件”或PlayStation游戏——通常作为目标代码分发（“开源”产品是一个重要的例外）。目标代码包含对计算机（例如PC或位于数码相机内的微处理器）的指令。这些指令告诉计算机如何表现得像操作系统、文字处理器、游戏或软件产品提供的任何其他功能。

计算机程序员创建这些指令，但通常是间接的：他们编写源代码（看起来像是pidgin英语和数学的组合），然后将其翻译（“编译”）为目标代码，然后将其打包到CD或互联网上——下载文件成为销售给客户的产品。

因此，软件诉讼关注源代码是有道理的。毕竟，当您可以得到人类编写的原件时，为什么还要费心翻译——只有计算机才能立即读取的翻译？

但这只是问题所在：直到诉讼的某个阶段，您才能获得对方的源代码。它被产品的所有者紧紧抓住。这提出了在软件专利诉讼中有时被视为先有鸡还是先有蛋的问题。

根据FRCP第11条，律师必须有合理的专利侵权投诉依据。合理依据有两个方面：权利要求解释，以及将被指控的设备或方法与这些权利要求进行比较。一旦软件专利案件滚动，比较将使用对手的源代码在索赔表中呈现，该源代码是在发现过程中产生的。但是发现需要一个案例，这需要一个投诉，而这反过来又需要一些合理的依据，正如刚才提到的。

除规则11外，地方专利规则通常要求专利侵权原告在案件早期提供详细的侵权论点，在发现之前描述至少一项主张权利要求的每个限制位于每个被控产品或过程中的位置。法院将此要求解释为反过来要求“逆向工程或其等效”（参见例如Network Caching v.Novell,ND Cal.,2002）。

因此，软件专利侵权索赔的合理依据，即预先提交和因此预先发现，通常必须基于对手紧紧持有的源代码之外的其他东西。

那靠什么？客户只是这么说并不是一个合理的依据。被指控的侵权者的营销材料或产品文档通常也不是。查看Engineering v.Robotic Vision Systems,208 F.3d 981（Fed.Cir.,2001）（仅基于对手的广告和向客户提出的索赔时，侵权索赔不充分）。用于调查过程和方法专利侵权的方法，例如使用对手的监管文件、与其客户和供应商交谈以及查看最近的价格变化和资本改进，虽然有用，但可能对软件的适用性有限。

那么，至少在您获得源代码之前，这个先有鸡还是先有蛋的问题的解决方案是让专家仔细检查实际的软件产品。换句话说，逆向工程（RE）。RE通常在IP上下文中作为一个待解决的问题出现（在RE期间制作的中间副本是否侵犯版权？；收缩包装许可协议能否强制禁止RE？）。然而，在这里，RE不是问题，而是用于回答一个事实问题的工具：D的产品是否实践了P发明的这一主张？

逆向工程的法律定义是“从已知产品开始，向后推算有助于其开发或制造的过程”。Kewanee Oil诉Bicron，416 US 470(1974)。事实上，软件RE更多的是向上不是向后工作。与其尝试重建原始源代码，不如从产品的较低级别细节中了解产品的“内置”设计。这是一个归纳过程，有点类似于普通法从无数特定事实案例中推断出的黑体法。通常，软件RE的目标不是复制原始产品，而是与其互操作或了解其缺陷。

如果产品本身是通过公平和诚实的方式获得的，美国商业秘密法将RE视为了解商业秘密的适当手段。统一商业秘密法(1985)§1（评论）。（然而，通过公平和诚实的方式进行收购可能是一个大的或至少是中等规模的“如果”。例如，来自广泛的“beta”测试的逆向工程软件呢，在该测试中，接收者亲自签署了禁止逆向工程条款但另一方面，软件供应商一直在向媒体广泛“泄密”？这些事实来自早期软件专利案件的商业机密部分，Stac v.Microsoft。）

同时，大多数软件最终用户许可协议(EULA)明确禁止逆向工程。例如，Microsoft Windows EULA规定：“对逆向工程、反编译和拆卸的限制。您不得对软件进行反向工程、反编译或反汇编，除非且仅在适用法律明确允许此类活动的情况下，尽管有此限制。”

然而，在具有收缩包装或点击包装许可的大众市场产品的背景下，如果RE有正当理由并且没有其他方式访问其他不受保护的元素时，此类限制通常被视为无法执行（Sega v.Accolade,977 F.2d 1510(9th Cir.,1993))—并且，如Microsoft条款的“除外”部分所示，这通常反映在EULA本身中。（非大众市场环境中的软件可能会呈现不同的故事。）

即使考虑到对可再生能源的可强制执行的软件许可禁令，在诉讼中使用可再生能源的成果也可能属于司法程序的合理使用例外。虽然并非所有法院都认为在法律诉讼中使用受版权保护的作品是“固有的”合理使用（Shell v.DeVries,2007 WL 4269047(10th Cir.)），但只要司法使用不是作品的“内在目的”，一些法院就会这样做（Jartech v.Clancy,666 F.2d 403(9th Cir.,1982)），合理使用在任何情况下通常都可以在标准的四因素测试下找到（例如，Shell v.DeVries，其中D未能支付P每页5,000美元从网站打印的“费用”）。

事实上，规则11在某些情况下被解释为要求对产品进行逆向工程作为申请前调查的一部分。Judin v.US and Hewlett-Packard(110 F.3d 780(Fed.Cir.,1997)；律师因依赖微光学成像专利的发明者而未尝试检查邮政服务条码扫描仪而受到制裁），Antonious v.Spalding and Evenflo(275 F.3d 1066(Fed.Cir.,2002)；未能切开并检查所有相关高尔夫球杆)，Bender诉Maxim Integrated Products(2010 WL 2991257(ND Cal.)；原告纠正了相反的情况工程不是绝对要求，但这里RE可能只是产生足够具体的侵权争论的方法。

与此同时，人们一直认为目标代码是难以理解的，即使是专家也无法理解，或者软件RE是不可行的。一些法院在等待源代码时允许不充分的侵权争论。NYU v.E.Piphany(2006 WL 559573(SDNY,2006)；将没有源代码的足够详细的初步侵权争议描述为“Catch 22”，并要求被告提供源代码以便原告可以更具体地了解声称，引用American Video Graphics诉Electronic Arts(359 F.Supp.2d 558(ED Tex.,2005))。

然而，除了目标代码本身不可用（例如隐藏在对手的网络服务器上）的情况之外，通常可以从软件RE中了解侵权情况。

特别是，软件产品内部有很多可立即理解的文本信息，隐藏在视线中。

从软件产品中提取信息

从软件中提取信息的一种方法是如此简单，以至于它可能应该被视为简单的视觉检查而不是逆向工程。这些信息就是程序员所说的“字符串”——人类可读的文本序列——用于提取这些信息的软件工具也称为字符串。

字符串不仅包括菜单和对话框的文本，还包括错误消息、内部诊断、自检和留在产品中的“调试”信息。值得注意的是，即使是严格保护其源代码作为“皇冠上的宝石”的供应商，通常也会在其产品中发送包含重要源代码片段的调试信息。这些字符串通常包含产品实现和使用的功能名称。

无需运行程序即可看到这些字符串。所需要的是查看组成产品的目标代码文件，就好像它们是文档一样，与您自己的文字处理文档几乎没有什么不同。例如，Microsoft Word由名称为winword.exe和mso.dll的文件组成。当这些文件的内容被计算机解释为指令时，这些文件就变成了指令。在运行之前（例如，通过单击图标），程序文件实际上只是一个文件，可以像文件一样检查它。

随便举个例子，我现在使用的微型无线调制解调器包含嵌入式软件（“固件”）。调制解调器有固件更新，可在Internet上免费获取。用字符串程序检查这个固件会发现有数千行文本涉及调制解调器软件中使用的技术。

虽然看起来难以理解，但该文本与源代码一样难以理解。例如，字符串“GLMSSecURIReplaceFunc”可能表示提供安全替换组列表管理服务器中统一资源标识符（例如HTTP Web地址）的函数。作为自检的一部分留在产品中的代码片段“ptr_arpi_cb->arp_instance>LAN_LLE_MIN”是指地址解析协议和长链接仿真。为了强调这一点，这个源代码片段位于供应商在互联网上公开的更新文件中。

正如律师们了解到文档通常包含隐藏的元数据（例如以前草稿的残余）一样，软件中隐藏（几乎没有）的文本也是一个富有成果的探索领域。

软件元数据包括产品所依赖的其他软件，或者它使用或提供的服务的名称。此类服务称为应用程序编程接口(API)。导出API是为了使产品或第三方软件的一个可分离组件能够使用（导入）产品提供的某些功能。此功能通常使用其名称调用，而名称又通常包含在程序文件的元数据中作为导入/导出表。因此，提供该功能的组件和使用该功能的其他组件都将包含该名称。这些API通常反映与专利权利要求中的元素或步骤相对应的低级功能。API通常有文档记录（如果不是由供应商，则由第三方），因此知道产品A使用来自产品B的API，连同产品B的文档，可以告诉您有关产品A的一些信息，而无需产品A的来源代码。（它还可能提供有关产品B的信息，即使从产品B的源代码。）

在字符串和元数据之后，程序员有时称之为“幻数”的软件内部立即可读性稍差一些。例如，base-16数字5A827999表示使用安全散列算法(SHA)。因此，这些数字可以充当代表某些算法的指纹或签名，或作为其一部分。使用扫描文件以查找此类签名的实用程序将有助于推断产品使用某些算法。二进制代码也有“大代码”方法，这可能有助于挖掘大量代码的模式。

随附的方框“不只是一和零”总结了软件产品中易于确定的信息类型。

最著名的软件RE工具类型是反汇编器和反编译器。这些工具将目标代码翻译成人类可读的东西。反汇编器以可读的汇编语言显示目标代码。例如，这将允许专家从错误或警告消息追溯到触发它的代码。反编译器试图恢复原始源代码的一些外观。虽然通常不比将英文文本翻译成俄文，然后尝试从俄文翻译中恢复逐字的原始英文更可行，但对于一些编程语言，如Java或Flash动画(SWF)，以及Microsoft的.NET等环境，反编译是可能的.

上述技术都是以一种或另一种方式将软件产品作为一段文本来阅读的所有形式。这些技术可以归类为静态RE。另一组方法，动态RE，在另一个程序的控制下主动运行被指控的产品，该程序测试或跟踪产品的行为。动态RE工具包括调试器、网络监视器（数据包嗅探器）、文件监视器和API跟踪实用程序。请参阅随附的方框“软件逆向工程工具”。

对源代码使用逆向工程

那么有什么理由获取源代码吗？是的，即使只是用对方自己的文件来确认和证明自己的RE调查结果。此外，产品内部的目标代码在一个重要的意义上是不完整的。正如蓝图中的某些信息可能不会反映在完成的建筑中一样，注释（程序员在源代码中添加的注释，例如解释一段代码打算做什么，或者为什么以某种方式实现它）是一个重要的源代码组件，在编译过程中丢失，因此无法从目标代码中恢复。评论是在发现中寻找对手源代码的关键原因。

如果无法从产品中检索到评论，反之，产品中是否存在无法在源代码中读取的内容？也许令人惊讶的是，是的。因为并非所有的源代码都必须用于生产被诉产品，并且因为并非所有的代码都必须被执行，所以不能仅从源代码中的存在就假设给定的元素或步骤实际上是由被诉产品执行的。归根结底，受禁令或损害赔偿的是成品，而不是源代码。

源代码和产品是不同的（尽管相关）野兽也意味着对产品进行逆向工程可以帮助您在发现中获取源代码。

就像文字处理文档中删除的文本一样，软件产品可能在供应商不知情的情况下不仅包含源代码片段，还包含文件名甚至源代码的完整路径名。例如，前面提到的无线调制解调器固件更新包含诸如“gpssrch_dispatcher.c”之类的文件名，以及诸如“pistachio/kernel/src/generic/kmemory.cc”和“drivers\boot\boot_shared_progressive_boot_block.c”之类的路径名。其中一些对应于调制解调器中使用的开源软件；知道了这一点，至少可以访问这部分源代码，而无需向调制解调器供应商提出发现请求。（当然，供应商对开源代码的修改、添加和删除是另一回事。）

此外，如果您知道要调用的专有名词（“按名称询问”），则可以构建更好的发现请求。大多数软件产品都不是单体。您可能对特定模块的源代码特别感兴趣，您或您的专家可能会从产品中了解其名称和版本。令人惊讶的是，软件产品还经常包含开发人员姓名，可用于提出令人震惊的精确发现请求（“他们怎么知道？！”）。

最后，一旦您获得了源代码，有两种方法可以帮助您检查最终产品。您的专家将更好地了解在源中寻找什么。而且，如果产品包含文件名或路径名，就像他们经常做的那样，您可以交叉检查生成的源代码的完整性。令人惊讶的是，许多软件供应商并不拥有其产品的所有源代码。由于这个和其他原因，发现中生成的源代码可能不完整。这有时可以通过检查源代码中的交叉引用来确定，但产品中的文件名或路径名也有助于揭示缺少某些内容。

使用逆向工程定位现有技术

虽然本文重点关注软件专利侵权的备案前调查，但RE也可用于专利生命周期的其他阶段。特别是，上面提到的更简单的RE方法可用于显示先前使用或对其他未发布的软件发明的了解。在这里可能适用的是更简单的方法，例如“字符串”，而不是反汇编，因为先前的使用或知识仅在公开披露和启用时才预期。

一个有趣的问题是，一个公开可用的软件产品，其中包含一个以后可以被拆卸的未记录的发明，是否具有预期性，因为只有在拆卸时才能访问的信息可能被视为未公开披露。在Internet上的目标文件中清晰可见的字符串更有可能构成先前的使用或知识。这自然是从本文的基本观点出发的，即软件产品通常包含易于访问的有用信息——包括供应商有意或无意公开的源代码片段。

作者：安德鲁·舒尔曼

原文地址：https://www.softwarelitigationconsulting.com/articles/hiding-in-plain-sight-using-reverse-engineering-to-uncover-software-patent-infringement/