DETAILED ACTION
Status of Claims
This action is in reply to the amendment filed on 10/10/2025.
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 .
The following Final Office Action includes rejections of newly added claims 21-23, updated to replace Final Office Action issued 01/27/2026 where rejections of newly added claims 21-23 were omitted.
Claims 7, 12-16 and 19-20 have been amended.
Claims 21-23 have been newly added.
Claims 4-6 and 18 have been cancelled.
Claims 1-3, 7-17 and 19-23 are currently pending and have been examined.
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-3, 7-17 and 19-23 are rejected under 35 U.S.C. §101 because the claimed invention is directed to an abstract idea without significantly more.
Step 1:
Claims -3, 7-17 and 19-23 are directed to a system (i.e., a machine) and claim 20 is directed to non-transitory computer readable medium (i.e., a manufacture). Accordingly, claims -3, 7-17 and 19-23 are all within at least one of the four statutory categories.
Step 2A - Prong One:
An “abstract idea” judicial exception is subject matter that falls within at least one of the following groupings: a) mathematical concepts, b) certain methods of organizing human activity, and/or c) mental processes.
Representative independent claim 20 includes limitations that recite an abstract idea. Independent claim 7 is the system claim, while claim 20 covers the matching computer readable medium.
Specifically, independent claim 20 recites:
A non-transitory computer storage medium encoded with instructions that, when executed by one or more computers, cause the one or more computers to perform operations comprising:
receiving, from a user device associated with an account, a request for data;
in response to receiving the request for data, determining, for an account for which a user interface will be presented, to provide a particular data type to which the account has permission to access wherein the account is for a health care employee:
receiving, from two or more data sources and using an identifier for a patient, data that indicates two or more characteristics of the patient, wherein the two or more data sources include lifestyle data, insurance data, and patient data;
accessing data from one or more data sources that includes, for each of a plurality of data types, corresponding data values, the accessing comprising:
generating, using at least some of the data and an action model created from at least portions of the lifestyle data and the patient data from the two or more data sources, a data structure that represents one or more actions to be performed to improve a health of a patient, relative to a health of a patient prior to performance of the one or more actions; and
accessing the data structure a) representing the one or more actions to be performed to improve a health of the patient, relative to a health of the patient prior to performance of the one or more actions b) that was generated using at least some of the data and the action model created from at least portions of the lifestyle data and the patient data from the two or more data sources;
generating, using data values for one or more of a plurality of data types to which the account does not have permission to access, a value for the particular data type, wherein the plurality of data types comprise at least one type of medical data;
selecting, from the plurality of data types and using permissions data for the account, one or more data types that the account has permission to access; and
causing, using the data and the data structure, presentation of the user interface that includes i) one or more of the two or more characteristics, ii) second data indicating the one or more actions to be performed to improve the health of the patient, relative to the health of the patient prior to performance of the one or more actions, and iii) data of the particular data type to which the account has permission to access including the value for the particular data type that was generated using one or more of the plurality of data types to which the account does not have permission to access, the causing comprising providing, to the user device using the data and the data structure and for each of the one or more data types that the account has permission to access, the corresponding data values.
determining, for an account for which the user interface is presented, whether to provide a particular data type to which the account has permission to access; and
in response to determining to provide the particular data type to which the account has permission to access;
determining whether to generate a value for the particular data type; and
in response to determining to generate a value for the particular data type, generating, using data values for one or more of a plurality of data types to which the account does not have permission to access, the value for the particular data type to which the account has permission to access,
wherein causing presentation of the user interface comprises causing presentation of the user interface that includes data of the particular data type to which the account has permission to access including the value for the particular data type that was generated using one or more of the plurality of data types to which the account does not have permission to access.
The Examiner submits that the foregoing underlined limitations constitute: (a) “certain methods of organizing human activity” because requesting and granting permission to access an account, indicating lifestyle, insurance and patient data, creating a data structure with the lifestyle, insurance and patient data and performing actions to improve the health of the patient are a part of a medical workflow, determining types of data a user has access to and providing healthcare services, which relate to managing human behavior/interactions between people. Furthermore, these limitations constitute (b) “a mental process” because indicating characteristics of a patient, determining types of data a user has access to and generating data values are observation/evaluation/analysis that can be performed in the human mind or with a pen and paper. The foregoing underlined limitations also relate to claim 7 (similarly to claim 20).
Accordingly, the claim describes at least one abstract idea.
In relation to claims 1-3, 8-17, 19, 21 and 23, these claims merely recite determining steps such as: claim 1 - accessing data from one or more data sources that includes, for each of a plurality of data types, corresponding data values, selecting, from the plurality of data types and using permissions data for the account, one or more data types that the account has permission to access and providing, to the user device and for each of the one or more data types that the account has permission to access, the corresponding data values, claim 2 - selecting the one or more data types comprises selecting, from the plurality of data types and using a role for the account that indicates the permissions data, the one or more data types that the role has permission to access; and providing the corresponding data values comprises providing, to the user device and for each of the one or more data types that the role has permission to access, the corresponding data values, claim 3- for the particular person b) that includes, for each of the plurality of data types, the corresponding data values; and providing the corresponding data values comprises providing, to the user device and for each of the one or more data types that the account has permission to access, the corresponding data values for the particular person, claim 8 - receiving, from another system, the data structure that represents the one or more actions to be performed to improve a health of the patient, relative to a health of the patient prior to performance of the one or more actions, claim 9 - generating, using at least some of the data and the action model created from at least portions of the lifestyle data and the patient data from the two or more data sources, the data structure that represents the one or more actions to be performed to improve a health of the patient, relative to a health of the patient prior to performance of the one or more actions, claim 10 - sending, to a client device and using the data and the data structure, instructions for presentation of the user interface that includes i) the one or more of the two or more characteristics and ii) the second data indicating the one or more actions to be performed to improve the health of the patient, relative to the health of the patient prior to performance of the one or more actions, claim 11 - presenting, on a display and using the data and the data structure, the user interface that includes i) the one or more of the two or more characteristics and ii) the second data indicating the one or more actions to be performed to improve the health of the patient, relative to the health of the patient prior to performance of the one or more actions, claim 12 - models relationships between the plurality of variables to select the set of predictor parameters and refining the machine learning algorithm using a measure of error associated with a score of the attribution output, claim 11 - generate a set of predictor-parameters for the machine learning algorithm, claim 12 - ranking, using the risk scores, the two or more patients ;selecting, using a threshold value and the ranking of the two or more patients, a plurality of highest risk patients from the two or more patients that have higher likelihoods of hospital encounters than the other patients from the two or more patients; causing presentation of a second user interface that includes, for each of one or more of the plurality of highest risk patients that includes the patient, at least some of the corresponding characteristics data, wherein the user interface and the second user interface are both interfaces for a single application; and receiving input data indicating selection of a user interface element, included in the second user interface, for the patient, wherein causing, using the data and the data structure, presentation of the user interface that includes i) the one or more of the two or more characteristics and ii) the second data indicating the one or more actions to be performed to improve the health of the patient, relative to the health of the patient prior to performance of the one or more actions is responsive to receiving the input data indicating selection of the user interface element, included in the second user interface, for the patient, claim 13 - causing, for the patient included in the plurality of highest risk patients and using the risk score for the patient, presentation of a recommendation about at least one of the one or more actions at a higher frequency than if the patient was not included in the plurality of highest risk patients, claim 14 - in response to receiving the input data, causing presentation of a third user interface that enables entry of a reason for removal of the second patient from the plurality of highest risk patients or of an option to cancel the removal of the second patient from the plurality of highest risk patients; and selectively maintaining or removing the second patient from the plurality of highest risk patients in response to entry of the reason for removal or the option to cancel the removal, claim 15 - generating using, as input to the risk model trained using at least portions of the lifestyle data and the patient data from the two or more data sources, second characteristics data for the second patient and (ii) represents a likelihood of a hospital encounter during a time period, wherein causing presentation of the second user interface comprises causing presentation of the second user interface with (a) a first region that includes the second risk score, at least some of the second characteristics data for the second patient, and a recommendation to add the second patient to the plurality of highest risk patients, and (b) a second region that includes, for each of the one or more of the plurality of highest risk patients, at least some of the corresponding characteristics data, claim 16 - causing presentation of the second user interface with the first region that includes the recommendation to add the second patient to the plurality of highest risk patients, input data that indicates user selection to add the second patient to the plurality of highest risk patients; and in response to receiving the input data that indicates user selection to add the second patient to the plurality of highest risk patients, causing presentation of an updated second user interface that includes, for each of the one or more of the plurality of highest risk patients including the second patient, at least some of the corresponding characteristics data , claim 17 - causing presentation of the user interface comprises causing, using the data and the data structure, presentation of the user interface that includes i) one or more of the two or more characteristics and ii) second data indicating best practice alerts that indicate the one or more actions to be performed to improve the health of the patient, relative to the health of the patient prior to performance of the one or more actions, claim 19 - causing presentation of the user interface i) on the first user device ii) that includes the one or more first characteristics and the second data indicating the first action, the operations comprising: retrieving, from the data structure and using a second, different role associated with a second user device one or more second characteristics of the patient and third data indicating a second, different action to be performed to improve the health of the patient, relative to a heath of the patient prior to performance of the second, different action and causing presentation of a second user interface i) on the second user device ii) that includes the one or more second characteristics of the patient and the third data indicating the second, different action, claim 21 - computing, for two or more user interface elements from the user interface, a recommended order in which to interact with the two or more user interface elements, wherein: causing presentation of the user interface comprises causing presentation of the user interface that includes, for at least some of the two or more user interface elements, a visual identifier that indicates the recommended order in which the user interface elements should be interacted and claim 23 - computing the recommended order uses a predicted impact on the health of a patient.
In relation to claim 22, this claim merely recites a type of output data such as: claim 22 - the visual identifier comprises a score, a color, a font, or another visual cue.
Step 2A - Prong Two:
Regarding Prong Two of Step 2A, it must be determined whether the claim as a whole integrates the abstract idea into a practical application. As noted, it must be determined whether any additional elements in the claim beyond the abstract idea integrate the exception into a practical application in a manner that imposes a meaningful limit on the judicial exception. The courts have indicated that additional elements merely using a computer to implement an abstract idea, adding insignificant extra solution activity, or generally linking use of a judicial exception to a particular technological environment or field of use do not integrate a judicial exception into a “practical application.”
The limitations of claims 7 and 20, as drafted is a process that, under its broadest reasonable interpretation, covers performance of the limitations in the mind but for the recitation of generic computer components. That is, other than reciting a system, a user device, a user interface, a display, and a tangible, non-transitory, computer-readable media having instructions to perform the limitations, nothing in the claim elements precludes the steps from practically being performed in the mind. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation within a health care environment in the mind but for the recitation of generic computer components, then it falls within the “certain methods of organizing human activity” and “Mental Process” grouping of abstract ideas. Accordingly, the claims recite an abstract idea.
The judicial exception is not integrated into a practical application. In particular, the system, user device, user interface, display and tangible, non-transitory, computer-readable media having instructions that, when executed by one or more computers are recited at high levels of generality (i.e., as generic computer components performing generic computer functions of receiving data/inputs, determining and providing data) such that it amounts no more than mere instructions to apply the exception using the generic computer components.
Regarding the additional limitations “generated using at least some of the data and an action model created from at least portions of the lifestyle data and the patient data” the Examiner submits that this additional limitation amount to merely using a computer to perform the at least one abstract idea (see MPEP § 2106.05(f)). Regarding the additional limitation “receiving,….. a request for data” and “receiving, from two or more data sources and using an identifier for a patient….” the Examiner submits that this additional limitation merely adds insignificant pre-solution activity (data gathering; selecting data to be manipulated) to the at least one abstract idea (see MPEP § 2106.05(g)).
Thus, taken alone, the additional elements do not amount to significantly more than the above identified judicial exception (the abstract idea). Looking at the limitations as an ordered combination add nothing that is not already present when looking at the elements taken individually. For instance, there is no indication that the additional elements, when considered as a whole, reflect an improvements in the functioning of a computer or an improvement to another technology or technical field, apply or us the above-noted implement/use to above-noted judicial exception with a particular machine or manufacture that is integral to the claim, effect a transformation or reduction of a particular article to a different state or thing, or apply or use the judicial exception in some meaningful way beyond generally linking the use of the judicial exception to a particular technological environment, such that the claim as a whole is not more than a drafting effort designed to monopolize the exception (see MPEP §2106.05). Their collective functions merely provide conventional computer implementation.
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 practical application, the additional elements amount to no more than mere instructions to apply the exception using generic computer components. Mere instructions to apply an exception using generic computer component provide an inventive concept. The claims are not patent eligible.
Step 2B:
Regarding Step 2B, in representative independent claim 20, regarding the additional limitations of the system, user device, user interface, display and tangible, non-transitory, computer-readable media having instructions, the Examiner submits that these limitations amount to merely using a computer to perform the at least one abstract idea (see MPEP § 2106.05(f)).
Thus, representative independent claim 20 and analogous independent claim 7 do not include additional elements (considered both individually and as an ordered combination) that are sufficient to amount to significantly more than the judicial exception for the same reasons to those discussed above with respect to determining that the claim does not integrate the abstract idea into a practical application.
The dependent claims no not include additional elements (considered both individually and as an ordered combination) that are sufficient to amount to significantly more than the judicial exception for the same reason discussed above with respect to determining that the dependent claims do not integrate the at least abstract idea into a practical application.
Therefore, claims -3, 7-17 and 19-23 are ineligible under 35 USC §101.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1-3, 7-11 and 19-20 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Gnanasambandam (US 2023/0360779 A1).
Claim 7:
Gnanasambandam discloses A system comprising one or more computers and one or more storage devices on which are stored instructions that are operable, when executed by the one or more computers, to cause the one or more computers to perform operations (See computing device in Fig. 14, P0071, P0222, non-transitory computer-readable medium storing instructions mentioned in P0006, P0054 and P0269.) comprising:
receiving, from two or more data sources and using an identifier for a patient, data that indicates two or more characteristics of the patient, wherein the two or more data sources include lifestyle data, insurance data, and patient data (See [P0166-P0168] Other sources can include a service that supplies identifying information of the user, where the information can include demographics or other characteristics of the user (e.g., a medical condition, a lifestyle). Also, see Fig. 8C P0200 listed characteristics or conditions questions answered by the user. Besides accessing content stored on blockchain ledger in P0082, P0089, see personal information such as name, insurance provider number, type of insurance, address and medical records in P0052 and recommended consultation in P0059, P0074.);
accessing a data structure a) representing one or more actions to be performed to improve a health of a patient, relative to a health of the patient prior to performance of the one or more actions b) that was generated using at least some of the data and an action model created from at least portions of the lifestyle data and the patient data from the two or more data sources (Taught as logical structure in P0072-P0074 where knowing attributes, concepts, conclusions, risks, correlations, complications of the medical conditions and knowing when prescribed medication, different medication and changed dosage of medication should take place serve as actions to be performed to improve the health of the patient. Also, see [P0074] The summary may identify gaps in the unstructured data, such as treatment gaps (e.g., should prescribe medication, should provide different medication, should change dosage of medication, etc.), risk gaps (e.g., the patient is at risk for cancer based on familial history and certain lifestyle behaviors), quality of care gaps (e.g., need to check-in with the patient more frequently).);
causing, using the data and the data structure, presentation of a user interface that includes i) one or more of the two or more characteristics and ii) second data indicating the one or more actions to be performed to improve the health of the patient, relative to the health of the patient prior to performance of the one or more actions (Besides recommended consultation in P0059, P0074, analyzing conversation context used for recommending items in conversation streams in P0149, see the logical structure in P0072-P0074 where knowing attributes, concepts, conclusions, risks, correlations, complications of the medical conditions and knowing when prescribed medication, different medication and changed dosage of medication should take place serve as actions to be performed to improve the health of the patient.);
determining, for an account for which the user interface is presented, whether to provide a particular data type to which the account has permission to access (See blockchain permission access in P0050, P0063-P0064 and P0055-P0057 where access rights depend on smart contract and type of content.); and
in response to determining to provide the particular data type to which the account has permission to access (See authenticating credentials in Fig. 23, P0300-P0304, encrypting and anonymizing personal data when a medical professional accesses patient care plan in P0374-P0376. Also, see other forms of permission access in P0050, P0380 and [P0408] the smart contract to cause the smart contract to output a value indicating whether the other user has permission to view the care plan.):
determining whether to generate a value for the particular data type (See P0089-P0090 exemplary physician requesting access to view a care plan via blockchain node transaction. Also, see requesting in Abstract, Fig. 26 and P0325-P0327.); and
in response to determining to generate a value for the particular data type, generating, using data values for one or more of a plurality of data types to which the account does not have permission to access, the value for the particular data type to which the account has permission to access (Besides accessing content stored on blockchain ledger in P0082, P0089, see personal information such as name, insurance provider number, type of insurance, address and medical records in P0052 and recommended consultation in P0059, P0074.);
wherein causing presentation of the user interface comprises causing presentation of the user interface that includes data of the particular data type to which the account has permission to access including the value for the particular data type that was generated using one or more of the plurality of data types to which the account does not have permission to access (See P0167-P0168 where the cognitive intelligence platform 102 determines if the user asking the originating question, is identified for account access. Also, see approval to deduct cryptocurrency from an account of the other user in P0408.).
Regarding claim 1, Gnanasambandam discloses The system of claim 7, wherein the operations further comprise: receiving, from a user device associated with an account, a request for data; accessing data from one or more data sources that includes, for each of a plurality of data types, corresponding data values; selecting, from the plurality of data types and using permissions data for the account, one or more data types that the account has permission to access; and providing, to the user device and for each of the one or more data types that the account has permission to access, the corresponding data values (See P0089-P0090 exemplary physician requesting access to view a care plan via blockchain node transaction. Also, see requesting in Abstract, Fig. 26 and P0325-P0327. See P0082, P0089 the exemplary physician requesting access to view a care plan via blockchain node. See [P0166-P0168] Other sources can include a service that supplies identifying information of the user, where the information can include demographics or other characteristics of the user (e.g., a medical condition, a lifestyle). Also, see Fig. 8C P0200 listed characteristics or conditions questions answered by the user. Besides accessing content stored on blockchain ledger in P0082, P0089, see personal information such as name, insurance provider number, type of insurance, address and medical records in P0052 and recommended consultation in P0059, P0074.).
Regarding claim 2, Gnanasambandam discloses the system of claim 1, wherein: selecting the one or more data types comprises selecting, from the plurality of data types and using a role for the account that indicates the permissions data, the one or more data types that the role has permission to access; and providing the corresponding data values comprises providing, to the user device and for each of the one or more data types that the role has permission to access, the corresponding data values (See P0089-P0090 exemplary physician requesting access to view a care plan via blockchain node transaction. Also, see requesting in Abstract, Fig. 26 and P0325-P0327. See P0082, P0089 the exemplary physician requesting access to view a care plan via blockchain node.).
Regarding claim 3, Gnanasambandam discloses the system of claim 1, wherein: receiving the request for the data comprises receiving, from the user device associated the an account, the request for the data for a particular person; accessing the data comprises retrieving, from each of the one or more data sources, the data a) for the particular person b) that includes, for each of the plurality of data types, the corresponding data values; and providing the corresponding data values comprises providing, to the user device and for each of the one or more data types that the account has permission to access, the corresponding data values for the particular person (See P0055-P0057 where access rights depends on smart contract and type of content.).
Regarding claim 8, Gnanasambandam discloses the system of claim 7, wherein accessing the data structure comprises receiving, from another system, the data structure that represents the one or more actions to be performed to improve a health of the patient, relative to a health of the patient prior to performance of the one or more actions (Taught as logical structure in P0072-P0074 where knowing attributes, concepts, conclusions, risks, correlations, complications of the medical conditions and knowing when prescribed medication, different medication and changed dosage of medication should take place serve as actions to be performed to improve the health of the patient.).
Regarding claim 9, Gnanasambandam discloses the system of claim 7, wherein accessing the data structure comprises generating, using at least some of the data and the action model created from at least portions of the lifestyle data and the patient data from the two or more data sources, the data structure that represents the one or more actions to be performed to improve a health of the patient, relative to a health of the patient prior to performance of the one or more actions (See P0072-P0074 machine learning models trained to generate knowledge graphs and summary of patients at risk for cancer based on familial history and certain lifestyle behaviors. Also, see [P0166-P0168] Other sources can include a service that supplies identifying information of the user, where the information can include demographics or other characteristics of the user (e.g., a medical condition, a lifestyle).).
Regarding claim 10, Gnanasambandam discloses the system of claim 7, wherein causing presentation of the user interface comprises sending, to a client device and using the data and the data structure, instructions for presentation of the user interface that includes i) the one or more of the two or more characteristics and ii) the second data indicating the one or more actions to be performed to improve the health of the patient, relative to the health of the patient prior to performance of the one or more actions (See Fig. 8B Diabetes Management Plan include 870 Managing with Lifestyle mentioned in P0195-P0196.).
Regarding claim 11, Gnanasambandam discloses the system of claim 7, wherein causing presentation of the user interface comprises presenting, on a display and using the data and the data structure, the user interface that includes i) the one or more of the two or more characteristics and ii) the second data indicating the one or more actions to be performed to improve the health of the patient, relative to the health of the patient prior to performance of the one or more actions (Taught as logical structure in P0072-P0074 where knowing attributes, concepts, conclusions, risks, correlations, complications of the medical conditions and knowing when prescribed medication, different medication and changed dosage of medication should take place serve as actions to be performed to improve the health of the patient.).
Regarding claim 19, Gnanasambandam discloses the system of claim 7, wherein causing presentation of the user interface comprises: retrieving, from the data structure and using a first role associated with a first user device, one or more first characteristics of the patient and the second data indicating a first action to be performed to improve the health of the patient, relative to a heath of the patient prior to performance of the first action; and causing presentation of the user interface i) on the first user device ii) that includes the one or more first characteristics and the second data indicating the first action (Taught as logical structure in P0072-P0074 where knowing attributes, concepts, conclusions, risks, correlations, complications of the medical conditions and knowing when prescribed medication, different medication and changed dosage of medication should take place serve as actions to be performed to improve the health of the patient. Also, see [P0074] The summary may identify gaps in the unstructured data, such as treatment gaps (e.g., should prescribe medication, should provide different medication, should change dosage of medication, etc.), risk gaps (e.g., the patient is at risk for cancer based on familial history and certain lifestyle behaviors), quality of care gaps (e.g., need to check-in with the patient more frequently).), the operations comprising: retrieving, from the data structure and using a second, different role associated with a second user device one or more second, different characteristics of the patient and third data indicating a second, different action to be performed to improve the health of the patient, relative to a heath of the patient prior to performance of the second, different action; and causing presentation of a second user interface i) on the second user device ii) that includes the one or more second characteristics of the patient and the third data indicating the second, different action (See P0072-P0074 machine learning models trained to generate knowledge graphs and summary of patients at risk for cancer based on familial history and certain lifestyle behaviors. Also, see [P0166-P0168] Other sources can include a service that supplies identifying information of the user, where the information can include demographics or other characteristics of the user (e.g., a medical condition, a lifestyle).),
wherein the first role is different than the second, different role and the one or more first characteristics of the patient are different than the one or more second, different characteristics because of the different roles (With characteristics as actions to improve the health of the patient, see suggested recommendation, asking questions about a lab, testing and goals in P0176-P0177, P0214 including nutrition, physical activities, educational information and attending local events as other characteristics shown in Fig. 13. Also, see Fig. 2, P0101, P0156 data specific to the various specialties within healthcare such as obstetrics, anesthesiology and dermatology, GUI screen shots in Fig. 8A-C, 9A, 12 where various Health Plans & Assessments 812 include plans for the user’s Diabetes, Cardiovascular health, Asthma and Back Pain mentioned in P0192-P0194.).
Claim 20:
Gnanasambandam discloses A non-transitory computer storage medium encoded with instructions that, when executed by one or more computers, cause the one or more computers to perform operations (See non-transitory computer-readable medium storing instructions mentioned in P0006, P0054 and P0269.) comprising:
receiving, from a user device associated with an account, a request for data (See P0089-P0090 exemplary physician requesting access to view a care plan via blockchain node transaction. Also, see requesting in Abstract, Fig. 26 and P0325-P0327.);
in response to receiving the request for data, determining, for an account for which a user interface will be presented, to provide a particular data type to which the account has permission to access wherein the account is for a health care employee (See P0082, P0089 the exemplary physician requesting access to view a care plan via blockchain node.);
receiving, from two or more data sources and using an identifier for a patient, data that indicates two or more characteristics of the patient, wherein the two or more data sources include lifestyle data, insurance data, and patient data (See [P0166-P0168] Other sources can include a service that supplies identifying information of the user, where the information can include demographics or other characteristics of the user (e.g., a medical condition, a lifestyle). Also, see Fig. 8C P0200 listed characteristics or conditions questions answered by the user.);
accessing data from one or more data sources that includes, for each of a plurality of data types, corresponding data values, the accessing (Besides accessing content stored on blockchain ledger in P0082, P0089, see personal information such as name, insurance provider number, type of insurance, address and medical records in P0052 and recommended consultation in P0059, P0074.) comprising:
generating, using at least some of the data and the action model created from at least portions of the lifestyle data and the patient data from the two or more data sources, the data structure that represents the one or more actions to be performed to improve a health of the patient, relative to a health of the patient prior to performance of the one or more actions (See P0072-P0074 machine learning models trained to generate knowledge graphs and summary of patients at risk for cancer based on familial history and certain lifestyle behaviors. Also, see [P0166-P0168] Other sources can include a service that supplies identifying information of the user, where the information can include demographics or other characteristics of the user (e.g., a medical condition, a lifestyle).); and
accessing the data structure a) representing the one or more actions to be performed to improve a health of the patient, relative to a health of the patient prior to performance of the one or more actions b) that was generated using at least some of the data and the action model created from at least portions of the lifestyle data and the patient data from the two or more data sources (Taught as logical structure in P0072-P0074 where knowing attributes, concepts, conclusions, risks, correlations, complications of the medical conditions and knowing when prescribed medication, different medication and changed dosage of medication should take place serve as actions to be performed to improve the health of the patient. Also, see [P0074] The summary may identify gaps in the unstructured data, such as treatment gaps (e.g., should prescribe medication, should provide different medication, should change dosage of medication, etc.), risk gaps (e.g., the patient is at risk for cancer based on familial history and certain lifestyle behaviors), quality of care gaps (e.g., need to check-in with the patient more frequently).),
generating, using data values for one or more of a plurality of data types to which the account does not have permission to access, a value for the particular data type, wherein the plurality of data types comprise at least one type of medical data (Taught as encrypting and anonymizing personal data when a medical professional accesses patient care plan in P0374-P0376. Also, see P0050, P0380 and [P0408] the smart contract to cause the smart contract to output a value indicating whether the other user has permission to view the care plan.);
selecting, from the plurality of data types and using permissions data for the account, one or more data types that the account has permission to access (Taught as setting public or private hyperledger access in Fig. 27, P0320 and setting pre-defined guidelines of a smart contract in P0379-P0381.);
causing, using the data and the data structure, presentation of the user interface that includes i) one or more of the two or more characteristics, ii) second data indicating the one or more actions to be performed to improve the health of the patient, relative to the health of the patient prior to performance of the one or more actions (Besides recommended consultation in P0059, P0074, analyzing conversation context used for recommending items in conversation streams in P0149, see the logical structure in P0072-P0074 where knowing attributes, concepts, conclusions, risks, correlations, complications of the medical conditions and knowing when prescribed medication, different medication and changed dosage of medication should take place serve as actions to be performed to improve the health of the patient.), and iii) data of the particular data type to which the account has permission to access including the value for the particular data type that was generated using one or more of the plurality of data types to which the account does not have permission to access, the causing comprising providing, to the user device using the data and the data structure and for each of the one or more data types that the account has permission to access, the corresponding data values (See authenticating credentials in Fig. 23, P0300-P0304, encrypting and anonymizing personal data when a medical professional accesses patient care plan in P0374-P0376. Also, see other forms of permission access in P0050, P0380 and [P0408] the smart contract to cause the smart contract to output a value indicating whether the other user has permission to view the care plan.);
determining, for an account for which the user interface is presented, whether to provide a particular data type to which the account has permission to access (See P0055-P0057 where access rights depend on smart contract and type of content.); and
in response to determining to provide the particular data type to which the account has permission to access (See authenticating credentials in Fig. 23, P0300-P0304, encrypting and anonymizing personal data when a medical professional accesses patient care plan in P0374-P0376. Also, see other forms of permission access in P0050, P0380 and [P0408] the smart contract to cause the smart contract to output a value indicating whether the other user has permission to view the care plan.):
determining whether to generate a value for the particular data type (See P0089-P0090 exemplary physician requesting access to view a care plan via blockchain node transaction. Also, see requesting in Abstract, Fig. 26 and P0325-P0327.); and
in response to determining to generate a value for the particular data type, generating, using data values for one or more of a plurality of data types to which the account does not have permission to access, the value for the particular data type to which the account has permission to access (Besides accessing content stored on blockchain ledger in P0082, P0089, see personal information such as name, insurance provider number, type of insurance, address and medical records in P0052 and recommended consultation in P0059, P0074.);
wherein causing presentation of the user interface comprises causing presentation of the user interface that includes data of the particular data type to which the account has permission to access including the value for the particular data type that was generated using one or more of the plurality of data types to which the account does not have permission to access (See P0167-P0168 where the cognitive intelligence platform 102 determines if the user asking the originating question, is identified for account access. Also, see approval to deduct cryptocurrency from an account of the other user in P0408.).
Claim Rejections - 35 USC § 103
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 12-17 are rejected under 35 U.S.C. 103 as being unpatentable over Gnanasambandam (US 2023/0360779 A1) in view of Mossin (US 2019/0034591 A1).
Regarding claim 12, although Gnanasambandam discloses the system of claim 7 mentioned above, Gnanasambandam not explicitly teach receiving risk scores, ranking, selecting for each of two or more patients, using a threshold value and the ranking of the two or more patients, a plurality of highest risk patients from the two or more patients that have higher likelihoods of hospital encounters than the other patients from the two or more patients, causing presentation of a second user interface that includes, for each of one or more of the plurality of highest risk patients that includes the patient, at least some of the corresponding characteristics data, wherein the user interface and the second user interface are both interfaces for a single application. Mossin teaches the operations comprising:
for each of two or more patients including the patient (See Fig. 8A, P0156-P0157 alerting the healthcare provider's attention early on two exemplary patients at risk Mark Smith and Jerry Mashokitar.):
receiving risk scores that (i) were generated using, as input to a risk model trained using at least portions of the lifestyle data and the patient data from the two or more data sources, characteristics data for the respective patient and (ii) represent a likelihood of a hospital encounter during a time period (See [P0156-P0157] For patient “Mark Smith”, the display includes an alert 104 which indicates that the predictive models predict two future clinical events for this particular patient, in this case an unplanned transfer to intensive care unit (ICU) and a delayed discharge from the hospital.);
ranking, using the risk scores, the two or more patients; selecting, using a threshold value and the ranking of the two or more patients, a plurality of highest risk patients from the two or more patients that have higher likelihoods of hospital encounters than the other patients from the two or more patients (See risk scores for two patients shown in Fig. 8A, P0052, P0129-P0132 evidence-based ranking of patients’ problems.);
causing presentation of a second user interface that includes, for each of one or more of the plurality of highest risk patients that includes the patient, at least some of the corresponding characteristics data, wherein the user interface and the second user interface are both interfaces for a single application (See Fig. 8A, [P0156-P0157] For patient “Mark Smith”, the display includes an alert 104 which indicates that the predictive models predict two future clinical events for this particular patient, in this case an unplanned transfer to intensive care unit (ICU) and a delayed discharge from the hospital.); and
receiving input data indicating selection of a user interface element, included in the second user interface, for the patient, wherein causing, using the data and the data structure, presentation of the user interface that includes i) the one or more of the two or more characteristics and ii) the second data indicating the one or more actions to be performed to improve the health of the patient, relative to the health of the patient prior to performance of the one or more actions is responsive to receiving the input data indicating selection of the user interface element, included in the second user interface, for the patient (See P0008-P0009, P0020-P0022 data structure basis. See Fig. 7, Fig. 8A, [P0132] FIG. 7 shows different types of predictions made by the models, including readmission, mortality, unplanned ER/hospital visits, etc. The “AUC” performance metric represents a receiver operating characteristic area under the curve, a standard performance metric in machine learning.).
Therefore, it would have been obvious to one of ordinary skill in the art of predicting medical events before the effective filing date of the claimed invention to modify the system of Gnanasambandam to include receiving risk scores, ranking, selecting for each of two or more patients, using a threshold value and the ranking of the two or more patients, a plurality of highest risk patients from the two or more patients that have higher likelihoods of hospital encounters than the other patients from the two or more patients, causing presentation of a second user interface that includes, for each of one or more of the plurality of highest risk patients that includes the patient, at least some of the corresponding characteristics data, wherein the user interface and the second user interface are both interfaces for a single application as taught by Mossin to provide predictions of future clinical events and highlighting of relevant underlying medical events contributing to these predictions in a timely manner of Mossin’s P0004.
Regarding claim 13, Gnanasambandam and Mossin teach the system of claim 12 mentioned above, and Gnanasambandam further teaches: the operations comprising: causing, for the patient included in the plurality of highest risk patients and using the risk score for the patient, presentation of a recommendation about at least one of the one or more actions at a higher frequency than if the patient was not included in the plurality of highest risk patients (Besides recommended consultation in P0059, P0074, analyzing conversation context used for recommending items in conversation streams in P0149, see the logical structure in P0072-P0074 where knowing attributes, concepts, conclusions, risks, correlations, complications of the medical conditions and knowing when prescribed medication, different medication and changed dosage of medication should take place serve as actions to be performed to improve the health of the patient.).
Regarding claim 14, although Gnanasambandam and Mossin teach the system of claim 12 mentioned above, Gnanasambandam not explicitly teach maintaining or removing highest risk patients. Mossin teaches wherein causing presentation of the second user interface comprises causing presentation of the second user interface that includes, for each of the one or more of the plurality of highest risk patients that includes the patient, (a) at least some of the corresponding characteristics data and (b) a user interface element that initiates removal of a corresponding patient from the plurality of highest risk patients, the operations comprising: receiving input data that indicates selection of one of the user interface elements that initiates removal of a second patient from the plurality of highest risk patients (See [P0156-P0157] For patient “Mark Smith”, the display includes an alert 104 which indicates that the predictive models predict two future clinical events for this particular patient, in this case an unplanned transfer to intensive care unit (ICU) and a delayed discharge from the hospital.); in response to receiving the input data, causing presentation of a third user interface that enables entry of a reason for removal of the second patient from the plurality of highest risk patients or of an option to cancel the removal of the second patient from the plurality of highest risk patients; and selectively maintaining or removing the second patient from the plurality of highest risk patients in response to entry of the reason for removal or the option to cancel the removal (By prioritizing two patients (P0045), ranking patients with problems (P0128-P0129) and discharge, length of stay and transfer allows for patients to be selectively be maintained or removed.).
Therefore, it would have been obvious to one of ordinary skill in the art of predicting medical events before the effective filing date of the claimed invention to modify the system of Gnanasambandam to include maintaining or removing highest risk patients as taught by Mossin to provide predictions of future clinical events and highlighting of relevant underlying medical events contributing to these predictions in a timely manner of Mossin’s P0004.
Regarding claim 15, although Gnanasambandam and Mossin teach the system of claim 12 mentioned above, Gnanasambandam not explicitly teach presenting a user interface with a first region that includes the second risk score, characteristics data for the patient, and a recommendation to add the second patient to the plurality of highest risk patients, and a second region that includes, for each highest risk patients, corresponding characteristics data. Mossin teaches the operations comprising: accessing, for a second patient not included in the plurality of highest risk patients, a second risk score that (i) was generating using, as input to the risk model trained using at least portions of the lifestyle data (See P0177 alcohol withdrawal as lifestyle change.)and the patient data from the two or more data sources, second characteristics data for the second patient and (ii) represents a likelihood of a hospital encounter during a time period (See [P0128] we run the model that identifies diagnosis codes (as explained previously, ICD9 code prediction and primary diagnosis CCS code prediction) over all historical time periods of the patient (say, once per historical encounter, or once for each week in the history)., wherein causing presentation of the second user interface comprises causing presentation of the second user interface with (a) a first region that includes the second risk score, at least some of the second characteristics data for the second patient, and a recommendation to add the second patient to the plurality of highest risk patients, and (b) a second region that includes, for each of the one or more of the plurality of highest risk patients, at least some of the corresponding characteristics data (See P0008-P0009, P0020-P0022 data structure basis. See Fig. 7, Fig. 8A, [P0132] FIG. 7 shows different types of predictions made by the models, including readmission, mortality, unplanned ER/hospital visits, etc. The “AUC” performance metric represents a receiver operating characteristic area under the curve, a standard performance metric in machine learning.).
Therefore, it would have been obvious to one of ordinary skill in the art of predicting medical events before the effective filing date of the claimed invention to modify the system of Gnanasambandam to include presenting a user interface with a first region that includes the second risk score, characteristics data for the patient, and a recommendation to add the second patient to the plurality of highest risk patients, and a second region that includes, for each highest risk patients, corresponding characteristics data as taught by Mossin to provide predictions of future clinical events and highlighting of relevant underlying medical events contributing to these predictions in a timely manner of Mossin’s P0004.
Regarding claim 16, Gnanasambandam discloses the system of claim 15, the operations comprising: receiving, in response to causing presentation of the second user interface with the first region that includes the recommendation to add the second patient to the plurality of highest risk patients (Besides recommended consultation in P0059, P0074, analyzing conversation context used for recommending items in conversation streams in P0149, see the logical structure in P0072-P0074 where knowing attributes, concepts, conclusions, risks, correlations, complications of the medical conditions and knowing when prescribed medication, different medication and changed dosage of medication should take place serve as actions to be performed to improve the health of the patient, input data that indicates user selection to add the second patient to the plurality of highest risk patients; and in response to receiving the input data that indicates user selection to add the second patient to the plurality of highest risk patients, causing presentation of an updated second user interface that includes, for each of the one or more of the plurality of highest risk patients including the second patient, at least some of the corresponding characteristics data (See [P0166-P0168] Other sources can include a service that supplies identifying information of the user, where the information can include demographics or other characteristics of the user (e.g., a medical condition, a lifestyle). Also, see Fig. 8C P0200 listed characteristics or conditions questions answered by the user.).
Regarding claim 17, although Gnanasambandam and Mossin teach the system of claim 7 mentioned above mentioned above, Gnanasambandam not explicitly teach presenting alerts indicating the plurality of highest risk patients. Mossin teaches wherein causing presentation of the user interface comprises causing, using the data and the data structure, presentation of the user interface that includes i) one or more of the two or more characteristics and ii) second data indicating best practice alerts that indicate the one or more actions to be performed to improve the health of the patient, relative to the health of the patient prior to performance of the one or more actions (See P0016, P0053-P0054 presenting predicted future events as alerts.).
Therefore, it would have been obvious to one of ordinary skill in the art of predicting medical events before the effective filing date of the claimed invention to modify the system of Gnanasambandam to include presenting alerts indicating the plurality of highest risk patients as taught by Mossin to provide predictions of future clinical events and highlighting of relevant underlying medical events contributing to these predictions in a timely manner of Mossin’s P0004.
Claims 21-23 are rejected under 35 U.S.C. 103 as being unpatentable over Gnanasambandam (US 2023/0360779 A1) in view of Shah (US 2023/0282325 A1).
Regarding claim 21, although Gnanasambandam discloses the system of claim 7 mentioned above, Gnanasambandam does not explicitly teach two or more user interface elements causing presentation of a visual identifier that indicates the recommended order in which the user interface elements should be interacted. Shah teaches:
the operations comprising: computing, for two or more user interface elements from the user interface, a recommended order in which to interact with the two or more user interface elements, wherein: causing presentation of the user interface comprises causing presentation of the user interface that includes, for at least some of the two or more user interface elements, a visual identifier that indicates the recommended order in which the user interface elements should be interacted (See Fig. 5A-B Health Plan Rankings of at least 2 recommended health plans based on health record data 515 and interactive conversation from the dynamic script panel 505 mentioned in P0129-P0131. Also, see Fig. 8D, P0164-P0165 ranking and comparing health plans (Items 852 & 854) according to Doctors, Out of Pocket Cost and Diagnosis Benefits. Also, see Abstract, P0092-P0093, [P0190-P0191] generate a set of health plan and lifestyle recommendations.).
Therefore, it would have been obvious to one of ordinary skill in the art of choosing healthcare services before the effective filing date of the claimed invention to modify the system of Gnanasambandam to include two or more user interface elements causing presentation of a visual identifier that indicates the recommended order in which the user interface elements should be interacted as taught by Shah to determine optimal health plans and identify any anomalies or records that do not appear consistent with other records with potential to cause harm mentioned in Shah’s P0003, P0023.
Regarding claim 22, although Gnanasambandam and Shah teach the system of claim 21 mentioned above, Gnanasambandam does not explicitly teach a visual identifier. Shah teaches wherein the visual identifier comprises a score, a color, a font, or another visual cue (See scoring and ranking health care coverage plans in P0043-P0044. Also, see P0129-P0131. Also, see Fig. 8D, P0164-P0165.).
Therefore, it would have been obvious to one of ordinary skill in the art of choosing healthcare services before the effective filing date of the claimed invention to modify the system of Gnanasambandam to include a visual identifier as taught by Shah to determine optimal health plans and identify any anomalies or records that do not appear consistent with other records with potential to cause harm mentioned in Shah’s P0003, P0023.
Regarding claim 23, although Gnanasambandam and Shah teach the system of claim 22 mentioned above, Gnanasambandam does not explicitly teach wherein computing the recommended order uses a predicted impact on the health of a patient (See [Abstract] generate a set of health outcome predictions for the user, and based on the set of health outcome predictions, the input data, and the health record data, the system can generate a set of health care plan rankings for the user. Also, see Fig. 1 item 135 and P0028.).
Therefore, it would have been obvious to one of ordinary skill in the art of choosing healthcare services before the effective filing date of the claimed invention to modify the system of Gnanasambandam to include the recommended order uses a predicted impact on the health of a patient as taught by Shah to determine optimal health plans and identify any anomalies or records that do not appear consistent with other records with potential to cause harm mentioned in Shah’s P0003, P0023.
Response to Arguments
Applicant argues that the present application provides technical improvements by presenting a unified user interface, e.g., the claimed user interface displaying the one or more of the two or more characteristics and the second data, can reduce a quantity of computer resources, liken to the Ex Parte Desjardins case, ranked Enfish. see pg. 11-12 of Remarks – Examiner disagrees.
The Applicant is talking about optimization and computer efficiency features not claimed. In the instant case, an alleged technological problem is not being necessarily solved with a technological solution by merely depicting multiple types of data in a convenient way and displaying an action recommendation. When considered both individually and as an ordered combination do not amount to significantly more than the abstract idea.
Furthermore, even if the system computer interfaces automatically determine whether to present particular types of data based on permission access, the instant case involves a technology not claimed. Also, no technological improvements have been placed within the medical time management fields, access permission to patient data software, HIPAA management, algorithms for accessing time sensitive patient data and the functionality of a computing device itself, outside of improving the computer specifically for implementing an abstract idea.
Regarding the prior art rejection, Applicant’s arguments have been fully considered, but are now moot in view of the new grounds of rejection. The Examiner has entered a new rejection under 35 USC § 102 (e) and 103(a) and applied new art and art already of record.
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TERESA S WILLIAMS whose telephone number is (571)270-5509. The examiner can normally be reached Mon-Fri, 8:30 am -6:30 pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Mamon Obeid can be reached at (571) 270-1813. 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.
/T.S.W./Examiner, Art Unit 3687 03/16/2026
/ALAAELDIN M. ELSHAER/Primary Examiner, Art Unit 3687