好的，我将作为资深专利代理师，对您提供的对比文件是否公开目标专利权利要求的各技术特征进行严谨评估。
首先，明确评估的基本信息如下：
- **对比文件名称：** 2011-07-12_US7979070B_发明授权_US07979070B2 Mobile equipment for sending an attach request to a network
- **目标专利名称：** 1039装置触发解决方案CN110022537B
- **本次调用模型名称：** 通用评估模型 V3.0
接下来，我将以目标专利权利要求的划分方式，逐一分析各技术特征是否被对比文件公开。在分析中，我将紧密结合目标专利说明书原文来解释技术特征的含义，并判断对比文件是否通过直接或隐含的方式公开了这些特征。
### 特征比对表格
| 技术特征描述及公开性判断结果 | 对比文件原文引用 | 公开性论述 |
| **技术特征A：** 用户装备发起附着请求并且在请求的装置属性部分中指示用户装备的装置触发能力<br><br>**《未公开》** | [0022] The Attach request 9 comprises a data field 10 defining IMSI... The “Attach Type” field 11 of the Attach request 9 indicates which type of attach is to be performed which may basically be “GPRS attach only”... or, as indicated in FIG. 3, combined “PS (packet switched)+default POP context activation”.<br><br>（译文：附着请求9包括定义IMSI的数据字段10...附着请求的“附着类型”字段11指示将要执行的附着类型，其可以是“仅GPRS附着”...或者如图3所示的组合“PS（分组交换）+默认PDP上下文激活”。）<br><br>[0023] In case the attach request transmitted from the mobile station 1 specifies the attach type “PS+DEFAULT PDP CONTEXT ACTIVATION” as shown in FIG. 3, the system is informed on the desired combined attach and PDP context activation.<br><br>（译文：在从移动站1发送的附着请求指定附着类型为“PS+默认PDP上下文激活”的情况下，系统被告知所需的组合附着和PDP上下文激活。） | 该特征的实质是：在附着请求中携带一个特定的指示，用以通知网络该用户设备具备被用于特定目的（装置触发）的能力，从而网络可以在后续流程中根据该能力进行特定操作。这个能力指示是一个功能性的、用于后续流程控制的标志。<br><br>对比文件公开了在附着请求中设置“附着类型”字段，例如“PS+默认PDP上下文激活”。此字段指示的是一种**对附着流程本身的修改**，即请求网络在完成附着的同时，自动激活一个默认的PDP上下文。这并非指示用户设备具备某项后续可被网络调用的“能力”，而是直接请求网络执行一个特定的组合流程。对比文件中没有提及任何与“装置触发能力”类似的概念，该字段的内容和作用与目标专利中的“装置触发能力的指示”在功能上完全不同，也不存在任何暗示。因此，对比文件既未直接公开也未隐含公开该技术特征。 |
| **技术特征B：** 移动性管理实体处理附着过程<br><br>**《直接公开》** | [0025] FIG. 4 shows an attach process flow. In step S1, the mobile station 1 sends an Attach request to the support node 2 which then checks, in step S2, the received Attach request...<br><br>（译文：图4示出了附着过程流程。在步骤S1，移动站1向支持节点2发送附着请求，然后在步骤S2，支持节点2检查接收到的附着请求...）<br><br>[0026] If no combined attach and default POP activation request is detected in step S2, the process proceeds to step S5 and performs a normal attachment only according to the designated attach type. As part of steps S4, S5, the support node 2 may also send an Attach Accept message to the mobile station 1... The attach process then ends (step S6).<br><br>（译文：如果在步骤S2未检测到组合附着和默认PDP激活请求，则过程进行到步骤S5，仅根据指定的附着类型执行正常附着。作为步骤S4、S5的一部分，支持节点2还可以向移动站1发送附着接受消息...附着过程然后结束（步骤S6）。） | 该特征限定了“移动性管理实体”（在GPRS/UMTS网络中对应SGSN）执行“处理附着过程”这一功能。这是一个非常基础且通用的网络功能。<br><br>对比文件明确公开了一个网络节点——服务GPRS支持节点（SGSN，支持节点2），其功能包括接收来自移动站（MS）的附着请求，并对该请求进行识别和验证（检查附着类型），随后执行相应的附着流程（包括发送附着接受消息等）。这些操作完全符合“移动性管理实体处理附着过程”的描述。因此，该技术特征被对比文件直接且毫无疑义地公开。 |
| **技术特征C：** 移动性管理实体存储（610）用户装备（810）的接收到的装置触发能力<br><br>**《未公开》** | [0025] ...the support node 2...then checks, in step S2, the received Attach request...<br><br>（译文：支持节点2...检查接收到的附着请求...）<br><br>[0030] Further, the Home Location Register 3 sends an Insert Subscriber Data to the new support node 2 which subscriber data includes information on the default PDP context(s). The new support node validates the MS's presence in the new routing area, and sends back an Insert Subscriber Data Acknowledgement to the Home Location Register 3.<br><br>（译文：此外，归属位置寄存器3向新支持节点2发送插入用户数据，该用户数据包括关于默认PDP上下文的信息。新支持节点验证MS在新路由区域中的存在，并向归属位置寄存器3发回插入用户数据确认。） | 该特征的实质是：移动性管理实体（MME/SGSN）在接收到用户装备（UE）发送的附着请求后，将其中包含的“装置触发能力”信息存储起来，以便后续使用。此处的“装置触发能力”是特征A中UE在请求中指示的信息。<br><br>对比文件中，SGSN（支持节点）在接收附着请求后，会检查并响应请求（如[0025]所述），但它存储的信息来自HLR的用户订阅数据（默认PDP上下文信息），而非来自UE在附着请求中指示的“能力”。对比文件从未提及UE会在附着请求中指示任何“能力”，更不存在“装置触发能力”这一概念，因此SGSN没有与之对应的信息可以存储。该特征在对比文件中未被公开。 |
| **技术特征D：** 移动性管理实体向机器类型通信交互工作功能通知装置触发能力<br><br>**《未公开》** | 对比文件全文未提及“机器类型通信交互工作功能（MTC-IWF）”或任何具有类似功能的网元。 | 该特征的执行主体是“移动性管理实体”和“机器类型通信交互工作功能（MTC-IWF）”。MTC-IWF是3GPP标准中为支持机器类型通信（MTC）而定义的一个核心网功能实体，用于在网络和MTC服务器之间交互。对比文件涉及的是GPRS/UMTS系统中标准的附着和PDP上下文激活流程，其描述的网络架构中只包含MS、SGSN、HLR、GGSN等传统网元，完全没有提及或暗示MTC-IWF的存在。因此，移动性管理实体（SGSN）无法向一个不存在的网元发送任何通知，该技术特征未被公开。 |
| **技术特征E：** 机器类型通信交互工作功能从机器类型通信服务器接收请求以触发用户装备<br><br>**《未公开》** | 对比文件全文未提及“机器类型通信交互工作功能（MTC-IWF）”或“机器类型通信服务器（MTC Server）”。 | 与特征D类似，该特征涉及MTC架构中的两个核心实体：MTC-IWF和MTC服务器。对比文件的发明目的是在附着时自动激活默认PDP上下文以减少信令，其技术方案完全基于传统GPRS/UMTS网络，不涉及MTC应用、MTC服务器或MTC-IWF。因此，该技术特征在对比文件中未被公开。 |
| **技术特征F：** 机器类型通信交互工作功能向移动性管理实体发送（720）装置触发请求消息<br><br>**《未公开》** | 对比文件全文未提及“装置触发请求消息”或MTC-IWF向SGSN发送任何消息以触发装置。 | 该特征描述了MTC-IWF在执行转换（特征L）和认证之后的一个关键动作：向为UE服务的移动性管理实体（MME/SGSN）发送触发请求。对比文件中，SGSN发起的PDP上下文激活请求（Create PDP Context Request）是直接发送给GGSN（网关GPRS支持节点）的（见[0032]步骤8），并非接收来自MTC-IWF的请求。整个对比文件不存在MTC-IWF向SGSN发送消息的流程，此特征未被公开。 |
| **技术特征G：** 移动性管理实体在接收到装置触发消息时触发用户装备。<br><br>**《未公开》** | [0032] In the next step 8, the new support node 2 sends a Create PDP Context Request to the gateway support node 4 so that the default PDP context(s) is (are) activated in the support node(s) 4 according to the information received from the Home Location Register 3 in step 6.<br><br>（译文：在下一步骤8，新支持节点2向网关支持节点4发送创建PDP上下文请求，以便根据在步骤6中从归属位置寄存器3接收到的信息在支持节点4中激活默认PDP上下文。）<br><br>[0032] In step 9, the support node 2 sends an Attach Accept message to the mobile station 1 for acknowledging the attach and default PDP context activation.<br><br>（译文：在步骤9，支持节点2向移动站1发送附着接受消息，以确认附着和默认PDP上下文激活。） | 该特征的关键在于“装置触发消息”。在目标专利中，此消息是MTC-IWF专门发送的，用于请求对某个UE进行触发的指令。MME/SGSN在收到该消息后，会执行一系列操作（如寻呼、存储触发信息、发送NAS消息等）来“触发”UE，以使其与网络建立连接。<br><br>对比文件中，SGSN执行PDP上下文激活是基于“附着请求”本身（结合了默认上下文激活请求）或后续的激活请求（图6），而不是基于一个外部的、独立的“装置触发消息”。SGSN向MS发送“附着接受”消息是为了确认附着和PDP上下文激活的结果，而非响应于一个装置触发请求来“触发”UE。两者在触发源、触发目的和触发流程上完全不同，因此该特征未被公开。 |
| **技术特征H：** 进一步包括：由用户装备响应于接收到的寻呼请求发送服务请求，其中所述触发所述用户装备是响应于所述接收到的装置触发的，并且所述接收到的装置触发是响应于所述服务请求所接收到的。<br><br>**《未公开》** | 对比文件未描述响应于“寻呼请求”来获取“装置触发”的流程。 | 该特征是目标专利中一种具体的触发流程：UE在空闲模式下，MME寻呼UE，UE响应服务请求，然后MME将装置触发信息发送给UE。对比文件中，SGSN和UE之间的交互并不包含“寻呼-服务请求-接收触发信息”这样的步骤。对比文件的流程是基于附着请求直接触发后续操作，或者由UE主动发起激活请求（图6），不存在网络侧单独进行寻呼以传递一个“装置触发消息”的过程。因此，该特征未被对比文件公开。 |
| **技术特征I：** 其中所述触发所述用户装备是响应于所述接收到的装置触发而执行的，并且所述接收到的装置触发是在非接入层消息中接收到的。<br><br>**《未公开》** | 对比文件未描述通过“非接入层（NAS）消息”传递“装置触发”信息。 | 该特征限定了“装置触发”信息是通过NAS消息传递给UE的。在目标专利中，这是一种直接由MME封装并发送给UE的触发方式。对比文件中，SGSN与MS之间的信令交互，例如Attach Accept（[0032]步骤9）或PDP上下文激活响应（图6步骤5），确实可能使用NAS消息。但是，这些消息是用于响应附着请求或PDP上下文激活请求的，而不是用于传递一个独立的、由MTC触发器产生的“装置触发”消息。对比文件的消息内容和用途与目标专利的“装置触发通告”完全不同。因此该特征未被公开。 |
| **技术特征J：** 进一步包括：由移动性管理实体将寻呼请求发送到所述用户装备，以便在触发所述用户装备之前接收响应服务请求。<br><br>**《未公开》** | 对比文件未涉及在装置触发流程中进行寻呼的步骤。 | 该特征与特征H紧密相关，描述了网络侧在触发空闲态UE时进行的寻呼操作。对比文件描述的流程不涉及在附着或PDP激活过程中对空闲态的UE进行寻呼。例如，在附着流程中，UE是主动发起请求的一方。在后续的默认PDP激活中（图6），也是UE主动发起请求。整个过程不包含“MME为了传递触发信息而主动寻呼UE”这一步骤。因此该特征未被公开。 |
| **技术特征K：** 其中所述触发所述用户装备包括发送服务接受消息、发送非接入层装置触发消息或者在不使用短消息服务中心或移动交换中心的情况下发送短消息服务消息中的至少一个。<br><br>**《未公开》** | [0032] In step 9, the support node 2 sends an Attach Accept message to the mobile station 1 for acknowledging the attach and default PDP context activation.<br><br>（译文：在步骤9，支持节点2向移动站1发送附着接受消息，以确认附着和默认PDP上下文激活。） | 该特征列举了三种用于触发UE的具体消息类型：`服务接受消息`、`非接入层装置触发消息`、`不使用SMSC/MSC的SMS消息`。在目标专利中，这些消息都承载了用于“装置触发”的信息。<br><br>对比文件中，SGSN确实会发送`Attach Accept`消息（等效于服务接受消息的一种），但其目的是为了确认附着和PDP上下文激活过程完成，而非传递触发信息。对比文件没有发送“非接入层装置触发消息”和“不使用SMSC/MSC的SMS消息”的任何描述。即便消息类型名称可能部分相似，但其承载的内容和目的在对比文件和目标专利中完全不同。因此该特征未被公开。 |
| **技术特征L：** 包括：由机器类型通信交互工作功能响应于从机器类型通信服务器接收用于用户装备的装置触发消息将应用标识符转换为接入点名称。<br><br>**《未公开》** | 对比文件全文未提及“机器类型通信交互工作功能（MTC-IWF）”、“机器类型通信服务器”或“应用标识符”。<br><br>[0035] ...the mobile station MS may send some parameters for the default POP context(s)... an example, APN (Access Point Name) may be sent from MS...<br><br>（译文：移动站MS可以发送用于默认PDP上下文的一些参数...例如，APN（接入点名称）可以从MS发送...） | 该技术特征描述了MTC-IWF的一个核心功能：将从MTC服务器接收的“应用标识符（appID）”转换为网络可识别的“接入点名称（APN）”。这是MTC-IWF在装置触发流程中的关键步骤。<br><br>对比文件虽然提到了APN，但APN是由MS（用户设备）发送给SGSN的参数（[0035]），或者是存储在HLR中的订阅信息的一部分。这仅是一个传统的PDP上下文激活过程。对比文件中完全没有MTC-IWF、MTC服务器以及应用标识符的概念，因此不存在从一个实体接收标识符并转换为APN的功能。该特征未被公开。 |
| **技术特征M：** 进一步包括：由机器类型通信交互工作功能通过使用从移动性管理实体接收到的装置触发能力来选择用于所述用户装备的触发机制。<br><br>**《未公开》** | 对比文件全文未提及“机器类型通信交互工作功能（MTC-IWF）”、“装置触发能力”或“选择触发机制”。 | 该特征描述了MTC-IWF依据从MME接收到的UE的装置触发能力信息，来决策采用何种具体方式（如特征K所述的几种方式之一）触发该UE。这是一个灵活的、基于能力协商的触发决策过程。<br><br>对比文件的方案中，网络侧的操作（激活默认PDP上下文）是依据订阅数据（来自HLR）和附着请求类型来决定的，是一个相对固定的流程。不存在一个类似MTC-IWF的实体来感知UE的“装置触发能力”并据此动态选择触发机制。因此该特征未被公开。 |
---
### 最终结论
经过严谨比对和论述，对比文件 **2011-07-12_US7979070B_发明授权_US07979070B2 Mobile equipment for sending an attach request to a network** 仅直接公开了目标专利权利要求中的一个技术特征。
- 被直接公开的技术特征：**B**
因此，在回答结尾插入对应的大写英文代码：
<<<B>>>