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 .
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.
Claims 1, 6-9, 14-17, 20, and 22 are rejected under 35 U.S.C. 103 as being unpatentable over Kodavati et al. (US Pre-Grant Publication 2023/0144349) in view of Balta et al. (US Pre-Grant Publication 2021/0383006), in view of Best et al. (US Patent 7,865,461), and further in view of Katz et al. (US Pre-Grant Publication 2002/0178077).
As to claim 1, Kodavati teaches a method of importing data to a database that is implemented by an electronic device, the method comprising:
acquiring incoming data from a data source according to a database config file (see Kodavati paragraphs [0019], [0022], and [0031]. Kodavati describes a system that uses “transformation configuration parameters” to identify and extract data from a source (see paragraph [0022]). It is noted that Kodavati indicates that the “transformation configuration parameters” may be stored in a file (see paragraphs [0019] and [0031]);
wherein the incoming data is original data directly acquired from the data source (see Kodavati paragraph [0032]. The data is directly acquired from the source data tables);
calculating and processing the incoming data according to the database config file to obtain computational data (see Kodavati paragraph [0033]-[0034]. The incoming data undergoes various data analyses, aggregation, and summarizations);
wherein the computational data is obtained by integrating and calculating the incoming data (see Kodavati paragraph [0033]-[0034]. The various data analyses, aggregation, and summarizations are “data integrations” and “calculations” to incoming data that result in computed data stored in an intermediate staging area); and
writing the incoming data and the computational data into the database (see Kodavati paragraph [0035]. The data stored in the intermediate staging area may be transformed into a format associated with a target computing system),
wherein the writing the incoming data and the computational data into the database comprises:
writing the incoming data and the computational data into a staging file (see Kodavati paragraph [0033]-[0034]);
…
modifying … the data format of the incoming data and the data format of the computational data to be consistent with the preset data format (see Kodavati paragraphs [0034]-[0035])
…
so that data formats of all data in the staging file meets a requirement of the database config file (see Kodavati paragraphs [0034]-[0035]), and
collectively writing all the data in the staging file into the database after the modifying (see Kodavati paragraphs [0034]-[0035]),
wherein writing the incoming data and the computational data into the database comprises … [transferring] data from the staging area to the database (see Kodavati paragraph [0035],
wherein the [transfer] is performed only after … any modifying operations have been completed for all data in the staging file, such that all data in the staging file satisfy the requirement of the database config file prior to transfer to the database (see Kodavati paragraphs [0034]-[0035]. The data is transferred to the target after all transformation and other analysis operations have been completed in the staging area. Also see Figures 2 and 3, in which the data being sent to the “target data tables” exist at the end of each workflow).
Kodavati does not teach:
checking whether a data format of the incoming data and a data format of the computational data in the staging file is consistent with a preset data format in the database config file, wherein the checking comprises:
checking whether a data structure of the incoming data and a data structure of the computational data in the staging file is consistent with a preset data structure in the database config file, and
checking a data integrity of the incoming data and a data integrity of the computational data;
writing, in response to the data format of the incoming data and the data format of the computational data being consistent with the preset data format, the incoming data and the computational data from the staging file into the database; and
modifying, in response to the data format of the incoming data and the data format of the computational data being inconsistent with the preset data format, the data format of the incoming data and the data format of the computational data to be consistent with the preset data format,
wherein writing the incoming data and the computational data into the database comprises performing a single batched commit operation that transfers data from the staging area to the database, thereby replacing multiple direct write operations with a single batched commit operation,
wherein the single batched commit operation is performed only after the checking and any modifying operations have been completed for all data in the staging file, such that all data in the staging file satisfy the requirement of the database config file prior to transfer to the database.
Balta teaches:
checking whether a data format of the incoming data and a data format of the computational data in the staging file is consistent with a preset data format in the database config file (see Balta paragraphs [0056]-[0058] for checking whether incoming data and computed data is consistent with a preset data format at a destination. It is noted that Kodavati paragraphs [0034]-[0035] teach the use of a staging area and a database config file), wherein the checking comprises:
checking whether a data structure of the incoming data and a data structure of the computational data in the staging file is consistent with a preset data structure in the database config file (see Balta paragraphs [0056]-[0058]), and
…
writing, in response to the data format of the incoming data and the data format of the computational data being consistent with the preset data format, the incoming data and the computational data from the staging file into the database (see Balta paragraphs [0056]-[0058]); and
modifying, in response to the data format of the incoming data and the data format of the computational data being inconsistent with the preset data format, the data format of the incoming data and the data format of the computational data to be consistent with the preset data format (see Balta paragraphs [0056]-[0058]. Balta teaches to identify a required format of the data. If the required format of the data is the same as the source and current format of the data, the data is not modified. If the required format and the present format are not the same, the data is modified),
so that data formats of all data in the staging file meets a requirement of the database config file (see Balta paragraphs [0056]-[0058]. Data is modified before being stored in the target database), and
collectively writing all the data in the staging file into the database after the modifying (see Balta paragraphs [0056]-[0058]. The data is stored in the target database after being modified, if modification was needed).
wherein the … commit operation is performed only after the checking and any modifying operations have been completed for all data in the staging file, such that all data in the staging file satisfy the requirement of the database config file prior to transfer to the database (see Balta Figure 6 and paragraph [0058]. Balta explicitly shows that writing data to the target is performed only after any checking and modifying operations have been completed. As noted above, Kodavati paragraphs [0034]-[0035] teaches the use of a staging area).
It would have been obvious to one of ordinary skill in the art before the earliest filing date of the invention to have modified Kodavati by the teachings of Balta because Balta provides Kodavati a benefit of determining whether reformatting is necessary or not with a check of each of multiple targets, which will improve efficiency.
Best teaches:
checking a data integrity of the incoming data and a data integrity of the computational data (see Best 5:62-6:6. Data located in a staging area may undergo an integrity check process that checks for data formatting and proper standards according to a reference database);
It would have been obvious to one of ordinary skill in the art before the earliest filing date of the invention to have modified Kodavati by the teachings of Best because Best provides Kodavati a benefit of validating incoming data in an ETL system that will ensure data is formatted correctly for a destination according to selected reference standards.
Katz teaches wherein writing the incoming data and the computational data into the database comprises performing a single batched commit operation that transfers data from the staging area to the database, thereby replacing multiple direct write operations with a single batched commit operation (see paragraph [0224]. In Katz, loading can be done using a single sequence).
It would have been obvious to one of ordinary skill in the art before the earliest filing date of the invention to have modified Kodavati by the teachings of Katz because Katz provides Kodavati the ability to incorporate data from many heterogeneous sources to load into a database and giving a user additional options when choosing how to load that data.
As to claim 6, Kodavati as modified teaches the method according to claim 1, wherein writing the incoming data and the computational data from the staging file into the database comprises:
processing the incoming data and the computational data into a plurality of data slices (see Kodavati paragraph [0035]. Data is processed in subsets); and
writing the plurality of data slices in batches from the staging file into the database (see Kodavati paragraph [0035]. Subsets of data are written to the database after processing).
As to claim 7, Kodavati as modified teaches the method according to claim 1, further comprising:
reading product side data regularly (see Kodavati paragraph [0037]);
determining whether a difference exists between the product side data and the database config file (see Kodavati paragraph [0037]. The system of Kodavati checks for new or updated data in view of the configuration file. This is determining whether a difference exists by determining values updated after a preset time);
writing, in response to the difference existing between the product side data and the database config file, difference data into the staging file (see Kodavati paragraph [0037]);
returning, in response to the difference not existing between the product side data and the database config file, to read the product side data regularly (see Kodavati paragraph [0037]);
checking, after writing the difference data into the staging file, whether a data format of the difference data is consistent with the preset data format (see Balta paragraphs [0056]-[0058]);
writing, in response to the data format of the difference data being consistent with the preset data format, the difference data from the staging file into the database (see Balta paragraphs [0056]-[0058]); and
modifying, in response to the data format of the difference data being inconsistent with the preset data format, the data format of the difference data to be consistent with the preset data format, and writing the modified difference data from the staging file into the database (see Kodavati paragraphs [0034]-[0035]. Also see Balta paragraphs [0056]-[0058])).
As to claim 8, Kodavati teaches the method according to claim 1, wherein the database config file comprises at least one of:
a road type;
an indicator name;
a data type (see Kodavati paragraphs [0033] and [0024]);
an indicator acquisition granularity;
a data request scope (see Kodavati paragraphs [0033] and [0024]);
an aggregation request parameter;
a data format (see Kodavati paragraphs [0033] and [0024]);
a scope request address;
an aggregation request address;
a time granularity;
a selected index (see Kodavati paragraphs [0033] and [0024]); or
a selected time period (see Kodavati paragraph [0037]).
As to claims 9, 17, and 20 see the rejection of claim 1.
As to claim 14, see the rejection of claim 6.
As to claim 15, see the rejection of claim 7.
As to claim 16, see the rejection of claim 8.
As to claim 22, Kodavati as modified by Best teaches method of claim 1, wherein checking the data format further comprises executing an automated integrity-validation engine that detects missing fields, inconsistent schemas, or null-value violations prior to committing data to the database (see Best 5:62-6:6. Inconsistent data standards, or schemas, are checked for during the integrity checking process).
Claims 3, 11, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Kodavati et al. (US Pre-Grant Publication 2023/0144349) in view of Balta et al. (US Pre-Grant Publication 2021/0383006), and further in view of in view of Best et al. (US Patent 7,865,461), in view of Katz et al. (US Pre-Grant Publication 2002/0178077), and further in view of Dill et al. (US Pre-Grant Publication 2004/0215656).
As to claim 3, Kodavati teaches the method according to claim 1, wherein the acquiring incoming data from a data source according to a database config file comprises:
acquiring a data runtime period, wherein the data runtime period comprises a user input [time] or a preset [time] (see Kodavati paragraph [0037] for a scheduling parameter); and
acquiring, according to the database config file, the original data corresponding to the data runtime period from the data source as the incoming data (see Kodavati paragraph [0037] for a scheduling parameter).
Kodavati does not explicitly teach a user input date or a preset date.
Dill teaches acquiring a data runtime period, wherein the data runtime period comprises a user input date or a preset date (see Dill paragraphs [0062]-[0063]); and
acquiring, according to the database config file, the original data corresponding to the data runtime period from the data source as the incoming data (see Dill paragraphs [0062]-[0063]).
It would have been obvious to one of ordinary skill in the art before the earliest filing date of the invention to have modified Kodavati by the teachings of Dill because Dill provides Kodavati additional parameters to consider when extracting data, which will improve the ability of a user to customize an ETL process with Kodavati.
As to claims 11 and 19, see the rejection of claim 3.
Claims 4-5 and 12-13 are rejected under 35 U.S.C. 103 as being unpatentable over Kodavati et al. (US Pre-Grant Publication 2023/0144349) in view of Balta et al. (US Pre-Grant Publication 2021/0383006), in view of Best et al. (US Patent 7,865,461), in view of Katz et al. (US Pre-Grant Publication 2002/0178077), and further in view of Beesley et al. (US Patent 6,704,645).
As to claim 4, Kodavati teaches the method according to claim 1, wherein the acquiring incoming data from a data source according to a database config file further comprises:
acquiring a first target parameter corresponding to the incoming data from the database config file (see Kodavati paragraphs [0033]-[0035]);
…
acquiring, according to the identity document and the first target parameter, corresponding original data from the data source as the incoming data (see Kodavati paragraphs [0033]-[0035]).
Kodavati does not teach:
acquiring an identity document corresponding to each road in the incoming data from a road network file;
wherein the incoming data is traffic data, and
the road network file comprises the identity document corresponding to each road in the traffic data and a hierarchical relationship between roads; and
Beesley teaches:
acquiring an identity document corresponding to each road in the incoming data from a road network file (see Beesley 4:51-5:5. Beesley shows a data structure that may store road network data);
wherein the incoming data is traffic data (see Beesley 7:45-8:7. Traffic data is considered along with road data), and
the road network file comprises the identity document corresponding to each road in the traffic data and a hierarchical relationship between roads (see Beesley 4:51-5:5. Beesley shows that the data structure may maintain a hierarchy of roads);
It would have been obvious to one of ordinary skill in the art before the earliest filing date of the invention to have modified Kodavati by the teachings of Beesley because Beesley provides Kodavati additional data to consider and parse that will improve efficiency analysis for certain uses, particularly traffic uses, on a target system of Kodavati.
As to claim 5, Kodavati teaches the method according to claim 4, wherein the calculating and processing the incoming data according to the database config file to obtain computational data comprises:
acquiring a second target parameter corresponding to the computational data from the database config file (see Beesley 7:45-8:7. A user may provide input for processing data. It is noted that Kodavati teaches wherein such processing instructions are in a database config file, paragraphs [0019] and [0031]). ;
acquiring an identity document and a hierarchical relationship corresponding to each road in the computational data from the road network file (see Beesley 4:51-5:5); and
calculating and processing the incoming data according to the identity document, the hierarchical relationship, and the second target parameter, so as to obtain corresponding second indicator data as the computational data (see Beesley 7:45-8:7);
wherein the calculating and processing comprises at least one of:
extracting the incoming data;
integrating the incoming data (see Beesley 7:45-8:7); or
ranking the incoming data.
As to claims 12 and 13, see the rejections of claim 4 and 5.
Claim 23 is rejected under 35 U.S.C. 103 as being unpatentable over Kodavati et al. (US Pre-Grant Publication 2023/0144349) in view of Balta et al. (US Pre-Grant Publication 2021/0383006), in view of Best et al. (US Patent 7,865,461), in view of Katz et al. (US Pre-Grant Publication 2002/0178077), and further in view of Scott et al. (US Pre-Grant Publication 2020/0125566).
As to claim 23, Kodavati as modified teaches method of claim 1.
Kodavati does not clearly teach wherein the staging file is stored in a predefined structured format supported by the staging area, wherein the predefined structure format is a CSV format.
Scott wherein the staging file is stored in a predefined structured format supported by the staging area, wherein the predefined structure format is a CSV format (see paragraphs [0038]-[0039]. Scott shows storing data pulled from a source into a CSV format).
It would have been obvious to one of ordinary skill in the art before the earliest filing date of the invention to have modified Kodavati by the teachings of Scott because Scott provides Kodavati the ability to incorporate data from many heterogeneous sources such that they can be presented in a unified view to a user, which will improve a user’s ability to understand the data inputs and outputs (see Scott paragraph [0022]).
Response to Arguments
Applicant's arguments filed 6 June 2026 have been fully considered but they are not persuasive.
Applicant asserts that “The claims now expressly recite that the single batched commit operation is conditionally executed only after completion of the checking and any modifying operations for all data in the staging file, such that all data satisfy the requirements of the database configuration file before any transfer to the database occurs. The cited references do not teach or suggest this limitation.”
In response to this argument, it is noted that the cited references do teach this limitation for the reasons provided above. Notably, both Kodavati and Balta show that writing to a destination may only occur after any transformations have occurred (see Kodavati paragraphs [0034]-[0035] for writing to a target only after transformations occur and Balta paragraph [0058] for also confirming format before writing to a target).
Applicant continues, arguing that “As amended, the claims do not merely recite performance of a batched operation. Rather, the claims require that the single batched commit operation be performed only after completion of the checking and any modifying operations for all data in the staging file, such that all data satisfy the requirements of the database configuration file prior to transfer to the database. Nothing in paragraph [0224] of Katz teaches or suggests:
- completion of validation operations for all staged data before a commit operation is performed;
- completion of modification operations for all staged data before a commit operation is performed;
- conditioning execution of a batched commit operation on successful completion of validation for an entire staged dataset; or
- ensuring that all data satisfy database configuration requirements prior to transfer to the database.
Rather, Katz discusses alternative execution modes for ETL loading operations, including batch, serial, parallel, and single-sequence execution. The cited disclosure concerns the scheduling and execution of loading tasks and does not disclose the claimed requirement that a single batched commit operation be deferred until all checking and any modifying operations have been completed for all data in the staging file. Accordingly, Katz does not teach the newly added limitation.”
In response to this argument, it is noted that Katz does not, and is not relied upon to teach the validation or modification operations. Kodavati and Balta teach these limitations.
In response to applicant's arguments against the references individually, one cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986).
The combination of references teaches every claim limitation as described in the rejection above.
Applicant argues that “In particular, Kodavati does not teach that a database write operation is deferred until checking and any modifying operations have been completed for all data in the staging file. While Kodavati may discuss transformation and loading operations in an ETL environment, it does not require completion of validation activities across an entire staged dataset before database writing occurs. Likewise, Balta does not teach that all validation and modification operations must be completed for all data before a database commit operation is executed.”
In response to this argument, Kodavati is not relied upon to teach the completion of validation activities before database writing occurs. Balta is relied upon for this feature (see Balta paragraphs [0056]-[0058] and the reasoning provided in the rejection above).
It is additionally noted that the claims do not require “deferring” a transfer operation, but rather only that the write operation occur only after the checking and modifying operations have completed. The claims only require a sequence of operations. In the current claims, transfer operations of the relevant data simply do not take place until after the checking and modifying operations have been completed.
Applicant is reminded that unclaimed features from the specification, such as “deferring” an operation while confirming that checking and modifying operations have completed, receive no patentable weight until claimed.
Applicant continues, arguing that “Balta may describe applying policies and transformations to data during processing, but does not disclose the claimed requirement that a single batched commit operation be performed only after completion of checking and modifying operations for all data in a staging file.”
Applicant continues, arguing that “Best similarly fails to disclose the claimed sequential relationship. Although Best may perform validation or correction operations, Best does not teach withholding a batched database commit until checking and any modifying operations have been completed for all staged data.”
In response to this argument, neither Balta nor Best is relied upon to teach a single batched commit operation. Katz is relied upon to teach a single batched commit operation (see paragraph [0224]. In Katz, loading can be done using a single sequence). The rejection is based upon a combination of references.
In response to applicant's arguments against the references individually, one cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986).
Applicant concludes, “Accordingly, the cited references may individually disclose various aspects of ETL processing, staging, transformation, validation, or loading, but they do not disclose or suggest the specific conditional relationship now recited in the claims.”
As noted in the rejection above, the references combined teach the claimed subject matter. Kodavati and Balta both teach a series of checks and transformations of incoming data. Best similarly teaches checking an integrity of data. In each references, after these checks and transformations are completed, a write operation occurs wherein data is written to a target location (see Kodavati paragraph [0035], Balta paragraph [0058] and Figure 6, and Best 6:30-39. As noted above, the claims only require a sequence of operations, wherein modifying and checking operations are performed before a transfer operation to a target database. This is shown in each of the cited references). Katz teaches wherein that write operation may be a single batched commit operation. Combined, the references teach the claimed subject matter.
Applicant is reminded that unclaimed features from the specification, such as any alleged step of deferring transfer until confirming that checking and modification have occurred, receive no patentable weight until claimed.
In response to applicant's arguments against the references individually, one cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986).
Applicant argues that “The rejection relies upon combining disparate teachings from Kodavati, Balta, Best, and Katz. However, even if these references were combined, the resulting system would still not teach or suggest the claimed architecture in which:
- data are stored in a staging file;
- checking operations are completed for all data in the staging file;
- any modifying operations are completed for all data in the staging file;
- all data in the staging file satisfy the requirements of the database configuration file; and only then
- a single batched commit operation is performed to transfer the data to the database.”
In response to this argument, Kodavati explicitly teaches storing data in a staging file (see Kodavati paragraphs [0033]-[0034], which explicitly discusses the use of a data structures in a staging area to store inputted data before sending the data to a target destination).
Balta teaches wherein checking operations are completed before data is sent to a target destination (see paragraph [0058]).
Kodavati and Balta both teach wherein modifying operations are completed for data before sending to a target (see Kodavati paragraphs [0033]-[0035] and Balta paragraph [0058]). This writing step only occurs after the data in the staging area satisfies the conditions for writing the data to the target database.
Katz teaches a single batched commit operation (see paragraph [0224]. In Katz, loading can be done using a single sequence).
Combined, the references render the claimed subject matter obvious.
Applicant argues that “The amended claims require a specific ordered relationship between validation and database writing. The claims recite that the single batched commit operation be contingent upon completion of the checking and any modifying operations for all staged data. The cited references do not teach or suggest this requirement, nor do they suggest delaying a database commit until the entire staged dataset has been validated and brought into compliance with database configuration requirements.”
As noted above, the cited references teach the limitations to the extent claimed.
It is noted that nothing in the claims requires “delaying a database commit until the entire staged dataset has been validated and brought into compliance with database configuration requirements.” There is no claimed step for “delaying” a commit until after a confirmation step has occurred to verify that all previous checks and transformations have been completed. Rather, the claims only require that the database commit happen after all the checking and modifying operations have been completed. This is obvious in view of the cited references for the reasons cited above.
Applicant is reminded unclaimed features from the specification – such as an active delaying step – do not receive patentable weight until claimed.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CHARLES D ADAMS whose telephone number is (571)272-3938. The examiner can normally be reached M-F, 9-5:30 EST.
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, Aleksandr Kerzhner can be reached at 5712701760. 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.
/CHARLES D ADAMS/ Primary Examiner, Art Unit 2165
Prosecution Insights