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
Claims 1-20 are pending and are considered in this Non-Final Office action.
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 therefore, subject to the
conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-patentable subject matter. The claims are directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more. In accordance with Step 1, it is first noted that the claimed apparatus in claims 1-10 and method in claims 11-20.
In accordance with Step 2A, Prong One, claims 1- 20, the claimed invention recites an abstract idea. Specifically, the independent claim(s) recite(s) (abstract idea recited in italics and additional elements recited in bold):
Claim 1:
A system for self-service data quality control, the system comprising: one or more memories; and one or more processors, communicatively coupled to the one or more memories, configured to: obtain a first set of user-defined data quality rules for an incoming dataset and a second set of user-defined data quality rules for an outgoing dataset; perform a first data quality validation check for the incoming dataset based on a comparison of data quality metrics associated with the incoming dataset and the first set of user-defined data quality rules for the incoming dataset; execute a data processing job to process the incoming dataset based on the incoming dataset passing the first data quality validation check, wherein the data processing job is executed to generate the outgoing dataset based on the incoming dataset; perform a second data quality validation check for the outgoing dataset based on a comparison of data quality metrics associated with the outgoing dataset and the second set of user-defined data quality rules for the outgoing dataset; and publish the outgoing dataset to a downstream data sink based on the outgoing dataset passing the second data quality validation check.
Claim 10:
A method for data quality validation, comprising: receiving, by a data processing system, an incoming dataset from a data source; obtaining, by the data processing system, a set of user-defined data quality rules for the incoming dataset; performing, by the data processing system, a data quality validation check for the incoming dataset based on a comparison of data quality metrics associated with the incoming dataset and the set of user-defined data quality rules for the incoming dataset; and aborting, by the data processing system, a data processing job to process the incoming dataset based on the incoming dataset failing the data quality validation check.
Claim 16:
A non-transitory computer-readable medium storing a set of instructions, the set of instructions comprising: one or more instructions that, when executed by one or more processors of a data processing system, cause the data processing system to: receive an incoming dataset from a data source; execute a data processing job to process the incoming dataset, wherein the data processing job is executed to generate an outgoing dataset based on the incoming dataset; obtain a set of user-defined data quality rules for the outgoing dataset; perform a data quality validation check for the outgoing dataset based on a comparison of data quality metrics associated with the outgoing dataset and the set of user-defined data quality rules for the outgoing dataset; and send an alert to a client device to indicate that the outgoing dataset will not be published to a downstream data sink due to the outgoing dataset failing the data quality validation check.
The above-recited italicized limitations viewed as an abstract idea are mental processes (i.e., concepts performed in the human mind (including an observation, evaluation, judgment, opinion). The claimed invention is directed to evaluating datasets according to user-defined data quality rules that define a validity check to determine whether the dataset will be processed. Accordingly, the claims recite mental processes.
According to Step 2A, prong two, this judicial exception is not integrated into a practical application
because the use of bolded additional elements for receiving/transmitting data (e.g., obtain a first set of user-defined data quality rules for an incoming dataset and a second set of user-defined data quality rules for an outgoing dataset; publish the outgoing dataset to a downstream data sink based on the outgoing dataset passing the second data quality validation check; receive an incoming dataset from a data source; send an alert to a client device to indicate that the outgoing dataset will not be published to a downstream data sink due to the outgoing dataset failing the data quality validation check.; etc.); processing data in the form of evaluating (e.g., perform a first data quality validation check for the incoming dataset based on a comparison of data quality metrics associated with the incoming dataset and the first set of user-defined data quality rules for the incoming dataset; execute a data processing job to process the incoming dataset based on the incoming dataset passing the first data quality validation check, wherein the data processing job is executed to generate the outgoing dataset based on the incoming dataset; perform a second data quality validation check for the outgoing dataset based on a comparison of data quality metrics associated with the outgoing dataset and the second set of user-defined data quality rules for the outgoing dataset; performing, by the data processing system, a data quality validation check for the incoming dataset based on a comparison of data quality metrics associated with the incoming dataset and the set of user-defined data quality rules for the incoming dataset; and aborting, by the data processing system, a data processing job to process the incoming dataset based on the incoming dataset failing the data quality validation check; execute a data processing job to process the incoming dataset, wherein the data processing job is executed to generate an outgoing dataset based on the incoming dataset; obtain a set of user-defined data quality rules for the outgoing dataset; perform a data quality validation check for the outgoing dataset based on a comparison of data quality metrics associated with the outgoing dataset and the set of user-defined data quality rules for the outgoing dataset; etc.); storing data; and displaying data and repeating steps is merely implementing the abstract idea steps of valuing an idea in the manner of “apply it”. Specifically, the above bolded additional elements of the apparatus comprising one or more image devices, one or more communication devices, one or more network components, analysis engine and user interface are mere computer tools used to implement the steps of the abstract idea. The claim(s) does/do not include additional elements that are sufficient to practically apply the judicial exception because they, whether taken separately or as a whole, merely use conventional computer components or technology to receive, process, store and display data and thus do not provide an inventive concept in the claims.
In accordance with Step 2B, the claims only recite the above bolded additional elements. The additional elements are recited at a high-level of generality (i.e., as a generic computer for evaluating data quality of datasets with rules) such that it amounts no more than mere instructions to apply the exception using a generic computer component. 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. Further, as evidence of generic computer implementation and an indication that the claimed invention does not amount to significantly more, it is first noted in the Applicant’s Specification, in ¶0046-0050, “the device 300 may correspond to the client device 210, the data source 220, the data processing system 230, and/or the data sink 240 described herein. In some implementations, the client device 210, the data source 220, the data processing system 230, and/or the data sink 240 may include one or more devices 300 and/or one or more components of the device 300. As shown in Fig. 3, the device 300 may include a bus 310, a processor 320, a memory 330, an input component 340, an output component 350, and/or a communication component 360. The bus 310 may include one or more components that enable wired and/or wireless communication among the components of the device 300. The bus 310 may couple together two or more components of Fig. 3, such as via operative coupling, communicative coupling, electronic coupling, and/or electric coupling. For example, the bus 310 may include an electrical connection (e.g., a wire, a trace, and/or a lead) and/or a wireless bus. The processor 320 may include a central processing unit, a graphics processing unit, a microprocessor, a controller, a microcontroller, a digital signal processor, a field-programmable gate array, an application-specific integrated circuit, and/or another type of processing component. The processor 320 may be implemented in hardware, firmware, or a combination of hardware and software. In some implementations, the processor 320 may include one or more processors capable of being programmed to perform one or more operations or processes described elsewhere herein. The memory 330 may include volatile and/or nonvolatile memory. For example, the memory 330 may include random access memory (RAM), read only memory (ROM), a hard disk drive, and/or another type of memory (e.g., a flash memory, a magnetic memory, and/or an optical memory). The memory 330 may include internal memory (e.g., RAM, ROM, or a hard disk drive) and/or removable memory (e.g., removable via a universal serial bus connection). The memory 330 may be a non-transitory computer-readable medium. The memory 330 may store information, one or more instructions, and/or software (e.g., one or more software applications) related to the operation of the device 300. In some implementations, the memory 330 may include one or more memories that are coupled (e.g., communicatively coupled) to one or more processors (e.g., processor 320), such as via the bus 310. Communicative coupling between a processor 320 and a memory 330 may enable the processor 320 to read and/or process information stored in the memory 330 and/or to store information in the memory 330… The device 300 may perform one or more operations or processes described herein. For example, a non-transitory computer-readable medium (e.g., memory 330) may store a set of instructions (e.g., one or more instructions or code) for execution by the processor 320. The processor 320 may execute the set of instructions to perform one or more operations or processes described herein. In some implementations, execution of the set of instructions, by one or more processors 320, causes the one or more processors 320 and/or the device 300 to perform one or more operations or processes described herein. In some implementations, hardwired circuitry may be used instead of or in combination with the instructions to perform one or more operations or processes described herein. Additionally, or alternatively, the processor 320 may be configured to perform one or more operations or processes described herein. Thus, implementations described herein are not limited to any specific combination of hardware circuitry and software. As additional evidence of conventional computer implementation, it is noted in the MPEP, the courts have recognized that “receiving or transmitting data over a network, e.g., using the Internet to gather data” (See buySAFE, Inc. v. Google, Inc., 765 F.3d
1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014) (computer performs data quality checks according to data rules) to be well‐understood, routine, and conventional functions when they are claimed in a merely generic manner (See MPEP 2106.05(d)). From the interpretation of the MPEP and the Specification, one would reasonably deduce that the additional elements are merely embodies generic computers and generic computing functions.
Dependent claims 2-8, 12-14 and 17-19 further narrow the abstract idea of a mental
Process of performing evaluative steps by further defining hard fail rules and data quality rules/metrics used to evaluate datasets. Therefore, recite elements that narrow the metes and bounds of the abstract idea but do not practically apply the abstract idea or provide ‘something more’. The dependent claims do not remedy these deficiencies.
Dependent claims 9, 15 and 20 recite the additional element of “wherein the one or more instructions further cause the data processing system to: invoke a microservice to obtain the data quality metrics associated with the outgoing dataset.” Applicant’s Specification recites, in ¶0054, “the data quality system may invoke a microservice that evaluates data elements, records, or other features of the incoming dataset against the criteria, requirements, conditions, or other parameters associated with the user-defined data quality rules for the incoming dataset, and the microservice may generate data quality metrics (e.g., percentages, ratios, or other values) that indicate a degree to which the data elements, records, or other features of the incoming dataset satisfy the user-defined data quality rules.” It is clear from the clam language and the support in the Specification that the “microservice” is merely invoked as a tool to perform the evaluative steps of the claimed abstract idea. Therefore, the elements of dependent claims 9, 15 and 20 fail to practically apply the abstract idea, as it values the idea in the manner of “apply it”. The elements of the dependent claims also do not provide ‘something more.’
Dependent claim 11 recites the additional element, “sending an alert to a client device to indicate that the data processing job was aborted due to the incoming dataset failing the data quality validation check.” The “sending an alert to a client device” is a mere transmission of information performed following the failing of the evaluative step of a “data quality validation check.” The transmission of information is a generic computing function. This additional element of “sending an alert to a client device” adds an extra-solution activity to the claim and does not practically apply the abstract idea. Also, the elements of this dependent claim do not provide ‘something more.’
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
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.
Claim(s) 1-8, 10-14 and 16-20 are rejected under 35 U.S.C. 103 as being unpatentable over Douros et al. (United States Patent Application Publication, 2012/0216202, hereinafter referred to as Douros) in view of Sivaswamy et all (United States Patent Application Publication, 2023/0086307, hereinafter referred to as Sivaswamy).
As per Claim 1, Douros discloses a system for self-service data quality control, the system comprising:
one or more memories; and one or more processors, communicatively coupled to the one or more memories (Douros: ¶0050-0051), configured to: obtain a first set of… data quality rules (Douros: ¶0026: A checkpoint record includes rules for process values and information relevant to the current execution phase of the process.);
perform a first data quality validation check for the incoming dataset based on a comparison of data quality metrics associated with the incoming dataset and the first set of… data quality rules for the incoming dataset (Douros: ¶0025-0026 and 0038-0039: Data processing systems use a checkpointing technique for validation by using process values associated with the incoming data records being processed. The process values derived from the data records are compared to checkpoint rules to determine if the process values are logical points at which a checkpoint occurs.);
execute a data processing job to process the incoming dataset based on the incoming dataset passing the first data quality validation check, wherein the data processing job is executed to generate the outgoing dataset based on the incoming dataset (Douros: ¶0039: To execute the data processing job, the data set travels through a multi-process validation checkpoint, wherein each checkpoint state passes result downstream (e.g. producing an outgoing dataset) for further validation. See Fig. 3.);
perform a second data quality validation check for the outgoing dataset based on a comparison of data quality metrics associated with the outgoing dataset and the… data quality rules for the outgoing dataset (Douros: ¶0025-0026 and 0038-0039: Data processing systems uses a checkpointing technique for validation by using process values associated with the incoming data records being processed. The process values derived from the data records are compared to checkpoint rules to determine if the process values are logical points at which a checkpoint occurs. See Fig. 3-4where the process performs multiple validation checks.); and
publish the outgoing dataset to a downstream data sink based on the outgoing dataset passing the second data quality validation check (Douros: ¶0044: All processes have completed checkpoint states before being published to the data sink process. See Fig. 3).
Douros discloses processing rules for data quality. However, Douros does not explicitly disclose; however, Sivaswamy discloses:
obtain a first set of user-defined data quality rules for an incoming dataset and a second set of user-defined data quality rules for an outgoing dataset (Sivaswamy: ¶0022: Predefined rules for data quality are obtained to implement transformations on extracted data for data processing. See Figure 1 where the multiple sets of data quality rules are applied to incoming and outgoing datasets.).
and d) user-defined data quality rules (Sivaswamy: ¶0022: Predefined rules for data quality are obtained to implement transformations on extracted data for data processing. See Figure 1 where the multiple sets of data quality rules are applied to incoming and outgoing datasets.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention
to combine Douros with Sivaswamy’s data quality rules for data processing because the references are analogous/compatible, since each is directed toward features of checking datapoints for data processing, and because incorporating Sivaswamy’s data quality rules for data processing in Douros would have served Douros’ pursuit of implementing a checkpoint record that evaluates values and information of processed records (See Douros, ¶0026); and further obvious since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
As per Claim 2, Douros in view of Sivaswamy discloses the system of claim 1, wherein the first set… rules for the incoming dataset includes one or more hard fail rules and one or more fault-tolerant rules (Douros: See ¶0026-0027 where the checkpoint rules were based on checkpoint information such as process values the determines whether the data process fails. See ¶0037-0039 for fault tolerance rules.).
Douros discloses processing rules for data quality. However, Douros does not explicitly disclose; however, Sivaswamy discloses user-defined data quality rules (Sivaswamy: ¶0022: Predefined rules for data quality are obtained to implement transformations on extracted data for data processing. See Figure 1 where the multiple sets of data quality rules are applied to incoming and outgoing datasets.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention
to combine Douros with Sivaswamy’s data quality rules for data processing because the references are analogous/compatible, since each is directed toward features of checking datapoints for data processing, and because incorporating Sivaswamy’s data quality rules for data processing in Douros would have served Douros’ pursuit of implementing a checkpoint record that evaluates values and information of processed records (See Douros, ¶0026); and further obvious since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
Claim 12 and 17 depend on claims 10 and 16, respectively. While independent claims 10 and 16 vary from independent claim 1, the rejection of claim 2 addresses the limitations recited in claims 12 and 17. Therefore, same rejection above applies to claims 12 and 17.
As per Claim 3, Douros in view of Sivaswamy discloses the system of claim 2, wherein the one or more processors, to perform the first data quality validation check for the incoming dataset, are configured to: determine that the data quality metrics associated with the incoming dataset failed to satisfy one or more data quality rules among the… rules (Douros: ¶0025-0027 and 0038-0039: Data processing systems use a checkpointing technique for validation by using process values associated with the incoming data records being processed. The process values derived from the data records are compared to checkpoint rules to determine if the process values are logical points at which a checkpoint occurs. If the dataset fails the checkpoint, the processing can be terminated. See Fig. 3-4where the process performs multiple validation checks.); and determine that the incoming dataset passed the first data quality validation check based on the one or more failed data quality rules each being a fault-tolerant rule (Douros ¶0038-0039 and 0044: Following a checkpoint state that processes checkpoint information for data quality, a fault tolerance manager is initiated to execute further processing rules for passing the data through the stream.).
Douros discloses processing rules for data quality. However, Douros does not explicitly disclose; however, Sivaswamy discloses user-defined data quality rules (Sivaswamy: ¶0022: Predefined rules for data quality are obtained to implement transformations on extracted data for data processing. See Figure 1 where the multiple sets of data quality rules are applied to incoming and outgoing datasets.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention
to combine Douros with Sivaswamy’s data quality rules for data processing because the references are analogous/compatible, since each is directed toward features of checking datapoints for data processing, and because incorporating Sivaswamy’s data quality rules for data processing in Douros would have served Douros’ pursuit of implementing a checkpoint record that evaluates values and information of processed records (See Douros, ¶0026); and further obvious since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
As per Claim 4, Douros in view of Sivaswamy discloses the system of claim 1, wherein the one or more processors, to perform the first data quality validation check for the incoming dataset, are configured to: determine that the incoming dataset passed the first data quality validation check based on the data quality metrics associated with the incoming dataset satisfying one or more criteria associated with each data quality rule in the first set of… rules (Douros: ¶0025-0026 and 0038-0039: Data processing systems use a checkpointing technique for validation by using process values associated with the incoming data records being processed. The process values derived from the data records are compared to checkpoint rules to determine if the process values are logical points at which a checkpoint occurs. See Fig. 3-4 where the process performs multiple validation checks.).
Douros discloses processing rules for data quality. However, Douros does not explicitly disclose; however, Sivaswamy discloses user-defined data quality rules (Sivaswamy: ¶0022: Predefined rules for data quality are obtained to implement transformations on extracted data for data processing. See Figure 1 where the multiple sets of data quality rules are applied to incoming and outgoing datasets.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention
to combine Douros with Sivaswamy’s data quality rules for data processing because the references are analogous/compatible, since each is directed toward features of checking datapoints for data processing, and because incorporating Sivaswamy’s data quality rules for data processing in Douros would have served Douros’ pursuit of implementing a checkpoint record that evaluates values and information of processed records (See Douros, ¶0026); and further obvious since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
As per Claim 5, Douros in view of Sivaswamy discloses the system of claim 1, wherein the second set of … rules for the outgoing dataset includes one or more hard fail rules and one or more fault-tolerant rules (Douros: See ¶0026-0027 where the checkpoint rules were based on checkpoint information such as process values the determines whether the data process fails. See ¶0037-0039 for fault tolerance rules. See Fig. 3-4 where the process performs multiple validation checks.).
Douros discloses processing rules for data quality. However, Douros does not explicitly disclose; however, Sivaswamy discloses user-defined data quality rules (Sivaswamy: ¶0022: Predefined rules for data quality are obtained to implement transformations on extracted data for data processing. See Figure 1 where the multiple sets of data quality rules are applied to incoming and outgoing datasets.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention
to combine Douros with Sivaswamy’s data quality rules for data processing because the references are analogous/compatible, since each is directed toward features of checking datapoints for data processing, and because incorporating Sivaswamy’s data quality rules for data processing in Douros would have served Douros’ pursuit of implementing a checkpoint record that evaluates values and information of processed records (See Douros, ¶0026); and further obvious since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
As per Claim 6, Douros in view of Sivaswamy discloses the system of claim 5, wherein the one or more processors, to perform the second data quality validation check for the outgoing dataset, are configured to: determine that the data quality metrics associated with the outgoing dataset failed to satisfy one or more data quality rules among the second set of… rules (Douros: ¶0025-0026 and 0038-0039: Data processing systems use a checkpointing technique for validation by using process values associated with the incoming data records being processed. The process values derived from the data records are compared to checkpoint rules to determine if the process values are logical points at which a checkpoint occurs. See Fig. 3-4 where the process performs multiple validation checks with secondary requirements. Also, Fig. 3 demonstrates outgoing datasets through the multiple checkpoint process.); and determine that the outgoing dataset passed the second data quality validation check based on the one or more failed data quality rules each being a fault-tolerant rule (Douros ¶0038-0039 and 0044: Following a checkpoint state that processes checkpoint information for data quality, a fault tolerance manager is initiated to execute further processing rules for passing the data through the stream. See Fig. 3 demonstrates outgoing datasets through the multiple checkpoint process.).
Douros discloses processing rules for data quality. However, Douros does not explicitly disclose; however, Sivaswamy discloses user-defined data quality rules (Sivaswamy: ¶0022: Predefined rules for data quality are obtained to implement transformations on extracted data for data processing. See Figure 1 where the multiple sets of data quality rules are applied to incoming and outgoing datasets.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention
to combine Douros with Sivaswamy’s data quality rules for data processing because the references are analogous/compatible, since each is directed toward features of checking datapoints for data processing, and because incorporating Sivaswamy’s data quality rules for data processing in Douros would have served Douros’ pursuit of implementing a checkpoint record that evaluates values and information of processed records (See Douros, ¶0026); and further obvious since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
As per Claim 7, Douros in view of Sivaswamy discloses the system of claim 1, wherein the one or more processors, to perform the second data quality validation check for the outgoing dataset, are configured to: determine that the outgoing dataset passed the second data quality validation check based on the data quality metrics associated with the outgoing dataset satisfying one or more criteria associated with each data quality rule in the second set of… rules (Douros: ¶0025-0026 and 0038-0039: Data processing systems uses a checkpointing technique for validation by using process values associated with the incoming data records being processed. The process values derived from the data records are compared to checkpoint rules to determine if the process values are logical points at which a checkpoint occurs. See Fig. 3-4 where the process performs multiple validation checks with secondary requirements. Also, Fig. 3 demonstrates outgoing datasets through the multiple checkpoint process.).
Douros discloses processing rules for data quality. However, Douros does not explicitly disclose; however, Sivaswamy discloses user-defined data quality rules (Sivaswamy: ¶0022: Predefined rules for data quality are obtained to implement transformations on extracted data for data processing. See Figure 1 where the multiple sets of data quality rules are applied to incoming and outgoing datasets.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention
to combine Douros with Sivaswamy’s data quality rules for data processing because the references are analogous/compatible, since each is directed toward features of checking datapoints for data processing, and because incorporating Sivaswamy’s data quality rules for data processing in Douros would have served Douros’ pursuit of implementing a checkpoint record that evaluates values and information of processed records (See Douros, ¶0026); and further obvious since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
As per Claim 8, Douros in view of Sivaswamy discloses the system of claim 1.
Douros does not explicitly disclose; however, Sivaswamy discloses wherein the one or more processors are configured to obtain a current version of the first set of user-defined data quality rules for the incoming dataset and a current version of the second set of user-defined data quality rules for the outgoing dataset responsive to receiving the incoming dataset from an upstream data source (Sivaswamy: ¶0021 and 0043: Rules are mapped for use for data quality checking for data of different datasets. See ¶0021 where the system seeks the most updated rules and holds extracted data in-memory until the current version of data quality rules is applied.).
Douros discloses processing rules for data quality. However, Douros does not explicitly disclose; however, Sivaswamy discloses user-defined data quality rules (Sivaswamy: ¶0022: Predefined rules for data quality are obtained to implement transformations on extracted data for data processing. See Figure 1 where the multiple sets of data quality rules are applied to incoming and outgoing datasets.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention
to combine Douros with Sivaswamy’s data quality rules for data processing because the references are analogous/compatible, since each is directed toward features of checking datapoints for data processing, and because incorporating Sivaswamy’s data quality rules for data processing in Douros would have served Douros’ pursuit of implementing a checkpoint record that evaluates values and information of processed records (See Douros, ¶0026); and further obvious since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
Claim 14 and 19 depend on claims 10 and 16, respectively. While independent claims 10 and 16 vary from independent claim 1, the rejection of claim 8 addresses the limitations recited in claims 14 and 19. Therefore, same rejection above applies to claims 14 and 19.
As per Claim 10, Douros discloses a method for data quality validation, comprising:
receiving, by a data processing system, an incoming dataset from a data source (Douros: See Fig. 1, embodiment 110 where the data records are received from the data source.); obtaining, by the data processing system, a set of user-defined data quality rules for the incoming dataset (Douros: ¶0026: A checkpoint record includes rules for process values and information relevant to the current execution phase of the process.);
performing, by the data processing system, a data quality validation check for the incoming dataset based on a comparison of data quality metrics associated with the incoming dataset and the set of user-defined data quality rules for the incoming dataset (Douros: ¶0025-0026 and 0038-0039: Data processing systems uses a checkpointing technique for validation by using process values associated with the incoming data records being processed. The process values derived from the data records are compared to checkpoint rules to determine if the process values are logical points at which a checkpoint occurs. See Fig. 3-4 where the process performs multiple validation checks.); and
aborting, by the data processing system, a data processing job to process the incoming dataset based on the incoming dataset failing the data quality validation check (Douros: ¶0036 and 0044: The aborting command is triggered when the data processing fails a check point and it aborts current processing tasks.).
Douros discloses processing rules for data quality. However, Douros does not explicitly disclose; however, Sivaswamy discloses:
user-defined data quality rules (Sivaswamy: ¶0022: Predefined rules for data quality are obtained to implement transformations on extracted data for data processing. See Figure 1 where the multiple sets of data quality rules are applied to incoming and outgoing datasets.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention
to combine Douros with Sivaswamy’s data quality rules for data processing because the references are analogous/compatible, since each is directed toward features of checking datapoints for data processing, and because incorporating Sivaswamy’s data quality rules for data processing in Douros would have served Douros’ pursuit of implementing a checkpoint record that evaluates values and information of processed records (See Douros, ¶0026); and further obvious since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
As per Claim 11, Douros in view of Sivaswamy discloses the method of claim 10, further comprising: sending an alert to a client device to indicate that the data processing job was aborted due to the incoming dataset failing the data quality validation check (Douros: ¶0036: An abort message may send a notification regarding the failing at a checkpoint state and the abortion of current processing tasks.).
As per Claim 13, Douros in view of Sivaswamy discloses the method of claim 12, wherein performing the data quality validation check for the incoming dataset comprises: determining that the data quality metrics associated with the incoming dataset failed to satisfy one or more data quality rules among the set of …rules (Douros: ¶0025-0026 and 0038-0039: Data processing systems uses a checkpointing technique for validation by using process values associated with the incoming data records being processed. The process values derived from the data records are compared to checkpoint rules to determine if the process values are logical points at which a checkpoint occurs. See Fig. 3-4 where the process performs multiple validation checks with secondary requirements for incoming and outgoing data.); and determining that the incoming dataset failed the data quality validation check based on the one or more data quality rules that failed including at least one hard fail rule (Douros: See ¶0026-0027 where the checkpoint rules were based on checkpoint information such as process values the determines whether the data process fails.).
Douros discloses processing rules for data quality. However, Douros does not explicitly disclose; however, Sivaswamy discloses user-defined data quality rules (Sivaswamy: ¶0022: Predefined rules for data quality are obtained to implement transformations on extracted data for data processing. See Figure 1 where the multiple sets of data quality rules are applied to incoming and outgoing datasets.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention
to combine Douros with Sivaswamy’s data quality rules for data processing because the references are analogous/compatible, since each is directed toward features of checking datapoints for data processing, and because incorporating Sivaswamy’s data quality rules for data processing in Douros would have served Douros’ pursuit of implementing a checkpoint record that evaluates values and information of processed records (See Douros, ¶0026); and further obvious since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
As per Claim 16, Douros discloses a non-transitory computer-readable medium storing a set of instructions, the set of instructions comprising: one or more instructions that, when executed by one or more processors of a data processing system, cause the data processing system (Douros: ¶0050-0051) to:
receive an incoming dataset from a data source (Douros: See Fig. 1, embodiment 110 where the data records are received from the data source.);
execute a data processing job to process the incoming dataset, wherein the data processing job is executed to generate an outgoing dataset based on the incoming dataset (Douros: See ¶0030 and Fig. 3 where the data source process provides a multi-step process that has data incoming and outgoing from a checkpoint for processing.);
obtain a set of user-defined data quality rules for the outgoing dataset (Douros: ¶0026: A checkpoint record includes rules for process values and information relevant to the current execution phase of the process.);
perform a data quality validation check for the outgoing dataset based on a comparison of data quality metrics associated with the outgoing dataset and the set of… rules for the outgoing dataset (Douros: ¶0025-0026 and 0038-0039: Data processing systems uses a checkpointing technique for validation by using process values associated with the incoming data records being processed. The process values derived from the data records are compared to checkpoint rules to determine if the process values are logical points at which a checkpoint occurs. See Fig. 3-4 where the process performs multiple validation checks. Also, Fig. 3 demonstrates outgoing datasets through the multiple checkpoint process.); and
send an alert to a client device to indicate that the outgoing dataset will not be published to a downstream data sink due to the outgoing dataset failing the data quality validation check (Douros: See ¶0044 where messaging is processed to send an alert upon the process failing checkpoint states. All processes that do not complete checkpoint states will not process upstream to the data sink process.).
Douros discloses processing rules for data quality. However, Douros does not explicitly disclose; however, Sivaswamy discloses:
d) user-defined data quality rules (Sivaswamy: ¶0022: Predefined rules for data quality are obtained to implement transformations on extracted data for data processing. See Figure 1 where the multiple sets of data quality rules are applied to incoming and outgoing datasets.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention
to combine Douros with Sivaswamy’s data quality rules for data processing because the references are analogous/compatible, since each is directed toward features of checking datapoints for data processing, and because incorporating Sivaswamy’s data quality rules for data processing in Douros would have served Douros’ pursuit of implementing a checkpoint record that evaluates values and information of processed records (See Douros, ¶0026); and further obvious since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
As per Claim 18, Douros in view of Sivaswamy discloses the non-transitory computer-readable medium of claim 17, wherein the one or more instructions, that cause the data processing system to perform the data quality validation check for the outgoing dataset, cause the data processing system to: determine that the data quality metrics associated with the outgoing dataset failed one or more data quality rules among the set of user-defined data quality rules (Douros: ¶0025-0026 and 0038-0039: Data processing systems uses a checkpointing technique for validation by using process values associated with the incoming data records being processed. The process values derived from the data records are compared to checkpoint rules to determine if the process values are logical points at which a checkpoint occurs. See Fig. 3-4 where the process performs multiple validation checks with secondary requirements for incoming and outgoing data.); and determine that the outgoing dataset failed the data quality validation check based on the one or more data quality rules that failed including at least one hard fail rule (Douros: See ¶0026-0027 where the checkpoint rules were based on checkpoint information such as process values the determines whether the data process fails.).
Douros discloses processing rules for data quality. However, Douros does not explicitly disclose; however, Sivaswamy discloses user-defined data quality rules (Sivaswamy: ¶0022: Predefined rules for data quality are obtained to implement transformations on extracted data for data processing. See Figure 1 where the multiple sets of data quality rules are applied to incoming and outgoing datasets.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention
to combine Douros with Sivaswamy’s data quality rules for data processing because the references are analogous/compatible, since each is directed toward features of checking datapoints for data processing, and because incorporating Sivaswamy’s data quality rules for data processing in Douros would have served Douros’ pursuit of implementing a checkpoint record that evaluates values and information of processed records (See Douros, ¶0026); and further obvious since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
Claim(s) 9, 15 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Douros et al. (United States Patent Application Publication, 2012/0216202, hereinafter referred to as Douros) in view of Sivaswamy et all (United States Patent Application Publication, 2023/0086307, hereinafter referred to as Sivaswamy) in further view of Agarwal et al. (United States Patent, 11,347,622, hereinafter referred to as Agarwal).
As per Claim 9, Douros in view of Sivaswamy discloses the system of claim 1.
Douros does not explicitly disclose; however, Agarwal discloses wherein the one or more processors are further configured to: invoke a microservice to obtain the data quality metrics associated with the incoming dataset and the data quality metrics associated with the outgoing dataset (Agarwal: Col. 42, lines20-31: A microservice ingests information identifying metrics traced and traversed over the application. See Fig. 9 where the microservice obtain metrics for incoming and outgoing datasets.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention
to combine Douros with Agarwal’s microservice implemented to ingest value information because the references are analogous/compatible, since each is directed toward features of deriving values to process data through a service, and because incorporating Agarwal’s microservice implemented to ingest value information in Douros would have served Douros’ pursuit of deriving values from data records being processed (See Douros, ¶0039); and further obvious since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
Claim 15 and 20 depend on claims 10 and 16, respectively. While independent claims 10 and 16 vary from independent claim 1, the rejection of claim 9 addresses the limitations recited in claims 15 and 20. Therefore, same rejection above applies to claims 15 and 20.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Kaspa et al. (US 2022/0374442): In some implementations, a monitoring device may receive configuration information associated with an extract, transform, load (ETL) pipeline that includes one or more data sources and one or more data sinks. The monitoring device may generate, based on the configuration information, lineage data related to a data flow from the one or more data sources to the one or more data sinks in the ETL pipeline. The monitoring device may generate one or more predicted quality metrics associated with the ETL pipeline using a machine learning model. The monitoring device may generate a visualization in which multiple nodes are arranged to indicate the data flow from the one or more data sources to the one or more data sinks and further in which the one or more predicted quality metrics are encoded within the visualization.
Singh et al. (US 2019/0130004): The technology disclosed relates to a system that provides exactly-once processing of stream data. The system includes a queue manager which receives a stream of data. The system establishes aggregation intermediation checkpoints during processing of the received data. To do this, the system partitions delivery of the data stream at offsets, saves partition demarcation offsets at the end of processing windows, and saves intermediate aggregation results to a distributed file system with a window identifier (abbreviated ID) that correlates the offsets and the aggregation results. At each checkpoint, the intermediate aggregation results can be initially saved on at least one write-ahead log (abbreviated WAL) on the distributed file system and, post-saving, persisted to storage in accordance with a fault tolerance scheme.
Uhlig et al. (US 2012/0137164): A method of achieving fault tolerance in a distributed stream processing system organized as a directed acyclic graph includes the initial step of managing a stream process within the distributed stream processing system including one or more operators. The one or more operators of the stream process are communicatively associated with one or more downstream operators. The method includes the steps of maintaining one or more data copies of a processing state of the one or more operators until the one or more data copies can be safely discarded, notifying the one or more operators when it is safe to discard at least one of the at least one of the one or more data copies of the processing state; and using an identifier to denote the data copy of the processing state to be safely discarded.
Bond (US 2017/0039253): Systems and methods for providing full data provenance visualization for versioned datasets. A method includes receiving selection of a versioned dataset that is within a data pipeline system. The method also includes determining the full data provenance of the selected versioned dataset. The full data provenance may comprise a set of versioned datasets. The method further includes providing for display of a visualization of the full data provenance of the selected versioned dataset. The visualization comprises a graph. The graph comprises a compound node for the selected versioned dataset and for each versioned dataset in the set of versioned datasets. The graph further comprises edges connecting the compounds nodes. Each edge represents a derivation dependency between versions of the versioned datasets represented by the compound nodes connected by the edge.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ALLISON MICHELLE NEAL whose telephone number is (571)272-9334. The examiner can normally be reached 9-2pm ET, M-F.
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, Brian Epstein can be reached at 5712705389. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/ALLISON M NEAL/Primary Examiner, Art Unit 3625
Prosecution Insights