DETAILED ACTION
Acknowledgements
This office action is in response to the claims filed 11/12/2025.
Claims 1, 9 and 17 are amended.
Claim 16 is cancelled.
Claim 21 is new
Claims 1-15, and 17-21 are pending.
Claims 1-15, and 17-21 have been examined.
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 .
Response to Arguments
Applicant's arguments filed 11/12/2025 have been fully considered but they are not persuasive.
101
Applicant argues “specifically, the claims are directed to an improvement to a relevant technology (e.g., authentication to a service), which is recognized as an example of an additional element that integrates the exception into a practical application.”. Examiner disagrees.
The claims recites insignificant extra-solution activity capable of being performed by a generic computer. Automating an abstract idea with a generic computing device performing insignificant extra-solution activity is no an additional element, The features recited in the claims are directed to transmitting, receiving information and generating messages. Additionally, Applicant’s improvement of “authentication to a service” is not an improvement, it is itself abstract to fundamental economic practices, business and commercial activities, contracting, mitigating risk etc. The rejection is maintained.
103
Arnold discloses accessing the service based at least in part on receiving the information (¶ 47, 61);
Arnold – The asset management application 202 then sends the public key and wallet address to the client device 208 (226) in order to enable the client device 208 to transfer a digital asset to the wallet. The client device 208 then can transfer the digital asset to the associated wallet by incorporating the transaction in a distributed ledger 210 (230)….At 610, the asset management application can monitor a distributed ledger associated with the wallet to confirm that the digital asset has been transferred to the wallet and the transaction has been incorporated into the distributed ledger. (¶ 61)
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 1-15, and 17-21 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Subject Matter Eligibility Standard
When considering subject matter eligibility under 35 U.S.C. § 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 (101 Analysis: Step 1). Even if the claim does fall within one of the statutory categories, it must then be determined whether the claim is directed to a judicial exception (i.e., law of nature, natural phenomenon, and abstract idea) (101 Analysis: Step 2a(Prong 1), and if so, Identify whether there are any additional elements recited in the claim beyond the judicial exception(s), and evaluate those additional elements to determine whether they integrate the exception into a practical application of the exception. (101 Analysis: Step 2a (Prong 2). If additional elements does not integrate the exception into a practical application of the exception, claim still requires an evaluation of whether the claim recites additional elements that amount to an inventive concept (aka “significantly more”) than the recited judicial exception. If the claim as a whole amounts to significantly more than the exception itself (there is an inventive concept in the claim), the claim is eligible. If the claim as a whole does not amount to significantly more (there is no inventive concept in the claim), the claim is ineligible. (101 Analysis: Step 2b).
The 2019 PEG explains that the abstract idea exception includes the following groupings of subject matter: a) Mathematical concepts b) Certain methods of organizing human activity and c) Mental processes
Analysis
In the instant case, claim 1 is directed to a method, and claims 9 and 17 are directed to an article of manufacture.
Step 2a.1– Identifying an Abstract Idea
The claims recite the steps of “transmitting… receiving… generate… message…transmitting… receiving… and accessing….” The recited limitations fall within the certain methods of organizing human activity grouping of abstract ideas, specifically, commercial interactions, for example, sending and receiving information to gain access to a service. Accordingly, the claims recites an abstract idea.
See MPEP 2106.
Step 2a.2 – Identifying a Practical Application
The claim does not currently recite any additional elements or combination of additional elements that integrate the judicial exception into a practical application.
In regards to “generating… a signed response message…”. According to the disclosure(¶ 20), “in some examples, transmitting the challenge response includes information indicating an action to be performed by the client application, where the action to be performed by the client application includes obtaining the signed response message from a wallet application.” The generating a message is an insignificant extra-solution activity of a generic computing device.
Accordingly, even in combination, these elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea.
Mere instructions to apply the exception using generic computer components and limitations to a particular field of use or technological environment do not amount to practical applications. The claim in directed to an abstract idea.
Step 2b
The claim limitations recite “transmitting… receiving” “generating…message” are not additional elements and they amount to no more than mere instructions to apply the exception using a generic computer component. For the same reason these elements are not sufficient to provide an inventive concept. This is also determined to be well-understood, routine and conventional activity in the field. The Symantec, TLI, and OIP Techs, court decision cited in MPEP 2106.05(d)(II) indicates that mere receipt or transmission of data over a network is a well-understood, routine and conventional function when it is claimed in a merely generic manner, as it is here. Therefore, when considering the additional elements alone, and in combination, there is no inventive concept in the claim and thus the claim is not eligible.
Viewed as a whole, instructions/method claims recite the concept of a commercial interaction as performed by a generic computer. The claims do not currently recite any additional elements or combination of additional elements that amount to significantly more than the judicial exception. The elements used to perform the claimed judicial exception amount to no more than mere instructions to implement the abstract idea in a network, and/or merely uses a network as a tool to perform an abstract idea and/or generally linking the use of the judicial exception to a particular environment.
Dependent claims 2-8, 10-15 and 18-21 discuss functions in more descriptive detail of the steps geared toward the abstract idea and insignificant extra solution activity such as receiving information. As such, these elements do not provide the significantly more to the underlying abstract idea necessary to render the invention patentable.
The claims do not, for example, purport to improve the functioning of the computer itself. Nor do they effect an improvement in any other technology or technical field. Therefore, based on case law precedent, the claims are claiming subject matter similar to concepts already identified by the courts as dealing with abstract ideas. See Alice Corp. Pty. Ltd., 573 U.S. 208 (citing Bilski v. Kappos, 561, U.S. 593, 611 (2010)).
The claims at issue amount to nothing significantly more than an instruction to apply the abstract idea using some unspecified, generic computer. See Alice Corp. Pty. Ltd., 573 U.S. 208. Mere instructions to apply the exception using a generic computer component and limitations to a particular field of use or technological environment cannot integrate a judicial exception into a practical application at Step 2A or provide an inventive concept in Step 2B. The use of a computer or processor to merely automate and/or implement the abstract idea cannot provide significantly more than the abstract idea itself (MPEP 2106.05(I)(A)(f) & (h)). Therefore, the claim is not patent eligible.
Conclusion
The claim as a whole, does not amount to significantly more than the abstract idea itself. This is because the claim does not affect an improvement to another technology or technical filed; the claim does not amount to an improvement to the functioning of a computer system itself; and the claim does not move beyond a general link of the use of an abstract idea to a particular technological environment.
Accordingly, the Examiner concludes that there are no meaningful limitations in the claim that transform the judicial exception into a patent eligible application such that the claim amounts to significantly more than the judicial exception itself.
Dependent claims do not resolve the deficiency of independent claims and accordingly stand rejected under 35 USC 101 based on the same rationale.
Dependent claims 2-8, 10-15 and 18-21 are also rejected.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claim 21 is rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 21 recites “wherein the wallet authentication procedure is a second factor in a two-factor authentication process for accessing the service”. The claim is unclear and indefinite. According to claim 1, “transmitting, to one or more servers and from the client application, an authentication request for a first user account to access a service… receiving, from the one or more servers, a response that indicates that an authentication procedure that uses a blockchain wallet”, claim 1 makes no reference to a “wallet authentication procedure”. The claim is unclear and indefinite as to what “wallet authentication procedure” is being referred to.
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, 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 1-15, and 17-21 are rejected under 35 U.S.C. 103 as being unpatentable over Arnold et al. (US 20240346493) (“Arnold”), and further in view of Campos et al. (US 20240378593) (“Campos”).
Regarding claims 1, 9 and 17, Arnold discloses transmitting, to one or more servers and from the client application, an authentication request for a first user account to access a service supported by the one or more servers (¶ 36, 40, 46, 56-59, 63);
Arnold – If a request to receive an inbound digital asset is received, the asset management system 102 can request that customer managed custody system 116 generate a new wallet, or otherwise prepare a digital wallet to receive the digital asset… The client device 208 can request a wallet (218) or a wallet address to which the digital asset is to be sent. (¶ 40, 46)
receiving, from the one or more servers, a response that indicates that an authentication procedure that uses a blockchain wallet is enabled for accessing the service for the first user account, the response including a blockchain wallet address associated with the first user account (¶ 43- 48, 54-60, 64);
Claim Interpretation – According to the disclosure(¶ 33, 48), “As used herein, a wallet, such as inbound wallets 165 and outbound wallets 170 may be associated with a wallet address, which may be an example of a public key, as described herein…As used herein, "wallet" and "address" may be used interchangeably… At 335, the server 310 may receive from the universal two-factor authentication component 305 in accordance with the wallet authentication procedure, a challenge request that includes the wallet address (e.g., chosen Ethereum address).”
Arnold – Once a wallet is generated (or selected) it's associated public key and wallet address can be send to the asset management application 202 (224). The asset management application 202 then sends the public key and wallet address to the client device 208 (226) in order to enable the client device 208 to transfer a digital asset to the wallet…which selects the appropriate blockchain based on the initial transaction request, and generates a transaction specific to that blockchain or distributed ledger (e.g., Ethereum, Bitcoin, Hyperledger, etc.). The transaction is then published to the appropriate blockchain, and notification can be sent to the owner of the wallet that the digital asset was sent to…The distributed ledger nodes 142 operate together to maintain a distributed ledger 144 that records transactions of digital assets between digital wallets. distributed ledger 144 can be, for example, a Bitcoin blockchain, or an Ethereum blockchain, among other cryptographic blockchains. (¶ 43, 47, 54)
transmitting, to the one or more servers and from the client application as part of the authentication procedure, a challenge request that includes the blockchain wallet address (¶ 50, 56, 65);
Arnold – In the meantime, a client device 408 associated with a user who is to receive a digital asset from the asset management application 402, can send a payment request, or invoice to the asset management application 402 (416). The payment request can include a public key and a wallet address of the wallet to which the digital asset is to be transferred. (¶ 50)
receiving, at the client application as part of the authentication procedure, a challenge response that includes a data payload (¶ 36, 50, 51, 53, 56, 65);
Arnold – The assets management application 402 can generate a transaction that includes all the necessary elements to transfer the digital asset from a wallet associated with the asset custody application 404 to the wallet in the initial request (418). In some implementations, generating the transaction includes requesting permission for the transaction from one or more owners associated with the wallet from which the transaction will occur. The generated transaction is sent with a request for signature to the asset custody application 404… For example, the asset custody application 404 can provide the first signature, and then send a notification or request to a user to apply a second signature from the offline wallet. (¶ 50, 51)
generating, at the client application as part of the authentication procedure, a signed response message using the data payload (¶ 36, 50, 51, 53, 56, 65);
Arnold – In implementations where the wallet from which the transaction will occur is a multi-signature wallet, the asset custody application 404 can provide one or more required signatures, and additional signatures can be provided from an offline wallet (e.g., cold storage wallet, not shown). For example, the asset custody application 404 can provide the first signature, and then send a notification or request to a user to apply a second signature from the offline wallet. …In some implementations, the transaction package is first sent to the customer or a device associated with the customer (e.g., client device 136 of FIG. 1 ) for approval. (¶ 51, 65)
transmitting, to the one or more servers as part of the authentication procedure, the signed response message (¶ 25, 41, 51-54, 66, 67);
Arnold – In some implementations, the asset custody application 404 sends the signed transaction back using a dedicated channel for sending signed transactions. The asset management application 402 can validate the transaction (426), for example, by confirming the signature is authentic using the public key of the associated wallet, and then send the transaction to the distributed ledger 410 to be persisted (428). In some implementations, the signed transaction is broadcasted to a number of distributed ledger nodes. (¶ 51)
receiving, at the client application, information that supports access to the service by the client application; and (¶ 43, 52, 54, 69);
Arnold – Once the transaction has been sent to the blockchain or distributed ledger, the asset management application 402 can send a message to the client device 408 confirming payment, or that the transaction has occurred 430. This allows the client device 408 or an associated entity to monitor the distributed ledger 410 for confirmation of the transaction. (¶ 52)
accessing the service based at least in part on receiving the information (¶ 47, 61);
Arnold – The asset management application 202 then sends the public key and wallet address to the client device 208 (226) in order to enable the client device 208 to transfer a digital asset to the wallet. The client device 208 then can transfer the digital asset to the associated wallet by incorporating the transaction in a distributed ledger 210 (230)….At 610, the asset management application can monitor a distributed ledger associated with the wallet to confirm that the digital asset has been transferred to the wallet and the transaction has been incorporated into the distributed ledger. (¶ 61)
Arnold does not disclose generating, at the client application as part of the authentication procedure, a signed response message using the data payload and a private key associated with the blockchain wallet address.
Campos teaches generating, at the client application as part of the authentication procedure, a signed response message using the data payload and a private key associated with the blockchain wallet address (¶ 26-29, 55, 61, 138);
Campos – Determining that the user is the owner of the wallet address usually requires the user to create a signed transaction with the user's private key and to share that transaction with the third-party. (¶ 28)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Arnold and Lu in order to provide an efficient, effective and speedy verification of assets in multiple wallets (Campos; ¶ 31).
Regarding claims 2, 10 and 18, Arnold discloses receiving at least one input to enable a set of authentication procedures of a plurality of authentication procedures for the first user account, wherein the set of enabled authentication procedures comprises at least the authentication procedure that uses the blockchain wallet (¶ 25, 45, 51, 68).
Regarding claims 3, 11 and 19, Arnold discloses wherein the authentication procedure that uses the blockchain wallet is enabled for a plurality of wallet addresses associated with the first user account, and wherein the response indicates the plurality of wallet addresses (¶ 33, 36, 37, 40, 60).
Regarding claims 4, 12 and 20, Campos teaches receiving, at the client application, a selection of a wallet provider, of a plurality of wallet providers, for authenticating at the service supported by the one or more servers (Figure 11B; ¶ 92, 93, 125, 148,149).
Regarding claims 5 and 13, Arnold discloses wherein receiving the challenge response comprises: receiving the challenge response that includes information indicating an action to be performed by the client application, wherein the action to be performed by the client application includes providing the signed response message received from a wallet application (¶ 41, 53, 54).
Regarding claims 6 and 14, Arnold discloses communicating, to the wallet application, the data payload to be signed by a private key associated with the wallet application and the first user account, wherein the signed response message is received after communicating the data payload to the wallet application (¶ 36, 50, 51, 53, 56, 65).
Regarding claims 7 and 15, Arnold discloses wherein receiving the information comprises receiving a proof token at the client application (¶ 42, 45).
Regarding claim 8, Arnold discloses wherein the one or more servers support a custodial token platform (¶ 42, 45, 46-49).
Regarding claim 21, Campos teaches wherein the wallet authentication procedure is a second factor in a two-factor authentication process for accessing the service, and wherein transmitting the authentication request comprises: transmitting, prior to receiving the response, a first authentication factor comprising at least one of a username and password combination or a phone authentication procedure for accessing the service, wherein the response that indicates that the second factor comprising the wallet authentication procedure is received after transmitting the first authentication factor (¶ 27, 53, 54, 151, 152).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Chen et al., (App 18/199,914) teaches combined electret hydrophone and transmission line.
Embrechts (US 2025/0182092) teaches recovering access to a crypto wallet
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ILSE I IMMANUEL whose telephone number is (469)295-9094. The examiner can normally be reached Monday-Friday 9:00 am to 5: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, NEHA H PATEL can be reached on (571) 270-1492. 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.
/ILSE I IMMANUEL/Primary Examiner, Art Unit 3699