一种会话控制实体（3），其包括 用于接收（31）注册用户（1）的请求的装置，； 用于确定（32）该请求是否包括针对紧急服务的注册请求的装置,；其中所述确定包括探测所述请求中的紧急指示，；用于维持（34）关于被分派用于紧急分组数据连接并且被一致地配置在会话控制实体中和分组数据网关(GGSN,P-GW)中的因特网协议（IP）地址的范围的信息的装置，；用于确定（33）该请求是否经由紧急分组数据连接被接收到的装置，；其中确定包括确定该请求中的因特网协议（IP）地址是否属于被分派用于紧急分组数据连接的因特网协议（IP）地址的范围，；以及用于如果因特网协议（IP）地址基于确定被分派用于紧急分组数据连接并且所述请求并不包括针对紧急服务的注册请求那么拒绝（36）所述请求的装置。

### 权利要求1的技术方案解析

结合目标专利说明书（CN103053149B）的相关记载，特别是第 [0005]-[0008] 段以及第 [0055]-[0058] 段落的描述，权利要求1保护一种**会话控制实体**（主要指代 IMS 网络中的 P-CSCF）。

该权利要求的核心发明点在于：**在应用层（SIP 会话层）防止欺诈用户为了非紧急目的而滥用高优先级的紧急分组数据连接（PDN 承载层）资源。**

为了实现这一目的，会话控制实体执行以下核心逻辑：

1. **信息同步配置**：P-CSCF 内部维持了一段专用于“紧急分组数据连接”的 IP 地址范围信息，且该范围与底层分组数据网关（GGSN、P-GW）中的配置保持一致（即网关在紧急附着时仅从该范围分配 IP）。

2. **承载层交叉验证**：当 P-CSCF 接收到用户的 SIP 注册请求时，不仅要探测请求本身是否带有应用层的“紧急指示”（如 SIP REGISTER 消息中的特定标记），还会提取该请求中的 IP 地址（如 SIP 联系头部中的联系地址）。

3. **滥用判定与拒绝**：P-CSCF 将提取到的 IP 地址与预留的紧急 IP 地址范围进行比对。如果 IP 地址落入该范围（说明底层实际占用了紧急 PDN 连接资源），但应用层的 SIP 注册请求并未包含紧急指示（说明用户在应用层发起的并非紧急服务），则 P-CSCF 直接拒绝该请求。

---

### 对比文件D1（WO2008009234A1）对比分析

对比文件 D1 公开了一种在 IMS 中识别滥用紧急承载资源的方法、装置及系统。特别是 D1 的**第五实施例（结合图 7）**，详细描述了通过在 GGSN 预留紧急 IP 地址范围，并在 P-CSCF 端进行 IP 地址和业务类型双重校验的防滥用机制。

以下是目标专利权利要求1与对比文件 D1 的技术特征详细比对分析：

#### 技术特征 A：其包括用于接收（31）注册用户（1）的请求的装置

* **D1 公开内容**：D1 公开了一种应用层服务器（P-CSCF），“步骤 605，GGSN 将所述注册请求消息转发给 P-CSCF，P-CSCF 接收该消息”。

* **比对结论**：D1 明确公开了该特征。

#### 技术特征 B & C：用于确定该请求是否包括针对紧急服务的注册请求的装置；其中所述确定包括探测所述请求中的紧急指示

* **D1 公开内容**：D1 第 15 页“步骤 611~616”指出，“P-CSCF 将检查该请求是否是紧急业务”；第 19 页在描述“紧急业务识别单元 83”时进一步明确，“紧急业务识别单元 83 可以通过对消息接收单元 81 接收的来自应用层的消息中**是否包含紧急业务指示信息进行检查**，来确定应用层是否为紧急业务...所述紧急业务指示信息可以是被叫号码、**用户的注册信息等**”。

* **比对结论**：D1 明确公开了该特征。

#### 技术特征 D：用于维持关于被分派用于紧急分组数据连接并且被一致地配置在会话控制实体中和分组数据网关(GGSN,P-GW)中的因特网协议（IP）地址的范围的信息的装置

