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 .
Response to Arguments
35 U.S.C. § 101 Rejections
Applicant’s arguments on pages 9-12 of the response filed 07/20/2026, with respect to the pending claims 1-33 under 35 U.S.C. § 101, have been fully considered and are not persuasive.
Applicant argues that the Examiner improperly oversimplifies claims 1, 29, and 30 by characterizing the amended operations as a mental process. Applicant particularly contends that transforming data from a predefined schema of a relational database to a dynamic schema of a non-relational database requires machine-executable database operations and therefore cannot practically be performed in the human mind or with pen and paper.
The Examiner respectfully disagrees because the updates-per-amended-claims Prong One analysis does not characterize the claimed relational database, non-relational database, data stores, or their technological implementation as mental processes. Under BRI, the abstract idea identified limitations identified as the exception recite the underlying informational acts of obtaining cohort criteria, retrieving information, reorganizing information from a predefined arrangement into another arrangement, identifying information satisfying specified criteria, compiling selected information, reformatting it into a usable form, and presenting the result. These acts correspond to human searching, comparing, selecting, organizing, and reformatting written information and can practically be performed using written records and pen and paper under MPEP § 2106.04(a)(2)(III). The separately identified database and technological implementation remain part of the claim and are evaluated as additional elements in Prong Two. Accordingly, Applicant’s argument does not overcome the Prong One determination.
Applicant argues that claims 1, 29, and 30 integrate any judicial exception into a practical application because the relational-to-non-relational schema transformation, script-driven retrieval, and subsequent data transformation provide the particular architecture that achieves the specification’s asserted improvement in cohort-selection flexibility, scalability, and speed and resolves the disclosed cohort-selection bottleneck.
The Examiner respectfully disagrees. MPEP § 2106.04(d)(1) requires the claim to include the components or steps providing the asserted technological improvement. Paragraph [0048] describes the bottleneck as delays, back-and-forth coordination, and resources required to generate project-specific datasets; reducing that workflow burden does not itself establish improved database or computer operation. Paragraph [0057] attributes the asserted increase in flexibility, scalability, and speed to implementing second data store 120b as a non-relational presentation database, whereas claim 1 requires the first data store to be non-relational and does not require the second data store to have that architecture. Paragraph [0055] describes the claimed first-store schema transformation but does not identify it as producing the asserted database-performance improvement. Accordingly, Applicant has not shown that the claimed arrangement reflects the particular technological improvement on which the argument relies.
Applicant argues that the interaction of the relational-to-non-relational schema transformation, script-driven retrieval, and second data-store transformation creates an ordered combination that improves the data-processing pipeline rather than merely applying the exception on a generic computer.
The Examiner respectfully disagrees. The sequence requires source data to be transformed for the non-relational first store, a criteria-generated script to retrieve matching information, and the selected data to be transformed for user processing and second-store storage; however, the conversions are defined by their required source and destination representations, and script generation by its criteria input and retrieval result, without specifying an operative mapping, conversion, or criteria-to-executable-instruction technique. As a whole, the elements therefore implement preparation, selection, and delivery of cohort information through the claimed database-and-script workflow rather than improving operation of the databases or another computer technology. Accordingly, the ordered combination does not integrate the exception into a practical application under MPEP §§ 2106.04(d), 2106.05(a), (f), and (g).
Applicant argue that interaction between the relational-to-non-relational schema transformation, the script-driven data retrieval, and the second data store transformation creates an ordered combination that confers a concrete improvement to the data processing pipeline, not merely a generic computer executing abstract steps.
Examiner respectfully disagreed because, claim does not recite a technological improvement, since only recite desire result by invoke generic elements. The new limitation does not change as a whole evaluation since invoking more generic elements and abstract idea not overcome prong two.
35 U.S.C. § 102 and 103 Rejections
Applicant’s arguments, filed on 07/20/2026, pages 14-16, with respect to the pending claims 1-33, have been fully considered but are not persuasive.. The rejections under 35 U.S.C. § 102 is overcome and replace with § 103 rejection see below.
Applicant argues that Claim 1,new limitation is not anticipate by Quinn primary art.
The Examiner respectfully agreed that specifically Quin does not describe relational-to-non-relational query and scheme-transformation implementation, cured with Hagmar see Obvious rational below.
Applicant argues that Quinn does not disclose the generation of a script.
Examiner respectfully disagreed, because “script” is not limited to particular SQL syntax, reasonable encompasses software/API instructions generated to access selected data, Quinn [0116, 0228, 0307-0308, 0311 and 0317] describe groups patient data according to selected parameters, receives ana analytics-developer request for specified patient data, generates an SDK/API for reading data store 330 and permits determination of the fields to be read, therefore Quinn discloses generating data-access instructions responsive to selected data parameters and executing those instructions to access the corresponding selected patient data.
Applicant argues that Quinn is not for assembling cohorts for research studies.
Examiner found applicant argument not substantive, since “for research” identifies the intended purpose of the resulting cohort but does not required an additional research-specific selection step, therefore does not gives meaning and purpose to the limitation.
Applicant argues that while Hagmar teaches mapping data between database formats in a generic data-propagation context, the combination of Quinn and Hagmar fails to teach an integrated, self-service cohort selection pipeline, particularly the combination of (a) transforming at least a portion of the third dataset from a predefined schema of the relational database to a dynamic schema of the non-relational database, (b) generating a script based on exposure/outcome criteria, (c) transforming retrieved data for a second data store, and (d) generating visual representations, all within the context of research cohort selection.
The Examiner respectfully disagrees because non-obviousness cannot be established by attacking the secondary reference individually where the rejection is founded upon the combination of references, Quinn teaches receiving criteria, script-based subset retrieval, metric transformation, and visual chart display (Quinn, paragraphs [0009], [0116], [0124], [0265], [0283]), while Hagmar supplies the relational-to-dynamic non-relational schema conversion via a mapping pipeline and dynamic parser (Hagmar, paragraphs [0028], [0035]–[0036], [0043]–[0047]). A POSITA would have combined these teachings to resolve known storage-format incompatibility (Hagmar, paragraph [0002]), and applicant’s reliance on an integrated, self-service pipeline asserts unclaimed features and non-limiting intended uses that cannot patentably distinguish the claimed operational steps (MPEP §§ 2111.01, 2111.02, 2145(III)). Therefore, the rejection of Claims 1, 29, and 30 is maintained under 35 U.S.C. § 103.
Applicant argues that Delaney, Lucas, Petersen, Hagmar and McCarthy do not cure the deficiencies of Quinn discussed above. Accordingly, these dependent claims are allowable, at a minimum, based on their dependency on the independent claims.
The Examiner respectfully disagrees because independent Claims 1, 29, and 30 are unpatentable under 35 U.S.C. § 103, and the cited secondary references teach each respective additional limitation recited in the dependent claims (MPEP § 2143.03). Specifically, Hagmar explicitly teaches pre-ingestion domain-based data filtering to reduce the amount of data entries to transfer... thereby reducing storage demands on the computing system (Hagmar, paragraphs [0005], [0034], [0053]) as recited in Claim 24, while the other secondary references cure the remaining dependent limitations. Because the independent claims are unpatentable and applicant’s traversal relies solely on dependency without demonstrating how the dependent claims patentably distinguish over the applied prior art combinations, the argument fails to rebut the prima facie case (MPEP § 2145(I)). Therefore, the rejection of Claims 2–20, 24–28, and 31–33 is maintained under 35 U.S.C. § 103.
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-20 and 24-33 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception without significantly more.
Step 1:
The claimed invention is analyzed under 35 U.S.C. 101 to determine if the pending claims belong to at least one of the four statutory categories: process, machine, manufacture, or composition of matter.
Claims 1-20, 24-28, and 31-33 describe a computer-implemented method, categorized as a process.
Claim 29 details a system with a data processor and memory, classified as a machine. Claim 30 refers to a non-transitory computer-readable medium, considered an article of manufacture.
Since each claim fits into a statutory category, the examination moves to Step 2A to assess whether the claims involve a judicial exception.
Step 2A, Prong One
Prong one asks whether the claims language recites a judicial exception.
Independent Claims Analysis
Claims 29 and 30 involve identical receipt, schema conversion, script execution, cohort-dataset creation, data-type conversion, and visual output processes. Claim 29 embeds these in a processor-and-memory system, while claim 30 specifies instructions on a non-transitory medium. These structural differences don't affect the cohort-selection evaluation.
Non-bold language identifies the asserted judicial exception; bold language identifies the additional elements evaluated in Prong Two and Step 2B.
Claim 1:
[1] A computer-implemented method, comprising:
[2] 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;
[3] generating a first dataset for storage at a first data store by at least querying a third data store to retrieve at least a portion of a third dataset stored therein,
[4] wherein the third data store is a relational database and the first data store is a non-relational database, and wherein generating the first dataset comprises transforming at least a portion of the third dataset from a predefined schema of the relational database to a dynamic schema of the non-relational database:
[5] generating, based at least on the one or more cohort selection criteria, a script for accessing the first data store storing the first dataset, wherein the cohort selection criteria comprises one or more parameters indicating exposure and/or outcomes;
[6] 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;
[7] 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;
[8] and generating, for display at the first client device, a visual representation of at least a portion of the second dataset.
Under the Broadest Reasonable Interpretation (BRI), the non-bold language selects and organizes information about individuals according to specified research-cohort criteria, including obtaining the criteria, querying and retrieving stored information, formulating selection instructions, applying the criteria to identify matching individuals, compiling the selected information into a usable form, and presenting the resulting information. See paragraph [0047].
Because a mental process includes concepts that can practically be performed in the human mind or by a human using pen and paper, including observations, evaluations, judgments, and equivalent human mental work, the non-bold language of limitations 2, 3, 5- 8 recites an abstract idea under MPEP § 2106.04(a)(2)(III).
Limitations 2 and 5 recite receiving cohort-selection criteria and formulating access instructions from criteria including exposures or outcomes. Under BRI, these steps amount to obtaining and formulating rules for deciding what information or individuals satisfy specified conditions, which constitutes human evaluation, judgment, and rule formulation.
Limitations 3 and 6 recite querying an underlying repository to retrieve stored information and identifying information corresponding to individuals satisfying the criteria. At the claimed level of generality, these steps amount to searching, collecting, and selecting information according to specified conditions, which can practically be performed using written records and pen and paper.
Limitations 7 and 8 recite compiling the selected information into a cohort dataset, changing data types into a usable form, and generating a visual representation. These steps amount to organizing, reformatting, and presenting selected information, which are equivalent forms of human mental work.
As a whole, the non-bold language mirrors a researcher who receives inclusion/exclusion rules, searches and retrieves records from a storage collection, identifies matching individuals, rewrites the selected information into a suitable format, compiles the cohort information, and prepares a chart, without requiring the separately identified database structures, transformation mechanisms, software, or hardware elements.
Dependent Claims Analysis
The dependent claims below incorporate the independent claims abstract idea, and also recite the following abstract ideas:
Claims 2–6, 9–11, 15–17, 24–25, 27, 31, and 33 further define the abstract information being evaluated or the rules and operations applied to it. They specify participant data, attributes, diseases, endpoints, inclusion/exclusion criteria, mathematical values, duplicate-record resolution, filtering, joining, conditional selection, default covariates, chart forms, or project-specific data content. Under BRI, these limitations further recite evaluating, comparing, selecting, organizing, reformatting, or presenting information according to specified conditions, which are mental processes performable using written records and pen and paper.
Claims 7, 8, 18–20, and 32 further apply the inherited abstract selection rules by identifying records from specified attributes or defaults, modifying criteria, retrieving a corresponding subset, or maintaining the resulting information. Claims 12–14 similarly determine or receive criteria and selectable values, while claim 26 receives modified or additional cohort criteria. These limitations retain the abstract evaluation and selection of information.
Because the claims recite an abstract idea, it would be evaluated through Prong Two below.
Step 2A, Prong Two
Prong Two asks whether claims recite a practical application.
Claims 1, 29, and 30 do not integrate the cohort-selection exception into a practical application. Their additional elements prepare information for evaluation, execute the selection instructions, and store or present the results. As explained below, the claimed relationships provide computer implementation under MPEP 2106.05(f) and supporting input/output activity under MPEP 2106.05(g).
The additional elements are the first client device; three data stores; relational database and non-relational database architectures with predefined-to-dynamic schema transformation (limitation 4); script generation and execution (limitations 5 and 6); and generation of a representation for display (limitation 8). Claims 29 and 30 additionally require a processor, memory, and an instruction-bearing medium.
The first client device and generation of a representation for display supply input and output for the abstract process. The client device obtains selection conditions electronically without altering how information is gathered. Generating a visual representation communicates selected data without altering processing. Under MPEP § 2106.05(g), these activities constitute insignificant extra-solution data gathering and data presentation.
The three data stores (first, second, and third data stores), along with the processor, memory, and instruction-bearing medium, supply generic storage and execution infrastructure. Specification paragraphs [0073]-[0075] describe these through generic instruction-processing components. Under MPEP § 2106.05(d) and (f), generic hardware performing standard storage and execution does not integrate an exception into a practical application.
The relational database, non-relational database, and schema transformation from a predefined schema to a dynamic schema (limitation 4) require data from the third store's predefined relational schema to populate the first store under a dynamic non-relational schema. These are actual structural representation requirements. However, the claim recites each conversion as a desired result (from a predefined schema to a dynamic schema, and into a compatible data type) without reciting an operative mapping algorithm or specialized database conversion mechanism. Under MPEP § 2106.04(d)(1) and § 2106.05(a), the claim fails to demonstrate an improvement to computer or database functionality. Paragraph [0057] of the specification attributes increased flexibility, scalability, and speed to implementing the second data store 120b as a non-relational presentation database, whereas claim 1 requires the first data store to be non-relational and leaves the second data store architecture unspecified. Furthermore, paragraph [0055] describes the schema transformation functionally without identifying any proprietary technical mechanism that improves database software or hardware operation. Under MPEP § 2106.05(f), reciting a desired result without specific technical mechanisms amounts to instructions to apply the exception using generic database.
The generated script and its execution (limitations 5 and 6) connect cohort criteria to retrieval of matching individuals' data. However, the claim defines script generation purely through its input criteria and retrieval purpose, without specifying how criteria are translated into executable access code. Paragraph [0049] describes generation from criteria followed by execution. Under MPEP § 2106.05(f), this functional relationship uses generic software instructions as a tool to execute the abstract evaluation.
The complete database and script setup does not integrate the exception. Claims 1, 29, and 30 describe how additional components work together to transform source data from a predefined relational schema into a flexible non-relational schema, run a criteria-based script on this data, convert the selected data for further processing and storage, and produce a visual output. According to BRI, these steps must be carried out by a machine, but their interaction mainly serves to prepare, select, and present cohort data. While the claims specify particular database types and processing stages, they define the conversions and script creation solely based on their intended results, without detailing any novel technical structure or algorithm that improves computer functioning. Therefore, the combined elements implement an abstract process via software, storage, and input/output, which does not incorporate the exception into a practical application as per MPEP § 2106.04(d) and § 2106.05(f).
Claims 12–14 add interface generation, a first criterion control, selectable record-derived values, and a second criterion control. The records determine the choices available through the controls, and those controls receive selection information for the inherited process. This relationship is considered together with the stores and script: record evaluation supplies the choices, the interface receives the selection, and the script implements it. The claimed contribution remains presenting and obtaining the information used by the exception. Under MPEP 2106.05(a), (f), and (g), specifying those choices and input functions does not establish an interface mechanism that integrates the exception into a practical application.
Claim 26 adds receipt of original and modified or further criteria from respective client devices. The second device supplies another input to the same cohort-selection process. In combination, the devices provide separate sources of selection instructions, while the inherited script and database operations apply those instructions. Because the claimed relationship concerns where the evaluation’s input originates, these additional elements supply electronic data gathering under MPEP 2106.05(g) and computer implementation under MPEP 2106.05(f). They do not alter the Prong Two determination.
Claim 28 adds authentication, active-directory credentials from a secure environment, a project and user management system, and the credential and project-access exchanges. Together, these elements associate user authentication and project-access information with the dataset’s project. The claim specifies the credential source, participating system, and returned information, but leaves authentication functionally stated and does not require its result to govern a cohort-processing operation. Thus, the exchange supplies a supporting authentication service for the computing environment. Under MPEP 2106.05(a) and (f), the claimed relationship does not establish either an authentication improvement or another meaningful application of the cohort-selection exception.
Claims 7, 8, 18–20, and 32 further direct the inherited script and stores through attribute-based selection, revised criteria, updated retrieval, retention or replacement of datasets, and default-based script generation. Their computer operations implement the informational rules identified in Prong One and retain the functions addressed above. Claims 2–6, 9–11, 15–17, 27, 31, and 33 further limit the identified abstract information or operations without adding a separate integrating element.
Therefore, merely using the additional elements explained above to apply the abstract idea without showing improvement to a technology recited functionally, as desired outputs are not enough to overcome prong two.
Thus, claims are evaluated below in the scope of step 2 B.
Step 2B
Step 2B asks whether the claims recite inventive concept.
Claims 1, 29, and 30 do not provide significantly more than the exception identified in Prong One, because:
The client-input receipt and generation of a representation for display remain insignificant supporting activities. Specification paragraph [0075] identifies a keyboard and/or pointing device and a display unit for displaying graphical user interfaces; paragraph [0076] describes network communication through Ethernet or other networking ports. These familiar components are described through their established input, output, and communication functions, supporting conventional implementation under MPEP 2106.07(a)(III)(A). MPEP 2106.05(d)(II) additionally identifies Receiving or transmitting data over a network as a recognized conventional function. At the claimed level, these operations obtain the selection criteria and present the resulting information. Refer to Electric Power Group, LLC v. Alstom S.A., 830 F.3d 1350, 1354-55 (Fed. Cir. 2016),
The data stores, processor, memory, and instruction-bearing medium likewise supply storage and execution facilities. MPEP 2106.05(d)(II) identifies electronic recordkeeping and storing and retrieving information in memory as conventional functions, citing Alice and Versata. Specification paragraphs [0074]–[0075] describe executing stored instructions and maintaining information, while paragraph [0078] permits a processor that can be special or general purpose. These disclosures support the generic character of the basic storage and execution functions required by claims 1, 29, and 30. Because those functions hold the datasets and execute the selection instructions, they do not individually supply an inventive concept. MPEP 2106.05(d), (f).
Relational and non-relational database storage are conventional, well-understood mechanisms, as recognized in MPEP § 2106.05(d)(II). Courts have affirmed that basic computer functions like storing, retrieving, and organizing data do not constitute an inventive concept, as seen in Alice Corp. v. CLS Bank and Versata Dev. Group v. SAP. The specification par. 0050, 0075-0077 confirm that the claimed databases are typical storage mechanisms, describing hardware and standard applications for data management. These structures perform routine data retention and access without modifying hardware, thus failing to meet the inventive concept requirement under MPEP § 2106.05(d).
The schema transformation (limitation 4), script generation and execution (limitations 5 and 6), and transformation lack an inventive concept under MPEP § 2106.05(f) because they describe only functional results without specific technical mechanisms. According to MPEP § 2106.05(f), claiming a desired outcome without a corresponding technical process or algorithmic detail amounts to instructions for implementing an abstract idea on a computer. Cases such as Electric Power Group v. Alstom S.A. and Two-Way Media Ltd. illustrate that claims only stating results without defining how to achieve them or specifying technical means fail to establish an inventive concept. The operations in spec 0055 are defined solely by their intended outcomes, not by technical structures.
Under MPEP § 2106.05(a), the combination does not demonstrate a technological improvement. The specification identifies the problem as an administrative research bottleneck, specifically manual coordination delays and labor involved in generating cohort datasets (paragraphs [0004], [0048]); automating this workflow does not enhance computer functionality. Importantly, claim 1 does not embody the claimed technological solution. Paragraph [0057] attributes increased flexibility, scalability, and speed to implementing the second data store 120b as a non-relational database. However, claim 1 requires the first data store to be non-relational, with the second store unspecified. Paragraph [0055] describes schema conversion only in functional terms. Since the conversions and script operations are recited solely by their desired outcomes, chaining them together amounts to an instruction to perform the abstract process under MPEP § 2106.05(e) and (f), which fails to provide an inventive concept under Step 2B.
Dependent Claims Analysis:
Claims 12–14 add interface generation and input controls, including record-derived choices and a second criterion control. Their input implementation is reconsidered under MPEP 2106.05(d) and (g). Paragraph [0061] describes a series of drop-down menus and search functions, and paragraph [0075] supplies the keyboard, pointing device, and graphical display. This disclosure supports conventional mechanisms for presenting choices and receiving selections under MPEP 2106.07(a)(III)(A). The record-derived criteria and values remain the evaluation identified in Prong One; the controls present and receive that information. Together with the inherited processing, they implement the selection through those input mechanisms and do not supply significantly more. MPEP 2106.05(f)–(g). Refer to Electric Power Group MPEP 2106.05(d).
Claim 26 adds receipt of modified or further criteria from a second client device. Paragraphs [0073]–[0076] describe client devices implemented with instruction-processing, input/output, and networking components. Together with the network-receipt authority in MPEP 2106.05(d)(II), this supports conventional receipt of selection information from the additional endpoint. Both devices supply criteria to the inherited evaluation; their claimed interaction adds another input source rather than another processing mechanism. Reconsidered individually and with the inherited elements, this receipt remains supporting data gathering under MPEP 2106.05(g) and does not supply significantly more.
Claim 28 adds authentication using active-directory credentials from a secure environment and exchanges with a project and user management system. Paragraph [0064] describes sending credentials and receiving project information, including clients with access. The claim identifies the credential source, participating system, and returned information, while stating authentication through those functional exchanges. In the claimed combination, this service associates authentication and project-access information with the cohort project; it does not specify a verification mechanism or an operative relationship through which authentication changes the inherited processing. Under MPEP 2106.05(f)(1), this functionally stated supporting service does not add significantly more.
The remaining dependent limitations retain the abstract refinements identified in Prong One. Claims 7, 8, 18–20, and 32 further direct the inherited script and stores to apply attributes or defaults, execute revised criteria, and retain or replace datasets. Their required computer operations implement those informational rules through the storage and execution functions addressed above. Considered with the inherited arrangement, these refinements do not supply an inventive concept, and the Step 2B determination remains unchanged.
Considering claims 1–20 and 24–33 as a whole, the additional elements do not supply significantly more because their claimed cooperation remains directed to implementing the cohort-selection evaluation rather than producing a different technological operation. Nothing in the claimed combinations changes how the underlying computer, database, interface, or authentication technology operates; instead, each element contributes its assigned function to obtaining, selecting, organizing, storing, or presenting the cohort information. Thus, even when considered in their ordered combinations, the additional elements implement the identified abstract process rather than create an inventive technological arrangement, and claims 1–20 and 24–33 do not recite significantly more under Step 2B.
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.
Claim(s) 1-3, 5, 7-10, 1220, 25-27 and 29-33 are rejected under 35 U.S.C. 103 as being obvious by Quinn et al. - US 2021/0049719 and further view of Hagmar et al. (US 2019/0370409 A1)
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 a first dataset for storage at a first data store by at least querying a third data store to retrieve at least a portion of a third dataset stored therein, ; (Quinn, par. 0101, 0107, 0116, 0124, 0125, 0265)
Quinn describe health-data framework that stores information about individual patients, imported data from HIE/HER and received data store.
generating, based at least on the one or more cohort selection criteria, a script for accessing the first data store storing the 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.
A POSITA would have combined before the filing date Quinn with Hagmar by modifying Quinn’s data aggregation pipeline to implement incoming data retrieval from a relational source and transformation into a non-relational destination store via Hagmar’s mapping pipeline and parser, which would have predictably resulted in populating Quinn’s central store from heterogeneous sources while resolving format mismatches.
A POSITA would have been motivated to apply Hagmar’s mapping to Quinn’s incoming data to address the known technical problem of integrating data from repositories having incompatible storage format, Hagmar par. [0002], [0040], while accommodating varied source fields in the destination. Because Quinn already aggregates heterogeneous health information across disparate systems, par. [0107], [0116], configuring the disclosed parser and mapping pipeline for the selected relational source and dynamic non-relational destination would predictably populate the destination for Quinn’s subsequent cohort analysis, with a reasonable expectation of success because Hagmar's components perform that exact conversion function, Hagmar par. [0035]–[0036] and [0043]–[0047].
Note: Claim 29-30 are rejected by the same analysis above to be very similar.
Claim 2.
Quinn in combination with Hagmar 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 in combination with Hagmar 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 in combination with Hagmar 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 in combination with Hagmar 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 in combination with Hagmar 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 in combination with Hagmar 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 in combination with Hagmar 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 in combination with Hagmar 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 in combination with Hagmar 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 in combination with Hagmar 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 in combination with Hagmar 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 in combination with Hagmar 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 in combination with Hagmar 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 in combination with Hagmar 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 in combination with Hagmar 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 in combination with Hagmar 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 25.
Quinn in combination with Hagmar 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 in combination with Hagmar 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 in combination with Hagmar 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 in combination with Hagmar 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 in combination with Hagmar 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.
Quinn in combination with Hagmar teaches, 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(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 Hagmar et al. US 2019/0370409 A1 and in further combination with Delaney et al. - US20240161883A1
Claim 4.
Quinn in combination with Hagmar 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.
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 Hagmar - US 2019/0370409 and in further combination with US-10957433-B2– Lucas
Claim 6.
Quinn in combination with Hagmar 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]
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 Hagmar - US 2019/0370409 and in further combination with Petersen et al. - US20210019296A1
Claim 11. Quinn in combination with Hagmar 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) 24 is rejected under 35 U.S.C. 103 as being unpatentable over Quinn et al. - US 2021/0049719 A1 in further combination Hagmar - US 2019/0370409 and in further combination with Hagmar et al. - US20190370409A1.
Claim 24.
Quinn in combination with Hagmar 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 in further combination Hagmar - US 2019/0370409 and 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
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any 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 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.
/J.D.R./Examiner, Art Unit 3684
/Shahid Merchant/Supervisory Patent Examiner, Art Unit 3684
