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
In the amendment filed 09/03/2025 the following occurred: Claims 1, 5, and 9 were amended; and Claims 4 and 12 were canceled. Claims 1-3 and 5-11 are presented for examination.
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-3 and 5-11 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.
Claims 1-3 and 5-11 are drawn to systems, which is/are statutory categories of invention (Step 1: YES).
Independent claim 1 recites a patient account database stored, the patient account database storing a plurality of patient accounts corresponding to a plurality of patients; a provider account database stored, the provider account database storing a plurality of provider accounts corresponding to a plurality of providers; each of the plurality of providers having patients, the provider's patients being comprised in the plurality of patients corresponding to the patient accounts, each provider account comprising provider-side healthcare information of each of the corresponding provider's patients, the provider account having unique provider login credentials; each patient account comprising patient-side healthcare information of one of the patients, the patient account having unique patient login credentials; in response to receiving provider login credentials entered which match the provider login credentials of the provider account, to display interactive provider dashboard views corresponding to the provider account; in response to receiving patient login credentials entered which match the patient login credentials of one of the patient accounts, to display interactive patient app views corresponding to the patient account; the provider dashboard views comprising a patient table view displaying patient data for each of the provider's patients, the patient data including a patient name, a patient diagnosis, a next step corresponding to the diagnosis having an agreed upon due date, an owner, and a patient risk level status, the owner representing a role responsible for the next step, and the risk level status representing a likelihood that the next step will not be completed by the agreed upon due date; the patient views displaying the patient's name, the patient diagnosis, the next step, and the risk level status; the patient risk level status comprising a risk level selected from a ranked plurality of risk levels, the software further comprising instructions to receive input and indicating the completion of the next step, and, in response to the passage of the agreed upon date without the next step completion input being received, to elevate the patient risk level status to the next higher risk level.
Independent claim 9 recites a patient account database, the patient account database storing a plurality of patient accounts corresponding to a plurality of patients; a provider account database, the provider account database storing a plurality of provider accounts corresponding to a plurality of providers; each of the plurality of providers having patients, the provider's patients being comprised in the plurality of patients corresponding to the patient accounts, each provider account comprising provider-side healthcare information of each of the corresponding provider's patients, the provider account having unique provider login credentials; each patient account comprising patient-side healthcare information of one of the patients, the patient account having unique patient login credentials; in response to receiving provider login credentials entered which match the provider login credentials of the provider account, to display interactive provider dashboard views corresponding to the provider account on the provider display; the software comprising instructions, in response to receiving patient login credentials entered which match the patient login credentials of one of the patient accounts, to display interactive patient app views corresponding to the patient account on the patient display; the provider dashboard views comprising a patient table view displaying patient data for each of the provider's patients, the patient data including a patient name, a patient diagnosis, a next step corresponding to the diagnosis having an agreed upon due date, an owner, and a patient risk level status, the owner representing a role responsible for the next step, and the risk level status representing a likelihood that the next step will not be completed by the agreed upon due date; the patient views displaying the patient's name, the patient diagnosis, the next step, and the risk level status; the software further comprising instructions to cause a patient interface device to receive and display an automated notification at a preset time; the software further comprising instructions to receive and store scheduled patient appointment information, the scheduled patient appointment information including scheduled appointment times, wherein the automated notification comprises a guided self-advocacy prompt, the preset time being selected so that the prompt will be displayed when the patient is predicted to be at a scheduled appointment with a provider based on one of the stored scheduled appointment times, the prompt including instructions for the patient to ask the provider one or more questions and to enter the provider's responses before the conclusion of the appointment.
The recited limitations, as drafted, under their broadest reasonable interpretation, cover certain methods of organizing human activity, as reflected in the specification, which states that the invention is to “computer-implemented healthcare management systems and methods” (see: specification paragraph 2) by way of “automated risk level status adjustment” (see: specification paragraph 55). If a claim limitation, under its broadest reasonable interpretation, covers managing personal behavior or relationships or interactions between people, then it falls within the “Certain Methods of Organizing Human Activity” grouping of abstract ideas. The present claims cover certain methods of organizing human activity because they address, for example, a problem that arises when “a patient struggles with a pending diagnosis and then never follows up to get the results of a biopsy. By the time the patient is seen again, often in an emergency room, they have lost treatment options and opportunities because their disease has advanced. The present disclosure provides a system for addressing this need” (see: specification paragraph 52) by facilitating “collaboration and communication between patients and providers as well as promoting more active patient involvement in following up with next steps in their healthcare plan, rather than solely relying on provider task completion and provider-initiated follow-up” (see: specification paragraph 53). Accordingly, the claims recite an abstract idea(s) (Step 2A Prong One: YES).
This judicial exception is not integrated into a practical application. The claims are abstract but for the inclusion of the additional elements including an “a processor; a computer readable memory device operatively connected to the processor; software stored in the memory device, the software being readable and executable by the processor;…in the memory device…in the memory device…a provider input device; a provider display; a patient input device; a patient display; each of the patient interface device, patient display, provider interface device, and provider display being operatively connected to the processor; the software comprising instructions for the processor,…into the provider input device…on the provider display…the software comprising instructions for the processor…into the patient input device…on the patient display…for the processor…from at least one of the patient interface device…the provider interface device…” (claim 1), “the system software further comprising instructions for the processor to…using a provider input device…” (claim 5), “the software further comprising instructions for the processor…from the provider input device…” (claim 6), “the software further comprising instructions for the processor…from a provider device…” (claim 8), “a processor; a computer readable memory device operatively connected to the processor; software stored in the memory device, the software being readable and executable by the processor;…stored in the memory device…stored in the memory device…a provider input device; a provider display; a patient input device; a patient display; each of the patient interface device, patient display, provider interface device, and provider display being operatively connected to the processor; the software comprising instructions for the processor…into the provider input device…for the processor…into the patient input device…for the processor…for the processor…in the memory device…from a provider input device…” (claim 9), and “on the patient display…the software further comprising instructions for the processor to…via the patient input device…” (claim 11), which are additional elements that are recited at a high level of generality (e.g., the “processor” is configured to perform functions through no more than a statement than that software is readable and executable “by the processor”; similarly, the “device”(s) is/are configured to perform functions though no more than a statement than that data is “input” either “into”, “from”, “via”, or “using” said device(s); and similarly, the “display”(s) is/are configured to display views though no more than a statement than that software instructions executed by the processor cause said display(s) “to display” said views) such that they amount to no more than mere instruction to apply the exception using generic computer components. See: MPEP 2106.05(f).
The combination of these additional elements is no more than mere instructions to apply the exception using generic computer components. Accordingly, even in combination, these additional elements do not integrate the abstract idea(s) into a practical application because they do not impose any meaningful limits on practicing the abstract idea(s). Accordingly, the claims are directed to an abstract idea(s) (Step 2A Prong Two: NO).
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea(s) into a practical application, using the additional elements to perform the abstract idea(s) amounts to no more than mere instructions to apply the exception using generic components. Mere instructions to apply an exception using generic components cannot provide an inventive concept. See MPEP 2106.05(f).
Further, the claimed additional elements, identified above, are not sufficient to amount to significantly more than the judicial exception because they are generic components that are configured to perform well-understood, routine, and conventional activities previously known to the industry. See: MPEP 2106.05(d). Said additional elements are recited at a high level of generality and provide conventional functions that do not add meaningful limits to practicing the abstract idea(s). The originally filed specification supports this conclusion and Fig. 1 and:
Paragraph 65, where “The system server 18 and the existing EMR storage S are operatively connected each other and to the cloud storage/AP! layer 16 via an external network, such as the internet or worldwide web. Collectively, a server side 20 of the system 10 is said to comprise the system server 18, the existing EMR storage S, and their secure connections to each other and to the cloud storage/AP! layer 16. This enables two-way secure transfer of patient health data between the cloud storage layer 16 and each of the system server 18 and the outside EMR storage S, the data being encrypted during transfer according to a suitable internet communications security protocol, such as TLS, and while at rest in the cloud storage layer 16. Similarly, a user side 22 of the system 10 is said to comprise the provider device 11, the patient devices 13, and secure connections between each of them and the cloud storage/AP! layer 16.”
Paragraph 66, where “The provider device 11, which comprises a provider display 24, can be any suitable electronic device operative to run the provider application so as to display the dashboard 12 on the display 24 and to receive input to the dashboard 12 from the provider, such as a desktop or laptop computer (not shown) operatively connected to the display 24 and to a user input device such as a keyboard, mouse, or touch pad (not shown) and/or a touch screen comprised in the display 24. Typically, the provider device 11 has a large enough display 24 to display simultaneously the names, diagnoses, statuses, and next steps for a number of patients of the provider, such as twenty to thirty patients, in a format that is readily and comfortably readable by a provider having ordinary vision unaided by a magnification device, many times throughout a typical workday of the provider. Thus, the provider device 11 is typically either a computer, with a monitor or laptop screen as the display 24, or a tablet having a 7- to 13-inch screen as the display 24. However, the provider device 11 can also be a smartphone or similar device.
Paragraph 67, where “Likewise, the patient devices 13, which comprise patient displays 26, can be any suitable electronic device operative to run the patient app so as to display the patient portal 14 on the display 26 and to receive input to the patient portal 14 from the patient. Typically, each patient enrolled in the system 10 has at least one patient device 13 that is a smartphone or other portable device, the display 26 being a smartphone touch screen that also serves as the interface for patient input to patient portal 14. It is advantageous that the patient device 13 be portable and normally carried by the patient throughout a typical day, so that the patient device 13 can serve as a reliable mode of delivering real-time reminders or alerts to the patient wherever they may be, as well as displaying self-advocacy prompts to a patient during a patient's care visit to a provider location, according to another aspect of the system 10. Such reminders, alerts and/or prompts can be automatically set up and triggered by software of the system 10, which can include, without limitation, the provider application running on the provider device 11, the patient app running on the patient device 13, and/or a server application running on the system server 18. In addition, or alternatively, the patient may have a patient device 13 that is a desktop or laptop computer or a larger-format tablet that the patient may or may not typically carry to in-person care visits, but which the patient may use at home or elsewhere to access the patient portal 14.”
Viewing the limitations as an ordered combination, the claims simply instruct the additional elements to implement the concept described above in the identification of abstract idea(s) with routine, conventional activity specified at a high level of generality in a particular technological environment.
Hence, the claims as a whole, considering the additional elements individually and as an ordered combination, do not amount to significantly more than the abstract idea(s) (Step 2B: NO).
Dependent claim(s) 2-3, 5-8, and 10-11, when analyzed as a whole, considering the additional elements individually and/or as an ordered combination, are held to be patent ineligible under 35 U.S.C. 101 because the additional recited limitation(s) fail(s) to establish that the claim(s) is/are not directed to an abstract idea(s) without significantly more. These claims fail to remedy the deficiencies of their parent claims above, and are therefore rejected for at least the same rationale as applied to their parent claims above, and incorporated herein.
Response to Arguments
Applicant’s arguments from the response filed on 09/03/2025 have been fully considered and will be addressed below in the order in which they appeared.
In the remarks, Applicant argues in substance that (1) the 35 U.S.C. 101 rejections should be withdrawn in view of the amendments because “…The foregoing reasoning ignores the further limitation of amended claim 1 (original claim 4), "in response to the passage of the agreed upon date without the next step completion input being received, to elevate the patient risk level status to the next higher risk level." As also recited in original and amended claim 1, this inherently causes the next higher risk level to be displayed as the patient risk level status on the provider display in the corresponding patient table view of the corresponding provider dashboard view. See amended claim 1, reciting "the provider dashboard views comprising a patient table view displaying patient data for each of the provider's patients, the patient data including ... a patient risk level status .... " This is significantly more than the abstract idea of "promoting more active patient involvement in following up with next steps of their healthcare plan, rather than solely relying on provider task completion and provider-initiated follow-up" (see Office Action, i 6, quoting specification ,i 0053). It is a practical application of that idea, by which the passage of a date without an input being received automatically causes a change to a patient risk level status that is displayed in a patient table view of a provider dashboard view. In this manner, the provider is not required to proactively review a patient's record and notice the non-completion of a next step in determining whether or not to update the patient's risk level status, and to act accordingly. Rather, the system processor automatically monitors next step completion (or non-completion) represented by the receipt or non-receipt of a next step completion input by an input date, and automatically updates and displays an updated patient risk-level status when the date passes without the next step completion. This is analogous to the example of a claim that does not recite an abstract idea…As with the MPEP example (vi) given above, according to amended claim 1 (original claim 4), a processor monitors user inputs over time, and in response to a condition observed in the monitored input (in this case the non-receipt of a next step completion input before the passage of a date), alters what is displayed on a graphical user interface (in this case the patient table view of the provider dashboard view). Therefore, when considering the subject matter as a whole, amended claim 1 (original claim 4) is not directed to an abstract idea, but rather to monitoring user inputs and changing what is displayed on a GUI based on the monitored input, as in example (vi) quoted above. Alternatively, displaying a patient's updated risk-level status in response to inputs tracked by the processor must amount to the recitation of significantly more than the abstract idea of "healthcare management" that is also recited in the claim, as this subject matter would be eligible in itself as being analogous to example (vi), and the additional recitation of "healthcare management" cannot remove from eligibility what would otherwise be eligible subject matter.”
The Examiner respectfully disagrees. Applicant’s arguments are not persuasive.
The arguments are towards elements representative of the abstract idea. As argued, the broadly claimed invention will “elevate the patient risk level status to the next higher risk level” after a particular date without input being received of next step completion, but there is nothing technical about changing an abstract risk level of a patient. As argued, an elevation in a patient’s risk level results in “the next higher risk level to be displayed as the patient risk level status on the provider display in the corresponding patient table view of the corresponding provider dashboard view”, but there is nothing technical in updating a display to reflect an abstract calculation. The tables themselves are described in the claims and include no technical elements (as per, e.g., Enfish), but instead describe a view of data with no corresponding functionality regarding graphical elements, and where the data view is not even described in any particular arrangement. Instead, the claims merely list the data to be displayed, such as, with regard to the argued provider dashboard: “the provider dashboard views comprising a patient table view displaying patient data for each of the provider's patients, the patient data including a patient name, a patient diagnosis, a next step corresponding to the diagnosis having an agreed upon due date, an owner, and a patient risk level status, the owner representing a role responsible for the next step, and the risk level status representing a likelihood that the next step will not be completed by the agreed upon due date”. The argued practical application is to “automatically monitors next step completion (or non-completion)” by detecting “receipt or non-receipt of a next step completion input by an input date” and then “automatically updates and displays an updated patient risk-level status”. The processing of inputted (or not) data to compute an updated risk-level status for the purposes of displaying said status, in the manner claimed, is abstract. The claims here are not directed to a specific improvement to computer functionality that amount to a practical application. Rather, they are directed to the use of conventional or generic technology in a well-known environment, without any claim that the invention reflects an inventive solution to a technical problem presented by combining the two. In the present case, the claims fail to recite any elements that individually or as an ordered combination transform the identified abstract idea(s) in the rejection into a patent-eligible application of that idea.
As per argued MPEP example (vi), this is Office provided Example 37. The rejection does not utilize “mental processes” and so does not compare directly to Example 37, but insofar as the example interface applies to the claimed dashboard views, what is argued is more similar to claim 3 of Example 37, which is ineligible. Example 37, claim 1, on the other hand, further includes the additional elements of “automatically moving the most used icons to a position on the GUI closest to the start icon of the computer system based on the determined amount of use.” There is nothing comparable in the present claims to the specific function of the GUI of claim 1 of example 37 of automatically moving the most used icons to a position on the GUI closest to the start icon of the computer system based on the determined amount of use. For example, the claimed limitations of a “provider dashboard views comprising a patient table view displaying patient data for each of the provider’s patients, the patient data including…” and “the patient views displaying the patient’s name, the patient diagnosis…” are all abstract descriptions of the data displayed or are representative of the data itself. Where the claims do include additional elements to execute this abstract idea, said additional elements are claimed at a high level such that they amount to no more than mere instruction to apply the exception using generic computer components.
In the remarks, Applicant argues in substance that (2) the 35 U.S.C. 101 rejections should be withdrawn in view of the amendments because “…The foregoing reasoning ignores the actions that the processor is further instructed to perform by the software, as well as the further limitation of amended claim 9 (from original claim 12), "the software further comprising instructions for the processor to receive and store in the memory device scheduled patient appointment information from a provider input device, the scheduled patient appointment information including scheduled appointment times, wherein the automated notification comprises a guided self-advocacy prompt, the preset time being selected so that the prompt will be displayed when the patient is predicted to be at a scheduled appointment with a provider based on one of the stored scheduled appointment times, the prompt including instructions for the patient to ask the provider one or more questions and to enter the provider's responses before the conclusion of the appointment .... " This is significantly more than the abstract idea of "promoting more active patient involvement in following up with next steps of their healthcare plan, rather than solely relying on provider task completion and provider-initiated follow-up",i 6, quoting specification ,i 0053). It is a practical application of that idea, by which the processor receives scheduled appointment times for a patient from a provider input device, and in response, causes the guided self-advocacy prompt to be displayed on the patient device when the patient is predicted to be at a scheduled appointment. In this manner, the provider is not relied upon to proactively elicit self-advocacy from a patient during the appointment. Rather, at an appropriate time based on the scheduled appointment time, the system processor automatically causes the patient device to display a prompt that the patient can use during the appointment to engage in guided self-advocacy. Therefore, when considering the subject matter as a whole, amended claim 9 (original claim 12) is not directed to an abstract idea, but rather to monitoring user inputs (scheduled appointment times input via the provider device) and changing what is displayed on a GUI (guided self-advocacy prompts displayed on the patient device) based on the monitored input, as in example (vi) quoted above from MPEP § 2106.04(a)(l). Alternatively, displaying guided self-advocacy prompts on the patient device in response to the provider-input scheduled appointment times tracked by the processor must amount to the recitation of significantly more than the abstract idea of "healthcare management" that is also recited in the claim, as this subject matter would be eligible in itself as being analogous to example (vi), and the additional recitation of "healthcare management" cannot remove from eligibility what would otherwise be eligible subject matter.”
The Examiner respectfully disagrees. Applicant’s arguments are not persuasive.
The arguments are towards elements representative of the abstract idea. As argued, the broadly claimed invention will “causes the guided self-advocacy prompt to be displayed on the patient device when the patient is predicted to be at a scheduled appointment” after receiving scheduled appointment times for a patient, but there is nothing technical about a guided self-advocacy prompt. As argued, the input of a scheduled appointment time “causes the patient device to display a prompt that the patient can use during the appointment to engage in guided self-advocacy”, but there is nothing technical in guided self-advocacy. The claimed prompt “includes instructions for the patient” with no corresponding functionality regarding graphical elements. Instead, the claims merely describe what the instructions are to be displayed include: “to ask the provider one or more questions and to enter the provider’s responses before the conclusion of the appointment”. The processing of inputted scheduled patient appointment information to determine a prompt for the purposes of instructing a patient, in the manner claimed, is abstract. The claims here are not directed to a specific improvement to computer functionality that amount to a practical application. Rather, they are directed to the use of conventional or generic technology in a well-known environment, without any claim that the invention reflects an inventive solution to a technical problem presented by combining the two. In the present case, the claims fail to recite any elements that individually or as an ordered combination transform the identified abstract idea(s) in the rejection into a patent-eligible application of that idea.
As per argued MPEP example (vi), this is Office provided Example 37. The rejection does not utilize “mental processes” and so does not compare directly to Example 37, but insofar as the example interface applies to the claimed displays and prompts, what is argued is more similar to claim 3 of Example 37, which is ineligible. Example 37, claim 1, on the other hand, further includes the additional elements of “automatically moving the most used icons to a position on the GUI closest to the start icon of the computer system based on the determined amount of use.” There is nothing comparable in the present claims to the specific function of the GUI of claim 1 of example 37 of automatically moving the most used icons to a position on the GUI closest to the start icon of the computer system based on the determined amount of use. For example, the claimed limitations of, “wherein the automated notification comprises a guided self-advocacy prompt, the preset time being selected so that the prompt will be displayed when the patient is predicted to be at a scheduled appointment with a provider based on one of the stored scheduled appointment times, the prompt including instructions for the patient to ask the provider one or more questions and to enter the provider’s responses before the conclusion of the appointment” are all abstract descriptions of the data displayed or are representative of the data itself. Where the claims do include additional elements to execute this abstract idea, said additional elements are claimed at a high level such that they amount to no more than mere instruction to apply the exception using generic computer components.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ROBERT A SOREY whose telephone number is (571)270-3606. The examiner can normally be reached Monday through Friday, 8am to 5pm.
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, Fonya Long can be reached on (571) 270-5096. 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.
/ROBERT A SOREY/Primary Examiner, Art Unit 3682