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 .
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 09/17/2024 was filed. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner
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.
Claims 1-3, 5-10, 12-16, and 18-20 are rejected under 35 U.S.C. 103 as being unpatentable over Grilli (US 2005/0193309 A1) in view of Vayanos (US 2008/0098283 A1).
Regarding claim 1, Grilli discloses: An apparatus for wireless communication at a transmitting device, comprising: one or more memories, because Grilli teaches an outer coding entity implemented with buffers that store service data units received from higher layers, which are memory structures: (Grilli, para [0160] “The Service Data Unit (SDU) buffer 412 receives user data (FEC SDUs) in the form of Service Data Units (SDUs) on radio bearer 402 as indicated by the arrow, and stores FEC SDUs from the higher layers.”)
Furthermore, Grilli discloses: one or more processors coupled to the one or more memories, the one or more processors individually or collectively configured to cause the transmitting device to: obtain a plurality of packet data convergence protocol (PDCP) packets, because Grilli teaches a transmitting forward error correction entity that receives user-plane information from the Packet Data Convergence Protocol layer sitting above it and processes those packets for outer coding: (Grilli, para [0133] “The Forward Error Correction (FEC) layer 157 receives user-plane information 163 directly over the user plane radio bearers. Because the Forward Error Correction (FEC) layer sits on top of the Radio Link Control (RLC) layer, FEC-Protocol Data Units (PDUs) correspond to the RLC-Service Data Units (SDUs).”)
Moreover, Grilli discloses: apply, in accordance with the difference between the PDCP packet size and the outer coding symbol size, a zero padding to at least one of the outer coding block or the plurality of outer coding symbols, because Grilli teaches organizing user data into payload rows by segmenting, concatenating, and padding data with insertion of overhead into the inner blocks before encoding the information block: (Grilli, para [0142] “assembled into large encoder packet or information block 91 by organizing user data into k payload rows by segmenting, concatenating, and padding data (including insertion of over head into inner blocks), and then encoding the resulting information block 91”)
In addition, Grilli discloses: transmit the outer coding block in accordance with applying the zero padding to at least one of the outer coding block or the plurality of outer coding symbols, because Grilli teaches transmitting the outer code block over the air as protocol data units while, because the row size is fixed and known at the receiver, refraining from transmitting the padding over the air: (Grilli, para [0198] “the 16 block outer code block 213 can be transmitted over the air as Protocol Data Units (PDUs) 214.”)
Although Grilli teaches an outer coding forward error correction entity above the RLC layer that obtains PDCP-layer user data into SDU buffers, segments, concatenates and pads the data into fixed-size inner blocks of an encoder packet, encodes them, and transmits the resulting outer code block while omitting the padding over the air: (Grilli, [0133], [0142], [0160], [0198]), Grilli does not explicitly disclose computing a difference between a PDCP packet size and an outer coding symbol size to drive the padding amount.
However, Grilli in view of Vayanos discloses calculate a difference between a PDCP packet size associated with the plurality of PDCP packets and an outer coding symbol size associated with a plurality of outer coding symbols because Vayanos teaches because each encoder packet row (an outer coding symbol) is a fixed integer number of bytes while the arriving SDUs are of arbitrary size, the transmitter must reconcile the gold packet size against the fixed inner block size, and this reference teaches constraining SDU sizes to byte multiples and matching the inner block size to the gold packet size so that the shortfall between the packet size and the fixed symbol size sets the padding to be added (Vayanos, para [0161], “Because the outer-code for the FEC layer 400 operates on byte size increments of data, the Encoder Packet (EP) row size would also need to be an integer number of bytes.”; Vayanos, para [0137], “performance of the outer code can be optimized since the inner block size matches the “gold” packet size of the packets that are sent over the air.”).
Therefore, it would have been obvious to one of ordinary skill in the art to compute the shortfall between the incoming PDCP packet size and the fixed outer coding symbol size as taught by Vayanos when filling the padding in Grilli's encoder packet rows, because Vayanos teaches that the outer code operates on byte-size increments and that its inner block size is set to match the gold packet size, so a PHOSITA reconciling variable-length SDUs against fixed-size symbol rows would naturally derive the padding amount from that size difference to keep the fixed-row encoder packet well formed and to avoid transmitting unnecessary bits over the air
Regarding claim 2, in spite of the fact that Grilli teaches the transmitting FEC entity that pads the encoder packet rows and transmits the outer code block while not sending the padding over the air: (Grilli, para [0142], [0198]), Grilli does not explicitly disclose adding zero padding bits and then refraining from transmitting those padding bits.
Yet, Grilli in view of Vayanos discloses The apparatus of claim 1, wherein applying the zero padding to at least one of the outer coding block or the plurality of outer coding symbols comprises adding one or more zero padding bits to the outer coding block or the plurality of outer coding symbols, and wherein transmitting the outer coding block comprises refraining from transmitting the one or more zero padding bits associated with the outer coding block or the plurality of outer coding symbols because padding is inserted into each fixed-size encoder packet row, but because the row size is fixed and therefore known at the receiver it is unnecessary to actually transmit the padding over the air, which reads on adding padding bits and then refraining from transmitting them (Vayanos, para [0185], “Since the Encoder Packet k(EP) 213 row size is fixed and therefore known at the receiver, it is unnecessary to actually transmit the padding 208 over the air.”).
Thus, it would have been obvious to one of ordinary skill in the art to add the padding bits to the fixed encoder packet rows yet refrain from transmitting them as taught by Vayanos, because Vayanos teaches that the fixed and receiver-known row size makes it unnecessary to send the padding over the air, which conserves radio resources while still allowing the receiver to reconstruct the block, a predictable benefit a PHOSITA would seek in Grilli's outer coding transmitter.
Regarding claim 3, although Grilli teaches the transmitting FEC entity whose outer code operates on fixed-size encoder packet rows configured through lower-layer setup: (Grilli, para [0142], [0171]), Grilli does not explicitly disclose obtaining an indication of the outer coding symbol size from a physical layer.
Yet, Grilli in view of Vayanos discloses The apparatus of claim 1, wherein the one or more processors are further configured to cause the transmitting device to obtain an indication of the outer coding symbol size from a physical layer because the physical layer performs channel coding including forward error correction and communicates the PDUs to and from the transport channels, so the transmitter obtains the outer coding row/symbol size constraint from the physical layer processing that fixes the block dimensions for over-the-air transmission (Vayanos, para [0109], “The physical layer (Ll) typically performs multiplexing and channel coding including CRC calculation, forward-error correction (FEC), rate matching, interleaving transport channel data, and multiplexing transport channel data”).
Consequently, it would have been obvious to one of ordinary skill in the art to obtain the outer coding symbol size indication from the physical layer as taught by Vayanos, because Vayanos teaches that the physical layer performs channel coding, forward error correction, and rate matching that fix the transmitted block dimensions, so a PHOSITA sizing Grilli's outer coding symbols would rely on the physical layer's size constraints to keep the encoded block acceptable for transmission.
Regarding claim 5, even though Grilli teaches the transmitting FEC entity that pads the encoder packet to reach the fixed row size before encoding and transmission: (Grilli, para [0142], [0186]), Grilli does not explicitly disclose applying the zero padding to an end of the outer coding block.
Yet, Grilli in view of Vayanos discloses The apparatus of claim 1, wherein the one or more processors, to cause the transmitting device to apply the zero padding to at least one of the outer coding block or the outer coding symbols, are configured to cause the transmitting device to apply the zero padding to an end of the outer coding block because where there is not enough data to build a PDU the layer adds padding, and a length indicator marks the last octet of an SDU ending within the PDU so that the remaining space at the end of the block is filled with padding, which reads on applying zero padding to an end of the outer coding block (Vayanos, para [0178], “For example, a Length Indicator (LI) can be used to indicate the last octet of each FEC Service Data Unit (SDU) ending within the Payload Data Unit (PDU).”).
Therefore, it would have been obvious to one of ordinary skill in the art to place the zero padding at the end of the outer coding block as taught by Vayanos, because Vayanos teaches using length indicators to mark where the last SDU octet ends within the PDU so the trailing space is filled by padding, and a PHOSITA completing Grilli's fixed-size encoder packet would predictably append the padding after the payload to reach the fixed block length.
Regarding claim 6, in spite of the fact that Grilli teaches the transmitting FEC entity that pads each fixed-size inner block row of the encoder packet before encoding: (Grilli, para [0142], [0185]), Grilli does not explicitly disclose applying the zero padding to an end of each outer coding symbol of the plurality of outer coding symbols.
Yet, Grilli in view of Vayanos discloses The apparatus of claim 1, wherein the one or more processors, to cause the transmitting device to apply the zero padding to at least one of the outer coding block or the outer coding symbols, are configured to cause the transmitting device to apply the zero padding to an end of each outer coding symbol of the plurality of outer coding symbols because each encoder packet row (an outer coding symbol) is a fixed byte-integer size, so any row not filled by payload is completed with padding at its end, which reads on applying the padding to the end of each outer coding symbol (Vayanos, para [0161], “Because the outer-code for the FEC layer 400 operates on byte size increments of data, the Encoder Packet (EP) row size would also need to be an integer number of bytes.”).
Accordingly, it would have been obvious to one of ordinary skill in the art to apply the padding to the end of each outer coding symbol as taught by Vayanos, because Vayanos teaches that each encoder packet row must be an integer number of bytes, so a PHOSITA aligning Grilli's per-row symbols to a fixed byte size would pad the trailing portion of each row, achieving the predictable result of uniformly sized coding symbols.
Regarding claim 7, even though Grilli teaches the transmitting FEC entity that appends header overhead including a sequence number to each row of the outer code block: (Grilli, para [0198]), Grilli does not explicitly disclose an outer coding header of each symbol indicating a first radio link control sequence number of the outer coding block.
Yet, Grilli in view of Vayanos discloses The apparatus of claim 1, wherein an outer coding header of each outer coding symbol of the plurality of outer coding symbols indicates a first radio link control sequence number of the outer coding block because the sequence number generator adds a sequence number at the front of each outer code block to generate PDUs, and this header is appended after the encoding so that each symbol's outer header carries the sequence number identifying the block, which reads on the outer coding header indicating a first RLC sequence number of the outer coding block (Vayanos, para [0158], “the sequence number generator adds, for example, an eight bit sequence number at the front of each outer code block to generate PDUs.”).
Thus, it would have been obvious to one of ordinary skill in the art to include in each outer coding symbol's header a sequence number identifying the block as taught by Vayanos, because Vayanos teaches adding a sequence number at the front of each outer code block to generate PDUs for reordering and duplicate detection, and a PHOSITA building Grilli's outer coding transmitter would carry that sequence-number header to let the receiver realign the symbols with their encoder packet.
Regarding claim 8, although Grilli teaches the transmitting FEC entity that obtains user-plane PDCP packets and organizes them into the encoder packet for outer coding: (Grilli, para [0133]), Grilli does not explicitly disclose the plurality of PDCP packets being associated with a protocol data unit set or a protocol data unit burst.
Yet, Grilli in view of Vayanos discloses The apparatus of claim 1, wherein the plurality of PDCP packets are associated with at least one of a protocol data unit set or a protocol data unit burst because the FEC layer transfers user-plane information as encoder packets built from groups of protocol data units, and additional overhead realigns the PDUs with an encoder packet during asynchronous transmission, so the grouped PDUs form a protocol data unit set or burst carried by the outer coding block (Vayanos, para [0128], “Use of additional overhead, such as sequence number, with unacknowledged transmissions can enable realigmnent of the Protocol Data Units (PDUs) with an Encoder Packet (EP) during asynchronous transmission of MBMS data.”).
Consequently, it would have been obvious to one of ordinary skill in the art to treat the plurality of PDCP packets as a protocol data unit set or burst as taught by Vayanos, because Vayanos teaches grouping and realigning multiple protocol data units into a single encoder packet for asynchronous transmission, and a PHOSITA in Grilli's outer coding transmitter would organize the incoming packets as such a set so the outer code spans a coherent group of PDUs.
Regarding claim 9, Grilli discloses: An apparatus for wireless communication at a receiving device, comprising: one or more memories, because Grilli teaches a receiving forward error correction entity that includes a receive buffer for reordering and duplicate detection, a memory structure holding received PDUs: (Grilli, para [0174] “the receiving Forward Error Correction (FEC) entity 430 includes a receive buffer/ reordering/duplicate detection unit 438, a sequence number removal unit 436, an outer decoder 434 that performs”)
Furthermore, Grilli discloses: one or more processors coupled to the one or more memories, the one or more processors individually or collectively configured to cause the receiving device to: receive a plurality of radio link control (RLC) protocol data units (PDUs), because Grilli teaches a receiving FEC entity that determines when a new FEC PDU corresponding to an RLC SDU is received and buffers it for decoding: (Grilli, para [0215] “At block 1410, it can be determined whether a new Forward Error Correction (FEC) Protocol Data Unit (PDU) is received.”)
Moreover, Grilli discloses: process the outer coding block or the plurality of outer coding symbols in accordance with the zero padding length to obtain a plurality of packet data convergence protocol (PDCP) packets, because Grilli teaches an outer decoder that performs Reed-Solomon decoding and a reassembly unit that reconstructs the SDUs, using length indicators to know where the SDU and padding start and end, delivering the recovered packets to higher layers: (Grilli, para [0192] “When the outer block is received, information, such as Length Indicators (Lis), can be used to let the receiver know where the Service Data Unit (SDU) and/ or padding start and end.”)
Although Grilli teaches a receiving outer coding FEC entity with a reorder/duplicate-detection buffer that receives FEC PDUs corresponding to RLC SDUs, Reed-Solomon decodes the outer block, and uses length indicators to locate where the SDU and padding start and end while reassembling the recovered packets for higher layers: (Grilli, [0174], [0192], [0215]), Grilli does not explicitly disclose identifying a difference between an RLC PDU size and an outer coding symbol size and estimating a corresponding zero padding length.
Yet, Grilli in view of Vayanos discloses identify a difference between an RLC PDU size associated with the plurality of RLC PDUs and an outer coding symbol size associated with a plurality of outer coding symbols included in an outer coding block because Vayanos teaches because the encoder packet row size is fixed and known at the receiver while the transmitted PDUs carry only the payload, the receiver reconciles the fixed row (symbol) size against the received PDU size, which reads on identifying the difference between the RLC PDU size and the outer coding symbol size (Vayanos, para [0185], “Since the Encoder Packet k(EP) 213 row size is fixed and therefore known at the receiver, it is unnecessary to actually transmit the padding 208 over the air.”).
Furthermore, Vayanos discloses estimate a zero padding length for at least one of the outer coding block or the plurality of outer coding symbols in accordance with the difference between the RLC PDU size and the outer coding symbol size because Vayanos teaches because the fixed row size is known at the receiver, the receiver reconstitutes the omitted padding by inferring its length from the difference between the fixed symbol size and the received data, and uses length indicators to know where padding ends, which reads on estimating the zero padding length from that size difference (Vayanos, para [0179], “When the outer block is received, information, such as Length Indicators (Lis), can be used to let the receiver know where the Service Data Unit (SDU) and/ or padding start and end.”).
Consequently, it would have been obvious to one of ordinary skill in the art to identify the difference between the received RLC PDU size and the fixed outer coding symbol size and to estimate the padding length from it as taught by Vayanos, because Vayanos teaches that the fixed encoder packet row size is known at the receiver so the padding need not be sent, and length indicators let the receiver locate where padding starts and ends, so a PHOSITA decoding Grilli's outer block would reconstruct the omitted padding from that size difference to correctly reassemble the SDUs
Regarding claim 10, although Grilli teaches the receiving outer coding entity whose fixed symbol size for decoding derives from physical layer processing: (Grilli, para [0174], [0192]), Grilli does not explicitly disclose obtaining an indication of the outer coding symbol size from a physical layer.
Yet, Grilli in view of Vayanos discloses The apparatus of claim 9, wherein the one or more processors are further configured to cause the receiving device to obtain an indication of the outer coding symbol size from a physical layer because the physical layer performs channel coding including forward error correction and rate matching that fixes the transmitted block dimensions, so the receiver obtains the outer coding symbol size from that physical layer processing (Vayanos, para [0109], “The physical layer (Ll) typically performs multiplexing and channel coding including CRC calculation, forward-error correction (FEC), rate matching, interleaving transport channel data, and multiplexing transport channel data”).
Therefore, it would have been obvious to one of ordinary skill in the art to obtain the outer coding symbol size from the physical layer as taught by Vayanos, because Vayanos teaches that the physical layer performs channel coding, forward error correction, and rate matching that fix the block dimensions, so a PHOSITA in Grilli's receiver would obtain the symbol size from those physical layer parameters to decode the outer block correctly.
Regarding claim 12, although Grilli teaches the receiving outer coding entity that uses length indicators to locate where the SDU and padding start and end in the received block: (Grilli, para [0192]), Grilli does not explicitly disclose estimating the zero padding length for an end of the outer coding block.
Yet, Grilli in view of Vayanos discloses The apparatus of claim 9, wherein the one or more processors, to cause the receiving device to estimate the zero padding length for at least one of the outer coding block or the outer coding symbols, are configured to cause the receiving device to estimate the zero padding length for an end of the outer coding block because the receiver uses length indicators to know where the SDU and padding start and end, so it infers the trailing padding length at the end of the received outer block, which reads on estimating the zero padding length for an end of the outer coding block (Vayanos, para [0179], “When the outer block is received, information, such as Length Indicators (Lis), can be used to let the receiver know where the Service Data Unit (SDU) and/ or padding start and end.”).
Thus, it would have been obvious to one of ordinary skill in the art to estimate the padding length at the end of the outer coding block as taught by Vayanos, because Vayanos teaches that length indicators let the receiver locate where the SDU and padding start and end, so a PHOSITA in Grilli's receiver would infer the trailing padding at the block end to correctly reassemble the SDUs.
Regarding claim 13, in spite of the fact that Grilli teaches the receiving entity that estimates the trailing padding at the block end from known sizes to reassemble the SDUs: (Grilli, para [0192]), Grilli does not explicitly disclose estimating the end-of-block padding length in accordance with the outer coding symbol size and the RLC PDU size.
Yet, Grilli in view of Vayanos discloses The apparatus of claim 12, wherein the one or more processors, to cause the receiving device to estimate the zero padding for the end of the outer coding block, are configured to cause the receiving device to estimate the zero padding length for the end of the outer coding block in accordance with the outer coding symbol size and the RLC PDU size because because the encoder packet row size is fixed and known at the receiver, the receiver computes the omitted end padding from the fixed symbol row size relative to the received PDU data, which reads on estimating the end-of-block padding from the outer coding symbol size and the RLC PDU size (Vayanos, para [0185], “Since the Encoder Packet k(EP) 213 row size is fixed and therefore known at the receiver, it is unnecessary to actually transmit the padding 208 over the air.”).
Consequently, it would have been obvious to one of ordinary skill in the art to compute the end-of-block padding length from the fixed symbol size and the received RLC PDU size as taught by Vayanos, because Vayanos teaches that the fixed row size is known at the receiver so the padding can be reconstructed rather than transmitted, and a PHOSITA in Grilli's receiver would derive that padding length from the size difference to rebuild the block.
Regarding claim 14, even though Grilli teaches the receiving outer coding entity that locates where SDU and padding start and end within each received row: (Grilli, para [0192]), Grilli does not explicitly disclose estimating the zero padding length for an end of each outer coding symbol.
Yet, Grilli in view of Vayanos discloses The apparatus of claim 9, wherein the one or more processors, to cause the receiving device to estimate the zero padding length for at least one of the outer coding block or the outer coding symbols, are configured to cause the receiving device to estimate the zero padding length for an end of each outer coding symbol of the plurality of outer coding symbols because each encoder packet row is a fixed byte-integer size, so the receiver infers the padding at the end of each such row (symbol) from the known fixed row size, which reads on estimating the padding length for the end of each outer coding symbol (Vayanos, para [0161], “Because the outer-code for the FEC layer 400 operates on byte size increments of data, the Encoder Packet (EP) row size would also need to be an integer number of bytes.”).
For these reasons, it would have been obvious to one of ordinary skill in the art to estimate the padding length at the end of each outer coding symbol as taught by Vayanos, because Vayanos teaches that each encoder packet row is a fixed integer number of bytes, so a PHOSITA in Grilli's receiver would infer the per-row trailing padding from that fixed size to reassemble each symbol.
Regarding claim 15, in spite of the fact that Grilli teaches the receiving entity that infers per-symbol trailing padding from the known fixed row size: (Grilli, para [0192]), Grilli does not explicitly disclose estimating the per-symbol padding length in accordance with the outer coding symbol size and the RLC PDU size.
Yet, Grilli in view of Vayanos discloses The apparatus of claim 14, wherein the one or more processors, to cause the receiving device to estimate the zero padding length for the end of each outer coding symbol, are configured to cause the receiving device to estimate the zero padding length for the end of each outer coding symbol in accordance with the outer coding symbol size and the RLC PDU size because because each row is a fixed byte-integer size known at the receiver, the receiver computes the per-symbol padding from that fixed symbol size relative to the received PDU data, which reads on estimating the per-symbol padding from the outer coding symbol size and the RLC PDU size (Vayanos, para [0185], “Since the Encoder Packet k(EP) 213 row size is fixed and therefore known at the receiver, it is unnecessary to actually transmit the padding 208 over the air.”).
Therefore, it would have been obvious to one of ordinary skill in the art to compute each symbol's padding length from the fixed symbol size and the received RLC PDU size as taught by Vayanos, because Vayanos teaches that the fixed, receiver-known row size makes reconstruction of the omitted padding possible, so a PHOSITA in Grilli's receiver would derive each symbol's padding from that size difference to rebuild the encoder packet.
Regarding claim 16, even though Grilli teaches the receiving outer coding entity that removes the sequence number header appended to each row of the outer code block: (Grilli, para [0174]), Grilli does not explicitly disclose an outer coding header of each symbol indicating a first radio link control sequence number of the outer coding block.
Yet, Grilli in view of Vayanos discloses The apparatus of claim 9, wherein an outer coding header of each outer coding symbol of the plurality of outer coding symbols indicates a first radio link control sequence number of the outer coding block because the sequence number generator adds a sequence number at the front of each outer code block to generate PDUs, so each symbol's outer header carries the sequence number identifying the block for the receiver to reorder and realign, which reads on the outer coding header indicating a first RLC sequence number of the outer coding block (Vayanos, para [0158], “the sequence number generator adds, for example, an eight bit sequence number at the front of each outer code block to generate PDUs.”).
Accordingly, it would have been obvious to one of ordinary skill in the art to have each outer coding symbol's header indicate a sequence number identifying the block as taught by Vayanos, because Vayanos teaches adding a sequence number at the front of each outer code block for reordering and realignment, so a PHOSITA in Grilli's receiver would read that per-symbol header to associate each symbol with its encoder packet.
Regarding claim 18, the claim recites: The apparatus of claim 9, wherein the plurality of PDCP packets are associated with at least one of a protocol data unit set or a protocol data unit burst. Claim 18 is analogous to claim 8 and is rejected for the same reasons.
Regarding claim 19, Grilli discloses: An apparatus for wireless communication at a transmitting device, comprising one or more memories, because Grilli teaches a transmitting FEC entity with an SDU buffer that stores FEC SDUs received from the higher layers, a memory structure: (Grilli, para [0160] “The Service Data Unit (SDU) buffer 412 receives user data (FEC SDUs) in the form of Service Data Units (SDUs) on radio bearer 402 as indicated by the arrow, and stores FEC SDUs from the higher layers.”)
Furthermore, Grilli discloses: one or more processors coupled to the one or more memories, the one or more processors individually or collectively configured to cause the transmitting device to: obtain a plurality of packet data convergence protocol (PDCP) packets, because Grilli teaches a transmitting FEC entity that receives user-plane information from the PDCP layer above it, so that its FEC PDUs correspond to those upper-layer packets: (Grilli, para [0133] “The Forward Error Correction (FEC) layer 157 receives user-plane information 163 directly over the user plane radio bearers. Because the Forward Error Correction (FEC) layer sits on top of the Radio Link Control (RLC) layer, FEC-Protocol Data Units (PDUs) correspond to the RLC-Service Data Units (SDUs).”)
Moreover, Grilli discloses: generate an outer coding block in accordance with assembling the plurality of outer coding symbols, because Grilli teaches assembling the segmented and padded user data into a large encoder packet or information block that is then encoded: (Grilli, para [0142] “and then encoding the resulting information block 91 to generate N-k parity rows 93”)
In addition, Grilli discloses: apply a forward error correction encoding to the outer coding block, because Grilli teaches an outer encoder that performs Reed-Solomon encoding on the assembled information block to generate the parity rows: (Grilli, para [0159] “an outer encoder 416 that performs Reed-Solomon (RS) encoding, a sequence number generator 418 that adds a sequence number to the encoded PDUs”)
Furthermore, Grilli discloses: transmit the outer coding block in accordance with applying the forward error correction to the outer coding block, because Grilli teaches transmitting the encoded outer code block over the air as protocol data units after adding overhead to each row: (Grilli, para [0198] “the 16 block outer code block 213 can be transmitted over the air as Protocol Data Units (PDUs) 214.”)
Although Grilli teaches a transmitting outer coding FEC entity above the RLC layer that obtains PDCP-layer user data into an SDU buffer, segments and assembles it into the rows of an encoder packet, applies Reed-Solomon forward error correction to generate parity rows, and transmits the resulting outer code block over the air as PDUs: (Grilli, [0133], [0142], [0159], [0160], [0198]), Grilli does not explicitly disclose sizing the segmentation of each packet into symbols according to a defined outer coding symbol size.
Yet, Grilli in view of Vayanos discloses segment each PDCP packet of the plurality of PDCP packets into a plurality of outer coding symbols in accordance with an outer coding symbol size because Vayanos teaches because the outer code operates on byte-size increments and the encoder packet row size must be an integer number of bytes, the segmentation of each packet into rows is performed in accordance with that defined symbol size, which reads on segmenting each PDCP packet into outer coding symbols in accordance with an outer coding symbol size (Vayanos, para [0161], “Because the outer-code for the FEC layer 400 operates on byte size increments of data, the Encoder Packet (EP) row size would also need to be an integer number of bytes.”).
Consequently, it would have been obvious to one of ordinary skill in the art to segment each PDCP packet into outer coding symbols according to a defined outer coding symbol size as taught by Vayanos, because Vayanos teaches that the outer code operates on byte-size increments and each encoder packet row must be an integer number of bytes, so a PHOSITA assembling Grilli's encoder packet would size the segmentation to that fixed row size to produce a well-formed, byte-aligned outer coding block
Regarding claim 20, in spite of the fact that Grilli teaches the transmitting FEC entity that segments the packets into encoder packet rows before assembling and encoding the outer coding block for transmission: (Grilli, para [0142], [0198]), Grilli does not explicitly disclose transmitting the block after segmenting each PDCP packet prior to generating the outer coding block.
Yet, Grilli in view of Vayanos discloses The apparatus of claim 19, wherein the one or more processors, to transmit the outer coding block, are configured to transmit the outer coding block in accordance with segmenting each PDCP packet of the plurality of PDCP packets prior to generating the outer coding block because the segmentation and concatenation unit segments the SDUs before the outer encoder assembles and encodes the block, and the resulting block is then transmitted, so segmentation of each packet occurs prior to generating the outer coding block that is transmitted (Vayanos, para [0150], “The transmitting Forward Error Correction (FEC) entity 410 includes a Service Data Unit (SDU) buffer 412 for receiving SDUs, a segmentation and concatenation unit 414, an outer encoder 416 that performs Reed-Solomon (RS) encoding”).
Therefore, it would have been obvious to one of ordinary skill in the art to segment each PDCP packet prior to generating and transmitting the outer coding block as taught by Vayanos, because Vayanos teaches a transmit chain in which a segmentation and concatenation unit precedes the outer encoder, so a PHOSITA in Grilli's transmitter would segment the packets before assembling and encoding the block, achieving the predictable ordered pipeline the claim recites.
Claims 4 and 11 are rejected under 35 U.S.C. 103 as being unpatentable over Grilli (US 2005/0193309 A1) in view of Vayanos (US 2008/0098283 A1) and further in view of Kim (US 2009/0059853 A1).
Regarding claim 4, in spite of the fact that Grilli in view of Vayanos teaches the transmitting outer coding combination that obtains PDCP-layer user data and sizes the encoder packet segmentation against the fixed byte-integer symbol size: (Grilli, para [0133], [0142]; Vayanos, para [0161]), Grilli in view of Vayanos does not explicitly disclose obtaining the packet size from an application layer where the packet size is based on an IP packet size plus a header size.
Yet, Grilli in view of Vayanos and further in view of Kim discloses The apparatus of claim 1, wherein the one or more processors are further configured to cause the transmitting device to obtain an indication of the PDCP packet size from an application layer, wherein the one or more processors are further configured to cause the transmitting device to obtain an indication of the PDCP packet size from an application layer because the transmission device recognizes, in the call setup process from higher layers, the size of the packet most frequently generated for the application service, so it obtains an indication of the packet size from an application layer (Kim, para [0045], “The network 210 calculates a size of the packet that will be most frequently generated in the call it desires to set up.”).
Moreover, Kim discloses wherein the PDCP packet size is based at least in part on an Internet Protocol packet size and at least one of a service data adaptation protocol header size or a PDCP header size because the most-frequent packet size is computed for a VoIP call where the IP/UDP/RTP header of the packet is header-compressed, so the resulting packet size is based on the IP packet payload together with the compressed header, which reads on the size being based on an IP packet size and a header size (Kim, para [0045], “if an Internet Protocol (IP)/User Datagram Protocol (UDP)/ Routing Table Protocol (RTP) header of a VoIP packet is compressed with a Robust Header Compression (ROHC) protocol, a size of the packet which is most frequently generated is as shown in Table 1”).
For these reasons, it would have been obvious to one of ordinary skill in the art to obtain the PDCP packet size from the application layer and to base it on the IP packet size plus its compressed header as taught by Kim, because Kim teaches that the network computes the most-frequently-generated packet size for a service during call setup, deriving that value from the IP/UDP/RTP header compressed with ROHC, so a PHOSITA computing the size difference in the Grilli-Vayanos transmitter would obtain the packet size this way to accurately determine the padding for each fixed-size symbol, thereby satisfying both the application-layer source of the size and its dependence on the IP packet and header sizes.
Regarding claim 11, in spite of the fact that Grilli in view of Vayanos teaches the receiving outer coding combination that reconstructs the omitted padding from the fixed symbol size and received PDU data to reassemble the packets: (Grilli, para [0192]; Vayanos, para [0185]), Grilli in view of Vayanos does not explicitly disclose obtaining the RLC PDU size from an application layer where the size is based on an IP PDU size plus a header size.
Yet, Grilli in view of Vayanos and further in view of Kim discloses The apparatus of claim 9, wherein the one or more processors are further configured to cause the receiving device to obtain an indication of the RLC PDU size from an application layer, wherein the one or more processors are further configured to cause the receiving device to obtain an indication of the RLC PDU size from an application layer because the network determines, during the call setup process from higher layers, the size of the packet most frequently generated for the application service, so the receiving device obtains an indication of the PDU size from an application layer (Kim, para [0045], “The network 210 calculates a size of the packet that will be most frequently generated in the call it desires to set up.”).
Moreover, Kim discloses wherein the RLC PDU size is in accordance with an Internet Protocol PDU size and at least one of a service data adaptation protocol header size or an RLC header size because the size condition is derived from the most-frequently-generated packet size for the service, computed from a VoIP IP/UDP/RTP packet whose header is compressed, so the PDU size accords with the IP PDU size plus its header, which reads on the RLC PDU size being based on an IP PDU size and a header size (Kim, para [0045], “if an Internet Protocol (IP)/User Datagram Protocol (UDP)/ Routing Table Protocol (RTP) header of a VoIP packet is compressed with a Robust Header Compression (ROHC) protocol, a size of the packet which is most frequently generated is as shown in Table 1”).
Accordingly, it would have been obvious to one of ordinary skill in the art to obtain the RLC PDU size from the application layer and to base it on the IP PDU size plus its compressed header as taught by Kim, because Kim teaches that the size condition of the bundled packets is recognized during call setup from higher layers and derives from the most-frequently-generated packet computed from a header-compressed IP/UDP/RTP packet, so a PHOSITA in the Grilli-Vayanos receiver would obtain the PDU size this way to accurately reconstruct the omitted padding, thereby satisfying both the application-layer source of the size and its dependence on the IP PDU and header sizes.
For these reasons Grilli and Vayanos are combined for the reasons set forth in the rejection of claim 1 above.
Claim 17 is rejected under 35 U.S.C. 103 as being unpatentable over Grilli (US 2005/0193309 A1) in view of Vayanos (US 2008/0098283 A1) and further in view of Thomas (WO 2022/122159 A1).
Regarding claim 17, although Grilli in view of Vayanos teaches the receiving outer coding combination whose per-symbol header carries the sequence number identifying the outer coding block for reordering and realignment: (Grilli, para [0174]; Vayanos, para [0158]), Grilli in view of Vayanos does not explicitly disclose calculating an outer coding sequence number from an RLC sequence number and the first RLC sequence number of the block.
Yet, Grilli in view of Vayanos and further in view of Thomas discloses The apparatus of claim 16, wherein the one or more processors are further configured to cause the receiving device to calculate an outer coding sequence number of the outer coding block using a radio link control sequence number of the outer coding block and the first radio link control sequence number of the outer coding block because Thomas links the network coded PDCP PDUs to the original PDCP PDUs by a linking formula that gives the network coded PDU sequence number in terms of the original PDU sequence numbers, so the coded (outer) block sequence number is calculated from the constituent PDU sequence numbers including the first one used to code the block (Thomas, para [0021], “According to one example embodiment, the second packet data convergence protocol (PDCP) entity is configured to: link original packet data convergence protocol (PDCP) protocol data units (PDUs) to network coded packet data convergence protocol (PDCP) protocol data units (PDUs) by a formula”).
Thus, it would have been obvious to one of ordinary skill in the art to add Thomas's linking-formula computation of the coded block sequence number from the original PDU sequence numbers to the Grilli-Vayanos receiver, because Thomas teaches deriving the sequence number of the network coded PDU from the sequence numbers of the original PDUs used to code it, so a PHOSITA would compute the outer coding block sequence number from the constituent RLC sequence numbers, including the first, to correctly associate coded blocks with the packets they protect and reconstruct missing originals.
Thus Grilli and Vayanos are combined for the reasons set forth in the rejection of claim 1 above.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CHONGSUH (John) PARK whose telephone number is 408-918-7574. The examiner can normally be reached Monday - Friday 8:00-5:30 PST
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, Avellino, Joseph can be reached at 571-272-3905 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.
/CHONGSUH PARK/Examiner, Art Unit 2478
/JOSEPH E AVELLINO/Supervisory Patent Examiner, Art Unit 2478
Prosecution Insights