DETAILED ACTION
Acknowledgements
This Non-Final Office Action is in reply to Applicant’s original application filed May 12, 2025, and to Applicant’s preliminary amendment filed June 24, 2026.
Claims 1-15 are currently pending.
Claims 1-15 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 .
Claim Rejections - 35 USC § 102
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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 9, 10, 12, 13 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by US Payments.
Regarding claim 9
US Payments discloses:
A computer-implemented method comprising:
generating a consumer token; {Page 16 “As a part of provisioning an individual account or PAN, the token service generates a token [consumer token]”}
mapping the consumer token to a crypto identifier associated with a consumer account at a crypto wallet entity; {Page 16 “As a part of provisioning an individual account or PAN [crypto identifier], the token service generates a token [consumer token], maps it to the PAN, and sends it to the token requestor. The vaulting service (Section 4.2.3) maintains the relationship between the PAN and the token.”}
sending the consumer token to a consumer computing device to authorise the consumer to access the consumer account at the crypto wallet entity in order to undertake transactions. {Page 17 “Token issuance also includes the delivery of the newly created token. The TSP acts as a trusted service manager (TSM) delivering the token over the air or over an Internet connection to a device or merchant.”}
Regarding claim 10
US Payments discloses:
A method as claimed in Claim 9, wherein the consumer token is in a format defined for transaction card account numbers issued in a transaction card account system. {Page 41 “Token. Generic term for a placeholder or surrogate. In the context of payment card transactions, a token refers to a surrogate card number that is submitted in the payment stream in place of the real card number.”}
Regarding claim 12
US Payments discloses:
A method as claimed in Claim 9, wherein the crypto identifier comprises an identifier selected from: a wallet ID, the wallet ID being a unique identifier associated with the consumer account; a consumer email address; a consumer identifier; a wallet address; a domain name.
The PAN (crypto identifier) of US Payments reads on at least wallet ID because it is an account number.
Regarding claim 13
Claim 13 is similar in scope to claim 9 and is rejected for the same reasons.
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 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 nonobviousness.
Claims 1-8, 14-15 are rejected under 35 U.S.C. 103 as being unpatentable over US Payments “EMV Payment Tokenization Primer and Lessons Learned” in view of Dooley (US 20140025571 A1).
Regarding claim 1
US Payments teaches:
A computer-implemented method of processing a transaction using cryptocurrency, the method comprising:
receiving an authorisation request from a merchant in respect of the transaction, the authorisation request containing a consumer token, the consumer token representing a tokenised crypto identifier associated with a consumer account at a crypto wallet entity; {Fig. 7, step #2}
PNG
media_image1.png
421
774
media_image1.png
Greyscale
detokenizing the consumer token to recover the crypto identifier; {Fig. 7, steps #3 and #4; “3. The payment network determines that the transaction is based on a token BIN and issues a request to the appropriate TSP to validate the unique cryptogram and detokenize the token to the clear PAN. 4. The TSP verifies the cryptogram and returns the clear PAN [crypto identifier] to the payment network.”}
determining the crypto wallet entity associated with the crypto identifier;
forwarding the authorisation request and the crypto identifier to the crypto wallet entity; {Fig. 7 steps #5 and #6 “5. The payment network forwards the transaction with the clear PAN to the appropriate issuer processor. 6. The issuer processor forwards the authorization request, with the clear PAN, to the issuer [crypto wallet entity].”; Page 39 “Bank Identification Number (BIN). The first six or eight digits of a payment card number (e.g., credit cards, debit cards). These are now known as the Issuer Identification Number (IIN). The BIN/IIN identifies [determining] the institution that issued the card to the cardholder.”}
receiving a transaction approval message from the crypto wallet entity; {Fig. 7 step #8 “8. The issuer processor sends the authorization response to the payment network.”}
forwarding the transaction approval message to an acquirer and {Fig. 7 step #9 “9. The payment network sends the authorization response to the merchant acquirer/processor”}
US Payments does not teach, however Dooley teaches:
sending a settlement advice message to a settlement bank to settle the transaction between the crypto wallet entity and the acquirer. {[0035] “According to various implementations of the invention, settlement advice request message(s) may be associated with the authorization approval response, wherein each settlement advice request message may include a request to transfer a portion of the authorized total amount indicated by the authorization approval response.”}
US Payments mentions settlement on page 6, but says it is outside the scope of that white paper. Dooley teaches a settlement advice request message associated with the authorization response to transfer the authorized amount.
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to add the settlement advice request message of Dooley to the authorization process of US Payments because it would have the advantage of actually transferring the authorized amount of money and because US Payments suggests the combination since US Payments explicitly mentions the need for settlement but declines to describe it (US Payments Page 6 “A number of topics were determined to be out of scope for this white paper, including: […] Issuer, merchant, and acquirer settlement”).
Regarding claim 2
A method as claimed in Claim 1, wherein the consumer account at the crypto wallet entity comprises encryption keys for accessing consumer cryptocurrency assets on a blockchain.
This language does not contain any method step, nor does it alter the performance of any claimed method step. Data held by the crypto wallet entity is outside the scope of the claimed method.
Regarding claim 3
US Payments does not teach, however Dooley teaches:
A method as claimed in Claim 1, comprising settling the transaction between the crypto wallet entity and the acquirer in fiat currency. {[0035] “According to various implementations of the invention, settlement advice request message(s) may be associated with the authorization approval response, wherein each settlement advice request message may include a request to transfer a portion of the authorized total amount indicated by the authorization approval response.”}
The reasons for combining US Payments with Dooley are given above with respect to claim 1.
Regarding claim 4
US Payments teaches:
A method as claimed in Claim 1, wherein the tokenised crypto identifier comprises a wallet ID, the wallet ID being a unique identifier associated with the consumer account. {Page 16 “As a part of provisioning an individual account or PAN [unique identifier associated with the consumer account], the token service generates a token [consumer token representing a tokenised crypto identifier], maps it to the PAN, and sends it to the token requestor. The vaulting service (Section 4.2.3) maintains the relationship between the PAN and the token.”; Page 8 “tokens are typically unique to a device and channel”}
Regarding claim 5
US Payments teaches:
A method as claimed in Claim 1, wherein the tokenised crypto identifier comprises one identifier selected from: a consumer email address; a consumer identifier; a wallet address; a domain name. {Page 8 “tokens are typically unique to a device and channel”}
The token of US Payments reads on at least consumer identifier.
Regarding claim 6
US Payments teaches:
A method as claimed in Claim 1, wherein the transaction is processed at a digital enablement system within a transaction infrastructure, the digital enablement system being configured to support tokenised transactions and wherein the method comprises routing transactions between the crypto wallet entity and the acquirer. {Fig. 7, Issuer reads on crypto wallet entity}
Regarding claim 7
US Payments teaches:
A method as claimed in Claim 6, wherein the crypto wallet entity comprises a crypto wallet host application that is configured to interact with the transaction infrastructure and the method comprises the digital enablement system onboarding the crypto wallet host application as an issuer entity. {Page 14 “Onboarding is required for the issuer to be enabled for the selected TSP.”}
Regarding claim 8
US Payments teaches:
A method as claimed in Claim 6, wherein the transaction infrastructure comprises an issuer processor device that is configured to communicate with the crypto wallet host application and the method comprises forwarding the authorisation request and crypto identifier to the issuer processor device for onward transmission to the crypto wallet host application. {Fig. 7 step #5}
Regarding claim 14
Claim 14 depends from claim 13 (disclosed by US Payments). The additional limitations of claim 14 are substantially similar to the limitations of claim 1 (taught by US Payments in view of Dooley). Claim 14 is therefore taught by US Payments in view of Dooley for the reasons given above with respect to claims 1 and 13.
Regarding claim 15
Claim 15 is similar in scope to claim 1 and is rejected for the same reasons.
Claim 11 is rejected under 35 U.S.C. 103 as being unpatentable over US Payments as applied to claim 10 above, and further in view of Wikipedia “Payment card number”.
Regarding claim 11
US Payments does not teach, however Wikipedia teaches:
A method as claimed in Claim 10, wherein the consumer token comprises 16 decimal digits. {Page 1 “Payment card numbers are composed of 8 to 19 digits”}
US Payments teaches “a token refers to a surrogate card number” (Page 41), but does not specifically teach a card number being 16 digits. It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention that the card number of US Payments could be 16 digits because Wikipedia teaches payment card numbers are in the range of 8 to 19 digits.
Cited Art Not Relied Upon
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure and is listed in the enclosed PTO-892.
Price (WO 2022154789 A1) teaches:
Abstract “Methods and systems for token-based off-chain interaction authorization are disclosed, A hub computer can maintain a network of off-chain (or "layer two") channels between itself, cryptocurrency issuer computers, and cryptocurrency custodian computers. These off-chain channels correspond to one or more underlying blockchains. The hub computer can receive an access token, a resource provider identifier, and an interaction value. The hub computer can use the access token to identify a cryptocurrency issuer computer associated with the mobile device, and use the resource provider identifier to identify the cryptocurrency custodian computer associated with the access device. The hub computer can update the state of the off-chain channels corresponding to these two computers based on the interaction value, then transmit an authorization response message.”
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SCOTT MICHAEL DIROMA whose telephone number is (571)272-6430. The examiner can normally be reached Monday - Friday 12:30 pm - 8:30 pm.
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 on (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.
/S.M.D./Examiner, Art Unit 3698
/PATRICK MCATEE/Supervisory Patent Examiner, Art Unit 3698
Prosecution Insights