好的，作为一名资深专利代理师，我将严格遵循您的要求，对目标专利的权利要求技术与对比文件进行逐一比对和评估。
请在回答的开始明确对比文件的名称：2016-07-21_US2016211949A_发明申请_US20160211949A1 METHOD FOR TRANSMITTING AND RECEIVING UPLINK_DOWNLINK DATA WITH MTC DEVICE和目标专利的名称：1131具有重复的配置的ULCN114531938B以及本次调用的模型名称。
**对比文件名称：** US20160211949A1 METHOD FOR TRANSMITTING AND RECEIVING UPLINK_DOWNLINK DATA WITH MTC DEVICE
**目标专利名称：** CN114531938B 具有重复的配置的UL
**本次调用的模型名称：** 未提供，假定为通用大语言模型
以下是根据您的要求创建的特征比对表格及详细分析。
### 特征比对表格
| 技术特征描述及公开性判断 | 对比文件原文引用 (中文翻译) | 公开性论述 |
| **技术特征A：** 接收(700)配置数量的重复 <br> **《直接公开》** | [0013] “...determining a repetition number of PUSCH including the same uplink data...” (确定包括相同上行链路数据的PUSCH的重复次数) <br> [0016] “The information on the repetition number of PUSCH may be included in a redundancy version field in a PDCCH.” (关于PUSCH重复次数的信息可以被包括在PDCCH中的冗余版本字段中。) <br> [0190] “A BS may deliver information that represents a count that the PDSCH is repeated within a bundle of PDSCHs which is retransmitted... to an MTC device through a PDCCH.” (BS可以通过PDCCH向MTC设备传递表示在重传的PDSCH束内PDSCH被重复的计数的信息。) | 对比文件明确公开了“重复次数”（repetition number）这一概念，并指出该信息可以通过PDCCH信令（包括RV字段）从基站（BS）接收。目标专利的技术特征A是“接收配置数量的重复”，其本质是从网络侧获取一个表示重复次数的配置参数。对比文件中的“determining a repetition number”的“determining”对于UE而言，即意味着从接收到的信令中获知或确定该次数。此外，对比文件多处提及“重复次数”的确定或接收，与本特征A高度对应。因此，该特征被对比文件直接公开。 |
| **技术特征B：** 跨与所述配置数量的重复相等数量的连续物理上行链路共享信道PUSCH重复(702)与物理上行链路共享信道PUSCH传输对应的传输块TB <br> **《隐含公开》** | [0013] “...transmitting initially a bundle of repeated physical uplink shared channels (PUSCHs) including same uplink data to a base station on a plurality of uplink subframes...” (在多个上行子帧上向基站初始传输包括相同上行链路数据的重复的物理上行链路共享信道(PUSCH)束。) <br> [0163] “...the MTC device 100 may retransmit the bundle of repeated PUSCHs to the BS 200.” (MTC设备100可以向BS 200重传重复的PUSCH束。) <br> [0198] “an MTC device initially transmits a bundle of PUSCHs made by identical uplink data, that is, PUSCHs being repeated on a plurality of subframes to a BS.” (MTC设备在多个子帧上向BS初始传输由相同上行链路数据构成的PUSCH束，即被重复的PUSCH。) | 对比文件明确公开了“PUSCH束”（bundle of PUSCHs）的概念，该束包含多个重复的PUSCH，每个PUSCH携带相同的上行数据。虽然对比文件没有直接使用“连续PUSCH”的措辞，但“on a plurality of uplink subframes”在LTE的上下文中通常指示连续的子帧。此外，对比文件将初始传输和重传的“束”的大小称为“重复次数”，这意味着UE会按照所确定的次数重复传输该PUSCH束。目标专利的TB重复是跨与配置数量相等的连续PUSCH，对比文件中的“束”内的PUSCH重复数量也是由重复次数决定的，且传输是跨多个子帧（可理解为连续PUSCH）进行的。虽然对比文件主要针对MTC场景，但其核心思想——通过跨多个连续子帧重复PUSCH来传输相同数据——与技术特征B高度一致。本领域技术人员能够合理推断出这种对应关系。因此，该特征被对比文件隐含公开。 |
| **技术特征C：** 其中，所述连续PUSCH中的所有被配置为具有相同的长度并且属于一个或多个配置的准许‑PUSCH CG‑PUSCH传输周期 <br> **《未公开》** | 无直接对应内容。对比文件基于LTE系统，主要讨论MTC覆盖增强下的子帧捆绑（subframe bundling），未明确引入NR中的“配置的准许-PUSCH (CG-PUSCH) 传输周期”这一概念。 | 对比文件描述了在多个子帧上的重复传输（捆绑），但没有定义或提及这些子帧属于“配置的准许-PUSCH (CG-PUSCH) 传输周期”。CG-PUSCH是NR中特定的配置上行资源机制，涉及RRC配置的周期性资源，这与LTE中的动态调度或半持续调度（SPS）在概念和实现上均有区别。对比文件未公开任何关于CG-PUSCH传输周期的内容，也没有公开PUSCH重复与特定配置周期之间的从属关系。因此，该技术特征未被对比文件公开。 |
| **技术特征D：** 其中两个相邻的PUSCH时机不被时间偏移分开 <br> **《未公开》** | 无直接或隐含公开。 | 对比文件未讨论PUSCH传输时机之间的时间关系，特别是没有提及“不被时间偏移分开”。对比文件中的“bundle”通常指在连续子帧上进行传输，这是一个默认的隐含特征，但并未作为一项需要特别指出的限制条件进行公开。目标专利的该特征旨在明确“连续”的具体含义，即排除存在时间间隔的情况。对比文件未对此进行任何教导或暗示。因此，该技术特征未被对比文件公开。 |
| **技术特征E：** 其中： <br> **《未公开》** | 无。 | 此为引导性语句，不构成实质技术特征。 |
| **技术特征F：** 接收(700)所述配置数量的重复进一步包括接收冗余版本RV <br> **《直接公开》** | [0016] “The information on the repetition number of PUSCH may be included in a redundancy version field in a PDCCH.” (关于PUSCH重复次数的信息可以被包括在PDCCH中的冗余版本字段中。) <br> [0174] “...a RV value that is used by one PDSCH bundle may be notified to an MTC device through DCI.” (一个PDSCH束使用的RV值可以通过DCI通知给MTC设备。) | 对比文件明确公开了通过PDCCH（包含DCI）中的RV字段来携带与重复传输相关的信息。虽然对比文件主要示例是RV字段携带重复次数，但该公开内容明确教导了接收重复配置（如重复次数）时可以伴随或通过接收RV信息来实现。目标专利的特征F是“接收配置数量的重复进一步包括接收RV”，这意味着接收重复配置的步骤与接收RV相关联。对比文件将重复次数信息包含在RV字段中，本领域技术人员可以直接地、毫无疑义地认识到，接收该配置（重复次数）必然也涉及接收或处理该字段，从而获取了RV或与RV相关的信息。因此，该特征被对比文件直接公开。 |
| **技术特征G：** 重复(702)与所述PUSCH传输对应的所述TB包括跨属于一个CG‑PUSCH传输周期的所述连续PUSCH重复与所述PUSCH传输对应的所述TB。 <br> **《未公开》** | 无直接对应内容。 | 同技术特征C，对比文件未引入NR中的“CG-PUSCH传输周期”概念。因此，无法公开“跨属于一个CG-PUSCH传输周期的连续PUSCH进行重复”这一特征。该技术特征未被对比文件公开。 |
| **技术特征H：** 其中， <br> **《未公开》** | 无。 | 此为引导性语句，不构成实质技术特征。 |
| **技术特征I：** 重复(702)与所述PUSCH传输对应的所述TB包括： <br> **《未公开》** | 无。 | 此为引导性语句，不构成实质技术特征。 |
| **技术特征J：** 根据所述RV， <br> **《隐含公开》** | [0171] “...RV0, RV1, RV2 and RV3 are applied as a cyclic shift for each subframe.” (RV0, RV1, RV2和RV3作为循环移位应用于每个子帧。) <br> [0178] “...RV0, RV1, RV2 and RV3 may be repeatedly used as cycle shift as a RV value for each subframe.” (RV0, RV1, RV2和RV3可以作为RV值在每个子帧中作为循环移位重复使用。) | 对比文件明确描述了在重复传输（捆绑）中，会根据一定的RV序列（如循环移位）来应用不同的RV值。这意味着重复传输的进行是“根据RV”的。虽然对比文件没有使用“根据所述RV”这样的表述，但其公开的捆绑传输机制本身就隐含了这种依赖关系：传输的冗余版本是根据某个RV序列或模式来确定的。本领域技术人员可以合理推断出，UE在跨子帧重复TB时，会依据所知的RV信息（序列或起始值）来确定每个重复的RV版本。因此，该特征被对比文件隐含公开。 |
| **技术特征K：** 在所述CG‑PUSCH传输周期中的任何时机处开始(702‑1)所述TB的初始传输， <br> **《未公开》** | 无直接对应内容。 | 同技术特征C和G，对比文件未引入NR中的“CG-PUSCH传输周期”概念。因此，无法公开“在CG-PUSCH传输周期中的任何时机处开始”这一特征。该技术特征未被对比文件公开。 |
| **技术特征L：** 后面是所述配置数量的重复。 <br> **《直接公开》** | [0013] “...determining a repetition number of PUSCH including the same uplink data... retransmitting the bundle of PUSCHs, which are repeated by the determined repetition number on a plurality of uplink subframes...” (确定重复次数...在多个上行子帧上重传由所确定的重复次数重复的PUSCH束。) | 对比文件明确公开了在初始传输（或重传）之后，会按照所确定的“重复次数”进行后续的重复传输。其描述的“bundle of repeated PUSCHs”本身即包含了初始传输和后续的（重复次数-1）次重复。目标专利的“后面是所述配置数量的重复”正是描述了这种在首次传输后接着进行配置次数重复的过程。因此，该特征被对比文件直接公开。 |
| **技术特征M：** 其中， <br> **《未公开》** | 无。 | 此为引导性语句，不构成实质技术特征。 |
| **技术特征N：** 所述TB的所述初始传输对应于RV值零0。 <br> **《直接公开》** | [0171] “...it may be that RV0=0...” (可以是RV0=0...) <br> [0174] “...when the RV value is applied within PDSCH bundle 0 that is initially transmitted PDSCH bundle in an order of RV0, RV1, RV2 and RV3 (at the moment, RV0=0, RV1=2, RV2=3 and RV3=1)...” (当RV值被应用于初始传输的PDSCH束0时，顺序为RV0， RV1， RV2和RV3（此时，RV0=0， RV1=2， RV2=3和RV3=1）...) | 对比文件明确教导了在初始传输的束（如PDSCH bundle 0）开始时，所使用的第一个RV值为0。这直接对应于目标专利中“TB的初始传输对应于RV值零0”的特征。尽管该示例针对PDSCH，但本领域技术人员知晓RV的概念和初始传输使用RV0的原则对于PUSCH同样适用。对比文件也明确将RV0定义为0。因此，该特征被对比文件直接公开。 |
| **技术特征O：** 其中， <br> **《未公开》** | 无。 | 此为引导性语句，不构成实质技术特征。 |
| **技术特征P：** 重复(702)与所述PUSCH传输对应的所述TB进一步包括： <br> **《未公开》** | 无。 | 此为引导性语句，不构成实质技术特征。 |
| **技术特征Q：** 当借助于无线电资源控制RRC信令和层1L1信令中的至少一个来发信号通知配置的准许并且重复的所述配置数量大于1时， <br> **《未公开》** | 无直接对应内容。 | 对比文件主要讨论通过PDCCH（L1信令）动态调度或触发MTC设备的重复传输，未明确涉及NR中通过RRC信令半静态配置的“配置的准许”机制。对比文件中的重复次数信息可以通过PDCCH（L1）指示，但“配置的准许”（Configured Grant）是NR中一种特定的、区别于动态调度的资源配置方式。对比文件未公开任何关于“配置的准许”与重复结合使用的场景，也未公开通过RRC或RRC+L1信令来触发此种模式。因此，该技术特征未被对比文件公开。 |
| **技术特征R：** 重复(702‑2)所述TB。 <br> **《隐含公开》** | [0013] “...transmitting initially a bundle of repeated physical uplink shared channels (PUSCHs) including same uplink data...” (初始传输包括相同上行链路数据的重复的PUSCH束) <br> [0163] “...the MTC device 100 may retransmit the bundle of repeated PUSCHs...” (MTC设备100可以重传重复的PUSCH束) | 对比文件的核心内容即是重复传输TB。其描述的初始传输和重传都是以“束”（bundle）的形式进行的，束内包含多个重复的PUSCH。当满足一定条件（如接收到NACK）时，MTC设备会进行重复传输。虽然触发条件不同，但“重复TB”这一动作本身是被对比文件广泛公开的。因此，该特征被对比文件隐含公开。 |
| **技术特征S：** 其中， <br> **《未公开》** | 无。 | 此为引导性语句，不构成实质技术特征。 |
| **技术特征T：** 重复(702)与所述PUSCH传输对应的所述TB进一步包括： <br> **《未公开》** | 无。 | 此为引导性语句，不构成实质技术特征。 |
| **技术特征U：** 响应于满足下列条件中的一个， <br> **《未公开》** | 无。 | 对比文件未公开基于以下W、X、Y所列条件列表来终止重复。其HARQ重传是基于NACK反馈，这与目标专利的终止条件不同。 |
| **技术特征V：** 终止(702‑3)与所述PUSCH传输对应的所述TB的所述重复： <br> **《未公开》** | 无。 | 对比文件未明确讨论在何种条件下“终止”重复。其操作流程是完成K次重复后自然结束，或者进行重传。目标专利定义了明确的终止条件，这与对比文件的行为模式不同。 |
| **技术特征W：** 重复与所述PUSCH传输对应的所述TB达重复的所述配置数量 <br> **《隐含公开》** | [0013] “...retransmitting the bundle of PUSCHs, which are repeated by the determined repetition number on a plurality of uplink subframes...” (在多个上行子帧上重传由所确定的重复次数重复的PUSCH束) | 对比文件的所有重复传输操作都隐含地基于一个前提：完成所确定的“重复次数”次传输。无论是初始传输还是重传，UE都会按照配置的次数进行重复。因此，“重复达重复的配置数量”是完成重复的隐含条件。虽然对比文件没有明确将其列为一个“终止条件”，但本领域技术人员可以合理推断，当UE完成了配置数量的重复后，该次传输过程自然终止。因此，该特征被对比文件隐含公开。 |
| **技术特征X：** 接收上行链路准许以用于在所述CG‑PUSCH传输周期内调度所述TB <br> **《未公开》** | 无直接对应内容。 | 对比文件未引入“CG-PUSCH传输周期”概念。虽然对比文件描述了通过PDCCH（UL grant）调度重传，但并未将其作为在配置的重复过程中提前终止重复的“条件”之一，也未将此UL grant与“CG-PUSCH传输周期”关联。目标专利的特征X是作为一个特定的、用于提前终止CG-PUSCH重复的条件。对比文件未公开此特定用途。因此，该特征未被对比文件公开。 |
| **技术特征Y：** 接收对所述TB的显式确认。 <br> **《未公开》** | 无直接对应内容。 | 对比文件详细描述了HARQ操作，其中ACK/NACK是响应于整个“束”（bundle）的。对比文件并未教导将接收到的对TB的“显式确认”（如ACK）作为提前终止正在进行的重复传输的条件。其HARQ过程是完成一次捆绑传输后，等待对本次捆绑的反馈。目标专利的特征Y是将早期接收到的ACK作为终止后续重复的触发条件，这与对比文件的行为模式不同。因此，该特征未被对比文件公开。 |
### 结论
根据以上分析，对比文件直接或隐含公开了部分技术特征。
<<<A>>><<<F>>><<<L>>><<<N>>>
<<<b>>><<<j>>><<<r>>><<<w>>>