DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of Claims
This Office Action is responsive to the response filed October 16, 2025.
Claims 1, 11 and 20 are amended, with no claims added or cancelled.
Claims 1-20 are currently pending and have been fully examined.
Response to Amendment
The previous objection to claim 1 is withdrawn in view of the Applicant’s amendment to the claim.
Specification
The disclosure is objected to because of the following informalities: The paragraphs are not properly numbered in accordance with 37 CFR 1.52(b)(6).
Although the response indicates that a substituted specification is submitted in the response of October 16, 2025, it is not in the file wrapper. Thus, the objection is maintained.
Claim Objections
Claim 11 is objected to because of the following informalities: claim 11 recites an administrative portal “to permit the healthcare provide to review the e-prescription”. An “r” is omitted from “provide” and should be “provider”. Appropriate correction is required.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are: “conversation engine”, “a comparator”, “a prescription generation module”, and “a communication module” in claims 1 and 11, “payment processing module” in claims 3-4, and “administrative portal” in claims 9-11.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1-20 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Claims 1, 11 and 20 recite “a conversation engine”, “a comparator”, “a prescription generation module”, “a communication module”, “a location module”, “an administrative portal”, and “a payment processing module”. Claims 2 and 12 also recites “a location module”, claims 3, 4, 13 and 14 recite “a payment processing module”, claim 8 recites “conversation engine”, claims 9-10 recite “an administrative portal”.
However, the written description fails to disclose the corresponding structure, material or acts for performing the entire claimed function and to clearly link the structure, material, or acts to the function. Under the broadest reasonable interpretation, the aforementioned claim limitations interpreted under 112(f) could be implemented as software (i.e., program code, algorithms) or hardware. Furthermore, the specification does not further describe the claim limitations. Par. [0039] of the specification describes these modules as being, “embodied directly in hardware, in a software module executed by a processor, or in a combination of the two.” Thus, there is no clear linking of the structure, material or acts to the function. Due to the disclosure’s lack of description that clearly links the structure to the function of the aforementioned claim limitations, the disclosure fails to sufficiently describe the aforementioned claim limitations.
Original claims may lack written description when the claims define the invention in functional language specifying a desired result but the specification does not sufficiently describe how the function is performed or the result is achieved. For software, this can occur when the algorithm or steps/procedure for performing the computer function are not explained at all or are not explained in sufficient detail (simply restating the function recited in the claim is not necessarily sufficient). In other words, the algorithm or steps/procedure taken to perform the function must be described with sufficient detail so that one of ordinary skill in the art would understand how the inventor intended the function to be performed. See MPEP §§ 2163.02 and 2181, subsection IV.
The level of detail required to satisfy the written description requirement varies depending on the nature and scope of the claims and on the complexity and predictability of the relevant technology. Ariad, 598 F.3d at 1351, 94 USPQ2d at 1172; Capon v. Eshhar, 418 F.3d 1349, 1357-58, 76 USPQ2d 1078, 1083-84 (Fed. Cir. 2005). Computer-implemented inventions are often disclosed and claimed in terms of their functionality. For computer-implemented inventions, the determination of the sufficiency of disclosure will require an inquiry into the sufficiency of both the disclosed hardware and the disclosed software due to the interrelationship and interdependence of computer hardware and software. The critical inquiry is whether the disclosure of the application relied upon reasonably conveys to those skilled in the art that the inventor had possession of the claimed subject matter as of the filing date. Vasudevan Software, Inc. v. MicroStrategy, Inc., 782 F.3d 671, 682. 114 USPQ2d 1349, 1356 (citing Ariad Pharm., Inc. V. Eli Lilly & Co, 598 F.3d 1336, 1351, 94 USPQ2d 1161, 1172 (Fed. Cir. 2010) in the context of determining possession of a claimed means of accessing disparate databases).
When examining computer-implemented functional claims, examiners should determine whether the specification discloses the computer and the algorithm (e.g., the necessary steps and/or flowcharts) that perform the claimed function in sufficient detail such that one of ordinary skill in the art can reasonably conclude that the inventor possessed the claimed subject matter at the time of filing. It is not enough that one skilled in the art could write a program to achieve the claimed function because the specification must explain how the inventor intends to achieve the claimed function to satisfy the written description requirement. See, e.g., Vasudevan Software, Inc. v. MicroStrategy, Inc., 782 F.3d 671, 681-683, 114 USPQ2d 1349, 1356, 1357 (Fed. Cir. 2015) (reversing and remanding the district court’s grant of summary judgment of invalidity for lack of adequate written description where there were genuine issues of material fact regarding "whether the specification show[ed] possession by the inventor of how accessing disparate databases is achieved"). If the specification does not provide a disclosure of the computer and algorithm in sufficient detail to demonstrate to one of ordinary skill in the art that the inventor possessed the invention a rejection under 35 U.S.C. 112(a) or pre-AIA 35 U.S.C. 112, first paragraph, for lack of written description must be made
Further, claims 1, 11 and 20 are also rejected because have been amended to specify that the payment processing module “processes patient payment and generates an invoice prior to transmission of the e-prescription”.
Upon review of paragraph 61 of the specification, while the payment processing module is operable to process a payment and generates an invoice, the specification is silent as to generating said invoice “prior to transmission of the e-prescription” as claimed. This aspect of the amendment is new matter and not supported by the specification.
Claims 2-10 and 12-19 are dependent on claims 1 and 11 and thus inherit the deficiency and are also rejected.
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-20 rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim limitations “conversation engine”, “a comparator”, “a prescription generation module”, “a communication module”, “a location module”, “an administrative portal”, and “a payment processing module” invokes 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. However, the written description fails to disclose the corresponding structure, material, or acts for performing the entire claimed function and to clearly link the structure, material, or acts to the function. Par. [0039] of the specification describes these modules as being, “embodied directly in hardware, in a software module executed by a processor, or in a combination of the two.” This makes it unclear what structure the modules would take. Therefore, the claim is indefinite and is rejected under 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, second paragraph.
Applicant may:
(a) Amend the claim so that the claim limitation will no longer be interpreted as a limitation under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph;
(b) Amend the written description of the specification such that it expressly recites what structure, material, or acts perform the entire claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
(c) Amend the written description of the specification such that it clearly links the structure, material, or acts disclosed therein to the function recited in the claim, without introducing any new matter (35 U.S.C. 132(a)).
If applicant is of the opinion that the written description of the specification already implicitly or inherently discloses the corresponding structure, material, or acts and clearly links them to the function so that one of ordinary skill in the art would recognize what structure, material, or acts perform the claimed function, applicant should clarify the record by either:
(a) Amending the written description of the specification such that it expressly recites the corresponding structure, material, or acts for performing the claimed function and clearly links or associates the structure, material, or acts to the claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
(b) Stating on the record what the corresponding structure, material, or acts, which are implicitly or inherently set forth in the written description of the specification, perform the claimed function. For more information, see 37 CFR 1.75(d) and MPEP §§ 608.01(o) and 2181.
Claim 1 recites a step of “transmit the e-prescription to a pharmacy” and has been amended to add a location module “to determine a patient location and provides a list of pharmacies within a predefined radius for selection, the communication module securely transmits the e-prescription to the selected pharmacy”. Claim 1 now provides a list of pharmacies and transmits the e-prescription to one of said pharmacies. However, the claim does not provide any description or details on how to determine or choose which of the listed pharmacies to transmit the e-prescription to. For example, does the patient select the pharmacy? Is the e-prescription transmitted to the pharmacy closest to the patient location? Is the list of pharmacies provided, or the pharmacy to which the e-prescription is transmitted based on the medication associated with the prescription (e.g., the medication is in-stock or carried by the particular pharmacy). Claims 11 and 20 contain the same defect. Claims 2-10 and 12-19 are dependent on claims 1 and 11 and thus are also rejected as they do not cure the deficiency of claims 1 and 11.
Claims 2 and 12 recites “a location module to determine the location of the patient and to provide a list of pharmacies within a predefined radius of the location of the patient”. It is unclear if this location module is separate and distinct (e.g., a second location module) from the location module of claims 1 and 11, which serves “to determine a patient location and provides a list of pharmacies within a predefined radius for selection”, the predefined radius being presumed to be the patient location. Clarification is required.
Claims 3 and 13 recite “a payment processing module to receive a payment from the patient and to distribute at least a portion of the payment to one or more recipients” and claims 4 and 14, which depends on claims 3 and 13 respectively, specifies that “the payment processing module is operable to generate an invoice associated with the e-prescription” and “the payment processing module is operable to generate an invoice associated with the e-prescription, wherein the payment processing module is in operable communication with the pharmacy API”. It is unclear if this payment processing module is separate and distinct (e.g., a second payment processing module) from the payment processing module of claim 1, which “processes patient payment and generates an invoice prior to transmission of the e-prescription”. Claims 1 and claims 3-4 differ in the distribution of payment to multiple recipients versus being silent as to payment distribution, and that the generated invoice is associated with an e-prescription versus prior to transmission of the e-prescription. It would appear that claim 3 is intended to further narrow the payment processing module of claim 1 to add the function of “to distribution at least a portion of the payment to one or more recipients” and claim 4 is intended to narrow the payment processing module of claim 1 to specify that the generated invoice is “associated with the e-prescription”. Similarly, it appears that claim 13 is intended to further narrow the payment processing module of claim 11 to add the function of “to distribution at least a portion of the payment to one or more recipients” and claim 14 is intended to add that the payment processing module is in operable communication with the pharmacy API. Clarification is required.
Claims 6 and 16 recites “a medication database to store the medication dataset, wherein the medication dataset is comprised of a plurality of antibiotics”. It is unclear if this medication database is separate and distinct (e.g., a second medication database) from the medication database of claims 1 and 11, where specifies that “medication dataset being stored in a medication database”. It would appear that claims 6 and 16 are intended to further narrow the medication database of claims 1 and 11 to specify the type of medication dataset stored in the medication database. Clarification is required.
Claims 8 and 18 seemingly introduce “an AI-enabled chat bot operable to… transmit automated communications to the patient; receive a plurality of patient-input communications; and… to identify a patient condition and determine if it is a qualified condition for a prescription and then recommend the medication to the patient based on the product algorithm”. However, claims 1 and 11 already recite “an AI-enabled chat bot configured to transmit automated questions, receive patient-input communications via the user interface” but that the conversation engine “generate[s] a recommended medication when a qualified condition is identified”. It is unclear is claims 8 and 18 are introducing a separate and distinct AI enabled chatbot than claims 1 and 11, and also whether it is the AI enabled chatbot or the conversation engine that generates a recommended medication when a qualified condition is identified.
Claim 8 recites “the product algorithm”. However, there is no antecedent basis for this term within claim 8, or claim 1, upon which claim 8 depends on.
Claim 15 recites a patient database, and specifies that “the patient database is a HIPAA compliant electronic health record”. It is unclear how a EHR can be a database.
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 is/are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more.
Step 1
The claim(s) recite(s) subject matter within a statutory category as a process (claim 20), machines (claims 1 and 11), which are recited as a methods and systems that perform the steps and/or functions of:
an application server in operable communication with the user network, the application server configured to host an application program for providing healthcare services and enabling an interaction between a healthcare provider using artificial intelligence and a patient, the application program having a user interface module for providing access to the application program via the at least one user computing device;
a conversation engine to analyze a plurality of patient symptoms and a plurality of patient medical information to evaluate the plurality of patient symptoms and the plurality of patient medical information, the conversation engine including an AI-enabled chat bot configured to transmit automated questions, receive patient-input communications via the user interface, and evaluate the patient symptoms and medical information using a clinical dataset of acute conditions stored in system databases;
wherein the conversation engine is further configured to identify a non-qualified condition, a qualified condition that allows for a prescription, and a high risk condition that necessitates a face-to-face medical evaluation, and to generate a recommended medication when a qualified condition is identified;
a comparator in operable communication with the conversation engine to compare the plurality of patient symptoms and the plurality of patient medical information to a clinical dataset to enable the determination of a medication from a medication dataset, the clinical dataset and medication dataset being stored in a medication database and accessed via a database engine;
a prescription generation module to associate the medication with the patient to generate an e-prescription, the e-prescription including patient identifiers and medication attributes and being formatted for electronic prescribing and digitally signed by the system and
a communication module to transmit the e-prescription to a pharmacy and
a location module to determine a patient location and provides a list of pharmacies within a predefined radius for selection, the communication module securely transmits the e-prescription to the selected pharmacy and records the transmission, and an administrative portal exposes the generated e-prescription for asynchronous validation after transmission; and
wherein a payment processing module processes patient payment and generates an invoice prior to transmission of the e-prescription.
Claim 11 additionally recites:
an administrative portal being accessible via the healthcare provider, the administrative portal to permit the healthcare provider to review the e-prescription and to validate, via an e-signature, the e-prescription;
a communication module to transmit the validated e-prescription to a pharmacy having a pharmacy API in operable communication with the application server, the communication module to provide an automated process of delivering validated e-prescription to the pharmacy.
Step 2A: Prong 1
When taken individually and as a whole, the underlined steps corresponds to concepts identified as abstract ideas by the courts, such as “certain methods of organizing human activity”, which are interactions between individuals that can include: fundamental economic principles or practices; commercial or legal interactions (including agreements in the form of contracts; legal obligations; advertising, marketing or sales activities or behaviors; business relations); and managing personal behavior or relationships or interactions between people (including social activities, teaching, and following rules or instructions).
The claim is directed to a system to perform the process of diagnosing a patient and writing a prescription for a patient, generating an invoice and processing patient payment, which is performed by the system performing the above underlined limitations of the claimed invention. The underlined limitations encompass rules or instructions followed to analyze medical data of a patient to prescribe a medication for the patient and facilitate payment. If a claim limitation, under its broadest reasonable interpretation, covers managing personal behavior or relationships or interactions between people, but for the recitation of generic computer components, then it falls with the “certain methods of organizing human activity” grouping of abstract ideas. Accordingly, the claims recite an abstract idea.
Step 2A: Prong 2
Independent claims 1, 11 and 20 recite additional elements:
At least one user computing device
A user network
An application server
An application program
Artificial intelligence
A user interface module
A conversation engine
An AI-enabled chat bot
a medication database
database engine
prescription generation module
e-prescription… being formatted for electronic prescribing and digitally signed
a communication module
a location module
an administrative portal
a payment processing module
a pharmacy API
The claims do not include additional elements that are sufficient to be considered a practical application because the additional elements amount to: insignificant extra-solution activity (MPEP 2106.05(g)), generally linking the application of the abstract idea to a particular field of use or technological environment (2106.05(h)), or mere instructions to apply it with a computer (MPEP 2106.05(f)), as discussed below.
The “artificial intelligence”, “AI enabled chat bot” is described at a high level of generality as the specification does not provide any description of the mechanism for accomplishing the result such that using artificial intelligence and AI-enabled chat bot amounts to no more than a recitation of the words “apply it” (or an equivalent), such as mere instructions to implement an abstract an abstract idea on a computer, generally linking the use of a judicial exception to a particular technological environment or field of use (i.e., computing), which does not serve to impose meaningful limits on the scope of the claim.
Further, electronic/digital or “e” prescriptions and signatures amount to no more than mere instructions to implement an abstract an idea on or using a computer, and only generally links the use of a judicial exception to a particular technological environment or field of use (i.e., computing), which does not serve to impose meaningful limits on the scope of the claim.
Further, “transmit[ting] the e-prescription to a pharmacy” and “record the transmission”, amount to no more than mere instructions to implement an abstract an idea on or using a computer, and only generally links the use of a judicial exception to a particular technological environment or field of use (i.e., computing), and amounts to insignificant extra-solution activity, as sending/transmitting/storing the result of the abstract idea (the prescription with medication) does not serve to impose meaningful limits on the abstract idea.
Mere Instructions to Apply the Abstract Idea Using a Computer
The steps reciting the use of computer components, such as the above bolded limitations of the claimed invention, serve as mere instructions to apply the abstract idea using a computer. Mere instructions to apply the abstract idea using a computer are not sufficient to integrate the abstract idea into a practical application or amount to significantly more than the abstract idea (MPEP 2106.05(f)).
Step 2B
The claims also do not include additional elements that are sufficient to be considered a significantly more than the abstract idea because the additional elements amount to: insignificant extra-solution activity (MPEP 2106.05(g)), mere instructions to apply it with a computer (MPEP 2106.05(f)), generally linking the application of the abstract idea to a particular field of use or technological environment (MPEP 2106.05(h)), or a well-understood, routine, and conventional limitation (MPEP 2106.05(d)), as discussed below.
The steps addressed above in Step 2A: Prong 2, when considered again under Step 2B are not considered to make the claims amount to significantly more than the abstract idea because those steps, when considered additionally with regards to Step 2B, are still considered to be either insignificant extra-solution activity, mere instructions to apply an abstract idea with a computer, or generally linking the application of the abstract idea to a particular field of use or technological environment, which are types of limitations that are not sufficient to make the claims amount to significantly more than the abstract idea (MPEP 2106.05.I.A).
The steps recited as either being part of the abstract idea or insignificant extra-solution activity are all examples of at least one of: storing and retrieving data from a memory, sending and receiving data over a network, electronic recordkeeping, or performing repetitive calculations. All of those functions have been identified as well-understood, routine, and conventional functions of a generic computer that are not significantly more than the abstract idea when claimed broadly or as an extra-solution activity (MPEP 2106.05(d).II).
The recited computer components (e.g., the computing device, the user network, the modules, APIs) are all generically recited components (see specification, par. [0031]-[0048] and [0068]-[0076]). Commercially available components, generic computer components, and specially-programmed computer components performing the functions of a generic computer are not considered to be amount to significantly more than the abstract idea (MPEP 2106.05(b)).
When considered as a whole, as an ordered combination, the components do not provide anything that is not present when the component parts are considered individually. Using the broadest reasonable interpretation, the system as a whole is a system of general purpose computer components analyzing data to diagnose and generate a prescription for a patient. This is a general purpose computer system performing the abstract idea and insignificant extra-solution activities through these generically described devices performing well-understood, routine, and conventional functions of a generic computer (MPEP 2106.05(d).II).
Dependent Claim Analysis
Claims 2-10 are ultimately dependent from Claim(s) 1 and includes all the limitations of Claim(s) 1. Therefore, claim(s) 2-10 recite the same abstract idea of certain methods of organizing human activity of claim 1.
Claims 2 and 7 recite additional limitations that serve to select by type or source the data to be manipulated, which is an insignificant extra-solution activity that is not sufficient to integrate the abstract idea into a practical application or amount to significantly more than the abstract idea (MPEP 2106.05(g)).
Claims 3-4 and 9-10 further describe the abstract idea by providing additional limitations regarding completing a payment transaction for the services provided to the user. The abstract idea and additional limitations that amount to an abstract idea are not capable of integrating the abstract idea into a practical application or amount to significantly more than the abstract idea (MPEP 2106.04.II.A.2). Additional limitations regarding the computer component that would perform these functions are limitations that amount to mere instructions to apply the abstract idea using a computer (MPEP 2106.05(f)).
Claims 5-6 recite additional limitations that amount to data gathering by describing the types of data to be collected by the system and stored in databases. Mere data gathering is an insignificant extra-solution activity that is not sufficient to integrate the abstract idea into a practical application or amount to significantly more than the abstract idea (MPEP 2106.05(g)), and the practice of storing and retrieving data in a memory is an example of a well-understood, routine, and conventional function of a general purpose computer when claimed broadly or as insignificant extra-solution activity (MPEP 2106.05(g)).
Claim 8 recites additional limitations further describing the abstract idea by describing the ability for the system to perform a similar process for diagnosing a patient and providing a prescription as the method in claim 1. The abstract idea and additional limitations that amount to an abstract idea are not capable of integrating the abstract idea into a practical application or amount to significantly more than the abstract idea (MPEP 2106.04.II.A.2). The limitation describing this being done by an AI-chatbot is mere instructions to apply using a computer (MPEP 2106.05(f)).
Claims 12-19 are ultimately dependent from Claim(s) 11 and includes all the limitations of Claim(s) 11. Therefore, claim(s) 12-19 recite the same abstract idea of certain methods of organizing human activity of claim 11.
Claims 12-18 recite additional limitations that are the same or substantially similar to the additional limitations from claims 2-8, respectively. Claims 12-18 are rejected under 101 for the same reasons as claims 2-8.
Claim 19 recites additional limitations that amount to selecting by type or source the data to be manipulated by describing the information to be included in the e-prescription. Selecting by type or source the data to be manipulated is an insignificant extra-solution activity that is not sufficient to integrate the abstract idea into a practical application or amount to significantly more than the abstract idea (MPEP 2106.05(g)).
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) 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-20 are rejected under 35 U.S.C. 103 as being unpatentable over Kannan (US PG Pub 20230105969) in view of Corlett (US PG Pub 20240029879) in view of Karbowicz et al. (US PG Pub 20240087708) in view of Selfridge (US PG Pub 20230188506).
Claim 1
Kannan teaches a system for automating patient condition analysis and prescription generation, the system comprising:
at least one user computing device in operable connection with a user network (Fig. 4, paragraph 42: medical decision support system 100 may interface with a user (e.g., a patient, a medical expert, etc.) via the user interface 102. The user may access the user interface 102 through at least one of a plurality of user devices 101, which may comprise a laptop, a smartphone, a tablet, smart speakers, digital assistances, etc.);
an application server in operable communication with the user network, the application server configured to host an application program for providing healthcare services and enabling an interaction between a healthcare provider using artificial intelligence and a patient, the application program having a user interface module for providing access to the application program via the at least one user computing device (paragraph 42: the user interface 102 may be in communication with the system 100 backend, which may comprise a user information module 108, a conversational engine 114, a differential diagnosis engine 116, a knowledge base 118 and a data/knowledge input module 120; paragraph 45: the DDx 116 may be based on rules in a knowledge based codifying probabilistic relationships between symptoms/findings and diseases. In another embodiment, the DDx 116 may be based on machine-learned models deriving relations between symptoms/findings and diseases from historical medical records. In yet another embodiment, the DDx 116 may be based on machine-learned models deriving both probabilities and relationships from historic medical records. In another embodiment, the DDx 116 may be based on machine-learned models learned from mixed data that includes at least one of synthetic data generated by a pre-existing expert system, electronic medical records, manual cases, labeled cases from the diagnosis engine; paragraphs 60-65: the engine 408 may be the backend server for a medical decision support system and may provide the following functionalities: Functionalities available on the Admin App and the Client App, Packaging all supported knowledge bases in the medical decision support system, Implementing algorithms that operate on the knowledge bases to provide functionalities such as next question to be posed to a patient and diagnosis to be presented to the patient, Logging user activity and managing user session history, Providing messaging support between patients and medical experts);
a conversation engine to analyze a plurality of patient symptoms and a plurality of patient medical information to evaluate the plurality of patient symptoms and the plurality of patient medical information, the conversation engine including an AI-enabled chat bot configured to transmit automated questions, receive patient-input communications via the user interface, and evaluate the patient symptoms and medical information using a clinical dataset of acute conditions stored in system databases (paragraph 43: The user input interface 104 may allow input from the user… Sometimes, the user output interface 106 may also need to present the user with questions in order to elicit additional and the right kind of information such that the system 100 is able provide a confident recommendation; paragraph 45: The conversational engine 114 may be in charge of understanding user's input(s), reasoning about the user's input(s), and deciding what is the most appropriate output(s) after consulting with the DDx 116 and the KB 118. The DDx 116 may produce a ranked list of possible diagnoses given any number of findings, which may be symptoms expressed by the patient as well as their history, demographics, etc.);
wherein the conversation engine is further configured to identify a non-qualified condition (paragraph 121: Similarly, some situations may require the patient to undergo some form of laboratory testing), a qualified condition that allows for a prescription (paragraph 114: Some of those treatments may involve prescriptions or recommendations for over-the-counter medications…the system 100 may facilitate the paperwork of prescribing and forwarding the prescription onto a pharmacy), and a high risk condition that necessitates a face-to-face medical evaluation (paragraph 105: In most situations, the triaging decision may be accomplished by formulating a diagnosis and classifying the diagnosis into the required attention and urgency. However, in many other situations, the simple existence of a symptom can trigger a triage recommendation. For example, chest pain on an elderly patient or high fever in an infant will trigger an automatic recommendation to visit the emergency room regardless of the confidence on the diagnosis; paragraph 121: In some cases, the kind of testing might be available through some form of at-home procedure (e.g., blood pressure), but in many other cases the patient may need to visit a physician or pharmacist), and to generate a recommended medication when a qualified condition is identified (paragraph 105: the goal to the system 100 is to answer patient questions by giving a set of actionable recommendations that may include not only a diagnostic and triaging, but also referral or treatment);
a comparator in operable communication with the conversation engine to compare the plurality of patient symptoms and the plurality of patient medical information to a clinical dataset to enable the determination of a medication from a medication dataset (paragraph 105: the triaging decision may be accomplished by formulating a diagnosis and classifying the diagnosis into the required attention and urgency. However, in many other situations, the simple existence of a symptom can trigger a triage recommendation; paragraph 113: Given a disease, or cluster of diseases that may afflict a patient, a component of the system 100 may be designed to sort through alternative possible treatments, qualify them based upon relevance to the patient's symptoms and history, and propose possible treatments that the patient could pursue; paragraph 114: Some of those treatments may involve prescriptions or recommendations for over-the-counter medications), the clinical dataset and medication dataset being stored in a medication database and accessed via a database engine (paragraphs 115-120: The system 100 may include a database of pharmacy within which it can: Cross-check against other medications the patient may be taking, Validate dosage for the demographics, weight, gender of the patient, Warn about possible side-effects, and incorporate follow-up on such side-effects in future interactions with the patient, Evaluate responses to prescribed medications to confirm or reduce weight on previous conclusions about the patient's disease or condition, Guide or advise on substitutions with alternatives or generic medications that may be differentially available, covered by insurance, and have differing efficacies);
a communication module to transmit the e-prescription to a pharmacy (paragraph 114: Some of those treatments may involve prescriptions or recommendations for over-the-counter medications…the system 100 may facilitate the paperwork of prescribing and forwarding the prescription onto a pharmacy); and
the communication module securely transmits the e- prescription to the selected pharmacy (paragraph 114: Some of those treatments may involve prescriptions or recommendations for over-the-counter medications…the system 100 may facilitate the paperwork of prescribing and forwarding the prescription onto a pharmacy) and records the transmission, and
Although not explicitly taught by Kannan, Corlett teaches:
a prescription generation module to associate the medication with the patient to generate an e-prescription, the e-prescription including patient identifiers and medication attributes and being formatted for electronic prescribing and digitally signed by the system (paragraph 95: through the practitioner interface, the server is able to receive a prescription from a practitioner profile, with the prescription being associated with a patient profile. In one embodiment, in order to generate the prescription, the platform receives personal health information regarding the patient from the practitioner device. In one embodiment, the platform receives information including the name of the patient, at least one contact method for the patient (e.g., a phone number, an email address, a home address, etc.), and/or a gender of the patient. In one embodiment, the platform receives information including any conditions (chronic or otherwise) experienced by the patient, any allergies of the patient, a medical record of the patient (e.g., including past illnesses, surgeries, etc.), vitals information for the patient (e.g., body temperature, blood sugar, height, weight, BMI, blood pressure, O2 saturation and/or pulse rate), current symptoms experienced by the patient, one or more diagnosed conditions for the patient, one or more lab test results, one or more other medicines taken by the patient (prescribed or unprescribed), one or more suggested lab work tests, a text summary of an appointment, a follow-up appointment date and time, additional comments, and/or other health information. In one embodiment, the platform receives a signature from the practitioner device to allow the prescription (e.g., a digital signature, a scanned signed document, etc.). In one embodiment, the platform automatically transmits the prescription information to a designated home pharmacy associated with the patient profile. In one embodiment, the practitioner interface is integrated with at least one third party data management system (e.g., EPIC), including application programming interface (API) plugins providing for automatic transcription with a suggested list of International Classification of Diseases (ICD)-10 diagnosis codes, decreasing the amount of time needed for practitioners to enter and characterize patient symptoms);
an administrative portal exposes the generated e-prescription for physician validation (paragraph 95: the platform receives a signature from the practitioner device to allow the prescription (e.g., a digital signature, a scanned signed document, etc.).);
generating an invoice prior to transmission of the e-prescription (paragraph 82: After a consultation or session, the integrated billing module is operable to display an amount of money due by the patient) {an invoice is prepared for the patient for the costs of the consultation, prior to any bill for fulfilling a prescription at a pharmacy}.
Although not taught by Kannan or Corlett, Karbowicz teaches:
a location module to determine a patient location and provides a list of pharmacies within a predefined radius for selection (paragraph 73: The method 500 begins at 502, which includes sending the prescription to a plurality of desired pharmacies, as indicated by the patient. The desired pharmacies may meet one or more parameters indicated by the patient, which may include being within a desired area, business hours being within a desired range, availability, in-network for the patient's insurance, and the like. The desired area may be based on a desired radius set by the patient. For example, the patient may set a radius of 10 miles from an initial location (e.g., home, work, prescriber office, etc.), wherein the central server may gather a list of pharmacies within the indicated radius),
wherein a payment processing module processes patient payment and generates an invoice upon transmission of the e-prescription (paragraph 43: electronic payment preferences may include an electronic payment source stored to the patient profile. In one example, the electronic payment source may include credit card information, debit card information, bank routing information, and/or the like. In this way, if patient preferences associated with the patient profile are adjusted to indicate a desire to electronically pay for prescription(s), then the electronic prescription wallet central service 120 may send payment information to a pharmacy when requesting the pharmacy to fill a prescription on behalf of the patient; paragraph 47: If funds are still due for the prescription, then the receipt sent to the electronic prescription wallet central service 120 may further include a request for payment. The electronic prescription wallet central service 120 may access a patient's electronic payment information stored in conjunction with their patient profile and send the payment information to the pharmacy system 180 in accordance with patient preference; paragraph 70: The method 400 may proceed to 406, which may include determining if the patient received the filled prescription. The pharmacy may signal to the central server, via a local client, that the patient has received the prescription. In some examples, this may correspond to a charge to the profile of the patient. That is to say, once the patient receives the prescription, the pharmacy may request payment information from the central server, wherein the request may indicate the patient receiving the prescription).
While Kannan teaches asynchronous tasks (paragraph 66: A Celery 518, which may be included in the engine 408, is an asynchronous task queue/job queue based on distributed message passing. The Celery 518 may be focused on real-time operation, and may also supports scheduling. The Celery 518 may be used in the engine 4408 to schedule and execute non-blocking tasks, such as sending messages, thereby allowing the Flask server 510 to respond to users' requests quickly without being blocked by slow calls that may be executed asynchronous. A Redis 516, which also may be include in engine 408, is an in-memory data structure store that may be used as a database, cache, and message broker. The engine 408 may schedule asynchronous tasks).
Although not taught by Kannan, Corlett or Karbowicz, Selfridge teaches asynchronous physician validation of a prescription after it is generated and transmitted (paragraph 69: the health provider 505 includes a physician 510 (or other authorized healthcare provider) that initiates treatment prescriptions 520 and prophylactic prescriptions 525, or updates/creates the patient records 530. In order to actually treat a patient, or provide a medical service to the patient, these objects are transmitted asynchronously to the pharmacy network 540 or patient services 560. For example, for the patient to obtain the prescriptions 520, 525, the health provider 505 forwards orders for the prescriptions 520, 525 to the pharmacy network 540. However, as mentioned above, the health provider 505 and the pharmacy network 540 may be two separate entities (e.g., two different companies) that use very different computing systems executing disparate software suites. Given the differences, asynchronous communication is used along with a confirmation or handshaking protocol to ensure the prescription orders were successfully received).
Similar to Corlett, Karobowicz also teaches generating an invoice prior to transmission of the e-prescription to the selected pharmacy (paragraph 65: if the patient decides to shop the prescription, the central server may send the prescription to a plurality of desired pharmacies, wherein the central server may receive a plurality of bids from the plurality of pharmacies. The controller may process the plurality of bids and correlate the plurality of bids to the patient profile. As such, a display of the patient profile may be adjusted to include the plurality of bids. The central server may further receive a request to fill the prescription at a pharmacy. As such, the central server may send a request to a pharmacy, which may include patient data including the prescription information, patient information, and patient payment information; paragraph 96: The third party system may further allow the patient to compare bids for filling the prescription and pay for the prescription via payment information saved to a profile of the patient.) {soliciting bids from a plurality of pharmacies for a price/cost to fill the prescription prior to the prescription being sent to a selected pharmacy for fulfilment and paying the bid amount}.
Kannan, Corlett, Karbowicz, and Selfridge are all analogous references as they are in the same field of endeavor striving to solve similar problems. Specifically, Kannan evaluates patient conditions to present medical recommendations, Corlett generates a prescription for medicine to be sent to a pharmacy for fulfillment in response to a patient’s symptoms, Karbowicz et al. allows a patient to maintain control of electronic prescriptions associated to them to fulfillment at an assigned pharmacy, and Selfridge allows for asynchronous communication between different computing systems, such as a pharmacy computing system and medical provider computing system. Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the teachings of Kannan to generate an e-prescription including patient identifiers and medication attributes and associating a medication with the patient, the e-prescription being formatted for electronic physician validation and being digitally signed as taught by Corlett, to determine a patient location and provides a list of pharmacies within a predefined radius for selection as taught by Karabowicz, processes patient payment and generates an invoice prior to transmission of the e-prescription as taught by Karobowicz and Corlett, and asynchronous physician validation of a prescription after it is generated and transmitted as taught by Selfridge because doing so facilitates the collaboration of a plurality of distinct providers (health professionals, pharmacies) operating independently of one another to provide appropriate treatment to address symptoms being experienced by a patient and facilitating payment/compensation for services provided.
Claims 11 and 20
Claims 11 and 20 recite substantially similar limitations to claim 1 above; thus, the same rejection applies.
Further regarding claim 11, Corlett teaches
an administrative portal being accessible via the healthcare provider, the administrative portal to permit the healthcare provider to review the e-prescription and to validate, via an e-signature, the e-prescription (paragraph 95: the platform receives a signature from the practitioner device to allow the prescription (e.g., a digital signature, a scanned signed document, etc.).);
a communication module to transmit the validated e-prescription to a pharmacy having a pharmacy API in operable communication with the application server, the communication module to provide an automated process of delivering validated e-prescription to the pharmacy (paragraph 95: the platform automatically transmits the prescription information to a designated home pharmacy associated with the patient profile. In one embodiment, the practitioner interface is integrated with at least one third party data management system (e.g., EPIC), including application programming interface (API) plugins providing for automatic transcription).
Karbowicz et al. teaches recording the transmission of the e-prescription to a pharmacy (paragraph 71: If the patient has received the filled prescription, then the method 400 may proceed to 410, which may include updating the patient profile to indicate the prescription is filled. The updating may further include date, time, location, payment information, and the like. Furthermore, the profile may be updated such that the prescription may comprise one fewer fill along with a cost of the prescription).
As previously noted, Kannan, Corlett, Karbowicz, and Selfridge are all analogous references as they are in the same field of endeavor striving to solve similar problems. Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the teachings of Kannan to permit the healthcare provider to review and validate the e-prescription and transmitting the validated e-prescription to a pharmacy as taught by Corlett and recording the transmission of the e-prescription as taught by Karbowicz et al. because doing so facilitates the collaboration of a plurality of distinct providers (health professionals, pharmacies) operating independently of one another to provide appropriate treatment to address symptoms being experienced by a patient and facilitating payment/compensation for services provided.
Claims 2 and 12
Kannan in view of Corlett in view of Karbowicz et al. in view of Selfridge teaches the system of claim 1, and Karbowicz et al. teaches:
a location module to determine a patient location of the patient and to provide a list of pharmacies within a predefined radius for selection (paragraph 73: The method 500 begins at 502, which includes sending the prescription to a plurality of desired pharmacies, as indicated by the patient. The desired pharmacies may meet one or more parameters indicated by the patient, which may include being within a desired area, business hours being within a desired range, availability, in-network for the patient's insurance, and the like. The desired area may be based on a desired radius set by the patient. For example, the patient may set a radius of 10 miles from an initial location (e.g., home, work, prescriber office, etc.), wherein the central server may gather a list of pharmacies within the indicated radius).
As previously noted, Kannan, Corlett, Karbowicz, and Selfridge are all analogous references as they are in the same field of endeavor striving to solve similar problems. Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the teachings of Kannan to provide a list of pharmacies within a predefined radius of a patient location as taught by Karbowicz et al. because doing so facilitates the collaboration of a plurality of distinct providers (health professionals, pharmacies) operating independently of one another to provide appropriate treatment to address symptoms being experienced by a patient and facilitating payment/compensation for services provided.
Claim 12 recites limitations substantially similar to claim 2; thus the same rejection applies.
Claims 3 and 13
Kannan in view of Corlett in view of Karbowicz et al. in view of Selfridge teaches the system of claim 1. Corlett teaches a payment processing module to pay a doctor for consultation costs/fees (paragraph 78: the platform is able to facilitate a live call (e.g., audio call, video call, etc.) between a service provider and the patient. The platform is then able to automatically facilitate consultation billing for the call, including facilitating insurance payments. If the service provider has prescribed anything to the patient, the platform is then able to automatically inform a relevant pharmacy of the prescription and notify the patient regarding details of the prescription; paragraph 82: After a consultation or session, the integrated billing module is operable to display an amount of money due by the patient) {an invoice is prepared for the patient for the costs of the consultation prior to any bill for fulfilling a prescription at a pharmacy, the service provider/doctor being a recipient of patient payment} and Karbowicz et al. teaches a payment processing module to receive a payment from the patient and to distribute at least a portion of the payment to one or more recipients (paragraph 43: electronic payment preferences may include an electronic payment source stored to the patient profile. In one example, the electronic payment source may include credit card information, debit card information, bank routing information, and/or the like. In this way, if patient preferences associated with the patient profile are adjusted to indicate a desire to electronically pay for prescription(s), then the electronic prescription wallet central service 120 may send payment information to a pharmacy when requesting the pharmacy to fill a prescription on behalf of the patient; paragraph 47: If funds are still due for the prescription, then the receipt sent to the electronic prescription wallet central service 120 may further include a request for payment. The electronic prescription wallet central service 120 may access a patient's electronic payment information stored in conjunction with their patient profile and send the payment information to the pharmacy system 180 in accordance with patient preference; paragraph 70: The method 400 may proceed to 406, which may include determining if the patient received the filled prescription. The pharmacy may signal to the central server, via a local client, that the patient has received the prescription. In some examples, this may correspond to a charge to the profile of the patient. That is to say, once the patient receives the prescription, the pharmacy may request payment information from the central server, wherein the request may indicate the patient receiving the prescription) {the pharmacy being another recipient of the payment from the patient}
As previously noted, Kannan, Corlett, Karbowicz, and Selfridge are all analogous references as they are in the same field of endeavor striving to solve similar problems. Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the teachings of Kannan to process payment from a patient for doctor consultation fees as taught by Corlett and payment to fill an e-prescription as taught by Karbowicz et al. because doing so facilitates the collaboration of a plurality of distinct providers (health professionals, pharmacies) operating independently of one another to provide appropriate treatment to address symptoms being experienced by a patient and facilitating payment/compensation for services provided.
Claim 13 recites limitations substantially similar to claim 3; thus the same rejection applies.
Claims 4 and 14
Kannan in view of Corlett in view of Karbowicz et al. in view of Selfridge teaches the system of claim 3, and Karbowicz et al. further teaches wherein the payment processing module is operable to generate an invoice associated with the e-prescription (paragraph 70: The method 400 may proceed to 406, which may include determining if the patient received the filled prescription. The pharmacy may signal to the central server, via a local client, that the patient has received the prescription. In some examples, this may correspond to a charge to the profile of the patient).
As previously noted, Kannan, Corlett, Karbowicz, and Selfridge are all analogous references as they are in the same field of endeavor striving to solve similar problems. Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the teachings of Kannan to generate an invoice associated with the e-prescription as taught by Karbowicz et al. because doing so facilitates the collaboration of a plurality of distinct providers (health professionals, pharmacies) operating independently of one another to provide appropriate treatment to address symptoms being experienced by a patient and facilitating payment/compensation for services provided.
Claim 14 recites limitations substantially similar to claim 4; thus the same rejection applies. Further, Cortlett teaches wherein the payment processing module is in operable communication with the pharmacy API (paragraph 95: the platform automatically transmits the prescription information to a designated home pharmacy associated with the patient profile. In one embodiment, the practitioner interface is integrated with at least one third party data management system (e.g., EPIC), including application programming interface (API) plugins providing for automatic transcription).
As previously noted, Kannan, Corlett, Karbowicz, and Selfridge are all analogous references as they are in the same field of endeavor striving to solve similar problems. Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the teachings of Kannan for payment processing to be operably communicative with a pharmacy API as taught by Corlett because doing so facilitates the collaboration of a plurality of distinct providers (health professionals, pharmacies) operating independently of one another to provide appropriate treatment to address symptoms being experienced by a patient and facilitating payment/compensation for services provided.
Claims 5 and 15
Kannan in view of Corlett in view of Karbowicz et al. in view of Selfridge teaches the system of claim 1. Kannan further teaches comprising patient database to store a plurality of patient information comprising: the plurality of patient symptoms, a patient medical history, and a plurality of patient identifying information (paragraph 21: the information from the user includes at least one of user's medical history and the user's symptoms; paragraph 43: The user input interface 104 may allow input from the user… Sometimes, the user output interface 106 may also need to present the user with questions in order to elicit additional and the right kind of information such that the system 100 is able provide a confident recommendation; paragraph 45: The conversational engine 114 may be in charge of understanding user's input(s), reasoning about the user's input(s), and deciding what is the most appropriate output(s) after consulting with the DDx 116 and the KB 118. The DDx 116 may produce a ranked list of possible diagnoses given any number of findings, which may be symptoms expressed by the patient as well as their history, demographics, etc.;) and Corlett teaches a plurality of patient identifying information (paragraph 106: In one embodiment, the add member page receives an input from a user device of a first name, a middle name, a last name, a date-of-birth, a gender, a patient type, a relationship, at least one email address, at least one phone number, an age, a profile picture, and/or other identifying information (e.g., SSN, driver's license number, etc.).
As previously noted, Kannan, Corlett, Karbowicz, and Selfridge are all analogous references as they are in the same field of endeavor striving to solve similar problems. Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the teachings of Kannan to include patient identifying information as taught by Corlett because doing so facilitates the collaboration of a plurality of distinct providers (health professionals, pharmacies) operating independently of one another to provide appropriate treatment to address symptoms being experienced by a patient and facilitating payment/compensation for services provided.
Claim 15 recites limitations substantially similar to claim 5; thus the same rejection applies. Further, Corlett teaches wherein the patient database is a HIPAA compliant electronic health record (paragraph 2: Telemedicine platforms such as CHIRON HEALTH and DOXY.ME focus on providing HIPAA-compliant platforms for video conferencing with physicians and managing schedules, including providing automatic appointment reminders. These platforms also commonly facilitate the sharing of electronic health records and provide systems for managing billing).
As previously noted, Kannan, Corlett, Karbowicz, and Selfridge are all analogous references as they are in the same field of endeavor striving to solve similar problems. Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the teachings of Kannan to use HIPAA compliant electronic health record and platforms as taught by Corlett because doing so facilitates the collaboration of a plurality of distinct providers (health professionals, pharmacies) operating independently of one another to provide appropriate treatment to address symptoms being experienced by a patient and facilitating payment/compensation for services provided.
Claims 6 and 16
Kannan in view of Corlett in view of Karbowicz et al. in view of Selfridge teaches the system of claim 1, and Karbowicz et al. further teaches a medication database to store the medication dataset, wherein the medication dataset is comprised of a plurality of antibiotics (paragraph 24: “specialty” medications may only be designated to be filled at a health plan's designated specialty pharmacy, while chronic medications may only be designated to be dispensed from a pharmacy benefit manager's mail-order facility, and a person who is acutely ill may pick up pain medication or antibiotics from a corner drug store; paragraph 93: prescription details 1202, which may include information such as an identifier of the medication associated with the prescription (e.g., a type, brand, size/concentration, etc.)) {information on antibiotics being available from a corner drug store being indicative of the PDEPW storing information on antibiotics as a class or type of medication}.
As previously noted, Kannan, Corlett, Karbowicz, and Selfridge are all analogous references as they are in the same field of endeavor striving to solve similar problems. Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the teachings of Kannan to store information on medications, including antibiotics, as taught by Karbowicz et al. because doing so facilitates the collaboration of a plurality of distinct providers (health professionals, pharmacies) operating independently of one another to provide appropriate treatment to address symptoms being experienced by a patient and facilitating payment/compensation for services provided.
Claim 16 recites limitations substantially similar to claim 6; thus the same rejection applies.
Claims 7 and 17
Kannan in view of Corlett in view of Karbowicz et al. in view of Selfridge teaches the system of claim 6, and Kannan teaches wherein the medication database stores a plurality of medications effective in treating one or more of a plurality of acute conditions comprising the clinical dataset (paragraphs 129-131: the system 100 may include comprehensive content that may be indexed and presented in response to any question. This includes: Information about diseases, symptoms and treatments.. Information about medications).
Claim 17 recites limitations substantially similar to claim 7; thus the same rejection applies.
Claims 8 and 18
Kannan in view of Corlett in view of Karbowicz et al. in view of Selfridge teaches the system of claim 1, and Kannan teaches wherein the conversation engine includes an AI-enabled chat bot operable to perform the following:
transmit automated communications to the patient; receive a plurality of patient-input communications; and analyze the plurality of patient-input communication to recommend the medication to the patient to e-prescribe the medication for the patient to the selected pharmacy in a licensed prescriber’s name (paragraph 43: The user input interface 104 may allow input from the user… Sometimes, the user output interface 106 may also need to present the user with questions in order to elicit additional and the right kind of information such that the system 100 is able provide a confident recommendation; paragraph 45: The conversational engine 114 may be in charge of understanding user's input(s), reasoning about the user's input(s), and deciding what is the most appropriate output(s) after consulting with the DDx 116 and the KB 118. The DDx 116 may produce a ranked list of possible diagnoses given any number of findings, which may be symptoms expressed by the patient as well as their history, demographics, etc.; paragraph 114: the system 100 may include referral to a healthcare professional, who can safely prescribe medications… the system may facilitate the paperwork of prescribing and forwarding the prescription onto a pharmacy); and
to identify a patient condition and determine if it is a qualified condition for a prescription and then recommend the medication to the patient based on the product algorithm (paragraph 114: Some of those treatments may involve prescriptions or recommendations for over-the-counter medications…the system 100 may facilitate the paperwork of prescribing and forwarding the prescription onto a pharmacy).
Claim 18 recites limitations substantially similar to claim 8; thus the same rejection applies.
Claim 9
Kannan in view of Corlett in view of Karbowicz et al. in view of Selfridge teaches the system of claim 1, and Corlett further teaches comprising an administrative portal being accessible via the healthcare provider (paragraph 95: the platform receives a signature from the practitioner device to allow the prescription (e.g., a digital signature, a scanned signed document, etc.).).
As previously noted, Kannan, Corlett, Karbowicz, and Selfridge are all analogous references as they are in the same field of endeavor striving to solve similar problems. Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the teachings of Kannan to include an administrative portal accessibly by healthcare providers as taught by Corlett because doing so facilitates the collaboration of a plurality of distinct providers (health professionals, pharmacies) operating independently of one another to provide appropriate treatment to address symptoms being experienced by a patient and facilitating payment/compensation for services provided.
Claim 10
Kannan in view of Corlett in view of Karbowicz et al. in view of Selfridge teaches the system of claim 9, and Corlett further teaches wherein the administrative portal is operable to permit the healthcare provider to review and to validate the e-prescription ((paragraph 95: the platform receives a signature from the practitioner device to allow the prescription (e.g., a digital signature, a scanned signed document, etc.).)).
As previously noted, Kannan, Corlett, Karbowicz, and Selfridge are all analogous references as they are in the same field of endeavor striving to solve similar problems. Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the teachings of Kannan to allow the healthcare provider to review and validate an e-prescription using an administrative portal as taught by Corlett because doing so facilitates the collaboration of a plurality of distinct providers (health professionals, pharmacies) operating independently of one another to provide appropriate treatment to address symptoms being experienced by a patient and facilitating payment/compensation for services provided.
Claim 20
Kannan in view of Corlett in view of Karbowicz et al. in view of Selfridge teaches the system of claim 18. Kannan teaches validating medicine dosage for the patient [paragraphs 115-117: The system 100 may include a database of pharmacy within which it can… validate dosage for the demographics, weight, gender of the patient] and Corlett teaches a dosage schedule [paragraph 111: a prescription details page for a patient GUI… allows the details of the prescription to be viewed, including, but not limited to… the dosage of the prescription… how to take the prescription] {dosage of the prescription and how to take the prescription encompassing dosage frequency/schedule}.
As previously noted, Kannan, Corlett, Karbowicz, and Selfridge are all analogous references as they are in the same field of endeavor striving to solve similar problems. Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the teachings of Kannan to include information on a dosage schedule of prescribed medicine as taught by Corlett because doing so facilitates the collaboration of a plurality of distinct providers (health professionals, pharmacies) operating independently of one another to provide appropriate treatment to address symptoms being experienced by a patient and facilitating payment/compensation for services provided.
Response to Arguments
Applicant's arguments filed October 16, 2025 have been fully considered but they are not persuasive.
Applicant argues that paragraphs 5, 7, 14, 16, 26, 28, 50 and 55 of the specification supports the contention that one of ordinary skill in the art would understand the metes and bounds of claims 1-19.
This argument is not persuasive. These paragraphs of the specification only restate the function recited in the claim without disclosing the structure and algorithm for performing these computer-implemented functions.
Original claims may lack written description when the claims define the invention in functional language specifying a desired result but the specification does not sufficiently describe how the function is performed or the result is achieved. For software, this can occur when the algorithm or steps/procedure for performing the computer function are not explained at all or are not explained in sufficient detail (simply restating the function recited in the claim is not necessarily sufficient). In other words, the algorithm or steps/procedure taken to perform the function must be described with sufficient detail so that one of ordinary skill in the art would understand how the inventor intended the function to be performed. See MPEP §§ 2163.02 and 2181, subsection IV.
The written description fails to disclose the corresponding structure, material, or acts for performing the entire claimed function and to clearly link the structure, material, or acts to the function. The specification lacks adequate structure to perform the claimed function. The specification does not provide sufficient details such that one of ordinary skill in the art would understand what structure or structure(s) perform the claimed function. Therefore, the claim is indefinite and is rejected under 35 USC 112B.
Applicant argues that independent claims 1, 11 and 20 recite elements demonstrating that the claims, as a whole, integrate the subject matter into a practical application and amount to far more than mere instructions to apply an abstract idea via a generic computer component or extra-solution activity as the amended portions cannot be performed or made in the human mind or be considered a method of organizing human activity.
Applicant argues that each of the limitations amended into the independent claims (AI-enabled chat bot, medication database, e-prescription contents, location module, communication module, administrative portal, payment processing module) serves to provide subject matter eligibility because it is not a mental process or organizes human activity, integrates subject matter into a practical application, is not well-known routine or conventional, and provide an improvement to the computer on which they operate.
Applicant argues each step of the claimed invention is tied to specific computer components and stored datasets, requires particular data structures and modules to operate, and culminates in a machine-generated, machine-formatted e-prescription that is location-sorted, paid for, transmitted over defined communication channels, logged, and then validated through an administrative portal in asynchronous physician oversight, integrating any abstract idea into a practical application with improvements to telehealth e-prescribing workflows and computer functionalities. Applicant argues that the claimed operations require substantial computing power, access to memory, and algorithmic processing and thus are necessarily rooted in computer technology.
These arguments are not persuasive.
Firstly, the claims recite an abstract idea in accordance with the ‘certain methods of organizing human activity’ grouping, but ‘mental process’ is not a basis on which the claims are being rejected as ineligible under 35 USC 101. The claims recite limitations for performing the process of diagnosing a patient and writing a prescription for a patient, generating an invoice and processing patient payment, which encompass rules or instructions followed to analyze medical data of a patient to prescribe a medication for the patient for fulfillment, which organizes human activity. Furthermore, facilitating payment by the patient, as recited in the claim, is a fundamental economic practice.
The “artificial intelligence” and “AI enabled chat bot” are described at a high level of generality as the specification does not provide any description of the mechanism for accomplishing the result such that using artificial intelligence and AI-enabled chat bot amounts to no more than a recitation of the words “apply it” (or an equivalent), such as mere instructions to implement an abstract an abstract idea on a computer, generally linking the use of a judicial exception to a particular technological environment or field of use (i.e., computing), which does not serve to impose meaningful limits on the scope of the claim.
Further, electronic/digital or “e” prescriptions and signatures amount to no more than mere instructions to implement an abstract an idea on or using a computer, and only generally links the use of a judicial exception to a particular technological environment or field of use (i.e., computing), which does not serve to impose meaningful limits on the scope of the claim.
Further, “transmit[ting] the e-prescription to a pharmacy” and “record the transmission”, amount to no more than mere instructions to implement an abstract an idea on or using a computer, and only generally links the use of a judicial exception to a particular technological environment or field of use (i.e., computing), and amounts to insignificant extra-solution activity, as sending/transmitting/storing the result of the abstract idea (the prescription with medication) does not serve to impose meaningful limits on the abstract idea.
Per MPEP 2106.05(d), the courts have recognized the following computer functions as well-understood, routine and conventional functions when they are claimed in a merely generic manner (e.g., at a high level of generality) or as insignificant extra-solution activity:
Receiving or transmitting data over a network, e.g., using the Internet to gather data, Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information); TLI Communications LLC v. AV Auto. LLC, 823 F.3d 607, 610, 118 USPQ2d 1744, 1745 (Fed. Cir. 2016) (using a telephone for image transmission); OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1093 (Fed. Cir. 2015) (sending messages over a network); buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014) (computer receives and sends information over a network); but see DDR Holdings, LLC v. Hotels.com, L.P., 773 F.3d 1245, 1258, 113 USPQ2d 1097, 1106 (Fed. Cir. 2014) (“Unlike the claims in Ultramercial, the claims at issue here specify how interactions with the Internet are manipulated to yield a desired result‐‐a result that overrides the routine and conventional sequence of events ordinarily triggered by the click of a hyperlink.” (emphasis added));
iii. Electronic recordkeeping, Alice Corp. Pty. Ltd. v. CLS Bank Int'l, 573 U.S. 208, 225, 110 USPQ2d 1984 (2014) (creating and maintaining “shadow accounts”); Ultramercial, 772 F.3d at 716, 112 USPQ2d at 1755 (updating an activity log);
iv. Storing and retrieving information in memory, Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334, 115 USPQ2d 1681, 1701 (Fed. Cir. 2015); OIP Techs., 788 F.3d at 1363, 115 USPQ2d at 1092-93;
Treating a patient by soliciting symptoms used to diagnose a condition and provide the patient with a prescription for medicine to be fulfilled at a pharmacy is not a problem rooted in technology and predates computers, the internet and artificial intelligence. This process is implemented in the claimed invention using various additional elements that are recited at a high level of generality and utilized in an “apply it” manner that do not serve to perform any functionality that was not capable of being done otherwise, and do not constitute any improvement to the functioning of the underlying computer or technology, improvement to the technical field, providing a particular treatment or prophylaxis or significantly more than the abstract idea.
Paragraphs 31-48 and 68-76 of the specification states the various embodiments that the processors, memory, input/output devices, data storage, interface and networks can take, the common use of APIs in computer operating systems and hardware devices that run software programs.
Neither the specification nor the claim contains any details on the AI chat-bot beyond the high level of generality of its purpose; there is no description of any mechanism or algorithm utilized by the AI chat-bot or conversation engine in how automated questions are transmitted, what questions are transmitted, how patient-input communications are received, how patient symptoms and medical information is evaluated using the stored clinical dataset of acute conditions. Further, there are no details on how the conversation engine identifies non-qualified or qualified conditions, high risk conditions, or generating a recommended medication upon identifying a qualified condition. Similarly, there are no details on any mechanism or algorithm utilized by the comparator to compare patient symptoms and patient medical information to enable the determination of a medication. There are no details on any mechanism or algorithm utilized by the prescription generation module to associated medication with the patient or in generating an e-prescription, formatting the e-prescription for electronic prescribing and being digitally signed. There are no details on any mechanism or algorithm utilized by the communication module to securely transmit an e-prescription to a pharmacy or recording the transmission, or the location module to determine patient location and provide a list of pharmacies within a predefined radius, or how the payment processing module processes patient payment and generates an invoice. It is not evident from the claims how any improvements to telehealth e-prescribing workflows and computer functionalities are realized.
Thus, their involvement mostly amounts to no more than a recitation of the words “apply it” (or an equivalent), such as mere instructions to implement an abstract idea on a computer and only serves to generally link the use of a judicial exception to a particular technological environment or field of use (i.e., computers), which does not impose meaningful limits on the scope of the claim or the abstract idea, per MPEP 2106.05(f). The recitation of claim limitations that attempt to cover any solution to an identified problem with no restriction on how the result is accomplished and no description of the mechanism for accomplishing the result, does not integrate a judicial exception into a practical application or provide significantly more because this type of recitation is equivalent to the words “apply it”. See Electric Power Group, LLC v. Alstom, S.A., 830 F.3d 1350, 1356, 119 USPQ2d 1739, 1743-44 (Fed. Cir. 2016); Intellectual Ventures I v. Symantec, 838 F.3d 1307, 1327, 120 USPQ2d 1353, 1366 (Fed. Cir. 2016); Internet Patents Corp. v. Active Network, Inc., 790 F.3d 1343, 1348, 115 USPQ2d 1414, 1417 (Fed. Cir. 2015). In contrast, claiming a particular solution to a problem or a particular way to achieve a desired outcome may integrate the judicial exception into a practical application or provide significantly more. See Electric Power, 830 F.3d at 1356, 119 USPQ2d at 1743.
By way of example, in Intellectual Ventures I v. Capital One Fin. Corp., 850 F.3d 1332, 121 USPQ2d 1940 (Fed. Cir. 2017), the steps in the claims described “the creation of a dynamic document based upon ‘management record types’ and ‘primary record types.’” 850 F.3d at 1339-40; 121 USPQ2d at 1945-46. The claims were found to be directed to the abstract idea of “collecting, displaying, and manipulating data.” 850 F.3d at 1340; 121 USPQ2d at 1946. In addition to the abstract idea, the claims also recited the additional element of modifying the underlying XML document in response to modifications made in the dynamic document. 850 F.3d at 1342; 121 USPQ2d at 1947-48. Although the claims purported to modify the underlying XML document in response to modifications made in the dynamic document, nothing in the claims indicated what specific steps were undertaken other than merely using the abstract idea in the context of XML documents. The court thus held the claims ineligible, because the additional limitations provided only a result-oriented solution and lacked details as to how the computer performed the modifications, which was equivalent to the words “apply it”. 850 F.3d at 1341-42; 121 USPQ2d at 1947-48 (citing Electric Power Group., 830 F.3d at 1356, 1356, USPQ2d at 1743-44 (cautioning against claims “so result focused, so functional, as to effectively cover any solution to an identified problem”)).
Use of a computer or other machinery in its ordinary capacity for economic or other tasks (e.g., to receive, store, or transmit data) or simply adding a general purpose computer or computer components after the fact to an abstract idea (e.g., a fundamental economic practice or mathematical equation) does not integrate a judicial exception into a practical application or provide significantly more. See Affinity Labs v. DirecTV, 838 F.3d 1253, 1262, 120 USPQ2d 1201, 1207 (Fed. Cir. 2016) (cellular telephone); TLI Communications LLC v. AV Auto, LLC, 823 F.3d 607, 613, 118 USPQ2d 1744, 1748 (Fed. Cir. 2016) (computer server and telephone unit). Similarly, “claiming the improved speed or efficiency inherent with applying the abstract idea on a computer” does not integrate a judicial exception into a practical application or provide an inventive concept. Intellectual Ventures I LLC v. Capital One Bank (USA), 792 F.3d 1363, 1367, 115 USPQ2d 1636, 1639 (Fed. Cir. 2015).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Greene (US PG Pub 20120310661)
Greene (US PG Pub 20080033751)
Clements (US PG Pub 20050216310)
Any inquiry concerning this communication or earlier communications from the examiner should be directed to PETER H CHOI whose telephone number is (469)295-9171. The examiner can normally be reached M-F 9am-7pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/PETER H CHOI/Supervisory Patent Examiner, Art Unit 3681