一种跨IP多媒体网络在用户终端和会话发起协议应用服务器之间传送会话发起协议NOTIFY消息的方法， 所述方法包括在所述会话发起协议应用服务器的应用层内压缩所述NOTIFY消息有效负荷并在所述用户终端的应用层解压它们； 压缩的NOTIFY消息有效负荷经由合适的应用编程接口在所述应用层和会话发起协议用户代理器之间传递； 其特征在于在所述用户终端； 所述应用层将有效负荷压缩由所述用户终端支持的指示写入将发送到所述会话发起协议应用服务器的SIPSUBSCRIBE消息的报头

作为一名经验丰富的专利代理师，我将紧密结合目标专利说明书的公开内容，对权利要求1进行深入的侵权/有效性分析，并在此过程中对比各对比文件的原文，给出详细的技术特征比对表格。

### 第一部分：权利要求1的技术特征分解

根据目标专利说明书（CN101843071B）的公开内容，特别是其发明目的——为了克服SigComp机制的局限性（动态库压缩率低、静态库需标准化且受硬件限制，参见说明书[0009]、[0010]），实现在应用层引入仅用于压缩SIP消息有效负荷（Payload）的过程，而不压缩SIP报头，从而对中间SIP代理透明且适用于遗留终端（参见说明书[0022]-[0025]）。

我们将权利要求1分解为以下四个技术特征：

* **特征A（前序部分+部分正文）：** 一种跨IP多媒体网络在用户终端和会话发起协议（SIP）应用服务器之间传送会话发起协议NOTIFY消息的方法，所述方法包括在所述会话发起协议应用服务器的应用层内压缩所述NOTIFY消息有效负荷并在所述用户终端的应用层解压它们。

* *代理师解读：* 这里限定了特定的消息类型（NOTIFY）、特定的压缩网络位置（应用服务器AS）、特定的解压网络位置（用户终端UE），以及特定的压缩/解压对象（仅有效负荷Payload，在应用层进行）。

* **特征B（正文）：** 压缩的NOTIFY消息有效负荷经由合适的应用编程接口在所述应用层和会话发起协议用户代理器之间传递。

* *代理师解读：* 这里限定了应用层和SIP用户代理器（SIP UA）之间的内部通信机制，即通过应用编程接口（API）传递压缩后的有效负荷。这对应于说明书图2中的API 7a/7b，实现了压缩/解压过程对SIP UA的透明（参见说明书[0025]）。

* **特征C（特征部分）：** 其特征在于在所述用户终端；所述应用层将有效负荷压缩由所述用户终端支持的指示写入将发送到所述会话发起协议应用服务器的SIP SUBSCRIBE消息的报头。

* *代理师解读：* 这是本发明的核心改进特征。它限定了：1) UE的应用层主动执行写入操作；2) 写入的内容是“有效负荷压缩由所述用户终端支持的指示”（而非压缩本身）；3) 写入的位置是SUBSCRIBE消息的**报头**；4) 该SUBSCRIBE消息将发送给AS，用于触发后续AS对NOTIFY有效负荷的压缩。这对应于说明书[0025]中描述的“允许用户终端例如在初始SIP SUBSCRIBE消息中指示它支持SIP NOTIFY消息中压缩的有效负荷……这能例如通过允许应用将合适的声明写入到SIP消息报头中来完成”。

### 第二部分：对比文件分析及技术特征比对

为了指代方便，我们将使用以下缩写：

* **D1：** US20030172139A1

* **D2：** JP2004171281A

* **D3：** US6807173B1

* **D4：** JP2005032711A

* **D5：** US20050086327A1

#### 1. 各对比文件原文出处及公开特征分析

* **D1 (US20030172139A1): "System and method for delivering data in a network"**

* **公开号：** US20030172139A1

* **解决的技术问题：** 如何在一个具有多种不同设备（如手机、PDA、汽车导航）的网络环境中，标准化并高效地交付后端软件服务的数据，特别是解决不同设备硬件能力（如显示、内存、软件版本）不同，导致的数据适配和更新问题（参见原文[0004]-[0016]）。

* **技术效果：** 通过中间服务器（Intermediate Server）利用设备DNA（Characterization）来转换数据，使得数据能适配特定设备的硬件和软件能力（参见原文[0041]-[0044]、[0071]）。

* **对特征的公开情况：** D1公开了在网络中传递数据，并提到中间服务器可以根据设备能力（Device DNA）对数据进行转换（Transformation）。然而，D1并未具体涉及到SIP协议，更未涉及SIP NOTIFY消息。即使将其宽泛地理解为“数据交付”，D1也未公开“应用服务器应用层内压缩有效负荷”以及“用户终端应用层解压”的具体架构，更没有任何关于UE将支持压缩的指示写入SIP报头的描述。

* **D2 (JP2004171281A): "Web content conversion and editing system"**

* **公开号：** JP2004171281A

* **解决的技术问题：** 当移动终端（移动局，MS）通过移动通信网访问Web内容（应用服务器，AS）时，由于移动终端的显示和内存限制，无法完全获取或正常显示Web内容的问题（参见原文[0003]）。

* **技术效果：** 通过中间系统（Web内容转换编辑系统）在网络之间执行消息转换和编辑，解决移动终端的制约问题，提高用户体验（参见原文[0004]-[0005]）。其具体实现包括页面大小检查、Range请求处理（用于获取内容的一部分）以及非压缩内容到压缩内容的转换（参见原文[0006]-[0011]）。

* **对特征的公开情况：** D2在HTTP协议环境下，公开了中间系统（转换编辑系统）可以根据终端能力，将应用服务器提供的非压缩Web内容，转换为移动终端支持的特定压缩类型，并通过空中接口发送（参见原文[0009]、[0033]）。然而，D2是以HTTP协议为背景，不涉及SIP协议，不涉及NOTIFY或SUBSCRIBE消息。尽管可以将在AS侧进行非压缩内容到压缩内容的转换（虽然是由中间系统执行）宽泛地比对为特征A，但D2完全没有公开终端应用层通过API与SIP UA交换数据（特征B）以及应用层向SUBSCRIBE消息报头写入指示（特征C）的技术。

