一种用户设备UE，其包括： 一个或多个非暂时性计算机可读介质，所述一个或多个非暂时性计算机可读介质具有包含在其上的计算机可执行指令；以及至少一个处理器，所述至少一个处理器耦接到所述一个或多个非暂时性计算机可读介质，所述至少一个处理器经配置以执行所述计算机可执行指令以：由所述UE的媒体访问控制MAC实体从下层接收用于所有上行链路UL传输的先听后说LBT失败指示； 当所述MAC实体接收到所述LBT失败指示时，增加LBT失败计数器； 当所述LBT失败计数器大于或等于阈值时，判定LBT失败事件发生；并且执行重建程序，以响应确定主小区PCell发生了LBT失败事件。

CN113273269B 权利要求1：截止日前英文专利检索结果

一、总体结论

我以公开日严格早于2019年1月9日为截止标准，对Google Patents进行了多轮关键词、分类号、引证链及相似文本检索。

本轮检索的结论是：

尚未检出一份在同一实施方式中，无歧义地覆盖权利要求1全部关键技术链条的截止日前英文专利公开文本。

因此，现有英文证据更适合用于构建创造性组合攻击，而不是仅凭一份文献主张权利要求1整体不具新颖性。

最有价值的证据组合是：

US20180124831A1 + US20170231005A1 + US20120281548A1

其中：

• US20180124831A1负责“PHY/下层向MAC报告LBT失败”；

• US20170231005A1负责“针对任意上行物理信道的LBT失败计数及阈值”；

• US20120281548A1负责“UL PCell随机接入失败触发RRC连接重建”。

另一条文献数量较少、但因果关系稍弱的路线是：

US20180048498A1 + US20120281548A1，必要时再以US20170231005A1补强。

二、权利要求1的关键技术特征

根据CN113273269B权利要求1，真正需要先前技术覆盖的核心链条可以拆解为：

其中F1属于常规硬件配置，实质争议集中在F2—F5。(谷歌专利)

三、核心英文专利文献

1. US20180124831A1

Dual Connectivity Scheduling Request for Wireless Network and Wireless Device
公开日：2018年5月3日

对权利要求1的贡献

该文献是本轮检索中，对“下层向MAC报告LBT失败”公开得最直接的英文文献：

• MAC指示物理层发送Scheduling Request；

• 物理层在发送SR之前执行LBT；

• 如果LBT失败，物理层向MAC告知SR传输的LBT失败；

• MAC侧维护SR计数器或SR-LBT计数器；

• 计数器达到预定最大值后，SR过程被视为未成功完成，并可转入随机接入程序。

这能够较强地覆盖或启示：

• F2中的“lower layer → MAC LBT failure indication”；

• F3、F4中的MAC计数器与失败阈值；

• LBT持续失败后进入进一步恢复程序的技术思路。(谷歌专利)

主要缺口

1. 明确实施例主要针对Scheduling Request/PUCCH，不是逐字公开“全部上行传输”；

2. 个别实施方式中计数器的更新并非严格限定为“仅在接收到失败指示后递增”；

3. 达到阈值后的处理是转入随机接入，不是直接公开“PCell发生LBT失败事件后执行RRC重建”。

评价

这是权利要求1最适合作为最接近现有技术的文献，但不宜单独主张完整破坏新颖性。

2. US20170231005A1

Channel Access Counter in a Wireless Network
公开日：2017年8月10日

对权利要求1的贡献

该文献对“LBT失败计数器及阈值”公开非常强：

• 上行传输尝试因LBT不成功而失败时，更新或递增一个或多个计数器；

• 可为特定物理信道设置计数器，例如PUSCH、PRACH；

• 也可以采用一个共同计数器，在任一上行物理信道上的传输尝试因LBT失败时递增；

• 当计数器达到配置值，例如4次时，产生相应处理或认为随机接入不成功。

因此它是以下特征的最强证据之一：

• F3：LBT失败发生时递增计数；

• F4：计数达到阈值即确定持续失败；

• F2中“all UL transmissions”的宽泛含义，即同一检测或计数机制适用于任意上行物理信道。(谷歌专利)

主要缺口

1. 没有像US20180124831A1那样明确写出“PHY向MAC提供LBT失败指示”；

2. 没有公开PCell发生该事件后进行RRC连接重建。

评价

这是补足US20180124831A1“仅针对SR，而不是全部上行传输”缺口的首选组合文献。

3. US20180048498A1

Uplink Operation for LTE in an Unlicensed Band
公开日：2018年2月15日

对权利要求1的贡献

该文献对“PHY向MAC反馈未传输状态、多个上行传输的LBT失败记录以及失败次数阈值”公开较全面：

• 物理层可以向MAC提供TX-NACK，说明请求发送的MAC PDU或Transport Block没有被发送；

• 未发送原因可包括信道忙、LBT或CCA失败；

• UE可以维护因信道忙而未传输的次数；

• 失败次数超过配置阈值时进行上报或其他处理；

• 文献还提到可以提供“所有因未获取信道而失败的上行传输”的列表；

• 所涉及的上行内容包括TB、MAC PDU、MAC CE等，范围比单独的SR更广。

它可以用于支持：

• F2的PHY/下层到MAC的失败反馈；

• “all UL transmissions”的广义覆盖；

• F3、F4中的LBT/CCA失败次数和阈值。(谷歌专利)

主要缺口

1. 物理层提供的是较通用的TX-NACK，并非始终被明确命名为专用的“LBT failure indication”；

2. “PHY向MAC发送TX-NACK”与“收到该TX-NACK后递增专门LBT失败计数器”分别出现在相关描述中，二者之间的直接因果关系没有像目标权利要求那样逐字连写；

3. 没有公开PCell触发RRC连接重建。

评价

这是覆盖“全部上行传输”范围最有价值的文献之一。它适合与US20120281548A1形成较简洁的两文献组合，但在“接收指示即递增计数器”这一因果关系上，弱于US20180124831A1与US20170231005A1的组合。

4. US20120281548A1

SCell Radio Link Monitoring and Radio Link Failure Handling
公开日：2012年11月8日

对权利要求1的贡献

该文献是本轮检索中，覆盖F5最直接的英文专利文献。其明确说明：

“Random access failure on UL PCELL triggers RRC connection reestablishment.”

即：

• UE可基于MAC提供的随机接入问题指示确定无线链路失败；

• UL PCell上的随机接入失败触发RRC连接重建。

它直接证明，在截止日前，“PCell上行接入持续失败 → RRC连接重建”已是已知恢复机制。(谷歌专利)

主要缺口

该文献不涉及LBT失败计数器，也没有公开下层向MAC提供LBT失败指示。

评价

这是补足权利要求1最后一步“PCell失败事件 → 重建程序”的首选文献。尤其适合与US20180124831A1配合，因为后者已经把连续LBT失败与随机接入程序连接起来。

四、辅助英文专利文献

5. WO2017144514A1

Radio Link Monitoring in Listen-Before-Talk Communications
公开日：2017年8月31日

该文献讨论了在非授权载波上运行的PCell，以及因LBT和干扰造成的链路监测问题。其公开：

• PCell可以工作在非授权载波；

• 物理层检测PCell接收问题，并向RRC提供out-of-sync指示；

• 连续达到N310次指示后启动T310；

• T310到期后，UE启动连接重建。

因此，该文献证明在非授权PCell环境中，基于连续下层失败指示和阈值确定链路故障、继而重建连接的整体思路在截止日前已经存在。(Google)

局限在于：它主要涉及下行无线链路监测和PHY向RRC提供out-of-sync指示，而不是上行LBT失败及PHY向MAC提供指示。

6. US20180184362A1

Licensed Assisted Access Radio Link Failure
公开日：2018年6月28日

该文献针对LAA及非授权载波的无线链路失败处理，公开了：

• LBT不成功可能造成控制信道无法接收并最终导致无线链路失败；

• 对PCell来自下层的连续out-of-sync指示进行计数；

• 满足N310/T310条件后执行RRC连接重建；

• 相关场景包括LAA、小区组及独立非授权载波操作。

该文献可辅助证明“LBT环境中的连续失败事件 → PCell无线链路失败 → 连接重建”这一恢复框架。(谷歌专利)

其不足与WO2017144514A1类似：失败源主要是下行控制信道或无线链路质量，不是目标权利要求所要求的“全部上行传输的LBT失败指示”。

7. WO2017136458A2

Listen-Before-Talk Failure During a Random Access Procedure
公开日：2017年8月10日

该文献专门讨论随机接入过程中的LBT失败，包括：

• LBT失败可能阻止PRACH前导码发送；

• LBT失败也可能阻止Msg3或其他上行授权传输；

• UE可跳过因LBT失败而无法进行的上行传输；

• MAC侧继续执行竞争解决定时器、随机接入窗口等程序。

它能够辅助建立：

持续LBT失败会直接导致随机接入过程不能成功完成。

该文献因而可作为US20180124831A1与US20120281548A1之间的技术桥梁。(谷歌专利)

其不足是没有明确公开一个专用的持续LBT失败计数器，也没有直接公开PCell RRC重建。

五、按权利要求特征确定首选证据

六、建议的无效组合路线

路线一：覆盖最稳的三文献组合

最接近现有技术

US20180124831A1

该文献已经给出：

• PHY执行LBT；

• PHY向MAC报告LBT失败；

• MAC维护LBT相关计数器；

• 达到最大值后认定SR过程失败并转入随机接入。

区别特征一：“全部上行传输”

以US20170231005A1补足：

• 共同计数器可适用于任一上行物理信道；

• PUSCH、PRACH等上行信道因LBT失败均可更新计数器；

• 达到配置阈值后确定接入失败。

区别特征二：“PCell发生事件后执行重建”

以US20120281548A1补足：

• UL PCell随机接入失败触发RRC连接重建。

组合逻辑

US20180124831A1本身已经把“达到LBT失败阈值”与“启动随机接入”连接起来；US20120281548A1又明确说明UL PCell随机接入失败会触发RRC重建。US20170231005A1则把检测范围从特定SR扩展至任意上行物理信道。

据此可形成以下完整技术链：

下层检测所有类型的上行LBT失败
→ 向MAC报告
→ MAC累计失败次数
→ 达到阈值确定持续失败
→ 在PCell上进入或无法完成随机接入
→ 执行RRC连接重建。

这是一项基于文献共同教导得出的创造性组合推论，不是任一文献的单篇直接公开。(谷歌专利)

路线二：文献数量较少的组合

US20180048498A1 + US20120281548A1

US20180048498A1提供：

• PHY向MAC发送未传输指示；

• 因LBT/CCA失败而未传输的统计；

• 失败次数阈值；

• 所有失败上行传输的列表。

US20120281548A1提供：

• UL PCell随机接入失败触发RRC连接重建。

这条路线只需要两份主要文献，但存在一个论证弱点：

US20180048498A1没有特别清楚地把“MAC收到专用LBT失败指示”与“MAC立即递增专用LBT失败计数器”写成一个连续因果步骤。

因此，实际证据组织中适合再引用US20170231005A1，证明“LBT失败发生时递增计数器”本身是明确已知的。(谷歌专利)

路线三：强调非授权PCell/RLF背景

可以采用：

US20180124831A1或US20170231005A1
＋ WO2017144514A1或US20180184362A1

前一组负责上行LBT失败报告、计数和阈值；后一组负责非授权PCell中基于连续下层失败指示确定无线链路故障并执行连接重建。

这条路线的优点是技术场景高度接近非授权频谱PCell；不足是WO2017144514A1和US20180184362A1主要处理下行链路质量或out-of-sync，而不是上行LBT失败，因此通常弱于US20120281548A1作为F5证据。(Google)

七、单篇新颖性判断

最接近单篇文献：US20180124831A1

它同时具有：

• PHY向MAC报告LBT失败；

• MAC侧LBT相关计数器；

• 阈值；

• 达到阈值后进行恢复处理。

但至少仍存在以下明确差异：

1. 主要针对SR，不是明确针对“全部上行传输”；

2. 没有直接公开PCell发生该LBT失败事件；

3. 达到阈值后的动作是随机接入，不是直接执行RRC连接重建。

因此，仅凭该文献主张权利要求1整体不具新颖性，技术证据不够稳固。

US20170231005A1和US20180048498A1也分别缺少明确的PCell重建步骤。因此，基于本轮检索结果，不建议把任何一篇列为无保留的单篇完全覆盖文献。

八、“all UL transmissions”的解释风险

这是权利要求1最可能影响无效结果的限定之一。

解释A：适用于任意类型的上行传输

即无论是PUSCH、PRACH、PUCCH、SR、MAC PDU或TB，只要该上行传输发生LBT失败，都使用同一失败检测或计数机制。

在这种解释下：

• US20170231005A1的“任一物理信道”共同计数器非常有力；

• US20180048498A1的“所有因未获取信道而失败的上行传输列表”也具有较强贡献。(谷歌专利)

解释B：一项汇总指示必须表示“所有上行传输均失败”

即下层提供的是一个代表全部上行传输整体状态的单一指示，而不是对任意一种上行传输均可产生失败指示。

在这种较窄解释下，本轮没有找到一份截止日前英文文献逐字、无歧义公开这一限定。US20170231005A1和US20180048498A1仍有组合价值，但更适合创造性论证，而非单篇新颖性论证。

九、被严格排除的近似文献

以下文献虽然优先权日在截止日前或技术内容接近，但其公开日晚于2019年1月9日，因此没有纳入本次截止日前英文先前技术清单：

• WO2020092359A1：公开日2020年5月7日；

• US10925093B2：授权公开日2021年2月16日；

• US20200221309A1：公开日2020年7月9日。(谷歌专利)

仅有早期优先权日而没有在截止日前向公众公开，通常不能仅凭该优先权书目记录作为本次所要求的公开在先文献使用。

十、重要的中文旁证

CN107770868A

公开日：2018年3月6日

该文献不是英文公开文本，因此没有列入用户要求的英文专利清单。但它具有较强的技术旁证价值：

• 执行LBT；

• LBT失败时更新失败次数；

• 重复执行直到达到预设次数；

• 超过预设次数后触发相应MAC CE或通知处理。

CN113273269B的Google Patents引证信息也列出了该文献。它可用于说明“LBT失败计数—预设阈值—触发处理”的基本机制在截止日前已经公开，但正式英文证据仍应以前述US/WO文献为主。(谷歌专利)

十一、最终优先级

建议按以下顺序组织无效检索证据：

1. US20180124831A1：最接近现有技术，明确PHY向MAC报告LBT失败；

2. US20170231005A1：最强的失败递增、阈值以及任意上行物理信道共同计数；

3. US20120281548A1：最直接的UL PCell失败触发RRC连接重建；

4. US20180048498A1：补强全部上行传输、PHY到MAC反馈及失败次数阈值；

5. WO2017144514A1：非授权PCell、连续下层失败指示与连接重建；

6. US20180184362A1：LAA/RLF场景下的PCell重建；

7. WO2017136458A2：LBT失败导致PRACH、Msg3及随机接入不能成功。

核心无效组合建议：

US20180124831A1
＋ US20170231005A1
＋ US20120281548A1

备选组合：

US20180048498A1
＋ US20120281548A1
＋ US20170231005A1（补强失败指示与计数之间的因果关系）

以上属于先前技术检索和技术特征比对，不是对无效结果的法律保证。正式提交无效请求前，应进一步核对各专利官方公开PDF、具体段落和附图，并结合CN113273269B的审查档案及“all UL transmissions”“re-establishment procedure”的权利要求解释确定最终证据组合。

