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 .
Remarks
The present application having Application No. 18/427,956 filed on 01/31/2024 presents claims 1-20 for examination.
Examiner Notes
Examiner cites particular columns and line numbers in the references as applied to the claims below for the convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references in entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the examiner.
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 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.
Drawings
The applicant’s drawings submitted are acceptable for examination purposes.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 1 recites the limitation "the stored time-series data" in line 8. There is insufficient antecedent basis for this limitation in the claim. It is not clear whether “timestamp data” stored in the time-series data structure or “the time-series data structures” is being used/referred to obtain a count value.
Claim 8 recites the limitations “the memory” in line 4; and "the stored time-series data" in line 11. There are insufficient antecedent basis for these limitations in the claim. It is not clear whether “timestamp data” stored in the time-series data structure or “the time-series data structures” is being used/referred to obtain a count value. In line 4, “the memory” should be changed to “the one or more memories” for clarity and consistency.
Claim 15 recites the limitation "the stored time-series data" in line 8. There is insufficient antecedent basis for this limitation in the claim. It is not clear whether “timestamp data” stored in the time-series data structure or “the time-series data structures” is being used/referred to obtain a count value.
The dependent claims 2-7, 8-14 and16-20 are also rejected based on virtue of their dependencies to base claims 1, 8 and 19, respectively.
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 of this title, 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, 5-10, 12-17, 19 and 20 are rejected under AIA 35 U.S.C. 103 as being unpatentable over Fischbeck et al. (US 2024/0143419 A1) (hereinafter Fischbeck) in view of Castagna et al. (US 2018/0167441 A1) (hereinafter Castagna).
As per claim 1, Fischbeck discloses A method (e.g. Fischbeck: [0024] discloses specification includes methods and systems for detecting and managing events/alarms. [0024-0025, 0037, 0064-0069, 0071-0075] discloses method/system for detecting an event, extracting event data, creating an event signature, tracking event instances over time and classifying event as noisy/flapping. Also see [Abstract] [0004-0015] [Fig. 3] [0087].) comprising: associating a definition of a cached variable with an event management orchestration, wherein the definition identifies the cached variable as a counter of events that meet predefined criteria (e.g. Fischbeck [0027-0035] [0067-0075]: Fischbeck teaches that the NMS can receive events, “classify specific events as noisy/flapping when their frequency meets and/or exceeds a specified frequency threshold,” and “prevent processing of events that have been classified as noisy/flapping.” Functionally, this is event-management orchestration in the sense that the NMS coordinates how events are handled based on stored event-history data and threshold logic, even though it does not use that exact label. Fischbeck further teaches that “the event history can be a count…of how many times that event signature has been encountered by the NMS,” and that “the counter value can specify the magnitude of detected events represented by the corresponding hash value,” which maps to the claimed cache variable defined as a counter of events meeting predefined criteria.); associating a time-series data structure with the cached variable (e.g. Fischbeck [0067-0069] [0078-0081]: Fischbeck teaches a “time log structure” that “uses a series of timestamps from which the number of instances of an event over a given time period can be derived,” and explains that timestamps are stored in associated with the event signature. This teaches the claimed time-series data structure associated with the cached variable.); storing timestamp data in the time-series data structure based on received events that meet the predefined criteria (e.g. Fischbeck [0079-0081] [0126]: Fischbeck teaches when the event signature is no already in the time log structure, the NMS adds the event signature and “adds the timestamp corresponding to the first instance of the event signature,” and that later matching instances add additional timestamps. This discloses storing timestamp data in the time-series data structure based on received event meeting the tracking criteria.); and using the stored time-series data to obtain a count value of the cached variable, wherein the count value is used by the event management orchestration to determine a processing or a subsequent event to the received events (e.g. Fischbeck [0033-0036] [0068-0069] [0076-0077]: Fischbeck discloses that the NMS can “count the number of timestamps stored” for a particular event identifier, determine whether the count meets the threshold, and then either classify the vent as noisy/flapping and exclude it from further processing or continue processing it. This teaches using stored time-series data to obtain a count value and using that count value to determine who the received event is processed.).
As discussed above, Fischbeck discloses performing same functions as the claimed event management orchestration because it tracks event frequency, classifies events based on threshold counts / timestamps, and then determines whether to exclude event prom processing or continue processing the event. Fischbeck teaches that the NMS detects an event, creates an event signature, tracks instances in a time log structure, classifies event as noisy/flapping when the threshold is met. Fischbeck also describes implementing tracking “at a front end of an event processing pipeline” so later processing is not performed. That is the functional role the claim assigns to the event management orchestration, but Fischbeck does not expressly discloses an event management orchestration.
However, Castagna discloses associating a definition of a cached variable with an event management orchestration (e.g. Castagna teaches this limitation because the reference discloses an event orchestration computing platform configured to orchestrate event through event protocols, where “each type of event may be associated with an event protocol comprising a specific sequence of sub-events, and different rules and/or parameters for the event and/or one or more sub-event of the event,” and those protocols are stored in an event database (paragraph [0026]). Castagna further discloses that the event orchestration database stores information used by the orchestration module, including “one or more event customized datasets and one or more master event datasets,” which is the claimed stored/cached event variable (paragraph [0033). Castagna also discloses that the first event request includes event-specific parameters, including “an event type parameter,” “an event date parameter,” and “an event occurrence parameter,” and that the event type is determined by “extracting the event type parameter from the received event request,” showing that the orchestration uses event-associated data (paragraph [0034] [0036]). Castagna additionally discloses that the platform sends command to generate “a master event dataset from the first event,” and that the commands are based on “a first framework for the event master dataset specified in the first event protocol,” which ties the stored dataset directly to the orchestration logic (paragraphs [0038] [0040]). Also see paragraphs [0046, 0065, 0071]. Accordingly, Castagna teaches that the cached/stored variable is the event-specific dataset maintained in the orchestration database and used throughout the event protocol-driven orchestration process.).
Castagna expressly teaches multicomputer processing of an event request with event orchestration, including receiving an event request, determining a sub-event, receiving a dataset associated with the event, generating orchestration commands, sending the dataset and command to a sub-event processing device, receiving results, and updating event dataset (See paragraphs [003-005, 0024-0027, 0034-0037, 0054-0057; Figs 2A-2H, 5 and related descriptions].).
Fischbeck and Castagna both teach event-based data handling and controlling downstream processing based on stored event-related information/parameters. Fischbeck teaches storing event history, counts, and timestamps to decide whether to process or exclude an event, while Castagna teaches receiving event requests, customized dataset associated with the event, orchestration commands, and updating dataset based on results. These overlapping teaching support combining the references to manage events more efficiently and in a more structured manner.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Castagna with Fischbeck because Fischbeck teaches a threshold-based event tracking mechanism, while Castagna teaches a structured orchestration framework for coordinating event execution across systems. Incorporating Castagna’s orchestration flow into Fischbeck’s event-frequency tracking would have predictably improved event management by allowing orchestrated processing decision to be driven by tracked counts and timestamps.
As per claim 2, the combination of Fischbeck and Castagna discloses The method of claim 1 [See rejection to claim 1 above], wherein storing the timestamp data in the time-series data structure based on the received events that meet the predefined criteria (e.g. Fischbeck [0079-0081] [0126]: Fischbeck teaches when the event signature is no already in the time log structure, the NMS adds the event signature and “adds the time stamp corresponding to the first instance of the event signature,” and that later matching instances add additional timestamps. This discloses storing timestamp data in the time-series data structure based on received event meeting the tracking criteria. [0078] states that “the time log structure logs the individual timestamps for the different instances of the event signature,” and [0080] states that when the NMS encounters a given signature, it adds “the timestamp corresponding to the first instance of the event signature” to the time log structure. [0081] further states that “when each subsequent instance of a particular event signature is encountered,” the NMS adds the corresponding timestamp to the time log structure. [0082-0084] explain that the timestamps are used within specified time/tracking period to determine whether the event meets the noisy/flapping criteria. Also see [0032-0034] [0049] [0067-0069] [Fig. 2] [0071-0084].) comprises: identifying the event management orchestration in response to a received event (e.g. Castagna expressly discloses receiving and event and then identifying the orchestration flow for that event. Castagna [0034] states the platform “may receive a first event request for a first event,” and [0041] the platform “may determine a first sub-event associated with the first event.” Castagna [0026] also states that each event type is associated with “an event protocol comprising a specific sequence of sub-events.” That is event management orchestration framework referenced in the claim.); prior to processing the received event via the event management orchestration: determining that the cached variable is referenced in the event management orchestration (e.g. Castagna’s sequence is explicitly pre-processing before execution: it receives the event request, determines the event type, determines sub-events, sends orchestration commands and customized dataset, then receives the results and updates the dataset (paragraphs [0034, 0041-0042). Paragraphs [0044-0046] disclose that actual processing occurs later when the sub-event processor executes the sub-event and returns results. Fischbeck: teaches that the system searches the tracking structure for the event signature and then uses the stored counter/timestamp entry when a match is found. Fischbeck [0071] states the NMS “can search the counter structure 208 to determine whether the counter structure includes an entry matching the event signature,” and [0079-0081] similarly describe searching the time log structure and adding entries for the event signature.); and obtaining the count value of the cached variable (e.g. Fischbeck expressly teaches count-based tracking. Fischbeck [0068] states that “the counter value can specify the magnitude of detected events represented by the corresponding hash value,” and [0075] states that “the counter structure 208 also has counter values indicating that Hash_1 has been encountered 8 times,” etc. Fischbeck [0072-0074] explain that the counter is incremented during the tracking period, and [0076] uses that count to determine noisy/flapping event.); processing the received event via the event management orchestration (e.g. Castagna expressly discloses processing the event through orchestration. Castagna [0042] states the platform sends commands instructing the customization engine to generate a customized dataset for the sub-event, [0043] states the platform sends the customized dataset and orchestration commands to the sub-event processor, [0045] the platform receives a results, and [0046] updates the master event dataset based on the results. These steps constitute as processing the event via the event management orchestration.); and after processing the received event, updating the time-series data structure based on the received event (e.g. Castagna [0043] states the platform sends the customized dataset and orchestration commands to the sub-event processor, [0045] the platform receives a results, and [0046] updates the master event dataset based on the results. Fischbeck teaches updating the time log/tracking data structure after subsequent matching evens are encountered. Fischbeck [0081] states that when each subsequent instance of a particular event signature is encountered, the NMS adds the timestamp corresponding to that instance to the time log structure. Fischbeck [0082-00084] further teach using the tracked timestamps to update the reference timestamp and count status within the tracking period.).
As per claim 3, the combination of Fischbeck and Castagna discloses The method of claim 2 [See rejection to claim 2 above], further comprising: storing, in another cached variable, textual data extracted from the received event prior to processing the received event via the event management orchestration (e.g. Fischbeck [Abstract] [0004] discloses two or more fields of event data of the event are extracted and an event signature that represents characteristics of the event is created using the two or more fields of event data. Fischbeck teaches extracting multiple event data fields before downstream processing. Fischbeck [0064] states that the NMS “extracts the Event Type field, Device field, and entity field from the event data 202 to create a set of extracted event data 204.” Fischbeck [0066] additionally discloses that the NMS “creates the event signature 206 by concatenating the event type, device identifier, and entity information…and inputting the concatenated information to a hash function,” with the output being a string of characters that uniquely identifies the event characteristics. Fischbeck also teaches storing event-driven values in a data structure before later handling. Fischbeck [0067] states that once the event signature is created, the NMS “can keep track of event frequency by storing the event signature and frequency information in a data structure.” Fischbeck [0068] explains that the counter structure uses “a counter and a reference timestamp,” and that the time log structure uses “a series of timestamps,” with each entry having corresponding data used to determine frequency. Fischbeck [0071] further states that the NMS searches the counter structure for the event signature, and if not match is found, “can create an entry in the counter structure” and enter the hash value into the “Event ID” column. These disclosure teach storing extracted event-derived information in a cached or tracked variable-like entry before later event handling. Also see [Fig. 2] [0090-0091] [0094]. Castagna: reinforces that the extracted event information is stored and used before orchestration processing. Castagna [0034] states that the computing platform may “received…an event request for an event” and “determine a sub-event associated with the event.” [0036] discloses event orchestration computing platform determines the event type of the first event by extracting the event type parameter form the received event request. [0043] further states that the event dataset customization engine may generated the customized dataset “by extracting the requested first subset of data from the first event master dataset generated for the first event.” [0071] state that if updated values are received, the platform may “replace the current values of these parameters in the second event master dataset with the updated values” and “add these new parameters and values to the second event master dataset.” Accordingly, Fischbeck teaches extracting event text fields and storing derived event identifier, counters, and timestamps in a data structure, while Castagna teaches extracting even-related parameters and maintaining them in a master dataset before orchestration.).
As per claim 5, the combination of Fischbeck and Castagna discloses The method of claim 3 [See rejection to claim 3 above], Fischbeck further discloses wherein the textual data are extracted from a payload of the received event (e.g. Fischbeck: [0049] discloses “the event data 202 can be generated in an XML or JSON format that the NMS 112 is capable of reading and parsing…The event data can be structured, for example, such that different characteristics of the event are contained in different fields of the event data 202.” [0050-0055] event data includes various fields related to the event. [0064] discloses “NMS extracts information from at least some of the fields of the event data” or “can extract all of the information from the fields of the event data, or extract information from fewer than all of the fields of the event data.” [0090-0091] discloses extracting fields of event data corresponding to the event, the event data can be in an XML format, JSON format or another format. The received event data in XML/JSON format constitutes as the event’s payload.).
As per claim 6, the combination of Fischbeck and Castagna discloses The method of claim 3 [See rejection to claim 3 above], wherein the textual data are extracted from metadata associated with the received event (e.g. Fischbeck: [0049] “the event data can be generated in an XML or JSON format that the NMS is capable of reading and parsing. [0050-0054] For example, the event data is shown to include the following: Date-Time: 10_21_22,0835, Event Type: Loss-of-signal, Device: Device_A_ID, Entity: eth 1, Sequence No.: 12345. [0055-0063] further discloses these fields can specify any information related to events in the event data. These are event-describing fields that can reasonably be treated as metadata under the applicant’s broad description. [0064] “The NMS extracts information from some of the fields of the event data 202 to create a set of extracted event data 204.” [0064-0066] For example, NMS extracts Event type, Device and Entity form the Event Type field, Device field, and Entity field, respectively; and creates event signature using the extracted data. This shows the system parses and extracts textual data from the fields [metadata] of event data. Thus, Fischbeck’s event fields constitute metadata associated with the received event, and Fischbeck therefore teaches extracting textual data form metadata associated with the event.).
As per claim 7, the combination of Fischbeck and Castagna discloses The method of claim 2 [See rejection to claim 2 above], wherein updating the time-series data structure based on the received event comprises: updating the time-series data structure based on a time window included in the definition (e.g. Fischbeck [0078-0084] expressly teaches updating a time log structure based on the number of timestamp stored for a given event signature, including removing timestamps outside a specified time period and updating the classification of the event based on the updated timestamp set. [0011-0013] “method can include the actions of determining that a given timestamp corresponding to a given subsequent hash is more than a specified amount of time after a reference timestamp corresponding to entry; and updating the reference timestamp…removing one or more timestamps that are more than a specified amount of time prior to a current time” Fischbeck therefore teaches updating the time-series data structure based on a time window ([0082-0084]). Castagna provides the surrounding event orchestration context and teaches that event definitions and protocols govern orchestration behavior, including the use of event parameters and frameworks tied to event type (Castagna: [0034-0040, 0041-0046]).
As per claims 8-10 and 12-14, these are system claims having similar limitations as cited in method claims 1-3 and 5-7, respectively. Thus, claims 8-10 and 12-14 are also rejected under the same rationale as cited in the rejection of rejected claims 1-3 and 5-7.
As per claims 15-17, 19 and 20, these are computer readable storage media claims having similar limitations as cited in method claims 1-3, 5 and 6, respectively. Thus, claims 15-17, 19 and 20 are also rejected under the same rationale as cited in the rejection of rejected claims 1-3, 5 and 6, respectively.
Claims 4, 11 and 18 are rejected under AIA 35 U.S.C. 103 as being unpatentable over Fischbeck in view of Castagna and further in view of Oliner et al. (US 2021/0110062 A1) (hereinafter Oliner).
As per claim 4, the combination of Fischbeck and Castagna discloses The method of claim 3 [See rejection to claim 3 above], but does not expressly disclose wherein the textual data are extracted from the received event based on a regular expression.
However, Oliner expressly discloses wherein the textual data are extracted from the received event based on a regular expression (e.g. Oliner: [0074] states that fields are defined by extraction rule (e.g., regular expressions) that derive one or more values from the data in each event. [0075] discloses that “an extraction rule comprises a regular expression” (regex rule) and that “the system applies the regex rule to the event data to extract values for associated fields in the event data by searching the event data for the sequence of characters defined in the regex rule. Also see [0115] [0133] [0244] [0283].).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Oliner with Fischbeck and Castagna because Oliner teaches using regular expressions as extraction rules to derive/extract field values form raw machine data, including applying regex rules at search or ingestion time to flexibly extract event fields from variably formatted data. Fischbeck already teaches extracting event fields from event data to create an event signature and storing the event-derived information in a data structure, while Castagna teaches using extracted event information in an orchestration workflow to determine sub-events and update event datasets. Combining Oliner’s regex-based extraction with Fischbeck and Castagna would have been a predictable use of known techniques to improve extraction flexibility and event processing efficiency, consistent with KSR.
As per claim 11, this is a system claim having similar limitations as cited in method claim 4. Thus, claim 11 is also rejected under the same rationale as cited in the rejection of rejected claim 4.
As per claim 18, this is non-transitory computer readable media claim having similar limitations as cited in method claim 4. Thus, claim 18 is also rejected under the same rationale as cited in the rejection of rejected claim 4.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Hiren Patel whose telephone number is (571) 270-3366. The examiner can normally be reached on Monday-Friday 9:30 AM to 6:00 PM.
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) Form at https://www.uspto.gov/patents/uspto-automated- interview-request-air-form.
If attempts to reach the above noted Examiner by telephone are unsuccessful, the Examiner’s supervisor, April Y. Blair, can be reached at the following telephone number: (571) 270-1014. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from Patent Center and the Private Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from Patent Center or Private PAIR. Status information for unpublished applications is available through Patent Center or Private PAIR to authorized users only. Should you have questions on access to Patent Center or the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
June 22, 2026
/HIREN P PATEL/Primary Examiner, Art Unit 2196
Prosecution Insights