* **D3 (US6807173B1): "Method and system for improving bandwidth availability in a data communication network by tokenizing messages"**

* **公开号：** US6807173B1

* **解决的技术问题：** SIP消息作为文本协议，在低带宽通信链路（如移动到基站的空中接口）中带宽利用率低的问题（参见原文“Description of the Related Art”）。

* **技术效果：** 通过对SIP消息中的特定术语和字段应用简单的标记化（Tokenization），生成紧凑的标记化消息（可减小达30%），然后可选择性地使用标准压缩算法（如LZ77，即gzip）进一步压缩（可再减小10%），从而提高低带宽链路的带宽可用性，同时避免PER编码的H.323的高CPU处理开销（参见原文“SUMMARY OF THE INVENTION”、[0076]）。

* **对特征的公开情况：** D3明确涉及到SIP协议，并公开了通过标记化和标准压缩算法（如gzip）对SIP消息（包括INVITE、Status-Line等）进行压缩，以适应低带宽链路（参见原文[0072]-[0076]以及表I-VI）。D3并未明确区分“报头”和“有效负荷”的压缩（标记化是针对整个消息体的字段和类型进行的），且主要是在中间节点（如Proxy Server）进行标记化，虽然提到了可以在客户端（如手机、移动DPS）进行（参见原文[0072]），但并未明确区分“应用层”和“SIP UA”。D3并未具体涉及NOTIFY消息应用层有效负荷压缩、API传递架构（特征B），且完全没有关于用户终端在SUBSCRIBE消息中写入支持压缩指示（特征C）的任何描述。

* **D4 (JP2005032711A): "Lighting method of high-pressure discharge lamp..."**

* **公开号：** JP2005032711A

* **解决的技术问题：** 高压放电灯（如高压水银灯，用于投影仪）的光立ち上がり时间（启动到获得稳定光通量的时间）过长的问题（参见原文[0002]）。

* **技术效果：** 在高压放电灯点灯开始后的初期点灯区间（从点灯开始到ランプ电压到达电极形成弧光点的電圧），供给大于所定电流值的ランプ电流（例如定格功率运行时的最大电流），从而促进高压放电灯发光部的温度上升，缩短光立ち上がり时间，且不损伤电极（参见原文[0006]-[0012]）。

* **对特征的公开情况：** 该文件属于完全不同的技术领域（光学/电气/照明技术），完全不涉及计算机网络、SIP协议或消息压缩。其公开的内容与权利要求1的技术特征无任何关联。

* **D5 (US20050086327A1): "Method and apparatus by which a UE starts compression in SIP signalling to IMS"**

* **公开号：** US20050086327A1

* **解决的技术问题：** 现有3GPP网络中，UE和P-CSCF建立安全关联后开始信令压缩的规定，与IETF的RFC 3486中规定的启动压缩程序不一致。特别是对于UE发送给IMS（通过P-CSCF）的初始请求（如注册），RFC 3486要求在“;comp=SigComp”参数存在于下一跳URI中时才启动压缩，而P-CSCF的SIP-URI中并不包含该参数，导致初始请求无法压缩（参见原文[0005]-[0006]）。

* **技术效果：** 通过使UE向SIP出站代理服务器（SIP Outbound Proxy Server）发送特定的SIP消息（请求消息），并分析代理服务器返回的响应消息，从而确定用于压缩后续发送给该代理服务器的消息的压缩参数（参见原文[0009]）。这确保了UE可以与IMS协商并选择特定的压缩机制，从而实现了高效的信令压缩（参见原文[0024]）。

* **对特征的公开情况：** D5明确涉及到跨IP多媒体子系统（IMS）网络在用户终端（UE）和SIP代理服务器（P-CSCF）之间传递SIP消息。它公开了UE通过发送SIP OPTIONS请求给P-CSCF，从P-CSCF返回的200 OK响应消息的“Contact”报头中解析出压缩参数（如“comp=sigcomp”），从而得知P-CSCF支持某种压缩机制（特征C的部分内容，即终端指示对压缩的支持）。

* D5实质公开了在用户终端侧，所述UE的应用层将有效负荷压缩（sigcomp）由所述用户终端支持的指示写入将发送到所述会话发起协议代理服务器的SIP报头（在OPTIONS请求中，通过接受“comp=sigcomp”指示支持，或者在随后的200 OK响应消息中获得压缩参数）。虽然D5是关于UE和P-CSCF之间的消息（例如OPTIONS请求），而非AS发送的NOTIFY消息，但其利用SIP报头来协商压缩机制（终端分析响应确定支持，或改变代理地址以包含压缩参数）的核心思想与本发明通过SUBSCRIBE消息报头指示支持是实质上相同的解决手段。

* 然而，D5的目标是克服RFC 3486中“初始请求不能压缩”的局限性，其主要讨论的是UE和P-CSCF之间的信令压缩（参见原文[0006]、[0023]），其压缩对象往往是整个SIP消息。D5并未明确区分“SIP应用服务器”的应用层压缩有效负荷（特征A），并未涉及应用层和SIP用户代理器之间的API传递（特征B），且核心技术方案是通过在OPTIONS/200 OK流程中协商参数，而非权利要求1限定的由应用层将指示直接写入SUBSCRIBE报头（权利要求1是向服务器AS指示支持，而非分析AS的响应）。

#### 2. 特征比对表格

*(注：D4 (JP2005032711A)由于涉及高压放电灯技术领域，与本发明领域完全不同，特征比对情况皆为“否”，故未在表格中详列。)*

