DETAILED ACTION
This final office action is in response to claims 1-7 and 14-17 filed on 02/12/2026 for examination. Claims 1-7 and 14-17 are being examined and are pending.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
Response to Amendment
The amendment filed February 12, 2026 has been entered. Claims 1-13 remain pending in the application. Claims 8-13 are withdrawn. Claims 14-17 are new. The claims have been amended. Applicant’s arguments and amendments have overcome each and every claim objection and drawings objection previously set forth in the Non-Final Office Action mailed August 12, 2025. Further, claim 1 has been amended and has necessitated a new ground(s) of rejection in this Office Action. Therefore, Applicant’s arguments filed on 02/12/2026 have been fully considered but are moot in view of the new ground(s) of rejection because the arguments do not apply to any of the updated reference(s) as being used in the current rejection.
Claim Objections
Claim(s) 1-2 and 4 is/are objected to because of the following informalities:
Claim 1 recites “the set of secure removably storage drives” in lines 11-12. Examiner suggests amending to, e.g., “the set of secure removable
Claim 1 recites “A secure hardware cryptocurrency keystore system […]” in line 1. For consistency (see, e.g., claim 2-line 1, claim 3 line-1, etc.), Examiner suggests amending to “A secure hardware cryptocurrency key store system […]”, if intended.
Claim 2 recites “wherein the keygen processor […]”. For consistency (see, e.g., claim 1 line 7), Examiner suggests amending to, e.g., “wherein the key generator machine processor” or similar, if intended. Claim 4 recites a similar deficiency, and is objected to under like rationale.
Appropriate correction is required.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1-2, 5-7, and 14-17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Martin et al. (US20190318356, hereinafter “Martin”) in view of Hoersten et al. (US20190305943, hereinafter “Hoersten”).
Regarding claim 1, Martin teaches a secure hardware cryptocurrency keystore system for performing a key generation ceremony ([0035-037] – the secure key system performs a key generation ceremony and stores cryptocurrency keys) comprising:
an air-gapped cryptocurrency generator machine ([0034-036] – secure computing system is the same system as the key storage system and the key generation system; [0039] and [0041] – a secure computing system <i.e., key storage/generation system> is offline/disconnected from a communication network, e.g., air-gapped from the network) including:
a terminal for accepting configuration parameters for a cryptocurrency key generation ceremony with a group of individual key holders ([0070] and [0063-064] – parameters for the shards/keys to be generated for key holders are received via a management account; [0047] and [0049] – management accounts implemented on computing systems <i.e., on terminals>);
a key generator machine processor that executes key generation instructions to create a master seed [[based on the entropy source]] ([0022] and [0052-054] – a cryptocurrency private key <i.e., master seed> is generated, and a plurality of shards/keys are generated based on the cryptocurrency private key), generate a fingerprint based on the master seed ([0051] – the cryptocurrency private key <i.e., master seed> is used to generate a corresponding public key. The cryptocurrency private key/public key have an associated cryptocurrency private key identifier. The cryptocurrency private key identifier may be, e.g., a cryptocurrency address generated by taking a hash of the cryptocurrency public key <i.e., cryptocurrency address is a “fingerprint” based on the master seed>), and to generate a set of private keys based on the master seed (Fig. 1 and [0057-058] – cryptocurrency private key is encrypted; [0061] and [0063-064] – encrypted cryptocurrency private key is used to generate a plurality of private key alpha shards <i.e., private keys> using, e.g., Shamir’s Secret Sharing <i.e., private keys generated based on the cryptocurrency private key/master key>), wherein the master seed is deleted after use ([0020] and [0036] – the cryptocurrency private key is used to generate the alpha shards and cryptocurrency public key <i.e., fingerprint> and then discarded <i.e., discarded>. The cryptocurrency private key never leaves the system intact);
a set of secure removable storage drives, each secure removable storage drive in the set of secure removably storage drives being uniquely associated with one of a group of individual key holders ([0042-045] and [0039] – beta shards <i.e., encrypted alpha shard/key> are delivered to/stored in, e.g., the separate <i.e., removable> HSM/physical storage system of an assigned shard/key holder; and [0076-077] – the shards and storages are uniquely assigned to individual key holders);
a key distribution input/output data port in communication with the key generator machine processor that receives the set of secure removable storage drives ([0042-045] and [0076-077] – beta shards <i.e., encrypted alpha shards> stored in, e.g., the separate <i.e., removable> HSM/physical storage system of an assigned shard/key holder; [0040] and [0123] – secure storage system/key generation system interface with other systems <i.e., have input/output ports in communication> including the user devices/off-chain systems);
a facilitator encryption key for generating a facilitator encrypted payload including the fingerprint and at least one of the set of private keys to each individual key holder in the set ([0020-021], [0042-045], and [0075-76] – each alpha shard <i.e., at least one private key of the set> is encrypted into a beta shard using a corresponding secondary encryption key <i.e., facilitator encryption key>. The beta shard and the beta shard’s associated auxiliary information are used as Beta Shard Information <i.e., facilitator encrypted payload comprising auxiliary information>. The included auxiliary information may be, e.g., the cryptocurrency private key identifier <i.e., payload includes the fingerprint>. Each beta shard information <i.e., facilitator encrypted payloads> may then be provided to their holders/physical storage systems/etc.); and
a secure removable storage device processor for storing and further encrypting the facilitator encrypted payload such that none of the individual key holders or a facilitator has access to the master seed or the set of private keys ([0080-081] and [0042-045] – the beta shard information <i.e., facilitator encrypted payload> is in a digital format provided to an HSM/physical storage system <i.e., secure removable storage device processor>. The beta shard information <i.e., facilitator encrypted payload> may be further encoded/encrypted when processed for storage in the HSM/physical storage system <i.e., secure removable storage device processor>; [0020], [0067], and [0121] – the cryptocurrency private key <i.e., master seed> and the alpha shards <i.e., private keys> may be discarded <i.e., none of the key holders or facilitators hold them>).
While Martin teaches executing instructions create a master seed (see, e.g., [0022] and [0052-054] – cryptographic private key generation), Martin appears to fail to specifically disclose an entropy source; and a keygen key generator machine processor executing that executes key generation instructions that to create a master seed based on the entropy source.
However, Hoersten teaches a security blockchain wallet system (see abstract, [0029]), comprising an entropy source ([0029-030] – receiver generates a cryptographically secure random entropy in its memory <i.e., is entropy source>); a keygen key generator machine processor executing that executes key generation instructions that to create a master seed based on the entropy source ([0029-030] – receiver generates a cryptographically secure random entropy in its memory <i.e., is entropy source>. The random entropy is then used to generate the master cryptographic private key <i.e., master seed>).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the air-gapped key generator of Martin with the teachings of Hoersten, comprising an entropy source; a keygen processor executing key generation instructions that create a master seed based on the entropy source, to ensure the cryptographic private key <i.e., master seed> is unpredictable and cannot be guessed based a function (see, e.g., Martin at [0029-030] and [0034]).
Regarding claim 2, the combination of Martin and Hoersten teach the secure hardware cryptocurrency key store system of claim 1, wherein the keygen processor encrypts each payload with a master payload encryption key before each payload is copied to one of the secure removeable storage devices (Martin at [0069] and [0075] – each user has a public key <i.e., master key of the user> which is used by the secure computing system to encrypt all the alpha shards <i.e., payload> received; [0042-045] and [0081] – alpha shards <i.e., the private key of the set> are encrypted into beta shards with associated information and stored in, e.g., separate hardware security modules).
Regarding claim 5, the combination of Martin and Hoersten teach the secure hardware cryptocurrency key store system of claim 1, wherein each secure removable storage drive in the set of secure removable storage devices include anti-tamper circuitry ([0042-045] and [0065-066] – alpha shards <i.e., the private keys of the set> are encrypted into beta shards and stored in, e.g., the separate <i.e., removable> HSM/physical storage system of an assigned shard/key holder; [0076-077] and [0081] – shards saved onto, e.g., the separate HSM/physical storage system for an assigned shard/key holder; Note: As would be recognized by one of ordinary skill in the art before the effective filing date of the claimed invention, a hard security module (HSM) is a tamper-resistance hardware device. While not presently relied upon, for additional definition see, e.g., NPL: “What are Hardware Security Module (HSM)s”, March 2021).
Regarding claim 6, the combination of Martin and Hoersten teach the secure hardware cryptocurrency key store system of claim 1, wherein the set of private keys are shards produced according to Shamir's Secret Sharing Scheme (S4) (Martin at Fig. 1 and [0061] and [0063-064] – encrypted cryptocurrency private key is sharded into private key shards <i.e., private keys> using, e.g., Shamir’s Secret Sharing Scheme).
Regarding claim 7, the combination of Martin and Hoersten teach the secure hardware cryptocurrency key store system of claim 6, wherein the key generation instructions include a request via the terminal for the facilitator to select an m-of-n sharding arrangement for generation of the shards (Martin at Fig. 1 and [0061] and [0063-064] – encrypted cryptocurrency private key is sharded into private key shards <i.e., private keys> using, e.g., Shamir’s Secret Sharing Scheme based on received parameters from a system user; see also [0017] and [0070] – m-of-n sharding parameters set).
Regarding claim 14, the combination of Martin and Hoersten teach the secure hardware cryptocurrency key store system of claim 1, wherein the master seed is one of a plurality of master seeds (Martin at [0025], [0036], and [0055] – a plurality of cryptocurrency public-private key pairs are generated, e.g., as a batch. Each cryptocurrency private key <i.e., master seed> is then used for its subset of information; [0022] and [0052-054] – a plurality of shards/keys are generated based on the cryptocurrency private key <i.e., cryptocurrency master key is a master seed>).
Regarding claim 15, the combination of Martin and Hoersten teach the secure hardware cryptocurrency key store system of claim 1, further comprising: a decryption key storage removable drive that stores the facilitator encryption key used in generating the facilitator encrypted payload ([0045] and [0092-095] – a key holder interface can be a physical storage device holding the secondary encryption keys <i.e., facilitator encryption key>. The key holder interface interfaces with the secure computing system to exchange shard/key information; [0034-035] and [0123] Storage devices can be, e.g., usb drives, floppy drives, CDs, etc. that interface with the computing system <i.e., input/ouput data port>); and a second input/output data port that receives the decryption key storage removable drive ([0045] and [0092-095] – a key holder interface can be a physical storage device holding the secondary encryption keys <i.e., facilitator encryption key>. The key holder interface interfaces with the secure computing system to exchange shard/key information; [0034-035] and [0123] – Storage devices can be, e.g., usb drives, floppy drives, CDs, etc. that interface with the computing system <i.e., input/ouput data port>).
Regarding claim 16, the combination of Martin and Hoersten teach the secure hardware cryptocurrency key store system of claim 1, further comprising: a second removable storage drive (Martin at [0042-044] and [0077-082] – beta shard information <i.e., encrypted alpha shard + auxiliary data> can also be stored in physical media, e.g., HSMs, physical repositories, etc. Each beta shard holder has their own physical media storage device <i.e., second, third, etc. removable storages>; [0034-035] and [0123] – Storage devices can be, e.g., usb drives, floppy drives, CDs, etc. that interface with the computing system <i.e., input/ouput data port>), wherein the secure removable storage device stores a public key corresponding to a private key of the set of private keys for an individual key holder (Martin at [0020-022], [0042], and [0067-069] – alpha shards <i.e., private keys of the set of private keys> are encrypted using the public secondary encryption keys/key holder public keys <i.e., public keys corresponding to the alpha shards for individual key holders>; [0042-044] and [0077-082] – beta shard information <i.e., encrypted alpha shard + auxiliary data> can be stored in physical media, e.g., HSMs, physical repositories, etc.).
Regarding claim 17, the combination of Martin and Hoersten teach the secure hardware cryptocurrency key store system of claim 16, further comprising: a transaction signing machine (Martin at [0038-040] and [0103-104] – secure computing system <i.e., transaction signing machine> receives an unsigned transaction request and signs it with the restored cryptocurrency key) that receives a second removable storage device comprising an unsigned blockchain transaction constructed from the public key (Martin at [0040], [0051], and [0103-106] – a transaction request is received with an unsigned transaction for a cryptocurrency address <i.e., unsigned blockchain ntransaction>. The cryptocurrency address may be a hash of the public key <i.e., request is constructed from the public key>).
Claim(s) 3-4 is/are rejected under 35 U.S.C. 103 as being unpatentable over Martin in view of Hoersten, further in view of Weight et al. (US20190220859, hereinafter “Weight”).
Regarding claim 3, while the combination of Martin and Hoersten teach the secure hardware cryptocurrency key store system of claim 1, as well as adding a multi-sig functioning key shard as a payload onto storage devices to be provided to an associated signing party (see, e.g., Martin at [0042-0045] and [0081]). Yet, the combination of Martin and Hoersten appear to fail to specifically teach wherein the payload includes an extended private key.
However, Weight teaches a multi-sig system for alternatively distributing extended private keys (see, e.g., Weight at [0043-044] and [0050-053]), wherein an extended private key is distributed to the recipient key holders in lieu of key shards (Weight at [0043-044] and [0050-053] – system may distribute private keys to signers instead of using Shamir secret sharing; [0234] ad [0238] – account keys are distributed to the multi-sig parties; [0210] and [0071] – distributed private account key is an extended private key).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the combination of Martin and Hoersten with the teachings of Weight, wherein the payload includes an extended private key, to provide improved key security to distributed ledgers which run native multi-sig systems (see, e.g., Weight at [0043-044] and [0050-053]).
Regarding claim 4, while the combination of Martin and Hoersten teach the secure hardware cryptocurrency key store system of claim 1, as well as a removable blockchain transaction delivery device to which the keygen processor copies an [[extended]] public key [[based on the master seed]] via the key distribution input/output data port (Martin at [0042-046] and [0081] – the information copied to the separable HSM <i.e., removeable transaction delivery device> includes the public key of a key holder, the HSM is used to store and deliver keys for the signing of transactions on the distributed ledger; [0040] and [0123] – secure storage system/key generation system interface with other systems <i.e., have input/output ports in communication> including the user devices/off-chain systems). However, the combination of Martin and Hoersten appear to fail to specifically teach wherein the public key of the key holder is an extended public key based on the master seed.
However, Weight teaches a multi-sig system for alternatively distributing extended private keys (see, e.g., Weight at [0043-044] and [0050-053]), wherein the distributed public key is an extended public key based on the master seed (Weight at [0043-044] and [0050-053] – system may distribute private keys to signers instead of using Shamir secret sharing; [0234] ad [0238] – account keys are distributed to the multi-sig parties; [0069] and [0079-080] – public account key is generated based on the master seed; [0210] and [0071] – distributed private account key and associated public account keys are extended keys).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the combination of Martin and Hoersten with the teachings of Weight, comprising a removable blockchain transaction delivery device to which the keygen processor copies an extended public key based on the master seed via the key distribution input/output port, to provide improved key security to distributed ledgers which run native multi-sig systems (see, e.g., Weight at [0043-044] and [0050-053]).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure: Gancarz et al. (US20200028675) teaches a system for signing transactions using air-gapped private keys, wherein the private keys are generated using a hardware entropy generator (see, e.g., Gancarz at abstract, [0047]). Pospieszalski (US20220253813) teaches a process for a multi-sig crypto system using a hieratical deterministic wallet, wherein keys are generated in an air-gapped server (see, e.g., Pospieszalski at [0040], [0046], and [0125]). NPL: “What Are Hardware Security Modules (HSM)s?” (March 2021) defines an HSM as a tamper-resistant hardware device (see, e.g., pg. 1).
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JOSHUA RAYMOND WHITE whose telephone number is (571)272-4365. The examiner can normally be reached Monday-Thursday, & Alternate Fridays.
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, Taghi Arani can be reached at 5712723787. 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.R.W./Examiner, Art Unit 2438 /TAGHI T ARANI/Supervisory Patent Examiner, Art Unit 2438
Prosecution Insights