US 8234705

A concise summary of US patent 8,234,705 is provided below.

Title: Contagion isolation and inoculation

Assignee: K Mizra LLC. Notably, the patent record indicates that the listed assignees may be inaccurate.

Inventors:

• James A. Roskind
• Aaron T. Emigh

Filing Date: September 27, 2005

Issue Date: July 31, 2012

Abstract:
The patent describes a method for "contagion isolation and inoculation." When a host computer requests to connect to a protected network, a determination is made as to whether the host needs to be quarantined. If quarantined, the host is granted only limited access to the network. This limited access is typically sufficient to remedy the condition that led to the quarantine, such as downloading software patches, updates, or definitions. Any attempts by the quarantined host to communicate with other hosts not involved in the remediation process are redirected to a quarantine system, such as a server, which can provide information, notices, updates, and instructions to the user.

Plain-Language Overview of Independent Claims:

After a thorough review of the patent's claims, the following is a plain-language summary of the independent claims:

• Claim 1: This claim outlines a method for managing network security. When a device (host) tries to connect to a protected network, the system checks if it needs to be quarantined. If it does, its access is restricted. Any attempt by the quarantined device to communicate with network resources not essential for fixing the problem (remediation) is rerouted to a special quarantine server.

• Claim 15: This claim describes a physical system designed to perform the security method. It includes a network interface to receive connection requests and a processor. The processor determines if a connecting device should be quarantined, limits its access if necessary, and redirects its non-remediation traffic to a quarantine server.

• Claim 26: This claim covers a computer-readable medium (like a hard drive or CD-ROM) that stores instructions. When these instructions are run on a computer, they cause the computer to execute the security method described in Claim 1: receiving a connection request, deciding whether to quarantine, and if so, limiting access and redirecting traffic.

Litigation:
A search of the U.S. Court of Appeals for the Federal Circuit (CAFC) dockets for 2026 did not reveal any specific litigation concerning US patent 8,234,705.

Litigation and Administrative Challenges Involving US Patent 8,234,705

As of April 26, 2026, US Patent 8,234,705, titled "Contagion isolation and inoculation," has been the subject of multiple legal and administrative challenges, including district court litigations and proceedings before the Patent Trial and Appeal Board (PTAB). The patent is currently owned by K Mizra LLC.

Below is a detailed list of the known legal disputes involving this patent.

District Court Litigation

The following are pending litigations identified in various jurisdictions:

• Case Number: 1:26-cv-00316

  • Plaintiff(s): To be determined from court records.
  • Defendant(s): To be determined from court records.
  • Jurisdiction: U.S. District Court for the Western District of Texas.
  • Filing Date: Information not publicly available.
  • Status: Pending.

• Case Number: 1:25-cv-00236

  • Plaintiff(s): To be determined from court records.
  • Defendant(s): To be determined from court records.
  • Jurisdiction: U.S. District Court for the Western District of Texas.
  • Filing Date: Information not publicly available.
  • Status: Pending.

• Case Number: 3:25-cv-04833

  • Plaintiff(s): To be determined from court records.
  • Defendant(s): To be determined from court records.
  • Jurisdiction: U.S. District Court for the Northern District of California.
  • Filing Date: Information not publicly available.
  • Status: Pending.

• Case Number: 5:25-cv-04833

  • Plaintiff(s): To be determined from court records.
  • Defendant(s): To be determined from court records.
  • Jurisdiction: U.S. District Court for the Northern District of California.
  • Filing Date: Information not publicly available.
  • Status: Pending.

Patent Trial and Appeal Board (PTAB) Proceedings

The patent has faced several challenges at the PTAB, primarily through Inter Partes Review (IPR) petitions, which seek to invalidate the patent's claims.

• Case Number: IPR2025-01468

  • Petitioner(s): Cloud Software Group Inc., Citrix Systems Inc.
  • Patent Owner: K Mizra LLC
  • Filing Date: August 29, 2025
  • Outcome/Status: Procedural Termination.

• Case Number: IPR2025-01436

  • Petitioner(s): Google LLC
  • Patent Owner: K Mizra LLC
  • Filing Date: September 19, 2025
  • Outcome/Status: Not Instituted - Procedural.

• Case Number: IPR2025-01115

  • Petitioner(s): Netskope Inc.
  • Patent Owner: K Mizra LLC
  • Filing Date: August 13, 2025
  • Outcome/Status: Not Instituted - Procedural.

• Case Number: IPR2022-00084

  • Petitioner(s): [Cisco Systems Inc.](/litigations/by-plaintiff/Cisco%20Systems%20Inc.), Forescout Technologies Inc., Hewlett Packard Enterprise Co.
  • Patent Owner: K Mizra LLC
  • Filing Date: October 22, 2021
  • Outcome/Status: Settled.

• Case Number: IPR2022-00081

  • Petitioner(s): Cisco Systems Inc., Forescout Technologies Inc., Hewlett Packard Enterprise Co.
  • Patent Owner: K Mizra LLC
  • Filing Date: October 22, 2021
  • Outcome/Status: Settled.

• Case Number: IPR2021-00593

  • Petitioner(s): Cisco Systems Inc., Forescout Technologies Inc., Hewlett Packard Enterprise Co.
  • Patent Owner: K Mizra LLC
  • Filing Date: March 15, 2021
  • Outcome/Status: Settled.

