好的，作为一名资深专利代理师，我将严格遵循您的要求，对目标专利的权利要求技术特征与对比文件进行详尽的比对分析。
**对比文件名称：** 2011-08-25_JP2011524127A_发明专利_JP2011524127A Cell dependent multigroup hybrid automatic repeat request method for multicast in a wireless network
**目标专利名称：** 0721创新音速CN201310722317.1(CN103906081B)_在无线通讯系统中小小区增强的方法及装置
**本次调用的模型名称：** 待调用模型
---
### 特征比对表格
| 技术特征描述以及公开性判断结果 | 对比文件原文引用 | 公开性论述 |
| 技术特征A：用于一使用者设备中，所述方法包括，连接至超过一个的服务小区 | **《隐含公开》** <br><br>对比文件图1及相关描述，例如段落[0021]和[0022]中，明确描述了客户端/接收机105可以通过无线接入点/基站（AP/BS）110连接到网络，并且这些AP/BS服务于不同的“小区”（cell）。例如，[0021]: “...複数のＡＰｓ／ＢＳ１１０に接続されており、サービスエリアを増強する複数のセルに役立つ。” (连接到多个AP/BS，服务于多个小区以增强服务区域)。[0022]: “マルチキャストグループＸに対するソースデータ並びにマルチキャストグループ１ＸにおけるＡＲＱ要求と再送信されたデータは、セル１において送信される。... 他のグループ（２Ｘ、．．．、ＮＸ１、．．．）に対するＡＲＱ要求及び再送信されたデータは、セル１において送信されない。”（对于多播组X的源数据以及对于多播组1X的ARQ请求和重传数据在小区1中发送... 对于其他组（2X，...，NX1，...）的ARQ请求和重传数据不在小区1中发送）。这隐含了客户端/接收机为了接收不同多播程序或参与不同ARQ过程，需要同时与一个或多个小区（服务小区）关联。 | 对比文件描述了客户端（相当于使用者设备）参与的无线网络环境，其中有多个AP/BS构成多个小区。虽然目标专利中的“连接”可能指RRC连接状态，但对比文件中的客户端为了接收多播数据和进行ARQ交流，需要与特定AP/BS关联，并可能同时监听来自不同小区的多播数据，这隐含了连接至超过一个服务小区的概念。 |
| 技术特征B：其中无线电承载和所述超过一个的服务小区之间的配对根据由网络提供的信息来配置 | **《隐含公开》** <br><br>对比文件段落[0022]和[0023]描述了ARQ多播组地址的生成方法，该地址依赖于AP/BS的MAC地址或IP地址。[0023]: “本発明において、各セルは、制御メッセージ交換（例えば、プログラムＸに対するＡＲＱ要求と再転送）のための別々のセル依存性マルチキャストアドレスを有する。” (在本发明中，每个小区具有用于控制消息交换（例如，针对程序X的ARQ请求和重传）的单独的小区依赖性多播地址。) [0024]: “セルＮにおけるプログラムＸに対するＡＲＱマルチキャストアドレスは、プログラムＸのソースデータマルチキャストグループアドレス及びセルＮに対するＡＰ／ＢＳのメディアアクセスコントロール（ＭＡＣ）アドレス又はＩＰアドレスから復号される。”(小区N中程序X的ARQ多播地址从程序X的源数据多播组地址和小区N的AP/BS的MAC地址或IP地址中解码出来)。这实质上是将“程序X的数据”（可视为一种数据类型，类似于无线电承载）与“小区”（服务小区）通过AP/BS地址（网络信息）进行配对。该配对信息由网络侧（AP/BS、ARQ服务器）的配置决定。 | 目标专利中的“无线电承载”对应对比文件中的“多播程序X的数据”。“服务小区”对应“小区N”。对比文件公开了多播数据流（无线电承载）与特定ARQ多播组（隐含与服务小区关联）的配对关系，该配对的确定依赖于AP/BS的MAC/IP地址，这些地址是由网络配置的。这与目标专利的B特征高度吻合，因此隐含公开。 |
| 技术特征C：从一特定无线电承载的一较高优先数据抵达时触发一缓冲状态报告 | **《未公开》** <br><br>对比文件全文未涉及“缓冲状态报告（BSR）”以及基于特定无线电承载、数据优先级或新数据到达触发的机制。（例如，段落[0027]描述了ARQ请求的触发是基于数据包丢失，而非优先级或缓冲状态）。 | 对比文件的技术核心是基于多播的ARQ/HARQ的恢复机制，与LTE/LTE-A中的上行调度请求和缓冲状态报告机制完全不同。对比文件中没有公开、暗示或涉及任何关于“缓冲状态报告触发”的内容。 |
| 技术特征D：在对应所述特定无线电承载的一特定服务小区中传送对应所述缓冲状态报告的一媒体存取控制控制单元 | **《未公开》** <br><br>对比文件未公开BSR，也未公开用于传送BSR的MAC控制单元（MAC CE）。对比文件中与MAC层相关的描述（例如，段落[0023]提到“メディアアクセスコントロール（MAC）アドレス”）仅指MAC地址，而非MAC CE。 | 同特征C的分析，对比文件没有BSR相关的概念，自然不会公开在其中传送MAC CE。 |
| 技术特征E：其中所述媒体存取控制控制单元包括可以在所述特定服务小区中传送的缓冲资料的状态 | **《未公开》** <br><br>对比文件没有公开MAC CE，更没有公开其内容包含“可以在特定服务小区传送的缓冲资料的状态”。 | 同特征C的论述。 |
| 技术特征F：不包括无法在所述特定服务小区中传送的缓冲数据的状态。 | **《未公开》** <br><br>对比文件没有公开MAC CE的内容限制。 | 同特征C的论述。 |
| 技术特征G：其中所述媒体存取控制控制单元通过对应所述特定无线电承载的一媒体存取控制实体所传送。 | **《未公开》** <br><br>对比文件未涉及MAC实体（MAC entity）与特定无线电承载的对应关系。对比文件描述了客户端设备，但未描述其内部的多MAC实体架构。 | 特征G涉及MAC层的内部架构，对比文件完全没有涉及此内容。 |
| 技术特征H：其中多个媒体存取控制实体由所述使用者设备使用 | **《未公开》** <br><br>对比文件未描述使用者设备侧使用多个MAC实体。 | 目标专利中引入了多MAC实体（例如，一个用于控制平面，一个用于用户平面）以支持小小区增强，这是对比文件所不具备的。 |
| 技术特征I：一个媒体存取控制实体对应一个进化B节点 | **《未公开》** <br><br>对比文件未涉及MAC实体与进化B节点（eNB）的对应关系。 | 对比文件涉及的是AP/BS和ARQ服务器，不是LTE中的eNB，也未涉及MAC实体与网络节点的对应关系。 |
| 技术特征J：所述无线电承载和所述媒体存取控制实体之间的配对根据由所述网络提供的所述信息来配置。 | **《未公开》** <br><br>对比文件未公开MAC实体，也无从谈起配置其与无线电承载间的配对。 | 基于特征G、H、I的逐级否定，该特征必然未公开。 |
| 技术特征K：其中所述超过一个的服务小区是由不同进化B节点所控制。 | **《隐含公开》** <br><br>对比文件图1中明确示出了多个AP/BS 110，它们通过高速有线网络130连接至不同的服务器。例如，[0021]: “マルチキャストサーバ／ビデオストリーミングサーバ１２０は、高速有線ネットワーク１３０を介して、複数のＡＰｓ／ＢＳ１１０に接続されており、サービスエリアを増強する複数のセルに役立つ。”（多播服务器/视频流服务器120通过高速有线网络130连接到多个AP/BS 110，服务于多个小区以增强服务区域）。这些AP/BS可以被视为不同的网络节点。在[0022]和后续段落的描述中，不同的小区（小区1、小区2、... 小区N）是分开控制的，有各自独立的ARQ多播组和AP/BS地址。 | 目标专利的“进化B节点”对应于对比文件中的“AP/BS”。对比文件中明确存在多个AP/BS，每个控制至少一个小区，这些AP/BS是不同的节点，它们控制的服务小区可以被认为是不同的。虽然目标专利特指LTE的eNB，但对比文件公开了由不同节点控制多个小区的基本架构，因此隐含公开。 |
| 技术特征L：其中媒体存取控制实体和所述超过一个服务小区之间的配对根据由所述网络提供的所述信息来配置。 | **《未公开》** <br><br>对比文件未涉及“媒体存取控制实体”。 | 同特征G的论述，该特征无法被公开。 |
| 技术特征M：还包括，由于所述缓冲状态报告触发一调度请求 | **《未公开》** <br><br>对比文件未公开BSR，也未公开由BSR触发的调度请求（Scheduling Request，SR）。对比文件客户端触发的ARQ请求是基于数据包丢失，而非上行资源调度请求。 | 该特征是LTE上行调度机制的一部分，对比文件完全没有涉及。 |
| 技术特征N：在对应所述特定无线电承载的一服务小区的一物理上行链路控制信道中传送所述调度请求 | **《未公开》** <br><br>对比文件未公开物理上行链路控制信道（PUCCH）以及在其中传送调度请求。对比文件中涉及的是基于IP的ARQ请求消息，通过多播或单播在有线/无线链路上传输，不是LTE的PUCCH。 | 同特征M的论述。 |
| 技术特征O：其中所述调度请求的物理上行链路控制信道资源是配置于所述使用者设备的超过一个的服务小区。 | **《未公开》** <br><br>对比文件未涉及PUCCH资源配置。 | 同特征N的论述。 |
---
### 附加比对分析
**分析结论：对比文件没有公开下列内容。**
详细分析如下：
1. **无线电承载/逻辑信道与特定服务小区、载波或小区组之间存在配对关系。**
* **论述：** 对比文件确实隐含公开了这种“配对”关系，如上文对技术特征B的分析。具体而言，对比文件将“多播程序X的数据”与特定小区（通过小区特定的ARQ多播组地址）关联起来。例如，段落[0022]指出，“ソースデータパケットは、マルチキャストにおけるセル内の多くのクライアント１０５に送信する。”(源数据包在小区内通过多播发送给众多客户端105)。而ARQ请求和重传数据只在特定的小区内进行，如[0022]所述：“セル１におけるクライアントは、マルチキャストグループＸ及び１Ｘのメンバである...他のグループ（２Ｘ、．．．、ＮＸ１、．．．）に対するＡＲＱ要求及び再送信されたデータは、セル１において送信されない。”(小区1中的客户是多播组X和1X的成员...对于其他组（2X，...，NX1，...）的ARQ请求和重传数据不在小区1中发送)。这建立了数据类型（多播数据/ARQ请求/重传数据）与服务小区之间的对应关系。因此，**对比文件有可能公开了第1点**。
2. **未配对的RB/LC数据不能在该服务小区或载波上传送。**
* **论述：** 对比文件虽然没有明确说“不能”传送，但其逻辑是数据只在为其分配的特定小区内发送。段落[0022]明确指出，与不相关ARQ多播组（2X，...）相关的数据不会在小区1中发送。这隐含了换句话说，只发送与小区内客户端相关的、已配对的数据。因此，**对比文件有可能隐含公开了第2点**。
3. **BSR/调度信息应发送给能够调度该数据的节点/小区。**
* **论述：** 对比文件没有BSR的概念，不符合此点。
4. **BSR内容仅反映该节点/小区可调度的数据。**
* **论述：** 对比文件没有BSR的概念，不符合此点。
5. **特定RB/逻辑信道的较高优先数据到达 → 触发BSR → 在对应服务小区/载波/MAC实体发送BSR MAC CE → BSR内容只包括该小区/载波可传数据，不包括不可传数据。**
* **论述：** 对比文件没有BSR的概念，不符合此点。
综上所述，虽然对比文件公开了与第1点和第2点类似的“配对”和“本地化传输”思想，但其实现机制和背景与目标专利的BSR/SR/MAC CE完全不同。对比文件公开了一种基于IP多播的ARQ恢复方案，而目标专利解决的是LTE小小区增强下的上行资源调度问题，两者的技术路径和技术问题并不相同。因此，不能认为对比文件开启了目标专利权利要求所涉及的具体技术解决方案。
因此，不插入代码 `<<<Z>>>`。
### 最终输出代码
根据以上分析，对比文件仅对技术特征A、B、K作出了隐含公开。
<<<a>>><<<b>>><<<k>>>