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 .
Notice to Applicant
This communication is in response to the amendment filed 2/23/26. Claims 1-8, 10-13, and 17-20 have been amended. Claims 21-23 are newly added. Claims 1-23 are pending.
Election/Restrictions
Newly submitted claim 23 is directed to an invention that lacks unity with the invention originally claimed for the following reasons:
REQUIREMENT FOR UNITY OF INVENTION
As provided in 37 CFR 1.475(a), a national stage application shall relate to one invention only or to a group of inventions so linked as to form a single general inventive concept (“requirement of unity of invention”). Where a group of inventions is claimed in a national stage application, the requirement of unity of invention shall be fulfilled only when there is a technical relationship among those inventions involving one or more of the same or corresponding special technical features. The expression “special technical features” shall mean those technical features that define a contribution which each of the claimed inventions, considered as a whole, makes over the prior art.
The determination whether a group of inventions is so linked as to form a single general inventive concept shall be made without regard to whether the inventions are claimed in separate claims or as alternatives within a single claim. See 37 CFR 1.475(e).
When Claims Are Directed to Multiple Categories of Inventions:
As provided in 37 CFR 1.475 (b), a national stage application containing claims to different categories of invention will be considered to have unity of invention if the claims are drawn only to one of the following combinations of categories:
(1) A product and a process specially adapted for the manufacture of said product; or
(2) A product and a process of use of said product; or
(3) A product, a process specially adapted for the manufacture of the said product, and a use of the said product; or
(4) A process and an apparatus or means specifically designed for carrying out the said process; or
(5) A product, a process specially adapted for the manufacture of the said product, and an apparatus or means specifically designed for carrying out the said process.
Otherwise, unity of invention might not be present. See 37 CFR 1.475 (c).
Restriction is required under 35 U.S.C. 121 and 372.
This application contains the following inventions or groups of inventions which are not so linked as to form a single general inventive concept under PCT Rule 13.1.
Group I, claim(s) 1-22, drawn to a system comprising a container, a code database, a computer, first software, a healthcare device, and second software to receive confirmation that the patient took the medication and determine a potential adjustment for a future dose.
Group II, claim(s) 23, drawn to a method comprising storing an expected dose schedule, determining whether data has been received, classifying the expected dose, causing a contact to be initiated, automatically tagging a verification video, queuing videos, storing the video, causing a congratulatory communication to be provided to the patient, receiving a descriptor of an issue, prompting a provider to define a new medication regimen, and updating the prescription information.
The groups of inventions listed above do not relate to a single general inventive concept under PCT Rule 13.1 because, under PCT Rule 13.2, they lack the same or corresponding special technical features for the following reasons:
Groups I and II lack unity of invention because the groups do not share the same or corresponding technical feature.
Since applicant has received an action on the merits for the originally presented invention, this invention has been constructively elected by original presentation for prosecution on the merits. Accordingly, claim 23 is withdrawn from consideration as being directed to a nonelected invention. See 37 CFR 1.142(b) and MPEP § 821.03.
To preserve a right to petition, the reply to this action must distinctly and specifically point out supposed errors in the restriction requirement. Otherwise, the election shall be treated as a final election without traverse. Traversal must be timely. Failure to timely traverse the requirement will result in the loss of right to petition under 37 CFR 1.144. If claims are subsequently added, applicant must indicate which of the subsequently added claims are readable upon the elected invention.
Should applicant traverse on the ground that the inventions are not patentably distinct, applicant should submit evidence or identify such evidence now of record showing the inventions to be obvious variants or clearly admit on the record that this is the case. In either instance, if the examiner finds one of the inventions unpatentable over the prior art, the evidence or admission may be used in a rejection under 35 U.S.C. 103 or pre-AIA 35 U.S.C. 103(a) of the other invention.
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-22 are rejected under 35 U.S.C. §101 because the claimed invention is directed to an abstract idea without significantly more.
Step 1:
Claims 1-22 are directed to a system (i.e., a machine). Accordingly, claims 1-22 are all within at least one of the four statutory categories.
Step 2A - Prong One:
Regarding Prong One of Step 2A, the claim limitations are to be analyzed to determine whether, under their broadest reasonable interpretation, they “recite” a judicial exception or in other words whether a judicial exception is “set forth” or “described” in the claims. An “abstract idea” judicial exception is subject matter that falls within at least one of the following groupings: a) certain methods of organizing human activity, b) mental processes, and/or c) mathematical concepts.
Representative independent claim 1 includes limitations that recite at least one abstract idea. Specifically, independent claim 1 recites:
1. A system for tracking medication compliance, comprising: a container storing medication therein and comprising a first printed code on an interior of the container, the first printed code being only accessible once the container is opened; a code database having stored codes stored in the code database, the code database being configured to associate the first printed code with the medication and a patient; a computer in data communication with the code database, the computer being configured to receive the first printed code from a patient device configured to capture the first printed code; first software configured to be executed on the computer, the software being further configured to, upon execution by a processor of the computer, cause the computer to confirm that the patient took the medication by comparing the first printed code received from the patient device with the stored codes stored in the code database; a healthcare device in data communication with the computer, the healthcare device being associated with at least one of: a healthcare provider or an organization having a healthcare role; and second software configured to be executed on the healthcare device, the software being further configured to, upon execution by a processor of the healthcare device, cause the healthcare device to: receive a confirmation that the patient took the medication from the computer; and determine a potential adjustment for a future dose of the medication for the patient based on the confirmation.
The Examiner submits that the foregoing underlined limitations constitute “a mental process” because tracking medication compliance; associate the first printed code with the medication and a patient; receive the first printed code; confirm that the patient took the medication by comparing the first printed code received with the codes; receive a confirmation that the patient took the medication; and determine a potential adjustment for a future dose of the medication for the patient based on the confirmation amount to observations/evaluations/judgments/analyses that can, at the currently claimed high level of generality, be practically performed in the human mind or via pen and paper.
Accordingly, the claim recites at least one abstract idea.
Step 2A - Prong Two:
Regarding Prong Two of Step 2A, it must be determined whether the claim as a whole integrates the abstract idea into a practical application. It must be determined whether any additional elements in the claim beyond the abstract idea integrate the exception into a practical application in a manner that imposes a meaningful limit on the judicial exception. The courts have indicated that additional elements merely using a computer to implement an abstract idea, adding insignificant extra solution activity, or generally linking use of a judicial exception to a particular technological environment or field of use do not integrate a judicial exception into a “practical application.”
The limitations of claim 1, as drafted, is a process that, under its broadest reasonable interpretation, covers performance of the limitations in the mind but for the recitation of generic computer components. That is, other than reciting a database, a computer, a processor, software, a patient device, and a healthcare device to perform the limitations, nothing in the claim elements precludes the steps from practically being performed in the mind. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic computer components, then it falls within the “Mental Processes” grouping of abstract ideas. Accordingly, the claims recite an abstract idea.
This judicial exception is not integrated into a practical application. In particular, the database, computer, processor, software, patient device, and healthcare device are recited at a high-level of generality (i.e., as generic computer components performing generic computer functions of storing data, associating data, receiving data, capturing data, comparing data, and determining data) such that it amounts no more than mere instructions to apply the exception using generic computer components. The claim also recites the additional element of a container comprising a printed code that is accessible. Such step would be routinely used by those of ordinary skill in the art and is a well-understood, routine and conventional activity specified at a high level of generality. It is mere data gathering in conjunction with the abstract idea and therefore adds insignificant extrasolution activity to the judicial exception. Accordingly, these additional elements do not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. The claims are directed to an abstract idea.
Thus, taken alone, the additional elements do not amount to significantly more than the above-identified judicial exception (the abstract idea). Looking at the limitations as an ordered combination adds nothing that is not already present when looking at the elements taken individually. For instance, there is no indication that the additional elements, when considered as a whole, reflect an improvement in the functioning of a computer or an improvement to another technology or technical field, apply or use the above-noted judicial exception to effect a particular treatment or prophylaxis for a disease or medical condition, implement/use the above-noted judicial exception with a particular machine or manufacture that is integral to the claim, effect a transformation or reduction of a particular article to a different state or thing, or apply or use the judicial exception in some other meaningful way beyond generally linking the use of the judicial exception to a particular technological environment, such that the claim as a whole is not more than a drafting effort designed to monopolize the exception (see MPEP § 2106.05). Their collective functions merely provide conventional computer implementation.
Claims 2-20 are ultimately dependent from Claim(s) 1 and include all the limitations of Claim(s) 1. Therefore, claim(s) 2-20 recite the same abstract idea. Claims 2-20 describe further limitations regarding wherein the code is transmitted via SMS; wherein the container comprises a packet and the code is printed on an inside of the packet; wherein the code is associated with a time for the patient to take the medication; only confirming that the patient took the medication when receives the code near the time for the patient to take the medication; receiving a medical status; determining a potential adjustment for the future dose of the medication for the patient based on the medical status; wherein the medical status of the patient comprises a self-report about one or more of: pain, fatigue, discomfort, or symptoms; wherein the medical status of the patient comprises one or more of: test results, bloodwork results, or healthcare provider notes; wherein the medical status is generated by a wearable device; anonymizing the medical status for use in making future adjustments to prescriptions; using machine learning; generating a reward based on the confirmation; transmitting the potential adjustment; generate a new prescription for the patient; wherein the new prescription is sent for fulfillment; wherein the healthcare device is associated with a clinical study; wherein the healthcare device is associated with a health insurance company; a camera configured to scan the code; a camera configured to take video of the patient administering the medication; receiving the video of the patient taking the medication; confirm whether the patient took the medication; the container comprises a second code on an outside of the container, the patient is required to break the second code to access the first code; associating the second code with the medication and the patient; receiving the second code confirming that the patient took the medication by comparing the second code received from the patient with codes; wherein the code is encrypted; determine a confidence level; prompt the patient to provide status information, anonymize and store patient data; and compare the anonymized patient data. The computer components in the dependent claims are recited at a high-level of generality (as generic computer components performing generic computer functions) such that it amounts to no more than mere instructions to apply the exception using generic computer components. These are all just further describing the abstract idea recited in claim 1 or the abstract idea of “certain methods of organizing human activity,” without adding significantly more.
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements amount to no more than mere instructions to apply the exception using generic computer components. Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept. The claims are not patent eligible.
Step 2B:
Regarding Step 2B, independent claim 1 does not include additional elements (considered both individually and as an ordered combination) that are sufficient to amount to significantly more than the judicial exception for reasons the same as those discussed above with respect to determining that the claim does not integrate the abstract idea into a practical application.
Regarding the additional limitations directed to a database having stored codes, a computer in data communication with the database; the computer being configured to receive the code from a patient device, and a healthcare device in data communication with the computer, all of which the Examiner submits merely add insignificant extra-solution activity to the abstract idea or are claimed in a merely generic manner (e.g., at a high level of generality), the Examiner further submits that such steps are not unconventional as they merely consist of storing and retrieving information in memory and receiving and transmitting data over a network. See MPEP 2106.05(d)(II).
The dependent claims do not include additional elements (considered both individually and as an ordered combination) that are sufficient to amount to significantly more than the judicial exception for the same reasons to those discussed above with respect to determining that the dependent claims do not integrate the at least one abstract idea into a practical application.
Therefore, claims 1-22 are ineligible under 35 USC §101.
Claim Objections
Claim 11 is objected to because of the following informalities: change “the a potential adjustment” to “the potential adjustment.” Appropriate correction is required.
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.
Claim(s) 1 and 3-6 is/are rejected under 35 U.S.C. 103 as being unpatentable over Lazar (US 2011/0119090 A1) in view of Hopen (US 2021/0065863 A1), and further in view of Sandhu (US 10,512,592 B1).
(A) Referring to claim 1, Lazar discloses A system for tracking medication compliance, comprising (para. 18 & 32 of Lazar; FIG. 1 is a diagrammatic perspective view of the smart cap of an embodiment of the present invention for a container to dispense a medication and for automatically (a) self-verifying the medication once the smart cap has been automatically programmed for the medication so as to prevent improper dispensing of the medication, (b) indicating and verifying the number of pills in the container, (c) indicating and verifying via timely (daily/weekly/monthly) compliance for medication as prescribed; and (d) communicating instructions and/or cautions to patients.):
a container storing medication therein and comprising a first printed code (see Fig. 1 and para. 19 & 47 of Lazar; The cap is configured to accommodate use of bar codes and/or other indicia);
a code database having stored codes stored in the code database, the code database being configured to associate the first printed code with the medication and a patient (para. 19, 27, 28, 30, and 52-54 of Lazar; The cap is provided with a recognition element such as an optical scanner configured with at least one locally contained or external data base having general medication identification data and optionally patient-specific information to scan and identify the medication (and optionally the dosage, specific formulations, manufacturing source, etc.) and to record and correlate information regarding patient medication usage (scanning of a medication is generally considered indicative of actual patient taking of the medication). The cap further comprises communication elements configured to transmit "usage" through scanning of a unit dosage of the medication, to an external data base such as the patient's cell phone and or computer (such as with blue tooth or RF communication). The consumer or patient is optionally provided with a detailed summary (such as a print out) of all prescribed medications from the data base with duplicate medications or those with adverse interactions being flagged. Alternatively, the smart cap communicates the information regarding duplication and/or adverse interactions to a pharmacy providing one of the medications or to a prescribing physician for contacting the patient or consumer.);
a computer in data communication with the code database (see Fig. 3 and para. 51-54 of Lazar; The identity of the medication is determined and a patient identifying code is generated from circuit 16 when a pill 14 is removed from the container 12 and scanned. The smart cap 10 (programmed to effect transmission) sends a signal of patient use of medication via the transmitter 110 to a proximate phone 120 by bluetooth transmission 400 and telephone communication 300 directly to a pharmacy or physician/healthcare provider. Alternatively the transmitter 110 sends the signal by WiFi transmission 130 to a computer 135 for interne transmission 200 or direct (e.g. 3G and the like) transmission 200 via the internet to an e-mail or similar site of a pharmacy site 150 and/or physician site 160 whereby the usage is recorded with patient and medication identity and stamped with a time and date into a configured data base. The patient file data base 160a maintained by the treating physician is preprogrammed to generate an alarm if patient usage deviates significantly from the prescription data. As shown, the transmission is to any or all of the pharmacy database 150, a physician (or other health care provider) patient file data base 160, or to a data base 170 maintained by the patient or caretaker (keeping track of patient usage of a medication) on a smart phone 120 or local computer 135.), the computer being configured to receive the first printed code from a patient device configured to capture the first printed code (para. 22 & 51-54 of Lazar; The identity of the medication is determined and a patient identifying code is generated from circuit 16 when a pill 14 is removed from the container 12 and scanned. The smart cap 10 (programmed to effect transmission) sends a signal of patient use of medication via the transmitter 110 to a proximate phone 120 by bluetooth transmission 400 and telephone communication 300 directly to a pharmacy or physician/healthcare provider. Alternatively the transmitter 110 sends the signal by WiFi transmission 130 to a computer 135 for interne transmission 200 or direct (e.g. 3G and the like) transmission 200 via the internet to an e-mail or similar site of a pharmacy site 150 and/or physician site 160 whereby the usage is recorded with patient and medication identity and stamped with a time and date into a configured data base. The transmission is to any or all of the pharmacy database 150, a physician (or other health care provider) patient file data base 160, or to a data base 170 maintained by the patient or caretaker (keeping track of patient usage of a medication) on a smart phone 120 or local computer 135. As described, the patient can print out usage, medication information and the like to safeguard against excessive medication usage or incomplete compliance and the like.);
first software configured to be executed on the computer, the software being further configured to, upon execution by a processor of the computer, cause the computer to confirm that the patient took the medication by comparing the first printed code received from the patient device with the stored codes stored in the code database (para. 18, 22, 28, & 51-54 of Lazar; a smart cap for a container to dispense a medication and for automatically (a) self-verifying at least two (2) sides of the medication once the smart cap has been programmed for visually identifying the medication so as to prevent improper dispensing thereof, (b) indicating and verifying the number of pills in the container, (c) indicating and verifying timely, (for example daily/weekly/monthly) compliance for taking of the medication as prescribed, (d) communicating instructions and/or cautions to patients in a language(s) or vernacular(s) understandable to the patients, (e) verifying some or all of the foregoing by means of bar codes or other identifiers and/or communicating patient usage (or evidencing non-usage and non compliance) of a medication and ensuring a constantly available supply. The cap is provided with a recognition element such as an optical scanner configured with at least one locally contained or external data base having general medication identification data and optionally patient-specific information to scan and identify the medication (and optionally the dosage, specific formulations, manufacturing source, etc.) and to record and correlate information regarding patient medication usage (scanning of a medication is generally considered indicative of actual patient taking of the medication).);
a healthcare device in data communication with the computer, the healthcare device being associated with at least one of: a healthcare provider or an organization having a healthcare role (see Fig. 3 and para. 51-55 of Lazar; the smart cap 10 further includes a communication element 110 which receives scanned medication information from circuit 16. In this embodiment the medication or pill 14 is placed on smart cap 10 into cavity 53 for programmed wireless transmitter 110 to wirelessly transmit a usage signal of the medication. The patient file data base 160a maintained by the treating physician is preprogrammed to generate an alarm if patient usage deviates significantly from the prescription data. As shown, the transmission is to any or all of the pharmacy database 150, a physician (or other health care provider) patient file data base 160, or to a data base 170 maintained by the patient or caretaker (keeping track of patient usage of a medication) on a smart phone 120 or local computer 135. The transmitter 110 may also be provided with a receiver function whereby outside sources such as the pharmacy, physician or even the FDA or other relevant agency can submit signals (shown as outside source 500) regarding the status of the medication, the need for renewal or warnings against medication usage (too much) or non compliance.); and
second software configured to be executed on the healthcare device (para. 22, 28, & 51-55 of Lazar; The patient file data base 160a maintained by the treating physician is preprogrammed to generate an alarm if patient usage deviates significantly from the prescription data. As shown, the transmission is to any or all of the pharmacy database 150, a physician (or other health care provider) patient file data base 160, or to a data base 170 maintained by the patient or caretaker (keeping track of patient usage of a medication) on a smart phone 120 or local computer 135. The transmitter 110 may also be provided with a receiver function whereby outside sources such as the pharmacy, physician or even the FDA or other relevant agency can submit signals (shown as outside source 500) regarding the status of the medication, the need for renewal or warnings against medication usage (too much) or non compliance.).
Lazar does not disclose a container storing medication therein and comprising a first printed code on an interior of the container, the first printed code being only accessible once the container is opened; the software being further configured to, upon execution by a processor of the healthcare device, cause the healthcare device to: receive a confirmation that the patient took the medication from the computer; and determine a potential adjustment for a future dose of the medication for the patient based on the confirmation.
Hopen discloses a container storing medication therein and comprising a first printed code on an interior of the container, the first printed code being only accessible once the container is opened (see Fig. 4, abstract, and para. 32 of Hopen; shown in FIG. 4, QR Code 110 is affixed to cap interior surface 40. Accordingly, the label otherwise obscured or occluded when cap 20 is threaded onto the bottle 10. Therefore, to operate the invention, the patient must remove cap 20 from bottle 10 thereby making medicine readably accessible.).
Sandhu discloses the software being further configured to, upon execution by a processor of the healthcare device, cause the healthcare device to: receive a confirmation that the patient took the medication from the computer; and determine a potential adjustment for a future dose of the medication for the patient based on the confirmation (col. 10, lines 42-67 of Sandhu; The tamper proof medication dispenser can be equipped with wide angle camera to record pictures and video of the patient taking the medications for further review of medication usage. The camera is activated for a short fixed amount of time when the medication is being sucked from the port via a light sensor located at the tip of the port and will record pictures or video of patient actually ingesting the medications to prevent further misuse by diversion. Motion sensors and float switch information can also be used to activate the camera. The tamper resistant medication dispenser can also incorporate a smart phone ecu with cellular service to record and monitor medication usage by uploading pictures and video to central server where such pictures and video can be reviewed and also to allow for remote reprogramming of the medication dosing interval but only within fixed medically safe predefined parameters (to prevent overdose risk) such as if the patient has significant exacerbation of pain such as after sustaining a fall or injury and higher dosage of medication is needed and is approved by the prescribing physician with the dosing interval being changed remotely. This can also be used to allow for remote activation of the medication deactivation mechanism in the event of misuse or abuse noted upon review of recorded pictures or video from the medication dispenser or change in patient medical condition as determined by the prescribing physician.).
Before the effective filing date of the claimed invention, it would have been obvious to a person of ordinary skill in the art to modify the container of Lazar to include the aforementioned features of Hopen and to combine the aforementioned features of Sandhu within Lazar and Hopen. The motivation for doing so would have been to provide a simple, inexpensive way to validate and monitor a patient's compliance to a dosage schedule and full completion of a course of prescribed medication (para. 5 of Hopen) and to allow for remote reprogramming of the medication dosing interval but only within fixed medically safe predefined parameters (col. 10, lines 42-67 of Sandhu).
(B) Referring to claim 3, Lazar does not disclose wherein the container further comprises a packet and the first printed code is printed on an inside of the packet.
Hopen discloses wherein the container further comprises a packet and the first printed code is printed on an inside of the packet (abstract and para. 7 & 32 of Hopen).
Before the effective filing date of the claimed invention, it would have been obvious to a person of ordinary skill in the art to modify the container of Lazar to include the aforementioned features of Hopen. The motivation for doing so would have been to provide a simple, inexpensive way to validate and monitor a patient's compliance to a dosage schedule and full completion of a course of prescribed medication (para. 5 of Hopen).
(C) Referring to claim 4, Lazar discloses wherein the first printed code is associated with a time for the patient to take the medication (para. 18, 19, 21, and 52 of Lazar).
(D) Referring to claim 5, Lazar discloses wherein the first software configured to be executed on the computer is further configured to cause the computer to only confirm that the patient took the medication when the computer receives the first printed code near the time for the patient to take the medication (para. 18, 19, and 52 of Lazar).
(E) Referring to claim 6, Lazar discloses wherein: the healthcare device is configured to receive a medical status; and the second software configured to be executed.
Claim(s) 2, 17, and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Lazar (US 2011/0119090 A1) in view of Hopen (US 2021/0065863 A1), in view of Sandhu (US 10,512,592 B1), and further in view of Wilz, SR. et al. (US 2016/0314276 A1).
(A) Referring to claim 2, Lazar, Hopen, and Sandhu do not disclose wherein the first printed code is transmitted by the patient device to the computer via Short Message Service (SMS).
Wilz discloses wherein the first printed code is transmitted by the patient device to the computer via Short Message Service (SMS) (para. 37 of Wilz).
Before the effective filing date of the claimed invention, it would have been obvious to a person of ordinary skill in the art to combine the aforementioned feature of Wilz within Lazar, Hopen, and Sandhu. The motivation for doing so would have been to download information automatically (para. 37 of Wilz).
(B) Referring to claim 17, Lazar, Hopen, and Sandhu do not expressly disclose wherein the patient device comprises a camera configured to scan the first printed code.
Wilz discloses wherein the patient device comprises a camera configured to scan the first printed code (para. 49 & 50 Wilz)
Before the effective filing date of the claimed invention, it would have been obvious to a person of ordinary skill in the art to combine the aforementioned feature of Wilz within Lazar, Hopen, and Sandhu. The motivation for doing so would have been to derive or retrieve information (para. 49 of Wilz).
(C) Referring to claim 19, Lazar discloses wherein: the code database is configured to associate the second printed code with the medication and the patient; the computer is configured to receive the second printed code from the patient device; and the first software configured to be executed on the computer is further configured to cause the computer to confirm that the patient took the medication by comparing the second printed code received from the patient with the stored codes in the code database (para. 19, 22, 28, 54, and 57 of Lazar).
Lazar does not disclose wherein: the container further comprises a second printed code on an outside of the container; the patient is required to break the second printed code to access the first printed code.
Hopen discloses the container further comprises a second printed code, the patient is required to break the second printed code to access the first printed code (para. 32 of Hopen).
Hopen and Sandhu also do not disclose the container further comprises a printed code on an outside of the container.
Wilz discloses the container further comprises a printed code on an outside of the container (Fig. 3 and para. 37 of Wilz).
Before the effective filing date of the claimed invention, it would have been obvious to a person of ordinary skill in the art to combine the aforementioned features of Hopen and Wilz within Lazar and Sandhu. The motivation for doing so would have been to verify that all medicine has been consumed by the patient (para. 32 of Hopen) and to directly identify the medication (para. 37 of Wilz).
Claim(s) 10 and 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Lazar (US 2011/0119090 A1) in view of Hopen (US 2021/0065863 A1), in view of Sandhu (US 10,512,592 B1), and further in view of Hanina et al. (US 2013/0169781 A1).
(A) Referring to claim 10, Lazar, Hopen, and Sandhu do not disclose wherein the second software configured to be executed on the healthcare device is further configured to cause the healthcare device to anonymize the medical status for storage in a second database for use in making future adjustments to prescriptions.
Hanina discloses wherein the second software configured to be executed on the healthcare device is further configured to cause the healthcare device to anonymize the medical status for storage in a second database for use in making future adjustments to prescriptions (para. 24, 25, 29, and 31-33 of Hanina).
Before the effective filing date of the claimed invention, it would have been obvious to a person of ordinary skill in the art to combine the aforementioned features of Hanina within Lazar, Hopen, and Sandhu. The motivation for doing so would have been to maintain the privacy of the patent identity and any other confidential or private patient information (para. 40 of Hanina).
(B) Referring to claim 18, Lazar, Hopen, and Sandhu do not disclose wherein: the patient device comprises a camera configured to take video of the patient administering the medication; the computer is further configured to receive the video of the patient taking the medication; and the first software configured to be executed on the computer is further configured to cause the computer to use machine vision to confirm whether the patient took the medication.
Hanina discloses wherein: the patient device comprises a camera configured to take video of the patient administering the medication; the computer is further configured to receive the video of the patient taking the medication; and the first software configured to be executed on the computer is further configured to cause the computer to use machine vision to confirm whether the patient took the medication (para. 13, 28, 32, 36, and 45 of Hanina).
Before the effective filing date of the claimed invention, it would have been obvious to a person of ordinary skill in the art to combine the aforementioned features of Hanina within Lazar, Hopen, and Sandhu. The motivation for doing so would have been to confirm proper medication administration (para. 38 of Hanina).
Claim(s) 7-9, 11, and 13-16 is/are rejected under 35 U.S.C. 103 as being unpatentable over Lazar (US 2011/0119090 A1) in view of Hopen (US 2021/0065863 A1), in view of Sandhu (US 10,512,592 B1), and further in view of Cooney et al. (US 2018/0365385 A1).
(A) Referring to claim 7, Lazar, Hopen, and Sandhu do not disclose wherein the medical status of the patient comprises a self-report about one or more of: pain, fatigue, discomfort or symptoms.
Cooney discloses wherein the medical status of the patient comprises a self-report about one or more of: pain, fatigue, discomfort or symptoms (para. 39-41 of Cooney).
Before the effective filing date of the claimed invention, it would have been obvious to a person of ordinary skill in the art to combine the aforementioned feature of Cooney within Lazar, Hopen, and Sandhu. The motivation for doing so would have been to determine a patient's reaction to the medication (para. 40 of Cooney).
(B) Referring to claim 8, Lazar, Hopen, and Sandhu do not disclose wherein the medical status of the patient comprises one or more of: test results, bloodwork results, or healthcare provider notes.
Cooney discloses wherein the medical status of the patient comprises one or more of: test results, bloodwork results, or healthcare provider notes (para. 44 of Cooney).
Before the effective filing date of the claimed invention, it would have been obvious to a person of ordinary skill in the art to combine the aforementioned feature of Cooney within Lazar, Hopen, and Sandhu. The motivation for doing so would have been to continuously capture physiological information about the patient (para. 42 of Cooney).
(C) Referring to claim 9, Lazar, Hopen, and Sandhu do not disclose wherein the medical status is generated by a wearable device in data communication with the patient device.
Cooney discloses wherein the medical status is generated by a wearable device in data communication with the patient device (para. 16 & 36 of Cooney).
Before the effective filing date of the claimed invention, it would have been obvious to a person of ordinary skill in the art to combine the aforementioned feature of Cooney within Lazar, Hopen, and Sandhu. The motivation for doing so would have been to obtain feedback information regarding a patient's reaction to a medication (para. 16 of Cooney).
(D) Referring to claim 11, Lazar, Hopen, and Sandhu do not disclose wherein the second software is further configured to cause the healthcare device to determine the a potential adjustment using machine learning.
Cooney discloses wherein the second software is further configured to cause the healthcare device to determine the a potential adjustment using machine learning (para. 76-78 of Cooney).
Before the effective filing date of the claimed invention, it would have been obvious to a person of ordinary skill in the art to combine the aforementioned feature of Cooney within Lazar, Hopen, and Sandhu. The motivation for doing so would have been to identify patterns in the historical reaction information (para. 76 of Cooney).
(E) Referring to claim 13, Lazar, Hopen, and Sandhu do not disclose wherein: the healthcare device is configured to transmit the potential adjustment to a device associated with a prescribing doctor of the patient; and the device associated with the prescribing doctor of the patient is configured to generate a new prescription for the patient.
Cooney discloses wherein: the healthcare device is configured to transmit the potential adjustment to a device associated with a prescribing doctor of the patient; and the device associated with the prescribing doctor of the patient is configured to generate a new prescription for the patient (para. 22, 71, and 124 of Cooney).
Before the effective filing date of the claimed invention, it would have been obvious to a person of ordinary skill in the art to combine the aforementioned feature of Cooney within Lazar, Hopen, and Sandhu. The motivation for doing so would have been to provide a response associated with a particular reaction, reaction value, and/or pattern in the reaction information (para. 71 of Cooney).
(F) Referring to claim 14, Lazar, Hopen, and Sandhu do not disclose wherein the new prescription is sent to the computer for fulfillment.
Cooney discloses wherein the new prescription is sent to the computer for fulfillment (para. 99 and 71 of Cooney).
Before the effective filing date of the claimed invention, it would have been obvious to a person of ordinary skill in the art to combine the aforementioned feature of Cooney within Lazar, Hopen, and Sandhu. The motivation for doing so would have been to automatically update the patient's records to reflect the patient's changes to his or her prescriptions (para. 71 of Cooney).
(G) Referring to claim 15, Lazar, Hopen, and Sandhu do not disclose wherein the healthcare device is associated with a clinical study.
Cooney discloses wherein the healthcare device is associated with a clinical study (para. 76 of Cooney).
Before the effective filing date of the claimed invention, it would have been obvious to a person of ordinary skill in the art to combine the aforementioned feature of Cooney within Lazar, Hopen, and Sandhu. The motivation for doing so would have been to identify side effects of the medication and efficacy (para. 76 of Cooney).
(H) Referring to claim 16, Lazar, Hopen, and Sandhu do not disclose wherein the healthcare device is associated with a health insurance company.
Cooney discloses wherein the healthcare device is associated with a health insurance company (para. 53 of Cooney).
Before the effective filing date of the claimed invention, it would have been obvious to a person of ordinary skill in the art to combine the aforementioned feature of Cooney within Lazar, Hopen, and Sandhu. The motivation for doing so would have been to allow authorized users to access and review various information about the patient (para. 53 of Cooney).
Claim(s) 12 is/are rejected under 35 U.S.C. 103 as being unpatentable over Lazar (US 2011/0119090 A1) in view of Hopen (US 2021/0065863 A1), in view of Sandhu (US 10,512,592 B1), and further in view of Amoyal et al. (US 2022/0028515 A1).
(A) Referring to claim 12, Lazar, Hopen, and Sandhu do not disclose wherein: the healthcare device is configured to generate a reward based on the confirmation; and the patient device is configured to receive the reward.
Amoyal discloses wherein: the healthcare device is configured to generate a reward based on the confirmation; and the patient device is configured to receive the reward (para. 18 & 19 of Amoyal).
Before the effective filing date of the claimed invention, it would have been obvious to a person of ordinary skill in the art to combine the aforementioned feature of Amoyal within Lazar, Hopen, and Sandhu. The motivation for doing so would have been to encourage patients (para. 4 of Amoyal).
Claim(s) 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Lazar (US 2011/0119090 A1) in view of Hopen (US 2021/0065863 A1), in view of Sandhu (US 10,512,592 B1), and further in view of Kraft (US 2012/0041778 A1).
(A) Referring to claim 20, Lazar, Hopen, and Sandhu do not disclose wherein the first printed code is encrypted.
Kraft discloses wherein the first printed code is encrypted (para. 83 of Kraft).
Before the effective filing date of the claimed invention, it would have been obvious to a person of ordinary skill in the art to combine the aforementioned feature of Kraft within Lazar, Hopen, and Sandhu. The motivation for doing so would have been to ensure patient privacy (para. 83 of Kraft).
Claim(s) 21 is/are rejected under 35 U.S.C. 103 as being unpatentable over Lazar (US 2011/0119090 A1) in view of Hopen (US 2021/0065863 A1), in view of Sandhu (US 10,512,592 B1), and further in view of Geman (US 2016/0106627 A1).
(A) Referring to claim 21, Lazar, Hopen, and Sandhu do not disclose wherein the first software is further configured to: determine a confidence level that the patient successfully took the medication based on at least one of the first code and a verification video of the patient administering the medication; and in response to the confidence level being below a threshold, cause the patient device to prompt the patient to provide status information explaining a perceived lack of compliance.
Geman discloses wherein the first software is further configured to: determine a confidence level that the patient successfully took the medication based on at least one of the first code and a verification video of the patient administering the medication; and in response to the confidence level being below a threshold, cause the patient device to prompt the patient to provide status information explaining a perceived lack of compliance (para. 7-9, 94, 76, 77 of Geman).
Before the effective filing date of the claimed invention, it would have been obvious to a person of ordinary skill in the art to combine the aforementioned features of Geman within Lazar, Hopen, and Sandhu. The motivation for doing so would have been to improve medication adherence (abstract of Geman).
Claim(s) 22 is/are rejected under 35 U.S.C. 103 as being unpatentable over Lazar (US 2011/0119090 A1) in view of Hopen (US 2021/0065863 A1), in view of Sandhu (US 10,512,592 B1), and further in view of Petak et al. (US 2016/0224760 A1).
(A) Referring to claim 22, Lazar, Hopen, and Sandhu do not disclose wherein the second software configured to be executed on the healthcare device is further configured to cause the healthcare device to: anonymize and store patient data corresponding to the patient in a healthcare database; and compare the anonymized patient data with anonymized data from other patients to generate suggested medications or dosages for the patient.
Petak discloses wherein the second software configured to be executed on the healthcare device is further configured to cause the healthcare device to: anonymize and store patient data corresponding to the patient in a healthcare database (para. 65 & 128 of Petak); and compare the anonymized patient data with anonymized data from other patients to generate suggested medications or dosages for the patient (para. 68, 128, 131-134, and 234 of Petak).
Before the effective filing date of the claimed invention, it would have been obvious to a person of ordinary skill in the art to combine the aforementioned features of Petak within Lazar, Hopen, and Sandhu. The motivation for doing so would have been to help medical decisions and research (para. 128 of Petak).
Response to Arguments
Applicant’s arguments with respect to claim(s) 1 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Applicant's additional arguments filed 2/23/26 have been fully considered but they are not persuasive. Applicant’s arguments will be addressed hereinbelow in the order in which they appear in the response filed 2/23/26.
(1) Applicant respectfully submits that the § 101 rejection of claims 1-20 should be withdrawn.
(2) Applicant argues that the applied references, whether considered alone or in combination, do not disclose or render obvious all of the features of amended independent claim 1.
(A) As per the first argument, see 101 rejection above. The Examiner submits that the foregoing underlined limitations in the 101 rejection above constitute “a mental process” because tracking medication compliance; associate the first printed code with the medication and a patient; receive the first printed code; confirm that the patient took the medication by comparing the first printed code received with the codes; receive a confirmation that the patient took the medication; and determine a potential adjustment for a future dose of the medication for the patient based on the confirmation amount to observations/evaluations/judgments/analyses that can, at the currently claimed high level of generality, be practically performed in the human mind or via pen and paper. Accordingly, the claim recites at least one abstract idea. This judicial exception is not integrated into a practical application. In particular, the database, computer, processor, software, patient device, and healthcare device are recited at a high-level of generality (i.e., as generic computer components performing generic computer functions of storing data, associating data, receiving data, capturing data, comparing data, and determining data) such that it amounts no more than mere instructions to apply the exception using generic computer components. The claim also recites the additional element of a container comprising a printed code that is accessible. Such step would be routinely used by those of ordinary skill in the art and is a well-understood, routine and conventional activity specified at a high level of generality. It is mere data gathering in conjunction with the abstract idea and therefore adds insignificant extrasolution activity to the judicial exception. Accordingly, these additional elements do not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. The limitations regarding “machine learning” or ”machine vision” in the dependent claims do not amount to more than a recitation of the words "apply it" (or an equivalent), such as mere instructions to implement an abstract idea on a computer.
(B) As per the second argument: In response to applicant's argument that a person of ordinary skill in the art would not be motivated to modify the smart cap of Lazar with a printed QR code in Hopen, the test for obviousness is not whether the features of a secondary reference may be bodily incorporated into the structure of the primary reference; nor is it that the claimed invention must be expressly suggested in any one or all of the references. Rather, the test is what the combined teachings of the references would have suggested to those of ordinary skill in the art. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981).
In response to applicant’s argument that there is no teaching, suggestion, or motivation to combine the references, the examiner recognizes that obviousness may be established by combining or modifying the teachings of the prior art to produce the claimed invention where there is some teaching, suggestion, or motivation to do so found either in the references themselves or in the knowledge generally available to one of ordinary skill in the art. See In re Fine, 837 F.2d 1071, 5 USPQ2d 1596 (Fed. Cir. 1988), In re Jones, 958 F.2d 347, 21 USPQ2d 1941 (Fed. Cir. 1992), and KSR International Co. v. Teleflex, Inc., 550 U.S. 398, 82 USPQ2d 1385 (2007). In this case, the motivation to combine came directly from the Hopen reference.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to LENA NAJARIAN whose telephone number is (571)272-7072. The examiner can normally be reached Monday - Friday 9:30 am-6 pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Mamon Obeid can be reached at (571)270-1813. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/LENA NAJARIAN/Primary Examiner, Art Unit 3687