对比文件名称：2008-07-24_US2008176586A_发明申请_US20080176586A1 System and method for effectuating remote control of a network node by a user equipment (UE) device
目标专利名称：使用带内信号的应用通知和服务选择CN103931269B
本次调用模型名称：DeepSeek-R1
## 特征比对表格
| 技术特征描述以及公开性判断结果 | 对比文件原文引用 | 公开性论述 |
| **技术特征A**：所述方法包括：确定所述第一站点能够在语音呼叫期间使用带内信令与所述第二站点交换控制信号，<br>**《隐含公开》** | [0004]：“…conventional choice has been the use of Dual Tone Multi-Frequency (DTMF) signaling, which uses command signals in either in-band (audible to the user) or out-of-band (inaudible to the user) mode.”（…常规选择是使用双音多频（DTMF）信令，其使用带内（用户可听见）或带外（用户听不见）模式的命令信号。） | 对比文件公开了在通信中可以使用“带内（in-band）”信令来传递命令信号。虽然对比文件主要描述的是UE设备与网络节点（如企业服务器）之间的控制，但其明确指出了DTMF信令可以在“带内”模式使用，这构成了在通信期间使用带内信令交换控制信号的技术手段。本领域技术人员可以理解，DTMF作为一种带内信令技术，可以在语音呼叫期间嵌入到语音信道中传输控制信息。因此，对比文件隐含公开了“在语音呼叫期间使用带内信令交换控制信号”这一技术特征。 |
| **技术特征B**：其中确定所述第一站点能够使用带内信令与所述第二站点交换控制信号包括在所述第一站点处通过向语音包施加水印来确定所述第二站点能够使用带内信令与所述第一站点交换控制信号，<br>**《未公开》** | 对比文件未提及“水印（watermark）”技术。 | 对比文件虽然提到了带内信令（如DTMF），但DTMF是通过特定的音调组合来传递信息，与“向语音包施加水印”是两种不同的技术手段。水印通常指将信息隐蔽地嵌入到载体信号（如语音）中，而对比文件公开的DTMF是明确可闻或特定的信令音。本领域技术人员无法从对比文件公开的DTMF信令毫无疑义地得出或合理推断出“通过向语音包施加水印来确定对方能力”的技术方案。因此，该技术特征未被对比文件公开。 |
| **技术特征C**：其中如果所述第二站点能够使用带内信令，则所述水印被所述第二站点解释为带内信号，<br>**《未公开》** | 对比文件未提及“水印（watermark）”技术。 | 由于对比文件根本没有公开“水印”技术，因此也就没有公开水印被解释为带内信号的相关内容。该技术特征未被对比文件公开。 |
| **技术特征D**：其中所述第一站点是移动站点<br>**《直接公开》** | [0015]：“a UE device may be a cellular phone or mobile station...”（UE设备可以是蜂窝电话或移动站…） | 对比文件明确将用户设备（UE device）描述为蜂窝电话或移动站（mobile station），即移动站点。因此，技术特征D被对比文件直接公开。 |
| **技术特征E**：使用带内信道在所述第一站点与所述第二站点之间交换控制信号，其中所述控制信号包括控制信息和数据，且其中所述数据包括来自所述第一站点或所述第二站点的至少一个传感器的数据<br>**《隐含公开》** | [0004]：“…DTMF signaling, which uses command signals in either in-band… mode.”（…DTMF信令，其使用带内…模式的命令信号。）<br>[0034]：“e) Code of the service one wants to communicate with f) Data for the service”（e) 想要与之通信的服务的代码 f) 服务的数据） | 对比文件公开了使用带内（in-band）模式的DTMF信令来发送命令信号（即控制信息）。其中提及的“命令信号”以及消息中可以包含的“服务数据”（Data for the service）共同构成了“控制信号包括控制信息和数据”。然而，对比文件未明确提及数据包括来自“传感器”的数据。虽然对比文件的消息内容可能包含位置信息（如GPS），但这并不等同于权利要求中明确限定的“来自至少一个传感器的数据”。本领域技术人员可能从发送各种数据（如位置）推断出可能涉及传感器，但该推断并非必然。考虑到隐含公开判断标准宽松，可以认为对比文件部分公开了该特征（使用带内信道交换控制信息和数据），但“传感器数据”这一具体限定未被公开。综合判断，该技术特征被部分隐含公开。 |
| **技术特征F**：使用所述控制信号经由所述带内信道在所述第一站点和所述第二站点之间交换装置信息，其中所述装置信息对所述基础设施透明。<br>**《隐含公开》** | [0034]：“c) Instance identifier (IMEI, ESN, MAC address, PIN) … Such an ID could be queried in a database to determine if the service can be invoked…”（c) 实例标识符（IMEI、ESN、MAC地址、PIN）… 可以查询数据库中的此类ID以确定是否可以调用服务…） | 对比文件公开了在消息中可以包含“实例标识符（Instance identifier）”，如IMEI、ESN等，这些信息属于装置信息。该消息是通过带外信道（如SMS/USSD）发送的，但对比文件也明确指出DTMF信令可以在“带内”模式使用（[0004]）。虽然实施例主要描述带外，但带内模式作为一种可选方式已被公开。本领域技术人员可以合理推断，既然可以使用带内信令发送命令，那么也可以使用它来交换装置信息。此外，这种端到端的信令交换（特别是使用DTMF或类似机制）很可能对核心网络基础设施是“透明”的，即基础设施不解析或处理其中的具体应用信息。因此，该技术特征被对比文件隐含公开。 |
| **技术特征G**：其中所述至少一个传感器包括近程传感器、定向传感器和心率监视器中的一者。<br>**《未公开》** | 对比文件未具体提及“近程传感器（proximity sensor）”、“定向传感器（orientation sensor）”或“心率监视器（heart rate monitor）”。 | 对比文件列举的消息内容（如位置、设备ID）并未具体指向权利要求中明确列举的这三种特定传感器类型。本领域技术人员无法从对比文件公开的内容中必然地、合理地推断出交换的数据来自这三种传感器之一。因此，该技术特征未被对比文件公开。 |
| **技术特征H**：其中在所述第一站点处确定所述第二站点是否能够使用带内信令与所述第一站点交换控制信号进一步包括使用带内信令发送探测信号。<br>**《未公开》** | 对比文件未提及“探测信号（probe signal）”或用于探测对方能力的握手过程。 | 对比文件描述了使用DTMF信令发送服务请求，这是一种已知目的的命令传输，而非用于探测对方是否具备某种兼容性能力的“探测信号”。本领域技术人员无法从对比文件中得出使用带内信令发送探测信号以确定对方能力的技术启示。因此，该技术特征未被对比文件公开。 |
| **技术特征I**：其中在所述第一站点处确定所述第二站点是否能够使用带内信令与所述第一站点交换控制信号进一步包括将带内探测信号发射到所述第二站点，以及从所述第二站点接收带内确认信号。<br>**《未公开》** | 对比文件未提及“探测信号（probe signal）”及相应的“确认信号（acknowledgment signal）”握手流程。 | 对比文件描述的消息流（图2、[0037]）涉及请求和确认，但这是针对特定服务请求的确认，而非针对对方设备是否具备带内信令能力的“探测-确认”握手过程。因此，该技术特征未被对比文件公开。 |
| **技术特征J**：其进一步包括周期性发射所述带内探测信号持续有限时间量。<br>**《未公开》** | 对比文件未提及周期性发射探测信号。 | 对比文件未涉及任何关于周期性发射信号的内容，更未提及针对探测信号的有限时间发射。因此，该技术特征未被对比文件公开。 |
| **技术特征K**：其中所述第一站点能够产生、检测带内信号并对带内信号作出反应，所述带内信号经设计使得(a)所述带内探测信号不作为有效包的任一者由不能够使用带内信令与所述第一站交换信息的站点接收，以及(b)如果所述带内确认信号由所述第一站点接收，那么所述第一站点确定发射路径为转码免除的且所述第二站点能够使用带内信令与所述第一站点交换信息。<br>**《未公开》** | 对比文件未提及带内信号的特殊设计以使其对传统设备无效，也未提及通过接收确认信号来推断发射路径是“转码免除的（transcoder-free）”。 | 对比文件完全没有涉及“转码免除”的概念，也没有描述带内信号需要设计成对传统解码器无效。其所公开的DTMF信令是标准化的、可被传统设备接收和产生（尽管可能不解析其控制含义）的音调。技术特征K中关于信号设计目的和通过确认推断网络路径状态的具体限定，在对比文件中完全没有记载，也无法从中合理推断。因此，该技术特征未被对比文件公开。 |
| **技术特征L**：其中所述控制信息和数据用于在不对基础设施作出改变的情况下进行以下操作中的至少一者：触发所述站点的一者上的应用程序、在所述站点的一者上产生系统声音、事件或通知，或选择新声码器类型。<br>**《隐含公开》** | [0019]：“…a number of telephony service features may be provided that may relate to an on-going CS call such as, e.g., direct inward calling service, call transfer service, customized abbreviated dialing service, voice mail service, follow-me service,…”（…可以提供许多可能与正在进行的CS呼叫相关的电话服务功能，例如，直接内线呼叫服务、呼叫转移服务、定制缩位拨号服务、语音邮件服务、跟我来服务、…）<br>[0037]：“Upon receiving the wrapped service feature message, service logic associated with the enterprise server 122 is executed to act on the message (illustrated as block 206), which performs the requested service feature.”（在接收到封装的服务功能消息后，执行与企业服务器122相关联的服务逻辑以对该消息采取行动（如图块206所示），从而执行所请求的服务功能。） | 对比文件明确公开了通过信令（可以是带内DTMF）远程控制企业服务器执行各种服务功能，例如呼叫转移、语音邮件等。这实质上就是“触发应用程序”或“产生事件或通知”（如呼叫转移事件、语音邮件通知）。这些操作是通过端到端的信令完成的，不需要改变网络基础设施。虽然对比文件未明确提及“选择新声码器类型”，但其公开的“在不对基础设施作出改变的情况下触发远程服务/事件”这一核心思想，与本特征的部分内容（触发应用、产生事件/通知）是相同的。因此，该技术特征被部分隐含公开。 |
| **技术特征M**：其进一步包括在所述第一站点处确定所述第二站点是否能够使用带内信令与所述第一站交换信息。<br>**《隐含公开》** | [0004]：“…conventional choice has been the use of Dual Tone Multi-Frequency (DTMF) signaling, which uses command signals in either in-band (audible to the user) or out-of-band (inaudible to the user) mode.”（…常规选择是使用双音多频（DTMF）信令，其使用带内（用户可听见）或带外（用户听不见）模式的命令信号。）<br>隐含地，使用某种信令模式的前提是双方都支持该模式。 | 对比文件公开了可以使用带内（或带外）信令。本领域技术人员可以理解，在实际通信中，若要成功使用一种特定的信令方式（如带内DTMF）进行信息交换，通信双方需要具备处理该信令的能力。因此，隐含了“确定对方是否能够使用该信令”这一逻辑前提或步骤。虽然对比文件没有像目标专利那样明确描述一个独立的“探测-确认”流程来确定能力，但“使用带内信令交换信息”这一行为本身，就隐含了对对方能力的一种确认（例如，发送命令后收到预期响应，即表明对方有能力处理）。因此，该技术特征被对比文件隐含公开。 |
| **技术特征N**：其进一步包括：基于经由所述带内信道经由所述控制信号的所述带内信令接收的所述所交换的装置信息控制所述第一站点或所述第二站点的设置。<br>**《未公开》** | 对比文件未提及基于交换的装置信息来控制UE设备本身的设置。 | 对比文件描述的是UE设备发送控制信息（命令）给网络节点（企业服务器），以控制服务器执行服务功能。虽然消息中可以包含装置信息（如设备ID），但目的是用于服务器端的决策（如是否允许服务），而不是用于控制通信对端设备（第二站点）或自身（第一站点）的设置（如音频处理设置、编解码器选择等）。因此，该技术特征未被对比文件公开。 |
| **技术特征O**：其中所述装置信息包括可行动信息。<br>**《隐含公开》** | [0034]：列出了可以在消息中发送的信息元素，如服务代码、服务数据等。<br>[0037]：“Upon receiving the wrapped service feature message, service logic … is executed to act on the message … which performs the requested service feature.”（在接收到封装的服务功能消息后，服务逻辑…被执行以对该消息采取行动…从而执行所请求的服务功能。） | 对比文件中UE设备发送给企业服务器的消息包含了“服务代码”和“服务数据”，企业服务器收到后会执行相应的服务功能。这些信息正是用于触发服务器采取行动（act on）的“可行动信息（actionable information）”。因此，该技术特征被对比文件隐含公开。 |
| **技术特征P**：其中所述可行动信息包括用于在不对所述基础设施作出改变的情况下选择新声码器类型的控制信息和数据。<br>**《未公开》** | 对比文件未提及“声码器类型（vocoder type）”或编解码器的选择。 | 对比文件公开的可行动信息是关于企业电话服务功能（如呼叫转移、语音邮件），与语音编解码器（声码器）的选择完全无关。本领域技术人员无法从对比文件中得到任何关于选择新声码器类型的技术启示。因此，该技术特征未被对比文件公开。 |
| **技术特征Q**：其中所述第二站点为移动站点。<br>**《隐含公开》** | [0015]：“For purposes of further generalization, a UE device may be a cellular phone or mobile station…”（为了进一步概括，UE设备可以是蜂窝电话或移动站…）<br>图1中，与UE设备102A通信的端点102B也是一个UE设备。 | 对比文件中的通信环境涉及两个UE设备（如102A和102B）之间的电路交换呼叫。UE设备被定义为移动设备（如蜂窝电话）。因此，作为通信对端的第二站点（对应于102B）也必然是移动站点。该技术特征被对比文件隐含公开。 |
| **技术特征R**：其中所述第一站点为针对所述语音呼叫的终端站点。<br>**《未公开》** | 对比文件未明确区分“发起站点（originating site）”和“终端站点（terminating site）”。 | 对比文件在描述UE设备102A与企业服务器交互时，并未明确102A在与其对端102B的语音呼叫中是处于发起方还是被叫方（终端）的角色。因此，无法确定第一站点是终端站点。该技术特征未被对比文件公开。 |
| **技术特征S**：其中所述第一站点为针对所述语音呼叫的发起站点。<br>**《未公开》** | 对比文件未明确区分“发起站点（originating site）”和“终端站点（terminating site）”。 | 同上，对比文件未明确第一站点（UE设备102A）在语音呼叫中的角色是发起方。因此，该技术特征未被对比文件公开。 |
| **技术特征T**：其进一步包括：确定所述第二站点能够使用带外OOB接口与所述第一站点交换装置信息<br>**《直接公开》** | [0004]：“…conventional choice has been the use of Dual Tone Multi-Frequency (DTMF) signaling, which uses command signals in either in-band (audible to the user) or out-of-band (inaudible to the user) mode.”（…常规选择是使用双音多频（DTMF）信令，其使用带内（用户可听见）或带外（用户听不见）模式的命令信号。）<br>[0010]：“…transmitted to the enterprise server via an out-of-band control channel…”（…通过带外控制信道传输到企业服务器…） | 对比文件明确且直接地公开了使用“带外（out-of-band， OOB）”模式或接口来发送信令（命令信号）。并且，全文核心就是描述通过SMS、USSD等带外控制信道来与企业服务器（作为通信对端的一种表现形式）交换信息。虽然对端是企业服务器而非严格对等的移动站点，但技术特征在于“使用OOB接口交换信息”这一手段。因此，该技术特征被对比文件直接公开。 |
| **技术特征U**：设定用于在所述第一站点与所述第二站点之间交换装置信息的OOB管道。<br>**《隐含公开》** | [0010]：“A message relating to an enterprise service feature is constructed and wrapped in a wrapper, which is then transmitted to the enterprise server via an out-of-band control channel for invoking the requested service feature.”（构建与企业服务功能相关的消息并将其封装在封装器中，然后通过带外控制信道传输到企业服务器以调用所请求的服务功能。）<br>[0016]：描述了SMS、USSD、UUS等作为封装器（wrapper）在带外信道中使用。 | 对比文件详细描述了通过建立特定的带外控制信道（如SMS、USSD）来传输封装的消息。这种建立的、用于传输特定信息的带外信道，可以理解为设定了用于交换信息的“OOB管道”。虽然“管道”一词是目标专利的用语，但其含义与对比文件中的“信道（channel）”或通过特定协议（如SMS）建立的通信路径实质相同。因此，该技术特征被对比文件隐含公开。 |
| **技术特征V**：其中确定所述第二站点是否能够使用所述OOB接口与所述第一站点交换信息包括发送探测信号。<br>**《未公开》** | 对比文件未提及使用“探测信号”来确定OOB接口能力。 | 对比文件描述了直接使用OOB接口（如SMS）发送服务请求，并没有描述一个先于服务请求的、用于探测对方OOB能力的独立过程或信号。因此，该技术特征未被对比文件公开。 |
| **技术特征W**：其进一步包括使用所述OOB接口在所述第一站点与所述第二站点之间交换可行动信息。<br>**《直接公开》** | [0010]：“A message relating to an enterprise service feature is constructed and wrapped in a wrapper, which is then transmitted to the enterprise server via an out-of-band control channel for invoking the requested service feature.”（构建与企业服务功能相关的消息并将其封装在封装器中，然后通过带外控制信道传输到企业服务器以调用所请求的服务功能。）<br>[0034], [0037]: 消息包含服务代码和数据，服务器收到后执行相应动作。 | 对比文件的核心就是教导使用OOB接口（如SMS/USSD信道）在第一站点（UE设备）与第二站点（企业服务器）之间交换可行动信息（即触发服务功能的消息）。这直接公开了技术特征W。 |
<<<D>>><<<T>>><<<a>>><<<e>>><<<f>>><<<l>>><<<m>>><<<o>>><<<q>>><<<u>>><<<w>>>