对比文件名称：2011-08-18_WO2011100497A_发明申请_WO2011100497A1 GROUP PAGING FOR MACHINE-TYPE COMMUNICATIONS
目标专利名称：294建立物联网(IOT)设备群并实现IOT设备群之间的通信CN105075185B
本次调用的模型名称：GPT-4
### 特征比对表格
| 技术特征描述以及公开性判断结果 | 对比文件原文引用 | 公开性论述 |
| **技术特征A**：根据一个或多个群准则以及与一个或多个IoT设备相关联的一个或多个属性来将多个IoT设备形成为多个IoT群。<br>**《直接公开》** | [p0066] “In an embodiment, an MTC group may be defined based on one or more shared features among MTC WTRUs. Features that may be used to determine whether WTRUs may be classified as a group may include but are not limited to: whether MTC WTRUs use a same or similar application, whether MTC WTRUs are time-controlled MTC WTRUs (e.g. MTC WTRUs that may send and/or receive data at pre-defined periods), whether WTRUs are mobile-originated-only MTC WTRUs (e.g. MTC WTRUs that may send data but will not receive data in the normal course of operation), whether MTC WTRUs are time -tolerant WTRUs (e.g. WTRUs that may be permitted to delay transmission of data), whether WTRUs are low-mobility WTRUs (e.g. MTC WTRUs that may not frequently move and/or may not move at high speeds), whether MTC WTRUs are not-mobile WTRUs (e.g. MTC WTRUs that may stay in the same location), and/or other features.”<br>**翻译**：在一个实施例中，可以基于MTC WTRU之间的一个或多个共享特征来定义MTC群组。可用于确定WTRU是否可被分类为群组的特征可包括但不限于：MTC WTRU是否使用相同或相似的应用、MTC WTRU是否是时间控制的MTC WTRU（例如，可在预定周期发送和/或接收数据的MTC WTRU）、WTRU是否是仅移动台发起的MTC WTRU（例如，可发送数据但在正常操作过程中不会接收数据的MTC WTRU）、MTC WTRU是否是时间容忍WTRU（例如，可被允许延迟数据传输的WTRU）、WTRU是否是低移动性WTRU（例如，可能不频繁移动和/或不能高速移动的MTC WTRU）、MTC WTRU是否是非移动WTRU（例如，可能停留在相同位置的MTC WTRU）和/或其他特征。 | 对比文件明确公开了基于“共享特征”（shared features）将MTC设备（可视为IoT设备的一种）组织成群组（MTC group）。这些“共享特征”（例如，使用相同应用、具有特定时序控制模式、移动性特征等）即为目标专利中所述的“群准则”和“属性”。本领域技术人员能够毫无疑义地确定，基于设备的属性（如应用类型、操作模式、移动性）形成群组，是对比文件公开的“基于共享特征定义群组”的直接技术方案。因此，技术特征A被对比文件直接公开。 |
| **技术特征B**：根据所述一个或多个群准则以及与所述一个或多个IoT设备相关联的所述一个或多个属性来定义每一IoT群内的一个或多个层次。<br>**未被公开** | 无 | 对比文件仅公开了将设备分组并进行群组寻呼，但未提及在已定义的群组内部进一步定义“层次”（hierarchy）。目标专利中的“层次”用于控制群内和群间的通信结构（如指定群主、高级别成员）。对比文件的内容不涉及群组内部的组织结构或层级划分。本领域技术人员无法从对比文件公开的“群组”概念中，直接或隐含地推导出需要在每个群内定义“一个或多个层次”。因此，技术特征B未被公开。 |
| **技术特征C**：其中所述一个或多个层次控制每一IoT群内的群内通信以及所述多个IoT群之间的群间通信。<br>**未被公开** | 无 | 如上所述，对比文件未公开“层次”这一技术特征。因此，由层次“控制”群内及群间通信的功能自然也未被公开。对比文件虽然描述了群组寻呼及群内设备对寻呼的响应（可视为一种群内通信），以及网络与群组之间的通信，但这种通信是由网络基础设施（如基站、核心网）基于群组标识直接控制的，而非由群组内部定义的“层次”来控制。因此，技术特征C未被公开。 |
| **技术特征D**：以及其中将所述多个IoT设备形成为所述多个IoT群包括形成包括具有上下文受限的一个或多个共同属性的一个或多个成员的至少一个自组织IoT群。<br>**未被公开** | 无 | 对比文件公开的群组是基于“共享特征”形成的，这些特征虽然可能包括时间控制（time-controlled）、位置（not-mobile）等，但其描述更侧重于设备固有的、可用于分类的静态或半静态属性，并未强调“上下文受限”（context-restricted）这一动态、临时性的概念。目标专利的“自组织IoT群”特指基于动态上下文（如特定时间、位置、状态）临时形成的群。对比文件未公开这种基于动态上下文临时、自组织形成群组的机制。因此，技术特征D未被公开。 |
| **技术特征E**：其中所述一个或多个群准则包括基于所述一个或多个上下文受限属性的动态准则。<br>**未被公开** | 无 | 对比文件未公开基于“上下文受限属性”形成群组（技术特征D），因此，作为其前提的“动态准则”自然也未被公开。对比文件提到的“time-controlled”等特征，在目标专利中可能被视为一种动态属性，但对比文件并未将其明确为用于动态形成群组的“准则”，也未区分静态与动态准则。因此，技术特征E未被公开。 |
| **技术特征F**：其中形成所述自组织IoT群包括：检测所述多个IoT设备中彼此相邻的复数个IoT设备。<br>**《隐含公开》** | [p0067] “In an embodiment, MTC WTRUs belonging to the same cell may be grouped into an MTC group. In an embodiment, MTC WTRUs located in the same geographic area may be grouped into an MTC group. For example, utility meters within a neighborhood may be grouped into an MTC group.”<br>**翻译**：在一个实施例中，属于相同小区的MTC WTRU可被分组成一个MTC群组。在一个实施例中，位于相同地理区域的MTC WTRU可被分组成一个MTC群组。例如，邻里内的公用事业仪表可被分组成一个MTC群组。 | 对比文件公开了将位于“相同地理区域”或“相同小区”的设备分组成一个MTC群组。为了将设备按地理位置分组，必然需要先知晓或“检测”哪些设备位于该区域，即这些设备是彼此相邻的。虽然对比文件未明确描述“检测”这一动作的具体步骤，但“位于相同地理区域”是分组的前提条件。本领域技术人员可以合理推断，为了实现按地理位置分组，网络或管理实体需要有能力检测或识别出哪些设备在物理位置上是相邻的。因此，技术特征F被对比文件隐含公开。 |
| **技术特征G**：标识要实现的期望功能。<br>**未被公开** | 无 | 对比文件的核心目的是通过群组寻呼来减少网络拥塞，其群组形成是基于设备共享的特征，而非为了实现某个特定的、用户或系统定义的“期望功能”（如减少光干扰、对房间制冷）。对比文件未提及在形成群组前或过程中，需要标识一个待实现的“期望功能”。因此，技术特征G未被公开。 |
| **技术特征H**：基于与所述复数个IoT设备相关联的一个或多个属性来确定所述复数个IoT设备中具有实现所述期望功能的能力的子集。<br>**未被公开** | 无 | 由于对比文件未公开“标识期望功能”（技术特征G），因此也就不存在基于设备属性来筛选能够实现该功能的设备“子集”这一步骤。对比文件中的群组是基于所有成员的共享特征形成的，并非从一个更大的相邻设备集合中，为特定功能筛选出一个子集来形成群。因此，技术特征H未被公开。 |
| **技术特征I**：指导所述复数个IoT设备的所确定的子集形成被配置成在本地通信信道上进行通信的独立设备群，其中所述至少一个自组织IoT群至少包括所述独立设备群。<br>**未被公开** | 无 | 对比文件中的MTC群组通信依赖于蜂窝网络基础设施（如通过寻呼信道PCH），并未提及形成在“本地通信信道”（例如独立的蓝牙、Wi-Fi信道）上进行通信的“独立设备群”。目标专利中“独立设备群”的关键在于其通信独立于组织者，使用本地信道。对比文件未公开指导设备形成此类独立群组，也未提及本地通信信道。因此，技术特征I未被公开。 |
| **技术特征J**：以及指导所述独立设备群实现所述期望功能。<br>**未被公开** | 无 | 由于对比文件未公开“独立设备群”（技术特征I）和“期望功能”（技术特征G），因此“指导实现期望功能”这一特征也未被公开。对比文件中群组被寻呼后，设备可能上传数据，但这并非在“指导”下协作实现一个如光照控制、温度调节之类的具体功能。因此，技术特征J未被公开。 |
| **技术特征K**：其特征在于，定义所述一个或多个层次包括：指定每一IoT群内的群主，其中所指定的群主协调与其他IoT群的所述群间通信。<br>**未被公开** | 无 | 对比文件完全没有提及在群组内指定“群主”（group master）这一角色。群组寻呼和响应是由网络直接管理，或由群内设备各自响应，没有由一个指定的设备（群主）来协调与其他群组通信的机制。因此，技术特征K未被公开。 |
| **技术特征L**：其特征在于，服务器与每一IoT群中的所述群主通信以便进一步协调所述群间通信。<br>**未被公开** | 无 | 对比文件提到了MTC服务器（MTC server）的存在（如图2、3），但该服务器是与网络或用户交互，并未描述其与每个群组内指定的“群主”进行通信以协调群间通信。由于“群主”角色未被公开，此特征的前提不存在。因此，技术特征L未被公开。 |
| **技术特征M**：其特征在于，每一IoT群中的所述群主进行对等通信以协调所述群间通信。<br>**未被公开** | 无 | 对比文件未提及“群主”，更未提及群主之间进行“对等通信”（P2P communication）以协调群间通信。群组间的交互（如果有）是通过网络基础设施进行的。因此，技术特征M未被公开。 |
| **技术特征N**：其特征在于，所述群间通信包括：将消息从第一IoT群中的IoT设备发送到与目标IoT群相关联的地址，其中与所述目标IoT群相关联的所述群主接收所述消息并根据控制所述群间通信的所述一个或多个层次来将所接收到的消息转发至所述目标IoT群中的其他IoT设备。<br>**未被公开** | 无 | 该特征描述了基于群主和层次结构的特定群间消息路由机制。对比文件未公开“群主”、“层次”，也未公开设备向目标“群地址”发送消息并由群主接收并转发的通信模式。因此，技术特征N未被公开。 |
| **技术特征O**：其特征在于，定义所述一个或多个层次包括：指定每一IoT群内的一个或多个高级别成员，其中所指定的高级别成员协调每一IoT群内的所述群内通信。<br>**未被公开** | 无 | 对比文件未提及在群组内指定“高级别成员”或任何内部层级来协调“群内通信”。群内设备对寻呼的响应可能是并行的或分时的，但没有一个被指定的成员来协调这些通信。因此，技术特征O未被公开。 |
| **技术特征P**：其特征在于，所述一个或多个群准则包括一个或多个静态准则，并且所述一个或多个层次基于所述一个或多个静态准则以及与每一IoT群中的所述一个或多个IoT设备相关联的永久属性来定义。<br>**未被公开** | 无 | 对比文件未区分“静态准则”和“动态准则”，也未公开基于任何准则来“定义层次”。虽然其用于分组的“共享特征”（如同类应用、低移动性）可能对应于目标专利中的“永久属性”，但将这些属性用于“定义层次”这一技术手段未被公开。因此，技术特征P未被公开。 |
| **技术特征Q**：其特征在于，将所述多个IoT设备形成为所述多个IoT群包括：形成包括共同具有一个或多个永久属性的一个或多个成员的至少一个预定义IoT群，其中所述一个或多个群准则包括基于所述一个或多个永久属性的静态准则。<br>**未被公开** | 无 | 对比文件公开的基于“共享特征”的群组，在某种意义上可以视为具有共同属性的“预定义群”。然而，对比文件并未明确区分“预定义群”和“自组织群”，也未强调其形成是基于“永久属性”和“静态准则”。更重要的是，目标专利中“预定义IoT群”是与“自组织IoT群”并列的概念，共同构成权利要求的整体方案。对比文件仅公开了类似“预定义群”的概念，但未公开与之并列的、基于动态准则的“自组织群”（技术特征D），因此，单独割裂地看，此特征可能被部分公开，但作为整体技术方案的一部分，其与自组织群的结合未被公开。从严格意义上，对比文件未明确公开“预定义IoT群”这一特定概念及其与静态准则的关联。因此，技术特征Q未被公开。 |
| **技术特征R**：其特征在于，所述一个或多个群准则包括一个或多个动态准则，并且所述一个或多个层次基于所述一个或多个动态准则以及与每一IoT群中的所述一个或多个IoT设备相关联的一个或多个上下文受限属性来定义。<br>**未被公开** | 无 | 对比文件未公开“动态准则”和“上下文受限属性”（参见技术特征D、E），也未公开基于它们来“定义层次”。因此，技术特征R未被公开。 |
| **技术特征S**：其特征在于，毗邻所述复数个IoT设备的设备组织者经由本地引导信道来检测所述复数个IoT设备。<br>**未被公开** | 无 | 对比文件未提及“设备组织者”（device organizer）这一实体，也未提及通过“本地引导信道”（local bootstrap channel）来检测设备。设备的分组可能由网络（如核心网）基于订阅数据或位置信息完成，而非由一个本地的组织者通过专用引导信道检测。因此，技术特征S未被公开。 |
| **技术特征T**：其特征在于：检测到的复数个IoT设备包括一个或多个光源，要实现的所述期望功能包括减少与所述复数个IoT设备相邻的投影屏幕附近的光干扰，所述一个或多个属性包括与所述一个或多个光源相关联的发光能力、安装位置和光输出取向，所述复数个IoT设备中的形成为所述独立设备群的所述子集被预期为基于与所述一个或多个光源相关联的所述发光能力、所述安装位置或所述取向中的一者或多者而导致所述投影屏幕附近的所述光干扰，并且所述复数个IoT设备中的形成为所述独立设备群的所述子集被配置成通过降低光输出能级或改变与其相关联的所述光输出取向中的一者或多者来减少所述投影屏幕附近的所述光干扰。<br>**未被公开** | 无 | 该技术特征是一个具体的光照控制应用实施例，涉及非常具体的设备类型（光源）、功能（减少光干扰）、属性（发光能力、位置、取向）和控制动作（降低光输出、改变取向）。对比文件通篇涉及的是通用的MTC通信和群组寻呼，以优化网络资源为目标，完全不涉及此类具体的物联网设备协同实现环境控制功能的场景、属性和方法。因此，技术特征T未被公开。 |
| **技术特征U**：其特征在于：所述检测到的复数个IoT设备包括一个或多个空调，要实现的所述期望功能包括对房间制冷，所述一个或多个属性包括所述一个或多个空调能够制冷的所标识的区域以及所述一个或多个空调能够对所述所标识的区域制冷的程度，所述复数个IoT设备中的形成为所述独立设备群的所述子集被配置成对所述房间制冷，并且所述复数个IoT设备中的形成为所述独立设备群的所述子集被配置成调整对所述房间制冷的制冷输出能级。<br>**未被公开** | 无 | 该技术特征是一个具体的温度控制应用实施例，涉及空调设备、制冷功能、制冷区域属性及输出能级调整。与技术特征T类似，对比文件完全不涉及此类具体的环境控制应用场景和设备协同工作方式。因此，技术特征U未被公开。 |
<<<A>>><<<f>>>