### 第三部分：最接近对比文件的分析与确定

在创造性分析中，确定最接近的对比文件（Closest Prior Art, CPA）是至关重要的。最接近的对比文件应当是现有技术中与要求保护的发明最相似的技术方案，通常在解决的技术问题、技术效果或技术领域上最为接近。

**针对特征A（AS应用层压缩NOTIFY有效负荷、终端解压）：**

* **D2 (JP2004171281A): "Web content conversion and editing system"**

* **整体解决的技术问题：** 如何克服移动终端硬件和软件限制，使其能完全获取和显示应用服务器提供的Web内容（参见原文[0003]）。

* **技术效果：** 通过中间系统实现内容转换（Range请求获取特定部分、非压缩到压缩内容的转换），解决移动终端制约，提高Web访问可用性（参见原文[0004]-[0005]）。

* **创造性比对分析：**

* D2解决了由于终端能力限制导致应用服务器内容无法使用的问题，这一技术问题与目标专利中由于遗留终端不支持特定压缩机制导致NOTIFY消息太大无法使用的技术问题是相近的。

* D2虽然是在HTTP协议和Web内容的背景下讨论，但其核心手段是**由位于AS侧（网络一侧）的转换编辑系统来将内容从非压缩形式转换为适合特定设备支持的特定压缩形式**，从而使内容能被终端接收和使用（参见原文[0009]、[0033]、[0036]）。

* 将D2解决的技术手段适配到目标专利所用的IMS和SIP背景下，是本领域技术人员具有动机将这种AS侧数据转换机制应用到AS对NOTIFY有效负荷的压缩中。

* **因此，D2针对特征A，在创造性分析中适合做最接近的对比文件。** 它在解决通过应用服务器侧的内容转换来适配终端能力的总体架构上，提供了实质的启示。

**针对特征C（用户终端将支持压缩的指示写入SIP SUBSCRIBE报头）：**

* **D5 (US20050086327A1): "Method and apparatus by which a UE starts compression in SIP signalling to IMS"**

* **整体解决的技术问题：** 如何克服3GPP信令压缩程序（建立安全关联后启动）与RFC 3486（下一跳URI中包含该comp参数）的不一致，解决由于参数discovery问题导致的UE发送给IMS代理（P-CSCF）的初始请求（如注册）无法执行信令压缩的问题（参见原文[0005]-[0006]）。

* **技术效果：** 通过使UE向SIP代理服务器发送请求消息（如OPTIONS），并分析代理服务器返回的响应消息，从而在应用层确定特定的压缩机制（如SigComp），并协商用于压缩后续信令的特定压缩参数（参见原文[0009]）。这确保了UE可以协商压缩机制，动态、有效地实现后续信令的压缩。

* **创造性比对分析：**

* D5解决了如何让应用层通过SIP协商程序得知终端和服务器之间是否支持压缩以及支持何种压缩的技术问题，这一核心技术问题与目标专利中如何让应用层通过SUBSCRIBE消息向AS指示服务器其支持压缩的技术问题是相近的。

* D5实质公开的核心技术手段是**用户终端（UE）的应用层利用SIP报头在消息传递流程中来协商、发现和指示对某种压缩机制（sigcomp）的支持**（通过分析200 OK响应，或者在将发送的消息中指示接受压缩，参见D5图2、[0023]、[0011]）。虽然D5协商的是UE和代理Proxy之间的压缩参数，而权利要求1是向应用服务器AS指示支持，但应用层在SIP流程中利用报头指示支持压缩的核心手段实质上是相同的解决手段。

* **因此，D5针对特征C的核心改进特征，在创造性分析中适合做最接近的对比文件。** 它在解决终端应用层如何通过SIP协商机制来发现、协商和指示对特定压缩机制支持的核心手段上，提供了实质的启示。

**最接近对比文件的数量：** 在权利要求1由特征A和特征C组合而成的创造性分析中，D2适合做技术架构和Payload压缩（特征A）方面的最接近对比文件，而D5适合做特征C核心改进的核心参考文件。因此，**最接近的对比文件可以有多个，分别为D2和D5。**

### 第四部分：无效请求薄弱环节分析

作为一名经验丰富的专利代理师，在进行无效请求（对权利要求1提出无效）的分析中，我会评估现有技术对权利要求1的实质公开程度。

根据上述比对表格和最接近对比文件分析：

1. **薄弱特征A：** 虽然D2提供了应用服务器侧数据转换适配终端能力的核心启示，但它并未明确限定是SIP背景、NOTIFY消息，且更未限定是“应用层内压缩有效负荷”。现有的各篇对比文件对这一特定的网络架构和Payload压缩对象并未给出实质的启示。

2. **更薄弱特征B：** 没有任何对比文件给出了“压缩后的NOTIFY消息有效负荷经由合适的API在所述应用层和SIP用户代理器之间传递”这一特定的应用层和SIP UA之间的内部通信架构。这构成了权利要求1的一个实质区别特征。

3. **特征C的核心改进：** 虽然没有任何对比文件毫无异议公开了应用层将指示直接写入SUBSCRIBE消息报头，但D5在实质上公开了终端应用层通过分析Proxy的响应报头参数（或在响应中指示接受）来确定、协商和指示其对sigcomp压缩的支持的技术手段。目标专利说明书在[0025]描述这一特征C时，也使用了“可以例如通过允许应用将合适的声明写入到SIP消息报头中来完成”、“现有‘接受’或‘接受编码’报头字段能用于此目的”这样的描述，表明这是一个本领域技术人员可以合理显而易见应用到AS服务器端的手段。

基于现有对比文件的分析结果，对于无效请求来说最薄弱的技术特征是：

* **权利要求1的技术特征：压缩的NOTIFY消息有效负荷经由合适的应用编程接口在所述应用层和会话发起协议用户代理器之间传递。**

