好的，本次分析对比文件为：2003-10-02_US2003185189A_发明申请_US20030185189A1 TDD-RLAN wireless telecommunication system with RAN IP gateway and methods，目标专利为：957通信网络系统中的不同IP接口CN101978667B，本次调用的模型为 DeepSeek-Chat。
以下是针对目标专利权利要求的特征比对分析。
### 特征比对表格
| 技术特征描述以及公开性判断结果 | 对比文件原文引用 | 公开性论述 |
| 技术特征A：包括：确定用户平面接口的类型，呼叫将经由该用户平面接口被处理。<br><br>**结论：未公开** | 对比文件明确探讨了用户平面（U-plane）和控制平面（C-plane）的分离，并描述了数据通过不同的接口（如Iu-PS、Iu-CS）进行路由。例如，[0017]段提到：“The UTRAN segment of a conventional UMTS architecture is split it into two traffic planes known as the C- and U- planes. The C-plane carries control (signaling) traffic, and the U-plane transports user data.” 此外，[0071]段描述了：“An Iub interface between each Node B and RNC is preferably implemented both in the control plane and the user data plane as a layered stacked protocol having Internet Protocol (IP) as the transport layer. Similarly at least a subset of an Iu-PS interface is preferably provided between an RNC and the RAN IP Gateway that is a layered stacked protocol having IP as the transport layer.” 对比文件还描述了当UE移动到RLAN服务区域外时，通过RAN IP网关利用IP分组服务进行切换（[0074]段）。 | 对比文件涉及在无线接入网络（UTRAN/RLAN）内使用IP作为传输层，并区分了用户平面和控制平面。然而，对比文件的核心思想是在无线接入网（RAN）层面引入一个RAN IP网关（RIP GW），使得无线接入网可以直接连接到互联网。在这个过程中，网络设备（如RNC或RAN IP网关）虽然处理用户数据，但并没有描述一个用于确定“呼叫将经由其处理”的特定“用户平面接口类型”（如目标专利中的A、Nb、Mb、Abis参考点）的步骤。对比文件中的接口（如Iu-PS）是静态配置或由标准定义的，而不是由控制装置动态确定并指示给网关的。因此，对比文件没有公开控制装置主动确定一个特定的用户平面接口类型的特征。 |
| 技术特征B：其中所确定的类型的用户平面接口是基于因特网协议的接口并且其中不使用Nb用户平面成帧协议<br><br>**结论：未公开** | 对比文件多处强调使用IP作为传输层协议，例如[0071]段：“...layered stacked protocol having Internet Protocol (IP) as the transport layer.” 整个发明背景和具体实施方式都围绕IP连接展开。对比文件没有提及“NbUP (Nb User Plane) framing protocol”（Nb用户平面成帧协议）。 | 虽然对比文件明确描述了使用基于因特网协议（IP）的接口，但其并未讨论或提及“Nb用户平面成帧协议（NbUP）”。目标专利的特征B是一个否定性特征，即明确排除了NbUP协议的使用。对比文件中没有关于是否使用NbUP协议的任何描述，因此不能得出其排除了NbUP协议的结论。本领域技术人员也无法从对比文件中毫无疑义地推断出其所使用的IP接口中不使用NbUP成帧协议。 |
| 技术特征C：在具有参考点值的分组中指示基于因特网协议的用户平面接口类型，<br><br>**结论：未公开** | 对比文件[0081]段提到：“The C-plane server is then coupled to the U-plane server via a Media gateway control protocol gateway (Megaco) over an IP transport layer. Megaco is a control plane protocol that sets up the bearer connection(s) between a Voice gateway elements...” 对比文件没有描述任何“具有参考点值的分组”。 | 对比文件描述的控制协议（Megaco，即H.248）用于在语音网关元素之间建立承载连接。然而，对比文件完全没有公开在例如Megaco/H.248协议的分组（如目标专利中的IPUP分组）中，使用一个“参考点值”来指示接口类型（如“A”、“Nb”、“Mb”）。对比文件没有描述通过分组携带参考点信息来指示接口类型的技术方案。 |
| 技术特征D：其中所述参考点值对应于所述基于因特网协议的用户平面接口类型，<br><br>**结论：未公开** | 对比文件无相关描述。 | 由于对比文件没有公开“具有参考点值的分组”以及“指示基于因特网协议的用户平面接口类型”，因此更不可能公开“参考点值对应于接口类型”这一具体特征。 |
| 技术特征E：所述分组被包含在终结点保留消息中<br><br>**结论：未公开** | 对比文件[0081]段描述了Megaco（H.248）协议用于控制平面，“sets up the bearer connection(s)...” 这可以广义地理解为一种资源保留过程。 | 虽然对比文件提到了Megaco/H.248协议用于设置承载连接，但其并没有描述一个名为“终结点保留消息”的特定消息，更未描述将包含参考点值的分组包含在该消息中。对比文件对Megaco的应用场景与目标专利完全不同（语音网关vs. MGW IP接口类型识别）。 |
| 技术特征F：发送包括所述分组的所述终结点保留消息。<br><br>**结论：未公开** | 对比文件无相关描述。 | 基于以上分析，对比文件未公开包括分组的终结点保留消息，因此也未公开发送该消息的特征。 |
| 技术特征G：包括：接收与所述呼叫相关的控制平面信令消息<br><br>**隐含公开** | 对比文件[0017]段：“The C-plane carries control (signaling) traffic...” 以及[0067]段描述了当UE在RLAN外时，第二UE的通信被导向第一UE的归属地址，该地址由核心网维护，核心网收到IP数据包后将其转发。整个通信流程必然涉及控制平面信令的交互。 | 在典型的通信网络系统中，要处理一个呼叫，控制装置（如MSC）必然需要接收与该呼叫相关的控制平面信令消息（如呼叫建立请求、SIP消息等）。对比文件描述了核心网和RAN IP网关参与通信，虽然未明确写出“接收控制平面信令消息”这一步骤，但这是实现其系统功能（如移动性管理、会话建立）的基础和前提。本领域技术人员可以合理推断，为了实现通信，控制装置必然会接收相关的控制平面信令消息。 |
| 技术特征H：根据所述控制平面信令消息来确定所述基于因特网协议的用户平面接口类型。<br><br>**结论：未公开** | 对比文件[0067]段提到，当UE在RLAN外，核心网起到路由作用。核心网知道UE是在归属网络还是在外地网络。但这种确定是基于位置或归属关系的，而非基于信令消息来确定是“A”、“Nb”或“Mb”这类细粒度的用户平面接口类型。 | 对比文件虽然涉及根据网络拓扑或UE位置确定数据路由，但其确定的数据路径是基于核心网和RAN的架构（Iu-PS, Iu-CS等），而不是目标专利中那种细粒度的、针对特定IP接入技术（AoIP, Nb over IP, Mb）的接口类型。控制装置（如MSC）根据控制信令（如SIP-I中的MSS指示，或BSSAP中的A接口指示）来区分并确定是A、Nb还是Mb参考点，这一核心思想在对比文件中完全没有体现。 |
| 技术特征I：其中，所述控制平面信令消息包括呼叫建立请求消息、协商发起消息和协商响应消息中的至少一个。<br><br>**结论：未公开** | 对比文件[0067]-[0068]段描述了UE间通信的IP数据包流程，涉及数据包的发送和转发。但未具体指明是“呼叫建立请求”、“协商发起”或“协商响应”消息。 | 尽管对比文件必然包含呼叫建立的流程，但其并未明确公开其所使用的控制平面信令消息的具体类型。特别是，其没有公开用于用户平面接口类型协商的“协商发起消息”和“协商响应消息”（如SIP-I消息）。这些特定消息类型是目标专利中用于区分接口类型的关键。 |
| 技术特征J：包括：接收呼叫建立请求消息<br><br>**隐含公开** | 对比文件[0067]段：“FIG. 10 illustrates IP packet data flow for a communication between a first UE ... and a second UE ...” 建立通信的第一步必然是接收某种形式的呼叫建立请求。 | 建立任何通信连接，无论是语音还是数据，都需要一个初始的请求。在移动通信系统中，这个请求可以理解为呼叫建立请求消息。虽然对比文件没有明确写出“接收呼叫建立请求消息”这个步骤，但这是通信建立流程中隐含的、必不可少的前提。本领域技术人员可以合理推断这一特征存在。 |
| 技术特征K：在对所述呼叫建立请求消息进行反应的将被发送的协商发起消息中，把装置指示为所述协商发起消息的发送方，其中所述协商发起消息将通过所述装置被发送<br><br>**结论：未公开** | 对比文件没有描述在协商消息（如SIP消息）中指示发送方身份的机制。其描述的通信流程主要涉及数据包的路由和转发（[0067]-[0069]段），并未详细描述MSS之间的SIP-I协商过程。 | 该特征高度具体，描述了目标专利中MSC服务器（MSS）之间通过SIP-I协议进行协商的核心步骤，即在SIP-I消息中指示“此消息的发送方是MSS”，以便接收方据此确定用户平面接口为Nb参考点。对比文件完全没有描述MSS之间的这种协商过程和特定指示方法。 |
| 技术特征L：发送所述协商发起消息。<br><br>**结论：未公开** | 对比文件无相关描述。 | 基于对技术特征K的分析，对比文件未公开协商发起消息的生成和发送过程。 |
| 技术特征M：包括：接收协商发起消息<br><br>**结论：未公开** | 对比文件无相关描述。 | 基于对技术特征K的分析，对比文件未公开MSS之间交互协商发起消息的过程，因此也未公开接收该消息的特征。 |
| 技术特征N：在对所述协商发起消息进行反应的将被发送的协商响应消息中，把装置指示为所述协商响应消息的发送方，其中所述协商响应消息将通过所述装置被发送<br><br>**结论：未公开** | 对比文件无相关描述。 | 该特征与特征K对应，描述了SIP-I协商中的响应步骤。对比文件同样没有描述此过程。 |
| 技术特征O：发送所述协商响应消息。<br><br>**结论：未公开** | 对比文件无相关描述。 | 基于对技术特征N的分析，对比文件未公开协商响应消息的生成和发送过程。 |
| 技术特征P：包括：使用H.248协议来发送所述终结点保留消息。<br><br>**结论：未公开** | 对比文件[0081]段提到：“The C-plane server is then coupled to the U-plane server via a Media gateway control protocol gateway (Megaco) over an IP transport layer. Megaco is a control plane protocol...” Megaco是H.248协议的一个实现。 | 虽然对比文件提到了使用Megaco（H.248）协议，但其应用场景是在C-plane server和U-plane server之间，或者与语音网关之间，用于建立承载连接。这与目标专利中MSS通过Mc接口（H.248）向MGW发送包含特定参考点值的终结点保留消息以指示接口类型的目的完全不同。对比文件未公开使用H.248协议发送目标专利所定义的“终结点保留消息”。 |
| 技术特征Q：包括：接收终结点保留消息，所述终结点保留消息包括具有对应于基于因特网协议的用户平面接口的参考点值的分组<br><br>**结论：未公开** | 对比文件无相关描述。 | 与特征C、D、E的分析一致，对比文件未公开任何包含参考点值的分组被包含在终结点保留消息中并由网关接收的特征。 |
| 技术特征R：根据在包含在所述终结点保留消息中的所述分组中所指示的所述参考点值来确定基于因特网协议的接口的用户平面接口类型，其中在所述用户平面接口类型中不使用Nb用户平面成帧协议<br><br>**结论：未公开** | 对比文件无相关描述。 | 基于以上分析，对比文件未公开任何形式的、通过分组中的参考点值来确定接口类型的机制。 |
| 技术特征S：依照基于因特网协议的用户平面接口类型来执行处理。<br><br>**隐含公开** | 对比文件[0015]段提到：“...significant advantages and benefits can be obtained by providing direct connectivity from a TDD-CDMA radio network to the Internet.” 整个发明都在阐述如何通过RAN IP网关处理互联网连接的用户数据。[0074]段描述了基于接口类型的切换处理：“...handover is implemented via the RAN IP gateway utilizing IP packet service...” | 对比文件明确描述了网络设备（如RAN IP网关、RNC）会根据通信路径（是经由核心网还是直接经由互联网）来处理用户数据。例如，当UE在RLAN内时，数据可能不经过核心网；当UE在RLAN外时，数据通过RAN IP网关的IP连接处理。这种“根据通信路径（接口类型）执行不同处理”的思想与特征S相符。尽管对比文件没有目标专利中定义的精细接口类型（A, Nb, Mb），但其确实根据网络架构所确定的接口类型（如Iu-PS，或直接IP连接）来执行相应的数据处理。因此，可以认为该特征被隐含公开。 |
| 技术特征T：包括：使用H.248协议来接收所述终结点保留消息。<br><br>**结论：未公开** | 对比文件[0081]段提到Megaco (H.248)。 | 理由与技术特征P相同。对比文件虽然使用了H.248/Megaco，但未公开使用该协议来接收目标专利定义的“终结点保留消息”。 |
| 技术特征U：包括：依照所述基于因特网协议的用户平面协议类型来保留资源。<br><br>**隐含公开** | 对比文件[0071]段描述了基于IP的Iub和Iu-PS接口。为了在这些接口上传输数据，网络节点必须分配和保留相应的资源，如IP地址、端口、带宽等。 | 在基于IP的通信中，要建立承载，网关（如MGW或RAN IP Gateway）必然需要保留资源（如IP端口、RTP端点等）。对比文件描述了RLAN组件间使用IP进行通信，例如RNC与RAN IP Gateway之间的Iu-PS接口。为了实现数据传输，相关网元必须为该会话保留必要的IP和网络资源。虽然对比文件没有明确写出“保留资源”这一步骤，但这是实现IP通信的内在和必要环节。 |
| 技术特征V：包括：依照所述基于因特网协议的用户平面协议类型来提供特定服务。<br><br>**隐含公开** | 对比文件[0083]-[0085]段描述了根据是否通过IP连接传输语音，提供不同的语音编码转换服务（如AMR与G.729之间的转换）。[0014]段也指出A接口和Mb/Nb接口需要不同的功能，但该段是背景技术。 | 特征V要求“提供特定服务”。对比文件明确描述了根据接口类型（或连接的终端类型）提供不同的服务，特别是关于语音编码转换（codec conversion）。例如，如果UE和ISP的语音网关使用不同的编码（AMR vs G.729），RAN IP网关或RNC会提供转换服务。这明确体现了“依照接口类型提供特定服务”的思想。虽然目标专利的“特定服务”是AEC、DTMF等，而对比文件是语音编码转换，但“根据接口特性提供不同处理”这一上位概念是相通的。 |
| 技术特征W：包括：用于确定用户平面接口的类型的部件，呼叫将经由该用户平面接口被处理，其中所确定的类型的用户平面接口是基于因特网协议的接口并且其中不使用Nb用户平面成帧协议<br><br>**结论：未公开** | 对比文件描述了RNC和RAN IP Gateway等部件，但其功能是在架构层面处理数据路由，而非动态确定并指示细粒度的用户平面接口类型。 | 该特征是基于方法特征A和B的装置特征。由于对比文件未公开方法特征A和B（确定且不使用NbUP），因此也未公开实现该功能的相应部件。 |
| 技术特征X：用于在具有参考点值的分组中指示基于因特网协议的用户平面接口类型的部件，其中所述参考点值对应于所述基于因特网协议的用户平面接口类型，所述分组被包含在终结点保留消息中<br><br>**结论：未公开** | 对比文件无相关描述。 | 该特征是基于方法特征C、D、E的装置特征。由于对比文件未公开这些方法特征，因此也未公开实现该功能的相应部件。 |
| 技术特征Y：用于发送包括所述分组的所述终结点保留消息的部件。<br><br>**结论：未公开** | 对比文件无相关描述。 | 该特征是基于方法特征F的装置特征。由于对比文件未公开该方法特征，因此也未公开实现该功能的相应部件。 |
| 技术特征Z：其中，所述控制平面信令消息包括呼叫建立请求消息、协商发起消息和协商响应消息中的至少一个。<br><br>**结论：未公开** | 对比文件无相关描述。 | 理由与技术特征I相同。对比文件未公开这些特定的控制平面信令消息类型用于接口类型的判定。 |
**总结论**：经过严谨的比对分析，该对比文件未直接或隐含公开目标专利权利要求的任何一项技术特征（A至Z）。该对比文件主要涉及一种无线局域网（RLAN）的架构，其核心创新在于通过RAN IP网关提供直接的互联网连接，以优化网络架构和移动性管理。而目标专利的核心在于解决MGW无法区分不同类型IP接口（A、Nb、Mb）的问题，其技术手段是在控制装置（MSS）和网关（MGW）之间通过H.248协议的IPUP分组传递接口参考点值，从而实现接口的分离和差异化处理。两者的技术问题、实现手段和技术效果均不相同。因此，对比文件无法破坏目标专利的新颖性和创造性。
<<<>>>
<<<g>>>
<<<j>>>
<<<s>>>
<<<u>>>
<<<v>>>