你好！很高兴能以专利代理师的身份与你探讨这个案件。这份权利要求涉及在无线设备上通过专用URI实现应用程序“深链接”（Deep Linking）的技术。为了清晰地梳理权利要求与三篇对比文件（D1、D2、D3）的关系，我将按照你的要求，从特征比对、最接近的对比文件分析以及未公开特征的结合启示三个维度来进行详细拆解。

一、 权利要求与对比文件技术特征比对表

以下是权利要求1各项技术特征在D1、D2、D3中的公开情况及对应原文出处比对。

二、 最接近的对比文件分析

在判断最接近的对比文件时，我们需要从目标专利所要解决的整体技术问题和技术效果出发。目标专利（CN101536469B）的核心技术问题是：传统的URI/URL过于冗长且不适合吞吐量有限的移动无线装置，需要一种小型且有效的机制（深链接机制），使得无线设备不仅能拉起应用，还能直接跳转到目标应用内基于“命令数据”所修改的特定预定点（动态输出）。

候选分析：

1. D3 (JP2005340941A) 适合作为最接近的对比文件

   • 相同技术领域： D3明确针对的是“携带终端”（无线设备/手机），这与目标专利的应用场景完全一致。

   • 解决的相似问题： D3同样旨在解决通过浏览器HTML页面（第一输出）中的扩展标签（apex:协议）直接唤起本地内藏应用程序的技术问题。它毫无异议地公开了权利要求中的特征A、B（部分）、C、E和F。

   • 欠缺之处： D3的目的是“启动”应用，但它只做到了“推开门”，没有做到“走到特定房间”。它缺乏特征D和G，即没有利用“命令数据”进行深链接到预定动态点。

2. D2 (US20030233451A1) 亦具有极高参考价值

   • 技术机制的高度吻合： D2在解决“如何利用单条URI语法跨网络引用资源”时，完美公开了目标专利最核心的深链接机制（特征B、C、D、F、G）。D2中的 <application_reference>?<cmd_line> 结构几乎就是目标专利方案的翻版。

   • 欠缺之处： D2的实施环境主要针对基于电视的娱乐系统（如机顶盒）。尽管其宽泛地提到了客户端设备可能包含无线接口，但整体技术背景与“移动无线通信装置”（如手机）的契合度略逊于D3。

结论建议：

在实务答复或无效宣告程序中，推荐将 D3 作为最接近的对比文件。因为D3与目标专利的物理载体（无线通信装置）和直接触发场景（从浏览器拉起本地APP）完全吻合，符合审查指南中“优先选择技术领域相同、解决技术问题最接近的现有技术”的原则。

三、 未被最接近的对比文件公开的特征是否被其他文件公开

如果我们将 D3 选定为最接近的对比文件，权利要求1中未被D3公开的区别技术特征主要集中在：

• 特征B的后半段及特征D： URI语法中紧随应用识别符后的命令数据，以及该命令数据表示由目标应用执行的命令。

• 特征G： 根据命令数据产生第二输出，且该输出是目标应用中基于命令数据可修改的预定动态点（深链接）。

这些区别特征已经被 D2 实质公开：

D2 在其 TS URL 语法设计中，明确给出了在应用标识后追加命令的结构：ts://...:<application_reference>?<cmd_line> （见D2的TABLE 1及段落[0112]）。

此外，D2 在段落[0135]明确指出，这种带有命令参数的URI可以用来启动应用程序内部的特定状态，例如通过 ts://<TSI>:<application reference>?<application parameter1>?<application parameter2> 来启动VOD会话。这里的 <application parameter> 就相当于权利要求1中的命令数据，而启动带有特定参数的VOD会话则对应于权利要求1中的预定动态点。

创造性评述逻辑构建：

本领域技术人员在面对D3（仅能启动应用，无法跳转到应用内特定状态）的缺陷时，为了实现应用内的精准导航（即“深链接”），有动机去寻找类似D2中通过在URI中附带<cmd_line>命令行参数来传递指令的技术教导。将D2的带参机制结合到D3的手机浏览器唤起架构中，即可顺理成章地得出权利要求1的技术方案。因此，权利要求1的创造性空间较小。