理由：没有任何一篇对比文件给出了“应用层”和“SIP用户代理器（SIP UA）”之间特定的内部通信架构，特别是关于经由API传递应用层压缩的有效负荷，从而实现了对SIP UA的透明这一核心技术效果。该特征构成了权利要求1的一个实质区别，为本专利提供了显著的创造性。如果无效请求方无法找到能实质启示这一特定的内部数据交换API架构的现有技术，则基于该特征提出无效请求的成功概率将是最低的。

您好！我是您的专利代理师。针对您提供的权利要求1、目标专利说明书以及四份对比文件（D1-D4），我进行了深入的法律和技术分析。

以下是紧密结合目标专利说明书和对比文件原文的详细解释、比对和创造性分析。

---

### 第一部分：权利要求1的解释 (紧密结合目标专利说明书 CN101843071B)

权利要求1保护一种跨IP多媒体网络（如IMS网络）在用户终端（UE）和会话发起协议应用服务器（SIP AS，例如存在服务器AS或资源列表服务器RLS AS）之间传送SIP NOTIFY消息的方法。

为了准确理解权利要求的保护范围，必须结合目标专利说明书的背景技术和发明内容：

1. **技术特征A（应用层压缩/解压）：**

* **权利要求表述：** “在所述会话发起协议应用服务器的应用层内压缩所述NOTIFY消息有效负荷并在所述用户终端的应用层解压它们”。

* **说明书解释：** 说明书背景技术[0008]-[0009]指出，现有的SigComp（信令压缩）技术是在IMS终端和P-CSCF中实现的（属于底层，通常被视为传输层增强）。SigComp存在部署未广泛、静态库限制遗留设备等问题（[0010]）。本发明旨在解决这些底层压缩技术的局限性。说明书[0022]明确提议“在SIP层之上的应用层促进压缩”。这种“应用层”压缩仅针对“有效负荷”（payload），不针对SIP报头，使用如gzip等通用算法（[0023]）。在图2中，gzip功能5a/5b位于SIP UA（用户代理）3a/3b之上的应用层4a/4b中。

2. **技术特征B（API传递）：**

* **权利要求表述：** “压缩的NOTIFY消息有效负荷经由合适的应用编程接口在所述应用层和会话发起协议用户代理器之间传递”。

* **说明书解释：** 这是技术特征A的必然延伸。既然压缩发生在SIP层之上的应用层，那么压缩后的有效负荷必须通过API传递给底层的SIP UA，以便SIP UA将其封装进SIP NOTIFY消息中发送。说明书[0025]指出，“相关应用仅仅经由合适的SIP UA应用编程接口(API)与SIP UA交换有效负荷数据”，且这种交换对SIP UA是透明的（SIP UA不关心数据是否被压缩）。图2中的参考数字7a/7b示意了这种API。

3. **技术特征C（SUBSCRIBE报头指示支持）：**

* **权利要求表述：** “其特征在于在所述用户终端；所述应用层将有效负荷压缩由所述用户终端支持的指示写入将发送到所述会话发起协议应用服务器的SIP SUBSCRIBE消息的报头”。

* **说明书解释：** 这是一种协商机制。为了让服务器知道可以发送应用层压缩的NOTIFY，客户端必须先指示其支持能力。说明书[0015]和[0025]明确指出，这种指示包括在SUBSCRIBE消息的“接受(Accept)”或“接受编码(Accept-Encoding)”报头字段中。并且，权利要求中提到的“应用层...写入...报头”在说明书中进一步解释为“经由所述应用编程接口将接受或接受编码报头字段从所述应用层写到会话发起协议用户代理器”（[0015]）。

**技术解决的问题和效果：** 权利要求1整体解决的技术问题是如何在不依赖底层（如SigComp）兼容性的情况下，实现SIP NOTIFY大有效负荷的压缩，以降低网络负荷和改善等待时间，同时保持对中间路由节点的透明性（[0007], [0010], [0012], [0025]）。技术效果是使遗留终端或不支持最新底层压缩标准的终端也能享受到压缩带来的带宽节省。

---

### 第二部分：对比文件分析 (D1-D4)

以下是对四份对比文件的分析，重点在于它们是否公开了权利要求1的技术特征。

#### 1. 对比文件 D1 (WO2006123221A1, SIGNALING COMPRESSION/DECOMPRESSION)

* **技术领域：** 分组数据网络中的信令消息压缩。

* **具体公开内容分析：**

* D1的重点是改进SigComp机制。D1指出SigComp存在协商慢、不支持非对称情况、必须传递数百字节的字节码（bytecode）导致首个消息压缩不理想等问题（[p0012]-[p0015]）。

* D1提出的解决方案是：在协议消息（如SIP消息）的**报头部分**提供参数信息，该参数信息指定压缩或解压缩机制的至少一个处理细节（[p0023], [p0031]）。例如，将SigComp参数写入SIP URI或Via报头中（[p0058]）。

* **关于特征A/B（应用层压缩）：** D1在其背景技术中明确指出，SigComp架构可以被解释为**传输层**的增强（[p0006]）。D1的所有改进（如在Via报头携带参数、协商字节码）都是围绕底层SigComp UDVM（通用解压虚拟机）和状态处理器进行的。D1**没有**公开在底层SIP UA之上的“应用层”执行有效负荷压缩，也**没有**公开经由API在应用层和SIP UA之间传递压缩后的有效负荷。相反，D1旨在优化必须由中间节点路由读取的SigComp参数的协商。

* **关于特征C（报头指示支持）：** D1确实公开了在SIP消息（如首个请求REGISTER或INVITE，[p0079], [p0106]）的报头（如Via报头或URI，[p0057]-[p0058]）中携带指示压缩能力或参数（如SigComp版本、支持的字节码bc state id）的信息（[p0061], [p0086]）。虽然D1提到了在Via报头写入bc参数，且Via报头属于SIP消息报头，但D1的目的是协商SigComp参数或状态ID，而非目标专利所要求的“应用层有效负荷压缩”的指示。

