DCT
1:19-cv-02811
Grecia v. Citibank NA
Key Events
Complaint
I. Executive Summary and Procedural Information
- Parties & Counsel:
- Plaintiff: William Grecia (Pennsylvania)
- Defendant: Citibank, N.A. (New York)
- Plaintiff’s Counsel: Wawrzyn & Jarvis LLC
- Case Identification: 1:19-cv-02811, S.D.N.Y., 03/29/2019
- Venue Allegations: Venue is alleged to be proper based on Citibank’s continuous and systematic business operations within the Southern District of New York.
- Core Dispute: Plaintiff alleges that Defendant’s "Citi with Zelle" financial service infringes a patent related to a process for transforming a user identifier into a secure, computer-readable authorization object for accessing cloud-based digital content.
- Technical Context: The technology resides in the field of digital rights management (DRM) and secure digital access, focusing on methods to link a user's identity to their access permissions for digital assets in a portable and persistent manner.
- Key Procedural History: The complaint references and relies upon a claim construction order from a prior litigation involving the same patent (Grecia v. Mastercard Int'l Inc.), indicating an attempt to apply previously adjudicated term definitions to the current infringement allegations.
Case Timeline
| Date | Event |
|---|---|
| 2010-03-21 | '308 Patent Priority Date |
| 2014-11-11 | '308 Patent Issue Date |
| 2018-09-08 | Claim Construction Order issued in Grecia v. Mastercard |
| 2019-03-29 | Complaint Filing Date |
II. Technology and Patent(s)-in-Suit Analysis
U.S. Patent No. 8,887,308 - DIGITAL CLOUD ACCESS (PDMAS PART III)
- Patent Identification: U.S. Patent No. 8,887,308, DIGITAL CLOUD ACCESS (PDMAS PART III), issued November 11, 2014.
The Invention Explained
- Problem Addressed: The patent describes a problem with traditional Digital Rights Management (DRM) systems, which often lock content to specific devices, rely on centralized servers that can be shut down, and limit consumers' "fair use" rights to share media with family ('308 Patent, col. 2:48-68).
- The Patented Solution: The invention proposes a more personal and interoperable system for managing access to digital content. The process involves using a "verification token" (like an email address) to authenticate a user against a "verified web service" (like a membership site). This authentication returns "metadata" (like a unique user ID) from the service. The system then creates a durable "authorization object" by writing both the user's original token and the returned metadata into a data store, linking the user's identity to the content access rights in a way that is not tied to a single device ('308 Patent, col. 3:11-44; Fig. 6).
- Technical Importance: This approach aimed to shift DRM from a device-centric model to a user-identity-centric model, potentially increasing content portability and preserving user access rights even if hardware changes or original providers cease services ('308 Patent, col. 3:4-10).
Key Claims at a Glance
- The complaint asserts independent Claim 1, as modified by a Certificate of Correction issued July 13, 2021.
- Claim 1, as corrected, requires a process comprising the following essential steps:
- (a) Receiving an access request for cloud digital content, where the request includes "verification data" recognized as a "verification token."
- (b) Authenticating the verification token using a verification token database.
- (c) Establishing an API communication with a separate database apparatus related to a "verified web service."
- (d) Requesting "metadata" from the API communication session.
- (e) Receiving the requested "metadata."
- (f) Creating a "computer readable authorization object" by writing at least two items into a data store: the received verification data from step (a) and the received metadata from step (e).
III. The Accused Instrumentality
Product Identification
- Defendant's "Citi with Zelle" service, referred to as "CZelle" in the complaint (Compl. ¶11).
Functionality and Market Context
- The complaint alleges that CZelle is a service for sending and receiving money that works by "transforming a user's email address, for example, into a payment token" (Compl. ¶11). The process allegedly involves a customer registering an email address or mobile phone number, which then serves as a "verification token" (Compl. ¶12). This token is allegedly authenticated, and an API connection is made to the "Zelle service database" to request and receive data, such as "CXCTokens" (Compl. ¶13-15). This process culminates in the creation of a "CZelle authorization object" that is used in subsequent requests for privileged access to financial data (Compl. ¶16).
IV. Analysis of Infringement Allegations
No probative visual evidence provided in complaint.
'308 Patent Infringement Allegations
| Claim Element (from Independent Claim 1, as corrected) | Alleged Infringing Functionality | Complaint Citation | Patent Citation |
|---|---|---|---|
| a) receiving an access request for cloud digital content through an apparatus..., the access request being a write request to a data store..., wherein the access request further comprises verification data provided by at least one user, wherein the verification data is recognized by the apparatus as a verification token... | CZelle receives a write request when a Citibank customer registers an email address or mobile telephone number with the service. This email or phone number is alleged to be the "verification token." | ¶12 | col. 14:32-43 |
| b) authenticating the verification token of (a) using a database recognized by the apparatus of (a) as a verification token database... | Citibank's CZelle service uses a database to authenticate the user's email address or mobile telephone number. | ¶13 | col. 14:44-47 |
| c) establishing an API communication between the apparatus of (a) and a database apparatus, the database apparatus being a different database from the verification token database of (b) wherein the API is related to a verified web service... | CZelle establishes a connection to the Zelle service database, which is alleged to be different from the verification token database and related to the Zelle services API (the "verified web service"). | ¶14 | col. 14:48-62 |
| d) requesting the metadata, from the apparatus of (a), from the API communication data exchange session of (c)... | The complaint alleges CZelle infringes this step when the Zelle service database returns the "CXCTokens requested." | ¶15 | col. 14:63-67 |
| e) receiving the metadata requested in (d) from the API communication data exchange session of (c)... | CZelle receives the requested "CXCTokens" from the Zelle service database. | ¶15 | col. 15:1-2 |
| f) creating a computer readable authorization object by writing into the data store of (a) at least two of: the received verification data of (a); and the received metadata of (e); wherein the created computer readable authorization object is recognized... as user access rights... | CZelle allegedly creates an authorization object by writing the "enrolled" verification data (email/phone) and the "enrolled" Zelle query data (metadata) into the CZelle data storage. This object is then used for subsequent access to privileged financial data. | ¶16 | col. 15:3-14 |
Identified Points of Contention
- Scope Questions: A primary question is whether the patent's terminology, developed for digital media DRM, can be read onto a financial transaction network. This raises the question of whether a simple user identifier like an email or phone number (Compl. ¶12) constitutes a "verification token" as defined by the patent, and whether the Zelle financial services API (Compl. ¶14) functions as a "verified web service" in the manner contemplated by the patent, which uses membership sites like Facebook as an exemplar ('308 Patent, col. 10:41-44).
- Technical Questions: The complaint alleges that "CXCTokens" constitute the "metadata" of the claim (Compl. ¶15). A key technical question will be what data these tokens actually contain and whether they correspond to the patent's concept of metadata, such as a unique account identifier from a web service ('308 Patent, col. 11:23-26). Furthermore, the corrected claim requires writing both the verification data and the metadata into a data store to create the authorization object. A significant evidentiary question is whether the accused CZelle system actually performs this specific combined writing action to create a single, persistent object as claimed ('308 Patent, col. 15:3-6).
V. Key Claim Terms for Construction
Term: ‘verification token’
- Context and Importance: This term defines the initial user input that triggers the patented process. The viability of the infringement claim depends on whether a user's email or phone number, as used in the Zelle enrollment process, falls within the term's scope. Practitioners may focus on this term because its construction from the prior Grecia v. Mastercard case—"data that represents permission to access digital media or cloud digital content" (Compl. ¶7)—is broad and its application to a financial identifier is a central point of dispute.
- Intrinsic Evidence for Interpretation:
- Evidence for a Broader Interpretation: The complaint relies on the prior construction, which is not limited to a specific format. The specification also mentions an "e-mail address associated with an e-commerce payment system" as an example of a token, which may support the Plaintiff's position ('308 Patent, col. 8:52-54).
- Evidence for a Narrower Interpretation: The specification also describes tokens as "structured or random password[s]," suggesting something created for security rather than a pre-existing general identifier ('308 Patent, col. 8:51-52). A defendant may argue the primary context is media DRM, not financial account lookups.
Term: ‘computer readable authorization object’
- Context and Importance: This is the final, tangible output of the claimed process. Infringement requires that the accused service creates this specific object. Practitioners may focus on this term because the Certificate of Correction added a specific structural requirement that could be a high bar for the Plaintiff to prove.
- Intrinsic Evidence for Interpretation:
- Evidence for a Broader Interpretation: The term itself suggests any data structure that a computer can read to grant authorization.
- Evidence for a Narrower Interpretation: The claim, as corrected, explicitly requires this object be created by "writing into the data store... at least two of: the received verification data... and the received metadata" ('308 Patent, col. 15:3-6). This requires a specific compositional act. A defendant could argue that its system stores these data elements separately or that any "object" is merely an ephemeral result of a query, not a distinct entity created by a specific "writing" action as claimed.
VI. Other Allegations
The complaint does not allege willful or indirect infringement.
VII. Analyst’s Conclusion: Key Questions for the Case
- A core issue will be one of definitional scope: can the patent's key terms, which are rooted in the technical context of personalizing access to digital media (DRM), be construed to cover the functional components of a peer-to-peer financial transaction network? Specifically, does a user's email address function as a "verification token" and does the Zelle payment API qualify as a "verified web service" as those terms are defined in the patent?
- A second central issue will be a question of structural and evidentiary proof: does the accused Citi with Zelle service, in its actual operation, create a single "computer readable authorization object" by performing the specific act of writing both the user's identifier ("verification data") and the data returned from the Zelle API ("metadata") into a data store, as explicitly required by the corrected structure of Claim 1?