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 present action filed on 07/25/2024.
Claims 1-15 are currently pending and have been examined.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 07/25/2024 was filed before the mailing date of the first action on the merits. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Claim Objections
Claim 7 is objected to for stating “the protocol package”. Examiner will interpret this limitation as “the protocol loading package” with the antecedent for this limitation established in Claim 1.
Claim 4 is objected to for reciting “the algorithm hosting platform” and “the protocol hosting platform”. These limitations lack antecedent basis in the claim or in Claim 1 upon which Claim 4 depends. Appropriate correction is required.
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 limitations are:
An algorithm monitor module adapted to receive a request message for access to one of the inference algorithms, assess a predefined one or more release conditions for the inference algorithm, and generate a release flag for a given algorithm if the predefined one or more release conditions are met (Claim 1)…read metadata for the algorithm,…determine whether the required input data for the specified algorithm is available, and generate release flags if the input data requirements are met (Claim 9)…execute a data collection sub-routine (Claim 10)… execute background operations…, for at least a subset of the inference algorithms in the algorithm datastore, monitoring whether the required input data for each algorithm is currently available and, if the required input data is not available, executing a data collection sub-routine for acquiring supplementary data to supplement the currently available data; (Claim 12)… read the metadata for the algorithm in the algorithm datastore; determine whether a patient associated with the input patient data matches the patient population type; and generate a release flag for a given algorithm only if the patient population type requirements are met (Claim 13).
a protocol module adapted to: receive a request message for loading one of the clinical protocols, and generate a protocol loading package comprising the protocol specification for the specified protocol (Claim 1);… read the metadata for the specified protocol to identify the required patient personalization data, access a patient data source to obtain the required patient personalization data, and configure the protocol in the protocol package with the patient data (Claim 7)… read the metadata for the specified protocol to identify the required clinical parameter data, determine whether the required clinical parameter data for the specified protocol is currently available; if the required clinical parameter data is not available, execute a data collection sub-routine for obtaining the required clinical parameter data (Claim 8)… execute background operations during running of the system comprising, for at least a subset of the protocols in the protocol datastore, monitoring whether the required clinical parameter data for running each protocol is currently available and, if the required input data is not available, executing a data collection sub-routine for obtaining the required clinical parameter data (Claim 12).
an orchestrator module, adapted to: receive one or more risk messages or alerts indicative of possible clinical risks (Claim 1);… receive release flags… responsive to a sent request message relating to a specified algorithm, and push released algorithms to the algorithm hosting platform for execution (Claim 2)… receive protocol loading packages from the protocol module, and push protocol specifications comprised by received protocol loading packages to the protocol hosting platform (Claim 3)… receive said risk messages or alerts (Claim 4)… communicate with a data collection sub-system to request acquisition of the supplementary data (Claim 10)… receive a prescription medication recommendation from a running protocol; fill… a medication request form based on the request; generate an alert on a user interface to alert a user to the medication recommendation; receive a user input…indicative of acceptance or rejection of the medication recommendation, and responsive to acceptance, forwarding the form to a prescription request platform (Claim 14).
an algorithm hosting platform adapted to host and run any of the one or more of the inference algorithms (Claim 2).
a protocol hosting platform adapted to host any of the one or more protocols (Claim 3).
a patient monitoring control module adapted to receive and compile data (Claim 15).
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.
An algorithm monitor module adapted to receive a request message for access to one of the inference algorithms, assess a predefined one or more release conditions for the inference algorithm, and generate a release flag (element 32 in Fig. 1);
a protocol module adapted to receive a request message for loading one of the clinical protocols, and generate a protocol loading package (element 34 in Fig. 1);
an orchestrator module, adapted to receive one or more risk messages or alerts indicative of possible clinical risks (element 22 in Fig. 1).
an algorithm hosting platform adapted to host and run any of the one or more of the inference algorithms (element 52 in Fig. 1).
a protocol hosting platform adapted to host any of the one or more protocols (element 54 in Fig. 1).
a patient monitoring control module adapted to receive and compile data (p. 8, lines 29-31).
Therefore, the claim limitations will be interpreted to be a hardware and software computer program (see MPEP § 2181(II}(B) wherein when the supporting disclosure for a computer-implemented invention discusses the implementation of the functionality of the invention through hardware, software, or a combination of both, a question can arise as to which mode of implementation supports the means-plus-function limitation. The language of 35 U.S.C. 112(f) requires that the recited "means" for performing the specified function shall be construed to cover the corresponding "structure or material" described in the specification and equivalents thereof. Therefore, by choosing to use a means-plus-function limitation and invoke 35 U.S.C. 112(f} applicant limits that claim limitation to the disclosed structure, i.e., implementation by hardware or the combination of hardware and software, and equivalents thereof. Therefore, the examiner should not construe the limitation as covering pure software implementation).
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 § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-15 are rejected under 35 USC § 101 as being directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more.
Step 1 Analysis:
Independent Claim 1 is within the four statutory categories as it is directed to a system. Dependent Claims 2-15 are further drawn to a system and therefore also fall into one of the four statutory categories.
Step 2A Analysis- Prong One:
Claim 1, which is representative of the inventive concept, recites the following:
A clinical decision support system, comprising: an algorithm datastore storing: a plurality of inference algorithms,
wherein each inference algorithm is adapted to receive a set of input patient data and generate an output metric or score indicative of a pre-defined aspect of patient status or for a pre-defined clinical risk;
a protocol datastore storing: a plurality of clinical protocol specifications, each protocol specification comprising a data representation of a clinical protocol associated with monitoring and/or treating a patient in respect of a pre-defined clinical condition or clinical risk,
and optionally including one or more machine-executable steps;
an algorithm monitor module adapted to: receive a request message for access to one of the inference algorithms, assess a predefined one or more release conditions for the inference algorithm, and generate a release flag for a given algorithm if the predefined one or more release conditions are met;
a protocol module adapted to: receive a request message for loading one of the clinical protocols, and generate a protocol loading package comprising the protocol specification for the specified protocol;
a risk database, recording, for each of a plurality of different clinical risks, one or more suitable clinical protocols and/or inference algorithms for responding to the risk;
an orchestrator module, adapted to: receive one or more risk messages or alerts indicative of possible clinical risks; responsive to receiving a risk message, consult the risk database to identify an inference algorithm in the algorithm datastore suitable for monitoring the relevant risk and/or to identify a protocol in the protocol datastore suitable for managing the risk;
and generate a request message for sending to the algorithm monitor module for requesting access to the identified inference algorithm(s) and/or sending a request message to the protocol module for requesting loading of the identified protocol.
The limitations as shown in underline above, given the broadest reasonable interpretation, cover the abstract idea of certain methods of organizing human activity because they recite managing personal behavior or relationships or interactions between people (i.e. social activities, teaching, and following rules or instructions, and/or mental process that a neurologist should follow when testing a patient for nervous system malfunctions- in this case, receiving input data, generating an output score, recording clinical protocols for each clinical risk, and sending request messages for loading an identified protocol), e.g. see MPEP 2106.04(a)(2). Any limitations not identified above as part of the abstract idea are deemed “additional elements” and will be discussed in further detail below.
Dependent Claims 5-15 include other limitations directed toward the abstract idea. For example, Claim 5 recites receiving risk alerts responsive to the metric or score, Claim 6 recites responsive to receipt of a request message, reading [data] for the specified protocol to identify any further clinical risk associated with any one or more steps of the protocol and retrieving clinical risk information, Claim 7 recites the use of patient personalization data for configuring protocols, Claim 8 recites protocol data indicates required patient clinical parameter data for running the protocol, determining whether a required clinical parameter data for the protocol is available, and if not, executing a data collection sub-routine, Claim 9 recites responsive to receipt of a request message, determining whether the required input data is available, Claim 10 recites executing a data collection routine to acquire supplementary data, Claim 11 recites sending a protocol recommendation, including recommended steps for acquiring input information that is not available, Claim 12 recites monitoring whether the required input data is currently available, and, if not, executing a data collection sub-routine to acquire the supplementary data, Claim 13 recites determining whether a patient associated with the input patient data matches the patient population type and generating a release flag is requirements are met, Claim 14 recites receiving a prescription medication recommendation, filling one or more fields of a medication request form based on the request, generating an alert, receiving a user input indicative of acceptance or rejection of the medication recommendation, and responsive to acceptance, forwarding the form to a prescription request platform, Claim 15 recites compiling data. These limitations only server to further narrow the abstract idea, and a claim may not preempt abstract ideas, even if the judicial exception is narrow, e.g., see MPEP 2106.04. Additionally, any limitations in dependent Claims 2-15 not addressed above are deemed additional elements to the abstract idea and will be further addressed below. Hence dependent Claims 5-15 are nonetheless directed towards fundamentally the same abstract idea as independent Claim 1.
Step 2A Analysis- Prong Two:
Claim 1 is not integrated into practical application because the additional elements (i.e. the non-underlined limitations above – in this case, the algorithm datastore, inference algorithm, protocol datastore, algorithm monitor module, protocol module, risk database, and orchestrator module of Claim 1) are recited at a high level of generality (i.e. as a generic processor performing generic computer functions) such that they amount to no more than mere instructions to apply an exception using generic computer parts. For example, Applicant’s specification explains that the system 30 includes an algorithm datastore 42 storing: a plurality of algorithms for use in monitoring patient condition and/or predicting patient condition. At least a subset of the algorithms may be machine learning algorithms. The algorithms may be inference algorithms (Applicant’s specification, p. 10, lines 19-21). In some embodiments, the protocol datastore further stores, for each protocol, metadata indicating: required patient personalization data for configuring the protocol (p. 5, lines 32-33). [T]he algorithm monitor module automatically keeps track of required input information for an algorithm to run correctly, and restricts usage of algorithms if the necessary input information is not available (p. 7, lines 19-21). [T]he protocol module is configured to automatically manage the retrieval of necessary data for configuring or tuning parameters of a protocol in accordance with patient-specific data (p. 5, lines 11-12). As discussed above, the orchestrator module 22 orchestrates when the inference algorithms and the clinical protocols are executed and when they are terminated via the designated platforms (i.e. algorithm hosting platform 54 and the protocol hosting platform 52) (p. 16, lines 32-35). Accordingly, these additional elements, when considered separately and as an ordered combination, do not integrate the abstract idea into practical application because they do not impose any meaningful limits on the abstract idea. Therefore, independent Claim 1 is directed to an abstract idea without practical application.
Dependent Claims 2-15 recite additional elements. Claim 2 recites the previously recited additional elements of the inference algorithm, orchestrator module and algorithm monitoring module as well as a new additional element of an algorithm hosting platform, and Claim 2 states the algorithm hosting platform is adapted to run any of the inference algorithms, and the orchestrator module receives release flags generated by the algorithm monitoring model responsive to a sent request message relating to a specified algorithm. Claim 3 recites the previously recited orchestrator module and protocol module and a new element of a protocol hosting platform and loading packages, and Claim 3 states the protocol hosting platform hosts any of the protocols and the orchestrator module receives protocol loading packages from the protocol module. Claim 4 recites the previously recited orchestrator module and user interface as well as new elements of algorithm hosting platform and a protocol hosting platform, and Claim 4 states the orchestrator module receives messages from the algorithm hosting platform, protocol hosting platform, protocol module, and user interface. Claim 5 recites the previously recited inference algorithm and states the inference algorithm generates a risk alert responsive to a metric/score generated by the algorithm passing a risk threshold. Claim 6 recites the previously recited protocol datastore, protocol module, and protocol loading package as well as a new additional element of metadata, and Claim 6 states the protocol data store stores metadata indicating risk associated with steps of the protocol, and the protocol module reads metadata for a specified protocol to identify risk, and the protocol loading packages includes the retrieved clinical risk information. Claim 7 recites the previously recited protocol datastore, metadata, and protocol module and specifies the protocol datastore stores metadata, and the protocol module reads metadata for the specified protocol to identify required data. Claim 8 recites the previously recited protocol datastore, metadata, and protocol module and specifies the protocol datastore stores metadata, and the protocol module reads the metadata for the specified protocol to identify the required clinical parameter data. Claim 9 recites the previously recited protocol algorithm datastore, inference algorithm, metadata, and algorithm monitor module, and Claim 9 states the algorithm datastore stores metadata for each inference algorithm, and the algorithm monitor module reads the metadata for the relevant specified algorithm in the algorithm datastore and determines whether the required input data for the algorithm is available. Claim 10 recites the previously recited algorithm monitor module, orchestrator module, and algorithm as well as a new element of a data collection sub-system, and Claim 10 states the algorithm monitor module executes a data collection sub-routine, and the sub-routine includes sending to the orchestrator module a data collection request message, and the orchestrator module communicates with a data collection sub-system to request acquisition of the supplementary data. Claim 11 recites the previously recited algorithm and orchestrator module and specifies the data collection sub-routine includes sending a protocol recommendation message to the orchestrator module, recommending execution of a protocol, wherein the recommended protocol includes steps for acquiring the required information for the specified algorithm. Claim 12 recites the previously recited algorithm monitor module, protocol module, inference algorithm, algorithm, and protocol datastore, and Claim 12 states the algorithm monitor module executes background operations during running of the system including monitoring whether required input data for each algorithm of the subset of inference algorithms is available, and the protocol module executes background operations for each subset of the protocol datastore of determining whether the required clinical parameter data for running each protocol is available. Claim 13 recites the previously recited algorithm monitor module, algorithm datastore, inference algorithm, and metadata, and Claim 13 states the algorithm datastore stores, for each inference algorithm, associated metadata including a patient population type for which the algorithm is configured to be applied, and further, the algorithm monitor module reads the metadata for the algorithm in the algorithm datastore and determines whether a patient matches, then generates a release flag for the algorithm only if the requirements are met. Claim 14 recites the previously recited orchestrator module and user interface as well as a new additional element of a prescription request platform, and Claim 14 states the orchestrator module receives prescription medication recommendation from running a protocol, generates an alert on a user interface, receives a user input from the user interface, and in response to acceptance, forwards the form to a prescription request platform. Claim 15 recites new additional elements of a patient monitoring sub-system, physiological parameter sensors, and a patient monitoring control module and states a patient monitoring sub-system includes physiological parameter sensors and a patient monitoring control module adapted to receive and compile data from the one or more physiological parameter sensors.
Step 2B Analysis:
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to the integration of the abstract idea into a practical application, the additional elements of the algorithm datastore, inference algorithm, protocol datastore, algorithm monitor module, protocol module, risk database, and orchestrator module of Claim 1 amount to no more than mere instructions to apply an exception using generic computer components. Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept (“significantly more”). MPEP 2106.05(I)(A) indicates that merely stating “apply it” or equivalent to the abstract idea cannot provide an inventive concept (“significantly more”).
Dependent Claims 2-4, 6, 10, and 14-15 recite new additional elements. Claim 2 recites the previously recited additional elements of the inference algorithm, orchestrator module and algorithm monitoring module as well as a new additional element of an algorithm hosting platform, and Claim 2 states the algorithm hosting platform is adapted to run any of the inference algorithms, and the orchestrator module receives release flags generated by the algorithm monitoring model responsive to a sent request message relating to a specified algorithm. Claim 3 recites the previously recited orchestrator module and protocol module and a new element of a protocol hosting platform and loading packages, and Claim 3 states the protocol hosting platform hosts any of the protocols and the orchestrator module receives protocol loading packages from the protocol module. Claim 4 recites the previously recited orchestrator module and user interface as well as new elements of algorithm hosting platform and a protocol hosting platform, and Claim 4 states the orchestrator module receives messages from the algorithm hosting platform, protocol hosting platform, protocol module, and user interface. Claim 6 recites the previously recited protocol datastore, protocol module, and protocol loading package as well as a new additional element of metadata, and Claim 6 states the protocol data store stores metadata indicating risk associated with steps of the protocol, and the protocol module reads metadata for a specified protocol to identify risk, and the protocol loading packages includes the retrieved clinical risk information. Claim 10 recites the previously recited algorithm monitor module, orchestrator module, and algorithm as well as a new element of a data collection sub-system, and Claim 10 states the algorithm monitor module executes a data collection sub-routine, and the sub-routine includes sending to the orchestrator module a data collection request message, and the orchestrator module communicates with a data collection sub-system to request acquisition of the supplementary data. Claim 14 recites the previously recited orchestrator module and user interface as well as a new additional element of a prescription request platform, and Claim 14 states the orchestrator module receives prescription medication recommendation from running a protocol, generates an alert on a user interface, receives a user input from the user interface, and in response to acceptance, forwards the form to a prescription request platform. Claim 15 recites new additional elements of a patient monitoring sub-system, physiological parameter sensors, and a patient monitoring control module and states a patient monitoring sub-system includes physiological parameter sensors and a patient monitoring control module adapted to receive and compile data from the one or more physiological parameter sensors.
Dependent Claims 5, 7-9, and 11-13 recite previously cited additional elements, which are not eligible for the reasons stated above, and further narrow the abstract idea. Claim 5 recites the previously recited inference algorithm and states the inference algorithm generates a risk alert responsive to a metric/score generated by the algorithm passing a risk threshold. Claim 7 recites the protocol datastore, metadata, and protocol module and specifies the protocol datastore stores metadata, and the protocol module reads metadata for the specified protocol to identify required data. Claim 8 recites the protocol datastore, metadata, and protocol module and specifies the protocol datastore stores metadata, and the protocol module reads the metadata for the specified protocol to identify the required clinical parameter data. Claim 9 recites the previously recited protocol algorithm datastore, inference algorithm, metadata, and algorithm monitor module, and Claim 9 states the algorithm datastore stores metadata for each inference algorithm, and the algorithm monitor module reads the metadata for the relevant specified algorithm in the algorithm datastore and determines whether the required input data for the algorithm is available. Claim 11 recites the algorithm and orchestrator module and specifies the data collection sub-routine includes sending a protocol recommendation message to the orchestrator module, recommending execution of a protocol, wherein the recommended protocol includes steps for acquiring the required information for the specified algorithm. Claim 12 recites the algorithm monitor module, protocol module, inference algorithm, algorithm, and protocol datastore, and Claim 12 states the algorithm monitor module executes background operations during running of the system including monitoring whether required input data for each algorithm of the subset of inference algorithms is available, and the protocol module executes background operations for each subset of the protocol datastore of determining whether the required clinical parameter data for running each protocol is available. Claim 13 recites the algorithm monitor module, algorithm datastore, inference algorithm, and metadata, and Claim 13 states the algorithm datastore stores, for each inference algorithm, associated metadata including a patient population type for which the algorithm is configured to be applied, and further, the algorithm monitor module reads the metadata for the algorithm in the algorithm datastore and determines whether a patient matches, then generates a release flag for the algorithm only if the requirements are met. Hence, Dependent Claims 2-15 do not include any additional elements that amount to “significantly more” than the judicial exception.
Thus, taken alone, the additional elements do not amount to significantly more than the abstract idea identified above. Furthermore, looking at the limitations as an ordered combination adds nothing that is not already present when looking at the elements taken individually, and there is no indication that the combination of elements improves the functioning of computer or improves any other technology, and their collective functions merely provide conventional computer implementation.
Therefore, whether taken individually or as an ordered combination, Claims 1-15 are nonetheless rejected under 35 U.S.C 101 as being directed to non-statutory subject matter.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-5, and 14 are rejected under 35 USC 103 as being unpatentable over Chari et al. (US 20140058742 A1) in view of Raman et al. (US 20180140271 A1) and Kwang et al. (KR 20160053651 A).
Regarding Claim 1, Chari discloses the following:
A clinical decision support system, comprising: (Chari discloses CPGs (clinical practice guidelines) provide recommendations to physicians on the diagnosis and management of patients based on the best data currently available on these conditions. CPGs represent the standard of care for the medical treatment of that specific condition [0004]. CPGs are interpreted as a form of clinical decision support. The present disclosure provides a system for interactive implementation of medical guidelines,…[0014].)
an algorithm datastore storing: a plurality of inference algorithms, (Chari discloses to generate recommendations for the medical management of a patient, the system may… employ a single CPG algorithm or multiple CPG algorithms for generating the recommendations [0130]. In the example of FIG. 35D, separate portions of different CPGD algorithms …are combined and executed together. Although this example shows only portions of the algorithms being combined, in some examples one or more whole algorithms from one or more CPGDs may be combined and executed together with portions of algorithms from other CPGDs [0101]. The algorithm for making such calculations may reside in the guideline module and/or the communication interface of the disclosed system [0210].)
wherein each inference algorithm is adapted to receive a set of input patient data and generate an output metric or score indicative of a pre-defined aspect of patient status or for a pre-defined clinical risk; (Chari discloses in order to generate recommendations for the medical management of a patient, the system may (e.g., depending on the patient's disease conditions) employ a single CPG algorithm or multiple CPG algorithms for generating the recommendations [0130]. As shown, the algorithm may include querying whether the patient has diabetes. If the answer is yes, a series of queries may be further posed with the result that a positive answer to any of these queries may place the patient at high risk, with recommendations generated based on this risk stratification [0133].)
a protocol datastore storing: a plurality of clinical protocol specifications, each protocol specification comprising a data representation of a clinical protocol associated with monitoring and/or treating a patient in respect of a pre-defined clinical condition or clinical risk, and optionally including one or more machine-executable steps; (Chari discloses the rules contained in the various CPGDs may be stored in a database of the system [0086]. CPGs provide recommendations to physicians on the diagnosis and management of patients based on the best data currently available on these conditions. CPGs represent the standard of care for the medical treatment of that specific condition [0004]. In some examples, the at least one medical guideline may include at least one medical guideline for a medical condition selected from: Allergy, Alzheimer's disease, Atrial fibrillation, Cancer of various etiologies, Chronic, kidney disease, Chronic obstructive pulmonary disease, Congestive heart failure, Dementia, Depression, Diabetes,…[0017].)
a risk database, recording, for each of a plurality of different clinical risks, one or more suitable clinical protocols and/or inference algorithms for responding to the risk; (Chari discloses at each of 1325, 1350 and 1355, the risk level of the patient may be stored in the patient database for future use. At 1360, the guideline module uses the rules of the dyslipidemia CPGD to generate one or more recommendations based on the determined patient risk level… recommendations may be provided to the user via the output interface…may also be stored in the patient database for future reference [0259-260].)
consult the risk database to identify an inference algorithm in the algorithm datastore suitable for monitoring the relevant risk and/or to identify a protocol in the protocol datastore suitable for managing the risk; (Chari discloses the present disclosure may allow for monitoring of all data values relevant to the CPGDs and may generate recommendations based on spontaneous changes in those data values. For example, an increase in age may cause a patient to move into the high risk category for a particular CPGD and may result in a new set of management recommendations being generated. These may be displayed as a new recommendation for that particular patient [0107]. Implementation of one CPGD may include calling up another CPGD (e.g., a dyslipidemia CPGD may require calculations according to a Reynold’s Risk Score CPGD) [0097]. At each of 1325, 1350 and 1355, the risk level of the patient may be stored in the patient database for future use. At 1360, the guideline module uses the rules of the dyslipidemia CPGD to generate one or more recommendations based on the determined patient risk level. Such recommendations may be provided to the user via the output interface. The recommendations may also be stored in the patient database for future reference [0259-260].)
message…indicative of possible clinical risks; (Chari discloses a case in which the patient is at risk for another disease, in this example labeled D2. In this case, a notification may be generated to alert the physician that the patient is at risk for D2 as illustrated in Box 13 [0316].)
Chari does not disclose the following limitations met by Raman:
a protocol module adapted to: receive a request message for loading one of the clinical protocols,…(Raman teaches the present disclosure provides a computer-implemented method for pulling imaging protocol data to an imaging protocol manager [0009]. At operation 1404, a protocol request is received at the cloud agent 350 for the imaging device 232-236. For example, the command and notification API 356 at the cloud agent 350 receives the command from the command & notification module 317 at the imaging protocol manager 310 to initiate the pull service module 362 at the cloud agent 350 to pull one or more…protocols [0132]. An imaging protocol may define a scanning plane for the associated imaging procedure, specify position and orientation of anatomical structure(s) or region(s) of interest in the patient, etc. [0003]. The Examiner interprets the protocols defining procedures or positions as being the protocol specification and the protocol manager as the protocol module.)
and generate a protocol loading package comprising the protocol specification for the specified protocol; (Raman teaches the imaging protocol manager 310, used in conjunction with the cloud agent 350, can manage uploading, editing, downloading, and monitoring of protocols for multiple modalities and device types across an organization [0097].)
an orchestrator module, adapted to: receive one or more…messages or alerts… responsive to receiving a…message,… (Raman teaches a response queue is used to receive messages from the equipment 232-236 back to the command and notification API 356 of the imaging protocol manager 310. Such messages can indicate completion and/or failure of execution of a command by the equipment 232-236 to pull protocol information from the protocol database 368, etc. [0157]. The Examiner interprets this as a module capable of receiving messages and taking action in response to the message.)
and generate a request message for sending to the…monitor module for requesting access to the identified inference algorithm(s) and/or sending a request message to the protocol module for requesting loading of the identified protocol. (Raman teaches at operation 1404, a protocol request is received at the cloud agent 350 for the imaging device 232-236. For example, the command and notification API 356 at the cloud agent 350 receives the command from the command & notification module 317 at the imaging protocol manager 310 to initiate the pull service module 362 at the cloud agent 350 to pull one or more…protocols [0132, see also Fig. 14].)
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to have modified the system for receiving patient input data and generating an output metric as well as clinical protocols as disclosed by Chari to incorporate a module for loading protocols as taught by Raman. This modification would create a system capable of managing protocols on devices in a consistent manner therefore ensuring patient safety and optimal outcome (see Raman, ¶ 0007).
Chari and Raman do not teach the following limitations met by Kwang:
an algorithm monitor module adapted to: receive a request message for access to one of the [data], (Kwang teaches the control unit 140 has received a request to access the digital content from a user of the plurality of user, requesting authentication on the access of the digital content (p. 4, ¶ 0003).)
assess a predefined one or more release conditions…, and generate a release flag for a given [data] if the predefined one or more release conditions are met; (Kwang teaches releasing condition determination unit 120 serves to determine whether the release conditions are satisfied. Whether meet the release conditions may be different depending on whether the disconnect condition is any form (p. 3, ¶ 0006). If it is determined that the release conditions are satisfied, the security method comprising the steps of: allowing the access to the at least one user of the plurality of users wherein the digital content, the digital content (p. 10, ¶ 0003). The release condition can be set to be met be a unique password for more than one user of the plurality of user input (p. 3, ¶ 0005). The examiner interprets the release condition being a password as a predefined condition.)
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to have modified the system for receiving patient input data and generating an output metric as well as clinical protocols as carrying out protocols through inference algorithms as disclosed by Chari to incorporate receiving a request for access to data and releasing the data if specified conditions are met as taught by Kwang. This modification would create a system capable of ensuring digital content remains secure (see Kwang, p. 1, ¶ 0004).
Regarding Claim 2, Chari, Raman, and Kwang teach the limitations as seen in the rejection of Claim 1 above. Chari further discloses the following:
wherein the system further comprises an algorithm hosting platform adapted to host and run any of the one or more of the inference algorithms;… relating to a specified algorithm…push released algorithms Chari discloses an example of a CPGD for implementing a given CPG (or multiple CPGs) is shown in FIG. 34. In this example, the CPGD may include an algorithm…, which may be called upon by other elements of the system (e.g., by components of the guideline module) to implement the rules of the given CPG. The algorithm may include one or more rules defined according to the directions in a single given CPG…where multiple CPG algorithms are employed, these algorithms may be executed in a sequence that calls on different algorithms or algorithm portions, …[0130].)
Chari does not disclose the following limitation met by Raman:
and wherein the orchestrator module is adapted to: …and push released [data] to the … hosting platform for execution. (Raman teaches protocols and associated clinical instructions and technical settings can be pulled from devices, stored in a data store, analyzed, and pushed to devices via the protocol manager, for example [0068]. The imaging protocol manager 310, in conjunction with the cloud agent 350, facilitates a protocol management workflow …The imaging protocol manager 310 and the cloud agent 350 execute a protocol management workflow (see, e.g., FIG. 9) including the following processes: …(2) pulling protocols and, in some examples, clinical instructions, from imaging devices to the protocol manager (see, e.g., FIG. 14); (3) analyzing protocol deviations (see, e.g., FIG. 16); and (4) pushing standard protocols from the protocol manager to applicable…devices (see, e.g., FIG. 21) [0108].)
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to have modified the system for receiving patient input data and generating an output metric as well as clinical protocols as disclosed by Chari to incorporate a module for pushing protocols as taught by Raman. This modification would create a system capable of managing data in a consistent manner therefore ensuring patient safety and optimal outcome (see Raman, ¶ 0007).
Chari and Raman do not teach the following limitations met by Kwang:
…receive release flags…generated by the algorithm monitoring module responsive to a sent request message… (Kwang teaches the control unit 140 has received a request to access the digital content from a user of the plurality of user, requesting authentication on the access of the digital content. Releasing condition determination unit 120 serves to determine whether the release conditions are satisfied. Whether meet the release conditions may be different depending on whether the disconnect condition is any form (p. 3, ¶ 0006). If it is determined that the release conditions are satisfied, the security method comprising the steps of: allowing the access to the at least one user of the plurality of users wherein the digital content, the digital content (p. 10, ¶ 0003).)
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to have modified the system for receiving patient input data and generating an output metric as well as clinical protocols as carrying out protocols through inference algorithms as disclosed by Chari to incorporate receiving a request for access to data and releasing the data if specified conditions are met as taught by Kwang. This modification would create a system capable of ensuring digital content remains secure (see Kwang, p. 1, ¶ 0004).
Regarding Claim 3, Chari, Raman, and Kwang teach the limitations as seen in the rejection of Claim 1 above. Chari does not disclose the following limitations met by Raman:
wherein the system further comprises a protocol hosting platform adapted to host any of the one or more protocols; (Raman teaches in some examples, clinical instructions are also pulled from the imaging devices and stored in the clinical instructions database 226. The web host for protocol application 218 supports, for example, a web-based portal/application for the protocol team(s) to access the… protocol manager 210 from a user device (e.g., user device 130 of FIG. 2) [0080].)
wherein the orchestrator module is adapted to: receive protocol loading packages from the protocol module, and push protocol specifications comprised by received protocol loading packages to the protocol hosting platform. (Raman teaches the present disclosure provides a computer-implemented method for pulling imaging protocol data to an imaging protocol manager [0009]. At operation 1404, a protocol request is received at the cloud agent 350 for the imaging device 232-236. For example, the command and notification API 356 at the cloud agent 350 receives the command from the command & notification module 317 at the imaging protocol manager 310 to initiate the pull service module 362 at the cloud agent 350 to pull one or more…protocols [0132]. An imaging protocol may define a scanning plane for the associated imaging procedure, specify position…etc. [0003]. The Examiner interprets the protocols defining procedures or positions as being the protocol specification and the protocol manager as the protocol module.)
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to have modified the system for receiving patient input data and generating an output metric as well as clinical protocols as disclosed by Chari to incorporate a module for hosting and loading protocols as taught by Raman. This modification would create a system capable of managing protocols on devices in a consistent manner therefore ensuring patient safety and optimal outcome (see Raman, ¶ 0007).
Regarding Claim 4, Chari, Raman, and Kwang teach the limitations as seen in the rejection of Claim 1 above. Raman teaches the orchestrator module as seen in the rejection of Claim 1, but Raman does not teach the orchestrator module being adapted for the following functionality disclosed by Chari:
wherein the orchestrator module is adapted to receive said risk messages or alerts from any one or more of: the algorithm hosting platform, the protocol hosting platform, the protocol module, and a user interface. (Chari discloses the evidence for the determination of high risk (e.g., patient data showing the patient is diabetic, is male and has an albumin/creatinine ratio greater than 2.0) may be provided with the recommendation that the patient is at high risk [0316]. The Examiner interprets the patient data being data input by a user via the interface.)
Regarding Claim 5, Chari, Raman, and Kwang teach the limitations as seen in the rejection of Claim 1 above. Chari further discloses:
wherein each inference algorithm is …responsive to the metric or score generated by the algorithm passing a risk threshold. (Chari discloses applying a CPGD may include calculating a criteria (e.g., calculating a patient value according to a definition in the CPGD, the value to be representative of the patient's medical condition and to be compared to a threshold value defined in the CPGD) for determining the medical condition of the patient according to the rules of the CPGD. This criteria may then be used to determine a medical recommendation for the patient according to the rules of the CPGD [0190].)
…adapted to generate a risk alert… (Chari discloses the system may automatically generate notifications requesting input of new or updated data. These notifications may be provided via appropriate output interfaces to the appropriate user. Such automatic notifications may be generated based on general CPGs that are universal for all patients, for example based on gender and/or age. These notifications may be generated once a patient reaches a certain age threshold and at a set frequency [0331-332]. The Examiner interprets this alert as a risk related alert because a patient's risk of health issues increases with age.)
Regarding Claim 14, Chari, Raman, and Kwang teach the limitations as seen in the rejection of Claim 1 above. The orchestrator module of Raman does not teach the following limitations disclosed by Chari:
wherein the …module is further adapted to: receive a prescription medication recommendation from a running protocol; (Chari discloses the disclosure may allow for two or more CPGDs to be implemented in synchrony. The patient database(s) may be unified or there may be a single patient database used by all the CPGDs implemented by the guideline module. Data may be simultaneously inputted and/or applied to multiple CPGDs and the resultant generated recommendations from all CPGDs relevant to the data may be provided to the physician [0452]. FIG. 19 shows an example table of medication that may be provided as a recommendation, in an example of the present disclosure;…[0073].)
fill one or more fields of a medication request form based on the request; (Chari discloses Fin FIG. 58, the physician has entered "1 month" as the prescription duration. Frequency of SMBG by the patient may be required. "Fasting am" and "AC supper" may be highlighted as recommendations. The operations shown in FIG. 58 may be based on Reference 1 [0431]. In FIG. 62, the selected prescription along with patient instructions may be presented to the physician. The physician may proceed to print the prescription along with the patient information by selecting "Prescribe" [0435, see Fig 58, 62].)
generate an alert on a user interface to alert a user to the medication recommendation; (Chari discloses FIG. 42 may be arrived at from FIG. 41. In FIG. 42, the physician has selected "Lantus" as the brand of insulin. A recommendation may be generated and presented made for the dosing of Lantus [0415, see Fig. 41-42, 64].)
receive a user input from the user interface indicative of acceptance or rejection of the medication recommendation, and responsive to acceptance, forwarding the form to a prescription request platform. (Chari discloses the physician may be able to reject this recommendation by selecting a "Reject" option which, upon selection, results in the algorithm returning to the Main Screen…This would be achieved by the physician selecting the "Add Medication" option which may take the physician to a display listing the available tools for selection of medication. In this manner, the physician may be able to follow a clinical path which may be different from the course of action in the generated recommendation, but still use the system as an aid to the management of the patient [0202]. A recommendation to add bolus insulin to the basal dose may be generated and presented to the physician. The physician may accept this recommendation by selecting "Next". The operations shown in FIG. 64 may be based on Reference 3. FIG. 65 may be arrived at from FIG. 64. In FIG. 65, the physician has selected "Next". A choice may be offered to the physician to add bolus insulin to one meal or all three meals. The operations shown in FIG. 65 may be based on References 2 and 3 [0437-438].)
Claims 6-10 and 12 are rejected under 35 USC 103 as being unpatentable over Chari et al. (US 20140058742 A1) in view of Raman et al. (US 20180140271 A1) and Kwang et al. (KR 20160053651 A) as seen in the rejection Claim 1, further in view of Manasco et al. (US 20200168304 A1).
Regarding Claim 6, Chari, Raman, and Kwang teach the limitations as seen in the rejection of Claim 1 above. Chari further discloses:
any further clinical risk associated with any one or more steps of the protocol; (Chari discloses an increase in age may cause a patient to move into the high risk category for a particular CPGD and may result in a new set of management recommendations being generated [0107].)
…protocol datastore… (Chari discloses the rules contained in the various CPGDs may be stored in a database of the system [0086]. In some examples, the at least one medical guideline may include at least one medical guideline for a medical condition selected from: Allergy, Alzheimer's disease, Atrial fibrillation, Cancer of various etiologies, Chronic, kidney disease,…[0017].)
Chari does not disclose the following limitations met by Raman:
wherein, responsive to receipt of a request message,… (Raman teaches at operation 1404, a protocol request is received at the cloud agent 350 for the imaging device 232-236. For example, the command and notification API 356 at the cloud agent 350 receives the command from the command & notification module 317 at the imaging protocol manager 310 to initiate the pull service module 362 at the cloud agent 350 to pull one or more…protocols [0132, see also Fig. 14].)
…the protocol module…(Raman teaches the present disclosure provides a computer-implemented method for pulling imaging protocol data to an imaging protocol manager [0009]…the command and notification API 356 at the cloud agent 350 receives the command from the command & notification module 317 at the imaging protocol manager 310 to initiate the pull service module 362 at the cloud agent 350 to pull one or more…protocols [0132]. The Examiner interprets the protocol manager as the protocol module.)
and wherein the protocol loading package… (Raman teaches the present disclosure provides a computer-implemented method for pulling imaging protocol data to an imaging protocol manager [0009]. At operation 1404, a protocol request is received at the cloud agent 350 …For example, the command and notification API 356 at the cloud agent 350 receives the command from the command & notification module 317 at the imaging protocol manager 310 to initiate the pull service module 362 at the cloud agent 350 to pull one or more…protocols [0132].)
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to have modified the system for receiving patient input data and generating an output metric as well as clinical protocols as disclosed by Chari to incorporate receiving requests and a module for loading protocols as taught by Raman. This modification would create a system capable of managing protocols on devices in a consistent manner therefore ensuring patient safety and optimal outcome (see Raman, ¶ 0007).
Chari, Raman, and Kwang do not teach the following functions of the protocol datastore and the protocol module which is met by Manasco:
wherein the .. datastore further stores, for each protocol, metadata indicating: any further clinical risk… (Manasco teaches Risk Assessment including risk identification, categorization, prioritization, mapping of oversight plans to risks, whether the risk occurred, and the metadata associated with the Risk Assessment [0043].)
… the… module is further adapted to read the metadata for the specified protocol to identify any further clinical risk associated with any one or more steps of the protocol; (Manasco teaches FIG. 2 illustrates an exemplary method 200 for identifying errors in clinical trial data and for directing workflow in a clinical trial process based on a specific clinical trial protocol and risk assessment performed by a clinical trial monitoring entity 102 according to the present disclosure. For instance, method 200 may include, at block 202, obtaining clinical trial data (e.g., clinical trial data 103) from one or more remote entities (e.g., remote entities 101) [0060]. Additionally…, clinical trial data 103 includes metadata associated with collection of data and queries [0026].)
and wherein the protocol loading package further includes the retrieved further clinical risk information associated with the relevant protocol. (Manasco teaches a clinical trial protocol typically establishes, for instance, how the clinical trial will be conducted, ethical considerations and potential risks,…[0002]. Risk Assessment including risk identification, categorization, prioritization, mapping of oversight plans to risks, whether the risk occurred, and the metadata associated with the Risk Assessment [0043].)
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to have modified the system for receiving patient input data and generating an output metric as well as clinical protocols as disclosed by Chari to incorporate the use of metadata associated with risks and patients as taught by Manasco. This modification would create a system capable of ensuring protocols are carried out properly by minimizing errors (see Manasco, ¶ 0002).
Regarding Claim 7, Chari, Raman, and Kwang teach the limitations as seen in the rejection of Claim 1 above. Chari further discloses:
access a patient data source to obtain the required patient personalization data, (Chari discloses the processor may be configured to receive the set of data from a patient database of the same or another system [0023].)
…protocol datastore…(Chari discloses the rules contained in the various CPGDs may be stored in a database of the system [0086]. In some examples, the at least one medical guideline may include at least one medical guideline for a medical condition selected from: Allergy, Alzheimer's disease, Atrial fibrillation, Cancer of various etiologies, Chronic, kidney disease,…[0017].)
Chari does not disclose the following limitations met by Raman:
wherein the … datastore further stores, for each protocol, [data] indicating: required patient personalization data for configuring the protocol; (Raman teaches an imaging device maintains a protocol database which stores various imaging procedures and/or protocols for the device to use according to one or more scenarios, reasons for examination, etc. The scenarios for examination may include patient size, anatomy type (e.g., heart, lung, kidney, brain, etc.), position, task, etc. [0004].)
wherein, responsive to receipt of a request message, the protocol module is further adapted to: read the metadata for the specified protocol to identify the required patient personalization data, and configure the protocol in the protocol loading package with the patient data (Raman teaches the commands may include, for example, listing available protocol(s) (e.g., of a certain type, for a certain device, etc.), searching for a particular protocol/protocol type, tagging protocol(s) (e.g., with a device type, hospital association, patient type association, condition association, etc.), publishing protocol(s)…, pushing protocols, and so on [0090]. The user can search protocols in the device protocols database 322 and/or the standard protocols database 324 by name, body part, anatomy, age (e.g., pediatric versus adult), patient size, etc. The user can compare two or more protocols including, for example, versions of device protocols, versions of library protocols, first device protocol versus second device protocol, device protocol versus standard library protocol, library standard protocol versus library standard protocol, etc. [0164].)
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to have modified the system for receiving patient input data and generating an output metric as well as clinical protocols as disclosed by Chari to incorporate receiving requests and a module for loading protocols for specific patients as taught by Raman. This modification would create a system capable of managing protocols on devices in a consistent manner therefore ensuring patient safety and optimal outcome (see Raman, ¶ 0007).
Chari and Raman do not teach the data being metadata which is met by Manasco:
…read the metadata…(Manasco teaches clinical trial data 103 includes metadata associated with collection of data and queries [0026].)
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to have modified the system for receiving patient input data and generating an output metric as well as clinical protocols as disclosed by Chari to incorporate the use of metadata associated with risks and patients as taught by Manasco. This modification would create a system capable of ensuring protocols are carried out properly by minimizing errors (see Manasco, ¶ 0002).
Regarding Claim 8, Chari, Raman, and Kwang teach the limitations as seen in the rejection of Claim 1 above. Chari further discloses:
…if the required clinical parameter data is not available, execute a data collection sub-routine for obtaining the required clinical parameter data. (Chari discloses Input Screen with data fields for all CPGDs will appear for population by the physician. Selection of this option may result in presentation of an input interface including data fields for all CPGDs available in the system. Upon receipt of patient data in the data fields, the guideline module may make calculations and recommendations based on all CPGDs. Where appropriate, the input interface may prompt the user for more data. Where there is insufficient data for some of the CPGDs, a notification may be generated informing the user that those CPGDs could not be implemented and recommendations for those CPGDs may not be outputted [0234]. One or more internal and/or external patient databases may also be queried in order to obtain the required patient data [0191].)
to identify the required clinical parameter data, determine whether the required clinical parameter data…is currently available (Chari discloses required data may be relatively detailed and may require regular updates. Such data may include, for example: physical exam results, lab values, past medical history, current and/or past medical states, current and/or past medications, family history and allergies, among others [0011]. Where appropriate, the input interface may prompt the user for more data. Where there is insufficient data for some of the CPGDs, a notification may be generated informing the user that those CPGDs could not be implemented and recommendations for those CPGDs may not be outputted [0234].)
read the [data] for the specified protocol…for the specified protocol… (Chari discloses the system may provide different input GUIs for receiving data specific to different CPGDs. This may be the case for receiving input from the physician. For example, at a general or home GUI (e.g., a GUI showing a main screen or home screen), the physician may choose a particular CPGD or CPGDs that are relevant to the diagnosed conditions on that patient, or all CPGDs [0221].)
… protocol datastore…(Chari discloses the rules contained in the various CPGDs may be stored in a database of the system [0086]. In some examples, the at least one medical guideline may include at least one medical guideline for a medical condition selected from: Allergy, Alzheimer's disease, Atrial fibrillation, Cancer of various etiologies, Chronic, kidney disease,…[0017].)
Chari does not disclose the following limitations met by Raman:
wherein, responsive to receipt of a request message, (Raman teaches at operation 1404, a protocol request is received at the cloud agent 350 for the imaging device 232-236. For example, the command and notification API 356 at the cloud agent 350 receives the command from the command & notification module 317 at the imaging protocol manager 310 to initiate the pull service module 362 at the cloud agent 350 to pull one or more…protocols [0132, see also Fig. 14].)
the protocol module is further adapted to: (Raman teaches imaging protocol manager apparatus includes an orchestrator, a baseliner, and a protocol application. The example orchestrator is to trigger a pull of a first imaging protocol from a first imaging device to the imaging protocol manager apparatus [0008].)
wherein the…datastore further stores, for each protocol, [data] indicating: required patient clinical parameter data for running the protocol; (Raman teaches referring to FIG. 20, a comparison of metadata for device protocols and metadata for standard protocols is shown, in accordance with an exemplary embodiment. As shown in FIG. 20, in some embodiments, the metadata associated with a protocol pulled from an imaging device and stored in the device protocols database 322 includes the model ID (i.e., UID), protocol ID in the device, protocol version in the device, device ID, library associated with the protocol, anatomy, humanoid, folder structure in the device, global system (GS) protocol ID, GS protocol version,… [0173].)
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to have modified the system for receiving patient input data and generating an output metric as well as clinical protocols as disclosed by Chari to incorporate receiving requests and a module for loading protocols for specific patients as taught by Raman. This modification would create a system capable of managing protocols on devices in a consistent manner therefore ensuring patient safety and optimal outcome (see Raman, ¶ 0007).
Chari, Raman, and Kwang do not teach the data being metadata which is met by Manasco:
…read the metadata…(Manasco teaches clinical trial data 103 includes metadata associated with collection of data and queries [0026].)
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to have modified the system for receiving patient input data and generating an output metric as well as clinical protocols as disclosed by Chari to incorporate the use of metadata associated with risks and patients as taught by Manasco. This modification would create a system capable of ensuring protocols are carried out properly by minimizing errors (see Manasco, ¶ 0002).
Regarding Claim 9, Chari, Raman, and Kwang teach the limitations as seen in the rejection of Claim 1 above. Chari further discloses:
wherein the algorithm datastore further stores, for each inference algorithm, [data] indicating required input data for running the algorithm; (Chari discloses an example algorithm for implementing the directions of the CPG aforementioned document. As shown, the algorithm may include querying whether the patient has diabetes. If the answer is yes, a series of queries may be further posed with the result that a positive answer to any of these queries may place the patient at high risk, with recommendations generated based on this risk stratification [0133].)
and wherein,… relating to a specified algorithm, the algorithm monitor module is further adapted to: read the [data] for the relevant specified algorithm in the algorithm datastore, (Chari discloses the guideline module may include a CPGD database. The CPGD database may store available (e.g., both old and new versions) CPGDs and may provide CPGDs to the CPGD scheduler and CPGD monitor components (e.g., in response to a query). The CPGD database may further interact with the patient manager and the contraindication module [0147]. The algorithm for making such calculations may reside in the guideline module and/or the communication interface of the disclosed system [0210]. The Examiner interprets the algorithms as being stored in the guideline module. If data for one CPGD is entered by the physician, the disclosed methods and systems may enable checking of all other CPGDs as to whether the inputted data is relevant for any other CPGD and, if so, implement the other relevant CPGDs and generate recommendations from the other relevant CPGDs based on the inputted data [0095].)
determine whether the required input data for the specified algorithm is currently available, (Chari discloses the input interface may prompt the user for more data. Where there is insufficient data for some of the CPGDs, a notification may be generated informing the user that those CPGDs could not be implemented and recommendations for those CPGDs may not be outputted [0234]. If it is determined (at 1510) that there is insufficient data to calculate the FRS, the user may be notified of the missing data and, at 1535, provided with an input interface to input the missing data [0270]. The calculation is interpreted as the execution of an algorithm.)
Chari does not disclose the following limitations met by Raman:
… responsive to receipt of a request message… (Raman teaches at operation 1404, a protocol request is received at the cloud agent 350 for the imaging device 232-236. For example, the command and notification API 356 at the cloud agent 350 receives the command from the command & notification module 317 at the…protocol manager 310 to initiate the pull service module 362 at the cloud agent 350 to pull one or more…protocols [0132, see also Fig. 14].)
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to have modified the system for receiving patient input data and generating an output metric as well as clinical protocols as disclosed by Chari to incorporate receiving requests as taught by Raman. This modification would create a system capable of managing protocols in a consistent manner therefore ensuring patient safety and optimal outcome (see Raman, ¶ 0007).
Chari and Raman do not teach the following limitation met by Kwang:
and generate the release flag for the algorithm only if the …data requirements are met. (Kwang teaches releasing condition determination unit 120 serves to determine whether the release conditions are satisfied. Whether meet the release conditions may be different depending on whether the disconnect condition is any form (p. 3, ¶ 0006).)
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to have modified the system for receiving patient input data and generating an output metric as well as clinical protocols as carrying out protocols through inference algorithms as disclosed by Chari to incorporate releasing data if specified conditions are met as taught by Kwang. This modification would create a system capable of ensuring digital content remains secure (see Kwang, p. 1, ¶ 0004).
Chari, Raman, and Kwang do not teach the following limitation met by Manasco:
metadata indicating required input… (Manasco teaches clinical trial data 103 includes metadata associated with collection of data and queries [0026].)
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to have modified the system for receiving patient input data and generating an output metric as well as clinical protocols as disclosed by Chari to incorporate the use of metadata associated with risks and patients as taught by Manasco. This modification would create a system capable of ensuring protocols are carried out properly by minimizing errors (see Manasco, ¶ 0002).
Regarding Claim 10, Chari, Raman, Kwang, and Manasco teach the limitations as seen in the rejection of Claim 9 above. Chari further discloses:
if the input data requirements are not met, the algorithm monitor module is further adapted to execute a data collection sub-routine for acquiring supplementary data to supplement the currently available patient data, (Chari discloses an Input Screen with data fields for all CPGDs will appear for population by the physician. Selection of this option may result in presentation of an input interface including data fields for all CPGDs available in the system. Upon receipt of patient data in the data fields, the guideline module may make calculations and recommendations based on all CPGDs. Where appropriate, the input interface may prompt the user for more data. Where there is insufficient data for some of the CPGDs, a notification may be generated informing the user that those CPGDs could not be implemented and recommendations for those CPGDs may not be outputted [0234]. One or more internal and/or external patient databases may also be queried in order to obtain the required patient data [0191].)
and optionally wherein: the data collection sub-routine includes: sending to the orchestrator module a data collection request message including an indication of recommended supplementary data to be acquired to supplement the currently available patient data; and the orchestrator module is adapted to communicate with a data collection sub-system to request acquisition of the supplementary data. (Examiner notes that "optionally" is not positively recited, and therefore, no art is applied.)
Regarding Claim 12, Chari, Raman, and Kwang teach the limitations as seen in the rejection of Claim 9 above. Chari further discloses:
wherein the algorithm monitor module is adapted to execute background operations whether the required clinical parameter data for running each protocol is currently available (Chari discloses upon receipt of patient data in the data fields, the guideline module may make calculations and recommendations based on all CPGDs. Where appropriate, the input interface may prompt the user for more data. Where there is insufficient data for some of the CPGDs, a notification may be generated informing the user that those CPGDs could not be implemented and recommendations for those CPGDs may not be outputted [0234]. The input interface may include prompts requesting input of any further required data [0094].)
and, if the required input data during running of the system comprising, for at least a subset of the inference algorithms in the algorithm datastore, monitoring whether the required input data for each algorithm is currently available and, if the required input data is not available, executing a data collection sub-routine for acquiring supplementary data to supplement the currently available data; and/or wherein the protocol module is adapted to execute background operations during running of the system comprising, for at least a subset of the protocols in the protocol datastore, monitoring is not available, executing a data collection sub-routine for obtaining the required clinical parameter data. (Chari discloses an Input Screen with data fields for all CPGDs will appear for population by the physician. Selection of this option may result in presentation of an input interface including data fields for all CPGDs available in the system. Upon receipt of patient data in the data fields, the guideline module may make calculations and recommendations based on all CPGDs. Where appropriate, the input interface may prompt the user for more data. Where there is insufficient data for some of the CPGDs, a notification may be generated informing the user that those CPGDs could not be implemented and recommendations for those CPGDs may not be outputted [0234]. One or more internal and/or external patient databases may also be queried in order to obtain the required patient data [0191].)
Claim 11 is rejected under 35 USC 103 as being unpatentable over Chari et al. (US 20140058742 A1) in view of Raman et al. (US 20180140271 A1), Kwang et al. (KR 20160053651 A) and Manasco et al. (US 20200168304 A1) in view of Singh et al. (US 20230153320 A1).
Regarding Claim 11, Chari, Raman, Kwang, and Manasco teach the limitations as seen in the rejection of Claim 10 above. Chari further discloses:
wherein the data collection sub-routine includes: (Chari discloses employ a CPGD by selecting the CPGD and entering the appropriate input data into an input screen or input interface. The input interface may include prompts requesting input of any further required data [0094]. Example interactions include:… automatically triggered employment of CPGDs; automatically triggered call-up of tools…[0225].)
wherein the recommended protocol includes steps for acquiring at least a subset of the required input information for the specified algorithm which is currently not available. (Chari discloses an Input Screen with data fields for all CPGDs will appear for population by the physician. Selection of this option may result in presentation of an input interface including data fields for all CPGDs available in the system. Upon receipt of patient data in the data fields, the guideline module may make calculations and recommendations based on all CPGDs. Where appropriate, the input interface may prompt the user for more data. Where there is insufficient data for some of the CPGDs, a notification may be generated informing the user that those CPGDs could not be implemented and recommendations for those CPGDs may not be outputted [0234]. One or more internal and/or external patient databases may also be queried in order to obtain the required patient data [0191].)
sending a …recommendation message to the orchestrator module, (Raman teaches a response queue is used to receive messages from the equipment 232-236 back to the command and notification API 356 of the imaging protocol manager 310. Such messages can indicate completion and/or failure of execution of a command by the equipment 232-236 to pull protocol information from the protocol database 368, etc. [0157]. The Examiner interprets this as a module capable of receiving messages and taking action in response to the message.)
Chari, Raman, Kwang, and Manasco do not teach recommending execution of a protocol which is met by Singh:
…recommending execution of a protocol… (Singh teaches the protocoling recommendation system 104 may recommend scan protocols to be executed by the at least one of the scanners 108. The at least one of the scanners 108 may then receive the recommended scan protocols as executables from the server 102, whereby a scan session may be initiated [0030]. The protocols may be recommended based on historical selection data (e.g., past protocols executed for various procedures) and/or patient demographic data, each of which may be communicated from the scanners to the server 102/protocoling recommendation system 104 [0042].)
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to have modified the system for receiving patient input data and generating an output metric as well as clinical protocols as disclosed by Chari to incorporate the recommendation of executing a protocol as taught by Singh. This modification would create a system capable of automatically performing the necessary steps thereby improving patient experience and health outcomes (see Singh, ¶ 0039).
Claim 13 is rejected under 35 USC 103 as being unpatentable over Chari et al. (US 20140058742 A1) in view of Raman et al. (US 20180140271 A1) and Kwang et al. (KR 20160053651 A) as seen in the rejection Claim 1, further in view of Lefkofsky et al. (US 20210118559 A1).
Regarding Claim 13, Chari, Raman, and Kwang teach the limitations as seen in the rejection of Claim 1 above. Chari further discloses:
wherein the algorithm datastore further stores, for each inference algorithm,… (Chari discloses to generate recommendations for the medical management of a patient, the system may… employ a single CPG algorithm or multiple CPG algorithms for generating the recommendations [0130]. In the example of FIG. 35D, separate portions of different CPGD algorithms …are combined and executed together…in some examples one or more whole algorithms from one or more CPGDs may be combined and executed together with portions of algorithms from other CPGDs [0101]. The algorithm for making such calculations may reside in the guideline module and/or the communication interface of the disclosed system [0210].)
and wherein, responsive to a request message, the algorithm monitor module is adapted to: read the [data] for the algorithm in the algorithm datastore; (Chari discloses a case in which the patient is at risk for another disease, in this example labeled D2. In this case, a notification may be generated… [0316]. In the example of FIG. 35D, separate portions of different CPGD algorithms …are combined and executed together. Although this example shows only portions of the algorithms being combined, in some examples one or more whole algorithms from one or more CPGDs may be combined and executed together with portions of algorithms from other CPGDs [0101]. The algorithm for making such calculations may reside in the guideline module and/or the communication interface of the disclosed system [0210].)
Chari and Raman do not teach the following limitations met by Kwang:
and generate a release flag for a given algorithm only if the … requirements are met. (Kwang teaches the control unit 140 has received a request to access the digital content from a user of the plurality of user, requesting authentication on the access of the digital content. Releasing condition determination unit 120 serves to determine whether the release conditions are satisfied. Whether meet the release conditions may be different depending on whether the disconnect condition is any form (p. 3, ¶ 0006). If it is determined that the release conditions are satisfied, the security method comprising the steps of: allowing the access to the at least one user of the plurality of users wherein the digital content, the digital content (p. 10, ¶ 0003).)
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to have modified the system for receiving patient input data and generating an output metric as well as clinical protocols as carrying out protocols through inference algorithms as disclosed by Chari to incorporate releasing data if specified conditions are met as taught by Kwang. This modification would create a system capable of ensuring digital content remains secure (see Kwang, p. 1, ¶ 0004).
Chari, Raman, and Kwang do not teach the following limitations met by Lefkofsky:
associated metadata including a patient population type for which the algorithm is configured to be applied; (Lefkofsky teaches profiles may include fields which affect the outcome of testing results, including: the subject's sex, age, race, medical history, general health, diet, and medications. Clinomic profiles may also include metadata about the particular testing or other health care that a subject has received,…[0008].)
determine whether a patient associated with the input patient data matches the patient population type;…if the patient population type requirements are met. (Lefkofsky teaches a Trial module may identify and test hypotheses for treating cancers having specific characteristics by matching features of a subject to clinical trials. These trials have inclusion and exclusion criteria that must be matched to enroll which may be ingested and structured from publications, trial reports, or other documentation [0218]. Clinical data types used to predict the likelihood that a patient will respond favorably to a therapy, have a particular degree of severity of disease, be contagious, and/or be susceptible to future infections may include patient age, gender, race, other patient demographics, health conditions…[03106]. The Examiner interprets determining the population type of the patient for a proper clinical trial as ensuring the requirements are met.)
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to have modified the system for receiving patient input data and generating an output metric as well as clinical protocols as carrying out protocols through inference algorithms as disclosed by Chari to incorporate the use of metadata associated with patient population type and ensuring the patient type is correct for use with the algorithm as taught by Lefkofsky. This modification would create a system capable of providing a personalized medicine approach to improve an individual’s health treatment (see Lefkofsky, ¶ 0007).
Claim 15 is rejected under 35 USC 103 as being unpatentable over Chari et al. (US 20140058742 A1) in view of Raman et al. (US 20180140271 A1) and Kwang et al. (KR 20160053651 A) as seen in the rejection Claim 1, further in view of Housworth et al. (US 20040225337 A1).
Regarding Claim 15, Chari, Raman, and Kwang teach the limitations as seen in the rejection of Claim 1 above. Chari, Raman, and Kwang do not teach the following limitations met by Housworth:
wherein the system further includes a patient monitoring sub-system comprising one or more physiological parameter sensors (Housworth teaches the programmer module is adapted for physical and electrical connection to a clinical instrument including a power supply and a central processing system and may include a user interface, a display and other physiological monitoring or therapy delivery modules [0011]. Modular systems are available having a number of "add-on" features that allow the addition of sensors, such as pulse oximetry sensors, ECG electrodes, respiration sensors, blood pressure sensors, CO.sub.2 sensors, or other physiological sensors. Such sensors are coupled to instrument 20 via an appropriate interface connection that provides analog or digital connection to central processing system 34 to allow display, storage or analysis of data received from sensors [0021].)
and a patient monitoring control module adapted to receive and compile data from the one or more physiological parameter sensors. (Housworth teaches the memory registers or RAM may also be used for storing data compiled from sensed cardiac activity and/or relating to device operating history or sensed physiologic parameters for telemetry out on receipt of a retrieval or interrogation instruction [0021].)
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to have modified the system for receiving patient input data and generating an output metric as well as clinical protocols as disclosed by Chari to incorporate the use of physiological sensors and a patient monitoring module as taught by Housworth. This modification would create a system capable of providing support for understanding the patient condition and selecting the most appropriate treatment (see Housworth, ¶ 0005).
Relevant Prior Art Not Currently Being Applied
The following references are considered pertinent to Applicant’s disclosure but are not currently being applied:
Selvaraj et al. (US 20240321447 A1) teaches a system and method which utilizes data stores and patient specific data, including from sensors, and the system uses algorithms to predict disease.
Rosenfeld et al. (US 20120284053 A1) teaches a system and method which utilizes a datastore comprising patient data and decision support algorithms to provide patient care advice.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to OLIVIA R GEDRA whose telephone number is (571)270-0944. The examiner can normally be reached Monday - Friday 8:00am-5:00pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Peter H Choi can be reached at (469)295-9171. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/OLIVIA R. GEDRA/Examiner, Art Unit 3681
/PETER H CHOI/Supervisory Patent Examiner, Art Unit 3681
Prosecution Insights