DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This office action is responsive to a response filed on June 5th, 2026. In this office action:
Claims 1-2, 4-6, and 8-9 are pending.
Claims 1-2, 4-6, and 8-9 are rejected.
Summary of Previous Office Action
In the Non-Final Office Action mailed on March 19th, 2026,
Claims 1-8 were rejected under 35 U.S.C. 101 because the claimed invention was directed to an abstract idea without significantly more.
Claims 1-8 were rejected under 35 U.S.C. 102 (a)(2) as being anticipated by Han et al. (Patent No. US 12,189,624), hereinafter Han.
Response to Amendment
The amendments filed on June 5th, 2026 have been entered.
Claims 1 and 5 have been amended.
Claims 3 and 7 have been canceled.
Claim 9 has been added.
Response to Arguments
Applicant’s arguments filed on June 5th, 2026 have been fully considered, but are not persuasive.
1/ Claim Rejections under 35 U.S.C. 101:
Regarding Applicant’s argument that [t]he pending claims are not directed to an abstract idea, but instead to a specific computer-implemented technique for converting, filtering, and storing IoT sensing data using defined data structures and execution-bounded processing logic ... (See Applicant’s Arguments, Page 6), the Examiner respectfully disagrees; it is noted that even mental processes which may need the physical aids such as pen and paper can be still mental processes (see MPEP §2106.04(a)(2)(III)(B)) and even the fact that the claimed invention is performing steps on a computer does not prevent the function from being a mental process (see MPEP §2106.04(a)(2)(III)(C)). As result, the claim recites a mental process.
In addition, the Examiner considered “storing” as insignificant extra-solution activity because storing does not add significantly more (also known as an "inventive concept") to the exception. The limitation recites storing data, which is a well-understood, routine, conventional computer function as recognized by the court decisions (See MPEP 2106.05(d) II “iv. Storing and retrieving information in memory, Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334, 115 USPQ2d 1681, 1701 (Fed. Cir. 2015); OIP Techs., 788 F.3d at 1363, 115 USPQ2d at 1092-93”)
1/ Claim Rejections under 35 U.S.C. 102:
Applicant’s argument:
Han does not teach or suggest converting IoT sensing data into a tuple data structure that includes a multidimensional values array populated pursuant to a filtering condition defined by a base device name and a time limit measured from first receipt of a triggering event. Nor does Han disclose selectively populating tuple array positions based on such a filtering window before storage as indexed time-series data, a configuration that reduces irrelevant data persistence and enables more accurate downstream analytics
Examiner’s response:
The Examiner respectfully disagrees.
Han discloses, in Col. 29 lines 43-53, [t]he results obtained or generated in response to a command in a query can be considered a set of results data. The set of results data can be passed from one command to another in any data format. In one embodiment, the set of result data can be in the form of a dynamically created table. Each command in a particular query can redefine the shape of the table. In some implementations, an event retrieved from an index in response to a query can be considered a row with a column for each field value. Columns can contain basic information about the data and/or data that has been dynamically extracted at search time. Further Han discloses, in Col. 25 lines 31-67 and Col. 26 lines 1-7, that [w]ith reference to the event reference array 340, each unique identifier 350, or event reference, can correspond to a unique event located in the time series bucket or machine data file 316B ...
Therefore, the Examiner has reasonably interpreted the claimed “multidimensional values array” to be equivalent to the created table, as taught by Han.
Regarding applicant’s argument that Han doesn’t disclose “converting IoT sensing data into a tuple data structure that includes a multidimensional values array populated pursuant to a filtering condition defined by a base device name and a time limit measured from first receipt of a triggering event,” The Examiner responds that the claim language doesn’t recites the converting of the IoT sensing data into a tuple data structure that includes a multidimensional values array is based on a filtering condition. The claim recites converting the IoT sensing data into a tuple data structure; the, a filtering is performed. It is noted that the features upon which applicant relies are not recited in the rejected claim. Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993)
Regarding Applicant’s argument that Han doesn’t disclose “selectively populating tuple array positions based on such a filtering window,” The Examiner respectfully disagrees. Han discloses, in Col. 29 lines 1-23, a command at the beginning of a query can perform a “filtering” step by retrieving a set of data based on a condition (e.g., records associated with server response times of less than 1 microsecond). The results of the filtering step can then be passed to a subsequent command in the pipeline that performs a “processing” step (e.g. calculation of an aggregate value related to the filtered events such as the average response time of servers with response times of less than 1 microsecond) ... See Col. 30 lines 8-19; Rows in the table 424 may represent individual records, where each record corresponds to an event in the disk 422 that satisfied the filter criteria. Columns in the table 424 may correspond to different fields of an event or record, such as “user,” “count,” percentage,” “timestamp,” or the raw machine data of an event, etc.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-2, 4-6, and 8-9 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
1/ Independent claims:
Claims 1 and 5 recite in part process steps which, under the broadest reasonable interpretation, are a series of mental processes including an observation, evaluation, judgment or opinion that could be performed in the human mind or with the aid of pencil and paper. If a claim, under its broadest reasonable interpretation, covers a mental process or a mathematical concept but for the recitation of generic computer components, then it falls within the "Mental Process" grouping of abstract ideas. The claim recites in part:
receiving, from an IoT platform, sensing data generated by an IoT device. The “receiving” is reasonably interpreted by the Examiner as gathering/collecting data. Under its broadest reasonable interpretation when read in light of the specification, the claimed “receiving” data encompasses gathering data.
parsing, by the data conversion module, the sensing data according to a first event data format storing an event object ... converting, by the data conversion module, the parsed event object into a tuple data structure conforming to a second time-series data format ... {performing a conversion on gathered data}. The gathered data undergoes a conversion which is reasonably interpreted by the Examiner as a process of translating data from one format, structure, or encoding system to another. The claim does not provide any details on how the data is converted or any details on the conversion. Under its broadest reasonable interpretation when read in light of the specification, the claimed “parsing” and “converting” the event into encompasses a process of translating the gathered data from one format (i.e., first format) to another (i.e., second format).
applying, by the data conversion module, a filtering condition data structure. The data undergoes a filtering which is reasonably interpreted by the Examiner as making a judgment on the data. Under its broadest reasonable interpretation when read in light of the specification, the claimed “filtering” encompasses observing information and making a judgement.
storing, by the data conversion module, the tuple data structure in a database table as multidimensional time-series data indexed by the tuple timestamp. The Examiner considered this limitation as insignificant extra-solution activity because storing does not add significantly more (also known as an "inventive concept") to the exception. The limitation recites storing data in a memory, which is a well-understood, routine, conventional computer function as recognized by the court decisions (See MPEP 2106.05(d) II “iv. Storing and retrieving information in memory, Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334, 115 USPQ2d 1681, 1701 (Fed. Cir. 2015); OIP Techs., 788 F.3d at 1363, 115 USPQ2d at 1092-93”)
Therefore, claims 1 and 5 recite an abstract idea.
This judicial exception is not integrated into a practical application. In particular, the claims only recite additional elements - when executed by a conversion module comprising a processor and memory/ input interface/ processor to receiving, parsing, converting, filtering, and storing. The input interface and the processors are recited at a high-level of generality, such that it amounts no more than mere instructions to apply the exception using a generic computer component. As described in MPEP 2106.0S(g), limitations that amount to merely adding insignificant extra-solution activity to a judicial exception cannot integrate a judicial exception into a practical application. Accordingly, these additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. Therefore, claims 1 and 5 are directed to a judicial exception.
Claims 1 and 5 do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above, the additional elements of an conversion module comprising a processor and memory/ input interface/ processor to receiving, parsing, converting, filtering, and storing to no more than mere instructions to apply the exception using a generic computer component. Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept. Claims 1 and 5 are not patent eligible.
2/ Dependent claims:
Claim 2 is rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more. Claim 2 depends on claim 1, and it further recites “wherein converting the sensing data comprises: converting the sensing data into the event according to the first data format including sensing information content constituted by an event identifier indicating a universally unique identifier being an identifier for distinguishing respective events, a timestamp indicating an event generation time, a device name indicating a device having transmitted sensing information, a resource name, a type of value, and a value.” The claim is further limiting the definition of converting the sensing data, which does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. Therefore, claim 2 is not patent eligible.
Claim 4 is rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more. Claim 4 depends on claim 1, and it further recites “wherein the storing comprises: filtering and processing sensing information satisfying preset conditions according to a filtering condition data format including a base device name indicating a device that is a base for filtering, a time limit indicating a processing range of an event to be filtered within a time limit after an event including the base device is first received, a time unit indicating a unit of time used for the time limit, and a filter list indicating a list of sensing information that is composed of a device name and a resource list and is to be subjected to filtering.” The claim is further limiting the definition of the storing, which does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. Therefore, claim 4 is not patent eligible.
Claim 6 is rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more. Claim 6 depends on claim 5, and it further recites “convert the sensing data into the event according to the first data format including sensing information content constituted by an event identifier indicating a universally unique identifier being an identifier for distinguishing respective events, a timestamp indicating an event generation time, a device name indicating a device having transmitted sensing information, a resource name, a type of value, and a value.” The claim is further limiting the definition of converting the sensing data, which does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. Therefore, claim 6 is not patent eligible.
Claim 8 is rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more. Claim 8 depends on claim 5, and it further recites “filter and process sensing information satisfying preset conditions according to a filtering condition data format including a base device name indicating a device that is a base for filtering, a time limit indicating a processing range of an event to be filtered within a time limit after an event including the base device is first received, a time unit indicating a unit of time used for the time limit, and a filter list indicating a list of sensing information that is composed of a device name and a resource list and is to be subjected to filtering.” The claim is further limiting the definition of the storing/filtering sensing information, which does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. Therefore, claim 8 is not patent eligible.
Claim 9 is rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more. Claim 9 depends on claim 1, and it further recites “wherein applying the filtering condition data structure comprises initiating a filtering window in response to detection of an event associated with the base device name, computing an elapsed time relative to the filtering window, and excluding sensing values from population of the multidimensional values array when the elapsed time exceeds the time limit.” The claim is further limiting the filtering, which does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. Therefore, claim 9 is not patent eligible.
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1-2, 4-6, and 8-9 are rejected under 35 U.S.C. 102 (a)(2) as being anticipated by Han et al. (Patent No. US 12,189,624), hereinafter Han.
Claim 1. Han discloses [a] computer-implemented method for converting and storing time series data of Internet of Things (IoT) events, the method executed by a data conversion module comprising a processor and memory (See Col. 9 lines 8-19; system 102 can include any one or any combination of an intake system 110 (including one or more components) to ingest data, an indexing system 112 (including one or more components) to index the data, a storage system 116 (including one or more components) to store the data, and/or a query system 114 (including one or more components) to search the data, etc. See also Col. 13 lines 38-67), the method comprising:
receiving, from an IoT platform, sensing data generated by an IoT device (See Col. 16 lines 48-67, Col. 17 lines 1-20 and Fig. 2; the intake system 110 receives data from a host device 104 (internet of things (IOT) device, See Col. 6 lines 47-67). The intake system 110 initially may receive the data as a raw data stream generated by the host device 104 ... the intake system 110 receives the raw data and may segment the data stream into messages, possibly of a uniform data size, to facilitate subsequent processing steps);
parsing, by the data conversion module, the sensing data according to a first event data format storing an event object that includes: an event identifier comprising a universally unique identifier, an event generation timestamp, a device name identifying the IoT device, and a readings array comprising at least one sensing value identified by a resource name and a value type (See Col. 16 lines 48-67, Col. 17 lines 1-20 and Fig. 2; ... the intake system 110 receives the raw data and may segment the data stream into messages, possibly of a uniform data size, to facilitate subsequent processing steps. The intake system 110 may thereafter process the messages in accordance with one or more rules to conduct preliminary processing of the data. In one embodiment, the processing conducted by the intake system 110 may be used to indicate one or more metadata fields applicable to each message. For example, the intake system 110 may include metadata fields within the messages, or publish the messages to topics indicative of a metadata field. These metadata fields may, for example, provide information related to a message as a whole and may apply to each event that is subsequently derived from the data in the message. For example, the metadata fields may include separate fields specifying each of a host, a source, and a sourcetype related to the message. A host field may contain a value identifying a host name or IP address of a device that generated the data. A source field may contain a value identifying a source of the data, such as a pathname of a file or a protocol and port related to received network data. A sourcetype field may contain a value specifying a particular sourcetype label for the data. Additional metadata fields may also be included, such as a character encoding of the data, if known, and possibly other values that provide information relevant to later processing steps. In certain embodiments, the intake system 110 may perform additional operations, such as, but not limited to, identifying individual events within the data, determining timestamps for the data, further enriching the data, etc. See Col. 25 lines 31-67 and Col. 26 lines 1-7; With reference to the event reference array 340, each unique identifier 350, or event reference, can correspond to a unique event located in the time series bucket or machine data file 316B ... See Col. 2 lines 38-57, Col. 4 lines 7-16, and Col. 18 lines 1-11);
converting, by the data conversion module, the parsed event object into a tuple data structure conforming to a second time-series data format that includes: a tuple timestamp having a preset temporal format different from the event generation timestamp, and a multidimensional values array storing numerical sensing values aligned to corresponding resource identifiers (See Col. 17 lines 45-67 and Fig. 2; the indexing system 112 can determine a timestamp for each event. Similar to the process for parsing machine data, the indexing system 112 may again refer to a sourcetype definition associated with the data to locate one or more properties that indicate instructions for determining a timestamp for each event. The properties may, for example, instruct the indexing system 112 to extract a time value from a portion of data for the event (e.g., using a regex rule), to interpolate time values based on timestamps associated with temporally proximate events, to create a timestamp based on a time the portion of machine data was received or generated, to use the timestamp of a previous event, or use any other rules for determining timestamps, etc. See Col. 25 lines 31-67 and Col. 26 lines 1-7; With reference to the event reference array 340, each unique identifier 350, or event reference, can correspond to a unique event located in the time series bucket or machine data file 316B ... See Col. 29 lines 43-53; The results obtained or generated in response to a command in a query can be considered a set of results data. The set of results data can be passed from one command to another in any data format. In one embodiment, the set of result data can be in the form of a dynamically created table. Each command in a particular query can redefine the shape of the table. In some implementations, an event retrieved from an index in response to a query can be considered a row with a column for each field value. Columns can contain basic information about the data and/or data that has been dynamically extracted at search time. See also Col. 18 lines 12-60);
applying, by the data conversion module, a filtering condition data structure that specifies: a base device name, a time limit defining a processing window measured from receipt of an event associated with the base device name, and a filter list identifying permissible device names and resource identifiers, to selectively populate positions within the multidimensional values array (See Col. 29 lines 1-23; a query can start with a search command and one or more corresponding search terms or filter criteria at the beginning of the pipeline. Such search terms or filter criteria can include any combination of keywords, phrases, times, dates, Boolean expressions, fieldname-field value pairs, etc. that specify which results should be obtained from different locations. The results can then be passed as inputs into subsequent commands in a sequence of commands by using, for example, a pipe character. The subsequent commands in a sequence can include directives for additional processing of the results once it has been obtained from one or more indexes. For example, commands may be used to filter unwanted information out of the results, extract more information, evaluate field values, calculate statistics, reorder the results, create an alert, create summary of the results, or perform some type of aggregation function. In some embodiments, the summary can include a graph, chart, metric, or other visualization of the data. An aggregation function can include analysis or calculations to return an aggregate value, such as an average value, a sum, a maximum value, a root mean square, statistical values, and the like ... a command at the beginning of a query can perform a “filtering” step by retrieving a set of data based on a condition (e.g., records associated with server response times of less than 1 microsecond). The results of the filtering step can then be passed to a subsequent command in the pipeline that performs a “processing” step (e.g. calculation of an aggregate value related to the filtered events such as the average response time of servers with response times of less than 1 microsecond). Furthermore, the search command can allow events to be filtered by keyword as well as field criteria. For example, a search command can filter events based on the word “warning” or filter events based on a field value “10.0.1.2” associated with a field “clientip.” See Col. 30 lines 8-19; Rows in the table 424 may represent individual records, where each record corresponds to an event in the disk 422 that satisfied the filter criteria. Columns in the table 424 may correspond to different fields of an event or record, such as “user,” “count,” percentage,” “timestamp,” or the raw machine data of an event, etc.); and
storing, by the data conversion module, the tuple data structure in a database table as multidimensional time-series data indexed by the tuple timestamp (See Col. 18 lines 61-67, Col. 19 lines 1-10, and Fig. 2; the indexing system 112 stores the events with an associated timestamp in the storage system 116, which may be in a local data store and/or in a shared storage system. Timestamps enable a user to search for events based on a time range. In some embodiments, the stored events are organized into “buckets,” where each bucket stores events associated with a specific time range based on the timestamps associated with each event. See Col. 29 lines 43-53; The results obtained or generated in response to a command in a query can be considered a set of results data. The set of results data can be passed from one command to another in any data format. In one embodiment, the set of result data can be in the form of a dynamically created table. Each command in a particular query can redefine the shape of the table. In some implementations, an event retrieved from an index in response to a query can be considered a row with a column for each field value. Columns can contain basic information about the data and/or data that has been dynamically extracted at search time. See also Fig. 3A-C).
Claim 2. Han discloses [t]he method of claim 1,
Han further discloses wherein converting the sensing data comprises: converting the sensing data into the event according to the first data format including sensing information content constituted by an event identifier indicating a universally unique identifier being an identifier for distinguishing respective events, a timestamp indicating an event generation time, a device name indicating a device having transmitted sensing information, a resource name, a type of value, and a value (See Col. 16 lines 48-67, Col. 17 lines 1-20 and Fig. 2; ... the intake system 110 receives the raw data and may segment the data stream into messages, possibly of a uniform data size, to facilitate subsequent processing steps. The intake system 110 may thereafter process the messages in accordance with one or more rules to conduct preliminary processing of the data. In one embodiment, the processing conducted by the intake system 110 may be used to indicate one or more metadata fields applicable to each message. For example, the intake system 110 may include metadata fields within the messages, or publish the messages to topics indicative of a metadata field. These metadata fields may, for example, provide information related to a message as a whole and may apply to each event that is subsequently derived from the data in the message. For example, the metadata fields may include separate fields specifying each of a host, a source, and a sourcetype related to the message. A host field may contain a value identifying a host name (a device name) or IP address of a device that generated the data. A source field may contain a value identifying a source of the data, such as a pathname of a file or a protocol and port related to received network data. A sourcetype field may contain a value specifying a particular sourcetype label for the data. Additional metadata fields may also be included, such as a character encoding of the data, if known, and possibly other values that provide information relevant to later processing steps. In certain embodiments, the intake system 110 may perform additional operations, such as, but not limited to, identifying individual events (an event identifier) within the data, determining timestamps for the data, further enriching the data, etc. See Col. 2 lines 38-57, Col. 4 lines 7-16, and Col. 18 lines 1-11).
Claim 4. Han discloses [t]he method of claim 1,
Han further discloses wherein the storing comprises: filtering and processing sensing information satisfying preset conditions according to a filtering condition data format including a base device name indicating a device that is a base for filtering, a time limit indicating a processing range of an event to be filtered within a time limit after an event including the base device is first received, a time unit indicating a unit of time used for the time limit, and a filter list indicating a list of sensing information that is composed of a device name and a resource list and is to be subjected to filtering (See Col. 18 lines 1-18; the indexing system 112 can also apply one or more transformations to event data that is to be included in an event. For example, such transformations can include removing a portion of the event data (e.g., a portion used to define event boundaries, extraneous characters from the event, other extraneous text, etc.), masking a portion of event data (e.g., masking a credit card number), removing redundant portions of event data, etc. The transformations applied to event data may, for example, be specified in one or more configuration files and referenced by one or more sourcetype definitions. [T]he indexing system 112 can group events. In some embodiments, the indexing system 112 can group events based on time. For example, events generated within a particular time period or events that have a time stamp within a particular time period can be grouped together to form a bucket See Col. 18 lines 61-67, Col. 19 lines 1-10, and Fig. 2; the indexing system 112 stores the events with an associated timestamp in the storage system 116, which may be in a local data store and/or in a shared storage system. Timestamps enable a user to search for events based on a time range. In some embodiments, the stored events are organized into “buckets,” where each bucket stores events associated with a specific time range based on the timestamps associated with each event. See also Col. 29 lines 24-42, Col. 30 lines 1-19, Fig. 3A-C and Fig. 4A-C).
Claim 5. Han discloses [a] system for converting and storing time series data of Internet of Things (IoT) events (See Col. 9 lines 8-19; system 102 can include any one or any combination of an intake system 110 (including one or more components) to ingest data, an indexing system 112 (including one or more components) to index the data, a storage system 116 (including one or more components) to store the data, and/or a query system 114 (including one or more components) to search the data, etc.), the system comprising:
an input interface configured to receive sensing data received from an IoT device (See Col. 16 lines 48-67, Col. 17 lines 1-20 and Fig. 2; the intake system 110 receives data from a host device 104 (internet of things (IOT) device, See Col. 6 lines 47-67));
a memory that stores a program configured to convert the sensing data into time series data for an IoT event and store the time series data; and a processor configured to execute the program (See Col. 54 lines 1-32; Embodiments are also described above with reference to flow chart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products. Each block of the flow chart illustrations and/or block diagrams, and combinations of blocks in the flow chart illustrations and/or block diagrams, may be implemented by computer program instructions. Such instructions may be provided to a processor) to:
receive, from an IoT platform, sensing data generated by an IoT device (See Col. 16 lines 48-67, Col. 17 lines 1-20 and Fig. 2; the intake system 110 receives data from a host device 104 (internet of things (IOT) device, See Col. 6 lines 47-67). The intake system 110 initially may receive the data as a raw data stream generated by the host device 104 ... the intake system 110 receives the raw data and may segment the data stream into messages, possibly of a uniform data size, to facilitate subsequent processing steps);
parse the sensing data according to a first event data format storing an event object that includes: an event identifier comprising a universally unique identifier, an event generation timestamp, a device name identifying the IoT device, and a readings array comprising at least one sensing value identified by a resource name and a value type (See Col. 16 lines 48-67, Col. 17 lines 1-20 and Fig. 2; ... the intake system 110 receives the raw data and may segment the data stream into messages, possibly of a uniform data size, to facilitate subsequent processing steps. The intake system 110 may thereafter process the messages in accordance with one or more rules to conduct preliminary processing of the data. In one embodiment, the processing conducted by the intake system 110 may be used to indicate one or more metadata fields applicable to each message. For example, the intake system 110 may include metadata fields within the messages, or publish the messages to topics indicative of a metadata field. These metadata fields may, for example, provide information related to a message as a whole and may apply to each event that is subsequently derived from the data in the message. For example, the metadata fields may include separate fields specifying each of a host, a source, and a sourcetype related to the message. A host field may contain a value identifying a host name or IP address of a device that generated the data. A source field may contain a value identifying a source of the data, such as a pathname of a file or a protocol and port related to received network data. A sourcetype field may contain a value specifying a particular sourcetype label for the data. Additional metadata fields may also be included, such as a character encoding of the data, if known, and possibly other values that provide information relevant to later processing steps. In certain embodiments, the intake system 110 may perform additional operations, such as, but not limited to, identifying individual events within the data, determining timestamps for the data, further enriching the data, etc. See Col. 25 lines 31-67 and Col. 26 lines 1-7; With reference to the event reference array 340, each unique identifier 350, or event reference, can correspond to a unique event located in the time series bucket or machine data file 316B ... See Col. 2 lines 38-57, Col. 4 lines 7-16, and Col. 18 lines 1-11);
convert the parsed event object into a tuple data structure conforming to a second time-series data format that includes: a tuple timestamp having a preset temporal format different from the event generation timestamp, and a multidimensional values array storing numerical sensing values aligned to corresponding resource identifiers (See Col. 17 lines 45-67 and Fig. 2; the indexing system 112 can determine a timestamp for each event. Similar to the process for parsing machine data, the indexing system 112 may again refer to a sourcetype definition associated with the data to locate one or more properties that indicate instructions for determining a timestamp for each event. The properties may, for example, instruct the indexing system 112 to extract a time value from a portion of data for the event (e.g., using a regex rule), to interpolate time values based on timestamps associated with temporally proximate events, to create a timestamp based on a time the portion of machine data was received or generated, to use the timestamp of a previous event, or use any other rules for determining timestamps, etc. See Col. 25 lines 31-67 and Col. 26 lines 1-7; With reference to the event reference array 340, each unique identifier 350, or event reference, can correspond to a unique event located in the time series bucket or machine data file 316B ... See Col. 29 lines 43-53; The results obtained or generated in response to a command in a query can be considered a set of results data. The set of results data can be passed from one command to another in any data format. In one embodiment, the set of result data can be in the form of a dynamically created table. Each command in a particular query can redefine the shape of the table. In some implementations, an event retrieved from an index in response to a query can be considered a row with a column for each field value. Columns can contain basic information about the data and/or data that has been dynamically extracted at search time. See also Col. 18 lines 12-60);
apply a filtering condition data structure that specifies: a base device name, a time limit defining a processing window measured from receipt of an event associated with the base device name, and a filter list identifying permissible device names and resource identifiers, to selectively populate positions within the multidimensional values array (See Col. 29 lines 1-23; a query can start with a search command and one or more corresponding search terms or filter criteria at the beginning of the pipeline. Such search terms or filter criteria can include any combination of keywords, phrases, times, dates, Boolean expressions, fieldname-field value pairs, etc. that specify which results should be obtained from different locations. The results can then be passed as inputs into subsequent commands in a sequence of commands by using, for example, a pipe character. The subsequent commands in a sequence can include directives for additional processing of the results once it has been obtained from one or more indexes. For example, commands may be used to filter unwanted information out of the results, extract more information, evaluate field values, calculate statistics, reorder the results, create an alert, create summary of the results, or perform some type of aggregation function. In some embodiments, the summary can include a graph, chart, metric, or other visualization of the data. An aggregation function can include analysis or calculations to return an aggregate value, such as an average value, a sum, a maximum value, a root mean square, statistical values, and the like ... a command at the beginning of a query can perform a “filtering” step by retrieving a set of data based on a condition (e.g., records associated with server response times of less than 1 microsecond). The results of the filtering step can then be passed to a subsequent command in the pipeline that performs a “processing” step (e.g. calculation of an aggregate value related to the filtered events such as the average response time of servers with response times of less than 1 microsecond). Furthermore, the search command can allow events to be filtered by keyword as well as field criteria. For example, a search command can filter events based on the word “warning” or filter events based on a field value “10.0.1.2” associated with a field “clientip.” See Col. 30 lines 8-19; Rows in the table 424 may represent individual records, where each record corresponds to an event in the disk 422 that satisfied the filter criteria. Columns in the table 424 may correspond to different fields of an event or record, such as “user,” “count,” percentage,” “timestamp,” or the raw machine data of an event, etc.); and
store the tuple data structure in a database table as multidimensional time-series data indexed by the tuple timestamp (See Col. 18 lines 61-67, Col. 19 lines 1-10, and Fig. 2; the indexing system 112 stores the events with an associated timestamp in the storage system 116, which may be in a local data store and/or in a shared storage system. Timestamps enable a user to search for events based on a time range. In some embodiments, the stored events are organized into “buckets,” where each bucket stores events associated with a specific time range based on the timestamps associated with each event. See Col. 29 lines 43-53; The results obtained or generated in response to a command in a query can be considered a set of results data. The set of results data can be passed from one command to another in any data format. In one embodiment, the set of result data can be in the form of a dynamically created table. Each command in a particular query can redefine the shape of the table. In some implementations, an event retrieved from an index in response to a query can be considered a row with a column for each field value. Columns can contain basic information about the data and/or data that has been dynamically extracted at search time. See also Fig. 3A-C).
Claims 6 and 8 is taught by Han as described for claims 2 and 4, respectively.
Claim 9. Han discloses [t]he method of claim 1,
Han further discloses wherein applying the filtering condition data structure comprises initiating a filtering window in response to detection of an event associated with the base device name, computing an elapsed time relative to the filtering window, and excluding sensing values from population of the multidimensional values array when the elapsed time exceeds the time limit (See Col. 29 lines 1-23; ... commands may be used to filter unwanted information out of the results, extract more information, evaluate field values, calculate statistics, reorder the results, create an alert, create summary of the results, or perform some type of aggregation function. In some embodiments, the summary can include a graph, chart, metric, or other visualization of the data ... a command at the beginning of a query can perform a “filtering” step by retrieving a set of data based on a condition (e.g., records associated with server response times of less than 1 microsecond). The results of the filtering step can then be passed to a subsequent command in the pipeline that performs a “processing” step (e.g. calculation of an aggregate value related to the filtered events such as the average response time of servers with response times of less than 1 microsecond). Furthermore, the search command can allow events to be filtered by keyword as well as field criteria. For example, a search command can filter events based on the word “warning” or filter events based on a field value “10.0.1.2” associated with a field “clientip.” See Col. 30 lines 8-19; Rows in the table 424 may represent individual records, where each record corresponds to an event in the disk 422 that satisfied the filter criteria. Columns in the table 424 may correspond to different fields of an event or record, such as “user,” “count,” percentage,” “timestamp,” or the raw machine data of an event, etc.).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Ortiz (US 2010/0131533) – Related art in the area of organization and communication of visual data, (Abstract; A computer-based system enables the creation of a time series based sequence of observations of a selected object. Each observation consists of a predefined, fixed set of standardized object views from which metadata about the visual data can be automatically determined and associated with the views. A set of standardized views and associated metadata, captured in an observation at a point in time, enables comparison of changes to a specific object over time on a view-by-view basis, or changes to a specific object over time in comparison to second reference object of the same type as the first object on a view-by-view basis. Metadata about the object in the domain are organized and made available in the domain specific processing system to support visual search, retrieval, analysis, and decision making by users within the domain).
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 extension fee 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 date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ABDELBASST TALIOUA whose telephone number is (571)272-4061. The examiner can normally be reached on Monday-Thursday 7:30 am - 5:30 pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Oscar Louie can be reached on 571-270-1684. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see https://ppair-my.uspto.gov/pair/PrivatePair. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/Abdelbasst Talioua/Primary Examiner, Art Unit 2445
Prosecution Insights