Detailed Action
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
The Office Action is in response to claims filed on 4/4/2025 where claim 1-20 are pending and ready for examination.
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.
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 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception without reciting significantly more.
Claim 1 recites a method of displaying synchronized messages including receiving a first message having a timestamp, converting the timestamp from a fist format to a universal format, selecting a time range, comparing the converted timestamp to the selected time range, and providing a visual indication when the timestamp is within the selected time range.
These limitations recite an abstract idea because they amount to collecting information, converting/analyzing timestamp data, comparing the data to a selected range, and displaying the result of the analysis. The converting and comparing steps are mathematical calculations and/or evaluations that could be performed mentally or with pen and paper, and the receiving and displaying steps are merely data input and output associated with that analysis.
The claim does not integrate the abstract idea into a practical application. The additional limitations merely receive data, display information related to the message, and provide a visual indication of the comparison result. These are insignificant extra solution activities and do not improve the functioning of a computer, improve another technology, use a particular machine integral to the claim, or otherwise impose a meaningful technological limitation on the abstract idea. MPEP 2106.05(g) treats mere data gathering and outputting as insignificant extra solution activity, and MPEP 2106 also explains that generally link an abstract idea to a technological environment is not enough.
The claim does not recite an inventive concept. The claim is drafted at a high level of generality and does not recite any specific timestamp conversion algorithm, synchronization protocol, display control mechanism, specialized hardware, or unconventional arrangement of components. Instead the claim merely applies the abstract idea of converting/comparing timestamp information and displaying the comparison result. Accordingly, claim 1 is directed to patent-ineligible subject matter under 35 U.S.C. 101.
The remaining independent claims (9 and 19) are rejected based on the same rationale. Furthermore the examiner has reviewed all of the dependent claims and they merely represent insignificant extra solution activity and/or reinforce the judicial exception. According claim 1-20 are rejected under 35 U.S.C. 101.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 3, 8 – 9, and 18 are rejected under 35 USC 103 as being unpatentable over Bitincka (US 11748160) and in further view of Baum (US 20130060783)
Regarding claim 1, a method for displaying synchronized messages comprising the steps of:
receiving a first message having a first timestamp in a first format (Bitincka; Bitincka describes an observability pipeline system that receives and ingests a stream of raw “event data” or “records” from various source agents, where the raw data includes individual, disparate format properties like timestamps. Under the Broadest Reasonable Interpretation (BRI), Bitincka’s ingested “event data” or “record” is the structural and functional equivalent of the claimed “first message”, and its raw timestamp is the claimed “first timestamp in a firs format”
Colum 10, Lines 54 – 55 “The event data 202 are streamed to the observability pipeline process 200 for processing ...”
Column 11, Lines 17 “In some instances, event data 202 represent events as structured or typed key value pairs that describe something that occurred at a given point in time. For example, the event data 202 can contain information in a data format that stores key-value pairs for an arbitrary number of fields or dimensions, e.g., in JSON format or another format. A structured event can have a timestamp and a “name” field. Instrumentation libraries can automatically add other relevant data like the request endpoint, the user-agent, or the database query. In some implementations, components of the events data 202 are provided in the smallest unit of observability (e.g., for a given event type or computing environment). For instance, the event data 202 can include data elements that provide insight into the performance of the computing environment 100 to monitor, track, and triage incidents (e.g., to diagnose issues, reduce downtime, or achieve other system objectives in a computing environment”);
converting the first timestamp from the first format (Bitincka; Bitincka teaches a scheme normalization module (Fig. 2, Module 220) that ingests raw, disparate data fields form different source agents and converts conflicting data into a single unified “common schema” for shared processing;
see e.g. Column 12, Lines 5-13 ” In the example shown in FIG. 2, the observability pipeline process 200 includes a schema normalization module that (at 220) converts the various types of event data 202 to a common schema or representation to execute shared logic across different agents and data types. For example, machine data from various agents such as Splunk, Elastic, Influx, and OpenTelemetry have different, opinionated schemas, and the schema normalization module can convert the event data to normalized event data”)
displaying information related to the first message (Bitincka; Bitincka discloses a user device running a user interface that displays a visual representation of the event data flowing through the pipeline system. Under BRI, Bitincka’s “visual representation of event data” matches the functional requirement of “displaying information related to the first message”;
see e.g. Column 1, Lines 16 – 19 “... Observability pipelines may also provide monitoring and alerting functions, which allow systematic observation of data for known conditions that require specific action or attention”
see e.g. Column 8, Lines 52 - 54 “... the user interface provided by the user device 120 (e.g., through an observability pipeline application) allows users to preview ..”
see e.g. Column 15, Lines 58 – 62 “Certain aspects of running the data collection job at 338 and some of the subsequent operations in the process shown in FIG. 3A depend on whether the data collection job is being run in full run mode or preview mode. In some cases, a data collection job can be run in another mode”)
selecting a time range (Bitincka; Bitincka teaches the system utilizes an “event filter criteria” that contains a user-defined range of time. Under BRI, configuring this criteria to isolate data within specific boundaries functionally executes the claimed step of “selecting a time range”
See e.g. Column 15, Lines 41 – 57 “While running the data collection job (at 338), the observability pipeline system 310 may also provide status information to the user device 320 (at 342), which can be displayed to a user. For example, the status information can include live capture information that can be used to display a representation of event data flowing through the observability pipeline system 310. The filtered event data retrieved at 340 are the event data that meet the event filter criteria included in the configuration information provided at 336. For example, the filtered event data retrieved at 340 may have a time stamp within a time range specified by the event filter criteria; a data type or data format specified by the event filter criteria; a file name or path name that matches the event filter criteria; an error code or event type specified by the event filter criteria; a data source specified by the event filter criteria; or a combination of any of these and other properties that meet the event filter criteria.”);
comparing the first timestamp to the selected time range (Bitincka; Bitincka teaches that the retrieved event data has a “time stamp within a time range specified by the event filter criteria”. As a matter of direct common sense and basis programming logic, a software engine cannot execute a filter to identify whether a timestamp is “within a time range” without actively executing a mathematical comparison gate evaluating whether the time stamp value falls inside those boundaries . Therefore Bitincka’s filtering process explicitly teaches the claimed function of “comparing”
See e.g. Column 15, Lines 41 – 57 “... event filter criteria ...”); and
providing a first visual indication to inform a user when the first timestamp is in the selected time range (Bitincka; Bitincka teaches the observability pipeline provides for alerts based upon specific action. When an operator sets a specific “event filter criteria” including a target time range ( See e.g. Column 15, Lines 41 – 57), it would be entirely inherent and a matter of basic common sense to one of ordinary skill in the art that the system’s disclosed “alerting functions” are triggered to notify the user when an incoming record meets those criteria. Under the BRI, an “alerting function” designed to draw a user’s attention to matching data satisfies the functional requirement of “providing a first visual indication to inform a user when the first timestamp matches the selected time range” The explicit purpose of Bitincka’s alerting function is to visually flag them;
see e.g. Column 1, Lines 16 – 19 “ ... Observability pipelines may also provide monitoring and alerting functions, which allow systematic observation of data for known conditions that require specific action or attention”)
The Examiner notes that one of ordinary skill in the art is readily able to implement visualizations, indications, and/or GUIs in all types of forms and formats, as this is a mere design by optimization exercise per KSR Int’l Co. v. Teleflex Inc., 550 US 398 (2007), Per KSR, a practitioner is fully able to extend the user interface implementation to whatever needs to be done to meet the specific criteria of the design criteria.
Bitincka does not mention all types of data formats and does not expressly disclose:
converting the first timestamp from the first format to a universal format;
comparing the first timestamp in the universal format ton the selected time range;
However in analogous art Baum discloses:
a universal format (Baum;
see e.g. [0051] “... universal time ...”)
Therefore it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Baum’s format. The motivation being the combined solution provides for incorporating a known technique resulting in increased efficiencies of processing data.
Bitincka in view of Baum disclose:
converting the first timestamp from the first format to a universal format (The combined solution provides for a conversion process with respect to a universal format as taught by Baum)
comparing the first timestamp in the universal format ton the selected time range (The combined solution provides for the comparing step with respect to the universal format as taught by Baum)
Regarding claim 3, Bitincka in view of Baum disclose the method of claim 1 further comprising the steps of:
receiving a second message having a second timestamp in a second format; converting the second timestamp from the second format to the universal format;
displaying information related to the second message;
comparing the second timestamp in the universal format to the selected time range; and
providing a second visual indication to inform the user when the second timestamp is in the selected time range.
The Examiner notes that Bitincka is fundamentally directed to the event processing of multiple events. Because the primary architecture is inherently designed to continuously ingest and process a plurality of events, one of ordinary skill in the art would recognize that executing the steps of receiving, converting, displaying, and evaluating a second event or message is merely repeating the exact same functional process previously established in Independent claim 1.
Furthermore the steps illustrated above merely duplicate the sequential processing steps of independent claim 1 to accommodate a subsequent event/message. Accordingly, one of ordinary skill in the art would readily recognize that these identical operations may be executed for a second message in the exact manner as previously contemplated by Bitincka in view of Baum.
Regarding claim 8, Bitincka and in further view of Baum disclose the method of claim 2 wherein the first visual indication and the second visual indication are displayed in a single user interface (Bitincka; Bitincka teaches a modified Gantt chart which is readily available to display temporal aspects of events;
See e.g. Column 11.Lines 40 51 In some instances, traces 208 represent a series of events with a parent/child relationship. A trace may provide information of an entire user interaction and may be displayed in a Gantt-chart like view. For instance, a trace can be a visualization of events in a computing environment, showing the calling relationship between parent and child events, as well as timing data for each event. In some implementations, individual events that form a trace are called spans. Each span stores a start time, duration, and an identification of a parent event (e.g., indicated in a parent_id field). Spans without an identification of a parent event are rendered as root spans)
Regarding claim 9, claim 9 comprises the same and/or similar subject matter as claim 3 and is considered an obvious variation; therefore it is rejected under the same rationale.
Regarding claim 18, Bitincka and in further view of Baum disclose he method of claim 8 wherein the first visual indication and the second visual indication are displayed in a single user interface (Bitincka; Bitincka teaches a modified Gantt chart which is readily available to display temporal aspects of events;
See e.g. Column 11.Lines 40 51 In some instances, traces 208 represent a series of events with a parent/child relationship. A trace may provide information of an entire user interaction and may be displayed in a Gantt-chart like view. For instance, a trace can be a visualization of events in a computing environment, showing the calling relationship between parent and child events, as well as timing data for each event. In some implementations, individual events that form a trace are called spans. Each span stores a start time, duration, and an identification of a parent event (e.g., indicated in a parent_id field). Spans without an identification of a parent event are rendered as root spans)
Claims 2, 4, 6, 10 – 11, 13-14, ,17 and 20 are rejected under 35 USC 103 as being unpatentable over Bitincka and in further view of Baum and in further view of Hammel (US 20170244813)
Regarding claim 2, Bitincka and in further view of Baum disclose the method of claim 1, Bitincka does not expressly disclose wherein the first message is received from a universal armament interface bus.
Hammel discloses:
wherein the first message is received from a universal armament interface bus (Hammel;
see e,g, [0052] “... a Universal Armament Interface (UAI) ... “).
Therefore it would have been prima facie obvious to one of ordinary skill in the art before the effective fling date of the claimed invention to incorporate Hammel’s universal armament interface. The motivation being the combined solution provides for implementing a known technique resulting in increased efficiencies of processing messages.
Regarding claim 4, Bitincka and in further view of Baum and in further view of Hammel disclose the method of claim 2 wherein the first format is different than the second format (The combined solution per Bitincka as Bitincka’s normalization process is designed to operate of various data formats per independent claim 1).
Regarding claim 6, Bitincka and in further view of Baum and in further view of Hammel disclose the method of claim 4 wherein the step of selecting a time range further comprises the steps of:
selecting the first message (Bitincka; See e.g. Column 15, Lines 41 – 57); and
defining the time range based on the timestamp of the first message (Bitincka; See e.g. Column 15, Lines 41 – 57).
Regarding claim 10, claim 10 comprises the same and/or similar subject matter as claim 2 and is considered an obvious variation; therefore it is rejected under the same rationale.
Regarding claim 11, claim 11 comprises the same and/or similar subject matter as claim 4 and is considered an obvious variation; therefore it is rejected under the same rationale
Regarding claim 13, claim 13 comprises the same and/or similar subject matter as claim 6 and is considered an obvious variation; therefore it is rejected under the same rationale
Regarding claim 14, claim 14 comprises the same and/or similar subject matter as claim 13 and is considered an obvious variation; therefore it is rejected under the same rationale
Regarding claim 17, Bitincka and in further view of Baum and in further view of Hammel disclose the method of claim 14 wherein the first visual indication, the second visual indication, and the third visual indication are displayed in a single user interface (Bitincka; Bitincka teaches a modified Gantt chart which is readily available to display temporal aspects of events;
See e.g. Column 11.Lines 40 51 In some instances, traces 208 represent a series of events with a parent/child relationship. A trace may provide information of an entire user interaction and may be displayed in a Gantt-chart like view. For instance, a trace can be a visualization of events in a computing environment, showing the calling relationship between parent and child events, as well as timing data for each event. In some implementations, individual events that form a trace are called spans. Each span stores a start time, duration, and an identification of a parent event (e.g., indicated in a parent_id field). Spans without an identification of a parent event are rendered as root spans)
Regarding claim 20., Bitincka and in further view of Baum and in further view of Hammel The method of claim 17 wherein the first visual indication, the second visual indication, and the third visual indication are displayed in a single user interface and the plurality of first messages, plurality of second messages, and plurality of third messages are received from a universal armament interface bus (The combined solution per Bitincka and Hammel;
Bitincka, See e.g. Column 11.Lines 40 51 In some instances, traces 208 represent a series of events with a parent/child relationship. A trace may provide information of an entire user interaction and may be displayed in a Gantt-chart like view. For instance, a trace can be a visualization of events in a computing environment, showing the calling relationship between parent and child events, as well as timing data for each event. In some implementations, individual events that form a trace are called spans. Each span stores a start time, duration, and an identification of a parent event (e.g., indicated in a parent_id field). Spans without an identification of a parent event are rendered as root spans
Hammel;
see e,g, [0052] “... a Universal Armament Interface (UAI) ... “)).
Claim 7 is rejected under 35 USC 103 as being unpatentable over Bitincka and in further view of Baum and in further view of Hammel and in further view of Bernat (US 20230050698)
Regarding claim 7, Bitincka and in further view of Baum and in further view of Hammel disclose the method of claim 6 further comprising the steps of:
receiving a plurality of second messages (Bitincka; Bitincka per independent claim 1 provides for processes sets of event data); and
providing a second visual indication to inform the user which of the plurality of second messages has a second timestamp in the universal format in the time range (Bitincka teaches the observability pipeline provides for alerts based upon specific action. When an operator sets a specific “event filter criteria” including a target time range ( See e.g. Column 15, Lines 41 – 57), it would be entirely inherent and a matter of basic common sense to one of ordinary skill in the art that the system’s disclosed “alerting functions” are triggered to notify the user when an incoming record meets those criteria. Under the BRI, an “alerting function” designed to draw a user’s attention to matching data satisfies the functional requirement of “providing a first visual indication to inform a user when the first timestamp matches the selected time range” The explicit purpose of Bitincka’s alerting function is to visually flag them;
see e.g. Column 1, Lines 16 – 19 “... Observability pipelines may also provide monitoring and alerting functions, which allow systematic observation of data for known conditions that require specific action or attention”)
Bitincka does not expressly disclose:
receiving a plurality of second messages from the second hardware monitor
Bernat teaches:
receiving messages from the second hardware monitor (Bernat;
(Bernat;
see e.g. [0119] “... various hardware monitors ...”)
Therefore it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Bernat’s hardware monitor. The motivation being the combined solution provides for implementing a known technique resulting in increased efficiencies of acquiring event data.
Claims 5 and 12 are rejected under 35 USC 103 as being unpatentable over Bitincka and in further view of Baum and in further view of Hammel and in further view of Bernat (US 20230050698)
Regarding claim 5, Bitincka and in further view of Baum and in further view of Hammel disclose the method of claim 2 Bitincka does not expressly disclose wherein the first message is transmitted by a first hardware monitor and the second message is transmitted by a second hardware monitor.
However Bernat discloses:
wherein the first message is transmitted by a first hardware monitor and the second message is transmitted by a second hardware monitor (Bernat;
see e.g. [0119] “... various hardware monitors ...”)
Therefore it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Bernat’s hardware monitor. The motivation being the combined solution provides for implementing a known technique resulting in increased efficiencies of acquiring event data.
. Regarding claim 12, claim 12 comprises the same and/or similar subject matter as claim 4 and is considered an obvious variation; therefore it is rejected under the same rationale
Claims 15, 16, and 19 are rejected under 35 USC 103 as being unpatentable over Bitincka and in view of Baum and in further view of Hammel and in further view of Bernat and in further view of Nimmiggadda (US 20250293921)
Regarding claim 15, Bitincka and in view of Baum and in further view of Hammel and in further view of Bernat disclose the method of claim 12 wherein each of the plurality of second messages has a timestamp in the second format and further comprises the steps of:
converting the timestamp in the second format of each of the plurality of second messages to the universal format (The combined solution);
comparing the timestamp in the universal format of each of the plurality of second messages to the timestamp in the universal format of the first message (The combined solution);
The combined solution does not expressly disclose:
selecting only a one of the plurality of second messages having the timestamp in the universal format closest in time to the timestamp in the universal format of the first message to be in the selected time range.
Nimmiggadda discloses:
selecting only a one of the plurality of second messages having the timestamp closest in time to the timestamp of the first message to be in the selected time range (Nimmiggadda;
n order to provide for precise analysis, the methods described herein filter the event data 302 based on their temporal proximity and not merely on timestamp data. In one implementation, attributes of event data 302 are compared with one or more filter criteria, so as to determine whether events corresponding to the event data 302 can be grouped together. For instance, the attributes can include a preset time period window, recurring pattern thresholds, a sequence of event data 302 arrival at the system, and the like. For example, if a given set of network events occur within a given time period dictated by the filter criteria (e.g., 5 minutes), these can be grouped together. In one example, the system disregards the order of the timestamps of individual event, and only considers the window of time to filter events. In another example, if a number of recurrences of two or more events exceeds a threshold number given by the filter criteria, these events can be grouped as well. Other implementations are contemplated.)
Therefore it would have prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Nimmiggadda’s proximity based filtering. The motivation being the combined solution provides for implanting a known technique resulting in increased efficiencies of processing messages)
Bitincka and in view of Baum and in further view of Hammel and in further view of Bernat and in further view of Nimmiggadda disclose:
selecting only a one of the plurality of second messages having the timestamp in the universal format closest in time to the timestamp in the universal format of the first message to be in the selected time range (The combines solution per Nimmiggadda)
Regarding claim 16, claim 16 comprises the same and/or similar subject matter as claim 15 and is considered an obvious variation; therefore it rejected under the same rationale.
Regarding claim 19, claim 19 comprises the same and/or similar subject matter as claim 16 and is considered an obvious variation; therefore it rejected under the same rationale.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Kurtin et al., "Combining Offsets with Precedence Constraints to Improve Temporal Analysis of Cyclic Real Time Streaming Applications", April 11th, 2016, IEEE Publishing
Kurtin teaches the utilization of a Gantt chart for displaying temporal data.
Any inquiry concerning this communication or earlier communications from the Examiner should be directed to TODD L. BARKER whose telephone number is (571) 270 0257. The Examiner can normally be reached on Monday through Friday, 7:30am to 5:00pm.
If attempts to reach the Examiner by telephone are unsuccessful, the Examiner's supervisor Vivek Srivastava can be reached on (571) 272 7304.
/TODD L BARKER/Primary Examiner, Art Unit 2449
Prosecution Insights