DCT
3:20-cv-03762
Digital Verification Systems LLC v. GetAccept Inc
I. Executive Summary and Procedural Information
- Parties & Counsel:
- Plaintiff: Digital Verification Systems, LLC (Texas)
- Defendant: GetAccept, Inc. (Delaware)
- Plaintiff’s Counsel: SML AVVOCATI P.C.
- Case Identification: 3:20-cv-03762, N.D. Cal., 06/08/2020
- Venue Allegations: Venue is based on Defendant GetAccept having a principal place of business in the Northern District of California, regularly transacting business in the state, and allegedly committing acts of infringement within the district.
- Core Dispute: Plaintiff alleges that Defendant’s eSign electronic signature platform infringes a patent related to systems and methods for creating and embedding a verifiable digital identity module within an electronic file.
- Technical Context: The technology operates in the electronic signature and digital identity verification market, which is foundational to digital contract execution, secure document management, and online transaction authentication.
- Key Procedural History: An Inter Partes Review (IPR) proceeding (IPR2018-00746) was previously concluded for the patent-in-suit. The resulting IPR certificate, issued on May 1, 2020, prior to the filing of this complaint, cancelled claims 23-39 of the patent. The complaint asserts infringement of claims 1 and 26; the cancellation of claim 26 raises a significant question regarding its continued assertion in this litigation.
Case Timeline
| Date | Event |
|---|---|
| 2008-01-02 | U.S. Patent No. 9,054,860 Priority Date |
| 2015-06-09 | U.S. Patent No. 9,054,860 Issue Date |
| 2018-01-24 | Example Accused Activity Date (Timestamp on Signature Certificate) |
| 2018-03-06 | IPR2018-00746 Filed against U.S. Patent No. 9,054,860 |
| 2020-05-01 | IPR Certificate Issued, Cancelling Claims 23-39 of the '860' Patent |
| 2020-06-08 | Complaint Filed |
II. Technology and Patent(s)-in-Suit Analysis
U.S. Patent No. 9,054,860, "Digital Verified Identification System and Method," issued June 9, 2015
The Invention Explained
- Problem Addressed: The patent’s background section identifies the difficulty of authenticating conventional electronic signatures, describing it as an "arduous, if not impossible task to verify and/or authenticate the identity of the signatory to a respectable degree" (’860 Patent, col. 1:31-35; Compl. ¶19).
- The Patented Solution: The invention describes a system for creating a "digital identification module" that is embedded within an electronic document (’860 Patent, col. 1:6-12). This module is generated by an assembly that receives "verification data element(s)" from a user (e.g., name, date of birth, password) (’860 Patent, col. 2:4-12). The module itself contains a "primary component" (e.g., a visible signature image) and hidden "metadata components" (e.g., user's name, timestamp, location), which can be revealed when a user interacts with the primary component, for instance, by hovering a mouse over it (’860 Patent, col. 2:25-47).
- Technical Importance: The technology purports to increase the reliability of electronic signatures by binding verifiable identity data directly to the signature object within a document, creating a self-contained token for authentication (’860 Patent, col. 1:36-44).
Key Claims at a Glance
- The complaint asserts independent claims 1 (a system claim) and 26 (a method claim) (Compl. ¶27).
- Independent Claim 1 (System) requires:
- A "digital identification module" associated with an entity.
- A "module generating assembly" that receives a "verification data element" to create the module.
- The module is "disposable within at least one electronic file."
- The module has a "primary component" to associate it with the entity.
- The module is "cooperatively structured to be embedded within only a single electronic file."
- Independent Claim 26 (Method) requires:
- Receiving a "verification data element" from an entity.
- Creating a "digital identification module" with a "primary component."
- Embedding the module within an electronic file where it is "cooperatively structured to be embedded within only a single electronic file."
- The complaint does not explicitly reserve the right to assert other claims.
III. The Accused Instrumentality
Product Identification
- The accused instrumentality is GetAccept's "eSign" product, described as a cloud-based process and method for digital identification verification (Compl. ¶¶ 21-22).
Functionality and Market Context
- The GetAccept eSign product allows users to sign electronic documents (Compl. ¶25). As part of the signing process, the system prompts a user to provide identity verification, which can include a handwritten signature, mobile confirmation, or SMS code (Compl. p. 6). After signing, the system generates and embeds a "Signature Certificate" into the document, which includes information such as the signatory's name, email, IP address, device used, and a trusted timestamp (Compl. ¶25, p. 9). The complaint provides a screenshot of a "Signature Certificate" generated for a "Vandelay Industries Deal.pdf" document, illustrating the embedded data (Compl. p. 9).
IV. Analysis of Infringement Allegations
’860 Patent Infringement Allegations
| Claim Element (from Independent Claim 1) | Alleged Infringing Functionality | Complaint Citation | Patent Citation |
|---|---|---|---|
| at least one digital identification module structured to be associated with at least one entity, | The "Signature Certificate," which includes the user's signature and associated data (name, IP address, timestamp), is alleged to be the digital identification module associated with the signing entity (Compl. p. 9). | ¶24 | col. 2:25-30 |
| a module generating assembly structured to receive at least one verification data element... and create said at least one digital identification module, | The GetAccept platform itself is alleged to be the assembly, which receives data from a customer (e.g., login credentials, signature) and creates the identification module (Compl. p. 6). | ¶23 | col. 1:65-2:6 |
| said at least one digital identification module being disposable within at least one electronic file, | The platform allows a customer to attach an e-signature to a document, which GetAccept then embeds, making it disposable within the electronic file (e.g., a PDF) (Compl. p. 8). | ¶25 | col. 1:9-12 |
| said at least one digital identification module comprising at least one primary component structured to at least partially associate said...module with said...entity, | The visible, graphical representation of the user's signature (e.g., the drawn signature of "George Costanza") is alleged to be the primary component (Compl. p. 8). | ¶24 | col. 6:10-16 |
| wherein said at least one digital identification module is cooperatively structured to be embedded within only a single electronic file. | The complaint alleges that the module is cooperatively structured because the information is embedded within a single document for the customer to access and review (Compl. p. 10). | ¶26 | col. 4:35-40 |
- Identified Points of Contention:
- Scope Questions: A central question may be whether the term "module generating assembly" reads on a general-purpose, cloud-based e-signature platform. The patent specification gives examples of "verification data element[s]" like a social security or driver's license number (’860 Patent, col. 4:1-8), raising the issue of whether the accused system, which primarily uses email or SMS for verification, meets the claimed level of verification required to create the module.
- Technical Questions: The complaint's allegation for the "cooperatively structured to be embedded within only a single electronic file" limitation is conclusory (Compl. ¶26). The patent specification suggests this structure could impart specific technical properties, such as rendering the module inoperable if the host file is manipulated or limiting its use to a pre-selected number of files (’860 Patent, col. 4:25-52). A key question for the court will be whether this claim limitation requires such specific functionality, and if so, what evidence shows the accused product possesses it.
V. Key Claim Terms for Construction
The Term: "cooperatively structured to be embedded within only a single electronic file"
- Context and Importance: This limitation appears to be a primary point of novelty intended to distinguish the invention from simply inserting an image into a file. The outcome of the infringement analysis may depend heavily on whether the accused product's simple embedding of a signature certificate meets the specific meaning of "cooperatively structured."
- Intrinsic Evidence for Interpretation:
- Evidence for a Broader Interpretation: A party could argue the plain language does not require more than the module being designed for and placed within one document, a condition met by most signature objects.
- Evidence for a Narrower Interpretation: The specification states that in one embodiment, "the digital identification module 20 may be automatically deleted or removed from the electronic file 40" if the file's contents are manipulated, or the module may be "stamped 'void'" (’860 Patent, col. 4:40-52). This suggests "cooperatively structured" implies an active, security-oriented relationship between the module and the file, rather than passive embedding.
The Term: "module generating assembly"
- Context and Importance: The definition of this term will determine whether the accused GetAccept platform, a cloud service, constitutes the claimed apparatus for creating the identification module. Practitioners may focus on this term to dispute whether a standard software-as-a-service (SaaS) platform qualifies as the specific "assembly" described.
- Intrinsic Evidence for Interpretation:
- Evidence for a Broader Interpretation: The term is defined functionally as something "structured to receive at least one verification data element... and create" the module (’860 Patent, col. 9:8-12), which could arguably encompass any software that performs this function.
- Evidence for a Narrower Interpretation: The specification describes the assembly as potentially being a distinct program or a feature integrated into a word processor (’860 Patent, col. 5:6-26, 60-65). A party might argue this implies a more discrete software component than a distributed cloud platform.
VI. Other Allegations
- Indirect Infringement: The complaint does not plead a separate count for indirect infringement. It makes a conclusory allegation that Defendant's customers use the accused products (Compl. ¶7), but it does not provide specific factual allegations to support the knowledge and intent elements required for induced or contributory infringement.
- Willful Infringement: The complaint alleges that Defendant "will have knowledge of infringement of the ’860 patent upon the service of this Complaint" (Compl. ¶30). The prayer for relief seeks enhanced damages for infringement occurring after service of the complaint, indicating a claim for post-suit willfulness only (Compl. p. 13, ¶5).
VII. Analyst’s Conclusion: Key Questions for the Case
- The IPR’s Impact: The most immediate issue is the legal effect of the IPR certificate that cancelled claim 26 prior to the suit's filing. The court will need to resolve why a claim that is no longer valid is being asserted, which may impact the scope and viability of the overall case.
- Claim Scope and "Cooperative Structure": A central technical and legal question will be one of definitional scope: will the term "cooperatively structured to be embedded within only a single electronic file" be construed to require the specific security features described in the patent's specification (e.g., self-invalidation upon document alteration), or will the simple embedding of a signature certificate suffice?
- Evidentiary Sufficiency: A key evidentiary question will be one of functional mapping: does the complaint, and the discovery that follows, provide sufficient technical evidence to demonstrate that the GetAccept cloud platform operates as the claimed "module generating assembly" and that its signature certificates possess the specific structural properties required by the asserted claims?