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 .
DETAILED ACTION
1. The pending claims 1-22 are presented for examination.
Claim Rejections - 35 USC § 103
2. 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.
3. This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
4. 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.
5. The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
6. Claims 1-2, 5, 7-10, 13 and 15-18 are rejected under 35 U.S.C. 103 as being unpatentable over SRIVASTAVA et al (US 20230367783 A1, hereinafter “SRIVASTAVA”) in view of BAIRD et al (U.S. Patent 11494493 B1 hereinafter, “BAIRD”), and further in view of Akkary et al (US 20030033511 A hereinafter, “Akkary”).
7. With respect to claim 1,
SRIVASTAVA discloses
a system comprising:
a non-transitory memory; and
one or more hardware processors coupled to the non-transitory memory and configured to read instructions from the non-transitory memory to cause the system to perform operations comprising:
loading data processing configurations for a data processing pipeline;
creating a plurality of processing threads for the data processing configurations of the application,
processing data received from a first system endpoint using the plurality of processing threads in a sequential order; and
delivering the processed data to a second system endpoint (SRIVASTAVA [0005], [0014], [0032], [0035] – [0037], [0046], [0049], [0051], [0054] - [0059], [0060] – [0066], [0069], [0071] – [0072], [0077] e.g. [0005] File-based Datasets may include system generated log files, application data, data which is periodically being exported and dumped frequently from external systems, enterprise buses, and the like. The files can be stored over SFTP, Shared Network Storage, Amazon S3, and the like. [0032] In an exemplary embodiment, the one or more first computing devices (102) may include a plurality of Distributed Source Systems such as Kafka, The Hadoop Distributed File System (HDFS)and the like. And the one or more second computing devices (104) may include a plurality of Distributed Storage Systems such as Elasticsearch, Hive, HDFS but not limited to the like with pluggable transformation and customized throughput, rate control, throttle and embedded Fault Tolerance. [0035] The data ingestion module (110) may be configured to provide scaling, parallelism and throughput to provide data-driven insights based on the predefined configuration parameters. The data ingestion module (110) may ingest and process streaming and batch data packets and a combination thereof by a plurality of processing logic modules associated with the data ingestion module (110), and wherein the ingested data may be passed through a plurality of micro batches, each micro-batch corresponding to a specific thread. In an embodiment, the processing logic modules may be pluggable and user defined. [0036] The set of data packets after being analysed and processed may be written into one or more second computing devices (104) (also referred to as sinks (104)). [0037] In an exemplary embodiment, the plurality of second computing devices (104) may act as sink for a set of data packets from the same first computing device (102). The data ingestion module (110) may be configured to ingest the set of data packets in real time or during a pre-determined time and the set of data packets may be compressed and arranged in a predefined format in real time to be stored in a configurable storage associated with the second computing device (104) or hosted in any given time without disrupting any flow of data. [0049] In an exemplary embodiment, the distributed processing and streaming module (304) may include APACHE SPARK, STORM, HIVE, KAFKA. FLINK, NIFI and the like. 0051] As illustrated, in an aspect, the proposed system may include a plurality of source connectors (406-1, 406-2 . . . 406-n) to connect to source data systems (302) and fetch data which may be ingested and processed. An application developer (402) may maintain a pluggable processing logic and a predefined configuration parameter. The data fetched by the source connectors may be then sent to an integrated data logistics platform such as but not limited to an Apache NIFI (408) and Apache Spark (410) and from the Apache NIFI (408) and Apache Spark (410), the data may be stored in an interim storage layer such as but not limited to Hadoop Distributed File System (HDFS) TD (412). A Configurable Reader (414), may take a schema from the Schema Registry (414-1) according to the predefined configuration parameters provided and then may read the data with the schema. A Data Quality Module (414-2) may log a plurality of bad input records from the data into a separate error queue (416). The data after removal of the plurality of bad input records by the data quality module (414-2) may be sent to a processor that may include pluggable transformation module (418). The data may be then sent to a Writer (420) which may write the data to a sink storage system (422). A plurality of sinks such as HDFS, HIVE REDIS, ELASTIC SEARCH but not limited to the like can be configured for the same application. [0055] In another exemplary embodiment, as illustrated in FIG. 5B, the streaming data sources may pertain to the event streaming platform such as but not limited to MQ or Kafka based at block 514 but not limited to it. [0056] In yet another exemplary embodiment, the ingestion framework at block 508 may directly read from the event streaming platform such as a Kafka topic using the data receiver framework (or herein as an example a Kafka receiver framework) in micro-batches, may write the batch to HDFS, may spark read the HDFS File, may process the data and write the data into the sink or the Hive. [0059] In an embodiment, for triggering any pipeline, a spark submit script may be required. Based on parameters in the spark script, the predefined configuration parameters may get loaded at runtime. [0060] In an embodiment, source data may be read based on the predefined configuration parameters such as format of the incoming data, schema file location, number of files to be processed in each batch and the like. [0062] In an embodiment, transformation may happen on an incoming data based on transformation logic available for a given source type. [0069] In another embodiment, the data from the sources may be using the data Ingestion module by first moving the data from the HiveMQ and the Solace to the Kafka and then reading the messages from Kafka in micro-batch fashion using the Kafka Receiver and after processing writing them to a table. Since there may be a plurality of devices in FTTX and may follow the same pattern, the fata ingestion module may allow to quickly develop such ingestion pipelines. [0077] Thus, the present disclosure provides a unique and inventive solution for facilitating an application developer to quickly plugin his/her logic and ingest data into Big Data Eco-System from a variety of sources to a plurality of sinks with minimum effort. … The processing rate and parallelism of an application can be scaled up and down according to the requirement with just few configuration changes. Further a data quality check module may check data and log any bad records coming from the source. Multiple sink capability may further allow the system to write to multiple sink devices from the same application [as
loading data processing configurations (e.g. An application developer (402) may maintain a pluggable processing logic and a predefined configuration parameter … A Configurable Reader (414), may take a schema from the Schema Registry (414-1) according to the predefined configuration parameters provided and then may read the data with the schema … The data after removal of the plurality of bad input records by the data quality module (414-2) may be sent to a processor that may include pluggable transformation module (418) … transformation may happen on an incoming data based on transformation logic available for a given source type … few configuration changes) for a data processing pipeline (e.g. ingestion pipeline);
creating a plurality of processing threads (e.g. multi-threaded and micro-batch fashion; threads - each micro-batch corresponding to a specific thread) for the data processing configurations of the application,
processing (e.g. ingest – [0056] In yet another exemplary embodiment, the ingestion framework at block 508 may directly read from the event streaming platform such as a Kafka topic using the data receiver framework (or herein as an example a Kafka receiver framework) in micro-batches; threads - each micro-batch corresponding to a specific thread) data received from a first system endpoint (e.g. sink) using the plurality of processing threads (e.g. multi-threaded and micro-batch fashion; threads - each micro-batch corresponding to a specific thread) in a sequential order (e.g. streaming data sources from source data systems); and
delivering the processed data to a second system endpoint (e.g. sink)]).
Although SRIVASTAVA substantially teaches the claimed invention, SRIVASTAVA does not explicitly indicate upon startup of an application executing in a serverless computing environment.
BAIRD teaches the limitations by stating upon startup of an application executing in a serverless computing environment (Baird col. 3 line 55 - col. 5 line 8, col. 12 lines 14-41, col. 21 lines 22-41 e.g. [col. 3 line 55 - col. 5 line 8] (13)… cryptographically verifiable build procedure or pipeline in various embodiments. … (14) After the executable version of the application is created and stored, the SVMS may be in a position to deploy the executable version of the application, e.g., on behalf of an application owner or designer. According to at least one embodiment, in response to a deployment request received via a programmatic interface, the SVMS may cause the executable version to be deployed at an execution resource of a dynamically provisioned (“server-less”) computing service of the kind mentioned above. … The executable version of the application may then be started up or run at the selected execution resource, and may begin its operations with an initialization phase in which one or more processes or threads are started in some embodiments. … (15) In at least one embodiment, upon starting up, and before any application requests are received or serviced, a process or thread of the application (which was launched via the deployed executable version of the application) may be configured to automatically submit a programmatic key request to the SVMS from the execution resource. … [col. 12 lines 14-41] (40) … may be added automatically to the baseline source code of the application as it passes through a pipeline similar to that shown in FIG. 2. … (41) A resource state analyzer 316 of the SVMS may extract various elements of state information 405 of the execution resource 360 in response to receiving the key request 371 in some embodiments, as indicated in FIG. 3c. … analyze records stored at local event logs 365 and/or external event logs 368, and so on. The state analyzer may construct a representation of an expected configuration of the execution resource, and compare it to the actual configuration as discerned from the information 405 and the key request 371. [col. 21 lines 22-41] (79) … In some embodiments, I/O interface 9030 may perform any necessary protocol, timing or other data transformations to convert data signals from one component (e.g., system memory 9020) into a format suitable for use by another component (e.g., processor 9010)).
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the invention, in view of the teachings of SRIVASTAVA and BAIRD, to provide a system and a method that can facilitate integration of storing, processing as well as analysing big data (SRIVASTAVA [0007]).
Although SRIVASTAVA and Baird combination substantially teaches the claimed invention, they do not explicitly indicate
wherein the plurality of processing threads are created in a reverse order, such that at least one subsequent thread is created before at least one initial thread;
such that the data is processed with the at least one initial thread before it is processed by the at least one subsequent thread.
Akkary teaches the limitations by stating
wherein the plurality of processing threads are created in a reverse order (e.g. the program order of children nodes of the thread are in the reverse of the order in which the threads were started (created)), such that at least one subsequent thread is created before at least one initial thread (e.g. the thread) (Akkary [0227] – [0228] e.g. [0227] Threads begin at the instruction following a backward branch or a function call. That is, threads begin at the next instruction assuming the backward branch were not taken or the function was not called (as illustrated by threads T2 in FIGS. 4 and 5). In so doing, from the perspective of a thread (node), the program order of children nodes of the thread are in the reverse of the order in which the threads were started (created). For example, in FIG. 6, in time order, execution of thread T2 begins before execution of thread T3, but in program order, thread T3 occurs before thread T2. [0228] In one embodiment, three events may cause a thread to be removed from the tree: (1) A thread at the root of the tree is removed when the thread is retired. When the thread at the root is retired, the thread (node) that is next in program order becomes the root and nodes are reassigned accordingly. (2) A thread that is last in program order is removed from the tree to make room for a thread higher in program order to be added to the tree. In this respect, the tree acts as a last-in-first-out (LIFO) stack. …);
such that the data is processed with the at least one initial thread before it is processed by the at least one subsequent thread (Akkary [0227] – [0228] e.g. [0227] Threads begin at the instruction following a backward branch or a function call. That is, threads begin at the next instruction assuming the backward branch were not taken or the function was not called (as illustrated by threads T2 in FIGS. 4 and 5). In so doing, from the perspective of a thread (node), the program order of children nodes of the thread are in the reverse of the order in which the threads were started (created). For example, in FIG. 6, in time order, execution of thread T2 begins before execution of thread T3, but in program order, thread T3 occurs before thread T2. [0228] In one embodiment, three events may cause a thread to be removed from the tree: (1) A thread at the root of the tree is removed when the thread is retired. When the thread at the root is retired, the thread (node) that is next in program order becomes the root and nodes are reassigned accordingly. (2) A thread that is last in program order is removed from the tree to make room for a thread higher in program order to be added to the tree. In this respect, the tree acts as a last-in-first-out (LIFO) stack. …).
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the invention, in view of the teachings of SRIVASTAVA, BAIRD and Akkary, to provide a system and a method that can facilitate integration of storing, processing as well as analyzing big data (SRIVASTAVA [0007]).
8. With respect to claim 2,
BAIRD further discloses wherein the serverless computing environment comprises a cloud computing environment without designated server clusters that perform the operations, and wherein the operations are performed by the system using executable code in the cloud computing environment configured to execute application conditions of the data processing configurations for evaluations and transformations of the data (Baird col. 2 line 38 – col. 3 line 4, col. 16 lines 27-42 e.g. cloud-computing environment).
9. With respect to claim 5,
SRIVASTAVA further discloses delivering, using a data sink configured to receive the processed data as a destination node, the processed data to system endpoints using the at least one subsequent thread, wherein the system endpoints comprise at least one of a user computing device, an administrator node, or a destination network address (SRIVASTAVA [0005], [0014], [0032], [0035] – [0037], [0046], [0049], [0051], [0055] - [0059], [0060] – [0066], [0069], [0071] – [0072], [0077] and Fig. 1).
10. With respect to claim 7,
SRIVASTAVA further discloses
executing software processors configured to provide data transformation capabilities for singletons from the data and batches from the data; and
formatting the data in a data format used by system endpoints using the software processors (SRIVASTAVA [0005], [0014], [0032], [0035] – [0037], [0046], [0049], [0051], [0055] - [0059], [0060] – [0066], [0069], [0071] – [0072], [0077] e.g. threads; according to Wikipedia: In computer science, a thread of execution is the smallest sequence of programmed instructions that can be managed independently by a scheduler, which is typically a part of the operating system.[1] In many cases, a thread is a component of a process).
11. With respect to claim 8,
SRIVASTAVA further discloses wherein the data is associated with at least one of a user login, a system activity, a security event log, or a system audit log (SRIVASTAVA [0073] e.g. [0073] In yet another embodiment, Firewall data may be event logs generated for all connections established to a plurality of servers on a Cisco firewall and the like. The logs may be sent to Rsyslog server but not limited to it. The Rsyslog server may write the data into local files and NIFI may write the data into HDFS and file locations on HDFS. Using the data ingestion module, data from HDFS may be consumed and written to Hive. Data volume for the source may be at least 2 TB a day), and wherein the operations further comprise:
tracing the data through the data processing pipeline, wherein the tracing identifies a data format utilized to transform the data and system endpoints that receive the data (SRIVASTAVA [0005], [0014], [0032], [0035] – [0037], [0046], [0049], [0051], [0055] - [0059], [0060] – [0066], [0069], [0071] – [0072], [0077] e.g. pipeline; format; sink).
12. With respect to claim 9,
SRIVASTAVA further discloses
wherein the first processing thread transforms the data into a data format (SRIVASTAVA [0005], [0014], [0032], [0035] – [0037], [0046], [0049], [0051], [0054] - [0059], [0060] – [0066], [0069], [0071] – [0072], [0077] e.g. format; schema) utilized by a second system endpoint designated to receive the data.
13. Claims 10, 13 and 15-16 are same as claims 2, 5 and 7-8 and are rejected for the same reasons as applied hereinabove.
14. Claims 17-18 are same as claims 9-10 and are rejected for the same reasons as applied hereinabove.
15. Claims 3-4, 11-12 and 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over SRIVASTAVA in view of BAIRD and AKKARY, and further in view Billa.
16. With respect to claim 3,
Although SRIVASTAVA, BAIRD and AKKARY combination substantially teaches the claimed invention, they do not explicitly indicate wherein the application conditions comprise a plurality of operators each having at least one inspector for the data and at least one logical action for the at least one inspector, and wherein each inspector comprises a coded expression for inspecting the data for routing to system endpoints through the data processing pipeline.
Billa teaches the limitations by stating wherein the application conditions comprise a plurality of operators each having at least one inspector for the data and at least one logical action for the at least one inspector, and wherein each inspector comprises a coded expression for inspecting the data for routing to system endpoints through the data processing pipeline (Billa [0155], [0176] – [0180] e.g. [0176] When compiling a set of regular expressions into instructions of an NFA graph, the compiler may generate macro-instructions operable by NFA engines 216. For example, rather than NFA engines 216 executing a first instruction for searching for the character ‘a’, a second instruction for searching for the character and a third instruction for searching for the character ‘c’ to search for the string ‘abc’, NFA engines 216 may executing a single instruction for searching for the string ‘abc’. [0177] In this way, the compiler may reduce a quantity of instructions used to traverse an NFA graph. The compiler thereby reduces an amount of data stored for the NFA graph, which may reduce power usage of RegEx accelerator 211. Moreover, using macro-instructions may increase a number of symbols that are processed during a single clock cycle, thereby resulting in increasing a search speed of RegEx accelerator 211. [0178] Each of NFA engines 216 includes one or more hardware threads configured to execute respective search processes according to an NFA. Each of the threads may include, for example, one or more respective memories (e.g., registers, caches, or the like) for storing a program counter for a next instruction for an arc of an NFA and a current position of a payload data being inspected. That is, the threads may store data representing a program counter and a payload offset. [0179] NFA engines 216 also include respective processing units for determining the current symbol and one or more subsequent symbols of the payload segment that satisfy a match condition. The threads of each of NFA engines 216 may share a common processing unit, or the threads may each include a corresponding processing unit. In general, the processing unit determines whether traversal of the NFA graph through application of the symbols of the payload results in reaching a match node of the NFA graph. [0180] The processing unit or the thread of the corresponding one of NFA engines 216 may then update a program counter and the payload offset. The processing unit may continue this evaluation until either the entire set of payload data has been examined without satisfying a match condition, or resulting in an instruction that is a final instruction indicating a matching condition. In response to satisfying the matching condition, the thread of the one of NFA engines 216 may return data indicating that a match has been identified.).
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the invention, in view of the teachings of SRIVASTAVA, BAIRD, AKKARY and Billa, to provide a system and a method that can facilitate integration of storing, processing as well as analysing big data (SRIVASTAVA [0007]).
17. With respect to claim 4,
SRIVASTAVA further discloses wherein the data processing pipeline is based on pre-coded data packages that are configurable by users implementing the data processing pipeline with the system (SRIVASTAVA [0005], [0014], [0032], [0035] – [0037], [0046], [0049], [0051], [0055] - [0059], [0060] – [0066], [0069], [0071] – [0072], [0077] e.g. An application developer (402) may maintain a pluggable processing logic and a predefined configuration parameter … A Configurable Reader (414), may take a schema from the Schema Registry (414-1) according to the predefined configuration parameters provided and then may read the data with the schema … The data after removal of the plurality of bad input records by the data quality module (414-2) may be sent to a processor that may include pluggable transformation module (418) … transformation may happen on an incoming data based on transformation logic available for a given source type … few configuration changes).
Billa further discloses wherein the pre-coded data packages comprise executable code for data transformation patterns that identify patterns of data and transform the patterns of data to designated system endpoints (Billa [0003], [0013], [0034], [0089], [0098], [0048], [0145] – [0148] e.g. patterns – [0003] In general, the DPUs are specialized data-centric processors architected for efficiently applying data manipulation operations (e.g., regular expression operations to match patterns, filtering operations, data retrieval, compression/decompression and encryption/decryption) to streams of data units, such as packet flows having network packets, a set of storage packets being retrieved from or written to storage or other data units. [0089] A stream of one type may be transformed into another type as a result of processing. [0098] Analytics functions 134 may, for example, include analytical data processing functions related to a customizable pipeline of data transformations).
18. Claims 11-12 are same as claims 3-4 and are rejected for the same reasons as applied hereinabove.
19. Claims 19-20 are same as claims 3-4 and are rejected for the same reasons as applied hereinabove.
20. Claims 6 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over SRIVASTAVA in view of BAIRD and AKKARY, and further in view Bishop.
21. With respect to claim 6,
SRIVASTAVA further discloses wherein the data is ingested on a per-item basis and in a time series of each datum in the data ingested by the system (SRIVASTAVA [0035] – [0038] e.g. real time streaming data).
Although SRIVASTAVA, BAIRD and AKKARY combination substantially teaches the claimed invention, they do not explicitly indicate wherein the data is ingested on a per-item basis and in a time series based on timestamps of each datum in the data ingested by the system.
Bishop teaches the limitations by stating wherein the data is ingested on a per-item basis and in a time series based on timestamps (Bishop [0043], [0066], [0085] e.g. timestamp indicating when the event occurred) of each datum in the data ingested by the system.
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the invention, in view of the teachings of SRIVASTAVA, BAIRD, AKKARY and Bishop, to provide a system and a method that can facilitate integration of storing, processing as well as analysing big data (SRIVASTAVA [0007]).
22. Claim 14 is same as claim 6 and is rejected for the same reasons as applied hereinabove.
23. Claim 21 is rejected under 35 U.S.C. 103 as being unpatentable over SRIVASTAVA in view of BAIRD and AKKARY, and further in view Perumalla et al (US 20230401909 A1 hereinafter, “Perumalla”).
24. With respect to claim 21,
Although SRIVASTAVA, BAIRD and AKKARY combination substantially teaches the claimed invention, they do not explicitly indicate wherein each of the data processing configurations is representative of a coded operation that provides a method for evaluating the data using a user-defined success criterion or failure criterion.
Perumalla teaches the limitations by stating wherein each of the data processing configurations is representative of a coded operation that provides a method for evaluating the data using a user-defined success criterion or failure criterion (Perumalla [0036] e.g. [0036] Some embodiments of the present invention may include one, or more, of the following operations, features, characteristics and/or advantages: (i) different edge devices (for example, autonomous vehicles) perform different ways of self-adapting the code; (ii) while storing the code in a Cloud hosted branch, the code merging and branching module identifies the changes in the code, and accordingly store the same in the appropriate branch of the version control tool; (iii) the system (for example, autonomous vehicles) will evaluate the success and failure criteria of addressing the contextual scenarios; and/or (iv) the system evaluates how the code is self-adapted, and accordingly, identify if the self-adaptation of the code is completed such that the code can be base lined and stored in the appropriate branch version control system.).
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the invention, in view of the teachings of SRIVASTAVA, BAIRD, AKKARY and Perumalla, to provide a system and a method that can facilitate integration of storing, processing as well as analysing big data (SRIVASTAVA [0007]).
25. Claim 22 is rejected under 35 U.S.C. 103 as being unpatentable over SRIVASTAVA in view of BAIRD, AKKARY and Perumalla, and further in view TOYODA et al (WO 2011043293 A1 hereinafter, “TOYODA”).
26. With respect to claim 22,
Perumalla teaches wherein the coded operation is implemented through at least one inspector and at least one operator, wherein each inspector is representative of an inspection method for evaluating data based on content (Perumalla [0036] e.g. [0036] Some embodiments of the present invention may include one, or more, of the following operations, features, characteristics and/or advantages: (i) different edge devices (for example, autonomous vehicles) perform different ways of self-adapting the code; (ii) while storing the code in a Cloud hosted branch, the code merging and branching module identifies the changes in the code, and accordingly store the same in the appropriate branch of the version control tool; (iii) the system (for example, autonomous vehicles) will evaluate the success and failure criteria of addressing the contextual scenarios; and/or (iv) the system evaluates how the code is self-adapted, and accordingly, identify if the self-adaptation of the code is completed such that the code can be base lined and stored in the appropriate branch version control system.), Internet Protocol (IP) address, length, regular expression, or strings.
Although SRIVASTAVA, BAIRD, AKKARY and Perumalla combination substantially teaches the claimed invention, they do not explicitly indicate each operator is representative of a collection of multiple inspectors that implement an evaluation pattern and utilize an operator.
TOYODA teaches the limitations by stating each operator is representative of a collection of multiple inspectors that implement an evaluation pattern and utilize an operator (TOYODA [0063] e.g. evaluation; pattern; operator(inspector)).
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the invention, in view of the teachings of SRIVASTAVA, BAIRD, AKKARY, Perumalla and TOYODA, to provide a system and a method that can facilitate integration of storing, processing as well as analysing big data (SRIVASTAVA [0007]).
Conclusion
The prior art made of record, listed on form PTO-892, and not relied upon, if any, is considered pertinent to applicant's disclosure.
27. The examiner requests, in response to this office action, support be shown for language added to any original claims on amendment and any new claims. That is, indicate support for newly added claim language by specifically pointing to page(s) and line no(s) in the specification and/or drawing figure(s). This will assist the examiner in prosecuting the application.
28. When responding to this office action, Applicant is advised to clearly point out the patentable novelty which he or she thinks the claims present, in view of the state of the art disclosed by the reference cited or the objections made. He or she must also show how the amendments avoid such references or objections See 37 CFR 1.111(c).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SYLING YEN whose telephone number is (571)270-1306. The examiner can normally be reached on 8am-4:30pm.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Sanjiv Shah can be reached at 571-272-4098. 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 http://pair-direct.uspto.gov. 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.
/SYLING YEN/Primary Examiner, Art Unit 2166
April 30, 2026
Prosecution Insights