对比文件名称：2008-02-20_CN101129049A_发明公开_CN101129049A 通信设备、通信方法和程序
目标专利名称：用于改进多个NFC-A设备的识别的方法和装置 CN104106077B
本次调用的模型名称：deepseek
## 特征比对表格
| 技术特征描述以及公开性判断结果 | 对比文件原文引用 | 公开性论述 |
| **技术特征A**：确定第一设备感测响应消息包括多个远程近场通信NFC设备之间的一个或多个冲突。<br>**《未直接公开也非隐含公开》** | 对比文件说明书第[0080]段：“在SDD处理中，当发起方向所述发起方周围的目标方请求NFCID时，可出现以下情况：当多个目标方存在于发起方周围时，从两个或多个目标方同时发送NFCID。在这种情况下，从两个或多个目标方发送的NFCID彼此冲突，发起方不能确认冲突的NFCID。” | 对比文件描述了在SDD（单个装置检测）处理中，当多个目标设备响应轮询请求时，其发送的NFCID可能发生冲突，导致发起方无法确认。这相当于公开了“存在多个远程NFC设备之间的冲突”这一现象。然而，目标专利的特征A强调“确定第一设备感测响应消息包括...一个或多个冲突”，这是一个主动的、具体的判断步骤。对比文件虽然提到了冲突现象，但并未明确描述发起方执行一个“确定”冲突是否存在于一个具体的“设备感测响应消息”（如SENS_RES）中的步骤。其冲突是在描述SDD处理流程中作为一种可能性提及的。因此，对比文件未直接公开特征A。从隐含公开的角度看，本领域技术人员可以理解，当发生所述冲突时，发起方必然会感知或检测到该冲突，这隐含了“确定冲突存在”这一基本动作。但考虑到目标专利将“确定冲突”作为其改进方法的一个明确步骤，且对比文件未聚焦于该确定动作本身，因此认为其公开性不足，既非直接公开也非隐含公开。 |
| **技术特征B**：所述第一设备感测响应消息响应于第一设备感测请求消息。<br>**《未直接公开也非隐含公开》** | 对比文件说明书第[0077]段：“在SDD处理中，发起方请求目标方的NFCID。由发起方通过发送称为轮询请求帧的帧来进行所述请求。当目标方接收到轮询请求帧时，目标方使用随机数来确定（例如）它自己的NFCID并发送NFCID所在的轮询响应帧。” | 对比文件描述了SDD处理中，发起方发送轮询请求帧（可视为一种设备感测请求），目标方响应以轮询响应帧（可视为设备感测响应）。这建立了请求与响应之间的对应关系。然而，目标专利明确限定了“第一设备感测响应消息响应于第一设备感测请求消息”，并特指为“设备感测响应消息”（如SENS_RES）。对比文件中的“轮询响应帧”是SDD处理的一部分，虽然功能类似，但并未明确等同于目标专利所依据的NFC论坛规范中的“设备感测响应消息”(SENS_RES)。因此，不能认定对比文件直接公开了特征B。隐含公开判断：虽然轮询请求和响应的关系是通信协议的基础，但对比文件并未明确将其关联到目标专利所特指的“设备感测请求/响应消息”这一具体协议层消息。因此，认为未被隐含公开。 |
| **技术特征C**：通过对所述第一设备感测响应消息执行冲突消除，来识别所述多个远程NFC设备中的第一远程NFC设备。<br>**《直接公开》** | 对比文件说明书第[0080]段：“即使每个目标方基于随机数确定作为发送轮询响应帧的时刻的时隙，由多个目标方发送轮询响应帧的时隙也会彼此冲突。这会引起轮询响应帧的冲突...发起方无法正常接收发送冲突的目标方#1和#3的轮询响应帧。因此，发起方再次发送轮询请求帧。” <br>第[0081]段：“从执行通信的对象中临时排除（置于已删除状态）轮询响应帧被正常接收并且NFCID可被确认的目标方#2、#4和#5，从而不会发回作为对轮询请求帧的响应的轮询响应帧。在这种情况下，发回对于由发起方重新发送的轮询请求帧的轮询响应帧的只是目标方#1和#3，它们的NFCID无法通过最初的轮询请求帧的传输被确认。因此，在这种情况下，可确认目标方#1到#5的所有NFCID，同时减少轮询响应帧会彼此冲突的可能性。” | 对比文件明确描述了在SDD处理中，当发生冲突（轮询响应帧冲突）时，发起方通过一种冲突消除过程来识别设备：首先，将已成功识别的设备（如#2, #4, #5）临时排除（置于已删除状态），使其不再响应后续请求。然后，重新发送轮询请求帧，使之前因冲突而未识别的设备（如#1, #3）有机会响应并被识别。这个过程正是“通过对冲突的响应执行操作（排除已识别设备并重新轮询）来识别设备”，即执行冲突消除以识别设备。虽然对比文件使用的术语是“轮询请求/响应帧”和“置于已删除状态”，而目标专利是“设备感测请求/响应消息”和“冲突消除”，但两者在技术本质上相同，都是NFC冲突避免和识别机制的一部分。本领域技术人员能够毫无疑义地认识到对比文件公开了“通过对冲突的响应消息执行操作来识别设备”这一技术特征。因此，特征C被直接公开。 |
| **技术特征D**：向所识别的第一远程NFC设备发送睡眠请求消息。<br>**《隐含公开》** | 对比文件说明书第[0081]段：“从执行通信的对象中临时排除（置于已删除状态）轮询响应帧被正常接收并且NFCID可被确认的目标方#2、#4和#5，从而不会发回作为对轮询请求帧的响应的轮询响应帧。” <br>第[0086]段，图8描述：“当发起方将目标方设置为处于取消选择状态时，命令DSL_REQ被发送。接收到命令DSL_REQ的目标方发送对命令DSL_REQ的响应DSL_RES并进入取消选择状态，随后变得对于除命令WUP_REQ以外的命令不作出响应（变为不发回任何响应）。” | 对比文件公开了在SDD冲突消除过程中，将已识别的设备“临时排除（置于已删除状态）”，使其不再响应后续的轮询请求帧。为了实现这种“排除”或“置于已删除状态”，必然需要向该设备发送一个指令。对比文件在第[0086]段进一步明确，可以通过发送“命令DSL_REQ”将目标方设置为“取消选择状态”，在该状态下设备对除唤醒命令外的命令不响应。虽然对比文件在描述SDD处理时未明确写出发送了“DSL_REQ”，但本领域技术人员根据其描述的“置于已删除状态”的效果，结合对比文件本身已公开的“DSL_REQ”命令可实现该效果，能够合理推断出：在SDD处理中，为了实现将已识别设备临时排除，需要向其发送一个使其进入不响应状态的请求消息（如DSL_REQ）。该消息在目标专利中称为“睡眠请求消息”。因此，特征D被隐含公开。 |
| **技术特征E**：所述睡眠请求消息使所识别的第一远程NFC设备转入睡眠状态。<br>**《隐含公开》** | 对比文件说明书第[0086]段：“接收到命令DSL_REQ的目标方...进入取消选择状态，随后变得对于除命令WUP_REQ以外的命令不作出响应（变为不发回任何响应）。” | 对比文件明确记载了命令DSL_REQ使目标设备“进入取消选择状态”，并且在该状态下设备对大多数命令不作出响应。这种“取消选择状态”在功能上等同于一种“睡眠状态”，即设备暂时退出活动响应序列。虽然术语不同（“取消选择状态” vs “睡眠状态”），但实质都是使设备在一段时间内不响应常规轮询请求。因此，本领域技术人员能够从对比文件公开的“DSL_REQ命令使设备进入取消选择状态”中，毫无疑义地得出“该请求消息使设备转入一种不响应的状态（即睡眠状态）”这一结论。特征E被隐含公开。 |
| **技术特征F**：所述睡眠状态禁止所识别的第一远程NFC设备对第一设备感测请求消息进行响应。<br>**《隐含公开》** | 对比文件说明书第[0081]段：“...临时排除（置于已删除状态）...从而不会发回作为对轮询请求帧的响应的轮询响应帧。” <br>第[0086]段：“...进入取消选择状态，随后变得对于除命令WUP_REQ以外的命令不作出响应...” | 对比文件公开了处于“已删除状态”或“取消选择状态”的设备，不会对“轮询请求帧”（即设备感测请求消息）进行响应（除特定的唤醒命令外）。这直接对应于特征F中“睡眠状态禁止设备对设备感测请求消息进行响应”的技术效果。虽然对比文件未使用“睡眠状态”和“设备感测请求消息”这两个特定词汇，但其描述的状态（取消选择状态）和禁止响应的对象（轮询请求帧）在功能和目的上与目标专利的特征F完全一致。因此，本领域技术人员能够直接且毫无疑义地从对比文件得出该技术特征。特征F被隐含公开。 |
| **技术特征G**：发送第二设备感测请求消息。<br>**《直接公开》** | 对比文件说明书第[0080]段：“发起方无法正常接收发送冲突的目标方#1和#3的轮询响应帧。因此，发起方再次发送轮询请求帧。” | 对比文件明确记载了在发生冲突导致识别失败后，“发起方再次发送轮询请求帧”。这里的“再次发送轮询请求帧”就是在首次请求（第一设备感测请求）之后，发送的第二次请求，即“第二设备感测请求消息”。虽然术语不同（轮询请求帧 vs 设备感测请求消息），但它们在NFC技术检测上下文中作用相同，都是用于探测设备存在的请求命令。因此，特征G被对比文件直接公开。 |
| **技术特征H**：接收包括所述多个远程NFC设备之间的冲突的第二设备感测响应消息。<br>**《隐含公开》** | 对比文件说明书第[0080]段：“...发起方再次发送轮询请求帧。由此请求目标方#1和#3发送它们的NFCID所在的轮询响应帧。” <br>第[0081]段：“...发回对于由发起方重新发送的轮询请求帧的轮询响应帧的只是目标方#1和#3...” | 对比文件描述了在再次发送轮询请求（第二设备感测请求）后，发起方会接收来自剩余未识别设备（如#1和#3）的轮询响应。由于#1和#3之前就是因为冲突而未识别，在它们同时响应新的请求时，其响应仍有可能包含冲突（对比文件未排除这种可能）。本领域技术人员根据对比文件描述的冲突场景和重新轮询的目的，可以合理推断出，在第二次及后续的轮询中，只要存在多个未识别设备，仍然可能接收到包含冲突的响应消息。因此，特征H所描述的“接收包括冲突的第二设备感测响应消息”这一步骤，是对比文件所公开流程中可能且合理发生的情况，故被隐含公开。 |
| **技术特征I**：通过对所述第二设备感测响应消息执行冲突消除，来识别所述多个远程NFC设备中的第二远程NFC设备。<br>**《隐含公开》** | 对比文件说明书第[0081]段：“在这种情况下，发回对于由发起方重新发送的轮询请求帧的轮询响应帧的只是目标方#1和#3，它们的NFCID无法通过最初的轮询请求帧的传输被确认。因此，在这种情况下，可确认目标方#1到#5的所有NFCID...” | 对比文件公开了通过重新发送轮询请求（第二设备感测请求），并接收响应，最终可以确认所有目标设备（包括第二台、第三台等）的NFCID。这个过程本身就是一个迭代的冲突消除过程。虽然对比文件没有将第二次识别单独拆解为“对第二响应消息执行冲突消除以识别第二设备”，但其描述的“确认所有NFCID”的结果必然包含了基于后续响应消息（第二响应消息）识别出后续设备（第二远程NFC设备）的过程。这是该流程的必然组成部分。因此，本领域技术人员能够从对比文件整体公开的迭代识别方法中，推导出特征I的技术方案。特征I被隐含公开。 |
| **技术特征J**：其中，冲突是指来自远程NFC设备的设备感测响应消息中有如下指示：针对单个值，既接收到“0”比特也接收到“1”比特。<br>**《未直接公开也非隐含公开》** | 对比文件说明书第[0080]段：“从两个或多个目标方同时发送NFCID。在这种情况下，从两个或多个目标方发送的NFCID彼此冲突，发起方不能确认冲突的NFCID。” | 对比文件定义了冲突是指多个设备“同时发送”NFCID导致“彼此冲突”，使发起方无法确认。这是一种对冲突现象的描述。目标专利的特征J则给出了冲突在比特层面的具体定义：“针对单个值，既接收到‘0’比特也接收到‘1’比特”。这是一个更具体、更底层的技术定义。对比文件没有提供冲突在物理信号或比特层面的这一定义。虽然本领域技术人员知道同时发送可能导致比特值冲突，但对比文件本身并未公开这一具体定义。因此，特征J既未被直接公开，也未被隐含公开（因为对比文件未提供足够信息以推导出该特定定义）。 |
| **技术特征K**：还包括：将所述第一设备感测响应消息存储在存储结构中的第一位置中，并且将所述第二设备感测响应消息存储在所述存储结构中的第二位置中。<br>**《未直接公开也非隐含公开》** | 对比文件全文中未提及存储设备感测响应消息，也未提及使用存储结构（如表格、矩阵）来存储不同轮次接收到的响应消息。 | 对比文件完全没有涉及存储多个设备感测响应消息的内容，更不用说将其存储在具有特定位置（第一位置、第二位置）的存储结构中。目标专利的该特征是关于保存历史响应数据以用于后续分析，这是一个特定的数据处理步骤。对比文件未公开任何相关内容，因此特征K既未被直接公开，也未被隐含公开。 |
| **技术特征L**：接收无冲突的设备感测响应消息。<br>**《隐含公开》** | 对比文件说明书第[0081]段：“从执行通信的对象中临时排除（置于已删除状态）轮询响应帧被正常接收并且NFCID可被确认的目标方#2、#4和#5...” | 对比文件提到，在首次轮询中，有些设备的轮询响应帧被“正常接收”且NFCID被确认。这意味着这些响应是无冲突的，否则无法正常接收和确认。此外，在迭代排除已识别设备后，当只剩下一个设备响应时，其响应必然是无冲突的。因此，接收无冲突的响应消息是对比文件所公开流程中的必然结果和中间状态。本领域技术人员能够理解这一点。特征L被隐含公开。 |
| **技术特征M**：通过使用所接收的无冲突设备感测响应消息对所述存储结构中的、所述第一位置中的所述第一设备感测响应消息和所述第二位置中的所述第二设备感测响应消息进行分析，来确定所述第一设备感测响应消息和所述第二设备感测响应消息的无冲突版本。<br>**《未直接公开也非隐含公开》** | 对比文件全文中未提及存储结构，也未提及使用无冲突响应消息对存储的历史冲突响应进行分析以推导出其无冲突版本。 | 该特征涉及一个具体的数据后处理方法：存储冲突响应，并利用最终获得的无冲突响应作为参考，反向推导出之前存储的冲突响应的正确值。这是一个特定且非必要的技术手段。对比文件完全没有公开任何关于存储冲突响应或进行此类分析的内容。因此，特征M既未被直接公开，也未被隐含公开。 |
| **技术特征N**：其中，所述第二设备感测响应消息覆写所述第一设备感测响应消息。<br>**《未直接公开也非隐含公开》** | 对比文件全文中未提及存储设备感测响应消息，因此更不可能公开覆写存储的操作。 | 该特征是关于存储管理的一个具体实施方式。对比文件未涉及任何存储响应消息的步骤，因此该覆写特征无从谈起。特征N既未被直接公开，也未被隐含公开。 |
| **技术特征O**：其中，所述多个远程NFC设备中的每个远程NFC设备被配置为使用NFC-A射频RF技术。<br>**《直接公开》** | 对比文件说明书第[0003]段：“作为用于执行以所述IC卡系统为典型代表的近距离通信的通信协议，NFCIP（近距离通信接口和协议）-1是公知的。NFCIP-1也被定义为ISO/IEC 18092。” <br>第[0049]段：“根据如ISO/IEC 18092定义的NFCIP-1执行NFC通信设备的通信。” | 目标专利的背景技术（[0003]段）指出，NFC论坛活动规范定义了NFC类型A(NFC-A)射频(RF)技术。而NFC-A技术正是基于ISO/IEC 18092 (NFCIP-1)标准。对比文件明确其通信设备执行的是NFCIP-1 (ISO/IEC 18092)协议。因此，对比文件公开的NFC通信设备所使用的RF技术，即NFCIP-1，实质上就是目标专利所指的NFC-A RF技术。本领域技术人员熟知这一点。因此，特征O被直接公开。 |
| **技术特征P**：其中，所述第一设备感测响应消息和所述第二设备感测响应消息是如在NFC论坛数字协议规范中定义的SENS_RES消息。<br>**《直接公开》** | 对比文件说明书第[0077]段：“在SDD处理中，发起方请求目标方的NFCID。由发起方通过发送称为轮询请求帧的帧来进行所述请求。当目标方接收到轮询请求帧时，目标方...发送NFCID所在的轮询响应帧。” | 在NFCIP-1标准（ISO/IEC 18092）以及后续的NFC论坛活动规范中，SDD处理中使用的“轮询请求帧”和“轮询响应帧”通常对应着“SENS_REQ”和“SENS_RES”消息。对比文件描述的SDD处理流程正是NFC-A技术检测的标准流程的一部分。因此，本领域技术人员能够毫无疑义地将对比文件中的“轮询响应帧”等同于目标专利中引用的、在NFC论坛数字协议规范中定义的“SENS_RES”消息。特征P被直接公开。 |
| **技术特征Q**：其中，所述第二设备感测请求消息是如在NFC论坛数字协议规范中定义的SENS_REQ消息。<br>**《直接公开》** | 对比文件说明书第[0077]段：“在SDD处理中，发起方请求目标方的NFCID。由发起方通过发送称为轮询请求帧的帧来进行所述请求。” | 同上所述，对比文件中的“轮询请求帧”在本领域技术人员看来，即对应NFC论坛规范中的“SENS_REQ”消息。特征Q被直接公开。 |
| **技术特征R**：其中，所述睡眠请求消息是如在NFC论坛数字协议规范中定义的SLP_REQ消息。<br>**《直接公开》** | 对比文件说明书第[0086]段：“当发起方将目标方设置为处于取消选择状态时，命令DSL_REQ被发送。” | 在NFCIP-1/NFC论坛规范中，用于使目标设备进入睡眠/取消选择状态的命令即为“SLP_REQ”。对比文件明确提到了“命令DSL_REQ”用于实现此功能。本领域技术人员熟知，“DSL_REQ”是“Deselect Request”的缩写，其在NFC标准中与“SLP_REQ”（Sleep Request）功能等效或密切相关，都是用于使设备进入非响应状态。因此，可以认定对比文件公开的“DSL_REQ”即为目标专利中所指的“SLP_REQ”消息。特征R被直接公开。 |
| **技术特征S**：其中，所述多个远程NFC设备包括阅读器设备、写入设备、标签、卡以及对等设备中的至少一个。<br>**《直接公开》** | 对比文件说明书第[0017]段：“可采用图1的通信系统作为IC卡系统，其中，NFC通信设备1到3中的一个或多个可构成阅读器/写入器，其它的一个或多个NFC通信设备可构成IC卡。” <br>第[0018]段：“此外，可采用NFC设备1到3中的每一个作为PDA（个人数字助理）、PC（个人计算机）、移动电话、腕表、笔等的通信系统。” | 对比文件明确提及了其NFC通信设备可以构成“阅读器/写入器”（即阅读器设备、写入设备）和“IC卡”（即卡、标签）。此外，PDA、移动电话等设备通常可以运行对等通信模式。因此，对比文件公开的远程NFC设备类型涵盖了目标专利特征S中所列举的多种设备。特征S被直接公开。 |
| **技术特征T**：还包括：与发送了设备感测响应消息的每个设备执行单个设备检测通信以便获得NFC设备标识符NFCID。<br>**《直接公开》** | 对比文件说明书第[0077]段：“在SDD处理中，发起方请求目标方的NFCID...目标方...发送NFCID所在的轮询响应帧。发起方通过接收从目标方发送的轮询响应帧来确认目标方的NFCID。” <br>第[0081]段：“...可确认目标方#1到#5的所有NFCID...” | “单个设备检测”（SDD）处理在对比文件中被明确且详细地描述（见第[0077]段及图7）。该处理的唯一目的就是让发起方获得每个目标设备的NFCID。对比文件全文多次提及并通过SDD处理获得NFCID。因此，特征T被对比文件直接公开。 |
<<<C>>><<<G>>><<<O>>><<<P>>><<<Q>>><<<R>>><<<S>>><<<T>>>
<<<d>>><<<e>>><<<f>>><<<h>>><<<i>>><<<l>>>