Prosecution Insights
Last updated: April 19, 2026
Application No. 18/710,589

SUPPORT FOR APPLICATION DATA UNIT BASED QUALITY OF SERVICE

Non-Final OA §102§103
Filed
May 15, 2024
Examiner
WOO, ANDREW M
Art Unit
2441
Tech Center
2400 — Computer Networks
Assignee
Qualcomm Incorporated
OA Round
1 (Non-Final)
83%
Grant Probability
Favorable
1-2
OA Rounds
2y 10m
To Grant
99%
With Interview

Examiner Intelligence

Grants 83% — above average
83%
Career Allow Rate
472 granted / 570 resolved
+24.8% vs TC avg
Strong +45% interview lift
Without
With
+45.0%
Interview Lift
resolved cases with interview
Typical timeline
2y 10m
Avg Prosecution
14 currently pending
Career history
584
Total Applications
across all art units

Statute-Specific Performance

§101
13.1%
-26.9% vs TC avg
§103
43.3%
+3.3% vs TC avg
§102
18.8%
-21.2% vs TC avg
§112
14.4%
-25.6% vs TC avg
Black line = Tech Center average estimate • Based on career data from 570 resolved cases

Office Action

§102 §103
DETAILED ACTION The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . The application has been examined. Claims 1-30 are pending. Information Disclosure Statement The information disclosure statement (IDS) submitted on 05/15/2024. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner. Priority Acknowledgment is made of applicant’s claim for foreign priority under 35 U.S.C. 119 (a)-(d). The certified copy has been filed in parent Application No. GR 20220100085, filed on 01/28/2022. Receipt is acknowledged of certified copies of papers required by 37 CFR 1.55. Claim Objections Claims 25-26 and 28-29 are objected to because of the following informalities: lack of terminology consistency Claim 25, line 8, recites “to the session” and should be changed to -- to the created session --. Similar changes are suggested to subsequent claims. Appropriate correction is required. Claim Rejections - 35 USC § 102 The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action: A person shall be entitled to a patent unless – (a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention. Claims 1-8, 10-20, and 22-30 are rejected under 35 U.S.C. 102(a)(1) as being unpatentable by Dao et al. (2020/0145876, hereinafter Dao). Regarding claim 1, Dao discloses a core network entity for wireless communication, comprising: a memory (Dao, para. 36); and a processor (Dao, para. 36) coupled to the memory, the processor and the memory being configured to: establish a session (Dao discloses that the PDU session establishment/modification procedure is based on the classification and marking of the UL user plane traffic associated to QoS flows based on QoS rules from the UE) (Dao, para. 133) that includes at least one of: application data unit (ADU) detection rules, or ADU handling rules related to a detection of ADUs in a user plane (Dao discloses that the SMF 310 may use the PDU session parameters provided by the UE 104 and/or connection management parameters provided by the AMF 308, and/or the application information provided by the AF, and/or user subscription data in the UDM 320, and/or the PCC rules from the PCF 316, to determine how to set the PHP parameters for one or more QoS flows of the requested PDU session) (Dao, para. 191); and determine, for one or more quality of service (QoS) flows (Dao discloses that each QoS flow basis consists of a dynamically assigned QFI, the QoS rule(s), and the QoS flow level QoS parameters) (Dao, para. 133), whether ADU awareness (Dao discloses that the management of the packet flow descriptions enables the UPF 304 to perform accurate application detection (awareness) when PFD(s) are provided by an application service provider and then to apply enforcement actions as instructed in the PCC rule) (Dao, para. 295) applies based on an application of the at least one of: the ADU detection rules, or the ADU handling rules (Dao discloses that the UE may send a packet handling indication to the CN indicating that the delayed packets or PDU of a QoS flow should be dropped/discarded or delivered; the UE packet handling indication, the CN CP functions, may create and send the PHP parameters to the user plane entities, such as the UE, RAN, and UPF) (Dao, para. 124). Regarding claim 2, Dao discloses the core network entity of claim 1, wherein the processor and the memory are further configured to: assign, in response to determining that ADU awareness applies, at least one ADU 5G QoS flow identifier (A5QI) (Dao discloses that each QoS profile has one corresponding QoS flow identifier (QFI), which has a dynamically assigned 5QI for a QoS flow) (Dao, para. 130) to at least one ADU aware QoS flow (Dao discloses that the PDU session establishment/modification procedure is based on the classification and marking of the UL user plane traffic associated to QoS flows based on QoS rules from the UE) (Dao, para. 133); and configure a radio access network (RAN) entity with the at least one A5QI and the at least one ADU aware QoS flow (Dao discloses that the RAN 302 sends the N2 message to the SMF 310 when the RAN 302 decides (configured) that the QoS targets for that QoS flow cannot be fulfilled or can be fulfilled again) (Dao, para. 226). Regarding claim 3, Dao discloses the core network entity of claim 2, wherein the A5QI is associated with ADU QoS parameters, and the ADU QoS parameters are included in at least one of: a table (Dao discloses that the RAN 302 receives PHP parameters associated with a QoS profile of a QoS flow, which may set its operational parameters accordingly) (Dao, para. 74, 340) of standardized 5G QoS flow Identifier (5Q1) related QoS parameters (Dao discloses that the N2 SM information carries information that the AMF 308 may provide to the RAN 302 that includes QoS profiles and the corresponding QFIs to notify the RAN 302 that one or more QoS flows were added, modified, or removed) (Dao, para. 230), or a table of standardized A5QI related QoS parameters. Regarding claim 4, Dao discloses the core network entity of claim 2, wherein the A5QI is associated with ADU QoS parameters, and the ADU QoS parameters include at least one of: a maximum ADU size, a maximum number of packet data units (PDUs) per ADU, an ADU delay budget, an ADU maximum data burst volume, or an ADU error rate (Dao discloses that the 5G QoS characteristics associated with the 5QI describes the QoS flow between the UE and UPF based the performance characteristics such as resource type, GBR, delay critical GBR or non-GBR, priority level, packet delay budget, packet error rate, maximum data burst volume) (Dao, para. 131). Regarding claim 5, Dao discloses the core network entity of claim 2, wherein parameters related to the at least one ADU aware QoS flow are provided in at least one of: a dedicated ADU QoS profile that includes QoS flow parameters exclusively related to the at least one A5QI, or a QoS profile that includes QoS flow parameters related to a 5G QoS flow identifier (5Q1) and the at least one A5QI (Dao discloses that each QoS profile has one corresponding QoS flow identifier (QFI), which has a dynamically assigned 5QI for a QoS flow; the RAN 302 may set operational parameters after receiving PHP parameters associated with a QoS profile of a QoS flow) (Dao, para. 130, 340). Regarding claim 6, Dao discloses the core network entity of claim 1, wherein the processor and the memory are further configured to: configure a user plane function (UPF) with at least one of: ADU aware filters, or the ADU detection rules (Dao discloses that the SMF 310 (UPF) may decide to modify a PDU session based on the trigger(s) of the locally configured policy or received report of a detected uplink or downlink PDUs that could be dropped/discarded or delivered packets that are delayed longer than a certain value) (Dao, para. 224). Regarding claim 7, Dao discloses the core network entity of claim 1, wherein the core network entity is a session management function (SMF) (Dao discloses that the SMF 310 communicates with other core network functions in a service based view through a service based interface) (Dao, para. 55), and the session is established with a user plane function (UPF) over an interface between the SMF and the UPF (Dao discloses that the SMF 310 may connect to a UPF 304 through a logical interface) (Dao, para. 55). Regarding claim 8, Dao discloses the core network entity of claim 1, wherein an ADU is comprised of a set of Internet Protocol (IP) packets or Ethernet frames jointly processed by at least one of: an application function, or an application server (Dao discloses that the application function (AF), which represents the control function of the application server, that sends an AF request to instruct the wireless network how to handle the packets) (Dao, para. 93). Regarding claim 10, Dao discloses the core network entity of claim 1, wherein the processor and the memory are further configured to: configure ADU aware uplink filters to a user equipment (Dao discloses that the PHP parameters, as part of a QoS rule, may be dynamically signaled to the UE on a per QoS flow basis) (Dao, para. 134) during at least one of: packet data unit (PDU) session establishment, or PDU session modification (Dao discloses that the N1 SM PDU session modification request, the UE 104 may indicate that the delayed packets of the QoS flow(s) that is/are associated with the packet filters shall be dropped/discarded or delivered; the SMF 310 may use the information to establish the downlink and uplink PHP parameters in the UE, RAN and UPF) (Dao, para. 218). Regarding claim 11, Dao discloses the core network entity of claim 1, wherein the processor and the memory are further configured to: obtain policy rules related to ADU-based QoS policies (Dao discloses that the SMF may create PHP parameters for the QoS profile in the RAN, and/or the QoS rules in the UE, and/or the packet detection rule in the UPF) (Dao, para. 121) from at least one of: a policy control function (PCF) (Dao, para. 242), or a local configuration (Dao, para. 242). Regarding claim 12, Dao discloses the core network entity of claim 1, wherein the processor and the memory are further configured to: obtain an identity of a user plane function that supports ADU-based QoS policies from a policy control function (PCF) (Dao discloses that the SMF 310 may use the input parameters from the PCF 316, where the PCF 316 provides some or all PHP parameters for the requested PDU session; the SMF 310 may send the PHP parameters to the UE 104 for the UL QoS flows, the PHP parameters to the RAN 302 for UL and DL QoS flows, the PHP parameters to the UPF 304 for UL and/or DL QoS flows) (Dao, para. 191). Regarding claim 13, Dao discloses a method at a core network entity, comprising: establishing a session (Dao discloses that the PDU session establishment/modification procedure is based on the classification and marking of the UL user plane traffic associated to QoS flows based on QoS rules from the UE) (Dao, para. 133) that includes at least one of: application data unit (ADU) detection rules, or ADU handling rules related to a detection of ADUs in a user plane (Dao discloses that the SMF 310 may use the PDU session parameters provided by the UE 104 and/or connection management parameters provided by the AMF 308, and/or the application information provided by the AF, and/or user subscription data in the UDM 320, and/or the PCC rules from the PCF 316, to determine how to set the PHP parameters for one or more QoS flows of the requested PDU session) (Dao, para. 191); and determining, for one or more quality of service (QOS) flows (Dao discloses that each QoS flow basis consists of a dynamically assigned QFI, the QoS rule(s), and the QoS flow level QoS parameters) (Dao, para. 133), whether ADU awareness (Dao discloses that the management of the packet flow descriptions enables the UPF 304 to perform accurate application detection (awareness) when PFD(s) are provided by an application service provider and then to apply enforcement actions as instructed in the PCC rule) (Dao, para. 295) applies based on an application of the at least one of: the ADU detection rules, or the ADU handling rules (Dao discloses that the UE may send a packet handling indication to the CN indicating that the delayed packets or PDU of a QoS flow should be dropped/discarded or delivered; the UE packet handling indication, the CN CP functions, may create and send the PHP parameters to the user plane entities, such as the UE, RAN, and UPF) (Dao, para. 124). Regarding claim 14, Dao discloses the method of claim 13, further comprising: assigning, in response to determining that ADU awareness applies, at least one ADU 5G QoS flow identifier (A5QI) (Dao discloses that each QoS profile has one corresponding QoS flow identifier (QFI), which has a dynamically assigned 5QI for a QoS flow) (Dao, para. 130) to at least one ADU aware QoS flow (Dao discloses that the PDU session establishment/modification procedure is based on the classification and marking of the UL user plane traffic associated to QoS flows based on QoS rules from the UE) (Dao, para. 133); and configuring a radio access network (RAN) entity with the at least one A5QI and the at least one ADU aware QoS flow (Dao discloses that the RAN 302 sends the N2 message to the SMF 310 when the RAN 302 decides (configured) that the QoS targets for that QoS flow cannot be fulfilled or can be fulfilled again) (Dao, para. 226). Regarding claim 15, Dao discloses the method of claim 14, wherein the A5QI is associated with ADU QoS parameters, and the ADU QoS parameters are included in at least one of: a table (Dao discloses that the RAN 302 receives PHP parameters associated with a QoS profile of a QoS flow, which may set its operational parameters accordingly) (Dao, para. 340) of standardized 5G QoS flow Identifier (5Q1) related QoS parameters (Dao discloses that the N2 SM information carries information that the AMF 308 may provide to the RAN 302 that includes QoS profiles and the corresponding QFIs to notify the RAN 302 that one or more QoS flows were added, modified, or removed) (Dao, para. 230), or a table of standardized A5QI related QoS parameters. Regarding claim 16, Dao discloses the method of claim 14, wherein the A5QI is associated with ADU QoS parameters, and the ADU QoS parameters include at least one of: a maximum ADU size, a maximum number of packet data units (PDUs) per ADU, an ADU delay budget, an ADU maximum data burst volume, or an ADU error rate (Dao discloses that the 5G QoS characteristics associated with the 5QI describes the QoS flow between the UE and UPF based the performance characteristics such as resource type, GBR, delay critical GBR or non-GBR, priority level, packet delay budget, packet error rate, maximum data burst volume) (Dao, para. 131). Regarding claim 17, Dao discloses the method of claim 14, wherein parameters related to the at least one ADU aware QoS flow are provided in at least one of: a dedicated ADU QoS profile that includes QoS flow parameters exclusively related to the at least one A5QI, or a QoS profile that includes QoS flow parameters related to a 5G QoS flow identifier (5Q1) and the at least one A5QI (Dao discloses that each QoS profile has one corresponding QoS flow identifier (QFI), which has a dynamically assigned 5QI for a QoS flow; the RAN 302 may set operational parameters after receiving PHP parameters associated with a QoS profile of a QoS flow) (Dao, para. 130, 340). Regarding claim 18, Dao discloses the method of claim 13, further comprising: configuring a user plane function (UPF) with at least one of: ADU aware filters, or the ADU detection rules (Dao discloses that the SMF 310 (UPF) may decide to modify a PDU session based on the trigger(s) of the locally configured policy or received report of a detected uplink or downlink PDUs that could be dropped/discarded or delivered packets that are delayed longer than a certain value) (Dao, para. 224). Regarding claim 19, Dao discloses the method of claim 13, wherein the core network entity is a session management function (SMF) (Dao discloses that the SMF 310 communicates with other core network functions in a service based view through a service based interface) (Dao, para. 55), and the session is established with a user plane function (UPF) over an interface between the SMF and the UPF (Dao discloses that the SMF 310 may connect to a UPF 304 through a logical interface) (Dao, para. 55). Regarding claim 20, Dao discloses the method of claim 13, wherein an ADU is comprised of a set of Internet Protocol (IP) packets or Ethernet frames jointly processed by at least one of: an application function, or an application server (Dao discloses that the application function (AF), which represents the control function of the application server, that sends an AF request to instruct the wireless network how to handle the packets) (Dao, para. 93). Regarding claim 22, Dao discloses the method of claim 13, further comprising: configuring ADU aware uplink filters to a user equipment (Dao discloses that the PHP parameters, as part of a QoS rule, may be dynamically signaled to the UE on a per QoS flow basis) (Dao, para. 134) during at least one of: packet data unit (PDU) session establishment, or PDU session modification (Dao discloses that the N1 SM PDU session modification request, the UE 104 may indicate that the delayed packets of the QoS flow(s) that is/are associated with the packet filters shall be dropped/discarded or delivered; the SMF 310 may use the information to establish the downlink and uplink PHP parameters in the UE, RAN and UPF) (Dao, para. 218). Regarding claim 23, Dao discloses the method of claim 13, further comprising: obtaining policy rules related to ADU-based QoS policies (Dao discloses that the SMF may create PHP parameters for the QoS profile in the RAN, and/or the QoS rules in the UE, and/or the packet detection rule in the UPF) (Dao, para. 121) from at least one of: a policy control function (PCF) (Dao, para. 242), or a local configuration (Dao, para. 242). Regarding claim 24, Dao discloses the method of claim 13, further comprising: obtaining an identity of a user plane function that supports ADU-based QoS policies from a policy control function (PCF) (Dao discloses that the SMF 310 may use the input parameters from the PCF 316, where the PCF 316 provides some or all PHP parameters for the requested PDU session; the SMF 310 may send the PHP parameters to the UE 104 for the UL QoS flows, the PHP parameters to the RAN 302 for UL and DL QoS flows, the PHP parameters to the UPF 304 for UL and/or DL QoS flows) (Dao, para. 191). Regarding claim 25, Dao discloses a core network entity for wireless communication, comprising: a memory (Dao, para. 36); and a processor (Dao, para. 36) coupled to the memory, the processor and the memory being configured to: transmit a request to create a session (Dao discloses that the PDU session establishment/modification procedure is based on the classification and marking of the UL user plane traffic associated to QoS flows based on QoS rules from the UE) (Dao, para. 133) that supports application data unit (ADU) based quality of service (QOS) flows (Dao discloses that each QoS flow basis consists of a dynamically assigned QFI, the QoS rule(s), and the QoS flow level QoS parameters) (Dao, para. 133), negotiate at least one of: ADU-based QoS policies, or ADU QoS rules applicable to the session (Dao discloses that the SMF 310 may send QoS enforcement rules and/or usage reporting rules, which includes information that defines the QoS enforcement of traffic or how traffic is identified by PDRs to be enforced and/or reported) (Dao, para. 286-287), and receive an acknowledgment of creation of the session in response to completing the negotiating (Dao discloses that in the initial request for a PDU session, the SMF 310 provide the PHP or the PHP parameters in its request to the UPF 304, which the UDF 304 acknowledges the request and allocates the CN tunnel) (Dao, para. 194). Regarding claim 26, Dao discloses the core network entity of claim 25, wherein the core network entity is an application function (AF) (Dao, para. 62), and the session is an AF session (Dao discloses that the service operation, npcf policy authorization, allows an AF to provide, update, delete application level information to the PCF; and the SMF communicates with the PCF to obtain and install the new policy, and policy updates according to the information, identification of the application session context, provided by the AF) (Dao, para. 244). Regarding claim 27, Dao discloses the core network entity of claim 25, wherein the request to create the session is transmitted to a network exposure function (NEF) (Dao discloses that the AF could provide or modify the PHP parameters by sending the npcf policy authorization create/update/ request message (create the session) directly to the PCF or via NEF) (Dao, para. 242) and the acknowledgment is received from the NEF if the core network entity is not a trusted core network entity (Dao discloses that NEF 314 is deployed in the network to allow servers, functions and other entities such as those outside a trusted domain (not a trusted core network) to have exposure to services and capabilities within the network) (Dao, para. 57), or the request to create the session is transmitted to a policy control function (PCF) and the acknowledgment is received from the PCF if the core network entity is a trusted core network entity (Dao discloses that the PCF 316 communicates with the UDR 340, where the PCF provides the policy profile information that governs access rights to the stored policy data which includes user subscription data, security credentials (authorized and acknowledged), access and mobility related subscription data and session related data (trusted core network entity)) (Dao, para. 61). Regarding claim 28, Dao discloses a method at a core network entity, comprising: transmitting a request to create a session (Dao discloses that the PDU session establishment/modification procedure is based on the classification and marking of the UL user plane traffic associated to QoS flows based on QoS rules from the UE) (Dao, para. 133) that supports application data unit (ADU) based quality of service (QOS) flows (Dao discloses that each QoS flow basis consists of a dynamically assigned QFI, the QoS rule(s), and the QoS flow level QoS parameters) (Dao, para. 133); negotiating at least one of: ADU-based QoS policies, or ADU QOS rules applicable to the session (Dao discloses that the SMF 310 may send QoS enforcement rules and/or usage reporting rules, which includes information that defines the QoS enforcement of traffic or how traffic is identified by PDRs to be enforced and/or reported) (Dao, para. 286-287); and receiving an acknowledgment of creation of the session in response to completing the negotiating (Dao discloses that in the initial request for a PDU session, the SMF 310 provide the PHP or the PHP parameters in its request to the UPF 304, which the UDF 304 acknowledges the request and allocates the CN tunnel) (Dao, para. 194). Regarding claim 29, Dao discloses the method of claim 28, wherein the core network entity is an application function (AF) (Dao, para. 62), and the session is an AF session (Dao discloses that the service operation, npcf policy authorization, allows an AF to provide, update, delete application level information to the PCF; and the SMF communicates with the PCF to obtain and install the new policy, and policy updates according to the information, identification of the application session context, provided by the AF) (Dao, para. 244). Regarding claim 30, Dao discloses the method of claim 28, wherein the request to create the session is transmitted to a network exposure function (NEF) (Dao discloses that the AF could provide or modify the PHP parameters by sending the npcf policy authorization create/update/ request message (create the session) directly to the PCF or via NEF) (Dao, para. 242) and the acknowledgment is received from the NEF if the core network entity is not a trusted core network entity (Dao discloses that NEF 314 is deployed in the network to allow servers, functions and other entities such as those outside a trusted domain (not a trusted core network) to have exposure to services and capabilities within the network) (Dao, para. 57), or the request to create the session is transmitted to a policy control function (PCF) and the acknowledgment is received from the PCF if the core network entity is a trusted core network entity (Dao discloses that the PCF 316 communicates with the UDR 340, where the PCF provides the policy profile information that governs access rights to the stored policy data which includes user subscription data, security credentials (authorized and acknowledged), access and mobility related subscription data and session related data (trusted core network entity)) (Dao, para. 61). 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 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made. Claims 9 and 21 are rejected under 35 U.S.C. 103 as being unpatentable over Dao et al. (2020/0145876, hereinafter Dao) as applied to claims 1 and 13 above, and further in view of Rossbach et al. (2023/0269620, hereinafter Rossbach). Regarding claim 9, Dao discloses the core network entity of claim 1, but does not explicitly disclose wherein one or more ADUs, each comprising a plurality of PDUs, are: generated by an application server at substantially a same time; and grouped in at least one burst. In analogous art, Rossbach teaches wherein one or more ADUs, each comprising a plurality of PDUs, are: generated by an application server at substantially a same time (Rossbach discloses that the RAN utilizes these networks and application functions and servers to provide the UE with the necessary data streams such that the 5G-XR aware application performs in an ideal fashion) (Rossbach, para. 125); and grouped in at least one burst (Rossbach discloses that the XR applications operate using application data units or data bursts represented by larger segments of data where each segment of the application layer data consist of a series of multiple IP packets) (Rossbach, para. 126). Therefore it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention to take the teachings of Rossbach related to having PDUs being generated by an application server and grouped in at least one burst and to combine with Dao in order to increase the efficiency of the operations by reducing unnecessary transmissions/receptions (Rossbach, para. 135). Regarding claim 21, Dao discloses the method of claim 13, but does not explicitly disclose wherein one or more ADUs, each comprising a plurality of PDUs, are: generated by an application server at substantially a same time; and grouped in at least one burst. In analogous art, Rossbach teaches wherein one or more ADUs, each comprising a plurality of PDUs, are: generated by an application server at substantially a same time (Rossbach discloses that the RAN utilizes these networks and application functions and servers to provide the UE with the necessary data streams such that the 5G-XR aware application performs in an ideal fashion) (Rossbach, para. 125); and grouped in at least one burst (Rossbach discloses that the XR applications operate using application data units or data bursts represented by larger segments of data where each segment of the application layer data consist of a series of multiple IP packets) (Rossbach, para. 126). Therefore it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention to take the teachings of Rossbach related to having PDUs being generated by an application server and grouped in at least one burst and to combine with Dao in order to increase the efficiency of the operations by reducing unnecessary transmissions/receptions (Rossbach, para. 135). Conclusion Any inquiry concerning this communication or earlier communications from the examiner should be directed to ANDREW WOO whose telephone number is (571)270-7521. The examiner can normally be reached Telework 9:00AM-6:00PM | IFP M-F 9:00AM-6: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, Umar Cheema can be reached at 571-270-3037. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300. Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. /ANDREW WOO/Examiner, Art Unit 2441
Read full office action

Prosecution Timeline

May 15, 2024
Application Filed
Jan 09, 2026
Non-Final Rejection — §102, §103 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12603923
CAPABILITY SIGNALING
2y 5m to grant Granted Apr 14, 2026
Patent 12592863
DIGITAL NETWORK SIMULATION AND GRAPH DATABASE FORMULATION FOR USE WITH A LARGE LANGUAGE MODEL
2y 5m to grant Granted Mar 31, 2026
Patent 12585484
A GENERAL NETWORK POLICY FOR NAMESPACES
2y 5m to grant Granted Mar 24, 2026
Patent 12587470
EXTEND HIGH CPS FLOW TABLE MANAGEMENT FROM DPU TO HOST CPU
2y 5m to grant Granted Mar 24, 2026
Patent 12580981
NETWORK LOAD BALANCING
2y 5m to grant Granted Mar 17, 2026
Study what changed to get past this examiner. Based on 5 most recent grants.

AI Strategy Recommendation

Get an AI-powered prosecution strategy using examiner precedents, rejection analysis, and claim mapping.
Powered by AI — typically takes 5-10 seconds

Prosecution Projections

1-2
Expected OA Rounds
83%
Grant Probability
99%
With Interview (+45.0%)
2y 10m
Median Time to Grant
Low
PTA Risk
Based on 570 resolved cases by this examiner. Grant probability derived from career allow rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month