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 .
Status of Claims
Claims 1-12 are pending in this instant application per original claims filed on 04/05/2018. Claims 1 and 8 are two independent claims reciting system and method claims. Claims 2-7 and 9-12 are respective dependent claims.
No IDS has been filed by the Applicant.
This Office Action is a non-final rejection on merits in response to the original claims filed by the Applicant for its original application of 02 SEPTEMBER 2024 that is titled: “System and Method for Implementing Medical Data Exchange and Medical Claim Settlement”.
Accordingly, pending Claims 1-12 are now being rejected herein.
Claim Objections
Independent Claim 8 is objected to because of the following informalities:
Claim 8, line 6 recites “… raw medical data to a FHIR …”, which is the first time that “FHIR” is recited in this independent claim. The normal US practice is that full-form of an acronym should be defined in each independent claim. Examiner suggests adding full-form of “FHIR” as “Fast Healthcare Interoperability Resources” at its first recitation in claim 8, as has been done in independent system Claim 1.
Appropriate correction is required.
Claim Rejections - 35 USC §112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION — The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 8-12 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor, or for pre-AIA the Applicant regards as the invention. Examiner notes the following rejections ---
Independent Claim 8, line 7 recites a limitation “the converter of the system of claim 1” that is unclear and/or indefinite. There is insufficient antecedent basis for this limitation in the claim. Examiner suggests changing said limitation to “a converter of the system of claim 1”, (as has been done in line 6 for “a FHIR authorized data” wherein it seeks antecedent basis for “FHIR” from Claim 1), or a similar modification of the Applicant’s own choice.
Independent Claim 8, line 7 recites a limitation “the service-provider server of the system of claim 1” that is unclear and/or indefinite. There is insufficient antecedent basis for this limitation in the claim. Examiner suggests changing said limitation to “a service-provider server of the system of claim 1”, (as has been done in line 6 for “a FHIR authorized data” wherein it seeks antecedent basis for “FHIR” from Claim 1), or a similar modification of the Applicant’s own choice.
Independent Claim 8, line 13 recites a limitation “the authority management module of the system of claim 1” that is unclear and/or indefinite. There is insufficient antecedent basis for this limitation in the claim. Examiner suggests changing said limitation to “an authority management module of the system of claim 1”, (as has been done in line 6 for “a FHIR authorized data” wherein it seeks antecedent basis for “FHIR” from Claim 1), or a similar modification of the Applicant’s own choice.
Independent Claim 8, line 14 recites a limitation “the data exchange module” that is unclear and/or indefinite. There is insufficient antecedent basis for this limitation in the claim. Examiner suggests changing said limitation to “a data exchange module”, (as has been done in line 6 for “a FHIR authorized data” wherein it seeks antecedent basis for “FHIR” from Claim 1), or a similar modification of the Applicant’s own choice.
Claims 9-12, depending from independent Claim 8 directly or indirectly, are rejected because they have at least the same deficiencies/errors as described above, due to their dependency on independent Claim 8.
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-12 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (abstract idea) without significantly more, wherein Claims 1 and 8 are independent system and method claims respectively.
Exemplary Analysis.
Claim 8: Ineligible.
The claim recites a series of steps. The claim is directed to a method reciting a series of steps, which is a statutory category of invention (Step 1 -- YES).
The claim is analyzed to determine whether it is directed to a judicial exception. This claim recites computer-implemented method for exchanging medical data and settling medical claims for a client using the client’s raw medical data and comprises the limitations of: (i) receiving a raw medical data of the client, wherein the raw medical data has a first format; (ii) converting the raw medical data to a FHIR authorized data in response to a mapping instruction, wherein the FHIR standard data has a second format that differs from the first format of the raw medical data, and the FHIR authorized data is stored in the blockchain database; and (iii) providing a medical claim service to the client based on the FHIR authorized data of step (ii); wherein the FHIR authorized data is processed according to instructions programmed within the authority management module as the FHIR authorized data is transmitted among the data exchange module, the blockchain database, by executing a procedure comprising steps of: (a) receiving a first public key and a first private key, and a second public key and a second private key from the service-provider, respectively; (b) combining the first private key and the second public key of step (a) to produce a key; (c) encrypting the FHIR authorized data with the key produced in step (b) to produce a ciphered FHIR authorized data; (d) providing a signature to the ciphered FHIR authorized data of step (c) by use of the first private key, thereby producing a signed FHIR authorized data; (e) verifying the signed FHIR authorized data of step (d) by use of the first public key to validate and rescind the signature, thereby restoring the ciphered FHIR authorized data of step (c); and (f) decrypting the ciphered FHIR authorized data of step (e) with the key of step (b) to obtain the FHIR authorized data that has been decrypted, wherein the key is produced by combining the second private key and the first public key of step (a). These limitations, as drafted, are steps of a method that, under its broadest reasonable interpretation, covers performance of the limitations via a method of organizing human activity such as fundamental economic principles or practices (including hedging, insurance, mitigating risk), and/or commercial or legal interactions (including agreements in the form of contracts; legal obligations; advertising, marketing or sales activities or behaviors; business relations), and/or managing behavior or relationships or interactions between people (including social activities, teaching, and following rules or instructions), but for the recitation of generic computer/s and/or computer component/s such as the devices/ mobile devices. These limitations fall under the “certain methods of organizing human activity” group (Step 2A1 -- YES).
Next, the claim is analyzed to determine if it is integrated into a practical
application. The claim recites additional elements of: a server, converter, service-provider server, authority management module and data exchange module as parts of a system. These additional elements are considered extra-solution activities. The server, converter, service-provider server and different modules of a system in the steps are recited at a high level of generality, i.e., as generic processors performing generic computer/s functions of processing data. These generic processors are no more than mere instructions to apply the exception using generic computer/s and/or computer component/s. 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. Thus, the claim is directed to the abstract idea (Step 2A2 -- NO).
Next, the claim is analyzed to determine if there are additional elements in this claim that individually, or as an ordered combination, ensure that the claim amounts to significantly more than the abstract ideas (whether claim provides inventive concept). As discussed with respect to Step 2A2 above, the additional elements in the claim amount to no more than mere instructions to apply the exception using generic computer/s and/or computer component/s. The same analysis applies here in Step 2B, i.e., mere instructions to apply an exception using a generic computer and/or computer components over a network cannot integrate a judicial exception into a practical application at Step 2A or provide an inventive concept in Step 2B. Because the additional elements of: a server, converter, service-provider server, authority management module and data exchange module as parts of a system, were considered to be extra-solution activities in Step 2A, they are re-evaluated in Step 2B to determine if they are more than what is well-understood, routine and conventional in the field. The disclosure does not provide any indication that these devices (processors) are anything other than generic processors and the Symantec, TLI, and OIP Techs. court decisions (MPEP 2106.05 (d) (II)) indicate that mere collection or receipt of data over a network is a well‐understood, routine, and conventional function when it is claimed in a merely generic manner (as it is here). Also, paras [0038], [0041]-[0042], [0047] & [0049] of the Applicant’s own Specification describe ---
{“ [0038] Accordingly, one aspect of the present invention is directed to a system for implementing medical data exchange and medical claim settlement via a Fast Healthcare Interoperability Resources (FHIR) standard data. Referring to FIG. 1, a system 100, which is communicatively connected to a server M, is depicted according to one embodiment of the present disclosure. As depicted, the present system 100 comprises in its structure a data exchange module 110, a blockchain database 120, a service-provider server 130, and an authority management module 140. Specifically, the data exchange module 110, the blockchain database 120 and the service-provider server 130 are communicatively connected to each other, the server M is communicatively connected to the data exchange module 110, and the authority management module 140 is communicatively connected to the data exchange module 110 and the blockchain database 120, respectively. The configuration aforementioned enables the transmission of the raw medical data having a first format from the server M to the present system100, where the raw data is converted to comply with FHIR standard. The converted data is then provided to the service-provider server 130 (e.g., insurance company) and serves as the basis for providing medical claims services to the client. ……………………………………………………………………………………
[0041] The data exchange module 110 is communicatively connected to the server M and is configured to receive and convert the raw medical data in the first format stored in server M into FHIR authorized data. Noted that the data exchange module 110 includes a built-in converter 112 configured to carry out the conversion process. The converter 112 is a tool or program used to convert one data format into another. The conversion process is not limited to converting only the data storage format; it can also map specific items from the raw medical data to corresponding fields defined in the FHIR standard, with or without changing the storage format, based on at least one mapping instructions. In one working example, the converter 112 is an XML-to-JSON converter. ……………………………………………………………………………….
[0042] According to some embodiments of the present disclosure, when the converter 112 receives the raw medical data, it reads the data content and parses the XML format into an internal representation. Then, the converter 112 maps each element or item of the raw medical data to the corresponding fields defined in the FHIR standard in accordance with predetermined mapping rules. The format conversion is then carried out, including steps such as rearranging data, transforming it, and renaming labels, to generate FHIR authorized data complying with the target format, while incorporating the content converted from the raw medical data. The converted data can be saved to a database or any designated storage unit, and/or directly output to other medical or insurance institutions' systems or applications for use. According to optional embodiments of the present disclosure, the FHIR authorized data is directly output to the service-provider server 130 for use, while simultaneously being stored in the blockchain database 120. …………………………………………………………….
……………………………………………………………………………………………….
[0047] In addition to be transmitted to the blockchain database 120 for storage, the FHIR authorized data can also be directly transmitted to the service-provider server 130, which is communicatively connected to the data exchange module 110. This allows the service provider, either through its systems (such as the claims settlement system of an insurance organization) or personnel (e.g., claims handlers), to generate and provide claims services based on the FHIR-authorized data directly received from the data exchange module 110 or by accessing the FHIR-authorized data stored in the blockchain database 120. ……………………………………………………………….
[0049] To ensure the confidentiality and security of medical information, which contains personal and sensitive data, and to prevent potential insurance fraud, the present system 100 implements an authority management module 140 that communicatively connected to the data exchange module 110 and the service-provider server 130 to manage access rights to FHIR authorized data. According to embodiments of the present disclosure, the authority management module 140 is programmed with instructions to execute a method for managing the FHIR authorized data when it is transmitted among the data exchange module 110, the blockchain database 120, and the service-provider server 130.”} ---
and indicate that the concept described by the extra-solution additional elements is conventional. Accordingly, a conclusion that the aforementioned extra-solution additional elements are well-understood, routine and conventional activity is supported under Berkheimer options 2 and 3, respectively.
Viewing the limitations as an ordered combination does not add anything further than looking at the limitations individually. When viewed either individually, or as an ordered combination, the additional elements do not amount to a claim as a whole that is significantly more than the abstract idea itself. Therefore, the claim does not amount to significantly more than the recited abstract idea (Step 2B -- NO), and the claim is not patent eligible.
The analysis above applies to all statutory categories of the invention including independent system Claim 1, which perform the steps similar to those of independent method Claim 8. Furthermore, the limitations of dependent method Claims 9-12, further narrow the independent method Claim 8 with additional steps and limitations (e.g., wherein the mapping instruction of step (ii) is produced through self-defining the FHIR standard data with the second format; wherein the authority management module is further programmed with instructions to execute the steps of transmitting the ciphered FHIR authorized data of step (c), …; wherein after step (c), the authority management module is further programmed with instructions to execute the steps of calculating the ciphered FHIR authorized data to produce a hash value; and transmitting the hash value to the blockchain database; wherein the service-provider server further comprises a data verification unit communicatively connected to the blockchain database and configured to calculate the ciphered FHIR authorized data to produce a checksum, …; etc.), and do not resolve the issues raised in rejection of independent method Claim 8. Similarly, dependent system Claims 2-7 also further narrow their independent Claim 1, which are rejected as ineligible for patenting under 35 U.S.C. 101 based upon the same analysis.
Therefore, said Claims 1-12 are rejected under 35 U.S.C. 101 as being directed to non-statutory subject matter.
Separate 101 Rejection for System Claims 1-7 ---
Independent System Claim 1 is rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. Claimed invention must fall into one of the four recognized statutory classes of invention, a process (or method), a machine (or system); an article of manufacture; or a composite of matter. However, Claim 1 does not fall within one of these recognized categories, but it falls into two categories, system and method, as recited in claims listing of 09/02/2024 as --- {“A computer-implemented method for exchanging medical data and settling medical claims for a client using the client’s raw medical data stored in a server via the system of claim 1, …”}. Claims 2-7 claim dependency from independent “system” claim 1 directly and/or indirectly, and hence these Claims 2-7 are also rejected.
Separate 101 Rejection for Method Claims 8-12 ---
Independent Method Claim 8 is rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. Claimed invention must fall into one of the four recognized statutory classes of invention, a process (or method), a machine (or system); an article of manufacture; or a composite of matter. However, Claim 8 does not fall within one of these recognized categories, but it falls into two categories, method and system, as recited in claims listing of 09/02/2024 as --- {“A computer-implemented method for exchanging medical data and settling medical claims for a client using the client’s raw medical data stored in a server via the system of claim 1, …”}; and “system” is recited nine/9 times in Claim 8 (while “system” is recited only twice in Claim 1). Claims 9-12 claim dependency from independent “method claim 8” directly and/or indirectly, and hence these Claims 9-12 are also rejected; and thus, Claim 8 is treated as a “method claim” only.
Claim Rejections - 35 USC §103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
This application currently names joint inventors. In considering patentability of the claims the Examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. The Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the Examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office Action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S.1,148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1.) Determining the scope and contents of the prior art.
2.) Ascertaining the differences between the prior art and the claims at issue.
3.) Resolving the level of ordinary skill in the pertinent art.
4.) Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-12 are rejected under 35 USC 103 as unpatentable over a combination of references as described below for each claim/ limitation.
Exemplary Analysis for Rejection of Claims 1-7
Independent Claim 1 is rejected under 35 USC 103 as unpatentable over Pub. No. US 2023/ 0162823 filed by Bastide et al. (hereinafter “Bastide”) in view of Pub. No. US 2013/ 0246094 filed by Cruise, Mark R. (hereinafter “Cruise”), and further in view of Pub. No. US 2024/ 0212815 filed by Lafauci et al. (hereinafter “Lafauci”), and as described below for each claim/ limitation.
Examiner notes that all claims have been copied as recited by the Applicant to keep them readable and whole, even if the limitations within a claim that are not taught explicitly by the primary/previous reference (are noted in parentheses), but these limitations are noted explicitly as taught by a secondary/new reference whenever a secondary/new reference has been used.
Examiner notes that, for brevity in this rejection, the motivation statement has not been repeated herein every time a secondary reference has been used.
With respect to Claim 1, Bastide teaches ---
1. A system for implementing medical data exchange and (medical claim settlement) via a Fast Healthcare Interoperability Resources (FHIR) standard data, communicatively connected to a server having a plurality of raw medical data of a first format stored thereon, the system comprises:
(see at least: Bastide Abstract and Summary in paras [0010]-[0016]; and para [0002] about {“… To manage this substantially large amount of data, an organization may offer a suite of common and flexible platform services for health data and analytics in a multi-cloud and hybrid-cloud environment. The services may include Fast Healthcare Interoperability Resources (FHIR), de-identification, patient insights, patient summary, precision cohorts, annotator for clinical data, insights for medical literature, etc.”}; and para [0032] about {“…… In embodiments, the record client 112 may provide a user interface in which the medical professional may enter a plurality of different types of information from demographics to medically related information as well as interact with one or more components of the retroactive code system 100, and utilize various wired and/or wireless connection protocols for data transmission and exchange associated with data used for modifying a version of an application, including Bluetooth, 2.4 gHz and 5 gHz internet, near-field communication, Z-Wave, Zigbee, etc.”}; and para [0035] about {“In the exemplary embodiments, the medical record data 122 may include medical records in various formats such as electronic health records (EHR), electronic medical records (EMR), Fast Healthcare Interoperatbility Resources (FHIR), etc. for respective patients. …”}; and para [0037] about {“…… In embodiments, the service client 142 may provide a user interface in which the service user may view the medical record of the patient and input information identified therein to process the service for the patient as well as interact with one or more components of the retroactive code system 100, and utilize various wired and/or wireless connection protocols for data transmission and exchange associated with data used for modifying a version of an application, including Bluetooth, 2.4 gHz and 5 gHz internet, near-field communication, Z-Wave, Zigbee, etc.”}; and para [0040] about {“In the exemplary embodiments, the retroactive server 130 may include a code identification program 132, a patient identification program 134, a code correlation program 136, and a retroactive updating program 138, and act as a server in a client-server relationship with the record client 112 and the service client 142 as well as be in a communicative relationship with the data repository 120. …”}; and para [0045] about {“……The analytical portion of the retroactive code system 100 may enter the data into a data table where the data is extracted from the standard format into an analytical format. The analytical format may contain patient and demographic data (e.g., age, location, observation, and codes). …”}; which together are the same as claimed limitations above to include ‘medical data exchange’, ‘FHIR’, ‘communicatively connected to a server’ and ‘raw medical data of a first format’)
Bastide teaches as disclosed above, but it may be argued that it may not explicitly disclose about ‘medical claim settlement’. However, Cruise teaches it explicitly.
(see at least: Cruise Abstract and Summary of the Invention in paras [0034]-[0044]; and para [0054] about {“FIG. 10 is a flow chart of a settlement posting process in a medical claims management system in accordance with an embodiment of the present invention.”}; and para [0082] about {“…… Therefore, it is advantageous to be able to track and analyze payment patterns over a great number of claims, such that a comprehensive analysis can be performed on the data as part of a settlement negotiation with a payer. Such a statistical payment analysis process in an embodiment of the present invention is now described with reference to FIG. 9. Payment data is assembled 1110 from a plurality of previously processed claims. Claims may be selected by date, payer, health care provider, medical procedure, and/or other data fields. From the claims, the data preferably contains a procedure code identifying for what medical procedure the charge was made. …”}; which together are the same as claimed limitations above including ‘medical claim settlement’)
It would have been obvious prior to the time of the effective filing date of the claimed invention to have an ordinary person of skill in the art to modify the teachings of Bastide with the teachings of Cruise. The motivation to combine these references would be to manage medical data may utilize a code system in which a condition, disease, or other medically related issue may be represented with a code in light of the dynamic nature of utilizing codes for medical data and the use of the codes in various medically related services (e.g., maintaining medical charts) and associated services (e.g., billing), conventional approaches have configured ways of tracking the medical data (see paras [0003]-[0004] of Bastide), and to provide the physician practice to communicate only via the clearinghouse with the insurer and never has a direct link with processes going on at the insurer, and does not know how the reports from the clearinghouse mesh with processes that are followed by the insurer in handling claims from the physician practice (see para [0031] of Cruise).
Bastide and Cruise teach ---
(a data exchange module) configured to receive the plurality of raw medical data from the server and convert them into a plurality of FHIR authorized data in response to a mapping instruction via a converter built therein;
(see at least: Bastide ibidem and citations listed above to include ‘medical data exchange’, ‘FHIR’, ‘communicatively connected to a server’ and ‘raw medical data of a first format’; and para [0048] about {“……Using the patient demographic and observation data associated with the determined existing code correlated to the new code, the retroactive server 130 may run the prior data (e.g., the medical records of patients) that does not associate or use the new code to confirm the second patients.”}; and para [0084] about {“…… Security provides identity verification for cloud consumers and tasks, as well as protection for data and other resources. …”}; which together are the same as claimed limitations above to include ‘authorized data’ per BRI rules)
(see at least: Cruise ibidem and citations listed above to include ‘medical claim settlement’)
Bastide and Cruise teach as disclosed above, but they may not explicitly disclose about ‘a data exchange module’. However, Lafauci teaches it explicitly.
(see at least: Lafauci Abstract and Summary in paras [0006]-[0050]; and para [0088] about {“In some embodiments, the medication monitoring module can be in digital communication with other medication monitoring modules operated in other user devices and/or with other databases for data stream or exchange. Such data can represent information relevant to the disposal and return of the medications. …”}; which together are the same as claimed limitations above to include ‘a data exchange module’)
It would have been obvious prior to the time of the effective filing date of the claimed invention to have an ordinary person of skill in the art to modify the teachings of Bastide and Cruise with the teachings of Lafauci. The motivation to combine these references would be to manage medical data may utilize a code system in which a condition, disease, or other medically related issue may be represented with a code in light of the dynamic nature of utilizing codes for medical data and the use of the codes in various medically related services (e.g., maintaining medical charts) and associated services (e.g., billing), conventional approaches have configured ways of tracking the medical data (see paras [0003]-[0004] of Bastide), and to provide the physician practice to communicate only via the clearinghouse with the insurer and never has a direct link with processes going on at the insurer, and does not know how the reports from the clearinghouse mesh with processes that are followed by the insurer in handling claims from the physician practice (see para [0031] of Cruise), and to provide ADM (automated dispending machine aka medication monitoring module) that can help in managing of medications that can be lost or misplaced (intentionally or unintentionally) during dispensing of the medications, e.g., from an ADM based on a patient’s medication (see para [0005] of Lafauci).
Bastide, Cruise and Lafauci teach ---
a blockchain database communicatively connected to the data exchange module and configured to store the plurality of FHIR authorized data;
(see at least: Bastide ibidem and citations listed above to include ‘medical data exchange’, ‘FHIR’, ‘communicatively connected to a server’ and ‘raw medical data of a first format’ plus ‘authorized data’)
(see at least: Cruise ibidem and citations listed above to include ‘medical claim settlement’)
(see at least: Lafauci ibidem and citations listed above to include ‘a data exchange module’; and para [0085] about {“……… The medication monitoring module can direct data entry and/or data streaming to and from a database operatively coupled to the medication monitoring module. Such database can be, for example, …… (iii) a collective database (e.g., a centralized database, a blockchain database, etc.) that is in digital communication with a plurality of medication monitoring modules operable in a plurality of user devices.”}; which together are the same as claimed limitations above to include ‘a blockchain database module’)
Bastide, Cruise and Lafauci teach ---
a service-provider server communicatively connected to the data exchange module and the blockchain database, and is configured to provide a claim settlement based on the plurality of FHIR authorized data; and
(see at least: Bastide ibidem and citations listed above to include ‘medical data exchange’, ‘FHIR’, ‘communicatively connected to a server’ and ‘raw medical data of a first format’; plus ‘authorized data’; and para [0036] for ‘an enterprise server’/ ‘a server’ and ‘service device 140 may be utilized by a service user providing a related service’; and para [0065] about {“On-demand self-service: a cloud consumer can unilaterally provision computing capabilities, such as server time and network storage, as needed automatically without requiring human interaction with the service's provider.”}; which together are the same as claimed limitations above to include ‘a service-provider server’)
(see at least: Cruise ibidem and citations listed above to include ‘medical claim settlement’; and para [0073] about {“It is preferable that the claims management system 30 have access to the health care service provider system 20 for making all required payments and adjustments. There are several ways to interact with any computer database system. Some health care service provider systems may employ proprietary tools designed for exactly this purpose. …… There is also a standard called ODBC (Open Database Connectivity) that certain health care service provider systems may require. So an application makes calls to a database server for records to read and sends data to the database server to write.”}; which together are the same as claimed limitations above to include ‘a service-provider server’)
(see at least: Lafauci ibidem and citations listed above to include ‘a data exchange module’; and ‘a blockchain database communicatively connected’)
Bastide, Cruise and Lafauci teach ---
an authority management module communicatively connected to the data exchange module and the service-provider server,
and is programmed with instructions to execute a method for managing each of the FHIR authorized data transmitted among the data exchange module, the blockchain database, and the service-provider server, wherein the method comprises,
(see at least: Bastide ibidem and citations listed above to include ‘medical data exchange’, ‘FHIR’, ‘communicatively connected to a server’ and ‘raw medical data of a first format’ plus ‘authorized data’ and ‘a service-provider server’)
(see at least: Cruise ibidem and citations listed above to include ‘medical claim settlement’ and ‘a service-provider server’; and management module 80; which together are the same as claimed limitations above to include ‘an authority management module’)
(see at least: Lafauci ibidem and citations listed above to include ‘a data exchange module’; and ‘a blockchain database communicatively connected’; and para [0209] for “the term “medication monitoring module” can be used generally as a “monitoring module” to monitor management”; which together are the same as claimed limitations above to include ‘an authority management module’)
Bastide, Cruise and Lafauci teach ---
(a) receiving (a first public key and a first private key) from the server, and (a second public key and a second private key) from the service-provider server, respectively;
(see at least: Bastide ibidem and citations listed above to include ‘medical data exchange’, ‘FHIR’, ‘communicatively connected to a server’ and ‘raw medical data of a first format’ plus ‘authorized data’ and ‘a service-provider server’)
(see at least: Cruise ibidem and citations listed above to include ‘medical claim settlement’ and ‘a service-provider server’; and ‘an authority management module’)
(see at least: Lafauci ibidem and citations listed above to include ‘a data exchange module’; and ‘a blockchain database communicatively connected’; and ‘an authority management module’)
Bastide, Cruise and Lafauci teach as disclosed above, but they may not explicitly disclose about ‘a first public key and a first private key’ and ‘a second public key and a second private key’. However, Yun teaches them explicitly.
(see at least: Yun Abstract and Description of Embodiments (Summary) in paras [0005]-[0023]; and para [0070] about {“The first token remittance electronic wallet 221 included in the first electronic wallet 220 of the first user generates a pair <PrK1, PuK1> of a first private key PrK1 and a first public key PuK1 and generates (or derives) a first user's first address U1A1 from the first public key PuK1 (or by applying a hash function to the first public key PuK1) in operation S110-1.”}; and para [0072] about {“The second token remittance electronic wallet 323 included in the second electronic wallet 320 of the second user generates a pair <PrK2, PuK2> of a second private key PrK2 and a second public key PuK2 and generates (or derives) a second user's second address U2A2 from the second public key PuK2 (or by applying a hash function to the second public key PuK2) in operation S110-2.”}; and paras [0079]-[0080] about {“The first token remittance electronic wallet 221 included in the first electronic wallet 220 of the first user generates a pair <PrK1, PuK1> of the first private key PrK1 and the first public key PuK1 in operation S110a. ………”}; and paras [0081]-[0082] about {“The second token remittance electronic wallet 323 included in the second electronic wallet 320 of the second user generates the pair <PrK2, PuK2> of the second private key PrK2 and the second public key PuK2 in operation S110b. ………”}; which together are the same as claimed limitations above to include ‘a first public key and a first private key’ and ‘a second public key and a second private key’)
It would have been obvious prior to the time of the effective filing date of the claimed invention to have an ordinary person of skill in the art to modify the teachings of Bastide, Cruise and Lafauci with the teachings of Yun. The motivation to combine these references would be to manage medical data may utilize a code system in which a condition, disease, or other medically related issue may be represented with a code in light of the dynamic nature of utilizing codes for medical data and the use of the codes in various medically related services (e.g., maintaining medical charts) and associated services (e.g., billing), conventional approaches have configured ways of tracking the medical data (see paras [0003]-[0004] of Bastide), and to provide the physician practice to communicate only via the clearinghouse with the insurer and never has a direct link with processes going on at the insurer, and does not know how the reports from the clearinghouse mesh with processes that are followed by the insurer in handling claims from the physician practice (see para [0031] of Cruise), and to provide ADM (automated dispending machine aka medication monitoring module) that can help in managing of medications that can be lost or misplaced (intentionally or unintentionally) during dispensing of the medications, e.g., from an ADM based on a patient’s medication (see para [0005] of Lafauci), and to ensure anonymity of a transaction in a blockchain, a blockchain records only the transaction history between blockchain addresses including numbers, but information about the owner of each of the blockchain addresses is not recorded (see para [0004] of Yun).
Bastide, Cruise, Lafauci and Yun teach ---
(b) combining the first private key and the second public key of step (a) to produce a key;
(c) encrypting each of the FHIR authorized data with the key produced in step (b) to produce a ciphered FHIR authorized data;
(d) providing a signature to the ciphered FHIR authorized data of step (c) by use of the first private key, thereby producing a signed FHIR authorized data;
(see at least: Bastide ibidem and citations listed above to include ‘medical data exchange’, ‘FHIR’, ‘communicatively connected to a server’ and ‘raw medical data of a first format’ plus ‘authorized data’ and ‘a service-provider server’; and code system 100 cited above for ‘ciphered data’ per BRI rules)
(see at least: Cruise ibidem and citations listed above to include ‘medical claim settlement’ and ‘a service-provider server’; and ‘an authority management module’)
(see at least: Lafauci ibidem and citations listed above to include ‘a data exchange module’; and ‘a blockchain database communicatively connected’; and ‘an authority management module’; and para [0142] about {“…… In some cases, data stored in the blockchain can be included in integrity checks, in which transactions are assembled into a transaction merkle tree and hashed to produce a block header. Any alterations to transactions in a blockchain database can become apparent as the block would be invalid when indexed. As such, the blockchain's consensus mechanism can allow a data's hash to be published to the blockchain as irrefutable proof that the data existed at a given time in the past. Both the timestamp and the hash may be unalterable.”}; which together are the same as claimed limitations above to include ‘encrypting data’ and ‘ciphered data’ per BRI rules)
(see at least: Yun ibidem and citations listed above to include ‘a first public key and a first private key’ and ‘a second public key and a second private key’; and para [0118] about {“As shown in FIGS. 6, 8, and 10, information (M1-1, RI2-1, MSGa, or MSGb), which is transmitted from the relay server 600 to an electronic wallet (321 or 223), may include sender information, receiver information, and remittance amount, and the relay server 600 may digitally sign the information (RI1-1, RI2-1, MSGa, or MSGb) with the key thereof (e.g., a private key allocated in each blockchain network (400 or 500) and transmit digitally signed information to the electronic wallet (321 or 223). At this time the electronic wallet (321 or 223) may decode or decipher the digitally signed information with the public key of the relay server 600 and check whether the content of the information (M1-1, RI2-1, MSGa, or MSGb) is correct.”}; and para [0173] about {“According to embodiments, the first token remittance electronic wallet 221 may create a first transaction, which includes the first token sender information (U1A1), the first identification information SAD1 of the relay server 600, and the first token TA1, generate a digitally signed first transaction STSa by digitally signing the first transaction TSa with the first private key PrK1, and generate the first remittance information RI3, which includes the first token sender information (U1A1), the first identification information SAD1 of the relay server 600, the first token TA1, the digitally signed first transaction STSa, and the first public key PuK1. In other words, the first token remittance electronic wallet 221 performs remittance with the relay server 600 as a receiver.”}; and para [0178] about {“According to embodiments, the second token remittance electronic wallet 323 may create a second transaction, which includes the second token sender information (U2A2), the second identification information SAD2 of the relay server 600, and the second token TA2, generate a digitally signed second transaction STSb by digitally signing the second transaction TSb with the second private key PrK2, and generate the second remittance information RI4, which includes the second token sender information (U2A2), the second identification information SAD2 of the relay server 600, the second token TA2, the digitally signed second transaction STSb, and the second public key PuK2. In other words, the second token remittance electronic wallet 323 performs remittance with the relay server 600 as a receiver.”}; which together are the same as claimed limitations above in steps (b)/(c)/(d) above)
Bastide, Cruise, Lafauci and Yun teach ---
(e) verifying the signed FHIR authorized data of step (d) by use of the first public key to validate and rescind the signature, thereby restoring the ciphered FHIR authorized data of step (c); and
(f) decrypting the ciphered FHIR authorized data of step (e) with the key of step (b) to obtain the FHIR authorized data that has been decrypted, wherein the key is produced by combining the second private key and the first public key of step (a);
wherein the FHIR standard data has a second format that differs from the first format of the plurality of raw medical data.
(see at least: Bastide ibidem and citations listed above to include ‘medical data exchange’, ‘FHIR’, ‘communicatively connected to a server’ and ‘raw medical data of a first format’ plus ‘a service-provider server’; and code system 100 cited above for ‘ciphered data’; and para [0045] about {“…… The analytical portion of the retroactive code system 100 may enter the data into a data table where the data is extracted from the standard format into an analytical format. …”}; which together are the same as claimed limitations above to include ‘decrypting … data’ (extract being synonym for decrypt) per BRI rules)
(see at least: Cruise ibidem and citations listed above to include ‘medical claim settlement’ and ‘a service-provider server’; and ‘an authority management module’)
(see at least: Lafauci ibidem and citations listed above to include ‘a data exchange module’; and ‘a blockchain database communicatively connected’; and ‘an authority management module’; and ‘encrypting data’ and ‘ciphered data’; and para [0088] about {“…… Thus, identity and/or a quantity of the medications being disposed can be verified, confirmed, or rewarded in real-time or near real-time prior to actual verification of the disposed medications by a third party. …”}; which together are the same as claimed limitations above to include ‘verifying data’; AND para [0182] about {“…… The GUI may be operatively coupled to a centralized database as disclosed herein, to search for the obtained medication identifier to receive/extract relevant information about the medication.”}; which together are the same as claimed limitations above to include ‘decrypting … data’ (extract being synonym for decrypt) per BRI rules)
(see at least: Yun ibidem and citations listed above to include ‘a first public key and a first private key’ and ‘a second public key and a second private key’)
Dependent Claims 2 and 5-7 are rejected under 35 USC 103 as unpatentable over Bastide in view of Cruise, Lafauci and Yun as applied to the rejection of independent Claim 1 above, and as described below for each claim/ limitation.
With respect to Claim 2, Bastide, Cruise, Lafauci and Yun teach ---
2. The system of claim 1, wherein the mapping instruction is produced through self-defining the FHIR standard data of the second format.
(see at least: Bastide ibidem and citations listed above to include ‘medical data exchange’, ‘FHIR’, ‘communicatively connected to a server’ and ‘raw medical data of a first format’ plus ‘authorized data’ and ‘a service-provider server’; and code system 100 cited above for ‘ciphered data’ per BRI rules)
(see at least: Cruise ibidem and citations listed above to include ‘medical claim settlement’ and ‘a service-provider server’; and ‘an authority management module’)
(see at least: Lafauci ibidem and citations listed above to include ‘a data exchange module’; and ‘a blockchain database communicatively connected’; and ‘an authority management module’)
(see at least: Yun ibidem and citations listed above to include ‘a first public key and a first private key’ and ‘a second public key and a second private key’)
With respect to Claim 5, Bastide, Cruise, Lafauci and Yun teach ---
5. The system of claim 1, wherein after step (c) and/or after step (d) of the method, the method further comprises transmitting the ciphered FHIR authorized data of step (c), the signed FHIR authorized data of step (d), or a combination thereof to the blockchain database.
(see at least: Bastide ibidem and citations listed above to include ‘medical data exchange’, ‘FHIR’, ‘communicatively connected to a server’ and ‘raw medical data of a first format’ plus ‘authorized data’ and ‘a service-provider server’; and code system 100 cited above for ‘ciphered data’ per BRI rules)
(see at least: Cruise ibidem and citations listed above to include ‘medical claim settlement’ and ‘a service-provider server’; and ‘an authority management module’)
(see at least: Lafauci ibidem and citations listed above to include ‘a data exchange module’; and ‘a blockchain database communicatively connected’; and ‘an authority management module’)
(see at least: Yun ibidem and citations listed above to include ‘a first public key and a first private key’ and ‘a second public key and a second private key’)
With respect to Claim 6, Bastide, Cruise, Lafauci and Yun teach ---
6. The system of claim 5, wherein after step (c) of the method, the method further comprises:
calculating the ciphered FHIR authorized data to produce a hash value; and
transmitting the hash value to the blockchain database.
(see at least: Bastide ibidem and citations listed above to include ‘medical data exchange’, ‘FHIR’, ‘communicatively connected to a server’ and ‘raw medical data of a first format’ plus ‘authorized data’ and ‘a service-provider server’; and code system 100 cited above for ‘ciphered data’ per BRI rules)
(see at least: Cruise ibidem and citations listed above to include ‘medical claim settlement’ and ‘a service-provider server’; and ‘an authority management module’)
(see at least: Lafauci ibidem and citations listed above to include ‘a data exchange module’; and ‘a blockchain database communicatively connected’; and ‘an authority management module’; and para [0141] about {“…… The term “blockchain,” as used herein, can refer to a suite of distributed ledger technologies that can be programmed to record and track anything of value (e.g., financial transactions, land titles, medical records, etc.). ……… Thus, each block can contain a cryptographic hash of the previous block to keep the previous block “accountable.”}; which together are the same as claimed limitations above to include ‘a/ the hash value’)
(see at least: Yun ibidem and citations listed above to include ‘a first public key and a first private key’ and ‘a second public key and a second private key’)
With respect to Claim 7, Bastide, Cruise, Lafauci and Yun teach ---
7. The system of claim 6, wherein the service-provider server further comprises a data verification unit communicatively connected to the blockchain database and is configured to calculate the ciphered FHIR authorized data to produce a checksum and to verify the consistency between the hash value and the checksum.
(see at least: Bastide ibidem and citations listed above to include ‘medical data exchange’, ‘FHIR’, ‘communicatively connected to a server’ and ‘raw medical data of a first format’ plus ‘authorized data’ and ‘a service-provider server’; and code system 100 cited above for ‘ciphered data’ per BRI rules)
(see at least: Cruise ibidem and citations listed above to include ‘medical claim settlement’ and ‘a service-provider server’; and ‘an authority management module’)
(see at least: Lafauci ibidem and citations listed above to include ‘a data exchange module’; and ‘a blockchain database communicatively connected’; and ‘an authority management module’ plus ‘a/ the hash value’)
(see at least: Yun ibidem and citations listed above to include ‘a first public key and a first private key’ and ‘a second public key and a second private key’)
Dependent Claims 3-4 are rejected under 35 USC 103 as unpatentable over Bastide in view of Cruise, Lafauci and Yun as applied to the rejection of Claims 1-2 and 5-7 above, and further in view of Pub. No. US 2023/ 0317260 filed by Zahora et al. (hereinafter “Zahora”), and as described below for each claim/ limitation.
With respect to Claim 3, Bastide, Cruise, Lafauci and Yun teach ---
3. The system of claim 2, wherein the first format is (an extensible markup language (XML) format), and the second format is (a JavaScript object notation (JSON) format).
(see at least: Bastide ibidem and citations listed above to include ‘medical data exchange’, ‘FHIR’, ‘communicatively connected to a server’ and ‘raw medical data of a first format’ plus ‘authorized data’ and ‘a service-provider server’; and code system 100 cited above for ‘ciphered data’ per BRI rules)
(see at least: Cruise ibidem and citations listed above to include ‘medical claim settlement’ and ‘a service-provider server’; and ‘an authority management module’)
(see at least: Lafauci ibidem and citations listed above to include ‘a data exchange module’; and ‘a blockchain database communicatively connected’; and ‘an authority management module’)
(see at least: Yun ibidem and citations listed above to include ‘a first public key and a first private key’ and ‘a second public key and a second private key’)
Bastide, Cruise, Lafauci and Yun teach as disclosed above, but they may not explicitly disclose about ‘an extensible markup language (XML) format’ and ‘a JavaScript object notation (JSON) format’. However, Zahora teaches them explicitly.
(see at least: Zahora Abstract and Summary of Illustrative Embodiments in paras [0005]-[0044]; and para [0110] about {“…… For example, the integration platform 194 may convert a comma separated values (CSV) format, an extensible markup language (XML) or other text file format, or JavaScript® Object Notation (JSON) formatted files to the communication standard. …”}; which together are the same as claimed limitations above to include ‘an extensible markup language (XML) format’ and ‘a JavaScipt object notation (JSON) format’)
It would have been obvious prior to the time of the effective filing date of the claimed invention to have an ordinary person of skill in the art to modify the teachings of Bastide, Cruise, Lafauci and Yun with the teachings of Zahora. The motivation to combine these references would be to manage medical data may utilize a code system in which a condition, disease, or other medically related issue may be represented with a code in light of the dynamic nature of utilizing codes for medical data and the use of the codes in various medically related services (e.g., maintaining medical charts) and associated services (e.g., billing), conventional approaches have configured ways of tracking the medical data (see paras [0003]-[0004] of Bastide), and to provide the physician practice to communicate only via the clearinghouse with the insurer and never has a direct link with processes going on at the insurer, and does not know how the reports from the clearinghouse mesh with processes that are followed by the insurer in handling claims from the physician practice (see para [0031] of Cruise), and to provide ADM (automated dispending machine aka medication monitoring module) that can help in managing of medications that can be lost or misplaced (intentionally or unintentionally) during dispensing of the medications, e.g., from an ADM based on a patient’s medication (see para [0005] of Lafauci), and to ensure anonymity of a transaction in a blockchain, a blockchain records only the transaction history between blockchain addresses including numbers, but information about the owner of each of the blockchain addresses is not recorded (see para [0004] of Yun), and to permit claims submission and processing involves many complex steps to move from initiating claims preparation to receiving payment and involves numerous entities and databases (see para [0004] of Zahora).
With respect to Claim 4, Bastide, Cruise, Lafauci, Yun and Zahora teach ---
4. The system of claim 3, wherein the converter is an XML to JSON converter.
(see at least: Bastide ibidem and citations listed above to include ‘medical data exchange’, ‘FHIR’, ‘communicatively connected to a server’ and ‘raw medical data of a first format’ plus ‘authorized data’ and ‘a service-provider server’; and code system 100 cited above for ‘ciphered data’ per BRI rules)
(see at least: Cruise ibidem and citations listed above to include ‘medical claim settlement’ and ‘a service-provider server’; and ‘an authority management module’; and para [0105] for JAVA and about {“…. The source code may be in a computer executable form (e.g., via an interpreter), or the source code may be converted (e.g., via a translator, assembler, or compiler) into a computer executable form. …”}; which are similar to claimed limitations above to include ‘JSON converter’)
(see at least: Lafauci ibidem and citations listed above to include ‘a data exchange module’; and ‘a blockchain database communicatively connected’; and ‘an authority management module’)
(see at least: Yun ibidem and citations listed above to include ‘a first public key and a first private key’ and ‘a second public key and a second private key’)
(see at least: Zahora ibidem and citations listed above and para [0110] for “convert from one format to another format”; which together are the same as claim limitations above to include ‘an
XML to JSON converter’)
With respect to Claims 8-12, the limitations of these method claims are rejected under 35 USC 103 based on the exemplary analysis above for the rejection of system Claims 1-7 as described above using cited references of Bastide, Cruise, Lafauci, Yun and Zahora, because the limitations of these method Claims 8-12 are commensurate in scope to limitations, and thus duplicates, of the above rejected system Claims 1-7 as described above.
Conclusion
The prior art made of record and not relied upon, listed in Form 892, that is considered pertinent to the Applicant's disclosure and review for not traversing already issued patents and/or claimed inventions by the claims of the current invention of the Applicant. Examiner notes that Form 892 contains more references than those cited in the rejection above under 35 USC 103, and that all the references cited on said Form 892 are relevant to this application and form a part of the body of prior art.
The Examiner has pointed out particular references contained in the prior art of record in the body of this action for the convenience of the Applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. The Applicant should consider the entire prior art as applicable as to the limitations of the claims.
Any inquiry concerning this communication or earlier communications from the Examiner should be directed to Sanjeev Malhotra whose telephone number is (571) 272-7292. The Examiner can normally be reached during Monday-Friday between 8:30-17:00 hours on a Flexible schedule.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, the Applicant is encouraged to contact the Examiner directly.
If attempts to reach the Examiner by telephone are unsuccessful, the examiner’s
supervisor, Abhishek Vyas, can be reached on (571) 270-1836. The facsimile/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 & 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.
Electronic Communications
Prior to initiating the first e-mail correspondence with an Examiner, Applicant is responsible for filing a written statement with the USPTO in accordance with MPEP §502.03(II). All received e-mail messages including e-mail attachments shall be placed into this application’s record. The Examiner’s e-mail address is provided below at the end of this Office Action.
/S.M./
Examiner, Art Unit 3691
sanjeev.malhotra@uspto.gov
/HANI M KAZIMI/Primary Examiner, Art Unit 3691