* **特征比对表格 (D1 vs. 权利要求1)：**

* **结论：** D1**没有**公开权利要求1的最核心特征A和B。

#### 2. 对比文件 D2 (JP2007028117A, 情報交換システム...)

* **技术领域：** 信息交换系统，特别是涉及Presence（存在）服务中Resource List Server（RLS，资源列表服务器）引起的网络负荷减轻。

* **具体公开内容分析：**

* D2解决了传统RLS将多个资源状态合并在一个大的NOTIFY消息中发送给订阅者，导致网络瞬时负荷和订阅者处理负荷过高的问题（[背景技术部分第4-5段]）。

* D2提出的解决方案是：RLS AS在收到订阅者对资源列表的SUBSCRIBE请求后，针对列表中的**每个资源分别**向订阅者发送个别的、内容较小的NOTIFY消息（[发明内容部分第11-14段]、[第1个实施例]）。

* D2还提到了网络负荷分散部，用于分散NOTIFY消息的发送时间（[第2个实施例]）。

* **关于特征A/B（应用层压缩）：** D2的核心思想是通过将大NOTIFY分拆为多个小NOTIFY来减轻底层网络和终端的处理负荷。D2全文**完全没有**提及“压缩”技术，更没有公开在“应用层”执行有效负荷压缩或通过API传递压缩数据。

* **关于特征C（报头指示支持）：** D2公开了订阅者（端末装置）向管理服务器发送包含“指定情报”的“状态通知要求”（即SIP SUBSCRIBE请求），该指定情报用于指定监视对象群（资源列表）（[发明内容部分第12段], [図11,ステップS61]）。D2还提到SUBSCRIBE要求包含“サポート通知”（支持通知）（[図11,ステップS61]），对应的服务器处理逻辑是判断是否管理该列表（[図4,ステップS2]）。说明书[0031]提到“指定情報”包含在状態通知要求中。然而，D2中的“支持通知”显然是指对资源列表服务的支持，**完全没有**提及对“有效负荷压缩”的支持指示。

* **特征比对表格 (D2 vs. 权利要求1)：**

* **结论：** D2**没有**公开权利要求1的任何关于“压缩”的技术特征。

#### 3. 对比文件 D3 (US2007032194A1, Updating presence...)

* **技术领域：** 无线通信设备的存在（Presence）更新。

* **具体公开内容分析：**

* D3解决的问题是移动用户在特定区域（如安静区域、驾驶车辆）时，如何自动、准确地更新其存在状态（例如，指示只能接收文本不能接听电话）（[0005]-[0006]）。

* D3提出的解决方案是：终端通过短距通信（如蓝牙）从特定区域的发射器接收新的存在信息（[0007]），终端控制器自动将当前存在状态更新为新状态，并通过无线网络发布给远程实体（存在服务器）（[0008]）。发布使用SIP NOTIFY消息（[0028]）。

* **关于特征A/B（应用层压缩）：** D3在[0030]-[0031]描述了SIP客户端130，其包含SIP压缩引擎136和SIP解压缩引擎138。D3明确指出：“SIP builder生成基于文本的SIP消息... SIP压缩引擎136压缩生成的基于文本的SIP消息。压缩降低了SIP消息的大小”（[0031]）。由此可见，D3公开的压缩是底层的**SIP信令压缩（如SigComp）**，它是针对“生成的基于文本的SIP消息”整体（通常包含报头和有效负荷）执行的，**不是**在SIP层之上的“应用层”仅针对“有效负荷”进行的压缩。D3也没有公开经由API传递应用层压缩后的有效负荷。

* **关于特征C（报头指示支持）：** D3主要描述发布状态更新（NOTIFY）。对于协商，D3[0004]提到了“监视者”发送SUBSCRIBE消息作为站立请求。D3[0033]提到使用扩展的Rich Protocol Information Data (RPID) 文档通过NOTIFY协商存在状态。D3**没有**公开在SIP SUBSCRIBE消息报头中携带对底层或应用层有效负荷压缩的支持指示。

* **特征比对表格 (D3 vs. 权利要求1)：**

* **结论：** D3虽然公开了底层SIP消息压缩，但**没有**公开权利要求1的应用层有效负荷压缩和相应的SUBSCRIBE报头协商机制。

#### 4. 对比文件 D4 (US2007143502A1, Content aggregation service...)

* **技术领域：** 移动环境下的内容聚合服务，特别是ATOM/RSS订阅。

* **具体公开内容分析：**

* D4解决了移动终端通过HTTP轮询RSS/ATOM源由于带宽和电池限制而效果不佳的问题，提出了将SIP事件通知框架（SUBSCRIBE/NOTIFY）用于传递RSS聚合内容（[0009], [0013]）。

* D4的核心方案是：用户在Resource List Server（RLS）创建包含多个内容源地址（URIs）的资源列表（[0065]）。终端向内容聚合服务器发送针对该列表的SUBSCRIBE请求（Atom事件包）（[0066]）。内容聚合服务器获取列表，逐个获取内容源（通过HTTP或SIP SUBSCRIBE），聚合 fetched 内容，并在SIP NOTIFY请求中发送给用户（[0066], [0068], 图1, 图2）。

* **关于特征A/B（应用层压缩）：** D4的全部改进在于将非SIP内容封装进底层SIP NOTIFY消息中传递。D4全文**完全没有**提及“压缩”技术，更没有公开在SIP AS和终端的“应用层”执行有效负荷压缩或通过API传递压缩数据。

