DETAILED ACTION
Status of Claims
Claims 1, 6-9, 11, 16-19, and 21 have been amended.
Claims 5, 15, and 22 have been cancelled
Claims 1-4, 6-14, and 16-21 are currently pending and have been considered by the examiner.
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. Applicant's submission filed on 8 December 2025 has been entered.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 16 January 2024, 21 March 2024, 19 July 2024, 8 December 2025, 23 December 2025, and 11 February 2026 were considered by the examiner.
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 Arguments
Prior Art Rejection:
Applicant asserts that the prior art of record fails to explicitly disclose: that a customer device “transmit[s] a request for… of the plurality of vault systems” on pg. 9 of the remarks received 8 December 2025. The examiner respectfully disagrees.
When considering the BRI of the claimed limitation, the claimed invention simply discloses the transmission of a request for the private key to at least one vault system of the plurality of vault systems. No further limitation is made describing the specific mechanism by which said key is provided other than that the key is received “from” said vault system. Thus, even if Resch discloses using a intermediary to retrieve the encrypted key, the examiner asserts that said disclosed functionality teaches the BRI of the claimed invention and thus disclsoes the aforementioned limitation.
Applicant also asserts that the prior art of record fails to explicitly disclose the newly added limitations because Jain does not explicitly mention multiple signature on a transaction. The examiner respectfully disagrees.
When considering the disclosed function of Jain in combination with the other prior art of record as outlined in the final rejection mailed 8 August 2025, the examiner reasserts that it would have been obvious to one of ordinary skill in the art before the effective filing date to substitute the cryptographic action disclosed by Di Nicola and Pennanen for the specific action of decrypting encrypted data as disclosed by Jain using the private key of the customer yielding the predictable result of an increase in the security strength of the invention by leveraging the well-known security properties of private key encryption for data transmission. Thus, the prior art of record fully discloses the claimed invention.
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-4 and 11-14 is/are rejected under 35 U.S.C. 103 as being unpatentable over Di Nicola et al. (US 20180069697 A1) in view of Pennanen (US 20150356524 A1) in further view of Mercuri et al. (US 20190013948 A1) and Resch (US 20140281550 A1).
Regarding Claims 1 and 11, Di Nicola discloses:
A customer device (See Di Nicola: Fig. 3 – Apparatus 10), comprising:
at least one processor (See Di Nicola: Fig. 3 – Processor 22);
at least one memory communicatively coupled to the at least one processor (See Di Nicola: Fig. 3 Memory 14), the at least one memory configured to: store a customer private key of a plurality of private keys associated with a customer (See Di Nicola: Para. [0062] – “The digital assets are accessed via M-number of cryptographic keys. Access to at least N-out-of-M keys is necessary in order to access the digital assets at a given time. N is a number less than M. The M-number of keys include at least a first key, a second key, and a third key … The key stored on the Apparatus 500 corresponds to the second key”);
wherein the plurality of private keys comprises the customer private key and a plurality of vault private keys, (The examiner has determined that the aforementioned limitation constitutes a recitation of nonfunctional descriptive material. Specifically, the limitation merely further describes the plurality of private of keys but does not impose any functional limitation on the recited method step of storing a customer private key. Thus, as the limitation poses no functional limitation on the claimed method step, the examiner must consider the limitation to be nonfunctional descriptive material and thus cannot give the limitation patentable weight. For purposes of compact prosecution, the examiner cites the following: See Di Nicola: Para. [0062] – “The digital assets are accessed via M-number of cryptographic keys. Access to at least N-out-of-M keys is necessary in order to access the digital assets at a given time. N is a number less than M. The M-number of keys include at least a first key, a second key, and a third key … The key stored on the Apparatus 500 corresponds to the second key” – The examiner asserts that term “vault private key” is functionally analogous to the plurality of M keys disclosed by Di Nicola) and
at least one network interface communicatively coupled to the at least one processor and configured to communicate with at least one vault system, each of the at least one vault system storing a respective one of the N private keys (See Di Nicola: Para. [0062] – “The key stored on the server corresponds to the third key … Apparatus 500 can also include a retrieving unit 540 that retrieves a second visual representation from the server”);
wherein the at least one processor is configured to: receive at least one private key of the private keys from the at least one vault system (See Di Nicola: Para. [0045] – “A user may create an account with a product that manages digital assets (such as a digital wallet, for example). The account may be created with a company that implements the digital wallet. After creating the account (with the company), the user receives a private key (such as a first key, as described above)”); and
perform at least one cryptographic action based on the at least one private key and the customer private key (See Di Nicola: Para. [0062] – “The third cryptographic key signs the first visual representation … the second visual representation is generated when the first visual representation meets the conditions of the third cryptographic key … Apparatus 500 can also include a determining unit 550 that determines whether the second visual representation meets condition of the second cryptographic key for accessing the digital assets.” – When considering the BRI of the claimed “cryptographic action”, the cryptographic determination disclosed by Di Nicola discloses the BRI of the claimed term).
Di Nicola fails to explicitly disclose:
Receiving at least one vault private key via the network interface at the customer device form at least one vault system
Performing a cryptographic action using both the at least one vault private key and the customer private key
However, in a similar field of endeavor, Pennanen discloses:
Receiving at least one vault private key via the network interface at the customer device from at least one vault system (See Pennanen: Para. [0031] – “to send the PIN code from the mobile terminal via a secure channel to open a vault in the one or more virtual machines, wherein the vault contains one or more private keys (PK) which are useable for authenticating the at least one cryptocurrency transaction”)
Performing a cryptographic action using the at least one vault private key (See Pennanen: Para. [0031] – “to send the PIN code from the mobile terminal via a secure channel to open a vault in the one or more virtual machines, wherein the vault contains one or more private keys (PK) which are useable for authenticating the at least one cryptocurrency transaction”)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date to modify the system of Di Nicola to additionally incorporate the vault private key disclosed by Pennanen as an additional security vector yielding the predictable result of an increase in the security strength of the invention by utilizing multi-factor authentication.
However, the combination fails to explicitly disclose:
Wherein the plurality of vault private keys are stored at at least one vault system of a plurality of vault systems
However, in a similar field of endeavor, Mercuri discloses:
wherein the plurality of vault private keys are stored at at least one vault system of a plurality of vault systems (See Mercuri: para. [0033] – Mercuri discloses a blockchain network with multiple participant nodes wherein each participant node locally stored a private key and wherein said private keys of each node are alos stored in an off-chain key vault)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date to apply the blockchain private key identity security structure disclosed by Mercuri to handle and transfer the private keys disclosed by the combination of Pennanen and Nicola yielding the predictable result of an increase in the security strength of the invention by leveraging the immutable nature of the blockchain.
However, the combination of Pennanen, Nicola, and Mercuri fails to explicitly disclose:
transmit a request for at least one vault private key of the plurality of vault private keys to the at least one vault system of the plurality of vault systems
However, in a similar field of endeavor, Resch discloses:
transmit a request for at least one vault private key of the plurality of vault private keys to the at least one vault system of the plurality of vault systems (See Resche: Para. [0113] – “The method begins with the step 170 where the DS managing unit receives a retrieve key request from a requester (e.g., any system element). Note that the key may be previously stored in the user vault and or DSN memory as an encrypted key as was previously discussed.”)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date to apply key request method disclosed by Resch to request the vault private keys disclosed by the combination of Pennanen, Nicola, and Mercuri on demand yielding the predictable result of an increase in the security strength of the invention by only providing keys when specifically requested.
However, the combination fails to explicitly disclose:
(1) decrypt encrypted data using the at least one private key and the customer private key; (2) encrypt data based on a public key derived from the at least one private key and the customer private key; (3) generate a transaction address using a hashing function and based on a public transaction key derived from the at least one private key and the customer private key; or (4) cryptographically sign a transaction using the at least one private key and the customer private key.
However, in a similar field of endeavor, Jain discloses:
(1) decrypt encrypted data using the at least one private key and the customer private key; (2) encrypt data based on a public key derived from the at least one private key and the customer private key; (3) generate a transaction address using a hashing function and based on a public transaction key derived from the at least one private key and the customer private key; or (4) cryptographically sign a transaction using the at least one private key and the customer private key (See Jain: Para. [0017]).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date to substitute the cryptographic action disclosed by Di Nicola, Pennanen, Mercuri, and Resch for the specific action of decrypting encrypted data as disclosed by Jain using the private key of the customer yielding the predictable result of an increase in the security strength of the invention by leveraging the well-known security properties of private key encryption for data transmission. Thus, the prior art of record fully discloses the claimed invention.
Regarding Claims 2 and 12, Di Nicola discloses:
wherein the at least one processor is further configured to generate the plurality of private keys and wherein the at least one network interface is further configured to transmit each respective vault private key of the plurality of vault private keys from the customer device to the respective vault system of the plurality of vault system (See Di Nicola: Para. [0029] – “In a more complex scenario, the digital wallet can also be fully accessed through a multi-key approach. When the user initially creates a digital wallet, the first key is generated and stored on the user's device; See Di Nicola: Para. [0062] – “Apparatus 500 can also include a first generating unit 520 that generates a first visual representation of the request to restore access to digital assets. Apparatus 500 can also include a presenting unit 530 that presents the first visual representation to the server”).
Regarding Claims 3 and 13, Di Nicola discloses:
wherein the plurality of private keys are generated by at least one of the plurality of vault system or the customer device (See Di Nicola: Para. [0029] – “In a more complex scenario, the digital wallet can also be fully accessed through a multi-key approach. When the user initially creates a digital wallet, the first key is generated and stored on the user's device; See Di Nicola: Para. [0062] – “Apparatus 500 can also include a first generating unit 520 that generates a first visual representation of the request to restore access to digital assets. Apparatus 500 can also include a presenting unit 530 that presents the first visual representation to the server”)
Regarding Claims 4 and 14, Di Nicola discloses:
wherein the at least one processor is further configured to transmit identity data for the customer; wherein the customer is authenticated, based on the identity data, at each of the plurality of vault system or at an identity services provider (See Di Nicola: Para. [0037] – “With certain embodiments, if a user loses the user's digital wallet, resulting in a loss of control/access to the first digital key, the user can contact the company that is associated with implementing the digital wallet. After the company confirms the identity of the user, the company can generate a request for accessing the third key, for the purpose of re-establishing access to the user's digital wallet.”)
Claim(s) 6, 16, and 22 is/are rejected under 35 U.S.C. 103 as being unpatentable over Di Nicola in view of Pennanen in further view of Mercuri, Resch and Jain (US 20190057368 A1).
Regarding Claims 6, 16, and 22, Di Nicola discloses:
A customer device (See Di Nicola: Fig. 3 – Apparatus 10), comprising:
at least one processor (See Di Nicola: Fig. 3 – Processor 22);
at least one memory communicatively coupled to the at least one processor (See Di Nicola: Fig. 3 Memory 14), the at least one memory storing a customer private key of N private keys associated with a customer (See Di Nicola: Para. [0062] – “The digital assets are accessed via M-number of cryptographic keys. Access to at least N-out-of-M keys is necessary in order to access the digital assets at a given time. N is a number less than M. The M-number of keys include at least a first key, a second key, and a third key … The key stored on the Apparatus 500 corresponds to the second key”);
wherein the plurality of private keys comprises the customer private key and a plurality of vault private keys, (The examiner has determined that the aforementioned limitation constitutes a recitation of nonfunctional descriptive material. Specifically, the limitation merely further describes the plurality of private of keys but does not impose any functional limitation on the recited method step of storing a customer private key. Thus, as the limitation poses no functional limitation on the claimed method step, the examiner must consider the limitation to be nonfunctional descriptive material and thus cannot give the limitation patentable weight. For purposes of compact prosecution, the examiner cites the following: See Di Nicola: Para. [0062] – “The digital assets are accessed via M-number of cryptographic keys. Access to at least N-out-of-M keys is necessary in order to access the digital assets at a given time. N is a number less than M. The M-number of keys include at least a first key, a second key, and a third key … The key stored on the Apparatus 500 corresponds to the second key” – The examiner asserts that term “vault private key” is functionally analogous to the plurality of M keys disclosed by Di Nicolaand
at least one network interface communicatively coupled to the at least one processor and configured to communicate with at least one vault system, each of the at least one vault system storing a respective one of the N private keys (See Di Nicola: Para. [0062] – “The key stored on the server corresponds to the third key … Apparatus 500 can also include a retrieving unit 540 that retrieves a second visual representation from the server”);
wherein the at least one processor is configured to: receive at least one private key of the N private keys from the at least one vault system (See Di Nicola: Para. [0045] – “A user may create an account with a product that manages digital assets (such as a digital wallet, for example). The account may be created with a company that implements the digital wallet. After creating the account (with the company), the user receives a private key (such as a first key, as described above)”);
Di Nicola fails to explicitly disclose:
Receiving at least one vault private key via the network interface at the customer device form at least one vault system
Performing a cryptographic action using both the at least one vault private key and the customer private key
However, in a similar field of endeavor, Pennanen discloses:
Receiving at least one vault private key via the network interface at the customer device from at least one vault system (See Pennanen: Para. [0031] – “to send the PIN code from the mobile terminal via a secure channel to open a vault in the one or more virtual machines, wherein the vault contains one or more private keys (PK) which are useable for authenticating the at least one cryptocurrency transaction”)
Performing a cryptographic action using the at least one vault private key (See Pennanen: Para. [0031] – “to send the PIN code from the mobile terminal via a secure channel to open a vault in the one or more virtual machines, wherein the vault contains one or more private keys (PK) which are useable for authenticating the at least one cryptocurrency transaction”)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date to modify the system of Di Nicola to additionally incorporate the vault private key disclosed by Pennanen as an additional security vector yielding the predictable result of an increase in the security strength of the invention by utilizing multi-factor authentication.
However, the combination of Di Nicola and Pennanen fails to explicitly disclose:
signing a transaction, using the at least one private key and the customer private key
transferring funds from a multi-approval transaction address in a customer wallet
However, the combination of Di Nicola and Pennanen fails to explicitly disclose
perform at least one of: (1) decrypt encrypted data using the at least one private key and the customer private key; (2) encrypt data based on a public key derived from the at least one private key and the customer private key; (3) generate a transaction address using a hashing function and based on a public transaction key derived from the at least one private key and the customer private key; or (4) cryptographically sign a transaction using the at least one private key and the customer private key.
However, in a similar field of endeavor, Jain discloses:
Decrypting encrypted data using a private key associated with a digital wallet or cryptocurrency wallet of a user (See Jain: Para. [0017])
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date to substitute the cryptographic action disclosed by Di Nicola and Pennanen for the specific action of decrypting encrypted data as disclosed by Jain using the private key of the customer yielding the predictable result of an increase in the security strength of the invention by leveraging the well-known security properties of private key encryption for data transmission
Claim(s) 7-10 and 17-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Di Nicola in view of Hill et al. (US 20190164221 A1).
Regarding Claims 7 and 17, Di Nicola discloses the customer device of claim 1 but fails to explicitly disclose:
wherein the at least one cryptographic action comprises: deriving a plurality of public transaction keys from the plurality of private keys; and generating a multi-approval transaction address based on the plurality of public transaction keys; wherein at least a subset of the plurality of private keys are required to transact from the multi-approval transaction address.
However, in a similar field of endeavor, Hill discloses:
deriving a plurality of public transaction keys from the plurality of private keys; and generating a multi-approval transaction address based on the plurality of public transaction keys; wherein at least a subset of the plurality of private keys are required to transact from the multi-approval transaction address. (See Hill: Fig. 2 and Para. [0038] – “After the parties in the system 200 have generated their keys, a multisig public key can be generated from the three public keys generated by the participants. Each party may communicate the party's public key to any or all of the other parties in the system 200 until at least one party has all three public keys. The three public keys are inputs to create the multisig address that will serve as the digital asset collateral wallet 208. The multisig address of the wallet 208 is also termed herein the multisig wallet deposit address. A participant that calculates the multisig wallet deposit address may communicate the address to the other parties. Alternatively, or additionally, each party may calculate the public multisig key address independently if the party has received the public keys of each of the other parties in the system 200.”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date to substitute the cryptographic action disclosed by Di Nicola and Pennanen for the cryptographic action of deriving keys for generation of a multisig address as disclosed by Hill yielding the predictable result of an increase to the ease of use and security of the invention (See Hill: Para. [0024])
Regarding Claims 8 and 18, the combination discloses:
wherein the at least one cryptographic action comprises: receiving funds into a generated transaction address as part of a transaction (See Hill: Para. [0076] – “In a depositing operation 814, the borrower 802 deposits digital asset(s) into the digital asset wallet 806”); and
transmitting, from the customer device, the transaction to a node implementing a distributed ledger for recording on the distributed ledger (See Hill: Para. [0076] – “The depositing operation 814 may include a single or multiple transactions broadcast to a blockchain network.”).
Regarding Claims 9 and 19, the combination discloses:
wherein the at least one cryptographic action comprises: generating, at the customer device, a transaction (See Hill: Para. [0078] – “If the digital assets in the collateral wallet 806 satisfy the withdrawal condition, the borrower 802 may request transaction signatures from other holders of private keys to the collateral wallet 806. In the case of a 2-of-3 multisig collateral wallet, a borrower 802 requesting signatures must obtain at least one other signature to unlock the wallet 806. The requesting operation 818 may therefore be additionally, or alternatively, directed to the lender. A forming operation 820 forms a transaction to spend from the collateral wallet 806.”); and signing the transaction, at the customer device, using the at least one vault private key and the customer private key (See Hill: Fig. 8: Step 820 – FORM/SIGN SPEND Tx).
Regarding Claims 10 and 20, the combination discloses:
wherein the transaction is a sweeping transaction that transfers all funds from at least one input transaction address in a customer wallet to a new transaction address (See Hill: Para. [0083] – “The example of FIG. 13 illustrates a digital asset collateral wallet 1308 that requires 2-of-3 multisig's during the loan period and only one digital signature from the borrower after the end of the loan period. The configuration illustrated in FIG. 13 protects both borrower and lender because the lender can still liquidate digital asset collateral if needed at any point during the course of the loan. If the loan term has expired, then either the loan was repaid in full to the lender or the lender liquidated digital asset collateral to satisfy deficiencies in loan repayment.” – Hill discloses that the collateral account can be liquidating in any amount to repay the loan which includes a complete liquidation/sweeping transaction).
Claim(s) 21 is/are rejected under 35 U.S.C. 103 as being unpatentable over Di Nicola in view of Pennanen, in further view of Mercuri, Resch, Hill and VOORHEES (US 20170154331 A1).
Regarding Claim 21, Di Nicola discloses the method of claim 11 but fails to explicitly disclose:
wherein performing the at least one cryptographic action comprises signing a transaction, using the at least one private key and the customer private key, transferring funds from a multi-approval transaction address in a customer wallet; and wherein the multi-approval transaction address in the customer wallet is generated at a currency conversion system, using a hashing function, based on the N private keys; wherein the currency conversion system transmits the multi-approval transaction address to the customer device.
However, in a similar field of endeavor, Hill discloses:
signing a transaction, using the at least one private key and the customer private key (See Hill: Fig. 8: Step 820 – FORM/SIGN SPEND Tx),
transferring funds from a multi-approval transaction address in a customer wallet (See Hill: Para. [0083] – “The example of FIG. 13 illustrates a digital asset collateral wallet 1308 that requires 2-of-3 multisig's during the loan period and only one digital signature from the borrower after the end of the loan period. The configuration illustrated in FIG. 13 protects both borrower and lender because the lender can still liquidate digital asset collateral if needed at any point during the course of the loan. If the loan term has expired, then either the loan was repaid in full to the lender or the lender liquidated digital asset collateral to satisfy deficiencies in loan repayment.”); and
However, the combination of Di Nicola and Hill fails to explicitly disclose:
wherein the multi-approval transaction address in the customer wallet is generated at a currency conversion system, using a hashing function, based on the N private keys;
wherein the currency conversion system transmits the multi-approval transaction address to the customer device.
However, in a similar field of endeavor, Voorhees discloses:
wherein the multi-approval transaction address in the customer wallet is generated at a currency conversion system, using a hashing function, based on the N private keys (See Voorhees: Para. [0074] – “At step 403, the Exchange will use the key1 generated by UserA to generate public Key2 and any other data necessary for the transaction. The keys act as the signatures on the multisig account.”);
wherein the currency conversion system transmits the multi-approval transaction address to the customer device (See Voorhees: Para. [0075] – “At step 408, the Deposit Address is sent to UserA”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date to modify the system disclosed by Di Nicola and Hill to additionally function in conjunction with a currency conversion system in addition to a collateral system as disclosed by Voorhees yielding the predictable result of a more economic viable invention by leveraging the well-known technique of diversification.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Sewell et al. (US 20210090072 A1) generally discloses a computer-implemented method for improving the security of a data record distribution process using blockchain via key sharing and the use of generated stealth addresses.
Kirsch (US 20150088754 A1) generally discloses using encryption keys to derive transfer addressed for funds used to purchase products.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to NICHOLAS K PHAN whose telephone number is (571)272-6748. The examiner can normally be reached M-F 1 pm-9 pm EST.
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, Neha Patel can be reached on 571-270-1492. 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.
/NICHOLAS K PHAN/Examiner, Art Unit 3699