* **D1 公开内容**：D1 第 14 页“步骤 600，在 GGSN 上为紧急业务预留一个源 IP 地址范围，用于为申请紧急业务的承载资源的用户分配”；“步骤 601，**在 P-CSCF 上通过配置或者其它手段获知 GGSN 上预留的源 IP 地址范围**，以便在 P-CSCF 收到所述预留 IP 范围内的请求时，检查该请求是否为紧急业务”。

* **比对结论**：D1 中的 P-CSCF 获知并记录了 GGSN 预留的紧急源 IP 地址范围，实质上公开了在会话控制实体和分组数据网关中一致配置并维持紧急 IP 地址范围信息的特征。

#### 技术特征 E & F：用于确定该请求是否经由紧急分组数据连接被接收到的装置，其中确定包括确定该请求中的因特网协议（IP）地址是否属于被分派用于紧急分组数据连接的因特网协议（IP）地址的范围

* **D1 公开内容**：D1 第 15 页“步骤 611~616”指出，“P-CSCF **根据所述注册请求消息中的源 IP 地址检查该 IP 是否属于为紧急业务所预留的源 IP 地址范围，若是，则 P-CSCF 认为该消息为采用紧急承载资源的消息**”。

* **比对结论**：D1 明确公开了基于请求中提取的 IP 地址是否落入预留 IP 范围，来确定底层是否使用了紧急承载（紧急分组数据连接）的特征。

#### 技术特征 G：用于如果因特网协议（IP）地址基于确定被分派用于紧急分组数据连接并且所述请求并不包括针对紧急服务的注册请求那么拒绝所述请求的装置

* **D1 公开内容**：D1 第 15 页“步骤 611~616”指出，当 P-CSCF 认为该消息采用了紧急承载资源后，“P-CSCF 将检查该请求是否是紧急业务，**如果请求的不是紧急业务，则 P-CSCF 认为该请求为非法请求**”（在通信协议处理逻辑中，判定为非法请求即等同于拒绝该请求，D1 第 20 页也明确提到“如果识别装置 921 检查结果为所述呼叫滥用紧急承载资源，则**禁止**或重定向所述呼叫”）。

* **比对结论**：D1 明确公开了在承载层使用了紧急 IP 资源但应用层请求非紧急业务时，予以拒绝/禁止的技术特征。

---

### 技术特征比对表

---

### 结论

对比文件 D1 的第五实施例及其配套的装置/系统说明，已经**单独且毫无疑义地公开**了目标专利权利要求 1 的全部技术特征。权利要求 1 所要求保护的 P-CSCF 侧利用 IP 地址范围一致性配置进行跨层（承载层与应用层）滥用校验的防欺诈逻辑，在 D1 中已被完整揭示。因此，**权利要求 1 相对于对比文件 D1 不具备新颖性**。

针对所提出的问题，我将紧密结合目标专利“CN103053149B”的说明书以及各对比文件的原文，重点分析这些对比文件是否单独或者组合毫无疑义地公开或实质公开了目标专利权利要求1中的技术特征C。

以下是具体的分析过程：

### 1. 目标专利技术特征C的专利法解释及说明书对应

首先，我们需要明确技术特征C在目标专利中的含义和作用。

**技术特征C**：其中所述确定包括探测所述请求中的紧急指示，

**专利法解释**：该特征限定了权利要求1中“用于确定（32）该请求是否包括针对紧急服务的注册请求的装置”的具体工作方式。即，会话控制实体（如P-CSCF）通过检查接收到的注册请求（如SIP REGISTER消息）中是否包含特定的“紧急指示”（Emergency Indicator）来判定该请求是否用于紧急服务的注册。

**说明书对应**：目标专利说明书【0013】中明确指出：“确定请求是否包括针对紧急服务的注册请求可以包括在请求中探测指示了用户正针对紧急服务进行注册的指示。”此外，在【0057】中描述信令流时，进一步具体化为：“UE 1也可以指示，为了紧急目的通过在请求中包括紧急指示，注册请求被发送来注册用户。在17中，P-CSCF 3可以探测到注册请求中的紧急指示。”

