US 6226751

I'll research US patent 6226751 across USPTO sources and check for any CAFC/litigation activity.

Let me check specifically for any CAFC/Federal Circuit or district court litigation involving this patent.

Let me run a couple more targeted searches for any PTAB or court proceedings.

US Patent 6,226,751 B1 — Summary

Source basis: The authoritative full text supplied (Google Patents, fetched 2026‑09‑26) plus corroborating indexes (FreePatentsOnline, uspto.report, Unified Patents, everypatent.com). I could not query USPTO PatentCenter/Public PAIR or the Federal Circuit's docket system directly; the litigation findings below come from web indexes and should be treated as indicative, not exhaustive.

Bibliographic data

Abstract (as issued)

The patent provides a method and apparatus for establishing a VPN operating over a public data network. A system selects entities coupled to the public network to include in the VPN, assembles identifiers for those entities, and uses the identifiers to identify communications between them so those communications can be transferred securely over the public network. Variations include defining encryption, authentication and compression parameters; selecting entities by assembling them into groups and selecting groups; defining access control rules governing what traffic may pass through VPN units; and defining address translation rules for VPN units to translate local network addresses into public network addresses.

Plain-language overview of the independent claims

Claim 1 — method of configuring a VPN. Steps: (a) receive selections of which entities on the public network belong to the VPN, where those entities sit on local networks and are addressed by local addresses; (b) assemble identifiers for those entities; (c) define address translation rules for the VPN units, so a VPN unit can translate a local address into a corresponding public‑network address; (d) use the identifiers to recognize traffic between the selected entities; and (e) transfer that traffic securely, applying the address translation rules during the transfer. The claim is about the configuration/management plane married to the data path — not merely about encrypting packets.

Claim 13 — method, more specific version. Like claim 1 but with two added requirements: entity selection is done by assembling entities into groups of one‑or‑more and selecting groups, with each group tied to a VPN unit through which the group's traffic is routed; and the configuration expressly includes defining encryption, authentication and compression parameters for the VPN.

Claim 16 — apparatus. A system comprising: a VPN manager on the public network with a selection mechanism that receives entity selections and assembles identifiers; the manager additionally configured to define address translation rules for VPN units; a VPN unit on the public network through which VPN traffic is routed; an identification mechanism inside the VPN unit that uses the identifiers to recognize traffic between the entities; and a secure communication mechanism that transfers communications securely and applies the address translation rules. Note the claim builds the translation role into both the manager (defining the rules) and the communication mechanism (using them).

Claim 27 — program storage device. A computer‑readable medium storing instructions that, when executed, perform the claim 1 method (select entities → assemble identifiers → define address translation rules → identify communications → transfer securely using the translation rules).

Dependent claims add: encryption/authentication/compression parameters (2, 17); grouping and group‑to‑VPN‑unit association (3, 4, 18, 19); access control rules (5, 14, 20); translation of many entities through a single IP address (6, 15, 21, 22); IP address and user‑ID identifiers (7, 8, 22, 23); entity types (computer system, computer user, remote client) (9–11, 24–26); and centralized VPN manager (12).

Notable specification content

• A single VPN unit can serve many VPNs, and a given network address can belong to several VPNs simultaneously — the core asserted advantage over paired encryption/decryption appliances.
• Lookup tables in each VPN unit hold the per‑VPN compression algorithm (LZW in one embodiment), encryption algorithm, and authentication/key‑management protocol; alternatively a VPN unit may use the same algorithms for all VPNs.
• Four high‑level management objects: VPN unit object (IP address), group object (associated VPN‑unit ID plus net/mask pairs), VPN object (encryption/authentication/compression algorithms, group list, remote‑client list), and client object (VPN memberships plus NSID/MKID, where NSID is described as the MD5 hash of a user name and MKID as the master key ID of the domain).
• Address translation unit 731 supports static, dynamic and port translation; port translation lets multiple local addresses map to one public address using different port identifiers.
• Management‑station modules include user interface presenter 500, error/semantics checker 502, command handler 506, "dredger" 504 (database search/update), collator 508 (address sorting/configuration generation), and communication library 510.

Litigation / CAFC check — important caveat

I found no Federal Circuit or other appellate docket in 2026 involving US 6,226,751. Given that the patent's term expired on April 17, 2018 (Google Patents lists "Anticipated expiration" and "Expired – Lifetime"), an active 2026 appeal is unlikely. I want to be explicit that this is a negative search result, not an authoritative confirmation — I could not query the CAFC docket or PACER/CourtListener directly, only indirectly.

What the record does show regarding the patent's role in litigation:

