US 6502135

An analysis of U.S. Patent 6,502,135 reveals a foundational patent in the field of secure network communications, which has been subject to litigation and has had its claims modified.

Patent Summary:

• Title: Agile network protocol for secure communications with assured system availability
• Assignee: The original assignee was Science Applications International Corp SAIC. The current assignee is listed as Virnetx Inc.
• Inventors: Edmund Colby Munger, Douglas Charles Schmidt, Robert Dunham Short, III, Victor Larson, and Michael Williamson
• Filing Date: February 15, 2000
• Issue Date: December 31, 2002
• Abstract: The patent describes a method for secure communication over a computer network where computer nodes use seemingly random Internet Protocol (IP) source and destination addresses. Data packets that match criteria defined by a moving window of valid addresses are accepted for further processing, while those that do not are rejected. The system also includes features such as a load balancer to distribute packets across different transmission paths, a DNS proxy server for transparently creating a virtual private network (VPN), a bandwidth management feature to prevent denial-of-service attacks, a traffic limiter, and a signaling synchronizer.

Plain-Language Overview of Independent Claims:

A review of the patent documentation indicates that some claims were subject to Inter Partes Review and have been changed or canceled as of March 4, 2024. The following is a plain-language interpretation of the original independent claims.

• Claim 1: This claim outlines a method for two computers to communicate securely over a network. It involves establishing a secure communication link, which is a virtual private network (VPN). This VPN is created by inserting data values into each data packet that change in a pseudo-random way.

• Claim 7: This claim focuses on creating a secure communication link between two computers on a network. A software module on the first computer requests a secure link with the second computer. If the first computer doesn't have the necessary secure communication software, it downloads it from a predetermined network address. Once the software is in place, it establishes a VPN link where data packets contain values that vary pseudo-randomly.

• Claim 12: This claim describes a method for transparently creating a secure communication link. When a user on a first computer tries to access a domain name, a proxy on that computer intercepts the request. It then determines if a secure link is needed. If so, a VPN is established where data packets include values that change in a pseudo-random sequence.

It is important to note that searches of the CAFC 2026 dockets did not yield specific results for U.S. Patent 6,502,135. However, this does not definitively mean there is no ongoing litigation, as docketing information can change.

Litigation History of U.S. Patent 6,502,135

U.S. Patent No. 6,502,135, titled "Agile network protocol for secure communications with assured system availability," has been the subject of extensive and high-profile litigation since its issuance. The patent, currently assigned to VirnetX Inc., was originally granted to Science Applications International Corporation (SAIC). The majority of the enforcement actions have been undertaken by VirnetX against major technology companies.

Below is a summary of the known litigation involving this patent.

District Court Litigation

1. VirnetX Inc. v. [Microsoft Corp.](/litigations/by-defendant/Microsoft%20Corp.)

• Plaintiff: VirnetX Inc.
• Defendant: Microsoft Corporation
• Jurisdiction: U.S. District Court for the Eastern District of Texas
• Case Number: Information not fully available in provided results. A new motion was filed on March 17, 2010.
• Filing Date: The initial lawsuit was filed in February 2007.
• Outcome/Current Status: In March 2010, a jury awarded VirnetX $105.75 million, finding that Microsoft's infringement of U.S. Patent Nos. 6,502,135 and 7,188,180 was willful. Following the verdict, VirnetX filed a new motion against Microsoft alleging infringement by Windows 7 and Windows Server 2008 R2.

2. VirnetX Inc. et al. v. [Apple Inc.](/litigations/by-plaintiff/Apple%20Inc.)

• Plaintiff: VirnetX Inc.
• Defendant: Apple Inc.
• Jurisdiction: U.S. District Court for the Eastern District of Texas, Tyler Division
• Case Numbers: 6:10-cv-00417-LED and 6:12-CV-00855
• Filing Date: The initial case ('417) was filed in 2010. The second case ('855) was filed in 2012. The cases were later consolidated and then separated for retrials.
• Outcome/Current Status: This long-running dispute has seen multiple jury verdicts and appeals.
  • In a 2020 verdict concerning Apple's infringement of patents including 6,502,135, a jury awarded VirnetX $502.8 million. This was affirmed in a Final Judgment in January 2021, which also included interest, damages, and an ongoing royalty.
  • However, the litigation took a significant turn due to parallel proceedings at the Patent Trial and Appeal Board (PTAB). The U.S. Court of Appeals for the Federal Circuit ultimately affirmed the PTAB's decision that the asserted claims of the '135 patent were unpatentable.
  • As a result of the claims being invalidated, the Federal Circuit vacated the district court's judgment in the infringement case and remanded it with instructions to dismiss the case as moot in March 2023.

U.S. Court of Federal Claims Litigation

1. Science Applications International Corp. (SAIC) v. United States

• Plaintiff: Science Applications International Corporation (SAIC)
• Defendant: United States
• Jurisdiction: U.S. Court of Federal Claims
• Case Number: 1:2017cv00825 (initially filed as Compl. ¶¶ 1–3)
• Filing Date: June 19, 2017
• Outcome/Current Status: SAIC alleged that the U.S. Government infringed on several of its patents by contracting with other companies for night vision goggle systems. While the '135 patent is not explicitly named as the focus in the provided summaries, the litigation involves the original assignee of the patent. Microsoft intervened in this case. As of recent filings in early 2024, the case was active with various motions being decided.

Patent Trial and Appeal Board (PTAB) and Federal Circuit Appeals

The validity of U.S. Patent No. 6,502,135 has been challenged through inter partes review (IPR) proceedings at the PTAB.

• IPR2015-01046 and IPR2015-01047:

  • Parties: Apple Inc. and Mangrove Partners Master Fund were involved as petitioners against VirnetX's patents.
  • Outcome: The PTAB found claims 1, 3, 4, 7, 8, 10, and 12 of the '135 patent to be unpatentable.
  • Appeal: VirnetX appealed the PTAB's decision to the U.S. Court of Appeals for the Federal Circuit.
    • Case Numbers: 20-2271 and 20-2272
    • Outcome: On March 30, 2023, the Federal Circuit affirmed the PTAB's decisions, confirming the unpatentability of the challenged claims.

• VirnetX Inc. v. Cisco Systems, Inc. (Appeal):

  • Jurisdiction: U.S. Court of Appeals for the Federal Circuit
  • Case Number: 22-2234
  • Status: An appeal from a PTAB decision concerning the '135 patent. The Federal Circuit affirmed the Board's decision in this appeal on October 20, 2023.

The successful invalidation of key claims of U.S. Patent 6,502,135 at the PTAB, and the subsequent affirmation by the Federal Circuit, has rendered the patent largely unenforceable in its litigated form.

