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
The following is a Final Office action. In response to communications received 5/7/2026, Applicant, on 7/22/2026, amended claims 1, 10 and 16. Claims 8-9, 14-15 and 19-20 are canceled. Claims 21-26 are new. Claims 1-7, 10-13, 16-18 and 21-26 remain pending in this application and have been rejected below.
Response to Amendment
Applicant’s amendments and arguments have been considered. However, the 101 rejection remains and is updated below.
Applicant’s amendments and arguments have been considered. However, the 103 rejection remains and is updated below.
Response to Argument
With respect to the 101 arguments, Applicant argues that the amended independent claim 1 is not directed to an abstract idea (See Remarks at pgs. 10-12). However, Examiner respectfully disagrees. Examiner notes that 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. The amended limitation, “invoke a microservice to obtain a current version of a first set of user-defined data quality rules, of user-defined data quality rule sets, for an incoming dataset and a second set of user-defined data quality rules, of the user-defined data quality rule sets, for an outgoing dataset, wherein the microservice is configured to store current versions of the user-defined data quality rule sets and generate data quality metrics associated with the incoming dataset based on the user-defined data quality rule sets;” describes the implementation of a microservice (i.e. software) where data quality rule sets and their associated quality metrics are user-defined, versioned and stored. These data quality rule sets are evaluative metrics used to process data and check for quality, which is a mental process. Also, the amended claim limitation, “provide, via a user interface or application programming interface, a capability to modify the first set of user-defined data quality rules for the incoming dataset or the second set of user-defined data quality rules for the outgoing dataset without requiring a change to code of the system” describes a user’s capability of modifying the user-defined data quality rules. Applicant’s Specification, ¶0025, identifies that that users are allowed to “self-service the user-defined data quality rules (e.g., delete old data quality rules, define new data quality rules, or modify existing data quality rules).” This user enablement of modifying user-defined rules further narrows the judicial exception through modification of the evaluative process. Accordingly, the claimed invention recites an abstract idea. See the updated rejection below.
Also, with respect to the 101 rejection, Applicant argues that the claims integrate any alleged abstract idea into a practical application (See Remarks at pgs. 12-14). Specifically, Applicant points to portions of Applicant’s Specification to suggest that “claim 1 reflects the Specification’s disclosed improvement in technology,” as it recites “provide, via a user interface or application programming interface, a capability to modify the first set of user-defined data quality rules for the incoming dataset or the second set of user-defined data quality rules for the outgoing dataset without requiring a change to code of the system," and "publish the outgoing dataset to a downstream data sink based on the outgoing dataset passing the second data quality validation check” (See Remarks at pg. 14). However, Examiner respectfully disagrees. As explained in the argument above, providing to a user interface the ability to modify data quality rules further narrows the judicial exception through modification of the evaluative process and therefore, is not viewed as an additional element. The limitation reciting "publish the outgoing dataset to a downstream data sink based on the outgoing dataset passing the second data quality validation check” is the mere transmission of data in response to the evaluative process including data quality validation check. While this limitation is viewed as an additional element, the mere transmission of data utilizes a computer to implement an idea in the manner of “apply it”. Therefore, the claims fail to practically apply the judicial exception. See the updated 101 rejection below.
With respect to the 103 rejection, Applicant argues that 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) fail to disclose the amended claim limitations (See Remarks at pg. 15). However, Examiner notes that this argument is now moot as the amended claims are now rejected by Douros et al. (United States Patent Application Publication, 2012/0216202, hereinafter referred to as Douros) in view of Shrivastava et al. (United States Patent Application Publication, ,hereinafter referred to as Shrivastava) in further view of Sivaswamy et al. (United States Patent Application Publication, 2023/0086307, hereinafter referred to as Sivaswamy).
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-7, 10-13, 16-18 and 21-26 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 system in claims 1-7 and 21-22; method in claims 10-13 and 23-24; and non-transitory computer-readable medium in claims 16-18 and 25-26is directed to a potentially eligible category of subject matter (i.e., processes, machine etc.). Thus, Step 1 is satisfied with respect to claims 1-7, 10-13, 16-18 and 21-26.
In accordance with Step 2A, Prong One, claims 1-7, 10-13, 16-18 and 21-26, 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: invoke a microservice to obtain a current version of a first set of user-defined data quality rules, of user-defined data quality rule sets, for an incoming dataset and a second set of user-defined data quality rules, of the user-defined data quality rule sets, for an outgoing dataset, wherein the microservice is configured to store current versions of the user-defined data quality rule sets and generate data quality metrics associated with the incoming dataset based on the user-defined data quality rule sets; perform a first data quality validation check for the incoming dataset based on a comparison of the 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; provide, via a user interface or application programming interface, a capability to modify the first set of user-defined data quality rules for the incoming dataset or the second set of user-defined data quality rules for the outgoing dataset without requiring a change to code of the system; 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; invoking, by the data processing system, a microservice to obtain a current version of a set of user-defined data quality rules, of user-defined data quality rule sets, for the incoming dataset, wherein the microservice is configured to store current versions of the user-defined data quality rule sets and generate data quality metrics associated with the incoming dataset; performing, by the data processing system, a data quality validation check for the incoming dataset based on a comparison of the data quality metrics 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; and providing, by the data processing system and via a user interface or application programming interface, a capability to modify the set of user-defined data quality rules without requiring a change to code of the data processing system.
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; invoke a microservice to obtain a current version of a set of user-defined data quality rules, of user-defined data quality rule sets, for the outgoing dataset, wherein the microservice is configured to store current versions of the user-defined data quality rule sets and generate data quality metrics associated with the outgoing dataset based on the user-defined data quality rule sets; 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; provide, via a user interface or application programming interface, a capability to modify the set of user-defined data quality rules without requiring a change to the one or more instructions of the data processing system; 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, such as a data processing system invoking a microservice for receiving/transmitting data (e.g., receive an incoming dataset from a data source;invoke a microservice to obtain a current version of a set of user-defined data quality rules, of user-defined data quality rule sets, for the outgoing dataset…; publish the outgoing dataset to a downstream data sink based on the outgoing dataset passing the second data quality validation check; provide, via a user interface or application programming interface, a capability to modify the set of user-defined data quality rules without requiring a change to the one or more instructions of the data processing system; 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 (e.g. , wherein the microservice is configured to store current versions of the user-defined data quality rule sets and generate data quality metrics associated with the outgoing dataset based on the user-defined data quality rule sets; etc.); 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 data processing system invoking a microservice 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-7, 12-13, 17-18, 21-22 and 24 further narrow the abstract idea of a mental process of performing evaluative steps by further defining and implementing hard fail rules, data quality rules/metrics and validation checks 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 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.’
Dependent claim 23 further describes the generic computing function of storing claimed datasets by detailing where the datasets are stored. This claim is descriptive of the computer technology where the judicial exception is applied. Therefore, this claim fails to practically apply the judicial exception or amount to significantly more.
Dependent claims 25 and 26 describe data processing through extraction, transformation and loading pipelines. The courts have recognized that the use of a computer to extract data is a well-understood, routine, conventional activity (See Content Extraction and Transmission, LLC v. Wells Fargo Bank, 776 F.3d 1343, 1348, 113 USPQ2d 1354, 1358 (Fed. Cir. 2014)). These dependent claims merely implement extraction to retrieve tasks from incoming datasets, which use a computer as a tool to perform an existing process. Therefore, these claims fail to practically apply the judicial exception or amount to significantly 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-7, 10-13, 16-18 and 21-26 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 Shrivastava et al. (United States Patent Application Publication, 2021/0326334, hereinafter referred to as Shrivastava) in further view of Sivaswamy et al. (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 the 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 the data quality metrics 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 does not explicitly disclose; however, Shrivastava discloses:
invoke a microservice to obtain a current version of a set of user-defined data quality rules, of user-defined data quality rule sets, for the outgoing dataset, wherein the microservice is configured to store current versions of the user-defined data quality rule sets and generate data quality metrics associated with the outgoing dataset based on the user-defined data quality rule sets (Shrivastava: ¶0051-0055: Data quality checks including rules for a condition found in data are used to validate the first versioned data set. The validator may transform and resolve a dataset into a new and current version of the data stored with its associated data quality metrics and data checks. See ¶0073-0084 for the microservices invoked to implement the invention.).
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 Shrivastava’s microservice invoked to perform data quality checks because the references are analogous/compatible, since each is directed toward features of data quality checks and validation, and because incorporating Shrivastava’s microservice invoked to perform data quality checks in Douros would have served Douros’ pursuit of implementing checkpointing techniques for validation (See Douros, ¶0025); 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.
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.).
provide, via a user interface or application programming interface, a capability to modify the first set of user-defined data quality rules for the incoming dataset or the second set of user-defined data quality rules for the outgoing dataset without requiring a change to code of the system ( Sivaswamy: ¶0018-0019: Predefined rules are kept separate from the code base to avoid changes to the code. See ¶0021 where updates to the predefined rules are integrated into the pipeline to be applied to source data. 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 Shrivastava in further 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 Shrivastava in further 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 Shrivastava in further 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 Shrivastava in further 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 Shrivastava in further 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 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 the data quality metrics 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.);
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 checkpoint and it aborts current processing tasks.); and
Douros does not explicitly disclose; however, Shrivastava discloses:
invoking, by a data processing system, a microservice to obtain a current version of a set of user-defined data quality rules, of user-defined data quality rule sets, for the incoming dataset, wherein the microservice is configured to store current versions of the user-defined data quality rule sets and generate data quality metrics associated with the incoming dataset based on the user-defined data quality rule sets (Shrivastava: ¶0051-0055: Data quality checks including rules for a condition found in data are used to validate the first versioned data set. The validator may transform and resolve a dataset into a new and current version of the data stored with its associated data quality metrics and data checks. See ¶0073-0084 for the microservices invoked to implement the invention.).
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 Shrivastava’s microservice invoked to perform data quality checks because the references are analogous/compatible, since each is directed toward features of data quality checks and validation, and because incorporating Shrivastava’s microservice invoked to perform data quality checks in Douros would have served Douros’ pursuit of implementing checkpointing techniques for validation (See Douros, ¶0025); 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.
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.).
providing, by the data processing system and via a user interface or application programming interface, a capability to modify the first set of user-defined data quality rules without requiring a change to code of the data processing system (Sivaswamy: ¶0018-0019: Predefined rules are kept separate from the code base to avoid changes to the code. See ¶0021 where updates to the predefined rules are integrated into the pipeline to be applied to source data. 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 Shrivastava in further 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 Shrivastava in further 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 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 does not explicitly disclose; however, Shrivastava discloses:
invoke a microservice to obtain a current version of a set of user-defined data quality rules, of user-defined data quality rule sets, for the outgoing dataset, wherein the microservice is configured to store current versions of the user-defined data quality rule sets and generate data quality metrics associated with the outgoing dataset based on the user-defined data quality rule sets (Shrivastava: ¶0051-0055: Data quality checks including rules for a condition found in data are used to validate the first versioned data set. The validator may transform and resolve a dataset into a new and current version of the data stored with its associated data quality metrics and data checks. See ¶0073-0084 for the microservices invoked to implement the invention.).
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 Shrivastava’s microservice invoked to perform data quality checks because the references are analogous/compatible, since each is directed toward features of data quality checks and validation, and because incorporating Shrivastava’s microservice invoked to perform data quality checks in Douros would have served Douros’ pursuit of implementing checkpointing techniques for validation (See Douros, ¶0025); 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.
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.);
provide, via a user interface or application programming interface, a capability to modify the first set of user-defined data quality rules without requiring a change to code of the data processing system (Sivaswamy: ¶0018-0019: Predefined rules are kept separate from the code base to avoid changes to the code. See ¶0021 where updates to the predefined rules are integrated into the pipeline to be applied to source data. 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 Shrivastava in further 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.
As per Claim 21, Douros in view of Shrivastava in further view of Sivaswamy discloses the system of claim 1.
Duoros does not explicitly disclose; however, Sivaswamy discloses wherein the first set of user-defined data quality rules are configured for validating the incoming dataset prior to executing the data processing job and the second set of user-defined data quality rules are configured for validating the outgoing dataset after generation of the 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. See DQ rules 1 used on the first incoming set, DQ rules 2 are used on the outgoing set and so on.).
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 22, Douros in view of Shrivastava in further view of Sivaswamy discloses the system of claim 1, wherein the one or more processors are configured to: determine, for each data quality validation check, whether any violated data quality rule is classified as a hard fail rule or a fault-tolerant rule, and automatically abort the data processing job or discard the outgoing dataset if a hard fail rule is violated, or proceed if only fault-tolerant rules are violated (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 ¶0035-0036 for an example where the fault tolerance manager determines at a checkpoint state whether the system should be aborted if at the checkpoint the activity is at fault.).
As per Claim 23, Douros in view of Shrivastava in further view of Sivaswamy discloses the method of claim 10, wherein the incoming dataset is from structured and/or unstructured data stored in one or more data repositories, cloud environments, on-premises environments, application-specific data repositories, mobile devices, or customer relationship management systems (Douros: ¶0019-0020: A data processing system receives data from application specific data sources. See also ¶0021 where data is received from an on-premise environment, such as a database associated with an ATM.).
As per Claim 24, Douros in view of Shrivastava in further view of Sivaswamy discloses the method of claim 10, further comprising: performing one or more transformation tasks to apply rules to the incoming dataset to prepare the outgoing dataset to be loaded into the downstream data sink (Douros: ¶0019: An initial dataset is processed (e.g. uses rules to transform, filter, confirm) to provide processed data to a downstream data queue. See example process in ¶0044.).
As per Claim 25, Douros in view of Shrivastava in further view of Sivaswamy discloses the non-transitory computer-readable medium of claim 16, wherein the data processing job includes one or more tasks that relate to extracting incoming datasets that include data records from source tables stored in one or more upstream data sources (Douros: ¶0041 and 0044: Data records from sources in one or more upstream processes are extracted to pass through checkpoints to downstream processes.).
As per Claim 26, Douros in view of Shrivastava in further view of Sivaswamy discloses a non-transitory computer-readable medium of claim 16, wherein the one or more instructions that cause the data processing system to execute a data processing job to process the incoming dataset, cause the data processing system to: execute one or more extract, transform, and load (ETL) pipelines (Douros: ¶0019: An initial dataset is processed (e.g. uses rules to transform, filter, confirm) to provide processed data to a downstream data queue. See example process in ¶0044.).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Evers et al. (US 2024/0078216): Various methods, apparatuses/systems, and media for data migration readiness of a target data source are disclosed. A processor receives a request having configurable filters and parameters from a consumer service to obtain data; invokes, in response to receiving the request, a service application programming interface (API) for the data; fetches requested data from a legacy data source in response to calling the service API; fetches data corresponding to the same request having the same configurable filters and parameters from a target data source; compare the fetched data from the legacy data source to the fetched data from the target data source; generates, in response to comparing, a data quality validation score; and when it is determined that the data quality validation score is equal to or more that predetermined threshold value, validates the target data source for migration readiness and terminating the legacy data source.
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to 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
