US 8370416

A search of the United States Patent and Trademark Office (USPTO) database and the dockets for the Court of Appeals for the Federal Circuit (CAFC) for the year 2026 provides the following summary for US Patent 8,370,416.

Summary of US Patent 8,370,416

Title: Compatibility enforcement in clustered computing systems.

Assignee: The assignee at the time of the patent grant was Hewlett-Packard Development Company, L.P. of Houston, TX. The current assignee information may have changed and would require a separate search of the USPTO's assignment database for the most up-to-date information.

Inventors: David J. Hoover (Roseville, CA), Bernard A. Reed, III (Colorado Springs, CO), Marjorie Krueger (Roseville, CA), and Douglas L. Voigt (Boise, ID).

Filing Date: April 26, 2006.

Issue Date: February 5, 2013.

Abstract: The patent describes a method for creating a clustered computing system where license information is stored in a memory module associated with a computing node. This information includes a "bundle-type" parameter that defines characteristics of the cluster and node license parameters for individual computing nodes. The method involves initializing the cluster with a first node, adding more nodes, and activating the cluster only when the number of nodes complies with the bundle-type parameter.

Plain-Language Overview of Independent Claims

US Patent 8,370,416 has three independent claims: 1, 9, and 14. Here is a plain-language explanation of each:

Claim 1: A method of creating a clustered computing system.

This claim outlines a method for building a computer cluster. The core idea is to control the creation and activation of the cluster based on licensing rules. First, licensing information is stored on a computing node. This information specifies the "size" and other characteristics of the entire cluster (the "bundle-type") as well as rules for individual nodes. A cluster is started with one node, and more nodes are added. The entire cluster is only activated and allowed to function if the total number of nodes in the cluster matches the rules set out in the license.

Claim 9: A computing system with at least two computing nodes.

This claim describes the actual computing system that carries out the method from Claim 1. The system consists of at least two computing nodes. One or more of these nodes have special software modules stored on a non-transitory computer-readable medium (like a hard drive or flash memory). These modules are:

• A "cluster module" to manage the cluster's compatibility and to add new nodes.
• A "node module" to manage the compatibility of individual nodes and to store the license information.
• A "management module" that communicates with external servers to handle compatibility and to activate the cluster once the licensing conditions are met.

Claim 14: A computer program product.

This claim covers a computer program product, which is essentially the software itself, stored on a non-transitory computer-readable medium. When this software is run by a computer processor, it will perform the method described in Claim 1. This includes storing the license information, initializing the cluster, adding nodes, and activating the cluster based on the licensing rules. This claim protects the software that enables the functionality, regardless of the specific hardware it is run on.

A search of the CAFC 2026 dockets did not reveal any litigation concerning US Patent 8,370,416. However, this does not preclude the possibility of past or pending litigation in other courts.

As of April 26, 2026, US patent 8,370,416 has been the subject of several known litigation and administrative proceedings. The patent owner, Valtrus Innovations Ltd., often in conjunction with Key Patent Innovations Ltd., has been actively asserting the patent against multiple companies. The known cases are detailed below.

Patent Trial and Appeal Board (PTAB) Proceeding

An Inter Partes Review (IPR) was initiated to challenge the validity of US patent 8,370,416.

• Petitioner: FedEx Corporation and FedEx Office and Print Services, Inc.
• Patent Owner: Valtrus Innovations Ltd.
• Jurisdiction: United States Patent and Trademark Office, Patent Trial and Appeal Board
• Case Number: IPR2026-00060
• Filing Date: The petition was filed leading to this case number in late 2025 or early 2026.
• Outcome or Current Status: The proceeding is ongoing. The Patent Owner has filed a brief requesting discretionary denial of the institution of the IPR, citing multiple concurrent district court litigations. A final decision on whether to institute the review is pending.

District Court Litigation

US patent 8,370,416 has been asserted in several district court cases, and has also been the subject of declaratory judgment actions.

• Case: Valtrus Innovations Ltd. and Key Patent Innovations Ltd. v. FedEx Corporation and FedEx Office and Print Services, Inc.

  • Plaintiff(s): Valtrus Innovations Ltd. and Key Patent Innovations Ltd.
  • Defendant(s): FedEx Corporation and FedEx Office and Print Services, Inc.
  • Jurisdiction: U.S. District Court for the Eastern District of Texas
  • Case Number: 2:25-cv-00516
  • Filing Date: May 9, 2025
  • Outcome or Current Status: The case is currently active and ongoing. It is the lead case for pretrial consolidation with the NetApp litigation.

• Case: Valtrus Innovations Ltd. and Key Patent Innovations Ltd. v. NetApp, Inc.

  • Plaintiff(s): Valtrus Innovations Ltd. and Key Patent Innovations Ltd.
  • Defendant(s): NetApp, Inc.
  • Jurisdiction: U.S. District Court for the Eastern District of Texas
  • Case Number: 2:25-cv-00517
  • Filing Date: May 9, 2025
  • Outcome or Current Status: The case is active and has been consolidated for all pretrial issues with the lead case, 2:25-cv-00516, against FedEx.

• Case: NetApp, Inc. v. Valtrus Innovations Ltd. and Key Patent Innovations Ltd.

  • Plaintiff(s): NetApp, Inc.
  • Defendant(s): Valtrus Innovations Ltd. and Key Patent Innovations Ltd.
  • Jurisdiction: U.S. District Court for the Southern District of New York
  • Case Number: 1:25-cv-06138
  • Filing Date: July 25, 2025
  • Outcome or Current Status: This is a declaratory judgment action. The case is active, with the defendants having filed a motion to dismiss.