我针对 CN113273269B 权利要求1，把检索范围限定为 Google Patents 中公开日严格早于 2019-01-09 的日本公开公报（JP/JPWO），又按日文关键词、LBT/UL-LBT、随机接入、PCell、MAC、RRC再确立等路径反复检索了一轮。

先给结论：日本截止日前文献里，最有价值的是 JP2014514821A / JP2015216681A 这一同族，以及 JPWO2016148243A1。前者很强地补“PCell随机接入失败→RRC连接再建立”和“MAC计数达到阈值→随机接入问题”；后者明确公开“UE上行LBT失败”。但目前我仍没有检到一篇截止日前JP公报单独公开“下层→MAC的LBT失败指示 + 专用LBT失败计数器递增 + 达阈值 + PCell重建立”完整链条。

CN113273269B权利要求1本身要求：UE的MAC实体从下层收到针对全部UL传输的LBT失败指示；收到指示时增加LBT失败计数器；计数达到阈值时确定LBT失败事件；并在PCell经历该事件后执行重建程序。Google Patents的授权权利要求1明确如此记载。(谷歌专利)

其中 JP2014514821A 和 JP2015216681A 属于同一基础技术族，正式无效论证时不能把它们当作两项彼此独立的技术启示重复计算。Google Patents显示JP2014514821A公开于2014-06-19，而JP2015216681A公开于2015-12-03。(谷歌专利)

1. JP2014514821A —— 日文证据中最关键的一篇

名称： SCELL無線リンクモニタリングおよび無線リンク障害ハンドリング
申请人： MediaTek
优先权日： 2011-05-03
公开日： 2014-06-19。(谷歌专利)

这篇对CN113273269B权利要求1最后半段非常重要。

Google Patents日文正文明确记载：

• PHY问题可导致RLF；

• MAC层指示随机接入问题时，也认为发生RLF；

• 一旦检测到RLF，UE尝试RRC连接重建；

• 更重要的是，它直接写到：“UL PCELL上のランダムアクセス失敗は、RRC接続再構築のトリガーとなる。” 即“UL PCell上的随机接入失败触发RRC连接重建”。(谷歌专利)

因此它对目标权利要求的F5：

“响应于确定PCell经历LBT失败事件而执行重建程序”

提供了非常强的“PCell UL持续接入失败→RRC重建”桥梁。

它还具有另外一个价值：在同一技术背景中明确说明随机接入故障由MAC层向上层指示，并最终进入RLF/RRC恢复机制。(谷歌专利)

对无效论证的意义

可以把目标专利的区别理解为：

不是传统“随机接入失败”作为PCell故障原因，而是把“持续UL LBT失败”定义成一种新的PCell故障原因。

那么JP2014514821A已经说明：

PCell上行侧出现持续到足以构成随机接入问题的失败 → RLF → RRC重建。

真正剩下需要另一篇现有技术补的是：

“如何把UL LBT失败累计到足以认定故障”。

这就是它和JPWO2016148243A1等LBT文献进行组合的价值。

2. JP2015216681A —— 对“计数+阈值+MAC问题指示”尤其有价值

公开日：2015-12-03。 (谷歌专利)

它与JP2014514821A属于同一基础技术族，但Google Patents中这份日文文本对计数机制写得尤其清楚：

当RACH前导码发送次数超过最大阈值（例如 preambleTransMax）时，MAC层向上层指示随机接入问题，并触发RLF检测。

也就是说它已经公开了：

失败尝试发生
→ 次数累计
→ 达到/超过预设最大阈值
→ MAC向上层指示问题
→ 触发RLF

Google Patents检索结果直接显示：“RACHプリアンブル伝送の回数が最大スレショルド値（例えばpreambleTransMax）を超える場合、MAC層はランダムアクセス問題を上層に示した上で、RFL検出のトリガーとなる。” (谷歌专利)

这跟CN113273269B权利要求1的逻辑架构：

LBT failure indication
→ counter++
→ counter ≥ threshold
→ failure event
→ PCell recovery

在MAC故障检测思想上高度接近。

区别主要是：

• JP2015216681A累计的是RACH前导码发送次数/随机接入失败；

• 目标权利要求累计的是LBT failure indication。

因此这不是单篇新颖性文献，但对“把既有MAC失败计数器的输入由RA失败替换成LBT失败”是否具有创造性，会很有作用。

3. JPWO2016148243A1 —— 截止日前直接出现“UL LBT failure”的强日文文献

名称： ユーザ端末及び基地局
申请人： 京瓷
优先权日： 2015-03-17
公开日： 2018-01-18。(谷歌专利)

这篇是目前这轮日文专利检索中，对权利要求1“上行LBT失败”本身最值得关注的一篇。

该文献明确讨论：

当eNB向多个UE分配连续子帧时，其中一个UE可能经历 LBT失敗。

Google Patents日文正文直接出现：

「一方のUEがLBT失敗を経験し得る。」

也就是说，在2018年1月18日前，日本公开专利中已经明确认识到：

• UE侧执行UL LBT；

• UL传输之前必须先完成LBT；

• LBT失败会导致本次上行发送不能执行；

• 这种UL LBT失败是需要专门解决的UL通信异常事件。(谷歌专利)

它与权利要求1的对应关系

它明显贡献：

• UE；

• UL transmission；

• UE执行LBT；

• UL LBT failure；

• LBT失败使UL传输不能进行。

但没有直接公开：

• PHY/lower layer向MAC发送专门的LBT failure indication；

• MAC收到该指示就增加专用LBT failure counter；

• 专用计数器达到阈值；

• PCell因该LBT failure event直接RRC重建。

所以我把它定为A档组合证据，而不是X文献式单篇破坏证据。

4. JPWO2015174437A1 —— “UL LBT结果→是否执行UL传输”

名称： Radio base station, user terminal and radio communication system
申请人： NTT DOCOMO
优先权日： 2014-05-15
公开日： 2017-04-20。(谷歌专利)

这篇明确公开了UE实施UL LBT。

尤其值得注意的是：

• UE在UL传输之前执行UL LBT；

• LBT_idle 时开始UL数据传输；

• LBT_busy 时不开始UL数据传输；

• 一个LBT结果还能对连续多个UL subframe有效。(谷歌专利)

它因此可以支持权利要求1中的基础技术事实：

下层进行UL发送以前已经具有明确的LBT成功/失败结果，该结果决定UL transmission是否真正发生。

对“all UL transmissions”也有一定贡献，因为文献不是只针对一个随机接入前导码，而是在讨论普通UL数据发送、连续UL subframe及UE的UL LBT行为。(谷歌专利)

但它没有公开LBT失败专用MAC counter，所以强度低于JPWO2016148243A1 + JP2015216681A的组合。

5. JPWO2016117608A1 —— LBT结果的早期日本公开

申请人： NTT DOCOMO
优先权日： 2015-01-21
公开日： 2017-11-24。(谷歌专利)

该文献公开：

• 执行LBT；

• 获得LBT result；

• 根据LBT result决定是否发送信号。

Google Patents同时显示其技术分类包括利用carrier sensing进行无线信道接入。(谷歌专利)

这篇更多用于证明：

“LBT是一个明确产生结果、并依据结果允许/禁止后续发送的检测过程”

在2019-01-09前已经属于成熟公开技术。

不过它主要偏向基站/DL实现，因此在无效权利要求1时我只会把它放在辅助证据位置，不会把它作为主引证。

最值得采用的日文专利组合

目前日本文献中，我认为最好的组合不是三四篇全堆上去，而是：

JPWO2016148243A1 + JP2014514821A / JP2015216681A

其逻辑非常清楚。

第一篇：JPWO2016148243A1

提供：

UE在非授权载波进行上行传输
→ 上行发送之前进行LBT
→ UE可能遭遇UL LBT failure
→ LBT失败导致上行传输无法进行。(谷歌专利)

第二篇：JP2014514821A / JP2015216681A

提供：

MAC侧对上行随机接入失败进行次数/阈值管理
→ 达到最大阈值时MAC指示随机接入问题
→ 形成RLF
→ UL PCell随机接入失败触发RRC连接重建。(谷歌专利)

将两者结合后形成：

UL LBT连续失败
→ 上行传输不能完成
→ 用既有MAC失败计数/阈值机制判断该持续失败
→ 当发生于PCell并达到故障程度
→ RLF/RRC重建。

这和CN113273269B权利要求1的实质链条已经非常接近。

更精细的特征对照

这里最明显的剩余缺口只有一个非常具体的接口限定：

“MAC实体从下层接收针对全部UL transmissions的LBT failure indication，并在收到该indication时递增专用LBT failure counter。”

截至目前这轮Google Patents的JP限定检索，我没有找到2019-01-09以前公开的日本公报把这句话完整、直接地公开出来。

这点很重要，因为后来公开的日本专利恰恰大量出现了几乎逐字相同的机制，例如“物理层→MAC的LBT失败指示、MAC递增LBT counter、达到阈值触发持续LBT failure”；但这些JP公报的公开日均晚于目标截止日，因此我已排除，不能拿来充当2019-01-09以前的JP现有技术。(谷歌专利)

关于JP2014514821A与JP2015216681A的使用方式

二者建议这样处理：

作为核心证据只选其中一份。

我倾向于优先使用 JP2014514821A，因为它公开更早（2014-06-19），而且正文直接给出了：

UL PCell random access failure triggers RRC connection re-establishment. (谷歌专利)

然后可引用同族JP2015216681A的对应段落协助定位“preambleTransMax→MAC random access problem→RLF”机制，但不把它视作第二个独立创造性启示。

当前日文检索结论

如果仅限定“2019-01-09以前公开的日本专利公报”，我会把证据优先级定成：

1. JP2014514821A — 最强的PCell/RRC重建证据；

2. JP2015216681A — 同族，最强的MAC计数/阈值/RLF细节；

3. JPWO2016148243A1 — 最强的截止日前“UL LBT failure”日文证据；

4. JPWO2015174437A1 — UL LBT、busy结果、禁止UL transmission；

5. JPWO2016117608A1 — LBT结果及基于结果控制发送的辅助证据。

现阶段最值得写进无效请求的日文组合：

JPWO2016148243A1 + JP2014514821A

并用JP2015216681A同族内容解释第二篇已经存在的MAC计数、最大阈值和RLF逻辑。

这套日文证据比单纯证明“LBT早已存在”更有用，因为它实际上把权利要求1最关键的两端都夹住了：

UL LBT failure ← JPWO2016148243A1
MAC失败累计/阈值 → PCell故障 → RRC重建 ← JP2014514821A / JP2015216681A

目前唯一仍需要继续深挖的，是中间那句最窄的接口特征：

PHY/lower layer → MAC 的 LBT failure indication，以及收到该指示即递增专用LBT failure counter。

这也是下一轮日文检索最应该集中攻击的点。

针对 CN113273269B 权利要求1，我把这一轮检索严格限定为：

韩国公开公报（KR）+ 公开日早于2019-01-09

并围绕四个核心点反复检索 Google Patents：
① UL LBT失败；② LBT失败的次数/阈值；③ PHY/下层与MAC之间的处理；④ PCell失败后RRC重建。

这一轮有一个比较重要的新发现：

KR20170093071A 是目前检到的、对权利要求1最有贡献的截止日前韩国专利。

它虽然没有完整公开“PHY→MAC LBT failure indication→专用LBT failure counter++”，但已经把“PCell分配的UL资源发生LBT失败”“连续N次LBT失败”“LBT可针对数据、PUCCH/SRS、RACH计算”“LBT失败与随机接入计数器之间的关系”放在同一篇文献里公开，技术距离明显比一般UL-LBT文献更近。

一、目标权利要求1重新拆解

CN113273269B权利要求1要求UE：

Google Patents的权利要求1明确就是这一技术链。(谷歌专利)

二、第一优先级：KR20170093071A

公开号：KR20170093071A
名称：5G 셀룰라 시스템의 단말 신호 송신을 위한 방법 및 장치
英文：Method and apparatus for UE signal transmission for 5G cellular communications
申请人：Samsung Electronics
优先权日：2016-02-04
公开日：2017-08-14

Google Patents明确记载其韩国公开日为2017-08-14，远早于2019-01-09。(谷歌专利)

这篇是这一轮最值得重点使用的文献。

1. 明确公开PCell分配UL资源上的LBT失败

文献明确写道：

UE判断由PCell分配的UL资源是否发生LBT失败，并在失败时执行后续动作。

Google Patents正文：

“the UE determines whether the LBT fails for the UL resource allocated from the PCell”

(谷歌专利)

这已经非常接近权利要求1的：

“PCell has experienced an LBT failure event”。

它不是泛泛讨论非授权频谱，而是直接把：

PCell → UL resource → UE LBT → failure

连接起来了。

2. 明确公开“连续N次LBT失败”作为失败条件

KR20170093071A明确规定UE侧LBT失败条件可以包括：

“If the terminal fails the LBT for N sets of RACH resources”

即：

UE在所配置的N个RACH资源上发生LBT失败。

同时还可以采用：

• 在特定时间内一直不能LBT成功；

• 到timer expiry仍未LBT成功；

• 到RAR window剩余X秒或Y%仍未成功。

(谷歌专利)

这对目标权利要求：

LBT failure counter ≥ threshold → determine an LBT failure event

是非常有价值的先前技术贡献。

虽然它没有使用“LBT_FAILURE_COUNTER”这个名称，但其技术判断已经是：

连续发生N次LBT failure → 判定UE LBT failure condition成立。

从技术功能上，与“计数达到阈值确定LBT失败事件”非常接近。

3. 最重要的是：并不限于RACH一种UL传输

KR20170093071A进一步明确：

LBT可以针对数据、控制信号PUCCH/SRS和RACH传输中的至少一种进行计算。

即Google Patents正文：

“The LBT can be calculated for at least one of LBT for data, LBT for control signals (PUCCH, SRS, etc.), and LBT for RACH transmission.”

(谷歌专利)

因此它公开的UL-LBT对象至少包括：

• 数据UL transmission；

• PUCCH；

• SRS；

• RACH。

这点对CN113273269B权1中的：

“for all UL transmissions”

尤其重要。

它尚不能说逐字公开“一个公共失败指示覆盖全部UL transmission”，但它已经清楚证明在2017年：

UE的LBT失败机制并不局限于PRACH，而可以横跨数据、PUCCH/SRS和RACH多种UL transmission。

所以在创造性论证中，这是一项非常强的“all UL transmissions”相关证据。

4. 还明确讨论“LBT failure和传输计数器”的关系

这篇文献有一个此前检索中很容易被忽略的重要段落。

它明确讨论：

• UE执行RAP发送；

• UE维护PREAMBLE TRANSMISSION COUNTER；

• 当某次RAP不能发送时，需要判断是否增加counter；

• LBT failure就是导致RAP不能发送的原因之一。

原文进一步给出一种实施方式：

如果由于LBT failure导致dropping，UE可以不增加RAP transmission counter。

(谷歌专利)

从无效角度，这段的意义并不是“它完全公开F3”，恰恰相反：

它证明在2017年，技术人员已经明确考虑过“LBT失败发生以后，MAC/RA相关计数器到底增不增加”这一具体设计问题。

目标专利后来采用的是：

LBT failure indication → 增加专用LBT failure counter。

KR20170093071A则公开一种选择：