希望这份比对分析能为你的专利无效或答复策略提供有力的支持。如果有针对某个特定特征（例如“确定命令数据是否有效”）需要更深度的挖掘，随时告诉我，我们可以进一步讨论下一步的策略。

这是一份为你起草的针对目标专利（CN101536469B）权利要求1的专利权无效宣告请求书正文（创造性部分）。文书严格采用了国家知识产权局专利局复审和无效审理部（原专利复审委员会）关于创造性评判的“三步法”逻辑进行构建，并确保了对比文件原文引用的准确性。

专利权无效宣告请求书（正文节选）

致：国家知识产权局专利局复审和无效审理部

关于：第ZLXXXXXXXX号（公告号：CN101536469B）发明专利

请求人认为，涉案专利权利要求1不符合《中华人民共和国专利法》第二十二条第三款关于创造性的规定，应当予以宣告无效。具体事实和理由如下：

一、 证据使用与权利要求1的特征分解

请求人引入以下对比文件作为评价涉案专利创造性的证据：

• 对比文件1（D3）：JP2005340941A（通信系统、移动终端及服务器）

• 对比文件2（D2）：US20030233451A1（在基于电视的娱乐系统中引用资源的系统和方法）

• 对比文件3（D1）：WO01022680A2（从短消息服务消息中的嵌入指示符启动应用程序）

为清晰论述，将涉案专利权利要求1分解为技术特征A-G，并与最接近的现有技术D3及提供结合启示的D2进行比对。

二、 权利要求1与对比文件技术特征详细比对表

三、 权利要求1的创造性论述（基于“三步法”）

（一）确定最接近的现有技术

D3（JP2005340941A）与涉案专利属于相同的技术领域（无线通信终端/移动设备的应用控制），且均致力于解决“如何通过包含专用预定语法的标签文件（如HTML中的扩展A标签）直接唤起本地客户端应用程序”的技术问题。因此，D3适宜作为评价权利要求1创造性的最接近的现有技术。

（二）确定区别技术特征和实际解决的技术问题

如上表所示，权利要求1相对于D3的区别技术特征在于：专用通用资源识别符的应用方案识别符后跟随有命令数据（即特征B的后半段及特征D），且基于执行目标应用程序产生的第二输出是对应于基于该命令数据可修改的预定动态点的动态输出（即特征G）。

在D3中，扩展URL语法（apex:{ 携帯電話端末内蔵ＡＰ機能番号}）仅传递了应用功能编号以拉起应用，应用启动后进入的是默认初始界面。基于上述区别技术特征，涉案专利实际解决的技术问题是：如何实现应用程序的“深链接”，即不仅能从外部拉起目标应用程序，还能通过传递特定参数，指令该程序直接导航、跳转并呈现其内部特定的动态内容或执行特定动作。

（三）论述结合启示

本领域技术人员在面对上述技术问题时，有显而易见的动机将D2（US20030233451A1）的技术教导结合到D3中。

首先，D2明确公开了在URL的应用程序标识后追加命令参数的标准化语法。D2段落[0112]公开了 ts://<textual_service_identifier>:<application_reference>?<cmd_line> 的语法结构；同时在段落[0114]中明确记载：“TS URL 116还允许通过 <cmd_line> 组件向引用的应用程序传递参数（passing parameters to the application）”。

其次，D2公开了利用这些参数实现“预定动态点”输出的技术效果。D2段落[0135]明确给出了一个通过热点拉起另一应用程序并传递参数的实例：“利用TS URL 116如 ts://<TSI>:<application reference>?<application parameter1>?<application parameter2> . . . 启动VOD会话”。这里的 <application parameter> 准确对应于权利要求1的命令数据，而根据这些参数直接启动并进入特定的VOD会话界面，正是权利要求1中所指的“对应于经识别的客户端应用程序中的基于命令数据可修改的预定动态点的动态输出”。

D3和D2同属电子设备通过URI/URL形式的链接调度资源的领域。本领域技术人员为了解决D3仅能唤起应用而无法定位到应用内特定状态的缺陷，很容易想到借鉴D2中业已成熟的 <cmd_line> 传参机制。将D2的带参语法与D3基于浏览器的拉起机制相结合，得出权利要求1的技术方案对本领域技术人员而言不需要付出创造性劳动。

