DETAILED ACTION
This office action in response to an application filing received September 20, 2024. The Application Data Sheet received on September 20, 2024 has been considered.
Claims 1-20 are pending.
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 Rejections - 35 USC § 103
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 non-obviousness.
Claim(s) 1-8, 11 and 13-20 are rejected under 35 U.S.C. 103 as being unpatentable over JIANG, US 20240179729 A1, (hereinafter JIANG) in view of Vajapeyam et al., US 20170041767 A1, (hereinafter Vajapeyam).
Regarding claim 1, and 19, JIANG teaches a user equipment (UE), comprising: one or more memories storing processor-executable code; and one or more processors coupled with the one or more memories and individually or collectively operable to execute the code to cause the UE to (see Fig. 1, e.g., element 102; Fig. 15, element 1500):
receive a first packet data convergence protocol (PDCP) protocol data unit (PDU) that comprises a set of bits, a first sequence number, and data (see ¶ [0043], e.g., the adjustment parameter of the variable of the receiving window of the PDCP entity may include at least one of the followings: a window length of the receiving window, a boundary value of the receiving window, a HFN value in a header of a first data packet received by the PDCP entity, a SN value in the header of the first data packet, and a COUNT value in the header of the first data packet; see ¶ [0106] - [0107], e.g., At step S801, a sequence number carried in a header of a first PDCP data packet received by the PDCP entity is determined as an adjustment parameter.);
set one or more parameters associated with a PDCP window based at least in part on a value of the set of bits and the first sequence number (see ¶ [0108] - [0116], e.g., a third sum of the sequence number carried in the header and a third target value is determined, and the lower boundary value of the receiving window and/or the sequence number of the next PDCP SDU to be received is configured to be the third sum… with the reasonable configuration of the third target value, the lower boundary value of the receiving window of the PDCP entity can maintain within a reasonable range after a new terminal device is accepted to join in),
based at least in part on the first Sequence number being within the PDCP window for PDCP PDU reordering (see ¶ [0041] - [0042], e.g., The receiving entity of the PDCP can reorder received PDU data packets in an order of PDCP sequence number (denoted as COUNT). The reordered PDCP data packets can be delivered to a higher-level protocol entity in sequence according to the COUNT… For a PDU data packet to be received, the PDCP entity may start a reordering timer, and when the reordering timer is expired, the PDCP entity ignores the “COUNT of the PDU data packet to be received” and updates the lower boundary of the receiving window… As illustrated in FIG. 3, initial values of the variables “RX_DELIV” and “RX_NEXT” of the PDCP entity are 0. When a PDU data packet numbered “1” is received, it means that a PDU data packet numbered “0” is not received. The PDCP entity updates the “RX_NEXT” to “2”. In response to the need to start the reordering timer, the “RX_REORD” is set to “2”. When a PDU data packet numbered “2” is received, the “RX_NEXT” is updated to “3”.).
however, it does not explicitly teach wherein the PDCP window indicates a range of sequence numbers that are to be stored at the UE for reordering of received PDCP PDUs; and
store the first PDCP PDU in a buffer with one or more other PDCP PDUs.
Vajapeyam teaches, wherein the PDCP window indicates a range of sequence numbers that are to be stored at the UE for reordering of received PDCP PDUs (see ¶ [0048], e.g., The PDCP layers 210 may perform reordering by establishing a reordering window that defines a range of PDCP SNs that are eligible for reordering. If a PDCP PDU is received from a MAC layer 215 that contains SDUs with PDCP SNs outside of the reordering window, the respective PDCP layers 210 may discard the PDU. The PDCP layers 210 may then process non-discarded PDUs and store associated SDUs in a reordering buffer.); and
store the first PDCP PDU in a buffer with one or more other PDCP PDUs (see ¶ [0049] - [0050], e.g., the reordering window may be one-half of available range of PDCP SNs, and PDCP PDUs that fall outside of the range may be discarded, with received PDCP PDUs within the range being stored (e.g., in a packet buffer) and processed. The reordering window, as noted above, may be anchored at the SN that was submitted to the respective upper layers, and PDUs received that are outside the window may be discarded while PDUs within the window may be stored and processed.).
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 receiving of a first packet data convergence protocol (PDCP) protocol data unit (PDU) of JIANG to incorporate the teachings of Vajapeyam to include wherein the PDCP window indicates a range of sequence numbers that are to be stored at the UE for reordering of received PDCP PDUs; and store the first PDCP PDU in a buffer with one or more other PDCP PDUs. Doing so would facilitate in achieving managing SRBs to provide enhanced reception as suggested by Vajapeyam (see ¶ [0061], e.g., SRBs may be configured with reordering parameters that provide enhanced likelihood of proper reception and processing of SRB information. SRBs may have particularly high reliability requirements because these radio bearers may not have associated processes at the upper layers that may trigger retransmission of lost PDUs. Thus, the PDCP layer, in some examples, may manage SRBs to provide enhanced reception. In some examples, the reordering timer for SDUs associated with an SRB may be set to infinity (or a timer limitation for an SRB may be otherwise disabled), thus helping to ensure that PDCP PDUs are received in the reordering buffer prior to pushing the reordering window.).
Regarding claim 2, and 20, JIANG as combined with Vajapeyam teaches the limitations of Claim 1, and 19.
JIANG further teaches, wherein, to set the one or more parameters associated with the PDCP window, the one or more processors are individually or collectively operable to execute the code to cause the UE to: set a lower bound of the range of sequence numbers as the first sequence number (see ¶ [0108] - [0111], e.g., At step S802, the variable of the receiving window is configured according to the sequence number carried in the header… a sequence number indicated in the header of the first PDCP data packet is 4, a SN portion of the lower boundary value RX_DELIV of the receiving window is configured to be 4,).
Regarding claim 3, JIANG as combined with Vajapeyam teaches the limitations of Claim 1.
JIANG further teaches, wherein the one or more processors are individually or collectively further operable to execute the code to cause the UE to: apply, based at least in part on the set of bits having a first value of two or more values, the one or more parameters associated with the PDCP window upon receipt of the set of bits (see ¶ [0093] - [0114], e.g., Optionally, a third sum of the sequence number carried in the header and a third target value is determined, and the lower boundary value of the receiving window and/or the sequence number of the next PDCP SDU to be received is configured to be the third sum… the sequence number indicated in the header of the first PDCP data packet is set to 4, and the third target value c is 1, thus the third sum is 4+1=5. Further, the SN portion of the lower boundary value RX_DELIV of the receiving window can be configured as 5, or the SN portion of the sequence number RX_NEXT of the next PDCP SDU to be received can be configured as 5).
Regarding claim 4, JIANG as combined with Vajapeyam teaches the limitations of Claim 1.
JIANG further teaches, wherein the one or more processors are individually or collectively further operable to execute the code to cause the UE to:
apply, based at least in part on the set of bits having a second value of two or more values, the one or more parameters associated with the PDCP window after expiration of a time period (see ¶ [0042] - [0043], e.g., For a PDU data packet to be received, the PDCP entity may start a reordering timer, and when the reordering timer is expired, the PDCP entity ignores the “COUNT of the PDU data packet to be received” and updates the lower boundary of the receiving window. If the PDCP receives a data packet outside of the receiving window, the PDCP entity discards the data packet. The variable “RX_REORD” identifies a data packet COUNT that starts the reordering timer. The variable “RX_NEXT” identifies a data packet COUNT of the next PDU data packet to be received… Optionally, the adjustment parameter of the variable of the receiving window of the PDCP entity may include at least one of the followings: a window length of the receiving window, a boundary value of the receiving window, a HFN value in a header of a first data packet received by the PDCP entity, a SN value in the header of the first data packet, and a COUNT value in the header of the first data packet.).
Regarding claim 5, JIANG as combined with Vajapeyam teaches the limitations of Claim 4.
JIANG further teaches, wherein the time period corresponds to a duration of a configured timer associated with the set of bits or a portion a duration of a reordering timer associated with the PDCP window (see ¶ [0042], e.g., For a PDU data packet to be received, the PDCP entity may start a reordering timer, and when the reordering timer is expired, the PDCP entity ignores the “COUNT of the PDU data packet to be received” and updates the lower boundary of the receiving window. If the PDCP receives a data packet outside of the receiving window, the PDCP entity discards the data packet. The variable “RX_REORD” identifies a data packet COUNT that starts the reordering timer).
Regarding claim 6, JIANG as combined with Vajapeyam teaches the limitations of Claim 1.
JIANG further teaches, wherein the one or more parameters associated with a PDCP window are applied per radio bearer of a set of radio bearers configured at the UE (see ¶ [0159], e.g., According to the method for configuring a receiving window of a PDCP entity of the disclosure, the corresponding PDCP entities are established based on different MRBs, which provide bearers for the terminal device to receive the MBS information, which ensures stable implementation of updating the variable of the receiving window, and ensures the continuity and reliability of MBS data transmission; ¶ [0162], e.g., the network device configures the adjustment parameter of the variable of the receiving window of the PDCP entity of a particular bearer for the terminal device based on the dynamic adjustment of the terminal device.).
Regarding claim 7, JIANG as combined with Vajapeyam teaches the limitations of Claim 6.
JIANG further teaches, wherein the one or more parameters associated with the PDCP window are selected from a set of PDCP parameters configured per radio bearer of the set of radio bearers, and
wherein the set of PDCP parameters are indicated by one or more of radio resource control (RRC) signaling or a medium access control (MAC) control element (see ¶ [0057], e.g., For example, if the candidate lower boundary value of the receiving window carried in the indication information sent by the network device is set to 4, i.e., RX_DELIV=4, for sending through multicast, the network device can configure the PDCP entity of the MRB-1 for the terminal device via a RRC signaling. The RRC signaling carries the candidate lower boundary value of the receiving window of the PDCP entity. Thus, the terminal device can configure the lower boundary value of the receiving window of the PDCP entity to be 4, i.e., RX_DELIV=4, in which the MRB-1 can be an MBS bearer identifier, and the RRC signaling can be a RRC connection reconfiguration signaling.).
Regarding claim 8, JIANG as combined with Vajapeyam teaches the limitations of Claim 6.
JIANG further teaches, wherein the one or more parameters associated with the PDCP window are configured during configuration of each radio bearer, or are based on a service that is associated with each radio bearer (see Fig. 10, element S1001-S1004; ¶ [0144] – [0159], e.g., the terminal device may establish a PDCP entity to realize the reception of MBS sending information. According to the multicast bearer configuration information, the MRB is established, and the corresponding PDCP entity is established based on the MRB. … According to the method for configuring a receiving window of a PDCP entity of the disclosure, the corresponding PDCP entities are established based on different MRBs, which provide bearers for the terminal device to receive the MBS information, which ensures stable implementation of updating the variable of the receiving window, and ensures the continuity and reliability of MBS data transmission).
Regarding claim 11, JIANG as combined with Vajapeyam teaches the limitations of Claim 1.
JIANG further teaches, wherein the one or more processors are individually or collectively further operable to execute the code to cause the UE to: enable setting of the one or more parameters associated with the PDCP window based at least in part on one or more of an estimated block error rate of communications at the UE, a characteristic of a serving cell of the UE, a type of network used for communications at the UE, or a frequency band used for communications at the UE (see ¶ [0031] - [0033], e.g., It should be noted that the technical solutions of the embodiments of the disclosure can be used in various communication systems, such as, a long term evolution (LTE) system, a 5th generation (5G) mobile communication system, a 5G new radio (NR) system, or other future new mobile communication systems.).
Regarding claim 13, JIANG teaches a network entity, comprising: one or more memories storing processor-executable code; and one or more processors coupled with the one or more memories and individually or collectively operable to execute the code to cause the network entity to (see Fig. 1, e.g., element 101; Fig. 15, element 1500):
set one or more parameters associated with a packet data convergence protocol (PDCP) window for a user equipment (UE) (see ¶ [0093] - [0095], e.g., the network device may configure another integer for the header of the first PDCP data packet received by the PDCP entity. The integer may also be agreed upon by a pre-signed agreement as the second target value. The maximum allowable value of the PDCP SN value, the first sum, and the second target value may be added together to obtain the second sum… the SN value of the PDCP is set within the range of 0 to 7, the second target value is b, the header of the first PDCP data packet of the MRB received by the terminal device indicates that SN=1, a=−2 and b=1… the terminal device may obtain the second sum according to the maximum allowable value of the SN value, the first sum and the second target value by 7+1-2+1=7. Further, the second sum of 7 is determined as the adjusted candidate configuration value of the SN portion of the variable of the receiving window.),
and transmit a first PDCP PDU to the UE that comprises a set of bits, a first sequence number, and data, (see ¶ [0043], e.g., the adjustment parameter of the variable of the receiving window of the PDCP entity may include at least one of the followings: a window length of the receiving window, a boundary value of the receiving window, a HFN value in a header of a first data packet received by the PDCP entity, a SN value in the header of the first data packet, and a COUNT value in the header of the first data packet; see ¶ [0106] - [0107], e.g., At step S801, a sequence number carried in a header of a first PDCP data packet received by the PDCP entity is determined as an adjustment parameter.);
wherein a value of the set of bits indicates the one or more parameters associated with the PDCP window (see ¶ [0093] - [0095], e.g., the network device may configure another integer for the header of the first PDCP data packet received by the PDCP entity. The integer may also be agreed upon by a pre-signed agreement as the second target value. The maximum allowable value of the PDCP SN value, the first sum, and the second target value may be added together to obtain the second sum… the second sum of 7 is determined as the adjusted candidate configuration value of the SN portion of the variable of the receiving window.);
based at least in part on the first Sequence number being within the PDCP window for PDCP PDU reordering (see ¶ [0041] - [0042], e.g., The receiving entity of the PDCP can reorder received PDU data packets in an order of PDCP sequence number (denoted as COUNT). The reordered PDCP data packets can be delivered to a higher-level protocol entity in sequence according to the COUNT… For a PDU data packet to be received, the PDCP entity may start a reordering timer, and when the reordering timer is expired, the PDCP entity ignores the “COUNT of the PDU data packet to be received” and updates the lower boundary of the receiving window… As illustrated in FIG. 3, initial values of the variables “RX_DELIV” and “RX_NEXT” of the PDCP entity are 0. When a PDU data packet numbered “1” is received, it means that a PDU data packet numbered “0” is not received. The PDCP entity updates the “RX_NEXT” to “2”. In response to the need to start the reordering timer, the “RX_REORD” is set to “2”. When a PDU data packet numbered “2” is received, the “RX_NEXT” is updated to “3”.).
however, it does not explicitly teach wherein the UE is to store the first PDCP PDU in a buffer with one or more other PDCP PDUs.
Vajapeyam teaches, wherein the UE is to store the first PDCP PDU in a buffer with one or more other PDCP PDUs (see ¶ [0048] - [0050], e.g., The PDCP layers 210 may perform reordering by establishing a reordering window that defines a range of PDCP SNs that are eligible for reordering. If a PDCP PDU is received from a MAC layer 215 that contains SDUs with PDCP SNs outside of the reordering window, the respective PDCP layers 210 may discard the PDU. The PDCP layers 210 may then process non-discarded PDUs and store associated SDUs in a reordering buffer… the reordering window may be one-half of available range of PDCP SNs, and PDCP PDUs that fall outside of the range may be discarded, with received PDCP PDUs within the range being stored (e.g., in a packet buffer) and processed. The reordering window, as noted above, may be anchored at the SN that was submitted to the respective upper layers, and PDUs received that are outside the window may be discarded while PDUs within the window may be stored and processed.).
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 receiving of a first packet data convergence protocol (PDCP) protocol data unit (PDU) of JIANG to incorporate the teachings of Vajapeyam to include wherein the PDCP window indicates a range of sequence numbers that are to be stored at the UE for reordering of received PDCP PDUs; and store the first PDCP PDU in a buffer with one or more other PDCP PDUs. Doing so would facilitate in achieving managing SRBs to provide enhanced reception as suggested by Vajapeyam (see ¶ [0061], e.g., In some examples, the reordering timer for SDUs associated with an SRB may be set to infinity (or a timer limitation for an SRB may be otherwise disabled), thus helping to ensure that PDCP PDUs are received in the reordering buffer prior to pushing the reordering window.).
Regarding claim 14, JIANG as combined with Vajapeyam teaches the limitations of Claim 13.
JIANG further teaches, wherein, to set the one or more parameters associated with the PDCP window, the one or more processors are individually or collectively operable to execute the code to cause the network entity to: set a lower bound of the range of sequence numbers as the first sequence number (see ¶ [0061], e.g., the adjustment of the lower boundary value of the receiving window can be realized based on the acquired candidate lower boundary value or the candidate upper boundary value and the window length sent by the network device, ¶ [0111], e.g., a sequence number indicated in the header of the first PDCP data packet is 4, a SN portion of the lower boundary value RX_DELIV of the receiving window is configured to be 4,).
Regarding claim 15, JIANG as combined with Vajapeyam teaches the limitations of Claim 13.
JIANG further teaches, wherein a first value of the set of bits indicates that the UE is to apply the one or more parameters associated with the PDCP window upon receipt of the set of bits (see ¶ [0093] - [0114], e.g., Optionally, a third sum of the sequence number carried in the header and a third target value is determined, and the lower boundary value of the receiving window and/or the sequence number of the next PDCP SDU to be received is configured to be the third sum… the sequence number indicated in the header of the first PDCP data packet is set to 4, and the third target value c is 1, thus the third sum is 4+1=5. Further, the SN portion of the lower boundary value RX_DELIV of the receiving window can be configured as 5, or the SN portion of the sequence number RX_NEXT of the next PDCP SDU to be received can be configured as 5).
Regarding claim 16, JIANG as combined with Vajapeyam teaches the limitations of Claim 13.
JIANG further teaches, wherein the one or more processors are individually or collectively further operable to execute the code to cause the UE to:
apply, based at least in part on the set of bits having a second value of two or more values, the one or more parameters associated with the PDCP window after expiration of a time period (see ¶ [0042] - [0043], e.g., For a PDU data packet to be received, the PDCP entity may start a reordering timer, and when the reordering timer is expired, the PDCP entity ignores the “COUNT of the PDU data packet to be received” and updates the lower boundary of the receiving window. If the PDCP receives a data packet outside of the receiving window, the PDCP entity discards the data packet. The variable “RX_REORD” identifies a data packet COUNT that starts the reordering timer. The variable “RX_NEXT” identifies a data packet COUNT of the next PDU data packet to be received… Optionally, the adjustment parameter of the variable of the receiving window of the PDCP entity may include at least one of the followings: a window length of the receiving window, a boundary value of the receiving window, a HFN value in a header of a first data packet received by the PDCP entity, a SN value in the header of the first data packet, and a COUNT value in the header of the first data packet.).
Regarding claim 17, JIANG as combined with Vajapeyam teaches the limitations of Claim 1.
JIANG further teaches, wherein the one or more parameters associated with a PDCP window are applied per radio bearer of a set of radio bearers configured at the UE (see ¶ [0159], e.g., According to the method for configuring a receiving window of a PDCP entity of the disclosure, the corresponding PDCP entities are established based on different MRBs, which provide bearers for the terminal device to receive the MBS information, which ensures stable implementation of updating the variable of the receiving window, and ensures the continuity and reliability of MBS data transmission; ¶ [0162], e.g., the network device configures the adjustment parameter of the variable of the receiving window of the PDCP entity of a particular bearer for the terminal device based on the dynamic adjustment of the terminal device.).
Regarding claim 18, JIANG as combined with Vajapeyam teaches the limitations of Claim 1.
JIANG further teaches, wherein the one or more processors are individually or collectively further operable to execute the code to cause the network entity to: configure the UE to enable modification one or more parameters associated with the PDCP window based at least in part on one or more of an estimated block error rate of communications at the UE, a characteristic of a serving cell of the UE, a type of network used for communications at the UE, or a frequency band used for communications at the UE (see ¶ [0031] - [0033], e.g., It should be noted that the technical solutions of the embodiments of the disclosure can be used in various communication systems, such as, a long term evolution (LTE) system, a 5th generation (5G) mobile communication system, a 5G new radio (NR) system, or other future new mobile communication systems.).
Claim(s) 9-10 are rejected under 35 U.S.C. 103 as being unpatentable over JIANG in view of Vajapeyam and in further view of Tsai et al., US 20260197707 A1, (hereinafter Tsai).
Regarding claim 9, JIANG as combined with Vajapeyam teaches the limitations of Claim 1.
JIANG as improved by Vajapeyam does not teach but Tsai teaches, wherein the value of the set of bits is based at least in part on traffic characteristics associated with the first PDCP PDU (see ¶ [0034], e.g., The disclosed mechanism may be performed when certain criteria are met, for example, in a wireless device, a base station, a radio environment, a network, a combination of the above, and/or the like. Example criteria may be based, at least in part, on for example, wireless device or network node configurations, traffic load, initial system set up, packet sizes, traffic characteristics, a combination of the above, and/or the like.).
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 receiving of a first packet data convergence protocol (PDCP) protocol data unit (PDU) of JIANG as combined with Vajapeyam to incorporate the teachings of Tsai to include wherein the value of the set of bits is based at least in part on traffic characteristics associated with the first PDCP PDU. Doing so would facilitate in achieving selectively implement protocols as suggested by Tsai (see ¶ [0114], e.g., When the one or more criteria are met, various example embodiments may be applied. Therefore, it may be possible to implement example embodiments that selectively implement disclosed protocols.).
Regarding claim 10, JIANG as combined with Vajapeyam teaches the limitations of Claim 1.
JIANG as improved by Vajapeyam does not teach but Tsai teaches, wherein the value of the set of bits is based at least in part on whether the first PDCP PDU includes data from a first data flow of two or more data flows (see ¶ [0070] - [0071], e.g., An uplink data flow through the NR user plane protocol stack may be similar to the downlink data flow depicted in FIG. 4A. The downlink data flow of FIG. 4A begins when SDAP 225 receives the three IP packets from one or more QoS flows and maps the three packets to radio bearers. In FIG. 4A, the SDAP 225 maps IP packets n and n+1 to a first radio bearer 402 and maps IP packet m to a second radio bearer 404).
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 receiving of a first packet data convergence protocol (PDCP) protocol data unit (PDU) of JIANG as combined with Vajapeyam to incorporate the teachings of Tsai to include wherein the value of the set of bits is based at least in part on traffic characteristics associated with the first PDCP PDU. Doing so would facilitate in achieving mapping IP packets from one or more QoS flows to radio bearers as suggested by Tsai (see ¶ [0071], e.g., The downlink data flow of FIG. 4A begins when SDAP 225 receives the three IP packets from one or more QoS flows and maps the three packets to radio bearers).
Claim(s) 12 is rejected under 35 U.S.C. 103 as being unpatentable over JIANG in view of Vajapeyam and in further view of ITABA, US 20240163013 A1, (hereinafter ITABA,).
Regarding claim 12, JIANG as combined with Vajapeyam teaches the limitations of Claim 1.
JIANG as improved by Vajapeyam does not teach but ITABA teaches, wherein the set of bits are included in a subset of bits of the PDCP PDU subsequent to a data or control indication bit and prior to the first sequence number in the PDCP PDU (see Fig 5-6, element 501, 601, ¶ [0048] - [0049], e.g., FIG. 5, in the PDU (Protocol Data Unit) where the PDCP SN value is expressed by 18-bits, out of 5 bits of the reserve bits 502, 1-bit is used for bit 503 for synchronization instruction (Sync. Ind.). Also, the lower-order 4 bits of the HFN value held by the transmitting end are set to the remaining 4 bits 504 (bits 3 to 6 in the PDU).).
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 receiving of a first packet data convergence protocol (PDCP) protocol data unit (PDU) of JIANG as combined with Vajapeyam to incorporate the teachings of ITABA to include wherein the set of bits are included in a subset of bits of the PDCP PDU subsequent to a data or control indication bit and prior to the first sequence number in the PDCP PDU. Doing so would facilitate in achieving resynchronization of the PDCP SN as suggested by ITABA (see ¶ [0015], e.g., According to an aspect of the present disclosure, it is possible to shorten the time period during which data communication cannot be properly performed. Also see ¶ [0050], e.g., The larger the number of bits indicating at a least part of the HFN value included in the transmitted data, the larger the window gap of the PDCP that can be resynchronized. When the lower-order 2 bits of the HFN value are included as in FIG. 6, resynchronization up to three cycles of the PDCP SN can be performed. When the lower-order 4 bits of the HFN value are included as in FIG. 5, resynchronization up to 15 cycles of the PDCP SN can be performed.).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 20190373455 A1, issued to Wang et al., teaches a method to reports packet data control protocol (PDCP) status and PDCP resets in a wireless communication.
US 12526691 B2, issued to Kim, teaches header compression or decompression procedure in a next-generation mobile communication system.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to POONAM SHARMA whose telephone number is (571)272-6579. The examiner can normally be reached Monday thru 8:30-5:30 pm, ET.
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, Kevin Bates can be reached at (571) 272-3980. 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.
/POONAM SHARMA/Examiner, Art Unit 2472
/KEVIN T BATES/Supervisory Patent Examiner, Art Unit 2472
Prosecution Insights