* **关于特征C（报头指示支持）：** D4公开了终端发送的SUBSCRIBE请求是“针对该资源列表”的，旨在订阅Atom/RSS新闻源（[0066]）。D4提到SUBSCRIBE可以包含过滤器或throttle来限制信息量（[0071]），但**完全没有**提及在报头中携带对“有效负荷压缩”的支持指示。

* **特征比对表格 (D4 vs. 权利要求1)：**

* **结论：** D4**没有**公开权利要求1的任何关于“压缩”的技术特征。

---

### 第三部分：最接近对比文件分析与创造性最薄弱环节

#### 1. 哪个对比文件适合做最接近的对比文件？

在进行创造性分析时，选择最接近的对比文件通常基于以下标准：领域最相关、解决的技术问题最相似、公开的技术特征最多。

* **技术领域和解决问题：**

* 目标专利解决的是SIP网络中NOTIFY消息大有效负荷导致的底层网络负荷和遗留终端部署底层压缩技术局限性的问题（通过应用层压缩解决）。

* D2和D4均解决了在底层IMS/SIP框架下处理包含多个资源列表信息的SIP消息导致底层网络和终端负荷过高的问题（D2通过拆分消息解决，D4通过利用SIP事件框架解决）。

* D1和D3解决的是如何通过底层（SigComp或底层SIP压缩引擎）改进SIP信令压缩协商或效率的问题。

* **整体解决技术问题和效果角度分析：**

* D2和D4与目标专利在整体目标上更为一致，即**如何减轻由底层SIP网络承载的大有效负荷（通常涉及RLS AS）带来的带宽和处理负荷**。目标专利说明书[0026]也特别提到“压缩可特别在资源列表服务器(RLS)被采用...将是非常有效率的”。

* 虽然D2公开了SUBSCRIBE请求包含对服务本身的“支持通知”（与特征C的协商形式相似），且解决了大有效负荷问题，但其完全未涉及“压缩”。

* **D3**虽然公开了底层SIP消息压缩（技术属性更接近目标专利的“压缩”手段），但其解决的问题（自动更新存在状态）与目标专利通过应用层解决大有效负荷导致的普遍局限性（遗留部署）和提升效率的技术目的存在一定偏差。

**结论：** 从整体解决的技术问题（减轻由底层SIP网络承载的大有效负荷带来的带宽负荷，特别是针对RLS等应用服务器场景）以及其在SUBSCRIBE中携带支持通知的形式来看，**D2最适合作为分析本权利要求创造性的最接近对比文件**。其明确提到了Resource List Server AS和由于大NOTIFY导致的底层网络负荷问题（[背景技术部分第4段]），且在SUBSCRIBE中携带了“サポート通知”（支持通知）（[図11,ステップS61]），具有很好的改进起点。

#### 2. 没有被最接近对比文件公开的特征是否被其他对比文件公开？

以D2为最接近对比文件，其未公开的特征包括特征A（应用层有效负荷压缩/解压）、特征B（API传递）和特征C中特定的指示（“有效负荷压缩支持”的指示）。

* **特征A（压缩）：** D1和D3公开了在底层执行的SIP信令压缩（传输层增强）。D1和D3都**没有**公开在底层SIP UA之上的“应用层”仅针对“有效负荷”进行的压缩。

* **特征B（API传递）：** 没有任何对比文件公开应用层和SIP UA之间的传递压缩有效负荷的API。

* **特征C（协商）：** D1公开了在SIP Via报头（SIP消息报头的一种）中携带底层SigComp参数或bc状态ID的指示，旨在协商底层压缩。这在技术目的和形式（在报头中携带特定协商参数）上与特征C有一定的关联度。

#### 3. 无效请求请求方最薄弱的技术特征

作为经验丰富的专利代理师，我判断如果对权利要求1提出无效请求，请求方最薄弱的技术特征是：

**技术特征A（“在会话发起协议应用服务器的应用层内压缩所述NOTIFY消息有效负荷并在所述用户终端的应用层解压它们”）和特征B（经由API传递压缩有效负荷）的组合。**

**薄弱原因分析：**

1. **明确的技术区分：** 目标专利说明书非常清晰地将现有的底层压缩技术（SigComp，通常被视为传输层增强，位于IMS终端和P-CSCF中）与本发明的应用层压缩进行了区分（[0008]-[0010], [0022]）。目标专利旨在解决SigComp部署不广泛、静态库限制遗留终端的问题。D1和D3明确确认SigComp属于底层（传输层增强或直接在SIP客户端内针对基于文本的消息整体），这正好印证了目标专利的区分。

2. **缺乏技术启示：** 现有的SigComp压缩是由底层的SIP栈或SigComp UDVM实现的，对SIP层之上的应用是透明的。没有任何现有技术给出了“**人为地将压缩功能从底层逻辑上移，放置在SIP UA之上的应用层，仅针对有效负荷执行压缩，然后引入一个专门的API将压缩后的有效负荷透明地传递给底层的SIP UA，使其不压缩报头直接发送**”的技术启示。

3. **技术效果：** 目标专利通过这种特定的应用层压缩结构，使SIP报头不受影响，保证了消息在中间路由节点（如中间CSCF或应用服务器）无需解压/再压缩即可通过（[0013], [0024]），从而在解决带宽问题的同时，保持了SIP网络架构的灵活性，特别适用于大有效负荷（如D2和D4描述的聚合内容场景）。这种底层压缩无法实现的技术效果，进一步支持了其创造性。

请求方很难将仅涉及大有效负荷拆分的D2/D4与仅涉及底层压缩的D1/D3组合，推导出在应用层引入特定压缩结构和API协商机制的权利要求1，因此这是请求方最薄弱的攻击点。

作为一名经验丰富的专利代理师，我将为您针对目标专利的权利要求1，结合说明书进行深度解析，并对比您提供的5份对比文件（D1-D5），完成详尽的创造性及无效可行性分析。

