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 .
Specification
The specification amendment submitted on 02/19/2024 which amended the title has been accepted.
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.
Claims 16-33 are 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.
Claim 16 recites “a first SN” in line 9. It is unclear whether or not it is referring to “one secondary node (SN)” in line 6. For the purpose of examination, examiner will interpret the claim as best understood.
Claim 16 recites “a current serving SN” in line 12. It is unclear whether or not it is referring to “multiple SNs” in line 7. For the purpose of examination, examiner will interpret the claim as best understood.
Claim 26 recites “a first SN” in line 9. It is unclear whether or not it is referring to “one secondary node (SN)” in line 6. For the purpose of examination, examiner will interpret the claim as best understood.
Claim 26 recites “a current serving SN” in line 10. It is unclear whether or not it is referring to “multiple SNs” in line 5. For the purpose of examination, examiner will interpret the claim as best understood.
Claims 17-25 and 27-33 are also rejected since they are depended on the rejected claims set forth above.
Claim Rejections - 35 USC § 102
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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale or otherwise available to the public before the effective filing date of the claimed invention.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 16-34 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Teyeb et al. (US 2020/0053815 A1, hereinafter “Teyeb”).
Regarding claims 16 and 26, Teyeb discloses a network apparatus for wireless communication [see Fig. 11, para. 56, 153-164; network node 1160], comprising:
at least one memory [see Fig. 11, para. 157-158; memory 1180]; and
at least one processor coupled with the at least one memory and configured to cause the network apparatus to [see Fig. 11, para. 155-157; processor 1170 coupled with the memory 1180 and configured to cause the network node to]:
determine whether to support a first quality of service (QOS) flow terminated at one secondary node (SN) or whether to support a second QoS flow terminated at multiple SNs simultaneously [see para. 53-55; see Fig. 7, para. 103-116; determine whether to support a first QOS flow terminated at one SN];
determine, in response to supporting the first QoS flow, that the first QoS flow is terminated at a first SN and the first QoS flow uses a radio resource of a secondary cell group (SCG) at a second SN [see Fig. 7, para. 104-105; determine, in response to supporting the first QoS flow, that the first QoS flow is SN-terminated and the first QoS flow uses a radio resource of a SCG at a SN]; and
transmit, in response to supporting the second QoS flow, information regarding a current serving SN of the second QoS flow to a core network (CN) node [see Fig. 7, step 9, para. 109; MN transmits PDU Session Modification Indication to the core network; see para. 124, Table 8; PDU Session Resource Modification Info: QoS flows to be setup list, DL forwarding, QoS flows to be modified list, QoS flows to be released list; see Fig. 10, step 1030, para. 142-146; transmit, in response to supporting a second QoS flow, information regarding a current serving SN of the second QoS flow to a core network].
Regarding claims 17 and 27, Teyeb discloses wherein the at least one processor is configured to cause the network apparatus to: transmit, in response to supporting the first QoS flow, a request to the second SN [see Fig. 7, step 1, para. 103-116; MN transmit SN addition request to SN], wherein the request includes at least one of: information related to the first QoS flow; a packet data convergence protocol (PDCP) parameter related to the first QoS flow; a radio link control (RLC) parameter related to the first QoS flow; or uplink (UL) user plane (UP) transport network layer (TNL) information of the first SN [see para. 104; the request includes QoS Flows characteristics (QoS Flow Level QoS parameters, PDU session level transport network layer (TNL) address information, and PDU session level Network Slice info)].
Regarding claims 18 and 28, Teyeb discloses wherein the UL UP TNL information includes at least one of: a cell group identifier (ID) of the first SN; a transport layer address of the first SN; or a general packet radio service (GPRS) tunnelling protocol tunnel endpoint identifier (GTP-TEID) of the first SN [see para. 104; a GPRS Tunneling Protocol (GTP) Tunnel Endpoint Identifier (TEID) and a TNL Internet Protocol (IP) address].
Regarding claims 19 and 29, Teyeb discloses wherein the at least one processor is configured to cause the network apparatus to: receive, in response to supporting the first QoS flow, a response from the second SN [see Fig. 7, step 2, para. 103-116; MN receive SN Addition Request Acknowledge (carry SN RRC configuration message) from the SN], wherein the response includes at least one of: radio resource control (RRC) configuration information generated by the second SN; or downlink (DL) user plane (UP) transport network layer (TNL) information of the second SN [see para. 106; The SN provides the new SCG radio resource configuration to the MN in a SN RRC configuration message contained in the SN Addition Request Acknowledge message. In case of bearer options that require Xn-U resources between the MN and the SN, the SN provides Xn-U TNL address information for the respective E-RAB, Xn-U UL TNL address information for SN-terminated bearers, Xn-U DL TNL address information for MN terminated bearers. For SN-terminated bearers, the SN provides the NG-U DL TNL address information for the respective PDU Session and security algorithm].
Regarding claims 20 and 30, Teyeb discloses wherein the DL UP TNL information includes at least one of: a cell group identifier (ID) of the second SN; a transport layer address of the second SN; and a general packet radio service (GPRS) tunnelling protocol tunnel endpoint identifier (GTP-TEID) of the second SN [see para. 106; The SN provides the new SCG radio resource configuration to the MN in a SN RRC configuration message contained in the SN Addition Request Acknowledge message. In case of bearer options that require Xn-U resources between the MN and the SN, the SN provides Xn-U TNL address information for the respective E-RAB, Xn-U UL TNL address information for SN-terminated bearers, Xn-U DL TNL address information for MN terminated bearers. For SN-terminated bearers, the SN provides the NG-U DL TNL address information for the respective PDU Session and security algorithm].
Regarding claims 21 and 31, Teyeb discloses wherein the information regarding the current serving SN of the second QoS flow is included in a packet data unit (PDU) session resource modify indication message [see Fig. 7, step 9, para. 109; MN transmits PDU Session Modification Indication to the core network].
Regarding claims 22 and 32, Teyeb discloses wherein the information regarding the current serving SN of the second QoS flow includes at least one of: downlink (DL) address information of a SN within the multiple SNs; information regarding a QoS flow associated with the SN within the multiple SNs; or an indication for indicating whether the SN within the multiple SNs is the current serving SN [see Fig. 7, steps 9-12, Path Update Procedure; see para. 124, Table 8; PDU Session Resource Modification Info: QoS flows to be setup list, DL forwarding, QoS flows to be modified list, QoS flows to be released list].
Regarding claims 23 and 33, Teyeb discloses wherein the at least one processor is configured to cause the network apparatus to: decide, in response to supporting the second QoS flow, to switch a user equipment (UE) from the current serving SN to a third SN within the multiple SNS, wherein the third SN is a next serving SN after switching the UE [see Fig. 7, steps 3-12, para. 12, 97, 107-109; MN decide to switch a UE from current serving SN to a next serving SN].
Regarding claim 24, Teyeb discloses wherein the at least one processor is configured to cause the network apparatus to: transmit, in response to deciding to switch the UE from the current serving SN to the third SN, information regarding the third SN to the CN node [see Fig. 7, Path Update Procedure, step 9, para. 109; MN transmits PDU Session Modification Indication to the core network; see para. 124, Table 8; PDU Session Resource Modification Info: QoS flows to be setup list, DL forwarding, QoS flows to be modified list, QoS flows to be released list].
Regarding claim 25, Teyeb discloses wherein the at least one processor is configured to cause the network apparatus to: transmit, in response to supporting the second QoS flow, information regarding one or more non-serving SNs within the multiple SNs to the current serving SN [see Fig. 7, steps 5, 7, para. 107-109; MN transmits SN Reconfiguration complete and SN status transfer to the SN].
Regarding claim 34, Teyeb discloses A first secondary node (SN) for wireless communication [see Fig. 11, para. 56, 153-164; network node 1160], comprising:
at least one memory [see Fig. 11, para. 157-158; memory 1180]; and
at least one processor couple with the at least one memory and configured to cause the first SN to [see Fig. 11, para. 155-157; processor 1170 coupled with the memory 1180 and configured to cause the network node to]:
determine whether to support a quality of service (QOS) flow terminated at an SN [see para. 53-55; see Fig. 7, para. 103-116; determine whether to support a QOS flow terminated at an SN (SN-terminated)];
transmit, in response to supporting the QoS flow, data forwarding address information of the first SN and configuration information of the first SN [see Fig. 7, para. 103, 106; transmit SN Addition Request Acknowledge (carry SN RRC configuration message) including Xn-U TNL address information for the respective E-RAB, Xn-U UL TNL address information for SN-terminated bearers, Xn-U DL TNL address information for MN terminated bearers, and the NG-U DL TNL address information for the respective PDU Session and security algorithm]; and
receive, in response to supporting the QoS flow, data forwarding address information of a second SN and configuration information related to a radio resource of a secondary cell group (SCG) at the second SN [see Fig. 7, para. 103-105; receive SN Addition Request including QoS Flows characteristics (QoS Flow Level QoS parameters, PDU session level transport network layer (TNL) address information, and PDU session level Network Slice info), a GPRS Tunneling Protocol (GTP) Tunnel Endpoint Identifier (TEID) and a TNL Internet Protocol (IP) address, the requested SCG configuration information, including the entire UE capabilities and the UE capability coordination result].
Claims 34-35 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Yilmaz et al. (US 2022/0141904 A1, hereinafter “Yilmaz”).
Regarding claim 34, Yilmaz discloses A first secondary node (SN) for wireless communication [see Fig. 10, 28a, para. 96-108, 665-669; SN], comprising:
at least one memory; and at least one processor couple with the at least one memory and configured to cause the first SN to [see Fig. 10, 28a, para. 96-108, 665-669; memory coupled with processor]:
determine whether to support a quality of service (QOS) flow terminated at an SN [see Fig. 10, para. 96-108; determine whether to support a QOS flow terminated at an SN];
transmit, in response to supporting the QoS flow, data forwarding address information of the first SN and configuration information of the first SN [see Fig. 10, para. 96-108; The source SN initiates the SN change procedure by sending the SN Change Required message, which contains a candidate target node ID and may include the SCG configuration (to support delta configuration) and measurement results related to the target SN]; and
receive, in response to supporting the QoS flow, data forwarding address information of a second SN and configuration information related to a radio resource of a secondary cell group (SCG) at the second SN [see Fig. 10, para. 96-108; If the allocation of target SN resources was successful, the MN confirms the change of the source SN. If data forwarding is needed the MN provides data forwarding addresses to the source SN. If direct data forwarding is used for SN terminated bearers, the MN provides data forwarding addresses as received from the target SN to source SN. Reception of the SN Change Confirm message triggers the source SN to stop providing user data to the UE and, if applicable, to start data forwarding].
Regarding claim 35, Yilmaz discloses A first secondary node (SN) for wireless communication [see Fig. 9, 28a, para. 82-95, 665-669; S-SN], comprising:
at least one memory; and at least one processor couple with the at least one memory and configured to cause the first SN to [see Fig. 9, 28a, para. 82-95, 665-669; memory coupled with processor]:
receive, from a master node (MN), configuration information for supporting a quality of service (QOS) flow [see Fig. 9, para. 82-95; receive, from MN, SN Release Request including configuration information for supporting a QoS flow];
determine whether the first SN is a current serving SN of the QoS flow [see para. 82-95; determine whether the S-SN is a current serving SN of the QoS flow]; and
determine, in response to the first SN being the current serving SN, whether to switch a user equipment (UE) from the first SN to a second SN, wherein the second SN is a next serving SN after switching the UE [see Fig. 9, para. 82-95; determine, in response to the S-SN being the current serving SN, whether to switch UE from the S-SN to T-SN, wherein the T-SN is a next serving SN after switching the UE].
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Ma et al. (US 2022/0232413 A1), discloses obtaining first redundancy indication information for establishing or modifying the PDU session and/or a QoS flow; and configuring the redundant PDU session and/or a redundant QoS flow on a corresponding RAN node, according to the first redundancy indication information.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to BRIAN T LE whose telephone number is (571)270-5615. The examiner can normally be reached on M-F 9AM-6PM.
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, JAE LEE can be reached on 571-270-3936. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/BRIAN T LE/Primary Examiner, Art Unit 2469