Ex Parte Reexamination

An ex parte reexamination of the patent has also been requested.

• Application Number: 90016173
  • Requestor: Google LLC
  • Patent Owner: K Mizra LLC
  • Filing Date: April 8, 2026
  • Status: Pending Receipt of Original or Corrected Ex Parte Reexam Request. This reexamination is noted as being related to the copending litigations.

Based on the provided information for US patent 8,234,705, here is an analysis of its AIA trial proceedings and strategic implications for a defendant as of May 13, 2026.

Proceedings overview

There has been one AIA trial proceeding filed against US patent 8,234,705, which resulted in a discretionary denial of institution. Consequently, the patent's claims have not yet been substantively reviewed or weakened by the Patent Trial and Appeal Board (PTAB), meaning a defendant faces a patent that has not been tested in an IPR but also has no claims confirmed as patentable over asserted prior art.

---

IPR2025-01436 — Google LLC v. K Mizra LLC

• Type: Inter Partes Review
• Filed: 2025-09-19
• Status: Discretionary Denial — This means the PTAB declined to institute a trial, not based on the merits of the prior art arguments, but for other procedural reasons. The Board never reached the question of whether the challenged claims were unpatentable.
• Judge panel: Information on the specific Administrative Patent Judges (APJs) is not available in the provided data. This would be found in the PTAB's decision document.
• Petition grounds: While the specific claims and prior art are not detailed in the provided summary, a petition would have asserted that one or more claims of US 8,234,705 were unpatentable under 35 U.S.C. § 102 (anticipation) or § 103 (obviousness) based on prior-art patents or printed publications.
• Institution decision: Denied on 2026-04-13 (based on the "last modified" date). A discretionary denial is commonly based on the PTAB's Fintiv factors, which weigh the status of a parallel district court case involving the same patent. The Board likely concluded that the co-pending litigation was too advanced to warrant the use of PTAB resources.
• Final Written Decision: None issued. Because the trial was not instituted, the PTAB did not conduct a full review and did not issue a final decision on the patentability of the claims.
• Settlement / termination: The proceeding was terminated at the institution stage by the PTAB's denial. There was no settlement that terminated the IPR itself.
• Appeal: Decisions declining to institute an IPR are final and non-appealable to the U.S. Court of Appeals for the Federal Circuit.
• Defensive value: This proceeding provides limited direct defensive value, as the merits of the patent's validity were never decided. However, it provides crucial intelligence: the patent owner, K Mizra LLC, is litigating this patent, and the PTAB may be inclined to discretionarily deny future IPRs if parallel litigation is sufficiently advanced. It shows a defendant must file any future IPR very early in a litigation timeline to have a chance of being heard.

Strategic summary

The patentability of the claims of US 8,234,705 remains entirely UNTESTED at the PTAB. No claims have been canceled, and none have been sustained or confirmed. The single IPR attempt by Google was terminated via a discretionary denial, which is a procedural outcome that does not touch upon the substantive weakness or strength of the patent claims.

From an estoppel perspective, this is advantageous for a future defendant. Because IPR2025-01436 did not result in a Final Written Decision, the petitioner (Google LLC) and its real parties-in-interest are not subject to IPR estoppel under 35 U.S.C. § 315(e)(2). They are not barred from raising the same or other invalidity grounds in a future PTAB petition or in district court. Any other defendant is similarly free to challenge the patent on any grounds.

The pattern signals a typical assertion campaign by a patent monetization entity (K Mizra LLC) against a large operating company (Google). The discretionary denial highlights the importance of the PTAB's Fintiv framework and its impact on parallel proceedings. Any defendant should assume the patent owner will use the status of ongoing litigation to argue against the institution of any future IPRs.

Recommended next steps

• Analyze the Discretionary Denial Decision: For a defendant, the most critical next step is to obtain and meticulously analyze the PTAB's Decision on Institution for IPR2025-01436. This document will explain the precise reasons for the denial. Understanding whether it was due to trial date proximity in a specific court, the scope of litigation arguments, or other factors is essential for crafting a future IPR strategy that can avoid the same outcome.
• Assess Litigation Timelines: If you are a defendant in a new litigation, you must act with extreme urgency. The history of this patent shows a high risk of discretionary denial. Your strategy for filing an IPR must be developed and executed within the first few months of being served, well before any significant discovery or claim construction milestones in the district court case.
• Evaluate Google's Petition: Although the IPR was not instituted, the petition filed by Google is a public document. It contains prior art and invalidity arguments that were likely vetted by a sophisticated party. This petition can serve as a valuable starting point for developing your own invalidity contentions, potentially saving significant time and expense.

Inventors

• James A. Roskind: At the time of filing, Mr. Roskind was known for his work on the design of the JavaScript language while at Netscape and was active in various technology startups.
• Aaron T. Emigh: Mr. Emigh was the co-founder and CTO of Radix Labs, the entity related to the original assignee.

There are no unusual patterns, such as mass departures, noted in their employment history around the time of filing.

Original assignee

