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 .
DETAILED ACTION
This action is in response to the amendment filed June 26, 2025 canceling claims 1-20 and adding new claims 21-40 which are pending and examined.
Specification
Applicant is required to update the status (pending, allowed, etc.) of all parent priority applications in the first line of the specification. The status of all citations of US filed applications in the specification should also be updated where appropriate.
Information Disclosure Statement
An initialed and dated copy of Applicant’s IDS forms 1449 filed 06/02/2025, 8/06/2025, and 1/13/2026 are attached to the instant Office action.
Claim Rejections - 35 USC § 101 Utility
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 21-40 are rejected under 35 U.S.C. 101. Based upon consideration of all of the relevant factors with respect to the claim as a whole, these claims are held to claim an abstract idea, and is/are therefore rejected as ineligible subject matter under 35 U.S.C. 101. In light of the recent Supreme Court decision in Bilski v. Kappos, 561 U.S. ___ (2010), the Interim Guidance for Determining Subject Matter Eligibility for Process Claims in View of Bilski v. Kappos provides factors to consider in determining whether a claim is directed to an abstract idea and is therefore not patent-eligible under 35 U.S.C. 101. Factors weighing toward eligibility include:
Recitation of a machine or transformation (either express or inherent).
The claim is directed toward applying a law of nature.
The claim is more than a mere statement of concept.
Factors weighing against eligibility include:
No recitation of a machine or transformation (either express or inherent).
Insufficient recitation of a machine or transformation.
The claim is not directed to an application of a law of nature.
The claim is a mere statement of a general concept.
An example of a method claim that would not qualify as a statutory process would be a claim that recited purely mental steps. Thus, to qualify as a § 101 statutory process, the claim could positively recite the other statutory class (the thing or product) to which it is tied, for example by identifying the apparatus that accomplishes the method steps, or positively recite the subject matter that is being transformed, for example by identifying the material that is being changed to a different state. Furthermore, the use of a particular machine or transformation of a particular article must involve more than insignificant extra-solution activity.
In light of the factors in the Supreme Court decision, Applicant’s method steps do not meet the requirements of 35 U.S.C. 101. Claims 21-28 are method claims that have a computing system executing the steps but the computer system could arguably be software making software per se. Claims 29-36 are system claims but contain no structural elements. Claims 37-40 are a manufacture claiming a computer readable medium the problem is that arguably includes claiming a signal which is transient making it non-statutory. (Examiner’s Note: Easy fixes for the method claims have a processor of the computing system executing the steps. For the system add some structural elements to the computer system. Make the computer readable medium a “tangible computer readable medium” which precludes it claiming a signal.)
Claims 21–40 are rejected under 35 U.S.C. § 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more.
In sum, claims 21–40 are rejected under 35 U.S.C. §101 because the claimed invention is directed to a judicial exception to patentability (i.e., a law of nature, a natural phenomenon, or an abstract idea) and do not include an inventive concept that is something “significantly more” than the judicial exception under the January 2019 patentable subject matter eligibility guidance (2019 PEG) analysis which follows.
Under the 2019 PEG step 1 analysis, it must first be determined whether the claims are directed to one of the four statutory categories of invention (i.e., process, machine, manufacture, or composition of matter). Applying step 1 of the analysis for patentable subject matter to the claims, it is determined that the claims are directed to the statutory category of a process (claims 21–28), a machine (claims 29–36) and a manufacture (claims 37–40), where the machine and manufacture are substantially directed to the subject matter of the process. (See, e.g., MPEP §2106.03). Therefore, we proceed to step 2A, Prong 1.
Under the 2019 PEG step 2A, Prong 1 analysis, it must be determined whether the claims recite an abstract idea that falls within one or more designated categories of patent ineligible subject matter (i.e., organizing human activity, mathematical concepts, and mental processes) that amount to a judicial exception to patentability. Here, the claims recite the abstract idea of associating, by a computing system, an account alias with an account of a customer, the account alias comprising an address to which Math-Based Currency (MBC) is to be deposited for the customer;
receiving, by the computing system, a first notification that an MBC deposit is made to the account alias;
in response to receiving the first notification, sending, by the computing system, a second notification to the customer;
in response to the second notification, receiving, by the computing system, a customer deposition selection;
transmitting, by the computing system, a service call comprising instructions to exchange a first amount of the MBC deposit to a second amount of fiat currency; and
crediting, by the computing system, the second amount of the fiat currency to the account of the customer.
Here, the recited abstract idea falls within one or more of the three enumerated 2019 PEG categories of patent ineligible subject matter, to wit: the category of certain methods of organizing human activity, which includes fundamental economic practices or principles and commercial or legal interactions (e.g., commercial or legal interactions (including contracts which financial transactions as exchanges of goods are contracts.). (Examiner’s Note more detail about how these transactions are being implemented such as things being encrypted could change this analysis. These claims are written at a very generic high level.)
Under the 2019 PEG step 2A, Prong 2 analysis, the identified abstract idea to which the claim is directed does not include limitations that integrate the abstract idea into a practical application, since the recited features of the abstract idea are being applied on a computer or computing device or via software programming that is simply being used as a tool (“apply it”) to implement the abstract idea. (See, e.g., MPEP §2106.05(f)). Therefore, the claim is directed to an abstract idea.
Under the 2019 PEG step 2B analysis, the additional elements are evaluated to determine whether they amount to something “significantly more” than the recited abstract idea. (i.e., an innovative concept). Here, the additional elements, such as: a “computing system” do not amount to an innovative concept since, as stated above in the step 2A, Prong 2 analysis, the claims are simply using the additional elements as a tool to carry out the abstract idea (i.e., “apply it”) on a computer or computing device and/or via software programming. (See, e.g., MPEP §2106.05(f)). The additional elements are specified at a high level of generality to simply implement the abstract idea and are not themselves being technologically improved. (See, e.g., MPEP §2106.05 I.A.); (see also, paragraph [0003] of the specification). Independent claim 21 is nearly identical to independent claims 29 and 37 and so the analysis for claim 9 also applies to claims 1 and 18.
Dependent claims 22–8, 30–36, and 38–40 have all been considered and do not integrate the abstract idea into a practical application. Dependent claims 22, 30, and 38 are substantially similarly and recite limitations that further define the abstract idea noted in claim 21 as they describe receiving from the customer a request to opt-in to the MBC transaction services and approving the request before associating an account alias. Sending and receiving data is considered insignificant Extra-Solution Activity MPEP §2106.05(g). Dependent claims 23, 31, and 39 are substantially similarly and recite limitations that further define the abstract idea noted in claim 21 as they describe the account alias as associated with a generated MBC wallet . Dependent claims 24, 32, and 40 are substantially similarly and both recite limitations that further define the abstract idea noted in claim 21 as they describe the first notification comprises an exchange rate between the fiat currency and the MBC. Dependent claims 25 and 33 are substantially similarly and both recite limitations that further define the abstract idea noted in claim 21 as they describe the second notification comprises fees associated with the MBC deposit. Dependent claims 26 and 34 are substantially similarly and both recite limitations that further define the abstract idea noted in claim 21 as they describe the second notification comprises a request to approve, deny, or hold the MBC deposit. Dependent claims 27 and 35 are substantially similarly and both recite limitations that further define the abstract idea noted in claim 21 as they describe in response to receiving the customer deposition selection, confirm, by the computing system, an exchange rate between the fiat currency and the MBC has not changed significantly. Dependent claim 28 and 36 are substantially similarly and recites limitations that further define the abstract idea noted in claim 21 as it describes prior to crediting the second amount of the fiat currency to the account of the customer, receiving, by the computing system, a deposit confirmation.
The additional elements of the dependent claims merely refine and further limit the abstract idea of the independent claims and do not add any feature that is an “inventive concept” which cures the deficiencies of their respective parent claim under the 2019 PEG analysis. None of the dependent claims considered individually, including their respective limitations, include an “inventive concept” of some additional element or combination of elements sufficient to ensure that the claims in practice amount to something “significantly more” than patent-ineligible subject matter to which the claims are directed.
The elements of the instant process steps when taken in combination do not offer substantially more than the sum of the functions of the elements when each is taken alone. The claims as a whole, do not amount to significantly more than the abstract idea itself because the claims do not effect an improvement to another technology or technical field (e.g., the field of computer coding technology is not being improved); the claims do not amount to an improvement to the functioning of an electronic device itself which implements the abstract idea (e.g., the general purpose computer and/or the computer system which implements the process are not made more efficient or technologically improved); the claims do not perform a transformation or reduction of a particular article to a different state or thing (i.e., the claims do not use the abstract idea in the claimed process to bring about a physical change. See, e.g., Diamond v. Diehr, 450 U.S. 175 (1981), where a physical change, and thus patentability, was imparted by the claimed process; contrast, Parker v. Flook, 437 U.S. 584 (1978), where a physical change, and thus patentability, was not imparted by the claimed process); and the claims do not move beyond a general link of the use of the abstract idea to a particular technological environment (e.g., simply claiming the use of a computer and/or computer system to implement the abstract idea).
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 21, 23-26, 29, 31-34, 37, 39, and 40 are rejected under 35 U.S.C. 103 as being unpatentable over Ronca et al. (USPG 2015/0363769 A1) in view of CALABRESE et al. (USPG 2011/0196792 A1).
As per claim 21 Ronca teaches:
A method, comprising:
associating, by a computing system, an account alias with an account of a customer, the account alias comprising an address to which Math-Based Currency (MBC) is to be deposited for the customer; (see at least Ronca paragraphs 117 and 139 “(0117] In certain embodiments, encoding engine 218 may encode a token onto a payment instrument. For example, encoding engine 218 may generate a token that represents cryptocurrency information, such as a public key, and encode the generated token onto the payment instrument. In other words, encoding engine 218 may create a new alias for the cryptocurrency information using a unique token ( e.g., a tokenized representation of the public key), thereby securing the cryptocurrency information.” (0139] Alert engine 230 may also retrieve block chain information associated with the cryptocurrency transaction to determine block chain cryptoidentifiers. In certain embodiments, alert engine 230 may identify various public keys, IP addresses, or cryptocurrency wallets associated with either the sender or the receiver of the cryptocurrency transaction. Using these identified block chain cryptoidentifiers, alert engine 230 may determine whether a block chain cryptoidentifier matches a stored cryptoidentifier associated with one of the plurality of user profiles. In certain embodiments, alert engine 230 also determines that one of the plurality of user profiles is associated with either the user or the third party of the requested cryptocurrency transaction based on the determined match. For example, if alert engine 230 identifies a public key of the third party to the cryptocurrency transaction from the block chain information and matches that to a public key from a stored user profile, then alert engine 230 may associate the third party to the user profile. “)
transmitting, by the computing system, a service call comprising instructions to exchange a first amount of the MBC deposit to a second amount of fiat currency; (see at least Ronca paragraph 62 “(0062] Enterprise cryptocurrency server 130 may include transformation engine 214. Generally, transformation engine 214 may initiate the execution of transactions that facilitate an exchange of one currency for another currency, such as an exchange of a fiat currency for a cryptocurrency (or vice versa) or an exchange of one cryptocurrency for another cryptocurrency, according to any one of a variety of embodiments suitable for a particular purpose. More specifically, transformation engine 214 may be any software, hardware, firmware, or combination thereof capable of initiating or performing a transaction to facilitate an exchange of funds involving cryptocurrency. According to some embodiments, transformation engine 214 may be a set of instructions stored in memory 202 that may be executed by processor 201.”) and
crediting, by the computing system, the second amount of the fiat currency to the account of the customer. (see at least Ronca paragraph 62)
While Ronca was not explicit about requesting approval from a customer to proceed with a transaction Calabrese taught sending such a request to approve or deny a transaction. (see at least Calabrese paragraphs 40 and 37 “(0040] The process flow may be best understood by reference to a realistic example in a restaurant environment: The server has presented the customer a check, the customer has briefly reviewed the check, found the total amount of, say, $40.00 agreeable, and handed the server the check and the credit card. The server then moves to a backroom and processes the transaction, by swiping the card and entering the amount of $40.00 into a register terminal Immediately upon receiving the authorization request, the credit card authorization system ( e.g., the acquirer 6) sends an SMS message to the customer's cell phone. The customer receives the message telling him that the restaurant has requested authorization for a charge of $40.00. This happens well before the server returns with the transaction slip requesting the customer's signature.” “(0037] … For instance, the profile may be set to a simple notification, as above, followed by a prompt to confirm the purchase. The confirmation, again, may take any of several forms. For example, a simple "1" in answer to the confirmation request may be a code for authorization and a "2" may be a refusal.” ) Therefore it would have been obvious to a person of ordinary skill in the art of financial transactions to send requests for customer approvals in response to receiving a transaction request to avoid the customer being surprised by a transaction that does not appear as the customer expected. Solving known problem in a known way with an expectation of success.
As per claim 23 Ronca teaches:
The method of claim 21, wherein associating the account alias with the account of the customer comprises transmitting, by the computing system, instructions for generation of an MBC wallet, wherein the account alias comprises an MBC wallet address associated with the MBC wallet or a pointer to the MBC wallet address. (see at least Ronca paragraph 139 “(0139] Alert engine 230 may also retrieve block chain information associated with the cryptocurrency transaction to determine block chain cryptoidentifiers. In certain embodiments, alert engine 230 may identify various public keys, IP addresses, or cryptocurrency wallets associated with either the sender or the receiver of the cryptocurrency transaction. Using these identified block chain cryptoidentifiers, alert engine 230 may determine whether a block chain cryptoidentifier matches a stored cryptoidentifier associated with one of the plurality of user profiles. In certain embodiments, alert engine 230 also determines that one of the plurality of user profiles is associated with either the user or the third party of the requested cryptocurrency transaction based on the determined match. For example, if alert engine 230 identifies a public key of the third party to the cryptocurrency transaction from the block chain information and matches that to a public key from a stored user profile, then alert engine 230 may associate the third party to the user profile.”)
As per claims 24, 25, 26, 32, 33, 34, and 40 while Ronca is not explicit about requesting approval from a customer to proceed with a transaction Calabrese taught sending such a request to approve or deny a transaction. (see at least Calabrese paragraphs 40 and 37) The request included the details of the financial transaction so it would have been obvious in the art of requesting customer approvals to include financial transaction details involved in the transaction being approved such as the exchange rate if the transaction involved a currency exchange or the fees associated with a transaction so that the customer could make an informed decision when deciding whether to confirm or refuse a transaction. Therefore it would have been solving a known problem in a known way with an expectation of success.
As per claim 29 Ronca teaches:
A system, comprising:
a computing system to:
associate an account alias with an account of a customer, the account alias comprising an address to which Math-Based Currency (MBC) is to be deposited for the customer; (see at least Ronca paragraphs 117 and 139)
transmit a service call comprising instructions to exchange a first amount of the MBC deposit to a second amount of fiat currency; (see at least Ronca paragraph 62) and
credit the second amount of the fiat currency to the account of the customer. (see at least Ronca paragraph 62)
While Ronca was not explicit about requesting approval from a customer to proceed with a transaction Calabrese taught sending such a request to approve or deny a transaction. (see at least Calabrese paragraphs 40 and 37) Therefore it would have been obvious to a person of ordinary skill in the art of financial transactions to send requests for customer approvals in response to receiving a transaction request to avoid the customer being surprised by a transaction that does not appear as the customer expected. Solving known problem in a known way with an expectation of success.
As per claim 31 Ronca teaches:
The system of claim 29, wherein associating the account alias with the account of the customer comprises transmit instructions for generation of an MBC wallet, wherein the account alias comprises an MBC wallet address associated with the MBC wallet or a pointer to the MBC wallet address. (see at least Ronca paragraph 139)
As per claim 37 Ronca teaches:
A computer readable medium including one or more instructions stored thereon and executable by a processor to:
associate an account alias with an account of a customer, the account alias comprising an address to which Math-Based Currency (MBC) is to be deposited for the customer; (see at least Ronca paragraphs 117 and 139)
transmit a service call comprising instructions to exchange a first amount of the MBC deposit to a second amount of fiat currency; (see at least Ronca paragraph 62) and
credit the second amount of the fiat currency to the account of the customer. (see at least Ronca paragraph 62)
While Ronca was not explicit about requesting approval from a customer to proceed with a transaction Calabrese taught sending such a request to approve or deny a transaction. (see at least Calabrese paragraphs 40 and 37) Therefore it would have been obvious to a person of ordinary skill in the art of financial transactions to send requests for customer approvals in response to receiving a transaction request to avoid the customer being surprised by a transaction that does not appear as the customer expected. Solving known problem in a known way with an expectation of success.
As per claim 39 Ronca teaches:
The computer readable medium of claim 37, wherein associating the account alias with the account of the customer comprises transmit instructions for generation of an MBC wallet, wherein the account alias comprises an MBC wallet address associated with the MBC wallet or a pointer to the MBC wallet address. (see at least Ronca paragraph 139)
Conclusion
The prior art made of record and not relied upon is considered pertinent to Applicant’s disclosure:
Grassadonia et al. (U.S. Patent 9,378,491 B1) - Described is a technology for seamless initiation of a transfer of payment from a sender to a recipient by sending email, without requiring any account creation and/or login procedure. The technology can involve sending payment from one mobile device to another. In one aspect, the technology includes receiving a payment amount from a sender via the sender's mobile device, causing an email with pre-populated information to be generated using a native email application on the mobile device, and initiating the process to transfer the payment amount upon sending of the email. The technology enables a simplified payment transaction system for ordinary consumers without the hassle of having to sign up, to remember a user account and a password, and to login for sending or receiving every payment transaction, while not sacrificing the essential security feature of authenticating the user for every payment transaction. (That was its Abstract it is using email addresses to connect to financial accounts therefore the email address is an alias for the financial accounts.)
Any inquiry concerning this communication from the examiner should be directed to Scott S. Trotter, whose telephone number is 571-272-7366. The examiner can normally be reached on 8:30 AM – 5:00 PM, M-F.
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, Matthew Gart, can be reached on 571-272-3955.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (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).
The fax phone number for the organization where this application or proceeding is assigned are as follows:
(571) 273-8300 (Official Communications; including After Final Communications labeled “BOX AF”)
(571) 273-7366 (Draft Communications)
/SCOTT S TROTTER/Primary Examiner, Art Unit 3696