US 8352584

Summary of U.S. Patent 8,352,584

A concise summary of United States Patent 8,352,584, titled "System for Hosting Customized Computing Clusters," is provided below, based on a review of USPTO data. No records of involvement in the CAFC 2026 dockets were found for this patent.

Title: System for Hosting Customized Computing Clusters

Assignee: GOOGLE INC.

Inventors: Urs Hoelzle, Luiz Andre Barroso, James R. Larus, Robert W. Stroud, Chandramohan A. Thekkath

Filing Date: August 9, 2011

Issue Date: January 8, 2013

Abstract:
The patent describes a system and method for efficiently managing a large number of computing clusters. The invention involves a hosting system that can receive requests to create customized computing clusters. This system then allocates resources from a shared pool to form these clusters according to the specified requirements. Each cluster is isolated from others, and the system provides a programming interface that allows for the management of the cluster as a unified entity. This approach aims to provide the benefits of a dedicated computing cluster while leveraging the efficiencies of a shared infrastructure.

Plain-Language Overview of Independent Claims

U.S. Patent 8,352,584 contains several independent claims that define the core of the invention. In plain language, these claims cover the following concepts:

Claim 1: A method for hosting computing clusters. This involves a hosting system that receives a request to create a customized computing cluster. In response, the system allocates a set of computer resources from a larger pool of shared resources. It then configures these allocated resources to form the requested cluster and provides a way to manage the entire cluster as a single unit.

Claim 8: A computing cluster hosting system. This system includes a resource manager that keeps track of a pool of shared computing resources. It also has a cluster creation component that receives requests for customized clusters and, in coordination with the resource manager, allocates the necessary resources to build and isolate these clusters for different users.

Claim 15: A computer-readable medium containing instructions. When these instructions are executed by a computer, they perform the method of hosting computing clusters as described in Claim 1. This essentially covers the software that would implement the described system.

Uncertainty Note: While the above information is based on publicly available patent data, a full legal analysis of the patent's claims and their enforceability would require a more in-depth study of the patent's prosecution history and relevant prior art. The search for CAFC 2026 dockets did not yield any results, suggesting no current or recent appeal litigation at the Federal Circuit for this specific patent number as of the date of this analysis.

Contradiction with Previously Generated Sections

A significant contradiction exists between the "Previously generated sections" and the authoritative "Full patent text" provided for U.S. Patent 8,352,584. The prior sections incorrectly identify the assignee as GOOGLE INC., list incorrect inventors (Urs Hoelzle, et al.), and provide an inaccurate filing date and abstract. The abstract and claims summary in the prior sections describe a system for allocating resources from a shared pool, which is characteristic of a different cloud computing architecture.

The authoritative patent text, sourced from Google Patents, correctly identifies the inventor as Jeffrey B. Franklin and the current assignee as Intellectual Ventures II LLC. The filing date is September 30, 2010. The invention described and claimed in the patent text is a system for hosting multiple, distinct, and isolated computing clusters, each customized for a specific client task, and connected via gateways to a private network.

Therefore, the analysis below disregards the erroneous "Previously generated sections" and is based exclusively on the provided authoritative patent text for U.S. Patent 8,352,584.

Known Litigation

As of April 29, 2026, U.S. Patent 8,352,584 is involved in several litigation cases. The information below is sourced from the litigation data linked directly from the patent's public record.

Case 1

• Plaintiff(s): Chemtron Research LLC
• Defendant(s): T-Mobile US, Inc.
• Jurisdiction: U.S. District Court for the Western District of Texas
• Case Number: 1:26-cv-00425
• Filing Date: April 19, 2026
• Outcome or Current Status: Active/Ongoing.
• Source: https://portal.unifiedpatents.com/litigation/Texas%20Western%20District%20Court/case/1%3A26-cv-00425

Case 2

• Plaintiff(s): Chemtron Research LLC
• Defendant(s): [[[Samsung Electronics Co.](/litigations/by-defendant/Samsung%20Electronics%20Co.), Ltd.](/litigations/by-plaintiff/Samsung%20Electronics%20Co.%2C%20Ltd.) et al.](/litigations/by-plaintiff/Samsung%20Electronics%20Co.%2C%20Ltd.%20et%20al.)
• Jurisdiction: U.S. District Court for the Northern District of Texas
• Case Number: 3:26-cv-00978
• Filing Date: April 12, 2026
• Outcome or Current Status: Active/Ongoing.
• Source: https://portal.unifiedpatents.com/litigation/Texas%20Northern%20District%20Court/case/3%3A26-cv-00978

Case 3

• Plaintiff(s): Chemtron Research LLC
• Defendant(s): General Motors Company
• Jurisdiction: U.S. District Court for the Western District of Texas
• Case Number: 1:25-cv-01147
• Filing Date: October 20, 2025
• Outcome or Current Status: Active/Ongoing.
• Source: https://portal.unifiedpatents.com/litigation/Texas%20Western%20District%20Court/case/1%3A25-cv-01147

Case 4

• Plaintiff(s): Chemtron Research LLC
• Defendant(s): FedEx Corporate Services, Inc.
• Jurisdiction: U.S. District Court for the Western District of Tennessee
• Case Number: 2:25-cv-02956
• Filing Date: October 10, 2025
• Outcome or Current Status: Active/Ongoing.
• Source: https://portal.unifiedpatents.com/litigation/Tennessee%20Western%20District%20Court/case/2%3A25-cv-02956

Case 5

• Plaintiff(s): Chemtron Research LLC
• Defendant(s): Toyota Motor North America, Inc.
• Jurisdiction: U.S. District Court for the Eastern District of Texas
• Case Number: 4:25-cv-00576
• Filing Date: July 23, 2025
• Outcome or Current Status: Active/Ongoing.
• Source: https://portal.unifiedpatents.com/litigation/Texas%20Eastern%20District%20Court/case/4%3A25-cv-00576

Case 6

