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 .
Drawings
The drawings were received on 2/20/2025. These drawings are accepted.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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.
Claim(s) 1-7,11-16,20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Sinha (US Publication No.: 20200366580) in view of Wighe et al (US Publication No.: 20250150391).
Claim 1, Sinha discloses
deploying a plurality of agents (Fig. 1a, label 102,106) in a cloud environment (Fig. 1a shows the cloud environment), wherein each agent of the plurality of agent is deployed onto a different node of a plurality of nodes (Fig. 1a, label 102,106 as nodes), and
wherein each agent of the plurality of agents (Fig. 1a, label 102,106) is:
executed in a kernel of a node on which the agent is deployed (Fig. 1b, label 120,197, paragraph 45 discloses “monitoring agents 120 and 197 may provide application performance management for application delivery system 190. For example, based upon one or more monitored performance conditions or metrics …”. Label 120,197 are part of respective nodes, 102,106.),
attached to network-related system calls in the kernel in which the network-related system calls are executed (Fig. 1b, label 102,106 as nodes, each attached to network related system calls (Fig. 1b, label 104,200) in the kernel om which the network-related system calls are executed (paragraph 45 discloses the kernel, 120,197, provide application performance management for application delivery system 190. Paragraph 38 discloses application delivery system 190 for delivering a computing environment, application (such as calls), and/or data files to one or more clients 102 from server 106.)), and
configured to monitor data associated with network traffic flows that originate from or received by the node (Paragraph 45 discloses 120,197 provides application performance management, such as metrics. Paragraph 90 discloses metrics “include volume, rate or timing of requests or responses received, transmitted or transversing the network element represented by the node or arc. Metrics may include metrics on usage of a resource by the element represented by the node, or arc.”) and
determine metrics associated with network traffic flows on the node based on the monitored data (Paragraph 90 discloses metrics regarding traffic.);
receiving, from each of the plurality of nodes, respective metrics associated with network traffic flows on the node determined by the agent deployed on the node (Paragraph 44 discloses 120,197 monitors metrics. Fig. 5a-c shows the network traffic with metrics received.);
identifying process-level network traffic flows based on the received metrics associated with network traffic flows (Fig. 5a-c shows the network device determining process-level network traffic flows (Fig. 5b shows the service graph displaying the process level network flows based on metrics associated with network traffic (paragraph 82 disclose metrics of network traffic of the service.) and a topology of the plurality of the nodes in the cloud environment (Fig. 5a, label 510 as the topology. Paragraph 83 discloses the identified topology 510 and metrics related to the network and the elements are used to generate and/or configure service graphs 505A-N.).;
generating a graph based on the identified process-level network traffic flows (Fig. 5b shows the graph generated based on identified process-level network traffic flows.),
the graph including a plurality of vertices representing source or destination processes running on the plurality of nodes, and edges linking the vertices representing process-level network traffic flows (Fig. 5b, label MS 575A,B,N as the microservice of nodes 570A-N), each vertex (Fig. 5b, label MS 575A,B,N) indicates a source or destination processes running on the plurality of nodes, nodes 570A-N) and edges linking vertices (Fig. 5b, label arcs) representing the process level network traffic flows.),
wherein the graph corresponds to the topology of the plurality of nodes (Fig. 5b shows the graph corresponds to topology of nodes 570a-n.), and the edges are annotated to indicate whether the corresponding traffic flows between nodes (Fig. 5b, label arcs); and
presenting the graph for display at a client device (Fig. 5b shows the service graph, Fig. 5a, label 514 shows the display. Paragraph 83 discloses user interface displaying the graph and Fig. 5a,5b shows a device on a network where Fig. 1b shows client device 102 as a device on the network.).
Sinha fails to disclose
classifying each of the process-level network flows into intra-zone or cross zone based on traffic being local or external to a zone; and a graph with edges or arcs indicating the classification as intra-zone or cross-zone.
Wighe et al discloses classifying each of the process-level network flows into intra-zone or cross zone based on traffic being local or external to a zone (Fig. 5, label 506. Paragraph 32 discloses the source an destination zones are identified and determines whether the network traffic is inner zone traffic, cross-zone traffic or external.) and a routing table (Fig. 4, label 400) comprising destination and source (Fig. 4, label source and dest) includes edges or FW are annotated or labeled indicating whether the network traffic is in a particular zone. (Fig. 7 shows an example of routing table similar to Fig. 4. The label or annotation for FW is dependent on the network traffic between source and destination is inner, cross-zone or external as per Fig. 5, where in the zone indicated in FW indicates the annotated zone as a result of the determination from Fig. 5. This indicates FW as the edges between source and destination.). It would be obvious to one skilled in the art before the effective filing date of the application to modify Sinha’s graph generation by incorporating classification of the process-level network flows as disclosed by Wighe et al so to provide efficient routing process with flexibility.
Claim 2, Sinha et al discloses the metrics associated with network traffic flows include one or more of packet volumes, packet retransmissions, packet drops, and latencies. (paragraph 83 discloses metrics are related to the network, wherein packet volumes, packet retransmission, packet drops and latencies are types of metrics related to the network. Paragraph 4 discloses metrics corresponding to network conditions and topology can be traffic volume, latency, etc.)
Claim 3, Sinha et al discloses wherein the agent is attached to the network related system calls in the kernal using eBPF (extended Berkley packet filter) hooks. (Paragraph 85 discloses “function node may represent a function that is applied to the traffic such as filter (firewalls), wherein eBPF hooks are types of filter (firewalls).).
Claim 4, Wighe et al discloses determining a topology of the plurality of nodes in the cloud environment based on metadata associated with the plurality of nodes (Fig. 3 shows the routing table generation using metadata such as IP address and zones.), the metadata associated with the plurality of nodes includes one or more of: node names, IP addresses, ports, regions, and zones associated with the plurality of nodes (Fig. 3, label 304 indicates the IP addresses for routing group address range, 302 as the number of zones in routing group.).
Claim 5, Wighe et al discloses identifying a plurality of levels of network traffic flows, including one or more of container level traffic flows, pod-level traffic flows, node-level traffic flows, and zone-level traffic flows (Fig. 7, label zone level traffic flows. Paragraphs 33-35 discloses inner, cross-zone, external zone network traffic indicating zone-level traffic flows.).
Claim 6, Sinha et al discloses the graph is dynamically updated in response to changes in the network traffic flows, including an addition of a new flow or termination of an existing flow. (Paragraph 83 discloses “service graph monitor 516 may monitor the network elements of the topology and service for metrics 518 to configure and generate a service graph505 and/or to update dynamically or in real-time the elements and metrics 518 of or represented by a service graph display 514.” By monitoring the network elements of the topology and service for metrics, changes found from such monitoring will enable dynamic updating of the service graph.)
Claim 7, Sinha et al discloses determining one or more network traffic metrics for each edge in the graph (Paragraph 88 discloses arcs represent a state or status of one or more metrics. Fig. 5b, label arcs indicates the edges between nodes. Fig. 5a, label 518 indicates the determined or monitored network traffic metrics.), wherein the one or more network traffic metrics include volume, bandwidth usage, latency, and packet loss associated with the corresponding process-level network traffic flow (Paragraph 111 discloses metrics such as traffic volume, latency, error rates and so forth.), and the edges of the graph is further annotated with the one or more network traffic metrics (paragraph 88 discloses arcs of the service graph represent a state or status of one or mor metrics. Paragraph 126 discloses “The arc may identify the monitored metrics through changing the shape, format, etc.”).
Claim 11 recites similar limitations as claim 1 and is rejected on the same ground as claim 1.
Claim 12 recites similar limitations as claim 2 and is rejected on the same ground as claim 2.
Claim 13 recites similar limitations as claim 3 and is rejected on the same ground as claim 3.
Claim 14 recites similar limitations as claim 5 and is rejected on the same ground as claim 5.
Claim 15 recites similar limitations as claim 4 and is rejected on the same ground as claim 4.
Claim 16 recites similar limitations as claim 7 and is rejected on the same ground as claim 7.
Claim 20 recites similar limitations as claim 1 and is rejected on the same ground as claim 1. In addition, Sinhe et al discloses one or more processors (paragraph 47); and a non-transitory computer readable storage medium having instructions encoded thereon that, when executed by one or more processors, cause the one or more processors (paragraph 48 discloses processor execute one or more computer programs. Paragraph 47 discloses memory storing computer instructions or programs.) to perform steps as recited in claim 1 (please see claim 1).
Allowable Subject Matter
Claims 8-10, 17-19 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to LINDA WONG whose telephone number is (571)272-6044. The examiner can normally be reached 9-5.
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, Andrew C Flanders can be reached at 571-272-7516. 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.
/LINDA WONG/Primary Examiner, Art Unit 2655
