DETAILED ACTION
Preliminary Amendment
Applicant’s preliminary amendment to the claims, abstract, and specification filed Jun. 17, 2025, is acknowledged and entered. MPEP § 714.01(e). Examiner has attached the preliminarily amended claims, abstract, and specification to this Non-Final Response.
Acknowledgements
This action is in response to Applicant’s filing on Jun. 17, 2025, as amended by preliminary amendment to the claims, abstract, and specification also filed Jun. 17, 2025, and is made Non-Final. This action is being examined by James H. Miller, who is in the eastern time zone (EST), and who can be reached by email at James.Miller1@uspto.gov or by telephone at (469) 295-9082.
Interviews
Interviews are “indispensable to advance the prosecution of a patent application.” MPEP § 713. Accordingly, the following Examiner’s guidance and suggested workflow maximizes this benefit to Applicant by: (1) avoiding back and forth telephone calls for scheduling, (2) permitting Examiner out-of-office notifications to the Applicant when sending the agenda, and (3) permitting real-time document collaboration and screen sharing.
Interviews are available by telephone or, preferably, by video conferencing using the USPTO’s web-based collaboration platform. Applicants are strongly encouraged to schedule via the USPTO Automated Interview Request (AIR) portal at http://www.uspto.gov/interviewpractice. If an interview is needed more quickly than permitted by the AIR scheduling tool, note this in the AIR remarks for consideration. The Examiner routinely considers such urgent requests when practicable.
An agenda submitted when filing the AIR is strongly encouraged, because Examiners use agendas when determining whether to grant an interview. The AIR has character limits, so send the agenda contemporaneously to James.Miller1@uspto.gov and reference the AIR.
After-Final Interviews Requests are granted only at the Examiner’s discretion and only if disposal or clarification for appeal may be accomplished with only nominal further consideration. MPEP § 713.09. An advance agenda explaining how the interview advances prosecution—e.g., through targeted arguments, identified Examiner error, or proposed claim amendments—is strongly suggested.
For GRANTED requests, expect an email within two (2) business days confirming a date/time slot and collaboration tool access instructions. For DENIED requests, the record will include an explanation for the denial.
The examiner is generally available for interviews, Monday through Friday, 10:00 a.m. to 4:00 p.m. ET.
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 .
Priority
Receipt is acknowledged of certified copies of papers required by 37 CFR 1.55.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on Jun. 17, 2025, was filed before the mailing of a first office action on the merits and therefore, is in compliance with the provisions of 37 CFR 1.97(b)(3). Accordingly, the IDS has been considered.
Claim Status
After entry of the preliminary amendment, the status of claims is as follows:
Claims 1–10 are pending and examined with Claim 1 in independent form.
Claims 1, 5, 6, 7, and 8 are presently amended.
No Claims are presently cancelled or added.
This is a first action on the merits.
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.
Claims 1–10 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.
Claims 1–10: Claim 1 recites the limitation "the payment terminal.” In Limitation B below. There is insufficient antecedent basis for this limitation in the claim. Claims 2–10 are rejected because they depend from a rejection Independent Claim.
Claims 1–10: Claim 1 recites “A system comprising a payment instrument; and a personal device” yet conditions its functions on “a first tap,” “a second tap,” and “a third tap”. In light of the specification, “tap” is only a manual act. Spec. pp. 9–10 ll. 31–4 (“A tap is to manually bring the payment instrument closed enough to the payment terminal so that a contactless communication channel can be established between the payment instrument and the payment terminal”); p. 9, ll. 29–30 (“The user may tap the payment instrument on the payment terminal to allow the start of the payment transaction at step S10.”). The specification further confirms that the tap is a user act by describing the user deciding “whether to perform whether to perform the third tap (step S20) or not to continue the financial transaction.” Spec. p. 10, ll. 22–24. No embodiment discloses a tap performed by the system. Thus, the system functions “in response to” each tap are inoperative without a user act, which improperly combines an apparatus with the method of using it, which creates confusion as to when direct infringement occurs. MPEP § 2173.05(p)(II) (citing In re Katz Interactive Call Processing Patent Litigation, 639 F.3d 1303, 1318 (Fed. Cir. 2011); IPXL Holdings v. Amazon.com, Inc., 430 F.3d 1377, 1384 (Fed. Cir. 2005)). Reading “tap” as an automated act absent a user performing the tap would improperly import into the claim a meaning the specification nowhere supports. Claim 2 is independently rejected for the same reasoning as in Independent Claim 1 because the claim requires the user act by reciting detecting sensor activation “during the first tap.” Claim 7 is independently rejected for the same reasoning as in Independent Claim 1 because the claim recites that "said security policy specifies that the payment instrument should have received an acknowledgement data generated by the personal device after capturing from the user an agreement entry reflecting acknowledgement of awareness of the subset by the user," which recites a method step performed by the user (the user's entry of an agreement reflecting awareness of the subset) within an apparatus claim. As with the recited taps, the specification confirms this is an affirmative user act for which no automated alternative is disclosed: the personal device "provides the user 50 ... with the subset 31," whereupon the user "can make the decision whether to perform the third tap ... or not to continue the financial transaction" (Spec. p. 10, ll. 14–24), and the agreement entry is captured "from the user 50 through a physical user interface of the personal device" (Spec. p.17, l.28–p.18, l.5)). Claims 2–10 are rejected based on their dependent to the rejected Independent Claim 1.
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–10 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., an abstract idea) without significantly more.
Analysis
Step 1: Claims 1–10 are directed to a statutory category. Claims 1–10 recite a “system” and are therefore, directed to the statutory category of a “machine.”
Representative Claim
Claim 1 is representative [“Rep. Claim 1”] of the subject matter under examination. Normal font is used for limitations that recite the judicial exception. Bold font is used to indicate additional elements evaluated under Step 2A, Prong Two (practical application) and Step 2B (significantly more). Italics font is used where necessary to identify intended use limitations1 and underline font is used, as needed, in further describing the judicial exception. Each limitation is identified by a letter designator for use as a shorthand notation when analyzing/referencing each limitation. Rep. Claim 1 recites:
[A] 1. A system comprising a payment instrument; and a personal device, wherein the payment instrument is assigned to a user,
[B] the payment instrument is configured to get a transaction data from the payment terminal in response to a first tap with the payment terminal leading to the start of a financial transaction;
[C] wherein the payment instrument comprises a preset parameter indicating whether a three-tap option is enabled and is configured to monitor the parameter during the first tap; and
[D] wherein, if the payment instrument detects that the parameter indicates that the three-tap option is enabled, the payment instrument is configured:
[E] to record a first indicator indicating that the financial transaction is in progress;
[F] in response to a second tap with a personal device, to send a subset of the transaction data to the personal device and to record a second indicator indicating that the payment instrument sent the subset to the personal device,
[G] in response to a third tap with the payment terminal, to use said first and second indicators for performing a check specified by a security policy stored in the payment instrument, said security policy specifying that the financial transaction should be in progress and said subset should have been sent to the personal device;
[H] in case of successful check, to continue treatments required by the financial transaction, and in case of unsuccessful check, to reject the financial transaction;
[I] wherein the payment instrument comprises a first key and the personal device comprises a second key, both said first and second keys defined during a pairing operation;
[J] in response to the second tap, the payment instrument and the personal device are configured to establish a secure channel using both said first and second keys; and
[K] wherein the payment instrument and the personal device are configured to exchange data through the secure channel.
Claims are directed to an abstract idea exception.
Step 2A, Prong One: Rep. Claim 1 recites “[B] … get a transaction data … in response to a first tap … leading to the start of a financial transaction;” “[C] … indicat[e] whether a three-tap option is enabled and is configured to monitor … during the first tap; “[D] … detects that … the three-tap option is enabled;” “[E] record a first indicator indicating that the financial transaction is in progress;” “[F] in response to a second tap … send a subset of the transaction data … and [ ] record a second indicator indicating that … the subset [is sent];” “[G] in response to a third tap … use said first and second indicators for performing a check … that the financial transaction should be in progress and said subset should have been sent … ;” [H] in case of successful check, to continue treatments required by the financial transaction, and in case of unsuccessful check, to reject the financial transaction.” The limitations in normal font, taken together, recite the fundamental economic practice commercial interaction of verifying and authorizing a “financial transaction” before completing it, which recites a sales/financial transaction and its authorization which is a certain method of organizing human activity. MPEP § 2106.04(a)(2)(II)(A), (B).
Step 2A, Prong Two: The additional elements identified in Rep. Claim 1, considered individually and as an ordered combination, do not integrate the abstract idea exception into a practical application. MPEP § 2106.04(d).
The additional elements are limited to the computer components and indicated in bold, supra. The additional elements are: A system comprising a payment instrument comprising a preset parameter, a first key and storing a security policy; a personal device comprising a second key; payment terminal; said first and second keys defined during a pairing operation; establish[ing] a secure channel using both said first and second keys; and exchang[ing] data through the secure channel. The specification describes the payment instrument as a smart card having a secure element 17 including both a hardware processor and a non-volatile memory. Spec. p. 13, ll. 28–29. The specification describes the personal device as “a commercial off-the shelf smartphone comprising a memory 23 storing a Point-Of-Sale terminal software application 24.” Spec. p. 14, ll. 17–19.
The additional elements do not improve the functioning of a computer or other technology. MPEP § 2106.05(a).
A claim improves technology only when it recites a specific improvement to the way a computer itself operates, not merely the application of an existing process using a computer. MPEP § 2106.05(a) (citing Enfish, LLC v. Microsoft Corp., 822 F.3d 1327, 1336 (Fed. Cir. 2016)). Here, the recited functions (recording (storing) indicators, sending (transmitting) a subset of transaction data, applying rules of a security policy, and accepting or rejecting a transaction (transmit or not)) are functions that do not alter the operation of the underlying hardware. Because the claimed components perform only their ordinary functions of recording (storing), transmitting, and comparing data, the computer is not being improved and is mere used as a tool to perform the abstract idea.
The specification confirms this characterization by describing the advantages of the claimed system in terms of business and security outcomes (“a hacked or fake payment terminal cannot cheat the user,” “the duration of the whole payment transaction remains reasonable for the user and easy to perform”), rather than in terms of any specific technical improvement to the computer, mobile device, or network infrastructure itself. Spec. p. 18, ll. 25–26; p. 19, ll. 7–9. The specification does not describe any specific technical improvement to contactless communication system or protocols, the secure element, the cryptographic keys, or the secure channel, but instead recites these only at a high functional level using exemplary language. Spec. p. 8, ll. 8–24, p. 13, ll. 1–14, p. 14, ll. 1–3. Thus, any improvements describe business or security outcomes, not technical improvements to the computers themselves.
The recitation of a “first key” and “second key” and “establish[ing] a secure channel using both said first and second keys” does not amount to a technical improvement. The specification describes these keys as conventional cryptographic keys that “may be symmetric keys or based on a public/private key pair” and that are merely “defined and stored during a prior pairing operation between the payment instrument and the personal device” after the devices “automatically establish a secure channel using both the first and second keys.” Spec. p. 13, ll. 4–7, 10–11. The specification teaches no improvement in any encryption algorithm, key-exchange protocol, or pairing mechanism and instead applies conventional cryptographic pairing to secure the transmission of the subset of transaction data. Spec. p. 13, ll. 4–7, 10–11; p. 14. ll. 4–9. Using established encryption to protect data transmitted in furtherance of the abstract idea is the use of computers as a tool and does not integrate the exception into a practical application. MPEP § 2106.05(a), (f).
To the extent the claimed invention is asserted to provide a technical solution, that solution is not commensurate with the scope of the claims. The specification describes the alleged technical solution as a particular sequence of operations: (1) the personal device "provides the user 50 of the payment instrument with the subset 31" (Spec. p. 10, ll. 15–16) so the cardholder can verify the true transaction parameters before deciding whether to continue, and the payment instrument requires "an acknowledgement data (32) generated by the personal device after capturing from the user an agreement entry (38) reflecting acknowledgement of awareness of the subset by the user" before continuing (Spec. p. 12, ll. 24–27); (2) “the payment instrument uses the first indicator 11 to link the first and third taps" (Spec. p. 15, ll. 27–28) and enforces a security policy " implemented as a set of rule(s)" (Spec. p. 16, ll. 23–24), a first rule of which requires that "both the financial transaction should be in progress and said subset 31 should have been sent to the personal device to pursue the transaction" (Spec. p. 10, ll. 5–8); and (3) that security policy further requires that "the first identifier should be equal to the second identifier" (Spec. p. 12, ll. 10–11) so the first and third taps occur with the same terminal, and that "the difference between the first and second timestamps should be less than a preset duration 18" (Spec. ¶. 12, ll. 19–21) so the taps occur within a limited time, whereby "a hacked or fake payment terminal cannot cheat the user by displaying an amount different from the transaction amount sent to the payment instrument" (Spec. p. 18, ll. 25–28). The claims, however, do not capture this solution. The claims do not recite that the personal device displays or presents the subset to the user, or that continuation is conditioned on acknowledgement data reflecting the user's awareness of the subset; do not recite that the verified subset includes the payment amount such that the displayed-versus-charged discrepancy is actually detected; and do not recite that the security policy compares the first and second terminal identifiers and enforces a preset-duration time window between the first and third taps such that a terminal attack is actually detected and rejected. Notably, these verification, acknowledgement, identifier-match, and timestamp-window features appear only in dependent claims 7–8 and 5–6, respectively, and are absent from independent claim 1. Instead, the claims recite the asserted anti-fraud verification, anti-relay, and anti-substitution protections as results obtained on generic components (i.e., a smart card, a personal device, and a paired secure channel.) Under MPEP § 2106.05(a), the claims must recite the improvement with sufficient specificity to reflect how the improvement is achieved, rather than claiming the desired outcome using generic components.
The additional elements do not apply the abstract idea with a particular machine.
Although the claims recite specific hardware components (i.e., a payment instrument/smart card, a personal device/smartphone, and payment terminal/SoftPOS), these components are recited at a high functional level and perform only their generic functions of receiving, transmitting, storing, and processing data. Spec. p. 8, ll. 18–31; p. 9, ll. 1–4, p. 14, ll. 10–19. A machine is “particular” only when it imposes a meaningful limit on the claims scope. MPEP § 2106.05(b). Here, any general-purpose contactless smart card, any general-purpose smartphone, and any commercial off-the-shelf payment terminal would satisfy the claim’s hardware requirements, which confirms that the hardware components are generic rather than “particular.” MPEP § 2106.05(b). The specification describes each computer component using broad, open-ended language (“for instance,” “may be”) without restricting the claimed hardware to any particular design, configuration, or architecture. Spec. p. 8, ll. 18–24; p. 14, ll. 17–22.
The additional elements are mere instructions to apply the abstract idea exception, MPEP § 2106.05(f); (2) generally link the judicial exception to a particular technological environment, MPEP § 2106.05(h); and/or (3) are insignificant extra solution activity; MPEP § 2106.05(g).
Regarding the additional elements, Applicant’s Specification does not otherwise describe them with specificity beyond exemplary language and instead describes them as a general-purpose computer, as a part of a general-purpose computer, or as any known and exemplary (generic) computer component known in the prior art. The specification’s own broad, exemplary characterization confirms that these components are not described in a manner that would impose any specific technical limitation that would integrate the abstract idea into a practical application. The specification failure to describe these components in any detail beyond exemplary language is itself an admission that the components are so well known to those of ordinary skill in the art that no explanation is needed under 35 U.S.C. § 112(a). See, Lindemann Maschinenfabrik GMBH v. Am. Hoist & Derrick Co., 730 F.2d 1452, 1463 (Fed. Cir. 1984) (citing In re Meyers, 410 F.2d 420, 424 (CCPA 1969) (“[T]he specification need not disclose what is well known in the art”). E.g., Spec. p. 7, ll. 22–24; p. 8, ll. 8–24.
The generic processor of the secure element, here, performs calculations (functions) and executes instructions that are programmed by software directed to the abstract idea. Spec. p. 8, ll. 8–18. This is a computer doing what it is designed to do—performing directions it is given to follow, and whose directions are directed to the abstract idea.
Limitations B–H describe the payment instrument and personal device performing the steps of the claimed invention, which represents the abstract idea exception itself on a general-purpose computer. Performing the steps of the abstract idea exception using a computer, merely adds a general-purpose computer after the fact to an abstract idea exception without imposing any meaningful technical limitations. MPEP § 2106.05(f)(2). Alternatively, the claim generically recites an effect of the abstract idea without specifying how the computer achieves that effect in any technically meaningful way. MPEP § 2106.05(f)(3).
Therefore, the claim as a whole, considering the additional elements individually and as an ordered combination, amounts to no more than mere instructions to apply the abstract idea using generic computer components and is not a practical application. MPEP § 2106.05(f). The additional elements do not integrate the abstract idea exception into a practical application because they do not impose any meaningful limits on the abstract idea exception. Accordingly, Rep. Claim 1 is directed to an abstract idea.
The claims do not provide an inventive concept.
Step 2B: Rep. Claim 1 fails Step 2B because the claim as a whole, even when considering the additional elements individually and in combination, does not amount to significantly more than the abstract idea. MPEP § 2106.05. The additional elements (i.e., A system comprising a payment instrument comprising a preset parameter, a first key and storing a security policy; a personal device comprising a second key; payment terminal; said first and second keys defined during a pairing operation; establish[ing] a secure channel using both said first and second keys; and exchang[ing] data through the secure channel), are each well-understood, routine, and conventional (“WRC”) computer components and functions in the relevant field, as evidenced by Applicant’s own disclosure2.
Applicant’s Specification expressly characterizes the hardware as conventional, off-the shelf (“COTS”) equipment.
(1) a payment instrument comprising a preset parameter, a first key and storing a security policy is WRC in the financial technology field. Spec. p. 8, ll. 8–24.
(2) a personal device comprising a second key is WRC. Spec. p. 8, ll. 18–24.
(3) said first and second keys defined during a pairing operation are WRC. Spec. p. 13, ll. 1–14. The specification describes these keys as conventional cryptographic keys that “may be symmetric keys or based on a public/private key pair” and that are merely “defined and stored during a prior pairing operation between the payment instrument and the personal device” after the devices “automatically establish a secure channel using both the first and second keys.” Spec. p. 13, ll. 4–7, 10–11.
(4) payment terminal is WRC. Spec. p. 14, ll. 17–22 (“The payment terminal may be a commercial off-the-shelf smartphone … storing a Point-Of-Sale terminal software application 24. Alternatively, the payment terminal conventional Point-Of-Sale terminal or an Teller Machine (ATM).”)
(5) establish[ing] a secure channel using both said first and second keys; and exchang[ing] data through the secure channel is WRC. Spec. p. 13, ll. 1–14.
The Specification further confirms that the functions of receiving, storing, transmitting, and processing data are normal, well-understood operations of generic computer systems, and the steps may be performed in any order or concurrently. See, e.g., Spec. p. 8, ll. 8–17; p. 9, ll. 5–10; p. 13, ll. 1–14.
The combination is also WRC at the high level of generality recited:
The combination of the additional elements is likewise WRC. A combination of individually well-understood, routine, and conventional elements does not provide an inventive concept unless the combination itself produces an unconventional result or is applied in an unconventional manner. MPEP § 2106.05(d)(2). Here, the combination performs each step in exactly the manner described as conventional throughout Applicant’s own Specification. Spec. p. 8, ll. 8–24; p.9, ll.20–p.10, ll.13 There is no indication that the combination of these elements operates in an unconventional manner or produces a result that is other than what would be expected from the generic application of these individual components.
Unlike BASCOM, where the claims recited a specific non-conventional arrangement of installing a filtering tool at a specific network location (an ISP server) rather than on individual end-user devices, Rep. Claim 1 does not recite how the elements are combined in a non-conventional way. The claims recite each element at a high level of generality without specifying the particular arrangement or order that constitutes the alleged improvement. At the high level of generality recited, the combination is WRC. Any BASCOM argument fails because nothing in Applicant’s Specification describes a non-conventional ordered arrangement of components that is then recited in the claims. Rep. Claim 1 recites only the abstract steps of recording indicators, sending a subset of transaction data, performing a rules-based check, and continuing ore rejecting the transaction, without incorporating any specific technical details for how these elements are performed. A non-conventional arrangement that is described but not claimed cannot supply the inventive concept at Step 2B. Because the claims here recite only generic components performing generic functions at a high level of generality, the claim cannot be an improvement to the computer or another technology. MPEP § 2106.05(f). No inventive concept is present under Step 2B. MPEP § 2106.05(d).
Under the 2019 PEG, a conclusion that an additional element is insignificant extra-solution activity in Step 2A should be re-evaluated in Step 2B. Reevaluated under Step 2B, the data transmission limitations (i.e., “send a subset of the transaction data to the personal device” and “exchange data through the secure channel”) are no more than well-understood, routine, and conventional data-transmission activity in the field of electronic transaction processing and do not provide an inventive concept. These limitations merely recite the smart card transmitting a subset of transaction data to a smartphone over a conventional contactless channel. The specification describes these operations as occurring within conventional contactless payment environment implemented using a generic smartcard, smartphone, and payment terminal, and does not indicate that these functions are performed in any unconventional way. Neither the Specification nor the record identifies these limitations as providing any improvement to the functioning of the computer itself, to the underlying contactless communications or cryptographic technology, not has Applicant provided any evidence that such operations were not well-understood, routine, and conventional in the field at the time of the invention. In view of this disclosure and the absence of contrary evidence, and consistent with MPEP § 2106.05(d) and USPTO guidance interpreting Berkheimer, these limitations are found to be WRC extra-solution activity in the field of electronic payment transactions and do not supply an inventive concept.
Accordingly, the additional elements of Rep. Claim 1 have been recognized, based on Applicant’s own disclosure, as WRC activity in the field. MPEP § 2106.05(d). These elements do no more than “apply” the recited abstract idea(s) using known computer and computer-related components. See also Step 2A, Prong Two, supra.
Dependent Claims Not Significantly More
The dependent claims have been given the full two-part analysis including analyzing the additional limitations both individually and in combination with the elements of the independent claims. Each dependent claim incorporates all the limitations of its parent Independent Claim and therefore recites the same abstract idea. The additional limitations recited in the dependent claims do not integrate the abstract idea exception into a practical application under Step 2A, Prong Two, and do not amount to significantly more than the abstract idea under Step 2B, for the following reasons:
Dependent Claims 2 and 3 add only a generic, conventional input component recited at a high level of generality and described in the specification using exemplary "may be" language, with no improvement to the sensor or to any technology. Spec. p. 11, ll. 5–13, 24–30; p. 12, ll. 1–11; p. 16, ll. 14–18. A generic sensor that merely toggles a parameter is a WRC component that neither integrates the abstract idea into a practical application nor supplies an inventive concept.
Dependent Claim 4 is insignificant post-solution data housekeeping (erasing data flags) performed by a generic processor and described as a conventional operation. Spec. p. 11, ll. 1–4. It does not integrate the abstract idea into a practical application and is well-understood, routine, and conventional.
Dependent Claims 5 and 6 merely narrow the abstract idea exception by adding comparison rules (matching identifiers; comparing a time difference to a threshold) that can be performed by observation and judgment, applied on generic components. An inventive concept or practical application cannot be furnished by an abstract idea exception itself. MPEP §§ 2106.05(I), 2106.04(d)(III).
Dependent Claims 7 and 8 further specify the content of the data and the verification rule and recite data gathering/transmitting data, which is insignificant extra-solution activity on generic components. They neither integrate the abstract idea into a practical application nor amount to significantly more.
Dependent Claims 9 and 10 merely name generic, conventional devices at a high level of generality, described in the specification with exemplary "for instance" language, and do not impose any particular machine or technical improvement. Generically reciting the type of hardware on which the abstract idea is performed does not integrate it into a practical application and is WRC.
Combined Consideration. The additional limitations of dependent Claims 2–10, considered individually and in ordered combination with the limitations of their respective independent claims, do not integrate the abstract idea into a practical application and do not amount to significantly more.
Conclusion
Claims 1–10 are therefore drawn to ineligible subject matter as they are directed to an abstract idea without significantly more. The analysis above applies to all statutory categories of invention. As such, the presentment of Rep. Claim 1 otherwise styled as another statutory category is subject to the same analysis.
Examiner Statement of Prior Art—No Prior Art Rejections
Based on the prior art search results, none of the references, alone or in combination, fails to teach or suggest this combination of Independent Claim 1: “where in the payment instrument comprises a preset parameter indicating whether a three-tap option is enabled and is configured to monitor the parameter during the first tap; and wherein, if the payment instrument detects that the parameter indicates that the three-tap option is enabled, the payment instrument is configured: to record a first indicator indicating that the financial transaction is in progress; in response to a second tap with a personal device, to send a subset of the transaction data to the personal device and to record a second indicator indicating that the payment instrument sent the subset to the personal device, in response to a third tap with the payment terminal, to use said first and second indicators for performing a check specified by a security policy stored in the payment instrument, said security policy specifying that the financial transaction should be in progress and said subset should have been sent to the personal device; in case of successful check, to continue treatments required by the financial transaction, and in case of unsuccessful check, to reject the financial transaction.”
FOR: Eur. Pat. Pub. No. EP 4 053 772 A1 discloses much the system architecture. FOR discloses a payment instrument, payment terminal, and separate personal device, the first-tap acquisition of transaction data, the paired first and second keys, and the secure channel data exchange. E.g., Fig. 2. However, FOR does not disclose a preset three-tap option monitored during the first tap, the recording of "a first indicator" and "a second indicator" across a first and second tap, or a third tap upon which the instrument uses "said first and second indicators" to perform an on-card "check specified by a security policy" requiring both that "the financial transaction should be in progress" and that "said subset should have been sent to the personal device."
Naccache et al. (U.S. Pat. Pub. No. 2023/0004965) discloses a policy or profile-based check within a two-party card-and-terminal exchange, but does not disclose a separate personal device, a multi-tap sequence, nor the linking of taps by means of the recited first and second indicators.
Accordingly, no reference teaches the combination by which the payment instrument uses a preset three-tap option, records two distinct indicators across successive taps, and conditions continuation on the transaction based on an on-card security policy check that uses both indicators. pre-computing and string a retry decision in memory before a transaction failure such that the decision is later retrieved without additional processing delay.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JAMES H MILLER whose telephone number is (469)295-9082. The examiner can normally be reached M-F: 10- 4 PM (EST).
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, Bennett M Sigmond can be reached at (303) 297-4411. 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.
/JAMES H MILLER/Primary Examiner, Art Unit 3694
1 Statements of intended use fail to limit the scope of the claim under BRI. MPEP § 2103(I)(C).
2 See Changes in Examination Procedure Pertaining to Subject Matter Eligibility, Recent Subject Matter Eligibility Decision (Berkheimer v. HP, Inc.), 3-4, https://www.uspto.gov/sites/default/files/documents/memo-berkheimer-20180419.PDF (April, 18, 2018) (That additional elements are well-understood, routine, or conventional may be supported by various forms of evidence, including "[a] citation to an express statement in the specification or to a statement made by an applicant during prosecution that demonstrates the well-understood, routine, conventional nature of the additional element(s).").
Prosecution Insights