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 .
This office action is in response to remarks filed 10/16/2025.
Claims 1-20 are pending and presented for examination. Claims 1 and 11 have been amended.
Claim Rejections - 35 USC § 112
Claims 1 and 11 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
The new matter which is not supported by the original disclosure is as follows: “determining a change in the UE status, via data plane notifications from an Access and Mobility Management Function (AMF) network function”. A review of the specification discloses, per applicant’s remarks to ¶0076 and ¶0079, finds that a ‘data plane notification from an Access and Mobility Management Function (AMF) network function’ is not disclosed and only describes general AMF operation. A review of the drawings, per applicant’s remarks to Fig. 1, does not disclose a data plane notification from an AMF. In addition, Fig. 2 discloses a control plane connected to a data plane by an ‘Sx’ connection as part of an LTE core network. Neither drawings disclose ‘data plane notification from an Access and Mobility Management Function (AMF) network function’.
Applicant is required to cancel the new matter in the reply to this Office Action.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-3, 5-9, 11-13, 16-19 are rejected under 35 U.S.C. 103 as being unpatentable over Gupta et al. (US 20150282086 A1, hereinafter “Gupta”), in view of Lubenski et al. (US 20180316617 A1, hereinafter, “Lubenski”), in view of Qiao et al. (US 20230179640 A1, hereinafter “Qiao”).
RE claim 1, Gupta discloses: A method for radio traffic management (Fig. 2-6) in a computer network comprising:
determining user equipment (UE) status (Fig. 3 and 5, element 315 decision block for UE state; ¶34: radio circuitry is determined by the traffic shaping module to change to high power state. (¶33: traffic shaping module may query the state of the radio circuitry) associated with a traffic flow session (¶25: IP stack may specify, such as a request from an application, how data is to be formatted, transmit, routed, and received over a network.);
determining traffic flow parameters associated with the traffic flow associated with the UE, (¶25: IP stack may specify, such as a request from an application, how data is to be formatted, transmit, routed, and received over a network.);
and determining a traffic action for at least one packet associated with the traffic flow (¶25: IP stack may specify, such as a request from an application, how data is to be formatted, transmit, routed, and received over a network.) based on the UE status (Fig. 3,4; ¶33: traffic shaping queries the states of the mobile device),.
Gupta does not explicitly disclose:
wherein the traffic flow parameters comprise packet type, application type, traffic session metrics, and traffic flow information;
wherein the traffic action is associated with the flow of the packet and the traffic flow parameters.
However Lubenski discloses:
wherein the traffic flow parameters comprise packet type, application type, traffic session metrics, and traffic flow information (Determine of traffic flow parameters is by shallow packet inspection to obtain source IP, destination IP, port, protocol for each packet, or other information required. Deep packet inspection may be used where shallow packet inspection is otherwise identified, ¶0047. Packet inspection information may type of traffic, quality of service, the source, the destination, the packet size, protocol number, application name, or any other envelope information may be used, ¶0059);
wherein the traffic action is associated with the flow of the packet and the traffic flow parameters (Network receives data, traffic flow, and performs packet inspection, traffic flow parameters, if message is relevant to a UE. ¶0077, Fig. 4:401; Determination of UE state, Idle or not Idle, is required to further determine the packet flow, ¶0077, Fig. 4:402; Based on inspection and UE state, traffic flow parameters, the network determines traffic action to normally send, fewer resources, or discard. ¶0077, Fig. 4: 404, 405, 406, 407)).
Gupta and Lubenski do not explicitly disclose:
determining a change in the UE status, via data plane notifications from an Access and Mobility Management Function (AMF) network function and timestamps associated with the UE traffic flow;
However, Qiao discloses:
determining a change in the UE status (Connection management, CM, may comprise establishing and releasing a signaling connection between a UE 100 and an AMF 155. The signaling connection may be employed to enable NAS signaling exchange between the UE 100 and the core network. Two connection management states of the UE with the AMF, CM-IDLE and CM-CONNECTED. ¶¶0222-0024, Fig. 6a, 6b), via data plane notifications from an Access and Mobility Management Function (AMF) network function (AMF includes connection management functionality include session management, SM, messages between UE and the SMF. ¶0198, Fig. 2:155; Connection management, CM, may comprise establishing and releasing a signaling connection between a UE 100 and an AMF 155 over N1 interface. The signaling connection may be employed to enable NAS signaling exchange between the UE 100 and the core network. ¶0222, Fig. 6a, 6b; Service request procedure to the AMF which sends Nsmf_PDUSession_UpdateSMContext to the SMF, a data plane notification. Service request procedure may be used when UE is in CM-IDLE and/or CM-CONNECTED and may allow selectively to activate user plane connections, data plane, for some of the established PDU sessions. ¶¶0286, 0295, 0297, 0312, Fig. 10, 11;) and timestamps associated with the UE traffic flow (AMF selects an SMF and sends a message, PDUSession_CreateSMContext Request, comprising at least flow synchronization request indication, flow information, and timestamp information. The message sent to the SMF may be used by the AMF to request establishing the PDU session. ¶0417, Fig. 20. SMF determines timestamp configuration based on the timestamp information comprising a timestamp type, timestamp size, and time difference between Service Data Flows/packet flows/QoS flow(s) for synchronization. ¶0420);
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to combine the method of Gupta with the teachings of Lubenski with the teachings of Qiao. Gupta discloses a method of traffic management by determining UE status, flow parameters, and a dependent traffic actions. Lubenski further teaches a set of selected traffic flow parameters to inspect and take action on a packet. Qiao further teaches a method of synchronized forwarding of data flows with state information of the UE.
This combination of Gupta in view of Lubenski in view of Qiao applies the use of known techniques to achieve the same desired results to identify and synchronize packet flows based on UE state and network conditions. This minimizes additional network traffic to and from the UE to minimize power consumption. (Gupta: Abstract, ¶4, 34; Lubenski: ¶12-13, 57-58; Qiao: Abstract, ¶¶0036-0037, 0217, 0295, 0297, 0312, 0380)
RE claim 2. Gupta discloses: A method wherein the change in the UE status (Fig. 3 and 5, element 315 decision block for UE state; ¶34: radio circuitry is determined by the traffic shaping module to change to high power state. ¶33: traffic shaping module may query the state of the radio circuitry) is from active to idle (Fig. 3, 5; ¶27,28: determine that the device is in a high/low power state.) and the traffic action is to queue packets until there is a further UE change in status (Abstract; Fig 3, 5; ¶26, 33: traffic shaping module may retain one or more packets in one or more buffers to reduce power consumption, ‘idle’.).
RE claim 3, Gupta discloses: A method wherein the change in the UE status (Fig. 3 and 5, element 315 decision block for UE state; ¶34: radio circuitry is determined by the traffic shaping module to change to high power state. ¶33: traffic shaping module may query the state of the radio circuitry) is from active to idle (Fig. 3, 5; ¶27,28: determine that the device is in a high/low power state.)
Gupta does not explicitly teach: and the traffic action is to close the traffic flow session with a server.
However, Lubenski teaches: and the traffic action is to close the traffic flow session with a server (¶73: UE may go idle and the Upstream Gateway may send final ACK to remote server in order to close the connection.).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to combine the method of Gupta with the teachings of Lubenski. Gupta discloses a method to detect a change in the UE status. Lubenski further teaches the closing of a connection when the UE goes idle.
This combination of Gupta in view of Lubenski applies the use of known techniques to achieve the same desired results to close an open connection when the UE goes idle. This minimizes additional network traffic to and from the UE to minimize power consumption. (Gupta: Abstract, ¶4, 34; Lubenski: ¶12-13, 57-58)
RE claim 5. Gupta discloses: A method, wherein the change in the UE status (Fig. 3 and 5, element 315 decision block for UE state; ¶34: radio circuitry is determined by the traffic shaping module to change to high power state. ¶33: traffic shaping module may query the state of the radio circuitry) is from idle to active and the traffic action is to respond to at least one packet initiated by the UE (Fig. 3, 4; ¶39, 41, 42: generating at least one packet for transmission over a network based on at least one request, ¶50 device is no longer in a low-power state and to release one or more retained packets.).
RE claim 6. Gupta discloses: A method, wherein the queued packets are transmitted to the UE on a change from idle to active (Fig. 3, 4; ¶39, 40, 41: when device is not low power mode and transmit packets).
RE claim 7. Gupta discloses: A method, wherein the queued packets are transmitted to the UE after a predetermined time threshold is met (Fig. 3, 4 Case 4: ¶43, 44, 49: releasing retained packets for transmission with a countdown timer).
RE claim 8. Gupta discloses: A method wherein the queued packets are transmitted to the UE after a predetermined number of packets have been queued (Fig. 3, 4 Case 3: ¶43, 44, 49: releasing retained packets for transmission based on threshold amount of packets).
RE claim 9, Gupta discloses: A method, further comprising:
receiving a UE packet from the UE (Fig. 3, 5; ¶39: generating at least one packet; ¶56 determine if connection is reset; ¶74);
determining if the UE packet is associated with a previously closed connection (Fig. 3, 5; ¶39: generating at least one packet; ¶56 determine if connection is reset over which data packets are to be sent; ¶74);
Gupta does not explicitly teach: and transmitting a further packet to the UE to close the connection for the UE.
However, Lubenski teaches: and transmitting a further packet to the UE to close the connection for the UE (¶13: sending from the TCP gateway to the TCP client a simulated FIN message in order to close the connection.).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to combine the method of Gupta with the teachings of Lubenski. Gupta discloses a method to determine if the current packet is associated with a previously closed connection. Lubenski further teaches closing a connection by use of a TCP gateway to terminate the unused connection.
This combination of Gupta in view of Lubenski applies the use of known techniques to achieve the same desired results to close a connection earlier rather than wait for the normal timeout and closure. This minimizes additional network traffic to and from the UE to minimize power consumption. (Gupta: Abstract, ¶39, 56; Lubenski: ¶12, 13, 48-49, 73)
RE claim 11, Gupta discloses: A system for radio traffic management (Fig. 2, 3, 4, 5, 6) in a computer network (Computing device with interconnected communication pathways such as processor, memory, and instructions, ¶0063, Fig. 7) comprising at least one processor (¶0063, Fig. 7: 704) configured to execute instructions stored in a memory component (Programming instructions in memory. ¶0065, Fig. 7: 708, 710, 712) wherein the instructions provide for:
a User Equipment (UE) state module configured to determine UE status (Fig. 3, 5; ¶27,28: determine that the device is in a high/low power state.) associated with a traffic flow session (¶25: IP stack may specify, such as a request from an application, how data is to be formatted, transmit, routed, and received over a network.);
a packet inspection module configured to determine traffic flow parameters (¶25: IP stack may specify, such as a request from an application, how data is to be formatted, transmit, routed, etc.) associated with the traffic flow associated with the UE (¶25: IP stack may specify, such as a request from an application, how data is to be formatted, transmit, routed, and received over a network.),
a forwarding module configured to determine a traffic action for at least one packet associated with the traffic flow (¶25: IP stack may specify, such as a request from an application, how data is to be formatted, transmit, routed, and received over a network.) based on the UE status (Fig. 3,4; ¶33: traffic shaping queries the states of the mobile device),.
Gupta does not explicitly disclose:
wherein the traffic flow parameters comprise packet type, application type, traffic session metrics, and traffic flow information;
wherein the traffic action is associated with the flow of the packet and the traffic flow parameters.
However Lubenski discloses:
wherein the traffic flow parameters comprise packet type, application type, traffic session metrics, and traffic flow information (Determine of traffic flow parameters is by shallow packet inspection to obtain source IP, destination IP, port, protocol for each packet, or other information required. Deep packet inspection may be used where shallow packet inspection is otherwise identified, ¶0047. Packet inspection information may type of traffic, quality of service, the source, the destination, the packet size, protocol number, application name, or any other envelope information may be used, ¶0059);
wherein the traffic action is associated with the flow of the packet and the traffic flow parameters (Network receives data, traffic flow, and performs packet inspection, traffic flow parameters, if message is relevant to a UE. ¶0077, Fig. 4:401; Determination of UE state, Idle or not Idle, is required to further determine the packet flow, ¶0077, Fig. 4:402; Based on inspection and UE state, traffic flow parameters, the network determines traffic action to normally send, fewer resources, or discard. ¶0077, Fig. 4: 404, 405, 406, 407)).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to combine the method of Gupta with the teachings of Lubenski. Gupta discloses a method of traffic management by determining UE status, flow parameters, and a dependent traffic actions. Lubenski further teaches a set of selected traffic flow parameters to inspect and take action on a packet. This combination of Gupta in view of Lubenski applies the use of known techniques to achieve the same desired results to identify and route packets based on UE and Network conditions. This minimizes additional network traffic to and from the UE to minimize power consumption. (Gupta: Abstract, ¶4, 34; Lubenski: ¶12-13, 57-58)
Gupta and Lubenski do not explicitly disclose:
wherein, the UE status is determined via data plan notifications from an Access and Mobility Management Function (AMF) network function and timestamps associated with the UE traffic flow;
However, Qiao discloses:
wherein, the UE status is determined via data plane notifications from an Access and Mobility Management Function (AMF) network function and timestamps associated with the UE traffic flow (Connection management, CM, may comprise establishing and releasing a signaling connection between a UE 100 and an AMF 155. The signaling connection may be employed to enable NAS signaling exchange between the UE 100 and the core network. Two connection management states of the UE with the AMF, CM-IDLE and CM-CONNECTED. ¶¶0222-0024, Fig. 6a, 6b; AMF includes connection management functionality include session management, SM, messages between UE and the SMF. ¶0198, Fig. 2:155; Connection management, CM, may comprise establishing and releasing a signaling connection between a UE 100 and an AMF 155 over N1 interface. The signaling connection may be employed to enable NAS signaling exchange between the UE 100 and the core network. ¶0222, Fig. 6a, 6b; Service request procedure to the AMF which sends Nsmf_PDUSession_UpdateSMContext to the SMF, a data plane notification. Service request procedure may be used when UE is in CM-IDLE and/or CM-CONNECTED and may allow selectively to activate user plane connections, data plane, for some of the established PDU sessions. ¶¶0286, 0295, 0297, 0312, Fig. 10, 11; AMF selects an SMF and sends a message, PDUSession_CreateSMContext Request, comprising at least flow synchronization request indication, flow information, and timestamp information. The message sent to the SMF may be used by the AMF to request establishing the PDU session. ¶0417, Fig. 20. SMF determines timestamp configuration based on the timestamp information comprising a timestamp type, timestamp size, and time difference between Service Data Flows/packet flows/QoS flow(s) for synchronization. ¶0420);
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to combine the method of Gupta with the teachings of Lubenski with the teachings of Qiao. Gupta discloses a method of traffic management by determining UE status, flow parameters, and a dependent traffic actions. Lubenski further teaches a set of selected traffic flow parameters to inspect and take action on a packet. Qiao further teaches a method of synchronized forwarding of data flows with state information of the UE.
This combination of Gupta in view of Lubenski in view of Qiao applies the use of known techniques to achieve the same desired results to identify and synchronize packet flows based on UE state and network conditions. This minimizes additional network traffic to and from the UE to minimize power consumption. (Gupta: Abstract, ¶4, 34; Lubenski: ¶12-13, 57-58; Qiao: Abstract, ¶¶0036-0037, 0217, 0295, 0297, 0312, 0380)
RE claim 12. Gupta discloses: A system wherein if the UE state module determines there has been a change in the UE status (Fig. 3 and 5, element 315 decision block for UE state; ¶34: radio circuitry is determined by the traffic shaping module to change to high power state. ¶33: traffic shaping module may query the state of the radio circuitry) from active to idle (Fig. 3, 5; ¶27,28: determine that the device is in a high/low power state.), the forwarding module is configured to queue packets until there is a further UE change in status (Abstract; Fig 3, 5; ¶26, 33: traffic shaping module may retain one or more packets in one or more buffers to reduce power consumption, ‘idle’.).
RE claim 13, Gupta discloses: A system wherein if the UE state module determines there has been a change in the UE status (Fig. 3 and 5, element 315 decision block for UE state; ¶34: radio circuitry is determined by the traffic shaping module to change to high power state. ¶33: traffic shaping module may query the state of the radio circuitry) from active to idle (Fig. 3, 5; ¶27,28: determine that the device is in a high/low power state.),
Gupta does not explicitly teach: the forwarding module is configured to close the traffic flow session with a server.
However, Lubenski teaches: the forwarding module is configured to close the traffic flow session with a server (¶13: sending from the TCP gateway to the TCP Server a TCP reset message to force terminate connection to the server).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to combine the method of Gupta with the teachings of Lubenski. Gupta discloses a method to determine a change in the UE status of active or idle. Lubenski teaches closing the TCP connection on a per-UE using FIN or RST messages.
This combination of Gupta in view of Lubenski applies the use of known techniques to achieve the same desired results to close a connection earlier rather than wait for the normal timeout and closure. This minimizes additional network traffic to and from the UE to minimize power consumption. (Gupta: Abstract, ¶33-34; Lubenski: ¶12, 13, 48-49, 73)
RE claim 15. Gupta discloses: A system , wherein if the UE state module determines there has been a change in the UE status (Fig. 3 and 5, element 315 decision block for UE state; ¶34: radio circuitry is determined by the traffic shaping module to change to high power state. ¶33: traffic shaping module may query the state of the radio circuitry) from idle to active, the forwarding module is configured to respond to at least one packet initiated by the UE (Fig. 3, 4; ¶39, 41, 42: generating at least one packet for transmission over a network based on at least one request, ¶50 device is no longer in a low-power state and to release one or more retained packets.).
RE claim 16. Gupta discloses: A system , wherein the forwarding module is configured to transmit the queued packets to the UE when the UE statue module determines there has been a change of status from idle to active (Fig. 3, 4; ¶39, 40, 41: when device is not low power mode and transmit packets).
RE claim 17. Gupta discloses: A system , wherein the forwarding module is configured to transmit queued packets to the UE, when the UE remains in idle status, after a predetermined time threshold is met (Fig. 3, 4 Case 4: ¶43, 44, 49: releasing retained packets for transmission with a countdown timer).
RE claim 18, Gupta discloses: A system wherein the forwarding module is configured to transmit queued packets to the UE, when the UE remains in idle status, after a predetermined number of packets have been queued (Fig. 3, 4 Case 3: ¶43, 44, 49: releasing retained packets for transmission base d on threshold amount of packets).
RE claim 19, Gupta discloses: A system , wherein:
the packet inspection module is configured to determine if a packet has been received from the UE (Fig. 3, 5; ¶39: generating at least one packet; ¶56 determine if connection is reset; ¶74);
the analysis module is configured to determine the UE packet is associated with a previously closed connection (Fig. 3, 5; ¶39: generating at least one packet; ¶56 determine if connection is reset over which data packets are to be sent; ¶74);
Gupta does not explicitly teach: and the forwarding module is configured to transmit a further packet to the UE to close the connection for the UE.
However, Lubenski teaches: and the forwarding module is configured to transmit a further packet to the UE to close the connection for the UE (¶13: sending from the TCP gateway to the TCP client a simulated FIN message in order to close the connection.).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to combine the method of Gupta with the teachings of Lubenski. Gupta discloses detecting a change in UE Idle or Active state, detecting a packet from UE, and determining if connection is reset. Lubenski teaches a method to close the TCP connection utilizing an intermediary gateway to send connection closure packets to either mobile or server depending on mobile power state.
This combination of Gupta in view of Lubenski applies the use of known techniques to achieve the same desired result of managing a TCP connection so as to minimize network traffic thus reducing power consumption (Gupta: Abstract, ¶25-27; Lubenski: ¶12, 13, 48-49, 73).
Claims 4 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Gupta, in view of Lubenski, in view of Qiao as applied to claims 1 and 11 above, and further in view of Arunachalam et al. (US 20170099636 A1, hereinafter, “Arunachalam”).
RE claim 4, Gupta discloses: A method, wherein the change in the UE status (Fig. 3 and 5, element 315 decision block for UE state; ¶34: radio circuitry is determined by the traffic shaping module to change to high power state. ¶33: traffic shaping module may query the state of the radio circuitry) is from active to idle (Fig. 3, 5; ¶27,28: determine that the device is in a high/low power state.)
Gupta and Lubenski do not explicitly teach: and the traffic action is to respond to a TCP window probe on behalf of the UE.
However, Arunachalam teaches: and the traffic action is to respond to a TCP window probe on behalf of the UE (Fig. 13, 14; ¶22: detecting window probes including terminating the TCP connection; ¶79: proactive actions to deal with TCP zero window probes; ¶81: mobile or server initiated closures which TCP controller controls TCP FIN and zero window probe packets; ¶83 TCP pattern recognizer identifies state of mobile or server closure).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to combine the method of Gupta and Arunachalam with the teachings of Arunachalam. Gupta discloses a method to determine a change in the UE status of idle or active. Arunachalam teaches the detection of TCP zero window probes and the TCP controller, acting as the intermediary, responds depending on the state of the UE or the server.
This combination of Gupta in view of Arunachalam applies the use of known techniques to achieve the same desired result of detecting UE status and TCP zero window probes by an intermediary to respond to the server after the UE status has changed to idle. This minimizes additional network traffic to and from the UE to minimize power consumption. (Gupta: Abstract, ¶33-34; Arunachalam: Abstract, ¶79, 81)
RE claim 14, Gupta discloses: A system , wherein if the UE state module determines there has been a change in the UE status (Fig. 3 and 5, element 315 decision block for UE state; ¶34: radio circuitry is determined by the traffic shaping module to change to high power state. ¶33: traffic shaping module may query the state of the radio circuitry) from active to idle (Fig. 3, 5; ¶27,28: determine that the device is in a high/low power state.)
Gupta and Lubenski do not explicitly teach: the forwarding module is configured to respond to a TCP window probe on behalf of the UE.
However, Arunachalam teaches: the forwarding module is configured to respond to a TCP window probe on behalf of the UE (Fig. 13, 14; ¶22: detecting window probes including terminating the TCP connection; ¶79: proactive actions to deal with TCP zero window probes; ¶81: mobile or server initiated closures which TCP controller controls TCP FIN and zero window probe packets; ¶83 TCP pattern recognizer identifies state of mobile or server closure).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to combine the method of Gupta and Arunachalam with the teachings of Arunachalam. Gupta discloses detecting a change in UE Idle or Active state, detecting a packet from UE, and determining if connection is reset. Arunachalam teaches a method to detect closed or partially closed TCP connections by monitoring the presence TCP Zero Window Probes to promptly close an open connection.
This combination of Gupta in view of Arunachalam applies the use of known techniques to achieve the same desired result of managing a TCP connection so as to minimize network traffic thus reducing power consumption (Gupta: Abstract, ¶33-34; Arunachalam: Abstract ¶79, 81 ).
Claims 10 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Gupta in view of Lubenski, in view of Qiao as applied to claims 1 and 11 above, and further in view of Backholm et al. (US 20150016261 A1, hereinafter, “Backholm”).
RE claim 10. Gupta discloses: A method, further comprising,
determining if the UE status is idle (Fig. 3, 5; ¶27,28: determine that the device is in a high/low power state.);
Gupta and Lubenski do not explicitly teach: determining if the at least one packet is a time critical packet;
if the at least one packet is not time critical, storing the packet for a predetermined amount of time or until there is a change in UE status;
and if the at least one packet is time critical, sending the packet to the UE.
However, Backholm teaches: determining if the at least one packet is a time critical packet (Fig.2 – 235, 241; ¶118, 119: transaction manager 235 can detect and identify data request and apply a rule according to time criticality of the transaction and the data transmitted in the transaction);
if the at least one packet is not time critical, storing the packet for a predetermined amount of time or until there is a change in UE status (Fig. 1, 125, 175, 185; ¶71, 131: the proxy server with the cache system and TCP optimizer can accumulate low priority data and send it in batches to avoid the protocol overhead of sending individual data fragments. ¶132: batch transfer may occur after an amount of time elapsed, batching module can initiate batch transfers when a higher priority event is detected at the device, the radio is triggered);
and if the at least one packet is time critical, sending the packet to the UE (Fig. 2 – 235, 241; ¶119 -121: transaction and connection manager along with radio controller can trigger the use of high power radio mode for a time critical transaction, ¶129: the transaction manager can use the priorities for requests and direct the radio controller to turn on the radio so requests can be sent when transaction is detected to be over a certain priority level).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to combine the method of Gupta and Lubenski with the teachings of Backholm. Gupta discloses a method to determine the UE status and if it is idle. Backholm teaches method to determine if a packet is critical or noncritical. If the packet is non-critical then store in a cache for latter transactions. If the packet is critical then turn on the radio to active mode and send the transactions. . This combination of Gupta in view of Backholm applies the use of known techniques to achieve the same desired result of managing a TCP connection so as to minimize network traffic thus reducing power consumption. (Gupta: Abstract, ¶26, 33-34; Backholm: Abstract, ¶71, 119-121, 129, 131)
RE claim 20. Gupta discloses: A system , wherein,
the UE state module is configured to determine if the UE status is idle (Fig. 3, 5; ¶27,28: determine that the device is in a high/low power state.);
Gupta and Lubenski do not explicitly teach: the packet inspection module is configured to determine whether the at least one packet is a time critical packet;
if the at least one packet is not time critical, the forwarding module stores the packet for a predetermined amount of time or until there is a change in UE status;
and if the at least one packet is time critical, the forwarding module sends the packet to the UE.
However, Backholm teaches: the packet inspection module is configured to determine whether the at least one packet is a time critical packet (Fig.2 – 235, 241; ¶118, 119: transaction manager 235 can detect and identify data request and apply a rule according to time criticality of the transaction and the data transmitter in the transaction);
if the at least one packet is not time critical, the forwarding module stores the packet for a predetermined amount of time or until there is a change in UE status (Fig. 1, 125, 175, 185; ¶71, 131: the proxy server with the cache system and TCP optimizer can accumulate low priority data and send it in batches to avoid the protocol overhead of sending individual data fragments. ¶132: batch transfer may occur after an amount of time elapsed, batching module can initiate batch transfers when a higher priority event is detected at the device, the radio is triggered);
and if the at least one packet is time critical, the forwarding module sends the packet to the UE (Fig. 2 – 235, 241; ¶119 -121: transaction and connection manager along with radio controller can trigger the use of high power radio mode for a time critical transaction, ¶129: the transaction manager can use the priorities for requests and direct the radio controller to turn on the radio so requests can be sent when transaction is detected to be over a certain priority level) .
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to combine the method of Gupta and Lubenski with the teachings of Backholm. Gupta discloses a method to determine the UE status and if it is idle. Backholm teaches method to determine if a packet is critical or noncritical. If the packet is non-critical then store in a cache for latter transactions. If the packet is critical then turn on the radio to active mode and send the transactions. . This combination of Gupta in view of Backholm applies the use of known techniques to achieve the same desired result of managing a TCP connection so as to minimize network traffic thus reducing power consumption. (Gupta: Abstract, ¶26, 33-34; Backholm: Abstract, ¶71, 119-121, 129, 131)
Response to Arguments
Applicant’s arguments with respect to amended language of claims 1 and 11 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Applicant’s arguments, filed 10/16/2025, have been fully considered but they are not persuasive.
Applicant submits that the system per Fig. 1 is associated with a data plane of a computer network. Applicant submits that “The system does not require additional hardware or software to be included on the mobile device but instead provides for determining a UE status from a network function without the need for additional messaging or knowledge derived directly from the mobile device.” Further, applicant submits that “Further the system and method are able to use various methods to determine a change in the UE status, thus providing for more accurate status information of the UE as detailed in paragraphs 76 and 79 of the application as filed.”.
Examiner respectfully disagrees. Figure 1 does not disclose a data plane of a computer network or a change in a UE status. Fig. 1 discloses an ‘initiator’ and a ‘receiver’ and actions to an established connection. According to the specification “Fig. 1 illustrates a conventional closing of a TCP connection”, ¶0030. Support of the amended limitations of Claims 1 and 11, notifications via a data plane, are not found in the disclosure. Refer to 112(a) rejection.
Applicant’s first argument submits that Gupta does not disclose the amended limitation of Claims 1 and 11. Per the applicant: “As such, Applicant submits that the state of the UE is determined at the device itself rather than by a system on the data plane of a computer network as in the present application. Applicant submits that the system provided in Gupta requires knowledge directly from and/or interaction with the mobile device and does not avail itself of data plane notification from the AMF”. In conclusion, applicant submits that “As such, Applicant submits that claim 1 is novel and not obvious in view of Gupta.”
Examiner respectfully disagrees. In review of the last office action, filed 07/16/2025, the limitation in question, “determining a change in the UE status, via notifications from an Access and Mobility Management Function (AMF) network function” was cited in reference to Yu and not Gupta. See pg. 6 of the last office action. Argument is moot with new grounds of rejection.
In response to applicant's arguments against the references individually, one cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986).
Applicant’s second argument submits that “Applicant submits that Lubenski discloses a method for tearing down a TCP connection between a client in a radio access network and a TCP server. Lubenski does not appear to determine a state of user equipment in a similar manner to the claimed method. Applicant notes that Lubenski discloses that a UE is detected as being in IDLE state by not being able to be contacted without paging (paragraph 77) or through other various means of tracking.” In addition, “Applicant submits that Lubenski does not consider determining the UE status through AMF notifications and through timestamps of the packet associated with the traffic flow.” Further, applicant submits “Applicant submits that the mention of the Mobility Management Entity of Lubenski does not among to disclosure relating to determining a UE status from messaging from the AMF. Applicant submits that these separate network devices may provide similar functionality, but to equate them with the same functionality is using hindsight that would not be available to a person of skill in the art at the time of filing.”
Examiner respectfully disagrees. In review of the last office action, filed 07/16/2025, the limitation in question was cited to Lebenski, included for reference. “Examiner respectfully disagrees. Examiner notes that the cursory review of Lubenski discloses the subject matter. User equipment state is tracked and determined by per-flow tracking, per-UE tracking for HARQ and other parameters, per-media server tracking, or other types of state tracking may be used, ¶0043 Lubenski. Determination of UE state, Idle or not Idle, is required to further determine the packet flow, ¶0077 Lubenski. The upstream node, the claimed invention, sits between the serving eNodeB and the mobility management entity, MME. ¶0087; A coordination gateway may also include an MME, ¶0101, Fig. 8; A person with ordinary skill in the art at the time of invention would understand the AMF and MME at least provide the same functionality of tracking of the UE state for managing both active and idle modes.”
Applicant’s argument to Lebenski ¶0077 and that UE is detected to be in an IDLE state by not being able to be contacted without paging. Lebenski does not state ‘UE is detected’ but clearly states ‘UE is in an IDLE state’. A UE connection state is a fundamental parameter tracked by a Mobility Function of a network, 4G or 5G. A UE connection state is tracked by either an MME or AMF to the limitation in question. Lebenski discloses several methods that apply to 4G, 5G, and other radio access technologies. ¶¶0035-0036, 0051, 0059.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to PAUL A. LANGER whose telephone number is (703)756-1780. The examiner can normally be reached Monday - Friday, 8:00 am - 5:00 pm, Eastern.
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, Nishant B. Divecha can be reached at 1 (571) 270-3125. 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.
/PAUL A. LANGER/Examiner, Art Unit 2419
/Nishant Divecha/Supervisory Patent Examiner, Art Unit 2419