The original assignee of record was Radix Holdings LLC. This entity appears to be the intellectual property holding company associated with Radix Labs, Inc., a startup co-founded by inventor Aaron Emigh. Radix Labs focused on developing security and anti-contagion software. It is unclear if Radix Labs ever shipped a commercial product embodying the specific claims of this patent before it ceased operations. The company appears to be dissolved, with its patents being sold off starting around 2017.

Assignment timeline

A search of the USPTO Patent Assignment Database for US 8,234,705 reveals the following chain of ownership.

• 2009-10-16 (executed) / recorded 2009-11-20 — Reel 023610/0556

  • Conveyance: Assignment
  • Assignor: AARON T. EMIGH, RADIX LABS, LLC, JAMES A. ROSKIND
  • Assignee: RADIX HOLDINGS, LLC
  • Correspondent: LAW OFFICE OF ROBERT C. HOHL, CHANTILLY, VA 20151
  • Context: Internal transfer consolidating the invention from the individual inventors and the operating company to a dedicated holding company.

• 2017-05-09 (executed) / recorded 2017-05-09 — Reel 041280/0172

  • Conveyance: Assignment
  • Assignor: RADIX HOLDINGS, LLC
  • Assignee: SPECTRUM PATENTS, INC.
  • Correspondent: WILLIAM W. L. CHEN, LAW OFFICES OF WILLIAM W. L. CHEN, LOS ANGELES, CA 90017
  • Context: Sale of the patent from the original inventor-controlled entity to a third party, Spectrum Patents, Inc.

• 2017-10-13 (executed) / recorded 2017-10-13 — Reel 042571/0879

  • Conveyance: Assignment
  • Assignor: SPECTRUM PATENTS, INC.
  • Assignee: NETWORK SECURITY TECHNOLOGIES, LLC
  • Correspondent: WILLIAM W. L. CHEN, LAW OFFICES OF WILLIAM W. L. CHEN, LOS ANGELES, CA 90017. This is the same correspondent as the previous transfer.
  • Context: Transfer from one holding company to another, likely an internal reorganization or sale between related entities given the shared correspondent.

• 2020-01-13 (executed) / recorded 2020-01-13 — Reel 051059/0572

  • Conveyance: Assignment of Assignor's Interest
  • Assignor: NETWORK SECURITY TECHNOLOGIES, LLC
  • Assignee: K.MIZRA LLC
  • Correspondent: J. Michael Martinez de Andino, ANDINO REYNAL & SCHOCH, CORAL GABLES, FL 33134
  • Context: Sale of the patent to K. Mizra LLC, an entity that has since asserted the patent in litigation.

Timeline diagram

timeline
    title Ownership of US 8234705
    2005 : Application filed
    2009 : Assigned to Radix Holdings LLC
    2012 : Patent Issued
    2017 : Sold to Spectrum Patents Inc
         : Transferred to Network Security Tech LLC
    2020 : Sold to K Mizra LLC
    2021 : First infringement suits filed

NPE / troll-pattern signals

1. Shell-entity transfer — Present. The patent was transferred from Radix Holdings LLC (associated with the inventors) to Spectrum Patents, Inc., then to Network Security Technologies, LLC, and finally to K. Mizra LLC. These latter three entities have no public evidence of product development and appear to be special-purpose vehicles for holding and asserting patents. K. Mizra LLC is a Texas LLC with a listed address corresponding to a registered agent service. The transfers are documented in Reels 041280/0172, 042571/0879, and 051059/0572.

2. Known asserter in the chain — Present. The current assignee, K. Mizra LLC, is a known patent asserter. Unified Patents lists K. Mizra LLC as a frequent plaintiff, noting its acquisition of patents from Network Security Technologies, LLC and subsequent litigation campaigns. Litigation records confirm K. Mizra LLC has filed suits asserting this patent (e.g., K. Mizra LLC v. ESET, LLC, Case 6:20-cv-01031, W.D. Tex.).

3. Repeat correspondent across the chain — Present. The attorney William W. L. Chen acted as the correspondent for both the transfer to Spectrum Patents, Inc. (Reel 041280/0172, dated 2017-05-09) and the subsequent transfer from Spectrum Patents, Inc. to Network Security Technologies, LLC (Reel 042571/0879, dated 2017-10-13). This recurrence for two consecutive transfers involving different LLCs is a strong indicator of a coordinated campaign.

4. Cascading transfers — Present. The patent was transferred from Spectrum Patents, Inc. to Network Security Technologies, LLC in October 2017, just five months after Spectrum acquired it in May 2017. While the subsequent transfer to K. Mizra LLC was just over two years later (January 2020), the initial rapid-fire transfer between two shell entities with the same correspondent is a positive signal.

5. Pre-litigation transfer — Present. The assignment to the current owner and plaintiff, K. Mizra LLC, was executed and recorded on January 13, 2020 (Reel 051059/0572). The first infringement suits asserting this patent were filed in late 2020 and early 2021, well within a year of this final transfer, indicating the patent was acquired for the purpose of assertion.

6. Bankruptcy fire-sale — Not present. There is no evidence that Radix Holdings LLC or Radix Labs, Inc. underwent formal bankruptcy proceedings.

7. Privateering — Not present. There is no evidence to suggest that the inventors or the original assignee are directing the assertion campaign by K. Mizra LLC against their competitors.

8. Defensive aggregator (anti-NPE) — Not present. No defensive aggregators appear in the ownership chain.

