本次调用的模型名称：gpt-4-turbo
### 特征比对表格
| 技术特征描述及公开性判断结果 | 对比文件原文引用 | 公开性论述 |
| **技术特征A：** 包括：确定用户平面接口的类型，呼叫将经由该用户平面接口被处理<br><br>**《未公开》** | 无直接或隐含公开对应内容 | 对比文件涉及利用SIP协议传输空间位置信息(SLO)以提供呈现（Presence）和即时消息（Instant Messaging）服务。其核心是确定用户的空间地理位置，而非通信网络中的“用户平面接口类型”。对比文件[0009]-[0011]描述了发明目的是传输空间位置信息、实现即时消息和呈现。对比文件[0052]提到“Presence as Spatial Location Applied to SIP”，均未涉及确定呼叫将经由的“用户平面接口”的类型（如A、Nb、Mb等参考点类型）。该技术特征的目标专利目的是区分不同IP接口（如A、Nb、Mb）以提供差异化服务，对比文件的技术方案完全不同，本领域技术人员无法从其内容毫无疑义地或通过推理得出该特征。 |
| **技术特征B：** 其中所确定的类型的用户平面接口是基于因特网协议的接口并且其中不使用Nb用户平面成帧协议<br><br>**《未公开》** | 无直接或隐含公开对应内容 | 对比文件虽然广泛涉及IP网络和应用层控制协议(SIP)，但完全没有提及“Nb用户平面成帧协议(NbUP)”，也未对用户平面接口做出“不使用NbUP成帧协议”的限定。对比文件关注的是应用层的信令和位置信息负载，而非用户平面传输的具体协议或成帧方式。目标专利[0070]-[0071]明确IPUP分组用于指示“其中不使用NbUP成帧协议的IP接口”，这在对比文件中完全未被公开或暗示。 |
| **技术特征C：** 在具有参考点值的分组中指示基于因特网协议的用户平面接口类型<br><br>**《未公开》** | 无直接或隐含公开对应内容 | 对比文件未公开任何“具有参考点值的分组”用于指示用户平面接口类型。对比文件中SIP协议的消息格式虽有多种头部和负载（如[0079]-[0082]所述），但其负载用于携带“空间位置信息(SLO)”（如[0087]-[0089]所述），而非用于指示接口类型的“参考点值”。目标专利的“参考点值”（如“Mb”、“Nb”、“A”）是对应特定接口类型的枚举值，对比文件没有类似概念。 |
| **技术特征D：** 其中所述参考点值对应于所述基于因特网协议的用户平面接口类型<br><br>**《未公开》** | 无直接或隐含公开对应内容 | 对比文件不存在“参考点值”与“用户平面接口类型”的对应关系。对比文件中的SIP消息携带的是用户位置信息、订阅状态等，其“Content-Type”等字段指示的是负载的格式（如[0116]“Content-Type: application/SLO”），而非用户平面接口的类型。因此，本特征未被公开。 |
| **技术特征E：** 所述分组被包含在终结点保留消息中<br><br>**《未公开》** | 无直接或隐含公开对应内容 | 对比文件未涉及“终结点保留消息”这一概念。对比文件主要使用SIP协议（REGISTER, INVITE, SUBSCRIBE, NOTIFY等）进行会话控制、注册和通知，未提及H.248协议或任何用于MGW中“终结点保留”的消息。目标专利[0100]明确分组（IPUP）是H.248分组，包含在终结点保留消息中发送，对比文件没有此项内容。 |
| **技术特征F：** 发送包括所述分组的所述终结点保留消息<br><br>**《未公开》** | 无直接或隐含公开对应内容 | 对比文件未公开发送包含特定分组的“终结点保留消息”。对比文件发送的是SIP请求或响应（如[0065]“providing an invitation message”、[0126]描述SIP REGISTER过程），消息内容是用于建立会话、注册用户或通知事件，而不是用于MGW保留IP接口终结点的消息。 |
| **技术特征G：** 包括：接收与所述呼叫相关的控制平面信令消息<br><br>**《直接公开》** | [0004] “The SIP is from the SIP WG ... It is an application layer control (signaling) protocol for creating, modifying and terminating sessions...”<br><br>[0065] “...an inviting user 22 provides an invitation message on a signal line 24 to the first central server 6...” | 对比文件明确将SIP定义为应用层控制（信令）协议。在[0065]描述的体系中，中央服务器（类比于目标专利的控制装置）接收来自用户的邀请消息（INVITE），该消息属于与呼叫相关的控制平面信令。因此，本领域技术人员可以毫无疑义地确定对比文件公开了接收控制平面信令消息这一技术特征。 |
| **技术特征H：** 根据所述控制平面信令消息来确定所述基于因特网协议的用户平面接口类型<br><br>**《未公开》** | 无直接或隐含公开对应内容 | 对比文件虽然接收控制平面信令（如SIP INVITE），但其目的是根据信令中的信息（如SDP）建立多媒体会话，或者根据SIP REGISTER中的SLO负载更新用户位置信息，以提供呈现或即时消息服务。对比文件没有任何内容表明根据接收到的控制平面信令来确定“用户平面接口的类型”（如A、Nb、Mb）。该确定动作是目标专利的核心发明点，对比文件未公开。 |
| **技术特征I：** 其中，所述控制平面信令消息包括呼叫建立请求消息、协商发起消息和协商响应消息中的至少一个。<br><br>**《隐含公开》** | [0080] “...the start line indicates if it is a Request (INVITE, ACK, OPTIONS, BYE, CANCEL, REGISTER, etc.) or a Response...”<br><br>[0065] “...an inviting user 22 provides an invitation message...” | 对比文件公开了SIP协议，其核心消息类型包括请求（如INVITE）和响应（如200 OK）。其中，INVITE消息是一种典型的呼叫建立请求消息，也可视为协商发起消息。SIP的响应消息（如200 OK）可视为对INVITE的协商响应消息。虽然对比文件主要不是在“确定用户平面接口类型”的上下文中使用它们，但本领域技术人员从对比文件对SIP协议的详细描述（[0065]-[0082]）中，可以合理推断出控制平面信令消息包含这些类型的消息。因此，该技术特征被隐含公开。 |
| **技术特征J：** 包括：接收呼叫建立请求消息<br><br>**《直接公开》** | [0065] “...an inviting user 22 provides an invitation message on a signal line 24 to the first central server 6...” | 对比文件[0065]明确描述了中央服务器6接收来自用户22的邀请消息（invitation message）。在SIP协议中，INVITE消息是核心的呼叫建立请求消息。因此，本领域技术人员可以直接地、毫无疑义地确定对比文件公开了接收呼叫建立请求消息这一特征。 |
| **技术特征K：** 在对所述呼叫建立请求消息进行反应的将被发送的协商发起消息中，把装置指示为所述协商发起消息的发送方，其中所述协商发起消息将通过所述装置被发送<br><br>**《隐含公开》** | [0081] “The message header is composed by multiple headers indicating, the Origin (“From:”), Destination (“To:”)...” | 对比文件[0081]详细描述了SIP消息头的组成，明确包含“Origin (From:)”字段，用于指示消息的发送方。在SIP协议中，当服务器（如MSC服务器）在收到INVITE并需要发起协商（如SDP提供/应答）时，其发送的INVITE或后续请求消息中，必然会在“From:”头域中将自己的装置标识为发送方。虽然对比文件未在完全相同的技术场景下描述，但本领域技术人员根据对比文件对SIP协议的全面讲解，能够合理、逻辑地推断出该操作的存在。 |
| **技术特征L：** 发送所述协商发起消息<br><br>**《直接公开》** | [0065] “...an inviting user 22 provides an invitation message on a signal line 24 to the first central server 6...” | 对比文件[0065]明确描述了“providing an invitation message”，即发送邀请消息。在SIP会话建立流程中，邀请消息本身就是一种协商发起消息。因此，本领域技术人员可以毫无疑义地确定对比文件公开了发送协商发起消息这一特征。 |
| **技术特征M：** 包括：接收协商发起消息<br><br>**《隐含公开》** | [0065] “...an inviting user 22 provides an invitation message on a signal line 24 to the first central server 6...”<br><br>[0066] “...the first central server 6 would respond to the invitation message on the line 24 by communicating with the second central server 16...” | 对比文件描述了通信网元之间交互SIP消息。在[0065]和[0066]中，虽然有发送邀请消息，但在任何SIP会话中，必然存在接收方。对比文件描述的系统中，中央服务器或最终用户必然需要接收来自其他方的协商发起消息才能进行后续处理。虽然对比文件未明确写出“接收”二字，但根据SIP协议的交互模型和对比文件描述的流程（如[0066]中服务器对邀请消息做出响应），本领域技术人员可以合理推断出接收协商发起消息是隐含且必要的步骤。 |
| **技术特征N：** 在对所述协商发起消息进行反应的将被发送的协商响应消息中，把装置指示为所述协商响应消息的发送方，其中所述协商响应消息将通过所述装置被发送<br><br>**《隐含公开》** | [0081] “The message header is composed by multiple headers indicating, the Origin (“From:”), Destination (“To:”)...” | 与特征K类似，SIP响应消息（如200 OK）同样包含“From:”头域，用于标识发送响应的源端。根据对比文件[0081]对SIP消息头的描述，当装置（如MSC服务器）接收到协商发起消息（如INVITE）并需要发送响应消息进行应答时，其必然会在响应消息的“From:”头域中将自己的装置标识为发送方。本领域技术人员基于对比文件对SIP协议结构的公开，可以逻辑推断出此特征。 |
| **技术特征O：** 发送所述协商响应消息<br><br>**《隐含公开》** | [0080] “...the start line indicates if it is a Request (INVITE, ACK, OPTIONS, BYE, CANCEL, REGISTER, etc.) or a Response (100 Informational, 200 Success, 300 Redirection...)...” | 对比文件在[0080]中明确指出SIP消息包括请求和响应。根据SIP协议的基本规则，收到请求（如INVITE）后必须发送响应（如200 OK）。对比文件[0065]描述了发送邀请消息，那么根据SIP协议的标准流程和对比文件对SIP消息类型的定义，本领域技术人员可以合理推断出，被邀请方或处理服务器需要发送协商响应消息（如200 OK）来完成会话建立流程。 |
| **技术特征P：** 包括：使用H.248协议来发送所述终结点保留消息。<br><br>**《未公开》** | 无直接或隐含公开对应内容 | 对比文件全文未提及H.248协议（也称为Megaco或媒体网关控制协议）。对比文件的核心协议是应用层控制协议SIP，用于会话控制、呈现和即时消息。尽管对比文件提到了MGW（[0150]等），但从未描述MSC通过H.248协议与MGW交互来发送“终结点保留消息”。该特征完全未被公开。 |
| **技术特征Q：** 包括：接收终结点保留消息，所述终结点保留消息包括具有对应于基于因特网协议的用户平面接口的参考点值的分组<br><br>**《未公开》** | 无直接或隐含公开对应内容 | 对比文件未涉及“终结点保留消息”及其包含的具有“参考点值”的分组。对比文件中的设备（如MGW、SIP服务器）接收的是SIP消息（INVITE, REGISTER等），消息内容是关于会话控制、位置更新或通知的，而不是用于保留MGW内部终结点的H.248消息。目标专利[0102]描述的“IPUP分组”及其携带的“参考点值”在对比文件中完全不存在。 |
| **技术特征R：** 根据在包含在所述终结点保留消息中的所述分组中所指示的所述参考点值来确定基于因特网协议的接口的用户平面接口类型，其中在所述用户平面接口类型中不使用Nb用户平面成帧协议<br><br>**《未公开》** | 无直接或隐含公开对应内容 | 对比文件不存在“终结点保留消息”、“分组”和“参考点值”这些概念，更不可能存在根据这些信息来确定不使用NbUP的接口类型的步骤。对比文件中的MGW或类似设备处理的是SIP信令和媒体流，其行为不依赖于目标专利所定义的这种接口类型指示机制。 |
| **技术特征S：** 依照基于因特网协议的用户平面接口类型来执行处理。<br><br>**《未公开》** | 无直接或隐含公开对应内容 | 对比文件没有公开“依照基于因特网协议的用户平面接口类型来执行处理”。对比文件中的处理（如提供呈现服务、发送即时消息通知）是基于用户的空间位置信息或订阅状态，而非基于用户平面接口类型。目标专利中MGW根据接口类型（A, Nb, Mb）执行不同的资源保留和服务提供（如语音增强、DTMF递送），这种处理方式在对比文件中未被公开或暗示。 |
| **技术特征T：** 包括：使用H.248协议来接收所述终结点保留消息。<br><br>**《未公开》** | 无直接或隐含公开对应内容 | 与特征P同理，对比文件完全没有涉及H.248协议及其消息接收。因此本特征未被公开。 |
| **技术特征U：** 包括：依照所述基于因特网协议的用户平面协议类型来保留资源。<br><br>**《未公开》** | 无直接或隐含公开对应内容 | 对比文件没有揭示“依照用户平面协议类型来保留资源”。对比文件[0165]等提到SIP会话管理和资源，但这里的资源保留是基于QoS或会话需求，而非根据特定的用户平面接口类型（如A, Nb, Mb）来差异化保留。目标专利[0052]等描述了根据参考点类型执行适当的资源保留，这是对比文件所不具备的。 |
| **技术特征V：** 包括：依照所述基于因特网协议的用户平面协议类型来提供特定服务。<br><br>**《未公开》** | 无直接或隐含公开对应内容 | 对比文件没有公开“依照用户平面协议类型提供特定服务”。对比文件提供的服务（如即时消息通知、位置查询）与应用层协议（SIP）和位置信息相关，而非与用户平面接口类型相关。目标专利[0014]-[0019]列举了在不同接口（A, Nb, Mb）中需要提供的特定服务组（如语音增强、DTMF递送），这种按接口类型区分服务的特征在对比文件中完全不存在。 |
| **技术特征W：** 包括：用于确定用户平面接口的类型的部件，呼叫将经由该用户平面接口被处理，其中所确定的类型的用户平面接口是基于因特网协议的接口并且其中不使用Nb用户平面成帧协议<br><br>**《未公开》** | 无直接或隐含公开对应内容 | 该特征为装置特征，对应于方法特征A+B。对比文件未公开任何用于确定用户平面接口类型的部件，也未公开对应的限定条件（不使用NbUP）。对比文件中的服务器部件用于处理位置信息和即时消息，不具备本特征所定义的功能。 |
| **技术特征X：** 用于在具有参考点值的分组中指示基于因特网协议的用户平面接口类型的部件，其中所述参考点值对应于所述基于因特网协议的用户平面接口类型，所述分组被包含在终结点保留消息中<br><br>**《未公开》** | 无直接或隐含公开对应内容 | 该特征对应于方法特征C+D+E。对比文件未公开用于生成或指示“参考点值”的部件，未公开包含此类分组的“终结点保留消息”。对比文件中的服务器部件使用SIP协议，不涉及H.248 IPUP分组和终结点保留机制。 |
| **技术特征Y：** 用于发送包括所述分组的所述终结点保留消息的部件。<br><br>**《未公开》** | 无直接或隐含公开对应内容 | 该特征对应于方法特征F+P。对比文件未公开发送“终结点保留消息”的部件，尤其是使用H.248协议发送。对比文件中的发送部件（如SIP用户代理或服务器）发送的是SIP消息，而非H.248终结点保留消息。 |
| **技术特征Z：** 其中，所述控制平面信令消息包括呼叫建立请求消息、协商发起消息和协商响应消息中的至少一个。<br><br>**《隐含公开》** | [0080] “...the start line indicates if it is a Request (INVITE, ACK, OPTIONS, BYE, CANCEL, REGISTER, etc.) or a Response (100 Informational, 200 Success, 300 Redirection...)...” | 与特征I类似，对比文件对SIP协议消息类型的详尽描述（[0080]）明确公开了请求（包含INVITE等呼叫建立请求）和响应（包含成功响应等协商响应）消息。本领域技术人员可以合理推断出这些消息类型即构成了控制平面信令消息。虽然对比文件未在目标专利的特定场景下使用，但消息类型本身是公开的。 |
### 公开性代码
<<<G>>><<<J>>><<<L>>><<<i>>><<<k>>><<<m>>><<<n>>><<<o>>><<<z>>>