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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 05/18/2026 has been entered.
Claims 1-2, 4-16 and 18-23 remain pending in this application.
The claim objection of claim 1 has been withdrawn in light of the amendments.
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-2, 4-16 and 18-23 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Step 1:
Claims 1-2, 4-16, 18 are drawn to a system which is within the four statutory categories (i.e. machine). Claims 19-23 are drawn to a method which is within the four statutory categories (i.e. process).
Step 2A, Prong 1:
Claims 1 and 19 have been amended to recite:
“receiving, at a first intermediary system of a health data platform, a first set of patient records from a first health system, wherein each of the patient records in the first set of patient records is in a first format;
receiving, at a second intermediary system of the health data platform, a second set of patient records from a second health system, wherein each of the patient records in the second set of patient records is in a second format different from the first format;
processing the first set of patient records at the first intermediary system, wherein the processing includes: (1) in a data normalization zone of the first intermediary zone, converting the first set of patient records into a common format that is different from the first format and the second format, and (2) in a de-identification zone of the first intermediary zone, generating a first set of de-identified records from the converted first set of patient records, …
for each patient record of the converted first set of patient records, selecting one or more identifiers of the patient record, generating a token based on the selected one or more identifiers of the patient record, adding the generated token to the patient record, based on the tokens, match the patient record to one or more different records belonging to the same patient to generate a unified patient record, and
generalizing a first value in the patient record by replacing the first value with a range of values;
processing the second set of patient records at the second intermediary system, wherein the processing includes: (1) converting the second set of patient records into the common format, and (2) generating a second set of de-identified records from the converted second set of patient records;
transmitting the first and second sets of de-identified records to a common data repository of a common data zone of the health data platform, wherein the common data repository is configured to store de-identified records from a plurality of different health systems;…”.
The limitations of “receiving the first set of patient records, processing the patient records by converting them into a common format, generating a first set of de-identified records from the converted first set of patient records, processing the second set of patient records by converting them into a common format and generating a second set of de-identified records from the converted second set of patient records” are directed to an abstract idea of certain methods of organizing human activity. This is a method of managing interactions between people (such as, user following rules and instructions). The mere nominal recitation of data platform (including one or more processors and a memory) does not take the claims out of the methods of organizing human interactions grouping. Thus, claims recite an abstract idea.
After considering all claim elements, both individually and in combination and in ordered combination, it has been determined that the claims do not amount to significantly more than the abstract idea itself.
Claims 2, 4-16, 18 and 20-23 are ultimately dependent from claims 1, 19 and include all the limitations of claims 1, 19. Therefore, claims 2, 4-16, 18 and 20-23 recite the same abstract idea. Claims 2, 4-16, 18 and 20-23 describe a further limitation regarding converting the set of patient records into a common format, and generating a set of de-identified records from the set of patient records. These are all just further describing the abstract idea recited in claims 1, 19, without adding significantly more.
Step 2A, Prong 2:
This judicial exception is not integrated into a practical application. In particular, claims recite the additional elements that are provided in “bolded” format below:
(Currently Amended) A computing system for aggregating health data from a plurality of health data providers, the computing system comprising: one or more processors; and a memory operably coupled to the one or more processors and storing instructions that, when executed by the one or more processors, cause the computing system to perform operations comprising: receiving, at a first intermediary zone of a health data platform, a first set of patient records from a health data provider, wherein each of the patient records in the first set of patient records is in a first format, and wherein the first intermediary zone has a first set of access controls that define data isolation boundaries tailored to a sensitivity level of data within the first intermediary zone, receiving, at a second intermediary zone of the health data platform, a second set of patient records from a second health data provider, wherein each of the patient records in the second set of patient records is in a second format different from the first format, and wherein the second intermediary zone has a second set of access controls that define data isolation boundaries tailored to a sensitivity level of data within the second intermediary zone, wherein the second set of access controls are different from the first set of access controls such that the first intermediary zone and second intermediary zone are isolated from one another, processing the first set of patient records at the first intermediary zone, wherein the processing includes: (1) in a data normalization zone of the first intermediary zone, converting the first set of patient records into a first set of normalized records, each normalized record having a uniform format that is different from the first format and the second format, and (2) in a de-identification zone of the first intermediary zone, generating a first set of de-identified records from the first set of normalized records, wherein the data normalization zone is configured with access controls that are more stringent relative to the de-identification zone, wherein generating the first set of de-identified records from the first set of normalized patient records comprises, for each patient record of the first set of normalized patient records; generating a plurality of tokens for the patient record, wherein generating each token for the patient record comprises selecting one or more identifiers of the patient record, generating a token based on the selected one or more identifiers of the patient record, adding the generated token to the patient record, and based on the tokens, match the patient record to one or more different records belonging to the same patient to generate a unified patient record, and generalizing a first value in the patient record by replacing the first value with a range of values, processing the second set of patient records at the second intermediary zone, wherein the processing includes: (1) converting the second set of patient records into a second set of normalized records, and (2) generating a second set of de-identified records from the second set of normalized records, transmitting the first and second sets of de-identified records to a common data repository of a common data zone of the health data platform, wherein the common data repository is configured to store de-identified records from a plurality of different health data providers, wherein the common data zone has a third set of access controls that define data isolation boundaries tailored to a sensitivity level of data within the common data zone, and wherein the third set of access controls are different from the first and second sets of access controls, and providing remote access to users over a network to the common data repository so the users can access the first and second sets of de-identified records in real time in the uniform format.
2. (Original) The computing system of claim 1, wherein the health data platform includes a plurality of intermediary zones, each intermediary zone being configured to receive data from a respective health data provider of the plurality of different health data providers.
4. (Original) The computing system of claim 2, wherein each intermediary zone is customized for the respective health data provider.
5. (Previously Presented) The computing system of claim 1, wherein the receiving, converting, and generating occur over at least two different data zones within each intermediary zone.
6. (Currently Amended) The computing system of claim 5, wherein: the receiving occurs at a first data zone within the first intermediary zone; the converting occurs at the data normalization zone, which is a second data zone within the first intermediary zone; and the generating occurs at the de-identification zone, which is a third data zone within the first intermediary zone.
7. (Previously Presented) The computing system of claim 6, wherein: the first data zone includes a first database configured to store the first set of patient records; the second data zone includes a second database configured to store the first set of normalized records; and the third data zone includes a third database configured to store the first set of de-identified records.
8. (Previously Presented) The computing system of claim 6, wherein the first health data provider is a health system including a plurality of care sites and the first intermediary zone includes a plurality of first data zones, each first data zone configured to receive patient records from a corresponding care site.
9. (Previously Presented) The computing system of claim 1, wherein the first set of patient records are received in a health system-specific format.
10. (Previously Presented) The computing system of claim 1, wherein the operations further comprise cleansing the first set of patient records.
11. (Previously Presented) The computing system of claim 1, wherein converting the first set of patient records into the first set of normalized records comprises enhancing at least some of the patient records with additional data.
12. (Previously Presented) The computing system of claim 1, wherein each normalized record includes one or more patient identifiers, and generating each set of de-identified records comprises one or more of removing or modifying at least some of the patient identifiers in each normalized record.
13. (Previously Presented) The computing system of claim 12, wherein generating each set of de- identified records comprises producing one or more tokens from at least some of the patient identifiers in each normalized record.
14. (Original) The computing system of claim 1, wherein each de-identified record in the common data repository is in the uniform format.
15. (Original) The computing system of claim 1, wherein the operations further comprise transmitting a subset of the de-identified records stored in the common data repository to a shipping zone.
16. (Original) The computing system of claim 15, wherein the shipping zone includes a plurality of user data zones, each user data zone configured for access by a respective user.
18. (Previously Presented) The computing system of claim 1, wherein each intermediary zone includes at least one audit interface configured to allow the health data provider to monitor the intermediary zone.
19. (Currently Amended) A method for aggregating health data from a plurality of health systems, the method comprising: receiving, at a first intermediary system of a health data platform, a first set of patient records from a health system, wherein each of the patient records in the first set of patient records is in a first format; receiving, at a second intermediary system of the health data platform, a second set of patient records from a second health system, wherein each of the patient records in the second set of patient records is in a second format different from the first format; processing the first set of patient records at the first intermediary system, wherein the processing includes: (1) in a data normalization zone of the first intermediary zone, converting the first set of patient records into a common format that is different from the first format and the second format, and (2) in a de-identification zone of the first intermediary zone, generating a first set of de-identified records from the converted first set of patient records, wherein the data normalization zone is configured with access controls that are more stringent relative to the de-identification zone, wherein generating the first set of de-identified records from the converted first set of patent records comprises, for each patient record of the converted first set of patient records; selecting one or more identifiers of the patient record, generating a token based on the selected one or more identifiers of the patient record, adding the generated token to the patient record, based on the tokens, match the patient record to one or more different records belonging to the same patient to generate a unified patient record, and generalizing a first value in the patient record by replacing the first value with a range of values; processing the second set of patient records at the second intermediary system, wherein the processing includes: (1) converting the second set of patient records into the common format, and (2) generating a second set of de-identified records from the converted second set of patient records; and transmitting the first and second sets of de-identified records to a common data repository of a common data zone of the health data platform, wherein the common data repository is configured to store de-identified records from a plurality of different health systems; and providing remote access to users over a network to the common repository so the users can access the first and second set of de- identified records in real time in the common format.
20. (Previously presented) The method of claim 19, wherein the second intermediary system includes a plurality of data processing subsystems, wherein the plurality of data processing subsystems includes: a first data handling subsystem configured to receive the second set of patient records; a second data handling subsystem configured to convert the second set of patient records into the common format; and a third data handling subsystem configured to generate the second set of de-identified records from the second set of patient records.
21. (Original) The method of claim 19, further comprising: receiving a request from a user to access a subset of the de-identified records in the common data repository; and transmitting the subset of the de-identified records to a shipping zone separate from the common data repository.
22. (Previously presented) The method of claim 21, further comprising: generating a first search result by executing a query on the set of de-identified records at the second intermediary system, generating a second search result by executing the query on the de-identified records from the plurality of the different health systems stored in the common data repository, and comparing the first and second search results.
23. (Previously presented) The method of claim 19, further comprising: storing, at the first intermediary system of the health data platform, the first set of patient records from the health system; providing remote access to users over a network the network so that any one or more of the users can provide at least one updated patient record in real time through an interface, wherein at least one of the users provides an updated patient record in a format other than the common format, wherein the format other than the common format is dependent on hardware and software platform used by the at least one user; converting the at least one updated patient record into the common format; generating a set of at least one de-identified record from the converted at least one updated patient record; storing, at the first intermediary system, the generated set of at least one de-identified record; after storing, at the first intermediary system, the generated set of at least one de-identified record, generating a message containing the generated set of at least one de- identified record; and transmitting the generated message to one or more users over the network in real time, so that the one or more users have access to the updated patient record.
These additional elements correspond to hardware and software elements, these limitations are not enough to qualify as “practical application” being recited in the claims along with the abstract idea since these elements are merely invoked as a tool to apply instructions of the abstract idea in a particular technological environment, and mere instructions to apply/implement/automate an abstract idea in a particular technological environment and merely limiting the use of an abstract idea to a particular field or technological environment do not provide practical application for an abstract idea (MPEP 2106.05(f) & (h)).
The claim steps are recited as being performed by ”one or processors” and “memory”, which are recited at a high level of generality and amounts to no more than mere instructions to apply the exception using a generic computer. The current specification recites “…The health data platform 102 can be implemented by one or more computing systems or devices having software and hardware components (e.g., processors, memory) configured to perform the various operations described herein. …” in [0016] and “…The method 200 can be performed by any embodiment of the systems and devices described herein, such as by a computing system or device including one or more processors and a memory storing instructions that, when executed by the one or more processors, cause the computing system or the device to perform some or all of the steps described herein….” in [0050]. Therefore, ”one or processors” and “memory” are directed to generic computing devices.
Accordingly, these 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. The claims are directed to an abstract idea.
Step 2B:
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional element of using one or more processors to perform converting, generating, storing and transmitting steps amounts to no more than mere instructions to apply the exception using a generic computer component. Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept.
Additionally, claims have been amended to recite “processing the set of patient records at the intermediary zone, wherein the processing includes: (1) converting the set of patient records into a set of normalized records, each normalized record having a uniform format that is different from the first format”, which corresponds to well-understood, routine and conventional activity in the field (see 2106.05(d)), as evidenced by the applied prior art, Eisenberger. In particular, Eisenberger discloses “…the application programs 254 include one or more of a message format standardization module 220 that can convert, map and/or parse patient data into a patient message format,…” in col. 14, lines 10-19. Accordingly, claims are directed to mere instruction to apply an exception.
The claims are not patent eligible.
Response to Arguments
Applicant's arguments filed 05/18/2026 have been fully considered but they are not persuasive. Applicant’s arguments will be addressed below in the order in which they appear.
Applicant argues that the current claims are not directed to “managing personal behavior or relationships or interactions between people”, such as “following rules or instructions”. Applicant argues that the current claims are directed to a system for securely generating normalized and aggregated health data while protecting patient privacy.
In response, Examiner submits that, as discussed in the rejection above, the limitations of “receiving the first set of patient records, processing the patient records by converting them into a common format, generating a first set of de-identified records from the converted first set of patient records, processing the second set of patient records by converting them into a common format and generating a second set of de-identified records from the converted second set of patient records” are directed to an abstract idea of certain methods of organizing human activity. This is a method of managing interactions between people (such as, user following rules and instructions). The features of generating tokens and matching the tokens with the patient record to generate a unified patient record is not part of the abstract idea rejection. These features are directed to additional elements that are covered in the section Step 2A, prong 2 above.
Applicant argues that claims as a whole recite more than merely an abstract idea and instructions to “apply it”.
In response, Examiner submits that the additional elements correspond to hardware and software elements and these elements are merely invoked as a tool to apply instructions of the abstract idea in a particular technological environment, and mere instructions to apply/implement/automate an abstract idea in a particular technological environment. The claim steps are recited as being performed by ”one or processors” and “memory”, which are recited at a high level of generality and amounts to no more than mere instructions to apply the exception using a generic computer. The current specification recites “…The health data platform 102 can be implemented by one or more computing systems or devices having software and hardware components (e.g., processors, memory) configured to perform the various operations described herein. …” in [0016] and “…The method 200 can be performed by any embodiment of the systems and devices described herein, such as by a computing system or device including one or more processors and a memory storing instructions that, when executed by the one or more processors, cause the computing system or the device to perform some or all of the steps described herein….” in [0050]. Therefore, ”one or processors” and “memory” are directed to generic computing devices.
Therefore, the arguments are not persuasive and claims are rejected under 35 U.S.C. §101 as being directed to non-statutory subject matter.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DILEK B COBANOGLU whose telephone number is (571)272-8295. The examiner can normally be reached 8:30-5:00 ET.
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, Obeid Mamon can be reached at (571) 270-1813. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/DILEK B COBANOGLU/Primary Examiner, Art Unit 3687
Prosecution Insights