Prosecution Insights
Last updated: April 19, 2026
Application No. 18/332,466

TECHNIQUES FOR MANAGING VIEWS OF TIME-SERIES BASED EVENT DATA

Non-Final OA §103
Filed
Jun 09, 2023
Examiner
LABOGIN, DORETHEA L
Art Unit
3624
Tech Center
3600 — Transportation & Electronic Commerce
Assignee
Microsoft Technology Licensing, LLC
OA Round
3 (Non-Final)
14%
Grant Probability
At Risk
3-4
OA Rounds
3y 11m
To Grant
30%
With Interview

Examiner Intelligence

Grants only 14% of cases
14%
Career Allow Rate
24 granted / 172 resolved
-38.0% vs TC avg
Strong +16% interview lift
Without
With
+16.2%
Interview Lift
resolved cases with interview
Typical timeline
3y 11m
Avg Prosecution
36 currently pending
Career history
208
Total Applications
across all art units

Statute-Specific Performance

§101
41.2%
+1.2% vs TC avg
§103
39.3%
-0.7% vs TC avg
§102
13.0%
-27.0% vs TC avg
§112
5.7%
-34.3% vs TC avg
Black line = Tech Center average estimate • Based on career data from 172 resolved cases

Office Action

§103
DETAILED ACTION Status of the Application This Non-Final Office Action is in response to Application Serial 18/332,466. Claims 1 3,5-10, 12-17, &19-21 are pending. In response to Examiner’s action mail dated, October 01, 2025, Applicant submitted argument and amendments mail dated January 2, 2026. Applicant cancelled claims 4, 11, and 18. Applicant amended claims 1, 8, and 15. Applicant added new claim 21. 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 . 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. Continued Examination Under 37 CFR 1.114 A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on January 02, 2026 has been entered. Information Disclosure Statement The information disclosure statements (IDS) submitted on January 02, 2026 and January 30, 2026 is/are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner. Response to Amendments Claims 1 3,5-10, 12-17, &19-21 are pending in this application. Regarding the 35 U.S.C. 101 rejection. The claims are examined under 35 U.S.C. 101 in light of 2019 Revised PEG Guidance. The Applicant’s arguments and amendments are persuasive. The pending 35 U.S.C. 101 is withdrawn. Regarding the pending 35 U.S.C. 103 rejection. The Applicant’s arguments and new claims were examined in light of 35 U.S.C. 103. The claims 1 3,5-10, 12-17, &19-21 are rejected under 35 U.S.C. 103, see below. Response to Arguments Applicant’s arguments filed on January 2, 2026, have been fully considered but they are not persuasive and/or are moot in view of the revised rejections. Applicant’s arguments will be addressed herein below. Rejections Based on 35 U.S.C. 101 On pages 7-10 of the Applicant’s 35 U.S.C. 101 arguments, Applicant traverses, Claim 1 (and similarly claims 8 and claim 15), as amended, recites in part amendments. The claims require a hot row store and a cold row store, and further storing an event in the hot row store , which can not be abstract. Applicant submits, even if the claims are viewed as directed to an abstract idea, which is not admitted and is traversed, the claims are integrated into a practical application in compliance with Step 2A. Turning to Step 2B, even if the claims could be considered to include an abstract idea, the claims certainly amount to significantly more than the abstract idea itself. Applicant submits independent claims 1, 8 and 15, and associated dependent claims, when taken as a whole recite an inventive concept that qualifies as significantly more. Applicant contends that the claims are directed to subject matter that is patent eligible under 35 U.S.C. 101. Accordingly, Applicant requests that the rejection of claims 1-3, 5-10, 12-17, 19 and 20, under 35 U.S.C. 101 be withdrawn. Examiner finds Applicant’s amendments persuasive. Examiner analyzed the amended claims under 35 U.S.C. 101. At Step 2A prong one, the claims are identifying a … an event data field of the plurality of event data fields; and data is store temporarily or longer term. Examiner submits the claims are recite mental concepts – evaluation and observation. The claims recite a mental concept and therefore are directed to a judicial exception at Step 2A prong one. At Step 2A prong two, the claims are integrated into a practical application. The claims are evaluated to determine if the additional elements are integrated into the judicial exception. The claims are evaluated for an improvement. The claims recited additional elements “a discoverable event stream”, “the discoverable event stream stores event data including multiple instances of events received from multiple objects in a single stream”, “a hot row store”, “a remaining portion of the event data in a cold row store”. In light of Parikh (US 11,818,156 B1) (disclosing datalakes) and the Applicant’s claims. Examiner submits the claims are integrated into a practical application. Examiner withdraws the 35 U.S.C. 101 rejection. Rejections Based on 35 U.S.C. 103 On pages 10-11 of the Applicant’s arguments, Applicant traverses the pending 35 U.S.C. 103 argument. Penchikala, Park, and Muddu, when taken alone or in combination, fail to disclose or suggest all aspects recited in the subject claims. Examiner acknowledges the Applicant’s 35 U.S.C. 103 arguments. The Applicant’s amendments necessitates grounds for a new rejection. See prior art rejection below. 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. The text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action. The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows: 1. Determining the scope and contents of the prior art. 2. Ascertaining the differences between the prior art and the claims at issue. 3. Resolving the level of ordinary skill in the pertinent art. 4. Considering objective evidence present in the application indicating obviousness or nonobviousness. Claim(s) 1-3, 5, 7-10, 12-17, & 19-21 is/are rejected under 35 U.S.C. 103 as being unpatentable over Danilov (US 2023/0,048,668 A1) in view of Yuan (US 11,269,808 B1). Regarding Claim 1,(Currently Amended) Danilov teaches: A method comprising: receiving a first event of a discoverable event stream, the first event including a plurality of event data fields representing an occurrence of the first event, wherein the discoverable event stream stores event data Danilov [015] teaches conventional event stream storage techniques, for example, can result in storage of many events objects in a stream. Danilov [016] discuss an ordered event stream (OES) that stores events. PNG media_image1.png 718 663 media_image1.png Greyscale including multiple instances of events received from multiple objects in a single stream ordered by time, and wherein the discoverable event stream stores a portion of the event data … Danilov [019] discloses an OES can comprise one or more stream segments. A segment of an event stream can generally be associated with a single processing instance to assure ordering of the events logically added to the segment. A processing instance can be a single real physical processor, a virtualized processor executing on one or more real physical processors, a group of real physical processors, a group pf virtual processors executing on one or more real physical processors, etc. As an example, a processing instance can be a blade server of a rack system. As another example, a processing instance can be a virtual processor deployed in an elastic computing system, e.g., a ‘cloud server,’ etc. Danilov [020] discloses an OES can be comprised of one or more portions, e.g., segments, shards, partitions, pieces, etc., that can generally be referred to as segments for convenience, a segment of an OES can act as a logical container for one or more events within the OES. When a new event is written to a stream, it can be stored to a segment of the stream based on a corresponding event routing key. Danilov [026] discloses ] FIG. 1 is an illustration of a system 100, which can facilitate retention of an event of a segment of an ordered event stream, in accordance with aspects of the subject disclosure. System 100 can comprise a storage component 102 that can store an ordered event stream (OES) 110, 111, etc., which can store representations of, reference to, etc., one or more events. , Danilov [026], [Figure 1]. PNG media_image2.png 743 564 media_image2.png Greyscale identifying a discoverable event stream view associated with an event data field of the plurality of event data fields; Danilove [058 ], [Figure 7] teaches method 700, which can facilitate retention of one or more batches of events of one or more segments of one or more ordered event streams. Danilove [0059] at 720, method 700 can comprise determining a first count of one or more retention windows that have not elapsed. The one or more retention windows can correspond to the first batch of events. generating, based on modifying a field name or applying a function to a field value of the event data field, a second event of the discoverable event stream view, wherein generating the second event of the discoverable event stream view comprises dropping the event data field from the plurality of event data fields as represented in the second event; Danilove [Figure 7], [060] teaches at 730, method 700 can comprise determining a second count of one or more retention windows that have not elapsed. These one or more retention windows can correspond to the second batch of events. storing, based on detecting an upcoming query for the discoverable event stream view to be executed within a period of time from a current time, … of the discoverable event stream; Danilove [Figure 7], [061] teaches in both 720 and 730, a triggered retention window can be affirmatively triggered, e.g., an occurrence can trigger activation of the triggered event window, or can be negatively triggered, e.g., lack of an occurrence triggers the activity. Although highly suggested, Danilove does not explicitly teach: … in a hot row store and a remaining portion of the event data in a cold row store … the second event in the hot row store …and displaying, via an interface and based on performance of the upcoming query, the discoverable event stream view including the second event. Yuan teaches: … in a hot row store and a remaining portion of the event data in a cold row store;… applying a function to a field value of the event data field … the second event in the hot row store … and displaying, via an interface and based on performance of the upcoming query, the discoverable event stream view including the second event. Yuan [column 22 lines 6-34] teaches storing events in buckets for specific time ranges, an indexer may further optimize the data retrieval process by searching buckets corresponding to time ranges that are relevant to a query … The home directory of an indexer stores hot buckets and warm buckets, and the cold directory of an indexer stores cold buckets. A hot bucket is a bucket that is capable of receiving and storing events. A warm bucket is a bucket that can no longer receive events for storage but has not yet been moved to the cold directory. A cold bucket is a bucket that can no longer receive events and may be a bucket that was previously stored in the home directory. Yuan [column 68 all] discloses in the situation in which the first instance of the persistent queue (or any component of the data pipeline queues 2102 or the indexer 206) is unable to complete the indexing process for a particular block of ingested data, the identifier assigned to that block of ingested data will not be received by the tube 2204.sub.2. Following expiration of a predetermined time after receipt of the block of ingested data, if the identifier assigned to the block of ingested data is not be received, the recovery thread 2410 moves, or causes movement of, the block of ingested data from the tube 2204.sub.3 to the tube 2204.sub.2 so that it may be provided to the data pipeline queues 2102 again. The predetermined time may be configurable via input from an administrator or other use. Yuan [Figure 24], [Figure 25], [column 68 all]. Yuan [column 9 lines 56-60] discloses the custom monitoring code may be incorporated into the code of a client application 110 in a number of different ways, such as the insertion of one or more lines in the client application code that call or otherwise invoke the monitoring component 112. As such, a developer of a client application 110 can add one or more lines of code into the client application 110 to trigger the monitoring component 112 at desired points during execution of the application. Within claim 1, Yuan discloses adding more lines of code to a client application to invoke a monitoring component 112, and thus, Yuan discloses applying a function to a field value of the event. Claim 1 a "Markush" claim recites a list of alternatively useable members. In re Harnisch, 631 F.2d 716, 719-20, 206 USPQ 300, 303 (CCPA 1980); Ex parte Markush, 1925 Dec. Comm'r Pat. 126, 127 (1924). The listing of specified alternatives within a Markush claim is referred to as a Markush group or a Markush grouping. Abbott Labs v. Baxter Pharmaceutical Products, Inc., 334 F.3d 1274, 1280-81, 67 USPQ2d 1191, 1196 (Fed. Cir. 2003) (citing to several sources that describe Markush groups)- See MPEP 706.03. Regarding Claim 2, (Original) [and similarly claims 9 and claim 16] The method of claim 1, wherein the event data field is a first event data field, and generating the second event of the discoverable event stream view comprises performing one or more functions on the first event data field to generate a second event data field of the second event of the discoverable event stream view. See Danilove Claim 1 – Figure 1 and the associated text. Regarding Claim 3, (Previously Presented) [and similarly claim 10 and claim 17] The method of claim 1, wherein modifying the field name or applying the function to the field value includes performing one or more query operations over the event data field. See Danilove Claim 1 and Yuan [column 10 lines 50-57] teaches a monitoring component 112 may be configured to collect device performance information by monitoring one or more client device operations, or by making calls to an operating system and/or one or more other applications executing on a client device 102 for performance information. Examiner submits the query operations are calls.; Yuan [column 9 lines 56-60] discloses the custom monitoring code may be incorporated into the code of a client application 110 in a number of different ways, such as the insertion of one or more lines in the client application code that call or otherwise invoke the monitoring component 112. As such, a developer of a client application 110 can add one or more lines of code into the client application 110 to trigger the monitoring component 112 at desired points during execution of the application. Danilov employs an event stream, (e.g., storing data). Yuan teaches parsing the data into one or more time-based events, storing the one or more time-based events in a second data store, and deleting the copy of at least the portion of the data from the first data store. It would have been obvious to combine before the effective filing date, to enable retention of an event based on a retention policy related to a ‘trigger,’ as taught by Danilov, with maintain non-yet processed data within a non-persistent data cache (cold row), as taught by Yuan, to improve the data intake process via HTTP. Yuan [column 61 line 50]. Regarding Claim 4, (Cancelled). Regarding Claim 5, (Original) [and similarly claim 12 and claim 19] The method of claim 1, wherein generating the second event of the discoverable event stream view comprises renaming the event data field as represented in the second event. See Danilove claim 1 and the associated text. Regarding Claim 7. (Original) [and similarly claim 7] The method of claim 1, wherein the event data field is a first event data field, and further comprising: generating a potential stream view of the discoverable event stream, the potential stream view defining a modification to or computation on a second event data field of the discoverable event stream; activating the potential stream view as the discoverable event stream view; and generating, based on the activating, during processing of the discoverable event stream, a fourth event data field of the discoverable event stream view by applying the modification or computation to the second event data field of the discoverable event stream. See claim 1 – Danilove Figure 1 and the associated text. Examiner further relies on Yuan to explicitly teach a potential stream view: Yuan teaches [column 34 lines 1-3] teaches by way of further example, instead of a search step, the set of events at the head of the pipeline may be generating by a call to a pre-existing inverted index (as will be explained later). Examiner submits the pre-existing inverted index is a potential stream. Yuan [column 37 lines 30-40] teaches a field extractor may be configured to automatically generate extraction rules for certain field values in the events when the events are being created, indexed, or stored, or possibly at a later time. In one embodiment, a user may be able to dynamically create custom fields by highlighting portions of a sample event that should be extracted as fields using a graphical user interface. The system would then generate a regular expression that extracts those fields from similar events and store the regular expression as an extraction rule for the associated field in the configuration file 712. Danilov employs an event stream, (e.g., storing data). Yuan teaches parsing the data into one or more time-based events, storing the one or more time-based events in a second data store, and deleting the copy of at least the portion of the data from the first data store. It would have been obvious to combine before the effective filing date, to enable retention of an event based on a retention policy related to a ‘trigger,’ as taught by Danilov, with maintain non-yet processed data within a non-persistent data cache (cold row), as taught by Yuan, to improve the data intake process via HTTP. Yuan [column 61 line 50]. Regarding Claim 21, (New) The method of claim 1, wherein the hot row store includes a non-persistent cache layer, and wherein the cold row store includes a persistent storage. See claim 1. Danilove Figure 1 and the associated text. Yuan Figure 26 and Figure 27 and the associated explicitly teaches persistent data. Danilov employs an event stream, (e.g., storing data). Yuan teaches parsing the data into one or more time-based events, storing the one or more time-based events in a second data store, and deleting the copy of at least the portion of the data from the first data store. It would have been obvious to combine before the effective filing date, to enable retention of an event based on a retention policy related to a ‘trigger,’ as taught by Danilov, with maintain non-yet processed data within a non-persistent data cache (cold row), as taught by Yuan, to improve the data intake process via HTTP. Yuan [column 61 line 50]. Although not relied on Examiner notes - May [column 3 lines 32-43] teaches hot (non-persistent storage) and cold storage (persistent). Claim(s) 6 is/are rejected under 35 U.S.C. 103 as being unpatentable over Danilov (US 2023/0,048,668 A1) in view of Yuan (US 11,269,808 B1) and in further view of Shete (US 2024/0,039,954 A1). Regarding Claim 6, (Previously Presented) The method of claim 1, wherein modifying the field name or applying the function to the field value is defined using a domain specific language. See claim 1 Danilove figure and figure 2 and Yuan [column 9 lines 56-60]. Shete further teaches restricted domains, DLP dictionaries. Danilov employs an event stream, (e.g., storing data). Yuan teaches parsing the data into one or more time-based events, storing the one or more time-based events in a second data store, and deleting the copy of at least the portion of the data from the first data store. It would have been obvious to combine before the effective filing date, to enable retention of an event based on a retention policy related to a ‘trigger,’ as taught by Danilov, with maintain non-yet processed data within a non-persistent data cache (cold row), as taught by Yuan, to improve the data intake process via HTTP. Yuan [column 61 line 50]. Danilov employs an event stream, (e.g., storing data). Shete performs risk assessment activities and preparing attained risk data. It would have been obvious to combine before the effective filing date, enabling retention of an event based on a retention policy related to a ‘trigger,’ as taught by Danilov, with parsing sub-domains of attack surface reports to fine and report specific VPN vulnerabilities, as taught by Shete, to protect domains. Shete [0135]. Examiner Notes: Penchikala (Big Data Processing with Apache Spark – Part 3: Spark Streaming) - teaches real-time monitoring of application server logs and performing data analytics on those logs using Apache libraries from Spark. Conclusion The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Park (US 2019/0,102,791 A1) teaches continuous queries typically perform filtering and aggregation function to discover and extract notable events from the input event streams. Crabtree (US 2018/0181537 A1) teaches Multiple dimension time series data store module. Zenger (US 2018/0,357,267 A1) teaches schemas mappings. Gurajada (US 2018/0,253,468 A1) teaches a database transaction affecting at least a first row in an in-memory row store and at least a second row in a persistent page store, logging changes to the second row within a page store transaction log as part of the processing and prior to committing the database transaction, and altering at least a portion of the in-memory row store based on accessing the row store transaction log. Armstrong (2013, LinkBench: a database Benchmark Based on the Facebook Social Graph) teaches database workload management, cache layering, performance, temporal patterns, and cold rows. Penchikala (Big Data Processing with Apache Spark – Part 3: Spark Streaming) - in real-time monitors application server logs and performance data analytics on those logs using Apache libraries from Spark. Muddu (US 9516053 B1) analyzes the data in real-time to detect anomalies, threat indicators, and threats…, by using Apache Spark Streaming., Muddu [column 15 lines 45-50]. May (US 11487762 B2) determines portions of a data set to be placed into hot or cold storage., May [column 1 lines 5-9]. Bozkurt (2023, Utilizing Flink and Kafka Technologies for Real-Time Sata Processing: A Case Study.) Flink’s stateful processing capabilities introduce the ability to maintain and update state across data streams, enabling complex event-driven workflows and pattern detection. Kafka's integration with various data systems, including batch processing frameworks, databases, and analytics tools, makes it an ideal hub for ingesting data from diverse sources and routing it to the appropriate destinations. Parikh (US 11,818,156 B1) teaches Datalakes and using an event streaming platform (e.g., Kafka) to obtain the data and/or pull data (e.g., configuration data from cloud environment. ) Any inquiry concerning this communication or earlier communications from the examiner should be directed to THEA LABOGIN whose telephone number is (571)272-9149. The examiner can normally be reached Monday -Friday, 8am-5pm. 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, Patricia Munson can be reached on 571-270- 5396. 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. /THEA LABOGIN/Examiner, Art Unit 3624
Read full office action

