对比文件名称：2006-11-23_WO2006123221A_发明申请_WO2006123221A1 SIGNALING COMPRESSION_DECOMPRESSION
目标专利名称：1085会话发起协议消息有效负荷压缩CN101843071B
本次调用的模型名称：DeepSeek-Chat
## 特征比对表格
| 技术特征描述及公开性判断 | 对比文件原文引用 | 公开性论述 |
| **技术特征A（未公开）**：所述方法包括在所述会话发起协议应用服务器的应用层内压缩所述NOTIFY消息有效负荷并在所述用户终端的应用层解压它们。 | 对比文件[0006]：“SigComp architecture can be interpreted as an enhancement to transport layer. Thus, SigComp provides the higher layer applications for both transmission and compression of the messages.”（SigComp架构可被解释为传输层的增强。因此，SigComp为高层应用提供消息的传输和压缩。） | 对比文件公开的压缩机制由SigComp层（解释为传输层增强）执行，而非在应用层内。目标专利特征A要求在应用层内进行压缩/解压，而对比文件中压缩功能位于应用层之下，应用层将未压缩的消息交给SigComp层处理。因此，对比文件未直接公开特征A，且本领域技术人员无法从对比文件推断出在应用层内执行压缩/解压的技术方案，也未隐含公开。 |
| **技术特征B（未公开）**：压缩的NOTIFY消息有效负荷经由合适的应用编程接口在所述应用层和会话发起协议用户代理器之间传递。 | 对比文件[0008]：“The transmitting side of the SigComp architecture comprises a compressor dispatcher, one or more compressors and a state handler. The compressor dispatcher serves as the interface from the application. The application supplies the compressor dispatcher with an application message and a compartment identifier.”（发送侧的SigComp架构包括压缩分配器、一个或多个压缩器和状态处理器。压缩分配器用作来自应用的接口。应用向压缩分配器提供应用消息和隔间标识符。） | 对比文件公开了应用层与SigComp压缩层之间的接口（压缩分配器），用于传递未压缩的应用消息。然而，目标专利特征B要求应用层与SIP用户代理器（UA）之间经由API传递已压缩的有效负荷，且SIP UA不感知压缩。对比文件中的接口并非应用层与SIP UA之间的API，且传递的是未压缩消息，压缩发生在下层。因此，既不直接公开也无隐含公开。 |
| **技术特征C（未公开）**：所述应用层将有效负荷压缩由所述用户终端支持的指示写入将发送到所述会话发起协议应用服务器的SIP SUBSCRIBE消息的报头。 | 对比文件[0058]：“Second, the SigComp parameters can be indicated as part of a Via-header field.”（第二，SigComp参数可作为Via报头字段的一部分来指示。）以及[0059]：“the second component is useful for the same client to declare its own SigComp capacity… in the via-header field of the request.”（第二组件对于同一客户端在请求的via报头字段中声明自己的SigComp能力是有用的。） | 对比文件公开了在SIP消息报头（例如Via-header）中指示压缩参数，但该指示是由SIP层或SigComp功能添加的，而非由应用层写入。此外，该指示涉及SigComp能力参数，而非“有效负荷压缩由用户终端支持”的指示，且未限定于SUBSCRIBE消息。因此，对比文件未公开特征C，且本领域技术人员无法合理推断出由应用层在SUBSCRIBE消息报头中写入所述指示的方案。 |
| **技术特征D（未公开）**：所述NOTIFY消息的报头被无压缩地发送。 | 对比文件[0006]：“SigComp… can compress application-layer protocol messages.”（SigComp能够压缩应用层协议消息。）以及对比文件整体涉及对整个应用消息（包括报头）的压缩，未提及仅压缩有效负荷而保留报头不压缩。 | 对比文件公开的SigComp压缩整个应用层消息，包括报头和有效负荷。目标专利特征D要求仅压缩有效负荷，报头无压缩发送。对比文件未公开这种部分压缩方式，且没有给出任何启示将报头排除在压缩之外。因此，未直接公开也未隐含公开。 |
| **技术特征E（未公开）**：使得所述NOTIFY消息能通过任何中间CSCF和应用服务器来路由。 | 对比文件未明确阐述报头不压缩以利于路由。可参考[0010]：“The transport layer data stream is directed to the decompressor dispatcher, which must be arranged to identify the SigComp messages for decompression and to pass the non-SigComp messages to a particular application client…”（传输层数据流被导向解压分配器，该分配器必须被布置为识别SigComp消息以进行解压，并将非SigComp消息传递给特定应用客户端……） | 对比文件没有公开通过保持报头不压缩来使消息能无附加处理地通过中间CSCF和AS路由的技术手段。在SigComp机制下，SIP代理需要处理SIP报头时通常需要解压消息。因此，特征E未被公开。 |
| **技术特征F（未公开）**：使用gzip来执行消息有效负荷的所述压缩和解压。 | 对比文件[0016]：“In addition, the network has no way to effect what algorithm a terminal device uses in compression. It might use a very slow or inefficient algorithm.”（此外，网络无法影响终端设备在压缩中使用什么算法。它可能使用非常慢或低效的算法。）表明算法可选，但未提及gzip。 | 对比文件未公开使用gzip作为压缩/解压算法。虽然SigComp允许使用各种压缩算法，但对比文件没有明确提及gzip，也没有指向在应用层采用gzip。因此，特征F未被公开。 |
| **技术特征G（直接公开）**：包括 | 对比文件[0022]：“characterized in that said method comprises the steps of:”（所述方法包括以下步骤：） | 对比文件明确使用了“comprises”一词，表明方法包括步骤，与目标专利特征G“包括”具有相同的含义和作用。因此，该特征被直接公开。 |
| **技术特征H（未公开）**：在所述SUBSCRIBE消息的接受或接受编码报头字段中包括所述指示。 | 对比文件未公开使用Accept或Accept-Encoding报头字段来承载压缩指示。如[0058]-[0076]所示，对比文件采用Via-header参数或URI参数来指示压缩能力。 | 目标专利特征H限定在SUBSCRIBE消息的Accept/Accept-Encoding报头字段中包括指示。对比文件完全没有公开或暗示使用这些特定的报头字段，更未涉及SUBSCRIBE消息。因此，特征H未被公开。 |
| **技术特征I（直接公开）**：包括 | 对比文件[0022]：“characterized in that said method comprises the steps of:”（所述方法包括以下步骤：） | 与特征G同理，对比文件公开了方法包括步骤，因此直接公开特征I。 |
| **技术特征J（未公开）**：经由所述应用编程接口从在所述用户终端的所述应用层将所述接受或接受编码报头字段写到所述会话发起协议用户代理器。 | 对比文件未公开应用层通过API向SIP UA写入报头字段的机制。其公开的接口（如[0008]）是用于传递应用消息到压缩层，而非向SIP UA写特定报头。 | 目标专利特征J涉及应用层利用API将Accept/Accept-Encoding报头写入SIP UA，这需要SIP UA提供相应的API供应用层调用。对比文件完全没有公开此类API及其调用过程，本领域技术人员无法从对比文件中推断出该技术方案。因此，特征J未被公开。 |
| **技术特征K（未公开）**：其中所述SUBSCRIBE和NOTIFY消息涉及存在服务。 | 对比文件[0005]：“SIP is defined by the IETF… in RFC 3261 and is an application-layer protocol used for (among other things) establishing, handling and releasing end-to-end multimedia sessions.”（SIP由IETF在RFC3261中定义，是一种应用层协议，用于建立、处理和释放端到端多媒体会话等。）对比文件未提及存在服务。 | 对比文件仅一般性地提到SIP用于多媒体会话，未具体公开SUBSCRIBE和NOTIFY消息涉及存在服务。因此，特征K未被公开。 |
<<<G>>><<<I>>>