DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of the Claims
The status of the claims as of the response filed 02/02/2026, is as follows:
Claims 16, 18-23, and 24-31 are pending.
Claims 17 is canceled
The applicant has amended Claims 16, 19 and 24.
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 02/02/2026 has been entered.
Response to Arguments
35 USC 101 Rejection
Applicant’s arguments, see page 10-15, filed 02/02/2026, with respect to amended Claims 16, 9 and 24 are amended, claims 16, 18-23, and 24-31 are pending, have been fully considered and are not persuasive, 35 USC 101 rejection is maintained, for the reasons below.
Applicant argues that Claims 16 and 24, including the workflow that “access[es]” manufacturer information, “analyze[s]” the information using rules, determines whether a sensor event “is relevant for diagnosis,” provides a label, and filters a first alert, are not properly rejected as reciting a certain method of organizing human activity because reducing clinician workload and using patient-derived data do not, by themselves, organize human behavior or interpersonal activity.
The Examiner respectfully disagreed because Applicant's arguments unpersuasive because Claims 16 and 24, under the Broadest Reasonable Interpretation, recite a mental process rather than a specific technological mechanism. The claims involve accessing manufacturer information, applying clinical rules, determining medical relevance, assigning labels, and filtering alerts, a sequence of observation and decision-making that does not overcome the mental-process rationale. As a result, the rejection is moot based on the mental-process characterization, rather than organizing human activity, for compact prosecution.
Applicant argues that Claims 16 and 24, especially “providing the output to an interface and causing the interface to provide a notification, without providing the first alert to the interface and without causing the interface to provide a first alert notification based on the first alert,” are directed to a practical technological improvement because selective filtering at the interface improves clinician workflow, analogous to BASCOM, DDR, Core Wireless, and CardioNet.
The Examiner respectfully disagreed because, under BRI, Claims 16 and 24 recite that the system analyzes manufacturer information, determines diagnostic relevance, labels the information, and then sends the resulting output to an interface while withholding a first alert from that interface and from a first-alert notification; thus, the claim language makes the interface a destination for the result of the mental-process triage, not a specifically recited mechanism that changes how the interface itself functions. The critical claim point is that the claims recite what information is suppressed and what notification is not sent, but they do not recite how the interface is technically structured, modified, or improved to achieve that result, which not match to BASCOM, DDR, Core Wireless, and CardioNet.
The examiner found Applicant’s position not persuasive because the cited case law turned on claims that recited a specific technological arrangement or interface implementation, while Claims 16 and 24, as actually written and reasonably construed, recite selective communication of an already-determined result. Therefore, the rejection is maintained.
Applicant argues that Claims 16 and 24, particularly “performing filtering of a first alert … and providing the output to an interface and causing the interface to provide a notification, without providing the first alert to the interface and without causing the interface to provide a first alert notification based on the first alert,” are no longer merely post-solution activity because the amendment allegedly “transform[s] data in order to reduce the overall transmission load” and therefore integrates the judicial exception into a practical application.
The Examiner respectfully disagreed, emphasizing that although amended Claims 16 and 24 specify analyzing manufacturer information, assigning a label, filtering a first alert, and sending the output to an interface, they do not recite a concrete technical mechanism for reducing transmission load or improving the interface itself. While Applicant references reduced alert generation and interface details, MPEP 2106 requires such improvements to be explicitly claimed, and here the claims remain focused on selective presentation rather than a particular technological solution. As a result, the Examiner found Applicant’s position unpersuasive, and the rejection is maintained.
35 USC 112(d) Rejection
Applicant’s arguments, see page 15-16, filed 02/02/2026, with respect to amended Claims 16, 9 and 24 are amended, claims 16, 18-23, and 24-31 are pending, have been fully considered and are persuasive, 35 USC 112(d) rejection is withdraw.
Applicant argues that Claim 19 is no longer subject to rejection under 35 U.S.C. § 112(d) because Applicant amended the claim “to correct the noted informalities, specifically by correcting the dependency of this claim.”
The Examiner respectfully agreed because Applicant’s amendment corrected Claim 19’s dependency, directly resolving the § 112(d) rejection which was based solely on improper claim form.
35 U.S.C. § 102/103 Rejection
Applicant’s arguments, see page 16-23, filed 02/02/2026, with respect to amended Claims 16, 19 and 24 are amended, claims 16, 18-23, and 24-31 are pending, have been fully considered, 35 U.S.C 102 rejection was withdrawn in view that amended claims is not anticipated by Gunderson, however was submitted a 35 U.S.C 103 rejection. Refer to answer below for further details.
The applicant argues that the claimed "first type rule" requires simultaneously "combining two distinct sources of information: sensor data from the AIMD and clinical information external to the device." They assert Gunderson lacks this specific conditional analysis and instead only teaches a generic data threshold or sorting rule.
The examiner disagreed because, Gunderson teaches a rule-based diagnostic framework where device-derived event data is evaluated using predefined metric conditions and patient-specific clinical context, and Table 1 shows a concrete combined event-plus-clinical-status rule. Refer to par. 0027-0028, 0042-0043, 0058, 0077-0079, 0105, 0119-0123,0152, 0165-0167, table 1, fig. 11 and for further details 35 U.S.C 103 rejection below.
Applicant argues that Claim 16, "verify a medical relevance of each of the at least one alert received from the manufacturer information" is not properly rejected because Gunderson does not apply a verification step to an already-received alert.
The Examiner respectfully agreed because under proper BRI, Claim 16 requires executing a rule to evaluate the diagnostic significance of a device alert that has already been received, whereas Gunderson applies its thresholds to raw patient data to initially generate the alert. The examiner found the applicant’s position persuasive regarding Gunderson's isolated teachings; however, because the current 35 U.S.C. § 103 rejection specifically incorporates Bharmi to teach applying a clinical risk-verification rule to an existing device alert (Bharmi, par. [0037]), this specific deficiency is fully cured.
Applicant argues that Claim 16, "verify a medical relevance" is not properly rejected because Gunderson’s reporting characteristics merely control display organization and priority (e.g., sorting) rather than actively assessing if an alert is clinically valid or relevant.
The Examiner respectfully disagreed because under proper BRI, Claim 16, "verify a medical relevance" encompasses evaluating the clinical priority or severity of data to determine if medical intervention is required. The record shows Gunderson uses reporting characteristics to define an "urgency, type of action to take" (par. [0045]) and to "triage patients" indicating "urgent attention by the clinician is necessary" (par. [0062]). The examiner found the applicant’s position not persuasive because actively assigning clinical urgency and triage actions directly constitutes assessing medical relevance; regardless, since Bharmi is used to apply relevance verification to an already-received alert, the argument against Gunderson alone is moot. Therefore, the rejection is maintained.
Identification Applicant argues that Claim 16, "the first type rule being defined in order to verify a medical relevance..." is not properly rejected because Gunderson’s paragraph [0028] merely defines a composite metric label (e.g., "primary-prevention patient") rather than performing an active analysis to determine clinical relevance.
The Examiner respectfully disagreed because under proper BRI, a computer system cannot output a combined, condition-specific metric without actively executing an underlying logical analysis step. The record shows Gunderson’s system must actively evaluate "sensed data... and stored information indicating the patient as a primary prevention patient" to output the specific event (par. [0028]). The examiner found the applicant’s position not persuasive because generating this context-specific metric conditional logic rule; furthermore, Bharmi explicitly teaches executing an Application Specific Model to analyze an incoming alert against clinical data, rendering the isolated attack on Gunderson moot.
Applicants argue that Claim 16, "said analysis comprising applying each first type rule to determine whether the corresponding predefined first sensor event has occurred and is relevant for diagnosis" is not properly rejected because Gunderson uses raw thresholding and sorting rather than applying a rule that makes a true medical evaluation of diagnostic significance.
The Examiner respectfully disagreed because under proper BRI, Claim 16, "determine whether the corresponding predefined first sensor event has occurred and is relevant for diagnosis" encompasses using conditional logic (like a threshold) to filter out clinically insignificant data. The record shows Gunderson teaches that "only diagnostic metrics exceeding a threshold may indicate that the patient requires attention... thus generate the patient management report that includes the diagnostic metrics having a value that exceeds the respective threshold" (par. [0120]). The examiner found the applicant’s position not persuasive because using a threshold rule to selectively exclude irrelevant events from a clinician's diagnostic report evaluates its diagnostic relevance; furthermore, Bharmi explicitly teaches analyzing the alert to determine the actual diagnostic "risk of at least one of hemolysis or thrombosis" (Bharmi, par. [0037]), rendering the isolated attack on Gunderson moot.
Applicant argues that Claim 16, "relevant for diagnosis" is not taught by Gunderson’s "reporting characteristics" because they merely define display and organizational parameters (e.g., urgency) rather than determining if an alert is medically valid.
The Examiner respectfully disagreed because under proper BRI, Claim 16, "relevant for diagnosis" broadly includes determining the clinical urgency, severity, or triage priority of a medical event. The record shows Gunderson uses reporting characteristics to dictate "urgency" and to "triage patients" when metrics "indicate urgent attention by the clinician is necessary" (pars. [0045], [0062]). The examiner found the applicant’s position not persuasive because actively evaluating an event to assign clinical urgency and trigger triage actions directly constitutes an assessment of its medical relevance, and the secondary reference Bharmi further teaches verifying clinical diagnostic risk, rendering the
Applicant argues that Claim 16, "at least one output adapted to provide data representative of at least one labeled manufacturer information for diagnosis taking account of the predefined first sensor event occurrence and relevancy" is not properly rejected because Gunderson lacks an output that reflects a post-analysis verification of medical relevance.
The Examiner respectfully disagrees with Applicant’s position because, under the Broadest Reasonable Interpretation (BRI), the claim does not require the "label" to be a specific clinical narrative, but rather a data state that distinguishes the information based on its medical significance. Gunderson already teaches outputs that are diagnostically relevant because it filters data using thresholds so only clinically significant events are reported, integrates sensor data with stored clinical context to produce labeled diagnostic metrics, and assigns urgency levels to triage patients. Taken together under BRI, these disclosures satisfy outputs that are labeled and generated based on the relevancy of sensor events for diagnosis. . (Gunderson, paragraphs 0004, 0006, 0026, 0060, 0105, 0120, 0130, 0157)
Applicant argues that Gunderson does not disclose an output providing "labeled manufacturer information" because the Office Action failed to identify data specifically derived from a manufacturer. Applicant contends that the only manufacturer-related disclosure in Gunderson involves a setting for report delivery frequency (par. [0062]), which is an external control parameter rather than the "manufacturer information" (device measurements/parameters) required by the claim to be incorporated into the output.
The Examiner respectfully disagrees because the Applicant's argument ignores the explicit definition of "manufacturer information" provided within the preamble and body of Claim 16. Under the Broadest Reasonable Interpretation (MPEP 2111), the claim defines this term as "comprising a plurality of measurements recorded by the at least one sensor of the AIMD or a plurality of parameters calculated by the device manufacturer's platform." Gunderson teaches this exact element by disclosing that the triage module receives and analyzes "sensed or detected parameters from IMD 16" (Gunderson, par. [0119]) to generate the output report (par. [0120]). Therefore, the system's output of diagnostic metrics derived from these device sensors constitutes the claimed "labeled manufacturer information," and the rejection is maintained.
Applicant argues that Claim 16, "performing filtering of a first alert... that removes the first alert from the output" is not properly rejected because Gunderson only discloses manual, user-driven display management (e.g., hiding or archiving reviewed metrics) rather than semantic and algorithmic filtering by the system.
The Examiner respectfully agrees that Gunderson alone fails to teach algorithmic suppression of an existing alert based on clinical context, as Gunderson’s removal of data relies on a clinician marking a report as "reviewed" (Gunderson, par. [0162]). However, the Applicant’s argument is not persuasive in overcoming the submitted 35 U.S.C. § 103 rejection because the combination with Bharmi specifically provides the missing automated "logic gate." Therefore argument is now smoot.
The Applicant argues that the dependent claims are patentable because the prior art allegedly fails to teach a “first type rule” that verifies medical relevance by jointly analyzing sensor and clinical data to reduce alert burden. The Examiner disagrees, finding that the combination of Gunderson and Bharmi, under BRI, already teaches automated filtering that verifies clinical relevance through triage, contextual analysis, and suppression of low-risk alerts. Bharmi in particular discloses rule-based logic that evaluates device alerts against clinical context and suppresses irrelevant alerts before output, directly addressing the claimed reduction in burden. Because the dependent claims rely solely on unpersuasive arguments tied to the rejected independent claims, their rejections are properly maintained.
Applicant argues that Claims 16 and 24 are patentable because Gunderson fails to teach a "first type rule" that verifies the medical relevance of an already-received alert by simultaneously evaluating sensor events and external clinical information. Applicant asserts that Gunderson’s thresholds merely trigger alert generation from raw data, rather than performing a semantic, system-driven filtering of existing alerts to reduce clinician burden.
The Examiner respectfully disagrees because while Gunderson provides the triage framework, the combination with Bharmi specifically teaches an Application Specific Model that "analyzes" a received device alert alongside clinical "AF burden" to verify medical risk (Bharmi, par. [0037]). Therefore argument is moot under submitted 35 U.S.C. § 103.
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 16, 18-23, and 24-31 are rejected under 35 U.S.C. § 101. The claims are directed to a judicial exception an abstract idea and lack additional elements that either integrate the idea into a practical application or provide an inventive concept amounting to significantly more than the idea itself.
Step 1: Statutory Categories Analysis
The claims are directed to statutory subject matter, encompassing the following statutory categories:
Machine (Claims 16, 18-23): The language reciting "A system for managing information... comprising: a server comprising at least one processor" describes a concrete thing consisting of parts, aligning with the definition of a machine in MPEP § 2106.03.
Process (Claims 24-30): The language reciting "A computer-implemented method for managing information... comprising... accessing... analyzing" defines a series of acts or steps, aligning with the definition of a process in MPEP § 2106.03.
Manufacture (Claim 31): The language reciting "A non-transitory computer-readable storage medium" describes a tangible article given a new form through artificial efforts, aligning with the definition of a manufacture in MPEP § 2106.03.
Having confirmed the claims are directed to statutory subject matter, the analysis proceeds to Step 2A.
Step 2A, Prong One: Judicial Exception Analysis
The claims are directed to a judicial exception because they recite an abstract idea.
Independent Claims Analysis
Claim 16: A system for managing information relating to at least one patient with an active implantable medical device (AIMD) comprising at least one sensor and communicatively coupled to a device manufacturer's platform, said system comprising: a server comprising at least one processor configured to: access, from the device manufacturer's platform, at least one manufacturer information...; analyze the received at least one manufacturer information based on at least one first type rule... to verify a medical relevance of the at least one alert... said analysis comprising applying each first type rule... in order to determine... whether the corresponding predefined first sensor event has occurred and is relevant for diagnosis; provide at least one label associated to the at least one manufacturer information based on a result of said analysis; ... wherein the server is comprised into a cloud-based service; at least one output adapted to provide data representative of at least one labeled manufacturer information... comprising, based on the at least one label, performing filtering of a first alert...
and providing the output to an interface and causing the interface to provide a notification, without providing the first alert to the interface and without causing the interface to provide a first alert notification based on the first alert.
Note: The bolded portions represent additional elements evaluated in Prong Two and Step 2B. The non-bolded portions represent the abstract idea. References from the specification US20240194311A1.
Independent Claims Classification Rational:
Under the broadest reasonable interpretation, Claims 16 and 24 functionally recite a workflow that first obtains AIMD-related information and alert information from a manufacturer platform, then applies one or more rules that use both the sensor-event information and the patient’s clinical information to decide whether an event is medically relevant for diagnosis, then assigns a label reflecting that decision, and finally outputs the labeled information while excluding a selected alert from the presented output and resulting notification. The independent claims language: gathers patient-device output and alerts; it compares that information against stored decision criteria and clinical context; it reaches a relevance determination and labels the information accordingly; and it presents a filtered result in which a first alert is withheld from interface presentation and alert-specific notification. The invention aims to “drastically reduce the amount of data destined to further processing, [par. 0016]” and to reduce alert burden on medical staff, which is consistent with the claims’ functional focus on reviewing incoming device information, deciding what matters, and suppressing what does not. Claim 31 does not add a different functional operation at Prong One because it merely packages instructions for carrying out the same method recited in Claim 24.
When those steps are compared to the abstract-idea groupings, the best fit is a mental process, because the core is reviewing information, applying rules, determining relevance, labeling, and deciding whether to present or suppress an alert, which are acts of observation, evaluation, judgment, and opinion. A useful analogy is a cardiac nurse who receives a device report and a patient chart, checks whether an AFib alert occurred during a clinically explained circumstance such as anticoagulant treatment, marks the alert as not diagnostically important, and prepares a summary for the physician that omits that alert; the claims mirror that same cognitive triage process, except stated as being carried out with generic computer implementation. Accordingly, Claims 16, and 24 recite a judicial exception in the form of a mental process at Step 2A, Prong One.
Dependent Claims Analysis
The dependent claims are also directed to abstract ideas, either by inheriting the Mental Process of the independent claims or by adding further abstract concepts.
(Claims 18, 23): These claims add steps of recording, exploiting, and notifying. While inheriting the underlying Mental Process, the "notifying" step introduces a further abstract idea: Certain Methods of Organizing Human Activity (MPEP § 2106.04(a)(2)(II)). Notifying is an interaction between people (e.g., a clinician informing another), which falls into the sub-category of managing relationships or interactions.
(Claims 19-20, 25-26, 30): These claims recite specific rules for the analysis, such as "comparing each time stamp to the drug intake time interval." This is a Mental Process, as it merely specifies the particular logic a human would use in the evaluation. These claims inherit the abstract idea of the independent claim by narrowing the focus of the mental steps.
(Claims 21, 29): These claims recite specific data points for the analysis, like "age, sex, medical scores." These claims inherit the abstract idea of the independent claims, as merely specifying the information being mentally processed does not change the nature of the process itself.
(Claims 22, 27-28): These claims recite applying a "second type rule" to determine if a "predefined second sensor event" has occurred. This describes an additional layer of data analysis, which is a Mental Process.
Step 2A, Prong Two: Integration into a Practical Application
The claims fail to integrate the abstract idea into a practical application because the additional elements merely provide a generic technological environment for the abstract idea.
Evaluation of Additional Elements (Independent Claims)
(Generic Computer Components): The recitation of a "server comprising at least one processor" (Claim 16), "computer-implemented method" (Claim 24), and a "non-transitory computer-readable storage medium" (Claim 31) fails to integrate the abstract idea because it:
(MPEP § 2106.05(f)): Reciting an abstract idea and instructing one to "apply it" on a computer is not an inventive application. The claims simply take the mental process of data analysis and state it will be performed by generic computing components.
(MPEP § 2106.05(a)): A claim that does not improve the functioning of a computer or any other technology is not a patent-eligible application of an abstract idea. These components are used in their normal capacity to process and store data.
(Generic Technological Environment): Reciting a "cloud-based service" (Claim 16) and an "output" (Claim 16) fails to integrate the abstract idea because it:
(MPEP § 2106.05(h)): Merely linking the use of an abstract idea to a particular technological environment is not enough for integration. The use of a "server," "cloud," or "output" only confines the abstract mental steps to a generic and ubiquitous technological setting.
(Insignificant Activity): The steps of "accessing" data from a "device manufacturer's platform" (Claims 16, 24) and "outputting" data (Claims 16, 24) fail to integrate the abstract idea because:
(MPEP § 2106.05(g)): Adding insignificant pre-solution or post-solution activity does not transform an abstract idea into a practical application. The "accessing" of data from a specified platform is mere pre-solution data gathering, and the "outputting" is insignificant post-solution display of the result. The platform is simply the source of the data, not a part of a practical application of the analysis.
With respect to the interface recited in claims 16 and 24, this additional element, viewed individually, does not integrate the mental process into a practical application because the claims only require providing the output to an interface and causing the interface to provide a notification, which uses the interface as a generic destination for the result of the analysis rather than reciting a particular technical mechanism for how the interface operates or is improved; claims that amount to no more than an instruction to apply the abstract idea using a generic computer do not render the abstract idea eligible, and the claim must reflect the asserted improvement itself, not merely state the desired result.
Combination Analysis:
When viewed as a whole, the combination of these elements does not integrate the abstract idea. The claims describe a generic computer system performing the abstract analysis of determining medical relevance, which fails to transform the abstract idea into a patent-eligible application.
Dependent Claims Analysis
The dependent claims add limitations that also fail to provide the necessary integration.
(Claims 19 and 23): These claims introduce a "remote monitoring platform" as the medium for notification. This element fails to integrate the abstract idea. The specification defines this platform in broad, functional terms as "any system for data management configured to receive and store and/or analyze data" (Spec., para. [0057]). This is the definition of a generic data management system. Using such a platform for notification is merely linking the abstract idea to a particular technological environment (h) and represents insignificant post-solution activity (g), as it only specifies the conduit for the result of the abstract analysis. It does not change the nature of the abstract process itself.
(Claims 18, 20-22, 25-30): These claims do not introduce new additional elements that could integrate the abstract idea. Instead, they add specific types of data or rules. This is a mere field-of-use limitation (h). Confining the abstract idea to the specific context of atrial fibrillation or particular drugs, or adding another layer of abstract rules, does not integrate the idea into a practical application. These limitations only narrow the scope of the abstract mental steps.
Conclusion: Because the claims are directed to an abstract idea without integrating it into a practical application alone and in combination, the analysis proceeds to Step 2B.
Step 2B: Inventive Concept Analysis
The claims lack an inventive concept because the additional elements do not amount to significantly more than the judicial exception itself.
Evaluation of Additional Elements (Independent Claims)
(Generic Computer Components):
(MPEP § 2106.05(f) - Mere Instructions): The claims simply instruct the performance of the abstract idea on generic hardware. The specification describes these components in broad, functional terms, defining a "Processor" as potentially "a computer, a microprocessor, an integrated circuit, or a programmable logic device" (Spec., para. [0054]), confirming their generic nature.
(MPEP § 2106.05(a) - No Tech Improvement): The claims do not improve computer functionality; they merely use the computer as a tool. The invention's purpose is to automate a human task, as it is "advantageous for reducing the workload of healthcare providers" (Spec., para. [0002]), not to enhance the server or cloud platform itself.
(Insignificant Activity):
(MPEP § 2106.05(g) - Insignificant Activity): The hardware performs generic data input/output. The step of accessing data from a "device manufacturer's platform" is a generic data-gathering step.
(MPEP § 2106.05(d) - Well-Understood, Routine, Conventional): Servers, processors, and cloud services are ubiquitous, off-the-shelf components used for their intended purpose. The specification confirms this by stating the system "may... have functions distributed over a cloud infrastructure" (Spec., para. [0084]). Furthermore, using a device manufacturer's platform as the source for AIMD data is the standard, conventional way this information is handled in the industry. The specification defines it as the system "provided by the manufacturer of the AIMD... configured to store the data" (Spec., para. [0056]). This is not an unconventional step but a routine prerequisite.
The interface recited in claims 16 and 24 does not supply an inventive concept because, per the claim language, it merely receives filtered output and provides a notification, which only communicates the mental-result rather than implements a technical mechanism for achieving a different operation. As explained in MPEP § 2106, an inventive concept must arise from elements or combinations that go beyond the judicial exception, ensuring the claim amounts to significantly more than the abstract idea; limitations that simply apply the abstract idea or state a desired result without specifying the means do not qualify.
Accordingly, claims 16 and 24 do not recite additional elements that, individually or in combination, amount to significantly more than the mental process, and therefore do not satisfy Step 2B.
Combination Analysis:
Viewed as a whole, the combination of accessing data from a manufacturer's platform and using a server, processor, and output in a cloud environment to analyze that data is an ideal example of a generic computer system performing its ordinary functions. This arrangement lacks an inventive concept.
Dependent Claims Analysis
(Claims 19, 23): The use of a "remote monitoring platform" does not add an inventive concept. Such platforms are well-understood, routine, and conventional (d) in the field of modern healthcare for managing patient data from remote devices. The platform as described is a generic data management and communication tool, used for its intended purpose. It does not represent a specific machine or a technological improvement, but rather a conventional setting for the abstract idea.
(Claims 18, 20-22, 25-30): These claims do not add new elements that could form an inventive concept. They only add further specificity to the abstract idea itself. These limitations are simply (f) mere instructions to perform a specific calculation on a generic computer and (h) mere field-of-use limitations. They do not add anything beyond the abstract analysis itself.
(Claim 29): This claim adds specific data points. This represents (g) insignificant pre-solution activity of gathering specific data and is a (h) mere field-of-use limitation; it does not add an inventive concept.
The dependent claims, taken individually or as a whole, do not supply an inventive concept. They merely narrow the abstract idea to a specific context, define the data to be analyzed, or add conventional data-handling steps, all performed on the same generic computing platform recited in the independent claims.
Conclusion
The claims are directed to the abstract idea of mentally analyzing clinical data to determine its relevance. The additional elements, both individually and in combination, do not amount to significantly more than the abstract idea itself. Therefore, Claims 16, 18-23, and 24-31 are rejected under 35 U.S.C. § 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.
Claim(s) 16, 18, 21-24, 27, 29 and 31 are rejected under 35 U.S.C. 103 as being unpatentable over US20140046690A1-Gunderson, and further in view of US20210020294A1-Bharmi.
Claim 16.
Gunderson teaches, A system for managing information relating to at least one patient with an active implantable medical device (AIMD) comprising at least one sensor and communicatively coupled to a device manufacturer's platform, said system comprising: (Gunderson, paragraphs 0001-0005, 0031, 0033, 0036, 0059, 0061-0065, 0084, fig.3), Gunderson describes, under BRI, a platform that collects sensed IMD data and detected episodes and delivers patient management reports via a networked server, which is semantically and functionally the same as a system managing AIMD information coupled to a manufacturer’s platform. Where IMD 16 senses cardiac signals and events and the server 120 / network 144 environment stores and distributes patient data, it reads on the claimed preamble.
a server comprising at least one processor configured to: (Gunderson teaches a server (server 120) comprising at least one processor (processors 122) configured to perform various functions including generating reports, as detailed in Gunderson, paragraphs [0059], [0094], [0102], [0103].)
access, from the device manufacturer's platform, at least one manufacturer information representative of an output of the respective AIMD over time; (Gunderson, paragraphs [0060], [0064] and [0088])
Gunderson teaches, how IMD 16 uses an access point to transmit sensed data over network144 into a secure repository on the manufacture’s external platform, thereby archiving time-series AIMD outputs for later retrieval.
the manufacturer information comprising a plurality of measurements recorded by the at least one sensor of the AIMD or a plurality of parameters calculated by the device manufacturer's platform using said plurality of measurements recorded by the at least one sensor of the AIMD, or a plurality of parameters calculated by the device manufacturer's platform using said plurality of measurements recorded by the at least one sensor of the AIMD[Gunderson, pars. 0005, 0027, 0028, 0040-0042, 0036, 0064, 0081, 0120, 0152]
Gunderson describes direct measurements (e.g., ECG/electrograms, VT/VF events, activity, HR, respiration) and calculated parameters as diagnostic metric values derived from those measurements; under BRI, both categories read on the claim. Where the system computes metric values from sensed data and optionally clinician-set thresholds, it is semantically the same as parameters calculated using said measurements.
the manufacturer information further comprising at least one alert that has been generated using said plurality of measurements or said plurality of parameters; [Gunderson, pars. 0005, 0006, 0029, 0042, 0167, 0120]
Gunderson explains that patient sensor readings are shown as alerts when they go above certain limits, and these results are included in reports only if those limits are passed.
analyze the received at least one manufacturer information based on at least one first type rule, each first type rule being associated to a predefined first sensor event referring to a measurement in the plurality of measurements or a parameter in the plurality of parameters used to generate the at least one alert comprised in the manufacturer information and to at least one patient's clinical information relating to a patient medical status,(Gunderson, pars. 0027 “…sensed data from an implantable or external medical device (e.g., patient data). For example, an implantable medical device (IMD)… used to generate the patient management report. Patient data from an IMD may include therapy use statistics (e.g., pacing or shocks),…”-0028 “…diagnostic metrics may include sensed data … incorporate patient history or other patient information…”, 0042 “… allow the user to define how IMD 16 senses, detects, and/or manages patient data… set the threshold for one or more diagnostic metrics… customize how diagnostic metrics are generated and when diagnostic metrics are included within a patient management report… patient management report when the metric exceeds the respective threshold…”, 0043 “…information related to the patient or patient condition…”, 0058 “…external medical devices may generate patient data that is used to generate diagnostic metrics and patient management reports…”, 0077 “…parameter values to be used in one or more diagnostic metrics…”, 0079 “…patient parameters may be used to generate a diagnostic metric that may be included in a patient management report when the value of the diagnostic metric exceeds a respective threshold. … patient parameters may include any sensed or detected parameters related to cardiac rhythms, electrical or hemodynamic cardiac episodes, patient activity, patient posture, or any other physiological event or condition of the patient…”, 0105, 0119-0123 “…generate the patient management report, triage module 130 may receive patient data for at least one patient. The patient data may include sensed or detected parameters from IMD 16 for each patient, patient history information, or any other information that may be used to generate each of the diagnostic metrics. … analyzing one or more pieces of received patient data… compare the diagnostic metric values to one or more respective thresholds of each diagnostic metric. If the diagnostic metric value exceeds its threshold, the diagnostic metric may be included in the patient management report. In other words, only diagnostic metrics exceeding a threshold may indicate that the patient requires attention from the clinician or other healthcare professional… thus generate the patient management report that includes the diagnostic metrics having a value that exceeds the respective threshold…, 0152, 0165-0167, 0062, table 1, fig. 11)
The examiner above BRI limitation require analyzing received manufacturer information based to a sensor predefined measure or parameter to generate an alert comprise manufacturer information and patient medical status.
Gunderson teaches a rule-based diagnostic framework where device-derived event data is evaluated using predefined metric conditions and patient-specific clinical context, and Table 1 shows a concrete combined event-plus-clinical-status rule.
the first type rule being defined in order to verify a medical relevance of the at least one alert [Gunderson, pars. 0026, 0028 “…a diagnostic metric may incorporate sensed data indicating that ventricular tachycardia has occurred... and stored information indicating the patient as a primary prevention patient to indicate when the first ventricular tachycardia has occurred within a primary prevention patient…clinically relevant automatic observation from a diagnostic metric…”, 0061 “…patient management report as a centralized information source about the patients that the clinician is tracking. The clinician may use the patient management report as a way to triage patients without separately reviewing data from each patient periodically…”, 0062 “…patient management reports may be generated in response to a request from the clinician or in response to one or more new diagnostic metrics that may indicate urgent attention by the clinician is necessary…”, 0080 “… review the detected patient parameters for accuracy, particularly with regards to detected arrhythmias… “ 0114, 0119-0121, 0126 “…clinician is prompted to update the preferences for each diagnostic metric and selected reporting characteristics…” 0150-0152, 0166-0167 “…. Triage module 130 may flag and monitor any patient with a threshold number of diagnostic metrics exceeding respective thresholds or any other at risk patients for more frequent or continual monitoring. In some examples, triage module 130 may receive a request from a clinician to more frequently monitor one or more patients…”fig. 11]
The limitation require any rule, logic, or conditional analysis executed by the system that uses a patient's clinical data as an active variable to evaluate whether a received device alert has medical or diagnostic significance.
Gunderson discloses using rules to "triage patients" based on "urgency" and incorporating clinical context (e.g., "primary prevention patient") to flag events requiring attention.
said analysis comprising applying each first type rule to the received at least one manufacturer information in order to determine, depending on each corresponding patient's clinical information, whether the corresponding predefined first sensor event has occurred and is relevant for diagnosis; [Gunderson, pars. 0006, 0026-0029, 0120, 0123, 0061, 0120]
The limitation requires the execution of the rule to determine: a confirmation that a predefined sensor event actually happened, and that this specific event holds diagnostic significance.
Gunderson it uses thresholds to confirm that a sensor and clinical event actually occurred and was important enough to include in a clinician’s diagnostic report
provide at least one label associated to the at least one manufacturer information based on a result of said analysis; (Gunderson, paragraphs [0006], [0029], [0120], [0167]), The limitation requires the system to assign a descriptive identifier or tag to the received device data as a direct consequence of the prior analytical evaluation. Gunderson teaches generating a "diagnosis" or including a "diagnostic metric" in a patient management report when the analysis shows a threshold is exceeded. This named "diagnosis" or "diagnostic metric" (e.g., "Oversensing episode") associated with the patient's data in the report functions as a label provided based on the result of the analysis
wherein the received at least one manufacturer information comprises information associated to the predefined first sensor event; (Gunderson, paragraphs [0005], [0015], [0077], [0120], [0123]), Gunderson teaches that diagnostic metrics are determined based on received patient data including sensed IMD data. To determine a metric related to a specific event (e.g., VT), the system must receive the underlying IMD data associated with that event.
wherein the server is comprised into a cloud-based service; (Gunderson, par. 0059, 0061-0064, 0106, 0119, fig.3)
Under the Broadest Reasonable Interpretation (MPEP 2111), a "cloud-based service" provides services from servers over a network. Gunderson discloses this by describing a "server 120" connected to medical devices via a "global network, such as the Internet," which generates "web pages... for viewing". This remote access architecture is directly compared to the "Medtronic CareLink® Network," a known cloud-based medical service.
at least one output adapted to provide data representative of at least one labeled manufacturer information for diagnosis taking account of the predefined first sensor event occurrence and relevancy. (Gunderson, paragraphs 0004, 0006, 0026, 0060, 0105, 0120, 0130, 0157), Gunderson teaches an output (network interface 126) adapted to provide data (the patient management report) representative of labeled manufacturer information (the diagnostic metrics exceeding thresholds listed in the report) for diagnosis, taking account of event occurrence and relevance (metric definition and exceeding the threshold).
comprising, based on the at least one label, performing filtering of a first alert in the at least one alert that removes the first alert from the output and providing the output to an interface and causing the interface to provide a notification, . (Gunderson, para. [0006], fig. 11, 0063, 0142, 0162, 0167-0168a, fig. 13, 0173)
Gunderson explains that the system assigns a status label (such as marking an entry “complete”) and uses that label to filter out and remove a specific alert or metric from the output. The filtered report is then sent to the clinician’s interface, where a notification is provided, but the removed alert is neither displayed nor triggers any notification. This directly matches filtering a first alert based on a label and providing an output that excludes that alert from the interface.
Obvious Rationale:
Claim 16 recites the first type rule being defined in order to verify a medical relevance of the at least one alert
Under the broadest reasonable interpretation, this limitation requires a conditional logic rule executed by the system that actively uses a patient's clinical data to evaluate the diagnostic significance of an already received device alert. Gunderson teaches using rules and clinical context to triage patient conditions, as shown by "a diagnostic metric may incorporate sensed data... and stored information indicating the patient as a primary prevention patient" to "triage patients" (Gunderson, pars. 0028, 0061). This reads on using clinical information to establish priority because it uses patient history to sort generated metrics for clinical review. However, Gunderson does not teach applying the rule to an already received alert to verify its medical relevance.
Bharmi teaches that missing feature, as shown by implementing a model "to analyze the AF burden and the [device alert] from the VAD in connection with risk of at least one of hemolysis or thrombosis" (Bharmi par. 0037), which reads on verifying an alert's medical relevance using clinical data because it explicitly processes an existing device alert alongside a patient's clinical AF burden to determine actual thrombosis risk.
A person of ordinary skill in the art would have combined before the effective filing date Gunderson with Bharmi to improve the clinical triage of device alerts by incorporating secondary clinical risk models, by configuring Gunderson's triage module to apply Bharmi risk-verification rule to incoming device alerts, because both references seek to efficiently "triage patients without separately reviewing data" (Gunderson, par. 0061) by accurately processing complex "IMD data" (Bharmi, par. 0037). Doing so would have predictably resulted in a more accurate patient management system that successfully verifies whether an incoming device alert represents a true medical risk before flagging it for the clinician's attention, by configuring Gunderson's triage module to apply Bharmi’s risk-verification result as a filter to automatically suppress low-risk alerts from the report. This combination is supported by the goal to efficiently "triage patients without separately reviewing data" (Gunderson, par. 0061) using rules that accurately assess whether an alert represents a true clinical risk (Bharmi, par. 0037). Doing so would have predictably resulted in a more efficient remote monitoring system that successfully prevents non-critical alerts from reaching the clinician's interface, thereby ensuring notifications are only provided for medically relevant events.
Claim 16 recites comprising, based on the at least one label, performing filtering of a first alert in the at least one alert that removes the first alert from the output and providing the output to an interface and causing the interface to provide a notification,
Under the broadest reasonable interpretation, this limitation requires the system to algorithmically use a previously assigned medical relevance tag to automatically suppress a specific device alert from the data payload before transmission, ensuring the user interface never receives or notifies the user of that suppressed alert. Gunderson teaches a platform that manages patient alerts and allows for the removal of entries from a report based on a status identifier, as shown by "checking a 'complete' box in the status column may remove that entry for the patient" (Gunderson, par. 0162) and delivering the updated report to a clinician interface (par. 0168). This reads on the structural removal of data from an output because it prevents a specific entry from appearing in the transmitted report.
However, Gunderson does not teach automatically performing this filtering based on a system-generated medical relevance label.
Bharmi teaches this missing feature by implementing an Application Specific Model (ASM) to analyze an existing "device alert from the MCS device" alongside clinical data like "AF burden" to verify a "risk of at least one of hemolysis or thrombosis" (Bharmi, par. [0029]). As shown in Figure 4 and Figure 6D, the ASM determines if a "Health Risk Index Exceed[s] [a] Threshold" (634); if not, the system follows a logic path to Do Nothing (428) and terminates without generating a notification (Bharmi, Fig. 6D). This reads on algorithmically determining medical relevance (the label) to perform filtering that removes an existing alert from the notification stream.
A person of ordinary skill in the art would have combined Gunderson with Bharmi to automate clinical triage and prevent alert fatigue, by configuring Gunderson's triage module to utilize Bharmi’s ASM risk-verification logic as a gate to automatically suppress alerts that lack verified clinical risk. This combination is supported by the goal to efficiently "triage patients without separately reviewing data" (Gunderson, par. [0061]) by utilizing a processor-driven model that can "automatically generate a notification" only after confirming diagnostic significance (Bharmi, par. [0038], Fig. 4). Doing so would have predictably resulted in a more efficient remote monitoring system that successfully prevents non-critical alerts from being transmitted to or notified at the clinician's interface, thereby ensuring notifications are only provided for medically relevant events.
Note: Claim 24 it is rejected with the same analysis above to being very similar to claim 16.
Claim 18. Gunderson in combination with Bharmi teaches, The system according to claim 16, wherein said at least one processor is further configured to record the at least one labeled manufacturer information labelled as not relevant and to exploit the at least one labeled manufacturer information labelled as relevant. (Gunderson, paragraphs [0004], [0006], [0116], [0064], [0099], [0110], [0118], [0120], [0121], [0126], [0150], [0181], [0173]), Gunderson teaches that the system determines which diagnostic metrics exceed a threshold (are 'relevant' for reporting) and exploits this determination by including them in the generated patient management report. Information not meeting the criteria for the report ('not relevant' for the current report) or previously viewed/reported information can be excluded from the main view but the underlying data is stored/archived and potentially flagged as viewed. This combination of selectively reporting relevant information while storing/archiving/flagging non-reported or previously reported information meets the broadest reasonable interpretation of recording the 'not relevant' labeled information and exploiting the 'relevant' labeled information.
Claim 21. Gunderson in combination with Bharmi teaches, The system according to claim 16, wherein the patient's clinical information is at least one of the following: age, sex, medical scores or classes, weight, comorbidities, symptoms, underwent surgeries, left ventricular fraction ejection. (Gunderson, paragraphs [0028], [0027]), Gunderson, mentions "procedures" (mapping to underwent surgeries) and "diagnoses" (mapping to comorbidities), and potentially others under "patient condition status".
Claim 22. Gunderson in combination with Bharmi teaches, The system according to claim 16, wherein, for each patient, the manufacturer information further comprises at least one sensor information representative of a physiological and/or physical activity of the patient as a function of time, the analysis of the received manufacturer information further comprising applying at least one second type rule to said sensor information in order to determine whether a predefined second sensor event, associated to said second type rule, has occurred. (Gunderson, paragraphs [0006-0007], [0110], [0120], [0033], [0037], [0038], [0056], [0057], [0079], [0081], [0084]), Gunderson teaches analyzing patient data, which includes time-series sensor information, to determine values for diagnostic metrics. Determining these metrics that involves applying rules or algorithms to the sensor information. Gunderson provides examples of diagnostic metrics (like "increase in frequency of cardiac episodes" or identifying trends in fluid index) that necessarily require applying rules to the time-series sensor information to detect specific predefined events or patterns within that data. This analysis corresponds to applying a "second type rule" to "sensor information" to determine if a "predefined second sensor event" has occurred.
Claim 23. Gunderson in combination with Bharmi teaches, The system according to claim 22, wherein said at least one processor is further configured to notify, via the remote monitoring platform, at least one label associated to the manufacturer information labeled on the basis of each second type rule, said at least one label being representative of each corresponding predefined second sensor event detected. (Gunderson, paragraphs [0123], [0006], [0104], [0110], [0120], FIG. 10, [0059], [0110], [0121]), Gunderson teaches a system that detects events by analyzing sensor data over time, then generates a patient management report including the specific names of these detected "diagnostic metrics" (serving as labels) and transmits this report over a network to clinicians (notification via a remote platform). The inclusion of the specific diagnostic metric name (e.g., "Frequency of episodes increased") in the transmitted report constitutes notifying a label representative of the detected second sensor event.
Claim 27. Gunderson in combination with Bharmi teaches, The method according to claim 24, wherein, for each patient, the manufacturer information further comprises at least one sensor information representative of a physiological and/or physical activity of the patient as a function of time, the analysis of the received manufacturer information further comprising applying at least one second type rule to said sensor information in order to determine whether a predefined second sensor event, associated to said second type rule, has occurred. (Gunderson, paragraphs [0005], [0027], [0036], [0037], [0073], [0081], [0084], [0073-0074], [0075], [0120]), Gunderson clearly teaches that the data received from the AIMD system includes time-based sensor data reflecting physiological activity (e.g., heart rate, arrhythmias, AF burden, impedance) and physical activity (accelerometer data). Gunderson further teaches that these rules are applied specifically to the sensor information (e.g., cardiac intervals, derived metrics precisely for the purpose of determining if predefined events have occurred (e.g., specific arrhythmias like AF/VT/VF, or diagnostic metrics exceeding thresholds.
Claim 29. Gunderson in combination with Bharmi teaches, The method according to claim 27, wherein the at least one sensor information includes an atrial fibrillation burden as a function of time and/or a biventricular pacing percentage as a function of time, derived from the active implantable medical device. (Gunderson, paragraphs [0081-0082]) Gunderson teaches using "atrial tachycardia or fibrillation burden" ([0081]) as sensor information derived from the IMD. Gunderson also explicitly teaches using "a cardiac resynchronization therapy percentage", which corresponds to biventricular pacing percentage, as sensor information derived from the IMD. Therefore, Gunderson teaches that the sensor information can include AF burden and/or BiV pacing percentage derived from the AIMD.
Claim 31. Gunderson in combination with Bharmi teaches, A non-transitory computer-readable storage medium comprising instructions which, when executed by a computer, cause the computer to carry out the method according to claim 24. (Gunderson, [0008], [0065], [0091], [0104], [0177], Claim 21) Gunderson teaches non-transitory computer-readable storage media, meeting limitation that these media comprise instructions for execution by a processor, these instructions cause the processor to carry out a method of patient data analysis and reporting.
Claim(s) 19-20, 25-26, 30 is/are rejected under 35 U.S.C. 103 as being unpatentable over US20140046690A1-Gunderson, and further in view of US20210020294A1-Bharmi in combination with US20010028308A1 - De La Huerga.
Claim 19. Gunderson teaches, The system according to claim 16, wherein:
the at least one manufacturer information comprises at least one alert information relating to a suspected abnormal activity of the patient's heart, each alert information being associated to a time stamp representing the time at which the alert information is generated; (Gunderson, [0040], [0079], [0088], [0123]), Gunderson discloses IMD data includes detected cardiac events (AF, VT) and delivered shocks, which function as alerts for abnormal activity. Paragraph [0040] explicitly mentions the "timeline of each shock," confirming the association with temporal information (timestamp).
Gunderson does not teaches,
However, Gunderson does not disclose using specific drug intake time intervals to filter alerts or automatically labeling alerts for non-notification based specifically on comparison to such intervals. But De La Huerga describes an interactive medication system managing consumption relative to specific time "periods" [ De La Huerga, paragraph 0517] and processing alerts based on context, because the system provides for "skipping alerts when previous events obviate the alerts". It is obvious to combine Gunderson with De La Huerga because Gunderson teaches generating reports/alerts based on clinician input and patient data including applying rules based on preferences [Gunderson, paragraph 0004, 0116], while De La Huerga teaches managing alerts based on consumption timing and context like "consumption outside specific time periods" and "skipping alerts when previous events obviate the alerts". A person of ordinary skill in the art could be motivated to integrate De La Huerga's alert management based on consumption periods and event context into Gunderson's system, because this provides the benefit of improved "health safety functions" by reducing unnecessary alerts.
Claim 25. Gunderson in combination with Bharmi teaches, The method according to claim 24, wherein, for each patient:
the at least one manufacturer information comprises at least one alert information relating to a suspected abnormal activity of the patient's heart, each alert information being associated to a time stamp representing the time at which the alert information is generated; Gunderson discloses receiving "patient data" ([0005], [0027], [0119]) from an IMD system ([0005], [0105]) (corresponding to "manufacturer information"), generating "diagnostic metrics" ([0005]) such as detected "atrial fibrillation," "ventricular tachycardia (VT)," "ventricular fibrillation (VF)," "shock events," or "oversensing episodes" ([0079], [0151]) when thresholds are exceeded (corresponding to "alert information relating to a suspected abnormal activity of the patient's heart"), and associating time data via the "time when the diagnostic metric originally occurred" ([0160]) (corresponding to "time stamp").
the patient's clinical information comprises at least ; (Gunderson, [0043], [0095], [0134], [0151] (Table 1), [0175]), Gunderson mentions "medication compliance" ([0043]) as part of patient information and lists "changing medications" ([0134], [0151], [0175]) as a treatment action derived from the analysis.
and for each first type rule, the analysis comprises applying said first type rule by labeled as labeled manufacturer information not to be notified. (Gunderson, [0116], [0142]) Gunderson's system labels information for reporting characteristics like urgency/action or hides viewed information based on clinician preference.
Gunderson teaches all limitations of claim 24, however, does not disclose using specific drug intake time intervals to filter alerts or automatically labeling alerts for non-notification based specifically on comparison to such intervals. But De La Huerga describes an interactive medication system managing consumption relative to specific time "periods" [ De La Huerga, paragraph 0517] and processing alerts based on context, because the system provides for "skipping alerts when previous events obviate the alerts". It is obvious to combine Gunderson with De La Huerga because Gunderson teaches generating reports/alerts based on clinician input and patient data including applying rules based on preferences [Gunderson, paragraph 0004, 0116], while De La Huerga teaches managing alerts based on consumption timing and context like "consumption outside specific time periods" and "skipping alerts when previous events obviate the alerts". A person of ordinary skill in the art could be motivated to integrate De La Huerga's alert management based on consumption periods and event context into Gunderson's system, because this provides the benefit of improved "health safety functions" by reducing unnecessary alerts.
Claim 30. Gunderson in combination with Bharmi teaches, The method according to claim 24, wherein, for each patient:
the at least one manufacturer information comprises:
at least one alert information relating to a suspected abnormal activity of the patient's heart, each alert information being associated to a time stamp representing the time at which the alert information is generated, and for each alert information, at least one sensor information used to generate the alert information; (Gunderson, [0079], [0081], [0158], [0160])
Gunderson teaches, episode-based diagnostic metrics for arrhythmias and shocks (alert), maintains their occurrence time to enable “most recent” ordering (time stamp), and stores the sensed electrogram/impedance values that yielded the episode (sensor information)
the patient's clinical information comprises at least one intake of a drug and a corresponding ; (Gunderson, [0043], [0095], [0134], [0151] (Table 1), [0175]), Gunderson mentions "medication compliance" ([0043]) as part of patient information and lists "changing medications" ([0134], [0151], [0175]) as a treatment action derived from the analysis.
the analysis of the received at least one manufacturer information further comprises applying at least one third type rule to the received manufacturer information, each third type rule being associated to a predefined third sensor event, and to at least one predefined threshold value, the applying each third type rule to the received manufacturer information including: (Gunderson teaches analyzing data by applying rules, including threshold comparisons ([0120]) which are associated with predefined events (exceeding the threshold) and inherently use a threshold value.)
and comparing a predetermined portion of each sensor information to the predefined threshold value, so that, (Gunderson, paragraphs [0005], [0120], [0141-0142], [0040]), Gunderson teaches, comparing a predetermined metric and threshold, corresponding to out parameters physical value, and labelled as viewed.
Gunderson teaches analyzing sensor information and generating diagnostic metrics or reports when a value determined from that information exceeds a respective threshold (e.g., paragraphs [0005], [0120]), however, Gunderson does not disclose automatically labeling information "not to be notified" based on the combination of the sensor information meeting a threshold condition and the information's timestamp falling within a specific drug intake time interval. But De La Huerga describes modifying or suppressing scheduled medication alerts based on comparing actual consumption time to the scheduled interval (paragraph [0026]), because the system can "skip or forego presenting an alert to the patient to consume medication at that time so the patient is not confused" (paragraph [0026]).
It is obvious to combine Gunderson with De La Huerga because both teach processor-controlled systems for managing patient medical data, including event timing and alerts (Gunderson, paragraphs [0006], [0110]; De La Huerga, paragraphs [0018], [0227], [0231]).
A person of ordinary skill in the art, seeking to reduce non-actionable alerts from Gunderson's threshold-based system, could be motivated to integrate De La Huerga's time-based alert suppression logic, because this provides the benefit of avoiding unnecessary alerts "so the patient is not confused" (De La Huerga, paragraph [0026]). A POSITA would therefore combine Gunderson's step of comparing sensor information to a threshold (paragraph [0120]) with De La Huerga's concept of comparing event timing against a schedule/interval to suppress alerts (paragraph [0026]), implementing a logical AND condition.
Claim 20. Gunderson in combination De La Huerga teaches, The system according to claim 19, wherein the alert information includes an alert relating to atrial fibrillation burden, and (Gunderson, Abstract, paragraphs: 0004, 0081, 0073 ), Gunderson teaches generating a patient management report (meeting the BRI of "alert information" ) which includes diagnostic metrics that exceed a threshold. Gunderson explicitly discloses using "atrial fibrillation burden" as such a diagnostic metric.
Gunderson teaches how to generate reports, including diagnostic metrics like "atrial fibrillation burden" (paragraph [0081]); however, Gunderson does not disclose applying the specific suppression rule of claim 19 in the particular context where the alert relates to AF burden and the drug is an anticoagulant drug. But Bharmi describes analyzing AF burden data in conjunction with anticoagulant medication information via INR levels (paragraph [0364]) because the system can assign a "health risk index based on the IMD data [including AF burden] and the BGA data [including INR level]... [and] generate a diagnosis, such as increase a dosage of anticoagulation" (paragraph [0364]).
It is obvious to combine Gunderson with Bharmi because both teach analyzing patient data including AF burden (Gunderson, paragraph [0081]; Bharmi, paragraph [0353]) and generating diagnoses or notifications based on the analysis (Gunderson, paragraph [0120]; Bharmi, paragraph [0364]).
Claim 26. Gunderson in combination De La Huerga teaches, The method according to claim 25, wherein the alert information includes an alert relating to an atrial fibrillation burden, and the . (Gunderson, [0081], [0088], [0090], [0120], [0114], Table 1). Gunderson teaches monitoring "atrial tachycardia or fibrillation burden" ([0081]) and generating reports/alerts when diagnostic metrics exceed thresholds ([0120]).
Gunderson teaches how to generate reports, including diagnostic metrics like "atrial fibrillation burden" (paragraph [0081]); however, Gunderson does not disclose applying the specific suppression rule of claim 19 in the particular context where the alert relates to AF burden and the drug is an anticoagulant drug. But Bharmi describes analyzing AF burden data in conjunction with anticoagulant medication information via INR levels (paragraph [0364]) because the system can assign a "health risk index based on the IMD data [including AF burden] and the BGA data [including INR level]... [and] generate a diagnosis, such as increase a dosage of anticoagulation" (paragraph [0364]).
It is obvious to combine Gunderson with Bharmi because both teach analyzing patient data including AF burden (Gunderson, paragraph [0081]; Bharmi, paragraph [0353]) and generating diagnoses or notifications based on the analysis (Gunderson, paragraph [0120]; Bharmi, paragraph [0364]).
A person of ordinary skill in the art could be motivated to integrate the specific clinical context taught by Bharmi ( anticoagulant medication) because is used to reduce the risk of thromboembolic events by inhibiting blood clot formation in patients who experience frequent or prolonged AF episodes" (paragraph [0364], [0030]).
Claim(s) 28 is/are rejected under 35 U.S.C. 103 as being unpatentable over US20140046690A1-Gunderson, and further in view of US20210020294A1-Bharmi in combination with US20180242876A1-Hughes.
Claim 28. Gunderson in combination with Bharmi teaches, The method according to claim 27, wherein the (Gunderson, [0073], [0081]), Gunderson teaches determining predefined sensor events, including the detection of "atrial fibrillation (AF)".
however, Gunderson does not disclose defining or detecting the specific AF-related medical conditions of claim 28 (e.g., first episode, increasing paroxysmal, paroxysmal, persistent, end of persistent AF) as the "predefined second sensor event."
But Hughes describes analyzing cardiac data to evaluate detailed aspects of AF occurrence beyond simple detection because Hughes teaches evaluating "daily burden (% of time in AF each day), and duration of episodes... both either in absolute terms or in comparison to prior benchmarks" (paragraph [0089]) and discusses the value of such monitoring approaches for applications like the "management of Paroxysmal Atrial Fibrillation" (paragraph [0087]).
It is obvious to combine Gunderson with Hughes because both teach systems that analyze cardiac sensor data (Gunderson, paragraph [0081]; Hughes, paragraph [Hughes, 0005]) using processors (Gunderson, paragraph [0007]; Hughes, paragraph [0164]) to determine arrhythmia information like AF burden (Gunderson, paragraph [0081]; Hughes, paragraph [0089]).
A person of ordinary skill in the art, seeking to enhance the clinical utility of Gunderson's AF detection, would be motivated by Hughes's disclosure to perform a more detailed characterization of AF episodes, because such analysis is "clinically meaningful" and helpful for applications like "management of Paroxysmal Atrial Fibrillation" (paragraphs [0087], [0089]).
Relevant Prior arts:
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 20160093205 A1-Boyer
The prior art above is relevant because describe a suppression mechanism of received alarms based on importance in the clinic area context. (abstract, par. 0006-0007, fig. 6 – 9).
Koomen E, Webster CS, Konrad D, van der Hoeven JG, Best T, Kesecioglu J, Gommers DA, de Vries WB, Kappen TH. Reducing medical device alarms by an order of magnitude: A human factors approach. Anaesth Intensive Care. 2021 Jan;49(1):52-61. doi: 10.1177/0310057X20968840. Epub 2021 Feb 2. PMID: 33530699; PMCID: PMC7905747.
The prior art above is relevant because recite provide a solution for the same applicant problem fatigue alarm by priorities and optimize alarms across all devices to display information more intuitively to generated alarm only after data integration from all devices and if the events is warranted
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JOSHUA DAMIAN RUIZ whose telephone number is (571)272-0409. The examiner can normally be reached 0800-1800.
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, Shahid Merchant can be reached at (571) 270-1360. 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.
/JOSHUA DAMIAN RUIZ/Examiner, Art Unit 3684
/KAREN A HRANEK/Primary Examiner, Art Unit 3684