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 07/13/2026 has been entered.
Response to Amendment/Remarks
This communication is considered fully responsive to the amendment filed on 06/12/2026.
Claims 1-7, 9-17, 19-22 are pending and are examined in this office action.
Claims 1, 10, 11, 20, have been amended.
No new claim has been added and claims 8, 18 have been canceled.
Response to Arguments
Applicant’s arguments, filed on 06/12/2026, with respect to claims have been considered but are moot. The Examiner found features modified to claims, i.e claim 1 as
“1. (Currently Amended) A device comprising: a processor to:
receive, at a Network Exposure Function (NEF) node or a Service Capability Exposure Function (SCEF) node, a request from a User Equipment (UE) device to register termination information, which includes an Internet Protocol (IP) address assigned to an application hosted on the UE device, for the application when a Protocol Data Unit (PDU) session or a Packet Data Network (PDN) session is established between the application and a network;
insert, into a routing table on the device, the termination information including the IP address assigned to the application hosted on the UE device in response to receiving the request;
receive data originating from the application on the UE device or from an application function (AF) node;
translate the received data using the routing table; and
forward the translated data to the application on the UE device or to the AF node..”
In view of the applicant’s amendment to the claims, the examiner has clarified and remapped the rejection to the argued claim limitations in details, using the prior art of record in the current prosecution of the claims as well a new prior art. See Aravind et al. (US 20220174757 A1; hereinafter as “Aravind”).
Regarding all dependent claims: the applicant alleges that all dependent claims are allowable since they depend from all the independent claims above. The examiner respectfully disagrees in view of the above explanation of independent claims.
Priority
The later-filed application must be an application for a patent for an invention which is also disclosed in the prior application (the parent or original nonprovisional application or provisional application). The disclosure of the invention in the parent application and in the later-filed application must be sufficient to comply with the requirements of 35 U.S.C. 112(a) or the first paragraph of pre-AIA 35 U.S.C. 112, except for the best mode requirement. See Transco Products, Inc. v. Performance Contracting, Inc., 38 F.3d 551, 32 USPQ2d 1077 (Fed. Cir. 1994).
The disclosure of the prior-filed application, U.S Application No. 16/109,926 ( Filing Date 08/23/2018), fails to provide adequate support or enablement in the manner provided by 35 U.S.C. 112(a) or pre-AIA 35 U.S.C. 112, first paragraph for one or more claims of this application. See MPEP § 211.05(I)(A).
In particular, the examiner fails to find support for “receive, at a Network Exposure Function (NEF) node or a Service Capability Exposure Function (SCEF) node, a request from a User Equipment (UE) device to register termination information, which includes an Internet Protocol (IP) address assigned to an application hosted on the UE device, for the application when a Protocol Data Unit (PDU) session or a Packet Data Network (PDN) session is established between the application and a network;
insert, into a routing table on the device, the termination information including the IP address assigned to the application hosted on the UE device in response to receiving the request;” as required by independent claims 1, 11, 20.
Closest support in Fig. 1 shows that FEN/SCEF 220 receives IP path from UE Device 104, paragraphs 0032, 0062 shows that NEF/SCEF register UE device but it does show amendment claim as shown above.
PNG
media_image1.png
644
545
media_image1.png
Greyscale
None of the priority documents explicitly or implicitly disclose claim limitations as required by all independent claims. Therefore, the effective filing date of the application has been deemed to be the filing date, 06/15/2023, of the instant application.
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-7, 9-17, 19-22 are rejected under 35 U.S.C. 103 as being unpatentable over ZHAO et al. (US 20200275304 A1; hereinafter as “ZHAO ”) in view of Aravind et al. (US 20220174757 A1; hereinafter as “Aravind”).
Examiner’s note: in what follows, references are drawn to ZHAO unless otherwise mentioned.
With respect to independence claim:
Regarding claim 1, ZHAO teaches,
A device (see fig. 16, Fig. 17-18: SCEF or NEF of SWG ] ) comprising:
PNG
media_image2.png
239
421
media_image2.png
Greyscale
PNG
media_image3.png
545
828
media_image3.png
Greyscale
a processor ( processor : [0056] ) to:
receive, at a Network Exposure Function (NEF) node or a Service Capability Exposure Function (SCEF) node (fig. 16 or Fig. 17-18 NEF or SCEF), a request from a User Equipment (UE) device to register termination information (fig. 18 1802, 1804 : “the UE 106 may send a “QoS message” (==empty QoS Spec) to the SCEF 1660 .. indicating to release (==termination information in claim) the dedicated bearer (1804). The message (==QoS message, empty QoS_Spec ) may include an empty QoS specification, e.g., to indicate that a default bearer may be used and that the dedicated bearer is no longer desired (==register termination information ). [0164]-[0165]; It will be appreciated that the release process of FIG. 18 may be followed by establishing a new dedicated pipeline, e.g., with different (or possibly the same) QoS characteristics. For example, the QoS request 1802 may specify a change in the desired QoS. Accordingly, the initial dedicated pipeline may be released as shown and a new pipeline may be established with the changed QoS. For example, such a replacement pipeline may be established using messaging as described above with respect to 1708-1718.”: [0168]; see fig. 18 element 1802, 1804; [0169];“ The App 710 may send a QoS release message to the UE 106 (1802). In response, the UE 106 may send a QoS message to t… NEF 1920 indicating to release the enhanced QoS flow 1950 (1804). The message may include an empty QoS specification, e.g., to indicate that a default (or other) flow may be used and that the enhanced QoS flow 1950 is no longer desired. ”: [0180]; aforesaid Application QoS Request Message include, inter alia, Application ID, Name, Vendor, ie. Identify the APP and/or traffic of the APP ),
which includes an Internet Protocol (IP) address assigned to an application hosted on the UE device, for the application when a Protocol Data Unit (PDU) session or a Packet Data Network (PDN) session is established between the application and a network ( “ App may send a QoS release message to the UE 106 (1802). Among various possibilities, such a release message may be sent through a QoS API. The release message may be sent in association with the user exiting the app, completing a game, or more generally the enhanced QoS being no longer required for the App”: [0164-[0167]; ] “ It will be appreciated that the release process of FIG. 21 may be followed by establishing a new dedicated pipeline, e.g., with different (or possibly the same) QoS characteristics. For example, the QoS request 1802 may specify a change in the desired QoS.”: [0181]; see fig. 1 element 1716: Establish Dedicated Bearer between UE (==ie. application/APP installed in UE ) and App server/Core Network : [0163]; : fig. 10 where Application QoS Release Message (==QOS object ) include IP address as IPv4 or IPv6 for Application running on UE : [0136]; Application QoS Release or request includes, inter alia, Application Information IPv2 or IPv6 , QOS information : [0141], “UE 106 and network may establish a default bearer and the SCEF 1660 and/or PGW 716 may transmit a notification of the attachment to the UE.”: [0161]; “ 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 (==network).”: [0163]; see fig. 12 where IPv4 TFT ( traffic flow Template) includes, 4 byes Source IP address (==IP address of UE or IP address of the APP inside an UE ), 2 bytes Source Port, 4 bytes : Destination IP address etc. : [0138]-[0139]; “ the request (==QOS Release Request ) may indicate address information (==IP Source address for UE where APP in installed ) for one or more application servers 320.”: [0086] ;
receive data originating from the application on the UE device or from an application function (AF) node ( see fig. 18: APP of UE which is installed in the UE is sending QoS Req to UE which aforesaid UE sending to SEEF in Fig. 18: “ the App 710 (==the application in claim ) may send a QoS release message to the UE 106 (1802). Among various possibilities, such a release message may be sent through a QoS API. The release message may be sent in association with the user exiting the app, completing a game, or more generally the enhanced QoS being no longer required for the App 710.
[0165] In response, the UE 106 may send a QoS message to the SCEF 1660 … indicating to release the dedicated bearer (1804). The message may include an empty QoS specification, e.g., to indicate that a default bearer may be used and that the dedicated bearer is no longer desired.”: [0164]-[0165]).
While ZHAO teaches, “which includes an Internet Protocol (IP) address assigned to an application hosted on the UE device, for the application when a Protocol Data Unit (PDU) session or a Packet Data Network (PDN) session is established between the application and a network”;
ZHAO does not expressively disclose:
insert, into a routing table on the device, the termination information including the IP address assigned to the application hosted on the UE device in response to receiving the request;
translate the received data using the routing table; and
forward the translated data to the application on the UE device or to the AF node.
Aravind, in the same field of endeavor, discloses:
insert, into a routing table on the device, the termination information including the IP address assigned to the application hosted on the UE device in response to receiving the request (see fig. 1 Fig. 4 User Equipment 402 (==the UE device in claim ) and application function 406 establishes connection via NEF 410 :[0037]-[0038]; Aforesaid NEF extract and/or retrieve aforesaid User Equipment context information, including IP address and port Identifier of the user equipment : [0050]; “ NEF 410 can extract and/or retrieve the user equipment context information, including source IP address and port identifier, from the encapsulated TCP packet. Afterwards, NEF 410 may extract the encapsulated TCP/IP payload which can be sent as NIDD MO submit messages to the application function 406 over unified interface 408, e.g., a T8/N33 interface, (e.g., using a context identifier retrieved from context data information for user equipment 402) created during the NIDD configuration procedure.”: [0050]; “ … NEF 410 stores the user equipment's IP address in the user equipment context information (e.g., UE context data table 600) (==inset into a routing table) and processes the MO and MT messages communicated between UE 402 and application function 406. In particular, NEF 410 receives the MO IP data messages from UPF 430 over an N6 interface. NEF 410 subsequently retrieves and/or extracts the application payload from the received TCP/IP packets and encapsulates the MO message in a T8/N33 message that is sent to application function 406 using TLTRI (e.g., NIDD configuration context identifier). ”: [0053]);
translate the received data using the routing table ( “ … NEF 410 can receive a MT message from application function 406 over unified interface 408 (e.g., T8/N33 interface) and can be configured to subsequently extract (e.g., decrypt) and/or retrieve the data payload from the encapsulated message. Notably, NEF 410 constructs the TCP/IP payload message using an application payload and subsequently sends the message to UE 402 via UPF 430 using the user equipment IP address.”: [0053]); and
forward the translated data to the application on the UE device or to the AF node (“:In particular, NEF 410 receives the MO IP data messages from UPF 430 over an N6 interface. NEF 410 subsequently retrieves and/or extracts the application payload from the received TCP/IP packets and encapsulates the MO message in a T8/N33 message that is sent to application function 406 using TLTRI (e.g., NIDD configuration context identifier). ”: [0053]).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of ZHAO to include the above recited limitations as taught by ARAVIND.
Aforesaid QoS request message or QoS Release Request Message in ZHAO could be a MO (MT) message in Aravind. The SCEF/PGW in ZAHO can be the NEF in Aravind which can be used to communicate User Equipment (UE or MO or MT) with Application Function in both ZHAO and ARAVIND . The suggestion/motivation would be to improve methods and systems for providing a unified interface configured to support infrequent communications via a network exposure function or service from User Equipment (UE or MO or MT) with Application Function . : (ARAVIND; [0003]).
Regarding claim 11, ZHAO teaches,
A method comprising:
receiving, at a Network Exposure Function (NEF) node or a Service Capability Exposure Function node, a request from a User Equipment (UE) device to register termination information, which includes an Internet Protocol (IP) address assigned to an application hosted on the UE device, for the application when a Protocol Data Unit (PDU)session or a Packet Data Network (PDN) session is established between the application and a network;
inserting, into a routing table on the device, the termination information including the IP address assigned to the application hosted on the UE device in response to receiving the request;
receiving data originating from the application on the UE device or from an application function (AF) node;
translating the received data using the routing table; and
forwarding the translated data to the application on the UE device or to the AF node (Regarding claim 11, the claim is interpreted and rejected for the same reason as set forth in claim 1).
Regarding claim 20 , ZHAO teaches, A non-transitory computer-readable medium comprising processor-executable instructions, which when executed by a processor causes the processor to:
receive, at a Network Exposure Function (NEF) node or a Service Capability Exposure Function (SCEF) node, a request from a User Equipment (UE) device to register termination information, which includes an Internet Protocol (IP) address assigned to an application hosted on the UE device, for the application when a Protocol Data Unit (PDU) session or a Packet Data Network (PDN) session is established between the application and a network;
insert, into a routing table on the device, the termination information including the IP address assigned to the application hosted on the UE device in response to receiving the request; receive data originating from the application on the UE device or from an application function (AF) node; translate the received data using the routing table; and forward the translated data to the application on the UE device or to the AF node.
( Regarding claim 20, the claim is interpreted and rejected for the same reason as set forth in claim 1).
With respect to dependence claim:
Regarding claim 2, ZHAO in view of ARAVIND teaches the invention of claim 1 as set forth above. Further, ZHAO teaches, The device of claim 1, wherein the UE device is configured to:
send a second request to register the termination information when the processor does not send an acknowledgment message in response to the request within a predetermined time ( timer setup to send another signal, “ A UE (e.g., UE 106 or other wireless device) may start an application (602). The application may execute on the UE, e.g., using one or more processors of the UE. The application may be initiated or launched by the user of the UE, or may be initiated based on other factors (e.g., a timer, a signal from an application server 320, etc.). The application may be any type of application, e.g., including music, video, voice or video calling, gaming, news, productivity, etc. The application may be configured to communicate with an application server 320 and may require or benefit from certain QoS characteristics for the communication of data between the UE and application server.”: [0083]).
Regarding claim 3, ZHAO in view of ARAVIND teaches the invention of claim 1 as set forth above. Further, ZHAO teaches, wherein the network includes a User Plane Function (UPF) node and when the processor receives data originating from the application on the UE device, the processor is to: receive the data via the UPF node (see fig. 19: Core Network include UPF node : “ 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. However, such options may not be widely available or effective. For example, there may be no standard Protocol/Message/Context between server and UPF/NEF in 5G. Thus, interoperability issues may complicate deployment and scalability.”: [0171]).
Regarding claim 4, ZHAO in view of ARAVIND teaches the invention of claim 1 as set forth above. Further, ZHAO teaches,
The device of claim 1, wherein the network includes a User Plane Function (UPF) node (see fig. 19: UPF and Code Network : [0171]) , and when the processor receives data originating from the AF node, the processor is to: forward the translated data to the UE device via the UPF node (use UPF to communicate with application server and core network : [0171]-[0172]).
Regarding claim 5, ZHAO in view of ARAVIND teaches the invention of claim 4 as set forth above. Further, ZHAO teaches, the device of claim 4, wherein the UPF node is configured to:
receive a Policy and Charging Control (PCC) rule from a Policy Control Function (PCF) node included in the network, wherein the PCC rule instructs the UPF node to direct Internet Protocol (IP) data, to the device, to be translated and redirected to the AF node ( UPF/PGW to enforces rules: works with PCF: [0091]-[0095]).
Regarding claim 6, ZHAO in view of ARAVIND teaches the invention of claim 1 as set forth above. Further, ARAVIND teaches, The device of claim 1, wherein the received data includes an Internet Protocol (IP) data that originated from the UE device, and wherein the translated data includes T8 data (Core Network uses T8 interface from application server (AF) to core network ; NEF receives UE’s IP address and translate in T8 interface to : [0053]; “ To facilitate the communication path(s), an N33/T8 interface between application function 106 and NEF 114 is established by the NEF. Once the communication path through control plane 104 is established, user equipment 102 and application function 106 can communicate small and infrequent data over 5G system 100. Specifically, NEF based NIDD data communication provides an API based interface (i.e., a T8/N33 interface) towards application function 106 for both MO and MT message communication between user equipment 102 and application function 106 over control plane 104. As such, NEF 114 serves and functions as a PDU session anchor for the data delivery path in this scenario”[0031]).
Regarding claim 7, ZHAO in view of ARAVIND teaches the invention of claim 1 as set forth above. Further, ARAVIND teaches, the device of claim 1, wherein the received data includes T8 data that originated from the AF node, and wherein the translated data includes IP data (Core Network uses T8 interface from application server (AF) to core network ; NEF receives UE’s IP address and translate in T8 interface to : [0053]; “ To facilitate the communication path(s), an N33/T8 interface between application function 106 and NEF 114 is established by the NEF. Once the communication path through control plane 104 is established, user equipment 102 and application function 106 can communicate small and infrequent data over 5G system 100. Specifically, NEF based NIDD data communication provides an API based interface (i.e., a T8/N33 interface) towards application function 106 for both MO and MT message communication between user equipment 102 and application function 106 over control plane 104. As such, NEF 114 serves and functions as a PDU session anchor for the data delivery path in this scenario”[0031]).
Regarding claim 9, ZHAO in view of ARAVIND teaches the invention of claim 1 as set forth above. Further, ZHAO teaches,
The device of claim 1, wherein the termination information further comprises at least one of:
an identifier (ID) of the UE device (UE ID); a port number associated with the application;
an Internet Protocol (IP) address of the application; a fully qualified domain name (FQDN) of the AF node; a Universal Resource Locator (URL) or a Universal Resource Identifier (URI) of the AF node; a port number of the AF node; or an IP address of the AF node ( “ If the verification returns a positive result, the UE may determine to grant the request. Accordingly, the QoS agent 712 may transmit an RSVP Resv request to the PGW 716/SGW 717 in the 3GPP core network (803). The request may be transmitted over user datagram protocol (UDP) port 3455, 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. For example, the request may include any or all of:
[0112] Application information, such as Application ID, Name, Vendor, e.g., to identify the app and/or traffic of the app. ”: [0111]-[0112]).
Regarding claim 10, ZHAO in view of ARAVIND teaches the invention of claim 1 as set forth above. Further, ZHAO teaches, The device of claim 1, wherein the processor: receives a second request, from the UE device when the PDU session or the PDN session ends, to deregister the termination information; and remove the termination information from the routing table in response to receiving the second request ( “ release of the dedicated bearer. As shown, a dedicated bearer may be established between a UE 106 and SCEF 1660 and/or PGW 716 (1716) and may extend to app server 320 (not shown). The App 710 may send a QoS release message to the UE 106 (1802). Among various possibilities, such a release message may be sent through a QoS API. The release message may be sent in association with the user exiting the app, completing a game, or more generally the enhanced QoS being no longer required for the App 710.”: [0164]; “ the UE 106 may send a QoS message to the SCEF 1660 and/or PGW 716 indicating to release the dedicated bearer (1804). The message may include an empty QoS specification, e.g., to indicate that a default bearer may be used and that the dedicated bearer is no longer desired.”: [0165]-[0168]).
Regarding claim 12, the claim is interpreted and rejected for the same reason as set forth in claim 2.
Regarding claim 13, the claim is interpreted and rejected for the same reason as set forth in claim 3.
Regarding claim 14, the claim is interpreted and rejected for the same reason as set forth in claim 4.
Regarding claim 15, the claim is interpreted and rejected for the same reason as set forth in claim 5.
Regarding claim 16, the claim is interpreted and rejected for the same reason as set forth in claim 6.
Regarding claim 17, the claim is interpreted and rejected for the same reason as set forth in claim 7.
Regarding claim 19, the claim is interpreted and rejected for the same reason as set forth in claim 9.
Regarding claim 21, the claim is interpreted and rejected for the same reason as set forth in claim 2.
Regarding claim 22, the claim is interpreted and rejected for the same reason as set forth in claim 3.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to M MOSTAZIR RAHMAN whose telephone number is (571)272-4785. The examiner can normally be reached 8:30am-5:00pm PST.
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 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.
/M Mostazir Rahman/Examiner, Art Unit 2411 /DERRICK W FERRIS/Supervisory Patent Examiner, Art Unit 2411
Prosecution Insights