DETAILED ACTION
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 .
Status of the Application
The office action is being examined in response to the amendments submitted by the applicant on November 13, 2025
Claims 1, 8, and 17 have been amended and are hereby entered.
Claims 3-5, 10, and 20 are cancelled.
Claims 1-2, 6-9, and 11-19 are pending and have been examined.
This action is made FINAL.
The examiner would like to note that this application is now being handled by examiner Michael Anderson.
Response to Arguments
I. REGARDING THE EXAMINER INTERVIEW
The Examiner acknowledges the telephonic interview conducted on November 4, 2025. No agreement was reached regarding the pending rejections.
II. RESPONSE TO ARGUMENTS REGARDING 35 U.S.C. § 101
Applicant’s arguments filed November 13, 2025 have been fully considered but are not persuasive.
A. The Claims Recite an Abstract Idea
Applicant argues that the Office provided only a “conclusory analysis” in identifying the abstract idea. The Examiner respectfully disagrees. As set forth in the Office Action, the claims recite the abstract idea of identity verification to authorize a transaction — i.e., sending an identity challenge to a user, receiving a credential response, validating the credential, and authorizing a transaction. This is a fundamental commercial and security practice that falls squarely within the grouping of certain methods of organizing human activity (commercial interactions, security arrangements).
The Office Action identified the specific claim limitations that recite the abstract idea: transmitting an authentication request, opening a communication field, receiving an authentication credential in response to a challenge, validating the request, and performing a transaction. These steps, at their core, describe a challenge-response identity verification process — a longstanding practice performed through various conventional means before the advent of modern computing.
B. The Claims Do Not Integrate the Abstract Idea into a Practical Application
Applicant argues that the claims integrate the abstract idea into a practical application because “SMS and NFC technology are used for identity verification with a URL linked to a website or mobile application” and cites the specification at ¶¶ [0022]-[0023].
The Examiner respectfully disagrees. The mere recitation of specific technologies, (SMS, NFC, URLs) as the means by which the abstract identity verification process is carried out does not constitute integration into a practical application. Under the 2019 PEG and MPEP § 2106.05(f), merely applying an abstract idea using generic, well-known technological tools does not integrate the exception into a practical application.
Specifically:
SMS messaging is a well-known, conventional data transmission technology. Using SMS to deliver an authentication request is a routine application of existing messaging infrastructure.
URLs directing users to websites or applications is the fundamental, conventional function of URL technology since the early 1990s.
NFC communication between a contactless card and a mobile device is a well-established, conventional technology. The claim does not recite any improvement to NFC technology; rather, it uses NFC as a conduit for the abstract identity verification.
The combination of SMS + URL + NFC is recited at a high level of generality without specifying any particular unconventional implementation. The claims do not recite the specific cryptographic operations, key diversification protocols, session key generation, MAC computation, or APDU-level structures described in the specification (¶¶ [0053]-[0067]) that might constitute a technical improvement.
Applicant cites MPEP § 2106.05(d)(I), stating the claims offer “a technological solution to a technological problem.” However, the alleged improvement described in the specification — that NFC’s close-proximity requirement makes interception infeasible (¶ [0023]) — is an inherent characteristic of NFC technology, not a technical improvement made by the claimed invention to that technology. The claims merely use NFC for authentication; they do not improve NFC or any other technology. See MPEP § 2106.05(a) (the improvement must be to the functioning of the computer or to another technology, not merely using a computer or technology as a tool).
Furthermore, Applicant’s argument regarding “preemption” is noted but is not dispositive. While preemption is the underlying concern of § 101, the two-part Alice/Mayo framework is the analysis tool; the absence of complete preemption does not establish eligibility.
C. The Amendments Do Not Overcome the § 101 Rejection
Applicant has amended the claims to specify that the authentication request is “contained in a short message service (SMS) message” and that the URL is “configured to direct the user device to one of a website, a website application, or a mobile application.” These amendments merely add further specificity to the type of generic technology employed (SMS as the delivery channel, URL directing to an application), but do not change the fundamental nature of the claimed process as an abstract identity verification procedure implemented using conventional technologies.
The 2019 PEG instructs that specifying the type of generic technology used does not transform an abstract idea into a patent-eligible claim. See MPEP § 2106.05(h) (field-of-use limitations); See also Ultramercial, Inc. v. Hulu, LLC, 772 F.3d 709, 716 (Fed. Cir. 2014) (specifying Internet as medium for performing abstract idea does not transform claim).
The § 101 rejection is MAINTAINED.
III. RESPONSE TO ARGUMENTS REGARDING PRIOR ART REJECTIONS
Specifically, Applicant’s arguments are directed to the previous anticipation rejection under 35 U.S.C. § 102 based on Osborn alone. Applicant argues that Osborn fails to disclose a “uniform resource locator (URL)” and “fails to disclose this URL initiated flow for authentication starting with a SMS message.” The Examiner does not disagree that Osborn alone does not explicitly teach these features. However, the claims as currently amended are now rejected under 35 U.S.C. § 103 as being unpatentable over Osborn (US 10,489,781 B1) in view of Rule (US 2020/0106614 A1) and further in view of Rule '300 (US 2021/0192300 A1). The limitations that Applicant identifies as missing from Osborn are taught by the secondary references Rule and Rule '300, as set forth in detail in the new § 103 rejection above.
Because Applicant’s amendments necessitated the new ground of rejection under § 103, and because Applicant’s remarks do not address the combined teachings of Osborn, Rule, and Rule '300 as applied in the new rejection, Applicant’s arguments are moot with respect to the current rejection.
The § 103 rejection is MAINTAINED.
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-2, 6-9, and 11-19 are rejected under 35 U.S.C. § 101 because the claimed invention is directed to an abstract idea without significantly more.
Independent Claim 1
Step 1 – Statutory Category:
Claim 1 is directed to a system comprising a card, a user device, and a server with a memory and processor. The claim falls within the statutory category of a machine (apparatus). However, the claim is further analyzed under Step 2A.
Step 2A, Prong 1 – Judicial Exception:
Claim 1 recites an abstract idea falling within the grouping of certain methods of organizing human activity — specifically, commercial interactions and/or security arrangements involving identity verification to authorize a transaction.
The following limitations, under their broadest reasonable interpretation, recite the abstract idea of authenticating a user’s identity and performing a transaction upon successful validation:
“transmit an authentication request to the user device…”
“open…a communication field between the user device and the card…”
“receive an authentication credential from the card in response to an authentication challenge contained in the URL”
“validate the authentication request”
“perform a transaction”
The core concept is: send an identity challenge to a user, receive a credential response, validate the credential, and authorize a transaction. This is a fundamental identity verification process — a longstanding commercial and security practice — that has been performed through various conventional means (e.g., presenting identification cards to a clerk, challenge-response protocols in banking). See Alice Corp. Pty. Ltd. v. CLS Bank Int’l, 573 U.S. 208 (2014) (intermediated settlement); Intellectual Ventures I LLC v. Capital One Bank (USA), 792 F.3d 1363 (Fed. Cir. 2015) (verifying identity and authorizing transactions).
Step 2A, Prong 2 – Integration into a Practical Application:
The claim recites the following additional elements beyond the abstract idea:
A card
A user device
A server comprising a memory and a processor
A short message service (SMS) message containing a URL
The URL directing the user device to one of a website, a website application, or a mobile application
A communication field between the user device and the card
A command to open the communication field contained in the URL
These additional elements do not integrate the abstract idea into a practical application because:
The server, processor, and memory are recited at a high level of generality and serve merely as generic computing components that implement the abstract idea. See Alice, 573 U.S. at 225 (“merely requiring generic computer implementation fails to transform [the] abstract idea into a patent-eligible invention”).
The card is recited generically without specifying any particular structural or functional improvement. The specification discloses it as a conventional contactless card (¶¶ [0042]-[0052]).
The user device is described generically — the specification identifies it as any smartphone, tablet, or computer (¶ [0026]).
Transmitting the authentication request via SMS containing a URL amounts to mere data transmission using well-known messaging technology. This is insignificant extra-solution activity (data gathering/outputting) and a generic technological environment..
Directing the user device to a website or mobile application via a URL is a high-level use of URL technology and represents a field-of-use limitation or generic linking of the abstract idea to a particular technological environment.
Opening a communication field between the user device and the card (where the command is in the URL) amounts to establishing a generic NFC/Bluetooth/RFID connection — a conventional operation for any NFC-enabled device pair. The claim does not recite any improvement to the communication field technology itself; rather, it uses the communication field as a conduit for the abstract identity verification process.
Receiving an authentication credential from the card in response to an authentication challenge recites the concept at a result-oriented, functional level without specifying the particular cryptographic operations, key diversification, session key generation, MAC computation, or APDU structures that the specification describes (¶¶ [0053]-[0067], [0081]-[0087]) as the actual technical mechanism. The claim merely states what is done (challenge-response), not how it is done at a technical level that would constitute a technological improvement.
The claim does not recite: (1) an improvement to computer functionality or to NFC technology; (2) a particular machine beyond generic components; (3) a transformation of a particular article; or (4) any other meaningful limitation beyond generally linking the use of the judicial exception to a computerized/NFC environment. The alleged improvement described in the specification — that NFC’s close-proximity requirement makes interception infeasible (¶ [0023]) — is an inherent characteristic of NFC technology, not a claimed technical improvement made by the invention to that technology. The claim merely uses NFC for authentication; it does not improve NFC.
Accordingly, claim 1 is directed to the abstract idea.
Step 2B – Significantly More:
The additional elements, taken individually and in ordered combination, do not amount to significantly more than the abstract idea because they constitute well-understood, routine, and conventional (WURC) activities:
Servers, processors, and memory performing computational tasks — WURC. See Alice, 573 U.S. at 225; MPEP § 2106.05(d)(II) (performing repetitive calculations, storing and retrieving information in memory, receiving or transmitting data over a network).
Transmitting data via SMS — WURC. Receiving or transmitting data over a network has been recognized as conventional computer function. See Symantec, 838 F.3d at 1321; OIP Techs., Inc. v. Amazon.com, Inc., 788 F.3d 1359, 1363 (Fed. Cir. 2015); buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355 (Fed. Cir. 2014).
URL-based redirection to a website or application — WURC. URLs directing users to web content are a fundamental, well-known Internet technology in use since the early 1990s.
Opening an NFC/Bluetooth/RFID communication field between a mobile device and a card — WURC. NFC communication between contactless cards and mobile devices is well-established and conventional. The specification itself acknowledges NFC technology and its standard operations (¶¶ [0069]-[0072]) without asserting any modification to NFC protocols.
Receiving authentication credentials from a card — WURC. Contactless card authentication (e.g., EMV contactless payment protocols, ISO/IEC 14443 compliant communications) is well-known and conventional in the art.
Validating authentication and performing a transaction — WURC. Generic validation steps and transaction execution are conventional computing operations in the financial and security technology domains.
The ordered combination of elements does not add anything that is not already present when the steps are considered separately. The claim simply appends well-understood, routine, and conventional activities previously known to the industry to the abstract idea of identity verification.
Claim 1 is NOT patent eligible under 35 U.S.C. § 101.
Independent Claim 8
Step 1 – Statutory Category:
Claim 8 is directed to a method. The claim falls within the statutory category of a process. However, the claim is further analyzed under Step 2A.
Step 2A, Prong 1 – Judicial Exception:
Claim 8 recites substantially the same abstract idea as claim 1 — certain methods of organizing human activity (identity verification to authorize a commercial transaction) — expressed as method steps:
“transmitting…an authentication request…to a user device, the authentication request further comprising a uniform resource locator (URL)”
“directing…the user device to an application”
“opening a communication field between a user device and a card, wherein a command to open the communication field is contained in the URL”
“receiving…an authentication credential from the card in response to an authentication challenge contained in the URL”
“validating the authentication request”
“performing a transaction”
These limitations recite the fundamental concept of sending a challenge, receiving a response credential, validating identity, and performing a transaction — an abstract commercial/security practice.
Step 2A, Prong 2 – Integration into a Practical Application:
The additional elements in claim 8 are:
A processor (performing the transmitting, directing, and receiving)
An SMS message containing a URL
A user device
A card
A communication field (opened via a command in the URL)
For the same reasons articulated with respect to claim 1, these additional elements do not integrate the abstract idea into a practical application. The processor is recited generically, the SMS/URL mechanism is conventional data transmission, and the communication field between the device and card is a generic use of NFC technology without any claimed technical improvement. The claim recites the authentication process at a high level of abstraction — it does not specify the cryptographic protocols, key diversification, MAC generation, or other technical mechanisms described in the specification that might constitute a technical improvement.
Claim 8 is directed to the abstract idea.
Step 2B – Significantly More:
For the same reasons set forth with respect to claim 1, the additional elements in claim 8, individually and in combination, do not provide significantly more. Transmitting data via SMS, URL-based redirection, NFC communication between a card and device, and generic processor-implemented validation are all WURC activities previously known to the industry.
Claim 8 is NOT patent eligible under 35 U.S.C. § 101.
Independent Claim 17
Step 1 – Statutory Category:
Claim 17 is directed to a “computer-accessible non-transitory medium comprising computer executable instructions.” The claim falls within the statutory category of a manufacture (article of manufacture).
Step 2A, Prong 1 – Judicial Exception:
Claim 17 recites substantially the same abstract idea as claims 1 and 8 — identity verification to authorize a transaction — falling within certain methods of organizing human activity:
“transmitting…an authentication request…to a user device, the authentication request further comprising a uniform resource locator (URL)”
“directing…the user device to an application”
“opening a communication field between a user device and a card, wherein a command to open the communication field is contained in the URL”
“receiving…an authentication credential from the card in response to an authentication challenge contained in the URL”
“validating the user device”
“performing a transaction”
These are the same abstract concepts of challenge-response identity verification, constituting certain methods of organizing human activity.
Step 2A, Prong 2 – Integration into a Practical Application:
The additional elements are a non-transitory computer-readable medium, a processor, an SMS message, a URL, a user device, a card, and a communication field. For the same reasons discussed regarding claims 1 and 8, these elements do not integrate the abstract idea into a practical application. The non-transitory medium and processor are generic computing elements, and the remaining elements are conventional technology used in their ordinary capacity.
Claim 17 is directed to the abstract idea.
Step 2B – Significantly More:
For the same reasons discussed with respect to claims 1 and 8, the additional elements do not amount to significantly more. A non-transitory computer-readable medium storing instructions for execution by a processor is a generic computer implementation that does not transform the abstract idea into eligible subject matter. See Alice, 573 U.S. at 226.
Claim 17 is NOT patent eligible under 35 U.S.C. § 101.
Dependent Claims
Claims 2, 9, and 18 recite that the user device is “at least one selected from the group of a smart phone, tablet, or computer.” This merely further defines the generic user device and constitutes a field-of-use limitation that does not integrate the abstract idea into a practical application or add significantly more. See MPEP § 2106.05(h).
Claim 6 recites that the communication field is “at least one selected from the group of near field communication (NFC), Bluetooth, or radio frequency identification (RFID).” This merely identifies the type of generic communication technology and constitutes a field-of-use limitation. Specifying NFC, Bluetooth, or RFID does not alter the fundamental nature of the abstract idea or add significantly more.
Claim 7 recites that the transaction is a “financial transaction through an ATM or banking institution.” This merely narrows the type of transaction (field-of-use limitation) and does not integrate the abstract idea into a practical application or add significantly more. Indeed, narrowing the abstract idea of authentication to the financial transaction context makes the claim more directed to methods of organizing human activity, not less.
Claim 11 recites that the user device is a smart watch. This is a field-of-use limitation identifying a generic computing device and does not add a meaningful limitation.
Claims 12 and 13 recite that the transaction is a “secure access transaction for entering a living space or abode” (claim 12) or “opening one or more secure storage spaces” (claim 13). These narrow the field of use of the transaction but do not add a technical limitation that integrates the abstract idea into a practical application or provides significantly more.
Claim 14 recites that the authentication credential is a “digital signature from the card.” While this adds some specificity to the type of credential, a digital signature is a well-understood, routine, and conventional cryptographic technique. See, e.g., NIST FIPS 186 (Digital Signature Standard, first published 1994). The claim does not recite any unconventional implementation of digital signatures and thus does not amount to significantly more.
Claim 15 recites that the authentication request and credential are “transmitted and received through an application protocol data unit (APDU).” APDUs are the standard communication unit defined by ISO/IEC 7816-4 for smart card communication. This is a well-understood, routine, and conventional element of smart card technology and does not transform the claim into eligible subject matter.
Claim 16 recites additional steps of transmitting a one-time password (OTP) to the user device, receiving a passcode from the user device, validating the user, and performing a transaction. This adds a further layer of the same abstract concept — challenge-response identity verification — using OTP, which is itself a well-understood, routine, and conventional authentication technique. This does not integrate the abstract idea into a practical application or provide significantly more.
Claim 19 recites that the user device is an automated teller machine (ATM). This is a field-of-use limitation identifying a particular type of computing device and does not add significantly more.
Claims 1-2, 6-9, and 11-19 are NOT patent eligible under 35 U.S.C. § 101.
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-2, 6-9, 11-19 are rejected under 35 U.S.C. § 103 as being unpatentable over Osborn et al. (US 10,489,781 B1) (“Osborn”) in view of Rule et al. (US 2020/0106614 A1) (“Rule”) and further in view of Rule et al. (US 2021/0192300 A1) (“Rule '300”).
Claim 1
Osborn discloses a system for validating a user’s identity (Osborn, Abstract: “systems and methods for cryptographic authentication of contactless cards”), the system comprising:
“a card” — Osborn discloses a contactless card 1305 containing a processor and a memory (Osborn, col. 31:40-55: “contactless card 1305…The contactless card 1305 may include a substrate, a processor, such as an EMV chip, and a memory”; see also FIGS. 5A-5B, col. 15:1-40).
“a user device” — Osborn discloses a client device 1310 (Osborn, col. 31:55-col. 32:20: “the client device 1310 may be a computer device, or communications device including, e.g., a server, a network appliance, a personal computer, a workstation, a mobile device, a phone…any device running Google’s Android® operating system, and/or any other smartphone or like wearable mobile device”).
“a server, the server further comprising: a memory, and a processor configured to:” — Osborn discloses an authentication server 1320 comprising one or more processors coupled to memory (Osborn, col. 33:1-10: “the one or more servers may include one or more processors, which are coupled to memory”).
“transmit an authentication request to the user device, the authentication request, contained in a short message service (SMS) message,” — Osborn discloses that the authentication server 1320 transmits a request for contactless card authentication to the client device 1310, and explicitly discloses that “[t]he request may be in the form of an in-application notification, a pop-up notification, an SMS message, an email, or any other suitable notification” (Osborn, col. 34:20-30, emphasis added). Osborn further discloses that “[t]he request may explain that further authentication is needed to proceed with the requested transaction and may further prompt the cardholder to bring the contactless card 1305 into a communication field of the client device 1310” (Osborn, col. 34:30-35).
“further comprising a uniform resource locator (URL)” — Osborn does not explicitly disclose that the authentication request comprises a URL. However, Rule discloses that authentication communications for contactless card activation comprise a uniform resource locator (URL): “a uniform resource locator (URL) may be dynamically generated such that the corresponding ‘Subject’ line of an email may include the card verification value or token, including but not limited to a one-time password token” (Rule, ¶[0184]; see also ¶[0199]; claim 5: “the first set of information comprises a uniform resource locator that is dynamically generated to activate the contactless card”). Rule further discloses that the URL comprises an encrypted payload configured to authenticate the contactless card (Rule, ¶[0190]: “the payload delivered, such as 1234567, may be configured to authenticate the contactless card”; claim 1: “a third information element comprises an encrypted payload”).
“wherein the URL is configured to direct the user device to one of a website, a website application, or a mobile application” — Rule discloses that the URL is configured to direct the user device to an application: “the default email program may be launched, or an application download store may be presented to prompt the user to download and install an email program on the client device. In other examples, rather than routing the user the application download store, the user may be presented with an activation link or URL to activate the contactless card such that the payload includes the URL” (Rule, ¶[0186]; see also ¶[0201]).
“open, in response to the authentication request, a communication field between the user device and the card,” — Osborn discloses that in response to the authentication request, the cardholder brings the contactless card 1305 into the communication field of the client device 1310: “At step 1412, the cardholder may, upon receiving the request for contactless card authentication via the client device 1310, bring the contactless card 1305 into the communication field of the client device 1310” (Osborn, col. 34:40-50). Rule '300 further discloses that the mobile device can programmatically activate NFC communication: “the mobile device 110 may trigger the card reader 118 via an API call” (Rule '300, ¶[0038]).
“wherein a command to open the communication field is contained in the URL” — Osborn discloses that the authentication request prompts the cardholder to bring the contactless card into the communication field (Osborn, col. 34:25-35). Rule discloses that the URL is configured to launch an application on the client device (Rule, ¶[0186], [0201]). Rule '300 discloses that the launched application can programmatically trigger the card reader to establish the communication field: “the mobile device 110 may trigger the card reader 118 via an API call” (Rule '300, ¶[0038]). Rule '300 further discloses that authentication data can be associated with a uniform resource indicator: “the MAC cryptogram may be included with a uniform resource indicator (e.g., as a formatted string)” (Rule '300, ¶[0044]). One of ordinary skill in the art would have understood that a URL that launches an application configured to programmatically trigger NFC (as taught by Rule '300) effectively contains the command to open the communication field, because the URL initiates the chain of operations resulting in the NFC field being opened.
“receive an authentication credential from the card in response to an authentication challenge contained in the URL” — Osborn discloses receiving a MAC cryptogram from the contactless card for authentication: “the processor 1311 of the client device 1310 may verify a MAC cryptogram generated by the contactless card 1305. The processor 1311 may then communicate to the authentication server 1320 that the contactless card 1305 has been verified. Alternatively, the MAC cryptogram generated by the contactless card may be transmitted to the authentication server 1320 for verification” (Osborn, col. 35:1-15). Osborn further discloses that “[t]he MAC cryptogram may function as a digital signature for purposes of verification” (Osborn, col. 7:55-60). Rule discloses that the URL contains an encrypted payload that serves as an authentication challenge for the contactless card: “the payload delivered, such as 1234567, may be configured to authenticate the contactless card” (Rule, ¶[0190]; see also ¶[0204]: “the payload delivered…may be configured to authenticate the contactless card”).
“validate the authentication request; and” — Osborn discloses that the authentication server validates the MAC cryptogram: “If at step 1414 the contactless card is authenticated (YES), the authentication server 1320 allows the transaction at step 1418” (Osborn, col. 35:25-40).
“perform a transaction.” — Osborn discloses performing a transaction upon successful authentication: “the authentication server 1320 allows the transaction at step 1418. When the transaction is allowed, the authentication server 1320 may additionally transmit a notification to the client device 1310 informing the cardholder that the transaction has been approved” (Osborn, col. 35:30-40; see also claim 1: “authorize the transaction when the authentication signal is received”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the SMS-based contactless card authentication system of Osborn, which sends an authentication request via SMS to a client device requesting contactless card authentication, to incorporate a dynamically generated URL with an encrypted authentication payload as taught by Rule, because Rule teaches that URLs with encrypted payloads provide an efficient mechanism for contactless card authentication that can direct users to appropriate applications for completing the authentication process (Rule, ¶[0184]-[0186], [0199]-[0201]), and because both Osborn and Rule are directed to solving the same problem of secure contactless card cryptographic authentication (Osborn, col. 2:15-30; Rule, ¶[0003]-[0006]). Both references are assigned to Capital One Services, LLC and share overlapping inventors, further establishing that one of ordinary skill would look to both references when solving problems in this field.
It would have been further obvious to one of ordinary skill in the art to incorporate the programmatic NFC card reader triggering mechanism of Rule '300, which teaches that “the mobile device 110 may trigger the card reader 118 via an API call” (Rule '300, ¶[0038]) and that cryptographic authentication data may be “included with a uniform resource indicator (e.g., as a formatted string)” (Rule '300, ¶[0044]), because Rule '300 teaches that programmatically triggering the card reader via a software call provides an efficient method of initiating NFC communication for authentication purposes without requiring the user to separately navigate to an application (Rule '300, ¶[0038]), and because combining known NFC-triggering mechanisms (API call per Rule '300) with known URL-based authentication delivery (per Rule) in a known SMS-based authentication framework (per Osborn) would yield the predictable result of a server sending an SMS containing a URL that, when accessed, programmatically activates NFC communication with the user’s contactless card. See KSR Int’l Co. v. Teleflex Inc., 550 U.S. 398, 416 (2007). Rule '300 is also assigned to Capital One Services, LLC and shares overlapping inventors with Osborn and Rule.
Claim 2
Regarding claim 2, the combination of Osborn, Rule, and Rule '300 discloses the system of claim 1. Osborn further discloses:
“wherein the user device is at least one selected from the group of a smart phone, tablet, or computer” — Osborn discloses that the client device “may include an iPhone, iPod, iPad from Apple® or any other mobile device running Apple’s iOS® operating system, any device running Microsoft’s Windows® Mobile operating system, any device running Google’s Android® operating system, and/or any other smartphone, tablet, or like wearable mobile device” (Osborn, col. 12:30-40).
Claim 6
Regarding claim 6, the combination of Osborn, Rule, and Rule '300 discloses the system of claim 1. Osborn further discloses:
“wherein the communication field is at least one selected from the group of near field communication (NFC), Bluetooth, or radio frequency identification (RFID)” — Osborn discloses that “contactless card 305 may comprise one or more chips, such as a radio frequency identification chip, configured to communication via NFC or other short-range protocols. In other embodiments, contactless card 305 may communicate with client device 310 through other means including, but not limited to, Bluetooth, satellite, Wi-Fi, wired communications, and/or any combination of wireless and wired connections” (Osborn, col. 11:25-40; see also col. 4:20-25: “contactless card 105 may be in wireless communication, utilizing NFC in an example, with client device 110”).
Claim 7
Regarding claim 7, the combination of Osborn, Rule, and Rule '300 discloses the system of claim 1. Osborn further discloses:
“wherein the transaction is financial transaction through at ATM or banking institution” — Osborn discloses that the system is used for authenticating financial transactions involving a contactless card associated with a financial account. The authentication server 1320 receives a “transaction request, wherein the transaction request includes account information for an account requesting to engage in a transaction and transaction information for the transaction” (Osborn, claim 1). Osborn discloses the contactless card may comprise “a credit card, a debit card” (Osborn, col. 31:45-50) issued by a financial institution (the authentication server/issuer). Osborn further discloses that the system “provide[s] improved security for transactions using a contactless card” (Osborn, col. 35:45-50), which are financial transactions processed through the authentication server of the issuing banking institution.
Claim 8
Regarding claim 8, Osborn discloses a method for validating a user’s identity (Osborn, Abstract), the method comprising the steps of:
“transmitting, by a processor, an authentication request, contained in a short message service (SMS) message, to a user device, the authentication request further comprising a uniform resource locator (URL)” — Osborn discloses that the authentication server transmits an authentication request to a client device via SMS: “the authentication server 1320 transmits a request via the network 1315 to the client device 1310 for contactless card authentication. The request may be in the form of…an SMS message” (Osborn, col. 34:20-30). Osborn does not explicitly disclose that the authentication request further comprises a URL. However, Rule discloses that authentication communications for contactless card authentication comprise a URL: “a uniform resource locator (URL) may be dynamically generated such that the corresponding ‘Subject’ line of an email may include the card verification value or token” (Rule, ¶[0184]; claim 5: “the first set of information comprises a uniform resource locator that is dynamically generated to activate the contactless card”). See motivation to combine set forth in the rejection of claim 1 above.
“directing, by a processor, the user device to an application” — Rule discloses that the URL directs the user device to an application: “the default email program may be launched, or an application download store may be presented to prompt the user to download and install an email program on the client device…the user may be presented with an activation link or URL to activate the contactless card” (Rule, ¶[0186], [0201]). Rule further discloses that “If the application is not installed on client device 310, a tap of the card against the card reader 313 may initiate a download of the application 311 (e.g., navigation to an application download page)” (Rule, ¶[0079]). See motivation to combine set forth in the rejection of claim 1 above.
“opening a communication field between a user device and a card, wherein a command to open the communication field is contained in the URL” — Osborn discloses that “the cardholder may, upon receiving the request for contactless card authentication via the client device 1310, bring the contactless card 1305 into the communication field of the client device 1310” (Osborn, col. 34:40-50). Rule discloses the URL launches an application on the client device (Rule, ¶[0186], [0201]). Rule '300 discloses that the launched application programmatically triggers the card reader: “the mobile device 110 may trigger the card reader 118 via an API call” (Rule '300, ¶[0038]). Rule '300 further discloses that authentication data can be formatted within a URI: “the MAC cryptogram may be included with a uniform resource indicator (e.g., as a formatted string)” (Rule '300, ¶[0044]). See motivation to combine set forth in the rejection of claim 1 above.
“receiving, by a processor, an authentication credential from the card in response to an authentication challenge contained in the URL” — Osborn discloses that upon entering the communication field, “the contactless card 1305 is authenticated” and “the processor 1311 of the client device 1310 may verify a MAC cryptogram generated by the contactless card 1305” (Osborn, col. 35:1-15). The MAC cryptogram is the authentication credential generated by the contactless card in response to authentication. Rule discloses that the URL contains an encrypted payload serving as an authentication challenge: “the payload delivered, such as 1234567, may be configured to authenticate the contactless card” (Rule, ¶[0190], [0204]). See motivation to combine set forth in the rejection of claim 1 above.
“validating the authentication request; and” — Osborn discloses: “If at step 1414 the contactless card is authenticated (YES), the authentication server 1320 allows the transaction at step 1418” (Osborn, col. 35:25-40).
“performing a transaction.” — Osborn discloses performing the transaction upon successful validation: “the authentication server 1320 allows the transaction at step 1418” (Osborn, col. 35:30-40; see also claim 14: “authorizing, by the authentication server, the transaction in response to verification of the authentication factor”).
Claim 9
Regarding claim 9, the combination of Osborn, Rule, and Rule '300 discloses the method of claim 8. Osborn further discloses:
“wherein the user device is at least one selected from the group of a smart phone, tablet, or computer” — Osborn discloses that the client device may be “any other smartphone, tablet, or like wearable mobile device” (Osborn, col. 12:30-40). See Claim 2 analysis.
Claim 11
Regarding claim 11, the combination of Osborn, Rule, and Rule '300 discloses the method of claim 8. Osborn further discloses:
“wherein the user device is a smart watch” — Osborn discloses that the client device may be “any other smartphone, tablet, or like wearable mobile device” (Osborn, col. 4:10-15, col. 12:35-40, emphasis added). A smart watch is a wearable mobile device. To the extent Osborn does not explicitly name a “smart watch,” it would have been obvious to one of ordinary skill in the art to use a smart watch as the user device, as NFC-enabled smart watches (e.g., Apple Watch, Samsung Galaxy Watch) were well-known and commercially available as wearable mobile devices before the effective filing date. The substitution of one known type of wearable mobile device for another would have yielded predictable results.
Claim 12
Regarding claim 12, the combination of Osborn, Rule, and Rule '300 discloses the method of claim 8. Osborn further discloses:
“where the transaction is a secure access transaction for entering a living space or abode” — Osborn discloses that the contactless card 1305 “may comprise at least one of a building access card, a credit card, a debit card, an identification card, a loyalty program card, and a transportation card” (Osborn, col. 31:50-55, emphasis added). It would have been obvious to one of ordinary skill in the art that building access encompasses access to a living space or abode, as contactless card-based access control systems for residential buildings (e.g., apartment complexes, condominiums, residential communities) were well-known and conventional before the effective filing date.
Claim 13
Regarding claim 13, the combination of Osborn, Rule, and Rule '300 discloses the method of claim 8. Osborn further discloses:
“wherein the transaction is a secure access transaction for opening one or more secure storage spaces” — Osborn discloses that the contactless card may comprise “a building access card” (Osborn, col. 31:50-55) for physical access control. It would have been obvious to one of ordinary skill in the art to extend the secure access transaction functionality of the combined system to opening one or more secure storage spaces (e.g., lockers, storage units, safe deposit boxes, mailboxes), as NFC-based contactless card authentication for access control to secure physical storage spaces was well-known and conventional in the art before the effective filing date. The substitution of one type of secure access transaction (building access) for another (storage access) using the same contactless card authentication mechanism would have yielded predictable results.
Claim 14
Regarding claim 14, the combination of Osborn, Rule, and Rule '300 discloses the method of claim 8. Osborn further discloses:
“wherein the authentication credential is a digital signature from the card” — Osborn explicitly discloses: “the MAC cryptogram may function as a digital signature for purposes of verification. Other digital signature algorithms, such as public key asymmetric algorithms, e.g., the Digital Signature Algorithm and the RSA algorithm, or zero knowledge protocols, may be used to perform this verification” (Osborn, col. 7:55-65, emphasis added).
Claim 15
Regarding claim 15, the combination of Osborn, Rule, and Rule '300 discloses the method of claim 8. Osborn further discloses:
“wherein the authentication request and authentication credential are transmitted and received through an application protocol data unit (APDU)” — Osborn discloses that the contactless card applets communicate via APDU: “the one or more applets may be configured to stop responding to all application protocol data unit (APDU) requests” (Osborn, col. 17:15-20, emphasis added). Osborn further discloses that NFC communication between the contactless card and client device follows the NDEF protocol, which involves APDU command sequences: “a reader, such as application 122, may transmit a message, such as an applet select message, with the applet ID of an NDEF producing applet. Upon confirmation of the selection, a sequence of select file messages followed by read file messages may be transmitted. For example, the sequence may include ‘Select Capabilities file’, ‘Read Capabilities file’, and ‘Select NDEF file’” (Osborn, col. 5:45-65). These select and read file messages constitute APDUs per ISO/IEC 7816-4.
Claim 16
Regarding claim 16, the combination of Osborn, Rule, and Rule '300 discloses the method of claim 8. Osborn further discloses:
“wherein the method further comprises, before the final step of performing a transaction, the additional steps of: transmitting, over the processor, a one-time password (OTP) to the user device;” — Osborn discloses that applets on the contactless card “may be added to contactless cards to provide a one-time password (OTP) for multifactor authentication (MFA) in various mobile application-based use cases. Applets may be configured to respond to one or more requests…and produce an NDEF message that comprises a cryptographically secure OTP encoded as an NDEF text tag” (Osborn, col. 16:25-35, emphasis added).
“receiving, over the processor, a passcode from the user device;” — Osborn discloses that the authentication server “may additionally request that the cardholder provide biometric information, provide a PIN, provide a password, or provide other identifying information, to the client device 1310 in addition to bringing the contactless card 1305 into the communication field” (Osborn, col. 34:35-45, emphasis added). The cardholder provides the requested passcode via the client device.
“validating the user; and” — Osborn discloses that the authentication server verifies the provided information: “The client device 1310 may verify the provided biometric information against reference biometric information stored in memory” (Osborn, col. 34:50-55).
“performing a transaction.” — Osborn discloses performing the transaction upon successful multi-factor authentication: “the authentication server 1320 allows the transaction at step 1418” (Osborn, col. 35:30-40).
It would have been obvious to one of ordinary skill in the art that the multi-factor authentication process of Osborn — which teaches both OTP generation by the contactless card and requiring additional authentication factors such as a password/PIN — encompasses transmitting an OTP to the user device and requiring the user to respond with a passcode before the transaction is authorized, as OTP-based second-factor authentication was a well-known and conventional method of multi-factor authentication before the effective filing date.
Claim 17
Regarding claim 17, Osborn discloses a computer-accessible non-transitory medium comprising computer executable instructions that, when executed on a processor, perform procedures (Osborn, col. 4:40-55: “a computer program tangibly embodied in an information carrier, e.g., in a machine readable storage device…for execution by, or to control the operation of, data processing apparatus, e.g., a programmable processor, a computer”) comprising the steps of:
“transmitting, by a processor, an authentication request, contained in a short message service (SMS) message, to a user device, the authentication request further comprising a uniform resource locator (URL)” — Osborn discloses that the authentication server transmits an authentication request to the client device via SMS (Osborn, col. 34:20-30: “The request may be in the form of…an SMS message”). Osborn does not explicitly disclose a URL in the SMS. Rule discloses that authentication communications comprise a URL with an encrypted payload (Rule, ¶[0184]-[0186], [0199]; claim 5). See motivation to combine set forth in the rejection of claim 1 above.
“directing, by a processor, the user device to an application” — Rule discloses that the URL directs the user device to an application (Rule, ¶[0186], [0201]: “the default email program may be launched, or an application download store may be presented”). See motivation to combine set forth in the rejection of claim 1 above.
“opening a communication field between a user device and a card, wherein a command to open the communication field is contained in the URL” — Osborn discloses opening a communication field between the client device and the contactless card in response to the authentication request (Osborn, col. 34:40-50). Rule discloses the URL launches an application (Rule, ¶[0186], [0201]). Rule '300 discloses the application triggers the card reader via an API call (Rule '300, ¶[0038]). See motivation to combine set forth in the rejection of claim 1 above.
“receiving, by a processor, an authentication credential from the card in response to an authentication challenge contained in the URL” — Osborn discloses receiving a MAC cryptogram from the contactless card (Osborn, col. 35:1-15). Rule discloses the URL contains an encrypted payload serving as an authentication challenge (Rule, ¶[0190], [0204]). See motivation to combine set forth in the rejection of claim 1 above.
“validating the user device; and” — Osborn discloses validating the authentication: “If at step 1414 the contactless card is authenticated (YES), the authentication server 1320 allows the transaction” (Osborn, col. 35:25-40). The validation of the contactless card authenticates the user device in conjunction with the device through which the card communicates.
“performing a transaction.” — Osborn discloses: “the authentication server 1320 allows the transaction at step 1418” (Osborn, col. 35:30-40).
Claim 18
Regarding claim 18, the combination of Osborn, Rule, and Rule '300 discloses the computer-accessible non-transitory medium of claim 17. Osborn further discloses:
“wherein the user device is at least one selected from the group of a smart phone, tablet, or computer” — Osborn discloses that the client device may be a smartphone, tablet, or computer (Osborn, col. 12:30-40). See Claim 2 analysis.
Claim 19
Regarding claim 19, the combination of Osborn, Rule, and Rule '300 discloses the computer-accessible non-transitory medium of claim 17. Osborn further discloses:
“wherein the user device is an automated teller machine (ATM)” — Osborn discloses that client devices include various network-enabled computer devices and specifically lists “a kiosk” (Osborn, col. 12:25-30). Osborn further discloses the system is used for financial transactions involving card authentication with a financial institution (Osborn, col. 31:40-55, col. 34:1-20). It would have been obvious to one of ordinary skill in the art to implement the authentication system on an ATM as the user device, as ATMs are well-known network-enabled computing devices used for financial card-based transactions that commonly incorporate contactless/NFC card readers and network connectivity to authentication servers. The substitution of one known type of financial transaction device (mobile phone per Osborn) for another known type (ATM) would have yielded predictable results.
Conclusion
Art cited but not relied upon pertinent to application disclosure includes Rule et al., U.S. 10,771,254 generally identifying contactless card systems and communications; Mitra et al., U.S. 2016/0267486 generally identifying smartcards, user devices and network communications; and Zarakas et al., U.S. 2017/0154328 generally identifying dynamic transaction cards, user devices and network communications.
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MICHAEL W ANDERSON whose telephone number is (571)270-0508. The examiner can normally be reached Monday - Thursday 9am-4pm.
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, Tariq Hafiz can be reached at (571) 272-5350. 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.
Mike Anderson
Supervisor Patent Examiner
Art Unit 3693
/Mike Anderson/Supervisory Patent Examiner, Art Unit 3693
Prosecution Insights