LBT failure导致RAP未发出 → 可以不增加传统RAP transmission counter。

这反而可以成为创造性论证的重要基础：传统RA counter不适合完整表达LBT失败次数，因此设置独立LBT失败计数机制属于一个很自然的设计方向。

当然，这是组合/显而易见性论证，不能把它描述成KR20170093071A已经直接公开专用LBT failure counter。

三、KR20130038797A：最强的“计数阈值→PCell→RRC重建”韩国文献

公开号：KR20130038797A
申请人：Samsung Electronics
优先权日：2011-10-10
公开日：2013-04-18

Google Patents明确确认公开日为2013-04-18。(谷歌专利)

这篇表面标题是MBMS，但说明书中包含非常重要的LTE随机接入/RLF处理内容。

1. 明确的counter与threshold

文献说明：

• UE进行随机接入；

• 使用PREAMBLE_TRANSMISSION_COUNTER；

• 需要重传时counter增加；

• 当counter达到preambleTransMax对应值时，认定随机接入存在问题。

Google Patents检索出的正文明确说明：

PREAMBLE_TRANSMISSION_COUNTER在需要重传时加1；达到preambleTransMax所对应的阈值以后，判断随机接入发生问题。(谷歌专利)

因此其技术结构几乎就是：

failure attempt
→ counter increment
→ counter reaches configured threshold
→ failure condition.

这与F3/F4的机制高度相似。

2. 最关键：PCell达到阈值后执行RRC connection reestablishment

该文献进一步明确：

如果UE在PCell上发送preamble，直到达到preambleTransMax随机接入仍未成功，则认为当前PCell连接发生严重问题，并启动RRC connection reestablishment程序。

Google Patents正文对此公开得很清楚。(谷歌专利)

这直接贡献目标权利要求的F5：

PCell failure event → re-establishment procedure

其区别仅在于导致阈值的失败输入：

• KR20130038797A：RA/preamble失败；

• CN113273269B：UL LBT failure indication。

因此它特别适合与KR20170093071A组合。

四、KR20170111643A：UL-LBT和多种UL传输的技术背景

公开号：KR20170111643A
名称：Unlicensed band support uplink transmission method and apparatus
优先权日：2016-03-29
公开日：2017-10-12

Google Patents确认其公开日为2017-10-12。(谷歌专利)

这篇文献集中讨论LAA环境中的UL LBT。

其主要贡献

文献明确公开：

• UE在非授权频段进行UL transmission之前执行UL LBT/UL CCA；

• UL LBT由UE执行；

• LBT参数包括竞争窗口CWS、defer period、channel access priority等；

• UL传输包括PUSCH等；

• UE可以针对UL burst/subframe执行UL LBT。

(谷歌专利)

从系统结构上，文献还明确区分：

• upper layer processing unit可处理MAC/RRC；

• physical layer processing unit处理PHY，例如UL transmission signal processing。

(谷歌专利)

因此它可以支持：

PHY负责UL transmission/LBT相关物理操作，MAC/RRC属于其上层。

但这篇没有检到明确的：

PHY产生LBT failure indication并发送MAC。

因此它只能作为架构和UL-LBT背景补强。

五、KR20170093071A其实比KR20170111643A更重要

经过这轮再检索，我会调整韩国文献的排序。

之前如果只按“UL LBT”搜索，很容易认为KR20170111643A是主文献。

但真正逐段阅读后：

KR20170093071A明显更接近CN113273269B权利要求1。

因为它同时具备：

• UE；

• UL LBT；

• PCell；

• UL resource；

• LBT failure；

• 连续N次失败；

• timer-based LBT failure；

• data/PUCCH/SRS/RACH多种UL transmission；

• LBT失败与RA transmission counter关系。

(谷歌专利)

这已经不是单纯的“LBT背景文献”，而是非常接近目标发明的问题场景。

六、为什么KR20170093071A + KR20130038797A是目前最佳韩国组合

这是我认为本轮检索后最值得采用的韩国专利组合：

KR20170093071A + KR20130038797A

其技术链可以这样建立。

KR20170093071A提供前半段

UE对PCell分配的UL资源判断LBT失败
→ 可以按照时间或N个资源上的连续LBT失败确定LBT failure condition
→ LBT计算可覆盖data、PUCCH、SRS、RACH等UL transmission。

(谷歌专利)

而且它还明确讨论：

LBT失败时，UE如何处理随机接入相关counter。

(谷歌专利)

KR20130038797A提供后半段

UE维护随机接入计数器
→ counter递增
→ 达到preambleTransMax阈值
→ 认定随机接入问题
→ 如果发生于PCell
→ 执行RRC connection reestablishment。

(谷歌专利)

二者组合后，目标专利权1的技术逻辑几乎被夹在中间：

多个UL transmission发生LBT失败
→ 对LBT失败次数进行累计/阈值判断
→ 达到阈值视为持续失败事件
→ PCell上的持续UL失败
→ RRC重建。

七、一个特别值得注意的“反向启示”

KR20170093071A有一个对无效创造性论证可能非常好用的点。

它明确说：

当LBT failure导致RAP transmission dropping时，传统的PREAMBLE TRANSMISSION COUNTER可以不递增。(谷歌专利)

这意味着现有RA counter无法准确记录：

实际发生了多少次LBT失败。

如果技术人员需要判断“PCell是否由于信道长期繁忙而持续LBT失败”，那么自然会产生两个技术需求：

1. 不应把没有实际发送的PRACH错误计入普通preamble transmission counter；

2. 但仍需要另一个统计量记录LBT失败本身。

于是很自然的设计就是：

增加独立的LBT failure counter。

这正好是CN113273269B权1所采取的方案。

这不是新颖性破坏，而是一条值得重点发展的创造性动机论证。

八、KR20170093071A与“all UL transmissions”的关系

权1最麻烦的词仍然是：

“LBT failure indication for all UL transmissions”

KR20170093071A没有逐字说：

一个共同LBT failure indication用于所有UL transmissions。

但它明确说LBT计算可以涵盖：

• data；

• control signals，包括PUCCH、SRS；

• RACH。

(谷歌专利)

所以如果“all UL transmissions”被解释为：

LBT失败检测机制应适用于各种UL transmission，而不限于PRACH/SR，

那么KR20170093071A是相当有力的证据。

如果解释为：

PHY必须产生一个统一的共同failure indication，该indication覆盖所有UL transmission类型，

那么仍有一个明确缺口。

九、没有发现截止日前公开的KR版本的几篇英文强文献

这一轮也专门追了之前英文检索里的强文献，但结果值得说明。

WO2017136458A2

Listen-before-talk failure during a random access procedure

它公开日2017-08-10，技术很有价值，但Google Patents family显示只有WO、CN、HK，没有韩国成员，因此不能列为“韩文专利公报”。(谷歌专利)

Uplink Operation for LTE in an Unlicensed Band

其韩国公报是：

KR20190143472A

但公开日是：

2019-12-30

已经晚于2019-01-09，所以本轮严格排除。(谷歌专利)

这也是为什么不能简单把上一轮英文文献全部换成KR号码。

十、必须排除的一篇“非常危险但公开太晚”的KR文献

检索中出现了非常接近目标权利要求的：

KR20210064295A / KR102965044B1 — NR-U LBT MAC procedures

它的基础优先权日是2018-09-26，早于目标日，但韩国公开是在2021年，不能作为2019-01-09以前已经公开的KR先前技术。

不过它的内容几乎直接说明：

PHY layer may indicate LBT success or failure to MAC，且该UL LBT indication可关联一个或多个MAC procedures。

(谷歌专利)

因此这篇有很高的技术演进/研发背景价值，但按照你给出的“公开日在20190109前”标准，必须排除。

同样，KR20210047901A/KR102587763B1虽然优先权日也是2018-09-26，而且内容甚至明确到：

PHY LBT failure indication → MAC/RRC → counter maintenance → RRC re-establishment，

但韩国公开日在2021年，同样不能列入截止日前韩国公开证据。(谷歌专利)

十一、目前韩国文献的特征覆盖矩阵

十二、韩国专利优先级建议

按“对无效权1的实际贡献”排序，我现在建议：

1. KR20170093071A — A+

   • 韩国截止日前最重要；

   • UL LBT failure；

   • PCell UL resource；

   • N次失败；

   • data/PUCCH/SRS/RACH多个UL类型；

   • LBT failure与计数器处理直接相关。(谷歌专利)

2. KR20130038797A — A+

   • counter；

   • threshold；

   • PCell；

   • 达阈值后RRC re-establishment。(谷歌专利)

3. KR20170111643A — B+

   • UE UL LBT；

   • 非授权频段；

   • UL LBT参数和UL transmission；

   • PHY/MAC层结构背景。(谷歌专利)

十三、目前最强的韩国无效路线

我会首先写：

KR20170093071A + KR20130038797A

而不是三篇文献全部堆上。

逻辑可以压缩成：

KR20170093071A

PCell分配UL资源
→ UE执行LBT
→ LBT失败
→ N个RACH资源上的失败可构成UE LBT failure condition
→ LBT范围可覆盖data、PUCCH、SRS和RACH。

然后：

KR20130038797A

UE采用counter累计UL随机接入失败
→ counter达到配置阈值
→ 认定PCell随机接入严重故障
→ 启动RRC connection re-establishment。

因此，与CN113273269B权1相比，真正剩余的最窄区别主要缩小到：

“由PHY/lower layer向MAC提供LBT failure indication，并由MAC依据该指示递增一个独立的LBT failure counter。”

这比一开始看起来的区别要窄很多。

从目前韩国公开专利结果看，权1最值得攻击的是创造性，不是依赖单篇KR文献攻击新颖性。

尤其是KR20170093071A已经在2017年把“LBT失败为什么不应该直接计入普通RA发送counter”这个问题明确摆出来，这为采用独立LBT failure counter提供了相当有价值的技术动机。

我又把检索范围严格限定到 Google Patents 中公开日早于 2019-01-09 的中文专利公报（CN），重点反复检索了“LBT失败/失败次数/预设次数/MAC/物理层/PCell/随机接入/RRC重建/非授权上行”等组合。

这一轮的结果比日文、韩文更有价值。尤其是：

CN107770868A 是目前中文先前技术中，对权利要求1前半段“LBT失败→累计失败次数→达到阈值”最直接、最干净的一篇。

而：

CN107483161A 是目前中文公报中，对后半段“PCell发生上行随机接入问题/失败→MAC通知RRC→RRC连接重建立”最直接的一篇。

所以目前我认为最值得用于无效权利要求1的中文组合是：

CN107770868A + CN107483161A

一、先固定CN113273269B权利要求1的真正攻击点

权利要求1可以拆成：

目标专利的Google Patents文本明确采用了这一链条。(谷歌专利)

因此真正需要找的不是泛泛的“早已有LBT”，而是：

LBT failure → counting → threshold → PCell failure → RRC re-establishment

二、第一优先级：CN107770868A

公开号：CN107770868A
名称：一种控制信元取消方法、装置及终端
申请人：中兴通讯股份有限公司
申请/优先权日：2016-08-19
公开日：2018-03-06

因此公开日明显早于2019-01-09。(谷歌专利)

这是目前中文文献中最值得重视的一篇。

1. 明确公开UE侧LBT失败

该文献针对非授权载波小区，由终端执行LBT。背景部分明确说明：

• MAC CE可以通过非授权载波发送；

• 终端要先执行LBT；

• 如果LBT失败，终端无法及时发送MAC CE。(谷歌专利)

也就是说，它已经把：

UE → 非授权载波UL transmission → LBT → LBT失败

这一基础链条公开出来。

三、CN107770868A最重要的地方：失败就更新“失败次数”

这篇文献的核心价值在说明书第96—98行附近。

它明确公开：

对非授权载波小区进行LBT过程，在LBT过程失败时更新失败次数。

然后：

如果更新后的失败次数不超过预设次数，则继续重复LBT。

再进一步：

如果失败次数超过预设次数，则进入另一种处理。

Google Patents正文直接记载：

“在LBT过程失败时更新失败次数；更新后的失败次数不超过预设次数时，重复执行……；确定所述LBT过程的失败次数超过所述预设次数时……” (谷歌专利)

这与CN113273269B权1的：

收到LBT failure indication
→ increase LBT failure counter
→ counter ≥ threshold
→ LBT failure event

在功能上已经高度接近。

四、它几乎直接公开F3和F4的核心思想

CN107770868A虽然用的词是：

“失败次数”

而不是：

“LBT failure counter”

但技术含义非常明确：

1. 执行一次LBT；

2. 如果失败；

3. 更新失败次数；

4. 与预设次数比较；

5. 重复执行；

6. 失败次数超过预设次数后触发另一处理。

(谷歌专利)

从技术实现角度：

“失败次数”本质上就是对LBT失败事件进行累计的计数状态。

所以我认为在无效检索表中可以把它标成：

• F3：强贡献

• F4：强贡献

但注意严谨措辞：

文献并没有逐字公开名为“LBT failure counter”的MAC变量，因此如果做新颖性逐字比对，应表述为“公开了在LBT失败时更新失败次数并与预设次数比较”，而不宜直接把术语等同。

五、它还明确涉及MAC与PHY

CN107770868A的技术背景和实施例明确涉及：

• MAC层生成MAC CE；

• MAC CE提交到物理层；

• LBT结果决定该物理层UL传输是否能够完成。

文献甚至明确描述：

终端中非授权载波小区的物理层中的MAC CE通过非授权载波小区发送，而MAC层维护相应MAC CE状态。(谷歌专利)

所以它已经把：

MAC层操作 + PHY传输 + LBT结果

置于同一UE协议栈上下文。

不过这里仍要非常谨慎：

它没有明确公开

PHY向MAC发送一个名为“LBT failure indication”的专门接口消息。

因此F2中的：

“MAC entity receives from a lower layer an LBT failure indication”

仍然是一个文字层面的区别特征。

六、CN107770868A与权1的对应关系

所以它非常适合作为权1前半段的核心文献。

七、第二优先级：CN107483161A

公开号：CN107483161A
名称：载波聚合无线通信系统中控制随机接入的方法和装置
申请人：Samsung Electronics
最早优先权日：2011-04-05
公开日：2017-12-15

Google Patents明确记录其公开日为2017-12-15。(谷歌专利)

这一篇负责补目标权利要求的后半段。

八、CN107483161A直接公开PCell失败→MAC→RRC→重建

该文献Google Patents摘要非常有价值。

它明确规定：

如果随机接入问题和/或失败发生在PCell，则检测到该问题/失败的UE的MAC层实体通知RRC实体。

随后：

RRC实体执行RRC连接重建立以及相应的RRC连接重配置，以重建与eNB之间的连接。

(谷歌专利)

技术链非常清楚：

PCell上的UL随机接入问题/失败
→ UE MAC检测问题
→ MAC通知RRC
→ RRC connection re-establishment

这对权1的F5：

PCell经历LBT failure event → perform re-establishment procedure

提供了非常直接的已知恢复机制。

九、CN107483161A为什么比普通RLF文献更好

因为它不是泛泛写：

无线链路失败后重建。

而是具体到：

PCell的随机接入问题/失败

然后由：

MAC层实体

向：

RRC实体

报告，并执行：

RRC connection re-establishment。

(谷歌专利)

这非常适合作为CN107770868A的后半段组合文献。

十、两篇组合后技术链非常完整

文献1：CN107770868A

公开：

