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 24, 2026.
Claims 1, 2, 7-8, 13 and 20 have been amended and are hereby entered.
Claims 1-20 are currently pending and have been examined.
This action is made FINAL.
Claim Objections
Claim 1 is objected to because of the following informalities:
Claim 1 recites “to map text in the extracted medical data to entities in a knowledge graph; constructing, with a processor, a knowledge graph from the extracted and entity-linked data;”. Currently, “a knowledge graph” is recited twice. Examiner suggests either amending the claim limitation to read “constructing, with a processor, the knowledge graph from the extracted and entity-linked data;” or simply reciting the steps of constructing a knowledge graph prior to how the text is mapped within the knowledge graph for better clarity within the claim. 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 by web crawling the plurality of data sources, wherein the plurality of data sources include a disease database, a patient database, and a medicine database, and wherein the disease database, the patient database, and the medicine database are network-connected databases; 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; performing entity linking on the extracted medical data by applying Unified Medical Language System (UMLS) identifiers with natural language processing techniques, including a neural language model trained for medical entity linking, to map text in the extracted medical data to entities in a knowledge graph; constructing, with a processor, a knowledge graph from the extracted data and entity linked data; 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 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 by web crawling the plurality of data sources, wherein the plurality of data sources include a disease database, a patient database, and a medicine database, and wherein the disease database, the patient database, and the medicine database are network-connected databases; 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; perform entity linking on the received medical data by applying Unified Medical Language System (UMLS) identifiers with natural language processing techniques, including a neural language model trained for medical entity linking, to map text in the received medical data to symptom entities in a knowledge graph; 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 the knowledge graph; wherein the knowledge graph 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; 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 by web crawling the plurality of data sources, wherein the plurality of data sources include a disease database, a patient database, and a medicine database, and wherein the disease database, the patient database, and the medicine database are network-connected databases; 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; perform entity linking on the extracted medical data by applying Unified Medical Language System (UMLS) identifiers with natural language processing techniques, including a neural language model trained for medical entity linking comprising MedLinker, to map text in the extracted medical data to entities in a knowledge graph; convert the extracted and entity-liked medical data into a different format; load the converted data into the 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; perform knowledge inference by detecting and classifying relationships between the multiple symptom entities and the multiple layman entities; 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 interprets the above bolded limitations as additional elements as further discussed below. The remaining non-bold limitations above, as drafted, are a process that, under the broadest reasonable interpretation, cover 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-bold 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 and entity-linked 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 and entity-linked 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 web crawling, a network-connected disease database, a network-connected patient database, a network-connected medicine database, a processor, using a trained 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, web crawling, a network-connected disease database, a network-connected patient database, a network-connected medicine database, using a trained neural language model, 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, web crawling, a network-connected disease database, a network-connected patient database, a network-connected medicine database, using a trained neural language model comprising MedLinker, load the converted data into a knowledge graph structure that is stored in the server, and transmitting a healthcare recommendation to the user device. 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 a network-connected disease database, a network-connected patient database, a network-connected medicine database, a processor, using a trained neural language model, using MedLinker, 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, limitations (1) web crawling the plurality of data sources (claims 1, 7 and 13) and (2) transmitting a healthcare recommendation to the user device (claim 13) are being interpreted as insignificant extra-solution activity. The web crawling step is recited at a high level of generality and amounts to mere data gathering, which is a form of extra-solution activity, and does not add a meaningful limitation to the claimed invention. The 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 elements of a network-connected disease database, a network-connected patient database, a network-connected medicine database, a processor, using a trained neural language model, using MedLinker, 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 elements of (1) web crawling the plurality of data sources (claims 1, 7 and 13) and (2) 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)]. Further, Applicant’s specification states, at a high level, that the web crawling of biomedical literature, for example in a network-connected archive or database such as PubMed, is taking place to perform data extraction (see para 61).
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 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-12 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 Kowolenko et al. (US 20200409951), further in view of Lucas et al. (US 20200176098).
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 Kowolenko:
by web crawling the plurality of data sources, (Kowolenko teaches a system for processing and analyzing data sourced from the web through the use of a web crawler (by web crawling the plurality of data sources). – paras 3, 50-51)
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 sourcing data via a web crawler in order to aggregate information without the requirement of a person with expertise in data transformation to convert all the disparate data types into a common data format that allows the user to explore relationships (see Kowolenko para 30).
Gnanasambandam, Wixon, Salazar and Kowolenko do not disclose the following limitations met by Lucas:
wherein the plurality of data sources include a disease database…, and wherein the disease database,…are network-connected databases; wherein the disease database includes a disease dataset that maps diagnostic codes to related terms; (Lucas teaches accessing the Unified Medical Language System (UMLS) (network-connected databases) which includes a Metathesaurus having drug vocabularies including ICD-10-CM, MeSH® and SNOMED CT® (a disease database). – para 40)
wherein the plurality of data sources include…a patient database…, and wherein the patient database,…are network-connected databases; (Lucas teaches accessing electronic health records (a network-connected patient database) and processing them into structure results. – paras 7, 15, 27, 46; FIG. 1)
wherein the plurality of data sources include… a medicine database, and wherein…the medicine database are network-connected databases; (Lucas teaches accessing the Unified Medical Language System (UMLS) (network-connected databases) which includes a Metathesaurus having drug vocabularies including MeSH®, RxNorm, and SNOMED CT®. Each of these drug vocabularies highlights and enumerates specific collections of relevant drugs (a medicine database). – para 40)
performing entity linking on the extracted medical data by applying Unified Medical Language System (UMLS) identifiers with natural language processing techniques, including a neural language model trained for medical entity linking, to map text in the extracted medical data to entities in a knowledge graph; (Lucas teaches utilizing neural language models (with natural language processing techniques, including a neural language model) and UMLS concept unique identifiers (CUI) for entity linking of patient data (performing entity linking on the extracted medical data by applying Unified Medical Language System (UMLS) identifiers). Neural networks for language modeling may be trained over millions of sentences and perform best when trained over text from the same domain as they will encounter in a production system (a neural language model trained for medical entity linking). Relationships may be visualized through a graph-based logic for following links between concepts that each specific integrated dictionary may provide (to map text in the extracted medical data to entities in a knowledge graph). – abstract; paras 40, 71, 95, 101, 168-170, 181-182, 253)
constructing, with a processor, a knowledge graph from the extracted data and entity-linked data; (Lucas teaches an ontological graphing algorithm and an exemplary ontological graph (a knowledge graph) database for viewing links between different dictionaries (from the extracted data). Returning to FIG. 1, entity normalization (e.g., at step 150) may be applied to determine which of the entity linked concepts (from the entity-linked data) of the previous stage are relevant to abstraction and, if they are relevant, which encoding schema may be applied to encapsulate the abstraction completely. – paras 8, 20, 182-183; FIGs. 1, 6)
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 accessing the Unified medical language system (UMLS), as well as a neural language model trained to utilize UMLS concept unique identifiers to perform entity linking on data obtained from medical health records in order to increase both accuracy and reliability of predictions specific to a patient record (see Lucas para 24).
Regarding Claim 2, Gnanasambandam, Wixon, Salazar, Kowolenko and Lucas disclose all the limitations above and further disclose the following limitations:
The method of claim 1, wherein the 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, Kowolenko and Lucas 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, Kowolenko and Lucas 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, Kowolenko and Lucas 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, Kowolenko and Lucas 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)
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 the 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 a 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) (a 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 Kowolenko:
by web crawling the plurality of data sources, (Kowolenko teaches a system for processing and analyzing data sourced from the web through the use of a web crawler (by web crawling the plurality of data sources). – paras 3, 50-51)
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 sourcing data via a web crawler in order to aggregate information without the requirement of a person with expertise in data transformation to convert all the disparate data types into a common data format that allows the user to explore relationships (see Kowolenko para 30).
Gnanasambandam, Wixon, Salazar and Kowolenko do not disclose the following limitations met by Lucas:
wherein the plurality of data sources include a disease database…, and wherein the disease database,…are network-connected databases; wherein the disease database includes a disease dataset that maps diagnostic codes to related terms; (Lucas teaches accessing the Unified Medical Language System (UMLS) (network-connected databases) which includes a Metathesaurus having drug vocabularies including ICD-10-CM, MeSH® and SNOMED CT® (a disease database). – para 40)
wherein the plurality of data sources include…a patient database…, and wherein the patient database,…are network-connected databases; (Lucas teaches accessing electronic health records (a network-connected patient database) and processing them into structure results. – paras 7, 15, 27, 46; FIG. 1)
wherein the plurality of data sources include… a medicine database, and wherein…the medicine database are network-connected databases; (Lucas teaches accessing the Unified Medical Language System (UMLS) (network-connected databases) which includes a Metathesaurus having drug vocabularies including MeSH®, RxNorm, and SNOMED CT®. Each of these drug vocabularies highlights and enumerates specific collections of relevant drugs (a medicine database). – para 40)
perform entity linking on the extracted medical data by applying Unified Medical Language System (UMLS) identifiers with natural language processing techniques, including a neural language model trained for medical entity linking, to map text in the extracted medical data to entities in a knowledge graph; (Lucas teaches utilizing neural language models (with natural language processing techniques, including a neural language model) and UMLS concept unique identifiers (CUI) for entity linking of patient data (perform entity linking on the extracted medical data by applying Unified Medical Language System (UMLS) identifiers). Neural networks for language modeling may be trained over millions of sentences and perform best when trained over text from the same domain as they will encounter in a production system (a neural language model trained for medical entity linking). Relationships may be visualized through a graph-based logic for following links between concepts that each specific integrated dictionary may provide (to map text in the extracted medical data to entities in a knowledge graph). – abstract; paras 40, 71, 95, 101, 168-170, 181-182, 253)
transform the received and entity-linked medical data into a different structure (Lucas teaches an ontological graphing algorithm and an exemplary ontological graph database for viewing links between different dictionaries (the received medical data). Returning to FIG. 1, entity normalization (e.g., at step 150) may be applied to determine which of the entity linked concepts of the previous stage are relevant to abstraction and, if they are relevant, which encoding schema may be applied to encapsulate the abstraction completely (transform the received and entity-linked medical data into a different structure). – paras 8, 20, 182-183; FIGs. 1, 6)
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 accessing the Unified medical language system (UMLS), as well as a neural language model trained to utilize UMLS concept unique identifiers to perform entity linking on data obtained from medical health records in order to increase both accuracy and reliability of predictions specific to a patient record (see Lucas para 24).
Regarding Claim 8, Gnanasambandam, Wixon, Salazar, Kowolenko and Lucas disclose all the limitations above and further disclose the following limitations:
The non-transitory computer-readable storage medium of claim 7, wherein the 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, Kowolenko and Lucas 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, Kowolenko and Lucas 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, Kowolenko and Lucas 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, Kowolenko and Lucas 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)
Claims 13-20 are rejected under 35 U.S.C. 103 as being unpatentable over Gnanasambandam, in view of Wixon, in view of Salazar, in view of Kowolenko, in view of Lucas, further in view of Loureiro et al. (Loureiro D, Jorge AM. MedLinker: Medical Entity Linking with Neural Representations and Dictionary Matching. Advances in Information Retrieval. 2020 Mar 24;12036:230–7. doi: 10.1007/978-3-030-45442-5_29. PMCID: PMC7148021.).
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 the 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 the 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)
perform knowledge inference by detecting and classifying relationships between the multiple symptom entities and the 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 the 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 Kowolenko:
by web crawling the plurality of data sources, (Kowolenko teaches a system for processing and analyzing data sourced from the web through the use of a web crawler (by web crawling the plurality of data sources). – paras 3, 50-51)
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 sourcing data via a web crawler as taught by Kowolenko in order to aggregate information without the requirement of a person with expertise in data transformation to convert all the disparate data types into a common data format that allows the user to explore relationships (see Kowolenko para 30).
Gnanasambandam, Wixon, Salazar and Kowolenko do not disclose the following limitations met by Lucas:
wherein the plurality of data sources include a disease database…, and wherein the disease database,…are network-connected databases; wherein the disease database includes a disease dataset that maps diagnostic codes to related terms; (Lucas teaches accessing the Unified Medical Language System (UMLS) (network-connected databases) which includes a Metathesaurus having drug vocabularies including ICD-10-CM, MeSH® and SNOMED CT® (a disease database). – para 40)
wherein the plurality of data sources include…a patient database…, and wherein the patient database,…are network-connected databases; (Lucas teaches accessing electronic health records (a network-connected patient database) and processing them into structure results. – paras 7, 15, 27, 46; FIG. 1)
wherein the plurality of data sources include… a medicine database, and wherein…the medicine database are network-connected databases; (Lucas teaches accessing the Unified Medical Language System (UMLS) (network-connected databases) which includes a Metathesaurus having drug vocabularies including MeSH®, RxNorm, and SNOMED CT®. Each of these drug vocabularies highlights and enumerates specific collections of relevant drugs (a medicine database). – para 40)
perform entity linking on the extracted medical data by applying Unified Medical Language System (UMLS) identifiers with natural language processing techniques, including a neural language model trained for medical entity linking…, to map text in the extracted medical data to entities in a knowledge graph; (Lucas teaches utilizing neural language models (with natural language processing techniques, including a neural language model) and UMLS concept unique identifiers (CUI) for entity linking of patient data (performing entity linking on the extracted medical data by applying Unified Medical Language System (UMLS) identifiers). Neural networks for language modeling may be trained over millions of sentences and perform best when trained over text from the same domain as they will encounter in a production system (a neural language model trained for medical entity linking). Relationships may be visualized through a graph-based logic for following links between concepts that each specific integrated dictionary may provide (to map text in the extracted medical data to entities in a knowledge graph). – abstract; paras 40, 71, 95, 101, 168-170, 181-182, 253)
convert the extracted and entity-linked medical data into a different format; (Lucas teaches an ontological graphing algorithm and an exemplary ontological graph database for viewing links between different dictionaries (the extracted medical data). Returning to FIG. 1, entity normalization (e.g., at step 150) may be applied to determine which of the entity linked concepts of the previous stage are relevant to abstraction and, if they are relevant, which encoding schema may be applied to encapsulate the abstraction completely (convert the extracted and entity-linked medical data into a different format). – paras 8, 20, 182-183; FIGs. 1, 6)
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 accessing the Unified medical language system (UMLS), as well as a neural language model trained to utilize UMLS concept unique identifiers to perform entity linking on data obtained from medical health records as taught by Lucas in order to increase both accuracy and reliability of predictions specific to a patient record (see Lucas para 24).
Gnanasambandam, Wixon, Salazar, Kowolenko and Lucas do not disclose the following limitations met by Loureiro:
a neural language model trained for medical entity linking comprising MedLinker (Loureiro teaches that MedLinker performs Medical Entity Linking by leveraging specialized neural language models with Approximate Dictionary Matching, for example, UMLS. – abstract; Introduction)
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 utilizing the MedLinker platform as taught by Loureiro in order to overcome challenges present with large datasets and low overlap between concepts in training, validation and test sets (see Loureiro Abstract).
Regarding Claim 14, Gnanasambandam, Wixon, Salazar, Kowolenko, Lucas and Loureiro 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, Kowolenko, Lucas and Loureiro 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, Kowolenko, Lucas and Loureiro 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, Kowolenko, Lucas and Loureiro 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, Kowolenko, Lucas and Loureiro 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, Kowolenko, Lucas and Loureiro 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, Kowolenko, Lucas and Loureiro 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 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 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 applicants’
disclosure.
Kannan et al. (US20190311814) discloses a graph representation of medical concepts and relations between the medical concepts, allowing for concepts, modifiers, relations, and hierarchies. The initial set of concepts in the graph may be derived from the Systematized Nomenclature of Medicine Clinical Terms (SNOMED CT) ontology standard and represented by unified medical language system (UMLS) concept unique identifiers (CUIs). The normalized medical concepts may further include a mapping of a medical text to a knowledge base representation by using an entity recognition module. The medical text understanding submodule may apply NLP technologies to extract concepts and relations from existing medical text resources to construct knowledge base graphs and diagnosis models. Additionally, engines that are based on models learned from data may be included. Such models quantify the relation between symptoms and diseases observed in real-world data. The models are trained using various medical data. See paras 44-45, 53 and 99-100.
Response to Arguments
Regarding the Claim Objections to Claims 2, 7-8 and 20, Applicant’s amendments have rendered the previous objections moot.
Regarding rejections under 35 USC § 101 to Claims 1-20, Applicant’s arguments have been fully considered and are not persuasive. The rejection has been updated in light of latest amendments. Applicant argues:
(a) Nonetheless, even if the claims were found to recite an abstract idea (which Applicant respectfully disagrees) the claims as amended integrate that idea into a practical application that imposes meaningful limits on any abstract idea, such that the claims are not directed to the abstract idea itself. This is not least because the amendments to independent claim 1 add technically specific limitations. In particular, claim 1 requires (1) web crawling of the plurality of data sources (network-connected databases) to extract medical data, and (2) entity linking on the extracted medical data by applying UMLS identifiers with natural language processing techniques, and mapping text in the extracted medical data to entities in the knowledge graph. These limitations are not merely abstract. Rather, the above-discussed limitations reflect concrete, technical steps performed by a computer system. (p. 12-13).
Regarding (a), Examiner respectfully disagrees. 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 determine a healthcare recommendation for a patient. Examiner notes that the limitations regarding the mapping of text in the extracted data to entities in the knowledge graph are interpreted to be part of the abstract idea because this can be done by a person following instructions and/or mentally. 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.
Limitations (1) and (2) argued by the Applicant are not interpreted to be part of the abstract idea but are interpreted to be additional elements. However, as evaluated in Step 2A Prong 2 and Step 2B in the updated 101 rejection above, the web crawling limitation is recited at a high level of generality and amounts to mere data gathering, which is a form of extra-solution activity, and does not add a meaningful limitation to the claimed invention. MPEP 2106.04(d)(I) indicates that extra-solution data gathering activity cannot provide a practical application. Further, the use of natural language processing techniques is 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. Therefore, a practical application is not present.
(b) Moreover, the claimed method improves upon prior approaches to healthcare data management in a technically concrete way. As a result of this particular approach, disparate, heterogeneous healthcare data is transformed into a unified, structured knowledge graph from which new healthcare insights are automatically derived. The claims further produce a tangible, concrete result: a healthcare recommendation output to a user device for display. In any event, even if the claims were found not to integrate any abstract idea into a practical application (which Applicant respectfully disagrees), the claims recite additional elements that amount to significantly more than the abstract idea. This is not least because the specific technical steps of web crawling, UMLS-based neural entity linking, relationship detection/classification, and machine-learning-based insight extraction represent a concrete improvement to computer-based healthcare data processing technology; and recite significantly more than any abstract idea. The claims require specific technical components and non-routine technical operations that exceed conventional computer functionality. (p. 13-14).
Regarding (b), Examiner respectfully disagrees. MPEP 2106.04(d)(1) states "the word 'improvements' in the context of this consideration is limited to improvements to the functioning of a computer or any other technology/technical field, whether in Step 2A Prong Two or in Step 2B." Here there is no improvement to the computer nor is there an improvement to another technology. Because neither type of improvement is present in the claims, an improvement to technology is not present and there is no practical application. The claims recite, to paraphrase, extracting data from a plurality of data sources and constructing a knowledge graph in order to generate a healthcare recommendation. While claims 7 and 13 do recite “transform the received and entity-linked 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 and entity-linked medical data into a different format;” (claim 13); these limitations are identified to be part of the abstract idea because, as claimed, 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. Thus, these limitations cannot provide a technical improvement.
Examiner notes that the limitations of outputting a healthcare recommendation to a user is interpreted as part of the abstract idea and is directed to certain methods of organizing human activity because, by generating a recommendation, the user then chooses what to do next, essentially dictating or directing a person on what to do (i.e., following rules or instructions). See MPEP 2106.04(a)(2)(II).
Lastly, the additional elements of web crawling, using natural language processing techniques, and machine learning were each found to not provide a practical application, nor an improvement to the functioning of a computer or any other technology/technical field. See response to argument (a), as well as the updated 101 rejection above. For example, there is no indication that the computer is made to reduce computing resources or network load. In fact, the computer may be caused to operate less efficiently through the implementation of Applicant’s claimed invention; we do not know. Because there is no improvement to the functioning of the computer, a practical application is not present.
Therefore, the claimed invention is using a computer as a tool and any improvement present is an improvement to the abstract idea of, to paraphrase, determining a healthcare recommendation for a patient. See updated rejection above.
Regarding rejections under 35 USC § 103 to Claims 1-20, Applicant’s arguments have been fully considered and are persuasive regarding the newly added limitations: “by web crawling the plurality of data sources wherein the plurality of data sources…and wherein the disease database, the patient database, and the medicine database are network-connected databases;…performing entity linking on the extracted medical data by applying Unified Medical Language System (UMLS) identifiers with natural language processing techniques, including a neural language model trained for medical entity linking, to map text in the extracted medical data to entities in a knowledge graph; constructing, with a processor, a knowledge graph from the extracted data and entity-linked data;”. 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 Kowolenko et al. (US 20200409951), in view of Lucas et al. (US 20200176098), further in view of Loureiro et al. (Loureiro D, Jorge AM. MedLinker: Medical Entity Linking with Neural Representations and Dictionary Matching. Advances in Information Retrieval. 2020 Mar 24;12036:230–7. doi: 10.1007/978-3-030-45442-5_29. PMCID: PMC7148021.), as per the rejection above.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to 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
Prosecution Insights