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