因此，该特征的技术实质在于会话控制实体主动探测（探测/检查）注册请求消息本身中携带的、用于明确标示其为紧急目的的指示。

### 2. 各对比文件原文分析与技术特征比对

接下来，我将依据对比文件原文，采用技术特征比对表格的形式，分析特征C的公开情况。

#### 2.1 技术特征比对表

#### 2.2 详细出处及比对分析

**对比文件3：US20080008157A1 (Method And Apparatus For Parallel Registration And Call Establishment)**

本领域技术人员结合D3的原文，可以毫无疑义地确定其公开了特征C。

* **D3原文详细出处**：具体实施方式第【0063】段。

* **D3原文内容**：

“...UE 110 may start registration by sending a **SIP REGISTER message** to P-CSCF 252 in visited network 130 (step 2). The **SIP REGISTER message may include an indication of an emergency call** and identification information for UE 110, e.g., a public emergency Uniform Resource Identifier (URI). P-CSCF 252 may forward the SIP REGISTER message to I-CSCF 262 in home network 160 (step 3). ...”

*（译文：……UE 110可以通过向拜访网络130中的P-CSCF 252发送 **SIP REGISTER消息** 来开始注册（步骤2）。该 **SIP REGISTER消息可以包括紧急呼叫的指示** 和UE 110的标识信息，例如公共紧急统一资源标识符（URI）。P-CSCF 252可以将该SIP REGISTER消息转发给归属网络160中的I-CSCF 262（步骤3）。……）*

**分析比对：**

D3公开了用户设备UE（对应目标专利的注册用户1）向拜访网络中的会话控制实体P-CSCF（对应目标专利的会话控制实体3）发送“SIP REGISTER消息”（即目标专利的“注册用户的请求”）。

D3明确指出了该“SIP REGISTER消息可以包括紧急呼叫的指示”（对应目标专利的“紧急指示”）。

在此基础上，虽然D3在【0063】段主要描述P-CSCF转发该消息，但本领域技术人员知晓，作为IMS网络中的核心会话控制节点，P-CSCF在转发请求之前必然需要对消息体进行解析和处理。既然D3已经明确该REGISTER消息中包含“紧急呼叫的指示”，P-CSCF在接收并处理该消息的过程中，必然毫无疑义地会对其进行“探测”（即检查或识别），从而确定该注册请求是为了紧急服务。这与目标专利说明书【0057】中描述的“P-CSCF 3可以探测到注册请求中的紧急指示”的技术实质是一致的。

因此，**对比文件3单独实质公开了目标专利的技术特征C**。

### 3. 分析结论

综上所述，作为一名经验丰富的专利代理师，我的分析结论如下：

针对目标专利“CN CN10305 CN103053149B”权利要求1中的技术特征C，**对比文件3（US20080008157A1）在其具体实施方式第【0063】段中，已经单独毫无疑义地公开了该技术特征的技术实质**。技术特征C并非由多个对比文件组合而成。

作为一名经验丰富的专利代理师，我现就目标专利 CN103053149B 的权利要求1，特别是技术特征C的公开情况，结合对比文件原文进行深入分析。

### 一、 权利要求特征合理解释

**技术特征C**：“其中所述确定包括探测所述请求中的紧急指示”。

在目标专利说明书背景技术及具体实施方式（如段落 [0013]、[0048]、[0049]）中，该特征被解释为：会话控制实体（如 P-CSCF）在接收到用户设备（UE）发送的注册请求（如 SIP REGISTER）时，通过检查报文中的特定字段（即“紧急指示”，Emergency Indication）来识别该请求的性质。例如，段落 [0049] 明确提到：“同样在 SIP 中，紧急指示可以被包括在紧急注册请求（例如 SIP 注册 (SIP REGISTER)）中”。因此，特征C的核心在于**会话控制实体对业务请求报文内容的解析与识别**。

---

### 二、 对比文件针对技术特征C的实质公开分析

经过对四份对比文件的逐一梳理，分析结果如下：

#### 1. 对比文件 D1 (US2010048161A1)

D1 公开了无线通信系统中实现紧急通信的方法。其在描述 IMS 紧急业务处理时，明确提到了 P-CSCF 对紧急指示的识别。