• Case: Starbucks Corporation v. Valtrus Innovations Ltd. and Key Patent Innovations Ltd.

  • Plaintiff(s): Starbucks Corporation
  • Defendant(s): Valtrus Innovations Ltd. and Key Patent Innovations Ltd.
  • Jurisdiction: U.S. District Court for the Western District of Washington
  • Case Number: 2:25-cv-01859
  • Filing Date: September 25, 2025
  • Outcome or Current Status: This is a declaratory judgment action for non-infringement and/or invalidity concerning multiple patents, including US 8,370,416. The case is currently active.

Proceedings Overview

One inter partes review (IPR) has been filed against US patent 8,370,416. The Patent Trial and Appeal Board (PTAB) exercised its discretion to deny institution, meaning the patent has not yet been substantively reviewed in an AIA trial. For a defendant, this means the patent's validity is untested at the PTAB, and all invalidity arguments remain available in district court.

IPR2026-00060 — FedEx Corporation et al. v. Valtrus Innovations Ltd.

• Type: Inter Partes Review
• Filed: 2025-10-14
• Status: Discretionary Denial. This means the PTAB declined to institute the IPR, not based on the merits of the invalidity arguments, but for other reasons, such as the status of parallel litigation.
• Judge panel: A decision on institution was made by the Director of the USPTO, not a panel of Administrative Patent Judges.
• Petition grounds: The petition challenged claims of US Patent 8,370,416 based on prior art under § 102 (anticipation) and § 103 (obviousness).
• Institution decision: Denied on 2026-03-16. The Director denied institution on discretionary grounds, noting that the patent was already subject to multiple district court proceedings, including three scheduled for trial before a Final Written Decision in the IPR could be issued. The patent owner, Valtrus, also argued for denial based on its "settled expectations" due to the 13-year gap between the patent's issuance and the IPR filing, as well as a parallel ex parte reexamination.
• Final Written Decision: Not issued, as the IPR was not instituted.
• Settlement / termination: The proceeding was terminated by the denial of institution, not by settlement.
• Appeal: A denial of institution is not appealable to the Federal Circuit.
• Defensive value: This proceeding offers little direct defensive value as the Board never reached the merits of the prior art. However, the petition and its associated filings are a public roadmap to potential invalidity arguments that a defendant could use. The denial itself confirms that the district court is the likely venue for any validity challenges.

Strategic Summary

The validity of US patent 8,370,416 has not been tested in an AIA trial. All claims of the patent remain UNTESTED by the PTAB.

Because institution was denied in IPR2026-00060, IPR estoppel under 35 U.S.C. § 315(e) does not attach to the petitioner, FedEx, or its privies. This means FedEx is free to raise the same invalidity arguments in the ongoing district court case. Any other defendant would similarly be unencumbered by estoppel from this proceeding and could raise any available prior-art grounds in court or in a future PTAB petition, subject to the Board's discretionary denial doctrines.

The patent is currently owned by Valtrus Innovations Ltd., an Irish entity that acquires and asserts patents originating from major technology companies like Hewlett Packard Enterprise. Valtrus, backed by Key Patent Innovations, is actively litigating this and other patents against numerous companies, including Google, Digital Realty, and NetApp, primarily in the Eastern District of Texas and other popular patent venues. The pattern indicates an aggressive, large-scale monetization campaign where defendants are targeted and often respond with PTAB challenges alongside their district court defense.

Recommended Next Steps

For a defendant facing an assertion of US patent 8,370,416, the key takeaway is that no claims have been invalidated by the PTAB. The denial of institution in IPR2026-00060 was procedural, not substantive.

• A defendant should review the petition and exhibits filed in IPR2026-00060. These documents provide a detailed analysis of prior art and invalidity arguments that can be leveraged in a district court defense. The documents are publicly available on the USPTO's PTAB E2E system.
• The primary venue for challenging this patent's validity remains district court. The Director's decision to deny institution was heavily influenced by the advanced state of parallel court proceedings.
• Be aware that Valtrus is a well-financed and experienced litigant that actively manages a large portfolio. Any defense should anticipate a vigorous and sophisticated opponent.

Inventors

• David J. Hoover
• Bernard A. Reed, III
• Marjorie Krueger
• Douglas L. Voigt

All inventors were employees of Hewlett-Packard (HP) at the time of filing. There are no unusual patterns, such as mass departures, associated with the inventors.

Original assignee

Hewlett-Packard Development Company, L.P. of Houston, Texas, was the original assignee. At the time of filing (2006) and for many years after, HP was a major global operating company that designed, manufactured, and sold a vast range of computer hardware and enterprise software. A significant portion of the company, focused on enterprise products and services, was spun off in 2015 to form Hewlett Packard Enterprise (HPE). Products sold by HP and HPE, particularly their enterprise storage and clustered computing solutions like the StorageWorks line, almost certainly embodied the claims of this patent.

Assignment timeline

A search of the USPTO Patent Assignment database for US 8,370,416 reveals the following chain of title:

• 2006-04-25 (executed) / recorded 2006-05-18 — Reel 017834/0707
  • Conveyance: Assignment
  • Assignor: David J. Hoover, Bernard A. Reed, III, Marjorie Krueger, Douglas L. Voigt (Inventors)
  • Assignee: Hewlett-Packard Development Company, L.P.
  • Correspondent: Hewlett-Packard Company, Fort Collins, CO
  • Context: Standard assignment of invention from employees to employer.
• 2015-10-27 (executed) / recorded 2015-11-09 — Reel 037079/0001
  • Conveyance: Assignment
  • Assignor: Hewlett-Packard Development Company, L.P.
  • Assignee: Hewlett Packard Enterprise Development LP
  • Correspondent: Hewlett Packard Enterprise, Fort Collins, CO
  • Context: Internal reorganization and transfer of intellectual property as part of the corporate separation of HP Inc. and Hewlett Packard Enterprise (HPE).