UL非授权载波执行LBT
→ LBT失败
→ 更新失败次数
→ 比较预设次数
→ 超过预设次数后进入故障处理。

(谷歌专利)

文献2：CN107483161A

公开：

PCell随机接入问题/失败
→ MAC实体通知RRC
→ RRC执行连接重建立。

(谷歌专利)

两者组合以后形成：

UL传输执行LBT
→ LBT失败
→ 累计LBT失败次数
→ 达到预定阈值
→ 将持续失败视为PCell接入问题
→ MAC/RRC故障处理
→ RRC连接重建立。

这已经非常接近CN113273269B权利要求1的完整技术逻辑。

十一、第三优先级：CN109076603A

公开号：CN109076603A
名称：用于上行链路传输的对话前监听
申请人：Intel Corporation
优先权日：2016-03-28
公开日：2018-12-21

Google Patents确认其CN公开日是2018-12-21，因此仅比目标日早19天，但仍满足你要求的截止条件。(谷歌专利)

这篇的主要用途不是失败计数，而是补：

LBT明确用于UL transmission

这一点。

它专门以：

“用于上行链路传输的对话前监听”

作为发明主题，公开了UE为UL transmission执行LBT的具体时间、符号和信道接入过程。(谷歌专利)

因此如果对方质疑CN107770868A只是在MAC CE发送背景下讨论LBT，可用CN109076603A证明：

2018年以前，UE在各种常规上行传输前执行LBT本身已经是明确、成熟的技术方案。

十二、第四优先级：CN109076514A

公开号：CN109076514A
名称：上行信息传输方法、基站与用户设备
申请人：华为技术有限公司
优先权日：2016-05-10
公开日：2018-12-21。(谷歌专利)

它主要讨论：

• UE；

• 上行信息传输；

• 小区组；

• 非授权小区；

• 授权与非授权小区配合；

• 多小区上行高可靠性传输。

(谷歌专利)

但本轮逐页搜索没有在Google Patents正文中找到明确的“LBT”术语。(谷歌专利)

因此：

不能把它作为LBT失败的核心证据。

它至多用于证明：

截止日前，在PCell/授权小区与非授权小区组成的小区组中进行UL传输、并根据不同小区情况处理UL信息已经是已知架构。

我只给它 C级辅助证据。

十三、另一类有价值但不能作为截止日前CN公开使用的文献

这次检索还找到几篇内容“非常危险”，但必须严格排除。

CN112954800A/B

该文献内容非常接近：

UE在第一UL BWP执行LBT；
LBT失败次数≥第一门限；
切换到第二UL BWP；
在非授权频段完成随机接入。

(谷歌专利)

它的优先权日是：

2018-08-01

虽然早于2019-01-09，但是CN公开日直到：

2021-06-11

所以不满足“公开日在2019-01-09前”这一条件。(谷歌专利)

不能用其后来的CN公开文本证明2019-01-09以前公众已经获得该内容。

十四、CN111869306A也必须排除

这篇也很接近目标问题：

• 非授权频谱；

• 每条随机接入消息前执行LBT；

• channel busy则不能发送；

• 随机接入被延后。

而且它要求了：

2018-08-01中国申请的优先权。

但是其公开日是：

2020-10-30

所以同样不满足截止日前公开要求。(谷歌专利)

十五、CN112753275A/B更接近权1，但必须排除

这是本轮检索中尤其值得注意的一篇：

CN112753275B：NR-U LBT MAC过程

它后来的权利要求几乎直接写出：

MAC接收LBT失败指示；

并且UL LBT时：

从物理层接收LBT失败指示；

还明确公开：

维护LBT失败计数器FC；

接收到LBT失败指示时，将FC递增1；

实施连续LBT失败检测与指示；

切换BWP、随机接入等恢复行为。

(谷歌专利)

从技术内容上，它几乎就是目标权利要求的直接先驱。

但是它的问题是：

最早优先权日虽然是 2018-09-26，但中国申请/公开均发生在截止日之后。

因此不能作为满足你这一轮条件的“2019-01-09前公开CN文献”。

但它有一个非常重要的研究意义：

它进一步确认了目标权1最窄的真正区别，很可能集中在2018年末3GPP NR-U正在形成的“PHY→MAC LBT failure indication接口”。

也就是说，早期CN文献已经分别公开：

• LBT失败；

• LBT失败次数；

• 阈值；

• PCell失败后RRC重建；

到2018年9月之后的申请中，才开始非常明确地把这些元素标准化为：

PHY → MAC LBT failure indication + dedicated LBT failure counter

这个时间线对创造性分析很重要。

十六、这一轮最重要的新颖性判断

目前截止到2019-01-09以前公开的中文CN文献中，我仍然没有发现一篇单篇公报无歧义地同时公开以下全部限定：

PHY/lower layer
→ 向MAC发送统一的LBT failure indication
→ MAC收到后增加专用LBT failure counter
→ 达阈值
→ PCell发生该LBT failure event
→ RRC重建。

因此：

单篇新颖性攻击

目前不建议仅凭某一篇CN文献直接主张权1所有技术特征被逐项完整公开。

创造性攻击

则已经有明显更强的证据：

CN107770868A + CN107483161A

这是目前我认为最干净的纯中文公报组合。

十七、核心组合一：CN107770868A + CN107483161A

我建议把这套作为中文证据主路线。

CN107770868A负责：

• UE；

• 非授权载波；

• UL发送；

• LBT；

• LBT失败；

• LBT失败就更新失败次数；

• 与预设次数比较；

• 超过预设次数触发特殊处理。

(谷歌专利)

CN107483161A负责：

• PCell；

• UL随机接入失败；

• MAC检测问题；

• MAC→RRC；

• RRC connection re-establishment。

(谷歌专利)

技术人员面对CN107770868A中的：

LBT持续失败已经达到预设次数

需要决定：

如果该持续UL接入故障发生在PCell，应该怎么办？

CN107483161A已经明确提供答案：

如果PCell的随机接入过程发生问题/失败，MAC通知RRC，执行RRC连接重建立。

因此组合动机是相当自然的。

十八、权1逐项覆盖矩阵

其中：

• ●：直接或较明确贡献

• ○：辅助贡献

• △：存在技术关联，但不宜声称逐字公开

十九、与之前英文证据相比，CN107770868A非常值得提高优先级

这一点我建议特别重视。

之前英文检索里，US20170231005A1的价值在于：

LBT失败 → counter → threshold。

而CN107770868A其实已经用非常朴素、清楚的中文公开：

LBT过程失败时更新失败次数 → 比较预设次数 → 超过预设次数。

而且它的公开日为：

2018-03-06

完全满足截止日前公开要求。(谷歌专利)

因此在中国无效程序的证据组织中，如果只看技术阅读便利性：

CN107770868A很可能比外文专利更适合作为前半段核心证据。

二十、目前中文专利优先级

我建议排序如下：

A+：CN107770868A

最重要。

贡献：

UL LBT failure
→ 更新失败次数
→ 预设次数/阈值
→ 超阈值后的处理。

公开日：

2018-03-06。(谷歌专利)

A+：CN107483161A

后半段最重要。

贡献：

PCell random access problem/failure
→ MAC通知RRC
→ RRC connection re-establishment。

公开日：

2017-12-15。(谷歌专利)

B：CN109076603A

贡献：

UE上行传输前LBT的完整物理层技术背景。

公开日：

2018-12-21。(谷歌专利)

适合用来补强“UL transmission的LBT不是只针对一个特殊MAC CE”。

C：CN109076514A

贡献：

UE、小区组、PCell/非授权小区相关的UL传输架构。

公开日：

2018-12-21。(谷歌专利)

但没有直接检到LBT术语，因此只适合作辅助。

二十一、最终建议的中文无效组合

目前纯中文专利证据中，我会把主组合明确确定为：

D1：CN107770868A
＋
D2：CN107483161A

必要时再增加：

D3：CN109076603A

作为“普通UL transmission执行LBT”的技术背景补强。

组合逻辑是：

D1：LBT失败就累计失败次数，失败次数与预设阈值比较；
↓
D2：PCell的UL随机接入问题发生后，由MAC向RRC报告并进行RRC连接重建立；
↓
D3：进一步证明LBT普遍应用于UE的UL transmission。

因此权利要求1剩余最值得争议的窄区别，已经收缩为：

把LBT结果明确封装成由PHY/lower layer发送给MAC的“LBT failure indication”，并由MAC据此维护一个专门的LBT failure counter。

而“LBT失败本身需要计数、达到阈值后视为持续失败，以及PCell持续上行接入失败需要RRC重建立”这三个核心思想，在2019-01-09以前的中文专利中已经分别存在较强公开。

如果按现有结果继续深入，下一轮最值得专门追的是2016—2018年中国申请中的“PHY向MAC报告CCA/LBT busy/failure、SR/PRACH未发送指示”。如果能在截止日前CN公报中把这个接口特征补出来，CN107770868A + 该接口文献 + CN107483161A 会形成比现在更完整的创造性攻击链。

我重新围绕 CN113273269B 权利要求1，对 Google Patents 的韩国公开公报做了多轮反向同族、韩文关键词、引证链和接口特征检索。这一轮比前一轮多找到了一篇很有价值的韩国文献 KR20180032572A，并重新核实了 KR20170093071A 的全文。

先固定目标权1：其核心要求是“MAC从下层接收用于所有UL传输的LBT失败指示 → 收到后增加LBT失败计数器 → 计数达到阈值判定LBT失败事件 → PCell发生该事件后执行重建程序”。(谷歌专利)

结论

在公开日严格早于2019-01-09的韩文KR公报中，目前最有价值的排序是：

目前我仍然没有发现一篇2019-01-09以前公开的KR公报，单篇逐字公开权1全部链条。但 KR20170093071A + KR20130038797A 已经形成相当强的创造性组合；加入 KR20180032572A 后，可以进一步压缩“lower layer/PHY→MAC”这一接口差异。

1. KR20170093071A——目前最重要的韩国文献

公开号：KR20170093071A
韩文名称：5g 셀룰라 시스템의 단말 신호 송신을 위한 방법 및 장치
申请人：Samsung Electronics
优先权日：2016-02-04
公开日：2017-08-14。(谷歌专利)

这篇应当放在韩国证据的第一位。

（1）直接公开“PCell分配的UL资源发生LBT失败”

原文明确记载：

UE判断PCell分配的UL资源是否发生LBT失败，并在失败时采取载波切换请求、在其他载波重试RACH等措施。(谷歌专利)

这意味着在2017年已经公开：

PCell → UL resource → UE执行LBT → LBT failure → 恢复动作

与权1最后的“PCell经历LBT failure event”高度接近。

（2）直接公开“N次LBT失败”作为LBT failure condition

该文献明确给出UE的LBT失败条件：

UE在配置的 N个RACH资源上LBT失败；

还包括：

在规定时间/定时器到期前始终未LBT成功；
RAR window剩余到一定时间/比例仍没有成功。

(谷歌专利)

因此，它实际上已经公开：

发生LBT失败 → 累积达到N次 → 构成LBT failure condition

只是没有把这个N次实现明确命名为“LBT failure counter ≥ threshold”。

这对权1的F3/F4非常重要。

（3）对“all UL transmissions”尤其强

文献进一步明确：

LBT可以针对数据、控制信号PUCCH/SRS、以及RACH transmission中的至少一种进行计算。(谷歌专利)

而且说明RACH资源分配方法同样可应用于：

PRACH、PUCCH、PUSCH、SRS等不同UL channel，并在short LBT成功后发送这些UL signals。(谷歌专利)

因此，如果权1的“用于所有UL transmissions”解释为：

LBT失败机制不限于某一种UL信道，而应适用于各种UL transmission，

那么KR20170093071A是截止日前非常强的韩国证据。

2. 更关键的新发现：它直接讨论“LBT失败后counter到底加不加”

KR20170093071A还有一组此前很容易漏掉的段落。

它先公开传统RA机制：

PREAMBLE_TRANSMISSION_COUNTER增加1；
当其达到preambleTransMax + 1时，向上层报告RA procedure problem。(谷歌专利)

然后专门针对LBT失败提出：

UE准备发送RAP但其LBT失败时，可以不增加RACH retry count；

或者：

LBT失败时，RACH retry count仍然增加，但不执行power ramping。(谷歌专利)

这是对目标专利非常重要的一项技术公开。

因为它证明在截止日前，本领域已经明确研究：

“发生一次UL LBT failure之后，协议层的失败/重试计数器应该如何更新？”

也就是说，“LBT failure”和“counter increment”之间的关系已经被直接提出，只不过该文献采用的是已有RA retry counter，而不是目标权1的独立LBT failure counter。

从创造性角度，这比单纯找到“LBT失败存在”要强得多。

3. KR20130038797A——最强的PCell阈值→RRC重建证据

公开号：KR20130038797A
韩文名称：이동통신 시스템에서 멀티 미디어 방송 서비스를 수신 방법 및 장치
优先权日：2011-10-10
公开日：2013-04-18。(谷歌专利)

虽然标题看起来和LBT无关，但说明书中的PCell随机接入处理对权1非常关键。

它明确给出：

preambleTransMax是UE在启动某个退出动作之前允许发送的最大preamble次数，该退出动作可以是RRC connection reestablishment。(谷歌专利)

更加直接的是：

如果随机接入在达到preambleTransMax之前仍未成功，则判断preamble是在PCell还是SCell上传输；如果是PCell，UE启动RRC连接再建立；如果是SCell，则停止preamble传输而不进行RRC重建。(谷歌专利)

该文献还明确解释：

当PCell上的随机接入在达到preambleTransMax时仍未成功，UE认为与当前PCell的连接发生严重问题，并启动 RRC connection reestablishment procedure。(谷歌专利)

所以其链条是：

PCell UL access attempts
→ 累计次数
→ 达到配置阈值preambleTransMax
→ 认定PCell严重故障
→ RRC connection reestablishment

这与权1的F4/F5结构几乎完全对应。

区别仅仅是计数对象：

KR20130038797A：preamble/RA失败或尝试次数
CN113273269B：LBT failure indication次数。

4. 新增强文献：KR20180032572A

公开号：KR20180032572A
韩文名称：비허가된 캐리어의 클리어 채널 평가가 실패한 경우의 업링크 제어 채널 정보의 송신
中文可译：非授权载波的CCA失败时发送上行控制信道信息
申请人：Qualcomm
优先权日：2015-07-23
公开日：2018-03-30。(谷歌专利)

这篇是本轮重新检索后新增的高价值韩国文献。

它直接公开UE判定UL CCA/LBT失败

摘要明确：

UE生成UL control information；
尝试对UL burst执行CCA；
判定CCA failure；
在CCA失败时，把PUCCH移到后续subframe、其他UL burst或其他carrier发送。(谷歌专利)

说明书又明确：

非授权SCC上的PUCCH受LBT procedure约束；如果CCA失败，则PUCCH可能无法发送。(谷歌专利)

所以它直接证明：

截止日前UE已经把UL LBT/CCA失败当成一个明确可判定的内部事件，并根据这个失败事件改变UL传输处理。

5. KR20180032572A对“lower layer→MAC”接口的特殊价值

更重要的是，它把UE协议层分得非常清楚：

Layer 2包括MAC层；(谷歌专利)

同时：

Layer 1包括PHY层，TX/RX processor实现PHY相关信号处理。(谷歌专利)

并且同一文献处理的是：