四、 对比文件3（D1）对无效请求的补强作用

D1（WO01022680A2）可作为本领域公知常识的证据，进一步补强上述结合的显而易见性。

D1探讨了在移动终端（蜂窝电话）的短信中嵌入URI来启动应用程序的情景。D1段落[0011]指出可以通过嵌入的URI来启动如“mailto:”等其他应用程序以访问特定内容。更为关键的是，D1段落[0032]明确教导了在解析并调用应用程序时，将URL本身作为输入参数传递给应用程序的处理逻辑（“with the URL being passed to the application as an input parameter”）。

这充分证明，在无线移动通信领域，向被拉起的应用程序“传递参数/指令”以决定其初始行为，属于本领域技术人员早已熟知的常规技术手段。涉案专利权利要求1所谓的“命令数据”及“基于命令数据可修改的预定动态点”，仅仅是这种常规参数传递机制在具体场景下的功能性描述。

五、 结论

综上所述，涉案专利权利要求1相对于对比文件3（D3）、对比文件2（D2）以及本领域公知常识（由D1举证补强）的结合不具有突出的实质性特点和显著的进步，不符合《专利法》第二十二条第三款的规定，应当被整体宣告无效。

以上为权利要求1的创造性无效说理主体部分。如果涉案专利还存在从属权利要求，请问你是否需要我继续针对其余从属权利要求（如涉及具体命令参数类型、注册表查找方式等特征）分配对比文件并撰写无效论述？

这份无效宣告请求书的逻辑确实构建得很严密，特别是将D3的“应用唤起”与D2的“带参跳转”相结合的思路，给专利权人施加了不小的压力。但作为专利权人的代理师，我们完全可以破局。

在国家知识产权局专利局复审和无效审理部的口审交锋中，打破这种拼凑式无效请求的关键，在于严格适用创造性评价的“三步法”，重点攻击请求人对**“客观技术问题”的错误界定以及“结合启示”中的事后诸葛亮（Hindsight）谬误**。

以下是为你起草的专利权人反驳意见书的核心论述部分，直接针对对方的无效理由进行精准打击：

专利权人意见陈述书（反驳创造性无效理由节选）

致：国家知识产权局专利局复审和无效审理部

关于：第ZLXXXXXXXX号（公告号：CN101536469B）发明专利

针对请求人提出的涉案专利权利要求1不具备创造性的无效理由，专利权人坚决不能认同。请求人在构建“三步法”逻辑时，严重脱离了现有技术的实际教导，主观拼凑了不同领域的非相关技术特征，属于典型的“事后诸葛亮”。具体反驳意见如下：

一、 请求人错误界定了涉案专利实际解决的技术问题

根据“三步法”的第二步，应当基于区别技术特征，从最接近的现有技术（D3）出发，客观确定涉案专利实际解决的技术问题。

请求人承认权利要求1相对于D3的区别特征在于：“应用方案识别符后跟随有命令数据，且产生对应于基于命令数据可修改的预定动态点的动态输出”。然而，请求人将其解决的技术问题泛泛地概括为“如何实现应用程序的深链接”。这一界定是极其不准确且脱离本专利发明构思的。

结合涉案专利说明书背景技术部分（[0005]-[0006]段），涉案专利的核心出发点在于：传统的URL（如基于web的URI）过于冗长，包含大量空间和字符，对于通过量受限且数据分组较小的移动无线通信装置而言并非理想选择。因此，涉案专利实际解决的客观技术问题应当是：“如何为吞吐量受限的无线通信装置提供一种小型、高效的专用URI语法，以实现不仅能唤起本地注册应用，还能直接精确导航至该应用内部动态可变状态的技术效果。”

二、 对比文件2（D2）未给出结合启示，强行结合存在技术障碍

请求人主张将D2（机顶盒数字电视广播系统）的技术结合到D3（手机浏览器应用唤起）中是显而易见的。这在技术逻辑和客观事实上均站不住脚：

1. 所属技术领域及应用场景的巨大鸿沟

