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 Claims
Claims 1-21 are currently pending and have been examined.
Claims 1, 6-8, 15 and 18-19 have been amended.
Claim 21 is new.
Claims 1-21 have been rejected.
Claim Interpretation
The Examiner notes that “the medical platform having a cloud computing architecture” and “the monitoring interval tracker of the medical platform” are being interpreted as software implementing the functions as there is no specific hardware recited in the claim language.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-21 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. The claimed invention is directed to an abstract idea without significantly more. Claims 1-21 are directed to a method which is one of the statutory categories of invention. (Step 1: YES).
Independent Claim 1 discloses a method for managing a cardiac monitoring device, the method comprising: receiving, at a medical platform having a cloud computing architecture, transmission data for a patient, the transmission data captured through one or more interrogations of the cardiac monitoring device and communicated to the medical platform over a network, the medical platform being in communication with a clinic system associated with a clinic treating the patient, the clinic system providing access to the medical platform through a provider portal; accessing a patient care modality rule from a rules database using a monitoring interval tracker of the medical platform; generating a monitoring interval associated with the cardiac monitoring device using the monitoring interval tracker, the monitoring interval having an end date based at least partly on the patient care modality rule; detecting a received date of the transmission data using the monitoring interval tracker; calculating whether the received date is later than the end date using the monitoring interval tracker; generating a docket report for the transmission data; receiving an approval timestamp corresponding to the docket report; calculating whether the approval timestamp indicates an approval date later than the end date using the monitoring interval tracker; accessing an interval extension rule from the rules database using the monitoring interval tracker; automatically generating a monitoring interval extension according to the interval extension rule using the monitoring interval tracker, the monitoring interval extension having an extended end date based at least partly on whether the received date is later than the end date or whether the approval date is later than the end date; and automatically generating a date of service (DOS) for the transmission data, the DOS being the extended end date of the monitoring interval extension.
Independent Claim 8 discloses a method for managing a cardiac monitoring device, the method comprising: receiving, at a medical platform having a cloud computing architecture, transmission data for a patient, the transmission data captured through one or more interrogations of the cardiac monitoring device and communicated to the medical platform over a network, the medical platform being in communication with a clinic system associated with a clinic treating the patient, the clinic system providing access to the medical platform through a provider portal; accessing a plurality of patient care modality rules from a rules database using a monitoring interval tracker of the medical platform; generating a first monitoring interval associated with the cardiac monitoring device using the monitoring interval tracker, the first monitoring interval having a first end date based at least partly on a first patient care modality rule of the plurality of patient care modality rules; generating a second monitoring interval associated with the cardiac monitoring device using the monitoring interval tracker, the second monitoring interval having a second end date based at least partly on a second patient care modality rule of the plurality of patient care modality rules, the second end date being different than the first end date; generating, for the transmission data, a first docket report associated with the first patient care modality rule; generating, for the transmission data, a second docket report associated with the second patient care modality rule; receiving an approval timestamp after the received date and indicating an approval date corresponding to only one the first docket report or the second docket report; calculating whether the approval date is later than the first end date using the monitoring interval tracker; accessing an interval extension rule from the rules database using the monitoring interval tracker; automatically determining whether to generate a monitoring interval extension according to the interval extension rule using the monitoring interval tracker, the monitoring interval extension having an extended end date based at least partly on whether the approval date is later than the first end date; and automatically generating a date of service (DOS) for the transmission data, the DOS being the approval date.
Independent claim 15 discloses a method for managing a cardiac monitoring device, the method comprising: receiving, at a medical platform having a cloud computing architecture, transmission data for a patient, the transmission data captured through one or more interrogations of the cardiac monitoring device and communicated to the medical platform over a network, the medical platform being in communication with a clinic system associated with a clinic treating the patient, the clinic system providing access to the medical platform through a provider portal; accessing a plurality of patient care modality rules from a rules database using a monitoring interval tracker of the medical platform; generating, based at least partly on the plurality of patient care modality rules, a plurality of monitoring intervals using the monitoring interval tracker, the plurality of monitoring intervals running concurrently, and being associated with the cardiac monitoring device, a first monitoring interval of the plurality of monitoring intervals having a first end date and a second monitoring interval of the plurality of monitoring intervals having a second end date that is different than the first end date; detecting a received date of the transmission data using the monitoring interval tracker; calculating whether the received date is later than at least one of the first end date or the second end date using the monitoring interval tracker; generating, for the transmission data, a docket report associated with the first monitoring interval or the second monitoring interval; receiving an approval timestamp indicating an approval date later than the received date and corresponding to the docket report; calculating that the approval date is later than the first end date; accessing an interval extension rule from the rules database using the monitoring interval tracker; automatically generating a monitoring interval extension according to the interval extension rule using the monitoring interval tracker, the monitoring interval extension having an extended end date based at least partly on the approval date being later than the received date and later than the first end date; and automatically generating a date of service (DOS) for the transmission data, the DOS being the approval date.
Independent Claim 21 (new) discloses a method for managing a cardiac monitoring device, the method comprising: receiving transmission data for a patient at a medical platform having a cloud computing architecture, the transmission data captured through one or more interrogations of the cardiac monitoring device and communicated to the medical platform over a network, the medical platform in communication with a clinic system associated with a clinic treating the patient, the clinic system providing access to the medical platform via a provider portal; generating a monitoring interval using a monitoring interval tracker of the medical platform, the monitoring interval generated based on at least one of the cardiac monitoring device or a patient care modality for the patient, the monitoring interval having an end date; detecting a received date for the transmission data using the monitoring interval tracker of the medical platform; and automatically generating a response to the received date for the transmission data, the response determined based on Date of Service ("DOS") criteria for the monitoring interval, the response including automatic application of a monitoring interval extension having an extended end date when the received date is not detected prior to the end date, the response including automatic application of a DOS for the transmission data when the received date is within the monitoring interval or the monitoring interval extension.
The examiner is interpreting the above bolded limitations as additional elements as further discussed below. The remaining un-bolded limitations merely recite steps that which could be performed by the human mind and/or a human with a physical aid as with a pen and paper which is an abstract idea. (Step 2A- Prong 1: YES. The claims are abstract).
This judicial exception is not integrated into a practical application. Limitations that are not indicative of integration into a practical application include: (1) Adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea (MPEP 2106.05.f), (2) Adding insignificant extra- solution activity to the judicial exception (MPEP 2106.05.g), (3) Generally linking the use of the judicial exception to a particular technological environment or field of use (MPEP 2106.05.h).
Independent claims 1, 8 and 15 disclose the following additional elements:
A cardiac monitoring device
Receiving, at a medical platform having a cloud computing architecture, transmission data for a patient, the transmission data captured through one or more interrogations of the cardiac monitoring device and communicated to the medical platform over a network
The medical platform being in communication with a clinic system associated with a clinic treating the patient, the clinic system providing access to the medical platform through a provider portal
A rules database
A monitoring interval tracker of the medical platform
Receiving an approval timestamp corresponding to the docket report
Automatically [generating outputs]
Independent claim 21 discloses the following additional elements:
A cardiac monitoring device
Receiving, at a medical platform having a cloud computing architecture, transmission data for a patient, the transmission data captured through one or more interrogations of the cardiac monitoring device and communicated to the medical platform over a network
The medical platform being in communication with a clinic system associated with a clinic treating the patient, the clinic system providing access to the medical platform through a provider portal
A monitoring interval tracker of the medical platform
Automatically [generating outputs]
In particular, the cardiac monitoring device (of claims 1, 8, 15, and 21), The medical platform being in communication with a clinic system associated with a clinic treating the patient, the clinic system providing access to the medical platform through a provider portal (of claims 1, 8, 15, and 21), the rules database (of claims 1, 8, and 15), monitoring interval tracker of the medical platform (of claims 1, 8, 15, and 21), and automatically [generating outputs] (of claims 1, 8, 15, and 21) are recited at a high-level of generality such that it amounts to no more than mere instructions to implement an abstract idea by adding the words ‘apply it’ (or an equivalent) with the judicial exception.
Additionally, the following limitations amount to insignificant extra solution activity:
Receiving, at a medical platform having a cloud computing architecture, transmission data for a patient, the transmission data captured through one or more interrogations of the cardiac monitoring device and communicated to the medical platform over a network
receiving an approval timestamp corresponding to the docket report (of claim 1)
receiving an approval timestamp after the received date and indicating an approval date corresponding to only one the first docket report or the second docket report (of claim 8)
receiving an approval timestamp indicating an approval date later than the received date and corresponding to the docket report (of claim 15)
Accordingly, these additional elements, when considered separately and as an ordered combination, do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea.
Further, Applicant’s specification para 3-4 discloses tracking every transmission of every cardiac monitoring device, generating docketing reports for the transmissions, approving the docketing reports, and establishing dates of service for the transmissions as a human task. MPEP 2106.04(d)(1) and MPEP 2106.05(a) indicates that a practical application may be present where the claimed invention provides a technical solution to a technical problem. See, e.g., DDR Holdings, LLC. v. Hotels.com, L.P., 773 F.3d 1245, 1259 (Fed. Cir. 2014) (finding that claiming a website that retained the “look and feel” of a host webpage provided a technological solution to the problem of retention of website visitors by utilizing a website descriptor that emulated the “look and feel” of the host webpage, where the problem arose out of the internet and was thus a technical problem). The problem of healthcare providers not being able to track every transmission of every cardiac monitoring device, generate docketing reports for the transmissions, approve the docketing reports, and establish dates of service for the transmissions is not a technical problem. The Examiner notes that the Applicant does not claim any hardware in a system claim or a computer implemented method. Thus, further indicating that this is a mental process for managing a cardiac monitoring device. The Applicant’s specification at para 36 discloses the network environment 100 includes at least one server 112 hosting a website or an application that the user may visit to access the medical device manager 102. Even if this server hosting a website or application was claimed, the problem of healthcare providers not being able to track every transmission of every cardiac monitoring device, generate docketing reports for the transmissions, approve the docketing reports, and establish dates of service for the transmissions is not a problem that is caused by the server itself (further indicating that this is not a technical problem). At best, Applicant’s identified problem is a business or management problem. Because no technological problem is present, the claims do not provide a practical application.
Accordingly, claim(s) 1, 8, and 15 are directed to an abstract idea(s) without a practical application. (Step 2A-Prong 2: NO: the additional claimed elements are not integrated into a practical application).
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements of the cardiac monitoring device, the rules database (containing patient care modality rules), and the rules database (containing interval extension rules) amounts to no more than mere instructions to apply the exception using a generic computer component. Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept ("significantly more’). MPEP2106.05(I)(A) indicates that merely saying "apply it” or equivalent to the abstract idea cannot provide an inventive concept ("significantly more").
Further, receiving, at a medical platform having a cloud computing architecture, transmission data for a patient, the transmission data captured through one or more interrogations of the cardiac monitoring device and communicated to the medical platform over a network (of claims 1, 8, 15, and 21), receiving an approval timestamp corresponding to the docket report (of claim 1), receiving an approval timestamp after the received date and indicating an approval date corresponding to only one the first docket report or the second docket report (of claim 8), receiving an approval timestamp indicating an approval date later than the received date and corresponding to the docket report (of claim 15) was considered insignificant extra-solution activity in Step 2A, Prong 2. Re-evaluating here in step 2B, this is also determined to be well-understood, routine, conventional activity in the field. The Mayo and OIP Techs court decisions cited in MPEP 2106.05(g) indicate that mere data gathering is well-understood, routine, conventional activity in the field and the courts indicate that receiving or transmitting data over a network e.g., using the Internet to gather data, Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information); TLI Communications LLC v. AV Auto. LLC, 823 F.3d 607, 610, 118 USPQ2d 1744, 1745 (Fed. Cir. 2016) (using a telephone for image transmission); OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1093 (Fed. Cir. 2015) (sending messages over a network); buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014) (computer receives and sends information over a network) are well-understood, routine, and conventional functions when they are claimed in a merely generic manner (e.g., at a high level of generality).
Accordingly, even in combination, this additional element does not provide significantly more. As such the independent claims 1, 8, and 15 are not patent eligible. (Step 2B: NO. The claims do not provide significantly more).
Dependent claim(s) 2-7, 9-14, and 16-20 are similarly rejected because they either further define/narrow the abstract idea and/or do not further limit the claim to a practical application or provide an inventive concept such that the claims are subject matter eligible even when considered individually or as an ordered combination.
Dependent claims 2-7, 9-14, and 16-20 do not further disclose any additional elements. As such, no further additional hardware components other than those found in the respective independent claims are recited, thus it is presumed that the claims are further utilizing the same generic systemization as presented above. The dependent claims do not include any additional elements that integrate the abstract idea into a practical application of the exception or are sufficient to amount to significantly more than the judicial exception when considered both individually and as an ordered combination.
Therefore, the dependent claims are also directed to an abstract idea.
Thus, Claims 1-21 are rejected under 35 U.S.C. 101 as being directed to non-statutory subject matter.
Subject Matter Free of Prior Art
Claims 1-21 contain subject matter free of prior art. The following references are relevant to the subject matter in claims 1-21, however, there is no obvious combination of prior references that disclose the claimed invention as described in further detail below.
Wadhwa (US 2018/0151255 A1) discloses receiving, at a medical platform having a cloud computing architecture, transmission data for a patient, the transmission data captured through one or more interrogations of the cardiac monitoring device and communicated to the medical platform over a network, generating a monitoring interval… calculating whether the received date is later than the end date…; generating… a monitoring interval extension having an extended end date based at least partly on whether the received date is later than the end date (See para 6 which discloses adjusting a billing cycle end date after the interrogation data is received (broadly an extension). See further para 35 discloses implantable cardiac devices and interrogation data as the transmission data. See further 96-96 disclosing the computing device and cloud based storage).
However, Wadhwa does not disclose accessing a patient care modality rule from a rules database using a monitoring interval tracker of the medical platform; generating a monitoring interval associated with the cardiac monitoring device using the monitoring interval tracker, the monitoring interval having an end date based at least partly on the patient care modality rule…generating a docket report for the transmission data; receiving an approval timestamp corresponding to the docket report; calculating whether the approval timestamp indicates an approval date later than the end date using the monitoring interval tracker; accessing an interval extension rule from the rules database using the monitoring interval tracker; automatically generating a monitoring interval extension according to the interval extension rule using the monitoring interval tracker, the monitoring interval extension having an extended end date based at least partly on whether the approval date is later than the end date; and automatically generating a date of service (DOS) for the transmission data, the DOS being the extended end date of the monitoring interval extension.
Zaidi (US 2017/0225001 A1) discloses generating a monitoring interval associated with the cardiac monitoring device, the monitoring interval having an end time (see abstract, para 165, Fig. 3, and para 78), and extending the time period if no high accuracy clauses are encountered wherein clauses that exhibit a high predictive certainty, e.g. accuracy, based on PPV and/or NPV may be categorized as high accuracy clauses (see para 33).
However, Zaidi does not explicitly discloses accessing a patient care modality rule from a rules database using a monitoring interval tracker of the medical platform; generating a monitoring interval associated with the cardiac monitoring device using the monitoring interval tracker, the monitoring interval having an end date based at least partly on the patient care modality rule…generating a docket report for the transmission data; receiving an approval timestamp corresponding to the docket report; calculating whether the approval timestamp indicates an approval date later than the end date using the monitoring interval tracker; accessing an interval extension rule from the rules database using the monitoring interval tracker; automatically generating a monitoring interval extension according to the interval extension rule using the monitoring interval tracker, the monitoring interval extension having an extended end date based at least partly on whether the approval date is later than the end date; and automatically generating a date of service (DOS) for the transmission data, the DOS being the extended end date of the monitoring interval extension.
Brown (US 2002/0019748 A1) discloses a method for managing a cardiac monitoring device (a method for managing a plurality of remote monitoring devices, such as devices for cardiovascular disease; para 21, 68), the method comprising: generating a monitoring interval associated with the cardiac monitoring device (measurements from the monitoring device are collected over a predetermined period of time; para 47); receiving, at a medical platform having a cloud computing architecture, transmission data for a patient, the transmission data captured through one or more interrogations of the cardiac monitoring device and communicated to the medical platform over a network, detecting a received date of the transmission data using the monitoring interval tracker (collection date 64 is the date the corresponding set of measurements are received by clinic server 12; para 41).
However, Brown does not explicitly disclose accessing a patient care modality rule from a rules database using a monitoring interval tracker of the medical platform; generating a monitoring interval associated with the cardiac monitoring device using the monitoring interval tracker, the monitoring interval having an end date based at least partly on the patient care modality rule…generating a docket report for the transmission data; receiving an approval timestamp corresponding to the docket report; calculating whether the approval timestamp indicates an approval date later than the end date using the monitoring interval tracker; accessing an interval extension rule from the rules database using the monitoring interval tracker; automatically generating a monitoring interval extension according to the interval extension rule using the monitoring interval tracker, the monitoring interval extension having an extended end date based at least partly on whether the approval date is later than the end date; and automatically generating a date of service (DOS) for the transmission data, the DOS being the extended end date of the monitoring interval extension.
Karz (US 4,173,971 A) discloses a method for managing a cardiac monitoring device (a method of continuously monitoring an ECG device; abstract), the method comprising: generating a monitoring interval associated with the cardiac monitoring device (predetermined time period during which recording occurs; column 6, lines 44-47).
However, Karz does not explicitly disclose accessing a patient care modality rule from a rules database using a monitoring interval tracker of the medical platform; generating a monitoring interval associated with the cardiac monitoring device using the monitoring interval tracker, the monitoring interval having an end date based at least partly on the patient care modality rule…generating a docket report for the transmission data; receiving an approval timestamp corresponding to the docket report; calculating whether the approval timestamp indicates an approval date later than the end date using the monitoring interval tracker; accessing an interval extension rule from the rules database using the monitoring interval tracker; automatically generating a monitoring interval extension according to the interval extension rule using the monitoring interval tracker, the monitoring interval extension having an extended end date based at least partly on whether the approval date is later than the end date; and automatically generating a date of service (DOS) for the transmission data, the DOS being the extended end date of the monitoring interval extension.
Mayou (US 2013/0035871 A1) discloses generating a monitoring interval associated with the cardiac monitoring device, the monitoring interval having an end date, receiving, at a medical platform having a cloud computing architecture, transmission data for a patient, the transmission data captured through one or more interrogations of the cardiac monitoring device and communicated to the medical platform over a network, detecting a received date of the transmission data using the monitoring interval tracker (abstract, para 18, 106,and 159), generating a report from the transmitted data signal (see para 185), and changing or modifying the start and end dates and times for the collected data to obtain more accurate pattern data (See para 321-329).
However, Mayou does not explicitly disclose accessing a patient care modality rule from a rules database using a monitoring interval tracker of the medical platform; generating a monitoring interval associated with the cardiac monitoring device using the monitoring interval tracker, the monitoring interval having an end date based at least partly on the patient care modality rule…generating a docket report for the transmission data; receiving an approval timestamp corresponding to the docket report; calculating whether the approval timestamp indicates an approval date later than the end date using the monitoring interval tracker; accessing an interval extension rule from the rules database using the monitoring interval tracker; automatically generating a monitoring interval extension according to the interval extension rule using the monitoring interval tracker, the monitoring interval extension having an extended end date based at least partly on whether the approval date is later than the end date; and automatically generating a date of service (DOS) for the transmission data, the DOS being the extended end date of the monitoring interval extension.
Reasons why the subject matter of the instant application contains subject matter free of prior art:
In conclusion, while the above listed references list some of the limitations as claimed in the independent claims (such as a method for managing a cardiac monitoring device, the method comprising: receiving, at a medical platform having a cloud computing architecture, transmission data for a patient, the transmission data captured through one or more interrogations of the cardiac monitoring device and communicated to the medical platform over a network, generating a monitoring interval associated with the cardiac monitoring device using the monitoring interval tracker; detecting a received date of the transmission data using the monitoring interval tracker), there is no obvious combination of references that also discloses the following: accessing a patient care modality rule from a rules database using a monitoring interval tracker of the medical platform; generating a monitoring interval associated with the cardiac monitoring device using the monitoring interval tracker, the monitoring interval having an end date based at least partly on the patient care modality rule…generating a docket report for the transmission data; receiving an approval timestamp corresponding to the docket report; calculating whether the approval timestamp indicates an approval date later than the end date using the monitoring interval tracker; accessing an interval extension rule from the rules database using the monitoring interval tracker; automatically generating a monitoring interval extension according to the interval extension rule using the monitoring interval tracker, the monitoring interval extension having an extended end date based at least partly on whether the approval date is later than the end date; and automatically generating a date of service (DOS) for the transmission data, the DOS being the extended end date of the monitoring interval extension.
Claim 8 contains subject matter free of prior art for the same reasons as claim 1, and further because there is no obvious combination of prior art that discloses generating a first monitoring interval associated with the cardiac monitoring device using the monitoring interval tracker, the first monitoring interval having a first end date based at least partly on a first patient care modality rule of the plurality of patient care modality rules; generating a second monitoring interval associated with the cardiac monitoring device using the monitoring interval tracker, the second monitoring interval having a second end date based at least partly on a second patient care modality rule of the plurality of patient care modality rules, the second end date being different than the first end date; detecting a received date of the transmission data using the monitoring interval tracker; calculating whether the received date is later than at least one of the first end date or the second end date using the monitoring interval tracker; generating, for the transmission data, a first docket report associated with the first patient care modality rule; generating, for the transmission data, a second docket report associated with the second patient care modality rule; receiving an approval timestamp after the received date and indicating an approval date corresponding to only one the first docket report or the second docket report; calculating whether the approval date is later than the first end date using the monitoring interval tracker; accessing an interval extension rule from the rules database using the monitoring interval tracker; automatically determining whether to generate a monitoring interval extension according to the interval extension rule using the monitoring interval tracker, the monitoring interval extension having an extended end date based at least partly on whether the approval date is later than the first end date; and automatically generating a date of service (DOS) for the transmission data, the DOS being the approval date.
Claim 15 contains subject matter free of prior art for the same reasons as claim 1, and further because there is no obvious combination of prior art that discloses accessing a plurality of patient care modality rules from a rules database using a monitoring interval tracker of the medical platform; generating, based at least partly on the plurality of patient care modality rules, a plurality of monitoring intervals using the monitoring interval tracker, the plurality of monitoring intervals running concurrently and being associated with the cardiac monitoring device, a first monitoring interval of the plurality of monitoring intervals having a first end date and a second monitoring interval of the plurality of monitoring intervals having a second end date that is different than the first end date; detecting a received date of the transmission data using the monitoring interval tracker; calculating whether the received date is later than at least one of the first end date or the second end date using the monitoring interval tracker; generating, for the transmission data, a docket report associated with the first monitoring interval or the second monitoring interval; receiving an approval timestamp indicating an approval date later than the received date and corresponding to the docket report; calculating that the approval date is later than the first end date using the monitoring interval tracker; accessing an interval extension rule from the rules database using the monitoring interval tracker; automatically generating, a monitoring interval extension according to the interval extension rule using the monitoring interval tracker, the monitoring interval extension having an extended end date based at least partly on the approval date being later than the received date and later than the first end date; and automatically generating a date of service (DOS) for the transmission data, the DOS being the approval date.
Claim 21 contains subject matter free of prior art for the same reasons as claim 1, and further because there is no obvious combination of prior art that discloses generating a monitoring interval using a monitoring interval tracker of the medical platform, the monitoring interval generated based on at least one of the cardiac monitoring device or a patient care modality for the patient, the monitoring interval having an end date; detecting a received date for the transmission data using the monitoring interval tracker of the medical platform; and automatically generating a response to the received date for the transmission data, the response determined based on Date of Service ("DOS") criteria for the monitoring interval, the response including automatic application of a monitoring interval extension having an extended end date when the received date is not detected prior to the end date, the response including automatic application of a DOS for the transmission data when the received date is within the monitoring interval or the monitoring interval extension.
Therefore, claims 1-21 contain subject matter free of prior art.
Response to Arguments
Applicant’s arguments filed 8/19/2026 with respect to 35 U.S.C. § 101 have been fully considered, and but are not persuasive.
First, the Applicant argues that the specification explains that the claimed operations “address technological and operational difficulties arising from the interaction of numerous cardiac monitoring devices, differing transmission frequencies, differing patient care modalities and asynchronous transmission and approval events and points to the specification, “tracking every transmission of every cardiac monitoring device, generating dockets for the transmissions, approving the docket reports, and establishing dates of service for the transmissions in a timely manner and without letting patient care diminish is a significant burden for clinics providing these services.” The Examiner notes that it is not claimed that the cardiac monitoring devices have differing transmission frequencies. Further, MPEP 2106.04(d)(1) and MPEP 2106.05(a) indicates that a practical application may be present where the claimed invention provides a technical solution to a technical problem. See, e.g., DDR Holdings, LLC. v. Hotels.com, L.P., 773 F.3d 1245, 1259 (Fed. Cir. 2014) (finding that claiming a website that retained the “look and feel” of a host webpage provided a technological solution to the problem of retention of website visitors by utilizing a website descriptor that emulated the “look and feel” of the host webpage, where the problem arose out of the internet and was thus a technical problem). Here, the Applicant’s argued problem is not a technological problem caused by the technological environment to which the claims are confined. The problem of needing to establish dates of service for the transmissions in a timely manner and without letting patient care diminish is not a problem caused by the computer that is involved in the process. At best, Applicant’s identified problem is a business problem. Because no technological problem is present, the claims do not provide a practical application and this argument is not persuasive.
The Applicant argues that the claims therefore do not merely recite that a person determines dates associated with medical care and argues that the human mind cannot receive over a network data captured through interrogations of a cardiac monitoring device at a “medical platform having a cloud computing architecture,” and further points to the provider portal and the monitoring interval tracker of the medical platform. The Examiner notes that these limitations are newly amended to the claims, however, as presented above in the updated 35 U.S.C 101 rejection, these newly added amendments recite additional elements and, thus, are not classified as a part of the abstract idea (the mental process). As such, this argument is not persuasive.
The Applicant then argues that the claims are patent-eligible for similar reasons as the claims at issue in Ex parte Hannun, Appeal 2018-003323 (PTAB Apr. 1, 2019). The Examiner disagrees that the claims of the instant application are analogous to those at issue in Ex parte Hannun. The claims at issue in Ex parte Hannun are directed to a specific implementation including the steps of normalizing an input file, generating a jitter set of audio files, generating a set of spectrogram frames, obtaining predicted character probabilities from a trained neural network and decoding a transcription of the input audio using the predicted character probability outputs and was found to not be directed to a mental process. The claims of the instant application recites, “accessing a patient care modality rule; generating a monitoring interval associated with the cardiac monitoring device, the monitoring interval having an end data based at least partly on the patient care modality rule, calculating whether the received date is later than the end date; generating a docket report for the transmission data; calculating whether the approval timestamp indicates an approval date later than the end date; accessing an interval extension rule; generating, according to the interval extension rule, a monitoring interval extension having an extended end date based at least partly on whether the received date is later than the end date or whether the approval date is later than the end date; and generating a date of service (DOS) for the transmission data, the DOS being the extended end date of the monitoring interval extension.” These limitations are directed to a mental process as they describe a process that could be practically performed in the human mind (i.e. observations, evaluations, judgements, and/or opinions in order to generate a date of service (DOS). A human can, to paraphrase, mentally access a rule, generate a monitoring interval having an end date based on that rule, calculate if a received date is later than the end date, generate a report, calculate whether an approval data is later than the end data, access an interval extension rule, generate an extension based at least partly on whether the received date is later than the end date or whether the approval date is later than the end date; and generating a date of service (DOS) for the transmission data, the DOS being the extended end date of the monitoring interval extension. The specific limitations the Applicant points to are the newly added amendments. As presented above, the cardiac monitoring device, network, medical platform having a cloud computing architecture, and the monitoring interval tracker of the medical platform were identified to be additional elements. Specifically,” receiving, at a medical platform having a cloud computing architecture, transmission data for a patient, the transmission data captured through one or more interrogations of the cardiac monitoring device and communicated to the medical platform over a network,” recites insignificant extra-solution activity as analyzed above. Additionally, the, “the medical platform being in communication with a clinic system associated with a clinic treating the patient, the clinic system providing access to the medical platform through a provider portal,” and, “the monitoring interval tracker of the medical platform” are recited at a high level of generality such that they amount to mere instructions to implement the abstract idea.
Further, the Applicant argues that the claims integrate any such judicial exception into a practical application and specifically argues the various transmission frequencies again and that para 69 describes the improvement, and says para 69 discloses, “provides significant improvements in efficiency for patient tracking, patient follow ups, and reducing missed monitoring failures to follow up.” The Examiner again notes that it is not claimed that the cardiac monitoring devices have differing transmission frequencies. Further, “significant improvements in efficiency for patient tracking, patient follow ups, and reducing missed monitoring failures to follow up,” describes a solution to a business problem. Even if that solution is a technical solution, it does not integrate the abstract idea into a practical application as it does not provide a technical solution to a technical problem. MPEP 2106.04(d)(1) and MPEP 2106.05(a) indicates that a practical application may be present where the claimed invention provides a technical solution to a technical problem. As the claimed invention does not describe a technical problem, this argument is not persuasive.
The Applicant then argues that the claims are also patent-eligible for similar reasons as USPTO Example 42, Claim 1. The Examiner respectfully disagrees. The Specification of Example 42 describes a technical problem (i.e., a problem caused by the technology): the technological implementation of software formats made it difficult to share updated health information. The claimed invention then solved this problem (a technical solution) by providing a message and access to updated real-time data that has been converted to a standardized format, thus integrating the abstract idea into a practical application. Unlike Example 42 and/or the technical solution to a technical problem inquiry, the Examiner cannot locate any technical problem that the claimed invention is solving. At best, the problem(s) described in the as-filed disclosure are medical and/or business problems.
Finally, the Applicant argues that the classification of the cardiac monitoring device and rules database as generic and the “receiving transmission data and approval timestamps” as well-understood, routine, and conventional data-gathering activity does not evaluate the actual ordered combination recited by the claims. The Examiner respectfully disagrees. The Examiner previously analyzed the additional elements of the independent and dependent claims individually and in combination and found that the additional elements did not integrate the abstract idea into a practical application or provide significantly more. Further, looking at the limitations as an ordered combination adds nothing that is not already present when looking at the elements taken individually, and there is no indication that the combination of elements improves the functioning of a computer or improves any other technology. The Applicant further argues that “the claimed ordered combination aligns with the combination that the specification identifies provides as the disclosed improvement.” As presented above, the technical solution to a technical problem inquiry, the Examiner cannot locate any technical problem that the claimed invention is solving. An improvement to the abstract idea, is still an improvement. As such, this argument is not persuasive.
Conclusion
THIS ACTION IS MADE FINAL. 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 SARA J MORICE DE VARGAS whose telephone number is (703)756-4608. The examiner can normally be reached M-F 8:30-5:30 pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Peter H. Choi can be reached at (469)295-9171. 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.
/SARA JESSICA MORICE DE VARGAS/Examiner, Art Unit 3681
/PETER H CHOI/Supervisory Patent Examiner, Art Unit 3681
