DETAILED ACTION
Status
This Final Office Action is in response to the communication filed on 29 June 2026. Claims 2, 6, and 8 have been cancelled, claims 1, 3-5, 7, 10, and 21-22 have been amended, and no new claims have been added. Therefore, claims 1, 3-5, 7, and 9-22 are pending and presented for examination.
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 .
Response to Amendment
A summary of the Examiner’s Response to Applicant’s amendment:
Applicant’s amendment overcomes the rejection(s) under 35 USC § 112; therefore, the Examiner withdraws the rejection(s).
Applicant’s amendment does not overcome the rejection(s) under 35 USC § 101; therefore, the Examiner maintains the rejection(s) while updating phrasing in keeping with current examination guidelines.
Applicant’s amendment overcomes the rejection(s) under 35 USC §§ 102 and/or 103 for claims 1, 3-5, 7, and 10; therefore, the Examiner indicates allowability over the prior art.
Applicant’s amendment does not overcome the prior art rejection(s) under 35 USC §§ 102 or 103 for claims 10-20; therefore, the Examiner maintains the rejection(s) as below.
Applicant’s amendment overcomes the rejection(s) under 35 USC §§ 102 and/or 103 for claims 21-22; therefore, the Examiner places new grounds of rejection.
Applicant’s arguments are found to be not persuasive; please see the Response to Arguments below.
Examiner’s Notes
The Examiner notes that “secure enclave” (as at claim 1) is not actually defined in the specification, but since it is described as storing a private key (at Applicant ¶ 0010) and/or biometric information (at Applicant ¶ 0012), and may be erased (at Applicant ¶ 0010), this is understood to be a memory of any sort or type (and not necessarily a hardware component, it may apparently be just a segmented data location).
The Examiner notes that claim 21 recites “a physician using a physician client in a blockchain network authorizing or creating a treatment plan for a user using a device in a blockchain network”, where this is interpreted as NOT claiming the physician, but rather that this means “authorizing or creating, by a physician, a treatment plan for a user”, and that the “using a device in a blockchain network” is in reference to the “physician using a physician client in a blockchain network” (and not that the user is using a device in a blockchain network).
The Examiner notes that claims 1 recites “anti-tampering circuitry configured to detect a tampering attempt in the treatment device”. However, the specification indicates that:
“Anti-tampering functionality includes physical intrusion detection, sensors to detect environmental changes (such as temperature and pressure), voltage and frequency monitoring, light detection, etc. The anti-tampering functionality can detect changes of temperatures, pressure, voltage, frequency, light etc., and create alarms if they are not within a specified range” (at Applicant ¶ 0010), and
“Anti-tampering block 125 is used for intrusion detection and may include sensors to detect changes in device temperature, pressure, voltage, frequency, and light level” (at Applicant ¶ 0012), and
“Environmental Sensors: to detect unusual temperature or pressure changes, indicating attempts to tamper with the device through extreme environmental conditions” (at Applicant ¶ 0019), and
Similar indications at Applicant ¶¶ 0101-0107).
Therefore, in light of the specification, the “tampering” apparently does not actually require any active tampering attempt – the term “tampering” also means or includes any reason for any environmental or supply issue or variance, such as power surges or outages, turning a light switch on or off, resetting or problems associated with a thermostat, air conditioning, or heating system, etc. There is no indication of any detection or determination as to why the temperature, pressure, voltage, frequency, or light sensing is out of range or beyond a threshold – the light of the specification apparently merely ASSUMES that this is due to tampering, but the actual system described merely detects the indicated measurements and does NOT detect any actual tampering. As such, “a tampering attempt” is interpreted to include any variation in temperature, pressure, voltage, frequency, or light of the environment of the device.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1, 3-5, 7, and 9-22 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Please see the following Subject Matter Eligibility (“SME”) analysis:
For analysis under SME Step 1, the claims herein are directed to a device (claims 1-3-5, 7, and 10), system (claims 11-20), and methods (claims 21-22), which would be classified under one of the listed statutory classifications (SME Step 1=Yes).
For analysis under revised SME Step 2A, Prong 1, independent claim 1 recites a treatment device comprising: a secure enclave; anti-tampering circuitry configured to detect a tampering attempt in the treatment device; at least one processor executing an application, the application when executed, causing the at least one processor to at least: generate a request for one or more treatments to be executed by the treatment device; retrieve data specifying the one or more treatments from a blockchain network, the blockchain network comprising a blockchain and one or more data availability sources; request authorization for a selected one of the one or more treatments from the blockchain; in response to receiving authorization from the blockchain, cause the device to execute the selected treatment based on data specifying the selected treatment; and in response to receiving an indication of the tampering attempt from the anti-tampering circuitry, initiate erasure of the secure enclave and a device shutdown.
Independent claim 11 recites a system comprising: a treatment device; a control client and a physician client, wherein the treatment device, control client and physician client communicate with a first and a second smart contract in a network.
Independent claim 21 recites a method comprising: a physician using a physician client in a blockchain network authorizing or creating a treatment plan for a user using a device in a blockchain network; the device in the blockchain network further comprises: a treatment device of the user in the blockchain network, the treatment device comprising a secure enclave and a blockchain client, wherein the treatment device does not locally store treatment recipes, further: generating a request for a treatment list from a smart contract on the blockchain network; receiving treatment list or prescribed treatment list for the user; requesting a prescription treatment recipe from the prescription treatment list, the treatment recipe specifying parameters for execution of a prescription treatment by the treatment device; requesting and receiving authorization for the prescription treatment from a physician smart contract on the blockchain network; sending a payment via a blockchain transaction for the authorized prescription recipe; and receiving the prescription treatment recipe and performing the treatment as per the treatment recipe.
Independent claim 22 recites a method comprising a treatment device of a user in a blockchain network, the treatment device comprising a secure enclave and a blockchain client, wherein the treatment device does not locally store treatment recipes, the treatment device: requesting a treatment list and receiving treatment list from a smart contract on the blockchain network; requesting a wellness treatment recipe from the treatment list, the wellness treatment recipe specifying parameters for execution of a wellness treatment by the treatment device; sending a payment via a blockchain transaction to the blockchain network for the wellness treatment recipe; receiving the wellness treatment recipe from the smart contract on the blockchain network; and performing the wellness treatment on the user as per the treatment recipe
The dependent claims (claims 3-5, 7, 10 and 12-20) appear to be encompassed by the abstract idea of the independent claims since they merely indicate temperature, pressure, voltage, frequency, and/or light sensors (claims 3-5), initiating an alarm upon a tampering indication (claim 7), a communication interface, a user authentication circuitry, a blockchain client, and a transcranial ultrasound hardware used for ultrasound targeting and stimulation (claim 10), data received (i.e., a treatment list, characteristics, and price) as accessed by a smart contract (claim 12), executing a blockchain transaction (claim 13), authorization from a smart contract (claim 14), retrieving and performing a treatment recipe from a second smart contract (claim 15), modifying a treatment cost, configuration, or list with a second smart contract (claim 16), a physician executing a/the blockchain transaction (claim 17), and/or using Ethereum and/or Solana Virtual Machines for smart contracts (claims 18-20).
The underlined portions of the claims are an indication of elements additional to the abstract idea (to be considered below).
The Examiner notes that the analysis regarding subject matter eligibility considers the entirety of the claim elements, both individually and as a whole (or ordered combination). This idea is within the following grouping(s) of subject matter:
Certain methods of organizing human activity (e.g. fundamental economic principles or practices such as hedging, insurance, mitigating risk; commercial or legal interactions such as agreements, contracts, legal obligations, advertising, marketing or sales activities/behaviors, or business relations; and/or managing personal behavior or relationships between people such as social activities, teaching, and following rules or instructions); and
Mental processes (e.g., concepts performed in the human mind such as observation, evaluation, judgment, and/or opinion).
Therefore, the claims are found to be directed to an abstract idea.
For analysis under revised SME Step 2A, Prong 2, the above judicial exception is not integrated into a practical application because the additional elements do not impose a meaningful limit on the judicial exception when evaluated individually and as a combination. The additional elements are using a device comprising: a secure enclave (i.e., a memory); anti-tampering circuitry configured to detect a tampering attempt in the treatment device; at least one processor executing an application, the application when executed, causing the at least one processor to [perform activities] to be executed by the treatment device; using blockchain network, the blockchain network comprising a blockchain (at claim 1), a system comprising: a treatment device; a control client and a physician client, wherein the treatment device, control client and physician client communicate with a first and a second smart contract in a network (at claim 11), a physician client in a blockchain network, using a device in a blockchain network, a treatment device in the blockchain network, the treatment device comprising a secure enclave and a blockchain client, using a smart contract, and payment via a blockchain transaction (at claim 21), and a treatment device of a user in a blockchain network the treatment device comprising a secure enclave and a blockchain client, using a smart contract, a blockchain, and a payment via a blockchain transaction (at claim 22).
There is no indication of any change or improvement to the devices, computers, technology, blockchain, blockchain network, or any other technology areas.
As such, these additional elements do not reflect an improvement in the functioning of a computer or an improvement to other technology or technical field, implement the judicial exception with, or by using in conjunction with, a particular machine or manufacture that is integral to the claim, effect a transformation or reduction of a particular article to a different state or thing (there is no transformation/reduction of a physical article), and/or apply or use the judicial exception in some other meaningful way beyond generically linking use of the judicial exception to a particular technological environment.
Regarding whether the claims effect a particular treatment or prophylaxis for a disease or medical condition, MPEP § 2106.04(d)(2) indicates that
One way to demonstrate such integration is when the additional elements apply or use the recited judicial exception to effect a particular treatment or prophylaxis for a disease or medical condition. The application or use of the judicial exception in this manner meaningfully limits the claim by going beyond generally linking the use of the judicial exception to a particular technological environment, and thus transforms a claim into patent-eligible subject matter.
(at MPEP § 2106.04(d)(2))
Examiners should keep in mind that in order to qualify as a ‘treatment’ or ‘prophylaxis’ limitation for purposes of this consideration, the claim limitation in question must affirmatively recite an action that effects a particular treatment or prophylaxis for a disease or medical condition” and that “The treatment or prophylaxis limitation must be ‘particular,’ i.e., specifically identified so that it does not encompass all applications of the judicial exception(s)
(at MPEP § 2106.04(d)(2)a.).
The indications of performing the treatment are very generalized – literally appearing to encompass any and all treatments of any type via any treatment device(s). Only dependent claim 10 designates any particular device or treatment (i.e., “a transcranial ultrasound hardware used for ultrasound targeting and stimulation”). However, even at claim 10, the device itself nor the operation of the device, nor the treatment being or to be applied appears changed – the price, list, and/or recipes of treatments (i.e., controls, settings, dosage, etc. that Applicant terms a “recipe” – see Applicant ¶¶ 0039 (as submitted, 0039-0045 as published) is apparently not changed, but merely the source of information is, per the claims, sourced from blockchain rather than from other possible sources. This is to say that the treatment and/or prophylaxis (if a treatment per the claims is viewed as proactively preventing) itself does not change, but apparently only the source of information regarding a/the price, list, and/or recipes is changed.
Claims 11-14 and 16-20 do not recite treatments as being made.
Therefore, the claims appear to merely apply the judicial exception, include instructions to implement an abstract idea on a computer, or merely use a computer as a tool to perform the abstract idea. The additional elements appear to merely add insignificant extra-solution activity to the judicial exception and/or generally link the use of the judicial exception to a particular technological environment or field of use.
For analysis under SME Step 2B, the claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception because the additional elements, as indicated above, are merely “[a]dding the words ‘apply it’ (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, e.g., a limitation indicating that a particular function such as creating and maintaining electronic records is performed by a computer, as discussed in Alice Corp.” that MPEP § 2106.05(I)(A) indicates to be insignificant activity
There is no indication the Examiner can find in the record regarding any specialized computer hardware or other “inventive” components, but rather, the claims merely indicate computer components which appear to be generic components and therefore do not satisfy an inventive concept that would constitute “significantly more” with respect to eligibility. Applicant ¶ 0102 (as submitted, 0126 as published) indicates the activities as able to be performed via a general purpose computer and/or a general purpose processor.
The individual elements therefore do not appear to offer any significance beyond the application of the abstract idea itself, and there does not appear to be any additional benefit or significance indicated by the ordered combination, i.e., there does not appear to be any synergy or special import to the claim as a whole other than the application of the idea itself.
The dependent claims, as indicated above, appear encompassed by the abstract idea since they merely limit the idea itself; therefore the dependent claims do not add significantly more than the idea.
Therefore, SME Step 2B=No, any additional elements, whether taken individually or as an ordered whole in combination, do not amount to significantly more than the abstract idea, including analysis of the dependent claims.
Please see the Subject Matter Eligibility (SME) guidance and instruction materials at https://www.uspto.gov/patent/laws-and-regulations/examination-policy/subject-matter-eligibility, which includes the latest guidance, memoranda, and update(s) for further information.
NOTICE
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.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale or otherwise available to the public before the effective filing date of the claimed invention.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 11-17 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Giordano et al (U.S. Patent Application Publication No. 2017/0300627, hereinafter Giordano).
Claim 11: Giordano discloses a system comprising:
a treatment device ((see Giordano at least at, e.g., ¶ 0071, “other types of smart contracts may exist on the network 200 as well. For example, a medical device 218 may be given an identity on the network 200 and may be assigned a device smart contract 218SC”; citation hereafter by number only);
a control client (0078, “FIG. 4 depicts a flow of transactions, calls, and smart contract executions in an example process 400 for sending medical records to a patient or other user in a distributed network. … The physician 402 may also generate an invoice for services rendered and any other costs associated with the diagnostic. Each record generated by the physician 402, or an agent of the physician 402, can be uploaded to a storage system that makes medical records available to authorized users”) and
a physician client (0057, “a computer 102 that belongs to a doctor may both store medical records created by the doctor for his or her patients and may also maintain an instance of the distributed ledger”, 0058, “when a doctor creates a medical record that is added to a patient's smart contract, the medical record may initially be hosted by one or more computers associated with the doctor that created the record”), wherein the treatment device, control client and physician client communicate with a first and a second smart contract in a network (0003, “The ledger may include blocks of transactions that indicate actions that have been taken on the network since its genesis. In some implementations, the ledger also stores program modules, referred to as smart contracts, which allow participants in a distributed medical records management network to interact with the ledger and with each other. For example, doctors, patients, pharmacists, and insurers may be issued role-specific smart contracts that allow the participants to invoke various records management events on the network”).
Claim 12: Giordano discloses the system of claim 11, wherein the treatment device requests and receives a treatment list, treatment characteristics, and prices from the system, wherein the treatment list, treatment characteristics and prices are accessed through a second smart contract (0003, “The ledger may include blocks of transactions that indicate actions that have been taken on the network since its genesis. In some implementations, the ledger also stores program modules, referred to as smart contracts, which allow participants in a distributed medical records management network to interact with the ledger and with each other. For example, doctors, patients, pharmacists, and insurers may be issued role-specific smart contracts that allow the participants to invoke various records management events on the network”).
Claim 13: Giordano discloses the system of claim 11, wherein the treatment device executes a blockchain transaction that pays for the wellness treatment or prescribed treatment to system; and upon successful completion of the blockchain transaction the second smart contract is altered (0064, “a ‘patient’ smart contract may enable a user to access medical records of the user (but not of other users), to add authorizations for doctors or other parties to access all or some of the user's medical records, to remove authorization of parties to access all or some of the user's medical records, to send valid prescriptions to a pharmacist for filling, to pay bills to an insurer or doctor or other medical provider, and to adjust user account settings”, 0045, “the computer 102—and every other node in the network that maintains a copy of the ledger 106—may update the ledger 106”).
Claim 14: Giordano discloses the system of claim 11, wherein the treatment device requests and receives authorization from a first smart contract for a treatment of a user or patient (0040, “The computer 102 may perform various functions, including maintaining a distributed ledger 106 and providing a terminal that allows its user to interact with the ledger 106, broadcast transactions to other nodes in the network, send and receive medical records from a storage system 112, create, review, and modify medical records if authorized, communicate with other users in the network, or perform a combination of these functions”).
Claim 15: Giordano discloses the system of claim 11 wherein the treatment device retrieves a treatment recipe from a second smart contract and performs the treatment on the user using the treatment recipe retrieved (0071, “the doctor may determine that one or more settings on the medical device 218 that affect the patient's treatment (e.g., CPAP pressure levels) require adjustment. The doctor, through his or her smart contract, may broadcast a transaction to the network addressed to the medical device's smart contract 218SC. Once the transaction is verified, the medical device's smart contract 218SC may adjust a treatment parameter for the patient accordingly. Due to the architecture of the network and transparency of transactions among nodes, the adjusted treatment can be effected efficiently and securely while minimizing risk of unauthorized users tampering with the medical device 218”).
Claim 16: Giordano discloses the system of claim 11, wherein the control device modifies a second smart contract stored on the blockchain; the modification is associated with a cost of a treatment, a configuration of a treatment, or a treatment list (0003, “The ledger may include blocks of transactions that indicate actions that have been taken on the network since its genesis. In some implementations, the ledger also stores program modules, referred to as smart contracts, which allow participants in a distributed medical records management network to interact with the ledger and with each other. For example, doctors, patients, pharmacists, and insurers may be issued role-specific smart contracts that allow the participants to invoke various records management events on the network”, 0071, “the doctor may determine that one or more settings on the medical device 218 that affect the patient's treatment (e.g., CPAP pressure levels) require adjustment. The doctor, through his or her smart contract, may broadcast a transaction to the network addressed to the medical device's smart contract 218SC. Once the transaction is verified, the medical device's smart contract 218SC may adjust a treatment parameter for the patient accordingly. Due to the architecture of the network and transparency of transactions among nodes, the adjusted treatment can be effected efficiently and securely while minimizing risk of unauthorized users tampering with the medical device 218”).
Claim 17: Giordano discloses the system of claim 11, wherein the physician using a physician device executes a blockchain transaction with a first smart contract that creates a prescription treatment or an authorization for a user or patient (0078, “FIG. 4 depicts a flow of transactions, calls, and smart contract executions … that include a diagnosis of the ailment, lab results related to the diagnostic, and a prescription that the physician 402 has written for the patient 412 for medication to treat the ailment”).
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 of this title, 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 18-19 are rejected under 35 U.S.C. 103 as being unpatentable over Giordano in view of Witchey et al. (U.S. Patent No. 12,462,246, hereinafter Witchey).
Claim 18: Giordano discloses the system of claim 11, but does not appear to explicitly disclose wherein the blockchain comprises Ethereum, and the authorization is provided via smart contract code running on the Ethereum Virtual Machine (at claim 18) or wherein the blockchain comprises Solana, and the authorization is provided via smart contract code running in a Solana Virtual Machine (at claim 19). Witchey, though, teaches “existing record-keeping system technologies, including systems from Ethereum, Chia networks, Solana, Polygon etc., minting DATs as NFTs or otherwise executing smart contract operations incur operation costs. For example, Ethereum charges “gas,” which is a fee provided in Ether tokens to motivate processing of the corresponding operation by Ethereum nodes running the Ethereum virtual machines” (Witchey at column:lines 39:45-52; citation hereafter by number only) and “At the time of this writing, Solana and Polygon have more attractive fee structures supporting minting or managing NFTs, but have less infrastructural support for oracles” (Witchey at 40:7-10). Since Solana, as a virtual machine is an Ethereum Virtual Machine (see Jain below at pertinent prior art not explicitly relied upon), the Examiner understands and finds that to provide the smart contract via an Ethereum or Solana Virtual Machine is applying a known technique to a known device, method, or product ready for improvement to yield predictable results so as to provide more infrastructure support and/or reduce fees.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine or modify the blockchain use of Giordano with the Ethereum and Solana use of Witchey in order to provide the smart contract via an Ethereum or Solana Virtual Machine so as to provide more infrastructure support and/or reduce fees.
The rationale for combining in this manner is that to provide the smart contract via an Ethereum or Solana Virtual Machine is applying a known technique to a known device, method, or product ready for improvement to yield predictable results so as to provide more infrastructure support and/or reduce fees as explained above.
Claim 20 is rejected under 35 U.S.C. 103 as being unpatentable over Giordano in view of Neureuter, Jack, The Rise of Layer 2 Scaling on Ethereum, dated 11 May 2023, downloaded 25 March 2026 from https://www.fidelitydigitalassets.com/research-and-insights/rise-layer-2-scaling-ethereum#:~:text=The%20most%20popular%20types%20of,an%20increase%20in%20transaction%20throughput (hereinafter Neureuter).
Claim 20: Giordano discloses the system of claim 11, but does not appear to explicitly disclose wherein the blockchain is a layer-2 chain settling to Ethereum. Neureuter, however, teaches that “active users and applications using the Ethereum network has grown drastically over time. This pushes Ethereum’s current scalability towards its upper bound and drives up the costs associated with routine network transactions” (at p. 2), and “Ethereum’s current roadmap is fixated primarily around increasing the overall Ethereum network and ecosystem’s scalability. This scaling roadmap consists of two main upgrades: direct on-chain scaling upgrades, which have shifted in focus over time, and indirect off-chain scaling upgrades” (Id.), where
Creating additional base layer throughput can also be done without design changes to a network’s base layer itself. Instead, off-chain solutions allow for transactions to occur in a separate environment from the main chain. The most popular off-chain scaling solution, and the main subject of this paper, are Layer 2 networks.
Layer 2 solutions inherit their security from the underlying Ethereum consensus. These networks have a primary goal of increasing transaction speed, reducing base layer network congestion (thereby lowering individual transaction costs), while inheriting decentralization and security from the underlying layer 1 blockchain.4 Layer 2 networks allow for additional scalability, while not forcing design upgrades or tradeoffs onto the layer 1 blockchain and largely isolating any potential risks to solely the users of that layer 2 scaling protocol.
(Id. at 5-6).
Therefore, the Examiner understands and finds that to use a layer-2 chain settling to Ethereum is applying a known technique to a known device, method, or product ready for improvement to yield predictable results so as to increase transaction speed, reduce base layer network congestion, and lower individual transaction costs, while inheriting decentralization and security from the underlying layer 1 blockchain.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine or modify the blockchain use of Giordano with the layer-2 blockchain use indicated in Neureuter in order to use a layer-2 chain settling to Ethereum so as to increase transaction speed, reduce base layer network congestion, and lower individual transaction costs, while inheriting decentralization and security from the underlying layer 1 blockchain.
The rationale for combining in this manner is that to use a layer-2 chain settling to Ethereum is applying a known technique to a known device, method, or product ready for improvement to yield predictable results so as to increase transaction speed, reduce base layer network congestion, and lower individual transaction costs, while inheriting decentralization and security from the underlying layer 1 blockchain as explained above.
Claims 21-22 are rejected under 35 U.S.C. 103 as being unpatentable over Lu et al. (U.S. Patent Application Publication No. 2020/0082933, hereinafter Lu) in view of Bálint (U.S. Patent Application Publication No. 2021/0064605, hereinafter Bálint) in further view of Puleo et al. (U.S. Patent Application Publication No. 2020/0411151, hereinafter Puleo).
Claim 21: Lu discloses a method comprising:
a physician using a physician client in a blockchain network authorizing or creating a treatment plan for a user using a device in a blockchain network (see Lu at least at, e.g., ¶¶ 0028, “Blockchain technology may consist of a shared log of events that may be kept in blocks of data that are passed to the next transaction in linear order. Thereafter, the transaction (i.e., pre-authorization and authorization) may be noted in the ledger. For example, Pre-Authorization Party A is the patient's primary care physician, Pre-Authorization Party B is a medical specialist and Pre-Authorization Party C is the insurance company. Each party, A, B and C, may need to provide authorization and consensus in order for the patient to seek medical care from the medical specialist (i.e., Pre-Authorization Party B). Once a consensus is reached, the block may be appended to the blockchain and the transaction may be noted in the ledger”, 0029, “Pre-authorization transaction requests and responses may not be tampered with on a blockchain system which may reduce errors and increase the security of the pre-authorization process”, 0030, “A pre-authorization system running on blockchain allows pre-authorization requests and authorization decisions to be traceable; citation hereafter by number only);
the device in the blockchain network further comprises:
a device of the user in the blockchain network, the device comprising a secure enclave and a blockchain client, wherein the treatment device does not locally store treatment recipes (0038, memory, where since 0014 indicates use of “a blockchain network for a secure and transparent pre-authorization process”, the memory is considered a secure enclave, 0028-0030 as above, 0080 and Fig. 4, Referring now to FIG. 4, illustrative cloud computing environment 1000 is depicted. As shown, cloud computing environment 1000 comprises one or more cloud computing nodes 100 with which local computing devices used by cloud consumers, such as, for example, personal digital assistant (PDA) or cellular telephone 1000A, desktop computer 1000B, laptop computer 1000C, and/or automobile computer system 1000N may communicate. Nodes 100 may communicate with one another. They may be grouped (not shown) physically or virtually, in one or more networks, such as Private, Community, Public, or Hybrid clouds as described hereinabove, or a combination thereof. This allows cloud computing environment 1000 to offer infrastructure, platforms and/or software as services for which a cloud consumer does not need to maintain resources on a local computing device”), further:
generating a request for a treatment list from a smart contract on the blockchain network (0028, “Blockchain technology may consist of a shared log of events that may be kept in blocks of data that are passed to the next transaction in linear order. Thereafter, the transaction (i.e., pre-authorization and authorization) may be noted in the ledger. For example, Pre-Authorization Party A is the patient's primary care physician, Pre-Authorization Party B is a medical specialist and Pre-Authorization Party C is the insurance company. Each party, A, B and C, may need to provide authorization and consensus in order for the patient to seek medical care from the medical specialist (i.e., Pre-Authorization Party B). Once a consensus is reached, the block may be appended to the blockchain and the transaction may be noted in the ledger”, 0029, “Pre-authorization transaction requests and responses may not be tampered with on a blockchain system which may reduce errors and increase the security of the pre-authorization process”, 0030, “A pre-authorization system running on blockchain allows pre-authorization requests and authorization decisions to be traceable);
receiving treatment list or prescribed treatment list for the user (0019, “The pre-authorization system may work cohesively with existing technologies and use the output data to extract key features that may be used to analyze and determine a patient treatment plan that may yield a positive medical outcome, result or conclusion. One existing technology output data may include a patient similarity analytics that identifies similar patients”, 0028, “Blockchain technology may consist of a shared log of events that may be kept in blocks of data that are passed to the next transaction in linear order. Thereafter, the transaction (i.e., pre-authorization and authorization) may be noted in the ledger. For example, Pre-Authorization Party A is the patient's primary care physician, Pre-Authorization Party B is a medical specialist and Pre-Authorization Party C is the insurance company. Each party, A, B and C, may need to provide authorization and consensus in order for the patient to seek medical care from the medical specialist (i.e., Pre-Authorization Party B). Once a consensus is reached, the block may be appended to the blockchain and the transaction may be noted in the ledger”, 0029, “Pre-authorization transaction requests and responses may not be tampered with on a blockchain system which may reduce errors and increase the security of the pre-authorization process”, 0030, “A pre-authorization system running on blockchain allows pre-authorization requests and authorization decisions to be traceable);
requesting and receiving authorization for the prescription treatment from a physician smart contract on the blockchain network (0028, “Blockchain technology may consist of a shared log of events that may be kept in blocks of data that are passed to the next transaction in linear order. Thereafter, the transaction (i.e., pre-authorization and authorization) may be noted in the ledger. For example, Pre-Authorization Party A is the patient's primary care physician, Pre-Authorization Party B is a medical specialist and Pre-Authorization Party C is the insurance company. Each party, A, B and C, may need to provide authorization and consensus in order for the patient to seek medical care from the medical specialist (i.e., Pre-Authorization Party B). Once a consensus is reached, the block may be appended to the blockchain and the transaction may be noted in the ledger”, 0029, “Pre-authorization transaction requests and responses may not be tampered with on a blockchain system which may reduce errors and increase the security of the pre-authorization process”, 0030, “A pre-authorization system running on blockchain allows pre-authorization requests and authorization decisions to be traceable);
Lu, however, does not appear to explicitly disclose the device being a treatment device, requesting a prescription treatment recipe from the prescription treatment list, the treatment recipe specifying parameters for execution of a prescription treatment by the treatment device, sending a payment via a blockchain transaction for the authorized prescription recipe; and receiving the prescription treatment recipe and performing the treatment as per the treatment recipe. Bálint, though, teaches “a medical device is provided that is at least partially implantable. The medical device includes an application component configured to apply a therapeutic treatment and/or stimulation signals to a patient, a wireless communications transceiver, and a computer memory storing a parameters library and computer readable instructions. A processor is configured to execute the computer readable instructions so as to: [0008] control application of therapeutic treatment and/or stimulation signals, via the application component, based on parameters stored in the parameters library; [0009] receive, via the wireless communications transceiver, update data representing an update to the parameters library from an external device or system; [0010] transmit at least the update data for verification by a blockchain network and addition of the update data to a verified blockchain public ledger including the update data; [0011] receive, via the wireless transceiver, blockchain public ledger data based on the verified blockchain public ledger; [0012] validate the update to the parameters library based at least on a first condition that the received blockchain public ledger data includes the update data; [0013] when the update to the parameters library is validated, control application of therapeutic treatment and/or stimulation signals, via the application component, based on parameters stored in the parameters library including the update data” (Bálint at 0007-0013). Therefore, the Examiner understands and finds that to use a treatment device, including requesting, receiving, and applying a treatment recipe with specified parameters is applying a known technique to a known device, method, or product ready for improvement to yield predictable results so as to apply updated, current therapeutic parameters.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine or modify the blockchain treatments of Lu with the updated treatment specifics of Bálint in order to use a treatment device, including requesting, receiving, and applying a treatment recipe with specified parameters is applying a known technique to a known device, method, or product ready for improvement to yield predictable results so as to apply updated, current therapeutic parameters.
The rationale for combining in this manner is that to use a treatment device, including requesting, receiving, and applying a treatment recipe with specified parameters is applying a known technique to a known device, method, or product ready for improvement to yield predictable results so as to apply updated, current therapeutic parameters as explained above.
Lu in view of Bálint, however, does not appear to explicitly disclose sending a payment via a blockchain transaction for the authorized prescription recipe. Puleo, though, teaches “a computer-implemented method to configure a device according to an electronic prescription defining an action for a patient” (Puleo at 0006), where “transactions 218-219,228-229, 238-239 (e.g., prescription, approval, usage, payment, remainder, etc.) can be captured in the blocks 210-230 of the blockchain … Thus, the blocks 210-230 are connected and/or otherwise associated with each other and can be used, such as via the hash 212-232, to validate each other, verify associated transactions 218-219, 228-229, 238-239, confirm usage, trigger reordering and/or other instruction, etc.” (Puleo at 0041). Therefore, the Examiner understands and finds that to make payment via blockchain for a prescription is applying a known technique to a known device, method, or product ready for improvement to yield predictable results so as to confirm usage and trigger follow-ups.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine or modify the blockchain treatments of Lu in view of Bálint with the blockchain payment of Puleo in order to make payment via blockchain for a prescription so as to confirm usage and trigger follow-ups.
The rationale for combining in this manner is that to make payment via blockchain for a prescription is applying a known technique to a known device, method, or product ready for improvement to yield predictable results so as to confirm usage and trigger follow-ups as explained above.
Claim 22 is rejected on the same basis as claim 21 above since the recitations above cover the user/patient as well.
Allowable Subject Matter
Claims 1, 3-5, 7, and 9-10 are indicated as allowable over the prior art.
The following is a statement of reasons for the indication of allowable subject matter: The closest prior art of record appears to be Lu in view of Felber in further view of Bálint (as at claims 21-22 above – indicating Lu and Bálint); however, parent independent claim 1 now recites that “in response to receiving an indication of the tampering attempt from the anti-tampering circuitry, initiate erasure of the secure enclave and a device shutdown”. Where Iwasawa et al. (U.S. Patent Application Publication No. 2024/0189048) discloses initiating a device shutdown, there does not appear to be prior art in a related field indicating to erase a memory (e.g., a/the secure enclave) if or when an indication of tampering is detected. Therefore, it does not appear reasonable to combine the prior art of record to arrive at the entirety of the claimed invention.
Response to Arguments
Applicant's arguments filed 29 June 2026 have been fully considered but they are not persuasive.
Applicant first reviews the Office Action and argues the § 112 rejections (Remarks at 7-8); however, the amendment appears to overcome the § 112 rejections. Therefore, the rejections are withdrawn, and the argument is considered moot and not persuasive.
Applicant then argues the § 101 rejections, first in relation to Step 2A, Prong 1, that “The amended claims are directed towards a specific technical architecture utilizing purpose-built hardware, including a secure enclave and anti-tampering circuitry configured to detect physical tampering attempts (e.g., drilling, cutting, abnormal voltage or frequency levels). This architecture is NOT one of the listed forms of organizing human behavior” (Remarks at 9, argument continuing at 10). However, the architecture is not specific – it appears to merely be a client-server where the claimed treatment device can access and/or retrieve a treatment recipe. The hardware is described at Applicant ¶ 0102 (as submitted, 0126 as published) as being a general-purpose computer and/or a general-purpose processor – not “purpose-built hardware”. The “secure enclave” not well described, and per the light of the specification does not appear to require or be anything more than memory, it is therefore interpreted as such. There is no claim requirement regarding drilling or cutting. The only indication of voltage or frequency sensing is dependent claim 10 (and therefore not required at parent claim 1), where a person can monitor or sense voltage or frequency changes or variations and the only description of this does not indicate any specific criteria (e.g., 108-114V, or something similar) but merely that this may “create alarms if they are not within a specified range” (just as with temperature, pressure, etc.). Therefore, the claims are within the general concept and appear to fully encompass what a person can do – monitor conditions and erase data and/or initiate a shutdown if or when the monitored conditions are not within whatever range someone may have indicated.
Applicant then argues Desjardins with respect to a practical application (Remarks at 10-12), alleging that “the claimed approach provides anti-tampering and security features ensuring that devices are not misused or tampered with by guaranteeing that the device will not start to function without valid, immutable interaction with a blockchain, thereby achieving this improvement to technology” (Id. at 11). However, the blockchain merely provides the treatment settings or recipe – the detection or sensing related to tampering or security (detecting temperature, voltage, frequency, light, and even drilling or cutting as argued – if it were claimed) is apparently entirely separate. The blockchain is apparently merely used as the avenue to provide a recipe such as a treatment plan, settings, etc. Applicant appears to allege or imply that to “initiate erasure of the secure enclave and a device shutdown” at the claims is/are “directly tied to the improvements to technology” (Id.); however, people have been erasing memory data and/or shutting down devices for decades – this does not appear to be any improvement to technology, but rather is part of the abstract idea and not an additional element that is considered in relation to a practical application.
Applicant then argues the prior art rejections (Remarks at 14-15), first alleging that “Giordano does not disclose a ‘treatment device’ pulling executable treatment recipes/specifications directly from a blockchain to perform a treatment. Rather, Giordano merely adjusts a parameter on a device (e.g., CPAP pressure levels) based on a doctor updating a medical record” (Id. at 14). However, the claims do not recite or require “pulling executable treatment recipes/specifications directly from a blockchain to perform a treatment” – as recited by Applicant, claim 11 only recites the devices and that they “communicate with a first and a second smart contract in a network”. Further, the parameters such as “CPCP pressure levels” appear to explicitly indicate treatment specifications for a treatment device.
Applicant then argues “Giordano lacks the structural network architecture of communication with ‘a first and a second smart contract’" (Remarks at 14). However, Giordano (as recited above) specifically indicates communication by patients and doctors or physicians with the smart contract, where the CPAP Applicant acknowledges as having parameters changed indicates treatment device communication with the smart contract. Nothing more appears required by the claims.
Applicant then argues “the specification … clearly establishes that the secure enclave is a specialized hardware component that ‘operates independently from the rest of the device and cannot reveal these secrets.’" (Remarks at 14, without a specific reference to where in the specification). This is referring to Applicant ¶ 0015 indicating “A private key 155 and master seed 156 are written to the secure enclave 150 during manufacturing. Enclave 150 operates independently from the rest of the device 101 and cannot reveal these secrets 155”. However, this in no way appears to indicate any “specialized hardware component” – this, as explained at the interpretation, indicates a memory (of apparently any sort), and that in the indicated example is that the memory has “A private key … and master seed” as the data being stored.
Applicant then argues claims 21-22 and the amendment regarding “the treatment device does not locally store treatment recipes” (Remarks at 14), which is addressed by recitation to Lu as at the rejection above.
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Solana.com, EVM vs. SVM: Smart Contracts, undated, downloaded 24 March 2026 from https://solana.com/developers/evm-to-svm/smart-contracts, indicating the page enables someone to “Learn the differences between Ethereum and Solana smart contracts” (at p. 1).
Jain, Shray, An Introduction to the Solana EVM, dated 5 August 2022, downloaded 24 March 2026 from https://www.alchemy.com/overviews/solana-evm, indicating that
A virtual machine is a building block of a virtualized computing resource that exhibits nearly all the same functionality as a computer, including running applications and operating systems. This concept of the virtual machine is not novel. The technology is used across numerous technology ecosystems.
The largest smart contract development platform, Ethereum, uses an Ethereum Virtual Machine (EVM) to run smart contracts on a globally distributed network of nodes. Because there are a lot of developers building Ethereum applications, EVM-compatible blockchains, and people using Ethereum, creating a Solana EVM to make Ethereum smart contracts compatible with Solana's rust-based blockchain is advantageous.
(at p. 1).
DigiKey, Developing Anti-Tamper Protection for Wireless Hardware, dated 21 May 2015, downloaded from https://www.digikey.com/en/articles/developing-anti-tamper-protection-for-wireless-hardware on 25 August 2026, indicating “This article looks at the ways devices are protected against all kinds of tampering, from malware code to physical differential power analysis (DPA) and the ways designers can protect against them, including design techniques and implementing physically unclonable functions (PUF)” (at 1).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SCOTT D GARTLAND whose telephone number is (571)270-5501. The examiner can normally be reached M-F 8:30 AM - 5 PM.
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, Kambiz Abdi can be reached at 571-272-6702. 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.
/SCOTT D GARTLAND/
Primary Examiner, Art Unit 3685
Prosecution Insights