UL burst的CCA/LBT失败，以及PUCCH/PUSCH等物理UL transmission。(谷歌专利)

因此它可以作为很好的协议栈桥梁证据：

LBT/CCA属于UL物理传输侧事件；
MAC位于PHY之上的Layer 2。

但必须严谨：

KR20180032572A没有直接写出

“PHY发送一个LBT failure indication给MAC”。

因此它不能单独完全覆盖F2，只能明显缩短这一接口差异。

6. KR20170118735A——CCA/LBT失败阻断随机接入

公开号：KR20170118735A
韩文名称：비허가 무선 주파수 스펙트럼 대역의 서브프레임에서의 셀룰라 랜덤 액세스에 대한 기법들
申请人：Qualcomm
优先权日：2015-02-18
公开日：2017-10-25。(谷歌专利)

该文献明确说明：

UE为了判断非授权频谱是否可用执行CCA/LBT；如果信道不可用，则以后重新执行CCA。(谷歌专利)

在随机接入场景中：

ePRACH/RACH请求只有在UE赢得CCA竞争后才能传输；由于CCA竞争具有不确定性，UE可能长时间无法发送access request。(谷歌专利)

而随机接入请求本身还可以包含：

RRC request或RRC connection reestablishment request。(谷歌专利)

因此它适合建立：

LBT/CCA failure → UL random access无法实施/被拖延 → RRC接入或重建过程受到影响

这一技术桥梁。

但它没有counter，因此属于辅助文献。

7. KR20170111643A——系统性UL-LBT背景

公开号：KR20170111643A
韩文名称：비면허 대역 지원 상향링크 전송 방법 및 장치
优先权日：2016-03-29
公开日：2017-10-12。(谷歌专利)

其摘要和权利要求明确：

UE在非授权频段进行UL transmission之前，决定并执行UL LBT或UL CCA，并配置竞争窗口、channel access priority、LBT parameters等。(谷歌专利)

它能够证明：

在2017年，UE在UL transmission之前进行UL LBT/CCA已经是一套完整、成熟的通信机制。

但没有专门的失败计数和PCell重建，因此作为B级背景文献即可。

8. 当前最强韩国组合：KR20170093071A + KR20130038797A

这两篇组合是最值得优先写进无效检索报告的。

D1：KR20170093071A

已经给出：

PCell分配UL资源
→ UE判断LBT failure
→ 连续N个RACH resource发生LBT failure即可构成LBT failure condition
→ LBT可用于data、PUCCH、SRS、RACH
→ LBT失败后专门考虑是否增加RA retry counter。(谷歌专利)

D2：KR20130038797A

已经给出：

PCell上的UL random access
→ 尝试次数达到preambleTransMax
→ 随机接入仍不成功
→ 判定PCell连接出现严重问题
→ RRC connection reestablishment。(谷歌专利)

二者组合后，技术逻辑就是：

UL LBT failure
→ 对重复LBT失败进行N次/阈值判断
→ 把持续的UL接入故障视为PCell故障
→ RRC connection reestablishment

这已经非常逼近权利要求1。

9. 更完整的三文献组合

如果希望专门处理“lower layer”这一点，我建议：

KR20170093071A + KR20180032572A + KR20130038797A

作用分工如下：

因此三篇组合后，最主要的剩余文字区别已经非常集中。

10. 目前仍未完全补上的唯一关键接口

这轮反复检索以后，我认为权1最需要继续攻击的不是“LBT failure”“counter”“threshold”或者“PCell re-establishment”本身。

这些在截止日前KR公报中都已经分别找到了很强的证据。

真正仍没有找到明确逐字公开的是：

由PHY/lower layer向MAC发送一个专门的、用于所有UL transmission的“LBT failure indication”，并且MAC每收到一次该indication就增加一个独立的LBT failure counter。

尤其是“独立的LBT failure counter”这一名称和接口组合。

KR20170093071A已经接近到：

LBT失败后明确决定RA/RACH counter是“增加”还是“不增加”；(谷歌专利)

KR20180032572A则把：

PHY Layer 1、MAC Layer 2以及UL CCA failure

放在同一公开文本中。(谷歌专利)

因此目标权1相对于截止日前韩国技术的实质增量已经可以被压缩为：

把既有“LBT failure + retry/failure counting”进一步标准化成PHY→MAC的统一失败指示，并设置一个独立LBT failure counter。

最终建议排序

用于下一步制作无效证据表，我会把韩国公报定成：

D1：KR20170093071A —— 主文献，最接近现有技术。
D2：KR20130038797A —— PCell阈值失败→RRC重建。
D3：KR20180032572A —— UL CCA failure + PHY/MAC协议栈接口背景。
D4：KR20170118735A —— LBT/CCA失败与随机接入/RRC接入之间的桥梁。
D5：KR20170111643A —— UL LBT通用背景。

就目前结果看，KR20170093071A + KR20130038797A 是最精炼、技术逻辑最强的韩国两文献组合；若对方重点争辩“lower layer/MAC”，再加入 KR20180032572A 最合适。

以上是专利先前技术检索和技术特征比对，不是对无效结论的法律意见。

这次重新以 CN113273269B授权后的权利要求1 为准，而不是以A文本的原始权利要求为准，对 Google Patents 中 公开日严格早于2019-01-09的中文CN公报又做了多轮检索。相比前一轮，结果有明显提升，尤其新增锁定了 CN107371273A，它直接触及此前最难补的“LBT失败信息→MAC层 + MAC设置LBT失败计数器”。

一、结论先行

目前我认为，对CN113273269B权利要求1最有贡献的中文专利应重新排序为：

我认为目前最强的纯中文创造性攻击组合应调整为：

D1：CN107371273A
＋ D2：CN107371168A
＋ D3：CN102870450A

其中CN107770868A非常适合作为进一步补强“LBT失败→失败次数递增→阈值”的旁证。

二、先明确授权权利要求1到底要求什么

CN113273269B授权权利要求1要求的技术链是：

F1：UE包括非暂时性计算机可读介质和处理器；
F2：UE的MAC实体从下层接收用于所有UL传输的LBT失败指示；
F3：MAC实体接收到该LBT失败指示时，增加LBT失败计数器；
F4：LBT失败计数器≥阈值时，确定LBT失败事件发生；
F5：响应于确定PCell经历该LBT失败事件，执行重建程序。(谷歌专利)

也就是说，本案的真正难点不在“LBT是否已知”，而在：

lower layer → MAC indication → LBT counter → threshold → PCell → re-establishment

三、最重要的新发现：CN107371273A

CN107371273A
《随机接入方法、装置及用户设备》
申请人：中兴通讯股份有限公司
优先权/申请日：2016-05-13
公开日：2017-11-21。(谷歌专利)

这篇是本轮最重要的新发现。

1. 它直接提出：LBT失败信息告诉MAC层

该文献针对LAA随机接入明确指出：

UE在发送Preamble前执行LBT；如果UE侧LBT失败，Preamble实际上没有正常发送。如果仍按照传统LTE机制累加Preamble发送次数，会“错误统计真实的Preamble发送次数”。(谷歌专利)

紧接着文献给出解决方案：

当UE发送Preamble执行LBT失败时，UE可以将LBT失败的信息告诉MAC层；需要向UE的MAC层和/或RRC层等上报或指示当前Preamble传输失败是由于UE侧LBT失败。(谷歌专利)

这一段对权1的F2非常重要。

目标权1：

lower layer → MAC：LBT failure indication

CN107371273A：

UE执行LBT失败 → 将LBT失败信息告诉MAC层

虽然它没有在这一句话里逐字写“PHY layer sends…”，但从协议功能上已经明确提出：

执行LBT的一侧必须把LBT失败结果反馈给MAC，否则MAC不能正确维护其计数状态。

四、更关键：CN107371273A已经明确提出“MAC的LBT失败计数器”

同一段的最后一句尤其重要：

“优选地，MAC层需要分别设置统计LBT失败或成功的计数器，和/或，统计Preamble码发送次数计数器。” (谷歌专利)

这意味着在2017-11-21以前公开的中文专利中已经明确出现：

MAC layer + LBT failure information + LBT failure counter

三个核心元素。

这比CN107770868A强很多，因为CN107770868A虽然有“LBT失败次数”，但没有如此直接地把：

LBT失败结果→MAC→单独LBT失败计数器

写在同一技术方案里。

与F2/F3的对应关系

目标权1：

MAC receives LBT failure indication
→ increments LBT failure counter.

CN107371273A：

UE发生LBT失败
→ 将LBT失败信息告诉MAC
→ MAC单独设置统计LBT失败的计数器。

因此它对F2/F3已经属于非常强的直接贡献。

尚存的文字差异是：

1. 实施例主要针对随机接入Preamble；

2. 没有明确逐字写“每收到一次failure indication，counter += 1”；

3. 没有在这一个LBT counter段落中进一步规定达到某个LBT阈值即判定失败事件。

而后两个缺口正好由其他截止日前CN公报补。

五、CN107371273A还明确涉及多种随机接入UL transmission

该文献不只考虑Msg1/Preamble，还对随机接入中的Msg1、Msg3等消息进行LBT设计，并规定在发送随机接入消息前进行相应LBT。(谷歌专利)

例如其正文还明确提出：

在发送Msg1前执行LBT；如果LBT失败，可发送相应指示，使MAC不进行PreambleTransMax计数器累加。(谷歌专利)

所以它已经显示出：

LBT结果必须反馈给MAC，否则MAC自己的协议计数器会被错误更新

这一与目标发明高度一致的技术问题。

六、第二核心文献：CN107371168A

CN107371168A
《一种非授权频谱中的测量方法和设备》
申请人：电信科学技术研究院
优先权日：2016-05-12
公开日：2017-11-21。(谷歌专利)

如果CN107371273A主要补的是：

LBT failure → MAC → LBT counter

那么CN107371168A主要解决的是：

all UL transmissions + LBT failure count + threshold

七、它明确覆盖多种UL transmission

CN107371168A明确规定：

UE确定需要进行上行传输时，在非授权频谱执行LBT并统计LBT结果。(谷歌专利)

它随后把“上行传输”明确列为：

• 基于网络动态调度的上行传输；

• 半持续调度上行传输；

• RACH前导码上行传输；

• D2D直接传输。(谷歌专利)

也就是说，它并没有把LBT failure counting限制在Preamble或SR一种传输类型。

更关键的是，其说明书进一步规定：

可以按RACH、PUSCH等特定信道分别统计，也可以**“基于UE整体传输进行统计”**。(谷歌专利)

这对权1中的：

“用于所有UL transmissions”

非常有意义。

八、CN107371168A直接公开“LBT失败次数≥阈值”

它规定事件触发条件可以是：

“所统计的LBT失败的次数大于或等于第二次数阈值”。(谷歌专利)

同时还可以是：

• LBT总次数≥第一次数阈值；

• LBT成功次数≥第三次数阈值；

• LBT失败概率达到相应阈值等。(谷歌专利)

并明确说明上述次数阈值可依据经验、仿真或应用环境设定。(谷歌专利)

所以它直接给出了：

统计LBT失败次数 → LBT failure count ≥ threshold → trigger event

这与权1 F3/F4的结构高度一致。

九、CN107371168A对“所有UL transmission”的贡献尤其值得重视

把CN107371168A与目标权1并排：

目标：

common LBT failure indication for all UL transmissions
→ common counter.

该文献：

多种不同UL transmission都执行LBT
→ 可以分别统计
→ 也可以基于UE整体传输统一统计LBT结果。(谷歌专利)

这不能直接等同于：

“PHY提供一个common failure indication”。

但如果“for all UL transmissions”解释为：

该LBT失败检测/统计机制跨不同UL传输类型统一适用，

那么CN107371168A是非常有力的截止日前中文证据。

十、而且CN107371168A本身就是目标专利的审查引证文献

Google Patents对CN113273269A/B专利族列出的审查引证包括：

• CN107371168A

• CN107770868A

• US20180176961A1。(谷歌专利)

这不意味着审查机关已经认定它们足以破坏授权权1，但至少说明：

CN107371168A与CN107770868A确实被审查程序识别为与本案LBT失败检测主题高度相关的先前技术。

而本轮新增的 CN107371273A 没有出现在这三篇Google Patents审查引证中，因此尤其值得作为无效检索中的新增证据深入使用。(谷歌专利)

十一、第三核心文献：CN102870450A

CN102870450A
《次服务小区无线电链路监测和无线电链路失败处理》
原申请人：MediaTek
优先权日：2011-05-03
公开日：2013-01-09。(谷歌专利)

它是当前中文文献中补F5最干净的一篇。

关键公开

文献首先说明传统LTE中：

MAC层指示随机接入问题时可被视为RLF；检测到RLF后，UE尝试进行RRC连接重建。(谷歌专利)

然后非常直接地写道：

“UL PCELL中的随机接入失败可触发RRC连接重新建立。” (谷歌专利)

这一句话对权1后半段非常关键。

目标权1：

PCell experiences LBT failure event
→ re-establishment procedure.

CN102870450A：

UL PCell random access failure
→ RRC connection re-establishment.

所以它证明：

截止日前，在PCell上发生严重的上行接入失败后，不是继续无限重试，而是转入RRC连接重建，

这一恢复逻辑早已明确公开。

十二、为什么它能和CN107371273A非常自然地衔接

CN107371273A已经告诉技术人员：

UE在随机接入Preamble传输时可能由于LBT失败而根本不能完成UL发送；
这种LBT失败应通知MAC，并由MAC单独统计LBT失败次数。(谷歌专利)

CN102870450A则告诉技术人员：

UL PCell随机接入失败最终触发RRC连接重建。 (谷歌专利)

所以二者之间存在非常明确的技术桥：

LBT持续失败
→ PCell随机接入无法完成
→ UL PCell随机接入故障
→ RRC connection re-establishment.

其间唯一需要再补的是：

“什么条件下把连续LBT失败认定成需要处理的失败事件？”

而CN107371168A正好给出了：

LBT failure count ≥ configured threshold → trigger event。(谷歌专利)

十三、CN107770868A仍然非常有价值

CN107770868A
《一种控制信元取消方法、装置及终端》
申请人：中兴通讯
优先权日：2016-08-19
公开日：2018-03-06。(谷歌专利)

它公开：

执行LBT过程；
LBT失败时更新失败次数；
更新后失败次数未超过预设次数则继续执行LBT；
与预设次数进行比较。(谷歌专利)

这一段实际上就是非常简单的：

if LBT failure → failure_count++
if failure_count > threshold → special processing

因此对于F3/F4，它比一些复杂的系统文献更容易向无效合议组解释。

十四、为什么现在不再把CN107770868A放第一位

因为CN107371273A出现以后，证据链发生了质变。

CN107770868A：

LBT failure → failure count → threshold

非常强。

但是它没有明确写：

“LBT失败的信息告诉MAC层，并在MAC层设置LBT失败计数器。”

而CN107371273A恰恰明确写了这两件事。(谷歌专利)

所以当前更合理的分工是：

• CN107371273A：MAC接口与MAC LBT counter；

• CN107371168A：多种/all UL + failure count threshold；

• CN102870450A：PCell → RRC re-establishment；

• CN107770868A：补强“每次LBT失败更新失败次数并与预设次数比较”。

十五、CN108633097A：普通UL-LBT背景的补强文献

CN108633097A
《无线通信方法和用户设备》
申请人：北京三星通信技术研究有限公司、Samsung Electronics
优先权日：2017-03-24
公开日：2018-10-09。(谷歌专利)