Verdict

NPE — high confidence

The ownership chain of US 8,234,705 displays multiple strong signals of non-practicing entity activity. The patent was moved from its original inventor-affiliated owner through a cascade of shell entities (Reels 041280/0172, 042571/0879), including two transfers handled by the same correspondent attorney. The patent's current owner, K. Mizra LLC, is a known high-frequency plaintiff per Unified Patents and began its assertion campaign (Reel 051059/0572) shortly after acquiring the patent.

Verification Link: USPTO Patent Assignment Search for US 8234705

An analysis of select prior art cited against U.S. Patent 8,234,705, titled "Contagion isolation and inoculation," reveals several earlier patents that touch upon key concepts of network security, including the quarantining of potentially infected computers. This analysis focuses on the most relevant of the 60 patent citations, examining their contributions to the field and their potential to anticipate the claims of the '705 patent under 35 U.S.C. § 102.

The '705 patent, filed on September 27, 2005, describes a system where a host attempting to connect to a protected network is assessed to determine if it needs to be quarantined. If quarantined, the host is given limited network access, primarily for remediation purposes, such as downloading security patches or updates. Attempts to access other network resources are redirected to a quarantine server that provides information and instructions to the user.

Below is an examination of key prior art and the specific claims of U.S. Patent 8,234,705 they may anticipate.

Key Prior Art Analysis:

1. U.S. Patent 6,804,780 B1: System and method for protecting a computer and a network from hostile downloadables

• Full Citation: US Patent 6,804,780 B1, filed November 7, 1997, and issued October 12, 2004.
• Brief Description: This patent discloses a system for protecting a network from suspicious and hostile "Downloadables" such as Java applets and ActiveX controls. The system uses a security policy to inspect and block malicious content at the gateway, before it can reach the client computer. It describes a method of receiving a downloadable, comparing it against a security policy, and discarding it if the policy is violated.
• Potential Anticipation of Claims: This prior art appears to anticipate the broader concepts within the independent claims of the '705 patent, such as monitoring network traffic and taking protective action. Specifically, it could be argued that it anticipates elements of Claim 1, which recites determining if a host is in an "insecure condition" and, if so, preventing it from sending data to other hosts on the protected network. The '780 patent's method of inspecting and blocking hostile downloadables at the network gateway is a form of identifying an insecure condition and taking preventative measures.

2. U.S. Patent 7,010,807 B1: System and method for virus protection of computers on a local area network

• Full Citation: US Patent 7,010,807 B1, filed April 13, 2001, and issued March 7, 2006.
• Brief Description: This patent describes a system where a firewall or other Internet access module enforces an anti-virus policy for client computers on a LAN. The policy can dictate the frequency of anti-virus software updates. Any computer not in compliance with the policy is denied Internet access. The firewall can also push updates to non-compliant clients to bring them into compliance.
• Potential Anticipation of Claims: This patent is highly relevant to the core claims of the '705 patent. It directly addresses the concept of checking a host's compliance with a security policy and restricting its network access if it fails to comply. The '807 patent's system of denying internet access to non-compliant computers and providing updates strongly anticipates the quarantine and remediation steps outlined in Claim 1 and Claim 15 of the '705 patent. The firewall in the '807 patent acts as a quarantine enforcement point, similar to the system described in the '705 patent.

3. U.S. Patent 5,623,600 A: Virus detection and removal apparatus for computer networks

• Full Citation: US Patent 5,623,600 A, filed September 26, 1995, and issued April 22, 1997.
• Brief Description: This patent details a system for detecting and eliminating viruses on a computer network using FTP and SMTP proxy servers. These servers scan all incoming and outgoing files and messages for viruses before they are transferred. If a virus is detected, the file or message is deleted, preventing it from entering or leaving the network.
• Potential Anticipation of Claims: While an earlier technology, the '600 patent discloses the fundamental concept of inspecting data at the network boundary and preventing the transmission of malicious content. This could be seen as anticipating the element of detecting a threat and taking preventative action as recited in Claim 1 of the '705 patent. The proxy servers in the '600 patent perform a function analogous to the initial security check in the '705 patent.

4. NEC Corporation Publication: "Development of PC Quarantine System"

• Publication Date: Believed to be publicly available before the 2005 filing date of the '705 patent.
• Brief Description: This non-patent literature describes a "PC Quarantine System" designed to prevent insecure PCs from connecting to an enterprise network. The system checks the security level of a PC at the time of connection and, if found to be insecure, places it on a quarantine network with limited access. This restricted network allows the PC to receive necessary security patches and updates to meet the required security level before being granted full network access.
• Potential Anticipation of Claims: This document is exceptionally relevant and likely anticipates the core concepts of the '705 patent's independent claims. It explicitly uses the term "quarantine" and describes a system that performs the same essential functions: checking a host's security status upon connection, isolating non-compliant hosts to a restricted network, and providing remediation resources. This publication could be a strong basis for an invalidity argument against Claim 1 and Claim 15 of the '705 patent, as it describes the entire claimed process.

