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 .
Applicant Argument Response
Examiner answer all applicant arguments in the filled remarks 07/06/26 pages 13-22 in regarding to the subject matter eligibility 35 U.S.C 101 frame, and were found not persuasive per the reasons below:
Applicant argues that the Office Action improperly assumed ineligibility without proving that the claims recite a judicial exception.
The Examiner disagreed that the prior non-final Office action failed to satisfy the Office’s burden; however, the rejection is maintained and clarified per amendments, claim 16 recites reviewing records, correlating timing, applying clinical criteria, determining diagnostic relevance, reconciling records, assigning a label, and screening an alert, each practically performable as observation, evaluation, or judgment using patient and device records.
Applicant argues that the AIMD, sensor, manufacturer platform, filtering, and interface-notification limitations make the claims too complex to perform practically in the human mind.
The Examiner respectfully disagrees because Prong One does not require every limitation, or the claim as a physical combination, to be performable mentally. The AIMD, sensor, platform access, preprocessing module, electronic storage, cloud server, interface, and notification are treated as additional elements under Prong Two. The narrower exception consists of the recited record review, temporal correlation, clinical evaluation, relevance determination, reconciliation, labeling, and alert-screening judgments. Those particular limitations fall within the mental-process grouping even though other limitations require physical or computer components. Therefore, the rejection is maintained.
Applicant argues, “The present claims are similar with respect to what is actually recited.” Applicant reasons that the AIMD sensor must be located within the patient and concludes that “the operation of the system requires a particular interaction which cannot be practically emulated in the human mind in the manner claimed.”
The Examiner respectfully disagrees. In SiRF, the claimed position calculation depended on satellite signals and pseudoranges that could not practically be obtained and calculated mentally in the claimed manner. Here, the AIMD and manufacturer platform supply existing measurements, parameters, episodes, and alerts; the claimed system does not itself perform the manufacturer platform’s parameter calculation or original alert generation. The identified exception concerns the subsequent ability to correlate the records, apply clinical criteria, determine relevance, reconcile information, label it, and screen an alert. The AIMD-related acquisition limitations are additional elements, but they do not make those downstream evaluative limitations nonmental.
Applicant argues that the claims materially require an AIMD sensor located within the patient, creating a specific patient–sensor interaction that cannot be practically emulated in the human mind as claimed.
The Examiner respectfully disagrees, because the AIMD/platform only supplies existing data; comparing records, determining relevance, labeling, and screening alerts can be performed mentally. Unlike SiRF, no machine-dependent signal calculation is claimed. The physical elements remain for Prong Two but do not remove the mental process at Prong One.
Applicant argues that the claim does more than merely say “filter an alert.” It identifies the input, the decision rule, and the result: manufacturer alert data is evaluated using a predefined sensor event, assigned a relevance label, and then either withheld or used to produce another notification.
The Examiner respectfully disagrees. Claims 16 and 24 use the medical-relevance label to determine which alert is withheld (Spec. p. 17). The filtering applies the screening judgment to select information for presentation, rather than improving the interface’s technical operation. Thus, the filtering does not integrate the exception into a practical application, and the rejection is maintained.
Applicant argues: Applicant argues that BASCOM recognizes customized filtering implemented through a particular arrangement as patent-eligible. The claims similarly use patient-specific clinical and sensor information to label, suppress, or notify selected alerts. Therefore, Applicant contends that the filtering is a practical application, not merely abstract screening.
The Examiner respectfully disagrees. The Examiner respectfully disagrees. Under BRI, filtering the first alert means that the medical-relevance label causes the server to withhold that alert and issue another notification; a timestamp/clinical-interval comparison produces the “not to be notified” label (Spec. p. 17, ll. 7–29). The sensor event and clinical data supply the information and criterion evaluated; filtering communicates that result. BASCOM instead claimed a “specific, discrete implementation” tying a remote ISP filter to individual accounts and customizable filtering schemes. Considering platform access, preprocessing, reconciliation, cloud service, and notification together, the claims do not recite a comparable technical interaction improving the monitoring system’s operation.
Applicant argues that the Office identifies differences in terminology but does not explain why those differences are material to eligibility.
The Examiner respectfully disagrees. The remarks mention DDR, CardioNet, BASCOM, and Core Wireless, but provide no distinct limitation-by-limitation comparison with DDR or CardioNet. The present claims do not recite a changed website operation, a particular cardiac-signal analysis technique, or another technological mechanism corresponding to the improvements material to those cases. A general similarity in purpose or result does not establish the same practical application.
Applicant argues that the relevant improvement is not the creation of new medical information but the computer’s improved selection and presentation of useful information.
The Examiner respectfully disagrees. Core Wireless upheld a specific interface arrangement that changed navigation, not merely the selection of useful content. Under BRI, claims 16 and 24 use a medical-relevance label to remove the first alert and cause a different notification, but do not specify a display layout, navigation path, selectable control, or manner of presenting the remaining information (Spec. p. 17, ll. 7–29). Considered as a whole, the claims change the content communicated, not the interface’s operation.
Applicant argues that relying on McRO, that automating work previously performed by clinicians does not, by itself, establish an abstract idea at Step 2A.
The Examiner respectfully disagrees. A computer-implemented claim still recites a mental process when the identified limitations can practically be performed mentally (MPEP § 2106.04(a)(2)(III)). Under BRI, claims 16 and 24 require reviewing sensor-event and clinical information, determining occurrence and diagnostic relevance, and deciding which alert should be withheld. Claims 19, 25, and 30 add timestamp, drug-interval, threshold, classification, and notification judgments. Unlike McRO, these rules do not require a particular nonmental computation. Acquisition, preprocessing, output removal, and notification are separately considered under Prong Two; they do not negate the mental evaluations recited at Prong One
Applicant argues that example 42 recognizes standardizing healthcare information from different sources as a practical technological application, and the amendments now recite comparable implementation detail.
The Examiner respectfully disagrees. Example 42 did not treat standardization alone as sufficient; eligibility rested on converting platform-dependent updates, storing the standardized record, automatically generating an update message, and transmitting it to all remote users in real time. Under BRI, claims 16 and 24 need only preprocess information for a respective AIMD before applying the medical-relevance analysis (Spec. p. 15, ll. 20–28). They do not require receiving incompatible updates from multiple sources or sharing the standardized record in real time. Considered as a whole, the preprocessing prepares information for the screening judgment but does not establish comparable technological integration under Prong Two.
Applicant argues that Intellectual Ventures v. Symantec supports eligibility because, unlike the claims there, claims 16 and 24 allegedly recite the mechanism that solves the alert-volume problem: multi-platform access, preprocessing, relevance rules, labeling, filtering, and notification.
The Examiner respectfully disagrees. Under BRI, claims 16 and 24 suppress an alert only after the server receives, reformats, and evaluates the information for medical relevance; claims 19 and 25 use the label to exclude records from a later clinical determination. The Declaration shows fewer alerts for clinicians to review, but not an improvement in sensing, alert generation, computer architecture, or transmission (Declaration 8–11; Spec. p. 18, ll. 1–15). Thus, unlike Symantec’s computer-processing volume problem, the claims apply and communicate a medical-screening judgment.
Applicant argues that the asserted technological improvement is supported by factual evidence rather than attorney argument alone. The declaration and studies allegedly connect the claim limitations to standardized multi-manufacturer monitoring, substantial alert reduction, improved workflow, and better clinical results.
The Examiner respectfully disagrees that the declaration establishes eligibility, although the evidence has been considered and given appropriate weight. Declaration paragraphs 3–9 provide relevant evidence concerning the Implicitly UMS and reported benefits. Paragraphs 10–11 present the declarant’s understanding and ultimate legal conclusion, which do not control eligibility. More importantly, the declaration discusses the commercial UMS and disclosed embodiments broadly without establishing that the full scope of claims 16, 19, 24, and 25 requires the product features responsible for those benefits. The evidence therefore lacks a sufficiently claim-specific and commensurate nexus.
Applicant argues: Varma demonstrates benefits attributable to the same multi-manufacturer consolidation and standardized presentation now reflected in the claims.
The Examiner respectfully disagrees that Varma establishes the required claim-specific technological nexus. The observational study evaluated the complete UMS service, including portal consolidation, adherence, staffing, workflow, alert identification, and treatments undertaken after review. The claims do not require that complete operational system, and the study does not isolate homogeneous-format preprocessing, single-label reconciliation, or alert withholding as the cause of the reported outcomes. The evidence supports a product-level association, not that the claimed technological features caused the clinical improvement. The rejection is maintained.
Applicant argues that Lazarus provides concrete evidence that time-based analysis and alert filtering reduce unnecessary alerts while preserving clinically useful information. In particular, a later event such as return to sinus rhythm may change the clinical importance of an earlier AF event.
The Examiner respectfully disagrees that Lazarus establishes eligibility across the claim scope, although the study is relevant to a specific implementation. Lazarus evaluated a particular retrospective algorithm using daily AF-burden values, seven-day trends, and defined clinical classifications. The declaration describes the algorithm as “similar to what is disclosed,” rather than demonstrating that every operative claim requires it. The study supports the benefit of a particular embodiment but does not establish a claim-wide technological nexus or improved computer mechanism.
Applicant argues that amended claim 16 no longer recites only generalized analysis and filtering. It now identifies multiple manufacturer platforms, a preprocessing module associated with manufacturer formats, conversion into a homogeneous format, a finite-duration sensor episode, temporal synchronization, reconciliation, and storage under one label.
The Examiner respectfully disagrees that the amendments overcome §101. Temporal correlation, reconciliation, and assignment of one label remain information comparisons and categorizations. The manufacturer platforms, preprocessing module, homogeneous-format conversion, AIMD acquisition, and storage are additional elements, but the claims state their intended results without a schema, parser, field mapping, conversion rule, altered data structure, or changed platform operation.
Applicant argues that claims 19 and 25 no longer recite an unspecified medical-relevance determination. They require timestamped alerts, comparison with drug-intake intervals, storage of information classified as not to be notified, continuous comparison with probability or value thresholds, and a second alert only after determining that suspected activity is abnormal.
The Examiner respectfully disagrees that claims 19 and 25 do not specify a data volume, sampling rate, signal-processing algorithm, model architecture, or calculation that makes the recited comparisons impracticable for a person reviewing records. At the claimed level, they require comparing timestamps with drug intervals and time-series information with thresholds, classifying suspected activity, and authorizing an alert. Storage, continuous computer execution, and notification automate and communicate those judgments rather than improve the underlying monitoring technology.
Applicant argues that Eligibility arises from the interaction of the limitations rather than any component considered separately. The claimed combination allegedly improves how a multi-manufacturer system standardizes information, controls notifications, presents relevant information, and uses computing resources.
The Examiner respectfully disagrees. The ordered combination acquires existing AIMD information, preprocesses it into a stated format, applies clinical screening judgments, stores labels, and communicates selected results using generic computer components. The claims do not recite an improved interface layout or operation, and they do not activate, deactivate, reprogram, or otherwise control the AIMD. Selective notification is not selective activation of an implanted device. Accordingly, the combination does not reflect the asserted technological improvements.
Applicant argues the Office cannot establish Step 2B by addressing only the components individually because “an inventive concept can be found in the non-conventional and non-generic arrangement of known, conventional pieces.” Applicant further argues that WURC is a factual issue that must be proven by “clear and convincing evidence.”
The Examiner disagrees because at this case WURC findings are limited to the generically claimed functions of network receipt or transmission, electronic recordkeeping, storage or retrieval, and interface communication identified in MPEP § 2106.05(d)(II). The Specification also describes the interface means as “well known by a person skilled in the art,” p. 16.
Applicant argues that amended claims provide “specific structure for solving the problem,” Reply, printed pp. 20–21, and explain “how the filtering is being performed,”. Applicant identifies multi-platform access, homogeneous-format preprocessing, synchronization of an episode with an alert, storage under a single label, and selective withholding of a labeled alert as an ordered technological arrangement comparable to BASCOM, Core Wireless, Intellectual Ventures I v. Symantec, and USPTO Example 42.
The Examiner disagrees that claims 16 and 24 recite the asserted non-generic technological arrangement. They require accessing the device manufacturer’s platform from among a plurality. They require preprocessing into a homogeneous format without specifying a schema, mapping, parser, or conversion sequence, and filtering based on the label without specifying filter placement, individualized configuration, interface arrangement, or device activation. BASCOM placed a filter remotely from end users and customized it per user; Core Wireless claimed a selectable summary of an unlaunched application; and Intellectual Ventures found no improvement because the claims omitted limitations addressing the asserted volume problem. MPEP § 2106.05(a). Example 42 converted nonstandard updates, transmitted them to all users in real time, and was resolved at Prong Two. USPTO Example 42. Because those authorities turned on implementation limitations absent here, they do not establish an inventive concept in claims 16 and 24. The rejection is maintained.
Applicant argues that the Varma study reports “significantly improved results” for mortality and hospitalizations. The Lazarus evidence reports reducing approximately 8.3 or 13.7 alerts per patient-year to approximately 2. Declaration. The declarant concludes that the claimed invention “represents an improvement in computer capabilities.”. Applicant contends that these results establish a nexus to reduced alert burden, improved monitoring, and improved computer operation.
The Examiner disagrees that the studies establish the required nexus across the claimed scope. Varma studied a UMS for “devices from all manufacturers” using a “single interface organized by priority level,” while Lazarus evaluated an atrial-management algorithm only “similar to what is disclosed.”. Claims 16 and 24 require neither all-manufacturer consolidation nor a priority-organized interface. Claims 19, 25, and 30 add timestamp, drug-interval, time-series, threshold, storage, and alert rules, but the declaration does not map the studied algorithm to those limitations. The remaining claims likewise do not require the studied configurations. The cited results measure mortality, hospitalizations, duration, and alerts per patient-year not processor, memory, network, or interface operation. Thus, the evidence shows clinical and workflow results for particular implementations, not improved operation across the claimed technology.
Examiner answer all applicant arguments in the filled remarks 07/06/26 pages 22-26 in regarding to the 35 U.S.C 103 frame.
Applicant’s arguments are moot because the prior § 103 rejections have been withdrawn. New grounds of rejection are presented for Claims 16, 18, and 20–23.
Claim Rejections – 35 U.S.C 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claim(s) 16 and 18–31 rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Independent claims 16 and 24 each require determining, “based on a previous record for the respective AIMD,” that information is indirectly provided by the AIMD to the device manufacturer’s platform. The Specification, p. 13, discloses that manufacturer information may be received directly from the AIMD or, alternatively, through a manufacturer platform that “has previously received the output of the AIMD over time.” The Specification, pp. 15 and 23, discloses retrieving information from manufacturer platforms and the indirect transmission path. These passages do not disclose using a previous record for the respective AIMD to determine that the indirect path applies.
Claim Rejections - 35 U.S.C. § 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 and 18-31 are rejected under 35 U.S.C. § 101 because, under their broadest reasonable interpretation, they recite a mental process, and their additional elements neither integrate that exception into a practical application nor amount to significantly more.
Step 1: Statutory Category
Claims 16 and 18-23 recite systems and fall within the machine category. Claims 24-30 recite computer-implemented methods and fall within the process category. Claim 31 recites a non-transitory computer-readable storage medium and falls within the manufacture category. Each claim satisfies Step 1, so the analysis proceeds to Step 2A.
Step 2A, Prong One
Claims 16 and 18-31 recite a mental process consisting of observing, comparing, correlating, evaluating, categorizing, and screening AIMD information according to prior device records, temporal correspondence, patient clinical information, and event-relevance criteria.
Independent Claims Analysis
Claims 16 and 24 are parallel in eligibility substance. Claim 16 recites a processor that reconciles and stores an episode and alert under one label. Claim 24 recites platform-generated information based on reconciliation, associates the episode and alert with a single label, and separately performs labeling. These differences do not change the non-bold mental operations. Claim 31 incorporates claim 24 through stored instructions.
Claim 16 is reproduced below. Non-bold language identifies mental processes. Bold language identifies the additional elements evaluated at Prong Two and Step 2B.
Representative Independent Claim
Claim 16.
(1) A system for managing information relating to at least one patient with at least one active implantable medical device (AIMD) comprising at least one sensor and communicatively coupled to a device manufacturer's platform, said system comprising:
(2) a server comprising at least one processor configured to:
(3) determine, for a respective AIMD of the at least one AIMD, based on a previous record for the respective AIMD, that information is indirectly provided by the respective AIMD to the device manufacturer's platform, and accessing the device manufacturer's platform from among a plurality of device manufacturer's platforms including the device manufacturer's platform;
(4) access, from the device manufacturer's platform, at least one manufacturer information representative of an output of the respective AIMD over time, the manufacturer information comprising a plurality of measurements recorded by the at least one sensor of the respective 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 respective AIMD, the manufacturer information further comprising at least one alert that has been generated using said plurality of measurements or said plurality of parameters;
(5) identify, from the device manufacturer's platform, at least one episode comprising a finite-time duration portion of at least one sensor signal collected by the respective AIMD that is synchronous with at least one of: the at least one alert, or at least one patient triggered alert collected from a user device;
(6) preprocess, with a preprocessing module having a plurality of manufacturer formats associated therewith, the manufacturer information into a homogeneous format;
(7) 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, the first type rule being defined in order to verify a medical relevance of the at least one alert received from the manufacturer information while taking into consideration the patient's clinical information, 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;
(8) provide at least one label associated to the at least one manufacturer information based on a result of said analysis, comprising reconciling, and storing under a single label, the at least one episode and the at least one of the at least one alert or at least one patient triggered alert;
(9) wherein the received at least one manufacturer information comprises information associated to the predefined first sensor event;
(10) wherein the server is comprised into a cloud-based service;
(11) 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, 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, without providing the first alert to the interface and without causing the interface to provide a first alert notification based on the first alert.
The non-bold language broadly requires reviewing a prior AIMD record to infer an information route; deriving parameters from sensor measurements; evaluating measurements or parameters to generate an alert; identifying temporally corresponding episodes and alerts; converting differently formatted information into a common organization; applying clinical and event rules; reconciling related records; assigning labels; and deciding whether an alert should be filtered.
The non-bold portions of limitations (3)-(9) and (11) recite observations, evaluations, and judgments falling within the mental-process grouping of MPEP § 2106.04(a)(2)(III). Limitation (3) reviews a prior record and infers an indirect information route. Limitation (4) requires the accessed information to include either sensor measurements or parameters calculated by the manufacturer platform from those measurements, together with an alert generated using the measurements or parameters. At the claimed level, calculating a parameter and evaluating whether measurements or parameters satisfy an alert criterion are recited without a particular calculation or alert-generation technique and constitute arithmetic and evaluative operations. Limitations (5) and (6) identify temporally corresponding information and reorganize differently formatted information into a uniform format. Limitations (7) and (8) apply clinical and event criteria to determine event occurrence and relevance, reconcile related records, and assign a label. Limitation (9) restricts the information considered to information associated with the predefined event. The filtering portion of limitation (11) uses the label to decide whether an alert should be omitted.
A reviewer using paper records could perform the claimed operations by examining the prior AIMD record, calculating a derived value, determining whether measurements warrant an alert, aligning episodes and alerts by timestamps, copying entries into common columns, applying clinical criteria, placing related entries under one label, and omitting an alert from a report. These are practical human observations, comparisons, and judgments.
Dependent Claims at Prong One
Each dependent claim retains the mental process of its incorporated claim. Claim 18 adds categorizing information according to relevance. Claims 19 and 25 add reviewing timestamps and successive time-series entries, comparing them with drug intervals and probability or value thresholds, judging whether suspected activity is abnormal, and deciding whether to authorize a second alert. Claims 20, 21, and 26 restrict the alert, drug, or clinical information considered in those evaluations.
Claims 22 and 27 add applying another rule to sensor information and determining whether another event occurred. Claim 23 adds a label representing that determination. Claims 28 and 29 restrict the medical conditions and time-varying information evaluated. Claim 30 adds comparing an alert timestamp with a drug interval and sensor information with a threshold, followed by a not-to-notify judgment. Claim 31 incorporates claim 24’s mental process without adding another judicial exception.
Claims 16 and 18-31 therefore recite the abstract idea of mentally reviewing, correlating, evaluating, categorizing, and screening AIMD information. The analysis proceeds to Prong Two.
Step 2A, Prong Two
The additional elements, individually and in their claimed relationships, supply AIMD information, computer implementation, storage, and result communication for the identified mental process. They do not integrate that process into a practical application.
Independent Claims Analysis
Additional Elements of the Independent Claims
The additional elements of claim 16 are the system; AIMD, sensor, manufacturer platform, and user device; server and processor; access to the selected manufacturer platform and its measurements, parameters, episodes, and alerts; preprocessing module; storage; cloud-based service; and output, interface, and notification operations. Claim 24 recites the corresponding computer implementation, AIMD and sensor, manufacturer platforms, user device, platform and information access, preprocessing module, cloud-based server, output, interface, and notification operations, without claim 16’s processor-performed storage.
Individual Additional Elements Evaluation
The AIMD, sensor, manufacturer platform, user device, platform selection, and access to measurements, parameters, episodes, and alerts provide the information to which the mental process is applied. The claims do not change how the AIMD senses a condition, how the platform generates an alert, or how a network transfers information. The Specification defines the manufacturer platform as software and servers that store, analyze, display, or transfer AIMD data. Specification, p. 9. These limitations are preparatory data gathering and confinement to an AIMD-monitoring environment under MPEP §§ 2106.05(g) and (h). Providing information “for diagnosis” neither treats the patient nor controls the AIMD.
The server, processor, cloud-based service, computer implementation, and preprocessing module execute the mental process on computer components. Although preprocessing must produce a “homogeneous format,” the claim recites no schema, parser, field mapping, conversion rule, or processing sequence that produces it. The Specification likewise states that the module verifies and may convert information into a “desired predefined format,” without identifying a conversion mechanism. Specification, p. 15. University of Florida Research Foundation, Inc. v. General Electric Co., 916 F.3d 1363, 1368-69 (Fed. Cir. 2019), found no computer improvement where comparable device-specific format conversion was stated in “purely functional terms.” These elements use computers as tools under MPEP §§ 2106.05(a) and (f).
The storage, output, interface, alert-removal, and notification operations retain or communicate the result of the mental screening. Claim 16 stores related records under one label without reciting a new storage structure or retrieval operation. Claims 16 and 24 omit the first alert from an interface notification without changing the interface, transmission protocol, or notification mechanism. These limitations are recordkeeping and result communication following the exception under MPEP §§ 2106.05(f) and (g).
Combination Additional Elements Evaluation
As an ordered combination, the additional elements obtain AIMD information from a selected manufacturer platform, standardize its format, store a label, and communicate a notification without the screened alert. The Specification attributes the benefits to accommodating manufacturers that “may use different format” and to “reduce the quantity of alerts displayed.” Specification, pp. 15 and 18. The claims achieve those results through the identified mental operations of standardizing information, correlating records, applying clinical criteria, labeling results, and screening alerts. The remaining elements recite no conversion mechanism, altered data structure, modified AIMD operation, or changed network or interface operation. The combination therefore does not improve the recited technology under MPEP § 2106.04(d)(1) or otherwise integrate the mental process into a practical application.
Dependent Claims Analysis
Claims 20-22 and 26-29 add no new additional element beyond those inherited from claims 16 or 24. Claims 20 and 26 narrow the alert and drug; claim 21 narrows the clinical information; claims 22 and 27 narrow the manufacturer information to time-varying sensor information and add a second rule-based event determination; and claims 28 and 29 narrow the event or sensor information evaluated. These recitations specify the information, criteria, or mental evaluation identified at Prong One. They add no new component, data-acquisition step, or technical operation. Their inherited additional elements remain governed by the independent-claim Prong Two analysis.
Claim 18 adds processor-performed electronic recording of information labeled not relevant. Using the relevant/not-relevant distinction remains part of the mental categorization identified at Prong One. The remaining electronic recordkeeping uses the inherited processor without changing processor or storage operation. It is computer implementation of the exception under MPEP § 2106.05(f), not a technological improvement under MPEP § 2106.05(a).
Claims 19 and 25 add a data storage, automatic recording in that storage, and triggering a second alert on the interface; claim 19 also places the not-to-notify result in a remote monitoring platform. These elements store and communicate results after the claimed comparisons and abnormality determination. They recite no particular storage structure, alert protocol, or changed interface operation and therefore constitute computer implementation and post-solution activity under MPEP §§ 2106.05(f) and (g).
Claim 23 adds notification through a remote monitoring platform. The platform merely communicates the label produced by the second-rule determination and does not change how the platform or network operates.
Claim 30 adds automatic computer labeling of manufacturer information as not to be notified after the third-rule comparisons. It specifies the result assigned by the inherited computer implementation without reciting a new processing architecture or labeling mechanism. The additional elements of claims 23 and 30 therefore use computers to implement or communicate the mental result under MPEP §§ 2106.05(f) and (g).
Claim 31 adds a non-transitory computer-readable storage medium, instructions, and a computer that executes the instructions to perform claim 24. These elements place the inherited method on generic computer components without reciting a particular machine arrangement integral to performance of the method. Under MPEP § 2106.05(f), this is computer implementation of the exception.
Individually and in combination with the inherited elements, the dependent-claim additional elements record, store, execute, or communicate results. They recite no changed AIMD sensing, data structure, processor operation, storage architecture, communication protocol, or interface operation. Claims 18-23 and 25-31 therefore do not integrate the mental process into a practical application under MPEP §§ 2106.05(a)-(c), and 2106.05(e)-(h).
Step 2B
The additional elements identified at Prong Two, considered individually and in their actual ordered combination, do not supply an inventive concept amounting to significantly more than the identified mental process.
Additional Elements of the Independent Claims
The additional elements remain the AIMD, sensor, manufacturer platform, user device, server, processor, platform and information access, preprocessing module, storage, cloud-based service, output, interface, and notification operations of claims 16 and 24.
Independent Claims Analysis
Individual Additional Elements Evaluation
The Specification states that AIMDs are “commonly used” to treat or monitor medical conditions and may store and transmit information for remote monitoring. Specification, p. 1. The AIMD and sensor are claimed as information sources, while the manufacturer platform and user device supply or transfer the resulting records. Their claimed functions are data gathering under MPEP § 2106.05(g). Platform selection and access also use generic receipt and transmission of data over a network, functions identified as well-understood, routine, and conventional when claimed at this level of generality. MPEP § 2106.05(d)(II).
The Specification defines a processor as a computer, microprocessor, integrated circuit, or programmable logic device and implements the disclosed elements on “appropriately programmed general-purpose devices.” Specification, pp. 8 and 13. It describes the cloud service as multiple computer devices that communicate with, retrieve data from, or transmit data to external systems, and identifies RAM, EEPROM, Flash memory, and SSD storage. Specification, pp. 14-15. It also describes interface input and output means as “well known.” Specification, p. 16. The server, processor, computer, cloud service, storage, output, interface, and notification components thus perform the generic processing, recordkeeping, storage, and network-communication functions recognized in MPEP § 2106.05(d)(II).
The preprocessing module is not claimed with a schema, parser, mapping, conversion rule, or special-purpose architecture; it is the functional component assigned the homogeneous-format result. The prior-record determination, standardization, episode-alert association, clinical-rule application, labeling, and alert screening are the mental process identified at Prong One and cannot provide their own inventive concept. BSG Tech LLC v. BuySeasons, Inc., 899 F.3d 1281, 1290 (Fed. Cir. 2018).
Combination Additional Elements Evaluation
In the claimed combination, an AIMD sensor supplies information through a manufacturer platform; a cloud-based server or computer accesses the selected platform; a processor-implemented preprocessing module supports standardization; storage retains the label; and an output and interface communicate a notification without the screened alert. The Specification describes the same ordinary path from AIMD measurements, through a transmitter, network, and manufacturer platform, to the monitoring system and medical professional. Specification, p. 24 and Figure 5. No claimed placement or interaction changes how those components sense, transmit, process, store, or output information. GoTV Streaming, LLC v. Netflix, Inc., Nos. 2024-1669, 2024-1744, slip op. at 24-25 (Fed. Cir. Feb. 9, 2026), requires a specific implementation that improves how ordinary computer and network functions operate, not merely functional language stating a result. The ordered combination therefore does not amount to significantly more.
Dependent Claims Analysis
Claims 20-22 and 26-29 add no new additional element for Step 2B. Their alert, drug, clinical-information, sensor-information, medical-condition, and rule-based evaluation limitations form part of the mental process identified at Prong One. The exception itself is not treated as its own inventive concept. These claims retain the additional elements and Step 2B result of their incorporated claims.
Claim 18 adds electronic recordkeeping of labeled information. The Specification implements the disclosed functions on appropriately programmed general-purpose devices having processors, memory, and input/output interfaces. Specification, p. 13. Electronic recordkeeping and storing or retrieving information are recognized well-understood, routine, and conventional computer functions under MPEP § 2106.05(d)(II)(iii)-(iv). The added function therefore does not provide an inventive concept.
Claims 19 and 25 add data storage, automatic recording, and a second interface alert; claim 19 also recites the remote monitoring platform. The Specification describes general-purpose processors, memory, input/output interfaces, cloud computer systems, and ordinary communication functions. Specification, pp. 13-16. Receiving or transmitting data, electronic recordkeeping, and storing or retrieving information are recognized functions under MPEP § 2106.05(d)(II)(i), (iii), and (iv). These additions do not amount to significantly more.
Claim 23 adds notification through the remote monitoring platform. The Specification defines notification as a message sent by email, SMS, or a third-party entity. Specification, p. 10. This is generic data transmission recognized under MPEP § 2106.05(d)(II)(i), not an inventive communication mechanism.
Claim 30 adds automatic computer labeling after the abstract timestamp, drug-interval, sensor-value, and threshold comparisons. The Specification describes implementation using general-purpose processors and computer devices. Specification, pp. 13-15. The added automation performs generic electronic processing and recordkeeping without a particular algorithm or computer arrangement and therefore supplies no inventive concept under MPEP § 2106.05(d).
Claim 31 adds a storage medium, stored instructions, and a computer. The Specification describes instructions stored in ordinary hardware, software, firmware, disk, RAM, and ROM. Specification, pp. 8 and 13. Storing and retrieving information in memory is recognized under MPEP § 2106.05(d)(II)(iv). These generic components merely execute the inherited method.
As an ordered combination, the added elements follow the ordinary path of recording, storing, executing, and communicating information. No dependent claim recites a non-generic placement, interaction, or configuration that changes the operation of the computer or AIMD-monitoring technology. Claims 18-23 and 25-31 therefore do not recite additional elements amounting to significantly more under MPEP § 2106.05(d).
Claims 16 and 18-31, considered individually and as ordered combinations, do not integrate the identified mental process into a practical application and do not recite additional elements amounting to significantly more. The claims therefore do not satisfy 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, and 21–23, are rejected under 35 U.S.C. § 103 as being unpatentable over US20130317852A1-Worrell, and further in view of US20170257341A1-Arsenault and WO2020185938A1-Zhao.
Claim 16.
Worrell teaches, A system for managing information relating to at least one patient with at least one active implantable medical device (AIMD) comprising at least one sensor and communicatively coupled to a device manufacturer's platform, said system comprising: (Worrell, implantable pacemakers and automatic internal cardiodefibrillators [0005]; wireless connectivity and internet based access to data [0002]; each manufacturer has a proprietary software platform [0004]; the implanted device obtains a measurement [0103]; lead information includes sense, impedance, pacing threshold [0086], [0105]; [0006]–[0007], [0042]–[0045], [0095]–[0096]; Figs. 1, 2, 10, 19, and 27.)
a server comprising at least one processor configured to: (Worrell, MDI Portal 100 includes at least one computing device and processing device [0006]–[0007]; computing device 108 is in data communication with the HIE, Device Vendor, and Dedicated Data Store [0041]–[0043]; its software engines are executed … to perform particular functions [0052]–[0054]; interface displays are generated by a server and displayed on a client computing device [0109]; Fig. 1.)
determine, for a respective AIMD of the at least one AIMD, ; (Worrell, database of patients for all Device Vendors, [0043]; determine the pertinent Device Vendor 104, [0055]; determines whether the patient has a home monitoring device, [0056]; first…manufacturer…second different…manufacturer, [0009].)
Worrell’s registry covers all device vendors, associates each patient and device with its vendor, and is queried to determine the pertinent vendor. This reads on selecting and accessing the corresponding manufacturer platform from among multiple manufacturer platforms.
access, from the device manufacturer’s platform, at least one manufacturer information representative of an output of the respective AIMD over time, the manufacturer information comprising a plurality of measurements recorded by the at least one sensor of the respective 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 respective AIMD, the manufacturer information further comprising at least one alert that has been generated using said plurality of measurements or said plurality of parameters;; (Worrell, receives relevant information from…the Device Vendor Dedicated Data Store, [0057]; measured voltage…sense, impedance, pacing threshold, [0085]–[0086]; measurement by the implanted device…satisfies the condition, [0103]; see Figs. 25–27, [0045], [0057], [0085]–[0087], [0101]–[0104].)
Worrell accesses vendor-maintained device and interrogation information containing multiple sensor measurements over time. Worrell further displays problematic-event indicators and generates alert messages when implanted-device measurements satisfy alert conditions, which a POSITA would read as an alert generated using the claimed measurement branch
identify, from the device manufacturer’s platform, at least one episode comprising a finite-time duration portion of at least one sensor signal collected by the respective AIMD that is synchronous with at least one of: the at least one alert, or at least one patient triggered alert collected from a user device; (Worrell, interrogation data…during the patient’s last episode, [0045]; type…date…time…and duration…electrocardiogram obtained from…tracings during patient episodes, [0092]–[0093]; indicators…of problematic events…when…a measurement…satisfies the condition, [0103]–[0104]; see Figs. 17, 25–26.)
Worrell identifies time-bounded episodes containing AIMD ECG tracings and specifies each episode’s date, time, and duration. Its Heart Rate History places problematic-event indicators at measurements satisfying alert conditions and links each indicator to the event readings; a POSITA would understand the bounded ECG episode as temporally corresponding to the alert indicator.
preprocess, with a preprocessing module having a plurality of manufacturer formats associated therewith, the manufacturer information into a homogeneous format; (Worrell, formatting…varies for each manufacturer and…device model…information must be mapped such that standardized information can be provided, [0095]; configured for interrogating multiple types…recognize the…type and model such that the information can be properly formatted, [0096]; presented in a uniform fashion irrespective of the device manufacturer, [0064]; see Fig. 19.)
Worrell’s MDI Portal recognizes multiple implantable-device types and models, maps differently formatted manufacturer information, and extracts and formats raw or PDF interrogation data before use. The resulting device information is standardized and presented uniformly regardless of manufacturer, satisfying the claimed preprocessing module and homogeneous format.
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 (Worrell, alert/abnormal value…includes a condition, [0101]; measurement by the implanted device…satisfies the condition, [0103]; indicators…of problematic events, [0103]–[0104]; Figs. 22–26.)
Worrell’s alert/abnormal-value condition is the claimed first type rule. The implanted-device measurement satisfying that condition is the predefined first sensor event, and the resulting problematic-event indicator or alert message is the alert generated using that measurement.
(Worrell, change in weight…the patient’s blood pressure, [0091]; prominently identifies health information that needs attention, [0101]; abnormal findings which may require immediate action, [0102].)
Worrell discloses patient clinical information, including weight and blood pressure, and rules identifying alerts or abnormal findings requiring attention.
said analysis comprising applying each first type rule to the received at least one manufacturer information in order to determine, ; (Worrell, measurement by the implanted device…satisfies the condition, [0103]; indicators…of problematic events, [0103]–[0104].)
Worrell determines that a sensor event occurred when an implanted-device measurement satisfies an alert condition and identifies the resulting event as problematic
provide at least one label associated to the at least one manufacturer information based on a result of said analysis, comprising ; (Worrell, green episodes…red episodes, [0092]–[0093]; condition…will change the color…alert message is generated, [0101]; indicator…display[s] the occurrence…links…readings, [0103]–[0104].)
Worrell provides analysis-derived red, yellow, or green indicators associated with manufacturer information. Its indicators identify problematic events and provide links to the corresponding episodes and readings, thereby disclosing labels associated with episodes and alerts.
wherein the received at least one manufacturer information comprises information associated to the predefined first sensor event; (Worrell, interrogation data…during the patient’s last episode, [0045]; types of episodes, [0087]; type…date…time…duration…electrocardiogram…during patient episodes, [0092]–[0093]; readings…for the selected event, [0104].)
Worrell’s received interrogation information contains episode type, date, time, duration, ECG tracing, and event readings. These data describe and are directly associated with the implanted-device measurement or episode satisfying the alert condition, thereby reading on information associated with the predefined first sensor event.
wherein the server is comprised into a cloud-based service;( Worrell [0097], [0109])
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, (Worrell, color coded such that issues…are readily apparent, [0082]; identifies health information that needs attention, [0101]; indicators…of problematic events, [0103]–[0104].)
Worrell’s MDI Portal outputs device information through color-coded tabs and event indicators. The labels distinguish normal findings from abnormal or problematic events requiring attention, thereby representing event occurrence and diagnostic relevance.
comprising, Worrell, tabs are color coded, [0082]; condition…will change the color…alert message is generated, [0101]; Figs. 22–24.)
Worrell uses color indicators to characterize displayed information and generates an alert message when an alert condition is satisfied. This discloses providing output and a notification through an interface.
Worrell supplies the AIMD, multiple manufacturer platforms, vendor access, episode/alert-data environment, and interface, leaving only the previously identified record-based routing, clinical-relevance, single-label reconciliation, and label-controlled filtering. See above, Worrell does not explicitly supply a previous device record to determine the indirect route. Arsenault’s previous record is the mapping-table entry because the table “maintain[s] the associations” between a device identity and its corresponding provider network; its timestamp shows when that association was “created or updated.” The control server then “retrieves . . . the stored identity,” thereby identifying the corresponding network and application server. The resulting device identifier is “used to establish a path” through the gateway and common network to that server, which constitutes indirect provision of the device information. Because Arsenault discloses first and second provider networks, the stored association selects the appropriate destination among multiple destinations. Arsenault, [0028], [0033]–[0034], [0049]–[0052], [0055]–[0062]. A POSITA would have applied Arsenault’s timestamped association-update technique to Worrell’s existing AIMD/vendor registry because Worrell relies on that registry to determine the pertinent Device Vendor, while Arsenault expressly addresses devices changing their service provider network associations by maintaining up-to-date associations. Both systems associate a device identity with the corresponding remote destination; therefore, adding Arsenault’s timestamp, validation, and update logic to Worrell’s registry would have been the predictable application of a known routing technique to prevent a stale vendor association from directing access to the wrong platform. Worrell, [0043], [0050], [0055]–[0057]; Arsenault, [0028], [0033]–[0034], [0049]–[0052].
Worrell presents clinical and device information but does not use the clinical information as part of the alert-relevance rule. Zhao teaches determining a patient-specific alert criterion in real-time based on the patient’s previous health measurements, diagnostic and medication history, current health state, and prior-alert validity. Zhao then classifies the resulting alert using the triggering measurement, previous measurements, and EHR data including clinical test results, medication history, family history, diagnoses thereby evaluating the alert’s medical significance in view of that patient’s clinical information. Zhao, [0124]–[0126], [0133]–[0135]. A POSITA would have applied Zhao’s patient-specific alert criteria and classification rules to Worrell’s portal because Worrell already processes all of the received data and presents differences between normal and abnormal findings, but does not use the patient’s clinical information to verify an alert’s medical relevance. Zhao expressly teaches that patient-specific criteria reduce false alerts and that clinical-history inputs improve classification of future alerts. Worrell’s HIE/EMR integration already provides the required patient information; thus, adding Zhao’s software rule at Worrell’s alert-analysis stage would predictably identify whether the triggering sensor event occurred and was diagnostically relevant for that patient, without altering Worrell’s data-acquisition or interface functions. Worrell, [0041], [0049]–[0051], [0064], [0082]; Zhao, 0125]–[0126], [0133]–[0135].
Worrell’s event determination is not dependent on patient clinical information. Zhao detects a sensor event using a threshold, particular feature or rhythm, or deviation from the patient’s baseline, and then applies patient-specific clinical criteria to resolve the resulting alert as true or false. Zhao,[0124]–[0128]. A POSITA would apply Zhao’s criteria to Worrell’s alert analysis to reduce the generation of false alerts, using Worrell’s available patient and device data. The combination predictably determines both event occurrence and patient-specific clinical relevance. Worrell associates alerts and episode information, but does not store them under a common analysis-derived label. Zhao stores each alert in one table row with its ID, the health measurement that resulted in the alert, measurement time, previous measurements, and status. The alert may be resolve[d]…as either true or false, with related actions preserved to create an audit trail and recorded in the EHR. Zhao, [0127], [0131], [0143].
Worrell may categorize or display alerts but does not remove an existing alert from the output based on its label. Zhao classifies initial alerts as true or false, resolves false alerts, and describes the process as alert filtering that leaves the true alerts for tiered handling. Zhao, [0128], [0146], [0150]–[0152]. A POSITA would place Zhao’s status-controlled filter before Worrell’s downstream alert output to reduce triage burden and focus intervention on critical alerts, benefits Zhao expressly identifies. A false/resolved label would predictably retain the alert record while excluding that alert from Worrell’s output.
Worrell ordinarily provides alerts through its interface rather than withholding the filtered alert and its notification. Zhao teaches. When the analytics layer determines that the true alert is low, medium, or high priority, it can transmit the alert through the corresponding downstream path; false alerts are filtered, leaving…true alerts for escalation. Zhao, [0140]–[0142], [0146]. To reduce triage burden and focus clinicians on critical alerts, a POSITA would place Zhao’s classification gate before Worrell’s clinician-facing output. A false/resolved alert would not reach that interface and therefore could not cause its notification.
Claim 18.
Worrell in combination with Zhao and Arsenault’s 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 . (Worrell, store digital data, [0053]; normal findings for the device that do not require an immediate action, [0082]; [0092], Figs. 7 and 16, prominently identifies health information that needs attention, [0101]; alert message is generated, [0101]; [0102]-[0104], Figs. 22-2)
Worrell teaches receiving and processing Device Vendor information, storing digital data, and distinguishing device findings with color labels. Green denotes normal findings for the device that do not require an immediate action, while abnormal information is used to prominently identifies health information that needs attention and generate selectable alerts. Worrell therefore teaches exploiting information labeled relevant, but does not teach record the at least one labeled manufacturer information labelled as not relevant. Zhao teaches the missing feature. Health-measurement data may be permanently stored; a dashboard can classify the alert as true or false and retain the status of the resolved alert. Zhao’s analytics layer can automatically resolve a false alert using a patient-specific criterion or baseline, without human input. Thus, when applied to Worrell’s manufacturer/device information, Zhao teaches retaining the information record with a false, and therefore not-relevant-for-diagnosis, classification while using and escalating true alerts. Zhao [0116], [0125]-[0134], Fig. 9; Before the effective filing date, a POSITA would have combined Worrell with Zhao by applying Zhao’s patient-specific true-or-false alert classification to Worrell’s color-coded manufacturer/device information and storing the resulting classification and resolution status with the corresponding record. Zhao expressly explains that patient-specific criteria reduce the generation of false alerts.
Claim 19.
Worrell in combination with Zhao and Arsenault’s teaches,
The system according to claim 16, wherein:
the at least one manufacturer information comprises
plurality of alert information relating to a suspected abnormal activity of the patient's heart, (Worrell, receives relevant information from the Device Vendor 104 [0057]; graphical timeline of the patient’s heart history 226 including the last five occasions of episodes [0082]; two indicators 274 of problematic events [0103].)
Worrell receives device-vendor information containing multiple cardiac episodes and displays indicators identifying problematic events.
each alert information in the plurality of alert information being associated to a time stamp in a plurality of time stamps representing the-a time at which the alert information is generated, (Worrell, the type of episode, the date of the episode, the time of the episode [0092]–[0093]; A/V rate detection [0092]–[0093]; Fig. 17; a measurement that satisfies the condition [0103].)
Figure 17 presents a detected VT episode together with its type, date, time, A/V rate-detection information, duration, and corresponding tracing. Because the VT designation is the device’s analysis result identifying the abnormal episode, a POSITA would reasonably understand its associated episode date and time as representing when that VT alert information was generated.
the plurality of time stamps providing a time series in which each alert information is at a different time; (Worrell, the last five occasions of episodes [0082]; prior issues with blood pressure, heart rate and spO2 are visible, and displayed in a timeline [0107], [0093])
Worrell expressly presents multiple prior episodes or issues in timelines, reasonably establishing distinct event times.
the patient's clinical information ; (Worrell, information regarding the patient’s medicine information may also be displayed in the MDI Portal 100 [0108].)
;
; (Worrell, the last five occasions of episodes [0082]; If there is an episode within the last seven days Fig. 23; Heart Rate History graph showing two indicators 274 of problematic events [0103]; each of the events that satisfied the condition [0104]; heart rate … information is tracked [0107].)
Worrell maintains heart-history and heart-rate time-series information. Figure 23 applies the condition “If there is an episode within the last seven days” and assigns the resulting condition a red alert classification. That condition is equivalent to a value threshold of at least one episode within the seven-day interval. Paragraphs [0103]–[0104] further explain that the history graph identifies problematic events when measurements satisfy the applicable condition.
wherein said at least one processor is then configured to determine whether or not the suspected abnormal activity is abnormal activity in the patient , (Worrell, a condition, which when satisfied will change the color of the respective tab [0101]; indicators 274 of problematic events [0103].)
and only upon determination that the suspected abnormal activity is abnormal activity, the at least one processor is configured to trigger a second alert on the interface. (Worrell, when a measurement by the implanted device obtains a measurement that satisfies the condition [0103]; the respective alert message is generated [0101].)
Worrell teaches that patient medicine information may be displayed in the MDI Portal. Worrell [0108]. Worrell therefore already places medication information in the same patient record as the timestamped cardiac episodes, but does not structure it as an intake with an associated interval. Zhao teaches monitoring medication effects, enforcing medication adherence, and detecting whether patients take medication in a timely manner under a medicinal protocol. Zhao [0006], [0016]. Zhao also uses medication history when dynamically determining alert criteria in real time. Zhao [0126]. A POSITA would have combined Zhao’s medication-adherence data with Worrell’s patient record because determining whether medication was taken timely under a protocol predictably requires representing the medication and its applicable administration period. Adding those schedule/intake fields to Worrell would permit its alerts to be evaluated using the patient-specific clinical context expressly recommended by Zhao.
Worrell teaches multiple dated and timed cardiac episodes forming a heart-history timeline. Worrell [0082], [0092]–[0093]. Worrell therefore supplies the alert timestamps and temporal series retained in the modified system. Worrell does not teach comparing each alert timestamp with a drug-intake interval. Zhao teaches that medication history can determine a patient-specific alert criterion in real time, that an alert record includes the time of the corresponding measurement, and that medication changes may be marked on a graph of patient measurements over time. Zhao [0126]–[0127], [0142]. A POSITA would have combined these teachings by supplying Worrell’s episode timestamp and Zhao’s medication-intake to the patient-specific rule. Comparing whether alert time falls within medication interval is the direct software operation needed to use Zhao’s medication context temporally. It preserves the ordinary functions of both data items: the timestamp locates the event, while the interval identifies the applicable clinical context. The motivation is Zhao’s express objective of using medication information and patient-specific criteria to reduce false alerts. Zhao [0125]–[0128].
Worrell teaches storing and presenting cardiac episode information and generating interface messages when alert conditions are satisfied. Worrell [0092]–[0093], [0101]–[0104]. Worrell does not teach automatically recording the manufacturer information corresponding to an in-interval timestamp as labeled information not to be notified. Zhao determines alert criteria in real time using “diagnostic and medication history,” can “resolve alerts without input from a human agent,” and records “whether the alert has been resolved, and the status of the resolved alert.” Zhao [0126], [0128], [0131]. A POSITA would have applied Zhao’s medication-aware automatic-resolution technique to Worrell’s timestamped episodes by comparing each episode time with the drug-intake interval, so alert validity reflects the medication context at the event time, and automatically assigning Zhao’s stored false/resolved status to in-interval information. This predictable modification implements the not-to-notify label and would “reduce the generation of false alerts.” Zhao [0125].
Worrell teaches identifying problematic cardiac events when implanted-device measurements satisfy an alert condition. Worrell [0101], [0103]–[0104]. Worrell does not teach determining abnormal activity based on whether manufacturer information remains after label-controlled removal. Zhao teaches generating and storing an initial-alert record, automatically resolving an alert as false when patient-specific secondary criteria are not satisfied, recording whether the alert is resolved and its resolution status, and permitting the system to resolve the alert as either true or false, and if true, escalate the alert. (Zhao [0127]–[0131].) Zhao subsequently classifies only true alerts by priority and transmits or escalates those surviving alerts. (Zhao [0132]–[0133], [0139]–[0142].) Zhao’s example filters alerts as false, leaving approximately 15 true alerts, of which only qualifying alerts are escalated. (Zhao [0146].) Zhao therefore supplies the missing causal relationship: a stored status removes false alerts from the downstream decision set, while the alerts remaining after that removal proceed to further classification and possible notification. A POSITA would have applied Zhao’s known alert-resolution gate to Worrell’s stored cardiac-event records by configuring Worrell’s processor to: (1) retain a status for each event; (2) treat an event labeled not to be notified as Zhao treats a false/resolved alert; (3) remove that event from the set evaluated under Worrell’s abnormality conditions; and (4) apply Worrell’s abnormality threshold and generate an interface alert only for an event remaining in the eligible set. Zhao expressly associates this filtering and tiered escalation with reducing unnecessary review while directing intervention toward genuinely critical alerts, which complements Worrell’s objective of identifying cardiac information requiring attention.
Worrell teaches a heart-history time series and temporally defined alert conditions. Figure 23 applies a seven-day episode condition, and paragraphs [0101]–[0104] generate an indicator when a condition is satisfied. Worrell does not teach continuously comparing the alert time series with abnormality-classification intervals associated with a probability or value threshold, after excluding information labeled not to be notified. Zhao teaches determining whether cardiac or other health information satisfies an alert criterion, including a minimum or maximum value, and dynamically determining that criterion in real-time from the patient’s previous measurements. Zhao also depicts measurements over adjustable periods of days, weeks, months, or years with threshold lines above or below which an alert results. (Zhao [0120], [0124]–[0126], [0148].) Zhao records an alert’s resolved status, resolves alerts as true or false, performs subsequent priority classification only for true alerts, and describes false alerts being removed, leaving approximately 15 true alerts, only some of which are escalated. (Zhao [0128], [0131]–[0133], [0146].) A POSITA would have applied Zhao’s real-time threshold-evaluation and false-alert-filtering technique to Worrell’s manufacturer-supplied cardiac-event timeline. Specifically, Worrell’s processor would update the applicable time interval when new event information is received, exclude records carrying the previously assigned not-to-notify status as Zhao excludes false/resolved alerts, and compare only the remaining events with Zhao’s value or confidence criterion. An event would be classified as abnormal and escalated only when it both remains eligible and satisfies the threshold. Zhao explains that this filtering and tiered escalation saves review time and directs intervention toward truly critical alerts, complementing Worrell’s objective of prominently identifying health information requiring attention.
Worrell teaches generating an interface alert message when its abnormal-value condition is satisfied. Worrell [0101]–[0104]. Worrell does not teach triggering a second interface alert only after determining that the unremoved suspected activity satisfies the probability or value threshold. Zhao teaches an ordered, two-stage alert process. The analytics layer first generates an initial alert, determines whether it is true or false, records its resolved status, and permits escalation if true. (Zhao [0127]–[0132].) Only true alerts proceed to priority classification and subsequent transmission. (Zhao [0133], [0139]–[0142].) For a qualifying high-priority true alert, Zhao generates and transmits an escalation report. (Zhao [0142].) Zhao’s example filters initial alerts as false, leaving approximately 15 true alerts, and escalates only the qualifying survivors. (Zhao [0146].) A POSITA would have applied Zhao’s conditional escalation technique to Worrell’s existing interface-alert routine. Worrell’s manufacturer-originated cardiac alert would serve as the initial alert. After applying the previously established not-to-notify exclusion and threshold determination, the processor would invoke Worrell’s interface-message routine only when the remaining event is determined to be abnormal; otherwise, the routine would not execute. Thus, Worrell’s existing alert message becomes the claimed second alert, downstream from the original manufacturer alert. Zhao expressly teaches this initial-alert, true/false-resolution, and survivor-only escalation sequence to reduce unnecessary review, save time and expense, and direct intervention toward truly critical alerts.
Claim 21.
Worrell in combination with Zhao and Arsenault’s teaches,
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. (Worrell, the patient’s weight, blood pressure, blood glucose, heart rate and spO2 information is tracked [0107], Figs. 29–30.)
Claim 22.
Worrell in combination with Zhao and Arsenault’s teaches,
for each patient, the manufacturer information further comprises at least one sensor information(Worrell, receives raw tracing data and episode details from the device-vendor source [0057]–[0059], [0093], Fig. 17.)
representative of a physiological and/or physical activity of the patient as a function of time, (Worrell, Heart Rate History graph and event readings [0103]–[0104]; historical heart rate allows review of trending information for the particular patient [0107].)
the analysis of the received manufacturer information further comprising applying at least one second type rule to said sensor information(Worrell, applies an alert or abnormal-value condition to implanted-device measurements [0101]–[0103].)
in order to determine whether a predefined second sensor event, associated to said second type rule, has occurred. (Worrell, a problematic-event indicator is produced when an implanted-device measurement satisfies the condition [0103]–[0104].)
Claim 23.
Worrell in combination with Zhao and Arsenault’s teaches,
The system according to claim 22,
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,
(Worrell, satisfaction of an alert condition changes the corresponding tab color and causes the respective alert message to be generated [0101]–[0102]. The Internet-accessible, server-generated MDI Portal supplies the remote platform [0043], [0109].)
The displayed red, yellow, or green status is a rule-derived label associated with the corresponding manufacturer information.
said at least one label being representative of each corresponding predefined second sensor event detected.
(Worrell, red and yellow indicators identify abnormal conditions, while selecting a problematic-event indicator displays the event and readings that satisfied the condition [0102]–[0104].) )
Claim(s) 20 is rejected under 35 U.S.C. § 103 as being unpatentable over US20130317852A1-Worrell, and further in view of US20170257341A1-Arsenault and WO2020185938A1-Zhao and further view of US 20210020294 - Bharmi
Claim 20.
Worrell in combination with Arsenault’s teaches,
The system according to claim 19, wherein the alert information includes an alert relating to atrial fibrillation burden, and the drug is an anticoagulant drug. (Worrell, Atrial burden [0091], Fig. 15; alert/abnormal-value conditions and generated alert messages [0101], Figs. 22–23.)
Worrell provides an implanted-device portal that already displays atrial-burden and medicine information and generates an interface alert when an alert/abnormal-value condition is satisfied, but it does not expressly configure an alert around AF burden or identify the medicine as an anticoagulant. Bharmi supplies that exact clinical relationship: implant-derived AF burden and anticoagulant information are jointly evaluated to produce an INR diagnosis and treatment notification [0028], with warfarin adjustment used to target a prescribed INR range [0030]. A POSITA would have implemented Bharmi’s AF-burden/anticoagulation rule as an additional alert condition in Worrell’s CHF Watch portal because Bharmi expressly demonstrates that those inputs are useful for generating an anticoagulation-treatment notification.
Free Prior Art
Unlike claim 16, claim 24 requires the manufacturer-platform information to be generated based on reconciliation of the finite sensor episode and its alert, with both associated with a single label. Worrell (US 2013/0317852 A1), Arsenault (US 2017/0257341 A1), and Zhao (WO 2020/185938 A1) support the rejection of claim 16 but do not disclose this additional actor-and-reconciliation relationship, therefore obvious rational for Claim 24-31 are overcome.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to 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.
/J.D.R./Examiner, Art Unit 3684
/Shahid Merchant/Supervisory Patent Examiner, Art Unit 3684
Prosecution Insights