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 .
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 06/01/2026 has been entered.
Formal Matters
Applicant's response, filed 06/01/2026, has been fully considered. The following rejections and/or objections are either reiterated or newly applied. They constitute the complete set presently being applied to the instant application.
Status of Claims
Claims 1-16 and 20 are currently pending and have been examined.
Claims 1 and 7 have been amended.
Claims 17-19 have been canceled.
Claims 1-16 and 20 have been rejected.
Priority
The instant application claims the benefit of priority under 35 U.S.C 119(e) or under 35 U.S.C. § 120, 121, or 365(c). Accordingly, the effective filing date for the instant application is 03 March 2021 claiming benefit to Provisional Applications 63/155,899 and 63/210,661.
Objections
Examiner acknowledges that appropriate correction to the previous objections have been made and withdraws the objections accordingly.
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-16 and 20 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.
Step 1 – Statutory Categories of Invention:
Claims 1-16 and 18-20 are drawn to a method or system, which are statutory categories of invention.
Step 2A – Judicial Exception Analysis, Prong 1:
Independent claim 1 recites a method in part performing the steps of providing electronic medical records (EMR) data; normalizing the EMR data; comparing the normalized EMR data with one or more threshold values, wherein the comparison determines whether medical test results are within a normal range, close to boundaries of the normal range, or outside of the normal range; displaying a plurality of medical test results, wherein the plurality of medical test results is displayed differently based on a selected user preference to indicate the medical test results that are within the normal range, close to the boundaries of the normal range, or outside of the normal range; formatting the medical data into a homogeneous format based on a predetermined preference value defining a default display particular to a type of user, wherein the type of user is a patient; converting the medical data into one or more graph elements compatible with [a device]; displaying the normalized medical information; prompting the patient to take action based on the compared data via a prompt; providing, in association with the prompt provided to the patient to take action based on the compared data, a confirmation dialog, wherein further access to [data on an interface] is secured behind the confirmation dialog; combining the data with a user input, the user input comprising an identity of the patient; and displaying, in the event of an alert, the plurality of medical test results in the form of a traditional medical chart; wherein the EMR data comprises patient test results from a plurality of medical tests having a correlation with presence or absence of a disease or a risk of the disease; and wherein normalizing the EMR data further comprises: individually weighing results of each medical test of the plurality of medical tests, wherein individually weighing results of each medical test comprises multiplying the results of each medical test by a predictive value weight factor and a normalized health measurement or observation so as to obtain the individually weighted medical test; and combining the individually weighted medical test results to generate the normalized EMR data, wherein combining the individually weighted medical test results comprises calculating a sum of the individually weighted medical tests and dividing the sum by the total amount of the individually weighted medical tests; wherein the [interface] displays medical data with the default laboratory results upon a selection of the user.
Independent claim 7 recites a system in part performing the steps of normalize the data, compare the normalized data with one or more threshold values, wherein the comparison determines whether medical test results are within a normal range, close to boundaries of the normal range, or outside of the normal range, format the medical data into a homogeneous format based on a predetermined preference value defining a default display particular to a type of user, wherein the type of user is a patient, and convert the medical data into one or more graph elements; and display the normalized medical information, prompt taking action based on the compared data via a prompt, provide, in association with the prompt provided to the patient to take action based on the compared data, a confirmation dialog, wherein further access to [data on an interface] is secured behind the confirmation dialog, and combine the data with a user input, the user input comprising an identity of the user’ wherein the data comprises patient test results from a plurality of medical tests having a correlation with presence or absence of a disease or risk of the disease; and wherein the data is normalized by: individually weighing results of each medical test of the plurality of medical tests, wherein individually weighing results of each medical test comprises multiplying the results of each medical test by a predictive value weight factor and a normalized health measurement or observation so as to obtain the individually weighted medical test; and combining the individually weighted medical test results to generate the normalized EMR data, wherein combining the individually weighted medical test results comprises calculating a sum of the individually weighted medical tests and dividing the sum by the total amount of individually weighted medical tests.
These steps of collecting, normalizing, processing, and displaying medical data to an authorized medical provider amount to methods of organizing human activity which includes functions relating to interpersonal and intrapersonal activities, such as managing relationships or transactions between people, social activities, and human behavior; satisfying or avoiding a legal obligation; advertising, marketing, and sales activities or behaviors; and managing human mental activity (MPEP § 2106.04(a)(2)(II)(C) citing the abstract idea grouping for methods of organizing human activity for `managing personal behavior or relationships or interactions between people – also note October 2019 Update: Subject Matter Eligibility on p. 5 and MPEP § 2106.04(a)(2)(II) stating certain activity between a person and a computer may fall within the “certain methods of organizing human activity” grouping).
Dependent claims 2 and 8 recite, in part, wherein the medical data comprises patient test results from a plurality of medical tests.
Dependent claims 3 and 10 recite, in part, generating and transmitting an alert based on the identification of a medical trend.
Dependent claims 4 and 11 recite, in part, [display] at least one icon associated with a subset of the transmitted medical information and which indicates at least one of a presence of a comment, a presence of additional information, or an alert.
Dependent claims 5 and 12 recite, in part, [displaying] at least one medical test result and wherein additional medical information related to the at least one medical test result is displayed in response to user interaction with the at least one medical test result [displayed].
Dependent claim 9 recites, in part, display a subset of the displayed medical information, and the subset is displayed differently to indicate the medical test results that are within the normal range, close to the boundaries of the normal range, or outside of the normal range.
Dependent claim 14 recites, in part, wherein the subset of the displayed medical information is displayed in different colors to indicate the medical test results that are within the normal range, close to the boundaries of the normal range, or outside of the normal range.
Dependent claim 15 recites, in part, wherein the selected user preference determines the graph elements that are displayed and a type of graph that is displayed.
Dependent claim 16 recites, in part, wherein the selected user preference determines an order of displayed medical test results or a type of visual indicia applied to the GUI to convey information
Dependent claim 20 recites, in part, wherein combining the individually weighted medical tests to generate the normalized EMR data is based on one or more of: a weighted multiplier based on a published predictive value of each medical test for the disease or risk of disease; a learning health system modifier weighting factor that is adjusted statistically based on new studies periodically refining a goodness of fit of each medical test for the disease or risk of disease; and a learning health system weighting factor that is adjusted based on artificial intelligence, machine learning, or an algorithm refining the goodness or properness of fit of each medical test for the disease or risk of disease.
Each of these steps of the preceding dependent claims 2-5, 8-12, and 14-20 only serve to further limit or specify the features of independent claims 1 or 7 accordingly, and hence are nonetheless directed towards fundamentally the same abstract idea as the independent claim and utilize the additional elements already analyzed in the expected manner.
Step 2A – Judicial Exception Analysis, Prong 2:
This judicial exception is not integrated into a practical application because the additional elements within the claims only amount to instructions to implement the judicial exception using a computer [MPEP 2106.05(f)].
Claim 1 recites a processor. Claim 1 and 7 recites a user device configured to present a graphical user interface (GUI) on a display to a user. Claims 1 and 7 recites an electronic medical records (EMR) server [having a processor and a memory]. Claims 16 and 17 recite a graphical user interface for displaying data. The specification states that the software executing the abstract idea can be utilized on any device with a display and network connectivity (Detailed Description in ¶ 0044). The use of a processor, user device configured to present a graphical user interface (GUI) on a display to a user, and electronic medical records (EMR) server [having a processor and a memory] is only recited as a tool to apply data to an algorithm and report the results (MPEP § 2106.05(f)(2) see case involving a commonplace business method or mathematical algorithm being applied on a general purpose computer within the “Other examples.. i.”) amounting to instruction to implement the abstract idea using a general purpose computer. Alice Corp. Pty. Ltd. V. CLS Bank Int’l, 134 S. Ct. 2347, 1357 (2014).
Claims 1 and 7 recite providing connectivity for data interchange between the user device and an electronic medical records (EMR) server. The limitations are only recited as a tool which only serves to input data for use by the abstract idea (MPEP § 2106.05(g) - insignificant pre/post-solution activity that amounts to mere data gathering to obtain input) and is therefore not a practical application of the recited judicial exception.
Claims 1 and 7 recite allowing the user device to request the EMR data and receive the EMR data from the EMR server. Claims 1 and 7 recite a transmitting, from the EMR server to the user device, in response to at least one of a request provided to the EMR server by the user device or an alert, a data set comprising medical information provided in the memory of the EMR server. The limitations are only recited as a tool which only serves to input data for use by the abstract idea (MPEP § 2106.05(g) - insignificant pre/post-solution activity that amounts to mere data gathering to obtain input) and is therefore not a practical application of the recited judicial exception.
Claim 1 recites displaying medical information on the user device. Claims 1 and 7 recite a push notification sent to a device. Claim 1 recites displaying in response to a user click on the alert. The limitations are only recited as a tool which only serves as display/output of the data determined from the abstract idea (MPEP § 2106.05(g) - insignificant pre/post-solution activity that amounts to post-solution output on a well-known display device) and is therefore not a practical application of the recited judicial exception.
Claim 6 recites a transmitting the EMR data from at least one of a cloud service or an HL7 server. Claim 13 recites a wherein the server is one of an HL7 FHIR server or a cloud service. The specification provides no extra detail regarding these servers (see the Summary in ¶ 0005). The cloud or HL7 server types only serve as extra solution activities incidental to the primary process that is merely a nominal or tangential addition to the claim (MPEP § 2106.05(g) - selecting a particular data source or type of data to be manipulated) and is therefore not a practical application of the recited judicial exception.
The above claims, as a whole, are therefore directed to an abstract idea.
Step 2B – Additional Elements that Amount to Significantly More:
The present claims do not include additional elements that are sufficient to amount to more than the abstract idea because the additional elements or combination of elements amount to no more than a recitation of instructions to implement the abstract idea on a computer.
Claim 1 recites a processor. Claim 1 and 7 recites a user device configured to present a graphical user interface (GUI) on a display to a user. Claims 1 and 7 recites an electronic medical records (EMR) server [having a processor and a memory]. Claims 16 and 17 recite a graphical user interface for displaying data. Each of these elements is only recited as a tool for performing steps of the abstract idea, such as the use of the storage mediums to store data, the computer and data processing devices to apply the algorithm, and the display device to display selected results of the algorithm. These additional elements therefore only amount to mere instructions to perform the abstract idea using a computer and are not sufficient to amount to significantly more than the abstract idea (MPEP 2016.05(f) see for additional guidance on the “mere instructions to apply an exception”).
Each additional element under Step 2A, Prong 2 is analyzed in light of the specification’s explanation of the additional element’s structure. The claimed invention’s additional elements do not have sufficient structure in the specification to be considered a not well-understood, routine, and conventional use of generic computer components. Note that the specification can support the conventionality of generic computer components if “the additional elements are sufficiently well-known that the specification does not need to describe the particulars of such additional elements to satisfy 35 U.S.C. § 112(a)” (MPEP § 2106.07(a)(III)(A) integrating the evidentiary requirements in making a § 101 rejection as established in Berkheimer in III. Impact on Examination Procedure, A. Formulating Rejections, 1. on p. 3).
Claims 1 and 7 recite providing connectivity for data interchange between the user device and an electronic medical records (EMR) server. Claims 1 and 7 recite allowing the user device to request the EMR data and receive the EMR data from the EMR server. Claims 1 and 7 recite a transmitting, from the EMR server to the user device, in response to at least one of a request provided to the EMR server by the user device or an alert, a data set comprising medical information provided in the memory of the EMR server. The courts have decided that receiving or transmitting data over a network as well-understood, routine, conventional activity when claimed in a merely generic manner (e.g., at a high level of generality) or as insignificant extra-solution activity (MPEP § 2106.05(d)(II) other types of activities example i. receiving or transmitting data over a network, OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1093 (Fed. Cir. 2015) (sending messages over a network).
Claim 1 recites displaying medical information on the user device. Claims 1 and 7 recite a push notification sent to a device. Claim 1 recites displaying in response to a user click on the alert. The courts have decided that presenting generated data as well-understood, routine, conventional activity when claimed in a merely generic manner (e.g., at a high level of generality) or as insignificant extra-solution activity (MPEP § 2106.05(d)(II) other types of activities example iv. presenting offers and gathering statistics, OIP Techs., 788 F.3d at 1362-63, 115 USPQ2d at 1092-93).
Claim 6 recites a transmitting the EMR data from at least one of a cloud service or an HL7 server. Claim 13 recites a wherein the server is one of an HL7 FHIR server or a cloud service. The use of a cloud server or HL7 [FHIR] server to save medical data is well understood, routine, and conventional activity. This position is supported by (1) Shelton (US Patent Pub No 2018/0046753) in the Detailed Description in ¶ 0068 and (2) Vesto and Ahmed (US Patent Pub No 2019/0172590) in the Overview in ¶ 0031 - both discussing known the art compliant healthcare storage and exchange protocols including HL7 FHIR and a private cloud architecture. Therefore, the use of the cloud server and HL7 FHIR server exchange is not sufficient to amount to significantly more than the recited judicial exception.
Thus, taken alone, the additional elements do not amount to significantly more than the above-identified judicial exception. Looking at the limitations as an ordered combination adds nothing that is not already present when looking at the elements taken individually. Their collective functions merely provide conventional computer implementation.
Claims 1-16 and 18-20 are therefore rejected under 35 U.S.C. § 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.
Claims 1-16 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Blink (US Patent Application No 2015/0261920)[hereinafter Blink] in view of Tesanovic et al. (US Patent Application No. 2014/0055285)[hereinafter Tesanovic].
As per claim 1, Blink teaches on the following limitations of the claim:
a method comprising: providing a user device configured to present a graphical user interface (GUI) on a display to a user is taught in the Detailed Description in ¶ 0032, ¶ 0041, ¶ 0044, and in the Figures at fig. 10 (teaching on a user device and display with a user interface for executing the software services)
the user comprising a patient is taught in the Detailed Description in ¶ 0025 and ¶ 0037 (teaching on the user including a patient user role)
providing connectivity for data interchange between the user device and an electronic medical records (EMR) server is taught in the Detailed Description in ¶ 0025 and ¶ 0044 (teaching on a wireless network connection between the user device and the patient's electronic medical record server)
providing EMR data on the EMR server; allowing the user device to request the EMR data is taught in the Detailed Description in ¶ 0025 and in the claims at claim 1 (teaching on the user device transmitting a request to a remote server for a patient's electronic health record data )
normalizing the EMR data by a processor is taught in the Detailed Description in ¶ 0025 and in the claims at claim 1 (teaching on normalizing the received EHR data to patient values)
comparing the normalized EMR data with one or more threshold values by the processor wherein the comparison determines whether medical test results are within a normal range, close to boundaries of the normal range, or outside of the normal range is taught in the Detailed Description in ¶ 0030 and ¶ 0032 (teaching on comparing the patient values to reference ranges to determine if the values are normal, near normal, or outside the reference range)
displaying a plurality of medical test results on the user device, ... to indicate the medical test results that are within the normal range, close to the boundaries of the normal range, or outside of the normal range is taught in the Detailed Description in ¶ 0027 and ¶ 0034 (teaching on displaying on the user device, an alarm state of each patient's values wherein each alarm state is visually distinguishable)
wherein the plurality of medical test results is displayed differently based on the selected user preference is taught in the Detailed Description in ¶ 0031 and 0038 (teaching on tailoring the data according to a user type - such as patient-oriented embodiment may use different or less professional language)
transmitting, from the EMR server to the user device, in response to at least one of a request provided to the EMR server by the user device or an alert, a data set comprising medical information provided in the memory of the EMR server is taught in the Detailed Description in ¶ 0027 and ¶ 0031 (teaching on sending an alert from a central server to a user device that an alarm state is present for a particular user and the corresponding data related to said alert - here the critical results can include a “!” icon)
formatting the medical data into a homogeneous format based on a predetermined preference value defining a default display is taught in the Detailed Description in ¶ 0041 (teaching on formatting the patient's information including the data in a predetermined format (treated as synonymous to a homogeneous format based on a predetermined preference value) set by the user )
particular to a type of user, wherein the type of user is a patient is taught in the Detailed Description in ¶ 0038 (teaching on tailoring the data according to a user type - such as patient-oriented embodiment may use different or less professional language)
converting the medical data into one or more graph elements compatible with the GUI of the user device is taught in the Detailed Description in ¶ 0038 and ¶ 0041 (teaching on formatting the patient's information including the patient values on the GUI via graphical elements (here there is a display container for each monitored patient))
displaying the normalized medical information medical information through the GUI on the user device is taught in the Detailed Description in ¶ 0038 and ¶ 0041 (teaching on displaying the graphical user interface)
prompting, via a push notification sent to a device of the patient to take action based on the compared data via a prompt provided on the GUI is taught in the Detailed Description in ¶ 0027 and ¶ 0036 (teaching on a patient alert prompt to acknowledge that a critical result, medical report, or medical image was viewed on the graphical user interface)
providing, in association with the prompt provided to the patient to take action based on the compared data, a confirmation dialog, wherein further access to the GUI is secured behind the confirmation dialog is taught in the Detailed Description in ¶ 0027, ¶ 0034-36, and in the Figures at fig. 3 (teaching on a patient alert prompt to acknowledge that a critical result, medical report, or medical image was viewed (treated as synonymous to a confirmation dialog) on the graphical user interface wherein the prompt secures further access to the GUI until the confirm button is pressed)
combining the data with a user input, the user input comprising an identity of the patient; and displaying in the event of an alert and in response to a user click on the alert, the plurality of medical test results in the form of a traditional medical chart wherein the EMR data comprises patient test results from a plurality of medical tests having a correlation with presence or absence of a disease or a risk of the disease; and is taught in the Detailed Description in ¶ 0027, ¶ 0034-36, and in the Figures at fig. 3 (teaching on, after the prompt is confirmed, returning to the patient values of medical tests having a correlation with the presence of absence or risk of a disease on the GUI page (treated as synonymous with a "traditional medical chart") with the patient identifying information)
wherein normalizing the EMR data further comprises: individually weighing results of each medical test of the plurality of medical tests, wherein individually weighing results of each medical test comprises multiplying the results of each medical test by a predictive value weight factor and a normalized health measurement or observation so as to obtain the individually weighted medical test; and is taught in the Detailed Description in ¶ 0024-25 (teaching on the normalization process being based on the "CentiBlick" units as patented in US Patent 8,204,713 incorporated by reference - this is consistent with the instant specification's disclosure in ¶ 0045 of the mathematical model for normalizing the data as encompassed by the instant claim)
wherein the GUI displays medical data with the default laboratory results upon a selection of the user is taught in the Detailed Description in ¶ 0038 (teaching on tailoring the data according to a user type - such as patient-oriented embodiment may use different or less professional language)
Blink fails to teach the following limitations of claim 1. Tesanovic, however, does teach the following:
combining the individually weighted medical test results to generate the normalized EMR data, wherein combining the individually weighted medical test results comprises calculating a sum of the individually weighted medical tests and dividing the sum by the total amount of individually weighted medical tests is taught in the Summary in ¶ 0037, ¶ 0040, and in the Detailed Description in ¶ 0076-79 (teaching on calculating a weighted average for each medical test score to obtain a "weighted value" to be averaged for the medical test category wherein an average is the sum of all the values divided by the total number of values as known to one of ordinary skill in the art)
One of ordinary skill in the art before the effective filing date of the invention would combine the EHR normalization and clinical decision support specific categorical alert system of Blink with the weighted average of historical results of Tesanovic the motivation of “fine-tun[ing] the zones for the patient” (Tesanovic in the Detailed Description in ¶ 0079). Additionally, since each individual element and its function are shown in the prior art, albeit shown in separate references, the difference between the claimed subject matter and the prior art rests not on any individual element or function but in the very combination itself- that is in the substitution of the weighted sum normalization equation of Tesanovic for the data normalization means of Blumenthal. Thus, the simple substitution of one known element for another producing a predictable result renders the claim obvious.
Independent claim 7 is rejected under a similar rational.
As per claim 2, the combination of Blink and Tesanovic discloses all of the limitations of claim 1. Blumenthal also discloses the following:
the method of claim 1, wherein the medical data comprises patient test results from a plurality of medical tests is taught in the Detailed Description in ¶ 0027, ¶ 0033, and in the Figures at fig. 2 (teaching on the patient values including a plurality of test results from a plurality of visits)
Dependent claim 8 is rejected under a similar rational.
As per claim 3, the combination of Blink and Tesanovic discloses all of the limitations of claim 1. Blink also discloses the following:
the method of claim 1, further comprising: generating and transmitting an alert based on the identification of a medical trend is taught in the Detailed Description in ¶ 0027 and ¶ 0038 (teaching on sending an alert and patient report to the user based on a medical test result wherein the result is compared to a trend)
Dependent claim 10 is rejected under a similar rational.
As per claim 4, the combination of Blink and Tesanovic discloses all of the limitations of claim 1. Blink also discloses the following:
the method of claim 1, wherein the displayed GUI includes at least one icon associated with a subset of the transmitted medical information and which indicates at least one of a presence of a comment, a presence of additional information, or an alert is taught in the Detailed Description in ¶ 0027, ¶ 0034-36, and in the Figures at fig. 3 (teaching on a patient alert prompt to acknowledge that a critical result, medical report, or medical image was viewed (treated as synonymous to a confirmation dialog) on the graphical user interface wherein the prompt secures further access to the GUI until the confirm button is pressed - here the critical results can include a “!” icon)
Dependent claim 11 is rejected under a similar rational.
As per claim 5, the combination of Blink and Tesanovic discloses all of the limitations of claim 1. Blink also discloses the following:
the method of claim 1, wherein the GUI displays at least one medical test result and wherein additional medical information related to the at least one medical test result is displayed in response to user interaction with the at least one medical test result displayed on the GUI is taught in the Detailed Description in ¶ 0027, ¶ 0034-36, and in the Figures at fig. 3 (teaching on, after the prompt is confirmed, returning to the patient values of medical tests having a correlation with the presence of absence or risk of a disease on the GUI page (treated as synonymous with a "traditional medical chart") with the patient identifying information)
Dependent claim 12 is rejected under a similar rational.
As per claim 6, the combination of Blink and Tesanovic discloses all of the limitations of claim 1. Blink also discloses the following:
the method of claim 1, further comprising: transmitting the EMR data from at least one of a cloud service or an HL7 server is taught in the Detailed Description in ¶ 0044 (teaching on the patient medical information stored as an HL7)
Dependent claim 13 is rejected under a similar rational.
As per claim 14, the combination of Blink and Tesanovic discloses all of the limitations of claim 1. Blink also discloses the following:
the method of claim 1, wherein the subset of the displayed medical information is displayed in different colors to indicate the medical test results that are within the normal range, close to the boundaries of the normal range, or outside of the normal range is taught in the Detailed Description in ¶ 0030-32 and ¶ 0041-42 (teaching on the range values being distinguished by colors or other identifying aspects)
As per claim 15, the combination of Blink and Tesanovic discloses all of the limitations of claim 1. Blink also discloses the following:
the method of claim 1, wherein the selected user preference determines the graph elements that are displayed and a type of graph that is displayed is taught in the Detailed Description in ¶ 0038 and ¶ 0041 (teaching on formatting the patient's information including the patient values on the GUI via graphical elements (here there is a display container for each monitored patient))
As per claim 16, the combination of Blink and Tesanovic discloses all of the limitations of claim 1. Blink also discloses the following:
the method of claim 1, wherein the selected user preference determines an order of displayed medical test results or a type of visual indicia applied to the GUI to convey information is taught in the Detailed Description in ¶ 0038 (teaching on tailoring the data according to a user type - such as patient-oriented embodiment may use different or less professional language (treated as synonymous to "a type of visual indicia"))
As per claim 20, the combination of Blink and Tesanovic discloses all of the limitations of claim 1. Blink fails to teach the following; Tesanovic, however, does disclose:
the method of claim 1, wherein combining the individually weighted medical tests to generate the normalized EMR data is based on one or more of: a weighted multiplier based on a published predictive value of each medical test for the disease or risk of disease; a learning health system modifier weighting factor that is adjusted statistically based on new studies periodically refining a goodness of fit of each medical test for the disease or risk of disease; and a learning health system weighting factor that is adjusted based on artificial intelligence, machine learning, or an algorithm refining the goodness or properness of fit of each medical test for the disease or risk of disease is taught in the Detailed Description in ¶ 0079 (teaching on the medical tests parameter weights being adjusted according to an algorithm representative of the proportional disease event risk (treated as synonymous to an algorithm refining the goodness or properness of fit of each medical test for the disease or risk of disease) wherein the algorithm may rely on published predictive value from a population database of each medical test for the disease or risk of disease).
One of ordinary skill in the art before the effective filing date of the invention would combine the EHR normalization and clinical decision support specific categorical alert system of Blumenthal and Mazar with the weighted average normalization of Tesanovic the motivation of “fine-tun[ing] the zones for the patient” (Tesanovic in the Detailed Description in ¶ 0079). Additionally, since each individual element and its function are shown in the prior art, albeit shown in separate references, the difference between the claimed subject matter and the prior art rests not on any individual element or function but in the very combination itself- that is in the substitution of the weighted sum normalization equation of Tesanovic for the data normalization means of Blumenthal. Thus, the simple substitution of one known element for another producing a predictable result renders the claim obvious.
As per claim 9, the combination of Blink and Tesanovic discloses all of the limitations of claim 8. Blink also discloses the following:
the system of claim 8, wherein the processor of the EMR server is further configured to display a subset of the displayed medical information, and the subset is displayed differently to indicate the medical test results that are within the normal range, close to the boundaries of the normal range, or outside of the normal range is taught in the Detailed Description in ¶ 0030 and ¶ 0032 (teaching on comparing the patient values to reference ranges to determine if the values are normal, near normal, or outside the reference range)
Response to Arguments
Applicant's arguments filed for with respect to 35 USC § 101 have been fully considered but they are not persuasive. Applicant asserts that the recitation of a normalization equation is not an abstract idea. Examiner is not persuaded. While Examiner has viewed the claim as a whole for identifying the judicial exception - the normalization and averaging of the values may also be reasonably considered a mathematical concept.
Next, Applicant asserts that the claims amount to a practical application via an improvement to a GUI under Step 2A Prong 2 via the recitation of a specific formula for transforming heterogenous medical test data into a normalized “metric”. Normalizing data prior to displaying is does not improve the functioning of a graphical user interface does not provide unique display functionality or provide a dynamic user interface, but instead the display aspect serves only as a tool to output the data determined from the abstract idea (MPEP § 2106.05(g) - insignificant pre/post-solution activity that amounts to post-solution output on a well-known display device) and is therefore not a practical application of the recited judicial exception.
Next, Applicant asserts “The specific normalization formula (two- factor multiplication followed by averaging), combined with the threshold comparison, patient- specific formatting, graphical display with user preference-based differentiation, push notification, confirmation dialog, and traditional chart fallback display, represents a non-conventional and non- generic arrangement of elements.” Examiner is not persuaded. The consideration under Step 2B is if the additional elements, alone or in combination, are well-understood, routine and conventional in the field – the novelty of the abstract idea is not considered relevant under the Step 2B analysis. Here, the additional elements of a display with an alert, alone or in combination, amount to instruction to implement the abstract idea using a general purpose computer. Alice Corp. Pty. Ltd. V. CLS Bank Int’l, 134 S. Ct. 2347, 1357 (2014).
Applicant' s arguments with respect to 35 USC § 103 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument. Applicant’s assertion that a weighted average divides the sum of the withes not the count of the values is not persuasive. The sum of the values divided by the number of values is an average. Tesanovic is now only relied upon to teach this principal of summing a set of normalized values to get a normalized average over time. The normalization of the original values is now taught by Blink as per the rejection above.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JORDAN LYNN JACKSON whose telephone number is (571)272-5389. The examiner can normally be reached Monday-Friday 8:30AM-4:30PM ET.
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, Arleen M Vazquez can be reached at 571-272-2619. 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.
/JORDAN L JACKSON/Primary Examiner, Art Unit 2857
Prosecution Insights