DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Amendment
Applicant’s amendment filed on April 6, 2026 has been entered. Claims 1, 3-4, 8, 21 and 23-24 have been amended. Claims 11-20 were previously canceled. Claims 2 and 22 are newly canceled. No claims have been added. Claims 1, 3-10, 21 and 23-30 are still pending in this application, with claims 1 and 21 being independent.
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.
Claims 1, 3, 21 and 23 are rejected under 35 U.S.C. 103 as being unpatentable over Starsinic et al. (U.S. PGPub 2025/0113395), hereinafter referred to as Starsinic.
Regarding claim 1, Starsinic discloses a method comprising:
determining application traffic is associated with a user equipment (UE) route selection policy (URSP) rule (the WTRU evaluates the URSP rules in the order of Rule Precedence and determines if the application matches the Traffic descriptor of any URSP rule. When a URSP rule is determined to be applicable for a given application, the WTRU will select a Route Selection Descriptor within this URSP rule in the order of the Route Selection Descriptor Precedence; See [0142]) that includes an offload guidance parameter (Each URSP rule consists of 2 parts. The first part of the URSP rule is a Traffic descriptor that is used to determine when the rule is applicable. A URSP rule is determined to be applicable when every component in the Traffic descriptor matches the corresponding information from the application. The second part of the URSP rule is a list of Route Selection Descriptors (RSD). The list of Route Selection Descriptors contains one or more Route Selection Descriptors. The RSDs are listed in priority order and describe the characteristics of a PDU Session that may be used to carry the uplink application data; See [0141]);
associating the application traffic to a protocol data unit (PDU) session based on the URSP rule (When a valid Route Selection Descriptor is found, the WTRU determines if there is an existing PDU Session that matches all components in the selected Route Selection Descriptor; See [0143]);
receiving, from a network, a PDU session establishment or modification accept message that includes an edge data network (DN) indication (According to an embodiment, if the information in the PDU Session Establishment request is associated with an edge data network, the SMF may include an Edge-Services-Indication in the PDU Session Establishment Accept message; See [0211]);
determining, based on the edge DN indication, the PDU session is to be serviced by an edge application server (The inclusion of this notification from the SMF will serve as a warning, or an indication, to the WTRU that the PDU Session may be used to access edge services and this warning will be considered by the WTRU when determining whether to use non-seamless WLAN offloading for any traffic that is associated with the PDU Session; See [0211]);
identifying offload restrictions based on the offload guidance parameter and said determining that the PDU session is to be serviced by the edge application server (When the Edge-Services-Indication is associated with a PDU Session and/or traffic that matches a traffic descriptor, the WTRU may use this indication as a hint that the associated PDU Session may be used to access services that are only available in an edge data network and that abruptly switching the associated application traffic to a different PDU session or terminating the PDU session may impact any user experience that is associated with the application traffic; See [0170]);
detecting an offloading connectivity option for application traffic (the WTRU determines that non-seamless offloading is available; See [0208]); and
selecting or discarding the offloading connectivity option based on the offload restrictions (the WTRU takes action to handle the edge routed traffic (i.e. determine to terminate the application traffic, attempt to move the traffic to non-seamless offloading, or keep the traffic in the 5G System); See [0209]).
Regarding claim 3, Starsinic further discloses the method of claim 2, wherein the offload restrictions prevent offloading the application traffic based on the edge application server servicing the PDU session (When the Edge-Services-Indication is associated with a PDU Session and/or traffic that matches a traffic descriptor, the WTRU may use this indication as a hint that the associated PDU Session may be used to access services that are only available in an edge data network and that abruptly switching the associated application traffic to a different PDU session or terminating the PDU session may impact any user experience that is associated with the application traffic; See [0170]).
Regarding claim 21, Starsinic discloses an apparatus (WTRU; See Fig. 1B, #102) comprising:
memory (non-removable memory; See Fig. 1B, #130) to store a user equipment (UE) route selection policy (URSP) rule (the WTRU evaluates the URSP rules in the order of Rule Precedence and determines if the application matches the Traffic descriptor of any URSP rule. When a URSP rule is determined to be applicable for a given application, the WTRU will select a Route Selection Descriptor within this URSP rule in the order of the Route Selection Descriptor Precedence; See [0142]) that includes an offload guidance parameter (Each URSP rule consists of 2 parts. The first part of the URSP rule is a Traffic descriptor that is used to determine when the rule is applicable. A URSP rule is determined to be applicable when every component in the Traffic descriptor matches the corresponding information from the application. The second part of the URSP rule is a list of Route Selection Descriptors (RSD). The list of Route Selection Descriptors contains one or more Route Selection Descriptors. The RSDs are listed in priority order and describe the characteristics of a PDU Session that may be used to carry the uplink application data; See [0141]); and
processing circuitry coupled with the memory (processor; See Fig. 1B, #118), the processing circuitry to
determine application traffic is associated with the URSP rule ();
associate the application traffic to a protocol data unit (PDU) session based on the URSP rule (When a valid Route Selection Descriptor is found, the WTRU determines if there is an existing PDU Session that matches all components in the selected Route Selection Descriptor; See [0143]);
determine, based on an edge data network (DN) indication from a network in a PDU session establishment or modification accept message, the PDU session is to be served by an edge application server (According to an embodiment, if the information in the PDU Session Establishment request is associated with an edge data network, the SMF may include an Edge-Services-Indication in the PDU Session Establishment Accept message; See [0211]);
identify offload restrictions based on the offload guidance parameter and determination that the PDU session is to be serviced by the edge application server (When the Edge-Services-Indication is associated with a PDU Session and/or traffic that matches a traffic descriptor, the WTRU may use this indication as a hint that the associated PDU Session may be used to access services that are only available in an edge data network and that abruptly switching the associated application traffic to a different PDU session or terminating the PDU session may impact any user experience that is associated with the application traffic; See [0170]);
detect an offloading connectivity option for application traffic (the WTRU determines that non-seamless offloading is available; See [0208]); and
select or discard the offloading connectivity option based on the offload restrictions (the WTRU takes action to handle the edge routed traffic (i.e. determine to terminate the application traffic, attempt to move the traffic to non-seamless offloading, or keep the traffic in the 5G System); See [0209]).
Regarding claim 23, Starsinic further discloses the apparatus of claim 22, wherein the offload restrictions prevent offloading the application traffic based on the edge application server servicing the PDU session (When the Edge-Services-Indication is associated with a PDU Session and/or traffic that matches a traffic descriptor, the WTRU may use this indication as a hint that the associated PDU Session may be used to access services that are only available in an edge data network and that abruptly switching the associated application traffic to a different PDU session or terminating the PDU session may impact any user experience that is associated with the application traffic; See [0170]).
Claims 4-5 and 24-25 are rejected under 35 U.S.C. 103 as being unpatentable over Starsinic as applied to claims 1 and 21 above, and further in view of Youn et al. (U.S. PGPub 2024/0015562), hereinafter referred to as Youn.
Regarding claim 4, Starsinic fails to teach the method of claim 1, wherein the PDU session establishment or modification accept message further includes measurement assistance information and the method further comprises: determining one or more round trip time (RTT) measurements on Third Generation Partnership Project (3GPP) access or non-3GPP access based on the measurement assistance information.
Youn teaches wherein the PDU session establishment or modification accept message further includes measurement assistance information (When the MA PDU session is established, the network may provide Measurement Assistance Information to the UE; See [0252]) and the method further comprises:
determining one or more round trip time (RTT) measurements on Third Generation Partnership Project (3GPP) access or non-3GPP access based on the measurement assistance information (PMF protocol messages such as the following examples may be exchanged between the UE and the PMF: Messages can be exchanged allowing Round Trip Time (RTT) measurements. For example, if a “Smallest Delay” Steering Mode is used, messages allowing RTT measurements may be exchanged; See [0258]-[0259]).
Therefore it would have been obvious to one of ordinary skill in the art at the time before the effective filing date of the invention, to modify the method of Starsinic to include wherein the PDU session establishment or modification accept message further includes measurement assistance information and the method further comprises: determining one or more round trip time (RTT) measurements on Third Generation Partnership Project (3GPP) access or non-3GPP access based on the measurement assistance information taught by Youn in order to enhance QoS in multi-access PDU sessions.
Regarding claim 5, Starsinic still fails to teach the method of claim 4, wherein the measurement assistance information includes an address of a performance measurement function.
Youn teaches wherein the measurement assistance information includes an address of a performance measurement function (When the MA PDU session is established, the network may provide Measurement Assistance Information to the UE. The measurement assistance information may include addressing information of a Performance Measurement Function (PMF) in UPF; See [0252]-[0253]).
Therefore it would have been obvious to one of ordinary skill in the art at the time before the effective filing date of the invention, to modify the method of Starsinic to include wherein the measurement assistance information includes an address of a performance measurement function taught by Youn in order to enhance QoS in multi-access PDU sessions.
Regarding claim 24, Starsinic fails to teach the apparatus of claim 22, wherein the PDU session establishment or modification accept message further includes measurement assistance information and the processing circuitry is further to: determine one or more round trip time (RTT) measurements on Third Generation Partnership Project (3GPP) access or non-3GPP access based on the measurement assistance information.
Youn teaches wherein the PDU session establishment or modification accept message further includes measurement assistance information (When the MA PDU session is established, the network may provide Measurement Assistance Information to the UE; See [0252]) and the processing circuitry is further to:
determine one or more round trip time (RTT) measurements on Third Generation Partnership Project (3GPP) access or non-3GPP access based on the measurement assistance information (PMF protocol messages such as the following examples may be exchanged between the UE and the PMF: Messages can be exchanged allowing Round Trip Time (RTT) measurements. For example, if a “Smallest Delay” Steering Mode is used, messages allowing RTT measurements may be exchanged; See [0258]-[0259]).
Therefore it would have been obvious to one of ordinary skill in the art at the time before the effective filing date of the invention, to modify the apparatus of Starsinic to include wherein the PDU session establishment or modification accept message further includes measurement assistance information and the processing circuitry is further to: determine one or more round trip time (RTT) measurements on Third Generation Partnership Project (3GPP) access or non-3GPP access based on the measurement assistance information taught by Youn in order to enhance QoS in multi-access PDU sessions.
Regarding claim 25, Starsinic fails to teach the apparatus of claim 24, wherein the measurement assistance information includes an address of a performance measurement function.
Youn teaches wherein the measurement assistance information includes an address of a performance measurement function (When the MA PDU session is established, the network may provide Measurement Assistance Information to the UE. The measurement assistance information may include addressing information of a Performance Measurement Function (PMF) in UPF; See [0252]-[0253]).
Therefore it would have been obvious to one of ordinary skill in the art at the time before the effective filing date of the invention, to modify the apparatus of Starsinic to include wherein the measurement assistance information includes an address of a performance measurement function taught by Youn in order to enhance QoS in multi-access PDU sessions.
Claims 6-8, 10, 26-28 and 30 are rejected under 35 U.S.C. 103 as being unpatentable over Starsinic in view of Youn as applied to claims 4 and 24 above, and further in view of Ly et al. (U.S. PGPub 2023/0413114), hereinafter referred to as Ly.
Regarding claim 6, Starsinic in view of Youn fails to teach the method of claim 4, wherein the PDU session establishment or modification accept message further includes one or more traffic offload rules and the method further comprises: identifying the offload restrictions based on the one or more traffic offload rules.
Ly teaches wherein the PDU session establishment or modification accept message further includes one or more traffic offload rules (In response, the network may return to the UE a status of the request and may include one or more of rules indicating a select steering mode, an adaptive steering mode, or a list of steering modes and the conditions on adapting traffic steering; See [0137]) and the method further comprises:
identifying the offload restrictions based on the one or more traffic offload rules (Traffic steering adaptation rules may be used to communicate conditions in which traffic adaptation may be made by the UE and/or the network. The adaptation rules may be included in a communication to request for enabling adaptive traffic steering, for example, or in a response to grant adaptive traffic steering functionality. The UE and the network can communicate to each other when traffic adaptation is to be performed to signal whether traffic adaptation may be performed for UL only, DL only, or both UL and DL; See [0138] and [0140]).
Therefore it would have been obvious to one of ordinary skill in the art at the time before the effective filing date of the invention, to modify the method of Starsinic in view of Youn to include wherein the PDU session establishment or modification accept message further includes one or more traffic offload rules and the method further comprises: identifying the offload restrictions based on the one or more traffic offload rules taught by Ly in order to address performance measurements from 3GPP and non-3GPP accesses both exceeding configured threshold values by error handling.
Regarding claim 7, Starsinic in view of Youn fails to teach the method of claim 6, further comprising: determining a measurement value based on the one or more the RTT measurements; comparing the measurement value to a threshold; and selecting or discarding the offloading connectivity option based on said comparing of the measurement value to the threshold.
Ly teaches determining a measurement value based on the one or more the RTT measurements (The network may send a PMFP Measurement request, e.g., including a QFI, measurement begin/end indicators, a measurement type, a measurement value, and/or an indication of whether measurement obtained from 3GPP or non-3GPP access; See [0146]), comparing the measurement value to a threshold (the UE and UPF may be allowed by network to determine how to proceed, based on comparison of difference between measurement and threshold value for each access (3GPP and non-3GPP); See [0147]), and selecting or discarding the offloading connectivity option based on said comparing of the measurement value to the threshold (whichever access has smaller difference is the access the UE/UPF should use; See [0147]).
Therefore it would have been obvious to one of ordinary skill in the art at the time before the effective filing date of the invention, to modify the apparatus of Starsinic in view of Youn to include determining a measurement value based on the one or more the RTT measurements; comparing the measurement value to a threshold; and selecting or discarding the offloading connectivity option based on said comparing of the measurement value to the threshold taught by Ly in order to address performance measurements from 3GPP and non-3GPP accesses both exceeding configured threshold values by error handling.
Regarding claim 8, Starsinic in view of Youn fails to teach the of claim 7, wherein the one or more RTT measurements includes a first RTT measurement on 3GPP access and a second RTT measurement on non-3GPP access and the measurement value is based on a comparison of the first RTT measurement and the second RTT measurement.
Ly teaches wherein the one or more RTT measurements includes a first RTT measurement on 3GPP access and a second RTT measurement on non-3GPP access and the measurement value is based on a comparison of the first RTT measurement and the second RTT measurement (the UE and UPF may be allowed by network to determine how to proceed, based on comparison of difference between measurement and threshold value for each access (3GPP and non-3GPP); See [0147]).
Therefore it would have been obvious to one of ordinary skill in the art at the time before the effective filing date of the invention, to modify the method of Starsinic in view of Youn to include wherein the one or more RTT measurements includes a first RTT measurement on 3GPP access and a second RTT measurement on non-3GPP access and the measurement value is based on a comparison of the first RTT measurement and the second RTT measurement taught by Ly in order to address performance measurements from 3GPP and non-3GPP accesses both exceeding configured threshold values by error handling.
Regarding claim 10, Starsinic in view of Youn fails to teach the method of claim 7, wherein the measurement assistance information includes an indication of the threshold.
Ly teaches wherein the measurement assistance information includes an indication of the threshold (Performance measurement configuration and exchange may include the network providing measurement assistance information to the UE that includes measurement type indicators (e.g., RTT, PLR), a threshold value; See [0146]).
Therefore it would have been obvious to one of ordinary skill in the art at the time before the effective filing date of the invention, to modify the method of Starsinic in view of Youn to include wherein the measurement assistance information includes an indication of the threshold taught by Ly in order to address performance measurements from 3GPP and non-3GPP accesses both exceeding configured threshold values by error handling.
Regarding claim 26, Starsinic in view of Youn fails to teach the apparatus of claim 24, wherein the PDU session establishment or modification accept message further includes one or more traffic offload rules and the processing circuitry is further to: identify the offload restrictions based on the one or more traffic offload rules.
Ly teaches wherein the PDU session establishment or modification accept message further includes one or more traffic offload rules (In response, the network may return to the UE a status of the request and may include one or more of rules indicating a select steering mode, an adaptive steering mode, or a list of steering modes and the conditions on adapting traffic steering; See [0137]) and the method further comprises:
identifying the offload restrictions based on the one or more traffic offload rules (Traffic steering adaptation rules may be used to communicate conditions in which traffic adaptation may be made by the UE and/or the network. The adaptation rules may be included in a communication to request for enabling adaptive traffic steering, for example, or in a response to grant adaptive traffic steering functionality. The UE and the network can communicate to each other when traffic adaptation is to be performed to signal whether traffic adaptation may be performed for UL only, DL only, or both UL and DL; See [0138] and [0140]).
Therefore it would have been obvious to one of ordinary skill in the art at the time before the effective filing date of the invention, to modify the apparatus of Starsinic in view of Youn to include wherein the PDU session establishment or modification accept message further includes one or more traffic offload rules and the method further comprises: identifying the offload restrictions based on the one or more traffic offload rules taught by Ly in order to address performance measurements from 3GPP and non-3GPP accesses both exceeding configured threshold values by error handling.
Regarding claim 27, Starsinic in view of Youn fails to teach the apparatus of claim 26, wherein the processing circuitry is further to: determine a measurement value based on the one or more the RTT measurements; compare the measurement value to a threshold; and select or discard the offloading connectivity option based on comparison of the measurement value to the threshold.
Ly teaches determining a measurement value based on the one or more the RTT measurements (The network may send a PMFP Measurement request, e.g., including a QFI, measurement begin/end indicators, a measurement type, a measurement value, and/or an indication of whether measurement obtained from 3GPP or non-3GPP access; See [0146]), comparing the measurement value to a threshold (the UE and UPF may be allowed by network to determine how to proceed, based on comparison of difference between measurement and threshold value for each access (3GPP and non-3GPP); See [0147]), and selecting or discarding the offloading connectivity option based on said comparing of the measurement value to the threshold (whichever access has smaller difference is the access the UE/UPF should use; See [0147]).
Therefore it would have been obvious to one of ordinary skill in the art at the time before the effective filing date of the invention, to modify the apparatus of Starsinic in view of Youn to include determining a measurement value based on the one or more the RTT measurements; comparing the measurement value to a threshold; and selecting or discarding the offloading connectivity option based on said comparing of the measurement value to the threshold taught by Ly in order to address performance measurements from 3GPP and non-3GPP accesses both exceeding configured threshold values by error handling.
Regarding claim 28, Starsinic in view of Youn fails to teach the apparatus of claim 27, wherein the one or more RTT measurements includes a first RTT measurement on 3GPP access and a second RTT measurement on non-3GPP access and the measurement value is based on a comparison of the first RTT measurement and the second RTT measurement.
Ly teaches wherein the one or more RTT measurements includes a first RTT measurement on 3GPP access and a second RTT measurement on non-3GPP access and the measurement value is based on a comparison of the first RTT measurement and the second RTT measurement (the UE and UPF may be allowed by network to determine how to proceed, based on comparison of difference between measurement and threshold value for each access (3GPP and non-3GPP); See [0147]).
Therefore it would have been obvious to one of ordinary skill in the art at the time before the effective filing date of the invention, to modify the apparatus of Starsinic in view of Youn to include wherein the one or more RTT measurements includes a first RTT measurement on 3GPP access and a second RTT measurement on non-3GPP access and the measurement value is based on a comparison of the first RTT measurement and the second RTT measurement taught by Ly in order to address performance measurements from 3GPP and non-3GPP accesses both exceeding configured threshold values by error handling.
Regarding claim 30, Starsinic in view of Youn fails to teach the apparatus of claim 27, wherein the measurement assistance information includes an indication of the threshold.
Ly teaches wherein the measurement assistance information includes an indication of the threshold (Performance measurement configuration and exchange may include the network providing measurement assistance information to the UE that includes measurement type indicators (e.g., RTT, PLR), a threshold value; See [0146]).
Therefore it would have been obvious to one of ordinary skill in the art at the time before the effective filing date of the invention, to modify the apparatus of Starsinic in view of Youn to include wherein the measurement assistance information includes an indication of the threshold taught by Ly in order to address performance measurements from 3GPP and non-3GPP accesses both exceeding configured threshold values by error handling.
Claims 9 and 29 are rejected under 35 U.S.C. 103 as being unpatentable over Starsinic in view of Youn and Ly as applied to claims 8 and 28 above, and further in view of Matolia et al. (U.S. PGPub 2021/0289400), hereinafter referred to as Matolia.
Regarding claim 9, Starsinic in view of Youn and Ly fails to teach the method of claim 8, further comprising: determining a UE-to-user plane function (UPF) RTT time; receiving a UPF-to-Application server (AS) RTT time from a session management function (SMF); and adding the UE-to-UPF RTT time to the UPF-to-AS RTT time to determine the first RTT measurement.
Matolia teaches determining a UE-to-user plane function (UPF) RTT time; receiving a UPF-to-Application server (AS) RTT time from a session management function (SMF); and adding the UE-to-UPF RTT time to the UPF-to-AS RTT time to determine the first RTT measurement (periodic latency measurements or RTT between the UE 110, UPF/PSA1 270a and the DN1/EAS1 280a for the currently executed application are performed; See [0057]).
Therefore it would have been obvious to one of ordinary skill in the art at the time before the effective filing date of the invention, to modify the method of Starsinic in view of Youn and Ly to include determining a UE-to-user plane function (UPF) RTT time; receiving a UPF-to-Application server (AS) RTT time from a session management function (SMF); and adding the UE-to-UPF RTT time to the UPF-to-AS RTT time to determine the first RTT measurement taught by Ly in order to address performance measurements from 3GPP and non-3GPP accesses both exceeding configured threshold values by error handling.
Regarding claim 29, Starsinic in view of Youn and Ly fails to teach the apparatus of claim 28, wherein the processing circuitry is further to: determine a UE-to-user plane function (UPF) RTT time; receive a UPF-to-Application server (AS) RTT time from a session management function (SMF); and add the UE-to-UPF RTT time to the UPF-to-AS RTT time to determine the first RTT measurement.
Matolia teaches determining a UE-to-user plane function (UPF) RTT time; receiving a UPF-to-Application server (AS) RTT time from a session management function (SMF); and adding the UE-to-UPF RTT time to the UPF-to-AS RTT time to determine the first RTT measurement (periodic latency measurements or RTT between the UE 110, UPF/PSA1 270a and the DN1/EAS1 280a for the currently executed application are performed; See [0057]).
Therefore it would have been obvious to one of ordinary skill in the art at the time before the effective filing date of the invention, to modify the apparatus of Starsinic in view of Youn and Ly to include determining a UE-to-user plane function (UPF) RTT time; receiving a UPF-to-Application server (AS) RTT time from a session management function (SMF); and adding the UE-to-UPF RTT time to the UPF-to-AS RTT time to determine the first RTT measurement taught by Ly in order to address performance measurements from 3GPP and non-3GPP accesses both exceeding configured threshold values by error handling.
Response to Arguments
Applicant’s arguments, see pages 8-9, filed April 6, 2026, with respect to the rejection(s) of claim(s) 1 and 21 under Salkintzis et al. (U.S. PGPub 2024/0323825), hereinafter referred to as Salkintzis have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made using Starsinic et al. (U.S. PGPub 2025/0113395), hereinafter referred to as Starsinic.
On pages 8-9 of the Applicants’ Response, Applicants state that Salkintzis fails to teach identifying offload restrictions based on the offload guidance parameter and said determining that the PDU session is to be serviced by the edge application server and receiving, from a network, a PDU session establishment or modification accept message that includes an edge data network (DN) indication.
Examiner agrees and has thus introduced Starsinic which teaches receiving, from a network, a PDU session establishment or modification accept message that includes an edge data network (DN) indication (According to an embodiment, if the information in the PDU Session Establishment request is associated with an edge data network, the SMF may include an Edge-Services-Indication in the PDU Session Establishment Accept message; See [0211]) and identifying offload restrictions based on the offload guidance parameter and said determining that the PDU session is to be serviced by the edge application server (When the Edge-Services-Indication is associated with a PDU Session and/or traffic that matches a traffic descriptor, the WTRU may use this indication as a hint that the associated PDU Session may be used to access services that are only available in an edge data network and that abruptly switching the associated application traffic to a different PDU session or terminating the PDU session may impact any user experience that is associated with the application traffic; See [0170]);
Conclusion
Any response to this action should be mailed to:
Commissioner for Patents,
P.O. Box 1450
Alexandria, VA 22313-1450
Hand delivered responses should be brought to:
Customer Service Window
Randolph Building
401 Dulany Street
Alexandria, VA 22314
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ASHLEY L SHIVERS whose telephone number is (571)270-3523. The examiner can normally be reached Monday-Friday 9:00am-5:00pm.
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, Chirag Shah can be reached at 571-272-3144. 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.
/ASHLEY SHIVERS/Primary Examiner, Art Unit 2477 6/3/2026
Prosecution Insights