Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
The Amendment filed on 12/11/25 has been received and entered. Application No. 18/749,175 of which claims 3, 13-24, 28 have previously been canceled. Claims 1, 2, 4-12, 25-27, and 29-34 are pending in the application, all of which are ready for examination by the examiner.
Continued Examination under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 12/11/2025 has been entered.
Response to Amendment
Applicant’s arguments and remarks necessitated new grounds of rejection.
Response to Arguments
Applicant’s arguments with respect to 35 USC § 103 rejections of claims 1, 2, 4-12, 25-27, and 29-34 have been fully considered but are moot because the arguments do not apply to any of the references being used in the current rejection.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 2, 4-12, 25-27, 29-34 are rejected under 35 U.S.C. 103 as being unpatentable over Sundararaman et al. (U.S. Pub 2020/0050949; hereinafter “Sundararaman”) in view of Leary et al. (U.S. PGPub 2024/0095463; hereinafter “Leary”) and further in view of Kundel et al. (U.S. PGPub 2024/0354321; hereinafter “Kundel”).
As per claims 1, 12, 25 and 26, Sundararaman discloses a query processing method, comprising: acquiring a to-be-processed target query; (See Fig. 2A, paras. 61-64, wherein query relating to target data are disclosed; as taught by Sundararaman.)
acquiring a data field in a target data model and acquiring target format information of a specified data format; (See Fig. 2A, paras. 61-64, wherein query relating to target data and format in which “digital assistant platform may provide a chatbot interface configured to receive the query from the user as textual data and/or audio data corresponding to a string of characters arranged in a natural language format” [0061] are disclosed, also See paras. 32-33, wherein healthcare data platform comprising data elements, converting data files to a specified format in which “the healthcare data platform may convert the incoming or received data files to the same CSV format (analogous to target format). For example, assume that the data elements (analogous to data fields) in the first data file correspond to a plurality of member identifiers and genders associated with the member identifiers” [0032] are disclosed; as taught by Sundararaman.)
wherein the target format information comprises a preset dimension field, a preset measure field, and a preset filtering condition, and the target format information is configured for placing a target dimension hit by the to-be-processed target query in the target data model into the preset dimension field, placing a target measure hit by the to-be-processed target query in the target data model into the preset measure field, and placing a to-be-filtered field in the to-be-processed target query into the preset filtering condition. (See Figs. 1B-1C, paras. 34-38, 41-44, wherein predetermined attributes associated with data elements in which “attribute identifiers may be predetermined, standardized, and/or predefined identifiers that label, classify, or otherwise identify the type of data (e.g., member data (e.g., health insurance member identifier, age, date of birth, and/or the like), claim data (e.g., service date, claim amount, balance due, and/or the like), healthcare provider data (e.g., healthcare provider identifier, hospital identifier, healthcare provider address, and/or the like), pharmacy data (e.g., a prescription identifier, a medication identifier, and/or the like), and/or the like) that is represented by the respective data element. In this way, the data received from the healthcare EDI may be standardized and homogenized, for example, using one or more standardization engines of the healthcare data platform” [0034] are disclosed; as taught by Sundararaman.)
However, Sundararaman fails to disclose a large language model, being executed by an electronic device having a query processing function.
On the other hand, Leary teaches a large language model, being executed by an electronic device having a query processing function. (See Figs. 1-2, paras. 21-24, 34, wherein large language models (LLM), processing text using large language model in which “client A 202 has a string of text to be processed using an LLM of an inference service 216. Based at least on an intended use for a result of the processing, the request can have one or more guidance mechanisms 218 associated with it, such as a specific prompt token to identify a type of result to be returned, as well as a retrieval set to identify the specific database that the LLM is to use to process the request” [0034] are disclosed; as taught by Leary.)
Therefore, it would have been obvious to a person of ordinary skill in the computer art before the effective filing date of the claimed invention to incorporate the Leary teachings in the Sundararaman system. Skilled artisan would have been motivated to incorporate the system for natural language processing applications using large language models taught by Leary in the Sundararaman system for efficient digital assistant platform of analyzing healthcare data. In addition, both of the references (Sundararaman and Leary) teach features that are directed to analogous art and they are directed to the same field of endeavor, such as query formulation. This close relation between both of the references highly suggests an expectation of success.
However, the combination of Sundararaman and Leary fails to disclose constructing a prompt based on the data field in the target data model, the target format information, and the to-be-processed target query such that the data field in the target data model, the target format information, and the to-be-processed target query are contained in the prompt; inputting the prompt into the large language model to obtain a target format result outputted by the large language model, wherein the target format result is of the specified data format; and querying, according to the target format result, the target data model to obtain an answer to the to-be-processed target query, and outputting the answer to the to-be-processed target query.
On the other hand, Kundel teaches constructing a prompt based on the data field in the target data model, the target format information, and the to-be-processed target query such that the data field in the target data model, the target format information, and the to-be-processed target query are contained in the prompt; (See Figs. 2A, 3, paras. 13-15, 22, 29, wherein prompt engineering method, generating a request to data store for user, target format and targeted query in which “data store may identify stored user data relevant to the QT request and return the identified data to the QT. The QT may then generate an intermediate query to the model (or a secondary, lightweight, model accessible to the QT). The intermediate request may be a targeted request that includes a representation (e.g., a summary, a list of titles, a digest of available data, etc.) (analogous to target model, information, to-be-processed data) of the data received from the data store (e.g., “what information in the user query would be useful for future customer interactions?”). Having received the response from the model (or the secondary model), the QT may select context data identified by the model as useful for responding to the user query and may provide the selected context data to the user” [0015] and “DM 160 may validate data, convert data into a target format, identify and eliminate duplicate data, and/or the like. DM 160 may aggregate data, e.g., identify and combine data associated with a given user in the user's profile (user's persona), and storing the user's profile on a single memory partition” [0022] are disclosed; as taught by Kundel.)
inputting the prompt into the large language model to obtain a target format result outputted by the large language model, wherein the target format result is of the specified data format; (See paras. 22, 42-43, wherein process of converting to target format and natural language generative model that includes large language model (LLM) features in which “DM 160 may validate data, convert data into a target format, identify and eliminate duplicate data, and/or the like. DM 160 may aggregate data, e.g., identify and combine data associated with a given user in the user's profile (user's persona), and storing the user's profile on a single memory partition” [0022] are disclosed; as taught by Kundel.)
and querying, according to the target format result, the target data model to obtain an answer to the to-be-processed target query, and outputting the answer to the to-be-processed target query. (See paras. 14-16, 29-30, wherein answering user query process in which “GM 120 may process the intermediate query (operation 218) and generate a response to listing some of the contextual data that GM 120 may find useful for answering user query 212, e.g., “the dates of the Spring Break week (or the school the user is attending), the number of days the user plans to travel, the user's budget, the user's prior travels over the last one, two, etc., years,” and/or the like. GM 120 may communicate the response with the identification of the contextual information to QT 101 (operation 220). In those instances where intermediate query 214 asked GM 120 (or lightweight GM 215) to rank the available traits” [0030] are disclosed; as taught by Kundel.)
Therefore, it would have been obvious to a person of ordinary skill in the computer art before the effective filing date of the claimed invention to incorporate the Kundel teachings in the combination of Sundararaman and Leary system. Skilled artisan would have been motivated to incorporate the system for providing contextual data for natural language queries taught by Kundel in the combination of Sundararaman and Leary system for efficient digital assistant platform of analyzing healthcare data. In addition, both of the references (Sundararaman, Leary, and Kundel) teach features that are directed to analogous art and they are directed to the same field of endeavor, such as query formulation. This close relation between both of the references highly suggests an expectation of success.
As per claims 2 and 27, the combination of Sundararaman and Kundel fails to disclose wherein the target format result is configured for establishment of a relationship between the to-be-processed target query and the data field in the target data model, and the target format result is a serialized result.
On the other hand, Leary teaches wherein the target format result is configured for establishment of a relationship between the to-be-processed target query and the data field in the target data model, and the target format result is a serialized result. (See paras. 38-39, wherein returned results in specified form in which “Returned results may be in specified forms, as indicated by the guidance tokens, such as a single Boolean value, text in a structured format, multiple responses—such as for types of speech of each word in an input text string, and so forth” [0038] (analogous to relationship between query (i.e. input), target data, target format) are disclosed; as taught by Leary.)
See claims 1 and 25 for motivation above.
As per claims 4 and 29, the combination of Sundararaman, Leary, and Kundel discloses wherein the preset filtering condition uses an array structure, and the preset filtering condition comprises a preset first subfield, a preset second subfield, and a preset third subfield, wherein the preset first subfield is configured to represent the to-be-filtered field, the preset second subfield is configured to represent a filtering value of the to-be-filtered field, and the preset third subfield is configured to represent an operator of the preset filtering condition. (See Figs. 1B-1C, paras. 34-38, 41-44, wherein predetermined attributes associated with data elements in which “attribute identifiers may be predetermined, standardized, and/or predefined identifiers that label, classify, or otherwise identify the type of data (e.g., member data (e.g., health insurance member identifier, age, date of birth, and/or the like), claim data (e.g., service date, claim amount, balance due, and/or the like), healthcare provider data (e.g., healthcare provider identifier, hospital identifier, healthcare provider address, and/or the like), pharmacy data (e.g., a prescription identifier, a medication identifier, and/or the like), and/or the like) that is represented by the respective data element (analogous to subfields, filtering values). In this way, the data received from the healthcare EDI may be standardized and homogenized, for example, using one or more standardization engines of the healthcare data platform” [0034] are disclosed; as taught by Sundararaman.)
As per claims 5 and 30, the combination of Sundararaman and Kundel fails to disclose acquiring at least one data record from the target data model; generating sample data for the data field based on the at least one data record; and adding the sample data of the data field to the prompt.
On the other hand, Leary teaches acquiring at least one data record from the target data model; (See paras. 67, 176, wherein acquiring data process are disclosed; as taught by Leary.)
generating sample data for the data field based on the at least one data record; (See paras. 29, wherein endpoints, various data in which “A given inference namespace 120 may contain all endpoints for receiving requests to perform inferencing using the hosted LLMs 104 of the inference service 102…Each endpoint 122, 126 can consist of a number of associated items or aspects, as may include a name, identifier, address, and/or uniform resource locator (URL), such as “/summarize_news_article”. An endpoint might also include an indicator for the size of LLM to use for a request sent to this endpoint, as well as one or more associated inference parameters (e.g., number of samples or temperature). An endpoint can also include, or be associated with, one or more guidance mechanisms 124, such as a prompt token and retrieval set tag. In at least some embodiments, an endpoint may also be associated with a type of data marshalling 128 to be performed… this may be an option provided to a user, developer, or entity creating the respective endpoint” (analogous to sample data) [0029] are disclosed; as taught by Leary.)
and adding the sample data of the data field to the prompt. (See paras. 21, 29, wherein guidance mechanism, prompt tokens, processing of input fields to be processed by LLMs in which “A guidance mechanism can include any token, tag, weight, file, modifier, or other type of data object that can be added to, embedded in, or associated with a request to perform a specific operation, or type of operation, with respect to a string of text. Example guidance mechanisms include prompt tokens to indicate a type of operation to be performed, a retrieval set tag to indicate a data set to use for the operation, and/or an adaptor weight that can effectively modify operation or structure of the language model, among other such options. An endpoint receiving such a request can perform marshalling and/or other operations needed to get the request in a text format required by the language model, and can add the guidance mechanisms to the request” [0021] are disclosed; as taught by Leary.)
See claims 1 and 25 for motivation above.
As per claims 6 and 31, the combination of Sundararaman and Kundel fails to disclose wherein the prompt further comprises sample queries and sample answers in at least two small samples, wherein the sample answers are in the specified data format.
On the other hand, Leary teaches wherein the prompt further comprises sample queries and sample answers in at least two small samples, wherein the sample answers are in the specified data format. (See paras. 29, wherein endpoints, various data that correspond to prompt tokens in which “An endpoint receiving such a request can perform marshalling and/or other operations needed to get the request in a text format (analogous to sample queries) required by the language model, and can add the guidance mechanisms to the request by, for example, prepending one or more text strings (or text prefixes) to the text formatted request…Once inferencing is performed using the model, the result (in the form specified by the prompt token) can be returned to the endpoint, where any marshalling and/or other processing can be performed to put the results in a necessary structure or format (analogous to sample answers), and the result may be forwarded on to the intended recipient or destination” [0021] are disclosed; as taught by Leary.)
See claims 1 and 25 for motivation above.
As per claims 7 and 32, the combination of Sundararaman and Kundel fails to disclose wherein fields in the sample answers are randomly selected from data fields of the target data model.
On the other hand, Leary teaches wherein fields in the sample answers are randomly selected from data fields of the target data model. (See para. 127, wherein output models that include machine learning models which unitize various techniques, such as random forest, K means clustering, decision trees, gradient booting algorithms, neural networks, etc. are disclosed; as taught by Leary.)
See claims 1 and 25 for motivation above.
As per claim 8, the combination of Sundararaman, Leary, and Kundel discloses wherein at least one of the sample answers comprises a dimension field, a measure field, and a filtering condition; and at least one of the sample answers lacks at least one of the dimension field, the measure field, or the filtering condition. (See para. 67, wherein insufficient keywords (analogous to lack of data fields) in which “when the keywords are insufficient to identify the intent classification and/or the entity and/or when sufficient keywords cannot be extracted from the query, the digital assistant platform may generate a subsequent request for additional information, and communicate the request for additional information to the user” are disclosed; as taught by Sundararaman.)
As per claim 9, the combination of Sundararaman, Leary, and Kundel discloses in response to the target data model comprising a data dimension of a date type, a first subfield in a filtering condition of at least one of the sample answers is of the date type. (See Figs. 1B-1C, paras. 34-38, 41-44, wherein predetermined attributes associated with data elements in which “attribute identifiers may be predetermined, standardized, and/or predefined identifiers that label, classify, or otherwise identify the type of data (e.g., member data (e.g., health insurance member identifier, age, date of birth, and/or the like),…” [0034] are disclosed; as taught by Sundararaman.)
As per claim 10, the combination of Sundararaman, Leary, and Kundel discloses in response to the target data model comprising a data dimension of a geographic location type, a first subfield in a filtering condition of at least one of the sample answers is of the geographic location type. (See Figs. 1B-1C, paras. 34-38, 41-44, wherein predetermined attributes associated with data elements in which “attribute identifiers may be predetermined, standardized, and/or predefined identifiers that label, classify, or otherwise identify the type of data (e.g., member data (e.g., health insurance member identifier, age, date of birth, and/or the like), claim data (e.g., service date, claim amount, balance due, and/or the like), healthcare provider data (e.g., healthcare provider identifier, hospital identifier, healthcare provider address, and/or the like), pharmacy data (e.g., a prescription identifier, a medication identifier, and/or the like), and/or the like) that is represented by the respective data element (analogous to subfields, filtering values). In this way, the data received from the healthcare EDI may be standardized and homogenized, for example, using one or more standardization engines of the healthcare data platform” [0034] are disclosed; as taught by Sundararaman.)
As per claim 11, the combination of Sundararaman, Leary, and Kundel discloses wherein the prompt comprises at least one of following policies: a time policy configured for, in response to the to-be-processed target query comprising time description information, processing the time description information into target time according to current time and placing the target time into a filtering condition of the target format result;
a sample data policy configured for, in response to a filtering condition of the target format result comprising sample data of a data field and the sample data of the data field being absent from the to-be-processed target query, removing the sample data of the data field from the filtering condition of the target format result by filtration; (See para. 37, wherein removing specific notations process in which “the healthcare data platform may assign, label, or classify the extracted data elements in the data files based on predetermined or predefined attribute identifiers. In this way, any specific notations (e.g., “M,” “F,” “1,” “2,” and/or the like) may be removed, obviated, standardized, and/or homogenized. In some implementations, the healthcare data platform may access data structures or mappings for assigning the data elements to the attribute identifiers. For example, the healthcare data platform may employ one or more mapping engines based on a healthcare subject area and one or more attribute data structures containing mappings (e.g., tables, catalogs, databases, and/or the like) to assign or map the data elements and the predefined attribute identifiers” are disclosed; as taught by Sundararaman.)
or a field policy configured for controlling a to-be-filtered field of a filtering condition in the target format result to be same as the data field in the target data model.
As per claim 33, the combination of Sundararaman, Leary, and Kundel discloses wherein the target data model comprises at least one of the following dimensions: order number, order date, region, province, city, product name, product category, product subcategory, customer name, customer type code, shipping date, or mailing method, and the target data model comprises at least one of the following measures: quantity, sales amount, cost, or profit. (See Fig. 1B, paras. 34-35, wherein attribute identifiers, type of data in which “predefined identifiers that label, classify, or otherwise identify the type of data ( e.g., member data ( e.g., health insurance member identifier, age, date of birth, and/or the like), claim data ( e.g., service date, claim amount, balance due, and/or the like), healthcare provider data ( e.g., healthcare provider identifier, hospital identifier, healthcare provider address, and/or the like), pharmacy data ( e.g., a prescription identifier, a medication identifier, and/or the like), and/or the like) that is represented by the respective data element” are disclosed, also See paras. 15, 50, wherein calculating amounts for paid claims, denied claims are disclosed; as taught by Sundararaman.)
As per claim 34, the combination of Sundararaman and Kundel fails to disclose wherein the target format result is configured for establishment of a relationship between the to-be-processed target query and the data field in the target data model, and the target format result is a serialized result.
On the other hand, Leary teaches wherein the target format result is configured for establishment of a relationship between the to-be-processed target query and the data field in the target data model, and the target format result is a serialized result. (See paras. 36-39, wherein prompt token, training/generation of prompt token in which “prompt token can take the form of a series of numbers that can be prepended to (or otherwise inserted in or after) the input request text string. The series of numbers (or alphanumeric characters) may not be human-understandable, but can provide guidance as to how the following text in the string should be processed” are disclosed; as taught by Leary.)
See claim 25 for motivation above.
Conclusion
1. The examiner requests, in response to this Office action, support be shown for language added to any original claims on amendment and any new claims. That is, indicate support for newly added claim language by specifically pointing to page(s) and line no(s) in the specification and/or drawing figure(s). This will assist the examiner in prosecuting the application.
2. When responding to this office action, Applicant is advised to clearly point out the patentable novelty which he or she thinks the claims present, in view of the state of the art disclosed by the references cited or the objections made. He or she must also show how the amendments avoid such references or objections See 37 CFR 1.111(c).
POINT OF CONTACT
Any inquiry concerning this communication or earlier communications from the examiner should be directed to LIN LIN M HTAY whose telephone number is (571)272-7293. The examiner can normally be reached on M-F, 7am-3pm, PST.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Kavita Stanley can be reached on (571)272-8352. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/L. L. H./
Examiner, Art Unit 2153
/KRIS E MACKES/ Primary Examiner, Art Unit 2153