DETAILED ACTION
1. 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 .
2. Status of Application and Claims
Claims 1, 4-5, 7, 16 and 18-20 are pending.
Claims 1 and 16 were amended or newly added in the Applicant’s filing on 10/29/2025.
Claims 2-3, 6, 8-15 and 17 were cancelled in the Applicant’s filing on 10/29/2025.
This office action is being issued in response to the Applicant's filing on 10/29/2025.
3. Claim Objections
Claim 1 is objected to because of the following informalities: lack of antecedent basis.
Claim 1 recites a method comprising:
receiving, via the at le[a]st one user interface device, a currency request include[ing] an amount of currency requested;
However, there is no earlier recitation of an, at least one, user interface device in Claim 1.
Appropriate correction is requested.
4. Claim Interpretation
The subject matter of a properly construed claim is defined by the terms that limit its scope when given their broadest reasonable interpretation. see MPEP §2013(I)(C). Specifically, the “broadest reasonable construction ‘in light of the specification as it would be interpreted by one of ordinary skill in the art.’” See MPEP §2111, citing Phillips v. AWH Corp., 75 USPQ2d 1321, 1329 (Fed. Cir. 2005). However, “[t]hough understanding the claim language may be aided by explanations contained in the written description, it is important not to import into claim limitations that are not part of the claim.” See MPEP §2111.01, citing Superguide Corp. v. DirecTV Enterprises, Inc., 69 USPQ2d 1865, 1868 (Fed. Cir. 2004). Construing claims broadly during prosecution is not unfair to the applicant, because the applicant has the opportunity to amend the claims to obtain more precise claim coverage. See MPEP §2111, citing In re Yamamoto, 222 USPQ 934, 936 (Fed. Cir. 1984).
As a general matter, grammar and the plain meaning of terms as understood by one having ordinary skill in the art used in a claim will dictate whether, and to what extent, the language limits the claim scope. See MPEP §2013(I)(C). Language that suggests or makes a feature or step optional but does not require that feature or step does not limit the scope of a claim under the broadest reasonable claim interpretation. See MPEP §2013(I)(C).
As such, claim limitations that contain statement(s) such as “if,” “may,” “might,” “can,” and “could” are treated as containing optional language. See MPEP §2013(I)(C). As matter of linguistic precision, optional claim elements do not narrow claim limitations, since they can always be omitted. See MPEP §2013(I)(C).
Similarly, a method step exercised or triggered upon the satisfaction of a condition, where there remains the possibility that the condition was not satisfied under the broadest reasonable interpretation, is an optional claim limitation. See MPEP §2111.04(II). As the Applicant does not address what happens should the optional claim limitations fail, Examiner assumes that nothing happens (i.e., the method stops). An alternate interpretation is that merely the claim limitations based upon the condition are not triggered or performed.
In addition, when a claim requires selection of an element from a list of alternatives, the prior art teaches the element if one of the alternatives is taught by the prior art. See MPEP §2143.03, citing Fresenius USA, Inc. v. Baxter Int’l, Inc., 582 F.3d 1288, 1298 (Fed. Cir. 2009);
Language in a method or system claim that states only the intended use or intended result, but does not result in a manipulative difference in the steps of the method claim nor a structural difference between the system claim and the prior art, fails to distinguish the claims from the prior art.
The following types of claim language may raise a question as to its limiting effect (this list is not exhaustive):
Statements of intended use or field of use, including statements of purpose or intended use in the preamble. See MPEP §2111.02;
Clauses such as “adapted to”, “adapted for”, “wherein”, and “whereby.” See MPEP §2111.04;
Contingent limitations. See MPEP §2111.04(II);
Printed matter. See MPEP §2111.05; and
Functional language associated with a claim term. See MPEP §2181.
As such, while all claim limitations have been considered and all words in the claims have been considered in judging the patentability of the claimed invention, the following italicized, underlined and/or boldened language is interpreted as not further limiting the scope of the claimed invention.
Additionally, the following italicized, underlined and emboldened language is not necessarily an exhaustive list of claim language that is interpreted as not further limiting the scope of the claimed invention. Applicant should review all claims for additional claim interpretation issues.
Claim 1 recites a method comprising:
translating, by the bankcard issuer computing system, at least a portion of the payment authorization data into tokenized bankcard data;
providing, by the bankcard issuer computing system, the payment authorization data with the tokenized bankcard data and a currency request that includes an amount of currency being requested;
translating, by the bankcard issuer computing system, at least a portion of the payment authorization data into tokenized bankcard data;
providing, by the bankcard issuer computing system, the payment authorization data with the tokenized bankcard data and a currency request that includes an amount of currency being requested;
Under the broadest reasonable interpretation, the entirety of payment authorization data is translated into tokenized bankcard data. As such, there is no payment authorization data to provide, only the tokenized bankcard data to provide. The tokenized bankcard data has replaced the payment authorization data.
Examiner assumes that the bankcard issuer computing system is providing two separate and distinct data elements, the payment authorization data (now tokenized bankcard data) and a currency request that includes an amount of currency being requested.
Claim 16 has similar issues. The tokenized bankcard data has replaced the payment authorization data.
5. 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, 4-5, 7, 16 and 18-20 are rejected under 35 U.S.C. § 101 because the claimed invention is directed to an abstract idea without significantly more.
STEP 1
The claimed invention falls within one of the four statutory categories of invention (i.e., process, machine, manufacture and composition of matter). See MPEP §2106.03.
STEP 2A – PRONG ONE
The claim(s) recite(s) a method and a system to perform a method comprising:
authenticating, by a bankcard issuer …, payment authorization data associated with a bankcard;
translating, by the bankcard issuer …, at least a portion of the payment authorization data into tokenized bankcard data;
providing, by the bankcard issuer …, the payment authorization data with the tokenized bankcard data and a currency request that includes an amount of currency being requested;
receiving, …, the payment authorization data;
receiving, …, a currency request include an amount of currency requested:
transmitting the currency request and payment authorization data including the tokenized bankcard data … to a token service provider;
translating, by the token service provider, the tokenized bankcard data into a standardized card number of a bankcard payment network known by computing systems of the bankcard issuer computing system;
receiving, by the token service provider, the currency request and payment authorization data including the tokenized bankcard data;
associating, by the bankcard issuer ..., the payment authorization data with a bankcard account of a user maintained [by] the bankcard … based on the standardized card number;
receiving …, a currency request response authorizing dispensing of the amount of currency request …;
transmitting, …, a request for user confirmation;
receiving, …, the user confirmation; and
dispensing, …, currency …. to the user, … in response to receiving the user confirmation from the [user].
These limitations, as drafted, under its broadest reasonable interpretation, covers a series of steps instructing how to process a financial transaction which is a fundamental economic practice, a sub-category of certain method(s) of organizing human activity, an enumerated grouping of abstract ideas. See MPEP §2106.04(a)(2)(II)(A).
Examiner notes that processing payments is a court-provided example of a fundamental economic practice. See MPEP §2106.04(a)(2)(II)(A), citing Inventor Holdings, LLC v. Bed Bath Beyond, 876 F.3d 1372, 1378-79, 125 USPQ2d 1019, 1023 (Fed. Cir. 2017).
Accordingly, the claimed invention recites an abstract idea.
STEP 2A – PRONG TWO
The claimed invention recites additional elements (i.e., computer elements) of a computing system (Claim(s) 1), a terminal or terminal controller (Claim(s) 1 and 16), a short-range radio transceiver device (Claim(s) 1 and 16), a mobile app (Claim(s) 1 and 16), a mobile device (Claim(s) 1 and 16), a user interface device (Claim(s) 1 and 16), a currency cassette (Claim(s) 1 and 16), a currency dispenser (Claim(s) 1 and 16), a processor (Claim(s) 16), a memory device (Claim(s) 16), a network interface device (Claim(s) 16).
The claimed invention does not include additional elements that integrate the judicial exception into a practical application of the exception because the claims do not provide improvements to another technology or technical field; improvements to the functioning of the computer itself; are not applying or using a judicial exception to effect a particular treatment or prophylaxis for a disease or medical condition; are not applying the judicial exception with or by use of a particular machine; are not effecting a transformation or reduction of a particular article to a different state or thing; and are not applying the judicial exception in some other meaningful way beyond generally linking the use of the judicial exception to a particular technological environment. See MPEP §2106.04(d).
The additional elements are recited at a high-level of generality such that it amounts no more than mere instructions to apply the exception using a generic computer component. See MPEP §2106.05(f). Alternately, the additional elements amount to no more than generally linking the exception to a particular technological environment or field of use. See MPEP §2106.05(h). Accordingly, these additional element(s), when considered separately and as an ordered combination, do not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea.
Accordingly, the claimed invention is directed to an abstract idea without a practical application.
STEP 2B
Upon reconsideration of the indicia noted under Step 2A in concert with the Step 2B considerations, the additional claim element(s) amounts to (i) adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, (ii) adding insignificant extra-solution activity to the judicial exception, and/or (iii) generally linking the use of judicial exception to a particular technological environment or field of use. See MPEP §2106.07(a)(II). The same analysis applies in Step 2B, i.e., mere instructions to apply an exception using a generic computer component cannot integrate a judicial exception into a practical application at Step 2A or provide an inventive concept in Step 2B. The claim does not provide an inventive concept significantly more than the abstract idea.
Accordingly, these additional elements, when considered separately and as an ordered combination, do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea.
DEPENDENT CLAIMS
Dependent Claim(s) 4, 5, 7, 19 and 20 recite claim limitations that further define the abstract idea recited in respective independent Claim(s) 1 and 16. As such, the dependent claims are also grouped an abstract idea utilizing the same rationale as previously asserted against the independent claims.
No additional computer components other than those found in the respective independent claims is recited, thus it is presumed that the claim is further utilizing the same generically recited computer.
As such, the dependent claims do not include any additional elements that integrate the abstract idea into a practical application of the judicial exception or are sufficient to amount to significantly more than the judicial exception when considered both individually and as an ordered combination.
Accordingly, the dependent claim(s) are also not patent eligible.
Appropriate correction is requested.
6. Claim Rejections - 35 USC § 112 (b)
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.
Claims 1, 4, 5 and 7 are 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 1 recites a method comprising:
authenticating, by a bankcard issuer computing system, payment authorization data associated with a bankcard;
translating, by the bankcard issuer computing system, at least a portion of the payment authorization data into tokenized bankcard data;
providing, by the bankcard issuer computing system, the payment authorization data with the tokenized bankcard data and a currency request that includes an amount of currency being requested;
receiving, by a terminal via a short-range radio transceiver device from a mobile wallet app that executes on a mobile device, the payment authorization data;
Under the broadest reasonable interpretation, the entirety of payment authorization data is translated into tokenized bankcard data by the bankcard issuer computing system. As such, there is no payment authorization data to provide, only the tokenized bankcard data to provide. The tokenized bankcard data has replaced the payment authorization data.
Examiner notes that the method does not recite what entity the payment authorization data and the amount of currency being requested is being provided to.
Is the terminal receiving payment authorization data (now tokenized bankcard data) from the mobile device wherein the payment authorization data is the same payment authorization data authenticated, translated and provided by the bankcard issuer computing system?
Or is the terminal receiving payment authorization data from the mobile device wherein the payment authorization data is separate and distinct from the payment authorization data (now tokenized bankcard data) processed by the bankcard issuer computing system?
Examiner notes that the payment authorization data existed prior to its processing by the bankcard issuer computer system, as the bankcard issuer computer system authenticated the payment authorization data.
Claim 1 recites a method comprising:
providing, by the bankcard issuer computing system, the payment authorization data with the tokenized bankcard data and a currency request that includes an amount of currency being requested;
receiving, by a terminal via a short-range radio transceiver device from a mobile wallet app that executes on a mobile device, the payment authorization data;
receiving, via the at least one user interface device, a currency request include an amount of currency requested;
Examiner notes that the method does not recite what entity the payment authorization data and the amount of currency being requested is being provided to.
Examiner notes that there is no previous recitation of a user interface device.
Is the user interface device a user interface of the terminal? Is the user interface device the previously recited mobile device? Or is the user interface device separate and distinct from all the previously recited structural elements?
Examiner notes that the method recites receiving a currency request including an amount of currency requested rather than the currency request, previously recited.
Is this a separate and distinct currency request from the currency request provided by the bankcard issuer computing system? Examiner notes that such an interpretation means that the initial currency request is nonfunctional descriptive material.
Or is the user interface receiving via the user interface device the currency request provided by the bankcard issuer computing system? Possibly, directly from the bankcard issuer computing device, as the claim is silent regarding to whom the currency request is being provided to or from whom it is being received from.
Claim 1 recites a method comprising:
transmitting the currency request and payment authorization data including the tokenized bankcard data from the terminal via a bankcard payment network to a token service provider;
translating, by the token service provider, the tokenized bankcard data into a standardized card number of a bankcard payment network known by computing systems of the bankcard issuer computing system;
receiving, by the token service provider, the currency request and payment authorization data including the tokenized bankcard data.
Examiner notes that the method recites transmitting data to a token service provider, the token service provider translating the data, and then the token service provider receiving the data. The steps appear to be out of order.
Claim 1 recites a method comprising:
authenticating, by a bankcard issuer computing system, payment authorization data associated with a bankcard;
translating, by the bankcard issuer computing system, at least a portion of the payment authorization data into tokenized bankcard data;
…
translating, by the token service provider, the tokenized bankcard data into a standardized card number of a bankcard payment network known by computing systems of the bankcard issuer computing system;
receiving, by the token service provider, the currency request and payment authorization data including the tokenized bankcard data.
associating, by the bankcard issuer computing system, the payment authorization data with a bankcard account of a user maintained on the bankcard issuer computing system based on the standardized card number.
Examiner notes that the token service provider receives data and translates the received data but the bankcard issuer computing system associates other data elements with the translated data.
Does this mean that the token service provider transmits the translated data to the bankcard issuer computing system and the bankcard issuer computing system is further processing the translated data?
Or does this mean that the bankcard issuer computing system is performing a function separate, distinct and unconnected to the translation performed by the token service provider? For example, the bankcard issuer computing system associated data elements with each other in a previous step before the token service provider ever received the payment authorization data.
Examiner notes that the bankcard issuer computing system translates the payment authorization data into tokenized bankcard data. If the token service provider can translate (i.e., reverse translate or back translate) the tokenized bankcard into the standardized card number, then the bankcard issuer computing system has already associated the payment authorization data with a bankcard account of a user maintained on the bankcard issuer when it tokenized the payment authorization data.
Examiner notes that the method does not perform any function based upon the associated data elements (i.e., the payment authorization data with a bankcard account of a user maintained on the bankcard issuer computing system based on the standardized card number). The method merely associates them (e.g., stores them together).
Appropriate correction is requested.
7. 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.
The text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied 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, 4, 5, 7, 16 and 18-20 are rejected under 35 U.S.C. 103 as obvious over Varadarajan (US PG Pub. 2011/0238573) in view of Aabye (US PG Pub. 2014/0164243) and Kay (US PG Pub. 2013/0124410).
Regarding Claim 1, Varadarajan discloses a method comprising:
authenticating, by a bankcard issuer computing system (provider system), payment authorization data (authentication information) associated with a bankcard. (see fig.3 and 4; para. 51);
translating (encrypting, obfuscating or camouflaging), by the bankcard issuer computing system, at least a portion of the authorization data into encrypted bankcard data (transaction identifier/transaction authenticator). (see fig. 3 and 4; para. 34, 54 and 56);
providing, by the bankcard issuer computing system, the payment authorization data with encrypted bankcard data (transaction identifier/transaction authenticator) and a currency request that includes an amount of currency being requested (transaction amount/sufficient funds). (see fig. 3 and 4; para. 36, 51, 54 and 56);
receiving by a terminal (ATM) via a short-range radio transceiver device (e.g., RFID, Bluetooth or NFC) from a mobile wallet app that executes on a mobile device, the payment authorization data (transaction identifier/transaction authenticator). (see abstract; fig. 3 and 4; para. 57-58);
receiving, by the at least one user interface device (device keypad), a currency request including an amount of currency requested (amount of the transaction). (see para. 56);
transmitting the currency request and payment authorization data including the encrypted bankcard data from the terminal (ATM) via a bankcard payment network to service provider. (see fig. 3 and 4; para. 69-70);
translating (decrypting), by the service provider, encrypted bankcard data (transaction identifier/transaction authorization) into a standardized card number (account number) of a bankcard issuer computing system. (see para. 36, 54 and 62);
receiving, by the service provider, the currency request and the payment authorization data including the encrypted bankcard data. (see fig.2-4; para. 42, 61-62 and 70);
associating, by the bankcard issuer computing system, the payment authorization data (authentication information) with a bankcard account (account information) of the user maintained on the bankcard issuer computing system based on the standardized card number (account number). (see para. 36 and 51);
receiving by the terminal via the bankcard payment network, a currency request response authorizing dispensing of currency in the amount of the currency request (transaction authorization result) at the terminal. (see fig. 2-4; para.
transmitting, by the terminal to the mobile device, a request for user confirmation (additional authentication). (see para. 40 and 50);
receiving, by the terminal from the mobile device, the user confirmation (additional authentication information). (see fig. 3; para. 40 and 59); and
dispensing, by the terminal, currency stored in a currency cassette by a currency dispenser (fund dispenser) in the amount of the currency request from the terminal to the user, wherein the currency dispenser is activated in response to receiving the user confirmation (authentication information) from the mobile device. (see fig. 3; para. 43).
Varadarajan does not explicitly teach a method wherein the encrypting/decrypting service provider is separate and distinct from the card issuer computing system.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to have modified Varadarajan by separating one composite claim element contained in Varadarajan (i.e., one system) into component claim elements (e.g., a first system and a second system) wherein each component claim element would serve the same separate function performed when it was a component in the original composite claim element. In the separation each component claim element, would merely have performed the same function as it did previously, and one of ordinary skill in the art at the effective filing date of the invention would have recognized that the results of the separation were predictable. See MPEP §2144.04 (V)(C).
Varadarajan does not explicitly teach a method wherein the encrypted data is tokenized (i.e., data encryption via substitution of a sensitive data element with a non-sensitive data element), although Varadarajan does recite that the data can be secured “by any method of encryption, obfuscation, camouflaging or other cryptographic or data security technique.” (see para. 74).
Regardless, Aabye discloses a method wherein:
the data is tokenized data (see para. 2); and
translating (reverse tokenization) tokenized data is performed by a token service provider. (see para. 2 and 93).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to have modified Varadarajan by incorporating tokenization of data to encrypt data, as disclosed by Aabye, as tokenization of data is a standard and conventional means by which to protect sensitive data.
Varadarajan does not explicitly teach a method comprising transmitting, by the terminal to the mobile device, a request for user confirmation, although Varadarajan discloses a method comprising transmitting, to the mobile device, a request (prompt) for user confirmation (authentication information) (see para. 40), and that data is exchanged between mobile device and terminal interfaces (see fig. 1; para. 40).
Regardless, Kay discloses a method comprising:
transmitting, by the terminal (financial transaction terminal) to the mobile device, a request for user confirmation (confirmation). (see para. 53); and
receiving, by the terminal from the mobile device, the user confirmation. (see para. 53).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to have modified Varadarajan and Aabye by incorporating the inclusion of a confirmation process, as disclosed by Kay, thereby ensuring that the user desired to proceed with the financial transaction before completing the financial transaction.
Regarding Claim 4, Varadarajan discloses a method wherein the short-range radio transceiver device is a Near-Field Communication (NFC) radio transceiver device (near field communication means). (see abstract).
Regarding Claim 5, Varadarajan discloses a method wherein the terminal is an Automated Teller Machine (ATM). (see abstract).
Regarding Claim 7, Varadarajan discloses a method wherein the bankcard is a credit card. (see para. 22).
Regarding Claims 16 and 18-20, such claims recite substantially similar limitations as claimed in previously rejected claims and, therefore, would have been obvious based upon previously rejected claims or are otherwise disclosed by the prior art applied in previously rejected claims.
8. Response to Arguments
Applicant's arguments filed 10/29/2025 have been fully considered but they are not persuasive.
§103 Rejection
Applicant argues that the previously asserted prior art (Varadarajan, Aabye and Kay) fail to teach or suggest the “mobile wallet integration with user confirmation process” of the claimed invention. See Arguments. p. 7.
Specifically, Applicant argues:
The amended claims specifically recite receiving payment authorization data "from a mobile wallet app that executes on a mobile device" and then later "transmitting, to the mobile device, a request for user confirmation" followed by "receiving, from the mobile device, the user confirmation" with the currency dispenser being "activated in response to receiving the user confirmation from the mobile device."
While Varadarajan discloses ATM transactions using mobile devices, it does not teach the specific integration of a mobile wallet app with a subsequent user confirmation process where the terminal specifically requests confirmation from the mobile device after receiving the payment authorization data. Varadarajan's authentication occurs at the beginning of the process, not as a separate confirmation step after payment processing.
Kay discloses some communication between terminals and mobile devices but does not teach the specific sequence of first receiving payment authorization data from a mobile wallet app, then subsequently requesting and receiving user confirmation from the same mobile device as a prerequisite for currency dispenser activation. See Arguments, p. 7.
The Examiner respectfully disagrees.
As a preliminary matter, in response to applicant's piecemeal analysis of the references, "one cannot show non-obviousness by attacking references individually where, as here, the rejections are based on combinations of references." See MPEP §2145(IV), citing In re Keller, Terry, and Davies, 208 USPQ 871, 882 (CCPA 1981). In the instant case, applicant refutes each prior art reference individually, rather than viewing them in combination, in light of the totality of their combined teachings.
Varadarajan recites:
The mobile user device 20 may be further configured with an ATM application 22 and may be configured with a dynamic value generator (DVG) 26. The ATM application 22 on the mobile user device 20 may include one or more algorithms configured to conduct communications with an automated teller machine such as the ATM 30. The DVG 26 may include one or more algorithms configured to generate one or more types of dynamic values, such as one-time passcodes, transaction identifiers and authentication values. See para. 15 – emphasis added.
At step 108, the transaction information, which for the process 200 shown in FIG. 3 may be the transaction identifier provided in step 226, is communicated from the mobile user device 20 to the ATM 30 through the interfaces 23, 33. In a preferred embodiment, the transaction identifier is representative of and substituted for all information required to complete the user's ATM transaction, including, for example, authentication information, thus avoiding the need for the user to input any information into the ATM 30 through the ATM keypad 35, a display touch screen 34, and/or a card reader 39. See para. 58 – emphasis added.
Varadarajan discloses a method comprising an ATM receiving payment authorization data (transaction identifier) from a mobile wallet app (an ATM application) that executes on a mobile device. See para. 15 and 58.
Kay recites:
The financial transaction terminal may use a display of the financial transaction terminal to communicate with the customer, or alternatively, the financial transaction terminal may use a display of the mobile device to communicate with the customer. The financial transaction device may require the customer to enter the PIN for authorization using the financial transaction terminal or the mobile device. Once authorized, the financial transaction terminal can prompt the customer, using the financial transaction terminal or the mobile device, that cash is being dispensed from the financial transaction terminal. During the communication session between the financial transaction terminal and the mobile device, the financial transaction terminal transmits to and receives information from the bank regarding the requested transaction, authentication information of the customer, and account information of the customer. During the communication session, the financial transaction terminal also transmits to and receives information from the mobile device regarding the requested transaction, authentication information of the customer, account information of the customer, confirmation by the customer, and input from the customer into the mobile device for commanding the financial transaction terminal. See para. 53 – emphasis added.
Kay recites a method comprising transmitting, from the terminal to the mobile device, a request for user confirmation and receiving, from the mobile device, user confirmation. See para. 53.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to have modified Varadarajan and Aabye by incorporating the inclusion of a confirmation process, as disclosed by Kay, thereby ensuring that the user desired to proceed with the financial transaction before completing the financial transaction.
Applicant argues that the previously asserted prior art (Varadarajan, Aabye and Kay) fails to teach or suggest the “specific user interface integration” of the claimed invention. See Arguments, p. 7.
Specifically, Applicant argues:
Amended claim 1 recites "receiving, via the at least one user interface device, a currency request including an amount of currency requested" as a separate step from receiving payment authorization data from the mobile wallet app. This specific dual-input approach (payment authorization from mobile wallet app plus currency request amount via user interface) is not taught by the referenced combination. See Arguments, p. 7.
The Examiner respectfully disagrees.
Varadarajan recites:
After the user's requested transaction has been affirmatively authorized at step 224, the provider system at step 226 may generate a transaction identifier, which may be specific to the user's authorized transaction. The transaction identifier generated or provided may serve as a substitutional value for the transaction information which the mobile user device 20 would input to the ATM, for example, in step 108 of process 200, and may further serve as a substituted or substitutional value for authentication or authorization information. Accordingly, the transaction identifier provided at step 226 is preferably unique to the user's authorized transaction, or may when inputted with an associated authenticator or authenticating value, such as a challenge or PIN, provide or generate a unique identifying parameter associated with the authorized transaction. The transaction identifier may be configured as one of or a combination of a character string of one or more alpha-numeric or special characters, a datum or an electronic signal transmittable from the user device, a datum or an electronic signal generated by the user device, or as a user instruction. These examples are not intended to be limiting in scope, and it is understood that a transaction identifier could be configured in any form which may be input into an ATM interface by, for example, the user or user device. For example, the transaction identifier may be an electronic signal or data transmittable from the mobile user device 20 to the ATM 30 through a connection which may be established between the interfaces 23, 33. As another example, the transaction identifier may be provided in human readable characters which can be input into the ATM 30 through an ATM input interface such as the keypad 35 or a touch screen display 34. See para. 53 – emphasis added.
At an optional step 228 of FIG. 3, which is indicated as an optional step by dashed lines, the process 200 may be configured to include generating or providing a transaction authenticator associated with the transaction identifier provided at step 226. The transaction authenticator may be configured as one of or a combination of a character string of one or more alpha-numeric or special characters, a datum or an electronic signal transmittable from the user device, a datum or an electronic signal generated by the user device, or as a user instruction. These examples are not intended to be limiting in scope, and it is understood that a transaction identifier could be configured in any form which may be input into any ATM interface by, for example, the user or the mobile user device 20. The transaction authenticator may be a PIN, challenge, OTP or a dynamic value provided to the user or user device by any suitable means. For example, the transaction authenticator may be a PIN or challenge generated by the provider system and provided to the mobile user device 20 as a SMS text message, voice mail, email or other means. The transaction authenticator may be a dynamic value generated, for example, using a key or secret and algorithm shared with a DVG 26 on the mobile user device 20 and the provider system 50, in the present example. The transaction authenticator may be an instruction to the user, for example, to generate an authenticator value using a DVG 26 on the mobile user device 20, or to input to the ATM 30, through a device 20 keypad or directly, the amount of the transaction for use as an authenticating value. See para. 56 – emphasis added.
Varadarajan discloses a method comprising receiving payment authorization data from a mobile wallet app on a mobile device. (see para. 53). Varadarajan discloses a method comprising receiving, via the at least one user interface (device keypad) a currency request including an amount of currency requested (amount of the transaction). See para. 56. Varadarajan does disclose a dual-input approach (i.e., payment authorization from mobile wallet app plus currency request amount via user interface).
Applicant argues that the previously asserted prior art (Varadarajan, Aabye and Kay) fails to teach or suggest the “tokenized data processing sequence” of the claimed invention. See Arguments, p. 7.
Specifically, Applicant argues:
The claims recite a specific sequence where tokenized bankcard data is first created by the bankcard issuer computing system, then received by the token service provider, then translated back to a standardized card number. This specific tokenization/detokenization workflow across multiple entities (bankcard issuer --terminal --token service provider --bankcard issuer) is not fully taught by the combination. See Arguments, p. 7.
The Examiner respectfully disagrees.
As a preliminary matter, Examiner notes that the system claims (Claims 16 and 18-20) do not recite a system tokenizing or detokenizing any data. The system claim merely receives and transmits data wherein the data is tokenized data.
The claim elements of the data being tokenized data pertain to nonfunctional descriptive material and are not functionally involved in the steps recited. The system merely receives and transmits the data, whether tokenized or not tokenized. Thus, this descriptive material will not distinguish the claimed invention from the prior art in terms of patentability. See MPEP §2111.05 (III).
The system claims do not recite a bankcard issuer.
The method claim (Claims 1, 4, 5 and 7) do not recite that the data is transmitted from the token service provider to the bankcard issuer. The claims, as written, recite that the token service provider detokenizes the tokenized data.
Assuming that the claims, as written, recited transmitting the detokenized data from the token service provider to the bankcard issuer computing system, then the data has gone full circle. That would mean that the bankcard issuer tokenized the original data (i.e. the original data containing the standardized card number) and the bankcard issuer received the detokenized data (i.e., the original data containing the standardized card number).
Applicant argues that improper combination of references as the Examiner has failed to demonstrate “that a person of ordinary skill in the would be motivated to combine these specific elements in the particular sequence claimed.” See Arguments, p. 8.
The Examiner respectfully disagrees.
The courts have stated that “[a] suggestion, teaching, or motivation to combine the relevant prior art teachings does not have to be found explicitly in the prior art, as the teaching, motivation, or suggestion may be implicit from the prior art as a whole, rather than expressly stated in the references...The test for an implicit showing is what the combined teachings, knowledge of one of ordinary skill in the art, and the nature of the problem to be solved as a whole would have suggested to those of ordinary skill in the art… there must be some articulated reasoning with some rational underpinning to support the legal conclusion of obviousness.” See In re Kahn, 78 USPQ2d 1329, 1336 (Fed. Cir. 2006).
Examiner asserts that he can and/or has provided such “articulated reasoning” to support the legal conclusion of obviousness.
Applicant argues that the claimed invention “provides unexpected security advantages by requiring both mobile wallet app authentication and subsequent user confirmation, creating a dual-factor authentication system specifically for currency dispensing that is not suggested by the individual references or their obvious combinations.” See Arguments, p. 8.
As a preliminary matter, Examiner disputes that requesting a user confirmation (e.g. “Would you like to proceed? Yes or No”) is analogous to a layer of authentication (i.e., the process verifying the identities of people, apps or devices).
Even if requesting user confirmation was analogous to a layer of authentication, there are no unexpected security advantages of two layers of authentication over one layer of authentication. Each layer of authentication has an obvious and expected advantage. Each additional layer of authentication creates more security.
9. Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JASON M. BORLINGHAUS whose telephone number is (571)272-6924. The examiner can normally be reached on M-F 9-5.
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, RYAN D. DONLON can be reached on (571)270-3602. 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 https://ppair-my.uspto.gov/pair/PrivatePair. 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.
/Jason M. Borlinghaus/Primary Examiner, Art Unit 3692
March 6, 2026