DCT
1:23-cv-00967
Magic Labs Inc v. Horkos Inc
I. Executive Summary and Procedural Information
- Parties & Counsel:
- Plaintiff: Magic Labs, Inc. (Delaware)
- Defendant: Horkos, Inc. d/b/a Privy (Delaware)
- Plaintiff’s Counsel: McCarter & English, LLP; Morrison & Foerster LLP
- Case Identification: 1:23-cv-00967, D. Del., 12/22/2023
- Venue Allegations: Venue is asserted in the District of Delaware based on Defendant Privy’s incorporation in the state.
- Core Dispute: Plaintiff alleges that Defendant’s embedded digital wallet product infringes two patents related to non-custodial methods for generating, storing, and using cryptographic keys for decentralized applications.
- Technical Context: The technology concerns foundational infrastructure for "Web3," enabling businesses to offer secure, user-friendly blockchain wallet services without directly holding (taking custody of) users' private keys.
- Key Procedural History: The complaint alleges that Privy's co-founder learned details of Magic's technology during discussions in late 2021 and early 2022 and subsequently modeled Privy's product on Magic's technology. Plaintiff also alleges it provided Defendant with pre-suit notice of the '321 patent and notice of the application that would issue as the '120 patent.
Case Timeline
| Date | Event |
|---|---|
| 2019-09-24 | Earliest Priority Date for ’321 and ’120 Patents |
| 2021-01-01 | Privy founded (approximate year) |
| 2021-09-01 | Privy co-founder allegedly learns of Magic’s technology (Fall 2021) |
| 2022-02-01 | Magic and Privy co-founders allegedly discuss Privy modeling its tech on Magic’s (Feb 2022) |
| 2022-04-01 | Privy closes $8.3 million seed funding round (April 2022) |
| 2023-01-03 | U.S. Patent No. 11,546,321 ('321 Patent) Issues |
| 2023-09-01 | Magic sends Privy letter notifying it of the ’321 Patent |
| 2023-11-14 | U.S. Patent No. 11,818,120 ('120 Patent) Issues |
| 2023-12-22 | First Amended Complaint Filed |
II. Technology and Patent(s)-in-Suit Analysis
U.S. Patent No. 11,546,321 - “Non-Custodial Tool for Building Decentralized Computer Applications,” issued January 3, 2023
The Invention Explained
- Problem Addressed: The patent describes the challenge of managing private keys for blockchain applications. Prior solutions suffered from significant drawbacks: personal hardware security modules (HSMs) were expensive and cumbersome; centralized servers created single points of failure and security risks; and in-browser storage was vulnerable to various attacks, exposing user keys (Compl. ¶¶25-30; ’321 Patent, col. 1:5-42). These issues created a conflict between security and user convenience (Compl. ¶32).
- The Patented Solution: The invention proposes a "non-custodial" authentication system that decouples key generation and storage from a central service provider. A public-private key pair is generated on the client's device (e.g., in a secure browser iframe), but is then encrypted by a remote, third-party service, such as a cloud-based HSM, using credentials obtained via a temporary access token. This architecture, illustrated in Figure 2A of the patent, prevents the central authentication server from ever accessing the user's unencrypted private key, thereby enhancing security while maintaining a convenient software-based user experience (Compl. ¶¶31, 33-37; ’321 Patent, Abstract, col. 4:35-5:31).
- Technical Importance: This architecture aimed to solve a core usability problem in Web3 by allowing developers to offer the security benefits of hardware-based key management with the simplicity of a standard email or social login, without forcing the end-user or the application developer to directly manage the complexities of private keys (Compl. ¶32).
Key Claims at a Glance
- The complaint asserts infringement of at least independent claim 11 (Compl. ¶44).
- Claim 11 (System Claim) essential elements include:
- A non-transitory computer readable storage medium with a program for performing a non-custodial authentication method.
- Sending, over a network by the client to an authentication system, a sign-up request.
- Receiving, at the client from the authentication system, an access token for use at a third party key storage system.
- Generating a key by the client.
- Sending, from the client to the third party key storage system, one or more messages that include the access token, the key, and a request to encrypt the key, while bypassing the authentication system.
- The complaint does not explicitly reserve the right to assert dependent claims for this patent.
U.S. Patent No. 11,818,120 - “Non-Custodial Tool for Building Decentralized Computer Applications,” issued November 14, 2023
The Invention Explained
- Problem Addressed: As a continuation of the '321 patent, the '120 patent addresses the same technical problems related to secure and user-friendly private key management for decentralized applications (Compl. ¶20; ’120 Patent, col. 1:12-49).
- The Patented Solution: The technology is identical to that of the '321 patent, focusing on a non-custodial architecture where a client device interacts directly with a third-party security service to manage encrypted keys, bypassing the primary authentication server. This patent focuses more on the method of using the stored key to sign transactions (Compl. ¶¶69-71; ’120 Patent, col. 6:11-37, Fig. 2B).
- Technical Importance: The solution provides a method for users to securely authorize blockchain transactions without repeatedly exposing their private key or managing complex hardware, a critical function for any digital wallet (Compl. ¶¶23-24).
Key Claims at a Glance
- The complaint asserts infringement of at least independent claims 1 and 9, and dependent claim 6 (Compl. ¶67).
- Claim 1 (Method Claim) essential elements include:
- Receiving, by a first computing environment (client), an access token corresponding to a user authentication by a second computing environment (server).
- Sending a request, bypassing the second computing environment, from the first computing environment to a third party security system to access a decrypted version of private key information.
- Receiving the decrypted version of the private key information at the first computing environment.
- Signing the transaction data with the decrypted version of the private key information.
- Sending the signed transaction data for submission to a decentralized network.
- Claim 9 (Dependent on Claim 1) adds the limitation that the signing step occurs "within an iframe at the first computing environment" ('120 Patent, col. 12:12-15).
III. The Accused Instrumentality
Product Identification
- The accused instrumentality is Defendant Privy’s embedded wallet product, including its related software development kit (SDK), services, and functionalities (collectively, "the Accused System") (Compl. ¶42).
Functionality and Market Context
- The Accused System is a software toolkit that allows developers to integrate "beautiful authentication flows and powerful embedded wallets" into their applications (Compl. ¶46). This enables end-users to create and use a Web3 wallet through familiar methods like email or social login, without needing a separate wallet application or browser extension (Compl. ¶¶16, 46). A screenshot from Privy's website shows options for "External Wallet" and "Embedded Wallet," with the latter facilitating new user onboarding (Compl. ¶46, p. 15). Privy markets its embedded wallets as "fully self-custodial," stating that "Neither Privy nor integrating applications ever have access to embedded wallet private keys" (Compl. ¶47, p. 17). The complaint alleges this functionality directly competes with Magic's offerings (Compl. ¶15).
IV. Analysis of Infringement Allegations
’321 Patent Infringement Allegations
| Claim Element (from Independent Claim 11) | Alleged Infringing Functionality | Complaint Citation | Patent Citation |
|---|---|---|---|
| sending, over a network by the client to an authentication system, a sign-up request for a user account associated with the decentralized application | The Accused System provides an interface that prompts a user to create a wallet to sign up for a decentralized application. A screenshot shows a "Don't have a wallet? Create one now." prompt. | ¶48-49 | col. 4:34-45 |
| receiving over the network at the client from the authentication system, an access token that corresponds to the sign-up request, for use at a third party key storage system | Upon user login, the Accused System issues a JSON Web Token (JWT) described as an "auth token" or "access token." This token is used to authorize subsequent requests. | ¶51-53 | col. 4:46-55 |
| generating a key by the client | Privy's documentation states that for embedded wallets, "The wallet's public and private keys are generated in your user's client." | ¶54-55 | col. 5:3-13 |
| sending over the network from the client to the third party key storage system and bypassing the authentication server, one or more messages that include the access token, the key, and a request to encrypt the key | The Accused System splits the private key into shares. One share, the "Recovery share," is encrypted by Privy using a key stored in a hardware security module (HSM). The complaint alleges that retrieving this share requires the user's access token, thereby mapping to the claimed step. | ¶56-57 | col. 5:14-24 |
- Identified Points of Contention:
- Scope Questions: Does Privy’s architecture, which splits a private key into multiple shares (e.g., Device, Auth, Recovery shares using Shamir's Secret Sharing) and encrypts only one of them (the "Recovery share") using an HSM, meet the claim limitation of sending "the key" for encryption? A court may need to determine if "the key" can be read to mean a component or share of the key essential for its recovery.
- Technical Questions: What evidence shows that the client sends the "access token" and a "request to encrypt the key" directly to the "third party key storage system," thereby "bypassing the authentication server"? The complaint relies on Privy's documentation describing the use of an HSM, which it equates with the claimed third-party system (Compl. ¶57). The specific network paths and division of responsibilities will be a focus of discovery.
’120 Patent Infringement Allegations
| Claim Element (from Independent Claim 1) | Alleged Infringing Functionality | Complaint Citation | Patent Citation |
|---|---|---|---|
| receiving, by a first computing environment, an access token that corresponds to a user authentication by a second computing environment | The Accused System (first computing environment/client) receives a JWT access token after authentication by Privy's backend systems (second computing environment). | ¶69, 72-73 | col. 4:46-55 |
| sending a request bypassing the second computing environment, by the first computing environment to access a decrypted version of a private key information from a third party security system | The client uses the access token to request decryption of the "Recovery share" from the HSM (third party security system), bypassing Privy's main infrastructure (second computing environment). | ¶70, 72 | col. 5:25-31 |
| receiving, in response to the request, the decrypted version of the private key information at the first computing environment from the third party security system | The client receives the decrypted "Recovery share" which, combined with other shares, allows for reconstitution of the full private key. | ¶70 | col. 5:32-35 |
| signing, by the first computing environment, the transaction data with the decrypted version of the private key information | The Accused System reconstitutes the private key in-memory within an isolated iframe on the client and uses it to sign transactions. A diagram from Privy's documentation shows the isolated iframe handling wallet operations. | ¶71, 77 | col. 5:36-39 |
- Identified Points of Contention:
- Scope Questions: Can the term "private key information" be construed to cover one of several cryptographic "shares" of a key? The infringement theory depends on equating the "Recovery share" with the claimed "private key information."
- Technical Questions: Does the Accused System's process of reconstituting a key from multiple shares (one of which is decrypted) meet the limitation of signing with "the decrypted version of the private key information"? This raises a question of functional and technical equivalence between decrypting a whole key versus decrypting a share to enable assembly of the whole key.
V. Key Claim Terms for Construction
’321 Patent
- The Term: "bypassing the authentication server"
- Context and Importance: This term is central to the patent's "non-custodial" value proposition, as it describes how the client can interact with the key storage system without exposing the key or credentials to the primary application server. The infringement case hinges on demonstrating that Privy's architecture operates this way (Compl. ¶56).
- Intrinsic Evidence for Interpretation:
- Evidence for a Broader Interpretation: The specification states, "The server is bypassed in this step, and cannot forge or intercept the scoped credentials" ('321 Patent, col. 4:61-64). This functional description could support an interpretation where any architecture preventing the server from intercepting the key/credentials qualifies as "bypassing."
- Evidence for a Narrower Interpretation: Figure 2A shows distinct communication lines (216, 217, 218) between the Client (110), 3rd Party Service (155), and HSM (175) that do not route through the Server (125). This could support a narrower, structural interpretation requiring a direct network path that excludes the server entirely.
’120 Patent
- The Term: "private key information"
- Context and Importance: The infringement reading for the '120 patent depends on this term covering the "Recovery Share" used in Privy's multi-share key system. Practitioners may focus on this term because if it is construed to mean only the entire private key, the infringement allegations may be weakened, as Privy's system involves decrypting only a portion of the information needed to reconstruct the key.
- Intrinsic Evidence for Interpretation:
- Evidence for a Broader Interpretation: The term itself is general. The patent's overall goal is secure key management, and an encrypted, essential share could be argued to be a form of "private key information" because without it, the key is unusable.
- Evidence for a Narrower Interpretation: The specification repeatedly refers to encrypting and decrypting "the private key" or "the encrypted private keys" as a whole unit ('321 Patent, col. 5:18-24, col. 6:20-24). This language may suggest that "private key information" was intended to refer to the entire key, not a mathematically divided share of it.
VI. Other Allegations
- Indirect Infringement: The complaint alleges inducement by citing Privy’s extensive online documentation, reference materials, and advertising that allegedly instruct and encourage its customers (application developers) to implement the Accused System in an infringing manner (Compl. ¶¶58, 60, 78, 80).
- Willful Infringement: The complaint alleges both pre- and post-suit willfulness. It asserts pre-suit knowledge of the '321 patent via a notice letter sent on September 1, 2023 (Compl. ¶59). It further alleges that Privy's co-founder had knowledge of Magic's technology and modeled Privy's system after it following meetings in 2021 and 2022, suggesting potential copying (Compl. ¶¶17-18). For the '120 patent, it alleges knowledge based on a pre-issuance notice letter regarding the parent application (Compl. ¶79).
VII. Analyst’s Conclusion: Key Questions for the Case
- A core issue will be one of architectural equivalence: can the patent claims, which describe a system where "the key" is encrypted and decrypted, be construed to read on the Accused System's more complex architecture that uses Shamir's Secret Sharing to split a private key into multiple shares and only requires decryption of one share to enable reconstitution of the full key?
- A second key question will be one of definitional scope: does the term "private key information" in the '120 patent encompass a single cryptographic share of a key, or is it limited to the entire private key itself? The outcome of this construction could be dispositive for the infringement analysis of the signing method claims.
- Finally, an evidentiary question will center on intent and copying: what evidence, beyond the complaint's allegations, will emerge regarding the early-stage discussions between the parties' founders and the extent to which Privy's technology was, in fact, modeled on Magic's? This will be critical to the willfulness claim.