想象一下，你收到了一封信函，要求查看某些内容。打开后，你发现这是一份指控你服务侵犯了视频编码专利的侵权主张图表。该图表引用了标准文档和供应商图示，但没有提及你的源代码，而且除了你之外，没有人见过你的源代码。
编解码专利主张通常像一个食谱：每个步骤都代表主张的一个元素。侵权的意思是被控系统执行了所有步骤。如果缺少任何一个步骤，则整个主张就会失效。在阅读图表之前，这一点必须牢记在心。
我们见过的大多数图表都会走捷径，直接指向标准文档。其逻辑是，如果你实现了H.265或AV1编码，那么你必定执行了主张中描述的内容。当标准强制执行某个步骤时，法院通常会接受这一观点，但如果步骤是可选的，则法院的态度则不太友好。而实际的流媒体栈常常会跳过标准允许的很多可选项，这取决于配置文件、预设和硬件限制。令人惊讶的是，即使某个标准被广泛使用，也不意味着其所有的可选特性都是开启的。
大多数主张是针对编码器设计的，因此应从这里开始。同时，我们需要使用实际设置而不是理论设置。获取命令行或API调用，获得梯度定义。尝试确定每个预设启用的编码工具，因为图表无法在没有内部信息的情况下做到这一点。你肯定需要一些示例编码和日志记录。我在一次更新中遇到了这种情况，该更新改变了我们的输出，但直到我们查看日志才知道原因。
软件与硬件实现的编码器并不完全相同。基于CPU的软件预设和集成到云处理器中的硬件编码器在选择上有所不同。因此，不考虑这一点的主张图表并不全面。预设名称也不一定是安全的。“快速”模式在某个版本中启用的功能可能在下个版本中被禁用。
首先，确定谁拥有该代码。许多服务会授权编码器，你可能完全无法查看源代码。因此，你应尽早明确这一点。在回答任何问题之前，请务必阅读合同。
打包器主要负责包装。它所做的只是将流分成块并生成清单，而不会处理实际的编码视频数据。在某些情况下，由于与信号传递的关系，可能在此领域提出一些主张。参数集或SEI消息可能在你的管道中不受影响地传递。你需要明确这些消息是自己创建的还是仅仅传输的。因此，在作出任何假设之前，最好寻求法律建议。保存每种版本的一个样本段，并使用比特流分析器打开，以查看其中的确切内容。只有真实的文件才能解决单独用图示无法解决的争论。
我们知道，解码器主张针对播放器，因此需要考虑你实际交付的内容。手机中的另一家公司制造的芯片进行解码。你的应用程序请求播放视频并接收像素。但是，谁执行了你现在列出的所有步骤？如果多个实体执行步骤，法律规定应找出谁控制了其他步骤的执行。如果主张涉及整个系统，则应找出谁使系统运行。在对步骤作出任何主张之前，先绘制主张中的步骤图，并识别每个步骤。
还有一件重要的事情要注意。一些关于软件的主张很少具备能力，而有些则需要步骤。主张中使用的措辞决定了这一点。如果主张需要某些功能开启，则配置信息是证据。如果只需具备能力，则代码本身是证据。你需要仔细阅读动词。
在采取任何措施之前，首先记录配置和编码器版本，以防任何人调整设置。简单记录每个更改及其时间，这可以消除聊天渠道中的猜疑。我们可能侵权的说法不是科学事实。
你也应记录事实日期。2021年的管道并不是当前的管道。由于损害赔偿基于过去事件，记录必须包括这些日期。
然后构建自己的表格，每个主张元素一行，并为编码器、打包器和播放器各设一列。每个单元格填入证据和来源文件。诚实地标记空单元格。最后，在与对方首次通话前将表格提交给法律顾问。