Prosecution Timeline

Jun 09, 2023
Application Filed
Mar 18, 2025
Non-Final Rejection — §103
Jun 18, 2025
Applicant Interview (Telephonic)
Jun 18, 2025
Examiner Interview Summary
Jun 25, 2025
Response Filed
Sep 23, 2025
Final Rejection — §103
Dec 03, 2025
Interview Requested
Dec 18, 2025
Applicant Interview (Telephonic)
Dec 18, 2025
Examiner Interview Summary
Jan 02, 2026
Request for Continued Examination
Feb 12, 2026
Response after Non-Final Action
Mar 23, 2026
Non-Final Rejection — §103 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12586018
SYSTEM AND METHOD FOR CREATING A SERVICE INSTANCE
2y 5m to grant Granted Mar 24, 2026
Patent 12406218
DASHBOARD FOR MULTI SITE MANAGEMENT SYSTEM
2y 5m to grant Granted Sep 02, 2025
Patent 12321841
Unsupervised Cross-Domain Data Augmentation for Long-Document Based Prediction and Explanation
2y 5m to grant Granted Jun 03, 2025
Patent 12299609
DYNAMICALLY TRANSMITTING ONLINE MODE INVITATIONS TO PROVIDER DEVICES IN RESPONSE TO DETECTED CHANGES IN PROVIDER DEVICE EFFICIENCY
2y 5m to grant Granted May 13, 2025
Patent 11928619
VEHICLE DISPATCH SERVICE BOARDING LOCATION DETERMINATION METHOD, AND VEHICLE DISPATCH SERVICE BOARDING LOCATION DETERMINATION DEVICE
2y 5m to grant Granted Mar 12, 2024
Study what changed to get past this examiner. Based on 5 most recent grants.

AI Strategy Recommendation

Get an AI-powered prosecution strategy using examiner precedents, rejection analysis, and claim mapping.
Powered by AI — typically takes 5-10 seconds

Prosecution Projections

3-4
Expected OA Rounds
14%
Grant Probability
30%
With Interview (+16.2%)
3y 11m
Median Time to Grant
High
PTA Risk
Based on 172 resolved cases by this examiner. Grant probability derived from career allow rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month