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 .
Request for Continued Examination
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 12 January 2026 has been entered.
DETAILED ACTION
The present Office Action is in response to the Request for Continued Examination dated 12 January 2026.
In the RCE filed 12 January 2026:
Claims 18-20 are new
Claims 1, 13-14 are amended
Claims 1-20 are pending
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more.
Claims 1, 13-14 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Step 1
The claims recite a method, system and computer program product, which are within a statutory category.
The limitations of:
Claims 1, 13-14 (Claim 13 being representative)
receiving a request from a user for one or more healthcare records;
receiving a selection of one or more secure providers from the user, the one or more secure providers selected from a […first location storing…] secure providers;
retrieving the one or more healthcare records from […a second location…];
combining the one or more healthcare records into a healthcare record package;
generating a hash based on the healthcare record package;
transmitting the healthcare record package to the one or more secure providers;
recording the user, the one or more secure providers, and the hash at a […third location…];
analyzing the […third location…] for unusual transactions;
and providing an alert to the user that an unusual transaction has occurred,
as drafted, is a process that, under the broadest reasonable interpretation, covers certain methods of organizing human activity (i.e., managing personal behavior including following rules or instructions) but for recitation of generic computer components. The claims encompass a series of rules or instructions for a person or persons to follow, with or without the aid of a computer, to transferring and sharing healthcare data in the blockchain in the manner described in the identified abstract idea, supra. The rules or instructions are the claimed steps of “receiving, retrieving, combining, generating, transmitting, recording, analyzing and providing” as indicated supra.
Other than reciting generic computer components (discussed infra), i.e., a system and method implemented by a data processor (computer), the claimed invention amounts to managing personal behavior or interaction between people. If a claim limitation, under its broadest reasonable interpretation, covers managing personal behavior or interactions between people but for the recitation of generic computer components, then it falls within the “certain methods of organizing human activity” grouping of abstract ideas. Accordingly, the claim recites an abstract idea.
Step 2A2
This judicial exception is not integrated into a practical application. In particular, the claims recite the additional elements of a processor and computer readable storage medium that implements the identified abstract idea. The server is not described by the applicant and is recited at a high-level of generality (i.e., a generic server performing generic computer functions) such that it amounts no more than mere instructions to apply the exception using a generic computer component. Accordingly, this additional element does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea.
The claims further recite the additional element of a healthcare record database, dynamic database and blockchain ledger having blocks. The healthcare record database, dynamic database and blockchain ledger having blocks merely generally links the abstract idea to a particular technological environment or field of use. MPEP 2106.04(d)(I) indicates that generally linking an abstract idea to a particular technological environment or field of use cannot provide a practical application. Accordingly, even in combination, these additional elements do not integrate the abstract idea into a practical application.
Step 2B
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements of using a processor and computer readable storage medium to perform the noted steps amounts to no more than mere instructions to apply the exception using a generic computer component. Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept (“significantly more”).
Also, as discussed above with respect to integration of the abstract idea into a practical application, the additional elements of a healthcare record database, dynamic database and blockchain ledger having blocks was determined to generally link the abstract idea to a particular technological environment or field of use. This has been re-evaluated under the “significantly more” analysis and has also been found insufficient to provide significantly more. MPEP 2106.05(A) indicates that generally linking an abstract idea to a particular technological environment or field of use cannot provide significantly more. Specifically regarding the blockchain ledger, the Examiner further notes that the court in Rady v. Boston Consulting Group, Inc., No. 2022-2218, slip op. at 9 (Fed. Cir., March 27, 2024) held that blockchain technology is well-understood, routine, and conventional. Well-understood, routine, and conventional elements cannot provide significantly more. As such the claims are not patent eligible.
Claims 2-12,15-20 are similarly rejected because they either further define/narrow the abstract idea and/or do not further limit the claim to a practical application or provide as inventive concept such that the claims are subject matter eligible even when considered individually or as an ordered combination.
Claim(s) 2-3 merely describe(s) what the healthcare record package contains, which further defines the abstract idea.
Claim(s) 4 merely describe(s) what the token contains, which further defines the abstract idea.
Claim(s) 5 merely describe(s) generating hash data, which further defines the abstract idea.
Claim(s) 6 merely describe(s) generation transaction log, which further defines the abstract idea. The claim also includes the additional element of “a log database” which is analyzed the same as the “a healthcare record database” and does not provide a practical application or significantly more for the same reasons.
Claim(s) 7 merely describe(s) receiving an audit request, which further defines the abstract idea.
Claim(s) 8 merely describe(s) querying a blockchain ledger, which further defines the abstract idea.
Claim(s) 7-8 also includes the additional element of “a blockchain ledger” which is analyzed the same as the “a blockchain ledger” in the independent claims and does not provide a practical application or significantly more for the same reasons.
Claim(s) 9 merely describe(s) providing the hash, which further defines the abstract idea.
Claim(s) 10 merely describe(s) comparing tokens for verification, which further defines the abstract idea.
Claim(s) 11 merely describe(s) what the medical record database contains, which further defines the abstract idea. Claim(s) 11 also includes the additional element of “a electronic health record server” which is analyzed the same as the “a health record database” and does not provide a practical application or significantly more for the same reasons.
Claim(s) 12 merely describe(s) data not included in the block, which further defines the abstract idea.
Claim(s) 15 merely describe(s) the secure providers in the dynamic database, which further defines the abstract idea.
Claim(s) 16-17 merely describe(s) healthcare record requests, which further defines the abstract idea.
Claim(s) 18-20 merely describe(s) analyzing the ledger for unusual transactions, which further defines the abstract idea.
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.
The Examiner notes that the rejection will reference the translated documents (attached) corresponding to any foreign documents recited in the rejection.
Claims 1-4,12-14,16,18-20 is/are rejected under 35 U.S.C. 103(a) as being unpatentable over GUILLAMA et al (US Publication No. 20200374125) in view of Raduchel et al (US Publication No. 20190208354) in view of SALIMAN et al (US Publication No. 20200005912) in view of Giordano et al (US Publication No. 20170300627).
Regarding Claim 1
GUILLAMA teaches a method comprising:
receiving a request from a user for one or more healthcare records [GUILLAMA at Para. 0006 teaches the method can include receiving, at a first computing device, a request from a second computing device to access at least one electronic health record in a database of electronic health records.];
retrieving the one or more healthcare records from a healthcare record database [GUILLAMA at Para. 0006];
transmitting the healthcare record package to the one or more secure providers [GUILLAMA at Para. 0021 teaches the present disclosure is directed to systems and method for electronically transferring and accessing healthcare records. Patients, who correspond to the healthcare records, can be incentivized to share their electronic healthcare records with health care providers, research institutions, or other parties];
recording the user, the one or more secure providers, and the hash at a block in a blockchain ledger [GUILLAMA at Para. 0082 teaches in greater detail, each block in the chain contains a cryptographic hash of the previous block, a timestamp, and transaction data (generally referred to as a “Merkle Tree” root hash)];
GUILLAMA does not teach receiving a selection of one or more secure providers from the user, the one or more secure providers selected from a dynamic database of secure providers;
combining the one or more healthcare records into a healthcare record package;
generating a hash based on the healthcare record package;
analyzing the blockchain ledger for unusual transactions;
and providing an alert to the user that an unusual transaction has occurred.
Raduchel teaches receiving a selection of one or more secure providers from the user, the one or more secure providers selected from a dynamic database of secure providers [Raduchel at Para. 0059 teaches in this example, the user may configure the list of approved or certified medical service providers, as stored at the particular storage system. The user may further issue a credential token to each of the approved or certified medical service providers, as an illustration, using a private key of the user. The credential token may be issued to a particular approved or certified medical service provider encrypted using a public key of the particular approved or certified medical service provider so that only the particular approved or certified medical service provider may decrypt the encrypted credential; Raduchel at Para. 0216 teaches in an exemplary embodiment, the user electronic device 130 compares the captured physical location with the address data of the healthcare providers 1440, 1450, or 1460 (1530). In this embodiment, the physical location captured by user electronic device 130 is converted to a street address. Each field of the converted street address is then compared to the equivalent fields of known healthcare providers, such as the healthcare providers 1440, 1450, and 1460. This comparison can be assisted by utilizing a database of healthcare provider addresses. This comparison can also be assisted by utilizing a list of healthcare providers that have previously interacted with the user (interpreted as dynamic database of secure providers)];
It would have been prima facie obvious skill in the art, at the time of effective filing, to combine blockchain of GUILLAMA with the providers of Raduchel with the motivation to improve possible inefficiencies in current medical practice.
GUILLAMA/Raduchel do not teach combining the one or more healthcare records into a healthcare record package;
generating a hash based on the healthcare record package;
analyzing the blockchain ledger for unusual transactions;
and providing an alert to the user that an unusual transaction has occurred.
SALIMAN teaches combining the one or more healthcare records into a healthcare record package [SALIMAN at Para. 0010 teaches in some instances, an indication of fulfillment of the condition may be packaged for storage on the blockchain. This packaging may include association of patient information and/or a patient identifier. Then, the packaged indication may be broadcast to the blockchain];
It would have been prima facie obvious skill in the art, at the time of effective filing, to combine the references of GUILLAMA, Raduchel with the package of SALIMAN with the motivation to increase privacy for patients.
GUILLAMA/Raduchel/SALIMAN
GUILLAMA/Raduchel/SALIMAN do not teach generating a hash based on the healthcare record package;
analyzing the blockchain ledger for unusual transactions;
and providing an alert to the user that an unusual transaction has occurred.
Giordano teaches generating a hash based on the healthcare record package [Giordano at Para. 0008 teaches the signature included in each respective group of records can include a hash value of the group of records that immediately precedes the respective group of records in the chronological ordering of the groups of records];
analyzing the blockchain ledger for unusual transactions; and providing an alert to the user that an unusual transaction has occurred [Giordano at Para. 0088 teaches FIG. 7 depicts a flow of transactions, calls, and smart contract executions in an example process 700 for performing fraud detection on a distributed network for records management. In some implementations, the network may include one or more smart contracts that are configured to analyze transactions that have occurred in the network over a period of time and to flag transactions that are related to potentially fraudulent activity (or otherwise abnormal activity)].
It would have been prima facie obvious skill in the art, at the time of effective filing, to combine the references of GUILLAMA, Raduchel, SALIMAN with the alert of Giordano with the motivation to improve medical record security.
Regarding Claim 2
GUILLAMA/Raduchel/SALIMAN/Giordano teach the method of claim 1,
GUILLAMA/Raduchel/SALIMAN/Giordano further teach wherein the healthcare record package comprises a token associated with the user [Raduchel at Para. 0065 teaches in some implementations, the authentication token may include authentication credentials for the user 120 associated with the request for records or a medical service provider].
Regarding Claim 3
GUILLAMA/Raduchel/SALIMAN/Giordano teach the method of claim 2,
GUILLAMA/Raduchel/SALIMAN/Giordano further teach wherein the healthcare record package comprises one or more additional tokens associated with the selected one or more secure providers [Raduchel at Para. 0164 teaches the patient electronic device 930 may periodically receive updated authentication information (e.g., passwords, tokens, etc.) for licensed/authorized emergency services providers or may request and receive authentication information (e.g., passwords, tokens, etc.)].
Regarding Claim 4
GUILLAMA/Raduchel/SALIMAN/Giordano teach the method of claim 2,
GUILLAMA/Raduchel/SALIMAN/Giordano further teach wherein each token comprises a unique identifier [GUILLAMA at Para. 0041 teaches in some examples of step 340, the generated token can be an unencrypted unique number or value].
Regarding Claim 12
GUILLAMA/Raduchel/SALIMAN/Giordano teach the method of claim 1,
GUILLAMA/Raduchel/SALIMAN/Giordano further teach wherein the block does not include any data from the one or more healthcare records [GUILLAMA at Para. 0006 teaches the block can include a cryptographic hash of a previous block, a timestamp, and transaction data related to the received request, and the at least one authorization requirement (interpreted as not having any data from one or more healthcare records)].
Regarding Claim 13
GUILLAMA teaches a system comprising:
a healthcare record database [GUILLAMA at Para. 0032 teaches in some embodiments, each electronic health record in the database of electronic health records can be automatically generated upon receiving health information from a user];
a computing node comprising a computer readable storage medium having program instructions embodied therewith, the program instructions executable by a processor of the computing node to cause the processor to perform a method comprising [GUILLAMA at Para. 0010 teaches the system includes one or more processors, and a memory coupled to the processors comprising instructions executable by the processors]:
receiving a request from a user for one or more healthcare records [GUILLAMA at Para. 0006 (see Claim 1 for explanation)];
retrieving the one or more healthcare records from the healthcare record database [GUILLAMA at Para. 0006 (see Claim 1 for explanation)];
transmitting the healthcare record package to the one or more secure providers [GUILLAMA at Para. 0021 (see Claim 1 for explanation)];
recording the user, the one or more secure providers, and the hash at a block in a blockchain ledger [GUILLAMA at Para. 0082 (see Claim 1 for explanation)];
GUILLAMA does not teach receiving a selection of one or more secure providers from the user, the one or more secure providers selected from a dynamic database of secure providers;
combining the one or more healthcare records into a healthcare record package;
generating a hash based on the healthcare record package;
analyzing the blockchain ledger for unusual transactions;
and providing an alert to the user that an unusual transaction has occurred.
Raduchel teaches receiving a selection of one or more secure providers from the user, the one or more secure providers selected from a dynamic database of secure providers [Raduchel at Para. 0059, 0216 (see Claim 1 for explanation)];
It would have been prima facie obvious skill in the art, at the time of effective filing, to combine blockchain of GUILLAMA with the providers of Raduchel with the motivation to improve possible inefficiencies in current medical practice.
GUILLAMA/Raduchel do not teach combining the one or more healthcare records into a healthcare record package;
generating a hash based on the healthcare record package;
analyzing the blockchain ledger for unusual transactions;
and providing an alert to the user that an unusual transaction has occurred.
SALIMAN teaches combining the one or more healthcare records into a healthcare record package [SALIMAN at Para. 0010 (see Claim 1 for explanation)];
It would have been prima facie obvious skill in the art, at the time of effective filing, to combine the references of GUILLAMA, Raduchel with the package of SALIMAN with the motivation to increase privacy for patients.
GUILLAMA/Raduchel/SALIMAN do not teach generating a hash based on the healthcare record package;
analyzing the blockchain ledger for unusual transactions;
and providing an alert to the user that an unusual transaction has occurred.
Giordano teaches generating a hash based on the healthcare record package [Giordano at Para. 0008 (see Claim 1 for explanation)];
analyzing the blockchain ledger for unusual transactions; and providing an alert to the user that an unusual transaction has occurred [Giordano at Para. 0088 (see Claim 1 for explanation)].
It would have been prima facie obvious skill in the art, at the time of effective filing, to combine the references of GUILLAMA, Raduchel, SALIMAN with the alert of Giordano with the motivation to improve medical record security.
Regarding Claim 14
GUILLAMA teaches a computer program product for continuous clinical evaluation and care adjustment, the computer program product comprising a computer readable storage medium having program instructions embodied therewith, the program instructions executable by a processor to cause the processor to perform a method comprising:
receiving a request from a user for one or more healthcare records [GUILLAMA at Para. 0006 (see Claim 1 for explanation)];
retrieving the one or more healthcare records from a healthcare record database [GUILLAMA at Para. 0006 (see Claim 1 for explanation)];
transmitting the healthcare record package to the one or more secure providers [GUILLAMA at Para. 0021 (see Claim 1 for explanation)];
recording the user, the one or more secure providers, and the hash at a block in a blockchain ledger [GUILLAMA at Para. 0082 (see Claim 1 for explanation)];
GUILLAMA does not teach receiving a selection of one or more secure providers from the user, the one or more secure providers selected from a dynamic database of secure providers;
combining the one or more healthcare records into a healthcare record package;
generating a hash based on the healthcare record package;
analyzing the blockchain ledger for unusual transactions;
and providing an alert to the user that an unusual transaction has occurred.
Raduchel teaches receiving a selection of one or more secure providers from the user, the one or more secure providers selected from a dynamic database of secure providers [Raduchel at Para. 0059, 0216 (see Claim 1 for explanation)];
It would have been prima facie obvious skill in the art, at the time of effective filing, to combine blockchain of GUILLAMA with the providers of Raduchel with the motivation to improve possible inefficiencies in current medical practice.
GUILLAMA/Raduchel do not teach combining the one or more healthcare records into a healthcare record package;
generating a hash based on the healthcare record package;
analyzing the blockchain ledger for unusual transactions;
and providing an alert to the user that an unusual transaction has occurred.
SALIMAN teaches combining the one or more healthcare records into a healthcare record package [SALIMAN at Para. 0010 (see Claim 1 for explanation)];
It would have been prima facie obvious skill in the art, at the time of effective filing, to combine the references of GUILLAMA, Raduchel with the package of SALIMAN with the motivation to increase privacy for patients.
GUILLAMA/Raduchel/SALIMAN do not teach generating a hash based on the healthcare record package;
analyzing the blockchain ledger for unusual transactions; and providing an alert to the user that an unusual transaction has occurred.
Giordano teaches generating a hash based on the healthcare record package [Giordano at Para. 0008 (see Claim 1 for explanation)];
analyzing the blockchain ledger for unusual transactions; and providing an alert to the user that an unusual transaction has occurred [Giordano at Para. 0088 (see Claim 1 for explanation)].
It would have been prima facie obvious skill in the art, at the time of effective filing, to combine the references of GUILLAMA, Raduchel, SALIMAN with the alert of Giordano with the motivation to improve medical record security.
Regarding Claim 16
GUILLAMA/Raduchel/SALIMAN/Giordano teach the method of claim 1,
GUILLAMA/Raduchel/SALIMAN/Giordano further teach wherein the request for one or more healthcare records comprises at least one portion of the healthcare record [GUILLAMA at Para. 0006 (see Claim 1 for explanation)].
Regarding Claim 18
GUILLAMA/Raduchel/SALIMAN/Giordano teach the method of claim 1,
GUILLAMA/Raduchel/SALIMAN/Giordano further teach wherein analyzing the blockchain ledger for unusual transactions comprises detecting abnormal data sharing [Giordano at Para. 0088 (see Claim 1 for explanation; abnormal activity interpreted as abnormal data sharing)].
Regarding Claim 19
GUILLAMA/Raduchel/SALIMAN/Giordano teach the method of claim 1,
GUILLAMA/Raduchel/SALIMAN/Giordano further teach wherein analyzing the blockchain ledger for unusual transactions comprises identifying a pattern of data sharing between the user and the one or more secure providers [Raduchel at Para. 0316 teaches in another example, the validity of the Healthcare Identity Graph data and electronic medical record data can be improved by capturing the history of all sharing transactions in a block chain].
Regarding Claim 20
GUILLAMA/Raduchel/SALIMAN/Giordano teach the method of claim 1,
GUILLAMA/Raduchel/SALIMAN/Giordano further teach wherein analyzing the blockchain ledger for unusual transactions comprises identifying a location for the user and the one or more secure providers [Raduchel at Para. 0004 teaches in one general sense, techniques and systems are described for aggregating medical records for a user. Methods, systems, and computer-readable media are disclosed for receiving, at a wireless device of a patient, first location data indicating a location of the wireless device, accessing, by the wireless device, second location data indicating locations of one or more healthcare providers, determining, by the wireless device and based at least on a comparison of the location of the wireless device to the one or more locations of the one or more healthcare providers, that the location of the patient corresponds to a location of a particular healthcare provider, calculating, by the wireless device, at least one of an updated score, a priority, or an outcome probability in response to determining that the location of the patient corresponds to the location of the particular healthcare provider, transmitting, from the wireless device to a recipient electronic device, at least one of an alert, an electronic medical record of the patient, or a recommendation based at least on the calculation of the at least one of the updated score, the priority, or the outcome probability, and transmitting, from the wireless device, authentication information for the at least one of the alert, the electronic medical record of the patient, or the recommendation].
Claims 5, 11 rejected under 35 U.S.C. 103(a) as being unpatentable over GUILLAMA, Raduchel, SALIMAN, Giordano as applied to claim 1,13-14 above, and further in view of Curbera et al (US Publication No. 20180082024).
Regarding Claim 5
GUILLAMA/Raduchel/SALIMAN/Giordano teach the method of claim 1,
GUILLAMA/Raduchel/SALIMAN/Giordano do not teach wherein generating the hash comprises hashing data within the healthcare record package.
Curbera teaches wherein generating the hash comprises hashing data within the healthcare record package [Curbera at Para. 0107 teaches if instead the exchange used record locators provided by the data exchange engine 224 based on the master patient record index 225, the releasing and receiving health providers log, into the CIMS 220, the release and receipt of the patient information, including the description of information being released and a unique hash value that is the fingerprint of the patient information or data being released, or in some illustrative embodiments a hash of the blockchain itself].
It would have been prima facie obvious skill in the art, at the time of effective filing, to combine the references of GUILLAMA, Raduchel, SALIMAN, Giordano with the hashing data of Curbera with the motivation to improve the patient and heath enterprise participant experience.
Regarding Claim 11
GUILLAMA/Raduchel/SALIMAN/Giordano teach the method of claim 1,
GUILLAMA/Raduchel/SALIMAN/Giordano do not teach wherein the medical record database comprises an electronic health record (EHR) server.
Curbera teaches wherein the medical record database comprises an electronic health record (EHR) server [Curbera at Para. 0087 teaches thus, in some illustrative embodiments, while all of the computing devices may implement elements 122, 124, 126, and 129, a single master server 104 may store the master patient record index (MPRI) that tracks the location of patient information and with which the other computing devices may need to interact in order to perform their operations for granting access to patient information, as described hereafter].
It would have been prima facie obvious skill in the art, at the time of effective filing, to combine the references of GUILLAMA, Raduchel, SALIMAN, Giordano with the server of Curbera with the motivation to improve the patient and heath enterprise participant experience.
Claims 6-10 rejected under 35 U.S.C. 103(a) as being unpatentable over GUILLAMA, Raduchel, SALIMAN, Giordano as applied to claim 1,13-14 above, and further in view of Simons et al (US Publication No. 20210144149).
Regarding Claim 6
GUILLAMA/Raduchel/SALIMAN/Giordano teach the method of claim 1,
GUILLAMA/Raduchel/SALIMAN/Giordano do not teach further comprising generating a transaction log for the recording in a log database.
Simons teaches further comprising generating a transaction log for the recording in a log database [Simons at Para. 0034 teaches when a transaction is recorded into the blockchain database, it is very difficult, if not impossible, to change or remove the transaction data from the database since the data is stored in more than one node in the distributed network].
It would have been prima facie obvious skill in the art, at the time of effective filing, to combine the references of GUILLAMA, Raduchel, SALIMAN, Giordano with the log of Simons with the motivation to improve security by only allowing access to the user if the user has authorization to access the portion of data from the blockchain entry.
Regarding Claim 7
GUILLAMA/Raduchel/SALIMAN/Giordano teach the method of claim 1,
GUILLAMA/Raduchel/SALIMAN/Giordano do not teach further comprising receiving, from the user, an audit request for a transaction recorded on the blockchain.
Simons teaches further comprising receiving, from the user, an audit request for a transaction recorded on the blockchain [Simons at Para. 0046 teaches in other examples, the received request to view the one or more data portions of the block entry comprises a financial auditing request].
It would have been prima facie obvious skill in the art, at the time of effective filing, to combine the references of GUILLAMA, Raduchel, SALIMAN, Giordano with the request of Simons with the motivation to improve security by only allowing access to the user if the user has authorization to access the portion of data from the blockchain entry.
Regarding Claim 8
GUILLAMA/Raduchel/SALIMAN/Giordano/Simons teach the method of claim 7,
GUILLAMA/Raduchel/SALIMAN/Giordano/Simons further teach further comprising querying the blockchain ledger based on the audit request [SALIMAN at Para. 0083 teaches in step 1015, a request to access medical notes for one or more patients may be received. Optionally, and step 1020, a request to receive billing information associated with the requested medical notes may also be received. One or more databases, and/or distributed ledgers, and/or blockchains that store medical notes, patient account information, electronic medical records, and/or billing information may then be accessed and queried for the requested information (step 1025)].
Regarding Claim 9
GUILLAMA/Raduchel/SALIMAN/Giordano/Simons teach the method of claim 8,
GUILLAMA/Raduchel/SALIMAN/Giordano/Simons further teach further comprising providing the hash in response to the audit request [GUILLAMA at Para. 0006 teaches the block can include a cryptographic hash of a previous block, a timestamp, and transaction data related to the received request, and the at least one authorization requirement].
Regarding Claim 10
GUILLAMA/Raduchel/SALIMAN/Giordano/Simons teach the method of claim 9,
GUILLAMA/Raduchel/SALIMAN/Giordano/Simons further teach further comprising comparing a recorded token to a user token to verify that the user was associated with the transaction [Raduchel at Para. 0065 teaches in these implementations, the storage system 140 may extract the authentication credentials from the authentication token, compare the authentication credentials with known authentication credentials for the user 120 or the medical service provider, and authenticate the first request based on the comparison].
Claim 15 rejected under 35 U.S.C. 103(a) as being unpatentable over GUILLAMA, Raduchel, SALIMAN, Giordano as applied to claim 1,13-14 above, and further in view of KOWALKIEWICZ et al (US Publication No. 20150100326).
Regarding Claim 15
GUILLAMA/Raduchel/SALIMAN/Giordano teach the method of claim 1,
GUILLAMA/Raduchel/SALIMAN/Giordano do not teach wherein the secure providers in the dynamic database of comprise enrolled providers within a health data share and protect system.
KOWALKIEWICZ teaches wherein the secure providers in the dynamic database of comprise enrolled providers within a health data share and protect system [KOWALKIEWICZ at Para. 0033 teaches a data repository 118 may be, for example, any database (e.g., relational database, in-memory database, etc.), an entity (e.g., set of related records), or a data set included in a database. In some implementations, data repository 118 serves to store data of healthcare providers (e.g., names, office address, contact information, specializations, etc.), reviews of healthcare providers (e.g., reviews by patients, ratings, etc.), national recommendation of healthcare schedule, users' information (e.g., health profiles, contact information, etc.), and so forth (interpreted to be secure providers)].
It would have been prima facie obvious skill in the art, at the time of effective filing, to combine the references of GUILLAMA, Raduchel, SALIMAN, Giordano with the providers of KOWALKIEWICZ with the motivation to improve the overall patient experience with the healthcare provider.
Claim 17 rejected under 35 U.S.C. 103(a) as being unpatentable over GUILLAMA, Raduchel, SALIMAN, Giordano as applied to claim 1,13-14 above, and further in view of ZHA et al ((Foreign Publication CN-109299369-A).
Regarding Claim 17
GUILLAMA/Raduchel/SALIMAN/Giordano teach the method of claim 16,
GUILLAMA/Raduchel/SALIMAN/Giordano do not teach further comprising recommending a subset of portions of the healthcare record to be requested.
ZHA teaches further comprising recommending a subset of portions of the healthcare record to be requested [ZHA at Page 7 Para. 1-2 teaches on the other hand, an embodiment of the present invention provides an apparatus for determining recommended data, where the apparatus includes: the device comprises a first obtaining module, a second obtaining module and a third obtaining module, wherein the first obtaining module is used for obtaining a request for obtaining recommended data sent by a terminal and taking the request as a data recommending request, the data recommending request comprises first attribute information of a target user, and the first attribute information comprises a target IP address of the terminal (interpret to combine with healthcare records of GUILLAMA)].
It would have been prima facie obvious skill in the art, at the time of effective filing, to combine the references of GUILLAMA, Raduchel, SALIMAN, Giordano with the recommendation of ZHA with the motivation to reduce the data processing burden.
Response to Arguments
Rejection under 35 U.S.C. § 101
Regarding the rejection of Claims 1-20, the Examiner has considered the Applicant’s arguments; however, the arguments are not persuasive. Any arguments inadvertently not addressed are unpersuasive for at least the following reasons. Applicant argues:
The Office Action alleges that the claims do not integrate the abstract idea into the practical application, as they only contain "the additional elements of using a processor and computer readable storage medium." (Office Action, at 3.) Applicant notes that the Patent Eligibility Guidance of October 17, 2019 ("2019 PEG") requires more analysis than this.
When considered as a whole, the claims are clearly integrated into the practical application. It is difficult to imagine that the phrase "integrated into the practical application" could have any substantive meaning if the above emphasized claim language were not considered to be "integrated into the practical application." Every limitation is integrated into the specific practical application, and in particular it is hard to imagine that the steps of "analyzing the blockchain ledger for unusual transactions" and "providing an alert to the user that an unusual transaction has occurred" are not integrated into the practical application (here, the practical application of detecting abnormal healthcare record transactions). The claims very clearly "use the judicial exception in a manner that imposes a meaningful limit on the judicial exception [here, mental processes], such that the claim is more than a drafting effort designed to monopolize the judicial exception." (2019 PEG, at 11.)
The Office Action, page 3, alleges that the claims "as drafted, constitute a process that, under its broadest reasonable interpretation, covers managing personal behavior or interaction" (sic). Applicant respectfully disagrees. In fact, the actual performance of managing personal behavior or interaction is not recited in the claims. The claims do not actually recite the performance of managing personal behavior or relationships. The claims do not actually recite the performance of interaction between people. The claims do not actually recite the performance of following rules or instructions. In contrast, the claims recite a method including the steps of "analyzing the blockchain ledger for unusual transactions," "providing an alert to the user that an unusual transaction has occurred." It is unclear how these steps could be interpreted to include an interaction between people.
Regarding (a), the Examiner respectfully disagrees. The Office Action, as it pertains to 101 in particular, is written to completion and follows the guidelines as written in the MPEP. The Applicant has not identified what “more that this” they believe is necessary or what the Examiner did not analyze correctly. The additional elements were analyzed both individually and as an ordered combination along with the abstract idea and were found to not provide a practical application. Applicant has pointed to nothing that indicates a practical application is present.
Further, the Examiner takes this opportunity to note that the features of the 2019 PEG and the October 2019 update have been integrated into the MPEP for at least five years. Applicant may wish to update their citations accordingly.
Regarding (b), the Examiner respectfully disagrees. The portion(s) of the claim emphasized by the Applicant are part of the abstract idea. Further, Applicant has not pointed to any specific reasoning, as delineated in MPEP 2106.04(d)(1), as to why the emphasized features provide a practical application. As such, the Examiner has nothing specific to respond to.
Regarding (c), the Examiner respectfully disagrees. Multiple CAFC decisions that the Office has characterized as Certain Method of Organizing Human Activity did not actively recite a person or persons performing the steps of the claims (see, e.g., EPG, TLI communications, Ultramercial). Because whether a human is required in the claim to perform the step of the claim is not a requirement for claims to encompass certain method of organizing human activity, this argument is not persuasive. The claims represent a series of rules or steps for a person to follow, with or without the aid of a computer, to perform blockchain-based healthcare record transfer and sharing (see Spec. Para. 0003).
Rejection under 35 U.S.C. § 103
Regarding the rejection of Claims 1-20, the Examiner has considered the Applicant’s arguments; however, these arguments are moot given the new grounds of rejection as afforded by the present RCE.
Request for Interview
The Examiner acknowledges the Applicant’s request for an interview; however, due to recent docket timing changes by the Office and the Examiner’s own personal schedule, an interview could not be scheduled prior to the due date of the present Office Action. The Examiner is happy to conduct an interview once the Applicant has had the opportunity to absorb the current rejection.
Conclusion
The prior art made of record and not relied upon in the present basis of rejection are noted in the attached PTO 892 and include:
Austríng et al (US Publication No. 20200402629) discloses systems configured to facilitate anonymous patient data transactions between multiple entities.
Patel et al (US Publication No. 20200058381) discloses systems and methods for auditing, monitoring, recording, verifying, and executing healthcare communications, decisions, and transactions using centralized storage and blockchain technology.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JONATHAN C EDOUARD whose telephone number is (571)270-0107. The examiner can normally be reached M-F 730 - 430.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Robert Morgan can be reached on (571) 272 - 6773. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of 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.
/JONATHAN C EDOUARD/Examiner, Art Unit 3683
/JASON S TIEDEMAN/Primary Examiner, Art Unit 3683
Prosecution Insights