Prosecution Insights
Last updated: April 19, 2026
Application No. 17/445,571

SYSTEMS AND METHODS FOR HEALTHCARE INSIGHTS WITH KNOWLEDGE GRAPHS

Non-Final OA §101§103
Filed
Aug 20, 2021
Examiner
VANDER WOUDE, KIMBERLY ELAINE
Art Unit
3681
Tech Center
3600 — Transportation & Electronic Commerce
Assignee
Cambia Health Solutions Inc.
OA Round
3 (Non-Final)
7%
Grant Probability
At Risk
3-4
OA Rounds
2y 6m
To Grant
16%
With Interview

Examiner Intelligence

Grants only 7% of cases
7%
Career Allow Rate
2 granted / 30 resolved
-45.3% vs TC avg
Moderate +10% lift
Without
With
+9.5%
Interview Lift
resolved cases with interview
Typical timeline
2y 6m
Avg Prosecution
24 currently pending
Career history
54
Total Applications
across all art units

Statute-Specific Performance

§101
35.2%
-4.8% vs TC avg
§103
35.6%
-4.4% vs TC avg
§102
11.3%
-28.7% vs TC avg
§112
13.9%
-26.1% vs TC avg
Black line = Tech Center average estimate • Based on career data from 30 resolved cases

Office Action