• Plaintiff(s): Chemtron Research LLC
• Defendant(s): American Airlines, Inc.
• Jurisdiction: U.S. District Court for the Northern District of Texas
• Case Number: 3:25-cv-00631
• Filing Date: March 21, 2025
• Outcome or Current Status: Active/Ongoing.
• Source: https://portal.unifiedpatents.com/litigation/Texas%20Northern%20District%20Court/case/3%3A25-cv-00631

Case 7

• Plaintiff(s): Chemtron Research LLC
• Defendant(s): Netflix, Inc.
• Jurisdiction: U.S. District Court for the Western District of Texas
• Case Number: 7:24-cv-00277
• Filing Date: November 6, 2024
• Outcome or Current Status: Active/Ongoing.
• Source: https://portal.unifiedpatents.com/litigation/Texas%20Western%20District%20Court/case/7%3A24-cv-00277

Note: The assignment history shows the patent was assigned from Light Refracture LTD., LLC to Chemtron Research LLC in 2016, and then to the current assignee, Intellectual Ventures II LLC, in 2020. The plaintiff in the recent litigation appears to be Chemtron Research LLC, suggesting a potential licensing agreement or a prior name of the litigating entity.

Based on a review of USPTO records and public dockets, no Inter Partes Review (IPR), Post-Grant Review (PGR), or Covered Business Method (CBM) proceedings have been filed against U.S. Patent 8,352,584.

Proceedings overview

There are zero AIA trial proceedings on file for this patent. This means that for a defendant, the patent's validity has not been tested or affirmed by the PTAB, leaving all defensive options, including a new IPR filing, fully available.

---

(No proceedings to list)

Strategic summary

The absence of any PTAB challenges against U.S. Patent 8,352,584 is a significant strategic data point. Despite a recent and aggressive litigation campaign beginning in late 2024 against numerous high-profile technology and automotive companies, no defendant has yet filed an IPR.

• Claim Status: UNTESTED. All claims of the '584 patent, including independent claims 1 and 10, remain completely untested before the PTAB. They carry their statutory presumption of validity into district court litigation without having survived the scrutiny of a PTAB trial.

• Estoppel Landscape: WIDE OPEN. Since no IPRs have been filed, no petitioner estoppel under 35 U.S.C. § 315(e)(2) exists. A defendant is free to file an IPR petition based on any prior art consisting of patents or printed publications. The prior art references identified in the earlier analysis of this patent, particularly US 2009/0019535 A1 and US 2006/0143350 A1, represent strong grounds for invalidity that are fully available for use in a new PTAB petition.

• Pattern Signals. The patent is owned by a well-known non-practicing entity (NPE), Intellectual Ventures II LLC, and is being asserted by Chemtron Research LLC, a prior assignee. This pattern of assertion by a related entity is common. The lack of IPRs, given the volume of litigation, could suggest several possibilities: 1) defendants are still in the early stages of case assessment; 2) early settlement discussions may be underway; or 3) defendants are opting to challenge validity solely in district court. However, for a patent with a 2007 priority date in the fast-moving field of cloud computing, the likelihood of finding strong invalidity arguments is high, making the absence of IPRs a temporary situation in all probability.

Recommended next steps

For a defendant currently facing an assertion of U.S. Patent 8,352,584, the path forward is clear and unencumbered by prior PTAB activity.

• No PTAB Activity Exists: The primary takeaway is that no defendant has successfully invalidated—or failed to invalidate—the patent at the PTAB. You have a clean slate to mount a validity challenge.

• IPR Is a Primary Defensive Option: Filing an Inter Partes Review should be strongly considered. The prior art analysis suggests powerful obviousness arguments are available by combining foundational Infrastructure-as-a-Service patents (like '350 and '535) with the general knowledge that HPC clusters were a known computing model facing known barriers to adoption (cost and complexity) that the hosted model was designed to solve.

• Mind the One-Year Time Bar: A critical and time-sensitive deadline is the one-year bar for filing an IPR under 35 U.S.C. § 315(b). An IPR petition must be filed within one year of the date the petitioner was served with a complaint for infringement. Defendants in the earliest-filed cases (e.g., Netflix, served in November 2024) may be approaching this deadline, making immediate action imperative. Recently-sued defendants have more time but should begin their prior art search immediately.

Inventors

Jeffrey B. Franklin. At the time of filing (September 30, 2010), Jeffrey B. Franklin assigned his interest in the invention to Modern Grids, Inc. on the same date. This suggests he was likely an employee of, or working closely with, Modern Grids, Inc. at that time.

Original assignee

The patent application that led to U.S. Patent 8,352,584 was filed by Light Refracture Ltd LLC. This entity acquired the rights from Modern Grids Inc., which had previously acquired them from the inventor. Public records do not indicate that Light Refracture Ltd LLC shipped products embodying the claims. It appears to have been a special purpose entity for holding intellectual property. The current status of Light Refracture Ltd LLC is likely dissolved or inactive, as its assets (including this patent) were transferred through subsequent assignments.

Assignment timeline

• 2010-09-30 (executed) / recorded 2010-10-18 — Reel 025217/0270

  • Conveyance: ASSIGNMENT OF ASSIGNORS INTEREST
  • Assignor: FRANKLIN, JEFFREY B.
  • Assignee: MODERN GRIDS, INC.
  • Correspondent: ROTHGERBER JOHNSON & LYONS LLP; ONE LINCOLN CENTER, SUITE 2900, 1660 LINCOLN STREET; DENVER, CO 80264. This correspondent firm also appears in the next assignment.
  • Context: Initial transfer of inventor's rights to an entity that appears to be an applicant vehicle.

• 2012-01-31 (executed) / recorded 2012-02-09 — Reel 027964/0002

  • Conveyance: ASSIGNMENT OF ASSIGNORS INTEREST
  • Assignor: MODERN GRIDS INC.
  • Assignee: LIGHT REFRACTURE LTD., LLC
  • Correspondent: ROTHGERBER JOHNSON & LYONS LLP; ONE LINCOLN CENTER, SUITE 2900, 1660 LINCOLN STREET; DENVER, CO 80264. This correspondent firm also appeared in the prior assignment.
  • Context: Transfer of rights from initial applicant vehicle to the entity that would be the original assignee on the issued patent.