它针对非授权频段UE的自动上行传输，明确涉及：

• UL transmission；

• UE获取LBT信息；

• 根据LBT信息确定LBT参数；

• 执行LBT；

• 基于LBT结果决定是否能够在自动上行资源发送。(谷歌专利)

因此如果需要证明：

LBT机制并不是只与PRACH相关，而是广泛应用于普通UL数据传输，

可以把它作为补充证据。

但因为CN107371168A已经对UL类型和整体传输统计公开得更直接，我目前只把CN108633097A列为B+级。

十六、目前最有用的逐项对照

◎ = 非常直接；● = 明确贡献；○ = 辅助；△ = 有关联但不宜称为逐字完整公开。

十七、目前最强的纯中文无效组合

组合A：CN107371273A + CN107371168A + CN102870450A

这是我现在最推荐的组合。

D1 — CN107371273A

解决：

LBT失败信息反馈到MAC
＋
MAC专门设置统计LBT失败/成功的计数器。(谷歌专利)

D2 — CN107371168A

进一步教导：

LBT适用于动态UL、半持续UL、RACH等多类上行传输；
可以基于UE整体传输统一统计；
LBT失败次数≥阈值即触发事件。(谷歌专利)

D3 — CN102870450A

进一步教导：

UL PCell随机接入失败可触发RRC connection re-establishment。 (谷歌专利)

组合后的技术链几乎就是：

UL transmission执行LBT
→ LBT失败
→ 将LBT失败结果通知MAC
→ MAC维护LBT失败计数
→ 跨UL transmission统计
→ LBT failure count达到阈值
→ 形成持续UL接入失败
→ 若发生于PCell
→ RRC连接重建。

十八、组合B：更强调“counter++”的方案

如果无效论证时希望对“收到一次失败就增加计数”说得更简单，可以采用：

CN107371273A
＋ CN107770868A
＋ CN102870450A

其逻辑是：

CN107371273A：

LBT failure → MAC；MAC设置LBT failure counter。(谷歌专利)

CN107770868A：

一次LBT failure → 更新失败次数 → 与预设次数比较。(谷歌专利)

CN102870450A：

UL PCell failure → RRC re-establishment。(谷歌专利)

这套组合的缺点是对“all UL transmissions”的覆盖弱于CN107371168A。

因此更稳的实际证据体系可以把CN107371168A也作为辅助文献列入，但不一定要求每一份都作为正式的创造性组合文献。

十九、目前是否已经找到单篇完全破坏权1新颖性的中文专利？

没有。

至少按我目前对Google Patents截止日前CN公报的反复检索，没有发现一篇单篇文献，在一个明确实施方案中同时无歧义公开：

① 下层向MAC提供适用于所有UL transmission的共同LBT failure indication；
② MAC每收到一次该指示即增加一个独立LBT failure counter；
③ counter≥threshold确定LBT failure event；
④ 该event发生在PCell；
⑤ 因此执行re-establishment。

所以目前中文专利路线，我更看好的是：

创造性组合攻击，而不是单篇新颖性攻击。

二十、权1真正剩余的“窄区别”已经很小

经过这一轮检索后，我认为最关键的剩余差异已经不再是：

• 是否知道LBT失败；

• 是否知道将LBT失败通知MAC；

• 是否知道MAC可以设置LBT failure counter；

• 是否知道LBT失败次数达到阈值；

• 是否知道多种UL传输进行LBT；

• 是否知道PCell UL失败后连接重建。

这些要素在2019-01-09以前的中文公报中都分别找到了。

目前最窄、最有争议的限定是：

把来自下层的LBT failure indication设计成一个“与UL transmission type无关”的共同指示，并以同一个MAC LBT counter跨不同UL transmission统一累计。

CN107371168A的“基于UE整体传输统计”已经非常接近这一思想，但它没有逐字公开“common lower-layer indication”。(谷歌专利)

二十一、后公开的超近文献进一步印证了这个差异在哪里，但必须排除

本轮还检到了后来非常接近甚至几乎逐字覆盖权1的中文公报，例如CN112753275A/B，其公开了NR-U下对LBT失败计数、最大阈值及MAC过程的处理。但其CN公开日为2021-05-04，虽然优先权在2018-09-26，按照你要求的“公开日在2019-01-09前”标准必须排除。(谷歌专利)

另外，CN114158127A等后公开文献甚至逐步写出了：

PHY执行LBT → LBT失败→PHY通知MAC→MAC counter +1→达到阈值→向RRC报告→RLF，

但这些中文公开同样晚于截止日，因此不能列为本轮的公开在先CN证据。(谷歌专利)

它们只适合用于理解技术演进，不能混入本轮截止日前先前技术集合。

最终推荐

如果现在就制作CN113273269B权1的中文专利无效检索表，我建议主证据顺序定为：

D1：CN107371273A — 2017-11-21
核心：LBT失败信息→MAC；MAC设置LBT失败/成功计数器。

D2：CN107371168A — 2017-11-21
核心：多种/整体UL transmission；LBT失败次数≥阈值。

D3：CN102870450A — 2013-01-09
核心：UL PCell随机接入失败→RRC连接重建。

D4：CN107770868A — 2018-03-06
核心补强：LBT失败一次就更新失败次数；达到预设次数阈值。

D5：CN108633097A — 2018-10-09
核心补强：常规非授权频段UL transmission的LBT机制。(谷歌专利)

其中，CN107371273A 是这一轮最值得进一步深挖全文、权利要求、附图和审查档案的新增文献。它对“LBT failure→MAC→专用LBT失败计数器”公开得异常接近目标权1，比我上一轮给出的CN107770868A单独作为前半段主证据明显更强。

以上属于专利检索及技术特征比对，不构成对无效结论的法律意见。

先给结论：如果“公开”是按新颖性意义理解，则不能说这三份对比文件的“组合”能够毫无异议地直接、无歧义公开B—E，因为新颖性原则上要求一份对比文件本身完整公开全部限定。
但如果问题是创造性/显而易见性，则我认为 R2-1817969 + R2-1816831 + TS 38.331 V15.3.0 是一组相当强的组合，能够形成非常完整的技术链条：

PHY/下层 → MAC报告LBT失败 → 对所有/不区分UL传输进行共同LBT失败监测 → LBT失败计数器累加 → 达到配置最大值 → 判定严重/持续LBT失败并触发RLF → 若发生于PCell/MCG → 按既有RRC机制执行连接重建。

不过，仍有2—3个需要通过组合和本领域技术人员常识补足的连接点，所以我不会评价为“毫无异议”。

目标权利要求1的B—E本身形成连续处理链：MAC从下层接收“用于所有UL传输”的LBT失败指示，收到后增加LBT失败计数器，达到阈值判定LBT失败事件，在PCell发生该事件时执行重建。

一、逐项评估

1. 特征B：基本可以组合出来，但这是第一个可争议点

R2-1816831非常明确地解决了“下层/PHY如何把LBT结果告诉MAC”的问题。文件指出，LBT是在PHY层执行，MAC本来不知道LBT结果，因此需要把LBT outcome指示给MAC；随后分别讨论了随机接入前导码、SR和configured grant。

尤其是文件结论明确提出：

• preamble因LBT失败 → 向MAC指示；

• SR因LBT失败 → 向MAC指示；

• configured grant因LBT失败 → 向MAC指示；

• Proposal 1为至少上述三种传输均向MAC报告LBT outcome。

这基本解决了B中的：

“UE的MAC实体”
“从下层接收”
“LBT失败指示”

三个要素。

真正有争议的是**“用于所有UL传输”**。

R2-1816831自己的文字是“at least for preamble、SR、configured grant”，而不是逐字写“all uplink transmissions”。

但R2-1817969正好补上这一点。其明确提出：

“For any uplink transmission, the UE need to perform a LBT operation”

并进一步强调LBT失败监测：

不应与某一种特定UL传输（RACH、SR、PUSCH等）绑定；
persistent LBT failures会同等影响all UL transmissions；
因而应有一个common RLM procedure对UL transmission中的LBT occurrence进行计数。

因此，把1816831的“PHY→MAC LBT outcome indication”与1817969的“不区分具体UL类型、all UL transmissions、common monitoring”结合，实际上已经非常接近：

由MAC从下层接收针对所有UL传输的一般化LBT失败指示。

但这仍然不是某一篇文件用一句话原样给出的，所以专利权人仍可以争辩：

R2-1816831只要求至少针对三类具体UL操作报告；
R2-1817969虽然提出common RLM，但没有明确规定该common RLM一定采用“PHY→MAC的统一失败指示”。

因此，B很强，但不宜称为“毫无异议的直接公开”。

2. 特征C：实际上比表面看起来更强

R2-1817969首先讨论了两种counter handling：

• Option 1：如果对应传输被LBT failure阻塞，增加counter；

• Option 2：不增加原对应counter。

随后文件指出，RAN1倾向于不增加preamble counter，但这样会延迟进入RLF，因此应当：

“call for a separate counter which counts the amount of LBT failures”

也就是专门设置一个独立的LBT failure counter。

更重要的是，随后其直接提出：

common RLM procedure counts LBT occurrences in UL transmissions

以及：

“introducing an additional counter for UL LBT failure monitoring”。

所以“收到一次LBT失败→LBT失败counter增加/计数一次”在功能上已经十分明确。

剩下唯一的小缺口是：

R2-1817969没有逐字写成“when the MAC entity receives the LBT failure indication, increment the LBT failure counter”。

但是R2-1816831已经明确规定LBT outcome由PHY传给MAC，而且MAC接收到NACK后采取相应动作。

因此组合后的逻辑是：

PHY报告LBT失败 → MAC获得该失败 → 1817969要求用独立counter统计LBT failures。

对于创造性判断而言，这个连接相当自然。

3. 特征D：这是组合中最强的一项

R2-1817969几乎逐字公开了“计数达到阈值”的机制：

如果连续发生的LBT failure数量达到网络配置的最大值，则可以declare radio link failure；

并正式Proposal：

引入一个additional counter用于UL LBT failure monitoring，
当连续UL LBT failures达到maximum number时，UE declares a radio link failure。

其附件拟加入TR 38.889的文字再次重复：

additional counter counts LBT failures；
consecutive LBT failures reaches a maximum number configured by network；
radio link failure can be declared。

这与D：

“LBT失败计数器大于或等于阈值时，判定LBT失败事件发生”

之间唯一可以做文字抗辩的是：

• 1817969称达到阈值后“declare RLF”；

• 权利要求先定义一个中间状态“LBT failure event”。

但从功能逻辑而言：

LBT failures计数 → max threshold → 产生需要上层处理的failure condition

已经完整公开。

甚至1817969比D走得更远，直接规定达到该阈值即可触发RLF。

所以D是我认为最难防守的特征。

4. 特征E：1817969 + TS 38.331组合非常顺

R2-1817969已经给出：

consecutive UL LBT failures达到最大数量 → declare RLF。

而TS 38.331 V15.3.0已经规定了MCG/PCell的标准RLF恢复路径。

TS 38.331规定，当：

• PCell上的T310到期；或者

• 来自MCG MAC的random access problem；或者

• MCG RLC达到最大重传次数，

则：

“consider radio link failure to be detected for the MCG”

并且在AS security已经激活的情况下：

“initiate the connection re-establishment procedure”。

同时，38.331定义PCell是MCG中的Primary Cell，Special Cell在MCG中就是PCell。

所以组合关系非常清楚：

1817969：LBT失败累计达到阈值 → RLF

＋

38.331：PCell/MCG发生RLF → RRC connection re-establishment

＝

PCell上的持续LBT失败达到阈值 → 触发RLF → 执行重建程序。

这已经非常接近E。

而且38.331还明确作出了MCG/PCell与SCG/PSCell不同处理：

• MCG/PCell RLF → connection re-establishment；

• SCG/PSCell RLF → SCG failure information procedure。

这一点反而对无效方非常有利，因为权利要求E恰恰限定的是PCell。

二、有没有“反向教导”？

有一段文字表面上很像反向教导，但我认为不构成真正的teaching away

最容易被专利权人利用的是R2-1817969中的这句话：

RAN1 prefers to not increment the preamble counter if the corresponding transmission is blocked by LBT failures.

以及结论中的：

“RAN1 … prefers to not increment counters if the corresponding uplink transmission is blocked by LBT failures.”

乍看似乎与C：

“收到LBT失败指示时增加LBT失败计数器”

方向相反。

但完整上下文恰好消除了这种反向教导。

因为1817969反对增加的是：

原有的、与特定UL传输过程绑定的counter，例如PREAMBLE_TRANSMISSION_COUNTER。

其马上解释：

如果不增加preamble counter会延迟RLF，
所以应设置一个separate counter which counts the amount of LBT failures。

然后进一步正式提出：

common RLM procedure counts LBT occurrences；
introducing an additional counter for UL LBT failure monitoring；
达到maximum number → declare RLF。

所以文件真正的教导是：

不要把LBT失败错误地算入原来的RA/SR业务counter；应另设一个专门的LBT failure counter。

这与涉案权利要求中的“LBT失败计数器”不仅不冲突，反而高度一致。

R2-1816831也不存在真正的反向教导

1816831明确说：

LBT失败时不增加PREAMBLE_POWER_RAMPING_COUNTER。

专利权人可能引用它说：

“LBT failure时文件明确教导counter不增加。”

但这种解释会混淆两种完全不同的counter：

1. PREAMBLE_POWER_RAMPING_COUNTER；

2. LBT failure counter。

前者的目的是功率爬升；后者的目的是统计持续LBT失败并判定链路异常。

1816831反对的是前者在LBT失败时增加，并没有反对另外建立LBT failure counter。

所以这也不构成对C的实质反向教导。

三、真正需要警惕的不是“反向教导”，而是三个组合连接点

如果我是专利权人，最可能攻击的是下面三个地方，而不是主张真正的teaching away。

第一，“at least三种UL传输”是否等于“所有UL传输”。
1816831本身只明确列举preamble、SR、configured grant；“所有UL传输”需要借1817969的“any UL transmission”“all UL transmissions”“not associated to any particular UL transmission”进行一般化。这个组合非常合理，但并非逐字公开。

第二，1817969的additional LBT counter是否明确属于MAC实体。
它提出common RLM/additional counter，但没有一句完全等同于“MAC收到下层指示时，由MAC增加LBT failure counter”。这一点要用1816831的PHY→MAC indication进行桥接。

第三，“达到LBT阈值→RLF→PCell重建”存在一个中间转换。
1817969直接说达到max LBT failures可declare RLF；38.331再规定MCG/PCell RLF进入re-establishment。因此E是两篇文件组合产生，而不是1817969一篇直接逐字给出。

这三个点决定了为什么我认为组合很强，但不应在无效请求中写成“毫无异议地直接公开”。

四、我建议的无效论证方式

最稳妥的是把 R2-1817969作为主对比文件，而不是R2-1816831。

理由是1817969已经一次性给出了整个核心思想：

所有UL传输均受到LBT影响 → 不区分具体UL transmission的common监测 → additional LBT failure counter → consecutive failures达到network-configured maximum → RLF。

然后：

R2-1816831只补B中的层间接口：

LBT由PHY执行，因此LBT outcome应由PHY/lower layer报告给MAC。

最后：

TS38.331只补E中的标准后续动作：

MCG/PCell RLF → connection re-establishment。