* **原文出处**：段落 [0013] 提到：“The P-CSCF receives the emergency service registration... and **identifies that the service requested by the terminal is an emergency service according to an emergency service indication carried in the request**...”（P-CSCF 接收紧急业务注册……并根据请求中携带的紧急业务指示识别出终端请求的业务是紧急业务）。

* **结论**：D1 已经**明确公开**了技术特征C。

#### 2. 对比文件 D2 (JP2010114872A)

D2 主要涉及防止垃圾多媒体通信（SPIT）的控制方法。

* **原文分析**：其侧重于通过 I-CSCF 进行可靠性检查、判定 SPIT 并记录黑名单。虽然涉及 SIP 消息的处理，但并未描述 P-CSCF 通过探测请求中的“紧急指示”来判定紧急注册的技术方案。

* **结论**：D2 **未公开**技术特征C。

#### 3. 对比文件 D3 (CN101730037A)

D3 提出了一种防止 UE 使用紧急承载进行正常业务的方法，侧重于 P-GW 的路由限制。

* **原文出处**：段落 [0004] 在描述背景技术时提到：“P-CSCF 应该拒绝并不是用于紧急目的而是通过使用紧急 PDN 连接所接收到的任何 IMS 注册”。

* **原文出处**：步骤 201 提到：“UE 向 MME 发起紧急附着请求……上述请求中携带紧急标识”。

* **分析**：虽然 D3 提到了请求中携带紧急标识以及 P-CSCF 拒绝非紧急目的注册的原则，但其核心方案是通过 P-GW 限制路由。对于“会话控制实体探测请求中的紧急指示”这一具体动作，其描述多属于行业通用背景。

* **结论**：D3 **实质公开**了紧急指示的存在，但在具体装置实现层面不如 D1 直接。

#### 4. 对比文件 D4 (CN101730039A)

D4 侧重于通过 HSS 记录 IP 地址属性来拦截异常注册。

* **原文分析**：同 D3，D4 提到了 UE 在建立紧急承载时携带紧急标识，但在 IMS 注册阶段，它主要讨论 I-CSCF 与 HSS 的交互。

* **结论**：D4 **未明确公开**会话控制实体探测紧急指示的具体逻辑。

---

### 三、 技术特征比对表

以下是针对权利要求1各技术特征与对比文件的详细比对：

---

### 四、 结论

1. **关于技术特征C**：对比文件 **D1 (US2010048161A1)** 在段落 [0013] 中已经**单独且毫无疑义地公开**了“P-CSCF 根据请求中携带的紧急业务指示（emergency service indication）识别业务”的技术特征。因此，特征C不具备新颖性。

2. **整体专利性分析**：虽然特征C已被 D1 公开，但权利要求1作为一个整体，其创造性主要体现在**特征D、E、F、G**的组合。即：通过在“会话控制实体（P-CSCF）”中**维持一个与“分组数据网关（P-GW）”一致的特定 IP 地址范围**，并利用该范围在 SIP 协议层对请求的合法性进行双重复核（既看请求报文里的指示，也看报文来源的 IP 地址归属）。对比文件 D3 和 D4 虽然提出了防止滥用紧急承载的问题，但其解决方案分别侧重于“P-GW 路由强制过滤”和“HSS 签约状态校验”，均未公开在会话控制实体内部通过维持 IP 范围信息来实现特征 G 所述的拒绝逻辑。

综上所述，技术特征C已被 D1 公开，但权利要求1整体相对于现有技术仍具有明显的区分特征。

同行您好。针对您提供的目标专利（CN103053149B）权利要求1以及三篇对比文件，我已进行了详细的侵权/无效分析比对。

为了确保比对的绝对严谨性，以下分析严格以您提供的文本为基础，不作任何超范围的技术推演或假设，并确保引用的出处精准无误。

### 一、 目标专利及权利要求1与技术特征C解析

**目标专利核心构思：**

目标专利（CN103053149B）要解决的技术问题是：防止欺诈的用户设备（UE）将紧急PDN连接（分组数据网络连接）用于非紧急的IMS注册目的（详见说明书[0004]及[0025]）。