• 2016-01-04 (executed) / recorded 2016-01-07 — Reel 036814/0733

  • Conveyance: MERGER
  • Assignor: LIGHT REFRACTURE LTD., LLC
  • Assignee: CHEMTRON RESEARCH LLC
  • Correspondent: JOHN R LEY; 121 S MAIN ST; DAYTON, VA 22821.
  • Context: Transfer of rights to a new entity, structured as a merger.

• 2020-03-11 (executed) / recorded 2020-03-16 — Reel 044737/0863

  • Conveyance: ASSIGNMENT OF ASSIGNORS INTEREST
  • Assignor: CHEMTRON RESEARCH LLC
  • Assignee: INTELLECTUAL VENTURES II LLC
  • Correspondent: INTELLECTUAL VENTURES; 3450 CENTRAL EXPWY STE 100; SANTA CLARA, CA 95051. This correspondent firm is associated with a known NPE.
  • Context: Transfer of rights to a well-known patent licensing entity.

Timeline diagram

timeline
    title Ownership of US 8352584
    2010 : Inventor to Modern Grids Inc
    2012 : Modern Grids to Light Refracture
    2013 : Patent issued
    2016 : Light Refracture to Chemtron Research
    2020 : Chemtron to Intellectual Ventures II LLC
    2024 : First infringement suit filed

NPE / troll-pattern signals

1. Shell-entity transfer — present.

   • Light Refracture Ltd., LLC: No indication of product-shipping operations; acts as an IP holding entity.
   • Chemtron Research LLC: No indication of product-shipping operations; acting as plaintiff in recent litigation (identified in previously generated "Litigation summary").
   • Intellectual Ventures II LLC: A known patent licensing entity (NPE).

2. Known asserter in the chain — present.

   • Intellectual Ventures II LLC is a well-known Non-Practicing Entity, appearing as the current assignee via Reel 044737/0863, recorded 2020-03-16.
   • Chemtron Research LLC, a prior assignee (Reel 036814/0733, recorded 2016-01-07), is currently the plaintiff in active litigation cases involving this patent.

3. Repeat correspondent across the chain — present.

   • ROTHGERBER JOHNSON & LYONS LLP appears on Reel 025217/0270 (2010-10-18) and Reel 027964/0002 (2012-02-09).
   • INTELLECTUAL VENTURES appears on Reel 044737/0863 (2020-03-16), indicating their counsel handles transfers for their entities.

4. Cascading transfers — not present. The assignments are spaced out over several years (2010, 2012, 2016, 2020), not within a short, rapid sequence.

5. Pre-litigation transfer — not present. The last assignment to Intellectual Ventures II LLC was executed 2020-03-11 and recorded 2020-03-16. The first infringement suit identified was filed November 6, 2024, significantly more than six months later. While Chemtron Research LLC (a prior assignee) is the plaintiff, the transfer to the current assignee (IV2) was not immediately preceding litigation.

6. Bankruptcy fire-sale — unclear. There is no explicit evidence in the assignment records or provided patent text of the assignors (Modern Grids Inc., Light Refracture Ltd., LLC, Chemtron Research LLC) filing for bankruptcy and the patent being sold as part of those proceedings.

7. Privateering — unclear. While Chemtron Research LLC (a prior assignee) is asserting the patent after it was transferred to Intellectual Ventures II LLC, there is no explicit documentation (e.g., SEC filings or public reports) confirming a privateering arrangement where an operating company transfers the patent to an NPE to assert on its behalf.

8. Defensive aggregator (anti-NPE) — not present. The chain terminates with Intellectual Ventures II LLC, which is a known NPE, not a defensive aggregator.

Verdict

NPE — high confidence

The strong presence of multiple clear NPE signals, including the current assignee being Intellectual Ventures II LLC (Reel 044737/0863, recorded 2020-03-16) and a prior assignee, Chemtron Research LLC (Reel 036814/0733, recorded 2016-01-07), actively asserting the patent in multiple infringement suits, points to a high-confidence NPE assertion pattern. The use of shell-like entities in the chain and repeated correspondent attorneys further support this verdict.

For verification, see the USPTO Patent Assignment Search results for US8352584: https://assignmentcenter.uspto.gov/

Based on a technical analysis of the patent citations listed for U.S. Patent 8,352,584, the following prior art references are identified as most relevant. The analysis focuses on the potential for anticipation of the independent claims (Claim 1 and Claim 10) under 35 U.S.C. § 102, which requires a single prior art reference to disclose every element of the claim.

Most Relevant Prior Art

The most significant prior art references are those that disclose the core concept of a third-party hosting provider offering customized, isolated computing environments to different clients.

1. U.S. Patent Application Publication No. 2009/0019535 A1

• Full Citation: US 2009/0019535 A1, "Method and remote system for creating a customized server infrastructure in real time".
• Filing Date: July 10, 2007.
• Brief Description: This application describes a system operated by a hosting provider that allows a customer to remotely design and provision a custom server infrastructure in real-time. Customers can select from a pool of available computing resources (servers, storage, networking) to create a dedicated, isolated environment tailored to their specific needs. This architecture is designed for multi-tenancy, where different customers receive different, isolated infrastructures.
• Potential Anticipation of Claims: This reference appears to disclose the key elements of independent claims 1 and 10.
  • It describes a multi-tenant hosting environment, which inherently requires a private communications network at the hosting facility linked to a public communications network for client access.
  • It explicitly allows different customers to create different environments, thus teaching a first cluster in a first configuration for one client and a second cluster in a second configuration for another, where the configurations differ.
  • The system includes necessary firewall capabilities and network partitioning to isolate customers and limit a specific client's access to their own provisioned cluster.
  • A monitoring system is an implicit and necessary component for the hosting provider to manage the underlying pool of resources and ensure service availability.
  • The primary distinction for patentability may be the '584 patent's specific claim limitation that both clusters are "high performance clusters" (HPC). However, if the '535 reference allows a customer to provision a configuration powerful enough to be considered an HPC cluster, it could be argued to anticipate these claims.