§101 §103
DETAILED ACTION 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 . Status of Claims This action is in reply to Applicant’s communication filed on June 10, 2025. Claims 1, 5, 7 and 13-20 have been amended and are hereby entered. Claims 1-20 are currently pending and have been examined. 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 June 10, 2025 has been entered. Claim Objections Claims 2, 7-8 and 20 are objected to because of the following informalities: Claim 2, 8 and 20 recite “the heterogeneous plurality of data sources” which should read “the plurality of data sources” in order to be consistent with Applicants other amendments. Claim 7 recites “wherein the knowledge graph includes the plurality of nodes and edges that correspond to a diagnosis code” should read “wherein the knowledge graph includes a plurality of nodes and edges that correspond to a diagnosis code” in order to be consistent with Applicants other amendments. 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. Step 1 analysis: Claims 1, 7 and 13 are directed to a method, a manufacture and a system respectively and therefore all fall into one of the four statutory categories. (Step 1: Yes, the claims fall into one of the four statutory categories). Step 2A analysis - Prong one: Claim 1 recites the following limitations: extracting medical data from a plurality of data sources that include a disease database, a patient database, and a medicine database; wherein the disease database includes a disease dataset that maps diagnostic codes to related terms; wherein the patient database includes de-identified data that includes procedure codes and diagnostic codes; wherein the medicine database includes detailed drug data; constructing, with a processor, a knowledge graph from the extracted data; wherein constructing the knowledge graph includes using a neural language model that maps the extracted data to symptom entities in the knowledge graph; automatically identifying one or more new connections within the knowledge graph with a machine learning model; generating a healthcare recommendation based on the one or more new connections; wherein the diagnosis code is associated with multiple symptom entities via multiple diagnosis code-symptom edges; wherein the multiple symptom entities are associated with multiple layman entities that indicates symptoms in layman's terms; wherein constructing the knowledge graph includes detecting and classifying relationships between the multiple symptom entities and multiple layman entities; outputting, to a user device for display to a user, the healthcare recommendation; wherein the extracted medical data does not indicate symptoms in layman's terms. Claim 7 further recites the following limitations: A non-transitory computer-readable storage medium including an executable program stored thereon, the program configured to cause a computer processor to: receive medical data from a plurality of data sources that include a disease database, a patient database, and a medicine database; wherein the disease database includes a disease dataset that maps diagnostic codes to related terms; wherein the patient database includes de-identified data that includes procedure codes and diagnostic codes; wherein the medicine database includes detailed drug data; transform the received medical data into a different structure; wherein transformation of the received data include conversion of relations encoded in the medical data in relational database structures into entities and edges or links therebetween; load the transformed data into a knowledge graph; wherein the knowledge graph includes the plurality of nodes and edges that correspond to a diagnosis code; wherein the diagnosis code is associated with multiple symptom entities via multiple diagnosis code-symptom edges; wherein the multiple symptom entities are associated with multiple layman entities that indicates symptoms in layman's terms; wherein constructing the knowledge graph includes detecting and classifying relationships between the multiple symptom entities and multiple layman entities; extract healthcare insights from the knowledge graph; and output, to a user device for display to a user, a healthcare recommendation based on the healthcare insights; wherein the received medical data does not indicate symptoms in layman's terms. Claim 13 recites the following limitations: a user device configured for a user; and a server communicatively coupled to a client device, the server configured with executable instructions in non-transitory memory of the server that when executed cause a processor of the server to: extract medical data from a plurality of data sources that include a disease database, a patient database, and a medicine database; wherein the disease database includes a disease dataset that maps diagnostic codes to related terms; wherein the patient database includes de-identified data that includes procedure codes and diagnostic codes; wherein the medicine database includes detailed drug data; convert the extracted medical data into a different format; load the converted data into a knowledge graph structure that is stored in the server; wherein the knowledge graph structure includes a plurality of nodes and edges that correspond to a diagnosis code; wherein the diagnosis code is associated with multiple symptom entities via multiple diagnosis code-symptom edges; wherein the multiple symptom entities are associated with multiple layman entities that indicates symptoms in layman's terms; automatically generate a healthcare insight from the knowledge graph structure; transmit a healthcare recommendation to the user device for display to the user, wherein the healthcare recommendation is generated based on the healthcare insight; wherein the extracted medical data does not indicate symptoms in layman's terms; wherein the healthcare insight includes one or more of newly-identified edges between multiple layman entities in the knowledge graph structure. The examiner is interpreting the above bolded limitations as additional elements as further discussed below. The remaining non-bolded limitations above, as drafted, is a process that, under the broadest reasonable interpretation, covers certain methods of organizing human activity (i.e., managing personal behavior including following rules or instructions) but for recitation of generic computer components. That is, other than reciting a system implemented by a processor (computer), the claimed invention amounts to managing personal behavior or interaction between people. For example, but for the processor, user device, machine learning models, etc., this claim encompasses a person collecting patient data from numerous sources, recognizing relationships between the data, and communicating a healthcare recommendation based on the relationships in the manner described in the identified abstract idea, supra. The Examiner notes that certain “method[s] of organizing human activity” includes a person’s interaction with a computer (see MPEP 2106.04(a)(2)(II)). If a claim limitation, under its broadest reasonable interpretation, covers managing personal behavior or interactions between people but for the recitation of generic computer components, then it falls within the “certain methods of organizing human activity” grouping of abstract ideas. Accordingly, the claim recites an abstract idea. Further, the non-bolded limitations above, as drafted, is a process that covers performance of the limitation in the mind but for recitation of generic computer components. That is, other than reciting a processor, machine learning models, a user device (Claims 1, 7 and 13), CRM implemented by a computer (Claim 7), and a server (Claim 13), nothing in the claim precludes the step from practically being performed in the mind (see full list of identified additional elements in Step 2A Prong two below). For example, but for the identified additional elements, this claim encompasses a person thinking about different concepts and their relationships to each other and indexing the relationships for later retrieval in the manner described in the identified abstract idea, supra. See also Applicant’s specification paras 13 and 62. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic computer components, then it falls within the “Mental Processes” grouping of abstract ideas. Accordingly, the claim recites an abstract idea. Regarding claims 7 and 13, Examiner notes that the limitations “transform the received medical data into a different structure; wherein transformation of the received data include conversion of relations encoded in the medical data in relational database structures into entities and edges or links therebetween;” (claim 7) and “convert the extracted medical data into a different format;” (claim 13) are identified to be part of the abstract idea because the transformation/conversion of data into a different structure/format may be interpreted as simply changing/converting units, adjusting a scale, etc. which are abstract ideas. The combination analysis of all the abstract ideas still leads to the determination that the limitations as a whole are grouped as certain methods of organizing human activity. The types of identified abstract ideas are considered together as a single abstract idea for analysis purposes. (Step 2A – Prong 1: Yes, the claims are abstract). Step 2A analysis - Prong two: Claims 1, 7 and 13 recite additional elements beyond the abstract idea. Claim 1 recites a disease database, a patient database, a medicine database, a processor, using a neural language model, using a machine learning model, and a user device. Claim 7 recites non-transitory computer-readable storage medium, a stored program, a computer processor, a disease database, a patient database, a medicine database, loading the transformed data into a knowledge graph, and a user device. Claim 13 recites a user device, a server communicatively coupled to a client device, instructions in non-transitory memory of the server, a processor, a disease database, a patient database, a medicine database, and load the converted data into a knowledge graph structure that is stored in the server. The claims are applying generic computer components to the recited abstract limitations. The executable program and executable instructions appear to be purely software. This judicial exception is not integrated into a practical application. In particular, the claims recite recites a disease database, a patient database, a medicine database, a processor, using a neural language model, using a machine learning model, a user device, non-transitory computer-readable storage medium, a stored program, loading the transformed data into a knowledge graph, a server communicatively coupled to a client device, and loading the converted data into a knowledge graph structure that is stored in the server; which are recited at a high-level of generality (i.e., as a generic processor performing generic computer functions) such that it amounts to no more than mere instructions to apply the exceptions using a generic computer component. For example, Applicant’s specification explains that the processor reads and executes instructions, receives data inputs, transforms input data, analyzes data, etc. (see Applicant’s specification paras 4, 18, 28, 66-67). Further, claim 13 recites transmitting a healthcare recommendation to the user device. This transmitting step is recited at a high level of generality (i.e., as a general means of transmitting data) and amounts to the mere transmission of data, which is a form of extra-solution activity. MPEP 2106.04(d)(I) indicates that extra-solution data gathering activity cannot provide a practical application. Accordingly, these additional elements, when considered separately and as an ordered combination, do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. Therefore, Claims 1, 7 and 13 are directed to an abstract idea without practical application. (Step 2A – Prong 2: No, the additional claimed elements are not integrated into a practical application). Step 2B analysis: The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional element of a disease database, a patient database, a medicine database, a processor, using a neural language model, using a machine learning model, a user device, non-transitory computer-readable storage medium, a stored program, loading the transformed data into a knowledge graph, a server communicatively coupled to a client device, and loading the converted data into a knowledge graph structure to perform the noted steps amounts to no more than mere instructions to apply the exception using a generic computer component. Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept (“significantly more”). Also, as discussed above with respect to integration of the abstract idea into a practical application, the additional element of transmitting a healthcare recommendation to the user device (claim 13) were considered extra-solution activity. This has been re-evaluated under the “significantly more” analysis and determined to be well-understood, routine, conventional activity in the field. MPEP 2016.05(d)(II) indicates that receiving and/or transmitting data over a network has been held by the courts to be well-understood, routine, conventional activity [Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information); TLI Communications LLC v. AV Auto. LLC, 823 F.3d 607, 610, 118 USPQ2d 1744, 1745 (Fed. Cir. 2016) (using a telephone for image transmission); OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1093 (Fed. Cir. 2015) (sending messages over a network); buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014) (computer receives and sends information over a network)]. Courts have held computer‐implemented processes not to be significantly more than an abstract idea (and thus ineligible) where the claim as a whole amounts to nothing more than generic computer functions merely used to implement an abstract idea, such as an idea that could be done by a human analog (i.e., by hand or by merely thinking). On the other hand, courts have held computer-implemented processes to be significantly more than an abstract idea (and thus eligible), where generic computer components are able in combination to perform functions that are not merely generic. See MPEP §2106.05(d)(II) – emphasis added. The claims are directed to an abstract idea with additional generic computer elements that do not add meaningful limitations to the abstract idea because they require no more than a generic computer to perform generic computer functions that are well-understood, routine, and conventional activities previously known in the industry. For the next step of the analysis, it must be determined whether the limitations present in the claims represent a patent-eligible application of the abstract idea. A claim directed to a judicial exception must be analyzed to determine whether the elements of the claim, considered both individually and as an ordered combination are sufficient to ensure that the claim as a whole amounts to significantly more than the exception itself. For the role of a computer in a computer implemented invention to be deemed meaningful in the context of this analysis, it must involve more than performance of well-understood, routine, and conventional activities previously known to the industry. Further, the mere recitation of a generic computer cannot transform a patent ineligible abstract idea into a patent-eligible invention. See MPEP 2106.05(d). Applicant’s specification discloses the following: Applicant describes embodiments of the disclosure at a very high level to include the use of a wide variety of processors, databases, input/output devices, non-transitory devices, servers, networks, memories, etc. (see paras 15-19, 21, 23-24, 28, 33, 35). The method may use any computing device configured to perform computation and that is capable of sending and receiving data communications by way of one or more wired and/or wireless communication interfaces (see para 35). Looking at the limitations as an ordered combination adds nothing that is not already present when looking at the elements taken individually. There is no indication that the combination of elements improves the functioning of a computer or improves any other technology. The collective functions appear to be implemented using conventional computer systemization. The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements discussed above 1) amount to no more than mere instructions to apply the exceptions using generic computer components or 2) were determined to be well-understood, routine, conventional activity. Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept. The claims do not provide an inventive concept significantly more than the abstract idea. Accordingly, these additional elements, when considered separately and as an ordered combination, do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. (Step 2B: No, the claims do not provide significantly more). Dependent Claims 2-6, 8-12 and 14-20 further define the abstract idea that is presented in independent Claims 1, 7 and 13 respectively, and are further grouped as certain methods of organizing human activity and are abstract for the same reasons and basis as presented above. Further, Claims 2, 8, 14 and 19 recite additional elements beyond the abstract idea. Claims 2 and 8 recite a disease database. Claim 14 recites that the plurality of data sources are communicatively coupled to the server via a network. This/these additional element(s) is/are recited at a high level of generality such that it amounts to no more than mere instructions to apply the exception using a generic computer component. For example, as noted above, the Applicant’s specification indicates the use of known databases, servers and networks. Claim 19 recites transmitting search results which amounts to the mere transmission of data, which is a form of extra-solution activity. MPEP 2106.04(d)(I) indicates that extra-solution data gathering activity cannot provide a practical application (see similar analysis of the transmitting limitation in claim 13 in steps 2A2 and 2B above). Accordingly, these additional elements, when considered separately and as an ordered combination, do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. The claims do not recite additional elements that integrate the judicial exception into a practical application when considered both individually and as an ordered combination. Therefore, the dependent claims are also directed to an abstract idea. Thus, Claims 1-20 are rejected under 35 U.S.C. 101 as being directed to abstract ideas without significantly more. Claim Rejections - 35 USC § 103 This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention. 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-6 are rejected under 35 U.S.C. 103 as being unpatentable over Gnanasambandam et al. (US 20220391270), in view of Wixon (Wixon, C. (2019, July 10). Transforming Health Information Technology with a knowledge graph. Graph Database & Analytics. https://neo4j.com/blog/healthcare/transforming-health-information-technology-knowledge-graph/), in view of Salazar et al. (US 20180218126), in view of Yuan (US 20210375479), in view of Johnson et al. (Johnson, A. E. W., Pollard, T. J., Shen, L., Lehman, L. H., Feng, M., Ghassemi, M., Moody, B., Szolovits, P., Anthony Celi, L., & Mark, R. G. (2016, May 24). Mimic-III, a freely accessible Critical Care Database. Nature News. https://www.nature.com/articles/sdata201635), further in view of Wishart et al. (Wishart DS, Knox C, Guo AC, Shrivastava S, Hassanali M, Stothard P, Chang Z, Woolsey J. DrugBank: a comprehensive resource for in silico drug discovery and exploration. Nucleic Acids Res. 2006 Jan 1;34(Database issue):D668-72. doi: 10.1093/nar/gkj067. PMID: 16381955; PMCID: PMC1347430.). Regarding Claim 1, Gnanasambandam discloses the following limitations: A method, comprising: extracting medical data from a plurality of data sources …;(Gnanasambandam discloses aggregating patient data across multiple health information technology resources and that the knowledge cloud 106 is configured to receive the data (extracting medical data) from various sources and entities (from a plurality of data sources) and integrate the data in a database. – paras 2, 168, 154) constructing, with a processor, a knowledge graph from the extracted data; (Gnanasambandam discloses one or more machine learning models generating one or more knowledge graphs (constructing, with a processor, a knowledge graph) (e.g., FIG 5 shows an exemplary knowledge graph) for each known medical condition. The knowledge graphs may be generated with evidence-based guidelines, physician research, patient notes in EMRs, physician feedback, and so forth (from the extracted data). – paras 114, 158, 272; FIG. 5) automatically identifying one or more new connections within the knowledge graph with a machine learning model; (Gnanasambandam discloses that the knowledge graph 500 or the matrix may be generated for each known medical condition and stored by the cognitive intelligence platform 102. The knowledge graphs and/or matrices may be updated continuously or on a periodic basis using subject data pertaining to the medical conditions received from the trusted sources. For example, additional clinical trials may lead to new discoveries about particular medical condition treatments, which may be used to update the knowledge graphs and/or matrices (automatically identifying one or more new connections within the knowledge graph). Where the cognitive intelligence platform includes an AI engines, i.e., machine learning models (with a machine learning model). Further, the cognitive agent 110 asserts non-existent concepts or relations to form new knowledge. – paras 157, 219, 272; FIG. 1 items 102 and 109) generating a healthcare recommendation based on the one or more new connections; (Gnanasambandam discloses that the knowledge graphs and/or matrices may be updated (based on the one or more new connections) continuously or on a periodic basis using subject data pertaining to the medical conditions. In addition, the cognitive intelligence platform may use a knowledge graph pertaining to a condition of a user and a data structure (e.g., a patient graph) corresponding to the condition and the user to electronically generate a care plan (generating a healthcare recommendation) for the condition of the user. – paras 69-70, 141, 272; FIGs. 57-58) outputting, to a user device for display to a user, the healthcare recommendation; (Gnanasambandam discloses outputting the generated care plan (the healthcare recommendation) based on the cognitive data via a user interface such as in FIG. 57D. – paras 539-540; FIGs. 57D and 58) wherein the extracted medical data does not indicate symptoms in layman's terms. (Gnanasambandam discloses that the service provider 112 collects and generates data associated with the patient or the user, including health records (the extracted medical data) that include doctor's notes about the patient and prescriptions (does not indicate symptoms in layman's terms), billing records (does not indicate symptoms in layman's terms), and insurance records (does not indicate symptoms in layman's terms). The service provider 112, using a computing device (e.g., a desktop computer or a tablet), provides the data associated with the user (the extracted medical data) to the cognitive intelligence platform 102, and more specifically the knowledge cloud 106. – para 169) Gnanasambandam does not disclose the following limitations met by Wixon: wherein the diagnosis code is associated with multiple symptom entities via multiple diagnosis code-symptom edges; (Wixon teaches creating a knowledge graph using a patients electronic health records. The nodes are connected to each other by lines (i.e., the edges) are representative of symptoms and related ICD diagnosis codes (the diagnosis code is associated with multiple symptom entities via multiple diagnosis code-symptom edges). Each node has a direct relationship to another node and a node may contain attributes such as symptoms and may also contain an appropriate ICD code. – page 7 and both images thereon) It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to have modified generating one or more knowledge graphs as disclosed by Gnanasambandam to incorporate using ICD codes as taught by Wixon in order to improve outcomes and reduce costs (see Wixon page 11 ‘conclusion’). Gnanasambandam and Wixon do not disclose the following limitations met by Salazar: wherein the multiple symptom entities are associated with multiple layman entities that indicates symptoms in layman's terms; (Salazar teaches generating a knowledge graph of nodes related to symptoms such as “heartburn” and “nausea/vomiting” (multiple symptom entities) and connected edges (are associated with) to other words/phrases such as “throat hurts”, “upset stomach”, etc. (multiple layman entities that indicates symptoms in layman's terms). For example, “throw up” 720 (layman's terms) is often colloquially used to mean “vomit” (i.e., “Nausea/Vomiting” 704) (symptom entities). – paras 4, 54-55; FIG. 7) wherein constructing the knowledge graph includes detecting and classifying relationships between the multiple symptom entities and multiple layman entities; (Salazar teaches that the edges of the knowledge graph may be weighted (detecting and classifying relationships between the multiple symptom entities and multiple layman entities) based on strength (based on frequency of co-occurrence) of the connection between the vertices 702-730. – para 56; FIG. 7) It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to have further modified generating one or more knowledge graphs as disclosed by Gnanasambandam to incorporate relationships between symptoms and more commonly used terms related to those symptoms as taught by Salazar in order that healthcare professionals can increase the number of patients they can assist, ensure high-quality care, and reduce operational costs (see Salazar para 3). Gnanasambandam, Wixon and Salazar do not disclose the following limitations met by Yuan: wherein constructing the knowledge graph includes using a neural language model that maps the extracted data to symptom entities in the knowledge graph; (Yuan teaches that it is necessary to convert the symptom entity data into a numerical form that the processing device can understand. A neural network language model (NNLM) is used (using a neural language model) to obtain the symptom encoding vector corresponding to the symptom entity data. The symptom encoding vector is then output to the graph convolutional neural network layer, and results in a symptom entity node in the knowledge graph (maps the extracted data to symptom entities in the knowledge graph). – paras 45-46, 48) It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to have further modified generating one or more knowledge graphs as disclosed by Gnanasambandam to incorporate a neural network language model as taught by Yuan in order to improve the accuracy of disease prediction based on symptom entity information (see Yuan paras 4-5). Gnanasambandam, Wixon, Salazar and Yuan do not disclose the following limitations met by Johnson: …a plurality of data sources that include a disease database…wherein the disease database includes a disease dataset that maps diagnostic codes to related terms; (Johnson teaches that MIMIC-III database (a disease database) contains a look-up table for cross referencing concept identifiers, for example ICD codes (a disease dataset that maps diagnostic codes), with associated labels (to related terms). – page 4, table 3) …a plurality of data sources that include…a patient database, …wherein the patient database includes de-identified data that includes procedure codes and diagnostic codes; (Johnson teaches that the MIMIC-III database contains deidentified patient data (includes de-identified data) such as procedure codes and diagnostic codes (includes procedure codes and diagnostic codes). – abstract; page 6, ‘Deidentification’) (Examiner notes that this known database is also described in Applicant’s specification in para 50 to contain deidentified patient data including procedure and diagnostic codes). It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to have further modified generating one or more knowledge graphs as disclosed by Gnanasambandam to incorporate the use of the MIMIC-III database as taught by Johnson in order to reproduce and improve clinical studies in ways that would not otherwise be possible (see Page 2, ‘Background & Summary’ para 3). Gnanasambandam, Wixon, Salazar, Yuan and Johnson do not disclose the following limitations met by Wishart: …a plurality of data sources that include… a medicine database; wherein the medicine database includes detailed drug data; (Wishart teaches DrugBank (a medicine database) which includes detailed drug (includes detailed drug data). – abstract) (Examiner notes that the Applicant’s specification describes this DrugBank to include detailed drug information in para 50) It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to have further modified generating one or more knowledge graphs as disclosed by Gnanasambandam to incorporate using detailed drug data from a database such as DrugBank as taught by Wishart in order to aid medical researchers (see ‘Introduction’ page 2). Regarding Claim 2, Gnanasambandam, Wixon, Salazar, Yuan, Johnson and Wishart disclose all the limitations above and further disclose the following limitations: The method of claim 1, wherein the heterogeneous plurality of data sources includes a provider data source, a patient data source, a medicine data source, a disease database, and at least one medical ontology data source. (Gnanasambandam discloses using medical subject matter ontology data (medical ontology data source – paras 240-241, 355-356), a service provider source (provider data source), a micro survey source from a user device (a patient data source), a facility source such as a hospital, clinic, trauma center, etc., (a medicine data source), as well as evidence-based guidelines, physician research, patient notes in EMRs, physician feedback, etc., in order to generate the knowledge graphs which may represent knowledge of a disease and the knowledge graph may include a set of concepts pertaining to the disease obtained from the known health related information and also includes relationships between the set of concepts. This indicates that the used data to generate the knowledge graphs includes disease data (a disease database). - paras 114, 153-154, 170-171, 240-241, 355-356, 377; FIG 1) Regarding Claim 3, Gnanasambandam, Wixon, Salazar, Yuan, Johnson and Wishart disclose all the limitations above and further disclose the following limitations: The method of claim 1, further comprising training knowledge graph embeddings based on the knowledge graph, (Gnanasambandam discloses one or more machine learning models that may be trained to generate one or more knowledge graphs (training knowledge graph embeddings), each pertaining to a particular medical condition. The one or more machine learning models may be trained to transform input unstructured data (e.g., patient notes) into cognified data (training knowledge graph embeddings) using the knowledge graph (based on the knowledge graph) and the logical structure. – paras 157-159, 388) receiving new patient data, and generating the healthcare recommendation based on the knowledge graph embeddings and the new patient data. (Gnanasambandam discloses that the knowledge graph and the logical structure may be generated and updated continuously or on a periodic basis by an artificial intelligence engine with evidence-based guidelines, physician research, patient notes in EMRs, physician feedback, and so forth (receiving new patient data). The artificial intelligence engine trains one or more machine learning models to generate one or more knowledge graphs (based on the knowledge graph embeddings) so that cognified data such as recommendations or care plans may then be generated (generating the healthcare recommendation). Updating the knowledge graph indicates that the care plan may also be updated. – paras 114, 158-159, 272) Regarding Claim 4, Gnanasambandam, Wixon, Salazar, Yuan, Johnson and Wishart disclose all the limitations above and further disclose the following limitations: The method of claim 1, further comprising updating the knowledge graph with user feedback and user behavior regarding the healthcare recommendations, (Gnanasambandam discloses updating the knowledge graphs (updating the knowledge graph) based on physician feedback and patient notes. The feedback may include information pertaining to whether or not the cognified data (the healthcare recommendations) is accurate for the patient and/or whether the diagnosis generated using the cognified data is accurate (user feedback and user behavior regarding the healthcare recommendations). – paras 114, 118-119, 161) and ranking subsequent healthcare recommendations based on the updated knowledge graph. (Gnanasambandam discloses that the health related information associated with the remaining nodes in the knowledge graph may be distributed to the computing device of the patient at different respective times. In some embodiments, the health related information to be provided and/or the times at which the health related information is provided may be selected based on relevancy to a stage of the medical condition of the patient (ranking subsequent healthcare recommendations). – paras 122, 305) Regarding Claim 5, Gnanasambandam, Wixon, Salazar, Yuan, Johnson and Wishart disclose all the limitations above and further disclose the following limitations: The method of claim 1, wherein the healthcare recommendation includes one or more of a relationship between a patient and a medication, a relationship between a symptom and the diagnosis code, and a relationship between a healthcare provider and a disease. (Gnanasambandam discloses that the knowledge graph may pertain to any suitable medical condition and include numerous elements (e.g., health artifacts) represented by nodes and relationships between the nodes represented by edges. Knowledge graphs for particular patients (i.e., patient graphs) may be generated. For example, FIG. 57B depicts the patient graph for a particular user (a patient) having the condition Type 2 Diabetes Mellitus and shows an edge representing a relationship between the “Type 2 Diabetes Mellitus” node and the “diabetes medicine” node (relationship between a patient and a medication – paras 532-534, 537). – paras 219, 523, 532-534, 537) Regarding Claim 6, Gnanasambandam, Wixon, Salazar, Yuan, Johnson and Wishart disclose all the limitations above and further disclose the following limitations: The method of claim 1, further comprising updating the knowledge graph to include entities relating plain language terminology to medical terminology, (Gnanasambandam discloses that the knowledge graph may be updated (updating the knowledge graph) by an artificial intelligence engine with evidence-based guidelines, physician research, patient notes in EMRs, physician feedback, and so forth. The knowledge graph pertains to ontological data of a medical condition. FIG. 5 shows an exemplary knowledge graph containing different health artifacts (i.e., nodes) (entities) and relationships between the health artifacts (entities relating). Some of the artifacts include “Type 2 Diabetes Mellitus”, “Diabetic Neuropathy”, “Diabetic Retinopathy”, etc. (medical terminology), as well as “being active”, “healthy eating”, “overweight”, etc. (plain language terminology). – paras 114, 265-267; FIG. 5) and performing a search responsive to a user query including the plain language terminology for one or more of healthcare providers and symptoms with the knowledge graph. (The broadest reasonable interpretation includes alternative form and therefore only a citation to symptoms with the knowledge graph is provided) (Gnanasambandam discloses that a user can search for symptoms (symptoms with the knowledge graph.) and the cognitive intelligence platform processes the natural language (plain language terminology) to provide the content associated with the entered search query (performing a search responsive to a user query). – paras 494; FIG. 49) Claims 7-20 are rejected under 35 U.S.C. 103 as being unpatentable over Gnanasambandam et al. (US 20220391270), in view of Wixon (Wixon, C. (2019, July 10). Transforming Health Information Technology with a knowledge graph. Graph Database & Analytics. https://neo4j.com/blog/healthcare/transforming-health-information-technology-knowledge-graph/), in view of Salazar et al. (US 20180218126), in view of Johnson et al. (Johnson, A. E. W., Pollard, T. J., Shen, L., Lehman, L. H., Feng, M., Ghassemi, M., Moody, B., Szolovits, P., Anthony Celi, L., & Mark, R. G. (2016, May 24). Mimic-III, a freely accessible Critical Care Database. Nature News. https://www.nature.com/articles/sdata201635), further in view of Wishart et al. (Wishart DS, Knox C, Guo AC, Shrivastava S, Hassanali M, Stothard P, Chang Z, Woolsey J. DrugBank: a comprehensive resource for in silico drug discovery and exploration. Nucleic Acids Res. 2006 Jan 1;34(Database issue):D668-72. doi: 10.1093/nar/gkj067. PMID: 16381955; PMCID: PMC1347430.). Regarding Claim 7, Gnanasambandam discloses the following limitations: A non-transitory computer-readable storage medium including an executable program stored thereon, the program configured to cause a computer processor to: (Gnanasambandam discloses non-transitory computer-readable medium storing instructions that, when executed, cause a processing device to execute the steps disclosed. – para 5) receive medical data from a plurality of data sources… (Gnanasambandam discloses aggregating patient data across multiple health information technology resources and that the knowledge cloud 106 is configured to receive the data (extracting medical data) from various sources and entities (from a plurality of data sources) and integrate the data in a database. – paras 2, 168, 154) transform the received medical data into a different structure; wherein transformation of the received data include conversion of relations encoded in the medical data in relational database structures into entities and edges or links therebetween; (Gnanasambandam discloses one or more machine learning models generating one or more knowledge graphs where the predicates and individual elements may be generated based on data that is input to the artificial intelligence engine (transform the received medical data into a different structure) and the generated knowledge graph pertains to any suitable medical condition including numerous elements represented by nodes and relationships between the nodes represented by edges (conversion of relations encoded in the medical data in relational database structures into entities and edges or links therebetween) (e.g., FIG 5 shows an exemplary knowledge graph). The knowledge graphs may be generated with evidence-based guidelines, physician research, patient notes in EMRs, physician feedback, and so forth (transform the received medical data into a different structure). – paras 114, 158, 272, 523; FIGs. 5 and 56) load the transformed data into a knowledge graph; (Gnanasambandam discloses generating the knowledge graph using the individual elements generated based on the data input(s). – para 114) extract healthcare insights from the knowledge graph; (Gnanasambandam discloses using the knowledge graphs to generate cognified data (extract healthcare insights) including one or more insights not present in the unstructured data. – paras 117, 159-160) and output, to a user device for display to a user, a healthcare recommendation based on the healthcare insights; (Gnanasambandam discloses outputting a generated care plan (a healthcare recommendation) based on the cognitive data via a user interface such as in FIG. 57D. – paras 539-540; FIGs. 57D and 58) wherein the received medical data does not indicate symptoms in layman's terms. (Gnanasambandam discloses that the service provider 112 collects and generates data associated with the patient or the user, including health records (the received medical data) that include doctor's notes about the patient and prescriptions (does not indicate symptoms in layman's terms), billing records (does not indicate symptoms in layman's terms), and insurance records (does not indicate symptoms in layman's terms). The service provider 112, using a computing device (e.g., a desktop computer or a tablet), provides the data associated with the user (the received medical data) to the cognitive intelligence platform 102, and more specifically the knowledge cloud 106. – para 169) Gnanasambandam does not disclose the following limitations met by Wixon: wherein the knowledge graph includes the plurality of nodes and edges that correspond to a diagnosis code; (Wixon teaches a knowledge graph that contains nodes that are connected to each other by lines (i.e., edges) (plurality of nodes and edges) and are representative of symptoms and related ICD diagnosis codes (a diagnosis code). - page 7 and both images thereon) wherein the diagnosis code is associated with multiple symptom entities via multiple diagnosis code-symptom edges; (Wixon teaches creating a knowledge graph using a patients electronic health records. The nodes are connected to each other by lines (i.e., the edges) are representative of symptoms and related ICD diagnosis codes (the diagnosis code is associated with multiple symptom entities via multiple diagnosis code-symptom edges). Each node has a direct relationship to another node and a node may contain attributes such as symptoms and may also contain an appropriate ICD code. – page 7 and both images thereon) It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to have modified generating one or more knowledge graphs as disclosed by Gnanasambandam to incorporate using ICD codes as taught by Wixon in order to improve outcomes and reduce costs (see Wixon page 11 ‘conclusion’). Gnanasambandam and Wixon do not disclose the following limitations met by Salazar: wherein the multiple symptom entities are associated with multiple layman entities that indicates symptoms in layman's terms; (Salazar teaches generating a knowledge graph of nodes related to symptoms such as “heartburn” and “nausea/vomiting” (multiple symptom entities) and connected edges (are associated with) to other words/phrases such as “throat hurts”, “upset stomach”, etc. (multiple layman entities that indicates symptoms in layman's terms). For example, “throw up” 720 (layman's terms) is often colloquially used to mean “vomit” (i.e., “Nausea/Vomiting” 704) (symptom entities). – paras 4, 54-55; FIG. 7) wherein constructing the knowledge graph includes detecting and classifying relationships between the multiple symptom entities and multiple layman entities; (Salazar teaches that the edges of the knowledge graph may be weighted (detecting and classifying relationships between the multiple symptom entities and multiple layman entities) based on strength (based on frequency of co-occurrence) of the connection between the vertices 702-730. – para 56; FIG. 7) It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to have further modified generating one or more knowledge graphs as disclosed by Gnanasambandam to incorporate relationships between symptoms and more commonly used terms related to those symptoms as taught by Salazar in order that healthcare professionals can increase the number of patients they can assist, ensure high-quality care, and reduce operational costs (see Salazar para 3). Gnanasambandam, Wixon and Salazar do not disclose the following limitations met by Johnson: a plurality of data sources… that include a disease database…; wherein the disease database includes a disease dataset that maps diagnostic codes to related terms; (Johnson teaches that MIMIC-III database (a disease database) contains a look-up table for cross referencing concept identifiers, for example ICD codes (a disease dataset that maps diagnostic codes), with associated labels (to related terms). – page 4, table 3) a plurality of data sources… that include…a patient database…; wherein the patient database includes de-identified data that includes procedure codes and diagnostic codes; (Johnson teaches that the MIMIC-III database contains deidentified patient data (includes de-identified data) such as procedure codes and diagnostic codes (includes procedure codes and diagnostic codes). – abstract; page 6, ‘Deidentification’) (Examiner notes that this known database is also described in Applicant’s specification in para 50 to contain deidentified patient data including procedure and diagnostic codes). It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to have further modified generating one or more knowledge graphs as disclosed by Gnanasambandam to incorporate the use of the MIMIC-III database as taught by Johnson in order to reproduce and improve clinical studies in ways that would not otherwise be possible (see Page 2, ‘Background & Summary’ para 3). Gnanasambandam, Wixon, Salazar and Johnson do not disclose the following limitations met by Wishart: a plurality of data sources… that include…a medicine database; wherein the medicine database includes detailed drug data; (Wishart teaches DrugBank (a medicine database) which includes detailed drug (includes detailed drug data). – abstract) (Examiner notes that the Applicant’s specification describes this DrugBank to include detailed drug information in para 50) It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to have further modified generating one or more knowledge graphs as disclosed by Gnanasambandam to incorporate using detailed drug data from a database such as DrugBank as taught by Wishart in order to aid medical researchers (see ‘Introduction’ page 2). Regarding Claim 8, Gnanasambandam, Wixon, Salazar, Johnson and Wishart disclose all the limitations above and further disclose the following limitations: The non-transitory computer-readable storage medium of claim 7, wherein the heterogeneous plurality of data sources includes a provider data source, a patient data source, a medicine data source, a disease database, and at least one medical ontology data source. (Gnanasambandam discloses using medical subject matter ontology data (medical ontology data source – paras 240-241, 355-356),a service provider source (provider data source), a micro survey source from a user device (a patient data source), a facility source such as a hospital, clinic, trauma center, etc., (a medicine data source), as well as evidence-based guidelines, physician research, patient notes in EMRs, physician feedback, etc., in order to generate the knowledge graphs which may represent knowledge of a disease and the knowledge graph may include a set of concepts pertaining to the disease obtained from the known health related information and also includes relationships between the set of concepts. This indicates that the used data to generate the knowledge graphs includes disease data (a disease database). - paras 114, 153-154, 170-171, 240-241, 355-356, 377; FIG 1) Regarding Claim 9, Gnanasambandam, Wixon, Salazar, Yuan, Johnson and Wishart disclose all the limitations above and further disclose the following limitations: The non-transitory computer-readable storage medium of claim 7, wherein the program is further configured to cause the computer processor to train knowledge graph embeddings based on the knowledge graph, (Gnanasambandam discloses one or more machine learning models that may be trained to generate one or more knowledge graphs (training knowledge graph embeddings), each pertaining to a particular medical condition. The one or more machine learning models may be trained to transform input unstructured data (e.g., patient notes) into cognified data (training knowledge graph embeddings) using the knowledge graph (based on the knowledge graph) and the logical structure. – paras 157-159, 388) receive new patient data, and generate the healthcare recommendation based on the knowledge graph embeddings and the new patient data. (Gnanasambandam discloses that the knowledge graph and the logical structure may be generated and updated continuously or on a periodic basis by an artificial intelligence engine with evidence-based guidelines, physician research, patient notes in EMRs, physician feedback, and so forth (receiving new patient data). The artificial intelligence engine trains one or more machine learning models to generate one or more knowledge graphs (based on the knowledge graph embeddings) so that cognified data such as recommendations or care plans may then be generated (generating the healthcare recommendation). Updating the knowledge graph indicates that the care plan may also be updated. – paras 114, 158-159, 272) Regarding Claim 10, Gnanasambandam, Wixon, Salazar, Yuan, Johnson and Wishart disclose all the limitations above and further disclose the following limitations: The non-transitory computer-readable storage medium of claim 7, wherein the program is further configured to cause the computer processor to update the knowledge graph with user feedback and user behavior regarding the healthcare recommendations, (Gnanasambandam discloses updating the knowledge graphs (updating the knowledge graph) based on physician feedback and patient notes. The feedback may include information pertaining to whether or not the cognified data (the healthcare recommendations) is accurate for the patient and/or whether the diagnosis generated using the cognified data is accurate (user feedback and user behavior regarding the healthcare recommendations). – paras 114, 118-119, 161) and rank subsequent healthcare recommendations based on the updated knowledge graph. (Gnanasambandam discloses that the health related information associated with the remaining nodes in the knowledge graph may be distributed to the computing device of the patient at different respective times. In some embodiments, the health related information to be provided and/or the times at which the health related information is provided may be selected based on relevancy to a stage of the medical condition of the patient (ranking subsequent healthcare recommendations). – paras 122, 305) Regarding Claim 11, Gnanasambandam, Wixon, Salazar, Yuan, Johnson and Wishart disclose all the limitations above and further disclose the following limitations: The non-transitory computer-readable storage medium of claim 7, wherein the healthcare insights include one or more of newly-identified edges between entities in the knowledge graph, including one or more of a relationship between a patient and a medication, a relationship between a symptom and a diagnostic code, and a relationship between a healthcare provider and a disease. (Gnanasambandam discloses that the knowledge graph may pertain to any suitable medical condition and include numerous elements (e.g., health artifacts) represented by nodes and relationships between the nodes represented by edges. Knowledge graphs for particular patients (i.e., patient graphs) may be generated. For example, FIG. 57B depicts the patient graph for a particular user (a patient) having the condition Type 2 Diabetes Mellitus and shows an edge representing a relationship between the “Type 2 Diabetes Mellitus” node and the “diabetes medicine” node (relationship between a patient and a medication – paras 532-534, 537). Further, the cognitive agent 110 asserts non-existent concepts or relations to form new knowledge (newly- identified edges between entities in the knowledge graph – para 219). – paras 219, 523, 532-534, 537) Regarding Claim 12, Gnanasambandam, Wixon, Salazar, Yuan, Johnson and Wishart disclose all the limitations above and further disclose the following limitations: The non-transitory computer-readable storage medium of claim 7, wherein the program is further configured to cause the computer processor to update the knowledge graph to include entities relating plain language terminology to medical terminology, (Gnanasambandam discloses that the knowledge graph may be updated (updating the knowledge graph) by an artificial intelligence engine with evidence-based guidelines, physician research, patient notes in EMRs, physician feedback, and so forth. The knowledge graph pertains to ontological data of a medical condition. FIG. 5 shows an exemplary knowledge graph containing different health artifacts (i.e., nodes) (entities) and relationships between the health artifacts (entities relating). Some of the artifacts include “Type 2 Diabetes Mellitus”, “Diabetic Neuropathy”, “Diabetic Retinopathy”, etc. (medical terminology), as well as “being active”, “healthy eating”, “overweight”, etc. (plain language terminology). – paras 114, 265-267; FIG. 5) and perform a search responsive to a user query including the plain language terminology for one or more of healthcare providers and symptoms with the knowledge graph. (The broadest reasonable interpretation includes alternative form and therefore only a citation to symptoms with the knowledge graph is provided) (Gnanasambandam discloses that a user can search for symptoms (symptoms with the knowledge graph.) and the cognitive intelligence platform processes the natural language (plain language terminology) to provide the content associated with the entered search query (performing a search responsive to a user query). – paras 494; FIG. 49) Regarding Claim 13, Gnanasambandam discloses the following limitations: A system, comprising: a user device configured for a user; and a server communicatively coupled to a client device, the server configured with executable instructions in non-transitory memory of the server that when executed cause a processor of the server to: (Gnanasambandam discloses a system comprising a memory device storing instructions and a processing device, communicatively coupled to the memory device, executing the instructions is disclosed. The individual computing devices can represent any form of a computing device such as a server device. – paras 5, 126, 152; FIG. 1) extract medical data from a plurality of data sources…; (Gnanasambandam discloses aggregating patient data across multiple health information technology resources and that the knowledge cloud 106 is configured to receive the data (extracting medical data) from various sources and entities (from a plurality of data sources) and integrate the data in a database. – paras 2, 168, 154) convert the extracted medical data into a different format; (Gnanasambandam discloses one or more machine learning models generating one or more knowledge graphs where the predicates and individual elements may be generated based on data that is input to the artificial intelligence engine (convert the extracted medical data into a different format) and the generated knowledge graph pertains to any suitable medical condition including numerous elements represented by nodes and relationships between the nodes represented by edges (e.g., FIG 5 shows an exemplary knowledge graph). The knowledge graphs may be generated with evidence-based guidelines, physician research, patient notes in EMRs, physician feedback, and so forth. – paras 114, 158, 272, 523; FIGs. 5 and 56) load the converted data into a knowledge graph structure that is stored in the server; (Gnanasambandam discloses generating the knowledge graph using the individual elements generated based on the data input(s) (load the converted data into a knowledge graph structure). An autonomous multipurpose application may execute in a cognitive intelligence platform may be implemented as one or more application programming interfaces (API) executing via one or more computing devices (e.g., servers) and includes at least one processor, at least one memory, and at least one storage (e.g., a hard drive, a solid-state storage device, a mass storage device, and a remote storage device). The knowledge graph may be generated for each known medical condition and stored by the cognitive intelligence platform 102 (stored in the server). – para 114, 126, 152, 272) automatically generate a healthcare insight from the knowledge graph structure; (Gnanasambandam discloses using the knowledge graphs (from the knowledge graph structure) to generate cognified data (automatically generate a healthcare insight) including one or more insights not present in the unstructured data. – paras 117, 159-160) transmit a healthcare recommendation to the user device for display to the user, wherein the healthcare recommendation is generated based on the healthcare insight; (Gnanasambandam discloses that the care plan (a healthcare recommendation) may be transmitted to the user device for presentation (transmit to the user device for display to the user) in the patient viewer, the clinic viewer, and/or the administrator viewer. The generated and transmitted care plan is based on the cognitive data (generated based on the healthcare insight) and displayed via a user interface such as in FIG. 57D. – paras 143, 539-540; FIGs. 57D and 58) wherein the extracted medical data does not indicate symptoms in layman's terms; (Gnanasambandam discloses that the service provider 112 collects and generates data associated with the patient or the user, including health records (the extracted medical data) that include doctor's notes about the patient and prescriptions (does not indicate symptoms in layman's terms), billing records (does not indicate symptoms in layman's terms), and insurance records (does not indicate symptoms in layman's terms). The service provider 112, using a computing device (e.g., a desktop computer or a tablet), provides the data associated with the user (the extracted medical data) to the cognitive intelligence platform 102, and more specifically the knowledge cloud 106. – para 169) wherein the healthcare insight includes one or more of newly-identified edges between multiple…entities in the knowledge graph structure. (Gnanasambandam discloses that the cognitive agent asserts non-existent concepts or relations to form new knowledge (one or more of newly-identified edges between the multiple entities in the knowledge graph structure). The knowledge graphs and/or matrices may be updated continuously or on a periodic basis using subject data pertaining to the medical conditions received from the trusted sources. – paras 219, 272, 380) Gnanasambandam does not disclose the following limitations met by Wixon: wherein the knowledge graph structure includes a plurality of nodes and edges that correspond to a diagnosis code; (Wixon teaches a knowledge graph (the knowledge graph structure) that contains nodes that are connected to each other by lines (i.e., edges) (plurality of nodes and edges) and are representative of symptoms and related ICD diagnosis codes (a diagnosis code). - page 7 and both images thereon) wherein the diagnosis code is associated with multiple symptom entities via multiple diagnosis code-symptom edges; (Wixon teaches creating a knowledge graph using a patients electronic health records. The nodes are connected to each other by lines (i.e., the edges) are representative of symptoms and related ICD diagnosis codes (the diagnosis code is associated with multiple symptom entities via multiple diagnosis code-symptom edges). Each node has a direct relationship to another node and a node may contain attributes such as symptoms and may also contain an appropriate ICD code. – page 7 and both images thereon) It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to have modified generating one or more knowledge graphs as disclosed by Gnanasambandam to incorporate using ICD codes as taught by Wixon in order to improve outcomes and reduce costs (see Wixon page 11 ‘conclusion’). Gnanasambandam and Wixon do not disclose the following limitations met by Salazar: wherein the multiple symptom entities are associated with multiple layman entities that indicates symptoms in layman's terms (Salazar teaches generating a knowledge graph of nodes related to symptoms such as “heartburn” and “nausea/vomiting” (multiple symptom entities) and connected edges (are associated with) to other words/phrases such as “throat hurts”, “upset stomach”, etc. (multiple layman entities that indicates symptoms in layman's terms). For example, “throw up” 720 (layman's terms) is often colloquially used to mean “vomit” (i.e., “Nausea/Vomiting” 704) (symptom entities). – paras 4, 54-55; FIG. 7) …one or more of newly-identified edges between multiple layman entities in the knowledge graph structure. (Salazar teaches generating a knowledge graph that associates mundane language (i.e., from the unstructured conversations) (the multiple layman entities) with medical symptoms determined by healthcare professionals by using unstructured conversations. Conversations may be received in real-time and the system may update its analysis (one or more of newly-identified edges between the multiple layman entities in the knowledge graph structure) with any newly received portions of the conversation. – paras 4, 41, 54) It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to have further modified generating one or more knowledge graphs as disclosed by Gnanasambandam to incorporate relationships between symptoms and more commonly used terms related to those symptoms as taught by Salazar in order that healthcare professionals can increase the number of patients they can assist, ensure high-quality care, and reduce operational costs (see Salazar para 3). Gnanasambandam, Wixon and Salazar do not disclose the following limitations met by Johnson: a plurality of data sources… that include a disease database…; wherein the disease database includes a disease dataset that maps diagnostic codes to related terms; (Johnson teaches that MIMIC-III database (a disease database) contains a look-up table for cross referencing concept identifiers, for example ICD codes (a disease dataset that maps diagnostic codes), with associated labels (to related terms). – page 4, table 3) a plurality of data sources… that include…a patient database…; wherein the patient database includes de-identified data that includes procedure codes and diagnostic codes; (Johnson teaches that the MIMIC-III database contains deidentified patient data (includes de-identified data) such as procedure codes and diagnostic codes (includes procedure codes and diagnostic codes). – abstract; page 6, ‘Deidentification’) (Examiner notes that this known database is also described in Applicant’s specification in para 50 to contain deidentified patient data including procedure and diagnostic codes). It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to have further modified generating one or more knowledge graphs as disclosed by Gnanasambandam to incorporate the use of the MIMIC-III database as taught by Johnson in order to reproduce and improve clinical studies in ways that would not otherwise be possible (see Page 2, ‘Background & Summary’ para 3). Gnanasambandam, Wixon, Salazar and Johnson do not disclose the following limitations met by Wishart: a plurality of data sources… that include…a medicine database; wherein the medicine database includes detailed drug data; (Wishart teaches DrugBank (a medicine database) which includes detailed drug (includes detailed drug data). – abstract) (Examiner notes that the Applicant’s specification describes this DrugBank to include detailed drug information in para 50) It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to have further modified generating one or more knowledge graphs as disclosed by Gnanasambandam to incorporate using detailed drug data from a database such as DrugBank as taught by Wishart in order to aid medical researchers (see ‘Introduction’ page 2). Regarding Claim 14, Gnanasambandam, Wixon, Salazar, Yuan, Johnson and Wishart disclose all the limitations above and further disclose the following limitations: The system of claim 13, wherein the plurality of data sources includes at least one medical ontology data source, (Gnanasambandam discloses using medical subject matter ontology data (medical ontology data source) to generate the knowledge graphs, which includes a set of concepts and categories in a subject matter or domain, where the set of concepts and categories capture properties and relationships between the concepts and categories. – paras 240-241, 355-356) and the plurality of data sources are communicatively coupled to the server via a network. (Gnanasambandam discloses that the cognitive intelligence platform and the various data sources are communicatively coupled via a network. – paras 152, 167; FIG. 1) Regarding Claim 15, Gnanasambandam, Wixon, Salazar, Yuan, Johnson and Wishart disclose all the limitations above and further disclose the following limitations: The system of claim 13, wherein the server is further configured with executable instructions in non-transitory memory of the server that when executed cause a processor of the server to train knowledge graph embeddings based on the knowledge graph structure, (Gnanasambandam discloses one or more machine learning models that may be trained to generate one or more knowledge graphs (training knowledge graph embeddings), each pertaining to a particular medical condition. The one or more machine learning models may be trained to transform input unstructured data (e.g., patient notes) into cognified data (training knowledge graph embeddings) using the knowledge graph (based on the knowledge graph structure) and the logical structure. – paras 157-159, 388) receive new patient data, and generate the healthcare recommendation based on the knowledge graph embeddings and the new patient data. (Gnanasambandam discloses that the knowledge graph and the logical structure may be generated and updated continuously or on a periodic basis by an artificial intelligence engine with evidence-based guidelines, physician research, patient notes in EMRs, physician feedback, and so forth (receiving new patient data). The artificial intelligence engine trains one or more machine learning models to generate one or more knowledge graphs (based on the knowledge graph embeddings) so that cognified data such as recommendations or care plans may then be generated (generating the healthcare recommendation). Updating the knowledge graph indicates that the care plan may also be updated. – paras 114, 158-159, 272) Regarding Claim 16, Gnanasambandam, Wixon, Salazar, Yuan, Johnson and Wishart disclose all the limitations above and further disclose the following limitations: The system of claim 13, wherein the server is further configured with executable instructions in non-transitory memory of the server that when executed cause a processor of the server to update the knowledge graph structure with user feedback and user behavior regarding the healthcare recommendations, (Gnanasambandam discloses updating the knowledge graphs (update the knowledge graph structure) based on physician feedback and patient notes. The feedback may include information pertaining to whether or not the cognified data (the healthcare recommendations) is accurate for the patient and/or whether the diagnosis generated using the cognified data is accurate (user feedback and user behavior regarding the healthcare recommendations). – paras 114, 118-119, 161) and rank subsequent healthcare recommendations based on the updated knowledge graph. (Gnanasambandam discloses that the health related information associated with the remaining nodes in the knowledge graph may be distributed to the computing device of the patient at different respective times. In some embodiments, the health related information to be provided and/or the times at which the health related information is provided may be selected based on relevancy to a stage of the medical condition of the patient (ranking subsequent healthcare recommendations). – paras 122, 305) Regarding Claim 17, Gnanasambandam, Wixon, Salazar, Yuan, Johnson and Wishart disclose all the limitations above and further disclose the following limitations: The system of claim 13, wherein the healthcare insights include one or more of newly- identified edges between entities in the knowledge graph structure, including one or more of a relationship between a patient and a medication, a relationship between a symptom and the diagnosis code, and a relationship between a healthcare provider and a disease. (Gnanasambandam discloses that the knowledge graph may pertain to any suitable medical condition and include numerous elements (e.g., health artifacts) represented by nodes and relationships between the nodes represented by edges. Knowledge graphs for particular patients (i.e., patient graphs) may be generated. For example, FIG. 57B depicts the patient graph for a particular user (a patient) having the condition Type 2 Diabetes Mellitus and shows an edge representing a relationship between the “Type 2 Diabetes Mellitus” node and the “diabetes medicine” node (relationship between a patient and a medication – paras 532-534, 537). Further, the cognitive agent 110 asserts non-existent concepts or relations to form new knowledge and the knowledge graphs may be updated continuously or on a periodic basis using subject data pertaining to the medical conditions received from the trusted sources (newly- identified edges between entities in the knowledge graph structure). – paras 219, 272, 523, 532-534, 537) Regarding Claim 18, Gnanasambandam, Wixon, Salazar, Yuan, Johnson and Wishart disclose all the limitations above and further disclose the following limitations: The system of claim 13, wherein the server is further configured with executable instructions in non-transitory memory of the server that when executed cause a processor of the server to update the knowledge graph structure to include entities relating plain language terminology to medical terminology, (Gnanasambandam discloses that the knowledge graph may be updated (update the knowledge graph structure) by an artificial intelligence engine with evidence-based guidelines, physician research, patient notes in EMRs, physician feedback, and so forth. The knowledge graph pertains to ontological data of a medical condition. FIG. 5 shows an exemplary knowledge graph containing different health artifacts (i.e., nodes) (entities) and relationships between the health artifacts (entities relating). Some of the artifacts include “Type 2 Diabetes Mellitus”, “Diabetic Neuropathy”, “Diabetic Retinopathy”, etc. (medical terminology), as well as “being active”, “healthy eating”, “overweight”, etc. (plain language terminology). – paras 114, 265-267; FIG. 5) and perform a search responsive to a user query including the plain language terminology for one or more of healthcare providers and symptoms with the knowledge graph structure. (Gnanasambandam discloses that a user can search for symptoms (symptoms with the knowledge graph structure.) and the cognitive intelligence platform processes the natural language (plain language terminology) to provide the content associated with the entered search query (performing a search responsive to a user query). – para 494; FIG. 49) Regarding Claim 19, Gnanasambandam, Wixon, Salazar, Yuan, Johnson and Wishart disclose all the limitations above and further disclose the following limitations: The system of claim 18, wherein the server is further configured with executable instructions in non-transitory memory of the server that when executed cause a processor of the server to transmit search results of the search obtained based on the knowledge graph structure to the user device for display to the user in a graphical user interface. (Gnanasambandam discloses an example of a user interface (display to the user in a graphical user interface) that allows for searching content and provides recommended content (transmit search results of the search) based on a condition of the user (obtained based on the knowledge graph structure). – paras 61, 164, 187, 494; FIG. 49) Regarding Claim 20, Gnanasambandam, Wixon, Salazar, Yuan, Johnson and Wishart disclose all the limitations above and further disclose the following limitations: The system of claim 13, wherein the server is further configured with executable instructions in non-transitory memory of the server that when executed cause a processor of the server to iteratively update the knowledge graph structure with new and additional data from the heterogeneous plurality of data sources. (Gnanasambandam discloses updating the knowledge graphs continuously or on a periodic basis (iteratively update the knowledge graph structure) by an artificial intelligence engine with evidence-based guidelines, physician research, patient notes in EMRs, physician feedback, and so forth (new and additional data from the heterogeneous plurality of data sources). For example, additional clinical trials may lead to new discoveries about particular medical condition treatments (new data), which may be used to update the knowledge graphs. – paras 114, 272) Relevant Prior Art of Record Not Currently Being Applied The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Poulin et al. (US 20090265316) discloses utilizing a database that receives and stores de-identified EMR data. The data may include information including the diagnosis. A medical professional may wish to access system 10 for diagnostic purposes. For example, a doctor may wish to access system 10 to retrieve data regarding treatment for a patient in a certain age or race demographic or with a specific ailment. Response to Arguments Regarding rejections under 35 USC § 101 to Claims 1-20, Applicant’s arguments have been fully considered, however, not all are persuasive. The rejection has been updated in light of latest amendments. Applicant argues: (a) Applicant submits that the elements in amended claim 1 are not directed to a judicial exception. To elaborate, amended claim 1 now recites the feature in which "constructing the knowledge graph includes using a neural language model that maps the extracted data to symptom entities in the knowledge graph." As such, the new features recited in amended claim 1 provide tangible improvements to a technical solution, even if the features were directed to the judicial exception (a point which Applicant is not conceding). (p. 14). Regarding (a), Examiner respectfully disagrees. While the limitation of regarding the use of a neural language model is interpreted as an additional element, it was found to amount to no more than mere instructions to apply the exceptions using a generic computer component. MPEP 2106.04(d)(I) states that merely reciting the words "apply it" (or an equivalent) with the judicial exception, or merely including instructions to implement an abstract idea on a computer, or merely using a computer as a tool to perform an abstract idea cannot integrate a judicial exception into a practical application. See updated rejection above. (b) Furthermore, the abovementioned features in the eligible claim of Example 38 are similar to the features in which "constructing the knowledge graph includes using a neural language model that maps the extracted data to symptom entities in the knowledge graph" and the steps of "automatically identifying one or more new connections within the knowledge graph with a machine learning model; [and] generating a healthcare recommendation based on the one or more new connections," which are now recited in amended claim 1. The similarities between the eligible claim of Example 38 and amended claim 1 further bolster Applicant's assertion that the new features move the method outside of the judicial exception. (p.14). Regarding (b), Examiner respectfully disagrees. Examiner notes that Example 38 was found as not reciting a judicial exception, and therefore evaluating the claim under Steps 2A and 2B were not performed. This scenario is not applicable to the Applicants claims because a judicial exception is recited and thus an evaluation of the identified additional elements under steps 2A and 2B is required. Per MPEP 2106.04(a)(2)(III) a claimed invention may encompass an abstract idea if it represents concepts that can be practically performed in the human mind (with or without the aid of pencil and paper or a computer) such as observations, evaluations, judgments, and opinions. Under the broadest reasonable interpretation, the identified features of the claim encompass mental process because it represents collecting and analyzing data in order to provide a health recommendation (see Spec. Para. 4). Regarding the Applicants argued limitations, other than the use of the neural language model and machine learning model, nothing in the claim precludes the steps from practically being performed in the mind. Because the identified features of the claim can be performed in the human mind, the claims are directed to an abstract idea. MPEP 2106.04(a)(2)(II) states that a claimed invention is directed to certain methods of organizing human activity if the identified claim elements contain limitations that encompass fundamental economic behavior or relationships or interactions between people (including social activities, teaching, and following rules or instructions). The Examiner submits that the identified claim elements represent a series of rules or instructions that a person or persons, with or without the aid of a computer, would follow to analyze data and provide a health recommendation. The Applicant has not pointed to anything in the claims that fall outside of this characterization. The Examiner notes that certain “method[s] of organizing human activity” includes a person’s interaction with a computer (see MPEP 2106.04(a)(2)(II)). Thus, the claimed invention is directed to an abstract idea. Further, Examiner notes that the identified additional elements of the use of the neural language model and machine learning model were found to amount to no more than mere instructions to apply the exceptions using a generic computer component (see MPEP 2106.04(d)(I)). (c) Applicant submits that the elements in amended claim 7 are outside the judicial exception and integrate the alleged judicial exception into a practical application. Specifically, amended claim 7 now recites "transform the received medical data into a different structure; wherein transformation of the received data include conversion of relations encoded in the medical data in relational database structures into entities and edges or links therebetween; [and] load the transformed data into a knowledge graph." Specifically, the conversion of relations encoded in the medical data in relational database structures into entities and edges or links therebetween allows the medical data to be more effectively and efficiently interpreted. Therefore, the features in amended claim 7 provide a technical benefit to the system, which move the alleged judicial acceptation into a practical application. (p. 15). Regarding (c), Examiner respectfully disagrees. MPEP 2106.04(d)(II) states that Examiners evaluate integration into a practical application by: (1) identifying whether there are any additional elements recited in the claim beyond the judicial exception(s); and (2) evaluating those additional elements individually and in combination to determine whether they integrate the exception into a practical application, using one or more of the considerations introduced in subsection I supra (emphasis added). First, the limitations of “transform the received medical data into a different structure; wherein transformation of the received data include conversion of relations encoded in the medical data in relational database structures into entities and edges or links therebetween” are interpreted to be part of the abstract idea and therefore cannot provide a practical application. Second, the limitation of “load the transformed data into a knowledge graph” has been identified as an additional element, however it was found to amount to no more than mere instructions to apply the exceptions using a generic computer component which. MPEP 2106.04(d)(I) states that merely reciting the words "apply it" (or an equivalent) with the judicial exception, or merely including instructions to implement an abstract idea on a computer, or merely using a computer as a tool to perform an abstract idea cannot integrate a judicial exception into a practical application. (d) Specifically, the steps reproduced below in the eligible claim of Example 41 were found by the court to demonstrate the practical application of the claims: * receiving a plaintext word signal at the first computer terminal; * transforming the plaintext word signal to one or more message block word signals M A; and * encoding each of the message block word signals M A to produce a ciphertext word signal CA, whereby CA =M Ae (mod n). The similarities between these steps in the eligible claim of Example 41 and the features in amended claim 7 that involve "receive medical data from a plurality of data sources that include a disease database, a patient database, and a medicine database; transform the received medical data into a different structure; wherein transformation of the received data include conversion of relations encoded in the medical data in relational database structures into entities and edges or links therebetween; load the transformed data into a knowledge graph" strengthen Applicant's assertion that the new features provide tangible improvements and move the method into a practical application. (p. 15-16). Regarding (d), Examiner respectfully disagrees. The claim in Example 41 was found eligible because “the combination of additional elements use the mathematical formulas and calculations in a specific manner that sufficiently limits the use of the mathematical concepts to the practical application of transmitting the ciphertext word signal to a computer terminal over a communication channel. Thus, the mathematical concepts are integrated into a process that secures private network communications, so that a ciphertext word signal can be transmitted between computers of people who do not know each other or who have not shared a private key between them in advance of the message being transmitted.” (emphasis added). Here, Applicants claim, as currently recited, does not preclude the steps from being performed in the human mind; other than the additional elements of using various databases and loading the transformed data into a knowledge graph. However, these additional elements were found to amount to no more than mere instructions to apply the exceptions using a generic computer component which. MPEP 2106.04(d)(I) states that merely reciting the words "apply it" (or an equivalent) with the judicial exception, or merely including instructions to implement an abstract idea on a computer, or merely using a computer as a tool to perform an abstract idea cannot integrate a judicial exception into a practical application. Examiner notes that the limitations regarding the data transformation is recited in a way that, using broadest reasonable interpretation, may simply be changing/converting units, adjusting a scale, etc. which are abstract ideas. See updated rejection above. (e) In particular, the steps reproduced below in the eligible claim of Example 42 were found by the court to demonstrate the practical application of the claim: a) storing information in a standardized format about a patient's condition in a plurality of network-based non-transitory storage devices having a collection of medical records stored thereon; b) providing remote access to users over a network so any one of the users can update the information about the patient's condition in the collection of medical records in real time through a graphical user interface, wherein the one of the users provides the updated information in a non- standardized format dependent on the hardware and software platform used by the one of the users; and c) converting, by a content server, the non-standardized updated information into the standardized format. The similarities between the above steps the eligible claim of Example 42 and the features in amended claim 13 that involve "extract medical data from a plurality of data sources that include a disease database, a patient database, and a medicine database; wherein the disease database includes a disease dataset that maps diagnostic codes to related terms; wherein the patient database includes de-identified data that includes procedure codes and diagnostic codes; wherein the medicine database includes detailed drug data; convert the extracted medical data into a different format; [and] load the converted data into a knowledge graph structure that is stored in the server" support Applicant's assertion that the new features provide tangible improvements and move the method into a practical application. (p. 16-17). Regarding (e), Examiner respectfully disagrees. MPEP 2106.04(d) sates that one way in which a claimed abstract idea may be subject matter eligible under prong 2A2 is if the claimed invention solves a described technological problem. Example 42 is an illustration of this. In the case of Example 42, there is a described technical problem of medical record systems that store medical records in a hardware and/or software dependent format that makes it difficult to share updated patient information. This is a described technical problem, i.e., a problem caused by the technology, that the claimed invention is solving (a technical solution) thus integrating the abstract idea into a practical application. Examiner notes that the Applicant has not identified any technological problem that was caused by the technological environment to which the claims are confined and therefore a technical solution is also not present. At best, the problem(s) described in the as-filed disclosure are medical or administrative problems involving providing personalized health recommendations based on collected data. Therefore, the claimed invention does not integrate the abstract idea into a practical application like Example 42 because the claim does not recite a technical solution to a technical problem. Regarding rejections under 35 USC § 103 to Claims 1-20, Applicant’s arguments have been fully considered and are persuasive regarding the following newly added limitations; Claims 1, 7 and 13: a plurality of data sources that include a disease database, a patient database, and a medicine database; wherein the disease database includes a disease dataset that maps diagnostic codes to related terms; wherein the patient database includes de-identified data that includes procedure codes and diagnostic codes; wherein the medicine database includes detailed drug data; Claim 1: wherein constructing the knowledge graph includes using a neural language model that maps the extracted data to symptom entities in the knowledge graph; Therefore, the rejection has been withdrawn. However, upon further consideration, a new grounds of rejection necessitated by Applicant’s amendments is made in view of Yuan (US 20210375479), in view of Johnson et al. (NPL citation above) and further in view of Wishart et al. (NPL citation above), as per the rejection above. Further, Applicant arguments are not persuasive regarding the remaining newly added limitations. Applicant argues: (f) In view of the above, Gnanasambandam, Shah, and Salazar do not teach or suggest all of the features that are now recited in amended claims 1,7, and 13. For at least this reason, Applicant respectfully requests that the rejection under 35 U.S.C. 103 of claims 1-20 be withdrawn. (p. 19). Regarding (f), Examiner respectfully disagrees. The following newly added limitations are disclosed by Gnanasambandam: extracting medical data from a plurality of data sources…; automatically identifying one or more new connections within the knowledge graph with a machine learning model; generating a healthcare recommendation based on the one or more new connections; wherein the extracted medical data does not indicate symptoms in layman's terms. Gnanasambandam discloses aggregating patient data across multiple health information technology resources and that the knowledge cloud 106 is configured to receive the data (extracting medical data) from various sources and entities (from a plurality of data sources) and integrate the data in a database. Further, the knowledge graph 500 or the matrix may be generated for each known medical condition and stored by the cognitive intelligence platform 102. The knowledge graphs and/or matrices may be updated continuously or on a periodic basis using subject data pertaining to the medical conditions received from the trusted sources. For example, additional clinical trials may lead to new discoveries about particular medical condition treatments, which may be used to update the knowledge graphs and/or matrices (automatically identifying one or more new connections within the knowledge graph). Where the cognitive intelligence platform includes an AI engines, i.e., machine learning models (with a machine learning model). Gnanasambandam also discloses that the knowledge graphs and/or matrices may be updated (based on the one or more new connections) continuously or on a periodic basis using subject data pertaining to the medical conditions. In addition, the cognitive intelligence platform may use a knowledge graph pertaining to a condition of a user and a data structure (e.g., a patient graph) corresponding to the condition and the user to electronically generate a care plan (generating a healthcare recommendation) for the condition of the user. And lastly, Gnanasambandam discloses that the service provider 112 collects and generates data associated with the patient or the user, including health records (the extracted medical data) that include doctor's notes about the patient and prescriptions (does not indicate symptoms in layman's terms), billing records (does not indicate symptoms in layman's terms), and insurance records (does not indicate symptoms in layman's terms). The service provider 112, using a computing device (e.g., a desktop computer or a tablet), provides the data associated with the user (the extracted medical data) to the cognitive intelligence platform 102, and more specifically the knowledge cloud 106. See updated rejection above for citations to prior art reference. Conclusion Any inquiry concerning this communication or earlier communications from the examiner should be directed to KIMBERLY VANDER WOUDE whose telephone number is (703)756-4684. The examiner can normally be reached M-F 9 AM-5 PM. 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, PETER H CHOI can be reached at (469) 295-9171. 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. /K.E.V./Examiner, Art Unit 3681 /PETER H CHOI/Supervisory Patent Examiner, Art Unit 3681
Read full office action

Prosecution Timeline

Aug 20, 2021
Application Filed
Aug 30, 2024
Non-Final Rejection — §101, §103
Nov 25, 2024
Applicant Interview (Telephonic)
Nov 25, 2024
Examiner Interview Summary
Dec 06, 2024
Response Filed
Feb 27, 2025
Final Rejection — §101, §103
May 29, 2025
Examiner Interview Summary
May 29, 2025
Applicant Interview (Telephonic)
Jun 10, 2025
Request for Continued Examination
Jun 17, 2025
Response after Non-Final Action
Mar 18, 2026
Non-Final Rejection — §101, §103 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12437863
SYSTEMS AND METHODS FOR CENTRALIZED BUFFERING AND INTERACTIVE ROUTING OF ELECTRONIC DATA MESSAGES OVER A COMPUTER NETWORK
2y 5m to grant Granted Oct 07, 2025
Study what changed to get past this examiner. Based on 1 most recent grants.

AI Strategy Recommendation

Get an AI-powered prosecution strategy using examiner precedents, rejection analysis, and claim mapping.
Powered by AI — typically takes 5-10 seconds

Prosecution Projections

3-4
Expected OA Rounds
7%
Grant Probability
16%
With Interview (+9.5%)
2y 6m
Median Time to Grant
High
PTA Risk
Based on 30 resolved cases by this examiner. Grant probability derived from career allow rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month