DCT

1:26-cv-00528

Nasdaq Private Market LLC v. Hiive Co Ltd

Log In
Key Events
Complaint
complaint Intelligence

I. Executive Summary and Procedural Information

  • Parties & Counsel:
  • Case Identification: 1:26-cv-00528, D. Del., 05/06/2026
  • Venue Allegations: Venue is alleged to be proper in the District of Delaware because three of the defendant entities are incorporated in Delaware, and the remaining two are foreign corporations subject to venue in any judicial district.
  • Core Dispute: Plaintiff alleges that Defendant's online marketplace for private securities infringes a patent related to a platform for standardizing the clearing and settlement of private company share transfers.
  • Technical Context: The technology at issue addresses the historically inefficient, manual, and non-standardized process of transferring shares in private, pre-IPO companies, aiming to bring speed and transparency to this market.
  • Key Procedural History: The complaint alleges that Plaintiff sent Defendants a cease and desist letter on March 31, 2026, providing alleged notice of the patent and the infringement claims prior to the lawsuit's filing.

Case Timeline

Date Event
2021 Plaintiff NPM becomes an independent company
2023-04-26 Earliest Priority Date for the '980 Patent
2026-03-10 U.S. Patent No. 12,572,980 Issues
2026-03-31 Plaintiff sends Cease & Desist Letter to Defendant
2026-05-06 Complaint Filed

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

U.S. Patent No. 12,572,980 - "Private Company Securities Clearing and Settlement Platform"

  • Patent Identification: U.S. Patent No. 12,572,980, "Private Company Securities Clearing and Settlement Platform," issued March 10, 2026.

The Invention Explained

  • Problem Addressed: The patent's background section describes the significant challenge in the secondary market for private company shares, where the lack of an industry-wide standard for processing transfers leads to bespoke, manual workflows and settlement timelines that can extend to 90-120 days or longer '980 Patent, col. 1:30-44 Compl. ¶18
  • The Patented Solution: The invention is a computer-implemented method and system that ingests transaction information in various non-standardized formats (e.g., from emails or different broker forms), converts this data into a standardized order format, and then automates the subsequent workflow '980 Patent, abstract '980 Patent, col. 4:37-44 This automated workflow includes generating a first notification to the share issuer to begin an approval process (such as for a right of first refusal, or ROFR) and then, after approval, generating a second set of notifications to all parties (buyer, seller, issuer) to execute the necessary transfer agreements '980 Patent, col. 5:35-5:55 '980 Patent, col. 6:7-6:22
  • Technical Importance: This technology aims to bring the efficiency, reliability, and transparency of public market clearing systems to the historically opaque and manual private secondary market Compl. ¶17

Key Claims at a Glance

  • The complaint asserts independent claim 1 Compl. ¶38
  • The essential elements of independent claim 1 are:
    • A method implemented by a private company securities platform.
    • Receiving an input in a non-standardized format for a security order.
    • Communicating with an API that provides a standardization process to convert data to a standardized order format.
    • Converting the non-standardized information into the standardized order format via the API.
    • Generating a security order with standardized data for automatic entry into user interfaces (UIs).
    • Automatically generating and populating a first notification in a first UI on an issuer's device, with this action triggering a countdown for transaction approval without further input from the issuer.
    • Automatically generating and populating a plurality of second notifications in the first UI and at least one second UI on at least one second device, requesting signatures from all parties for a transfer agreement.

III. The Accused Instrumentality

Product Identification

The complaint identifies the accused instrumentality as "Hiive's Accused Platform," which includes the "Hiive Transaction Administration" products and services and the "Hiive Issuer Interface" Compl. ¶22

Functionality and Market Context

  • The Accused Platform is described as an "alternative trading system for the secondary market trading of shares in private (unlisted) late-stage venture-backed companies and funds" Compl. ¶23 The complaint alleges the platform receives non-standardized information for security orders via channels like email Compl. ¶26 This information is then allegedly converted and used to populate user interfaces for issuers, buyers, and sellers to manage the transaction lifecycle, including triggering approvals and gathering signatures Compl. ¶¶28-30 A screenshot provided in the complaint shows an email with transaction details, representing an alleged non-standardized input Compl. p. 11
  • The complaint alleges the Accused Platform has significant market traction, citing Defendant's claims of facilitating "over $2 billion in secondary transactions across 300 private companies" Compl. ¶24

IV. Analysis of Infringement Allegations

'980 Patent Infringement Allegations

