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
This is in response to an amendment/response/communication filed 4/16/2025.
No claims have been added.
Claim(s) 2, 4, 6-9, 12, 14, 16-17, 19-20, 22, 24, 26-28, 30, 32-35, 37, 39, 41-44, 48-49 and 51-60 has/have been cancelled.
Claims(s) 1, 3, 5, 10-11, 13, 15, 18, 21, 23, 25, 29, 31, 36, 38, 40, 45-47 and 50 is/are currently pending.
Information Disclosure Statement
The information disclosure statement(s) (IDS(s)) submitted on 10/2/2024 is/are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the Examiner.
Priority
Receipt is acknowledged of certified copies of papers required by 37 CFR 1.55.
Drawings
The drawings were received on 10/2/2024. These drawings are accepted.
Specification
The lengthy specification has not been checked to the extent necessary to determine the presence of all possible minor errors. Applicant's cooperation is requested in correcting any errors of which applicant may become aware in the specification.
The listing of references in the specification is not a proper information disclosure statement. 37 CFR 1.98(b) requires a list of all patents, publications, or other information submitted for consideration by the Office, and MPEP § 609.04(a) states, "the list may not be incorporated into the specification but must be submitted in a separate paper." Therefore, unless the references have been cited by the examiner on form PTO-892, they have not been considered. See paragraphs 0187, 0209 0218, 0228 and 0232 of the specification of the original disclosure.
Claim Objections
Claim 5 is objected to because of the following informalities: claim 5, line 1, notes “the PDCP status report”, however, “PDCP status report” has not previously been noted. The Examiner suggests changing to “a PDCP status report”, or something similar. Appropriate correction is required.
Claim 46 is objected to because of the following informalities: claim 46, line 3 and claim 46, line 6, note, “the uplink radio bearer”, however, the “uplink radio bearer” has not previously been noted. The Examiner suggests changing to “the downlink radio bearer”, or something similar. Appropriate correction is required.
Examiner’s Comments Regarding Subject Matter Eligibility
The potential abstract ideas of “determining that a PDCP protocol data unit (PDP) has been successfully delivered to a network node” as noted in claim 1 and “determining that PDCP PDU has been successfully delivered to a first UE”, as noted in claim 36 are considered as not capable of being performed in the human mind and the claims are therefore considered as eligible subject matter under 35 U.S.C. 101.
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 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, 3, 21, 23, 36 and 38 is/are rejected under 35 U.S.C. 103 as being unpatentable over Song et al. US 20220232402 in view of Wang et al. US 20230074899 and in further view of Palat et al. US 20230189380.
As to claim 1:
Song et al. discloses:
A method formed by a first user equipment (UE), comprising:
for an uplink radio bearer that has been activated with packet data convergence protocol (PDCP), duplication,
(“With respect to the SDAP layer, the terminal may be instructed through an RRC message from the base station whether to use a header of the SDAP layer or whether to use the function of the SDAP layer for each PDCP layer, each bearer, or each logical channel. When the SDAP header is configured, a 1-bit indicator (e.g., non-access stratum (NAS) reflective quality of service (QoS)) and a 1-bit indicator (e.g., access stratum (AS) reflective QoS) in the SDAP header may indicate to the terminal whether to update or reconfigure mapping information for uplink and downlink QoS flows and data bearers. The SDAP header may include QoS flow ID information indicating a QoS. The QoS information may be used as data processing priority, scheduling information, or the like to support smooth service provisioning.”; Song et al.; 0109)
(“In addition, the PDCP layers 521 to 523, 621 to 623, and 671 to 673 may be in charge of operations such as IP header compression/decompression. The main functions of the PDCP layer may be summarized as follows, and may not be limited to the following examples. [0111] Header compression and decompression: robust header compression (ROHC) only [0112] Transfer of user data [0113] In-sequence delivery of upper layer PDUs at PDCP re-establishment procedure for RLC acknowledge mode (AM) [0114] For split bearers in DC (only support for RLC AM): PDCP PDU routing for transmission and PDCP PDU reordering for reception [0115] Duplicate detection of lower layer SDUs at PDCP re-establishment procedure for RLC AM [0116] Retransmission of PDCP SDUs at handover and, for split bearers in DC, of PDCP PDUs at PDCP data-recovery procedure, for RLC AM [0117] Ciphering and deciphering [0118] Timer-based SDU discard in uplink”; Song et al.; 0110)
(where
“SDAP layer for each PDCP layer…uplink…data bearers”/”In addition, the PDCP layers 521 to 523, 621 to 623, and 671 to 673 may be in charge of operations such as IP header compression/decompression. The main functions of the PDCP layer may be summarized as follows, … For split bearers in DC (only support for RLC AM): …Duplicate detection … for split bearers in DC” maps to “for an uplink radio bearer that has been activated with packet data convergence protocol (PDCP), duplication”, where “uplink…data bearers” maps to “uplink radio bearer”, “PDCP… may be in charge” maps to “activated”, “duplicate” maps to “duplication”
determining that a PDCP protocol data unit (PDU), has been successfully delivered to a network node via a relay UE on a UE-to-network relay path; and (“In the above-described situation, the PDCP layer 1024 of the first base station 1020 may receive the first PDCP PDUs transmitted by the second relay terminal 1050 through the PHY layer 1021, the MAC layer 1022, and the RLC layer 1023. In addition, the PDCP layer 1024 of the first base station 1020 may receive, from the second base station 1030, the second PDCP PDUs transmitted from the first relay terminal 1040. Then, the PDCP layer 1024 of the first base station 1020 may identify sequence numbers (SNs) of the first PDCP PDUs and the second PDCP PDUs, reassemble them by using the sequence numbers, and deliver the reassembled PDUs to the core network.”; Song et al.; 0173)
(“In the above-described situation, the PDCP layer 1024 of the first base station 1020 may receive first PDCP PDUs transmitted by the second relay terminal 1050 through the PHY layer 1021, the MAC layer 1022, and the RLC layer 1023. In addition, the PDCP layer 1024 of the first base station 1020 may receive, from the second base station 1030, the second PDCP PDUs transmitted from the first relay terminal 1040. In this case, the PDCP layer 1024 of the first base station 1020 may identify sequence numbers (SNs) of the first PDCP PDU and the second PDCP PDU. If they are confirmed as the same PDCP PDU, either one may be discarded, and the other PDCP PDU may be delivered to the core network.”; Song et al.; 0176)
(“On the other hand, in a communication system for a high-speed mobile vehicle such as a high-speed train (HST), there may be a direct communication scheme in which a user terminal in the mobile vehicle communicates directly with an external (e.g., terrestrial) base station and a relay communication scheme in which the user terminal communicates with the base station through a relay terminal installed in the mobile vehicle.”; Song et al.; 0046)
(where
“the first base station 1020 may receive first PDCP PDUs transmitted by the second relay terminal 1050 through the PHY layer 1021, the MAC layer 1022, and the RLC layer 1023. In addition, the PDCP layer 1024 of the first base station 1020 may receive, from the second base station 1030, the second PDCP PDUs transmitted from the first relay terminal 1040”/”a user terminal in the mobile vehicle communicates directly with an external (e.g., terrestrial) base station and a relay communication scheme in which the user terminal communicates with the base station through a relay terminal”/”the PDCP layer 1024 of the first base station 1020 may receive the first PDCP PDUs transmitted by the second relay terminal … the PDCP layer 1024 of the first base station 1020 may receive, from the second base station 1030, the second PDCP PDUs transmitted from the first relay terminal 1040. Then, the PDCP layer 1024 of the first base station 1020 may identify sequence numbers (SNs) of the first PDCP PDUs and the second PDCP PDUs, reassemble them by using the sequence numbers”/FIG. 1/FIG. 10 maps to “determining that a PDCP protocol data unit (PDU), has been successfully delivered to a network node via a relay UE on a UE-to-network relay path”, where “receive first PDCP PDUs”/”receive…second PDCP PDUs”/”may identify sequence numbers (SNs) of the first PDCP PDUs and the second PDCP PDUs, reassemble them” maps to “determining that a PDCP protocol data unit (PDU), has been successfully delivered to a network node”, where “”receive”/”reassemble” is considered as requiring “determining that a PDCP protocol data unit (PDU), has been successfully delivered”, in order to perform “receive”/reassemble”, “base station” maps to “network node”, a user terminal in the mobile vehicle communicates directly with an external (e.g., terrestrial) base station and a relay communication scheme in which the user terminal communicates with the base station through a relay terminal” maps to ” via a relay UE on a UE-to-network relay path”, where “relay terminal “ maps “ via a relay UE”, user terminal communicates with the base station through a relay terminal”/FIG. 1/FIG. 10 maps/illustrates “on a UE-to-network relay path”
discarding at least one duplicated PDCP PDU on at least one other UE-to network path, wherein the at least one other UE-to-network path comprises:
a UE-to-network relay path, and/or
…
(where
“If they are confirmed as the same PDCP PDU, either one may be discarded, and the other PDCP PDU may be delivered to the core network” maps to “discarding at least one duplicated PDCP PDU on at least one other UE-to-network path, wherein the at least one other UE-to-network path comprises:
a UE-to-network relay path”, where “discarded” maps to “discarding”, “same” maps to “duplicated”, “PDCP PDU” maps to “PDCP PDU”, “other PDCP PDU”/FIG. 10 maps to “one other UE-to-network path”/”UE-to-network relay path”
Song et al. teaches PDCP with an uplink bearer where duplicate PDUs are received via two different relay paths and one PDU is discarded.
Song et al. as described above does not explicitly teach:
a UE-to-network direct path.
However, Wang et al. further teaches a discard capability which includes:
a UE-to-network direct path.
(“FIG. 3 is a schematic diagram of uplink data packet transmission according to an embodiment. Taking uplink packet transmission as an example, as shown in FIG. 3, UE1 has submitted packets 1, 2, 3, and 4 to a PC5 interface for transmission to a relay 1. The PC5 interface adopts RLC acknowledgement mode (AM mode) transmission, and the UE1 receives a packets 1, 2, and 4 acknowledgement indication and a packet 3 unacknowledgement indication sent by the relay. In this case, if path switch is performed, the UE1 performs PDCP data recovery and submits the first packet (packet 3) not acknowledged by the relay and subsequent packets to a Uu interface for direct transmission to the base station (NW). The relay will continue to send the packets 1, 2, and 4 to the base station, and the base station receives the packets 1, 2, and 4 forwarded by the relay and packets 3, 4, 5, 6, . . . sent by the UE1 through the Uu interface, performs duplicate packet detection, discards a duplicate packet (packet 4), and performs PDCP reordering, so as to sequentially submit the packets to an upper layer.”; Wang et al.; 0053)
(where
“packets 3, 4, 5, 6, . . . sent by the UE1 through the Uu interface, performs duplicate packet detection, discards a duplicate packet (packet 4)” maps to “a UE-to-network direct path”, where “Uu interface” maps to “UE-to-network direct path”, where Palat et al. teaches PDU can be referred to as “packed…data unit” or “prococol data unit”
Wang et al. teaches duplicate packets received via relay/PC5 and UU, where a duplicate packet received via UU is discarded.
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the discard capability of Wang et al. into Song et al. By modifying the processing/communications of Song et al. to include the discard capability as taught by the processing/communications of Wang et al. with the packet/PDU teaching of Palat et al., the benefits of improved packet duplication transmission (Song et al.; 0179) with improved reliability (Wang et al.; 0004) are achieved.
As to claim 3:
Song et al. as described above does not explicitly teach:
wherein determining
that the PDCP PDD has been successfully delivered to the network node via the relay DE on the
DE-to-network relay path comprises:
llreceiving a radio link control (RLC), RLC, status report from the relay DE, wherein the
RLC status report indicates that the PDCP PDD has been successfully transmitted to the relay DE
in a sidelink; and
determining that the PDCP PDD has been successfully delivered to the network node via
the relay DE on the DE-to-network relay path based on the RLC status report, or
2) receiving a PDCP status report from the network node, wherein the PDCP status report
indicates that the PDCP PDD has been successfully received by the network node via the DE-tonetwork
relay path; and
determining that the PDCP PDD has been successfully delivered to the network node on
the DE-to-network relay path based on the PDCP status report, or
…
However, Wang et al. further teaches a status report capability which includes:
wherein determining
that the PDCP PDD has been successfully delivered to the network node via the relay DE on the
DE-to-network relay path comprises:
llreceiving a radio link control (RLC), RLC, status report from the relay DE, wherein the
RLC status report indicates that the PDCP PDD has been successfully transmitted to the relay DE
in a sidelink; and
determining that the PDCP PDD has been successfully delivered to the network node via
the relay DE on the DE-to-network relay path based on the RLC status report, or
2) receiving a PDCP status report from the network node, wherein the PDCP status report
indicates that the PDCP PDD has been successfully received by the network node via the DE-tonetwork
relay path; and
determining that the PDCP PDD has been successfully delivered to the network node on
the DE-to-network relay path based on the PDCP status report, or
…
(“FIG. 3 is a schematic diagram of uplink data packet transmission according to an embodiment. Taking uplink packet transmission as an example, as shown in FIG. 3, UE1 has submitted packets 1, 2, 3, and 4 to a PC5 interface for transmission to a relay 1. The PC5 interface adopts RLC acknowledgement mode (AM mode) transmission, and the UE1 receives a packets 1, 2, and 4 acknowledgement indication and a packet 3 unacknowledgement indication sent by the relay. In this case, if path switch is performed, the UE1 performs PDCP data recovery and submits the first packet (packet 3) not acknowledged by the relay and subsequent packets to a Uu interface for direct transmission to the base station (NW). The relay will continue to send the packets 1, 2, and 4 to the base station, and the base station receives the packets 1, 2, and 4 forwarded by the relay and packets 3, 4, 5, 6, . . . sent by the UE1 through the Uu interface, performs duplicate packet detection, discards a duplicate packet (packet 4), and performs PDCP reordering, so as to sequentially submit the packets to an upper layer.
[0054] In an embodiment, the path switching method further includes: receiving a first PDCP status report sent by the base station; and retransmitting the data packets not received successfully indicated in the first PDCP status report and/or transmitting new data through the second link according to the first PDCP status report.
[0055] In this embodiment, the first PDCP status report indicates the data packets not received successfully, which are retransmitted to avoid packet loss. In response to there being no unsuccessfully received data packets in the first PDCP status report, new data can be transmitted.”; Wang et al.; 0053-0055)
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the status report capability of Wang et al. into Song et al. By modifying the processing/communications of Song et al. to include the status report capability as taught by the processing/communications of Wang et al. with the packet/PDU teaching of Palat et al., the benefits of improved packet duplication transmission (Song et al.; 0179) with improved reliability (Wang et al.; 0004) are achieved.
As to claim 21:
Song et al. discloses:
A method performed by a relay DE, comprising:
receiving a PDCP PDD of an uplink radio bearer from a first DE, wherein the uplink radio bearer has been activated with PDCP duplication; and
(“With respect to the SDAP layer, the terminal may be instructed through an RRC message from the base station whether to use a header of the SDAP layer or whether to use the function of the SDAP layer for each PDCP layer, each bearer, or each logical channel. When the SDAP header is configured, a 1-bit indicator (e.g., non-access stratum (NAS) reflective quality of service (QoS)) and a 1-bit indicator (e.g., access stratum (AS) reflective QoS) in the SDAP header may indicate to the terminal whether to update or reconfigure mapping information for uplink and downlink QoS flows and data bearers. The SDAP header may include QoS flow ID information indicating a QoS. The QoS information may be used as data processing priority, scheduling information, or the like to support smooth service provisioning.”; Song et al.; 0109)
(“In addition, the PDCP layers 521 to 523, 621 to 623, and 671 to 673 may be in charge of operations such as IP header compression/decompression. The main functions of the PDCP layer may be summarized as follows, and may not be limited to the following examples. [0111] Header compression and decompression: robust header compression (ROHC) only [0112] Transfer of user data [0113] In-sequence delivery of upper layer PDUs at PDCP re-establishment procedure for RLC acknowledge mode (AM) [0114] For split bearers in DC (only support for RLC AM): PDCP PDU routing for transmission and PDCP PDU reordering for reception [0115] Duplicate detection of lower layer SDUs at PDCP re-establishment procedure for RLC AM [0116] Retransmission of PDCP SDUs at handover and, for split bearers in DC, of PDCP PDUs at PDCP data-recovery procedure, for RLC AM [0117] Ciphering and deciphering [0118] Timer-based SDU discard in uplink”; Song et al.; 0110)
(where
“SDAP layer for each PDCP layer…uplink…data bearers”/”In addition, the PDCP layers 521 to 523, 621 to 623, and 671 to 673 may be in charge of operations such as IP header compression/decompression. The main functions of the PDCP layer may be summarized as follows, … For split bearers in DC (only support for RLC AM): …Duplicate detection … for split bearers in DC” maps to “for an uplink radio bearer that has been activated with packet data convergence protocol (PDCP), duplication”, where “uplink…data bearers” maps to “uplink radio bearer”, “PDCP… may be in charge” maps to “activated”, “duplicate” maps to “duplication”
Song et al. teaches PDCP with an uplink bearer where duplicate PDUs are received via two different relay paths and one PDU is discarded.
Song et al. as described above does not explicitly teach:
sending an indication that the PDCP PDU has been successfully delivered to a network node via the relay UE on a UE-to-network relay path to the first UE, wherein the PDCP PDU is delivered to the network node via at least one of:
a UE-to-network relay path, or
a UE-to-network direct path
However, Wang et al. further teaches a status report capability which includes:
sending an indication that the PDCP PDU has been successfully delivered to a network node via the relay UE on a UE-to-network relay path to the first UE, wherein the PDCP PDU is delivered to the network node via at least one of:
a UE-to-network relay path, or
a UE-to-network direct path
(“FIG. 3 is a schematic diagram of uplink data packet transmission according to an embodiment. Taking uplink packet transmission as an example, as shown in FIG. 3, UE1 has submitted packets 1, 2, 3, and 4 to a PC5 interface for transmission to a relay 1. The PC5 interface adopts RLC acknowledgement mode (AM mode) transmission, and the UE1 receives a packets 1, 2, and 4 acknowledgement indication and a packet 3 unacknowledgement indication sent by the relay. In this case, if path switch is performed, the UE1 performs PDCP data recovery and submits the first packet (packet 3) not acknowledged by the relay and subsequent packets to a Uu interface for direct transmission to the base station (NW). The relay will continue to send the packets 1, 2, and 4 to the base station, and the base station receives the packets 1, 2, and 4 forwarded by the relay and packets 3, 4, 5, 6, . . . sent by the UE1 through the Uu interface, performs duplicate packet detection, discards a duplicate packet (packet 4), and performs PDCP reordering, so as to sequentially submit the packets to an upper layer.”; Wang et al.; 0053)
(“In an embodiment, the path switching method further includes: receiving a first PDCP status report sent by the base station; and retransmitting the data packets not received successfully indicated in the first PDCP status report and/or transmitting new data through the second link according to the first PDCP status report.”; Wang et al.; 0054)
(“In this embodiment, the first PDCP status report indicates the data packets not received successfully, which are retransmitted to avoid packet loss. In response to there being no unsuccessfully received data packets in the first PDCP status report, new data can be transmitted.”; Wang et al.; 0055)
(where
“packets 3, 4, 5, 6, . . . sent by the UE1 through the Uu interface, performs duplicate packet detection, discards a duplicate packet (packet 4)” maps to “a UE-to-network direct path”, where “Uu interface” maps to “UE-to-network direct path”, where Palat et al. teaches PDU can be referred to as “packed…data unit” or “prococol data unit”
“there being no unsuccessfully received data packets in the first PDCP status report” maps to “PDCP PDU has been successfully delivered”
Wang et al. teaches duplicate packets received via relay/PC5 and UU, where a duplicate packet received via UU is discarded.
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the status report capability of Wang et al. into Song et al. By modifying the processing/communications of Song et al. to include the status report capability as taught by the processing/communications of Wang et al. with the packet/PDU teaching of Palat et al., the benefits of improved packet duplication transmission (Song et al.; 0179) with improved reliability (Wang et al.; 0004) are achieved.
As to claim 23:
Song et al. as described above does not explicitly teach:
wherein the indication is a RLC status report indicating that the PDCP PDD has been successfully transmitted to the relay DE in a sidelink, or
wherein the indication indicates the relay DE has received a RLC status report for the PDCP PDD from the network node.
However, Wang et al. further teaches a status report capability which includes:
wherein the indication is a RLC status report indicating that the PDCP PDD has been successfully transmitted to the relay DE in a sidelink, or
wherein the indication indicates the relay DE has received a RLC status report for the PDCP PDD from the network node.
(“FIG. 3 is a schematic diagram of uplink data packet transmission according to an embodiment. Taking uplink packet transmission as an example, as shown in FIG. 3, UE1 has submitted packets 1, 2, 3, and 4 to a PC5 interface for transmission to a relay 1. The PC5 interface adopts RLC acknowledgement mode (AM mode) transmission, and the UE1 receives a packets 1, 2, and 4 acknowledgement indication and a packet 3 unacknowledgement indication sent by the relay. In this case, if path switch is performed, the UE1 performs PDCP data recovery and submits the first packet (packet 3) not acknowledged by the relay and subsequent packets to a Uu interface for direct transmission to the base station (NW). The relay will continue to send the packets 1, 2, and 4 to the base station, and the base station receives the packets 1, 2, and 4 forwarded by the relay and packets 3, 4, 5, 6, . . . sent by the UE1 through the Uu interface, performs duplicate packet detection, discards a duplicate packet (packet 4), and performs PDCP reordering, so as to sequentially submit the packets to an upper layer.”; Wang et al.; 0053)
(“In an embodiment, the path switching method further includes: receiving a first PDCP status report sent by the base station; and retransmitting the data packets not received successfully indicated in the first PDCP status report and/or transmitting new data through the second link according to the first PDCP status report.”; Wang et al.; 0054)
(“In this embodiment, the first PDCP status report indicates the data packets not received successfully, which are retransmitted to avoid packet loss. In response to there being no unsuccessfully received data packets in the first PDCP status report, new data can be transmitted.”; Wang et al.; 0055)
(where
“packets 3, 4, 5, 6, . . . sent by the UE1 through the Uu interface, performs duplicate packet detection, discards a duplicate packet (packet 4)” maps to “a UE-to-network direct path”, where “Uu interface” maps to “UE-to-network direct path”, where Palat et al. teaches PDU can be referred to as “packed…data unit” or “prococol data unit”
“there being no unsuccessfully received data packets in the first PDCP status report” maps to “PDCP PDU has been successfully delivered”
Wang et al. teaches duplicate packets received via relay/PC5 and UU, where a duplicate packet received via UU is discarded.
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the status report capability of Wang et al. into Song et al. By modifying the processing/communications of Song et al. to include the status report capability as taught by the processing/communications of Wang et al. with the packet/PDU teaching of Palat et al., the benefits of improved packet duplication transmission (Song et al.; 0179) with improved reliability (Wang et al.; 0004) are achieved.
As to claim 36:
Song et al. discloses:
A method performed by a network node, comprising:
for a downlink radio bearer that has been activated with PDCP duplication, determining that a PDCP PDU has been successfully delivered to a first UE via a relay UE on a UE-to-network relay path; and
(“With respect to the SDAP layer, the terminal may be instructed through an RRC message from the base station whether to use a header of the SDAP layer or whether to use the function of the SDAP layer for each PDCP layer, each bearer, or each logical channel. When the SDAP header is configured, a 1-bit indicator (e.g., non-access stratum (NAS) reflective quality of service (QoS)) and a 1-bit indicator (e.g., access stratum (AS) reflective QoS) in the SDAP header may indicate to the terminal whether to update or reconfigure mapping information for uplink and downlink QoS flows and data bearers. The SDAP header may include QoS flow ID information indicating a QoS. The QoS information may be used as data processing priority, scheduling information, or the like to support smooth service provisioning.”; Song et al.; 0109)
(“In addition, the PDCP layers 521 to 523, 621 to 623, and 671 to 673 may be in charge of operations such as IP header compression/decompression. The main functions of the PDCP layer may be summarized as follows, and may not be limited to the following examples. [0111] Header compression and decompression: robust header compression (ROHC) only [0112] Transfer of user data [0113] In-sequence delivery of upper layer PDUs at PDCP re-establishment procedure for RLC acknowledge mode (AM) [0114] For split bearers in DC (only support for RLC AM): PDCP PDU routing for transmission and PDCP PDU reordering for reception [0115] Duplicate detection of lower layer SDUs at PDCP re-establishment procedure for RLC AM [0116] Retransmission of PDCP SDUs at handover and, for split bearers in DC, of PDCP PDUs at PDCP data-recovery procedure, for RLC AM [0117] Ciphering and deciphering [0118] Timer-based SDU discard in uplink”; Song et al.; 0110)
(where
“SDAP layer for each PDCP layer…downlink…data bearers”/”In addition, the PDCP layers 521 to 523, 621 to 623, and 671 to 673 may be in charge of operations such as IP header compression/decompression. The main functions of the PDCP layer may be summarized as follows, … For split bearers in DC (only support for RLC AM): …Duplicate detection … for split bearers in DC” maps to “for an downlink radio bearer that has been activated with packet data convergence protocol (PDCP), duplication”, where “downlink…data bearers” maps to “uplink radio bearer”, “PDCP… may be in charge” maps to “activated”, “duplicate” maps to “duplication”
discarding at least one duplicated PDCP PDU on at least one other UE-to network path, wherein the at least one other UE-to-network path comprises:
a UE-to-network relay path, and/or
…
(where
The Examiner notes the “discarding”, is not specifically noted as associated with “downlink radio bearer”.
“If they are confirmed as the same PDCP PDU, either one may be discarded, and the other PDCP PDU may be delivered to the core network” maps to “discarding at least one duplicated PDCP PDU on at least one other UE-to-network path, wherein the at least one other UE-to-network path comprises:
a UE-to-network relay path”, where “discarded” maps to “discarding”, “same” maps to “duplicated”, “PDCP PDU” maps to “PDCP PDU”, “other PDCP PDU”/FIG. 10 maps to “one other UE-to-network path”/”UE-to-network relay path”
Song et al. teaches PDCP with an uplink bearer where duplicate PDUs are received via two different relay paths and one PDU is discarded.
Song et al. as described above does not explicitly teach:
determining that a PDCP PDU has been successfully delivered to a first UE via a relay UE on a UE-to-network relay path
a UE-to-network direct path.
However, Wang et al. further teaches a discard/status report capability which includes:
determining that a PDCP PDU has been successfully delivered to a first UE via a relay UE on a UE-to-network relay path
(“FIG. 4 is a schematic diagram of downlink data packet transmission according to an embodiment. As shown in FIG. 4, packet loss may also occur in the transmission of downlink data. After the relay (relay 1) sends the packet 1 to the UE1, the quality of the PC5 link between the relay and the UE1 suddenly deteriorates or RLF occurs, and the packets 2 and 4 are still cached in the relay and not sent to the UE1, because the first packet submitted to the Uu interface for transmission by the base station is the packet 3, packet loss will occur, and the UE1 fails to receive the packet 2. In this case, this embodiment adopts the following methods to ensure lossless transmission between the base station and the UE1 during path switch.
[0064] Method One: In response to the UE1 instructing the base station to perform path switch or the base station making a decision to instruct the UE1 to perform path switch, the UE1 sends a PDCP status report for downlink data to the base station through the Uu interface, and the base station retransmits the unacknowledged data packets indicated in the PDCP status report. The acknowledged data packets do not need to be sent repeatedly.
[0065] Method Two: In response to the relay detecting that RLF occurs at the PC5 interface with the UE1, the relay sends instruction information to the base station through an RRC message (such as FailureInformation, or sidelinkUElnformation, or other uplink RRC messages), and informs the base station of PDCP SNs of data packets at the relay which have not been forwarded to the UE1 or have been forwarded but no acknowledgement feedback indication is received from the UE1.”; Wang et al.; 0063-0065)
a UE-to-network direct path.
(“FIG. 3 is a schematic diagram of uplink data packet transmission according to an embodiment. Taking uplink packet transmission as an example, as shown in FIG. 3, UE1 has submitted packets 1, 2, 3, and 4 to a PC5 interface for transmission to a relay 1. The PC5 interface adopts RLC acknowledgement mode (AM mode) transmission, and the UE1 receives a packets 1, 2, and 4 acknowledgement indication and a packet 3 unacknowledgement indication sent by the relay. In this case, if path switch is performed, the UE1 performs PDCP data recovery and submits the first packet (packet 3) not acknowledged by the relay and subsequent packets to a Uu interface for direct transmission to the base station (NW). The relay will continue to send the packets 1, 2, and 4 to the base station, and the base station receives the packets 1, 2, and 4 forwarded by the relay and packets 3, 4, 5, 6, . . . sent by the UE1 through the Uu interface, performs duplicate packet detection, discards a duplicate packet (packet 4), and performs PDCP reordering, so as to sequentially submit the packets to an upper layer.”; Wang et al.; 0053)
(where
“packets 3, 4, 5, 6, . . . sent by the UE1 through the Uu interface, performs duplicate packet detection, discards a duplicate packet (packet 4)” maps to “a UE-to-network direct path”, where “Uu interface” maps to “UE-to-network direct path”, where Palat et al. teaches PDU can be referred to as “packed…data unit” or “prococol data unit”
Wang et al. teaches duplicate packets received via relay/PC5 and UU, where a duplicate packet received via UU is discarded.
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the discard/status report capability of Wang et al. into Song et al. By modifying the processing/communications of Song et al. to include the discard/status report capability as taught by the processing/communications of Wang et al. with the packet/PDU teaching of Palat et al., the benefits of improved packet duplication transmission (Song et al.; 0179) with improved reliability (Wang et al.; 0004) are achieved.
As to claim 38:
Song et al. as described above does not explicitly teach:
wherein
determining that the PDCP PDD has been successfully delivered to the first DE via the relay DE
on the DE-to-network relay path comprises:
llreceiving a RLC status report from the relay DE, wherein the RLC status report indicates
that the PDCP PDD has been successfully transmitted to the relay DE in a Du link; and
determining that the PDCP PDD has been successfully delivered to the first DE via the
relay DE on the DE-to-network relay path based on the RLC status report, or
2) receiving a PDCP status report from the first DE, wherein the PDCP status report
indicates that the PDCP PDD has been successfully received by the first DE via the DE-to-network
relay path; and
determining that the PDCP PDD has been successfully delivered to the first DE on the DEto-
network relay path based on the PDCP status report, or
…
However, Wang et al. further teaches a status report capability which includes:
wherein
determining that the PDCP PDD has been successfully delivered to the first DE via the relay DE
on the DE-to-network relay path comprises:
llreceiving a RLC status report from the relay DE, wherein the RLC status report indicates
that the PDCP PDD has been successfully transmitted to the relay DE in a Du link; and
determining that the PDCP PDD has been successfully delivered to the first DE via the
relay DE on the DE-to-network relay path based on the RLC status report, or
2) receiving a PDCP status report from the first DE, wherein the PDCP status report
indicates that the PDCP PDD has been successfully received by the first DE via the DE-to-network
relay path; and
determining that the PDCP PDD has been successfully delivered to the first DE on the DEto-
network relay path based on the PDCP status report, or
…
(“FIG. 4 is a schematic diagram of downlink data packet transmission according to an embodiment. As shown in FIG. 4, packet loss may also occur in the transmission of downlink data. After the relay (relay 1) sends the packet 1 to the UE1, the quality of the PC5 link between the relay and the UE1 suddenly deteriorates or RLF occurs, and the packets 2 and 4 are still cached in the relay and not sent to the UE1, because the first packet submitted to the Uu interface for transmission by the base station is the packet 3, packet loss will occur, and the UE1 fails to receive the packet 2. In this case, this embodiment adopts the following methods to ensure lossless transmission between the base station and the UE1 during path switch.
[0064] Method One: In response to the UE1 instructing the base station to perform path switch or the base station making a decision to instruct the UE1 to perform path switch, the UE1 sends a PDCP status report for downlink data to the base station through the Uu interface, and the base station retransmits the unacknowledged data packets indicated in the PDCP status report. The acknowledged data packets do not need to be sent repeatedly.
[0065] Method Two: In response to the relay detecting that RLF occurs at the PC5 interface with the UE1, the relay sends instruction information to the base station through an RRC message (such as FailureInformation, or sidelinkUElnformation, or other uplink RRC messages), and informs the base station of PDCP SNs of data packets at the relay which have not been forwarded to the UE1 or have been forwarded but no acknowledgement feedback indication is received from the UE1.”; Wang et al.; 0063-0065)
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the status report capability of Wang et al. into Song et al. By modifying the processing/communications of Song et al. to include the status report capability as taught by the processing/communications of Wang et al. with the packet/PDU teaching of Palat et al., the benefits of improved packet duplication transmission (Song et al.; 0179) with improved reliability (Wang et al.; 0004) are achieved.
Claim(s) 5 and 40 is/are rejected under 35 U.S.C. 103 as being unpatentable over Song et al. US 20220232402 in view of Wang et al. US 20230074899 and in further view of Palat et al. US 20230189380 and Di Girolamo et al. US 20240187140.
As to claim 5:
Song et al. as described above does not explicitly teach:
wherein the PDCP status report is received from the network node when at least one of:
an upper layer requests a PDCP entity re-establishment,
an upper layer requests a PDCP data recovery,
an upper layer requests a uplink data switching,
an upper layer reconfigures a PDCP entity to release dual active protocol stack (DAPS) and
daps-SourceRelease is configured in upper layer,
…
However, DiGirolamo et al. further teaches a PDCP status capability which includes:
wherein the PDCP status report is received from the network node when at least one of:
an upper layer requests a PDCP entity re-establishment,
an upper layer requests a PDCP data recovery,
an upper layer requests a uplink data switching,
an upper layer reconfigures a PDCP entity to release dual active protocol stack (DAPS) and
daps-SourceRelease is configured in upper layer,
…
(“Techniques for sending a PDCP status report are described herein, which provides solutions to Problem 4 described above. After a handover, the UE may be missing certain PDCP SDUs. For services requiring reliability and service continuity, the receiving entity may send a PDCP status report to the transmitting entity so that the transmitting entity may be aware of which PDCP SDUs requiring retransmission. According to TS38.323, for AM DRBs configured by upper layers to send a PDCP status report, the receiving PDCP entity may trigger a PDCP status report when: [0463] Upper layer requests a PDCP entity re-establishment; [0464] Upper layer requests a PDCP data recovery; [0465] Upper layer requests an uplink data switching; [0466] Upper layer reconfigures the PDCP entity to release DAPS and daps-SourceRelease may be configured as described in TS 38.331.”; Di Girolamo et al.; 0462)
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the PDCP status capability of Di Girolamo et al. into Song et al. By modifying the processing/communications of Song et al. to include the PDCP status capability as taught by the processing/communications of Di Girolamo et al., the benefits of improved packet duplication transmission (Song et al.; 0179) with improved reliability (DiGirolamo et al.; 0248) are achieved.
As to claim 40:
Song et al. as described above does not explicitly teach:
wherein the PDCP status report is received from the network node when at least one of:
an upper layer requests a PDCP entity re-establishment,
an upper layer requests a PDCP data recovery,
an upper layer requests a uplink data switching,
an upper layer reconfigures a PDCP entity to release dual active protocol stack (DAPS) and
daps-SourceRelease is configured in upper layer,
…
However, DiGirolamo et al. further teaches a PDCP status capability which includes:
wherein the PDCP status report is received from the network node when at least one of:
an upper layer requests a PDCP entity re-establishment,
an upper layer requests a PDCP data recovery,
an upper layer requests a uplink data switching,
an upper layer reconfigures a PDCP entity to release dual active protocol stack (DAPS) and
daps-SourceRelease is configured in upper layer,
…
(“Techniques for sending a PDCP status report are described herein, which provides solutions to Problem 4 described above. After a handover, the UE may be missing certain PDCP SDUs. For services requiring reliability and service continuity, the receiving entity may send a PDCP status report to the transmitting entity so that the transmitting entity may be aware of which PDCP SDUs requiring retransmission. According to TS38.323, for AM DRBs configured by upper layers to send a PDCP status report, the receiving PDCP entity may trigger a PDCP status report when: [0463] Upper layer requests a PDCP entity re-establishment; [0464] Upper layer requests a PDCP data recovery; [0465] Upper layer requests an uplink data switching; [0466] Upper layer reconfigures the PDCP entity to release DAPS and daps-SourceRelease may be configured as described in TS 38.331.”; Di Girolamo et al.; 0462)
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the PDCP status capability of Di Girolamo et al. into Song et al. By modifying the processing/communications of Song et al. to include the PDCP status capability as taught by the processing/communications of Di Girolamo et al., the benefits of improved packet duplication transmission (Song et al.; 0179) with improved reliability (DiGirolamo et al.; 0248) are achieved.
Claim(s) 10 is/are rejected under 35 U.S.C. 103 as being unpatentable over Song et al. US 20220232402 in view of Wang et al. US 20230074899 and in further view of Palat et al. US 20230189380 and Pradas et al. US 20200235869.
As to claim 10:
Song et al. as described above does not explicitly teach:
receiving a third signaling from the network node, wherein the third signaling indicates deactivation of PDCP duplication of the uplink radio bearer; and performing at least one of:
deactivating the PDCP duplication for the uplink radio bearer;
…
However, Pradas et al. further teaches a deactivation capability which includes:
receiving a third signaling from the network node, wherein the third signaling indicates deactivation of PDCP duplication of the uplink radio bearer; and performing at least one of:
deactivating the PDCP duplication for the uplink radio bearer;
…
(“Duplication of UL PDCP PDUs will take a considerable amount of resources in the network and, therefore, activation/deactivation should be fully in control of the network. From this angle, the beat alternatives to control this feature may be RRC or PDCP. According to certain embodiments: [0074] PDCP Control Command can activate deactivate UL (DRB) data duplication. [0075] Once an PDCP duplication has been activated, the UE should deliver the same PDCP PDUs to both RLC entities. [0076] Once an PDCP duplication has been deactivated, the UE should not deliver the same PDCP PDUs to both RLC entitles. [0077] Any (duplicated) data in (RLS/MAC) lower layers should be unaffected by the PDCP duplication activation/deactivation.”; Pradas et al.; 0073)
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the deactivation capability of Pradas et al. into Song et al. By modifying the processing/communications of Song et al. to include the deactivation capability as taught by the processing/communications of Pradas et al., the benefits of improved packet duplication transmission (Song et al.; 0179) with improved communication (Pradas et al.; Abstract) are achieved.
Claim(s) 10 is/are rejected under 35 U.S.C. 103 as being unpatentable over Song et al. US 20220232402 in view of Wang et al. US 20230074899 and in further view of Palat et al. US 20230189380 and Fujishiro US 20240163767.
As to claim 10:
Song et al. as described above does not explicitly teach:
…
2) receiving a fifth signaling from the network node, wherein the fifth signaling indicates deactivation of PDCP duplication of the uplink radio bearer for at least one sidelink RLC entity;
and
performing at least one of:
discarding at least one third duplicated PDCP PDU and/or RLC SDU associated with the uplink radio bearer of the at least one RLC entity
…
However, Fujishiro further teaches a deactivation capability which includes:
…
2) receiving a fifth signaling from the network node, wherein the fifth signaling indicates deactivation of PDCP duplication of the uplink radio bearer for at least one sidelink RLC entity;
and
performing at least one of:
discarding at least one third duplicated PDCP PDU and/or RLC SDU associated with the uplink radio bearer of the at least one RLC entity
…
(“Returning to FIG. 13, in step S63, the gNB 200 may configure to activate or deactivate the inter-UE split bearer. This configuration may be performed by using an RRC message, MAC CE, or DCI. The configuration may be activation or deactivation of an SL DRB. In this case, the inter-UE split bearer may be activated (or turned on) by activating the SL DRB. The inter-UE split bearer may be deactivated (or turned off) by deactivating the SL DRB. Note that, when SL-Radio Link Failure (RLF) occurs in PC5 connection or when PC-5RRC connection is released between the UE 100-1 and the UE 100-2, the inter-UE split bearer may be (automatically) deactivated. Alternatively, in this case, the establishment of the inter-UE split bearer may be (automatically) de-configured.”; Fujishiro; 0150)
(“In step S45, the UE 100-2 assumes that transmission of the packet has been completed. The UE 100-2 may assume that transmission of packets (PDCP PDUs) up to the PDCP SN has been completed. For example, in response to the reception of the PDCP SN, the synchronized PDCP entity 150-2 of the UE 100-2 may assume that transmission of the packet has been completed even when transmission of the packet is not completed or when the packet is not transmitted. Note that the upper layer (the RRC entity or the synchronized PDCP entity 150-2) of the UE 100-2 may notify the lower layer of completed transmission of the packet. In this case, the synchronized PDCP entity 150-2 may discard the packet received from the application layer. In this case, the lower layer (the RLC entity or the MAC entity) of the UE 100-2 may discard the packet upon receiving the completed transmission.”; Fujishiro; 0115)
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the deactivation capability of Fujishiro into Song et al. By modifying the processing/communications of Song et al. to include the deactivation capability as taught by the processing/communications of Fujishiro, the benefits of improved packet duplication transmission (Song et al.; 0179) with improved reception (Fujishiro; 0092) are achieved.
Claim(s) 29 is/are rejected under 35 U.S.C. 103 as being unpatentable over Song et al. US 20220232402 in view of Wang et al. US 20230074899 and in further view of Palat et al. US 20230189380 and Rao et al. US 20240187935.
As to claim 29:
Song et al. as described above does not explicitly teach:
…
2) receiving a signaling comprising an identifier of the first DE from the network node,
wherein the signaling indicates deactivating at least one RLC entity of the uplink radio bearer in
the DE-to-network relay path; and
deactivating at least one RLC entity of the uplink radio bearer in the DE-to-network relay
However, Rao et al. further teaches a deactivation capability which includes:
…
2) receiving a signaling comprising an identifier of the first DE from the network node,
wherein the signaling indicates deactivating at least one RLC entity of the uplink radio bearer in
the DE-to-network relay path; and
deactivating at least one RLC entity of the uplink radio bearer in the DE-to-network relay
(“Regarding indication/information from the remote WTRU, in an example, the relay WTRU may receive the semi-static information on expected QoS from the (source) remote WTRU from which the E2E radio bearers may be configured. The expected QoS may be indicated to the relay WTRU upon performing the E2E QoS splitting in the first and subsequent hop(s), for example. When relaying in UL, the remote WTRU may estimate/measure the QoS expenditure over the PC5 link, and, based on the awareness of E2E QoS, the remote WTRU may indicate the information on expected QoS (e.g., per RLC channel) to the relay WTRU for changing the configuration at egress RLC channels, for example. The relay WTRU may trigger an action (e.g., determining LCH/MAC configuration), described in the embodiments herein, based on the indication/information received from remote WTRU, for example.”; Rao et al.; 0103)
(“Regarding dynamic activation/deactivation of one or more configured or preconfigured LCH/MAC configurations based on a condition, for example, a relay WTRU may receive an activation and/or deactivation of one or more configured or preconfigured RLC configurations from the network and/or remote WTRU and may apply the activated RLC channel configuration. In another example, the one or more LCH/MAC may be dynamically activated/deactivated by the relay WTRU based on an indication received from the network (e.g., in RRC signaling, MAC CE or DCI) and/or remote WTRU (e.g., in PC5-RRC signaling, adaptation layer control, SL MAC CE, or SCI). In this case, the indication may contain the identifier/ID of the LCH/MAC configured or preconfigured to be activated/deactivated. The relay WTRU may receive the activation/deactivation indication based on other indications sent by the network/remote WTRU, which may contain information on the expected QoS and/or loading attributes associated with the RLC channels, for example.”; Rao et al.; 0122)
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the deactivation capability of Rao et al. into Song et al. By modifying the processing/communications of Song et al. to include the deactivation capability as taught by the processing/communications of Rao et al., the benefits of improved packet duplication transmission (Song et al.; 0179) with improved functionality (Rao et al.; 0066) are achieved.
Claim(s) 45 is/are rejected under 35 U.S.C. 103 as being unpatentable over Song et al. US 20220232402 in view of Wang et al. US 20230074899 and in further view of Palat et al. US 20230189380 and Tseng et al. US 20180332501.
As to claim 45:
Song et al. as described above does not explicitly teach:
determining to deactivate the PDCP duplication of the downlink radio bearer;
performing at least one of:
deactivating the PDCP duplication of the downlink radio bearer;
…
However, Tseng et al. further teaches a deactivation capability which includes:
determining to deactivate the PDCP duplication of the downlink radio bearer;
performing at least one of:
deactivating the PDCP duplication of the downlink radio bearer;
…
(“FIG. 1 is a block diagram of a three-stage control scheme for the configuration, activation and deactivation of PDCP PDU duplication (hereinafter “Duplication”) and/or TB repetition (hereinafter “Repetition”) in a radio access network (RAN), according to an exemplary implementation of the present application. As shown in FIG. 1, a three-stage control scheme 100 includes Stage 101 for RAN configuration, Stage 102 for RAN activation, and Stage 103 for RAN implementation. It should be noted that although FIG. 1 shows a three-stage control scheme based on uplink (UL) operations, the control schemes according to implementations of the present application are not limited to UL operations. That is, the three-stage control scheme 100 according to implementations of the present application may apply to downlink (DL) operations and sidelink (SL) operations as well.”; Tseng et al.; 0039)
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the deactivation capability of Tseng et al. into Song et al. By modifying the processing/communications of Song et al. to include the deactivation capability as taught by the processing/communications of Tseng et al., the benefits of improved packet duplication transmission (Song et al.; 0179) with improved PDCP (Tseng et al.; Abstract) are achieved.
Allowable Subject Matter
Claim(s) 11, 13, 15, 18, 25, 31, 47 and 50 is/are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Examiner Notes
Claim 46 does not have a prior art rejection.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
US 20200404696 – teaches PDCP status reporting and duplicated discard (see para. 0087).
US 20220216948 - teaches PDCP status reporting and duplicated discard (see para. 0100 and Abstract).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MICHAEL K PHILLIPS whose telephone number is (571)272-1037. The examiner can normally be reached M-F 8am-10am, 1pm-5pm.
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, Ricky Ngo can be reached on 571-272-3139. 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.
MICHAEL K. PHILLIPS
Examiner
Art Unit 2464
/MICHAEL K PHILLIPS/Examiner, Art Unit 2464
Prosecution Insights