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 .
Continued Examination under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 02/02/2026 has been entered.
Response to Amendment
This communication is considered fully responsive to the amendment filed on 02/02/2026.
Claims 1, 9-11, and 17-20 have been amended.
Response to Arguments
Applicant’s arguments with respect to claims 1-20 filed on 02/02/2026 have been considered but are moot because the applicant’s arguments were drawn to newly added features to independent claims, which have been addressed in the instant office action with newly identified prior arts, Li et al (U.S. Patent Application Publication NO. 20240154883, hereinafter “Li”) and Fitzmaurice et al (U.S. Patent Application Publication NO. 20240397344, hereinafter “Fitzmaurice”), thus rendering Applicant’s arguments moot.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 11, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Patent Application Publication NO. 20240154883 to Li et al (hereinafter “Li”) in view of U.S. Patent Application Publication NO. 20240397344 to Fitzmaurice et al. (hereinafter “Fitzmaurice”).
Examiner’s note: in what follows, references are drawn to Li unless otherwise mentioned.
Regarding Claim 1, Li teaches A method, comprising:
receiving, by a network device and via an external interface, a service request, from an application in a data network, for a bearer associated with an external application (para [0097]: FIG. 14 shows an example procedure for cloud application workload offloading and data preprocessing. In the example procedure, cloud applications (interpreted as “a service request, from an application in a data network”) interact with the 6G system's Service Exposure Function (SEF) to inquire about system services and request for services. The SEF may act as a bridge between the 6G system and external systems. … the requested application service may be registered in the Service Registry and informed to the SOCF (interpreted as “receiving, by a network device and via an external interface, a service request”, the SOCF is interpreted as “a network device”));
performing, by the network device, authentication and authorization for the service request (para [0097]: the requested application service may be registered in the Service Registry and informed to the SOCF. The corresponding authentication and policy setting may be recorded in the Authentication Function.);
generating, by the network device, a network configuration request for a core network, based on information in the service request (para [0097]: The SOCF can then select proper Comp SF/Data SF, deploy the application service instances (interpreted as “generating, by the network device, a network configuration request for a core network, based on information in the service request”), and send the updated service chain info to RAN CP and Comp SF, which then update RAN UP and Comp SF a related routing path according to the updated service chain.);
sending, by the network device and in response to receiving the service request, the network configuration request to an exposure function in the core network (para [0097]: cloud applications interact with the 6G system's Service Exposure Function (SEF) to inquire about system services and request for services. The SEF may act as a bridge between the 6G system and external systems. … The SOCF can then select proper Comp SF/Data SF, deploy the application service instances, and send the updated service chain info to RAN CP and Comp SF, which then update RAN UP and Comp SF a related routing path according to the updated service chain.); and.
Li teaches that the Management Plane is utilized to provision new services and optimize system performance (see para [0047-0056] of Li). However, Li does not explicitly teaches: sending, by the network device and in response to receiving the service request, one of a subscriber profile identifier (SPID) update or a radio access technology frequency selection priority (RFSP) update to an operations support system (OSS) function in the core network.
Fitzmaurice, however, in an analogous art, disclose a platform for real-time, responsive re-configuration of dynamic user profiles and network profiles based on event triggers. Specifically, Fitzmaurice teaches that a dynamic access management system interacts with a back-office rating engine in the form of an operating support system (OSS)) … (see para [0036] of Fitzmaurice).
Fitzmaurice teaches:
sending, by the network device and in response to receiving the service request, one of a subscriber profile identifier (SPID) update or a radio access technology frequency selection priority (RFSP) update to an operations support system (OSS) function in the core network (para [0058] of Fitzmaurice: 310: The event manager 220 identifies (based upon a specified “type” of the received event message per FIG. 2B) the network emergency node 232 as the appropriate trigger processor node, of the set of trigger event processors 230, to handle the received civil emergency event 203 instance and forwards a notification message, corresponding to the received civil emergency event 203 (interpreted as “in response to receiving the service request,”), to the network emergency node 232.) (para [0061] of Fitzmaurice: The profile manager 246, in accordance with a new experience band to which an identified subscriber is now assigned, updates a network profile description (see FIG. 5 ) and passes a provisioning message (see FIG. 2D) specifying the updated profile description to the provisioning node 250.) (para [0060] of Fitzmaurice: 340: The band manager 244 executes the received prescribed action on the identified user/account identification. By way of example, the identified subscriber is assigned to a new user experience band (see FIG. 6 ) in accordance with the prescribed action.) (para [0062] of Fitzmaurice: 360 and 370: The profile configuration 252 element, of the provisioning node 250, receives an updated profile for the identified subscriber (interpreted as “a subscriber profile identifier (SPID) update”) …the network interface 254 issues reconfiguration instructions/commands, in accordance with the updated profile (e.g., degraded downlink data rate) of the identified subscriber/account, to … the network operating tools 110 (interpreted as “to an operations support system (OSS) function in the core network”) to incorporate/implement the new/updated profile of the identified subscriber/account in the physical components managing user experience of the identified subscriber/account in a mobile wireless network.) .
It would have been obvious to a person of ordinary skill in the art (PHOSITA) at the time the invention was made to modify the 6G service orchestration framework of Li by incorporating the dynamic profile updating mechanism targeting the operations support system (OSS) function as taught by Fitzmaurice.
The motivation to combine these references is to enable the network architecture of Li to dynamically optimize RAN resource allocation and scale out computing capabilities based on specific application demands or network conditions, ensuring optimal Quality of Service (QoS). Furthermore, prescribing such policy updates to the OSS function (i.e., network operating tools in Fitzmaurice) to execute the service orchestration in Li is a mere predicable application of well-known telecommunication network management techniques yielding the expected result of real-time bearer optimization.
Regarding claim 11, it is a network device claim corresponding to the method claim 1, except the limitations “one or more network devices (FIGs. 1 and 5; RAN, NEF; SOCF; NRF; PCF), comprising: one or more processors” (FIG. 10; CPU) and is therefore rejected for the similar reasons set forth in the rejection of claim 1.
Regarding claim 18, it is a non-transitory computer-readable medium claim corresponding to the method claim 1, except the limitations “non-transitory computer-readable medium” (FIG. 24 and para [0028]: FIG. 24 is a block diagram illustrating components, according to some example embodiments, able to read instructions from a machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium) and perform any one or more of the methodologies discussed herein.) and is therefore rejected for the similar reasons set forth in the rejection of claim 1.
Claims 2, 3, 5-10, 12-13, 17, 19, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Li, Fitzmaurice, and further in view of U.S. Patent Application Publication NO. 20200275304 to Zhao et al (hereinafter “Zhao”).
Regarding Claim 2, Li and Fitzmaurice teach The method of claim 1, Li and Fitzmaurice fail to teach:
wherein the service request includes: a requested quality of service (QoS) level for a flow, an application identifier, an application port, a user equipment (UE) port, and a callback uniform resource locator (URL).
Zhao, in an analogous art of mobile wireless network managing QoS and policy control, teaches: wherein the service request includes: (FIGs. 9-14 and para [0111] of Zhao: For example, the request may include any or all of:
a requested quality of service (QOS) level for a flow (para [0113] of Zhao: Flow information, including treatment and differentiated services code point (DSCP) values, e.g., to indicate QoS requirements of the application traffic (interpreted as “a requested quality of service (QOS) level for a flow”),
an application identifier (para [0112] of Zhao: Application information, such as Application ID (interpreted as “an application identifier”), Name, Vendor, e.g., to identify the app and/or traffic of the app.),
an application port (FIG. 12 and para [0138] of Zhao: The IPv4 TFT IE may carry the IP filter information for PGW to identify and route flows associated with the application…)(“source port” in FIG. 12 is interpreted as “application port”)
a user equipment (UE) port (FIG. 12 and para [0138] of Zhao: The IPv4 TFT IE may carry the IP filter information for PGW to identify and route flows associated with the application…)(“Destination port” in FIG. 12 is interpreted as “user equipment (UE) port”), and
a callback uniform resource locator (URL) (FIG. 12 and para [0138] of Zhao: The IPv4 TFT IE may carry the IP filter information for PGW to identify and route flows associated with the application…)(“Destination IP address” in FIG. 12 is interpreted as “callback uniform resource locator (URL)”).
It would have been obvious to a person of ordinary skill in the art at the time the invention was made to modify the service request messaging framework of Li by incorporating the specific application, flow, and packet filtering parameters (Application ID, DSCP QoS values, ports, and IP routing addresses) taught by Zhao. One of ordinary skill in the art would have been motivated to implement this combination because the combination of Li and Fitzmaurice discloses establishing service chains and dedicated bearers to handle application data traffic (see paragraphs [0082] and [0103] of Li), but requires a precise filtering mechanism to identify which specific packets belong to the requested application flow. Integrating the packet filtering fields (such as Source/Destination ports and IP addresses within a Traffic Flow Template IE structure) as taught in Zhao provides the exact structural payload necessary for the core network to successfully identify and steer the requested differentiated QoS flow. The application of standard packet-filtering attributes (Application ID, QoS level, Port numbers, and destination addresses/URLs) to define a service request payload is a routine and predictable practice in 3GPP and IP-based network architecture to achieve reliable session management.
Regarding Claim 3, Li and Fitzmaurice teach The method of claim 1, Li further teaches wherein the network device serves as an application function that interfaces with the data network and that interfaces with the exposure function in the core network (para [0097]: In the example procedure, cloud applications interact with the 6G system's Service Exposure Function (SEF) to inquire about system services and request for services.);
Li and Fitzmaurice, however, fail to explicitly teach:
wherein receiving the service request includes receiving the service request via an Internet Protocol (IP) interface; and
wherein sending the network configuration request includes sending a differentiated quality of service (QoS) flow request via a non-IP interface.
Zhao, in an analogous art of mobile wireless network managing QoS and policy control, teaches:
wherein receiving the service request includes receiving the service request via an Internet Protocol (IP) interface (para [0111] of Zhao: The request may be transmitted over user datagram protocol (UDP) port 3455 (The UDP is interpreted as “Internet Protocol (IP) interface”), among various possibilities. The request may be or include an RSVP Resv message with a 3GPP QoS object. The request message may include information for the QoS request and policy control.); and
wherein sending the network configuration request includes sending a differentiated quality of service (QOS) flow request via a non-IP interface (para [0140] of Zhao: FIG. 14 illustrates a service quality IE, according to some embodiments. The service quality IE may carry an indication of the service quality measured or requested by the UE. An operation field of the IE may specify whether the indicated QoS characteristics are requested by the UE (e.g., for a dedicated bearer) or measured by the UE (e.g., for a specific bearer and/or in general). For example, the UE may use a service quality IE (e.g., of the request type) to specify QoS characteristics requested for a dedicated bearer associated with an app 710 (interpreted as “differentiated quality of service (QOS) flow request”)) (para [0163] of Zhao: The elements of the core network may check the application profile, and, in response to a successful verification, acknowledge the request (1714) and instruct the SCEF 1660 (interpreted as “sending, … , the network configuration request to an exposure function in the core network”) and/or PGW 716 (and in turn the RAN) to establish the dedicated bearer for the application data flow or flows between the UE 106 and the App server 320.) (Examiner’s comments: Under the Broadest Reasonable Interpretation (BRI), a person of ordinary skill in the art would interpret sending such a specialized cellular core network configuration request to establish an enhanced QoS pipeline as sending a differentiated QoS flow request via a non-IP interface).
It would have been obvious to a person of ordinary skill in the art at the time the invention was made to modify the network orchestration architecture of Li by incorporating the dual-protocol signaling interface (IP-based UDP entry and non-IP cellular control plane provisioning) as taught by Zhao. One of ordinary skill in the art would have been motivated to implement this combination because Li focuses on allowing external cloud-based IP applications to interact with next-generation cellular system networks (see para [0097] of Li). Utilizing a standard IP interface (such as a UDP port as taught in para [0111] of Zhao) is necessary to maintain seamless connectivity with external data networks. At the same time, converting that external request into a non-IP cellular signaling message (such as the QoS service quality IE request taught in paragraphs [0140] and [0163] of Zhao) allows the core network to securely and efficiently provision internal transport channels and manage radio resource within the proprietary cellular infrastructure.
Regarding Claim 5, Li and Fitzmaurice teach The method of claim 1, Li and Fitzmaurice fail to explicitly teach wherein sending the network configuration request includes sending a differentiated quality of service (QOS) flow request to a service capability exposure function (SCEF) for a 4G network.
Zhao, in an analogous art of establishing application-specific network pipeline and managing QoS control, teaches: wherein sending the network configuration request includes sending a differentiated quality of service (QOS) flow request to a service capability exposure function (SCEF) for a 4G network (para [0140] of Zhao: FIG. 14 illustrates a service quality IE, according to some embodiments. The service quality IE may carry an indication of the service quality measured or requested by the UE. An operation field of the IE may specify whether the indicated QoS characteristics are requested by the UE (e.g., for a dedicated bearer) or measured by the UE (e.g., for a specific bearer and/or in general). For example, the UE may use a service quality IE (e.g., of the request type) to specify QoS characteristics requested for a dedicated bearer associated with an app 710 (interpreted as “differentiated quality of service (QOS) flow request”)) (para [0162] of Zhao: the UE 106 may transmit a QoS request message to the SCEF 1660 and/or PGW 716 (1708).) (para [0163] of Zhao: The SCEF 1660 and/or PGW 716 may transmit a confirmation (1710) to the UE 106 and may transmit a QoS request (e.g., in response to the request 1708 from the UE) to the 4G core network (e.g., EPC) 100 (1712), according to some embodiments. … The elements of the core network may check the application profile, and, in response to a successful verification, acknowledge the request (1714) and instruct the SCEF 1660 (interpreted as “sending, … , the network configuration request to an exposure function in the core network”) and/or PGW 716 (and in turn the RAN) to establish the dedicated bearer for the application data flow or flows between the UE 106 and the App server 320.).
It would have been obvious to a person of ordinary skill in the art at the time the invention was made to modify the network configuration and exposure framework of Li by incorporating the SCEF-based 4G core network QoS provisioning mechanism as taught by Zhao. One of ordinary skill in the art would have been motivated to implement this combination because Li explicitly contemplates an evolutionary network architecture designed to interwork, transition, and maintain backward compatibility preceding legacy generations of core networks (see para [0105] of Li). The utilization of an SCEF as a gateway to expose and provision QoS pipelines within a 4G core network is a routine, predictable application of well-known 3GPP interface standards to achieve backward network compatibility.
Regarding Claim 6, Li and Fitzmaurice teach The method of claim 1, Li and Fitzmaurice fail to explicitly teach wherein sending the network configuration request includes sending a differentiated quality of service (QOS) flow request to a network exposure function (NEF) for a 5G network
Zhao, in an analogous art of establishing application-specific network pipeline and managing QoS control, teaches: wherein sending the network configuration request includes sending a differentiated quality of service (QOS) flow request to a network exposure function (NEF) for a 5G network (para [0140] of Zhao: FIG. 14 illustrates a service quality IE, according to some embodiments. The service quality IE may carry an indication of the service quality measured or requested by the UE. An operation field of the IE may specify whether the indicated QoS characteristics are requested by the UE (e.g., for a dedicated bearer) or measured by the UE (e.g., for a specific bearer and/or in general). For example, the UE may use a service quality IE (e.g., of the request type) to specify QoS characteristics requested for a dedicated bearer associated with an app 710 (interpreted as “differentiated quality of service (QOS) flow request”)) (para [0163] of Zhao: The elements of the core network may check the application profile, and, in response to a successful verification, acknowledge the request (1714) and instruct the SCEF 1660 (interpreted as “sending the differentiated quality of service (QOS) flow request to the network configuration request to an exposure function in the core network”) and/or PGW 716 (and in turn the RAN) to establish the dedicated bearer for the application data flow or flows between the UE 106 and the App server 320.) (para [0171] of Zhao: It is noted that FIG. 19 merely illustrates relationships among certain example UE-side and networked or external entities and should not be construed to narrow the scope or spirit of the subject matter described herein, and that various other embodiments of such systems and methods are possible. For example, 5G core network standards may allow an application server (e.g., 320) to connect to a user plane function (UPF) 1910 and/or network exposure function (NEF) 1920 and to send request for a specified QoS with a UE.).
It would have been obvious to a person of ordinary skill in the art at the time the invention was made to modify the network configuration and exposure framework of Li by incorporating the SCEF-based 5G core network QoS provisioning mechanism as taught by Zhao. The utilization of an SCEF as a gateway to expose and provision QoS pipelines within a 5G network is a routine, predictable application of well-known 3GPP interface standards to achieve backward network compatibility.
Regarding Claim 7, Li and Fitzmaurice teach The method of claim 1, Li and Fitzmaurice fail to explicitly teach wherein the service request includes one of: wherein the service request includes one of: a request to create a quality of service (QoS) session, a request to update an existing QoS session, or a request to delete a QoS session.
Zhao, in an analogous art of establishing application-specific network pipeline and managing QoS control, teaches:
a request to create a quality of service (QOS) session (para [0140] of Zhao: An operation field of the IE may specify whether the indicated QoS characteristics are requested by the UE (e.g., for a dedicated bearer)) (interpreted as “a request to create a quality of service (QOS) session”),
a request to update an existing QoS session (Claim 5 of Zhao: a request to modify QoS characteristics of the enhanced QoS pipeline in response to the second QoS request.), or
a request to delete a QoS session (para [0164] of Zhao: The App 710 may send a QoS release message to the UE 106 (1802).) (para [0165] of Zhao: a QoS message to the SCEF 1660 and/or PGW 716 indicating to release the dedicated bearer (1804).).
It would have been obvious to a person of ordinary skill in the art at the time the invention was made to modify the service orchestration framework of Li by incorporating the granular lifecycle session management commands (create, update/modify, and release/delete) as taught by Zhao. The adoption of create, update, and delete commands represents a routine and ubiquitous practice in 3GPP session management protocols to ensure optimal network resource efficiency.
Regarding Claim 8, Li and Fitzmaurice teach The method of claim 1, Li and Fitzmaurice fail to explicitly teach wherein the service request identifies a type of differentiated quality of service (QOS) for the bearer.
Zhao, in an analogous art of establishing application-specific network pipeline and managing QoS control, teaches: wherein the service request identifies a type of differentiated quality of service (QOS) for the bearer (paragraphs [0111-0113] of Zhao: The request message may include information for the QoS request and policy control. For example, the request may include any or all of: …Flow information, including treatment and differentiated services code point (DSCP) values, e.g., to indicate QoS requirements of the application traffic.)
It would have been obvious to a person of ordinary skill in the art at the time the invention was made to modify the service request messaging framework of Li by incorporating the specific types of differentiated QoS indicators (such as DSCP values) as taught by Zhao. A person of ordinary skill in the art would recognize that for a core network to successfully allocate and scale network resources tailored to a specific application, the incoming service request must explicitly articulate its specific QoS requirement.
Regarding Claim 9, Li and Fitzmaurice teach The method of claim 1, further comprising: Li and Fitzmaurice fail to explicitly teach: sending, to the data network, a subscription identifier and a quality of service (QoS) status for a QoS session.
Zhao, in an analogous art of establishing application-specific network pipeline and managing QoS control, teaches: sending, to the data network, a subscription identifier and a quality of service (QoS) status for a QoS session (para [0008] of Zhao: The UE may transmit a request to the network for a dedicated bearer or enhanced QoS flow for the application traffic. The UE may indicate requested QoS configuration parameters and other parameters for the bearer/flow.)(para [0009] of Zhao: The UE may use an extended Resource ReSerVation Protocol (RSVP) to communicate about the request and associated parameters with the network.)(paragraphs [0090-0092] of Zhao: Based on a determination to grant the request, the UE may generate and transmit a request to a core network entity (608), according to some embodiments. The request may request a dedicated bearer or pipeline for the application, e.g., between the UE and the application server 320. …The Resv message may include a “3GPP QoS Object” as further described below. The object may include application profile and QoS information (interpreted as “a subscription identifier and a quality of service (QoS) status for a QoS session”), e.g., which may be necessary for the PGW/PCEF to grant the request and/or to implement the dedicated bearer for the application.) (paragraphs [0111-0114] of Zhao: The request may be or include an RSVP Resv message with a 3GPP QoS object. The request message may include information for the QoS request and policy control. For example, the request may include any or all of: … … Authentication information useable to authenticate the application and/or traffic of the app (interpreted as “a subscription identifier and a quality of service (QoS) status for a QoS session”).).
It would have been obvious to a person of ordinary skill in the art at the time the invention was made to modify the network orchestration framework of Li by incorporating the step of sending the subscription identifier and QoS session status updates to the data network application entity as taught by Zhao. One of ordinary skill in the art would have been motivated to implement this combination because Li’s core architecture relies on an exposure function (SEF/NEF) to bridge external cloud data network applications with internal core network control element (see para [0097] of Li). The sharing of session configuration status parameters between a cellular core network and an authorized data network server is a routine and predictable practice in 3GPP service exposure protocols yielding expected system interoperability.
Regarding Claim 10, Li, Fitzmaurice, and Zhao teach The method of claim 9, wherein sending the subscription identifier and the QoS status includes: Zhao further teaches:
sending the subscription identifier and the QoS status via a callback uniform resource locator (URL) included in the service request (para [0150] of Zhao: It will be appreciated that various other transport protocols (e.g., instead of or in addition to RSVP) may be used transport the various messages, objects, information elements, etc. of FIG. 9-14. Among various possibilities, any of the following protocols may be used: HyperText Transfer Protocol (HTTP), HTTP Secure (HTTPs), and/or stream control transfer protocol (SCTP).) (para [0163] of Zhao: The SCEF 1660 and/or PGW 716 may transmit a confirmation (1710) to the UE 106 and may transmit a QoS request (e.g., in response to the request 1708 from the UE) to the 4G core network (e.g., EPC) 100 (1712), according to some embodiments. The QoS request to the core network may specify the desired QoS characteristics for a dedicated pipeline (e.g., end-to-end bearer) for application traffic between the UE 106 and app server 320. The elements of the core network may check the application profile, and, in response to a successful verification, acknowledge the request (1714) and instruct the SCEF 1660 and/or PGW 716 (and in turn the RAN) to establish the dedicated bearer for the application data flow or flows between the UE 106 and the App server 320. The dedicated bearer may be a dedicated end-to-end pipeline from the UE 106 to the app server 320, e.g., including any component connections (e.g., UE 106 to base station 102, base station 102 to gateway 716, gateway 716 to any intermediate network elements, intermediate network elements to app server 320, etc.) Each component connection of the dedicated end-to-end pipeline may be configured so that the entire end-to-end pipeline provides the desired QoS. For example, each of the component connections may be configured to meet or exceed the desired QoS. After the dedicated bearer (e.g., 350) is established, the core network may transmit a notification indicating the enhanced QoS to the UE (1716). The UE 106 may in turn confirm the QoS to the app 710 (1718). The application 710 and the app server 320 may exchange data using the dedicated bearer 350.).
Examiner’s comments: Zhao explicitly discloses utilizing web-based application-layer transport protocols to convey session notification messages and parameters between network elements and an authorized application servers (see Fig. 17; paragraphs [0150] and [0163] of Zhao). Specifically, Zhao discloses that various session control messages, objects, and configuration information elements may be transported using web-standard communication protocols, explicitly including HyperText Transfer Protocol (HTTP) and HTTP secure (para [0150] of Zhao). Zhao further discloses a session lifecycle flow wherein core network functions process and transmit status notification messages (such as “notification indicating the enhanced QoS”) to ensure synchronization with the destination Application Server 320 within the data network (para [0163] of Zhao; Fig. 17, step 1716).
Under the Broadest Reasonable Interpretation (BRI), a person of ordinary skill in the art would recognize that within standard HTTP/HTTPs-based web REST API framework, a server or exposure function asynchronously pushes event updates or session status response back to an external application server by executing a routine web operation targeting a destination address (see Fig. 13 of Zhao)-specifically, a Callback Uniform Resource Locator (URL)-which is pre-provisioned and included within the incoming request payload. Thus, Zhao teaches the sending the subscription identifier and the QoS status via a callback uniform resource locator (URL) included in the service request.
Regarding Claim 12, Li and Fitzmaurice teach The one or more network devices of claim 11, Li teaches wherein the one or more network devices serve as an application function that interfaces with the data network and the exposure function in the core network (para [0097]: FIG. 14 shows an example procedure for cloud application workload offloading and data preprocessing. In the example procedure, cloud applications interact with the 6G system’s Service Exposure Function (SEF) to inquire about system services and request for services. The SEF may act as a bridge between the 6G system and external systems. … the requested application service may be registered in the Service Registry and informed to the SOCF (the SEF and SOCF is interpreted as “one or more network devices”)); and
Li and Fitzmaurice fail to explicitly teach wherein, when receiving the service request, the one or more processor are further configured to: receive the service request via a dedicated application programming interface (API) using Internet Protocol.
Zhao, in analogous art of application-specific QoS session handling and network resource management, explicitly discloses providing a dedicated application programming interface (API) running over standard internet transport protocols to process network configuration and QoS requests. Specifically, Zhao teaches:
wherein, when receiving the service request, the one or more processor are further configured to: receive the service request via a dedicated application programming interface (API) using Internet Protocol (para [0085] of Zhao: The request may be received via an application programming interface (API), e.g., a QoS API. A QoS API may provide an interface for applications executing on the UE to request enhanced QoS for communications with an application server (e.g., the application server 320) (para [0086] of Zhao: The request may indicate various details about the requested QoS for communications of the application with the application server 320. For example, the request may indicate QoS parameters such as latency, throughput, jitter, error rate, etc., e.g., for communication with server 320. Further, the request may indicate routing information associated with the requested QoS. For example, the request may indicate address information for one or more application servers 320.) (para [0150] of Zhao: It will be appreciated that various other transport protocols (e.g., instead of or in addition to RSVP) may be used transport the various messages, objects, information elements, etc. of FIG. 9-14. Among various possibilities, any of the following protocols may be used: HyperText Transfer Protocol (HTTP), HTTP Secure (HTTPs), and/or stream control transfer protocol (SCTP)).
It would have been obvious to a person of ordinary skill in the art at the time the invention was made to modify the service exposure framework of Li by incorporating the IP-based dedicated API mechanism as taught by Zhao. A person of ordinary skill in the art would recognize that HTTP and HTTPs protocols explicitly operate over the standard Internet Protocol (IP) suite (TCP/IP). Therefore, under the Broadest Reasonable Interpretation (BRI), executing a request via an HTTP/HTTPs-based QoS API represents receiving the service request via a dedicated API using Internet Protocol.
Regarding Claim 13, Li, Fitzmaurice, and Zhao teach The one or more network devices of claim 12, wherein the one or more processor are further configured to: Zhao further teaches:
send, using the dedicated API, a subscription identifier and quality of service (QOS) status for a flow associated with the service request (para [0008]: The UE may transmit a request to the network for a dedicated bearer or enhanced QoS flow for the application traffic. The UE may indicate requested QoS configuration parameters and other parameters for the bearer/flow.)(para [0009]: The UE may use an extended Resource ReSerVation Protocol (RSVP) to communicate about the request and associated parameters with the network.)(para [0092]: The Resv message may include a “3GPP QoS Object” as further described below. The object may include application profile and QoS information (interpreted as “a subscription identifier and quality of service (QOS) status”), e.g., which may be necessary for the PGW/PCEF to grant the request and/or to implement the dedicated bearer for the application.) (para [0085] of Zhao: The request may be received via an application programming interface (API), e.g., a QoS API. A QoS API may provide an interface for applications executing on the UE to request enhanced QoS for communications with an application server (e.g., the application server 320).
Regarding Claim 17, Claim 17, has similar limitation as of Claim(s) 10, therefore it is rejected under the same reasons as Claim(s) 10.
Regarding Claim 19, Li and Fitzmaurice teach The non-transitory computer-readable medium of claim 18, further comprising one or more instructions for: Li and Fitzmaurice fail to teach:
receiving the service request via a dedicated API using Internet Protocol; and
sending, to an external network function and using the dedicated API, a subscription identifier and quality of service (QoS) status for a flow associated with the service request.
Zhao, in analogous art of application-specific QoS session handling and network resource management, explicitly discloses providing a dedicated application programming interface (API) running over standard internet transport protocols to process network configuration and QoS requests. Specifically, Zhao teaches:
receiving the service request via a dedicated API using Internet Protocol (para [0085]: The request may be received via an application programming interface (API), e.g., a QoS API. A QoS API may provide an interface for applications executing on the UE to request enhanced QoS for communications with an application server (e.g., the application server 320) (para [0111]: The request may be transmitted over user datagram protocol (UDP) port 3455 (The UDP is interpreted as “Internet Protocol”),…); and
send, to an external network function and using the dedicated API, a subscription identifier and quality of service (QOS) status for a flow associated with the service request (para [0008]: The UE may transmit a request to the network for a dedicated bearer or enhanced QoS flow for the application traffic. The UE may indicate requested QoS configuration parameters and other parameters for the bearer/flow.)(para [0009]: The UE may use an extended Resource ReSerVation Protocol (RSVP) to communicate about the request and associated parameters with the network.)(para [0092]: The Resv message may include a “3GPP QoS Object” as further described below. The object may include application profile and QoS information (interpreted as “a subscription identifier and quality of service (QOS) status”), e.g., which may be necessary for the PGW/PCEF to grant the request and/or to implement the dedicated bearer for the application.).
It would have been obvious to a person of ordinary skill in the art at the time the invention was made to modify the service exposure framework of Li by incorporating the IP-based dedicated API mechanism as taught by Zhao. One of ordinary skill in the art would have been motivated to implement this combination because Li relies on a Service Exposure Function (SEF) or Network Exposure Function (NEF) to expose internal cellular capabilities to third-party data network application (para [0097] of Li).
Regarding Claim 20, Claim 20, has similar limitation as of Claim(s) 10, therefore it is rejected under the same reasons as Claim(s) 10.
Claim(s) 4, 14, and 15 rejected under 35 U.S.C. 103 as being unpatentable over Li and Fitzmaurice and further in view of 3GPP Technical Specification 23.501 V16.16.0 (uploaded date: March 31, 2023) (hereinafter “3GPP TS 23.501”).
Examiner’s note: in what follows, references are drawn to Zhao unless otherwise mentioned.
Regarding Claim 4, Li and Fitzmaurice teaches The method of claim 1, Li and Fitzmaurice do not explicitly teach wherein sending the network configuration request includes sending the network configuration request to the exposure function (para [0097]: The SOCF can then select proper Comp SF/Data SF, deploy the application service instances (interpreted as “generating, by the network device, a network configuration request for a core network, based on information in the service request”), and send the updated service chain info to RAN CP and Comp SF, which then update RAN UP and Comp SF a related routing path according to the updated service chain.)) via one of a T8 interface or an N33 interface.
It is noted that while disclosing the claimed feature “sending the network configuration request to the exposure function” (see para [0097] of Li), Li and Fitzmaurice do not explicitly teach the via T8 interface or N33 interface.
It, however, had been known in the art before the effective date of the instant application as shown by 3GPP TS 23.501, page 238, as follows; … For external exposure of services related to specific UE(s), the SCEF+NEF resides in the HPLMN. Depending on operator agreements, the SCEF+NEF in the HPLMN may have interface(s) with NF(s)(“Network Function(s)”) in the VPLMN.) (Also see Figure 4.3.5.1 of 3GPP TS 23.501, page 65).
PNG
media_image1.png
200
400
media_image1.png
Greyscale
(Figure 4.3.5.1 of 3GPP TS 23.501, page 65)
Therefore, it would have been obvious to one of ordinary skill in the art at the time of instant application to modify the combination of Li and Fitzmaurice by using a T8 interface or an N33 interface defined in 3GPP Technical Specification 23.501 in order to have sent the network configuration request to the exposure function via the one of a T8 interface or an N33 interface (see page 238 of 3GPP TS 23.501 V16.16.0).
Regarding Claim 14, Claim 14, has similar limitation as of Claim(s) 4, therefore it is rejected under the same reasons as Claim(s) 4.
Regarding Claim 15, Claim 15, has similar limitation as of Claim(s) 4, therefore it is rejected under the same reasons as Claim(s) 4.
Claim(s) 16 rejected under 35 U.S.C. 103 as being unpatentable over Li, Fitzmaurice, Zhao, and further in view of 3GPP TS 23.501.
Regarding Claim 16, Li and Fitzmaurice teach The one or more network device of claim 11, Li and Fitzmaurice fail to explicitly teach wherein the service request includes: a requested quality of service (QoS) level for a service flow, an application identifier, an application IP address, a user equipment (UE) IP address, and a duration for terminating the requested service.
Zhao, in an analogous art of mobile wireless network managing QoS and policy control, teaches: wherein the service request includes: (FIGs. 9-14 and para [0111] of Zhao: For example, the request may include any or all of:
a requested quality of service (QOS) level for a service flow (para [0113] of Zhao: Flow information, including treatment and differentiated services code point (DSCP) values, e.g., to indicate QoS requirements of the application traffic (interpreted as “a requested quality of service (QOS) level for a flow”),
an application identifier (para [0112] of Zhao: Application information, such as Application ID (interpreted as “an application identifier”), Name, Vendor, e.g., to identify the app and/or traffic of the app.),
an application IP address (FIG. 12 and para [0138]: The Ipv4 TFT IE may carry the IP filter information for PGW to identify and route flows associated with the application…) (“source IP address” in FIG. 12 is interpreted as “an application IP address”)
a user equipment (UE) IP address a user equipment (UE) IP address (FIG. 12 and para [0138]: The Ipv4 TFT IE may carry the IP filter information for PGW to identify and route flows associated with the application…)(“Destination IP address” in FIG. 12 is interpreted as “a user equipment (UE) IP address”), and
It would have been obvious to a person of ordinary skill in the art at the time the invention was made to modify the service request messaging framework of Li by incorporating the specific application, flow, and packet filtering parameters (Application ID, DSCP QoS values, ports, and IP routing addresses) taught by Zhao. One of ordinary skill in the art would have been motivated to implement this combination because the combination of Li and Fitzmaurice discloses establishing service chains and dedicated bearers to handle application data traffic (see paragraphs [0082] and [0103] of Li), but requires a precise filtering mechanism to identify which specific packets belong to the requested application flow. Integrating the packet filtering fields (such as Source/Destination ports and IP addresses within a Traffic Flow Template IE structure) as taught in Zhao provides the exact structural payload necessary for the core network to successfully identify and steer the requested differentiated QoS flow. The application of standard packet-filtering attributes (Application ID, QoS level, Port numbers, and destination addresses/URLs) to define a service request payload is a routine and predictable practice in 3GPP and IP-based network architecture to achieve reliable session management.
A combination of Li, Fitzmaurice and Zhao, however, fails to explicitly teach a duration for terminating the requested service.
It, however, had been known in the art before the effective date of the instant application as shown by 3GPP TS 23.501, as follows.
In page 119, Table 5.6.7-1 of 3GPP TS 23.501: discloses “Information element contained in AF request”. In Table 5.6.7-1, 3GPP TS 23.501 discloses the information of “Temporal Validity Condition : Time interval(s) or duration(s)”. In page 121, 3GPP TS 23.501 discloses that “Temporal validity condition. This is provided in the form of time interval(s) or duration(s) during which the AF request is to be applied.”
Therefore, it would have been obvious to one of ordinary skill in the art at the time of instant application to modify the service request messaging framework of the combination of Li, Fitzmaurice and Zhao by incorporating Time interval(s) or duration(s) defined in 3GPP Technical Specification 23.501.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to WON JUN CHOI whose telephone number is (703)756-1695. The examiner can normally be reached MON-FRI 08:00 - 17:00.
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, Derrick W Ferris can be reached at 571-272-3123. 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.
/WON JUN CHOI/Examiner, Art Unit 2411
/DERRICK W FERRIS/Supervisory Patent Examiner, Art Unit 2411
Prosecution Insights