Implicit LLC v. Sandvine Corp

I. Executive Summary and Procedural Information

• Parties & Counsel:
  • Plaintiff: Implicit, LLC (Washington)
  • Defendant: Sandvine Corporation (Canada)
  • Plaintiff’s Counsel: Singer/Bea LLP; The Davis Firm, PC
• Case Identification: 2:18-cv-00054, E.D. Tex., 03/08/2018
• Venue Allegations: Plaintiff alleges venue is proper because Defendant conducts substantial business in the district, places products into the stream of commerce with the expectation of purchase in the forum, and derives substantial revenue from goods and services provided in the district.
• Core Dispute: Plaintiff alleges that Defendant’s products incorporating the Procera Network Application Visibility Library (NAVL) infringe three patents related to dynamically identifying and applying sequences of routines to process network data packets.
• Technical Context: The patents relate to the field of network data processing, specifically to methods for efficiently demultiplexing and converting data streams that may arrive in various formats and require different processing steps.
• Key Procedural History: The complaint does not provide information regarding prior litigation involving the patents-in-suit, Inter Partes Review (IPR) proceedings, or relevant licensing history.

Case Timeline

Date	Event
1999-12-29	Earliest Priority Date for '683, '790, and '104 Patents
2014-04-08	U.S. Patent No. 8,694,683 Issued
2016-02-23	U.S. Patent No. 9,270,790 Issued
2017-03-07	U.S. Patent No. 9,591,104 Issued
2018-03-08	Complaint Filed

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

U.S. Patent No. 8,694,683, "Method and System for Data Demultiplexing," issued April 8, 2014

The Invention Explained