这样组合动机也非常强：R2-1816831与R2-1817969均来自同一次3GPP RAN2 #104会议、同一个NR-U LBT failure议题，前者专门讨论LBT outcome indication，后者专门讨论LBT failure monitoring/RLF，两者解决的是同一问题的相邻协议环节。R2-1816831的文件首页显示会议为2018年11月12–16日。 R2-1817969同样来自该次会议。

最终评价

**不存在足以破坏该组合动机的实质性反向教导。**所谓“不增加counter”的文字，针对的是既有preamble/SR等传输counter，全文反而明确要求另设LBT failure counter，因此从完整技术教导看，对C是正向教导，而不是反向教导。

但是我也不建议在无效理由中使用“B—E已经被三文件组合毫无异议直接公开”这种表述。更严谨、也更不容易被专利权人抓住的是：

R2-1817969已经公开了不区分具体UL传输的共同LBT失败监测、LBT失败专用计数器以及达到配置最大值后触发RLF；R2-1816831进一步明确给出了PHY下层向MAC实体报告LBT失败结果的机制；依据当时现行的TS 38.331，MCG/PCell发生RLF后UE执行RRC连接重建。因此，本领域技术人员面对持续UL LBT失败检测问题，有明确动机将上述技术教导结合，并可在不付出创造性劳动的情况下得到B—E的完整处理链。

**就B—E本身而言，我会把该组合评为“创造性无效攻击强度：较高，约80–88%”，而不是“100%无争议”。**其中真正值得进一步补强的只有两个点：**①一份2019年1月9日前文件明确写出“common LBT failure indication for all UL transmissions”；②一份文件明确写出“MAC收到该indication即increment专用LBT failure counter”。**如果能再找到这两点中的任意一点，整体论证会明显接近“闭环”。

如权利要求1所述的UE，其特征在于，所述至少一个处理器还经配置以执行所述计算机可执行指令以：在判定所述LBT失败事件发生后，将所述UE的活动带宽部分BWP切换到另一BWP。

如权利要求1所述的UE，其特征在于，所述至少一个处理器还经配置以执行所述计算机可执行指令以：在判定所述LBT失败事件发生后，由所述UE的所述MAC实体向上层指示LBT失败问题。

如权利要求3所述的UE，其特征在于，所述至少一个处理器还经配置以执行所述计算机可执行指令以：执行无线电链路失败RLF恢复程序。

如权利要求4所述的UE，其特征在于，在执行重建程序时，所述至少一个处理器还经配置以执行所述计算机可执行指令以：传输将重建原因指示为LBT失败的无线电资源控制RRC重建请求消息。

如权利要求4所述的UE，其特征在于，所述至少一个处理器还经配置以执行所述计算机可执行指令以：当所述LBT失败事件发生在主辅小区PSCell中时，向主节点传输指示所述LBT失败问题的辅小区组SCG失败报告。

如权利要求1所述的UE，其特征在于，所述至少一个处理器还经配置以执行所述计算机可执行指令以：接收指示所述阈值的配置。

如权利要求1所述的UE，其特征在于，所述至少一个处理器还经配置以执行所述计算机可执行指令以：当所述阈值被重新配置时，重置所述LBT失败计数器。

如权利要求1所述的UE，其特征在于，所述至少一个处理器还经配置以执行所述计算机可执行指令以：当所述UE切换到另一BWP时，重置所述LBT失败计数器。

如权利要求1所述的UE，其特征在于，所述至少一个处理器还经配置以执行所述计算机可执行指令以：当所述MAC实体被请求重置时，重置所述LBT失败计数器。

一种由用户设备UE执行的用于先听后说LBT失败检测的方法，所述方法包括：由所述UE的媒体访问控制MAC实体从下层接收用于所有上行链路UL传输的LBT失败指示； 当所述MAC实体接收到所述LBT失败指示时，增加LBT失败计数器； 当所述LBT失败计数器大于或等于阈值时，判定LBT失败事件发生；以及执行重建程序，以响应确定主小区PCell发生了LBT失败事件。

如权利要求11所述的方法，其特征在于，还包括：在判定所述LBT失败事件发生时，将所述UE的活动带宽部分BWP切换到另一BWP。

如权利要求11所述的方法，其特征在于，还包括：在判定所述LBT失败事件发生后，由所述UE的所述MAC实体向上层指示LBT失败问题。

如权利要求13所述的方法，其特征在于，还包括：执行无线电链路失败RLF恢复程序。

如权利要求14所述的方法，其特征在于，在执行重建程序时，还包括：传输将重建原因指示为LBT失败的无线电资源控制RRC重建请求消息。

如权利要求14所述的方法，其特征在于，还包括：当所述LBT失败事件发生在主辅小区PSCell中时，向主节点传输指示所述LBT失败问题的辅小区组SCG失败报告。

如权利要求11所述的方法，其特征在于，还包括：接收指示所述阈值的配置。

如权利要求11所述的方法，其特征在于，还包括：当所述阈值被重新配置时，重置所述LBT失败计数器。

如权利要求11所述的方法，其特征在于，还包括：当所述UE切换到另一BWP时，重置所述LBT失败计数器。

如权利要求11所述的方法，其特征在于，还包括：当所述MAC实体被请求重置时，重置所述LBT失败计数器。

分析

综合你上传的无效检索材料，我认为：权利要求1的无效前景较强，但核心应放在创造性，而不是单篇文献破坏新颖性。 当前材料将权利要求1拆成A—E五组特征，其中真正决定成败的是“下层→MAC的LBT失败指示—MAC计数—阈值—PCell失败—重建”这条链。

一、概率判断

我的审慎评估如下：

附件原报告给出的数值是：单篇新颖性约24%、创造性约85%、综合无效概率84%，合理区间78%–89%。我认为这个区间基本合理，并没有明显高估。

关键原因是：**目前确实没有发现一篇截止日前文献能够稳妥、直接、无歧义地公开A—E全部技术特征。**因此，不适合把权利要求1的无效押在新颖性上。

二、有没有“一篇对比文件公开了大部分技术特征”？

有。

如果把3GPP会议文稿也作为对比文件，我认为目前的最佳单篇最接近现有技术是R2-1817969《Handling LBT failures》。

它已经公开或非常接近公开：

• 多种/任一UL发送均受到LBT影响；

• 对UL LBT失败进行共同监测；

• LBT失败进行累计；

• 连续失败次数达到网络配置最大值；

• 达到最大值后宣告RLF。

附件也明确把R2-1817969确定为最接近现有技术，原因就是它已经把“所有UL—共同监测—计数—最大值—RLF”这条核心链串得最完整。

逐项看：

附件的逐项矩阵也是这个结论。

所以可以准确地说：

R2-1817969已经公开了权利要求1绝大部分“实质技术逻辑”，但没有单篇完整公开权利要求1。

其最大的两个缺口是：

1. **“由下层/PHY向MAC提供用于所有UL transmission的LBT failure indication”**的明确接口；

2. **“PCell发生该LBT failure event后执行RRC re-establishment”**的最后桥接。

三、如果只看“专利文献”，也有一篇非常接近大部分特征

如果不希望依赖3GPP会议稿，而只问专利对比文件，我会特别注意：

US20180048498A1

这篇单篇已经同时涉及：

• PHY向MAC提供TX-NACK/未传输反馈；

• 未发送原因包括信道忙、LBT/CCA失败；

• 统计因信道忙/LBT而未传输次数；

• 与配置阈值比较；

• 涉及“所有因未取得信道而失败的上行传输”的范围；

• UL对象包括TB、MAC PDU、MAC CE等。

也就是说，它实际上已经覆盖了B、C、D的大部分内容，而且“all UL”范围较宽。

但它仍有两个明显缺陷：

• “收到PHY/MAC失败反馈→立即增加专用LBT failure counter”的因果关系没有目标权利要求写得那么紧；

• 完全没有公开PCell发生LBT失败事件后执行RRC重建。

附件也因此认为它适合与US20120281548A1形成两文献组合，而不适合单篇破坏新颖性。

四、其实中文专利证据现在也已经很强

附件后面的再次检索找到了一篇非常重要的新文献：

CN107371273A

它明确公开：

UE发生LBT失败后，将LBT失败信息告诉MAC层；

而且进一步明确：

MAC层分别设置统计LBT失败或成功的计数器。

这已经直接击中了目标权利要求中最难找的**“LBT failure → MAC → LBT failure counter”**。

但它的主要场景还是随机接入Preamble，而且没有完整规定：

• 每收到一个failure indication就counter+1；

• counter≥threshold；

• PCell失败后RRC重建。

附件对此也作了明确保留。

再结合：

• CN107371168A：多种UL transmission、UE整体LBT统计、LBT失败次数≥阈值；

• CN102870450A：UL PCell随机接入失败→RRC connection re-establishment；

纯中文证据已经可以形成一条相当完整的创造性攻击链：

CN107371273A + CN107371168A + CN102870450A

这也是附件后续检索最终推荐的中文组合。

五、我认为真正决定无效成败的是一个很窄的区别

经过现有英文、中文、韩文以及3GPP文献反复比对以后，权利要求1已经不能把创新点宽泛地说成：

“LBT失败计数”“失败阈值”“PCell失败”“RRC重建”。

这些基本都已经被截止日前现有技术分别公开。

真正剩余的最窄争点是：

将来自PHY/下层的LBT failure indication设计成一个跨不同UL transmission类型统一适用的MAC失败指示，并由同一个MAC LBT failure counter统一累计。

附件后续中文检索也得出了几乎相同的结论。

这反过来也是权利要求1创造性风险高的原因：区别已经被压缩成一个协议接口和计数机制的统一化设计，而不是新的无线链路恢复原理。

六、最终结论

第一，权利要求1被成功无效的概率，我给约84%，合理区间约78%–88%。

第二，目前没有一篇文献足以让我建议直接主张“权利要求1全部技术特征被单篇公开”，所以新颖性不是主攻方向。

第三，确实存在公开“大部分技术特征”的单篇文献。如果包括3GPP文献，首选R2-1817969；如果仅限专利文献，US20180048498A1属于单篇覆盖范围最广的一类文献，而CN107371273A则是对最关键的“LBT失败→MAC→LBT失败计数器”接口公开最直接的中文专利之一。

**第四，最强无效路线仍然是创造性：R2-1817969 + R2-1816831 + TS 38.331 V15.3.0。**附件也将这一组合作为主组合，并以R2-1817968补强“所有UL共同计数”。

从无效请求书的实战角度，我会把R2-1817969作为最接近现有技术，CN107371273A作为非常重要的专利旁证/替代起点；这样比单纯依赖三篇3GPP材料更抗“会议提案未采纳、公开性不足、多文献拼接”的抗辩。

我把你所说的“毫无意义地无效”按“能否毫无疑义/毫无争议地无效权利要求1”来理解。以下只基于你上传的 CN113273269B、R2-1816831、R2-1817969、3GPP TS 38.331 V15.3.0 进行分析，不额外引入新的对比文件。

一、结论先行

结论是：目前这三份对比文件的组合，对权利要求1的创造性攻击相当强，但我不建议主张“任一单篇对比文件已经毫无疑义地完整公开权利要求1，从而直接破坏新颖性”。

其中，R2-1817969 是最适合作为最接近现有技术的文件。它已经非常接近权利要求1的实质核心：针对并非特定UL传输类型的LBT失败进行统一监测、设置额外LBT失败计数器、连续LBT失败达到网络配置的最大值后宣告RLF。

R2-1816831 恰好补上 R2-1817969 最明显的缺口——“LBT结果由物理层/下层通知MAC层”。该文件明确指出LBT在物理层执行、MAC不知道LBT结果，因此物理层应当将LBT outcome通知MAC，并分别将其应用于前导码、SR和configured grant。

**TS 38.331 V15.3.0 则补上“PCell发生RLF以后执行RRC connection re-establishment”这一标准化后果。**该规范明确规定：PCell中T310到期、MCG MAC随机接入问题或者MCG RLC达到最大重传次数时，UE认定MCG发生RLF；在AS安全已激活的情况下，UE启动连接重建程序。

因此，比较合理的无效路线不是：

R2-1817969 单篇 → 权利要求1无新颖性

而是：

R2-1817969 + R2-1816831 + TS 38.331 V15.3.0 → 权利要求1不具备创造性。

二、先把权利要求1准确拆开

CN113273269B权利要求1实际上包含以下完整技术链：

A：一种UE；

B：具有一个或多个非暂时性计算机可读介质，其上包含计算机可执行指令；

C：至少一个处理器与上述介质耦接，并执行该指令；

D：由UE的MAC实体从下层接收用于所有UL传输的LBT失败指示；

E：MAC实体收到该LBT失败指示时，增加LBT失败计数器；

F：当LBT失败计数器≥阈值时，判定LBT失败事件发生；

G：响应于确定PCell发生LBT失败事件，执行重建程序。

这正是授权权利要求1的文字内容。

尤其需要注意，说明书对“用于所有UL传输”的解释非常宽：LBT失败指示可以与具体UL传输类型无关，对于不同UL传输操作，PHY可向MAC提供共同的LBT失败指示。

特征比对表

符号含义：✅＝明确/直接公开；△＝部分公开、实质接近或需要技术人员结合上下文；❌＝未见明确公开。

三、R2-1816831到底公开了什么

R2-1816831的价值非常集中，而且非常重要。

它首先明确指出：LBT是在物理层执行的，而MAC层不知道LBT outcome，因此LBT outcome需要从物理层通知MAC层。

而且这不是只针对一种UL操作。该文件进一步分别讨论了前导码、SR以及configured grant，最后明确提出：

LBT outcome应当通知MAC层，至少针对preamble、SR以及configured grant transmission failure。

所以，它对于权利要求1的特征D前半部分——

“由MAC实体从下层接收LBT失败指示”

几乎是正面、直接的对应。

但它的缺陷也很明显：其目的主要是解决前导码功率爬升、RAR window、SR prohibit timer和configured grant timer的问题，并没有提出权利要求1那种：

LBT failure indication → LBT failure counter +1 → threshold → persistent LBT failure event → RLF/re-establishment

因此，R2-1816831绝对不是适合单独攻击权利要求1新颖性的文件，它更适合作为R2-1817969的补充文献。

四、R2-1817969是目前最重要的一篇

这篇文件和权利要求1的实质思想已经非常接近。

它明确说：

对于任何上行链路传输（any uplink transmission），UE需要执行LBT；LBT失败时传输可能被丢弃。

之后先讨论针对RA单独设置LBT失败counter的方案，也讨论针对SR设置单独counter，但随后认为这种按具体UL程序分别处理的方式收益有限。

最关键的是随后这几句话：

LBT failure monitoring不应关联于任何特定UL transmission，例如RACH、SR、PUSCH等；持续LBT失败时所有UL transmissions都会同样受到影响；因此应当存在一个common RLM procedure，用于count LBT occurrences in UL transmissions，并在LBT failure过多时采取动作，例如在高层宣告RLF。

紧接着它给出了Proposal 2：

引入additional counter用于UL LBT failure monitoring，当连续UL LBT failures达到maximum number时，UE declares a radio link failure。

这与目标专利的：

所有UL → 共同LBT失败指示 → LBT failure counter → threshold → LBT failure event

已经高度接近。

真正的区别主要剩在一点：

R2-1817969没有明确把这个共同LBT计数器放在MAC实体中，也没有明确写出“MAC从PHY接收到每个LBT failure indication时加1”。

