DETAILED ACTION
Continued Examination Under 37 CFR 1.114
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. Applicants’ submission filed on May 20, 2026, has been entered.
Response to Amendment
The amendment filed on May 20, 2026, has been entered. Applicant has amended claims 42, 55, 63, and 66. 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 .
Continuation
This application is a divisional of U.S. Patent Application No. 16/451,707, filed on
June 25, 2019, now U.S. Patent No. 12,027,244, which is a divisional of U.S. Patent Application No. 14/711,740, filed on May 13, 2015, now U.S. Patent No. 10,340,038, which claims the benefit of U.S. Provisional Patent Application No. 61/992,734, filed May 13, 2014. See MPEP §201.07. In accordance with MPEP §609.02 A.2 and MPEP §2001.06(b) (last paragraph), the Examiner has reviewed and considered the prior art cited in the Parent Application(s). Also, in accordance with MPEP §2001.06(b) (last paragraph), all documents cited or considered ‘of record’ in the Parent Application(s) are now considered cited or ‘of record’ in this application. Additionally, Applicant(s) are reminded that a listing of the information cited or ‘of record’ in the Parent Application need not be resubmitted in this application unless Applicant(s) desire the information to be printed on a patent issuing from this application. See MPEP §609.02 A.2.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
Claims 42-68 are rejected under 35 U.S.C. 112(b) as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor regards as the invention.
Regarding Claims 42, 63 and 66: Claim 42 recites, in part, “receive from a peer, one or more healthcare tokens, comprising new healthcare transaction data, […].” The comma placement in this limitation makes the limitation unclear. That is, it is unclear whether the “peer” or the “one or more healthcare tokens” comprises the new healthcare transaction data. As best understood, the “one or more healthcare tokens” are what comprise the new healthcare transaction data (i.e., not the peer). In order to further prosecution, the claims have been interpreted in this manner. If this understanding is correct, the limitation should be amended to recite “receive, from a peer, one or more healthcare tokens[[,]] comprising new healthcare transaction data, […].”
Independent claims 63 and 66 recite a substantially similar limitation and contain the same lack of clarity issue, accordingly, claims 63 and 66 are rejected under 35 U.S.C. 112(b) for the same reasons and rational explained above. Claims 43-62, 64-65 and 67-68 are also rejected under 35 U.S.C. 112(b) based on their dependency to claim 42, 63 or 66.
Regarding Claims 42, 63 and 66: Claim 42 recites, in the generating a validity block step, “wherein the validity block is generated based on […] a validity token obtained via a validator interface or as a confidence score having a value determined from a set of values or within a range of values.” The meaning of this limitation is unclear. For example, it is unclear whether this limitation means that the block is generated based on a validity token or a confidence score. Alternatively, this limitation could mean that the validity token is obtained via a validator device or that the validity token is obtained as a confidence score. Alternatively, the limitation could be grammatically incorrect. For example, it is unclear whether the limitation should recite “wherein the validity block is generated based on […] a validity token, wherein the validity token is obtained via a validator interface, and wherein the validity token comprises ” Applicant’s disclosure indicates that the “validity token could be obtained as a code from a validity analysis routine where the code could take on binary value (e.g., valid - invalid; agree - disagree, 0 - 1, etc.), or could take on a range of values.” Specification [0052]. The disclosure further indicates that “In other embodiments, the validity token can be obtained via validator interface.” Specification [0053]. Based on applicant’s disclosure, it appears that “wherein the validity block is generated based on […] a validity token, wherein the validity token is obtained via a validator interface, and wherein the validity token comprises ” is the most reasonable interpretation for this limitation. Accordingly, the claim(s) has/have been interpreted in this manner. Further clarification is needed.
Independent claims 63 and 66 recite a substantially similar limitation and contain the same lack of clarity issue, accordingly, claims 63 and 66 are rejected under 35 U.S.C. 112(b) for the same reasons and rational explained above. Claims 43-62, 64-65 and 67-68 are also rejected under 35 U.S.C. 112(b) based on their dependency to claim 42, 63 or 66.
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 associated with a stakeholder 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) associated with a stakeholder (i.e., associated with an owner/user) comprising one or more blocks comprising historical transaction data (i.e., transaction data) regarding historical actions (i.e., prior transactions) taken with respect to the 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 instructions 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 from a peer, one or more tokens, comprising new transaction data, wherein each token is associated with a stakeholder and corresponds to a transaction, wherein the peer includes 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 the stakeholder [0048]; [0063]; (See at least Pauker [0026-0028]; [0032-0039]; [0063]; [0068]; Fig. 15; Pauker Claim 1. Pauker discloses receiving from a peer (i.e., from a node), one or more tokens (i.e., one or more transactions, e.g., a coinbase transaction, a cryptocurrency transaction), comprising new transaction data (i.e., information about the transaction(s)), wherein each token (i.e., each transaction) is associated with a stakeholder (i.e., with an owner/user, e.g., an owner/user of a wallet) and corresponds to a transaction, wherein the peer (i.e., node) includes at least one validation device (e.g., 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., previous/prior transactions) taken 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).);
generating a validity block comprising the one or more tokens calculated by one or more peers on the computer network, wherein the validity block is generated based on the historical block identifier, the new transaction data, and a validity token obtained via a validator interface or as 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 generating a validity block (i.e., a new block) comprising the one or more tokens (i.e., comprising the one or more transactions) 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 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 validity token (i.e., nonce value) obtained via a validator interface (i.e., by control circuitry) or as a confidence score (i.e., comprising a 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 that transactions 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 applicable to each of the one or more healthcare tokens; 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 applicable to each of the one or more tokens (See at least Winklevoss Col. 15 lines 10-25. Winklevoss teaches determining a validity of the validity block (i.e., of a miner’s proposed block) according to a validity requirement (i.e., according to a prescribed target. Where the miner’s check the work to ensure the header is less than a prescribed target.) applicable to each of the one or more tokens (i.e., applicable to each of the transactions recorded in the block. Note that all transactions in the block are subject to the same 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 tokens are “healthcare” tokens, 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 tokens, 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 simple 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 simple 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 simple 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 Rejections – 35 U.S.C. § 101
Applicant asserts 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. 9-11. Examiner agrees that any abstract idea is now integrated into a practical application. Examiner contends that the claims still recite one or more abstract ideas (e.g., acquiring/receiving, validating, and/or conditionally recording information), however Examiner agrees that the additional limitations integrate any abstract idea into a practical application. For example, the claimed invention moves beyond the mere obtaining and storing of data because it describes a particular way to generate and validate a validity block (i.e. blockchain block) which ensures that only accurate/validated healthcare transaction data is stored on the blockchain. Accordingly, the 101 rejection is withdrawn.
Claim Rejections – 35 U.S.C. § 103
Applicant argues that neither Brama, Pauker, Winklevoss, nor Reddy, taken separately or together, teach, disclose, or suggest the limitations of independent claim 42 as currently amended. Amendment, pp. 11-12. Examiner respectfully disagrees. Applicants’ arguments amount to a general allegation that the claims define a patentable invention without specifically pointing out how the language of the claims patentably distinguishes them from the references. Examiner has updated the prior art rejection based on the current claim amendments; however, Examiner contends that the combination of Pauker and Winklevoss continues to render independent claims 42, 63 and 66 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 into a standardized format before storing into a data bank of a medical source. Shah [0007].
O'Brien (US 10,535,111 B2) discloses that a 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.
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
/PATRICK MCATEE/Supervisory Patent Examiner, Art Unit 3698
Prosecution Insights