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 .
This communication is in response to the amendment received on 11/06/2025. Claims 1-16 and 18-24 remain pending in this application.
Claim Objections
Claims 1 is objected to because of the following informalities: Claim 1 has been amended to recite “…generating a plurality of tokens for the patient record, wherein generating each token for the patent record comprises…” in lines 29-30. Examiner considers that there is a typographical error and claims should recite “patient record” instead of “patent record”. Appropriate correction is required.
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-16 and 18-24 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-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). Claim 24 is drawn to a non-transitory media which is within the four statutory categories (i.e. manufacture).
Step 2A, Prong 1:
Claims 1, 19 and 24 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) converting the first set of patient records into a common format that is different from the first format and the second format, and (2) 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, 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…”.
These claims correspond to 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-16, 18 and 20-23 are ultimately dependent from claims 1, 19 and include all the limitations of claims 1, 19. Therefore, claims 2-16, 18 and 20-23 recite the same abstract idea. Claims 2-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, processing the first set of patient records at the first intermediary zone, wherein the processing includes: (1) 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) generating a first set of de-identified records from the first set of normalized records, 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 patent 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 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.
3. (Original) The computing system of claim 2, wherein the plurality of intermediary zones are isolated from each other.
4. (Original) The computing system of claim 2, wherein each intermediary zone is customized for the respective health data provider.
5. (Currently Amended) 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 a second data zone within the first intermediary zone; and the generating occurs at a third data zone within the first intermediary zone.
7. (Currently Amended) 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. (Currently Amended) 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. (Currently Amended) The computing system of claim 1, wherein the first set of patient records are received in a health system-specific format.
10. (Currently Amended) The computing system of claim 1, wherein the operations further comprise cleansing the first set of patient records.
11. (Currently Amended) 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. (Currently Amended) 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. (Currently Amended) 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. (Currently Amended) 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) converting the first set of patient records into a common format that is different from the first format and the second format, and (2) generating a first set of de-identified records from the converted first set of patient records, 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, 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.
24. (Currently Amended) One or more non-transitory computer-readable storage media comprising instructions that, when executed by one or more processors of a computing system, cause the computing system to perform operations comprising: receiving, at first intermediary zone of a health data platform, a first set of patient records from a first health system, each of the patient records of the first set of patient records being in a first schema;
receiving, at a second intermediary zone of the health data platform, a second set of patient records from a second health system, each of the patient records of the second set of patient records being in a second schema different from the first schema; converting the first set of patient records into a first set of normalized records, each normalized record being in a uniform schema that is different from the first schema and the second schema; converting the second set of patient records into a second set of normalized records; generating a set of de-identified records from the first and second sets of normalized records, wherein generating the set of de-identified records from the first and second sets of normalized records comprises: for each patient record of the first and second sets of normalized 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, and generalizing a first value in the patient record by replacing the first value with a range of values; transmitting the set of de-identified records to a common zone of the health data platform, wherein the common zone 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 set of de-identified records in real time in the uniform schema.
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 11/06/2025 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 claims recite a technology that provides an improved system for collecting, storing, and providing access to de-identified data, thereby improving patient care. Applicant argues that claims 1, 19 and 24 recite additional elements that are specific improvement over prior art healthcare system by making healthcare data easily joinable, thereby providing an improved system for collecting, storing, and providing access to de-identified data, which improves insights for research and patient care, similar to the Example 42 of the USPTO’s Subject Matter Eligibility Examples.
With respect to Applicant's assertion that the prior art does not teach the recited claims, Examiner response that, under current Office guidelines, patentability with respect to 35 U.S.C. 101 is not evaluated through the lens of 35 U.S.C. 103(a). Although novelty and non-obviousness may provide a useful clue in identifying limitations that are not conventional or routine in the field (79 Fed. Reg. 74624), claims that overcome rejections under 35 U.S.C. 102 or 103 are not necessarily statutory in nature.
In response to Applicant’s argument about claims providing an improvement to the technology, Examiner submits that the features of converting patient records into a normalized format and de-identifying the converted records are directed to mere instructions to apply/implement/automate an abstract idea in a particular technological environment. 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)). Also, as indicated in the section above, “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.
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
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 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