PTAB

IPR2025-00795

Intel Corp v. Advanced Cluster Systems Inc

Key Events
Petition
petition

1. Case Identification

2. Patent Overview

  • Title: Parallelizing Mathematical Software on Computer Clusters
  • Brief Description: The ’768 patent describes a system for adapting single-computer mathematical application programs, such as Mathematica, to run in parallel on a computer cluster. The system uses cluster node modules and Message-Passing Interfaces (MPIs) to distribute tasks across multiple nodes in a peer-to-peer architecture.

3. Grounds for Unpatentability

Ground 1: Claims 26, 29, 35-36, and 39 are obvious over Menon, Trefethen, RS6000, and POEref.

  • Prior Art Relied Upon: Menon (a 1997 conference proceeding on "MultiMATLAB"), Trefethen (a 1996 technical report on MultiMATLAB), RS6000 (an IBM product manual for the RS/6000 SP system), and POEref (an IBM product manual for the Parallel Operating Environment).
  • Core Argument for this Ground:
    • Prior Art Mapping: Petitioner argued that Menon and Trefethen collectively disclose "MultiMATLAB," a system that parallelizes the MATLAB mathematical tool to run on a cluster of processors using a peer-to-peer architecture and MPI for communication, thus teaching the core limitations of the challenged claims. Specifically, Trefethen was cited to show a precise sequence of operations required by the claims: a first node sends data to a second, the second performs a calculation and sends the result to a third, which performs another calculation and communicates the result back to the first node for user display. RS6000 and POEref were presented as product manuals for the IBM SP2 hardware and its operating environment, which Menon explicitly identifies as the platform for which MultiMATLAB was designed. These references were argued to supply the predictable, known details of the underlying hardware, such as nodes with multiple processing cores.
    • Motivation to Combine: A POSITA would combine Menon and Trefethen because they are companion papers by the same research team describing the same MultiMATLAB system, with Menon expressly citing Trefethen. A POSITA implementing the system described in Menon on its specified IBM SP2 platform would be motivated to consult the corresponding IBM product manuals (RS6000 and POEref) for implementation details.
    • Expectation of Success: A POSITA would have a high expectation of success, as the combination involved implementing the MultiMATLAB software (Menon, Trefethen) on the exact hardware platform and operating environment (RS6000, POEref) for which it was designed, yielding the predictable result of a functioning parallel computing system.

Ground 2: Claims 27-28 and 37-38 are obvious over Menon, Trefethen, RS6000, and POEref, further in view of MPIref.

  • Prior Art Relied Upon: Menon, Trefethen, RS6000, POEref, and MPIref (the 1994 Message-Passing Interface Standard).
  • Core Argument for this Ground:
    • Prior Art Mapping: This ground built upon Ground 1, adding MPIref to address claims reciting specific details of asynchronous communication commands and data packets. Petitioner argued that while Menon discloses using the MPI communication standard, MPIref provides the explicit technical details of that standard. MPIref was cited to teach the syntax and function of standard asynchronous commands like MPI_SEND and MPI_RECV, including the creation of packets containing a payload (the expression) and a target node address. Petitioner contended that these details in the official MPI standard rendered the specific command and packet limitations of claims 27, 28, 37, and 38 obvious.
    • Motivation to Combine: A POSITA would combine MPIref with the other references because Menon explicitly states that MultiMATLAB uses "the MPI communication standard" as its communication layer. To implement this system, a POSITA would have been directly motivated to consult MPIref, the foundational document defining that standard, for the necessary technical specifications of communication commands.
    • Expectation of Success: The expectation of success was argued to be high, as it involved using the official MPI standard (MPIref) to implement the communication layer of a system (Menon's MultiMATLAB) that was expressly designed to use that very standard.

4. Key Claim Construction Positions

  • "peer-to-peer architecture": For the purposes of the petition, Petitioner adopted the Patent Owner's construction from a prior proceeding: "an architecture in which each node can communicate tasks and data with other nodes without the tasks and data being required to go through a central server or master node."
  • "a mechanism for...": Petitioner argued this is a means-plus-function term under pre-AIA 35 U.S.C. § 112, sixth paragraph. The recited function is communicating results between nodes, and the corresponding structure disclosed in the specification was identified as an "MPI module," specifically the "MPI module 302" which implements MPI calls.

5. Arguments Regarding Discretionary Denial

  • Fintiv: Petitioner argued against discretionary denial under Fintiv, asserting that the petition was filed promptly and well before the one-year statutory bar. A parallel district court trial is scheduled for November 2026, which is after the likely date for a Final Written Decision (FWD). Petitioner also filed a Sotera stipulation in the district court, agreeing not to pursue any invalidity grounds in that case that were raised or reasonably could have been raised in the IPR if instituted.
  • Advanced Bionics (§ 325(d)): Petitioner argued denial would be inappropriate because the prior art asserted in the petition was not considered by the examiner during prosecution. Furthermore, the art was argued to be materially different from that considered in prior, uninstituted IPRs against the same patent, particularly Trefethen's explicit teaching of the sequential node-to-node communication that the Board previously found lacking in other art.
  • General Plastic: Petitioner contended that follow-on petition factors weigh against denial because Intel is a different petitioner from the filer of the previous IPRs (NVIDIA) and did not coordinate with them. Petitioner asserted it presented materially different grounds and did not use the Board's prior decisions as a "roadmap."

6. Relief Requested

  • Petitioner requested the institution of an inter partes review and cancellation of claims 26-29 and 35-39 of the ’768 patent as unpatentable.