DETAILED ACTION
Acknowledgements
This office action is in response to the claims filed June 15, 2026.
Claims 1-4 and 7-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 .
Response to Amendment(s)
Claims 1-4 and 7-20 are pending
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-4 and 7-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, a healthcare plan assigned to a patient from a remote source
causing…[…]…present healthcare information of the patient based on the healthcare plan;
receiving healthcare data regarding the patient based on the healthcare plan;
analyzing, …[…]…the healthcare data to determine that the patient is in a physiological state defined by a state configuration of the healthcare plan;
configuring, …[…]…in response to determining that the patient is in the physiological state, …[…]…to capture one or more vital signs of the patient,
wherein configuring …[…]…to capture the one or more vital signs at a first capture rate that is higher than a second capture rate at which …[…]….captured the one or more vital signs prior to determining that the patient is in the physiological state
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 patient-side remote patient monitoring (RPM) application executing on a plug-in device
a separate media device
a first healthcare monitoring device of the 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 separate media device, is applied as “apply-it” as a tool or equivalent to gather data
The additional element, a first healthcare monitoring device of the 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-4, 7-11, and 13-19:
Eligibility Step 1 (does the subject matter fall within a statutory category?): The dependent claims 2-4 and 7-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-4, 7-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-4, 7-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-4, 7-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, by a patient-side remote patient monitoring (RPM) application executing on the plug-in device, a healthcare plan assigned to a patient from a remote source; ([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 ).” / examiner notes the instant application specification discloses in [0019] The plug-in device 110 can include any technically feasible type of computer system.)
causing, by the patient-side RPM application, 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.”)
analyzing, by the patient-side RPM application, the healthcare data to determine that the patient is in a physiological state defined by a state configuration of the healthcare plan; configuring, by the patient-side RPM application and in response to determining that the patient is in the physiological state, a first healthcare monitoring device of the one or more healthcare monitoring devices 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.”)
wherein configuring the first healthcare monitoring device comprises configuring the first healthcare monitoring device to capture the one or more vital signs at a first capture rate that is higher than a second capture rate at which the first healthcare monitoring device captured 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)
and sending, by the patient-side RPM application, 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 the 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 the first healthcare monitoring device to: detect the physiological state of the patient; (abnormal ECG) and measure the 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 7, Petterson teaches:
The method of claim 1, 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 the first healthcare monitoring device to: detect an event associated with the patient; and measure the 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, the first healthcare monitoring device to capture the 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 separate 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 the 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 16, 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.
Response to Arguments Regarding 35 U.S.C § 101 Rejections
Applicant’s arguments on pages 1-15 of remarks have been considered. Applicant argues the following: Applicant respectfully traverses the rejection of claims 1-20 under 35 U.S.C. § 101 as allegedly not being directed to eligible subject matter. Nevertheless, solely to advance prosecution and without acquiescing to the rejection, Applicant has amended independent claim 1 to more clearly recite patent-eligible subject matter
1. The Claims Do Not Recite A Judicial Exception Under Step 2A, Prong One Applicant respectfully submits that the claims do not recite a judicial exception under Step 2A, Prong One, and are therefore patent-eligible. Specifically, the claims do not recite any of the judicial exceptions enumerated in the 2024 Guidance Update on Patent Subject Matter Eligibility Including on Artificial Intelligence, 89 Fed. Reg. 58128-58138 (Jul. 17, 2024) ("2024 PEG") and MPEP §§ 2103 to 2106.07. Further, the claims do not recite a judicial exception as explained in Reminders on evaluating subject matter eligibility of claims under 35 U.S. C. 101 issued August 4, 2025 ("August 4 Memo"). Moreover, the claims do not recite a judicial exception as exemplified in the July 2024 Subject Matter Eligibility Examples effective July 17, 2024 ("July Examples"); the October 2019 PEG Appendix ] issued October 17, 2019 ("October Examples"); the 2019 PEG Examples 37 through 42 issued January 7, 2019 ("January Examples"); and the Examples 1-36 issued between December 16, 2014, through December 16, 2016 ("101 Examples").
The Office alleges that the claims are "directed to an abstract idea without significantly more" and that the "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." Office Action at 3. Applicant interprets this assertion as alleging the claims fall under the "managing personal behavior or relationships or interactions between people" sub-grouping and respectfully disagrees with this interpretation of the claims.
Applicant respectfully submits that the recited subject matter of amended independent claim 1 is directed to a specific, autonomous, device-implemented technical method that operates entirely at the hardware and software level of the plug-in device (e.g., a defined over-the-top (OTT) computing platform), without any human organizational component.
For example, claim 1 does not involve providing any instructions to a human (e.g., healthcare provider, patient) to follow the recited steps. Instead, each step of amended claim 1 is performed autonomously by the patient-side RPM application executing on the plug-in device. Specifically, the patient-side RPM application executing on the plug-in device: (i) receives a healthcare plan from a remote source, (ii) causes a separate media device to present healthcare information, (iii) receives healthcare data from one or more healthcare monitoring devices, (iv) analyzes the healthcare data to determine a physiological state of the patient, (v) configures, in response to determining the patient is in the physiological state, a first healthcare monitoring device differently than previously configured, and (vi) sending the healthcare data to the remote source. No human behavior (either individual or between humans) is managed, and no rules or instructions for following are recited.
Instead, claim 1 recites subject matter relating to the patient-side RPM application executing on the plug-in device executing a series of technical steps that meaningfully modify the operation of another device (i.e., first healthcare monitoring device) in at least "configuring, by the patient- side RPM application and in response to determining that the patient is in the physiological state, a first healthcare monitoring device of the one or more healthcare monitoring devices to capture one or more vital signs of the patient, wherein configuring the first healthcare monitoring device comprises configuring the first healthcare monitoring device to capture the one or more vital signs at a first capture rate that is higher than a second capture rate at which the first healthcare monitoring device captured the one or more vital signs prior to determining that the patient is in the physiological state." At least this recitation in amended claim 1 is not directed to any abstract idea grouping. For example, this recitation is related to real-time, autonomous reconfiguration of a healthcare monitoring device by the patient-side RPM application executing on the plug-in device.
Additionally, Applicant interprets the Office's silence regarding the abstract idea groupings of mathematical concepts and mental processes as admitting the claims are not so directed. Applicant agrees and submits that the claims are not directed to a mathematical concept (e.g., because no mathematical concept is recited) or a mental process (e.g., because the human mind is ill-equipped, with or without a physical aid, to perform the recited subject matter).
Therefore, even if some steps recited in the independent claims may be considered a certain method of organizing human activity, which the Applicant does not accede, the claims as a whole are not directed to a judicial exception (i.e., Step 2A, Prong One: NO).
Examiner appreciates applicant’s arguments but does not find it persuasive. The MPEP § 2106.04(a) The sub-grouping “managing personal behavior or relationships or interactions between people" include social activities, teaching, and following rules or instructions. An example of a claim reciting managing personal behavior is Intellectual Ventures I LLC v. Capital One Bank (USA), 792 F.3d 1363, 115 USPQ2d 1636 (Fed. Cir. 2015). The patentee in this case claimed methods comprising storing user-selected pre-set limits on spending in a database, and when one of the limits is reached, communicating a notification to the user via a device. 792 F.3d. at 1367, 115 USPQ2d at 1639-40. The Federal Circuit determined that the claims were directed to the abstract idea of "tracking financial transactions to determine whether they exceed a pre-set spending limit (i.e., budgeting)", which "is not meaningfully different from the ideas found to be abstract in other cases before the Supreme Court and our court involving methods of organizing human activity." 792 F.3d. at 1367-68, 115 USPQ2d at 1640 MPEP 2106.04(a)(2) (II) states, “Finally, the sub-groupings encompass both activity of a single person (for example, a person following a set of instructions or a person signing a contract online) and activity that involves multiple people (such as a commercial interaction), and thus, certain activity between a person and a computer (for example a method of anonymous loan shopping that a person conducts using a mobile phone) may fall within the “certain methods of organizing human activity” grouping. It is noted that the number of people involved in the activity is not dispositive as to whether a claim limitation falls within this grouping.”
The instant application claims 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)
Examiner is tasked with considering the claim as a whole and determining what is abstract idea in the claim and what are additional elements. Examiner performed this analysis and did not overly simplify the claims as the claims clearly recite receiving a patient receiving a healthcare plan and healthcare data and analyzing this data to monitor a physiological state and presenting or sending additional data based on this physiological state and this abstract idea is a form of human activity completed prior to the use of generic computers by humans following rules and instructions and as the MPEP states the computer tools do not make this dispositive of being certain methods of organizing human activity. Further real-time, autonomous reconfiguration of a healthcare monitoring device by the patient-side RPM application executing on the plug-in device is not recited in the claim. The claim recites configured to which is clear “apply-it” language not a transformation of hardware.
Applicant further argues, 2. The Claims Integrate Any Alleged Judicial Exception Into A Practical Application Under Step 2A Prong Two As explained above, the claims do not recite a judicial exception under Step 2A, Prong One. Under Prong Two, the combination of steps and elements, when analyzed as a whole, also sufficiently ensures that the claims as a whole integrate any judicial exception into a practical application of the exception. For example, the MPEP states that: The Prong Two analysis considers the claim as a whole. That is, the limitations containing the judicial exception as well as the additional elements in the claim besides the judicial exception need to be evaluated together to determine whether the claim integrates the judicial exception into a practical application.... [T]he way in which the additional elements use or interact with the exception may integrate it into a practical application. Accordingly, the additional limitations should not be evaluated in a vacuum, completely separate from the recited judicial exception. Instead, the analysis should take into consideration all the claim limitations and how those limitations interact and impact each other when evaluating whether the exception is integrated into a practical application. MPEP § 2106.04(d)(III) (emphases added). Thus, Applicant respectfully disagrees with the Office's Step 2A, Prong Two analysis of previously presented claim 1 because the Office only identified "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," and "a plug-in device comprising: a memory storing instructions; and a processing system coupled to the memory that executes the instructions" as additional elements while failing to consider how these additional elements interact with the other elements of the claim. See Office Action at 4. Instead, the Office merely alleges that each of the above-identified additional elements are merely applied as "apply-it" as a tool to perform the alleged abstract idea. See Office Action at 4.
Thus, the Office has failed to properly consider each claim element, including their ordered combination, in assessing the claims under Step 2A, Prong Two. See, e.g., MPEP § 2106.04(d)(III): "However, the way in which the additional elements use or interact with the exception may integrate it into a practical application. Accordingly, the additional limitations should not be evaluated in a vacuum, completely separate from the recited judicial exception. Instead, the analysis should take into consideration all the claim limitations and how those limitations interact and impact each other when evaluating whether the exception is integrated into a practical application." (Emphases added).
Additionally, Applicant respectfully submits that amended claim 1 recites other elements that themselves do not recite or are directed to any abstract idea grouping, such as "configuring, by the patient-side RPM application and in response to determining that the patient is in the physiological state, a first healthcare monitoring device of the one or more healthcare monitoring devices to capture one or more vital signs of the patient, wherein configuring the first healthcare monitoring device comprises configuring the first healthcare monitoring device to capture the one or more vital signs at a first capture rate that is higher than a second capture rate at which the first healthcare monitoring device captured the one or more vital signs prior to determining that the patient is in the physiological state," and are therefore "additional elements" for consideration in the Step 2A, Prong Two analysis.
As explained above, these operations have nothing to do with any rules or instructions for following as defined and exemplified in MPEP § 2106.04(a)(2)(II)(C). Instead, these operations are specific, technical steps that integrate the alleged abstract idea into a practical application. For example, the MPEP states that: One way to demonstrate such integration is when the claimed invention improves the functioning of a computer or improves another technology or technical field.... In short, first the specification should be evaluated to determine if the disclosure provides sufficient details such that one of ordinary skill in the art would recognize the claimed invention as providing an improvement.... Second, if the specification sets forth an improvement in technology, the claim must be evaluated to ensure that the claim itself reflects the disclosed improvement. That is, the claim includes the components or steps of the invention that provide the improvement described in the specification. MPEP § 2106.04(d)(1) (emphases added). i. Applicant's specification provides sufficient detail about improvements recited in amended independent claim 1 For example, the Specification identifies a technical problem: Healthcare monitoring devices can measure various vital signs, monitor activity levels, and capture stressful events without user intervention by frequently collecting data on the patient at regular intervals. Such frequent measurement of vital signs generates large quantities of health data, which can be challenging for a healthcare provider and/or data analysis program to analyze, correlate, and interpret. Furthermore, with the limited battery capacity of many battery-powered healthcare monitoring devices, configuring frequent data collection leads to rapid draining of batteries, which results in frequent recharging or frequent battery replacement. To address this, healthcare monitoring devices are often configured to compromise by collecting data less often so as to reduce the quantity of data generated and improve the battery life of the healthcare monitoring devices. However, capturing data less often can cause a healthcare monitoring device to miss capturing vital data at an important moment, such as while the patient is experiencing a stressful condition or is in an important physiological state (e.g., a heart attack).
Specification at [0005] (emphasis added). That is, healthcare monitoring devices are technically constrained to operate at fixed monitoring intervals, thereby either unnecessarily increasing battery consumption, memory usage, bandwidth utilization, and computational overhead, or failing to capture clinically relevant healthcare data during critical physiological conditions of a patient. See also Specification at [0004] and [0006]. The Specification further provides sufficient detail such that one having ordinary skill in the art would recognize an improvement and technical solution to the above-discussed technical problem:
In step 412, healthcare data is received regarding the patient. The RPM application receives the healthcare data regarding the patient, such as patient 102, from a healthcare monitoring device, such as healthcare monitoring device 136. In some examples, the healthcare data are received when a healthcare monitoring device detects an event or a state and begins collecting the healthcare data in response. In some examples, the healthcare data are received when a healthcare monitoring device is configured by an RPM application to start collecting healthcare data in response to the RPM application detecting an event or a state. In some examples, the RPM application analyzes the healthcare data from a first healthcare monitoring device to see whether the healthcare data indicates a particular event in an event configuration or an event in an event configuration for which the first healthcare monitoring devices is not configured to automatically collect the additional healthcare data associated with the event configuration or the state configuration. When the first healthcare monitoring device is not configured to automatically collect the additional healthcare data, the RPM application configures the first healthcare monitoring device or a second healthcare monitoring device to collect the additional healthcare data. In some examples, the RPM application uses an API provided by the healthcare monitoring device to request the healthcare data from the healthcare monitoring device at periodic intervals, in response to various alerts, in response to notifications received from the healthcare monitoring device and/or in response to notifications received from another healthcare monitoring device. Specification at [0084] (emphasis added). One having ordinary skill in the art would recognize that such an event-detection-based configuration of one or more healthcare monitoring devices would "reduc[e] power consumption, reduc[e] memory usage, and reduc[e] bandwidth" and also reduce "computing resources used to analyze the collected data." Specification at [0104].
Therefore, Applicant's specification provides sufficient detail about the improvements recited in amended claim 1. ii. Amended independent claim 1 recites the disclosed improvements and how they are achieved
As noted above, amended independent claim 1 recites, in part, "configuring, by the patient-side RPM application and in response to determining that the patient is in the physiological state, a first healthcare monitoring device of the one or more healthcare monitoring devices to capture one or more vital signs of the patient, wherein configuring the first healthcare monitoring device comprises configuring the first healthcare monitoring device to capture the one or more vital signs at a first capture rate that is higher than a second capture rate at which the first healthcare monitoring device captured the one or more vital signs prior to determining that the patient is in the physiological state." (Emphases added).
At least these claim limitations reflect that amended independent claim 1 includes the technical operations by the RPM application executing on the plug-in device disclosed in Applicant's specification to automatically configure one or more healthcare monitoring devices to capture vital signs at a higher capture rate responsive to determining that the patient is in a particular physiological state, thereby maximizing performance while minimizing potentially unnecessary or less relevant data collection.
Accordingly, amended claim 1 as a whole integrates an abstract idea, alleged by the Office and disputed by Applicant, into a practical application such that amended claim 1 is not directed to the abstract idea. See MPEP §§ 2106.04(d)(III) and 2106.04(d)(1). Amended independent claims 12 and 20, although of different scope, each recite limitations similar to those discussed above for amended claim 1, and therefore also integrates the alleged abstract idea into a practical application.
Accordingly, Applicant respectfully submits that each of amended independent claims 1, 12, and 20 integrates the alleged abstract ideas into a practical application because of their improvements in the technical operation of the patient-side RPM application executing on the plug- in device and one or more healthcare monitoring devices. Therefore, they recite patent eligible subject matter at Step 2A, Prong Two in accordance with MPEP § 2106.04(d)(III). (i.e., Step 2A, Prong Two: YES).
Examiner appreciates applicant’s argument but does not find it persuasive. Examiner analyzes and reads the claims as a whole not in a “vacuum” and also considers what abstract idea is recited within the claims If any and also considers the additional elements as required by the MPEP as the additional elements are what bring forth the practical application as the abstract idea cannot provide the practical application. The analysis at each prong was completed as required by the MPEP and the additional elements must bring forth the improvement and must be directed to a specific improvement in the computer’s functionality, not simply to use of the computer “as a tool” to implement an abstract idea or other technological improvement confined to the computer environment in which the claims recite. The claims are confined to “apply-it” level computer tools as evidenced by the broad recitation of such devices in the claims “patient a patient-side remote patient monitoring (RPM) application executing on a plug-in device” “a separate media device” “a first healthcare monitoring device of the one or more healthcare monitoring devices” “One or more non-transitory computer-readable media storing instructions that, when executed by one or more processors” and “A plug-in device comprising: a memory storing instructions; and a processing system coupled to the memory that executes the instructions” and in combination with the remainder of the claim recitation which is mere gathering and outputting of healthcare data it is clear in the MPEP this may be a more quick way to determine a healthcare plan and monitor a patients physiological state but it is still abstract and the additional elements do not bring forth a practical application. So, while examiner can appreciate the level of detail in the specification the claims do not reflect a solution to the identified technical problem of "reduc[e] power consumption, reduc[e] memory usage, and reduc[e] bandwidth" and also reduce "computing resources used to analyze the collected data." as the claims do not improve upon the computer functionality or any substrate to achieve this solution but rather use the generic computer elements as tools with no affirmative recitation of any transformation to the technology which would achieve this type of computer confined tangible improvement as the data collection could in fact do the opposite of what is recited as the technical problem in the specification at the level of breadth claimed as there is no additional technical detail or affirmative recitation on how these additional elements in combination with the claim as a whole reduce power consumption, reduce memory usage, or reduce bandwidth.
Applicant further argues, 3. The Claims Recite Significantly More than an Abstract Idea
As described above, Applicant's claims are not directed to an abstract idea, and the claims are patent-eligible without needing to reach the "significantly more" inquiry under Step 2B. Nevertheless, Applicant notes that the claims also amount to "significantly more" than any alleged "abstract idea," and the Office has not shown otherwise.
The Office Action's conclusion under Step 2B that the claims do not recite significantly more than the alleged abstract idea is based on the allegation that "[t]he independent claims do not include additional element which provide significantly more for the same reasons given in prong 2A-2 above." Office Action at 5.
Initially, Applicant submits that the Office has failed to properly analyze the claims under Step 2B through its mere reference to the Step 2A, Prong Two analysis. See Office Action at 5. According to the MPEP, "Step 2A Prong Two is similar to Step 2B in that both analyses involve evaluating a set of judicial considerations to determine if the claim is eligible. See MPEP § § 2106.05(a) through (h) for the list of considerations that are evaluated at Step 2B. Although most of these considerations overlap (i.e., they are evaluated in both Step 2A Prong Two and Step 2B), Step 2A specifically excludes consideration of whether the additional elements represent well-understood, routine, conventional activity." MPEP § 2106.04(d)(I) (emphasis added). See also MPEP § 2106.07(a): "For Step 2B, the rejection should explain why the additional elements, taken individually and in combination, do not result in the claim, as a whole, amounting to significantly more than the identified judicial exception. For instance, when the examiner has concluded that certain claim elements recite well understood, routine, conventional activities in the relevant field, the examiner must expressly support the rejection in writing with one of the four options specified in Subsection III." That is, while the Step 2B analysis includes some overlap with Step 2A, Prong Two, the Step 2B analysis is a separate and additional consideration of the claims that the Office has failed to clearly set forth.
Moreover, Applicant respectfully submits that the independent claims, when taken as a whole, provide a specific, technological improvement to the functioning of a technical device and system (e.g., patient-side RPM application executing on the plug-in device) and does not preempt all applications of the alleged judicial exception.
In particular, the Applicant's claimed invention includes: (i) receiving, by a plug-in device executing a patient-side RPM application, a healthcare plan comprising a state configuration from an RPM platform; (ii) autonomously analyzing received healthcare data against the state configuration to determine whether a patient is in a physiological state; (iii) automatically configuring a first healthcare monitoring device to capture one or more vital signs at a first rate that is higher than a second rate used prior to determining the physiological state; (iv) causing a separate media device to present healthcare information to the patient through the plug-in device; and (v) dynamically transmitting healthcare data associated with the elevated capture operation to the RPM platform without requiring healthcare provider intervention.
Applicant submits that the recited coordinated and non-conventional combination of devices and operations results in an adaptive, event-driven remote monitoring system that performs autonomous physiological state detection and real-time capture-rate escalation, which is not achievable in conventional remote patient monitoring systems (e.g., which operate at static or provider-controlled collection intervals).
For example, as discussed in the Specification and above, conventional RPM systems lack the capability to adaptively change data collection rates in response to detected physiological states, thereby resulting in excessive battery consumption caused by continuously frequent monitoring and/or missed clinically significant events caused by infrequent monitoring intervals. The subject matter recited in amended claim 1 overcomes these deficiencies through a state-triggered, adaptive monitoring framework that selectively escalates data collection only when the patient-side RPM application determines that the patient is in a defined physiological state. This arrangement provides concrete technological improvements including reduced power consumption, reduced memory usage, reduced bandwidth utilization, and improved clinical relevance of captured healthcare data.
Although not specifically alleged by the Office, amended claim 1 recites technical operations within a defined technical architecture involving a plug-in OTT computing device having dedicated processing, memory, I/O, and network interfaces that communicate with one or more healthcare monitoring devices and a separate media device, none of which could be considered generic data collection or post-solution activity. Instead, amended claim 1 recites technical operations that transform healthcare monitoring operations through autonomous, device- side physiological state analysis and adaptive hardware reconfiguration that alters how physical healthcare monitoring devices operate in the real world. Specifically, the configuring step changes the capture behavior of a physical healthcare monitoring device from a lower capture rate to a higher capture rate upon detection of a defined physiological condition. This is a concrete technical operation affecting physical medical hardware and not merely the manipulation or presentation of information.
For example, in CardioNet, LLC v. InfoBionic, Inc., 955 F.3d 1358 (Fed. Cir. 2020), the Federal Circuit reversed a § 101 ineligibility determination and held that claims directed to an improved cardiac monitoring device were patent eligible. The Court emphasized that the claims were not merely directed to collecting, analyzing, and reporting physiological data. Rather, the claims recited a specific technological improvement in cardiac monitoring, namely detecting beat- to-beat timing, detecting premature ventricular beats, and determining the relevance of beat-to-beat variability to atrial fibrillation or atrial flutter while accounting for variability caused by premature ventricular beats. The Court specifically cautioned that generalizing such claims as merely "collecting, analyzing, and reporting data" improperly oversimplifies the claim language and fails to account for the specific technological requirements of the claims.
The reasoning in CardioNet draws direct parallels to the presently pending claims. Similar to the claims found eligible in CardioNet, the pending claims are not directed merely to gathering, processing, and presenting healthcare information. Instead, the claims recite a specific technological improvement in RPM systems, namely a patient-side RPM application executing on a plug-in device that receives healthcare data from one or more healthcare monitoring devices, analyzes the healthcare data to determine that a patient is in a physiological state defined by a state configuration of a healthcare plan, and, in response, automatically configures a first healthcare monitoring device to capture vital signs at a first capture rate higher than a second capture rate used before the physiological state was determined.
Accordingly, as in CardioNet, the claims improve the operation of healthcare monitoring technology itself. The claimed plug-in device does not merely use a computer as a tool to automate a healthcare workflow. Rather, the plug-in device executes a closed-loop, patient-side monitoring process that transforms detected physiological-state information into adaptive control of physical monitoring hardware. This improves the functioning of the remote patient monitoring system by enabling condition-responsive capture-rate escalation, reducing unnecessary high-frequency monitoring, conserving power, memory, bandwidth, and processing resources, and improving capture of clinically relevant patient data. Therefore, the claims are directed to a specific technological improvement in remote patient monitoring and are patent eligible under § 101 for reasons analogous to those recognized by the Federal Circuit in CardioNet.
The dependent claims further reinforce the non-conventional character of the claimed invention by reciting additional technical limitations including configuring healthcare monitoring devices to detect physiological states and measure vital signs, dynamically stopping elevated monitoring upon determining the patient is no longer in the physiological state, generating alerts based on healthcare plan criteria, providing reminders through the separate media device with remote-control acknowledgment functionality, facilitating video calls with healthcare providers through the plug-in device, and specifically identifying the remote source as a remote patient monitoring platform. These additional limitations further anchor the claims to a specific technical architecture and confirm that the claims amount to significantly more than any alleged abstract idea.
Accordingly, the claimed invention recites significantly more than any alleged judicial exception by virtue of its non-generic integration of autonomous physiological state analysis, adaptive medical device reconfiguration, event-driven capture-rate escalation, and plug-in device- based remote monitoring operations into a cohesive technical solution for adaptive remote patient monitoring. In view of the foregoing, amended claim 1 recites "significantly more" than the alleged abstract idea and for this additional reason is patent eligible. Although of different scope, independent claims 12 and 20 are similarly directed and thus recite "significantly more" than the alleged abstract idea for the reasons discussed above with respect to claim 1. Dependent claims 2- 4, 7-11, and 13-19 are also eligible at least by virtue of their dependence from patent-eligible claims, as well as the additional features recited therein. Accordingly, the rejection under 35 U.S.C. § 101 should be withdrawn.
Examiner appreciates applicant’s arguments but does not find them persuasive. CardioNet has no nexus with the claimed invention as the fact pattern and scope of claims are different and each case turns on its on set of facts as it was an improvement to a specific technology affirmatively recited in the claims. Further examiner will not restate what has already been stated above as the analysis at Prong 2 does apply here and no further analysis as required by examiner as the generic computer components were an “apply-it” level.
Examiner maintains the 35 U.S.C 101 rejection.
Response to Arguments Regarding 35 U.S.C § 102/103 Rejections
Applicant’s arguments on pages 15-19 of remarks have been considered. Applicant argues the following: Applicant respectfully traverses the rejection of claims 1-15 and 18-20 under 35 U.S.C. § 102(a)(2) as allegedly being anticipated by Petterson. See Office Action at 7-22. Nevertheless, solely to advance prosecution and without acquiescing to the Office's assertions, Applicant has amended independent claim 1 to further distinguish from Petterson. For example, amended claim 1 recites subject matter previously recited in dependent claims 5 and 6, which are now cancelled.
Amended claim 1 recites, in part: analyzing, by the patient-side RPM application, the healthcare data to determine that the patient is in a physiological state defined by a state configuration of the healthcare plan; configuring, by the patient-side RPM application and in response to determining that the patient is in the physiological state, a first healthcare monitoring device of the one or more healthcare monitoring devices to capture one or more vital signs of the patient, wherein configuring the first healthcare monitoring device comprises configuring the first healthcare monitoring device to capture the one or more vital signs at a first capture rate that is higher than a second capture rate at which the first healthcare monitoring device captured the one or more vital signs prior to determining that the patient is in the physiological state
According to MPEP § 2131: "A claimed invention may be rejected under 35 U.S.C. 102 when the invention is anticipated (or is "not novel") over a disclosure that is available as prior art. To reject a claim as anticipated by a reference, the disclosure must teach every element required by the claim under its broadest reasonable interpretation. See, e.g., MPEP § 2114, subsections II and IV. 'A claim is anticipated only if each and every element as set forth in the claim is found, either expressly or inherently described, in a single prior art reference.' Verdegaal Bros. v. Union Oil Co. of California, 814 F.2d 628, 631, 2 USPQ2d 1051, 1053 (Fed. Cir. 1987)."
Firstly, the Office alleges Petterson discloses "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" as previously recited in now-cancelled claim 5, citing [0087], [0089], and [0090] of Petterson. See Office Action at 13-14. Applicant respectfully disagrees.
For example, these cited paragraphs merely disclose provider-side notification functionality in which the healthcare provider application alerts a healthcare provider regarding received ECG data or allows the provider to configure notification preferences. Petterson fails to teach, expressly or implicitly, any analysis of healthcare data or any configuration of a healthcare monitoring device, including by a "patient-side RPM application executing on the plug-in device" as recited in amended claim 1. Indeed, Petterson merely discloses that data is collected and displayed. For at least this reason, amended claim 1 is allowable.
Secondly, the Office alleges Petterson teaches "wherein configuring the first healthcare monitoring device to capture the one or more vital signs comprises configuring the first healthcare-24-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" as previously recited in now-cancelled claim 6, citing [0074] and [0075] and FIG. 9B of Petterson. Office Action at 15. Applicant respectfully disagrees.
For example, Petterson merely discloses that its device can be used to monitor heart rate during an exercise stress test. However, Petterson fails to teach, expressly or implicitly, that the device itself captures data at a higher rate during such an exercise stress test. Instead, the Office appears to map the "higher rate" to the patient's heart rate before and during the exercise stress test and not the actual capture rate of the healthcare monitoring device itself. Thus, Petterson fails to teach at least this additional element of amended claim 1, and for at least this additional reason, amended claim 1 is allowable. Thirdly, amended claim 1 recites that the operations are performed by "a patient-side remote patient monitoring (RPM) application executing on the plug-in device." Applicant respectfully submits that Petterson fails to teach, expressly or implicitly, that each of the recited operations are performed by such a device. For example, Petterson discloses operations as being performed by digital processing device 101 and remote device 135, neither of which are taught as including an RPM application executing on a plug-in device. For at least this additional reason, amended claim 1 is allowable. In view of the above-discussed differentiating features, Petterson fails to teach each and every element of amended claim 1. Although of different scope, independent claims 12 and 20 have been amended to recite subject matter similar to that discussed above with respect to amended claim 1 and are therefore allowable at least for similar reasons. Dependent claims 2-4, 7-11, 12-15, 18, and 19 are also allowable at least due to their dependence from one of independent claims 1, 12, and 20 as well as due to the additional patentable subject matter they recite. The rejection of claims 5 and 6 are mooted by their cancellation.
Accordingly, Applicant respectfully requests the Office withdraw the § 102 rejection of claims 1-15 and 18-20.
Examiner appreciates applicant’s argument but respectfully disagrees. Petterson clearly teaches the limitations of claim one under broadest reasonable interpretation. The claim recites “A computer-implemented method for remote patient monitoring using a plug-in device, comprising: receiving, by a patient-side remote patient monitoring (RPM) application executing on the plug-in device, a healthcare plan assigned to a patient from a remote source;” and Petterson teaches in [0069] which 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 ).” Examiner notes the instant application specification discloses in [0019] The plug-in device 110 can include any technically feasible type of computer system.” Therefore Petterson teaches patient side monitoring device which can be plug in as it can be any computer system according to applicant and a healthcare plan is received at this software application.
Further the claim 1 recites “ causing, by the patient-side RPM application, a separate media device to present healthcare information of the patient based on the healthcare plan;” and Petterson clearly teaches in [0060] which 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 application , 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).” It is clear that the presentation of video or audio of ECG can be on a separate device which is caused by the patient side monitoring application using touchscreen.
Further the claim recites “receiving healthcare data regarding the patient from one or more healthcare monitoring devices based on the healthcare plan;” and Petterson clearly teaches in [0040] which 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.” Which is receiving data frm one or more healthcare monitoring devices as broadly recited in the claim.
Further the claim recites “analyzing, by the patient-side RPM application, the healthcare data to determine that the patient is in a physiological state defined by a state configuration of the healthcare plan; configuring, by the patient-side RPM application and in response to determining that the patient is in the physiological state, a first healthcare monitoring device of the one or more healthcare monitoring devices to capture one or more vital signs of the patient,” and Petterson clearly teaches in [0087] which 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.” Which clearly Patterson recites that the patient side software application has necessarily analyzed data as there is clear information output such as atrial fibrillation detected. The claim does not limit what type of analysis or level of detailed analysis is completed. Further the provider may prescribe tasks to the patient side application such as recording ECG data, again configured to is very broad claim limitation with no transformation or technical detail. It is not affirmatively recited the devices configure each other but rather that the devices can in fact do the functional limitations claimed thus are configured to.
Further the claim recites, “ wherein configuring the first healthcare monitoring device comprises configuring the first healthcare monitoring device to capture the one or more vital signs at a first capture rate that is higher than a second capture rate at which the first healthcare monitoring device captured the one or more vital signs prior to determining that the patient is in the physiological state” and Petterson teaches in fig. 9B for e.g. and see [0074] and [0075] which 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” thus clearly Petterson does teach that healthcare monitoring device of the previously cited ECG monitor can capture a baseline vital sign which it is configured to do at the broad level recited in the claims and then when the patient is in a stressful physiological state using another capture rate which it is also configured to do. Examiner notes the claims are interpreted under BRI and the claim needs to reflect or recite further limitation on the what and how of the configuration to give it the limited meaning applicant would like.
Applicant further argues, IV. 35 U.S.C. & 103 Rejection Applicant respectfully traverses the rejection under 35 U.S.C. § 103 of claims 16 and 17 as allegedly being unpatentable over Petterson in view of Quinn. See Office Action at 23-27.
Firstly, as discussed above, Petterson fails to teach many elements recited in amended independent claim 1. Applicant respectfully submits that Petterson, Quinn, or any combination of the two fail to disclose or suggest the subject matter recited in amended claim 12. For example, Petterson fails to disclose or suggest at least the subject matter discussed above with respect to the § 102 rejection, and Quinn fails to cure those deficiencies of Petterson. Thus, dependent claims 16 and 17 are allowable at least due to their dependence from amended independent claim 12.
Secondly, the Office acknowledges that Petterson fails to teach the subject matter of dependent claims 16 and 17. See Office Action at 23 and 24. Applicant agrees that Petterson does not teach their subject matter. The Office then alleges Quinn cures these deficiencies of Petterson. See id. Applicant respectfully disagrees. For example, Quinn 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. Quinn at [00022] (emphases added). That is, Quinn discloses that a pause/stop presentation command is possible based on monitoring the subject for such a command. Quinn fails to disclose or suggest that such a command is part of providing a reminder, as recited in dependent claim 16. For at least this additional reason, dependent claim 16 is allowable.
Similarly, Quinn fails to disclose or suggest "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" as recited in dependent claim 17. Instead, Quinn discloses that "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)." Quinn at [00096]. Quinn fails to disclose or suggest that the reminder pauses content (as discussed above) and that presentation of content is restarted in response to receiving an acknowledgement from a remote control associated with a plug-in device as recited in dependent claim 17. For at least this additional reason, dependent claim 17 is allowable.
Accordingly, Applicant respectfully requests the Office withdraw the § 103 rejection of claims 16 and 17.
Examiner appreciates applicants arguments but does not find them persuasive. Quinn teaches in see [00022] which 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.” In which the reminder is the instruction to perform a physical task and the ability to start and stop the healthcare information is clearly present as applicant also agrees, the instant application claim does not limit that the reminder must comprise this start and stop within its data structure but rather that within the functionality of providing the reminder there comprises for the user start and stop ability of media content which in this case is the healthcare content as disclosed in Quinn ( “providing the reminder comprises pausing media content being presented by the media device.”.)
Further in claim 17 which recites “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.” Quinn teaches in [00096] which 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.).”) Quinn clearly teaches reminder for a procedure with commands available to the user which can receive an e.g. “I understand” acknowledgement from the user and include ability by user to modify command in any capacity such as restart command. There is no further recitation in the claim of what the technical bounds are to restarting the presentation just that it happens in response.
Examiner maintains the 35 U.S.C 102/103 rejection.
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 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
