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 .
Claims 1-7, 9, 21-32 are pending.
Response to Amendment
Applicant’s amendment filed 12 January 2026 overcome the rejection under 35 U.S.C. 101. However the amendment raises new issues of 35 U.S.C.112 discussed below.
Response to Arguments
Applicant’s arguments regarding the rejection of claim 1 at page 11 of the response filed 12 January 2026 have been fully considered but they are not persuasive. Applicant seems to argue limitations not supported by the specification as originally filed for example “to form type-homogeneous groups of event”, “the intermediate records conform to ingestion requirements of the data warehouse platform”. Applicant also argues limitations not reflected in the claim language for example “to structure data streams for ingestion into analytic warehouses. Tucker was cited merely for teaching groupings events by event type. Pippin already teaches data ingestion in a warehouse wherein the core pipeline may perform a parsing operation that unpacks or processes complex data structures so that downstream consumer systems can access the data (see [0045])
Applicant argues at page 11 “Miller merely disclosed generic ETL concept”. In response the examiner is not persuaded. Applicant seems to argue references separately. Miller was cited merely to teach the use of intermediate records. It is the combination of Pippin, Tucker and Miller that teaches the claimed features.
Applicant presents no specific arguments regarding other claims.
For all the reasons discussed above, the rejection to all pending claims is maintained using the references of record
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1-7, 9, 21-32 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
The specification as originally filed does not support the now claimed “to form type-homogeneous groups of events”, “wherein the intermediate records conform to ingestion requirements of the data warehouse platform” recited in independent claims 1, 30.
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-7, 9, 21-32 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.
The specification as originally filed does not support the now claimed “to form type-homogeneous groups of events”, “wherein the intermediate records conform to ingestion requirements of the data warehouse platform” recited in independent claims 1, 30.
Furthermore it is not clear what role the “ingestion requirements of the data warehouse platform” play in the claimed method. Why converting what already conform to ingestion requirement of the data warehouse platform to a second version? Does applicant intend to mean data ingested into the warehouse undergo another transformation?
For examination purpose, the claimed “type-homogeneous groups of event” is mapped to the event stored in table of Pippin by event type at paragraph [0128]:”In some embodiments, the method (600b) creates a plurality of tables for storing events received from a stream processor. In one embodiment, the events are stored per batch interval (e.g., in five-minute increments) and also per event type”.
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-7, 9, 21-25, 30-32 is/are rejected under 35 U.S.C. 103 as being unpatentable over Pippin et al (US 20210365462 A1) of record, in view of Tucker et al (US 20200084085 A1) of record, further in view of Miller (US 20180144314 A1) of record.
Regarding claim 1, Pippin substantially discloses a method comprising:
receiving by a first computing system from an event streaming platform coupled to the first computing system communicating with a second computing system over a computer network (see at least Figs 3-4) first event data generated by at least one agent monitoring the second computing system and describing an event occurring in the second computing system (see at least [0027] The event emitters (102) can comprise any computing system capable of generating data. The disclosure places no limitations on the type of data or type of systems capable of generating such data. As one example, an event emitter may include a digital analytics system configured to track and monitor user events on webpages or in mobile apps. A digital analytics platform generates many events as users access products. One example is the delivery of advertising creatives. In these scenarios, the analytics platform generates an event indicating that a server transmitted the creative to the end-user. The analytics platform also generates an event indicating that the end-user device displayed the creative (i.e., an impression). If the end-user interacts with the creative, the analytics platform generates a “click” event (which may be any type of interaction including touch events and thus is not limited to physical mouse clicks). In certain embodiments, the analytics platform also generates conversion events that indicate that after an impression, and after a click, the end-user has completed another action (e.g., completes a digital purchase) that is related to the previous events. In some embodiments, the analytics platform tracks all of these events via a client-side identifier stored in, for example, a cookie or other end-user storage mechanism.),
wherein the first event data is encoded in a first storage format associated with the event streaming platform (see at least 0032: the streaming pipeline (106) processes data in real-time or near real-time. Thus, when the streaming pipeline (106) receives an event over the transport layer (104), it immediately processes or transforms the event and writes the processed event to the data warehouse (110).);
generating, based at least in part on the first event data, second event data describing the event encoded in a second storage format for storage in a data warehouse platform, the data warehouse platform comprising an analytic database created from two or more data sources coupled to the first computing system (see at least [0027] The event emitters (102) can comprise any computing system capable of generating data. The disclosure places no limitations on the type of data or type of systems capable of generating such data. As one example, an event emitter may include a digital analytics system configured to track and monitor user events on webpages or in mobile apps. A digital analytics platform generates many events as users access products. One example is the delivery of advertising creatives. In these scenarios, the analytics platform generates an event indicating that a server transmitted the creative to the end-user. The analytics platform also generates an event indicating that the end-user device displayed the creative (i.e., an impression). If the end-user interacts with the creative, the analytics platform generates a "click" event (which may be any type of interaction including touch events and thus is not limited to physical mouse clicks). In certain embodiments, the analytics platform also generates conversion events that indicate that after an impression, and after a click, the end-user has completed another action (e.g., completes a digital purchase) that is related to the previous events. In some embodiments, the analytics platform tracks all of these events via a client-side identifier stored in, for example, a cookie or other end-user storage mechanism.
the difference is Pippin does not specifically show:
by
grouping first event data conforming to a first version of the event into a plurality of groups based on event type to form type-homogeneous groups of events;
however Pippin clearly teaches creating tables for storing events by event type (see at least [0128]: In some embodiments, the method (600b) creates a plurality of tables for storing events received from a stream processor. In one embodiment, the events are stored per batch interval (e.g., in five-minute increments) and also per event type).
Furthermore it is customary in the art to group events by event types as shown by Tucker (see at least the following paragraphs:
Tucker [0029]: The second part may be implemented, for example, using techniques such as those described in FIG. 5. Once groups of related event types have been determined based on historical event data, they may be saved and/or passed to the second part that may apply those groups of event types to aggregate event data (e.g., new event data from a network being monitored). For example, received events may be classified by event type and aggregated by group of event types to organize a potential large flow of event data. The aggregated event data may be presented to a user (e.g., a network administrator), which may facilitate efficient monitoring and/or response to received events.)
Tucker [0062]: FIG. 2B is a block diagram of an example modular configuration of a computing system 250 for determining groups of related event types and presenting reports regarding received events based in part on the groups of event types in an electronic computing and communications system, such as the system 100 of FIG. 1. The system 250 may be implemented using computing devices, such as the systems, modules, and devices described with respect to FIGS. 1, 2A, and 2B. The system 250 may be implemented, for example, by executing a machine-readable program or other computer-executable instructions, such as instructions or programs described according to JavaScript, C, or other such instructions. The steps, or operations, performed by system 250 or any other method, process, or algorithm described in connection with the implementations disclosed herein can be implemented directly in hardware, firmware, software executed by hardware, circuitry, and/or a combination thereof.
Tucker [0063]: The computing system 250 has two parts. The first part is the event pattern detection module 252 that determines groups of event types 254 based on analysis of historical event data 256, where events of event types included in a group may be related to one another in a way that is useful for a network administrator to recognize. The second part is the event reporting module 260 that uses the groups of event types 254 from the event pattern detection module 252 to aggregate events arriving in an event stream 262 by the groups of event types 254 and present the aggregated information about the incoming events, in one or more graphical display regions 264, to a user (e.g., a network administrator for a network that generates the event stream 262). Presenting the information about the incoming events in a format that is aggregated by groups of related events may facilitate efficient monitoring and response to the incoming events in the event stream 262.
it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include such grouping while implementing the method of Pippin in order to present reports of related event types as taught by Tucker. Note Pippin already shows the method adds a version identifier to a given event. The claimed first version is taught by Pippin at paragraph [0149]: the method (600d) will additionally add a version identifier to the given event. In some embodiments, the version comprises a timestamp or may comprise an incrementing integer value.
Pippin does not specifically show:
converting the first event data conforming to the first version of the event into a plurality of intermediate records encoded using the second storage format according to the plurality of groups, wherein the intermediate records conform to ingestion requirements of the data warehouse platform, and
converting the plurality of intermediate records into the second event data conforming to a second version of the event used by the data warehouse computing system,
however it is customary in the art to do so as shown by Miller (see at least Miller [0090]. "…To extract and segment the invoice line item data, the invoice analytics system performs an extraction, transform, and load (ETL) operation 202 on the aggregated business service transactional invoice data. The invoice analytics system converts the extracted and segmented invoice line item data into an intermediate format that is ready for transformation processing. The invoice analytics system then transforms the extracted and segmented invoice line item data by applying business rules, cleaning the extracted and segmented invoice line item data, filtering the extracted and segmented invoice line item data based on business rules, splitting the extracted and segmented invoice line item data, validating the extracted and segmented invoice line item data, etc."
it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include such intermediate records while implementing the method of Pippin/Tucker in order to accommodate different second storage formats;
Pippin/Tucker/Miller further teaches:
wherein a first set of fields of the first version of the event is different than a second set of fields of the second version of the event (see at least Pippin [0032]: when the streaming pipeline (106) receives an event over the transport layer (104), it immediately processes or transforms the event); and
sending the second event data from the first computing system to the data warehouse platform as grouped records to be ingested into the data warehouse platform (see at least Pippin [0032]: when the streaming pipeline (106) receives an event over the transport layer (104 writes the processed event to the data warehouse (110), Pippin [0091]: In the illustrated embodiment, the deduplication store (414) stores events per batch period and per type of event. In some embodiments, the store (414) creates a new table for each event type and batch period pair for a fixed period of time (e.g., one week) since the current time.).
Regarding claim 2, Pippin/Tucker/Miller further teaches the method of claim 1, wherein sending the second event data to the data warehouse platform to store the second event data in one or more files associated with the data warehouse of the data warehouse platform and further comprising receiving, by the first computing system, a confirmation that the second event data was successfully stored (see at least Pippin [0147] In the case where the given event is primary event, the method (600d) will update the records in the tables associated with the secondary events (step 606d). After confirm that this update was successful, the method (600d) will only then write the given event to the distributed database. However, if the given event was not a primary event, the method proceeds to write the secondary event directly to the database. Certainly, if the associated primary event is received at a later date, the method (600d) will update this secondary event as discussed above).
Regarding claims 3, 4, Pippin/Tucker/Miller further teaches or suggests the method of claim 1, wherein the number of fields in the first set is more or less than a number of fields in the second set (see at least Miller [0090]: In an invoice aggregation database. The optical character recognition 201 performed by the invoice analytics system converts the received invoices of different formats into editable and searchable data. The invoice analytics system extracts and segments invoice line item data from the aggregated business service transactional invoice data using optical character recognition 201. To extract and segment the invoice line item data, the invoice analytics system performs an extraction, transform, and load (ETL) operation 202 on the aggregated business service transactional invoice data. The invoice analytics system converts the extracted and segmented invoice line item data into an intermediate format that is ready for transformation processing).
Regarding claim 5, Pippin/Tucker/Miller teaches or suggests the method of claim 4, wherein an added field in the second set includes a machine identifier (MID) uniquely indicating a computing asset generating the first event data in the second computing system (see at least Tucker [0100]: Events may be classified at operation 520 by event type. For example, event data received at operation 510 may include an event identifier (e.g., identifiers indicating conditions, such as high processor usage, high disk space usage, or firewall breached), and the event may be classified at operation 520 based at least in part on the event identifier. For example, event data received at operation 510 may include a metric name (e.g., processor usage, disk space usage, or number of packets received) and the event may be classified at operation 520 based at least in part on the metric name. For example, event data received at operation 510 may include a CI identifier (e.g., a name, a MAC address, an IP address, and/or a port number), and the event may be classified at operation 520 based at least in part on the CI identifier).
Regarding claim 6, Pippin/Tucker/Miller further teaches or suggests the method of claim 4, wherein an added field in the second set includes a log sequence number (LSN) identifying a location in a stream of records of the first event data (see at least Pippin [0054]: after the core pipeline (210) applies all operations to the event data, the core pipeline (210) writes the processed event to one or more fact feeds (212). In the illustrated embodiment, a fact feed (212) comprises a log of every event that was received by the core pipeline (210) and any additional information that the core pipeline (210) annotates or computes.). Note the log of every event received in the method of Pippin/Tucker/Miller clearly has to include log sequence numbers as claimed.
Regarding claim 7, Pippin/Tucker/Miller further teaches the method of claim 6, wherein the LSN comprises a partition identifier indicating a partition and an offset indicating a record in the partition (see at least Pippin [0099]-[0100]: For the at most once filter, the filter spout enables automatically committing offsets in a stream queue. By turning on auto- commitment, the filter spout only transmits a given event once and does not re-transmit events causing duplication. For the at least once with tag filter, the at least one filter mechanism can be used. However, in this filter, tags will be added prior to transmission to the consumer. These tags include the cursor, as described above, but also a topic and partition if they aren't implied by the derived stream's partition.).
Regarding claim 9, Pippin/Tucker/Miller further teaches the method of claim 2, wherein the event corresponds to a particular event type of a plurality of event types, and wherein the one or more files of the data warehouse computing platform storing the second event data corresponds to one of the plurality of event types (see at least Pippin [0107]: In one embodiment, the type field (506a) comprise an enumerated value indicating the type of the underlying event. In some embodiments, this type field (506a) may comprise an integer value or may comprise symbol or other type of fixed value. Examples of event types include click and serve events in an advertising system).
Regarding claim 21, Pippin/Tucker/Miller teaches or suggests the method of claim 1, wherein the at least one of the plurality of agents monitors activity of one or more computing nodes of the second computing system (see at least Miller [0140]: As a part of the platform governance 2705, the invoice analytics system 2603 monitors quality of the ingested data, that is, the extracted contract line item data and the extracted and segmented invoice line item data, ensures comprehensive data categorization, monitors authorization of access of the raw store 2703, monitors protection of sensitive data, for example, financial information in the raw store 2703 using masking, performs quota management of the extracted contract line item data and the extracted and segmented invoice line item data stored in the raw store 2708, etc.).
Regarding claim 22, Pippin/Tucker/Miller teaches or suggests the method of claim 1, further comprising identifying, by the first computing system, a topic of events and selecting the first event data related to the topic (see at least Pippin [0096]: Finally, a filter having an at least once with tag QoS generates batch dataset wherein each event in the batch includes tags allowing downstream consumer systems to detect duplicates. In one embodiment, this filter includes a stream topic, partition, and a "cursor," that can be used to detect duplicates).
Regarding claim 23, Pippin/Tucker/Miller teaches or suggests the method of claim 22, further comprising indicating one or more identifiers of customers of the second computing system associated with the topic, and wherein the first event data is associated with the one or more identifiers of the customers (see at least Pippin [0067] After processing by consumer pipelines (214a, 214b, 214n), each of the consumer pipelines (214a, 214b, 214n) output further processed event data to respective data warehouses (218a, 218b, 218n) in the warehousing layer (220e). The warehousing layer (220e) is generally the final stage of the system (200), where data is loaded into various systems to facilitate reporting, billing, or analysis. A data team may be responsible for various aspects of the warehousing, or it may be delegated to a data customer instead. Operations for a data team include loading, replication, and verification).
Regarding claim 24, Pippin/Tucker/Miller teaches or suggests the method of claim 1, wherein the first event data comprises network connection information relating to a selected computing asset of the second computing system (see at least Pippin [0161] The computing device (700) may optionally communicate with a base station (not shown), or directly with another computing device. Network interface (750) is sometimes known as a transceiver, transceiving device, or network interface card (NIC).
Regarding claim 25, Pippin/Tucker/Miller teaches or suggests the method of claim 24, wherein the first event data comprises a number of network connections established during an interval (see at least Pippin [0128] In some embodiments, the method (600b) creates a plurality of tables for storing events received from a stream processor. In one embodiment, the events are stored per batch interval (e.g., in five-minute increments) and also per event type. Thus, the method (600b) is configured to create new database tables for each tuple (EventType, BatchTime) for a preconfigured interval. As one example, the method (600b) may create these tables for a week worth of batch intervals. In some embodiments, the method (600b) is performed at regular intervals (e.g., once a day). In some embodiments, the method (600b) is scheduled using a workflow scheduler system (e.g., Apache® Oozie).).
Claim 30 essentially corresponds to an apparatus for performing the method of claim 1 thus is rejected for the same reasons discussed in claim 1 above.
Regarding claim 31, Pippin/Tucker/Miller teaches or suggests the apparatus of claim 30, wherein a number of fields in the first set is less than a number of fields in the second set (see at least Miller [0090]: in an invoice aggregation database. The optical character recognition 201 performed by the invoice analytics system converts the received invoices of different formats into editable and searchable data. The invoice analytics system extracts and segments invoice line item data from the aggregated business service transactional invoice data using optical character recognition 201. To extract and segment the invoice line item data, the invoice analytics system performs an extraction, transform, and load (ETL) operation 202 on the aggregated business service transactional invoice data. The invoice analytics system converts the extracted and segmented invoice line item data into an intermediate format that is ready for transformation processing).
Claim 32 essentially corresponds to an apparatus for performing the method of claim 5 thus is rejected for the same reasons discussed in claim 5 above.
Claim(s) 26-29 is/are rejected under 35 U.S.C. 103 as being unpatentable over Pippin et al (US 20210365462 A1) of record, in view of Tucker et al (US 20200084085 A1) of record, in view of Miller (US 20180144314 A1) of record, further in view of Mitkar et al (US 20210271564 A1) of record.
Regarding claim 26, Pippin/Tucker/Miller does not does not specifically show the method of claim 1, wherein the first event data comprises at least one of an operation and a performance metric performed by at least one of an application and a container executing on the second computing system.
However it is customary in the art to do so as shown by Mitkar (see at least [0009]: In some embodiments, the system described in the present disclosure can facilitate more efficient backups of data used for executing containerized applications by accessing and moving such data from cloud provider systems onto low-cost secondary storage devices. Additionally, the system can group all the data objects relevant to executing a containerized application or a collection thereof (e.g., a pod) on the container orchestration system to facilitate tracking, backup, and restore of such data objects. In some cases, the secondary storage computing device and the components thereof described herein may be implemented as a pod executed on the same machine (e.g., virtual or physical) as the pod containing the user's containerized applications (e.g., instead of being external to the container orchestration system) to make better use of the interfaces provided by the container orchestration system,)
it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include such features while implementing the method of Pippin/Tucker/Miller in order to facilitate tracking of events by the second computing system.
Regarding claim 27, Pippin/Tucker/Miller does not specifically show the method of claim 1, comprising grouping a plurality of records of the second event data into a single communication to the data warehouse computing system.
However it is customary in the art to do so as shown by Mitkar (see at least [0009].. the system can group all the data objects relevant to executing a containerized application or a collection thereof (e.g., a pod) on the container orchestration system to facilitate tracking, backup, and restore of such data objects).
it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include such features while implementing the method of Pippin/Tucker/Miller in order to facilitate tracking of events by the second computing system.
Regarding claim 28, Pippin/Tucker/Miller does not specifically show the method of claim 2, comprising detecting an error when the confirmation is not received.
However it is customary in the art to do so as shown by Mitkar (see at least [0105]: management database 146 may comprise data needed to kick off secondary copy operations (e.g., storage policies, schedule policies, etc.), status and reporting information about completed jobs (e.g., status and error reports on yesterday's backup jobs), and additional information sufficient to enable restore and disaster recovery operations (e.g., media agent associations, location indexing, content indexing, etc.).
it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include such features while implementing the method of Pippin/Tucker/Miller in order to report job completion status.
Regarding claim 29, Pippin/Tucker/Miller does not specifically show the method of claim 1, comprising receiving the first event data from a cloud- based log generation service associated with the second computing system.
However it is customary in the art to do so as shown by Mitkar (see at least [0006]: Certain embodiments described herein relate to an improved information management system for protecting data for containerized applications executed on a container orchestration system. The information management system may include a secondary storage computing device that can communicate with the container orchestration system and a cloud provider system utilized by the containerized applications executed on the container orchestration system. The secondary storage computing device may perform one or more of the techniques described herein. For example, the secondary storage computing device may access a pod specification associated with the pod executing on the container orchestration system, identify the cloud provider system based on the information provided in the pod specification, create a snapshot of the cloud storage volume utilized by the pod, access the data inside the snapshot using a provider-specific interface associated with the identified cloud provider system, store the data onto a secondary storage device separate from the cloud provider system, and remove the snapshot from the cloud provider system).
it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include such features while implementing the method of Pippin/Tucker/Miller in order to benefit from the services of a cloud provider system.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Houston et al (US 20020019945 A1) teach a computer-implemented system for managing security event data collected from a computing network. The system employs an event managing software module that can reside on a computing network that is being monitored with security devices. The event managing software collects security event data from security devices located in the monitored computing network and can process the security event data. In processing the security event data, the event manager module can format the data and create manageable summaries of the data. The event manager also supports storage of the security event data and the results of any processing performed on the data. Security event data can be identified by the event manager for use in responding to a security event.
Singh et al (US 10419469 B1) teach Log data associated with at least one user session associated with an original user is received. A logical graph is generated using at least a portion of the received log data. One example of such a logical graph is a privilege change graph that models privilege changes between processes. Another example of such a logical graph is a user login graph that models machines with which the original user interacts. Another example of such a logical graph is a machine-server graph that clusters machines into nodes based on resources executing on the machine. The generated logical graph is used to detect an anomaly. The detected anomaly is recorded. Agent service 132 is a microservice that is responsible for accepting data collected from agents (e.g., provided by aggregator 114). In various embodiments, agent service 132 uses a standard secure protocol, such as HTTPS to communicate with aggregators (and as applicable agents), and receives data in an appropriate format such as Apache Avro. When agent service 132 receives an incoming connection, it can perform a variety of checks, such as to see whether the data is being provided by a current customer, and whether the data is being provided in an appropriate format. If the data is not appropriately formatted (and/or is not provided by a current customer), it is rejected. If the data is appropriately formatted, agent service 132 facilitates copying the received data to a streaming data stable storage (e.g., using Amazon Kinesis (134)). Once the ingesting into Kinesis is complete, service 132 sends an acknowledgement to the data provider (e.g., data aggregator 114). If the agent does not receive such an acknowledgement, it is configured to retry sending the data to platform 102.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, 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 UYEN T LE whose telephone number is (571)272-4021. The examiner can normally be reached M-F 9-5.
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, Ajay M Bhatia can be reached at 5712723906. 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.
/UYEN T LE/Primary Examiner, Art Unit 2156 15 March 2026