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 . Claims 1-20 are pending.
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 a judicial exception without significantly more.
Step 1 (The Statutory Categories): Is the claim to a process, machine, manufacture, or composition of matter? MPEP 2106.03.
Per Step 1, claim 1 is to a method (i.e., a process), claim 8 to a system (i.e., a machine), and claim 15 to a non-transitory computer-readable medium (i.e., a manufacture). Thus, the claims are directed to statutory categories of invention. However, the claims are rejected under 35 U.S.C. 101 because they are directed to an abstract idea, a judicial exception, without reciting additional elements that integrate the judicial exception into a practical application.
The analysis proceeds to Step 2A Prong One.
Step 2A Prong One: Does the claim recite an abstract idea, law of nature, or natural phenomenon? MPEP 2106.04.
The abstract idea of claims 1, 8, and 15 is (claim 1 being representative):
receiving a request that indicates (i) an entity feature dataset associated with the entity identifier and (ii) an event progression model;
receiving an event risk data object for the entity identifier that is generated using the entity feature dataset and the event progression model;
initiating a rendering of an event progression graphical visualization that is based on the event risk data object;
receiving a request comprising a natural language query for interacting with the event progression model;
receiving a simulated event risk data object for the entity identifier that is generated using the entity feature dataset, the event progression model, and the natural language query; and
initiating an updated rendering of the event progression graphical visualization that is based on the simulated event risk data object.
The abstract idea steps italicized above describe the rules or instructions, communicated between persons or a person and a computer, that articulate how to generate a visualization (e.g., a timeline) that depicts simulated event progression. This constitutes a process that, under its broadest reasonable interpretation, covers managing personal behavior relationships, interactions between people. Examiner notes that the abstract idea merely describes the acts of receiving of data, initiating a rendering of a visualization (e.g., sketching a timeline), and updating the rendering of the visualization, which are not inherently technical, given that a person (e.g., a healthcare provider), when instructed, may generate a visual representation of event progression under difference scenarios.
If a claim limitation, under its broadest reasonable interpretation, covers managing personal behavior relationships, interactions between people, including social activities, teaching, and/or following rules or instructions, then it falls within the Certain Methods of Organizing Human Activity – Managing Personal Behavior Relationships, Interactions Between People grouping of abstract ideas. Accordingly, the claim recites an abstract idea.
Step 2A Prong Two: Does the claim recite additional elements that integrate the judicial exception into a practical application? MPEP 2106.04.
This judicial exception is not integrated into a practical application because the additional elements are merely instructions to apply the abstract idea to a computer, as described in MPEP 2106.05(f).
The independent claims recite the following additional elements:
Claim 1: computer-implemented; user interface application programming interface (API); by [the] one or more processors; model API; via a [the] conversational user interface.
Claim 8: a computing system comprising memory and one or more processors communicatively coupled to the memory; user interface application programming interface (API); model API; via a [the] conversational user interface.
Claim 15: one or more non-transitory computer-readable storage media including instructions that, when executed by one or more processors; user interface application programming interface (API); model API; via a [the] conversational user interface.
These elements are merely instructions to apply the abstract idea to a computer, per MPEP 2106.05(f). Applicant has only described generic computing elements in their specification, as seen in [0036]-[0045] of applicant’s specification as filed, for example.
Further, the combination of these elements is nothing more than a generic computing system applied to the tasks of the abstract idea. Because the additional elements are merely instructions to apply the abstract idea to a generic computing system, they do not integrate the abstract idea into a practical application, when viewed in combination. See MPEP 2106.05(f).
Therefore, per Step 2A Prong Two, the additional elements, alone and in combination, do not integrate the judicial exception into a practical application. The claim is directed to an abstract idea.
Step 2B (The Inventive Concept): Does the claim recite additional elements that amount to significantly more than the judicial exception? MPEP 2106.05.
Step 2B involves evaluating the additional elements to determine whether they amount to significantly more than the judicial exception itself.
The examination process involves carrying over identification of the additional element(s) in the claim from Step 2A Prong Two and carrying over conclusions from Step 2A Prong Two pertaining to MPEP 2106.05(f).
The additional elements and their analysis are therefore carried over: applicant has merely recited elements that facilitate the tasks of the abstract idea, as described in MPEP 2106.05(f).
Further, the combination of these elements is nothing more than a generic computing system applied to the tasks of the abstract idea. When the claim elements above are considered, alone and in combination, they do not amount to significantly more.
Therefore, per Step 2B, the additional elements, alone and in combination, are not significantly more. The claims are not patent eligible.
The analysis takes into consideration all dependent claims as well:
Dependent claims 2-7, 9-14, and 16-20 recite additional abstract steps and/or information that further narrow the abstract idea. This narrowing of the abstract idea does not integrate it into practical application or add significantly more, and the same abstract idea grouping highlighted above applies. Some of the dependent claims recite further additional elements:
Claims 4-5, 11-12, and 18-19: a [the] model interaction dialog widget.
Similar to above, these are generic computing elements used in their ordinary capacity to facilitate the tasks of the abstract idea. Whether viewed alone or in combination, they do not integrate the abstract idea into practical application or add significantly more. See MPEP 2106.05(f).
Accordingly, claims 1-20 are rejected under 35 USC § 101 as being directed to non-statutory subject matter.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Larson (US 11605465) in view of Mossin (US 20190034591), Setlur (US 20210303558), and Shrager (US 20200411199).
Claims 1, 8, and 15
Larson discloses:
[Claim 1] A computer-implemented method {col. 13, line 24 to col. 14, line 50} comprising:
[Claim 8] A computing system comprising memory and one or more processors communicatively coupled to the memory {col. 13, line 24 to col. 14, line 50}, the one or more processors configured to:
[Claim 15] One or more non-transitory computer-readable storage media including instructions {col. 13, line 24 to col. 14, line 50} that, when executed by one or more processors, cause the one or more processors to:
receiving, by one or more processors, a user interface application programming interface (API) request that indicates (i) an entity feature dataset associated with the entity identifier and (ii) an event progression model {receiving a request that indicates (i) an entity feature dataset associated with the entity identifier and (ii) an event progression model described in col. 11, line 64 to col. 12, line 6: FIG. 4 illustrates operation of the prediction module 110 with respect to processing a prediction request according to various embodiments. An end user may access the machine learning system 104 with a user device 108 via a prediction application 106 (a web application) and request a report. In the request, the end user may provide specific episode data, e.g., specific patient data (patient metrics and treatment), to populate a selected episode profile or template in a selected web application associated with the prediction application 106.
a user interface application programming interface (API) request described in col. 12, lines 15-20: The prediction module 110 may include an application interface 116 configured to handle communication between the prediction application 106 and the prediction module 110.
one or more processors described in col. 13, line 24 to col. 14, line 50.};
receiving, by the one or more processors, an event risk data object for the entity identifier that is generated using the entity feature dataset and the event progression model {receiving an event risk data object for the entity identifier that is generated using the entity feature dataset and the event progression model described in col. 12, lines 40-51: Using the episode data and best in class model in the prediction database corresponding to the client model, the episode data may be input into the model and model may be run 502. The running of the model with the episode data generates a prediction response based on the model output 503. The prediction response may then be provided to the client requester 504, e.g., the prediction module may transmit the response to the prediction application for display, storage, or routing to the user device or another location specified by the client user or request.};
model API request {See previous citation to 12, lines 15-20.}.
Larson doesn’t explicitly disclose, however, Mossin, in a similar field of endeavor directed to predicting medical events, teaches:
initiating, by the one or more processors and via a conversational user interface, a rendering of an event progression graphical visualization that is based on the event risk data object {initiating, by the one or more processors and via a conversational user interface, a rendering of an event progression graphical visualization that is based on the event risk data object described in [0157]: FIG. 8A also shows other aspects of interest, including a tool bar 108 which allows the physician to select a graphical display of different probabilities (or risks) in the timeline area 105 of the display 102, on a Y axis scale of 0-100. In this instance, the physician has toggled to the “on” position the risks/probabilities of death, discharge, and ICU transfer. Line 110 plots the probability of discharge from the hospital. Line 112 plots the probability of ICU transfer. Line 114 plots the risk of death. Note that approximately 16:00 there was a sharp spike in the in the risk of ICU transfer and shortly after that a slight increase in the risk of death. The physician can explore these plots of risks/probabilities and find out more information on past medical events related to the risk of ICU transfer and delayed discharge by clicking on or selecting the Alert icon 104.}.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify Larson to include the features of Mossin. Given that Larson is directed to forecasting patient treatment outcomes, one of ordinary skill in the art would have been motivated to look to Mossin, in order to provide predictions of future clinical events and highlighting of relevant underlying medical events contributing to these predictions in a timely manner {[0004] of Mossin}.
The combination of Larson and Mossin, while teaching an event progression model and model API request (see cited portions of Larson), doesn’t explicitly teach, however, Setlur, in a similar field of endeavor directed to applying natural language processing to data visualizations, teaches:
receiving, by the one or more processors and via the conversational user interface, a [command] comprising a natural language query for interacting with the [data visualization] {receiving a request comprising a natural language query for interacting with the event progression model described in [0079]: In some implementations, the graphical user interface 100 also includes a natural language processing region 124. The natural language processing region 124 includes an input bar (also referred to herein as a command bar) for receiving natural language commands. A user may interact with the input bar to provide commands. For example, the user may type a command in the input bar to provide the command. In addition, the user may indirectly interact with the input bar by speaking into a microphone (e.g., an audio input device 220) to provide commands. In some implementations, data elements are initially associated with the column shelf 120 and the row shelf 122 (e.g., using drag and drop operations from the schema information region 110 to the column shelf 120 and/or the row shelf 122). After the initial association, the user may use natural language commands (e.g., in the natural language processing region 124) to further explore the displayed data visualization.}.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the combination of Larson and Mossin to include the features of Setlur. Given that Larson is directed to forecasting patient treatment outcomes, which requires multiple datasets, one of ordinary skill in the art would have been motivated to look to Setlur, in order to facilitate interacting with and exploring the datasets {[0003] of Setlur}.
The combination of Larson, Mossin, and Setlur doesn’t explicitly teach, however, Shrager, in a similar field of endeavor directed to conducting virtual trials , teaches:
receiving, by the one or more processors, a simulated event risk data object for the entity identifier that is generated using the entity feature dataset, the event progression model, and the natural language query {receiving a simulated event risk data object for the entity identifier that is generated using the entity feature dataset, the event progression model, and the natural language query described in [0113]: A user may use an application or portal presenting an interactive virtual trial interface. The interface can comprise parameters comprising user-selectable values. These parameters can include patient information such as age, gender, biomarkers, treatments, survival since diagnosis, and other relevant criteria that may be used to sort, filter, and/or search for a cohort of clinical cases… In some cases, simulated patient histories are generated under various treatment protocols to achieve rapid target learning (FIG. 16).
natural language query further described in [0065]: In order to efficiently capture the unambiguous meaning of the case-contextualized treatment rationales generated by molecular tumor boards, the platform described herein focuses on “Biomedical Controlled English” (BCE), a biomedically-specific form of Controlled Natural Language (CNL; Kuhn, 2014).}; and
initiating, by the one or more processors and via the conversational user interface, an updated rendering of the event progression graphical visualization that is based on the simulated event risk data object {As seen in Fig. 16. Also see [0113].}.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the combination of Larson, Mossin, and Setlur to include the features of Shrager. Given that Larson is directed to forecasting patient treatment outcomes, one of ordinary skill in the art would have been motivated to look to Shrager, in order to facilitate rapid global learning from different patient treatments {[0003] of Shrager}.
Claims 2, 9, and 16
Larson further discloses: wherein receiving the user interface API request comprises the entity feature dataset and a request to perform a predictive operation using the event progression model {See col. 11, line 64 to col. 12, line 6: FIG. 4 illustrates operation of the prediction module 110 with respect to processing a prediction request according to various embodiments. An end user may access the machine learning system 104 with a user device 108 via a prediction application 106 (a web application) and request a report. In the request, the end user may provide specific episode data, e.g., specific patient data (patient metrics and treatment), to populate a selected episode profile or template in a selected web application associated with the prediction application 106.}.
Claims 3, 10, and 17
Larson further disclose: wherein receiving the user interface API request comprises the event progression model and a request to perform a predictive operation on the entity feature dataset using the event progression model {See col. 11, line 64 to col. 12, line 6: FIG. 4 illustrates operation of the prediction module 110 with respect to processing a prediction request according to various embodiments. An end user may access the machine learning system 104 with a user device 108 via a prediction application 106 (a web application) and request a report. In the request, the end user may provide specific episode data, e.g., specific patient data (patient metrics and treatment), to populate a selected episode profile or template in a selected web application associated with the prediction application 106.}.
Claims 4, 11, and 18
Setlur further teaches: wherein receiving the natural language query comprises: initiating, via the conversational user interface, a rendering of a model interaction dialog widget {See [0153]: FIG. 12A illustrates a set of widgets generated for handling ambiguity in a user query according to some implementations. A challenge for natural language understanding systems that support interactive dialog is determining the intent of the utterance. In some implementations, the system automatically resolves various forms of syntactic, lexical and semantic ambiguities. These resolutions are expressed in the form of widgets and feedback to help the user understand the system's intent and the provenance of how the utterance was interpreted. By manipulating these widgets and viewing the feedback of what results are shown in the visualization, the user can, for instance, instantiate a follow-up repair utterance to override or clarify the system decisions made.}; receiving, via the conversational user interface, one or more user inputs to the model interaction dialog widget, wherein each of the one or more user inputs comprises a text segment {See [0154]: In some implementations, the system identifies one or more widgets from the analytical functions derived from an utterance. In some such implementations, the system organizes and presents the widgets in an intuitive way so that the user can understand how the system interprets her utterance and subsequently modify the interpretation using these widgets. For this purpose, the system takes the original utterance and orders the widgets in the same sequence as the corresponding query terms. In some such implementations, the system achieves this by using a library, such as Sparklificator™, that facilitates the placement of small word-scale visualization within text in a compact way. In addition, some implementations provide a set of interfaces to users including the ability to manipulate and/or remove a widget, to modify the query, and to resolve ambiguous queries.}; and aggregating the one or more user inputs to generate the natural language query { See previous citations to [0153], [0154].}.
The motivation and rationale to include the additional features of Setlur is the same as set forth previously.
Claims 5, 12, and 19
Setlur further teaches: wherein receiving the natural language query further comprises, in response to a first user input of the one or more user inputs: generating a prompt based on the first user input {See previous citations to [0153], [0154].}; and initiating, via the conversational user interface, a rendering of the prompt within the model interaction dialog widget {See previous citations to [0153], [0154].}.
The motivation and rationale to include the additional features of Setlur is the same as set forth previously.
Claims 6, 13, and 20
Larson further disclose: event progression model {See previous citation to col. 11, line 64 to col. 12, line 6.}.
Setlur further teaches: wherein the prompt comprises a list of predetermined natural language queries that correspond to the first user input and each of the list of predetermined natural language queries correspond to a model action for augmenting the performance of the [data visualization] {See [0098]: The system uses the forward-looking conversation centers C.sub.f(U.sub.n+1) (319) for updating one or more data visualization(s) according to some implementations. The system also uses the set of forward-looking centers C.sub.f(U.sub.n+1) (319) as the backward-looking conversation centers C.sub.b(U.sub.n+2) for the next utterance U.sub.n+2, and so on. When the user either moves to a different dataset or resets the visualization, the system updates the global coherence of the analytical conversation, and clears all previous states (including the forward-looking conversation centers, the backward-looking conversation centers, and the temporary conversation centers), in accordance with some implementations. Also see previous citations to [0153], [0154].}
The motivation and rationale to include the additional features of Setlur is the same as set forth previously.
Claims 7 and 14
Shrager further teaches: wherein initiating the updated rendering of the event progression graphical visualization comprises: initiating a rendering of an event progression timeline chart that is based on (i) the simulated event risk data object and (ii) one or more predefined event labels for one or more predefined events related to an event domain {See previous citations to [0113], Fig. 16.}.
The motivation and rationale to include the additional features of Shrager is the same as set forth previously.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
“Unsupervised learning of disease progression models” (NPL attached), which teaches: In this paper, we propose a probabilistic disease progression model that address these challenges. As compared to existing disease progression models, the advantage of our model is three-fold: 1) it learns a continuous-time progression model from discrete-time observations with non-equal intervals; 2) it learns the full progression trajectory from a set of incomplete records that only cover short segments of the progression; 3) it learns a compact set of medical concepts as the bridge between the hidden progression process and the observed medical evidence, which are usually extremely sparse and noisy. We demonstrate the capabilities of our model by applying it to a real-world COPD patient cohort and deriving some interesting clinical insights.
US 20210125731, which teaches: A system and method for analyzing a data store of de-identified patient data to generate one or more dynamic user interfaces usable to predict an expected response of a particular patient population or cohort when provided with a certain treatment. The automated analysis of patterns occurring in patient clinical, molecular, phenotypic, and response data, as facilitated by the various user interfaces, provides an efficient, intuitive way for clinicians to evaluate large data sets to aid in the potential discovery of insights of therapeutic significance.
US 20230099880, which teaches: A method for early diagnosis of an autoimmune or chronic disease in subject. The method includes (i) selecting, out of missing existing health related data of the subject (HRDS) items, a subject-specific subset; (ii) obtaining at least one missing existing HRDS item; (iii) adding the at least one obtained HRDS item to an existing HRDS to provide an updated HRDS; (iv) applying to the updated HRDS, a second machine learning model adapted to convert parameters of the updated HRDS, some of which may be indicative of the early development stages of the disease, into a second vector that provides a compact representation of the updated HRDS that reflects on the medical condition of the subject; and (v) applying a second classifier model to the second vector to provide a second classification result that is indicative of a second likelihood of the subject having or developing the disease.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JOHN SAMUEL WASAFF whose telephone number is (571)270-5091. The examiner can normally be reached Monday through Friday 8:00 am to 6:00 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, SARAH MONFELDT can be reached at (571) 270-1833. 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.
JOHN SAMUEL WASAFF
Primary Examiner
Art Unit 3629
/JOHN S. WASAFF/Primary Examiner, Art Unit 3629
Prosecution Insights