In conclusion, while U.S. Patent 8,234,705 provides a detailed implementation of a contagion isolation and inoculation system, the fundamental concepts of network security, including the inspection of hosts, quarantining of non-compliant devices, and providing remediation, were well-established in the prior art. The cited references, particularly U.S. Patent 7,010,807 and the NEC "PC Quarantine System" publication, appear to disclose many of the key elements of the '705 patent's independent claims, suggesting a strong potential for anticipation.

Obviousness Analysis of US Patent 8,234,705

This analysis evaluates the patentability of the independent claims of U.S. Patent 8,234,705 ("the '705 patent") in light of prior art, focusing on the standard of obviousness under 35 U.S.C. § 103. The '705 patent, with a priority date of September 27, 2004, describes a method and system for quarantining a host computer that requests access to a protected network.

I. Standard for Obviousness

An invention is considered obvious if the differences between the claimed invention and the prior art are such that the subject matter as a whole would have been obvious at the time the invention was made to a person having ordinary skill in the art (PHOSITA). An obviousness rejection requires a clear articulation of the reasons why the claimed invention would have been obvious. This involves demonstrating not just that individual elements of the claim existed in the prior art, but that a PHOSITA would have been motivated to combine these elements with a reasonable expectation of success.

II. Person Having Ordinary Skill in the Art (PHOSITA)

For the '705 patent, a PHOSITA would be an individual with a bachelor's degree in computer science, electrical engineering, or a related field, and 2-3 years of professional experience in network administration or network security. This experience would include familiarity with network protocols (TCP/IP), firewalls, routing, and common security threats such as viruses and worms prevalent in the early 2000s.

III. Analysis of Independent Claims

The independent claims (1, 15, and 26) of the '705 patent recite the same core invention. The analysis below focuses on Claim 1 as representative of all three.

Claim 1 Elements:
a) Receiving a request from a host to connect to a protected network.
b) Determining whether the host is required to be quarantined.
c) If so, providing only limited access to the protected network.
d) Redirecting communication attempts from the quarantined host (for non-remediation purposes) to a quarantine system/server.

IV. Prior Art and Motivation to Combine

The concept of network quarantine was a known solution to the problem of infected or non-compliant devices connecting to a network prior to the '705 patent's 2004 priority date. The proliferation of worms like MSBlast and Sobig.F in 2003 created a significant and widely recognized need to verify the security posture of connecting devices, particularly those of remote users.

Microsoft's Network Access Quarantine Control (NAQC)

In 2003, Microsoft introduced a feature in Windows Server 2003 called Network Access Quarantine Control (NAQC). This system was explicitly designed to address the risks posed by remote access clients connecting to a corporate network.

• Teaches Elements (a), (b), and (c): Microsoft's white paper on NAQC, published in March 2003, describes a system that intercepts a connection request from a remote access system (element a). It then places the connecting system into a "quarantine with limited access" (element c) until a script can validate its compliance with security policies, such as having the latest patches and antivirus updates (element b). The system was designed to ensure legitimate users complied with policies regarding firewalls, anti-virus software, and security patches.

• Motivation for Element (d): While the 2003 descriptions of NAQC focus on running a script to check for compliance, the logical next step for a PHOSITA would be to automate the remediation process for non-compliant machines. A non-compliant user needs a way to fix their system to gain full access. Simply blocking them is counterproductive. The most direct way to facilitate this is to redirect their traffic to a remediation server. This server could host necessary patches, antivirus updates, and provide instructions.

The concept of a separate, isolated "quarantine network" where non-compliant PCs are sent for remediation was a known strategy. A paper by NEC Corporation discusses this exact architecture: "The PCs that do not comply with the security policy are isolated in a quarantine network that is configured separately from the backbone network as a countermeasure in support of the security policy." The purpose of this isolation is explicitly for "remediation."

Motivation to Combine:

A PHOSITA in 2004, facing the well-known problem of non-compliant remote devices, would have been highly motivated to combine a system like Microsoft's NAQC with the concept of a dedicated remediation server.

1. Problem-Solving: The primary goal of a quarantine system is not just to block, but to securely grant access. If a device is non-compliant, the system must provide a path to compliance. Combining NAQC's quarantine function with a remediation server solves the problem of how to fix a non-compliant machine.
2. Predictable Results: Redirecting a non-compliant host's traffic to a server that holds the tools to make it compliant is a straightforward and predictable solution. A PHOSITA would reasonably expect that a quarantined device, when its web traffic is redirected to a server with patches, could download those patches and achieve compliance.
3. Efficiency and Automation: Manually remediating every quarantined machine is inefficient. Automating the process by redirecting users to a self-service remediation portal is a common-sense improvement that a PHOSITA would readily envision to reduce administrative burden.

V. Conclusion

The independent claims of the '705 patent appear to be obvious in light of prior art available before September 27, 2004. Systems like Microsoft's NAQC, available in 2003, already taught the core concepts of receiving a connection request, making a quarantine determination, and providing limited access. The concept of a separate quarantine network for the express purpose of remediation was also well-established.

A person having ordinary skill in the art would have been motivated to combine these known elements to create a more efficient and automated system. The motivation would stem from the clear and urgent need to solve the problem of non-compliant machines connecting to a network, a problem highlighted by major worm outbreaks in 2003. The combination of an access control system that quarantines non-compliant hosts with a remediation server to fix them would have been a predictable and logical step to a PHOSITA at the time. Therefore, the independent claims of US Patent 8,234,705 are likely invalid under 35 U.S.C. § 103.

