Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of the Application
Claims 1-20 are currently pending in this case and have been examined and addressed below. This communication is a Final Rejection in response to the Amendments to the Claims and Remarks filed on 12/08/2025.
Claims 1, 3, 8, 10, and 15-16 are currently amended.
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., an abstract idea) without significantly more.
Step 1: Claims 1-7 are drawn to a process. Claims 8-20 are drawn to a process. As such, claims 1-20 are drawn to one of the statutory categories of invention (Step 1: YES).
Step 2A - Prong One: In prong one of step 2A, the claim(s) is/are analyzed to evaluate whether it/they recite(s) a judicial exception.
Independent Claim 1: A computer-implemented method comprising:
receiving a first request for electronic health records (EHRs);
sending a second request to a first health information exchange to cause the first health information exchange to send one or more third requests for at least some of the EHRs from second health information exchanges through a health information network, wherein the EHRs are stored across the second health information exchanges in non- standardized formats;
receiving the EHRs from the first health information exchange, wherein the EHRs are received in the non-standardized formats;
converting the EHRs into a requested standardized format with an NCQA certification for export of the EHRs, comprising:
converting payloads of the EHRs from the non-standardized formats into standardized payloads in the requested standardized format suitable for export and tagging data in the standardized payloads for analytics based on codes in the data to make the EHRs in the requested standardized format with the NCQA certification actionable for clinical decision-making;
and providing the EHRs, in the requested standardized format with the NCQA certification, to a patient portal application for display to a user in real time to enable the user to access consolidated patient information from the second health information exchanges in the requested standardized format despite the non-standardized formats in which the EHRs were originally stored and provided by the second health information exchanges.
Independent Claim 8: A system comprising one or more processors and one or more non- transitory computer-readable media storing computing instructions that, when executed on the one or more processors, cause the one or more processors to perform operations comprising:
receiving a first request for electronic health records (EHRs);
sending a second request to a first health information exchange to cause the first health information exchange to send one or more third requests for at least some of the EHRs from second health information exchanges through a health information network, wherein the EHRs are stored across the second health information exchanges in non- standardized formats;
receiving the EHRs from the first health information exchange, wherein the EHRs are received in the non-standardized formats;
converting the EHRs into a requested standardized format with a NCQA certification for export of the EHRs, comprising:
converting payloads of the EHRs from the non-standardized formats into standardized payloads in the requested standardized format suitable for export and tagging data in the standardized payloads for analytics based on codes in the data to make the EHRs in the requested standardized format with the NCQA certification actionable for clinical decision-making;
and providing the EHRs, in the requested standardized format with the NCQA certification, to a patient portal application for display to a user in real time to enable the user to access consolidated patient information from the second health information exchanges in the requested standardized format despite the non-standardized formats in which the EHRs were originally stored and provided by the second health information exchanges.
Independent Claim 15: One or more non-transitory computer-readable media storing computing instructions that, when executed on one or more processors, cause the one or more processors to perform operations comprising:
receiving a first request for electronic health records (EHRs);
sending a second request to a first health information exchange to cause the first health information exchange to send one or more third requests for at least some of the EHRs from second health information exchanges through a health information network, wherein the EHRs are stored across the second health information exchanges in non- standardized formats;
receiving the EHRs from the first health information exchange, wherein the EHRs are received in the non-standardized formats;
converting the EHRs into a requested standardized format with a NCQA certification for export of the EHRs, comprising:
converting payloads of the EHRs from the non-standardized formats into standardized payloads in the requested standardized format suitable for export; and tagging data in the standardized payloads for analytics based on codes in the data to make the EHRs in the requested standardized format with the NCQA certification actionable for clinical decision-making;
and providing the EHRs, in the requested standardized format with the NCQA certification, to a patient portal application for display to a user in real time to enable the user to access consolidated patient information from the second health information exchanges in the requested standardized format despite the non-standardized formats in which the EHRs were originally stored and provided by the second health information exchanges.
(Examiner notes: The above claim terms underlined are additional elements that fall under Step 2A - Prong Two analysis section detailed below)
These steps amount to methods of organizing human activity which includes functions relating to interpersonal and intrapersonal activities, such as managing relationships or transactions between people, social activities, and human behavior; satisfying or avoiding a legal obligation; advertising, marketing, and sales activities or behaviors; and managing human mental activity (MPEP § 2106.04(a)(2)(II)(C) citing the abstract idea grouping for methods of organizing human activity for managing personal behavior or relationships or interactions between people). Therefore, receiving a request, receiving EHRs, converting EHRs into a requested standardized format, converting payloads from non-standardized formats into standardized formats, tagging data, and providing EHRs are directed to managing personal interactions or personal behavior.
The dependent claims 2 and 9 are directed to authenticating the user prior to receiving the first request for the EHRs.
The dependent claims 3, 10, and 16 are directed to the requested standardized format is one of Clinical Document Architecture (CDA), Fast Healthcare Interoperability Resources (FHIR), or Portable Document Format (PDF).
The dependent claims 5, 12, and 18 are directed to accessing the EHRs.
The dependent claims 6, 13, and 19 are directed to receiving healthcare payment records comprising explanation of benefits (EOB) information from one or more payers.
The dependent claims 7, 14, and 20 are directed to requesting third requests.
Each of these steps of the preceding dependent claims 2-7, 9-14, and 16-20 only serve to further limit or specify the features of independent claims 1, 8, and 15 accordingly, and hence are nonetheless directed towards fundamentally the same abstract idea as the independent claim and utilize the additional elements analyzed below in the expected manner.
As such, the Examiner concludes that the preceding claims recite an abstract idea (Step 2A – Prong One: YES).
Step 2A - Prong Two: In prong two of step 2A, an evaluation is made whether a claim recites any additional element, or combination of additional elements, that integrate the exception into a practical application of that exception. An “additional element” is an element that is recited in the claim in addition to (beyond) the judicial exception (i.e., an element/limitation that sets forth an abstract idea is not an additional element). The phrase “integration into a practical application” is defined as requiring an additional element or a combination of additional elements in the claim to apply, rely on, or use the judicial exception in a manner that imposes a meaningful limit on the judicial exception, such that it is more than a drafting effort designed to monopolize the exception.
Claims 1, 8, and 15 recite the use of a sending a second request to a first health information exchange to cause the first health information exchange to send one or more third requests for at least some of the EHRs from second health information exchanges through a health information network, wherein the EHRs are stored across the second health information exchanges in non- standardized formats, only as a tool to perform an existing process and only amounts to an instruction to implement the abstract idea using a computer (MPEP § 2106.05(f)(2)).
Claims 1, 8, and 15 further recite the use of a patient portal application for display, only recites the patient portal application for display as a tool to perform an existing process and only amounts to an instruction to implement the abstract idea using a computer (MPEP § 2106.05(f)(2)).
Claims 1, 7-8, 14-15, and 20 recite the use of a first health information exchange, only as a tool to perform an existing process and only amounts to an instruction to implement the abstract idea using a computer (MPEP § 2106.05(f)(2)).
Claims 4, 11, and 17 recite the use of a storing the EHRs in a patient records database, only as a tool to perform an existing process and only amounts to an instruction to implement the abstract idea using a computer (MPEP § 2106.05(f)(2)).
Claims 5, 12, and 18 recite the use of a patient records database is accessible by the patient portal application, in this case to access the EHRs, only recites the patient records database is accessible by the patient portal application as a tool to perform an existing process and only amounts to an instruction to implement the abstract idea using a computer (MPEP § 2106.05(f)(2)).
Claim 8 recites the use of a one or more processors and one or more non- transitory computer-readable media storing computing instructions that, when executed on the one or more processors, cause the one or more processors to perform operations, in this case to receiving a first request for electronic health records, sending requests for EHRs, receiving EHRs, converting EHRs and payloads of EHRs into standardized formats, tagging data, providing EHRs, only recites the one or more processors and one or more non- transitory computer-readable media storing computing instructions that, when executed on the one or more processors, cause the one or more processors to perform operations as a tool to perform an existing process and only amounts to an instruction to implement the abstract idea using a computer (MPEP § 2106.05(f)(2)).
Claim 15 recites the use of one or more non-transitory computer-readable media storing computing instructions that, when executed on one or more processors, cause the one or more processors to perform operations, in this case to receiving a first request for electronic health records, sending requests for EHRs, receiving EHRs, converting EHRs and payloads of EHRs into standardized formats, tagging data, providing EHRs, only recites the one or more non-transitory computer-readable media storing computing instructions that, when executed on one or more processors, cause the one or more processors to perform operations as a tool to perform an existing process and only amounts to an instruction to implement the abstract idea using a computer (MPEP § 2106.05(f)(2)).
The Examiner has therefore determined that the additional elements, or combination of additional elements, do not integrate the abstract idea into a practical application. Accordingly, the claim(s) is/are directed to an abstract idea (Step 2A – Prong two: NO).
Step 2B: In step 2B, the claims are analyzed to determine whether any additional element, or combination of additional elements, is/are sufficient to ensure that the claims amount to significantly more than the judicial exception.
As discussed above in “Step 2A – Prong 2”, the identified additional elements, such as sending a second request to a first health information exchange to cause the first health information exchange to send one or more third requests for at least some of the EHRs from second health information exchanges through a health information network, wherein the EHRs are stored across the second health information exchanges in non- standardized formats, first health information exchange, a patient portal application for display, storing the EHRs in a patient records database, patient records database is accessible by the patient portal application, one or more processors and one or more non- transitory computer-readable media storing computing instructions that, when executed on the one or more processors, cause the one or more processors to perform operations, and one or more non-transitory computer-readable media storing computing instructions that, when executed on one or more processors, cause the one or more processors to perform operations in independent claims 1, 8, and 15 and dependent claims 2-7, 9-14, and 16-20 are equivalent to adding the words “apply it” on a generic computer. Each of these elements is only recited as a tool for performing steps of the abstract idea, such as the use of the computer and data processing devices to apply the algorithm. These additional elements therefore only amount to mere instructions to perform the abstract idea using a computer and are not sufficient to amount to significantly more than the abstract idea (MPEP 2016.05(f) see for additional guidance on the “mere instructions to apply an exception”). Each additional element under Step 2A, Prong 2 is analyzed in light of the specification’s explanation of the additional element’s structure. The claimed invention’s additional elements are directed to generic computer component and functions being used to perform the abstract idea.
Applicant’s own disclosure in paragraph [0034-0035] acknowledges that the “memory storage unit 208 that includes both read only memory (ROM) and random access memory (RAM). Non-volatile portions of memory storage unit 208 or the ROM can be encoded with a boot code sequence suitable for restoring computer system 100 (FIG. 1) to a functional state after a system reset. In addition, memory storage unit 208 can include microcode such as a Basic Input-Output System (BIOS). In some examples, the one or more memory storage units of the various embodiments disclosed herein can include memory storage unit 208, a USB-equipped electronic device (e.g., an external memory storage unit (not shown) coupled to universal serial bus (USB) port 112 (FIGs. 1-2)), hard drive 114 (FIGs. 1-2), and/or CD-ROM, DVD, Blu-Ray, or other suitable media, such as media configured to be used in CD-ROM and/or DVD drive 116 (FIGs. 1-2). Non-volatile or non-transitory memory storage unit(s) refer to the portions of the memory storage units(s) that are non-volatile memory and not a transitory signal. In the same or different examples, the one or more memory storage units of the various embodiments disclosed herein can include an operating system, which can be a software program that manages the hardware and software resources of a computer and/or a computer network…“processor” and/or “processing module” means any type of computational circuit, such as but not limited to a microprocessor, a microcontroller, a controller, a complex instruction set computing (CISC) microprocessor, a reduced instruction set computing (RISC) microprocessor, a very long instruction word (VLIW) microprocessor, a graphics processor, a digital signal processor, or any other type of processor or processing circuit capable of performing the desired functions. In some examples, the one or more processors of the various embodiments disclosed herein can comprise CPU 210”. Paragraphs [0042-0043] disclose “system 300 can include a patient portal application (“app”)…system 300 can be implemented with hardware and/or software, as described herein. In some embodiments, part or all of the hardware and/or software can be conventional, while in these or other embodiments, part or all of the hardware and/or software can be customized (e.g., optimized) for implementing part or all of the functionality of system 300 described herein. The components of FIG. 3 can each be, or be implemented on, a computer system, such as computer system 100 (FIG. 1), as described above, and can each be, or be implemented on, a single computer, a single server, or a cluster or collection of computers or servers, or a cloud of computers or servers. In another embodiment, a single computer system can host some or all of the components of system 300… patient portal app 310 can be an application, such as a mobile application or desktop application, or a web-based application”. Furthermore, paragraph [0047] acknowledges that the “one or more databases can be stored on one or more memory storage units (e.g., non-transitory computer readable media), which can be similar or identical to the one or more memory storage units (e.g., non-transitory computer readable media) described above with respect to computer system 100 (FIG. 1). Also, in some embodiments, for any particular database of the one or more databases, that particular database can be stored on a single memory storage unit or the contents of that particular database can be spread across multiple ones of the memory storage units storing the one or more databases, depending on the size of the particular database and/or the storage capacity of the memory storage units. The one or more databases can each include a structured (e.g., indexed) collection of data and can be managed by any suitable database management systems configured to define, create, query, organize, update, and manage database(s). Exemplary database management systems can include MySQL (Structured Query Language) Database, PostgreSQL Database, Microsoft SQL Server Database, Oracle Database, SAP (Systems, Applications, & Products) Database, and IBM DB2 Database”. Also, paragraph [0051] acknowledges that the “health information exchange 330 can be an HIE (Health Information Exchange), such as C3HIE, HASA (Healthcare Access San Antonio), or another suitable HIE, which can make healthcare data available to healthcare providers”. Paragraph [0053] discloses that the “health information network 340 can be eHealth Exchange, or another suitable health information network to access third-party HIEs (CommonWell, etc.)”.
The Examiner has therefore determined that no additional element, or combination of additional claims elements is/are sufficient to ensure the claim(s) amount to significantly more than the abstract idea identified above (Step 2B: NO).
Therefore, claims 1-20 are not eligible subject matter under 35 USC 101.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over MISHRA (US-20160103963-A1)[hereinafter Mishra], in view of GREEN (US-20110301982-A1)[hereinafter Green].
As per Claim 1, Mishra discloses a computer-implemented method in paragraphs [0164] and [0245-0246] (a computer-implemented method) comprising: receiving a first request for electronic health records (EHRs) in paragraphs [0108] and [0164] (receiving a transfer request (synonymous to a first request) for electronic health records or EHRs); sending a second request to a first health information exchange to cause the first health information exchange to send one or more third requests for at least some of the EHRs from second health information exchanges through a health information network, wherein the EHRs are stored across the second health information exchanges in non- standardized formats in paragraphs [0105] and [0167] and [0171-0177] and [0251] (sending a request (synonymous to a second request) to a server in the federated healthcare information exchange (synonymous to a first health information exchange), referred to as federated HIE, to cause the server in the federated HIE to send a query (synonymous to one or more third requests) for EHRs from another server in the federated HIE (synonymous to a second healthcare information exchange) through a network (synonymous to a health information network), wherein the EHRs are stored across the other server in the federated HIE in non-standardized formats (Examiner notes that a storing a complete copy of all of the records of every patient indicates storing records in non-standardized formats)); receiving the EHRs from the first health information exchange, wherein the EHRs are received in the non-standardized formats in paragraphs [0167-0177] (receiving the EHRs from the server in the federated HIE, wherein the EHRs are received in non-standardized formats); and providing the EHRs, in the requested standardized format to a patient portal application for display to a user in paragraphs [0104] and [0118] and [0128] and [0144] and [0148-0150] and [0152] and Figure 6 (providing the EHRs, in the requested standardized format, to a patient portal application for display to a user).
Mishra discloses providing the EHRs in the requested standardized format to a patient portal application for display to a user, but does not disclose the concept of converting the EHRs from a non-standardized format into a standardized format with an NCQA certification. However, Green discloses converting the EHRs into a requested standardized format with an NCQA certification for export of the EHRs in paragraphs [0004-0005] and [0066] and [0100-0101] and Figure 4 (converting the EHRs into the Health Level Seven (HL7) standardized format (synonymous to a requested standardized format with an NCQA certification) for export of the EHRs (Examiner notes that according to NCQA, it is encouraged to use HL7 as a standardized format to exchange data)), comprising: converting payloads of the EHRs from the non-standardized formats into standardized payloads in the requested standardized format suitable for export in paragraphs [0066] and [0100-0103] and Figure 4 (converting patient data (synonymous to payloads of the EHRs) into standardized patient data using HL7 standardized format (synonymous to the requested standardized format suitable for export)) and tagging data in the standardized payloads for analytics based on codes in the data to make the EHRs in the requested standardized format with the NCQA certification actionable for clinical decision-making in paragraphs [0063] and [0093-0096] and [0110-0125] and Figure 4 (flagging patient data for correlating data with triggering events, form fields, and other data using the standardized medical vocabularies, terminologies, and classification systems based on codes in the patient data to make the EHRs in HL7 standardized format for clinical decision support); and providing the EHRs, in the requested standardized format with the NCQA certification, to a patient portal application for display to a user in real time to enable the user to access consolidated patient information from the second health information exchanges in the requested standardized format despite the non-standardized formats in which the EHRs were originally stored and provided by the second health information exchanges in paragraphs [0066] and [0100-0103] and [0156-0157] (providing the EHRs, in the HL7 standardized format, to the main user interface (synonymous to a patient portal application for display to a user) in real time to access patient data that has eliminated errors, duplication, and inconsistencies from the health information exchanges in the HL7 standardized format (Examiner notes that patient data that does not include errors, duplicates, or inconsistencies indicates consolidated patient data)).
It would have been obvious to a person of ordinary skill in the art before the effective filling date of the applicant’s invention of a method the receives a first request for EHRs, sending requests through health information exchanges for EHRs, receiving the EHRs from the health information exchange, and displaying the EHRs, as disclosed by Mishra, to be combined with converting the EHRs into a requested standardized format with an NCQA certification by converting payloads of the EHRs from non-standardized formats to standardized formats and tagging data in the standardized payloads for clinical decision making, as disclosed by Green, for the purpose of analyzing collecting and tracking patient data across a vast population while not capturing, storing, or managing duplicate or inconsistent data and complying with HIPAA regulations [0020].
As per Claim 2, Mishra and Green disclose the computer-implemented method of claim 1, Mishra also discloses further comprising authenticating the user prior to receiving the first request for the EHRs in paragraphs [0047] and [0107-0108] and [0164] (authenticating the user before receiving the transfer request for the EHRs).
As per Claim 3, Mishra and Green disclose the computer-implemented method of claim 1.
Mishra discloses a requested standardized format, but does not disclose types of requested standardized formats. However, Green discloses wherein the requested standardized format is one of Clinical Document Architecture (CDA), Fast Healthcare Interoperability Resources (FHIR), or Portable Document Format (PDF) in paragraph [0103] (the requested standardized format is clinical document architecture (CDA) (Examiner notes that the CDA meets the "one of" limitation)).
It would have been obvious to a person of ordinary skill in the art before the effective filling date of the applicant’s invention of a method the receives a first request for EHRs, sending requests through health information exchanges for EHRs, receiving the EHRs from the health information exchange, and displaying the EHRs, as disclosed by Mishra, to be combined with the requested standardized format being Clinical Document Architecture, as disclosed by Green, for the purpose of analyzing collecting and tracking patient data across a vast population while not capturing, storing, or managing duplicate or inconsistent data and complying with HIPAA regulations [0020].
As per Claim 4, Mishra and Green disclose the computer-implemented method of claim 1, Mishra also discloses further comprising storing the EHRs in a patient records database in paragraphs [0104-0105] (storing electronic health records in a EHR database (synonymous to a patient records database)).
As per Claim 5, Mishra and Green disclose the computer-implemented method of claim 4, Mishra also discloses wherein the patient records database is accessible by the patient portal application in paragraphs [0116] and [0128] and [0148] (the EHR database is accessible by the patient portal application).
As per Claim 6, Mishra and Green disclose the computer-implemented method of claim 1, Mishra also discloses further comprising receiving healthcare payment records comprising explanation of benefits (EOB) information from one or more payers in paragraphs [0051] and [0104] and [0152] (receiving insurance records (synonymous to healthcare payment records) including encounter information (synonymous to explanation of benefits information) from an insurance provider (synonymous to one or more payers)).
As per Claim 7, Mishra and Green disclose the computer-implemented method of claim 1, Mishra also discloses wherein the third requests are requested by the first health information exchange in paragraphs [0173] and [0176-0177] (a query is requested by the server of the federated HIE).
As per Claim 8, Mishra discloses a system comprising one or more processors and one or more non- transitory computer-readable media storing computing instructions that, when executed on the one or more processors, cause the one or more processors to perform operations in paragraphs [0245-0246] and [0249-0250] and [0255] and Figure 15 (a computing system including one or more processors and a memory (synonymous to one or more non-transitory computer-readable media) storing processor executable program instructions, causing the one or more processors to perform operations) comprising: receiving a first request for electronic health records (EHRs) in paragraphs [0108] and [0164] (receiving a transfer request (synonymous to a first request) for electronic health records or EHRs); sending a second request to a first health information exchange to cause the first health information exchange to send one or more third requests for at least some of the EHRs from second health information exchanges through a health information network, wherein the EHRs are stored across the second health information exchanges in non- standardized formats in paragraphs [0105] and [0167] and [0171-0177] and [0251] (sending a request (synonymous to a second request) to a server in the federated healthcare information exchange (synonymous to a first health information exchange), referred to as federated HIE, to cause the server in the federated HIE to send a query (synonymous to one or more third requests) for EHRs from another server in the federated HIE (synonymous to a second healthcare information exchange) through a network (synonymous to a health information network), wherein the EHRs are stored across the other server in the federated HIE in non-standardized formats (Examiner notes that a storing a complete copy of all of the records of every patient indicates storing records in non-standardized formats)); receiving the EHRs from the first health information exchange, wherein the EHRs are received in the non-standardized formats in paragraphs [0167-0177] (receiving the EHRs from the server in the federated HIE, wherein the EHRs are received in non-standardized formats); and providing the EHRs, in the requested standardized format to a patient portal application for display to a user in paragraphs [0104] and [0118] and [0128] and [0144] and [0148-0150] and [0152] and Figure 6 (providing the EHRs, in the requested standardized format, to a patient portal application for display to a user).
Mishra discloses providing the EHRs in the requested standardized format to a patient portal application for display to a user, but does not disclose the concept of converting the EHRs from a non-standardized format into a standardized format with an NCQA certification. However, Green discloses converting the EHRs into a requested standardized format with a NCQA certification for export of the EHRs in paragraphs [0004-0005] and [0066] and [0100-0101] and Figure 4 (converting the EHRs into the Health Level Seven (HL7) standardized format (synonymous to a requested standardized format with an NCQA certification) for export of the EHRs (Examiner notes that according to NCQA, it is encouraged to use HL7 as a standardized format to exchange data)), comprising: converting payloads of the EHRs from the non-standardized formats into standardized payloads in the requested standardized format suitable for export in paragraphs [0066] and [0100-0103] and Figure 4 (converting patient data (synonymous to payloads of the EHRs) into standardized patient data using HL7 standardized format (synonymous to the requested standardized format suitable for export)) and tagging data in the standardized payloads for analytics based on codes in the data to make the EHRs in the requested standardized format with the NCQA certification actionable for clinical decision-making in paragraphs [0063] and [0093-0096] and [0110-0125] and Figure 4 (flagging patient data for correlating data with triggering events, form fields, and other data using the standardized medical vocabularies, terminologies, and classification systems based on codes in the patient data to make the EHRs in HL7 standardized format for clinical decision support); and providing the EHRs, in the requested standardized format with the NCQA certification, to a patient portal application for display to a user in real time to enable the user to access consolidated patient information from the second health information exchanges in the requested standardized format despite the non-standardized formats in which the EHRs were originally stored and provided by the second health information exchanges in paragraphs [0066] and [0100-0103] and [0156-0157] (providing the EHRs, in the HL7 standardized format, to the main user interface (synonymous to a patient portal application for display to a user) in real time to access patient data that has eliminated errors, duplication, and inconsistencies from the health information exchanges in the HL7 standardized format (Examiner notes that patient data that does not include errors, duplicates, or inconsistencies indicates consolidated patient data)).
It would have been obvious to a person of ordinary skill in the art before the effective filling date of the applicant’s invention of a system the receives a first request for EHRs, sending requests through health information exchanges for EHRs, receiving the EHRs from the health information exchange, and displaying the EHRs, as disclosed by Mishra, to be combined with converting the EHRs into a requested standardized format with an NCQA certification by converting payloads of the EHRs from non-standardized formats to standardized formats and tagging data in the standardized payloads for clinical decision making, as disclosed by Green, for the purpose of analyzing collecting and tracking patient data across a vast population while not capturing, storing, or managing duplicate or inconsistent data and complying with HIPAA regulations [0020].
As per Claim 9, Mishra and Green disclose the system of claim 8, Mishra also discloses wherein the operations further comprise authenticating the user prior to receiving the first request for the EHRs in paragraphs [0047] and [0107-0108] and [0164] (authenticating the user before receiving the transfer request for the EHRs).
As per Claim 10, Mishra and Green disclose the system of claim 8.
Mishra discloses a requested standardized format, but does not disclose types of requested standardized formats. However, Green discloses wherein the requested standardized format is one of Clinical Document Architecture (CDA), Fast Healthcare Interoperability Resources (FHIR), or Portable Document Format (PDF) in paragraph [0103] (the requested standardized format is clinical document architecture (CDA) (Examiner notes that the CDA meets the "one of" limitation)).
It would have been obvious to a person of ordinary skill in the art before the effective filling date of the applicant’s invention of a system the receives a first request for EHRs, sending requests through health information exchanges for EHRs, receiving the EHRs from the health information exchange, and displaying the EHRs, as disclosed by Mishra, to be combined with the requested standardized format being Clinical Document Architecture, as disclosed by Green, for the purpose of analyzing collecting and tracking patient data across a vast population while not capturing, storing, or managing duplicate or inconsistent data and complying with HIPAA regulations [0020].
As per Claim 11, Mishra and Green disclose the system of claim 8, Mishra also discloses wherein the operations further comprise storing the EHRs in a patient records database in paragraphs [0104-0105] (storing electronic health records in a EHR database (synonymous to a patient records database)).
As per Claim 12, Mishra and Green disclose the system of claim 11, Mishra also discloses wherein the patient records database is accessible by the patient portal application in paragraphs [0116] and [0128] and [0148] (the EHR database is accessible by the patient portal application).
As per Claim 13, Mishra and Green disclose the system of claim 8, Mishra also discloses wherein the operations further comprise receiving healthcare payment records comprising explanation of benefits (EOB) information from one or more payers in paragraphs [0051] and [0104] and [0152] (receiving insurance records (synonymous to healthcare payment records) including encounter information (synonymous to explanation of benefits information) from an insurance provider (synonymous to one or more payers)).
As per Claim 14, Mishra and Green disclose the system of claim 8, Mishra also discloses wherein the third requests are requested by the first health information exchange in paragraphs [0173] and [0176-0177] (a query is requested by the server of the federated HIE).
As per Claim 15, Mishra discloses one or more non-transitory computer-readable media storing computing instructions that, when executed on one or more processors, cause the one or more processors to perform operations in paragraphs [0245-0246] and [0249-0250] and [0255] and Figure 15 ( a memory (synonymous to one or more non-transitory computer-readable media) storing processor executable program instructions, causing the one or more processors to perform operations) comprising: receiving a first request for electronic health records (EHRs) in paragraphs [0108] and [0164] (receiving a transfer request (synonymous to a first request) for electronic health records or EHRs); sending a second request to a first health information exchange to cause the first health information exchange to send one or more third requests for at least some of the EHRs from second health information exchanges through a health information network, wherein the EHRs are stored across the second health information exchanges in non- standardized formats in paragraphs [0105] and [0167] and [0171-0177] and [0251] (sending a request (synonymous to a second request) to a server in the federated healthcare information exchange (synonymous to a first health information exchange), referred to as federated HIE, to cause the server in the federated HIE to send a query (synonymous to one or more third requests) for EHRs from another server in the federated HIE (synonymous to a second healthcare information exchange) through a network (synonymous to a health information network), wherein the EHRs are stored across the other server in the federated HIE in non-standardized formats (Examiner notes that a storing a complete copy of all of the records of every patient indicates storing records in non-standardized formats)); receiving the EHRs from the first health information exchange, wherein the EHRs are received in the non-standardized formats in paragraphs [0167-0177] (receiving the EHRs from the server in the federated HIE, wherein the EHRs are received in non-standardized formats); and providing the EHRs, in the requested standardized format to a patient portal application for display to a user in paragraphs [0104] and [0118] and [0128] and [0144] and [0148-0150] and [0152] and Figure 6 (providing the EHRs, in the requested standardized format, to a patient portal application for display to a user).
Mishra discloses providing the EHRs in the requested standardized format to a patient portal application for display to a user, but does not disclose the concept of converting the EHRs from a non-standardized format into a standardized format with an NCQA certification. However, Green discloses converting the EHRs into a requested standardized format with a NCQA certification for export of the EHRs in paragraphs [0004-0005] and [0066] and [0100-0101] and Figure 4 (converting the EHRs into the Health Level Seven (HL7) standardized format (synonymous to a requested standardized format with an NCQA certification) for export of the EHRs (Examiner notes that according to NCQA, it is encouraged to use HL7 as a standardized format to exchange data)), comprising: converting payloads of the EHRs from the non-standardized formats into standardized payloads in the requested standardized format suitable for export in paragraphs [0066] and [0100-0103] and Figure 4 (converting patient data (synonymous to payloads of the EHRs) into standardized patient data using HL7 standardized format (synonymous to the requested standardized format suitable for export)); and tagging data in the standardized payloads for analytics based on codes in the data to make the EHRs in the requested standardized format with the NCQA certification actionable for clinical decision-making in paragraphs [0063] and [0093-0096] and [0110-0125] and Figure 4 (flagging patient data for correlating data with triggering events, form fields, and other data using the standardized medical vocabularies, terminologies, and classification systems based on codes in the patient data to make the EHRs in HL7 standardized format for clinical decision support); and providing the EHRs, in the requested standardized format with the NCQA certification, to a patient portal application for display to a user in real time to enable the user to access consolidated patient information from the second health information exchanges in the requested standardized format despite the non-standardized formats in which the EHRs were originally stored and provided by the second health information exchanges in paragraphs [0066] and [0100-0103] and [0156-0157] (providing the EHRs, in the HL7 standardized format, to the main user interface (synonymous to a patient portal application for display to a user) in real time to access patient data that has eliminated errors, duplication, and inconsistencies from the health information exchanges in the HL7 standardized format (Examiner notes that patient data that does not include errors, duplicates, or inconsistencies indicates consolidated patient data)).
It would have been obvious to a person of ordinary skill in the art before the effective filling date of the applicant’s invention of a non-transitory computer-readable media the receives a first request for EHRs, sending requests through health information exchanges for EHRs, receiving the EHRs from the health information exchange, and displaying the EHRs, as disclosed by Mishra, to be combined with converting the EHRs into a requested standardized format with an NCQA certification by converting payloads of the EHRs from non-standardized formats to standardized formats and tagging data in the standardized payloads for clinical decision making, as disclosed by Green, for the purpose of analyzing collecting and tracking patient data across a vast population while not capturing, storing, or managing duplicate or inconsistent data and complying with HIPAA regulations [0020].
As per Claim 16, Mishra and Green disclose the one or more non-transitory computer-readable media of claim 15.
Mishra discloses a requested standardized format, but does not disclose types of requested standardized formats. However, Green discloses wherein the requested standardized format is one of Clinical Document Architecture (CDA), Fast Healthcare Interoperability Resources (FHIR), or Portable Document Format (PDF) in paragraph [0103] (the requested standardized format is clinical document architecture (CDA) (Examiner notes that the CDA meets the "one of" limitation)).
It would have been obvious to a person of ordinary skill in the art before the effective filling date of the applicant’s invention of a non-transitory computer-readable media the receives a first request for EHRs, sending requests through health information exchanges for EHRs, receiving the EHRs from the health information exchange, and displaying the EHRs, as disclosed by Mishra, to be combined with the requested standardized format being Clinical Document Architecture, as disclosed by Green, for the purpose of analyzing collecting and tracking patient data across a vast population while not capturing, storing, or managing duplicate or inconsistent data and complying with HIPAA regulations [0020].
As per Claim 17, Mishra and Green disclose the one or more non-transitory computer-readable media of claim 15, Mishra also discloses wherein the operations further comprise storing the EHRs in a patient records database in paragraphs [0104-0105] (storing electronic health records in a EHR database (synonymous to a patient records database)).
As per Claim 18, Mishra and Green disclose the one or more non-transitory computer-readable media of claim 17, Mishra also discloses wherein the patient records database is accessible by the patient portal application in paragraphs [0116] and [0128] and [0148] (the EHR database is accessible by the patient portal application).
As per Claim 19, Mishra and Green disclose the one or more non-transitory computer-readable media of claim 15, Mishra also discloses wherein the operations further comprise receiving healthcare payment records comprising explanation of benefits (EOB) information from one or more payers in paragraphs [0051] and [0104] and [0152] (receiving insurance records (synonymous to healthcare payment records) including encounter information (synonymous to explanation of benefits information) from an insurance provider (synonymous to one or more payers)).
As per Claim 20, Mishra and Green disclose the one or more non-transitory computer-readable media of claim 15, Mishra also discloses wherein the third requests are requested by the first health information exchange in paragraphs [0173] and [0176-0177] (a query is requested by the server of the federated HIE).
Response to Arguments
Applicant's arguments, see Pages 8-11, “Amended Claims 1-20 Are Allowable Over 35 U.S.C. 101“, filed 12/08/2025 with respect to claims 1, 8 and 15 have been fully considered but they are not persuasive.
Applicant argues that the amended independent claims integrate the abstract idea into a practical application by providing technical improvements over prior systems. Examiner respectfully disagrees. The claims do not recite an improvement to data fragmentation and interoperability. The claims merely recite receiving a request, receiving EHRs, converting EHRs into a requested standardized format, converting payloads from non-standardized formats into standardized formats, tagging data, and providing EHRs, which are a part of the abstract idea. An improvement to the abstract ideas of receiving a request, receiving EHRs, converting EHRs into a requested standardized format, converting payloads from non-standardized formats into standardized formats, tagging data, and providing EHRs does not amount to an improvement to technology or a technical field (see MPEP § 2106.05(a)(II) stating “it is important to keep in mind that an improvement in the abstract idea itself (e.g. a recited fundamental economic concept) is not an improvement in technology."). The courts indicated in TLI Communications, 823 F.3d at 612-13, 118 USPQ2d at 1747-48, that gathering and analyzing information using conventional techniques and providing the output is not sufficient to show an improvement to technology. The claim language and instant application fails to provide details regarding how a computer aids the method, the extent to which the computer aids the method, or the significance of a computer to the performance of the method. Here, the improvement is to receiving a request, receiving EHRs, converting EHRs into a requested standardized format, converting payloads from non-standardized formats into standardized formats, tagging data, and providing EHRs. There is no indication in the disclosure that the involvement of a computer assists in improving the technology for the outlined problem statement. Merely adding generic computer components to perform the method is not sufficient.
Applicant then draws factual comparisons between Example 42 of the October 2019 Update: Subject Matter Eligibility Guidance Update. Examiner maintains the position that Example 42 is distinguishable from the instant claims. As previously expressed, Example 42's abridged background provides the technical problem of latency and incompatibility between remote devices stating "medical providers must continually monitor a patient’s medical records for updated information, which is often-times incomplete since records in separate locations are not timely or readily-shared or cannot be consolidated due to format inconsistencies as well as physicians who are unaware that other physicians are also seeing the patient for varying reasons" wherein the technical solution is reflected in the claim language. The instant application, however, present a non-technical problem – data fragmentation and interoperability. The solution to the problem is rooted in an improvement to the abstract idea itself and not a technical failure of a computer system. The additional elements can best be characterized as tools to perform an existing process and only amounts to an instruction to implement the abstract idea using a computer (MPEP § 2106.05(f)(2) see case requiring the use of software to tailor information and provide it to the user on a generic computer within the “Other examples., v.”).
Applicant’s arguments, see Pages 11-12, “Amended Claims 1-20 Are Allowable in View of 35 U.S.C. 102 and 103”, filed 12/08/2025 with respect to claims 1-20 have been fully considered.
With regards to claims 1, 8, and 15, Applicant argues that Mishra and Mari do not teach or suggest the amended limitations individually or in combination. Examiner finds this persuasive. Therefore, the rejection of 09/08/2025 has been withdrawn. However, upon further consideration a new grounds of rejection is made over Mishra in view of Green. As per the rejections of claims 2-7, 9-14, and 16-20, Applicant argues overcoming the rejections due to the dependent claims respective amended independent claims not being taught or suggested by the cited references. Examiner respectfully disagrees and points Applicant to the updated rejection and citations in the 103 rejections above.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Sullivan et al. (US-20170068784-A1) teaches on methods and systems for management of health care information.
Patel et al. “A framework for secure and decentralized sharing of medical imaging data via blockchain consensus” (2018) teaches electronic sharing of medical imaging data through a blockchain framework.
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 KRYSTEN N WRIGHT whose telephone number is (571)272-5116. The examiner can normally be reached Monday thru Friday 8 - 5 pm, 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, Fonya Long can be reached on (571)270-5096. 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.
/K.N.W./
Examiner, Art Unit 3682
/FONYA M LONG/Supervisory Patent Examiner, Art Unit 3682