DETAILED ACTION
Acknowledgements
This office action is in response to the claims filed December 24, 2024.
Claims 1-20 are pending.
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 .
Information Disclosure Statement(s)
Information disclosure statement dated 12/31/2024 is considered by examiner.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected to under 35 U.S.C 101 as not being directed to eligible subject matter based on the grounds set out in detail below:
Independent Claims 1, 12, and 20:
Eligibility Step 1 (does the subject matter fall within a statutory category?):
Independent claim 1 falls within the statutory category of method
Independent claim 12 falls within the statutory category of article of manufacture
Independent claim 20 falls within the statutory category of machine
Eligibility Step 2A-1 (does the claim recite an abstract idea, law of nature, or natural phenomenon?): Independent claims 1, 12, and 20 (claim 1 being representative) claimed invention is directed to an abstract idea without significantly more.
The claim elements which set forth the abstract idea in the independent claims (claim 1 being representative) is:
A method for remote patient monitoring
receiving, from a remote source, a healthcare plan assigned to a patient;
present healthcare information of the patient based on the healthcare plan;
receiving healthcare data regarding the patient based on the healthcare plan;
and sending the healthcare data to the remote source.
This abstract idea is “certain methods of organizing human activity” as it is following rules and instructions to gather, process, and present healthcare data for patient monitoring (MPEP § 2106.04(a)(2), subsection II)
Eligibility Step 2A-2 (does the claim recite additional elements that integrate the judicial exception into a practical application?): For Independent claims 1, 12, and 20 judicial exception is not integrated into a practical application.
In Claims 1, 12, and 20 the additional elements are:
a computer
a plug-in device
a separate media device
one or more healthcare monitoring devices
One or more non-transitory computer-readable media storing instructions that, when executed by one or more processors
A plug-in device comprising: a memory storing instructions; and a processing system coupled to the memory that executes the instructions
Examiner takes the applicable considerations stated in MPEP 2106.04 (d) and analyzes them below in light of the instant applications disclosure and claim elements as a whole.
The additional elements, (a), (d), and (e), are performing the abstract idea and stated as general purpose computer tools or equivalent to apply the abstract idea as “apply-it” (see [0129] of instant application specification)
The additional element, a plug-in device, is applied as “apply-it” as a tool or equivalent to gather and output data
The additional element, a separate media device, is applied as “apply-it” as a tool or equivalent to gather data
The additional element, one or more healthcare monitoring devices, is applied as “apply-it” as a tool or equivalent to gather data
Accordingly, claims 1, 12, and 20 do not integrate the abstract idea into a practical application.
Eligibility Step 2B (Does the claim amount to significantly more?): The independent claims do not include additional element which provide significantly more for the same reasons given in prong 2A-2 above. The claims are patent ineligible.
Dependent Claims 2-11 and 13-19:
Eligibility Step 1 (does the subject matter fall within a statutory category?):The dependent claims 2-11 fall within the statutory category of method. The dependent claims 13-19 fall within the statutory category of article of manufacture.
Eligibility Step 2A-1 (does the claim recite an abstract idea, law of nature, or natural phenomenon?): Dependent claims 2-11 and 13-19 claimed invention is directed to an abstract idea without significantly more. The claims continue to limit the independent claim 1 and 12 abstract idea by (1) further limiting the types of data monitored and collected in regards to the healthcare plan and (2) further limiting alerts and reminders. Therefore, the dependent claims inherit the same abstract idea which is This abstract idea is “certain methods of organizing human activity” as it is following rules and instructions to gather, process, and present healthcare data for patient monitoring (MPEP § 2106.04(a)(2), subsection II)
Eligibility Step 2A-2 (does the claim recite additional elements that integrate the judicial exception into a practical application?): For claims 2-11 and 13-19 this judicial exception is not integrated into a practical application.
In the dependent claims the additional elements not already recited in the independent claims are:
a first healthcare monitoring device
a remote control
a video call
a remote patient monitoring platform.
Examiner takes the applicable considerations stated in MPEP 2106.04 (d) and analyzes them below in light of the instant applications disclosure and claim elements as a whole.
The additional elements, (a), (b), (c), and (d), are applied as “apply-it” as a tool or equivalent to gather and output data
Accordingly, the dependent claims as a whole do not integrate the recited abstract idea into a practical application (MPEP 2106.05(f) and 2106.04(d)(1).
Eligibility Step 2B (Does the claim amount to significantly more?): The dependent claims do not include additional element which provide significantly more for the same reasons given in prong 2A-2 above. The claims are patent ineligible.
Claim Rejections - 35 USC § 102
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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1-15 and 18-20 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Petterson et. al (hereinafter Petterson) (US20220199251A1)
As per claim 1, Petterson teaches:
A computer-implemented method for remote patient monitoring using a plug-in device, comprising: receiving, from a remote source, a healthcare plan assigned to a patient; ([0069] discloses, “The applications of the present disclosure also provide patients with a patient interface where the tasks provided by a healthcare provider are received and dis played . In this case , as shown in FIG . 6 , a healthcare provider has provided to the patient a care plan comprising of recording his or her weight.” And see [0070] discloses, “The software application also provides an interface where push notifications sent by the healthcare provider are received and displayed . An additional interface component , in some embodiments , allows the patient to track or affirm completion of various health - related tasks such as physical activity or taking medications.” And see [0071] discloses, “FIG . 7 shows a screenshot of an exemplary patient interface on a patient application , wherein a patient is given a task 700 that corresponds to a patient care plan ( in this case , the care plan of FIG . 6 ).”)
causing a separate media device to present healthcare information of the patient based on the healthcare plan; ([0060] discloses, “FIG . 3 shows a screenshot of an exemplary patient interface a patient encounters during the sensing of an ECG - displayed on the interface at 300 — using an ECG sensing device . In some embodiments of the patient appli cation , a patient is able to select an option in the patient interface , for example , using a touchscreen button 306 that allows the patient to record audio and / or video using a computing device that is interacting with the patient application ( e.g. a smartphone that is running the patient application as an app ) . For example , a patient may sense an ECG with an ECG sensing device , transmit the sensed ECG to a processor on a computing device ( e.g. a smartphone or a smartwatch ) , and record an audio and / or video recording that the patient application associates with the sensed ECG . For example , a patient may record an audio recording that says “ I'm having chest pain ” together with a sensed ECG . The patient application is configured to associate the sensed ECG together with the recorded audio and / or video recording and store them locally on a computing device interacting with the patient application and / or transmit ECG and audio and / or video recording together to another computing device (e.g. a computing device of a healthcare provider or monitoring service).” )
receiving healthcare data regarding the patient from one or more healthcare monitoring devices based on the healthcare plan; ([0040] discloses, “A sensing device , in some embodiments , comprises a stand - alone device configured to transmit data to a patient application and / or a healthcare provider application . Non limiting examples of sensing devices configured to operate with the platform described herein include thermometers , heart - rate sensors , activity sensors ( e.g. an accelerometer , a gyroscope ) , location sensors ( including position sensors ) , blood pressure sensors , oxygen saturation sensors , weight sensors ( e.g. a scale ) , sweat sensors ( e.g. a capacitive sensor ) , respiration sensors , EEG sensors , and ECG sensors.” And see [0052] discloses, “In some embodiments of the patient application , the patient application is configured to communicate with another application running within the platform described herein , and , in some embodiments , is also configured to communicate with software applications that are not a part of the platform in order to transfer and / or receive data such as height , weight ,age , physical activity level , heart rate , blood pressure , and / or ECG data from a sensing device . For example , in some embodiments , the patient transfers to and / or receives data from other health based software applications including , but not limited to , Apple Health , Google Fit , S Health , and /or Fitbit and save it to his or her cardiac monitoring device.”)
and sending the healthcare data to the remote source. ([0053] discloses, “The patient application provides patients with one or more patient interfaces that provide for selection by the patient of specific data to be transmitted to a healthcare provider , and / or data that may be transmitted from the patient application to the healthcare provider automatically . Data transmitted to a healthcare provider application from the patient application comprises , for example , height data , weight data , age data , physical activity level data , heart rate data , blood pressure data , and ECG data.” And see [0042] discloses, “A patient application is configured to be operated by a patient and a healthcare provider application is configured to be operated by a healthcare provider . In some embodiments of the platform , a patient application is on a computing device that is located with the patient and is remotely located from a healthcare provider .)
As per claim 2, Petterson teaches:
The method of claim 1, further comprising configuring the one or more healthcare monitoring devices based on the healthcare plan. ([0040] discloses, “A sensing device , in some embodiments , comprises a stand - alone device configured to transmit data to a patient application and / or a healthcare provider application . Non limiting examples of sensing devices configured to operate with the platform described herein include thermometers , heart - rate sensors , activity sensors ( e.g. an accelerometer , a gyroscope ) , location sensors ( including position sensors ) , blood pressure sensors , oxygen saturation sensors , weight sensors ( e.g. a scale ) , sweat sensors ( e.g. a capacitive sensor ) , respiration sensors , EEG sensors , and ECG sensors.” And see [0059] discloses, “In some embodiments of the patient application , a patient interface comprises a dashboard 210 and / or interface 204 , which the patient engages with in order to carry out a task such as sense , for example , one or more physiologic parameters using a sensing device such as , for example , resting heart rate ( FIG . 2C ) , blood pressure ( FIG . 2D ) , physical activity , and weight BMI ( FIG . 2E ) . In some embodiments , when engaged by the patient ,interface 204 causes the sensing of a physiologic parameter of a patient by a sensing device 200 , 206 , or 208 ( which are depicted on the screen shot of the patient application in the exemplary embodiments of FIGS . 2B - E ) . First sensing device 200 comprises a smartphone operably coupled to one or more ECG electrodes ( not shown ) . As described herein , in some embodiments , a patient application is running on the first sensing device 200. A second sensing device 206 comprises a blood pressure cuff and a third sensing device 208 com prises a scale . As described herein , in some embodiments , a patient application receives sensed data transmitted from a sensing device on which it is not running such as , for example , embodiments of the second and third sensing devices 206 and 208.”)
As per claim 3, Petterson teaches:
The method of claim 2, wherein configuring the one or more healthcare monitoring devices comprises configuring a first healthcare monitoring device to capture a first vital sign at a first time. ([0061] discloses, “A patient application , in some embodiments , dis plays sensed patient data via a patient interface such as the exemplary interface displayed in FIG . 3. One or more health metrics displayed in the patient interface are displayed graphically or textually. The patient interface may also display an ECG at 300 and heart rate recordings at 304 over a period of time ; the ECG , heart rate recordings , and time may be displayed graphically or textually.” And see [0062] discloses, “The patient interface may further , for example , display the status of an ECG measurement , wherein the status may reflect : a normal ECG measurement and may be labeled as “ normal ; ” or an abnormal ECG measurement may be labeled as “ atrial fibrillation . ” In other aspects , the patient dashboard interface may enable the patient to add notes to each recorded health metric.”)
As per claim 4, Petterson teaches:
The method of claim 1, wherein configuring the one or more healthcare monitoring devices comprises configuring a first healthcare monitoring device to: detect a physiological state of the patient; (abnormal ECG) and measure one or more vital signs of the patient in response to detecting the physiological state. ([0087] discloses, “The healthcare provider application may alert the healthcare provider if certain data are received . For example , an interface of the healthcare provider's software application may show a list of notifications displaying information such as the patient's name , gender , age , phone number , and corresponding status update . In some embodiments of the software application , a status update may comprise a notification regarding a patient's ECG recording or the percentage of abnormal ECG data of a patient. Other examples of patient status updates that the healthcare provider may choose to activate notifications for are : possible atrial fibrillation detected , possible atrial fibrillation detected with heart rate surpassing a customizable number , heart rate surpassing a customizable number , heart rate under a customizable number , and no ECG data received in a customizable number of days . The frequency in which notifications are sent may be set to different parameters such as never , once , or always.” And see provider to choose an assessment of the highlighted ECG.” And see [0089] discloses, “In some embodiments of the healthcare provider application , the healthcare provider may also add an optional note to an ECG recording by selecting the “ Add Optional Note ” option 908 as illustrated by FIG . 9D . The healthcare provider application interface may provide for selection by the healthcare provider to adjust and / or select which types of status updates may be assigned to be notified . The software application interface may display the health care provider's total number of patients that are currently using the software application and have connected with the healthcare provider . An interface component provides for selection by the healthcare provider to add a new patient and send an invitation code via email . The healthcare provider may also send an electronic prescription for a cardiac health monitoring device or for regular cardiac health monitoring . The software application interface may display the health care provider's total number of patients that are currently pending acceptance of the healthcare provider's invitation to use the software application.” and see [0090] discloses, “Notifications may not only be received by the healthcare provider , but they may also be sent by the healthcare provider to a patient of their choice . The notifications sent to patients may be automatically generated . The notifications sent to patients may be personalized push notifications that are automatically generated and sent to patients when patients complete a prescribed task . For example , a healthcare provider's software application may automatically generate and send a push notification to a patient congratulating a patient for achieving a prescribed task . Examples of prescribed tasks may be performing a physical activity , losing weight , decreasing BMI points , recording ECG data , and / or recording blood pressure measurements.”)
As per claim 5, Petterson teaches:
The method of claim 1, further comprising: analyzing the healthcare data to determine that the patient is in a physiological state; and configuring, in response to determining that the patient is in the physiological state, a first healthcare monitoring device to capture one or more vital signs of the patient. ([0087] discloses, “The healthcare provider application may alert the healthcare provider if certain data are received . For example , an interface of the healthcare provider's software application may show a list of notifications displaying information such as the patient's name , gender , age , phone number , and corresponding status update . In some embodiments of the software application , a status update may comprise a notification regarding a patient's ECG recording or the percentage of abnormal ECG data of a patient. Other examples of patient status updates that the healthcare provider may choose to activate notifications for are : possible atrial fibrillation detected , possible atrial fibrillation detected with heart rate surpassing a customizable number , heart rate surpassing a customizable number , heart rate under a customizable number , and no ECG data received in a customizable number of days . The frequency in which notifications are sent may be set to different parameters such as never , once , or always.” And see provider to choose an assessment of the highlighted ECG.” And see [0089] discloses, “In some embodiments of the healthcare provider application , the healthcare provider may also add an optional note to an ECG recording by selecting the “ Add Optional Note ” option 908 as illustrated by FIG . 9D . The healthcare provider application interface may provide for selection by the healthcare provider to adjust and / or select which types of status updates may be assigned to be notified . The software application interface may display the health care provider's total number of patients that are currently using the software application and have connected with the healthcare provider . An interface component provides for selection by the healthcare provider to add a new patient and send an invitation code via email . The healthcare provider may also send an electronic prescription for a cardiac health monitoring device or for regular cardiac health monitoring . The software application interface may display the health care provider's total number of patients that are currently pending acceptance of the healthcare provider's invitation to use the software application.” and see [0090] discloses, “Notifications may not only be received by the healthcare provider , but they may also be sent by the healthcare provider to a patient of their choice . The notifications sent to patients may be automatically generated . The notifications sent to patients may be personalized push notifications that are automatically generated and sent to patients when patients complete a prescribed task . For example , a healthcare provider's software application may automatically generate and send a push notification to a patient congratulating a patient for achieving a prescribed task . Examples of prescribed tasks may be performing a physical activity , losing weight , decreasing BMI points , recording ECG data , and / or recording blood pressure measurements.”)
As per claim 6, Petterson teaches:
The method of claim 5, wherein configuring the first healthcare monitoring device to capture the one or more vital signs comprises configuring the first healthcare monitoring device to capture the one or more vital signs at a first rate that is higher than a second used to capture the one or more vital signs prior to determining that the patient is in the physiological state. (fig. 9B for e.g. and see [0074] and [0075] discloses, configuring healthcare device to monitor heart rate vital sign from a patient at a higher rate when undergoing stress test than a prior rate when the patient is at a baseline physiological state to induce a certain rhythm)
As per claim 7, Petterson teaches:
The method of claim 5, further comprising: receiving additional healthcare data regarding the patient from the one or more healthcare monitoring devices; determining, based on the additional healthcare data, that the patient is no longer in the physiological state; and reconfiguring, in response to determining that the patient is no longer in the physiological state, the first healthcare monitoring device to stop capturing the one or more vital signs of the patient. (fig. 9B for e.g. and see [0074] and [0075] discloses, post stress test having a 2 minute heart rate where the physiological state of stress is not present and the stress test monitoring rate is stopped)
As per claim 8, Petterson teaches:
The method of claim 1, wherein configuring the one or more healthcare monitoring devices comprises configuring a first healthcare monitoring device to: detect an event associated with the patient; and measure one or more vital signs of the patient in response to detecting the event. ([0087] discloses, “The healthcare provider application may alert the healthcare provider if certain data are received . For example , an interface of the healthcare provider's software application may show a list of notifications displaying information such as the patient's name , gender , age , phone number , and corresponding status update . In some embodiments of the software application , a status update may comprise a notification regarding a patient's ECG recording or the percentage of abnormal ECG data of a patient. Other examples of patient status updates that the healthcare provider may choose to activate notifications for are : possible atrial fibrillation detected , possible atrial fibrillation detected with heart rate surpassing a customizable number , heart rate surpassing a customizable number , heart rate under a customizable number , and no ECG data received in a customizable number of days . The frequency in which notifications are sent may be set to different parameters such as never , once , or always.” And see provider to choose an assessment of the highlighted ECG.” And see [0089] discloses, “In some embodiments of the healthcare provider application , the healthcare provider may also add an optional note to an ECG recording by selecting the “ Add Optional Note ” option 908 as illustrated by FIG . 9D . The healthcare provider application interface may provide for selection by the healthcare provider to adjust and / or select which types of status updates may be assigned to be notified . The software application interface may display the health care provider's total number of patients that are currently using the software application and have connected with the healthcare provider . An interface component provides for selection by the healthcare provider to add a new patient and send an invitation code via email . The healthcare provider may also send an electronic prescription for a cardiac health monitoring device or for regular cardiac health monitoring . The software application interface may display the health care provider's total number of patients that are currently pending acceptance of the healthcare provider's invitation to use the software application.” and see [0090] discloses, “Notifications may not only be received by the healthcare provider , but they may also be sent by the healthcare provider to a patient of their choice . The notifications sent to patients may be automatically generated . The notifications sent to patients may be personalized push notifications that are automatically generated and sent to patients when patients complete a prescribed task . For example , a healthcare provider's software application may automatically generate and send a push notification to a patient congratulating a patient for achieving a prescribed task . Examples of prescribed tasks may be performing a physical activity , losing weight , decreasing BMI points , recording ECG data , and / or recording blood pressure measurements.” / examiner interprets the abnormal ECG as both a physiological state and an event which happened physiologically to the patient)
As per claim 9, Petterson teaches:
The method of claim 1, further comprising: detecting occurrence of an event associated with the patient, based on the healthcare data; and configuring, in response to detecting the event, a first healthcare monitoring device to capture one or more vital signs of the patient. ([0087] discloses, “The healthcare provider application may alert the healthcare provider if certain data are received . For example , an interface of the healthcare provider's software application may show a list of notifications displaying information such as the patient's name , gender , age , phone number , and corresponding status update . In some embodiments of the software application , a status update may comprise a notification regarding a patient's ECG recording or the percentage of abnormal ECG data of a patient. Other examples of patient status updates that the healthcare provider may choose to activate notifications for are : possible atrial fibrillation detected , possible atrial fibrillation detected with heart rate surpassing a customizable number , heart rate surpassing a customizable number , heart rate under a customizable number , and no ECG data received in a customizable number of days . The frequency in which notifications are sent may be set to different parameters such as never , once , or always.” And see provider to choose an assessment of the highlighted ECG.” And see [0089] discloses, “In some embodiments of the healthcare provider application , the healthcare provider may also add an optional note to an ECG recording by selecting the “ Add Optional Note ” option 908 as illustrated by FIG . 9D . The healthcare provider application interface may provide for selection by the healthcare provider to adjust and / or select which types of status updates may be assigned to be notified . The software application interface may display the health care provider's total number of patients that are currently using the software application and have connected with the healthcare provider . An interface component provides for selection by the healthcare provider to add a new patient and send an invitation code via email . The healthcare provider may also send an electronic prescription for a cardiac health monitoring device or for regular cardiac health monitoring . The software application interface may display the health care provider's total number of patients that are currently pending acceptance of the healthcare provider's invitation to use the software application.” and see [0090] discloses, “Notifications may not only be received by the healthcare provider , but they may also be sent by the healthcare provider to a patient of their choice . The notifications sent to patients may be automatically generated . The notifications sent to patients may be personalized push notifications that are automatically generated and sent to patients when patients complete a prescribed task . For example , a healthcare provider's software application may automatically generate and send a push notification to a patient congratulating a patient for achieving a prescribed task . Examples of prescribed tasks may be performing a physical activity , losing weight , decreasing BMI points , recording ECG data , and / or recording blood pressure measurements.”)
As per claim 10, Petterson teaches:
The method of claim 1, further comprising: determining, based on the healthcare data, that one or more criteria of an alert are satisfied; and generating the alert in response to determining that the one or more criteria of the alert are satisfied. ([0064] discloses, “FIG . 4A shows a screenshot of an exemplary patient interface during sensing of a physiologic parameter comprising a blood pressure measurement . A sensing device , in some embodiments , comprises a blood pressure monitor comprising an electronic sphygmomanometer configured to sense a patient blood pressure and transmit the sensed blood pressure to the patient application . In some embodiments . a patient is prompted to record a blood pressure measurement by the patient application through the transmission of an alert or alarm 400 displayed on the interface or otherwise transmitted through a computing device interfacing with the patient application. The patient is then prompted , in some embodiments , to transfer the blood pressure recording from the blood pressure device to the patient application by , for example , engaging touchscreen button 402 , and furthermore , the patient may store said blood pressure recording in a computing device via the patient application , whereas , in some embodiments , storage and transmission of a sensed parameter is done automatically.” / examiner interprets the alert to take blood pressure as first prompted alert and the second prompt/alert in response to completion for transmitting the information)
As per claim 11, Petterson teaches:
The method of claim 1, further comprising providing a reminder to the patient using the media device based on the healthcare plan. ([0094] discloses, “The care plan may comprise automatically- or healthcare provider - generated tasks for the patient to complete and reminders to complete such tasks . Such tasks may be based on the patient's current health status and may provide specific health goals to meet”)
As per claims, 12, 13, and 14 they are article of manufacture claim which repeats the same limitations of claims 1, 3, 4, 8, and 11, the corresponding method claims, as a collection of executable instructions stored on machine readable media as opposed to a series of process steps. Since the teachings of Petterson disclose the underlying process steps that constitute the method of claim 1, 3, 4, 8, and 11, it is respectfully submitted that they likewise disclose the executable instructions that perform the steps as well. As such, the limitations of claims 12, 13, and 14, are rejected for the same reasons given above for claims 1, 3, 4, 8, and 11.
As per claim 15, Petterson teaches:
The one or more non-transitory computer-readable media of claim 14, wherein the reminder is a reminder to take a medication or to perform an action. ([0094] discloses, “The care plan may comprise automatically- or healthcare provider - generated tasks for the patient to complete and reminders to complete such tasks . Such tasks may be based on the patient's current health status and may provide specific health goals to meet” and see [0070] discloses, “An additional interface component , in some embodiments , allows the patient to track or affirm completion of various health - related tasks such as physical activity or taking medications.” / examiner under BRI interprets an action as a task as a task could be taking medication as disclosed )
As per claim 18, Petterson teaches:
The one or more non-transitory computer-readable media of claim 12, wherein the steps further comprise facilitating a video call with a healthcare provider. ([0005] discloses, “In some embodiments , the patient communication is recorded and transmit ted to the healthcare provider in real - time . In some embodiments , the sensor is configured to operably couple with a mobile computing device . In some embodiments , the sensor is integrated with the mobile computing device . In some embodiments , the sensor comprises two ECG electrodes . In some embodiments , the automatically generated communication comprises a message of encourage…[…]…In some embodiments , transmitting a real - time video communication between the patient and the healthcare provider”)
As per claim 19, Petterson teaches:
The one or more non-transitory computer-readable media of claim 12, wherein the remote source is a remote patient monitoring platform. ([0029] discloses, “A platform comprises one or more applications , wherein at least one application comprises a patient application and one application comprises a healthcare provider application . In some embodiments , a platform comprises an additional monitoring application ( i.e. in addition to the patient and healthcare provider application ) that is located on a computing device at a remote monitoring location . For example , a third party , in some embodiments , has a monitoring application that allows the third party to monitor and / or interact with one or more applications of one or more platforms . For example , a monitoring service that monitors patient data would utilize a monitoring application.” And see e.g. [0040] / examiner interprets the platform with remote devices and sensors to collect information in a centralized manner)
As per claim 20, it is a system claim which repeat the same limitations of claim 1, the corresponding method claim, as a collection of elements as opposed to a series of process steps. Since the teachings of Petterson disclose the underlying process steps that constitute the methods of claim 1, it is respectfully submitted that they provide the underlying structural elements that perform the steps as well. As such, the limitations of claim 20 is rejected for the same reasons given above for claim 1.
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.
Claims 16 and 17 are rejected to under 35 U.S.C. 103 as being unpatentable over Petterson et. al (hereinafter Petterson) (US20220199251A1) in view of Quinn et. al (hereinafter Quinn) (WO2015021208A1)
As per claim 16, Petterson does not teach:
The one or more non-transitory computer-readable media of claim 14, wherein providing the reminder comprises pausing media content being presented by the media device.
However, Quinn teaches:
The one or more non-transitory computer-readable media of claim 14, wherein providing the reminder comprises pausing media content being presented by the media device. (see field and see [00022] discloses, “A method for hands-free mobile healthcare aid to a subject may include: presenting, from a mobile device, a plurality of discrete pieces of health care information from a set of health care information, wherein at least one of the pieces of health care information comprise an instruction for the performance of a physical task by the subject; monitoring, using the mobile device, the subject for a verbal, visual or verbal and visual presentation control command while presenting the health care information, wherein the presentation control command controls the presentation of the piece of health care information and is selected from the group consisting of: a pause/stop presentation command, a repeat presentation command, a restart presentation command, a next presentation command, a slow presentation command, a provide more detail on presentation command, an increase volume of presentation command, a decrease volume of presentation command, a speed up presentation command, and a skip presentation command; interrupting the presentation of the piece of health care information after receiving the presentation control command to perform the presentation control command from the mobile device; and pausing after the presentation of each piece of health care information and confirming that the information has been received before presenting another piece of health care information.”)
It would be obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Petterson’s teachings with Quinn’s teachings, the motivation being Petterson discloses the need to put health management using generic phone devices (e.g. see [0002]) in the hand of the patient , and Quinn’s teachings as previously cited would improve the health management through a generic phone device and ensure that the patient is clear of the alerted healthcare plan to improve care of the patient.
As per claim 17, Petterson does not teach:
The one or more non-transitory computer-readable media of claim 14, wherein the steps further comprise: receiving, from a remote control associated with the plug-in device, an acknowledgment of the reminder; and restarting presentation of the content in response to receiving the acknowledgment.
However, Quinn does teach:
The one or more non-transitory computer-readable media of claim 14, wherein the steps further comprise: receiving, from a remote control associated with the plug-in device, an acknowledgment of the reminder; and restarting presentation of the content in response to receiving the acknowledgment. ([00096] discloses, “At screen 202 of FIG. 2, a reminder screen can pop up on the personal health assistant apparatus a specified time period prior to an upcoming procedure, exam, or appointment (such as on the user's smartphone running the software program). For example, for a patient with an upcoming colonoscopy procedure, screen 202 can pop up on the user's smartphone 5 days prior to the procedure to remind the patient to stop taking certain medications. At screen 202, the medical avatar can communicate to the patient through text or speech that it's 5 days until the colonoscopy and time to stop taking certain medications. The user may be required to indicate that they are ready to continue orally and/or by pressing a button on the apparatus, such as by indicating "next" or "I understand" before the software program advances to the next screen.” And see [00029] discloses, “In any of the methods for presenting the health care information described, the hands-free methods may generally include concurrent presentation (e.g., verbal/spoken word presentation) of the pieces of information and monitoring to detect a verbal presentation command (and/or response to an inquiry). Thus, any of the systems implementing these methods may filter the presented information and listen for verbal commands/responses from the subject. [00030] In general, the presentation control commands may be provided using spoken language (verbally) and may control or regulate the presentation; when control command is detected, the presentation is, depending on the command, interrupted so that it can be performed. Monitoring the subject for a presentation control command may include detecting a verbal message from the subject and comparing the verbal message to a menu of natural-language responses. Although the control commands described herein are primarily verbal, alternatively or additionally, control commands that are non-verbal (e.g., gestural and/or tactile) may also be used. For example, a control command for "stop" may be indicated by pressing a button (e.g., on the touchscreen of a phone).” And see [00031] discloses, “Any appropriate control command may be used and may modify the presentation. For example, a stop command (which may correspond to a subject saying "stop", "pause", "hang on", "wait", "hold on" or similar), may suspend the presentation, e.g., until a resume command is heard or received (e.g., "go on", "continue", "resume", "go", "start", "restart", etc.). Other control commands may include an end or quit the entire presentation command ("quit", "end presentation", "turn off, etc.); a repeat command, which may repeat the most recent piece of information presented ("repeat", "what was that?", "say that again", "say again", "one more time", etc.); a restart command, which may jump back to an previously presented piece of information ("restart", "go back", etc.); a next command, which may skip to the next piece of information ("next," "jump ahead", "skip", etc.); a slow command, which may slow the rate of the presentation, including the rate that the piece of information is being read aloud (e.g. "slow down", "slow", "slower", etc.); a faster command, which may increase the rate of the presentation, including the rate that the piece of information is being read aloud (e.g., "speed up", "faster", etc.); a provide more detail command ("tell me more about...", "more info", "what do you mean?", etc.); and volume command controls, such as an increase volume command ("louder", "I can't hear you", etc.), and a decrease volume command (e.g., "softer", "quieter", etc.). Any of these commands may be performed either without further notification, or after confirming and/or notifying the subject. In addition, after the presentation of each piece of health care information, the method or apparatus may wait for a verbal instruction from the subject to continue ("go one", "ok", "I understand", "done", etc.).”)
It would be obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Petterson’s teachings with Quinn’s teachings for the same reasons given for claim 16.
Prior Art not cited but made of record
US20140303988A1 – Maneri et. al
According to an example, collaborative healthcare may include retrieving healthcare data for a patient from at least one data Source, and generating a plurality of distinct health care programs for the patient based on the healthcare data. Collaborative healthcare may further include reconciling the plurality of distinct healthcare programs to generate a universal patient healthcare plan for the patient. The universal patient healthcare plan may include a universal view of the overall healthcare for the patient and healthcare provider specific views for the patient. The reconciling may include detecting conflicts for predetermined components of the healthcare programs, and in response to the detection of the conflicts, eliminating errors related to the detected conflicts.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Ashley Elizabeth Evans whose telephone number is (571) 270-0110. The examiner can normally be reached Monday – Friday 8:00 AM – 5:00 PM.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Mamon Obeid can be reached on (571) 270-1813. The fax phone number for the organization where this application or proceeding is assigned 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. Should you have questions on access to the Patent Center, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
/ASHLEY ELIZABETH EVANS/Examiner, Art Unit 3687
/MAMON OBEID/Supervisory Patent Examiner, Art Unit 3687