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 .
The Amendment filed on 01/23/26 has been received and entered. Application No. 18/763,320 of which claims 27-29 are added. Claims 1-29 are pending in the application, all of which are ready for examination by the examiner.
Continued Examination under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 01/23/2026 has been entered.
Response to Amendment
Applicant’s amendment necessitated new grounds of rejection.
Applicant’s response, filed on 01/23/26, with respect to double patenting rejections of claims 1-26 have been fully considered but are not persuasive. The rejections are maintained.
Applicant’s response with respect to 101 rejections directed to an abstract idea of claims 1-26 have been fully considered and are persuasive. The rejections are withdrawn.
Response to Arguments
Applicant’s arguments with respect to 35 USC § 103 rejections of claims 1-26 have been fully considered but are moot because the arguments do not apply to any of the references being used in the current rejection.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the claims at issue are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); and In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on a nonstatutory double patenting ground provided the reference application or patent either is shown to be commonly owned with this application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement.
Effective January 1, 1994, a registered attorney or agent of record may sign a terminal disclaimer. A terminal disclaimer signed by the assignee must fully comply with 37 CFR 3.73(b).
Claims 1-29 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-20 of U.S. Patent No. 12,045,212 in view of claims being not patentably distinct from each other because claims 1-26 of the instant application substantially recite the limitations of claims 1-20 of U.S. Patent No. 12,045,212 which is the method for verifying entries in disparate databases.
The subject matter claimed in the instant application is fully disclosed in the referenced patent and the instant application are claiming common subject matter, as follows in Table 1 below.
Instant Application
Claims 1, 10 & 19. A method for validating data on disparate databases based on data stored on a Pick
database, the method comprising:
operating a Pick database and a modern database, in parallel; retrieving, in response to receiving an update to a business object at the Pick database,
Pick data from the Pick database related to the business object; converting the Pick data into an external format by extracting a plurality of raw data entries, determining identification tags to be associated with each of the plurality of raw data, and compiling the raw data and the identification tags into a data table in the external format; converting the Pick data from the external format to a common format by filtering entries in the data table to obtain a filtered data set comprising information associated with a
business object and restructuring the filtered data set into the common format;
retrieving corresponding data from the modern database comprising the business object, the microservice business object comprising a copy of the Pick business object stored on the
modem database; converting the corresponding data to the common format; comparing the Pick data in the common format to the corresponding data in the common format; and
validating that the corresponding data and the Pick data are consistent by determining that the Pick database business object and the corresponding data business object contain equivalent information, wherein in response to determining a data mismatch between the Pick database
business object and the corresponding data business object, sending a comparison message identifying a correction to be made to the modern database to update the corresponding data business object using a master copy of the Pick database business object to correct the corresponding data stored on the modern database.
Claims 2, 11 & 20. The method of claim 1, wherein the common format is JSON and the external format is XML.
Claims 3, 12 & 21. The method of claim 1, further comprising monitoring the Pick database for updates to a plurality of business objects.
Claims 4, 13 & 22. The method of claim 3, wherein when an update occurs, a message with a key indicating which business object the update is associated with is generated.
Claims 5, 14 & 23. The method of claim 1, wherein the business object comprises one of a customer business object, an employee business object, a vendor business object, and a financial
institution business object.
Claims 6 & 15. The method of claim 1, wherein the Pick database is part of a centralized dealer management system.
Claims 7 & 16. The method of claim 1, wherein the modern database is a modern micro service architecture.
Claim 24. The computing apparatus of claim 15, wherein the Pick database is part of a centralized dealer management system and the modern database is a modern microservice architecture.
Claims 8, 17 & 25 of the instant application are covered by claims 1, 8, and 15 of the patent.
Claims 9, 18 & 26 of the instant application are covered by claim 1, 9, 16 of the patent.
Patent U.S. 12,045,212
Claims 1, 8 & 15. A method for validating data on disparate databases based on data stored on a Pick database, the method comprising: operating, in parallel, the Pick database having a first database architecture and corresponding to a dealer management system, and a modern database having a second database architecture different from the first database structure and corresponding to a modern microservice; retrieving Pick data having a first data architecture from the Pick database having the first database architecture, the Pick data comprising a Pick business object, the retrieving being in response to receiving an update to the Pick business object at the Pick database; converting the Pick data into an external format, wherein converting the Pick data comprises extracting a plurality of raw data entries, determining identification tags to be associated with each of the plurality of raw data, and compiling the raw data and the identification tags into a data table in the external format; converting the Pick data from the external format to a common format by filtering entries in the data table to obtain a filtered data set comprising information associated with the Pick business object and restructuring the filtered data set into the common format; retrieving corresponding data having a second data architecture different from the first data architecture from the modern database having the second database architecture, the corresponding data comprising a microservice business object, the microservice business object comprising a copy of the Pick business object as stored on the modern database; converting the corresponding data to the common format; comparing the Pick data in the common format and comprising the Pick business object to the corresponding data in the common format and comprising the microservice business object, wherein the comparing is business object-type agnostic; and validating that the corresponding data and the Pick data are consistent by determining that the Pick business object and the microservice business object contain equivalent information, wherein if a data mismatch is determined between the Pick business object and the microservice business object, sending a comparison message to the modern database to update the microservice business object using a master copy of the Pick business object, the updating used to correct the corresponding data stored on the modern database.
Claims 2, 9 & 16. The method of claim 1, wherein the common format is JSON and the external format is XML.
Claims 3, 10 & 17. The method of claim 1, further comprising monitoring the Pick database for updates to a plurality of Pick business objects, including the update to the Pick business object.
Claims 4, 11 & 18. The method of claim 3, wherein when the update occurs, a message with a key indicating which Pick business object the update is associated with is generated.
Claims 5, 12 & 19. The method of claim 1, wherein the Pick business object comprises one of a customer business object, an employee business object, a vendor business object, and a financial institution business object.
Claims 6 & 13. The method of claim 1, wherein the Pick database is part of a centralized dealer management system.
Claims 7 & 14. The method of claim 1, wherein the modern database is a modern microservice architecture.
Claim 20. The computing apparatus of claim 15, wherein the Pick database is part of a centralized dealer management system and the modern database is a modern microservice architecture.
Table 1
Although the conflicting claims are not identical, they are not patentably distinct from each other because claims 1-29 of the instant application substantially recite the limitations of claims 1-20 of U.S. Patent No. 12,045,212 which is the method for verifying entries in disparate databases. Therefore, it would have been obvious to one of ordinary skill in the art of a method for retrieving data from data architecture at the time the invention was made to incorporate a process for validating data on disparate databases from the independent claims of U.S. Patent No. 12,045,212.
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 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 of this title, 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-29 are rejected under 35 U.S.C. 103 as being unpatentable over Gilley et al. (U.S. PGPub 2017/0093700; hereinafter “Gilley”) in view of Gubba et al. (U.S. PGPub 2021/0200744; hereinafter “Gubba”) and further in view of Glania et al. (U.S. Patent 8,315,988; hereinafter “Glania”).
As per claims 1, 10, and 19, Gilley discloses A method for validating data on disparate databases based on data stored on a Pick database, the method comprising:
operating a Pick database and a modern database, in parallel; (See paras. 44-45, wherein platforms and disparate sources are disclosed are disclosed, also See paras. 76, 114, wherein executing programs simultaneously are disclosed; as taught by Gilley.)
converting the Pick data into an external format by extracting a plurality of raw data entries, determining identification tags to be associated with each of the plurality of raw data, and compiling the raw data and the identification tags into a data table in the external format; (See paras. 21-22, 55, wherein identified entities are disclosed, also See Fig. 7C, paras. 24, 50, 138-140, wherein converting data and raw data disclosed, also See paras. 86, 111-114, wherein external application integration are disclosed; as taught by Gilley.)
converting the Pick data from the external format to a common format by filtering entries in the data table to obtain a filtered data set comprising information associated with a business object and restructuring the filtered data set into the common format; (See Fig. 8, paras. 48-54, 159 and 195, wherein filtering data processes are disclosed, also See Fig. 7C, paras. 24, 50, 138-140, wherein converting data and raw data disclosed; as taught by Gilley.)
However, Gilley fails to disclose retrieving, in response to receiving an update to a business object at the Pick database, Pick data from the Pick database related to the business object; converting the corresponding data to the common format; comparing the Pick data in the common format to the corresponding data in the common format; validating that the corresponding data and the Pick data are consistent by determining that the Pick database business object and the corresponding data business object contain equivalent information, wherein in response to determining a data mismatch between the Pick database business object and the corresponding data business object.
On the other hand, Gubba teaches retrieving, in response to receiving an update to a business object at the Pick database, Pick data from the Pick database related to the business object; (See Fig. 3, paras. 23-24, wherein data extraction, data retrieval, data transformation processes are disclosed, also See Fig. 9, paras. 35, 57, wherein transformation process process in which “The transformation happens on the target data source once it is imported into the memory and overwritten with the changes” [0035] (analogous to receiving an update) are disclosed; as taught by Gubba.)
converting the corresponding data to the common format; (See Fig. 3, paras. 23-24, wherein data extraction, data retrieval, data transformation processes are disclosed, also See Fig. 9, paras. 35, 57, wherein transformation process in which “The transformation happens on the target data source once it is imported into the memory and overwritten with the changes” [0035] (analogous to receiving an update) are disclosed, also See claim 5, wherein transforming data type in which “transform the elements of the second data type into the first data type” (analogous to converting the corresponding data to the common format) are disclosed; as taught by Gubba.)
comparing the Pick data in the common format to the corresponding data in the common format; (See Fig. 1, paras. 23-24, 26, wherein data comparison engine in which “data transformation portion 106 performs operations on table data, once it is stored in memory, as needed, due to the differences in how the tables are stored between the source and target databases. Legacy databases may, for example, store dates with using two digits for the year while newer databases store year information using four digits” [0024] and “data comparison engine 110 selects one or more tables and one or more columns of the stored data and performs a row count comparison between the selected tables/columns… Any differences in row count (mismatches) are stored in the key-delta file 112. The data comparison engine 110 also performs a data comparison between the selected tables/columns. Any differences in data are stored in the column-delta file 114. In some embodiments, the key-delta file 112 and the column-delta file 114 are stored in a cloud storage service” [0026] are disclosed; as taught by Gubba.)
validating that the corresponding data and the Pick data are consistent by determining that the Pick database business object and the corresponding data business object contain equivalent information, wherein in response to determining a data mismatch between the Pick database business object and the corresponding data business object. (See Figs. 5-6, paras. 45-46, wherein data validation software features in which “Migration teams may review these two files and fix data discrepancies if found… the automation of the multi-table data validation software 102 helps avoid manual validation, reduces the time to validate, helps teams to fix data migration issues, ensures the data is consistent, and ensures the security is not compromised” [0045] are disclosed; as taught by Gubba.)
Therefore, it would have been obvious to a person of ordinary skill in the computer art before the effective filing date of the claimed invention to incorporate the Gubba teachings in the Gilley system. Skilled artisan would have been motivated to incorporate multi-table data validation tool extracting, transforming, masking data taught by Gubba in the Gilley system for effectively receiving data from disparate data sources and making data available. In addition, both of the references (Gilley and Gubba) teach features that are directed to analogous art and they are directed to the same field of endeavor, such as data format conversion. This close relation between both of the references highly suggests an expectation of success.
The combination of Gilley and Gubba fails to disclose sending a comparison message identifying a correction to be made to the modem database to update the corresponding data business object using a master copy of the Pick database business object, the comparison message used to correct the corresponding data stored on the modern database.
On the other hand, Glania teaches sending a comparison message identifying a correction to be made to the modem database to update the corresponding data business object using a master copy of the Pick database business object, the comparison message used to correct the corresponding data stored on the modern database. (See Fig. 3, col. 5, ll 37-46, wherein verification manager functions on verifying consistency of data, implementing reconciliation procedures to correct any data inconsistencies in which “Verification manager 150 may communicate, via network connections 140, with each of deployment units 110 and 120. More specifically, verification manager 150 may verify the consistency of data sent between deployment units 110 and 120, data within a deployment unit itself, or data within other parts of system (analogous to sending comparison message)…if an inconsistency is detected, implement reconciliation procedures to correct for 45 any data inconsistencies” are disclosed; as taught by Glania.)
Therefore, it would have been obvious to a person of ordinary skill in the computer art before the effective filing date of the claimed invention to incorporate the Glania teachings in the combination of Gilley and Gubba system. Skilled artisan would have been motivated to incorporate system for verifying a data communication process taught by Glania in the combination of Gilley and Gubba system for effectively receiving data from disparate data sources and making data available. In addition, both of the references (Gilley, Gubba and Glania) teach features that are directed to analogous art and they are directed to the same field of endeavor, such as data format conversion. This close relation between both of the references highly suggests an expectation of success.
As per claims 2, 11, and 20, the combination of Gilley, Gubba and Glania discloses wherein the common format is JSON and the external format is XML. (See paras. 143, 170, and 183-190, wherein JSON documents and Javascript are disclosed, as taught by Gilley.)
As per claims 3, 12, and 21, the combination of Gilley, Gubba and Glania discloses monitoring the Pick database for updates to a plurality of business objects. (See paras. 105, 244 and 247, wherein monitoring data and updates are disclosed; as taught by Gilley.)
As per claims 4, 13, and 22, the combination of Gilley, Gubba and Glania discloses wherein when an update occurs, a message with a key indicating which business object the update is associated with is generated. (See paras. 105, 244 and 247, wherein monitoring data and updates are disclosed; as taught by Gilley.)
As per claims 5, 14, and 23, the combination of Gilley, Gubba and Glania discloses wherein the business object comprises one of a customer business object, an employee business object, a vendor business object, and a financial institution business object. (See Fig. 10A, paras. 240-249, wherein various objects, such as business, customer, employee, vendor and payments are disclosed; as taught by Gilley.)
As per claims 6 and 15, the combination of Gilley, Gubba and Glania discloses wherein the Pick database is part of a centralized dealer management system. (See Fig. 2A, paras. 58-63, wherein data services exchange configurations are disclosed; as taught by Gilley.)
As per claims 7 and 16, the combination of Gilley, Gubba and Glania discloses wherein the modern database is a modern microservice architecture. (See paras. 27-31, wherein service-oriented architecture is disclosed; as taught by Gilley.)
As per claims 8, 17 and 25, the combination of Gilley, Gubba and Glania discloses wherein the Pick database has a first database architecture and the modern database has a second database architecture different from the first database structure. (See paras. 7, 22, 44, wherein different protocols, different data products and services are disclosed; as taught by Gilley.)
As per claims 9, 18 and 26, the combination of Gilley, Gubba and Glania discloses wherein the Pick database, having the first database architecture, corresponds to a dealer management system, and the modern database, having the second database architecture, corresponds to a modern microservice. (See Fig. 2A, paras. 58-63, wherein data services exchange configurations are disclosed, also See paras. 27-31, wherein service-oriented architecture is disclosed, also See paras. 108, 117, 244, wherein models database services are disclosed; as taught by Gilley.)
As per claim 24, the combination of Gilley, Gubba and Glania discloses wherein the Pick database is part of a centralized dealer management system and the modern database is a modern microservice architecture. (See Fig. 2A, paras. 58-63, wherein data services exchange configurations are disclosed, also See paras. 27-31, wherein service-oriented architecture is disclosed; as taught by Gilley.)
As per claims 27, 28 and 29, the combination of Gilley and Glania fails to disclose in response to determining the data mismatch between the Pick database business object and the corresponding data business object, using the filtered data set from the Pick database that has been restructured into the common format as the master copy of the business object to correct the corresponding data stored on the modem database.
On the other hand, Gubba teaches in response to determining the data mismatch between the Pick database business object and the corresponding data business object, using the filtered data set from the Pick database that has been restructured into the common format as the master copy of the business object to correct the corresponding data stored on the modem database. (See Figs. 5-6, paras. 45-46, wherein data validation software features in which “Migration teams may review these two files and fix data discrepancies if found… the automation of the multi-table data validation software 102 helps avoid manual validation, reduces the time to validate, helps teams to fix data migration issues, ensures the data is consistent, and ensures the security is not compromised” [0045] are disclosed, also See claim 5, wherein transforming data type in which “transform the elements of the second data type into the first data type” (analogous to converting the corresponding data to the common format) are disclosed; as taught by Gubba.)
See claims 1, 10, and 19 for motivation above.
Conclusion
1. The examiner requests, in response to this Office action, support be shown for language added to any original claims on amendment and any new claims. That is, indicate support for newly added claim language by specifically pointing to page(s) and line no(s) in the specification and/or drawing figure(s). This will assist the examiner in prosecuting the application.
2. When responding to this office action, Applicant is advised to clearly point out the patentable novelty which he or she thinks the claims present, in view of the state of the art disclosed by the references cited or the objections made. He or she must also show how the amendments avoid such references or objections See 37 CFR 1.111(c).
POINT OF CONTACT
Any inquiry concerning this communication or earlier communications from the examiner should be directed to LIN LIN M HTAY whose telephone number is (571)272-7293. The examiner can normally be reached on M-F, 7am-3pm, PST.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Kavita Stanley can be reached on (571)272-8352. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/L. L. H./
Examiner, Art Unit 2153
/KAVITA STANLEY/ Supervisory Patent Examiner, Art Unit 2153