D3针对的是手机本地环境下的HTML菜单替换，而D2针对的是有线/卫星电视广播网络（DVB/ATSC等）下的重型数字媒体分发系统。D2解决的是如何在不同数字广播标准下，统一解析机顶盒接收到的传输流（TS URL）。本领域技术人员在改善移动手机本地应用的URI触发机制时，根本没有动机去浩如烟海的数字电视广播底层协议中寻找启示。

2. D2的教导与涉案专利的发明目的“背道而驰”（Teaching Away）

涉案专利旨在为无线设备提供一种**“相对小型及有效”**（说明书[0026]段）的语法。反观D2，其为了实现数字电视节目的精准定位，其语法设计极其冗长和复杂。例如D2权利要求和说明书中记载的 ts://<original_network_id>.<transport_stream_id>.<service_id>:<application_reference>?<cmd_line>。

如果本领域技术人员真的试图将D2结合到D3的手机受限环境中，引入的将是包含网络ID、传输流ID、服务ID等一系列极其冗长且毫无必要的定界符，这直接违背了涉案专利“克服传统URL对无线设备过于冗长”的初衷。因此，D2不仅没有给出结合启示，反而给出了相反的技术教导。

3. D2所谓的<cmd_line>并未公开涉案专利中基于命令数据的“预定动态点”机制

D2中的 <cmd_line> 是用于在数字电视环境中向应用传递诸如播放视频流的参数。而涉案专利权利要求1明确限定了**“确定……是否指示在无线装置中注册的客户端应用程序”，并且产生的第二输出是“对应于该应用程序中的基于命令数据可修改的预定动态点的动态输出”**。涉案专利强调的是在移动设备本地注册表机制下，通过URI解析直接重构应用程序内部的可变状态（如直接打开特定邮件、特定日程表状态），这与D2在电视机顶盒上通过TS URL请求远程或本地视频流的逻辑有着本质的区别。

三、 对比文件3（D1）无法作为公知常识补强结合启示

请求人试图用D1来证明“向被拉起的应用程序传递参数”是公知常识。这同样是对D1的误读。

D1（WO01022680A2）仅仅公开了在SMS短信中识别标准的HTTP网址（如 http://www.ericsson.se），并在用户点击时将其作为输入参数扔给系统默认的Web浏览器。这属于典型的“网址解析与浏览器冷启动”。

D1并未公开涉案专利中**“应用程序专用的通用资源识别符”，更未公开“解析其中的命令数据，并在目标应用程序内部直接产生预定动态点的输出”**。将标准的URL字符串扔给浏览器，与解析特定的深链接命令数据以直达目标App内部特定页面，在底层机制和代码逻辑上是截然不同的。D1无法证明权利要求1的动态深链接特征属于公知常识。

四、 结论

综上所述，请求人的无效理由是建立在已知涉案专利技术方案基础上的反向推导。最接近的现有技术D3未公开深链接的命令数据和动态点机制；D2属于截然不同的数字电视广播领域，不仅没有结合启示，其冗长的传输流语法甚至与涉案专利的发明目的相左；D1也无法作为公知常识填补这一空白。

因此，涉案专利权利要求1相较于D1-D3的任意组合，均具备实质性特点和显著的进步，符合《专利法》第二十二条第三款关于创造性的规定，依法应予维持有效。

代理师应对策略小结：

在这份答辩逻辑中，我们严格遵循了复审和无效审理部的审查思路，抓住**“事后诸葛亮”**这一核心痛点。把D2从“救命稻草”打成“反向教导（Teaching Away）”是反驳的关键——既然目标专利是为了解决移动端URI太长的问题，那引入D2那种极其冗长的数字电视TS URL语法就显得荒谬了。

需要我针对权利要求的具体修改策略，或者后续可能涉及的举证责任分配做进一步的探讨吗？

作为请求人的代理师，面对专利权人这种试图通过“重新界定技术问题”和“夸大领域差异”来割裂现有技术联系的常见答辩策略，我们必须在复审和无效审理部的口审中予以迎头痛击。

