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 .
Status of Claims
This office action is a response to an application filed on 01/16/2025, wherein claims 1-20 are presented for examination.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 01/16/2025 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 15-20 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 15 recites “offering a low latency, low loss and scalable throughput (L4S) on demand service to an application” and “providing L4S on demand for an application”. It is unclear whether “an application” in these limitations is referring to the same or different applications, therefore the claim is rendered indefinite.
Claims 16-20 are dependent from claim 15 and therefore contain the same indefinite language. As a result, they are rejected under the same rationale as claim 15.
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 of this title, 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, 8, 10, 11 and 15-17 are rejected under 35 U.S.C. 103 as being unpatentable over Chitta et al. (US 2020/0245182), hereinafter Chitta, in view of Sahin et al. (US 2024/0388989), hereinafter Sahin.
Regarding claim 1, Chitta discloses a method comprising:
by deploying an alternative bearer providing a different quality of service (QoS) for execution of the application on the wireless device than a QoS provided by a default bearer (Chitta, [0041], [0042], [0045], [0049]: operator Packet core deploys a dedicated bearer (alternative bearer) with appropriate QoS for low latency traffic (different QoS) after establishing a default bearer for normal latency traffic of UE (application on the wireless device)); and
maintaining the default bearer for other activities performed by the wireless device and providing non-L4S congestion control for the other activities (Chitta, [0042], [0074]: directing packets sent by the UE that are not low latency traffic (other activities) over the default bearer (maintaining the default bearer) and applying the rest of the PCC rules (providing non-L4S congestion control) on non-latency sensitive bearers).
Chitta does not explicitly disclose receiving a request for low latency, low loss and scalable throughput (L4S) on demand from a requesting application executed by a wireless device; providing L4S on demand for the requesting application.
However, Sahin discloses receiving a request for low latency, low loss and scalable throughput (L4S) on demand from a requesting application executed by a wireless device (Sahin, [0048], [0049], [0052], [0053]: application 1 executed on UE 106 sends an API message or application traffic request indicating L4S service, and UE 106 then sends a PDU session establishment or modification request received by AMF 124);
providing L4S on demand for the requesting application by providing a different quality of service (QoS) for execution of the application on the wireless device (Sahin, [0048]-[0049], [0053]-[0055]: establishing or modifying a PDU session in response to application 1’s request for receiving L4S treatment for a traffic flow (i.e., providing L4S on-demand), and providing an LL-QM QoS flow (different QoS)); and
for other activities performed by the wireless device and providing non-L4S congestion control for the other activities (Sahin, [0048], [0064], [0077]: UE (wireless device) includes client application 2 using non-L4S flows (other activities), and provides non-L4S rules and classic SF ECT(0) treatment (non-L4S congestion control) for such activities).
It would have been obvious to one of ordinary skill in the art, having the teachings of Chitta and Sahin before him or her before the effective filing date of the claimed invention, to modify a network-controlled low-latency traffic segregation method as taught by Chitta, to include application generated L4S request as an additional indication that a particular flow requires low latency treatment as taught by Sahin. The modification would result in Chitta’s packet core applying the appropriate PCC/QoS rules and deploying the dedicated low latency bearer only for that application flow while maintaining the default bearer for the wireless device’s remaining traffic. The motivation for doing so would have been to identify more accurately application traffic genuinely requiring L4S, provide the requested low latency treatment on demand, and avoid unnecessarily consuming scarce edge resources for traffic that does not require that treatment.
Regarding claim 8, Chitta discloses a system comprising:
wireless communication components facilitating communication with wireless devices (Chitta, [0040]);
a memory storing data and instructions (Chitta, [0094], [0096]); and
a processor executing the stored instructions to perform operations including (Chitta, [0096], [0098], [0104])):
by deploying an alternative bearer providing a different quality of service (QoS) than a default QoS for execution of the requesting application on a wireless device (Chitta, [0041], [0042], [0045], [0049]: operator Packet core deploys a dedicated bearer (alternative bearer) with appropriate QoS for low latency traffic (different QoS) after establishing a default bearer for normal latency traffic of UE (application on a wireless device)); and
maintaining a default bearer receiving the default QoS for other activities performed by the wireless device (Chitta, [0049], [0053], [0057]: forwarding remaining non-low latency traffic (other activities) over the default bearer (maintaining the default bearer); [The default bearer’s normal latency treatment provides the default QoS received by those other activities]) and providing non-L4S congestion control for the other activities (Chitta, [0042]: applying the rest of the PCC rules (providing non-L4S congestion control) on non-latency sensitive bearers carrying non-latency sensitive traffic (other activities)).
Chitta does not explicitly disclose providing low latency, low loss, and scalable throughput (L4S) on-demand for a requesting application.
However, Sahin discloses
providing low latency, low loss, and scalable throughput (L4S) on-demand for a requesting application by providing a different quality of service (QoS) for execution of the requesting application on a wireless device (Sahin, [0048]-[0049], [0053]-[0055]: establishing or modifying a PDU session in response to application 1’s request for receiving L4S treatment for a traffic flow (i.e., providing L4S on-demand), and providing an LL-QM QoS flow (different QoS)); and
for other activities performed by the wireless device and providing non-L4S congestion control for the other activities (Sahin, [0048], [0064], [0077]: UE (wireless device) includes client application 2 using non-L4S flows (other activities), and provides non-L4S rules and classic SF ECT(0) treatment (non-L4S congestion control) for such activities).
It would have been obvious to one of ordinary skill in the art, having the teachings of Chitta and Sahin before him or her before the effective filing date of the claimed invention, to modify a network-controlled low-latency traffic segregation method as taught by Chitta, to include application generated L4S request as an additional indication that a particular flow requires low latency treatment as taught by Sahin. The modification would result in Chitta’s packet core applying the appropriate PCC/QoS rules and deploying the dedicated low latency bearer only for that application flow while maintaining the default bearer for the wireless device’s remaining traffic. The motivation for doing so would have been to identify more accurately application traffic genuinely requiring L4S, provide the requested low latency treatment on demand, and avoid unnecessarily consuming scarce edge resources for traffic that does not require that treatment.
Regarding claim 15, Chitta discloses a method comprising:
offering a low latency on demand service to an application executed by a wireless device (Chitta, [0042], [0045]: operator packet core triggers a dedicated low latency bearer based on need and authenticates the UE’s (application executed by a wireless device) subscription for the low latency dedicated bearer service);
by deploying an alternative bearer providing a different quality of service (QoS) than a default QoS for execution of the application on a wireless device (Chitta, [0041], [0042], [0045], [0049]: operator packet core deploys a dedicated bearer (alternative bearer) for low latency traffic after a default bearer for normal latency traffic of UE (application on a wireless device) is established and applies appropriate QoS (different QoS) to the low latency traffic); and
maintaining a default bearer receiving the default QoS for other activities performed by the wireless device (Chitta, [0049], [0053], [0057]: forwarding remaining non-low latency traffic (other activities) over the default bearer (maintaining the default bearer); [The default bearer’s normal latency treatment provides the default QoS received by those other activities]) and providing non-L4S congestion control for the other activities (Chitta, [0042]: applying the rest of the PCC rules (providing non-L4S congestion control) on non-latency sensitive bearers carrying non-latency sensitive traffic (other activities)).
Chitta does not explicitly disclose a low latency, low loss and scalable throughput (L4S) on demand service; providing L4S on demand for an application.
However, Sahin discloses
providing L4S on demand for an application by providing a different quality of service (QoS) for execution of the application on a wireless device (Sahin, [0048]-[0049], [0053]-[0055]: establishing or modifying a PDU session in response to application 1’s request for receiving L4S treatment for a traffic flow (i.e., providing L4S on-demand), and providing an LL-QM QoS flow (different QoS)); and
for other activities performed by the wireless device and providing non-L4S congestion control for the other activities (Sahin, [0048], [0064], [0077]: UE (wireless device) includes client application 2 using non-L4S flows (other activities), and provides non-L4S rules and classic SF ECT(0) treatment (non-L4S congestion control) for such activities).
It would have been obvious to one of ordinary skill in the art, having the teachings of Chitta and Sahin before him or her before the effective filing date of the claimed invention, to modify a network-controlled low-latency traffic segregation method as taught by Chitta, to include application generated L4S request as an additional indication that a particular flow requires low latency treatment as taught by Sahin. The modification would result in Chitta’s packet core applying the appropriate PCC/QoS rules and deploying the dedicated low latency bearer only for that application flow while maintaining the default bearer for the wireless device’s remaining traffic. The motivation for doing so would have been to identify more accurately application traffic genuinely requiring L4S, provide the requested low latency treatment on demand, and avoid unnecessarily consuming scarce edge resources for traffic that does not require that treatment.
Regarding claim 2, Chitta discloses further comprising offering the on demand as a subscription service (Chitta, [0042], [0045]: authenticating the UE’s subscription for low latency dedicated bearer service and triggering the dedicated bearer based on the need for low latency traffic segregation).
Chitta does not explicitly disclose L4S.
However, Sahin discloses offering the L4S on demand (Sahin, [0048], [0049], [0054], [0055]: making L4S service available to application 1 through an API request and subsequently providing an LL-AQM QoS flow in response to the request).
It would have been obvious to one of ordinary skill in the art, having the teachings of Chitta and Sahin before him or her before the effective filing date of the claimed invention, to modify a subscription based low latency dedicated bearer service as taught by Chitta, to provide L4S service for application traffic requesting L4S treatment as taught by Sahin. The motivation for doing so would have been to verify entitlement, and reserve costly and scarce edge resources for authorized traffic requiring low latency treatment.
Regarding claim 3, Chitta wherein the requesting application is an augmented reality (AR) or virtual reality (VR) application (Chitta, [0026]).
Regarding claims 10 and 16, the limitations have been addressed in the rejection of claim 2.
Regarding claims 11 and 17, the limitations have been addressed in the rejection of claim 3.
Claims 4, 12 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Chitta in view of Sahin, further in view of Bae et al. (US 2024/0056869), hereinafter Bae.
Regarding claim 4, Chitta and Sahin do not explicitly disclose wherein the wireless device is tethered to WiFi and the QoS for tethering to WiFi is changed from the QoS provided by the default bearer.
However, Bae discloses wherein the wireless device is tethered to WiFi (Bae, [0053], [0061]: XR device (wireless device) connects to the UE through WiFi and accesses the 5G network through tethering) and the QoS for tethering to WiFi is changed (Bae, [0072], [0084], [0096]: changing the QoS for tethering to WiFi by performing QoS scheduling and changing the 5QI of the tethered XR service flow based on the transmission delay difference between the UE and the XR device connected through WiFi) from the QoS provided by the default bearer to the different QoS for the requesting application (Bae, [0097], [0113]-0116]: changing the QoS for the tethered XR service flow from a default QFI and QoS profile (QoS provided by the default bearer) to a different 5QI (different QoS) in response to an XR service related QoS update request (i.e. from a requesting application)).
It would have been obvious to one of ordinary skill in the art, having the teachings of Chitta, Sahin and Bae before him or her before the effective filing date of the claimed invention, to modify a dedicated bearer system providing application requested L4S service as taught by Chitta and Sahin, to enable the requesting wireless device to be tethered through WiFi and the QoS of its tethered service flow changed from the default bearer QoS to a different QoS as taught by Bae. The motivation for doing so would have been to compensate for tethering delay and keep the requesting application within its allowable latency.
Regarding claims 12 and 18, the limitations have been addressed in the rejection of claim 4.
Claims 5, 13 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Chitta in view of Sahin and Bae, further in view of Cai et al. (US 2013/0117092), hereinafter Cai.
Regarding claim 5, Chitta discloses further comprising providing the different QoS (Chitta, [0045], [0049]: provides appropriate QoS (different QoS) for low latency traffic on a dedicated bearer) and the QoS provided by the default bearer and non-L4S service for the requesting application (Chitta, [0042], [0049], [0057]: establishes a default bearer for normal latency traffic [i.e., the default bearer’s normal latency treatment provides the default QoS] and applies the rest of the PCC rules on non-latency sensitive bearers (non-L4S service));.
Chitta does not explicitly disclose the L4S on demand service for a predetermined time period before returning to.
However, Sahin discloses providing the different QoS and the L4S on demand service (Sahin, [0054], [0055]: provides application 1’s requested L4S treatment (L4S on demand) through an L4S supporting PDU session and an LL-AQM QoS flow (different QoS)).
It would have been obvious to one of ordinary skill in the art, having the teachings of Chitta and Sahin before him or her before the effective filing date of the claimed invention, to modify a network-controlled low-latency traffic segregation method as taught by Chitta, to include application generated L4S request as an additional indication that a particular flow requires low latency treatment as taught by Sahin. The modification would result in Chitta’s packet core applying the appropriate PCC/QoS rules and deploying the dedicated low latency bearer only for that application flow while maintaining the default bearer for the wireless device’s remaining traffic. The motivation for doing so would have been to identify more accurately application traffic genuinely requiring L4S, provide the requested low latency treatment on demand, and avoid unnecessarily consuming scarce edge resources for traffic that does not require that treatment.
Furthermore, the combination of Chitta, Sahin and Bae does not explicitly disclose for a predetermined time period before returning to.
However, Cai discloses providing the different QoS and the on demand service (Cai, Fig. 3, [0031], [0028]: giving the requested data service an on-demand temporary QoS upgrade (different QoS) above the authorized QoS) for a predetermined time period (Cai, Fig. 3, [0029]: enforcing the temporary QoS upgrade for a determined period) before returning to the QoS provided by the default bearer and service (Cai, [0026], [0045]: after the period expires, reverting to the authorized QoS (QoS provided by the default bearer); [0085], [0089]-[0090]: enforcing the temporary upgrade for the modified data service and returning that service to the prior authorization when the period expires).
It would have been obvious to one of ordinary skill in the art, having the teachings of Chitta, Sahin, Bae and Cai before him or her before the effective filing date of the claimed invention, to modify a dedicated bearer system providing an application with requested L4S treatment as taught by Chitta, Sahin and Bae, to enforce the upgraded QoS only for a determined period and then revert the requesting application to the originally authorized default QoS when that period expires as taught by Cai. The motivation for doing so would have been to provide the requesting application with enhanced low latency performance only when requested and for as long as needed, while preventing continued use of costly and scarce low latency edge resources after the predetermined period ends.
Regarding claims 13 and 19, the limitations have been addressed in the rejection of claim 5.
Claims 6, 7, 14 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Chitta in view of Sahin, further in view of Saha (US 2024/0414620).
Regarding claim 6, Chitta and Sahin do not explicitly disclose wherein the QoS provided by the default bearer is fifth generation (5g) QoS identifier (5QI)-8.
However, Saha discloses wherein the QoS provided by the default bearer is fifth generation (5g) QoS identifier (5QI)-8 (Saha, [0032]: a default bearer is available for all applications; [0015]: identifies 5QI as a 5G QoS identifier; Fig. 1: row 8 lists 5QI-8 for buffered video streaming, we, email, chat, and file transfer services).
It would have been obvious to one of ordinary skill in the art, having the teachings of Chitta, Sahin and Saha before him or her before the effective filing date of the claimed invention, to modify a default and dedicated bearer architecture providing application requested L4 treatment as taught by Chitta and Sahin, to include enabling the default bearer to use 5QI-8 QoS for ordinary application traffic as taught by Saha. The motivation for doing so would have been to conserve costly and scarce resources by providing standardized non-GBR QoS for ordinary Internet traffic, while reserving the dedicated bearer for the requesting application’s low latency L4S traffic.
Regarding claim 7, Chitta and Sahin do not explicitly disclose wherein the different QoS is 5QI-80.
However, Saha discloses wherein the different QoS is 5QI-80 (Saha, [0015], [0029]).
It would have been obvious to one of ordinary skill in the art, having the teachings of Chitta, Sahin and Saha before him or her before the effective filing date of the claimed invention, to modify a dedicated low latency bearer providing application requested L4S treatment as taught by Chitta and Sahin, to include utilizing 5QI-80 as a different QoS as taught by Saha. The motivation for doing so would have been to provide the requesting application with low latency QoS while the application is being executed because some applications, including augmented reality applications, may only function properly when at least the QoS defined by 5Qi-80 is provided (Saha, [0015]).
Regarding claims 14 and 20, the limitations have been addressed in the rejections of claims 6 and 7.
Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over Chitta in view of Sahin, further in view of Brown et al. (US 2021/0014724), hereinafter Brown.
Regarding claim 9, Chitta does not explicitly disclose the operations further including receiving a request for the L4S on demand through the default bearer from a requesting application executed by the wireless device.
However, Sahin discloses the operations further including receiving a request for the L4S on demand from a requesting application executed by the wireless device (Sahin, [0048], [0049], [0052], [0053]: application 1 executed on UE 106 sends an API message or application traffic request indicating L4S service, and UE 106 then sends a PDU session establishment or modification request received by AMF 124).
It would have been obvious to one of ordinary skill in the art, having the teachings of Chitta and Sahin before him or her before the effective filing date of the claimed invention, to modify a network-controlled low-latency traffic segregation method as taught by Chitta, to include application generated L4S request as an additional indication that a particular flow requires low latency treatment as taught by Sahin. The modification would result in Chitta’s packet core applying the appropriate PCC/QoS rules and deploying the dedicated low latency bearer only for that application flow while maintaining the default bearer for the wireless device’s remaining traffic. The motivation for doing so would have been to identify more accurately application traffic genuinely requiring L4S, provide the requested low latency treatment on demand, and avoid unnecessarily consuming scarce edge resources for traffic that does not require that treatment.
Furthermore, the combination of Chitta and Sahin does not explicitly disclose through the default bearer.
However, Brown discloses the operations further including receiving a request through the default bearer from a requesting application executed by the wireless device (Brown, [0031], [0035], [0036], [0042], [0044]: receiving a UE initiated dedicated bearer request sent through the default bearer after an application executing on the UE initiates the data session).
It would have been obvious to one of ordinary skill in the art, having the teachings of Chitta, Sahin and Brown before him or her before the effective filing date of the claimed invention, to modify a dedicated bearer system providing application requested L4S treatment as taught by Chitta and Sahin, to include enabling the request to be transmitted through an existing default bearer as taught by Brown. The motivation for doing so would have been to allow the wireless device to request enhanced L4S treatment before the dedicated bearer exists so that the network establishes the dedicated bearer only when needed, thereby avoiding unnecessary bearer allocation and conserving network resources).
Related Art
The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure:
Ma et al. (US 2015/0009826) discloses a default bearer, an additional dedicated bearer and different QoS/QCI treatment for their traffic (Ma, [0065]-[0074]) .
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to LESA M KENNEDY whose telephone number is (571)431-0704. The examiner can normally be reached Monday-Wednesday 9:30 am - 5:30 pm ET.
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, Umar Cheema can be reached on (571) 270-3037. 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.
The examiner also requests, in response to this Office Action, support be shown for language added to any original claims on amendment and any new claims. That is, indicate support for newly added claim language by specifically pointing to page(s) and line no(s) in the specification and/or drawing figure(s). This will assist the examiner in prosecuting the application.
/LESA M KENNEDY/Primary Examiner, Art Unit 2458
Prosecution Insights