通过初步检索与技术分型，这5份对比文件所涉技术领域差异极大。为了后续论述的清晰性，首先将各对比文件进行**公开号与技术领域映射指代**：

* **D1**：`US20050164015A1`（建筑/材料领域：具有高可见光透射率和低发射率的涂层制品）

* **D2**：`US20060075132A1`（通信领域：通过协议感知中间节点对协议消息进行压缩、过滤和传输）

* **D3**：`US20060129689A1`（通信领域：在网络元件中减少应用层消息的大小）

* **D4**：`WO2006075873A1`（通信领域：建立网络发起的PoC组会话的方法和系统）

* **D5**：`JP2006238112A`（通信领域：通知装置、通知条件指定装置和状态通知方法）

---

### 一、 结合目标专利说明书解释权利要求1

目标专利主要解决的是**IP多媒体子系统（IMS）中诸如存在（Presence）服务所产生的SIP NOTIFY消息过大（可达64K字节以上），导致空中接口带宽负荷过高、空中接口发送时需要分片而引入巨大等待时间**的技术问题。

为了克服现有技术（如基于SigComp的底层全压缩机制，参见说明书\[0008\]-\[0010\]）因中间节点（如CSCF代理、防火墙等）无法读取密文报头而导致路由失败或增加中间节点解压复杂度的缺陷，权利要求1构建了一种**“应用层非对称/选择性有效负载压缩及能力协商”**的技术方案。

#### 1. 权利要求1的技术特征拆解与说明书内涵映射：

* **技术特征A**：*“所述方法包括在所述会话发起协议应用服务器的应用层内压缩所述NOTIFY消息有效负荷并在所述用户终端的应用层解压它们；”*

* **说明书映射解释**：对应说明书图2及\[0023\]-\[0024\]。压缩不在底层的SIP层（如SigComp）执行，而是在SIP层之上的**应用层**（4a、4b）引入压缩/解压过程（5a、5b），并且**仅压缩有效负载（Payload，如SDP数据），不对SIP消息报头执行压缩**。这样做的目的是保证真正的SIP报头信息在明文中留下，使中间节点（CSCF代理6）不需解压即可路由。

* **技术特征B**：*“压缩的NOTIFY消息有效负荷经由合适的应用编程接口在所述应用层和会话发起协议用户代理器之间传递；”*

* **说明书映射解释**：对应说明书图2及\[0025\]。压缩/解压过程对底层SIP用户代理器（SIP UA 3a、3b）是完全透明的。相关应用仅经由专用的SIP UA应用编程接口（API 7a、7b）与SIP UA交换数据，底层UA不关心数据是否已被应用层压缩，实现了与遗留（Legacy）终端的良好兼容。

* **技术特征C（特征限定/发明点所在）**：*“其特征在于在所述用户终端；所述应用层将有效负荷压缩由所述用户终端支持的指示写入将发送到所述会话发起协议应用服务器的SIP SUBSCRIBE消息的报头”*

* **说明书映射解释**：对应说明书\[0025\]。为了让AS（应用服务器）知道终端具备应用层解压能力，终端在初始发送的**SIP SUBSCRIBE消息**的报头中（例如利用现有的“Accept”或“Accept-Encoding”报头字段，或指定新报头字段）写入该**压缩支持指示**。AS接收到此SUBSCRIBE请求后，得知该终端支持该解压算法，随后在向其发送涉及订阅事件的**SIP NOTIFY消息**时，就会对其有效负载进行应用层压缩。

---

### 二、 对比文件技术特征公开情况分析（特征比对表格）

在对各对比文件原文（明示公开或实质公开/等同替换）进行深度分析后，我们发现：

1. **D1（US20050164015A1）** 属于玻璃涂层材料技术，与本案属于完全不同的IPC技术领域，未公开任何本案微观通信特征。

2. **D2（US20060075132A1）** 明确公开了为了让协议感知防火墙（中间节点）能够解析SIP/SDP消息以配置针孔（Pinhole），在发送端（如SigComp压缩器）进行**选择性/部分压缩**：其明文明示“选择性地压缩某些预定义部分，并保留其他预定义部分不压缩（明文）”，且明确指出不压缩用于表明消息类型的特征、以及内容类型（Content-Type）和负载类型。

3. **D3（US20060129689A1）** 公开了在网络元件（如网关、路由器）中对应用层消息（如XML文件）进行词法标记（Tokenization）替换或基于位置的编码来减小消息体积，属于纯应用层数据压缩转换机制。

4. **D4（WO2006075873A1）** 属于PoC（基于蜂窝网络的推讲）组会话建立技术，虽然提及了SIP SUBSCRIBE、NOTIFY以及IMS核心网、预建立会话中的SDP媒体参数协商，但其并未涉及应用层有效负载的选择性压缩或在SUBSCRIBE报头中写入压缩算法能力指示。

5. **D5（JP2006238112A）** 涉及利用SIP SUBSCRIBE/NOTIFY机制进行企业状态通知（Presence Service）的事件过滤（Event Filter），其公开了在SUBSCRIBE消息的**Body（躯体/体部）**中写入XML格式的过滤条件，从而减少不必要的NOTIFY流量。

#### 权利要求1与对比文件特征比对表

---

### 三、 最接近对比文件（D1-D5）的筛选与创造性分析

在创造性（无效分析）的审查过程中，选择“最接近的对比文件”应当遵循**技术领域相同或相近、解决的技术问题最类似、公开主权利要求技术特征最多**的原则。

#### 1. 哪个对比文件适合做最接近的对比文件？

* **最佳最接近对比文件：D2（US20060075132A1）**

