DETAILED ACTION
Response to Amendment
The amendment filed on November 14, 2025 has been entered. Applicant has amended claims 42, 43, 44, 50, 55, 57, and 63 - 68. Claims 42-68 remain pending, have been examined and currently stand rejected.
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 . 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.
Priority
Applicant’s claim for the benefit of a prior-filed application under 35 U.S.C. 119(e) or under 35 U.S.C. 120, 121, 365(c), or 386(c) is acknowledged.
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 42-68 are rejected under 35 U.S.C. 101 because the claimed invention recites and is directed to a judicial exception to patentability (i.e., an abstract idea) and does not provide an integration of the recited abstract idea into a practical application nor include an inventive concept that is “significantly more” than the recited abstract idea to which the claim is directed. MPEP §2106.
In determining subject matter eligibility in an Alice rejection under 35 U.S.C. §101, it is first determined at Step 1 whether the claims are directed to one of the four statutory categories of an invention (i.e., a process, a machine, a manufacture, or a composition of matter). MPEP §2106.03. Here, claims 42-62 are directed to the statutory category of a machine, claims 63-65 are directed to the statutory category of a manufacture, and claims 66-68 are directed to the statutory category of a process. Under the Step 2A, Prong 1 analysis, it must be determined whether the claims recite an abstract idea that falls within one or more enumerated categories of patent ineligible subject matter that amounts to a judicial exception to patentability. MPEP §2106.04. Independent Claim 42 is selected as being representative of the independent claims in the instant application. Claim 42 recites:
A system for validating at least one healthcare transaction, comprising:
a plurality of computers in a computer network, the plurality of computers including one or more peers being configured to store a healthcare historical blockchain comprising one or more blocks comprising historical healthcare transaction data regarding historical actions taken with respect to a healthcare stakeholder; and
at least one validation device coupled to the computer network, the validation device comprising at least one processor and a memory storing one or more machine-readable instructions, which upon execution by the one or more processors perform the following operations:
receive new healthcare transaction data corresponding to healthcare actions taken with respect to the healthcare stakeholder;
receive from a first peer or an authority service on the computer network a historical block identifier corresponding to a block in the healthcare historical blockchain;
receive a validity block calculated by one or more peers on the computer network, wherein the validity block is calculated based on the historical block identifier, the new healthcare transaction data, and a confidence score having a value determined from a set of values or within a range of values;
determine the validity of the validity block according to a validity requirement; and
upon the validity requirement being met, transmitting the validity block to one or more peers to append the validity block to the healthcare historical blockchain.
Here, the claims recite the abstract idea, or combination of abstract ideas, of acquiring, validating, are conditionally recording information. This concept/abstract idea, which is identified in the bolded sections seen above, falls within the Certain Methods of Organizing Human Activity grouping because it describes a commercial interaction in the form of a business relation (e.g., a relationship between one or more entities supplying healthcare transaction data and validation data and an entity validating healthcare transaction data). Accordingly, it is determined that the claims recite an abstract idea since they fall within one or more of the three enumerated categories of patent ineligible subject matter. MPEP §2106.04. Furthermore, the Federal Circuit has explained that “the ‘directed to’ inquiry applies a stage-one filter to claims, considered in light of the specification, based on whether ‘their character as a whole is directed to excluded subject matter.’” Enfish, LLC v. Microsoft Corp., 822 F.3d 1327, 1335 (Fed. Cir. 2016) (quoting Internet Patents Corp. v. Active Network, Inc., 790 F .3d 1343, 1346 (Fed. Cir. 2015)). It asks whether the focus of the claims is on a specific improvement in relevant technology or on a process that itself qualifies as an "abstract idea" for which computers are invoked merely as a tool. See id. at 1335-36. Here, it is clear that the claim(s) focus on an abstract idea, and not on any improvement to technology and/or a technical field. It is further noted that, the performance of the one or more process steps using a generic computer component (e.g., a system, a computer, a validation device, a processor, etc.) does not preclude the claim limitation(s) from being in the certain methods of organizing human activity grouping. Since it is determined that the claim(s) recite a judicial exception, it must then be determined, under Step 2A, Prong 2, whether the judicial exception is integrated into a practical application of the exception. MPEP §2106.04. In order to make this determination, the additional element(s) are analyzed to determine if the claim as a whole integrates the recited judicial exception into a practical application of that exception. A claim that integrates a judicial exception into a practical application will apply, rely on, or use the judicial exception in a manner that imposes a meaningful limit on the judicial exception, such that the claim is more than a drafting effort designed to monopolize the judicial exception. In this instance, claim 42 recites the additional elements of: a plurality of computers in a computer network, the plurality of computers including one or more peers being configured to store a healthcare historical blockchain comprising one or more blocks comprising historical healthcare transaction data regarding historical actions taken with respect to a healthcare stakeholder; and
at least one validation device coupled to the computer network, the validation device comprising at least one processor and a memory storing one or more machine-readable instructions. Independent claim 63 recites the additional elements of: at least one processor; and at least one validation device coupled to a computer network comprising a plurality of computers configured to store a healthcare historical blockchain comprising one or more blocks including historical healthcare transaction data regarding historical actions taken with respect to a healthcare stakeholder. Independent claim 66 recites the additional elements of: a computer (i.e., computer assisted); and at least one validation device coupled to a computer network comprising a plurality of computers configured to store a healthcare historical blockchain comprising one or more blocks including historical healthcare transaction data regarding historical actions taken with respect to a healthcare stakeholder.
The computers, computer network, validation device, and processor are all recited at a high-level of generality such that they amount to no more than mere instructions to apply the exception, or a portion thereof, using a generic computer or generic computer component. MPEP 2106.05(f). Examiner finds no indication that the computer/system/device, and/or its component(s), which implement the abstract idea is/are improved, or that there is an improvement to some other technology. Examiner finds no indication in the Specification (See e.g., Specification [0077-0079]), that the operations recited in the independent claims require any specialized computer hardware or other inventive computer components, i.e., a particular machine, invoke any allegedly inventive programming, or that the claimed invention is implemented using other than generic computer components to perform generic computer functions. See DDR Holdings, LLC v. Hotels.com, L.P., 773 F.3d 1245, 1256 (Fed. Cir. 2014) ("[A]fter Alice, there can remain no doubt: recitation of generic computer limitations does not make an otherwise ineligible claim patent-eligible."). Accordingly, the claim(s) lack(s) additional elements that improve a computer or other technology.
Examiner finds no indication in applicant’s disclosure that the claimed invention, as recited, effects a transformation or reduction of a particular article to a different state or thing. The additional elements do not apply the abstract idea in a meaningful way beyond merely linking it to a particular technological environment. Furthermore, there is no indication in the claim(s) that the computing components in combination with the abstract idea leads to an improvement of the computing components, or another technology, or to a technical field. Accordingly, the additional elements cited above do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. Looking at the above elements as a combination does not add anything more than the elements analyzed individually. Examiner further notes that even though the claims may not preempt all forms of the abstraction, this alone, does not make them any less abstract. See OIP Techs., Inc. v. Amazon.com, Inc., 788 F.3d 1359, 1362-63 (Fed. Cir. 2015).
Under the Step 2B analysis, it is determined whether the recited additional elements amount to something “significantly more” than the recited abstract idea to which the claims are directed (i.e., provide an inventive concept). MPEP §2106.05. Here, the claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional element of using generic computing components (e.g., a processor, computer, validation device, etc.) to implement the abstract idea amounts to no more than mere instructions to apply the exception using a generic computer component and/or computer. Mere instructions to apply an exception using a generic computer component and/or computer is not enough to transform an abstract idea into a patent-eligible invention. Therefore, taken alone, the additional elements do not amount to significantly more than a judicial exception. Considered as an ordered combination, the additional elements recited in the claim(s) add nothing that is not already present when the steps are considered separately. Therefore, claims 42, 63 and 66 are rejected under 35 U.S.C. §101 and are not patent eligible. Dependent claims 43-62, 64-65, and 67-68 when analyzed are held to be patent ineligible under 35 U.S.C. §101 because the additional recited limitation(s) fail to establish that the claim(s) is/are not directed to an abstract idea.
Dependent claims 43, 64 and 67 refine the abstract idea by describing the contents of the validity block, however the claimed invention fails to explicitly utilize the pre-authorization score described in these claims. Accordingly, these claims fail to include any new additional elements that integrate the abstract idea into a practical application or provide significantly more than the abstract idea.
Dependent claims 44, 65 and 68 refine the abstract idea by describing the contents of the blockchain, validity block and the transaction data, however the claimed invention fails to utilize these contents. Accordingly, these claims fail to include any new additional elements that integrate the abstract idea into a practical application or provide significantly more than the abstract idea.
Dependent claim 45 further refines the abstract idea by describing the contents of the electronic medical records, however the claim fails to utilize this information. This claim fails to include any new additional elements that integrate the abstract idea into a practical application or provide significantly more than the abstract idea.
Dependent claim 46 recites the additional abstract idea of recording information associated with the validated information. This claim fails to include any new additional elements that integrate the abstract idea into a practical application or provide significantly more than the abstract idea.
Dependent claim 47 further refines the abstract idea by characteristics about the blockchain. This claim fails to include any new additional elements that integrate the abstract idea into a practical application or provide significantly more than the abstract idea.
Dependent claim 48 further refines the abstract idea by describing characteristics about the validity block and the blockchain. This claim fails to include any new additional elements that integrate the abstract idea into a practical application or provide significantly more than the abstract idea.
Dependent claim 49 further refines the abstract idea by describing characteristics about the healthcare stakeholder. This claim fails to include any new additional elements that integrate the abstract idea into a practical application or provide significantly more than the abstract idea.
Dependent claim 50 further refines the abstract idea by details about the validated information. This claim fails to include any new additional elements that integrate the abstract idea into a practical application or provide significantly more than the abstract idea.
Dependent claim 51 further refines the abstract idea by details about the validated information. This claim fails to include any new additional elements that integrate the abstract idea into a practical application or provide significantly more than the abstract idea.
Dependent claim 52 further refines the abstract idea by describing, at a high level of generality, how the validated information is received. This claim fails to include any new additional elements that integrate the abstract idea into a practical application or provide significantly more than the abstract idea.
Dependent claim 53 further refines the abstract idea by describing, at a high level of generality, a validation requirement. This claim fails to include any new additional elements that integrate the abstract idea into a practical application or provide significantly more than the abstract idea.
Dependent claim 54 further refines the abstract idea by describing, at a high level of generality, how the information in validated (e.g., based on a signature). This claim fails to include any new additional elements that integrate the abstract idea into a practical application or provide significantly more than the abstract idea.
Dependent claim 55 further refines the abstract idea by describing, at a high level of generality, how the validity block is calculated (e.g., based on hashing information). It is also noted that applicant is not positively reciting a step where the validity block is calculated. This claim fails to include any new additional elements that integrate the abstract idea into a practical application or provide significantly more than the abstract idea.
Dependent claim 56 further refines the abstract idea by describing, at a high level of generality, how the information is validated (e.g., based on hashing information). This claim fails to include any new additional elements that integrate the abstract idea into a practical application or provide significantly more than the abstract idea.
Dependent claim 57 further refines the abstract idea by describing, at a high level of generality, how the information is validated (e.g., based on a particular hashing function). This claim fails to include any new additional elements that integrate the abstract idea into a practical application or provide significantly more than the abstract idea.
Dependent claim 58 further refines the abstract idea by providing details describing the received information. This claim fails to include any new additional elements that integrate the abstract idea into a practical application or provide significantly more than the abstract idea.
Dependent claim 59 further refines the abstract idea by providing details describing the received information. This claim fails to include any new additional elements that integrate the abstract idea into a practical application or provide significantly more than the abstract idea.
Dependent claim 60 further refines the abstract idea by broadcasting a result of the validation. This claim fails to include any new additional elements that integrate the abstract idea into a practical application or provide significantly more than the abstract idea.
Dependent claim 61 further refines the abstract idea by rewarding/paying those who validate the information. This claim fails to include any new additional elements that integrate the abstract idea into a practical application or provide significantly more than the abstract idea.
Dependent claim 62 further refines the abstract idea by describing the type of reward/payment received for validating the information. This claim fails to include any new additional elements that integrate the abstract idea into a practical application or provide significantly more than the abstract idea.
In summary, the dependent claims considered both individually and as an ordered combination do not provide meaningful limitations to transform the abstract idea into a patent eligible application of the abstract idea such that the claims amount to significantly more than the abstract idea itself. The claims do not recite an improvement to another technology or technical field, an improvement to the functioning of the computer itself, or provide meaningful limitations beyond generally linking an abstract idea to a particular technological environment. Therefore, the dependent claims are also not patent eligible. Accordingly, it is determined that all claims are directed to non-statutory subject matter under 35 U.S.C. 101 and are ineligible.
Claim Rejections - 35 USC § 103
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.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 42, 46-48, 52-63 and 66 are rejected under 35 U.S.C. 103 as being unpatentable over Pauker et al. (US 2015/0294308 A1) (“Pauker”) in view of Winklevoss et al. (US 9,892,460 B1) (“Winklevoss”), where the cited portions of Winklevoss are supported by Provisional application No. 61/989,047, filed on May 6, 2014.Regarding Claims 42, 63 and 66: Pauker discloses:
Claim 42: A system for validating at least one transaction, comprising:
a plurality of computers in a computer network, the plurality of computers including one or more peers being configured to store a historical blockchain comprising one or more blocks comprising historical transaction data regarding historical actions taken with respect to a stakeholder (See at least Pauker [0026-0031]; Fig. 15. Pauker discloses a plurality of computers (i.e., plurality of computing equipment/plurality of nodes) in a computer network (i.e., network), the plurality of computers including one or more peers (i.e., a plurality of nodes) configured to store a historical blockchain (i.e., block chain/a global ledger, or a copy thereof) comprising one or more blocks comprising historical transaction data (i.e., transaction data) regarding historical actions (i.e., prior transactions) taken with respect to a stakeholder.); and
at least one validation device coupled to the computer network, the validation device comprising at least one processor and a memory storing one or more machine-readable instructions, which upon execution by the one or more processors perform the following operations (See at least Pauker [0026-0031]; Fig. 15. Pauker discloses at least one validation device (i.e., device 110) coupled to the computer network (i.e., network), the validation device comprising at least one processor (i.e., processing circuitry) and a memory (i.e., storage, e.g., memory) storing one or more machine-readable instructions.):
Claim 63: A computer program product for validating at least one transaction, comprising one or more machine-readable instruction stored in a non-transitory computer readable medium, wherein the one or more machine-readable instructions, upon execution by at least one processor (See at least Pauker [0026-0031]), perform: Claim 66: A computer-assisted method for validating at least one transaction, the method comprising:
receiving, by at least one validation device coupled to a computer network comprising a plurality of computers configured to store a historical blockchain comprising one or more blocks including historical transaction data regarding historical actions taken with respect to a stakeholder, new transaction data corresponding to actions taken with respect to the stakeholder (See at least Pauker [0026-0027]; [0032]; [0034]; [0048]; [0063]; Fig. 15; Pauker Claim 1. Pauker discloses receiving, by at least one validation device (i.e., device 110) coupled to a computer network (i.e., network) comprising a plurality of computers (i.e., plurality of computing equipment/plurality of nodes) configured to store a historical blockchain (i.e., block chain/a global ledger, or a copy thereof) comprising one or more blocks including historical transaction data (i.e., transaction data) regarding historical actions (i.e., prior transactions) taken with respect to a stakeholder, new transaction data (i.e., transaction information) corresponding to actions taken (e.g., a performed transaction) with respect to the stakeholder (i.e., owner/user).);
receiving from a first peer or an authority service on the computer network, a historical block identifier corresponding to a block in the historical blockchain (See at least Pauker [0059]; [0063]; [0067]. Where the validation device (i.e. device) receives, from a first peer or an authority service on the computer network, a historical block identifier (i.e. a previous block identifier) corresponding to a block in the historical blockchain (i.e., in block chain 200).);
receiving a validity block calculated by one or more peers on the computer network, wherein the validity block is calculated based on the historical block identifier, the new transaction data, and a confidence score having a value determined from a set of values or within a range of values (See at least Pauker [0007]; [0047-0048]; [0059]; [0063]; [0075]; [0078]; [0080]; [0084]. Pauker discloses receiving (i.e., receiving by the control circuitry in device 110) a validity block (i.e., a new block) calculated by one or more peers (i.e., nodes, e.g., nodes running mining circuitry) on the computer network, wherein the validity block (i.e., new block) is calculated (i.e., generated, e.g., by identifying a solution to a cryptographic puzzle) based on the historical block identifier (i.e. the previous block identifier), the new transaction data (i.e., transaction information, e.g., a constant portion based on the transaction(s)), and a confidence score (i.e., nonce value) having a value determined from a set of values or within a range of values (e.g., within a range of nonce values).).
Pauker discloses receiving a validity block (i.e., a new block) calculated by one or more peers (i.e., nodes, e.g., nodes running mining circuitry) on the computer network. Pauker [0007]; [0047-0048]; [0059]; [0063]; [0075]; [0078]; [0080]; [0084]. Pauker also discloses transaction added to the global ledger by each node may be verified by other nodes to help ensure the validity of the ledger. Pauker [0027]. However, Pauker does not explicitly disclose: determining a validity of the validity block according to a validity requirement; or upon the validity requirement being met, transmitting the validity block to one or more peers to append the validity block to the healthcare historical blockchain.
Winklevoss, on the other hand, teaches:
determining a validity of the validity block according to a validity requirement (See at least Winklevoss Col. 15 lines 10-22. Winklevoss teaches determining a validity of the validity block (i.e., of a miner’s proposed block) according to a validity requirement (i.e., check the miner’s work to ensure the header is less than a prescribed target.); and
upon the validity requirement being met, transmitting the validity block to one or more peers to append the validity block to the historical blockchain (See at least Winklevoss Col. 15 lines 10-22. Winklevoss teaches upon the validity requirement being met (i.e., indicated by a defined percentage or number of nodes confirming the miner’s work), transmitting the validity block (i.e., the miner’s proposed block) to one or more peers to append the validity block to the historical blockchain (i.e., to add the miner’s proposed block to the blockchain).).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Winklevoss into Pauker’s method of verifying information added to the ledger in order to ensure its validity. One of ordinary skill in the art would have been motivated to include such features in order to prove that a particular sequence of events was verified by a majority of the network’s computing power (Winklevoss Col. 11 lines 43-49). Pauker further differs from the claimed invention because Pauker does not explicitly disclose that the transactions are “healthcare” transactions, that the historical blockchain is a “healthcare” historical blockchain, that the historical and new transaction data is “healthcare” data, that the stakeholder is a “healthcare” stakeholder, and/or that the parameters are “healthcare” parameters. However, the use of the term “healthcare” to describe the various features in the claim is merely providing non-functional descriptive language regarding the type of transactions, data, stakeholder(s), actions, parameters and/or blockchains used in the recited process. The fact that these items/entities are of a particular type (i.e. a type involving healthcare) fails to affect how any of the positively recited steps are performed. For example, data is not received in a particular manner simply because the data is healthcare related. Similarly, there is no indication in the claim(s) or the disclosure that the blockchain and/or the associated transactions function differently simply because they are healthcare related. It has been held that non-functional descriptive material will not distinguish the invention from the prior art in terms of patentability. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to apply the blockchain techniques disclosed by Pauker to various fields and/or types of data (e.g., healthcare, financial, insurance, etc.) because the particular field and/or type of data has no impact on how the blockchain techniques are performed. Furthermore, using one type of data over another type of data is merely a simply substitution of the data used in the recited process.
Regarding Claim 46: The combination of Pauker and Winklevoss discloses the healthcare validation system of claim 42. Pauker further discloses further comprising creating the historical blockchain from the historical transaction data (See at least Pauker [0046]; [0059]; Pauker Claims 3 & 4. Where the historical blockchain (i.e., block chain, e.g., blockchain 200) is created from the transaction data (i.e., from the transaction information, e.g., when a new block is added to the block chain).).
Pauker differs from the claimed invention, in part, because Pauker does not explicitly disclose that the historical blockchain is a “healthcare” historical blockchain or that the historical transaction data is historical “healthcare” transaction data. However, the use of the term “healthcare” to describe the various features in the claim is merely providing non-functional descriptive language regarding the type of data and/or blockchains used in the recited process. The fact that these items are of a particular type (i.e. a type involving healthcare) fails to affect how any of the positively recited steps are performed. Similarly, there is no indication in the claim(s) or the disclosure that the blockchain and/or the associated transactions function differently simply because they are healthcare related. It has been held that non-functional descriptive material will not distinguish the invention from the prior art in terms of patentability.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to apply the blockchain techniques disclosed by Pauker to various fields and/or types of data (e.g., healthcare, financial, insurance, etc.) because the particular field and/or type of data has no impact on how the blockchain techniques are performed. Furthermore, using one type of data over another type of data is merely a simply substitution of the data used in the recited process.
Examiner Note: The phrase “wherein the validity block is calculated based on the historical block identifier, the new healthcare transaction data, and a confidence score having a value determined from a set of values or within a range of values” is non-functional descriptive material as it only describes, at least in part, the type of data that is used to calculate/generate the validity block. However, the fact that the validity block is calculated based on this specific data fails to affect how any of the positively recited steps are performed. For example, the validity block is not received in a particular manner because it was calculated based on this specific data. Likewise, there is no indication that any of the data used to calculate the validity block is used to determine if the validity block is valid. Examiner also notes that applicant is not positively reciting a step where the validity block is calculated. It has been held that non-functional descriptive material will not distinguish the invention from the prior art in terms of patentability.
Regarding Claim 47: The combination of Pauker and Winklevoss discloses the healthcare validation system of claim 46. Pauker further discloses wherein the healthcare historical blockchain depends on a birth token (See at least Pauker [0058]; Fig. 9. Where the healthcare historical blockchain (i.e., block chain, e.g., blockchain 200) depends on a birth token (i.e., an originating block (genesis block), e.g., block 150’).).
Examiner Note: The phrase “wherein the historical blockchain depends on a birth token” is non-functional descriptive material as it only describes, at least in part, data that could be included in the historical blockchain, however, the fact that the historical blockchain depends on and/or comprises this data fails to affect how any of the positively recited steps are performed. For example, there is no indication that the blockchain is created differently because it depends on a birth token. It has been held that non-functional descriptive material will not distinguish the invention from the prior art in terms of patentability.
Regarding Claim 48: The combination of Pauker and Winklevoss discloses the healthcare validation system of claim 46. Pauker further discloses wherein the validity block comprises at least one parent token and the healthcare historical blockchain depends on the at least one parent token (See at least Pauker [0047]; [0049]; [0052]; [0056]; [0063]; Pauker Claim 13; Fig. 11. Where the validity block (i.e., the new block, e.g., block 150) comprises at least one parent token (i.e., a Merkle Root) and the healthcare historical blockchain (i.e., block chain, e.g., blockchain 200) depends on the at least one parent token.).
Examiner Note: The phrase “wherein the validity block comprises at least one parent token and the historical blockchain depends on the at least one parent token” is non-functional descriptive material as it only describes, at least in part, data that could be included in the validity block and/or historical blockchain, however, the fact that the validity block comprises this data or that the historical blockchain depends on and/or comprises this data fails to affect how any of the positively recited steps are performed. For example, there is no indication that the block and/or blockchain is created differently because it depends on a parent token. It has been held that non-functional descriptive material will not distinguish the invention from the prior art in terms of patentability.
Regarding Claim 52: The combination of Pauker and Winklevoss discloses the healthcare validation system of claim 42. Pauker further discloses wherein the operation of receiving from the first peer or the authority service on the computer network the historical block identifier includes receiving at least a portion of the healthcare historical blockchain over the computer network (See at least Pauker [0003]; [0027]; [0059]; [0063]; [0067]; Pauker Claim 4. Pauker discloses wherein the operation of receiving from the first peer or the authority service on the computer network the historical block identifier (i.e., the previous block identifier) includes receiving at least a portion of the healthcare historical blockchain (e.g., a copy of the global ledger (e.g., a complete copy or only a partial copy), and/or the last (most recently record) block in block chain 200) over the computer network (i.e., peer-to-peer network).).
Regarding Claim 53: The combination of Pauker and Winklevoss discloses the healthcare validation system of claim 42. Pauker further discloses wherein the validity requirement comprises a proof-of-work difficulty (See at least Pauker [0050]; [0063]; [0085]. Where the validity requirement (i.e., the difficulty value) comprises a proof-of-work difficulty (i.e., “difficulty value 170 may specify how many leading zeros in a binary data representation are required in the hashed block header value”).).
Regarding Claim 54: The combination of Pauker and Winklevoss discloses the healthcare validation system of claim 42. Pauker further discloses wherein the validity block is further calculated as a function of a digital signature of a validator, the digital signature of the validator utilizing at least one of the following: a validator ID, a validator address, a validator public key, and a validator private key (See at least Pauker [0038]; [0052-0054]; [0059]; Fig. 4. Where the validity block (i.e., the new block, e.g., block 150) is further calculated as a function of a digital signature of a validator (i.e., a signature of a source), the digital signature of the validator utilizing at least one of the following: a validator ID, a validator address, a validator public key (i.e., private key of the source wallet), and a validator private key. Note that the new block is calculated by hashing the Merkle root, which is a hash of the transactions in the block (e.g., the signed transaction).).
Regarding Claim 55: The combination of Pauker and Winklevoss discloses the healthcare validation system of claim 42. Pauker further discloses wherein the validity block is calculated at least in part by applying a first hash as the function to the new healthcare transaction data (See at least Pauker [0052-0055]; [0059]; [0063]; [0081]; Fig. 8; Fig. 12 item 258. Where the validity block (i.e., the new block, e.g., block 150) is calculated at least in part by applying a first hash as the function to the new healthcare transaction data (e.g., by applying a hash function to the transaction data to generate the Merkle root, and/or by applying a first hash function to a first portion of the block header).).
Regarding Claim 56: The combination of Pauker and Winklevoss discloses the healthcare validation system of claim 55. Pauker further discloses applying at least a second hash to the results from the first hash (See at least Pauker [0052-0055]; [0059]; [0063]; [0081-0084]; Fig. 12 item 260. Where at least a second hash is applied to the results from the first hash (i.e., is applied to the Merkle root, and/or is applied to the output of the first hash function stage.).
Regarding Claim 57: The combination of Pauker and Winklevoss discloses the healthcare validation system of claim 55. Pauker further discloses wherein the first hash is selected from the group consisting of: SHA, Scrypt, MD5, RIPEMD, and WHIRLPOOL (See at least Pauker [0050] “The hash may be calculated using a protocol-determined hash function such as the Secure Hash Algorithm (SHA).”; [0052]; [0054]; [0081] “SHA function”.).
Regarding Claim 58: The combination of Pauker and Winklevoss discloses the healthcare validation system of claim 42. Pauker further discloses wherein the historical block identifier comprises a hash of a header of a previous block in the healthcare historical blockchain (See at least Pauker [0048] “Previous block identifier 164 may identify a previous block in the global ledger (e.g., the global ledger may be a chain of blocks 152 in which each block references a previous block in the chain). For example, the previous block identifier may be a hash of the block header of the previous block.”).
Regarding Claim 59: The combination of Pauker and Winklevoss discloses the healthcare validation system of claim 58. Pauker further discloses wherein the hash of the header of the previous block is of a last block added to the healthcare historical blockchain (See at least Pauker [0048]; [0059]. Where the hash of the header of the previous block (i.e., hash of the block header of the previous block) is of a last block added to the historical blockchain (i.e., last block of block chain 200).).
Regarding Claim 60: The combination of Pauker and Winklevoss discloses the healthcare validation system of claim 42. Pauker further discloses updating the healthcare historical blockchain by broadcasting the validity block to one or more peers in the computer network (See at least Pauker [0027]; [0046]; [0059]; [0092]; Pauker Claims 3 & 4. Where the healthcare historical blockchain is updated by broadcasting (i.e., communicating) the validity block to one or more peers in the computer network when each node in the network receives an updated copy of the global ledger/chain.).
Regarding Claim 61: The combination of Pauker and Winklevoss discloses the healthcare validation system of claim 42. Pauker further discloses receiving a digital redeemable token in exchange for determining the validity of the validity block according to the validity requirement (See at least Pauker Abstract; [0003]; [0006]; [0042]. Where a digital redeemable token (i.e., a reward of the digital currency, e.g., bitcoins) is received in exchange for determining the validity of the validity block according to the validity requirement (i.e., for successful computation of a solution to the cryptographic puzzle).).
Regarding Claim 62: The combination of Pauker and Winklevoss discloses the healthcare validation system of claim 61. Pauker further discloses wherein the digital redeemable token includes at least one of the following: a coupon, a virtual currency, a fiat currency, and a service (See at least Pauker Abstract; [0003]; [0006]; [0025] “Mining circuitry and mining operations described herein may be used for any digital medium of exchange such as digital currencies, credits, rewards, or points.”; [0042]. Where the digital redeemable token (i.e., a reward of the digital currency) includes at least one of the following: a coupon (e.g., a credit, reward), a virtual currency (e.g., bitcoin), a fiat currency, and a service.).
Claims 43-45, 49, 64, 65, 67 and 68 are rejected under 35 U.S.C. 103 as being unpatentable over Pauker in view of Winklevoss, as applied above, and further in view of Brama (US 2015/0205929 A1).
Regarding Claims 43, 64 and 67: The combination of Pauker and Winklevoss discloses the healthcare validation system of claim 42, the computer program product of claim 63, and the computer-assisted method of claim 66. Pauker does not explicitly disclose wherein the validity block comprises a healthcare token based on one or more of the following: a doctor, a patient, and a treatment associated with the one or more healthcare actions.
Brama, on the other hand, teaches wherein the validity block comprises a healthcare token based on one or more of the following: a doctor, a patient, and a treatment associated with the one or more healthcare actions (See at least Brama [0075]. Brama teaches wherein the validity block (i.e., blockchain block) comprises a healthcare token (i.e., a signature indicating validity) based on one or more of the following: a doctor (i.e., doctor/provider), a patient (i.e., client), and a treatment associated with the one or more healthcare actions (i.e., medical record).).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Pauker’s method which validates and adds transactions to a global ledger, to include the teachings of Brama, in order to provide a healthcare provider with a method of updating a client’s medical records by encoding them as a transaction to the client’s digital wallet address (Brama [0075]). Additionally, using the blockchain to record client medical records provides an effective method for transferring and/or communicating data between parties (Brama [0062]).
Examiner Note: The phrase “wherein the validity block comprises a pre-authorization score based on one or more of the following: a doctor, a patient, and a treatment associated with the one or more healthcare actions” is non-functional descriptive material as it only describes, at least in part, the composition of the validity block, however, the fact that the validity block comprises this particular information fails to affect how any of the positively recited steps are performed. It has been held that non-functional descriptive material will not distinguish the invention from the prior art in terms of patentability.
Regarding Claims 44, 65 and 68: The combination of Pauker and Winklevoss discloses the healthcare validation system of claim 42, the computer program product of claim 63, and the computer-assisted method of claim 66. Pauker further discloses wherein the historical blockchain includes the historical transaction data, the validity block includes the new transaction data (See at least Brama [0003] “The public ledger serves as an official history of transactions”; [0059] “During mining operations, a device collects a set of transactions that have not already been recorded in block chain 200. The mining circuitry may identify the last (most recently recorded) block in block chain 200. The mining circuitry may subsequently generate a new block 150 from the set of transactions”. Pauker discloses wherein the historical blockchain (i.e., block chain) includes the historical transaction data (i.e., previously recorded transactions / historical transactions), the validity block includes the new transaction data (i.e., transactions that have not been recorded in the block chain).).
Pauker differs from the claimed invention because Pauker does not explicitly disclose that the historical blockchain is a “healthcare” historical blockchain or that the historical and new transaction data is “healthcare” data. However, the use of the term “healthcare” to describe the various features in the claim is merely providing non-functional descriptive language regarding the type of data and/or blockchains used in the recited process. The fact that these items/entities are of a particular type (i.e. a type involving healthcare) fails to affect how any of the positively recited steps are performed. For example, data is not received in a particular manner simply because the data is healthcare related. Similarly, there is no indication in the claim(s), or the disclosure, that the blockchain and/or the associated transactions function differently simply because they are healthcare related. It has been held that non-functional descriptive material will not distinguish the invention from the prior art in terms of patentability. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to apply the blockchain techniques disclosed by Pauker to various fields and/or types of data (e.g., healthcare, financial, insurance, etc.) because the particular field and/or type of data has no impact on how the blockchain techniques are performed. Furthermore, using one type of data over another type of data is merely a simply substitution of the data used in the recited process. Pauker discloses the need to perform mining operations in order to verify transactions and to have those transactions recorded in a global ledger as part of a new block. Pauker [0046]; [0059]. Pauker also discloses that a transaction may include information such as a “block height”. Pauker [0040-0041]. Pauker indicates that the block height may help identify where the transaction is located within the global ledger (i.e., a pointer). However, Pauker does not explicitly disclose, but Brama teaches wherein the historical healthcare transaction data and the new healthcare transaction data comprises one or more pointers to one or more locations to an electronic medical record system storing an electronic medical record regarding the one or more health care actions (See at least Brama [0063-0065]; [0067]. Brama teaches wherein the historical healthcare transaction data (i.e., medical record(s)) and the new healthcare transaction data (i.e., new medical record(s)) comprises one or more pointers (i.e., a message that serves as a pointer, or reference location to further data) to one or more locations to an electronic medical record system (i.e., location of user data) storing an electronic medical record regarding the one or more health care actions.).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Pauker’s method which validates and adds transactions to a global ledger, to include the teachings of Brama, in order to provide a healthcare provider with a method of updating a client’s medical records by encoding them as a transaction to the client’s digital wallet address (Brama [0075]). Additionally, using the blockchain to record client medical records provides an effective method for transferring and/or communicating data between parties (Brama [0062]).
Examiner Note: The phrase “the historical healthcare transaction data and the new healthcare transaction data comprises one or more pointers to one or more locations to an electronic medical record system storing an electronic medical record regarding the one or more health care actions” is non-functional descriptive material as it only describes, at least in part, the composition of the historical healthcare transaction data and the new healthcare transaction data, however, the fact that this data comprises this particular information fails to affect how any of the positively recited steps are performed. It has been held that non-functional descriptive material will not distinguish the invention from the prior art in terms of patentability.
Regarding Claim 45: The combination of Pauker, Winklevoss and Brama discloses the healthcare validation system of claim 44. Pauker does not disclose, however Brama further teaches wherein the electronic medical record comprises at least one of the following: a test result, a genetic code, a diagnosis, a prognosis, a patient identifier, a caregiver identifier, a fee, and a payer identifier (See at least Brama [0067] “a doctor may send medical data to a patient and may embed with the data a message with a reference to a location of further data, i.e. imaging, background, lab results, etc.”; [0075]).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Pauker’s method which validates and adds transactions to a global ledger, to include the teachings of Brama, in order to provide a healthcare provider with a method of updating a client’s medical records by encoding them as a transaction to the client’s digital wallet address (Brama [0075]). Additionally, using the blockchain to record client medical records provides an effective method for transferring and/or communicating data between parties (Brama [0062]).
Examiner Note: The phrase “wherein the electronic medical record comprises at least one of the following: a test result, a genetic code, a diagnosis, a prognosis, a patient identifier, a caregiver identifier, a fee, and a payer identifier” is non-functional descriptive material as it only describes, at least in part, the composition of the electronic medical record, however, the fact that the electronic medical record comprises this particular information fails to affect how any of the positively recited steps are performed. It has been held that non-functional descriptive material will not distinguish the invention from the prior art in terms of patentability.
Regarding Claim 49: The combination of Pauker and Winklevoss discloses the healthcare validation system of claim 42. Pauker does not explicitly disclose wherein the healthcare stakeholder includes at least one of the following: a patient, a physician, a technician, a care provider, a payer, a broker, and a guardian. Brama, on the other hand, teaches wherein the healthcare stakeholder includes at least one of the following: a patient, a physician, a technician, a care provider, a payer, a broker, and a guardian (See at least Brama [0065]; [0067] “data transferred between users may be associated with other data. In a non-limiting example, a doctor may send medical data to a patient and may embed with the data a message with a reference to a location of further data, i.e. imaging, background, lab results, etc”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Pauker’s method which validates and adds transactions to a global ledger, to include the teachings of Brama, in order to provide a healthcare provider with a method of updating a client’s medical records by encoding them as a transaction to the client’s digital wallet address (Brama [0075]). Additionally, using the blockchain to record client medical records provides an effective method for transferring and/or communicating data between parties (Brama [0062]).
Examiner Note: The phrase “wherein the healthcare stakeholder includes at least one of the following: a patient, a care provider, a technician, a payer, a broker, and a guardian” is non-functional descriptive material as it only describes, at least in part, a particular title/name for the stakeholder, however, the fact that the stakeholder has a particular title/name fails to affect how any of the positively recited steps are performed. For example, there is no indication that healthcare transaction data would be received differently when the stakeholder is a patient or a care provider. It has been held that non-functional descriptive material will not distinguish the invention from the prior art in terms of patentability.
Claims 50-51 are rejected under 35 U.S.C. 103 as being unpatentable over Pauker in view of Winklevoss, as applied above, and further in view of Reddy (US 2014/0372140 A1).
Regarding Claim 50: The combination of Pauker and Winklevoss discloses the healthcare validation system of claim 42. Pauker does not explicitly disclose wherein the healthcare transaction data comprises one or more standardized codes associated with health care diagnosis, treatment, or services.
Reddy, on the other hand, teaches wherein the healthcare transaction data comprises one or more standardized codes associated with health care diagnosis, treatment, or services (See at least Reddy [0064]. Where the healthcare transaction data (i.e., parameters) comprises one or more standardized codes associated with health care diagnosis, treatment, or services (e.g., Current Procedural Terminology (“CPT”) modifiers/codes).).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Pauker’s method which validates and adds transactions to a global ledger, to include wherein the healthcare transaction data comprises standardized codes, as taught by Reddy. One of ordinary skill in the art would have been motivated to include such features because adding standardized codes to the healthcare transaction data would allow for the adjusting of payment terms based on the complexity of the procedure or treatment which could be determined by details such as the CPT code (Reddy [0064]).
Examiner Note: The phrase “wherein the healthcare transaction data comprises one or more standardized codes associated with health care diagnosis, treatment, or services” is non-functional descriptive material as it only describes, at least in part, the composition of the transaction data, however, the fact that the transaction data comprises this particular information fails to affect how any of the positively recited steps are performed. It has been held that non-functional descriptive material will not distinguish the invention from the prior art in terms of patentability.
Regarding Claim 51: The combination of Pauker, Winklevoss and Reddy discloses the healthcare validation system of claim 50. Pauker does not disclose, however Reddy further teaches, wherein the standardized codes include at least one of the following: an International Statistical Classification of Diseases and Related Health Problems (ICD) code, a Current Procedural Terminology (CPT) code, and a Diagnostic and Statistical Manual of Mental Disorders (DSM) code (See at least Reddy [0016] “ICD code”; [0029]; [0064] “Current Procedural Terminology (“CPT”) modifiers”.).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Pauker’s method which validates and adds transactions to a global ledger, to include wherein the healthcare transaction data comprises standardized codes, as taught by Reddy. One of ordinary skill in the art would have been motivated to include such features because adding standardized codes to the healthcare transaction data would allow for the adjusting of payment terms based on the complexity of the procedure or treatment which could be determined by details such as the CPT code (Reddy [0064]).
Examiner Note: The phrase “wherein the standardized codes include at least one of the following: an International Classification of Diseases (ICD) code, a Current Procedural Terminology (CPT) code, and a Diagnostic and Statistical Manual (DSM) code” is non-functional descriptive material as it only describes, at least in part, the particular type of standardized code in the transaction data, however, the fact that the transaction data comprises this particular information fails to affect how any of the positively recited steps are performed. It has been held that non-functional descriptive material will not distinguish the invention from the prior art in terms of patentability.
Response to Arguments
Claim Objections
Claims 67 and 68 were objected to for minor informalities. Applicant’s amendment have addressed the previously identified issues, accordingly the prior objections are withdrawn.
Claim Rejections – 35 U.S.C. § 112(a)
Claims 42-62, 64 and 67 were rejected under 35 U.S.C. 112(a) as failing to comply with the written description requirement. Applicant’s amendments have corrected the previously identified issues, accordingly the prior 112(a) rejections are withdrawn.
Claim Rejections – 35 U.S.C. § 112(b)
Claims 42-62 were rejected under 35 U.S.C. 112(b) as being indefinite. Applicant’s amendments have corrected the previously identified issues, accordingly the prior 112(b) rejections are withdrawn.
Claim Rejections – 35 U.S.C. § 101
With respect to the 101 rejection, Applicant argues that independent claim 42 as amended creates a new data structure called a HHBC (healthcare historical blockchain) that has a practical application, creating a permanent record that represents a healthcare path taken by a patient throughout their entire life. Amendment, pp. 11-12. This argument is unpersuasive. Examiner acknowledges that, in some instances (e.g., when the validity requirement is met), healthcare data is being stored to the blockchain, however this is not a new data structure. Rather, the claimed invention is merely utilizing existing blockchain technology and practices to store a particular type of data (e.g., healthcare data). Examiner finds no indication that the claimed invention somehow alters, or improves upon, blockchain technology so that healthcare data can be stored. Phrased differently, merely storing a different type of data in a known database/data structure (e.g., a blockchain) is not indicative of a practical application.
Applicant argues that the claims of the present application are at least in part analogous to those in Enfish. Amendment, pp. 12-13. Examiner respectfully disagrees. The claims in Enfish were found eligible because they were directed to an improvement to computer functionality. Examiner contends that no such improvement is found in the instant claims. For example, the independent claims of the present application has five steps. Three of these steps receive data and one step sends data. The only other step in the independent claims is the step which determines validity of the validity block and this step is recited at a high level of generality. Examiner contends that these limitations fail to provide any indication that they are improving upon a computers functionality.
For the above reasons, and for those set forth in the 35 U.S.C. § 101 rejection seen above, all claims remain rejected under 35 U.S.C. § 101.
Claim Rejections – 35 U.S.C. § 103
Applicant argues that neither Brama nor Pauker, taken separately or together, teach, disclose, or suggest the limitations of independent claim 42 as currently amended. Amendment, pp. 13-14. Examiner agrees that Brama and Pauker do not teach all of the limitations of claim 42. Examiner has added an additional reference, Winklevoss, to the current art rejection to teach the features not taught by Pauker. Examiner contends that the combination of Pauker and Winklevoss renders claim 42 obvious.
For the above reasons, and for those set forth in the 35 U.S.C. § 103 rejection seen above, all claims remain rejected under 35 U.S.C. § 103.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure is cited in the Notice of References Cited (PTO-892). The additional cited art further establishes the state of the art prior to the effective filling date of Applicant’s claimed invention.
Shah (US 2013/0290022 A1) discloses a system and a method configured to retrieve data from varied medical sources and convert it in a standardized format before storing into a data bank of a medical source. Shah [0007].
O'Brien (US 10,535,111 B2) discloses blockchain is a data structure that stores a list of transactions and can be thought of as a distributed electronic ledger that records transactions between source identifiers and destination identifiers. Each transaction of the blockchain is bundled into blocks and every block ( except for the first block) refers back to or is linked to a prior block in the chain. Computer nodes maintain the blockchain and cryptographically validate each new block and thus the transactions contained in the corresponding block. This validation process includes solving a computationally difficult problem that is also easy to verify and is sometimes called a "proof-of-work." O’Brien Col. 1 lines 44-55.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JASON FENSTERMACHER whose telephone number is (571)270-3511. The examiner can normally be reached Monday - Friday 9:00 AM to 5:30 PM ET, Alternate Fridays Off.
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, Patrick McAtee can be reached at 571-272-7575. 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.
/J.F./Examiner, Art Unit 3698 February 20, 2026
/PATRICK MCATEE/Supervisory Patent Examiner, Art Unit 3698