1:26-cv-00187
Mistwood Partnership v. DocuSign Inc
I. Executive Summary and Procedural Information
- Parties & Counsel:
- Plaintiff: Mistwood Partnership (Texas)
- Defendant: DocuSign, Inc. (Delaware)
- Plaintiff’s Counsel: Bayard, P.A.; Arch & Lake LLP
- Case Identification: 1:26-cv-00187, D. Del., 02/20/2026
- Venue Allegations: Venue is alleged to be proper in the District of Delaware because Defendant DocuSign, Inc. is a Delaware corporation and therefore resides in the district.
- Core Dispute: Plaintiff alleges that Defendant’s e-signature and digital transaction management products infringe three U.S. patents related to systems for controlling the delivery of electronic communications and mandating receipt acknowledgment.
- Technical Context: The technology at issue provides methods for ensuring and verifying that a recipient has received and opened a digital message (such as an email or HTTP communication) by preventing access to the message’s content until the recipient authorizes a confirmation to be sent back to the originator.
- Key Procedural History: The complaint notes that the patents-in-suit belong to a family of applications stemming from a series of continuation and continuation-in-part filings. No other procedural events, such as prior litigation or administrative challenges, are mentioned in the complaint.
Case Timeline
| Date | Event |
|---|---|
| 2011-03-31 | Earliest Priority Date for ’495, ’385, and ’386 Patents |
| 2014-08-05 | U.S. Patent No. 8,799,385 Issued |
| 2014-08-05 | U.S. Patent No. 8,799,386 Issued |
| 2014-12-XX | Alleged infringing "new signing experience" enabled for production use |
| 2014-12-30 | U.S. Patent No. 8,924,495 Issued |
| 2015-XX-XX | Alleged infringing DocuSign Winter 2015 release |
| 2026-02-20 | Complaint Filed |
II. Technology and Patent(s)-in-Suit Analysis
U.S. Patent No. 8,924,495 - "Delivery Control for HTTP Communications Among Multiple End User Communication Devices" (issued Dec. 30, 2014)
The Invention Explained
- Problem Addressed: The patent’s background section describes the uncertainty faced by the sender of an HTTP-based communication, who does not know if the recipient has actually viewed the message content unless the recipient voluntarily sends a separate confirmation (US 8,924,495 Patent, col. 2:4-22).
- The Patented Solution: The invention is a method implemented on a recipient's device for processing a received HTTP message. The message contains an "acknowledgement command" that gates access to its primary content. The system prevents the display of the message content until the user provides input authorizing an acknowledgment reply. Once authorized, the device automatically transmits a confirmation message back to the originator and simultaneously enables the display of the original message's content (US 8,924,495 Patent, abstract; US 8,924,495 Patent, col. 2:30-41).
- Technical Importance: This technology provides a system for mandatory and verifiable receipt confirmation in web-based communications, which is valuable for transactions or notifications where proof of delivery and access is critical (US 8,924,495 Patent, col. 2:23-29).
Key Claims at a Glance
- The complaint asserts at least independent claims 1 (a method), 6 (a non-transitory computer-readable medium), and 11 (a software product) (Compl. ¶22).
- The essential elements of independent claim 1 include (Compl. ¶23):
- Receiving an HTTP message comprising a user message and an acknowledgement command.
- Preventing the display of the user message's content until input is entered authorizing a reply to the acknowledgement request.
- Upon receiving the authorizing input: automatically generating and transmitting a reply HTTP message with an acknowledgement; enabling the display of the original message content; and storing a read message indicator.
- The complaint alleges infringement of "one or more claims," suggesting the right to assert additional dependent claims is reserved (Compl. ¶19).
U.S. Patent No. 8,799,385 - "Delivery Control for Email Communicated Among Multiple End User Communication Devices" (issued Aug. 5, 2014)
The Invention Explained
- Problem Addressed: The patent addresses the fact that standard email protocols do not provide a mechanism to force a recipient to send a receipt confirmation; a recipient can receive, open, and read an email without the sender's knowledge (US 8,799,385 Patent, col. 2:1-9).
- The Patented Solution: This invention describes a method implemented on the sender's device. It involves generating an email that comprises a user message and a "command portion," and inserting an "acknowledgement request" into a command field within that portion. This embedded command is designed to be executed by the recipient's device to compel an acknowledgment. The email can be transmitted using standard SMTP or HTTP protocols (US 8,799,385 Patent, abstract; US 8,799,385 Patent, col. 2:11-31).
- Technical Importance: The invention creates a mechanism for an email originator to enforce a mandatory acknowledgment of receipt, a feature not natively supported by conventional email systems and useful for certified communications (US 8,799,385 Patent, col. 2:11-17).
Key Claims at a Glance
- The complaint asserts at least independent claims 1 (a method), 7 (a non-transitory computer-readable medium), and 13 (an end-user device) (Compl. ¶34).
- The essential elements of independent claim 1 include (Compl. ¶35):
- Generating an email as a digital packet containing a user message and a command portion.
- Inserting an acknowledgement request into a command field within the command portion, wherein the request causes the addressee's device to execute predetermined steps.
- Transmitting the digital packet for delivery using SMTP or HTTP.
- The complaint reserves the right to assert other claims by alleging infringement of "one or more claims" (Compl. ¶31).
U.S. Patent No. 8,799,386 - "Delivery Control for Email Communicated Among Multiple End User Communication Devices" (issued August 5, 2014)
Multi-Patent Capsule
- Patent Identification: U.S. Patent No. 8,799,386, "Delivery Control for Email Communicated Among Multiple End User Communication Devices," issued August 5, 2014 (Compl. ¶11).
- Technology Synopsis: This patent, similar to the ’495 Patent, focuses on the recipient-side processing of a message—in this case, an email. It addresses the problem of non-mandatory receipt confirmations in email systems (US 8,799,386 Patent, col. 2:1-9). The patented solution is a method that prevents a recipient from viewing an email's content until the user explicitly authorizes a reply acknowledgment, which is then automatically transmitted to the sender (US 8,799,386 Patent, abstract).
- Asserted Claims: The complaint asserts at least claims 1, 6, 9, and 11 (Compl. ¶45).
- Accused Features: The complaint alleges that DocuSign's eSignature and IAM applications, when used to manage and control electronic communications, perform the steps claimed by the ’386 Patent (Compl. ¶43).
III. The Accused Instrumentality
Product Identification
- The accused instrumentalities are Defendant's software-based products, systems, and services, identified as "the Accused Products" (Compl. ¶14). These include, but are not limited to, Docusign eSignature and the DocuSign IAM application suite (IAM Core, IAM for Sales, and IAM for Customer Experience), as well as DocuSign CLM (Compl. ¶14).
Functionality and Market Context
- The Accused Products are described as tools for managing electronic agreements and obtaining electronic signatures (Compl. ¶14).
- The complaint alleges these products perform "delivery, receipt acknowledgment, and controlled display of HTTP communications" (Compl. ¶15). A key accused feature is a standardized "new signing experience" for recipients, which was allegedly enabled for production use in December 2014 and subsequently became the default user experience (Compl. ¶16).
- No probative visual evidence provided in complaint.
IV. Analysis of Infringement Allegations
The complaint references claim-chart exhibits that are not provided; the following tables summarize the infringement theory based on the narrative allegations in the complaint.
’495 Patent Infringement Allegations
| Claim Element (from Independent Claim 1) | Alleged Infringing Functionality | Complaint Citation | Patent Citation |
|---|---|---|---|
| receiving the first HTTP message that comprises a digital packet having a header and a user data segment, the user data segment containing a user message and an acknowledgement command... | Defendant's systems deliver an HTTP-based signing request to a recipient's device, which contains the document to be signed and data functioning as an acknowledgment command. | ¶¶15-16; ¶20 | col. 2:32-34 |
| preventing the display on a screen of the first end-user communication device of content of the received user message until input on the first end-user communication device is entered authorizing a reply to the acknowledgement request; | The accused "new signing experience" allegedly requires a recipient to interact with the interface (e.g., click to review) before the full document content is displayed, with this interaction constituting authorization. | ¶16; ¶20 | col. 2:38-41 |
| upon receiving the input authorizing the reply: automatically generating by the first end-user communication device and transmitting a reply HTTP message with an acknowledgement to the originating device... | Upon the recipient's interaction and signature, Defendant's system automatically generates and transmits a notification and/or the completed document back to the originator. | ¶15; ¶20 | col. 2:36-38 |
| enabling the display of the content of the corresponding received user message on the screen of the first end-user communication device; and | After the recipient provides the required input to proceed with the signing process, the content of the document is enabled for display. | ¶16; ¶20 | col. 2:38-41 |
| storing in the first end-user communication device a read message indicator having a value that represents that the reply HTTP message was authorized... | Defendant's platform tracks and stores the status of the signing process (e.g., "viewed," "signed"), which allegedly functions as the claimed read message indicator. | ¶15; ¶20 | col. 3:1-5 |
- Identified Points of Contention:
- Scope Questions: A central issue may be whether a standard user interface workflow, which requires a user to click a "Review Document" button before viewing a contract, meets the claim limitation of "preventing the display... until input... is entered authorizing a reply." The defense may argue this is merely navigating a webpage, not authorizing an "acknowledgement" in the specific manner claimed.
- Technical Questions: The analysis may turn on whether the accused DocuSign signing request contains a data structure that can be considered an "acknowledgement command." The question is whether the request is a functional one embedded in the system's logic or a discrete command within the data packet as potentially contemplated by the patent.
’385 Patent Infringement Allegations
| Claim Element (from Independent Claim 1) | Alleged Infringing Functionality | Complaint Citation | Patent Citation |
|---|---|---|---|
| generating, by the first end-user communication device, the email comprising a digital packet... containing a user message and a command portion; | Defendant's platform allows an originator to create and send an email notification for an e-signature request, which contains a link to the document and data that allegedly constitutes a command portion. | ¶14; ¶32 | col. 2:21-25 |
| inserting an acknowledgement request in a command field in the command portion wherein the addressee device upon receipt thereof executes predetermined steps... | When an originator creates a document for signature, the system allegedly inserts a functional requirement for the recipient to act, which Plaintiff contends is equivalent to the claimed "acknowledgement request." | ¶14; ¶32 | col. 2:25-26 |
| transmitting the digital packet for delivery to the addressee device... by using either simple mail transfer protocol or hypertext transfer protocol... | Defendant's platform transmits the generated e-signature requests to recipients via email, which uses Simple Mail Transfer Protocol (SMTP). | ¶14; ¶32 | col. 2:27-31 |
- Identified Points of Contention:
- Scope Questions: It raises the question of whether using a graphical user interface to prepare a document for signature constitutes "generating" an email and "inserting an acknowledgement request in a command field" in the technical sense described in the patent, which details specific data packet structures.
- Technical Questions: A key point of dispute may be whether the emails generated by the Accused Products contain a discrete "command field" as specified in the claim. The defense could argue that the acknowledgment function is an emergent property of the overall system workflow rather than the result of a specific command embedded in the email packet itself.
V. Key Claim Terms for Construction
For the ’495 Patent:
The Term: "acknowledgement command"
Context and Importance: The existence of this "command" in the accused HTTP messages is fundamental to the infringement allegation. Its construction will determine whether a functional instruction inherent in a system's workflow qualifies, or if a specific, coded data element is required.
Intrinsic Evidence for Interpretation:
- Evidence for a Broader Interpretation: The patent specification describes a "user data segment containing a user message and a command portion," which could support a functional interpretation where any data that directs the recipient device's behavior is part of a "command portion" (US 8,924,495 Patent, col. 2:34-36).
- Evidence for a Narrower Interpretation: The specifications of the related ’385 and ’386 patents, incorporated by reference, depict detailed byte-level structures for commands in their figures, suggesting a more limited, structured definition of a "command" rather than a purely functional one (US 8,799,386 Patent, Fig. 5).
The Term: "preventing the display on a screen... of content"
Context and Importance: This term is critical for determining whether the user interface of the accused "signing experience" meets the claim limitation. Practitioners may focus on this term because the accused products likely present a button or link to view content, rather than completely blocking any display related to the message.
Intrinsic Evidence for Interpretation:
- Evidence for a Broader Interpretation: The claim language itself does not specify the degree of prevention, which may support an argument that obscuring the main content behind a user-initiated action is sufficient.
- Evidence for a Narrower Interpretation: The abstract of the ’495 Patent states "The received user message is prevented from being displayed," and the related ’386 patent states "Viewing of the content... is prohibited," suggesting a complete restriction of access, not merely an intermediary UI step (US 8,924,495 Patent, abstract; US 8,799,386 Patent, abstract).
VI. Other Allegations
- Indirect Infringement: The complaint alleges that to the extent any claimed steps are performed by Defendant’s customers, Defendant is liable for induced infringement by "knowingly encouraging, instructing, and facilitating" use of the Accused Products through product design, documentation, and technical support (Compl. ¶21; Compl. ¶25; Compl. ¶33; Compl. ¶44; Compl. ¶48). The complaint also pleads contributory infringement, alleging the Accused Products are material components specially made for infringing use (Compl. ¶26; Compl. ¶37; Compl. ¶49).
- Willful Infringement: Willfulness is alleged based on two grounds. First, on information and belief, that Defendant had pre-suit "actual or constructive knowledge" of the patents due to their public issuance and availability (Compl. ¶27; Compl. ¶38; Compl. ¶50). Second, that Defendant has knowledge at least as of the filing of the complaint, forming a basis for ongoing willful infringement (Compl. ¶27; Compl. ¶38; Compl. ¶50).
VII. Analyst’s Conclusion: Key Questions for the Case
- A core issue will be one of definitional scope: Can terms like "acknowledgement command" and "command field", which the patents' detailed descriptions link to specific byte-level data structures, be construed broadly enough to read on the functional workflow of a modern web-based e-signature platform that may achieve a similar outcome without such explicit, low-level command codes?
- A key evidentiary question will be one of technical implementation: Does the accused "new signing experience," which requires a user to click a button to view a document, perform the function of "preventing the display" of content until an acknowledgment is "authorized," as recited in the claims? The case may turn on whether this common UI design is technically equivalent to the gatekeeping mechanism described in the patents.
- A central factual question regarding damages will be one of pre-suit knowledge: Can the Plaintiff provide evidence that the Defendant had actual knowledge of the patents-in-suit prior to the litigation, which would be necessary to substantiate the claim for pre-suit willful infringement and potential enhanced damages, or will the claim rest solely on a weaker allegation of constructive knowledge?