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 application filed on December 11th, 2024. In this office action:
Claims 1-8 are pending.
Claims 1-8 are rejected.
Drawings
The drawings submitted on December 11th, 2024 have been considered and accepted.
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-8 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:
converting sensing data received from an IoT device into an event according to a preset first data format {performing a conversion on gathered data}. The “received” data is reasonably interpreted by the Examiner as gathering/collecting data; in addition, 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 received and converted or any details on the gathered data and the conversion. Under its broadest reasonable interpretation when read in light of the specification, the claimed “converting sensing data received” from an IoT device into an event according to a preset first data format encompasses gathering data and performing a process of translating the gathered data from one format to another (i.e., first format).
converting the event into a tuple according to a preset second data format {performing a second conversion on gathered data}. The gathered data undergoes a second 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 “converting” the event into a tuple according to a preset second data format encompasses a process of translating the gathered data from one format (i.e., first format) to another (i.e., second format).
storing the time series data in a database table in a multidimensional time series data format based on the tuple. 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 an input interface to receive sensing data and a processor to convert the sensing data into an event, convert the event into a tuple, and store the time series data in a database table. The input interface and the processor 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 input interface to receive sensing data and a processor to convert the sensing data into an event, convert the event into a tuple, and store the time series data in a database table 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 3 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 3 depends on claim 1, and it further recites “wherein converting the event comprises: converting the event into the tuple according to the second data format including time series data including a timestamp and a value, a timestamp indicating an event generation time and having a preset format, and a value having an arrangement structure including an integer or decimal value.” The claim is further limiting the definition of converting the event, 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 3 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 7 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 7 depends on claim 5, and it further recites “convert the event into the tuple according to the second data format including time series data including a timestamp and a value, a timestamp indicating an event generation time and having a preset format, and a value having an arrangement structure including an integer or decimal value.” The claim is further limiting the definition of converting the event, 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 7 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 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-8 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] method for converting and storing time series data of Internet of Things (IoT) events performed by a system for converting and storing the time series data of the 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 method comprising:
converting sensing data received from an IoT device into an event according to a preset first data format (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. 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. 2 lines 38-57, Col. 4 lines 7-16, and Col. 18 lines 1-11. Examiner’s interpretation: Applicant’s specification and Claim 2 below, teach “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”);
converting the event into a tuple according to a preset second data format (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 also Col. 18 lines 12-60. Examiner’s interpretation: Applicant’s specification and Claim 3 below, teach “converting the event into the tuple according to the second data format including time series data including a timestamp and a value, a timestamp indicating an event generation time and having a preset format, and a value having an arrangement structure including an integer or decimal value”); and
storing the time series data in a database table in a multidimensional time series data format based on the tuple (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 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 3. Han discloses [t]he method of claim 1,
Han further discloses wherein converting the event comprises: converting the event into the tuple according to the second data format including time series data including a timestamp and a value, a timestamp indicating an event generation time and having a preset format, and a value having an arrangement structure including an integer or decimal value (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 (a timestamp indicating an event generation time), to use the timestamp of a previous event, or use any other rules for determining timestamps, etc. See also Col. 18 lines 12-60 and Fig. 3A-C).
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:
convert the sensing data into an event according to a preset first data format (See Col. 16 lines 48-67, Col. 17 lines 1-20 and Fig. 2; 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. 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. 2 lines 38-57, Col. 4 lines 7-16, and Col. 18 lines 1-11. Examiner’s interpretation: Applicant’s specification and Claim 2 below, teach “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”),
convert the event into a tuple according to a preset second data format (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 also Col. 18 lines 12-60. Examiner’s interpretation: Applicant’s specification and Claim 3 below, teach “converting the event into the tuple according to the second data format including time series data including a timestamp and a value, a timestamp indicating an event generation time and having a preset format, and a value having an arrangement structure including an integer or decimal value”), and
store the time series data in a database table in a multidimensional time series data format based on the tuple (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 Fig. 3A-C).
Claims 6-8 is taught by Han as described for claims 2-4, respectively.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Du (US 2023/0095870) – Related art in the area of IoT security event correlation, (Abstract; Correlating Internet of Things (IoT) security events is disclosed. A set of security events is received. A graph is generated, where nodes of the graph correspond to at least some of the received security events in the set. The edges in the graph correspond to identifiable patterns of correlation. A determination of whether or not the generated graph matches a prebuilt scenario is determined and a remedial action is taken in response to the determination).
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/Examiner, Art Unit 2445