DCT
2:22-cv-07613
Communication Interface Tech LLC v. Lego System A S
I. Executive Summary and Procedural Information
- Parties & Counsel:
- Plaintiff: Communication Interface Technologies, LLC (Delaware)
- Defendant: Lego System AS (Denmark)
- Plaintiff’s Counsel: Law Offices Of Seth W. Wiener
- Case Identification: 2:22-cv-07613, C.D. Cal., 10/19/2022
- Venue Allegations: Plaintiff alleges that because Defendant is not a resident of the United States, venue is proper in any judicial district.
- Core Dispute: Plaintiff alleges that Defendant’s mobile applications infringe three expired patents related to establishing, maintaining, and efficiently reactivating client-server communication sessions, particularly in wireless or intermittent connectivity environments.
- Technical Context: The technology concerns methods for managing communication sessions between a client device and a server, allowing a session to enter an inactive "sleep state" and be quickly resumed without a full, resource-intensive renegotiation, a foundational concept for modern mobile application connectivity.
- Key Procedural History: The complaint states that the asserted patents have been licensed to more than 180 entities. It also notes that the lead patent was previously litigated in cases that settled before claim construction hearings were conducted and lists a significant number of more recent lawsuits filed by the Plaintiff asserting the same family of patents.
Case Timeline
| Date | Event |
|---|---|
| 1998-10-07 | Earliest Priority Date for ’239, ’296, and ’010 Patents |
| 2003-06-03 | ’239 Patent Issued |
| 2012-09-11 | ’296 Patent Issued |
| 2012-10-16 | ’010 Patent Issued |
| On or before 2018 | Accused Lego Apps Developed and Published |
| 2018-10-07 | ’239 Patent Expired |
| 2019-03-30 | ’296 and ’010 Patents Expired |
| 2022-10-19 | Complaint Filed |
II. Technology and Patent(s)-in-Suit Analysis
U.S. Patent No. 6,574,239 - "VIRTUAL CONNECTION OF A REMOTE UNIT TO A SERVER"
- Patent Identification: U.S. Patent No. 6,574,239, "VIRTUAL CONNECTION OF A REMOTE UNIT TO A SERVER," issued June 3, 2003.
The Invention Explained
- Problem Addressed: The patent’s background section describes the inefficiency of prior art client-server communication sessions, which required a complete and time-consuming renegotiation of connection parameters (including cryptographic keys) each time a connection was needed after a period of inactivity (Compl. ¶¶ 11-12; ’239 Patent, col. 2:51-62). This was particularly burdensome for mobile and wireless devices with intermittent connectivity and for dial-up modems (Compl. ¶13).
- The Patented Solution: The invention proposes a "virtual session" layer that allows a communication session to be maintained in a deactivated or "inactive" state without being fully terminated when the physical connection is dropped (’239 Patent, col. 3:33-45). By storing session parameters, such as pre-computed encryption keys, the connection can be quickly "reactivated" when needed, bypassing the lengthy initial setup process and creating a more seamless user experience (Compl. ¶12; ’239 Patent, Abstract). Figure 1A of the patent illustrates this "Virtual Session" layer (154, 156) operating between the application and transport layers of the protocol stack (’239 Patent, Fig. 1A).
- Technical Importance: This approach aimed to conserve computational resources and reduce connection latency, making applications on devices with intermittent connectivity significantly more efficient and responsive (Compl. ¶¶ 13, 16).
Key Claims at a Glance
- The complaint asserts independent claim 7 (’239 Patent, col. 26:46-61; Compl. ¶38).
- The essential elements of Claim 7, a method for a server to control a virtual session, are:
- establishing a virtual session with a remote unit to support an application layer program;
- placing the virtual session in an inactive state;
- sending a signal to the remote unit indicative of an incoming communication request and an application-program identifying packet;
- the packet identifies an application program that needs to resume a virtual session;
- placing the virtual session back into the active state and transferring data in response to the sending step.
- The complaint reserves the right to amend its infringement analysis, which may include asserting additional claims (Compl. ¶40).
U.S. Patent No. 8,266,296 - "APPLICATION-LAYER EVALUATION OF COMMUNICATIONS RECEIVED BY A MOBILE DEVICE"
- Patent Identification: U.S. Patent No. 8,266,296, "APPLICATION-LAYER EVALUATION OF COMMUNICATIONS RECEIVED BY A MOBILE DEVICE," issued September 11, 2012.
The Invention Explained
- Problem Addressed: Stemming from the same specification as the ’239 patent, this invention addresses the client-side challenge of efficiently handling an unsolicited communication from a server intended for a specific application when the session is inactive (’239 Patent, col. 2:38-50).
- The Patented Solution: The patented method involves a mobile device receiving a communication from a remote entity that was not initiated in response to a request from the device (’296 Patent, col. 29:30-40). This communication contains a "set of information identifying an application layer program." A control program on the device evaluates this information, launches the corresponding application, and reactivates the communication session, allowing the server to effectively "wake up" the correct application to receive data (’296 Patent, col. 29:41-52).
- Technical Importance: This method provides a technical framework for modern server-initiated push notifications, enabling servers to efficiently deliver information to specific applications on a mobile device without requiring the application to maintain a persistent, resource-draining active connection (Compl. ¶¶ 21-22).
Key Claims at a Glance
- The complaint asserts independent claim 1 (’296 Patent, col. 29:30-52; Compl. ¶56).
- The essential elements of Claim 1, a method performed on a mobile handset, are:
- receiving a first communication initiated by a remote entity, not in response to a request from the handset;
- the communication includes a set of information identifying an application layer program installed on the handset;
- a control program causing the handset to evaluate the set of information;
- in response to determining the information identifies the application, causing the handset to launch the application and reactivate a communication session with the remote entity.
- The complaint reserves the right to amend its infringement analysis (Compl. ¶58).
U.S. Patent No. 8,291,010 - "VIRTUAL CONNECTION OF A REMOTE UNIT TO A SERVER"
- Patent Identification: U.S. Patent No. 8,291,010, "VIRTUAL CONNECTION OF A REMOTE UNIT TO A SERVER," issued October 16, 2012.
- Technology Synopsis: This patent, which shares a specification with the ’239 and ’296 patents, claims methods for managing and reactivating communication sessions. The claims focus on a computing device receiving an unsolicited communication during an inactive session and, in response, reactivating the session after determining that the communication includes information identifying an application on the device (Compl. ¶¶ 65, 67; ’010 Patent, col. 29:11-40).
- Asserted Claims: Independent claims 1 and 17 are asserted (Compl. ¶¶ 74-75).
- Accused Features: The accused functionality involves the LEGO Apps receiving and processing push notifications from LEGO servers, which allegedly causes the apps to reactivate an inactive communication session to receive data (Compl. ¶¶ 71, 73).
III. The Accused Instrumentality
- Product Identification: The "LEGO Builder" application and other mobile applications ("Lego Apps") developed by Defendant for mobile electronic devices (Compl. ¶¶ 35, 53, 71).
- Functionality and Market Context: The complaint alleges the Accused Instrumentalities are mobile apps that communicate with remote LEGO servers using Transport Layer Security (TLS) sessions (Compl. ¶¶ 37, 55, 73). A key alleged function is the receipt of wireless push notification messages, which are sent from the remote server to the client-side application to prompt the resumption of communication (Compl. ¶¶ 37, 55, 73). The complaint includes a screenshot from the Google Play store showing the array of available LEGO apps, including "LEGO® Builder," "LEGO® Life," and others. (Compl. Ex. 4, p. 96). Plaintiff alleges these apps enhance customer engagement and increase operational efficiency for Defendant (Compl. ¶23).
IV. Analysis of Infringement Allegations
’239 Patent Infringement Allegations
| Claim Element (from Independent Claim 7) | Alleged Infringing Functionality | Complaint Citation | Patent Citation |
|---|---|---|---|
| For use in controlling a virtual session on a server, a method comprising: establishing a virtual session with a remote unit, the virtual session being instantiated to support at least one application layer program; | The server-side Lego Application and the client-side Lego App establish a Transport Layer Security (TLS) session, which allegedly functions as the claimed "virtual session." This session supports communications for the Lego App (the application layer program). | ¶38; Ex. 4, p. 97 | col. 9:5-14 |
| placing the virtual session in an inactive state; | When the application data transfer phase of the TLS session is complete, the session is placed into an inactive state pending further communication. | ¶38; Ex. 4, p. 98 | col. 10:57-62 |
| sending a signal indicative of an incoming communication request and an application-program identifying packet to said remote unit... | The Lego Application server sends a push notification message to the user's mobile device (remote unit). This push notification allegedly serves as the claimed signal and packet. | ¶38; Ex. 4, p. 98 | col. 24:1-26 |
| ...said application-program identifying packet identifying an application program that needs to resume a virtual session and communicate with said remote unit; and | The push notification allegedly includes an "app-specific device token" that identifies the Lego App as the intended recipient, thereby identifying the application program that needs to resume the session. | ¶38; Ex. 4, p. 99 | col. 26:50-55 |
| placing the virtual session back into the active state and transferring data between the application and the remote unit via the virtual session in response to said step of sending. | In response to the push notification, the TLS session is resumed using an abbreviated handshake sequence, placing it back into an active state to allow new data to be transferred between the Lego server and the App. | ¶38; Ex. 4, p. 100 | col. 10:29-33 |
- Identified Points of Contention:
- Scope Questions: A central issue may be whether a standardized "TLS session," governed by modern internet protocols (RFCs), meets the limitations of the term "virtual session" as defined and described in the 1998-priority-date patent. Further, it raises the question of whether an "app-specific device token," used by a third-party notification gateway (e.g., Google's FCM) for routing, constitutes an "application-program identifying packet" in the manner contemplated by the claim.
- Technical Questions: What is the precise mechanism by which the push notification causes the session to become active? Does the token within the notification directly enable the resumption as required by the claim's "in response to said step of sending" language, or does it merely trigger a separate, user- or OS-mediated process that then initiates a standard TLS resumption?
’296 Patent Infringement Allegations
| Claim Element (from Independent Claim 1) | Alleged Infringing Functionality | Complaint Citation | Patent Citation |
|---|---|---|---|
| A method, comprising: receiving, at a control program executing on a mobile handset, a first communication initiated by a remote entity... | The Lego App, executing on a smartphone, receives a push notification message initiated by a remote Lego server. | ¶56; Ex. 5, p. 113 | col. 29:30-34 |
| ...wherein the first communication includes a set of information identifying an application layer program that is installed on the mobile handset... | The push notification message includes an app-specific device token, which allegedly serves as the "set of information" that identifies the Lego App. | ¶56; Ex. 5, p. 114 | col. 29:35-38 |
| ...and wherein initiation of the first communication by the remote entity was not in response to a request sent by the mobile handset; | Push notifications are "call-out" type messages sent by the server asynchronously and are not sent in direct response to a "pull" request from the mobile handset. | ¶56; Ex. 5, p. 114 | col. 29:39-40 |
| the control program causing the mobile handset to evaluate the set of information included in the first communication; and | The mobile device's operating system and the Lego App's control program are connected and allegedly evaluate the app-specific device token to determine which application should handle the new information. | ¶56; Ex. 5, p. 114 | col. 29:41-44 |
| in response to determining...that the set of information identifies the application layer program, the control program causing the mobile handset to: launch the application layer program; and reactivate, from an inactive state, a communication session... | Upon user interaction with the notification, the control program determines the Lego App is the target, causing the App to launch or come to the foreground and reactivating the previously inactive TLS session with the server. | ¶56; Ex. 5, p. 115 | col. 29:45-52 |
- Identified Points of Contention:
- Scope Questions: Does the "control program" that performs the "evaluating" and "causing" steps reside within the Lego App itself, or is it a function of the underlying mobile operating system (e.g., Android OS)? The distinction may be critical for claim construction and infringement analysis.
- Technical Questions: What specific technical act constitutes "launching the application layer program"? Does displaying a notification banner qualify, or does it require the full application to be brought to the foreground? The complaint's chart suggests both interpretations may be at play, creating a potential point of dispute.
V. Key Claim Terms for Construction
The Term: "virtual session"
Context and Importance: This term is the foundation of the asserted patents. Its construction will determine whether a modern, standardized TLS session falls within the patent's scope. Practitioners may focus on this term because Defendant could argue that TLS session resumption is a distinct, later-developed technology, while Plaintiff may argue that it is merely a modern implementation of the broader "virtual session" concept taught in the patent.
Intrinsic Evidence for Interpretation:
- Evidence for a Broader Interpretation: The specification describes the concept broadly, stating the "virtual session layer allows a communication session and an application session to be maintained in a deactivated state when no physical connection exists" (’239 Patent, col. 3:33-37).
- Evidence for a Narrower Interpretation: The patent also describes specific embodiments, such as a "virtual session server" that "maintains a table linking one or more application sessions to a virtual session" using specific parameters like logon data and modem settings (’239 Patent, col. 8:56-65, Fig. 2). Defendant may point to these details to argue for a narrower construction limited to such specific architectures.
The Term: "application-program identifying packet" (’239 Patent) / "set of information identifying an application layer program" (’296 Patent)
Context and Importance: Plaintiff's infringement theory relies on mapping this term to the "app-specific device token" in a modern push notification. The definition of this term is critical because the token's primary purpose in the accused system is for routing by a third-party gateway, not necessarily for session resumption by the client device itself.
Intrinsic Evidence for Interpretation:
- Evidence for a Broader Interpretation: The claims require the packet to identify an application that "needs to resume a virtual session" (’239 Patent, col. 26:53-55), a functional description that Plaintiff may argue is met by the token's role in directing the notification to the correct app.
- Evidence for a Narrower Interpretation: The specification provides an example where different types of communications (voice call, email) are identified using a "caller identification packet" (’239 Patent, col. 24:1-12, Fig. 8). Defendant may argue this suggests a more direct identification scheme than the indirect routing function of a modern push notification token.
VI. Other Allegations
- Indirect Infringement: The complaint does not contain specific factual allegations to support the knowledge and intent elements required for claims of induced or contributory infringement.
- Willful Infringement: The complaint does not contain allegations of willful infringement or a request for enhanced damages.
VII. Analyst’s Conclusion: Key Questions for the Case
- A core issue will be one of definitional scope: can the term "virtual session," conceived in the context of 1990s-era dial-up and early wireless protocols, be construed to cover a modern, standardized Transport Layer Security (TLS) session and its specific resumption mechanisms? The answer will likely depend on whether the court views the patent as claiming a broad functional concept or a more specific architectural implementation.
- A key evidentiary question will be one of technical causation: does the "app-specific device token" in the accused push notification system function as the claimed "application-program identifying packet" that directly enables session resumption, or is it merely a routing instruction for an intermediary service, with the actual session reactivation being a separate process initiated by the operating system or user, potentially breaking the causal link required by the claims?