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 .
Priority
This application’s status as a continuation of patent applications 18/483,632, 18/179,529, 17/152,433, and 16/156,446 and corresponding claim of priority to provisional patent application 62/570299 are acknowledged.
Status of the Claims
Claims 1-20 are currently pending and have been considered below.
Information Disclosure Statement
The information disclosure statements (IDS) submitted on 3/28/2025 and 7/29/2025 are in accordance with the provisions of 37 CFR 1.97 and are considered by the Examiner except where lined through. No copy of the cited Lyles et al. reference (NPL reference 2 on one of the IDSs filed 3/28/2025) was found in this application or any parent application, and accordingly this reference was not considered.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Step 1
In the instant case, claims 1-20 are directed to a method (i.e. a process), and thus each of the claims falls within one of the four statutory categories. Nevertheless, the claims fall within the judicial exception of an abstract idea.
Step 2A – Prong 1
Independent claim 1 recites steps that, under their broadest reasonable interpretations, describe certain methods of organizing human activity. Specifically, the claim recites:
A method of making a request of a remote diabetes care provider using a software application operating on a mobile computing device, the method comprising:
receiving blood glucose information from a user at the software application;
receiving the request at the software application;
providing the blood glucose information and the request from the software application to the remote diabetes care provider through a diabetes care system;
receiving a response to the request at the software application from the remote diabetes care provider through the diabetes care system without the user having to visit the remote diabetes care provider, the response being based on the blood glucose information; and
displaying the response on the mobile computing device using the software application.
But for the recitation of generic computer components like a software application operating on a mobile computing device and a diabetes care system, the italicized steps, when considered as a whole, describe a clinical data exchange operation that could be achieved by managing interactions between a patient and a clinician. For example, a patient could make a request to a clinician regarding their blood glucose information (e.g. by calling the clinician’s office, mailing a written request, etc.), and receive a response to the request from the clinician (e.g. by receiving a return phone call, receiving a written report responsive to the request, etc.). Accordingly, this claim recites certain methods of organizing human activity because the steps describe the process of acquiring clinical data for a clinician to review and receiving a response from the clinician based on the clinical data, which is an interaction that commonly occurs during medical appointments or inquiries between a patient and physician.
Dependent claims 2-20 inherit the limitations that recite an abstract idea from their dependence on claim 1, and thus these claims also recite an abstract idea under the Step 2A – Prong 1 analysis. In addition, each of claims 3-19 merely further describe the abstract idea identified for the independent claim above.
Specifically, claim 3 recites that the blood glucose information comprises blood glucose measurements collected from the user over a period of time, which a patient could provide to a clinician during an interaction by detailing at least two glucose measurements.
Claims 4-5, 7, 11, and 14 recite different types of requests that a patient could make of a clinician, which are each in line with what could be requested of a clinician during a traditional appointment or other medical/administrative interaction.
Claim 6 recites that a clinician’s response indicates that the request has been granted and communicated to another entity, which a clinician could communicate to a patient in a response during an appointment or other medical/administrative interaction.
Claims 6, 8-10, 12-13, and 15-16 each describe what a clinician’s response may comprise, including various care recommendations based on patient-specific information, notification that various data has been shared with additional entities, and/or administrative interactions such as scheduling of appointments based on user preferences. Each of these types of responses remain consistent with what could be achieved during a traditional patient-clinician interaction, e.g. by a doctor providing recommended medications, referrals, etc. to a patient based on the patient’s specific situation and ensuring the appropriate follow-up action has occurred by communicating information to external entities like a pharmacy or licensing authority.
Claim 17 describes a process of soliciting supplemental information from a patient, which could also be achieved during a patient-physician interaction by a doctor asking follow-up questions and considering the patient’s responses when making care recommendations.
Claims 18 and 19 describe the type of supplemental information provided in such a process (e.g. photograph, video, or physiological test results) which could easily be provided by a patient during a patient-clinician interaction.
Thus, claims 1-20 recite an abstract idea. However, recitation of an abstract idea is not the end of the analysis. Each of the claims must be analyzed for additional elements that indicate the abstract idea is integrated into a practical application to determine whether the claim is considered to be “directed to” an abstract idea.
Step 2A – Prong 2
The judicial exception is not integrated into a practical application. In particular, independent claim 1 does not include additional elements that integrate the abstract idea into a practical application. The additional elements of claim 1 include a software application operating on a mobile computing device and a diabetes care system for implementing the steps of the method, as well as the functional additional elements of receiving the request at the software application and displaying the response on the mobile computing device using the software application.
These additional elements, when considered in the context of the claim as a whole, amount to mere instructions to “apply” the abstract idea on a computer because the software application of the mobile computing device and the diabetes care system merely serve to digitize what could otherwise be a human interaction between patient and clinician (see MPEP 2106.05(f)). That is, these elements merely specify that the method of organizing human activity be implemented in a digital manner with an app rather than, e.g., in-person verbal communication, mailed written communication, etc. Applicant’s specification appears to support this assertion in at least paras. [0003]-[0004], where the invention is broadly described as allowing for the remote resolution of patient requests that may previously have been resolved via an in-person doctor visit.
Similarly, the receipt of the blood glucose information and request at the software application before being sent to the diabetes care system as well as the display of the response at the mobile computing device merely further describe the digitized architecture of the human interaction because these steps are necessary for communicating data in a digitized infrastructure (i.e. information that would be spoken or exchanged in writing in a manual interaction must be received and forwarded at application software and displayed for a user to achieve equivalent data exchange). Further, these steps are tangential to the main idea (sending a request to and receiving a response from a medical provider) and serve as necessary steps for digital data exchange such that they may also be considered insignificant extra-solution activity, e.g. the mere outputting of data equivalent to printing a report as described in MPEP 2106.05(g). Accordingly, the claim as a whole is directed to an abstract idea without integration into a practical application.
The judicial exception recited in dependent claims 3-19 is not integrated into a practical application under the same analysis as above because each claimed function is performed with the same additional elements identified in claim 1 without introducing any new additional elements; the software application and diabetes care system still merely serve to implement the abstract idea in a digitized environment and thus amount to mere instructions to apply the exception on a computer.
Claims 2 and 20 introduce new additional elements beyond those recited in the independent claim, but these elements still do not provide integration into an abstract idea. Claim 2 recites that the software application receives the blood glucose information wirelessly from a blood glucose meter connected to the mobile computing device, which specifies a type of clinical data gathering incidental to the overall invention; that is, it does not appear to matter whether the blood glucose data is provided by a user manually inputting the readings, via a glucose meter over a wired connection, via a wireless glucose meter, etc. because the main steps of the method merely require that this data is received in some way. Accordingly, the receipt of this data specifically from a wirelessly connected glucose meter is incidental and amounts to insignificant extra-solution activity in the form of mere data gathering.
Claim 20 introduces the additional elements of receiving a prompt from the diabetes care system at the software application and displaying the prompt on the mobile computing device using the software application such that the request is responsive to the prompt. This “prompting” functionality again appears to merely elicit the gathering of data necessary for the overall invention to perform its intended function (sending a request and receiving a response) such that these limitations also amount to insignificant extra-solution activity in the form of necessary data gathering.
Accordingly, the additional elements of claims 1-20 do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. Claims 1-20 are directed to an abstract idea.
Step 2B
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements of a software application operating on a mobile computing device and a diabetes care system for implementing the steps of the method, as well as the functional additional elements of receiving the request at the software application and displaying the response on the mobile computing device using the software application amount to no more than mere instructions to apply the exception using generic computer components. As evidence of the generic nature of the above-recited additional elements, Examiner notes para. [0027] of Applicant’s specification, where the mobile computing device and associated software are described in generic, exemplary terms (e.g. “As examples, the mobile computing device may be a smartphone, laptop, or other personal computing device. The device 205 can include, for instance, a user interface, a network communication mechanism (e.g., one or more wireless transceivers), a processor, and a non-transitory computer-readable storage article. The non-transitory computer-readable storage article can have computer-executable instructions stored thereon and run by the processor to cause the processor to perform specified actions”) such that one of ordinary skill in the art would understand that any generic mobile device may be used. The remote server (i.e. the diabetes care system) is described similarly in at least para. [0032]. One of ordinary skill in the art would understand from these nonspecific descriptions that any generic mobile device executing stored software and interacting with a generic server could be used to implement the invention.
The combination of these additional hardware elements is not expanded upon in the specification as a unique arrangement and as such relies on the knowledge of one of ordinary skill in the art to understand the combination of components within a server-client architecture as a well-known and generic combination for automating an abstract idea that could otherwise be implemented as interactions between human actors and thus do not provide an inventive concept. Additionally, at least the abstract & [0082]-[0083] of Baharav et al. (US 20040220829 A1) as well as the abstract & Figs. 5-7 of Henderson (US 8014756 B1) show that it was well-understood, routine, and conventional at the time of filing to utilize a mobile device running a software application to interact with a remote server system to facilitate requested remote doctor-patient clinical and administrative interactions.
Regarding the functional additional elements, as noted above, the steps of receiving the request at the software application and displaying the response on the mobile computing device using the software application are also considered insignificant extra-solution activities, such as necessary data gathering and outputting data. These activities are also nothing more than those recognized as well-understood, routine, and conventional in the art. For example, receiving a request input at a software application of a mobile device is noted in at least Figs. 9-10 & 13-17 of Baharav and Figs. 1-2B of Henderson; while displaying a response from a remote user at a local mobile device using a software application is noted in at least Fig. 6 of Baharav and Fig. 4 of Henderson.
The additional elements introduced in dependent claims 2 and 20 also do not amount to significantly more than the abstract idea. As noted above, the receipt of blood glucose data from a wireless blood glucose meter at the mobile computing device (as in claim 2) and request prompting functionality (as in claim 20) are each considered insignificant extra-solution activities in the form of necessary data gathering. Each of these activities are also nothing more than those recognized as well-understood, routine, and conventional in the art. For example, use of a wireless blood glucose meter connected to a mobile device to collect blood glucose information is noted in at least Fig. 1 & [0019] of Whitehurst (US 20160210416 A1) and Fig. 1 & [0020] of Birtwhistle et al. (US 20140325065 A1); while prompting or reminding a user to begin a request is noted in at least Fig. 4 of Baharav and [0054] of Hunkeler et al. (US 20050283385 A1).
Analyzing these additional elements as an ordered combination adds nothing that is not already present when considering the elements individually; the overall effect of the software application and various digitized means of obtaining or outputting data in combination is to digitize and/or automate a health-related data sharing operation that could otherwise be achieved as an interaction between a patient and clinician. Thus, when considered as a whole and in combination, claims 1-20 are not patent eligible.
Claim Rejections - 35 USC § 103
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
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.
Claims 1, 4, 7, 10-11, 14, 16, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Baharav et al. (US 20040220829 A1) in further view of “Standards of Medical Care for Patients with Diabetes Mellitus” by the American Diabetes Association (NPL Reference No. 2 on the IDS submitted 3/28/2025, hereinafter “Standards”).
Claim 1
Baharav teaches a method of making a request of a remote diabetes care provider using a software application operating on a mobile computing device (Baharav abstract, noting server-client software architecture that allows a patient to make a variety of requests to a remote healthcare provider; [0083] indicates that a patient interacts with the distributed system via web browsers at client devices such as laptops or handheld computing devices (i.e. software applications operating on mobile computing devices), while [0122] notes that the system may be utilized to provide care and consultation for chronic conditions like diabetes, indicating that the remote healthcare provider may be considered a remote diabetes care provider), the method comprising:
receiving user health information from a user at the software application (Baharav Figs. 9-10, [0082], [0122], noting a user interacts with a GUI to input health information relevant to the request they wish to make);
receiving the request at the software application (Baharav [0082], [0122], noting that when a user has finished inputting relevant information for the request, a message to the provider is composed based on the input. A patient completing the input section (e.g. in the “Review & Send” section pictured in Figs. 9-10) is thus considered equivalent to the software application receiving the request);
providing the user health information and the request from the software application to the remote diabetes care provider through a diabetes care system (Baharav [0082], [0122], noting a message containing the relevant input information is composed and sent to the remote healthcare provider via the server; an example of the request with relevant user health information is shown in Fig. 26 and described in [0180]-[0190]);
receiving a response to the request at the software application from the remote diabetes care provider through the diabetes care system without the user having to visit the remote diabetes care provider, the response being based on the user health information (Baharav [0122], [0191]-[0202], noting the provider responds to the patient’s request based on the information provided, e.g. with a prescription, an appointment request, test results, educational information, etc.; example responses are shown in Figs. 27-29. The request and response are fully embodied as an online messaging system as disclosed throughout the reference, indicating that a user does not need to visit the remote provider to receive a response to the request; [0122] further notes that the system provides “consultation for minor, non-critical conditions that may not require an office visit”, emphasis added); and
displaying the response on the mobile computing device using the software application (Baharav Fig. 6, [0111], noting the patient may select and view responses from the provider at their client device).
In summary, Baharav teaches a system that facilitates a patient sending a request to a remote medical provider for a variety of reasons. The patient may input health information relevant to the request so that the provider can review the information and provide a response based at least in part on the provided information (as in Figs. 9-10, [0082], [0122]). The system is also disclosed as capable of being used for chronic care management, e.g. to review patient compliance with a care plan for diabetes (as in [0122]). However, Baharav fails to explicitly disclose that the received user health information included with the request is specifically blood glucose information.
However, Standards discloses that a fundamental aspect of chronic diabetes management is glycemic control (Standards S35, first para. of “Glycemic control”) and that when evaluating a patient with diabetes, the past and present degree of glycemic control should be reviewed, e.g. by assessing a user’s current medications, meal plan, and glucose monitoring results (Standards S35, “Initial Evaluation” and S36, Table 5). Standards further notes that various actions should be taken if a patient is not achieving their desired treatment goals (e.g. preprandial plasma glucose levels and/or peak postprandial plasma glucose as summarized in S37, Table 6). The disclosures of this reference thus indicate that blood glucose would be a relevant type of user health information for a provider to know when providing care recommendations or other health information to a diabetic patient as part of a chronic diabetes management plan. It therefore would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Baharav to include receipt of specifically blood glucose information in a request to a remote provider because Standards shows that this type of information is fundamental for making care decisions for diabetic patients, and it would thus be a relevant type of information to include in a request from a patient managing chronic diabetes (as in [0122] of Baharav) in order to provide a full picture of the patient’s health and ensure the best care is achieved.
Claim 4
Baharav in view of Standards teaches the method of claim 1, and the combination further teaches wherein the request comprises a request for an authorization from the remote diabetes care provider (Baharav [0011], [0104], noting a requested service includes an authorization of medication refills and renewals).
Claim 7
Baharav in view of Standards teaches the method of claim 4, and the combination further teaches wherein the request for the authorization comprises a prescription renewal request (Baharav Fig. 14, [0011], [0153], noting a requested service includes an authorization of medication refills and renewals).
Claim 10
Baharav in view of Standards teaches the method of claim 4, and the combination further teaches wherein the response comprises a notification that the request for authorization has been granted or denied (Baharav Fig. 6, showing that messages received by the patient include responses to authorization requests, e.g. the message with the subject “Medication Renewal”; [0011] further notes that prescription renewal requests may be affirmatively authorized by the provider. Together, these disclosures suggest that the message received by the patient could include information notifying a patient of the status of a medication renewal authorization request, i.e. whether it has been granted). Additionally, the content of the message does not change the function of the invention (i.e. providing/displaying a response to a user at a software application), and it would be obvious to substitute any information relevant to the request and/or response (e.g. whether the request has been granted or denied) as content of the response message.
Claim 11
Baharav in view of Standards teaches the method of claim 1, and the combination further teaches wherein the request comprises a request for a referral to a diabetes care specialist (Baharav Fig. 16, [0105], [0155], noting a requested service includes a referral to a specialist such as an allergist; when considering a specific diabetes implementation, the specialist could be a diabetes care specialist like an endocrinologist (as in Standards S37, “Referral for diabetes management”)).
Claim 14
Baharav in view of Standards teaches the method of claim 1, and the combination further teaches wherein the request comprises a request for a diabetes management recommendation (Baharav Figs. 9-10, [0082], [0122], noting a request for consultation indicates a user desires professional guidance or recommendations for a medical issue or condition; as in [0122], a medical condition for which a user might seek care is diabetes, indicating that a request for consultation could specifically be a request for a diabetes management recommendation).
Claim 16
Baharav in view of Standards teaches the method of claim 1, and the combination further teaches wherein the response comprises a recommendation that the user visit the remote diabetes care provider (Baharav [0122], [0204]-[0205], noting a provider response may indicate that the patient come in to be seen by the provider).
Claim 20
Baharav in view of Standards teaches the method of claim 1, and the combination further teaches the method comprising: receiving a prompt from the diabetes care system at the software application; and 32Docket No.: 63344.1005.2displaying the prompt on the mobile computing device using the software application, the request being responsive to the prompt (Baharav Fig. 4, showing menu prompts displayed at a GUI including “consult your doctor,” “request/cancel appointment,” “request medication refills,” etc. that prompt a patient to begin a new request; this view also shows a “Reminders” section that may also act as a prompt for a patient to begin a new request, e.g. the displayed prompt “Remember to fill your prescription for Zithromax Z-Pak” could prompt a patient to begin a medication refill request).
Claims 2-3 and 17-19 are rejected under 35 U.S.C. 103 as being unpatentable over Baharav and Standards as applied to claim 1 above, and further in view of Whitehurst (US 20160210416 A1).
Claim 2
Baharav in view of Standards teaches the method of claim 1, showing a system that allows for the input of user health information such as blood glucose measurements. However, the combination fails to explicitly disclose wherein the software application receives the blood glucose information wirelessly from a blood glucose meter connected to the mobile computing device. However, Whitehurst teaches that in a remote medical consultation system, user health information such as blood glucose measurements to be sent to a remote medical provider may be acquired from a sensor device wirelessly communicating with the user’s mobile computing device (Whitehurst Fig. 1, [0010], [0019], [0048]). It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to substitute the wireless data acquisition of Whitehurst for the manual data entry of the combination because inputting and sharing an extensive blood glucose history may be too burdensome to perform manually, and wireless data collection and subsequent sharing via a wearable sensor allows large amounts of data to be shared in relatively short periods of time without requiring burdensome interrogation or data entry by the patient (as suggested by Whitehurst [0036]).
Claim 3
Baharav in view of Standards and Whitehurst teaches the method of claim 2, and the combination further teaches wherein the blood glucose information comprises blood glucose measurements collected from the user over a period of time (Standards S38, “Self-monitoring of blood glucose”, noting monitoring of blood glucose “allows patients to evaluate their individual response to therapy and assess whether glycemic targets are being achieved” and that blood glucose readings are recommended to be taken at least daily for some patients, and at least three times daily for other patients; this indicates that it would be useful to evaluate blood glucose measurements collected from the user over a period of time; see also Whitehurst [0048], noting that sensor data (e.g. blood glucose information) is “collected over a duration of time, the duration generally exceeding a few days, such [sic] one or more weeks, months or years”).
Claim 17
Baharav in view of Standards teaches the method of claim 1, showing a method wherein a patient sends a request to and receives a response from a remote medical provider. Baharav further teaches that the medical provider’s response may include an online consultation interview for the patient to complete (per Fig. 27 & [0198]), indicating that the provider is requesting additional information from the user that could be filled out and sent back in the same manner as the initial consultation interview as described in [0082]. However, though the combination contemplates the request for and receipt of additional information from the patient, it fails to explicitly disclose:
wherein the response comprises a request for supplemental information about the user, the method further comprising:
receiving the supplemental information at the software application;
providing the supplemental information from the software application to the remote diabetes care provider through the diabetes care system;
receiving a supplemental response at the software application from the remote diabetes care provider through the diabetes care system without the user having to visit the remote diabetes care provider, the supplemental response being based on the supplemental information; and
displaying the supplemental response on the mobile computing device using the software application.
However, Whitehurst teaches that in a telemedical interaction between a patient and remote medical provider, the medical provider may receive some medical information from the patient and determine that additional information is required (Whitehurst Fig. 4, [0061]-[0062], [0071]). The provider then utilizes a computerized system to request supplemental information from a patient (e.g. photos, laboratory results, sensor results, additional questions), which the patient provides via the system. After reviewing the additional information, the provider sends another response (e.g. containing treatment and/or diagnosis instructions) based on the supplemental information.
In summary, the combination contemplates a medical provider’s response prompting a patient to input supplemental information, but does not explicitly disclose a method comprising receiving, providing, receiving, and displaying as required by the instant claim. Whitehurst explicitly describes how supplemental information is requested and acquired by a provider in a telemedicine system, as well as how a supplemental response is generated and sent to a patient. It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to substitute the explicitly described supplemental information method of Whitehurst for the generically contemplated supplemental information functionality of the combination in order to explicitly provide functionality that allows a provider to request additional information about a patient when deemed necessary and provide a more thorough and informed response to the patient’s telemedical inquiry, as suggested by Whitehurst [0062].
Claim 18
Baharav in view of Standards and Whitehurst teaches the method of claim 17, and the combination further teaches wherein the supplemental information comprises a photograph or video of an anatomical part of the user (Whitehurst Figs. 4 & 10C, [0062], [0071], noting additionally requested information may comprise photos or video of the patient, e.g. a picture of a patient’s skin).
Claim 19
Baharav in view of Standards and Whitehurst teaches the method of claim 17, and the combination further teaches wherein the supplemental information comprises results of a physiological test self-administered by the user (Whitehurst Fig. 4, [0062], noting additionally requested information may comprise laboratory results or sensor results; sensor results would be acquired from one or more of the various sensors described in at least [0010], [0019], & [0048], which include wearable sensors that measure a variety of patient physiological parameters such as respiration, body temperature, hydration levels, perspiration, blood glucose, oxygen levels, etc. The “sensor results” are thus considered equivalent to results of a physiological test self-administered by the user because they are measurements acquired from a user’s wearable (i.e. self-administered) sensors).
Claims 5-6 are rejected under 35 U.S.C. 103 as being unpatentable over Baharav and Standards as applied to claims 1 and 4 above, and further in view of “Diabetes and Driving” by the American Diabetes Association (NPL Reference 1 on the IDS filed 3/28/2025, hereinafter “Driving”).
Claim 5
Baharav in view of Standards teaches the method of claim 4, showing a system that allows a patient to initiate a request to a provider for a medical consultation, authorization of a prescription or referral, or other routine clinical tasks. However, the combination fails to explicitly disclose wherein the request for the authorization comprises a request for medical clearance for purposes of renewing a license.
However, Driving teaches that the reason a patient might require a medical consultation is for medical clearance for purposes of renewing a driver’s license (Driving S81, last para. of “Licensing Requirements”, noting if a person has diabetes or another condition likely to cause loss of consciousness while driving, they may be “required to submit a medical evaluation before he or she will be issued a license”; see further S81-S82 “Medical evaluation”, noting “Medical evaluation procedures vary and range from a simple confirmation of the person’s diabetes from a physician to a more elaborate process involving a state medical advisory board, hearings, and presentation and assessment of medical evidence” as well as “Factors in the federal commercial driving medical evaluation include a review of diabetes history, medications, hospitalizations, blood glucose history, and tests for various complications and an assessment of driver understanding of diabetes and willingness to monitor their condition”).
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify the combination to include patient consultation/authorization requests specifically for medical clearance to renew a license because the infrastructure of Baharav provides for patient-directed online clinical consultations and/or authorizations in a variety of scenarios, while Driving demonstrates that a specific scenario in which a patient might seek out a clinical consultation and/or authorization is to attain medical clearance to renew a driver’s license. The combination would provide the advantage of a user being able to obtain medical clearance as a response from the physician after an appropriate evaluation of the relevant patient information in the online consultation.
Claim 6
Baharav in view of Standards and Driving teaches the method of claim 5, showing a system that allows a patient to initiate a request to a provider for a medical consultation and/or authorization, e.g. for purposes of attaining medical clearance for a license renewal procedure (as suggested by Driving). Baharav further teaches that in response to a prescription renewal authorization request, a physician may instantly transmit the authorized prescription to a pharmacy of the patient’s choosing (per at least [0011]). This shows that the system is capable of communicating to a relevant third party that a particular type of authorization has been granted. Baharav also shows that messages received by the patient include responses to authorization requests (e.g. in Fig. 6 there is a message with the subject “Medication Renewal” that indicates the body of the message includes information responsive to the patient’s authorization request). Together, these disclosures suggest that the message received by the patient could include information notifying a patient of the status of a medication renewal authorization request, i.e. whether it has been granted and communicated to a chosen pharmacy. Additionally, the content of the message does not change the function of the invention (i.e. providing/displaying a response to a user at a software application), and it would be obvious to substitute any information relevant to the request and/or response (e.g. whether the request has been granted and sent to a relevant entity) as content of the response message.
Though Baharav itself does not explicitly disclose these functionalities applying to a medical clearance request scenario, the system has the capability to perform the functional limitations of this claim (albeit for a different purpose) as described above. That is, the system is capable of providing a physician response that could contain content notifying a patient that a request for authorization has been granted and communicated to a relevant third party (e.g. that a prescription renewal request has been authorized and sent to a pharmacy as in [0011]). When combined with the disclosure of Driving that suggests a reason for a medical consultation/authorization request could be for medical clearance required by a licensing agency (as in claim 5 above), it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to also apply the architecture of the medication renewal authorization response to a medical clearance authorization response such that the authorization is communicated to a relevant third party (e.g. the licensing authority) and the patient is provided with a response message (i.e. notification) indicating the authorization/approval of the request.
Claims 8-9 are rejected under 35 U.S.C. 103 as being unpatentable over Baharav and Standards as applied to claims 1 and 7 above, and further in view of Kubey (US 20180075212 A1).
Claim 8
Baharav in view of Standards teaches the method of claim 7, showing a system where a patient can request authorization of a prescription renewal from a remote medical provider. Standards further teaches that a patient’s pharmacological therapies might require changing if their health data indicates that their diabetes treatment goals (such as glycemic control) are not being met (Standards S37, “Referral for diabetes management” & Table 6). This suggests that the outcome of a provider reviewing a patient’s blood glucose information (i.e. as in a consultation or authorization request) could be the recommendation of an alternative medication-based treatment. However, the combination fails to explicitly disclose wherein the response comprises a recommended medication, wherein the diabetes care system identifies the recommended medication based on medication price information and insurance information of the user.
However, Kubey teaches a system that analyzes a patient’s as-written prescription, stored medication price information, and insurance information of the patient to recommend an optimized prescription for the patient (Kubey abstract, [0075]-[0077], [0083]-[0109]). The patient’s prescription information (including prescription refills/renewals per [0106]) is input to the system, and an optimization process identifies various therapeutic equivalents (including equivalent formulations, dosages, generic alternatives, etc. per [0075]) and their associated prices based on prices at particular pharmacies (per [0035]) as well as any discounts that a patient may have (e.g. from insurance policies, discount programs, etc. per [0051]). After considering all possible permutations, results are output that allow a user to identify the lowest price prescription, best value prescription, etc. (per [0076], [0081], [0108]). It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify the combination to specify that a response can comprise a recommended medication identified based on price and insurance information as in Kubey in order to optimize price for the patient when refilling medications while retaining therapeutic value, which in turn provides cost savings to both the patient and other payers while reducing non-adherence with prescribed medication regimens, as suggested by at least Kubey abstract, [0084], [0106], & [0109].
Claim 9
Baharav in view of Standards and Kubey teaches the method of claim 8, showing a system wherein a patient can request authorization for a prescription renewal and receive a response recommending a more cost-effective medication equivalent/alternative. Baharav further teaches that in response to a prescription renewal authorization request, a physician may instantly transmit the authorized prescription to a pharmacy of the patient’s choosing (per at least [0011] & [0285]). This shows that the system is capable of communicating to a pharmacy that a medication renewal authorization has been granted. Baharav also shows that messages received by the patient include responses to authorization requests (e.g. in Fig. 6 there is a message with the subject “Medication Renewal” that indicates the body of the message includes information responsive to the patient’s authorization request). Together, these disclosures suggest that the message received by the patient could include information notifying a patient of the status of a medication renewal authorization request, i.e. whether it has been granted and communicated to a chosen pharmacy). Additionally, the content of the message does not change the function of the invention (i.e. providing/displaying a response to a user at a software application), and it would be obvious to substitute any information relevant to the request and/or response (e.g. whether the request has been granted and sent to a pharmacy) as content of the response message.
Thus, the system is shown to be capable of providing a physician response that could contain content notifying a patient that a request for authorization has been granted and communicated to a pharmacy. However, though Baharav notes that authorized prescriptions may be transmitted to “virtually any pharmacy in the United States chosen by the patient” (see [0011]), it does not explicitly disclose that the response comprises a notification that an order of the recommended medication was submitted to a recommended pharmacy, wherein the diabetes care system identifies the recommended pharmacy based on pharmacy price information and location information of the user.
However, Kubey shows that part of the process of optimizing a patient’s prescription is comparing the prices of medications at multiple pharmacies within a certain geographic area or zip code (Kubey [0035], [0049], [0075]-[0076], [0087]-[0089]). The result of the optimization process is the identification of a suitable medication available at a particular pharmacy (within defined geographic preferences) with the lowest price available to the patient. Thus, Kubey teaches a recommended medication being specifically associated with a recommended pharmacy based on pharmacy price information and location information of the user. It therefore would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify the authorized prescription transmission and notification capabilities of the combination with the particular recommended pharmacy capabilities of Kubey in order to tailor the optimization process to the individual patient’s preferences and personalized information to most effectively provide cost savings, as suggested by Kubey [0108].
Claims 12-13 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Baharav and Standards as applied to claims 1, 11, and 14 above, and further in view of Basri (US 20160321412 A1).
Claim 12
Baharav in view of Standards teaches the method of claim 11, showing a system wherein a patient may request referral to a specialist such as an endocrinologist. Baharav further teaches that a user’s request does not need to indicate a specific doctor (as in Fig. 16) and that the patient’s insurance information would be utilized for purposes of referrals (as in Fig. 17, [0155]), while Standards further teaches that a referral to a particular type of specialist (e.g. an endocrinologist) may be made in response to particular physiological and/or behavioral data of the patient (e.g. A1C, blood glucose, blood pressure, or lipid levels as in S37, “Referral for diabetes management” & Table 6). However, the combination fails to explicitly disclose wherein the response comprises a grant of the request for the referral, along with a name of a recommended diabetes care specialist, wherein the diabetes care system identifies the recommended diabetes care specialist based on physiological and/or behavioral information, location information, and insurance information of the user.
However, Basri teaches a referral management system that recommends a specialist based on a variety of factors and preferences (Basri [0012], [0101]). The recommended specialist is identified based on the desired/ordered procedure (which would be based on a patient’s physiological, behavioral, or other health information such that this is considered equivalent to the recommendation being based on physiological and/or behavioral information), location information, and insurance information per [0107]. A messaging means allows the system to communicate the recommended provider and other relevant administrative information to the patient per [0109]. It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify the open-ended referral architecture of the combination to include a response that specifies the granting of the referral for a specific recommended provider as in Basri in order to provide a patient with the most appropriate and cost-effective specialist based on their personal information and preferences, as suggested by Basri [0032]-[0033].
Claim 13
Baharav in view of Standards and Basri teaches the method of claim 12, and the combination further teaches:
wherein the response further comprises notification of an appointment for the user with the recommended diabetes care specialist (Basri [0108]-[0109], noting a message shared with the patient may include information relating to a scheduled appointment),
wherein the method further comprises receiving user calendar information at the software application and providing the user calendar information to the diabetes care system (Baharav Fig. 13, [0128], [0137], noting a user may utilize a GUI to input preferred dates and times of an appointment (i.e. user calendar information); see also Basri Fig. 2B, elements 6C(i)-(iii)),
wherein the diabetes care system communicates with the recommended diabetes care specialist and makes the appointment based on the user calendar information (Baharav [0139]-[0146], noting the patient’s date and time preferences are displayed for the selected provider, who then sends a response with chosen acceptable dates and times so that a patient may confirm the appointment and the system can make the desired appointment; see also Basri Fig. 2B, [0017], [0108]).
Claim 15
Baharav in view of Standards teaches the method of claim 14, showing a system wherein a patient may request a consultation with their provider, e.g. a diabetes care provider. Standards further teaches that in response to reviewing a patient’s particular physiological and/or behavioral data (e.g. A1C, blood glucose, blood pressure, or lipid levels as in S37, “Referral for diabetes management” & Table 6), a referral to a specialist (e.g. an endocrinologist) may be made, while Baharav further teaches administrative referral functionalities (as in Fig. 16, [0155]). However, the combination fails to explicitly disclose wherein the response comprises a specific recommendation to visit a recommended diabetes care provider, wherein the diabetes care system makes the recommendation based on physiologica