US 6584508

I'll verify details against live sources, then summarize.

Verification note

I cross-checked the patent text you supplied against Google Patents, Justia, FreePatentsOnline, and the USPTO-hosted PDF. All bibliographic fields below are consistent across those sources. I did not find any CAFC (or district court) docket that names U.S. 6,584,508 — see the "Litigation check" section for the limits of that negative finding.

Bibliographic summary — US 6,584,508 B1

Abstract (as issued): A system and method for increasing the security of a data guard. The guard is based on a multi-part proxy comprising a first proxy agent communicating with an inside network region, a second proxy agent communicating with an outside network region, and a content-based filter application reviewing information passed between the two proxy agents. Both proxy agents can be based on existing firewall proxies. The proxy agents listen for protocol operations (e.g., IIOP requests or replies) and translate them into protocol-independent data, which the protocol-independent content-based filter then analyzes. The behavior of the multi-part proxy can be further constrained through software wrapper technology.

Plain-language overview of the independent claim

Claim 1 recites a computer system (a single machine) that acts as a security barrier between two network regions. Mapping it element by element:

1. GUI-driven configuration. A graphical user interface presents a template to a user and receives "content limitations" — expressly defined as rules and values — through that template. This is a distinctive hook: the filtering policy is entered by a non-programmer through a template, not hand-coded.
2. Two application-level proxy agents. A first proxy agent talks to the first (inside) network region; a second proxy agent talks to the second (outside) network region. Both are expressly limited to application-level proxy agents.
3. A protocol-independent content filter in the middle. A content-based filter application reviews information passed between the two proxies. It is expressly a protocol-independent analysis application, and the manner in which it reviews information is user-configurable using the GUI-supplied rules and values.
4. Independent software wrappers. One or more software wrappers constrain the behavior of each of the first proxy, the second proxy, and the content filter — i.e., each component is separately wrapped (this is the "independently wrapped components" of the title).
5. Interchange format. The two proxies generate and pass files to the content filter; the files include extensible markup language (XML) code.
6. Shared memory. The proxies also pass information to the content filter using shared memory.
7. Modification/sanitation. The content filter modifies the information based on its review (the spec calls this "sanitation," e.g., excising profanity or "fizzing" values).
8. Queuing. Components positioned between the two proxies and the content filter are queued and dequeued (corresponding to the FIG. 7 queue/dequeue programs).
9. COTS operating system. All three components run on a commercial off-the-shelf operating system.
10. Intrusion-detection alerts. The content filter generates application-specific alerts for an intrusion detection system in response to its review, based on the rules and values of the content limitations.

Key drafting observation: the issued claim 1 is a notably narrow, "kitchen-sink" claim. The file-transfer mechanism, XML, shared memory, queuing/dequeuing, COTS OS, the GUI template, and IDS alerting are all positive limitations, not alternatives. Practically, this means infringement requires essentially the whole FIG. 5/FIG. 7 architecture plus the GUI template front end. (Note also the literal typo in the printed claim: "between said first and sad second proxy agents" — I am reporting it as printed, not correcting it.)

Dependent claims (context only, not independent claims)

• Claim 2: the application-specific alerts are user-configured.
• Claim 3: the content limitations are reviewed to ensure they meet organizational security requirements.
• Claim 4: the content limitations relate to a monetary transaction.
• Claim 5: (depending from claim 4) the content limitations relate to a bank transaction — tracking the specification's worked example of graduated alerts for deposit amounts ($1,000 / $10,000 / $100,000 / $1,000,000 thresholds).

There is only one independent claim; the preamble-plus-limitations structure above is the entire independent scope.

Litigation / docket check — and its limits

• I searched for U.S. 6,584,508 styled as "the '508 patent," "6584508," and "6,584,508" in combination with Networks Associates, McAfee, CAFC, PTAB, IPR, and infringement terms.
• No district court complaint, PTAB petition, or CAFC appeal naming U.S. 6,584,508 was found. Every "'508 patent" or "'508" hit in the search results belongs to a different patent number — e.g., US 7,653,508 (Uniloc, IPR2018-00387), US 6,961,508 (Corning), US 6,441,508 apparently unrelated, and the Hilgraeve v. McAfee line concerning U.S. 5,600,776. Those results do not relate to U.S. 6,584,508.
• Uncertainty statement: I could not query the CAFC CM/ECF or USPTO PatentCenter/PTAB APIs directly; my search was web-mediated, and CAFC 2026 docket sheets are not fully indexed by general web search. So I can say confidently that no litigation surfaced, but I cannot certify that no litigation exists. Given the patent's status (expired fee-related as of 2019-12-30, roughly six-plus years before the current date), a 2026 CAFC appeal on this patent would be unusual, since appeals generally require a live dispute and pre-expiry infringement window.
• The patent is cited as prior art in later documents (e.g., it appears in the reference lists of US 9,118,711 and WO 2012/113596), which is consistent with it being an expired, non-asserted reference rather than an asserted patent.

Caveats on the record

• Assignee history is reported from Google Patents' reassignment records; the "current assignee" field warns it may be inaccurate and is not a legal conclusion. McAfee, LLC is the listed current assignee.
• The priority date of 1999-07-13 and the anticipated expiration of 2019-12-30 are flagged by the source as assumptions, not legal conclusions.
• The specification's core technical narrative (multi-part proxy split into inside proxy, outside proxy, and protocol-independent content filter; three wrappers — one for the proxies, one for the queue/dequeue programs, one for the content filter; data sealing via digital signatures on imported data) is fully consistent across the Google Patents text, Justia, and FreePatentsOnline, so I have high confidence in the technical description.

I'll search multiple litigation-tracking sources for US 6,584,508.

Let me search litigation-specific databases with the exact patent number format.

Let me check patent-specific litigation databases and other angles.

Answer: No litigation found involving U.S. Patent No. 6,584,508

I ran multiple targeted searches for the exact number in both formats ("6584508" and "6,584,508") combined with litigation-oriented terms (infringement, lawsuit, McAfee, Network Associates, docketalarm, Justia, Unified Patents, Google Patents litigation). I located no district court case, ITC investigation, CAFC appeal, or PTAB/post-grant proceeding in which U.S. Patent No. 6,584,508 is identified as an asserted, challenged, or adjudicated patent.

