DETAILED ACTION
This communication is in response to the Amendments and Arguments filed on 01 July 2026. Claims 1-20 are pending and have been examined. Hence, this action has been made FINAL.
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 .
Response to Arguments
The reply filed on 01 July 2026 has been entered. Applicant’s arguments with respect to claims 1-20 have been considered but are not persuasive/moot in view of new ground(s) of rejection caused by the amendments.
With respect to the applicant’s arguments to claim rejections under 35 U.S.C. § 101, Applicant has amended each of the independent claims and asserts that “the § 101 rejection is moot with respect to the currently amended claims, and Applicant submits that the currently amended independent claims are directed to patent-eligible subject matter and not directed to an abstract idea and specifically a mental process. Even assuming, arguendo, that the claims are directed to an abstract idea, the amendments to the claims integrate any such abstract idea into a practical application.” The examiner respectfully disagrees with these assertions. The applicant asserts that claim rejections under 35 U.S.C. § 101 are moot, but does not explain nor attempt to justify why such amendments overcome claim rejections under 35 U.S.C. § 101. As amended, there is no language in the independent claims that would prevent a human from performing these steps, as addressed in further detail below with respect to claim rejections under 35 USC § 101.
With respect to the applicant’s arguments to claim rejections under 35 U.S.C § 103, the applicant’s arguments with respect to claims 1, 9-10, and 17 have been considered but are moot in view of new ground(s) of rejection caused by the amendments.
Claim Objections
Claims 10 and 17 is objected to because of the following informalities:
Claim 10, line 9, should be “access the concept graph…”
Claim 17, line 15, should be “generating, utilizing [[a]] the large language model to execute the instructions…”
Appropriate correction is required.
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 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. All of the claims are method claims (1-9, 17-20), apparatus/machine claims (10-16) or manufacture claim under (Step 1), but under Step 2A all of these claims recite abstract ideas and specifically mental processes. These mental processes are more particularly recited in claims 1, 10, and 17 as:
generating a concept graph comprising hyper edges linking tables in a database schema to concepts in a predetermined list of concepts…
accessing the concept graph in response to receiving a natural language query for the database schema…
determining one or more indicated concepts from the natural language query…
extracting the set of tables from values in a set of hyper edges corresponding to the one or more indicated concepts from the concept graph…
generating instructions for a large language model comprising the natural language query and the set of tables relevant to the natural language query…
generating, utilizing a large language model to execute instructions, a response for the natural language query from the set of tables relevant to the natural language query…
Under Step 2A Prong One, claims 1, 10, and 17 are directed to an abstract idea and specifically a mental process. As detailed above, the steps of generating, determining, extracting, etc. may be practically performed in the human mind with the use of a physical aid such as a pen and paper. For example, a human could receive a group of relational tables and create a concept graph for the group of tables using a predetermined schema. The human could then receive an instructional query to search for a given concept in the group of tables, access the group of relational tables, refer to their concept graph to extract a set of tables that are relevant to the given concept, and based on the extracted set of tables, summarize what data is available in response to the query.
Under Step 2A Prong Two, this judicial exception is not integrated into a practical application because claims 1-20 do not recite additional elements that integrate the exception into a practical application. In particular, claims 1, 10, and 17 recite the additional elements of a server device (¶ [0034]-[0035]), memory (¶ [0120]), and a large language model (¶ [0032]). These additional elements are recited at a high level of generality and merely equate to “apply it” or otherwise merely uses a generic computer as a tool to perform an abstract which are not indicative of integration into a practical application as per MPEP 2106.05(f). Accordingly, these additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea.
Under Step 2B, the claims do not recite additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to the integration of the abstract idea into a practical application, the additional elements of using a computer is noted as a general computer {server device (¶ [0034]-[0035]); memory (¶ [0120])}. Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept. The claims are not patent eligible.
With respect to claims 2 and 10, the claim relates to generating concepts from table contents. This relates to a human reading each table in the group of tables and comparing the headers to the predetermined schema in order to generate a set of concepts for a hypergraph. No additional limitations are present. The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception.
With respect to claims 3-5 and 12-13, the claim relates to determining tables with shared concept tags and generating a hyperedge based on tables sharing concepts. This relates to a human noticing that two tables share at least two concepts defined by the predetermined schema and drawing a hyperedge to connect two nodes, each node representing a table, based on the fact that the tables share said concepts. No additional limitations are present. The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception.
With respect to claims 6-7, 14-15, and 19, the claim relates to determining relevancy between a natural language query and a set of tables based on matching an indicated concept from the query to the set of tables. This relates to a human extracting concepts from the instructional query, matching those concepts to key-value pairings in the concept graph, and extracting tables from the concept graph based on successful key pairings. No additional limitations are present. The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception.
With respect to claims 8 and 18, the claim relates to identifying concepts in a query. This relates to a human normalizing the instructional query by converting every character to lowercase and removing punctuation, and comparing each word in the query to the predetermined schema in order to find matching lexicon. No additional limitations are present. The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception.
With respect to claims 9, the claim relates to handling failed queries. This relates to a human noticing that an instructional query doesn’t exactly match any records and in response, discard the non-matching tokens from the query and continue thereafter by excluding the non-matching tokens from their table search. No additional limitations are present. The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception.
With respect to claims 16 and 20, the claim relates to generating a prompt for a language model containing a structured query. This relates to a human manager giving the human the instructional query in the form of an SQL query and expecting a summary of the retrieved SQL results from the human. No additional limitations are present. The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception.
For all of the above reasons, taken alone or in combination, claims 1-20 recite a non-statutory mental process.
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-7, 10, 12-14 and 17 are rejected under 35 U.S.C. 103 as obvious over US Patent Publication 20170075891 A1 (Bozkaya et al.) in view of US Patent Publication 20250342191 A1 (Noel et al.) in view of US Patent Publication 20220101151 A1 (Portisch et al.).
Claim 1
Regarding claim 1, Bozkaya et al. disclose a computer-implemented method comprising:
generating, by one or more server devices (Bozkaya et al. ¶ [0205], "Embodiments of the subject matter described in this specification can be implemented in a computing system that includes a back-end component, e.g., as a data server, or that includes a middleware component, e.g., an application server"), concept tags for tables in a database schema based on content of the tables corresponding to concepts in a predetermined list of concepts (Bozkaya et al. ¶ [0031], "the phrase “sales” can be recognized as an n-gram mapping to a “sales_cost_usd” column in a table for a particular schema lexicon. Consequently, an attribute concept is generated as corresponding to the phrase “sales” in the parsed query. Other information may be known from the lexicon, for example, that the phrase is associated with a numeric and aggregatable column. This information can be used when eventually generating corresponding structured queries." A schema lexicon is considered analogous to a predetermined list of concepts) [that limits which concepts are searchable when performing database queries on the tables by determining relationships between the tables and the concepts in the predetermined list of concepts];
generating, by the one or more server devices, a concept graph comprising hyper edges (Bozkaya et al. ¶ [0035], "The system creates 114 a hypergraph from the concept tree and analyses the hypergraph to generate joins.") linking the tables to the concepts according to the concept tags of the tables (Bozkaya et al. ¶ [0035], "A hypergraph represents a database schema where data tables may have multiple join mappings among themselves. ... Two nodes are connected by an edge if the columns represented by the two nodes are joinable; and the edge identifies the tables to which the columns belong. The hypergraph analysis includes path resolution for joins using the concept tree.") [indicating the relationships between the tables and the concepts in the predetermined list of concepts];
accessing, by the one or more server devices, the concept graph in response to receiving a natural language query for the database schema (Bozkaya et al. ¶ [0191], "The disambiguation subsystem 624 disambiguates natural language queries based on join paths stored on nodes of a concept tree." Disambiguating a natural language query based on a concept tree is considered analogous to accessing a concept graph in response to receiving a natural language query); and
determining, by the one or more server devices and from the tables in the database schema, a set of tables relevant to the natural language query comprising an indicated concept (Bozkaya et al. ¶ [0166], "Returning to the example query “what is the total sales for buyers who have their personal address in Nevada?”.... Node 512 corresponds to the unambiguous “sale” attribute of BuyerSeller table. Node 514 and Node 516 are subcontext concept nodes augmented with join lineages. Node 518 is an inverted index match for the State column in the address table.") by extracting the set of tables from one or more hyper edges corresponding to the indicated concept from the concept graph (Bozkaya et al. ¶ [0168]-[0173], "The resulting query is: SELECT SUM(BuyerSeller.sales_usd) AS alias0_sales_usd FROM BuyerSeller INNER JOIN Person ON (BuyerSeller.buyer_id=Person.person_id) INNER JOIN Address ON (Person.personal_address_id=Address.address_id) WHERE Address.state=Nevada." See Fig. 7-8 and the algorithm presented in ¶ [0152]-[0165]. BuyerSeller, Person, and Address are considered analogous to a set of tables from one or more hyperedges found using algorithm cited above).
Bozkaya et al. do not explicitly disclose all of a large language model.
However, Noel et al. disclose determining, by the one or more server devices and from the tables in a database schema, a set of tables relevant to a natural language query comprising an indicated concept (Noel et al. ¶ [0073], "At step 406, a graph database query may be generated based on the one or more node types identified in the natural language user query. The graph database query may be generated by a large language model.") [by extracting the set of tables from one or more hyper edges corresponding to the indicated concept from the concept graph];
generating, by the one or more server devices, instructions for a large language model comprising the natural language query and the set of tables relevant to the natural language query (Noel et al. ¶ [0082], "Step 410 includes receiving results of the graph database query. ... The results may contain the necessary data for responding to the natural language user query." ¶ [0087], "the system may first build a prompt for the large language model. The prompt may include a user-role prompt and a system-role prompt. The user-role prompt may include the natural language user query, and the system-role prompt may include instructions to provide a detailed description of the scenario represented by the results of the graph database query in the context of the application domain." A prompt is considered analogous to instructions for a large language model); and
generating, by the one or more server devices utilizing the large language model to execute the instructions, a response for the natural language query from the set of tables relevant to the natural language query (Noel et al. ¶ [0082]-[0086], "Step 410 includes receiving results of the graph database query. ... The results may contain the necessary data for responding to the natural language user query. ... Step 412 includes generating, using the large language model, a natural language response to the natural language user query based on the results of the graph database query.").
It would have been obvious to a person having ordinary skill in the art before the time of the effective filing date of the claimed invention of the instant application to modify Bozkaya et al.’s concept-based retrieval method to incorporate Noel et al.’s large language model.
The suggestion/motivation for doing so would have been that, “enabling the exchange of information using natural language can help users process information more efficiently than they could if queries and results were provided in graphical terms,” as noted by the Noel et al. disclosure in paragraph [0033].
Bozkaya et al. in view of Noel et al. do not explicitly disclose all of a predetermined list of concepts that limit searchable concepts.
However, Portisch et al. disclose generating, [by one or more server devices,] concept tags for tables in a database schema based on content of the tables corresponding to concepts in a predetermined list of concepts (Portisch et al. ¶ [0131], "the intelligent labeling algorithm described herein can generate and assign a meaningful label corresponding to a column of data in the database table. As described above, such assigned label can be compliant with an existing ontology of a data repository." An existing ontology is considered analogous to a predetermined list of concepts) that limits which concepts are searchable when performing database queries on the tables by determining relationships between the tables and the concepts in the predetermined list of concepts (Portisch et al. ¶ [0123], "As shown, the data repository 850 includes a plurality of database tables (e.g., 852, 854, 856). The data repository 850 also maintains its own ontology 858 and all database tables contains therein are compliant with the ontology 858 so that a software application accessing the data repository can properly utilize the database tables." Ensuring that existing data tables are compliant with the existing database ontology is considered analogous to limiting which concepts are searchable by determining relationships between tables and concepts in a predetermined list of concepts); and
[generating, by the one or more server devices, a concept graph comprising hyper edges] linking the tables to the concepts according to the concept tags of the tables indicating the relationships between the tables and the concepts in the predetermined list of concepts (Portisch et al. ¶ [0131], "the intelligent labeling algorithm described herein can generate and assign a meaningful label corresponding to a column of data in the database table. As described above, such assigned label can be compliant with an existing ontology of a data repository." Generating and assigning ontology-compliant labels to a database table is considered analogous to linking tables to concepts according to concept tags of the tables indicating relationships between said tables and concepts in a predetermined list of concepts)….
It would have been obvious to a person having ordinary skill in the art before the time of the effective filing date of the claimed invention of the instant application to modify Bozkaya et al. in view of Noel et al. to incorporate Portisch et al.’s predetermined list of concepts that limit concept searching by enforcing concept compliance in databases.
The suggestion/motivation for doing so would have been that, “if database tables in the data repository 850 are not compliant with the ontology 858 (for exampling, assuming database tables 852, 854, 856 have different naming conventions), then some database operations (e.g., a data JOIN statement) may not be able to access all relevant data because of inconsistent use of data labels among the database tables,” as noted by the Portisch et al. disclosure in paragraph [0123].
Claim 3
Regarding claim 3, the rejection of claim 1 is incorporated.
Bozkaya et al. further disclose determining a first table and a second table that are tagged with a first concept tag corresponding to a first concept in the predetermined list of concepts and a second concept tag corresponding to a second concept in the predetermined list of concepts (Bozkaya et al. ¶ [0131], "The algorithm for hypergraph creation goes through all of the tables and their attributes based on the schema lexicons and join mappings. It is possible to have very comprehensive lexicon coverage for tables with a large number of attributes." Attributes are considered analogous to concepts/concept tags. A schema lexicon is considered analogous to a predetermined list of concepts); and
generating a hyper edge linking the first table and the second table to the first concept and the second concept (Bozkaya et al. ¶ [0032], "Two nodes are connected by an edge if the columns represented by the two nodes are joinable; and the edge identifies the tables to which the columns belong." ¶ [0048]-[0053], "An example algorithm for generating join paths follows: ... Create a hyperedge for this table “instance” and add it to the hypergraph. Hyperedge(T, T.join_lineage, hypernodes={ }) ... For table T, find all columns that do not appear as a primary key in any join mappings. For each such column T.c, create a hypernode and add it to the hypergraph. Note that we are seeing these attributes for the first time and that is why we create nodes for them." Columns/nodes are considered synonymous with attributes, and are thus considered analogous to concepts).
Claim 4
Regarding claim 4, the rejection of claim 3 is incorporated.
Bozkaya et al. further disclose wherein generating the hyper edge comprises generating a dictionary of key-value mappings in the concept graph comprising the hyper edge as a key with the first table as a first value assigned to the key and the second table as a second value assigned to the key (Bozkaya et al. ¶ [0032], "The hypergraph can include a set of nodes representing columns of data tables stored in a database, as well as a set of edges representing tables to which the columns belong. Two nodes are connected by an edge if the columns represented by the two nodes are joinable; and the edge identifies the tables to which the columns belong." Edge-node pairings are considered analogous to a key-value mappings. The set of edges is considered analogous to keys. The set of nodes representing columns of data tables are considered analogous to values assigned to the key.).
Claim 5
Regarding claim 5, the rejection of claim 4 is incorporated.
Bozkaya et al. further disclose generating the key for the hyper edge as a combination of a plurality of concepts corresponding to the hyper edge (Bozkaya et al. ¶ [0034], "A hyperedge includes: a table name, a join lineage, and a list of hypernodes (by reference or index). A node includes: a table name, an attribute name, and {a join lineage with the attribute name}, which is also called an attribute path." ¶ [0059]-[0061], "After processing (BuyerSeller, “BuyerSeller”): ... New Hyperedges: i. E1(BuyerSeller, “BuyerSeller”, {N1,N2,N3,N4,N5})" Hypernodes N1-N5 contain attribute information for given concepts; see ¶ [0062]-[0067] for examples. Thus, A hyperedge that stores a plurality of hypernodes is considered analogous to generating a key for a hyperedge as a combination of a plurality of concepts corresponding to the hyperedge).
Claim 6
Regarding claim 6, the rejection of claim 4 is incorporated.
Bozkaya et al. further disclose comparing the indicated concept to a plurality of keys in the concept graph to determine that the indicated concept matches the key of the hyper edge (Bozkaya et al. ¶ [0154]-[0156], "For each concept (C) in the concept tree based on a breadth-first traversal: Find the attribute referenced in this concept C. ... Assume this is T.x (attribute x of table T). ... If (HyperedgeCount[T]==1) then it means there is no ambiguity for the attribute reference. We find that hyperedge (H) and set the full attribute path for the attribute reference in concept (C) as H.join_lineage +“x”."); and
extracting, from the concept graph, one or more values assigned to the key indicating one or more tables relevant to the natural language query (Bozkaya et al. ¶ [0168]-[0173], "The resulting query is: SELECT SUM(BuyerSeller.sales_usd) AS alias0_sales_usd FROM BuyerSeller INNER JOIN Person ON (BuyerSeller.buyer_id=Person.person_id) INNER JOIN Address ON (Person.personal_address_id=Address.address_id) WHERE Address.state=Nevada.").
Claim 7
Regarding claim 7, the rejection of claim 5 is incorporated.
Bozkaya et al. further disclose determining that the natural language query includes a plurality of indicated concepts in the predetermined list of concepts (Bozkaya et al. ¶ [0166], "Returning to the example query “what is the total sales for buyers who have their personal address in Nevada?”.... Node 512 corresponds to the unambiguous “sale” attribute of BuyerSeller table. Node 514 and Node 516 are subcontext concept nodes augmented with join lineages. Node 518 is an inverted index match for the State column in the address table.");
determining that the plurality of indicated concepts matches a plurality of keys corresponding to a plurality of hyper edges in the concept graph (Bozkaya et al. ¶ [0154]-[0156], "For each concept (C) in the concept tree based on a breadth-first traversal: Find the attribute referenced in this concept C. ... Assume this is T.x (attribute x of table T). ... If (HyperedgeCount[T]==1) then it means there is no ambiguity for the attribute reference. We find that hyperedge (H) and set the full attribute path for the attribute reference in concept (C) as H.join_lineage +“x”."); and
extracting a plurality of tables from values of the plurality of hyper edges corresponding to the plurality of indicated concepts (Bozkaya et al. ¶ [0168]-[0173], "The resulting query is: SELECT SUM(BuyerSeller.sales_usd) AS alias0_sales_usd FROM BuyerSeller INNER JOIN Person ON (BuyerSeller.buyer_id=Person.person_id) INNER JOIN Address ON (Person.personal_address_id=Address.address_id) WHERE Address.state=Nevada.").
Claim 10
Regarding claim 10, Bozkaya et al. disclose one or more memory devices comprising a database schema (Bozkaya et al. ¶ [0195], " The entity database 634 stores entity information, i.e., information about entities, e.g., dates of birth of people, addresses for businesses, and relationships between multiple organizations. The entity information is stored in the entity database 634 according to a data schema."); and
one or more server devices (Bozkaya et al. ¶ [0205], "Embodiments of the subject matter described in this specification can be implemented in a computing system that includes a back-end component, e.g., as a data server, or that includes a middleware component, e.g., an application server") configured to:
generate a concept graph comprising hyper edges (Bozkaya et al. ¶ [0035], "The system creates 114 a hypergraph from the concept tree and analyses the hypergraph to generate joins.") linking tables in a database schema to concepts in a predetermined list of concepts [that limits which concepts are searchable when performing database queries on the tables] according to concept tags of the tables (Bozkaya et al. ¶ [0035], "A hypergraph represents a database schema where data tables may have multiple join mappings among themselves. ... Two nodes are connected by an edge if the columns represented by the two nodes are joinable; and the edge identifies the tables to which the columns belong. The hypergraph analysis includes path resolution for joins using the concept tree.") based on content of the tables (Bozkaya et al. ¶ [0031], "the phrase “sales” can be recognized as an n-gram mapping to a “sales_cost_usd” column in a table for a particular schema lexicon. Consequently, an attribute concept is generated as corresponding to the phrase “sales” in the parsed query.") [and relationships between the tables and the concepts in the predetermined list of concepts];
access the concept graph in response to receiving a natural language query for the database schema (Bozkaya et al. ¶ [0191], "The disambiguation subsystem 624 disambiguates natural language queries based on join paths stored on nodes of a concept tree." Disambiguating a natural language query based on a concept tree is considered analogous to accessing a concept graph in response to receiving a natural language query); and
determine, from the tables in the database schema, a set of tables relevant to a natural language query comprising a plurality of indicated concepts (Bozkaya et al. ¶ [0166], "Returning to the example query “what is the total sales for buyers who have their personal address in Nevada?”.... Node 512 corresponds to the unambiguous “sale” attribute of BuyerSeller table. Node 514 and Node 516 are subcontext concept nodes augmented with join lineages. Node 518 is an inverted index match for the State column in the address table.") by extracting the set of tables from stored values in a set of hyper edges corresponding to the plurality of indicated concepts from the concept graph (Bozkaya et al. ¶ [0168]-[0173], "The resulting query is: SELECT SUM(BuyerSeller.sales_usd) AS alias0_sales_usd FROM BuyerSeller INNER JOIN Person ON (BuyerSeller.buyer_id=Person.person_id) INNER JOIN Address ON (Person.personal_address_id=Address.address_id) WHERE Address.state=Nevada." See Fig. 7-8 and the algorithm presented in ¶ [0152]-[0165]. BuyerSeller, Person, and Address are considered analogous to a set of tables from one or more hyperedges found using algorithm cited above).
Bozkaya et al. do not explicitly disclose all of a large language model.
However, Noel et al. disclose determining, from the tables in a database schema, a set of tables relevant to a natural language query comprising a plurality of indicated concepts (Noel et al. ¶ [0073], "At step 406, a graph database query may be generated based on the one or more node types identified in the natural language user query. The graph database query may be generated by a large language model.") [by extracting the set of tables from stored values in a set of hyper edges corresponding to the plurality of indicated concepts from the concept graph];
generating instructions for a large language model comprising the natural language query and a set of relevant tables (Noel et al. ¶ [0082], "Step 410 includes receiving results of the graph database query. ... The results may contain the necessary data for responding to the natural language user query." ¶ [0087], "the system may first build a prompt for the large language model. The prompt may include a user-role prompt and a system-role prompt. The user-role prompt may include the natural language user query, and the system-role prompt may include instructions to provide a detailed description of the scenario represented by the results of the graph database query in the context of the application domain." A prompt is considered analogous to instructions for a large language model); and
generating, utilizing the large language model to execute the instructions, a response for the natural language query from the set of tables relevant to the natural language query (Noel et al. ¶ [0082]-[0086], "Step 410 includes receiving results of the graph database query. ... The results may contain the necessary data for responding to the natural language user query. ... Step 412 includes generating, using the large language model, a natural language response to the natural language user query based on the results of the graph database query.").
It would have been obvious to a person having ordinary skill in the art before the time of the effective filing date of the claimed invention of the instant application to modify Bozkaya et al.’s concept-based retrieval method to incorporate Noel et al.’s large language model.
The suggestion/motivation for doing so is similar to the suggestion/motivation described above with respect to claim 1.
Bozkaya et al. in view of Noel et al. do not explicitly disclose all of a predetermined list of concepts that limit searchable concepts.
However, Portisch et al. disclose linking tables in a database schema to concepts in a predetermined list of concepts (Portisch et al. ¶ [0131], "the intelligent labeling algorithm described herein can generate and assign a meaningful label corresponding to a column of data in the database table. As described above, such assigned label can be compliant with an existing ontology of a data repository." Generating and assigning ontology-compliant labels to a database table is considered analogous to linking tables to concepts according to concept tags of the tables indicating relationships between said tables and concepts in a predetermined list of concepts) that limits which concepts are searchable when performing database queries on the tables according to concept tags of the tables based on content of the tables and relationships between the tables and the concepts in the predetermined list of concepts (Portisch et al. ¶ [0123], "As shown, the data repository 850 includes a plurality of database tables (e.g., 852, 854, 856). The data repository 850 also maintains its own ontology 858 and all database tables contains therein are compliant with the ontology 858 so that a software application accessing the data repository can properly utilize the database tables." Ensuring that existing data tables are compliant with the existing database ontology is considered analogous to limiting which concepts are searchable according to concept tags of the tables and their relationships to concepts in a predetermined list of concepts)….
It would have been obvious to a person having ordinary skill in the art before the time of the effective filing date of the claimed invention of the instant application to modify Bozkaya et al. in view of Noel et al. to incorporate Portisch et al.’s predetermined list of concepts that limit concept searching by enforcing concept compliance in databases.
The suggestion/motivation for doing so is similar to the suggestion/motivation described above with respect to claim 1.
Claim 12
Regarding claim 12, the rejection of claim 10 is incorporated. The limitations of claim 12 are similar in scope to that of claim 3 and therefore are rejected for similar reasons as described above.
Claim 13
Regarding claim 13, the rejection of claim 12 is incorporated. The limitations of claim 13 are similar in scope to that of claim 4 and therefore are rejected for similar reasons as described above.
Claim 14
Regarding claim 14, the rejection of claim 10 is incorporated.
Bozkaya et al. further disclose generating a plurality of tokens for a plurality of character strings in the natural language query (Bozkaya et al. ¶ [0028], "For example, after receiving the query “calculate the sales of goods produced in Italy” a natural language system may generate the following three tokens: “sales,” “Italy,” and “produced.”" Each word in the above query is considered analogous to a character string);
comparing the plurality of tokens to the predetermined list of concepts to determine that the natural language query includes the plurality of indicated concepts (Bozkaya et al. ¶ [0028], " Tokens determined by the natural language system to match schema lexicons are recognized as concepts.") based on a subset of tokens in the natural language query that match a subset of concepts in the predetermined list of concepts (Bozkaya et al. ¶ [0028], "For example, the system may recognize the “sales” as a concept referring to the “sales_usd” column of the table 102 shown in FIG. 1; the concept “Italy,” as an inverted index match for a country name; and the concept “produced” as an n-gram included in subcontext 204 shown in FIG. 2; and therefore the system identifies the query as including three concepts."); and
determining the set of tables relevant to the natural language query utilizing the subset of tokens in the natural language query (Bozkaya et al. ¶ [0189], "The NL query processing system 620 processes natural language queries, e.g., plain English queries, received from user devices 610 into structured operations e.g., SQL queries, executes these operations on the API of the knowledge base 630 to produce queries results, and returns the query results to the user devices 610.").
Claim 17
Regarding claim 17, Bozkaya et al. disclose a computer-implemented method comprising:
generating a concept graph comprising hyper edges (Bozkaya et al. ¶ [0035], "The system creates 114 a hypergraph from the concept tree and analyses the hypergraph to generate joins.") linking tables in a database schema to concepts in a predetermined list of concepts (Bozkaya et al. ¶ [0035], "A hypergraph represents a database schema where data tables may have multiple join mappings among themselves. ... Two nodes are connected by an edge if the columns represented by the two nodes are joinable; and the edge identifies the tables to which the columns belong. The hypergraph analysis includes path resolution for joins using the concept tree.") [that limits which concepts are searchable when performing database queries on the tables by determining relationships between the tables and the concepts in the predetermined list of concepts];
accessing the concept graph in response to receiving a natural language query for the database schema (Bozkaya et al. ¶ [0191], "The disambiguation subsystem 624 disambiguates natural language queries based on join paths stored on nodes of a concept tree." Disambiguating a natural language query based on a concept tree is considered analogous to accessing a concept graph in response to receiving a natural language query); and
determining, from the tables in the database schema, a set of tables relevant to a natural language query by:
determining one or more indicated concepts from the natural language query (Bozkaya et al. ¶ [0166], "Returning to the example query “what is the total sales for buyers who have their personal address in Nevada?”.... Node 512 corresponds to the unambiguous “sale” attribute of BuyerSeller table. Node 514 and Node 516 are subcontext concept nodes augmented with join lineages. Node 518 is an inverted index match for the State column in the address table."); and
extracting the set of tables from values in a set of hyper edges corresponding to the one or more indicated concepts from the concept graph (Bozkaya et al. ¶ [0168]-[0173], "The resulting query is: SELECT SUM(BuyerSeller.sales_usd) AS alias0_sales_usd FROM BuyerSeller INNER JOIN Person ON (BuyerSeller.buyer_id=Person.person_id) INNER JOIN Address ON (Person.personal_address_id=Address.address_id) WHERE Address.state=Nevada." See Fig. 7-8 and the algorithm presented in ¶ [0152]-[0165]. BuyerSeller, Person, and Address are considered analogous to a set of tables from one or more hyperedges found using algorithm cited above).
Bozkaya et al. do not explicitly disclose all of a large language model.
However, Noel et al. disclose determining one or more indicated concepts from the natural language query (Noel et al. ¶ [0073], "At step 406, a graph database query may be generated based on the one or more node types identified in the natural language user query. The graph database query may be generated by a large language model.");
generating instructions for a large language model comprising the natural language query and the set of tables relevant to the natural language query (Noel et al. ¶ [0082], "Step 410 includes receiving results of the graph database query. ... The results may contain the necessary data for responding to the natural language user query." ¶ [0087], "the system may first build a prompt for the large language model. The prompt may include a user-role prompt and a system-role prompt. The user-role prompt may include the natural language user query, and the system-role prompt may include instructions to provide a detailed description of the scenario represented by the results of the graph database query in the context of the application domain." A prompt is considered analogous to instructions for a large language model); and
generating, utilizing the large language model to execute the instructions, a response for the natural language query from the set of tables relevant to the natural language query (Noel et al. ¶ [0082]-[0086], "Step 410 includes receiving results of the graph database query. ... The results may contain the necessary data for responding to the natural language user query. ... Step 412 includes generating, using the large language model, a natural language response to the natural language user query based on the results of the graph database query.").
It would have been obvious to a person having ordinary skill in the art before the time of the effective filing date of the claimed invention of the instant application to modify Bozkaya et al.’s concept-based retrieval method to incorporate Noel et al.’s large language model.
The suggestion/motivation for doing so is similar to the suggestion/motivation described above with respect to claim 1.
Bozkaya et al. in view of Noel et al. do not explicitly disclose all of a predetermined list of concepts that limit searchable concepts.
However, Portisch et al. disclose linking tables in a database schema to concepts in a predetermined list of concepts (Portisch et al. ¶ [0131], "the intelligent labeling algorithm described herein can generate and assign a meaningful label corresponding to a column of data in the database table. As described above, such assigned label can be compliant with an existing ontology of a data repository." An existing ontology is considered analogous to a predetermined list of concepts) that limits which concepts are searchable when performing database queries on the tables by determining relationships between the tables and the concepts in the predetermined list of concepts (Portisch et al. ¶ [0123], "As shown, the data repository 850 includes a plurality of database tables (e.g., 852, 854, 856). The data repository 850 also maintains its own ontology 858 and all database tables contains therein are compliant with the ontology 858 so that a software application accessing the data repository can properly utilize the database tables." Ensuring that existing data tables are compliant with the existing database ontology is considered analogous to limiting which concepts are searchable by determining relationships between tables and concepts in a predetermined list of concepts)….
It would have been obvious to a person having ordinary skill in the art before the time of the effective filing date of the claimed invention of the instant application to modify Bozkaya et al. in view of Noel et al. to incorporate Portisch et al.’s predetermined list of concepts that limit concept searching by enforcing concept compliance in databases.
The suggestion/motivation for doing so is similar to the suggestion/motivation described above with respect to claim 1.
Claims 2 and 11 are rejected under 35 U.S.C. 103 as obvious over Bozkaya et al. in view of Noel et al. in view of Portisch et al. as applied to claims 1 and 10 above, and further in view of “Data-Driven Domain Discovery for Structured Datasets” (Ota et al.).
Claim 2
Regarding claim 2, the rejection of claim 1 is incorporated. Bozkaya et al. in view of Noel et al. disclose all the elements of the claimed invention as stated above.
Bozkaya et al. in view of Noel et al. in view of Portisch et al. do not explicitly disclose all of extracting concept tags from tables.
However, Ota et al. disclose extracting one or more concepts from content of a table in the database schema (Ota et al. pg. 955, Section 1, Paragraph 14, "The domain discovery component works in two stages. In the first stage, it derives from each column a set of domain candidates, called local domains. Local domains are clusters of terms in an (expanded) column that are likely to belong to the same type."); and
generating one or more concept tags for the table in response to determining that the one or more concepts extracted from the content of the table matches one or more concepts (Ota et al. pg. 961, Section 5.1, Paragraph 2, "We compared D4 and C4 for domain discovery, and evaluated the resulting clusters using the setup of [14]: for each GTD and each cluster that overlaps with the GTD, we compute precision, recall and F-score; then, for each GTD, we select the cluster with the highest F-score.") in the predetermined list of concepts (Ota et al. pg. 962, Section 5.2, Paragraph 1, "For a given set of seed terms, the goal is to identify a set of local domains that together represent a domain of interest with respect to the seed.").
It would have been obvious to a person having ordinary skill in the art before the time of the effective filing date of the claimed invention of the instant application to modify Bozkaya et al. in view of Noel et al. in view of Portisch et al. to incorporate Ota et al.’s table-based concept tagging.
The suggestion/motivation for doing so would have been that, “given a collection of tables, we aim to identify sets of terms that represent instances of a semantic concept or domain. Knowledge of attribute domains not only enables a richer set of queries over dataset collections, but it can also help in data integration,” as noted by Ota et al. in the abstract.
Claim 11
Regarding claim 11, the rejection of claim 10 is incorporated.
Bozkaya et al. in view of Noel et al. in view of Portisch et al. do not explicitly disclose all of extracting concept tags from tables.
However, Ota et al. disclose determining relationships between the tables in the database schema and the concepts (Ota et al. pg. 955, Section 1, Paragraph 14, "The domain discovery component works in two stages. In the first stage, it derives from each column a set of domain candidates, called local domains. Local domains are clusters of terms in an (expanded) column that are likely to belong to the same type.") in the predetermined list of concepts (Ota et al. pg. 962, Section 5.2, Paragraph 1, "For a given set of seed terms, the goal is to identify a set of local domains that together represent a domain of interest with respect to the seed.") based on content of the tables (Ota et al. pg. 955, Section 1, Paragraph 14, see above); and
generating concept tags for the tables according to the relationships between the tables and the concepts in the predetermined list of concepts (Ota et al. pg. 961, Section 5.1, Paragraph 2, "We compared D4 and C4 for domain discovery, and evaluated the resulting clusters using the setup of [14]: for each GTD and each cluster that overlaps with the GTD, we compute precision, recall and F-score; then, for each GTD, we select the cluster with the highest F-score.").
It would have been obvious to a person having ordinary skill in the art before the time of the effective filing date of the claimed invention of the instant application to modify Bozkaya et al. in view of Noel et al. in view of Portisch et al. to incorporate Ota et al.’s table-based concept tagging.
The suggestion/motivation for doing so is similar to the suggestion/motivation described above with respect to claim 2.
Claims 8, 15, and 18-19 are rejected under 35 U.S.C. 103 as obvious over Bozkaya et al. in view of Noel et al. in view of Portisch et al. as applied to claims 1 and 10 above, and further in view of US Patent Publication 20130041921 A1 (Cooper et al.).
Claim 8
Regarding claim 8, the rejection of claim 1 is incorporated.
Bozkaya et al. in view of Noel et al. in view of Portisch et al. do not explicitly disclose all of normalizing tokens.
However, Cooper et al. disclose generating one or more normalized tokens for one or more character strings in the natural language query (Cooper et al. ¶ [0030]-[0032], "In query mode, language analysis module 110 is configured to receive at least one query and to format natural language-based queries into elements and/or annotations for satisfying language rule conditions. ... elementizer 150 forms elements through known tokenization processes that form "tokens" as the elemental units of text corresponding to one or more words in a text stream. ... Canonical annotator 154 provides an element to canonical module ("CM") 152, which processes that element and returns its canonical form. For example, if element "swimming" is generated by elementizer 150 and passed to canonical annotator 154, then CM 152 will be expected to return the base word, or stem, "swim.""); and
comparing the one or more normalized tokens to the predetermined list of concepts to determine that the natural language query includes the indicated concept (Cooper et al. ¶ [0032], "a concept annotator 156 ... matches a generated element against ontology-based concepts stored in multi-layered concept repository 134. For example, if element "cat" is generated by elementizer 150 and passed to concept annotator 156, then multi-layered concept repository 134 might be expected to return the concept <noun.animal.cat>. Such a concept annotation could be used by System 100 to link the element "cat" to a higher-layered concept (e.g. a genus term), such as "animal."").
It would have been obvious to a person having ordinary skill in the art before the time of the effective filing date of the claimed invention of the instant application to modify Bozkaya et al. in view of Noel et al. in view of Portisch et al. to incorporate Cooper et al.’s normalized tokens because such a modification is the result of combining prior art elements according to known methods to yield predictable results. More specifically, Bozkaya et al.’s concept matching as modified by Cooper et al.’s normalized tokenization can yield a predictable result of improving performance since normalizing tokens into identical forms allow concept matching to become quicker and more efficient. Thus, a person of ordinary skill would have appreciated including in Bozkaya et al.’s concept matching the ability to do Cooper et al.’s normalized tokenization since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
Claim 15
Regarding claim 15, the rejection of claim 14 is incorporated.
Bozkaya et al. further disclose determining that one or more [combinations of tokens] of the subset of tokens in the natural language query matches a key in the concept graph (Bozkaya et al. ¶ [0154]-[0156], "For each concept (C) in the concept tree based on a breadth-first traversal: Find the attribute referenced in this concept C. ... Assume this is T.x (attribute x of table T). ... If (HyperedgeCount[T]==1) then it means there is no ambiguity for the attribute reference. We find that hyperedge (H) and set the full attribute path for the attribute reference in concept (C) as H.join_lineage +“x”." A hyperedge is considered a key in a hypergraph); and
extracting one or more values indicating the set of tables relevant to the natural language query from one or more key-value mappings corresponding to the key in the concept graph (Bozkaya et al. ¶ [0168]-[0173], "The resulting query is: SELECT SUM(BuyerSeller.sales_usd) AS alias0_sales_usd FROM BuyerSeller INNER JOIN Person ON (BuyerSeller.buyer_id=Person.person_id) INNER JOIN Address ON (Person.personal_address_id=Address.address_id) WHERE Address.state=Nevada.").
Bozkaya et al. in view of Noel et al. in view of Portisch et al. do not explicitly disclose all of combining subsets of tokens.
However, Cooper et al. disclose determining that one or more combinations of tokens of the subset of tokens (Cooper et al. ¶ [0039], "<concept> 200 can be defined as a compositional phrase 230, which is a set of concepts 232. ... For example, the concept 200 "<financial_institution>" is defined as compositional phrase 230 and is defined by the set of concepts {<finance>, <institution>}.") in the natural language query matches a key (Cooper et al. ¶ [0030], "In query mode, language analysis module 110 is configured to receive at least one query and to format natural language-based queries into elements and/or annotations for satisfying language rule conditions.").
It would have been obvious to a person having ordinary skill in the art before the time of the effective filing date of the claimed invention of the instant application to modify Bozkaya et al. in view of Noel et al. in view of Portisch et al. to incorporate Cooper et al.’s token combination because such a modification is the result of combining prior art elements according to known methods to yield predictable results. More specifically, Bozkaya et al.’s concept matching as modified by Cooper et al.’s token combination can yield a predictable result of improving flexibility since more complex concept types can be inferred from both database tables and the natural language query. Thus, a person of ordinary skill would have appreciated including in Bozkaya et al.’s concept matching the ability to do Cooper et al.’s token combination since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
Claim 18
Regarding claim 18, the rejection of claim 17 is incorporated. The limitations of claim 18 are similar in scope to that of claim 8 and therefore are rejected for similar reasons as described above.
Claim 19
Regarding claim 19, the rejection of claim 18 is incorporated. The limitations of claim 19 are similar in scope to that of claim 15 and therefore are rejected for similar reasons as described above.
Claim 9 is rejected under 35 U.S.C. 103 as obvious over Bozkaya et al. in view of Noel et al. in view of Portisch et al. as applied to claim 7 above, and further in view of US Patent Publication 20170075953 A1 (Bozkaya et al. 2).
Claim 9
Regarding claim 9, the rejection of claim 7 is incorporated.
Portisch et al. further disclose determining that one or more tokens are not in the predetermined list of concepts (Portisch et al. ¶ [0122]-[0126], "FIG. 8 shows a diagram illustrating an example method of importing a database table 810 into a data repository 850 ... To ensure ontology compliance when importing the database table 810 into the data repository 850, the labels 812 can be compared with labels contained in the ontology dictionary 840. As shown in this example, by looking up the ontology dictionary 840, it can be found that the label “Company” defined in ontology 832 has an equivalent label “Biz_Name” defined in ontology 858, whereas the two other labels “Business” and “Corporation” have no corresponding equivalent labels"); and
discarding the one or more tokens (Portisch et al. ¶ [0126], "by looking up the ontology dictionary 840, it can be found that ... the two other labels “Business” and “Corporation” have no corresponding equivalent labels and can be removed." Removing labels is considered analogous to discarding tokens).
Bozkaya et al. in view of Noel et al. in view of Portisch et al. do not explicitly disclose all of further processing beyond a failed match.
However, Bozkaya et al. 2 disclose determining that a combined set of tokens from the natural language query does not match keys in the concept graph (Bozkaya et al. 2 ¶ [0092], "During hypergraph analysis, the system may determine that it is unable to uniquely identify a column reference. The system may be able to perform a partial matching to join paths to determine which join step is missing.");
determining a subset of tokens of the combined set of tokens from the natural language query (Bozkaya et al. 2 ¶ [0061]-[0063], "In response to a determination that an error is triggered by the parsed query, error branch, the system determines 308 whether there is an alternative parse ... In response to a determination that there is no alternative parse available, the system selects a best available parse 310.") by:
determining that one or more tokens are not in the predetermined list of concepts (Bozkaya et al. 2 ¶ [0099]-[0100], "The system monitors for noun phrases that are not matched to any lexicons, e.g., attributes, subcontexts, etc. ... For example, the system can recognize either “personal address” or “business address” phrases but the user only includes the phrase “address” in the query. The system will ... propagate a message to the user saying that the phrase “address” is not matched to any phrases that the system recognizes."); and
[discarding the one or more tokens; and]
selecting one or more tables relevant to the natural language query in response to determining that the subset of tokens matches a key in the concept graph (Bozkaya et al. 2 ¶ [0065], "A best parse is a parse that may have warnings, but does not have any errors. If such a best parse if found, the system generates 314 a structured query. The analysis of the parsed query, or parsed alternative queries, includes the generation of a transformed concept tree, which can then be used to generate the structured query." A structured query is considered analogous to selecting one or more tables).
It would have been obvious to a person having ordinary skill in the art before the time of the effective filing date of the claimed invention of the instant application to modify Bozkaya et al. in view of Noel et al. in view of Portisch et al. to incorporate Bozkaya et al. 2’s failure handling.
The suggestion/motivation for doing so would have been that, “linguistic ambiguities detected in a user-provided natural language query can be resolved as they arise, eliminating the need to produce search results based on each alternative interpretation,” as noted by the Bozkaya et al. 2 disclosure in paragraph [0008].
Claims 16 and 20 are rejected under 35 U.S.C. 103 as obvious over Bozkaya et al. in view of Noel et al. in view of Portisch et al. as applied to claims 10 and 17 above, and further in view of “Querying Large Language Models with SQL” (Saeed et al.).
Claim 16
Regarding claim 16, the rejection of claim 10 is incorporated.
Noel et al. further disclose wherein the one or more server devices are further configured to generate the response for the natural language query by generating, [for] by the large language model, a prompt comprising a structured database query for the natural language query indicating the set of tables relevant to the natural language query (Noel et al. ¶ [0027], "The query resolution system can process the natural language user query to identify one or more node types of a type graph that are present in the natural language user query. ... Once the node types in the natural language user query are identified, an analytic orchestrator component of the query resolution system can build a prompt for a large language model ... to generate a graph database query based on the identified node types. The analytic orchestrator may then query a graph database using the graph database query generated by the large language model and receive the results of the graph database query.").
Bozkaya et al. in view of Noel et al. in view of Portisch et al. do not explicitly disclose all of inputting a structured database query into a large language model.
However, Saeed et al. disclose generating, for the large language model, a prompt comprising a structured database query (Saeed et al. pg. 1 , Section 1, Paragraph 4, “We envision querying pre-trained LLMs with SQL scripts. As depicted in example (1) in Figure 1, the pre-trained LLM can act as the data storage containing the information to answer the query.” See Figure 1)
It would have been obvious to a person having ordinary skill in the art before the time of the effective filing date of the claimed invention of the instant application to modify Bozkaya et al. in view of Noel et al. in view of Portisch et al. to incorporate Saeed et al.’s SQL input.
The suggestion/motivation for doing so would have been that, “when we look at [LLMs] from a DB perspective, they (i) have extensive coverage of facts from massive textual sources; [and] (ii) have perfect availability,” as noted by Saeed et al. in pg. 3, Section 3, Paragraph 1.
Claim 20
Regarding claim 20, the rejection of claim 17 is incorporated.
Noel et al. further disclose generating a prompt comprising [a structure database query indicating the set of tables and] the set of tables relevant to the natural language query (Noel et al. ¶ [0073], "At step 406, a graph database query may be generated based on the one or more node types identified in the natural language user query. The graph database query may be generated by a large language model.").
Bozkaya et al. in view of Noel et al. in view of Portisch et al. do not explicitly disclose all of generating a prompt for a large language model comprising a structured database query.
However, Saeed et al. disclose generating a prompt comprising a structure database query (Saeed et al. pg. 1 , Figure 1 illustrates querying an LLM using an SQL query) indicating a set of tables (Saeed et al. pg. 1 , Figure 1’s SQL query indicates selecting fields from tables c and cm. See Figure 3 for a more in-depth example for how SQL queries interact with database fields) [and the set of tables relevant to the natural language query]; and
providing the prompt to the large language model to generate the response (Saeed et al. pg. 1, Figure 1 illustrates an LLM returning a formatted table).
It would have been obvious to a person having ordinary skill in the art before the time of the effective filing date of the claimed invention of the instant application to modify Bozkaya et al. in view of Noel et al. to incorporate Saeed et al.’s SQL input.
The suggestion/motivation for doing so is similar to the suggestion/motivation described above with respect to claim 16.
Reference Cited
The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure.
US Patent Publication 20140143284 A1 to McCaffrey discloses generating and updating database schema based on metadata defining persistent classes and members associated with said persistent classes.
“A Survey on Hypergraph Neural Networks: An In-Depth and Step-by-Step Guide” to Kim et al. discloses a variety of use-cases for hypergraphs in prior art, including hypergraph classification, modeling, and mining.
“A Nonlinear Diffusion Method for Semi-Supervised Learning on Hypergraphs” to Prokopchik et al. discloses a hypergraph learning method that comprises assigning labels to nodes within a hypergraph, given a predetermined set of labels.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JACOB B VOGT whose telephone number is (571)272-7028. The examiner can normally be reached Monday - Friday, 11am - 8pm EST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, PARAS D SHAH can be reached at (571)270-1650. 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.
/JACOB B VOGT/Examiner, Art Unit 2653
/Paras D Shah/Supervisory Patent Examiner, Art Unit 2653
09/16/2026
