DCT

1:20-cv-03810

Trust & Verify Data Protection LLC v. Vimeo Inc

I. Executive Summary and Procedural Information

  • Case Name: Trust & Verify Data Protection LLC v. Vimeo Inc.
  • Parties & Counsel:
  • Case Identification: 1:20-cv-03810, S.D.N.Y., 05/15/2020
  • Venue Allegations: Venue is alleged to be proper in the Southern District of New York because Defendant has committed acts of patent infringement and maintains an established place of business in the District.
  • Core Dispute: Plaintiff alleges that Defendant’s unnamed products and services infringe a patent related to protecting digital data and software from unauthorized analysis and modification.
  • Technical Context: The technology concerns methods for securing software by dynamically altering its executable code at runtime to prevent inspection and reverse engineering.
  • Key Procedural History: The complaint does not mention any prior litigation, inter partes review (IPR) proceedings, or licensing history related to the patent-in-suit.

Case Timeline

Date Event
2000-07-18 ’735 Patent Priority Date
2007-01-09 ’735 Patent Issue Date
2020-05-15 Complaint Filing Date

II. Technology and Patent(s)-in-Suit Analysis

U.S. Patent No. 7,162,735 - “Digital data protection arrangement,”

The Invention Explained

  • Problem Addressed: The patent describes the vulnerability of conventional software, which, when loaded into a computer's memory (RAM), exists in an unencrypted and exposed form, making it susceptible to unauthorized copying, analysis by hackers, or virus attacks (’735 Patent, col. 1:9-14, col. 3:11-17).
  • The Patented Solution: The invention proposes a two-stage execution process to shield software. Initially, a small, trusted "ENGINE" is loaded into memory (’735 Patent, col. 3:24-27). When the protected application is called, this ENGINE dynamically generates the application's executable code. Crucially, instead of writing a complete, viewable program, the ENGINE can replace a key operational step of the application with a "CALL" instruction that points to a separate "PROTECTION block" (’735 Patent, col. 5:19-24; Fig. 3d). This protection block performs security checks. If the checks pass, it then overwrites the CALL instruction with the original, intended operational code, allowing the application to proceed. This ensures the complete, functional application code is never exposed in memory at one time until it is actively and legitimately running (’735 Patent, col. 5:41-51).
  • Technical Importance: This self-modifying code approach was designed to defeat static analysis and debugging tools by making the program's structure ephemeral and dependent on runtime conditions, presenting a constantly changing and incomplete target to a "malevolent watcher" (’735 Patent, col. 6:8-16).

Key Claims at a Glance

  • The complaint alleges infringement of one or more unspecified claims, referring to them as the "Exemplary '735 Patent Claims" identified in an unprovided exhibit (Compl. ¶11, ¶17). Independent claim 4 is representative of the technology.
  • Independent Claim 4 Elements:
    • A digital data arrangement comprising protected code and security code,
    • wherein the protected code comprises incomplete executable code, the executable code including one or more call instructions to the security code,
    • and the security code, when executed, replaces a respective call instruction with executable code,
    • such that the executable code of the protected code is completed upon execution of all call instructions.
  • The complaint does not explicitly reserve the right to assert dependent claims, but refers generally to "one or more claims" (Compl. ¶11).

III. The Accused Instrumentality

Product Identification

The complaint does not name any specific accused products or services in its main body. It refers to "Exemplary Defendant Products" that are identified in "charts incorporated into this Count" (Compl. ¶11) and in an "Exhibit 2" (Compl. ¶17), neither of which were filed with the complaint.

Functionality and Market Context

The complaint does not provide sufficient detail for analysis of the accused instrumentality's specific functionality or market context. It makes only a general allegation that the unnamed products "practice the technology claimed by the '735 Patent" (Compl. ¶17).

IV. Analysis of Infringement Allegations

The complaint alleges that an unprovided document, Exhibit 2, "includes charts comparing the Exemplary '735 Patent Claims to the Exemplary Defendant Products" (Compl. ¶17). Because this exhibit is not available, a detailed claim chart summary cannot be constructed. The complaint's narrative infringement theory is that the "Exemplary Defendant Products" practice the claimed technology and "satisfy all elements of the Exemplary '735 Patent Claims" (Compl. ¶17).