Because no case exists to report, I cannot supply plaintiff, defendant, jurisdiction, case number, filing date, or outcome. I want to be explicit that this is a "not found" result rather than an affirmative representation that no litigation ever existed — see the caveats below.

What the sources did show about the patent

• Ownership chain (relevant to any would-be plaintiff): Original assignee Networks Associates Technology, Inc.; assignments recorded to Networks Associates, Inc. (1999‑12‑30 filing), Networks Associates Technology, Inc. (2002‑02‑19), and McAfee, Inc. (2007‑09‑18). Current listed assignee: McAfee LLC. Any suit would most likely have been brought by one of these entities.
• Term / status: Priority date 1999‑07‑13 (provisional 60/143,553); filed 1999‑12‑30; granted 2003‑06‑24. Google Patents lists "Anticipated expiration 2019‑12‑30" and legal status "Expired – Fee Related." The patent is past term, which materially reduces the likelihood of historical or future assertion.
• Google Patents page shows no "Litigation" section for US6584508; it shows only "Cited By" and "Citations" lists (those are prior‑art/scholarly citations, not lawsuits). Likewise, the Unified Patents litigation caselist and RPX Insight did not surface this patent in the results indexed by my searches.

Numbers I encountered that are NOT this patent (do not conflate)

Per the literal-interpretation rule, I flag these look-alikes rather than silently discarding them:

• EP search report citation "US 6584508 P 20080215" — appears as a reference on EP 2090820 (LED lighting). It is a citation, not evidence of litigation, and the cited document/date does not obviously correspond to the 2003 grant of our patent.
• "U.S. Registration No. 6584508" — a trademark registration (URBAN EYEWEAR, New York Optical‑International, Inc.), unrelated.
• Lithuanian registry notice no. 6584508 and Turkish patent‑attorney person no. 6584508 — administrative identifiers, unrelated.
• "the '658 Patent" in Dynapass IP Holdings LLC v. Regions Financial Corp. et al. (E.D. Tex. 2022) and "the '508 patent" in MCOM IP litigations — these are different patents whose numbers merely end in 658/508; they are not U.S. 6,584,508.

Caveats and recommended verification

• I could not directly query PACER or the CAFC docket system, or run a paid Docket Alarm / Lex Machina / RPX search; my access was via general web search. A negative public‑web result does not rule out a sealed, settled, or old case, or one in which the patent is mentioned but not indexed textually.
• The patent's 2019 expiration means any enforcement activity would have had to occur roughly between 2003 and 2019, further narrowing (and making less likely) any case.

Suggested next steps for definitive confirmation:

1. Run the patent number in USPTO Patent Public Search / Global Dossier "Litigation" and assignment records.
2. Search PACER Case Locator and CourtListener/RECAP (free) for full‑text "6,584,508."
3. Check Lex Machina, Docket Navigator, or RPX Insight (which expressly track asserted‑patent histories) under assignees "Networks Associates Technology" and "McAfee."
4. Search PTAB (IPR/PGR/CBM) and ITC EDIS for the patent, as post‑grant and Section 337 actions also count as "known litigation."

If you'd like, I can draft the exact query strings for those paywalled/authenticated databases.

PTAB / AIA Trial Proceedings — US 6,584,508 B1

Verification approach: I sourced the proceedings list from the structured "PTAB proceedings on file" block (USPTO Open Data Portal, most recent ingest) and independently re-ran web searches against PTAB decision text, PTABS petition records, Docket Alarm PTAB dockets, and general web indices for the patent number, the title, and the lead inventor. The two sources agree.

Proceedings overview

There are ZERO AIA trial proceedings on file against US 6,584,508 B1 — no IPR, no PGR, and no CBM review, at any stage of completion: none instituted, none denied, none settled, none terminated. Consequently there are no canceled claims, no sustained claims as adjudicated by the Board, no FWDs, and no Federal Circuit appeals arising from PTAB proceedings. The defensive posture this gives a defendant is not "hardened patent" or "invalidated patent" — it is "unlitigated and unenforceable paper": the patent expired (Google Patents records "Expired – Fee Related," with anticipated expiration 2019-12-30), so the correct response to any demand letter citing claims 1–5 is that no live infringement liability can attach, and there is no PTAB record to litigate about either way.

Proceedings

None. There is no proceeding to describe at the required per-proceeding granularity. I decline to construct a template with fabricated proceeding numbers, panels, or dispositions; instead, here is the negative finding and its evidentiary basis.

What I searched (2026-09-27)

Collision warning (important for anyone repeating this search): the string "6584508" is not unique. It appears as (a) a provisional application serial number in EPO records (US 6584508 P), (b) a live US trademark registration number, and (c) a foreign administrative ID. Any search hit must be validated against "US 6,584,508 B1, Networks Associates Technology, Inc., Advanced data guard having independently wrapped components" before it is credited. Every "508" IPR I surfaced belongs to a different patent.

Limits of this negative finding: I could not issue direct API calls to PTAB E2E / PTAB Center or CM/ECF; the finding is web-mediated against indexed PTAB decision and petition text. CBM petitions (available 2012-09-16 to 2020-09-16) were, however, extremely well indexed in the same corpora — a CBM on a 1999-issued-family security patent would almost certainly have surfaced. I also note that no PTAB activity would be expected here: see the strategic summary.

Strategic summary

Claim status: every claim untested — and moot. Claims 1–5 of US 6,584,508 have never been before the Board. None is canceled; none is judicially sustained. That is not a sign of robustness but of irrelevance: the patent was never asserted in a district court or ITC action that I could find (consistent with the earlier litigation check in this analysis), so no petitioner ever had a § 315(b) one-year trigger or a commercial reason to file. A patent that expires without ever being asserted tends to generate no IPR, and that is exactly the pattern here. The added wrinkle is that the earlier analysis flagged the independent claim as a narrow, "kitchen-sink" claim (GUI template + rules-and-values content limitations + two application-level proxies + protocol-independent filter + XML files + shared memory + queue/dequeue + COTS OS + IDS alerts, all conjunctively). A claim like that is comparatively easy to design around and would have been a favorable IPR target — which reinforces that the absence of IPRs reflects lack of assertion, not defensive strength.