**技术特征C解析：**

* **技术特征C**：“其中所述确定包括探测所述请求中的紧急指示，”

* **说明书支撑**：结合说明书[0049]“同样在SIP中，紧急指示可以被包括在紧急注册请求（例如SIP注册（SIP REGISTER））中...”以及[0057]“在17中，P-CSCF 3可以探测到注册请求中的紧急指示。”可知，特征C限定了**会话控制实体（P-CSCF）需要在应用层（SIP层）的注册请求（Register Request）中，去探测是否包含“紧急指示（Emergency Indication）”**。这是目标专利进行后续逻辑判断（即特征G：判断IP是紧急的，但SIP请求中没有紧急指示，则拒绝）的先决条件。

---

### 二、 对比文件公开情况严格核查（针对特征C）

以下我们将逐一审查D1、D2、D3是否单独或组合实质公开了技术特征C。

#### 1. 审查 D1 (US2006174009A1)

* **审查结果：未公开**。

* **分析**：D1主要涉及在IMS域中通过“Push Proxy”机制激活信令PDP上下文以建立多媒体会话。全文检索关于“emergency”，仅在段落 `[0020]` 中泛泛提及了 P-CSCF 的一般功能包括：“...handling local emergency calls...”（处理本地紧急呼叫）。D1并未涉及如何具体识别紧急注册，更未公开P-CSCF在SIP注册请求中探测“紧急指示”的具体技术手段。

#### 2. 审查 D2 (US2010211686A1)

* **审查结果：未公开**。

* **分析**：D2涉及IMS中的用户面控制和本地疏导（Local Breakout）策略，主要由S-CSCF根据漫游状态和媒体类型来决定路由。全文未提及任何与“紧急服务（Emergency Services）”、“紧急注册”或“紧急指示”相关的技术内容。

#### 3. 审查 D3 (WO2010127529A1)

* **审查结果：未公开**。

* **分析**：D3是与目标专利最接近的现有技术，其发明目的同样是“防止UE使用紧急承载发起IMS正常业务”。

* **D3的机制**：D3通过底层网络元件（MME）在UE发起紧急附着时，将该IP地址通知给归属用户服务器（HSS）并记录（详见 `步骤303`）。当UE后续试图用该IP进行IMS**正常业务**注册时，HSS/I-CSCF/P-CSCF直接根据该**IP地址**将其拦截并拒绝（详见 `步骤308-311`）。

* **关于“紧急指示”的区别**：D3在 `步骤301` 中公开了：“UE向MME发起紧急附着请求...上述请求中携带**紧急业务标识**”。请注意，这里的“紧急业务标识（Emergency APN等）”是携带在**底层承载建立请求**（如紧急附着请求）中发给**MME**的，而非携带在应用层的**SIP注册请求**中发给**P-CSCF**的。

* 在D3的SIP注册阶段（ `步骤306`：“UE使用已建立的紧急承载向P-CSCF发起IMS**正常**业务的注册请求”），UE发起的是“正常”注册，本身就不携带紧急指示，P-CSCF也未执行“探测注册请求中是否包含紧急指示”的步骤，而是被动等待HSS/I-CSCF基于IP地址的拦截指令。

#### 4. 组合评价

由于D1和D2均未提供任何关于在SIP注册请求中探测紧急指示的技术启示，D3虽然涉及紧急承载防滥用，但其技术路线是“IP地址黑名单映射/拦截”，而非“侦测SIP信令本身是否带有紧急标签”。因此，D1-D3的任何组合均无法毫无疑义地得出技术特征C。

---

### 三、 技术特征比对表格

---

### 四、 案件成功率中立评估

从专利无效宣告/行政诉讼的实务角度来看，若仅依赖本提示词提供的D1、D2、D3，**攻破权利要求1的概率极低**。

**关键障碍在于：**

目标专利权人将防欺诈逻辑建立在**双重验证**上：(1) 底层IP属于紧急PDN池（特征F） + (2) 应用层SIP请求未携带紧急指示（特征C/G）。

而对比文件D3的防欺诈逻辑是**单向拦截**：只要底层IP是紧急分配的，无论SIP请求长什么样，直接在HSS/I-CSCF端基于IP拦截。

