US 6604135

I'll run targeted searches to verify the patent record and check for any litigation or CAFC activity.

Let me check for the actual claim text and any litigation involving this specific patent.

Let me try to retrieve the actual claim set and check specifically for 2026 CAFC docket activity.

US Patent 6,604,135 — Verification Summary

Scope note: I searched for this specific number (no fuzzy/near-number matching) on Google Patents, PubChem's patent record, Unified Patents' portal, and general web indexes, plus a targeted sweep for Federal Circuit / litigation activity. Findings below; where I could not get authoritative text I say so explicitly.

---

1. Bibliographic record (as reported by the sources)

Sources: https://patents.google.com/patent/US6604135/en ; https://pubchem.ncbi.nlm.nih.gov/patent/US-6604135-B1 ; https://portal.unifiedpatents.com/patents/patent/US-6604135-B1

2. Priority chain / family (from the patent's own "Related Applications" text)

The '135 patent states it is a divisional of U.S. Ser. No. 08/761,684, filed Dec. 6, 1996, now U.S. Pat. No. 5,974,441 ("WWW Client Server Interactive System Method with Java™"), which is itself a continuation-in-part of U.S. Ser. No. 08/474,577, filed Jun. 7, 1995, now U.S. Pat. No. 5,701,451. It is also related to the concurrently-filed Jun. 7, 1995 family: U.S. Pat. Nos. 5,721,908; 5,752,246; 5,745,754; 5,793,964; 5,710,918; and 5,761,663. This chain explains the 1995 priority date and the 2015 expiry.

Ownership changes recorded: assignment to Google Inc. (2011-10-03), then Google LLC (change of name, 2017-10-06; corrective reassignment 2024-03-04).

3. Abstract (verbatim)

"A control program agent at a Web server receives a browser request by way of a server side API and fulfills requests as an agent of the browser client. Program capsules are utilized by distributed integration solution (DIS) servers for retrieving, from a database gateway coupled to a plurality of database resources, requested information from multiple data bases, performing calculations, formatting, and other services on the information and reporting results to the web browser or to other locations, in a selected format, as in a display, fax, printer, and to customer installations."

Note the abstract's "server side API" phrasing — the specification itself frames the Web-server-to-agent invocation around CGI (Common Gateway Interface) and the ODAS API, with the FIG. 8 control program using PATH_INFO and QUERY_STRING environment variables, ODAS API calls, a capsule-execution queue threshold test, and dynamic generation of HTML to present results. The abstract's "server side API" and the spec's "CGI" are not identical terminology, which is worth flagging if claim scope matters.

4. Plain-language overview of the independent claims — NOT VERIFIED

I do not have authoritative claim text for US 6,604,135 and will not reconstruct it. The full-text capture I was given truncates mid-specification (inside the FIG. 8 description at "step 113") and does not include the claims. My searches returned claim sets for sibling patents — notably US 5,974,441 (the '135 patent's parent), US 5,721,908, and US 5,745,754 — but not the numbered claims of the '135 patent itself.

Because claim language is legally operative, I will not paraphrase claims I have not read. The honest statement is: the independent claims are believed to be of the "method for fulfilling requests of a Web browser" type (consistent with the parent's claim style), covering a control program agent at a Web server that ingests request parameters, drives DIS capsule execution via an API (ODAS), and dynamically generates HTML to report results — but this is inference from the specification and family, not a verified reading of the '135 claims. If exact claim scope is required, pull the granted claims directly from USPTO PatentCenter or the Google Patents claims tab for US6604135B1.

5. Litigation / CAFC 2026 docket check — negative result

• I found no Federal Circuit docket, no 2026 appeal, and no district-court action naming 6,604,135 as the patent-in-suit. Note this is a failed-to-find, not a certified absence — my search was open-web, not a direct PACER/CAFC docket query.
• I did find the Rogers et al. family cited as prior art in USPTO post-grant proceedings against US 6,415,335 (the "page server / dispatcher" patent): inter partes reexaminations 90/008,342, 90/008,562, 90/008,574 and IPRs IPR2015-00486, IPR2015-01732, IPR2015-01734, where IBM was the petitioner/third-party requester. In those papers the patent owner characterizes "Rogers" as using "a single ODAS server" and "a lone control program agent in a web server," with no dispatcher and no plurality of page servers. (See e.g. https://www.docketalarm.com/cases/[PTAB](/ptab)/IPR2015-01734/... and https://storage.courtlistener.com/recap/gov.uscourts.ded.36792.294.0.pdf)
• Caveat: the "Rogers, et al." citation in those papers is not pinned to a single patent number in the excerpts I retrieved; it may refer to US 6,604,135, its parent US 5,974,441, or another family member. Treat that attribution as unconfirmed.
• Separately, do not confuse this with VirnetX U.S. Pat. No. 6,502,135 (a different patent, different number ending in 135), which is heavily litigated at the Federal Circuit. The searches surfaced that case repeatedly, and it is not the patent you asked about.

6. Explicit uncertainty statements

1. Claims not retrieved — no verified independent-claim summary is possible from what I have. Do not rely on any inferred claim scope.
2. CAFC 2026 activity — none found; absence unverified against primary docket systems.
3. "Rogers, et al." prior-art citation — could refer to this patent or a sibling; unconfirmed.
4. Abstract vs. specification terminology — the abstract says "server side API"; the detailed description describes CGI plus ODAS. Noted, not reconciled.

Bottom line: US 6,604,135 B1 is a 2003 IBM-origin divisional (Rogers & Lagarde) claiming priority to June 7, 1995, now assigned to Google LLC and expired as of June 7, 2015. It describes a Web server control-program-agent architecture bridging HTML/CGI requests to IBM's Data Interpretation System (DIS) via ODAS, with capsule objects pulling from heterogeneous databases (DB2, Oracle, Sybase, Redbrick) and results returned as dynamically generated HTML, fax, print, e-mail, voice, or video. I found no evidence of it being litigated or reaching the Federal Circuit.

I'll research litigation involving US patent 6604135. Let me run several targeted searches.

Let me search more specifically in litigation databases.

The first searches surfaced similar-numbered patents (6,502,135 VirnetX; 6,436,135 Bard) — those are NOT the patent at issue. Let me target the correct patent directly.

Summary of Findings: Litigation Involving U.S. Patent No. 6,604,135

Result: I found no record of any litigation involving U.S. Patent No. 6,604,135.

Important caveat on the search results

My searches repeatedly returned hits for different patents that share the trailing digits "135" — these must NOT be conflated with your target:

Every "135 patent lawsuit" that surfaced was one of the two above, not US 6,604,135. Per your strict instruction, I excluded them.

What the record shows for US 6,604,135

• Title: WWW client server dynamic interactive system method
• Inventors: Richard Michael Rogers; Konrad Charles Lagarde
• Original assignee: International Business Machines Corp. (IBM)
• Current assignee: Google LLC (assignment to Google recorded 2011-10-03; name change to Google LLC recorded 2017-10-06)
• Application: US 09/369,625; a divisional of Ser. No. 08/761,684 (now US 5,974,441)
• Priority date: 1995-06-07; filed: 1999-08-06; granted: 2003-08-05
• Legal status: Expired – Lifetime (anticipated expiration 2015-06-07)

Why no litigation likely exists

• The patent expired on 2015-06-07, so the window for new infringement suits is closed.
• It was a defensive/dormant IBM portfolio asset transferred to Google in 2011 as part of the large IBM→Google patent transfer. Such transferred assets are often held for defensive/counter-assertion purposes rather than for offensive assertion.
• No asserted-case references, no PACER/Unified Patents/Google Patents "Litigation" entries, and no CAFC dockets tied to "6,604,135" appeared in any search I was able to complete.

Confidence and limitations

• Confidence that no litigation exists: moderate-to-high. The patent is expired and no case, docket number, party, or CAFC appeal referencing "6,604,135" appeared.
• Limitations on my research (disclosed for transparency): I exhausted my available search steps before I could complete direct queries against the Unified Patents litigation caselist (portal.unifiedpatents.com/litigation/caselist) and PACER/CAFC dockets specific to this number. My conclusion is based on that constraint; if you need a court-record-grade confirmation, a definitive check would be:
  1. Unified Patents litigation portal — search "6604135" in the patent litigation caselist.
  2. PACER / CourtListener RECAP — full-text search for "6,604,135".
  3. USPTO Patent Trial and Appeal Board (PTAB) — for any IPR/PGR/reexam on this number (none found in searches).
  4. USPTO Assignment records — for any security interests or litigation-related transfers.

Bottom line: Based strictly on the identifiers you supplied (US 6,604,135 / "6604135"), and after excluding results for the similarly numbered but unrelated patents 6,502,135 and 6,436,135, there is no known litigation involving U.S. Patent No. 6,604,135.

PTAB / AIA Trial Report — U.S. Patent No. 6,604,135

Patent: US 6,604,135 B1 — "WWW client server dynamic interactive system method"
Inventors: Richard Michael Rogers; Konrad Charles Lagarde
Original assignee: International Business Machines Corporation
Current assignee: Google LLC (IBM → Google Inc. recorded 2011-10-03; → Google LLC 2017-10-06)
Application: US 09/369,625 (divisional of US 08/761,684, now US 5,974,441)
Priority date: 1995-06-07 · Filing date: 1999-08-06 · Grant: 2003-08-05
Legal status: Expired — Lifetime (anticipated expiration 2015-06-07)

---

Proceedings overview

Total AIA trial proceedings on file against US 6,604,135: 0. The structured "PTAB proceedings on file" block supplied with this task — sourced from the USPTO Open Data Portal — returns no IPR, PGR, or CBM proceedings, and independent web searches across PTAB petition records, PTAB E2E, Google Patents' legal-events record, CourtListener, and the Unified Patents patent portal surfaced no AIA trial, no ex parte/inter partes reexamination, and no Federal Circuit appeal involving this patent number. No proceeding is therefore in any status category (active / claims invalidated / claims sustained / settled / institution denied) — the breakdown is 0 / 0 / 0 / 0 / 0.

Bottom-line defensive posture: the record is not "the patent survived two IPRs and is hardened" — it is "the patent was never challenged at the PTAB at all." Critically, however, US 6,604,135 expired on 2015-06-07 and is owned by Google LLC, an operating company that acquired it from IBM in 2011 as part of a large defensive portfolio transfer. Because the patent term has run, it cannot be infringed today; any residual exposure would be past damages, and the six-year back-damages window of 35 U.S.C. § 286 has long since closed (2015-06-07 + 6 years = 2021-06-07). A demand letter citing this patent today is, on its face, difficult to square with the patent's expired status.

Confidence note / limitation. I could not access a PTAB E2E or Docket Navigator-style structured feed in this session. My conclusions rest on (a) the canonical ODP "no proceedings" block in the prompt and (b) negative results across the searches I was able to run. If a CBM or IPR was filed and terminated very early (e.g., a pre-institution withdrawal, which leaves only a short-lived public docket entry), a targeted PTAB E2E patent-number search is the definitive confirmation step. I did not find one, but I cannot rule one out with the certainty I would want for a clearance opinion.

---

Per-proceeding detail

None to report. There is no proceeding number, petitioner, panel, institution decision, Final Written Decision, settlement, or appeal to describe for US 6,604,135. I am deliberately not generating any placeholder proceeding numbers, judge names, or claim-level dispositions — doing so would be fabrication.

What the negative record does not mean

Three adjacent items surfaced in search and should be expressly distinguished from this patent, because the patent numbers are confusable:

• US 6,502,135 (VirnetX) — the subject of a long IPR/reexamination campaign (e.g., IPR2015-01046, IPR2016-00062) and Federal Circuit appeals (e.g., VirnetX Inc. v. Cisco Systems, Inc., No. 19-1671 (Fed. Cir. 2023); the CourtListener opinion at https://www.courtlistener.com/opinion/[9434237](/patent/9434237)/virnetx-inc-v-cisco-systems-inc/). This is a different patent with a similar number. None of those proceedings touch 6,604,135.
• US 6,436,135 (Bard Peripheral Vascular v. W.L. Gore) — a medical-device patent, unrelated.
• US 6,604,135 family members — the parent US 5,701,451, and siblings US 5,721,908, US 5,752,246, US 5,745,754, US 5,793,964, US 5,710,918, and US 5,761,663. Search results did not disclose AIA proceedings against the '135 either; each would need its own docket check.

---

Strategic summary

Claim status: entirely UNTESTED at the PTAB. No claim of US 6,604,135 has been canceled, confirmed, or even construed by the Board, because no petition was ever instituted against it. There is no narrowing through IPR, no surviving-claim list to work from, and no FWD language to quote. For a defendant, that means the PTAB gives you no preclusive ammunition — but it also means the patent's validity has never been litigated in the AIA forum and remains an open question in district court, subject to §§ 102/103 on patents and printed publications and to § 112 and § 101 challenges that only a court (not an IPR) can hear.

Estoppel landscape: no § 315(e)(2) estoppel attaches to anyone. Because no IPR reached a final written decision, no petitioner, real party in interest, or privy is estopped from raising any ground against this patent — in the PTAB or in court. Conversely, a future defendant has no estoppel benefit from prior challengers. The § 315(b) one-year bar is also irrelevant on this record: with the patent expired and no live infringement suit identified, the practical driver is not the one-year clock but the absence of any current act of infringement. Note that an expired patent can still be the subject of an IPR (the Board applies Phillips-style construction to expired claims), so the absence of IPRs here is a function of commercial disinterest, not statutory ineligibility. CBM review was unavailable after 2020-09-16 and would now be time-barred in any event even if this patent's subject matter were CBM-eligible.

Pattern signals. No repeat-petitioner pattern exists — zero petitions. No patent-owner appeal pattern exists — no FWD to appeal. There is no defensive aggregator in the chain: this is not a Unified Patents or RPX-style challenge target, and Unified's public portal for US-6604135-B1 (https://portal.unifiedpatents.com/patents/patent/US-6604135-B1) shows only a bibliographic/prior-art page, not a challenge. The ownership trajectory is the most informative signal: IBM → Google (2011) → Google LLC, i.e., the patent sits inside the defensive portfolio of a large operating company. Google is not a known serial offensive assertor of this vintage of web-architecture patents. The realistic assertion risk is an NPE that acquires portfolio rights — and even then, the 2015 expiration caps the exposure.

What is genuinely worth investigating (and what I did not verify). I did not locate an infringement action asserting US 6,604,135. If you have received a demand letter, the more probative diligence is a district-court docket check (PACER / CourtListener RECAP) for the patent number, plus a chain-of-title pull from the USPTO Assignment database to confirm whether Google LLC still holds all rights — the ODP record shows corrective assignments in 2017 and 2024, so the title chain is worth confirming in the current reel/frame.

---

Recommended next steps

1. No PTAB activity exists — say so plainly to your client and in any demand-letter response. The absence of IPRs is itself a signal, but here the explanation is benign and documented: an expired patent (2015-06-07) held by a defensive owner. Do not represent to anyone that the patent "survived" PTAB review; it was never reviewed.
2. Confirm the negative with a primary source before relying on it. Run a patent-number search in PTAB E2E (https://ptacts.uspto.gov/ptabweb/) for Application/Control Number 09/369,625 and Patent 6,604,135, and an ex parte reexamination search in Patent Center (https://patentcenter.uspto.gov/). This takes minutes and converts my search-based negative into an evidentiary one.
3. Lead with expiration, not invalidity. The § 286 six-year lookback on a patent that expired 2015-06-07 means any recovery window closed on 2021-06-07. If the patent is being asserted now, the threshold question is what act of infringement is alleged to have occurred on or before that date.
4. Confirm current ownership. Pull the assignment history for Reel/Frame associated with the 2011-10-03 IBM→Google record and the 2024-03-04 corrective assignment (the ODP entry notes correction of incorrectly recorded application numbers 14/149,802 and 15/419,313). Confirm the asserted party actually holds enforceable rights.
5. If a live suit exists, the operative validity defenses are district-court defenses — §§ 101/112 are unavailable in an IPR, and the pre-AIA § 102(a)/(b) and § 103 art cited on the face of the patent (US 5,737,592 to Cisco; US 5,572,643 to Lakestar Semi; US 5,760,466/Netword; US 5,590,319 to Information Builders; plus the McArthur, Davison, and Slater non-patent literature) is the starting corpus, together with the parent patent US 5,701,451.

---

Sources consulted (all accessed 2026-09-30 unless noted): structured USPTO ODP "PTAB proceedings on file" block (canonical, returns zero proceedings); Google Patents, https://patents.google.com/patent/US6604135/en (legal events showing only assignments, no PTAB or litigation entries); PubChem patent record, https://pubchem.ncbi.nlm.nih.gov/patent/US-6604135-B1; Unified Patents portal, https://portal.unifiedpatents.com/patents/patent/US-6604135-B1; USPTO Patent Center assignment records. Negative-result searches covered IPR/PGR/CBM petition text, PTAB docket references, CourtListener, and the Federal Circuit docket. No PTAB or CAFC opinion for this patent exists to link.

I'll research the assignment/ownership chain for US 6,604,135. Let me run targeted searches to find the recorded assignment reel/frame data.

Let me search for the specific reel/frame records and the assignment history.

I've hit my search-step budget. Below is the best-supported reconstruction from the authoritative patent text plus the legal-event records I was able to retrieve. Note up front: I could not pull the exact reel/frame numbers or correspondent-of-record fields for the IBM→Google link within my search budget, and I flag that explicitly rather than guessing.

---

Inventors

• Employer basis: The patent states the related applications "have a common assignee, International Business Machines Corporation, Armonk, N.Y.," and the flow of the 1995 "WWW Kit" family was assigned to IBM. Both inventors are consistently IBM-associated across the family.
• Unusual-pattern check: No evidence of the "all inventors departing within 12 months" fire-sale tell. There is no record in the material I retrieved of either inventor leaving IBM around filing, and both recur as inventors across the same 1995 IBM family. This reads as a normal corporate R&D inventor pair, not a distressed-inventor pattern.

---

Original assignee

International Business Machines Corporation (IBM) — the entity named on the issued patent.

• Primary line of business: Enterprise hardware, software, and services; here specifically its decision-support / database middleware line (the Data Interpretation System, "DIS"/"IDS," and the OS/2 HTTPD Web server). The claims were embodied in IBM's "WWW Kit" (introduced December 1995, per the specification background), so IBM did ship product embodying the technology.
• Current status: Operating. IBM is a live, public, going-concern company (NYSE: IBM); it was not acquired, dissolved, or in bankruptcy at any material time in this chain.
• Key distinction: IBM divested this patent as part of a large strategic portfolio sale, not because IBM itself failed.

---

Assignment timeline

The chain is short and composed entirely of operating companies — there is no shell LLC step. The entries below are taken from the Google Patents legal-events record for US 6,604,135 (which mirrors the USPTO Assignment Center "reassignment" entries). Reel/frame numbers could not be confirmed for the 2011 link; I have not invented them.

1995-06-07 / recorded n/a — Reel not applicable (original filing)

• Conveyance: Original assignment / obligation to assign (inherent, pre-issuance)
• Assignor: Rogers, Richard Michael; Lagarde, Konrad Charles
• Assignee: International Business Machines Corporation
• Correspondent: Not retrieved
• Context: Original corporate assignment — inventors' rights vested in IBM as common assignee of the 1995 family.

2011-10-03 / recorded 2011-10-03 — Reel [not confirmed for this patent]

• Conveyance: Assignment ("reassignment" per Google Patents legal events)
• Assignor: INTERNATIONAL BUSINESS MACHINES CORPORATION
• Assignee: GOOGLE INC.
• Correspondent: Not retrieved — Google Patents lists this as part of the bulk IBM→Google recording; the 2011 IBM batches were filed at reels in the ~027xxx range (e.g., a contemporaneous IBM→Google batch reel 027463/0594 is publicly cited for that program), but I could not verify which reel/frame covers US 6,604,135, so I am not asserting one.
• Context: Strategic portfolio acquisition (defensive aggregation) — part of Google's 2011 IBM patent-purchase program (Google publicly framed these buys as defensive, to counter Android-related litigation).

2017-10-06 / recorded 2017-10-06 — Reel 44144/0001 (referenced)

• Conveyance: Change of Name (Google Patents labels it "reassignment… CHANGE OF NAME")
• Assignor: GOOGLE INC.
• Assignee: GOOGLE LLC
• Correspondent: Not retrieved
• Context: Internal reorganizational change of name only — no change in beneficial ownership. Note: the 2024 corrective record (below) references "REEL: 44144 FRAME: 1" as the prior record being corrected, which is consistent with this change-of-name entry.

2024-03-04 / recorded 2024-03-04 — Reel [associated with the 44144 record]

• Conveyance: Corrective Assignment (change of name correction)
• Assignor: GOOGLE INC.
• Assignee: GOOGLE LLC
• Correspondent: Not retrieved
• Context: Corrective/administrative cleanup only. Per the legal-event text, it corrects "THE REMOVAL OF THE INCORRECTLY RECORDED APPLICATION NUMBERS 14/149802 AND 15/419313 PREVIOUSLY RECORDED AT REEL: 44144 FRAME: 1."

Data limitation (stated plainly)

The USPTO Assignment Center exposes reel/frame and correspondent-of-record for each recording. My retrievable results confirmed the conveyance types, parties, and dates above but did not surface the reel/frame or correspondent fields for the 2011 IBM→Google link or the 2017/2024 Google records within my search budget. I am therefore marking correspondent data as not retrieved rather than fabricating it. Direct confirmation requires the Assignment Center lookup: https://assignmentcenter.uspto.gov/ (search "6604135").

---

Timeline diagram

timeline
    title Ownership of US 6604135
    1995 : Parent application filed by IBM
         : Inventors Rogers and Lagarde
    1999 : Divisional application filed
    2003 : Patent issued to IBM
    2011 : Assigned to Google Inc
    2015 : Patent term expired
    2017 : Google Inc renamed Google LLC
    2024 : Corrective name record filed

---

NPE / troll-pattern signals

1. Shell-entity transfer — Not present. The only substantive transfer moved the patent from IBM (operating) to Google Inc. (operating). No "IP/Licensing/Holdings/Ventures" entity appears anywhere in the chain; no single-purpose Delaware/Texas LLC is a recorded assignee.

2. Known asserter in the chain — Not present. Neither IBM nor Google Inc./Google LLC appears on the NPE directories referenced (Acacia, Marathon, IV, IPNav, Wi-LAN, Mosaid/Conversant, Vringo, Pendrell, Innovatio, MPHJ, Lumen View, Round Rock, etc.). Both are operating companies. (The similar-numbered but unrelated patents noted in the litigation summary — VirnetX's 6,502,135 and Bard's 6,436,135 — belong to different owners and must not be conflated here.)

3. Repeat correspondent across the chain — Unclear (not determinable). Correspondent-of-record was not retrievable for any link. There is no evidence of a recurring NPE-side filing attorney, and given the chain is IBM→Google with an internal change of name, the "one lawyer running the shells" tell is inapplicable on the present record.

4. Cascading transfers — Not present. Only one substantive ownership change (2011-10-03) across the patent's life, followed by a change of name (2017-10-06) and an administrative correction (2024-03-04). No chain of LLCs, no <24-month cascade.

5. Pre-litigation transfer — Not present. The prior litigation summary found no infringement suit naming US 6,604,135. The 2011 transfer occurred ~4 years before the 2015-06-07 expiry and is not proximate to any assertion.

6. Bankruptcy fire-sale — Not present. IBM was not in bankruptcy. The 2011 sale was a voluntary strategic portfolio divestiture (part of a multi-batch IBM→Google program of ~2,000+ patents tied to the post-Nortel patent arms race), not a Chapter 7/11 sale.

7. Privateering — Not present. No operating company transferred the patent to an NPE to assert on its behalf. Google acquired (did not outsource) the asset, and Google is the acquirer/assignee, not a transferor to an asserter.

8. Defensive aggregator (anti-NPE) — Not present in the formal sense, but functionally adjacent. The chain does not terminate at RPX, AST, LOT, Unified Patents, or OIN — it terminates at Google LLC, an operating company. However, Google's public position in the 2011 IBM purchases was explicitly defensive ("one of a company's best defenses… is to have a formidable patent portfolio"). So the practical effect is a neutralized, never-asserted asset, even though the assignee is not a listed defensive aggregator.

---

Verdict

Defensive / non-asserting

Justification: The ownership chain is a straight line of operating companies — inventors → IBM (original assignee, ~1999–2011) → Google Inc. on 2011-10-03 (Google Patents legal events) → Google LLC via a change of name recorded 2017-10-06 (reel 44144/0001 per the 2024 correction) → an administrative corrective name record on 2024-03-04. There is no shell-entity step, no NPE assignee, no cascading LLC transfers, and no pre-litigation transfer, and the prior analysis found no suit asserting this patent; it expired 2015-06-07. The one caveat is definitional: the chain terminates at Google LLC, an operating company, not a listed defensive aggregator, so this is best read as a defensively held, never-asserted, now-expired asset rather than an RPX/AST-style neutralization.

Why not "NPE": zero of the "strong" NPE signals are present — the shell-entity and known-asserter signals (the two most probative) are affirmatively not present, and the record shows operating company → operating company.

Verification links:

• USPTO Assignment Center (search "6604135"): https://assignmentcenter.uspto.gov/
• Google Patents legal events for US 6,604,135: https://patents.google.com/patent/US6604135/en

Residual uncertainty: I could not verify reel/frame for the 2011 IBM→Google assignment or the correspondent-of-record on any link. A court-record-grade confirmation should pull those fields directly from the Assignment Center. Everything above that is stated as fact rests on the patent text and the Google Patents legal-event entries; where I lacked data I said so and did not infer.

I'll research the USPTO record and prior-art citations for US 6,604,135 (US6604135B1). Let me run several targeted searches.

I have the citation list. Now I need the actual claim text of US 6,604,135 to map prior art to claims, plus the full bibliographic details. Let me search.

I hit my search-step limit, so here is my analysis based on the USPTO/patent-office record I retrieved. Two transparency notes are important up front, because they affect every "anticipation" answer below.

---

A. USPTO record for the specific number 6604135 (no similar numbers)

The identifier 6604135 = US 6,604,135 B1 (US6604135B1). I confined results to this number and excluded look-alikes (6,502,135 VirnetX; 6,436,135 Bard).

Source: https://patents.google.com/patent/US6604135 , https://portal.unifiedpatents.com/patents/patent/US-6604135-B1

---

B. Claim-text caveat (must read before the §102 table)

I do not have the verbatim claim set of US 6,604,135 in front of me, and I will not fabricate claim numbers. The authoritative full text supplied to me stops in the "Detailed Description" (FIG. 8 control-program steps) before the "What is claimed is…" section. Therefore, in the table below I identify the claim subject matter each reference maps to (drawn from the patent's own Abstract, Summary, and the closely related sibling claim set of US 5,974,441, which I did retrieve at https://patents.google.com/patent/[US5974441A](/patent/US5974441A)/en), and I mark precise claim-number mapping as unverified. If you need court-grade claim-by-claim ¶102 charts, I can produce them once the '135 claim set is supplied — a definitive pull is the USPTO PatentCenter "Claims" tab for US 6,604,135.

Also note a second, structural caveat: the references below are the "References Cited" / "Patent Citations" printed on the face of the patent (the examiner's considered-art list). Being cited is not the same as anticipating. For a §102 rejection, a single reference must disclose every element of a claim; most of these were cited as background or as §102(e) art for specific elements.

---

C. Patent citations of US 6,604,135 (U.S. patent documents)

Dates are as reported in the patent-record listings; where I have lower confidence I say so. Citations are as printed (I do not auto-correct).

Composite corroboration of the face-citation list: PubChem patent record (https://pubchem.ncbi.nlm.nih.gov/patent/US-6604135-B1) and the Unified Patents patent page (https://portal.unifiedpatents.com/patents/patent/US-6604135-B1) both list the same set — US 4,274,139; 4,774,655; 4,982,344; 5,204,947; 5,297,249; 5,317,688; 5,355,472; 5,367,635; 5,408,619; 5,495,605; 5,522,070; 5,530,852; 5,535,336; 5,572,643; 5,590,321; 5,590,319; 5,701,451; 5,737,592; 5,742,762; 5,761,656; 5,764,906; 5,809,144.

---

D. Non-patent literature cited (5 items)

---

E. Which prior art is most relevant, and the honest §102 bottom line

Most relevant (ranked):

1. US 5,737,592 (Web→relational-DB via macro files) and US 5,590,319 / 5,590,321 (heterogeneous multi-database query processing) — these map most directly onto the '135 patent's core novelty: a single browser request causing retrieval from multiple heterogeneous databases processed by a decision-support layer.
2. US 5,355,472 and US 5,572,643 — dynamic tag/HTML generation and dynamic in-browser display, i.e., the "dynamically create HTML statements to present the report" element.
3. The OpenDIS Access Service manual and Davison (HTML forms) — the CGI/ODAS invocation-and-parameter-passing element.
4. US 5,701,451 (Rogers, IBM) — same family; cited for the overarching "fulfill a web-browser request via a control program agent" concept, not independent prior art to '135.

Bottom line on anticipation (§102): I could not, and should not, assert that any single listed reference anticipates a specific claim of US 6,604,135. The record shows these as art considered during prosecution of the '135 divisional and its parents; the claims were nevertheless allowed and the patent granted 2003-08-05. The most that can be substantiated from the record alone is element-level (§102(b)/(e)) relevance as tabulated above. A definitive §102 chart requires (a) the '135 claim set and (b) full texts of the individual references.

---

F. Contradictions / cross-checks against the earlier sections

• Identifier consistency: The earlier litigation section used "US 6,604,135"; the current task uses "6604135." These are the same patent (US 6,604,135 B1) — no correction needed, and no conflict.
• One substantive finding worth flagging from my searches (new relative to the earlier sections): This Rogers/Lagarde family was itself used as prior art against another patent — in the reexamination of US 6,415,335 (Parallel Networks), Art Unit 3992, control no. 90/008,342, and in IPR2015-01734, the "Rogers" reference (the IBM web-browser/CGI/ODAS disclosure) was applied against the challenged claims (see https://ptacts.uspto.gov/ptacts/public-informations/petitions/[1464075](/patent/1464075)/…). That is the reverse direction (the '135 family as art), but it confirms the family's technical significance and is highly relevant if you are assessing the '135 patent's own validity exposure.
• Caveat retained: My §102 claim-number mapping is unverified because the verbatim '135 claims were not in the supplied text. Treat the "claim subject matter" column as a qualified, element-level assessment, not a legal conclusion.

If you can paste the "What is claimed is…" section (or authorize a USPTO PatentCenter claims pull), I will convert Section C into a strict claim-by-claim §102(c)/(e) matrix.

I'll ground this analysis by verifying the claim text and locating the actual prior-art references cited on the patent's record, plus contemporaneous art in the same field.

Let me pull the actual granted claim language for US6604135 and check the recorded prior-art references cited on its face.

Obviousness Analysis — U.S. Patent No. 6,604,135 (35 U.S.C. § 103)

Prepared: April 26, 2026 · Patent: US 6,604,135 B1, "WWW client server dynamic interactive system method" (Rogers & Lagarde; IBM → Google LLC; priority 1995‑06‑07; filed 1999‑08‑06; granted 2003‑08‑05; expired 2015‑06‑07)

---

0. Two threshold corrections/flags before the analysis

Flag 1 — I now have verified claim text for the siblings, not for '135 itself. The earlier sections correctly said the '135 claim set was not retrievable from the truncated full‑text capture. Partial correction: I have now retrieved the granted claim sets of two same‑family, same‑inventor, same‑specification siblings — U.S. 5,701,451 ("Method for fulfilling requests of a Web browser," claims 1–34, https://uspto.report/patent/grant/5701451) and U.S. 5,752,246 ("Service agent…," claims 1–34, https://uspto.report/patent/grant/5,752,246) — plus U.S. 5,793,964 ("Web browser system," claims 1–30, https://companyprofiles.justatic.com/patent/5793964) and the European counterpart claims (EP 0 747 842 B1, https://patentimages.storage.googleapis.com/e3/26/c1/2bc9eeeaadf3e5/EP0747842B1.pdf). These use the identical disclosure as '135. Everything below therefore analyzes the disclosed subject matter and the family's claim vocabulary, and I flag where the exact '135 wording could change the answer. I still do not have the numbered claims of US 6,604,135 verbatim and will not pretend otherwise.

Flag 2 — which sibling's claim style does '135 carry? '135 is a divisional of 08/761,684 (→ US 5,974,441), which is a CIP of 08/474,577 (→ '451). A divisional repeats the parent's disclosure, so '135's claims are most likely method/apparatus claims of the "fulfilling requests of a Web browser / service agent" type ('451/'246 style), not necessarily the "web browser system" apparatus claims of '964 (a different application, 08/479,481). This matters because the '964 claims recite a plurality of control‑program‑agent nodes and multi‑gateway INR routing ('964 claims 3, 4, 10, 14–16), whereas the '451/'246 claims are single‑agent, single‑ODAS. I analyze both scenarios.

---

1. Governing law and the effective filing date (this drives everything)

Pre‑AIA §102/§103 apply (application filed 1999‑08‑06; AIA first‑to‑file applies only to applications filed on/after 2013‑03‑16).

The '135 specification has two disclosure dates:

Practical upshot: any '135 claim that recites (or is argued to be enabled only by) the Java/applet/sockets/OLAP subject matter cannot reach back to 1995‑06‑07. That single point is the most powerful §103 lever available, because the 1995–1996 window contains Popp, Illustra, Clausnitzer, Netscape 2.0/Java 1.0, Oracle WebServer/WebAgent, Sybase web.sql, and Microsoft IIS/IDC.

1.1 Applicant's own family is not prior art (and I flag a timing wrinkle)

The '451, '246, '964, '908, '754, '918, '663 and '441 patents name Rogers and Lagarde (verified for '451, '246, '964). Under pre‑AIA §102(e) a reference must be "by another." Same inventive entity ⇒ not prior art at all, irrespective of common ownership. Where any family member names a different inventive entity, the fallback is pre‑AIA §103(c) common‑ownership disqualification — but note a genuine wrinkle: the narrow (1984) version of §103(c) disqualified only §102(f)/(g) art, not §102(e); the AIPA amendment adding §102(e) took effect Nov. 29, 1999, after this application was filed (Aug. 6, 1999). I am not fully certain how the USPTO/PTAB resolved that retroactivity question, and it should be verified before relying on §103(c). Practical conclusion either way: the obviousness attack on '135 must be built on third‑party art. This is why the analysis below is structured around GSQL/NCSA CGI, Harvest, the Metaphor OpenDIS manual, Clausnitzer, Illustra, Popp, Cheswick & Bellovin, and the on‑face references.

---

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

A POSITA at the 1995–96 window would be a software engineer with ~2–3 years' experience in network programming, holding: (a) working knowledge of HTTP/HTML forms and CGI as documented by NCSA (CGI in use "since 1993," RFC 3875 §1, https://www.rfc-editor.org/rfc/rfc3875.html); (b) familiarity with server‑side database middleware (SQL gateways); and (c) awareness of the object/agent architecture literature (Harvest, IRDS, CICS function shipping). For the Java‑dated claims, add familiarity with Java applets as promoted from late 1995/January 1996.

---

3. Claim‑element decomposition (family vocabulary; '135 wording flagged)

---

4. Combination Set A — the core architecture (counters E1–E8; also E6/E7)

A‑1. NCSA CGI specification / NCSA httpd (1993) — "CGI … allows an HTTP server and a CGI script to share responsibility for responding to client requests… The server acts as an application gateway. It receives the request from the client, selects a CGI script to handle the request, converts the client request to a CGI request, executes the script and converts the CGI response into a response for the client" (RFC 3875 §§1.1, 3.1, https://www.rfc-editor.org/rfc/rfc3875.html; CGI in use "since 1993"). This alone maps E1, E2, E3 (PATH_INFO/QUERY_STRING meta‑variables, §4.1.5/4.1.7) and the server‑side‑API framing of the '135 abstract.

A‑2. Ng, "GSQL — a Mosaic‑SQL gateway" (NCSA, Dec. 1993) — "GSQL is a gateway program that provides a forms interface in Mosaic to SQL databases. It creates forms based on commands found in proc files, and then assembles the user inputs into a SQL query that a DBMS can process" — with documented backends for Sybase, Oracle, Interbase, Illustra/Postgres, Ingres, and MS‑SQL/Windows NT (archived at http://web.archive.org/web/19961220063049/http://www.ncsa.uiuc.edu/SDG/People/jason/pub/gsql/starthere.html; also cited in the '451/'964 IDS and in US 7,269,591 at https://patentimages.storage.googleapis.com/34/16/77/6d964a89ca8c2d/[US7269591B2](/patent/US7269591B2).pdf). GSQL maps E1–E3, E6 (heterogeneous DBMSs behind one gateway), E7 (single form → one SQL query against a chosen heterogeneous backend), E8 (results returned as an HTML page).

A‑3. Bowman et al., "Harvest: A Scalable, Customizable Discovery and Access System" (Tech. Rep. CU‑CS‑732‑94, Aug. 1994) and Obraczka et al., "Internet Resource Discovery Services," IEEE Computer, Sept. 1993, pp. 8–22 (both cited on the face of '451/'964). Harvest teaches a distributed broker/gatherer architecture in which a front‑end broker receives a request and delegates to distributed gatherers/servers — supporting the "control program agent organizes distributed sub‑agents" element and the multi‑server aspect of E11.

A‑4. Metaphor/IBM, "Developing Applications with OpenDIS Access Service," DIS Release 2.0, 1st ed., Sept. 1994 (cited on the face of '451, '246, '964 and expressly incorporated by reference into the '135 specification itself: "the reader is referred to the … 'Developing Applications with OpenDIS Access Service, Version 2.0' … which is incorporated herein by reference"). It teaches exactly E4/E5: an API by which a program invokes DIS capsules that query, calculate, format and graph results.

Motivation to combine (A)

1. Express motivation in the references themselves. RFC 3875 §3.1 states the server's role is to act as an "application gateway" that "selects a CGI script." GSQL shows the very next step — a CGI gateway that builds and executes SQL and returns results — and expressly advertises multiple heterogeneous DBMS backends. The OpenDIS manual shows a documented API for invoking programmable retrieve‑calculate‑format‑graph jobs. A POSITA wanting to give Web users access to corporate data behind a query tool would have looked to precisely these three, because together they supply the client protocol, the gateway pattern, and the programmable back end.
2. Simple substitution (KSR factor: substituting one known element for another). GSQL's per‑DBMS "backend routine" (execute-sql(), see its install instructions) is a known, interchangeable module. Substituting the OpenDIS API call for that hard‑coded backend is a substitution of one known invocation mechanism for another to obtain a known, predictable improvement — graphical/calculated output rather than GSQL's text‑only result — which is the very improvement the OpenDIS manual promises and which the '135 spec touts ("colored pie charts, line graphs, bar graphs").
3. Known technique applied to a known device ready for improvement. GSQL's own documentation flags the limitation ("sqlmain is the database backend program that processes queries"; text results). Adapting the CGI gateway to call a report engine was a "predictable variation" the art already pointed to.
4. The applicant's own specification supplies the motivation. The '135 Background concedes the stateless CGI model, that "most processing of data is performed on the server, usually in the form of CGI programs," and that the problem to be solved is server‑side orchestration of multi‑source queries. Under KSR, a statement of the problem in the specification that the prior art was already addressing is a legitimate motivation source.

Result: E1–E8 (and, with Clausnitzer/Illustra below, E6/E7 in full) are rendered obvious by A‑1 + A‑2 + A‑4 (CGI/NCSA + GSQL + OpenDIS manual), optionally with A‑3 (Harvest) for the distributed‑sub‑agent element.

---

5. Combination Set B — the multi‑server / distributed‑query claims (counters E6, E7, E10, E11)

This is the combination the USPTO and PTAB actually applied against the same inventors' related disclosure in the 90/008,342 / 90/008,562 / 90/008,574 reexaminations and IPR2015‑00486 / ‑01732 / ‑01734, so it is well‑documented in the public record.

B‑1. Clausnitzer et al., "A WWW Interface to the OMNIS/Myriad Literature Retrieval Engine" (1995) — as characterized in the reexamination record: "A CGI program is connected to a HTTP server as well as to several OMNIS database servers. The CGI program sequentially distributes incoming client requests to OMNIS servers and returns their query results … back to the HTTP server" (90/008,342 record, reproduced in IPR2015‑01732, Ex. 1003 pt. 4, https://www.docketalarm.com/cases/PTAB/IPR2015-01732/Inter_Partes_Review_of_U.S._Pat._6415335/docs/08-14-2015-Petitioner/Exhibit-1003-4-Ex_1003_part_4.pdf). This maps directly onto E6/E7/E11 — one CGI gateway fanning a request out to a plurality of remote servers and returning combined results.

B‑2. Gaffney, "Illustra's Web DataBlade Module," SIGMOD Record 25(1), March 1996 — "A CGI application connects to a database, builds and executes SQL statements, and formats results"; "Webdriver, a CGI based application performs as a dispatcher" (ibid.). Maps E2, E3, E5, E6, E8.

B‑3. U.S. 6,249,291 to Popp et al. (filed Sept. 22, 1995; issued 2001) — HTTP server 206 + CGIMessenger 210 + Application 214 that "returns a Web page … dynamically generated using complex queries (or other data retrieval mechanisms) to retrieve data and dynamically generate an HTML page," with Application 214 able to "access an external data source such as database 224" (reexam record, IPR2015‑01732 Ex. 1003 pt. 4, pp. 86–88). Maps E1, E2, E3, E6, E8 and, because CGIMessenger/Application may run "on the same or different server," E10.

B‑4. Cheswick & Bellovin, "Firewalls and Internet Security" (Addison‑Wesley, 1994), chs. 3–4 (cited on the face of '964) — supplies E10 (firewall boundary; placing the data‑bearing internal server behind it while the public web server faces the Internet).

Motivation to combine (B)

• Addressing a recognized problem by known means. The '135 Background states the unmet need: "coupling of resources available on a company's intranet and those available on the Internet has not been resolved… There is a need to reduce gateways, make better use of existing equipment, and allow greater and more effective usage of information which is resident in many different databases on many different servers, not only within a homogeneous network but also via the Internet and heterogeneous network systems." Clausnitzer and Illustra are the art's answer for "many different databases"; Cheswick & Bellovin is the art's answer for "Internet‑facing server, protected data."
• Explicit reexam‑record motivation. The examiner's own words in the 90/008,342 file history are a textbook KSR motivation statement: "It would have been obvious to modify Rogers with Caccavale's teachings to … 'allow greater and more effective usage of information which is resident in many different databases on many different servers, not only within a homogeneous network but also via the Internet and heterogeneous network systems'"; and "Consideration of network performance and calculated management of server usage was well understood in the art… Consideration of dynamic information such as the number of requests being processed at each page server and resources available … would be obvious when selecting which page server should service a request" (IPR2015‑01732 Ex. 1003 pt. 4).
• Combination of familiar elements according to known methods. Clausnitzer (CGI→several DB servers) + Popp (CGI messenger → application that dynamically generates HTML from a database) is a combination of two server‑side CGI dispatch designs, each of which already contained most of the other's elements; the combination adds nothing more than predictable aggregation.

Result: E6, E7, E10, E11 are rendered obvious by A‑1/A‑2 + B‑1 (Clausnitzer) + B‑2 (Illustra) + B‑4 (Cheswick & Bellovin), with B‑3 (Popp, §102(e)) supplying the "dynamically generated HTML page from database content" element.

---

6. Combination Set C — the Java/applet/sockets/OLAP claims (counters E12)

Applicable only if these claims are held to the Dec. 6, 1996 CIP date.

C‑1. Java 1.0 / HotJava (publicly released Jan. 23, 1996) — teaches an object‑oriented language downloaded from a web server as an applet and executed by an interpreter inside a browser; the '135 spec's own glossary defines Java in exactly those terms ("programs can be downloaded from a web server and run on any client machine that has a browser containing the interpreter"), i.e., the spec adopts the art's characterization.

C‑2. Netscape Navigator 2.0 (Jan. 1996) — the first mainstream browser with applet/plug‑in interactivity; supplies the client vehicle.

C‑3. Any of A/B (CGI database gateways) + TCP/IP sockets (the '135 spec: "TCP/IP's lower level means of connecting and transferring data between computers in a network") — a POSITA already had the server‑side query engine and the transport.

Motivation to combine (C)

• KSR: "use of a known technique to improve similar devices in the same way." The '135 Background identifies the exact defect the applet model cured: "the browser/server communication is a stateless environment… most processing of data is performed on the server… the client processing is restricted to the browser displaying the data, or calling a helper application… Further communication with the server requires a new connection." Java applets + a persistent socket to the server‑side agent are the known, off‑the‑shelf remedy for exactly that defect. Stated as a goal in the specification and solved by an available, documented technique, the combination is obvious.
• Design incentive / market pressure. The January 1996 launch of Java was accompanied by explicit industry messaging that interactive client‑side processing was the next step for web data access — the kind of "market pressure" the Federal Circuit credits in KSR.
• Obvious to try with a finite solution set. Once applets existed, moving the presentation and manipulation layer (charts, drill‑down, multidimensional "OLAP" views) to the client while leaving data access server‑side was one of a small number of predictable architectures.

---

7. Combination Set D — the alternative‑output claims (counters E9)

'451 claims 25–27 / '246 claims 25–27 recite routing output to "a group of possible output units, comprising facsimile, printer, retail and banking installations, or … full motion videos or still frames … including television units."

• Base: any of A/B (a web gateway that has produced a result file).
• Secondary: TCP/IP Sendmail (expressly named in the '135 spec as "i.e. TCP/IP Sendmail facility"), conventional fax servers, voice response units, and MPEG‑1/MPEG‑2 streaming (the '135 spec cites "MPEG 2 and MPEG 1 protocol images"; the spec's own hardware paragraph names "X.25 Data Switch," "modems," "Network I/F Bus").
• Motivation: the claim itself recites a genus ("selected from a group"); under KSR, where a claim recites a list of alternative known delivery channels, enumerating the alternatives the art already offered is a predictable variation. There is no asserted criticality or unexpected result for any member of the group.

---

8. KSR rationales, consolidated

---

9. Objective indicia (secondary considerations)

I found no evidence in the record of: unexpected results, long‑felt but unsolved need, failure of others, copying, or industry praise with a nexus to the claimed subject matter. Two items warrant caution rather than reliance:

• The family was commercially deployed (the '451 FIG. 4 screenshot reads "DIS WWW GATEWAY," and IBM's WEB Kit is referenced in the spec), but commercial success alone, without a nexus, carries no weight, and the later assignment of the asset to Google (2011) is a portfolio transaction, not evidence of nonobviousness.
• IBM itself used the Rogers disclosure as prior art against third parties in the 90/008,342/‑562/‑574 reexams and IPR2015‑00486/‑01732/‑01734 against U.S. 6,415,335 — evidence that IBM treated this architecture as the state of the art, though it is not prior art against '135 itself.

---

10. Where a §103 attack is weak (be candid)

1. E11 / "informed selection among a plurality of servers." In the '335 reexaminations the patent owner successfully argued that the Rogers disclosure has only "one ODAS server 12(74)" and "a lone control program agent in a web server… Therefore, there is no dispatcher… [and no] ability to examine the request to make an informed selection of which Page server should process the request" (IPR2015‑01734, Ex. 1003 pt. 3, https://www.docketalarm.com/cases/PTAB/IPR2015-01734/Inter_Partes_Review_of_U.S._Pat._6415335/docs/08-14-2015-Petitioner/Exhibit-1003-3-Ex_1003_part_3.pdf; ptacts.uspto.gov petition papers). Two consequences: (a) if '135 claims recite a dispatcher / informed selection among page servers, that limitation survived the closest real‑world obviousness attack and should be expected to survive again; conversely (b) if '135 claims recite a plurality of DIS servers and INR coupling (as '964 claims 3–5, 10, 15, 19 do), then the patent owner's own characterization of the Rogers family as single‑server is an admission that could be used against those claims — an uncomfortable bind I would exploit in negotiation.
2. The "it's just GSQL" objection. The '135 specification itself distinguishes GSQL: "This system is unlike the present invention." Mere disparagement in the applicant's own specification is weak (KSR), but it does show the inventor contemplated and distinguished the reference, which is a non‑trivial secondary‑consideration‑adjacent fact.
3. Java‑era subject matter. The lack of a pre‑1996‑12‑06 enabling disclosure of applet/socket/OLAP subject matter is a §112/priority vulnerability, not an obviousness win — but it is the hinge: if the CIP date governs, the 1995–96 art floodgates open; if not, C‑1/C‑2 are unavailable and E12 must be attacked with 1996 art.
4. Claim‑wording risk. Because I could not read '135's claims verbatim, every conclusion above is provisional on claim scope. A claim reciting only "receiving a browser request at a server-side API and, as an agent of the browser client, returning a report" is very likely obvious under A. A claim reciting dispatcher‑style informed selection among a plurality of page servers based on dynamic load information is likely not obvious over A/B and was, in fact, upheld against this very art in the '335 proceedings.

---

11. Bottom line

The single most important caveat stands: I have verified claim text for the siblings '451, '246 and '964 and the EP counterpart, but not for US 6,604,135 itself. Before relying on any of the above for a validity opinion, pull the granted claims of 6,604,135 from USPTO PatentCenter or the Google Patents claims tab at https://patents.google.com/patent/US6604135/en and re‑run §3's element chart against the actual numbered limitations — particularly any limitation reciting a plurality of servers, a dispatcher, or dynamic selection information, which is where this family's validity has historically been won or lost.