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
This action is responsive to the application filed on May 19, 2025. Claims 1-20 were presented, and are pending examination.
Drawings
The drawings filed on May 19, 2025 are accepted.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1-19 are rejected on the ground of nonstatutory anticipatory type double patenting as being unpatentable over claims 1-16 of U.S. Patent No. 12335126, hereinafter, Patent No. 12335126. Although the claims at issue are not identical, they are not patentably distinct from each other. As shown in the following table, independent claims may be worded differently, however, the subject matters are essentially same.
Differences between the claims are indicated in italics, and subject matter which is worded differently, but recites the same or similar concepts are shown in bold. It should be noted that when differences are shown in italics, the instant claims have been recited in a broader manner, leaving out some details of the steps. Sometimes two of the instant claims together are the same subject matter of one of the patent claims, or the opposite is true. Finally, the underlining indicates that the limitation is found in the instant application and the patented application.
Instant Application No. 19/212,623
US Patent No. 12335126
Claim 1:
A method of application performance monitoring in a network, comprising:
executing a plurality of applications on a plurality of computing devices, wherein: the plurality of computing devices are located in a plurality of different geographical regions and connected via the network;
a plurality of collectors are distributed across the network; each respective collector of the plurality of collectors is positioned proximate a corresponding computing device of the plurality of computing devices; and each of the plurality of collectors has a local memory;
transmitting a plurality of trace events from the plurality of computing devices to the plurality of collectors via the network; sampling the plurality of trace events at the respective collectors;
identifying one or more sampled trace events of the plurality of trace events that meet a configurable attribute, wherein the configurable attribute includes at least one of (i) a success of a particular trace event of the plurality of trace events and (ii) a failure of the particular trace event; and storing the one or more sampled trace events that meet the configurable attribute in the local memory of the respective collectors.
Claim 1:
A method of application performance monitoring in one or more networks, comprising:
executing a plurality of respective applications on two or more computing devices located in at least two different geographical regions connected via the one or more networks;
distributing a plurality of collectors across the one or more networks, each collector being positioned proximate a respective computing device of the two or more computing devices;
sampling, by each of the plurality of collectors, a plurality of trace events received from the applications on the computing devices proximate the respective collector;
retaining in local memory sampled trace events that meet a configurable attribute comprising at least one of a latency threshold for completing a trace associated with one or more of the sampled trace events, or a success or failure of the trace, selectively transmitting by one of the collectors across the one or more networks a representation of the retained trace events to others of the plurality of collectors;
transmitting to an orchestration server across the one or more networks information comprising a trace event identified based on a local sampling decision, the orchestration server configured for indexing other information representing sampled trace events obtained from other collectors of the plurality of collectors that correspond with the trace event identified in the information; and publishing sampled trace identifiers (IDs) to the orchestration server to allow other collectors to enable indexing of events related to the trace.
Claim 2:
further comprising: transmitting information from the plurality of computing devices to an orchestration server, wherein: the information includes a particular trace event of the plurality of trace events that is identified based on a local sampling decision in the respective collectors; the orchestration server is operational to index other information representing other sampled trace events of the plurality of trace events obtained from other collectors of the plurality of collectors that correspond with the particular trace event identified in the information; and publishing sampled trace identifiers from the orchestration server to the other collectors.
Part of claim 1:
transmitting to an orchestration server across the one or more networks information comprising a trace event identified based on a local sampling decision, the orchestration server configured for indexing other information representing sampled trace events obtained from other collectors of the plurality of collectors that correspond with the trace event identified in the information; and publishing sampled trace identifiers (IDs) to the orchestration server to allow other collectors to enable indexing of events related to the trace.
Claim 3:
further comprising: transmitting a representation of the one or more sampled trace events stored in the local memory from one of the plurality of collectors to the other collectors.
Claim 2:
wherein: selectively transmitting the representation of the retained sampled trace events further comprises transmitting the representation via an orchestration server; and the orchestration server transmits the representation to the others using the one or more networks.
Claim 4:
wherein: the transmitting of the representation of the one or more sampled trace events further comprises transmitting the representation via the orchestration server; and the orchestration server transmits the representation to the other collectors.
Claim 2:
wherein: selectively transmitting the representation of the retained sampled trace events further comprises transmitting the representation via an orchestration server; and the orchestration server transmits the representation to the others using the one or more networks.
Claim 5:
wherein: the representation comprises a trace identifier.
Claim 5:
wherein the representation comprises a trace identifier (ID).
Claim 6:
further comprising: building a directed acyclic graph in at least one the plurality of collectors; and sampling a root trace event in the directed acyclic graph.
Claim 16:
wherein the at least some collectors of the plurality of collectors are configured to identify the root event by transforming sampled trace events into a directed acyclic graph (DAG) or a hierarchical tree.
Claim 7:
further comprising determining that the one or more sampled trace events includes a root trace event in at least one of the plurality of collectors.
Claim 5:
further comprising determining by the at least one of the collectors that the sampled trace event comprises a root trace event.
Claim 8:
wherein: the sampling by at least one of the plurality of collectors is tail-based sampling.
Claim 6:
wherein the sampling by at least one of the collectors comprises tail-based sampling.
Claim 9:
further comprising: determining at least one of (i) a root transaction duration and (ii) a root transaction outcome based on the tail-based sampling; and retaining a particular sampled trace event of the one or more sampled trace events based at least in part on the determining.
Claim 7:
further comprising: determining, using the tail-based sampling, at least one of a root transaction duration or a root transaction outcome; and retaining a sampled trace event based at least in part on the determining.
Claim 10:
further comprising: reservoir-sampling a root transaction by at least one of the plurality of collectors; and synchronizing prior sampling decisions by the at least one of the plurality of collectors to index any other trace events that are part of a sampled trace.
Claim 8:
further comprising: reservoir-sampling, by at least one of the collectors, a root transaction; and synchronizing prior sampling decisions by the at least one of the collectors to index any other trace events that are part of a sampled trace.
Claim 11:
A system for distributed data management comprising:
a plurality of computing devices operational to: execute a plurality of applications; and transmit a plurality of trace events on a network, wherein: the plurality of computing devices are located in a plurality of different geographical regions and connected via a network; and a
plurality of collectors operational to sample the plurality of trace events, wherein: the plurality of collectors are distributed across the network; each respective collector of the plurality of collectors is positioned proximate a corresponding computing device of the plurality of computing devices; each of the plurality of collectors has a local memory; and the respective collectors are further operational to: identify one or more sampled trace events of the plurality of trace events that meet a configurable attribute, wherein the configurable attribute includes at least one of (i) a success of a particular trace event of the plurality of trace events and (ii) a failure of the particular trace event; and store the one or more sampled trace events that meet the configurable attribute in the local memory of the respective collectors.
Claim 9:
A system for distributed data management, comprising:
a plurality of computing devices geographically distributed and communicatively coupled together via one or more networks, each computing device being configured to execute at least one application;
a plurality of geographically-distributed collectors, each collector being located proximate one or more of the computing devices and configured to: sample a plurality of trace events from the one or more of the computing devices; and retain in local memory sampled trace events that meet a configurable attribute comprising at least one of a latency threshold for completing a trace associated with one or more of the sampled trace events, or a success or failure of the trace, wherein at least some collectors of the plurality of collectors are configured to:
determine a root event of a trace, pass the root event through a reservoir sampler for making a local sampling decision, transmit to an orchestration server across the one or more networks information comprising a trace event identified based on the local sampling decision, the orchestration server being configured to index other information representing sampled trace events obtained from other collectors of the plurality of collectors that correspond with the trace event identified in the information, and publish sampled trace identifiers (IDs) to the orchestration server to allow other collectors to enable indexing of events related to the trace.
Claim 12:
further comprising: an orchestration server, wherein: at least one collector of the plurality of collectors is further operational to: generate a probabilistic set of a plurality of trace identifiers; and transmit the probabilistic set to the orchestration server.
Claim 10:
further comprising an orchestration server, wherein at least some collectors of the plurality of collectors are further configured to: generate a probabilistic set of trace identifiers (IDs); and transmit the probabilistic set to the orchestration server.
Claim 13:wherein: the probabilistic set comprises a Bloom Filter.
Claim 11:
wherein the probabilistic set comprises a Bloom Filter.
Claim 14:
wherein: at least one collector of the plurality of collectors is further operational to: perform a tail-based sampling of event data to determine a property of a completed trace; and store the completed trace in the local memory where the property meets a threshold.
Claim 12:
wherein at least some collectors of the plurality of collectors are further configured to: perform tail-based sampling of event data to determine a property of a completed trace; and locally store the trace or portion thereof when the property meets a threshold.
Claim 15:
wherein: the property is at least one of (i) a root transaction duration, (ii) a trace success trace outcome and (iii) a failed trace outcome.
Claim 13:
wherein the property comprises at least one of a root transaction duration or a trace success or failure outcome.
Claim 16:
wherein the at least one collector is further operational to: synchronize sampling decisions to index any other trace events that are part of sampled traces.
Claim 14:
wherein the at least some collectors are further configured to synchronize sampling decisions to index any other trace events that are part of sampled traces.
Claim 17:
wherein at least one collector of the plurality of collectors is further operational to: build a directed acyclic graph of the plurality of trace events; and determine a root event of the directed acyclic graph.
Claim 16:
wherein the at least some collectors of the plurality of collectors are configured to identify the root event by transforming sampled trace events into a directed acyclic graph (DAG) or a hierarchical tree.
Claim 18:
further comprising: an orchestration server on the network; and a reservoir sampler operational to make a local sampling decision, wherein: at least one collector of the plurality of collectors is further operational to: determine a root event of a trace; pass the root event through the reservoir sampler to make the local sampling decision; and transmit information to the orchestration server, wherein the information includes a trace event identified based on the local sampling decision; and the orchestration server is operational to: index other information representing the one or more sampled trace events obtained from other collectors of the plurality of collectors that correspond with the trace event identified in the information; and publish sampled trace identifiers to the other collectors.
Part of claim 11:
determine a root event of a trace, pass the root event through a reservoir sampler for making a local sampling decision, transmit to an orchestration server across the one or more networks information comprising a trace event identified based on the local sampling decision, the orchestration server being configured to index other information representing sampled trace events obtained from other collectors of the plurality of collectors that correspond with the trace event identified in the information, and publish sampled trace identifiers (IDs) to the orchestration server to allow other collectors to enable indexing of events related to the trace.
Claim 19:
wherein the at least one collector is further operational to: identify the root event by transforming the one or more sampled trace events into a hierarchical tree.
Claim 16:
wherein the at least some collectors of the plurality of collectors are configured to identify the root event by transforming sampled trace events into a directed acyclic graph (DAG) or a hierarchical tree.
Claim 20 is rejected on the ground of nonstatutory obviousness type double patenting as being unpatentable over claim 1 of U.S. Patent No. 12335126 in view of Goldberg et al. (US Patent No. US 10397343 B1), hereinafter, Goldberg, and further in view of Liu et al. (US Patent No. 11210156), hereinafter, Liu.
Instant Application No. 18/615,347
US Patent No. 12335126
Claim 20:
A system for application performance monitoring across one or more networks, comprising:
a plurality of computing devices geographically distributed across the one or more networks, each computing device including code for executing at least one application;
a plurality of collectors, each collector located proximate one of the computing devices and being configured to: sample a plurality of trace events received from a proximate one of the computing devices, the sampling based on a configurable policy;
buffer non-root sampled trace events for a configured duration; and
an orchestration server configured to: receive an indication of a sampling decision sent from a collector of the plurality of collectors when the collector samples a root trace event; and propagate the sampling decision to collectors to enable the collectors to retain in local memory buffered trace events related to the root trace event.
Claim 1
Patent No. 12335126 does not teach buffer non-root sampled trace events for a configured duration.
Goldberg teaches buffer non-root sampled trace events for a configured duration (Col. 10, lines 44-48 discloses retaining (buffer) all trace events/service interactions i.e., root trace events and non-root trace events as stated “In one embodiment, all or nearly all of the service interactions may be monitored to generate trace data, and that trace data may be stored locally by the hosts that implement the various services.”. Fig. 3 shows retaining trace events in trace storage 130A for corresponding expiration time (configured duration).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Patent No. 12335126 to incorporate the Goldberg of Arnold about retaining (buffer) all trace events/service interactions. One would be motivated to do that to improve the trace events in bandwidth-constraint environment (see Col. 1, lines 35-44, of Goldberg).
Patent No. 12335126 does not teach receive an indication of a sampling decision sent from at least one collector of the plurality of collectors in response to the at least one collector sampling a root trace event of the plurality of trace events; propagate the sampling decision to the plurality of collectors, wherein the plurality of collectors store buffered trace events related to the root trace event in the local memory.
Liu teaches:
receive an indication of a sampling decision sent from at least one collector of the plurality of collectors in response to the at least one collector sampling a root trace event of the plurality of trace events (Fig. 4 shows plurality of tracing agents 418 in plurality of services 410 and a tracing server 430. Col. 8, lines 58-63, discloses the tracing server 430 receives tracing data summary (representative indication) of sampled tracing data from each of the tracing agents as stated “When a transaction is finished, each of the tracing agents 418-1, 418-2, . . . , 418-N may send a tracing data summary corresponding to the transaction to the tracing server 430 where whether a received tracing data summary of a transaction matches at least one tracing rule 432 is determined”);
propagate the sampling decision to the plurality of collectors, wherein the plurality of collectors store buffered trace events related to the root trace event in the local memory (Col. 8, lines 67, and Col. 9, lines 1-7, discloses the tracing server 430 sends (propagate) instruction to the tracing agents based on tracing data summary to delete tracing data that do not match tracing rule, i.e. in other way to say, to retain tracing data that match the tracing rule as stated “For the tracing data summaries that do not match any tracing rules 432, the tracing server 430 may send instructions to the corresponding services, instructing their corresponding tracing agents to delete the corresponding tracing data. Before getting instructions from the tracing server 430, each of the services 410-1, 410-2, . . . , 410-N needs to store a copy of tracing data in the local environment”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Patent No. 12335126 to incorporate the teaching of Liu about receives tracing data summary and instructing tracing agents to retain tracing data that matches the tracing rule. One would be motivated to do that to track interaction of services in the service-chain related to the initial event (see Col. 2, lines 39-45 of Patent. No. 12335126).
Claims 1-19 are rejected on the ground of nonstatutory anticipatory type double patenting as being unpatentable over claims 1-18 of U.S. Patent No. 11962483, hereinafter, Patent No. 11962483. Although the claims at issue are not identical, they are not patentably distinct from each other. As shown in the following table, independent claims may be worded differently, however, the subject matters are essentially same.
Instant Application No. 19/212,623
US Patent No. 11962483
Claim 1:
A method of application performance monitoring in a network, comprising:
executing a plurality of applications on a plurality of computing devices, wherein: the plurality of computing devices are located in a plurality of different geographical regions and connected via the network; a plurality of collectors are distributed across the network; each respective collector of the plurality of collectors is positioned proximate a corresponding computing device of the plurality of computing devices; and each of the plurality of collectors has a local memory;
transmitting a plurality of trace events from the plurality of computing devices to the plurality of collectors via the network; sampling the plurality of trace events at the respective collectors; identifying one or more sampled trace events of the plurality of trace events that meet a configurable attribute, wherein the configurable attribute includes at least one of (i) a success of a particular trace event of the plurality of trace events and (ii) a failure of the particular trace event; and storing the one or more sampled trace events that meet the configurable attribute in the local memory of the respective collectors.
Claim 1:
A method of application performance monitoring in one or more networks, comprising:
executing a plurality of respective applications on two or more computing devices located in at least two different geographical regions connected via the one or more networks; distributing a plurality of collectors across the one or more networks, each collector being positioned proximate a respective computing device of the two or more computing devices;
sampling, by each of the plurality of collectors, a plurality of trace events received from the applications on the computing devices proximate the respective collector; retaining in local memory sampled trace events that meet a configurable attributes;
determining, by the plurality of collectors, a root event of a trace; passing the root event through a reservoir sampler for making a local sampling decision; transmitting to an orchestration server across the one or more networks information comprising a trace event identified based on the local sampling decision, the orchestration server configured for indexing other information representing sampled trace events obtained from other collectors of the plurality of collectors that correspond with the trace event identified in the information; and publishing sampled trace identifiers (IDs) to the orchestration server to allow other collectors to enable indexing of events related to the trace.
Claim 2:
wherein the configurable attribute comprises at least one of a latency threshold for completing a trace associated with one or more of the sampled trace events, or a success or failure of the trace.
Claim 2:
further comprising: transmitting information from the plurality of computing devices to an orchestration server, wherein:the information includes a particular trace event of the plurality of trace events that is identified based on a local sampling decision in the respective collectors; the orchestration server is operational to index other information representing other sampled trace events of the plurality of trace events obtained from other collectors of the plurality of collectors that correspond with the particular trace event identified in the information; and publishing sampled trace identifiers from the orchestration server to the other collectors.
Part of Claim 1:
determining, by the plurality of collectors, a root event of a trace; passing the root event through a reservoir sampler for making a local sampling decision; transmitting to an orchestration server across the one or more networks information comprising a trace event identified based on the local sampling decision, the orchestration server configured for indexing other information representing sampled trace events obtained from other collectors of the plurality of collectors that correspond with the trace event identified in the information; and publishing sampled trace identifiers (IDs) to the orchestration server to allow other collectors to enable indexing of events related to the trace..
Claim 3:
further comprising: transmitting a representation of the one or more sampled trace events stored in the local memory from one of the plurality of collectors to the other collectors.
Claim 3:
further comprising selectively transmitting by one of the collectors across the one or more networks a representation of the retained trace events to others of the plurality of collectors.
Claim 4:
wherein: the transmitting of the representation of the one or more sampled trace events further comprises transmitting the representation via the orchestration server; and the orchestration server transmits the representation to the other collectors.
Claim 4:
wherein: selectively transmitting the representation of the retained sampled trace events further comprises transmitting the representation via an orchestration server; and the orchestration server transmits the representation to the others using the one or more networks.
Claim 5:
wherein: the representation comprises a trace identifier.
Claim 5:
wherein the representation comprises a trace identifier (ID).
Claim 6:
further comprising: building a directed acyclic graph in at least one the plurality of collectors; and sampling a root trace event in the directed acyclic graph.
Claim 18:
wherein the at least some collectors of the plurality of collectors are configured to identify the root event by transforming sampled trace events into a directed acyclic graph (DAG) or a hierarchical tree.
Claim 7:
further comprising determining that the one or more sampled trace events includes a root trace event in at least one of the plurality of collectors.
Claim 7:
further comprising determining by the at least one of the collectors that the sampled trace event comprises a root trace event.
Claim 8:
wherein: the sampling by at least one of the plurality of collectors is tail-based sampling.
Claim 8:
wherein the sampling by at least one of the collectors comprises tail-based sampling.
Claim 9:
further comprising: determining at least one of (i) a root transaction duration and (ii) a root transaction outcome based on the tail-based sampling; and retaining a particular sampled trace event of the one or more sampled trace events based at least in part on the determining.
Claim 9:
further comprising: determining, using the tail-based sampling, at least one of a root transaction duration or a root transaction outcome; and retaining a sampled trace event based at least in part on the determining.
Claim 10:
further comprising: reservoir-sampling a root transaction by at least one of the plurality of collectors; and synchronizing prior sampling decisions by the at least one of the plurality of collectors to index any other trace events that are part of a sampled trace.
Claim 10:
further comprising: reservoir-sampling, by at least one of the collectors, a root transaction; and synchronizing prior sampling decisions by the at least one of the collectors to index any other trace events that are part of a sampled trace.
Claim 11:
A system for distributed data management comprising:
a plurality of computing devices operational to:
execute a plurality of applications; and transmit a plurality of trace events on a network, wherein: the plurality of computing devices are located in a plurality of different geographical regions and connected via a network; and a plurality of collectors operational to sample the plurality of trace events, wherein: the plurality of collectors are distributed across the network; each respective collector of the plurality of collectors is positioned proximate a corresponding computing device of the plurality of computing devices; each of the plurality of collectors has a local memory; and
the respective collectors are further operational to: identify one or more sampled trace events of the plurality of trace events that meet a configurable attribute, wherein the configurable attribute includes at least one of (i) a success of a particular trace event of the plurality of trace events and (ii) a failure of the particular trace event; and store the one or more sampled trace events that meet the configurable attribute in the local memory of the respective collectors.
Claim 11:
A system for distributed data management, comprising:
a plurality of computing devices geographically distributed and communicatively coupled together via one or more networks, each computing device being configured to execute at least one application; a plurality of geographically-distributed collectors, each collector being located proximate one or more of the computing devices and configured to: sample a plurality of trace events from the one or more of the computing devices; and
retain in local memory sampled trace events that meet a configurable attribute, wherein at least some collectors of the plurality of collectors are further configured to: determine a root event of a trace;
pass the root event through a reservoir sampler for making a local sampling decision; transmit to an orchestration server across the one or more networks information comprising a trace event identified based on the local sampling decision, the orchestration server configured to index other information representing sampled trace events obtained from other collectors of the plurality of collectors that correspond with the trace event identified in the information; and publish sampled trace identifiers (IDs) to the orchestration server to allow other collectors to enable indexing of events related to the trace.
Claim 2:
wherein the configurable attribute comprises at least one of a latency threshold for completing a trace associated with one or more of the sampled trace events, or a success or failure of the trace.
Claim 12:
further comprising: an orchestration server, wherein: at least one collector of the plurality of collectors is further operational to: generate a probabilistic set of a plurality of trace identifiers; and transmit the probabilistic set to the orchestration server.
Claim 12:
further comprising an orchestration server, wherein at least some collectors of the plurality of collectors are further configured to: generate a probabilistic set of trace identifiers (IDs); and transmit the probabilistic set to the orchestration server.
Claim 13:wherein: the probabilistic set comprises a Bloom Filter.
Claim 13:
wherein the probabilistic set comprises a Bloom Filter.
Claim 14:
wherein: at least one collector of the plurality of collectors is further operational to: perform a tail-based sampling of event data to determine a property of a completed trace; and store the completed trace in the local memory where the property meets a threshold.
Claim 14:
wherein at least some collectors of the plurality of collectors are further configured to: perform tail-based sampling of event data to determine a property of a completed trace; and locally store the trace or portion thereof when the property meets a threshold.
Claim 15:
wherein: the property is at least one of (i) a root transaction duration, (ii) a trace success trace outcome and (iii) a failed trace outcome.
Claim 15:
wherein the property comprises at least one of a root transaction duration or a trace success or failure outcome.
Claim 16:
wherein the at least one collector is further operational to: synchronize sampling decisions to index any other trace events that are part of sampled traces.
Claim 16:
wherein the at least some collectors are further configured to synchronize sampling decisions to index any other trace events that are part of sampled traces.
Claim 17:
wherein at least one collector of the plurality of collectors is further operational to: build a directed acyclic graph of the plurality of trace events; and determine a root event of the directed acyclic graph.
Claim 18:
wherein the at least some collectors of the plurality of collectors are configured to identify the root event by transforming sampled trace events into a directed acyclic graph (DAG) or a hierarchical tree.
Claim 18:
further comprising: an orchestration server on the network; and a reservoir sampler operational to make a local sampling decision, wherein: at least one collector of the plurality of collectors is further operational to: determine a root event of a trace; pass the root event through the reservoir sampler to make the local sampling decision; and transmit information to the orchestration server, wherein the information includes a trace event identified based on the local sampling decision; and the orchestration server is operational to: index other information representing the one or more sampled trace events obtained from other collectors of the plurality of collectors that correspond with the trace event identified in the information; and publish sampled trace identifiers to the other collectors.
Part of claim 11:
pass the root event through a reservoir sampler for making a local sampling decision; transmit to an orchestration server across the one or more networks information comprising a trace event identified based on the local sampling decision, the orchestration server configured to index other information representing sampled trace events obtained from other collectors of the plurality of collectors that correspond with the trace event identified in the information; and publish sampled trace identifiers (IDs) to the orchestration server to allow other collectors to enable indexing of events related to the trace.
Claim 19:
wherein the at least one collector is further operational to: identify the root event by transforming the one or more sampled trace events into a hierarchical tree.
Claim 18:
wherein the at least some collectors of the plurality of collectors are configured to identify the root event by transforming sampled trace events into a directed acyclic graph (DAG) or a hierarchical tree.
Claim 20 is rejected on the ground of nonstatutory obviousness type double patenting as being unpatentable over claim 1 of US Patent No. 11962483 in view of Goldberg et al. (US Patent No. US 10397343 B1), hereinafter, Goldberg, and further in view of Liu et al. (US Patent No. 11210156), hereinafter, Liu.
Instant Application No. 19/212,623
US Patent No. 11962483
Claim 20:
A system for application performance monitoring across a network comprising:
a plurality of computing devices geographically distributed across the network, and each operational to execute an application;
a plurality of collectors, each located proximate a corresponding one of the computing devices, each having a local memory, and each operational to: sample a plurality of trace events received from the corresponding computing device, wherein the sampling is based on a configurable policy; and
buffer non-root sampled trace events for a configured duration; and
an orchestration server operational to: receive an indication of a sampling decision sent from at least one collector of the plurality of collectors in response to the at least one collector sampling a root trace event of the plurality of trace events; and
propagate the sampling decision to the plurality of collectors, wherein the plurality of collectors store buffered trace events related to the root trace event in the local memory.
Claim 1
Patent No. 11962483 does not teach buffer non-root sampled trace events for a configured duration.
Goldberg teaches buffer non-root sampled trace events for a configured duration (Col. 10, lines 44-48 discloses retaining (buffer) all trace events/service interactions i.e., root trace events and non-root trace events as stated “In one embodiment, all or nearly all of the service interactions may be monitored to generate trace data, and that trace data may be stored locally by the hosts that implement the various services.”. Fig. 3 shows retaining trace events in trace storage 130A for corresponding expiration time (configured duration).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Patent No. 11962483 to incorporate the Goldberg of Arnold about retaining (buffer) all trace events/service interactions. One would be motivated to do that to improve the trace events in bandwidth-constraint environment (see Col. 1, lines 35-44, of Goldberg).
Patent No. 11962483 does not teach receive an indication of a sampling decision sent from at least one collector of the plurality of collectors in response to the at least one collector sampling a root trace event of the plurality of trace events; propagate the sampling decision to the plurality of collectors, wherein the plurality of collectors store buffered trace events related to the root trace event in the local memory.
Liu teaches:
receive an indication of a sampling decision sent from at least one collector of the plurality of collectors in response to the at least one collector sampling a root trace event of the plurality of trace events (Fig. 4 shows plurality of tracing agents 418 in plurality of services 410 and a tracing server 430. Col. 8, lines 58-63, discloses the tracing server 430 receives tracing data summary (representative indication) of sampled tracing data from each of the tracing agents as stated “When a transaction is finished, each of the tracing agents 418-1, 418-2, . . . , 418-N may send a tracing data summary corresponding to the transaction to the tracing server 430 where whether a received tracing data summary of a transaction matches at least one tracing rule 432 is determined”);
propagate the sampling decision to the plurality of collectors, wherein the plurality of collectors store buffered trace events related to the root trace event in the local memory (Col. 8, lines 67, and Col. 9, lines 1-7, discloses the tracing server 430 sends (propagate) instruction to the tracing agents based on tracing data summary to delete tracing data that do not match tracing rule, i.e. in other way to say, to retain tracing data that match the tracing rule as stated “For the tracing data summaries that do not match any tracing rules 432, the tracing server 430 may send instructions to the corresponding services, instructing their corresponding tracing agents to delete the corresponding tracing data. Before getting instructions from the tracing server 430, each of the services 410-1, 410-2, . . . , 410-N needs to store a copy of tracing data in the local environment”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Patent No. 11962483 to incorporate the teaching of Liu about receives tracing data summary and instructing tracing agents to retain tracing data that matches the tracing rule. One would be motivated to do that to track interaction of services in the service-chain related to the initial event (see Col. 2, lines 39-45 of Patent. No. 11962483).
Examiner’s Note about the Format of 35 U.S.C. 102/103 Rejections
Generally, limitations of a claim are reproduced identically and followed by examiner’s explanation with citation from prior art in Italic enclosed by a parenthesis, (), for each limitation. In examiner’s explanation, the mapping of the key elements of a limitation to the disclosed elements of prior art is shown by stating the disclosed element immediately followed by the claimed element inside a parenthesis. Specific quotation from prior art is delineated with quotation mark, ““. If primary art fails to teach a limitation or part of the limitation, the limitation or the part of the limitation is placed inside double square brackets, [[ ]], for better understandability, and appropriate secondary art(s) is/are applied later addressing the deficiency of the primary art.
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.
Claims 1, 6-9, 11, 12, 14, 15, and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Goldberg et al. (US Patent No. US 10397343 B1), hereinafter, Goldberg, in view of Arnold et al. (US PGPUB No. US 20210399953 A1), hereinafter, Arnold.
Regarding claim 1:
Goldberg teaches:
A method of application performance monitoring in a network, comprising (Fig. 1 shows distributed service monitoring in a network 190 (one or more networks)):
executing a plurality of applications on a plurality of computing devices, wherein: the plurality of computing devices are located in a plurality of different geographical regions and connected via the network (Fig. 4 shows services 110A-110N (plurality of applications) executing on plurality of hosts (two or more computing devices) located in different geographical locations (plurality of different geographical regions) as stated in Col. 3, lines 15-20 “The services 110A-110N may be implemented using a plurality of hosts, any of which may be implemented by the example computing device 3000 illustrated in FIG. 16. The hosts may be located in any suitable number of data centers or geographical locations”. Col. 3, lines 13-15, discloses service as a set of program code as stated “Any of the services 110A-110N may represent different services (e.g., different sets of program code) or different instances of the same service”. Therefore, a service equates to an application);
a plurality of collectors are distributed across the network; each respective collector of the plurality of collectors is positioned proximate a corresponding computing device of the plurality of computing devices (Fig. 1 shows plurality of interaction monitoring functionalities 120A-120N (plurality of collectors) are distributed across the network 190 wherein each interaction monitoring functionality is positioned proximate to respective host (corresponding computing device) as stated in Col. 4, lines 11-19 “For example, service 110A may include an interaction monitoring functionality 120A, service 110B may include an interaction monitoring functionality 120B, and service 110N may include an interaction monitoring functionality 120N. The interaction monitoring functionality 120A, 120B, or 120N may monitor or track interactions between the corresponding service 110A, 110B, or 110N and other services (or components of services) in the service-oriented system 100.”); and
each of the plurality of collectors has a local memory (Fig. 1 shows each interaction monitoring functionality 120 has its own trace storage 130 (local memory));
transmitting a plurality of trace events from the plurality of computing devices to the plurality of collectors via the network; sampling the plurality of trace events at the respective collectors (Fig. 3 shows plurality of trace events 132A-132N (plurality of trace events) received from the service 110A as stated in Col. 9, lines 20-26, “Each element of log data may relate to a particular trace event and thus to a particular interaction (e.g., a service request or service response) with another service. For example, as shown in FIG. 3, log data 332A may relate to trace event 132A, log data 332B may relate to trace event 132B, and log data 332N may relate to trace event 132N”. Col. 10, lines 43-48 discloses sampling trace event/data as stated “FIG. 6 illustrates sampling of real-time trace data in a service-oriented system, according to some embodiments. In one embodiment, all or nearly all of the service interactions may be monitored to generate trace data, and that trace data may be stored locally by the hosts that implement the various services.”. );
identifying one or more sampled trace events of the plurality of trace events that meet a configurable attribute, [[wherein the configurable attribute includes at least one of (i) a success of a particular trace event of the plurality of trace events and (ii) a failure of the particular trace event]]; and
storing the one or more sampled trace events that meet the configurable attribute in the local memory of the respective collectors (Col. 9, lines 1-7, discloses identifying trace events that are high priority (configurable attribute) and storing the high-priority trace events in the trace storage 130A as stated “In one embodiment, the expiration times 133A-133N may represent times at which the corresponding trace events were stored or other indicators of storage priority, such that the oldest or lowest-priority trace events may be retained in the trace storage 130A only until space is needed to store newer or higher-priority trace events”).
Goldberg does not teach wherein the configurable attribute includes at least one of (i) a success of a particular trace event of the plurality of trace events and (ii) a failure of the particular trace event.
Arnold teaches wherein the configurable attribute includes at least one of (i) a success of a particular trace event of the plurality of trace events and (ii) a failure of the particular trace event (paragraph 0016 discloses identifying traces with trace error (failure of the particular trace event) and thereby giving more priority to those traces as stated “The trace criteria define rules for when a trace and associated span data is deemed interesting and thus worthy of sampling. Some examples of trace criteria may include a random trace selection, trace duration threshold, occurrence of trace error, and trace priority level threshold. The use of random trace selection includes determining the selected and unselected subsets of traces randomly. The use of trace duration threshold includes using a time threshold where traces having trace duration, as may be defined by execution time, that exceed the time threshold are selected for sampling. The use of occurrence of trace error includes detecting a trace error of interest in the traces. Traces with errors or error types of interest may be given higher priority for sampling. The use of trace priority level threshold includes comparing a priority level of a trace defining the importance of the trace with a threshold value, where important traces that exceed the trace priority level threshold are selected for sampling”. Paragraph 0042, lines 1-2, discloses discarding unselected span/trace i.e. retaining selected span/trace with error as stated “The trace manager discards 430 unselected span data of the unselected subset of traces”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Goldberg to incorporate the teaching of Arnold about retaining traces/events with trace error. One would be motivated to do that to keep only the traces/spans data that are deemed to be interesting to save local storage capacity and to save bandwidth in trace data transmission (see at least paragraphs 0016 and 0042, lines 2-6, of Arnold).
As to claim 6, the rejection of claim 1 is incorporated. Goldberg in view of Arnold teach all the limitations of claim 1 as shown above.
Goldberg further teaches further comprising: building a directed acyclic graph in at least one the plurality of collectors; and sampling a root trace event in the directed acyclic graph (Fig. 14 shows a directed graph include root request. See Col. 21, lines 39-67, and Col. 22, lines 1-3 for generation of the directed graph).
As to claim 7, the rejection of claim 1 is incorporated. Goldberg in view of Arnold teach all the limitations of claim 1 as shown above.
Goldberg further teaches further comprising determining that the one or more sampled trace events includes a root trace event in at least one of the plurality of collectors (Col. 12, 43-49, as discloses identifying downstream trace event linked to the initial event (root event) using trace identifier as stated “The initial trace event may include a trace identifier (e.g., a request identifier) as well as call path data. As shown in 910, the next downstream host in the trace may be identified using the call path data in the initial trace event. As shown in 915, the next trace event and related log data may be retrieved from the next downstream host, e.g., by specifying the trace identifier to the next downstream host”).
As to claim 8, the rejection of claim 1 is incorporated. Goldberg in view of Arnold teach all the limitations of claim 1 as shown above.
Goldberg does not teach wherein: the sampling by at least one of the plurality of collectors is tail-based sampling.
Arnold teaches wherein: the sampling by at least one of the plurality of collectors is tail-based sampling (paragraph 0041, lines 5-7, discloses tail-based sampling).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Goldberg to incorporate the teaching of Arnold about tail-based sampling. One would be motivated to do use tail-based sampling because tail-based sampling approach allows for trace metrics to be generated from the complete collection of span data and every trace even though only a subset of the traces is kept for sampling purpose that saves local storage capacity and bandwidth in trace data transmission (see at least paragraphs 0017 and 0042, lines 2-6, of Arnold).
As to claim 9, the rejection of claim 8 is incorporated. Goldberg in view of Arnold teach all the limitations of claim 8 as shown above.
Goldberg does not teach further comprising: determining at least one of (i) a root transaction duration and (ii) a root transaction outcome based on the tail-based sampling; and retaining a particular sampled trace event of the one or more sampled trace events based at least in part on the determining.
Arnold teaches further comprising: determining at least one of (i) a root transaction duration and (ii) a root transaction outcome based on the tail-based sampling; and retaining a particular sampled trace event of the one or more sampled trace events based at least in part on the determining (paragraph 0041, lines 5-15, discloses selecting span/trace by comparing trace characteristics, for example trace duration, with trace duration threshold using tail-based sampling. Paragraph 0042, 1-2, discloses discarding unselected span/trace i.e., retaining selected span/trace that meets the trace duration threshold), and;
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Goldberg to incorporate the teaching of Arnold about retaining trace that meets the trace duration threshold using tail-based sampling. Such modification would allow Goldberg to use tail-based sampling based on the trace duration of the root request. One would be motivated to use tail-based sampling to keep only the trace/span data that is deemed to be interesting to save local storage capacity and to save bandwidth in trace data transmission (see at least paragraphs 0016, 0017, and 0042 of Arnold).
Regarding claim 11:
Goldberg teaches:
A system for distributed data management comprising (Fig. 1 shows a system for distributed service monitoring):
a plurality of computing devices operational to: execute a plurality of applications; and transmit a plurality of trace events on a network, wherein: the plurality of computing devices are located in a plurality of different geographical regions and connected via a network (Fig. 4 shows plurality of hosts (plurality of computing devices) distributed in different geographic locations wherein each host executes one service (application) of plurality of services 110A-110N (plurality of applications) as stated in Col. 3, lines 15-20 “The services 110A-110N may be implemented using a plurality of hosts, any of which may be implemented by the example computing device 3000 illustrated in FIG. 16. The hosts may be located in any suitable number of data centers or geographical locations”. Fig. 1 shows host computers communicate via network 190 (one or more network). Col. 3, lines 13-15, discloses service as a set of program code as stated “Any of the services 110A-110N may represent different services (e.g., different sets of program code) or different instances of the same service”. Therefore, a service equates to an application.); and
a plurality of collectors operational to sample the plurality of trace events, wherein: the plurality of collectors are distributed across the network; each respective collector of the plurality of collectors is positioned proximate a corresponding computing device of the plurality of computing devices (Fig. 1 shows plurality of interaction monitoring functionalities 120A-120N (plurality of collectors) are distributed across the network 190 wherein each interaction monitoring functionality is positioned proximate to the respective host as stated in Col. 4, lines 11-19 “For example, service 110A may include an interaction monitoring functionality 120A, service 110B may include an interaction monitoring functionality 120B, and service 110N may include an interaction monitoring functionality 120N. The interaction monitoring functionality 120A, 120B, or 120N may monitor or track interactions between the corresponding service 110A, 110B, or 110N and other services (or components of services) in the service-oriented system 100.”. Fig. 3 shows plurality of trace events 132A-132N (plurality of trace events) as stated in Col. 9, lines 20-26, “Each element of log data may relate to a particular trace event and thus to a particular interaction (e.g., a service request or service response) with another service. For example, as shown in FIG. 3, log data 332A may relate to trace event 132A, log data 332B may relate to trace event 132B, and log data 332N may relate to trace event 132N”. Col. 10, lines 43-48 discloses sampling trace event/data as stated “FIG. 6 illustrates sampling of real-time trace data in a service-oriented system, according to some embodiments. In one embodiment, all or nearly all of the service interactions may be monitored to generate trace data, and that trace data may be stored locally by the hosts that implement the various services.”. );
each of the plurality of collectors has a local memory (Fig. 1 shows each interaction monitoring functionality 120 has its own trace storage 130 (local memory)); and
the respective collectors are further operational to: identify one or more sampled trace events of the plurality of trace events that meet a configurable attribute, [[wherein the configurable attribute includes at least one of (i) a success of a particular trace event of the plurality of trace events and (ii) a failure of the particular trace event]]; and store the one or more sampled trace events that meet the configurable attribute in the local memory of the respective collectors (Col. 9, lines 1-7, discloses identifying trace events that are high priority (configurable attribute) and storing the high-priority trace events in the trace storage 130A as stated “In one embodiment, the expiration times 133A-133N may represent times at which the corresponding trace events were stored or other indicators of storage priority, such that the oldest or lowest-priority trace events may be retained in the trace storage 130A only until space is needed to store newer or higher-priority trace events”).
Goldberg does not teach wherein the configurable attribute includes at least one of (i) a success of a particular trace event of the plurality of trace events and (ii) a failure of the particular trace event.
Arnold teaches wherein the configurable attribute includes at least one of (i) a success of a particular trace event of the plurality of trace events and (ii) a failure of the particular trace event (paragraph 0016 discloses identifying traces with trace error (failure of the particular trace event) and thereby giving more priority to those traces as stated “The trace criteria define rules for when a trace and associated span data is deemed interesting and thus worthy of sampling. Some examples of trace criteria may include a random trace selection, trace duration threshold, occurrence of trace error, and trace priority level threshold. The use of random trace selection includes determining the selected and unselected subsets of traces randomly. The use of trace duration threshold includes using a time threshold where traces having trace duration, as may be defined by execution time, that exceed the time threshold are selected for sampling. The use of occurrence of trace error includes detecting a trace error of interest in the traces. Traces with errors or error types of interest may be given higher priority for sampling. The use of trace priority level threshold includes comparing a priority level of a trace defining the importance of the trace with a threshold value, where important traces that exceed the trace priority level threshold are selected for sampling”. Paragraph 0042, lines 1-2, discloses discarding unselected span/trace i.e. retaining selected span/trace with error as stated “The trace manager discards 430 unselected span data of the unselected subset of traces”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Goldberg to incorporate the teaching of Arnold about retaining traces/events that meet the trace duration threshold. One would be motivated to do that to keep only the traces/spans data that are deemed to be interesting to save local storage capacity and to save bandwidth in trace data transmission (see at least paragraphs 0016 and 0042, lines 2-6, of Arnold).
As to claim 12, the rejection of claim 11 is incorporated. Goldberg in view of Arnold teach all the limitations of claim 11 as shown above.
Goldberg further teaches further comprising:
an orchestration server, wherein: at least one collector of the plurality of collectors is further operational to: generate a probabilistic set of a plurality of trace identifiers (Fig. 1 shows trace analysis system 160 (orchestration server). Col. 10, lines 48-55, discloses generating a probabilistic sampled subset (probabilistic set) of service interaction as stated “In one embodiment, a sampled subset of the trace data may be provided to the trace analysis system 160 without the trace analysis system requesting the trace data. Any suitable technique may be used to identify which of the service interactions are provided to the trace analysis system 160. For example, probabilistic sampling techniques may be used to obtain the results of interaction monitoring for a certain percentage (e.g., 1%) of all service interactions”. Figs. 10 and 11 show each service interaction has an interaction identifier. Therefore, a probabilistic sampled subset of service interactions includes a set of interaction identifiers); and
transmit the probabilistic set to the orchestration server (Col. 10, lines 56-59, discloses transmitting the probabilistic sampled subset to the trace analysis system 160 as stated “Accordingly, each of the services 110A, 110B, or 110N may include a trace sampling functionality 650A, 650B, or 650N configured to sample a subset of service interactions and supply the sampled subset to the trace analysis system 160”).
As to claim 14, the rejection of claim 11 is incorporated. Goldberg in view of Arnold teach all the limitations of claim 11 as shown above.
Goldberg does not teach wherein: at least one collector of the plurality of collectors is further operational to: perform a tail-based sampling of event data to determine a property of a completed trace; and store the completed trace in the local memory where the property meets a threshold.
Arnold teaches wherein: at least one collector of the plurality of collectors is further operational to: perform a tail-based sampling of event data to determine a property of a completed trace; and store the completed trace in the local memory where the property meets a threshold (paragraph 0041, lines 5-15, discloses tail -based sampling by comparing trace characteristics, for example trace duration, with trace duration threshold (threshold) as stated “The trace manager performs a tail-based sampling of the span data by the trace characteristics for complete traces of the span data. In some embodiments, the one or more trace characteristics include a trace duration and the one or more trace criteria include a trace duration threshold. In some embodiments, the one or more trace characteristics include trace error and the one or more trace criteria include an occurrence of trace error. In some embodiments, the one or more trace characteristics include a trace priority level and the one or more trace criteria include a trace priority level threshold”. Paragraph 0042, lines 1-2, discloses discarding unselected span/trace i.e. retaining selected span/trace that meets the trace duration threshold as stated “The trace manager discards 430 unselected span data of the unselected subset of traces”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Goldberg to incorporate the teaching of Arnold about retaining trace that meets the trace duration threshold using tail-based sampling. One would be motivated to use tail-based sampling to keep only the trace/span data that is deemed to be interesting to save local storage capacity and to save bandwidth in trace data transmission (see at least paragraphs 0016, 0017, and 0042 of Arnold).
As to claim 15, the rejection of claim 14 is incorporated. Goldberg in view of Arnold teach all the limitations of claim 14 as shown above.
Goldberg further teaches wherein: the property is at least one of (i) a root transaction duration, (ii) a trace success trace outcome and (iii) a failed trace outcome (Col. 6, lines 65-67, and Col. 7, lines 1-5, discloses root request (root transaction) as stated “To process a given received request, one or more services may be invoked. As used herein, an initial request may be referred to as the “root request.” In various embodiments, the root request may but need not originate from a computer system outside of the service-oriented system 100. In many embodiments, a root request may be processed by an initial service, which may then call one or more other services.”. Col. 5, lines 4-10, discloses trace data includes performance of service interactions including latency. Therefore, trace data of the root request includes latency of root request (root transaction duration)).
Claim 17 recites limitations similar to claim 6. Accordingly, it is rejected under similar rationale.
Claims 10 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Goldberg in view of Arnold, and further in view of Alaranta et al. (US PGPUB No. 20180150384), hereinafter, Alaranta.
As to claim 10, the rejection of claim 1 is incorporated. Goldberg in view of Arnold teach all the limitations of claim 1 as shown above.
Goldberg does not teach further comprising: reservoir-sampling a root transaction by at least one of the plurality of collectors; and synchronizing prior sampling decisions by the at least one of the plurality of collectors to index any other trace events that are part of a sampled trace.
Alaranta teaches further comprising:
reservoir-sampling a root transaction by at least one of the plurality of collectors (Fig. 3 shows sampling services 303a-303N for sampling trace data of plurality of respective user services 130a-130N in a service-chain. Paragraph 0069, lines 12-15, discloses sampling service applies reservoir sampling as stated “In box 813, the sampling service 303 applies reservoir sampling based at least in part on the sampling parameter(s) 412 to collect a fixed number of code traces 403 for a time period”); and
synchronizing prior sampling decisions by the at least one of the plurality of collectors to index any other trace events that are part of a sampled trace (paragraph 0073, lines 1-7, discloses adjusting sampling parameters (synchronizing prior sampling decisions) as stated “In box 839, the sampling service 303 dynamically adjusts one or more sampling parameters 412 to modify the sampling in response to the directive. In one use case, the sampling service 303 may dynamically increase traces forwarded (as a proportion) when fewer traces are received, or may dynamically decrease traces forwarded (as a proportion) when more traces are received”. Paragraph 0033 discusses trace indexing).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Goldberg to incorporate the teaching of Alaranta about reservoir sampling and dynamically adjusting sampling parameters. Such modification would enable Goldberg to apply reservoir sampling in the root transaction and adjusting sampling parameters. One would be motivated to do that since distributed service may contain millions of requests/transactions and reservoir sampling enable sampling a fraction of the large number of related traces (see at least Col. 15, lines 59-67, and Col.16, lines 1-3 of Goldberg and paragraphs 0034 and 73 of Alaranta).
As to claim 16, the rejection of claim 14 is incorporated. Goldberg teaches all the limitations of claim 14 as shown above.
Goldberg does not teach wherein the at least one collector is further operational to: synchronize sampling decisions to index any other trace events that are part of sampled traces.
Alaranta teaches wherein the at least one collector is further operational to: synchronize sampling decisions to index any other trace events that are part of sampled traces (paragraph 0073, lines 1-7, discloses adjusting sampling (synchronizing prior sampling decisions). Paragraph 0033 discusses trace indexing).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Goldberg to incorporate the teaching of Alaranta dynamically adjusting sampling parameters. One would be motivated to do to sample traces efficiently (see paragraph 0073 of Alaranta).
Claims 13 is rejected under 35 U.S.C. 103 as being unpatentable over Goldberg in view of Arnold, and further view of Decker et al. (US Patent No. 10554701), hereinafter, Decker.
As to claim 13, the rejection of claim 12 is incorporated Goldberg in view of Arnold teach all the limitations of claim 12 as shown above.
Goldberg does not teach wherein: the probabilistic set comprises a Bloom Filter.
Decker teaches wherein the probabilistic set comprises a Bloom Filter (Col. 10, lines 8-13, discloses determining a probabilistic set as bloom filter as stated “In one embodiment, the data structure(s) may include one or more Bloom filters. A Bloom filter may represent a probabilistic data structure that may be employed to test whether an element, such as a trace signature, is a member of a set, such as a particular tier or category of upstream call path”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Goldberg to incorporate the teaching of Decker about a bloom filter. Such incorporation would enable Goldberg to determine the probabilistic sample subset of service interaction as bloom filter. One would be motivated to use bloom filter to identify the traces of interest/priority (Col. 10, lines 19-29, of Decker as stated “In one embodiment, however, a Bloom filter may be used to determine which requests can be dropped with a high degree of certainty. In one embodiment, one or more Bloom filters may be used to determine the tiers or categories (if any) to which a request belongs. The different tiers or categories may represent different priorities for requests. For example, if the trace signature of a request indicates that the upstream call path began with a bot and not with a registered user, then the trace signature may be determined to belong to a lower priority tier, and a service may decide to discard the request.”).
Claim 20 is rejected under 35 U.S.C. 103 as being unpatentable over Goldberg in view of Liu et al. (US Patent No. 11210156), hereinafter, Liu.
Regarding claim 20:
Goldberg teaches:
A system for application performance monitoring across a network comprising (Fig. 1 shows a system for distributed service monitoring across network 190 (one or more network)):
a plurality of computing devices geographically distributed across the network, and each operational to execute an application (Fig. 4 shows plurality of hosts (plurality of computing devices) distributed in different geographic locations across the network 190 wherein each host executes one service (application) of plurality of services 110A-110N as stated in Col. 3, lines 15-20 “The services 110A-110N may be implemented using a plurality of hosts, any of which may be implemented by the example computing device 3000 illustrated in FIG. 16. The hosts may be located in any suitable number of data centers or geographical locations”. Col. 3, lines 13-15, discloses service as a set of program code as stated “Any of the services 110A-110N may represent different services (e.g., different sets of program code) or different instances of the same service”. Therefore, a service equates to an application);
a plurality of collectors, each located proximate a corresponding one of the computing devices, each having a local memory, and each operational to (Fig. 1 shows plurality of interaction monitoring functionalities 120A-120N (plurality of collectors) wherein each interaction monitoring functionality is positioned proximate to respective host as stated in Col. 4, lines 11-19 “For example, service 110A may include an interaction monitoring functionality 120A, service 110B may include an interaction monitoring functionality 120B, and service 110N may include an interaction monitoring functionality 120N. The interaction monitoring functionality 120A, 120B, or 120N may monitor or track interactions between the corresponding service 110A, 110B, or 110N and other services (or components of services) in the service-oriented system 100.”. Fig. 1 shows each interaction monitoring functionality 120 has its own trace storage 130 (local memory)):
sample a plurality of trace events received from the corresponding computing device, wherein the sampling is based on a configurable policy (Fig. 3 shows plurality of trace events 132A-132N (plurality of trace events) as stated in Col. 9, lines 20-26, “Each element of log data may relate to a particular trace event and thus to a particular interaction (e.g., a service request or service response) with another service. For example, as shown in FIG. 3, log data 332A may relate to trace event 132A, log data 332B may relate to trace event 132B, and log data 332N may relate to trace event 132N”. Col. 10, lines 43-48 discloses sampling policy (configurable policy) is to sample all trace events/service interactions as stated “FIG. 6 illustrates sampling of real-time trace data in a service-oriented system, according to some embodiments. In one embodiment, all or nearly all of the service interactions may be monitored to generate trace data, and that trace data may be stored locally by the hosts that implement the various services”);
buffer non-root sampled trace events for a configured duration (Col. 10, lines 44-48 discloses retaining (buffer) all trace events/service interactions i.e. root trace events and non-root trace events as stated “In one embodiment, all or nearly all of the service interactions may be monitored to generate trace data, and that trace data may be stored locally by the hosts that implement the various services.”. Fig. 3 shows retaining trace events in trace storage 130A for corresponding expiration time (configured duration); and
an orchestration server (Fig. 1 shows trace analysis system 160 (orchestration server)).
Goldberg does not teach: receive an indication of a sampling decision sent from at least one collector of the plurality of collectors in response to the at least one collector sampling a root trace event of the plurality of trace events; and propagate the sampling decision to the plurality of collectors, wherein the plurality of collectors store buffered trace events related to the root trace event in the local memory.
Liu teaches:
receive an indication of a sampling decision sent from at least one collector of the plurality of collectors in response to the at least one collector sampling a root trace event of the plurality of trace events (Fig. 4 shows plurality of tracing agents 418 in plurality of services 410 and a tracing server 430. Col. 8, lines 58-63, discloses the tracing server 430 receives tracing data summary (representative indication) of sampled tracing data from each of the tracing agents as stated “When a transaction is finished, each of the tracing agents 418-1, 418-2, . . . , 418-N may send a tracing data summary corresponding to the transaction to the tracing server 430 where whether a received tracing data summary of a transaction matches at least one tracing rule 432 is determined”);
propagate the sampling decision to the plurality of collectors, wherein the plurality of collectors store buffered trace events related to the root trace event in the local memory (Col. 8, lines 67, and Col. 9, lines 1-7, discloses the tracing server 430 sends (propagate) instruction to the tracing agents based on tracing data summary to delete tracing data that do not match tracing rule, i.e. in other way to say, to retain tracing data that match the tracing rule as stated “For the tracing data summaries that do not match any tracing rules 432, the tracing server 430 may send instructions to the corresponding services, instructing their corresponding tracing agents to delete the corresponding tracing data. Before getting instructions from the tracing server 430, each of the services 410-1, 410-2, . . . , 410-N needs to store a copy of tracing data in the local environment”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Goldberg to incorporate the teaching of Liu about receives tracing data summary and instructing tracing agents to retain tracing data that matches the tracing rule. Such incorporation would enable Goldberg’s trace analysis system 160 to receive the tracing data summary indicating the initial event and instruct interaction monitoring functionalities 120A-120N to retain trace/events related to the initial event in the local trace storage 130A-130N. One would be motivated to do that to track interaction of services in the service-chain related to the initial event (Col. 13, lines 27-42 of Goldberg).
Allowable Subject Matter
Claims 2-5, 18, and 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 KAMAL M HOSSAIN whose telephone number is (571)270-3070. The examiner can normally be reached 9:30-5:30 M-F.
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 at (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 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.
June 12, 2026
/KAMAL M HOSSAIN/Primary Examiner, Art Unit 2444
Prosecution Insights