DETAILED ACTION
This non-final Office action is responsive to the preliminary amendments filed May 27th, 2025. Claim 1 has been cancelled. Claims 2-21 are new. Claims 2-21 are presented for examination.
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 .
Priority
Applicant’s claim for the benefit of a prior-filed application under 35 U.S.C. 119(e) or under 35 U.S.C. 120, 121, 365(c), or 386(c) is acknowledged.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 08/01/25 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Specification
The disclosure is objected to because of the following informalities: Paragraphs [0120] and [0125] refer to the I/O controller as item 810 which is typographical error that should recite item 840.
Appropriate correction is required.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 2-21 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter;
When considering subject matter eligibility under 35 U.S.C. 101, it must be determined whether the claim is directed to one of the four statutory categories of invention, i.e., process, machine, manufacture, or composition of matter. If the claim does fall within one of the statutory categories, it must then be determined whether the claim is directed to a judicial exception (i.e., law of nature, natural phenomenon, and abstract idea), and if so, it must additionally be determined whether the claim is a patent-eligible application of the exception. If an abstract idea is present in the claim, any element or combination of elements in the claim must be sufficient to ensure that the claim amounts to significantly more than the abstract idea itself.
Step 1: Independent claims 2 (method), 18 (apparatus), and 21 (non-transitory computer-readable medium) and dependent claims 3-17 and 19-20, respectively, fall within at least one of the four statutory categories of 35 U.S.C. 101: (i) process; (ii) machine; (iii) manufacture; or (iv) composition of matter. Claim 2 is directed to a method (i.e. process), claim 18 is directed to an apparatus (i.e. machine), and claim 21 is directed to a non-transitory computer-readable medium (i.e. manufacture).
Step 2A Prong 1: The independent claims recite generating trace data for one or more spans corresponding to respective portions of a user journey, wherein for each span of the one or more spans the trace data includes at least a customer identifier, a customer profile, and a geographical context, and wherein each span of the one or more spans is associated with a respective service of a plurality of services of an application; collecting diagnostic information and user-specific transaction information associated with the user journey based at least in part on the customer identifier, the customer profile, and the geographical context included in the trace data; generating trace context information for the one or more spans, the trace context information associated with the diagnostic information and the user-specific transaction information; storing the diagnostic information and the user-specific transaction information based at least in part on generating the trace data for the user journey, wherein one or more logs associated with the user-specific transaction information are stored in a first database and one or more tags associated with the one or more logs are stored in a second database; and retrieving, as part of a troubleshooting operation, the diagnostic information and the user-specific transaction information in response to determining that an account balance indicated by the user-specific transaction information exceeds a minimum account balance threshold (Certain Method of Organizing Human Activity & Mental Process), which are considered to be abstract ideas (See PEG 2019 and MPEP 2106.05). [Examiner notes the underlined limitations above recite the abstract idea].
The steps/functions disclosed above and in the independent claims recite the abstract idea of Certain Methods of Organizing Human Activity because the claimed limitations are generating trace data for one or more spans corresponding to respective portions of a user journey; generating trace context information for the one or more spans; and determining that an account balance indicated by the user-specific transaction information exceeds a minimum account balance threshold, which is managing personal behavior, relationships, and interactions.
The steps/functions disclosed above and in the independent claims recite the abstract idea of Mental Process because the claimed limitations are generating trace data for one or more spans corresponding to respective portions of a user journey; generating trace context information for the one or more spans; and determining that an account balance indicated by the user-specific transaction information exceeds a minimum account balance threshold, which are observations, judgments, and evaluations of the human mind.
In addition, dependent claims 3-6, 8, 10-12, 14-15, 17, 19-20 further narrow the abstract idea and recite further defining the trace data; approving a request to view the account balance after authentication of the customer identifier; propagating the trace context information across the plurality of services; processing diagnostic information and user specific transaction information; identifying successful and unsuccessful processes of the user journey based on the user-specific transaction information; generating logs and tags of user-specific transaction information; identifying a set of metrics associated with at least one service of the plurality of services; generating journey information for the user journey based at least in part on the diagnostic information, the user-specific transaction information, and the set of metrics; the set of metrics; and generating a visualization of the user journey based at least in part on the trace data, the one or more logs for the user-specific transaction information, and a set of metrics associated with at least one service of the plurality of services for the user journey. These processes are similar to the abstract idea noted in the independent claims because they further the limitations of the independent claims which recite a certain method of organizing human activity which include commercial and legal interactions such as business relations. Accordingly, these claim elements do not serve to confer subject matter eligibility to the claims since they recite abstract ideas. Dependent claims 7, 9, 13, and 16 will be discussed in Prong 2 analysis below.
Step 2A Prong 2: In this application, the above “collecting diagnostic information and user-specific transaction information associated with the user journey based at least in part on the customer identifier, the customer profile, and the geographical context included in the trace data; storing the diagnostic information and the user-specific transaction information based at least in part on generating the trace data for the user journey, wherein one or more logs associated with the user-specific transaction information are stored in a first database and one or more tags associated with the one or more logs are stored in a second database; retrieving, as part of a troubleshooting operation, the diagnostic information and the user-specific transaction information in response to determining that an account balance indicated by the user-specific transaction information exceeds a minimum account balance threshold” steps/functions of the independent claims would not account for additional elements that integrate the judicial exception (e.g. abstract idea) into a practical application because receiving/storing data and displaying data merely add insignificant extra-solution activity and merely adds the words to apply it with the judicial exception. Also, the claimed “a first database; a second database; a distributed tracing system; a relational database; a columnar database; An apparatus, comprising: one or more processors; one or more memories coupled with the one or more processors; and instructions stored in the one or more memories and executable by the one or more processors; A non-transitory computer-readable medium storing code, the code comprising instructions executable by one or more processors” would not account for additional elements that integrate the judicial exception (e.g. abstract idea) into a practical application because the claimed structure merely adds the words to apply it with the judicial exception and mere instructions to implement an abstract idea on a computer (See PEG 2019 and MPEP 2106.05).
In addition, dependent claims 3-6, 8, 10-12, 14-15, 17, 19-20 further narrow the abstract idea and dependent claims 7-9, 13, and 16 additionally recite “the second database is indexed according to a hash index associated with the user-specific transaction information, and wherein the diagnostic information is retrieved in part using the hash index”; “wherein the diagnostic information and the user-specific transaction information are retrieved, collected, processed, or any combination thereof, in approximate real time”; “collecting the diagnostic information and the user-specific transaction information comprises: collecting the diagnostic information and the user-specific transaction information based at least in part on one or more code wrappers applied to a distributed tracing system, the one or more code wrappers being configured to collect at least the user-specific transaction information for the plurality of services”; “storing the one or more logs in the first database comprising raw data storage; and storing the one or more tags in the second database different than the first database, wherein the second database comprises a relational database”; and “storing the trace data in a columnar database based at least in part on generating the trace data” which do not account for additional elements that integrate the judicial exception (e.g. abstract idea) into a practical application because receiving/storing data and displaying data merely add insignificant extra-solution activity and the claimed “second database”, “a distributed tracing system”, “first database”, “a relational database”, “a columnar database” which do not account for additional elements that integrate the judicial exception (e.g. abstract idea) into a practical application because the claimed structure merely adds the words to apply it with the judicial exception and mere instructions to implement an abstract idea on a computer (See PEG 2019 and MPEP 2106.05).
The claimed “a first database; a second database; a distributed tracing system; a relational database; a columnar database; An apparatus, comprising: one or more processors; one or more memories coupled with the one or more processors; and instructions stored in the one or more memories and executable by the one or more processors; A non-transitory computer-readable medium storing code, the code comprising instructions executable by one or more processors” are recited so generically (no details whatsoever are provided other than that they are general purpose computing components and regular office supplies) that they represent no more than mere instructions to apply the judicial exception on a computer. These limitations can also be viewed as nothing more than an attempt to generally link the use of the judicial exception to the technological environment of a computer. Even when viewed in combination, the additional elements in the claims do no more than use the computer components as a tool. There is no change to the computers and other technology that is recited in the claim, and thus the claims do not improve computer functionality or other technology (See PEG 2019).
Step 2B: When analyzing the additional element(s) and/or combination of elements in the claim(s) other than the abstract idea per se the claim limitations amount(s) to no more than: a general link of the use of an abstract idea to a particular technological environment and merely amounts to the application or instructions to apply the abstract idea on a computer (See MPEP 2106.05 and PEG 2019). Further, method claims 2-17; system claims 18-20; and non-transitory computer-readable storage medium claim 21 recites “a first database; a second database; a distributed tracing system; a relational database; a columnar database; An apparatus, comprising: one or more processors; one or more memories coupled with the one or more processors; and instructions stored in the one or more memories and executable by the one or more processors; A non-transitory computer-readable medium storing code, the code comprising instructions executable by one or more processors”; however, these elements merely facilitate the claimed functions at a high level of generality and they perform conventional functions and are considered to be general purpose computer components which is supported by Applicant’s specification in Paragraphs [0106], [0122], [0125] and Figures 1-2 & 6-8. The Applicant’s claimed additional elements are mere instructions to implement the abstract idea on a general-purpose computer and generally link of the use of an abstract idea to a particular technological environment. Also, the above “collecting diagnostic information and user-specific transaction information associated with the user journey based at least in part on the customer identifier, the customer profile, and the geographical context included in the trace data; storing the diagnostic information and the user-specific transaction information based at least in part on generating the trace data for the user journey, wherein one or more logs associated with the user-specific transaction information are stored in a first database and one or more tags associated with the one or more logs are stored in a second database; retrieving, as part of a troubleshooting operation, the diagnostic information and the user-specific transaction information in response to determining that an account balance indicated by the user-specific transaction information exceeds a minimum account balance threshold” steps/functions of the independent claims would not account for significantly more than the abstract idea because receiving data and displaying/presenting data (See MPEP 2106.05) have been identified as well-known, routine, and conventional steps/functions to one of ordinary skill in the art. When viewed as a whole, these additional claim element(s) do not provide meaningful limitation(s) to transform the abstract idea into a patent eligible application of the abstract idea such that the claim(s) amounts to significantly more than the abstract idea itself.
In addition, claims 3-6, 8, 10-12, 14-15, 17, 19-20 further narrow the abstract idea identified in the independent claims. The Examiner notes that the dependent claims merely further define the data being analyzed and how the data is being analyzed. Similarly, claims 7-9, 13, and 16 additionally recite “the second database is indexed according to a hash index associated with the user-specific transaction information, and wherein the diagnostic information is retrieved in part using the hash index”; “wherein the diagnostic information and the user-specific transaction information are retrieved, collected, processed, or any combination thereof, in approximate real time”; “collecting the diagnostic information and the user-specific transaction information comprises: collecting the diagnostic information and the user-specific transaction information based at least in part on one or more code wrappers applied to a distributed tracing system, the one or more code wrappers being configured to collect at least the user-specific transaction information for the plurality of services”; “storing the one or more logs in the first database comprising raw data storage; and storing the one or more tags in the second database different than the first database, wherein the second database comprises a relational database”; and “storing the trace data in a columnar database based at least in part on generating the trace data” which do not account for additional elements that amount to significantly more than the abstract idea because receiving data and displaying/presenting data (See MPEP 2106.05) have been identified as well-known, routine, and conventional steps/functions to one of ordinary skill in the art and the claimed “second database”, “a distributed tracing system”, “first database”, “a relational database”, “a columnar database” which do not account for additional elements that amount to significantly more than the abstract idea because the claimed structure merely amounts to the application or instructions to apply the abstract idea on a computer and does not move beyond a general link of the use of an abstract idea to a particular technological environment (See MPEP 2106.05). The additional limitations of the independent and dependent claim(s) when considered individually and as an ordered combination do not amount to significantly more than the abstract idea. The examiner has considered the dependent claims in a full analysis including the additional limitations individually and in combination as analyzed in the independent claim(s). Therefore, the claim(s) are rejected under 35 U.S.C. 101 as being directed to non-statutory subject matter.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claim(s) 2-5, 7-15, and 17-21 is/are rejected under 35 U.S.C. 103 as being unpatentable over Agarwal (U.S 11,347,625 B1) in view of Devaraj (U.S 2022/0121628 A1) in view of Bowers (U.S 11,847,581 B1).
Claims 2, 18, and 21
Regarding Claim 2, Agarwal discloses the following:
A method, comprising [see at least Col 13 lines 61-63 for reference to Performing Application Performance Monitoring methods such as distributed tracing to profile and monitor applications; Col 18 lines 3-7 for reference to a method for ingesting and aggregating span information to support multiple modalities of analysis for application performance monitoring (APM); Figure 5 and related text regarding the method for ingesting and aggregating span information to support multiple modalities of analysis for application performance monitoring (APM)]
generating trace data for one or more spans corresponding to respective portions of a user journey, wherein for each span of the one or more spans the trace data includes at least a customer identifier and a geographical context, and wherein each span of the one or more spans is associated with a respective service of a plurality of services of an application [see at least Col 6 lines 55-58 for reference to "Global tags” generally represent properties of a user request (e.g., tenant name, tenant level, user location, environment type, etc.) and may be extracted from any span of the trace based on configured rules; Col 9 lines 42-53 for reference to the generation of distributed tracing data using software such as OPENTELEMETRY and OpenCensus to annotate each span with one or more tags that provide context about the execution, such as the client instrumenting the software, a document involved in the request, an infrastructure element used in servicing the request; Col 9 lines 54-66 for reference to the instrumentation of code handling the creation of unique session IDs, trace and span IDs, tracking duration, adding metadata and handling context data; Col 9 lines 67 & Col 10 lines 1-3 for reference to the trace data generated by the services being collected and analyzed to monitor and troubleshoot the microservices based applications generating the trace data; Col 39 lines 41-46 for reference to monitoring real-user data across a variety of end-user configurations, user status, locations etc.; Col 56 lines 34-38 for reference to a plurality of spans associated with a real user interaction with a GUI are automatically ingested for a given time duration and consolidated into one or more traces; Col 46 lines 49-54 for reference to each browser span has all the metadata needed to analyze it, e.g., sessionId, location.href, activity, all tags , etc.; Col 57 lines 13-19 for reference to when the frontend receives a request from a user, a Span ID, and a Trace ID are generates from the request by the RUM instrumentation and the backend responds with a header (e.g., a server-timing header); Col 57 lines 20-21 for reference to the context propagation being REST which is header-based; Figure 2A and related text regarding the exemplary trace tree which displays Figure 3 and related text regarding the collection and ingestion of trace data for further analysis within a computer system; Figure 24 and related text regarding item 2402 ‘Generate a plurality of traces from a plurality of spans ingested during a given duration of time’; Examiner notes the ‘instrumented code’ as analogous to the ‘distributed trace code’]
collecting diagnostic information and user-specific transaction information associated with the user journey based at least in part on the customer identifier and the geographical context included in the trace data [see at least Col 8 lines 23-27 for reference to a trace representing a single user request, also referred to as a transaction, and represents the entire lifecycle of a request as it traverses across the various services or components of a distributed system; Col 8 lines 32-35 for reference to the system using real user monitoring (RUM) to surface meaningful diagnostic information on frontend performance; Col 8 lines 55-60 for reference to both RUM and APM based methods monitoring the speed at which both frontend and backend transactions are performed by end-users; Col 44 lines 3-6 for reference to the connection of frontend and backend traces to provide complete visibility into any transaction all the way from a user browser, through the network, and to any backend system]
generating trace context information for the one or more spans, the trace context information associated with the diagnostic information and the user-specific transaction information [see at least Col 9 lines 49-53 for reference to the system annotating each span with one or more tags that provide context about the execution, such as the client instrumenting the software, a document involved in the request, an infrastructure element used in servicing a request, etc.; Col 9 lines 56-65 for reference to the handling of context data being known as context propagation to pass context (e.g., Trace ID) between function/microservice calls; Col 26 lines 60-62 for reference to each of the generated spans carrying the Trace ID associated with the request, thereby, propagating the context of the trace]
storing the diagnostic information and the user-specific transaction information based at least in part on generating the trace data for the user journey [see at least Col 10 lines 57-60 for reference to the collector running the span data through a processing pipeline to store it in specific storage or analytics backend such as a monitoring service; Col 11 lines 26-30 for reference to span and tracing data being transmitted to storage and monitoring backend services; Col 15 lines 37-40 for reference to the monitoring platform simultaneously storing ingested trace data using three different formats corresponding to different modalities]
wherein one or more logs associated with the user-specific transaction information are stored in a first database and one or more tags associated with the one or more logs are stored in a second database [see at least Col 19 lines 43-54 for reference to the databases representing different respective databases for each of the three modalities; Col 26 lines 30-37 for reference to different nodes or tags being stored within different databases; Col 43 lines 43-60 for reference to the schema for persisting certain data in certain databases being different; Figure 5 and related text regarding item 55 ‘Database(s) for storing data for each modality’; Figure 7 and related text regarding item 777 ‘Database’; Figure 13 and related text regarding item 1366 ‘Database for storing aggregated information’; Figure 17 and related text regarding item 1717 ‘Database(s) for storing data for each modality’]
retrieving, as part of a troubleshooting operation, the diagnostic information and the user-specific transaction information in response to determining that an account balance indicated by the user-specific transaction information exceeds a minimum account balance threshold [see at least Col 9 lines 65-67 and Col 10 lines 1-2 for reference to the trace data generated by the services being collected and analyzed to monitor and troubleshoot the microservices-based applications generating the trace data; Col 11 lines 24-26 for reference to the monitoring services receiving and analyzing the span data for monitoring and troubleshooting purposes; Col 13 lines 39-46 for reference to the metrics data being used in a thresholding comparison to determine that there is an issue that needs attention and the trace data being used to determine which component requires attention; Col 14 lines 25-27 for reference to the monitoring service storing 100% of the spans received from the client in real time; Col 14 lines 31-37 for reference to incoming trace and span information being efficiently ingested and aggregated in real time by the monitoring platform; Col 19 lines 14-16 for reference to the sessionization module being able to ingest, process, and store all or more spans of the collector in real time; Col 56 lines 57-63 for reference to the monitoring platform providing a unified monitoring view for diagnosing problems and troubleshooting by using information extracted from the ingested spans]
While Agarwal discloses the limitations above, it does not disclose wherein for each span of the one or more spans the trace data includes at least a customer profile; collecting diagnostic information and user-specific transaction information associated with the user journey based at least in part on the customer profile; and retrieving, as part of a troubleshooting operation, the diagnostic information and the user-specific transaction information in response to determining that an account balance indicated by the user-specific transaction information exceeds a minimum account balance threshold.
However, Devaraj discloses the following:
wherein for each span of the one or more spans the trace data includes at least a customer profile [see at least Paragraph 0152 for reference to the monitoring component may also monitor and collect other device profile information including, for example, a type of client device, a manufacturer, and model of the device, versions of various software applications installed on the device, and so forth; Paragraph 0775 for reference to distributed tracing, also called distributed request tracing, is a method used to profile and monitor applications, especially those built using a microservices architecture; Paragraph 0778 for reference to each span can further include information regarding the particular operation represented by the span, such as a duration of the operation, inputs and outputs to the operation, performance metrics regarding the operation (e.g., amount of computing resources used, utilization rates during the operation, etc.), or the like]
collecting diagnostic information and user-specific transaction information associated with the user journey based at least in part on the customer profile [see at least Paragraph 0127 for reference to when the data source is an operating system log, an event can include one or more lines from the operating system log containing machine data that includes different types of performance and diagnostic information associated with a specific point in time (e.g., a timestamp); Paragraph 0744 for reference to proactive monitoring tree enables a user to easily navigate the hierarchy by selectively expanding nodes representing various entities (e.g., virtual centers or computing clusters) to view performance information for lower-level nodes associated with lower-level entities (e.g., virtual machines or host systems); Paragraph 0774 for reference to user may therefore analyze trace data to identify potentially issues with a transaction, thus helping to monitor and analyze performance of a distributed system; Paragraph 0792 for reference to intake system can then extract the relevant data from the logs, in order to generate a trace for that transaction also the intake system can be configured to detect, within these entries, identifying information for a transaction to which the operation relates also the intake system can detect hierarchical relationships between operations based on the content of log entries, and arrange such spans in that hierarchical relationship within the trace data]
Before the effective filing date, it would have been obvious to one of ordinary skill in the art to modify the span data of Agarwal to include the client profile information of Devaraj. Doing so an end user can be enabled to, for example, view the tree to identify operations making up a transaction, and to select individual nodes of the tree to identify specific information regarding those operations, as stated by Devaraj (Paragraph 0778).
While the combination of Agarwal and Devaraj disclose the limitations above, they do not disclose retrieving, the user-specific transaction information in response to determining that an account balance indicated by the user-specific transaction information exceeds a minimum account balance threshold.
However, Bowers discloses the following:
retrieving, the user-specific transaction information in response to determining that an account balance indicated by the user-specific transaction information exceeds a minimum account balance threshold [see at least Col 35 lines 29-58 for reference to the financial institution providing the customer and option to set a low balance threshold which represents a maximum negative balance after the customer account enters low cash mode and the threshold including providing the customer with the ability to selectively choose one or more scheduled payments for processing; Figure 30 and related text regarding managing financial accounts including item 3004 ‘Receive low balance threshold’ and item 3006 ‘Determine account balance’]
Before the effective filing date, it would have been obvious to one of ordinary skill in the art to modify the user specific transaction monitoring of Agarwal to include the determination of exceeding a minimum account balance threshold of Bowers. Doing so would provide the customer with pace of mind that a negative balance will not exceed the customer’s ability repay and also has the benefit of assisting the financial institution in assessing a financial risk profile associated with the customer, as stated by Bowers (Col 35 lines 36-40).
Regarding claims 18 and 21, the claims recite limitations already addressed by the rejection of claim 2. Regarding claim 18, Agarwal teaches an apparatus comprising: one or more processors; one or more memories coupled with the one or more processors; and instructions stored in the one or more memories and executable by the one or more processors [Col 10 lines 28-34 & Figures 1A-B and 3]. Regarding claim 21, Agarwal teaches a non-transitory computer-readable medium storing code, the code comprising instructions executable by one or more processors [Col 55 lines 64-67 & Col 56 lines 30-33]. Therefore, claims 18 and 21 are rejected as being unpatentable over the combination of Agarwal, Devaraj, and Bowers.
Claims 3 and 19
While the combination of Agarwal, Devaraj, and Bowers discloses the limitations above, regarding Claim 3, Agarwal discloses the following:
wherein the customer identifier associates a span with a corresponding customer and a set of customer data and the geographical context comprises geographical location data indicative of a location where the corresponding customer accesses the application [see at least Col 6 lines 55-58 for reference to "Global tags” generally represent properties of a user request (e.g., tenant name, tenant level, user location, environment type, etc.) and may be extracted from any span of the trace based on configured rules; Col 39 lines 41-46 for reference to monitoring real-user data across a variety of end-user configurations, user status, locations etc.; Col 46 lines 49-54 for reference to each browser span has all the metadata needed to analyze it, e.g., sessionId, location.href, activity, all tags , etc.; Col 54 lines 56-60 for reference to session exemplars may comprise details regarding the session ID, a timestamp associated with the session, the duration of the session, the agent (e.g., a browser, platform, OS) used during the session, a location of the user; Col 55 lines 7-11 for reference to client seeing page views based on user ID]
While Agarwal discloses the limitations above, it does not disclose the customer profile comprises one or more attributes of the corresponding customer.
However, Devaraj discloses the following:
the customer profile comprises one or more attributes of the corresponding customer [see at least Paragraph 0152 for reference to the monitoring component may also monitor and collect other device profile information including, for example, a type of client device, a manufacturer, and model of the device, versions of various software applications installed on the device, and so forth; Paragraph 0775 for reference to distributed tracing, also called distributed request tracing, is a method used to profile and monitor applications, especially those built using a microservices architecture; Paragraph 0778 for reference to each span can further include information regarding the particular operation represented by the span, such as a duration of the operation, inputs and outputs to the operation, performance metrics regarding the operation (e.g., amount of computing resources used, utilization rates during the operation, etc.), or the like]
Before the effective filing date, it would have been obvious to one of ordinary skill in the art to modify the span data of Agarwal to include the client profile information of Devaraj. Doing so an end user can be enabled to, for example, view the tree to identify operations making up a transaction, and to select individual nodes of the tree to identify specific information regarding those operations, as stated by Devaraj (Paragraph 0778).
Regarding claim 19, the claim recites limitations already addressed by the rejection of claim 3.
Claims 4 and 20
While the combination of Agarwal, Devaraj, and Bowers discloses the limitations above, regarding Claim 4, Agarwal discloses the following:
wherein the trace data further comprises a time of day that a user initiates the user journey including an initial timestamp, an ending timestamp, a total time, or both, a type of transaction that corresponds to the user-specific transaction information, or any combination thereof [see at least Col 6 lines 35-39 for reference to a span including a unique span ID, a service name, an operation name, duration, start and end timestamps, and additional annotations and attributes; Figure 24 and related text regarding item 2402 ‘Generate a plurality of traces from a plurality of spans ingested during a given duration of time’]
Regarding claim 20, the claim recites limitations already addressed by the rejection of claim 4.
Claim 5
While the combination of Agarwal, Devaraj, and Bowers discloses the limitations above, Agarwal does not disclose approving a request to view the account balance after authentication of the customer identifier.
Regarding Claim 5, Bowers discloses the following:
approving a request to view the account balance after authentication of the customer identifier [see at least Col 20 lines 31-67 for reference to Fraud Protection Features including the use of security questions, multi-factor authentication, password standards, and other features to verify customer identity; Figure 20 and related text regarding multi-factor authentication including item 2014 ‘Grant account access’]
Before the effective filing date, it would have been obvious to one of ordinary skill in the art to modify the user-transaction data of Agarwal to include the approving request following authentication of Bowers. Doing so would provide comprehensive transactional services for customers managing their financial accounts in a low cash mode, as stated by Bowers (Col 1 lines 50-52).
Claim 7
While the combination of Agarwal, Devaraj, and Bowers discloses the limitations above, Agarwal does not disclose wherein the second database is indexed according to a hash index associated with the user-specific transaction information, and wherein the diagnostic information is retrieved in part using the hash index.
Regarding Claim 7, Devaraj discloses the following:
wherein the second database is indexed according to a hash index associated with the user-specific transaction information, and wherein the diagnostic information is retrieved in part using the hash index [see at least Paragraph 0274 for reference to the search node mapping policy can indicate that the search manager 514 is to use a consistent hash function or other function to consistently map a bucket to a particular search node; Paragraph 0283 for reference to the data can be raw machine data, performance metrics data, correlation data, JSON blobs, XML data, data in a datamodel, report data, tabular data, streaming data, data exposed in an API, data in a relational database, etc.; Paragraph 0333 for reference to the data store catalog 220 can be updated by the indexing system 212 with information about the buckets or data stored in common storage; Paragraph 0798 for reference to the intake system 210 may apply a deterministic naming algorithm (e.g., a hash function) to the transaction identifier “Transaction A” in order to determine a trace identifier; Paragraph 0821 for reference to the trace and spans may be identified within according to a deterministic naming scheme, such as application of a hash function to trace and span identifiers]
Before the effective filing date, it would have been obvious to one of ordinary skill in the art to modify the second database of Agarwal to include the hash indexing function of Devaraj. Doing so subsequent traces generated for the same transaction can include the same trace identifier, and can be used to amend a previously generated trace, as stated by Davaraj (Paragraph 0821).
Claim 8
While the combination of Agarwal, Devaraj, and Bowers discloses the limitations above, regarding Claim 8, Agarwal discloses the following:
wherein the diagnostic information and the user-specific transaction information are retrieved, collected, processed, or any combination thereof, in approximate real time [see at least Col 14 lines 25-27 for reference to the monitoring service storing 100% of the spans received from the client in real time; Col 14 lines 31-37 for reference to incoming trace and span information being efficiently ingested and aggregated in real time by the monitoring platform; Col 19 lines 14-16 for reference to the sessionization module being able to ingest, process, and store all or more spans of the collector in real time; Col 56 lines 57-63 for reference to the monitoring platform providing a unified monitoring view for diagnosing problems and troubleshooting by using information extracted from the ingested spans]
Claim 9
While the combination of Agarwal, Devaraj, and Bowers discloses the limitations above, regarding Claim 9, Agarwal discloses the following:
wherein collecting the diagnostic information and the user-specific transaction information comprises: collecting the diagnostic information and the user-specific transaction information based at least in part on one or more code wrappers applied to a distributed tracing system, the one or more code wrappers being configured to collect at least the user-specific transaction information for the plurality of services [see at least Col 8 lines 32-38 for reference to the system using real user monitoring (RUM) to surface meaningful diagnostic information on frontend performance so developers can optimize frontend code and deliver the best possible user experience as well as APM monitoring the performance of server-side code and offering detailed insight on improving it to reduce infrastructure cost; Col 39 lines 16-20 for reference to the platform returning a list of the traces matching the client-entered filters and providing information about the traces, e.g., the Trace ID, duration, start time, root operation, root cause error status code and associated spans; Figure 16 and related text regarding item 1602 and the listed code associated with Trace ID]
Claim 10
While the combination of Agarwal, Devaraj, and Bowers discloses the limitations above, regarding Claim 10, Agarwal discloses the following:
identifying, using the trace context information, one or more unsuccessful processes of the user journey based at least in part on the user-specific transaction information [see at least Col 8 lines 47-51 for reference to tracking real users allows RUM to provide critical real-world measurements and helps developers identify whether certain user engagements or activities are triggering a lag in performance or causing errors; Col 14 lines 32-36 for reference to incoming trace and span information being efficiently ingested and aggregated in real time, the monitoring platform is able to convey meaningful and accurate information regarding error rate; Figure 15A and related text regarding item 1505 ‘error’ indication associating the operation as resulting in an error; Examiner notes the raising of an error as ‘unsuccessful’]
Claim 11
While the combination of Agarwal, Devaraj, and Bowers discloses the limitations above, regarding Claim 11, Agarwal discloses the following:
identifying, using the trace context information, one or more successful processes of the user journey based at least in part on the user-specific transaction information [see at least Col 8 lines 47-51 for reference to tracking real users allows RUM to provide critical real-world measurements and helps developers identify whether certain user engagements or activities are triggering a lag in performance or causing errors; Col 14 lines 32-36 for reference to incoming trace and span information being efficiently ingested and aggregated in real time, the monitoring platform is able to convey meaningful and accurate information regarding error rate; Figure 15A and related text regarding item 1505 ‘error’ indication associating the operation as resulting in an error; Examiner notes the lack of raising of an error as ‘successful’]
Claim 12
While the combination of Agarwal, Devaraj, and Bowers discloses the limitations above, regarding Claim 12, Agarwal discloses the following:
generating the one or more logs for the user-specific transaction information of the user journey, wherein each log of the one or more logs correspond to a set of transactions occurring at a point in time [see at least Col 12 lines 40-44 for reference to tracing data being coupled with log data and/or metrics data in order to provide clients with a more complete picture of the system; Col 13 lines 36-39 for reference to trace data being correlated to log data to provide insights]
generating the one or more tags for the user-specific transaction information of the user journey, wherein each tag of the one or more tags is associated with a respective log of the one or more logs using key value pairing [see at least Col 6 lines 35-39 for reference to the span including a unique span ID, a service name, an operation name, duration, start and end timestamps, and additional annotations (e.g., tags such as key: value pairs); Col 6 lines 46-49 for reference to “tags” as used herein generally refers to key: value pairs that provide further context regarding the execution environment and enable client - defined annotation of spans in order to query, filter and comprehend trace data; Col 21 lines 22-25 for reference to extended identity comprising the span’s base identity and additionally a mapping of the span’s tag key: value pairs that match a clients configuration setting; Figure 17 and related text regarding item 1707 ‘tag indexing module’]
Claim 13
While the combination of Agarwal, Devaraj, and Bowers discloses the limitations above, regarding Claim 13, Agarwal discloses the following:
storing the one or more logs in the first database comprising raw data storage [see at least Col 19 lines 43-54 for reference to data sets associated with each of the modalities being stored in a corresponding database; Figure 7 and related text regarding item 742 ‘Determine trace identities’ and then corresponding item 777 ‘database’; Figure 17 and related text regarding item 1717 ‘Database(s) for storing data for each modality’]
storing the one or more tags in the second database different than the first database [see at least Col 19 lines 43-54 for reference to data sets associated with each of the modalities being stored in a corresponding database; Col 31 lines 56-59 for reference to the collection module collecting each pair of spans that has a parent-child relationship and where each of the two spans in the pair are associated with a different service; Col 43 lines 53-60 for reference to data sets associated with each of the modalities being stored in a corresponding database; Figure 7 and related text regarding item 742 ‘Determine trace identities’ and then corresponding item 777 ‘database’; Figure 17 and related text regarding item 1717 ‘Database(s) for storing data for each modality’]
While Agarwal discloses the limitations above, it does not disclose wherein the second database comprises a relational database.
However, Devaraj discloses the following:
wherein the second database comprises a relational database [see at least Paragraph 0332 for reference to the data store catalog 22—may utilize a database, e.g., a relational database engine, such as commercially-provided relational database services, e.g., Amazon's Aurora; Paragraph 0383 for reference to the data can be raw machine data, performance metrics data, correlation data, JSON blobs, XML data, data in a datamodel, report data, tabular data, streaming data, data exposed in an API, data in a relational database, etc.]
Before the effective filing date, it would have been obvious to one of ordinary skill in the art to modify the storage of Agarwal to include the relational database of Devaraj. Doing so enables a user to continue investigating and learn valuable insights about the machine data, as stated by Devaraj (Paragraph 0113).
Claim 14
While the combination of Agarwal, Devaraj, and Bowers discloses the limitations above, regarding Claim 14, Agarwal discloses the following:
identifying a set of metrics associated with at least one service of the plurality of services, wherein the set of metrics comprises one or more threshold values corresponding to a service level objective, a service level indicator, a service level agreement, or any combination thereof [see at least Col 11 lines 63-66 for reference to traces being sampled to generate metric values and the tasks sending values corresponding to various metrics as they are generated to the instrument analysis system; Col 13 lines 6-10 for reference to the monitoring system generating metrics data from the trace data; Col 17 lines 6-10 for reference to the systems use of service level indicators(SLI) to aggregate metric data; Figure 6 and related text regarding the method of generating metric time series from ingested spans; Figure 26 and related text regarding item 2604 ‘Aggregating metrics data associated with both a frontend and a backend of an application (or website) from the plurality of traces’]
generating journey information for the user journey based at least in part on the diagnostic information, the user-specific transaction information, and the set of metrics [see at least Col 51 lines 35-39 for reference to the system providing a pop-up window associated with the Trace ID providing a performance summary; Col 54 lines 3-6 for reference to system allowing the client to receive insight into a user’s journey, in particular, the manner in which the user navigated from one page to the next; Figure 20C and related text regarding item 2078 ‘performance summary’]
Claim 15
While the combination of Agarwal, Devaraj, and Bowers discloses the limitations above, regarding Claim 15, Agarwal discloses the following:
wherein the set of metrics includes one or more predetermined values, one or more measurements over a time period, or any combination thereof [see at least Col 31 lines 49-51 for reference to the collection module receiving one or more traces generated within a predetermined time window; Figure 7 and related text regarding ‘Aggregating for metric time series modality’; Figure 17 and related text regarding item 1780 ‘Time window Y’, item 1720 ‘Real-time aggregation for metric time series’]
Claim 17
While the combination of Agarwal, Devaraj, and Bowers discloses the limitations above, regarding Claim 17, Agarwal discloses the following:
generating a visualization of the user journey based at least in part on the trace data, the one or more logs for the user-specific transaction information, and a set of metrics associated with at least one service of the plurality of services for the user journey, wherein the visualization is generated based at least in part on a transaction type, or a portion of the user journey, or any combination thereof [see at least Col 12 lined 21-26 for reference to the query engine and reporting system within the monitoring service being configured to render graphical user interfaces (GUIs) and/or graphical visualizations to represent the trace and span information received from various clients; Col 56 lines 5-11 for reference to the system rendering and displaying aggregated metrics for the user session over a time duration associated with the user session in which aggregated metrics pertaining to errors, requests, etc. may be plotted graphically; Col 56 lines 12-18 for reference to the waterfall visualization displaying a span that corresponds to a particular time period within a selected time duration of the client; Figure 23 and related text regarding item 2304 ‘Render a Graphical Visualization Displaying Aggregated Metrics for the User Session Over a Time Duration’ and item 2306 ‘Render a Waterfall Visualization Displaying Spans Associated with Events in the User Session, Wherein the Waterfall Visualization is Operable to be Scoped to a Select Period within the Time Duration’]
Claim(s) 6 is/are rejected under 35 U.S.C. 103 as being unpatentable over Agarwal (U.S 11,347,625 B1) in view of Devaraj (U.S 2022/0121628 A1) in view of Bowers (U.S 11,847,581 B1), as applied in claim 2, in view of Cirone (U.S 2022/0083452 A1).
Claim 6
While the combination of Agarwal, Devaraj, and Bowers discloses the limitations above, regarding Claim 6, Agarwal discloses the following:
propagating the trace context information across the plurality of services based at least in part on one or more trace headers, wherein the trace context information is propagated in accordance with a propagation scheme [see at least Col 9 lines 14-16 for reference to the generation of a Trace ID and the following of the request as it propagates through the distributed system; Col 9 lines 60-63 for reference to context propagation being based on REST which is header-based and requires a transaction to pass headers between service-to-service calls; Col 16 lines 9-12 for reference to each user request being assigned a Trace ID which will then propagate to the various spans that are generated during the service request’; Figure 2B and related text regarding the trace tree]
While Agarwal discloses the limitations above, it does not disclose wherein the trace context information is propagated in accordance with a B3 propagation scheme.
However, Cirone discloses the following:
wherein the trace context information is propagated in accordance with a B3 propagation scheme [see at least Paragraph 0043 for reference to propagating span context across different devices; Paragraph 0065 for reference to span context can be propagated along with the outgoing request (for example, in the form of special HTTP headers); Paragraph 0124 for reference to the process for propagating tracing across distributed software application; Paragraph 0139 for reference to the determination of propagation headers; Paragraph 0147-0152 for reference to the propagation scheme examples; Paragraph 0163 for reference to the Zipkin B3 HTTP header scheme is used due to its wide support, showing examples of B3 headers; Figure 11 and related text regarding the process for propagating tracing across a distributed software application]
Before the effective filing date, it would have been obvious to one of ordinary skill in the art to modify the propagation scheme of Agarwal to include the B3 propagation scheme of Cirone. Doing so would automatically track operations such as user iteractions, page navigation, and server calls and groups related logical transactions together in such a way as to enable end-to-end tracing from a click of a user on a web page, including a distributed server system (heterogenous or otherwise) that implements back end services, as stated by Cirone (Paragraph 0031).
Claim(s) 16 is/are rejected under 35 U.S.C. 103 as being unpatentable over Agarwal (U.S 11,347,625 B1) in view of Devaraj (U.S 2022/0121628 A1) in view of Bowers (U.S 11,847,581 B1), as applied in claim 2, in view of Rahman (U.S 2015/0161623 A1).
Claim 16
While the combination of Agarwal, Devaraj, and Bowers discloses the limitations above, regarding Claim 16, Agarwal discloses the following:
storing the trace data in a columnar database based at least in part on generating the trace data [see at least Col 10 lines 57-60 for reference to the collector running the span data through a processing pipeline to store it in specific storage or analytics backend such as a monitoring service; Col 11 lines 26-30 for reference to span and tracing data being transmitted to storage and monitoring backend services; Col 15 lines 37-40 for reference to the monitoring platform simultaneously storing ingested trace data using three different formats corresponding to different modalities]
While Agarwal discloses the limitations above, it does not disclose storing the trace data in a columnar database based at least in part on generating the trace data.
However, Rahman discloses the following:
storing the trace data in a columnar database based at least in part on generating the trace data [see at least Paragraph 0024 for reference to the database being a columnar database; Figure 1 and related text regarding item 112 ‘database’]
Before the effective filing date, it would have been obvious to one of ordinary skill in the art to modify the storage of Agarwal to include the columnar database of Rahman. Doing so allows a user to easily modify (for example, add, delete, and/or change) characteristics of the customer, the base maps, or other data elements without changing the framework, thereby enabling scalability and extensibility of the system, as stated by Rahman (Paragraph 0013).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Bernard, Gaël, and Periklis Andritsos. "Discovering customer journeys from evidence: a genetic approach inspired by process mining." International Conference on Advanced Information Systems Engineering. Cham: Springer International Publishing, 2019.
Bernard, Gaël, Arik Senderovich, and Periklis Andritsos. "Cut to the trace! process-aware partitioning of long-running cases in customer journey logs." International Conference on Advanced Information Systems Engineering. Cham: Springer International Publishing, 2021.
DOCUMENT ID
INVENTOR(S)
TITLE
US 11,582,316 B1
Danyi et al.
URL Normalization For Rendering A Service Graph And Aggregating Metrics Associated With A Real User Session
US 2005/0044438 A1
Nonogaki et al.
Trace Data Processing Apparatus And Method
JP2010177851A
Nakayama et al.
System of monitoring user action, and method of monitoring user action
Any inquiry concerning this communication or earlier communications from the examiner should be directed to KRISTIN ELIZABETH GAVIN whose telephone number is (571)270-7019. The examiner can normally be reached M-F 7:30-4:30 PM EST.
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, Jerry O'Connor can be reached at 571-272-6787. 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.
/KRISTIN E GAVIN/Primary Examiner, Art Unit 3624
Prosecution Insights