DETAILED ACTION
Claims 1-20 are currently pending and have been examined.
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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 2/13/2026 has been entered.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. §101 because the claimed invention is directed to an abstract idea without significantly more.
Subject Matter Eligibility Criteria - Step 1:
Claims 1-12 & 19-20 are directed to a system (i.e., a machine); Claims 13-18 are directed to a method (i.e., a process).
Subject Matter Eligibility Criteria - Alice/Mayo Test: Step 2A - Prong One:
Regarding Prong One of Step 2A, the claim limitations are to be analyzed to determine whether, under their broadest reasonable interpretation, they “recite” a judicial exception or in other words whether a judicial exception is “set forth” or “described” in the claims. MPEP 2106.04(II)(A)(1). An “abstract idea” judicial exception is subject matter that falls within at least one of the following groupings: a) certain methods of organizing human activity, b) mental processes, and/or c) mathematical concepts. MPEP 2106.04(a).
Independent claim 1 includes limitations that recite at least one abstract idea. Specifically, independent claim 1 recites:
1. A system (100) for remote patient monitoring, comprising:
(a) at least one medical device (10);
(b) a patient remote device (12);
(c) a remote monitoring server device, RMS (14); and
(d) a health care professional, HCP, remote device (16);
wherein the at least one medical device is configured to automatically collect physiological data of a patient and transmit the collected physiological data of the patient to the RMS via the patient remote device; and
wherein the RMS is configured to interface with the HCP remote device via a healthcare professional interface comprising a web-based portal and/or an app-based portal to allow a health care professional to access the collected physiological data of the patient on the RMS,
wherein the system is configured to provide at least one alert to the patient, wherein the at least one alert is indicative of an impacted patient compliance, the at least one alert being triggered by one or more of:
(i) an impedance on a therapeutic electrode being out of range,
(ii) a suspected shift of an implanted lead,
(iii) a usage of a stimulation therapy delivered by the medical device falling below a predefined threshold,
(iv) a battery of the medical device reaching a depletion level,
(v) an MRI mode of the medical device remaining enabled for a predefined period,
(vi)an active therapy program of the medical device changing from a preferred therapy program, or
(vii) an amplitude of the active therapy program dropping below a predefined value for more than a predefined number of days.
The Examiner submits that the foregoing underlined limitations constitute “methods of organizing human activity” because sending healthcare data from various parties, generating and outputting the healthcare data to multiple parties including generating an alert to a patient based on a trigger condition are associated with managing personal behavior or relationships or interactions between people. For example, but for the system, this claim encompasses a person facilitating data access, receiving data, and outputting data in the manner described in the identified abstract idea. The Examiner notes that “method of organizing human activity” includes a person’s interaction with a computer – see MPEP 2106.04(a)(2)(II)(C). If a claim limitation, under its broadest reasonable interpretation, covers managing personal behavior or interactions between people but for the recitation of generic computer components, then it falls within the “method of organizing human activity” grouping of abstract ideas. Accordingly, the claim recites an abstract idea.
Independent claim 19 includes limitations that recite at least one abstract idea. Specifically, independent claim 19 recites:
19. (New) A system (100) for remote patient monitoring, comprising:(a) at least one medical device (10);
(b) a patient remote device (12);
(c) a remote monitoring server device, RMS (14); and
(d) a health care professional, HCP, remote device (16);
wherein the at least one medical device is configured to automatically collect physiological data of a patient and transmit the collected physiological data of the patient to the RMS via the patient remote device,
wherein the RMS is configured to interface with the HCP remote device via a healthcare professional interface comprising a web-based portal and/or an app-based portal to allow a health care professional to access the collected physiological data of the patient on the RMS,
wherein the patient remote device is further configured to interface with the RMS via a patient interface comprising a web-based portal and/or an app-based portal to allow the patient to provide patient-provided data and transmit the patient-provided data to the RMS,
wherein the system is configured to provide at least one alert to the patient, wherein the at least one alert is indicative of an impacted patient compliance, the at least one alert being triggered by one or more of:
(i) an impedance on a therapeutic electrode being out of range,
(ii) a suspected shift of an implanted lead,
(iii) a usage of a stimulation therapy delivered by the medical device falling below a predefined threshold,
(iv) a battery of the medical device reaching a depletion level,
(v) an MRI mode of the medical device remaining enabled for a predefined period,
(vi)an active therapy program of the medical device changing from a preferred therapy program, or
(vii) an amplitude of the active therapy program dropping below a predefined value for more than a predefined number of days.
The Examiner submits that the foregoing underlined limitations constitute “methods of organizing human activity” because sending healthcare data from various parties, generating, outputting the healthcare data to multiple parties, and generating an alert based on a trigger condition are associated with managing personal behavior or relationships or interactions between people. For example, but for the system, this claim encompasses a person facilitating data access, receiving data, and outputting data in the manner described in the identified abstract idea. The Examiner notes that “method of organizing human activity” includes a person’s interaction with a computer – see MPEP 2106.04(a)(2)(II)(C). If a claim limitation, under its broadest reasonable interpretation, covers managing personal behavior or interactions between people but for the recitation of generic computer components, then it falls within the “method of organizing human activity” grouping of abstract ideas. Accordingly, the claim recites an abstract idea.
Accordingly, independent claims 1 & analogous claim 13, and 19 recite at least one abstract idea.
Furthermore, dependent claims 2-12, 14-18, & 20 further narrow the abstract idea described in the independent claims. Claim 4 recites types of patient data; Claims 7-12, 16-17 recites monitoring data and outputting an alert, Claim 18 recites combining different data, and Claim 20 recites interfacing with additional portals, generating reports to different interfaces and generating pain-related data used in a pain assessment plan. These limitations only serve to further limit the abstract idea and hence, are directed towards fundamentally the same abstract idea as independent claim 1 and analogous independent claims 13 & 19, even when considered individually and as an ordered combination.
Subject Matter Eligibility Criteria - Alice/Mayo Test: Step 2A - Prong Two:
Regarding Prong Two of Step 2A of the Alice/Mayo test, it must be determined whether the claim as a whole integrates the abstract idea into a practical application. As noted at MPEP §2106.04(II)(A)(2), it must be determined whether any additional elements in the claim beyond the abstract idea integrate the exception into a practical application in a manner that imposes a meaningful limit on the judicial exception. The courts have indicated that additional elements merely using a computer to implement an abstract idea, adding insignificant extra solution activity, or generally linking use of a judicial exception to a particular technological environment or field of use do not integrate a judicial exception into a “practical application.” MPEP §2106.05(I)(A).
In the present case, the additional limitations beyond the above-noted at least one abstract idea recited in the claim are as follows (where the bolded portions are the “additional limitations” while the underlined portions continue to represent the at least one “abstract idea”):
1. A system (100) for remote patient monitoring, comprising:
(a) at least one medical device (10);
(b) a patient remote device (12);
(c) a remote monitoring server device, RMS (14); and
(d) a health care professional, HCP, remote device (16);
wherein the at least one medical device is configured to automatically collect physiological data of a patient and transmit the collected physiological data of the patient to the RMS via the patient remote device; and
wherein the RMS is configured to interface with the HCP remote device via a healthcare professional interface comprising a web-based portal and/or an app-based portal to allow a health care professional to access the collected physiological data of the patient on the RMS,
wherein the system is configured to provide at least one alert to the patient, wherein the at least one alert is indicative of an impacted patient compliance, the at least one alert being triggered by one or more of:
(i) an impedance on a therapeutic electrode being out of range,
(ii) a suspected shift of an implanted lead,
(iii) a usage of a stimulation therapy delivered by the medical device falling below a predefined threshold,
(iv) a battery of the medical device reaching a depletion level,
(v) an MRI mode of the medical device remaining enabled for a predefined period,
(vi)an active therapy program of the medical device changing from a preferred therapy program, or
(vii) an amplitude of the active therapy program dropping below a predefined value for more than a predefined number of days.
19. (New) A system (100) for remote patient monitoring, comprising:(a) at least one medical device (10);
(b) a patient remote device (12);
(c) a remote monitoring server device, RMS (14); and
(d) a health care professional, HCP, remote device (16);
wherein the at least one medical device is configured to automatically collect physiological data of a patient and transmit the collected physiological data of the patient to the RMS via the patient remote device,
wherein the RMS is configured to interface with the HCP remote device via a healthcare professional interface comprising a web-based portal and/or an app-based portal to allow a health care professional to access the collected physiological data of the patient on the RMS,
wherein the patient remote device is further configured to interface with the RMS via a patient interface comprising a web-based portal and/or an app-based portal to allow the patient to provide patient-provided data and transmit the patient-provided data to the RMS,
wherein the system is configured to provide at least one alert to the patient, wherein the at least one alert is indicative of an impacted patient compliance, the at least one alert being triggered by one or more of:
(i) an impedance on a therapeutic electrode being out of range,
(ii) a suspected shift of an implanted lead,
(iii) a usage of a stimulation therapy delivered by the medical device falling below a predefined threshold,
(iv) a battery of the medical device reaching a depletion level,
(v) an MRI mode of the medical device remaining enabled for a predefined period,
(vi)an active therapy program of the medical device changing from a preferred therapy program, or
(vii) an amplitude of the active therapy program dropping below a predefined value for more than a predefined number of days.
For the following reasons, the Examiner submits that the above identified additional limitations do not integrate the above-noted at least one abstract idea into a practical application.
Regarding the additional limitations of the medical device, remote device, remote server device, healthcare professional remote device, interfaces, web-based portal, app-based portal, the Examiner submits that these limitations amount to merely using computers as tools to perform the above-noted at least one abstract idea (see MPEP § 2106.05(f)).
Regarding the additional limitations of collecting physiological, pain, and sleep data of a patient and transmit the collected physiological, pain, and sleep data of the patient, the Examiner submits that this additional limitation merely adds insignificant extra-solution activity (data gathering; selecting data to be manipulated) to the at least one abstract idea in a manner that does not meaningfully limit the at least one abstract idea (see MPEP § 2106.05(g)) and is conventional as it merely consists of transmitting data over a network (see MPEP § 2106.05(d)(II)).
Thus, taken alone, the additional elements do not integrate the at least one abstract idea into a practical application.
Looking at the additional limitations as an ordered combination adds nothing that is not already present when looking at the elements taken individually. For instance, there is no indication that the additional elements, when considered as a whole with the abstract idea, reflect an improvement in the functioning of a computer or an improvement to another technology or technical field, apply or use the above-noted judicial exception to effect a particular treatment or prophylaxis for a disease or medical condition, implement/use the above-noted judicial exception with a particular machine or manufacture that is integral to the claim, effect a transformation or reduction of a particular article to a different state or thing, or apply or use the judicial exception in some other meaningful way beyond generally linking the use of the judicial exception to a particular technological environment, such that the claim as a whole does not integrate the abstract idea into a practical application of the abstract idea. MPEP §2106.05(I)(A) and §2106.04(II)(A)(2).
For these reasons, independent claims 1, 13 & 19 do not recite additional elements that integrate the judicial exception into a practical application.
Accordingly, the claims recite at least one abstract idea.
The remaining dependent claim limitations not addressed above fail to integrate the abstract idea into a practical application as set forth below:
Claims 2, 20: recites providing interrogation of a medical device, and a motion or acceleration circuit collecting data and do no more than generally link use of the abstract idea to a particular technological environment or field of use without altering or affecting how the at least one abstract idea is performed (see MPEP § 2106.05(h)).
Claims 3, 5: recites a patient interface allowing for access and transmission patient data which merely represent insignificant extra-solution activity (e.g., receiving and transmitting data)(see MPEP § 2106.05(g)) and conventional activities as they merely consist of receiving and transmitting data over a network (see MPEP § 2106.05(d)(II)).
Thus, taken alone, any additional elements do not integrate the at least one abstract idea into a practical application. Therefore, the claims are directed to at least one abstract idea.
Subject Matter Eligibility Criteria - Alice/Mayo Test: Step 2B:
Regarding Step 2B of the Alice/Mayo test, representative independent claim 1 does not include additional elements (considered both individually and as an ordered combination) that are sufficient to amount to significantly more than the judicial exception for reasons the same as those discussed above with respect to determining that the claim does not integrate the abstract idea into a practical application.
As discussed above, regarding the additional limitations of the medical device, remote device, remote server device, healthcare professional remote device, interface, web-based portal, app-based portal, the Examiner submits that these limitations amount to merely using computers as tools to perform the above-noted at least one abstract idea (see MPEP § 2106.05(f)).
Regarding the additional limitations of collecting physiological, pain, and sleep data of a patient and transmit the collected physiological, pain, and sleep data of the patient, the Examiner submits that this additional limitation merely adds insignificant extra-solution activity (data gathering; selecting data to be manipulated) to the at least one abstract idea in a manner that does not meaningfully limit the at least one abstract idea (see MPEP § 2106.05(g)) and is conventional as it merely consists of transmitting data over a network (see MPEP § 2106.05(d)(II)). The Examiner has reevaluated such limitation and determined it to not be unconventional as it merely consists of transmitting data over a network. See MPEP 2106.05(d)(II).
The dependent claims also do not include additional elements (considered both individually and as an ordered combination) that are sufficient to amount to significantly more than the judicial exception for the same reasons to those discussed above with respect to determining that the dependent claims do not integrate the at least one abstract idea into a practical application.
Therefore, claims 1-20 are ineligible under 35 USC §101.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-11, 13-16, & 19 are rejected under 35 U.S.C. 103 as being unpatentable over Mass (US20130310896) in view of Fears (US20050192837).
As per claim 1, Mass teaches a system for remote patient monitoring, comprising:
(a) at least one medical device (para. 38: patient sensor);
(b) a patient remote device (para. 38: patient device);
(c) a remote monitoring server device, RMS (para. 39: remote server); and
(d) a health care professional, HCP, remote device (para. 169: physician device);
wherein the at least one medical device is configured to automatically collect physiological data of a patient and transmit the collected physiological data of the patient to the RMS via the patient remote device (para. 38: patient sensor collects physiological data and transmits data to patient device; device then sends data to remote server);
wherein the RMS is configured to interface with the HCP remote device via a healthcare professional interface comprising a web-based portal (para. 169: physician can access patient physiological data via access to a remote server via website).
wherein the system is configured to provide at least one alert to the patient, wherein the at least one alert is indicative of an impacted patient compliance (para. 392: alert module), the at least one alert being triggered by one or more of:
(i) an impedance on a therapeutic electrode being out of range,
(ii) a suspected shift of an implanted lead,
(iii) a usage of a stimulation therapy delivered by the medical device falling below a predefined threshold,
(iv) a battery of the medical device reaching a depletion level (para. 392-393: battery level is monitored and alert is generated and sent to various users if battery level reaches a depletion level),
(v) an MRI mode of the medical device remaining enabled for a predefined period,
(vi)an active therapy program of the medical device changing from a preferred therapy program, or
(vii) an amplitude of the active therapy program dropping below a predefined value for more than a predefined number of days.
Mass does not expressly teach an app-based portal to allow a health care professional to access the collected physiological data of the patient on the RMS
Fears, however, teaches to a medical device data platform where a server can communicate with information servers associated with various parties including manufacturer servers (para. 68). Fears also teaches to the data sent to different parties comprising different data such as medical device data and objective/subjective physician data (para. 68). Fears also teaches to third parties can access subset database a number of different ways, including, for example, using a database structured query language, using software programs adapted to access the database, or using web pages or applet having embedded database calls (para. 67).
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to combine the aforementioned features in Fears with Mass based on the motivation of provides systems and methods for facilitating access to implantable medical device information (Fears – para. 5).
As per claim 2, Mass and Fears teach the system according to claim 1. Mass teaches wherein the system is configured to provide real-time remote programming and/or interrogation of the at least one medical device using the healthcare professional interface via the patient remote device (para. 65, 86, 110: real-time two way communication allowing for system updates).
As per claim 3, Mass and Fears teach the system according to claim 1. Mass teaches wherein the patient remote device is further configured to interface with the RMS via the patient interface comprising a web-based portal and/or an app-based portal to;
(a) allow the patient to provide patient-provided data and transmit the patient-provided data to the RMS (para. 87: patient device can obtain sensor data from medical device and transmit data to remote server via network interface); and
(b) allow the patient and/or a patient caregiver to access a subset of patient-appropriate data for the patient (para. 329: display allow user to view data).
As per claim 4, Mass and Fears teach the system according to claim 3. Mass teaches wherein the patient-provided data comprises one or more of:
(a) patient-reported remote pain assessment;
(b) patient-reported remote sleep assessment; and
(c) patient-reported symptom data (para. 110: patient can input physiological or other patient related data into computer).
As per claim 5, Mass and Fears teach the system according to claim 1. Mass teaches wherein the patient remote device is configured to provide interrogation of diagnostic device data of the at least one medical device and transmit the diagnostic device data to the RMS (para. 87: patient device can obtain sensor data from medical device and transmit data to remote server via network interface).
Mass does not expressly teach wherein the RMS (16) is configured to interface with a manufacturer support via a manufacturer support interface comprising a second web-based portal and/or app-based portal.
Fears, however, teaches to a medical device data platform where a server can communicate with information servers associated with various parties including manufacturer servers (para. 68). Fears also teaches to the data sent to different parties comprising different data such as medical device data and objective/subjective physician data (para. 68). Fears also teaches to third parties can access subset database a number of different ways, including, for example, using a database structured query language, using software programs adapted to access the database, or using web pages or applet having embedded database calls (para. 67).
The motivations to combine the above mentioned references are discussed in the rejection of claim 1, and incorporated herein.
As per claim 6, Mass and Fears teach the system according to claim 5. Mass does not expressly teach wherein the RMS is configured to allow the manufacturer support interface to access the collected physiological data of the patient and/or the diagnostic device data of the at least one medical device.
Fears, however, teaches to a medical device data platform where a server can communicate with information servers associated with various parties including manufacturer servers (para. 68). Fears also teaches to the data sent to different parties comprising different data such as medical device data and objective/subjective physician data (para. 68).
The motivations to combine the above mentioned references are discussed in the rejection of claim 1, and incorporated herein.
As per claim 7, Mass and Fears teach the system according to claim 5. Mass teaches wherein the RMS is configured to:
(a) monitor the collected physiological data of the patient and/or patient-provided data and to generate the at least one alert, the at least one alert being further indicative of a likely change in the patient's health or mental wellbeing upon an occurrence of one or more pre-set triggers (para. 295-286: patient data is monitored and compared against thresholds; if threshold is reach alert is generated); or
(b) monitor the diagnostic device data and to generate the at least one alert, the at least one alert being further indicative of a likely impacted patient compliance upon an occurrence of one or more pre-set triggers.
As per claim 8, Mass and Fears teach the system according to claim 7. Mass teaches wherein the one or more pre-set triggers are configurable via the healthcare professional interface and/or the manufacturer support interface (para. 285: thresholds for alerts can be adjusted via remote programming).
As per claim 9, Mass and Fears teach the system according to claim 8. Mass teaches wherein the one or more pre-set triggers are configurable on a per patient basis or a per patient group basis (para. 286: flexible alerts can be dynamically changed; and group of alerts can be configured for different patient condition groups); or
wherein the one or more pre-set triggers are configurable for a destination of the generated at least one alert.
As per claim 10, Mass and Fears teach the system according to claim 7. Mass teaches wherein the RMS is configured to generate the alert with a level of priority (para. 355: alerts can be categorized based on criticality of event).
As per claim 11, Mass and Fears teach the system according to claim 7. Mass teaches wherein the one or more pre-set triggers are initially configurable via the healthcare professional interface (para. 286: thresholds for alerts can be adjusted via remote programming); and
wherein the RMS is configured to continuously update the one or more pre-set triggers based on a need of the patient (para. 285-286: thresholds for alerts can dynamically be adjusted based on type of condition detected).
Claims 13-15 recites substantially similar limitations as those already addressed in claim 1, and, as such, is rejected for similar reasons as given above.
As per claim 16, Mass and Fears teach the method of claim 13. Mass teaches the method further including:(a) setting a pre-set trigger using the HCP remote device, the pre-set trigger being configured to notify an HCP upon an occurrence of a patient event occurring (para. 286, 392: alert threshold triggers stored in system; alert communicated to other party);
(b) autonomously monitoring for the occurrence of the patient event based on the pre- set trigger using artificial intelligence (para. 339: system monitors patient condition using various algorithms); and
(c) notifying the HCP upon the occurrence of the patient event (para. 286, 392: alert threshold triggers stored in system; alert communicated to other party).
As per claim 19, Mass teaches a system for remote patient monitoring, comprising:
(a) at least one medical device (10) (para. 38: patient sensor);
(b) a patient remote device (12) (para. 38: patient device);
(c) a remote monitoring server device, RMS (14) (para. 39: remote server); and
(d) a health care professional, HCP, remote device (16) (para. 169: physician device);
wherein the at least one medical device is configured to automatically collect physiological data of a patient and transmit the collected physiological data of the patient to the RMS via the patient remote device (para. 38: patient sensor collects physiological data and transmits data to patient device; device then sends data to remote server), wherein the RMS is configured to interface with the HCP remote device via a healthcare professional interface comprising a web-based portal to allow a health care professional to access the collected physiological data of the patient on the RMS (para. 169: physician can access patient physiological data via access to a remote server via website),
wherein the patient remote device is further configured to interface with the RMS via a patient interface comprising a web-based portal and/or an app-based portal to allow the patient to provide patient-provided data and transmit the patient-provided data to the RMS (Fig. 11; para. 38, 347: patient sensor collects physiological data and transmits data to patient device; device then sends data to remote server via web interface),
wherein the system is configured to provide at least one alert to the patient, wherein the at least one alert is indicative of an impacted patient compliance (para. 392: alert module), the at least one alert being triggered by one or more of:
(i) an impedance on a therapeutic electrode being out of range,
(ii) a suspected shift of an implanted lead,
(iii) a usage of a stimulation therapy delivered by the medical device falling below a predefined threshold,
(iv) a battery of the medical device reaching a depletion level (para. 392-393: battery level is monitored and alert is generated and sent to various users if battery level reaches a depletion level),
(v) an MRI mode of the medical device remaining enabled for a predefined period,
(vi)an active therapy program of the medical device changing from a preferred therapy program, or
(vii) an amplitude of the active therapy program dropping below a predefined value for more than a predefined number of days.
Mass does not expressly teach wherein the RMS is configured to interface with the HCP remote device via a healthcare professional interface comprising an app-based portal to allow a health care professional to access the collected physiological data of the patient on the RMS.
Fears, however, teaches to a medical device data platform where a server can communicate with information servers associated with various parties including manufacturer servers (para. 68). Fears also teaches to the data sent to different parties comprising different data such as medical device data and objective/subjective physician data (para. 68). Fears also teaches to third parties can access subset database a number of different ways, including, for example, using a database structured query language, using software programs adapted to access the database, or using web pages or applet having embedded database calls (para. 67).
The motivations to combine the above mentioned references are discussed in the rejection of claim 1, and incorporated herein.
Claim 12 is rejected under 35 U.S.C. 103 as being unpatentable over Mass (US20130310896) in view of Fears (US20050192837) as applied to claim 7 above, and in further view of Reiner (US20170068792).
As per claim 12, Mass and Fears teach the system according to claim 7, wherein data is output via the manufacturer support interface (Mass - para. 204: customer service dashboard interface allows customer service personnel to collect data from the medical device)
Mass and Fears do not expressly teach wherein the RMS is configured to generate a ticket upon an occurrence of one or more pre-set triggers and to share the ticket amongst a plurality of manufacturer support users.
Reiner, however, teaches to providing for automated alert detection upon identification of abnormal device data and communicating the data with other parties including manufacturer (para. 198-199).
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to combine the aforementioned features in Reiner with Mass and Fears based on the motivation of enable the creation, recording, storage, communication, analysis, and reporting of standardized quality and safety metrics throughout the medical device life span (Reiner – para. 22).
Claim 17 is rejected under 35 U.S.C. 103 as being unpatentable over Mass (US20130310896) & Fears (US20050192837) as applied to claim 16 above, and in further view of Myers (US20170132383).
As per claim 17, Mass & Fears teach the method of claim 16, but do not expressly teach the method further including autonomously updating the pre-set trigger using artificial intelligence.
Myers, however, teaches to automated rule generation and discovery for detection of health state changes where a system uses machine learning to update alert thresholds for patient parameter detection (para. 38).
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to combine the aforementioned features in Myers with Mass & Fears based on the motivation of allow for automatic updates or generation of new rules or thresholds to improve detection accuracy (Myers – para. 4).
Claims 18 & 20 are rejected under 35 U.S.C. 103 as being unpatentable over Mass (US20130310896) and Fears (US20050192837) as applied to claims 1 & 13 above, and in further view of Sterner (US20210050098).
As per claim 18, Mass and Fears teach the method of claim 13, but do not expressly teach combining subjective data and objective data to thereby simultaneously be displayed on the healthcare professional interface.
Sterner, however, teaches to displaying various dashboards to a physician via an interface and where the dashboards display a visual representation of different patient data or different subsets of patient data (para. 47).
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to combine the aforementioned features in Sterner with Mass and Fears based on the motivation of providing methods and systems for monitoring and utilizing patient health data to improve patient outcomes (Sterner – para. 2).
As per claim 20, Mass and Fears teach the system of claim 1, wherein the RMS (16) is configured to interface with a manufacturer support via a manufacturer support interface comprising a second web-based portal and/or app- based portal (Fears – para. 68: a medical device data platform where a server can communicate with information servers associated with various parties including manufacturer servers; data sent to different parties comprising different data such as medical device data and objective/subjective physician data), and
wherein the system is configured to issue a first report to the healthcare professional interface and a second report to the manufacturer support interface, wherein the first report and the second report are different and are each based on the collected physiological data (Fears – para. 68: a medical device data platform where a server can communicate with information servers associated with various parties including manufacturer servers; data sent to different parties comprising different data such as medical device data and objective/subjective physician data);
wherein the at least one medical device is configured to initiate the collection of the physiological data of the patient via the patient remote device, the healthcare professional interface, and the manufacturer support interface (Fears – para. 52-53, 68: implanted medical device data is uploaded to communication network via mobile device; data is sent to various systems). Mass and Fears do not expressly teach the system further comprising a motion and/or acceleration detection circuit, wherein the motion and/or acceleration detection circuit is configured to generate an output to be included in pain related data, the pain related data including pre-treatment pain related data and post-treatment pain related data, the pain related data to be used for a pain assessment of the patient, the pain assessment being based at least in part on a comparison of the pre-treatment pain related data to the post-treatment pain related data.
Sterner, however, teaches to collecting patient and sensor data and calculating pain benchmarks pre surgery and post surgery based on the patient and sensor data (para. 16, 41, 48). Sterner also teaches to outputting the pain score to the physician via an interface (para. 47). Sterner also teaches to the pain score data may be collected over time, such that the aggregate benchmark pain score for knee replacement surgery may be a trend line over a period of time, e.g., pre-surgery to 90 days post-surgery (para. 48).
The motivations to combine the above mentioned references are discussed in the rejection of claim 13, and incorporated herein.
Response to Arguments
Applicant’s arguments with respect to the 35 U.S.C. § 101 rejection on pages 9-11 in regards to claims 1-20 have been considered but are not persuasive.
Applicant argues that the claims go beyond organizing human activity and the analysis should not extend beyond Step 2A Prong One.
The Examiner, however, asserts that MPEP 2106.04(a)(2)(II) recites that 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. The Examiner argues that Applicant’s claims amount to the same situation where certain activity between a person and a computer is recited and therefore the claims recite an abstract idea as described above.
Similar to BASCOM, the claims recite a non-conventional and non-generic arrangement of known, conventional pieces and is therefore a practical application.
The Examiner asserts that the Applicant’s claims are not analogous to BASCOM. In BASCOM the court held that the claims amounted to statutory subject matter under step 2B because the additional elements within the claims were directed to a particular arrangement that yielded a technical improvement to the technology of filtering content. Specifically, the particular arrangement of the additional elements of controlled network access accounts, a local client computer, an Internet computer network, and a remote ISP server, provided an unconventional combination of elements based on the installation of a filtering tool at a specific location within the network, remote from the end-users, with customizable filtering features specific to each end user, where the filtering tool at the ISP was able to identify individual accounts that communicate with the ISP server and associate a request for Internet content with a specific individual account. It explained that this yielded a technical improvement because this particular arrangement of the known elements offered both the benefits of a filter on the local computer and the benefits of a filter on the ISP server. The court pointed to the disclosure of the application which explained why and how the particular claimed arrangement of these elements yielded the asserted technological improvement. No such unconventional and non-generic arrangement of otherwise known computer elements is argued with respect to the present claims, and Examiner asserts that the present claims do not satisfy the rationale provided by the court. Claim 1 for example recites a medical device, remote device, remote server device, healthcare professional remote device, interfaces, web-based portal, app-based portal. In contrast to the claims in BASCOM however, these additional elements are not arranged in an unconventional and non-generic combination but instead are arranged, and used, in well-known, routine and conventional fashion(s). Additionally, each of these elements individually performs its well-understood, routine and conventional function. This remains true when the elements are viewed as an ordered combination. Each of the elements still performs its well-understood, routine and conventional function in relation to the other elements. The relationship between each of these elements and their respective functions remain those of generic computer devices. As such, the Examiner respectfully submits that the Applicant’s claims are not analogous to those found to be patent eligible in BASCOM.
Applicant’s arguments with respect to the 35 U.S.C. § 103(a) rejection on pages 11-14 in regards to claims 1-20 have been considered but are moot in view of the new ground(s) of rejection.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Hoyme (US20070299317) teaches to providing ad hoc programming of operational characteristics of patient medical devices that are remotely monitored to permit flexible selection of and control over collection of patient data in light of available and limited on-board patient medical device resources.
Mazar (US20040128161) teaches to a method and system for communicating with an implantable medical device that can communicate with the device in real-time so that device measurements and device adjustments may be practiced remotely by a clinician or physician.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Jonathan K Ng whose telephone number is (571)270-7941. The examiner can normally be reached M-F 8 AM - 5 PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Anita Coupe can be reached at 571-270-7949. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/Jonathan Ng/ Primary Examiner, Art Unit 3619