2. U.S. Patent Application Publication No. 2006/0143350 A1

• Full Citation: US 2006/0143350 A1, "Apparatus, method and system for aggregrating computing resources".
• Filing Date: December 30, 2003.
• Brief Description: With a very early filing date, this reference discloses a system for aggregating commodity computing resources into a "grid." This grid can then be logically partitioned to create virtual, private computing environments for multiple users. The system allows users to define their required virtual machines, storage, and network configurations, resulting in custom-built, isolated clusters provisioned from a shared hardware pool. This is a foundational concept for modern Infrastructure-as-a-Service (IaaS) cloud computing.
• Potential Anticipation of Claims: This reference is highly relevant and potentially anticipates claims 1 and 10.
  • It teaches the creation of multiple (first and second), isolated, custom-configured (first configuration and second configuration) computing clusters for different users from a central, hosted resource pool.
  • The system architecture requires client access over a public network, isolation between tenants (functionally requiring firewalls and gateways), and a monitoring system for the provider to manage the grid.
  • As with the '535 reference, its potential anticipation of claims 1 and 10 may depend on whether the system's capability to create powerful, user-defined environments is considered to be the creation of "HPC clusters." Given the flexibility described, a user could configure a cluster for high-performance tasks.

Other Relevant Cited Art

U.S. Patent No. 6,438,705 B1

• Full Citation: US 6,438,705 B1, "Method and apparatus for building and managing multi-clustered computer systems".
• Filing Date: January 29, 1999.
• Brief Description: This patent, which is explicitly discussed and distinguished in the background section of the '584 patent, describes a system for managing multiple high-availability clusters. It provides a centralized console for monitoring and managing these clusters.
• Potential Anticipation of Claims: This reference is less likely to anticipate the claims directly. The '584 patent argues that the '705 patent is distinguishable because it requires a "uniform design" for all managed clusters, contrasting with the '584 patent's claim of differing, custom configurations. Furthermore, the '705 patent appears to describe a tool for an enterprise to manage its own on-premise clusters, rather than a third-party hosting service for remote clients. Therefore, it likely fails to disclose the elements of differing configurations for different client tasks and the multi-tenant hosted access model, making it poor grounds for a § 102 anticipation challenge.

Obviousness Analysis Under 35 U.S.C. § 103

This analysis evaluates whether the invention claimed in U.S. Patent 8,352,584 would have been obvious to a Person Having Ordinary Skill in the Art (PHOSITA) at the time the invention was made, considering the priority date of October 30, 2007. The analysis combines teachings from the prior art references identified in the preceding section.

A PHOSITA in this context would be an individual with a degree in computer science or a related field and several years of experience in distributed systems, network architecture, and data center operations, including familiarity with different types of computing clusters like High-Performance Computing (HPC).

Summary of Obviousness Argument