Analysis of Patent Term, Adjustments, and Family for US Patent 8,234,705

Date of Analysis: May 13, 2026

This report details the patent term adjustments, related applications, and the projected expiration date for US Patent 8,234,705.

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

A Patent Term Adjustment (PTA) can be granted to compensate for delays caused by the U.S. Patent and Trademark Office (USPTO) during the patent examination process. For US Patent 8,234,705, there is a significant patent term adjustment. The application for this patent (US 11/237,003) was filed on September 27, 2005, and the patent was granted on July 31, 2012. The lengthy prosecution period resulted in a notable adjustment. While the precise calculation of the PTA is not detailed in the available public records, the "Adjusted expiration" date is listed as November 25, 2029.

There is no indication of any Patent Term Extension (PTE) under 35 U.S.C. § 156, which is typically granted for delays in regulatory review by agencies such as the Food and Drug Administration (FDA) and is not applicable to this technology area.

Continuity and Divisional Applications:

US Patent 8,234,705, which issued from application number 11/237,003, claims priority to U.S. Provisional Patent Application No. 60/613,909, filed on September 27, 2004. There is no record of any continuation or divisional applications filed that claim priority to application number 11/237,003. Therefore, this patent does not appear to be part of a larger family of pending applications or issued patents stemming from continuation or divisional filings in the United States.

Patent Family Members:

Based on the available information, US Patent 8,234,705 does not have any direct foreign counterparts or other patent family members. The priority claim is limited to the earlier U.S. provisional application.

Projected Expiration Date:

A U.S. patent filed after June 8, 1995, generally has a term of 20 years from the earliest non-provisional filing date. The application for US Patent 8,234,705 was filed on September 27, 2005. Without any adjustments, the patent would expire on September 27, 2025.

However, due to the aforementioned patent term adjustment, the official "Adjusted expiration" date for US Patent 8,234,705 is November 25, 2029. This indicates a substantial adjustment period was granted due to delays during the patent's prosecution.

Defensive Disclosure and Prior Art Derivations for US Patent 8,234,705

This document provides a detailed technical disclosure of derivative inventions and improvements based on the core concepts described in US Patent 8,234,705. The intent of this disclosure is to place these concepts into the public domain, thereby rendering them as prior art for the purposes of patentability examination. Each concept is described with sufficient detail to be enabled by a person skilled in the art.

---

Derivations Based on Independent Claim 1: A Method for Quarantining a Host

1. Material & Component Substitution

Derivative 1.1: FPGA-Based Hardware Quarantine Enforcement

• Enabling Description: This variation replaces the general-purpose processor-based quarantine determination with a Field-Programmable Gate Array (FPGA) co-processor integrated into the network switch or gateway. The FPGA is loaded with a hardware description language (HDL) implementation of a finite state machine (FSM) that performs the quarantine logic. Upon receiving a connection request (e.g., a DHCP DISCOVER packet), the FPGA inspects the packet's MAC address against an on-chip block RAM (BRAM) containing a list of compromised or non-compliant devices. If a match is found, the FPGA directly manipulates the switch's forwarding tables to reroute all traffic from the corresponding port to a dedicated quarantine VLAN, except for traffic destined for the remediation server's MAC address. This hardware-level enforcement reduces latency from milliseconds (in a software-based system) to nanoseconds, making it suitable for line-rate enforcement in 100/400 Gbps networks. The determination of whether a host is "required to be quarantined" is offloaded to this dedicated hardware circuit, providing a deterministic, low-latency response.

• Mermaid.js Diagram:

  graph TD
      A[Host Connects: DHCP DISCOVER] --> B{FPGA Co-Processor};
      B --> C{Inspect MAC Address};
      C --> D{Lookup in On-Chip BRAM};
      D -- Match Found --> E[Reconfigure Switch Fabric];
      E --> F[Redirect Port Traffic to Quarantine VLAN];
      F --> G[Allow Traffic to Remediation Server MAC];
      D -- No Match --> H[Allow Normal Network Access];
  

---

2. Operational Parameter Expansion

Derivative 2.1: Cryogenic Datacenter Network Quarantine

• Enabling Description: This method is adapted for network hardware operating in a cryogenic environment (e.g., below 77 Kelvin) for high-performance computing or quantum computing systems. All network components, including switches and routers, are designed to operate at these temperatures. The quarantine determination process accounts for the unique physical layer characteristics, such as superconducting interconnects. The "limited access" state is defined not just by logical ports but by allocating a specific, power-limited optical wavelength to the quarantined host. The quarantine server itself is a specialized virtual machine running on a fault-tolerant quantum computer, capable of performing cryptographic analysis on the quarantined host's traffic to identify novel threats that are computationally infeasible to detect with classical computers. The remediation process involves transmitting a quantum key distribution (QKD) secured patch to the host.

