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 .
Claim Rejections - 35 USC § 103
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 and 5-7 are rejected under 35 U.S.C. 103 as being unpatentable over Palanisamy US (2023/0198911) in view of Das et al. US (2019/0319858).
Regarding Claim 1, Palanisamy discloses one or more non-transitory computer-readable media storing one or more computer programs (see Para [0086] i.e., non-transitory computer readable medium containing a set of instructions, when executed by a processor to perform steps in a method) for providing one or more quality of service (QoS) flows for over-the-top (OTT) applications (see Para’s [0049] & [0052]), the one or more computer programs configured to cause at least one processor (see Para [0086]) to:
monitor packets from an OTT application executing on a mobile device; (In light of the applicants specification in Para’s [0003], [0042], [0048], & [0065], an OTT application may be i.e., “WhatsAPP”). (Palanisamy, see Fig. 1 i.e., packets from user device 10 (i.e., mobile device) are monitored by system node 100 for classification, Fig. 2 i.e., packet processing engine 102 & Para’s [0037-0038] i.e., deep packet inspection (DPI) is used to review and classify network traffic, [0039-0040] i.e., A subscriber, using a subscriber device 10, may initiate a traffic flow with a base station 12 which may be reviewed and classified by the system 100, & [0045-0047] i.e., the packet processing engine 105 (i.e., of system 100 in Fig. 1) may also determine when any traffic actions are to be associated with the traffic flow and packets (i.e., “monitored packets”) of the traffic flow once the traffic flow is classified, [0049] i.e., The classification module 120 is configured to classify the traffic (i.e., “packets”) based on the type of traffic, for example, video streaming, data transfer, VoIP, or the like as well as the application associated with the traffic flow, for example Netflix, WhatsAPP (i.e., “OTT application”), or the like. The classification model 120 may classify the type of traffic based on the application associated with the traffic flow & [0058] i.e., applications such as WhatsAPP Call, [0078] i.e., application of traffic)
determine that the monitored packets pertain to the OTT application and a service type, (see Para’s [0037-0038] i.e., Further, the machine learning model may also determine characteristics such as application, [0039] i.e., the system 100 use a pre-trained machine learning model to analyze the traffic flows…and determine what application is being transmitted over the network, & [0049] i.e., The classification module 120 is configured to classify the traffic (i.e., “packets”) based on the type of traffic (i.e., “service type”), for example, video streaming, data transfer, VoIP, or the like as well as the application associated with the traffic flow, for example Netflix, WhatsAPP (i.e., “OTT application”), or the like. The classification model 120 may classify the type of traffic based on the application associated with the traffic flow, [0051] i.e., application recognition, [0056-0058], [0061], & [0078] i.e., If the model provides a full classification of the traffic flow for the particular aspect of the flow, for example, category of traffic (i.e., “service type”), application of traffic (i.e., “OTT application”))
and create and/or assign one or more flows to the OTT application (see Fig. 3 i.e., step 220 apply traffic action & Para [0051-0052] i.e., If the traffic flow, is classified, traffic actions, for example, prioritization, policies, and/or rules may be applied to the traffic flow (i.e., prioritization applied to the traffic flow will create and/or assign a prioritized flow to the OTT application traffic) & [0064] i.e., traffic action such as a particular prioritization of the traffic flow), the mobile device, or both, based on the determined OTT application and service type, (see Fig. 3 & Para’s [0039] i.e., determined application being transmitted, [0049] i.e., The classification module 120 is configured to classify the traffic based on the type of traffic (i.e., “service type”), for example, video streaming, data transfer, VoIP, or the like as well as the application associated with the traffic flow, for example Netflix, WhatsAPP (i.e., “determined OTT application”), or the like. The classification model 120 may classify the type of traffic based on the application associated with the traffic flow, [0051-0052], & [0078])
While Palanisamy discloses the prioritization applied to the traffic flow will create and/or assign a prioritized flow for the OTT application traffic (see Para [0052]), Palanisamy does not disclose the prioritization creates and/or assigns one or more QoS flows to the OTT application, and wherein the one or more created and/or assigned QoS flows have a higher QoS than an originally assigned QoS flow for OTT data the mobile device. However the claim feature would be rendered obvious in view of Das et al. US (2019/0319858).
Das discloses prioritization of upstream traffic from a mobile device (see Fig. 9) creates and/or assigns one or more QoS flows to the OTT application of the mobile device, the mobile device, or both (see Fig. 9 & Para’s [0264], [0275-0277] i.e., Referring to Fig. 9, a default bearer 902a and an attached dedicated bearer 904a may carry data packets upstream…the data packets include audio packets, specifically OTT voice data…Moreover, when a voice packet transmitted through the default bearer 902a is detected by a MECx module 442, the MECx 442 instructs the DUe to create a dedicated bearer 904a. The dedicated bearer 904a is logically attached to the default bearer 902a and may have enhanced QoS parameters (e.g., higher priority for detected voice data, higher or wider bandwidth, lower packet delay budget) (i.e., “created and/or assigned QoS flow”), which in turn enhances the QoE of users who are utilizing OTT voice applications), [0309], [0323] i.e., the MECx module may cause transmission of subsequent data packets from the client device via the dedicated bearer(s) (i.e., “created and/or assigned QoS flow”), thereby enabling improved or guaranteed QoE to users of the network at least by virtue of prioritization of the upstream voice traffic through the dedicated bearer(s), & [0331] i.e., by giving higher priority (among other QoS and network enhancements associated with the QCI value of the dedicated bearer) to traffic exchanged via the dedicated bearer, over other traffic exchanged via the “best effort” default bearer)
and wherein the one or more created and/or assigned QoS flows have a higher QoS than an originally assigned QoS flow for OTT data the mobile device (see Fig. 9 & Para’s [0235-0236] i.e., Moreover, a dedicated bearer may provide a guaranteed bit rate (GBR)…while a default bearer does not have a guaranteed bit rate. GBR generally comes with a higher priority level (i.e., dedicated bearer has a higher QoS than originally assigned QoS flow in the default bearer), [0264], [0277] i.e., The dedicated bearer 904a (i.e., “created and/or assigned QoS flow”) is logically attached to the default bearer 902a and may have enhanced QoS parameters (e.g., higher priority for detected voice data, higher or wider bandwidth, lower packet delay budget) (i.e., dedicated bearer 904a has a higher QoS than an originally assigned QoS flow in the default bearer), which in turn enhances the QoE of users who are utilizing OTT voice applications), [0309] i.e., Generally, the priority level of the dedicated bearer (i.e., “created and/or assigned QoS flow”) is higher than that of the default bearer, & [0331] i.e., by giving higher priority (among other QoS and network enhancements associated with the QCI value of the dedicated bearer) to traffic exchanged via the dedicated bearer, over other traffic exchanged via the “best effort” default bearer).
(Das suggests the one or more created and/or assigned QoS flows via the dedicated bearer provides enhanced QoS parameters such as higher priority for OTT voice data which in turn enhances the quality of experience (QoE) of users who are utilizing OTT voice applications and mitigates the impact of network congestion, (see Para’s [0276-0277], & [0331])).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date for the prioritization applied to the traffic flow which creates and/or assigns a prioritized flow for the OTT application traffic as disclosed in Palanisamy to create and/or assign one or more QoS flows to the OTT application, wherein the one or more created and/or assigned QoS flows have a higher QoS than an originally assigned QoS flow for OTT data the mobile device according to the prioritization of the upstream OTT voice data traffic via the dedicated bearer as disclosed in the teachings of Das, because the motivation lies in Das that the one or more created and/or assigned QoS flows via the dedicated bearer provides enhanced QoS parameters such as higher priority for OTT voice data which in turn enhances the quality of experience (QoE) of users who are utilizing OTT voice applications and mitigates the impact of network congestion.
Regarding Claim 2, Palanisamy discloses the one or more non-transitory computer-readable media of claim 1, but does not disclose wherein the one or more created and/or assigned QoS flows provide a guaranteed packet latency, packet drop rate, and packet priority. However the claim feature would be rendered obvious in view of Das et al. US (2019/0319858).
Das discloses wherein the one or more created and/or assigned QoS flows provide a guaranteed packet latency, packet drop rate, and packet priority (see Para’s [0118] i.e., The foregoing enables enhanced QoE and QoS commensurate with user expectations for the ultra-high data rate and ultra-low latency (i.e., “guaranteed packet latency”) of the 5G enables network (i.e., high-bitrate audio and/or video, minimized or eliminated disconnects or packet drops even with multi-party conference calls over OTT voice services) thereby enabling a rich and sustained delivery of voice traffic for the users even in a congested network environment, [0235-0236] i.e., Moreover, a dedicated bearer may provide a guaranteed bit rate (GBR)…while a default bearer does not have a guaranteed bit rate. GBR generally comes with a higher priority level, [0309] i.e., Generally, the priory level of the dedicated bearer is higher than that of the default bearer, making the packets less likely to drop, [0264] i.e., The dedicated bearer to…(iii) transmit voice data at ultra-high data rates and ultra-low latencies to reduce user-perceptible delays or artifacts associated with transmission of the packet media data (i.e., “guaranteed packet latency”), [0277] i.e., The dedicated bearer 904a (i.e., “created and/or assigned QoS flow”) is logically attached to the default bearer 902a and may have enhanced QoS parameters (e.g., higher priority for detected voice data (i.e., packet priority”), higher or wider bandwidth, lower packet delay budget, which in turn enhances the QoE of users who are utilizing OTT voice applications), [0309] i.e., the dedicated bearer has a different CQI value associated with e.g., a different priority level, different packet error loss rate…Generally, the priority level of the dedicated bearer is higher than that of the default bearer, making the packets less likely to drop & [0344] i.e., voice packets guaranteed not to drop)
(Das suggests the one or more created and/or assigned QoS flows via the dedicated bearer provides enhanced QoS parameters such as higher priority for OTT voice data which in turn enhances the quality of experience (QoE) of users who are utilizing OTT voice applications and mitigates the impact of network congestion, (see Para’s [0276-0277], & [0331])).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date for the prioritization applied to the traffic flow which creates and/or assigns a prioritized flow for the OTT application traffic as disclosed in Palanisamy to create and/or assign one or more QoS flows to the OTT application, wherein the one or more created and/or assigned QoS flows provide a guaranteed packet latency, packet drop rate, and packet priority according to the prioritization of the upstream OTT voice data traffic via the dedicated bearer as disclosed in the teachings of Das, because the motivation lies in Das that the one or more created and/or assigned QoS flows via the dedicated bearer provides enhanced QoS parameters such as higher priority for OTT voice data which in turn enhances the quality of experience (QoE) of users who are utilizing OTT voice applications and mitigates the impact of network congestion.
Regarding Claim 3, the combination of Palanisamy in view of Das discloses the one or more non-transitory computer-readable media of claim 1, wherein the monitoring of the packets from the OTT application comprises performing Deep Packet Inspection (DPI) on the monitored packets (Palanisamy, see Para’s [0037] i.e., deep packet inspection (DP) used to review and classify network traffic) to determine patterns and characteristics of communications to and/or from the OTT application, (see Para’s [0003] i.e., Traffic identification (either to an application or to a traffic category) generally happens using various techniques. First, classification is based on byte pattern and strings available in the payload, [0037-0038] i.e., Generally, DPI has been used to review and classify network traffic. DPI may generate various information associated with a network traffic flow related and provide statistics associated with the network characteristics of the flow…these statistics and attributes may be used to build a machine learning model. The machine learning model may then determine whether other encrypted flows exhibit characteristics of a streaming video traffic flow (i.e., may be determining patterns), a VoIP traffic flow, a Web surfing traffic flow, or another type of traffic flow, [0040] & [0053] i.e., The traffic classification may be a conventional method based on a particular byte pattern available in the payload & [0049] the classification module 120 is configured to classify the traffic flow using a model making module based)
Regarding Claim 5, the combination of Palanisamy in view of Das discloses the one or more non-transitory computer-readable media of claim 3, wherein the monitoring of the packets from the OTT application comprises monitoring a bit rate of the monitored packets, (Palanisamy, see Para’s [0036-0038] i.e., data and traffic statistics are collected. The collected data is reviewed and passed on by the system in order to classify the traffic flow, via, for example, machine learning, [0041], & [0048-0049] i.e., data collection module 115 may collect statistics such as bitrate)
Regarding Claim 6, the combination of Palanisamy in view of Das discloses the one or more non-transitory computer-readable media of claim 3, wherein the DPI comprises using one or more trained artificial intelligence (AI) /machine learning (ML) models that have been trained to learn characteristics of each OTT application type and perform classification of the OTT application and the service type, (Palanisamy, see Para’s [0036-0037] i.e., DPI may generate various information associated with a network traffic flow related and provide statistics associated with the network characteristics of the flow…these statistics and attributes may be used to build (i.e., training ML) a machine learning model. The machine learning model may then determine whether other encrypted flows exhibit characteristics of a streaming video traffic flow, a VOIP flow. Further the machine learning model may also determine characteristics such as application or other classification attributes…with the aid of the machine learning model will be used to identify and classify the traffic flow, [0039] i.e., pre-trained supervised machine learning model, [0047], [0049] i.e., the classification model 120 is configured to classify the traffic based on the type of traffic as well as the application associated with the traffic flow, [0055-0056], [0061], & [0072])
Regarding Claim 7, the combination of Palanisamy in view of Das discloses the one or more non-transitory computer-readable media of claim 6, wherein the one or more AI/ML models are trained based on recorded OTT application communications, service type bit rates, ports and IP addresses of the OTT applications, or any combination thereof. (Palanisamy, see Para’s [0036-0037] i.e., DPI may generate various information associated with a network traffic flow related and provide statistics associated with the network characteristics of the flow…these statistics and attributes (i.e., “recorded OTT application communications”) may be used to build (i.e., training ML) a machine learning model. The machine learning model may then determine whether other encrypted flows exhibit characteristics of a streaming video traffic flow, a VoIP traffic flow, a Web surfing traffic flow, or any other type of traffic flow (i.e., “recorded OTT application communications”) . Further the machine learning model may also determine characteristics such as application or other classification attributes…with the aid of the machine learning model will be used to identify and classify the traffic flow [0039] i.e., pre-trained supervised machine learning model, [0040] i.e., a model may be built based on the pre-labeled data (i.e., “recorded OTT application communications”) to classify the traffic to a plurality of popular category of traffic flows…there may be a predefined set of categories (i.e., “recorded OTT application communications”) & [0048-0049] i.e., data collection module 115 may collect statistics such as bitrate (i.e., “service type bit rate”)…the classification module 120 is configured to classify the traffic flow using a model to classify the traffic based on the type of traffic, for example, video streaming, data transfer, VoIP, & [0052] i.e., the system will try to classify the traffic flow based on the newly collected data)
Claim 4 is rejected under 35 U.S.C. 103 as being unpatentable over Palanisamy US (2023/0198911) in view of Das et al. US (2019/0319858) as applied to claim 3 above, and further in view of Kovari et al. US (2021/0051088).
Regarding Claim 4, the combination of Palanisamy in view of Das discloses the one or more non-transitory computer-readable media of claim 3 including the monitored packets that are associated with the OTT application (Palanisamy, see Para [0049]), but does not disclose wherein the monitoring of the packets from the OTT application comprises determining one or more service Internet Protocol (IP) addresses and/or one or more ports in the monitored packets that are associated with the OTT application. However the claim feature would be rendered obvious in view of Kovari et al. US (2021/0051088).
Kovari discloses determining one or more service Internet Protocol (IP) addresses and/or one or more ports in the monitored packets that are associated with an OTT application for classifying the OTT data traffic, (see Para [0029] i.e., The first packet probe 120a on the S1-u interface can be configured to classify the OTT traffic of the different OTT session/flows by destination/target IP address(es) and/or port(s)).
(Kovari suggests the packet probe 120 is configured to perform deep packet inspection which can include analyzing the data packets of the OTT data 16 to determine characteristics of the OTT data streams traversing the data communication system 10 and to properly classify the OTT traffic of different OTT sessions/flows based on the destination IP addresses and/or ports (see Para’s [0028-0029])).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date for the monitoring of the packets associated with the OTT application for performing classification as disclosed in Palanisamy in view of Das to be performed determining one or more service Internet Protocol (IP) addresses and/or one or more ports in the monitored packets for classifying the OTT data traffic as disclosed in Kovari, because the motivation lies in Kovari that the packet probe 120 is configured to perform deep packet inspection which can include analyzing the data packets of the OTT data 16 to determine characteristics of the OTT data streams traversing the data communication system 10 and to properly classify the OTT traffic of different OTT sessions/flows based on the destination IP addresses and/or ports.
Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over Palanisamy US (2023/0198911) in view of Das et al. US (2019/0319858) as applied to claim 1 above, and further in view of Jia et al. US (2022/0417823).
Regarding Claim 8, the combination of Palanisamy in view of Das discloses the one or more non-transitory computer-readable media of claim 1 including the monitoring of the packets from the OTT application (Palanisamy, see Para’s [0037] & [0045-0049]), but does not disclose wherein the monitoring of the packets from the OTT application comprises obtaining a 5G Application Identifier (App ID) from the monitored packets that indicates a type of the OTT application. However the claim feature would be rendered obvious in view of Jia et al. US (2022/0417823).
Jia discloses monitoring of packets from the OTT application comprises obtaining a 5G Application Identifier (App ID) from monitored packets that indicates a type of the OTT application (see Para’s [0012-0013] i.e., 5G, [0035], [0041] i.e., OTT voice/video apps or services…association of application/service traffic with, and identification of such traffic based on, network slice IDs (i.e., “5G APP ID”) enables traffic prioritization, [0044] i.e., Traffic corresponding to the high priority application or service may be associated with (e.g., assigned) the network slice ID (i.e., “5G APP ID”), which enables the network node 216 to distinguish such traffic from other traffic for optimization purposes, [0056], & [0064]).
(Jia suggests traffic corresponding to the high priority application or service may be associated with (e.g., assigned) the network slice ID which enables a network node to distinguish such traffic from other traffic for optimization purposes and enables traffic prioritization, (see Para’s [0041] & [0044])).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date for the monitoring of the packets from the OTT application for performing classification as disclosed in Palanisamy in view of Das to be performed by obtaining a 5G Application Identifier (App ID) from monitored packets that indicates a type of the OTT application as disclosed in Jia, because the motivation lies in Jia that traffic corresponding to the high priority application or service may be associated with (e.g., assigned) the network slice ID which enables a network node to distinguish such traffic from other traffic for optimization purposes and enables traffic prioritization.
Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over Palanisamy US (2023/0198911) in view of Das et al. US (2019/0319858) as applied to claim 1 above, and further in view of Sofuoglu US (2024/0348523).
Regarding Claim 9, the combination of Palanisamy in view of Das discloses the one or more non-transitory computer-readable media of claim 1, wherein the service type of the OTT application comprises a voice call, a video, or a group communication (Palanisamy, see Para’s [0037] i.e., the machine learning model may then determine whether other encrypted flows exhibit characteristics of a streaming video traffic flow, a VoIP traffic flow & [0049] i.e., video streaming, VoIP), but does not disclose and a Service Data Flow (SDF) template is assigned to each service type. However the claim feature would be rendered obvious in view of Sofuoglu US (2024/0348523).
Sofuoglu discloses a Service Data Flow (SDF) template is assigned to each service type (see Para’s [0002-0005] i.e., OTT applications which include service types, [0101] i.e., service data flow (SDF) templates, [0102] i.e., QFI, QoS flow type, & [0105] i.e., PSA-UPF 110 can enforce QoS monitoring on UE’s uplink and downlink traffic in 5GC using the SDF templates sent by the SMF 840…the PSA-UPF 110 may perform mapping of user-plane packets to QoS flows based on PDRs (packet detection rules)…The PDRs include packet detection information (PDI) to classify/match the traffic using 5-tuple to map the traffic (e.g., SDF) to a QoS flow (e.g., SDF binding) (i.e., SDF templates are associated with different service types for classifying the traffic according to its respective service))
(Sofuoglu suggests the SDF template sent from the SMF to the UPF is included in packet detection rules (PDRs) which is used by the UPF for performing QoS monitoring and classification of the UEs traffic for correctly mapping the packets to appropriate QoS flows for QoS flow modification, (see Para’s [0101-0105])).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date for the service types of the OTT application as disclosed in Palanisamy in view of Das to be assigned to a Service Data Flow (SDF) template based on the teachings of Sofuoglu who discloses Service Data Flow (SDF) templates are used by a UPF for classifying the UEs traffic to a corresponding service type, because the motivation lies in Sofuoglu that the SDF template sent from the SMF to the UPF is included in packet detection rules (PDRs) which is used by the UPF for performing QoS monitoring and classification of the UEs traffic for correctly mapping the packets to appropriate QoS flows for QoS flow modification.
Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over Palanisamy US (2023/0198911) in view of Das et al. US (2019/0319858) as applied to claim 1 above, further in view of Villasante et al. US (2022/0385550), and further in view of Sofuoglu US (2024/0348523).
Regarding Claim 10, the combination of Palanisamy in view of Das discloses the one or more non-transitory computer-readable media of claim 1 including the creating and/or assigning of the one or more QoS flows to the OTT application (Palanisamy, see Fig. 1 & Para [0052] & Das, see Para [0277]), but does not disclose the claim features of wherein the creating and/or assigning of the one or more QoS flows to the OTT application is performed by a Session Management Function (SMF) using one or more Service Data Flow (SDF) templates based on policy information from a Policy Control Function (PCF), and the SMF and PCF are executing on one or more computing systems of a network core. However the claim features would be rendered obvious in view of Villasante et al. US (2022/0385550).
Villasante discloses creating and/or assigning of the one or more QoS flows to an OTT application is performed by a Session Management Function (SMF) (see Fig. 1, Fig. 5 i.e., PCF 110 & Para’s [0004] i.e., Such flow classification is needed for various control and reporting purposes including…enforcement of QoS guarantees, [0006] i.e., PCFP defines a packet forwarding model that includes a procedure to classify data packet flows using packet detection rules (PDRs)…each PDR is associated with one or more actions (i.e., forwarding) that are to be applied to the matching data packets (i.e., QoS flow will be created for the forwarded packets), [0013-0014] i.e., OTT application, [0061], [0064] i.e., an action may relate to an enforcement of a QoS strategy for the one or more matching data packets, & [0087] i.e., SMF 107 receives policy and charging control (PCC) rules from a policy control function (PCF) 108 and configured a UPF 106 accordingly. The PCC rules include PDR and associated actions. Among other things, SMF 107 control the packet processing in UPF 106 by establishing, modifying, or deleting PFCP sessions and by provisioning (i.e., adding, modifying, or deleting)) PDRs and associated actions (i.e., modifying PDRs and association actions may include modifying QoS enforcement rules (QER) for the OTT traffic which creates and/or assigns a QoS flow for the OTT data traffic based on the modified QoS enforcement rule (QER)), as defined in forwarding action rules (FARs), QoS enforcement rules (QER), and/or URR, per PFCP session. A PFCP session may correspond to an individual PDU session)
using one or more Service Data Flow (SDF) templates (see Fig. 1, Fig. 5 & Para’s [0063], [0087] i.e., SMF 107 receives policy and charging control (PCC) rules from a policy control function (PCF) 108 and configured a UPF 106 accordingly. The PCC rules include PDR (i.e., PDR includes “SDF templates”) and associated actions. Among other things, SMF 107 control the packet processing in UPF 106 by establishing, modifying, or deleting PFCP sessions and by provisioning (i.e., adding, modifying, or deleting)) PDRs (i.e., PDR includes “SDF templates”) and associated actions as defined in forwarding action rules (FARs), QoS enforcement rules (QER), and/or URR, per PFCP session. A PFCP session may correspond to an individual PDU session, & [0106] i.e., Each PDR (i.e., PDR includes “SDF template”) contains packet detection information (PDI) specifying the traffic filters (i.e., “SDF template”) or signatures against which incoming data packets are matched)
based on policy information from a Policy Control Function (PCF), (see Fig. 1, Fig. 5 i.e., PCF 110 & Para’s [0004] i.e., Such flow classification is needed for various control and reporting purposes including…enforcement of QoS guarantees, [0006] i.e., PCFP defines a packet forwarding model that includes a procedure to classify data packet flows using packet detection rules (PDRs)…each PDR is associated with one or more actions (i.e., forwarding) that are to be applied to the matching data packets (i.e., QoS flow will be created for the forwarded packets), [0064] i.e., an action may relate to an enforcement of a QoS strategy for the one or more matching data packets, & [0087] i.e., SMF 107 receives policy and charging control (PCC) rules from a policy control function (PCF) 108 and configured a UPF 106 accordingly. The PCC rules include PDR and associated actions. Among other things, SMF 107 control the packet processing in UPF 106 by establishing, modifying, or deleting PFCP sessions and by provisioning (i.e., adding, modifying, or deleting)) PDRs and associated actions (i.e., modifying PDRs and association actions may include modifying QoS enforcement rules (QER) for the OTT traffic which creates and/or assigns a QoS flow for the OTT data traffic based on the modified QoS enforcement rule (QER)), as defined in forwarding action rules (FARs), QoS enforcement rules (QER), and/or URR, per PFCP session. A PFCP session may correspond to an individual PDU session)
and the SMF (see Fig. 5 i.e., SMF 107) and PCF (see Fig. 5 i.e., PCF 110) are executing on one or more computing systems of a network core (see Fig. 5 & Para’s [0054] i.e., core network, [0083-0087] i.e., SMF 107 is a control plane function with an Nsmf interface, [0089] i.e., The PCF 110 supports, via an Npcf interface, a unified policy framework to govern the core network domain behavior…the PCF 110 provides the PCC rules to the 107 that enforces PCC decisions according to these PCC rules & [0160]).
(Villasante suggests proper classification of individual packet flows is an important user plane feature which is needed for various purposes including traffic steering and enforcement of quality of service (QoS) guarantees for guaranteeing QoS of the OTT traffic according to the modified QoS enforcement rule (QER) performed by the SMF, (see Para’s [0004-0006], [0013-0014], [0061], [0064], & [0087])).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date for the creating and/or assigning of the one or more QoS flows to the OTT application as performed by the network system as disclosed in Palanisamy in view of Das to be performed by a Session Management Function (SMF) using one or more Service Data Flow (SDF) templates based on policy information from a Policy Control Function (PCF) as disclosed in the teachings of Villasante, because the motivation lies in Villasante that proper classification of individual packet flows is an important user plane feature which is needed for various purposes including traffic steering and enforcement of quality of service (QoS) guarantees for guaranteeing QoS of the OTT traffic according to the modified QoS enforcement rule (QER) performed by the SMF.
While Villasante suggests the SMF using one or more service data flow (SDF) templates (see Para’s [0063], [0087], & [0106] i.e., Each PDR (i.e., PDR includes “SDF template”) contains packet detection information (PDI) specifying the traffic filters (i.e., “SDF template”) or signatures against which incoming data packets are matched), the combination of Palanisamy in view of Das, and further in view of Villasante does not explicitly disclose a service data flow (SDF) template. However the claim feature would be rendered obvious in view of Sofuoglu US (2024/0348523).
Sofuoglu discloses a UPF 110 can enforce QoS monitoring on UE’s uplink and downlink traffic using service data flow (SDF) templates sent by an SMF 840 (see Fig. 8 & Para’s [0101] i.e., The SMF 840 can collect PCC rules from the PCF 850 and convert the PCC rules into service data flow (SDF) templates for the PSA-UPF 110 & [0105] i.e., PSA-UPF 110 can enforce QoS monitoring on UE’s uplink and downlink traffic in 5GC using the SDF templates sent by the SMF 840…The PSA-UPF 110 may perform mapping of user-plane packets to QoS flows based on packet detection rules (PDRs) which comprise packet handling instructions received from SMF 840…the PDRs include packet detection information (PDI) to classify/match the traffic using 5-tuple to map the traffic (e.g., SDF) to a QoS flow (e.g., SDF binding)).
(Sofuoglu suggests the SDF template sent from the SMF to the UPF is included in packet detection rules (PDRs) which is used by the UPF for performing QoS monitoring and classification of the UEs traffic for correctly mapping the packets to appropriate QoS flows for QoS flow modification, (see Para’s [0101-0105])).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date for the packet detection rules (PDRs) which contain packet detection information used by the SMF for creating and/or assigning the one or more QoS flows to the OTT application as disclosed in Palanisamy in view of Das, and further in view of Villasante to include the service data flow (SDF) templates included in the packetd detection information (PDI) of the packet detection rule (PDR) used by the SMF as disclosed in the teachings of Sofuoglu who discloses a UPF can enforce QoS monitoring on UE’s uplink and downlink traffic using service data flow (SDF) templates sent by an SMF, because the motivation lies in Sofuoglu that the SDF template sent from the SMF to the UPF is included in packet detection rules (PDRs) which is used by the UPF for performing QoS monitoring and classification of the UEs traffic for correctly mapping the packets to appropriate QoS flows for QoS flow modification.
Claim 11 is rejected under 35 U.S.C. 103 as being unpatentable over Palanisamy US (2023/0198911) in view of Das et al. US (2019/0319858) as applied to claim 1 above, further in view of Villasante et al. US (2022/0385550), and further in view of Sofuoglu US (2024/0348523) as applied to claim 10 above, and further in view of Mladin et al. US (2024/0334504).
Regarding Claim 11, the combination of Palanisamy in view of Das, further in view of Villasante, and further in view of Sofuoglu discloses the one or more non-transitory computer-readable media of claim 10, but does not disclose wherein Reflective QoS is used for uplink communications from the mobile device. However the claim feature would be rendered obvious in view of Mladin et al. US (2024/0334504).
Mladin wherein Reflective QoS is used for uplink communications from the mobile device (see Para’s [0066] the UPF may apply QoS marking to the DL traffic and the UE may be configured for Reflective QoS so that the same QoS treatment may be applied in the UL & [0068]).
(Mladin suggests reflective QoS is a QoS treatment method at the UE which may be controlled on the network side on a per-packet basis which results in automatically determining the QoS for the UEs uplink traffic based on the same QoS of the received downlink traffic and for flexibility controlling for the UE the reflective QoS on a per-packet basis by the network side, (see Para’s [0066] & [0068])).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date for the uplink communications from the mobile device as disclosed in Palanisamy in view of Das, further in view of Villasante, and further in view of Sofuoglu to include using Reflective QoS for uplink communications from the mobile device as disclosed in the teachings of Mladin, because the motivation lies in Mladin that reflective QoS is a QoS treatment method at the UE which may be controlled on the network side on a per-packet basis which results in automatically determining the QoS for the UEs uplink traffic based on the same QoS of the received downlink traffic and for flexibility controlling for the UE the reflective QoS on a per-packet basis by the network side.
Claim 12 is rejected under 35 U.S.C. 103 as being unpatentable over Palanisamy US (2023/0198911) in view of Das et al. US (2019/0319858) as applied to claim 1 above, further in view of Villasante et al. US (2022/0385550), and further in view of Sofuoglu US (2024/0348523) as applied to claim 10 above, and further in view of Jia et al. US (2022/0417823).
Regarding Claim 12, the combination of Palanisamy in view of Das, further in view of Villasante, and further in view of Sofuoglu discloses the one or more non-transitory computer-readable media of claim 10, but does not disclose the claim feature of wherein User Equipment (UE) Route Selection Policy (URSP) is used by the mobile device for routing packets of the OTT application to an appropriate slice. However the claim feature would be rendered obvious in view of Jia et al. US (2022/0417823).
Jia discloses wherein User Equipment (UE) Route Selection Policy (URSP) is used by the mobile device for routing packets of the OTT application to an appropriate slice (see Fig. 2C i.e., steps 275b & 275c Para’s [0041] i.e., OTT voice/video apps or services, such as VOIP, video over IP, or the like, [0043-0044] i.e., UE route selection policy evaluation, [0063] i.e., a high priority application, such as a voice/video IP call, may be initiated. For example, a user of the UE 220 may initiate a voice/video IP call…Initiation of a voice/video IP call may, for example, involve a device modem or operating system triggering a UE route selection policy evaluation, & [0064] i.e., At 275c, a dedicated, end-to-end network slice may be assigned for the high priority application or service. For example, the network slice manager 236 may configure, or otherwise activate, an end-to-end network slice 240, having a particular slice ID, for the high priority application or service between the UE 220 and the core network 230b).
(Jia suggests based on the Route Selection Policy (URSP) used by the mobile device, a dedicated network slice may be assigned for the high priority application or service for facilitating the high priority application or service between the UE and the core network and traffic corresponding to the high priority application may be associated with a network slice ID which enables traffic prioritization and a network node to distinguish traffic for optimization purposes, (see Para’s [0041], [0044] & [0064])).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date for the communication of the OTT application for the UE as disclosed in Palanisamy in view of Das, further in view of Villasante, and further in view of Sofuoglu to include a User Equipment (UE) Route Selection Policy (URSP) which is used by the mobile device for routing packets of the OTT application to an appropriate slice as disclosed in the teachings of Jia, because the motivation lies in Jia, that based on the Route Selection Policy (URSP) used by the mobile device, a dedicated network slice may be assigned for the high priority application or service for facilitating the high priority application or service between the UE and the core network and traffic corresponding to the high priority application may be associated with a network slice ID which enables traffic prioritization and a network node to distinguish traffic for optimization purposes.
Claim 13 is rejected under 35 U.S.C. 103 as being unpatentable over Palanisamy US (2023/0198911) in view of Das et al. US (2019/0319858) as applied to claim 1 above, and further in view of Villasante et al. US (2022/0385550).
Regarding Claim 13, the combination of Palanisamy in view of Das discloses the one or more non-transitory computer-readable media of claim 1, but does not disclose wherein the monitoring of the packets from the OTT application is performed by a User Plane Function (UPF), and the UPF is executing on one or more computing systems of a network core. However the claim feature would be rendered obvious in view of Villasante et al. US (2022/0385550).
Villasante discloses wherein the monitoring of the packets from the OTT application is performed by a User Plane Function (UPF), (see Fig. 1 i.e., flow classifier 106 & Para’s [0013-0014] i.e., OTT application, [0060] i.e., transporting application traffic in the form of data packet flows between the content provider system 101 and the terminal devices 104…the terminal devices 104 could likewise generate application traffic, & [0057-0063] i.e., the flow classifier 106 is configured to classify a particular packet data flow using packet detection rules (PDRs). A particular data packet flow is classified according to a particular PDR in case one or more data packets of that data packet flow match that particular PDR, & [0088] i.e., UPF 106 supports classification of application traffic based on the PDRs received from SMF 107. UPF 106 takes the role of the flow classifier 106 of Fig. 1)
and the UPF is executing on one or more computing systems of a network core (see Fig. 5 i.e., SMF 107 & Para’s [0054] i.e., core network, [0083-0087] i.e., SMF 107 is a control plane function with an Nsmf interface, [0089] i.e., The PCF 110 supports, via an Npcf interface, a unified policy framework to govern the core network domain behavior…the PCF 110 provides the PCC rules to the 107 that enforces PCC decisions according to these PCC rules & [0160]).
(Villasante suggests proper classification of individual packet flows is an important user plane feature performed by the UPF which is needed for various purposes including traffic steering and enforcement of quality of service (QoS) guarantees for guaranteeing QoS of the OTT traffic according to a QoS enforcement rule (QER) associated with the classification, (see Para’s [0004-0006], [0013-0014], [0061], [0064], & [0087])).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date for the monitoring of the packets from the OTT application performed by the network system as disclosed in Palanisamy in view of Das to be performed by a User Plane Function (UPF) executing on one or more computing systems of a network core as disclosed in the teachings of Villasante, because the motivation lies in Villasante that proper classification of individual packet flows is an important user plane feature performed by the UPF which is needed for various purposes including traffic steering and enforcement of quality of service (QoS) guarantees for guaranteeing QoS of the OTT traffic according to a QoS enforcement rule (QER) associated with the classification.
Claims 14-15 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Palanisamy US (2023/0198911) in view of Das et al. US (2019/0319858), and further in view of Villasante et al. US (2022/0385550).
Regarding Claim 14, Palanisamy discloses one or more computing systems (see Fig. 1 i.e., system 100, Fig. 2 & Para [0039]), comprising: memory (see Fig. 1 i.e., memory 140) storing computer program instructions (see Para’s [0045] & [0086] i.e., non-transitory computer readable medium containing a set of instructions, when executed by a processor to perform steps in a method) for providing one or more quality of service (QoS) flows for over-the-top (OTT) applications, (see Para’s [0049] & [0052])
and at least one processor configured to execute the computer program instructions (see Para’s [0045] i.e., the processor may be configured to execute the instructions stored in the memory component in order for the modules to execute their functions & [0086]), wherein the computer instructions are configured to cause the at least one processor (see Para’s [0045] & [0086]) to: monitor packets from an OTT application executing on a mobile device that utilizes deep packet inspection (DPI) on the monitored packets to determine patterns and characteristics of communications to and/or from the OTT application; (In light of the applicants specification in Para’s [0003], [0042], [0048], & [0065], an OTT application may be i.e., “WhatsAPP”). (Palanisamy, see Fig. 1 i.e., packets from user device 10 (i.e., mobile device) are monitored by system node 100 for classification, Fig. 2 i.e., packet processing engine 102 & Para’s [0003], [0037-0038] i.e., deep packet inspection (DPI) is used to review and classify network traffic…DPI may generate various information associated with a network traffic flow related and provide statistics associated with characteristics of the flow. These statistics and attributes may be used to build a machine learning model. The machine learning model as detailed herein, may then determine whether other encrypted flows exhibit characteristics of a streaming video traffic flow, a VoIP traffic flow, a Web surfing traffic flow, or another type of traffic flow, [0039-0040] i.e., A subscriber, using a subscriber device 10, may initiate a traffic flow with a base station 12 which may be reviewed and classified by the system 100, & [0045-0047] i.e., the packet processing engine 105 (i.e., of system 100 in Fig. 1) may also determine when any traffic actions are to be associated with the traffic flow and packets (i.e., “monitored packets”) of the traffic flow once the traffic flow is classified, [0049] i.e., The classification module 120 is configured to classify the traffic (i.e., “packets”) based on the type of traffic, for example, video streaming, data transfer, VoIP, or the like as well as the application associated with the traffic flow, for example Netflix, WhatsAPP (i.e., “OTT application”), or the like. The classification model 120 may classify the type of traffic based on the application associated with the traffic flow, [0053] i.e., traffic classification may be based on a particular byte pattern available in the payload, & [0058] i.e., applications such as WhatsAPP Call having a specific traffic pattern, [0078] i.e., application of traffic)
determine that the monitored packets pertain to the OTT application and a service type, (see Para’s [0037-0038] i.e., Further, the machine learning model may also determine characteristics such as application, [0039] i.e., the system 100 use a pre-trained machine learning model to analyze the traffic flows…and determine what application is being transmitted over the network, & [0049] i.e., The classification module 120 is configured to classify the traffic (i.e., “packets”) based on the type of traffic (i.e., “service type”), for example, video streaming, data transfer, VoIP, or the like as well as the application associated with the traffic flow, for example Netflix, WhatsAPP (i.e., “OTT application”), or the like. The classification model 120 may classify the type of traffic based on the application associated with the traffic flow, [0051] i.e., application recognition, [0056-0058], [0061], & [0078] i.e., If the model provides a full classification of the traffic flow for the particular aspect of the flow, for example, category of traffic (i.e., “service type”), application of traffic (i.e., “OTT application”))
and create and/or assign one or more flows to the OTT application (see Fig. 3 i.e., step 220 apply traffic action & Para [0051-0052] i.e., If the traffic flow, is classified, traffic actions, for example, prioritization, policies, and/or rules may be applied to the traffic flow (i.e., prioritization applied to the traffic flow will create and/or assign a prioritized flow to the OTT application traffic) & [0064] i.e., traffic action such as a particular prioritization of the traffic flow), the mobile device, or both, based on the determined OTT application and service type, (see Fig. 3 & Para’s [0039] i.e., determined application being transmitted, [0049] i.e., The classification module 120 is configured to classify the traffic based on the type of traffic (i.e., “service type”), for example, video streaming, data transfer, VoIP, or the like as well as the application associated with the traffic flow, for example Netflix, WhatsAPP (i.e., “determined OTT application”), or the like. The classification model 120 may classify the type of traffic based on the application associated with the traffic flow, [0051-0052], & [0078])
While Palanisamy discloses the prioritization applied to the traffic flow will create and/or assign a prioritized flow for the OTT application traffic (see Para [0052]), Palanisamy does not disclose the prioritization creates and/or assigns one or more QoS flows to the OTT application, and wherein the one or more created and/or assigned QoS flows have a higher QoS than an originally assigned QoS flow for OTT data the mobile device. However the claim feature would be rendered obvious in view of Das et al. US (2019/0319858).
Das discloses prioritization of upstream traffic from a mobile device (see Fig. 9) creates and/or assigns one or more QoS flows to the OTT application of the mobile device, the mobile device, or both (see Fig. 9 & Para’s [0264], [0275-0277] i.e., Referring to Fig. 9, a default bearer 902a and an attached dedicated bearer 904a may carry data packets upstream…the data packets include audio packets, specifically OTT voice data…Moreover, when a voice packet transmitted through the default bearer 902a is detected by a MECx module 442, the MECx 442 instructs the DUe to create a dedicated bearer 904a. The dedicated bearer 904a is logically attached to the default bearer 902a and may have enhanced QoS parameters (e.g., higher priority for detected voice data, higher or wider bandwidth, lower packet delay budget) (i.e., “created and/or assigned QoS flow”), which in turn enhances the QoE of users who are utilizing OTT voice applications), [0309], [0323] i.e., the MECx module may cause transmission of subsequent data packets from the client device via the dedicated bearer(s) (i.e., “created and/or assigned QoS flow”), thereby enabling improved or guaranteed QoE to users of the network at least by virtue of prioritization of the upstream voice traffic through the dedicated bearer(s), & [0331] i.e., by giving higher priority (among other QoS and network enhancements associated with the QCI value of the dedicated bearer) to traffic exchanged via the dedicated bearer, over other traffic exchanged via the “best effort” default bearer)
and wherein the one or more created and/or assigned QoS flows have a higher QoS than an originally assigned QoS flow for OTT data the mobile device (see Fig. 9 & Para’s [0235-0236] i.e., Moreover, a dedicated bearer may provide a guaranteed bit rate (GBR)…while a default bearer does not have a guaranteed bit rate. GBR generally comes with a higher priority level (i.e., dedicated bearer has a higher QoS than originally assigned QoS flow in the default bearer), [0264], [0277] i.e., The dedicated bearer 904a (i.e., “created and/or assigned QoS flow”) is logically attached to the default bearer 902a and may have enhanced QoS parameters (e.g., higher priority for detected voice data, higher or wider bandwidth, lower packet delay budget) (i.e., dedicated bearer 904a has a higher QoS than an originally assigned QoS flow in the default bearer), which in turn enhances the QoE of users who are utilizing OTT voice applications), [0309] i.e., Generally, the priority level of the dedicated bearer (i.e., “created and/or assigned QoS flow”) is higher than that of the default bearer, & [0331] i.e., by giving higher priority (among other QoS and network enhancements associated with the QCI value of the dedicated bearer) to traffic exchanged via the dedicated bearer, over other traffic exchanged via the “best effort” default bearer).
(Das suggests the one or more created and/or assigned QoS flows via the dedicated bearer provides enhanced QoS parameters such as higher priority for OTT voice data which in turn enhances the quality of experience (QoE) of users who are utilizing OTT voice applications and mitigates the impact of network congestion, (see Para’s [0276-0277], & [0331])).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date for the prioritization applied to the traffic flow which creates and/or assigns a prioritized flow for the OTT application traffic as disclosed in Palanisamy to create and/or assign one or more QoS flows to the OTT application, wherein the one or more created and/or assigned QoS flows have a higher QoS than an originally assigned QoS flow for OTT data the mobile device according to the prioritization of the upstream OTT voice data traffic via the dedicated bearer as disclosed in the teachings of Das, because the motivation lies in Das that the one or more created and/or assigned QoS flows via the dedicated bearer provides enhanced QoS parameters such as higher priority for OTT voice data which in turn enhances the quality of experience (QoE) of users who are utilizing OTT voice applications and mitigates the impact of network congestion.
The combination of Palanisamy in view of Das does not disclose the monitoring is performed by a user plane function (UPF). However the claim limitation would be rendered obvious in view of Villasante et al. US (2022/0385550).
Villasante discloses monitoring packets from an OTT application executing on a mobile device by a user plane function (see Fig. 1 i.e., 106 & Para [0088] i.e., UPF 106 takes the role of the flow classifier 106 of Fig. 1) that utilizes deep packet inspection (DPI) (see Para [0063] i.e., deep packet inspection) for classifying the packets, (see Fig. 1 i.e., flow classifier 106 & Para’s [0014], [0057-0062] i.e., transporting application traffic in the form of data packet flows between the content provider system 101 and the terminal devices 104…any of the terminal devices 104 could likewise generate application traffic, [0063] i.e., the flow classifier 106 is configured to classify a particular packet data flow…Classification is performed by the flow classifier 106 using packet detection rules (PDRs). A particular data packet flow is classified according to a particular PDR in case one or more data packets of that data packet flow match that particular PDR, [0068-0071], & [0087-0088] i.e., UPF 106 takes the role of the flow classifier 106 of Fig. 1 & [0138] i.e., UPF 106 has to analyze a significant amount of data packets to properly identify specific (e.g., video or browsing) components in a certain application service, such as youtube video in accordance with PDR 902)
(Villasante suggests proper classification by the UPF of individual packet flows is an important user plane feature which is needed for various purposes including traffic steering and enforcement of quality of service (QoS) guarantees for guaranteeing QoS of the OTT traffic according to an action applied to the one or more packets such as forwarding the packets according to a QoS enforcement rule (QER), (see Para’s [0004-0006], [0013-0014], [0061], [0064-0065], & [0087-0088])).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date the monitoring techniques performed on the packets from the OTT application executing on the mobile device utilizing DPI on the monitored packets as disclosed in Palanisamy in view of Das to be performed by a user plane function (UPF), such as the UPF disclosed in the teachings of Villasante who discloses monitoring packets from an OTT application executing on a mobile device by a user plane function that utilizes deep packet inspection (DPI) for classifying the packets, because the motivation lies in Villasante that proper classification by the UPF of individual packet flows is an important user plane feature which is needed for various purposes including traffic steering and enforcement of quality of service (QoS) guarantees for guaranteeing QoS of the OTT traffic according to an action applied to the one or more packets such as forwarding the packets according to a QoS enforcement rule (QER).
Regarding Claim 15, The combination of Palanisamy in view of Das, and further in view of Villasante discloses the one or more computing systems of claim 14, wherein the DPI comprises using one or more trained artificial intelligence (AI) / machine learning (ML) models that have been trained to learn characteristics of each OTT application type and perform classification of the OTT application and the service type, (Palanisamy, see Para’s [0036-0037] i.e., DPI may generate various information associated with a network traffic flow related and provide statistics associated with the network characteristics of the flow…these statistics and attributes may be used to build (i.e., training ML) a machine learning model. The machine learning model may then determine whether other encrypted flows exhibit characteristics of a streaming video traffic flow, a VOIP flow. Further the machine learning model may also determine characteristics such as application or other classification attributes…with the aid of the machine learning model will be used to identify and classify the traffic flow, [0039] i.e., pre-trained supervised machine learning model, [0047], [0049] i.e., the classification model 120 is configured to classify the traffic based on the type of traffic as well as the application associated with the traffic flow, [0055-0056], [0061], & [0072])
and the one or more AI/ML models are trained based on recorded OTT application communications, service type bit rates, ports and IP addresses of the OTT applications, or any combination thereof. (Palanisamy, see Para’s [0036-0037] i.e., DPI may generate various information associated with a network traffic flow related and provide statistics associated with the network characteristics of the flow…these statistics and attributes (i.e., “recorded OTT application communications”) may be used to build (i.e., training ML) a machine learning model. The machine learning model may then determine whether other encrypted flows exhibit characteristics of a streaming video traffic flow, a VoIP traffic flow, a Web surfing traffic flow, or any other type of traffic flow (i.e., “recorded OTT application communications”) . Further the machine learning model may also determine characteristics such as application or other classification attributes…with the aid of the machine learning model will be used to identify and classify the traffic flow [0039] i.e., pre-trained supervised machine learning model, [0040] i.e., a model may be built based on the pre-labeled data (i.e., “recorded OTT application communications”) to classify the traffic to a plurality of popular category of traffic flows…there may be a predefined set of categories (i.e., “recorded OTT application communications”) & [0048-0049] i.e., data collection module 115 may collect statistics such as bitrate (i.e., “service type bit rate”)…the classification module 120 is configured to classify the traffic flow using a model to classify the traffic based on the type of traffic, for example, video streaming, data transfer, VoIP, & [0052] i.e., the system will try to classify the traffic flow based on the newly collected data)
Regarding Claim 17, Palanisamy discloses a computer-implemented method for providing one or more quality of service (QoS) flows for over-the-top (OTT) applications (see Para’s [0036-0037], [0045], [0049] & [0052]), comprising: monitor packets from an OTT application executing on a mobile device, by a system node (In light of the applicants specification in Para’s [0003], [0042], [0048], & [0065], an OTT application may be i.e., “WhatsAPP”). (Palanisamy, see Fig. 1 i.e., packets from user device 10 (i.e., mobile device) are monitored by system node 100 for classification, Fig. 2 i.e., packet processing engine 102 & Para’s [0003], [0037-0038] i.e., deep packet inspection (DPI) is used to review and classify network traffic…DPI may generate various information associated with a network traffic flow related and provide statistics associated with characteristics of the flow. These statistics and attributes may be used to build a machine learning model. The machine learning model as detailed herein, may then determine whether other encrypted flows exhibit characteristics of a streaming video traffic flow, a VoIP traffic flow, a Web surfing traffic flow, or another type of traffic flow, [0039-0040] i.e., A subscriber, using a subscriber device 10, may initiate a traffic flow with a base station 12 which may be reviewed and classified by the system 100, & [0045-0047] i.e., the packet processing engine 105 (i.e., of system 100 in Fig. 1) may also determine when any traffic actions are to be associated with the traffic flow and packets (i.e., “monitored packets”) of the traffic flow once the traffic flow is classified, [0049] i.e., The classification module 120 is configured to classify the traffic (i.e., “packets”) based on the type of traffic, for example, video streaming, data transfer, VoIP, or the like as well as the application associated with the traffic flow, for example Netflix, WhatsAPP (i.e., “OTT application”), or the like. The classification model 120 may classify the type of traffic based on the application associated with the traffic flow, [0053] i.e., traffic classification may be based on a particular byte pattern available in the payload, & [0058] i.e., applications such as WhatsAPP Call having a specific traffic pattern, [0078] i.e., application of traffic)
determining that the monitored packets pertain to the OTT application and a service type, by the system node (see Para’s [0037-0038] i.e., Further, the machine learning model may also determine characteristics such as application, [0039] i.e., the system 100 use a pre-trained machine learning model to analyze the traffic flows…and determine what application is being transmitted over the network, & [0049] i.e., The classification module 120 is configured to classify the traffic (i.e., “packets”) based on the type of traffic (i.e., “service type”), for example, video streaming, data transfer, VoIP, or the like as well as the application associated with the traffic flow, for example Netflix, WhatsAPP (i.e., “OTT application”), or the like. The classification model 120 may classify the type of traffic based on the application associated with the traffic flow, [0051] i.e., application recognition, [0056-0058], [0061], & [0078] i.e., If the model provides a full classification of the traffic flow for the particular aspect of the flow, for example, category of traffic (i.e., “service type”), application of traffic (i.e., “OTT application”))
and creating and/or assigning one or more flows to the OTT application (see Fig. 3 i.e., step 220 apply traffic action & Para [0051-0052] i.e., If the traffic flow, is classified, traffic actions, for example, prioritization, policies, and/or rules may be applied to the traffic flow (i.e., prioritization applied to the traffic flow will create and/or assign a prioritized flow to the OTT application traffic) & [0064] i.e., traffic action such as a particular prioritization of the traffic flow), the mobile device, or both, based on the determined OTT application and service type, (see Fig. 3 & Para’s [0039] i.e., determined application being transmitted, [0049] i.e., The classification module 120 is configured to classify the traffic based on the type of traffic (i.e., “service type”), for example, video streaming, data transfer, VoIP, or the like as well as the application associated with the traffic flow, for example Netflix, WhatsAPP (i.e., “determined OTT application”), or the like. The classification model 120 may classify the type of traffic based on the application associated with the traffic flow, [0051-0052], & [0078])
While Palanisamy discloses the prioritization applied to the traffic flow will create and/or assign a prioritized flow for the OTT application traffic (see Para [0052]), Palanisamy does not disclose the prioritization creates and/or assigns one or more QoS flows to the OTT application, and wherein the one or more created and/or assigned QoS flows have a higher QoS than an originally assigned QoS flow for OTT data the mobile device and the claim feature of wherein the one or more created and/or assigned QoS flows provide a guaranteed packet latency, packet drop rate, and packet priority. However the claim features would be rendered obvious in view of Das et al. US (2019/0319858).
Das discloses prioritization of upstream traffic from a mobile device (see Fig. 9) creates and/or assigns one or more QoS flows to the OTT application of the mobile device, the mobile device, or both (see Fig. 9 & Para’s [0264], [0275-0277] i.e., Referring to Fig. 9, a default bearer 902a and an attached dedicated bearer 904a may carry data packets upstream…the data packets include audio packets, specifically OTT voice data…Moreover, when a voice packet transmitted through the default bearer 902a is detected by a MECx module 442, the MECx 442 instructs the DUe to create a dedicated bearer 904a. The dedicated bearer 904a is logically attached to the default bearer 902a and may have enhanced QoS parameters (e.g., higher priority for detected voice data, higher or wider bandwidth, lower packet delay budget) (i.e., “created and/or assigned QoS flow”), which in turn enhances the QoE of users who are utilizing OTT voice applications), [0309], [0323] i.e., the MECx module may cause transmission of subsequent data packets from the client device via the dedicated bearer(s) (i.e., “created and/or assigned QoS flow”), thereby enabling improved or guaranteed QoE to users of the network at least by virtue of prioritization of the upstream voice traffic through the dedicated bearer(s), & [0331] i.e., by giving higher priority (among other QoS and network enhancements associated with the QCI value of the dedicated bearer) to traffic exchanged via the dedicated bearer, over other traffic exchanged via the “best effort” default bearer)
and wherein the one or more created and/or assigned QoS flows have a higher QoS than an originally assigned QoS flow for OTT data the mobile device (see Fig. 9 & Para’s [0235-0236] i.e., Moreover, a dedicated bearer may provide a guaranteed bit rate (GBR)…while a default bearer does not have a guaranteed bit rate. GBR generally comes with a higher priority level (i.e., dedicated bearer has a higher QoS than originally assigned QoS flow in the default bearer), [0264], [0277] i.e., The dedicated bearer 904a (i.e., “created and/or assigned QoS flow”) is logically attached to the default bearer 902a and may have enhanced QoS parameters (e.g., higher priority for detected voice data, higher or wider bandwidth, lower packet delay budget) (i.e., dedicated bearer 904a has a higher QoS than an originally assigned QoS flow in the default bearer), which in turn enhances the QoE of users who are utilizing OTT voice applications), [0309] i.e., Generally, the priority level of the dedicated bearer (i.e., “created and/or assigned QoS flow”) is higher than that of the default bearer, & [0331] i.e., by giving higher priority (among other QoS and network enhancements associated with the QCI value of the dedicated bearer) to traffic exchanged via the dedicated bearer, over other traffic exchanged via the “best effort” default bearer).
wherein the one or more created and/or assigned QoS flows provide a guaranteed packet latency, packet drop rate, and packet priority, (see Para’s [0118] i.e., The foregoing enables enhanced QoE and QoS commensurate with user expectations for the ultra-high data rate and ultra-low latency (i.e., “guaranteed packet latency”) of the 5G enables network (i.e., high-bitrate audio and/or video, minimized or eliminated disconnects or packet drops even with multi-party conference calls over OTT voice services) thereby enabling a rich and sustained delivery of voice traffic for the users even in a congested network environment, [0235-0236] i.e., Moreover, a dedicated bearer may provide a guaranteed bit rate (GBR)…while a default bearer does not have a guaranteed bit rate. GBR generally comes with a higher priority level, [0309] i.e., Generally, the priory level of the dedicated bearer is higher than that of the default bearer, making the packets less likely to drop, [0264] i.e., The dedicated bearer to…(iii) transmit voice data at ultra-high data rates and ultra-low latencies to reduce user-perceptible delays or artifacts associated with transmission of the packet media data (i.e., “guaranteed packet latency”), [0277] i.e., The dedicated bearer 904a (i.e., “created and/or assigned QoS flow”) is logically attached to the default bearer 902a and may have enhanced QoS parameters (e.g., higher priority for detected voice data (i.e., packet priority”), higher or wider bandwidth, lower packet delay budget, which in turn enhances the QoE of users who are utilizing OTT voice applications), [0309] i.e., the dedicated bearer has a different CQI value associated with e.g., a different priority level, different packet error loss rate…Generally, the priority level of the dedicated bearer is higher than that of the default bearer, making the packets less likely to drop & [0344] i.e., voice packets guaranteed not to drop)
(Das suggests the one or more created and/or assigned QoS flows via the dedicated bearer provides enhanced QoS parameters such as higher priority for OTT voice data which in turn enhances the quality of experience (QoE) of users who are utilizing OTT voice applications and mitigates the impact of network congestion, (see Para’s [0276-0277], & [0331])).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date for the prioritization applied to the traffic flow which creates and/or assigns a prioritized flow for the OTT application traffic as disclosed in Palanisamy to create and/or assign one or more QoS flows to the OTT application, wherein the one or more created and/or assigned QoS flows have a higher QoS than an originally assigned QoS flow for OTT data the mobile device according to the prioritization of the upstream OTT voice data traffic via the dedicated bearer as disclosed in the teachings of Das, because the motivation lies in Das that the one or more created and/or assigned QoS flows via the dedicated bearer provides enhanced QoS parameters such as higher priority for OTT voice data which in turn enhances the quality of experience (QoE) of users who are utilizing OTT voice applications and mitigates the impact of network congestion.
The combination of Palanisamy in view of Das does not disclose the monitoring is performed by a user plane function (UPF). but does not disclose the claim features of wherein the creating and/or assigning of the one or more QoS flows to the OTT application is performed by a Session Management Function (SMF) using one or more Service Data Flow (SDF) templates based on policy information from a Policy Control Function (PCF), and the SMF and PCF are executing on one or more computing systems of a network core. However the claim features would be rendered obvious in view of Villasante et al. US (2022/0385550).
Villasante discloses monitoring packets from an OTT application executing on a mobile device by a user plane function (UPF) (see Fig. 1 i.e., 106 & Para [0088] i.e., UPF 106 takes the role of the flow classifier 106 of Fig. 1) for classifying the packets, (see Fig. 1 i.e., flow classifier 106 & Para’s [0014], [0057-0062] i.e., transporting application traffic in the form of data packet flows between the content provider system 101 and the terminal devices 104…any of the terminal devices 104 could likewise generate application traffic, [0063] i.e., the flow classifier 106 is configured to classify a particular packet data flow…Classification is performed by the flow classifier 106 using packet detection rules (PDRs). A particular data packet flow is classified according to a particular PDR in case one or more data packets of that data packet flow match that particular PDR, [0068-0071], & [0087-0088] i.e., UPF 106 takes the role of the flow classifier 106 of Fig. 1 & [0138] i.e., UPF 106 has to analyze a significant amount of data packets to properly identify specific (e.g., video or browsing) components in a certain application service, such as youtube video in accordance with PDR 902)
Villasante further discloses creating and/or assigning of the one or more QoS flows to an OTT application is performed by a Session Management Function (SMF) (see Fig. 1, Fig. 5 i.e., PCF 110 & Para’s [0004] i.e., Such flow classification is needed for various control and reporting purposes including…enforcement of QoS guarantees, [0006] i.e., PCFP defines a packet forwarding model that includes a procedure to classify data packet flows using packet detection rules (PDRs)…each PDR is associated with one or more actions (i.e., forwarding) that are to be applied to the matching data packets (i.e., QoS flow will be created for the forwarded packets), [0013-0014] i.e., OTT application, [0061], [0064] i.e., an action may relate to an enforcement of a QoS strategy for the one or more matching data packets, & [0087] i.e., SMF 107 receives policy and charging control (PCC) rules from a policy control function (PCF) 108 and configured a UPF 106 accordingly. The PCC rules include PDR and associated actions. Among other things, SMF 107 control the packet processing in UPF 106 by establishing, modifying, or deleting PFCP sessions and by provisioning (i.e., adding, modifying, or deleting)) PDRs and associated actions (i.e., modifying PDRs and association actions may include modifying QoS enforcement rules (QER) for the OTT traffic which creates and/or assigns a QoS flow for the OTT data traffic based on the modified QoS enforcement rule (QER)), as defined in forwarding action rules (FARs), QoS enforcement rules (QER), and/or URR, per PFCP session. A PFCP session may correspond to an individual PDU session)
using one or more Service Data Flow (SDF) templates (see Fig. 1, Fig. 5 & Para’s [0063], [0087] i.e., SMF 107 receives policy and charging control (PCC) rules from a policy control function (PCF) 108 and configured a UPF 106 accordingly. The PCC rules include PDR (i.e., PDR includes “SDF templates”) and associated actions. Among other things, SMF 107 control the packet processing in UPF 106 by establishing, modifying, or deleting PFCP sessions and by provisioning (i.e., adding, modifying, or deleting)) PDRs (i.e., PDR includes “SDF templates”) and associated actions as defined in forwarding action rules (FARs), QoS enforcement rules (QER), and/or URR, per PFCP session. A PFCP session may correspond to an individual PDU session, & [0106] i.e., Each PDR (i.e., PDR includes “SDF template”) contains packet detection information (PDI) specifying the traffic filters (i.e., “SDF template”) or signatures against which incoming data packets are matched)
based on policy information from a Policy Control Function (PCF), (see Fig. 1, Fig. 5 i.e., PCF 110 & Para’s [0004] i.e., Such flow classification is needed for various control and reporting purposes including…enforcement of QoS guarantees, [0006] i.e., PCFP defines a packet forwarding model that includes a procedure to classify data packet flows using packet detection rules (PDRs)…each PDR is associated with one or more actions (i.e., forwarding) that are to be applied to the matching data packets (i.e., QoS flow will be created for the forwarded packets), [0064] i.e., an action may relate to an enforcement of a QoS strategy for the one or more matching data packets, & [0087] i.e., SMF 107 receives policy and charging control (PCC) rules from a policy control function (PCF) 108 and configured a UPF 106 accordingly. The PCC rules include PDR and associated actions. Among other things, SMF 107 control the packet processing in UPF 106 by establishing, modifying, or deleting PFCP sessions and by provisioning (i.e., adding, modifying, or deleting)) PDRs and associated actions (i.e., modifying PDRs and association actions may include modifying QoS enforcement rules (QER) for the OTT traffic which creates and/or assigns a QoS flow for the OTT data traffic based on the modified QoS enforcement rule (QER)), as defined in forwarding action rules (FARs), QoS enforcement rules (QER), and/or URR, per PFCP session. A PFCP session may correspond to an individual PDU session)
and the UPF (see Fig. 5 i.e., UPF & Para’s [0087-0088]), the SMF (see Fig. 5 i.e., SMF 107) and the PCF (see Fig. 5 i.e., PCF 110) are executing on one or more computing systems of a network core (see Fig. 5 & Para’s [0054] i.e., core network, [0083-0087] i.e., SMF 107 is a control plane function with an Nsmf interface, [0088] i.e., UPF 106 has an N4 interface 102c to SMF 107 and an N3 interface to the access network domain, [0089] i.e., The PCF 110 supports, via an Npcf interface, a unified policy framework to govern the core network domain behavior…the PCF 110 provides the PCC rules to the 107 that enforces PCC decisions according to these PCC rules & [0160]).
(Villasante suggests proper classification of individual packet flows is an important user plane feature which is needed for various purposes including traffic steering and enforcement of quality of service (QoS) guarantees for guaranteeing QoS of the OTT traffic according to the modified QoS enforcement rule (QER) performed by the SMF, (see Para’s [0004-0006], [0013-0014], [0061], [0064], & [0087])).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date for the creating and/or assigning of the one or more QoS flows to the OTT application as performed by the network system as disclosed in Palanisamy in view of Das to be performed by a Session Management Function (SMF) using one or more Service Data Flow (SDF) templates based on policy information from a Policy Control Function (PCF) and for the monitoring of the packets to be performed by a UPF as disclosed in the teachings of Villasante, because the motivation lies in Villasante that proper classification of individual packet flows is an important user plane feature which is needed for various purposes including traffic steering and enforcement of quality of service (QoS) guarantees for guaranteeing QoS of the OTT traffic according to the modified QoS enforcement rule (QER) performed by the SMF.
Claims 18-19 are rejected under 35 U.S.C. 103 as being unpatentable over Palanisamy US (2023/0198911) in view of Das et al. US (2019/0319858), and further in view of Villasante et al. US (2022/0385550) as applied to claim 17 above, and further in view of Kovari et al. US (2021/0051088).
Regarding Claim 18, The combination of Palanisamy in view of Das, and further in view of Villasante discloses the computer-implemented method of claim 17, wherein the monitoring of the packets from the OTT application comprises performing Deep Packet Inspection (DPI) on the monitored packets (Palanisamy, see Para’s [0037] i.e., deep packet inspection (DP) used to review and classify network traffic) to determine patterns and characteristics of communications to and/or from the OTT application, (see Para’s [0003] i.e., Traffic identification (either to an application or to a traffic category) generally happens using various techniques. First, classification is based on byte pattern and strings available in the payload, [0037-0038] i.e., Generally, DPI has been used to review and classify network traffic. DPI may generate various information associated with a network traffic flow related and provide statistics associated with the network characteristics of the flow…these statistics and attributes may be used to build a machine learning model. The machine learning model may then determine whether other encrypted flows exhibit characteristics of a streaming video traffic flow (i.e., may be determining patterns), a VoIP traffic flow, a Web surfing traffic flow, or another type of traffic flow, [0040] & [0053] i.e., The traffic classification may be a conventional method based on a particular byte pattern available in the payload & [0049] the classification module 120 is configured to classify the traffic flow using a model making module based)
monitoring a bit rate of the monitored packets, (Palanisamy, see Para’s [0036-0038] i.e., data and traffic statistics are collected. The collected data is reviewed and passed on by the system in order to classify the traffic flow, via, for example, machine learning, [0041], & [0048-0049] i.e., data collection module 115 may collect statistics such as bitrate)
The combination of Palanisamy in view of Das, and further in view of Villasante does not disclose wherein the monitoring of the packets from the OTT application comprises determining one or more service Internet Protocol (IP) addresses and/or one or more ports in the monitored packets that are associated with the OTT application. However the claim feature would be rendered obvious in view of Kovari et al. US (2021/0051088).
Kovari discloses determining one or more service Internet Protocol (IP) addresses and/or one or more ports in the monitored packets that are associated with an OTT application for classifying the OTT data traffic, (see Para [0029] i.e., The first packet probe 120a on the S1-u interface can be configured to classify the OTT traffic of the different OTT session/flows by destination/target IP address(es) and/or port(s)).
(Kovari suggests the packet probe 120 is configured to perform deep packet inspection which can include analyzing the data packets of the OTT data 16 to determine characteristics of the OTT data streams traversing the data communication system 10 and to properly classify the OTT traffic of different OTT sessions/flows based on the destination IP addresses and/or ports (see Para’s [0028-0029])).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date for the monitoring of the packets associated with the OTT application for performing classification as disclosed in Palanisamy in view of Das, and further in view of Villasante to be performed by determining one or more service Internet Protocol (IP) addresses and/or one or more ports in the monitored packets for classifying the OTT data traffic as disclosed in Kovari, because the motivation lies in Kovari that the packet probe 120 is configured to perform deep packet inspection which can include analyzing the data packets of the OTT data 16 to determine characteristics of the OTT data streams traversing the data communication system 10 and to properly classify the OTT traffic of different OTT sessions/flows based on the destination IP addresses and/or ports.
Regarding Claim 19, the combination of Palanisamy in view of Das, and further in view of Villasante discloses the computer-implemented method of claim 17, wherein the monitoring of the packets from the OTT application comprises performing Deep Packet Inspection (DPI) on the monitored packets to determine patterns and characteristics of communications to and/or from the OTT application, (Palanisamy, see Fig. 1 i.e., packets from user device 10 (i.e., mobile device) are monitored by system node 100 for classification, Fig. 2 i.e., packet processing engine 102 & Para’s [0003], [0037-0038] i.e., deep packet inspection (DPI) is used to review and classify network traffic…DPI may generate various information associated with a network traffic flow related and provide statistics associated with characteristics of the flow. These statistics and attributes may be used to build a machine learning model. The machine learning model as detailed herein, may then determine whether other encrypted flows exhibit characteristics of a streaming video traffic flow, a VoIP traffic flow, a Web surfing traffic flow, or another type of traffic flow, [0039-0040] i.e., A subscriber, using a subscriber device 10, may initiate a traffic flow with a base station 12 which may be reviewed and classified by the system 100, & [0045-0047] i.e., the packet processing engine 105 (i.e., of system 100 in Fig. 1) may also determine when any traffic actions are to be associated with the traffic flow and packets (i.e., “monitored packets”) of the traffic flow once the traffic flow is classified, [0049] i.e., The classification module 120 is configured to classify the traffic (i.e., “packets”) based on the type of traffic, for example, video streaming, data transfer, VoIP, or the like as well as the application associated with the traffic flow, for example Netflix, WhatsAPP (i.e., “OTT application”), or the like. The classification model 120 may classify the type of traffic based on the application associated with the traffic flow, [0053] i.e., traffic classification may be based on a particular byte pattern available in the payload, & [0058] i.e., applications such as WhatsAPP Call having a specific traffic pattern, [0078] i.e., application of traffic)
the DPI comprises using one or more trained artificial intelligence (AI) / machine learning (ML) models that have been trained to learn characteristics of each OTT application type and perform classification of the OTT application and the service type, (Palanisamy, see Para’s [0036-0037] i.e., DPI may generate various information associated with a network traffic flow related and provide statistics associated with the network characteristics of the flow…these statistics and attributes may be used to build (i.e., training ML) a machine learning model. The machine learning model may then determine whether other encrypted flows exhibit characteristics of a streaming video traffic flow, a VOIP flow. Further the machine learning model may also determine characteristics such as application or other classification attributes…with the aid of the machine learning model will be used to identify and classify the traffic flow, [0039] i.e., pre-trained supervised machine learning model, [0047], [0049] i.e., the classification model 120 is configured to classify the traffic based on the type of traffic as well as the application associated with the traffic flow, [0055-0056], [0061], & [0072])
and the one or more AI/ML models are trained based on recorded OTT application communications, service type bit rates, ports and IP addresses of the OTT applications, or any combination thereof. (Palanisamy, see Para’s [0036-0037] i.e., DPI may generate various information associated with a network traffic flow related and provide statistics associated with the network characteristics of the flow…these statistics and attributes (i.e., “recorded OTT application communications”) may be used to build (i.e., training ML) a machine learning model. The machine learning model may then determine whether other encrypted flows exhibit characteristics of a streaming video traffic flow, a VoIP traffic flow, a Web surfing traffic flow, or any other type of traffic flow (i.e., “recorded OTT application communications”) . Further the machine learning model may also determine characteristics such as application or other classification attributes…with the aid of the machine learning model will be used to identify and classify the traffic flow [0039] i.e., pre-trained supervised machine learning model, [0040] i.e., a model may be built based on the pre-labeled data (i.e., “recorded OTT application communications”) to classify the traffic to a plurality of popular category of traffic flows…there may be a predefined set of categories (i.e., “recorded OTT application communications”) & [0048-0049] i.e., data collection module 115 may collect statistics such as bitrate (i.e., “service type bit rate”)…the classification module 120 is configured to classify the traffic flow using a model to classify the traffic based on the type of traffic, for example, video streaming, data transfer, VoIP, & [0052] i.e., the system will try to classify the traffic flow based on the newly collected data)
Claims 16 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Palanisamy US (2023/0198911) in view of Das et al. US (2019/0319858), and further in view of Villasante et al. US (2022/0385550) applied to claims 14 and 17 above, further in view of Mladin et al. US (2024/0334504), and further in view of Jia et al. US (2022/0417823).
Regarding Claims 16 and 20, the combination of Palanisamy in view of Das, and further in view of Villasante discloses the one or more computing systems and computer-implemented method of claims 14 and 17, but does not disclose wherein Reflective QoS is used for uplink communications from the mobile device, but does not disclose wherein Reflective QoS is used for uplink communications from the mobile device. However the claim feature would be rendered obvious in view of Mladin et al. US (2024/0334504).
Mladin wherein Reflective QoS is used for uplink communications from the mobile device (see Para’s [0066] the UPF may apply QoS marking to the DL traffic and the UE may be configured for Reflective QoS so that the same QoS treatment may be applied in the UL & [0068]).
(Mladin suggests reflective QoS is a QoS treatment method at the UE which may be controlled on the network side on a per-packet basis which results in automatically determining the QoS for the UEs uplink traffic based on the same QoS of the received downlink traffic and for flexibility controlling for the UE the reflective QoS on a per-packet basis by the network side, (see Para’s [0066] & [0068])).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date for the uplink communications from the mobile device as disclosed in Palanisamy in view of Das, and further in view of Villasante, to include using Reflective QoS for uplink communications from the mobile device as disclosed in the teachings of Mladin, because the motivation lies in Mladin that reflective QoS is a QoS treatment method at the UE which may be controlled on the network side on a per-packet basis which results in automatically determining the QoS for the UEs uplink traffic based on the same QoS of the received downlink traffic and for flexibility controlling for the UE the reflective QoS on a per-packet basis by the network side.
The combination of Palanisamy in view of Das, further in view of Villasante, and further in view of Mladin does not disclose the claim feature of wherein User Equipment (UE) Route Selection Policy (URSP) is used by the mobile device for routing packets of the OTT application to an appropriate slice. However the claim feature would be rendered obvious in view of Jia et al. US (2022/0417823).
Jia discloses wherein User Equipment (UE) Route Selection Policy (URSP) is used by the mobile device for routing packets of the OTT application to an appropriate slice (see Fig. 2C i.e., steps 275b & 275c Para’s [0041] i.e., OTT voice/video apps or services, such as VOIP, video over IP, or the like, [0043-0044] i.e., UE route selection policy evaluation, [0063] i.e., a high priority application, such as a voice/video IP call, may be initiated. For example, a user of the UE 220 may initiate a voice/video IP call…Initiation of a voice/video IP call may, for example, involve a device modem or operating system triggering a UE route selection policy evaluation, & [0064] i.e., At 275c, a dedicated, end-to-end network slice may be assigned for the high priority application or service. For example, the network slice manager 236 may configure, or otherwise activate, an end-to-end network slice 240, having a particular slice ID, for the high priority application or service between the UE 220 and the core network 230b).
(Jia suggests based on the Route Selection Policy (URSP) used by the mobile device, a dedicated network slice may be assigned for the high priority application or service for facilitating the high priority application or service between the UE and the core network and traffic corresponding to the high priority application may be associated with a network slice ID which enables traffic prioritization and a network node to distinguish traffic for optimization purposes, (see Para’s [0041], [0044] & [0064])).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date for the communication of the OTT application for the UE as disclosed in Palanisamy in view of Das, further in view of Villasante, and further in view of Mladin to include a User Equipment (UE) Route Selection Policy (URSP) which is used by the mobile device for routing packets of the OTT application to an appropriate slice as disclosed in the teachings of Jia, because the motivation lies in Jia, that based on the Route Selection Policy (URSP) used by the mobile device, a dedicated network slice may be assigned for the high priority application or service for facilitating the high priority application or service between the UE and the core network and traffic corresponding to the high priority application may be associated with a network slice ID which enables traffic prioritization and a network node to distinguish traffic for optimization purposes.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ADNAN A BAIG whose telephone number is (571)270-7511. The examiner can normally be reached M-F 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, Huy Vu can be reached at 571-272-3155. 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.
/ADNAN BAIG/Primary Examiner, Art Unit 2461