1:19-cv-01995
Digital Verification Systems LLC v. Onespan Inc
I. Executive Summary and Procedural Information
- Parties & Counsel:
- Plaintiff: Digital Verification Systems, LLC (Texas)
- Defendant: OneSpan, Inc. (Delaware)
- Plaintiff’s Counsel: Stamoulis & Weinblatt, LLP
- Case Identification: 1:19-cv-01995, D. Del., 10/21/2019
- Venue Allegations: Venue is alleged to be proper in the District of Delaware because Defendant is a Delaware corporation and allegedly maintains a regular and established place of business within the district.
- Core Dispute: Plaintiff alleges that Defendant’s electronic signature products infringe a patent related to creating and embedding a verifiable digital identification module into a single electronic document.
- Technical Context: The technology concerns secure electronic document signing and user authentication, a field essential for digital transactions, contracts, and records management.
- Key Procedural History: The complaint asserts claim 26 of the ’860 patent. Subsequent to the filing of this complaint, a certificate for Inter Partes Review (IPR2018-00746) was issued on May 1, 2020. The certificate, which is attached to the provided patent, states that claims 23-39 of the ’860 patent, including the asserted claim 26, have been cancelled. This post-filing event raises a potentially dispositive issue regarding the continued viability of the infringement claim as pleaded.
Case Timeline
| Date | Event |
|---|---|
| 2008-01-02 | ’860 Patent Priority Date (Application Filing) |
| 2015-06-09 | ’860 Patent Issue Date |
| 2018-03-06 | Inter Partes Review (IPR2018-00746) Filed |
| 2019-10-21 | Complaint Filing Date |
| 2020-05-01 | IPR Certificate Issued (Claims 23-39 Cancelled) |
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 a need for a more reliable way to authenticate electronic signatures, noting that common methods at the time were "rather difficult to authenticate" and verifying the signatory's identity was an "arduous, if not impossible task" (’860 Patent, col. 1:30-36).
- The Patented Solution: The invention proposes a system and method for creating a "digital identification module" that is embedded within an electronic file (’860 Patent, Abstract). This module is generated after receiving at least one "verification data element" from a user, such as a username or password (’860 Patent, col. 2:5-12). The module itself contains a visible "primary component" (e.g., a digital signature image) and one or more "metadata components" (e.g., timestamp, user location, reference numbers) that can be revealed when a user interacts with the primary component, for example by hovering a mouse over it (’860 Patent, col. 2:25-44).
- Technical Importance: The technology aimed to solve authentication problems by creating a dynamic, data-rich digital object that could be bound to a document to provide stronger proof of a signatory's identity and the context of the signing event (’860 Patent, col. 1:37-43).
Key Claims at a Glance
- The complaint asserts independent method claim 26 (’860 Patent, col. 10:60-11:7; Compl. ¶20).
- The essential elements of Claim 26 are:
- Receiving at least one verification data element from an entity.
- Creating at least one digital identification module corresponding to the entity, where the module includes at least one primary component associated with the entity.
- Embedding the digital identification module within an electronic file.
- The digital identification module is cooperatively structured to be embedded within only a single electronic file.
III. The Accused Instrumentality
Product Identification
The accused product is OneSpan's Esignlive (now known as OneSpan Sign) service (Compl. ¶20).
Functionality and Market Context
The complaint describes the Accused Product as a service for e-signing documents. A user provides credentials, such as a login ID and password, to access a document (Compl. ¶23). The user can then apply an electronic signature, which is embedded into the document file along with information such as user identity, date, and time (Compl. ¶¶24-25). The complaint includes a screenshot from the Accused Product's "e-Witness" feature, which displays an embedded signature block with a timestamp (Compl. ¶25, p. 8). This screenshot shows an embedded signature with the text "e-SIGNed by Paul Lancaster on 2017-10-17 11:37:11 UTC."
IV. Analysis of Infringement Allegations
’860 Patent Infringement Allegations
| Claim Element (from Independent Claim 26) | Alleged Infringing Functionality | Complaint Citation | Patent Citation |
|---|---|---|---|
| receiving at least one verification data element from an entity, | The Accused Product requires a user to provide a "unique login ID and password for accessing and verifying" the service to e-sign documents. | ¶23 | col. 4:51-54 |
| creating at least one digital identification module corresponding to the entity, wherein the digital identification module includes at least one primary component at least partially associated with the entity, | The Accused Product allows a user to create a signature, which is alleged to be the digital identification module containing a primary component. The complaint provides a visual of a mobile signing process showing a "Tap to Sign" button. | ¶24 | col. 6:11-16 |
| embedding the at least one digital identification module within an electronic file, | The Accused Product allegedly saves the user's signature, identity, date, and time "all embedded with the document file." The complaint includes a screenshot of an "e-Witness" feature showing this embedded information. | ¶25 | col. 6:26-34 |
| 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 Accused Product allows for the module "to be embedded within only a single document." | ¶26 | col. 4:25-27 |
Identified Points of Contention
- Scope Questions: A central dispute may arise over the meaning of "cooperatively structured to be embedded within only a single electronic file." The question for the court would be whether this limitation requires a specific technical mechanism that binds the module to one file (e.g., rendering it inoperable if copied), or if it is met simply by the act of generating a unique signature instance for one specific signing transaction.
- Technical Questions: A technical question is whether the "verification data element" (the login credentials) is functionally used in the "creating" of the "digital identification module" as required by the claim's structure. The court may need to determine if the login process is merely an access gate, separate from the subsequent signature creation step, or if data from that verification step is integrated into the module itself.
V. Key Claim Terms for Construction
The Term: "digital identification module"
- Context and Importance: This term defines the core inventive concept. Its construction will determine the scope of infringing articles, as it dictates what combination of features (e.g., signature image, metadata, file format) constitutes the patented "module."
- Intrinsic Evidence for Interpretation:
- Evidence for a Broader Interpretation: The specification describes the module as potentially being "virtually any file, item, object, or device structured to be embedded" and gives examples like JPEG or PNG files, suggesting a broad structural definition (’860 Patent, col. 3:31-39).
- Evidence for a Narrower Interpretation: The abstract and summary state the module "includes at least one primary component" and "one or more metadata components," which could be interpreted to require the presence of both distinct element types (’860 Patent, Abstract; col. 2:25-28).
The Term: "cooperatively structured to be embedded within only a single electronic file"
- Context and Importance: This limitation appears intended to distinguish the invention from generic, reusable signature images. Its interpretation is critical to the infringement analysis, particularly concerning how the module and document relate.
- Intrinsic Evidence for Interpretation:
- Evidence for a Broader Interpretation: This could be read to mean the module is simply created for a single document, without imposing a strict technical restraint on its portability.
- Evidence for a Narrower Interpretation: The specification discloses that in one embodiment, the module "may be automatically deleted, become inoperable, or otherwise be disposed in an inactive state" if the document is manipulated, which suggests a technical binding or lock between the module and the specific file (’860 Patent, col. 4:30-48).
VI. Other Allegations
Indirect Infringement
The complaint’s single count is for direct infringement by OneSpan and does not plead a separate cause of action for indirect infringement (Compl. p. 10).
Willful Infringement
The complaint alleges that infringement "after service of this Complaint is intentional and knowing," asserting a claim for post-suit willfulness. It does not allege pre-suit knowledge of the patent or willful infringement prior to the lawsuit’s filing (Compl. Prayer ¶5).
VII. Analyst’s Conclusion: Key Questions for the Case
- Claim Viability: The foremost question is procedural: what is the legal effect of the IPR certificate that cancelled asserted claim 26 after the complaint was filed? The fact that the sole asserted claim has been held unpatentable by the USPTO presents a fundamental, and likely dispositive, challenge to the continuation of the lawsuit.
- Definitional Scope: Assuming the claim were still valid, a key substantive question would be one of definitional scope: can the limitation "cooperatively structured to be embedded within only a single electronic file" be satisfied by the creation of a unique signature instance for a document, or does it require a technical feature that actively prevents the signature module from being ported to or used in another file?
- Functional Linkage: An essential evidentiary question would be one of operational linkage: does the Accused Product use the "verification data element" (e.g., login credentials) in the actual "creating" of the signature module, as the claim language suggests, or does it function merely as a prerequisite for authentication, separate from the signature generation process?