Claim Element (from Independent Claim 1) Alleged Infringing Functionality Complaint Citation Patent Citation
receiving an input in a non-standardized format and comprising non-standardized information for a security order associated with an issuer; The Hiive platform receives non-standardized information for security orders via email and other channels. ¶26 col. 3:59-4:3
communicating with an application programming interface (API) ... wherein the API provides a standardization process that enables converting data... to a standardized order format; The complaint infers that the Hiive platform communicates with an API that provides a standardization process to enable the conversion of data from non-standardized to standardized formats. ¶27 col. 2:5-9
converting the non-standardized information into the standardized order format using the standardization process via the API; The Hiive platform allegedly converts the non-standardized information (e.g., from an email) into a standardized order format. ¶27 col. 4:37-44
generating the security order comprising standardized order data based on the non-standardized information converted... The Hiive platform generates security orders with standardized data and automatically enters this information into its user interfaces, such as the Hiive Issuer Interface. ¶28 col. 4:45-57
automatically generating and populating, within a first UI on a first device associated with the issuer, a first notification including the standardized order data to the issuer, the populating of the first notification triggering a countdown for a transaction approval for the issuer automatically... The Hiive platform allegedly generates and populates notifications in the "Hiive Issuer Interface," which triggers transaction approval countdowns, including for rights of first refusal (ROFR). A complaint exhibit shows a user interface for a transaction with status tracking. Compl. p. 13 ¶29 col. 5:35-55
automatically generating and populating... a plurality of second notifications to all parties to the security order, the plurality of second notifications requesting a plurality of signatures... for a transfer agreement... The platform allegedly generates notifications requesting signatures within different interfaces for different parties (issuers, buyers, sellers) on their respective devices. A screenshot in the complaint shows a user interface with a list of tasks including "Complete the Transfer Agreement." Compl. p. 15 ¶30 col. 6:7-22
  • Identified Points of Contention:
    • Scope Questions: The infringement theory for the "communicating with an application programming interface (API)" element is based on inference Compl. ¶27 A potential point of contention is whether the accused system's internal architecture meets the construed definition of an "API" that "provides a standardization process," or if the data conversion is performed in a way that does not involve communicating with a distinct API as claimed.
    • Technical Questions: The claim requires that the first notification triggers a countdown "automatically in the first UI and with the private company securities platform without further input from the issuer." A key technical question is what level of automation this requires and whether the Accused Platform's process, which may involve user interactions to navigate the UI, operates "without further input" in the manner required by the claim.

V. Key Claim Terms for Construction

  • The Term: "non-standardized format"

    • Context and Importance: This term defines the starting point of the claimed process. The scope of the term is critical, as it determines what types of inputs fall within the claim. Practitioners may focus on this term because the Defendants could argue that their data intake, while varied, follows internal or structured formats that are not "non-standardized" in the context of the patent.
    • Intrinsic Evidence for Interpretation:
      • Evidence for a Broader Interpretation: The patent's background contrasts the invention with a market that has "no industry-wide standards" '980 Patent, col. 4:9-12, suggesting that any format not part of such a universal, public standard could be considered "non-standardized."
      • Evidence for a Narrower Interpretation: The specification provides examples of non-standardized inputs such as "an email, a phone call transcript, a direct user interface input or other mechanism" '980 Patent, col. 4:1-5 This could support an argument that the term is limited to unstructured or semi-structured human communications, not machine-readable data from other systems.

  • The Term: "automatically"

    • Context and Importance: This term appears multiple times in Claim 1 and is central to the patent's claim of an automated workflow. The degree of human intervention permitted by the term "automatically" will be a key point of dispute in determining infringement.
    • Intrinsic Evidence for Interpretation:
      • Evidence for a Broader Interpretation: A broader view might argue "automatically" simply means the computer performs the step without a user having to manually re-type or re-enter the specific data for that step, even if a user prompts the action by clicking a button.
      • Evidence for a Narrower Interpretation: The claim language "without further input from the issuer" tied to the first notification's countdown '980 Patent, col. 22:28-35 suggests a high degree of automation with no intervening human action required for that specific step. The patent's overall focus on replacing a "manual and bespoke market" Compl. ¶17 could support a narrower construction requiring minimal to no human intervention for a step to be considered "automatic."

VI. Other Allegations

  • Indirect Infringement: The complaint alleges inducement by "instructing customers and partners how to use Hiive's Accused Platform for private securities trading" Compl. ¶49 It also alleges contributory infringement, asserting that the Accused Platform is "specially made and adapted for use in trading private company securities" and is "not a staple article of commerce or suitable for any non-infringing use" Compl. ¶55
  • Willful Infringement: The complaint alleges willful infringement based on Defendants' alleged knowledge of the '980 Patent since at least March 31, 2026, the date they allegedly received a cease and desist letter from the Plaintiff Compl. ¶34 Compl. ¶43

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

  • A core issue will be one of functional operation: does the Accused Platform's workflow operate "automatically... without further input from the issuer" as strictly required by Claim 1? The case may turn on evidence of the precise level of human interaction required to move a transaction through the Defendants' system, and whether that level of interaction distinguishes it from the claimed automated method.
  • A second key issue will be one of architectural evidence: the complaint's allegation of an infringing "API" is based on inference Compl. ¶27 A central question for discovery will be whether the underlying software architecture of the Accused Platform contains a module or component that can be fairly characterized as an "API [that] provides a standardization process," or if the data transformation is performed by a monolithic or integrated function that does not meet that claim limitation as it may be construed by the court.
Loading Complaint