DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of the Claims
Claims 2-21 are presented for examination. Applicant filed a request for continued examination on 11/25/2025 amending claims 2, 6, 10, 14, 17, and 21. In light of Applicant's amendments, Examiner has withdrawn the previous § 101 rejection and the previous grounds of § 103 rejection of claims 2-21. Examiner has, however, established new § 101 rejection for claims 2-21 in the instant Office action.
Examiner's Remarks
§ 101 Rejection: Applicant argues in pages 11-12 of Applicant's Remarks:
Applicant asserts that the amended claims include several limitations that integrate any alleged abstract idea into a practical limitation, as required under the current guidance and reinforced in the USPTO Memo of August 4, 2025, including at pages 4-5 ("Improvements consideration" and "Apply it" guidance). Accordingly, even if the amended claims 2, 10, and 17 are considered to be directed to an alleged abstract idea, the amended claims (and their corresponding dependent claims), when taken as a whole, integrate any alleged abstract idea into a practical limitation as shown by the improvement to technology and/or a technical field as discussed above. Further, Applicant submits that while the above clearly supports the claims are statutory under current guidance, the USPTO Memo of August 4, 2025 at page 5 also states that "Examiners are reminded that if it is a 'close call' as to whether a claim is eligible, they should only make a rejection when it is more likely than not (i.e., more than 50%) that the claim is ineligible under 35 U.S.C. 101" and "unpatentability must be established by a preponderance of the evidence." As such, Applicant submits the claims are directed to patent eligible subject matter and respectfully requests reconsideration and withdrawal of the rejections under 35 U.S.C. § 101.
Examiner respectfully disagrees. Instant claims 2-21 do not integrate the recited abstract idea into a practical application because the claims are recited in high level of abstraction lacking details and specifics as to how the technological solution to a technological problem is carried out. For example, independent claims 2, 10, and 17 (as well as the dependent claims) are silent as to how the monitoring process is accomplished in technological specifics and details in case such details exist, nor do they provide details as to how the triggering is caused or how the event is detected in technological specifics and details in case such details exist. Applicant is merely using technology in solving a business problem instead of improving technology by solving technological problem and reciting the details and specifics of that solution. Further, here, it is not more likely than not that instant claims are patent eligible under 35 U.S.C. § 101. Therefore, claims 2-21 are not patent eligible under 35 U.S.C. § 101.
Prior Art Rejection: The closest cited prior art reference of record, Holland (US 23020/0027080 A1) teaches generally rebalancing an amount of cryptocurrency between an online storage and an offline storage based on risk. Holland, however, does not teach – alone or in combination with other references – all the claim limitations of claims 2, 10, and 17 as an ordered combination of steps.
Claim Rejections - 35 USC § 101
35 U.S.C. § 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 2-21 are rejected under 35 USC § 101 because they are directed to non-statutory subject matter. The rationale for this finding is explained below.
The Supreme Court in Mayo laid out a framework for determining whether an applicant is seeking to patent a judicial exception itself or a patent-eligible application of the judicial exception. See Alice Corp., 134 S. Ct. at 2355,110 USPQ2d at 1981 (citing Mayo, 566 U.S. 66, 101 USPQ2d 1961). This framework, which is referred to as the Mayo test or the Alice/Mayo test (“the test”), is described in detail in Manual of Patent Examining Procedure (”MPEP”) (see MPEP § 2106(III) for further guidance). The step 1 of the test: It need to be determined whether the claims are directed to a patent eligible (i.e., statutory) subject matter under 35 USC § 101. Step 2A of the test: If the claims are found to be directed to a statutory subject matter, the next step is to determine whether the claims are directed to a judicial exception i.e., law of nature, natural phenomenon, and abstract idea (Prong 1). If the claims are found to be directed to an abstract idea, it needs to be determined whether the claims recite additional elements that integrate the judicial exception into a practical application (Prong 2). Step 2B of the test: If the claims are directed to a judicial exception, the next and final step is to determine whether the claims recite additional elements that amount to significantly more than the judicial exception.
Step 1 of the Test:
When considering subject matter eligibility under 35 USC § 101, it must be determined whether the claim is directed to one of the four statutory categories of invention, i.e., process, machine, manufacture, or composition of matter. Here, the claimed invention of claims 2-9 is a system, which is one of the statutory categories of invention. Further, the claimed invention of claims 10-16 is a series of steps, which is method (i.e., a process) and, thus, also one of the statutory categories of invention. Still further, the claimed invention of claims 17-21 is a non-transitory machine-readable medium, which is also one of the statutory categories of invention.
Conclusion of Step 1 Analysis: Therefore, claims 2-21 are statutory under 35 USC § 101 in view of step 1 of the test.
Step 2A of the Test:
Prong 1: Claims 2-21, however, recite an abstract idea of rebalancing an amount of cryptocurrency between an online storage and an offline storage based on risk. The creation of rebalancing an amount of cryptocurrency between an online storage and an offline storage based on risk, as recited in the independent claims 2, 10, and 17, belongs to certain methods of organizing human activity (i.e., fundamental economic principles of practices including mitigating risk) that are found by the courts to be abstract ideas. The limitations in independent claims 2, 10, and 17, which set forth or describe the recited abstract idea, are found in the following steps:
“execute, periodically using a daemon application that is implemented in a background to monitor whether balances associated with one or more crypto storages comply with a threshold, a monitoring process that requests reading data from an online storage associated with the system for a first amount of cryptocurrency stored by the online storage and accessible through a digital cryptocurrency trading platform associated with the system” (claim 2);
“execute a plurality of first application programming interface (API) calls to a wallet application associated with the online storage for the data using the daemon application and the monitoring process” (claim 2);
“detect an occurrence of an event based on the plurality of first API calls and the data, wherein the event triggers a rebalancing of the online storage with an offline storage, wherein the rebalancing moves a second amount of cryptocurrency between the online storage and the offline storage, and wherein the risk parameter minimizes a threshold percentage of a total amount of cryptocurrency from being exposed to the digital cryptocurrency trading platform via the online storage associated with the system” (claim 2);
“determine, based on detecting the occurrence of the event, that the rebalancing of the online storage with the offline storage is required” (claim 2);
“trigger, using at least one second API call, the rebalancing of the online storage with the offline storage” (claim 2);
"determine, based on the second API call and the risk parameter, the second amount of cryptocurrency to move between the online storage and the offline storage" (claim 2);
"execute a third API call to an offline storage system corresponding to the offline storage, wherein the third API call requests that the offline storage system access a third amount of cryptocurrency stored by the offline storage in a secure offline environment for the rebalancing" (claim 2);
"execute one or more fourth API calls that move the second amount of cryptocurrency between the online storage and the offline storage" (claim 2);
“executing, using a daemon application that is implemented in a background to monitor whether balances associated with one or more crypto storages comply with a threshold, a monitoring process that reads data from an online storage corresponding to a digital cryptocurrency trading platform, wherein the data is associated with real-time balance information for a first amount of cryptocurrency stored by the online storage (claim 10);
“executing a plurality of first application programming interface (API) calls to a wallet application associated with the online storage for the data using the daemon application and the monitoring process” (claim 10);
“detecting an occurrence of an event based on the plurality of first API calls and the data, wherein the event triggers a rebalancing of the online storage with an offline storage, wherein the rebalancing moves a second amount of cryptocurrency between the online storage and the offline storage, and wherein the risk parameter minimizes a threshold percentage of a total amount of cryptocurrency from being exposed to the digital cryptocurrency trading platform via the online storage” (claim 10);
“determining, based on detecting the occurrence of the event, that the rebalance of the online storage is required to maintain the first amount of cryptocurrency at or below a threshold amount based on a risk parameter” (claim 10);
“triggering, using a second API call, the rebalancing of the online storage with the offline storage” (claim 10);
“determining, based on the second API call and the risk parameter, a second amount of cryptocurrency that rebalances the cryptocurrency between the online storage and the offline storage” (claim 10);
“executing a third API call corresponding to the offline storage, wherein the third API call requests that the offline storage system access the offline storage in an offline environment” (claim 10);
“executing one or more fourth API calls that exchange the second amount of cryptocurrency between the online storage and the offline storage using at least the offline storage system” (claim 10);
“executing the second API call to the online storage, wherein the second API call requests that a portion of the amount of cryptocurrency for the daemon application to perform a rebalancing of the online storage with the offline storage inaccessible via the cryptocurrency trading platform” (claim 17);
“executing a plurality of first application programming interface (API) calls to a wallet application associated with the online storage for the data using the daemon application and the monitoring process” (claim 17);
“detecting an occurrence of an event based on the plurality of first API calls and the data, wherein the event triggers a rebalancing of the online storage with an offline storage, wherein the rebalancing moves a second amount of cryptocurrency between the online storage and the offline storage, and wherein the risk parameter minimizes a threshold percentage of a total amount of cryptocurrency from being exposed to the digital cryptocurrency trading platform via the online storage” (claim 17);
“determining, based on detecting the occurrence of the event, that the rebalancing of the online storage with the offline storage is required” (claim 17);
“triggering, using a second API call, the rebalancing of the online storage with the offline storage” (claim 17);
“executing the second API call to the online storage, wherein the second API call requests that a portion of the amount of cryptocurrency to perform for the daemon application to perform a rebalancing of the online storage with the offline storage inaccessible via the cryptocurrency trading platform" (claim 17); and
“executing a third API call to an offline storage system corresponding to the offline storage, wherein the third API call requests access the offline storage and perform the rebalancing by storing the portion of the amount of cryptocurrency in the offline storage" (claim 17).
Prong 2: In addition to abstract steps recited above in Prong 1, independent claims 2, 10, and 17, recite additional elements:
"a non-transitory memory" (claim 2);
"one or more hardware processors coupled to the non-transitory memory and configured to execute instructions" (claim 2);
"a daemon application that is implemented in a background" (claims 2, 10, and 17);
"an online storage" (claims 2, 10, and 17); and
"a non-transitory machine-readable medium having stored thereon machine-readable instructions executable by a machine to cause a machine to perform operations."
These additional elements are recited at a high level of generality (e.g., as a generic processor performing generic computer functions) such that they amount to no more than mere instructions to apply the exception using generic computer components and software. Also, the following additional limitations recite insignificant extra solution activity (for example, data gathering):
“obtaining the portion of the amount of cryptocurrency” (claim 17); and
“transferring the portion of the amount of cryptocurrency to the offline storage system” (claim 17).
These additional limitations do not integrate the abstract idea into a practical application because they do not impose a meaningful limit on the judicial exception. The additional elements/limitations of independent claims 2, 10, and 17, here do not render improvements to the functioning of a computer or to any other technology or technical field (see MPEP § 2106.05(a)), nor do they integrate the abstract idea into a practical application under MPEP § 2106.05(b) (particular machine); MPEP § 2106.05(c) (particular transformations); or MPEP § 2106.05(e) (other meaningful limitations). Further, the combination of these additional elements/limitations is no more than mere instructions to apply the exception using a generic device. Accordingly, even in combination, these additional elements/ limitations do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea.
Conclusion of Step 2A Analysis: Therefore, independent claims 2, 10, and 17, are non-statutory under 35 USC § 101 in view of step 2A of the test.
Step 2B of the Test: The additional elements of independent claims 2, 10, and 17, (see above under Step 2A – Prong 2) are well-understood, routine, and conventional elements that amount to no more than implementing the abstract idea with a computerized system. The Applicant’s Specification describes these additional elements in following terms:
[00036] Service provider server 140 of FIG. 1 includes a cryptocurrency wallet application 150, a transaction processing application 142, a database 144, and a network interface component 146. Cryptocurrency wallet application 150 and transaction processing application 142 may correspond to executable processes, procedures, and/or applications with associated hardware. []
[00061] FIG. 5 is a block diagram of a computer system suitable for implementing one or more components in FIG. 1, according to an embodiment. In various embodiments, the communication device may comprise a personal computing device e.g., smart phone, a computing tablet, a personal computer, laptop, a wearable computing device such as glasses or a watch, Bluetooth device, key FOB, badge, etc.) capable of communicating with the network. The service provider may utilize a network computing device (e.g., a network server) capable of communicating with the network. It should be appreciated that each of the devices utilized by users and service providers may be implemented as computer system 500 in a manner as follows.
[00062] Computer system 500 includes a bus 502 or other communication mechanism for communicating information data, signals, and information between various components of computer system 500. Components include an input/output (I/O) component 504 that processes a user action, such as selecting keys from a keypad/keyboard, selecting one or more buttons, image, or links, and/or moving one or more images, etc., and sends a corresponding signal to bus 502. I/O component 504 may also include an output component, such as a display 511 and a cursor control 513 (such as a keyboard, keypad, mouse, etc.) . . . A transceiver or network interface 506 transmits and receives signals between computer system 500 and other devices, such as another communication device, service device, or a service provider server via network 160. In one embodiment, the transmission is wireless, although other transmission mediums and methods may also be suitable. One or more processors . . . 512 may also control transmission of information, such as cookies or IP addresses, to other devices.
[00063] Components of computer system 500 also include a system memory component 514 (e.g., RAM), a static storage component 516 (e.g., ROM), and/or a disk drive 517. Computer system 500 performs specific operations by processor(s) 512 and other components by executing one or more sequences of instructions contained in system memory component 514. Logic may be encoded in a computer readable medium, which may refer to any medium that participates in providing instructions to processor(s) 512 for execution. Such a medium may take many forms, including but not limited to, non-volatile media, volatile media, and transmission media. In various embodiments, non-volatile media includes optical or magnetic disks, volatile media includes dynamic memory, such as system memory component 514, and transmission media includes coaxial cables, copper wire, and fiber optics, including wires that comprise bus 502. In one embodiment, the logic is encoded in non-transitory computer readable medium.
This is a description of general-purpose computer. Further, the additional limitations of "obtaining" and "transferring" information amount to no more than mere instructions to apply the exception using generic computer components. For the same reason, these additional limitations are not sufficient to provide an inventive concept. The additional elements of "obtaining" and "transferring" information were considered insignificant extra-solution activity in Step 2A – Prong 2. Re-evaluating here in Step 2B, they are also determined to be well-understood, routine, and conventional activity in the field. Similarly to OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1093 (Fed. Cir. 2015) (sending messages over a network), and buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014) (computer receives and sends information over a network), the additional elements of independent claim 17 "obtains" and "transfers" information over a network in a merely generic manner. The courts have recognized "obtaining" and "transferring" information functions as well-understood, routine and conventional when claimed in a merely generic manner. Therefore, the additional limitations of independent claim 17 are well-understood, routine, and conventional. Further, taken as combination, the additional elements/limitations add nothing more than what is present when the additional elements/limitations are considered individually. There is no indication that the combination provides any effect regarding the functioning of the computer or any improvement to another technology.
Conclusion of Step 2B Analysis: Therefore, independent claims 2, 10, and 17, are non-statutory under 35 USC § 101 in view of step 2B of the test.
Dependent Claims: Dependent claims 3-9 depend on independent claim 2; dependent claims 11-16 depend on independent claim 10; and dependent claims 18-21 depend on independent claim 17. The elements in dependent claims 3-9, 11-16, and 18-21, which set forth or describe the abstract idea, are:
“the online storage comprises an online digital wallet for the first amount of cryptocurrency with the digital cryptocurrency trading platform for a cryptocurrency liquidity service separate from the system” (claim 3: further narrowing the recited abstract idea);
“the offline storage comprises an offline cold digital wallet, wherein the offline storage system comprises a secure digital asset custodian in a private computing network secured from the digital cryptocurrency trading platform, and wherein the secure digital asset custodian requires a consent for an outgoing transfer associated with the third amount of cryptocurrency” (claim 4: further narrowing the recited abstract idea);
“the consent comprises a group authorization from a plurality of administrators of an entity corresponding to at least one of the system or the secure digital asset custodian” (claim 5: further narrowing the recited abstract idea);
“prior to executing the plurality of first API calls, executing the instructions further causes the system to: determine a variable price of cryptocurrency corresponding to each of the first, second, and third amounts of cryptocurrency based on trading data corresponding to the digital cryptocurrency trading platform; and determine a balance value of the first amount of cryptocurrency stored by the online storage based on the variable price, wherein the risk parameter is associated with the balance value, and wherein the data provided to the daemon application includes the balance value of the first amount of cryptocurrency” (claim 6: further narrowing the recited abstract idea);
“the rebalancing comprises one of a first transfer of the second amount of cryptocurrency from the online storage to the offline storage or a second transfer of the second amount of cryptocurrency from the offline storage to the online storage, wherein the first transfer occurs for the rebalancing when the first amount of cryptocurrency is at or above the threshold percentage of the total amount of cryptocurrency, and wherein the second transfer occurs for the rebalancing when the first amount of cryptocurrency is at or below the threshold percentage of the total amount of cryptocurrency” (claim 7: further narrowing the recited abstract idea);
“the daemon application is executed by the system, and wherein executing the instructions further causes the system to: perform a plurality of rebalancing operations with the online storage and the offline storage over a time period using the daemon application, wherein the plurality of rebalancing operations maintains the first amount of cryptocurrency stored by the online storage at or below the threshold percentage” (claim 8: further narrowing the recited abstract idea);
“the plurality of rebalancing operations are performed based on at least one of periodic time intervals for rebalancing the online storage or a rebalancing trigger associated with a maximum cryptocurrency balance in the online storage” (claim 9: further narrowing the recited abstract idea);
“the online storage comprises an online digital wallet for the first amount of cryptocurrency with the digital cryptocurrency trading platform for a cryptocurrency liquidity service” (claim 11: further narrowing the recited abstract idea);
“the offline storage comprises an offline cold digital wallet, wherein the offline storage system comprises a secure digital asset custodian in a private computing network secured from the digital cryptocurrency trading platform, and the secure digital asset custodian requires a consent for an outgoing transfer associated with the offline cold digital wallet” (claim 12: further narrowing the recited abstract idea);
“the consent comprises a group authorization from a plurality of administrators of an entity corresponding to the secure digital asset custodian” (claim 13: further narrowing the recited abstract idea);
“prior to the executing the plurality of first API calls, the method further comprises: determining a value of the first amount of cryptocurrency stored by the online storage, wherein the risk parameter is associated with the value, and wherein the data provided to the daemon application includes the value of the value” (claim 14: further narrowing the recited abstract idea);
“the executing the one or more fourth API calls is associated with requesting that the second amount of cryptocurrency be transferred from the online storage to the offline storage via the offline storage system” (claim 15: further narrowing the recited abstract idea);
“the executing the one or more fourth API calls is associated with requesting that the second amount of cryptocurrency be transferred from the offline storage to the online storage by the offline storage system without accessing the offline storage in a networked environment with the online storage” (claim 16: further narrowing the recited abstract idea);
“the online storage comprises an online digital wallet for the amount of cryptocurrency with the cryptocurrency trading platform for a cryptocurrency liquidity service” (claim 18: further narrowing the recited abstract idea);
“the offline storage comprises an offline cold digital wallet, wherein the offline storage system comprises a secure digital asset custodian in a private computing network secured from the cryptocurrency trading platform, and wherein the secure digital asset custodian requires a consent for an outgoing transfer associated with the offline cold digital wallet” (claim 19: further narrowing the recited abstract idea);
“consent comprises a group authorization from a plurality of administrators of an entity corresponding to the secure digital asset custodian” (claim 20: further narrowing the recited abstract idea); and
“to the executing the plurality of first API calls, the operations further comprise: determining a value of the amount of cryptocurrency stored by the online storage, wherein the risk parameter is associated with the value, and wherein the data provided to the daemon application includes the value of the value" (claim 21: further narrowing the recited abstract idea).
Conclusion of Dependent Claims Analysis: Dependent claims 3-9, 11-16, and 18-21, do not correct the deficiencies of independent claims 2, 10, and 17, and they are, thus, rejected on the same basis.
Conclusion of the 35 USC § 101 Analysis: Therefore, claims 2-21 are rejected as directed to an abstract idea without “significantly more” under 35 USC § 101.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Joveski (US 11,151,525 B2) discloses: “The payment destination generation request (PDGR) functions to request a payment destination from the PDE. The PDGR can be: the same as the charge request, part of the charge request (e.g., subcomponent of the same request, subset of the charge request process, etc.), different from the charge request, or otherwise related to the charge request. The payment destination generation request can be: an API call (e.g., to a public endpoint), a call to a predetermined URL (e.g., public URL with the PDR appended at the end), a button press or icon selection (e.g., that triggers an API call), and/or have any other suitable format. The payment destination generation request can include: a user identifier, a cryptocurrency selection, a device identifier (e.g., for the device sending the request), a signature (e.g., signed by the private key), metadata (e.g., generated by the front end module, entered by a user, automatically determined from the user device that the front end module is running on, etc.), invoice information (e.g., payee, invoiced items, charge amount, etc.), and/or other information that can be used to determine which public key and/or account a payment destination should be generated for.”
Van Hoek (US 11,568,489 B1) discloses: “Checking that the transaction does not exceed any of the risk parameters involves the volatility of cryptocurrency. More specifically, given the volatility of cryptocurrency, holding a large amount of cryptocurrency is considered a risk. Accordingly, limitations may be put in place to prevent transactions with excessive amounts to reduce the risk. Some or every exchange for some or all transactions may be checked to make sure any defined balance thresholds are not exceeded.”
(JP 2022519438 A) discloses: “The online and offline virtual currency transfer methods and systems thereof of the present invention include a wallet storage module, an external transaction unit, and an approver side. The wallet storage module has an integrated unit and at least one online storage unit containing a plurality of transaction data, and a storage unit and an offline storage unit containing a plurality of digital data. The digital data has a cryptocurrency address and a cryptographic value. The external transaction unit and the numerical value generated by the integrated unit are received and used to detect the validity of the numerical value. The approver is used to receive the number to obtain a transaction fee.”
Wu (TW M584475 U) discloses: “An online and offline virtual currency transfer system includes a wallet storage module, an external transaction unit, and a verification end. The wallet storage module has at least an online storage unit and an offline storage unit. The online storage unit includes An integration unit and a plurality of transaction data. The offline storage unit includes a storage unit and a plurality of data information. The data information has an encrypted currency address and an encrypted value. The external transaction unit is used to receive the integration unit. A value is generated and the external transaction unit is used to check the validity of the value. The verification end is used to receive the value to obtain a transaction fee.”
Harz, Dominik, et al. "Balance: Dynamic adjustment of cryptocurrency deposits." Proceedings of the 2019 ACM SIGSAC Conference on Computer and Communications Security. 2019.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to VIRPI H. KANERVO whose telephone number is 571-272-9818. The examiner can normally be reached on Monday – Friday, 10 am – 6 pm. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor Abhishek Vyas can be reached on 571-270-1836. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/VIRPI H KANERVO/Primary Examiner, Art Unit 3691