DETAILED ACTION
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 .
This application is a CIP of 18/239,050 08/28/2023 ABN
18/239,050 has PRO 63/401,514 08/26/2022
Status of Claims
Claims 1, 2, and 5-8 are currently pending and rejected.
Claims 3, 4, and 9-21 are canceled.
Claim Rejection – 35 U.S.C. 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claim 1 is rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention. The amended limitations, “a vault module configured to store and encrypt the at least one digital asset within a secure storage contains that is accessible exclusively through said verified user identifier” and “a withdrawal module configured to return and decrypt the at least one digital asset to said user upon detection of a verified retrieval request authenticated through said verification module”. The specification does not mention encryption or decryption of any kind. These newly added limitations are not given patentable weight.
Claim Rejection – 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, 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, and 5-8 is/are rejected under 35 U.S.C. 103 as being unpatentable over Ingargiola (Pub. No.: US 2021/0073913), in view of Harrison et al. (Patent No.: US 12,265,953) and Jiang et al. (CN 112598523 A).
As per claim 1, Ingargiola teaches a system for the storage and retrieval of digital assets comprising:
a processor disposed in connection with a memory having computer-readable instructions stored thereon, said processor configured to execute a storage system (see paragraph 0103, “System 130 includes a processing unit (CPU or processor) 154 and a system connection 138 that couples various system components including the system memory 146, read on memory (ROM) 148, and random access memory (RAM) 150, to the processor 154”), said storage system comprising:
an initiation module configured to register a user, and generate a unique user identifier (see paragraph 0165, “A trader 810 is registered with and has access to the virtual custodian 802; see paragraph 0306, in another embodiment, trader can register with a governance node without any custodian; also see paragraph 0135, “receives the client request for reservation of collateral on UI or via API 512 via request communication 514 which contains client specific identifiers…receives request communication 514 at display and/or interface 518 and verifies client identifiers”, prior art teaches a user is identified by a unique user identifier);
a verification module configured to verify the identity of said user (see paragraph 0070, “verifying, by the custodian module, an authenticity of the client and the request by mapping personal details received from the request against the custodial ledger”; also see paragraph 0150), through multifactor authentication (see paragraph 0062 and 0201, “thus enabling sponsoring firm to perform all applicable functions through a web portal accessed through a multi-factor authentication process”; also see paragraph 0135, “receives the client request for reservation of collateral on UI or via API 512 via request communication 514 which contains client specific identifiers…receives request communication 514 at display and/or interface 518 and verifies client identifiers”);
a bailee module configured to receive at least one digital asset (see paragraph 0070, “The method can further include receiving, from the client and at the custodian module, a request for a reservation of assets representing at least a portion of the collateral”, the “custodian module” in prior art is the same as bailee module in the present claim; see paragraph 0112, “These user interface can enable clients to transfer assets to a custodian 302”; see paragraph 0334, “receiving at the custodian entity, collateral from a client, the collateral being of the asset type; maintaining the collateral in a custodial ledger of the custodian entity”; also see paragraph 0087, 0206, 0227, 0236);
a contracting module configured to execute at least one smart contract between said user and the storage system, said smart contract defining storage condition for said digital assets (see paragraph 0099, “The architecture disclosed herein in one aspect includes a fully decentralized governance approach and autonomous software such as smart contracts that can be stored on and executed by blockchain systems”; see paragraph 0112, “The approach can also cover any type of digital asset storage mechanism including protocols that can lock and unlock and transfer assets based on meeting logical criterion, smart contracts, etc.”);
a vault module configured to store and encrypt the at least one digital asset within a secure storage container that is accessible exclusively through said verified user identifier (see paragraph 0069, “The method can also include receiving, at the custodian entity operating the custodian module, collateral from a client, the collateral being of the asset type”; see paragraph 0112, “The approach can also cover any type of digital asset storage mechanism”; see paragraph 0186, “All communications, such as API calls, secure communications, requests for information, responses to requests, network security, encryption of data, decryption of data and so worth, are considered to be included within the scope of this application where different entities need to perform respective functions to carry out the overall process described herein with respect to the creation and use of the blockchain-based ledgers”; also see paragraph 0135, “receives the client request for reservation of collateral on UI or via API 512 via request communication 514 which contains client specific identifiers…receives request communication 514 at display and/or interface 518 and verifies client identifiers”; ); and
a withdrawal module configured to return and decrypt the at least one digital asset to said user upon detection of a verified retrieval request authenticated through said verification module (see paragraph 0079, “the system can allow access to traders an order entry system, initiate issuance and redemption requests to the custodian module”; see paragraph 0139, “The custodian blockchain node 522 generates the initial ledger root metadata containing ownership information (identifying the custodian) and conditions applicable to all clients requesting issuance or redemption of collateral”; see paragraph 0148, “Redemption of collateral form the custodian 520 is initiated by the present cryptographically provable owners such as the client 508 by sending a request including at least the asset…and amount being redeemed off the custodian’s ledger”; the custodian module in prior art provides the function of withdrawal module; see paragraph 0186, “All communications, such as API calls, secure communications, requests for information, responses to requests, network security, encryption of data, decryption of data and so worth, are considered to be included within the scope of this application where different entities need to perform respective functions to carry out the overall process described herein with respect to the creation and use of the blockchain-based ledgers”).
Ingargiola does not explicitly teach generate a unique user identifier associated with a user wallet, a bailee configured to receive at least one digital asset, directly from said user wallet without transfer to a third-party custodian.
Harrison teaches generate a unique user identifier associated with a user wallet (see col 23 line 22-43, “A digital asset account identifier and/or digital wallet identifier may comprise a public key and/or a public address. Such a digital asset account identifier may be used to identify an account in transactions; also see col 231, line 20-52, “Notification instruction may specify the frequency of notifications (e.g., real-time, once a day, once a week, or name a few), the notification alert types (e.g., SMS, email, mobile application push notifications, to name a few), and/or notification recipient information (e.g., email address, telephone number, mobile device ID, digital wallet ID, to name a few)”, prior art teaches a unique user account/wallet ID is created to identify the user account in transactions);
a bailee configured to receive at least one digital asset, directly from said user wallet without transfer to a third-party custodian (see col 39 line 46 through col 40 line 9, “the exchange may operate a pooled or omnibus digital wallet system, e.g., as part of a centralized exchange system. The pooled system may use an electronic ledger to track digital asset ownership for each exchange customer. Customers may transfer digital assets from their own digital wallets to an exchange address in order to fund their digital asset account on the exchange”; also see col 40 line 20-30, prior art also teaches an alternative embodiment, where user’s digital asset is sent to a custodial account to be held, so in order words, the embodiment without custodian and the embodiment relying on custodian are interchangeable; see col 205 line 31-67, “In step S222’, an exchange user using computer system or user device can send to a deposit address associated with a deposit digital wallet maintained by the exchange, which in turn receive, assets (e.g., digital math assets such as bitcoin) to be deposited with the exchange”, “In step S240, an exchange deposit digital wallet can be created using the exchange computer system to receive assets from one or more user digital wallets”).
It would have been obvious to one of ordinary skill in the art at the effective filing date of the present application to modify Ingargiola with teaching from Harrison to include generate a unique user identifier associated with a user wallet, a bailee configured to receive at least one digital asset, directly from said user wallet without transfer to a third-party custodian. The modification would have been obvious, because it is merely applying known technique (i.e., generating a unique user identifier associated with a user wallet and receiving digital asset directly from user wallet without going through a third-party custodian) to a known system (i.e., digital assets storage and retrieval) ready to provide predictable result (i.e., securely identify a user wallet, and removing delays and security concerns by bypassing a third-party custodian).
Examiner further notes, the combination of Ingargiola and Harrison does not explicitly teach whitelist user wallet prior to any transaction.
Jiang teaches whitelist user wallet prior to any transaction (see page 2, “As a preferred technical solution, the security module setting request IP white list, request frequency limit, off-line signature verification, cold and hot wallet separation, port strictly limited”).
It would have been obvious to one of ordinary skill in the art at the effective filing date of the present application to modify the combination of Ingargiola and Harrison with teaching from Jiang to include whitelist user wallet prior to any transaction. The modification would have been obvious, because it is merely applying known technique (i.e., using a whitelist for verification) to a known system (i.e., digital assets storage and retrieval) ready to provide predictable result (i.e., use simple and well-known whitelist to enhance security).
As per claim 2, Ingargiola teaches wherein said initiation module is configured to receive contact information and billing information related to said user (see paragraph 0117 and 0175).
Claim 3 and 4 are canceled.
As per claim 5, Ingargiola teaches wherein said at least one smart contract is recorded on a distributed ledger (see paragraph 0060, 0066, 0078, and 0110).
As per claim 6, Ingargiola teaches wherein said vault module is configured to store said at least one digital asset according to a vault component consisting of one of the group selected from hot storage, cold storage, and hybrid storage (see paragraph 0148, “cryptographic wallets of any kind (e.g., hot or cold storage, software or hardware)”).
As per claim 7, Ingargiola teaches wherein said withdrawal module is configured to be initiated upon the termination of the smart contract (see paragraph 0175 and 0349-0350).
As per claim 8, Ingargiola teaches wherein said withdrawal module may be limited at any time by said user (see paragraph 0175 and 0349-0350).
Claims 9-21 are cancelled.
Response to Remarks
Applicant’s arguments, see Remarks, filed on 11/06/2025, with respect to rejection under 35 U.S.C. 101 have been fully considered and are persuasive. The claim rejection under 35 U.S.C. 101 has been withdrawn.
In the claims filed on 11/06/2025, Applicant amended independent claim 1 and argued that the amended claims eliminate the custodian. Examiner points out that in Applicant’s specification, the custodian party not entirely eliminated. The smart contract is still configured to tie a user and one custodian to a single wallet. Examiner cites a new prior art, Harrison et al. (Patent No.: US 12,265,953), to address transferring digital asset without third-party custodian. Updated rejection is provided in this Office Action.
Conclusion
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 HAO FU whose telephone number is (571)270-3441. The examiner can normally be reached 9:00 AM - 6:00 PM PST.
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, Christine M Behncke can be reached at (571) 272-8103. 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.
/HAO FU/Primary Examiner, Art Unit 3695
JAN-2026