1. US 6,226,751 appears as prior art in the VirnetX v. Apple line of cases. A 2014 Cryptome exhibit list of "agile network secure comms patent" materials (Case 14‑1202) lists "6226751 May 2001 Arrow et al." among references. Notably, US 6,701,437 — the child CIP of '751 — was used as an anticipatory reference against VirnetX's patents (e.g., US 9,860,283's reference list cites VirnetX v. Microsoft contentions, and an EPO international search report on PCT/US2005/037292 cites US 6,701,437 as X‑category prior art against VPN routing claims, with the family annex listing US 6,226,751 B1 as its related parent). This is a good illustration of '751's family being weaponized as prior art rather than asserted.

2. The '751 family shows up in Cisco VPN invalidity contentions (PTAB/PTACTS exhibit C‑28 materials, petition 1557625) as part of prior‑art combinations with Mehta, Caronni I/II, and Hipp — again as a cited reference, not as an asserted patent.

3. No infringement suit asserting '751 itself surfaced. The patent transferred through a long chain of Avaya/VPNET security interests (Bank of New York 2002; Citibank/Citicorp 2007; Bank of New York Mellon 2011 and 2013; Citibank 2017; Goldman Sachs and Citibank 2018), with most liens released via Avaya's bankruptcy court orders around December 2017–January 2018 and the Goldman Sachs interest released May 2023. The numerous security-interest recordals are collateral assignments, not evidence of litigation.

Identifier disambiguation (per your literal-interpretation instruction)

Searches for the string "6226751" return several unrelated items that are not this patent and should not be conflated with it:

• JP 6226751 B2 — a Japanese patent (appearing in an EPO family annex for EP 22 17 2082, publication date rendered as 08‑11‑201…); a different document entirely.
• FEC transaction ID 6226751 and a SEC EDGAR accession/related ID "6226751" tied to Quiksilver, Inc. — administrative identifiers, not patents.
• The '751 in the VirnetX materials is the same patent as US 6,226,751 (Arrow et al., May 2001), so that usage is on point.

Uncertainty statement

• Claim text, dates, inventors, assignees and abstract are taken from the authoritative full text you supplied and are high confidence.
• Current ownership is stated with the caveat Google Patents itself gives — the assignee list "may be inaccurate" and reflects recorded assignments, not a legal conclusion on chain of title. Given the 2017–2018 bankruptcy lien releases and the 2023 Goldman Sachs release, the operative owner today would most plausibly be Avaya Inc. (or an Avaya successor/divested entity), but I cannot confirm current title without Assignment Center/PAIR access.
• My 2026 CAFC docket finding is a negative result from indirect search only; if you need a definitive answer, a direct query of the Federal Circuit's CM/ECF docket and CourtListener/PACER for "6,226,751" and "6226751" is required.

I'll search for litigation involving US patent 6226751 across multiple sources.

Let me search more specific litigation sources.

Let me try more targeted litigation database searches.

Litigation Search Results for US Patent No. 6,226,751

Bottom line: I found no litigation specifically involving US Patent No. 6,226,751. I was unable to identify any district court case, ITC investigation, PTAB proceeding, or Federal Circuit appeal in which US 6,226,751 was a patent-in-suit or patent-at-issue.

What I searched

I ran targeted queries across general web indexes that surface patent litigation aggregators, including references to the Unified Patents litigation portal, CourtListener/RECAP, Docket Alarm, PACER-derived dockets, and Justia. I searched on the literal strings "6226751," "6,226,751," and "US-6226751-B1," combined with litigation terms (infringement, complaint, lawsuit, district court).

What I found (and why it does not show litigation on this patent)

Every hit for "6226751" was a false positive or a non-litigation reference:

Important caveats on my confidence

• I was not able to directly open the Unified Patents litigation caselist (portal.unifiedpatents.com/litigation/caselist) or run a full Docket Alarm / PACER party search for this patent before hitting my search limits. My conclusion rests on indexed results, not on a purpose-built litigation database query.
• This patent has a long and complex chain of title (VPNet Technologies → Avaya Technology Corp. → Avaya Inc. → Avaya Technology LLC → back to Avaya Inc., with multiple security interests and a 2017 bankruptcy release). Given that ownership history and the patent's 2018 expiration, I cannot rule out a case I did not surface — but nothing in my searches indicates one exists.
• The patent expired (anticipated expiration) on 2018-04-17, which reduces the likelihood of any recent assertion activity.

Recommendation

To confirm definitively, run direct queries against:

1. Unified Patents litigation caselist (https://portal.unifiedpatents.com/litigation/caselist) — search the patent number US-6226751-B1.
2. Docket Alarm / PACER — party search for plaintiffs "VPNet Technologies, Inc." and "Avaya Inc." with patent 6,226,751.
3. USPTO Patent Trial and Appeal Board (PTAB) — search for IPR/PGR/CBM proceedings naming 6,226,751 as the challenged patent.

On the current record, my answer is: no litigation is known to have involved US Patent No. 6,226,751. I am flagging this as a "not found" result rather than an affirmative "none ever existed," because I could not complete a direct litigation-database query.

I'll verify the structured ODP result against public sources before writing the analysis.

Let me run a couple more targeted checks on this specific patent number and its litigation history.

PTAB Proceedings — U.S. Patent 6,226,751 ("Method and apparatus for configuring a virtual private network")

Verification note (what I checked): The structured ODP block states there are no AIA trial proceedings on file for US 6,226,751 as of the most recent ingest. I ran independent web checks against PTAB-hosted documents, CourtListener/recap dockets, Docket Alarm PTAB case pages, Federal Circuit materials, and the Unified Patents patent portal. Every "751" hit in those results was a different patent (e.g., U.S. 10,536,751 to Broadband iTV, and IPR proceedings captioning it), not U.S. 6,226,751. I found no IPR, PGR, or CBM involving this patent. I did not confirm or rule out pre-AIA inter partes reexamination or ex parte reexamination (my search was scoped to AIA trials); treat that as an open item rather than a negative finding.

Proceedings overview

Total AIA trials on this patent: 0. Breakdown: 0 active, 0 claims invalidated, 0 claims sustained, 0 settled, 0 institution denials. Bottom line for a defendant: there is no PTAB record to lean on — no claim of the '751 patent has been canceled, narrowed, or even tested at the Board, and no petitioner is estopped under § 315(e)(2) from attacking it. You get none of the "claims 1–13 are already dead" leverage that a prior IPR would give you, but you also inherit a completely clean slate: every ground — § 102, § 103, § 112 — is still available to you, subject only to the ordinary limits (printed publications/patents as prior art in an IPR; the § 315(b) one-year bar if you've been served).

Two structural facts dominate any defensive analysis here before you even get to the prior art:

1. The patent expired on 2018-04-17 (20 years from the 1998-04-17 filing date; Google Patents legal status: "Expired - Lifetime"). It cannot be infringed going forward. Any assertion is a past-damages play, and § 286's six-year lookback means the recoverable window closed no later than 2024-04-17 — i.e., roughly 2.4 years before today's date, 2026-09-27.
2. This patent has no known PTAB or Federal Circuit validity footprint at all. That cuts both ways; see the strategic summary.

Strategic summary

Claim status of the 27 claims: none canceled, none sustained, all untested. The patent issued with 27 claims: independent method claims 1 and 13, independent apparatus claim 16, and independent program-storage-device claim 27, with the remaining claims depending from them (claims 2–12 from claim 1, claims 14–15 from claim 13, claims 17–26 from claim 16). Because no AIA trial ever reached a final written decision, every one of claims 1–27 stands exactly as issued — no certificate of cancellation, no certificate of correction narrowing them, and (as far as I can verify) no reexamination certificate of any kind. A defendant therefore faces the full original claim set, un-narrowed: that is the worst case on substance and the best case on procedural freedom.

Estoppel landscape: empty. § 315(e)(2) estoppel is triggered only by an IPR/PGR that reaches a final written decision. With no instituted proceeding and no FWD, no petitioner, real party in interest, or privy is barred from raising anything in a civil action or ITC action, and there is no estoppel running against you by privity to any prior challenger. The only clock that matters is your own: if you have been served with a complaint alleging infringement, 35 U.S.C. § 315(b) gives you one year from service to file an IPR; and note that the one-year bar applies to service of a complaint, whereas a pre-suit demand letter does not start it. Because the patent expired in 2018 and no proceeding exists, a defendant asserting invalidity will be litigating it in district court — where the burden is clear-and-convincing, the presumption of validity applies, and IPR's broadest-reasonable-interpretation and preponderance standards are unavailable to you.

Pattern signals — all negative here. No petitioner has filed even once against this patent, so there is no serial-petitioner pattern, no joinder/understudy dynamic, no General Plastic issue, and no defensive aggregator IPR in the chain. Unified Patents maintains a portal entry for US-6226751-B1 (prior-art listing and family data at https://portal.unifiedpatents.com/patents/patent/US-6226751-B1), but a portal entry is a database record, not a challenge — I found no Unified Patents-filed petition on this patent. The absence of any IPR is itself informative: this patent was a foundational VPNet Technologies asset (filed 1998-04-17, granted 2001-05-01, later held in the Avaya chain of title after the VPNet acquisition), and it was a configuring patent — the operational counterpart, U.S. 6,701,437 ("Method and apparatus for processing communications in a virtual private network," filed 1998-11-09 as a continuation-in-part of the same 09/062,507 application), is the one with the family relationship worth tracking. Tellingly, the '751's own CIP sibling U.S. 6,701,437 (referred to in that record as "Hoke") was itself used as prior art in a later PTAB proceeding — IPR2020-00580 (U.S. 9,667,534), where Patent Owner argued the Dantu–Aziz combination was cumulative of "the combination of Hoke and Newman" previously overcome during prosecution (https://bannerwitcoff.com/wp-content/uploads/2020/08/PTAB-IPR2020-00580-11.pdf). That is a signal about how the VPN-encapsulation art family behaves at the Board against neighboring patents; it is not an invalidity finding about the '751 patent, and the '437 patent's later 1998-11-09 filing date means it is not § 102/§ 103 prior art against the '751's own 1998-04-17 filing.

Recommended next steps

• Do not represent to a court or a counterparty that any claim of the '751 patent has been canceled. It has not. There is no FWD to cite, because there was no trial. If you were hoping to quote a disposition at claim 1, you cannot — and the fact pattern here is the opposite of "the troll has no case because claims 1–5 are gone."
• Lead with the expiration/limitations position, not with PTAB. Any demand letter citing U.S. 6,226,751 is, at best, asserting pre-2018-04-17 conduct, and § 286 caps recovery to the six years before filing — so an assertion filed today, 2026-09-27, reaches back only to roughly 2020-09-27, all of which post-dates the expiration. That makes the damages theory worth zero on its face absent some theory of pre-expiration accrual that was already time-barred as of 2024-04-17. Ask the patent owner to identify (a) the accused acts and their dates, and (b) the authority under which a patent expired since 2018-04-17 supports a live damages claim. This is your strongest and cheapest defense.
• If there is live pre-2018 exposure or a pending suit, preserve your IPR window. Confirm your § 315(b) service date; if you are inside the one-year window, an IPR remains available even against an expired patent (the Board applies Phillips claim construction for expired claims, which is a genuinely petitioner-friendly difference from the BRI era). But note that an expired patent gives you no claim-construction-favorable post-grant leverage elsewhere, and an IPR victory produces no estoppel benefit against you, only a clean invalidity judgment.
• Build the invalidity case on 1997–1998-era printed publications and patents, since there is no § 315(e) estoppel constraining you and no prior PTAB record to distinguish. The art cited across the neighboring VPN-encapsulation proceedings — Aziz (U.S. 5,548,646), Beser (U.S. 6,496,867), RFC 2401 (Kent & Atkinson, Nov. 1998), and firewall/VPN product documentation of the period — defines the field the Board has accepted as analogous; note that RFC 2401 post-dates the '751's 1998-04-17 filing, so verify publication dates against the '751 priority date rather than importing the reference set from the later VirnetX-family IPRs, where the priority dates were years later.
• Do not expect a CBM route. The covered-business-method transitional program was limited to patents claiming a financial product or service, and its window has closed in any event. A VPN configuration patent of this vintage is not CBM-eligible, and I found no CBM filing here regardless.
• Set expectations with your client: "no PTAB activity" is not a defense, and it is not the same as "the patent is weak." It means (1) there is no free claim-cancellation story to tell, and (2) you are the first mover, with a full, uncluttered record and no estoppel — a better posture to litigate from than to rely on, but only if you actually file or actually try the invalidity case.

I'll verify the assignment record against external sources before writing up. Let me run several targeted searches in parallel.

Assignment & Ownership Reconstruction — US Patent No. 6,226,751

Method note / limitations (read first): The assignment data below is drawn from the Google Patents "Legal Events / Reassignment" record reproduced in the authoritative patent text, not from a live USPTO Assignment Center query. I was unable to open assignmentcenter.uspto.gov or assignment.uspto.gov directly before hitting my tool limits, so the following should be treated as a reconstruction from the Google-hosted legal-events record (which mirrors the same underlying USPTO reels) rather than a fresh Assignment Center pull. Two consequences:

• Reel/frame numbers are only partially available. The provided record surfaces reel/frames only where they are quoted inside a later release description (012775/0149, 025863/0535, 041576/0001, 030083/0639, 45124/0026, 045034/0001). For the remaining entries the reel/frame is not recoverable from the sources I could access, and I will say so rather than invent them.
• Correspondent-of-record data is absent. The Google legal-events feed does not carry the recording attorney/agent. I could not retrieve it. No correspondent is stated below, because fabricating one would be worse than the gap. This directly limits NPE Signal #3.

Inventors

Named inventors (all on the face of US 6,226,751):

Supporting detail / unusual patterns:

• All six inventors assigned to the original assignee VPNet Technologies, Inc., i.e., this was an employer-owned invention set, not an independent-inventor filing (1998-07-06 assignment, and again 2005-05-19; both recorded to VPNet).
• Recording defect pattern worth noting: the first recorded assignment (1998-07-06) names only five assignors — Arrow, Bots, Hoke, Jones, Liu. William E. Hunt is missing. The later 2005-05-19 assignment names all six, adding Hunt. This is consistent with a corrective/confirmatory inventor assignment curing an omission in the original record. It is not evidence of inventor turnover.
• Inventor continuity, not exodus: Bots and Hunt independently appear as inventors on VPNet's related "Architecture for virtual private networks" family (EP 0988735 / US 7,010,702), confirming they remained VPNet technical personnel across the portfolio. I found no evidence that all (or any) inventors departed VPNet within 12 months of filing, and I flag the "mass inventor departure preceding a fire-sale" pattern as not present on the available record.
• I could not determine individual post-2001 employment (pre/post the Avaya acquisition) for each inventor.

Original assignee

VPNet Technologies, Inc. (original assignee on the issued patent; Milpitas, California — some sources also list a Basking Ridge, New Jersey address).

• Business: A developer of virtual private network (VPN) solutions and devices — dedicated high-speed VPN hardware plus client and management software. Press coverage names the VPNware Systems product line and the VPNsure Managed Services Program; founding year given as 1995.
• Did it ship a product embodying the claims? Yes, on the record. The patent's claimed subject matter is a centralized VPN management station that configures distributed VPN units to selectively encrypt/authen­ticate/compress inter-entity traffic (claim 1; FIGS. 1, 4–5, 8–9). VPNet commercially shipped VPN gateways, remote clients, and centralized management software — the exact architecture described. This is an operating-company patent, not a paper asset.
• Current status: Acquired. Avaya Inc. announced the acquisition of VPNet on 2001-01-08 and it closed in the quarter ending 2001-03-31 (reported as completed 2001-02-08 per M&A databases), for ~$120 million in cash. VPNet's name persists as a recorded co-assignee/obligor in later Avaya security agreements (2007, 2017, 2018), i.e., it survived as an Avaya subsidiary/record entity rather than being struck off.
• Successor owner status: Avaya Inc. — a large operating communications-equipment vendor (spun out of Lucent). Avaya filed Chapter 11 on 2017-01-19 (S.D.N.Y.) and emerged 2017-12-15; it filed Chapter 11 again in February 2023. It remains an operating company, not a licensing vehicle.

Assignment timeline

Chronological, as reflected in the authoritative record. Where execution vs. recording dates or reel/frame are not separable in the source, I say so.

1. 1998-04-17 (executed) / recorded 1998 — Reel not surfaced

   • Conveyance: Application filed (not an assignment)
   • Assignor: n/a — Applicant VPNet Technologies, Inc.
   • Assignee: n/a
   • Correspondent: unavailable
   • Context: Original application filing (Ser. No. 09/062,507).

2. 1998-07-06 (executed) / recorded 1998-07-06 — Reel not surfaced

   • Conveyance: Assignment of assignors' interest
   • Assignor: Arrow, Leslie J.; Bots, Henk J.; Hoke, Mark R.; Jones, Russell C.; Liu, Quentin C. (Hunt omitted)
   • Assignee: VPNet Technologies, Inc.
   • Correspondent: unavailable from sources accessed
   • Context: Original inventor→company assignment. Defective on its face — one named inventor (Hunt) not included.

3. 2001-05-01 — Reel n/a

   • Conveyance: Issuance (patent granted)
   • Context: Patent issued to VPNet Technologies, Inc.

4. 2002-04-09 (executed) / recorded 2002 — Reel not surfaced

   • Conveyance: Security Agreement
   • Assignor: Avaya Technology Corp. (successor to VPNet via the Feb 2001 acquisition)
   • Assignee: The Bank of New York
   • Correspondent: unavailable
   • Context: Securitization — collateral pledge, not a sale. Note the title gap: no discrete VPNet→Avaya assignment instrument appears in the record; Avaya's ownership appears to arise from the 2001 acquisition (functionally a merger / operation of law), evidenced by Avaya Technology Corp. granting this security interest a year later.

5. 2005-05-19 (executed) / recorded 2005 — Reel not surfaced

   • Conveyance: Assignment of assignors' interest (corrective/confirmatory)
   • Assignor: Hunt, William E.; Hoke, Mark R.; Arrow, Leslie J.; Jones, Russell C.; Bots, Henk J.; Liu, Quentin C. (all six)
   • Assignee: VPNet Technologies, Inc.
   • Correspondent: unavailable
   • Context: Cure/confirmatory instrument adding the inventor omitted in the 1998 recording. Note it still names VPNet as assignee even though Avaya held beneficial title — consistent with a records-hygiene filing against the original chain.

6. 2007-11-27 (executed) / recorded 2007 — Reel not surfaced

   • Conveyance: Security Agreement
   • Assignor: Avaya Technology LLC; Avaya, Inc.; Octel Communications LLC; VPNet Technologies, Inc. (joint obligors)
   • Assignee: Citibank, N.A., as Administrative Agent
   • Correspondent: unavailable
   • Context: Securitization — pooled collateral pledge covering the Avaya group.

7. 2007-11-28 (executed) / recorded 2007 — Reel not surfaced

   • Conveyance: Security Agreement
   • Assignor: same Avaya-group obligors
   • Assignee: Citicorp USA, Inc., as Administrative Agent
   • Correspondent: unavailable
   • Context: Securitization — parallel collateral pledge.

8. 2008-06-27 (executed) / recorded 2008 — Reel not surfaced

   • Conveyance: Reassignment
   • Assignor: Avaya Technology LLC
   • Assignee: Avaya Inc.
   • Correspondent: unavailable
   • Context: Internal reorganization (intra-group title consolidation).

9. 2008-12-29 (executed) / recorded 2008 — Reel not surfaced

   • Conveyance: Conversion from Corp to LLC
   • Assignor: Avaya Technology Corp.
   • Assignee: Avaya Technology LLC
   • Correspondent: unavailable
   • Context: Change of name / entity form only.

10. 2011-02-22 (executed) / recorded 2011 — Reel not surfaced

    • Conveyance: Security Agreement
    • Assignor: Avaya Inc. (a Delaware corporation)
    • Assignee: The Bank of New York Mellon Trust, N.A., as Notes Collateral Agent
    • Correspondent: unavailable
    • Context: Securitization.

11. 2013-03-13 (executed) / recorded 2013 — Reel not surfaced

    • Conveyance: Security Agreement
    • Assignor: Avaya, Inc.
    • Assignee: The Bank of New York Mellon Trust Company, N.A.
    • Correspondent: unavailable
    • Context: Securitization.

12. 2017-01-27 (executed) / recorded 2017 — Reel not surfaced

    • Conveyance: Security Interest
    • Assignor: Avaya Inc.; Avaya Integrated Cabinet Solutions Inc.; Octel Communications Corporation; VPNet Technologies, Inc.
    • Assignee: Citibank, N.A., as Administrative Agent
    • Correspondent: unavailable
    • Context: Securitization, recorded days after Avaya's 2017-01-19 Chapter 11 filing.

13. 2017-12-15 (executed) / recorded 2017 — Reels 012775/0149, 025863/0535, 041576/0001, 030083/0639 (four separate releases)

    • Conveyance: Release (Bankruptcy Court order releasing all liens)
    • Assignor(s): The Bank of New York; The Bank of New York Mellon Trust, N.A.; Citibank, N.A.; The Bank of New York Mellon Trust Company, N.A.
    • Assignee: Avaya Inc. (and affiliates, incl. VPNet Technologies, Inc., Octel Communications LLC, Avaya Integrated Cabinet Solutions Inc.)
    • Correspondent: unavailable
    • Context: Emergence from Chapter 11 — liens discharged, title cleared back to Avaya. This is the opposite of a fire-sale: the patent stayed inside the operating company.

14. 2018-01-09 (executed) / recorded 2018 — Reel not surfaced

    • Conveyance: Release by Secured Party
    • Assignor: Citicorp USA, Inc.
    • Assignee/beneficiary: VPNet Technologies, Inc.; Avaya Technology LLC; Avaya, Inc.; Sierra Holdings Corp.; Octel Communications LLC
    • Correspondent: unavailable
    • Context: Lien cleanup following the 2017 restructuring.

15. 2018-01-10 (executed) / recorded 2018 — Reel not surfaced

    • Conveyance: Security Interest
    • Assignor: Avaya Inc.; Avaya Integrated Cabinet Solutions LLC; Octel Communications LLC; VPNet Technologies, Inc.; Zang, Inc.
    • Assignee: Goldman Sachs Bank USA, as Collateral Agent
    • Correspondent: unavailable
    • Context: Securitization — new post-emergence collateral package.

16. 2018-01-23 (executed) / recorded 2018 — Reel not surfaced

    • Conveyance: Security Interest
    • Assignor: same Avaya-group obligors
    • Assignee: Citibank, N.A., as Collateral Agent
    • Correspondent: unavailable
    • Context: Securitization — parallel post-emergence collateral package.

17. 2018-04-17 — Reel n/a

    • Conveyance: Anticipated expiration
    • Context: Patent term ends (20 years from the 1998-04-17 filing). No assertion preceded it.

18. 2023-04-26 (executed) / recorded 2023 — Reel 45124/0026 (as quoted in the release)

    • Conveyance: Release of Security Interest
    • Assignor: Citibank, N.A., as Collateral Agent
    • Assignee/beneficiary: Avaya Integrated Cabinet Solutions LLC; Avaya Inc.; Avaya Management L.P.; Avaya Holdings Corp.
    • Correspondent: unavailable
    • Context: Lien release in connection with Avaya's 2023 Chapter 11.

19. 2023-05-18 (executed) / recorded 2023 — Reel 045034/0001 (as quoted in the release)

    • Conveyance: Release of Security Interest
    • Assignor: Goldman Sachs Bank USA, as Collateral Agent
    • Assignee/beneficiary: CAAS Technologies LLC; Intellisist, Inc.; HyperQuality, Inc.; HyperQuality II, LLC; Avaya Inc.; Avaya Management L.P.; VPNet Technologies, Inc.; Octel Communications LLC; Avaya Integrated Cabinet Solutions LLC; Zang, Inc.
    • Correspondent: unavailable
    • Context: Lien release connected to the 2023 Avaya restructuring.

No record of any sale, transfer to a licensing entity, or assignment to an NPE appears anywhere in the chain. Every substantive holder is an operating company; every other entry is a security/pledge or a release of one.

Timeline diagram

timeline
    title Ownership of US 6226751
    1998 : Application filed 17 April
         : Inventors assign rights to VPNet
    2001 : Patent issues 1 May
         : Avaya buys VPNet for 120M
    2002 : Security agreement to Bank of New York
    2005 : Corrective inventor assignment to VPNet
    2007 : Security agreements to Citibank and Citicorp
    2008 : Avaya Technology Corp converts to LLC
         : Reassignment to Avaya Inc
    2011 : Security agreement to BNY Mellon
    2013 : Further security agreement to BNY Mellon
    2017 : Avaya files Chapter 11 in January
         : Bankruptcy releases liens in December
    2018 : New collateral deals with Goldman Sachs
         : Patent expires 17 April
    2023 : Security interests released

NPE / troll-pattern signals

1. Shell-entity transfer — not present. No assignee anywhere in the chain carries an "IP / Patents / Licensing / Holdings / Ventures" suffix. Holders are VPNet Technologies, Inc. (operating), Avaya Technology Corp./LLC (operating), Avaya Inc. (operating), plus bank collateral agents. No single-purpose Delaware/Texas LLC appears. (Entries 1–2, 4–11.)

2. Known asserter in the chain — not present. None of the recorded assignees or collateral agents (VPNet, Avaya, The Bank of New York, Citibank, Citicorp, BNY Mellon Trust, Goldman Sachs Bank USA) matches a public NPE directory (Acacia, Marathon, IV, IPNav, Wi-LAN, Conversant/Mosaid, Vringo, Pendrell, Innovatio, MPHJ, Lumen View, Round Rock, Erich Spangenberg entities, etc.). Important disambiguation: a similarly named plaintiff, "VPN Technology Holdings, LLC," sued Red Hat in E.D. Tex. in Jan 2025, but that case asserts U.S. Patent No. 7,844,718 (a different inventor, different priority, different family) — not 6,226,751 and not in this chain. Do not conflate the two.

3. Repeat correspondent across the chain — unclear / cannot assess. The correspondent-of-record for each reel is not present in the data I could retrieve, so I cannot determine whether one attorney or firm handled multiple links. Per the operating rules, a naming pattern alone is not evidence; without the correspondent field this signal stays unclear, and I decline to guess.

4. Cascading transfers — not present. The 2007–2008 cluster is a classic intra-group reorganization (Corp→LLC conversion, reassignment to Avaya Inc.) plus securitization pledges — not a chain of unrelated LLCs passing title. There are no consecutive skillfully-staged transfers through nominally distinct acquirers. (Entries 6–9.)

5. Pre-litigation transfer — not present. No infringement suit naming 6,226,751 was identified (consistent with the prior litigation finding of "none found"), so there is no "transfer 6 months before suit" trigger. (Entries 15–16 sit ~3 months before the 2018-04-17 expiration, but they are collateral pledges, not pre-suit maneuvers.)

6. Bankruptcy fire-sale — not present (bankruptcy occurred; no sale). Avaya filed Chapter 11 on 2017-01-19 and emerged 2017-12-15. The only bankruptcy-related recordings are "Bankruptcy Court Order Releasing All Liens" (reels 012775/0149, 025863/0535, 041576/0001, 030083/0639), i.e., liens were discharged and title returned to Avaya — the patent was retained, not auctioned. Contrast the true fire-sales (Nortel, Kodak, Polaroid). (Entries 13–14.)

7. Privateering — not present. No evidence that Avaya transferred this patent (or the family) to an NPE to assert against competitors. The patent simply expired in place at Avaya. (Entries 13–17; no downstream licensing vehicle.)

8. Defensive aggregator (anti-NPE) — not present. The chain does not terminate at RPX, AST, LOT Network, Unified Patents, or OIN. It terminates with Avaya Inc. (operating) and discharged bank collateral agents. (Entries 13–19.)

Explicit caveats on this analysis:

• Signal #3 is the only signal I genuinely could not evaluate, because correspondent data was unavailable to me. A live Assignment Center pull would resolve it.
• Both prior (1998) and corrective (2005) inventor assignments name VPNet as assignee while Avaya held beneficial title — a records quirk, not an NPE tell, but it does mean the visible chain has no discrete VPNet→Avaya instrument, which a title examiner would want to trace via the 2001 merger documents.

Verdict

Defensive / non-asserting.

Justification: Every substantive link in the chain is an operating company — VPNet Technologies, Inc. (entries 1–2, 5) → Avaya (entries 4, 6–16) — and the only non-operating parties are bank collateral agents taking security interests (The Bank of New York, reel/entry 4; Citibank and Citicorp, 2007; BNY Mellon, 2011 and 2013; Goldman Sachs, 2018). The Avaya Chapter 11 produced lien releases, not a patent sale (reels 012775/0149, 025863/0535, 041576/0001, 030083/0639, all 2017-12-15), and no suit asserting 6,226,751 was identified before the 2018-04-17 expiration. There is no shell LLC, no known asserter, no cascading transfer, and no defensive-aggregator endpoint in the record.

Category-fit flag (per the "flag contradictions" instruction): the enumerated verdict set has no exact bucket for a "clean operating-company, never-asserted, now-expired" patent. I have selected the non-asserting label because the operative finding is non-assertion; note that the parenthetical definition ("chain terminates at a defensive aggregator") does not literally apply here — the chain terminates at an operating company, not at RPX/AST/LOT/Unified/OIN. Read this verdict as "non-asserting by an operating owner," not "neutralized by a defensive aggregator."

Verify at: https://assignment.uspto.gov/patent/index.html — search 6226751 (and the sibling 6,701,437, application 09/188,867, the CIP filed 1998-11-09) to confirm reels, frames, and correspondent of record, which are the fields I could not retrieve here.

Cross-reference note with prior section

The Litigation section concluded "no litigation known" on 6,226,751 but could not run a direct database query. My independent searches corroborate that: the only VPN-flavored assertion I surfaced (VPN Technology Holdings, LLC v. Red Hat, E.D. Tex. 2:25-cv-00085) is on U.S. 7,844,718, a different entity and different patent. This is consistent, not contradictory — but it is exactly the kind of same-industry name collision that can create a false "this patent was asserted" impression, so I am flagging it as the one item most likely to confuse a future reviewer.

I'll research the prior art cited against US 6,226,751, starting with USPTO and Google Patents records for this specific patent number.

I found the exact prior-art references cited on the face of US 6,226,751. Let me verify the details of each reference.

Prior Art Analysis — US Patent No. 6,226,751

Scope, method, and confidence note

I was asked to identify prior art for US 6,226,751 by examining "each patent citation for 6226751" and mapping each reference to the claims it could anticipate under 35 U.S.C. § 102. Before the analysis, three important framing points:

1. The authoritative patent text provided in my working record does not contain a "References Cited" section. The Google Patents scrape supplied in the earlier sections includes the "Cited By (139)" forward-citation list, but omits the backward citations (the examiner's references). I therefore reconstructed the face-of-patent citation list from two secondary sources that reproduce the printed front page: uspto.report/patent/grant/6226751 and the Unified Patents patent page for US-6226751-B1. Both list the same seven references (five US patents + two WO publications), which gives me reasonable confidence the list is accurate. The raw USPTO/PatentCenter page itself was not directly retrieved (I exhausted my tool budget before fetching it).

2. These are references that were considered and overcome, not references that anticipated the granted claims. US 6,226,751 issued on 2001-05-01 with all 27 claims intact. That means the examiner cited these references but did not enter a surviving § 102 anticipation rejection against the allowed claims. My § 102 mapping below is therefore a hypothetical/analyst assessment of which claims each reference is most plausibly relevant to — it is not a record of an actual examiner rejection.

3. This is consistent with the earlier litigation section of this analysis, which found no litigation or PTAB proceedings involving US 6,226,751 (a finding I am not re-litigating here, only cross-referencing). No IPR/PGR record exists in which these references were applied against the claims.

The cited references (as printed on the face of US 6,226,751)

U.S. Patent Documents

1. US 5,606,668 — Shwed

• Full citation: U.S. Patent No. 5,606,668, "System for securing inbound and outbound data packet flow in a computer network," inventor Gil Shwed; assignee Check Point Software Technologies Ltd. (Ramat Gan, IL).
• Dates: Filed 1993-12-14/15; issued 1997-02-25.
• Description: Describes a security system in which a system administrator uses a GUI to define security rules. Those rules are compiled by a "packet filter generator" into filter-language instructions that are downloaded to packet filters installed at network nodes (workstations, gateways, firewalls). Each filter examines every packet and accepts or rejects it according to the rule set. The patent also discusses logging and centralized control from a system administrator workstation.
• Potential § 102 relevance: Closest on the "centralized rule definition + distributed enforcement" concept. Could be argued as § 102 prior art against claim 5 (defining access-control rules specifying what is allowed to pass through network units) and possibly claim 1 (identifiers = source/destination addresses used to identify communications; secure transfer). It does not disclose group-of-entities selection for a VPN or the local-network→public-network address-translation configuration that is the core of claim 1.

2. US 5,623,492 — Teraslinna

• Full citation: U.S. Patent No. 5,623,492, "Methods and systems for managing bandwidth resources in a fast packet switching network," inventor Kari Tapio Teraslinna; assignee MCI/Qwest Communications International Inc.
• Dates: Filed 1995-03-23; issued 1997-04-22.
• Description: A bandwidth-resource-management method for fast packet switches. Packets carry an address field identifying provisioned virtual connections. The patent explicitly discusses implementing a virtual private network by provisioning permanent virtual connections between N subscribers (N(N−1) one-way connections), and enforces bandwidth constraints per source endpoint.
• Potential § 102 relevance: Weak. It uses the term "virtual private network" but in the sense of provisioned permanent virtual circuits in a carrier network — not an encrypted VPN over a public/insecure network configured by a management station. It does not disclose entity selection, identifiers, address translation, or encryption/authentication parameters. Not a credible § 102 reference against any of claims 1–27 as I read them.

3. US 5,835,726 — Shwed et al. (Check Point)

• Full citation: U.S. Patent No. 5,835,726, "System for securing the flow of and selectively modifying packets in a computer network," inventors Gil Shwed, Shlomo Kramer, Nir Zuk, Gil Dogon, Ehud Ben-Reuven; assignee Check Point Software Technologies Ltd.
• Dates: Filed 1996-06-17; issued 1998-11-10. (Term statutorily limited by US 5,606,668, of which it is a continuation.)
• Description: Continuation-in-concept of the '668 patent. A graphically defined rule base (source, destination, service, accept/reject, log) is compiled into filter-language instructions. An inspection engine on a firewall accepts/rejects, and may then modify accepted packets — modification including encryption, decryption, signature generation/verification, and address translation. The abstract expressly states: "This permits the use of insecure public networks in constructing a WAN that includes both private and public network segments, thus forming a virtual private network."
• Potential § 102 relevance: The most relevant cited reference. It expressly recites (i) encryption-based VPN formation over an insecure public network, and (ii) address translation as a packet modification performed per the rule base. Arguably relevant to claim 1 (secure transfer; identifiers = addressed source/destination; address translation), claim 5 (rule base = access-control rules), and claim 7 (IP-address identifiers). It does not disclose selecting entities into groups and assembling groups into a VPN, nor configuration by a centralized VPN manager of remote VPN units, so claims 3, 4, 12, 13, 16's "selection mechanism," and 27 appear to remain distinguishable.

4. US 5,918,018 — Gooderum et al.

• Full citation: U.S. Patent No. 5,918,018, "System and method for achieving network separation," inventors Michael R. Gooderum et al.; assignee 3Com Corporation.
• Dates: Issued 1999-06-29. Filing date not positively verified in this session (my tool budget expired before I could retrieve the face page; I identified the title/assignee/issue date from the Unified Patents listing but did not confirm the filing date — flagging this rather than guessing).
• Description: Directed to separating an internal network from an external network (network separation / isolation), by the title itself.
• Potential § 102 relevance: Because it issued after the 1998-04-17 filing date, it could only be prior art under pre-AIA § 102(e), and only if its filing date precedes 1998-04-17. Weak substantive overlap: it addresses separating networks rather than the claimed selective, identity-based secure transfer with configurable VPN entity groups and address-translation rules. Plausibly relevant, at most, to the "access control / separation" flavor of claim 5. Low confidence pending filing-date confirmation.

5. US 5,968,176 — Nessett et al.

• Full citation: U.S. Patent No. 5,968,176, "Multilayer firewall system," inventors Danny M. Nessett et al.; assignee Hewlett-Packard Company.
• Dates: Filed 1997-05-28; issued 1999-10-19.
• Description: A firewall system applying security policy across multiple protocol layers (network/transport/application), with layered filtering rules.
• Potential § 102 relevance: Because it issued after the 1998-04-17 filing date, it qualifies only as pre-AIA § 102(e) prior art (filing date 1997-05-28 predates the applicant's filing). Its layered access-control approach is arguably relevant to claim 5 (defining access-control rules) and, more loosely, to the "identification mechanism" concept in claim 16. It does not disclose VPN entity-group selection or the local-to-public address-translation configuration of claims 1/6/13/15/21.

Foreign Patent Documents

6. WO 95/01023 A1 — Ascom Timeplex Trading AG

• Full citation: International (PCT) Publication WO 95/01023 A1, "Hub for segmented virtual local area network," applicant Ascom Timeplex Trading AG.
• Dates: Priority/filed 1993-06-16; published 1995-01-05.
• Description: A hub supporting a segmented virtual local area network (VLAN).
• Potential § 102 relevance: Pre-dates the filing by years and qualifies under § 102(a)/(b). It is the only cited reference squarely about grouping/segmenting network entities in a "virtual" network context, so it is the most plausible § 102 candidate for the group-of-entities limitations in claims 3, 4, 18, and 19, and the group-selection portion of claim 13. However, a segmented VLAN hub is a Layer-2 LAN segmentation device — it does not disclose secure (encrypted) transfer over a public data network, nor the local-to-public address translation of claim 1. So at most a partial teaching, not full anticipation of any independent claim.

7. WO 97/00471 A2 — Check Point Software Technologies Ltd.

• Full citation: International (PCT) Publication WO 97/00471 A2, "A system for securing the flow of and selectively modifying packets in a computer network."
• Dates: Published 1997-01-03 (qualifies under § 102(a)/(b), before 1998-04-17).
• Description: The PCT counterpart to the Check Point invention described in US 5,835,726 (Shwed et al.), with the same substance: rule-base-driven packet inspection and selective modification including encryption and address translation, forming a VPN over public network segments.
• Potential § 102 relevance: Same analysis as US 5,835,726: strongest candidate against claims 1, 5, and 7; does not reach the entity-group-assembly and centralized VPN-manager configuration features.

Consolidated § 102 mapping

Bottom line on anticipation: No single cited reference appears to disclose the full combination recited in independent claims 1, 13, 16, or 27 — namely, receiving selections of entities, assembling them into groups, defining local-to-public address-translation rules at VPN units, using identifiers to identify communications, and securely transferring with translation applied. The Shwed/Check Point references (US 5,835,726 and WO 97/00471) come closest because they expressly combine encryption-based VPNs over insecure networks with rule-driven address translation, but they lack the "selected entity/group configured by a centralized VPN manager" architecture that distinguishes the granted claims. This is consistent with the claims having issued over these references.

Caveats and recommended verification steps

1. The face-of-patent reference list was reconstructed from secondary sources (uspto.report and Unified Patents), not read directly off the USPTO/PatentCenter page. Confirm against the official front page.
2. US 5,918,018's filing date is unverified — I could not retrieve its face page before exhausting my tool budget. Its § 102(e) eligibility depends on that date. I have flagged rather than guessed it.
3. These references were considered and the claims allowed over them. Any § 102 statement above is an analytical hypothesis, not a record of an actual rejection. To see whether any reference was applied in a rejection (and how it was overcome), pull the file wrapper / prosecution history for application 09/062,507 from USPTO PatentCenter.
4. Non-patent prior art was not assessed here and could exist (e.g., IETF/IPSEC, PPTP/L2TP drafts, firewall and VPN product literature from 1995–1998). The face-of-patent citation list contains only patent documents, so any § 102 challenge on non-patent literature would come from outside this list.
5. Related application, not prior art: The specification cites co-pending application Ser. No. 09/013,743 (Liu, "Method and apparatus for managing a virtual private network," filed 1998-01-27), and US 6,701,437 is a continuation-in-part of this family (filed 1998-11-09). These are common-ownership relatives of the same invention and are not § 102 prior art against US 6,226,751.

If you want, I can, in a follow-up pass, (a) retrieve the official USPTO front-page citation list and prosecution history for application 09/062,507, and (b) verify the US 5,918,018 filing date — both of which would let me firm up the two flagged items above.

I'll research the prior art references cited on the US 6,226,751 page before building the § 103 analysis.

I have the cited prior art from the patent's own record. Let me pull details on each reference to ground the combination analysis.

Obviousness Analysis — US 6,226,751 B1 under 35 U.S.C. § 103

0. A necessary evidentiary note before the analysis

Cross-reference / contradiction flag. The authoritative full text of US 6,226,751 B1 supplied for this analysis (fetched from Google Patents) does not contain a "References Cited / Prior Art" table. The text cuts off inside the forward-citation table ("Cited By (139)") at US7376828B1. What is present is a forward-citation list (later patents citing '751), which is not prior art to a 1998-04-17 filing.

Therefore, for the "prior art section of this page" I have used the examiner/applicant citation list for the same patent as recorded on the Unified Patents bibliographic page for US-6226751-B1, which lists "Patent Art (7)" — i.e., the seven documents cited against '751. I flag explicitly: this is a substitute source, and it may not be byte-identical to Google's "Patent Citations" table for '751. Where I could independently corroborate a reference (title, inventor, dates, disclosure), I say so and give the URL. Where I could not fully verify a reference's content (I hit a search-step limit), I mark it lower confidence.

Bibliographic discrepancies between sources (recorded literally, not auto-corrected):

Also note the Unified Patents page (possibly erroneously) lists "Priority Date: 1998-04-16" and "Application Date: 1998-04-16." Per the operating rule, I treat 1998-04-17 (the Google Patents value, consistent with application Ser. No. 09/062,507) as the critical date for § 102/§ 103 purposes, but the one-day offset does not change any conclusion below.

Litigation. Consistent with the previously generated litigation section: no litigation, ITC, PTAB, or Federal Circuit matter naming US 6,226,751 was found. This matters for this task because there is therefore no adjudicated claim construction, no validity ruling, and no objective-indicia record to draw on — all of the constructions below are mine, applying the ordinary-and-customary-meaning standard (pre-AIA claims; Phillips v. AWH, 415 F.3d 1303 (Fed. Cir. 2005)), and obviousness is in any event a question of law on which this memo offers only the underlying technical findings.

1. The invention to be evaluated

'751 is a configuration/management patent, not a packet-processing patent (that is its CIP sibling, US 6,704,307, filed 1998-11-09). The independent claims are:

• Claim 1 — method: (a) receiving selections of "a plurality of entities coupled to the public data network" to include in the VPN; (b) the entities reside on local networks and are addressed by local network addresses; (c) assembling a plurality of identifiers for those entities; (d) defining address translation rules for VPN units, "the virtual private network units using the address translation rules to translate local network addresses for the local networks into corresponding addresses on the public data network"; (e) using the identifiers to identify communications between the entities; (f) transferring the communications securely; and (g) "wherein transferring the communications involves using the address translation rules to translate local network addresses into addresses on the public data network."
• Claim 13 — method: claim 1's elements restricted to groups ("assembling entities into groups of at least one entity, and selecting groups"), each group associated with a VPN unit, plus "defining encryption, authentication and compression parameters."
• Claim 16 — apparatus: VPN manager + "selection mechanism" + VPN unit + "identification mechanism" + "secure communication mechanism" + address-translation-rule definition.
• Claim 27 — Beauregard-style program storage device performing claim 1's method.

Dependents of note: 2/17 (encryption + authentication + compression parameters); 3/18 and 4/19 (grouping; group↔VPN-unit association); 5/20 (access control rules specifying types of communications allowed through VPN units); 6/15/21 ("multiple entities through a single Internet Protocol (IP) address" — i.e., NAPT/port translation); 7/22 (identifiers include an IP address); 8/23 (identifiers include a user identifier); 9–11/24–26 (entity = computer system, computer user, remote client); 12 (selection received at a centralized VPN manager on the public network).

Preamble note. "For establishing a virtual private network for facilitating secure communications…" is a statement of intended purpose; it does not import a separate structural requirement. The only "secure" limitation of substance is claim 1(f)/(g) plus the express encryption/authentication/compression limitations in claims 2/13/17.

2. Level of ordinary skill in the art (POSITA)

A POSITA as of 1998-04-17 would have a bachelor's degree in electrical engineering, computer engineering, or computer science, and approximately two years of experience in data networking and network security, or equivalent experience. That person would be familiar with: IP packet routing; packet-filter firewalls and rule bases; tunneling/encapsulation; the then-current IETF security work (RFC 1825–1829 IP security architecture, AH/ESP, key management, SKIP/ISAKMP); NAT/NAPT (RFC 1631, May 1994); RADIUS (RFC 2058, Jan. 1997; RFC 2138, Apr. 1997); VLAN segmentation (IEEE 802.1Q work in progress; the Ascom Timeplex art below); and SNMP-based network management (which the '751 spec itself invokes at SNMP module 720). Additional experience can substitute for education and vice versa.

This level is deliberately modest; '751's disclosure is at an architectural/functional level and expressly disclaims any one particular implementation ("The present invention is not limited to any one particular implementation technique").

3. The cited prior art (the seven documents)

All seven pre-date the 1998-04-17 filing, so all are available as prior art. Notes on the statutory basis are given because two of them issued after the filing date and therefore rely on § 102(e).

Same-family / same-assignee note. A1, A2 and A3 are the same Check Point work (A2 is a CIP that expressly "seeks to provide an improved flexible, easily-alterable security method which controls information flow on a computer network to that described in copending coassigned U.S. patent application Ser. No. 08/168,041" — i.e., A1). Combining a reference with its own parent/child is not a "combination of separate references" in any meaningful sense; the later member simply supplies the added disclosure. See MPEP 2131 and the general treatment of continuing applications.

4. Ground 1 — Shwed '726 (A2/A3) alone, or A1+A2, renders claims 1, 13, 16 and 27 obvious

This is the strongest ground, because A2 is close to a full anticipation of the independent claims' technical content; the only thing that saves '751 is the claim framing ("receiving selections" by a manager, and the "address translation rules" being defined for VPN units) — and A2's GUI/rule-base/"INSTALL ON GATEWAYS" architecture supplies even that.

4.1 Claim 1

Result. Every element of claim 1 is disclosed by A2, and the residual "configuration" character of the claim is met by A2's centralized rule-base generation with an "INSTALL ON: GATEWAYS" distribution step. At minimum, A1+A2 render claim 1 obvious.

4.2 Claim 13

Claim 13 = claim 1 restricted to groups + group↔VPN unit association + encryption, authentication and compression parameters.

• Groups: A2's Network Object Manager explicitly supports GROUP objects and named groups; A1's rule language matches "network objects," and A2's rule base includes rules keyed to groups (e.g., rule 3 "TRUSTEDPARTIES → INTERNAL: ACCEPT"; rule 5 "ANY → INTERNAL: REJECT"). Ascom Timeplex A4 independently teaches segmentation of a LAN into virtual LANs, i.e., logical grouping of nodes for isolation.
• Group ↔ VPN unit: A2's rule base has an "INSTALL ON" column populated with "GATEWAYS", and per-rule targeting to specific gateways — that is, a group's rule/VPN association is bound to a specific VPN-unit/firewall. A5 (Secure Computing) states the concept at a higher level: "Regions let you group both physical interfaces (network cards) and Virtual Private Networks (VPNs) into areas of similar trust and security needs."
• Encryption + authentication: A2 expressly (key management panel: CYPHER METHOD, KEY METHOD, MD METHOD, public key IDs, CHALLENGE KEY C, SIG(R)) — encryption and message-digest/signature authentication.
• Compression: this is the one limitation not clearly in A1–A7. See § 8.

4.3 Claim 16 (apparatus)

Claim 16 therefore adds nothing structural beyond claim 1's substance expressed as means-plus-function-style modules (none of the claim-16 elements is drafted in § 112(6) "means" form, so they are construed as the corresponding structures disclosed in '751's FIG. 7 — VPN management station 160, command handler 506, collator 508, address translation unit 731 — each of which has an A2 counterpart).

4.4 Claim 27 (program storage device)

Claim 27 recites only "storing instructions that when executed by a computer perform a method …" — the claim's patentable weight is entirely in the method steps (which are claim 1's). If claim 1 is obvious, claim 27 is obvious: storing software on a known computer-readable medium was routine and predictable. In re Beauregard, 53 F.3d 1583 (Fed. Cir. 1995). Caveat: claim 27's drafting raises § 112/§ 101 questions (the cited text contains no "non-transitory" language), but that is a separate invalidity theory, not a § 103 point.

5. Ground 2 — Adding the group/access-control references (claims 3, 4, 5, 14, 18, 19, 20)

The '751 specification's own example of claim 5/20 — "communications between non-members of a VPN and members of the VPN are not allowed to pass through a particular VPN unit" — is the direct analogue of A2's rule 5 ("ANY → INTERNAL: REJECT") and of A5's region policies.

6. Ground 3 — Address translation down to a single public IP (claims 6, 15, 21)

Claims 6/15/21 recite that "the address translation rules facilitate communicating with multiple entities through a single Internet Protocol (IP) address." This is NAPT / port-level multiplexing, which the '751 specification itself describes: "mapping multiple local addresses to a single public network address … by using the same public network address with different port identifiers for different local addresses."

• A2 supplies the architecture (address translation performed by the firewall under rule-base control) and the motivation ("interconnect various networks with different addressing schemes"). But A2 does not, on the face of the cited disclosure, recite many-to-one translation with port differentiation.
• The natural secondary reference is RFC 1631, "The IP Network Address Translator (NAT)," Egevang & Francis (May 1994) — which teaches exactly the many-to-one, source-port-differentiated translation — plus the large NAT patent family of the mid-1990s (e.g., the "Network Address Translation" work later invoked by In re the IBM "NAT integration with IP security" filings visible in the citation data at US 20030149899A1).
• Caveat (explicit): RFC 1631 and the NAT/NAPT family are not in the seven-document cited set. A challenger relying only on the documents of record would have to show that port-multiplexed translation was a known technique applied in a predictable way (KSR rationale (C)/(D)), which I assess as straightforward but which is the weakest documentary link for claims 6/15/21. I flag this honestly rather than asserting a mapping I cannot cite.

7. Ground 4 — The identifier-type claims (claims 7–11 / 22–26, and claim 12)

8. The compression limitation — the one real documentary gap (claims 2, 13, 17)

Claims 2/17 require "defining encryption, authentication and compression parameters"; claim 13 embeds the same. A1–A7 supply encryption and authentication abundantly (A2's cypher/MD/key methods, signatures; A5's policy engine; A6's filters), but I could not locate a compression teaching in the cited seven documents — A7 (bandwidth resource management in a fast packet switch) is about admission/bandwidth allocation, not payload compression, and I could not verify any compression disclosure in it.

Consequences:

1. The combination for claims 2/13/17 must be supplemented either by (i) A7 as interpreted more broadly than its title suggests (low confidence — I did not verify), or (ii) the knowledge of a POSITA that WAN links routinely used link/network-layer compression (e.g., PPP compression, RFC 1974; LZW; the LZ77/LZ family). This is a proper KSR "known technique" rationale, not a documentary anticipation.
2. But note the applicant's own admission. The '751 specification states: "…whether or not data packets transferred between members of the particular VPN are to be compressed, and if so, what algorithm is used for compression. Many possible compression algorithms are well known … in one embodiment of the invention, LZW compression is used." That admission (a) concedes compression was well-known, and (b) reduces the claim-2/17 "compression parameter" to a routine design choice — which is exactly the KSR rationale (F) (design incentives) and MPEP 2144.02 (obvious design choice). So even the weakest limitation falls.

Net: claims 2 and 17 are obvious over A1+A2 in further view of the admitted well-known compression algorithms and/or a compression teaching (RFC 1974 / LZW), and claim 13 is obvious for the same reason plus its group elements.

9. Where a § 103 case is genuinely weak (honest assessment)

I do not want to overstate. The following are the soft spots a patent owner would attack, and my candid assessment:

1. A7 (US 5,623,492) mapping. I could not verify that its "bandwidth resources in a fast packet switching network" content maps onto any '751 claim element. Its role in the citation list may have been as a general packet-switching background reference. I would not build a ground on A7. Confidence: low.
2. A4 (WO 95/01023, Ascom Timeplex VLAN hub). Title and dates are corroborated, but I could not open the specification; the "segmented virtual LAN" concept supports grouping/VLAN isolation generally, but I cannot quote specific passages. Use as corroboration, not as the primary group reference. Confidence: medium.
3. A6 (US 5,968,176, HP multilayer firewall). Its issue date (1999-10-19) is after '751's filing, so it is prior art only under § 102(e) as to subject matter present in its 1997-05-28 US application. I corroborated its title, date, "firewall engine with installed filters/policy" architecture, and its use as prior art in later prosecutions — but I did not open the full US text. Treat as a § 102(e) reference. Confidence: medium.
4. A5 (US 5,918,018 / Secure Computing family). The US patent's earliest priority (Feb. 1996) pre-dates '751, so § 102(e) is available for its commonly-disclosed subject matter; but I sourced the "regions include VPNs / embedded VPN support" language from a same-family PCT publication (WO 1999/048261 A2), not from the US patent text itself. A challenger must confirm that the US disclosure carries the region/VPN grouping subject matter. Confidence: high on the family, medium on the specific US-text mapping.
5. Claims 6/15/21 (single-IP multiplexing). Needs NAT/NAPT art (RFC 1631 et al.) that is outside the cited set.
6. No secondary considerations are documented. Since no litigation was found, there is no evidence of commercial success, copying, long-felt need, or licensing tied to '751. Under Graham v. John Deere Co., 383 U.S. 1 (1966), and Stratoflex v. Aeroquip, 713 F.2d 1530 (Fed. Cir. 1983), that means the objective-indicia factor is (on the current record) neutral, and the patent owner would bear the burden of production on any nexus-bearing evidence.

10. Motivation to combine — why a POSITA would have made these combinations

Under KSR Int'l Co. v. Teleflex Inc., 550 U.S. 398 (2007), and MPEP § 2143, the motivations here are unusually clear-cut:

(a) Same field / analogous art. A1, A2, A3, A5, A6 are all network security/firewall references; A4 is LAN segmentation; all are reasonably pertinent to the problem '751 addresses (secure inter-site communication over an untrusted network). The field-of-endeavor and "reasonably pertinent to the particular problem" tests are both satisfied. In re Bigio, 381 F.3d 1320 (Fed. Cir. 2004).

(b) The market/incentive motivation is in the references themselves. A2 states the problem and the solution in the same breath: enterprises had used "dedicated point-to-point connections" which were inflexible and expensive; "public networks such as the Internet provide a flexible and inexpensive solution"; a VPN "is significantly less expensive and more flexible than a dedicated private network"; and A2's invention supplies the missing security by "encrypting communications between two firewalls … thus forming a virtual private network." '751's own Background recites verbatim the same problem. A POSITA seeking to build an enterprise VPN over the Internet would predictably start from the Check Point rule-base/firewall architecture, because it already: (i) forces all traffic through controlled points, (ii) matches on source/destination/service identifiers, (iii) modifies accepted packets (encrypt/authenticate/translate addresses), and (iv) is centrally configured and pushed to remote enforcement points.

(c) Combining the Check Point references with each other is not a "combination" at all. A2 is a CIP of A1; A3 is the PCT publication of the same subject matter. A2's own text frames itself as an improvement to A1 for the express purpose of VPNs. This is the KSR rationale of "use of a known technique to improve a similar device in the same way" taken to its limit, and MPEP 2131's treatment of parent/child disclosures.

(d) Grouping and access-control references. A4's virtual-LAN segmentation and A5's regions/policies are the standard, well-understood mechanism for expressing "who may talk to whom" in network management, and they solve the same problem ('751's stated need to let finance communicate securely while excluding engineering). A POSITA would adopt group/scoping objects because (i) A2's own GUI already exposes GROUP objects, and (ii) policy at the group level dramatically reduces rule count — an express benefit A5 articulates ("you eliminate the need to enter multiple versions of the same access rule for each network or VPN"). That is a credible, articulated, functional motivation, not hindsight.

(e) Address translation. Once the packets traverse a public network, there is an immediate, well-known need to reconcile private, non-unique local addressing with globally routable addressing; A2 anticipates it by listing address translation among its rule-driven modifications and by targeting "networks with different addressing schemes." A POSITA combining A2 with the well-known NAT/NAPT technique (RFC 1631) arrives at claim 6/15/21 predictably: the combination is the application of a known technique to a known device, ready for improvement.

(f) Centralized management. A2/A1's "system administrator" + "INSTALL ON GATEWAYS," and A6's policy-managed multilayer firewall, supply claim 12's "centralized site" selection in a way that is the whole point of rule-base management — pushing configuration to distributed enforcement points is a known technique used for the known purpose of reducing administrative cost, with predictable results (KSR rationale (C)).

(g) Compression. Applying link/network-layer compression to WAN traffic was a matter of design choice, and '751 admits the algorithms were "well known" (LZW, etc.). KSR/MPEP 2144.02.

Reasonable expectation of success. Every combination above is a combination of known network-security building blocks producing a predictable result — an enterprise VPN whose end-to-end behavior (encrypted, authenticated, address-translated traffic between identified members, centrally configured) is exactly the sum of the parts. Nothing in '751 alleges, and nothing in the record shows, any unexpected result or criticality of any parameter.

11. Summary chart — claim → § 103 ground

Bottom line. On the documents cited against US 6,226,751, claims 1, 3–5, 7, 9–10, 12–14, 16, 18–20, 22, 24–25 and 27 are, in my technical judgment, obvious over the Check Point Shwed references (US 5,835,726 and US 5,606,668 / WO 97/000471), alone or in view of Ascom Timeplex WO 95/01023 and Secure Computing US 5,918,018 (and HP US 5,968,176 for the type-of-communication filtering claims). Claims 2, 13 and 17 hinge on the compression limitation, which is met by the applicant's own admission of well-known compression algorithms (LZW) plus KSR "obvious design choice," and claims 6, 15 and 21 require NAT/NAPT art outside the cited set (RFC 1631 family). The main vulnerability of the entire challenge is documentary rather than conceptual: the seven cited references give an excellent case on claims 1/13/16/27, but four of the dependent-level features (compression parameters, many-to-one address translation, user-ID identifiers, remote clients) need supplementation from art the Examiner did not cite.

12. Explicit confidence and residual-uncertainty statement

• High confidence: the identity, dates, and disclosure of US 5,835,726 (Shwed et al.) and US 5,606,668 (Shwed); the mapping of those two documents to claim 1, claim 13 (minus compression) and claim 16.
• Medium confidence: US 5,918,018's US-text disclosure of regions grouping interfaces and VPNs (I read the same-family PCT publication, not the US text); US 5,968,176's exact filter/policy disclosure; WO 95/01023's specification content; the precise identity of the seven documents as the examiner's citation list for '751 (I sourced them from Unified Patents' "Patent Art (7)" because the fetched Google Patents text lacks a references-cited table — see § 0).
• Low confidence: any mapping of US 5,623,492 to '751's claims; I could not verify it and would not rely on it.
• I did not run a PTAB/PAIR prosecution-history check for the actual examiner citations and § 102(e)/§ 103 rejections during prosecution of Ser. No. 09/062,507, nor did I confirm whether the "Prior Art" listing on the live Google Patents page matches the Unified Patents list. Those verifications (Google Patents "Patent Citations" table; USPTO PatentCenter IFW for Ser. No. 09/062,507; and the examiner's Notice of References Cited) would be the correct next step to lock the record down before this analysis were used in any adversarial paper.