DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of Claims
This action is in reply to the amendment filed on 09/08/25.
Claims 98-119 have been added.
Claims 80-97 have been canceled.
Claims 1-79 were previously canceled.
Claims 98-119 are currently pending and have been examined.
This action is made FINAL.
Continuity/Priority Date
Status of this application as a continuation of application 15/360,799, which claims priority to provisional application 62/365,317, filed 07/21/2016, is acknowledged. Accordingly, a priority date of 07/21/16 has been given to this application.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are as follows, in Claim 115 and 116:
a rules engine configured to evaluate a payer-specific drug formulary and prior authorization rules and compute an authorization outcome and, when prior authorization is required, to issue a computer-readable prior authorization request and to receive an electronic approval, denial, or request for additional documentation;
a payments module configured to generate an electronic payment instruction specifying any patient copayment or coinsurance, to cause authorization or initiation of the instruction via a payment network, and to store a payment-network authorization record;
a fulfillment engine configured to generate and cause execution of a computer-readable fulfillment or administration instruction, processable by a specialty pharmacy subsystem or a manufacturer distribution system, the instruction specifying a delivery mode selected from direct-to-patient delivery and provider-site delivery, including delivery to an integrated payer-provider facility;
an event-ingest service configured to receive a confirmation event comprising at least one of: shipment, delivery, dispense, or administration information
a policy-enforcement component configured to enforce message-level encryption in transit, encryption at rest, and role-based access logging for operations
the policy- enforcement component is further configured to: a) condition access to at least one of a specialty pharmacy subsystem and a payment network on submission of a platform-generated transaction identifier associated with the prescription; b) validate the identifier by applying at least one of: a time limit or a digital signature; c) require capture of a confirmation event selected from shipment, delivery, dispense, or administration prior to settlement by the payments module of the electronic payment instruction; d) block, delay, or cancel fulfillment or payment operations that omit the identifier or fail validation of the identifier; and e) append an approval, rejection, delay, or cancellation record to an append-only, time- stamped audit log (Claim 116)
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 115-117, 119 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Regarding Claim 15:
Claim limitation “a rules engine configured to evaluate a payer-specific drug formulary and prior authorization rules and compute an authorization outcome and, when prior authorization is required, to issue a computer-readable prior authorization request and to receive an electronic approval, denial, or request for additional documentation” invokes 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. However, the written description fails to disclose the corresponding structure, material, or acts for performing the entire claimed function and to clearly link the structure, material, or acts to the function. The specification does not contain disclosure of “rules engine”, any type of “engine”, or any kind of rules-based logic, model or program. Therefore, the specification does not provide sufficient details such that one of ordinary skill in the art would know the structure of the claimed rule engine for performing the claimed function.
Claim limitation “a payments module configured to generate an electronic payment instruction specifying any patient copayment or coinsurance, to cause authorization or initiation of the instruction via a payment network, and to store a payment-network authorization record” invokes 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. However, the written description fails to disclose the corresponding structure, material, or acts for performing the entire claimed function and to clearly link the structure, material, or acts to the function. The specification does not contain disclosure of “payments module”, or any other type of module or software used in conjunction with payments. Therefore, the specification does not provide sufficient details such that one of ordinary skill in the art would know the structure of the claimed payments module for performing the claimed function.
Claim limitation “a fulfillment engine configured to generate and cause execution of a computer-readable fulfillment or administration instruction, processable by a specialty pharmacy subsystem or a manufacturer distribution system, the instruction specifying a delivery mode selected from direct-to-patient delivery and provider-site delivery, including delivery to an integrated payer-provider facility” invokes 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. However, the written description fails to disclose the corresponding structure, material, or acts for performing the entire claimed function and to clearly link the structure, material, or acts to the function. The specification does not contain disclosure of “fulfillment engine”, any type of “engine”, or any kind of rules-based logic, model, program or software used in conjunction with fulfillment. Therefore, the specification does not provide sufficient details such that one of ordinary skill in the art would know the structure of the claimed fulfillment engine for performing the claimed function.
Claim limitation “an event-ingest service configured to receive a confirmation event comprising at least one of: shipment, delivery, dispense, or administration information” invokes 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. However, the written description fails to disclose the corresponding structure, material, or acts for performing the entire claimed function and to clearly link the structure, material, or acts to the function. The specification does not contain disclosure of “event-ingest service”, any type of software, module, service or software, etc. pertaining to ingesting events. Therefore, the specification does not provide sufficient details such that one of ordinary skill in the art would know the structure of the claimed event-ingest service for performing the claimed function.
Regarding Claims 15 and 16:
Claim limitations “ a policy-enforcement component configured to enforce message-level encryption in transit, encryption at rest, and role-based access logging for operations…” and “he policy- enforcement component is further configured to: a) condition access to at least one of a specialty pharmacy subsystem and a payment network on submission of a platform-generated transaction identifier associated with the prescription…” invoke 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. However, the written description fails to disclose the corresponding structure, material, or acts for performing the entire claimed function and to clearly link the structure, material, or acts to the function. The specification does not contain disclosure of “policy-enforcement”, any type of software, module, component, etc. pertaining to enforcement of policies. Therefore, the specification does not provide sufficient details such that one of ordinary skill in the art would know the structure of the claimed policy enforcement component for performing the claimed function.
Therefore, the Claims 15-16 are indefinite and are rejected under 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, second paragraph. Claims 116, 117, 119 inherit the deficiencies of parent Claim 115 and are subsequently rejected.
Applicant may:
(a) Amend the claim so that the claim limitation will no longer be interpreted as a limitation under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph;
(b) Amend the written description of the specification such that it expressly recites what structure, material, or acts perform the entire claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
(c) Amend the written description of the specification such that it clearly links the structure, material, or acts disclosed therein to the function recited in the claim, without introducing any new matter (35 U.S.C. 132(a)).
If applicant is of the opinion that the written description of the specification already implicitly or inherently discloses the corresponding structure, material, or acts and clearly links them to the function so that one of ordinary skill in the art would recognize what structure, material, or acts perform the claimed function, applicant should clarify the record by either:
(a) Amending the written description of the specification such that it expressly recites the corresponding structure, material, or acts for performing the claimed function and clearly links or associates the structure, material, or acts to the claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
(b) Stating on the record what the corresponding structure, material, or acts, which are implicitly or inherently set forth in the written description of the specification, perform the claimed function. For more information, see 37 CFR 1.75(d) and MPEP §§ 608.01(o) and 2181.
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.
Claims 115-117, 119 are 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.
Regarding Claims 115-116: As described above, the disclosure does not provide sufficient structure for performing the function of: evaluate a payer-specific drug formulary and prior authorization rules and compute an authorization outcome and, when prior authorization is required, to issue a computer-readable prior authorization request and to receive an electronic approval, denial, or request for additional documentation. The specification does not contain any disclosure of “rules engine” or any other structure that could reasonably be construed as a “rules engine” (see corresponding new matter rejection below). The specification does not demonstrate that Applicant has made an invention that achieves the claimed functions because the invention is not described with sufficient detail such that one of ordinary skill in the art can reasonably conclude that the inventor had possession of the claimed invention.
As described above, the disclosure does not provide sufficient structure for performing the function of: generate an electronic payment instruction specifying any patient copayment or coinsurance, to cause authorization or initiation of the instruction via a payment network, and to store a payment-network authorization record. The specification does not contain any disclosure of “payment module” or any other structure that could reasonably be construed as a “payment module” (see corresponding new matter rejection below). The specification does not demonstrate that Applicant has made an invention that achieves the claimed functions because the invention is not described with sufficient detail such that one of ordinary skill in the art can reasonably conclude that the inventor had possession of the claimed invention.
As described above, the disclosure does not provide sufficient structure for performing the function of: generate and cause execution of a computer-readable fulfillment or administration instruction, processable by a specialty pharmacy subsystem or a manufacturer distribution system, the instruction specifying a delivery mode selected from direct-to-patient delivery and provider-site delivery, including delivery to an integrated payer-provider facility. The specification does not contain any disclosure of “fulfillment engine” or any other structure that could reasonably be construed as a “fulfillment engine” (see corresponding new matter rejection below). The specification does not demonstrate that Applicant has made an invention that achieves the claimed functions because the invention is not described with sufficient detail such that one of ordinary skill in the art can reasonably conclude that the inventor had possession of the claimed invention.
As described above, the disclosure does not provide sufficient structure for performing the function of: receive a confirmation event comprising at least one of: shipment, delivery, dispense, or administration information. The specification does not contain any disclosure of “an event-ingest service” or any other structure that could reasonably be construed as a “an event-ingest service” (see corresponding new matter rejection below). The specification does not demonstrate that Applicant has made an invention that achieves the claimed functions because the invention is not described with sufficient detail such that one of ordinary skill in the art can reasonably conclude that the inventor had possession of the claimed invention.
As described above, the disclosure does not provide sufficient structure for performing the function of: enforce message-level encryption in transit, encryption at rest, and role-based access logging for operations and a) condition access to at least one of a specialty pharmacy subsystem and a payment network on submission of a platform-generated transaction identifier associated with the prescription… The specification does not contain any disclosure of “a policy-enforcement component” or any other structure that could reasonably be construed as a “a policy enforcement component” (see corresponding new matter rejection below). The specification does not demonstrate that Applicant has made an invention that achieves the claimed functions because the invention is not described with sufficient detail such that one of ordinary skill in the art can reasonably conclude that the inventor had possession of the claimed invention.
Claims 116, 117, 119 inherit the deficiencies of parent Claim 115 and are subsequently rejected.
Claim Rejections - 35 USC § 112(a) - New Matter
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 98-119 are 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 appears to constitute new matter 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.
Regarding Claims 98, 99, 100, 102, 104, 105, 106, 108, 109, 110, 111, 114, the newly added limitations of various types of “processor-executable logic”, e.g., processor-executable reimbursement or assurance logic or processor-executable comparison logic, appears to constitute new matter that was not disclosed in the specification as originally filed. In particular, Applicant does not point to, nor was Examiner able to find support for this newly added language within the specification as originally filed. The specification does not contain any instances of processor; executable instructions; or any instructions pertaining to computer operations/functions, comparisons, reimbursement; nor does it contain any descriptions of software, hardware, firmware, logic, program code, etc. that could reasonably be construed as being “processor-executable logic” for performing the claimed functions. As such, Applicant is respectfully requested to clarify the above issues and to specifically point out support for the newly added limitations in the originally filed spec and claims.
Claims 99-104, 108-111 inherit the deficiencies of parent Claim 98 and are subsequently rejected. Claims 106, 107 inherit the deficiencies of parent claim 105 and are subsequently rejected.
Regarding Claims 112, 114, 115, the newly added recitations of “ledger” and “transaction log” appear to contain new matter that was not described in the specification as originally filed. In remarks at Page 15, Applicant appears to equate the “electronic payment system” of the disclosure with the newly added ledger and transaction log recitations. However, “electronic payment system” in the context of the specification is considerably broader than a “ledger” and “transaction log”, which are very specific things, as claimed in Claims 112, 114, 115. As such, Applicant is respectfully requested to clarify the above issues and to specifically point out support for the newly added limitations in the originally filed spec and claims.
Claims 113, 114, 118 inherit the deficiencies of parent claim 112 and are subsequently rejected.
Regarding Claim 115, the newly added recitations of a) a secure API gateway configured to receive prescriptions and prior authorization requests for the specialty drug; b) a rules engine configured to evaluate a payer-specific drug formulary and prior authorization rules and compute an authorization outcome and, when prior authorization is required, to issue a computer-readable prior authorization request and to receive an electronic approval, denial, or request for additional documentation; c) a payments module configured to generate an electronic payment instruction specifying any patient copayment or coinsurance, to cause authorization or initiation of the instruction via a payment network, and to store a payment-network authorization record; d) a fulfillment engine configured to generate and cause execution of a computer-readable fulfillment or administration instruction, processable by a specialty pharmacy subsystem or a manufacturer distribution system, the instruction specifying a delivery mode selected from direct-to-patient delivery and provider-site delivery, including delivery to an integrated payer-provider facility; e) an event-ingest service configured to receive a confirmation event comprising at least one of: shipment, delivery, dispense, or administration information; f) an encrypted, role-segmented data store configured to persist time-stamped event records; g) a ledger store or transaction log configured to maintain a payer-facing electronic ledger updated based on the event records; and h) a policy-enforcement component configured to enforce message-level encryption in transit, encryption at rest, and role-based access logging for operations of the gateway, rules engine, payments module, fulfillment engine, event-ingest service, data store, and the ledger store or transaction log, and to require a confirmation event prior to settlement by the payments module; wherein components (a)-(h) are operable together such that, upon receipt of the prescription and the prior authorization request through the secure API gateway, the platform automatically performs the operations of computing the authorization outcome, generating and causing execution of the electronic payment instruction, generating and causing execution of the fulfillment instruction, receiving the confirmation event and writing the time-stamped event record, and updating the payer-facing ledger, appear to constitute new matter. In particular, Applicant does not point to, nor was Examiner able to find support for this newly added language within the specification as originally filed. As discussed above in 112(a) rejections related to 112(f) claim interpretations, the specification does not contain any recitations of any of the recited structural components, e.g., “(i) secure API gateway; (ii) rules engine; (iii) payments module that records in the ledger store or transaction log; (iv) logistics execution or fulfillment engine; (v) event-ingest service; (vi) encrypted, role-segmented store; (vii) ledger store/transaction log; (viii) policy-enforcement component-operable together such that, upon input, the system automatically performs the end-to-end operations”; as such, recitation of these “concrete components” (Applicant’s terminology, used at page 27), e.g., rules engine, all constitute new matter. These components are not disclosed by the specification as performing the claimed functions; nor does the instant specification disclose any hardware, software or computing elements that could reasonably be construed as any of the above “concrete components” (such as a “rules engine”) for performing the claimed functions. As such, Applicant is respectfully requested to clarify the above issues and to specifically point out support for the newly added limitations in the originally filed spec and claims.
Claims 116-117, 119 inherit the deficiencies of parent Claim 115 and are subsequently rejected.
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 98-119 are rejected under 35 U.S.C.101 because the claimed invention is directed to a judicial exception (an abstract idea) without significantly more.
Step 1
Claims 98-104, 108-114, 118 are drawn to a method, Claims 105-107 are drawn to a database system, and Claims 115-117, 119 are drawn to a platform, each of which are within the four statutory categories. Claims 98-119 are further directed to an abstract idea on the grounds set out in detail below.
Step 2A Prong 1
Claim 98 recites implementing the steps of:
a) initiating administration instruction for the specialty drug for one or more patients, and receiving an administration confirmation from a provider or patient;
b) receiving, for each treated patient:
i) baseline disease activity data and at least one disease-specific or drug-specific theragnostic data point(s) acquired before treatment initiation, and
ii) follow-up therapeutic outcome data and theragnostic data acquired at one or more pre-specified post-initiation time points;
c) computing, for each treated patient, a therapeutic effectiveness metric by comparing the baseline disease activity data and theragnostic data with the follow-up therapeutic outcome data and theragnostic data according to disease-specific clinical criteria;
d) developing one or more therapeutic effectiveness datasets, each dataset corresponding to one or more of: (i) a single patient, (ii) at least one stratified subset of patients, or (iii) an entire disease-specific patient population undergoing the treatment protocol; and
e) operating a feedback-controlled theragnostic evaluation that, at each pre-specified post- initiation time point and using the datasets developed in step (d), automatically generates, for each patient or for at least one stratified subset of patients identified by a stratification flag determined from pre-specified theragnostic or clinical stratification criteria stored in the platform, including one or more of: (i) mechanism of action of the drug, (ii) disease subtype, (iii) disease stage, or (iv) disease severity, at least one of:
i) a therapeutic appropriateness indicator;
ii) a therapeutic guidance indicator that updates a stored patient-specific drug dose or dosing schedule and sends an administration instruction for a next administration event to achieve or maintain a pre-specified therapeutic effectiveness criterion at a pre-specified time point during the treatment period;
iii) an alternative therapy signal that sends administration instruction to initiate an alternative therapy when a pre-specified criterion is not achieved; and
iv) a payer-facing output record including, for the corresponding time point, the therapeutic effectiveness metric and any indicator generated under (i)-(iii), the output record being processable by processor-executable reimbursement or assurance logic; and
updating the datasets developed in step (d) to record any signal, instruction, update, or output record generated under this step;
These steps amount to managing personal behavior or relationships or interactions
between people and therefore recite certain methods of organizing human activity including managing personal behaviors. Receiving patient treatment and outcome data, computing a therapeutic effectiveness metric by performing a comparison, developing datasets corresponding to a single patient or patient population, performing a feedback-controlled evaluation to automatically generate, for each patient/population of patients, a mechanism of action, disease subtype, stage, or severity, and indication of therapeutic appropriateness, and updating datasets accordingly are personal behaviors that may be performed by healthcare providers or individuals working in the health insurance fields; e.g., they all perform to obtaining, processing, analyzing, and outputting various types of patient and treatment data to provide efficacy assurance for a drug treatment of a disease/disorder.
Claim 105 recites implementing the steps of:
a) receive data for one or more patients receiving a specialty drug treatment for a disease or disorder, the data including any of: therapeutic outcome data, diagnostic data, theragnostic data, patient therapeutic adherence (PTA) metrics, therapy guidelines adherence (TGA) metrics, and electronic medical record (EMR) data
b) process the data to perform at least one of:
i) measuring adherence patterns and determining at least one of a PTA rate and a TGA rate;
ii) computing a therapeutic effectiveness metric according to pre-specified disease-specific clinical criteria; and
iii) comparing a proposed treatment strategy with prior standard-of-care responses stored in the database system;
iv) generating a payer-facing output record including the therapeutic effectiveness metric computed under (ii); and
c) update the processed data and results of the processing for real-time or subsequent retrieval and use; wherein, operations (a)-(c) are automatically performed upon on receipt of data
These steps amount to managing personal behavior or relationships or interactions
between people and therefore recite certain methods of organizing human activity including managing personal behaviors. Receiving patient data such as therapeutic outcome, diagnostic or theragnostic data, PTA metrics, TGA metrics, etc., subsequently processing the data to measure an adherence pattern and determine a TGA or PTA rate, compute a theragnostic effectiveness metric according to pre-specified criteria, compare a proposed treatment strategy with prior standard of care responses stored in a database generating a payer-facing output record, and updating the processed data and results for real time retrieval and use are personal behaviors that may be performed by healthcare providers or individuals working in the health insurance fields; e.g., they all perform to obtaining, processing, analyzing, and outputting various types of patient and treatment data to provide efficacy assurance for a drug treatment of a disease/disorder.
Claim 112 recites implementing the steps of:
a) receiving a prescription for the specialty drug and a prior authorization request from a provider;
b) retrieving payer-specific drug formulary and prior authorization rules and computing an authorization outcome and, when prior authorization is required, sending a prior authorization request and receiving an approval, denial, or request for additional documentation;
c) generating a payment instruction that specifies any patient copayment or coinsurance and causing authorization or initiation of the instruction via a payment network
d) specifying a delivery mode selected from direct-to-patient delivery and provider-site delivery, including delivery to an integrated payer-provider facility;
e) receiving a confirmation event comprising at least one of: shipment, delivery, dispense, or administration information, and writing a time-stamped event record to an encrypted, access-controlled repository;
f) updating a payer-facing ledger based on the event record and settling the payment instruction only upon receipt of a confirmation event selected from shipment, delivery, dispense, or administration;
These steps amount to managing personal behavior or relationships or interactions
between people and therefore recite certain methods of organizing human activity including managing personal behaviors. Receiving a prescription and prior authorization request, retrieving payer-specific formulary and authorization rules to compute an authorization outcome, sending a prior authorization request and receiving an approval/denial/request for additional information, generating payment instructions to specify patient co-pay/co-insurance, specifying a delivery mode, receiving a confirmation event for shipment, delivery, dispense or administration event and time-stamping the event to a repository, and updating a payer-facing badger based on the event record and settling the payment instruction upon receipt of a confirmation event, are all personal behaviors that may be performed by healthcare providers or individuals working in the health insurance fields; e.g., they all perform to obtaining, processing, analyzing, and outputting various types of patient, payment authorization, and payment data.
Claim 115 recites implementing the steps of:
a) receive prescriptions and prior authorization requests for the specialty drug;
b) evaluate a payer-specific drug formulary and prior authorization rules and compute an authorization outcome and, when prior authorization is required, to issue a prior authorization request and to receive an electronic approval, denial, or request for additional documentation;
c) generate a payment instruction specifying any patient copayment or coinsurance, to cause authorization or initiation of the instruction via a payment network
d) specify a delivery mode selected from direct-to-patient delivery and provider-site delivery, including delivery to an integrated payer-provider facility;
e) receive a confirmation event comprising at least one of: shipment, delivery, dispense, or administration information
These steps amount to managing personal behavior or relationships or interactions
between people and therefore recite certain methods of organizing human activity including managing personal behaviors. Receiving a prescription and prior authorization request, retrieving payer-specific formulary and authorization rules to compute an authorization outcome, sending a prior authorization request and receiving an approval/denial/request for additional information, generating payment instructions to specify patient co-pay/co-insurance, specifying a delivery mode, and receiving a confirmation event for shipment, delivery, dispense or administration event, are all personal behaviors that may be performed by healthcare providers or individuals working in the health insurance fields; e.g., they all perform to obtaining, processing, analyzing, and outputting various types of patient, payment authorization, and payment data.
Claims 98, 105, 112, 115 are therefore directed to an abstract idea.
Step 2A Prong 2
This judicial exception is not integrated into a practical application because the additional
elements within the claims only amount to:
A. Instructions to Implement the Judicial Exception. MPEP 2106.05(f)
Claim 98 additionally recites:
at least one processor of an integrated treatment- payment platform as implementing the steps of the method
execution of a computer-readable administration instruction as describing how administration for the specialty drug for one or more patients is performed
a provider- or patient-side application as implementing the step of receiving an administration confirmation
processor-executable comparison logic as implementing the step of computing, for each treated patient, a therapeutic effectiveness metric
the integrated treatment-payment platform as implementing each of steps (a)-(e);
signal as a means of showing a degree or value of a characteristic, e.g., therapeutic appropriateness
processable by processor-executable reimbursement or assurance logic
transmission of a computer-readable administration instruction as a means of sending information electronically
external systems may supply data to the platform or carry out actions in response to computer- readable instructions issued by the platform as a means of using computers to apply the abstract idea, e.g., providing data electronically or performing actions electronically
Claim 105 additionally recites:
A database system integrated as a component of an integrated treatment- payment platform, the database system comprising at least one encrypted, access- controlled database and at least one processor operatively coupled thereto, the processor as implementing the steps of the abstract idea
processor-executable comparison logic as implementing the step of computing a therapeutic effectiveness metric according to pre-specified disease-specific clinical criteria;
processor- executable reimbursement or assurance logic as implementing the step of processing the output record
wherein, upon receipt of data via the secure electronic interface, the database system automatically performs operations (a)-(c) as a means of electronically implementing the steps of the abstract idea
Claim 112 additionally recites:
A computer-implemented method executed by at least one processor of an integrated treatment-payment platform for a specialty drug treatment of a disease or disorder / the integrated treatment-payment platform as implementing the steps of the abstract idea / as performing each of steps (a)-(g);
a secure electronic interface as implementing the step of receiving a prescription for the specialty drug and a prior authorization request from a provider system;
provider system as the entity from which a prescription and prior authorization request are received
an access-controlled database as the means from which payer-specific drug formulary and prior authorization rules are retrieved when prior authorization is required, sending a
a computer-readable prior authorization request and an electronic approval, denial, or request for additional documentation;
an electronic payment instruction
a computer-readable fulfillment instruction, processable by a specialty pharmacy subsystem or a manufacturer distribution system, as implementing the step of specifying a delivery mode selected from direct-to-patient delivery and provider-site delivery, including delivery to an integrated payer-provider facility;
electronically writing a time-stamped event record to an encrypted, access-controlled repository;
a payer-facing electronic ledger
external systems may supply data to the platform or carry out actions in response to computer- readable instructions issued by the platform as a means of using computers to apply the abstract idea, e.g., providing data electronically or performing actions electronically
enforcing message-level encryption in transit, encryption at rest, and role-based access logging for operations (a)-(f)
enforcing message-level encryption in transit, encryption at rest, and role-based access logging for operations (a)-(f); as a means of electronically protecting information
Claim 115
an integrated treatment-payment platform for a specialty drug treatment of a disease or disorder as implementing the steps of the abstract idea
a secure API gateway as implementing the step of receive prescriptions and prior authorization requests for the specialty drug;
a rules engine as implementing the step of evaluate a payer-specific drug formulary and prior authorization rules and compute an authorization outcome and, when prior authorization is required, to issue a computer-readable prior authorization request and to receive an electronic approval, denial, or request for additional documentation;
a payments module as implementing the step of generate an electronic payment instruction specifying any patient copayment or coinsurance, to cause authorization or initiation of the instruction via a payment network,
a fulfillment engine as implementing the step of generate and cause execution of a computer-readable fulfillment or administration instruction,
a specialty pharmacy subsystem or a manufacturer distribution system as implementing the step of specifying a delivery mode selected from direct-to-patient delivery and provider-site delivery, including delivery to an integrated payer-provider facility;
an event-ingest service as implementing the step of receive a confirmation event comprising at least one of: shipment, delivery, dispense, or administration information;
wherein components (a)-(h) are operable together such that, upon receipt of the prescription and the prior authorization request through the secure API gateway, the platform automatically performs the operations of computing the authorization outcome, generating and causing execution of the electronic payment instruction, generating and causing execution of the fulfillment instruction, receiving the confirmation event and writing the time-stamped event record, and updating the payer-facing ledger as a means of electronically implementing the steps of the abstract idea
a policy-enforcement component configured to enforce message-level encryption in transit, encryption at rest as a means of electronically protecting information
role-based access logging for operations of the gateway, rules engine, payments module, fulfillment engine, event-ingest service, data store, and
the ledger store or transaction log, and to require a confirmation event prior to settlement by the payments module as a means of electronically logging events
The broad recitation of the aforementioned general purpose computing elements and performing steps “electronically” at a high level of generality only amounts to mere instructions to implement the abstract idea using computing components as tools.
Regarding at least one processor of an integrated treatment- payment platform, the specification does not appear to disclose any particulars (e.g., structure) of the “platform” or “processor”. Per originally filed claims (3/16/21) this is understood to be a computer system with a processor operating in its ordinary capacity to implement the steps of the abstract idea.
Regarding (various) computer-readable instructions, the specification does not appear to disclose any particulars of computer-readable instructions. Per originally filed claims (3/16/21) this is understood to be a computer system with a processor operating in its ordinary capacity to execute computer-readable instructions to implement the steps of the abstract idea.
Regarding the provider-side/patient-side application, the specification only discloses that the system may be made available via a “mobile device app’’ (para. [0123]). No particulars of the app are provided. As such, it is given its broadest reasonable interpretation as a general purpose computing element and amounts to mere instructions to apply the abstract idea on a general purpose computing device.
Regarding processor-executable comparison/reimbursement/assurance logic, the specification does not appear to disclose any particulars of computer-executable logic. Per originally filed claims (3/16/21) this is understood to be a computer system with a processor operating in its ordinary capacity to use execute instructions (“logic”) to implement the steps of the abstract idea.
Regarding “signal”, the specification only appears to disclose “signal” in context with cell signaling ([0252]) and amplifying cell signal by using an antibody or reagent ([0313]) which are not consistent with the use “signal” in the claims. As such, “signal” (e.g., therapeutic effectiveness signal) is given its broadest reasonable interpretation as an electronic indication. Per originally filed claims (3/16/21) this is understood to be a computer system with a processor operating in its ordinary capacity to implement the steps of the abstract idea and as such, a “signal” only amounts to applying the abstract idea on a general purpose computer.
Regarding “external systems”, the specification does not disclose any particulars of “external systems”. These external systems are therefore given their broadest reasonable interpretation as general purpose computing systems functioning in their ordinary capacities.
Regarding the database/database system, para. [0034] discloses “a database comprising a plurality of such medical records” and “the database is in a form of electronic, optical, paper, or some combination”. No particulars or structures of the database are provided. As such, the database is given its broadest reasonable interpretation as a general purpose database functioning in its ordinary capacity to implement the steps of the abstract idea.
Regarding a provider system, no particulars of the provider system are disclosed. Per originally filed claims (3/16/21) this is understood to be a computer system with a processor operating in its ordinary capacity.
Regarding a secure electronic interface, no particulars of the interface are provided. This is interpreted as being the interface of a mobile device per [0123]; as no particulars of the mobile device or any other computing devices are provided, this element is given its broadest reasonable interpretation as the electronic interface of a general purpose computing device functioning in its ordinary capacity.
Regarding the various instances of “electronic”, e.g., electronic approval, electronic payment instr