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 the Claims
The status of the claims as of the response filed 02/03/2026 is as follows:
Claims 1-33 are pending.
Amended Claims 1, 29-30 and Claims 31-33 are new and have been considered below.
Continued Examination
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 02/03/2026 has been entered.
Response to Arguments
35 U.S.C. § 101 Rejections
Applicant’s arguments on pages 8-12 of the response filed 02/03/2026, with respect to the pending claims 1-33 under 35 U.S.C. § 101, have been fully considered and are not persuasive.
Applicants argue that Claim 1, is not directed to managing interactions between people or researchers, but instead to a technical improvement in data transformation.
Examiner respectfully disagreed because, Claim 1 still reads as an abstract idea because receiving cohort criteria, generating access instructions, retrieving matching data, converting selected data into a usable form for another store or user, and presenting the result for review, which is an information-processing workflow rather than a recited improvement in how the computer itself operates; and MPEP 2106.04(d)(1) and 2106.05(a), require not only an asserted technical improvement, but that the claim itself reflects the disclosed improvement.
The applicant’s argument is not persuasive on practical application, because the claim recites result-oriented compatibility and visualization rather than a particular technical solution; therefore, the § 101 rejection is maintained.
Applicant argues that Claim 1, generating, for storage at a second data store, a second dataset corresponding to the first subset of data retrieved from the first data store, wherein the second dataset corresponds to a cohort, and generating the second dataset comprises transforming at least one data type in the first dataset into a data type compatible with data processing by the user and storage at the second data store; and generating, for display at the first client device, a visual representation of at least a portion of the second dataset, is not directed to managing interactions between people, because the claim is directed to cohort dataset generation and data-type transformation, and the specification identifies prior cohort selection as often a bottlenecking event in large studies.
The Examiner respectfully disagrees because, under proper BRI, Claim 1 still reads as receiving cohort criteria, generating access instructions, retrieving matching records, converting selected information into a compatible form, and displaying the result, which is a data-selection and information-presentation workflow thus describe a mental-process. The practical-application argument is nevertheless not persuasive because MPEP 2106 requires that the claim itself reflect the improvement and recite a particular solution, and Claim 1, only recites result-oriented script generation, data compatibility, and visualization. Claim 1 does not recite the concrete mechanism said to produce that result. Therefore, the § 101 rejection is maintained, with the rationale better anchored to mental process for compact prosecution.
Applicant argues that Claim 1, generating, based at least on the one or more cohort selection criteria, a script for accessing a first data store storing a first dataset; executing the script to retrieve, from the first dataset, a first subset of data; generating, for storage at a second data store, a second dataset ... wherein generating the second dataset comprises transforming at least one data type ... into a data type compatible with data processing by the user and storage at the second data store; and generating ... a visual representation, provides new capabilities not available in existing systems, is novel and non-obvious over the prior art, and therefore is not well-understood, routine, or conventional.
The Examiner respectfully disagrees because, under the governing § 101 framework, novelty and non-obviousness are not the test for patent eligibility, and MPEP 2106.05(d) explains that the question whether an additional element is well-understood, routine, conventional is fully apart from whether the claim is new or non-obvious. Under proper BRI, Claim 1 still recites high-level data-processing functions receiving criteria, generating a script, retrieving a subset, transforming data into a compatible format, and displaying results without reciting the specific technical mechanism that the specification separately describes for database architecture or schema transformation; the specification, moreover, describes generic client devices and a generic computing system, which does not support applicant’s position that the claim itself recites a non-generic technological implementation.
Thus, the applicant’s position is not persuasive because the asserted novelty over Quinn and the other references does not, by itself, establish that the claim is not directed to an abstract idea or that the additional elements amount to significantly more under § 101. Therefore, the rejection is maintained.
35 U.S.C. § 102 and 103 Rejections
Applicant’s arguments, filed on 02/03/2026, pages 12-15, with respect to the pending claims 1-33, have been fully considered but are not persuasive.. The rejections under 35 U.S.C. § 102 and § 103 are maintained.
Applicant argues that Claim 1, "the cohort selection criteria comprises one or more parameters indicating exposure and/or outcomes" and "the cohort selection criteria comprises criteria for inclusion or exclusion of one or more subjects into a cohort for research", are not taught by the prior art because Quinn's attributes differ from exposures or outcomes, and Quinn's retrieved data is not used to create a research cohort.
The Examiner respectfully disagreed because under proper BRI, Claim 1, "parameters indicating exposure and/or outcomes" and "cohort for research" broadly encompass using medical variables like medication usage or health status to group subjects for targeted data analysis. The record shows Quinn's data analytics engine groups and analyzes patient data based on specific criteria such as lifestyle, personal health, and medications (Quinn, par. 0116), which act as exposure and outcome parameters used to include or exclude subjects for an analytical study. Thus, the applicant's position is not persuasive because Quinn expressly teaches generating and executing a script to retrieve a subset of patient data defined by these exact types of parameters to perform targeted data analysis, which functionally satisfies assembling a research cohort. Therefore, the rejection is maintained.
Applicant argues that Claim 1, "generating, for storage at a second data store, a second dataset corresponding to the first subset of data..." and "transforming at least one data type in the first dataset into a data type compatible with data processing by the user and storage at the second data store", are not taught by the prior art because Quinn preserves source electronic health record data formats and therefore teaches away from data transformation.
The Examiner respectfully disagreed because under proper BRI, Claim 1, "transforming at least one data type... into a data type compatible with data processing" broadly encompasses converting or modifying raw data into a newly calculated metric, standardized format, or anonymized dataset for subsequent analytical use. The record shows Quinn explicitly discloses a "common data platform that allows data aggregation across health data sources" (paragraph [0107]) and analyzing retrieved raw patient data to "generate health and wellness metrics" (paragraph [0265]) or store it within a "redacted patient data store 412" (paragraph [0125]). Thus, the applicant's position is not persuasive because Quinn does not criticize, discredit, or otherwise discourage data modification to establish a teaching away, but rather expressly teaches transforming the original data type into a compatible format for analytical processing and storage. Therefore, the rejection is maintained.
Applicant argues that Claims 4, 6, 11, 22-24, and 28 are allowable because the secondary references do not cure the alleged deficiencies of Quinn discussed regarding the independent claims.
The Examiner respectfully disagreed because where an applicant does not separately argue the patentability of dependent claims, they stand or fall with the independent claim. The record shows that Quinn does not possess the alleged deficiencies regarding the independent claims, as it expressly discloses a Data analytics engine 312 that analyzes and groups patient data to form subsets based on specific parameters such as disease, age, gender, lifestyle, personal health, and medications (Quinn at paragraphs [0009], [0116], [0124], and [0265]). Thus, the applicant's position is not persuasive because the rejection of the independent claims over Quinn has been shown to be proper, and the applicant has not pointed out how the additional limitations of the dependent claims patentably distinguish them over the respective applied combinations. Therefore, the rejection is maintained.
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-33 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an
abstract idea without significantly more.
Step 1:
The claims encompass three statutory categories: process, machine, and manufacture.
Process (Claims 1-28, 31-33)
These claims are directed to a computer-implemented method, which constitutes a series of acts or steps to achieve a specific outcome.
Machine (Claim 29)
This claim recites a system comprising concrete, physical components, specifically "at least one data processor" and "at least one memory".
Manufacture (Claim 30)
This claim is directed to a "non-transitory computer readable medium," which is a tangible article that has been modified by storing instructions upon it.
The claims encompass three statutory categories: process, machine, and manufacture. Having confirmed the claims fall within statutory categories, the analysis proceeds to Step 2A.
Step 2A, Prong One: Judicial Exception Analysis
Step 2A, Prong One asks whether the claims recites a judicial exception.
Independent Claims Analysis
Claim 1. A computer-implemented method, comprising:
receiving, from a first client device, a first user input specifying one or more cohort selection criteria, wherein the cohort selection criteria comprises criteria for inclusion or exclusion of one or more subjects into a cohort for research;
generating, based at least on the one or more cohort selection criteria, a script for accessing a first data store storing a first dataset, wherein the cohort selection criteria comprises one or more parameters indicating exposure and/or outcomes;
executing the script to retrieve, from the first dataset in the first data store, a first subset of data corresponding to one or more individuals having the selected cohort selection criteria;
generating, for storage at a second data store, a second dataset corresponding to the first subset of data retrieved from the first data store, wherein the second dataset corresponds to a cohort,
and generating the second dataset comprises transforming at least one data type in the first dataset into a data type compatible with data processing by the user and storage at the second data store; and
generating, for display at the first client device, a visual representation of at least a portion of the second dataset.
Note: The bolded portions represent additional elements evaluated in Prong Two and Step 2B. The non-bolded portions represent the abstract idea.
Claims 1, 29-30, recites a research-selection workflow in which a user provides cohort inclusion or exclusion criteria, the system generates access instructions from those criteria, retrieves matching records, creates a cohort dataset by converting at least one data type into a compatible form, and presents the result visually.
Claims 1, 29, and 30 recite the abstract idea of a mental process because: Receiving... a first user input specifying one or more cohort selection criteria is the evaluation and selection of who belongs in the study group; generating... a script is formulating instructions from those chosen criteria; executing the script to retrieve... a first subset of data is filtering information based on those instructions; transforming at least one data type is reformatting selected information into a usable form; and generating... a visual representation is organizing and presenting that information for review.
A direct human analogue is a researcher giving an assistant inclusion and exclusion rules, the assistant writing those rules down, locating the matching files, copying the relevant fields into a new table in a consistent format, and preparing a chart.
Dependent Claims Analysis
The dependent claims 2-28 are also directed to an abstract idea because they merely add specificity to the abstract concept recited in the independent claims without adding a non-abstract concept.
Claims 2-10, 16, 17: These claims recite, under BRI, the types of data being organized ("records...associated with a participant," "genomic biomarkers," "endpoint definition") and the rules for organizing it ("inclusion criteria or exclusion criteria"). These are refinements of the Mental Process of data categorization.
Claim 11: This claim recites "performing a deduplication"7. This is a quintessential data-organizing task a mental sorting process to identify and merge duplicate information.
Claims 12-14: These claims recite a "user interface including a... first input control" 8. A GUI is a generic, conventional tool used to perform the abstract step of providing criteria. Applying an abstract idea on a generic computer component does not make it eligible.
Claims 15, 18-28: This group recites additional abstract steps, such as specifying chart types ("heat map, a bar graph") 9, updating the criteria 10, querying a third database 11, allowing multi-user input 12, and user authentication13. These limitations describe further instructions for implementing the Mental Process or the Method of Organizing Human Activity within a broader, but still generic, technological environment.
Claim 31. Under the broadest reasonable interpretation, determining one or more default parameters for the cohort selection criteria based on a determination of essential covariates reads as selecting default study inputs by evaluating which variables are important for the cohort definition. That is a recitation of an abstract idea under Prong One because it describes a mental process, namely judgment and evaluation of which covariates are essential and what default parameters should follow from that determination, which can be performed in the human mind or with pen and paper.
Claim 32. Under the broadest reasonable interpretation, the script is generated based on the determined one or more default parameters reads as creating retrieval instructions from preselected default study inputs. This also recites an abstract idea under Prong One because, at the claimed level of generality, it is still the formulation of instructions from evaluated criteria, which remains part of the same mental-process workflow rather than a specific technical improvement in script generation.
Claim 33. Under the broadest reasonable interpretation, the first data store comprises project-specific combinations of exposure data, endpoint data, and analytic designs for projects reads as characterizing the content of the stored information available for a project. This does not itself recite an abstract idea because it is a data-store-content limitation describing what the repository contains, however inherent abstract idea from claim 1.
Because the claims as a whole are directed to a judicial exception, the analysis proceeds to Step 2A, Prong Two, to determine if the claims recite additional elements that amount to significantly more than the abstract idea itself.
Step 2A, Prong Two: Integration into a Practical Application
The claims fail to integrate the abstract idea into a practical application because the additional elements, both individually and in combination, merely provide a generic technological environment for implementing the abstract idea and do not impose meaningful limits on the claim scope.
Evaluation of Independent Claims 1, 29, and 30 Additional Elements
The additional elements beyond the abstract idea are grouped and analyzed as follows:
Computing and Storage Hardware: The recitation of a first client device, first data store, second data store, at least one data processor, and at least one memory fails to integrate the abstract idea because these are generic computer components that simply provide a setting for the abstract process.
(MPEP § 2106.05(f))- Mere Instructions: The claim is not integrated because it recites mere instructions to apply an abstract idea on a generic computer, which is not a practical application. The hardware elements (client device, data stores) are simply the generic tools invoked to perform the abstract data selection; they do not represent a specific application of the idea itself.
(MPEP § 2106.05(a))-No Tech Improvement: The claims are not integrated because they fail to recite an improvement to computer technology, instead only using the computer as a tool to perform an abstract task. The hardware components are recited functionally, without any detail on how they are improved or specially configured to perform the cohort selection in a novel way.
When viewed as a whole, the combination of a generic client device, data stores, a processor, a functionally-described script, and a generic data transformation step does not integrate the abstract idea. The collection of elements merely describes a generic computer arrangement performing the abstract analysis, which does not transform the abstract idea into a patent-eligible practical application.
Dependent Claims Analysis
The dependent claims add only minor limitations that fail to provide the necessary integration.
Claims 2-10, 16, 17: These claims add specificity to the data content (e.g., genomic biomarkers, vital status, endpoint definition). This is a mere field-of-use limitation (h) that narrows the abstract idea to the medical research field but fails to integrate it into a practical application.
Claim 11: This amended claim adds performing a deduplication. This is an insignificant pre-solution activity (g) and a fundamental, data organization and cleaning.
Claims 12-14: These amended claims add a user interface. A user interface is a generic hardware element that fails to improve computer functionality (a) and merely provides a tool for the abstract step of receiving input.
Claims 15, 18-28: This group adds further details like chart types (heat map, a bar graph), updating criteria, querying a third database, and user authentication. These limitations are insignificant post-solution activities (g) or further define the abstract rules, failing to integrate the core abstract idea into a practical application.
Claims 31-32: This group does not add any new elements, and the reasons why they are abstract have already been explained in prong one; therefore, they do not need to be evaluated in this analysis.
Claim 33 does not overcome Step 2A, Prong Two because it only says the first data store contains certain project-specific bundles (exposure data, endpoint data, analytic designs) and does not claim any specific technical mechanism that integrates the abstract workflow into a practical application. Under USPTO/MPEP §2106 guidance, adding only information content or field-of-use context without a concrete technological improvement or non-generic implementation is not enough to satisfy Prong Two.
When viewed as a whole, the combination of these elements in the dependent and independent claims does not integrate the abstract idea because they collectively amount to a more detailed set of instructions to "apply" the abstract concepts on generic computer hardware, without adding a specific, practical application.
Because the claims recite an abstract idea and the additional elements fail to impose meaningful limits that integrate the idea into a practical application, the claims are 'directed to' the judicial exception. Therefore, the analysis proceeds to Step 2B.
Step 2B: Inventive Concept Analysis
The claims lack an inventive concept because the additional elements are limited to generic computer components performing their generic functions. These elements, whether viewed individually or as an ordered combination, do not amount to significantly more than the judicial exception itself.
Evaluation of Independent Claims 1, 29, and 30 Additional Elements
Computing and Storage Hardware (client device, data stores, processor, memory)
MPEP § 2106.05(f) - Mere Instructions: The claims fail to recite an inventive concept because they merely instruct one to apply the abstract idea of cohort selection on a generic computer. The specification describes these components generically: “The one or more client devices 130 may be a processor-based device including, for example, a workstation, a desktop computer, a laptop computer, a smartphone, a tablet computer...” (Spec., para. 0051-0052).
MPEP § 2106.05(a) - No Tech Improvement: The recitation of hardware does not provide an inventive concept because it does not improve the computer's functionality. The claims do not describe a specific technological improvement to the hardware, instead describing a standard deployment: a “computing system 500 can include a processor 510, a memory 520, a storage device 530, and input/output devices 540” (Spec., para. 0074-0075).
MPEP § 2106.05(d) - WRC Elements: These hardware components are well-understood, routine, and conventional and thus do not provide an inventive concept. The specification's description of standard, off-the-shelf computer systems (Spec., paras. 0051-0052, 0074-0075) confirms these elements are nothing more than a generic technological environment.
Viewed as an ordered combination, the additional elements fail to provide an inventive concept. Merely instructing (MPEP § 2106.05(f)) the use of hardware to perform functionally-claimed software steps that do not improve the computer itself (MPEP § 2106.05(a)) amounts to nothing more than automating a mental process in a high-level way, which is not 'significantly more.'
Dependent Claims Analysis
(Claims 2-10, 16-17): These claims add details about the data being processed ("plurality of attributes corresponding to one or more exposures, genomic biomarkers, and/or clinical phenotypes" Spec., para. 0010). This is a mere field-of-use limitation (h) that confines the abstract idea to medical research but does not add an inventive concept.
(Claim 11): The amended claim adds performing a deduplication. This is an insignificant pre-solution activity (g). The specification describes this functionally without presenting any inventive technique (Spec., para. [0018-0019]).
(Claims 12-14): The amended claims add a user interface. This is a well-understood, routine, and conventional tool (d) for receiving user input. The specification describes a generic interface for making selections (Spec., para. 0019-0020).
(Claims 15, 18-28): This group recites additional abstract steps like displaying charts ("heat map, a bar graph" Spec., para.0022-0023) and user authentication ("project & user management system 160" Spec., para. 0066-0065). There are not new additional element it just abstract steps.
Claims 31-32: This group does not add any new elements, and the reasons why they are abstract have already been explained in prong one; therefore, they do not need to be evaluated in this analysis.
Claim 33 does not overcome Step 2B because it only says the first data store contains certain project-specific bundles (exposure data, endpoint data, analytic designs) and does not claim any specific technical mechanism that integrates the abstract workflow to significantly more. Under USPTO/MPEP §2106 guidance, adding only information content or field-of-use context without a concrete technological improvement or non-generic implementation is not enough to satisfy Step 2B.
The additional elements in the dependent claims, even when combined with the independent claims, fail to supply an inventive concept. They merely add more detail about the abstract idea itself or the technological environment in which it is applied.
The claims are directed to an abstract idea and lack an inventive concept because the additional elements simply describe using a generic computer to perform the abstract mental process of data selection and organization. Therefore, Claims 1-30 are rejected under 35 U.S.C. § 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.
2. Claim(s) 1-3, 5, 7-10, 12--21, 25-27 and 29-33 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Quinn et al. - US 2021/0049719
Claim 1. Quinn teaches, A computer-implemented method, comprising:
receiving, from a first client device, a first user input specifying one or more cohort selection criteria, wherein the cohort selection criteria comprises criteria for inclusion or exclusion of one or more subjects into a cohort for research;
Quinn's system is described as "receiving, by a controller, a user request from a first system user" where the request may be an "analysis of health data associated with the first group of system users" (paragraph [0009]). The system receives this request, for instance, from a provider, as taught in paragraph [0164]: "At 1506, user application engine 320 receives a request from provider 204." The criteria for this analysis can be specified, for example, through a "Category icon 6024" that allows a user to select a "medical condition" (paragraph [0301]). This system functionality is the semantic and logical equivalent of receiving user input specifying cohort selection criteria. Quinn describe wherein the cohort selection criteria comprises criteria for inclusion or exclusion of one or more subjects into a cohort for research by disclosing a data analytics engine that forms a first group of system users by grouping patient data based on parameters like disease, age, gender, or geography, and subsequently analyzing that grouped health data. Said grouping of patient data based on various parameters is read on the cohort selection criteria, as patients are included or excluded from the analyzed group based on whether they possess the selected parameter, which explicitly fulfills assembling a cohort for research. Refer to par. 0116, 0008
generating, based at least on the one or more cohort selection criteria, a script for accessing a first data store storing a first dataset, wherein the cohort selection criteria comprises one or more parameters indicating exposure and/or outcomes;
Quinn teaches that upon receiving a user request for analysis, its "Data analytics engine 312" will "group or analyze patient data based on various parameters" (paragraph [0116]) from the data stored in its "Data store 330" (paragraph [0124]). The function of the engine analyzing the data store based on user-defined parameters teaches the generation of an underlying query (a "script") to access that data store.
Quinn explicitly lists numerous parameters for grouping and analyzing patient data that directly correspond to exposures (e.g., medications, lifestyle, health applications used) and outcomes (e.g., personal health). Refer to paragraph 0116.
executing the script to retrieve, from the first dataset in the first data store, a first subset of data corresponding to one or more individuals having the selected cohort selection criteria;
Quinn teaches executing an analysis for a specified group of users. The system's purpose is for "analyzing, by the controller, health data for a first group of system users if the user request is an analysis of health data" (paragraph [0009]). This analysis function necessarily includes the step of retrieving the data for that specific group (a subset) from the main "Data store 330" in order to perform the analysis. This is further shown by the system's ability to display discrete groups like the "watch list 5634" (paragraph [0271]), which requires retrieving that subset of data.
The data that is analyzed and provided corresponds specifically to the selected group, par. 0091, abstract.
generating, for storage at a second data store, a second dataset corresponding to the first subset of data retrieved from the first data store, wherein the second dataset corresponds to a cohort. and generating the second dataset comprises transforming at least one data type in the first dataset into a data type compatible with data processing by the user and storage at the second data store;
Quinn teaches that its system "analyzes the retrieved data, and generates... health and wellness metrics" (paragraph [0265]) and provides the "analyzed health data" to the user (paragraph [0009]). This generated output is a new dataset. This new dataset, such as "Ranking Data 410", is then stored in the system distinct from the raw source data ("Patient Data 402"), as shown in FIG. 4 and described in paragraph [0125], which functions as storage in a second data store.
Quinn's disclosure of a Data analytics engine that analyzes raw data to "Generate health / wellness metrics" directly maps to the claimed transformation. The raw data retrieved for the cohort is the "first subset," and the resulting "metric" is the "second dataset." This transformation from raw data points into a calculated "metric" or "trend" is precisely what makes the data "compatible with data processing by the user." The subsequent step to "Provide metrics to patient" this newly generated dataset be stored, even if transiently, in the system's memory or storage (memory 5502, storage device 5503), which satisfies the "storage at a second data store" element. See paragraphs 0009, 0091, 0116, 0265-0266, fig. 54
and generating, for display at the first client device, a visual representation of at least a portion of the second dataset.
Quinn explicitly teaches generating visual charts from analyzed health data, stating, "In various embodiments, the analytics are displayed pictorially in pie charts, bar charts, line charts, and the like" (paragraph [0283]). Quinn's FIG. 60 explicitly shows bar charts and line graphs that display "analytics" of patient data, such as "BP IMPROVEMENT" and "SYSTOLIC BP AVERAGE", which is further detailed in paragraph [0303]. This directly teaches generating a visual representation of the analyzed data (the second dataset) for display.
Note: Claim 29-30 are rejected by the same analysis above to be very similar.
Claim 2. Quinn teaches, The method of claim 1, wherein the first dataset includes a plurality of records, and wherein each of the plurality of records is associated with a participant.
Quinn teaches this directly. The system is designed for processing medical data from a "plurality of system users" which includes a "plurality of patient systems 208" (paragraph [0084]). The central data repository includes a "patient data store 402" (paragraph [0125]) for holding this information.
Claim 3. Quinn teaches, The method of claim 2, wherein each of the plurality of records is associated with a plurality of attributes corresponding to one or more exposures, genomic biomarkers, and/or clinical phenotypes of the participant.
Quinn teaches the collection of a plurality of such attributes. The system is designed to process "wellness data, such as the exercise regiment, diet" (paragraph [0150]), which are exposures. It also processes "physiological parameters" monitored by health devices, including "heart rate," "blood pressure," and "blood chemistry, such as glucose" (paragraphs [0096], [0098]), which are clinical phenotypes.
Claim 5. Quinn teaches, The method of claim 3, wherein the plurality of attributes include a first date when follow-up began, a second date when follow-up ended, and a third date of each follow-up survey.
Quinn teaches a system for "long-term disease management" (paragraph [0088]) that includes a "survey engine 306" (paragraph [0113]), which necessitates the tracking of events over time. The system's ability to record and display the date of the "LAST DATA CAPTURE" (FIG. 48) for a device demonstrates that it tracks data with associated dates, which is the basis for follow-up periods and survey dates.
Claim 7. Quinn teaches, The method of claim 3, wherein the script is executed to identify, based on one or more of the plurality of attributes, one or more records matching the one or more cohort selection criteria.
Quinn explicitly teaches this functionality. The "Data analytics engine 312" is disclosed to "group or analyze patient data based on various parameters, including, for example, ... gender, ethnicity, age, lifestyle, personal health, medications..." (paragraph [0116]). This action is the definition of identifying records based on one or more attributes to match selection criteria.
Claim 8. Quinn teaches, The method of claim 3, wherein the script is executed to identify, based on a combination of a first attribute and a second attribute from the plurality of attributes, one or more records matching the one or more cohort selection criteria.
Quinn describes how its "Data analytics engine 312" can determine a patient's condition "based on an analysis of both blood sugar and weight" (paragraph [0266]). This is a clear example of executing a script to identify a record (a patient showing signs of diabetes) based on a combination of a first attribute (blood sugar) and a second attribute (weight).
Claim 9. Quinn teaches, The method of claim 8, wherein the combination of the first attribute and the second attribute comprises a maximum, a minimum, a mean, a mode, a median, and/or a range of a respective values of the first attribute and the second attribute.
Quinn’s system generates an "alert list 5636" composed of any patient whose medical results "falls outside of a normal or patient-specific range," which is a direct disclosure of identifying records using a "range" as the selection criterion (para. [0271]). This function is semantically and functionally identical to the applicant's claimed step of using a "range," "minimum," or "maximum" as the basis for the "combination of attributes" to select a cohort.
Claim 10. Quinn teaches, The method of claim 2, wherein the plurality of records include a first record for a first disease associated with the participant and a second record for a second disease associated with the participant.
The system allows patients to input their "medical history, chronic conditions, and current health conditions" (paragraph [0149]). The use of plural terms "chronic conditions" and "health conditions" shows the system's ability to manage records for a participant with multiple diseases. The analysis of co-morbid indicators like "blood sugar and weight" (paragraph [0266]) further supports that the system handles data for multiple conditions for a single participant.
Claim 12. Quinn teaches, The method of claim 2, further comprising:
generating a user interface for receiving the first user input specifying the one or more cohort selection criteria, the user interface including a first input control for a first cohort selection criterion determined based on at least a portion of the plurality of records.
Quinn teaches this directly. Quinn's FIG. 60 shows a user interface that includes a "category icon 6024" (paragraph [0300]). This icon is described as an input control that "allows employer 230 to access, add, or modify information related to types of medical condition, vitals, health condition, or status of user" (paragraph [0301]), which directly corresponds to a first input control for a first cohort selection criterion.
Quinn's system first analyzes the entire set of employee health data (the "plurality of records"). From this analysis, it identifies key health conditions present within that population, such as "high blood pressure" and "high blood sugar." Par. 0298
Claim 13. Quinn teaches, The method of claim 12, wherein the first input control provides a selection between at least a first value and a second value for the first cohort selection criteria, and wherein the first value and the second value are determined on at least the portion of the plurality of records.
Quinn teaches this functionality. The "category icon 6024" allows a user to select from various "types of medical condition, vitals, health condition, or status of user" (paragraph [0301]). This act of selecting a category, such as "HIGH BP" or "BMI > 30" as shown in FIG. 60, constitutes a selection between at least a first value and a second value for the cohort selection criterion.
The fact that these specific values ("HGH BP," "HIGH BLOOD SUGAR") are presented as options, and especially that they are presented with a corresponding count of individuals, proves they were determined by analyzing the plurality of employee records. To generate the UI element "high blood pressure (9027)," the system must have first processed the plurality of records to identify and count all instances of that condition. Refer to par. 0298
Claim 14. Quinn teaches, The method of claim 12, wherein the user interface further includes a second input control for a second cohort selection criterion determined based on at least the portion of the plurality of records.
Quinn teaches a user interface with multiple controls for defining the analysis cohort. The screenshot in FIG. 60 includes the "category icon 6024" (the first input control) and also a "time period icon 6026" (paragraph [0300]). This "time period icon 6026" (paragraph [0302]) functions as a second input control, allowing the user to specify a second criterion (the time period) for the data selection.
The selectable date ranges offered by this icon are "determined based on at least the portion of the plurality of records," because the system must know the date range of the underlying data to provide a meaningful and functional time-based filter. Refer to par. 0302
Claim 15. Quinn teaches, The method of claim 1, wherein the visual representation of at least the portion of the second dataset include at least one of a heat map, a bar graph, a pie chart, and a line graph.
Quinn explicitly states that in its system, "the analytics are displayed pictorially in pie charts, bar charts, line charts, and the like" (paragraph [0283]). This disclosure anticipates the claimed limitation.
Claim 16. Quinn teaches, The method of claim 1, wherein the one or more cohort selection criteria includes an endpoint definition comprising one or more of a disease diagnosis, hospitalization, and mortality.
Quinn's system allows users to select patient groups based on "types of medical condition" (paragraph [0301]), which is a "disease diagnosis." It also explicitly identifies and lists patients who are "hospitalized" (paragraph [0271]). Therefore, Quinn teaches using disease diagnosis and hospitalization as cohort selection criteria.
Claim 17. Quinn teaches, The method of claim 1, wherein the one or more cohort selection criteria includes one or more inclusion criteria or exclusion criteria.
Quinn teaches a method of claim 1 wherein a user can define cohort selection criteria. Quinn’s “Data analytics engine 312” allows a user to "group or analyze patient data based on various parameters" (paragraph [0116]), such as a specific medical condition or patient status. This functional selection of a group based on parameters is equivalent to applying rules to include certain participants and exclude others.
Claim 18. Quinn teaches, The method of claim 1, further comprising:
receiving, from the client device, a second user input modifying the one or more cohort selection criteria;
Quinn teaches an iterative system where a user can modify parameters. The process flows described in Quinn explicitly show the system returning to a state of "waiting to receive a... request" after an action is performed (paragraph [0127]). The user interface provides controls like the "category icon 6024" (paragraph [0301]) and "time period icon 6026" (paragraph [0302]) that allow a user to change the parameters of the analysis, which is the equivalent of receiving a second user input to modify the cohort selection criteria.
updating, based at least on the one or more modified cohort selection criteria, the script for accessing the first data store storing the first dataset;
When a user selects new criteria via the user interface, the system "displays the data" reflecting that new selection (paragraph [0303]). To accomplish this, the system's "Data analytics engine 312" (paragraph [0116]) must update its internal logic or query to match the modified criteria before it can retrieve and display the correct new results. This is the functional equivalent of updating the script.
executing the updated script to retrieve, from the first dataset in the first data store, a second subset of data;
Quinn teaches this as the direct result of a user modifying the analysis criteria. The statement that "Upon selection of icons 6022, 6024 and 6026, health information processing system 202 displays the data" (paragraph [0303]) requires the system to first execute the updated query based on the new selections to retrieve the corresponding new subset of data that will then be displayed.
and updating the second data store to include the second subset of data retrieved from the first data store.
Quinn teaches that after a user modifies selection criteria, a new set of "analyzed health data" is generated and provided to the user (paragraph [0009]). The creation and storage (even if transiently for display) of this new set of results, which corresponds to the newly retrieved "second subset of data," is functionally equivalent to updating the second data store.
Claim 19. Quinn teaches, The method of claim 18, wherein the second data store is updated to include the first subset of data as a first version of the second dataset and the second subset of data as a second version of the second dataset.
Quinn's system allows a user to access history, including "data share, review, or recommendations reviewed" (paragraphs [0132], [0147]). For the system to provide a history of user actions, such as performing a first analysis and then a second, modified analysis, it must store records of both events. This storage of sequential analysis results is the functional equivalent of storing a first version and a second version of the dataset.
Claim 20. Quinn teaches, The method of claim 18, wherein the second data store is updated by at least replacing the first subset of data with the second subset of data as the second dataset.
Quinn teaches when a user modifies the analysis criteria, the system's described action is to "display the data" corresponding to the new selection (paragraph [0303]). For the user interface to show the new visualization, the previous visualization must be replaced. This replacement on the display is driven by the underlying dataset for the visualization being replaced, which is a direct teaching of updating by replacing the first subset with the second.
Claim 21. Quinn teaches, The method of claim 1, further comprising:
generating the first dataset by at least querying a third data store to retrieve at least a portion of a third dataset stored therein;
Quinn explicitly discloses an architecture where its central system interacts with external data systems. FIG. 2 shows the "PatientKey System 202" communicating with external entities, including a "health information exchange/electronic health record (HIE/EHR) system 210" (paragraph [0084]). An HIE/EHR system is a third-party data repository, which is the equivalent of a "third data store." The central system stores data "received from... HIE/EHR system 210" (paragraph [0125]), which is the functional equivalent of querying and retrieving a third dataset.
and updating the first data store to include the first dataset.
Quinn teaches that its central "Data store 330" (the first data store) includes a "HIE/EHR data store 408 for storing data received from... HIE/EHR system 210" (paragraph [0125]). This act of receiving and storing data from the external HIE/EHR system is a direct teaching of updating the first data store to include the retrieved data.
Claim 25. Quinn teaches, The method of claim 21, wherein the generating of the first dataset includes joining at least the portion of the third dataset.
Quinn teaches this function through its disclosure of "data aggregation across health data sources 227" (paragraph [0107]). The example of performing "an analysis of both blood sugar and weight" (paragraph [0266]) to make a clinical determination inherently requires joining these two separate data points for a given patient, thus teaching the claimed limitation.
Claim 26. Quinn teaches, The method of claim 1, further comprising:
receiving, from the first client device, the first user input specifying a first cohort selection criterion;
Quinn teaches this directly. Quinn's system is built to receive user requests, such as when its "user application engine 320 receives a patent request from patient 208" (paragraph [0127]) or a "request from provider 204" (paragraph [0164]). This initial request to analyze data for a cohort is the claimed receiving of a first user input from a first client device.
and receiving, from a second client device, a second user input modifying the first cohort selection criteria and/or specifying a second cohort selection criteria.
Quinn teaches a multi-user platform where data is shared and acted upon by different users. A patient (first user) on a "first client device" can authorize a provider to see their data via the "data sharing" function (paragraph [0152] ). The provider (second user) can then log in from their own "second client device" and submit a "provider request" (paragraph [0164]) to analyze that same dataset, which is the functional equivalent of receiving a second user input from a second client device to modify or specify selection criteria.
Claim 27. Quinn teaches, The method of claim 1, further comprising:
in response to the first user input specifying a first value for a cohort selection criterion, generating the second dataset to correspond to the first dataset retrieved from the first data store;
Quinn teaches this. A user can select a "first value" for a criterion, such as a "medical condition" (paragraph [0301]), and in response, the system retrieves the matching data and generates "analyzed health data" (paragraph [0009]), which is the resulting second dataset.
and in response to the first user input specifying a second value for the cohort selection criterion, generating a further subset of the first subset of the first dataset corresponding to the second value of the cohort selection criterion and generating the second dataset to correspond to the further subset of the first subset of the first dataset.
Quinn teaches an interface that allows for this type of layered filtering. The UI disclosed in Quinn includes multiple controls, such as a "category icon 6024" (paragraph [0301]) and a "time period icon 6026" (paragraph [0302]). A user can apply a first filter (e.g., category = "HIGH BLOOD PRESSURE"), and then apply a second filter to those results (e.g., time period = "3 MONTHS"). The result is a subset of the originally filtered data, which is precisely what the claim describes.Claim 31.
Quinn teaches, The method of claim 1, further comprising: determining one or more default parameters for the cohort selection criteria based on a determination of essential covariates for the cohort selection criteria. (Quinn, par. 0279-0280,0186 )
Quinn describes this limitation by detailing how the system identifies and targets "groups of patients" (cohorts) by evaluating essential baseline attributes, specifically utilizing a "patient profile (age, gender) or medical vitals (e.g., body mass index or blood pressure)" as the covariates. Furthermore, Quinn explains that these group-defining parameters are determined and applied systematically, as cohort selections and subsequent actions can be "made automatically based on criteria set by provider."
Claim 32.
Quinn teaches, The method of claim 31, wherein the script is generated based on the determined one or more default parameters. (Quinn, par. 0279-0280,0186 )
Quinn explains that the system generates instructions by automatically issuing medical directives “based on criteria set by provider 204.” These criteria function as the defined parameters, prompting the system to act when it evaluates a “patient profile (age, gender) or medical vitals (e.g., body mass index or blood pressure) or a specific medical condition.” Upon matching these parameters, the system executes the generated instructions as it “recommends health data sources 227 or health applications... via email, short message service (SMS) text, [or] phone call” to the targeted patients.
Claim 33.
The method of claim 1, wherein the first data store comprises project-specific combinations of exposure data, endpoint data, and analytic designs for projects.
Quinn in Paragraph [0116], describes how the “Data analytics engine 312” (analytic designs) evaluates custom combinations of “patient device usage” and “medications” (exposure data) alongside “health trends” and “efficacy of devices” (endpoint data). Quinn explains that this is achieved by allowing the engine to “group or analyze patient data based on various parameters,” enabling developers and providers to isolate specific variables for targeted health and regulatory evaluations. Furthermore, Paragraph [0286] demonstrates these project-specific combinations in action, noting the system generates customized analytics tracking specific “bundles” of applications and devices (exposures) against the “corresponding improvements or changes in vitals” (endpoints).
Claim Rejections - 35 USC § 103
3. 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.
4. 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.
5. Claim(s) 4, is/are rejected under 35 U.S.C. 103 as being unpatentable over Quinn et al. - US 2021/0049719 A1 in further combination with Delaney et al. - US20240161883A1
Claim 4. Quinn teaches, The method of claim 3, wherein the plurality of attributes include a date of birth, a race, an ethnicity, and a vital status of the participant.
Quinn teaches a method of processing healthcare data where records are associated with a plurality of attributes. Quinn discloses that its "Data analytics engine 312" is able to "group or analyze patient data based on various parameters, including, for example, employer, geography, gender, ethnicity, age, lifestyle..." (paragraph [0116] ). Quinn's explicit teaching of analysis by "ethnicity" and "age" (which implies date of birth) teaches most of the claimed attributes. While Quinn's system for "chronic disease management" (paragraph [0085] ) would inherently track a patient's condition, it does not explicitly enumerate all standard demographic and status attributes.
Delaney teaches that it is a standard practice for healthcare data systems to include the attributes recited in the claim. Delaney discloses a system configured to support a "plurality of data types required by a broad range of clinicians," specifically including "demographics" and "vital signs" (paragraph [0052]).
It would have been obvious to a person of ordinary skill in the art at the time the invention was made to implement the healthcare data system of Quinn to include the full range of standard demographic and status attributes as confirmed by Delaney. The motivation would be to create a more comprehensive and clinically useful patient profile for the analysis that Quinn's system is designed to perform. Delaney confirms the standard practice of including "demographics" and "vital signs" (paragraph [0052]) in such a system. The tracking of "vital signs" is directly related to monitoring a patient's "vital status." Therefore, a skilled artisan would have found it obvious to incorporate these data types into Quinn's platform to provide a more robust and complete dataset for analysis, which is a predictable improvement of the system.
6. Claim(s) 6 is/are rejected under 35 U.S.C. 103 as being unpatentable over Quinn et al. - US 2021/0049719 A1 in further combination with US-10957433-B2– Lucas
Claim 6. Quinn teaches, The method of claim 3, wherein the plurality of attributes include a site, a stage, a grade, and a diagnosis date for a disease associated with the participant.
Quinn teaches a method of processing healthcare data for "chronic disease management" that involves collecting a patient's "medical history, chronic conditions, and current health conditions" (paragraphs [0085], [0149]). Quinn does not teach that the patient records include the specific attributes of a site, a stage, a grade, and a diagnosis date for a disease associated with the participant.
Lucas addresses this deficiency by disclosing a system that automatically processes clinical documents to identify and extract key characteristics. Lucas explicitly teaches the structuring of clinical data into numerous fields, including "clinical diagnoses (e.g., date of initial diagnosis, date of metastatic diagnosis, cancer staging, tumor characterization, tissue of origin, etc.)" [Column 6, lines 10-45] and further provides for the "categorization of concept candidates" to include "Primary Diagnosis Site," "Metastatic Diagnosis Site," "Standard Grade," "Alternative Grade," and "American Joint Committee on Cancer (AJCC) Stage." This directly teaches the missing elements of site, stage, and grade as critical attributes for characterizing a patient's disease.
A person of ordinary skill in the art would have been motivated to modify the general cohort selection system of Quinn with the specific clinical data extraction and structuring capabilities disclosed by Lucas. This motivation is found to resolve the problem identify with Lucas "parts of a patient’s record which may include rich and meaningful data... remain isolated, unstructured, and inaccessible" Lucas Column 1, 2. Description of the Related Art. To solve this, Lucas teaches a system that automatically processes clinical documents to extract key characteristics, including fields for "clinical diagnoses (e.g., date of initial diagnosis, date of metastatic diagnosis, cancer staging, tumor characterization, tissue of origin, etc.)" and categorizes concepts such as "Primary Diagnosis Site," "Standard Grade," and "American Joint Committee on Cancer (AJCC) Stage”.)" Lucas, [Column 6, lines 10-45]
7. Claim(s) 11 is/are rejected under 35 U.S.C. 103 as being unpatentable over Quinn et al. - US 2021/0049719 A1 in further combination with Petersen et al. - US20210019296A1
Claim 11.Quinn teaches, The method of claim 2, further comprising:
preprocessing the first dataset at the first data store by at least identifying a first record and a second record of a same disease associated with the participant, and performing a deduplication that includes (i) removing the first record or the second record based on the first record and the second record being identical or (ii) combining the first record and the second record to generate a third record replacing the first record and the second record based on the first record and the second record each containing some but not all of the plurality of records.
Quinn teaches a method for processing healthcare data for a "plurality of... patients" (paragraph [0084]) using a "common data platform that allows data aggregation across health data sources" (paragraph [0107]). The goal of this aggregation is to produce "actionable patient data" (paragraph [0105]).
Quinn does not explicitly disclose the specific preprocessing steps of identifying and performing deduplication on duplicate records for the same disease or event.
Petersen is directed to a "SYSTEM AND METHOD FOR DATA DE-DUPLICATION AND AUGMENTATION" within the healthcare data domain. Petersen explicitly addresses the problem where aggregated records "may accumulate duplicated data" (paragraph [0002]). To solve this, Petersen teaches a method to "remove duplicate information/records" (paragraph [0014]). The method includes the steps of "Identify a record in the prescription history response that is eligible for data de-duplication" (paragraph [0123], FIG. 5, step 512 ) and to "Remove the record based on a determination that the record is a duplicated record" (paragraph [0124], FIG. 5, step 514).
Petersen also teaches the process of combining two different, incomplete records to generate a single, more complete record that replaces them. This is accomplished through a combination of data aggregation and augmentation. Petersen , abstract, par. 0003, 0061, 0081 By aggregating data from a first and second record and then using its augmentation logic to fill in missing fields from one record using data present in the other (or an external source), Petersen generates a new, more complete "third record." This final, augmented, and de-duplicated record effectively replaces the original incomplete records in the final data response provided to the user.
It would have been obvious to a person of ordinary skill in the art at the time the invention was made to modify the system of Quinn with the explicit data deduplication method taught by Petersen. A person of ordinary skill implementing Quinn's system for "data aggregation across health data sources" (paragraph [0107]) would recognize the problem that such aggregation leads to duplicate records, which Petersen describes as when records "accumulate duplicated data" (paragraph [0002] ).
The motivation to solve this problem would be to achieve Quinn's stated goal of providing "actionable patient data" (paragraph [0105]), as redundant data is not actionable. A skilled artisan would have been motivated to look for solutions and would have found the explicit method in Petersen for "removing duplicate dispensed medication records" (paragraph [0023]). It would have been obvious to incorporate Petersen's steps of identifying and removing duplicate records (paragraphs [0123-0124]) into Quinn's data aggregation pipeline to achieve the predictable result of a higher-quality, de-duplicated, and therefore more "actionable" dataset.
Claim(s) 22-24 is/are rejected under 35 U.S.C. 103 as being unpatentable over Quinn et al. - US 2021/0049719 A1 in further combination with Hagmar et al. - US20190370409A1.
Claim 22. Quinn teaches, The method of claim 21, wherein the third data store is a relational database and the first data store is a non-relational database.
Quinn does not teach the specific database technologies used, namely that the third data store is a relational database and the first data store is a non-relational database.
Hagmar teaches a data propagation and mapping system designed to work between various types of databases, and its disclosure explicitly contemplates the use of both "relational databases (e.g., Oracle databases, MySQL databases, etc.), [and] non-relational databases (e.g., NoSQL databases, etc.)" (paragraph [0028]).
It would have been obvious to a person of ordinary skill in the art, at the time the invention was made, to implement Quinn's data aggregation system using the specific database technologies taught by Hagmar. A person of ordinary skill, tasked with building the "common data platform" of Quinn (paragraph [0107]), would be confronted with the exact technical problem Hagmar describes: integrating data from sources with different, potentially "incompatible storage format[s]" (paragraph [0040]). The motivation to consult a reference like Hagmar would be to solve this problem. It would have been obvious to apply Hagmar's solution—using a flexible non-relational database as the central store and accommodating legacy relational databases as third-party sources (paragraph [0028])—to the system of Quinn to achieve the benefit of a functional and reliable aggregation platform.
Claim 23. Quinn in combination with Hagmar teaches, The method of claim 22, wherein the generating of the first dataset includes transforming at least a portion of the third dataset retrieved from the third data store from a predefined schema of the relational database to a dynamic schema of the non-relational database.
Hagmar identifies "mapping the propagated data from a first storage format to a second storage format" as one of the "examples of technical problems" its system is designed to solve (paragraph [0062]). Hagmar's solution is a "mapping pipeline" (FIG. 1) configured to "transform data stored in a first storage format into data stored in a second storage format" (paragraph [0019]), for example by converting "linked data objects... to a series of tabulated entries" (paragraph [0035]).
Claim 24. Quinn teaches, The method of claim 21, wherein the generating of the first dataset includes performing a domain based filtering of the third dataset.
Quinn teaches a health information system that processes medical data from various sources and users, including the displaying of health data item icons and receiving selections of health data items for sharing (Quinn, Abstract, Claim 39). However, Quinn does not explicitly disclose performing a "domain based filtering" of a dataset as part of generating a new dataset; instead, its data analysis functions focus on grouping or analyzing already collected patient data based on various parameters for purposes such as ranking or trend detection, rather than an initial filtering step during dataset generation (Quinn, [0116]).
But Hagmar describes filtering data entries based on properties or characteristics to generate a subset of filtered data entries (Hagmar, Abstract, [0034]). Hagmar's system is configured to "filter the one or more identified data entries in the first non-transitory computer storage medium to generate a subset of filtered data entries" (Hagmar, paragraph [0005], [0034]).
It is obvious to combine Quinn with Hagmar because both references deal with managing and processing data, specifically filtering data to make it more relevant or usable. Quinn's system processes "medical data from health care providers, payers and patients" (Quinn, [0002]), while Hagmar's system "may funnel data entries from the first database into a mapping pipeline to transform data stored in a first storage format to a data entry in a second storage format" (Hagmar, [0035]). A person of ordinary skill in the art would be motivated to integrate domain-based filtering into Quinn's system because it offers the benefit of reducing the amount of data transferred and processed, as noted in Hagmar where "the filtering step may be advantageously executed prior to the identifying step to reduce the amount of data entries to transfer from the first database to the system, thereby reducing storage demands on the computing system" (Hagmar, [0053]).
Claim(s) 28 is/are rejected under 35 U.S.C. 103 as being unpatentable over Quinn et al. - US 2021/0049719 A1 in further combination with McCarthy et al. - US20150163206A1.
Claim 28. Quinn teaches, The method of claim 1, further comprising:
authenticating a user associated with the first client device by at least sending, to a project and user management system, a user credential information from an active directory of a secure environment and receiving, from the project and user management system, one or more client devices with access to a project associated with the first dataset.
Quinn teaches a healthcare data platform that comprises authenticating a user. Specifically, Quinn discloses a "security engine 304" that "authenticates people or systems trying to access health information processing system 202 as an authorized system users 201" (paragraph [0112]). However, Quinn does not explicitly disclose an authentication architecture where credentials from an active directory are sent to a separate project and user management system for verification.
McCarthy teaches a customizable secure data exchange environment with a sophisticated authentication and identity management framework. McCarthy discloses that an "identity service is responsible for validating the identity of a user" and that this service may support a "federation model" where the service is "provided by a fourth organizational entity identity provider" (paragraph [0013-0015]). This external identity provider is the functional equivalent of the claimed "project and user management system." Furthermore, McCarthy explicitly teaches integration with Active Directory, disclosing that the system can perform "bulk user administration through active directory" (paragraph 0178-0179).
It would have been obvious to a person of ordinary skill in the art at the time the invention was made to implement the general authentication system of Quinn using the specific dedicated identity provider architecture taught by McCarthy. A person of ordinary skill tasked with building the multi-user healthcare platform of Quinn would recognize the need for a robust, scalable, and secure authentication solution suitable for multiple organizations, a challenge that Quinn's general "security engine 304" (paragraph [0112]) addresses.
The motivation to modify Quinn’s system would arise from the need to manage secure access across different business entities, a problem explicitly solved by McCarthy. McCarthy's system is designed for "secure sharing of... content between a first client device accessed by a user associated with a first organizational entity and a second client device accessed by a user associated with a second organizational entity" (paragraph [0005]). A skilled artisan, facing this same cross-enterprise challenge in Quinn's healthcare context, would have been motivated to adopt McCarthy's proven architecture to gain the predictable benefits of enhanced security and standardized user management. It would have been an obvious design choice to implement McCarthy's "identity service" that supports a "federation model" (paragraph [0014]) and allows for "active directory" integration (paragraph [0179]) into the Quinn platform to create a more secure, scalable, and enterprise-ready system with a reasonable expectation of success.
Conclusion
Relevant Prior Arts: The following prior arts are relevant because recites: US 11328796 B1->In some implementations, one or more computing devices receive data indicating selection criteria for a cohort through an interface. The one or more computing devices determine a first set of candidates classified as having attributes that satisfy the selection criteria. The one or more computing devices also determine a second set of candidates that satisfy a subset of the selection criteria and are determined to not satisfy a same one or more criteria of the selection criteria. The one or more computing devices provide output data through the interface that includes (i) data indicating the first set of candidates, (ii) data indicating the second set of candidates, and (iii) data indicating the one or more selection criteria not satisfied by the members of the second set of candidates.(abstract, fig.1).
US 20220059240 A1-> [0007] In one embodiment the invention provides a method for identifying an outlier group of patients, including: 1) selecting a cohort of patients including a plurality of patients; 2) calculating an average survival rate for the cohort of patients; 3) selecting a plurality of clinical or molecular characteristics associated with the cohort of patients; 4) for each characteristic of the plurality of characteristics: a) identifying a plurality of data values associated with the characteristic, b) for each data value of the plurality of data values associated with the characteristic: i) dividing the cohort of patients into a first subgroup and a second subgroup of the plurality of patients based on whether each patient of the plurality of patients survived during an outlier time period, ii) determining a difference between a number of patients in the first subgroup and the second subgroup, and iii) selecting a data value that results in the difference that is a largest difference between a number of patients in the first subgroup and the second subgroup; 5) creating a new node of a tree structure based on the data value that results in the largest difference between the number of patients in the first subgroup and the second subgroup; 6) creating a first branch from the new node based on the first subgroup; 7) creating a second branch from the new node based on the second subgroup; 8) for each of the first branch and the second branch, repeating steps of 4) b) i-iii) and 5) based on patients in the first subgroup and the second subgroup, respectively, until either: a maximum number of nodes or branches has been created, or a node contains fewer than a minimum number of patients; and 9) identifying at least one node containing an outlier group of patients. [0094] An alteration module may be one or more microservices, servers, scripts, or other executable algorithms which generate alteration features associated with de-identified patient features from the feature collection. [0116] Patient Cohort Filtering User Interface
US 20180285526 A1 -> Cohort definition and selection system for a computer having a memory, a central processing unit and a display, the system including: a cohort definition module to configure the memory according to a phenotype vector. The phenotype vector includes a patient ID to uniquely associate the phenotype vector to a patient, a plurality of demographic dimension fields, each demographic dimension field to describe a respective demographic aspect of the patient, a calculated dimension field to describe a calculated information related to the patient, a plurality of phenotype-based dimension fields, each phenotype-based dimension field to indicate relevance of the respective phenotype-based dimension field to the patient, and a child phenotype vector to recursively define a phenotype-based dimension field, and a cohort selection module to select a set of phenotype vectors that are within a predetermined error from a cohort selection criteria (abstract, fig. 5 and fig. 6).
US 10127359 B2 --> In general, embodiments of the present invention provide systems, methods and computer readable media for a healthcare similarity engine that uses healthcare data to identify a set of similar patients. One aspect of the subject matter described in this specification can be embodied in methods that include the actions of receiving a similarity request including a patient X data vector representing attributes of a particular patient X and a set of similarity parameters; calculating a set of similarity metrics using the patient X data vector and the set of similarity parameters; ranking the population of patients based on their respective similarity metrics; and generating a neighborhood subset of the population of patients most similar to patient X by selecting the top-ranked patients. Another aspect of the subject matter can be embodied in methods that include the actions of providing a display of a graphical representation of a healthcare similarity request input dashboard.
US 20180137177 A1 --> [0022] The list of users, for example, may be returned in the form of a set of user or equipment identifiers. For example, a clinical risk filter may be utilized to identify all patients who have a risk of abdominal sepsis. Filters are instantiated based on parameters extracted from the corresponding processing section. Depending on the application, filters are instantiated through the provisioning of SQL queries, UNIX shell scripts, language integrated query languages (LINQ), multi-dimensional expressions (MDX) queries, among others. In some embodiments, the query device selectively instantiates the filters using specific underlying query languages (e.g., SQL) or frameworks (e.g., .NET) based on the identified classification of filter. In some embodiments, SQL queries can be manually generated. This provides flexibility in tailoring retrieval of data.
US 20200105421 A1-> The system (110) a pre-processing module configured to process clinical datasets (105) and generate a first table having first rows which represent trial subjects and first columns include outcomes of the trial subjects. A second table has the rows representing the trial subjects and columns includes predictors. A graph of interest is selected from the metric graphs. A compressed version of the graph of interest is generated. A first layout of the graph of interest and a second layout of the graph of interest is generated. An automatic search is performed using machine learning algorithms to identify a group of related trial subjects. A user input includes the selected groups of the trial subjects are received through the graphical representation. A statistical analysis of predictors associated with trial subjects within the selected groups of the trial subjects is performed using the second table. A report with results of the statistical analysis is displayed. (abstract)
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JOSHUA DAMIAN RUIZ whose telephone number is (571)272-0409. The examiner can normally be reached 0800-1800.
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, Shahid Merchant can be reached at (571) 270-1360. 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.
/JOSHUA DAMIAN RUIZ/Examiner, Art Unit 3684
/Shahid Merchant/Supervisory Patent Examiner, Art Unit 3684
Prosecution Insights