No probative visual evidence provided in complaint.

Identified Points of Contention

  • Factual Basis: A threshold issue for the court may be whether the complaint, by failing to identify any specific accused products or their functions and instead relying on an unprovided exhibit, meets the plausibility standard for pleading patent infringement under Twombly/Iqbal.
  • Technical Questions: A central dispute, once the accused technology is identified, will likely be whether it performs the specific actions required by the claims. For instance, does the accused system actually generate "incomplete executable code" and then "replace a respective call instruction with executable code" (’735 Patent, col. 16:28-34)? Or does it achieve security through other means common in modern software, such as sandboxing, virtualization, or application-level encryption, which may not map to the patent's specific mechanism? The significant time gap between the patent's 2000 priority date and the current software environment suggests a potential for a fundamental technical mismatch.

V. Key Claim Terms for Construction

"incomplete executable code" (from Claim 4)

Context and Importance

The definition of this term is fundamental. The plaintiff's infringement case requires showing the accused products use code that is "incomplete." The scope of this term will determine whether it is limited to the specific embodiments shown or can cover a broader range of dynamically generated software.

Intrinsic Evidence for Interpretation

  • Evidence for a Broader Interpretation: The claim language itself does not specify how the code must be incomplete, which may support a construction covering any code that is not fully functional until runtime modification.
  • Evidence for a Narrower Interpretation: The specification consistently illustrates this concept with a specific example: a sequence of program steps where one step (e.g., "STEP 2") is physically absent and replaced by a "CALL instruction" (’735 Patent, col. 5:19-24, Fig. 3d). A party could argue this context limits the term to code that is missing entire instructional blocks that are later inserted.

"replaces a respective call instruction with executable code" (from Claim 4)

Context and Importance

This term describes the core protective action of the invention. Its construction will be critical in determining whether the accused products perform the claimed function. Practitioners may focus on this term because modern software architectures may achieve similar security goals without performing the literal "replacement" action described.

Intrinsic Evidence for Interpretation

  • Evidence for a Broader Interpretation: A party might argue that "replaces" should be construed functionally to mean any process that logically substitutes a security routine for a program step at runtime, regardless of the underlying memory operations.
  • Evidence for a Narrower Interpretation: The patent describes the security block creating code for a missing step and "written over the CALL instruction 36" (’735 Patent, col. 5:46-48). This suggests a direct, in-place memory overwrite. A defendant could argue that this limits the claim to this specific implementation, excluding systems that use pointers, just-in-time compilers, or other indirect methods to execute code.

VI. Other Allegations

Indirect Infringement

The complaint alleges induced infringement, stating that Defendant sells its products to customers for use in an infringing manner and distributes "product literature and website materials" that induce this use (Compl. ¶14-15). It also alleges contributory infringement, asserting the accused products "are not a staple article of commerce suitable for substantial noninfringing use" (Compl. ¶16).

Willful Infringement

The complaint alleges willfulness based on post-suit knowledge. It asserts that "service of this Complaint upon Defendant constitutes actual knowledge" and that Defendant's continued infringement despite this knowledge is willful (Compl. ¶13-14). No allegations of pre-suit knowledge are made.

VII. Analyst’s Conclusion: Key Questions for the Case

  • A core issue will be one of technical implementation: Does the accused Vimeo technology, developed long after the patent's priority date, actually perform the specific self-modifying code sequence claimed—physically replacing a call instruction with application code in memory—or does the infringement allegation depend on an overly broad and abstract interpretation of the claim language that ignores fundamental differences in software architecture?
  • The case will also present a question of definitional scope: Can the term "replaces," rooted in the patent's depiction of a direct memory overwrite, be construed to cover modern software security methods that may achieve a logically similar outcome (i.e., executing a check before a function) through entirely different technical means?
  • Finally, a key procedural question will be one of pleading sufficiency: Does the complaint, which omits any identification of the accused products or their functionality from its body and relies on an unprovided exhibit, state a plausible claim for relief, or will it be found deficient for failing to provide the defendant with adequate notice of the factual basis for the suit?