Prosecution Insights
Last updated: April 19, 2026
Application No. 18/313,700

METHOD OF EXITING A NON-FUNGIBLE TOKEN BLOCKCHAIN

Final Rejection §101§103
Filed
May 08, 2023
Examiner
HYDER, MD SAKIB
Art Unit
3698
Tech Center
3600 — Transportation & Electronic Commerce
Assignee
The Everest Project LLC
OA Round
2 (Final)
0%
Grant Probability
At Risk
3-4
OA Rounds
3y 0m
To Grant
0%
With Interview

Examiner Intelligence

Grants only 0% of cases
0%
Career Allow Rate
0 granted / 8 resolved
-52.0% vs TC avg
Minimal +0% lift
Without
With
+0.0%
Interview Lift
resolved cases with interview
Typical timeline
3y 0m
Avg Prosecution
28 currently pending
Career history
36
Total Applications
across all art units

Statute-Specific Performance

§101
35.7%
-4.3% vs TC avg
§103
41.6%
+1.6% vs TC avg
§102
0.7%
-39.3% vs TC avg
§112
19.3%
-20.7% vs TC avg
Black line = Tech Center average estimate • Based on career data from 8 resolved cases

Office Action

§101 §103
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 . Status of Claims The following is a FINAL Office Action in response to Applicant’s amendments filed on 10/09/2025. a. Claims 21, 26, 36 are amended b. Claims 1-20, 22-23, 28-29, 40 are cancelled Overall, Claims 21, 24-27, 30-39 are pending and have been considered below. Information Disclosure Statement (IDS) The information disclosure statement (IDS) submitted on 06/26/2025, 09/11/2025, 01/08/2026 are in compliance with the provisions of 37 CFR 1.97. Accordingly, such IDS is being considered by Examiner. Claim Objection(s) Claim 36 objected to because of the following informality: “at least smart device” should read, “at least one smart device”. Appropriate correction is required. Claim Rejections - 35 USC § 101 35 USC 101 reads as follows: Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title. Claims 21, 24-27, 30-39 are rejected under 35 USC 101 because the claimed invention is not directed to patent eligible subject matter. The claimed matter is directed to a judicial exception, i.e. an abstract idea, not integrated into a practical application, and without significantly more. Per Step 1 of the multi-step eligibility analysis, claims 21, 24-27, 30-35 are directed to a computer implemented method, claims 36-39 are directed to a system. Thus, on its face, each independent claim and the associated dependent claims are directed to a statutory category of invention. Per Step 2A.1. Claim 21 is rejected under 35 USC 101 because the claim is directed to an abstract idea, a judicial exception, without reciting additional elements that integrate the judicial exception into a practical application. The limitations of the independent claim 1 recite an abstract idea, shown in bold, while the non-bolded claim elements recite additional element according to MPEP 2106.04(a). [A] A method A method of exiting a blockchain comprising: [B] receiving a user-initiated exit request containing a security token; [C] initiating an authentication queue; [D] requesting authentication information to confirm a wallet exit request from a user controlling a digital wallet for which the exit request was received; [E] verifying the authentication information; [F] retrieving unique identifying information for the user and wallet file data from a local network; [G] matching the unique identifying information and the wallet file data to the authentication information in the exit request; [H] decrypting the wallet file data; and [I] appending the decrypted wallet file data to the digital wallet. [J] sending a wallet blockchain removal request to an activation programming interface (API) request queue; and [K] removing the digital wallet from a stored wallet database in such a manner that the user no longer relies on the blockchain to provide storage for any assets held in the digital wallet, [L] wherein the user thereby controls the digital wallet for which the exit request was received and maintains full ownership of the digital wallet and any assets contained therein. Claim 21 recites: receiving a request ([B]); receiving and verifying authentication information ([C]-[G]); decrypting and adding file data ([H]-[I]); sending a removal request ([J]); and removing the wallet and controlling the asset within the wallet ([K]-[L]), which, based on the claim language and in view of the application disclosure, represents enabling system for managing data. This overall combination, covers agreement in the form of contracts business relationships because the claim language recites authenticating, and removing of wallet and digital assets, which falls under Certain Methods of Organizing Human Activity, i.e., Commercial or Legal Interactions grouping of abstract ideas (see MPEP 2106.04(a)(2)). Accordingly, it is reasonable to conclude that claim 21 recites an abstract idea that corresponds to a judicial exception. Per Step 2A.2. The identified abstract idea is not integrated into a practical application because the additional elements in the independent claims only amount to instructions to apply the judicial exception to a computer, or are a general link to a technological environment (see MPEP 2106.05(f); MPEP 2106.05(h)). For example, the additional elements “blockchain,” “security,” and “exit,” “digital” recite computing elements at a high level of generality, which is equivalent to instructions to implement the abstract idea “by a computer” or “on a computer.” The additional elements do not preclude from carrying out the identified abstract idea of managing data. Therefore, those additional elements do not serve to integrate the identified abstract idea into practical application. The additional elements in the independent claims, shown not bolded above, recite: sending a wallet blockchain removal request to an activation programming interface (API) ([J]). When considered individually or as an ordered combination, they amount to nothing more than reception, transmission and/or general computation (i.e., not specific enough computation) of claim elements that serves merely to implement the abstract idea using computing components for performing computer functions (adding the words “apply it” or an equivalent), or merely uses a computer as a tool to perform the identified abstract idea. Therefore, the additional elements of claim 21 do not integrate the identified abstract idea into a practical application and the claims remain a judicial exception. Per Step 2B. Claim 21 does not include additional elements that are sufficient to amount to significantly more than the judicial exception because, when the independent claim is reevaluated as a whole, as an ordered combination under the considerations of Step 2B, the outcome is the same like under Step 2A.2. Therefore, when considered as a whole and as an ordered combination, the additional elements in the claim amount to instructions to apply the abstract idea on a computer. Moreover, as noted above, there is nothing the computing and additional element (limitation [J]), that is significant or meaningful to the underlying abstract idea because the identified abstract idea of managing data could have been reasonably performed when provided with the relevant data and/or information. Therefore, it is concluded that independent claim 21 deemed ineligible. Per Step 2A.1. Claim 36 is rejected under 35 USC 101 because the claim is directed to an abstract idea, a judicial exception, without reciting additional elements that integrate the judicial exception into a practical application. The limitations of the independent claim 1 recite an abstract idea, shown in bold, while the non-bolded claim elements recite additional element according to MPEP 2106.04(a). [A] A system comprising: [B] at least smart device hosting a native application; [C] at least one processor capable of executing logical functions in operable communication with the native application; [D] at least one non-transitory computer readable storage medium having instructions encoded thereon that, when executed by the at least one processor, implements operations to generate a user-initiated exit request containing a security token, the instructions including: [E] initiate an authentication queue; [F] request authentication information to confirm a wallet exit request from a user controlling a digital wallet for which the exit request was received; [G] activate a user denial response handler simultaneously with requesting authentication information; [H] verifying the authentication information; [I] retrieving unique identifying information for the user and wallet file data from a local network; [J] matching the unique identifying information and the wallet file data to the authentication information in the exit request; [K] decrypting the wallet file data; and [L] appending the decrypted wallet file data to the digital wallet. [M] sending a wallet blockchain removal request to an activation programming interface (API) request queue; and [N] removing the digital wallet from a stored wallet database in such a manner that the user no longer relies on the blockchain to provide storage for any assets held in the digital wallet, [O] wherein the user thereby controls the digital wallet for which the exit request was received and maintains full ownership of the digital wallet and any assets contained therein. Claim 36 recites: receiving a request ([D]); receiving and verifying authentication information ([E]-[J]); decrypting and adding file data ([K]-[L]); sending a removal request ([M]); and removing the wallet and controlling the asset within the wallet ([N]-[O]), which, based on the claim language and in view of the application disclosure, represents enabling system for managing data. This overall combination, covers agreement in the form of contracts business relationships because the claim language recites authenticating, and removing of wallet and digital assets, which falls under Certain Methods of Organizing Human Activity, i.e., Commercial or Legal Interactions grouping of abstract ideas (see MPEP 2106.04(a)(2)). Accordingly, it is reasonable to conclude that claim 36 recites an abstract idea that corresponds to a judicial exception. Per Step 2A.2. The identified abstract idea is not integrated into a practical application because the additional elements in the independent claims only amount to instructions to apply the judicial exception to a computer, or are a general link to a technological environment (see MPEP 2106.05(f); MPEP 2106.05(h)). For example, the additional elements “smart device,” “processor,” “native application,” “blockchain,” “security,” and “exit,” “digital” recite computing elements at a high level of generality, which is equivalent to instructions to implement the abstract idea “by a computer” or “on a computer.” The additional elements do not preclude from carrying out the identified abstract idea of managing data. Therefore, those additional elements do not serve to integrate the identified abstract idea into practical application. The additional elements in the independent claims, shown not bolded above, recite: smart device for hosting ([B]), processor for executing logic for communication ([C]), sending request to an activation programming interface (API) ([M]). When considered individually or as an ordered combination, they amount to nothing more than reception, transmission and/or general computation (i.e., not specific enough computation) of claim elements that serves merely to implement the abstract idea using computing components for performing computer functions (adding the words “apply it” or an equivalent), or merely uses a computer as a tool to perform the identified abstract idea. Therefore, the additional elements of claim 36 do not integrate the identified abstract idea into a practical application and the claims remain a judicial exception. Per Step 2B. Claim 36 does not include additional elements that are sufficient to amount to significantly more than the judicial exception because, when the independent claim is reevaluated as a whole, as an ordered combination under the considerations of Step 2B, the outcome is the same like under Step 2A.2. Therefore, when considered as a whole and as an ordered combination, the additional elements in the claim amount to instructions to apply the abstract idea on a computer. Moreover, as noted above, there is nothing the computing and additional element (limitation [J]), that is significant or meaningful to the underlying abstract idea because the identified abstract idea of managing data could have been reasonably performed when provided with the relevant data and/or information. Therefore, it is concluded that independent claim 36 deemed ineligible. Dependent Claims: Claims 24-27, 30-35, 37-39 are analyzed for subject matter eligibility. However, these claims fails to recite patent eligible subject matter for following reasons: Claim 24, recites the following bolded claim elements as abstract ideas while the non-bolded claim elements recites additional elements according to MPEP 2106.04(a). The claim further recites: [A] deleting any archived pass phrase files and archived wallet file data from archived storage upon successful matching of the unique identifying information and wallet file data to the authentication information in the exit request. The claim further recites the abstract idea of managing data. In other words, it recites limitation grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The non-bolded additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP 2106.05(f)). Claim 25, recites the following bolded claim elements as abstract ideas while the non-bolded claim elements recites additional elements according to MPEP 2106.04(a). The claim further recites: [A] generating a notification of a successful match; and [B] generating a prompt for the user controlling the digital wallet for which the exit request was received to download the wallet file data. The claim further recites the abstract idea of authenticating the user. In other words, it recites limitation grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The non-bolded additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP 2106.05(f)). Claim 26, recites the following bolded claim elements as abstract ideas while the non-bolded claim elements recites additional elements according to MPEP 2106.04(a). The claim further recites: [A] wherein the digital wallet is removed from the stored wallet database after generating the prompt for the user to download the wallet file data. The claim further recites the abstract idea of managing data. In other words, it recites limitation grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The non-bolded additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP 2106.05(f)). Claim 27, recites the following bolded claim elements as abstract ideas while the non-bolded claim elements recites additional elements according to MPEP 2106.04(a). The claim further recites: [A] wherein the user controlling the digital wallet for which the exit request was received maintains full ownership of the digital wallet and any assets contained therein upon successful download of the wallet file data. The claim further recites the abstract idea of managing data and maintaining ownership of asset. In other words, it recites limitation grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The non-bolded additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP 2106.05(f)). Claim 30, recites the following bolded claim elements as abstract ideas while the non-bolded claim elements recites additional elements according to MPEP 2106.04(a). The claim further recites: [A] decrypting a first part of the wallet file data with a first cipher; and [B] decrypting a second part of the wallet file data with a second cipher. The claim further recites the abstract idea of decrypting data. In other words, it recites limitation grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The non-bolded additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP 2106.05(f)). Claim 31, recites the following bolded claim elements as abstract ideas while the non-bolded claim elements recites additional elements according to MPEP 2106.04(a). The claim further recites: [A] decrypting a third part of the wallet file data with the second cipher. The claim further recites the abstract idea of decrypting data. In other words, it recites limitation grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The non-bolded additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP 2106.05(f)). Claim 32, recites the following bolded claim elements as abstract ideas while the non-bolded claim elements recites additional elements according to MPEP 2106.04(a). The claim further recites: [A] requesting the third part of the wallet file data to be uploaded from a device owned by the user controlling the digital wallet for which the exit request was received. The claim further recites the abstract idea of managing data. In other words, it recites limitation grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The non-bolded additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP 2106.05(f)). Claim 33, recites the following bolded claim elements as abstract ideas while the non-bolded claim elements recites additional elements according to MPEP 2106.04(a). The claim further recites: [A] wherein the third part of the wallet file data is uploaded automatically upon initiation of the exit request by the user. The claim further recites the abstract idea of managing data. In other words, it recites limitation grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The non-bolded additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP 2106.05(f)). Claim 34, recites the following bolded claim elements as abstract ideas while the non-bolded claim elements recites additional elements according to MPEP 2106.04(a). The claim further recites: [A] wherein the first cipher further comprises an activation programming interface (API) cipher that was used to encrypt the first part of the wallet file data and the third part of the wallet file data upon original creation of the wallet file data. The claim further recites the abstract idea of managing data. In other words, it recites limitation grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The non-bolded additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP 2106.05(f)). Claim 35, recites the following bolded claim elements as abstract ideas while the non-bolded claim elements recites additional elements according to MPEP 2106.04(a). The claim further recites: [A] wherein the second cipher further comprises a server cipher that was used to encrypt the second part of the wallet file data upon the original creation of the wallet file data. The claim further recites the abstract idea of managing data. In other words, it recites limitation grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The non-bolded additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP 2106.05(f)). Claim 37, recites the following bolded claim elements as abstract ideas while the non-bolded claim elements recites additional elements according to MPEP 2106.04(a). The claim further recites: [A] delete any archived pass phrase files and archived wallet file data from archived storage upon successful matching of the unique identifying information and wallet file data to the authentication information in the exit request. The claim further recites the abstract idea of managing data. In other words, it recites limitation grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The non-bolded additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP 2106.05(f)). Claim 38, recites the following bolded claim elements as abstract ideas while the non-bolded claim elements recites additional elements according to MPEP 2106.04(a). The claim further recites: [A] generate a notification of a successful match; and [B] generate a prompt for the user controlling the digital wallet for which the exit request was received to download the wallet file data. The claim further recites the abstract idea of authenticating the user. In other words, it recites limitation grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The non-bolded additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP 2106.05(f)). Claim 39, recites the following bolded claim elements as abstract ideas while the non-bolded claim elements recites additional elements according to MPEP 2106.04(a). The claim further recites: [A] wherein the digital wallet is removed from the stored wallet database after generating the prompt for the user to download the wallet file data. The claim further recites the abstract idea of managing data. In other words, it recites limitation grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The non-bolded additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP 2106.05(f)). When the dependent claims are considered as a whole, as an ordered combination, the claim elements noted above appear to merely apply the abstract concept to a technical environment in a very general sense, i.e., a computer receives information from another computer, processes that information and then sends a response based on processing results. The most significant elements of the claims, that is the elements that really outline the inventive elements of the claims, are set forth in the elements identified in the independent claims as an abstract idea. The fact that the computing devices are facilitating the abstract concept is not enough to confer subject matter eligibility. Overall, the further elements do not confer subject matter eligibility to the invention since their individual and combined significance are not changing the nature of the abstract concepts at the core of the claimed invention. Therefore, it is concluded that the dependent claims of the instant application do not amount to significantly more. (See MPEP 2106.05). In sum, Claims 21, 24-27, 30-39 are rejected under 35 USC 101 as being directed to non-statutory subject matter. Claim Rejections - 35 USC § 103 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 (i.e., changing from AIA to pre-AIA ) 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. 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. The text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action. The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows: 1. Determining the scope and contents of the prior art. 2. Ascertaining the differences between the prior art and the claims at issue. 3. Resolving the level of ordinary skill in the pertinent art. 4. Considering objective evidence present in the application indicating obviousness or non-obviousness. Claims 21, 36 are rejected under 35 U.S.C. 103 as being unpatentable over Kim (US 20200005282 A1), in view of Roach (US 20220237595 A1), in further view of Silvestri (US 20210383376 A1). Regarding Claim 21. Kim discloses: receiving an exit request containing a security token; [see at least Fig. 1, (0012) receiving a wallet recovery request from a user S100; and providing wallet access to the user when a recovery condition is met S600.] initiating an authentication queue; [see at least (0063) verifying the user identity S200;] requesting authentication information to confirm a wallet exit request from a user controlling a digital wallet for which the exit request was received; [see at least (0074) S200 is preferably performed using the identity information received with the recovery request (e.g., login credentials)] verifying the authentication information; [see at least (0063) verifying the user identity S200;] retrieving unique identifying information for the user and wallet file data from a local network; [see at least (0074) the user identity can be verified using: the logged-in user account (e.g., the user account requesting wallet recovery must be associated with the wallet), user device verification (e.g., the user enters the correct code into a user device associated with the wallet), identity documentation (e.g., the provided documentation matches the user identity or credentials associated with the wallet), user credential verification (e.g., for the user account, such as login credential verification, authentication credential verification, valid token verification, etc.), multi-factor authentication (e.g., two-factor authentication)] matching the unique identifying information and the wallet file data to the authentication information in the exit request; [see at least (0074) the user identity can be verified using: the logged-in user account (e.g., the user account requesting wallet recovery must be associated with the wallet), user device verification (e.g., the user enters the correct code into a user device associated with the wallet), identity documentation (e.g., the provided documentation matches the user identity or credentials associated with the wallet] sending a wallet blockchain removal request to an activation programming interface (API) request queue; and [see at least Fig. 5, (0038) the wallet is managed by an off-chain wallet system (e.g., a third party system e.g., 220, an owner system 231, a user system 232, a hardware wallet, etc.), and the off-chain wallet system includes an API (Application Programming Interface) that defines and implements methods that perform wallet management operations for wallets managed by the off-chain wallet system] Kim discloses authenticating user, however, Kim does not disclose: decrypting the wallet file data; and appending the decrypted wallet file data to the digital wallet. removing the digital wallet from a stored wallet database in such a manner that the user no longer relies on the blockchain to provide storage for any assets held in the digital wallet, wherein the user thereby controls the digital wallet for which the exit request was received and maintains full ownership of the digital wallet and any assets contained therein. Nonetheless, Roach discloses decrypting data: decrypting the wallet file data; and [see at least (0045) where the digital signature is used to verify the user and transaction. The message may be decrypted with the corresponding public key of the user wallet. Since the private key is unique to the user, successful decryption of the message with the corresponding public key verifies the message was sent by the user.] appending the decrypted wallet file data to the digital wallet. [see at least (0045) where the digital signature is used to verify the user and transaction. The message may be decrypted with the corresponding public key of the user wallet. Since the private key is unique to the user, successful decryption of the message with the corresponding public key verifies the message was sent by the user.] In addition, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify Kim to include the features of Roach. One would have been motivated to do so, in order to securely decrypt data. Kim discloses authenticating user. Roach teaches decrypting data using the public key. Because Kim, as well as Roach are implemented in security environment, and the steps of authenticating of Kim is analogous to the decrypting technique of Roach that performs the decryption of data and could themselves be programmed to carry out that function as taught by Roach. Moreover, since the elements disclosed by Kim, as well as Roach would function in the same manner in combination as they do in their separate embodiments, it would be reasonable to conclude that their resulting combination would be predictable. Accordingly, the claimed subject matter is obvious over Kim/Roach. The combination of Kim, in view of Roach discloses authenticating and decrypting data, however, the above combination of Kim, Roach does not disclose: removing the digital wallet from a stored wallet database in such a manner that the user no longer relies on the blockchain to provide storage for any assets held in the digital wallet, wherein the user thereby controls the digital wallet for which the exit request was received and maintains full ownership of the digital wallet and any assets contained therein. However, Silvestri discloses removing wallet data: removing the digital wallet from a stored wallet database in such a manner that the user no longer relies on the blockchain to provide storage for any assets held in the digital wallet, [see at least (0097) At block 418, the method 410 involves disconnecting from the hot wallet. For instance, a general processing unit may disconnect the wireless connection between the hardware wallet and the hot wallet. Once disconnected, the hardware wallet can be completely offline and store the transaction data in cold storage.] wherein the user thereby controls the digital wallet for which the exit request was received and maintains full ownership of the digital wallet and any assets contained therein. [see at least (0031) the user may disconnect the hardware wallet from the mobile client and cause the hardware wallet to switch back to completely offline and resume storing the modified digital currency data in cold storage.] Note: MPEP 2144.01 sets forth that it is proper to take into account not only specific teachings of the reference but also the inferences which one skilled in the art would reasonably be expected to draw therefrom. Here, it is reasonable to infer that in order for the wallet to continue storing data, the user would require to have ownership of the wallet and the data that is being stored. And therefore, one of skill in the art would have understood the reference to teach the limitation. In addition, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify Kim, Roach to include the features of Silvestri. A person having the ordinary skill in the art would have been motivated to securely store asset by authenticating the user as taught by Kim, Roach and storing the asset in a cold storage as taught by Silvestri. Kim, Roach discloses authenticating user. Silvestri teaches disconnecting hardware wallet (i.e. cold storage). Because Kim, Roach as well as Silvestri are implemented in an environment to securely store and access data, and the references addresses storing data, and the technique for storing assets in a cold storage as taught by Silvestri would have been available to the technique for authenticating user of Kim, Roach. Moreover, since the elements disclosed by Kim, Roach as well as Silvestri would function in the same manner in combination as they do in their separate embodiments, it would be reasonable to conclude that their resulting combination would be predictable. Accordingly, the claimed subject matter is obvious over Kim, Roach/Silvestri. Regarding Claim 36. Kim discloses: at least smart device hosting a native application; [see at least (0030) an owner system (e.g., 231), and a user system (e.g., 232) (either directly or indirectly via one or more other systems) via a network (e.g., a private network, a public network, the Internet, etc.)] at least one processor capable of executing logical functions in operable communication with the native application; [see at least (0030) an owner system (e.g., 231), and a user system (e.g., 232) (either directly or indirectly via one or more other systems) via a network (e.g., a private network, a public network, the Internet, etc.)] at least one non-transitory computer readable storage medium having instructions encoded thereon that, when executed by the at least one processor, implements operations to generate a user-initiated exit request exit request containing a security token, the instructions including: [see at least Fig. 1, (0012) receiving a wallet recovery request from a user S100; and providing wallet access to the user when a recovery condition is met S600. [0030] an owner system (e.g., 231), and a user system (e.g., 232) (either directly or indirectly via one or more other systems) via a network (e.g., a private network, a public network, the Internet, etc.)} initiate an authentication queue; [see at least (0063) verifying the user identity S200;] request authentication information to confirm the wallet exit request from a user controlling a digital wallet for which the exit request was received; [see at least (0074) S200 is preferably performed using the identity information received with the recovery request (e.g., login credentials)] activate a user denial response handler simultaneously with requesting authentication information; [see at least (0019) wallet owners abort the challenge (e.g., through the notification), the method can include: sending an abort request, signed by the recovery account, to the wallet, wherein the wallet can terminate the challenge process and optionally delete the new keys] verify the authentication information; [see at least (0063) verifying the user identity S200;] retrieve unique identifying information for the user and wallet file data from a local network; [see at least (0074) the user identity can be verified using: the logged-in user account (e.g., the user account requesting wallet recovery must be associated with the wallet), user device verification (e.g., the user enters the correct code into a user device associated with the wallet), identity documentation (e.g., the provided documentation matches the user identity or credentials associated with the wallet), user credential verification (e.g., for the user account, such as login credential verification, authentication credential verification, valid token verification, etc.), multi-factor authentication (e.g., two-factor authentication)] match the unique identifying information and the wallet file data to the authentication information in the exit request; [see at least (0074) the user identity can be verified using: the logged-in user account (e.g., the user account requesting wallet recovery must be associated with the wallet), user device verification (e.g., the user enters the correct code into a user device associated with the wallet), identity documentation (e.g., the provided documentation matches the user identity or credentials associated with the wallet] send a wallet blockchain removal request to an activation programming interface (API) request queue; and [see at least Fig. 5, (0038) the wallet is managed by an off-chain wallet system (e.g., a third party system e.g., 220, an owner system 231, a user system 232, a hardware wallet, etc.), and the off-chain wallet system includes an API (Application Programming Interface) that defines and implements methods that perform wallet management operations for wallets managed by the off-chain wallet system] Kim discloses authenticating user, however, Kim does not disclose: decrypt the wallet file data; and append the decrypted wallet file data to the digital wallet. remove the digital wallet from a stored wallet database in such a manner that the user no longer relies on the blockchain to provide storage for any assets held in the digital wallet, wherein the user thereby controls the digital wallet for which the exit request was received and maintains full ownership of the digital wallet and any assets contained therein. Nonetheless, Roach discloses decrypting data: decrypt the wallet file data; and [see at least (0045) where the digital signature is used to verify the user and transaction. The message may be decrypted with the corresponding public key of the user wallet. Since the private key is unique to the user, successful decryption of the message with the corresponding public key verifies the message was sent by the user.] append the decrypted wallet file data to the digital wallet. [see at least (0045) where the digital signature is used to verify the user and transaction. The message may be decrypted with the corresponding public key of the user wallet. Since the private key is unique to the user, successful decryption of the message with the corresponding public key verifies the message was sent by the user.] In addition, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify Kim to include the features of Roach. One would have been motivated to do so, in order to securely decrypt data. Kim discloses authenticating user. Roach teaches decrypting data using the public key. Because Kim, as well as Roach are implemented in security environment, and the steps of authenticating is analogous to the decrypting technique of Roach that performs the decryption of data and could themselves be programmed to carry out that function as taught by Roach. Moreover, the subject matter is merely a combination of old elements, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art before the effective filing date would have recognized that the results of the combination were predictable. The combination of Kim, in view of Roach discloses authenticating and decrypting data, however, the above combination of Kim, Roach does not disclose: remove the digital wallet from a stored wallet database in such a manner that the user no longer relies on the blockchain to provide storage for any assets held in the digital wallet, wherein the user thereby controls the digital wallet for which the exit request was received and maintains full ownership of the digital wallet and any assets contained therein. However, Silvestri discloses removing wallet data: remove the digital wallet from a stored wallet database in such a manner that the user no longer relies on the blockchain to provide storage for any assets held in the digital wallet, [see at least (0097) At block 418, the method 410 involves disconnecting from the hot wallet. For instance, a general processing unit may disconnect the wireless connection between the hardware wallet and the hot wallet. Once disconnected, the hardware wallet can be completely offline and store the transaction data in cold storage.] wherein the user thereby controls the digital wallet for which the exit request was received and maintains full ownership of the digital wallet and any assets contained therein. [see at least (0031) the user may disconnect the hardware wallet from the mobile client and cause the hardware wallet to switch back to completely offline and resume storing the modified digital currency data in cold storage.] Note: MPEP 2144.01 sets forth that it is proper to take into account not only specific teachings of the reference but also the inferences which one skilled in the art would reasonably be expected to draw therefrom. Here, it is reasonable to infer that in order for the wallet to continue storing data, the user would require to have ownership of the wallet and the data that is being stored. And therefore, one of skill in the art would have understood the reference to teach the limitation. In addition, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify Kim, Roach to include the features of Silvestri. A person having the ordinary skill in the art would have been motivated to securely store asset by authenticating the user as taught by Kim, Roach and storing the asset in a cold storage as taught by Silvestri. Kim, Roach discloses authenticating user. Silvestri teaches disconnecting hardware wallet (i.e. cold storage). Because Kim, Roach as well as Silvestri are implemented in an environment to securely store and access data, and the references addresses storing data, and the technique for storing assets in a cold storage as taught by Silvestri would have been available to the technique for authenticating user of Kim, Roach. Moreover, the subject matter is merely a combination of old elements, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art before the effective filing date would have recognized that the results of the combination were predictable. Claims 24-27, 37-39 are rejected under 35 U.S.C. 103 as being unpatentable over Kim, in view of Roach, in view of Silvestri, as applied to claims [21, 36] above, in further view of Mu (US 20250021966 A1). Regarding Claim 24. Kim. Roach, Silvestri discloses the limitations of Claim 21. Kim further discloses: … successful matching of the unique identifying information and wallet file data to the authentication information in the exit request. [see at least (0076) Transmitting a challenge initiation request to the wallet S300 functions to instruct the wallet (e.g., 210, 310) to initiate the challenge process. S300 is preferably performed upon verification of the user's identity as a wallet owner or authorized wallet user] The combination of Kim, in view of Roach, in view of Silvestri discloses authenticating and storing data in cold storage, however, the above combination of Kim, Roach, Silvestri does not disclose: deleting any archived pass phrase files and archived wallet file data from archived storage upon … However, Mu discloses deleting data: deleting any archived pass phrase files and archived wallet file data from archived storage upon … [see at least [0104] the security chip executes these instructions so as to delete an original digital currency wallet application, and download and install a new digital currency wallet application.] Note: MPEP 2144.01 sets forth that it is proper to take into account not only specific teachings of the reference but also the inferences which one skilled in the art would reasonably be expected to draw therefrom. Here, it is reasonable to infer that in order for the user to delete data, the user need to be authenticated. And therefore, one of skill in the art would have understood the reference to teach the limitation. In addition, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify Kim, Roach, Silvestri to include the features of Mu. A person having the ordinary skill in the art would have been motivated to securely manage data by authenticating the user as taught by Kim, Roach and deleting data as taught by Mu. Kim, Roach, Silvestri discloses authenticating user. Mu teaches deleting data. Because Kim, Roach, Silvestri as well as Mu are implemented in an environment to securely access and manage data, and the references addresses managing, and the technique deleting data as taught by Mu would have been available to the technique for authenticating user of Kim, Roach, Silvestri. Moreover, since the elements disclosed by Kim, Roach, Silvestri as well as Mu would function in the same manner in combination as they do in their separate embodiments, it would be reasonable to conclude that their resulting combination would be predictable. Accordingly, the claimed subject matter is obvious over Kim, Roach, Silvestri/ Mu. Regarding Claim 25. Kim. Roach, Silvestri, Mu discloses the limitations of Claim 24. Kim further discloses: generating a notification of a successful match; and [see at least (0019) wallet owners abort the challenge (e.g., through the notification), the method can include: sending an abort request, signed by the recovery account, to the wallet, wherein the wallet can terminate the challenge process and optionally delete the new keys] Mu further discloses deleting data: generating a prompt for the user controlling the digital wallet for which the exit request was received to download the wallet file data. [see at least [0104] The trusted platform may issue these instructions in batch, such that the security chip executes these instructions so as to delete an original digital currency wallet application, and download and install a new digital currency wallet application] In addition, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify Kim, Roach, Silvestri to include the features of Mu. A person having the ordinary skill in the art would have been motivated to securely manage data by authenticating the user as taught by Kim, Roach and deleting data as taught by Mu. Kim, Roach, Silvestri discloses authenticating user. Mu teaches deleting data. Because Kim, Roach, Silvestri as well as Mu are implemented in an environment to securely access and manage data, and the references addresses managing, and the technique deleting data as taught by Mu would have been available to the technique for authenticating user of Kim, Roach, Silvestri. Moreover, since the subject matter is merely a combination of old elements, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art before the effective filing date would have recognized that the results of the combination were predictable. Regarding Claim 26. Kim. Roach, Silvestri, Mu discloses the limitations of Claim 25. Silvestri further discloses: wherein the digital wallet is removed from the stored wallet database after generating the prompt for the user to download the wallet file data. [see at least (0097) At block 418, the method 410 involves disconnecting from the hot wallet. For instance, a general processing unit may disconnect the wireless connection between the hardware wallet and the hot wallet. Once disconnected, the hardware wallet can be completely offline and store the transaction data in cold storage.] In addition, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify Kim, Roach, Silvestri, Mu to include the additional features of Silvestri. A person having the ordinary skill in the art would have been motivated to securely store asset by authenticating the user as taught by Kim, Roach, Silvestri, Mu and storing the asset in a cold storage as taught by Silvestri. Kim, Roach, Silvestri, Mu discloses authenticating user. Silvestri teaches disconnecting hardware wallet (i.e. cold storage). Because Kim, Roach, Silvestri, Mu as well as Silvestri are implemented in an environment to securely store and access data, and the references addresses storing data, and the technique for storing assets in a cold storage as taught by Silvestri would have been available to the technique for authenticating user of Kim, Roach, Silvestri, Mu. Moreover, the subject matter is merely a combination of old elements, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art before the effective filing date would have recognized that the results of the combination were predictable. Regarding Claim 27. Kim. Roach, Silvestri, Mu discloses the limitations of Claim 25. Silvestri further discloses: wherein the user controlling the digital wallet for which the exit request was received maintains full ownership of the digital wallet and any assets contained therein upon successful download of the wallet file data. [see at least (0031) the user may disconnect the hardware wallet from the mobile client and cause the hardware wallet to switch back to completely offline and resume storing the modified digital currency data in cold storage.] Note: MPEP 2144.01 sets forth that it is proper to take into account not only specific teachings of the reference but also the inferences which one skilled in the art would reasonably be expected to draw therefrom. Here, it is reasonable to infer that in order for the wallet to continue storing data, the user would require to have ownership of the wallet and the data that is being stored. And therefore, one of skill in the art would have understood the reference to teach the limitation. In addition, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify Kim, Roach to include the features of Silvestri. A person having the ordinary skill in the art would have been motivated to securely store asset by authenticating the user as taught by Kim, Roach and storing the asset in a cold storage as taught by Silvestri. Kim, Roach discloses authenticating user. Silvestri teaches disconnecting hardware wallet (i.e. cold storage). Because Kim, Roach as well as Silvestri are implemented in an environment to securely store and access data, and the references addresses storing data, and the technique for storing assets in a cold storage as taught by Silvestri would have been available to the technique for authenticating user of Kim, Roach. Moreover, the subject matter is merely a combination of old elements, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art before the effective filing date would have recognized that the results of the combination were predictable. Regarding Claim 37. Kim. Roach, Silvestri discloses the limitations of Claim 36. Kim further disclose: … successful matching of the unique identifying information and wallet file data to the authentication information in the exit request. [see at least (0076) Transmitting a challenge initiation request to the wallet S300 functions to instruct the wallet (e.g., 210, 310) to initiate the challenge process. S300 is preferably performed upon verification of the user's identity as a wallet owner or authorized wallet user] The combination of Kim, in view of Roach, in view of Silvestri discloses authenticating and storing data in cold storage, however, the above combination of Kim, Roach, Silvestri does not disclose: delete any archived pass phrase files and archived wallet file data from archived storage upon … However, Mu discloses deleting data: delete any archived pass phrase files and archived wallet file data from archived storage upon … [see at least [0104] the security chip executes these instructions so as to delete an original digital currency wallet application, and download and install a new digital currency wallet application.] Note: MPEP 2144.01 sets forth that it is proper to take into account not only specific teachings of the reference but also the inferences which one skilled in the art would reasonably be expected to draw therefrom. Here, it is reasonable to infer that in order for the user to delete data, the user need to be authenticated. And therefore, one of skill in the art would have understood the reference to teach the limitation. In addition, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify Kim, Roach, Silvestri to include the features of Mu. A person having the ordinary skill in the art would have been motivated to securely manage data by authenticating the user as taught by Kim, Roach and deleting data as taught by Mu. Kim, Roach, Silvestri discloses authenticating user. Mu teaches deleting data. Because Kim, Roach, Silvestri as well as Mu are implemented in an environment to securely access and manage data, and the references addresses managing, and the technique deleting data as taught by Mu would have been available to the technique for authenticating user of Kim, Roach, Silvestri. Moreover, the subject matter is merely a combination of old elements, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art before the effective filing date would have recognized that the results of the combination were predictable. Regarding Claim 38. Kim. Roach, Silvestri, Mu discloses the limitations of Claim 37. Kim further discloses: generate a notification of a successful match; and [see at least (0019) wallet owners abort the challenge (e.g., through the notification), the method can include: sending an abort request, signed by the recovery account, to the wallet, wherein the wallet can terminate the challenge process and optionally delete the new keys] Mu further discloses deleting data: generate a prompt for the user controlling the digital wallet for which the exit request was received to download the wallet file data. [see at least [0104] The trusted platform may issue these instructions in batch, such that the security chip executes these instructions so as to delete an original digital currency wallet application, and download and install a new digital currency wallet application] In addition, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify Kim, Roach, Silvestri to include the features of Mu. A person having the ordinary skill in the art would have been motivated to securely manage data by authenticating the user as taught by Kim, Roach and deleting data as taught by Mu. Kim, Roach, Silvestri discloses authenticating user. Mu teaches deleting data. Because Kim, Roach, Silvestri as well as Mu are implemented in an environment to securely access and manage data, and the references addresses managing, and the technique deleting data as taught by Mu would have been available to the technique for authenticating user of Kim, Roach, Silvestri. Moreover, since the subject matter is merely a combination of old elements, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art before the effective filing date would have recognized that the results of the combination were predictable. Regarding Claim 39. Kim. Roach, Silvestri, Mu discloses the limitations of Claim 38. Silvestri further discloses: wherein the digital wallet is to be removed from the stored wallet database after the prompt for the user to download the wallet file data is generated. [see at least (0097) At block 418, the method 410 involves disconnecting from the hot wallet. For instance, a general processing unit may disconnect the wireless connection between the hardware wallet and the hot wallet. Once disconnected, the hardware wallet can be completely offline and store the transaction data in cold storage.] In addition, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify Kim, Roach, Silvestri, Mu to include the additional features of Silvestri. A person having the ordinary skill in the art would have been motivated to securely store asset by authenticating the user as taught by Kim, Roach, Silvestri, Mu and storing the asset in a cold storage as taught by Silvestri. Kim, Roach, Silvestri, Mu discloses authenticating user. Silvestri teaches disconnecting hardware wallet (i.e. cold storage). Because Kim, Roach, Silvestri, Mu as well as Silvestri are implemented in an environment to securely store and access data, and the references addresses storing data, and the technique for storing assets in a cold storage as taught by Silvestri would have been available to the technique for authenticating user of Kim, Roach, Silvestri, Mu. Moreover, the subject matter is merely a combination of old elements, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art before the effective filing date would have recognized that the results of the combination were predictable. Claims 30-31, 34-35 are rejected under 35 U.S.C. 103 as being unpatentable over Kim, in view of Roach, in view of Silvestri, as applied to claim 21 above, in further view of Winklevoss (US 10650376 B1). Regarding Claim 30. Kim, Roach, Silvestri discloses the limitations of Claim 21. Roach further discloses: wherein decrypting the wallet file data … [see at least (0080) the cryptocurrency client application 102 prompts the user to enter the secret password for decrypting the encrypted key store.] In addition, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify Kim, Roach, Silvestri to include the additional features of Roach. One would have been motivated to do so, in order to securely decrypt data. Kim, Roach, Silvestri discloses authenticating user. Roach teaches decrypting data using the public key. Because Kim, Roach, Silvestri, as well as Roach are implemented in security environment, and the steps of authenticating of Kim, Roach, Silvestri is analogous to the decrypting technique of Roach that performs the decryption of data and could themselves be programmed to carry out that function as taught by Roach. Moreover, the subject matter is merely a combination of old elements, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art before the effective filing date would have recognized that the results of the combination were predictable. In addition, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify Kim to include the features of Roach. The combination of Kim, in view of Roach, in view of Silvestri discloses authenticating and storing data in cold storage, however, the above combination of Kim, Roach, Silvestri does not disclose: … decrypting a first part of the wallet file data with a first cipher; and decrypting a second part of the wallet file data with a second cipher. However, Winklevoss discloses decrypting in segments: … decrypting a first part of the wallet file data with a first cipher; and [see at least (27/30-31) the private key may be divided into 2, 3, 4 or more segments. (41/6-11) the system may decrypt, reassemble, and/or decipher private keys and/or key segments before returning the keys and/or key segments to a user. In embodiments, a user may be provided with the option of having the system perform the decrypting, reassembling, and/or deciphering steps.] decrypting a second part of the wallet file data with a second cipher. [see at least (27/30-31) the private key may be divided into 2, 3, 4 or more segments. (41/59-65) decryption, reassembly, and or deciphering of private keys and/or key segments may occur before or after returning the keys and/or key segments to a user and may be performed by the system or by a user, who may use software provided by the system.] In addition, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify features of Kim, Roach, Silvestri to include features of Winklevoss. A person having the ordinary skill in the art would have been motivated to securely manage asset by authenticating the user as taught by Kim, Roach and decrypting data in segments as taught by Winklevoss. Kim, Roach, Silvestri discloses authenticating and decrypting data. Winklevoss teaches decrypting data using cipher. Because Kim, Roach, Silvestri as well as Winklevoss are implemented in an environment to securely access data, and the references addresses decrypting data, and the technique for decrypting data in segments as taught by Winklevoss would have been available to the technique for authenticating user of Kim, Roach, Silvestri. Moreover, since the elements disclosed by Kim, Roach, Silvestri as well as Winklevoss would function in the same manner in combination as they do in their separate embodiments, it would be reasonable to conclude that their resulting combination would be predictable. Accordingly, the claimed subject matter is obvious over Kim, Roach, Silvestri/Winklevoss. Regarding Claim 31. Kim, Roach, Silvestri, Winklevoss discloses the limitations of Claim 30. Winklevoss further discloses: decrypting a third part of the wallet file data with the second cipher. [see at least Fig. 12C, (27/30-31) the private key may be divided into 2, 3, 4 or more segments. (41/59-65) In embodiments, decryption, reassembly, and or deciphering of private keys and/or key segments may occur before or after returning the keys and/or key segments to a user and may be performed by the system or by a user, who may use software provided by the system.] In addition, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify features of Kim, Roach, Silvestri, Winklevoss to include the additional features of Winklevoss. A person having the ordinary skill in the art would have been motivated to securely manage asset by authenticating the user as taught by Kim, Roach, Winklevoss and decrypting data in segments as taught by Winklevoss. Kim, Roach, Silvestri, Winklevoss discloses authenticating and decrypting data. Winklevoss teaches decrypting data using cipher. Because Kim, Roach, Silvestri, Winklevoss as well as Winklevoss are implemented in an environment to securely access data, and the references addresses decrypting data, and the technique for decrypting data in segments as taught by Winklevoss would have been available to the technique for authenticating user of Kim, Roach, Silvestri, Winklevoss. Moreover, since the subject matter is merely a combination of old elements, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art before the effective filing date would have recognized that the results of the combination were predictable. Regarding Claim 32. Kim, Roach, Silvestri, Winklevoss discloses the limitations of Claim 31. Silvestri further discloses: requesting the third part of the wallet file data to be uploaded from a device owned by the user controlling the digital wallet for which the exit request was received. [see at least Fig. 1, (0030) a hardware wallet described herein may incorporate security features that can boost digital currency data and general data protection, including during cold storage. (0031) After the one or more transactions are initiated (or completed), the user may disconnect the hardware wallet from the mobile client and cause the hardware wallet to switch back to completely offline and resume storing the modified digital currency data in cold storage.] In addition, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify Kim, Roach, Silvestri, Winklevoss to include the additional features of Silvestri. A person having the ordinary skill in the art would have been motivated to securely store asset by authenticating the user as taught by Kim, Roach, Silvestri, Winklevoss and storing the asset in a cold storage as taught by Silvestri. Kim, Roach discloses authenticating user. Silvestri teaches disconnecting hardware wallet (i.e. cold storage). Because Kim, Roach, Silvestri, Winklevoss as well as Silvestri are implemented in an environment to securely store and access data, and the references addresses storing data, and the technique for storing assets in a cold storage as taught by Silvestri would have been available to the technique for authenticating user of Kim, Roach, Silvestri, Winklevoss. Moreover, the subject matter is merely a combination of old elements, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art before the effective filing date would have recognized that the results of the combination were predictable. Regarding Claim 33. Kim, Roach, Silvestri, Winklevoss, discloses the limitations of Claim 32. Silvestri further discloses: wherein the third part of the wallet file data is uploaded automatically upon initiation of the exit request by the user.[see at least Fig. 1, (0030) a hardware wallet described herein may incorporate security features that can boost digital currency data and general data protection, including during cold storage. (0031) After the one or more transactions are initiated (or completed), the user may disconnect the hardware wallet from the mobile client and cause the hardware wallet to switch back to completely offline and resume storing the modified digital currency data in cold storage.] Note: The above combination of Kim, Roach, Silvestri, Winklevoss does not explicitly disclose wherein the third part of the wallet file data is uploaded automatically. However this limitation represents non-functional descriptive material and does not affect how the claimed method functions (i.e., the descriptive material does not have any claim function in the claimed method; see MPEP 2106.01). A “wherein” clause does not function to actively limit the claim language. Therefore, the claim element is considered, but given no patentable weight. (MPEP 2111.05). The reference is provided for the purpose of compact prosecution. Regarding Claim 34. Kim, Roach, Silvestri, Winklevoss discloses the limitations of Claim 31. Winklevoss further discloses: wherein the first cipher further comprises an activation programming interface (API) cipher that was used to encrypt the first part of the wallet file data and the third part of the wallet file data upon original creation of the wallet file data. [see at least (6/1-6), (25/1-6), (69/11-14) The exchange data may be received via electronic transmission (e.g., over the Internet) and/or electronically accessed (e.g., using one or more APIs)] In addition, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify features of Kim, Roach, Silvestri, Winklevoss to include the additional features of Winklevoss. A person having the ordinary skill in the art would have been motivated to securely manage asset by authenticating the user as taught by Kim, Roach, Winklevoss and decrypting data in segments as taught by Winklevoss. Kim, Roach, Silvestri, Winklevoss discloses authenticating and decrypting data. Winklevoss teaches decrypting data using cipher. Because Kim, Roach, Silvestri, Winklevoss as well as Winklevoss are implemented in an environment to securely access data, and the references addresses decrypting data, and the technique for decrypting data in segments as taught by Winklevoss would have been available to the technique for authenticating user of Kim, Roach, Silvestri, Winklevoss. Moreover, since the subject matter is merely a combination of old elements, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art before the effective filing date would have recognized that the results of the combination were predictable. Regarding Claim 35. Kim, Roach, Silvestri, Winklevoss discloses the limitations of Claim 31. Winklevoss further discloses: wherein the second cipher further comprises a server cipher that was used to encrypt the second part of the wallet file data upon the original creation of the wallet file data. [see at least (24/60-25/22) Keys or key segments may be encrypted and/or ciphered, using one or more ciphers, as an additional security measure. The encryption and/or ciphers may be applied by computers running encryption software, separate encryption devices] In addition, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify features of Kim, Roach, Silvestri, Winklevoss to include the additional features of Winklevoss. A person having the ordinary skill in the art would have been motivated to securely manage asset by authenticating the user as taught by Kim, Roach, Winklevoss and decrypting data in segments as taught by Winklevoss. Kim, Roach, Silvestri, Winklevoss discloses authenticating and decrypting data. Winklevoss teaches decrypting data using cipher. Because Kim, Roach, Silvestri, Winklevoss as well as Winklevoss are implemented in an environment to securely access data, and the references addresses decrypting data, and the technique for decrypting data in segments as taught by Winklevoss would have been available to the technique for authenticating user of Kim, Roach, Silvestri, Winklevoss. Moreover, since the subject matter is merely a combination of old elements, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art before the effective filing date would have recognized that the results of the combination were predictable. Relevant Prior Art Not Relied Upon The prior art made of record and not relied upon which, however, is considered pertinent to applicant's disclosure: US 20230230069 A1 VOORHEES; Jacques et al. DIAMOND CUSTODY SYSTEM WITH BLOCKCHAIN NON-FUNGIBLE TOKENS (NFTS) - A non-fungible blockchain token (NFT) transferable from wallet to wallet on a blockchain represents ownership of a physical diamond custodied in a secure vault. The NFT can be sold and resold to investors wishing to use the diamond as a store of value. The NFT owner, who may only be known by a blockchain wallet address, can communicate with the custodian, the issuer, auditors, and more by writing signal messages into the blockchain NFT. A diamond custody controller unit at the custodian includes a trusted program module to handle private cryptographic key functions and to output retrieval and shipping instructions when a signal message indicates the NFT owner instructs the custodian to move the diamond to a new custodian. The NFT owner can also write signal messages into the NFT to instruct other parties, such as auditors, to perform services relating to the diamond. US 20220122050 A1 Pacella; Dante J. et al. Systems and Methods for Digital Asset Management - An exemplary method includes a digital asset management system sending a non-fungible digital asset from a first computer system to a second computer system. The first computer system and the second computer system may be included in a plurality of computer systems configured to form a distributed record configured to track ownership of non-fungible digital assets. The digital asset management system may further record, in the distributed record, information indicative of the sending of the non-fungible digital asset to the second computer system. A user account associated with the first computer system may retain partial ownership in the non-fungible digital asset after the sending of the non-fungible digital asset to the second computer system. US 20230162174 A1 Brasse; Antonio et al. SYSTEM AND METHOD OF AUTOMATED KNOW-YOUR-TRANSACTION CHECKING IN DIGITAL ASSET TRANSACTIONS - An automated method of checking for legitimacy during a digital asset transaction, including by a customer, initiating a digital asset transaction, receiving a wallet address corresponding to a wallet, checking the wallet address against one or more databases, wherein said one or more databases comprise wallet transaction history and risk category information, determining if the wallet address should be flagged as a suspicious transaction based on the transaction history and risk category information stored in the one or more databases, if the wallet address is flagged as suspicious, rejecting the transaction and notifying the customer of the rejection. or moving the digital assets to a holding wallet for further checks, and if the wallet address is not flagged as suspicious, releasing the digital assets and proceeding with the transaction. US 20230360034 A1 DeLuca; Lisa Seacat et al. PROFILE BADGES AND ACCESS CONTROL BASED ON DIGITAL WALLET BLOCKCHAIN ACTIVITY - According to a present invention embodiment, a system for monitoring blockchain activity comprises one or more memories and at least one processor coupled to the one or more memories. A wallet is determined to be associated with a user has engaged in a transaction on a blockchain. A badge of a plurality of badges is identified based on the transaction. A profile of the user is updated to include the badge to indicate a user status for activity on the blockchain. Embodiments of the present invention further include a method and computer program product for monitoring blockchain activity in substantially the same manner described above. US 20190043040 A1 MALMBORG; Anders et al. METHOD FOR PREVENTING THE MISUSE OF ELECTRONIC ACCESS PERMISSIONS, WHICH CAN BE MANAGED IN MOBILE ELECTRONIC DEVICES USING A WALLET APPLICATION AND WHICH ARE TRANSMITTED TO THE MOBILE ELECTRONIC DEVICES BY A SERVER, IN EACH CASE USING A LINK FOR DOWNLOADING THE ACCESS PERMISSION - A method for preventing misuse of electronic access permissions, managed in mobile electronic devices using a wallet application and transmitted by a server. A link is purchased from the server (2), during which a password or authentication data and a mobile electronic device, are specified via the link. When activating the link, a unique ID of the first mobile electronic device (3), which is associated with an ID of the purchased access permission, is transmitted to the server (2). The electronic access permission is only transferable from the first mobile electronic device (3) to another mobile electronic device (4) after the password is first entered with the server (2). Upon successful transfer, in the server (2) the access permission ID is now associated with the ID of the other mobile electronic device (4) and the access permission stored on the first mobile electronic device (3) is marked as invalid. US 20220351195 A1 QUIGLEY; William Edward et al. CRAFTING OF NON-FUNGIBLE TOKENS USING PRE-MINTED TOKENS - According to some embodiments, a method for awarding pre-minted NFTs using a crafting recipe is disclosed. The method includes receiving a crafting request that indicates a set of owned NFTs that are owned by a user, wherein each owned NFTs indicates a type of the owned NFT. The method includes determining a crafting recipe that is implicated by the set of owned NFTs indicated in the crafting request and determining a specified type of NFT based on the crafting recipe. When the specified type of NFT is a pre-minted NFT, the method includes randomly selecting a crafted NFT from a set of pre-minted NFTs of the specified type. When the specified type of NFT were not pre-minted, the method includes minting the crafted NFT. The method further includes assigning the crafted NFT to a user account of the user on the distributed ledger. US 10387928 B1 Hecht; Al Systems and methods for transferring a gift using an information storage and communication system - Systems and methods for using an information wallet system to deliver a gift and receive, redeem, or re-gift the gift are disclosed. The information wallet system's storage is securely maintained by a financial institution computing system (i.e. a bank) and receives and holds purchase transaction information. Purchase information transaction may be received from a user computing device or an entity computing system, such as a merchant computing system. In one embodiment, a user may purchase a gift through an online website or at a brick and mortar location and direct the gift to be deposited into the information wallet storage of a recipient. A recipient may then continue to hold the gift, redeem the gift, or re-gift the gift to another party. Response to Amendments/Arguments With respect to Applicant’s Remarks as to the claims being rejected under 35 USC § 101. Applicant submits: “MPEP §2106.05(a) sets forth, "In determining patent eligibility, examiners should consider whether the claim "purport(s) to improve the functioning of the computer itself" or "any other technology or technical field." Alice Corp. Pty. Ltd. v. CLS Bank Int'l, 573 U.S. 208, 225, 110 USPQ2d 1976, 1984 (2014)." In line with the ruling provided in Alice v. CLS, claim 21, as amended, now recites, in part, the step of "removing the digital wallet from a stored wallet database in such a manner that the user no longer relies on the blockchain to provide storage for any assets held in the digital wallet, wherein the user thereby controls the digital wallet for which the exit request was received and maintains full ownership of the digital wallet and any assets contained therein." (Emphasis added.) Similarly, claim 36, as amended, now recites, in part, an instruction to "remove the digital wallet from a stored wallet database in such a manner that the user no longer relies on the blockchain to provide storage for any assets held in the digital wallet, wherein the user thereby controls the digital wallet for which the exit request was received and maintains full ownership of the digital wallet and any assets contained therein." (Emphasis added.) Applicant submits that the removal of "the digital wallet from a stored wallet database in such a manner that the user no longer relies on the blockchain to provide storage for any assets held in the digital wallet, wherein the user thereby controls the digital wallet for which the exit request was received and maintains full ownership of the digital wallet and any assets contained therein," as recited in each of amended claims 21 and 36, improves the functionality of the underlying computer process associated therewith by now making it possible to remove a user's digital wallet from the stored wallet database and doing so in manner in which "the user thereby controls the digital wallet for which the exit request was received and maintains full ownership of the digital wallet and any assets contained therein." Particularly, the ability to remove a user's digital wallet from the stored wallet database is NOT simply an act or an instruction to apply the judicial exception to the computer or that is a general link to a technological environment (see MPEP 2106.05(f); MPEP 2106.05(h)). Instead, the ability to remove a user's digital wallet from the stored wallet database is a step or operation that is peculiar to the operation of the computer itself. That is, such a step can only exist within the context of the operation of the computer and, thus, must be considered to improve the functioning of the computer itself, which is in concordance with Alice v. CLS. In further support of amended claims 21 and 36, Applicant's specification sets forth that, "If a user wishes to exit a blockchain service, current practice is to require a new, separate wallet to be created, and the contents of the digital wallet must be transferred... [In] current systems, the user does not own their wallet, but instead relies on the blockchain interface to provide the secure storage of their assets. Often in these scenarios, the creation of a new wallet and the transfer of the assets thereto incur additional fees." (Parag. [0103] of the published application (i.e., US 2024/0106651 A1)) Applicant's specification further provides that, "Should a buyer or seller wish to exit the application and remove themselves from the marketplace, the processes herein provide that they may do so while retaining ownership of their entire wallet and its contents. Current systems do not allow for this, instead requiring the user exiting to create a new wallet elsewhere before enacting a transfer of the contents of their current wallet to the new wallet." (Parag. [0117] of the published application) That is, the ability of the user to make an exit request in such a manner as to remove the digital wallet from a stored wallet database and being able to do so in a manner in which the user maintains full ownership of the digital wallet and any assets contained therein, in the manner of amended claims 21 and 36, provides distinct benefits to the user. For one, the user does not need to create an additional digital wallet to which assets may be transferred. For another, the user does not have to incur possible additional fees to perform such a transaction when performed in the manner of amended claims 21 and/or 36. As such, amended claims 21 and 36 do improve the digital wallet technology by providing a particular solution to at least some of the problems previously associated with a digital wallet exit request (e.g., a need to create another digital wallet and/or a need to incur additional fees as part of that exit transaction). McRO, 837 F.3d at 1314-15, 120 USPQ2d at 1102-03; DDR Holdings, 773 F.3d at 1259, 113 USPQ2d at 1107.” Examiner response: Examiner has fully considered, but doesn’t find Applicant’s argument persuasive. Examiner respectfully disagree with the applicant. Under MPEP 2106.4(d)(1), the “improvements” analysis in Step 2A determines whether the claim pertains to an improvement to the functioning of a computer or to another technology without reference to what is well-understood, routine, conventional activity. The claim language of claim 21 and 36do not point technological improvement such as modifying cryptographic technique or modifying blockchain protocols. The claim language of 21 and 36 merely changes the storage (i.e. hot wallet to a cold wallet). Furthermore, the specification describes the result of “user no longer relies on the blockchain” but not describe technological improvement. Thus the rejection is proper and has been maintained. Applicant submits: “The mere recitation of a judicial exception does not mean that the claim is "directed to" that judicial exception under Step 2A Prong Two. Instead, under Prong Two, a claim that recites a judicial exception is not directed to that judicial exception, if the claim as a whole "integrates the recited judicial exception into a practical application of that exception." USPTO 2019 Revised Patent Subject Matter Eligibility Guidance. Claim 21, as amended, recites, in part ,"receiving an user-initiated exit request" and, ultimately, "removing the digital wallet from a stored wallet database" based on that exit request; and claim 36, as amended, recites, in part, "at least one non-transitory computer readable storage medium having instructions encoded thereon that, when executed by the at least one processor, implements operations to generate an user- initiated exit request" and, ultimately, with instructions to "remove the digital wallet from a stored wallet database..." (Emphasis added.) The subject matter of amended claims 21 and 36 is clearly a practical application of a judicial exception. For one, the process of amended claim 21 or the instructions associated with the at least one non-transitory computer readable storage medium of amended claim 36 CANNOT be enacted without an express human decision (e.g., the "user-initiated exit request") to implement the process/instructions to begin with. As such, that is, the process/instructions of claims 21 or 36 are inherently practical in that neither is fully definable as a judicial exception (as purely an abstract idea). Plus, taking a step back, both claims 21 and 36 are predicated on the conscious, human decision to make the exit request (e.g., not merely an "extra-solution activity"), leading to the removal of a "digital wallet from a stored wallet database," in a manner where the user making the exit request "maintains full ownership" of that digital wallet. Thus, amended claim 21 and 36, when analyzed under Prong Two, recite a judicial exception that is not directed to that judicial exception, and, thus each claim as a whole "integrates the recited judicial exception into a practical application of that exception."” Examiner response: Examiner has fully considered, but doesn’t find Applicant’s argument persuasive. Examiner respectfully disagree with the applicant, the MPEP 2106.04(d) discloses that “an important consideration to evaluate when determining whether the claim as a whole integrates a judicial exception into a practical application is whether the claimed invention improves the functioning of a computer or other technology In short, first the specification should be evaluated to determine if the disclosure provides sufficient details such that one of ordinary skill in the art would recognize the claimed invention as providing an improvement. The specification need not explicitly set forth the improvement, but it must describe the invention such that the improvement would be apparent to one of ordinary skill in the art Second, if the specification sets forth an improvement in technology. the claim must be evaluated to ensure that the claim itself reflects the disclosed improvement.” (Emphasis added) “That is, the claimed invention may integrate the judicial exception into a practical application by demonstrating that it improves the relevant existing technology although it may not be an improvement over well-understood, routine, conventional activity.” (Emphasis added). Thus, the rejection is proper and has been maintained. Applicant submits: “Accordingly, Applicant submits that amended independent claims 21 and 36; claims 24-27 and 30-35, depending from claim 21; and claims 37-39, depending from claim 36, do now, indeed, comply with 35 U.S.C. § 101 and, accordingly, request the withdrawal of that rejection and the allowance of claims 21, 24-27, and 30-39 under this statute. Further, the rejection of claims 22, 23, 28, 29, and 40 under 35 U.S.C. § 101 has been rendered moot by the cancellation of those claims.” Examiner response: Examiner has fully considered, but doesn’t find Applicant’s argument persuasive. Examiner respectfully disagree with the applicant, the independent claims 21, 36, and its dependent claims 24-27, 30-35, 37-39 does not comply with 35 U.S.C. § 101. See response above. Thus, the rejection is proper and has been maintained. With respect to Applicant’s Remarks as to the claims being rejected under 35 USC § 103. Applicant submits: “Since claim 21 has been amended to include the subject matter of previous claim 26 and a portion of claim 27; and since claim 36 has been amended to include the subject matter of claim 39, the rejection of amended claims 21 and 36 are discussed hereinbelow over Kim et al., Roach et al., Mu et al., and Hecht et al. Regarding claim 26, the Office Action (pp. 24-25) admits that "Kim, Roach does not disclose" but contends that "Mu discloses: removing the digital wallet from a stored wallet database. {see at least [0104]...}" Similarly, the Office Action (pp. 26-27) admits, with respect to claim 39, that admits that "Kim, Roach does not disclose" but contends that "Mu discloses: remove the digital wallet from a stored wallet database. {see at least [0104]...}" Regarding claim 27, the Office Action (pp. 27-28) admits that "Kim, Roach, Mu does not disclose" but instead contends that "Hecht discloses: wherein the user controlling the digital wallet for which the exit request was received maintains full ownership of the digital wallet and any assets contained therein... {see at least (34)/14:13-18 the information wallet application 140 may comprise computer software with executable code and may be downloaded and installed on a user computing device 120. The information wallet application 140 may be configured to run on any operating system... (reads on: the owner having full access on the downloaded information)}" First, the Office Action particularly cites Parag. [0104] of Mu et al. in support of its rejection of claims 26 and 39. Upon closer inspection, Parag. [0104] of Mu et al. recites, in part, "The trusted platform may issue these instructions in batch, such that the security chip executes these instructions so as to delete an original digital currency wallet application, and download and install a new digital currency wallet application." Parag. [0107] of Mu et al. further recites, in part, "Through the wallet opening instruction, and the account data such as the certificate, the nickname, and the historical transaction record, the opening of a new version of digital currency wallet is achieved, and the newly opened digital currency wallet is in an available status." Additionally, Parag. [0002] of Mu et al. indicates that its "disclosure relates to... a method, terminal, and system for updating a digital currency wallet." That is, Mu et al. is expressly geared simply to updating a digital currency wallet. There is nothing in Mu et al. that suggests a set of instructions or steps that would facilitate the storage of that digital wallet in a completely different wallet database, let alone relinquishing that digital wallet from the current wallet database. Put in another way, Mu et al. fails to disclose a process by which the database owner has surrendered control over the digital wallet being updated (e.g., doing so in "a manner that the user no longer relies on the blockchain to provide storage for any assets held in the digital wallet," as set forth in amended claims 21 and 36). Mu et al. clearly is not directed to fully exiting a blockchain in a manner that removes "the digital wallet from a stored wallet database in such a manner that the user no longer relies on the blockchain to provide storage for any assets held in the digital wallet, wherein the user thereby controls the digital wallet for which the exit request was received and maintains full ownership of the digital wallet and any assets contained therein," as recited in amended claims 21 and 36. Thus, Mu et al., like Kim et al. and Roach et al., fails to disclose or render obvious the removal of "the digital wallet from a stored wallet database," as recited in amended claims 21 and 36. With respect to the aspect that "the user thereby controls the digital wallet for which the exit request was received and maintains full ownership of the digital wallet and any assets contained therein," as recited in amended claims 21 and 36, that element was previously set forth in claim 27. The Office Action (pp. 27-28), in addressing claim 27, admits that "Kim, Roach, Mu does not disclose" that subject matter, instead arguing that "Hect discloses: wherein the user controlling the digital wallet for which the exit request was received maintains full ownership of the digital wallet and any assets contained therein upon successful download of the wallet file data. {see at least (34)/14:13-18 the information wallet application 140... may be downloaded and installed on a user computing device 120. The information wallet application 140 may be configured to run on any operating system and may allow secure access to the information wallet computing system 115. (reads on: the owner having full access on the downloaded information)}" However, with Hecht, the point remains that the "information wallet application 140"clearly relies on the ability to "secure access to the information wallet computing system 115." That is, Hecht, like Mu et al., does not disclose or suggest the surrender of the "information wallet application 140" from the initial "stored wallet database" thereof (i.e., "the information wallet computing system 115"). By no means is the "information wallet application 140" REMOVED from the "information wallet computinq system 115" of Hecht, with the user still relying on the blockchain (e.g., via the "information wallet computing system 115") of Hecht to provide storage for the assets of that digital wallet. So, in fact, the user of the digital wallet in Hecht does not maintain "full ownership of the digital wallet and any assets contained therein," as recited in amended claims 21 and 36, since the user in Hecht is still ultimately reliant on his/her ability to access the "information wallet computing system 115" thereof to get at the wallet contents. The situation in Hecht may be considered to be akin to retrievinq valuables from a safety deposit box, where the bank owns the actual box and thus has ownership over the ability of a user to access those contents. Accordingly, Hecht, like Kim, Roach et al., and Mu et al., fails to disclose or otherwise render obvious exiting a blockchain in a manner that removes "the digital wallet from a stored wallet database in such a manner that the user no longer relies on the blockchain to provide storage for any assets held in the digital wallet, wherein the user thereby controls the digital wallet for which the exit request was received and maintains full ownership of the digital wallet and any assets contained therein," as recited in amended claims 21 and 36, and is thus unable to overcome the shortcomings associated with the other cited references. Thus, Kim, Roach et al., Mu et al., and Hecht, whether taken alone or in combination, fail to disclose and/or render obvious each and every element of claims 21 and/or 36, as amended.” Examiner response: Examiner has fully considered, but doesn’t find Applicant’s argument persuasive. Examiner respectfully disagree with the applicant, the applicant’s arguments are directed towards the amended claim language and not original set of claims. Additionally, the newly cited reference Silvestri, teaches asset being stored in cold storage (i.e. a wallet that is disconnected from the blockchain) and the user can continue to store asset to the cold storage, see Silvestri [0031]. The combination of Kim, Roach, and Silvestri discloses the claim language of claims 21 and 36. Furthermore, see the updated rejection above. Thus, the rejection is proper and has been maintained. Applicant submits: “While Applicant does not acquiesce to the particular rejections of dependent Claims 24-27, 30-35, and/or 37-39, it is believed that these rejections are now nullified in view of the amendments to the respective base independent claim (21 or 36) from which they depend. These dependent claims include all the limitations of their respective base claim, and any intervening claim(s), and recite additional features which further distinguish these claims from the asserted combinations of references. Therefore, dependent claims 24-27, 30-35, and/or 37-39 are also not rendered obvious by the cited references, whether taken alone or in combination, under 35 U.S.C. § 103. The rejection of claims 22, 23, 28, 29, and 40 under 35 U.S.C. § 103 has been rendered moot by the cancellation of those claims. For the foregoing reasons, Applicant respectfully requests reconsideration and withdrawal of the rejection of the claims 21, 24-27, and 30-39 under 35 U.S.C. § 103 and allowance thereof.” Examiner submits: Examiner has fully considered, but doesn’t find Applicant’s argument persuasive. Examiner respectfully disagree with the applicant, the applicant’s arguments are directed towards the amended claim language and not original set of claims. The combination of Kim, Roach, and Silvestri discloses the claim language of claims 21 and 36, therefore, claims 24-27, 30-35, and/or 37-39 are still rejected based on dependency. See the updated art rejection above. Thus the rejection is proper and has been maintained. 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 MD S HYDER whose telephone number is (571)270-1820. The examiner can normally be reached Monday - Friday 8:30am - 6:00pm. 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. /M.S.H./Examiner, Art Unit 3698 01/28/2026 /PATRICK MCATEE/Supervisory Patent Examiner, Art Unit 3698
Read full office action

Prosecution Timeline

May 08, 2023
Application Filed
Sep 27, 2023
Response after Non-Final Action
Jun 18, 2025
Non-Final Rejection — §101, §103
Oct 09, 2025
Response Filed
Jan 28, 2026
Final Rejection — §101, §103 (current)

AI Strategy Recommendation

Get an AI-powered prosecution strategy using examiner precedents, rejection analysis, and claim mapping.
Powered by AI — typically takes 5-10 seconds

Prosecution Projections

3-4
Expected OA Rounds
0%
Grant Probability
0%
With Interview (+0.0%)
3y 0m
Median Time to Grant
Moderate
PTA Risk
Based on 8 resolved cases by this examiner. Grant probability derived from career allow rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month