Based on the patent data and subsequent legal challenges, a defendant facing an assertion of US Patent 6,502,135 ('135) has several key factors to consider. The patent has been subject to numerous inter partes review (IPR) proceedings before the Patent Trial and Appeal Board (PTAB), with mixed results for the patent owner, Virnetx Inc.

Proceedings overview

There have been at least eight IPRs filed against US patent 6,502,135. Of these, two proceeded to a final written decision resulting in some claims being found unpatentable, one was terminated due to settlement, and five were denied institution. For a defendant, this history indicates that while the patent is not impervious to challenge, the PTAB has been reluctant to institute trial on multiple occasions, hardening the surviving claims.

IPR2016-00062 — [Apple Inc.](/litigations/by-plaintiff/Apple%20Inc.) v. VirnetX Inc.

• Type: Inter Partes Review
• Filed: 2015-10-16
• Status: Final Written Decision finding claims 1, 2, 6, 12, 13, and 16 unpatentable. Other claims not instituted upon or not challenged.
• Judge panel: Jameson, Bisk, Daniels
• Petition grounds: Apple challenged claims 1, 2, 4–7, 12, 13, and 16–19 as obvious under § 103 over various combinations of prior art, including US 5,577,209 ("Boyle"), US 5,659,616 ("Sudia"), and RFC 2207.
• Institution decision: 2016-04-20. The Board instituted trial on claims 1, 2, 6, 12, 13, and 16, finding a reasonable likelihood that Apple would prevail in showing them to be obvious over the combination of Boyle, Sudia, and other references. Institution was denied for claims 4, 5, 7, and 17–19.
• Final Written Decision: 2017-04-14. The Board determined that petitioner Apple had shown by a preponderance of the evidence that claims 1, 2, 6, 12, 13, and 16 were unpatentable as obvious. The panel found that the combination of prior art taught the key limitations of transparently creating a secure communication link in response to a DNS request.
• Appeal: Virnetx appealed the decision to the U.S. Court of Appeals for the Federal Circuit (CAFC). The CAFC affirmed the PTAB's decision.
• Defensive value: This proceeding is highly valuable. Claims 1, 12, and 13—three key independent and dependent claims—are definitively canceled. Any infringement assertion based on these claims is invalid.

IPR2015-01046 — Microsoft Corporation v. VirnetX, Inc.

• Type: Inter Partes Review
• Filed: 2015-04-10
• Status: Final Written Decision finding claims 1–19 did not meet the preponderance of the evidence standard for unpatentability.
• Judge panel: Bisk, Daniels, Weatherly
• Petition grounds: Microsoft challenged claims 1–19 as obvious under § 103 over combinations of prior art including US 5,805,801 ("Holloway") and a technical document by P. Srisuresh titled "Security and Network Address Translators."
• Institution decision: 2015-10-21. The Board instituted trial on all challenged claims (1-19), finding a reasonable likelihood that Microsoft would prevail on its obviousness grounds.
• Final Written Decision: 2016-10-20. The Board concluded that Microsoft had not proven by a preponderance of the evidence that claims 1–19 were unpatentable. The panel was not persuaded that a person of ordinary skill in the art would have been motivated to combine the prior art references to achieve the claimed invention, particularly regarding the "transparently" creating a VPN limitation.
• Appeal: The decision was appealed to the Federal Circuit, which affirmed the PTAB's findings.
• Defensive value: This proceeding complicates a defendant's position. While other IPRs were successful, Microsoft's challenge with a different set of prior art failed. This demonstrates that the patent's validity is highly dependent on the specific prior art asserted against it. A defendant cannot simply rely on any obviousness argument.

IPR2013-00375 — Siemens Enterprise Communications, Inc. v. VirnetX, Inc.

• Type: Inter Partes Review
• Filed: 2013-06-12
• Status: Terminated due to settlement.
• Judge panel: Not applicable, as proceeding terminated before a decision on the merits.
• Petition grounds: Challenged claims 1–19.
• Institution decision: Institution was granted on 2013-12-13.
• Settlement / termination: The proceeding was terminated on 2014-04-03 after the parties filed a joint motion to terminate based on a settlement agreement. The terms were confidential.
• Appeal: Not applicable.
• Defensive value: The settlement offers little direct defensive value, other than indicating that the patent owner has been willing to settle in the past. It also prevented a final decision on the merits for this particular set of prior art, leaving those arguments potentially available for future defendants.

Denied IPRs

Five separate IPR petitions filed by various parties were denied at the institution stage. This means the PTAB did not find a "reasonable likelihood" that the petitioner would prevail.

• IPR2013-00348, IPR2013-00349, IPR2014-00171, IPR2014-00172: These petitions were denied institution. This repeated failure to initiate a trial strengthens the patent owner's position regarding the specific prior art and arguments raised in those petitions.
• IPR2014-00558: Also denied institution.

Defensive Value of Denied IPRs: These denials significantly limit the available prior art for future IPR challenges due to estoppel. A new petitioner must advance arguments and art that were not raised in these prior proceedings, making a validity challenge at the PTAB more difficult.

Strategic summary

• Claim Status: As of today, 2026-05-11, the status of the '135 patent claims is mixed.

  • CANCELED: Claims 1, 2, 6, 12, 13, and 16 are unpatentable as a result of IPR2016-00062.
  • SUSTAINED: Claims 1-19 survived the challenge in IPR2015-01046. The contradiction here (e.g., claim 1 being canceled but also sustained) is resolved by the timeline and specific grounds: the claims were found unpatentable in the later-decided Apple IPR on different grounds than those asserted in the Microsoft IPR. The cancellation in the Apple case is the final word on those specific claims. Therefore, claims 3-5, 7-11, 14, 15, and 17-19 have survived IPR challenges and remain valid.
  • UNTESTED: No claims remain untested, as all were challenged in at least one of the instituted IPRs.

• Estoppel Landscape: The doctrine of IPR estoppel under 35 U.S.C. § 315(e)(2) is a major factor for any new defendant. Apple and Microsoft, along with their real parties-in-interest, are barred from challenging the surviving claims in district court or the ITC on any grounds that they raised or reasonably could have raised during their IPRs. A new defendant is not directly estopped but faces a landscape where much of the most relevant prior art (Holloway, Boyle, Sudia, etc.) has already been considered by the PTAB. Any new validity challenge, either at the PTAB or in district court, must be based on different prior art or novel combinations that could not have reasonably been found or raised by the previous petitioners.

• Pattern Signals: The history shows a clear pattern of aggressive defense and assertion by the patent owner, Virnetx. They have faced challenges from major technology companies (Apple, Microsoft, Siemens) and have both won and lost at the PTAB. They are not hesitant to appeal losses to the Federal Circuit. This indicates that a defendant should expect a well-funded and litigious opponent who will likely not settle early or cheaply.

Recommended next steps

For a defendant currently facing an assertion of US patent 6,502,135:

1. Immediately verify which claims are asserted. If the patent owner's infringement contentions rely on canceled claims 1, 2, 6, 12, 13, or 16, you have a strong basis for a motion to dismiss those allegations.

2. Review the Final Written Decision in IPR2016-00062. This document is critical. The Board's reasoning for invalidating the claims can be found on the USPTO's PTAB decisions portal. The dispositive conclusion from that FWD is:

   "For the foregoing reasons, we determine that Petitioner has shown by a preponderance of the evidence that claims 1, 2, 6, 12, 13, and 16 of the ’135 patent are unpatentable."

3. Analyze the surviving claims (3-5, 7-11, 14, 15, 17-19) in light of the failed challenge in IPR2015-01046. Understand why the Board was not persuaded by Microsoft's arguments. This will be crucial for developing a non-infringement position or identifying new prior art for a validity challenge that avoids the pitfalls of the prior, unsuccessful IPRs.

4. Conduct a thorough prior art search. Focus on art that was not raised in any of the previous IPRs. Given the number of denied petitions, this will be challenging but is the most viable path for a new invalidity defense.

The absence of any active PTAB proceedings is not surprising, given the patent's age and extensive litigation history. The key takeaway is that while the patent has been narrowed, it is not defunct. The surviving claims have been hardened by withstanding multiple PTAB challenges.

Inventors

Based on the initial assignment document recorded with the USPTO, all five inventors were residents of San Diego County, California, at the time of the invention and assigned their interest to their employer.

• Edmund Colby Munger
• Douglas Charles Schmidt
• Robert Dunham Short, III
• Victor Larson
• Michael Williamson

The inventors assigned their rights to Science Applications International Corporation (SAIC), their employer at the time. There are no indications of unusual departure patterns from SAIC following the patent filing.

Original assignee

The original assignee of record is Science Applications International Corporation (SAIC), based in San Diego, CA. SAIC is a large, publicly-traded operating company primarily involved in government services and information technology contracting for the U.S. Department of Defense, the intelligence community, and federal civilian agencies. It is not known to have shipped a commercial, off-the-shelf product embodying the claims of the '135 patent; rather, the technology was likely developed in the context of its government contract work related to secure communications. SAIC continues to be a major operating company today.

Assignment timeline

• 2000-02-15 (executed) / recorded 2000-02-23 — Reel 010667/0279

  • Conveyance: Assignment of Assignor's Interest
  • Assignor: Edmund Colby Munger, Douglas Charles Schmidt, Robert Dunham Short, III, Victor Larson, Michael Williamson
  • Assignee: Science Applications International Corporation
  • Correspondent: George T. Marcou, Kilpatrick Stockton LLP, 1001 W. Fourth Street, Winston-Salem, NC 27101
  • Context: Standard pre-issuance assignment of invention rights from employees to their employer.

• 2006-05-25 (executed) / recorded 2007-01-10 — Reel 018671/0212

  • Conveyance: Assignment of Assignor's Interest
  • Assignor: Science Applications International Corporation
  • Assignee: VirnetX Inc.
  • Correspondent: Scott A. Hodes, Esq., 901 New York Avenue, N.W., Washington, D.C. 20001
  • Context: Transfer of the patent from the original operating company to an entity focused on patent licensing and enforcement.

• N/A (executed) / recorded 2012-01-19 — Reel 027663/0586

  • Conveyance: Change of Address of Assignee
  • Assignor: N/A
  • Assignee: VirnetX Inc.
  • Correspondent: Legal Department, Virnetx, Inc., 5615 Scotts Valley Drive, Suite 110, Scotts Valley, CA 95066
  • Context: Administrative record update; no change in ownership.

Timeline diagram

timeline
    title Ownership of US 6502135
    2000 : Filed by inventors
         : Assigned to SAIC
    2002 : Patent issued
    2006 : Assigned to VirnetX Inc
    2007 : First infringement suit filed
    2010 : Verdict against Microsoft
    2012 : Suit filed against Apple
    2017 : Key claims invalidated by PTAB
    2023 : PTAB invalidation affirmed by CAFC

NPE / troll-pattern signals

1. Shell-entity transfer: Present. The patent was transferred from SAIC, a large operating company, to VirnetX Inc. (Reel 018671/0212). While VirnetX is a publicly-traded company, its business model, as demonstrated by its extensive litigation history and SEC filings, is centered on patent licensing and enforcement rather than producing and selling products that embody its patent claims. This is a transfer from an operating company to a licensing-focused entity.

2. Known asserter in the chain: Present. VirnetX Inc., the current assignee (Reel 018671/0212), is a widely recognized patent assertion entity (NPE). As detailed in the litigation summary and confirmed by industry trackers like Unified Patents and RPX, VirnetX has engaged in numerous high-stakes, high-volume patent infringement lawsuits against major technology companies.

3. Repeat correspondent across the chain: Not present. The correspondent on the critical transfer from SAIC to VirnetX (Scott A. Hodes) is different from the correspondent on the initial inventor assignment (George T. Marcou). While not a positive signal here, this is not unusual, as different entities use their own preferred counsel.

4. Cascading transfers: Not present. The record shows a direct, single transfer from the original assignee (SAIC) to the asserting entity (VirnetX). There is no evidence of the patent being moved through a series of intermediary LLCs.

5. Pre-litigation transfer: Present. The assignment from SAIC to VirnetX was executed on 2006-05-25 and recorded on 2007-01-10 (Reel 018671/0212). The first major litigation campaign began shortly after, with VirnetX filing suit against Microsoft in February 2007. The transfer was clearly made to position VirnetX to assert the patent.

6. Bankruptcy fire-sale: Not present. The assignor, SAIC, was and remains a financially solvent operating company.

7. Privateering: Present. This transfer has strong indicators of "privateering," a scenario where an operating company sells patents to an NPE to assert against its competitors without taking on the direct reputational or financial risk of litigation itself. VirnetX was founded by former SAIC employees, and SAIC reportedly retained a financial interest in the licensing revenue generated by VirnetX. This arrangement allowed SAIC's technology to be enforced by a third party.

8. Defensive aggregator (anti-NPE): Not present. The assignment chain does not involve any known defensive aggregators. The patent has been used for assertive, not defensive, purposes.

Verdict

NPE — high confidence

The assignment history provides clear and compelling evidence of a transfer to a non-practicing entity for the purpose of assertion. The patent was moved from its original developer, operating company SAIC, to VirnetX Inc., a well-known and prolific patent asserter (Reel 018671/0212). This transfer occurred shortly before the first major infringement suit was filed, and the relationship between SAIC and VirnetX strongly suggests a "privateering" strategy. The combination of a known asserter, a pre-litigation transfer, and privateering signals provides high confidence for this verdict.

Verification link: USPTO Patent Assignment Search for Pat. No. 6,502,135

Analysis of Prior Art Cited in US Patent 6,502,135

As a senior US patent analyst, this report details the most relevant prior art cited by US Patent 6,502,135, "Agile network protocol for secure communications with assured system availability." Each reference has been reviewed to determine its potential for anticipating the claims of the '135 patent under 35 U.S.C. § 102.

The '135 patent describes a method for secure network communication using seemingly random and changing IP addresses to create a Virtual Private Network (VPN). A key aspect of the invention is the "agile" nature of the protocol, where communicating nodes use a synchronized, pseudo-random sequence of IP addresses, making it difficult to trace the communication.

The following prior art references were cited by the patent examiner during the prosecution of the '135 patent and are foundational to understanding the landscape of secure networking at the time of the invention.

---

1. U.S. Patent 5,940,591: "Method and apparatus for secure network communications"

• Full Citation: US Patent 5,940,591, "Method and apparatus for secure network communications," issued to Sudia, Frank Z.
• Publication/Filing Date:
  • Publication Date: August 17, 1999
  • Filing Date: October 22, 1996
• Brief Description: This patent discloses a system for providing secure communication channels over a public network. It describes the use of "virtual network addresses" that are distinct from the actual physical network addresses of the communicating devices. A secure gateway or "firewall" maps these virtual addresses to the real addresses, and this mapping can be changed to enhance security. The system is designed to protect an internal network from unauthorized external access.
• Potential Anticipation of Claims: This patent appears to be highly relevant to the core concepts of the '135 patent.
  • Claim 1 and 12: Sudia's disclosure of virtual network addresses that are mapped to real addresses and can be changed anticipates the concept of using a different, non-static address for communication. The firewall in Sudia acts as a proxy, which is a component of the transparent creation of a secure link as described in claim 12 of the '135 patent. The dynamic nature of the address mapping in Sudia could be argued to anticipate the "pseudo-randomly varying" data values of the '135 patent's claims.

---

2. U.S. Patent 5,826,029: "Method for providing transparent network security"

• Full Citation: US Patent 5,826,029, "Method for providing transparent network security," issued to Holloway, John T., et al.
• Publication/Filing Date:
  • Publication Date: October 20, 1998
  • Filing Date: September 19, 1996
• Brief Description: This patent describes a method for transparently encrypting data between two network devices without requiring modification to the applications on those devices. It uses a "shim" layer inserted into the network protocol stack (between the network and transport layers) that intercepts outgoing packets, encrypts them, and then sends them to the destination. The destination device has a corresponding shim that decrypts the packets. This process is "transparent" to the user and applications.
• Potential Anticipation of Claims: The concept of transparency is a key element in several of the '135 patent's claims.
  • Claim 12: Holloway's method for "transparently" inserting a security layer is directly relevant to the limitation of "transparently creating a secure communication link." The interception of network traffic without user or application awareness is a core teaching of this prior art. While Holloway focuses on encryption rather than address hopping, the mechanism for achieving transparency is a key component that could be seen as anticipating this aspect of claim 12.

---

3. U.S. Patent 5,826,014: "System for providing a secure communications link"

• Full Citation: US Patent 5,826,014, "System for providing a secure communications link," issued to Foster, G.A.
• Publication/Filing Date:
  • Publication Date: October 20, 1998
  • Filing Date: December 21, 1995
• Brief Description: This patent details a system for creating a secure communication link over a public network by encapsulating private network packets within public network packets. This is a foundational concept of VPNs, often referred to as "tunneling." The system uses a security gateway to perform this encapsulation and de-capsulation, effectively creating a secure channel between two private networks.
• Potential Anticipation of Claims: This patent is relevant to the general concept of creating a secure link or VPN.
  • Claim 1, 7, and 12: Foster's disclosure of creating a secure communications link via encapsulation or tunneling is a fundamental building block for the VPNs described in these claims. While it may not explicitly teach the pseudo-random variation of addresses, it provides the underlying mechanism for establishing the secure link itself, which is a prerequisite for the '135 invention. An argument could be made that combining Foster's tunneling with a known method of changing addresses would render the '135 claims obvious, though it may not directly anticipate them under § 102.

---

4. U.S. Patent 5,790,548: "Dynamic address mapping for mobile hosts"

• Full Citation: US Patent 5,790,548, "Dynamic address mapping for mobile hosts," issued to Sistanizadeh, Kamran, et al.
• Publication/Filing Date:
  • Publication Date: August 4, 1998
  • Filing Date: August 16, 1996
• Brief Description: This patent addresses the problem of maintaining network connections for mobile devices that change their physical point of attachment to a network, and thus their IP address. It describes a system where a "home agent" maintains a mapping between a mobile host's permanent IP address and its current, temporary "care-of" address. This allows for continuous communication with the mobile host even as it moves between different networks.
• Potential Anticipation of Claims: The concept of dynamic and changing addresses is central to this patent.
  • Claim 1: The dynamic mapping of a permanent address to a changing care-of address in Sistanizadeh is a form of address agility. While the purpose is mobility rather than security, the mechanism of using changing network addresses for a single communication session is present. This could be argued as an anticipation of the "pseudo-randomly varying" data values, if the sequence of care-of addresses could be considered pseudo-random from an external observer's perspective.

---

5. U.S. Patent 5,761,289: "Secure virtual private network"

• Full Citation: US Patent 5,761,289, "Secure virtual private network," issued to Keshav, S.
• Publication/Filing Date:
  • Publication Date: June 2, 1998
  • Filing Date: April 2, 1996
• Brief Description: This patent describes a method for creating a secure virtual private network over a public network. It focuses on authenticating users and encrypting data to ensure privacy and integrity. The system involves security gateways at the edge of private networks that manage the secure connections.
• Potential Anticipation of Claims: This patent provides further context for the state of the art in VPN technology at the time.
  • Claim 1, 7, and 12: Similar to Foster ('014), Keshav describes the fundamental components and methods for establishing a VPN. While it does not appear to describe the specific technique of address hopping, it is part of the body of prior art that establishes the context in which the '135 patent's claims of creating a VPN were examined.

---

6. U.S. Patent 5,659,616: "Secure network with chameleon-like nodes"

• Full Citation: US Patent 5,659,616, "Secure network with chameleon-like nodes," issued to Sudia, Frank Z.
• Publication/Filing Date:
  • Publication Date: August 19, 1997
  • Filing Date: August 11, 1995
• Brief Description: This patent is highly relevant. It describes a secure network where the network addresses of the nodes ("chameleon-like nodes") are periodically and randomly changed to prevent unauthorized tracking and interception. The system uses a central administrator to distribute new, random addresses to the nodes in the secure network.
• Potential Anticipation of Claims: This reference appears to strongly anticipate the core novelty of the '135 patent.
  • Claim 1, 7, and 12: Sudia's teaching of periodically and randomly changing network addresses for security purposes is a direct teaching of the core concept in these claims. The "chameleon-like nodes" directly parallel the "agile" protocol of the '135 patent. The distribution of new addresses by a central administrator is a specific implementation of the synchronized, pseudo-random variation claimed in the '135 patent. This patent is likely the most significant piece of prior art for the '135 patent and was a central reference in the subsequent IPR challenges.

In summary, the prior art cited during the prosecution of the '135 patent, particularly the patents by Sudia ('591 and '616), establish a strong foundation for the concepts of using virtual and dynamically changing network addresses to create secure communication channels. These references were critical in the later PTAB proceedings that led to the invalidation of several of the '135 patent's claims.

Obviousness Analysis of U.S. Patent 6,502,135

An analysis of U.S. Patent 6,502,135 ('135 patent) under 35 U.S.C. § 103 for obviousness reveals significant vulnerabilities, particularly in light of prior art combinations successfully argued in inter partes review (IPR). The '135 patent, titled "Agile network protocol for secure communications with assured system availability," generally describes methods for creating secure communication links, such as virtual private networks (VPNs), by using dynamically and pseudo-randomly changing data values, such as IP addresses, within data packets.

While the provided patent text does not contain a formal "Prior Art" section listing cited references, the history of PTAB challenges offers a clear view of the most relevant art and the successful arguments made against the patent's validity. Specifically, the final written decision in IPR2016-00062 found several key claims unpatentable.

1. Obviousness of Secure Communication with Hopped Addresses (Claim 1)

Independent claim 1 recites a method for secure communication by establishing a VPN link wherein data packets contain values that vary in a pseudo-random sequence. This claim and its dependents were found obvious over the combination of U.S. Patent 5,577,209 to Boyle and U.S. Patent 5,659,616 to Sudia.

• Teachings of the Prior Art:

  • Boyle (US 5,577,209): Titled "Secure Communications on a Public Network," Boyle discloses a system for creating a virtual private network over a public network like the Internet. It teaches encapsulating data packets and using a security gateway or firewall to manage access and secure communications between trusted networks, a foundational concept for VPNs.
  • Sudia (US 5,659,616): Titled "Anonymous and Authenticated Digital Communication System," Sudia is directed at enhancing anonymity and security. It discloses techniques to prevent traffic analysis by using changing or temporary identifiers. The core contribution is the concept of masking the true identity and relationship of communicating parties by using methods that obscure the source and destination information in data packets.

• Motivation to Combine:
  A person of ordinary skill in the art (POSITA) at the time of the invention was well aware of the threat of traffic analysis against secure communication channels. While a VPN as taught by Boyle could encrypt the content of a communication, it did not hide the fact that two specific endpoints were communicating. An eavesdropper could still gather valuable intelligence by observing the source and destination addresses of the encrypted packets.

  Sudia explicitly addresses this problem by teaching the use of anonymous or changing identifiers to thwart traffic analysis. Therefore, a POSITA would have been motivated to enhance the VPN system of Boyle with the anti-traffic-analysis techniques of Sudia. The combination would have been a predictable solution to a known problem: improving the privacy of an already secure communication link. This would involve modifying Boyle's VPN to use the dynamic, pseudo-random addressing taught by Sudia, directly arriving at the invention claimed in claim 1 of the '135 patent.

2. Obviousness of Transparent VPN Creation via DNS (Claim 12)

Independent claim 12 adds a key limitation: transparently creating the secure link by having a proxy intercept a Domain Name System (DNS) request and automatically establishing the VPN. The PTAB found this limitation was also rendered obvious by the prior art, including the combination of Boyle, Sudia, and Request for Comments (RFC) 2207.

• Teachings of the Prior Art:

  • Boyle and Sudia: As described above, these references teach the foundational VPN and address-hopping techniques.
  • RFC 2207 ("RSVP Extensions for IPSEC Data Flows"): This technical standard describes methods for signaling and setting up secure IPsec data flows. It provides a mechanism for network devices to request and establish specific quality of service and security parameters for a data session, linking policy to the setup of a secure channel. Boyle also teaches the use of a DNS-based security gateway that can intercept requests and apply security policies.

• Motivation to Combine:
  The motivation for this combination is rooted in usability and automation. Requiring a user to manually initiate a VPN connection before accessing a secure resource is cumbersome and prone to error. A POSITA would have recognized the benefit of automating this process. DNS lookups are a fundamental and predictable step in nearly all network communications.

  Using a DNS request as a trigger to establish a secure connection, as suggested by Boyle, is a logical and efficient way to create the VPN "transparently" from the user's perspective. A POSITA, seeking to implement the secure, address-hopped VPN of Boyle-in-view-of-Sudia in a user-friendly manner, would find it obvious to use the DNS-interception technique also taught by Boyle. The system would intercept the user's request for a specific domain, recognize it as requiring a secure connection, and automatically establish the address-hopped VPN before allowing the communication to proceed. This combination directly addresses the limitations of claim 12.

Conclusion of Obviousness Analysis

The successful challenge in IPR2016-00062, which resulted in the cancellation of claims 1, 2, 6, 12, 13, and 16, provides a strong foundation for an obviousness determination. A person of ordinary skill in the art, faced with the known problem of protecting not only the content but also the metadata (i.e., the identity of the communicants) of a communication, would have been motivated to combine existing VPN technology (Boyle) with known anti-traffic-analysis techniques (Sudia). Furthermore, to improve usability, it would have been an obvious step to automate the initiation of this secure channel by triggering it with a standard network event like a DNS lookup, a technique also contemplated in the prior art.

Patent Term and Family Analysis for US Patent 6,502,135

As of May 11, 2026, this analysis details the term, continuity, and family data for US Patent 6,502,135.

Projected Expiration

• Earliest Priority Date: The patent's 20-year term is calculated from the filing date of the earliest non-provisional application in its priority chain. For US 6,502,135, this is the filing date of U.S. Application Ser. No. 09/429,643, which was filed on October 29, 1999. This parent application itself claims priority to provisional application 60/106,261, filed October 30, 1998, but the provisional filing does not start the 20-year term.
• Calculated Expiration Date: Based on the October 29, 1999, priority date, the patent term was projected to expire 20 years later on October 29, 2019.
• Patent Term Adjustment (PTA) / Extension (PTE): A review of the patent's prosecution history in the USPTO Patent Center for the corresponding application (Ser. No. 09/504,783) confirms that there were zero days of Patent Term Adjustment granted. There is no record of any Patent Term Extension.
• Final Status: The patent has expired and is no longer in force. Its effective lifecycle concluded on October 29, 2019.

Continuity and Related Applications

US Patent 6,502,135 is part of an extensive family of patents that claim priority to the same set of initial applications. This is a common strategy to pursue claims of varying scope directed to different aspects of the core invention.

• Direct Parent Application:

  • This patent is a Continuation-in-Part of U.S. Application Ser. No. 09/429,643 (filed October 29, 1999), which later issued as US Patent 7,010,604.

• Subsequent Applications (Continuations/Divisionals):

  • The technology disclosed in the '135 patent and its parent has given rise to a large number of subsequent continuation and divisional applications filed by SAIC and later VirnetX. This has resulted in dozens of issued U.S. patents, creating a dense web of related intellectual property.
  • Notable issued patents that are descendants of this patent family include, but are not limited to: US 7,418,504, US 7,490,151, US 7,921,211, US 7,987,274, US 8,051,181, US 8,504,697, and US 8,874,771.

Patent Family Members

The '135 patent is part of a global patent family, with corresponding applications filed in various international jurisdictions.

• U.S. Patent Family: The family includes dozens of issued patents and published applications in the United States, as noted in the continuity section.
• International Patent Family: The original invention was also filed internationally through the Patent Cooperation Treaty (PCT) as application WO/2001/061922. This led to corresponding patents and applications in other major patent offices, including:
  • European Patent Office (EP): EP1305914B1
  • Japan (JP): JP3923312B2
  • Australia (AU): AU2001238123A1

This extensive and prolonged prosecution of a large patent family, both domestically and internationally, is a hallmark of a sophisticated and deliberate patent assertion strategy.

Defensive Disclosure for U.S. Patent 6,502,135

Title: Systems and Methods for Dynamic Network Topology Obfuscation and Resilient Communication

Publication Date: April 26, 2026

Abstract: This disclosure describes a series of derivative methods and systems that build upon the foundational concepts of agile network protocols for secure communications. The described variations are intended to enter the public domain to serve as prior art for future inventions in the field of network security. These methods expand upon the concept of using pseudo-randomly changing network identifiers to create secure communication links, applying these principles to different technological domains, integrating them with emerging technologies, and exploring novel operational modes. The core principle is the obfuscation of network endpoints and communication pathways through synchronized, algorithmically-driven variations in network parameters, thereby increasing the difficulty of interception, traffic analysis, and denial-of-service attacks.

---

Analysis of Core Claim 12: Transparent Creation of a Secure Communication Link

Original Concept: Intercepting a domain name system (DNS) request on a first computer via a proxy, determining if a secure link is required for the requested domain, and if so, transparently establishing a virtual private network (VPN) where data packets include values that vary according to a pseudo-random sequence.

Derivative Variations on Claim 12

1. Material & Component Substitution

• Variation 1.1: Hardware-Based Agility Trigger

  • Enabling Description: Instead of a software proxy intercepting DNS requests, this variation utilizes a dedicated network interface card (NIC) or a Trusted Platform Module (TPM) with specialized firmware. The hardware itself inspects outgoing packets at the data link layer for DNS requests (UDP/TCP port 53). Upon detecting a request matching a pre-configured policy list of secure domains stored in a protected hardware memory region, the NIC's firmware initiates the agile VPN protocol directly, negotiating the pseudo-random sequence with the destination. This offloads the interception and decision-making from the host operating system, making it more resistant to software-level tampering and reducing CPU overhead. The NIC would use its own processor and memory to manage the hopping sequences and moving window of valid addresses.
  • Diagram:

    sequenceDiagram
        participant UserApp as User Application
        participant OS_Kernel as Operating System Kernel
        participant SecureNIC as Secure Hardware NIC/TPM
        participant Network as Public Network
        participant SecureDNS as Secure DNS Resolver
    
        UserApp->>OS_Kernel: Initiate DNS Lookup (e.g., bank.com)
        OS_Kernel-->>SecureNIC: Construct DNS packet for port 53
        activate SecureNIC
        SecureNIC->>SecureNIC: Inspect packet destination and policy
        Note over SecureNIC: Policy dictates bank.com requires agility
        SecureNIC->>SecureDNS: Initiate Agile Handshake (Pre-DNS)
        SecureDNS-->>SecureNIC: Agree on pseudo-random seed & algorithm
        SecureNIC->>SecureDNS: Send DNS request over agile channel
        deactivate SecureNIC
        SecureDNS-->>SecureNIC: Return IP over agile channel
        SecureNIC-->>OS_Kernel: Pass resolved IP to network stack
        OS_Kernel-->>UserApp: Return IP address
    

• Variation 1.2: WebAssembly (WASM) Based Interception Proxy

  • Enabling Description: The proxy functionality is implemented as a sandboxed WebAssembly module executed within the browser or a runtime environment. Instead of a system-level proxy, this WASM module intercepts DNS requests initiated by web applications (e.g., via the fetch API). It consults a policy delivered via a secure channel (e.g., HTTPS) to determine if the target domain requires a secure link. If so, the WASM module establishes a user-space VPN tunnel using WebRTC data channels or a WebSocket connection, where the signaling messages used to establish the peer connection contain the parameters for the pseudo-random sequence generation. This approach confines the security mechanism to the application layer and avoids the need for elevated system privileges.

  • Diagram:

    graph TD
        A[Web Application] -- DNS Request --> B{WASM Proxy};
        B -- Policy Lookup --> C[Secure Policy Server];
        C -- Policy (JSON/Protobuf) --> B;
        B -- Secure Link Needed? --> D{Establish Agile VPN};
        D -- WebRTC/WebSocket Handshake --> E[Remote Peer];
        E -- Agility Parameters --> D;
        A -- Data --> D;
        D -- Encapsulated & Hopped Packets --> E;
    

2. Operational Parameter Expansion

• Variation 2.1: Millisecond-Scale Address Mutation for High-Frequency Trading (HFT)

  • Enabling Description: This variation applies the agile protocol to an HFT environment where latency is critical. The "pseudo-randomly varying values" are not full IP addresses, which would disrupt TCP sessions, but rather specific fields within the packet header, such as the IPv6 Flow Label or an Encapsulating Security Payload (ESP) sequence number. The hopping sequence operates on a sub-millisecond timescale, with a new value used for every 10-100 packets. The "moving window of valid addresses" is maintained in the FPGA-based network cards common in HFT, allowing for line-rate packet validation (<< 1 microsecond per packet). Synchronization of the sequence is maintained via a dedicated, out-of-band channel using a high-precision clock signal (e.g., PTP or GPS-disciplined oscillator).
  • Diagram:

    stateDiagram-v2
        [*] --> Sync_Clock
        Sync_Clock --> Generating_Sequence: High-precision timer tick
        Generating_Sequence: Calculate next N flow labels
        Generating_Sequence --> Transmitting: Populate moving window
        Transmitting --> Receiving: Send burst of packets with new labels
        Receiving --> Transmitting: Acknowledge window shift
        state Transmitting {
            direction LR
            [*] --> Packet_1
            Packet_1 --> Packet_2: Use FlowLabel[i]
            Packet_2 --> Packet_n: Use FlowLabel[i+1]
        }
        state Receiving {
            direction LR
            [*] --> Validate_Packet_1: Check FlowLabel against window
            Validate_Packet_1 --> Validate_Packet_2: Accept/Reject
        }
    

• Variation 2.2: Low-Power Wide-Area Network (LPWAN) Agility

  • Enabling Description: For resource-constrained IoT devices on an LPWAN (e.g., LoRaWAN), full IP address hopping is infeasible due to power and bandwidth limitations. This variation adapts the protocol by hopping a much smaller device identifier within the application-layer payload. A central network server pre-provisions each device with a unique pseudo-random number generator (PRNG) seed. Upon waking, the device calculates the next valid identifier in its sequence based on the current time slot (derived from a network beacon). It transmits a small data packet (e.g., 51 bytes) with this identifier. The network server, knowing the seeds for all devices, computes the expected identifiers for all devices in that time slot and accepts the message. This provides lightweight endpoint authentication and obfuscation with minimal overhead. The "moving window" on the server side accounts for clock drift and transmission delays.
  • Diagram:

    flowchart TD
        subgraph IoT Device (Low Power)
            A[Wake from Sleep] --> B{Sync to Network Beacon};
            B --> C[Get Current Time Slot];
            C --> D[Calculate Next ID from Seed + Time];
            D --> E[Transmit Payload + Hopped ID];
        end
        subgraph Network Server
            F[Receive Packet] --> G{For each registered device...};
            G --> H[Calculate Expected ID from Seed + Time];
            H --> I{Is received ID in valid window?};
            I -- Yes --> J[Accept & Process Packet];
            I -- No --> K[Reject Packet];
        end
        E --> F;
    

3. Cross-Domain Application

• Variation 3.1: Automotive - Vehicle-to-Everything (V2X) Communications

  • Enabling Description: In a V2X network, vehicles and infrastructure nodes transparently establish agile communication links to broadcast safety messages (e.g., collision warnings). A vehicle's Telematics Control Unit (TCU) acts as the proxy. When it needs to communicate with a nearby vehicle or a roadside unit (RSU), it does not use its permanent MAC address or IP address. Instead, it generates a temporary, pseudo-random identifier based on a shared secret provisioned by a regional vehicle authority and synchronized via GPS time. All vehicles in a geographic area share the same algorithm. A receiving vehicle validates incoming messages by checking if the sender's identifier falls within a moving window of valid identifiers for the current time epoch. This prevents message spoofing and tracking of a vehicle's movements by its network identifiers.
  • Diagram:

    classDiagram
        class VehicleTCU {
            +permanentID: string
            -regionalSecret: key
            -gpsTime: timestamp
            +generateTemporaryID()
            +broadcastSafetyMessage(message)
            +receiveMessage(message)
        }
        class RoadsideUnit {
            -regionalSecret: key
            -gpsTime: timestamp
            +validateMessage(message): bool
        }
        VehicleTCU --|> V2X_Node
        RoadsideUnit --|> V2X_Node
        class V2X_Node {
            <<interface>>
            validateMessage()
        }
    

• Variation 3.2: AgTech - Secure Irrigation Control Network

  • Enabling Description: An agricultural technology system uses the agile protocol to secure communications between a central irrigation controller and thousands of wireless soil moisture sensors and valve actuators distributed across a large farm. The gateway controller, upon receiving a DNS request for its management domain, initiates an agile session over a 900 MHz mesh network. Each sensor/actuator node has a pre-shared key. The "varying data value" is a compact message authentication code (MAC) appended to each command or sensor reading, calculated using the shared key and a synchronized counter value (the sequence). The controller broadcasts a new counter value periodically. Any command received by a valve actuator with an invalid MAC (not matching the expected value based on the current counter) is ignored. This prevents attackers from issuing fraudulent commands (e.g., "open all valves") by replaying old messages or spoofing the controller.
  • Diagram:

    sequenceDiagram
        participant Controller as Central Controller
        participant Sensor as Soil Sensor
        participant Actuator as Valve Actuator
    
        Controller->>all: Broadcast new Counter Value (CV)
        loop Every Minute
            Sensor->>Controller: Reading + generateMAC(Reading, SharedKey, CV)
            Controller->>Actuator: Command + generateMAC(Command, SharedKey, CV)
            activate Actuator
            Actuator->>Actuator: Validate MAC(Command, SharedKey, CV)
            Note right of Actuator: If valid, execute command. Else, discard.
            deactivate Actuator
        end
    

• Variation 3.3: Consumer Electronics - Smart Home Device Onboarding

  • Enabling Description: When a new smart home device (e.g., a lightbulb) joins a home network, it uses an agile protocol for secure onboarding. The user's smartphone, acting as the proxy, scans a QR code on the device. The QR code contains a one-time secret. The phone intercepts the device's initial attempt to contact its cloud service via DNS. Instead, it establishes a local agile link over Wi-Fi Direct or Bluetooth LE. The "pseudo-randomly varying value" is a changing channel or frequency hopping pattern, synchronized using the one-time secret from the QR code. Over this secure, temporary link, the phone safely provisions the device with the home Wi-Fi credentials and a permanent device certificate, after which the agile link is torn down. This prevents eavesdropping on Wi-Fi credentials during the vulnerable setup phase.
  • Diagram:

    flowchart LR
        A[User scans QR code on Bulb] --> B(Phone obtains one-time secret);
        C[Bulb powers on, broadcasts setup beacon] --> D{Phone intercepts beacon};
        D -- Uses secret --> E[Establish Agile Wi-Fi Direct Link];
        subgraph Agile Link (Frequency Hopping)
            E -- Securely transmit --> F[Wi-Fi Credentials & Certificate];
        end
        F --> G[Bulb connects to Home Wi-Fi];
        G --> H(Agile Link Terminated);
    

4. Integration with Emerging Tech

• Variation 4.1: AI-Driven Predictive Path Obfuscation

  • Enabling Description: The agile networking protocol is integrated with an AI-based threat intelligence platform. The AI model continuously analyzes global network traffic patterns to predict likely attack vectors and reconnaissance probes. When a DNS request is intercepted for a high-value domain, the proxy not only establishes a VPN but also uses the AI's output to select the parameters for the pseudo-random sequence. For example, if the AI predicts a high likelihood of a DDoS attack from a specific geographic region, the address hopping algorithm is biased to select IP addresses from netblocks that are topologically distant from the predicted attack source, and the hop frequency is increased dynamically. The moving window size is also adjusted based on the AI's real-time assessment of network jitter and packet loss.
  • Diagram:

    graph TD
        A[Client DNS Request] --> B{Proxy Intercept};
        B --> C[AI Threat Intelligence Platform];
        C -- Real-time Risk Score & Topology Data --> B;
        B --> D{Select Agile Parameters};
        D -- Seed, Algorithm, Hop Rate --> E[VPN Tunnel Module];
        E -- Agile VPN Established --> F[Destination Server];
    

• Variation 4.2: IoT Sensor-Triggered Network Agility

  • Enabling Description: A secure facility's network integrates the agile protocol with its physical security system (IoT sensors). The network operates in a standard, static IP configuration by default. However, if an IoT sensor (e.g., a door tamper sensor, a geofence breach detector) is triggered, it sends an authenticated alert to a central security controller. The controller immediately instructs all network nodes (clients, servers) to switch to an agile communication mode. The trigger event itself contains the seed for the pseudo-random sequence, ensuring that only nodes that received the specific alert can communicate. This creates an "on-demand" VPN that isolates the network segment under potential physical threat, preventing an intruder who gains physical access from easily scanning or accessing the network.
  • Diagram:

    stateDiagram-v2
        state "Static IP Mode" as Static
        state "Agile IP Mode" as Agile
    
        [*] --> Static: Network Normal
        Static --> Agile: IoT_Sensor_Alert(seed)
        Agile --> Agile: Communication via Hopped IPs
        Agile --> Static: All_Clear_Signal
    

• Variation 4.3: Blockchain-Managed Agility Policies

  • Enabling Description: The policies determining which domain names trigger a secure agile link are managed on a private or permissioned blockchain. A central administrator (or a decentralized autonomous organization - DAO) proposes a new policy (e.g., "add secure.corp.com to the agile list"). This policy change is a transaction that must be validated by multiple nodes before being committed to an immutable block. Client proxies query a blockchain node via a lightweight client to retrieve the latest authoritative policy set. This provides a tamper-proof, auditable trail of all policy changes and prevents a single compromised server from pushing malicious policies (e.g., disabling security for a specific domain) to clients. The blockchain's block hash can also be used as a seed for the pseudo-random sequence, ensuring all clients are synchronized to the same sequence based on the latest state of the distributed ledger.
  • Diagram:

    erDiagram
        POLICY {
            string domainName
            string policyType
        }
        BLOCK {
            int blockID
            string blockHash
            timestamp time
        }
        TRANSACTION {
            int txID
            string payload
        }
        BLOCK ||--o{ TRANSACTION : contains
        POLICY ||..|| TRANSACTION : is_payload_of
    

5. The "Inverse" or Failure Mode

• Variation 5.1: Graceful Degradation under DDoS Attack

  • Enabling Description: This variation is designed to maintain system availability during a high-volume packet flood (DDoS) attack. When the proxy or gateway detects an incoming packet rate exceeding a critical threshold, it enters a "degraded agility" mode. In this mode, instead of hopping individual source/destination IP addresses, it hops entire /24 subnets. It communicates a new pair of source/destination subnets to the legitimate client via an authenticated, out-of-band channel (e.g., an SMS message or a pre-established secure websocket). The client and server then use any valid IP within those subnets. This makes it computationally harder for the attacker to adapt their flood to the new network space. While security is reduced (as the address space is more predictable), core connectivity for legitimate users is preserved until the attack subsides.
  • Diagram:

    graph TD
        A[Normal Operation: IP Hopping] --> B{DDoS Detected?};
        B -- No --> A;
        B -- Yes --> C[Enter Degraded Mode];
        C --> D[Switch to Subnet Hopping];
        D --> E[Transmit new /24 subnets to client via OOB channel];
        E --> F[Resume communication on new subnets];
        F --> G{Attack Mitigated?};
        G -- No --> D;
        G -- Yes --> A;
    

• Variation 5.2: Low-Functionality "Beacon" Mode

  • Enabling Description: A mobile device or sensor with limited battery life uses this mode to conserve power. Instead of maintaining a full agile VPN, the device remains in a low-power sleep state. Periodically, it wakes and transmits a single, authenticated "beacon" packet. The "pseudo-randomly varying value" is the UDP source port from which the beacon is sent. The device and a server share a synchronized list of valid source ports for the next transmission window. If the server needs to send a command to the device, it replies to the beacon's IP and hopped source port immediately. If no reply is received within a short timeout, the device returns to sleep. This allows the server to maintain "assured availability" of the device without the overhead of a persistent connection, only establishing a full data link when necessary.
  • Diagram:

    sequenceDiagram
        participant Device as Mobile Device
        participant Server as Cloud Server
        loop While Idle
            Device->>Device: Sleep(t)
            Device->>Server: Send Beacon (from hopped UDP port)
            alt Server has data for Device
                Server-->>Device: Send Command
                Device->>Device: Process Command
            else No data
                Device->>Device: Timeout, return to sleep
            end
        end
    

---

Combination Prior Art Scenarios

• Combination 1: Integration with DNSSEC (Domain Name System Security Extensions)

  • Enabling Description: The determination of whether to create a secure link is integrated with the DNSSEC validation process. An open-source DNS resolver like BIND or Unbound is modified. When a client requests a domain, the resolver performs standard DNSSEC validation to verify the authenticity of the DNS records. A new, custom resource record (e.g., a TXT record with a specific format like _agilevpn.example.com IN TXT "enabled=true; alg=sha256; seed_uri=...") is defined. If this record is present and the entire DNS response is cryptographically validated by DNSSEC, the resolver signals the client's proxy (as described in the '135 patent) to initiate the agile VPN. This combines the transport-layer security of agile networking with the DNS-layer authenticity provided by DNSSEC, ensuring that the policy to enable the VPN is itself authentic and not spoofed.
  • Diagram:

    flowchart TD
        A[Client] -- DNS Query for www.example.com --> B[DNSSEC-aware Resolver];
        B -- Fetches Records --> C[Authoritative DNS Server];
        C -- Signs Records with Private Key --> C;
        C -- Returns RRSIG + A + TXT records --> B;
        subgraph Resolver
            B1[Validate RRSIG with Public Key] --> B2{Signature Valid?};
            B2 -- Yes --> B3[Check for _agilevpn TXT Record];
            B3 -- Yes --> B4[Signal Client Proxy to start Agile VPN];
        end
        B --> A;
    

• Combination 2: Integration with QUIC (Quick UDP Internet Connections)

  • Enabling Description: The agile protocol is implemented over the QUIC transport protocol. QUIC, an open standard from the IETF, provides encrypted, stream-multiplexed transport over UDP. In this combination, the "pseudo-randomly varying value" is the QUIC Connection ID (CID). Clients and servers negotiate a synchronized algorithm for generating future CIDs. During a session, either party can issue a NEW_CONNECTION_ID frame, instructing the peer to start using a new CID from the pre-agreed sequence for subsequent packets. Routers and firewalls would see packets for the same logical connection appearing to come from different connection identifiers, obfuscating the session while leveraging QUIC's built-in encryption, congestion control, and resistance to head-of-line blocking.
  • Diagram:

    sequenceDiagram
        participant Client
        participant Server
        Client->>Server: Initial QUIC Handshake (establishes agility algorithm)
        Client->>Server: QUIC packets with ConnectionID_1
        Server->>Client: QUIC packets with ConnectionID_A
        Server->>Client: NEW_CONNECTION_ID frame (propose ConnectionID_B)
        Client->>Server: Acknowledge, switch to sending to ConnectionID_B
        Client->>Server: QUIC packets with ConnectionID_2
        Note over Client,Server: External observer sees multiple unrelated UDP flows
    

• Combination 3: Integration with WireGuard

  • Enabling Description: The simple and open-source WireGuard VPN protocol is used as the underlying secure tunnel, but it is modified to support agile addressing. A small daemon runs alongside the standard WireGuard process. This daemon is responsible for managing the agility algorithm. Periodically, or upon a trigger, the daemon uses a control interface (e.g., wg-quick scripting hooks) to change the Endpoint IP address in the peer configuration of the WireGuard interface. The agility daemon on the server side simultaneously updates its firewall rules to accept incoming WireGuard packets from the new client IP address. The public keys (PublicKey) remain the same, providing continuous cryptographic identity, but the underlying routable IP endpoints change according to the pseudo-random sequence, combining WireGuard's cryptographic strength with the network-level obfuscation of the '135 patent.
  • Diagram:

    graph BT
        subgraph Client Machine
            A[Agility Daemon] -- "wg set wg0 peer... endpoint=NEW_IP" --> B[WireGuard Interface (wg0)];
            C[User Traffic] --> B;
        end
        subgraph Server Machine
            E[Agility Daemon] -- "firewall-cmd --add-source=NEW_IP" --> D[Firewall];
            F[WireGuard Interface (wg0)] --> D;
        end
        B -- Encapsulated UDP Packet --> G((Internet));
        G --> D;
        A -- Sync Channel --> E;