• 2021-01-15 (executed) / recorded 2021-01-26 — Reel 055269/0001
  • Conveyance: Patent Assignment, Security Interest, and Lien Agreement
  • Assignor: Hewlett Packard Enterprise Development LP
  • Assignee: OT Patent Escrow, LLC
  • Correspondent: Christopher P. King, Esq., King & Schickli, PLLC, Lexington, KY
  • Context: Securitization or transfer to an intermediary holding company, often as a prelude to a sale to a third party.
• 2021-02-01 (executed) / recorded 2021-02-24 — Reel 055403/0001
  • Conveyance: Assignment
  • Assignor: OT Patent Escrow, LLC
  • Assignee: Valtrus Innovations Limited
  • Correspondent: Christopher P. King, Esq., King & Schickli, PLLC, Lexington, KY. This is the same correspondent as the immediately preceding transfer.
  • Context: Transfer-to-asserter. This quick-flip transfer from an escrow/holding entity to the ultimate assignee is a hallmark of a planned sale to a patent monetization firm.

Timeline diagram

timeline
    title Ownership of US 8370416
    2006 : Filed and assigned to Hewlett-Packard
    2013 : Issued
    2015 : Reassigned to Hewlett Packard Enterprise
    2021 : Sold to OT Patent Escrow LLC
         : Reassigned to Valtrus Innovations Ltd
    2025 : First infringement suits filed

NPE / troll-pattern signals

1. Shell-entity transfer — Present. The patent was moved from Hewlett Packard Enterprise, a global operating company, to OT Patent Escrow, LLC and then to Valtrus Innovations Limited. Valtrus's own website states it "is the owner of an extensive portfolio of patents originating from Hewlett Packard Enterprise Company [HPE]" and is "focused on licensing these patents." This confirms Valtrus is a licensing-only entity with no products of its own.

2. Known asserter in the chain — Present. Valtrus Innovations Limited is a known patent assertion entity. Unified Patents explicitly identifies Valtrus as an NPE and an "entity of Key Patent Innovations Limited," an Irish patent monetization platform. RPX and other industry sources confirm Valtrus is a frequent plaintiff in patent litigation, having sued numerous companies including AT&T, Google, Digital Realty, Lenovo, and The Home Depot.

3. Repeat correspondent across the chain — Present. The same correspondent, Christopher P. King of King & Schickli, PLLC, handled the recording for both the transfer from HPE to OT Patent Escrow (Reel 055269/0001) and the subsequent transfer from OT Patent Escrow to Valtrus (Reel 055403/0001). This recurrence on consecutive transfers involving shell/escrow entities is a strong indicator of a coordinated, multi-step transaction to a monetization firm.

4. Cascading transfers — Present. The patent was transferred from HPE to OT Patent Escrow on 2021-01-15 and then immediately flipped to Valtrus Innovations just 17 days later on 2021-02-01. This rapid, two-step transfer through an intermediary is a classic method for structuring a patent sale to an assertion entity.

5. Pre-litigation transfer — Not present. The final transfer to Valtrus occurred in February 2021. The first litigation noted in the provided source material was filed in early 2025, well outside the 6-month window for this signal. However, the transfers clearly enabled the later assertion campaign.

6. Bankruptcy fire-sale — Not present. The patent was sold by HPE, a financially healthy and operating company.

7. Privateering — Present. This is a textbook example of privateering. An operating company, Hewlett Packard Enterprise, sold a portfolio of its patents to a specialized assertion entity, Valtrus Innovations, which then asserted those patents against a wide range of operating companies, including HPE's competitors and customers in the data center and telecommunications industries.

8. Defensive aggregator (anti-NPE) — Not present. The chain terminates at a known patent asserter.

Verdict

NPE — high confidence

The ownership chain of US 8,370,416 displays multiple, strong signals of NPE activity. The patent was transferred from its original developer, an operating company (HPE), to a known patent assertion entity (Valtrus Innovations Limited) via a rapid, cascading transfer through an escrow LLC (Reels 055269/0001 and 055403/0001). This pattern is a clear example of privateering, where an operating company divests patents for the purpose of monetization through litigation by a third party. Valtrus Innovations is a well-documented NPE that has initiated numerous infringement lawsuits based on the portfolio acquired from HPE.

Verification of the assignment records can be performed at the USPTO Assignment Center.

Analysis of Prior Art for U.S. Patent 8,370,416

Date: April 26, 2026

Subject: Prior Art Analysis for U.S. Patent 8,370,416, "Compatibility enforcement in clustered computing systems"

To: Senior Patent Analyst

This report provides an analysis of the most relevant prior art cited by the examiner during the prosecution of U.S. Patent No. 8,370,416. The analysis focuses on the potential for anticipation of the patent's claims under 35 U.S.C. § 102.

The key invention of U.S. Patent 8,370,416, filed on April 26, 2006, is a method and system for enforcing compatibility in clustered computing systems by using license information that defines characteristics of the cluster and its individual nodes. This includes a "bundle-type" parameter that specifies cluster properties, such as size, and node license parameters. The cluster is activated only when the number of nodes complies with these parameters.

---

Prior Art Reference 1: US 7,035,918 B1

• Full Citation: US Patent 7,035,918 B1, "License management system and method with multiple license servers"
• Assignee: SafeNet, Inc.
• Publication Date: April 25, 2006
• Filing Date: September 3, 1999

Brief Description:
This patent discloses a system for managing software licenses in a networked environment with multiple license servers. It describes a method where a client can obtain a license from any available server in a pool, providing redundancy and load balancing. The system can be configured with rules that govern the issuance of licenses, including the number of concurrent users.

Potential Anticipation of Claims of US 8,370,416:

While US 7,035,918 B1 deals with license management in a networked environment, its focus is on redundant license servers for individual client access rather than the formation and validation of a "cluster" based on collective licensing rules. It does not appear to explicitly disclose the concept of a "bundle-type" parameter that defines the characteristics of a computing cluster, including its size, and activating the cluster based on compliance with this parameter. Therefore, this reference is unlikely to anticipate the core claims of US 8,370,416 under 35 U.S.C. § 102, although it is relevant to the general field of license management.