Estoppel landscape: none exists, and none matters. Because there has never been an instituted IPR, § 315(e)(2) estoppel never attached to anyone. Any party facing a demand today retains the full universe of §§ 102/103/112 art, including art that could have been, but was not, petitioned. Practically this is academic: with the patent recorded as expired fee-related and the 20-year term running out on 2019-12-30, there is no live infringement window over which to fight. For completeness, the natural prior-art hooks that a hypothetical petitioner would have reached for are already embedded in the file: the applicant's own ARGuE Guard paper (J. Epstein, Architecture and Concepts of the ARGuE Guard, 15th Annual Computer Security Applications Conference, Dec. 1999), the Fraser et al. generic-software-wrappers paper cited in the specification, and the ISSE/C² Guard references. And the CBM door — the only AIA track that could have plausibly reached a network-security patent with monetary/bank-transaction dependent claims 4–5 — closed on 2020-09-16, before the patent's expiry, and no CBM was ever filed.

Pattern signals: essentially nil. No serial petitioner. No joiners. No defensive aggregator — I found no Unified Patents (or comparable) filing or membership-based challenge naming this patent. No patent-owner appeal activity, because there was no adverse Board decision to appeal. The only downstream footprint of this patent is forward citation: it appears in the reference/intent-to-cite lists of later documents (e.g., the Cited By set on Google Patents includes US 9,118,711 and WO 2012/113596), which is the normal fate of an expired, never-asserted reference. That citation footprint is a signal of technological relevance, not of assertion risk.

Recommended next steps

If you are a defendant receiving a demand that cites US 6,584,508:

1. Do not commission an IPR. There is nothing to invalidate that isn't already dead. The patent is recorded as expired; IPR of an expired patent is generally pointless (claims cannot be broadened, and no enforceable right remains).
2. Check the expiration theory carefully and in writing. Google Patents labels the status "Expired – Fee Related" and shows a 2019-12-30 anticipated expiration. Those two facts can point to different dates: 2019-12-30 is the 20-year term from the 1999-12-30 filing, whereas "fee-related" expiration usually means an earlier lapse for non-payment of a maintenance fee. This ambiguity matters only for fixing the last possible date of accrual — pull the maintenance-fee history from USPTO PatentCenter (https://patentcenter.uspto.gov/) to pin the actual lapse date. Flagging this explicitly: the structured source itself marks the expiration date as an assumption, not a legal conclusion.
3. Quote the negative PTAB record in your response. If the demand letter implies the patent has survived challenges or is "validated," that is unsupported: PTAB E2E (https://ptacts.uspto.gov/ptabweb/) shows no AIA trial for this patent, and there is no FWD to quote. There is likewise no FWD, no institution decision, and no CAFC opinion to link — so I cannot link to one, and neither can opposing counsel.
4. Preserve the estoppel point for completeness. Since no IPR ever instituted, no § 315(e)(2) bar limits either side; if (implausibly) a live dispute turns out to exist, all §§ 102/103/112 grounds are on the table. But the first and dispositive check is status, not validity.
5. If you need a citable public record of "no PTAB activity," use the USPTO Patent Trial and Appeal Board End-to-End system at https://ptacts.uspto.gov/ptabweb/ and the Board's decisions page at https://www.uspto.gov/patents/patent-trial-and-appeal-board/ptab-decisions, each searched by patent number 6,584,508.

If you were expecting an IPR and didn't find one — that is the finding. Well-asserted patents eventually attract IPRs; this one was never asserted, which is why it never attracted one. Do not treat that absence as evidence the claims would survive a challenge.

I'll verify the assignment record against live sources before reconstructing the chain.

Initial searches didn't surface the specific reel/frame records. Let me try more targeted queries.

Let me try to locate the actual assignment records via additional routes.

I hit the tool-call ceiling before I could pull the reel/frame images themselves, so I must be explicit up front about what I verified versus what I could not retrieve.

Data-access limitation (read this first)

I could not retrieve the underlying USPTO Assignment Center record images in this session. Repeated queries against the Assignment Center indexes (assignmentcenter.uspto.gov, assignment.uspto.gov) and against Google Patents' legal-events/assignment views returned no reel/frame numbers and no correspondent data for US 6,584,508. Every "'508" hit that did surface belonged to a different patent (e.g. US 7,653,508 / Uniloc, US 6,961,508 / Corning). Per the operating rules, I am not going to invent reel/frame numbers or correspondents. The three events below are taken from the Google Patents reassignment/legal-events entries (which mirror USPTO assignment data for date, conveyance type, assignor and assignee) but do not carry the reel/frame or correspondent fields.

Where a field is unknown, I mark it [not retrieved] rather than guessing.

Inventors

Pattern check — no unusual pattern found. There is no evidence that either inventor departed the original assignee within 12 months of the 1999-07-13 priority date; on the contrary, the 1999-12-30 inventor→company assignment (see below) shows both inventors conveying to the same corporate assignee at filing, and the second inventor's later publications/citations ("Kiernan et al., TIS Labs Report #0743/#0744D, 1998") show the project stayed inside the TIS Labs / Network Associates organisation. Caveat: I did not verify individual employment tenures from primary HR or SEC sources; the employer attribution is inferred from the TIS Labs provenance of the cited work. Jeremy Epstein is publicly known to have held later roles outside McAfee, but I did not confirm dates.

Original assignee

• Entity on the issued patent: Networks Associates Technology, Inc. (a subsidiary of Network Associates, Inc., d/b/a Network Associates, Inc.).
• Primary line of business at the time: enterprise network security — the Gauntlet™ firewall, PGP, Sniffer, and the Cybercop™ intrusion-detection line. The specification itself names the Gauntlet™ firewall and PDK as the platform being extended, so Network Associates was unambiguously an operating company.
• Did they ship a product embodying the claims? Partially/unclear. Gauntlet and its proxies were unquestionably shipped commercial products, and the specification frames the "advanced data guard" as an extension of Gauntlet (the ARGuE guard work, DARPA/DISA-adjacent research). Whether a commercial SKU implemented the issued claim-1 combination — GUI template + XML file transfer + shared memory + queue/dequeue + wrappers + IDS alerting — is not established from the record I retrieved. Treat "practised in a shipping product" as unproven.
• Current status of the chain entity: Network Associates, Inc. renamed itself McAfee, Inc.; McAfee was acquired by Intel (2011), spun out to TPG (2017), re-IPO'd (2020), and taken private by an Advent/Crosspoint/Permira-led group (2022), with the enterprise business later folded into Trellix. The listed current assignee of record is McAfee, LLC. Uncertainty: I could not retrieve the assignment record that would show the Networks Associates Technology → McAfee, Inc. → McAfee, LLC successive steps beyond the 2007 merger entry, nor whether any later 2021/2022 McAfee reorganisation affected this specific patent.

Assignment timeline

Note on completeness: the entries below are the reassignment events published on Google Patents' legal-events tab for US 6,584,508. Reel/frame and correspondent-of-record were [not retrieved] for any entry. This is a genuine gap, not a finding that the fields are blank.

• 1999-12-30 (executed; the record shows assignment contemporaneous with the filing date) / recorded [not retrieved] — Reel [not retrieved]

  • Conveyance: Assignment (inventor → employer)
  • Assignor: Epstein, Jeremy; Thomas, Linda
  • Assignee: Networks Associates, Inc., d/b/a Network Associates, Inc.
  • Correspondent: [not retrieved] — could not retrieve the recording attorney/firm. If this correspondent recurs on the [not retrieved] 2002 and 2007 entries, that would be a repeat-correspondent signal; I cannot make that call on the record I obtained.
  • Context: standard employee invention assignment at filing (the priority provisional, US 60/143,553, was filed 1999-07-13; the non-provisional was filed 1999-12-30).

• 2002-02-19 / recorded [not retrieved] — Reel [not retrieved]

  • Conveyance: Assignment
  • Assignor: Networks Associates, Inc., d/b/a Network Associates, Inc.
  • Assignee: Networks Associates Technology, Inc.
  • Correspondent: [not retrieved]
  • Context: internal reorganisation — transfer down into the group's technology-holding subsidiary; the same assignee footprint appears on the face of the issued patent.

• 2007-09-18 / recorded [not retrieved] — Reel [not retrieved]

  • Conveyance: Merger
  • Assignor: Networks Associates Technology, Inc.
  • Assignee: McAfee, Inc.
  • Correspondent: [not retrieved]
  • Context: corporate succession via merger (Network Associates had already re-adopted the McAfee name; the record formalises the vesting of the subsidiary's assets in McAfee, Inc.).

• 2019-12-30 — anticipated expiration (not an assignment; listed for chain completeness). Status: Expired – Fee Related, i.e. maintenance fees lapsed rather than the patent being sold or litigated to term.

No post-2007 assignment to any third party appears in the retrieved record. There is no recorded transfer to a licensing entity, no security agreement, and no defensive-aggregator assignment for this patent in the sources I could reach.

Timeline diagram

timeline
    title Ownership of US 6584508
    1999 : Provisional filed July 13
         : Inventors assign to Network Associates
         : Non-provisional filed December 30
    2002 : Assigned to Networks Associates Technology
    2003 : Patent issues June 24
    2007 : Merger into McAfee Inc
    2019 : Patent expires fee related

NPE / troll-pattern signals

Side observation (not a signal against this patent): one search result surfaced a "Patent Assignment from JPMorgan Chase Bank, NA to McAfee, LLC" record (PlainSite assignment id 10272295), which is a release of a security interest on a bundle of McAfee patents. I could not confirm that US 6,584,508 was among the pledged patents, so I am not treating a McAfee portfolio-level security agreement as a recorded lien on this patent. If you want that checked, it requires the Assignment Center's assignor-indexed search (assignor "McAfee") filtered to this reel, which I could not reach.

Verdict

Defensive / non-asserting.

The retrieved ownership chain (1999-12-30 inventor assignment to Networks Associates, Inc.; 2002-02-19 reorganisation to Networks Associates Technology, Inc.; 2007-09-18 merger into McAfee, Inc.) never leaves the original operating-company family, and the patent was then allowed to lapse fee-related with an anticipated expiration of 2019-12-30 — it was neither sold to a licensing entity nor asserted. I am applying this label with a caveat: the literal trigger for this category (termination at RPX/AST/LOT/Unified) is absent; the closest fit is that the patent was effectively neutralised inside a large security vendor that declined to pay maintenance. Six of the eight NPE signals are affirmatively not present and the remaining two (repeat correspondent, pre-litigation transfer) are unclear only because the reel/frame and correspondent fields could not be retrieved, not because of any evidence pointing the other way.

Verification links:

• USPTO Assignment Center (search by patent number 6584508): https://assignmentcenter.uspto.gov/
• USPTO legacy assignment index: https://assignment.uspto.gov/patent/index.html
• Google Patents legal events: https://patents.google.com/patent/[US6584508B1](/patent/US6584508B1)/en

What to pull next to close the gap: the three reel/frame entries above and their correspondent-of-record. That single field is the one substantive test in this task I could not run, and it is the only thing that could move this verdict — if the 2002 and 2007 recordings share a correspondent with any known asserter family, the call would change from "corporate succession" to a flagged pattern. On the record as retrieved, there is nothing to support that.

I'll verify the citation record and key references against live sources before building the prior-art analysis.

Now let me verify the remaining citations and the examiner's non-patent references.

Prior-art analysis for US 6,584,508 B1 — Advanced data guard having independently wrapped components

A note on date and record consistency before the substance

The current-task header gives April 26, 2026, while the system header gives 2026-09-27 and the Google Patents fetch stamp is 2026-09-26. Three different "today" values for the same exercise. I proceed on the record's citation data, but you should reconcile the system clock before dating any filing or response document.

1. Scope, sources, and confidence

You asked me to search the USPTO database for 6584508 (not similar numbers) and to work the patent citations for that document. What I can and cannot certify:

• The authoritative citation lists are the ones embedded in the patent record you supplied (Google Patents' rendering of the USPTO file): a 14-entry "Patent Citations" table and a 20-entry "Non-Patent Citations" table, plus a 12-entry inline "Citations" table and two "Cited By" tables (listed inconsistently as 95 and 160 entries).
• My live searches reached Google Patents, FreePatentsOnline, uspto.report, patentimages (USPTO-captured PDFs), the Unified Patents patent portal, PTAB/PTACTS documents, and EPO search reports — i.e., records derived from USPTO data. I did not have direct API/console access to USPTO Patent Public Search or PatentCenter. Treat the citation lists as accurate to the file and my description of each reference's disclosure as verified only where I say so below.
• Confidence is flagged per reference: [V] = full text fetched and read; [R] = record-level only (number, date, title, assignee); description is inferential and must be re-verified before use in any §102/§103 chart.

Record inconsistency to flag (12 vs. 14): the two patent-citation tables do not match. The 14-entry table is the 12-entry table plus US 6,061,798 and US 6,052,788 — the two Network Engineering Software continuations in the same family as US 5,826,014 / US 5,898,830. Nothing is genuinely missing; the smaller table simply collapses the family. Cite the 14-entry list as the complete citation set.

Data artifact to disregard: the Google Patents "Concepts" panel for this patent lists a chemical compound (SAPGTCDSBGMXCD-UHFFFAOYSA-N, a chlorophenyl-fluorophenyl-pyrimidinyl-methanol). That is Google's automated chemical-entity extraction noise, not a citation. Ignore it.

2. Legal framework actually applicable (this governs the whole answer)

US 6,584,508 was filed 1999-12-30 with a provisional priority date of 1999-07-13. It is therefore a pre-AIA patent; only §102(a), (b), (e) and (g) are in play, and §102(e) carries no publication requirement for applications filed before 2000-11-29.

Three points that decide most of the answers below:

1. Anticipation is single-reference and all-elements. Under §102 a reference anticipates only if it discloses every limitation, arranged as in the claim. Because claims 2–5 depend from claim 1, they incorporate all of claim 1's limitations — so a reference that meets only a dependent claim's added limitation (e.g., "monetary transaction") cannot anticipate claims 4 or 5.
2. Claim 1 is a conjunction, not a menu. As flagged in the earlier section, claim 1 positively requires: a GUI template supplying rules and values; two application-level proxy agents; a protocol-independent content-based filter whose review is user-configured from those rules/values; software wrappers constraining each of the two proxies and the filter; files including XML; shared memory transport; content modification; queuing/dequeuing components between the proxies and the filter; a COTS operating system; and application-specific IDS alerts keyed to the rules/values. No single reference in this record touches even half of that list.
3. Grant date ≠ prior-art date. Several cited references issued after the '508 priority date yet remain available as §102(e) art because their US applications were filed earlier (US 6,349,336, US 6,345,300, US 6,104,716, US 6,058,379, US 6,219,706, US 6,061,798, US 6,052,788). Do not discard them on issue date alone.

3. Patent references (the 14-entry citation set)

4. Non-patent references (the 20-entry NPL set) — the ones that matter

5. Most relevant prior art — ranked

Ranked by closeness to claim 1, not by number:

1. US 5,864,683 (Secure Computing / Boebert et al.) — the only cited reference that combines a two-sided secure interface, kernel-enforced confinement of processes (the functional equivalent of independent wrappers on each component), content-based filtering, and alarm generation. If claim 1 is ever tested, this is the lead reference, combined with the Fraser wrapper paper.
2. Fraser et al., "Hardening COTS Software with Generic Software Wrappers" (May 1999) — squarely on the limitation that distinguishes the title ("independently wrapped components") and on the COTS framing.
3. US 6,349,336 (HP) — a two-sided application-level proxy pair straddling a firewall without application modification: the best single-reference teaching of "first proxy agent + second proxy agent."
4. US 6,009,475 (IBM) — GUI-driven rule administration with validation of the rule set: the best single-reference teaching of the GUI-template and claim 3 limitations.
5. US 6,345,300 (Intel) — proxy-side content modification (transcoding) driven by a user-set preference.
6. US 5,550,984 (Matsushita) — the split, protocol-translating, address-stripping barrier.
7. Fiorino et al. (C² Guard) + Kiernan TIS Labs wrapper reports — the queue/dequeue architecture and wrapper operational detail respectively.
8. US 6,058,379 (Auction Source) — the only reference reaching claims 4–5's monetary-transaction subject matter.

6. Claim-by-claim §102 conclusion

Bottom line: none of the 14 patent references or 20 non-patent references anticipates any claim of US 6,584,508. The cited set is §103 material, and it is conspicuously thin in exactly the places the issued claim is thickest.

7. What the cited art conspicuously does not cover — and why that matters

Mapping the claim 1 limitations against the citation set, four gaps stand out. These are the limitations that plausibly carried the allowance, and any validity analysis should treat them as the load-bearing elements:

• XML as the proxy↔filter interchange format. The only reference to XML in the entire citation record is the TechEncyclopedia entry dated 2003‑01‑06 — which is not prior art at all. There is no pre-1999 reference in this record teaching XML serialization between a proxy and a content filter.
• Shared memory as the transport between the proxies and the filter. Nothing in the cited set. The specification itself frames shared memory as an alternative to the file mechanism, and both appear in claim 1 as conjunctive limitations — an unusual and narrowing choice.
• Queuing/dequeuing components interposed between the proxies and the filter. Only the Fiorino C² Guard NPL (separate queue/dequeue computers) approaches this, and it is a separate-machine, serial-link architecture, not in-line queued directories.
• A GUI template feeding rules and values into a content filter that then drives application-specific IDS alerts. US 6,009,475 gets you GUI + rule validation; US 5,864,683 gets you content filtering + alarms; nothing cited bridges them.

That gap set is the direct technical explanation for the drafting observation in the earlier section: the issued claim is a narrow, "kitchen-sink" conjunction, and the reason no reference anticipates is precisely that the applicant put the four gap-limitations into the claim rather than leaving them in the specification.

8. Caveats and contradictions to carry forward

• Consistency with the earlier sections: nothing here contradicts the bibliographic summary or the litigation findings. The prior sections noted the '508 patent is cited as prior art in US 9,118,711 and WO 2012/113596 — consistent with the two "Cited By" tables in the record. The earlier-flagged EP citation "US 6584508 P 20080215" appearing on EP 2090820 remains unverified; the newly fetched record does not show it, and per the literal-interpretation rule I am not assuming it corresponds to the 2003 grant.
• Reference-level verification gaps: items marked [R] above (US 5,819,251; US 5,826,014; US 6,061,798; US 5,898,830; US 6,052,788; US 5,944,823; US 6,104,716; US 6,058,379; US 6,219,706) are described from record-level metadata only. My element mapping for those is provisional and must be re-verified against full text before appearing in a §102/§103 chart.
• Date-unverified NPL: the two Network Associates white papers and the TIS Internet Firewall Toolkit overview carry no dates in this record. Their §102 status is indeterminate as supplied, and because two of the three are the applicant's own publications, establishing their dates is the single highest-value follow-up.
• My access limits: I could not query USPTO Patent Public Search, PatentCenter, PACER, or PTAB APIs directly; the citation data here derives from the file record and from public mirrors. A definitive prior-art chart should be rebuilt from the USPTO file wrapper (09/475,944) — specifically the examiner's cited references and the PTO-892/1449 forms — because Google's rendered tables do not reliably distinguish examiner-cited from applicant-disclosed art, and the * / † attribution markers were mangled in the fetched text.

I'll verify the key prior-art references listed on the patent page before building the § 103 analysis.

Good grounding on several references. Now let me verify the remaining key ones.

Obviousness analysis — U.S. Patent No. 6,584,508 under 35 U.S.C. § 103 (pre‑AIA)

Building on the claim mapping and bibliographic sections above; not repeating them. Framing note: the application was filed 1999‑12‑30 with a 1999‑07‑13 provisional, so pre‑AIA §§ 102/103 govern. Sources: Google Patents US6584508B1; the "Patent Citations (14)" and "Non‑Patent Citations (20)" lists on that page are the prior‑art universe I was asked to use.

1. Framework and the threshold definitional problem

The § 103 inquiry is the Graham v. John Deere four-factor test as applied in KSR Int'l Co. v. Teleflex Inc., 550 U.S. 398 (2007): scope/content of the art, differences from the claims, level of ordinary skill, and objective indicia. KSR supplies the rationales a petitioner or examiner may use — predictable combination of known elements, substitution of a known element, use of a known technique to improve a similar device, "obvious to try," and design incentives/market forces.

Critical threshold point about this record: the prior art on the face of the patent is not a normal sampling. The specification admits a large part of the architecture as background. The patent itself concedes: the Gauntlet™ firewall with its proxy architecture (thousands of installations, COTS hardware); the TIS Internet Firewall Toolkit proxies; the C₂ Guard (Fiorino et al., Lessons Learned During the Life Cycle of an MLS Guard Deployed at Multiple Sites, 11th ACSAC, Dec. 1995) as a three‑computer guard with queuing and dequeuing computers and content‑based filters in the middle, moving files; the ISSE guard; Secure Computing's SMG; and Cybercop™ IDS integration. Admissions in the specification are usable as prior art irrespective of whether the reference itself is produced. That framing materially lowers the obviousness burden for most of claim 1.

I also want to flag two identifications that are not prior art despite appearing on the page, because conflating them would produce an invalid rejection:

• "Cited By (95)" / "Cited By (160)" lists are not prior art. Every entry there (e.g., US 6,775,657 Cisco multilayered IDS, filed 1999‑12‑22; US 7,024,694 McAfee) post‑dates the applicant's effective date and cannot be used.
• The TechEncyclopedia XML citation is dated on the page as "Jan. 6, 2003" — after the 1999 filing. It is a definitional reference, not § 102(b) art. A rejection on the XML limitation must rest on a pre‑1999‑07‑13 reference, not this citation.

2. Level of ordinary skill

A POSITA here is a network-security engineer/developer with a B.S. in CS or EE and roughly 2–4 years of firewall/proxy and UNIX systems programming experience. That skill level is corroborated by the applicant's own statement that filter authoring in Felt "requires significant expertise," and by the DISA-sponsored "Security Guard Study" (Aug. 1995) cited in the spec. Notably, such a POSITA would be squarely familiar with (i) dual‑homed/application‑level firewall proxies, (ii) system‑call interposition, and (iii) the guard problem the spec admits dates to at least 1994–95.

3. Ground 1 (primary): Jade (US 5,944,823) + Fraser et al. + Shrader (US 6,009,475), with Fiorino admitted

US 5,944,823 (IBM, Jade/Walters/Moore/Rao; filed 1996‑10‑21; issued 1999‑08‑31) — verified. Discloses, verbatim from the abstract and spec: a "tunneling" mechanism "operating on both sides of a firewall," implemented as "tunneling applications, running on interface servers inside and outside the firewall," with an inside interface server (Server A) and an outside interface server (Server B), a control connection accessible only to the two tunneling applications, a trusted socket table that requests are validated against before forwarding, and a firewall computer through which data connections are formed under inside control. (US5944823 PDF; Unified Patents record). This is structurally the claimed "first proxy agent … second proxy agent" pair on one machine acting as a barrier, with access validation at each interface. The same disclosure appears in the cited family member US 6,061,797 (Jade et al., issued 2000‑05‑09, filed 1996‑10‑17 → available as § 102(e) art).

What Jade lacks: a content filter between the two relays, XML, shared memory, wrappers, GUI configuration, IDS alerts.

Fraser et al., "Hardening COTS Software with Generic Software Wrappers," 1999 IEEE Symp. on Security and Privacy — cited on the face of the patent and credited in the spec for its premise: the wrapped application "should be unaware of the wrapping, and should not need any modifications to be wrapped," with a kernel loadable module intercepting system calls against a wrapper specification (WS) and a WEL that "tracks running processes and evaluates activation criteria at appropriate times to activate new wrapper instances for processes." That per‑process, per‑binary activation criterion is precisely "independently wrapped components." I could not re‑verify the Fraser paper text in this session (search limit reached); I am relying on the patent's own detailed characterization of it, which is itself an admission that wrappers worked this way.

US 6,009,475 (IBM, Shrader; filed 1996‑12‑23; issued 1999‑12‑28) — verified. Abstract: "Filter rules on a firewall between a secure computer network and a nonsecure computer network are validated from a user interface. A user interface is presented in which a test packet can be defined. The user interface includes controls for defining values for attributes… A defined test packet is validated against a set of filter rules…" It uses "a web based user interface framework which presents a consistent graphical interface to the administrator" (IP Filter Definition Page, Validation Test Page, Query Page), lets the administrator save and retrieve predefined queries / batch‑test a series, and expressly states the invention "has application to any set of filter rules which may be imposed between secure and nonsecure networks." (US6009475 PDF).

Mapping to claim 1:

Motivation to combine (KSR rationales (a), (c), (f)):

1. The only reason to place a device between two network regions and call it a guard rather than a firewall is content/information‑flow control — the spec says so: "a guard has the additional goal of preventing information on the inside from being sent to the outside." A POSITA designing on the admitted C₂ Guard model would place the content filter between the two relays as a matter of course.
2. Jade supplies the single‑machine version of the two‑relay architecture and the security‑critical intuition that each interface server should validate its own side's requests — which is the natural motivation for per‑component constraints.
3. Fraser supplies the mechanism that the patent's own narrative says was needed: proxies are written by non‑security programmers and "should be protected so that they operate within a restricted subset of available system calls." A POSITA who already operates COTS proxies (unmodifiable binaries) has a strong, articulated reason to use generic wrappers rather than source‑level hardening.
4. Shrader provides the direct design incentive (moving administrators off "arcane commands" to a consistent GUI) and reason to use it (rule sets grown complex, per its own background on "the burdens on Internet administrators hav[ing] been rapidly growing both in volume and in complexity").

4. Ground 2: Secure Computing US 5,864,683 + US 6,349,336 (HP) + Fraser + Shrader

US 5,864,683 (Boebert et al., filed 1994‑10‑12, issued 1999‑01‑26) — verified. It claims a "secure computer … inserted into the private network to serve as the gateway to the unsecured network," with "a private network interface," "an unsecured network interface," "a server function for transferring data between the private network interface and the unsecured network interface," and "a filter function for filtering data transferred between the remote computer and the workstation." Its unifying mechanism is Type Enforcement: "in Type Enforcing (TE) Secure Computers executables residing within the secure computer can only be executed if the person requesting execution has execution privileges for that executable object." (Unified Patents).

This is the closest single reference to the purpose of claim 1: one computer, two network interfaces, a transfer function, and a filter — plus an OS‑level mechanism that limits what each program can do. Motivation to substitute generic wrappers for TE is a textbook KSR (b)/(c) case: the applicant's own spec explains that TE‑style approaches require source access and kernel modification, whereas Fraser's generic wrappers work on unmodified COTS binaries — an improvement to the same device by a known technique, yielding the predictable result the claim recites. (Note: a sibling Secure Computing patent, US 5,867,647, Haigh et al., "System and method for securing compiled program code," expressly teaches allowing a compiled program to execute, logging type‑enforcement violations, then modifying the execution environment to prevent recurrence — i.e., learn‑then‑confine, the same loop the spec attributes to wrappers. I list it as a lead because it is a close relative of the cited US 5,864,683, but I must flag that it does not itself appear on the US 6,584,508 face.)

US 6,349,336 (HP, Nelson et al.; filed 1999‑04‑26; issued 2002‑02‑19) — verified; § 102(e) art because its filing precedes 1999‑07‑13. Claims a "proxy agent device" on the internal side and a "reverse proxy device" on the external side of a firewall, each an independent program interoperating "without modification of communication applications on either said local processor or said remote processor." (US6349336 PDF). This directly supplies the "two independent proxy agents on opposite sides of a barrier" element in application‑level form, and supplies the same transparency premise the patent invokes for data sealing.

5. Ground 3: US 5,550,984 (Matsushita/Gelb) — the "protocol‑independent" element

US 5,550,984 (filed 1994‑12‑07, issued 1996‑08‑27) — verified. It discloses a security system with "a first network motherboard and a second network motherboard," each with a network interface adapter, where communications "in Transmission Control Protocol/Internet Control Protocol (TCP/IP) format … are translated into Internet Packet Exchange (IPX) … format," removing "the upper TCP protocol layer, and the original IP datagram headers" so that "upper level layer protocol information and originating source and destination address information are removed." It is expressly built from "available standard hardware and software components" (its stated object), i.e., COTS. (US5550984 PDF).

Motivation: a POSITA facing the applicant's admitted problem — "none of these guards had the capability to deal with modern middleware protocols such as IIOP used by CORBA" — would combine Jade's two‑relay guard with a translation‑to‑intermediate‑form step so that one content filter could serve many protocols. That is exactly the claimed "protocol‑independent analysis application," and it is a KSR (d) (applying a known technique to a known device ready for improvement).

6. Ground 4: the XML / file / shared‑memory cluster

• Files + queuing: admitted prior art (C₂ Guard's queuing and dequeuing computers moving files; the spec concedes "The process is equivalent for files being transferred from the outside to the inside").
• Shared memory instead of files: this element is very weak as a non‑obviousness anchor, because the spec itself treats it as a design alternative: "there is no fundamental architectural reason why the connection needs to be based on the use of a file. Accordingly, in an alternative embodiment, shared memory segments are used…" That is an admission that substituting UNIX shared‑memory IPC for file IPC was an obvious engineering choice (KSR (b)); the applicant even asserts a bonus effect (speed) without data. A POSITA familiar with System V/POSIX shared memory would find it obvious to use documented IPC between co‑resident processes.
• XML: the only support on the page is a 2003‑dated encyclopedia citation, which cannot be prior art. This is the single element for which Ground 1–3 art is deficient, and it is where a real petition must supplement. A pre‑1999‑07‑13 reference teaching markup‑language‑based content filtering would close the gap. Lead I could not verify: Network Engineering Software's US 5,870,550 (filed 1996‑02‑26, issued 1999‑02‑09) appears in a German family citation relating to "Filterung von einen Inhalt gemäss einer Markierungssprache einschliessenden Nachrichten" (filtering messages containing a markup language), and it appears with Network Engineering Software's US 5,826,014 / US 6,061,798 — both of which are cited on the page. If US 5,870,550 teaches markup‑language content filtering, XML is covered by 1999 as well. Treat this as unverified.

7. Ground 5: the IDS‑alerting element and dependent claims

The wrapper art supplies the alerting pathway: the spec states that wrappers can be "designed to generate alerts to an intrusion detection system … by writing records to a log file, and having a user space daemon read the log file and forward the relevant records." Framed as a motivation: once a third process receives interposed‑call records, extending it to application‑value records from a content filter is a routine, predictable extension of a known alerting pipeline — KSR (a). The admitted Cybercop™/Gauntlet integration supplies the market‑force rationale (KSR (f)). I should be candid: none of the twenty listed non‑patent citations and none of the fourteen listed patent citations is an IDS reference with value‑threshold alerting, so this element is the analytically weakest, together with XML.

Claims 2–5:

• Claim 2 (alerts user‑configured): Shrader's GUI defines user‑entered values and saves/retrieves prior definitions; making alert parameters user‑configurable is a non‑technical configuration choice.
• Claim 3 (limitations "reviewed to ensure … organizational security requirements"): This is Shrader almost verbatim — validation testing of a rule set, displaying the denying rule, with the stated purpose of appli[ying] to any set of filter rules between secure and nonsecure networks. Strongest dependent claim for a rejection.
• Claim 4 (monetary transaction): US 6,058,379 (Auction Source, "Real‑time network exchange with seller specified exchange parameters"); I did not verify its disclosure beyond the title/date, so treat as a lead. Otherwise, applying a known content filter to financial data fields is the definition of an obvious field of use — the claim adds no structure beyond the data's semantic domain.
• Claim 5 (bank transaction): same rationale, one level narrower; essentially the spec's own deposit‑threshold worked example, i.e., an exercise of the ordinary skill of writing filter rules.

8. Counterarguments a patent owner would raise — and where they have force

1. Conjunctive "files and shared memory." Claim 1 requires the proxies to "generate and pass files … wherein said files include [XML]" and to "pass information … using shared memory." The specification presents these as alternatives, not as a combined embodiment. Two consequences: (i) it is genuinely harder to show a motivation to do both, because no prior‑art system would need to; and (ii) it raises a written‑description concern for the claimed combination. This is the best non‑obviousness argument the claim has, and it should be conceded rather than papered over.
2. Jade's directionality. US 5,944,823 is aimed at enabling outside‑in access — the wall a guard is designed to hold. A patent owner will argue that a POSITA would not look to a "let them in" reference to build a "keep it in" device. This is a weak teaching‑away argument (the claimed system is a barrier "between" regions with no directional limitation, and Jade's validation machinery is agnostic as to direction), but it will be made.
3. Fraser's caution. Fraser (per the spec's own summary) warns that "creating too precise a proxy wrapper can result in the breaking of the proxy," and suggests logging rather than blocking where uncertain. That is a warning about granularity, not a teaching away from wrapping.
4. Objective indicia. None in this record. No unexpected results, no long‑felt need beyond the admitted pre‑1994 guard problem, no failure of others documented, no evidence of copying. Gauntlet's "thousands of sites" predates the invention and is not the novel subject matter, so there is no nexus. The earlier sections' finding that the patent expired fee‑related in 2019 and was never asserted cuts against evidence of industry recognition.

9. The provisional‑priority wrinkle — it can only make the patent more vulnerable

Because the provisional (60/143,553) was filed 1999‑07‑13 and the non‑provisional 1999‑12‑30, any claim limitation not supported by the provisional gets a 1999‑12‑30 effective date. That would pull in two additional categories:

• US 6,775,657 (Cisco, filed 1999‑12‑22) — within the § 102(e) window relative to a 1999‑12‑30 date for any such limitation.
• The applicant's own ARGuE Guard paper (J. Epstein, Architecture and Concepts of the ARGuE Guard, 15th ACSAC, Dec. 1999), which is cited on the face of the patent. I flag the 102(a) "by others" and 102(b) one‑year issues: a Dec. 1999 paper is less than one year before 1999‑12‑30 and is by the same inventor, so it is probably not itself prior art. But note the asymmetry — the examiner had the applicant's own contemporaneous description of this same architecture before them and still issued the claim. That is a point in the patent's favor, and it means a petitioner should not expect the examiner's citation of ARGuE to do any work.

10. Bottom line

• Claim 1 is, on this record, more likely than not obvious over Jade (US 5,944,823 or its § 102(e) sibling US 6,061,797) in view of Fraser et al., in further view of Shrader (US 6,009,475), with the C₂ Guard architecture (admitted in the specification) supplying the between‑the‑relays content filter and the queuing/dequeuing file transfer, and with the specification's own admission that file‑vs‑shared‑memory is an arbitrary design choice.
• A second, independent ground runs on US 5,864,683 in view of US 6,349,336, Fraser, and Shrader, using US 5,550,984 for the protocol‑independent intermediate representation and COTS componentry.
• The two elements requiring art outside the page are XML and value‑based IDS alerting. The TechEncyclopedia citation cannot do that work (2003 date). Recommend supplementing with (a) a pre‑July‑1999 markup‑language content‑filtering reference — Network Engineering Software's US 5,870,550 is the lead to check — and (b) a pre‑1999 network IDS reference disclosing rule/threshold alerting on inspected content.
• If XML and IDS alerting cannot both be met, claim 1 likely survives on those two limitations alone, and the realistic outcome is a § 103 rejection of claim 3 (and 2) over Shrader + Fraser + Jade, with claims 1, 4, and 5 requiring the supplemented art or a § 112 challenge on the conjunctive file/shared‑memory limitation.

Confidence and limits: I verified the disclosures of US 5,944,823 (and its family), US 6,009,475, US 5,864,683, US 6,349,336, and US 5,550,984 from primary documents this session. I could not re‑verify Fraser et al., Kiernan et al., Goldberg et al., Mitchem et al., Fiorino et al., the ARGuE paper, US 6,058,379, or US 6,345,300 (tool step limit reached); statements about those rest on the patent's own characterization or on titles/dates only, and are labeled as such above. Nothing in this analysis contradicts the bibliographic or litigation findings in the earlier sections.