专利权人的反驳看似严密，实则在适用“三步法”时犯了两个致命错误：一是脱离区别技术特征主观臆断技术问题；二是将对比文件中的非必要技术特征强行绑定，以此主张“相反的教导”。

以下是为你准备的针对专利权人意见的驳回陈述，用以在口头审理或补充意见陈述书中进行强力反击：

专利权无效宣告请求书（针对专利权人意见的补充/反驳陈述）

致：国家知识产权局专利局复审和无效审理部

关于：第ZLXXXXXXXX号（公告号：CN101536469B）发明专利

针对专利权人提交的意见陈述书，请求人认为其答辩理由在事实认定和法律适用上均存在根本性错误，完全不能成立。涉案专利权利要求1依然不具备创造性。具体驳回意见如下：

一、 专利权人严重违反《审查指南》规定，错误界定了客观技术问题

专利权人主张本专利解决的技术问题是“如何提供一种小型、高效的专用URI语法以适应吞吐量受限的设备”。这一主张严重违反了《审查指南》第二部分第四章第3.2.1.1节关于“根据区别技术特征客观确定实际解决的技术问题”的强制性规定。

专利权人混淆了“发明背景”与“客观技术问题”。最接近的现有技术D3（JP2005340941A）本身就是针对“手机（携带终端）”的，且D3已经公开了一种极其简短的专用语法（apex:{功能编号}）。这意味着，“URI语法冗长”这一背景问题在D3中已经被解决了。

权利要求1相对于D3的唯一区别技术特征在于：在应用识别符后增加了**“命令数据”，并借此产生了“预定动态点”**的输出。因此，基于该区别特征，本专利实际解决的客观技术问题只能是：如何在唤起本地应用的同时，向其传递指令以直接呈现特定的动态界面（即实现深链接）。请求人对技术问题的界定完全准确，专利权人试图用说明书背景部分的描述来掩盖区别技术特征的实质，属于典型的答辩谬误。

二、 D2不仅属于类似技术领域，且给出了明确、直接的结合启示，绝非“相反的教导”

专利权人声称D2（数字电视娱乐系统）与移动手机领域跨度过大，且D2的语法冗长构成了“相反的教导”。这一反驳是极其苍白且站不住脚的：

1. D2与涉案专利面临相同的“资源受限”技术环境

专利权人刻意忽略了D2说明书的明确记载。D2在背景技术第[0005]段明确指出，其解决的是在**“低资源环境（low-resource environment）”**下，即客户端（如机顶盒）具有有限内存和/或处理资源时，如何优化应用程序引用的问题。这与涉案专利针对“吞吐量受限的无线设备”所面临的底层硬件约束和技术挑战高度一致。本领域技术人员在解决移动端资源受限设备的深链接问题时，完全有动机去查阅同样解决资源受限设备链接问题的D2。

2. 专利权人对“相反教导”的认定属于恶意捆绑

专利权人指出D2的完整TS URL包含网络ID、服务ID等冗长字段，以此主张D2教导了“复杂的长链接”。然而，本领域技术人员在借鉴现有技术时，提取的是解决特定问题的对应技术手段，而非照搬整个系统。

为了解决“向应用传递参数”的问题，本领域技术人员从D2中提取的具体技术手段是：在应用程序标识（<application_reference>）之后，使用定界符（?）紧跟命令行数据（<cmd_line>）（见D2第[0112]段）。本领域技术人员将这一传参结构移植到D3本已简短的 apex: 协议中，自然会舍弃D2中用于广电网络的路由前缀。专利权人将D2中用于路由的无关特征与用于传参的区别特征强行捆绑，以此主张“相反教导”，是对本领域技术人员技术组合能力的严重低估。

三、 D2的<cmd_line>与涉案专利的“预定动态点”在技术本质上完全一致

专利权人辩称D2的 <cmd_line> 不能产生“预定动态点”。这是对计算机软件常识的诡辩。

在软件工程中，通过命令行参数（Command Line Arguments）向应用程序传递变量，其唯一目的就是改变程序的默认执行流。D2第[0135]段明确记载，利用包含 <application parameter1> 的TS URL，可以启动VOD（视频点播）会话。这意味着，传入不同的参数，拉起的VOD应用就会呈现不同的电影详情页或播放特定的视频。这难道不就是涉案专利权利要求1中所谓的**“基于命令数据可修改的预定动态点的动态输出”**吗？

