DETAILED ACTION
Claims 1-20 are pending in this office action.
Claim Rejections - 35 USC § 103
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-3, 8-10, 15-17 are rejected under 35 U.S.C. 103 as being unpatentable over Cline et al (or hereinafter “Cline”) (US 20150363458) in view of Wotring et al (or hereinafter “Wotring”) (US 6665677) and Bell et al (or hereinafter “Bell”) (US 20250094611).
As to claim 1, Cline teaches a method comprising:
“receiving, at a computer system, a request to transfer data from a first database to a second database” as receiving, at data migration system 100 that includes computing device 136 including processor and memory, is represented as a computer system (fig. 1, paragraphs 22-23), export parameters (step 200) as a request to migrate data from source database as a first database to target database as the second database (fig. 2, paragraphs 31-32, 46-47), “wherein the first database and the second database comprise at least one distinction such that a direct transfer of the data from the first database to the second database cannot occur” as the source database as the first database includes source table (paragraph 32) that is not compatible with target table of the target database as the second table is represented as at least one distinction (fig. 2, step 212, paragraphs 54-55); and the target database as the second database includes target table (paragraph 51) that is not compatible with source table is represented as at least one distinction (fig. 2, step 212, paragraph 54-55); therefore, migrating data from the source database as the first database to the target database as the second database is terminated e.g., to step 216 as cannot occur (fig. 2, paragraphs 54- 55) and the data is migrated at step 222 only when the source table and target table are compatible at step 212 (fig. 2, paragraphs 46-47).
The source table that is not compatible with target table is represented as at least one distinction (paragraphs 32, 54-55). The target table that is not compatible with the source table is represented as at least one distinction (paragraphs 32, 54-55).
In another way, the difference (not compatible) between the source table of the source database and the target table of the target database is represented as at least one distinction; thus, the migration data from the source database as the first database to the target database as the second database is terminated e.g., to step 216 as cannot occur (fig. 2, paragraphs 54- 55).
In particularly:
At 212 of FIG. 2, the data migration system 100 may determine whether the source and target tables and other database objects are compatible. For example, after attempting to match and verify all objects, when unmatched objects exist in the export file (212, No) then, at 216, data migration system 100 may alert the database manager to any unmatched objects and terminate the data migration (i.e., the import), thus averting a data migration that would not be successful. As described above, even if a potentially matching table exists, the tables may not be compatible because of differences in table structure (e.g., number of columns, length of columns, column names, etc.) (paragraph 55).
Steps 202 to 206 may be performed, for example, at a source computing device, such as computing device 136. At the conclusion of step 206, the data migration system 100 may have created an export file 400 and an image copy file 405. In other embodiments, the export file and the image copy may be in one file. In some embodiments, the export file and the image copy may be transferred to a target computing device, such as device 186. In other embodiments a target computing device may have access to a storage location of the export file and the image copy. The target computing device may then perform steps 208 to 222 to complete the migration of data from the source database to the target database (paragraph 46);
“generating, via ……executed by at least one processor of the computer system,……” as creating, via an instruction executed by the processor of the computer device e.g., computing device 136 (fig. 1, paragraphs 8, 23, 26) , an image copy of the source database at step 204 (fig. 2, paragraphs 26, 33);
“generating, via ……executed by the at least one processor, ……” as creating, via an instruction executed by the processor of the computer device e.g., computing device 136 (fig. 1, paragraphs 8, 23), an export file at step 206 (fig. 2, paragraphs 20, 26);
“generating, via the at least one processor using ……to process……, a database mapping” as creating, by the processor (fig. 1, paragraphs 22-23) using a method 200 (fig. 2) to receive as process import parameters step 208 (fig. 2, paragraph 31) or process 500 (fig. 5) to read as process a source table name, a table mapping between the source database with target database at step 210 (fig. 2) or a temporary database table storing a mapping (paragraphs 49, 54).
In particularly: At 210, data migration system 100 may begin the migration import process by mapping the source table names to the target table names and verifying that the table structures are compatible (paragraph 49).
For example, data migration system 100 may create or update a temporary database table that stores the mapping. The mapping may include the table spaces, owners, names, and object identifiers of the source and target tables (paragraph 54).
FIG. 5 is a flowchart illustrating a process 500 for mapping source objects to target objects and for verifying the compatibility of the source and target table structures, according to some implementations. Data migration system 100 can use process 500 to perform the mapping before beginning the refreshing of the target database with the image copy file (paragraph 50);
“transferring, via the at least one processor and the database mapping, the data from the first database to the second database using the database mapping according to the request” as migrating, by the processor (fig. 1, paragraphs 22-23) and the table mapping as the database mapping (at step 210) (fig. 2, paragraph 54), the data from the source database as the first database to the target database as the second database (at step 222) using the table mapping (at step 210) based on the received export parameters at step 202 (fig. 2, paragraphs 32, 46, 49-50).
In particularly:
At 202, data migration system 100 may receive export parameters from a database manager. For example, in some instances the parameters may include the name of the table space or table in the source database to be exported. A migration may be done for a table, a table space, an entire database, or a set of databases. In addition, the parameters may include the name of the metadata export file and/or the location where the export file is to be stored (paragraph 32).
The target computing device may then perform steps 208 to 222 to complete the migration of data from the source database to the target database (paragraph 46).
At 210, data migration system 100 may begin the migration import process by mapping the source table names to the target table names and verifying that the table structures are compatible. As part of the mapping process data migration, system 100 may create a temporary database table from the information contained in the metadata export file (paragraph 49).
FIG. 5 is a flowchart illustrating a process 500 for mapping source objects to target objects and for verifying the compatibility of the source and target table structures, according to some implementations. Data migration system 100 can use process 500 to perform the mapping before beginning the refreshing of the target database with the image copy file (paragraph 50).
Cline does not explicitly teach limitations
an entity relationship mapping algorithm, a first text description of first entity relationships, the first entity relationships identifying how data is stored in the first database;
the entity relationship mapping algorithm, a second text description of second entity relationships, the second entity relationships identifying how data is stored in the second database;
a natural language processing (NLP) based large language model (LLM); the first text description with the second text description,
wherein the database mapping identifies how information in the first database corresponds to the second database.
Wotring teaches limitations
an entity relationship mapping algorithm, the entity relationship mapping algorithm (as a database mapping process of relationships of database table(s) is represented as an entity relationship mapping algorithm: col. 4, lines 38-46; col. 5, lines 39-55; col. 7. lines 65-67, figs. 8A-8B, 10A).
In particularly:
The first step in the transformation of a relational database to a hierarchical database is to create a hierarchical database schema that correlates with the structure of the existing relational database. In a relational database, there is usually a main or parent table that holds the basic information of the database and then a series of related tables that hold information associated with the main or parent table. Within a relational database, there is usually a relationship key structure between tables. The relationship key structure defines relationships between tables through one or more key files that are shared between tables. The key structure helps to identify the structure of the relational database and is used to create a hierarchical schema. The key structure also helps to allow tailoring of SQL statements during the database mapping process (col. 5, lines 39-55).
Associations between parent and child tables are revealed through matching their key values. The key structure defines relationships between tables through any number of key fields that are shared between two or more tables. Hence, the term "relational database." The key structure is extremely important in identifying what the structure of the relational database is, in order to create a hierarchical schema. In addition, the key structure reveals how to tailor SQL statements during the database mapping process (col. 4, lines 38-46);
“a first text description of first entity relationships, the first entity relationships” as relational database schema 203 (fig. 2, col. 4, lines 10-20) that includes text fields e.g., first name, middle, last and street of table relationships of the relational database are represented as a first text description of the first entity relationships (figs. 3, 10A-10B, col. 4, lines 10-40; col. 3, lines 38-40; col. 5, line 45-55), the table relationships of the relational database are represented as the first entity relationships (figs. 3, 10A-10B, col. 3, lines 38-40; col. 5, lines 45-55).
In particularly:
FIG. 2, Relational Database Schema 203 and Hierarchical Database Schema 201 are used to create a Database Mapping Structure 202. Database Mapping Structure 202, also called Import Map, defines the logic for transforming the records of an existing relational database into hierarchical database objects. The content of Relational Database 205 is imported to Import Facility 204, via Structured Query Language (SQL) statements sent by Import Facility 204 (col. 4, lines 10-20).
Associations between parent and child tables are revealed through matching their key values. The key structure defines relationships between tables through any number of key fields that are shared between two or more tables (col. 4, lines 38-41).
Within a relational database, there is usually a relationship key structure between tables. The relationship key structure defines relationships between tables through one or more key files that are shared between tables. The key structure helps to identify the structure of the relational database and is used to create a hierarchical schema. The key structure also helps to allow tailoring of SQL statements during the database mapping process (col. 5, lines 39-55);
“a second text description of second entity relationships, the second entity relationships identifying how data is stored in the second database” as a hierarchical database schema 201 (fig. 2) that includes text e.g., First, 404, Middle 404 is represented as a second text description of the table relationships as the second entity relationships (fig. 5, col.6, lines 10-30), the table relationships as the second entity relationships is used to determine which table’s data is stored in which compound object in hierarchical database 504 (col. 6, lines 10-30).
As discussed above, the table relationships as the second entity relationships are used to determine which table’s data is stored in which compound object in hierarchical database 504 that is represented as the second entity relationships identifying how data is stored in the second database. In this case, the hierarchical database 504 is represented as the second database.
In particularly: FIG. 5, the transformation of a Relational Database 500 to a Hierarchical Database 504 results in the data from each table of the Relational Database 500 being stored in a compound object of the Hierarchical Database 504. The determination of which table's data is stored in which compound object is for the user to determine, based upon the relationships between the tables in the Relational Database 500. In the embodiment shown, TABLE 1501 is joined only to related TABLE 2502 by a primary key. Thus, upon transformation, the data in TABLE 1501 is stored in the parent Compound Object 1505 which has no parent of its own. TABLE 2502 is joined both to TABLE 1501 by a primary key and to TABLE 3503, by a secondary key, also known as a foreign key. Thus, upon transformation, the data stored in TABLE 2502 is stored in Compound Object 2506, which has a parent and a child of its own. TABLE 3503 is joined to TABLE 2502 by a secondary key and transitively joined to TABLE 1501 via TABLE 2502. Thus, upon transformation, the data stored in TABLE 3503 is stored in Compound Object 3507, which is a child of Compound Object 2506 (col. 6, lines 10-30);
“wherein the database mapping identifies how information in the first database corresponds to the second database” as an import map for relational database is represented as the database mapping maps as identifies each relational database field as information in relational database as the first database to a hierarchical field in the hierarchical database as the second database (fig. 2, abstract, col. 2, lines 1-20; col. 3, lines 50-67).
In particularly:
a computer-implemented method for transforming data in a relational database to a hierarchical database. It comprises creating an import map that maps each relational database field to a hierarchical field in the hierarchical database using a relational database schema and a hierarchical database schema, using the import map to import data from the relational database; and transforming the relational data into hierarchical documents (abstract);
“the first text description with the second text description” as use a relational database schema as the first text description with a hierarchical database schema as the second text description to generate database mapping structure (import map) (fig. 2, col. 4, lines 10-20).
In particularly:
Referring now to FIG. 2, Relational Database Schema 203 and Hierarchical Database Schema 201 are used to create a Database Mapping Structure 202. Database Mapping Structure 202, also called Import Map, defines the logic for transforming the records of an existing relational database into hierarchical database objects. The content of Relational Database 205 is imported to Import Facility 204, via Structured Query Language (SQL) statements sent by Import Facility 204 (col. 4, lines 10-20).
Wotring further teaches limitation
“generating, via the at least one processor using ….to process the first text description with the second text description, a database mapping” as creating, via a CPU (col. 11, lines 50-60) using a computer-implemented method to execute a relational database schema as the first text description with a hierarchical database schema as the second text description, database mapping structure (import map) as a database mapping (fig. 2, col. 2, lines 1-15; col. 4, lines 10-20).
Cline and Wotring disclose a method of transferring data from a database to another database. Theses references are in the same field with application field. Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention Wotring’s teaching to Cline’s system in order to allow data to be transformed from one format of a database to format of another database for transferring successfully and further to improve data integrity and quality using data scrubbing algorithms.
Bell teaches limitations
“identifying how data is stored in the first database” as determining as identifying how to store sensitive data (paragraph 83) in local storage (paragraph 74) e.g., data repository 216 as the first database (paragraph 68).
In particularly: Handling engine 214 can determine how to store, present, transmit, or otherwise operate on the sensitive data (paragraph 83). A instructed by handling engine 214, personal data can be stored on local storage, but not on cloud storage (paragraph 74). Data repository 216 can be physical storage such as local storage or file storage on fixed or portable computing device. In another embodiment, data repository 216 can be cloud-based storage including a plurality of storage nodes (paragraph 68);
“a natural language processing (NLP) based large language model (LLM)” as a large language model (LLM) such as ChatGPT that uses natural language processing to create human dialogue is represented as a natural language processing (NLP) based large language model (LLM) (paragraph 2).
Bell further teaches limitations
“identifying how data is stored in the second database” as determining as identifying how to store sensitive data (paragraph 83) in local storage (paragraph 74) e.g., data repository 216 as the first database (paragraph 68) or indicating storing personal data in remote data storage as the second database (paragraphs 59-60).
Cline and Bell disclose a method of transferring data from a database to another database. Theses references are in the same field with application field. Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention Bell’s teaching to Cline’s system in order to protect data during transferring data from one database to another database, to indicate that a transfer of data is desired to a certain migration center from another migration center, and further to interpret user interactions to determine a data request made by the user efficiently and quickly.
As to claims 2, 9, 16, Cline, Wotring and Bell teach limitation “wherein the NLP-based LLM is executed by a third party” as a large language model (LLM) such as ChatGPT that uses natural language processing to create human dialogue is represented as a natural language processing (NLP) based large language model (LLM) (Bell: paragraph 2). The NPL-based LLM is executed by (Bell: paragraphs 2, 86) a third party (Bell: paragraphs 27, 46; Cline: paragraph 22).
As to claims 3, 10, 17, Cline, Wotring and Bell teach limitation “wherein the NLP-based LLM is CHATGPT” as the NLP-based LLM is CHATGPT(Bell: paragraphs 2, 86).
Claim 8 has the same claimed limitation subject matter as discussed in claim 1; thus claim 8 is rejected under the same reason as discussed in claim 1. In addition, Cline further teaches a system comprising: “at least one processor; and a non-transitory computer-readable storage medium having instructions stored which, when executed by the at least one processor, cause the at least one processor to perform operations comprising:” as a non-transitory computer-readable storage medium storing instructions that are executed by a processor, causes the processor to perform operations including (paragraphs 8, 10-11);
“generating, by executing……, …....” as creating, by executing an instruction (fig. 1, paragraphs 8, 23, 26), an image copy of the source database at step 204 (fig. 2, paragraphs 26, 33);
“generating, by executing……, ……” as creating, executing instruction by the processor of the computer device e.g., computing device 136 (fig. 1, paragraphs 8, 23), an export file at step 206 (fig. 2, paragraphs 20, 26);
“generating, using ……to process……, a database mapping” as creating, by the processor (fig. 1, paragraphs 22-23) using a method 200 (fig. 2) to receive as process import parameters step 208 (fig. 2, paragraph 31) or process 500 (fig. 5) to read as process a source table name, a table mapping between the source database with target database at step 210 (fig. 2) or a temporary database table storing a mapping (paragraphs 49, 54).
In particularly: At 210, data migration system 100 may begin the migration import process by mapping the source table names to the target table names and verifying that the table structures are compatible (paragraph 49).
For example, data migration system 100 may create or update a temporary database table that stores the mapping. The mapping may include the table spaces, owners, names, and object identifiers of the source and target tables (paragraph 54).
FIG. 5 is a flowchart illustrating a process 500 for mapping source objects to target objects and for verifying the compatibility of the source and target table structures, according to some implementations. Data migration system 100 can use process 500 to perform the mapping before beginning the refreshing of the target database with the image copy file (paragraph 50);
“transferring, using the database mapping, the data from the first database to the second database using the database mapping according to the request” as migrating, based on the table mapping as the database mapping (at step 210) (fig. 2, paragraph 54), the data from the source database as the first database to the target database as the second database (at step 222) using the table mapping (at step 210) corresponding to the received export parameters at step 202 (fig. 2, paragraphs 32, 46, 49-50).
In particularly:
At 202, data migration system 100 may receive export parameters from a database manager. For example, in some instances the parameters may include the name of the table space or table in the source database to be exported. A migration may be done for a table, a table space, an entire database, or a set of databases. In addition, the parameters may include the name of the metadata export file and/or the location where the export file is to be stored (paragraph 32).
The target computing device may then perform steps 208 to 222 to complete the migration of data from the source database to the target database (paragraph 46).
At 210, data migration system 100 may begin the migration import process by mapping the source table names to the target table names and verifying that the table structures are compatible. As part of the mapping process data migration, system 100 may create a temporary database table from the information contained in the metadata export file (paragraph 49).
FIG. 5 is a flowchart illustrating a process 500 for mapping source objects to target objects and for verifying the compatibility of the source and target table structures, according to some implementations. Data migration system 100 can use process 500 to perform the mapping before beginning the refreshing of the target database with the image copy file (paragraph 50).
Wotring further teaches limitation
“generating, using ….to process the first text description with the second text description, a database mapping” as creating, using a computer-implemented method to use a relational database schema as the first text description with a hierarchical database schema as the second text description, database mapping structure (import map) as a database mapping (fig. 2, col. 2, lines 1-15; col. 4, lines 10-20).
Cline and Wotring disclose a method of transferring data from a database to another database. Theses references are in the same field with application field. Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention Wotring’s teaching to Cline’s system in order to allow data to be transformed from one format of a database to format of another database for transferring successfully and further to improve data integrity and quality using data scrubbing algorithms.
Claim 15 has the same claimed limitation subject matter as discussed in claims 1, 8; thus claim 15 is rejected under the same reason as discussed in claims 1, 8. In addition, Cline teaches “a non-transitory computer-readable storage medium having instructions stored which, when executed by at least one processor, cause the at least one processor to perform operations comprising” as a non-transitory computer-readable storage medium storing instructions that are executed by a processor, causes the processor to perform operations including (paragraphs 8, 10-11).
Claims 4-5, 11-12, 18-19 are rejected under 35 U.S.C. 103 as being unpatentable over Cline in view of Wotring and Bell and further in view of Beyer (US 20210182237).
As to claims 4,11, 18, Cline, Wotring and Bell teach limitation “wherein the at least one distinction comprises……” as the difference (not compatible) of the source database as the first database and the target table as the second table that is represented as the at least one distinction includes different structures (Cline: fig. 2, step 212, paragraphs 32, 54-55) or different types (Wotring: col. 1, lines 20-30).
Cline, Wotring and Bell teach limitation
different names for fields.
Beyer teaches limitation
“different names for fields” as different names for fields (paragraph 16).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention Beyer’s teaching to Cline’s system in order to
allow fast searching and retrieval for converting the data from a format of the source field into a format of the target field.
As to claims 5, 12,19, Cline, Wotring and Bell teach limitation “wherein the at least one distinction comprises……” as the difference (not compatible) of the source database as the first database and the target table as the second table that is represented as the at least one distinction includes different structures (Cline: fig. 2, step 212, paragraphs 32, 54-55) or different types (Wotring: col. 1, lines 20-30).
Cline, Wotring and Bell teach limitation
distinct fields.
Beyer teaches limitation
“distinct fields” as fields that have different names are represented distinct fields (paragraphs 16, 37).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention Beyer’s teaching to Cline’s system in order to
allow fast searching and retrieval for converting the data from a format of the source field into a format of the target field.
Claims 6-7, 13-14, 20 are rejected under 35 U.S.C. 103 as being unpatentable over Cline in view of Wotring and Bell and further in view of Wynblatt et al (or hereinafter “Wy”) (US 20020143755)
As to claims 6, 13, 20 Cline teaches limitations
“the non-transitory computer-readable storage medium having additional instructions stored which, when executed by the at least one processor, cause the at least one processor to perform operations comprising: or
having additional instructions stored which, when executed by the at least one processor, cause the at least one processor to perform operations comprising” as a non-transitory computer-readable storage medium storing instructions that are executed by a processor, causes the processor to perform operations including (Cline: paragraphs 8, 10-11):
“generating, via the at least one processor using the database mapping, ……for: saving data to the first database and the second database” as creating, by the processor (Cline: fig. 1, paragraphs 22-23) using a temporary database table having mapping as database mapping (Cline: fig. 2, paragraphs 49-50, 54), import map 202 for (Wotring: col. 15, lines 19-25) storing data to local storage as the first database (Beyer: paragraph 74) and a remote data storage as second database (Beyer: paragraph 60);
“retrieving data from the first database and the second database” as retrieving data from (Cline: paragraphs 41, 62) local storage as the first database (Beyer: paragraph 74) and a remote data storage as second database (Beyer: paragraph 60);
“wherein when a user enters a command for a given database using……, the at least one processor…… the given database” as when a user made data request as a command for repository 216 as a given database using AI model 202 e.g., a user operating user device 206 interact with AI model 202 (Bell: paragraphs 79-81), the processor (Bell: paragraph 14; Wotring: paragraphs 8, 23) retrieve data from repository 216 as the given database (Bell: Paragraph 80).
Cline, Wotring and Bell do not explicitly teach limitation:
a global schema; the global schema;
converts the command from the global schema to a format needed by the given database.
Wy teaches limitations
“a global schema; the global schema” as a global schema (paragraph 50);
“converts the command from the global schema to a format needed by the given database” as converts the query as the command from the global schema to the local schema as format that is relevant for data source as the given database so that the query can access the data source (fig. 2, paragraphs 46, 49-50)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention Wy’s teaching to Cline’s system in order to allow multiple users and programs to access and process data source data from any point in the network and further to significantly reduce network traffic compared to polling or continuous-refresh systems
As to claims 7, 14, Cline, Wotring, Bell and Wy teach limitation “wherein converting of the command from the global schema to the format needed by the given database occurs via machine learning” as converting the query from the global schema to the local schema as format required for the data source as the given database is processed as occurs via (Wy: fig. 2, paragraphs 46, 49-50; Cline: paragraphs 47, 54) machine learning model (Bell: paragraphs 9-10).
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CAM-Y T TRUONG whose telephone number is (571)272-4042. The examiner can normally be reached (571) 272 4042.
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, SHERIEF BADAWI can be reached at (571) 272-9782. 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.
/CAM Y T TRUONG/ Primary Examiner, Art Unit 2169