• Problem Addressed: The patent’s background describes the inefficiency of processing network data that must be converted through many different intermediate formats (e.g., from an Ethernet format through IP and TCP to a final application format). Computer systems traditionally used predefined, static configurations to handle these conversions, which creates high overhead and lacks the flexibility to handle data formats that are not known in advance ('683 Patent, col. 1:21-60).
• The Patented Solution: The invention provides a system that dynamically identifies a correct sequence of conversion routines, or "message handlers," to process a data packet. This sequence is termed a "path." Once identified for the first packet of a message, the system stores this path so it can be quickly retrieved and applied to subsequent packets of the same message, thereby avoiding repeated searches and efficiently "demultiplexing" multiple, distinct data streams ('683 Patent, col. 2:41-68). Figure 4 illustrates how different paths can share common lower-level protocol sessions (e.g., Ethernet, IP) while branching to unique higher-level sessions (e.g., TCP) ('683 Patent, Fig. 4).
• Technical Importance: This approach sought to replace static configurations for network protocol stacks with a more flexible system capable of handling diverse and dynamically arriving data streams ('683 Patent, col. 2:5-11).

Key Claims at a Glance

• The complaint asserts independent claim 1 ('Compl. ¶19).
• Claim 1 of the ’683 Patent recites an apparatus comprising a processing unit and memory with instructions to:
  • create, based on information in a received packet, a "path" that includes data structures indicating a "sequence of routines" for processing packets;
  • store the created path;
  • process subsequent packets using the stored path's indicated sequence of routines;
  • wherein the sequence includes a routine to execute a Transmission Control Protocol (TCP) to convert packets from a TCP format to a different format.

U.S. Patent No. 9,270,790, "Method and System for Data Demultiplexing," issued February 23, 2016

The Invention Explained

• Problem Addressed: As a continuation of the application leading to the ’683 Patent, the ’790 Patent addresses the same technical problem of inefficiently processing network data requiring multiple, dynamically determined format conversions (’790 Patent, col. 1:24-63).
• The Patented Solution: The ’790 Patent describes the same core solution of creating and storing a "path" of "message handlers" to process data packets. The claims of this patent, however, focus more specifically on the mechanism used to identify the correct path for a given packet (’790 Patent, col. 2:44-67). The detailed description, shared with the ’683 Patent, explains that a path can be associated with a session identified by a key (’790 Patent, col. 8:51-60).
• Technical Importance: This technology aims to provide a flexible and efficient alternative to static network protocol stack configurations (’790 Patent, col. 2:5-14).

Key Claims at a Glance

• The complaint asserts independent claim 1 (Compl. ¶25).
• Claim 1 of the ’790 Patent recites an apparatus comprising a processing unit and memory with instructions to:
  • identify a "path" for received packets, where the path indicates a "sequence of two or more routines";
  • the path is identified based on a "key located in one of the received packets," which includes an "IP address and a port address";
  • process the packets using the identified path's sequence of routines;
  • wherein the sequence includes a routine to execute a Transmission Control Protocol (TCP) to convert packets from a TCP format to a different format.

U.S. Patent No. 9,591,104, "Method and System for Data Demultiplexing," issued March 7, 2017

Technology Synopsis

The ’104 Patent, part of the same patent family, addresses the problem of efficiently processing network data that requires multiple, dynamically determined format conversions. The patented solution involves a system that identifies a sequence of "message handlers" or routines to form a processing "path" for a given message, based on a key derived from packet information, and then stores this path to quickly process subsequent packets of the same message (’104 Patent, col. 1:24-63, col. 2:44-67).

Asserted Claims

The complaint asserts independent claim 1 (Compl. ¶31).

Accused Features

The complaint alleges that Defendant’s products incorporating the Procera Network Application Visibility Library infringe the ’104 Patent (Compl. ¶¶ 14, 31).

III. The Accused Instrumentality

Product Identification

The complaint identifies the accused instrumentalities as "certain products (the 'Sandvine Accused Products'), including but not limited to products that incorporate the Procera Network Application Visibility Library ('NAVL')" (Compl. ¶14).

Functionality and Market Context

The complaint does not provide specific technical details regarding the operation or features of the NAVL software. It alleges that Sandvine makes, uses, sells, or imports these products within the United States (Compl. ¶14). The complaint does not contain allegations regarding the products' specific commercial importance or market positioning.

No probative visual evidence provided in complaint.

IV. Analysis of Infringement Allegations

The complaint provides conclusory allegations of infringement without mapping specific features of the accused products to the elements of the asserted claims. It states, for example, that "[t]he Sandvine Accused Products are covered by at least claim 1 of the '683 Patent" (Compl. ¶19). This level of detail precludes the creation of a summary claim chart based on the complaint's contents.

’683 Patent Infringement Allegations

• Identified Points of Contention:
  • Evidentiary Question: A primary evidentiary question will be what features, if any, within the Procera NAVL software perform the claimed functions of creating a "path," storing that path, and using the stored path to process subsequent packets according to an indicated "sequence of routines."
  • Scope Question: A potential point of contention may be whether the operations performed by the accused NAVL software constitute "creating" a "path" as claimed, or if the software utilizes a different, non-infringing logic for processing data packets.

’790 Patent Infringement Allegations

• Identified Points of Contention:
  • Technical Question: The infringement analysis will likely focus on whether the Accused Products identify a processing "path" based on a "key located in one of the received packets" that specifically includes an "IP address and a port address," as required by the claim.
  • Scope Question: A dispute may arise over the definition of the "key." The question may be whether simply using header information like an IP address and port number for routing decisions is sufficient to meet this limitation, or if the claim requires the creation of a formal "key" data structure used to look up a specific, stored processing path.

V. Key Claim Terms for Construction

Term from '683 Patent, Claim 1: "a sequence of routines"

• Context and Importance: This term is central to the claimed invention, defining the nature of the processing "path." Its construction will determine what level of software modularity and execution order within the accused products could constitute infringement. Practitioners may focus on this term because its scope could distinguish between a pre-compiled, monolithic processing function and the dynamically assembled sequence described in the patent.
• Intrinsic Evidence for Interpretation:
  • Evidence for a Broader Interpretation: The specification uses the general term "message handlers" to describe the components of the sequence, suggesting any series of distinct software functions that process a packet could qualify (’683 Patent, col. 2:47).
  • Evidence for a Narrower Interpretation: The patent’s primary embodiment illustrates the routines as corresponding to entire network protocol layers, such as Ethernet, IP, and TCP (’683 Patent, Fig. 4; col. 5:41-50). This may support a narrower construction limiting "routines" to complete, self-contained protocol handlers rather than smaller sub-functions.

Term from '790 Patent, Claim 1: "key located in one of the received packets"

• Context and Importance: This term defines the mechanism for path identification. Its construction is critical because it dictates how the accused system must use packet data to select the appropriate processing sequence. The dispute will likely center on whether any use of packet header data suffices, or if a more specific action of generating and using a "key" is required.
• Intrinsic Evidence for Interpretation:
  • Evidence for a Broader Interpretation: The claim language recites that the key "includes an IP address and a port address," which may support an interpretation that any set of data derived from a packet's header fields for routing purposes constitutes the "key."
  • Evidence for a Narrower Interpretation: The specification describes using a key to retrieve a "session," which stores state information for a message (’790 Patent, col. 8:51-60). This could support a narrower interpretation where the "key" must be a formal data structure used specifically to look up a stateful session that, in turn, dictates the processing path.

VI. Other Allegations

• Indirect Infringement: The complaint alleges inducement of infringement based on Sandvine allegedly supplying the Accused Products and "instructing such consumers (for example in instructional manuals or videos...)" on how to use them in an infringing manner (Compl. ¶¶ 21, 27, 33). It also alleges contributory infringement, asserting that Sandvine provides "Accused Components," including the Procera NAVL, that are "especially made or especially adapted" to practice the invention and are not staple articles of commerce suitable for substantial noninfringing use (Compl. ¶¶ 22, 28, 34).
• Willful Infringement: The complaint alleges willful infringement based on knowledge obtained "as of the filing and service of this Complaint" (Compl. ¶¶ 23, 29, 35). This suggests the willfulness claim is based on alleged post-suit continuation of infringement rather than pre-suit knowledge.

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

The resolution of this case will likely depend on the answers to a few central questions for the court:

• A central evidentiary issue will be establishing the specific operation of the accused Procera NAVL software. The complaint's lack of technical detail raises the question of what discovery will reveal about whether NAVL creates, stores, and reuses a "path" corresponding to a "sequence of routines" as claimed, or if it employs a fundamentally different technical architecture.
• A core legal question will concern claim construction, particularly the scope of "a sequence of routines." The case may turn on whether this term is construed broadly to cover any series of packet-processing software functions, or more narrowly to require a dynamically assembled sequence of distinct protocol handlers as depicted in the patent's embodiments.
• A key technical question for the ’790 and ’104 Patents will be one of functional specificity: do the accused products merely use packet header information for routing, or do they generate and use a "key" containing an IP address and port address to explicitly identify a pre-defined processing path, as the claim language requires?