DETAILED ACTION
This is in response to the application filed on 06/06/2023.
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claims 1-20 have been examined and are pending.
Specification
The lengthy specification has not been checked to the extent necessary to determine the presence of all possible minor errors. Applicant’s cooperation is requested in correcting any errors of which applicant may become aware in the specification.
Claim Objections
Claims 7-9 are objected to because of the following informalities:
Independent claim 7 recites the limitations “…, and program instructions collectively stored on the one or more computer readable storage medium, the program instructions executable by a processor to cause the processor to perform operations comprising: …”. Dependent claim 8 recites the limitations “…wherein the stored program instructions are stored in a computer readable storage device in a data processing system, and wherein the stored program instructions are transferred over a network…”. Dependent claim 9 recites the limitations “…wherein the stored program instructions are stored in a computer readable storage device in a server data processing system, and wherein the stored program instructions are downloaded in response to a request over a network to a remote data processing system for use in a computer readable storage device associated with the remote data processing system, further comprising: program instructions to meter use of the program instructions associated with the request; and program instructions to generate an invoice based on the metered use.”
The examiner notes that the difference in scope of the claim elements ‘the stored program instructions’ in claims 7-9, ‘the program instructions’ in claim 7 and 9, and ‘program instructions’ in claim 9 is not clear, and requests applicant to clarify their scope and/or amend the claim language as necessary to maintain consistent antecedent basis and clarify scope.
Appropriate correction is required.
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-5, 7-8, 10-13, and 15-19 are rejected under 35 U.S.C. 103 as being unpatentable over Rahmfeld (US 2021/0390096A1 A1) in view of Jaganmohan (US 10943072 B1).
Regarding claim 1,
Rahmfeld teaches A computer-implemented method comprising: extracting, from a natural language input, a functionality intent, the functionality intent comprising an operation on a dataset; generating a portion of source code implementing the functionality intent; and *see paras15-19, 20-23(“ …data conversation system may include a translation module that contains a natural language (NL) interface...translation module may enable a user to build one or more data exploration and/or analysis flows, where a data exploration and/or analysis flow may use previous utterances and their corresponding results as context for new utterances. The translation module may convert received natural language utterances to one or more executable structured query language… structured query language (e.g., SQL) statement may be executed against one or more datasets stored by one or more data storage platforms…translation module may…translate the one or more utterances of a data conversation into one or more structured query language (e.g., SQL) statements…action identification component may compare the language included in a received utterance to one or more predefined keywords to determine whether the received utterance is directed to the underlying schema (e.g., tables and columns from a database stored on the data source medium) or referenced result set table(s) and column(s) from previous step(s) of the current data conversation [extracting from natural language input… functionality intent]. Translating utterances directed at the latter table and column references may be implemented using Common Table Expressions which are available in many database systems…NL translation component may translate utterances expressed in natural language and data conversation context into one or more intermediate structured query language statements…intermediate structured query language statements may be constructed so as to: (i) largely be structured query language dialect agnostic, (ii) compactly represent existing standard SQL statements (e.g., ‘SELECT’, ‘COUNT’) and (iii) encode system-specific actions that capture a higher-level user intent (e.g., operations on or querying of one or more previous result sets in the data conversation) [functionality intent comprising operation on dataset]…post-processing component may convert the intermediate structured query language statements to one or more executable structured query language statements [source code]. The executable structured query language statements may interface with a specific database schema either directly and/or through dataset(s) that were returned by previous user utterances in the data conversation…” teaches generating portion of source code implementing functionality intent), paras28-33(“...user may input an utterance at the user interface…utterance or query may be directed at data accessible by the data conversation system 101 (e.g., at data store(s) 150)…translation module 130 may execute pre-processing of the utterance submitted in the present step 111 c at a pre-processing layer 132…132 may determine whether the utterance includes one or more references to any steps 111 included in the data conversation…132 may remove one or more unnecessary tokens (e.g., words) from the utterance and/or identify higher-level actions indicated by keyword(s) in the utterance [extracting from natural language input…functionality intent]…action identification layer 134 may determine the schema (e.g., included in data store(s) 150) and/or the result set(s) from previous steps (…) on which to operate, query, and/or use [functionality intent comprising operation on dataset]…translation module 130 may translate and/or otherwise convert the processed utterance (…), keyword(s) (…), and effective schema (…) to an intermediate SQL-like statement having characteristics as described herein…translation module 130 may generate an executable query (e.g., SQL statement(s)) based on the intermediate SQL-like statement (e.g., from the translation layer 136) and generate feedback for communication (e.g., display) by a virtual assistant 140. The post-processing layer 138 may convert the intermediate SQL-like statement to an executable query (e.g., SQL statement)…138 may include operations involving derivation and insertion of From/Join and/or Group-By expressions in the executable SQL statement [generating portion of source code implementing functionality intent]…To generate the executable query (e.g., SQL statement), the translation module 130 may assemble a structured query language statement using previous structured query language statement(s)…system 101 may display the generated query (e.g., SQL statement) 160 at the user interface…data conversation system 101 may execute the query (e.g., SQL statement) 160 provided by the post-processing layer 138 against the encoded schema (e.g., at the data store(s) 150)...”)
recommending, using a result of executing an executable version of the portion of source code on the dataset, a next functionality intent, ... *see paras15-19(“… data conversation may contain a series of one or more data conversation steps that operate within a conversational context. A data conversation step may contain one or more utterances (i.e., natural language queries) and/or one more structured query language (e.g., SQL) queries directed at one or more datasets. If a data conversation step starts with an utterance (versus a structured query language query), then the utterance is first translated by the data conversation system into a structured query language query. The (translated or directly submitted) structured query language query is executed against the targeted one or more data sets which produces a data result set and metadata for a given data conversation step…enable a user to build complex data analyses using a modular approach that allows for new utterances to leverage previous conversation steps (including utterances and result sets) of a data conversation. Users may derive insights from a number of data sources through data conversations with their dataset(s), facilitated by the data conversation system's data visualization capabilities for data result sets and feedback and recommendations of a virtual assistant. The present system may provide feedback and recommendations regarding a specific utterance, SQL query, and/or result set within a data conversation (e.g., via a virtual assistant) [recommending next functionality intent, using result of executing code/queries on dataset, under BRI of claim elements]. For example, feedback can allow a user to understand whether their utterance was interpreted as intended and/or facilitate the user in providing another utterance.”), paras78-83(“…should the group classifier 264 predict that the correct token has a 75% chance to be a token referring to a column and the classifier for the column selection would predict that within the columns the third column has a chance of 80% to be the correct one, then the overall likelihood that the 3rd column is the correct next SQL output token is” teaches recommending next functionality intent, based on executing code/queries on dataset, under BRI of elements)
However, Rahmfeld does not expressly teach ‘…recommending, using a result of executing an executable version of the portion of source code on the dataset, a next functionality intent, the next functionality intent expressed in natural language form.'
Jaganmohan teaches …recommending, using a result of executing an executable version of the portion of source code on the dataset, a next functionality intent, the next functionality intent expressed in natural language form. *see cols12-13(“FIG. 3…conversational AI insight and action system or platform 140 for user context and intent-based natural language processing [functionality intent expressed in natural language] and data insight generation …Structured Query Language (SQL), Python, or other analytical languages may be used to query structured data within relational databases…Based on structured data profiling results and extracted raw textual data 342 from any unstructured data, one or more knowledge graphs 374 may be constructed. A knowledge graph is a data entity relationship graph made of vertices connected by edges…may also include entity nodes that represent transactional data, quantitative metrics, or analytical languages that can be run and applied upon structured data associated with connected entity nodes…an analytical function z=ƒ(x, y) may be represented by a node that is connected to two input entities x and y, and one output entity z, while SQL instructions for running such an analytical function ƒ may be provided [executable version…source code]”), cols14-15(“…semantic meaning of the given user request may be compared to one or more knowledge graphs 374 to find matching entities nodes and entity relationships, taking into account similarities in terminologies as given by word embeddings 372. For example, in the conversation shown in FIG. 2B, with the first question “revenue for this year?” the system may establish the context as {revenue, this year}, and a user attribute of {group: sales manager, security level: access right to company-wide data}. When the second question “gross profit margin?” is asked by the user, the system may extract the semantic meaning as {gross, profit, margin}, and this semantic meaning compared to entities in a knowledge graph 374, under the assumption that the user is asking for the gross profit margin for this year and the user has access to company-wide data...Depending on the content of unstructured data 301 and structured data 302 used to build the knowledge graph, an exact match may or may not be found. For example, entity nodes may exist for yearly gross profits and an analytical function for computing profit margins, and a sequence of analytical instructions such as SQL commands may be generated based on these entity nodes and relationship between these nodes, such that when the analytical instructions are applied to company sales data from database 314, gross profit margin for this year can be computed [executable version…source code on dataset, under BRI of claim elements]…knowledge graph may contain entity nodes for gross sales instead of gross profits, and word embeddings 372 may be utilized in the matching process to help determine that the desired gross profit margin can be computed based on gross sales and some other entity nodes, given profit and sales are similar in meaning…if the system determines that no matching entity nodes and relationships can be found, the system may interact further with the user by providing one or more questions, prompts or options to the user to answer or select from [it is understood that prompts/options are based on result of execution of code as described above]. Exemplary questions may be in the form of “did you mean this” where the user has the options to say or choose yes or no, “did you mean A, or B, or C” where the user has the options to choose one of the three options given [recommending, using result of executing…source code…next functionality intent…expressed in natural language form, under BRI of claim elements], or “which years of data do you want to see over 1980 to present” etc… direction questions or multiple choice questions given by the system may both be viewed as a plurality of options, explicit or implicit, for the user to choose from. The process flow shown in FIG. 3 thus returns from the knowledge base back to obtain new user interaction data 316, and such data are again processed through step 348, with additional matchings performed based on the new data…”), cols20-21(“FIG. 11…generate context-based data insight responses to user requests…request is analyzed to extract semantic information or meaning…textual content of the request may be parsed, tokenized and tagged with POS data…plurality of candidate semantic meanings are constructed from the tokenized user request; and one of the plurality of candidate semantic meanings may be selected based on a knowledge graph and a word embedding as a true semantic meaning of the user request [functionality intent]… user attribute and context data are determined, from the user request itself, and/or based on previous user interaction data…Based on tokens tagged with POS data, data entities and/or entity attributes associated with the user request may be identified at a next step 1108 by data extractor 1018 in FIG. 10. Recall such data entities and/or attributes may represent the semantic meaning of the user request. At step 1110, it is determined whether matching data pertinent to the user request, or the semantic meaning of the user request, can be identified from word embeddings 442 and knowledge graphs 444 in FIG. 4. If matching data (e.g., entities and entity relationships on the knowledge graphs) are identified, a response is generated at step 1112 and conveyed to the user at step 1114 via one or more of interaction interfaces 552 [recommending next functionality intent, under BRI of elements]…user may accept the answer or response provided at step 1114, in which case the system may record a successful interaction, thereby learning about user intent, context, and vocabulary usage…At step 1120, if it is determined that a sentence structure of the user request has not been seen before, a next process step 1140 may be performed to generate semantically close sentence templates using sentence similarity information, and to fill tagged tokens. According to such sentence templates, at a step 1142, question sentences may be generated with a sentence dismatch tag, for presentation to the user [recommending next functionality intent, under BRI of elements] and feedback collection at step 1136. The data entity matching and user interaction process continues until a match is found and an insight response to the user is generated”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Rahmfeld to incorporate the teachings of Jaganmohan and enable Rahmfeld to recommend, using a result of executing an executable version of the portion of source code on the dataset, a next functionality intent, the next functionality intent expressed in natural language form, as doing so would enable adaptively learning previously unseen forms of user requests, and infer user context and intent to help accurately understand user inputs and insight requests (Jaganmohan, col7).
Regarding claim 2,
Rahmfeld as modified by Jaganmohan teaches all the claimed limitations as set forth in the rejection of claim 1 above.
Rahmfeld as modified by Jaganmohan further teaches The computer-implemented method of claim 1, further comprising: extracting, from an input portion of source code, a second functionality intent, the second functionality intent comprising a second operation on the dataset; adapting the input portion of source code to implement the second functionality intent, the adapting resulting in an adapted version of the input portion; and executing, on the dataset, an executable version of the adapted version. *see paras15-17(“ A data conversation may contain a series of one or more data conversation steps that operate within a conversational context [first/next/second functionality intent, under broadest reasonable interpretation/BRI of claim elements]. A data conversation step may contain one or more utterances (i.e., natural language queries) and/or one more structured query language (e.g., SQL) queries directed at one or more datasets. If a data conversation step starts with an utterance (versus a structured query language query), then the utterance is first translated by the data conversation system into a structured query language query. The (translated or directly submitted) structured query language query is executed against the targeted one or more data sets which produces a data result set and metadata for a given data conversation step. The end product of a data conversation may be new data insights from and/or a broader understanding of the data included in the one or more datasets…system can enable a user to build complex data analyses using a modular approach that allows for new utterances to leverage previous conversation steps (including utterances and result sets) of a data conversation...Technical users (e.g., data analysts) may be able to review, modify, and/or augment existing data conversations shared by users (e.g., business users)… further improve and accelerate collaboration…”), para42(“…translation module 130 may also allow for usage of custom mathematical calculations, where the calculations may either be pre-defined or generated by a user within the utterance…130 may allow a new utterance to operate on, query, and/or use previous results…”), paras49-54(“... translation module 130 may include a pre-processing layer 132 configured to prepare user input(s) and utterance context for input to subsequent layers of the translation model 130…utterance 114 may include an ad-hoc custom calculation, which may enable users to perform complex mathematical operations on a previous result set using mathematical operations expressed as SQL phrases [source code]. As an example, a previous result set (e.g., the result of Step 3) may contain the sales amount and the quota for each account executive per quarter. An ad-hoc custom calculation may then be defined to determine an achievement ratio for each account representative [extracting from input portion of source code… second functionality intent, under BRI of elements]. The ad-hoc custom calculation may be calculated by inputting the following utterance: “Using Step 3, what is the [sum(amount)/sum(quota) as achievement ratio] per account representative?” [second functionality intent comprising second operation on dataset, under BRI of claim elements] To process the ad-hoc calculation, the pre-processing layer 132 may extract the calculation and the metric name from the utterance 114. The calculation and the metric name may then be encoded in a temporary schema along with the columns of the result set from Step 3 in the basic action identification Layer 134, following the schema encoding approach outlined above…the language pattern ‘using Step 3’ may identify that this temporary schema is the one that the to-be-generated structured query language SQL statement should be executed on [executing executable version of adapted version, under BRI of claim elements], i.e., the translation layer 136 and the post-processing layer 138 may use this temporary schema to generate the structured query language statement…As indicated in Table 1, in some implementations, if a predefined key phrase such as ‘using Step N’ is expressed in the utterance 114, this communicates the user's intent that the previous Step N is the target of the question. A temporary schema encoding may be constructed by the action identification layer 134 that encodes now the column information of the result set of Step N in the same way as the schema encoding encodes the database schema, i.e., one may interpret the result set columns of the result set as a simple temporary schema consisting of one table This temporary schema encoding may then be used by the translation layer 136 to construct an intermediate SQL that may aim to query this temporary table. The post-processing layer 138 may then convert the intermediate SQL into an executable SQL statement 160 that can be executed against the underlying schema. The last step may include reinserting the executable SQL statement of Step N [adapting input portion of source code to implement second functionality intent…, under BRI of claim elements]. If the action identification layer 134 does not identify the need to construct a temporary schema encoding based on a referenced step, the translation layer 136 and the post-processing layer 138 may use the schema encoding of the underlying database schema to translate the utterance 114 as described herein…another exemplary language pattern that may be implemented is shown in the second row in Table 1. A language pattern using the keyword ‘combine’ in conjunction with referencing two previous steps may trigger the generation of an executable SQL statement by the action identification layer 134. The SQL statement may implement an inner join of the referenced steps where the join columns may be the columns that appear in both referenced result sets. The translation layer 136 and the post-processing layer 138 may then be bypassed, as the executable SQL has already been constructed…”), paras83-111
Regarding claim 3,
Rahmfeld as modified by Jaganmohan teaches all the claimed limitations as set forth in the rejection of claim 1 above.
Rahmfeld further teaches The computer-implemented method of claim 1, wherein extracting the functionality intent comprises mapping an intent extracted from the natural language input to one of plurality of known functionality intents. *see paras55-77, paras78-85(“...intermediate SQL as described herein may be an abstracted universal (or near universal) SQL format, i.e. a language format that may be largely database agnostic and broadens the purpose to also align with a conversational context. The keywords used in the intermediate SQL grammar may consist of i) standard SQL keywords (e.g., ‘SELECT’, ‘COUNT’) and ii) keywords that encode higher-level actions mirroring a user intent that may refer back to previous steps in the conversation history 116 (e.g., ‘DROP’ as in ‘drop column cars using step 4’) [extracting…mapping intent extracted from natural language input to…known functionality intents]. The intermediate SQL may extend a standard SQL grammar by incorporating actions that refer to broader user intent that may not be part of a standard SQL vocabulary. The action(s) encoded in these extensions may be translated into executable SQL output during a post-processing operation…Table 2 below lists example utterance keywords, their actions (i.e. meanings) [mapping…], and their corresponding intermediate SQL encodings generated by the translation layer 136… TABLE 2 Example Intermediate SQL Mappings…”; data in “Intermediate SQL Keyword, Utterance Example” columns teaches intent extracted from natural language input; data in “Action, Intermediate SQL Encoding example” column teaches mapping to plurality of known functionality intents, under BRI of claim elements)
Regarding claim 4,
Rahmfeld as modified by Jaganmohan teaches all the claimed limitations as set forth in the rejection of claim 1 above.
Rahmfeld further teaches The computer-implemented method of claim 1, wherein generating the portion of source code comprises adapting a stored portion of source code to implement the functionality intent, the stored portion of source code comprising a previously implemented functionality intent. *see paras83-111(“...translation module 130 may include a post-processing layer 138. The post-processing layer 138 may convert the intermediate SQL statement from the translation layer 136 to an executable SQL statement that can be executed against the underlying database schema directly and/or previous result set(s) in the conversation context (which may be expressed as executable SQL statements against the underlying database schema themselves)…Converting intermediate SQL statements with the intermediate SQL keyword extensions into executable SQL clauses may…be accomplished by parsing the intermediate SQL statements and then constructing the appropriate clauses for the executable SQL statements. The schema encoding may be referenced for this construction. The complexity of the construction process may vary depending on the specific keyword used. For example, for some keywords that may extract time components of dates (e.g., ‘Year’, ‘Month’), the construction may be straightforward and the only complexity may be in the proper conversion for a particular structured query language dialect. An example… In other cases, the executable SQL construction may be more complex. Consider, for example, the case of ‘Drop’. The overall flow for a specific example may be: 1) assume that step 3 contains a result set with a number of columns, including a column named ‘stage’ 2) the new utterance in step 4 is “remove stage in step 3” 3) the effective schema identification layer 134 may identify the result set of step 3 as the correct target for the intermediate SQL and constructs a temporary effective schema which may be based on the column names of the result set of step 3 4) The translation layer 136 may…translate the utterance for the effective schema to the following intermediate SQL statement: “SELECT DROP(stage)” 5) The post-processing layer 138…may: i) identify the extended SQL keyword ‘Drop’ ii) use the columns of the effective schema to construct a SQL clause that selects all columns except for column ‘stage’ iii) combines the newly constructed clause with the executable SQL statement of step 3 to construct the executable SQL statement for step 4, which…may be done using Common Table Expressions [teaches generating portion of source code comprises adapting stored portion of source code to implement functionality intent… comprising previously implemented functionality intent, under BRI of claim elements]… As an example, the post-processing layer 138 may execute the following conversion from an intermediate SQL statement to an executable SQL statement: …Another example illustrating the reference to an earlier result set in the conversation history 116 could be:… ”), paras49-54
Regarding claim 5,
Rahmfeld as modified by Jaganmohan teaches all the claimed limitations as set forth in the rejection of claim 1 above.
Rahmfeld and Jaganmohan further teach The computer-implemented method of claim 1, wherein the next functionality intent comprises a functionality intent not yet logged in a log of executed functionality intents on the dataset. *see Rahmfeld:paras15-20(“...system can enable a user to build complex data analyses using a modular approach that allows for new utterances [next functionality intent comprises functionality intent not yet logged…, under BRI of claim elements] to leverage previous conversation steps (including utterances and result sets) of a data conversation...translation module may enable a user to build one or more data exploration and/or analysis flows, where a data exploration and/or analysis flow may use previous utterances and their corresponding results as context for new utterances”), para42(“...translation module 130 may also allow for usage of custom mathematical calculations, where the calculations may either be pre-defined [log of executed functionality intents, under BRI of claim elements] or generated by a user within the utterance [functionality intent not yet logged, under BRI]…module 130 may allow a new utterance to operate on, query, and/or use previous results.); Jaganmohan:cols14-15(“…Depending on the content of unstructured data 301 and structured data 302 used to build the knowledge graph, an exact match may or may not be found. For example, entity nodes may exist for yearly gross profits [log of executed functionality intents, under BRI of claim elements] and an analytical function for computing profit margins, and a sequence of analytical instructions such as SQL commands may be generated based on these entity nodes and relationship between these nodes, such that when the analytical instructions are applied to company sales data from database 314, gross profit margin for this year can be computed. In another example, the knowledge graph may contain entity nodes for gross sales instead of gross profits, and word embeddings 372 may be utilized in the matching process to help determine that the desired gross profit margin can be computed based on gross sales and some other entity nodes, given profit and sales are similar in meaning…if the system determines that no matching entity nodes and relationships can be found, the system may interact further with the user by providing one or more questions, prompts or options to the user to answer or select from [functionality intent not yet logged, under BRI]. Exemplary questions may be in the form of “did you mean this” where the user has the options to say or choose yes or no, “did you mean A, or B, or C” where the user has the options to choose one of the three options given, or “which years of data do you want to see over 1980 to present” etc… direction questions or multiple choice questions given by the system may both be viewed as a plurality of options, explicit or implicit, for the user to choose from. The process flow shown in FIG. 3 thus returns from the knowledge base back to obtain new user interaction data 316, and such data are again processed through step 348, with additional matchings performed based on the new data…”), cols20-21(“FIG. 11…generate context-based data insight responses to user requests…plurality of candidate semantic meanings are constructed from the tokenized user request; and one of the plurality of candidate semantic meanings may be selected based on a knowledge graph and a word embedding as a true semantic meaning of the user request…it is determined whether matching data pertinent to the user request, or the semantic meaning of the user request, can be identified from word embeddings 442 and knowledge graphs 444 in FIG. 4. If matching data (e.g., entities and entity relationships on the knowledge graphs) are identified, a response is generated at step 1112 and conveyed to the user at step 1114 via one or more of interaction interfaces 552. In some embodiments, the user may accept the answer or response provided at step 1114, in which case the system may record a successful interaction, thereby learning about user intent, context, and vocabulary usage [log of executed functionality intents, under BRI of claim elements].If it is determined at step 1110 that an accurate matching cannot be identified , the system may attempt to generate a question, prompt, or suggestion to the user, as a way to collect additional user input to clarify the original user request…user request is assessed at step 1120 to determine if its sentence structure has been seen before, for example, by comparing to a syntactic and semantic database internal to the knowledge base. If the answer is yes, next a step 1130 is performed to annotate and tag tokens, if any has not previously been annotated. Subsequently, a word embedding is used to help find closest matches to the user request's semantic meaning at a step 1132, optionally taking into account of user attributes such as but not limited to the terminology generally used within the context, the domain and the enterprise to provide suggestions. These closest matches are made into questions such as “Did you mean this” in a step 1134 to guide the user in framing the request correctly and to ask the right questions [functionality intent not yet logged, under BRI]. Here the question may be assigned a vocabulary dismatch tag…dismatch may indicate that no matching terminologies or data entities has been found on the knowledge graph; in some embodiments, dismatch may indicate a mismatch, where a matching result is found with a very low matching score or confidence level. The user may answer the system generated question or system provided option, for example by stating or selecting yes or no, at a step 1136. This user feedback is used in a step 1138 to adaptively or progressively train and enforce parts of the knowledge base…From another perspective, the user-selected answer is used by the knowledge base builder for supervised training of the knowledge base wherein labelled data is provided by the user for adding to one or more of the knowledge graphs and the word embeddings. The system learns elements such as user context and vocabularies usage from the user interactions, and improves the knowledge base with greater interaction. In addition, the user-selected answers may be stored under user profile or user attribute for future reference. At step 1120, if it is determined that a sentence structure of the user request has not been seen before, a next process step 1140 may be performed to generate semantically close sentence templates using sentence similarity information, and to fill tagged tokens. According to such sentence templates, at a step 1142, question sentences may be generated with a sentence dismatch tag, for presentation to the user [recommending functionality intent not yet logged, under BRI] and feedback collection at step 1136. The data entity matching and user interaction process continues until a match is found and an insight response to the user is generated”)
Regarding claim 7,
Claim 7 recites substantially the same claim limitations as claim 1, and is rejected for the same reasons.
Regarding claim 8,
Rahmfeld as modified by Jaganmohan teaches all the claimed limitations as set forth in the rejection of claim 7 above.
Rahmfeld further teaches The computer program product of claim 7, wherein the stored program instructions are stored in a computer readable storage device in a data processing system, and wherein the stored program instructions are transferred over a network from a remote data processing system. *see paras20, paras123-132(“...at least a portion of the approaches described above may be realized by instructions that upon execution cause one or more processing devices to carry out the processes and functions described above. Such instructions may include, for example, interpreted instructions such as script instructions, or executable code, or other instructions stored in a non-transitory computer readable medium. The storage device may be implemented in a distributed way over a network, for example as a server farm or a set of widely distributed servers, or may be implemented in a single computing device…A computer program can be deployed to be executed on one computer or on multiple computers that are located at one site or distributed across multiple sites and interconnected by a communication network…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, or that includes a front end component, e.g., a client computer having a graphical user interface or a Web browser through which a user can interact with an implementation of the subject matter described in this specification, or any combination of one or more such back end, middleware, or front end components. The components of the system can be interconnected by any form or medium of digital data communication, e.g., a communication network...The computing system can include clients and servers. A client and server are generally remote from each other and typically interact through a communication network…” teaches stored program instructions transferred over network from remote data processing system, under BRI of claim elements)
Regarding claim 10,
Claim 10 recites substantially the same claim limitations as claim 2, and is rejected for the same reasons.
Regarding claim 11,
Claim 11 recites substantially the same claim limitations as claim 3, and is rejected for the same reasons.
Regarding claim 12,
Claim 12 recites substantially the same claim limitations as claim 4, and is rejected for the same reasons.
Regarding claim 13,
Claim 13 recites substantially the same claim limitations as claim 5, and is rejected for the same reasons.
Regarding claim 15,
Claim 15 recites substantially the same claim limitations as claim 1, and is rejected for the same reasons.
Regarding claim 16,
Claim 16 recites substantially the same claim limitations as claim 2, and is rejected for the same reasons.
Regarding claim 17,
Claim 17 recites substantially the same claim limitations as claim 3, and is rejected for the same reasons.
Regarding claim 18,
Claim 18 recites substantially the same claim limitations as claim 4, and is rejected for the same reasons.
Regarding claim 19,
Claim 19 recites substantially the same claim limitations as claim 5, and is rejected for the same reasons.
Claims 6, 14 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Rahmfeld in view of Jaganmohan and Byron (US 2015/0142418 A1).
Regarding claim 6,
Rahmfeld as modified by Jaganmohan teaches all the claimed limitations as set forth in the rejection of claim 1 above.
However, Rahmfeld as modified by Jaganmohan does not expressly teach ‘The computer-implemented method of claim 1, wherein the functionality intent comprises a missing value identification operation, the result comprises an identification of a missing value, and the next functionality intent comprises a missing value imputation operation.’
Byron teaches The computer-implemented method of claim 1, wherein the functionality intent comprises a missing value identification operation, the result comprises an identification of a missing value, and the next functionality intent comprises a missing value imputation operation. *see FIGS. 9-10, para20(“…embodiments are directed to correcting erroneous or missing portions of content of a document using a Question and Answer (QA) system and queries generated from the context of the document surrounding the erroneous portion of the content [functionality intent comprises missing value identification operation, under BRI of claim elements]…erroneous or missing portions of content comprise values in cells of table data structures, the context of the document comprises discovered functional dependencies within the table data structures between portions of the table data structures or across one or more different table data structures, and the natural language conversions of cell information into queries are used by a QA system to correct the erroneous or missing portions of content…”), paras152-155(“FIG. 10…example process for correcting erroneous or missing data values in cells based upon discovered functional relationships in tabular data…process starts by receiving a natural language processed document with table structure and functional dependencies identified according to hypotheses and confidence ratings (step 1010) as described in the processes outlined in FIGS. 6 and 7 above…if an erroneous or missing data value is found, a semantic signature for the erroneous or missing data value is generated (step 1030). A question/query is generated from the semantic signature (step 1040) and is submitted to a knowledge base, e.g., QA system [functionality intent comprises a missing value identification operation, under BRI], document database, or the like (step 1050) search the knowledge base for an answer to the question/query. The results of the application of the question/query to the knowledge base are received (step 1060) and the results are used as a basis to replace the missing or erroneous value with a correct value either automatically or manually based on measures of confidence returned in the results (step 1070) [result comprises identification of missing value, next functionality intent comprises missing value imputation operation, under BRI of claim elements]…illustrative embodiments utilize the context surrounding the identified erroneous or missing data values, or portions of content, to generate questions/queries that are submitted to a knowledge base to obtain corrected values or corrected portions of content. Based on measures of confidence associated with the corrected values or corrected portions of content, the erroneous or missing content may be automatically or semi-automatically (with human user manual approval) corrected. As a result, more complete table structures and other document content for natural language processed documents are generated that can be used to perform natural language processing operations, such as question and answer operations in a QA system…”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Rahmfeld to incorporate the teachings of Byron and enable Rahmfeld to incorporate missing value identification operation as a functionality intent, identification of a missing value, and the next functionality intent as missing value imputation operation, as doing so would enable performing error correction in tables using a question and answer system, and generating complete table structures and content that can be used for natural language processing operations (Byron, paras20,155).
Regarding claim 14,
Claim 14 recites substantially the same claim limitations as claim 6, and is rejected for the same reasons.
Regarding claim 20,
Claim 20 recites substantially the same claim limitations as claim 6, and is rejected for the same reasons.
Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over Rahmfeld in view of Jaganmohan and Cowan (US 2022/0147400 A1).
Regarding claim 9,
Rahmfeld as modified by Jaganmohan teaches all the claimed limitations as set forth in the rejection of claim 7 above.
However, Rahmfeld as modified by Jaganmohan does not expressly teach The computer program product of claim 7, wherein the stored program instructions are stored in a computer readable storage device in a server data processing system, and wherein the stored program instructions are downloaded in response to a request over a network to a remote data processing system for use in a computer readable storage device associated with the remote data processing system, further comprising: program instructions to meter use of the program instructions associated with the request; and program instructions to generate an invoice based on the metered use.
Cowan teaches The computer program product of claim 7, wherein the stored program instructions are stored in a computer readable storage device in a server data processing system, and wherein the stored program instructions are downloaded in response to a request over a network to a remote data processing system for use in a computer readable storage device associated with the remote data processing system, further comprising: program instructions to meter use of the program instructions associated with the request; and program instructions to generate an invoice based on the metered use. *see paras24-26(“...system for tokenization of distributed compute resources, including at least one edge computing platform in network communication with a plurality of server nodes, wherein the at least one edge computing platform includes at least one collector, at least one meter, and at least one analytics platform, wherein the at least one edge computing platform is operable to fetch data from at least one of the plurality of server nodes using a serverless function in response to a request [teaches downloaded in response to request over network to remote data processing system, under BRI of claim elements], wherein the at least one edge computing platform is operable to monitor compute metrics, wherein the at least one collector is operable to determine consumption metrics for each of the plurality of server nodes based on the compute metrics, wherein the consumption metrics include capacity data, wherein the at least one collector is operable to transmit the consumption metrics to the at least one meter, wherein the at least one meter is operable to generate metering data based on the consumption metrics, wherein the at least one analytics platform is operable to aggregate the consumption metrics and the metering data from the plurality of server nodes to generate analytics data for at least one user account, wherein the at least one edge computing platform is operable to develop a billing scheme for usage of the distributed compute resources using the consumption metrics, the metering data [meter use of instructions associated with request…generate invoice based on metered use], and/or the analytics data, wherein the at least one edge computing platform is operable to compensate each of the plurality of server nodes for usage of the distributed compute resources, and wherein the at least one edge computing platform is operable to store the consumption metrics, the metering data, and/or the analytics data on a distributed ledger…it is necessary to meter usage of distributed compute resources in order to properly bill users for usage…present invention provides systems and methods for automated metering, tokenization, and billing for distributed compute resources in a content delivery network…”), paras59-61
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Rahmfeld to incorporate the teachings of Cowan and enable Rahmfeld to download stored program instructions to a remote data processing system in response to a network request, and further metering use of instructions associated with the request, and generating an invoice based on the metered use, as doing so would enable metering of distributed compute resources to properly bill users for true resource usage, while not including excessive and/or irrelevant resource usage (Cowan, paras29, 62).
Conclusion
The prior art made of record in PTO-892 and not relied upon is considered pertinent to applicant's disclosure.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ANUGEETHA KUNJITHAPATHAM whose telephone number is (408)918-7510. The examiner can normally be reached M-F 9-5 PT.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Aleksandr Kerzhner can be reached at (571) 270-1760. 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.
/A.K./Examiner, Art Unit 2165 /ALEKSANDR KERZHNER/Supervisory Patent Examiner, Art Unit 2165
Prosecution Insights