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 Office Action is responsive to the amendments filed August 7, 2025.
Claims 1, 10, and 19 have been amended. Claims 2 and 11 have been cancelled and no claims have been added.
Claims 1, 3-10 and 12-19 are currently pending and have been fully examined.
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 8/7/25 has been entered.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1, 3-10 and 12-19 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Independent claims 1, 10 and 19 recite that “a portion of the different types of the data” are correlated to the adverse healthcare event for one or more individuals, and that “the other portion of types of the data” is not correlated to the adverse healthcare event. However, the specification does not provide any description of some types or portion of data not being correlated to the adverse healthcare event.
Claims 3-9 and 12-18 depend on claims 1 and 10 and thus are also rejected.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 10 and 12-18 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 10 recites “correlate a portion of the different types of the data”. There is insufficient antecedent basis for “the different types”.
Dependent claims 12-18 inherit the deficiency of claim 10 and thus are also rejected.
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.
Claim 19 is rejected under 35 USC 101 as being directed to non-statutory subject matter. The claim does not fall within at least one of the four categories of patent eligible subject matter because the claims are directed to a signal per se and mere information in the form of data. Claim 19 is recited to “a computer readable storage medium”, which is deemed to be directed purely towards signals per se.
The specification does not explicitly exclude transitory signals per se from the definition of the computer readable storage medium. Applicant’s specification states at paragraph [0044] that exemplary embodiments of the invention is further intended to cover later developed mediums such as transitory mediums, carrier waves, etc., and at [0047] that the computer readable storage medium may be, for example, but is not limited to, a series of devices, and further that a non-exhaustive list of more specific examples of the computer readable storage medium a further set of devices. Though the applicant attempts to specify that “[a] computer readable storage medium, as used herein, is not to be construed as being transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission media (e.g., light pulses passing through a fiber-optic cable), or electrical signals transmitted through a wire”, the specification simultaneously uses open-ended language and contemplates transitory mediums and carrier waves as embodiments intended to be covered that are “capable of performing the various heretofore-disclosed determinations, calculations, or the like”. In the interest of compact prosecution, the Examiner will interpret the claim as if it is directed to a statutory category of invention.
Claims 1, 3-10 and 12-19 is/are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more.
Under Step 1, as outlined in MPEP 2106, Claims 1 and 3-9 are drawn to a method, claims 10 and 12-18 are drawn to a system and Claim 19 is drawn to a computer program product.
Under Step 2A, Prong 1, the steps of the claim for the invention represents an abstract idea of a series of steps that recite a method of receiving data of different types associated with individuals related to an adverse healthcare event such as an institutionalization admission, hospital admission and death, correlating a portion of the different types of data to the adverse healthcare event to an individual, wherein other portions of types of the data is not correlated to the adverse healthcare event, generating a regression model based on the portion of different types of data based on the correlation of the portion of the data to the adverse healthcare event, wherein the regression model includes covariates that are associated with the different types of the data and wherein weights are assigned to the covariates for generating an indicator of risk to the adverse healthcare event, applying it to another individual to generate an indicator of risk for the other individual to have an adverse healthcare event. Receiving, correlating, modeling and generating an indicator of risk fall under the abstract grouping “mental processes” (methods which can be performed mentally, or which are the equivalent of human mental work, are unpatentable abstract ideas the ‘basic tools of scientific and technological work’ that are open to all.) (In MPEP §2106.04(a) because they simply discuss a series of steps regarding thinking that “can be performed in the human mind, or by a human using a pen and paper” to be followed to evaluate the data and indicate the risk of an adverse healthcare event of an individual, which is a mental process including observation and evaluation.
The independent claims 1, 10 and 19 recite receiving,…, data of different types associated with a plurality of individuals, wherein the data indicates that the individuals have experienced an adverse healthcare event; correlating a portion of the different types of the data to an adverse healthcare event for one or more of the individuals, wherein the other portion of types of the data is not correlated to the adverse healthcare event; generating a regression model that relates the portion of the different types of the data to the adverse healthcare event based on the correlation of the portion of the data to the adverse healthcare event, wherein the regression model includes variates that are associated with the different types of the data, and wherein weights are assigned to the covariates for generating an indicator of risk to the adverse healthcare event; applying the model to data of another individual to generate an indicator of risk of the other individual to the adverse healthcare event; and presenting the indicator of risk..
These limitations given the broadest reasonable interpretation, cover performance of the
limitations by a human user/actor that constitute certain mental processes. The steps of the claim for the invention represents an abstract idea of methods, which can be performed mentally, to receive data of different types associated with a plurality of individuals, correlating a portion of the different types of the data to an adverse healthcare event, generating a regression model that relates the portion of the different types of data, applying the model to another individual, and presenting the indicator of risk. These claim steps of the invention represent an abstract idea in which encompasses activity of a single person or multiple people that falls under observations, evaluations and judgements. Per MPEP 2106.04(a)(2)(III): the "mental processes" abstract idea grouping is defined as concepts performed in the human mind, and examples of mental processes include observations, evaluations, judgments, and opinions. The courts do not distinguish between mental processes that are performed entirely in the human mind and mental processes that require a human to use a physical aid (e.g., pen and paper or a slide rule) to perform the claim limitation. See, e.g., Benson, 409 U.S. at 67, 65, 175 USPQ at 674-75, 674 (noting that the claimed "conversion of [binary-coded decimal] numerals to pure binary numerals can be done mentally," i.e., "as a person would do it by head and hand."); Synopsys, Inc. v. Mentor Graphics Corp., 839 F.3d 1138, 1139, 120 USPQ2d 1473, 1474 (Fed. Cir. 2016) (holding that claims to a mental process of "translating a functional description of a logic circuit into a hardware component description of the logic circuit" are directed to an abstract idea, because the claims "read on an individual performing the claimed steps mentally or with pencil and paper").
Nor do the courts distinguish between claims that recite mental processes performed by humans and claims that recite mental processes performed on a computer. As the Federal Circuit has explained, "[c]ourts have examined claims that required the use of a computer and still found that the underlying, patent-ineligible invention could be performed via pen and paper or in a person’s mind." Versata Dev. Group v. SAP Am., Inc., 793 F.3d 1306, 1335, 115 USPQ2d 1681, 1702 (Fed. Cir. 2015). See also Intellectual Ventures I LLC v. Symantec Corp., 838 F.3d 1307, 1318, 120 USPQ2d 1353, 1360 (Fed. Cir. 2016) (‘‘[W]ith the exception of generic computer-implemented steps, there is nothing in the claims themselves that foreclose them from being performed by a human, mentally or with pen and paper.’’); Mortgage Grader, Inc. v. First Choice Loan Servs. Inc., 811 F.3d 1314, 1324, 117 USPQ2d 1693, 1699 (Fed. Cir. 2016) (holding that computer-implemented method for "anonymous loan shopping" was an abstract idea because it could be "performed by humans without a computer").
Claims can recite a mental process even if they are claimed as being performed on a computer. The claimed invention is described as a concept that is performed in the human mind and applicant is merely claiming that concept performed 1) on a generic computer, or 2) in a computer environment, or 3) is merely using a computer as a tool to perform the concept. In these situations, the claim is considered to recite a mental process.
Further, the steps represent mathematical concepts, specifically “wherein the generated regression model includes covariates that are associated with the different types of the data, and wherein weights are assigned to the covariates for generating an indicator of risk to the adverse healthcare event”. Per the specification (paragraphs 31-32), the regression model can be a Cox proportional hazards model. The Cox proportional hazards model is known to be a statistical (mathematical) method used to analyze the effect of covariates in survival data.
Per MPEP 2106.04(a)(2)(I): It is important to note that a mathematical concept need not be expressed in mathematical symbols, because "[w]ords used in a claim operating on data to solve a problem can serve the same purpose as a formula." In re Grams, 888 F.2d 835, 837 and n.1, 12 USPQ2d 1824, 1826 and n.1 (Fed. Cir. 1989). See, e.g., SAP America, Inc. v. InvestPic, LLC, 898 F.3d 1161, 1163, 127 USPQ2d 1597, 1599 (Fed. Cir. 2018) (holding that claims to a ‘‘series of mathematical calculations based on selected information’’ are directed to abstract ideas); Digitech Image Techs., LLC v. Elecs. for Imaging, Inc., 758 F.3d 1344, 1350, 111 USPQ2d 1717, 1721 (Fed. Cir. 2014) (holding that claims to a ‘‘process of organizing information through mathematical correlations’’ are directed to an abstract idea); and Bancorp Servs., LLC v. Sun Life Assurance Co. of Can. (U.S.), 687 F.3d 1266, 1280, 103 USPQ2d 1425, 1434 (Fed. Cir. 2012) (identifying the concept of ‘‘managing a stable value protected life insurance policy by performing calculations and manipulating the results’’ as an abstract idea).
Under Step 2A, Prong Two, the judicial exception is not integrated into a practical application because the additional elements amount to no more than general purpose computer components programmed to perform abstract ideas, linking to the abstract idea to a particular technological environment and insignificant, extra-solution activity. The claim recites additional elements, which includes “a computing device” (claims 1, 10, 19), “adverse healthcare event analyzer” (claims 1, 10), “a processor and memory” (claims 1, 10 and 19), “database” (claims 1, 10), “user interface” (claims 1, 10, and 19), , “computer program product” (Claim 19), “computer readable storage medium” (Claim 19), to perform the steps mentioned above.
The recitation of additional elements, is merely implemented as a tool such that it amounts to no more than adding the words “apply it” or an equivalent with the judicial exception, or mere instructions to implement an abstract idea on a computer or merely uses a computer as a tool to perform an abstract idea, (see MPEP §2106.05(f)). Further, the additional elements that recite receiving selections of the at least one individual and the adverse health event are examples of mere data gathering, which is a type of insignificant extra-solution activity (MPEP 2106.05(g)). Overall, the claims above, as a whole, individually, and in combination, these additional elements provide no integration of said abstract ideas into a practical application because they merely automate a manual process. Therefore, the claims as a whole are directed to an abstract idea.
With respect to the limitations, “wherein the data indicates that the individuals have experienced an adverse healthcare event”, the risk of the adverse healthcare event being at “a subsequent time”, and the risk being “the risk of the identified at least one individual to the specified adverse healthcare event at the subsequent time” are limitations that are examples of selecting by type or source the data to be manipulated, which is an insignificant extra-solution activity that is not sufficient to integrate the abstract idea into a practical application or amount to significantly more than the abstract idea (MPEP 2106.05(g)).
The additional elements do not integrate the abstract idea into a practical application, as there is no improvement in the functioning of a computer, technology or technical field, no particular treatment or prophylaxis for a disease or medical condition, use of a particular machine integral to the claim, transformation or reduction of subject matter to a different state or thing, or application of the abstract idea in some meaningful way beyond generally linking the use of the abstract idea to a particular technological environment.
Under Step 2B, the claims do not include additional elements that are sufficient to amount to “Significantly more” than the judicial exception because as previously mentioned, the additional elements amount to no more than generic computer components recited at a high level of generality that amount to no more than mere instruction to perform the abstract idea such that it amounts to no more than adding the words “apply it” or equivalent to apply the exception, and merely link the abstract idea to particular technological environment. The above step 2A prong 2 analysis can be applied here as well. There is no indication that the combination of elements improves the functioning of a computer or other technology. The collective functions merely provide conventional computer implementation add mere instructions to apply an exception using a generic computer component cannot provide an inventive concept. The claims are not patent eligible.
Dependent claims 3-9 and 12-18 include all the limitations of 1, 10, and 19 and therefore display the described abstract idea above. The dependent claims add additional limitations, but are nevertheless, still ineligible as analyzed below.
Claim(s) 3-9 and 12-18 recite limitations under the broadest reasonable interpretation which further define the abstract idea noted in the independent claims(s) which covers mathematical concepts and mental processes and by a human user/actor and a computer following instructions, which is considered a mental process, but in reference to use of generic computer components which are rejected because the claims listed above further define the abstract idea and do not further limit the claim to a practical application or provide an inventive concept such that would make the subject matter eligible. The mere instruction to apply the exception using a generic computer component cannot provide an inventive concept.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, 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.
Claim(s) 1, 3, 7-10, 12, and 16-19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Syed (US PG Pub. 2012/0059779) in view of Phillips (US PG Pub. 2018/0004904) in view of Guo (“An overview of semiparametric models in survival analysis”; Journal of Statistical Planning and Inference. 2013).
Claim 1
Regarding claim 1, Syed teaches
A method comprising
Abstract, “A method for assessing whether a patient is at risk of developing a clinical condition includes receiving training data representing a set of patient-related variables for each of a plurality of patients”
At a computing device comprising an adverse event health care event analyzer including a processor and memory
Par. [0161], “Some or all calculations performed in the health risk assessment embodiments described above (e.g., calculations for generating model data or determining a risk level) may be performed by a computer such as the computer 810, and more specifically may be performed by a processor such as the processing unit 820, for example. In some embodiments, some calculations may be performed by a first computer such as the computer 810 while other calculations may be performed by one or more other computers such as the remote computer 880. The calculations may be performed according to instructions that are part of a program such as the application programs 835, the application programs 845 and/or the remote application programs 885, for example.”
Receiving, from a database and at the processor, data of different types associated with a plurality of individuals
Par. [0020], “The method 100 may receive training data for a plurality of patients and target data for a target patient (block 110). The training data may include data relating to a variety of factors for each of the patients in the training sample, such as demographics (e.g., gender, age), comorbidity (e.g., presence of a particular disease), laboratory results (e.g., creatinine level, albumin level) and/or procedural factors (e.g., type of surgical procedure performed on a patient, amount of work done by a surgeon on a patient), for example.”
Wherein the data indicates that the individuals have experienced an adverse healthcare event
Par. [0037], “Moreover, although the method 200 generally does not require that training data be positively or negatively labeled, some additional predictive precision may be obtained if the system is trained based only on negative examples, i.e., if the generation of model data (block 220) is based only on training data for patients known to be free of the clinical condition(s) associated with the adverse outcome. If training data is positively and negatively labeled, for example, then in some embodiments the method 200 can achieve this by determining that portions of the training data correspond to patients positively associated with the adverse outcome, and disregarding those portions of the training data so that they are not used to generate the model data.”
Training data that is positively labeled as being associated with an adverse outcome would indicate that those positively labeled individuals have experienced an adverse healthcare event
Correlating a portion of the different types of the data to an adverse healthcare event for one or more of the individuals, wherein the other portion of types of the data is not correlated to the adverse healthcare event;
Par. [0004] Certain types of data relating to a patient population, such as surgical and diagnostic codes, may not be amenable to certain risk prediction techniques despite containing useful information
Par. [0118] The method 520 may receive training data representing a set of patient-related variables for each of a plurality of patients (block 522). In some embodiments, the training data is received from a database such as the NSW database. However, the training data could alternatively be obtained from other databases, which could include any of a variety of datasets, any registry, a corporate data store, a research data set, a surgical log, etc.
Par. [0120-0122] In some embodiments where the clinical condition is a mortality condition, the set of patient-related variables includes some or all of: functional health status prior to surgery, ASA classification, preoperative serum albumin, age, and presence of disseminated cancer… In some embodiments, where the clinical condition is a morbidity condition (e.g., one or multiple diseases, disabilities, etc.), the set of patient-related variables includes: ASA classification, work relative value unit, preoperative serum albumin, emergent vs. non-emergent case, functional health status prior to surgery, inpatient vs. outpatient case, preoperative systemic sepsis, age, steroid use for chronic condition, and weight…In some embodiments where the clinical condition is a morbidity condition, the set of patient-related variables includes: ASA classification, work relative value unit, preoperative serum albumin, emergent vs. non-emergent case, and functional health status prior to surgery
Par. [0123] In some embodiments, the set of patient-related variables excludes all variables corresponding to laboratory results. For example, the set of patient-related variables may exclude variables such as preoperative serum albumin, preoperative BUN, creatinine, and SGOT. In some embodiments, the set of patient-related variables may additionally or alternatively exclude all training data collected within a particular period of time (e.g., within the previous one year, or within the current and previous calendar year) immediately prior to receiving the training data at block 522. In some embodiments, all data collected within the year (or calendar year) that the training data is received at block 522, and/or within the preceding year (or calendar year), may be excluded. {Excluded data is considered to be not correlated}
Par. [0130], CPT codes retain information about the specific operations performed, but do not directly measure risk. Moreover, these codes span a wide range and need to be categorized before they can be used in logistic regression models for risk adjustment. If the categories are too narrowly defined, the large number of total CPT groups and the resulting small number of cases within each group make these data less useful for risk adjustment. Similarly, if the CPT codes are aggregated into broad categories of anatomic ranges as is current practice, this can greatly limit the granularity at which operational complexity, and consequently the risk associated with specific procedures, can be assessed. For example, CPT codes between 40,000 and 49,999 generally correspond to gastrointestinal operations. Within this range are included both relatively minor operations, such as inguinal hernia repair, as well as very complex procedures, such as pancreaticoduodenectomy {CPT codes needing further categorization to be useful; thus the CPT codes themselves are not directly used to measure risk and thus are not directly correlated}
Par. [0037], “Moreover, although the method 200 generally does not require that training data be positively or negatively labeled, some additional predictive precision may be obtained if the system is trained based only on negative examples, i.e., if the generation of model data (block 220) is based only on training data for patients known to be free of the clinical condition(s) associated with the adverse outcome. If training data is positively and negatively labeled, for example, then in some embodiments the method 200 can achieve this by determining that portions of the training data correspond to patients positively associated with the adverse outcome, and disregarding those portions of the training data so that they are not used to generate the model data.”
Both positively and negatively labeled examples correlate the patient’s data to the event. For positively labeled examples, there is a direct correlation between the patient data and experiencing the event. For negatively labeled examples, the training data is correlated to not experiencing the event, which is finding an inverse correlation between those patients’ data and the event.
Generating, by the processor, a regression model that relates the portion of the different types of the data
Par. [0022], “The method 100 may generate model data based on the training data (block 120).”
Par. [0138], “The method 540 may generate model data based on the received training data (block 548). In an embodiment, the model data is generated at least in part by utilizing a non-parametric learning method that maps the codes corresponding to the plurality of patients to a linear space. For example, generating the model data may include utilizing a 2-class SVM learning method.”
Par. [0090] Based on the training data x, y, the method 500 may calculate model data according to a decision rule for a 1.5-class SVM method that combines a supervised 2-class SVM method and an unsupervised I-class SVM method (block 504).
Par. [0134] The SVM training process described so far focuses on learning a model that makes binary predictions (e.g., uses CPT codes to make "hard" predictions about whether patients will experience 30-day outcomes or remain event-free depending on which side of the decision boundary they lie on). One of skill in the art can extend this training process to perform SVM regression, i.e., to make "soft" predictions of risk along a continuum. Moreover, while the above embodiments include SVM training, any non-parametric learning technique that maps codes to a linear space may be used.)
Receiving information regarding the at least one individual using a user interface
Par. [0160], “The training data and/or target data may be received over a communication medium such as local area network 871 or wide area network 873, via network interface 870 or user-input interface 860, for example.”
Applying, by the processor, the model to data of the identified at least one individual to generate an indicator of risk of the identified at least one individual to the specified adverse healthcare event
Par. [0099], “The method 500 may calculate a classification of the target data x.sub.tp, using the target data x.sub.tp and the calculated model data, according to the 1.5-class SVM decision rule (block 508) In some embodiments, the decision rule may use the decision boundary w.sup.T.phi.(x)-.rho.. In other embodiments, the decision rule may use the decision boundary w.sup.T.sup.-.phi.(x)-b.”
Par. [0100], “If the classification corresponds to a high risk of developing the clinical condition (block 510), the method 500 may indicate that the target patient is at risk of developing the clinical condition (block 512). In some embodiments, the method 500 may indicate that a target patient is at risk of an adverse outcome by setting the value of a data field representing patient risk. In some embodiments, the method 500 may indicate that a target patient is at risk of an adverse outcome by generating or providing a report.”
Displaying a graphic that visually represents the indicator via the user interface
Par. [0100], “In some embodiments, the method 500 may indicate that a target patient is at risk of an adverse outcome by generating or providing a report.”
Par. [0156], “A monitor 891 or other type of display device is also connected to the system bus 821 via an interface, such as a graphics controller 890. In addition to the monitor, computers may also include other peripheral output devices such as printer 896, which may be connected through an output peripheral interface 895.”
Par. [0162], “Indicating target patient risk, as described above in the health risk assessment embodiments, may also be performed by a computer such as the computer 810. The indications may be made by setting the value of a data field stored in the ROM memory 831 and/or the RAM memory 832, for example. In some embodiments, indicating target patient risk may include sending data over a network such as the local area network 871 or the wide area network 873 to another computer, such as the remote computer 881. In other embodiments, indicating target patient risk may include sending data over a video interface such as the video interface 890 to display information relating to risk on an output device such as the monitor 891 or the printer 896, for example.”
Displaying information on a monitor is generating a graphic with a visual indication of the values being displayed
The display monitor is connected through the graphics controller, so the output displayed on the monitor would be a graphic.
Text is a visual representation of data.
However, Syed does not teach
Receiving, via a user interface, user input to identify at least one individual for assessing the at least one individual’s risk of an adverse healthcare event at a subsequent time
Receiving, via the user interface, user input to specify the adverse healthcare event
Displaying a graphic that visually represents the indicator of risk of risk of the identified at least one individual to the specified adverse healthcare event at the subsequent time via the user interface
Phillips teaches
Receiving, via a user interface, user input to identify at least one individual for assessing the at least one individual’s risk of an adverse healthcare event at a subsequent time
Par. [0047], “At operation 310, a user of the medical documentation platform 102 selects a patient to analyze. For example, a doctor in an emergency room or a hospital administrator selects a patient from a graphical user interface or enters in a patient's name via the graphical user interface. In response to the patient selection, the medical documentation platform 102 can retrieve the patient's medical record data (e.g., from a EHR or EMR). The medical documentation platform 102 can present the patient data such as the patient's diagnostic symptoms, medical history, and demographic information.”
Par. [0019], “For example, an emergency room doctor can use the medical documentation system to predict post-discharge events for a patient experiencing chest pain (e.g., readmission to the hospital for chest pain, heart attack within three weeks of visit, or likelihood of mortality within three months). The doctor can use the likelihood of post-discharge events to recommend a plan for care.”
Predicting post-discharge events for a patient being treated in an emergency room is predicting the risk of events at a subsequent time.
Receiving, via the user interface, user input to specify the adverse healthcare event
Par. [0047], “Also, the medical documentation platform 102 can receive a diagnosis from the doctor or determine a previous diagnosis in the record. For example, a hospital administrator can enter in “heart attack” or an ICD-9 or ICD-10 code for a patient.”
Par. [0056], “Also, a user can select a diagnosis (e.g., acute heart failure, migraine, broken bone) that he or she wants to analyze for a given patient. Selecting a diagnosis can link the evidence-based models and risk variables associated with the symptom diagnosis.”
Par. [0019], “For example, an emergency room doctor can use the medical documentation system to predict post-discharge events for a patient experiencing chest pain (e.g., readmission to the hospital for chest pain, heart attack within three weeks of visit, or likelihood of mortality within three months).”
It would have been obvious to one having ordinary skill in the art before the effective filing date of this application to add to the to add to the system of Syed the ability to use a user interface to receive an identification of at least one individual and an occurrence in order to determine the risk of the individual experiencing the occurrence, as taught by Phillips, because it can assist in improving patient care by allowing a doctor to “use the likelihood of post-discharge events to recommend a plan for care” (Phillips, par. [0019]).
Phillips further teaches
Displaying a graphic that visually represents the indicator of risk of risk of the identified at least one individual to the specified adverse healthcare event at the subsequent time via the user interface
Par. [0019], “For example, an emergency room doctor can use the medical documentation system to predict post-discharge events for a patient experiencing chest pain (e.g., readmission to the hospital for chest pain, heart attack within three weeks of visit, or likelihood of mortality within three months). The doctor can use the likelihood of post-discharge events to recommend a plan for care.”
Par. [0056], “Also, a user can select a diagnosis (e.g., acute heart failure, migraine, broken bone) that he or she wants to analyze for a given patient. Selecting a diagnosis can link the evidence-based models and risk variables associated with the symptom diagnosis.”
Par. [0059], “FIG. 8 is a GUI displaying outputs or predictive statistical results for a variety of evidence-based models. For example, the GUI is displaying results for the following models: EFFECT-30d, OPTIMIZE-HF, EFFECT-1yr. The GUI can include a description of the evidence-based model used and some statistical results for the model form. A user can select the post-discharge data and readmission button to display the GUI shown in FIG. 9.”
The generated chart displayed in the example user interface shown in Fig. 8 is a graphic, and the numerical risk displayed is a visual representation of the indicator of risk determined by the system.
It would have been obvious to one having ordinary skill in the art before the effective filing date of this application to add to the system of Syed and Phillips the ability to display a graphic that visually represent the indicator of risk via the user interface, as taught by Phillips, because it is a simple substitution of one known prior art element (the generically described displaying of results on an output monitor using a graphics controller in Syed) with another known prior art element (the chart displaying the patient’s risk indication in Phillips) combined according to known methods (programming the system of Syed to output the reports of the data in the format of the chart in Phillips) to achieve predictable results (a system that can make a determination of risk and output the determination of risk in a visual chart in a graphical user interface), with no further Graham v. Deere considerations (MPEP 2143.I.B).
Although not explicitly taught by Syed or Phillips, Guo teaches a regression model that relates the portion of the different types of the data… based on the correlation of the portion of the data….wherein the regression model includes covariates that are associated with the different types of the data and wherein weights are assigned to the covariates for generating an indicator of risk to the adverse healthcare event (page 2: Multivariate survival outcomes are often investigated in many studies. They can be the survival events from a clustered group of subjects, different types of survival outcomes from the same subject, difference cause-specific survival time, the repeated occurrence of the same type of event in the same subject and the presence of multiple outcomes of which survival event is one; page 3: The most popular semiparameteric model for data fitting is the Cox proportional hazards model, which is the cornerstone of modern survival analysis. Given the vector of covariates Z, this model is specified by a hazard function involving a vector of unknown regression coefficients and an unknown baseline hazard function. The covariate effects act multiplicatively on the hazard function) {the regression coefficients being weights}.
It would have been obvious to one having ordinary skill in the art before the effective filing date of this application to modify the regression model of Syed to adapt the Cox Proportional Hazard model and include covariates associated with the different data and assign weights to the covariates to generate an indicator of risk, as taught by Guo, because doing so allows for the adjustment of multiple quantitative risk factors resulting in more accurate and precise modeling to be performed in generating a risk indication which would lead to more effective decision-making for the affected individual.
Claims 10 and 19 provide substantially similar limitations as those already addressed in claim 1, but applied to a system and a computer program product. (Syed [0015] The disclosed system utilizes anomaly detection methods and variations thereof to assess the risk of an adverse outcome. Although anomaly detection methods allow unsupervised learning and do not require positively and negatively labeled training data, they still can provide a useful prediction of risk. This predictive ability of anomaly detection methods supports the hypothesis that patients who differ the most from other patients in a population, in any direction, are likely to be at an increased risk of an adverse outcome. Syed [Claim 8] A computer-readable storage medium comprising computer-readable instructions to be executed on a processor of a system for assessing whether a patient is at risk of developing a clinical condition, the instructions when executed cause the processor to…)
Claim 3 recites wherein the data associated with a plurality of individuals comprises one or more of demographic information of the individuals, homelife information of the individuals, cognition information of the individuals, daily living information of the individuals, chronic conditions of the individuals, geographic locations associated with the individuals, and avoidable healthcare-related outcome information associated with the individuals (Syed [0020] The method 100 may receive training data for a plurality of patients and target data for a target patient (block 110). The training data may include data relating to a variety of factors for each of the patients in the training sample, such as demographics (e.g., gender, age), comorbidity (e.g., presence of a particular disease), laboratory results (e.g., creatinine level, albumin level) and/or procedural factors (e.g., type of surgical procedure performed on a patient, amount of work done by a surgeon on a patient), for example. Although the method 100 does not generally require that training data include label data indicating whether each of the plurality of patients is positively associated with the adverse outcome, the training data may or may not include such label data. In some embodiments, the training data may lack label data because the outcomes (e.g., 30-day mortality or morbidity outcomes) for some or all of the plurality of patients have not yet occurred and therefore cannot yet be known. The target data corresponds to the patient whose risk is being assessed (i.e., the target patient), and may include data relating to some or all of the factors to which the training data relates.)
Claim 12 is rejected under 103 similarly to Claim 3, as they recite identical terms, but applied to a system and dependent from claim 10.
Claim 7 recites wherein the steps of receiving, correlating, generating and apply are implemented at a first computing device comprising at least one processor and memory, and wherein the step of presenting is implemented at a second computing device comprising the user interface. (Syed [0160] The methods of the health risk assessment embodiments described above may be implemented in part or in their entirety using one or more computer systems such as the computer system 800 illustrated in FIG. 10. The training data and/or target data may be received by a computer such as the computer 810, for example. The training data and/or target data may be received over a communication medium such as local area network 871 or wide area network 873, via network interface 870 or user-input interface 860, for example. As another example, the training data and/or target data may be received from a remote source such as the remote computer 880 where the data is initially stored on memory device such as the memory storage device 881. [0161] Some or all calculations performed in the health risk assessment embodiments described above (e.g., calculations for generating model data or determining a risk level) may be performed by a computer such as the computer 810, and more specifically may be performed by a processor such as the processing unit 820, for example. In some embodiments, some calculations may be performed by a first computer such as the computer 810 while other calculations may be performed by one or more other computers such as the remote computer 880. [0162] Indicating target patient risk, as described above in the health risk assessment embodiments, may also be performed by a computer such as the computer 810. The indications may be made by setting the value of a data field stored in the ROM memory 831 and/or the RAM memory 832, for example. In some embodiments, indicating target patient risk may include sending data over a network such as the local area network 871 or the wide area network 873 to another computer, such as the remote computer 881. In other embodiments, indicating target patient risk may include sending data over a video interface such as the video interface 890 to display information relating to risk on an output device such as the monitor 891 or the printer 896, for example.)
Claim 16 is rejected under 103 similarly to Claim 7, as they recite identical terms, but applied to a system and dependent from claim 10.
Claim 8 recites further comprising communicating, by the first computing device, the indicator to the second computing device. (Syed [159] The communications connections 870, 872 allow the device to communicate with other devices. The communications connections 870, 872 are an example of communication media. The communication media typically embodies computer readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media: A "modulated data signal" may be a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media. Computer readable media may include both storage media and communication media.)
Claim 17 is rejected under 103 similarly to Claim 8 as they recite identical terms, but applied to a system and dependent from claim 10.
Claim 9 recites wherein the steps of receiving, correlating, generating and apply are implemented at a first computing device comprising at least one processor and memory, and wherein receiving the data comprises receiving the data from a second computing device comprising memory including the database. ([0149] data and/or target data may also be received from a remotely-accessible, free standing memory device on the network 700 (not shown). In some embodiments, the training data and/or target data may be received by more than one computer. In other embodiments, the training data and/or target data may be received from more than one computer and/or remotely-accessible memory device.) [0152] FIG. 10 illustrates an exemplary block diagram of a computer system 800 on which an exemplary personalized health risk assessment method may operate in accordance with the described embodiments. The computer system 800 of FIG. 10 in includes a computing device the form of a computer 810. Components of the computer 810 may include, but are not limited to, a processing unit 820, a system memory 830, and a system bus 821 that couples various system components including the system memory to the processing unit 820. The system bus 821 may be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. [0161] Some or all calculations performed in the health risk assessment embodiments described above (e.g., calculations for generating model data or determining a risk level) may be performed by a computer such as the computer 810, and more specifically may be performed by a processor such as the processing unit 820, for example. In some embodiments, some calculations may be performed by a first computer such as the computer 810 while other calculations may be performed by one or more other computers such as the remote computer 880.)
Claim 18 is rejected under 103 similarly to Claim 9, as they recite identical terms, but applied to a system and dependent from claim 10.
Claim(s) 4-5 and 13-14 is/are rejected under 35 U.S.C. 103 as being unpatentable over the combination of Syed and Phillips and Guo, in further view of Boden (US PG Pub. 2002/0019753).
Claim 4 recites, wherein the adverse healthcare event comprises institutionalization admission, hospital admission, and death.
Syed does not disclose: wherein the adverse healthcare event comprises institutionalization admission, hospital admission, and death.
However, Boden discloses [0063] The Health Status web page, is for Health Status data, and is shown in FIGS. 27-29. As seen in those screen shots, the health status data to be input on this web page comprises hospitalizations, rehabilitation admissions, nursing home admissions, weight, health notes, skills assessment, toileting, driving skills, required equipment, home environment, and cognitive status. Further, once all of the data for the individual is input pertaining to these issues, a thorough and informative report of the individual's health is presented and preserved and accessible at some point in the future with the click of a button.
Therefore, it would have been obvious to one of ordinary skill in the art of patient management before the effective filing date of the claimed invention to modify the method for assessing whether a patient is at risk of developing a clinical condition as disclosed by Syed, to incorporate the data as disclosed in Boden to apply the method for assessing patient risk to patients who have severe health issues. Including said health status data would allow for a more focused data set to further provide more information to model, allowing for healthcare facilities to not miss any indication of risk and provide the proper care to the patients.
Claim 13 is rejected under 103 similarly to Claim 4, as they recite identical terms, but applied to a system and dependent from claim 10.
Claim 5 discloses wherein the adverse healthcare event comprises nursing home admission.
Syed does not disclose: wherein the adverse healthcare event comprises nursing home admission.
However, Boden discloses: [0063] The Health Status web page, is for Health Status data, and is shown in FIGS. 27-29. As seen in those screen shots, the health status data to be input on this web page comprises hospitalizations, rehabilitation admissions, nursing home admissions, weight, health notes, skills assessment, toileting, driving skills, required equipment, home environment, and cognitive status. Further, once all of the data for the individual is input pertaining to these issues, a thorough and informative report of the individual's health is presented and preserved and accessible at some point in the future with the click of a button.
Therefore, it would have been obvious to one of ordinary skill in the art of patient management before the effective filing date of the claimed invention to modify the method for assessing whether a patient is at risk of developing a clinical condition as disclosed by Syed, to incorporate the data as disclosed in Boden to apply the method for assessing patient risk to patients who have severe health issues. Including said health status data would allow for a more focused data set to further provide more information to model, allowing for healthcare facilities to not miss any indication of risk and provide the proper care to the patients.
Claim 14 is rejected under 103 similarly to Claim 5, as they recite identical terms, but applied to a system and dependent from claim 10.
Claim(s) 6 and 15 is/are rejected under 35 U.S.C. 103 as being unpatentable over the combination of Syed and Phillips and Guo, in further view of Hasan (US PG Pub. 2007/0027720).
Claim 6 discloses wherein the data in the database comprises administrative claims data and/or in-person assessment data.
Syed does not disclose wherein the data in the database comprises administrative claims data and/or in-person assessment data.
However, Hasan discloses: [0054] The PHR system102 may include a PHR population engine 202 to populate and/or update the PHRs in the PHR database 200. The PHR population engine 202 may collect data from a wide variety of sources, such as medical claims, pharmacy claims, orders and results from laboratory systems, admission summaries, op report and discharge summaries from custom and standard hospital interfaces, and manually entered information from surveys, health risk assessments and direct entry. In some cases, manually entered data may be inputted by the patients themselves or representative from health plans, provider offices, hospitals, etc. By populating the PHRs from a variety of sources, the PHRs would not be limited to the data available from individual practices and hospitals. The table below shows a variety of sources from which the PHR may be populated, according to one embodiment, along with example information that may be gleaned from each source: TABLE-US-00001 SOURCE METHOD OF COLLECTION 1. Patients Answers to questionnaires and surveys. Regular entries pertaining to management of their conditions, such as home blood glucose levels, airway test results, etc., to track the progress of the disease condition. Patients may also directly enter information, such as over the counter drugs, immunizations and allergies, into their PHR directly by connecting to the PHR system. 2. Health Plans Directly collecting the claims data from the claim processing systems on a periodic (e.g., daily basis) or real time basis. Deriving the data to obtain clinical information. This information may also be entered directly into PHRs by persons associated with the health plans, such as case and disease managers. 3. Pharmacy Benefits Electronic tape or direct access to obtain Manager ("PBM") data relating to prescriptions. 4. Labs From the lab systems using Universal interfaces (e.g., HL7) or customized interfaces. 5. Imaging Centers From the Imaging Center Systems using Universal (HL7) or customized interfaces. 6. Freestanding Outpatient From the EMR of the facility using Facilities Universal or customized interfaces. 7. Hospitals Information imported from the respective EMR's of the hospital using Universal Interfaces (such as HL7) or customized interfaces. 8. Physicians a. From the claims submitted to the payers b. direct online notes or input to the PHR.
Therefore, it would have been obvious to one of ordinary skill in the art of patient management before the effective filing date of the claimed invention to modify the method for assessing whether a patient is at risk of developing a clinical condition as disclosed by Syed, to incorporate the data as disclosed in Hasan to apply the method for assessing patient risk to patients to who have severe health issues. Including in person assessment and claims data would allow for the data applied to the model for indicating risk to be more focused, allowing healthcare facilities to not miss any indication of risk and provide the proper care to the patients.
Claim 15 is rejected under 103 similarly to Claim 6, as they recite identical terms, but applied to a system and dependent from claim 10.
Double Patenting
Claims 1, 7-10 and 16-19 are provisionally rejected on grounds of non-statutory double patenting in view of the claims 1, 7-10, and 16-19 of copending application 17/359,821.
Although not identical, the instant claims are an obvious variant of the invention defined in the claims of the conflicting patent 17/359,821.
Claims 1, 10, and 19 of US 17/359,821 includes the limitations of the examined claims 1, 10 and 19 except that
The data related to a plurality of individuals is related to an avoidable healthcare event instead of an adverse healthcare event as recited in the instant application
In regards to claim 10 specifically, the use of an avoidable healthcare event analyzer instead of an adverse healthcare analyzer as recited in the instant application
As disclosed in claim 4 of both applications, the definitions of an avoidable healthcare event and an avoidable healthcare event recite similar limitations such as hospital/hospital admission, but with adverse healthcare event applying to an institutionalization admission and death and an avoidable healthcare event comprising an emergency facility visit. It would have been obvious to one of ordinary skill in the art to apply the method, system and computer program product of 17/359,821 to an adverse healthcare event as both data types recite similar limitations and because the method, system, and product as disclosed in 17/359,797 would benefit the analysis of adverse healthcare events and limit the avoidable outcomes of patients.
Claims 7-9, 10 and 16-18 of both 17/359,797 and 17/359,821 recite identical terms but applied to the methods and systems disclosed in claim 10 and 11 of both 17/359,797 and 17/359,821.
Application 17/359,821
Application 17/359,797
1. A method comprising: at a computing device comprising an adverse healthcare event analyzer including a processor and memory: receiving, from a database and at the processor, data of different types associated with a plurality of individuals, wherein the data indicates that the individuals have experienced an avoidable healthcare event; correlating, by the processor, a portion of the different types of the data to the avoidable healthcare event for one or more of the individuals, wherein the other portion of types of the data is not correlated to the avoidable healthcare event; generating, by the processor, a regression model that relates the portion of the different types of the data to the avoidable healthcare event based on the correlation of the data to the avoidable healthcare event, wherein the regression model includes covariates that are associated with different types of the data, and wherein weights are assigned to the covariates for generating an indicator of risk to the avoidable healthcare event; receiving, via a user interface, user input to identify at least one individual for assessing the at least one individual's risk of the avoidable healthcare event at a subsequent time; receiving, via the user interface, user input to specify the adverse healthcare event; applying, by the processor, the model to data of the identified at least one individual to generate an indicator of risk of the identified at least one individual to the specified avoidable healthcare event; and displaying a graphic that visually represents the indicator of risk of the identified at least one individual to the specified avoidable healthcare event at the subsequent time via the user interface.
1. A method comprising: at a computing device comprising an adverse healthcare event analyzer including a processor and memory: receiving, from a database and at the processor, data of different types associated with a plurality of individuals wherein the data indicates that the individuals have experienced an adverse healthcare event; correlating, by the processor, a portion of the different types of the data to the adverse healthcare event for one or more of the individuals, wherein the other portion of types of the data is not correlated to the adverse healthcare event; generating, by the processor, a regression model that relates the portion of the different types of the data to the adverse healthcare event based on the correlation of the portion of the data to the adverse healthcare event, wherein the regression model includes covariates that are associated with the different types of the data, and wherein weights are assigned to the covariates for generating an indicator of risk to the adverse healthcare event; receiving, via a user interface, user input to identify at least one individual for assessing the at least one individual's risk of the adverse healthcare event at a subsequent time; receiving, via the user interface, user input to specify the adverse healthcare event; applying, by the processor, the model to data of the identified at least one individual to generate an indicator of risk of the identified at least one individual to the specified adverse healthcare event; and displaying a graphic that visually represents the indicator of risk of the identified at least one individual to the specified adverse healthcare event at the subsequent time via the user interface.
10. A system comprising: a database comprising data associated with a plurality of individuals; a computing device comprising an avoidable healthcare event analyzer including a processor and memory configured to: receive data of different types associated with a plurality of individuals, wherein the data indicates that the individuals have experienced an avoidable healthcare event; correlate a portion of the different types of the data to an avoidable healthcare event for one or more of the individuals, wherein the other portion of types of the data is not correlated to the avoidable healthcare event; generate a regression model that relates the data to the avoidable healthcare event based on the correlation of the data to the avoidable healthcare event, wherein the regression model includes covariates that are associated with different types of the data, and wherein weights are assigned to the covariates for generating an indicator of risk to the avoidable healthcare event; receive, via a user interface, user input to identify at least one individual for assessing the at least one individual’s risk of the avoidable healthcare event at a subsequent time; and apply the model to data of another individual to generate an indicator of risk of the other individual to the avoidable healthcare event; and a user interface configured to display a graphic that visually represents the indicator of risk of the identified at least one individual to the specified avoidable healthcare event at the subsequent time.
10. A system comprising: a database comprising data associated with a plurality of individuals; a computing device comprising an adverse healthcare event analyzer including a processor and memory configured to: receive data associated with a plurality of individuals, wherein the data indicates that the individuals have experienced an adverse healthcare event; correlate a portion of the different types of the data to an adverse healthcare event for one or more of the individuals, wherein the other portions of types of the data is not correlated to the adverse healthcare event; generate a regression model that relates the portion of the different types of the data to the adverse healthcare event based on the correlation of portion of the data to the adverse healthcare event, wherein the regression model includes covariates that are associated with different types of the data, and wherein weights are assigned to the covariates for generating an indicator of risk to the adverse healthcare event; receive, via a user interface, user input to identify at least one individual for assessing the at least one individual’s risk of the adverse healthcare event at a subsequent time; and apply the model to data of another individual to generate an indicator of risk of the other individual to the adverse healthcare event; and a user interface configured to display a graphic that visually represents the indicator of risk of the identified at least one individual to the specified adverse healthcare event at the subsequent time.
19. A computer program product comprising a computer readable storage medium having program instructions embodied therewith, the program instructions executable by a computing device to cause the computing device to: receive, at the computing device, data of different types associated with a plurality of individuals, wherein the data indicates that the individuals have experienced an avoidable healthcare event; correlate, at the computing device, a portion of the different types of the data to an avoidable healthcare event for one or more of the individuals, wherein the other portion of the types of the data is not correlated to the avoidable healthcare event; generate, at the computing device, a regression model that relates the portion of the different types of the data to the avoidable healthcare event based on the correlation of the data to the avoidable healthcare event, , wherein the regression model includes covariates that are associated with different types of the data, and wherein weights are assigned to the covariates for generating an indicator of risk to the avoidable healthcare event; receive, at the computing device, user input entered at a user interface to identify at least one individual for assessing the at least one individual’s risk of the avoidable healthcare event at a subsequent time; receive, at the computing device, user input entered at the user interface to specify the avoidable healthcare event; apply, at the computing device, the model to data of another individual to generate an indicator of risk of the other individual to the avoidable healthcare event; and utilize, at the computing device, the user interface to display a graphic that visually represents the indicator of the identified at least one individual to the specified avoidable healthcare event at the subsequent time.
19. A computer program product comprising a computer readable storage medium having program instructions embodied therewith, the program instructions executable by a computing device to cause the computing device to: receive, at the computing device, data of different types associated with a plurality of individuals, wherein the data indicates that the individuals have experienced an adverse healthcare event; correlate, at the computing device, a portion of the different types of the data to an adverse healthcare event for one or more of the individuals, wherein the other portion of types of the data is not correlated to the adverse healthcare event; generate, at the computing device, a regression model that relates the portion of the different types of the data to the adverse healthcare event based on the correlation of the data to the adverse healthcare event, wherein the regression model includes covariates that are associated with different types of the data, and wherein weights are assigned to the covariates for generating an indicator of risk to the adverse healthcare event; receive, at the computing device, user input entered at a user interface to identify at least one individual for assessing the at least one individual’s risk of the adverse healthcare event at a subsequent time; receive, at the computing device, user input entered at the user interface to specify the adverse healthcare event; apply, at the computing device, the model to data of another individual to generate an indicator of risk of the other individual to the adverse healthcare event; and utilize, at the computing device, the user interface to display a graphic that visually represents the indicator of the identified at least one individual to the specified adverse healthcare event at the subsequent time.
7. The method of claim 1, wherein the steps of receiving, correlating, generating and apply are implemented at a first computing device comprising at least one processor and memory, and wherein the step of presenting is implemented at a second computing device comprising the user interface.
7. The method of claim 1, wherein the steps of receiving, correlating, generating and apply are implemented at a first computing device comprising at least one processor and memory, and wherein the step of presenting is implemented at a second computing device comprising the user interface.
8. The method of claim 7, further comprising communicating, by the first computing device, the indicator to the second computing device.
8. The method of claim 7, further comprising communicating, by the first computing device, the indicator to the second computing device.
9. The method of claim 1, wherein the steps of receiving, correlating, generating and apply are implemented at a first computing device comprising at least one processor and memory, and wherein receiving the data comprises receiving the data from a second computing device comprising memory including the database.
9. The method of claim 1, wherein the steps of receiving, correlating, generating and apply are implemented at a first computing device comprising at least one processor and memory, and wherein receiving the data comprises receiving the data from a second computing device comprising memory including the database.
16. The system of claim 1, wherein the functions of receiving, correlating, generating and apply are implemented at a first computing device comprising at least one processor and memory, and wherein the function of presenting is implemented at a second computing device comprising the user interface.
16. The system of claim 1, wherein the functions of receiving, correlating, generating and apply are implemented at a first computing device comprising at least one processor and memory, and wherein the function of presenting is implemented at a second computing device comprising the user interface.
17. The system of claim 16, wherein the first computing device is configured to communicate the indicator to the second computing device.
17. The system of claim 16, wherein the first computing device is configured to communicate the indicator to the second computing device.
18. The system of claim 10, wherein the functions of receiving, correlating, generating and apply are implemented at a first computing device comprising at least one processor and memory, and wherein the data is received at the first computing device from a second computing device comprising memory including the database.
18. The system of claim 10, wherein the functions of receiving, correlating, generating and apply are implemented at a first computing device comprising at least one processor and memory, and wherein the data is received at the first computing device from a second computing device comprising memory including the database.
Response to Arguments
Double Patenting
The Applicant responded to the provisional double patenting rejection by opting to hold it in abeyance until later in prosecution. For this reason, the provisional double patenting rejection will be sustained.
101 Rejections
Applicant's arguments filed August 7, 2025, have been fully considered but they are not persuasive.
Applicant argues that the amended limitation of “generating a regression model including covariates that are associated with the different types of the data, and wherein weights are assigned to the covariates for generating an indicator of risk to the adverse healthcare event” is patent eligible subject matter under 35 USC 101 as a practical application.
This argument is not persuasive. The generated regression model is considered to be abstract; in particular, it is an abstract idea that can be categorized in the “mathematical concepts” grouping. An abstract idea cannot integrate itself into a practical application.
Applicant argues that generating an indicator of risk for an “adverse healthcare event” is a specific, real-world outcome in the healthcare domain.
This argument is not persuasive. Again, generating an indicator of risk is considered to be part of the abstract idea recited in the claims.
Applicant argues that claim 1 involves “covariates that are associated with different types of the data” and “weights associated to the covariates”, suggesting a tailored process for handling diverse, complex datasets.
This argument is not persuasive. As noted above, the recitation of a regression model that includes covariates associated with different types of data and weights associated to the covariates is considered to be an abstract idea of the “mathematical concepts” grouping. Any technological improvement is evaluated with respect to the additional elements beyond the abstract idea, rather than the abstract idea itself. Any improvement to the abstract idea would not change the disposition that the claim recites an abstract idea. The Supreme Court’s decisions make it clear that judicial exceptions need not be old or long-prevalent, and that even newly discovered or novel judicial exceptions are still exceptions. MPEP 2106.04(I).
Applicant argues that the “indicator of risk” is not merely an abstract mathematical result but a tangible output that can guide clinical decision-making, and thus is a transformation of raw data into a specific, actionable metric. Applicant argues that the risk indicator enables healthcare providers to take concrete actions, such as preventative measures, to mitigate adverse events.
This argument is not persuasive. Generating an “indicator of risk” is not a transformation of subject matter to a different state or thing. Per MPEP 2106.05(c), purely mental processes in which thoughts or human based actions are "changed" are not considered an eligible transformation. For data, mere "manipulation of basic mathematical constructs [i.e.,] the paradigmatic ‘abstract idea,’" has not been deemed a transformation. CyberSource v. Retail Decisions, 654 F.3d 1366, 1372 n.2, 99 USPQ2d 1690, 1695 n.2 (Fed. Cir. 2011)
Further, the claim does not recite any action taken by a healthcare provider; the scope of the claim ends when the indicator of risk is graphically displayed via a user interface.
For at least the foregoing reasons, the arguments against the 101 rejections are not persuasive, and the 101 rejections will be sustained.
Prior Art Rejections
Applicant's arguments filed August 7, 2025, have been fully considered but they are not persuasive.
With respect to the argument that the Office Action “admits at page 9 that Syed does not disclose the claim 1 feature of ‘correlating’ so it cannot teach or suggest implementing the aforementioned features as well”, this argument is incorrect.
The Office Action dated April 15, 2025 (hereafter, the Final Rejection), does not make an admission that the Syed reference does not teach “correlating”. Page 9 of that Office Action does not make any admissions regarding what is not taught by the primary reference. Those admissions are made on page 12 of the Final Rejection, and none of the admissions made there relate to the correlating step. Rather, page 9 of the Final shows that the Syed reference does teach a correlating step.
Because Syed teaches a correlating step, all of the arguments regarding the prior art depending on the assertion that Syed does not teach a correlating step are not persuasive.
Additionally, the claim rejections have been updated in order to address all of the newly added claim limitations, incorporating a new prior art reference, Guo.
For at least the foregoing reasons, the arguments against the prior art rejections are not persuasive.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Jung (US PGPubs 20080082359, 20080081957, 20080082503, 20080082500)
Kocis (US Patent 10163174 and US PGPub 20130197924)
Dugger (WO 2019217876)
Any inquiry concerning this communication or earlier communications from the examiner should be directed to PETER H CHOI whose telephone number is (469)295-9171. The examiner can normally be reached M-Th 9am-7pm.
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.
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.
/PETER H CHOI/Supervisory Patent Examiner, Art Unit 3681
