对比文件名称：2004-10-14_US2004203652A_发明申请_US20040203652A1 METHOD AND DEVICE FOR DTMF WIRELESS HANDSET BASED TEXT MESSAGING
目标专利名称：使用带内信号的应用通知和服务选择CN103931269B
模型名称：DeepSeek-R1
| 技术特征描述及公开性判断结果 | 对比文件原文引用 | 公开性论述 |
| **A**：所述方法包括：确定所述第一站点能够在语音呼叫期间使用带内信令与所述第二站点交换控制信号，《直接公开》 | [0023] “...during a conversation between two users, the first user simply holds down the “0” key for a predetermined time until the second user responds by pushing “0”, and establishing the text chat connection.” <br> [0030] “A voice connection is established between the two mobile phones 12, 14, allowing users to communicate verbally;” | 对比文件公开了在两个移动电话（站点）之间建立语音连接（语音呼叫）后，用户可以通过长按“0”键发送“0DA”信号来请求建立文本聊天连接，另一方通过按“0”键发送“0DB”信号进行确认。这个过程是在已建立的语音呼叫期间，使用DTMF音调（一种带内信号）来交换连接控制信号。因此，对比文件直接公开了在语音呼叫期间使用带内信令交换控制信号以确定彼此能力的技术特征。 |
| **B**：其中确定所述第一站点能够使用带内信令与所述第二站点交换控制信号包括在所述第一站点处通过向语音包施加水印来确定所述第二站点能够使用带内信令与所述第一站点交换控制信号，《未被公开》 | 对比文件未公开任何关于“水印”的技术内容。对比文件使用DTMF音调作为带内信号。 | 目标专利中，“施加水印”是一种特定的带内信令实施方式，水印是嵌入到语音包中不易被传统解码器察觉但可被兼容站点提取并解释的信号。对比文件公开的是使用明显的、可被传统电话接收和播放的DTMF双音多频音调序列作为信号。两者虽然都是带内信号，但具体的技术手段（水印 vs. DTMF音调）不同，本领域技术人员不能毫无疑义地从对比文件得出“施加水印”这一具体技术方案。因此，该技术特征未被对比文件公开。 |
| **C**：其中如果所述第二站点能够使用带内信令，则所述水印被所述第二站点解释为带内信号，《未被公开》 | 对比文件未公开任何关于“水印”的技术内容。 | 由于技术特征B（施加水印）未被公开，作为其后续解释的技术特征C自然也未被公开。对比文件中，能够使用带内信令的站点是将接收到的DTMF音调序列解释为字符或控制命令，而非“水印”。 |
| **D**：其中所述第一站点是移动站点，《直接公开》 | [0018] “...mobile phones 12, 14...” <br> [0029] “Step 102: A voice connection is established between the two mobile phones 12, 14...” | 对比文件全文均以移动电话（mobile phones）作为通信装置进行描述。因此，第一站点是移动站点这一特征被对比文件直接公开。 |
| **E**：使用带内信道在所述第一站点与所述第二站点之间交换控制信号，其中所述控制信号包括控制信息和数据，且其中所述数据包括来自所述第一站点或所述第二站点的至少一个传感器的数据，《部分直接公开，部分未被公开》 | [0023] “To request a text chat connection, a tone series “0DA” is used; to acknowledge a connection request, a tone series “0DB” is used... other control tones used include the “A” tone for moving a text-entering cursor... the “B” tone for moving the cursor right, the “C” tone for deleting the previously entered character...” <br> [0025] “...characters input through the keypad 32...” | 对比文件明确公开了使用DTMF音调序列（通过语音信道，即带内信道）在第一与第二站点之间交换控制信号（如请求连接“0DA”、确认连接“0DB”、光标移动“A”、“B”、删除“C”、“D”等）和数据（如通过键盘输入的文本字符“HELLO”）。因此，“使用带内信道交换控制信号，控制信号包括控制信息和数据”被直接公开。然而，对比文件中的数据仅限于用户通过键盘手动输入的文本字符，并未提及任何来自“传感器”（如近程、定向、心率传感器）的数据。因此，“数据包括来自至少一个传感器的数据”这一限定未被公开。 |
| **F**：使用所述控制信号经由所述带内信道在所述第一站点和所述第二站点之间交换装置信息，其中所述装置信息对所述基础设施透明。《隐含公开》 | [0022] “...the standard ASCII character set, an extended ASCII character set, and a set of controls can be represented by a series of DTMF tones.” <br> [0005] “These systems require a separate digital data channel and base station cooperation in order to function...” | 目标专利中“装置信息”是广义的，可包括设备标识、能力等。对比文件公开了使用DTMF音调序列在语音信道上编码并传输ASCII字符集和一套控制指令。本领域技术人员可以理解，通过这种编码方式，理论上可以传输任何能够被编码为字符序列的信息，包括装置信息（例如将制造商ID、型号等编码为特定字符串通过DTMF发送）。同时，对比文件背景技术指出传统短信服务需要基站协作和独立数据信道，而本发明在语音信道上进行，基站仅传递DTMF音调而不理解其文本含义（见[0005]），这隐含了所交换的信息（无论是文本还是编码后的装置信息）对网络基础设施（基站）是“透明”的（即基础设施不解析其内容）。因此，本领域技术人员有可能从对比文件公开的内容中推理出使用所述带内信道交换对基础设施透明的装置信息。 |
| **G**：其中所述至少一个传感器包括近程传感器、定向传感器和心率监视器中的一者。《未被公开》 | 对比文件未提及任何传感器。 | 对比文件完全没有公开任何关于传感器的内容，更未具体公开近程传感器、定向传感器或心率监视器。本领域技术人员无法从对比文件中推理出此技术特征。 |
| **H**：其中在所述第一站点处确定所述第二站点是否能够使用带内信令与所述第一站点交换控制信号进一步包括使用带内信令发送探测信号。《直接公开》 | [0023] “To request a text chat connection, a tone series “0DA” is used...” <br> [0030] “Step 104: The DTMF decoders 40 of the mobile phones 12, 14 continually listen for the text chat request DTMF signal of “0DA”.” | 对比文件公开了在已建立语音呼叫后，一方通过发送特定的DTMF音调序列“0DA”来请求文本聊天连接。这个“0DA”信号的作用就是探测对方是否具备接收并响应此DTMF文本聊天协议的能力，其本质就是一种探测信号。因此，该技术特征被直接公开。 |
| **I**：其中在所述第一站点处确定所述第二站点是否能够使用带内信令与所述第一站点交换控制信号进一步包括将带内探测信号发射到所述第二站点，以及从所述第二站点接收带内确认信号。《直接公开》 | [0023] “To request a text chat connection, a tone series “0DA” is used; to acknowledge a connection request, a tone series “0DB” is used...” <br> [0031] “Step 106: ... Has the user accepted the request by pressing the “0” key on the keypad 32 to return a DTMF tone of “0DB”...” | 对比文件完整公开了探测与确认的过程：第一站点发射探测信号“0DA”到第二站点；第二站点如果接受，则通过按“0”键返回确认信号“0DB”给第一站点。这完全符合“发射带内探测信号”和“接收带内确认信号”的技术特征。 |
| **J**：其进一步包括周期性发射所述带内探测信号持续有限时间量。《未被公开》 | 对比文件未提及周期性发射探测信号。 | 对比文件仅描述了通过长按“0”键一次来发送“0DA”请求信号（见[0023]），并未公开“周期性”发射探测信号，也未提及发射“持续有限时间量”。本领域技术人员无法从对比文件中得出此技术特征。 |
| **K**：其中所述第一站点能够产生、检测带内信号并对带内信号作出反应，所述带内信号经设计使得(a)所述带内探测信号不作为有效包的任一者由不能够使用带内信令与所述第一站交换信息的站点接收，以及(b)如果所述带内确认信号由所述第一站点接收，那么所述第一站点确定发射路径为转码免除的且所述第二站点能够使用带内信令与所述第一站点交换信息。《未被公开》 | [0023] “...the “0DA” ... tones being generated automatically by the DTMF encoder 34.” <br> [0025] “Any DTMF tone signals in the radio signal are demodulated as such and sent to the DTMF decoder 40.” | 对比文件公开的带内信号（DTMF音调）是标准电话信号。对于（a），不能使用该带内信令的传统站点（即不具备本专利DTMF解码文本功能的普通电话）仍然能够接收DTMF音调，并可能将其作为有效的拨号音或交互音播放出来，这与目标专利中“不作为有效包接收”（即不被传统解码器视为有效语音帧）的设计不同。对于（b），对比文件完全没有提及“转码免除”的概念，也未涉及通过接收确认信号来推断网络路径是否转码免除。因此，该技术特征未被公开。 |
| **L**：其中所述控制信息和数据用于在不对基础设施作出改变的情况下进行以下操作中的至少一者：触发所述站点的一者上的应用程序、在所述站点的一者上产生系统声音、事件或通知，或选择新声码器类型。《部分直接公开，部分未被公开》 | [0023] “Both of these request/acknowledge systems are supported by the microcontroller 44, which triggers corresponding audio or visual signals (such as emitting an audible tone to the user alerting them to an incoming chat request).” <br> [0041] “Each mobile phone 12, 14 then sets up the DTMF encoder 34 and decoder 40, loads the text entry program, and configures the LCD 42...” | 对比文件公开了控制信息（如“0DA”）用于触发接收方站点上的文本输入程序（一种应用程序），并产生可听提示音（一种系统声音或通知）。这实现了“触发应用程序”和“产生系统声音、事件或通知”。并且，整个过程在现有语音信道上进行，不需要对基站等基础设施作出改变。因此，这部分被直接公开。然而，对比文件完全没有提及“选择新声码器类型”这一操作。因此，该部分未被公开。 |
| **M**：其进一步包括在所述第一站点处确定所述第二站点是否能够使用带内信令与所述第一站交换信息。《直接公开》 | [0030]-[0031] “Step 104: ... listen for the text chat request... If the request “0DA” has been received... Step 106: ... Has the user accepted the request... If acknowledgement has been sent...” | 对比文件方法流程图（图3）的步骤104-106明确描述了第一站点（以接收请求方为例）通过监听、接收“0DA”请求信号，并判断是否收到来自第二站点的“0DB”确认信号，来确定是否建立文本聊天连接。这本质上就是在确定第二站点是否能够使用该DTMF带内信令协议进行信息交换。因此，该技术特征被直接公开。 |
| **N**：其进一步包括：基于经由所述带内信道经由所述控制信号的所述带内信令接收的所述所交换的装置信息控制所述第一站点或所述第二站点的设置。《未被公开》 | 对比文件未公开基于交换的装置信息来控制设备设置。 | 对比文件公开了交换控制信号（如连接请求）和数据（文本字符），并基于控制信号触发应用程序或产生提示音。但并未公开交换“装置信息”（如设备能力、ID等），更未公开基于此类交换的装置信息去“控制站点的设置”（如调整音频处理参数、选择模式等）。本领域技术人员无法从对比文件中推理出此技术特征。 |
| **O**：其中所述装置信息包括可行动信息。《隐含公开》 | [0023] “To request a text chat connection, a tone series “0DA” is used; to acknowledge a connection request, a tone series “0DB” is used...” | 目标专利中“可行动信息”指能够触发接收方执行某个动作的信息。对比文件中交换的“0DA”（请求连接）和“0DB”（确认连接）等控制信号，就是典型的可行动信息，接收方在收到后会执行相应的动作（如触发提示音、加载文本程序）。虽然对比文件未明确使用“可行动信息”这一术语，但本领域技术人员能够理解其交换的控制信号具备“可行动”的属性。因此，该技术特征被隐含公开。 |
| **P**：其中所述可行动信息包括用于在不对所述基础设施作出改变的情况下选择新声码器类型的控制信息和数据。《未被公开》 | 对比文件未提及声码器或声码器类型的选择。 | 对比文件完全没有涉及任何与声码器或编解码器类型选择相关的内容。本领域技术人员无法从对比文件中推理出此技术特征。 |
| **Q**：其中所述第二站点为移动站点。《直接公开》 | [0018] “...mobile phones 12, 14...” <br> [0029] “Step 102: A voice connection is established between the two mobile phones 12, 14...” | 同特征D，对比文件明确通信双方都是移动电话（mobile phones）。因此，第二站点是移动站点这一特征被直接公开。 |
| **R**：其中所述第一站点为针对所述语音呼叫的终端站点。《未被公开》 | 对比文件未明确区分语音呼叫的发起站点和终端站点。 | 对比文件描述了两个移动电话之间建立语音连接并进行文本聊天，但并未指明在所述语音呼叫或文本聊天请求中，哪个站点是“发起”方，哪个是“终端”方。从实施例看，任何一方都可以发起文本聊天请求（见[0023] “during a conversation between two users, the first user simply holds down the “0” key...”）。因此，该技术特征未被公开。 |
| **S**：其中所述第一站点为针对所述语音呼叫的发起站点。《未被公开》 | 对比文件未明确区分语音呼叫的发起站点和终端站点。 | 理由同特征R。对比文件未指明第一站点是语音呼叫的发起站点。因此，该技术特征未被公开。 |
| **T**：其进一步包括：确定所述第二站点能够使用带外OOB接口与所述第一站点交换装置信息。《未被公开》 | 对比文件全文仅涉及在语音信道（带内）使用DTMF进行通信，未提及任何带外（OOB）接口。 | 对比文件的技术方案完全基于在现有语音信道上利用DTMF音调传输信息，属于纯带内信令方案，没有涉及任何带外接口。本领域技术人员无法从对比文件中推理出此技术特征。 |
| **U**：设定用于在所述第一站点与所述第二站点之间交换装置信息的OOB管道。《未被公开》 | 对比文件未提及任何带外（OOB）接口或管道。 | 理由同特征T。该技术特征未被公开。 |
| **V**：其中确定所述第二站点是否能够使用所述OOB接口与所述第一站点交换信息包括发送探测信号。《未被公开》 | 对比文件未提及任何带外（OOB）接口或相关的探测。 | 理由同特征T。该技术特征未被公开。 |
| **W**：其进一步包括使用所述OOB接口在所述第一站点与所述第二站点之间交换可行动信息。《未被公开》 | 对比文件未提及任何带外（OOB）接口。 | 理由同特征T。该技术特征未被公开。 |
<<<A>>><<<D>>><<<E>>><<<H>>><<<I>>><<<M>>><<<Q>>><<<f>>><<<o>>>