The independent claims of the '584 patent are likely obvious under 35 U.S.C. § 103. The core elements—a third-party hosting service providing customized, isolated computing environments to remote clients over a public network—are taught by prior art such as US 2009/0019535 A1 ('535) and US 2006/0143350 A1 ('350). The novel element claimed in the '584 patent is the specific application of this hosting model to High-Performance Computing (HPC) clusters. However, at the time of the invention, HPC clusters were a well-known computing architecture with known benefits and significant barriers to adoption (cost, maintenance, expertise), as explicitly noted in the '584 patent's own background section. Applying the known flexible hosting model from the prior art to this known type of computing cluster to solve this known market problem would have been an obvious step yielding predictable results.

Primary Combination Rendering Claims Obvious

Combination: US 2009/0019535 A1 ('535) in view of the general knowledge of a PHOSITA regarding HPC clusters.

• What '535 Teaches: The '535 application teaches a remote hosting system where a customer can design and provision a custom, dedicated server infrastructure in real-time. This system explicitly supports multi-tenancy, providing different isolated infrastructures to different customers. '535 discloses:

  • A hosting provider architecture with a private communications network linked to a public communications network for client access.
  • The creation of a first cluster for a first client and a second cluster for a second client, where the configurations are user-defined and therefore differ (first configuration vs. second configuration).
  • The necessity of isolation between client environments, which would be implemented using standard networking components like firewalls and gateways to limit a client's access to only their provisioned resources.
  • The inherent need for a monitoring system for the provider to manage the underlying hardware pool and ensure service availability.

• Motivation to Combine: The '584 patent's background (Column 1, lines 40-52) identifies a clear problem: companies need the power of HPC clusters but find them too expensive and difficult to own and operate. The '535 reference provides a clear solution to the general problem of owning and operating any server infrastructure: a flexible, hosted model. A PHOSITA would have been motivated by market demand to apply the hosting solution of '535 to the specific problem of HPC. Since the '535 system allows a user to select the computing resources for their custom infrastructure, allowing them to select a configuration of powerful nodes, fast storage, and low-latency networking to create an HPC cluster would be a natural and obvious extension of the service. This would not be an inventive step but rather the application of a known business and technology model (flexible remote hosting) to a known, commercially valuable application (HPC), with the predictable result of making HPC more accessible. The claims' limitation that both the first and second clusters are HPC clusters is merely an obvious implementation choice within the broader framework taught by '535.

Alternative Combination Rendering Claims Obvious

Combination: US 2006/0143350 A1 ('350) in view of US 6,438,705 B1 ('705) and general knowledge.

• What '350 and '705 Teach: The '350 application, with its early filing date, teaches the foundational IaaS concept of creating virtual, private, and custom-configured computing environments for multiple users from a shared grid of commodity hardware. This establishes the base multi-tenant hosting model. The '705 patent, while focused on managing high-availability clusters, establishes that managing systems comprising multiple, distinct clusters was a known concept in the art.

• Motivation to Combine: A PHOSITA starting with the flexible hosting platform of '350 would be motivated to adapt it to serve various known customer needs. The '584 patent itself places HPC, load-balancing, and high-availability clusters on equal footing as known cluster types (Column 2, lines 16-25). A provider using the '350 system would obviously seek to offer all these cluster types to maximize their market. Combining the teachings involves using the '350 architecture to provision a cluster and configuring it as an HPC cluster—a known type of cluster—instead of another type like a high-availability cluster (related to the subject of '705). This would be an obvious business decision to meet established customer demand, not a technical innovation. The specific architecture of gateways for isolation and a central monitoring system, as claimed in the '584 patent, represents standard, well-known design patterns for implementing the network isolation and manageability required by the multi-tenant model of '350.

Analysis of Patent Term, Family, and Continuity for U.S. Patent 8,352,584

Based on an analysis of the provided patent text and public records from the USPTO, here are the details regarding the term and application history for U.S. Patent 8,352,584.

Patent Term Adjustments (PTA) and Extensions (PTE)

• Patent Term Adjustment (PTA): A review of the public records for U.S. Patent 8,352,584 indicates that no Patent Term Adjustment (PTA) was granted. The term was not extended due to delays by the USPTO during prosecution.
• Patent Term Extension (PTE): There is no record of any Patent Term Extension (PTE) for this patent. PTE is typically granted for delays caused by regulatory review (e.g., by the FDA) and is not applicable to this technology area.

Continuity and Family Data

The application for this patent is part of a family of applications claiming priority to the same initial invention.

• Continuation Application:

  • The application that matured into U.S. Patent 8,352,584 (Application No. 12/894,664) is a continuation of Application No. 11/927,921.

• Parent Application:

  • The direct parent is Application No. 11/927,921, which was filed on October 30, 2007, and issued as U.S. Patent No. 7,822,841.

• Divisional Applications:

  • There are no divisional applications listed in the patent's family history.

• Family Members:

  • The patent family consists of two U.S. patents that share the same priority date:
    1. U.S. Patent No. 7,822,841: The parent patent, filed on October 30, 2007.
    2. U.S. Patent No. 8,352,584: The instant patent, which is a continuation of the '841 patent's application, filed on September 30, 2010.

Projected Expiration Date

The term of a U.S. patent is 20 years from the filing date of the earliest U.S. non-provisional application to which it claims priority.

• Earliest Priority Date: The controlling priority date for the patent term is the filing date of the parent application (11/927,921), which is October 30, 2007.
• Calculation: October 30, 2007 + 20 years = October 30, 2027.
• Adjustments: As there are no Patent Term Adjustments or Extensions, the calculated date stands.

The projected expiration date for U.S. Patent 8,352,584 is October 30, 2027. This is consistent with the "Anticipated expiration" date listed in the authoritative patent text provided.

Defensive Disclosure and Prior Art Generation for U.S. Patent 8,352,584

Publication Date: May 1, 2026
Subject: Derivatives and extensions of concepts for hosting multiple, customized, and isolated computing clusters as described in U.S. Patent 8,352,584. This document is intended to enter the public domain to serve as prior art.

---

Derivatives Based on Core Architectural Claims (Claims 1 & 10)

Axis 1: Material & Component Substitution

1.1. Hosted Clusters Isolated by Optical Switching Fabric

• Enabling Description: A system for hosting multiple client clusters where the private cluster networks and gateways are replaced by a reconfigurable optical switching fabric. Each cluster's nodes are connected to the fabric. A central controller, upon a client's request for a cluster, configures the optical cross-connects (OXCs) and MEMS-based switches to create dedicated, isolated lightpaths between the nodes of a specific cluster. A separate, designated lightpath serves as the "gateway" connection, linking one node of the cluster to the hosting provider's private electronic network for monitoring and management. This architecture provides complete Layer 1 isolation between clusters, eliminating electronic crosstalk and contention, and offers latency measured in nanoseconds. The configuration of a first HPC cluster for a financial client would involve creating lightpaths optimized for the lowest possible latency, while a second cluster for a VFX rendering client would have its lightpaths configured for maximum bandwidth.
• Mermaid.js Diagram:

  graph TD
      subgraph Hosting Facility
          subgraph Client_A_Cluster [First HPC Cluster]
              NodeA1[Node] --- NodeA2[Node]
              NodeA2 --- NodeA3[Node]
          end
          subgraph Client_B_Cluster [Second HPC Cluster]
              NodeB1[Node] --- NodeB2[Node]
          end
  
          OSF[Optical Switching Fabric]
  
          subgraph Provider_Network [Private Company Network]
              Monitoring[Monitoring System 220]
              MgmtGateway[Management Gateway]
          end
  
          NodeA1 -- lightpath A --> OSF
          NodeA2 -- lightpath A --> OSF
          NodeA3 -- lightpath A --> OSF
          NodeB1 -- lightpath B --> OSF
          NodeB2 -- lightpath B --> OSF
  
          OSF -- lightpath A (Gateway) --> MgmtGateway
          OSF -- lightpath B (Gateway) --> MgmtGateway
      end
  
      ClientA[Client A System 208] --> PublicNet[Public Network 204]
      ClientB[Client B System 208] --> PublicNet
      PublicNet --> Firewall[Firewall/Auth 210]
      Firewall --> Provider_Network
  

1.2. FPGA-Based Network Isolation Gateways

• Enabling Description: The gateway devices (240, 241, 242) are implemented not as general-purpose routers but as specialized network interface cards (NICs) or appliances based on Field-Programmable Gate Arrays (FPGAs). For each client cluster, a specific bitstream is loaded onto the FPGA. This bitstream implements stateful packet inspection, traffic shaping, and access control lists directly in hardware logic. This allows for network isolation rules to be enforced at multi-gigabit line rates with deterministic, microsecond-level latency. A first cluster for a real-time data processing task could have its FPGA gateway programmed with rules to prioritize specific UDP streams, while a second cluster for batch analytics could have its gateway programmed to enforce strict bandwidth caps and perform protocol filtering.
• Mermaid.js Diagram:

  sequenceDiagram
      participant Client
      participant PublicNet
      participant Firewall
      participant CompanyNet
      participant FPGAGateway as FPGA Gateway (240)
      participant Cluster as Custom HPC Cluster (250)
  
      Client->>PublicNet: Access Request
      PublicNet->>Firewall: Forward Request
      Firewall->>CompanyNet: Authenticated Request
      CompanyNet->>FPGAGateway: Route to Cluster 250
      FPGAGateway->>Cluster: Forward Packet (Line-rate check)
      Note over FPGAGateway: Bitstream enforces isolation and traffic shaping rules in hardware logic.
      Cluster->>FPGAGateway: Response
      FPGAGateway->>CompanyNet: Forward Response
      CompanyNet->>Firewall: Route to Client
      Firewall->>PublicNet: Forward Response
      PublicNet->>Client: Deliver Response
  

1.3. Software-Defined Perimeter for Client Access

• Enabling Description: The centralized firewall and authentication mechanism (210) is replaced with a Software-Defined Perimeter (SDP), also known as a "zero trust" architecture. There is no single entry point. Instead, an SDP Controller is linked to an identity provider. When a client attempts to connect, their device and identity are first authenticated by the Controller. Upon successful authentication, the Controller dynamically instructs a specific SDP Gateway, co-located with the client's assigned cluster, to create a temporary, encrypted TLS tunnel directly to the client's machine. This creates a secure, individualized network segment of one, preventing any lateral network movement. The configuration differs in that a client for a high-security cluster may require multi-factor authentication and device posture checking before the tunnel is established, while a client for a development cluster may only require a username/password.
• Mermaid.js Diagram:

  graph TD
      subgraph SDP_Architecture
          ClientA[Client A] --> SDPController[SDP Controller]
          SDPController -- Authenticate & Authorize --> ClientA
          SDPController -- Push Rules --> SDP_Gateway_A[SDP Gateway A]
  
          ClientA -- mTLS Tunnel --> SDP_Gateway_A
          SDP_Gateway_A --- ClusterA[HPC Cluster A]
          ClusterA --- PrivateNet[Private Company Network]
  
          ClientB[Client B] --> SDPController
          SDPController -- Authenticate & Authorize --> ClientB
          SDPController -- Push Rules --> SDP_Gateway_B[SDP Gateway B]
          ClientB -- mTLS Tunnel --> SDP_Gateway_B
          SDP_Gateway_B --- ClusterB[HPC Cluster B]
          ClusterB --- PrivateNet
  
          PrivateNet --- MonitoringSystem[Monitoring System]
      end
  

1.4. Disaggregated Persistent Memory as Shared Storage

• Enabling Description: The shared data storage within a cluster is implemented using disaggregated persistent memory modules (e.g., Intel Optane or other Storage Class Memory) connected over a high-speed, low-latency fabric like Compute Express Link (CXL) or Gen-Z. Instead of a dedicated storage node (320), pools of persistent memory are directly accessible by all processing nodes in the cluster via the fabric. A first cluster can be configured with memory-mapped access to this persistent memory pool, treating it like extended DRAM for in-memory database tasks. A second cluster, for the same client, can be configured to access a different portion of the same physical memory pool as a block device, providing an ultra-fast scratch space for checkpointing large simulations. The configuration difference lies in the software-defined access mode (memory vs. block) and the quality-of-service policies applied by the fabric manager.
• Mermaid.js Diagram:

  graph TD
      subgraph Custom_Cluster_350
          Node1[Processing Node]
          Node2[Processing Node]
          Node3[Processing Node]
  
          CXL_Fabric[CXL Fabric Switch]
  
          Node1 -- CXL Link --> CXL_Fabric
          Node2 -- CXL Link --> CXL_Fabric
          Node3 -- CXL Link --> CXL_Fabric
      end
  
      subgraph Disaggregated_P-Mem_Pool
          PMem1[Persistent Memory Module]
          PMem2[Persistent Memory Module]
      end
  
      CXL_Fabric -- CXL Link --> PMem1
      CXL_Fabric -- CXL Link --> PMem2
  
      Gateway[Gateway 240] -- Connects one node to --> PrivateNet[Private Network 230]
      Node1 --- Gateway
  

---

Axis 2: Operational Parameter Expansion

2.1. Hosted Cryogenic and Ambient Temperature Clusters

• Enabling Description: A hosting system offers different clusters operating at extreme temperature differentials. The first cluster is a standard HPC cluster using CMOS-based processors operating at ambient data center temperatures (e.g., 20°C). The second cluster comprises computing elements based on superconducting logic (e.g., circuits with Josephson junctions) that require cryogenic cooling to near absolute zero (< 4 Kelvin). Both clusters are connected to the same private company network via their respective gateways for monitoring and job submission. The configuration for the second cluster is vastly different, involving specialized hardware, cryogenic cooling infrastructure, and different software compilers, and is intended for quantum simulation or other tasks that benefit from superconducting electronics. The monitoring system is adapted to track both standard hardware metrics and cryogenic-specific parameters like liquid helium levels and operating temperatures.
• Mermaid.js Diagram:

  stateDiagram-v2
      direction LR
      state "Client Task Definition" as Task
      Task --> Ambient_Config
      Task --> Cryo_Config
  
      state "Ambient HPC Cluster (20°C)" as Ambient {
          direction LR
          [*] --> Processing
          Processing --> Completed
      }
  
      state "Cryogenic HPC Cluster (<4K)" as Cryo {
          direction LR
          [*] --> Superconducting_Processing
          Superconducting_Processing --> Completed
      }
  
      Ambient_Config --> Ambient
      Cryo_Config --> Cryo
  
      state "Monitoring System" as Monitor
      Monitor: Tracks CPU temp, fan speed
      Monitor: Tracks Helium levels, Kelvin temp
  
      Ambient --> Monitor
      Cryo --> Monitor
  

2.2. Globally Distributed, Logically Centralized Hosted Clusters

• Enabling Description: The system is expanded to a global scale where the "private company network" is a secure, high-speed global WAN. A first cluster is physically deployed in a data center in a specific legal jurisdiction (e.g., Germany) to satisfy a client's data residency requirements under GDPR. A second cluster for the same client is deployed in a U.S. data center to be closer to their American end-users for latency-sensitive processing. Both clusters are managed and monitored by a single, logically centralized monitoring system. The gateways (240, 241) connect their respective local cluster networks to the global WAN. This configuration is customized based on geopolitical and network latency parameters, not just hardware specifications.
• Mermaid.js Diagram:

  graph TD
      subgraph EU_Datacenter
          Cluster_A[First HPC Cluster - GDPR Compliant]
          Gateway_A[Gateway 240]
          Cluster_A -- private net --> Gateway_A
      end
  
      subgraph US_Datacenter
          Cluster_B[Second HPC Cluster - Low Latency]
          Gateway_B[Gateway 241]
          Cluster_B -- private net --> Gateway_B
      end
  
      subgraph Global_WAN [Private Company Network 230]
          Monitoring[Centralized Monitoring System 220]
      end
  
      Gateway_A -- WAN Link --> Global_WAN
      Gateway_B -- WAN Link --> Global_WAN
  
      Client[Client System 208] --> PublicInternet[Public Internet]
      PublicInternet --> Firewall[Firewall 210]
      Firewall --> Global_WAN
  

---

Axis 3: Cross-Domain Application

3.1. Aerospace: Unified Digital Twin Simulation

• Enabling Description: An aerospace company leases two distinct, isolated clusters for creating a comprehensive "digital twin" of a new aircraft. The first cluster is configured with high-frequency CPUs, large memory per node, and a high-speed parallel file system; it is used to run complex Computational Fluid Dynamics (CFD) and structural mechanics simulations on the airframe. The second cluster is configured with a real-time operating system, lower-power processors, and specialized I/O cards (e.g., MIL-STD-1553) to perform hardware-in-the-loop (HIL) simulation of the aircraft's avionics and control software. A firewall and gateway system ensures that the aerodynamics team can only access the CFD cluster, while the avionics team can only access the HIL cluster, preventing cross-contamination of simulation environments while allowing a central project manager to monitor both.
• Mermaid.js Diagram:

  flowchart LR
      subgraph Hosted_Service
          subgraph CFD_Environment
              ClusterA[Cluster A: High-Mem, Fast I/O]
          end
          subgraph HIL_Environment
              ClusterB[Cluster B: RTOS, Specialized I/O]
          end
          ClusterA -- isolated by Gateway A --> PrivateNet[Mgmt Network]
          ClusterB -- isolated by Gateway B --> PrivateNet
      end
  
      Aero_Team[Aerodynamics Team] --> Auth[Firewall]
      Avionics_Team[Avionics Team] --> Auth
  
      Auth -- access grant --> Aero_Team -- only to --> CFD_Environment
      Auth -- access grant --> Avionics_Team -- only to --> HIL_Environment
  

3.2. AgTech: Genomic Selection and Climate Forecasting

• Enabling Description: An agricultural technology company uses the hosting service to accelerate crop development. The first cluster is configured as a high-throughput computing (HTC) system with vast amounts of attached storage. It is used to perform genomic sequencing analysis and identify desirable genetic markers from thousands of plant samples. The second cluster is a classic HPC system with a low-latency interconnect (e.g., InfiniBand) used to run complex, long-range weather and climate models to predict growing conditions in target regions. The configurations are starkly different: one is optimized for I/O-bound, embarrassingly parallel tasks, while the other is for tightly-coupled, communication-intensive simulations. The system isolates the work of the geneticists from the climatologists.
• Mermaid.js Diagram:

  erDiagram
      CLIENT {
          string Name
      }
      CLUSTER {
          string Type
          string Configuration
      }
      TASK {
          string Name
          string Requirements
      }
  
      CLIENT ||--o{ TASK : "defines"
      TASK ||--|{ CLUSTER : "requires"
  
      CLIENT {
          Name "AgTech Corp"
      }
      TASK {
          Name "Genomic Analysis"
          Requirements "High I/O, Parallel"
      }
      TASK {
          Name "Climate Modeling"
          Requirements "Low Latency Interconnect"
      }
      CLUSTER {
          Type "First Cluster (HTC)"
          Configuration "Large Storage, HTC Sched."
      }
      CLUSTER {
          Type "Second Cluster (HPC)"
          Configuration "InfiniBand, MPI"
      }
  

---

Axis 4: Integration with Emerging Tech

4.1. AI-Driven Dynamic Cluster Reconfiguration

• Enabling Description: The hosting system incorporates an AI-based resource manager. A client submits a job not with a pre-defined cluster configuration, but with a high-level description of their task, its dataset, and performance goals (e.g., "Train ResNet-50 model on ImageNet dataset, minimize time-to-solution"). A reinforcement learning agent, pre-trained on performance data from thousands of previous jobs, selects the optimal hardware configuration from a heterogeneous pool of resources (CPUs, GPUs, TPUs, various network fabrics). It provisions a temporary, custom cluster for the duration of the job. A first cluster for one client might be dynamically configured with GPUs and NVLink, while a second cluster for another client's data analytics task might be configured with high-memory CPU nodes and a Spark environment. The AI acts as the "configuration engine" described in the patent.
• Mermaid.js Diagram:

  sequenceDiagram
      participant Client
      participant AI_Manager as AI Resource Manager
      participant ResourcePool as Heterogeneous Hardware Pool
      participant Provisioner
      participant Cluster
  
      Client->>AI_Manager: Submit Task (e.g., 'Train Model')
      AI_Manager->>ResourcePool: Query available resources
      ResourcePool-->>AI_Manager: Return inventory (GPUs, CPUs, etc.)
      AI_Manager->>AI_Manager: RL Agent selects optimal configuration
      AI_Manager->>Provisioner: Instruct to build Cluster with config X
      Provisioner->>ResourcePool: Allocate specific nodes/links
      Provisioner->>Cluster: Configure software and network
      Provisioner-->>AI_Manager: Cluster Ready
      AI_Manager-->>Client: Provide Cluster endpoint
  

4.2. Blockchain-Secured Cluster Provenance and Audit

• Enabling Description: The hosting system integrates a private, permissioned blockchain (e.g., Hyperledger Fabric) to provide an immutable audit trail for each cluster, targeted at clients in regulated industries like finance or healthcare. When a first cluster is provisioned, a transaction is written to the blockchain ledger detailing the exact hardware components (by serial number), the software image hashes, the network configuration, and the client's request ID. All subsequent administrative actions (e.g., patching a kernel, replacing a failed node, a client accessing data) are recorded as new transactions, digitally signed by the entity performing the action. This provides the client with a verifiable, tamper-proof log of their cluster's entire lifecycle, which can be used to satisfy regulatory compliance audits.
• Mermaid.js Diagram:

  flowchart TD
      A[Client Requests Cluster] --> B{Provision Cluster};
      B --> C[Generate Genesis Block];
      C -- Contains --> D["Hardware IDs\nSoftware Hashes\nClient ID"];
      D --> E{Add Block to Ledger};
      E --> F[Cluster is Active];
      F --> G{Admin Action: Patch OS};
      G --> H[Create New Transaction];
      H -- Signed by Admin --> I["Action: Patch\nImage Hash: 0xabc...\nTimestamp"];
      I --> J{Add Block to Ledger};
      J --> K[Client Action: Run Job];
      K --> L[Create New Transaction];
      L -- Signed by Client --> M["Action: Run Job\nJobID: 123\nTimestamp"];
      M --> N{Add Block to Ledger};
  
      subgraph Private_Blockchain
          direction LR
          E -- links to --> J
          J -- links to --> N
      end
  

---

Axis 5: The "Inverse" or Failure Mode

5.1. Quarantinable Gateway for Security Incident Response

• Enabling Description: The system is designed for high-security operations where cluster isolation must be guaranteed even during a security breach. The monitoring system (220) is integrated with an intrusion detection system (IDS). If the IDS detects anomalous activity within the first cluster (e.g., traffic patterns indicative of malware), it triggers an alert. The central management system automatically reconfigures the cluster's associated gateway (240). The gateway's primary function is inverted: instead of forwarding traffic, it drops all connections to the public and private company networks and redirects all outbound traffic from the cluster to a dedicated, isolated forensic analysis environment (a "honeynet"). This "quarantine mode" ensures the compromised cluster cannot attack other clusters while preserving its state for investigation.
• Mermaid.js Diagram:

  stateDiagram-v2
      [*] --> Normal_Operation
      Normal_Operation: Gateway routes traffic to Private/Public nets.
      Quarantined: Gateway drops external traffic, redirects internal to forensics.
  
      Normal_Operation --> Quarantined: IDS detects threat
      Quarantined --> Normal_Operation: Security team clears incident
      Quarantined --> Decommissioned: Cluster is terminated after analysis
  

---

Combination Prior Art with Open-Source Standards

C.1. Combination with OpenStack and Neutron

• Enabling Description: A method for hosting customized computing clusters is implemented using the open-source cloud platform OpenStack. Each client is mapped to a unique OpenStack "tenant" (or "project"). The first cluster for a first client is a collection of "Nova" virtual machine instances provisioned within the first tenant. The second cluster for a second client is a separate collection of Nova VMs in a second tenant. The cluster network isolation and gateway functionality are achieved entirely through "Neutron," OpenStack's networking component. A dedicated virtual L2 network is created for each tenant's cluster. A Neutron "virtual router" is attached to each tenant's network, acting as the gateway (240, 241). This virtual router handles traffic between the cluster's private network and the shared private company network (the OpenStack provider network). The firewall (210) is implemented using Neutron's Security Groups and Floating IP addresses, which control access from the public internet to specific instances within each tenant's cluster. The monitoring system (220) is implemented using OpenStack's "Ceilometer" and "Monasca" projects to collect metrics from all tenant resources.

C.2. Combination with Kubernetes and Cilium/eBPF

• Enabling Description: A system for hosting customized container-based clusters using Kubernetes. The provider manages a large, multi-tenant physical infrastructure running Kubernetes. Each client's "cluster" is a dedicated Kubernetes "namespace." To achieve the network isolation claimed in the patent, the system utilizes the open-source Cilium CNI plugin, which leverages eBPF in the Linux kernel. Instead of physical gateways, Cilium network policies are created on a per-namespace basis. These policies explicitly whitelist allowed traffic flows (e.g., within the namespace) and deny all other traffic by default, including any attempt to communicate with pods in another client's namespace. The "gateway" function is provided by a dedicated Ingress controller (e.g., NGINX Ingress) deployed within each namespace, which is the only component exposed to the provider's private network for routing external client traffic. The firewall function is handled by the same Ingress controller, which can enforce authentication and TLS termination. This provides high-performance, kernel-level isolation between different client clusters running on the same underlying nodes.

C.3. Combination with Slurm Workload Manager and OpenFlow

• Enabling Description: A system for hosting bare-metal HPC clusters where the physical network is a software-defined fabric controlled by an OpenFlow controller. The open-source Slurm Workload Manager is used to manage compute resources. When a client requests a first cluster, they submit a Slurm job that reserves a set of physical nodes. Upon allocation, the Slurm controller communicates with the OpenFlow controller. The OpenFlow controller then programs the physical switches in the fabric to create a virtual, isolated Layer 2 network connecting only the nodes allocated to that job. A single node in the allocation is designated as the "head node" and the OpenFlow controller installs specific flow rules that allow only this node to communicate with the private company network for management and monitoring, effectively making it the gateway. A separate job from a second client would result in the OpenFlow controller creating a completely separate set of flow rules for its allocated nodes, ensuring the two clusters are isolated at the network hardware level.