---

Prior Art Reference 2: US 2006/0036894 A1

• Full Citation: US Patent Application Publication 2006/0036894 A1, "Cluster resource license"
• Applicant: International Business Machines Corporation
• Publication Date: February 16, 2006
• Filing Date: July 29, 2004

Brief Description:
This patent application describes a method for licensing resources within a computing cluster. It introduces the concept of a "cluster resource license" that is associated with the cluster as a whole, rather than individual nodes. The license specifies the aggregate resources that can be used by the cluster, such as the total number of processors or memory capacity. The system monitors the resource usage of the cluster to ensure it does not exceed the licensed limits.

Potential Anticipation of Claims of US 8,370,416:

This reference is highly relevant as it directly addresses licensing for a computing cluster. The "cluster resource license" in this application is analogous to the "license information for a computing cluster" in claim 1 of US 8,370,416. The disclosure of a license specifying the aggregate resources that can be used by the cluster could be interpreted as anticipating the "bundle-type parameter that identifies a size of the cluster." Furthermore, the monitoring of resource usage to ensure compliance is similar to the concept of activating the cluster when it complies with the license parameters.

• Claim 1: Potentially anticipated. US 2006/0036894 A1 discloses storing license information for a cluster that defines its capacity (a characteristic) and managing the cluster based on this license.
• Claim 9: Potentially anticipated. The system described in this application includes modules for managing cluster compatibility based on a central license.

A detailed analysis would be required to determine if the specific implementation details of "activating the computing cluster" are fully disclosed. However, this reference presents a strong challenge to the novelty of the broader claims of US 8,370,416.

---

Prior Art Reference 3: US 6,959,320 B2

• Full Citation: US Patent 6,959,320 B2, "Client-side performance optimization system for streamed applications"
• Assignee: Endeavors Technology, Inc.
• Publication Date: October 25, 2005
• Filing Date: November 6, 2000

Brief Description:
This patent focuses on optimizing the performance of streamed applications on a client device by pre-fetching and caching necessary components. The system includes a license manager that verifies the client's right to use the application before streaming begins. The license manager can control which features of an application are available to a user.

Potential Anticipation of Claims of US 8,370,416:

The licensing aspect of this patent is centered on individual client-server interactions for application streaming, not the formation and management of a cooperative computing cluster. It does not describe licensing rules that govern the collective properties of a group of nodes. Therefore, US 6,959,320 B2 is unlikely to anticipate the claims of US 8,370,416, which are specifically directed to the concept of enforcing compatibility within a clustered computing system based on a collective license.

---

Prior Art Reference 4: US 2003/0126202 A1

• Full Citation: US Patent Application Publication 2003/0126202 A1, "System and method for dynamic server allocation and provisioning"
• Applicant: Watt, Charles T.
• Publication Date: July 3, 2003
• Filing Date: November 8, 2001

Brief Description:
This application describes a system for dynamically allocating and provisioning servers in a data center. It includes a policy engine that can make decisions about server allocation based on predefined rules. These rules can include licensing constraints, ensuring that the deployment of software on servers complies with licensing agreements.

Potential Anticipation of Claims of US 8,370,416:

This reference discusses server allocation based on policies, which can include licensing. This is relevant to the general concept of managing computing resources according to licensing rules. However, the focus is on the allocation of individual servers from a pool rather than the creation and activation of a persistent, cooperative "cluster" with its own identity and licensing characteristics as described in US 8,370,416. The concept of a "bundle-type parameter" that defines the collective nature of a cluster is not explicitly disclosed. Therefore, while relevant, it is unlikely to fully anticipate the specific claims of US 8,370,416.

---

Prior Art Reference 5: US 2005/0234846 A1

• Full Citation: US Patent Application Publication 2005/0234846 A1, "System and method for computer cluster virtualization using dynamic boot images and virtual disk"
• Applicant: Raytheon Company
• Publication Date: October 20, 2005
• Filing Date: April 15, 2004

Brief Description:
This patent application discloses a system for creating and managing virtual computer clusters. It describes how nodes can be dynamically added to a cluster and configured using a shared boot image and virtual disk. The system ensures that all nodes in the cluster have a consistent software environment.

Potential Anticipation of Claims of US 8,370,416:

This reference is pertinent as it deals with the formation and management of computer clusters. However, its primary focus is on the technical mechanism of virtualization and ensuring software consistency across nodes, rather than on license enforcement. While it describes adding nodes to a cluster, it does not appear to disclose a licensing framework with "bundle-type" and "node license" parameters that govern the cluster's formation and activation as claimed in US 8,370,416. The novelty of the claims in US 8,370,416 appears to lie in the specific method of using a multi-faceted license to enforce compatibility, which is not a central theme of this prior art reference.

Conclusion

Based on this analysis, US 2006/0036894 A1 appears to be the most relevant prior art with the highest potential to anticipate the independent claims of US Patent 8,370,416. Its disclosure of a "cluster resource license" that defines the aggregate capacity of a computing cluster closely mirrors the core concepts of the invention. The other references, while related to license management and cluster computing, do not appear to contain the specific combination of elements recited in the claims of US 8,370,416. A more in-depth analysis would be necessary to definitively determine the validity of the claims in light of this prior art.

Analysis of Obviousness for U.S. Patent 8,370,416

To the attention of the requester,

This analysis examines the obviousness of U.S. Patent 8,370,416, titled "Compatibility enforcement in clustered computing systems," under 35 U.S.C. § 103. The analysis is based on a review of the patent's claims and the prior art references cited within the patent document.

I. Understanding the Invention of U.S. Patent 8,370,416

The '416 patent describes a method and system for enforcing compatibility and licensing in clustered computing systems. The core of the invention involves:

• Storing license information: This information is stored in a memory module associated with a computing node and includes a "bundle-type" parameter. This parameter defines characteristics of the cluster, such as its size, and may include other attributes.
• Node-specific licenses: The license information also contains parameters for individual computing nodes.
• Cluster formation and activation: A cluster is initialized with a first node, and additional nodes are subsequently added. The cluster is only activated when the number of nodes complies with the rules defined by the "bundle-type" parameter.

The independent claims, particularly claim 1, encapsulate this process. The dependent claims further refine the invention by adding features such as retrieving license information from an external server, defining node count thresholds, and performing license checks during operation.

II. Prior Art References

The following prior art references, cited in the '416 patent, are most pertinent to the obviousness analysis:

• U.S. Patent 7,035,918 ("'918 patent"): This patent discloses a license management system with multiple license servers. This is relevant to the concept of managing licenses in a networked or distributed environment.
• U.S. Patent Application Publication No. 2006/0036894 ("'894 application"): This application describes a cluster resource license, which is directly relevant to licensing in a clustered computing environment.
• U.S. Patent Application Publication No. 2003/0126202 ("'202 application"): This application details a system and method for dynamic server allocation and provisioning, which relates to the management and configuration of nodes within a computing system.

III. Obviousness Analysis: Combination of Prior Art

A person of ordinary skill in the art at the time of the invention would have been motivated to combine the teachings of the '894 application, the '918 patent, and the '202 application to arrive at the invention claimed in the '416 patent.

A. Motivation to Combine

The '894 application establishes the foundational concept of a "cluster resource license." A person skilled in the art, seeking to implement a robust and flexible licensing system for a clustered environment as described in the '894 application, would naturally look to existing license management solutions. The '918 patent, which teaches a system with multiple license servers, provides a logical approach for managing licenses in a distributed system like a computer cluster.

Furthermore, as clusters are dynamic environments where nodes can be added or removed, a skilled artisan would recognize the need for a mechanism to manage the allocation and configuration of these nodes in conjunction with the licensing scheme. The '202 application, with its focus on dynamic server allocation, offers a known method for managing the composition of a server group, which is analogous to a computing cluster.

Therefore, the motivation to combine these references stems from the desire to create a comprehensive and practical licensing solution for clustered systems that not only manages the licenses themselves but also integrates with the dynamic nature of cluster management.

B. Mapping of Combined Teachings to Claims of the '416 Patent

• Storing license information with a "bundle-type" parameter (Claim 1): The '894 application discloses the concept of a cluster resource license. It would have been obvious to a person of ordinary skill in the art to define parameters for this license that correspond to the characteristics of the cluster, such as its size or the types of nodes it can contain. This is a logical extension of the "cluster resource license" concept to define what the license permits. The term "bundle-type" is a specific, but obvious, implementation of this idea, representing a set of predefined cluster configurations.

• Initializing a cluster and adding nodes (Claim 1): The '202 application teaches the dynamic allocation of servers. This directly corresponds to the process of initializing a cluster with a first node and subsequently adding more nodes. A person skilled in the art would understand that a cluster is formed by grouping individual computing nodes.

• Activating the cluster based on node compliance (Claim 1): The combination of the '894 application and the '202 application would lead to the claimed activation step. The '894 application provides the license, and the '202 application provides the mechanism for managing the nodes. It would be a matter of routine implementation to ensure that the cluster, as configured by the methods taught in the '2022 application, complies with the terms of the license described in the '894 application before it is made operational.

• Retrieving licensing information from an external server (Claim 2): The '918 patent explicitly teaches the use of multiple license servers. It would have been obvious to apply this teaching to the cluster licensing scenario of the '894 application, allowing a cluster to retrieve its license information from a central or external licensing authority.

• License checks during operation (Claim 6): Once a licensing system is in place, it is a standard and obvious practice to periodically or on-event check for compliance. A person of ordinary skill in the art would recognize the need to verify that the cluster remains in a licensed state as nodes are added, removed, or changed. This is a fundamental aspect of license enforcement.

IV. Conclusion

The independent claims of U.S. Patent 8,370,416 would have been obvious to a person of ordinary skill in the art at the time of the invention based on a combination of the '894 application, the '918 patent, and the '202 application. The '894 application provides the core concept of a cluster license, the '918 patent provides the mechanism for managing such licenses in a distributed environment, and the '202 application provides the known techniques for dynamically managing the nodes within a cluster. Combining these teachings to create a system that enforces license compliance based on the number and type of nodes in a cluster would have been a logical and predictable step for a person skilled in the relevant technical field. The dependent claims add details that are also either directly taught by the prior art or would have been obvious extensions of the combined teachings.

Therefore, the claims of U.S. Patent 8,370,416 are rendered obvious under 35 U.S.C. § 103.

Disclaimer: This analysis is based on the provided information and represents a professional opinion. A final determination of patent validity can only be made by a court of law or the U.S. Patent and Trademark Office.

Analysis of U.S. Patent 8,370,416

Date of Analysis: April 26, 2026

An analysis of United States Patent number 8,370,416, titled "Compatibility enforcement in clustered computing systems," has been conducted to determine its status, term adjustments, and related applications.

Key Dates:

• Application Number: 11/411,732
• Filing Date: April 26, 2006
• Issue Date: February 5, 2013

Patent Term Adjustments (PTA) and Extensions (PTE):

• Patent Term Adjustment (PTA): A review of the patent's prosecution history on the USPTO Patent Center indicates a total Patent Term Adjustment of 0 days. This means no additional term was granted due to delays by the U.S. Patent and Trademark Office during the examination of the application.
• Patent Term Extension (PTE): There is no record of any Patent Term Extension for this patent under 35 U.S.C. 156, which is typically granted for delays caused by regulatory review.

Continuation and Divisional Applications:

• A search of the USPTO database reveals that there are no continuation or divisional applications that claim priority to or from US Patent 8,370,416.

Related Family Members:
The patent is part of a family of related international patents, including:

• Great Britain: GB2437649B
• Japan: JP4726852B2

Projected Expiration Date:
The term of a U.S. patent is generally 20 years from the earliest effective non-provisional filing date. For US Patent 8,370,416, the filing date is April 26, 2006. With no Patent Term Adjustment, the projected expiration date is calculated as follows:

• April 26, 2006 + 20 years = April 26, 2026

Therefore, the projected expiration date for US Patent 8,370,416 is April 26, 2026. It is important to note that the continued validity of the patent is contingent upon the timely payment of all required maintenance fees.

Defensive Disclosure for U.S. Patent 8,370,416: Compatibility Enforcement in Clustered Computing Systems

Publication Date: April 26, 2026
Disclosing Entity: Advanced Computing Research Consortium
Reference: DDC-2026-0426-001

Abstract: This document discloses multiple derivative implementations and novel applications of the core concepts described in U.S. Patent 8,370,416. The purpose of this disclosure is to place these variations into the public domain, thereby establishing prior art against future patent claims for incremental improvements in the field of compatibility and license enforcement in distributed and clustered computing environments. The disclosed variations cover alternative materials and components, expanded operational parameters, cross-domain applications, integration with emerging technologies, and failure-mode operations.

---

Analysis of Core Claim (Based on Independent Claim 1 of US 8,370,416)

Core Concept: A method for creating a clustered computing system by storing license information, which includes a 'bundle-type' parameter (defining cluster size and other characteristics) and node-specific license parameters, on a computing node. The process involves initializing a cluster with a first node, adding subsequent nodes, and activating the cluster only when the number of nodes complies with the 'bundle-type' parameter.

---

Derivative Disclosures

I. Material & Component Substitution

Derivative 1.1: Ferroelectric RAM (F-RAM) for License Storage

• Enabling Description: Instead of conventional non-volatile memory (NVM) like Flash or EEPROM for storing the bundle-type and node license parameters, this variation utilizes Ferroelectric RAM (F-RAM). F-RAM offers significantly higher write endurance and lower power consumption. The license information, including the cluster's Right-to-Use (RTU) token and the pool of node licenses, is written to a dedicated F-RAM module (e.g., a Cypress/Infineon EXCELON™ F-RAM) on each node's controller board. The low latency of F-RAM allows for near-instantaneous license verification during node boot-up and cluster formation, reducing the overall time to cluster activation. The cluster creation module (create cluster module 412) is modified to interface with the F-RAM controller via an SPI or I2C bus, ensuring atomic write operations for license branding to prevent corruption.
• Mermaid Diagram:

  graph TD
      A[External License Server] -->|License Key| B(Management Module);
      B -->|RTU Token & Node Licenses| C{Node Controller};
      C -->|Write via SPI/I2C| D[F-RAM Module];
      E[Cluster Initialization] --> F{Read License from F-RAM};
      F --> G{Verify Bundle-Type Compliance};
      G -->|Compliant| H[Activate Cluster];
      G -->|Non-compliant| I[Inhibit Node Join];
  

Derivative 1.2: System-on-a-Chip (SoC) with Integrated Secure Enclave

• Enabling Description: This variation implements the node and cluster logic on a System-on-a-Chip (SoC) that contains a hardware-based secure enclave (e.g., ARM TrustZone or a dedicated security co-processor). The license information (bundle-type, node license pool) is stored within this encrypted, tamper-resistant enclave. The create cluster module, add node module, and all license verification logic execute within this secure environment. Any attempt to access or modify the license data from the non-secure part of the SoC is cryptographically denied. This provides a robust defense against "gray market" nodes where license data might be illicitly copied or modified, as the unique hardware-backed keys within the enclave cannot be cloned. Communication between enclaves on different nodes for cluster formation is established via a mutually authenticated TLS channel, using certificates rooted in the secure hardware.
• Mermaid Diagram:

  sequenceDiagram
      participant NodeA as Node A (SoC)
      participant NodeB as Node B (SoC)
      NodeA->>NodeA: Secure Enclave: Load License Info
      NodeB->>NodeB: Secure Enclave: Load License Info
      NodeA->>NodeB: Initiate Secure Handshake (TLS)
      Note over NodeA, NodeB: Authentication via Hardware-rooted Certificates
      NodeB-->>NodeA: Handshake Complete
      NodeA->>NodeB: Request to Join Cluster (inside TLS)
      NodeB-->>NodeA: Verify Node A's License Brand (inside Enclave)
      NodeB-->>NodeA: Approve Join & Update Cluster State
  

---

II. Operational Parameter Expansion

Derivative 2.1: Hyperscale Datacenter License Enforcement

• Enabling Description: The system is scaled to manage licensing for a hyperscale computing cluster comprising over one million nodes distributed across multiple geopolitical regions. The "bundle-type" parameter is extended to include geo-fencing rules and data residency requirements (e.g., GDPR compliance). A central, highly-available license server (external license server 460) is replaced with a distributed ledger (blockchain) or a globally replicated database (e.g., Google Spanner) to manage the Right-to-Use licenses and node license pools. When a new rack of servers (nodes) is provisioned, the add node module on a regional cluster manager queries this distributed ledger to acquire and "brand" the nodes. The activation process (activating the computing cluster) is hierarchical; sub-clusters are activated locally, and the global cluster state is only validated once a quorum of regional clusters meets the global "bundle-type" specifications.
• Mermaid Diagram:

  graph TD
      subgraph Global
          A[Distributed License Ledger];
      end
      subgraph Region_US
          B[US Cluster Manager] --> C{US Sub-cluster};
      end
      subgraph Region_EU
          D[EU Cluster Manager] --> E{EU Sub-cluster};
      end
      subgraph Region_APAC
          F[APAC Cluster Manager] --> G{APAC Sub-cluster};
      end
      B -- Query/Update --> A;
      D -- Query/Update --> A;
      F -- Query/Update --> A;
      C -- Activate --> H((Global Cluster Activation));
      E -- Activate --> H;
      G -- Activate --> H;
  

