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 .
Continued Examination Under 37 CFR 1.114
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 04/17/2026 has been entered. Claims 1, 3-9, and 11-17 are pending.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1, 3-9, and 11-17 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claims 1 and 9 recite the limitation “wherein the MAC process, the RLC process, the PDCP process and the related processing are performed completely based on hardware without memory access”. The processes of the claims necessitate the use of memory or buffers within the device itself. Therefore, claiming that the processes are performed “without memory access” entirely is indefinite. The examiner interprets that this limitation is intended to claim performing the processes within the hardware acceleration device and not accessing main memory. Therefore, the examiner suggests that the limitation should read “wherein the MAC process, the RLC process, the PDCP process and the related processing are performed completely based on hardware without main memory access” (emphasis added) for clarity. For the purposes of examination, the limitation is interpreted as such. Claims 3-8 and 17 are rejected due to their dependency on independent claim 1. Claims 11-16 are rejected due to their dependency on independent claim 9.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
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.
Claims 1, 3-9, and 11-16 are rejected under 35 U.S.C. 103 as being unpatentable over Kim et al. (US 2022/0150693), hereinafter "Kim '693", in view of Kim et al. (US 2022/0174135), hereinafter "Kim '135", and further in view of Helman (US 2019/0187996), hereinafter “Helman”, and further in view of Rao et al. (CN 117294660), published 26 December, 2023, hereinafter “Rao” (see “CN117294660_Translation.pdf” for citations).
Regarding claims 1, 9, Kim ‘693 teaches:
A method for speeding up packet processing or a device for speeding up packet processing (see Kim ‘693, Fig. 28, par. [0487]: FIG. 28 illustrates the structure of a UE), comprising:
a central processing unit (CPU) (see Kim ‘693, Fig. 28, par. [0488]: the UE may include a radio frequency (RF) processor 1cd-10, a baseband processor 1cd-20, a memory 1cd-30, and a controller 1cd-40); and
a hardware acceleration processor coupled to the CPU, wherein the hardware acceleration processor is operable (see Kim ‘693, Fig. 7A, par. [0388]: the UE can increase the data processing speed since the header of each layer device has a fixed size in the PDCP layer device, the RLC layer device, or the MAC layer device. For example, when applying a hardware accelerator with high efficiency to data processing when repeating the same size or operation as the repeated procedure, if a header with fixed size is used in SDAP, PDCP, RLC, or MAC layer devices in the above, the data processing efficiency is increased and the data processing speed can be reduced) to:
receiving, by a hardware acceleration circuitry of a computing device, a downlink transport block (TB) from a physical (PHY) layer (see Kim ‘693, Fig. 1, par. [0201]: The NR PHY layers 1d-20 and 1d-25 may perform operations of channel-coding and modulating upper layer data, forming the upper layer data into an OFDM symbol, transmitting the OFDM symbols via a radio channel or demodulating and channel decoding of the OFDM symbols received via the radio channel, and transferring the OFDM symbol to an upper layer, and see Kim ‘693, Fig. 7A, par. [0239]: In reference numeral 1g-10, when the UE receives data from the lower layer device, and see Kim ‘693, par. [0242]: the data has a repeated structure, such as header (MAC header, RLC header, PDCP header, or SDAP header) and data and header (MAC header, RLC header, PDCP header or SDAP header) and data. Therefore, when generating data having a repeated structure with headers having a fixed size as described above, in order to perform faster data processing, a hardware accelerator (hardware engine) may be applied to reduce data processing time, and see Kim ‘693, pars. [0144-0146]: The MACs 1b-15 and 1b-30 are connected to multiple RLC layer devices configured in one UE, and may perform an operation of multiplexing RLC PDUs to MAC PDUs and demultiplexing RLC PDUs from MAC PDUs. The main functions of MACs are summarized as follows. Mapping between logical channels and transport channels Multiplexing/de-multiplexing of MAC SDUs belonging to one or different logical channels into/from transport blocks (TB) transferred to/from the physical layer on transport channels; in this case, the UE may receive data, including a TB from a physical layer, for hardware acceleration);
performing, by the hardware acceleration circuitry, a medium access control (MAC) process on the downlink TB to obtain MAC service data units (SDUs) (see Kim ‘693, Fig. 7A, par. [0239]: when the UE receives data from the lower layer device, the UE may read the MAC header and identifies the length field to separate the data, or may identify the logical channel identifier and demultiplexes the data to the corresponding RLC layer device and transmit the same, and see Kim ‘693, par. [0397]: The predetermined reason of requiring the segmentation operation may correspond to a case of requesting segmentation operation for a specific MAC SDU (RLC PDU) from the RLC layer since the size of the currently generated MAC subheader and MAC SDU is larger than the size of the transmission resource allocated by the MAC layer; in this case, the hardware accelerator performs an operation on the data, demultiplexes to separate data from the MAC header (corresponding to obtaining MAC SDUs));
performing, by the hardware acceleration circuitry, a radio link control (RLC) process on RLC protocol data units (PDUs) corresponding to the MAC SDUs to obtain RLC SDUs (see Kim ‘693, Fig. 7A, par. [0432]: The receiving terminal RLC layer device receives the RLC PDU, identifies the SI field in the RLC header, and distinguishes whether the received RLC PDU is an RLC PDU for which no segmentation operation is performed (complete RLC PDU) or an RLC PDU for which the segmentation operation is received (segmented RLC PDU). If it is an RLC SDU for which the segmentation operation is not performed, the RLC header may be deleted and transmitted to an upper layer, and see Kim ‘693, par. [0397]: The predetermined reason of requiring the segmentation operation may correspond to a case of requesting segmentation operation for a specific MAC SDU (RLC PDU) from the RLC layer since the size of the currently generated MAC subheader and MAC SDU is larger than the size of the transmission resource allocated by the MAC layer; in this case, the hardware accelerator performs an operation on RLC PDUs to determine RLC SDUs);
performing, by the hardware acceleration circuitry, a packet data convergence protocol (PDCP) process on PDCP PDUs corresponding to the RLC SDUs to obtain PDCP SDUs (see Kim ‘693, Fig. 7A, par. [0239]: the RLC layer device may reassemble the pieces of segmented data to configure full data and transfer the reassembled data to the PDCP layer device. In the above, when a ciphering procedure is configured, the PDCP layer device performs a deciphering procedure, and if the deciphered data is arranged in a sequence of a PDCP serial number or COUNT value, or if a header compression procedure is configured, the PDCP layer device applies a header decompression procedure to the data, and transfer the data to an upper layer device in ascending order of the COUNT value, and see Kim ‘693, par. [0523]: When using maximum SDU processing (or MSDU processing method), it is straightforward that the number of L2 headers is reduced by 1/N times (where N denotes the number of concatenated PDCP SDUs), which implies the reduction of the number of RLC/PDCP sequence numbers (SN) impinging the complexity of window management as well as their header parsing complexity; in this case, the hardware accelerator performs an operation at the PDCP layer to then transfer the data to an upper layer (corresponding to a process on PDUs to obtain SDUs));
and
transmitting, by the hardware acceleration circuitry, the processed packet to an upper layer (see Kim ‘693, Fig. 7A, par. [0239]: the PDCP layer device applies a header decompression procedure to the data, and transfer the data to an upper layer device in ascending order of the COUNT value);
However, Kim ‘693 does not teach:
determining, by the hardware acceleration circuitry, whether each of the PDCP SDUs corresponding to a packet is an Internet protocol (IP) packet or a transmission control protocol/user datagram protocol (TCP/UDP) packet;
performing, by the hardware acceleration circuitry, related processing on the packet to obtain a processed packet in response to determining that the packet is an IP packet or a TCP/UDP packet;
wherein the MAC process, the RLC process, the PDCP process and the related processing are performed completely based on hardware without memory access;
wherein the related processing at least comprises:
a checksum calculation for the IP packet or the TCP/UDP packet; and
an IP fragmentation.
Kim ‘135, in the same field of endeavor, teaches:
determining, by the hardware acceleration circuitry, whether each of the PDCP SDUs corresponding to a packet is an Internet protocol (IP) packet or a transmission control protocol/user datagram protocol (TCP/UDP) packet (see Kim ‘135, par. [0108]: the PDCP SDU analyzer 530 may identify a characteristic of a PDCP SDU by analyzing the PDCP SDU (e.g., IP data packet) delivered from the AP or an upper layer. For example, the PDCP SDU analyzer 530 may identify the characteristic of the PDCP SDU based on information (e.g., transmission protocol) of an IP data packet included in the PDCP SDU; in this case, analyzing information of an IP data packet corresponds to determining whether the packets are an IP or TCP/UDP packet);
performing, by the hardware acceleration circuitry, related processing on the packet to obtain a processed packet in response to determining that the packet is an IP packet or a TCP/UDP packet (see Kim ‘135, par. [0108]: the PDCP SDU analyzer 530 may identify a characteristic of a PDCP SDU by analyzing the PDCP SDU (e.g., IP data packet) delivered from the AP or an upper layer. For example, the PDCP SDU analyzer 530 may identify the characteristic of the PDCP SDU based on information (e.g., transmission protocol) of an IP data packet included in the PDCP SDU, and see Kim ‘135, Fig. 6, par. [0125]: The electronic device 101 may process a PDCP SDU predicted to be lost based on a determination (e.g., processing by using AP or CP) of the PDCP SDU manager 560, and see Kim ‘135, par. [0122]: the electronic device 101 (e.g., the PDCP SDU manager 560) may determine whether to store the PDCP SDU in a PDCP buffer (e.g., the PDCP buffer 504 of FIG. 5) based on a received PDCP SDU characteristic, and see Kim ‘135, par. [0125]: when the electronic device 101 determines to process data PDCP SDU predicted to be lost by using the AP, the electronic device 101 may delete the PDCP SDU predicted to be lost and may retransmit an IP data packet corresponding to the PDCP SDU from the AP to a PDCP layer (e.g., the PDCP layer 410 of FIG. 4); in this case, the packet may be processed based on a determination which is based on the characteristic (corresponding to in response to determining the packet is an IP or TCP/UDP packet));
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to have modified the method of Kim ‘693 with the processing based on packets and without memory access of Kim ‘135 with a reasonable expectation of success. One of ordinary skill in the art would have been motivated to make this modification for the benefit of preventing deterioration of service performance and preventing dropping of packets (see Kim ‘135, pars. [0017-0019]).
However, the combination of Kim ‘693 in view of Kim ‘135 does not teach:
wherein the MAC process, the RLC process, the PDCP process and the related processing are performed completely based on hardware without memory access;
wherein the related processing at least comprises:
a checksum calculation for the IP packet or the TCP/UDP packet; and
an IP fragmentation.
Helman, in the same field of endeavor, teaches:
wherein the MAC process, the RLC process, the PDCP process and the related processing are performed completely based on hardware without memory access (see Helman, pars. [0055-0056]: in regard to FIG. 1, a hardware acceleration circuit may include a buffer or other suitable storage circuit that allows for the storage of the intermediate data. By including localized storage in the hardware acceleration circuit, the architecture of the computer system is improved to allow for subsequent operations to be performed by the hardware acceleration circuit using the intermediate data without accesses to main memory, which can result in additional delay and power consumption. In addition to executing the first instruction of the plurality of chained hardware instructions, the hardware acceleration circuit may then execute a second hardware instruction, which is chained to the first hardware instruction, to perform a second operation using the intermediate data, and possibly a second data stream of the plurality of data streams. Since the result of the first operation, i.e., the intermediate data, is locally available within the hardware acceleration circuit, if the second operation consumes only results of the first operation, the second operation can be performed without accesses to main memory; in this case, hardware acceleration is performed without main memory access. In combination with Kim ‘693 and Kim ‘135, which teach hardware acceleration circuitry performing MAC, RLC, PDCP, and related processes, the references teach the limitation).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to have modified the MAC, RLC, PDCP, and related processes performed by hardware acceleration circuitry of the combination of Kim ‘693 in view of Kim ‘135 with the hardware acceleration being performed without memory access of Helman with a reasonable expectation of success. One of ordinary skill in the art would have been motivated to make this modification for the benefit of improving throughput and reducing power consumption (see Helman, pars. [0016] and [0055-0056]).
However, the combination of Kim ‘693 in view of Kim ‘135, and further in view of Helman, does not teach:
wherein the related processing at least comprises:
a checksum calculation for the IP packet or the TCP/UDP packet; and
an IP fragmentation.
Rao, in the same field of endeavor, teaches:
wherein the related processing at least comprises:
a checksum calculation for the IP packet or the TCP/UDP packet (see Rao, par. [n0041]: the offload mechanism of a smart network interface card (NIC) mainly refers to transferring operations such as IP fragmentation, TCP segmentation, reassembly, and checksum verification, which were originally performed in the software protocol stack, to the NIC hardware); and
an IP fragmentation (see Rao, par. [n0041]: the offload mechanism of a smart network interface card (NIC) mainly refers to transferring operations such as IP fragmentation, TCP segmentation, reassembly, and checksum verification, which were originally performed in the software protocol stack, to the NIC hardware).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to have modified the related processing of the combination of Kim ‘693 in view of Kim ‘135, and further in view of Helman, with the specific processing of Rao with a reasonable expectation of success. One of ordinary skill in the art would have been motivated to make this modification for the benefit of reducing system CPU load and improving processing performance (see Rao, par. [n0041]).
Regarding claim 3, the combination of Kim ‘693 in view of Kim ‘135, and further in view of Helman, and further in view of Rao, teaches the method. Kim ‘693 further teaches:
further comprising:
transmitting the non-IP packet or the non-TCP/UDP packet to the upper layer by the CPU (see Kim ‘693, par. [0239]: the PDCP layer device applies a header decompression procedure to the data, and transfer the data to an upper layer device in ascending order of the COUNT value, and see Kim ‘693, par. [0493]: The controller 1cd-40 may control overall operations of the UE. For example, the controller 1cd-40 may transmit and receive signals through the baseband processor 1cd-20 and the RF processor 1cd-10; in this case, a controller (corresponding to a CPU) may be used to transmit signals).
Kim ‘693 does not teach, but Kim ‘135 teaches:
transferring, by the hardware acceleration circuitry, the packet to a memory of the computing device and instructing a central processing unit (CPU) of the computing device to perform the related processing on the packet in the memory in response to determining that the packet is not an IP packet or a TCP/UDP packet (see Kim ‘135, par. [0097]: the electronic device 101 may generate a PDCP SDU through reverse conversion of a data packet predicted to be lost. For example, a MAC PDU of the first communication protocol stack may be identified as data predicted to be lost (hereinafter referred to as loss-predicted data), and a PDCP SDU corresponding to the MAC PDU may be in a deleted state. In this case, when handing over the electronic device 101 to a cell corresponding to the second communication protocol stack, the electronic device 101 may generate a plurality of PDCP SDUs from the MAC PDU through reverse conversion for the MAC PDU generated by the E-UTRA MAC 318. For example, the electronic device 101 may store the PDCP SDUs generated through reverse conversion in a memory of the electronic device 101 at least temporarily, and see Kim ‘135, par. [0074]: an E-UTRA protocol stack may be referred to as a first communication protocol stack or a first protocol stack, and see Kim ‘135, par. [0140]: the inter-communication protocol stack PDCP SDU deliverer 570 may deliver information (e.g., address information) of a PDCP SDU stored in a memory region other than the PDCP buffer 504 to the protocol stack corresponding to the second bearer. The electronic device 101 may transmit data through the second bearer based on the delivered PDCP SDU (e.g., operation 630 of FIG. 6), and see Kim ‘135, Fig. 11, pars. [0159-0160]: in operation 1105, the at least one processor may store, during wireless communication based on the first RAT, at least one first data packet related to the first PDCP in the first buffer (e.g., the PDCP buffer 504) at least temporarily. For example, the at least one first data packet may include at least one first packet header including an identifier related to the first PDCP and at least one service data unit (SDU)…According to various embodiments, in operation 1110, the at least one processor, when the wireless communication is changed to wireless communication based on the second RAT, may change at least a portion of the stored at least one first data packet to at least one second data packet related to the second PDCP; in this case, a packet may be stored in memory for further processing by a controller (i.e. CPU) based on an identification of the communication protocol stack as data predicted to be lost (corresponding to in response to determining that the packet is not an IP or TCP/UDP packet));
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to have modified the method of Kim ‘693 with the transferring packets of Kim ‘135 with a reasonable expectation of success. One of ordinary skill in the art would have been motivated to make this modification for the benefit of preventing deterioration of service performance and preventing dropping of packets (see Kim ‘135, pars. [0017-0019]).
Regarding claims 4, 12, the combination of Kim ‘693 in view of Kim ‘135, and further in view of Helman, and further in view of Rao, teaches the method or device.
The combination of Kim ‘693 in view of Kim ‘135, and further in view of Helman, does not teach, but Rao teaches:
wherein the related processing further comprises:
a TCP segmentation offload (TSO) (see Rao, par. [n0041]: the offload mechanism of a smart network interface card (NIC) mainly refers to transferring operations such as IP fragmentation, TCP segmentation, reassembly, and checksum verification, which were originally performed in the software protocol stack, to the NIC hardware).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to have modified the related processing of the combination of Kim ‘693 in view of Kim ‘135, and further in view of Helman, with the specific processing of Rao with a reasonable expectation of success. One of ordinary skill in the art would have been motivated to make this modification for the benefit of reducing system CPU load and improving processing performance (see Rao, par. [n0041]).
Regarding claims 5, 13, the combination of Kim ‘693 in view of Kim ‘135, and further in view of Helman, and further in view of Rao, teaches the method or device. Kim ‘693 further teaches:
wherein the MAC process comprises:
parsing MAC headers in the downlink TB to obtain MAC SDU information;
fetching the MAC SDUs according to the MAC SDU information; and
transmitting the MAC SDUs (see Kim ‘693, Fig. 7A, par. [0239]: when the UE receives data from the lower layer device, the UE may read the MAC header and identifies the length field to separate the data, or may identify the logical channel identifier and demultiplexes the data to the corresponding RLC layer device and transmit the same, and see Kim ‘693, par. [0397]: The predetermined reason of requiring the segmentation operation may correspond to a case of requesting segmentation operation for a specific MAC SDU (RLC PDU) from the RLC layer since the size of the currently generated MAC subheader and MAC SDU is larger than the size of the transmission resource allocated by the MAC layer; in this case, reading MAC headers to identify the length field corresponds to parsing MAC headers to obtain MAC SDU information. Separating the data or demultiplexing the data corresponds to fetching the MAC SDUs according to the MAC SDU information. The data is then transmitted).
Regarding claims 6, 14, the combination of Kim ‘693 in view of Kim ‘135, and further in view of Helman, and further in view of Rao, teaches the method or device. Kim ‘693 further teaches:
wherein the RLC process comprises:
parsing RLC headers in the RLC PDUs to obtain RLC SDU information (see Kim ‘693, par. [0432]: The receiving terminal RLC layer device receives the RLC PDU, identifies the SI field in the RLC header; in this case, identifying the SI field in the RLC header corresponds to parsing RLC headers to obtain RLC SDU information);
determining whether the RLC PDUs comprise more than one RLC SDU segment according to the RLC SDU information (see Kim ‘693, par. [0432]: The receiving terminal RLC layer device receives the RLC PDU, identifies the SI field in the RLC header, and distinguishes whether the received RLC PDU is an RLC PDU for which no segmentation operation is performed (complete RLC PDU) or an RLC PDU for which the segmentation operation is received (segmented RLC PDU). If it is an RLC SDU for which the segmentation operation is not performed, the RLC header may be deleted and transmitted to an upper layer; in this case, identifying whether segmentation operation is performed corresponds to determining whether the PDUs comprise more than one segment);
concatenating the more than one RLC SDU segment to a complete RLC SDU in response to determining that the RLC PDUs comprise the more than one RLC SDU segment (see Kim ‘693, par. [0432]: If it is an RLC SDU for which the segmentation operation is performed, the receiving terminal RLC layer device identifies the SI field, identifies whether it is the first, the middle, or the last segment, stores and organizes the segments according to the RLC serial number, if the reassembly function is triggered by a window or a timer, reassembles the segments to generate a complete RLC SDU; in this case, organizing the segments corresponds to concatenating to generate a complete SDU); and
transmitting the complete RLC SDU (see Kim ‘693, par. [0432]: If it is an RLC SDU for which the segmentation operation is performed, the receiving terminal RLC layer device identifies the SI field, identifies whether it is the first, the middle, or the last segment, stores and organizes the segments according to the RLC serial number, if the reassembly function is triggered by a window or a timer, reassembles the segments to generate a complete RLC SDU and transmit the same to the upper layer).
Regarding claims 7, 15, the combination of Kim ‘693 in view of Kim ‘135, and further in view of Helman, and further in view of Rao, teaches the method or device. Kim ‘693 further teaches:
wherein the RLC process further comprises:
reordering RLC SDUs in an order according to sequence numbers in the RLC SDU information in response to determining that the RLC PDUs comprise only one RLC SDU segment (see Kim ‘693, Fig. 23, par. [0189]: The in-sequence delivery function may include a function of reordering the received RLC PDUs based on an RLC SN, and see Kim ‘693, par. [0432]: If it is an RLC SDU for which the segmentation operation is not performed, the RLC header may be deleted and transmitted to an upper layer, and see Kim ‘693, par. [0394]: The sequence number (SN) field indicates the serial number of the RLC PDU and may have a predetermined length); and
transmitting the RLC SDUs in the order (see Kim ‘693, par. [0432]: If it is an RLC SDU for which the segmentation operation is not performed, the RLC header may be deleted and transmitted to an upper layer, and see Kim ‘693, Fig. 23, par. [0189]: The in-sequence delivery function may include a function of reordering the received RLC PDUs based on an RLC SN).
Regarding claims 8, 16, the combination of Kim ‘693 in view of Kim ‘135, and further in view of Helman, and further in view of Rao, teaches the method or device. Kim ‘693 further teaches:
wherein the PDCP process comprises:
parsing PDCP headers in the PDCP PDUs to obtain PDCP SDU information (see Kim ‘693, par. [0239]: the RLC layer device may reassemble the pieces of segmented data to configure full data and transfer the reassembled data to the PDCP layer device. In the above, when a ciphering procedure is configured, the PDCP layer device performs a deciphering procedure, and if the deciphered data is arranged in a sequence of a PDCP serial number or COUNT value, or if a header compression procedure is configured, the PDCP layer device applies a header decompression procedure to the data, and transfer the data to an upper layer device in ascending order of the COUNT value, and see Kim ‘693, par. [0522]: in order to maximize the efficiency of HW engines, multiple PDCP SDUs may be concatenated into one pseudo SDU with maximum size smaller than the size supported by HW engines. For DL data, the HW processing can be applied to L2 header parsing or de-cryptographic algorithms for each pseudo SDU, and see Kim ‘693, par. [0513]: the HW processing can be applied to the most computationally intensive tasks for DL data processing, e.g., in the order of parsing (or reading or interpreting) L2 headers and running cryptographic algorithms (deciphering and integrity verification), and see Kim ‘693, par. [0277]: the receiving terminal (receiving PDCP layer device) may separate pieces of data according to the data de-concatenation procedure proposed in the disclosure, and may apply a deciphering procedure, integrity verification procedure, or a header decompression procedure to each data, and see Kim ‘693, par. [0333]: (if a header compression procedure (or data compression procedure) is configured in the PDCP layer device, a header decompression procedure (or data decompression procedure) may be applied to each data, and the decompressed data may be transferred to an upper layer device); in this case, performing a header decompression procedure to obtain data corresponds to parsing PDCP headers to obtain PDCP SDU information. Deciphering corresponds to decrypting. The data may then be transmitted to an upper layer);
decrypting the PDCP SDUs according to the PDCP SDU information to obtain decrypted PDCP SDUs (see Kim ‘693, par. [0239]: the RLC layer device may reassemble the pieces of segmented data to configure full data and transfer the reassembled data to the PDCP layer device. In the above, when a ciphering procedure is configured, the PDCP layer device performs a deciphering procedure, and if the deciphered data is arranged in a sequence of a PDCP serial number or COUNT value, or if a header compression procedure is configured, the PDCP layer device applies a header decompression procedure to the data, and transfer the data to an upper layer device in ascending order of the COUNT value, and see Kim ‘693, par. [0522]: in order to maximize the efficiency of HW engines, multiple PDCP SDUs may be concatenated into one pseudo SDU with maximum size smaller than the size supported by HW engines. For DL data, the HW processing can be applied to L2 header parsing or de-cryptographic algorithms for each pseudo SDU, and see Kim ‘693, par. [0513]: the HW processing can be applied to the most computationally intensive tasks for DL data processing, e.g., in the order of parsing (or reading or interpreting) L2 headers and running cryptographic algorithms (deciphering and integrity verification), and see Kim ‘693, par. [0277]: the receiving terminal (receiving PDCP layer device) may separate pieces of data according to the data de-concatenation procedure proposed in the disclosure, and may apply a deciphering procedure, integrity verification procedure, or a header decompression procedure to each data, and see Kim ‘693, par. [0333]: (if a header compression procedure (or data compression procedure) is configured in the PDCP layer device, a header decompression procedure (or data decompression procedure) may be applied to each data, and the decompressed data may be transferred to an upper layer device); in this case, performing a header decompression procedure to obtain data corresponds to parsing PDCP headers to obtain PDCP SDU information. Deciphering corresponds to decrypting. The data may then be transmitted to an upper layer); and
transmitting the decrypted PDCP SDUs to the upper layer (see Kim ‘693, par. [0239]: the RLC layer device may reassemble the pieces of segmented data to configure full data and transfer the reassembled data to the PDCP layer device. In the above, when a ciphering procedure is configured, the PDCP layer device performs a deciphering procedure, and if the deciphered data is arranged in a sequence of a PDCP serial number or COUNT value, or if a header compression procedure is configured, the PDCP layer device applies a header decompression procedure to the data, and transfer the data to an upper layer device in ascending order of the COUNT value, and see Kim ‘693, par. [0522]: in order to maximize the efficiency of HW engines, multiple PDCP SDUs may be concatenated into one pseudo SDU with maximum size smaller than the size supported by HW engines. For DL data, the HW processing can be applied to L2 header parsing or de-cryptographic algorithms for each pseudo SDU, and see Kim ‘693, par. [0513]: the HW processing can be applied to the most computationally intensive tasks for DL data processing, e.g., in the order of parsing (or reading or interpreting) L2 headers and running cryptographic algorithms (deciphering and integrity verification), and see Kim ‘693, par. [0277]: the receiving terminal (receiving PDCP layer device) may separate pieces of data according to the data de-concatenation procedure proposed in the disclosure, and may apply a deciphering procedure, integrity verification procedure, or a header decompression procedure to each data, and see Kim ‘693, par. [0333]: (if a header compression procedure (or data compression procedure) is configured in the PDCP layer device, a header decompression procedure (or data decompression procedure) may be applied to each data, and the decompressed data may be transferred to an upper layer device); in this case, performing a header decompression procedure to obtain data corresponds to parsing PDCP headers to obtain PDCP SDU information. Deciphering corresponds to decrypting. The data may then be transmitted to an upper layer).
Regarding claim 11, the combination of Kim ‘693 in view of Kim ‘135, and further in view of Helman, and further in view of Rao, teaches the device. Kim ‘693 further teaches:
wherein the device further comprises:
a memory, coupled to the CPU and the hardware acceleration processor (see Kim ‘693, Fig. 28, par. [0488]: Referring to FIG. 28, the UE may include a radio frequency (RF) processor 1cd-10, a baseband processor 1cd-20, a memory 1cd-30, and a controller 1cd-40);
wherein the CPU is operable to: transmit the non-IP packet or the non-TCP/UDP packet to the upper layer (see Kim ‘693, par. [0239]: the PDCP layer device applies a header decompression procedure to the data, and transfer the data to an upper layer device in ascending order of the COUNT value, and see Kim ‘693, par. [0493]: The controller 1cd-40 may control overall operations of the UE. For example, the controller 1cd-40 may transmit and receive signals through the baseband processor 1cd-20 and the RF processor 1cd-10; in this case, a controller (corresponding to a CPU) may be used to transmit signals).
Kim ‘693 does not teach, but Kim ‘135 teaches:
wherein the hardware acceleration processor is further operable to:
transfer the packet to a memory of the computing device and instructing a central processing unit (CPU) of the computing device to perform the related processing on the packet in the memory in response to determining that the packet is not an IP packet or a TCP/UDP packet (see Kim ‘135, par. [0097]: the electronic device 101 may generate a PDCP SDU through reverse conversion of a data packet predicted to be lost. For example, a MAC PDU of the first communication protocol stack may be identified as data predicted to be lost (hereinafter referred to as loss-predicted data), and a PDCP SDU corresponding to the MAC PDU may be in a deleted state. In this case, when handing over the electronic device 101 to a cell corresponding to the second communication protocol stack, the electronic device 101 may generate a plurality of PDCP SDUs from the MAC PDU through reverse conversion for the MAC PDU generated by the E-UTRA MAC 318. For example, the electronic device 101 may store the PDCP SDUs generated through reverse conversion in a memory of the electronic device 101 at least temporarily, and see Kim ‘135, par. [0074]: an E-UTRA protocol stack may be referred to as a first communication protocol stack or a first protocol stack, and see Kim ‘135, par. [0140]: the inter-communication protocol stack PDCP SDU deliverer 570 may deliver information (e.g., address information) of a PDCP SDU stored in a memory region other than the PDCP buffer 504 to the protocol stack corresponding to the second bearer. The electronic device 101 may transmit data through the second bearer based on the delivered PDCP SDU (e.g., operation 630 of FIG. 6), and see Kim ‘135, Fig. 11, pars. [0159-0160]: in operation 1105, the at least one processor may store, during wireless communication based on the first RAT, at least one first data packet related to the first PDCP in the first buffer (e.g., the PDCP buffer 504) at least temporarily. For example, the at least one first data packet may include at least one first packet header including an identifier related to the first PDCP and at least one service data unit (SDU)…According to various embodiments, in operation 1110, the at least one processor, when the wireless communication is changed to wireless communication based on the second RAT, may change at least a portion of the stored at least one first data packet to at least one second data packet related to the second PDCP; in this case, a packet may be stored in memory for further processing by a controller (i.e. CPU) based on an identification of the communication protocol stack as data predicted to be lost (corresponding to in response to determining that the packet is not an IP or TCP/UDP packet));
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to have modified the device of Kim ‘693 with the transferring packets of Kim ‘135 with a reasonable expectation of success. One of ordinary skill in the art would have been motivated to make this modification for the benefit of preventing deterioration of service performance and preventing dropping of packets (see Kim ‘135, pars. [0017-0019]).
Claim 17 is rejected under 35 U.S.C. 103 as being unpatentable over Kim ‘693 in view of Kim ‘135, and further in view of Helman, and further in view of Rao, as applied to claims 1, 3-9, 11-16 above, and further in view of Wu (CN 113273303), published 17 August, 2021, hereinafter “Wu” (see “CN113273303_Translation.pdf” for citations).
Regarding claim 17, the combination of Kim ‘693 in view of Kim ‘135, and further in view of Helman, and further in view of Rao, teaches the device.
However, the combination of Kim ‘693 in view of Kim ‘135, and further in view of Helman, and further in view of Rao, does not teach:
wherein the MAC header comprises a 1-bit reserved field, a 1-bit format field, a 6-bit logical channel identifier (LCID) field, and an 8-bit length field.
Wu, in the same field of endeavor, teaches:
wherein the MAC header comprises a 1-bit reserved field, a 1-bit format field, a 6-bit logical channel identifier (LCID) field, and an 8-bit length field (see Wu, par. [n0110]: If the RAR is a variable-size CE, the first MAC subheader includes an R field (e.g., one bit), an F field (e.g., one bit), an LCID field (e.g., six bits), and an L field (e.g., eight or 16 bits)).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to have modified the MAC header of the combination of Kim ‘693 in view of Kim ‘135, and further in view of Helman, and further in view of Rao, with the specific fields of Wu with a reasonable expectation of success. One of ordinary skill in the art would have been motivated to make this modification for the benefit of allowing communication using several different formats for messages (see Wu, par. [n0007]).
Response to Arguments
Applicant’s arguments with respect to claims 1 and 9 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Jin et al. (US 2018/0368200) teaches a method and apparatus for processing packets in a next-generation mobile communication system.
Shaheen (US 10,880,871) teaches a 5G NR user equipment (UE) and 5G NR based station (gNB) for transmitting and receiving NR User Plane data traffic and NR Control Plane data.
Xu et al. (US 2024/0163674) teaches a method and apparatus for performing packet processing for network security.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CALEB J BALLOWE whose telephone number is (571)270-0410. The examiner can normally be reached MON-FRI 7:30-5.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Nishant B. Divecha can be reached at (571) 270-3125. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/C.J.B./Examiner, Art Unit 2419
/Nishant Divecha/Supervisory Patent Examiner, Art Unit 2419
Prosecution Insights