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 statements (IDSs) submitted on January 23, 2025 are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statements are being considered by the examiner.
Applicant should note that the large number of references in the attached IDSs have been considered by the examiner in the same manner as other documents in Office search files are considered by the examiner while conducting a search of the prior art in a proper field of search. See MPEP 609.05(b). Applicant is invited to point out any particular reference(s) in the IDS that they believe may be of particular relevance to the instant claimed invention in response to this Office Action. It is desirable to avoid the submission of long lists of documents if it can be avoided. If a long list is submitted, highlight those documents which have been specifically brought to applicant’s attention and/or are known to be of most significance. See Penn Yan Boats, Inc. v. Sea Lark Boats, Inc., 359 F. Supp. 948, 175 USPQ 260 (S.D. Fla. 1972), aff ’d, 479 F.2d 1338, 178 USPQ 577 (5th Cir. 1973), cert. denied, 414 U.S. 874 (1974). But cf. Molins PLC v. Textron Inc., 48 F.3d 1172, 33 USPQ2d 1823 (Fed. Cir. 1995).
Claim Objections
Claims 8 and 12 objected to because of the following informalities:
In Claim 8: The phrase “… to include field which indicates presence of the range field” is grammatically incorrect due to missing articles. It is suggested to amend this phrase to “to include a field which indicates the presence of the range field” or similar.
In Claim 12: There is a missing conjunction “and” between the first and second clauses of the claim. Specifically, the semi-colon at the end of the limitation “…a transmitter node of the telecommunications system;” should be followed by the conjunction “and” to properly connect it to the subsequent paragraph beginning with “processor circuitry configured to determine…”.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claim(s) 12-15 rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor, or for pre-AIA the applicant regards as the invention.
Regarding Claim 12, the phrase “to process the packet accordingly” is vague and indefinite. There is no antecedent basis for the term “the packet” in Claim 12. The claim previously introduces “an obsolete packet,” but does not introduce “a packet” that is to be processed. For proper antecedent basis, the relationship between “an obsolete packet” and “the packet” must be clearly defined.
The functional term “accordingly” is vague and indefinite. It fails to define the specific processing steps or actions the processor circuitry takes (e.g., discarding the packet, releasing a buffer, advancing a window), rendering the scope of the claim unclear.
Regarding Claim 13, similar to claim 12, the phrase “to process the plural number of packets accordingly” is vague and indefinite. There is no antecedent basis for the term “the plural number of packets” in Claim 13. The claim previously introduces “a plural number of obsolete packets,” but does not introduce “a plural number of packets” that is to be processed. For proper antecedent basis, the relationship between “a plural number of obsolete packets” and “the plural number of packets” must be clearly defined.
Regarding Claim 14, the phrase “an indication of a radio link control (RLC) base sequence number which is reported as being an obsolete packet” is indefinite. A sequence number is a numerical identifier, not a packet itself. By stating that the sequence number is the obsolete packet, the claim contains a logical inconsistency that renders its scope ambiguous. It appears the applicant intends to claim a sequence number corresponding to a packet that is reported as obsolete.
Regarding Claims 13-15, these claims depend from Claim 12, thus carry the same indefiniteness issues as discussed above, and therefore are rejected on the same grounds discussed above.
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.
Claim(s) 1 and 4-15 rejected under 35 U.S.C. 103 as being unpatentable over Phuyal et al. (U.S. Patent Application Publication No. 20220353734, hereinafter “Phuyal”) in view of Ma et al. (U.S. Patent Application Publication No. 20250392531, which claims priority to U.S. Provisional Patent Application No. 63/663,323, filed on Jun. 24, 2024, entitled “INTENTIONAL DROPPING OF OBSOLETE PACKETS,” hereinafter “Ma”).
Examiner’s note: in what follows, references are drawn to Phuyal unless otherwise mentioned.
With respect to independent claims:
Regarding Claim 1, Phuyal teaches A transmitter node (Fig. 2, Base Station 110) of a telecommunications system, the node comprising:
processor circuitry (Fig. 2, Controller/Processor 240) configured to include a polling request in an obsolete packet indication message for an obsolete packet
(para [0072]: …For example, the RLC-AM may enable a UE 120 to transmit a status PDU indicating RLC control information, such as ACK or NACK feedback for one or more RLC SDUs, for example. The RLC-AM may enable a UE 120 to poll a peer RLC entity in order to trigger status reporting at the peer RLC entity.) (Fig. 5 and para [0074]: The PDU format 510 may include a polling bit (shown as “P” in FIG. 5) in the first octet indicating whether polling is request for the PDU.) (para [0076]: if a UE 120 receives a PDU format where unknown fields or reserved fields are used (for example, where an unknown field or a reserved field includes a value of “1”), the UE 120 may discard or ignore the PDU (for example, in accordance with a wireless communication standard).) (para [0099]: the base station 110 may use a reserved field of an RLC header (interpreted as “an obsolete packet indication message”) to indicate that the packet is a redundancy packet (interpreted as “an obsolete packet”) for a network coding feature or a forward error correction feature.); and
interface circuitry (Fig. 2, Transmit Processor/Tx MIMO Processor/ Controller/Processor 230/240) configured to transmit the obsolete packet indication message over a radio interface to a receiver node of the telecommunications system (para [0099]: In a ninth operation 645, the base station 110 may transmit one or more retransmissions of the previously transmitted RLC PDUs, or redundancy packets associated with the multicast/broadcast message in accordance with a network coding feature or a forward error correction feature, or a combination thereof. …In some aspects, the base station 110 may use a reserved field of an RLC header (interpreted as “an obsolete packet indication message”, the radio link control (RLC) is interpreted as “over a radio interface”) to indicate that the packet is a redundancy packet for a network coding feature or a forward error correction feature.) (para [0100]: Additionally, in a tenth operation 650, as a reserved field is used to indicate that the packet is a parity packet, the first UE 120 (interpreted as “a receiver node of the telecommunications system”) may discard or drop the packet.).
As noted above, Phuyal discloses processor circuitry 240 configured to generate an RLC PDU format (e.g., AMD PDU) that includes a poling request (a polling bit “P” in Fig. 5) to trigger a peer RLC entity to provide status reporting (para [0072]). Furthermore, Phuyal discloses generating a specific indication message/control header (e.g., an RLC control PDU or reserved bit) that explicitly indicates a packet is to be dropped/discarded by the receiver (e.g., indicating a packet is a parity/redundancy packet which enables the UE to drop it)(paragraphs [0031], [0099], [0100])
Phuyal does not explicitly discloses that the indication message instructing the receiver to drop the packet is specifically an obsolete packet indication message “for an obsolete packet.”
However, Ma discloses a method in a radio access network (RAN) entity for identifying and intentionally dropping obsolete packets to conserve the receiver’s power and optimize throughput. Ma explicitly defines these “obsolete packets” as redundant repair packets (e.g., used in Application Layer Forward Error Correction (AL-FEC) or network coding) that are no longer necessary for successfully reconstructing source packets at the receiver (see paragraphs [0028]-[0029] and [0092]-[0093] of Ma).
Para [0028] of Ma (see para [0027] of Provisional Patent Application No. 63/663,323) : If source packets are successfully received, repair packets are not needed, or are obsolete. That is, obsolete packets may include packets that are not unnecessary for successful reconstruction of the source packets. Obsolete packets may include obsolete repair packets of an application data unit (ADU) or a protocol data unit (PDU) set (such as for FlexFEC), or obsolete coded packets in Reed-Solomon codes. Some schemes for error correction may include a router intentionally dropping obsolete packets in order to conserve the receiver's power, because the receiver does not need to stay awake longer than necessary to receive the redundant repair packets.
Para [0029] of Ma (see para [0028] of Provisional Patent Application No. 63/663,323): The intentional dropping of obsolete packets at a radio access network (RAN) network entity occurs at the last hop of an end-to-end path.).
Therefore, it would have been obvious to a person of ordinary skill in the art at the time the invention was made to modify the transmitter node of Phuyal to incorporate the intentional dropping of obsolete repair packets as taught by Ma, and to utilize the control indication message and polling request mechanism of Phuyal to notify the receiver of such obsolete packets. The motivation for this modification would be to maintain Radio Link Control (RLC) window synchronization and prevent receiver buffer stalling when implementing the power-saving packet dropping mechanism of Ma.
By utilizing the control indication message and polling request mechanism (as taught by Phuyal), the transmitter can explicitly inform the receiver that the specific packet was intentionally discarded (i.e., is an obsolete packet), while simultaneously polling the receiver to trigger an immediate status report. This predictable combination of known signaling mechanism ensures that the receiver rapidly advances its receiving window and ignores the dropped obsolete packets without triggering unnecessary retransmission procedure, thereby perfectly achieving ma’s goal of resource and power conservation without compromising the stability of the RLC protocol.
Regarding Claim 11, it is method claim corresponding to the transmitter node claim and is therefore rejected for the similar reasons set forth in the rejection of claim 1.
Regarding Claim 12, Phuyal teaches A receiver node (Fig. 2, UE 120) of a telecommunications system, the node comprising:
interface circuitry (Fig. 2, a receive processor 258) configured to receive an obsolete packet indication message over a radio interface from a transmitter node of the telecommunications system (para [0099]: In a ninth operation 645, the base station 110 may transmit one or more retransmissions of the previously transmitted RLC PDUs, or redundancy packets associated with the multicast/broadcast message in accordance with a network coding feature or a forward error correction feature, or a combination thereof. …In some aspects, the base station 110 may use a reserved field of an RLC header (interpreted as “an obsolete packet indication message”, the radio link control (RLC) is interpreted as “over a radio interface”) to indicate that the packet is a redundancy packet for a network coding feature or a forward error correction feature.) (para [0100]: Additionally, in a tenth operation 650, as a reserved field is used to indicate that the packet is a parity packet, the first UE 120 (interpreted as “the receiver node”) may discard or drop the packet.);
processor circuitry (Fig. 2, a controller/processor 280) configured to determine if a polling request is included in the obsolete packet indication message for an obsolete packet and to process the packet accordingly (para [0072]: …For example, the RLC-AM may enable a UE 120 to transmit a status PDU indicating RLC control information, such as ACK or NACK feedback for one or more RLC SDUs, for example. The RLC-AM may enable a UE 120 to poll a peer RLC entity in order to trigger status reporting at the peer RLC entity.) (Fig. 5 and para [0074]: The PDU format 510 may include a polling bit (shown as “P” in FIG. 5) in the first octet indicating whether polling is request for the PDU.) (para [0076]: if a UE 120 receives a PDU format where unknown fields or reserved fields are used (for example, where an unknown field or a reserved field includes a value of “1”), the UE 120 may discard or ignore the PDU (for example, in accordance with a wireless communication standard).) (para [0099]: the base station 110 may use a reserved field of an RLC header (interpreted as “the obsolete packet indication message”) to indicate that the packet is a redundancy packet (interpreted as “an obsolete packet”) for a network coding feature or a forward error correction feature.) (para [0100]: Additionally, in a tenth operation 650, as a reserved field is used to indicate that the packet is a parity packet, the first UE 120 (interpreted as “the receiver node”) may discard or drop the packet.).
As noted above, Phuyal discloses processor circuitry 240 configured to generate an RLC PDU format (e.g., AMD PDU) that includes a poling request (a polling bit “P” in Fig. 5) to trigger a peer RLC entity to provide status reporting (para [0072]). Furthermore, Phuyal discloses generating a specific indication message/control header (e.g., an RLC control PDU or reserved bit) that explicitly indicates a packet is to be dropped/discarded by the receiver (e.g., indicating a packet is a parity/redundancy packet which enables the UE to drop it)(paragraphs [0031], [0099], [0100])
Phuyal does not explicitly discloses that the indication message instructing the receiver to drop the packet is specifically an obsolete packet indication message “for an obsolete packet.”
However, Ma discloses a method in a radio access network (RAN) entity for identifying and intentionally dropping obsolete packets to conserve the receiver’s power and optimize throughput. Ma explicitly defines these “obsolete packets” as redundant repair packets (e.g., used in Application Layer Forward Error Correction (AL-FEC) or network coding) that are no longer necessary for successfully reconstructing source packets at the receiver (see paragraphs [0028]-[0029] and [0092]-[0093] of Ma).
Para [0028] of Ma (see para [0027] of Provisional Patent Application No. 63/663,323) : If source packets are successfully received, repair packets are not needed, or are obsolete. That is, obsolete packets may include packets that are not unnecessary for successful reconstruction of the source packets. Obsolete packets may include obsolete repair packets of an application data unit (ADU) or a protocol data unit (PDU) set (such as for FlexFEC), or obsolete coded packets in Reed-Solomon codes. Some schemes for error correction may include a router intentionally dropping obsolete packets in order to conserve the receiver's power, because the receiver does not need to stay awake longer than necessary to receive the redundant repair packets.
Para [0029] of Ma (see para [0028] of Provisional Patent Application No. 63/663,323): The intentional dropping of obsolete packets at a radio access network (RAN) network entity occurs at the last hop of an end-to-end path.).
Therefore, it would have been obvious to a person of ordinary skill in the art at the time the invention was made to modify the transmitter node of Phuyal to incorporate the intentional dropping of obsolete repair packets as taught by Ma, and to utilize the control indication message and polling request mechanism of Phuyal to notify the receiver of such obsolete packets. The motivation for this modification would be to maintain Radio Link Control (RLC) window synchronization and prevent receiver buffer stalling when implementing the power-saving packet dropping mechanism of Ma.
By utilizing the control indication message and polling request mechanism (as taught by Phuyal), the transmitter can explicitly inform the receiver that the specific packet was intentionally discarded (i.e., is an obsolete packet), while simultaneously polling the receiver to trigger an immediate status report. This predictable combination of known signaling mechanism ensures that the receiver rapidly advances its receiving window and ignores the dropped obsolete packets without triggering unnecessary retransmission procedure, thereby perfectly achieving Ma’s goal of resource and power conservation without compromising the stability of the RLC protocol.
With respect to dependent claims:
Regarding claim 4, Phuyal and Ma teach The node of claim 1, Phuyal further teaches wherein the polling request comprises a predetermined value of a polling bit (Fig. 5 and para [0074]: The PDU format 510 may include a polling bit (shown as “P” in FIG. 5) in the first octet indicating whether polling is request for the PDU.).
Regarding claim 5, Phuyal and Ma teach The node of claim 1, Phuyal further teaches wherein the processor circuitry is configured to generate the obsolete packet indication message to include an indication of a radio link control (RLC) base sequence number which is reported as being an obsolete packet (Claim 28 of Phuyal: … the packet that includes a field indicating a PDCP sequence number range associated with the packet or a Control PDU Type (CPT) field indicating that the packet is a redundancy packet.).
Regarding claim 6, Phuyal and Ma teach The node of claim 5, Phuyal further teaches wherein the radio link control (RLC) base sequence number is a highest RLC SN among RLC SNs reported as being obsolete packets. (Fig. 5 and para [0074]: The PDU format 510 may include a polling bit (shown as “P” in FIG. 5) in the first octet indicating whether polling is request for the PDU.) (Claim 28 of Phuyal: … the packet that includes a field indicating a PDCP sequence number range associated with the packet or a Control PDU Type (CPT) field indicating that the packet is a redundancy packet.).
It would be obvious to a person of ordinary skill in the art at the time the invention was made to configure the RLC base sequence number to be the highest RLC SN among the reported obsolete packets. Defining the “a highest RLC SN” as the base sequence number for reporting a group of obsolete packets is a routine and predictable design choice. It provides a clear, mathematically consistent reference point for the receiving node to interpret the reported SN range or the associated bitmap. This optimization is explicitly supported by the established sequence number ranging mechanisms disclosed in Phuyal and represents a standard implementation detail for any protocol requiring sequence number range-based reporting. Thus, this limitation is an obvious optimization that yields only expected results.
Regarding claim 7, Phuyal and Ma teach The node of claim 5, Phuyal further teaches wherein the processor circuitry is configured to generate the obsolete packet indication message to include a range field which indicates a number of consecutive RLC SDUs from the base sequence number that are obsolete packets (Fig. 5 and para [0074]: The PDU format 510 may include a polling bit (shown as “P” in FIG. 5) in the first octet indicating whether polling is request for the PDU.) (Claim 28 of Phuyal: … the packet that includes a field indicating a PDCP sequence number range associated with the packet or a Control PDU Type (CPT) field indicating that the packet is a redundancy packet.).
Regarding claim 8, Phuyal and Ma teach The node of claim 7, Phuyal further teaches wherein the processor circuitry is configured to generate the obsolete packet indication message to include field which indicates presence of the range field (Fig. 5 and para [0074]: The PDU format 510 may include a polling bit (shown as “P” in FIG. 5) in the first octet indicating whether polling is request for the PDU.) (Claim 28 of Phuyal: … the packet that includes a field indicating a PDCP sequence number range associated with the packet or a Control PDU Type (CPT) field indicating that the packet is a redundancy packet.).
Regarding claim 9, Phuyal and Ma teach The node of claim 1, Phuyal further teaches wherein the processor circuitry is configured to generate the obsolete packet indication message to not include user application data (Fig. 5 and para [0074]: The PDU format 510 for the RLC-AM (for example, for the AMD PDU) may include a bit indicating whether the PDU is for data information or control information (shown as “D/C” in FIG. 5) in a first octet (Oct 1). The bit indicating whether the PDU is for data information or control information may be referred to herein as a “D/C bit” or a “D/C indication,” among other examples. The PDU format 510 may include a polling bit (shown as “P” in FIG. 5) in the first octet indicating whether polling is request for the PDU.).
Phuyal explicitly teaches that RLC-AM PDU formats utilize a “D/C bit” to distinguish between data information and control information (see para [0074]).
It would have been obvious to a person of ordinary skill in the art to configured the obsolete packet indication message as a Control PDU (i.e., not including user application data).
Regarding claim 10, Phuyal and Ma teach The node of claim 1, wherein the node is one of (1) a wireless terminal which communicates over the radio interface with a radio access network; and (2) a network node which communicates over the radio interface with a wireless terminal (Fig. 2 and para [0045]: FIG. 2 is a diagram illustrating an example base station in communication with a UE in a wireless network in accordance with the present disclosure. The base station may correspond to base station 110 of FIG. 1. Similarly, the UE may correspond to UE 120 of FIG. 1.) (para [0072]: …For example, the RLC-AM may enable a UE 120 to transmit a status PDU indicating RLC control information, such as ACK or NACK feedback for one or more RLC SDUs, for example. The RLC-AM may enable a UE 120 to poll a peer RLC entity in order to trigger status reporting at the peer RLC entity.).
Regarding claim 13, Phuyal and Ma teach The node of claim 12, Phuyal further teaches wherein the processor circuitry is configured to determine if a polling request is included in the obsolete packet indication message for a plural number of obsolete packets and to process the plural number of packets accordingly (Fig. 5 and para [0074]: The PDU format 510 may include a polling bit (shown as “P” in FIG. 5) in the first octet indicating whether polling is request for the PDU.) (Claim 28 of Phuyal: … the packet that includes a field indicating a PDCP sequence number range associated with the packet or a Control PDU Type (CPT) field indicating that the packet is a redundancy packet.).
Regarding claim 14, Phuyal and Ma teach The node of claim 12, Phuyal further teaches wherein the processor circuitry is configured to determine if a polling request includes an indication of a radio link control (RLC) base sequence number which is reported as being an obsolete packet (Fig. 5 and para [0074]: The PDU format 510 may include a polling bit (shown as “P” in FIG. 5) in the first octet indicating whether polling is request for the PDU.) (Claim 28 of Phuyal: … the packet that includes a field indicating a PDCP sequence number range associated with the packet or a Control PDU Type (CPT) field indicating that the packet is a redundancy packet.).
Phuyal explicitly teaches that the RLC-AM PDU formant (PDU format 510) concurrently includes both a polling bit (p) and a sequence number (SN) field within the same PDU header (See Fig. 5 and para [0074]).
It would have been obvious to a person of ordinary skill in the art to configured the processor circuitry to process the obsolete packet indication message to determine if the polling request includes an indication of the RLC base sequence number.
Regarding claim 15, Claim 15, has similar limitation as of Claim(s) 10, therefore it is rejected under the same reasons as Claim(s) 10.
Claim(s) 2-3 rejected under 35 U.S.C. 103 as being unpatentable over Phuyal in view of Ma, and further in view of 3GPP TS 138.322 v16.1.0 (2020-07) “Radio Link Control (RLC) protocol specification (3GPP TS 38.322 version 16.1.0 Release 16)”(hereinafter “3GPP TS 38.322”).
Regarding claim 2, Phuyal and Ma teach The node of claim 1, Phuyal and Ma fail to explicitly teach wherein the processor circuitry is configured to include the polling request in the obsolete packet indication message upon expiration of a polling retransmit timer.
The combination of Phuyal and Ma discloses a transmitter node comprising the processor circuitry is configured to include a polling request in the obsolete packet indication message for an obsolete packet, as discussed in the rejection of Claim 1. However, the combination of Phuyal and Ma does not explicitly disclose the specific temporal trigger of including the polling request upon expiration of a polling retransmit timer.
3GPP TS 38.322 defines the Radio Link Control (RLC) protocol. 3GPP TS 38.322 explicitly discloses the polling mechanism in an AM RLC entity. Specifically, Section 5.3.3.4 of 3GPP TS 38.322 teaches that “Upon expiry of t-PollRetransmit, the transmitting side of an AM RLC entity shall: … include a poll in an AMD PDU as described in clause 5.3.3.2. Section 5.3.3.4 of 3GPP TS 38.322 is reproduced herein below.
PNG
media_image1.png
360
1044
media_image1.png
Greyscale
(Section 5.3.3.4 of 3GPP TS 38.322, page 20)
If would have been obvious to a person of ordinary skill in the art at the time the invention was made to further modify the combined system of Phuyal and Ma by incorporating the timer-based polling trigger mechanism explicitly taught by the industry standard 3GPP TS 38.322. The motivation for this modification is to comply with standard RLC protocol requirements to maintain transmission window synchronization.
Regarding claim 3, Phuyal and Ma teach The node of claim 1, Phuyal and Ma fail to explicitly teach wherein the processor circuitry is configured to include the polling request in the obsolete packet indication message when all packets in a transmission buffer are obsolete packets.
The combination of Phuyal and Ma discloses a transmitter node comprising the processor circuitry is configured to include a polling request in the obsolete packet indication message for an obsolete packet, as discussed in the rejection of Claim 1. However, the combination of Phuyal and Ma does not explicitly disclose the specific condition of including the polling request when all packets in a transmission buffer are obsolete packets.
3GPP TS 38.322 defines the Radio Link Control (RLC) protocol. Section 5.3.3.2 of 3GPP TS 38.322 explicitly teaches the buffer-status-based polling triggers in an AM RLC entity. Specifically, 3GPP TS 38.322 discloses that “the transmitting side of an AM RLC entity shall: if both the transmission buffer and the retransmission buffer becomes empty (excluding transmitted RLC SDUs or RLC SDU segments awaiting acknowledgements) after the transmission of the AMD PDU; or if no new RLC SDU can be transmitted after the transmission of the AMD PDU (e.g. due to window stalling); include a poll in the AMD PDU as describe below.” (see page 19, Section 5.3.3.2 (Transmission of a AMD PDU)). (Examiner’s note: When a transmitter identifies that all packets remaining in its transmission buffer are obsolete packets, it will intentionally drop them to conserve resources, as taught by Phuyal and Ma. Consequently, the intentional dropping of all remaining packets leaves the transmitter in a state where there is no valid data left to transmit, rendering the transmission buffer effectively “empty” of transmittable data (i.e., no new RLC SDU can be transmitted).)
It would have been obvious to a person of ordinary skill in the art at the time the invention was made to apply the standard buffer-status-based polling trigger mechanism of the industry standard 3GPP TS 38.322 to the packet dropping method of Phuyal and Ma. The motivation is to predictable maintain RLC window synchronization and prevent protocol stalling when all remaining packets in the buffer are identified as obsolete and dropped.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to WON JUN CHOI whose telephone number is (703)756-1695. The examiner can normally be reached MON-FRI 08:00 - 17:00.
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, Derrick W Ferris can be reached at 571-272-3123. 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.
/WON JUN CHOI/Examiner, Art Unit 2411
/DERRICK W FERRIS/Supervisory Patent Examiner, Art Unit 2411
Prosecution Insights