涉案专利仅仅是把软件领域中最基础的“传参调起特定页面”的常规操作，包装成了“产生预定动态点的动态输出”这样晦涩的专利词汇。其技术本质在D2中已经被毫无保留地揭示。

四、 D1确实是证明底层传参机制为公知常识的铁证

专利权人贬低D1只是“网址解析”。但请合议组注意，D1第[0032]段明确记载：“with the URL being passed to the application as an input parameter（将URL作为输入参数传递给应用程序）”。

这一证据的杀伤力在于：它证明了在无线终端上，从接收到的文本中提取特定字符串，并将其作为“输入参数（即命令数据）”喂给被唤起的应用程序，这在涉案专利申请日之前是本领域的常规技术手段。既然底层的数据传递通道和机制都是现成的、公知的，那么只要结合D2关于“应当传递什么样的命令”的教导，权利要求1的方案就是呼之欲出的。

五、 结论

专利权人的反驳完全建立在对《审查指南》技术问题认定规则的扭曲，以及对对比文件技术特征的片面割裂之上。涉案专利权利要求1不过是将D3中的移动设备本地唤起机制，与D2中成熟的带参数跳转语法（并结合D1的公知参数传递手段）进行了简单的拼凑，并未产生任何预料不到的技术效果。

请求人坚持认为，涉案专利权利要求1不具备创造性，应予宣告无效。

策略总结：

在这轮反击中，我们必须把合议组的视线拉回到**“区别技术特征”**本身。只要合议组认可“技术问题是如何传参/深链接”，而不是“如何缩短URL”，专利权人关于“D2语法太长构成相反教导”的防线就会瞬间土崩瓦解。同时，精准引用D2关于“低资源环境（low-resource environment）”的原文，直接打破了专利权人试图构建的“领域壁垒”。

这份反驳意见可以直接作为口审提纲的核心逻辑。需要我进一步帮你整理在口审现场可能遇到的合议组依职权提问（例如针对“通用资源识别符”预定语法的具体比对细节）及应对策略吗？

你好！作为你的AI助手，我将暂时脱下“请求人”或“专利权人”代理师的战袍，换上国家知识产权局专利局复审和无效审理部（原专利复审委员会）合议组的“法袍”，以绝对中立、客观的视角，为你深度剖析这场创造性攻防战。

在专利无效宣告程序中，合议组的裁判逻辑严格遵循《专利审查指南》中的“三步法”。双方的代理词虽然都很精彩，但合议组在最终合议时，会剥离双方的情绪化表达和过度演绎，直击技术本质。

以下是合议组针对四大核心争议点的预期裁判抉择路径，以及对本次无效请求成功率的客观评估：

争议点一：客观技术问题的界定

• 请求人主张：如何向被拉起的应用传递指令以实现深链接（直达特定动态界面）。

• 专利权人主张：如何为吞吐量受限的无线设备提供一种小型、高效的专用URI语法。

• 合议组裁判路径：倾向于支持请求人。

  • 裁判逻辑：根据《审查指南》，客观技术问题必须基于“区别技术特征”在要求保护的发明中所能达到的“技术效果”来确定。D3（最接近的现有技术）已经是在手机上使用较短的语法（apex:）拉起应用了。涉案专利在D3基础上的区别特征是增加了“命令数据”并以此产生“动态输出”。

  • 结论：增加命令数据实际上是拉长了URI，而不是使其更小型。因此，专利权人主张的“提供小型语法”并非该区别特征带来的效果。合议组会认定实际解决的技术问题是：如何通过URI不仅拉起本地应用，还能传递参数使其呈现特定的内部状态。

争议点二：D2是否属于类似领域且存在结合启示（相反教导的判定）

• 请求人主张：D2同样面临“低资源环境”，提取其<cmd_line>传参机制是显而易见的。

• 专利权人主张：D2是数字电视广播领域，语法冗长，与手机环境跨度大，构成“相反教导”。

