Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Amendment
2. Claims 1, 13 and 19-20 are amended. Claim 9 is cancelled. Claims 1-8 and 10-20 are pending.
Response to Arguments
With regards to applicant’s arguments, filed on 10/30/2025, have been fully considered but they are not persuasive. The applicant asserts, with respect to claims 1-8 and 10-20, that Aziz does not teach or suggest: “a memory operatively coupled to both the MCU and the Layer 2 circuits and configured to store the plurality sets of commands into a plurality of command queues to be fetched by the at least one of the Layer 2 circuits, respectively”. Examiner respectfully disagrees.
Aziz teaches, as shown in Fig. 3, a control processor (CP) memory unit 118. The CP memory is coupled directly to the control processor 112, as well as to the a plurality of hardware accelerators. The plurality of accelerators are associated with L2 (Layer 2) processing, including PDCP, RLC and MAC sub-layer processing. The apparatus 100, of Fig. 3, includes a PDCP SDU manager 104, a TX memory 105, a MAC PDU assembler 106, a control processor 112, header generators 114, header decoders 116, a control processor memory 118, a MAC PDU manager 196, a RX memory 195, and a PDCP SDU fetcher 194. A portion of the TX memory 105 is allocated as a PDCP SDU buffer 122 and another portion of the TX memory 105 is allocated as a header buffer 124. A portion of the RX memory 195 is allocated as a MAC PDU buffer 172. The control processor has a memory from which it fetches programs to execute and which stores the associated data used by the programs, e.g., L2 procedure parameters and state. The control processor may provide to the plurality of hardware accelerators pointers to locations of the memory unit from which the plurality of hardware accelerators assemble the one or more transmit MAC PDU and fetch the one or more receive PDCP SDU. (See Aziz; Par. [2], [10], [27], [41] and Fig. 3)
In addition, Aziz teaches The TX memory 105 and RX memory 195 are used to hold transmit and receive packet data, respectively, as described in more detail below, and advantageously serve as temporary storage buffers through which the packets may flow without being read or written by the control processor 112. PDCP, RLC and MAC headers are generated and written into the TX memory 105 and decoded from the RX memory 195 without the control processor 112 writing/reading the TX/RX memory 105/195. The control processor memory 118 holds code executed by the control processor 112 and data processed by the control processor 112. Preferably, the control processor memory 118 is dedicated to the control processor 112 to facilitate high performance and deterministic operation of the control processor 112 to meet stringent latency and data throughput requirements, such as those imposed by the mm wave 5G NR standard. [Therefore, a CP Memory 118 stores programs and instructions and associated data used by the programs to be executed by the control processor, and which are fetched by the PDCP, RLC, and/or MAC accelerators (L2 Circuits)] (See Aziz; Par. [42]-[43] and Fig. 3)
Therefore, and for the reasons set above, the combination of Aziz and Li teaches the claimed invention. The rejection of claims 1-8 and 10-20 is sustained.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1-6, 8, 10-17 and 19-20 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Aziz et al. (US. Pub. No. 2019/0082040 A1).
Regarding claim 1, Aziz discloses a baseband chip (See Fig. 3; Wireless Communication Apparatus 100), comprising:
a plurality of Layer 2 circuits configured to receive Layer 1 transport blocks and generate Layer 3 data packets from the Layer 1 transport blocks in an in-line manner (See Par. [44]-[48], [57] and Fig. 2-3 of Aziz for a reference to a wireless communication apparatus that comprises three distinct layer 2 hardware 414; MAC, RLC and PDCP accelerators that converts L1 transport blocks [PHY TB; See Par. [13]] into L3 packets inline); and
a microcontroller unit (MCU) operatively coupled to the Layer 2 circuits (See Par. [41] and Fig. 3; Control Processor 112 of Aziz for a reference to CP 112 coupled to layer 2 accelerators) and configured to control, through a plurality sets of commands, at least one of the Layer 2 circuits to generate the Layer 3 data packets from the Layer 1 transport blocks (See Par. [39], [48], [55] of Aziz for a reference to the CP 112 controls the PDCP, RLC and MAC accelerator to decode and convert the PHY TB and generate an L3 layer packet), and a memory operatively coupled to both the MCU and the Layer 2 circuits (See Par. [2], [41]-[42] and Fig. 3 of Aziz for a reference to the wireless communication apparatus comprises a plurality of memories; CP memory 118 that is coupled to the CP 112 and to a plurality of PDCP, RLC, MAC hardware accelerators (L2 Circuits)) and configured to store the plurality sets of commands into a plurality of command queues to be fetched by the at least one of the Layer 2 circuits, respectively (See Par. [27], [42]-[43] of Aziz for a reference to CP Memory 118 stores programs and instructions and associated data used by the programs to be executed by the control processor, and which are fetched by the PDCP, RLC, and/or MAC accelerators (L2 Circuits)).
Regarding claim 2, Aziz discloses wherein the Layer 2 circuits comprise: an interface configured to receive the Layer 1 transport blocks based on a set of interface commands from the MCU (See Par. [39], [43]-[44] and Fig. 3 of Aziz for a reference to the FIFO 108, FIFO 198, FIFO 102 and FIFO 192 interfaces coupled to the L2 layer hardware and the CP 112, which are programmed according to the CP 112 instructions [Commands] to transmit/receive L3 packet and L1 TB respectively); and a buffer operatively coupled to the interface and configured to store the Layer 1 transport blocks (See Par. [41], [49]-[53] and Fig. 3 of Aziz for a reference to the PDCP SDU Buffer 122 & MAC PDU Buffer 172 coupled to the FIFO 102/192 interfaces to store the L1 TB).
Regarding claim 3, Aziz discloses wherein the buffer is further configured to buffer the Layer 1 transport blocks to be adapted to Layer 1 data rate (See Par. [49]-[53] and Fig. 3 of Aziz for a reference to the circular buffers matches the PHY [L1] transport timing and rate).
Regarding claim 4, Aziz discloses wherein the Layer 2 circuits further comprise: a Media Access Control (MAC) circuit operatively coupled to the buffer and configured to process MAC headers of the Layer 1 transport blocks received from the buffer based on a set of MAC commands from the MCU (See Par. [33], [44]-[48] and Fig. 3 of Aziz for a reference to the MAC PDU Manager 196 & Assembler 106 that process, based on the CP 122 instructions, the MAC header of the TB received from the buffer); and
a Radio Link Control (RLC) circuit operatively coupled to the MAC circuit and configured to process RLC headers of the Layer 1 transport blocks received from the MAC circuit based on a set of RLC commands from the MCU (See Par. [28], [32], [36] and Fig. 2 of Aziz for a reference to the CP 112 controls the RLC accelerator to process the PHY TB received in the buffer).
Regarding claim 5, Aziz discloses wherein none of the MAC circuit and the RLC circuit processes payloads of the Layer 1 transport blocks stored in the buffer (See Par. [2]-[3], [42]-[45] of Aziz for a reference to the MAC accelerator and the RLC accelerator process only the header of the received TB in the buffer and avoid payload handling).
Regarding claim 6, Aziz discloses wherein the Layer 2 circuits further comprise a Packet Data Convergence Protocol (PDCP) circuit operatively coupled to the RLC circuit and the buffer and configured to, based on a set of PDCP commands from the MCU (See Par. [43]-[44], [48] and Fig. 3; the PDCP SDU Fetcher & the PDCP manager [Of the PDCP accelerator] of Aziz for a reference to the PDCP accelerator, based on the CP 112 instructions, assembles the L3 packet):
process PDCP headers of the Layer 1 transport blocks received from the RLC circuit (See Par. [31], [48] of Aziz for a reference to the PDCP accelerator, based on the CP 112 instructions, performs the header generation/compression of the TB received from the RLC accelerator);
process payloads of the Layer 1 transport blocks received from the buffer (See Par. [44]-[48] of Aziz for a reference to the PDCP accelerator detects the presence of the PDCP SDU in the FIFO 102. It reads the SDU payload, process it, and write it to a location in the PDCP buffer 122); and
generate the Layer 3 data packets based on the processed PDCP headers and payloads of the Layer 1 transport blocks (See Par. [44]-[48] of Aziz for a reference to the PDCP accelerator assembles the L3 packet’s header and payload from the received L1 TB).
Regarding claim 8, Aziz discloses wherein each of the SDAP, PDCP, RLC, and MAC circuits is an application-specific integrated circuit (ASIC) (See Par. [44] of Aziz for a reference to the L2 accelerators are hardware circuits that performs operations in response to the control processor input [Commands] may be implemented on an application-specific integrated circuit (ASIC)).
Regarding claim 10, Aziz discloses wherein the memory is further configured to receive a plurality sets of result statuses from the at least one of the Layer 2 circuits, and store the plurality sets of result statuses into a plurality of status queues, respectively (See Par. [36], [44]-[48], [53] of Aziz for a reference to the CP 112 receives the status results, PDCP SDU location, as well as packet size from the L2 accelerators).
Regarding claim 11, Aziz discloses wherein the MCU is further configured to: retrieve the plurality sets of result statuses from the memory (See Par. [36], [44]-[48], [53] of Aziz for a reference to the CP 112 receives the status results, PDCP SDU location, as well as packet size from the L2 accelerators); and
generate each set of the commands for controlling a respective one of the Layer 2 circuits based on a corresponding set of the result statuses (See Par. [27], [53] of Aziz for a reference to the CP 112 generates and provides header/command and state parameters to header generators of the MAC, RLC and PDCP accelerators), wherein the corresponding set of the result status are from another one of the Layer 2 circuits at a lower layer in Layer 2 protocol stack than the respective one of the Layer 2 circuits (See Par. [27], [36], [53] of Aziz for a reference to the PDCP accelerator receives the command and state parameters from the RLC accelerator, which in turn, receives commands and state parameters from the MAC accelerator).
Regarding claim 12, Aziz discloses wherein the Layer 2 circuits are configured to pass the Layer 1 transport blocks through the Layer 2 circuits without storing the Layer 1 transport blocks in an external memory (See Par. [3]-[4], [42] of Aziz for a reference to the payload of transport blocks are streamed through the MAC/RLC/PDCP accelerators without being stored in the CP Memory).
Regarding claim 13, Aziz discloses a baseband chip (See Fig. 3; Wireless Communication Apparatus 100), comprising:
a buffer configured to store Layer 1 transport blocks (See Par. [41], [49]-[53] and Fig. 3 of Aziz for a reference to the PDCP SDU Buffer 122 & MAC PDU Buffer 172 coupled to the FIFO 102/192 interfaces to store the L1 TB);
a Medium Access Control (MAC) circuit configured to process MAC headers of the Layer 1 transport blocks received from the buffer (See Par. [33], [44]-[48] and Fig. 3 of Aziz for a reference to the MAC PDU Manager 196 & Assembler 106 that process, based on the CP 122 instructions, the MAC header of the TB received from the buffer);
a Radio Link Control (RLC) circuit operatively coupled to the MAC circuit (See Par. [58] and Fig. 4 of Aziz for a reference to RLC header generator 414-RG is operatively coupled to the MAC header generator 414-MG) and configured to process RLC headers of the Layer 1 transport blocks received from the MAC circuit (See Par. [28], [32], [36] and Fig. 2 of Aziz for a reference to the CP 112 controls the RLC accelerator to process the PHY TB received in the buffer); and
a Packet Data Convergence Protocol (PDCP) circuit operatively coupled to the RLC circuit (See Par. [58] and Fig. 4 of Aziz for a reference to PDCP header generator 414-PG is operatively coupled to the RLC header generator 414-RG) and (See Par. [43]-[44], [48] and Fig. 3; the PDCP SDU Fetcher & the PDCP manager [Of the PDCP accelerator] of Aziz for a reference to the PDCP accelerator, based on the CP 112 instructions, assembles the L3 packet) configured to:
process PDCP headers of the Layer 1 transport blocks received from the RLC circuit (See Par. [31], [48] of Aziz for a reference to the PDCP accelerator, based on the CP 112 instructions, performs the header generation/compression of the TB received from the RLC accelerator);
process payloads of the Layer 1 transport blocks received from the buffer (See Par. [44]-[48] of Aziz for a reference to the PDCP accelerator detects the presence of the PDCP SDU in the FIFO 102. It reads the SDU payload, process it, and write it to a location in the PDCP buffer 122); and
generate Layer 3 data packets based on the processed PDCP headers and payloads of the Layer 1 transport blocks (See Par. [44]-[48] of Aziz for a reference to the PDCP accelerator assembles the L3 packet’s header and payload from the received L1 TB).
Regarding claim 14, the claim is interpreted and rejected for the same reason as set forth in claim 8.
Regarding claim 15, Aziz discloses the baseband chip of claim 13, further comprising an interface configured to: receive the Layer 1 transport blocks, and forward the Layer 1 transport blocks to the buffer (See Par. [39], [43]-[44] and Fig. 3 of Aziz for a reference to the FIFO 108, FIFO 198, FIFO 102 and FIFO 192 interfaces coupled to the L2 layer hardware and the CP 112, which are programmed according to the CP 112 instructions [Commands] to transmit/receive L3 packet and L1 TB respectively); and
based on information related to the Layer 1 transport blocks and an interface lookup table (LUT) circuit, generate a set of MAC commands, wherein the MAC circuit is configured to process the MAC headers based on the set of MAC commands (See Par. [33], [44]-[48] and Fig. 3 of Aziz for a reference to the MAC PDU Manager 196 & Assembler 106 that process, based on the CP 122 instructions, the MAC header of the TB received from the buffer).
Regarding claim 16, Aziz discloses wherein: the MAC circuit is further configured to, based on the processed MAC headers and a MAC LUT circuit, generate a set of RLC commands (See Par. [33], [39], [44]-[48], [55] and Fig. 3 of Aziz for a reference to the MAC PDU Manager 196 & Assembler 106 that process, based on the CP 112 instructions, the MAC header of the TB received from the buffer. The CP 112 controls the PDCP, RLC and MAC accelerator to decode and convert the PHY TB and generate an L3 layer packet); and
the RLC circuit is configured to process the RLC headers based on the set of RLC commands (See Par. [28], [32], [36] and Fig. 2 of Aziz for a reference to the CP 112 controls the RLC accelerator to process the PHY TB received in the buffer).
Regarding claim 17, Aziz discloses wherein: the RLC circuit is further configured to, based on the processed RLC headers and a PDCP LUT circuit, generate a set of PDCP commands (See Par. [28], [32], [36], [39], [55] and Fig. 2 of Aziz for a reference to the CP 112 controls the RLC accelerator to process the PHY TB received in the buffer. The CP 112 controls the PDCP, RLC and MAC accelerator to decode and convert the PHY TB and generate an L3 layer packet); and
the PDCP circuit is configured to, based on the set of PDCP commands, process the PDCP headers and the payloads and generate the Layer 3 data packets (See Par. [31], [44]-[48] of Aziz for a reference to the PDCP accelerator, based on the CP 112 instructions, performs the header generation/compression of the TB received from the RLC accelerator. The PDCP accelerator detects the presence of the PDCP SDU in the FIFO 102. It reads the SDU payload, process it, and write it to a location in the PDCP buffer 122. The PDCP accelerator assembles the L3 packet’s header and payload from the received L1 TB).
Regarding claim 19, Aziz discloses a method for Layer 2 downlink data processing (See Abstract), comprising:
receiving, by a microcontroller unit (MCU) via a memory (See Fig. 3; Control Processor (CP) memory), a first set of result statuses based on information related to Layer 1 transport blocks (See Par. [36], [44]-[48], [53] of Aziz for a reference to the CP 112 receives the status results, PDCP SDU location, as well as packet size from the L2 accelerators);
providing, by the MCU via a memory, a first set of commands based on the first set of result statuses to control a Medium Access Control (MAC) circuit to process MAC headers of the Layer 1 transport blocks (See Par. [27], [53] of Aziz for a reference to the CP 112 generates and provides header/command and state parameters, stored in CP memory 118, to header generators of the MAC accelerator);
receiving, by the MCU via a memory, a second set of result statuses based on the processing result of the MAC circuit (See Par. [27], [36], [44]-[48], [53] of Aziz for a reference to the CP 112 receives the status results, PDCP SDU location, as well as packet size from the L2 accelerators. The PDCP accelerator receives the command and state parameters from the RLC accelerator, which in turn, receives commands and state parameters from the MAC accelerator);
providing, by the MCU via a memory, a second set of commands based on the second set of result statuses to control a Radio Link Control (RLC) circuit to process RLC headers of the Layer 1 transport blocks (See Par. [27], [53] of Aziz for a reference to the CP 112 generates and provides header/command and state parameters, stored in CP memory 118, to header generators of the RLC accelerator);
receiving, by the MCU via a memory, a third set of result statuses based on the processing result of the RLC circuit (See Par. [27], [36], [44]-[48], [53] of Aziz for a reference to the CP 112 receives the status results, PDCP SDU location, as well as packet size from the L2 accelerators. The PDCP accelerator receives the command and state parameters, stored in CP memory 118, from the RLC accelerator, which in turn, receives commands and state parameters from the MAC accelerator)
; and
providing, by the MCU via a memory, a third set of commands based on the third set of result statuses to control a Packet Data Convergence Protocol (PDCP) circuit to process PDCP headers and payloads of the Layer 1 transport blocks (See Par. [27], [53] of Aziz for a reference to the CP 112 generates and provides header/command and state parameters, stored in CP memory 118, to header generators of the PDCP accelerator), and generate Layer 3 data packets based on the processed PDCP headers and payloads of the Layer 1 transport blocks (See Par. [44]-[48] of Aziz for a reference to the PDCP accelerator assembles the L3 packet’s header and payload from the received L1 TB).
Regarding claim 20, Aziz discloses wherein: providing each set of the commands comprises storing the respective set of the commands into a corresponding command queue in a memory (See Par. [36], [44]-[48], [53] of Aziz for a reference to the CP 112 receives the status results, PDCP SDU location, as well as packet size from the L2 accelerators); and
receiving each set of the result statuses comprises retrieving the respective set of the result statuses from a corresponding status queue in the memory (See Par. [27], [36], [44]-[48], [53] of Aziz for a reference to the CP 112 receives the status results, PDCP SDU location, as well as packet size from the L2 accelerators. The PDCP accelerator receives the command and state parameters from the RLC accelerator, which in turn, receives commands and state parameters from the MAC accelerator).
Claim Rejections - 35 USC § 103
5. The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
6. Claims 7 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Aziz et al. in view of Li et al. (US. Pub. No. 2020/0404069 A1).
Regarding Claim 7, Aziz does not explicitly disclose wherein the Layer 2 circuits further comprise a Service Data Adaptation Protocol (SDAP) circuit configured to cause the PDCP circuit to organize the Layer 3 data packets based on Quality of Service (QoS).
However, Li discloses wherein the Layer 2 circuits further comprise a Service Data Adaptation Protocol (SDAP) circuit configured to cause the PDCP circuit to organize the Layer 3 data packets based on Quality of Service (QoS) (See Par. [254]-[255] of Li for a reference to the SDAP entity 1949 maps QoS flows to DRBs and makes QFIs in DL & UL packets SDAP header supports in-sequence delivery during QoS flows remapping).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Li to Aziz. The motivation for combination would be to improve network’s performance, by providing an efficient service delivery through the reduced end-to-end latency and load on the transport network. (Li; Par. [136])
Regarding claim 18, the claim is interpreted and rejected for the same reason as set forth in claim 7.
Conclusion
7. The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Hong et al. (US. Pub. No. 2022/0360650 A1) discloses an apparatus and method for descriptor handling and a computer-readable medium, which may be applicable to communication systems.
Zhu et al. (US. Pub. No. 2020/0007223 A1) discloses advanced radio resource management in next-gen multi-hop relaying cellular network.
Kristen et al. (US. Pub. No. 2019/0116555 A1) discloses wakeup radio preamble design and pulse generation for low and high transmission rates for wake-up radio packet transmissions.
8. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the date of this final action.
9. Any inquiry concerning this communication from the examiner should be directed to RASHA FAYED whose telephone number is (571) 270-3804. The examiner can normally be reached on M-F 8:00AM-4:30PM.
If attempts to reach the examiner by telephone are unsuccessful, the supervisory Examiner, Un Cho can be reached on (571)272-7919. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/R.K.F/Examiner, Art Unit 2413
/UN C CHO/Supervisory Patent Examiner, Art Unit 2413
Prosecution Insights