DETAILED ACTION
The present application 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.
This Office Action is in response Applicant communication filed on 10/9/2025.
Restriction/Election Acknowledgement
Applicant’s election on claims 1-15 without traverse is acknowledged.
Claims
Claims 16-20 have been withdrawn from consideration as being directed to non-elected subject matter.
Claims 1-20 are currently pending in the application.
Claim Objections
Claim 14 is objected to because of the following informalities:
Claim 14 recites “the computing system of claim 1, wherein the operations further include…” (emphasis added). Claim 1 is a computer-implemented method. The examiner believes that the applicant mean to recite that claim 14 is dependent on the computing system of claim 8 and not claim 1.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(B) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 8-13 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor, or for pre-AIA the applicant regards as the invention. In this instant case,
Claim 8 recites “obtaining, by a computing system of a platform, an end user request to create an end user digital wallet on behalf of the end user” (emphasis added). It is unclear whether “a computing system of a platform” is referring to the same computing system of a platform recited in the preamble.
Further claims 9-13 are also rejected as being dependent on claim 8 above.
Rejections under 35 § U.S.C. 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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1-5, 7-12, 14, and 15 are rejected under 35 U.S.C. 103 as being unpatentable over US 20200219094 A1 (“Dikhit”) and US 20240265381 A1 (“Antonino”) and US 20230350881 A1 (“Vukich”).
Per claims 1, 8 and 15, Dikhit teaches:
one or more processors (e.g. For example, may comprise one or more network environments, servers, computer-based systems, processors, databases, and/or the like. Security provider system 112 may comprise at least one computing device in the form of a computer or processor, or a set of computers/processors, although other types of computing units or systems may be used, such as, for example, a server, web server, pooled servers, or the like. Security provider system 112 may also include one or more data centers, cloud storages, or the like, and may include software, such as APIs, SDKs, etc. configured to retrieve and write data to the user device 104, browser 106, crypto-wallet 108, and/or security provider plugin 110. In various embodiments, security provider system 112 may include one or more processors and/or one or more tangible, non-transitory memories and be capable of implementing logic. The processor may be configured to implement various logical operations in response to execution of instructions, for example, instructions stored on a non-transitory, tangible, computer-readable medium, as discussed further herein) (Section [0026]);
one or more non-transitory computer-readable media that collectively store instructions that, when executed by the one or more processors, cause the computing system to perform operations (e.g. For example, may comprise one or more network environments, servers, computer-based systems, processors, databases, and/or the like. Security provider system 112 may comprise at least one computing device in the form of a computer or processor, or a set of computers/processors, although other types of computing units or systems may be used, such as, for example, a server, web server, pooled servers, or the like. Security provider system 112 may also include one or more data centers, cloud storages, or the like, and may include software, such as APIs, SDKs, etc. configured to retrieve and write data to the user device 104, browser 106, crypto-wallet 108, and/or security provider plugin 110. In various embodiments, security provider system 112 may include one or more processors and/or one or more tangible, non-transitory memories and be capable of implementing logic. The processor may be configured to implement various logical operations in response to execution of instructions, for example, instructions stored on a non-transitory, tangible, computer-readable medium, as discussed further herein) (Section [0026]);
obtaining, by a computing system of a platform, an end user request to create an end user digital wallet on behalf of the end user (e.g. Browser 106 may receive a request to create a wallet address (e.g., a blockchain address or a transaction address) (step 210) and, in response, browser based crypto-wallet 108 may generate a key pair including a public key (i.e., the wallet address) and a private key associated with the public key (step 212)) (Section [0032]);
generating, by the computing system of the platform, the end user digital wallet for the end user, wherein generating, by the computing system of the platform, the end user digital wallet comprises obtaining a user private key and a user public key, and generating user authentication information (e.g. Browser 106 may receive a request to create a wallet address (e.g., a blockchain address or a transaction address) (step 210) and, in response, browser based crypto-wallet 108 may generate a key pair including a public key (i.e., the wallet address) and a private key associated with the public key (step 212). Browser 106 may, via security provider plugin 110, prompt the user 102 for a user ID and password to associate with the wallet address (step 214). User 102 may input the user ID and password information in browser 106 via user device 104 (step 216). Browser 106 may pass the user ID and password to controller 114 via security provider plugin 110 (step 218). Controller 114 may pass the user ID and password to crypto module 116 (step 220) and, in response to receiving the user ID and password, crypto module 116 may hash the user ID and password to produce a password hash (step 222). Controller 114 may save the password hash in the repository 118 as a stored password hash (step 224). In various embodiments, step 224 may include associating the stored password hash with the account creation information) (Section [0032]).
Although Dikhit teaches receiving a user request to create a digital wallet and generating the user digital wallet including wallet private/public keys and user authentication information, Dikhit does not specifically disclose:
maintaining, by the platform, the end user digital wallet for the end user;
obtaining, by the computing system of the platform, a request from the end user to transfer custody of the end user digital wallet to a recipient;
providing, by the computing system of the platform, the user private key to the recipient.
However Antonino, in analogous art of custodial wallets, discloses:
maintaining, by the platform, the end user digital wallet for the end user (e.g. Thus it will be seen that, in accordance with embodiments of the invention, a user's private key is held securely in an encrypted enclave of a server, and the user can then instruct the custody server to sign transactions on the user's behalf, within a trusted execution environment (“TEE”) of the server. The server is referred to herein as a “custody server”, because it acts as custodian for the key. The custody server can thus relieve the user of the burden and risk of having to handle his or her private keys, thereby providing convenience for the user and confidence to recipients of the signed transaction) (Section [0015], [0022]-[0029], and [0174]).
It would have been obvious to one of ordinary skill in the art as of the effective filing date of the claimed invention to modify the digital wallet system of Dikhit to include the maintaining of the user’s private key, as taught by Antonino, in order to achieve the predictable result of relieving the user of the burden and risk of having to handle his or her private keys, thereby providing convenience for the user and confidence to recipients of the signed transaction (See Antonino paragraph [0029]).
Although Dikhit/Antonino teaches generating a user digital wallet and maintaining the user’s digital wallet for the user, Dikhit/Antonino do not specifically disclose:
obtaining, by the computing system of the platform, a request from the end user to transfer custody of the end user digital wallet to a recipient;
providing, by the computing system of the platform, the user private key to the recipient.
However Vukich, in analogous art of digital wallets, discloses:
obtaining, by the computing system of the platform, a request from the end user to transfer custody of the end user digital wallet to a recipient (e.g. The method may include receiving 215 (e.g., via an API and recovery agent 120), a wallet recovery request associated with the first smart contract. The wallet recovery request may specify recovery wallet 140 (e.g., a third smart contract) as being a recipient wallet for assets 112. However, this is merely an example. In some cases, recovery agent 120 may instantiate recovery wallet 140 in response to receiving a recovery request) (Section [0036], [0040], and [0041]);
providing, by the computing system of the platform, the user private key to the recipient
(e.g. The instantiation logic 124 may modify an existing code file (e.g., template) of a recovery wallet to generate a case-specific recovery wallet 140 (e.g., by providing a delivery address associated with the owner of smart wallet 110, such as an e-mail address, for delivery of the recovery wallet 140 private key)) (Section [0036]).
It would have been obvious to one of ordinary skill in the art as of the effective filing date of the claimed invention to modify the digital wallet system of Dikhit/Antonino to include the capability to transfer the digital wallet to a recipient and giving them access to the wallet private key, as taught by Vukich, in order to achieve the predictable result of providing user security by giving them control over their own wallet and private key.
Per claims 2 and 9, Dikhit/Antonino/Vukich discloses all the limitations of claims 1 and 8 above. Antonino further discloses:
wherein maintaining, by the computing system of the platform, the end user digital wallet for the end user comprises maintaining, by the computing system of the platform, custody of the user private key (e.g. Thus it will be seen that, in accordance with embodiments of the invention, a user's private key is held securely in an encrypted enclave of a server, and the user can then instruct the custody server to sign transactions on the user's behalf, within a trusted execution environment (“TEE”) of the server. The server is referred to herein as a “custody server”, because it acts as custodian for the key. The custody server can thus relieve the user of the burden and risk of having to handle his or her private keys, thereby providing convenience for the user and confidence to recipients of the signed transaction) (Section [0015], [0022]-[0029], and [0174]).
The motivation to combine Antonino with Dikhit/Vukich is described above with reference to claims 1, 8, and 15.
Per claims 3 and 10, Dikhit/Antonino/Vukich discloses all the limitations of claims 1 and 8 above. Dikhit further discloses:
wherein generating, by the computing system of the platform, the end user digital wallet further comprises, and providing to the end user the public key and the user authentication information (e.g. For example, each participant may register with blockchain network 120, and/or an existing trust participant (e.g., identity provider), and may be assigned and provided a private key and public key pair) (e.g. In various embodiments, the browser 106 may prompt the user 102 to save the passcode in cold storage) (Section [0022] and [0032]-[0034]).
Per claims 4 and 11, Dikhit/Antonino/Vukich discloses all the limitations of claims 1 and 8 above. Dikhit further discloses:
wherein the user authentication information comprises user login data (e.g. Browser 106 may, via security provider plugin 110, prompt the user 102 for a user ID and password to associate with the wallet address (step 214). User 102 may input the user ID and password information in browser 106 via user device 104 (step 216). Browser 106 may pass the user ID and password to controller 114 via security provider plugin 110 (step 218). Controller 114 may pass the user ID and password to crypto module 116 (step 220) and, in response to receiving the user ID and password, crypto module 116 may hash the user ID and password to produce a password hash (step 222). Controller 114 may save the password hash in the repository 118 as a stored password hash (step 224). In various embodiments, step 224 may include associating the stored password hash with the account creation information) (Section [0032]).
Per claims 5 and 12, Dikhit/Antonino/Vukich discloses all the limitations of claims 1 and 8 above. Vukich further discloses:
wherein the recipient is the end user (e.g. According to some embodiment, there may be provided a method of recovering blockchain wallet items, the method including: receiving, from a user device, log-in credentials associated with a user account; receiving, from the user device, an indication that a key associated with a user smart wallet associated with the user account has been lost; initiating a validation and recovery process for items stored in the user smart wallet; instantiating a recovery smart wallet; transferring the items stored in the user smart wallet to the recovery smart wallet; and associating the recovery smart wallet with the user account) (Section [0014]).
The motivation to combine Vukich with Dikhit/Antonino is described above with reference to claims 1, 8, and 15.
Per claims 7 and 14, Dikhit/Antonino/Vukich discloses all the limitations of claim 1 above. Antonino further discloses:
obtaining, by the computing system of the platform, end user transaction data from the end user (e.g. receive a request to sign a transaction on behalf of a user of the plurality of users) (Sections [0041]-[0048]);
confirming, by the computing system of the platform, the end user initiated a transaction according to the end user transaction data (e.g. receive user-authentication data for the user; [0047] determine, within the trusted execution environment, whether the user-authentication data satisfies the access policy for the transaction-signing key pair associated with the user) (Section [0041]-[0048]);
signing, by the computing system of the platform, the transaction with the user private key (e.g. when the user-authentication data satisfies the access policy, use the private key of the transaction-signing key pair associated with the user to sign the transaction, within the trusted execution environment, on behalf of the user, and output data representative of the signed transaction) (Section [0048]);
broadcasting, by the computing system of the platform, the transaction to a blockchain (e.g. Assuming the user-authentication data, and any other required conditions for the requested transaction, satisfy the access policy, the CS 4 builds and signs the transaction with the wallet private key, using the transaction signing module 42 executing within the TEE enclave associated with the user 20 (step 5). It sends the signed transaction back to the DAB 3 as byte array (step 6). The DAB 3 can then implement the authorised transaction, e.g. by performing appropriate operations on a blockchain of the cryptocurrency) (Sections [0048] and [0180]).
It would have been obvious to one of ordinary skill in the art as of the effective filing date of the claimed invention to modify the digital wallet transaction process of Dikhit/Vukich to authenticate the user before allowing the custodial service to use the user’s private key to perform a transaction, as taught by Antonino, in order to achieve the predictable result of increasing the security and convenience of the user by not requiring them to remember their private key to perform transactions with their digital wallet while at the same time ensuring that the user is authorized to perform transactions using the digital wallet.
Claims 6 and 13 are rejected under 35 U.S.C. 103 as being unpatentable over Dikhit/Antonino/Vukich, as applied to claims 1 and 8 above, in further view of US 20150254640 A1 (“Cassano”).
Per claims 6 and 13, Although Dikhit/Antonino/Vukich discloses providing the user private key to the recipient, Dikhit/Antonino/Vukich do not specifically disclose:
wherein providing, by the computing system of the platform, the user private key to the recipient comprises removing, by the computing system of the platform, the private key from custody of the computing system of the platform.
However Cassano, in analogous art of digital wallets, discloses:
wherein providing, by the computing system of the platform, the user private key to the recipient comprises removing, by the computing system of the platform, the private key from custody of the computing system of the platform (e.g. For security of the new wallet 408, the POS system 401 may choose to remove all information of the new wallet 408 so that only the buyer 492 has the access to the private key of the new wallet 408) (Sections [0052] and [0053]).
It would have been obvious to one of ordinary skill in the art as of the effective filing date of the claimed invention to modify the private key provisioning system of Dikhit/Antonino/Vukich to include the removal of the private key from the system after it is provided to the user, as taught by Cassano, in order to achieve the predictable result of increasing security by ensuring that only the user contains the private key to their wallet.
Conclusion
The following prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
US Publication Number 20250173705 A1 to Osborn teaches a system and method that generates public and private keys for a user wallet and then sends them to the user. US Publication Number 20210383363 A1 to Smirnov teaches a system and method that requests creation of a digital wallet and then generates a private key and public key for the digital wallet. US Publication Number 20230376944 A1 to Filter teaches a system and method that utilizes both custodial wallets and non-custodial wallets.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TIMOTHY P SAX whose telephone number is (571) 272-2935. The examiner can normally be reached on M-F 8-4:30.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Patrick McAtee can be reached at (571) 272-7575. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/TS/
Examiner, Art Unit 3698
/PATRICK MCATEE/Supervisory Patent Examiner, Art Unit 3698