• Mermaid.js Diagram:

  sequenceDiagram
      participant Host
      participant CryoSwitch
      participant QuantumQuarantineServer
      Host->>CryoSwitch: Connection Request
      CryoSwitch->>QuantumQuarantineServer: Forward Request for Analysis
      QuantumQuarantineServer-->>CryoSwitch: Quarantine Decision (True/False)
      alt Quarantine Required
          CryoSwitch->>CryoSwitch: Allocate Power-Limited Wavelength to Host Port
          Host->>CryoSwitch: Outbound Traffic (e.g., to Mainframe)
          CryoSwitch->>QuantumQuarantineServer: Redirect traffic
          QuantumQuarantineServer->>Host: Remediation Instructions via QKD
      else Not Required
          CryoSwitch->>Host: Grant Full-Spectrum Access
      end
  

Derivative 2.2: Massive-Scale IoT Swarm Quarantine

• Enabling Description: This application addresses a swarm of millions of low-power, ephemeral IoT devices (e.g., environmental sensors). A central mesh network controller receives connection requests. The "determination" is based on the collective behavior of a device's local cluster. If the aggregate data flow from a cluster of 1,000 devices deviates from a predicted model by more than a set threshold (e.g., 5 standard deviations), the entire cluster is flagged for quarantine. "Limited access" for the swarm is achieved by instructing the mesh network to refuse to route their traffic packets, except for packets directed to a specific remediation gateway that can push a signed firmware update. Non-remediation traffic is not redirected; it is simply dropped with a "route unavailable" response sent to the source node, minimizing network overhead.

• Mermaid.js Diagram:

  stateDiagram-v2
      state "Normal Operation" as Normal
      state "Quarantined" as Quarantined
      state "Under Observation" as Observation
  
      [*] --> Normal
      Normal --> Observation: Aggregate data deviates > 3σ
      Observation --> Normal: Anomaly resolves within 60s
      Observation --> Quarantined: Anomaly persists or exceeds 5σ
      Quarantined --> Normal: Signed firmware update received
      Quarantined --> Quarantined: Attempts non-remediation traffic (packets dropped)
      Normal --> Normal: Data within expected bounds
  

---

3. Cross-Domain Application

Derivative 3.1: Aerospace - In-Flight Avionics Bus Isolation

• Enabling Description: Within an aircraft's federated avionics architecture (e.g., ARINC 664), a central gateway monitors the health and data integrity of all Line-Replaceable Units (LRUs) on the network. If an LRU (e.g., a flight management system) begins transmitting data that violates the predetermined bus timing, checksum, or semantic rules, the gateway determines it must be quarantined. The "quarantine" action involves the gateway ceasing to forward packets from the faulty LRU to critical flight control systems. "Limited access" is provided by allowing the quarantined LRU to communicate only with the Onboard Maintenance System (OMS). The OMS acts as the quarantine server, logging the LRU's fault data and providing diagnostic routines, but preventing its corrupt data from affecting the autopilot or navigation systems.

• Mermaid.js Diagram:

  graph TD
      subgraph Aircraft Network
          A[Flight Management System (LRU)] -- ARINC 664 Packets --> B{Avionics Gateway};
          C[Flight Controls]
          D[Onboard Maintenance System (OMS)]
      end
  
      B -- Valid Data --> C;
      B -- Anomalous Data Detected --> E{Quarantine Decision};
      E -- Quarantine=True --> F[Isolate LRU];
      F -- Block Traffic --> C;
      F -- Allow Traffic --> D;
      A -- Non-Remediation Traffic --> B
      B -- Blocked --> C
  

Derivative 3.2: AgTech - Automated Irrigation Network Safety

• Enabling Description: In a smart farm, hundreds of wireless soil moisture sensors and valve actuators form a network. A central irrigation controller receives connection requests from these devices. If a sensor reports a value outside of physical possibility (e.g., 110% moisture) or an actuator fails to confirm its state change within a time limit, the controller determines the device must be quarantined. "Limited access" allows the device to communicate only with a diagnostic hub for recalibration or battery checks. Any commands from the quarantined device to open other valves (non-remediation traffic) are redirected to the diagnostic hub, which logs the command as an anomaly but does not execute it, preventing catastrophic flooding or crop dehydration due to a single faulty node.

• Mermaid.js Diagram:

  sequenceDiagram
      participant Sensor
      participant IrrigationController
      participant DiagnosticHub
      participant OtherValves
  
      Sensor->>IrrigationController: Report Moisture (110%)
      IrrigationController->>IrrigationController: Determination: Value is anomalous
      IrrigationController->>Sensor: Quarantine Flag Set
      Sensor->>IrrigationController: Request to Open Valve B
      IrrigationController->>DiagnosticHub: Redirected Request from Quarantined Sensor
      DiagnosticHub->>DiagnosticHub: Log Anomaly
      IrrigationController-->>OtherValves: No command forwarded
  

---

4. Integration with Emerging Tech

Derivative 4.1: AI-Driven Predictive Quarantine

• Enabling Description: The quarantine determination logic is replaced with a recurrent neural network (RNN) trained on months of baseline network traffic metadata. The RNN model is hosted on a dedicated inference server. When a host connects, its initial traffic patterns (protocol usage, packet sizes, destination entropy) are fed into the RNN. The model outputs a "probability of future compromise" score. If this score exceeds a predefined risk threshold (e.g., 0.95), the system preemptively quarantines the host, even before any malicious activity is detected. The quarantine server provides remediation by forcing the user through a multi-factor authentication challenge and a mandatory security awareness module.

