DETAILED ACTION
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 .
Status of Claims
Claims 21-24, 26-33, and 35-40 are pending in this Office Action.
Response to Arguments
Applicant's arguments filed in the amendment on 04/21/2026, have been fully considered but they are moot in view of new grounds of rejections. The reasons are set forth below.
Drawings
The formal drawings received on 12/28/2020 have been entered.
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) 21-24, 26-33, and 35-41 is/are rejected under 35 U.S.C. 103 as being unpatentable over Sigelman et al. (Dapper, a Large-Scale Distributed Systems Tracing Infrastructure, April 2010, Google, pages 1-14, hereinafter, “Sigelman,” provided in the IDS dated 03/15/2021) in view of Zhang et al. (US 20150180755), and further in view of Reynolds et al. (Pip: Detecting the Unexpected in Distributed Systems, 07 May 2007, The University of Wisconsin Madison, pages 1-17, hereinafter, “Reynolds”) and Banks et al. (US 2011/0134797).
Claims 21, 30, 39. Sigelman teaches:
A method, comprising: generating a plurality of trace events at a plurality of system nodes of an online distributed computer system for a plurality of request paths, – on pages 1-4, 8, 12, 13, Figs. 1-5 (Here we introduce the design of Dapper, Google’s production distributed systems tracing infrastructure. The Dapper “Depot API,” or DAPI, provides direct access to the distributed trace records in the regional Dapper repositories (or “Depots”). Dapper uses a global identifier to tie together related events from various parts of a distributed system. An additional design goal is for tracing data to be available for analysis quickly after it is generated: ideally within a minute. A tracing infrastructure for distributed services needs to record information about all the work done in a system on behalf of a given initiator. The resulting system also includes code to collect traces, tools to visualize them, and libraries and APIs (Application Programming Interfaces) to analyze large collections of traces. Figure 3 provides a more detailed view of the logged events in a typical Dapper trace span. A simple yet useful distributed trace for this request would be a collection of message identifiers and timestamped events for every message sent and received at each server. When a thread handles a traced control path, Dapper attaches a trace context to thread-local storage.)
wherein each trace event in the plurality of trace events is generated for both a corresponding request path in the plurality of request paths and for a corresponding span of the corresponding request path, – on pages 1-4, Figs. 1-5 (For example, Figure 1 shows a service with 5 servers: a front-end (A), two middle-tiers (B and C) and two backends (D and E). When a user request (the initiator in this case) arrives at the front end, it sends two RPCs to servers B and C. B can respond right away, but C requires work from backends D and E before it can reply to A, which in turn responds to the originating request. A simple yet useful distributed trace for this request would be a collection of message identifiers and timestamped events for every message sent and received at each server. Dapper records a human-readable span name for each span, as well as a span id and parent id in order to reconstruct the causal relationships between the individual spans in a single distributed trace. When a thread handles a traced control path, Dapper attaches a trace context to thread-local storage. A trace context is a small and easily copyable container of span attributes such as trace and span ids.)
the corresponding span representing computation performed by a system node at which the trace event is generated; – on pages 3, Figs. 1-5 (In a Dapper trace tree, the tree nodes are basic units of work which we refer to as spans. Dapper records a human-readable span name for each span, as well as a span id and parent id in order to reconstruct the causal relationships between the individual spans in a single distributed trace.)
wherein the subset of the plurality of trace events is identified based on one or more span identifiers associated with the particular system node and one or more parent span identifiers associated with the parent system node in the subset of the plurality of trace events; – on pages 2-4, Figs. 1-5 (Dapper records a human-readable span name for each span, as well as a span id and parent id in order to reconstruct the causal relationships between the individual spans in a single distributed trace. All spans associated with a specific trace also share a common trace id (not shown in the figure).)
computing a span metric aggregate from one or more span metrics in the subset of the plurality of trace events; – on pages 3-5, 13, Figs. 1-5 (Two classes of solutions have been proposed to aggregate this information so that one can associate all record entries with a given initiator (e.g., RequestX in Figure 1), black-box and annotation-based monitoring schemes. Black-box schemes [1, 15, 2] assume there is no additional information other than the message record described above, and use statistical regression techniques to infer that association. Figure 3 provides a more detailed view of the logged events in a typical Dapper trace span. Span data is written (1) to local log files. Annotation-based schemes [3, 12, 9, 16] rely on applications or middleware to explicitly tag every record with a global identifier that links these message records back to the originating request. Dapper uses a global identifier to tie together related events from various parts of a distributed system.)
wherein the plurality of trace events being associated with a particular system node and a parent system node of the particular system node – on pages 1-14 (In a Dapper trace tree, the tree nodes are basic units of work which we refer to as spans. The edges indicate a casual relationship between a span and its parent span. Dapper records a human-readable span name for each span, as well as a span id and parent id in order to reconstruct the causal relationships between the individual spans in a single distributed trace. Spans created without a parent id are known as root spans. All spans associated with a specific trace also share a common trace id. The instrumentation points described above are sufficient to derive detailed traces of complex distributed systems, making the core Dapper functionality available to otherwise unmodified Google applications.)
Sigelman does not explicitly teach:
identifying, for the plurality of request paths, a subset of the plurality of trace events based on the subset of the plurality of trace events being associated with a particular system node across multiple request paths included in the plurality of request paths.
However, Zhang teaches:
identifying, for the plurality of request paths, a subset of the plurality of trace events based on the subset of the plurality of trace events being associated with a particular system node across multiple request paths included in the plurality of request paths, – in paragraphs [0042]-[0070] (The trace slice clustering 401 constructs the clusters of trace slices based on the similarity of the paths of packets. This path similarity is determined as the similarity of the switch id and the port pair which are represented as a trace slice vector.)
It would have been obvious for one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Sigelman with Zhang to include identifying, for the plurality of request paths, a subset of the plurality of trace events based on the subset of the plurality of trace events being associated with a particular system node across multiple request paths included in the plurality of request paths, as taught by Zhang, in paragraphs [0002]-[0008], to provide a technique for network monitoring that includes providing network packet event characterization and analysis for network monitoring that comprises supporting summarization and characterization of network packet traces collected across multiple processing elements of different types in a network.
Combination of Sigelman and Zhang does not explicitly teach:
displaying, in a graphical user interface, a graphical representation of the particular system node; and displaying, in the graphical user interface, the span metric aggregate in conjunction with the display of the graphical representation of the particular system node.
However, Reynolds teaches:
displaying, in a graphical user interface, a graphical representation of the particular system node; and – on pages 5, 12-14 (Behavior Explorer - Interactive GUI displays: Casual Path Structure, Communication Structure, Valid/Invalid Paths, Resource Usage Graphs.)
displaying, in the graphical user interface, the span metric aggregate in conjunction with the display of the graphical representation of the particular system node. – on pages 5, 12-14 (Behavior Explorer - Interactive GUI displays: Casual Path Structure, Communication Structure, Valid/Invalid Paths, Resource Usage Graphs.)
It would have been obvious for one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Sigelman and Zhang with Reynolds to include displaying, in a graphical user interface, a graphical representation of the particular system node; and displaying, in the graphical user interface, the span metric aggregate in conjunction with the display of the graphical representation of the particular system node, as taught by Sigelman, on page 4, to allow application developers to enrich Dapper traces with additional information that may be useful to monitor higher level system behavior or to help in debugging problems.
Combination of Sigelman, Zhang, and Reynolds does not explicitly teach:
wherein each trace event is generated based on one or more interprocess communications.
However, Banks teaches:
wherein each trace event is generated based on one or more interprocess communications – in paragraphs (In response, a remote procedure call may be transmitted from the host 110 to the node 22 instructing the node 22 to transmit such a route trace message. In response, the core logic 80 of the node 22 creates a route trace message and wirelessly transmits such message via the communication device 77 of the node 22.)
It would have been obvious for one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Sigelman, Zhang, and Reynolds with Banks to include wherein each trace event is generated based on one or more interprocess communications, as taught by Banks, in paragraph [0123], to discover the status or health of the route.
Claims 22, 31. The method of claim 21 – refer to the indicated claim for the reference(s).
Sigelman teaches:
further comprising collecting the plurality of trace events from the plurality of system nodes. – on pages 4, 5, Figs. 1-5 (The Dapper trace logging and collection pipeline is a three-stage process (see Figure 5). First, span data is written (1) to local log files. It is then pulled (2) from all production hosts by Dapper daemons and collection infrastructure and finally written (3) to a cell in one of several regional Dapper Bigtable [8] repositories.)
Claims 23, 32. The method of claim 21 – refer to the indicated claim for the reference(s).
Sigelman teaches:
wherein the computation performed by the system node occurs on behalf of an interprocess communication call from a parent span in the corresponding request path, wherein the parent span corresponding to one of the system nodes in the corresponding request path. – on pages 1-4, Figs. 1-5 (Nearly all of Google’s inter-process communication is built around a single RPC framework with bindings in both C++ and Java. We have instrumented that framework to define spans around all RPCs. The span and trace ids are transmitted from client to server for traced RPCs. For example, Figure 1 shows a service with 5 servers: a front-end (A), two middle-tiers (B and C) and two backends (D and E). When a user request (the initiator in this case) arrives at the front end, it sends two RPCs to servers B and C. B can respond right away, but C requires work from backends D and E before it can reply to A, which in turn responds to the originating request. A simple yet useful distributed trace for this request would be a collection of message identifiers and timestamped events for every message sent and received at each server. Dapper records a human-readable span name for each span, as well as a span id and parent id in order to reconstruct the causal relationships between the individual spans in a single distributed trace. When a thread handles a traced control path, Dapper attaches a trace context to thread-local storage. A trace context is a small and easily copyable container of span attributes such as trace and span ids.)
Claims 24, 33, 40. The method of claim 21 – refer to the indicated claim for the reference(s).
Sigelman teaches:
wherein identifying the subset of the plurality of trace events associated with the particular system node and the parent system node is based on one or more trace identifiers, the one or more span identifiers, and one or more node identifiers in the subset of the plurality of trace events. – on pages 3-4 (We illustrate how spans form the structure of a larger trace in Figure 2. Dapper records a human-readable span name for each span, as well as a span id and parent id in order to reconstruct the causal relationships between the individual spans in a single distributed trace. Spans created without a parent id are known as root spans. All spans associated with a specific trace also share a common trace id.)
Claims 26, 35. The method of claim 25 – refer to the indicated claim for the reference(s).
Sigelman teaches:
wherein identifying the subset of the plurality of trace events associated with the particular system node and the parent system node is based on one or more trace identifiers, one or more span identifiers, the one or more parent span identifiers, and one or more node identifiers in the subset of the plurality of trace events. – on pages 3-4 (We illustrate how spans form the structure of a larger trace in Figure 2. Dapper records a human-readable span name for each span, as well as a span id and parent id in order to reconstruct the causal relationships between the individual spans in a single distributed trace. Spans created without a parent id are known as root spans. All spans associated with a specific trace also share a common trace id.)
Claims 27, 36. The method of claim 21 – refer to the indicated claim for the reference(s).
Reynolds further teaches:
wherein the graphical user interface comprises a visual call graph having a set of visual nodes and one or more visual edges connecting the set of visual nodes. – on pages 5, 12-14 (Behavior Explorer - Interactive GUI displays: Casual Path Structure, Communication Structure, Valid/Invalid Paths, Resource Usage Graphs.)
Claims 28, 37. The method of claim 21 – refer to the indicated claim for the reference(s).
Sigelman teaches:
wherein the span metric aggregate is displayed in response to detecting input directed to the graphical representation. – on pages 9-10 (The user describes the service and time window they’re interested in, as well as whatever information they need to distinguish trace patterns (in this case, the span name).)
Claims 29, 38. The method of claim 21 – refer to the indicated claim for the reference(s).
Reynolds further teaches:
wherein the span metric aggregate is displayed in response to detecting input directed to a graphical representation of a graph edge visually connecting the graphical representation of the particular system node with a graphical representation of another node of the plurality of system nodes. – on pages 5, 12-14 (Behavior Explorer - Interactive GUI displays: Casual Path Structure, Communication Structure, Valid/Invalid Paths, Resource Usage Graphs.)
Claim 41. The method of claim 21, – refer to the indicated claim for the reference(s).
Sigelman teaches:
wherein the subset of the plurality of trace events is identified based on one or more span identifiers and one or more parent span identifiers included in the subset of the plurality of trace events. – on pages 1-14 (In a Dapper trace tree, the tree nodes are basic units of work which we refer to as spans. The edges indicate a casual relationship between a span and its parent span. Dapper records a human-readable span name for each span, as well as a span id and parent id in order to reconstruct the causal relationships between the individual spans in a single distributed trace. Spans created without a parent id are known as root spans. All spans associated with a specific trace also share a common trace id. The instrumentation points described above are sufficient to derive detailed traces of complex distributed systems, making the core Dapper functionality available to otherwise unmodified Google applications.)
REMARKS
Applicant has presented amendments to the claims. The examiner maintains the rejections, see remarks below.
Argument 1: The Applicant argues that the art cited on the record does not teach identifying, for the plurality of request paths, a subset of the plurality of trace events based on the subset of the plurality of trace events being associated with a particular system node and a parent system node of the particular system node across multiple request paths included in the plurality of request paths, wherein the subset of the plurality of trace events is identified based on one or more span identifiers associated with the particular system node and one or more parent span identifiers associated with the parent system node in the subset of the plurality of trace events; computing a span metric aggregate from one or more span metrics in the subset of the plurality of trace events, as recited in the independent claims.
In response, the examiner respectfully submits:
Sigelman teaches wherein the subset of the plurality of trace events is identified based on one or more span identifiers associated with the particular system node and one or more parent span identifiers associated with the parent system node in the subset of the plurality of trace events; – on pages 2-4, Figs. 1-5 (Dapper records a human-readable span name for each span, as well as a span id and parent id in order to reconstruct the causal relationships between the individual spans in a single distributed trace. All spans associated with a specific trace also share a common trace id (not shown in the figure).)
Sigelman teaches computing a span metric aggregate from one or more span metrics in the subset of the plurality of trace events; – on pages 3-5, 13, Figs. 1-5 (Two classes of solutions have been proposed to aggregate this information so that one can associate all record entries with a given initiator (e.g., RequestX in Figure 1), black-box and annotation-based monitoring schemes. Black-box schemes [1, 15, 2] assume there is no additional information other than the message record described above, and use statistical regression techniques to infer that association. Figure 3 provides a more detailed view of the logged events in a typical Dapper trace span. Span data is written (1) to local log files. Annotation-based schemes [3, 12, 9, 16] rely on applications or middleware to explicitly tag every record with a global identifier that links these message records back to the originating request. Dapper uses a global identifier to tie together related events from various parts of a distributed system.)
Sigelman teaches wherein the plurality of trace events being associated with a particular system node and a parent system node of the particular system node – on pages 1-14 (In a Dapper trace tree, the tree nodes are basic units of work which we refer to as spans. The edges indicate a casual relationship between a span and its parent span. Dapper records a human-readable span name for each span, as well as a span id and parent id in order to reconstruct the causal relationships between the individual spans in a single distributed trace. Spans created without a parent id are known as root spans. All spans associated with a specific trace also share a common trace id. The instrumentation points described above are sufficient to derive detailed traces of complex distributed systems, making the core Dapper functionality available to otherwise unmodified Google applications.)
However, Zhang teaches identifying, for the plurality of request paths, a subset of the plurality of trace events based on the subset of the plurality of trace events being associated with a particular system node across multiple request paths included in the plurality of request paths, – in paragraphs [0042]-[0070] (The trace slice clustering 401 constructs the clusters of trace slices based on the similarity of the paths of packets. This path similarity is determined as the similarity of the switch id and the port pair which are represented as a trace slice vector.)
It would have been obvious for one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Sigelman with Zhang to include identifying, for the plurality of request paths, a subset of the plurality of trace events based on the subset of the plurality of trace events being associated with a particular system node across multiple request paths included in the plurality of request paths, as taught by Zhang, in paragraphs [0002]-[0008], to provide a technique for network monitoring that includes providing network packet event characterization and analysis for network monitoring that comprises supporting summarization and characterization of network packet traces collected across multiple processing elements of different types in a network.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MUHAMMAD RAZA whose telephone number is (571)272-7734. The examiner can normally be reached Monday-Friday, 7:00 A.M.-5:00 P.M..
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, Vivek Srivastava can be reached on (571)272-7304. 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.
/MUHAMMAD RAZA/Primary Examiner, Art Unit 2449
Prosecution Insights