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 .
Notice to Applicant
This communication is in response to the amendment filed 08/12/2026. Claims 1, 10-11, 13-20 have been amended. Claims 1-20 are presented for examination.
Subject Matter Free of Prior Art
Claim(s) 1-20 are allowable over prior art because the prior art of record fail to expressly teach or suggest, either alone or in combination, the features found within the independent claims, in particular: “at a first time, during an encounter between a patient and the provider…populating a first data request with a patient identifier of the patient, a first time period preceding the encounter, and a first subset of data codes, in the first set of data codes, predicted to return a first quantity of units of patient data within a target duration; transmitting the first data request to a health record database remote from the computer system and containing a corpus of historical patient data; receiving a first set of patient data corresponding to the first subset of data codes, from the health record database responsive to the first data request; and rendering the first set of patient data” (claim 1); “at a first time, preceding an encounter between a patient and the provider…for a first unit of patient data in the first set of patient data, comprising a first data code corresponding to a first evidence type: in response to a first format of the first unit of patient data deviating from a first target format specified for the first evidence type, extracting a first set of metadata from the first unit of patient data; in response to the first set of metadata corresponding to criteria defined by a first set of mapping rules for patient data of the first evidence type: transforming the first set of metadata into a first mapped data unit, in the first target format, based on the first set of mapping rules; and populating a list of mapped patient data with the first mapped data unit; and at a second time, succeeding the first time, during the encounter with the patient…for a second unit of patient data in the second set of patient data, omitting a code linking the second unit of patient data to an evidence type: extracting a second set of metadata from the second unit of patient data: and in response to the second set of metadata exhibiting correspondence with criteria defined by a second set of mapping rules for patient data of a second evidence type: transforming the second set of metadata into a second mapped data unit, in a second target format, based on the second set of mapping rules; and populating the list of mapped patient data with the second mapped data unit; and rendering the list of mapped patient data within the provider portal” (claim 14); “at a first time preceding an encounter between a patient and a provider… for a first unit of patient data, in the first set of patient data, comprising a first data code, in the set of data codes, corresponding to a first evidence type: in response to a first format of the first unit of patient data deviating from a first target format specified for the first evidence type, extracting a first set of metadata from the first unit of patient data; and -in response to the first set of metadata exhibiting correspondence with criteria defined by a first set of mapping rules for patient data of the first evidence type: transforming the first set of metadata into a first mapped data unit, in the first target format, based on the first set of mapping rules; and populating a list of mapped patient data with the first mapped data unit; and at a second time, succeeding the first time, during the encounter with the patient…for each unit of patient data in the second set of patient data, populating the list of mapped patient data with a mapped data unit corresponding to the unit of patient data; and serving the list of mapped patient data to the provider via the provider portal” (claim 20). Because the prior art does not teach or disclose the above features in the specific manner and combinations recited in independent claims 1, 14, 20, claims 1, 14, 20 are hereby deemed to be allowable over prior art. Originally numbered dependent claims 2-13, 15-19 incorporate the allowable features of originally numbered independent claims 1, 14, through dependency, respectively.
However, the claims are still rejected under 101.
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 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more. Based upon consideration of all of the relevant factors with respect to the claims as a whole, the claims are directed to non-statutory subject matter which do not include additional elements that are sufficient to amount to significantly more than the judicial exception because of the following analysis:
Claim 1 is drawn to a method which is within the four statutory categories (i.e., method). Claim 14 is drawn to a method which is within the four statutory categories (i.e., method). Claim 20 is drawn to a method which is within the four statutory categories (i.e., method).
Independent claim 1 recites…at a first time, during an encounter between a patient and the provider; receiving a first patient indicator exhibited by the patient from the provider…; querying a diagnostic model for a first set of possible diagnoses, in a population of diagnoses, for the patient, each diagnoses in the first set of possible diagnoses associated with an evidence type analogous to the first patient indicator; aggregating a first set of evidence types corresponding to the first set of possible diagnoses; aggregating a first set of data codes, each data code in the first set of data codes linked to an evidence type in the first set of evidence types; populating a first data request with a patient identifier of the patient, a first time period preceding the encounter, and a first subset of data codes, in the first set of data codes, predicted to return a first quantity of units of patient data within a target duration; …; and rendering the first set of patient data…; and at a second time, succeeding the first time, during the encounter: populating a second data request, different from the first data request, with the patient identifier; …; and rendering the second set of patient data…
Independent claim 14 recites…at a first time, preceding an encounter between a patient and the provider: accessing a patient identifier of the patient from a patient list representing patients associated with the provider; populating a first data request with the patient identifier, and a first time period preceding the encounter; …; and for a first unit of patient data in the first set of patient data, comprising a first data code corresponding to a first evidence type: in response to a first format of the first unit of patient data deviating from a first target format specified for the first evidence type, extracting a first set of metadata from the first unit of patient data; and in response to the first set of metadata corresponding to criteria defined by a first set of mapping rules for patient data of the first evidence type: transforming the first set of metadata into a first mapped data unit, in the first target format, based on the first set of mapping rules; and populating a list of mapped patient data with the first mapped data unit; and at a second time, succeeding the first time, during the encounter with the patient: populating a second data request with: the patient identifier; and a second time period between the first time and the second time; …; for a second unit of patient data, in the second set of patient data, omitting a code linking the second unit of patient data to an evidence type: extracting a second set of metadata from the second unit of patient data: and in response to the second set of metadata exhibiting correspondence with criteria defined by a second set of mapping rules for patient data of a second evidence type: transforming the second set of metadata into a second mapped data unit, in a second target format, based on the second set of mapping rules; and populating the list of mapped patient data with the second mapped data unit; and rendering the list of mapped patient data; and for a first diagnosis module, in a population of diagnosis modules, corresponding to a first diagnosis: accessing a set of evidence types supporting the first diagnosis; and populating a list of evidence with units of manned patient data, in the list of mapped patient data, linked to the set of evidence types and supporting the first diagnosis for the patient.
Independent claim 20 recites…a method comprising: at a first time preceding an encounter between a patient and a provider: accessing a patient identifier of the patient…; populating a first data request with the patient identifier and a set of data codes, each data code, in the set of data codes, corresponding to an evidence type; …; and for a first unit of patient data, in the first set of patient data, comprising a first data code, in the set of data codes, corresponding to a first evidence type: in response to a first format of the first unit of patient data deviating from a first target format specified for the first evidence type, extracting a first set of metadata from the first unit of patient data; and -in response to the first set of metadata exhibiting correspondence with criteria defined by a first set of mapping rules for patient data of the first evidence type: transforming the first set of metadata into a first mapped data unit, in the first target format, based on the first set of mapping rules; and populating a list of mapped patient data with the first mapped data unit; and at a second time, succeeding the first time, during the encounter with the patient: populating a second data request with: the patient identifier; and a time period defined between the first time and the second time; …; and for each unit of patient data in the second set of patient data, populating the list of mapped patient data with a mapped data unit corresponding to the unit of patient data; and serving the list of mapped patient data to the provider...
Under its broadest reasonable interpretation, the limitations noted above, as drafted, covers certain methods of organizing human activity (i.e., managing personal behavior or relationships or interactions between people…following rules or instructions), but for the recitation of generic computer components. The claims encompass a series of rules or instructions for a person or persons to follow, with or without the aid of a computer, to collect data (i.e., related to a patient), analyze the collected data, and output relevant information (i.e., related to a diagnosis) for a user (i.e., doctor) accordingly in the manner described in the identified abstract idea, supra. The rules or instructions are the claimed steps as indicated supra. That is, other than reciting generic computer components (discussed infra), the claim amounts to managing personal behavior or relationships or interactions between people following rules or instructions. If a claim limitation, under its broadest reasonable interpretation, covers managing personal behavior or relationships or interactions between people, but for the recitation of generic computer components, then it falls within the “Certain Methods of Organizing Human Activity” grouping of abstract ideas. Accordingly, the claims recite an abstract idea.
Claim 1 recites additional elements (i.e., a computer system interfacing with a provider portal executing on a computing device accessed by a provider; transmitting the first data request to a health record database remote from the computer system and containing a corpus of historical patient data; receiving a first set of patient data corresponding to the first subset of data codes, from the health record database responsive to the first data request; transmitting the second data request to the health record database; receiving a second set of patient data from the health record database responsive to the second data request). Claim 14 recites additional elements (i.e., a computer system interfacing with a provider portal executing on a computing device accessed by a provider; transmitting the first data request to a health record database containing a corpus of historical patient data; receiving a first set of patient data responsive to the first data request; transmitting the second data request to the health record database; receiving a second set of patient data responsive to the second data request). Claim 20 recites additional elements (i.e., via a provider portal executing on a computing device accessed by the provider; transmitting the first data request to a health record database containing a corpus of historical patient data; receiving a first set of patient data responsive to the first data request; transmitting the second data request to the health record database; receiving a second set of patient data responsive to the second data request). Looking to the specifications, a computer system interfacing with a provider portal executing on a computing device accessed by a provider is described at a high level of generality (¶ 0022; ¶ 00127), such that it amounts to no more than mere instructions to apply the exception using generic computer components. Also, “transmitting the first data request to a health record database remote from the computer system and containing a corpus of historical patient data; receiving a first set of patient data corresponding to the first subset of data codes, from the health record database responsive to the first data request; transmitting the second data request to the health record database; receiving a second set of patient data from the health record database responsive to the second data request” only invokes the database merely as a tool in its ordinary capacity to perform an existing process (i.e., receiving, storing, providing data), which does not impose meaningful limits on the scope of the claim and amounts to no more than a recitation of the words "apply it" (or an equivalent), and only provides the input data for the performance of the abstract idea, and as such, amounts to insignificant extrasolution activity (i.e., mere data gathering), which does not impose meaningful limits on the scope of the claim. Looking at the limitations as an ordered combination adds nothing that is not already present when looking at the elements individually. The additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. Accordingly, the claims are directed to an abstract idea.
Reevaluated under step 2B, the additional elements noted above do not provide “significantly more” when taken either individually or as an ordered combination. The use of a general purpose computer or computers (i.e., a computer system interfacing with a provider portal executing on a computing device accessed by a provider) amounts to no more than mere instructions to apply the exception using generic computer components and does not impose any meaningful limitation on the computer implementation of the abstract idea, so it does not amount to significantly more than the abstract idea. Also, “transmitting the first data request to a health record database remote from the computer system and containing a corpus of historical patient data; receiving a first set of patient data corresponding to the first subset of data codes, from the health record database responsive to the first data request; transmitting the second data request to the health record database; receiving a second set of patient data from the health record database responsive to the second data request” only invokes the database merely as a tool in its ordinary capacity to perform an existing process (i.e., receiving, storing, providing data), which does not impose meaningful limits on the scope of the claim and amounts to no more than a recitation of the words "apply it" (or an equivalent). Furthermore, receiving or transmitting data over a network has been recognized by the courts as well-understood, routine, and conventional elements/functions. See: MPEP § 2106.05(d)(II). Looking at the limitations as an ordered combination adds nothing that is not already present when looking at the elements individually. The combination of elements does not indicate a significant improvement to the functioning of a computer or any other technology and their collective functions merely provide a conventional computer implementation of the abstract idea. Therefore, there are no limitations in the claims that transform the judicial exception into a patent eligible application such that the claims amount to significantly more than the judicial exception.
Dependent claims 2-13, 15-19 include all the limitations of the parent claims and further elaborate on the abstract idea discussed above and incorporated herein.
Claims 4-9, 11, 15-19 further define the analysis and organization of data for the performance of the abstract idea and do not recite any additional elements. Looking at the limitations as an ordered combination adds nothing that is not already present when looking at the elements individually. Thus, the claims do not integrate the abstract idea into a practical application and do not provide “significantly more.”
Claim 2 further recites the additional elements of “transmitting the third data request to the health record database; receiving a third set of patient data responsive to the third data request,” which only invokes the database merely as a tool in its ordinary capacity to perform an existing process (i.e., receiving, storing, providing data), which does not impose meaningful limits on the scope of the claim and amounts to no more than a recitation of the words "apply it" (or an equivalent), and only provides the input data for the performance of the abstract idea, and as such, amounts to insignificant extrasolution activity (i.e., mere data gathering), which does not impose meaningful limits on the scope of the claim. Reevaluated under step 2B, the aforementioned additional elements still amounts to no more than a recitation of the words "apply it" (or an equivalent). Furthermore, receiving or transmitting data over a network has been recognized by the courts as well-understood, routine, and conventional elements/functions. See: MPEP § 2106.05(d)(II). Also, functional limitations further define the analysis and organization of data for the performance of the abstract idea. Looking at the limitations as an ordered combination adds nothing that is not already present when looking at the elements individually. Thus, the claims as a whole do not integrate the abstract idea into a practical application and do not provide “significantly more.”
Claim 10 further recites the additional elements of “transmitting the first notification to the provider via the provider portal” and “transmitting the second notification to the provider via the provider portal.” Claim 12 further recites the additional elements of “transmitting the second notification to the provider via the provider portal.” Claim 13 further recites the additional elements of “transmitting the first notification to the provider for review.” The “transmitting… via the provider portal” amounts to no more than mere instructions to apply the exception using generic computer components, which does not impose meaningful limits on the scope of the claim and amounts to no more than a recitation of the words "apply it" (or an equivalent), and only provides the output data of the performed abstract idea, and as such, amounts to insignificant extrasolution activity (i.e., post-solution activity), which does not impose meaningful limits on the scope of the claim. Reevaluated under step 2B, the aforementioned additional elements still amounts to no more than mere instructions to apply the exception using generic computer components, which does not impose meaningful limits on the scope of the claim and amounts to no more than a recitation of the words "apply it" (or an equivalent). Furthermore, receiving or transmitting data over a network has been recognized by the courts as well-understood, routine, and conventional elements/functions. See: MPEP § 2106.05(d)(II). Also, functional limitations further define the analysis and organization of data for the performance of the abstract idea. Looking at the limitations as an ordered combination adds nothing that is not already present when looking at the elements individually. Thus, the claims as a whole do not integrate the abstract idea into a practical application and do not provide “significantly more.”
Claim 2 further recites the additional elements of “receiving a third set of patient data responsive to the third data request.” Claim 3 further recites the additional elements of “wherein receiving the first set of patient data comprises receiving a first subset of patient data contained in a health record stored in the health record database and corresponding to the patient,” “wherein receiving the second set of patient data comprises receiving a second subset of patient data contained in the health record,” “wherein receiving the third set of patient data comprises receiving an entirety of the health record recorded within the unbounded time period preceding the first time period.” Claim 10 further recites the additional elements of “receiving a first diagnosis for the patient from the provider via a provider portal executing on a computing device accessed by the provider.” The “receiving” from “the health record database” and “a provider portal executing on a computing device” amounts to no more than mere instructions to apply the exception using generic computer components, which does not impose meaningful limits on the scope of the claim and amounts to no more than a recitation of the words "apply it" (or an equivalent), and only provides the input data for the performance of the abstract idea, and as such, amounts to insignificant extrasolution activity (i.e., mere data gathering), which does not impose meaningful limits on the scope of the claim. Reevaluated under step 2B, the aforementioned additional elements still amounts to no more than mere instructions to apply the exception using generic computer components, which does not impose meaningful limits on the scope of the claim and amounts to no more than a recitation of the words "apply it" (or an equivalent). Furthermore, receiving or transmitting data over a network has been recognized by the courts as well-understood, routine, and conventional elements/functions. See: MPEP § 2106.05(d)(II). Also, functional limitations further define the analysis and organization of data for the performance of the abstract idea. Looking at the limitations as an ordered combination adds nothing that is not already present when looking at the elements individually. Thus, the claims as a whole do not integrate the abstract idea into a practical application and do not provide “significantly more.”
Although the dependent claims add additional limitations, they only serve to further limit the abstract idea by reciting limitations on what the information is and how it is received and used. These information characteristics do not change the fundamental analogy to the abstract idea groupings and, when viewed individually or as a whole, they do not add anything substantial beyond the abstract idea. Furthermore, the combination of elements does not indicate a significant improvement to the functioning of a computer or any other technology. Therefore, the claims when taken as a whole are ineligible for the same reasons as the independent claims.
Response to Arguments
Applicant's arguments filed 08/12/2026 have been fully considered but they are not persuasive. Applicant’s arguments will be addressed hereinbelow in the order in which they appear in the response filed 08/12/2026.
In the remarks, Applicant argues in substance that:
Regarding the 112(b) rejections, the amendments overcome the rejections.
Regarding the 101 rejections,
“the instant Office Action does not identify which specific limitations purportedly recite the abstract idea… The Claims recite structured machine transactions and/or communications between machines and operations on machine- formatted data, such as populating and transmitting data requests to a health record database; receiving units of patient data responsive to these data requests; extracting metadata from units of patient data; and transforming this metadata into target formats according to mapping rules. These limitations describe no interaction between people and no management of personal behavior or relationships. The Applicant further notes that the rationale the instant Office Action provides - "a series of rules or instructions for a person or persons to follow, with or without the aid of a computer" - tracks the "mental processes" grouping defined in MPEP §21o6.04(a)(2), subsection III, rather than the "certain methods of organizing human activity" grouping the rejection names. The rejection therefore pairs the named grouping with a rationale directed to a different grouping, and identifies no limitation falling within either grouping… A person, with or without the aid of a computer, does not populate a data request with data codes, receive data packets from a health record database, or transform metadata into target formats… The Claims recite such improvements, including: " selectively limiting which portions of a patient's electronic health record are accessed based on data codes corresponding to evidence types supporting possible diagnoses identified for the patient, and a first time period preceding the encounter, rather than retrieving an entirety of the health record; " populating each data request with a subset of data codes predicted to return a quantity of units of patient data within a target duration, thereby minimizing a total quantity of data packets received and thus minimizing latency between sending of a data request and receiving of patient data in return, such that the provider portal renders diagnostically-relevant patient data within seconds of a data request rather than waiting on serial transmission of an entirety of a health record; and " transforming units of patient data - received from the health record database in formats deviating from target formats specified for corresponding evidence types, or received without a code linking these units to any evidence type - into mapped data units, thereby enabling a population of diagnosis modules to evaluate patient data that these modules could not otherwise process. In particular, the system isolates a specific subset of patient data captured within a defined time period preceding the encounter, thereby reducing the search space of the database. Additionally, the system implements a corpus of predefined data codes, each data code corresponding to a particular evidence type, such that the computer system requests only patient data corresponding to evidence types supporting possible diagnoses for the patient… the Claims recite how the computer system minimizes latency between transmission of a data request and rendering of patient data for the provider. In particular, the computer system aggregates data codes corresponding to evidence types supporting possible diagnoses for the patient; populates each data request with a subset of these data codes predicted to return patient data within a target duration; and transforms returned units of patient data into mapped data units for evaluation by the population of diagnosis modules. The combination of these limitations reduces a quantity of patient data retrieved, transmitted, and processed for each encounter and therefore provides an improvement in the functioning of a computer, as discussed in MPEP §§ 2106.04(d)(1) and 2106.05(a)… the claimed method provides a specific technical solution to processing electronic health records, reducing unnecessary computation and data transmission, and real-time presentation of diagnostically-relevant patient data… The instant Office Action does not specifically address any of the dependent Claims… Claim 3 recites… a staged retrieval architecture, with specific latency bounds, that the instant Office Action characterizes only as "further defin[ing] the analysis and organization of data." As a further example, Claim 5 recites… autonomous generation of new transformation logic that no person performs, mentally or otherwise”;
“a patient's electronic health record may contain a population (e.g., tens, hundreds, thousands) of data points measured over time… recorded by disparate sources (e.g., different providers, facilities, laboratories, and devices) in disparate formats. The computer system retrieves this patient data under fixed constraints: the health record database returns a bounded quantity of patient data for a data request within a fixed duration, and the diagnosis modules of the diagnostic model evaluate only units of patient data mapped to evidence types in target formats. A data request for an entirety of a health record therefore forces the computer system to wait on a series of transmissions spanning the encounter, and returns patient data that the diagnosis modules cannot evaluate (e.g., units of patient data in deviating formats, or without codes linking these units to evidence types) and patient data that no possible diagnosis for the patient requires (e.g., a fracture recorded decades prior to the encounter). Furthermore, to evaluate possible diagnoses for the patient during the encounter, the computer system must supply the diagnosis modules with mapped, temporally-relevant patient data within a duration bounded by the encounter itself… Accordingly, to surface relevant patient data to the provider in real-time, the computer system selectively queries the health record database based on evidence type, temporal relevance, and predicted quantities of returned patient data, rather than exhaustively scanning the full record… The system thus improves computational efficiency by avoiding exhaustive scanning of large electronic health records during a time-constrained patient encounter. More specifically, the system: limits the first data request to a first time period preceding the encounter and to data codes corresponding to evidence types supporting possible diagnoses for the patient; and populates the first data request with a subset of these data codes predicted to return a first quantity of units of patient data within a target duration. This selective retrieval immediately constrains the search space, reducing database query execution time and memory consumption by preventing unnecessary retrieval of irrelevant historical data (e.g., data captured years prior to the current encounter)… the amended claims improve computer capabilities by reducing the amount of data the system must retrieve, evaluate, and transmit in order to surface diagnostically-relevant evidence in real time… By populating each data request with data codes predicted to return patient data within the target duration, the computer system bounds each transmission and paces its load on the health record database, thereby reducing a quantity of patient data transmitted over the network and minimizing latency for every data request that the health record database serves. Additionally, the system reduces computational resources allocated to retrieval and transmission of patient data by transmitting selectively extracted subsets of supporting evidence, rather than unfiltered or complete patient records to the provider portal. In particular, the system renders, within the provider portal, the list of mapped patient data and lists of evidence supporting diagnoses for the patient, rather than transmitting all patient data evaluated during retrieval, thereby reducing size and frequency of data payloads transmitted to provider devices, decreasing network congestion, and avoiding unnecessary data transfer that does not contribute to diagnostic support…The claimed method provides specific improvements to computational efficiency by: limiting each data request to a time period and to data codes for evidence types supporting possible diagnoses for the patient, thereby reducing database query time and memory consumption; populating each data request with data codes predicted to return patient data within a target duration, thereby reducing a quantity of transmissions between the health record database and the computer system; and transforming returned units of patient data into mapped data units evaluated by the population of diagnosis modules. These limitations impose meaningful constraints on computer implementation by specifying how the system selectively accesses, retrieves, transforms, and renders patient data.”
It is respectfully submitted that Examiner has considered Applicant’s arguments and does not find them persuasive. Examiner has attempted to address all of the arguments presented by Applicant; however, any arguments inadvertently not addressed are not persuasive for at least the following reasons:
In response to Applicant’s argument that (a) regarding the 112(b) rejections, the amendments overcome the rejections:
It is respectfully submitted that Examiner withdraws the aforementioned 112(b) rejections of Office Action dated 03/12/2026 because the amendments have rendered the rejections moot.
However, the claims are still rejected under 101.
In response to Applicant’s argument that (b) regarding the 101 rejections,
“the instant Office Action does not identify which specific limitations purportedly recite the abstract idea… The Claims recite structured machine transactions and/or communications between machines and operations on machine- formatted data, such as populating and transmitting data requests to a health record database; receiving units of patient data responsive to these data requests; extracting metadata from units of patient data; and transforming this metadata into target formats according to mapping rules. These limitations describe no interaction between people and no management of personal behavior or relationships. The Applicant further notes that the rationale the instant Office Action provides - "a series of rules or instructions for a person or persons to follow, with or without the aid of a computer" - tracks the "mental processes" grouping defined in MPEP §21o6.04(a)(2), subsection III, rather than the "certain methods of organizing human activity" grouping the rejection names. The rejection therefore pairs the named grouping with a rationale directed to a different grouping, and identifies no limitation falling within either grouping… A person, with or without the aid of a computer, does not populate a data request with data codes, receive data packets from a health record database, or transform metadata into target formats… The Claims recite such improvements, including: " selectively limiting which portions of a patient's electronic health record are accessed based on data codes corresponding to evidence types supporting possible diagnoses identified for the patient, and a first time period preceding the encounter, rather than retrieving an entirety of the health record; " populating each data request with a subset of data codes predicted to return a quantity of units of patient data within a target duration, thereby minimizing a total quantity of data packets received and thus minimizing latency between sending of a data request and receiving of patient data in return, such that the provider portal renders diagnostically-relevant patient data within seconds of a data request rather than waiting on serial transmission of an entirety of a health record; and " transforming units of patient data - received from the health record database in formats deviating from target formats specified for corresponding evidence types, or received without a code linking these units to any evidence type - into mapped data units, thereby enabling a population of diagnosis modules to evaluate patient data that these modules could not otherwise process. In particular, the system isolates a specific subset of patient data captured within a defined time period preceding the encounter, thereby reducing the search space of the database. Additionally, the system implements a corpus of predefined data codes, each data code corresponding to a particular evidence type, such that the computer system requests only patient data corresponding to evidence types supporting possible diagnoses for the patient… the Claims recite how the computer system minimizes latency between transmission of a data request and rendering of patient data for the provider. In particular, the computer system aggregates data codes corresponding to evidence types supporting possible diagnoses for the patient; populates each data request with a subset of these data codes predicted to return patient data within a target duration; and transforms returned units of patient data into mapped data units for evaluation by the population of diagnosis modules. The combination of these limitations reduces a quantity of patient data retrieved, transmitted, and processed for each encounter and therefore provides an improvement in the functioning of a computer, as discussed in MPEP §§ 2106.04(d)(1) and 2106.05(a)… the claimed method provides a specific technical solution to processing electronic health records, reducing unnecessary computation and data transmission, and real-time presentation of diagnostically-relevant patient data… The instant Office Action does not specifically address any of the dependent Claims… Claim 3 recites… a staged retrieval architecture, with specific latency bounds, that the instant Office Action characterizes only as "further defin[ing] the analysis and organization of data." As a further example, Claim 5 recites… autonomous generation of new transformation logic that no person performs, mentally or otherwise”:
It is respectfully submitted that Applicant argues “the instant Office Action does not identify which specific limitations purportedly recite the abstract idea.” However, Examiner identifies specific limitations as the abstract idea in bullet number 8 of Office Action dated 03/12/2026 and updated above in bullet number 6, which is reproduced below:
Independent claim 1 recites…at a first time, during an encounter between a patient and the provider; receiving a first patient indicator exhibited by the patient from the provider…; querying a diagnostic model for a first set of possible diagnoses, in a population of diagnoses, for the patient, each diagnoses in the first set of possible diagnoses associated with an evidence type analogous to the first patient indicator; aggregating a first set of evidence types corresponding to the first set of possible diagnoses; aggregating a first set of data codes, each data code in the first set of data codes linked to an evidence type in the first set of evidence types; populating a first data request with a patient identifier of the patient, a first time period preceding the encounter, and a first subset of data codes, in the first set of data codes, predicted to return a first quantity of units of patient data within a target duration; …; and rendering the first set of patient data…; and at a second time, succeeding the first time, during the encounter: populating a second data request, different from the first data request, with the patient identifier; …; and rendering the second set of patient data…
Independent claim 14 recites…at a first time, preceding an encounter between a patient and the provider: accessing a patient identifier of the patient from a patient list representing patients associated with the provider; populating a first data request with the patient identifier, and a first time period preceding the encounter; …; and for a first unit of patient data in the first set of patient data, comprising a first data code corresponding to a first evidence type: in response to a first format of the first unit of patient data deviating from a first target format specified for the first evidence type, extracting a first set of metadata from the first unit of patient data; and in response to the first set of metadata corresponding to criteria defined by a first set of mapping rules for patient data of the first evidence type: transforming the first set of metadata into a first mapped data unit, in the first target format, based on the first set of mapping rules; and populating a list of mapped patient data with the first mapped data unit; and at a second time, succeeding the first time, during the encounter with the patient: populating a second data request with: the patient identifier; and a second time period between the first time and the second time; …; for a second unit of patient data, in the second set of patient data, omitting a code linking the second unit of patient data to an evidence type: extracting a second set of metadata from the second unit of patient data: and in response to the second set of metadata exhibiting correspondence with criteria defined by a second set of mapping rules for patient data of a second evidence type: transforming the second set of metadata into a second mapped data unit, in a second target format, based on the second set of mapping rules; and populating the list of mapped patient data with the second mapped data unit; and rendering the list of mapped patient data; and for a first diagnosis module, in a population of diagnosis modules, corresponding to a first diagnosis: accessing a set of evidence types supporting the first diagnosis; and populating a list of evidence with units of manned patient data, in the list of mapped patient data, linked to the set of evidence types and supporting the first diagnosis for the patient.
Independent claim 20 recites…a method comprising: at a first time preceding an encounter between a patient and a provider: accessing a patient identifier of the patient…; populating a first data request with the patient identifier and a set of data codes, each data code, in the set of data codes, corresponding to an evidence type; …; and for a first unit of patient data, in the first set of patient data, comprising a first data code, in the set of data codes, corresponding to a first evidence type: in response to a first format of the first unit of patient data deviating from a first target format specified for the first evidence type, extracting a first set of metadata from the first unit of patient data; and -in response to the first set of metadata exhibiting correspondence with criteria defined by a first set of mapping rules for patient data of the first evidence type: transforming the first set of metadata into a first mapped data unit, in the first target format, based on the first set of mapping rules; and populating a list of mapped patient data with the first mapped data unit; and at a second time, succeeding the first time, during the encounter with the patient: populating a second data request with: the patient identifier; and a time period defined between the first time and the second time; …; and for each unit of patient data in the second set of patient data, populating the list of mapped patient data with a mapped data unit corresponding to the unit of patient data; and serving the list of mapped patient data to the provider...
Applicant argues “The Claims recite structured machine transactions and/or communications between machines and operations on machine- formatted data, such as populating and transmitting data requests to a health record database; receiving units of patient data responsive to these data requests; extracting metadata from units of patient data; and transforming this metadata into target formats according to mapping rules. These limitations describe no interaction between people and no management of personal behavior or relationships.” However, the claim limitations to which Applicant seem to refer as “populating…data requests…extracting metadata from units of patient data; and transforming this metadata into target formats according to mapping rules” are interpreted as rules or instructions for a person or persons to follow, with or without the aid of a computer, to collect data (i.e., related to a patient), analyze the collected data, and output relevant information (i.e., related to a diagnosis) for a user (i.e., doctor) accordingly in the manner described in the identified abstract idea, supra, which amounts to managing personal behavior or relationships or interactions between people following rules or instructions within the “Certain Methods of Organizing Human Activity” grouping of abstract ideas. The claim limitations to which Applicant seem to refer as “transmitting data requests to a health record database; receiving units of patient data responsive to these data requests” are not interpreted as part of the abstract idea, but as additional elements, which only invokes the database merely as a tool in its ordinary capacity to perform an existing process (i.e., receiving, storing, providing data), which does not impose meaningful limits on the scope of the claim and amounts to no more than a recitation of the words "apply it" (or an equivalent), and only provides the input data for the performance of the abstract idea, and as such, amounts to insignificant extrasolution activity (i.e., mere data gathering), which does not impose meaningful limits on the scope of the claim. Looking at the limitations as an ordered combination adds nothing that is not already present when looking at the elements individually.
Applicant argues “"a series of rules or instructions for a person or persons to follow, with or without the aid of a computer" - tracks the "mental processes" grouping defined in MPEP §21o6.04(a)(2), subsection III, rather than the "certain methods of organizing human activity" grouping the rejection names. The rejection therefore pairs the named grouping with a rationale directed to a different grouping, and identifies no limitation falling within either grouping.” However, “a series of rules or instructions for a person or persons to follow, with or without the aid of a computer” can amount to managing personal behavior or relationships or interactions between people following rules or instructions within the “Certain Methods of Organizing Human Activity” grouping of abstract ideas, as Examiner describes, and not the “Mental Processes” grouping, as Applicant now argues. Furthermore, MPEP § 2106.04(a)(2)(II)(C) notes: “a mental process that a neurologist should follow when testing a patient for nervous system malfunctions” is also an “[example] of managing personal behavior recited in a claim.”
Applicant argues “A person, with or without the aid of a computer, does not populate a data request with data codes, receive data packets from a health record database, or transform metadata into target formats.” However, Applicant fails to specify how “A person, with or without the aid of a computer, does not populate a data request with data codes, receive data packets from a health record database, or transform metadata into target formats.” Regardless, per MPEP § 2106.04(a)(2)(II), “It is noted that the number of people involved in the activity is not dispositive as to whether a claim limitation falls within [the "certain methods of organizing human activity"] grouping, as long as the claim recites an abstract idea, which it does, by managing personal behavior or relationships or interactions between people following rules or instructions, as explained above. As stated previously above, the claim limitations to which Applicant seem to refer as “populate a data request with data codes” and “transform metadata into target formats” are interpreted as rules or instructions for a person or persons to follow, with or without the aid of a computer, to collect data (i.e., related to a patient), analyze the collected data, and output relevant information (i.e., related to a diagnosis) for a user (i.e., doctor) accordingly in the manner described in the identified abstract idea, supra, which amounts to managing personal behavior or relationships or interactions between people following rules or instructions within the “Certain Methods of Organizing Human Activity” grouping of abstract ideas, but for the recitation of generic computer components. The claim limitations to which Applicant seem to refer as “receive data packets from a health record database” are not interpreted as part of the abstract idea, but as additional elements, which only invokes the database merely as a tool in its ordinary capacity to perform an existing process (i.e., receiving, storing, providing data), which does not impose meaningful limits on the scope of the claim and amounts to no more than a recitation of the words "apply it" (or an equivalent), and only provides the input data for the performance of the abstract idea, and as such, amounts to insignificant extrasolution activity (i.e., mere data gathering), which does not impose meaningful limits on the scope of the claim. Looking at the limitations as an ordered combination adds nothing that is not already present when looking at the elements individually.
Applicant argues “The Claims recite such improvements, including: " selectively limiting which portions of a patient's electronic health record are accessed based on data codes corresponding to evidence types supporting possible diagnoses identified for the patient, and a first time period preceding the encounter, rather than retrieving an entirety of the health record; " populating each data request with a subset of data codes predicted to return a quantity of units of patient data within a target duration, thereby minimizing a total quantity of data packets received and thus minimizing latency between sending of a data request and receiving of patient data in return, such that the provider portal renders diagnostically-relevant patient data within seconds of a data request rather than waiting on serial transmission of an entirety of a health record; and " transforming units of patient data - received from the health record database in formats deviating from target formats specified for corresponding evidence types, or received without a code linking these units to any evidence type - into mapped data units, thereby enabling a population of diagnosis modules to evaluate patient data that these modules could not otherwise process. In particular, the system isolates a specific subset of patient data captured within a defined time period preceding the encounter, thereby reducing the search space of the database. Additionally, the system implements a corpus of predefined data codes, each data code corresponding to a particular evidence type, such that the computer system requests only patient data corresponding to evidence types supporting possible diagnoses for the patient.” However, the claim limitations to which Applicant seem to refer as providing the alleged improvements (i.e., “selectively limiting which portions of a patient's electronic health record are accessed,” “populating each data request with a subset of data codes,” “transforming units of patient data,” “predefined data codes”) are interpreted as rules or instructions for a person or persons to follow, with or without the aid of a computer, to collect data (i.e., related to a patient), analyze the collected data, and output relevant information (i.e., related to a diagnosis) for a user (i.e., doctor), which is the abstract idea, and not additional elements to be interpreted in Step 2A, Prong Two. Even if the claims provide the alleged improvements of “reducing the search space of the database,” any alleged benefits of the invention are at best, an improvement to rules or instructions for a person or persons to follow, with or without the aid of a computer, to collect data (i.e., related to a patient), analyze the collected data, and output relevant information (i.e., related to a diagnosis) for a user (i.e., doctor) accordingly, which is the abstract idea. However, an improved abstract idea is still an abstract idea and the claims do not provide a technical improvement.
Applicant argues “the Claims recite how the computer system minimizes latency between transmission of a data request and rendering of patient data for the provider. In particular, the computer system aggregates data codes corresponding to evidence types supporting possible diagnoses for the patient; populates each data request with a subset of these data codes predicted to return patient data within a target duration; and transforms returned units of patient data into mapped data units for evaluation by the population of diagnosis modules. The combination of these limitations reduces a quantity of patient data retrieved, transmitted, and processed for each encounter and therefore provides an improvement in the functioning of a computer, as discussed in MPEP §§ 2106.04(d)(1) and 2106.05(a)… the claimed method provides a specific technical solution to processing electronic health records, reducing unnecessary computation and data transmission, and real-time presentation of diagnostically-relevant patient data.” However, there is no nexus between the functionality of the claims and the aforementioned problems and thus, the claims do not reflect the alleged improvements. For example, paragraph [0052] describes “minimizing latency” as a problem addressed by “[populating] this data request with codes configured to return data packets filled to and/or nearly filled to capacity (e.g., a threshold bin size)” and paragraph [0050] describes “[distributing codes] across the data request in a particular distribution”; however, it is noted that the features upon which applicant relies (i.e., “capacity (e.g., a threshold bin size)”) are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993). As stated previously above, the claim limitations to which Applicant seem to refer as providing the alleged improvements (i.e., “aggregates data codes corresponding to evidence types supporting possible diagnoses for the patient; populates each data request with a subset of these data codes predicted to return patient data within a target duration; and transforms returned units of patient data into mapped data units for evaluation by the population of diagnosis modules”) are interpreted as rules or instructions for a person or persons to follow, with or without the aid of a computer, to collect data (i.e., related to a patient), analyze the collected data, and output relevant information (i.e., related to a diagnosis) for a user (i.e., doctor), which is the abstract idea, and not additional elements to be interpreted in Step 2A, Prong Two. Even if the claims provide the alleged improvements of “reduces a quantity of patient data retrieved, transmitted, and processed for each encounter” or “processing electronic health records, reducing unnecessary computation and data transmission, and real-time presentation of diagnostically-relevant patient data,” any alleged benefits of the invention are at best, an improvement to rules or instructions for a person or persons to follow, with or without the aid of a computer, to collect data (i.e., related to a patient), analyze the collected data, and output relevant information (i.e., related to a diagnosis) for a user (i.e., doctor) accordingly, which is the abstract idea. However, an improved abstract idea is still an abstract idea and the claims do not provide a technical improvement.
Applicant argues “The instant Office Action does not specifically address any of the dependent Claims… Claim 3 recites… a staged retrieval architecture, with specific latency bounds, that the instant Office Action characterizes only as "further defin[ing] the analysis and organization of data." As a further example, Claim 5 recites… autonomous generation of new transformation logic that no person performs, mentally or otherwise.” However, as stated previously in Office Action dated 03/12/2026 and updated above, which is reproduced below:
Dependent claims 2-13, 15-19 include all the limitations of the parent claims and further elaborate on the abstract idea discussed above and incorporated herein.
Claims 4-9, 11, 15-19 further define the analysis and organization of data for the performance of the abstract idea and do not recite any additional elements. Looking at the limitations as an ordered combination adds nothing that is not already present when looking at the elements individually. Thus, the claims do not integrate the abstract idea into a practical application and do not provide “significantly more.”
Claim 2 further recites the additional elements of “transmitting the third data request to the health record database; receiving a third set of patient data responsive to the third data request,” which only invokes the database merely as a tool in its ordinary capacity to perform an existing process (i.e., receiving, storing, providing data), which does not impose meaningful limits on the scope of the claim and amounts to no more than a recitation of the words "apply it" (or an equivalent), and only provides the input data for the performance of the abstract idea, and as such, amounts to insignificant extrasolution activity (i.e., mere data gathering), which does not impose meaningful limits on the scope of the claim. Reevaluated under step 2B, the aforementioned additional elements still amounts to no more than a recitation of the words "apply it" (or an equivalent). Furthermore, receiving or transmitting data over a network has been recognized by the courts as well-understood, routine, and conventional elements/functions. See: MPEP § 2106.05(d)(II). Also, functional limitations further define the analysis and organization of data for the performance of the abstract idea. Looking at the limitations as an ordered combination adds nothing that is not already present when looking at the elements individually. Thus, the claims as a whole do not integrate the abstract idea into a practical application and do not provide “significantly more.”
Claim 10 further recites the additional elements of “transmitting the first notification to the provider via the provider portal” and “transmitting the second notification to the provider via the provider portal.” Claim 12 further recites the additional elements of “transmitting the second notification to the provider via the provider portal.” Claim 13 further recites the additional elements of “transmitting the first notification to the provider for review.” The “transmitting… via the provider portal” amounts to no more than mere instructions to apply the exception using generic computer components, which does not impose meaningful limits on the scope of the claim and amounts to no more than a recitation of the words "apply it" (or an equivalent), and only provides the output data of the performed abstract idea, and as such, amounts to insignificant extrasolution activity (i.e., post-solution activity), which does not impose meaningful limits on the scope of the claim. Reevaluated under step 2B, the aforementioned additional elements still amounts to no more than mere instructions to apply the exception using generic computer components, which does not impose meaningful limits on the scope of the claim and amounts to no more than a recitation of the words "apply it" (or an equivalent). Furthermore, receiving or transmitting data over a network has been recognized by the courts as well-understood, routine, and conventional elements/functions. See: MPEP § 2106.05(d)(II). Also, functional limitations further define the analysis and organization of data for the performance of the abstract idea. Looking at the limitations as an ordered combination adds nothing that is not already present when looking at the elements individually. Thus, the claims as a whole do not integrate the abstract idea into a practical application and do not provide “significantly more.”
Claim 2 further recites the additional elements of “receiving a third set of patient data responsive to the third data request.” Claim 3 further recites the additional elements of “wherein receiving the first set of patient data comprises receiving a first subset of patient data contained in a health record stored in the health record database and corresponding to the patient,” “wherein receiving the second set of patient data comprises receiving a second subset of patient data contained in the health record,” “wherein receiving the third set of patient data comprises receiving an entirety of the health record recorded within the unbounded time period preceding the first time period.” Claim 10 further recites the additional elements of “receiving a first diagnosis for the patient from the provider via a provider portal executing on a computing device accessed by the provider.” The “receiving” from “the health record database” and “a provider portal executing on a computing device” amounts to no more than mere instructions to apply the exception using generic computer components, which does not impose meaningful limits on the scope of the claim and amounts to no more than a recitation of the words "apply it" (or an equivalent), and only provides the input data for the performance of the abstract idea, and as such, amounts to insignificant extrasolution activity (i.e., mere data gathering), which does not impose meaningful limits on the scope of the claim. Reevaluated under step 2B, the aforementioned additional elements still amounts to no more than mere instructions to apply the exception using generic computer components, which does not impose meaningful limits on the scope of the claim and amounts to no more than a recitation of the words "apply it" (or an equivalent). Furthermore, receiving or transmitting data over a network has been recognized by the courts as well-understood, routine, and conventional elements/functions. See: MPEP § 2106.05(d)(II). Also, functional limitations further define the analysis and organization of data for the performance of the abstract idea. Looking at the limitations as an ordered combination adds nothing that is not already present when looking at the elements individually. Thus, the claims as a whole do not integrate the abstract idea into a practical application and do not provide “significantly more.”
Although the dependent claims add additional limitations, they only serve to further limit the abstract idea by reciting limitations on what the information is and how it is received and used. These information characteristics do not change the fundamental analogy to the abstract idea groupings and, when viewed individually or as a whole, they do not add anything substantial beyond the abstract idea. Furthermore, the combination of elements does not indicate a significant improvement to the functioning of a computer or any other technology. Therefore, the claims when taken as a whole are ineligible for the same reasons as the independent claims.
For example, “rendering the first set of patient data "within a five-second time window following receipt of the first set of patient data" and receiving "an entirety of the health record recorded within the unbounded time period preceding the first time period" responsive to a third data request - a staged retrieval architecture, with specific latency bounds” and “"accessing a rule-generating model configured to autonomously generate mapping rules based on metadata extracted from units of patient data" and appending the set of mapping rules with a newly-generated mapping rule” only recites more rules or instructions for a person or persons to follow, with or without the aid of a computer, to collect data (i.e., related to a patient), analyze the collected data, and output relevant information (i.e., related to a diagnosis) for a user (i.e., doctor) accordingly in the manner described in the identified abstract idea, supra. As stated previously above, per MPEP § 2106.04(a)(2)(II), “It is noted that the number of people involved in the activity is not dispositive as to whether a claim limitation falls within [the "certain methods of organizing human activity"] grouping, as long as the claim recites an abstract idea, which it does, by managing personal behavior or relationships or interactions between people following rules or instructions, as explained above.
Thus, the claims are directed to an abstract idea and the claim as a whole does not integrate the recited judicial exception into a practical application.
“a patient's electronic health record may contain a population (e.g., tens, hundreds, thousands) of data points measured over time… recorded by disparate sources (e.g., different providers, facilities, laboratories, and devices) in disparate formats. The computer system retrieves this patient data under fixed constraints: the health record database returns a bounded quantity of patient data for a data request within a fixed duration, and the diagnosis modules of the diagnostic model evaluate only units of patient data mapped to evidence types in target formats. A data request for an entirety of a health record therefore forces the computer system to wait on a series of transmissions spanning the encounter, and returns patient data that the diagnosis modules cannot evaluate (e.g., units of patient data in deviating formats, or without codes linking these units to evidence types) and patient data that no possible diagnosis for the patient requires (e.g., a fracture recorded decades prior to the encounter). Furthermore, to evaluate possible diagnoses for the patient during the encounter, the computer system must supply the diagnosis modules with mapped, temporally-relevant patient data within a duration bounded by the encounter itself… Accordingly, to surface relevant patient data to the provider in real-time, the computer system selectively queries the health record database based on evidence type, temporal relevance, and predicted quantities of returned patient data, rather than exhaustively scanning the full record… The system thus improves computational efficiency by avoiding exhaustive scanning of large electronic health records during a time-constrained patient encounter. More specifically, the system: limits the first data request to a first time period preceding the encounter and to data codes corresponding to evidence types supporting possible diagnoses for the patient; and populates the first data request with a subset of these data codes predicted to return a first quantity of units of patient data within a target duration. This selective retrieval immediately constrains the search space, reducing database query execution time and memory consumption by preventing unnecessary retrieval of irrelevant historical data (e.g., data captured years prior to the current encounter)… the amended claims improve computer capabilities by reducing the amount of data the system must retrieve, evaluate, and transmit in order to surface diagnostically-relevant evidence in real time… By populating each data request with data codes predicted to return patient data within the target duration, the computer system bounds each transmission and paces its load on the health record database, thereby reducing a quantity of patient data transmitted over the network and minimizing latency for every data request that the health record database serves. Additionally, the system reduces computational resources allocated to retrieval and transmission of patient data by transmitting selectively extracted subsets of supporting evidence, rather than unfiltered or complete patient records to the provider portal. In particular, the system renders, within the provider portal, the list of mapped patient data and lists of evidence supporting diagnoses for the patient, rather than transmitting all patient data evaluated during retrieval, thereby reducing size and frequency of data payloads transmitted to provider devices, decreasing network congestion, and avoiding unnecessary data transfer that does not contribute to diagnostic support…The claimed method provides specific improvements to computational efficiency by: limiting each data request to a time period and to data codes for evidence types supporting possible diagnoses for the patient, thereby reducing database query time and memory consumption; populating each data request with data codes predicted to return patient data within a target duration, thereby reducing a quantity of transmissions between the health record database and the computer system; and transforming returned units of patient data into mapped data units evaluated by the population of diagnosis modules. These limitations impose meaningful constraints on computer implementation by specifying how the system selectively accesses, retrieves, transforms, and renders patient data”:
Applicant argues “a patient's electronic health record may contain a population (e.g., tens, hundreds, thousands) of data points measured over time… recorded by disparate sources (e.g., different providers, facilities, laboratories, and devices) in disparate formats. The computer system retrieves this patient data under fixed constraints: the health record database returns a bounded quantity of patient data for a data request within a fixed duration, and the diagnosis modules of the diagnostic model evaluate only units of patient data mapped to evidence types in target formats. A data request for an entirety of a health record therefore forces the computer system to wait on a series of transmissions spanning the encounter, and returns patient data that the diagnosis modules cannot evaluate (e.g., units of patient data in deviating formats, or without codes linking these units to evidence types) and patient data that no possible diagnosis for the patient requires (e.g., a fracture recorded decades prior to the encounter).” However, Applicant fails to specify how “the diagnosis modules cannot evaluate… units of patient data in deviating formats, or without codes linking these units to evidence types.” The computing system did not cause the argued problem and thus it is not a technical problem caused by the technological environment to which the claims are confined. Even a technical solution to a non-technical problem does not integrate the judicial exception into a practical application. Applicant’s claims do not recite the invention of improvements to computer functionality, technology, or any other technological field, but the use of generic computer components to collect data (i.e., related to a patient), analyze the collected data, and output relevant information (i.e., related to a diagnosis) for a user (i.e., doctor) accordingly, which is an abstract idea, but for the recitation of generic computer components. While the specification need not explicitly set forth the improvement, the disclosure does not provide sufficient details such that one of ordinary skill in the art would recognize the claimed invention as providing any technical improvement to computer technology, a physical improvement to the computer, or any other technical improvement. See MPEP § 2106.04(d)(1) and 2106.05(a).
Applicant argues “to evaluate possible diagnoses for the patient during the encounter, the computer system must supply the diagnosis modules with mapped, temporally-relevant patient data within a duration bounded by the encounter itself… Accordingly, to surface relevant patient data to the provider in real-time, the computer system selectively queries the health record database based on evidence type, temporal relevance, and predicted quantities of returned patient data, rather than exhaustively scanning the full record… The system thus improves computational efficiency by avoiding exhaustive scanning of large electronic health records during a time-constrained patient encounter. More specifically, the system: limits the first data request to a first time period preceding the encounter and to data codes corresponding to evidence types supporting possible diagnoses for the patient; and populates the first data request with a subset of these data codes predicted to return a first quantity of units of patient data within a target duration. This selective retrieval immediately constrains the search space, reducing database query execution time and memory consumption by preventing unnecessary retrieval of irrelevant historical data (e.g., data captured years prior to the current encounter)… the amended claims improve computer capabilities by reducing the amount of data the system must retrieve, evaluate, and transmit in order to surface diagnostically-relevant evidence in real time… By populating each data request with data codes predicted to return patient data within the target duration, the computer system bounds each transmission and paces its load on the health record database, thereby reducing a quantity of patient data transmitted over the network and minimizing latency for every data request that the health record database serves. Additionally, the system reduces computational resources allocated to retrieval and transmission of patient data by transmitting selectively extracted subsets of supporting evidence, rather than unfiltered or complete patient records to the provider portal. In particular, the system renders, within the provider portal, the list of mapped patient data and lists of evidence supporting diagnoses for the patient, rather than transmitting all patient data evaluated during retrieval, thereby reducing size and frequency of data payloads transmitted to provider devices, decreasing network congestion, and avoiding unnecessary data transfer that does not contribute to diagnostic support…The claimed method provides specific improvements to computational efficiency by: limiting each data request to a time period and to data codes for evidence types supporting possible diagnoses for the patient, thereby reducing database query time and memory consumption; populating each data request with data codes predicted to return patient data within a target duration, thereby reducing a quantity of transmissions between the health record database and the computer system; and transforming returned units of patient data into mapped data units evaluated by the population of diagnosis modules. These limitations impose meaningful constraints on computer implementation by specifying how the system selectively accesses, retrieves, transforms, and renders patient data.” However, the claim limitations to which Applicant seem to refer as providing the alleged improvements (i.e., “supply the diagnosis modules with mapped, temporally-relevant patient data within a duration bounded by the encounter itself,” “selectively queries the health record database based on evidence type, temporal relevance, and predicted quantities of returned patient data,” “limits the first data request to a first time period preceding the encounter and to data codes corresponding to evidence types supporting possible diagnoses for the patient; and populates the first data request with a subset of these data codes predicted to return a first quantity of units of patient data within a target duration,” “populating each data request with data codes predicted to return patient data within the target duration”) are interpreted as rules or instructions for a person or persons to follow, with or without the aid of a computer, to collect data (i.e., related to a patient), analyze the collected data, and output relevant information (i.e., related to a diagnosis) for a user (i.e., doctor), which is the abstract idea, and not additional elements to be interpreted in Step 2B. Furthermore, the alleged improvements seem to be accomplished by “reducing the amount of data the system must retrieve, evaluate, and transmit,” which only processes less data, and not necessarily the same amount of data more efficiently. Even if the claims provide the alleged improvements, any alleged benefits of the invention are at best, an improvement to rules or instructions for a person or persons to follow, with or without the aid of a computer, to collect data (i.e., related to a patient), analyze the collected data, and output relevant information (i.e., related to a diagnosis) for a user (i.e., doctor) accordingly, which is the abstract idea. However, an improved abstract idea is still an abstract idea and the claims do not provide a technical improvement.
Thus, the claim as a whole does not amount to significantly more than the judicial exception.
Thus, Examiner maintains the 101 rejections of claims 1-20, which have been updated to address Applicant’s remarks and to comply with the 2019 Revised Patent Subject Matter Eligibility Guidance and the 2024 Guidance Update on Patent Subject Matter Eligibility, Including on Artificial Intelligence in the above Office Action.
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Emily Huynh whose telephone number is (571)272-8317. The examiner can normally be reached on M-Th 8-5 PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Robert Morgan can be reached on (571) 272-6773.The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/EMILY HUYNH/Primary Examiner, Art Unit 3683
Prosecution Insights