好的，收到您的任务。作为一名经验丰富的专利代理师，我将严谨、细致地对目标专利与对比文件进行特征比对分析。首先，我将明确本次分析涉及的各项信息，并严格遵循您设定的评估框架和要求。
**对比文件名称：** 2008-04-24_US2008098071A_发明申请_US20080098071A1 METHOD AND PROCESS TO UNSUBSCRIBE FROM ON-GOING ELECTRONIC MESSAGE THREADS
**目标专利名称：** 1158M2M通信的动态事件订阅CN107431722B
**调用模型名称：** 未指定
接下来，我将依据目标专利的权利要求和说明书，以及对对比文件的详细解读，创建特征比对表格并进行公开性判断。
### 特征比对与分析
**特征分析前声明：**
目标专利的技术背景是M2M通信，涉及公共服务实体(CSE)、订阅发起者、接收者等特定实体，以及基于事件的通知、移除策略、组管理等技术特征。对比文件涉及的是电子邮件消息线程的退订管理。虽然两者都涉及“退订”或“移除接收者”的概念，但其技术领域、系统架构、实体关系、核心处理逻辑（尤其是移除策略的概念和动态性）存在本质差异。以下分析将基于此前提进行。
| 技术特征描述及公开性判断结果 | 对比文件原文引用 | 公开性论述 |
| **技术特征A：** 36)执行的能够移除通知接收者(38)的操作的方法，包括：向一个或多个接收者(38)发送事件的通知，所述一个或多个接收者(38)通过订阅发起者(34)订阅所述事件的通知，并且与所述订阅发起者(34)不同<br><br>**《未公开》** | 对比文件[0019]:“With the present invention when a recipient unsubscribes from an on-going email thread that is not of interest, the recipient's email server continues to monitor for any incoming mail on the thread (attributes are the email subject and the email parties) and holds the email.”<br><br>对比文件[0020]:“In FIG. 1A a sender 100 sends a message 102 with a subject of “Machine Problems” to five recipients (A, B, C, D, E) 104, 106, 108, 110, 112. Subsequently, in recipient E 112 unsubscribes from the thread 116 with the “Machine Problem” subject matter.” | 对比文件公开了向多个接收者（收件人）发送消息（电子邮件线程中的消息），以及接收者可以退订（unsubscribe）该消息线程。然而，目标专利中的“事件的通知”是基于M2M系统内特定事件（如温度超阈值）触发的，而对比文件中的“消息”是电子邮件线程中的一系列回复。更重要的是，目标专利中接收者是通过“订阅发起者”进行订阅的，订阅发起者与接收者是不同的实体，这是目标专利解决的技术问题之一。对比文件中，消息的发送者（原始发件人）直接向收件人发送邮件，收件人并非“通过”发件人“订阅”该邮件线程。发件人发起消息线程，但收件人作为线程的参与者，其本身是消息的接收者，而非通过发件人“订阅”一个事件。对比文件中不存在“订阅发起者”这一独立于发送者和接收者的角色，且没有“订阅事件通知”的概念。因此，技术特征A未被公开。 |
| **技术特征B：** 接收来自所述一个或多个接收者(38)中的接收者(38)的移除请求，所述移除请求是移除作为事件通知的接收者的所述接收者(38)的请求<br><br>**《直接公开》** | 对比文件[0020]:“Subsequently, in recipient E 112 unsubscribes from the thread 116 with the “Machine Problem” subject matter.”<br><br>对比文件[0019]:“With the present invention when a recipient unsubscribes from an on-going email thread ...” | 对比文件明确公开了接收者（recipient）发起的退订（unsubscribe）行为。该退订行为在本质上就是接收者向系统（邮件服务器）发出的、请求将自身从消息线程的接收者列表中移除的请求。这与目标专利中所述的“接收来自接收者的移除请求，该请求是移除作为事件通知的接收者的请求”对应。目标专利的“移除请求”对应对比文件的“unsubscribe”请求。 |
| **技术特征C：** 基于针对所述接收者的移除策略，确定是否允许移除作为所述事件通知的接收者的所述接收者(38)<br><br>**《未公开》** | 对比文件[0019]:“When a recipient unsubscribes from an on-going email thread ... the recipient's email server continues to monitor for any incoming mail on the thread ... and holds the email.”<br><br>对比文件[0020]:“In response to recipient E 112, the server handling recipient E's messages 118 will filter for messages with the “Machine Problem” subject matter, as well as sender 100 and recipients 104, 106, 108, 110, and .” | 目标专利的“移除策略”是关键特征，它是由订阅发起者定义，用于控制是否允许接收者移除的规则（例如，需要批准、满足时间/位置条件等）。对比文件仅描述了接收者可以直接退订邮件线程，服务器被动地处理该退订请求（例如，过滤并保留后续邮件）。对比文件中不存在一个由发送者（或任何第三方）定义的、用于判断是否允许退订的“策略”。退订是完全由接收者单方面决定的。对比文件中的“覆盖”（override）机制（[0019]段落）是由其他接收者发起的，并非订阅发起者定义的策略，且是针对已退订者再次发送，而非在初始退订时决定“是否允许移除”。因此，技术特征C未被公开。 |
| **技术特征D：** 确定移除策略是否需要来自订阅发起者(34)的批准<br><br>**《未公开》** | 对比文件[0020] 及全文：未提及“订阅发起者（subscription initiator）”的概念，也未提及“订阅发起者的批准”。 | 基于技术特征C的分析，对比文件不存在“移除策略”，因此不存在“确定移除策略是否需要来自订阅发起者的批准”这一步骤。对比文件中，接收者退订是自主行为，无需任何第三方（如发送者）的批准。 |
| **技术特征E：** 其中所述移除策略指示在允许移除接收者(38)之前需要订阅发起者(34)的批准<br><br>**《未公开》** | 对比文件全文：未公开任何需要订阅发起者（或任何类似实体）批准的移除策略。 | 与特征D同理，对比文件未公开该技术特征。 |
| **技术特征F：** 并且确定是否允许移除作为所述事件通知的接收者的所述接收者(38)包括：请求订阅发起者(34)批准移除作为事件通知的接收者的所述接收者(38)<br><br>**《未公开》** | 对比文件全文：未公开请求任何实体批准移除接收者的步骤。 | 对比文件中接收者退订后，其他接收者回复全部时，会被通知该退订者，并可以选择“覆盖”（override）退订，将特定消息发送给退订者（[0019]）。但这并非“请求订阅发起者批准移除”。这里的“覆盖”是其他接收者的主动行为，目的是绕过退订，而非在退订发生时请求批准。因此，技术特征F未被公开。 |
| **技术特征G：** 以及一旦接收到来自订阅发起者(34)的批准，确定允许移除作为事件通知的接收者的所述接收者(38)<br><br>**《未公开》** | 对比文件全文：未公开接收“订阅发起者”批准的逻辑。 | 对比文件不存在“订阅发起者批准”这一环节。 |
| **技术特征H：** 一旦确定允许移除作为事件通知的接收者的所述接收者(38)，移除作为事件通知的接收者的所述接收者(38)<br><br>**《直接公开》** | 对比文件[0019]:“...when a recipient unsubscribes from an on-going email thread ... the email will not be delivered into the recipient's box ... the recipient's email server continues to monitor for any incoming mail on the thread ... and holds the email.”<br><br>对比文件[0020]:“Subsequently, in recipient E 112 unsubscribes from the thread 116 with the “Machine Problem” subject matter.” | 尽管对比文件中“确定允许移除”的逻辑（基于移除策略）未被公开，但一旦接收者发起退订，系统（邮件服务器）会执行移除操作（典型表现为不再将后续线程的消息投递到其收件箱）。这个执行移除的结果与目标专利是相同的。因此，对比文件公开了“当确定允许移除后，执行移除”这一最终动作。 |
| **技术特征I：** 还包括：一旦确定不允许移除作为所述事件通知的接收者的所述接收者(38)，拒绝移除作为所述事件通知的接收者的所述接收者(38)<br><br>**《未公开》** | 对比文件全文：未公开任何“拒绝移除”的情况。在对比文件中，接收者的退订请求是直接被接受的。 | 对比文件不存在“确定不允许移除”的情形或步骤，因此不存在“拒绝移除”的响应。 |
| **技术特征J：** 其中所述移除策略指示在允许移除所述接收者(38)之前是否需要所述订阅发起者(34)的批准。<br><br>**《未公开》** | 对比文件全文：未公开移除策略及订阅发起者批准的概念。 | 与特征C、D、E的分析一致，未被公开。 |
| **技术特征K：** 其中所述移除策略指示在允许移除所述接收者(38)之前不需要所述订阅发起者(34)的批准，并且确定是否允许移除作为所述事件通知的接收者的所述接收者(38)包括：在没有来自订阅发起者(34)的输入的情况下，确定是否允许移除作为事件通知的接收者的所述接收者(38)。<br><br>**《隐含公开》** | 对比文件[0019]:“When a recipient unsubscribes from an on-going email thread ... the email will not be delivered into the recipient's box ... the recipient's email server continues to monitor for any incoming mail on the thread ... and holds the email.”<br><br>对比文件[0020]:“Subsequently, in recipient E 112 unsubscribes from the thread 116 with the “Machine Problem” subject matter.” | 目标专利的该特征描述了移除策略的一种具体情形：不需要订阅发起者批准，实体自主决定是否允许移除。对比文件中，接收者的退订行为是自主的，系统（邮件服务器）直接接受该请求，并没有请求任何第三方（如发送者）的批准。这实质上等同于“在没有来自订阅发起者的输入的情况下，确定允许移除”。尽管对比文件没有明确地定义这个“移除策略”，但系统的行为模式（即接收者退订-系统接受）完全符合该特征所描述的场景。因此，可以合理地推断出，对比文件隐含地包含了该技术特征所示的操作模式。 |
| **技术特征L：** 其中，所述移除策略包括在允许移除作为事件通知的接收者的所述接收者(38)之前必须满足的一个或多个定义的标准。<br><br>**《隐含公开》** | 对比文件[0019]:“...the recipient's email server continues to monitor for any incoming mail on the thread (attributes are the email subject and the email parties) and holds the email.”<br><br>对比文件[0020]:“...the server handling recipient E's messages 118 will filter for messages with the “Machine Problem” subject matter, as well as sender 100 and recipients 104, 106, 108, 110, and .” | 目标专利的该特征定义了在允许移除前需要满足的“标准”。对比文件中，接收者退订后，其邮件服务器会基于特定标准（如邮件主题“Machine Problem”和参与方“sender 100 and recipients...”）来过滤后续邮件。虽然在对比文件中，这些标准是用在接收者已退订后“如何识别并处理属于该线程的邮件”，而不是用在“决定是否允许其退订”这一判断上。然而，这些标准（邮件主题、参与方）本质上是系统对“被移除的接收者”的后续操作进行定义的条件。对于本领域技术人员而言，对比文件至少公开了“当接收者请求移除后，系统会应用特定的标准来处理与该接收者相关的后续通知”，这揭示了“标准在管理通知流中扮演重要角色”这一思路。尽管情景不完全一致，但基于对比文件公开了“基于标准处理已退订者的通知”，可以合理推断出，在更宽泛的上下文中，这种标准的概念可以用于决定是否允许退订本身。因此，倾向于将其认定为隐含公开。 |
| **技术特征M：** 其中所述一个或多个确定的标准包括以下中的至少一个：事件发生的一天中的时间和接收者(38)的地理位置。<br><br>**《未公开》** | 对比文件全文：未提及“一天中的时间”或“地理位置”作为任何判断标准。所述标准仅为“邮件主题”和“邮件参与方”。 | 对比文件未公开基于时间或地理位置的标准。 |
| **技术特征N：** 其中，所述接收者(38)的移除策略还包括：用于将所述接收者(38)自动添加回来作为所述事件通知的接收者的一个或多个标准，并且所述方法还包括：在移除作为事件通知的接收者的所述接收者(38)之后，一旦确定满足用于将所述接收者(38)自动添加回来作为所述事件通知的接收者的所述一个或多个标准，将所述接收者(38)添加回来作为所述事件通知的接收者。<br><br>**《未公开》** | 对比文件[0019]:“If the current replier/sender chooses to override the un-subscription, the override is only good for this one email in the thread, and the un-subscription will still be in place for the remainder of the thread.”<br><br>对比文件[0022]:“In case 3, recipient E's message server 118 informs recipient E 112 that recipient B 106 has requested to override the un-subscription, and provides recipient E 112 with the option to accept or reject the override.” | 对比文件公开了“覆盖”（override）机制：其他接收者可以单次性地将一个消息发送给已退订者，但退订状态依然有效。这并非“自动添加回来”。对比文件也公开了退订者可以“接受覆盖”（accept override），这更像是手动允许一条消息，而非“自动添加回来”作为常规接收者。不存在基于预定义标准自动将已移除的接收者重新添加回来的机制。因此，技术特征N未被公开。 |
| **技术特征O：** 其中所述一个或多个接收者(38)包括多个接收者(38)，并且针对所述多个接收者(38)中的至少两个接收者中的每一个定义单独的移除策略。<br><br>**《未公开》** | 对比文件全文：未公开针对不同接收者定义不同“移除策略”的概念。所有接收者都遵循相同的退订处理逻辑。 | 对比文件未公开该特征。 |
| **技术特征P：** 其中所述一个或多个接收者(38)包括多个接收者(38)，并且所述移除策略是针对所述多个接收者(38)的全部或子集定义的公共移除策略。<br><br>**《未公开》** | 对比文件全文：未公开“移除策略”的概念，更未公开公共策略。 | 对比文件未公开该特征。 |
| **技术特征Q：** 还包括：在向接收者(38)发送所述通知之前，基于接收者(38)的通知策略确定是否要向接收者(38)发送所述通知<br><br>**《未公开》** | 对比文件[0019]:“...the recipient's email server continues to monitor for any incoming mail on the thread ... and holds the email.”<br><br>对比文件[0022]:“...the message sent by recipient B 106 is held in recipient E's message server 118, which places a notification in E's message box that recipient B 106 has requested that their particular message be read by recipient E 112.” | 目标专利的“通知策略”是在发送通知前，基于预定义规则（如时间、位置）决定是否向特定接收者发送。对比文件中，退订后，系统会“保留”（hold）消息，而非基于一个主动的策略来决定“是否发送”。虽然对比文件有“覆盖”机制，但这并非“通知策略”，而是在接收者已退订后，其他发件人的主动行为。对比文件不存在一个在每次发送通知前都应用的、用于判断是否发送给特定接收者的策略。因此，技术特征Q未被公开。 |
| **技术特征R：** 向接收者(38)发送所述通知包括：一旦基于所述接收者(38)的通知策略确定要将通知发送给所述接收者(38)，向所述接收者(38)发送所述通知。<br><br>**《未公开》** | 对比文件全文：未公开基于通知策略来确定是否发送通知。 | 基于技术特征Q的分析，该特征未被公开。 |
| **技术特征S：** 其中，所述接收者(38)的所述通知策略基于一个或多个定义的标准。<br><br>**《未公开》** | 对比文件全文：未公开通知策略及其标准。 | 基于技术特征Q的分析，该特征未被公开。 |
| **技术特征T：** 其中所述一个或多个定义的标准包括以下中的至少一个：一天中的时间和接收者(38)的地理位置。<br><br>**《未公开》** | 对比文件全文：未公开基于时间或地理位置的标准。 | 对比文件未公开该特征。 |
| **技术特征U：** 还包括：在向所述一个或多个接收者(38)发送所述事件的通知之前：从所述订阅发起者(34)接收对所述事件的通知的订阅，其中，所述订阅是针对所述一个或多个接收者(38)的对所述事件的通知的订阅，并且所述接收者(38)的移除策略与所述订阅相关联。<br><br>**《未公开》** | 对比文件[0020]:“In FIG. 1A a sender 100 sends a message 102 with a subject of “Machine Problems” to five recipients (A, B, C, D, E) 104, 106, 108, 110, 112.” | 目标专利的“订阅”是核心概念，订阅发起者为其他接收者订阅事件通知。对比文件中，发送者是直接发送消息，没有“订阅”这一层。接收者收到消息是作为消息的收件人，而不是作为一个“订阅”的受益者。因此，对比文件不存在“从订阅发起者接收订阅”这一步骤。技术特征U未被公开。 |
| **技术特征V：** 还包括：接收创建包括所述一个或多个接收者(38)的组(42)的请求<br><br>**《未公开》** | 对比文件全文：未公开创建接收者组的请求。 | 对比文件的消息是发送给一个邮件列表或多位收件人，但整个流程中不存在一个动态创建的“组”的抽象概念，也不涉及创建组的请求。 |
| **技术特征W：** 用针对所述组(42)的组标识符来响应创建组(42)的所述请求<br><br>**《未公开》** | 对比文件全文：未公开组标识符。 | 对比文件未公开该特征。 |
| **技术特征X：** 接收具有作为所述通知的接收者(38)的标识符的所述组标识符的所述事件的通知<br><br>**《未公开》** | 对比文件全文：未公开发送给组标识符的通知。 | 对比文件未公开该特征。 |
| **技术特征Y：** 其中，向所述一个或多个接收者(38)发送所述事件的通知包括：响应于接收具有作为所述通知的接收者(38)的所述组标识符的标识符的所述事件的通知，向所述组(42)中的所述一个或多个接收者(38)发送所述事件的通知。<br><br>**《未公开》** | 对比文件全文：未公开通过组标识符向组内成员分发通知。 | 对比文件未公开该特征。 |
| **技术特征Z：** 其中，发送给所述组(42)中的所述一个或多个接收者(38)的所述事件的通知包括所述组标识符。<br><br>**《未公开》** | 对比文件全文：未公开通知中包含组标识符。 | 对比文件未公开该特征。 |
### 结论与最终代码
根据以上严谨的比对和论述，对比文件US20080098071A1直接公开了目标专利权利要求的**技术特征B和技术特征H**，隐含公开了**技术特征K和技术特征L**。其余技术特征（A, C, D, E, F, G, I, J, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z）未被对比文件直接或隐含公开。
<<<B>>>,<<<H>>>,<<<k>>>,<<<l>>>