Prosecution Insights
Last updated: April 19, 2026
Application No. 17/931,514

PACKET FLOW IDENTIFICATION WITH REDUCED DECODE OPERATIONS

Final Rejection §103
Filed
Sep 12, 2022
Examiner
BENGZON, GREG C
Art Unit
2444
Tech Center
2400 — Computer Networks
Assignee
AT&T Intellectual Property I, L.P.
OA Round
6 (Final)
58%
Grant Probability
Moderate
7-8
OA Rounds
3y 11m
To Grant
64%
With Interview

Examiner Intelligence

Grants 58% of resolved cases
58%
Career Allow Rate
283 granted / 486 resolved
At TC average
Moderate +6% lift
Without
With
+5.9%
Interview Lift
resolved cases with interview
Typical timeline
3y 11m
Avg Prosecution
38 currently pending
Career history
524
Total Applications
across all art units

Statute-Specific Performance

§101
12.2%
-27.8% vs TC avg
§103
65.8%
+25.8% vs TC avg
§102
4.9%
-35.1% vs TC avg
§112
9.0%
-31.0% vs TC avg
Black line = Tech Center average estimate • Based on career data from 486 resolved cases

Office Action

§103
DETAILED ACTION This application has been examined. Claims 1-13,16-18,20-23 are pending. Claims 14-15,19 are cancelled. Claims 22-23 are submitted as new claims. 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 . Making Final Applicant's arguments filed 11/28/2025 have been fully considered but they are moot in view of the new grounds for rejection. The claim amendments regarding -- ‘wherein the first packet, the second packet, and the third packet are obtained from a network tap that copies traffic on a link between components of the telecommunications network and provides traffic that is copied including the first packet, the second packet, and the third packet to the processing system’ -- clearly change the literal scope of the independent and dependent claims and/or the range of equivalents for such claims. The said amendments alter the scope of the claims but do not overcome the disclosure by the prior art as shown below. The Examiner is presenting new grounds for rejection as necessitated by the claim amendments and is thus making this action FINAL. Response to Arguments Applicant's arguments filed 11/28/2025 have been fully considered but they are moot in view of the new grounds for rejection. The Applicant presents the following argument(s) [in italics]: …Jadhav discloses that a segment enforcer may be deployed at a TAP. Moreover, although segment enforcer performs operations including generating flow identifiers for packet flows (Jadhav, paragraph 0004), Jadhav does not disclose that the segment enforcer receives the packet flows from the TAP… The Examiner respectfully disagrees with the Applicant. Zhang-Tian-Jadhav disclosed (re. Claim 1) wherein the first packet, the second packet, and the third packet are obtained from a network tap that copies traffic on a link between components of the telecommunications network and provides traffic that is copied including the first packet, the second packet, and the third packet to the processing system.(Jadhav-Paragraph 31, inspect the traffic flows within the segment of the internal network and share/disseminate traffic flow information (e.g., flow ID, etc.) and trust/risk scores with the CIC (108) and other segment enforcers, Paragraph 26, receive/obtain and consolidate telemetry (e.g., flow ID, trust and risk scores, etc.) from one or more segment enforcer(s)) In regard to Claim 22 Zhang-Tian-Jadhav disclosed (re. Claim 22) wherein the first packet, the second packet and the third packet are encapsulated in accordance with a protocol of a networking layer of the telecommunications service provider network.(Tian-Paragraph 65, The SDN controller 420 may decapsulate the VXLAN encapsulation) In regard to Claim 23 Zhang-Tian-Jadhav disclosed (re. Claim 23) wherein the first packet, the second packet, and the third packet each include at least one header of the following: an internet protocol header, a header for a transport layer protocol data unit, a virtual local area network identifier header, or a tunneling protocol header. (Tian- VXLAN tunnel which is indicated by the VNI 100 ) Priority This application claims benefits of priority from US Application 16/356166 filed March 18, 2019. The effective date of the claims described in this application is March 18, 2019. 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-6,8-9,13,16-18,20-23 is/are rejected under 35 U.S.C. 103 as being unpatentable over Zhang (USPGPUB 2015/0016279) further in view of Tian (USPGPUB 2018/0048593) further in view of Jadhav (USPGPUB 2018/0063178) In regard to Claim 1 Zhang Paragraph 44-Paragraph 45 disclosed the MFE sends the packet to a service node, which is a specific type of MFE that handles broadcast, unknown, and multicast (BUM) packets, possibly among other features. The service node, in addition to forwarding the packet to its destination, returns information to the MFE, allowing the MFE to create a new flow entry or set of flow entries such that future packets sent to the particular destination can be forwarded directly to their destination. The creation of new flow entries through such learning actions may cause future packets to be processed by flow entries the use of which would not be detected on a first pass of the flow reachability analysis. Accordingly, some embodiments perform a first iteration of the flow reachability analysis to determine the flow entries that would be created by the learning actions, then perform a second iteration of the analysis with these new flow entries, to determine all of the flow entries that could be used in the network. Zhang Paragraph 47 disclosed using headerspace analysis to identify a set of flow entries that eventually cause a packet to be processed by a particular flow entry. That is, the analysis of the paths can determine all of the different flow entries that are matched by packets which eventually match a particular flow entry as well as identifying all of the different flow entries matched by packets after matching the particular flow entry. Zhang disclosed (re. Claim 1) a method comprising: ‘ obtaining, by a processing system including at least one processor, a first packet including a first header (Zhang-Paragraph 66, packet header data structure 700 includes fields for the VLAN ID, source MAC address, destination MAC address, eight registers, and a tunnel ID (sometimes referred to as register 0). ) determining, by the processing system, a first tunnel identifier from the tunnel identifier field, (Zhang-Paragraph 66, packet header data structure 700 includes fields for the VLAN ID, source MAC address, destination MAC address, eight registers, and a tunnel ID (sometimes referred to as register 0) ) a first source port identifier from the source port identifier field, and a first value from the at least one additional field; (Zhang-Paragraph 67, layer 3 and layer 4 packet header fields (e.g., source and destination IP addresses, source and destination transport layer port numbers, transport protocol type ) assigning, by the processing system, the first packet to a first flow based on the first tunnel identifier, the first source port identifier, and the first value; (Zhang-Paragraph 41, When a packet meets the match conditions for a particular flow entry, the MFE 300 applies the set of actions specified by the flow entry to the packet , Paragraph 85, Paragraph 100, When the packet processing is complete (i.e., the packet has matched a flow entry specifying to drop the packet or deliver the packet to its destination) ) obtaining, by the processing system, a second packet including a second header from the network tap; (Zhang-Paragraph 123,create a new flow entry or set of flow entries such that future packets sent to the particular destination can be forwarded directly to their destination ) While Zhang substantially disclosed the claimed invention Zhang does not disclose (re. Claim 1) a network tap deployed on at least one link of a telecommunication network. While Zhang substantially disclosed the claimed invention Zhang does not disclose (re. Claim 1) decapsulating, by the processing system, a plurality of fields of the first header, the plurality of fields including a tunnel identifier field, a source port identifier field, and at least one additional field; determining, by the processing system, an offset of the tunnel identifier field and an offset of the source port identifier field; extracting, by the processing system, a second value from a tunnel identifier field of the second header using the offset of the tunnel identifier field and a third value from a source port identifier field of the second header using the offset of the source port identifier field, without decapsulating the second packet; determining, by the processing system, that the second value matches the first tunnel identifier and that the third value matches the first source port identifier; assigning, by the processing system, the second packet to the first flow in response to the determining that the second value matches the first tunnel identifier and that the third value matches the first source port identifier, wherein the assigning is performed without determining whether any values associated with any additional fields of the second header in addition to the tunnel identifier field and the source port identifier field match any identifiers of the plurality of fields in addition to the tunnel identifier field and the source port identifier field of the first packet.’ While Zhang substantially disclosed the claimed invention Zhang does not disclose (re. Claim 1) wherein the first packet, the second packet, and the third packet are obtained from a network tap that copies traffic on a link between components of the telecommunications network and provides traffic that is copied including the first packet, the second packet, and the third packet to the processing system. Tian Paragraph 15, Paragraph 20 disclosed a flexible approach to matching which uses a match offset field. A flow entry is generated for the flow and an offset match field is generated in match fields of the flow entry based on an offset matching operation that needs to be performed. The offset match field may include a match position, a match length, a match mask and a match value. Tian Figure 3, Paragraph 49 disclosed wherein it is determined that match fields of the flow entry include an offset match field, then a field is extracted from a received packet according to a match position of the offset match field and the number of bytes indicated by a match length of the offset match field. Tian disclosed (re. Claim 1) decapsulating, by the processing system, a plurality of fields of the first header, (Tian-Paragraph 65, The SDN controller 420 may decapsulate the VXLAN encapsulation, Paragraph 81, process for the SDN switch 412 to decapsulate the VXLAN-encapsulated Ethernet data packet may include: the SDN switch 412, based on the offset pop action [offset type: L1, offset length: 0 byte, pop length: 50 bytes], pops 50 bytes starting from the first byte of the outermost packet header of the VXLAN-encapsulated Ethernet data packet.) the plurality of fields including a tunnel identifier field, (Tian- VXLAN tunnel which is indicated by the VNI 100 ) a source port identifier field, (Tian-Paragraph 71, match fields may include: an ingress port field ) and at least one additional field; (Tian-Paragraph 30,Paragraph 93, The SDN controller 420 may determine use an ingress port 412-3 field, an User Networks interface (UNI ) field 100 and an inner destination MAC address field to search flow table searching for VXLAN packets sent from the switch 413 to the switch 411, also Zhang-Paragraph 67, layer 3 and layer 4 packet header fields (e.g., source and destination IP addresses, source and destination transport layer port numbers, transport protocol type ) determining, by the processing system, an offset (Tian- Figure 3, Paragraph 49, it is determined that match fields of the flow entry include an offset match field, then a field is extracted from a received packet according to a match position of the offset match field and the number of bytes indicated by a match length of the offset match field ) of the tunnel identifier field header (Tian-Paragraph 75, learns a MAC address entry based on the inner source MAC address 00-00-00-00-00-02 and the VXLAN tunnel which is indicated by the VNI 100 ) and an offset of the source port identifier field; (Tian-Paragraph 71, match fields may include: an ingress port field ) extracting, by the processing system, a second value from a tunnel identifier field of the second header (Tian-Paragraph 75, learns a MAC address entry based on the inner source MAC address 00-00-00-00-00-02 and the VXLAN tunnel which is indicated by the VNI 100 ) using the offset of the tunnel identifier field and a third value from a source port identifier field of the second header (Tian-Paragraph 71, match fields may include: an ingress port field ) using the offset of the source port identifier field, without decapsulating the second packet; (Tian- Figure 3, Paragraph 49, it is determined that match fields of the flow entry include an offset match field, then a field is extracted from a received packet according to a match position of the offset match field and the number of bytes indicated by a match length of the offset match field ) Tian disclosed wherein the packet analyzer ‘may skip to the bit positions, byte positions, etc. where the tunnel ID and source port ID fields’ and thus does not necessarily have to decapsulate subsequent packets because Tian extracts the field from a received packet according to a match position of the offset match field and the number of bytes indicated by a match length of the offset match field. The Examiner notes wherein the Tian extraction process does not require a decapsulation process because Tian does not require matching packet fields with a predetermined protocol data structure and can extract the field values without having to process the packet knowing and/or using the protocol with which it has been encoded. Zhang and Tian are analogous art because they present concepts and practices regarding packet flow management. Before the time of the effective filing date of the claimed invention it would have been obvious to combine Tian into Zhang. The motivation for the said combination would have been to enable an SDN switch to correctly match an flow entry for an unsupported protocol packet, such as a VXLAN packet, an EVI packet, or the like, wherein the said packets are to be sent via a tunnel and encapsulated and/or decapsulated. (Tian-Paragraph 15) Zhang-Tian disclosed (re. Claim 1) determining, by the processing system, that the second value (Tian- VXLAN tunnel which is indicated by the VNI 100 ) matches the first tunnel identifier (Zhang- Paragraph 66, packet header data structure 700 includes a tunnel ID (sometimes referred to as register 0) ) and that the third value (Tian-Paragraph 71, match fields may include: an ingress port field ) matches the first source port identifier; (Zhang-Paragraph 67, layer 3 and layer 4 packet header fields (e.g., source and destination IP addresses, source and destination transport layer port numbers, transport protocol type ) The Examiner notes wherein Zhang Paragraph 41 disclosed determining when a packet meets the match conditions for a particular flow entry. While Zhang-Tian substantially disclosed the claimed invention Zhang-Tian does not disclose (re. Claim 1) a network tap deployed on at least one link of a telecommunication network. While Zhang-Tian substantially disclosed the claimed invention Zhang-Tian does not disclose (re. Claim 1) assigning, by the processing system, the second packet to the first flow in response to the determining that the second value matches the first tunnel identifier and that the third value matches the first source port identifier, wherein the assigning is performed without determining whether any values associated with any additional fields of the second header in addition to the tunnel identifier field and the source port identifier field match any identifiers of the plurality of fields in addition to the tunnel identifier field and the source port identifier field of the first packet.’ While Zhang-Tian substantially disclosed the claimed invention Zhang-Tian does not disclose (re. Claim 1) wherein the first packet, the second packet, and the third packet are obtained from a network tap that copies traffic on a link between components of the telecommunications network and provides traffic that is copied including the first packet, the second packet, and the third packet to the processing system. Jadhav Paragraph 30 disclosed wherein a segment enforcer (112X, 112Y, 112Z) may be deployed (adjacent to or on) include, but are not limited to, a network device with a switch port analyzer (SPAN) port, a network device with a test access point (TAP) port. Jadhav Paragraph 43 disclosed wherein any subsequent network packet determined to match a previously identified traffic flow is assigned the flow ID of that traffic flow. Jadhav disclosed (re. Claim 1) a network tap deployed on at least one link of a telecommunication network. (Jadhav-Paragraph 30,a segment enforcer (112X, 112Y, 112Z) may be deployed on a network device with a switch port analyzer (SPAN) port, a network device with a test access point (TAP) port) ) Jadhav disclosed (re. Claim 1) assigning, by the processing system, (Jadhav-Paragraph 43 ,any subsequent network packet determined to match a previously identified traffic flow is assigned the flow ID of that traffic flow ) the second packet to the first flow in response to the determining that the second value matches the first tunnel identifier and that the third value matches the first source port identifier, Jadhav disclosed (re. Claim 1) wherein the first packet, the second packet, and the third packet are obtained from a network tap that copies traffic on a link between components of the telecommunications network and provides traffic that is copied including the first packet, the second packet, and the third packet to the processing system.(Jadhav-Paragraph 31, inspect the traffic flows within the segment of the internal network and share/disseminate traffic flow information (e.g., flow ID, etc.) and trust/risk scores with the CIC (108) and other segment enforcers, Paragraph 26, receive/obtain and consolidate telemetry (e.g., flow ID, trust and risk scores, etc.) from one or more segment enforcer(s)) Zhang,Tian and Jadhav are analogous art because they present concepts and practices regarding packet flow management. Before the time of the effective filing date of the claimed invention it would have been obvious to combine Jadhav into Zhang-Tian. The motivation for the said combination would have been to enable monitoring a strategic position within the internal network (104) that provides a segment enforcer visibility to the east-west traffic flowing within a segment of the internal network (104) and enable identifying IoT devices within the internal network as prime targets for the execution of network threats.(Jadhav-Paragraph 2) Zhang-Tian-Jadhav disclosed (re. Claim 1) wherein the assigning is performed (Jadhav-Paragraph 43 ,any subsequent network packet determined to match a previously identified traffic flow is assigned the flow ID of that traffic flow ) without determining whether any values associated with any additional fields of the second header in addition to the tunnel identifier field and the source port identifier field match any identifiers of the plurality of fields in addition to the tunnel identifier field and the source port identifier field of the first packet.’ Regarding packet inspection and matching, the Examiner notes where Zhang is not limited to analyzing and matching packets using every data field in the header space. Zhang Paragraph 60 disclosed wherein analysis application(s) can use as input a flow region that spans the entire flow space (i.e., with every packet header field fully wildcarded), while other embodiments set certain fields (e.g., input ports). Furthermore Zhang Paragraph 92-93 disclosed the flow entries are organized in stages (e.g., ingress port mapping, one or more ACL stages, logical forwarding stages, tunneling stages, etc.), and the context register that identifies the stage is set to the value corresponding to the first stage upon input. Zhang Paragraph 95 disclosed wherein packet might be defined in the packet header representation (e.g., the input port and the context register). The Examiner notes wherein Zhang does not explicitly disclose using just two header field values: tunnel identifier (ID) and source port. The Supreme Court in KSR International Co. v. Teleflex Inc., identified a number of rationales to support a conclusion of obviousness which are consistent with the proper "functional approach" to the determination of obviousness as laid down in Graham. An exemplary rationale that may support a conclusion of obviousness is that of: (G) Some teaching, suggestion, or motivation in the prior art that would have led one of ordinary skill to modify the prior art reference or to combine prior art reference teachings to arrive at the claimed invention. The Examiner notes that before the time of the effective filing date of the claimed invention it would have been obvious to a person of ordinary skill in the networking art to use only certain fields (and not all fields) for analysis of the flow space as indicated by Zhang Paragraph 60. Furthermore it would have been obvious to use the Zhang tunnel identifier (ID) field and source port field in the analysis wherein the context register is indicating the tunneling stage. The motivation for the said implementation would have been to enable identifying flow entries that can be removed from the system at the earliest possible/relevant stage that may provide significant benefit in terms of memory usage. Zhang-Tian-Jadhav disclosed (re. Claim 1) obtaining, by the processing system, a third packet including a third header;(Zhang-Paragraph 44, allowing the MFE to create a new flow entry or set of flow entries such that future packets sent to the particular destination can be forwarded directly to their destination) extracting, by the processing system, a fourth value from a tunnel identifier field of the third header using the offset of the tunnel identifier field (Tian-Paragraph 75, learns a MAC address entry based on the inner source MAC address 00-00-00-00-00-02 and the VXLAN tunnel which is indicated by the VNI 100 ) and a fifth value from a source port identifier field of the third header (Tian-Paragraph 71, match fields may include: an ingress port field ) using the offset of the source port identifier field, without decapsulating the third packet; (Tian- Figure 3, Paragraph 49, it is determined that match fields of the flow entry include an offset match field, then a field is extracted from a received packet according to a match position of the offset match field and the number of bytes indicated by a match length of the offset match field ) determining, by the processing system, that at least one of: the fourth value does not match the first tunnel identifier or the fifth value does not match the first source port identifier, (Tian- Paragraph 18, When failing to find a matching flow entry, the SDN switch may send the packet as the first packet of a flow, Figure 3, Paragraph 49, it is determined that match fields of the flow entry include an offset match field, then a field is extracted from a received packet according to a match position of the offset match field and the number of bytes indicated by a match length of the offset match field ) resulting in the third packet not being sent to the first flow (Jadhav-Paragraph 69, in response to a low trust score and/or high risk score, the appropriate enforcement action may be to block the associated traffic flow from spreading into additional segments of the internal network. Alternatively, in response to a high trust score and/or low risk score, the appropriate enforcement action may be to allow the network packet(s) corresponding to the traffic flow to continue towards their intended destination) in response to the determining that at least one of: the fourth value does not match the first tunnel identifier or the fifth value does not match the first source port identifier. (Jadhav-Paragraph 45,Paragraph 46, if it is determined that the network packet flow ID cannot be found within the flow ID table (e.g., the network packet flow ID does not match the flow ID included in any of the table entries of the flow ID table).. in determining that the flow ID for the network packet could not be found within the flow ID table, a new table entry is generated ) In regard to Claim 17 Claim 17 (re. non-transitory computer-readable medium) recites substantially similar limitations as Claim 1. Claim 17 is rejected on the same basis as Claim 1. In regard to Claim 20 Claim 20 (re. device) recites substantially similar limitations as Claim 1. Claim 20 is rejected on the same basis as Claim 1. In regard to Claim 2 Zhang-Tian-Jadhav disclosed (re. Claim 2) wherein the first flow is characterized by the first tunnel identifier (Zhang- Paragraph 66, packet header data structure 700 includes a tunnel ID (sometimes referred to as register 0)) and the first source port identifier. (Zhang-Paragraph 67, layer 3 and layer 4 packet header fields (e.g., source and destination IP addresses, source and destination transport layer port numbers, transport protocol type) In regard to Claim 3,18 Zhang-Tian-Jadhav disclosed (re. Claim 3,18) wherein the offset of the tunnel identifier field comprises a number of data units from a start of the first packet to a start of the tunnel identifier field. (Zhang-Paragraph 53, bit range for analysis includes the first L bits of a packet that make up the packet header and M bits of metadata (e.g., register values, etc.) stored for the packet ) In regard to Claim 4,19 Zhang-Tian-Jadhav disclosed (re. Claim 4,19) wherein the offset of the source port identifier field comprises a number of bits from a start of the first packet to a start of the source port identifier field. (Zhang-Paragraph 53, bit range for analysis includes the first L bits of a packet that make up the packet header and M bits of metadata (e.g., register values, etc.) stored for the packet ) In regard to Claim 5 Zhang-Tian-Jadhav disclosed (re. Claim 5) assigning, by the processing system, a third packet to a second flow (Jadhav-Paragraph 45, if it is determined that the network packet flow ID cannot be found within the flow ID table (e.g., the network packet flow ID does not match the flow ID included in any of the table entries of the flow ID table).. in determining that the flow ID for the network packet could not be found within the flow ID table, a new table entry is generated ) in response to the determining that the third packet does not belong to the first flow. (Tian- Paragraph 18, When failing to find a matching flow entry, the SDN switch may send the packet as the first packet of a flow, Figure 3, Paragraph 49, it is determined that match fields of the flow entry include an offset match field, then a field is extracted from a received packet according to a match position of the offset match field and the number of bytes indicated by a match length of the offset match field ) In regard to Claim 6 Zhang-Tian-Jadhav disclosed (re. Claim 6) determining a second tunnel identifier (Zhang-Paragraph 66, packet header data structure 700 includes fields for the VLAN ID, source MAC address, destination MAC address, eight registers, and a tunnel ID (sometimes referred to as register 0). ) and a second source port identifier from a plurality of header fields of the third packet, (Zhang-Paragraph 67, layer 3 and layer 4 packet header fields (e.g., source and destination IP addresses, source and destination transport layer port numbers, transport protocol type ) wherein the second flow is characterized by the second tunnel identifier and the second source port identifier. In regard to Claim 8 Zhang-Tian-Jadhav disclosed (re. Claim 8) wherein the source port identifier field comprises a transport layer protocol header field. (Zhang-Paragraph 67, layer 3 and layer 4 packet header fields (e.g., source and destination IP addresses, source and destination transport layer port numbers, transport protocol type) In regard to Claim 9 Zhang-Tian-Jadhav disclosed (re. Claim 9) wherein the transport layer protocol header field comprises: a uniform datagram protocol header field; or a transmission control protocol header field.(Zhang-Paragraph 24, Ethernet frames, TCP segments, UDP datagrams, IP packets ) In regard to Claim 13 Zhang-Tian-Jadhav disclosed (re. Claim 13) wherein the first packet and the second packet both comprise packets of data plane traffic (Jadhav-Paragraph 42, payload/packet signature may specify that a network packet may have been generated by the BitTorrent software application for the purpose of peer-to-peer file sharing) In regard to Claim 16 Zhang-Tian-Jadhav disclosed (re. Claim 16) wherein the traffic that is copied comprises data plane traffic. (Jadhav-Paragraph 42, payload/packet signature may specify that a network packet may have been generated by the BitTorrent software application for the purpose of peer-to-peer file sharing ) In regard to Claim 21 Zhang-Tian-Jadhav disclosed (re. Claim 21) wherein the rule is maintained on the processing system (Zhang-Paragraph 79, physical network administrator (e.g., a private enterprise datacenter owner) could specify the network setup (e.g., the various ACL and other rules to have in place). Flow reachability analysis can then be performed to identify which flow entries do not need to be distributed to the managed forwarding elements, and the flow entry generation process (e.g., the table mapping engine, in some embodiments) adjusted accordingly before deployment) for matching the subsequently obtained packets to the first flow without maintaining the rule on another processing system of the plurality of processing systems. (Zhang-Paragraph 52, a network controller, or network analysis tool analyzing the output of a network controller, performs HSA on the flow entries generated by a network controller) In regard to Claim 22 Zhang-Tian-Jadhav disclosed (re. Claim 22) wherein the first packet, the second packet and the third packet are encapsulated in accordance with a protocol of a networking layer of the telecommunications service provider network.(Tian-Paragraph 65, The SDN controller 420 may decapsulate the VXLAN encapsulation) In regard to Claim 23 Zhang-Tian-Jadhav disclosed (re. Claim 23) wherein the first packet, the second packet, and the third packet each include at least one header of the following: an internet protocol header, a header for a transport layer protocol data unit, a virtual local area network identifier header, or a tunneling protocol header. (Tian- VXLAN tunnel which is indicated by the VNI 100 ) Claims 7 is/are rejected under 35 U.S.C. 103 as being unpatentable over Zhang (USPGPUB 2015/0016279) further in view of Tian (USPGPUB 2018/0048593) further in view of Jadhav (USPGPUB 2018/0063178) further in view of Hsu (USPGPUB 2015/0215841) In regard to Claim 7 While Zhang-Tian-Jadhav substantially disclosed the claimed invention Zhang-Tian-Jadhav does not disclose (re. Claim 7) wherein the first tunnel identifier comprises a general packet radio service tunnel identifier. Hsu Paragraph 37 disclosed wherein the communication sessions to which different subsets of traffic entering network switch 118 belong can be identified using GTP correlation cluster (GCC) 120. Hsu disclosed (re. Claim 7) wherein the first tunnel identifier comprises a general packet radio service tunnel identifier.(Hsu-Paragraph 4, GPRS Tunneling Protocol (GTP) is a group of Internet Protocol (IP)-based communications protocols used to carry packets conforming to the GPRS standard within GSM, UMTS and LTE networks. , Paragraph 71, GCC 120 can create session map 204 to map the particular GTP-C packet's IMSI to designated attributes such as a source IP address, a destination IP address, a transmission control protocol (TCP) port, and a tunnel identifier (TEID) specified in the particular GTP-C packet.) Zhang,Tian,Jadhav and Hsu are analogous art because they present concepts and practices regarding packet flow management. Before the time of the effective filing date of the claimed invention it would have been obvious to combine Hsu into Zhang-Tian-Jadhav. The motivation for the said combination would have been to enable ensuring a network switch will forward copies of non-control packets belonging to a particular communication session to the same analytic server even if address pairs of non-control packets within that particular communication session differ due to mobile device movement. (Hsu-Paragraph 47) Claims 10-11 is/are rejected under 35 U.S.C. 103 as being unpatentable over Zhang (USPGPUB 2015/0016279) further in view of Tian (USPGPUB 2018/0048593) further in view of Jadhav (USPGPUB 2018/0063178) further in view of Whiteside (US Patent 10033613). In regard to Claim 10 Zhang-Tian-Jadhav disclosed (re. Claim 10) extracting the first value and the second value from the second packet. (Tian- Figure 3, Paragraph 49, it is determined that match fields of the flow entry include an offset match field, then a field is extracted from a received packet according to a match position of the offset match field and the number of bytes indicated by a match length of the offset match field ) While Zhang-Tian-Jadhav substantially disclosed the claimed invention Zhang-Tian-Jadhav does not disclose (re. Claim 10) wherein the extraction is performed within a defined time window from the assigning of the first packet to the first flow. Whiteside disclosed wherein flow caching involves storing information about packet flows, which can be derived from the packets seen at a network node. The information stored for the packet flows may include information identifying the packet flow, and/or statistics about the packet flow. Whiteside Column 14 Lines 25-40 disclosed data collection interval may initially be set to an initial value that is estimated to be reasonable. The interval may then be adjusted each time the large flow data memory 364 is read. In some implementations, the interval may be increased or decreased in one second increments or increments of a fraction of a second, or in gradually decreasing increments (e.g., one second, one half second, one quarter second, one eight second, etc.). In some cases, the increment may be increased when it is found that the interval has needed to be adjusted in the same direction more than once in a row. Ideally, the interval should be adjusted until there are no overflows or collision errors. Whiteside disclosed (re. Claim 10) wherein the extraction is performed within a defined time window from the assigning of the first packet to the first flow. (Whiteside-Column 14 Lines 25-40, data collection interval may initially be set to an initial value that is estimated to be reasonable ) Zhang,Tian,Jadhav and Whiteside are analogous art because they present concepts and practices regarding packet flow management. Before the time of the effective filing date of the claimed invention it would have been obvious to combine Whiteside into Zhang-Tian-Jadhav. The motivation for the said combination would have been to enable adjusting the data collection interval until there are no overflows or collision errors. In regard to Claim 11 Zhang-Tian-Jadhav-Whiteside disclosed (re. Claim 11) reducing the defined time window (Whiteside- Column 14 Lines 25-40, the interval may be increased or decreased in one second increments or increments of a fraction of a second, or in gradually decreasing increments ) when a collision probability between the first flow and at least a second flow exceeds a collision probability threshold.(Whiteside-Column 15 Lines 10-20, When there were too many collision errors… the threshold may be reduced, Column 19 Lines 5-15, error statistics may keep track of the number of times a collision was seen for this data entry, and/or an approximation of how many individual flows collided on this data entry ) Claims 12 is/are rejected under 35 U.S.C. 103 as being unpatentable over Zhang (USPGPUB 2015/0016279) further in view of Tian (USPGPUB 2018/0048593) further in view of Jadhav (USPGPUB 2018/0063178) further in view of Whiteside (US Patent 10033613) further in view of Padiyar (US Patent 8160089). In regard to Claim 12 While Zhang-Tian-Jadhav substantially disclosed the claimed invention Zhang-Tian-Jadhav does not disclose (re. Claim 12) wherein the collision probability comprises a rate at which packets from the at least the second flow comprising the first tunnel identifier and the first source port identifier are detected within the defined time window. Padiyar Column 7 Lines 20-35 disclosed obtaining the number of collisions over a predetermined period of time, also referred to as a collision rate. The driver 204 adjusts the current IPG value by a step size and sets the device 202 to a new IPG value. The driver 204 waits a select period of time and again retrieves the number of collisions over a the period of time from the network device 202. If the number of collisions or the new collision rate is reduced, the newer IPG value is maintained, otherwise, the previous IPG value is re-written to the device. The driver 204 can make additional adjustments until a range of possible IPG values are employed and tested and can then select one that is suitable (e.g., the IPG value that provided the lowest number of collisions). Alternately, the driver 204 can make additional adjustments until an IPG value is obtained that yields a suitable collision rate. Padiyar disclosed (re. Claim 12) wherein the collision probability comprises a rate (Padiyar- Column 7 Lines 20-35,obtaining the number of collisions over a predetermined period of time, also referred to as a collision rate ) at which packets from the at least the second flow comprising the first tunnel identifier and the first source port identifier are detected within the defined time window. Zhang,Tian,Jadhav and Padiyar are analogous art because they present concepts and practices regarding packet flow management. Before the time of the effective filing date of the claimed invention it would have been obvious to combine Padiyar into Zhang-Tian-Jadhav. The motivation for the said combination would have been to enable adjustments until a range of possible IPG values are employed and tested and can then select one that is suitable (e.g., the IPG value that provided the lowest number of collisions). Conclusion Examiner’s Note: In the case of amending the claimed invention, Applicant is respectfully requested to indicate the portion(s) of the specification which dictate(s) the structure relied on for proper interpretation and also to verify and ascertain the metes and bounds of the claimed invention. 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 GREG C BENGZON whose telephone number is (571)272-3944. The examiner can normally be reached on Monday - Friday 8 AM - 4:30 PM. 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, John Follansbee can be reached on (571) 272-3964. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300. Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. /GREG C BENGZON/ Primary Examiner, Art Unit 2444
Read full office action

Prosecution Timeline

Sep 12, 2022
Application Filed
Sep 29, 2023
Non-Final Rejection — §103
Jan 04, 2024
Response Filed
Feb 23, 2024
Final Rejection — §103
May 24, 2024
Response after Non-Final Action
May 30, 2024
Applicant Interview (Telephonic)
May 30, 2024
Examiner Interview Summary
Jun 03, 2024
Response after Non-Final Action
Jun 25, 2024
Request for Continued Examination
Jul 02, 2024
Response after Non-Final Action
Oct 19, 2024
Non-Final Rejection — §103
Jan 23, 2025
Response Filed
Mar 07, 2025
Final Rejection — §103
Jun 05, 2025
Interview Requested
Jun 12, 2025
Request for Continued Examination
Jun 20, 2025
Response after Non-Final Action
Aug 27, 2025
Non-Final Rejection — §103
Nov 28, 2025
Response Filed
Feb 05, 2026
Final Rejection — §103 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12574727
EMERGENCY REPORTING SYSTEM FOR VEHICLE, AND VEHICLE
2y 5m to grant Granted Mar 10, 2026
Patent 12549481
PROACTIVE HASHING FOR PACKET PROCESSING ENGINE
2y 5m to grant Granted Feb 10, 2026
Patent 12543231
METHOD AND DEVICE FOR COMMUNICATION ON MULTIPLE LINKS, AND COMPUTER-READABLE STORAGE MEDIUM
2y 5m to grant Granted Feb 03, 2026
Patent 12537789
METHODS AND SYSTEM FOR DISTRIBUTING INFORMATION VIA MULTIPLE FORMS OF DELIVERY SERVICES
2y 5m to grant Granted Jan 27, 2026
Patent 12530951
METHOD AND SYSTEM FOR ENROLLING A CAMERA INTO A VIDEO SURVEILLANCE SYSTEM
2y 5m to grant Granted Jan 20, 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

7-8
Expected OA Rounds
58%
Grant Probability
64%
With Interview (+5.9%)
3y 11m
Median Time to Grant
High
PTA Risk
Based on 486 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