Derivative 2.2: Nanoscale Molecular Computing Cluster

• Enabling Description: The principles are applied to a theoretical nanoscale computing cluster where individual "nodes" are complex molecules or quantum dots capable of computation and state storage. License information is encoded in the molecular structure or quantum state of a designated "license molecule." The "bundle-type" parameter dictates the maximum number of computational molecules that can form a stable, functional cluster for a specific task (e.g., drug simulation). "Adding a node" involves a chemical or quantum-mechanical interaction that binds a new computational molecule to the cluster. The cluster "activates" (i.e., begins its computation) only when the energy state of the entire molecular assembly corresponds to a valid, licensed configuration. An invalid configuration (too many or incompatible molecules) results in an unstable, non-functional state.
• Mermaid Diagram:

  stateDiagram-v2
      [*] --> Unformed
      Unformed --> Initialized: Add License Molecule
      Initialized --> Building: Add Computational Molecule
      Building --> Building: Add more molecules
      Building --> Activated: Node count complies with Bundle-Type
      Activated --> [*]: Computation Complete
      Building --> Unstable: Node count exceeds Bundle-Type
      Unstable --> [*]: Cluster Disassociates
  

---

III. Cross-Domain Application

Derivative 3.1: Aerospace - Federated Satellite Constellation Management

• Enabling Description: A constellation of satellites from different manufacturers and operators forms a federated cluster for Earth observation. Each satellite is a "node." The license information stored on each satellite's flight computer dictates its participation rights. The bundle-type parameter defines characteristics of the federated service, such as the minimum number of satellites required for 24/7 global coverage (size), the required sensor types (additional bundle-type characteristic), and data sharing permissions. When a ground station commands the formation of a new imaging cluster for a specific mission, satellites are added. The cluster activates—begins coordinated data acquisition and transmission—only when satellites with compatible licenses and capabilities form a compliant group. This prevents unauthorized use of high-resolution sensors or the formation of a cluster that violates international data sharing agreements.
• Mermaid Diagram:

  flowchart LR
      A[Ground Station] -- Command --> B{Cluster Formation Request};
      B -- Polls Satellites --> C[Sat-A (Node)];
      B -- Polls Satellites --> D[Sat-B (Node)];
      B -- Polls Satellites --> E[Sat-C (Node)];
      C -- Reports License --> B;
      D -- Reports License --> B;
      E -- Reports License --> B;
      B -- Verifies Bundle Compliance --> F{Compliant?};
      F -- Yes --> G[Activate Coordinated Imaging];
      F -- No --> H[Reject Cluster Formation];
  

Derivative 3.2: AgTech - Autonomous Drone Swarm Licensing