事实上，在R2-1817969全文中没有出现“MAC”这一明确层间机制。对文件进行全文检索也未找到“MAC”用语。

这正是为什么R2-1816831特别关键：它几乎正好提供了R2-1817969缺少的层间信令接口。

五、TS 38.331补的是最后一个“RLF→重建”链条

TS 38.331 V15.3.0是2018年9月的Release 15 RRC规范。

它本身没有公开LBT。全文精确检索“LBT”没有得到匹配。

所以绝不能用它来证明“LBT failure counter”本身。

但它对权利要求1最后一步非常有用。规范5.3.10.3明确规定，在PCell发生特定故障后，UE认定MCG RLF；如果AS安全已经激活，则：

initiate the connection re-establishment procedure as specified in 5.3.7.

因此，把R2-1817969的：

连续UL LBT失败达到阈值 → declare RLF

放进TS 38.331已有的：

PCell/MCG RLF → RRC connection re-establishment

恢复框架中，技术上的衔接非常自然。

六、能否用R2-1817969单篇直接破坏新颖性？

我的判断是：不够稳。

最主要的原因不是计数器或者阈值。R2-1817969对这些已经很强。

真正的问题是权利要求1把几个概念限定成了一条非常具体的层间链：

PHY/下层 → MAC LBT indication → MAC共同LBT counter → threshold → LBT failure event → PCell → re-establishment。

R2-1817969虽然已经公开了：

所有UL都受LBT影响 → common monitoring → count LBT occurrences → maximum configured number → RLF

但没有明确写：

“PHY向MAC给出用于所有UL transmission的共同LBT failure indication，并且MAC在收到该indication时使counter增加”。

对于新颖性而言，这个缺口不宜靠另一篇文献或者一般推理来补。

因此，我不会把“R2-1817969单篇破坏权利要求1新颖性”作为主攻理由。可以写成辅助理由，但风险明显较高。

七、三篇组合攻击创造性则明显更强

以 R2-1817969作为最接近现有技术，逻辑非常顺。

R2-1817969已经提出：不应为RACH、SR、PUSCH分别设置孤立的LBT失败机制，而应当建立统一的LBT failure monitoring机制，对UL transmission中的LBT occurrences计数，达到网络配置的maximum number后宣告RLF。

与权利要求1相比，最重要的区别可以归纳为：

“怎样把物理层发生的各类UL LBT失败提供给负责上述共同失败监测/计数的协议实体。”

R2-1816831恰恰明确告诉本领域技术人员：LBT在PHY执行，MAC不知道结果，因而应当由PHY把LBT outcome通知MAC；而且这一机制明确用于preamble、SR和configured grant等不同UL操作。

因此，将R2-1816831的PHY→MAC LBT indication作为R2-1817969的common LBT failure counter的输入，在技术逻辑上几乎不存在结构冲突，也没有表现出需要创造性劳动才能完成的重新设计。

随后，一旦R2-1817969按照连续LBT failures达到阈值宣告RLF，TS 38.331已经给出了PCell/MCG发生RLF后的标准动作——启动RRC connection re-establishment。

所以完整组合关系可以表示为：

R2-1816831

PHY执行LBT
↓
PHY把LBT失败/outcome通知MAC

+ R2-1817969

不同UL transmission统一监测
↓
common LBT failure counter
↓
连续失败达到网络配置最大值
↓
declare RLF

+ TS 38.331

PCell/MCG发生RLF
↓
initiate RRC connection re-establishment

这条技术链和权利要求1的功能链已经高度重合。

八、唯一还建议补强的是“处理器+非暂时性存储介质”

目前三份3GPP文件都不是设备硬件架构专利，而是协议/标准贡献文件，因此均没有明确按照权利要求1的形式写：

非暂时性计算机可读介质 + 可执行指令 + 与其耦接的处理器。

这几个特征本身属于非常典型的通用计算设备实现形式，目标专利说明书自身也把相关算法描述为可由硬件、软件或二者组合实现，并介绍了微处理器、通用计算机、ASIC、DSP等常规实现方式。

但在无效程序的证据组织上，不建议仅凭一句“这是公知常识”带过。更稳妥的做法是再加入一份2019年1月9日前公开的UE/无线设备文献，直接公开：

processor + memory/non-transitory computer-readable medium + instructions

用它专门填补A/B/C形式性硬件特征。

这不会改变技术核心，但会让组合证据链更完整。

九、最终评价

新颖性方面：目前没有一篇我愿意认定为“毫无疑义地直接、完整公开权利要求1全部技术特征”的对比文件。

R2-1816831只解决“PHY/下层→MAC LBT outcome”；R2-1817969解决“所有UL的共同LBT失败监测+计数器+阈值+RLF”；TS 38.331解决“PCell/MCG RLF→重建”。三者明显互补，而不是其中一篇完全包含另外两篇的内容。

创造性方面：这组证据的攻击力度明显较强。特别是R2-1816831与R2-1817969不仅都属于NR-U/LBT同一技术领域，而且均来自同一次3GPP RAN WG2 #104会议（2018年11月12–16日）。R2-1816831的文首对此有明确记载， R2-1817969也记载了相同会议和日期。 这会明显有利于论证本领域技术人员具有将二者结合的技术动机。

目标专利所记载的最早优先权日为2019年1月9日。 从三份文件表面的版本/会议日期看，均早于该日期。但在正式无效请求中，仍应另外建立3GPP文件在2019年1月9日前已经向公众可获得的完整证据链，不能只依赖Word文件首页的会议日期。

因此，我对目前证据的最终定性是：

“不足以非常稳妥地以单篇文献破坏权利要求1新颖性；但以R2-1817969为最接近现有技术，结合R2-1816831和TS 38.331攻击创造性，是目前非常有竞争力的无效路线。权利要求1存在较高的创造性无效风险，但还没有达到‘无需补证、毫无争议必然无效’的程度。”

其中最值得进一步补强的只有两个环节：**第一，找一份2019-01-09前明确公开processor + non-transitory medium的UE文献；第二，把R2-1816831、R2-1817969的3GPP FTP上传时间/公开可获取时间做成正式证据链。**完成这两点后，这一组创造性无效理由会明显更加完整。

截止2019年1月9日的“全UL通用LBT失败指示”与“MAC接收后递增专用LBT失败计数器”公开证据检索报告

执行摘要

本报告以2019年1月9日（含）以前已经能够向公众获得的文件为时间门槛，优先检索3GPP RAN1/RAN2会议文档、3GPP TS/TR以及2016年至该截止日之前公开的专利文献，并以涉案权利要求1的技术链为核对基准：

B：UE的MAC实体从下层接收用于所有UL传输的LBT失败指示；
C：MAC实体接收到该指示时增加LBT失败计数器；
D：计数器达到阈值时判定LBT失败事件；
E：PCell发生该事件时执行重建程序。
涉案CN113273269B的权利要求1确实如此限定。fileciteturn0file0

核心检索结论

关于要求①——“对所有UL传输通用的LBT失败指示”的单一原始出处：本次检索没有发现截止2019年1月9日已经公开、且在同一文件中直接、明确、无歧义同时记载以下全部内容的文件：

all UL transmissions + common LBT failure indication + lower layer/PHY → UE MAC

最接近的是同一次RAN2 #104会议上的两份文件互补组合：

·       ZTE，R2-1816831《LBT outcome indication》明确记载：LBT由PHY执行，MAC不知道结果，因此PHY/L1的LBT outcome应向MAC指示；并明确覆盖preamble、SR、configured grant三类UL传输。但其表述是“at least for”这三类，并没有写成“all uplink transmissions”，也没有明确说这些不同UL类型使用的是一个common indication。fileciteturn0file2

·       Ericsson，R2-1817969《Handling LBT failures》则明确写出“For any uplink transmission”、持续LBT失败时“all UL transmissions are equally affected”，并提出不与RACH/SR/PUSCH等特定传输绑定的“common RLM procedure”。但是它没有进一步明确规定这个common procedure的输入恰好是“由PHY向MAC发送的一个common LBT failure indication”。fileciteturn0file3

因此，①能够被R2-1816831 + R2-1817969非常自然地组合得到，但目前不能说已经找到一份截止日以前的单一文件逐字、完整公开①。

关于要求②——“MAC收到该指示时增加专用LBT失败计数器”：本次检索同样没有发现截止日以前的一份单一公开文件明确写成完整的因果链：

lower-layer LBT failure indication received by MAC → MAC increments a dedicated/common LBT failure counter

最接近的证据仍然是：

·       R2-1816831：明确“PHY/LBT outcome → MAC”，但没有专用LBT failure counter；fileciteturn0file2

·       R2-1817969：明确“separate/additional counter counts LBT failures”“additional counter for UL LBT failure monitoring”，且达到最大连续失败数后触发RLF；但没有明确“由MAC维护”，也没有写出“upon receiving the lower-layer indication, increment”。fileciteturn0file3

·       US20180176961A1：在2018年6月21日已经公开“LBT表明信道占用→UE增加counter→达到设定值判定RA失败”的机制；但它是RACH/随机接入专用、UE本地执行LBT后的counter逻辑，不是PHY→MAC indication触发MAC递增。[1]

值得特别注意的是，涉案专利家族后来的公开文本恰好完整写出了①和②：其优先权日为2019年1月9日，但PCT申请到2020年1月8日才提交，WO2020143672A1于2020年7月16日才公开。因此，除非另有证据证明2019年1月9日的美国临时申请62/790,099或相同内容在当天已经以其他方式向公众公开，否则该文本本身不能作为2019年1月9日以前的公开文献。fileciteturn0file0 [2]

综合而言：

换言之，目前证据最适合用于“创造性/显而易见性组合”攻击，而不是宣称某一份截止日前文件已经毫无争议地单独预见B+C。

检索口径与检索策略

时间与公开性的筛选标准

本次检索将“2019年1月9日（含）之前公开”理解为：必须能够证明文件内容在该日期之前已经向公众可获得。对于3GPP会议贡献，重点核查会议文档及3GPP公开FTP/会议档案；对于专利，则以公开日作为本报告判断“已经公开”的基本门槛，而不把更早的优先权日或尚未公开的临时申请自动视为公众公开。

这一点尤其影响涉案专利本身。CN113273269B记载其要求2019年1月9日美国临时申请62/790,099的优先权，名称为“Lower Layer Indications for LBT Results”；但对应PCT的公开日是2020年7月16日。fileciteturn0file0 Google Patents对WO2020143672A1也显示：priority 2019-01-09、filing 2020-01-08、publication 2020-07-16。[2]

因此，本报告不会把“2019-01-09 priority”误写成“2019-01-09 publication”。

针对3GPP的检索字符串

实际检索围绕RAN2 #103、#103bis、#104以及TR 38.889进行，核心字符串包括：

site:3gpp.org/ftp/TSG_RAN/WG2_RL2 "LBT outcome" MAC

site:3gpp.org/ftp/TSG_RAN/WG2_RL2 "LBT failure" "additional counter"

site:3gpp.org/ftp/TSG_RAN/WG2_RL2/TSGR2_104 "LBT outcome"

site:3gpp.org/ftp/TSG_RAN/WG2_RL2/TSGR2_104 "Handling LBT failures"

site:3gpp.org "R2-1816831"

site:3gpp.org "R2-1817969"

site:3gpp.org "R2-1816684"

site:3gpp.org "R2-1814009"

site:3gpp.org "R2-1811282"

site:3gpp.org "LBT failure" "common RLM"

site:3gpp.org "consecutive LBT failures" counter

site:3gpp.org "LBT failure indication" "MAC layer"

site:3gpp.org "all UL transmissions" LBT

时间集中在2016-01-01至2019-01-09，尤其关注2018年8月RAN2 #103、2018年10月#103bis、2018年11月#104以及2018年12月形成的TR 38.889 V16.0.0。

3GPP官方RAN2会议档案可以确认#103bis和#104时期的TDoc在3GPP FTP中按会议存档；例如#103bis档案中R2-1814009的文件记录在2018年9月底已经出现，而#104档案中的文件在会议召开前已经开始上传。[3]

针对Google Patents的检索字符串

本次采用的专利检索概念组合包括：

"LBT failure" "MAC layer" counter

"LBT failure indication" MAC counter

"LBT outcome" "MAC layer" increment

"physical layer" "LBT failure" MAC counter

"LBT failure" "dedicated counter"

"LBT failure" "separate counter"

"listen before talk" counter "random access failure"

"LBT" "all uplink transmissions"

"LBT failure indication" "lower layer"

"LBT failure" MAC PHY 2017

"LBT failure" MAC PHY 2018

同时用网页限定：

site:patents.google.com/patent/ "LBT failure" "MAC layer" counter

site:patents.google.com/patent/ "LBT failure indication" "counter"

site:patents.google.com/patent/ "LBT outcome" MAC

site:patents.google.com/patent/ "listen-before-talk" "increment" counter

专利候选以公开日在2016-01-01至2019-01-09之间为主要过滤条件；优先权较早但公开日晚于截止日的文件单独标为“后公开、不能直接满足时间条件”。

对“所有UL传输的通用LBT失败指示”的原始出处检验

R2-1816831：下层到MAC的来源最明确，但“all/common”不足

完整引用：

3GPP TSG RAN WG2 NR #104, R2-1816831, ZTE, LBT outcome indication, Spokane, USA, 12–16 November 2018, Agenda Item 11.2.1.1, Document for Discussion and Decision, pp. 1–2. fileciteturn0file2

这份文件是目前找到的截止日前最直接的“LBT结果由下层/PHY通知MAC”原始文献之一。

原文首先说明：

“However, the LBT is performed in the physical layer, the MAC layer is not aware of the LBT outcome. Therefore, the LBT outcome may need to be indicated to the MAC layer.”

逐句翻译：

“但是，LBT是在物理层执行的，MAC层并不知道LBT的结果。”
“因此，可能需要将LBT结果指示给MAC层。”

这已经非常明确地给出了涉案B中的两个核心关系：

PHY/lower layer执行LBT → MAC需要接收LBT outcome。 fileciteturn0file2

针对随机接入前导码，文件进一步写道：

“When preamble is not transmitted due to LBT failure, the LBT outcome should be indicated to the MAC layer.”

翻译：

“当前导码由于LBT失败而没有发送时，应当将LBT结果指示给MAC层。”

对于SR：

“When SR transmission is blocked due to LBT failure, LBT outcome should be indicated to the MAC layer.”

翻译：

“当SR发送由于LBT失败而被阻塞时，应当将LBT结果指示给MAC层。”

对于configured grant：

“When configured grant transmission/retransmission is blocked due to LBT failure, LBT outcome should be indicated to the MAC layer.”

翻译：

“当配置授权的发送/重传由于LBT失败而被阻塞时，应当将LBT结果指示给MAC层。”

最后的Proposal 1是：

“LBT outcome should be indicated to the MAC layer, at least for preamble transmission failure, SR transmission failure, and configured grant transmission failure due to LBT.”

逐句译为：

“应当将LBT结果指示给MAC层，至少针对由于LBT导致的前导码发送失败、SR发送失败以及配置授权发送失败。”

这里的“at least”非常重要。它说明作者并未将适用范围封闭在三类传输上，而且有向其他UL传输扩张的技术方向；但是从“直接且无歧义公开”的严格文本角度，“至少A、B、C”仍然不能自动等同于“所有UL传输”。fileciteturn0file2

对应权利要求的评价为：