DCT
9:25-cv-00121
Secure Mobile Transactions LLC v. Regions Bank
I. Executive Summary and Procedural Information
- Parties & Counsel:
- Plaintiff: Secure Mobile Transactions LLC (Texas)
- Defendant: Regions Bank (Texas)
- Plaintiff’s Counsel: Antonelli, Harrington & Thompson LLP; The Stafford Davis Firm
- Case Identification: 9:25-cv-00121, E.D. Tex., 04/08/2025
- Venue Allegations: Plaintiff alleges venue is proper in the Eastern District of Texas because Defendant Regions Bank has committed acts of patent infringement in the district and maintains regular and established places of business there.
- Core Dispute: Plaintiff alleges that Defendant’s card services, when used with third-party digital wallets like Apple Pay and Google Pay, infringe patents related to secure, token-based mobile payment transaction systems.
- Technical Context: The technology concerns methods for replacing a card's primary account number (PAN) with a secure token during mobile payments to prevent fraud, a foundational concept in modern contactless payment ecosystems.
- Key Procedural History: The asserted patents are part of a family claiming priority to a 2007 provisional application. U.S. Patent No. 11,288,647 is subject to a terminal disclaimer, which may limit the potential damages period for that patent to the expiration date of an earlier patent in the family.
Case Timeline
| Date | Event |
|---|---|
| 2007-01-03 | Earliest Priority Date for all Asserted Patents |
| 2017-10-17 | U.S. Patent No. 9,792,596 Issued |
| 2020-01-28 | U.S. Patent No. 10,546,285 Issued |
| 2022-03-29 | U.S. Patent No. 11,288,647 Issued |
| 2025-04-08 | Complaint Filed |
II. Technology and Patent(s)-in-Suit Analysis
U.S. Patent No. 9,792,596 - Mobile Phone Based Rebate Device for Redemption at a Point of Sale Terminal
The Invention Explained
- Problem Addressed: The patent describes the challenge retailers face in implementing loyalty and reward programs for mobile device users. Traditional methods are not scalable and require customers to share sensitive personal information, creating privacy concerns and friction during transactions (’596 Patent, col. 1:25-45).
- The Patented Solution: The invention proposes a system where a user's mobile device presents a "unique code" at a Point of Sale (POS) terminal to conduct a transaction instead of a financial account number (’596 Patent, Abstract). This code is sent to a remote computer system, which authenticates it, links it to a "virtual account ID," and authorizes the transaction, thereby preventing the POS terminal from ever handling the actual account number (’596 Patent, col. 7:1-20; Fig. 3).
- Technical Importance: This architecture was designed to mitigate the risks of merchant data breaches by removing the sensitive financial account number from the POS environment, a significant security concern for the payment industry (Compl. ¶13).
Key Claims at a Glance
- The complaint asserts at least independent claim 1 (Compl. ¶23).
- Claim 1 is a method for enabling a POS transaction, with key elements including:
- Receiving, by a remote computer system from a POS terminal, a unique code and not a financial account number.
- Routing the unique code to an accounting server.
- Determining a virtual account ID.
- Routing the transaction to an authentication, authorization and accounting (AAA) server.
- Communicating an authorization message back to the POS terminal without communicating the financial account number.
- The complaint reserves the right to assert additional claims, including dependent claims (Compl. ¶22).
U.S. Patent No. 10,546,285 - Mobile Phone Based Transactions at a Point of Sale Terminal
The Invention Explained
- Problem Addressed: The patent addresses the same technical problem as its parent '596 patent: the need for a secure and unified system to manage mobile rewards and transactions without exposing underlying financial account data at the point of sale (’285 Patent, col. 1:25-45).
- The Patented Solution: The solution is a system architecture that aggregates various loyalty programs into a single virtual account accessible from a mobile device (’285 Patent, Abstract). A transaction is initiated by transmitting a "mobile transaction-specific unique code" from the mobile device to the POS system, which then communicates with a remote server for authorization, all while shielding the actual financial account number from the merchant (’285 Patent, col. 8:1-17).
- Technical Importance: By focusing on aggregating multiple retailer programs into a single user account, the technology aimed to provide a more seamless and secure user experience for mobile commerce (Compl. ¶11).
Key Claims at a Glance
- The complaint asserts at least independent claim 7 (Compl. ¶41).
- Claim 7 is a method performed by a POS system, with key elements including:
- Receiving from an Internet capable mobile device a mobile transaction-specific unique code without also receiving a financial account number.
- Routing the unique code to a remote computer system, where the code enables the remote system to determine a device-specific virtual account ID.
- Receiving an authorization message for the transaction without receiving the financial account number.
- The complaint reserves the right to assert additional claims, including dependent claims (Compl. ¶40).
U.S. Patent No. 11,288,647 - Radio Device Based Transactions at a Point of Sale Terminal
The Invention Explained
Continuing the technology of the parent patents, the ’647 Patent discloses a method for executing a transaction using a "radio device" (e.g., a smartphone) at a POS terminal. The core invention is a system that uses a transaction-specific unique code, rather than a financial account number, to communicate with a remote accounting server for authorization. This process is designed to prevent the merchant's POS system from ever receiving or storing the user's sensitive financial account number, thus enhancing security (’647 Patent, Abstract; col. 1:20-45).
Key Claims and Accused Features
- Asserted Claims: The complaint asserts at least independent claim 7 (Compl. ¶59).
- Accused Features: The accused features are Regions Bank's card authentication systems that enable customers to use their debit/credit cards in digital wallets (e.g., Apple Pay, Google Pay) for contactless, token-based payments (Compl. ¶¶56-57).
III. The Accused Instrumentality
Product Identification
The Accused Instrumentality is Regions Bank's card authentication system, which enables its debit and credit cards, such as the Cash Rewards Visa Signature Credit Card, to be used for contactless mobile payments (Compl. ¶¶20, 38, 56).
Functionality and Market Context
The complaint alleges that Regions' system is implemented using EMVCo compliant tokens, which replace a customer's actual debit or credit card number during a transaction (Compl. ¶20). According to the complaint, a customer adds their Regions card to a digital wallet on a smartphone (e.g., Apple Pay, Google Pay). A screenshot from Regions' website shows instructions for customers on how to "Add your card to the digital wallet" (Compl. p. 8). When making a purchase, the customer's phone uses Near Field Communication (NFC) to transmit a payment token and a cryptogram—not the actual card number—to the merchant's POS terminal (Compl. ¶21). This information is then routed through the payment network for de-tokenization and authorization by the card issuer, Regions Bank (Compl. p. 11, Fig. 6). The complaint alleges this process mirrors the technology claimed in the Asserted Patents, as the merchant POS terminal executes a transaction without ever receiving the customer's financial account number (Compl. ¶21).
IV. Analysis of Infringement Allegations
’596 Patent Infringement Allegations
| Claim Element (from Independent Claim 1) | Alleged Infringing Functionality | Complaint Citation | Patent Citation |
|---|---|---|---|
| receiving by a remote computer system from a physical point of sale (POS) terminal, a unique code and not a financial account number... | The complaint alleges that after a customer taps their phone, the merchant's system sends a transaction request containing a payment token (the "unique code") to the payment network and issuer processor (the "remote computer system") without sending the actual card number (PAN) (Compl. p. 11, Fig. 6, steps 2-3). | ¶21 | col. 7:1-3 |
| routing said unique code without said financial account number to an accounting server; | The payment network allegedly routes the token-based transaction to the appropriate Token Service Provider (TSP) and subsequently to the issuer processor (collectively, the "accounting server") for processing (Compl. p. 11, Fig. 6, steps 3-5). | ¶21 | col. 7:4-7 |
| determining a virtual account ID; | The TSP is alleged to receive the token and use it to look up, or "detokenize," the corresponding actual PAN, which functions as the "virtual account ID" for routing to the issuer (Compl. p. 11, Fig. 6, step 4). | ¶21 | col. 7:15-17 |
| communicating an authorization message for the transaction without also communicating said financial account number to said physical POS terminal that received said unique code without said financial account number | The issuer processor allegedly sends an authorization response back through the payment network to the merchant acquirer/processor, which ensures that only the token, not the clear PAN, is included in the final message to the merchant's POS terminal (Compl. p. 12, Fig. 6, steps 8-9). A diagram from the U.S. Payments Forum illustrates this data flow. | ¶21 | col. 8:25-33 |
’285 Patent Infringement Allegations
| Claim Element (from Independent Claim 7) | Alleged Infringing Functionality | Complaint Citation | Patent Citation |
|---|---|---|---|
| receiving from the Internet capable mobile device a mobile transaction specific unique code without also receiving any financial account number from said Internet capable mobile device; | The complaint alleges that an NFC-enabled merchant terminal receives a payment token (the "unique code") from the user's smartphone when the user taps to pay, without receiving the actual financial account number (Compl. p. 11, Fig. 6, step 1). | ¶39 | col. 9:26-30 |
| routing to a remote computer system the mobile transaction-specific unique code without also routing any financial account number to said remote computer system... | The merchant's acquirer/processor allegedly receives the transaction request with the token and routes it to the appropriate payment network for processing by the TSP and issuer processor (the "remote computer system"). The actual account number is not routed from the POS (Compl. p. 11, Fig. 6, steps 2-3). | ¶39 | col. 9:31-35 |
| receiving an authorization message for the transaction without also receiving any financial account number from said Internet capable mobile device; | The merchant acquirer/processor is alleged to receive an authorization response from the payment network and, in turn, sends a completion message to the contactless terminal. This authorization message does not contain the actual account number (Compl. p. 12, Fig. 6, steps 9-10). | ¶39 | col. 9:40-44 |
Identified Points of Contention
- Scope Questions: The specifications of the asserted patents heavily discuss the invention in the context of "rebate," "loyalty," and "discount code" programs (’596 Patent, Title; ’285 Patent, col. 4:14-15). A potential point of contention is whether the scope of a term like "unique code" can be read to cover the general-purpose "payment token" used in the accused EMVCo system, or if its meaning is limited by the specification's focus on rebates and rewards.
- Technical Questions: The patents describe an architecture involving an "Accounting Server" and "AAA server" (’285 Patent, Fig. 3). The complaint maps these elements to the complex, multi-entity EMVCo ecosystem, which includes merchant acquirers, payment networks, Token Service Providers (TSPs), and issuer processors (Compl. ¶22, 40). This raises the question of whether the distributed functions of the accused system are structurally and functionally equivalent to the more centralized system depicted in the patent figures.
V. Key Claim Terms for Construction
"unique code" / "mobile transaction-specific unique code"
- Context and Importance: This term is the technological core of the asserted claims. Its construction will be critical to determining infringement. Defendant may argue the term is limited to the "discount code" and "rebate" embodiments that pervade the specification, whereas Plaintiff will likely argue it broadly covers any unique identifier, such as a payment token, that is used in place of a financial account number.
- Intrinsic Evidence for a Broader Interpretation: The plain language of the claims requires only "a unique code and not a financial account number" (’596 Patent, col. 8:5-6), without explicit limitation to rebates.
- Intrinsic Evidence for a Narrower Interpretation: The specification repeatedly frames the invention around loyalty programs, referring to "Discount Codes (PINs/SKUs/Barcodes)" and a system for managing "retail reward programs" (’285 Patent, col. 3:12-14, col. 4:45-48). The title of the '596 patent itself refers to a "Rebate Device."
"accounting server" / "remote computer system"
- Context and Importance: The claims require specific actions to be performed by these remote systems. The infringement case rests on mapping these claimed servers to the components of the accused EMVCo payment infrastructure (e.g., acquirer, TSP, issuer processor). Practitioners may focus on this term because the patent figures depict a seemingly distinct architecture from the multi-party system alleged to infringe.
- Intrinsic Evidence for a Broader Interpretation: The patent describes the functions of the servers, such as authenticating codes and processing transactions, which Plaintiff will argue are performed by the collection of servers in the accused system, even if distributed among different entities (Compl. ¶22).
- Intrinsic Evidence for a Narrower Interpretation: The patent figures show distinct "Accounting Server" and "AAA Server" entities, which could support an argument that the claims require a specific, less-distributed architecture than the one used for modern tokenized payments (’596 Patent, Fig. 3).
VI. Other Allegations
- Indirect Infringement: The complaint alleges inducement by asserting that Regions actively encourages and instructs its customers to use the accused systems. This is supported by pointing to Regions' website, which provides instructions on how to add a Regions card to a digital wallet (Compl. ¶¶25, 74, p. 8). Contributory infringement is also alleged, on the basis that the tokenization system is a material part of the invention especially adapted for infringement and has no substantial non-infringing use (Compl. ¶¶27, 82-84).
- Willful Infringement: Willfulness allegations are based on Regions' alleged knowledge of the patents "at least as of the date when it was notified of the filing of this action" (Compl. ¶¶32, 50, 68). The complaint further alleges that Regions' actions are "at least objectively reckless as to the risk of infringing valid patents" (Compl. ¶86).
VII. Analyst’s Conclusion: Key Questions for the Case
- A core issue will be one of definitional scope: can the term "unique code," rooted in a patent specification focused on "rebates" and "loyalty programs," be construed to cover the general-purpose "payment tokens" that are foundational to the accused EMVCo payment standard?
- A key evidentiary question will be one of architectural mapping: does the distributed, multi-entity EMVCo system—involving distinct merchant acquirers, payment networks, token service providers, and issuer processors—perform the functions of and constitute the "remote computer system" and "accounting server" as claimed in the patents, or is there a fundamental mismatch in the claimed and accused system architectures?
- A third question will relate to inducement: does providing customers with instructions on how to enable industry-standard functionality like Apple Pay or Google Pay rise to the level of specific intent to encourage infringement of the asserted patents, particularly if the claimed technology is alleged to be the standard itself?