• Enabling Description: A farmer purchases a "bundle" license for a swarm of autonomous agricultural drones. Each drone is a "node." The license, stored in the drone's non-volatile memory, specifies a bundle-type for "Crop Dusting - 5 Drones Max" or "Soil Analysis - 10 Drones Min." When a task is initiated from a central controller (e.g., a tablet), it attempts to form a cluster of available drones. The add node module ensures only drones with the correct bundle-type brand can join. The swarm (computing cluster) activates its task (e.g., begins spraying) only when the number of connected drones is within the licensed range. This allows manufacturers to sell scalable solutions and prevents the unauthorized use of a small, low-cost swarm for a large-scale operation that requires a more expensive license.
• Mermaid Diagram:

  erDiagram
      FARMER ||--o{ DRONE : "owns"
      DRONE {
          string DroneID
          string LicenseBrand
      }
      FARMER ||--|{ LICENSE : "purchases"
      LICENSE {
          string BundleType
          int MinNodes
          int MaxNodes
      }
      DRONE }o--|| CLUSTER : "joins"
      CLUSTER {
          string TaskID
          string RequiredBundleType
          int CurrentNodeCount
      }
  

Derivative 3.3: Consumer Electronics - Smart Home Ecosystem Control

• Enabling Description: A premium smart home ecosystem (e.g., for security or energy management) requires a license to function. The central hub is the first computing node. Other smart devices (locks, cameras, thermostats) are additional nodes. The bundle-type dictates the tier of service, e.g., "Gold Security Bundle" allows up to 10 cameras and 4 smart locks. When a new device is added to the home network, the hub attempts to add it to the security cluster. It checks the device's compatibility and the total node count against the bundle license. The premium features (computing cluster) like coordinated video recording or AI-based threat detection are only activated if the number and type of devices comply with the license. If a user adds an 11th camera, it may function in a basic, standalone mode but will not be integrated into the licensed premium security service.
• Mermaid Diagram:

  graph TD
      A[User adds new Smart Camera] --> B{Smart Hub};
      B --> C{Check current Node Count};
      C --> D{Count < MaxNodes?};
      D -- Yes --> E{Add Camera to Cluster};
      E --> F[Activate Premium AI Security Feature];
      D -- No --> G{Add Camera in Standalone Mode};
      G --> H[Notify User: License Limit Exceeded];
  

---

IV. Integration with Emerging Tech

Derivative 4.1: AI-Driven Predictive License Allocation

• Enabling Description: An AI model running on the management module (management module 450) analyzes historical cluster usage patterns, resource demands, and task schedules. It predicts future needs for cluster expansion or contraction. Based on these predictions, it proactively requests new node license parameters from the external license server before they are actually needed, minimizing delays in scaling up. The bundle-type is dynamically adjusted by the AI to optimize cost versus performance. For example, if the AI predicts a high-demand period, it might automatically upgrade the Right-to-Use license to a larger bundle-type for 24 hours and then downgrade it to save costs.
• Mermaid Diagram:

  sequenceDiagram
      participant AI as AI Model
      participant Manager as Management Module
      participant Server as External License Server
      loop Usage Analysis
          AI->>Manager: Analyze Cluster Metrics
      end
      AI->>Manager: Predict Future Demand Spike
      Manager->>Server: Request Temporary License Upgrade
      Server-->>Manager: Issue Upgraded RTU Token
      Manager->>Manager: Apply New Bundle-Type to Cluster
  

Derivative 4.2: IoT Sensor-Based Compliance Monitoring

• Enabling Description: Each computing node is equipped with IoT sensors that monitor physical and operational parameters like temperature, power consumption, and chassis intrusion. This sensor data is cryptographically signed and streamed to the cluster module. The bundle-type parameter is extended to include operational compliance rules (e.g., "must operate below 80°C"). The license check process (FIG. 6) is triggered not just periodically, but also in real-time when a sensor reports an anomaly. If a node violates the operational parameters defined in the license (e.g., it is overclocked and overheating), its license status is flagged as non-compliant, and the error routine can quarantine the node or throttle its performance until it returns to a compliant state.
• Mermaid Diagram:

  flowchart TD
      A[IoT Sensor on Node] -- Temp > 80°C --> B{Real-time Anomaly Event};
      B --> C{Trigger License Check};
      C --> D{Is Node violating operational license?};
      D -- Yes --> E[Invoke Error Routine];
      E --> F[Quarantine Node];
      D -- No --> G[Continue Normal Operation];
  

Derivative 4.3: Blockchain for Immutable License Provenance

• Enabling Description: The entire lifecycle of a license—from creation by the vendor to assignment to a cluster and "branding" onto a node—is recorded as a series of transactions on a private blockchain (e.g., using Hyperledger Fabric). The Right-to-Use license 422 and node license pool 424 are represented as non-fungible tokens (NFTs) on the ledger. When a cluster is created, the management module transfers the NFT representing the base licenses to a smart contract that governs the cluster. Adding a node involves the smart contract assigning a specific node license NFT to the node's unique public key. This creates an unchangeable, auditable trail of license ownership and assignment, completely eliminating the possibility of "gray market" nodes by ensuring every node's license can be traced back to a legitimate origin on the blockchain.
• Mermaid Diagram:

  graph LR
      A[Vendor Mints License NFT] --> B(License Ledger);
      C[Customer Buys License] --> D{Transfer NFT to Customer Wallet};
      D --> E[Customer Deploys Cluster];
      E --> F{Cluster Smart Contract};
      F -- Assigns --> G[Node A gets License Token];
      F -- Assigns --> H[Node B gets License Token];
      B <--> F;
  

---

V. The "Inverse" or Failure Mode

Derivative 5.1: Graceful Degradation on License Incompatibility

• Enabling Description: Instead of the error routine completely inhibiting the operation of a non-compliant node, this variation places the node into a "gracefully degraded" state. If a license check fails (e.g., an expired license or incompatible brand-type), the cluster module restricts the node's capabilities. For instance, a storage node might be limited to read-only operations, or a compute node might be restricted to running only low-priority, non-critical workloads. The node remains part of the cluster's management domain, allowing an administrator to remotely diagnose the issue and apply a valid license without physical intervention. This ensures partial system availability instead of complete node failure.
• Mermaid Diagram:

  stateDiagram-v2
      state "Fully Functional" as Active
      state "Degraded Mode" as Degraded
      [*] --> Active: License Valid
      Active --> Degraded: License Check Fails
      Degraded --> Active: New License Applied
      Active --> [*]: Node Decommissioned
      Degraded --> [*]: Node Decommissioned
  

---

Combination Prior Art Scenarios

1. Combination with OPC UA (Open Platform Communications Unified Architecture): The compatibility enforcement method of US 8,370,416 is integrated into an industrial control system (ICS) environment using the OPC UA standard. The "nodes" are programmable logic controllers (PLCs) or industrial PCs. The "bundle-type" license, stored on an OPC UA server, defines the number and type of devices (e.g., "Motor Drive," "Robot Arm") that can participate in a coordinated manufacturing process ("cluster"). When a new PLC is added to the network, it uses the OPC UA discovery and security models to connect to the server. The server, implementing the patent's add node logic, verifies the PLC's license against the process bundle-type before allowing it to subscribe to real-time process data, thereby preventing unauthorized or misconfigured devices from disrupting a production line.

2. Combination with OpenAPI Specification: A microservices-based cloud application uses the OpenAPI Specification to define its inter-service communication. Each microservice instance is a "node." The license information, managed by an API Gateway, functions as the cluster module. The bundle-type is defined in a custom section of the OpenAPI document (e.g., x-license-bundle) and specifies the maximum number of instances for a given service tier (e.g., "Free Tier: 2 instances," "Pro Tier: 10 instances"). When a service attempts to scale up, the API Gateway intercepts the orchestration command (e.g., from Kubernetes), checks the current instance count against the bundle-type in the OpenAPI definition, and only allows the new instance to be added and activated if it complies with the license.

3. Combination with Hyperledger Besu: The license management system is built as a decentralized application (DApp) on a Hyperledger Besu blockchain, which is an Ethereum client designed for enterprise use. The license information is encoded in an ERC-1155 multi-token smart contract, where each token ID represents a different bundle-type or node license parameter. A company can purchase a set of these tokens. To create a cluster, the first computing node calls a function on the smart contract, locking the main bundle-type token. To add other nodes, the contract requires the transfer of a node license token from the company's wallet to the node's address. The cluster activates once the smart contract's state reflects the correct number of locked node tokens corresponding to the main bundle token's rules, creating a fully transparent, auditable, and decentralized license enforcement mechanism.