DETAILED ACTION
This communication is in response to the Applicant Arguments/Remarks dated 3/3/2026. Claims 1-15, 21-25 are pending in the application.
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 .
Response to Arguments
Applicant's arguments filed 3/3/2026 have been fully considered.
Regarding the argument on page 12 that “The combined teachings of Miller and Kundra do not disclose at least the limitation of claim 1, "receiving a new thin event, wherein the new thin event identifies the existing thick event using a thick event identifier stored in the new thin event." Miller's table format updates (col. 24:53-67, col. 18:31-36) describe updating a table format with search results and user interactions with table formats, but do not teach thin events that contain and use a thick event identifier to establish the association. Kundra's event categorization (para. 82) similarly describes storing event categories and metadata, but does not teach a thin event storing and using a thick event identifier to identify its associated thick event as claimed”, examiner respectfully disagrees.
Specification, para. 3 discloses at para. 3: “A thick event causes selection of a content item from multiple content items for presentation to a user. A thin event may represent user interactions associated with the content item”. Thus, a user search, modify the search or interactions in relating to content items: good or services etc. are equivalent to a thin event. And a user selection (of an item of search results) is equivalent to a thick event.
Regarding the underlined, amended limitations above, please see a new combination of references with columns and lines cited below.
Specification, para. 12 teaches “A large number of events may be received over a period of 48 hours resulting in a large number of entries in the database tables”.
Regarding the argument in relating to the analyzing step,
Miller et al. teaches in fig. 6A: buttercupgames is searched in the search bar 602; an "events tab" that displays various information about events returned by the searches (equivalent to user interactions/thin events), session IDs, product ID, item ID etc.; col. 16:37-67: search screen 800 may also be utilized as part of a search interface that allows a user to modify the search query.
col. 18:46-59: a user makes a selection/thick event of one or more portions of the table format. Based on the selection, the search system causes for display one or more options (e.g., a list of options) corresponding to the selection. The search system can cause one or more commands to be added to a search query that corresponds to the set of events used to populate the table format, based on a user selecting/thick event one of the options from the list of options.
col. 24:53-67: the screen can be updated based on any changes corresponding to the selected options. For example, in search screen, when a user selects an option, the set of events utilized to populate/hydrate table format (e.g., a search results set) may be automatically updated by the operations associated with the option – equivalent to generating a distribution of thin events grouped based on the attributes of corresponding selections/thick events).
col. 71:36-45: the summary report of the numerical data type represented in column 1904b, on the other hand, depicts a distribution of values of the data items of the date event attribute over time. The values have undergone a numerical, or statistical, analysis to identify a maximum value, a minimum value, etc. of the values of the data items of the date event attribute. The cited references do teach the argued limitations.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1-15, 21-25 are rejected under 35 U.S.C. 103 as being unpatentable over Veggalam et al. (US 20230139289) in view of Miller et al. (US 11615073) and further in view of Kundra et al. (US 20190141919).
Specification, para. 3 discloses at para. 3: “A thick event causes selection of a content item from multiple content items for presentation to a user. A thin event may represent user interactions associated with the content item”.
As per claims 1, 9, 15, Veggalam et al. (US 20230139289) teaches
receiving a set of events; classifying each of the set of events based on a type of operation represented by the event as one of: a thick event including a first set of attributes that identify a content item selected by an online system for presentation to a user, or a thin event including a second set of attributes describing a user interaction with a content item associated with a thick event (para. 17: the recommendation engine utilizes big data technology to computationally analyze datasets in order to reveal patterns, trends, and associations, especially relating to human behavior and interactions /thin events with recommendations. As such, aggregating and processing events data becomes part of service management workflows. The recommendation engine trains the ML model based on past and current events data to build an ML model with a classification framework that classifies events based on attributes. The ML model can map types of events (e.g., classes) to assignment groups that can most effectively process those events; para. 40: a workflow can thus involve receiving an indication of an event, analyzing the event, and flagging the event for investigation; para. 47: the content based filtering sorts events data based on known data (e.g., content) of an item (name, location, description, etc.) rather
than patterns, behavior, etc. – content items relating to service requests; para. 57: the interface includes a recommendation section that shows attributes and values for a selected one of the events shown on the interface/ thick events);
storing data describing the set of events received; wherein at least one or more thick events are associated with a plurality of thin events; monitoring the raw event data store to detect insertion of a new thin event associated with an existing thick event, wherein the new thin event identifies the existing thick event using a thick event identifier stored in the new thin event (para. 12, 41: identify commonalities in the data and react based on the presence or absence of such commonalities in each new event identify related events that tend to occur concurrently; para. 44: processes event data stored at memory devices. Implementations can include any number of memory devices that store different types of event data; para. 62: correlate events, including use of node and connection topology to identify related events that tend to occur concurrently; para. 72: the system can cause the computing device to display, on the interface, useful information including, for example, statistical information or supporting information for the event, as illustrated in FIG. 4. The statistical information indicates … an indication whether the event needs correlation with another event. The supporting information includes links to additional information about the event which can be alternatively accepted/rejected; para. 75: the
disclosed system can tag a service request/thin event with an identifier. The identifier can include a timestamp and location data that enables tracking of the service request in a workflow. In other words, the identifier enables timely localization of the service request, which could be used to route the service request to geographically local assignment groups. As such, the system can permit remote customer support for any
system that is distributed geographically such as a telecommunications system/thick event);
in response to detecting the insertion of the new thin event associated with the existing thick event, storing the first set of attributes of the existing thick event and the second set of attributes of the new thin event as a hydrated event record in a hydrated/populated event data store different from the raw event data store (para. 16, 45: the recommendations are designed to influence whether and which of the assignment groups should respond to events, and how they should respond. The recommendation engine can also cause the system to trigger actions autonomously such as populating fields of a record for an event and initiating next actions; para. 56: automatically select the attributes and set values based on the historical information to reduce noise and improve operational efficiencies of the service management system);
Veggalam et al. does not explicitly teach a raw event data store.
Miller et al. (US 11615073) teaches
storing, in a raw event data store, data describing the set of events received, (col. 4:29-56: in the SPLUNK® ENTERPRISE system, performance data is stored as “events,” wherein each event comprises a collection of performance data and/or diagnostic information that is generated by a computer system and is correlated with a specific point in time; col. 17:7-17: one or more events can be displayed in a table format, such as table format in search screen. The table format can be employed in various interfaces for interacting with displayed events in various ways and its use is not limited to search interfaces or search screens. Events can be used to populate the table format, and may be search results, such as in search screen, but could more generally be any type of events; col. 18:31-59; fig. 6A: a list of raw events is stored including thick event/selection or thin event/interaction – See col. 10:15-45: displays an
events list that enables a user to view the raw data in each of the returned events);
Miller further teaches
wherein at least one or more thick events are associated with a plurality of thin events (fig. 6A: buttercupgames is searched in the search bar 602; an "events tab" that displays various information about events returned by the searches (equivalent to user interactions/thin events), session IDs, product ID, item ID etc.; col. 16:37-67: search screen 800 may also be utilized as part of a search interface that allows a user to modify the search query. Some exemplary options for modifying the search query include any combination of deleting commands from the search query, adding commands to the search query, reordering one or more commands in the search query, and modifying variables, parameters, arguments, and/or other properties of commands in the search query; col. 18:31-59: a user can make a selection/thick event of one or more portions of the table format. Based on the selection, the system causes for display one or more options (e.g., a list of options) corresponding to the selected one or more portions. Thus, after searches, a user select a displayed result).
monitoring the raw event data store to detect insertion of a new thin event
associated with an existing thick event, wherein the new thin event identifies the existing thick event using a thick event identifier stored in the new thin event (col. 38:54-61: as in the raw event data of event 1 in fig. 8A, any values that are extracted from events using an extraction rule may be assigned to a new or existing field of an event as data items, for example, to define a late-binding schema for events. Thus, with reference to FIG. 8A, using the extraction rule, a new event attribute (an extracted field) may be created and assigned the extracted field label "itemid" for each event, along with data items corresponding to the extracted value associated with the field label for that event; col. 50:24-29; para. 59:57-67: each event attribute displayed in the table format is loaded into the search interface. The _time and _raw attributes are displayed automatically in events list, enabling the user to view the raw event data in each of the returned events from the query with corresponding time stamps. The remaining event attributes are displayed in sidebar. This could be accomplished, for example, by loading metadata saved with respect to search screen that specifies which event attributes to display in the table format and loading those event attributes into search screen using the metadata);
in response to detecting the insertion of the new thin event associated with the existing thick event, storing the first set of attributes of the existing thick event and the second set of attributes of the new thin event as a hydrated event record in a hydrated/populated event data store different from the raw event data store (col. 24:; col. 56:10-19: the user may optionally be permitted to interact with the displayed query results corresponding to the query up to the endpoint to insert one or more commands into the query directly after the endpoint, and to insert one or more command entries that represent the one or more commands directly after the selected command entry in the command entry list; figs 20-21: in response to a user selecting an interactive region of the table, display a list of actions…add interactive regions to the table corresponding to data items of the supplemental event attribute; para. 59:57-67: each event attribute displayed in the table format is loaded into the search interface. The _time and _raw attributes are displayed automatically in events list/raw event data file, enabling the user to view the raw event data in each of the returned events from the query with corresponding time stamps. The remaining event attributes are displayed in sidebar),
analyzing hydrated event records stored in the hydrated event data store to generate a distribution of thin events grouped based on contextual attributes of
corresponding thick events (col. 18:31-36: a user can interact with one or more events of a set of events (e.g., a search result set) that are used to populate a table format by interacting with the table format. For example, a user can interact with table format, which is populated with at least some data items from events that correspond to the search result set; col. 24:53-67: the screen can be updated based on any changes corresponding to the selected options. For example, in search screen, when a user selects an option, the set of events utilized to populate/hydrate table format (e.g., a search results set) may be automatically updated by the operations associated with the option – equivalent to generating a distribution of thin events grouped based on the attributes of corresponding selections/thick events; col. 25-29: the system can cause one or more commands to be added to a search query that corresponds to a group of events used to populate the table format, based on; col. 71:36-45: the summary report of the numerical data type represented in column 1904b, on the other hand, depicts a distribution of values of the data items of the date event attribute over time. The values have undergone a numerical, or statistical, analysis to identify a maximum value, a
minimum value, etc. of the values of the data items of the date event attribute; col.75:50-67),
the contextual attributes of thick events including a content item identifier of a content item selected for presentation during a thick event, and a presentation context indicating why the content item was selected for display during the thick event (col. 42:18-24: the system receives data indicating the selection of one or more portions of data items of a set of events in a graphical interface displaying one or more events of the set of events; col. 76:36-64: once the set of events has been filtered based on the user selection, in some embodiments, the system is configured to update the summary graphs to reflect the filtered set of events. As the user successively selects summary entries, the user can gain additional insight into the data through the changes reflected in the summary graphs in response to each selection; para. 78:36-51: events are displayed in a table. For example, a search system can cause display of events that correspond to search results of a search query in a table);
generating a report based on hydrated event records stored in the hydrated event data store and the analyzing of the hydrated event records stored in the hydrated event data store, the report including at least the distribution of thin events grouped based on the contextual attributes of corresponding thick events (col. 8:39-45: the results generated by system can be returned to a client using different techniques. For example, one technique streams results back to a client in real-time as they are identified. Another technique waits to report results to the client until a complete set of results is ready to return to the client; col. 12:18-20: the summarization table can be populated by running a "collection query" that scans a set of events to find instances of a specific field-value combination; col. 17:7-19: one or more events can be displayed in a table format, such as table format in search screen. The table format can be employed in various interfaces for interacting with displayed events in various ways and its use is not limited to search interfaces or search screens. Events can be used to populate the table format, and may be search results, such as in search screen, but could more generally be any type of events/grouped. Table format comprises one or more columns, such as columns/attributes and one or more rows/records; para. 26:57-59: events may be grouped into transactions based on the values of a given event attribute; para. 70:59-64).
Thus, it would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Veggalam with the storing, in a raw event data store, data describing events received, thin event/interaction and thick event/selection of Miller to effectively allow users to store the received data for analyzing, classifying, manipulate, view, and interact with events that occurred.
Even if Veggalam and Miller do not explicitly teach storing, in a raw event data store, data describing events received,
Kundara et al. teaches said limitation at para. 82: video storage database storing raw video data associated with streaming video camera, as well as event categorization models (e.g., event clusters, categorization criteria, etc.), event categorization results (e.g., recognized event categories, and assignment of past events to the recognized event categories, representative events for each recognized event category, etc.), event masks for past events, video segments for each past event, preview video (e.g., sprites) of past events, and other relevant metadata (e.g., names of event categories, location of the cameras, creation time, duration, etc.) associated with the events; para. 107: editing event categorization results, selecting event filters; fig. 3B).
Thus, it would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Veggalam, Miller and with the storing, in a raw event data store, data describing events received, thin event/interaction and thick event/selection in order to effectively allow users to better manipulate, view, interact, and/or analyze the events.
As per claims 2, 10, 16, Veggalam teaches
wherein the new thin event is a first thin event, the method further comprising: receiving an indication of addition of a second thin event to the raw event data store (fig. 8A displays a search screen may be utilized as part of a search interface to display one or more events returned as part of a search result set based on a search query. Search screen 800 may also be utilized as part of a search interface that allows a user to modify the search query. Some exemplary options for modifying the search query include any combination of deleting commands from the search query, adding commands to the search query, reordering one or more commands in the search query, and modifying variables, parameters, arguments, and/or other properties of commands in the search query. Thus, first search is equivalent to a first thin event, additional search or modifying the first search is equivalent to the second thin event; fig. 2; col. 8:17-38.)
Veggalam does not explicitly teach the comparing step.
Miller et al. teaches
wherein the new thin event is a first thin event (col. 30:9-49: a user interaction with the command entry list may break a dependency of a command element(s) of one or more command entries, the system may automatically detect a dependency between the commands of the command entries when a user renames “referer” through interaction with the first command entry), the method further comprising: receiving an indication of addition of a second thin event to the raw event data store (col. 40:45-49: based on the prepend, the new fields generated by the autoextract command will each be assigned field labels comprising the discovered field labels prepended with “new_.” Thus, a user may easily identify the fields in a graphical interface. Therefore, automatically or repeatedly, the new field indicates an addition of an event; col. 42:18-21: the system receives data indicating the selection of one or more portions of data items of a set of events in a graphical interface displaying one or more events of the set of events);
comparing a time of creation of the second thin event with a time of creation of the first thin event; and responsive to determining that the time of creation of the second thin event is within a threshold value of the time of creation of the first thin event, determining the second thin event as invalid wherein an invalid event is not added to the record associated with the thick event (col. 52:24-26: identify one or more reference event attributes based on comparisons between event attributes of the query results and attributes defined by a data object; fig. 2: receive data, apportion data into events, determine timestamps from events, associate timestamps with events, transform events, id keywords in events, update keyword index, store events in data store; See events in fig. 6A, format timeline is 1 hour per column. Thus, within a threshold value of the time of creation of thin events is within 1 hour, if the second thin event is not within said 1 hour, said second thin event is considered invalid or not belong to said 1 hour. See the time range picker item 612; col. 7:45-65: the stored events are organized into a plurality of buckets, wherein each bucket stores events associated with a specific time range. This not only improves time-based searches, but it also allows events with recent timestamps that may have a higher likelihood of being accessed to be stored in faster memory to facilitate faster retrieval; col. 8:50-59: filtering out events that are not within the search time range thus, produce a reduced set of search results).
Thus, it would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Veggalam with the comparing a time of creation of thin events in order to identify relating user search within a search session that leads to a thick event, e.g., selection action in order to analyze, classify, view, and interact with related events.
As per claims 3, 11, 17, Veggalam does not explicitly teach said claims.
Miller et al. teaches
receiving an indication of addition of a third thin event to the raw event data store; comparing a time of creation of the third thin event with a time of creation of the first thin event (col. 38:58-62: with reference to FIG. 8A, using the extraction rule, a new event attribute (an extracted field) may be created and assigned the extracted field label “itemid” for each event, along with data items corresponding to the extracted value associated with the field label for that event; col. 40:45-49: based on the prepend, the new fields generated by the auto extract command will each be assigned field labels comprising the discovered field labels prepended with “new_.” Thus, a user may easily identify the fields in a graphical interface. Therefore, automatically or repeatedly, the new field indicates an addition of an event; col. 42:18-24: the system receives data indicating the selection of one or more portions of data items of a set of events in a graphical interface displaying one or more events of the set of events);
and responsive to determining that the time of creation of the second thin event exceeds the threshold value from the time of creation of the first thin event, determining the second thin event as valid, wherein a valid event is added to the record associated with the thick event (fig. 2: receive data, apportion data into events, determine timestamps from events, associate timestamps with events, transform events, id keywords in events, update keyword index, store events in data store; See events in fig. 6A, format timeline is 1 hour per column. Thus, within a threshold value of the time of creation of thin events is within 1 hour, if the second thin event is not within said 1 hour, said second thin event is considered invalid or not belong to said 1 hour. See the time range picker item 612; col. 7:45-65: the stored events are organized into a plurality of buckets, wherein each bucket stores events associated with a specific time range. This not only improves time-based searches, but it also allows events with recent timestamps that may have a higher likelihood of being accessed to be stored in faster memory to facilitate faster retrieval; col. 41:51-52: applying such as command to the event raw data of event attribute of events 1, 3, and 4 may extract field label-value pairs for each field label discovered therein, which may include, itemid, JSESSIONID, categoryid, productid, and action, and also might automatically assign those field label-value pairs to fields. However, the user may only be interested in itemid; para. 64: apps may give users insights into their projects via dash-boards, reports, data inputs, and search sessions (e. g., in a search interface) that work in the project environment in which they are installed).
Thus, it would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Veggalam with the adding, comparing events of Miller to effectively allow users to store the received data for analyzing, classifying, manipulate, view, and interact with events that occurred.
As per claims 4, 12, 18, Veggalam does not explicitly teach said claims.
Miller et al. teaches
storing additional attributes associated with an event in one or more database tables, wherein identifying one or more additional attributes associated with the thin event comprises joining the event attributes with the one or more database tables storing additional attributes (fig. 12F: command join with column sources: SupplementalData and Saleforce_id field; col 37:39-47; col. 51:46-52; col. 52:5-26: supplemental event attributes may be added to query results of the table format from relational database tables and/or query results. For a join, the system could analyze attribute labels of attributes (e.g., relational or late-binding) and/or values thereof (e.g., of relational values or of data items) to determine whether a particular attribute matches one or more event attributes in the query results displayed in the table format; para. 59: it is noted that at least some of the metadata of the previously saved editing session may be loaded based upon selection of the extend pipeline link. For example, the table formatting metadata can be loaded and applied to the table format; col. 62:26-34).
Thus, it would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Veggalam with the joining the event attributes of Miller to effectively allow users to store the received data for analyzing, classifying, manipulate, view, and interact with events that occurred.
As per claims 5, 13, 19, Veggalam does not explicitly teach said claims.
Miller et al. teaches
wherein the raw event data store is a key-value store, wherein each event is stored using a key associated with a thick event (fig. 2: store events in data store; col. 12:8-13: the system maintains a separate summarization table for each of the above-described time specific buckets that stores events for a specific time range, wherein a bucket-specific summarization table includes entries for specific field-value combinations that occur in events in the specific bucket; para. 37:50-53; col. 42:30-36: a user selects a cell in the table interface, which could correspond to the selection of cell 810 shown in FIG. 8B, the system could attempt to detect at least one field label-value
pair that is at least partially within the data item corresponding to cell 810. One such field label-value pair that may be detected in cell 810 has a field label of "productid" and a value of "SF-BVF-G0l."),
wherein monitoring the raw event data store comprises listening to changes to the key-value store (col. 24:57-67: the screen can be updated based on any changes corresponding to the selected options. For example, in search screen, when a user selects an option, the set of events utilized to populate table format (e.g., a search results set) may be automatically updated by the operations associated with the option. As an example, one or more portions of a search query could be executed, as needed to accurately portray events corresponding to the search query in the table format. Furthermore, the displayed table format may be automatically updated to reflect changes to the set of events; col. 37:48-67: field label-value pairs).
Thus, it would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Veggalam with the limitation: each event is stored using a key associated with a thick event of Miller to effectively allow correlating events be updated and or utilized for user to further interact, select etc. with displayed event results.
Even if Miller does not teach wherein the raw event data store is a key-value store.
Kundra teaches
wherein the raw event data store is a key-value store (para. 330: an event can be represented by a data structure that is associated with a certain point in time and comprises a portion of raw machine data (i.e., machine data). Events are described in greater detail below in conjunction with fig. 72. The event-processing system can be configured to perform real-time indexing of the machine data and to execute real-time, scheduled, or historic searches on the source data; para. 345, 1749: the events tab illustrated in fig. 81A displays a timeline graph that graphically illustrates the number of events that occurred in one-hour intervals over the selected time range. It also displays an events list that enables a user to view the raw data in each of the returned events. It additionally displays a fields sidebar that includes statistics about occurrences of specific fields in the returned events, including “selected fields” that are pre-selected by the user, and “interesting fields” that are automatically selected by the system based on pre-specified criteria).
Thus, it would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Veggalam, Miller and the raw event data store is a key-value store to effectively identify relating events, analyze, retrieve event results.
As per claims 6, 14, 20, Veggalam teaches at para. 47: the content-based filtering sorts events data based on known data (e.g., content) of an item (name, location, description, etc.) rather than patterns, behavior, etc.
Veggalam does not explicitly teach said claims.
Miller et al. also teaches
wherein a thick event causes selection of a content item from a plurality of content items (fig. 20: in response to a user selecting an interactive region of the table, display a list of options; col. 18:37-43: a user can make a selection of one or more portions of the table format. Based on the selection, the system causes for display one or more options (e.g., a list of options) corresponding to the selected one or more portions. Based on a user selecting one of the displayed options, operations corresponding to the displayed option can be carried out by the system).
Thus, it would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Veggalam, and the selection of a content item of Miller to effectively identify relating events, analyze, retrieve event results.
As per claim 7, Veggalam teaches
wherein a thin event represents a user interaction with the content item (para. 38-39: the system 200 includes modules that serve groups of users (referred to collectively as "users 202" and individually as "user 202") in an organization. The service request management module handles requests/interactions/thin events from users for information, advice, or to access a service, such as when a subscriber to a wireless telecommunications network requests an upgrade to a service for a mobile device on the network; para. 47: the content-based filtering sorts events data based on known data (e.g., content) of an item (name, location, description, etc.) rather than patterns, behavior, etc. – content items relating to service requests).
Miller et al. also teaches said limitation at col. 17:7-17: events can be displayed in a table format, such as table format in search screen. The table format can be employed in various interfaces for interacting with displayed events in various ways and its use is not limited to search interfaces or search screens. Events can be used to populate the table format, and may be search results, such as in search screen, but could more generally be any type of events.
As per claim 8, Veggalam teaches
wherein a thin event represents presenting the content item to a user via a webpage (para. 39, 47: the content-based filtering sorts events data based on known data (e.g., content) of an item (name, location, description, etc.) rather than patterns, behavior, etc. – content items relating to service requests; para. 51: an online web-based portal that can display recommendation data in visualizations or other user-friendly features that enable the assignment groups 308 to investigate or ignore events and learn procedures for efficiently advancing workflows).
Miller et al. also teaches
wherein a thin event represents presenting the content item to a user via a webpage (fig. 6A: pages of web page on the search screen; col. 16:33-37: display of an event may include display of one or more event attributes of the event, examples of which include extracted fields, metadata, event raw data, and/or other types of data items assigned to the event; col. 17:57-64).
As per claim 21, Veggalam et al. teaches
in response to detecting that a thin event is received and a corresponding thick event has not yet been received, postponing processing of the thin event until the thick event is received (para. 39-40: the system 200 includes modules that serve groups of users (referred to collectively as "users 202" and individually as "user 202") in an organization. The service request management module handles requests/interactions/thin events from users for information, advice, or to access a service, such as when a subscriber to a wireless telecommunications network requests an upgrade to a service for a mobile device on the network. The users 202 or devices select the modules to which events are routed. A workflow can thus involve receiving an indication of an event, analyzing the event, and flagging the event for investigation. Thus, the investigation is not processed until the selection is made).
As per claim 22, Veggalam et al. teaches
in response to a thin event failing to be hydrated by an event hydration module, storing the thin event in a purgatory database table; and periodically attempting to rehydrate the thin event stored in the purgatory database table (para. 17: the ML model can map types of events (e.g., classes) to assignment groups that can most effectively process those events. As such, the recommendation engine can mitigate inefficiencies due to false-positives, misclassifications (e.g., due to a lack of
classifying information), misrouting to wrong assignment groups, investigating events that are anomalous but not malicious, or failing to identify root causes of events; para. 40: a reviewer of an assignment group attempts to address issues related to the event and, if the reviewer is unable to address the issues, reroutes the event to a different assignment group where any misclassified events are rerouted to other modules or reviewers. In prior systems, this cycle continues until the event is resolved.)
Miller also teaches in fig. 6A: all events are stored in relating to all time, item 612. Thus, a new thin event that is not or failed to be populated at one time would be rehydrated by a user, scheduled, or automatically – See col. 12:18-26.
As per claim 23, Veggalam et al. teaches
providing the hydrated event records stored in the hydrated event data store as training data for training a machine learning model, wherein the machine learning model predicts a score representing a likelihood of a particular user interacting with a content item if presented with the content item (para. 12: the ML algorithm of the recommendation engine can build the ML model based on the event data, configured as training data, in order to make predictions or decisions without being
explicitly programmed to do so. In some examples, the ML training involves assigning weights for a classification framework to identify and/or discover classifications and
attributes for events; para. 18, 44, 59: the ML algorithms are trained based on past resolutions to predict the cause of an event, which enables routing of the event to the
most suitable assignment group).
As per claim 24, Veggalam et al. teaches
receiving an out-of-order event having a timestamp preceding a previously processed event, and responsive to receiving the out-of-order event, recomputing validation status for a subset of events associated with the out-of-order event (para. 17-18: the ML model can map types of events (e.g., classes) to assignment groups that can most effectively process those events. As such, the recommendation engine can mitigate inefficiencies due to false-positives, misclassifications (e.g., due to a lack of classifying information), misrouting to wrong assignment groups (out of order events), investigating events that are anomalous but not malicious, or failing to identify root causes of events. If a reviewer accepts a recommendation for a 3 second delay and rejects other recommendations, the accepted recommendation is associated
with a greater weight compared to the rejected recommendations/validation status; para. 56-58: examples of attributes include a time delay, view type, or alarm behavior in general. The time delay can be set to a numerical value (e.g., I hour, 15 minutes, 5
minutes), the view type can be set to one of multiple types (e.g., impacted, non-impacted). The attribute of the problem includes a time delay/delayed events. A reviewer can manually select a checkmark or "X" of an attribute to accept or reject, respectively, the attribute and/or its value).
As per claim 23, Veggalam et al. teaches
sorting the set of events by their respective timestamps; and invalidating each event that occurs within a threshold time interval of a prior event in the set of events (para. 47: The collaborative filtering sorts events data having similar characteristics into respective groups, which can be used as training data for the ML model. The content-based filtering sorts events data based on known data (e.g., content) of an item (name, location, description, etc.) rather than patterns, behavior, etc.; para. 75).
Veggalam does not explicitly teach performing sessionization of a set of events associated with a thick event.
Miller teaches at col. 10:15-45: the user can select a specific time range, or alternatively a relative time range, such as "today," "yesterday" or "last week." For "real-time searches," the user can select the size of a preceding time window to search for real-time events; fig. 6A: buttercupgames is searched in the search bar 602; an "events tab" that displays various information about events returned by the searches (equivalent to user interactions/thin events), session IDs, product ID, item ID etc.; col. 41:51-52: applying such as command to the event raw data of event attribute of events 1, 3, and 4 may extract field label-value pairs for each field label discovered therein, which may include, itemid, JSESSIONID, categoryid, productid, and action, and also might automatically assign those field label-value pairs to fields. However, the user may only be interested in itemid; para. 64: apps may give users insights into their projects via dash-boards, reports, data inputs, and search sessions (e. g., in a search interface) that work in the project environment in which they are installed; para. 59: it is noted that at least some of the metadata of the previously saved editing session may be loaded based upon selection of the extend pipeline link. For example, the table formatting metadata can be loaded and applied to the table format.
Thus, it would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Veggalam, and the performing sessionization of a set of events associated with a thick event of Miller in order to display to the user a list of events corresponding to the selection/thick event.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Rathod (US 20180350144) teaches at para. 124: identify particular real world object's details and associated one or more types of contents from one or more sources, based on scanning of purchase receipt identify purchasing of one or more products or services, wherein sufficiently matching date and time of augmented reality scanning or taking a photograph of receipt of purchase of one or more products and services in real world with server's current date and time.
Hon et al. (US 20100185733) teaches at para. 106-107: an output device 1615 for selective audio visual presentation of said content based upon a user, media-layer events, time and command.
Baranczyk et al. (US 20170132286) teaches at para. 44: the database management system detects a triggering event. Detecting can include receiving (e.g., from a user, from an application), sensing (e.g., in a multidimensional array, in an application), o bserving (e.g., based on usage/utilization). The triggering event may include achieving a temporal criterion (e.g., a time-to-live, an expiration date/time for a hint/query, an on-peak/off-peak period, a usage time etc.)
Fletcher et al. (US 20170046127) teaches at para. 650-651: user interaction with bulk action element 17654 is shown as a drop-down selection box. User interaction with bulk action element 17654 may result in the appearance of a drop-down selection list of available bulk actions from which a user may make a selection.
THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to LINH BLACK whose telephone number is (571)272-4106. The examiner can normally be reached 9AM-5PM EST M-F.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Tony Mahmoudi can be reached on 571-272-4078. 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.
/LINH BLACK/Examiner, Art Unit 2163 6/10/2026
/TONY MAHMOUDI/Supervisory Patent Examiner, Art Unit 2163
Prosecution Insights