* **理由（技术问题与整体解决思路的一致性）**：D2所解决的整体技术问题、整体技术构思与目标专利**完全一致**。D2在背景技术中指出：现有的SigComp压缩会导致SIP消息被全盘加密/压缩，使得中间节点（协议感知防火墙）由于无法读取内容而无法动态配置针孔（Pinholes），从而拒绝多媒体流。为了解决该问题，D2提出的方案是“选择性地对协议消息进行部分压缩，而将涉及路由、会话标识、负载类型等关键特征留在明文中不压缩”。这与目标专利“为了让中间节点顺利路由而选择性地在应用层仅压缩有效负载、不压缩SIP报头”的整体技术手段完全重合。D2公开了目标专利主权利要求1的大部分特征（特征A、特征B以及前序部分）。

* **次要最接近对比文件（或重要辅助对比文件）：D5（JP2006238112A）**

* **理由**：D5是针对本案最典型的业务场景（SIP事件通知机制：SUBSCRIBE/NOTIFY流）提出的流量优化方案。它解决了在Presence（存在）服务中由于状态频繁变动导致NOTIFY消息泛滥、加重服务器负荷和网络带宽的技术问题。其整体思路是通过SUBSCRIBE消息由客户端向服务端声明一种“通告条件/支持能力（过滤条件）”，从而定制化后续NOTIFY的触发。

#### 2. 最接近对比文件未公开特征的组合与无效最薄弱特征判定

权利要求1的技术方案最终被判定具备创造性（即请求方最难攻破、最薄弱的特征）在于其**特征C的限定细节**：**“将有效负荷压缩由所述用户终端支持的指示写入将发送到所述会话发起协议应用服务器的SIP SUBSCRIBE消息的报头（Header）”**。

**创造性及攻防漏洞深度分析（请求方最薄弱/最难攻击的特征点）：**

1. **D2的局限性（未公开特征C）**：D2虽然精细地设计了哪些字段压缩、哪些不压缩（如不压缩Content-Type），但D2的压缩框架是单向静态设定或基于本地协议知识的（如D2的`[0164]`）。D2完全没有提到**客户端与服务端之间如何动态协商该“应用层压缩算法”的支持能力**。

2. **D5与本案特征C的对比（Body vs Header）**：

* 无效请求方通常会试图用**D2 + D5**进行显而易见性推导，辩称：D2公开了选择性压缩负载，D5公开了在SUBSCRIBE中通告客户端过滤条件以改变后续NOTIFY。因此，在D2的基础上引入D5的协商机制，由客户端在SUBSCRIBE中通告AS自己支持何种负载压缩，是显而易见的。

* **然而，目标专利在此处构筑了精准的保护盾——“写入报头（Header）”**。

* 根据D5原文明示（图24及说明书叙述）：“ＰＣ７０４はＳＵＢＳＣＲＩＢＥを送信する際に、ＮＯＴＩＦＹを生成する条件を**ＳＵＢＳＣＲＩＢＥのボディ部（Body）**に記述する。なお、実際の条件の記述は**ＸＭＬ**が使われる”。D5通告能力/条件是放在消息的**体部（Body）**，由于使用了结构复杂的XML文件，服务端必须启动XML解析器对Body进行深度语义解析。

* 反观目标专利权利要求1，其特意强调指示是写入**“SUBSCRIBE消息的报头（Header）”**（如说明书所述的Accept或Accept-Encoding字段）。

**技术效果与整体解决技术问题的对立（答辩突破口）：**

在专利无效程序中，作为专利权人（目标专利），我们可以针对请求方（D2+D5组合）给出极其有力的反驳：

* **技术阻碍/反向教导**：目标专利的核心宗旨是**“降低中间节点的解析开销、与没有最新支持的终端保持兼容”**。如果按照D5的教导将指示写入**Body部**，IMS网络中的中间节点（或AS的底层结构）为了获知该终端是否支持压缩，必须强制对SUBSCRIBE的Body体进行昂贵的XML应用层解析，这违背了目标专利在报头层面（轻量级、明文路由）解决问题的初衷。

* **非显而易见性**：报头（Header）和体部（Body）在SIP协议栈中属于完全不同的处理层次。将负载压缩这种应用层的算法能力指示，跨层改写进入底层用户代理（UA）可直接读取并处理的SIP**报头**中，超出了常规活动过滤器（Body层XML）的惯用手段范畴。

### 四、 无效宣告请求的诉讼建议

1. **对于无效请求方而言最薄弱（最难攻克）的技术特征**：

终端通过应用层将负载压缩支持指示**写入SIP SUBSCRIBE消息的“报头（Header）”**。

2. **诉讼应对策略**：

* **如果您是请求方（试图无效此专利）**：切勿单用D2+D5（因为Body和Header的技术分野很明显，容易被专利局合议组判定存在技术阻碍）。您必须扩大检索范围，全力寻找一份**公开了在SIP/HTTP协议中，利用Accept-Encoding或自定义Header报头字段来携带“数据压缩算法/有效负载解压算法能力协商”的通信基础对比文件（D6）**。通过 D2（选择性有效负载压缩）+ D6（报头字段能力协商）的组合，方可瓦解特征C的创造性高度。

* **如果您是专利权人（防守方）**：应牢牢咬死“报头限定带来的高效率路由及免XML解析的技术效果”，强调D2未解决协商问题、D5的Body XML方案存在反向教导，从而稳固该专利的创造性。

如权利要求1所述的方法， 所述NOTIFY消息的报头被无压缩地发送； 使得所述NOTIFY消息能通过任何中间CSCF和应用服务器来路由

如权利要求1或2所述的方法， 使用gzip来执行消息有效负荷的所述压缩和解压

如前面权利要求的任一项所述的方法， 并且包括；在所述SUBSCRIBE消息的接受或接受编码报头字段中包括所述指示

如权利要求4所述的方法， 并且包括；经由所述应用编程接口从在所述用户终端的所述应用层将所述接受或接受编码报头字段写到所述会话发起协议用户代理器

如前面权利要求的任一项所述的方法， 其中所述SUBSCRIBE和NOTIFY消息涉及存在服务