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 .
Response to Amendment
Applicant’s submission filed on 04/01/2026 has been entered. Claims 1-20 are pending.
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-5, 10-11, 13-15, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Höhne et al. (US 2025/0024320), hereinafter “Hohne”, in view of Attar et al. (US 7,088,701), hereinafter “Attar”, and further in view of Lu (US 2022/0151015), hereinafter “Lu”.
Regarding claims 1, 11, Hohne teaches:
A method implemented by a wireless transmit/receive unit (WTRU), or a wireless transmit/receive unit (WTRU) (see Hohne, Fig. 15B, par. [0135]: FIG. 15B illustrates an example of an apparatus 20 according to another embodiment. In an embodiment, apparatus 20 may be a node or element in a communications network or associated with such a network, such as a UE, communication node, mobile equipment (ME), mobile station, mobile device, stationary device, IoT device, or other device), the method or the WTRU comprising:
a processor, memory, and a transceiver which are configured (see Hohne, Fig. 15B, par. [0137]: apparatus 20 may include or be coupled to a processor 22, and see Hohne, par. [0139]: Apparatus 20 may further include or be coupled to a memory 24, and see Hohne, par. [0141]: Apparatus 20 may further include a transceiver 28, and see Hohne, par. [0144]: apparatus 20 may be controlled by memory 24 and processor 22 to perform the functions associated with any of the embodiments described herein, such as one or more of the operations illustrated in, or described with respect to, FIG. 14B or any other method described herein) to:
receiving information indicating a Network Coding (NC) configuration including any of a NC process success release time duration (optional limitation) and/or one or more NC process parameters (see Hohne, Fig. 13, pars. [0105-0106]: the transmitter and receiver may be provided, at 1 and 2 respectively, with a configuration of network coding functionality in PDCP entity. The configuration may include the DRB to use if any, lower layer (RLC, MAC) configuration if second PDCP entity is used, and/or formula to link the original to coded PDUs. Depending on the solution, the formula may be expressed by (const(1), const(2)), or (n, const(1) . . . const(n)), as discussed above. For instance, according to the example of FIG. 13, the receiver may obtain, at 2, the configuration with coded PDU SN mapping to original PDU SN and/or DRB/PDCP configuration (single or dual). In case of error in the original PDCP PDU, the receiver may use SN of original PDU and the linking formula to determine which original and coded PDUs to use to reconstruct the missing original; in this case, receiving a configuration which includes formula to link the original to coded PDUs corresponds to a NC configuration including one or more NC process parameters);
receiving a first protocol data unit (PDU) of a NC PDU set (see Hohne, Fig. 6, par. [0086]: a receiving side of the PDCP entity 620 may receive coded PDUs from an associated network coding PDCP entity);
associating the first PDU with a NC process associated with the NC PDU set based on header information of the first PDU (see Hohne, par. [0079]: the original PDUs may be linked to the network coded PDUs via a formula that allows to derive the original PDU SN from the network coded PDU SN. Corresponding functionality is introduced into the PDCP entity. In an embodiment, the formula allows to introduce a SN offset between original and coded PDUs, and see Hohne, par. [0044]: the sequence numbers SN1 and SN2 are carried in the network coded packet data convergence protocol (PDCP) protocol data units (PDUs) headers; in this case, original PDUs are linked to network coded PDUs (corresponding to associating the first PDU with a NC process) using PDU SN which may be carried in headers);
successfully decoding the NC process using the first PDU and the one or more NC process parameters (see Hohne, Fig. 7, par. [0087]: the receiving PDCP entity 620 may communicate with the network decoding PDCP entity 720 by primitives such as request coded PDU (SN) and inform RX_DELIVERY counter. Similarly, in an embodiment, the network decoding PDCP entity 720 may perform the network decoding in which case the primitives may include provide original PDUs and inform RX_DELIVERY);
receiving a second PDU of the NC PDU set (see Hohne, Fig. 6, par. [0086]: a receiving side of the PDCP entity 620 may receive coded PDUs from an associated network coding PDCP entity);
However, Hohne does not teach:
discarding the second PDU based on the second PDU being received within the NC process success release time duration from a time of the successful decoding of the NC process; and
releasing the NC process based on lapsing of the NC process success release time duration from a time of the successful decoding of the NC process.
Attar, in the same field of endeavor, teaches:
discarding the second PDU based on the second PDU being received within the NC process success release time duration from a time of the successful decoding of the NC process (see Attar, col. 8, lines 46-53: If the noise characteristics of the forward link channel improve after the first slot is sent, the destination subscriber station 102b may be able to successfully decode the packet before receiving the maximum number of time slots. Once the destination subscriber station 102b successfully decodes the packet, subsequent forward link time slots containing data for the decoded packet are discarded; in this case, after successfully decoding the packet, subsequent packets are discarded. Discarding is performed for subsequent time slots before receiving the maximum number of time slots, corresponding to within the NC process success release time duration from a time of the successful decoding);
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 or WTRU of Hohne with the discarding of Attar 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 by minimizing unnecessary retransmissions of data (see Attar, col. 3, lines 7-21).
However, the combination of Hohne in view of Attar does not teach:
releasing the NC process based on lapsing of the NC process success release time duration from a time of the successful decoding of the NC process.
Lu, in the same field of endeavor, teaches:
releasing the NC process based on lapsing of the NC process success release time duration from a time of the successful decoding of the NC process (see Lu, Fig. 21, par. [0320]: when TB1 is successfully decoded, the terminal stops the discontinuous reception downlink retransmission timer; when the decoding TB1 fails, the terminal continues to run the discontinuous reception downlink retransmission timer (until the timer expires or a retransmission scheduling of the downlink data is received). After the decoding for the retransmission of TB1 is successful, the UE stops the drx-RetransmissionTimerDL at the time T45. Thereafter, the network side device schedules the second retransmission of TB2. Since the drx-onDurationTimer, the drx-InactivityTimer and the drx-RetransmissionTimerDL are all not running at this time, the UE is in the DRX dormant state, and the UE does not monitor the PDCCH indicating the second retransmission scheduling of TB2, and does not receive the corresponding PDSCH. At the time T12 when the first DRX cycle ends and the second DRX cycle begins, the UE starts the drx-onDurationTimer; in this case, ending a first reception cycle and starting a second reception cycle after successfully decoding and when the first reception cycle time (i.e. NC process success release time duration) ends corresponds to releasing the NC process based on lapsing of the NC process success release time duration from a time of successful decoding).
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 or WTRU of the combination of Hohne in view of Attar with the releasing the NC process of Lu 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 power consumption of the terminal (see Lu, pars. [0043-0044]).
Regarding claims 3, 13, the combination of Hohne in view of Attar, and further in view of Lu, teaches the method or WTRU. Hohne further teaches:
further comprising:
before receiving the first PDU, receiving one or more third PDUs of the NC PDU set (see Hohne, Fig. 6, par. [0086]: a receiving side of the PDCP entity 620 may receive coded PDUs from an associated network coding PDCP entity); and
initiating the NC process associated with the NC PDU set based on header information of the one or more third PDUs (see Hohne, par. [0079]: the original PDUs may be linked to the network coded PDUs via a formula that allows to derive the original PDU SN from the network coded PDU SN. Corresponding functionality is introduced into the PDCP entity. In an embodiment, the formula allows to introduce a SN offset between original and coded PDUs, and see Hohne, par. [0044]: the sequence numbers SN1 and SN2 are carried in the network coded packet data convergence protocol (PDCP) protocol data units (PDUs) headers; in this case, linking original PDUs to network coded PDUs corresponds to initiating the NC process and is done using sequence numbers which may be in headers (i.e. based on header information)),
wherein the successful decoding of the NC process uses, the first PDU, the one or more third PDUs, and the one or more NC process parameters (see Hohne, Fig. 7, par. [0087]: the receiving PDCP entity 620 may communicate with the network decoding PDCP entity 720 by primitives such as request coded PDU (SN) and inform RX_DELIVERY counter. Similarly, in an embodiment, the network decoding PDCP entity 720 may perform the network decoding in which case the primitives may include provide original PDUs and inform RX_DELIVERY; in this case, decoding is done using PDUs and sequence numbers (i.e. process parameters)).
Regarding claims 4, 14, the combination of Hohne in view of Attar, and further in view of Lu, teaches the method or WRTU. Hohne further teaches:
wherein the associating the first PDU with the NC process associated with the NC PDU set includes initiating the NC process associated with the NC PDU set based on header information of the first PDU (see Hohne, par. [0079]: the original PDUs may be linked to the network coded PDUs via a formula that allows to derive the original PDU SN from the network coded PDU SN. Corresponding functionality is introduced into the PDCP entity. In an embodiment, the formula allows to introduce a SN offset between original and coded PDUs, and see Hohne, par. [0044]: the sequence numbers SN1 and SN2 are carried in the network coded packet data convergence protocol (PDCP) protocol data units (PDUs) headers; in this case, linking original PDUs to network coded PDUs corresponds to initiating the NC process and is done using sequence numbers which may be in headers (i.e. based on header information)).
Regarding claims 5, 15, the combination of Hohne in view of Attar, and further in view of Lu, teaches the method or WRTU. Hohne further teaches:
wherein the header information of the first PDU includes a packet data convergence protocol (PDCP) sub-header including information indicating a NC PDU set sequence number and/or an order sequence number (see Hohne, Fig. 13, pars. [0105-0106]: the transmitter and receiver may be provided, at 1 and 2 respectively, with a configuration of network coding functionality in PDCP entity. The configuration may include the DRB to use if any, lower layer (RLC, MAC) configuration if second PDCP entity is used, and/or formula to link the original to coded PDUs. Depending on the solution, the formula may be expressed by (const(1), const(2)), or (n, const(1) . . . const(n)), as discussed above. For instance, according to the example of FIG. 13, the receiver may obtain, at 2, the configuration with coded PDU SN mapping to original PDU SN and/or DRB/PDCP configuration (single or dual). In case of error in the original PDCP PDU, the receiver may use SN of original PDU and the linking formula to determine which original and coded PDUs to use to reconstruct the missing original, and see Hohne, par. [0044]: the sequence numbers SN1 and SN2 are carried in the network coded packet data convergence protocol (PDCP) protocol data units (PDUs) headers; in this case, the header information may be PDCP headers which include sequence numbers), and
wherein the one or more NC process parameters include a range of NC PDU set sequence numbers corresponding to the NC PDU set (see Hohne, Fig. 13, pars. [0105-0106]: the transmitter and receiver may be provided, at 1 and 2 respectively, with a configuration of network coding functionality in PDCP entity. The configuration may include the DRB to use if any, lower layer (RLC, MAC) configuration if second PDCP entity is used, and/or formula to link the original to coded PDUs. Depending on the solution, the formula may be expressed by (const(1), const(2)), or (n, const(1) . . . const(n)), as discussed above. For instance, according to the example of FIG. 13, the receiver may obtain, at 2, the configuration with coded PDU SN mapping to original PDU SN and/or DRB/PDCP configuration (single or dual). In case of error in the original PDCP PDU, the receiver may use SN of original PDU and the linking formula to determine which original and coded PDUs to use to reconstruct the missing original; in this case, the headers may include a plurality (i.e. a range) of sequence numbers).
Regarding claims 10, 20, the combination of Hohne in view of Attar, and further in view of Lu, teaches the method or WRTU. Hohne further teaches:
wherein the NC configuration information includes information associated with a radio bearer and/or a packet data convergence protocol (PDCP) entity (see Hohne, Fig. 13, pars. [0105-0106]: the transmitter and receiver may be provided, at 1 and 2 respectively, with a configuration of network coding functionality in PDCP entity. The configuration may include the DRB to use if any, lower layer (RLC, MAC) configuration if second PDCP entity is used, and/or formula to link the original to coded PDUs. Depending on the solution, the formula may be expressed by (const(1), const(2)), or (n, const(1) . . . const(n)), as discussed above. For instance, according to the example of FIG. 13, the receiver may obtain, at 2, the configuration with coded PDU SN mapping to original PDU SN and/or DRB/PDCP configuration (single or dual). In case of error in the original PDCP PDU, the receiver may use SN of original PDU and the linking formula to determine which original and coded PDUs to use to reconstruct the missing original; in this case, the configuration includes DRB information and PDCP sequence number information for linking (corresponding to information associated with a PDCP entity)), and
wherein the first PDU is received via the radio bearer and/or the header information of the first PDU indicates the PDCP entity (see Hohne, par. [0079]: the original PDUs may be linked to the network coded PDUs via a formula that allows to derive the original PDU SN from the network coded PDU SN. Corresponding functionality is introduced into the PDCP entity. In an embodiment, the formula allows to introduce a SN offset between original and coded PDUs, and see Hohne, par. [0044]: the sequence numbers SN1 and SN2 are carried in the network coded packet data convergence protocol (PDCP) protocol data units (PDUs) headers, and see Hohne, Fig. 13, pars. [0105-0106]: the transmitter and receiver may be provided, at 1 and 2 respectively, with a configuration of network coding functionality in PDCP entity. The configuration may include the DRB to use if any, lower layer (RLC, MAC) configuration if second PDCP entity is used, and/or formula to link the original to coded PDUs. Depending on the solution, the formula may be expressed by (const(1), const(2)), or (n, const(1) . . . const(n)), as discussed above. For instance, according to the example of FIG. 13, the receiver may obtain, at 2, the configuration with coded PDU SN mapping to original PDU SN and/or DRB/PDCP configuration (single or dual). In case of error in the original PDCP PDU, the receiver may use SN of original PDU and the linking formula to determine which original and coded PDUs to use to reconstruct the missing original; in this case, header information may include sequence numbers regarding the PDCP entity).
Claims 2 and 12 are rejected under 35 U.S.C. 103 as being unpatentable over Hohne in view of Attar, and further in view of Lu, as applied to claims 1, 3-5, 10-11, 13-15, and 20 above, and further in view of Liu et al. (US 2024/0267791), hereinafter “Liu ‘791”.
Regarding claims 2, 12, the combination of Hohne in view of Attar, and further in view of Lu, teaches the method or WRTU.
However, the combination of Hohne in view of Attar, and further in view of Lu, does not teach:
wherein the successful decoding of the NC process includes obtaining one or more service data units (SDUs) encoded by the NC PDU set.
Liu ‘791, in the same field of endeavor, teaches:
wherein the successful decoding of the NC process includes obtaining one or more service data units (SDUs) encoded by the NC PDU set (see Liu ‘791, Fig. 7B, par. [0099]: the UE 120 may receive the initial transmission and may attempt to decode the initial transmission. For example, the UE 120 may identify packets from the first set of encoded packets that were successfully received by the UE 120. The UE 120 may identify RLC SDUs, encoded packets, and/or RLC PDUs that were not successfully received by the UE 120 (e.g., based at least in part on information included in headers of the successfully received encoded packets). The UE 120 may attempt to decode the encoded packets to obtain a set of source packets (e.g., associated with an RLC SDU). The UE 120 may attempt to reassemble the RLC SDU from the decoded source packets).
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 decoding of the combination of Hohne in view of Attar, and further in view of Lu, with the decoding including obtaining SDUs of Liu ‘791 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 reliability and efficiency (see Liu, ‘791, par. [0086]).
Claims 6, 8-9, 16, and 18-19 are rejected under 35 U.S.C. 103 as being unpatentable over Hohne in view of Attar, and further in view of Lu, as applied to claims 1, 3-5, 10-11, 13-15, and 20 above, and further in view of Liu et al. (WO 2023/005909), published 02, February, 2023, hereinafter “Liu ‘909” (see “WO_2023005909_Translation.pdf” for citations).
Regarding claims 6, 16, the combination of Hohne in view of Attar, and further in view of Lu, teaches the method or WRTU.
However, the combination of Hohne in view of Attar, and further in view of Lu, does not teach:
further comprising: transmitting a PDU discard indicator based on the discarding of the second PDU.
Liu ‘909, in the same field of endeavor, teaches:
further comprising: transmitting a PDU discard indicator based on the discarding of the second PDU (see Liu ‘909, Fig. 13a, par. [0250]: After the gNB-CU performs network coding on one or more PDCP PDUs to generate coded packets, it can send the generated coded packets to the gNB-DU. If the gNB-CU has sent a coded packet to the gNB-DU and the timer associated with the coded packet on the gNB-CU has expired, the gNB-CU may send an indication message to the gNB-DU to instruct the gNB-DU to discard the coded 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 the combination of Hohne in view of Attar, and further in view of Lu, with the transmitting a discard indicator of Liu ‘909 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 the waste of resource and improving efficiency (see Liu ‘909, par. [0007]).
Regarding claims 8, 18, the combination of Hohne in view of Attar, and further in view of Lu, teaches the method or WRTU.
However, the combination of Hohne in view of Attar, and further in view of Lu, does not teach:
wherein the releasing of the NC process includes discarding any received PDUs associated with the NC process.
Liu ‘909, in the same field of endeavor, teaches:
wherein the releasing of the NC process includes discarding any received PDUs associated with the NC process (see Liu ‘909, par. [0195]: The PDCP layer of the communication device receives multiple PDCP SDUs from an upper layer (such as an SDAP layer), and cancels/disables a mechanism for associating each PDCP SDU with a discardTimer, or in other words, disables a function for associating each PDCP SDU with a discardTimer. The PDCP layer of the communication device determines a group of original data to be processed by the network coding function, for example: taking the received multiple PDCP SDUs as a group of original data, or taking the first N PDCP SDUs of the received multiple PDCP SDUs as a group of original data, N is a positive integer, and associating a timer for the group of PDCP SDUs (i.e., the group of original data). The PDCP layer of the communication device performs network coding processing on the group of PDCP SDUs together/jointly/commonly to generate multiple coding packets. The specific processing of the network coding function can be referred to as shown in the aforementioned Figure 5b, which will not be repeated here. If the timer associated with the group of PDCP SDUs (i.e., the group of original data) times out, indicating that the QoS of the group of PDCP SDUs has expired, the PDCP layer of the communication device discards the group of PDCP SDUs (i.e., the group of original data) and all coded packets generated by performing network coding function processing on the group of PDCP SDUs (i.e., the group of original data), and see Liu ‘909, Fig. 8, par. [0199]: after receiving PDCP SDU0, PDCP SDU1 and PDCP SDU2, the sending PDCP entity associates the three PDCP SDUs as a group of original data with a discardTimer. Then, the group of original data (ie, PDCP SDU0 to PDCP SDU2) is processed by the network coding function to generate coding packets, and a PDCP header is added to each coding packet to generate a PDCP PDU. Therefore, once the discardTimer associated with a group of original data (i.e., PDCP SDU0 to PDCP SDU2) times out, the sending PDCP entity will discard PDCP SDU0, PDCP SDU1, PDCP SDU2, and the corresponding coded packets (PDCP SDU0,PDCP SDU1, PDCP SDU2 respectively), as well as the corresponding PDCP PDU0, PDCP PDU1, PDCP PDU2 and PDCP PDU3; in this case, when disabling a mechanism for associating packets with a timer (i.e. releasing a NC process), all packets are discarded).
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 the combination of Hohne in view of Attar, and further in view of Lu, with the discarding when releasing of Liu ‘909 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 the waste of resource and improving efficiency (see Liu ‘909, par. [0007]).
Regarding claims 9, 19, the combination of Hohne in view of Attar, and further in view of Lu, teaches the method or WRTU.
However, the combination of Hohne in view of Attar, and further in view of Lu, does not teach:
wherein the one or more NC process parameters include coding coefficient information, and
wherein the successful decoding of the NC process uses a subset of the coding coefficient information indicated by the first PDU.
Liu ‘909, in the same field of endeavor, further teaches:
wherein the one or more NC process parameters include coding coefficient information (see Liu ‘909, par. [0127]: the content of the package body of the system package is consistent with the content of the original data package(that is, the system package is composed of the encoded packet header and the original data package). The system package can be obtained by directly adding the header to the original data package, or by encoding it with the aforementioned encoder and then adding the header. The coding coefficient of the system package is a unit vector. The coding coefficients of the redundant packets are non-unit vectors), and
wherein the successful decoding of the NC process uses a subset of the coding coefficient information indicated by the first PDU (see Liu ‘909, Fig. 5A, par. [0148]: the receiving end receives at least K data packets, and the K data packets are linearly independent, that is, the rank of the corresponding coefficient matrix is equal to K. In this way, the receiving end can recover K original data packets through decoding, and then recover the corresponding PDU; in this case, decoding is performed using a coefficient matrix).
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 the combination of Hohne in view of Attar, and further in view of Lu, with the coding coefficient information of Liu ‘909 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 the waste of resource and improving efficiency (see Liu ‘909, par. [0007]).
Claims 7 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Hohne in view of Attar, and further in view of Lu, as applied to claims 1, 3-5, 10-11, 13-15, and 20 above, and further in view of Le Bars et al. (US 2023/0188249), hereinafter “Le Bars”.
Regarding claims 7, 17, the combination of Hohne in view of Attar, and further in view of Lu, teaches the method or WRTU.
However, the combination of Hohne in view of Attar, and further in view of Lu, does not teach:
further comprising: transmitting a NC process release indicator based on the releasing of the NC process.
Le Bars, in the same field of endeavor, teaches:
further comprising: transmitting a NC process release indicator based on the releasing of the NC process (see Le Bars, Fig. 26, par. [0360]: At step 2601, the Base Station sends an RRC Release message. The first effect of this message is to suspend all message exchanges on the data bearers, and hence, it will automatically terminate Network Coding Operations. However, The Base Station may decide to send an RRC Release Message with an indication of suspension of Network Coding, in order to not lose the current configuration).
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 the combination of Hohne in view of Attar, and further in view of Lu, with the transmission of a release indicator of Le Bars 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 the capability to react quickly to conditions changes (see Le Bars, pars. [0007-0008]).
Response to Arguments
Applicant’s arguments, see Applicant's Remarks, pages 6-, filed 04/01, with respect to the rejection(s) of claim(s) 1 and 11 under 35 USC § 103 have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of Hohne in view of Attar, and further in view of Lu, under 35 U.S.C. 103.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure:
Lee (US 2019/0349842) teaches a method and a device for processing system information including receiving repetitions of system information for scheduling other SIBs in a first period; receiving an indicator indicating the system information for scheduling other SIBs is not changed in a second period followed by the first period in a specific time of the first period; and processing the system information for scheduling other SIBs based on the repetitions of the system information accumulated from the specific time of the first period if the system information for scheduling other SIBs is not successfully decoded at the time of end of the first period.
Lou et al. (US 2022/0255693) teaches methods and apparatuses for feedback based on midamble adaptation including a STA generating a physical layer convergence procedure (PLCP) protocol data unit (PPDU) that includes at least one midamble within a data portion of the PPDU.
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