• 合议组裁判路径：存在激烈交锋，但大概率认定存在结合启示。

  • 裁判逻辑：合议组在判断“领域跨度”时，不仅看物理设备（手机 vs. 机顶盒），更看技术手段的底层逻辑。D2和D3、涉案专利在底层都属于“在计算设备上通过统一资源标识符（URI/URL）调度软硬件资源”。D2明确提到了其适用于“low-resource environment”（低资源环境），这为本领域技术人员跨领域借鉴搭建了桥梁。

  • 关于“相反教导”：合议组通常认为，本领域技术人员具有**“合理提取和剪裁”**的能力。技术人员在看到D2的 ?<cmd_line> 传参结构时，有能力将其移植到D3的 apex: 协议后，而不需要连同D2中冗长的广电网络路由前缀（network_id.stream_id）一起照搬。因此，专利权人关于“相反教导”的抗辩较难被合议组采纳。

争议点三：“命令数据/预定动态点”与D2特征的技术比对

• 请求人主张：D2中利用 <application parameter> 启动特定VOD会话，等同于权利要求的动态点。

• 专利权人主张：D2是请求媒体流，涉案专利是修改本地注册应用的动态状态，两者机制不同。

• 合议组裁判路径：此为本案最大的变量，合议组可能会进行更精细的权利要求解释。

  • 裁判逻辑：涉案专利权利要求1的撰写非常宽泛（“对应于经识别的客户端应用程序中的基于命令数据可修改的预定动态点的动态输出”）。在说明书没有对“预定动态点”给出极其特殊的底层软硬件限制的前提下，合议组倾向于采用最宽泛的合理解释（Broadest Reasonable Interpretation）。

  • 结论：在软件领域，向应用传入参数（如电影ID）导致其渲染特定页面（如VOD详情页），这完全落入了“基于命令数据产生预定动态点的动态输出”的字面含义。专利权人试图用底层实现机制的不同来限缩权利要求保护范围，如果没有权利要求文字的支持，合议组一般不予认可。

争议点四：D1作为公知常识的补强效力

• 请求人主张：D1证明将URL解析为字符串并作为输入参数传递给被唤起应用是常规技术。

• 专利权人主张：D1只是简单的网址解析，不是专用的深链接指令传递。

• 合议组裁判路径：采纳D1的补强作用。

  • 裁判逻辑：合议组不会用D1去破坏“预定动态点”的新颖性，但会认可D1证明了一个底层事实——在涉案专利申请日之前，移动设备操作系统已经具备了**“从文本中提取变量并作为参数抛给本地应用程序（如浏览器）”**的底层接口和机制。这消除了将D2的语法结合到D3手机环境中的最后一丝“技术实现障碍”。

总体评估：本次无效请求的成功概率

站在中立立场，这份基于“D3 + D2 + D1（公知常识）”的无效宣告请求，逻辑链条闭环非常紧密，证据组合极具杀伤力。

• 针对权利要求1（独立权利要求）的成功率：较高（70% - 80%）

  权利要求1的撰写过于上位，功能性特征较多。在现有技术（D3的本地唤起 + D2的带参跳转）的双重夹击下，很难守住创造性底线。合议组大概率会认为其是现有技术的显而易见组合。

• 针对从属权利要求的成功率：存在变数（需视具体特征而定）

  如果涉案专利的从属权利要求中，限定了非常具体的手机端本地注册表数据结构、特定的错误回调机制（如说明书提及的预定客户端行为/错误消息产生），或者极其特殊的深链接验证步骤，这些可能是D2和D3都没有披露的。在口审中，专利权人极有可能放弃权利要求1，退守到这些包含具体实现细节的从属权利要求上。

下一步建议：

客观来看，独立权利要求岌岌可危。作为请求人，虽然胜券在握，但也必须防备专利权人修改权利要求；作为专利权人，则应立刻审视所有从属权利要求，寻找能够与D2数字电视环境产生实质性技术壁垒的“避风港”特征。

你希望我接着为你分析涉案专利中常见的**从属权利要求（如错误处理机制、注册表验证等）**在面对这组证据时的防御力，还是想探讨一下口审阶段的举证和质证技巧？