D3缺失了SIP层面的信令探测动作（特征C）。如果在后续无效检索中，无法补充一篇明确公开“在IMS SIP注册信令（如SIP REGISTER）头部/内容中设置并由P-CSCF解析紧急标识（Emergency indication）”的对比文件（例如3GPP TS 24.229的相关早期版本规范），要论证特征C属于本领域的公知常识将面临举证困难，从而难以破坏权利要求1的新颖性与创造性。建议将下一步的检索重心严格锁定在3GPP规范关于 `SIP REGISTER` 消息中紧急标识（如 `sos` SIP URI 参数）的处理机制上。

根据权利要求1所述的会话控制实体，其中，所述请求中的因特网协议（IP）地址包括用户的联系地址，和/或被嵌入在会话发起协议的联系头部中。

根据权利要求1至2中的任意权利要求所述的会话控制实体，进一步包括用于如果所述请求基于确定包括针对紧急服务的注册请求那么将所述请求传送（35）到另一会话控制实体的装置。

一种方法，其包括： 如果分组数据连接包括紧急分组数据连接，那么在所述分组数据连接的建立期间针对用户分配（42）来自被分派用于紧急分组数据连接的因特网协议（IP）地址的范围的因特网协议(IP)地址,其中在分组数据连接的建立期间，基于从用户接收到的指示来判定（41）分组数据连接是否包括紧急分组数据连接，确定（44）注册用户的请求是否经由紧急分组数据连接被接收到，其中确定包括确定所述请求中的因特网协议（IP）地址是否属于被分派用于紧急分组数据连接的因特网协议（IP）地址的范围，确定（45）所述请求是否包括针对紧急服务的注册请求,其中所述确定包括判定所述请求中的紧急指示，以及如果基于确定经由紧急分组数据连接接收到所述请求并且所述请求并不包括针对紧急服务的注册请求，那么拒绝（46）所述请求。

根据权利要求4所述的方法，进一步包括：如果所述请求基于确定包括针对紧急服务的注册请求，那么向会话控制实体传送（47）所述请求。

一种用于注册的方法，其包括： 分配（51）用于分组数据网关（GGSN、P-GW）中的紧急分组数据连接的因特网协议（IP）地址的范围，在会话控制实体（P-CSCF）中配置（52）因特网协议（IP）地址的范围，当从用户设备（UE）接收到注册请求时，由会话控制实体来探测（53）用户设备（UE）是否将紧急分组数据连接用于非紧急注册请求，其中探测包括探测用户设备（UE）的联系地址中的因特网协议（IP）地址是否被包括在用于紧急分组数据连接的因特网协议（IP）地址的范围中并且确定所述请求是否包括紧急指示，以及如果用户设备（UE）将紧急分组数据连接用于非紧急注册请求，那么拒绝（54）所述请求。

一种系统，其包括： 用于在分组数据网关（GGSN、P-GW）中维持（23）关于被分派用于紧急分组数据连接的因特网协议（IP）地址的范围的信息的装置，用于在会话控制实体中维持（34）关于被分派用于紧急分组数据连接的因特网协议（IP）地址的范围的信息的装置，用于如果分组数据连接包括紧急分组数据连接则在该分组数据连接在分组数据网关中的建立期间针对用户分配（22、25）来自被分派用于紧急分组数据连接的因特网协议（IP）地址的范围的因特网协议(IP)地址的装置，用于在会话控制实体中确定（33）注册用户的请求是否经由紧急分组数据连接被接收到的装置，其中确定包括确定该请求中的因特网协议（IP）地址是否属于被分派用于紧急分组数据连接的因特网协议（IP）地址的范围,用于在会话控制实体中确定(32)所述请求是否包括针对紧急服务的注册请求的装置,其中所述确定包括探测所述请求中的紧急指示,以及用于在会话控制实体中如果基于所述确定所述因特网协议(IP)地址被包括在被分派用于紧急分组数据连接的因特网协议（IP）地址的范围并且所述请求并不包括针对紧急服务的注册请求那么拒绝（36）所述请求的装置。