DETAILED ACTION
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 .
Claim Status
Claims 1, 11, 13 and 19 are amended. Claims 10 and 20 are cancelled. Claims 1-8 and 11-19 are pending.
Continued Examination Under 37 CFR 1.114
3. A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 5/26/2026 has been entered.
Response to Arguments
Applicant’s arguments, filed on 1/29/2026 with respect to claims 1-8 and 11-19, have been considered but are moot in view of new grounds of rejection.
Claim Rejections - 35 USC § 103
4. 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.
5. Claims 1-6, 8, 11-17 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Aziz et al. (US. Pub. No. 2019/0082040 A1)in view of Jean et al. (US. Pat. No. 8,713,357 B1).
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 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)).
Aziz does not explicitly disclose memory directly coupled to both the MCU and the Layer 2 circuits; wherein the memory is further configured to receive a plurality sets of result statuses directly 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.
However, Jean discloses a memory directly coupled to both the MCU and the Layer 2 circuits ( See Col. 2; L 16-22, Col.3; L 29-35, Col. 6; L4-20 and Fig. 2 of Jean for a reference to a controller interfaces directly with a Non-Volatile Memory (NVM) storage device including NVM storage coupled with a bridge. The bridge 152 in one embodiment comprises bus logic/interface 154 for communicating with the bus logic/interface 140 (on the controller 130). On the other end of the bridge, the bridge device 152 includes a low level interface 158 for communicating with the NVM storage 160. Communications between the controller and the bridge are effected through a PCIe protocol stack 230 which includes a number of layers on both sides, including a data link layer (234, 240) [Bridge 152 is mapped to Layer 2 Circuits]); wherein the memory is further configured to receive a plurality sets of result statuses directly 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 Col. 5; L 46-67 and Fig. 2 of Jean for a reference to a plurality of distinct status queues (completion queue, info queue, error queue) that receive result-status messages directly from the bridge device (the Layer-2-circuit) as commands complete or fail. The bridge uses the completion queue 226 to indicate it has successfully completed one or more commands and the error queue 218 allows the bridge to send detailed reports when one or more command fails).
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 Jean to Aziz. The motivation for combination would be to improve network’s performance, by allowing for efficient insertion and notification of the queue with minimal bus traffic, because the controller knows the current queue depth based on the number of status responses the bridge has sent back. (Jean; Col. 5; L 15-30)
Regarding claim 2, the combination and Aziz and Jean, specifically 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, the combination and Aziz and Jean, specifically 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, the combination and Aziz and Jean, specifically 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, the combination and Aziz and Jean, specifically 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, the combination and Aziz and Jean, specifically 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, the combination and Aziz and Jean, specifically 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 11, the combination and Aziz and Jean, specifically 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, the combination and Aziz and Jean, specifically 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); and
a Packet Data Convergence Protocol (PDCP) circuit directly 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 directly 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).
Aziz does not explicitly disclose a Radio Link Control (RLC) circuit directly coupled to the MAC circuit and configured to process RLC headers of the Layer 1 transport blocks received directly from the MAC circuit.
However, Jean discloses a Radio Link Control (RLC) circuit directly coupled to the MAC circuit and configured to process RLC headers of the Layer 1 transport blocks received directly from the MAC circuit ( See Col. 5; L 46-67, Col. 6; L 4-20 and Fig. 2 of Jean for a reference to a plurality of distinct status queues (completion queue, info queue, error queue) that receive result-status messages directly from the bridge device (the Layer-2-circuit) as commands complete or fail. The bridge uses the completion queue 226 to indicate it has successfully completed one or more commands and the error queue 218 allows the bridge to send detailed reports when one or more command fails. Communications between the controller and the bridge are effected through a PCIe protocol stack 230 which includes a number of layers on both sides, including RLC and MAC layers).
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 Jean to Aziz. The motivation for combination would be to improve network’s performance, by allowing for efficient insertion and notification of the queue with minimal bus traffic, because the controller knows the current queue depth based on the number of status responses the bridge has sent back. (Jean; Col. 5; L 15-30)
.
Regarding claim 14, the claim is interpreted and rejected for the same reason as set forth in claim 8.
Regarding claim 15, the combination and Aziz and Jean, specifically 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, the combination and Aziz and Jean, specifically 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, the combination and Aziz and Jean, specifically 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 from 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 from 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 from 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).
Aziz does not explicitly disclose wherein providing each set of the commands comprises storing, into the memory, the respective set of the commands into a corresponding command queue; and wherein receiving each set of the result statuses comprises retrieving, from the memory, the respective set of the result statuses from a corresponding status queue.
However, Jean discloses wherein providing each set of the commands comprises storing, into the memory, the respective set of the commands into a corresponding command queue ( See Col. 2; L 16-22, Col.3; L 29-35, Col. 6; L4-20 and Fig. 2 of Jean for a reference to a controller interfaces directly with a Non-Volatile Memory (NVM) storage device including NVM storage coupled with a bridge. The bridge 152 in one embodiment comprises bus logic/interface 154 for communicating with the bus logic/interface 140 (on the controller 130). On the other end of the bridge, the bridge device 152 includes a low level interface 158 for communicating with the NVM storage 160. Communications between the controller and the bridge are effected through a PCIe protocol stack 230 which includes a number of layers on both sides, including a data link layer (234, 240) [Bridge 152 is mapped to Layer 2 Circuits]); wherein receiving each set of the result statuses comprises retrieving, from the memory, the respective set of the result statuses from a corresponding status queue ( See Col. 5; L 46-67 and Fig. 2 of Jean for a reference to a plurality of distinct status queues (completion queue, info queue, error queue) that receive result-status messages directly from the bridge device (the Layer-2-circuit) as commands complete or fail. The bridge uses the completion queue 226 to indicate it has successfully completed one or more commands and the error queue 218 allows the bridge to send detailed reports when one or more command fails).
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 Jean to Aziz. The motivation for combination would be to improve network’s performance, by allowing for efficient insertion and notification of the queue with minimal bus traffic, because the controller knows the current queue depth based on the number of status responses the bridge has sent back. (Jean; Col. 5; L 15-30)
6. Claims 7 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Aziz et al. in view of Jean et al. and further in view of Li et al. (US. Pub. No. 2020/0404069 A1).
Regarding Claim 7, the combination and Aziz and Jean 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 the combination and Aziz and Jean. 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.
Levinsky et al. (US 2021/0056024 A1) discloses methods, architectures, apparatuses, systems for efficiently forwarding cache misses to another level of the hierarchy.
Antony et al. (US 2020/0125721 A1) discloses techniques for providing a cloud-based managed service to build and run untrusted code.
Shi et al. (US 2019/0200251 A1) discloses a transmission status reporting apparatus and method and communication system.
8. 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 Primary Examiner, Shah M. Rahman can be reached on (571)272-8951. 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. F./
Examiner, Art Unit 2413
/UN C CHO/Supervisory Patent Examiner, Art Unit 2413
Prosecution Insights