DETAILED ACTION
Notice of 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 .
Information Disclosure Statement
The information disclosure statement submitted on 4/17/2024 has been considered.
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 therefor, subject to the conditions and requirements of this title.
Claims 15-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. Claims 15-20 do not fall within at least one of the four categories of patent eligible subject matter because they are directed to a computer readable storage medium (an article of manufacture), and the broadest reasonable interpretation of a computer readable storage medium includes transitory forms of signal transmission (often referred to as “signals per se”). MPEP 2106.03. The examiner suggests amending such limitations to recite “a non-transitory computer readable storage medium” in order to overcome the rejections.
Under Step 2A, Prong 1, the examiner acknowledges that the independent claims, under the broadest reasonable interpretation, include at least a mental step of “compar[ing] the output file to an output sample”, where a human could potentially mentally compare simple files mentally, such as simple text files illustrated in Fig. 4 of the instant application.
However, under Step 2A, Prong 2, the examiner finds that the claimed invention is an improvement to the functioning of a computer. See MPEP 2106.04(d)(1). Para. 0007 of the instant specification explains how the claimed invention improves data interoperability of computer file types, file formats, and software, and therefore this improvement to computer functionality integrates the judicial exception into a practical application.
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.
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.
Claims 1-4, 7-11, and 14-18 are rejected under 35 U.S.C. 103 as being unpatentable over US 20230023645 A1, hereinafter referenced as RETINAJ, in view of US 20100023921 A1, hereinafter referenced as CHAAR, and further in view of US 20220019663 A1, hereinafter referenced as STAPLETON.
Regarding Claim 1
RETINAJ teaches:
An artificial intelligence (AI) based model builder system configured to automatically transform computer files, the system comprising: (RETINAJ, para. 0001: “The present disclosure relates to mapping a schema of one database to a schema of a different database. In particular, the present disclosure relates to machine learning techniques for schema mapping.”
RETINAJ, para. 0022: “As indicated above, generating a mapping that converts a database schema associated with a source database into a database schema associated with a target database is time consuming, error prone, and laborious. Examples of the present disclosure overcome these challenges associated with generating a database schema using trained machine learning models that, in some embodiments, may include graph neural networks (GNN). In some examples, using a trained graph neural network to graphically render source and target database schemas as n-dimensional graphs improves the convenience, speed, and accuracy of the schema mapping process. In particular, the GNN may identify source to target database schema mappings using, among other features of the graph, context data associated with each node in a graph.”;
RETINAJ, para. 0040: “In some examples, training a GNN may occur in stages, first using a generic dataset, whether a publicly available NLP training dataset (e.g., an NLP training dataset, such as those available from commoncrawl or Wikipedia®) or a generically pre-trained model (e.g., OpenAI GPT-3, Google® BERT, Microsoft® CodeBERT, Facebook® RoBERTa).”
RETINAJ, para. 0087: “In some examples, the mapping may generate a set of rules that, when applied, transforms, converts, or translates source database schema into a target database schema. In some examples, the mapping may be stored as a data entity or data object that identifies the correspondence between source data entities and target data entities. In some examples, the mapping may be stored as an executable file that translates or converts source data entities into target data entities.”;
Examiner’s Note: RETINAJ teaches mapping a source database schema (corresponding to a recited “file”) to a target database schema, where the mapping scheme uses a graph neural network (GNN) (corresponding to recited “AI”))
one or more processors; and (RETINAJ, para. 0118: “For example, FIG. 5 is a block diagram that illustrates a computer system 500 upon which an embodiment of the invention may be implemented. Computer system 500 includes a bus 502 or other communication mechanism for communicating information, and a hardware processor 504 coupled with bus 502 for processing information. Hardware processor 504 may be, for example, a general purpose microprocessor.”)
a training base comprising a memory configured to store data formats, sample data, and data specifications defining one or more respective file types; (RETINAJ, para. 0035: “In some examples, the training logic 112 receives a set of data items as input (i.e., a training corpus or training data set). Examples of data items include, but are not limited to, data entities (e.g., structures and/or objects, such as fields, arrays, tables) associated with a “target” database schema that, as described below, a “source” database schema is mapped to. The data items used for training may also be associated with one or more attributes, such as those described above in the context of the feature extractor 108 (e.g., field names, field values, field value types).”;
RETINAJ, para. 0040: “In some examples, training data used by the training logic 112 to train the machine learning engine 110 includes feature vectors of data items that are generated by the feature extractor 108, described above. In various examples, the training logic 112 may access one or more training datasets (e.g., publicly and/or privately available datasets) that may be wholly or partially rendered as a graph. A training graph (or graphs) (i.e., one or more graphical representations of the training data and/or multiple training datasets) may then be used to train a graphical neural network (GNN). In some examples, training a GNN may occur in stages, first using a generic dataset, whether a publicly available NLP training dataset (e.g., an NLP training dataset, such as those available from commoncrawl or Wikipedia®) or a generically pre-trained model (e.g., OpenAI GPT-3, Google® BERT, Microsoft® CodeBERT, Facebook® RoBERTa). Training may continue by subsequently using additional datasets that are focused in a particular field or subject to which a trained GNN will be applied. Examples, include Luminati for health care subject matter and Kaggle for acronyms, abbreviations, and other similar concise expressions. Training may further be refined by applying one or more filters to the training data to restrict some aspects of the training data. For example, geographic filters (e.g., ZIP code, city, state, province) may be used to exclude regional colloquialisms in an NLP database.”;
RETINAJ, para. 0058: “In one or more embodiments, data repositories 122, 126 may be any type of storage unit and/or device (e.g., a file system, database, collection of tables, or any other storage mechanism) for storing data. Further, data repositories 122, 126 may each include multiple different storage units and/or devices. The multiple different storage units and/or devices may or may not be of the same type or located at the same physical site. Further, data repositories 122, 126 may be implemented or may execute on the same computing system as the ML application 104. Alternatively or additionally, data repositories 122, 126 may be implemented or executed on a computing system separate from the ML application 104. Data repositories 122, 126 may be communicatively coupled to the ML application 104 via a direct connection or via a network.”
RETINAJ, para. 0119: “Computer system 500 also includes a main memory 506, such as a random access memory (RAM) or other dynamic storage device, coupled to bus 502 for storing information and instructions to be executed by processor 504.”)
a generative AI model; (RETINAJ, para. 0022: “As indicated above, generating a mapping that converts a database schema associated with a source database into a database schema associated with a target database is time consuming, error prone, and laborious. Examples of the present disclosure overcome these challenges associated with generating a database schema using trained machine learning models that, in some embodiments, may include graph neural networks (GNN). In some examples, using a trained graph neural network to graphically render source and target database schemas as n-dimensional graphs improves the convenience, speed, and accuracy of the schema mapping process. In particular, the GNN may identify source to target database schema mappings using, among other features of the graph, context data associated with each node in a graph.”;
RETINAJ, para. 0040: “In some examples, training a GNN may occur in stages, first using a generic dataset, whether a publicly available NLP training dataset (e.g., an NLP training dataset, such as those available from commoncrawl or Wikipedia®) or a generically pre-trained model (e.g., OpenAI GPT-3, Google® BERT, Microsoft® CodeBERT, Facebook® RoBERTa).”
Examiner’s Note: the GNN, which can be based on GPT-3 (a generative pre-trained transformer 3) corresponds to the recited “generative AI model”)
a model and map builder engine comprising computing instructions configured to access the AI model and the training base, wherein the computing instructions of the model and map builder engine, when executed by the one or more processors, cause the one or more processors to: (RETINAJ, para. 0034: “The machine learning engine 110 of the ML application 104 includes training logic 112 and a trained machine learning (ML) model 114. The trained ML model 114 further includes a graph generator 115 and a graph analyzer 116.”;
RETINAJ, para. 0035: “In some examples, the training logic 112 receives a set of data items as input (i.e., a training corpus or training data set). Examples of data items include, but are not limited to, data entities (e.g., structures and/or objects, such as fields, arrays, tables) associated with a “target” database schema that, as described below, a “source” database schema is mapped to. The data items used for training may also be associated with one or more attributes, such as those described above in the context of the feature extractor 108 (e.g., field names, field values, field value types).”;
RETINAJ, para. 0036: “As described below, one example of an ML model used in some embodiments of the system 100 is that of a graph neural network (GNN). In this example, the training logic 112 may progressively train the GNN using different data sets. For example, the GNN may be trained using supervised training data using one or more labeled graph-representations of training schemas. In some embodiments, these supervising training processes may be executed using generic schema training data. In other examples, the training logic 112 may use a “target” database schema (i.e., the schema into which a source database schema is to be translated and/or converted) to train the GNN algorithm.”;
Examiner’s Note: the Machine Learning Engine 110 corresponds to the recited “model and map builder engine”, where the Machine Learning Engine 110 includes an ML Model 114, which can be a GNN, and training logic 112 which has access to training datasets as explained above)
input a source file and a source file specification, corresponding to a source file type selected from the training base, the source file including one or more source data items, the source file specification defining formats of the one or more source data items; (RETINAJ, para. 0031: “In other examples, the feature extractor 108 may identify attributes associated with data entities and a database schema, tokenize the attributes, and generate one or more feature vectors that correspond to entities of the schema and/or the schema itself. For example, the feature extractor 108 may identify data entities associated with a database schema that include tables, arrays, files, sets, fields, and/or other types of data objects. The feature extractor 108 may then identify, within these various data objects, attribute names, attribute definitions, attribute descriptions, permitted field values and/or permitted field value types (e.g., integer, string, alphanumeric characters). The feature extractor 108 may then process the identified entities, entity types, and/or attributes to generate one or more feature vectors.”
RETINAJ, para. 0045: “The ML model 114 is schematically represented in FIG. 1 as including a graph generator 115 and a graph analyzer 116 for convenience of explanation. As described below in more detail in the context of FIGS. 2 and 3, the graph generator 115 may receive a database schema and convert the schema into a graph representation. In preparation for representing the schema as a graph of nodes and edges, the ML model 114 may analyze database schema data and identify various attributes associated with the analyzed schema and/or the entities of the schema. These attributes may then be used to identify schema entities and entity relationships that are then used to render the schema as a graph. Example attributes, also indicated above, include but are not limited to attribute names, attribute definitions, attribute descriptions, entity names, entity descriptions, entity groups, industry type (e.g., financial, healthcare, manufacturing, service), as well as other contextual data. Once the ML model 114 has analyzed these data, the graph generator 115 may use the analysis to represent the analyzed schema as a graph.”
RETINAJ, para. 0059: “In the embodiment illustrated in FIG. 1, the data repositories 122, 126 includes a source schema 124 and a target schema 128, respectively. In some embodiments, the data repositories 122, 126 also store data items associated with each of the source database and the target database, respectively.”;
Examiner’s Note: the source schema 124 corresponds to the recited “source file” and the feature vector extracted for the source schema corresponds to the recited “source file specification”, and such information is input to the ML Model 114 and Graph Generator 115 in order to create a graph representation for the schema)
generate, using the generative AI model based on the source file and the source file specification, a source file model comprising a source-based graph representation including one or more source nodes, each of one or more source nodes associated with a respective data item of the one or more source data items; (RETINAJ, para. 0045: “The ML model 114 is schematically represented in FIG. 1 as including a graph generator 115 and a graph analyzer 116 for convenience of explanation. As described below in more detail in the context of FIGS. 2 and 3, the graph generator 115 may receive a database schema and convert the schema into a graph representation. In preparation for representing the schema as a graph of nodes and edges, the ML model 114 may analyze database schema data and identify various attributes associated with the analyzed schema and/or the entities of the schema. These attributes may then be used to identify schema entities and entity relationships that are then used to render the schema as a graph. Example attributes, also indicated above, include but are not limited to attribute names, attribute definitions, attribute descriptions, entity names, entity descriptions, entity groups, industry type (e.g., financial, healthcare, manufacturing, service), as well as other contextual data. Once the ML model 114 has analyzed these data, the graph generator 115 may use the analysis to represent the analyzed schema as a graph.”
RETINAJ, para. 0066: “Nodes of the graph representing the source database schema (“source graph”) may correspond to entities in the source database schema (operation 206). Edges that connect nodes in the source graph may represent the relationships between the entities connected by the edge (operation 208). A simple illustration of an edge between two nodes is that of a direct connection. In terms of the directly connected data entities themselves, these entities may for example have a direct relationship of a set and subset (e.g., parent-child). Another illustration of a direct relationship is that of peer tables that are employed by another data entity (e.g., a sibling direct relationship). Other types of data entities and other types of direct relationships will also be appreciated in light of this description.”;
Examiner’s Note: Graph Generator 115 creates a graph representation of the source schema, where nodes of the graph correspond to entities in the source database schema)
generate, using the generative AI model, a transform map mapping the one or more source nodes to one more target nodes of a target-based graph of a target file model corresponding to a target file type; (RETINAJ, para. 0069: “A trained GNN may use graphical context data (e.g., in latter stages of the method 200 described below) to further improve the accuracy of the graph and of the mapping from the source graph to the target graph.”;
RETINAJ, para. 0074: “The system may then begin a process of mapping the source schema to the target schema using the corresponding graphs and graphical context data. In some examples, this process may include comparing graphical context data for a selected node in the source graph to graphical context data for a selected node in the target graph (operation 232). The selection and comparison processes are repeated for some or all of the nodes in the source and target graphs to generate a mapping, thereby effectively predicting links between the selected node and other nodes in the target graph”
RETINAJ, para. 0086: “For selected source graph nodes that are identified as similar to corresponding target graph nodes, the system may generate a mapping between these nodes, and more specifically, between the corresponding aspects of the source schema and target schema represented by the similar nodes (operation 240). In some examples, this mapping may associate data entities of the source schema to those of the target schema. In some examples, the mapping may (in addition or as an alternative), associate attributes and/or attribute values of a source database schema with those of a target database schema. The mapping enables, for example, entities of a source database to be interoperable with (e.g., accessed/read/written to) or imported into a target database.”;
… generate an output file by applying the transform map to the one or more nodes of the source file model; and (RETINAJ, para. 0020: “The system uses identified correspondences to generate a map that maps elements of the source database schema to a target database schema. This map may be applied to convert data items from one schema to another.”;
RETINAJ, para. 0087: “In some examples, the mapping may generate a set of rules that, when applied, transforms, converts, or translates source database schema into a target database schema. In some examples, the mapping may be stored as a data entity or data object that identifies the correspondence between source data entities and target data entities. In some examples, the mapping may be stored as an executable file that translates or converts source data entities into target data entities.”;
Examiner’s Note: the target schema that is created using the mapping corresponds to the recited “output file”)
However, RETINAJ fails to explicitly teach:
invoke a semantic model-based transformation service to …
invoke a comparison module to compare the output file to an output sample, the output sample describing expected formats of the output file.
However, in a related field of endeavor (reconciling data canonical data model exchange formats in an enterprise environment, see para. 006), CHAAR teaches and makes obvious:
invoke a semantic model-based transformation service to generate an output file by applying the transform map to the one or more nodes of the source file (CHAAR, para. 0313: “With reference now to FIG. 16, a semantic data model 1602 is interpreted by a Semantic Model Transform Algorithm (SMTA) 1604, which is specific for a particular Software Factory 1606 (which utilizes the architecture of the Software Factory 100 depicted and described above in FIG. 1). SMTA 1604 projects data that describes activities within the Software Factory 1606 in the format and notation that supports a specific role or responsibility in the SDLC. Thus, practitioners 1608 are able to view in canonical form the semantic data model 1602. That is, the semantic data model 1602 is in a format that "makes sense" to the practitioners 1608, since it presents a high-level view of the Software Factory 1606 using language, terms and descriptors that the practitioners 1608 readily understand.”;
CHAAR, para. 0314: “The Semantic Model Transform Algorithm 1604 may be accessible via standard relational Database Management System (DBMS) technology, either programmatically via an Application Programming Interface (API) or through a Software Factory custom semantic reconciliation engine (neither shown in FIG. 16, but are understood to be part of SFP 1348 described in FIG. 13).”;
CHAAR, para. 0315: “The Semantic Model Transform Algorithm 1604 thus defines semantic data model projections which allow software factory key artifacts to be viewed in the notation required by software development practitioners.”;
Examiner’s Note: CHAAR teaches using a semantic data model for a particular factory’s software environment; the RETINAJ-CHAAR combination now uses a semantic data model as in CHAAR when transforming the source schema to the target schema of RETINAJ, where for example, the semantic data model can be used to explain the terminology required by the target schema)
Before the effective filing date of the present application, it would have been obvious to one of ordinary skill to combine the teachings of RETINAJ with CHAAR as explained above. As disclosed by CHAAR, one of ordinary skill would have been motivated to do so in order to utilize the techniques related to “repeatable scientific managed engineered streamline information supply chain. The software factory incorporates applied system and industrial engineering quality assured efficiencies that provide for the waste eliminating, highly optimized performed instrumentation, measured monitoring and risk mitigated management of software development.” (para. 0028). In other words, CHAAR teaches techniques for ensuring that customized software systems have interoperability, and one of ordinary skill in the art would have been motivated to apply those teachings to source and target schema from different vendors with respect to interoperability.
However, RETINAJ and CHAAR fail to explicitly teach:
invoke a comparison module to compare the output file to an output sample, the output sample describing expected formats of the output file.
However, in a related field of endeavor (machine learning models, see para. 0001), STAPLETON teaches and makes obvious:
invoke a comparison module to compare the output file to an output sample, the output sample describing expected formats of the output file. (STAPLETON, para. 0086: “At block 706, the system may compare one or more of the verification outputs to one or more known verification outputs. In various embodiments, the one or more known verification outputs may have been generated based on prior application of the digital key as input across at least the same portion of the trained machine learning model. Intuitively, if a ML model remains unaltered, then applying the same data across the same portion of the ML model at different times should yield the same output. Thus, in some embodiments, the comparing of block 706 seeks an exact match between the verification output(s) generated at block 704 and the known verification output(s). However, this is not meant to be limiting. In other embodiments, other types of comparisons may be performed. For example, the verification outputs generated at block 704 may be applied as input to a hash function, and the result may be compared to another hash or value used as a proxy for, or generated from, known verification output(s).”;
Examiner’s Note: the RETINAJ-CHAAR-STAPLETON combination now uses the comparison teachings of STAPLETON to verify the transformation mapping to target schema of RETINAJ by comparing transformed files to known files to determine if there is an exact or close match as in STAPLETON)
Before the effective filing date of the present application, it would have been obvious to one of ordinary skill to combine the teachings of RETINAJ with CHAAR and STAPLETON as explained above. As disclosed by STAPLETON, one of ordinary skill would have been motivated to do so in order to verify the integrity of a ML model in order to determine if it has been compromised by an attacker. (para. 0039).
Regarding Claim 2
RETINAJ, CHAAR, and STAPLETON teach the system of claim 1 as explained above. RETINAJ further teaches:
update the training base by registering the source file model and the transform map with the training base. (RETINAJ, para. 0027: “That is, a user may label, using a GUI, an analysis generated by the ML application 104 as accurate or not accurate, thereby further revising or validating training data. This latter feature enables a user to label data analyzed by the ML application 104 so that the ML application 104 may update its training.”;
RETINAJ, para. 0089: “The manual updates may be provided to the GNN or other trained machine learning model to update training data. Essentially the user may alter a label via a user interface so that a correct association between a source database schema data entity and a corresponding target database schema entity are stored in the system.”;
Examiner’s Note: One of ordinary skill would understand that updating the training data includes updating the training data to utilize known good source file models (including source graph representations) and associated transform maps)
However, RETINAJ and CHAAR fail to explicitly teach:
determine, based on the comparison, that the output file matches the output sample
However, in a related field of endeavor (machine learning models, see para. 0001), STAPLETON teaches and makes obvious:
determine, based on the comparison, that the output file matches the output sample (STAPLETON, para. 0086: “At block 706, the system may compare one or more of the verification outputs to one or more known verification outputs. In various embodiments, the one or more known verification outputs may have been generated based on prior application of the digital key as input across at least the same portion of the trained machine learning model. Intuitively, if a ML model remains unaltered, then applying the same data across the same portion of the ML model at different times should yield the same output. Thus, in some embodiments, the comparing of block 706 seeks an exact match between the verification output(s) generated at block 704 and the known verification output(s). However, this is not meant to be limiting. In other embodiments, other types of comparisons may be performed. For example, the verification outputs generated at block 704 may be applied as input to a hash function, and the result may be compared to another hash or value used as a proxy for, or generated from, known verification output(s).”;
Examiner’s Note: the RETINAJ-CHAAR-STAPLETON combination now uses the comparison teachings of STAPLETON to verify the transformation mapping to target schema of RETINAJ by comparing transformed files to known files to determine if there is an exact as in STAPLETON)
Before the effective filing date of the present application, it would have been obvious to one of ordinary skill to combine the teachings of RETINAJ with CHAAR and STAPLETON as explained above. As disclosed by STAPLETON, one of ordinary skill would have been motivated to do so in order to verify the integrity of a ML model in order to determine if it has been compromised by an attacker. (para. 0039).
Regarding Claim 3
RETINAJ, CHAAR, and STAPLETON teach the system of claim 2 as explained above. RETINAJ further teaches:
update the generative AI model using the source file model and the transform map. (RETINAJ, para. 0033: “ As described above, the system may use labeled data for training, re-training, and applying its analysis to new (target) data.”;
RETINAJ, para. 0036: “As described below, one example of an ML model used in some embodiments of the system 100 is that of a graph neural network (GNN). In this example, the training logic 112 may progressively train the GNN using different data sets. For example, the GNN may be trained using supervised training data using one or more labeled graph-representations of training schemas. In some embodiments, these supervising training processes may be executed using generic schema training data. In other examples, the training logic 112 may use a “target” database schema (i.e., the schema into which a source database schema is to be translated and/or converted) to train the GNN algorithm.”;
RETINAJ, para. 0089: “In some examples, a user may manually intervene in the process to alter mappings that are generated by the system (e.g., provided via a client device 102). The manual updates may be provided to the GNN or other trained machine learning model to update training data.”)
Regarding Claim 4
RETINAJ, CHAAR, and STAPLETON teach the system of claim 1 as explained above. RETINAJ further teaches:
receive a user input indicating the target file type; (RETINAJ, para. 0027: “The GUI may present an interface by which a user triggers execution of computing transactions, thereby generating and/or analyzing data items. In some examples, the GUI may include features that enable a user to view training data, classify training data, instruct the ML application 104 to map a source database schema to a target database schema, generate graphs corresponding to database schemas, and other features of embodiments described herein.”)
retrieve, from the training base, the target file model corresponding to the target file type, the target file model comprising the target-based graph. (RETINAJ, para. 0036: “ In this example, the training logic 112 may progressively train the GNN using different data sets. For example, the GNN may be trained using supervised training data using one or more labeled graph-representations of training schemas.”;
RETINAJ, para. 0082: “In some examples, this prediction process may additionally or alternatively be applied to the target schema. That is, a GNN may predict graphical context data that includes a predicted set of edges and a predicted set of nodes based on attributes associated with target data entities that are represented by the target graph nodes. The system may then compare the predicted target graph (or portions thereof) to the actual target graph. The system may add nodes, edges, and any corresponding graphical context data to the target graph to generate an updated target graph. The updated target graph (and its associated graphical context data) may then be used in the analysis of the source graph to generate a more accurate mapping between source and target databases.”)
Regarding Claim 7
RETINAJ, CHAAR, and STAPLETON teach the system of claim 1 as explained above. RETINAJ further teaches:
wherein the transform map includes one or more transformations associated with the one or more source nodes and the one or more target nodes, and (RETINAJ, para. 0042: “Once the analogs are identified, the ML engine 110 may generate a mapping so that the source database schema may be translated into the target database schema. The mapping may be stored as a data object or as executable code. Techniques describing these operations are described below in the context of FIGS. 2 and 3.”;
RETINAJ, para. 0087: “In some examples, the mapping may generate a set of rules that, when applied, transforms, converts, or translates source database schema into a target database schema.”)
apply the one or more transformations to the one or more source data items associated with the one or more source nodes to generate one or more output data items; and (RETINAJ, para. 0042: “Once the analogs are identified, the ML engine 110 may generate a mapping so that the source database schema may be translated into the target database schema. The mapping may be stored as a data object or as executable code. Techniques describing these operations are described below in the context of FIGS. 2 and 3.”;
RETINAJ, para. 0087: “In some examples, the mapping may generate a set of rules that, when applied, transforms, converts, or translates source database schema into a target database schema.”)
organize the one or more output data items to generate the output file. (RETINAJ, para. 0020: “The system uses identified correspondences to generate a map that maps elements of the source database schema to a target database schema. This map may be applied to convert data items from one schema to another.”;
RETINAJ, para. 0087: “In some examples, the mapping may generate a set of rules that, when applied, transforms, converts, or translates source database schema into a target database schema. In some examples, the mapping may be stored as a data entity or data object that identifies the correspondence between source data entities and target data entities. In some examples, the mapping may be stored as an executable file that translates or converts source data entities into target data entities.”;
Examiner’s Note: the target schema that is created using the mapping corresponds to the recited “output file”)
Claim 8 recites a method that corresponds to the system of claim 1 and is rejected for the same reasons explained above with respect to claim 1.
Claim 9 depends from claim 8 and recites a method that corresponds to the system of claim 2 and is rejected for the same reasons explained above with respect to claims 2 and 8.
Claim 10 depends from claim 9 and recites a method that corresponds to the system of claim 3 and is rejected for the same reasons explained above with respect to claims 3 and 9.
Claim 11 depends from claim 8 and recites a method that corresponds to the system of claim 4 and is rejected for the same reasons explained above with respect to claims 4 and 8.
Claim 14 depends from claim 8 and recites a method that corresponds to the system of claim 7 and is rejected for the same reasons explained above with respect to claims 7 and 8.
Claim 15 recites a computer readable storage medium that corresponds to the system of claim 1 and is rejected for the same reasons explained above with respect to claim 1.
Claim 16 depends from claim 15 and recites a computer readable storage medium that corresponds to the system of claim 2 and is rejected for the same reasons explained above with respect to claims 2 and 15.
Claim 17 depends from claim 16 and recites a computer readable storage medium that corresponds to the system of claim 3 and is rejected for the same reasons explained above with respect to claims 3 and 16.
Claim 18 depends from claim 15 and recites a computer readable storage medium that corresponds to the system of claim 4 and is rejected for the same reasons explained above with respect to claims 4 and 15.
Claims 5, 12, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over RETINAJ, CHAAR, and STAPLETON, and further in view of US 20210271965 A1, hereinafter referenced as MALYNIN.
Regarding Claim 5
RETINAJ, CHAAR, and STAPLETON teach the system of claim 1 as explained above. RETINAJ further teaches:
wherein the generative AI model includes a plurality of parameters, (RETINAJ, para. 0036: “As described below, one example of an ML model used in some embodiments of the system 100 is that of a graph neural network (GNN).”;
RETINAJ, para. 0040: “ In some examples, training a GNN may occur in stages, first using a generic dataset, whether a publicly available NLP training dataset (e.g., an NLP training dataset, such as those available from commoncrawl or Wikipedia®) or a generically pre-trained model (e.g., OpenAI GPT-3, Google® BERT, Microsoft® CodeBERT, Facebook® RoBERTa).”;
Examiner’s Note: one of ordinary skill would understand that a neural network has 1 or more input layers, 1 or more hidden layers, and 1 or more output layers, where each hidden layer has nodes with weights (corresponding to the recited “plurality of parameters”))
and to train the generative AI model, the computing instructions, when executed by the one or more processors, cause the one or more processors to: input a plurality of sample source files and a plurality of sample source file specifications associated with the sample source files into the generative AI model to generate a plurality of source file models; (RETINAJ, para. 0028: “The ML application 104 of the system 100 may be configured to train one or more ML models using training data, prepare target data before ML analysis, and analyze data so as to map a source database schema to a target database schema, thereby enabling the integration or inter-operation of database schemas.”;
RETINAJ, para. 0064: “The system may generate a graph representing the source database schema using any of a number of techniques. In some examples, a GNN (or other trained machine learning algorithm) may execute the operation 204 by identifying entities of the source database schema using entity identifiers.”;
RETINAJ, para. 0074: “The system may then begin a process of mapping the source schema to the target schema using the corresponding graphs and graphical context data. In some examples, this process may include comparing graphical context data for a selected node in the source graph to graphical context data for a selected node in the target graph (operation 232). The selection and comparison processes are repeated for some or all of the nodes in the source and target graphs to generate a mapping, thereby effectively predicting links between the selected node and other nodes in the target graph”)
However, RETINAJ, CHAAR, and STAPLETON fail to explicitly teach:
determine differences between the plurality of source file models and a plurality sample source file models associated with the sample source files and sample source file specifications; and iteratively update the plurality of parameters based on the differences.
Under the broadest reasonable interpretation, these missing limitations merely relate to the basics of training neural networks using backpropagation. However, because RETINAJ does not go into the specifics about how the GNN is trained, an additional reference is being used to explicitly teach these limitations.
In a related field of endeavor (graph neural networks, see para. 0036), MALYNIN teaches and makes obvious:
determine differences between the plurality of source file models and a plurality sample source file models associated with the sample source files and sample source file specifications; and iteratively update the plurality of parameters based on the differences. (MALYNIN, para. 0047: “Generally, to optimize the results of the function and generate an adjusted set of parameter values that result in an optimized result for the function, function parameter optimizer 134 may generate a loss function for the calculation graph. The loss function, in some embodiments, may be represented as gradient functions associated with each edge connecting nodes in the calculation graph. The loss function generated for the calculation graph neural network may, in some embodiments, be represented as a chain rule expression over connections between individual nodes in the calculation graph neural network. In some embodiments, the loss function may be calculated using a backpropagation operation that computes the gradient of a loss function based on weights in the calculation graph neural network. The backpropagation operation may calculate the gradient of the loss function identified for the output layer of the calculation graph neural network (e.g., the node(s) representing the result of the function in the knowledge graph for which the calculation graph neural network is generated). The backpropagation operation may iterate backwards from the output layer of the calculation graph neural network through other layers of the neural network to calculate gradients of other loss functions associated with other pairings of nodes until the beginning layers of the neural network are reached. The beginning layers may represent, for example, an initial input or set of inputs from which the result of the function is generated.”;
Examiner’s Note: the RETINAJ-CHAAR-STAPLETON-MALYNIN combination now trains the GNN of RETINAJ using a loss function (to calculate differences) and backpropagation to iteratively update and train the GNN as explicitly taught by MALYNIN)
Before the effective filing date of the present application, it would have been obvious to one of ordinary skill to combine the teachings of RETINAJ with CHAAR, STAPLETON, and MALYNIN as explained above. As disclosed by MALYNIN, one of ordinary skill would have been motivated to do so in order to use basic backpropagation techniques with respect to neural networks in order to determine an “optimized result.” (para. 0055).
Claim 12 depends from claim 8 and recites a method that corresponds to the system of claim 5 and is rejected for the same reasons explained above with respect to claims 5 and 8.
Claim 19 depends from claim 15 and recites a computer readable storage medium that corresponds to the system of claim 5 and is rejected for the same reasons explained above with respect to claims 5 and 15.
Claims 6, 13, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over RETINAJ, CHAAR, and STAPLETON, and further in view of US 20230421602 A1, hereinafter referenced as BOYER.
Regarding Claim 6
RETINAJ, CHAAR, and STAPLETON teach the system of claim 1 as explained above. However, RETINAJ, CHAAR, and STAPLETON fail to explicitly teach:
wherein the system further comprises an AI model for comparison, and
invoke the comparison module to use the AI model for comparison to compare the output file to the output sample.
However, in a related field of endeavor (machine learning, see para. 0018), BOYER teaches and makes obvious:
wherein the system further comprises an AI model for comparison, (BOYER, para. 0045: The phishing site detector 100 with its modules and AI models derives key features from a given screenshot of a page under analysis and compares those key features to key features in the same category from the library of logos, texts and/or phrases from known phishing sites, and outputs if there is a calculated substantial close match—indicating a spoofed, for example, Office 365 page etc.”;
Examiner’s Note: BOYER teaches using an AI model to perform comparisons; the RETINAJ-CHAAR-STAPLETON-BOYER combination now modifies RETINAJ to use the comparison logic of STAPLETON, where such comparison logic utilizes an AI model as in BOYER)
invoke the comparison module to use the AI model for comparison to compare the output file to the output sample. (BOYER, para. 0045: The phishing site detector 100 with its modules and AI models derives key features from a given screenshot of a page under analysis and compares those key features to key features in the same category from the library of logos, texts and/or phrases from known phishing sites, and outputs if there is a calculated substantial close match—indicating a spoofed, for example, Office 365 page etc.”;
Examiner’s Note: BOYER teaches using an AI model to perform comparisons; the RETINAJ-CHAAR-STAPLETON-BOYER combination now modifies RETINAJ to use the comparison logic of STAPLETON, where such comparison logic utilizes an AI model as in BOYER)
Before the effective filing date of the present application, it would have been obvious to one of ordinary skill to combine the teachings of RETINAJ with CHAAR, STAPLETON, and BOYER as explained above. As disclosed by BOYER, one of ordinary skill would have been motivated to do so in order to do so because an AI model can be more sensitive to certain kind of errors than conventional comparison techniques. (para. 0042).
Claim 13 depends from claim 8 and recites a method that corresponds to the system of claim 6 and is rejected for the same reasons explained above with respect to claims 6 and 8.
Claim 20 depends from claim 15 and recites a computer readable storage medium that corresponds to the system of claim 6 and is rejected for the same reasons explained above with respect to claims 6 and 15.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 11861335 B1 (Margolin). “An example embodiment includes a method performed by a processor. The method may include capturing training data including JSON objects and corresponding code to transform the JSON objects into a desired data structure, transforming JSON objects into code graphs, transforming code graphs into abstract syntax trees (ASTs), and performing machine learning with pairs of code graphs and corresponding ASTs to determine a function to approximate an AST from a code graph.” (col. 1, lines 32-40).
US 20120095973 A1 (Kehoe). “In some embodiments, the methods and systems include defining a data integration application comprising functional operators to extract, transform, and load data, whereby each input and output operator is configured to specify a physical schema that defines the physical data being read or written, the composite semantic type that defines the standardized semantic model of the data being processed, and a set of mapping rules that define the conversion from the physical data to the semantic data on the input operators and from the semantic data to the physical data on the output operators, and whereby each transform operator between the input and output operators is configured to manipulate data only according to the semantic model.” (para. 0019).
US 20230297577 A1 (Vo). “In converting natural language queries of users to structured database queries that may be understood by computers, specifically database management system, it may be common to use a natural language interface for databases (NLIDB) based on the concept of a rule-based system, which may operate using a semantic model of the database elements that defines relationships between entities.” (para. 0016).
Daniel, Gwendal, et al. "UMLtoGraphDB: mapping conceptual schemas to graph databases." International Conference on Conceptual Modeling. Cham: Springer International Publishing, 2016. “To overcome this situation, we propose the UMLtoGraphDB framework, that translates conceptual schemas expressed using the Unified Modeling Language (UML) [24] into a graph representation, and generates database-level queries from business rules and invariants defined using the Object Constraint Lan guage (OCL) [23]. The framework relies on a new GraphDB metamodel, as an intermediate representation to facilitate the integration of several kinds of graph databases.” (p. 431, section 1).
Guo, Jiaqi, et al. "Towards complex text-to-sql in cross-domain database with intermediate representation." Proceedings of the 57th annual meeting of the association for computational linguistics. 2019. “To eliminate the mismatch, we design a domain specific language, called SemQL, which serves as an intermediate representation between NL and SQL. Figure 2 presents the context-free grammar of SemQL. An illustrative SemQL query is shown in Figure 3. We elaborate on the design of SemQL in the following. Inspired by lambda DCS(Liang, 2013), SemQL is designed to be tree-structured.” (p. 4526, section 2.1).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MICHAEL C LEE whose telephone number is (571)272-4933. The examiner can normally be reached M-F 12:00 pm - 8:00 pm ET.
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, Omar Fernandez Rivas can be reached at 571-272-2589. 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.
/MICHAEL C. LEE/Examiner, Art Unit 2128
Prosecution Insights