• Mermaid.js Diagram:

  graph LR
      A[Host Connects] --> B[Capture Initial Traffic Metadata];
      B --> C[AI Inference Server (RNN Model)];
      C -- Metadata Vector --> D{Calculate 'Future Compromise' Score};
      D -- Score > 0.95 --> E[Quarantine Host];
      E --> F[Redirect to MFA & Training Server];
      D -- Score <= 0.95 --> G[Allow Full Access];
  

Derivative 4.2: Blockchain-Audited Quarantine Policy

• Enabling Description: The network access control policy (defining conditions for quarantine) is encoded as a smart contract on a permissioned blockchain (e.g., Hyperledger Fabric). A network gateway acts as a blockchain client. When a host requests access, the gateway queries the smart contract with the host's credentials (e.g., a signed certificate). The smart contract code executes the determination logic. If quarantine is required, the gateway executes the quarantine and writes a new transaction to the blockchain, creating an immutable, non-repudiable audit log of the event (who, what, when, why). The "quarantine server" is a decentralized application (dApp) that allows an administrator to review the audit log and push policy updates via new smart contract deployments.

• Mermaid.js Diagram:

  sequenceDiagram
      participant Host
      participant Gateway
      participant Blockchain
      participant dAppAdmin
  
      Host->>Gateway: Connection Request with Certificate
      Gateway->>Blockchain: Query SmartContract.ShouldQuarantine(HostCert)
      Blockchain-->>Gateway: Return Quarantine=True
      Gateway->>Gateway: Enforce Limited Access for Host
      Gateway->>Blockchain: Execute SmartContract.LogQuarantineEvent(Host, Reason)
      dAppAdmin->>Blockchain: View Immutable Audit Log
  

---

5. The "Inverse" or Failure Mode

Derivative 5.1: Graceful Degradation Quarantine (Fail-Safe Access)

• Enabling Description: This design prioritizes availability. If a host is determined to be quarantined, but the designated quarantine server is unreachable (e.g., due to network failure or DDoS attack), the system enters a "graceful degradation" mode instead of blocking the host completely. In this mode, the host is granted access to a highly restricted, isolated network segment with egress-only access to a predefined list of external cloud services (e.g., office productivity suites, CRMs). All peer-to-peer traffic within the local network is blocked. This allows the user to remain productive with essential cloud tools while still preventing the potential spread of a lateral-moving threat on the internal network. The system logs all traffic for later analysis when the quarantine server is restored.

• Mermaid.js Diagram:

  stateDiagram-v2
      state "Determine Quarantine" as Check
      state "Full Access" as Full
      state "Fully Quarantined" as Quarantined
      state "Degraded Access" as Degraded
  
      [*] --> Check
      Check --> Full: Host is Clean
      Check --> Quarantined: Host is Dirty AND Quarantine Server is Reachable
      Check --> Degraded: Host is Dirty AND Quarantine Server is UNREACHABLE
  
      Quarantined --> Full: Remediation Complete
      Degraded --> Quarantined: Quarantine Server becomes Reachable
      Degraded: Egress-only to cloud apps
      Degraded: All internal P2P traffic blocked
  

---

Combination Prior Art Scenarios with Open-Source Standards

1. Combination with STIX/TAXII for Threat-Intel-Based Quarantine:

   • Enabling Description: A network gateway subscribes to a threat intelligence feed from a TAXII server, receiving threat indicators in the STIX 2.1 format. The "determination of whether the host is required to be quarantined" is made by matching outbound connection requests from the host against STIX indicator objects from the feed. For example, if a host attempts a DNS lookup for a domain name matching an indicator of type domain-name associated with a known command-and-control server, the gateway immediately quarantines the host. The "quarantine server" provides the user with the specific STIX report that triggered the quarantine, offering transparency and context for the remediation.

2. Combination with RADIUS for Dynamic VLAN-Based Quarantine:

   • Enabling Description: A host connects to a network port configured for 802.1X authentication. The network switch forwards the host's credentials to a FreeRADIUS server. The FreeRADIUS server, in addition to checking credentials, queries an external asset management database to determine the host's patch level. If the host is missing critical patches, the RADIUS server's "determination" is to return a Tunnel-Private-Group-ID attribute in its Access-Accept message. The switch interprets this attribute as a VLAN ID for the designated quarantine network. All non-remediation traffic is thus isolated at Layer 2. The quarantine server is a remediation portal, and once the host is patched, it must re-authenticate, at which point the RADIUS server will return a different VLAN ID for production access.

3. Combination with Prometheus/Alertmanager for Behavior-Based Quarantine:

   • Enabling Description: Network traffic flow data is exported (e.g., via NetFlow/sFlow) to a Prometheus time-series database. A set of alerting rules in Prometheus monitors host behavior, such as rate(outbound_connections[5m]) > 100 or increase(dns_queries_to_rare_tlds[10m]) > 50. If a rule triggers, Prometheus sends an alert to Alertmanager. Alertmanager is configured with a webhook receiver that translates the alert into an API call to the network's SDN (Software-Defined Networking) controller. This API call serves as the "determination" to quarantine. The SDN controller then pushes a new flow rule to the relevant switch, redirecting the offending host's traffic (identified by its IP address in the alert payload) to the quarantine server.