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 reply to communication filed on 03/06/2025. Claimed priority is granted from priority patent application 19/060,271, filed on 06/29/2023.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 06/11/2025 was filed simultaneously with the original filing. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
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-28 are rejected under 35 U.S.C. 103 as being unpatentable over Rosenberg, US 10523536 B2, in view of Pularikkal, US 10,904,322 (hereinafter Pula).
Regarding claim 1, Rosenberg teaches the invention substantially as claimed. Rosenberg discloses a network monitoring architecture in which a plurality of traffic monitor nodes, i.e. network nodes corresponding to compute nodes – extract and forward packet header portions (partially replicated data packets) to a central sFlow Collector (gateway device). Specifically, Rosenberg discloses a method comprising:
receiving, by a gateway device and from a plurality of compute nodes, a plurality of partially replicated data packets (col. 3, lines 10-30, abstract; Each traffic monitor node (compute node) extracts a packet header from each monitored data packet, producing a partially replicated data packet consisting of the packet header);
determining, based on the plurality of partially replicated data packets, traffic data associated with the plurality of compute nodes (abstract, col. 3, lines 35-50; the extracted packet header portions are transmitted to a central sFlow Collector that “is responsible for collecting sFlow datagrams from a plurality of network nodes”, Thus teaching receiving, by a gateway device, a plurality of partially replicated data packets from a plurality of compute nodes). Further the sFlow Collector analyzes the received header datagrams to produce a “rich, real-time, network-wide view of traffic flows” associated with each sending node, thereby determining traffic data associated with the plurality of compute nodes). In addition, the sFlow datagrams are encapsulated UDP datagrams, and the Collector performs decapsulation to process them (Abstract, col. 3, lines 55-65).
However, Rosenberg does not disclose the details of causing, based on the traffic data, adjustment of resources allocated to the plurality of compute nodes. This feature is well-known in the art, as evidenced Pula. This secondary prior art of Pula remedies this deficiency, disclosing a cloud-based system that:
Monitors network metrics (traffic data) associated with individual server or gateway instances [(compute nodes); Abstract, col. 2, lines 30-50]
Automatically causes adjustment of resources (scaling up or scaling down server/gateway instances) based on the detected traffic data/network metrics (Abstract, claims 1, 13; col. 3. Lines 15-40)
Transmits instructions from a management system to instantiate or terminate server instances (gateway elements) base on traffic-derived thresholds (col. 2, lines 45-65; col. 3, lines 20-40).
Accordingly, it would have been obvious to a person of ordinary skill in the art (POSITA), at the time of the invention, to combine the packet header replication and traffic monitoring system of Rosenberg with the traffic-driven automated resource scaling system of Pula. Both references are directed to the same technical field of network traffic management and resource optimization in distributed, cloud-based network architecture. A POSITA would have been motivated to combine the teaching because:
The sFlows traffic data collected in Rosenberg provides exactly the type of network metrics (packet counts, flow rates, node utilization) that Pula’s scaling system is designed to act upon. It would have been predictable, routine engineering choice to feed the traffic data already collected by Rosenberg system into a resource management module like that of Pula. Rosenberg itself recognizes the need for “improved scaling characteristics” based on the traffic data analysis (col. 5, lines 1-15), providing an explicit suggestion within the primary reference to pursue the resource scaling taught by Pula.
The combination uses known techniques (packet header replication for monitoring; traffic-driven auto-scaling) to yield predictable results (efficient, scalable network resource management), with no unexpected result. See KSR Int’l Co. v. Teleflex Inc., 550 U.S. 398 (2007) (combination of familiar elements using known methods to yield predictable results is obvious). Both references belong to the same field of endeavor (virtualized network resource management and traffic monitoring), and a POSITA regularly working with sFlow-based monitoring (Rosenberg) would be aware of and motivated to apply contemporaneous cloud auto-scaling techniques (Pula) to achieve the claimed method. By this rationale, the combination of Rosenberg and Pula renders claim 1 is rejected.
Regarding claims 2-28, the combination Rosenberg-Pula teaches:
2. (New) The method of claim 1, wherein at least one of the partially replicated data packets consists of a first packet header; and wherein the first packet header is a replicate of a second packet header of a data packet received at one of the plurality of compute nodes (Rosenberg discloses this limitation explicitly as its core inventive concept). At col. 3, lines 10-30 and in the Abstract, Rosenberg teaches that the sFlow Agent extracts a copy of the packet header from each monitored data packet (the original data packet received at the compute node) and includes that extracted header copy in the sFlow datagram transmitted to the collector). The extracted packet header is thus a replicate of the original packet header. Accordingly, claim 2 is obvious over Rosenberg alone, or in combination with Pula as applied to claim 1.
3. (New) The method of claim 1, wherein each of the plurality of partially replicated data packets comprises a marker indicating whether the partially replicated data packet is a partially replicated upstream data packets or a partially replicated downstream data packet. Rosenberg discloses at col. 4, lines 20-45 that the extracted data packet header portion contain protocol header fields including directional identifiers, port numbers, and flow identifiers that identify the direction and the type of traffic. These fields constitute a marker indicating the directionality (upstream/downstream) of the monitored data packet. It would have been obvious for a POSITA to include such directional markers in the extracted packet headers as a routine and known implementation detail in the packet monitoring systems to differentiate traffic flows. Accordingly, claim 3 is obvious in view of Rosenberg, in further combination with Pula as applied in the independent claim.
4. (New) The method of claim 1, wherein the plurality of partially replicated data packets are encapsulated, and wherein the receiving the plurality of partially replicated data packets comprises decapsulating the plurality of partially replicated data packets. Rosenberg explicitly disclose this limitation. The sFlow datagrams are encapsulated UDP datagrams (Abstract, col. 5, lines 55-65). The sFlow Collector (gateway) receives these encapsulated datagrams and processes them, which necessarily involves decapsulation to extract the payload. Encapsulation in UDP and the decapsulation at the collector is inherent to and expressly described by the sFlow protocol taught in Rosenberg. Accordingly, claim 4 is obvious in view of Rosenberg, in further combination with Puta as applied to claim 1.
5. (New) The method of claim 1, wherein the traffic data indicate a need for one or more additional compute nodes, and wherein the causing the adjustment of resources allocated to the plurality of compute nodes comprises: sending, to a management device, the traffic data; receiving, from the management device and based on the sending of the traffic data, an instruction to instantiate an additional gateway element; and instantiating, based on the instruction, the additional gateway element. While Rosenberg teaches sending traffic data to a collector/analysis node (col. 5, lines 1-15), Rosenberg does not explicitly teach dynamic instantiation of a gateway element based on traffic data. Pula explicitly teaches all sub-elements of claim 5. Pula discloses that:
network traffic metrics (traffic data) associated with server/gateway instances indicate a need for additional instances (Abstract, col. 2, lines 45-65);
traffic data is sent to a management system/controller (col. 3, lines 20-35);
the management system/controller issues an instruction to spin up (instantiate) and additional gateway instance (col. 3, lines 15-40; claim 1); and
the additional gateway instance is instantiated based on the instruction (Abstract, col. 3, lines 35-50).
For the reasons to combine stated in connection with claim 1, the combination of Rosenberg and Pula renders claim 5 obvious. A POSITA would have been motivated to apply the resources instantiation mechanism of Pula to the traffic data output of the Rosenberg system to achieve scalable, demand-responsive network infrastructure.
6. (New) The method of claim 1, further comprising: receiving, from each of the plurality of compute nodes, a second plurality of partially replicated data packets associated with user interaction with content; determining, based on the second plurality of partially replicated data packets, information associated with the user interaction; and sending, to a management device, the information. Rosenberg discloses a network monitoring architecture in which sFlow Agents at each network node (compute node) continuously sample and extract packet headers from all data packets transiting those nodes, then forward the extracted header portions – i.e., partially replicated data packets – to the central sFlow Collector (gateway). See Rosenberg, Abstract; col. 2, lines 40-55; col. 3, lines 10-45. Importantly, Rosenberg teaches that the sFlow Agent operates on all traffic classes traversing the node, without restriction to a particular traffic type. See also Rosenberg, col. 4, lines 5-25 wherein, the sFlow datagrams maybe analyzed to produce a rich, real-time, network-wide view of traffic flows, with traffic flow information derived from the extracted headers of all sampled packets. Additionally, Rosenberg does not expressly call out user interaction with content as a discrete traffic category. Pula remedies this gap. Pula discloses monitoring network metrics associated with client connections to server/gateway instances, which inherently includes the traffic generated by users interacting with content served by those compute nodes (see Pula, Abstract, col. 2. lines 30-55). A POSITA would have recognized that the packet headers collected by Rosenberg’s sFlow system are generated by user sessions (user interaction with content), and that selecting or making a subset of those headers for content-interaction analysis is a straightforward application of the monitoring framework Rosenberg discloses. See also Rosenberg, Abstract, col. 3, lines 15-50; col. 2, lines 20-30; see Pula, col. 3, lines 15-40 and the disclosure of claim 1). Both references therefore teach sending determined user-interaction-related information to a management to a management device. See Rosenberg for additional motivation to combine (col. 2, lines 20-30).
7. (New) The method of claim 1, wherein the determining the traffic data comprises determining one of more of: quantities of partially replicated data packets associated with each compute node of the plurality of compute nodes; time information of partially replicated data packets associated with each compute node of the plurality of compute nodes; identification information of partially replicated data packets associated with each compute node of the plurality of compute nodes; or quality of service (QoS) information of partially replicated data packets associated with each compute node of the plurality of compute nodes. See Rosenberg, col. 2, lines 45-55, col. 3, lines 55-65; col. 3, lines 20-40, col. 4, lines 10-30, col. 2, lined 45-60; col. 3, lines 10-30, col. 4, lines 20-35; col. 3, lines 35-50; see Pula, col. 2, lines 30-50). By this rationale, the claim is rejected.
8. (New) A gateway device comprising: one or more processors; and memory storing instructions that, when executed by the one or more processors, cause the gateway device to: receive, from a plurality of compute nodes, a plurality of partially replicated data packets (col. 3, lines 10-30, abstract); determine, based on the plurality of partially replicated data packets, traffic data associated with the plurality of compute nodes (Abstract, col. 3, lines 35-50; col. 3, lines 55-65); and cause, based on the traffic data, adjustment of resources allocated to the plurality of compute nodes [(compute nodes); Pula; Abstract, col. 2, lines 30-50]. The same motivation and reason to combine used for the rejection of claim 1 is also valid for this claim. By this rationale, claim 1 is rejected.
.
9. (New) The gateway device of claim 8, wherein at least one of the partially replicated data packets consists of a first packet header; and wherein the first packet header is a replicate of a second packet header of a data packet received at one of the plurality of compute nodes (78, col. 3, lines 10-30 and in the Abstract).
10. (New) The gateway device of claim 8, wherein each of the plurality of partially replicated data packets comprises a marker indicating whether the partially replicated data packet is a partially replicated upstream data packets or a partially replicated downstream data packet (Rosenberg; col. 4, lines 20-45).
11. (New) The gateway device of claim 8, wherein the plurality of partially replicated data packets are encapsulated, and wherein the instructions, when executed by the one or more processors, cause the gateway device to receive the plurality of partially replicated data packets by decapsulating the plurality of partially replicated data packets (Rosenberg; Abstract, col. 5, lines 55-65).
12. (New) The gateway device of claim 8, wherein the traffic data indicate a need for one or more additional compute nodes, and wherein the instructions, when executed by the one or more processors, cause the gateway device to cause the adjustment of resources allocated to the plurality of compute nodes by: sending, to a management device, the traffic data; receiving, from the management device and based on the sending of the traffic data, an instruction to instantiate an additional gateway element; and instantiating, based on the instruction, the additional gateway element. While Rosenberg teaches sending traffic data to a collector/analysis node (col. 5, lines 1-15), Rosenberg does not explicitly teach dynamic instantiation of a gateway element based on traffic data. Pula explicitly teaches all sub-elements of claim 5. Pula discloses that:
network traffic metrics (traffic data) associated with server/gateway instances indicate a need for additional instances (Abstract, col. 2, lines 45-65);
traffic data is sent to a management system/controller (col. 3, lines 20-35);
the management system/controller issues an instruction to spin up (instantiate) and additional gateway instance (col. 3, lines 15-40; claim 1); and
the additional gateway instance is instantiated based on the instruction (Abstract, col. 3, lines 35-50).
For the reasons to combine stated in connection with claim 1, the combination of Rosenberg and Pula renders claim 5 obvious. A POSITA would have been motivated to apply the resources instantiation mechanism of Pula to the traffic data output of the Rosenberg system to achieve scalable, demand-responsive network infrastructure.
.
13. (New) The gateway device of claim 8, wherein the instructions, when executed by the one or more processors, further cause the gateway device to: receive, from each of the plurality of compute nodes, a second plurality of partially replicated data packets associated with user interaction with content; determine, based on the second plurality of partially replicated data packets, information associated with the user interaction; and send, to a management device, the information. Rosenberg discloses a network monitoring architecture in which sFlow Agents at each network node (compute node) continuously sample and extract packet headers from all data packets transiting those nodes, then forward the extracted header portions – i.e., partially replicated data packets – to the central sFlow Collector (gateway). See Rosenberg, Abstract; col. 2, lines 40-55; col. 3, lines 10-45. Importantly, Rosenberg teaches that the sFlow Agent operates on all traffic classes traversing the node, without restriction to a particular traffic type. See also Rosenberg, col. 4, lines 5-25 wherein, the sFlow datagrams maybe analyzed to produce a rich, real-time, network-wide view of traffic flows, with traffic flow information derived from the extracted headers of all sampled packets. Additionally, Rosenberg does not expressly call out user interaction with content as a discrete traffic category. Pula remedies this gap. Pula discloses monitoring network metrics associated with client connections to server/gateway instances, which inherently includes the traffic generated by users interacting with content served by those compute nodes (see Pula, Abstract, col. 2. lines 30-55). A POSITA would have recognized that the packet headers collected by Rosenberg’s sFlow system are generated by user sessions (user interaction with content), and that selecting or making a subset of those headers for content-interaction analysis is a straightforward application of the monitoring framework Rosenberg discloses. See also Rosenberg, Abstract, col. 3, lines 15-50; col. 2, lines 20-30; see Pula, col. 3, lines 15-40 and the disclosure of claim 1). Both references therefore teach sending determined user-interaction-related information to a management to a management device. See Rosenberg for additional motivation to combine (col. 2, lines 20-30).
14. (New) The gateway device of claim 8, wherein the instructions, when executed by the one or more processors, cause the gateway device to determine the traffic data by determining one of more of: quantities of partially replicated data packets associated with each compute node of the plurality of compute nodes; time information of partially replicated data packets associated with each compute node of the plurality of compute nodes; identification information of partially replicated data packets associated with each compute node of the plurality of compute nodes; or quality of service (QoS) information of partially replicated data packets associated with each compute node of the plurality of compute nodes. . See Rosenberg, col. 2, lines 45-55, col. 3, lines 55-65; col. 3, lines 20-40, col. 4, lines 10-30, col. 2, lined 45-60; col. 3, lines 10-30, col. 4, lines 20-35; col. 3, lines 35-50; see Pula, col. 2, lines 30-50). By this rationale, the claim is rejected.
15. (New) A non-transitory computer readable medium storing instructions that, when executed, cause: receiving, from a plurality of compute nodes, a plurality of partially replicated data packets (col. 3, lines 10-30, abstract); determining, based on the plurality of partially replicated data packets, traffic data associated with the plurality of compute nodes (Abstract, col. 3, lines 35-50; lines 55-65); and causing, based on the traffic data, adjustment of resources allocated to the plurality of compute nodes [(compute nodes); Pula; Abstract, col. 2, lines 30-50]. The same motivation and reason to combine used for the rejection of claim 1 is also valid for this claim. By this rationale, claim 1 is rejected.
16. (New) The non-transitory computer readable medium of claim 15, wherein at least one of the partially replicated data packets consists of a first packet header; and wherein the first packet header is a replicate of a second packet header of a data packet received at one of the plurality of compute nodes (Rosenberg, col. 3, lines 10-30 and in the Abstract).
17. (New) The non-transitory computer readable medium of claim 15, wherein each of the plurality of partially replicated data packets comprises a marker indicating whether the partially replicated data packet is a partially replicated upstream data packets or a partially replicated downstream data packet (Rosenberg; col. 4, lines 20-45).
18. (New) The non-transitory computer readable medium of claim 15, wherein the plurality of partially replicated data packets are encapsulated, and wherein the instructions, when executed, cause receiving the plurality of partially replicated data packets by decapsulating the plurality of partially replicated data packets (Rosenberg; Abstract, col. 5, lines 55-65).
19. (New) The non-transitory computer readable medium of claim 15, wherein the traffic data indicate a need for one or more additional compute nodes, and wherein the instructions, when executed, cause the adjustment of resources allocated to the plurality of compute nodes by: sending, to a management device, the traffic data; receiving, from the management device and based on the sending of the traffic data, an instruction to instantiate an additional gateway element; and instantiating, based on the instruction, the additional gateway element. While Rosenberg teaches sending traffic data to a collector/analysis node (col. 5, lines 1-15), Rosenberg does not explicitly teach dynamic instantiation of a gateway element based on traffic data. Pula explicitly teaches all sub-elements of claim 5. Pula discloses that:
network traffic metrics (traffic data) associated with server/gateway instances indicate a need for additional instances (Abstract, col. 2, lines 45-65);
traffic data is sent to a management system/controller (col. 3, lines 20-35);
the management system/controller issues an instruction to spin up (instantiate) and additional gateway instance (col. 3, lines 15-40; claim 1); and
the additional gateway instance is instantiated based on the instruction (Abstract, col. 3, lines 35-50).
For the reasons to combine stated in connection with claim 1, the combination of Rosenberg and Pula renders claim 5 obvious. A POSITA would have been motivated to apply the resources instantiation mechanism of Pula to the traffic data output of the Rosenberg system to achieve scalable, demand-responsive network infrastructure.
20. (New) The non-transitory computer readable medium of claim 15, wherein the instructions, when executed, further cause: receiving, from each of the plurality of compute nodes, a second plurality of partially replicated data packets associated with user interaction with content; determining, based on the second plurality of partially replicated data packets, information associated with the user interaction; and ending, to a management device, the information. Rosenberg discloses a network monitoring architecture in which sFlow Agents at each network node (compute node) continuously sample and extract packet headers from all data packets transiting those nodes, then forward the extracted header portions – i.e., partially replicated data packets – to the central sFlow Collector (gateway). See Rosenberg, Abstract; col. 2, lines 40-55; col. 3, lines 10-45. Importantly, Rosenberg teaches that the sFlow Agent operates on all traffic classes traversing the node, without restriction to a particular traffic type. See also Rosenberg, col. 4, lines 5-25 wherein, the sFlow datagrams maybe analyzed to produce a rich, real-time, network-wide view of traffic flows, with traffic flow information derived from the extracted headers of all sampled packets. Additionally, Rosenberg does not expressly call out user interaction with content as a discrete traffic category. Pula remedies this gap. Pula discloses monitoring network metrics associated with client connections to server/gateway instances, which inherently includes the traffic generated by users interacting with content served by those compute nodes (see Pula, Abstract, col. 2. lines 30-55). A POSITA would have recognized that the packet headers collected by Rosenberg’s sFlow system are generated by user sessions (user interaction with content), and that selecting or making a subset of those headers for content-interaction analysis is a straightforward application of the monitoring framework Rosenberg discloses. See also Rosenberg, Abstract, col. 3, lines 15-50; col. 2, lines 20-30; see Pula, col. 3, lines 15-40 and the disclosure of claim 1). Both references therefore teach sending determined user-interaction-related information to a management to a management device. See Rosenberg for additional motivation to combine (col. 2, lines 20-30).
21. (New) The non-transitory computer readable medium of claim 15, wherein the instructions, when executed, cause determining the traffic data by determining one of more of: quantities of partially replicated data packets associated with each compute node of the plurality of compute nodes; time information of partially replicated data packets associated with each compute node of the plurality of compute nodes; identification information of partially replicated data packets associated with each compute node of the plurality of compute nodes; or quality of service (QoS) information of partially replicated data packets associated with each compute node of the plurality of compute nodes. . See Rosenberg, col. 2, lines 45-55, col. 3, lines 55-65; col. 3, lines 20-40, col. 4, lines 10-30, col. 2, lined 45-60; col. 3, lines 10-30, col. 4, lines 20-35; col. 3, lines 35-50; see Pula, col. 2, lines 30-50). By this rationale, the claim is rejected.
22. (New) A system comprising: a plurality of compute nodes; and a gateway device configured to: receive, from the plurality of compute nodes, a plurality of partially replicated data packets (col. 3, lines 10-30, abstract); determine, based on the plurality of partially replicated data packets, traffic data associated with the plurality of compute nodes ((Abstract, col. 3, lines 35-50; col. 3, lines 55-65); and cause, based on the traffic data, adjustment of resources allocated to the plurality of compute nodes [(compute nodes); Pula; Abstract, col. 2, lines 30-50]. The same motivation and reason to combine used for the rejection of claim 1 is also valid for this claim. By this rationale, claim 1 is rejected.
23. (New) The system of claim 22, wherein at least one of the partially replicated data packets consists of a first packet header; and wherein the first packet header is a replicate of a second packet header of a data packet received at one of the plurality of compute nodes (Rosenberg, col. 3, lines 10-30 and in the Abstract).
24. (New) The system of claim 22, wherein each of the plurality of partially replicated data packets comprises a marker indicating whether the partially replicated data packet is a partially replicated upstream data packets or a partially replicated downstream data packet (Rosenberg; col. 4, lines 20-45).
25. (New) The system of claim 22, wherein the plurality of partially replicated data packets are encapsulated, and wherein the gateway device is configured to receive the plurality of partially replicated data packets by decapsulating the plurality of partially replicated data packets (Rosenberg; Abstract, col. 5, lines 55-65).
26. (New) The system of claim 22, wherein the traffic data indicate a need for one or more additional compute nodes, wherein the gateway device is configured to cause the adjustment of resources allocated to the plurality of compute nodes by: sending, to a management device, the traffic data; receiving, from the management device and based on the sending of the traffic data, an instruction to instantiate an additional gateway element; and instantiating, based on the instruction, the additional gateway element. While Rosenberg teaches sending traffic data to a collector/analysis node (col. 5, lines 1-15), Rosenberg does not explicitly teach dynamic instantiation of a gateway element based on traffic data. Pula explicitly teaches all sub-elements of claim 5. Pula discloses that:
network traffic metrics (traffic data) associated with server/gateway instances indicate a need for additional instances (Abstract, col. 2, lines 45-65);
traffic data is sent to a management system/controller (col. 3, lines 20-35);
the management system/controller issues an instruction to spin up (instantiate) and additional gateway instance (col. 3, lines 15-40; claim 1); and
the additional gateway instance is instantiated based on the instruction (Abstract, col. 3, lines 35-50).
For the reasons to combine stated in connection with claim 1, the combination of Rosenberg and Pula renders claim 5 obvious. A POSITA would have been motivated to apply the resources instantiation mechanism of Pula to the traffic data output of the Rosenberg system to achieve scalable, demand-responsive network infrastructure.
27. (New) The system of claim 22, wherein the gateway device is further configured to: receive, from each of the plurality of compute nodes, a second plurality of partially replicated data packets associated with user interaction with content; determine, based on the second plurality of partially replicated data packets, information associated with the user interaction; and send, to a management device, the information. Rosenberg discloses a network monitoring architecture in which sFlow Agents at each network node (compute node) continuously sample and extract packet headers from all data packets transiting those nodes, then forward the extracted header portions – i.e., partially replicated data packets – to the central sFlow Collector (gateway). See Rosenberg, Abstract; col. 2, lines 40-55; col. 3, lines 10-45. Importantly, Rosenberg teaches that the sFlow Agent operates on all traffic classes traversing the node, without restriction to a particular traffic type. See also Rosenberg, col. 4, lines 5-25 wherein, the sFlow datagrams maybe analyzed to produce a rich, real-time, network-wide view of traffic flows, with traffic flow information derived from the extracted headers of all sampled packets. Additionally, Rosenberg does not expressly call out user interaction with content as a discrete traffic category. Pula remedies this gap. Pula discloses monitoring network metrics associated with client connections to server/gateway instances, which inherently includes the traffic generated by users interacting with content served by those compute nodes (see Pula, Abstract, col. 2. lines 30-55). A POSITA would have recognized that the packet headers collected by Rosenberg’s sFlow system are generated by user sessions (user interaction with content), and that selecting or making a subset of those headers for content-interaction analysis is a straightforward application of the monitoring framework Rosenberg discloses. See also Rosenberg, Abstract, col. 3, lines 15-50; col. 2, lines 20-30; see Pula, col. 3, lines 15-40 and the disclosure of claim 1). Both references therefore teach sending determined user-interaction-related information to a management to a management device. See Rosenberg for additional motivation to combine (col. 2, lines 20-30).
28. (New) The system of claim 22, wherein the gateway device is configured to determine the traffic data by determining one of more of: quantities of partially replicated data packets associated with each compute node of the plurality of compute nodes; time information of partially replicated data packets associated with each compute node of the plurality of compute nodes; identification information of partially replicated data packets associated with each compute node of the plurality of compute nodes; or quality of service (QoS) information of partially replicated data packets associated with each compute node of the plurality of compute nodes. See Rosenberg, col. 2, lines 45-55, col. 3, lines 55-65; col. 3, lines 20-40, col. 4, lines 10-30, col. 2, lined 45-60; col. 3, lines 10-30, col. 4, lines 20-35; col. 3, lines 35-50; see Pula, col. 2, lines 30-50). By this rationale, the claim is rejected.
CONCLUSION
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Jude Jean-Gilles whose telephone number is 571-272-3914. The examiner can normally be reached on Mon-Fri, from 9:00AM-5: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, Tonia Dollinger can be reached on 571-272-4170. 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.
/JUDE JEAN GILLES/Primary Examiner, Art Unit 2459
May 29, 2026
Prosecution Insights