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 instruction, electronically writing a time-stamped event, an electronic ledger: this only amounts to mere instructions to apply the abstract idea on a computer. Per originally filed claims (3/16/21) this is understood to be a computer system with a processor operating in its ordinary capacity.
Regarding the specialty pharmacy subsystem or manufacturer distribution system, no particulars are provided. These are given their broadest reasonable interpretation as general purpose computers used to apply the abstract idea.
Regarding enforcing message-level encryption in transit, encryption at rest, and role-based access logging for operations (a)-(f), the specification does not provide any particulars of the encryption process other than to state that communication streams are encrypted and data and apps are secured (encrypted) to comply with HIPAA ([0124]). Accordingly, this only amounts to using a general purpose computer to electronically protect information in transit.
Regarding the secure API gateway, rules engine, payments module, fulfillment engine, event-ingest service: the specification does not describe or disclose any of these elements. For purposes of this 101 analysis, per originally filed claims (3/16/21), these elements are being interpreted as software/hardware installed on a general purpose computer system with a processor operating in its ordinary capacity, to implement the respective claimed function.
Regarding 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, this only amounts to using the platform, understood to be general purpose computing system as previously explained, to implement the steps of the abstract idea.
Regarding a policy-enforcement component configured to enforce message-level encryption in transit, encryption at rest the specification does not provide any particulars of the encryption process other than to state that communication streams are encrypted and data and apps are secured (encrypted) to comply with HIPAA ([0124]). Accordingly, this only amounts to using a general purpose computer to electronically protect information in transit
Regarding a 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, the specification does not provide any particulars nor does it disclose the various components above (gateway, rules engine, etc.) and as such, for purposes of examination, this is being interpreted as general purpose computing elements used to apply the abstract idea.
The above additional elements are therefore not sufficient to integrate the abstract idea into a practical application. Looking at the limitations as an ordered combination adds nothing that is not already present when looking at the elements taken individually.
B. Insignificant Extra-Solution Activity. MPEP 2106.05(g)
Claim 98 additionally recites:
storing one or more therapeutic effectiveness datasets in an encrypted, access-controlled repository
Claim 105 additionally recites:
store, via a secure electronic interface, 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
store the processed data and results of the processing for real-time or subsequent retrieval and use and retrieve the data
Claim 112 additionally recites:
storing a payment-network authorization record
Claim 115 additionally recites:
to store a payment-network authorization record;
an encrypted, role-segmented data store configured to persist time-stamped event records;
a ledger store or transaction log configured to maintain a payer-facing electronic ledger updated based on the event records;
These elements amount to insignificant extra-solution activity. As explained above, Claims 98, 105, 112, 115 are all directed to an abstract idea in the forms of obtaining, processing, analyzing, and outputting patient, treatment outcome/efficacy, payment authorization, and payment information. As stated in MPEP 2106.05(g), "[t]he term "extra-solution activity" can be understood as activities incidental to the primary process or product that are merely a nominal or tangential addition to the claim." In the present claim, the functions of storing the various data recited by claims 98, 105, 112, 115 are only nominally or tangentially related to the processes of obtaining, processing, analyzing, and outputting patient, treatment outcome/efficacy, payment authorization, and payment information to provide efficacy assurance for a drug treatment of a disease/disorder.
The above elements in Sections A and B above are therefore not sufficient to integrate the abstract idea into a practical application. Looking at the limitations as an ordered combination adds nothing that is not already present when looking at the elements taken individually.
The above claims, as a whole, are therefore directed to an abstract idea.
Step 2B
The present claims do not include additional elements that are sufficient to amount to
more than the abstract idea because the additional elements or combination of elements amount to no more than a recitation of:
A. Instructions to Implement the Judicial Exception. MPEP 2106.05(f)
As explained above, claims 98, 105, 112, 115 only recite the aforementioned computing elements as tools for performing the steps of the abstract idea, and mere instructions to perform the abstract idea using a computer is not sufficient to amount to significantly more than the abstract idea. MPEP 2106.05(f).
B. Insignificant Extra-Solution Activity. MPEP 2106.05(g)
Likewise, the steps of storing one or more therapeutic effectiveness datasets in an encrypted, access-controlled repository; store, via a secure electronic interface, 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; store the processed data and results of the processing for real-time or subsequent retrieval and use and retrieve the data; storing a payment-network authorization record; to store a payment-network authorization record; an encrypted, role-segmented data store configured to persist time-stamped event records; a ledger store or transaction log configured to maintain a payer-facing electronic ledger updated based on the event records; only amount to insignificant extra-solution activity.
C. Well-Understood, Routine and Conventional Activities. MPEP 2106.0S(d)
In addition to amounting to insignificant extra-solution activity the elements in Section B above constitute well-understood, routine and conventional activity. The various limitations pertaining to “storing” data in the independent claims as described above only amount to storing/retrieving data in memory, which has been previously held to be well-understood, routine and conventional when claimed at a high level of generality or as insignificant extra-solution activity. See MPEP 2106.05(d)(II).
Thus, taken alone, the additional elements do not amount to significantly more than the
above-identified judicial exception. Looking at the limitations as an ordered combination adds
nothing that is not already present when looking at the elements taken individually. Their
collective functions merely provide conventional computer implementation.
Depending Claims
Dependent claims 99-104, 106-111, 113-114, 116-119 recite additional subject matter which further narrows the scope of the abstract idea embodied in the claims and/or recite limitations that are certain methods of organizing human activity as described below.
Claims 99, 100, 117-119 recite limitations that further narrow the scope of the abstract ideas set out in their respective independent claim above.
Claims 101-104, 106-111, 113-114, 116 all recite limitations that are also directed to certain methods of organizing human activity, including managing personal behavior. These claims all recite various limitations that amount to obtaining data, processing/ analyzing data in various ways (e.g., comparing data), making a decision or determination, and outputting a result/determination, which are personal behaviors that may be performed by a healthcare provider or healthcare insurance personnel.
The dependent claims recite additional elements consistent with those additional elements already identified and discussed above with respect to the independent claims, and only amount to mere instructions to apply the abstract idea on a general purpose computer functioning in its ordinary capacity and/or limitations which amount to insignificant extra-solution activity in the form of storing/retrieving data in memory, which has been held to be well-understood, routine and conventional when claimed at a high level of generality.
The dependent claims have been given the full two-part analysis including analyzing the additional limitations both individually and in combination. The dependent claims, when analyzed individually, and in combination, are also held to be patent ineligible under 35 U.S.C. 101 as they include all of the limitations of their respective parent claim. The additional recited limitations of the dependent claims fail to establish that the claims do not recite an abstract idea because the additional recited limitations of the dependent claims merely further narrow the abstract idea. Beyond the limitations which recite the abstract idea, the claims recite additional elements consistent with those identified above with respect to the independent claims which encompass 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 - see MPEP 2106.05(f), or are insignificant extra-solution activity. Looking at the limitations as an ordered combination adds nothing that is not already present when looking at the elements taken individually. There is no indication that the combination of elements improves the functioning of a computer or improves any other technology. Their collective functions merely provide conventional computer implementation. Accordingly, these additional elements do not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea.
Dependent claims 99-104, 106-111, 113-114, 116-119, when analyzed as a whole, are held to be patent ineligible under 35 U.S.C. 101 because the additional recited limitation(s) fail(s) to establish that the claim(s) is/are not directed to an abstract idea without significantly more. These claims fail to remedy the deficiencies of their parent claims above, and are therefore rejected for at least the same rationale as applied to their parent claims above, and incorporated herein.
For the reasons stated, Claims 98-119 fail the Subject Matter Eligibility Test and are consequently rejected under 35 U.S.C. 101.
Response to Applicant’s Remarks/Arguments
Please note: When referencing page numbers of Applicant’s response, references are to page numbers as printed.
Note to Applicant
At page 14, Applicant remarks:
PNG
media_image1.png
551
1412
media_image1.png
Greyscale
Regarding cancellation of claims and renumbering rather than marking up existing claims, please see MPEP 714(C), Amendments to the Claims, section (B):
(B) Markings to Show the Changes: All claims being currently amended must be presented with markings to indicate the changes that have been made relative to the immediate prior version. The changes in any amended claim must be shown by strike-through (for deleted matter) or underlining (for added matter) with 2 exceptions: (1) for deletion of five or fewer consecutive characters, double brackets may be used (e.g., [[eroor]]); (2) if strike-through cannot be easily perceived (e.g., deletion of number "4" or certain punctuation marks), double brackets must be used (e.g., [[4]]). As an alternative to using double brackets, however, extra portions of text may be included before and after text being deleted, all in strike-through, followed by including and underlining the extra text with the desired change (e.g., number 14 as ). An accompanying clean version is not required and should not be presented. Only claims of the status "currently amended" or "withdrawn" will include markings.
Examiner acknowledges Applicant’s detailed explanation of which subject matter from prior-filed claims has been re-presented into new claims, e.g., at least at pages 16-18 (e.g., “Claim lineage”). If the substance is indeed being “re-presented” from prior filed claims, please follow the standard set forth in MPEP 714 for providing markings to properly document amended limitations in future amendments, should Applicant choose to amend.
Rejections under 35 USC 101
Applicant’s remarks have been fully considered but are not persuasive.
Applicant argues:
(Page 18-19): Applicant disagrees with the OA’s characterization of the pending claims as directed to “certain methods of organizing human activity”.
(Page 19) Step 2A, Prong One - The claims are not "directed to" a judicial exception. The "character as a whole" of each independent claim is a technological platform workflow, not a business policy.
Regarding (a), the Examiner disagrees. As an initial matter, Examiner never asserted that the claims are directed to a “business policy”.
MPEP 2106. 04(a)(2)(II) states that a claimed invention is directed to certain methods of organizing human activity if the identified claim elements contain limitations that encompass fundamental economic principles or practices, commercial or legal interactions, or managing personal behavior or relationships or interactions between people (including social activities, teaching, and following rules or instructions). The Examiner submits that the identified claim elements represent personal behaviors that a person or persons, such as a healthcare provider or personnel working in the insurance field, with or without the aid of a computer, would perform to provide efficacy assurance for a specialty drug treatment of a disease or disorder. Furthermore, the Examiner submits that healthcare itself is inherently represents the organization of human activity.
Applicant has not pointed to anything in the claims that fall outside of this characterization. Recitation of the various additional elements (computer-readable instructions, etc.), these only amount to mere instructions to apply the abstract idea using a computer functioning in its ordinary capacity, as discussed above in detail in main 101 analysis section. Because the claim elements fall under a series of personal behaviors that a person or persons would follow to provide efficacy assurance for a specialty drug treatment of a disease or disorder, the claimed invention is directed to an abstract idea.
Regarding Applicant’s remarks regarding each individual independent claim at page 19, Examiner respectfully disagrees with Applicant’s position and maintains the position that as discussed above, the claims are directed to an abstract idea and only recite the platform and other additional elements as a means to apply the abstract idea. For example, the “processor-executed” workflow using “processor-executable comparison logic” and “computer-readable instructions” only amounts to mere instructions to apply the abstract idea: a medical provider could take defined clinical/theragnostic inputs and convert/transform them into a therapeutic effectiveness metric by performing a calculation. The same rationale applies to the other steps listed at top of page 19; these are all personal behaviors that could be performed by a healthcare provider or insurance personnel that are being implemented on a general purpose computer. This argument is not persuasive.
Regarding remark that “These recitations are concrete computing operations and data-structure transformations, not mental steps”: Examiner never asserted the claims were “mental steps”. A claim can be directed to certain methods of organizing human activity even if the steps cannot be performed mentally. This argument is not persuasive.
Step 2A, Prong Two - Integration into a practical application. Even assuming an identified abstract idea, the additional elements integrate any such idea into a practical application.
Regarding (b) and remarks pertaining to “specific data transformation” at page 20, the Examiner respectfully disagrees. MPEP 2106.04(d)(2) indicates that a practical application may be present where the claimed invention effects a transformation or reduction of a particular article to a different state or thing. MPEP 2106.05(c) thereafter describes that a transformation is present where a physical object or substance is transformed to a different state or thing. Notably, the mere manipulation of data has been deemed not to be a transformation within the meaning of the term “transformation.” Because no transformation is present in Applicant’s claimed invention, a practical application is not present.
Regarding generation and execution of computer-readable instructions, this only amounts to mere instructions to apply the abstract idea on a general purpose computer as discussed above in main 101 analysis section. Similarly, receiving confirmations and writing records falls within the scope of the abstract idea and merely recites the computing elements as instructions to implement on a computer. Policy enforcement and security, to the extent described in the claims, only amounts to mere instructions to implement the abstract idea on a computer. Platform data structures enabling machine execution, to the extent described in the claims and specification, only amounts to using a computer to implement the abstract idea, e.g., using a processor to output a payer-facing record. Regarding Claims 112 and 115, Examiner submits that as presented, the claims are directed to certain methods of organizing human activity and only recite the additional elements as tools for implementing the abstract idea. See detailed breakdown in 101 analysis section above. These arguments are not persuasive.
Commercialization-grade fulfillment platform… This is a concrete, end-to-end electronic
improvement in specialty drug commercialization operations, not a mental process (step (d) in
claims 112, 115).
Regarding (c), The claim limitations have not been characterized as being directed to mental processes. This argument is moot. For argument’s sake, simply because the steps are “not a mental process” does not preclude the claims from being directed to certain methods of organizing human activity. Regarding Applicant’s remark to “a concrete, end-to-end electronic
improvement in specialty drug commercialization operations”, Examiner submits that any purported improvements may improvements to the abstract idea itself, e.g., an improvement to specialty drug commercialization operations. However, any purported improvements appear to come from the steps of the abstract idea itself. Regarding patentability requirements under 35 USC 101, please reference MPEP 2106.04(d)(II) which states, “The analysis under Step 2A Prong Two is the same for all claims reciting a judicial exception, whether the exception is an abstract idea, a law of nature, or a natural phenomenon (including products of nature). Examiners evaluate integration into a practical application by: (1) identifying whether there are any additional elements recited in the claim beyond the judicial exception(s); and (2) evaluating those additional elements individually and in combination to determine whether they integrate the exception into a practical application, using one or more of the considerations introduced in subsection I supra, and discussed in more detail in MPEP §§ 2106.04(d)(1), 2106.04(d)(2), 2106.05(a) through (c) and 2106.05(e) through (h)”; please see also MPEP 2106.05(a) which states, “It is important to note, the judicial exception alone cannot provide the improvement. The improvement can be provided by one or more additional elements.” Applicant has not demonstrated, nor can Examiner find, evidence in the originally filed disclosure that describes how the additional elements provide an improvement over prior art systems. This argument is not persuasive.
Step 2B - "Significantly more". The OA asserts that the computer elements are generic and well-understood, routine, and conventional (WURC). As presented, the claims recite non-generic, ordered combinations that provide a specific improvement in platform operation.
Regarding (d), The Examiner respectfully disagrees. The Examiner respectfully submits that whether the claims recite “ordered combinations” is immaterial with regard to whether a practical application or significantly more is present. The "ordered combination" analysis refers to identified additional elements and whether the ordered combination of additional elements is sufficient to render the claim subject matter eligible. The Applicant has not identified, nor can the Examiner find, any combination of additional elements that render the claims subject matter eligible. MPEP 2106.05(d) states: “Another consideration when determining whether a claim recites significantly more than a judicial exception is whether the additional element(s) are well-understood, routine, conventional activities previously known to the industry (emphasis added).” It is only the additional elements identified by the Examiner to not be part of the abstract idea that are analyzed to determine whether they represent well-understood, routine, conventional activities in the field of the invention.
In that regard, MPEP 2106.05(d)(I) indicates that in determining whether the additional elements represent are well-understood, routine, conventional activities, the Examiner should consider whether the additional elements (1) provide an improvement to the technological environment to which the claim is confined, (2) whether the additional elements are mere instructions to apply the judicial exception, or (3) whether the additional elements represent insignificant extra-solution activity. The additional elements of the claims do not provide significantly more based on this inquiry, as explained in detail in 101 analysis section above.
Taking these in turn, whether the additional elements of the claim provide an improvement was addressed in the 2A2 analysis; the additional elements do not provide an improvement over prior art systems as described in Applicant’s specification. The technological environment to which the claims are confined (a general-purpose computer performing generic computer functions) is recited at a high level of generality and has been found by the courts to be insufficient to provide a practical application (see MPEP 2106.05(d)(II); Alice Corp.). The additional elements pertaining to storing data (see 101 analysis section above) that were found to represent extra-solution activity were analyzed and determined to represent well-understood, routine, conventional activities in the field, e.g., storing/retrieving data in memory. As such, when viewed either individually or as an ordered combination, the additional elements do not provide significantly more to the abstract idea and the claims are not subject matter eligible.
Examiner submits that at page 22, Applicant appears to be arguing a particularly narrow interpretation of the claims, for which there may or may not be adequate support in the specification as originally filed (e.g., “settlement gating dependency”, “cross-module gating”). The features cited by applicant at page 22 are considerably more narrow/specific than what is actually claimed. Regardless, all amount to either mere instructions to apply the abstract idea, steps that fall within the scope of the abstract idea, or insignificant extra solution activity that has been found to be well understood, routine and conventional. This argument is not persuasive.
Regarding remark “Under In re Berkheimer, whether claim elements are well-understood, routine, and conventional (WURC) is a factual determination requiring evidentiary support.”. As explained above, this applies to additional elements, not to “claim elements”, e.g., those within the scope of the abstract idea. This argument is not persuasive.
For all of the above reasons, Claims 98-119 are rejected under 35 USC 101.
Examiner has thoroughly reviewed the as-filed disclosure and cannot suggest a path forward that would render the claimed invention subject-matter eligible.
Rejections under 35 USC 103
Applicant’s arguments have been fully considered. The prior art rejections are withdrawn in view of Applicant’s remarks and amended claims. A search of publicly available prior art fails to yield a reference or combination of references that would make the claimed combination of elements obvious when considered as a whole.
Conclusion
Examiner respectfully requests that Applicant provides citations to relevant paragraphs of specification for support for amendments in future correspondence.
The following relevant prior art not cited is made of record:
US Publication 20140201095 A1, teaching on a healthcare assurance system
US Publication 20090254371 A1, teaching on quality assurance methods for medication therapy management
THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee 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 date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ANNE-MARIE K ALDERSON whose telephone number is (571)272-3370. The examiner can normally be reached on Mon-Fri 9:00am-5:00pm EST, and generally schedules interviews in the timeframe of 2:00-5:00pm EST.
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, Fonya Long, can be reached on 571-270-5096. 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.
/ANNE-MARIE K ALDERSON/Primary Examiner, Art Unit 3682
Prosecution Insights