US 6539494

I'll search for the specific patent number and any CAFC 2026 docket activity.

Let me do one more targeted search on litigation/docket activity for this patent.

US Patent 6,539,494 — Analyst Summary

Scope note on the searches: I searched for the literal number 6539494 (title, USPTO/Google Patents record, and CAFC 2026 docket/appellate activity). The patent record is well-corroborated. I found no CAFC 2026 docket, appeal, or Federal Circuit activity for this specific patent number. The only "CAFC 2026" result retrieved was a generic Federal Circuit update PDF that does not mention 6,539,494, and a court document referencing an unrelated "'949 patent" (U.S. 8,878,949). I therefore cannot confirm any 2026 appellate activity, and given the patent expired in 2019 (see below), active 2026 litigation is unlikely. I am flagging this as an absence of evidence rather than proof of no activity — I do not have authoritative docket access.

Bibliographic Data

Per the operating rules, all identifiers above are reproduced literally from the record; consistent with Google Patents, the source renders the primary number as "US6539494B1."

Abstract

A computer system for a web site uses three tiers of servers — web (HTTP) servers, application servers, and backup servers. The backup servers back up session data for particular application servers. Each web session is assigned a session ID that encodes the IP addresses of the application server and its backup server, plus a unique identifier for the session within that application server. A session is automatically routed to a second application server if the first application server should fail or not have the requested application. The request carries the original session ID. The second application server detects from the session ID that the session may have been handled by the first server, decodes the backup server's IP address, connects to that backup server, and recovers the session data — reconstituting it into a new session with a new session ID. If the session had previously existed on the second application server, the second server's existing session ID and session data are used, updated with data from the first backup server.

Plain-Language Overview of Each Independent Claim

Claim 1 — System with multiple app servers + backup server (transparent recovery)
A computer system with (a) several application servers, each keeping session data for the user session assigned to it, and (b) a backup server coupled to them that keeps a backup of session data for a first application server. When a second application server receives a service request that does not correspond to any user session it is hosting, it fetches the backed-up session data from the backup server. The switchover is transparent to the user.

Claim 16 — System with web server, app servers, and per-server backup assignment
A system with a web server; multiple application servers where a user session is assigned to one app server that maintains its session data; and a group of at least one backup server. Each application server is assigned to one backup server, and each backup server backs up session data for at least one app server. The session gets a session ID, and the second app server assigns a different session ID. When the second app server receives a request (from the web server) that doesn't match a session it hosts, it obtains the backup of session data from the backup server to which the first app server was assigned. Again, the transition is transparent to the user.

Claim 17 — Method for transferring a session
A method comprising: assigning a user session to a first application server; assigning a first session ID; sending a service request (including the first session ID) to a second application server; determining whether the request corresponds to a session hosted by the second app server; retrieving the user session's data from a backup server assigned to the first app server; and assigning a second session ID. The retrieval from the first server to the second server is transparent to the user.

Claim 28 — Single app server + backup server, with session-ID list comparison
A system with an application server that maintains session data for its assigned user sessions and assigns each a session ID, plus a backup server that maintains a backup of session data for a user session. The application server fetches the backup from the backup server if it is not hosting the user session. It determines it is not hosting the session by comparing the session ID against a list of session IDs it is currently hosting. The transfer of session data to the application server is transparent to the user.

Key Dependent-Claim Concepts (brief)

• Claims 2–5: session ID uniquely identifies the session and identifies the application server and the backup server.
• Claims 6–9: new session ID assignment when the second app server is not hosting the session / the session ID doesn't point to it.
• Claims 10–12: session-alias table (in a separate alias server or in the backup server) tracking equivalent session IDs across app servers.
• Claims 13–15: web server routing, failover routing, and a load manager polling app servers for load information.
• Claims 18–27: details of the method — identifying the backup server from the session ID, equivalence lists, updating the second app server's backup server and the first's backup server, and merging recovered/updated session data.

Context and Uncertainty Notes

• Assignee chain (from the record): Art Technology Group, Inc. → security agreements with Silicon Valley Bank (2004, 2006) and release (2010) → Oracle OTC Subsidiary LLC (2012 merger). Current assignee per the record is Oracle OTC Subsidiary LLC. I cannot independently verify present-day ownership beyond the recorded assignments.
• Expiration: Anticipated expiration June 17, 2019 (20 years from the 1999 filing), status "Expired – Lifetime."
• Related family: EP 1 192 545 B1 (granted European counterpart) and WO 2000/079391 A1, with national counterparts in DE, ES, and AT.
• Notable prior art cited: U.S. 5,951,694 and 5,956,489 (Microsoft); U.S. 6,058,424 (IBM); U.S. 6,076,108 (i2 Technologies); U.S. 5,796,934 (Oracle); U.S. 5,852,724 (Veritas).
• Notable forward citations: U.S. 8,090,829 (Oracle America, backup-server selection), US 2003/0014526 (Pullara, session replication), U.S. 7,254,634 (Akamai, CDN web-tier session state), U.S. 7,437,594 (AOL, server-side session management).
• Uncertainty: I could not identify any CAFC 2026 docket activity or pending IPR for 6,539,494. No assertion is made that none exists; the search simply returned nothing specific to this number.

I'll search for litigation involving US patent 6539494.

Let me search more specific sources for litigation records.

Let me try more targeted searches on dedicated patent litigation sources.

Litigation Search Report — U.S. Patent No. 6,539,494

Patent identified: U.S. Patent No. 6,539,494 B1, "Internet server session backup apparatus"

• Application No. 09/335,004; filed June 17, 1999; granted March 25, 2003
• Inventors: Nathan Abramson, Joseph T. Chung
• Original assignee: Art Technology Group, Inc.; current assignee of record: Oracle OTC Subsidiary LLC
• Status: Expired – Lifetime (anticipated expiration June 17, 2019)
• Family: WO2000079391A1, EP1192545B1, DE60014645T2, ES2230116T3, ATE278985T1

Result: No litigation located

Based on the searches I was able to run (web searches against patent-litigation aggregators and general web sources, including attempts to reach the Unified Patents litigation/PTAB caselist, and searches for the patent number, the title, and the assignees), I did not find any evidence of litigation involving U.S. Patent No. 6,539,494 — no district court case, no CAFC appeal, and no PTAB proceeding.

I want to be explicit about the limits of this conclusion rather than overstate it:

1. I could not complete direct database queries. My tool budget was exhausted before I could run dedicated queries against PACER, the CAFC docket, or the Unified Patents portal caselist at https://portal.unifiedpatents.com/litigation/caselist. The searches I did run returned general litigation statistics and unrelated cases, not patent-specific records for this number.
2. Search hits for "949" were for different patents and must not be confused with 6,539,494. In particular:
   • U.S. Patent No. 7,949,494 (Blue Spike v. Clovolution USA, E.D. Tex.) — a different patent.
   • U.S. Patent No. 8,878,949 (Gesture Technology Partners / Apple IPR2021-00921) — a different patent.
   • The "'949 patent family" in MPH Technologies v. Apple (N.D. Cal. 4:22-cv-06603, per the CourtListener filing referencing Case No. 4:22-cv-) — again different patents.
   • EP 3590949B1 ("EP'949") in the Moderna v. Pfizer/BioNTech European proceedings — a different, unrelated patent.
     None of these is U.S. 6,539,494.
3. The record hits I did find are citations, not litigation. U.S. 6,539,494 appears as a cited prior-art reference (e.g., a Justia "referenced by" listing for U.S. 8,181,111, and as a search-report citation in RU 2365046 C2, a Microsoft "Routing hints" family member). Citations of a patent as prior art are not assertions of that patent and are not litigation.

Practical context

Consistent with the absence of found litigation, several record facts make an enforcement campaign unlikely:

• The patent expired in 2019, well before the current date.
• It was assigned to a large operating company (Oracle) rather than a known asserting entity, and its prosecution/ownership chain shows ordinary corporate reassignments (Art Technology Group → Silicon Valley Bank security interests → releases → Oracle OTC Subsidiary LLC merger in 2012), not transfers to a litigation vehicle.
• It is classified in failover/redundancy arts (G06F11/2023, G06F11/203) and has a very large forward-citation count, but forward citations alone do not indicate assertion.

Bottom line

No known litigation involving U.S. Patent No. 6,539,494 was located. I therefore cannot provide plaintiff(s), defendant(s), jurisdiction, case number, filing date, or status for any case. If a definitive, exhaustive confirmation is required, the next step would be a direct docket query (Lex Machina / Docket Navigator / PACER "Patent Number" search and the Unified Patents portal) for US 6,539,494 — I was unable to complete those queries here and am flagging that gap explicitly rather than asserting a negative I could not fully verify.

I'll verify the structured PTAB block against live search before writing anything up.

Let me check for litigation context and any Unified Patents / aggregator involvement.

US 6,539,494 — AIA Trial Proceedings Report

Source hierarchy: The structured "PTAB proceedings on file" block from the USPTO Open Data Portal is canonical and controls here. It states: "The USPTO ODP API returns no AIA trial proceedings for this patent as of the most recent ingest." Live web search corroborates. No proceeding numbers are supplied, and per the operating rules I will not invent any.

Proceedings overview

Total AIA trial proceedings on file: 0 — zero active, zero claims-invalidated, zero claims-sustained, zero settled, zero institution-denied. There is no PTAB record to litigate from. The bottom-line defensive posture is therefore not "the patent has survived IPRs and is hardened," but rather the far stronger position for a defendant: there is no adverse PTAB estoppel, no IPR survivorship finding, and — critically — the patent expired on 2019-06-17, so its entire enforceable life ended more than seven years before today's date (2026-09-29). Any assertion today faces a zero-dollar recoverable-damages window (see Strategic summary) regardless of validity.

Proceedings

No AIA trial proceedings on file

• Type: N/A — no IPR, PGR, or CBM was ever filed against US 6,539,494.
• Filed: N/A.
• Status: N/A.
• Judge panel: N/A — no panel ever convened.
• Petition grounds: N/A.
• Institution decision: N/A.
• Final Written Decision: N/A. No claim of US 6,539,494 has ever been canceled or held unpatentable by the PTAB. All 28 claims (4 independent — 1, 16, 17, 28 — and 24 dependent) stand as issued, untested at the PTAB.
• Settlement / termination: N/A.
• Appeal: None to the Federal Circuit arising from a PTAB proceeding. This is consistent with the prior section's finding of no CAFC 2026 docket activity for this patent number.
• Defensive value: A defendant cannot point to a canceled claim, and equally cannot be estopped. Because no petitioner ever went through trial, there is no § 325(e)/§ 315(e) estoppel running against anyone, and no third party has pre-litigated the validity question. That cuts both ways — it means the prior art has not been judicially tested, but it also removes the "hardened patent" narrative the owner would need.

Search verification performed (2026-09-29): Searches on the literal number, "IPR" + the title, "Art Technology Group" + litigation, and Unified Patents/aggregator activity returned no petition, no PTAB docket, and no district-court complaint naming US 6,539,494. The patent appears in the wild only as a cited reference (e.g., in Microsoft's WO 2005/020085 "Routing hints" family and in numerous later session-management filings). A result citing 6,539,494 as prior art is not evidence of a proceeding against it; I flag that distinction explicitly so it is not misread as an IPR hit.

Strategic summary

Claim status. All 28 claims are UNTESTED. Nothing is canceled; nothing is sustained-by-FWD. There is no claim-level disposition to quote, and I will not manufacture one. If a demand letter arrives citing claim 1, claim 17, or any other claim, the correct response is not "that claim was invalidated" — it is "no tribunal has ever taken this patent up, and none can meaningfully do so now."

Estoppel landscape. Because no AIA trial was instituted, § 315(e)(2) estoppel is a non-issue — no petitioner, no privies, no estoppel. Conversely, there is also no benefit to a defendant from a prior petitioner's work. A defendant today retains the full universe of § 102/§ 103 prior art grounds it could have raised: U.S. 5,951,694 and 5,956,489 (Microsoft), U.S. 6,058,424 (IBM), U.S. 6,076,108 (i2 Technologies), U.S. 5,796,934 (Oracle), U.S. 5,852,724 (Veritas), EP 0 798 893 (Tandem), plus the non-patent literature citation of record (Bacon et al., Mobile Applications for Ubiquitous Environments, ICL Systems Journal, Nov. 1997) — and, importantly, art that was never before the examiner, since no adversarial proceeding ever probed the file. Note that the record shows ~19–21 examiner-cited references; the full IPR-grade prior-art screen has never been run.

Procedure timing. PGR was never available (the application was filed 1999-06-17, pre-AIA). The CBM window has closed — CBM review sunset on 2020-09-16, and in any event the claims recite generic session-data backup rather than a financial-institution product or service, so CBM eligibility was always doubtful. IPR remains theoretically available (IPR has no sunset and may, in limited circumstances, be filed against an expired patent where a live dispute over past damages exists), but the economics are poor for everyone: see below.

The decisive point — the damages window is empty. The patent's 20-year term ran from the 1999-06-17 filing and anticipated expiration was 2019-06-17 ("Expired – Lifetime" on the record). Under 35 U.S.C. § 286, damages recoverable in a suit filed today can reach back only six years — i.e., to roughly 2020-09-29, which is after the patent expired. There is therefore no pre-expiration damages period available to a 2026 complainant. Pre-2019 infringement is time-barred by the six-year limitation. (The AIA abolished laches as a damages defense in 2011, but the express statutory § 286 bar is unaffected and independently fatal.) Practically, this means any assertion of 6,539,494 today is a nuisance-value play at best, and the strongest response is not a validity challenge at all but the expiration/§ 286 threshold defense.

Pattern signals. None present. No serial petitioner, no defensive aggregator (no Unified Patents / RPX proceeding found), and no history of aggressive PTAB appeals by the patent owner. The patent reads as a foundational technical disclosure that became widely cited prior art (147+ forward citations, 298 in the extended family view) rather than a litigation asset. That is the opposite of the well-asserted-patent profile.

Recommended next steps

1. Do not frame the defense as "claims are invalidated." They are not — the patent is untested but expired. Lead with the expiration date (2019-06-17) and 35 U.S.C. § 286.
2. If a demand cites US 6,539,494, respond with: (a) expiration 2019-06-17, status "Expired – Lifetime" (Google Patents record); (b) the six-year § 286 lookback leaves no recovery period; (c) zero PTAB proceedings — point the sender to USPTO PTAB Decisions / PTAB E2E, where the absence of any proceeding is verifiable, and to CourtListener for the absence of an associated Federal Circuit appeal. Note the caveat that I do not have authoritative docket access and am reporting absence of evidence.
3. If, despite the above, an IPR is contemplated (e.g., a co-defendant wants a merits ruling for a parallel dispute): IPR remains available, the full prior-art universe including non-examiner-cited art is open, and there is no § 315(e) estoppel to worry about — but weigh the cost against a damages period that is, on this record, essentially nil.
4. Verify currency before relying on this. The ODP ingest may lag and I lack authoritative docket access. A live check of PTAB E2E and PACER/CourtListener for the literal number is the only way to convert "no activity found" into "no activity exists."

Explicit uncertainty flag: No PTAB proceeding number, petitioner, panel, institution date, FWD, or CAFC docket exists to report — I have not supplied any, because none was found in the canonical structured data or in live search. If a proceeding surfaces after the ODP ingest date, this section must be regenerated; do not treat the zero as permanent.

I'll attempt to retrieve the actual Assignment Center records (reel/frame, correspondent) before writing anything.

Let me try to pin down the specific reel/frame records and any assertion history.

Preliminary note on sourcing

I reconstructed the chain from the reel/frame data exposed in the Google Patents Legal Events view for US6539494B1 (https://patents.google.com/patent/US6539494B1#legal-events), cross-checked against the Espacenet/INPADOC record for the ATG→Oracle merger and ATG's SEC filings.

What I could not retrieve, and will not invent: the Assignment Center's per-record correspondent-of-record field (the attorney/firm who filed each recording) and the exact recordation dates for the 1999 assignment. The Assignment Center's public search index surfaces conveyances and reel/frame but I could not get into the individual record views in this session. Any correspondent name I wrote down would be fabricated, so I have left that field as "not retrieved" throughout and flagged the consequence in Signal 3 below. If you have Assignment Center access, the per-record view for each reel/frame below will populate it.

Inventors

Unusual-pattern check — no signal. The classic red flag (all inventors departing the assignee within 12 months of filing, preceding a fire-sale) is not present on the record I retrieved. To the contrary: the assignment was executed 1999‑06‑16 — the day before filing — which is the ordinary pre-filing employment/invention assignment, not a later cleanup. I found no evidence of either inventor's departure from ATG within twelve months, and Chung is documented as remaining identified with ATG as a founder. I could not establish Abramson's specific title at filing from the sources retrieved; he is associated with ATG's Dynamo application server line, but I am not asserting that as a documented fact.

Original assignee

Art Technology Group, Inc. (Delaware corporation; principal place of business 25 First Street, Cambridge, Massachusetts 02141 — address confirmed in ATG's 2004 SVB loan correspondence filed with the SEC).

• Primary line of business: e-commerce / Internet application software. ATG shipped the Dynamo application server — and the patent's own Background section names it: "The Dynamo 3.0 application server, provided by the Art Technology Group, Boston, Massachusetts, the assignee of the present application, achieves a near-linear scalability through the use of session-based load-balancing techniques." That is a documented statement by the patentee that the original assignee shipped a product embodying the claimed subject matter (session-based routing with externalized session data).
• Current status: operating, as an Oracle subsidiary — not dissolved, not bankrupt. ATG IPO'd in 1999, acquired Primus Knowledge Solutions (2004), eStara (2006), CleverSet (2008) and InstantService (2010). Oracle announced the acquisition 2010‑11‑02, closed 2011‑01‑05 for ~$1B / $6.00 per share (≈$1B, per the archived ATG Wikipedia entry), and the ATG business continues under Oracle as Oracle Commerce.
• IP-litigation posture of the original assignee: ATG was a payor and defendant in patent disputes, not an asserter — ATG paid $11M (2000), $2M (2001), $2M (2002) to acquire a perpetual license settling BroadVision's infringement claim (ATG 10‑K/10‑Q disclosure). No suit by ATG asserting US 6,539,494 was found.

Assignment timeline

Five recorded events. All reel/frame values below are taken from the Google Patents Legal Events feed for US6539494B1, which reproduces the USPTO assignment database fields.

• 1999‑06‑16 (executed) / recorded 1999 (exact recordation date not retrieved; the Google Patents index ties the event to the 1999‑06‑17 filing date) — Reel 010042/0989

  • Conveyance: Assignment ("ASSIGNMENT OF ASSIGNORS INTEREST")
  • Assignor: Abramson, Nathan; Chung, Joseph T. (individually)
  • Assignee: Art Technology Group, Inc. (Massachusetts)
  • Correspondent: not retrieved (see note above)
  • Context: Ordinary pre-filing inventor assignment by employees/founders to the operating company — no third-party or financial party involved.

• 2004‑01‑31 (executed) / recorded 2004‑03‑12 — Reel 014420/0610

  • Conveyance: Security Agreement (security interest, not a transfer of title)
  • Assignor: Art Technology Group, Inc.
  • Assignee: Silicon Valley Bank dba Silicon Valley East (California)
  • Correspondent: not retrieved
  • Context: Securitization — collateral grant over ATG's IP under the SVB loan facility. This transaction is corroborated by ATG's SEC-filed Amended & Restated Intellectual Property Security Agreement with Silicon Valley Bank (Nov 26, 1997, as amended; June 16, 2004 loan letter, Exhibits 10.25 / 10.24 series).

• 2006‑02‑10 (executed) / recorded 2006‑03‑10 — Reel 017286/0281

  • Conveyance: recorded as a security instrument, but the direction of interest runs SVB → ATG (SVB named as assignor, ATG as recipient with "Owner name: ART TECHNOLOGY GROUP, INC.")
  • Assignor: Silicon Valley Bank
  • Assignee: Art Technology Group, Inc.
  • Correspondent: not retrieved
  • Context: Lien release / re-conveyance of the earlier security interest back to ATG. ⚠️ Flagged contradiction: the Google Patents event index labels this entry's conveyance type as "SECURITY AGREEMENT," which is inconsistent with SVB appearing as assignor — the substance is a release. Treat the conveyance label, not the direction, as unreliable here.

• 2010‑02‑09 (executed) / recorded 2010‑02‑10 — Reel 023937/0412

  • Conveyance: Release
  • Assignor: Silicon Valley Bank
  • Assignee: Art Technology Group, Inc.
  • Correspondent: not retrieved
  • Context: Lien release. ⚠️ Flagged uncertainty: a second release in 2010 implies a security interest was re-granted to SVB after the 2006 re-conveyance at reel 017286/0281; the record I retrieved does not show that intervening grant. The chain may be incomplete on the financing side (this does not affect title).

• 2012‑03‑28 (executed/effective) / recorded 2012‑08‑31 — Reel 028880/0986

  • Conveyance: Merger
  • Assignor: Art Technology Group, LLC
  • Assignee: Oracle OTC Subsidiary LLC (California)
  • Correspondent: not retrieved
  • Context: Internal reorg resulting from acquisition — Oracle's 2011 acquisition of ATG, effected as a merger of ATG (converted to an LLC) into Oracle OTC Subsidiary LLC. Corroboration: INPADOC records the same reel 028880/0986 with the same 2012‑03‑28 effective date for a different ATG patent (US 2009/010414 A1), indicating this is the transaction-level reel for the whole ATG portfolio rather than a patent-specific recordation.

Bottom line: there are no recorded post-issuance title transfers to any entity other than the original assignee's own corporate successors. The only third party ever on the record is Silicon Valley Bank, and only as a secured lender whose interests were released in 2006 and 2010. No recorded assignment since 2012.

Timeline diagram

timeline
    title Ownership of US 6539494
    1999 : Inventors assign to Art Technology Group
    2003 : Patent issued
    2004 : Security interest to Silicon Valley Bank
    2006 : Lien reconveyed to Art Technology Group
    2010 : Second release recorded by SVB
    2011 : Oracle completes ATG acquisition
    2012 : Merger into Oracle OTC Subsidiary LLC
    2019 : Patent expires

NPE / troll-pattern signals

1. Shell-entity transfer — NOT PRESENT.
No link in the chain moves the patent from an operating assignee to a licensing-only LLC. The final recordation (reel 028880/0986, effective 2012‑03‑28) runs Art Technology Group, LLC → Oracle OTC Subsidiary LLC by merger. "Oracle OTC Subsidiary LLC" carries a corporate-form suffix, but it is a wholly owned operating subsidiary of a public company (Oracle Corporation), not a single-purpose Delaware/Texas assertion vehicle — it is a named party in ordinary commercial litigation, e.g. as a petitioner (defensive posture) in Oracle v. Click-to-Call Technologies, IPR2013‑00312. No registered-agent-service address appears in any record I retrieved.

2. Known asserter in the chain — NOT PRESENT (with a stated limitation).
None of the three assignees that ever appear (Art Technology Group, Inc.; Silicon Valley Bank dba Silicon Valley East; Oracle OTC Subsidiary LLC) matches the enumerated asserter lists (Acacia, Marathon, IV, IPNav, Wi-LAN, Mosaid/Conversant, Vringo, Pendrell, Innovatio, MPHJ, Lumen View, Round Rock, Document Generation Corp, Spangenberg entities). Limitation: I was unable to query the RPX Insurance and Unified Patents asserter directories directly in this session, so this is a negative finding against the list you supplied plus my own knowledge, not a completed directory sweep.

3. Repeat correspondent across the chain — UNRESOLVED / cannot be assessed.
The correspondent-of-record field was not retrievable for any of the five recordations, so I cannot confirm or exclude the classic "same lawyer, different shell LLCs" pattern. All I can say is that four of the five instruments are bank collateral or corporate-merger filings of a type recorded by lender's counsel and acquirer's counsel respectively (014420/0610, 017286/0281, 023937/0412, 028880/0986), which is not the signature of an asserter-side filing firm. I am marking this unclear rather than absent, and recommend pulling the correspondent fields at the Assignment Center record level.

4. Cascading transfers — NOT PRESENT.
The recorded transfers are separated by 2, 4, and 2 years (2004 → 2006 → 2010 → 2012), and none is an LLC→LLC chain of assignees. Only one LLC-to-LLC event exists (reel 028880/0986), and it is a documented merger, not a cascade. No shared-address or common-principal pattern is visible.

5. Pre-litigation transfer — NOT PRESENT (as to this patent).
I found no infringement suit naming US 6,539,494 by any party. The only litigation tie to the assignee family is Soverain Software LLC v. Oracle Corporation et al., E.D. Tex. 6:12‑cv‑00141, filed 2012‑03‑14, in which Art Technology Group, LLC was a defendant — and where Oracle's briefs identify "Oracle OTC Subsidiary LLC (successor to Art Technology Group, Inc.)." The 2012‑03‑28 merger effective date (reel 028880/0986) falls ~2 weeks after that filing, which is worth noting as a chronology curiosity, but the merger was driven by the Oracle acquisition (announced 2010‑11‑02, closed 2011‑01‑05), not by that suit, and the '494 patent is not among Soverain's asserted patents.

6. Bankruptcy fire-sale — NOT PRESENT.
ATG was sold solvent, for ~$1B in cash (Oracle; announced 2010‑11‑02, closed 2011‑01‑05). There is no Chapter 7/11 proceeding and no judicial sale of the portfolio. Contrast with the Kodak/Nortel/Polaroid pattern.

7. Privateering — NOT PRESENT.
No evidence that Oracle moved US 6,539,494 (or the ATG portfolio generally) to an NPE to assert on its behalf. The record terminates at Oracle OTC Subsidiary LLC (reel 028880/0986) and stays there; the patent's own terminal event is expiration on 2019‑06‑17 (20 years from the 1999 filing), with the EP counterpart likewise lapsed (INPADOC R071/MK9A, expiry 2020‑06‑18).

8. Defensive aggregator (anti-NPE) — NOT PRESENT.
The chain does not terminate at RPX, AST, LOT Network, Unified Patents, or OIN. It terminates in Oracle's own subsidiary. The inverse conclusion (patent "neutralized" by an aggregator) does not apply.

Verdict

Defensive / non-asserting.

Caveat on the label: the taxonomy's parenthetical for this verdict contemplates a chain ending at a defensive aggregator, which is not what happened here. I select it on the "non-asserting" prong: the record ends at Oracle OTC Subsidiary LLC (reel 028880/0986, effective 2012‑03‑28) — a large operating company that holds the asset as part of an acquired product line (ATG Dynamo → Oracle Commerce, the very product the patent's own Background section cites) — with zero recorded assertions of US 6,539,494, no post-2012 transfer, and the patent expired 2019‑06‑17. If your taxonomy requires the strict aggregator definition, the correct characterization is "operating-company-owned, non-asserted, expired" rather than any NPE category.

Justification (reel/frame citations): Reel 010042/0989 (1999‑06‑16) shows an ordinary pre-filing inventor assignment to an operating company that shipped the embodiment; reels 014420/0610 and 023937/0412 are lender collateral and release instruments from Silicon Valley Bank, not title transfers to an asserter; and reel 028880/0986 (effective 2012‑03‑28) is an acquisition-driven merger into an Oracle subsidiary, not an NPE shell. I found no assignment into a licensing entity, no asserter name, no cascading LLC transfers, and no suit asserting this patent — but I explicitly could not obtain the correspondent-of-record fields, so Signal 3 remains unresolved rather than cleared.

Verify at: USPTO Assignment Center — https://assignmentcenter.uspto.gov/ (search patent 6539494), mirrored at https://assignment.uspto.gov/patent/index.html. Google Patents legal-events view used for the reel/frame values: https://patents.google.com/patent/US6539494B1#legal-events.

I'll research the prior art cited on the face of US 6,539,494, focusing on the references most relevant to § 102 anticipation. Let me verify the key citations.

I have strong detail on the session-related references. Let me verify the remaining key citations (Veritas, Oracle, Compaq) and the non-patent literature.

Prior-Art Analysis for US 6,539,494 B1 ("Internet server session backup apparatus")

Methodology note / flags before the substance:

1. Date contradiction. The previously generated section was produced under a 2026-09-29 system date; this task states "Current Date: April 26, 2026." I flag this inconsistency and do not resolve it. It does not affect the prior-art analysis (all relevant art predates the 1999 priority).
2. Source of the citation list. The authoritative document I was given (the Google Patents record at https://patents.google.com/patent/US6539494) lists 21 U.S./EP citations plus 1 non-patent citation (Bacon et al.). That is the universe I analyze. I did not find any additional prior art cited during reexamination or in litigation.
3. § 102 vs. § 103 honesty. Front-page citations are examiner-curated references. Most of them are § 103 combination art, not single-reference § 102 anticipations. Because anticipation requires one reference to disclose every limitation of a claim as arranged, I state for each reference whether it is a genuine § 102 candidate or only § 103 material — and I flag where I could not retrieve full text (I hit the tool-call limit before retrieving Veritas, Oracle, Compaq, and Bacon full text).
4. Applicable § 102 subsections. Priority/filing is 17 June 1999, so pre-AIA law governs. The relevant buckets are § 102(a), § 102(b) (published/patented before 17 June 1998), and § 102(e) (U.S. patent/published app with an earlier effective filing date). I map each reference accordingly.

A. Full citation table (all citations on the face of US 6,539,494)

Date discrepancy flagged: US 6,058,424 is listed by Google Patents as priority 1997-11-17 / grant 2000-05-02, but a secondary source (Unified Patents, https://portal.unifiedpatents.com/patents/patent/US-[6058424](/patent/6058424)-A) renders priority 1997-11-16 and grant 2000-05-01. I use the Google Patents/patent-record dates and note the one-day discrepancy without resolving it.

B. The most relevant references — detailed § 102 analysis

The four independent claims (1, 16, 17, 28) share a common inventive core: (i) a session assigned to a first application server; (ii) session data backed up to a backup server tier; (iii) a second application server that, on receiving a request whose session ID it is not hosting, retrieves that session data from the backup server; and (iv) transparency to the user. Anticipation therefore requires a reference to disclose all four, including the distinct backup-server retrieval path.

B.1 — US 6,076,108 A (i2 Technologies, Courts et al.) — the strongest single-reference candidate

• Citation: U.S. Patent 6,076,108, "System and method for maintaining a state for a user session using a web system having a global session server," appl. 09/036,010, filed 1998-03-06, granted 2000-06-13; assignee i2 Technologies, Inc.
• Disclosure: A "global session server" (GSS) stores session data (220) representing the state of a user session in memory; the web system engine retrieves that session data from the GSS for each subsequent request, updates it, and writes it back. The GSS "transparently provides session information to servers in the web system and provides a fault-tolerant architecture for maintaining state." Individual web servers can remain stateless and respond regardless of whether they previously served the user. (https://patents.google.com/patent/[US6076108A](/patent/US6076108A))
• § 102 assessment: This reference maps very cleanly onto the "backup server maintains a backup of the session data" limitation of claims 1, 16, 17, and 28 and onto the transparency requirement. It is a legitimate § 102(e) candidate for claim 28 in particular, because claim 28's core is broad: an application server that maintains/assigns session IDs and "obtains from the backup server the backup of session data … if the application server is not hosting the user session." The GSS is structurally the claimed backup server, and stateless web servers obtaining session state from it read directly on that concept.
• Gap: The '108 reference frames the GSS around load-balancing/statelessness across web servers, not around a failure of a specific first application server with routing of the original session ID to a different application server that detects it is not the host. If read narrowly, § 102 on claims 1/16/17 is arguable but not clean; it is at minimum the preeminent § 103 reference.

B.2 — US 5,951,694 A (Microsoft, Choquier et al.) — closest on "transfer to a second app server"

• Citation: U.S. Patent 5,951,694, "Method of redirecting a client service session to a second application server without interrupting the session by forwarding service-specific information to the second server," appl. 08/794,350 (divisional of 08/472,807, filed 1995-06-07), filed 1997-02-03, granted 1999-09-14; inventors Choquier, Peyroux, Griffin; assignee Microsoft. (§ 102(e): effective filing 1995-06-07.) (https://uspto.report/patent/grant/5951694)
• Disclosure: On-line services network with replicated application servers behind Gateway microcomputers; per-service-session assignment of a user to one application server; dynamic load balancing using a periodically updated "service map" (a load table updated ~every 30 s); and a "hot redirection" technique transferring a service session from a first to a second (replicated) application server without interruption by having the first server return a serialized state object that the Gateway forwards to the second server.
• § 102 assessment: Excellent § 102(e)/§ 103 art for the session-transfer, load-balancing, and transparency elements of claims 1, 13, 15, 16, and 17. The "service map" reads directly on claim 15's load-manager table and claim 13's request routing.
• Decisive gap for anticipation: The state is forwarded directly server-to-server (or via the Gateway) from the still-available first server; there is no backup-server tier storing the session data, and no step of a second server "retrieving session data from a backup server assigned to the first application server." Because every independent claim of the '494 patent requires that backup-server retrieval, US 5,951,694 does not anticipate any independent claim; it is powerful § 103 art when combined with B.1/'108 or B.4/'424.

B.3 — US 6,058,424 A (IBM, Dixon et al.) — session takeover without loss

• Citation: U.S. Patent 6,058,424, "System and method for transferring a session from one application server to another without losing existing resources," appl. 08/972,053, filed 1997-11-17, granted 2000-05-02; inventors Dixon, Wood, Verburg, Shi; assignee IBM. (§ 102(e).) (https://patents.google.com/patent/US6058424)
• Disclosure: A session is "enabled for takeover" via an API (msEnableTakeover) that returns session takeover data (which must be available to a successor server); on failure (or cooperatively), a new application server accesses the takeover data (from a shared file or pipes), calls msTakeover, reconstructs status/access information for the session's resources, and continues the session. A control server queues callbacks during takeover. The transfer is "non-disruptive to the user."
• § 102 assessment: Strong § 102(e)/§ 103 art for the concept of transferring a session between app servers without losing resources, transparently, i.e., the conceptual thrust of claims 1 and 17.
• Gap: The takeover data resides in a shared file or pipes / at the first server's API, not in a distinct backup server that is "assigned to" the first application server and from which the second server fetches session data. No session-ID-encodes-backup-server mechanism. So again — no clean § 102 anticipation of the independent claims; best used in combination.

B.4 — EP 0 798 893 A1 (Tandem Computers) — session recovery + new session ID

• Citation: EP 0 798 893 A1 (granted as EP 0 798 893 B1), "End-to-end session recovery," priority 1996-03-28, published 1997-10-01; applicant Tandem Computers Inc. (§ 102(b) — published before 1998-06-17.) US counterpart US 5,754,752. (http://data.epo.org/gpi/EP0798893A1)
• Disclosure: On a client/server protocol error (e.g., TCP/IP error), server and client switch to new data sockets using a client listening socket; the server verifies an encrypted session ID and generates a new session ID (MD5-based) that the client stores for future recovery. The server buffers commands/data during recovery so the session survives with minimal data loss.
• § 102 assessment: § 102(b) art relevant to claim 17's "assigning a second session ID" and to the general notion of session recovery with a backup (TCP/IP) process. It is a printed publication as of 1997-10-01.
• Gap: Recovery is on the same server (via its backup process), not to a second application server retrieving data from a separate backup server. The "backup" here is a redundant protocol process/memory, not a backup-server tier holding session data keyed by session ID. § 103 art; not anticipatory of claims 1/16/17/28.

B.5 — US 5,852,724 A (Veritas Software) — N-to-1 failover

• Citation: U.S. Patent 5,852,724, "System and method for 'N' primary servers to fail over to '1' secondary server," filed 1996-06-18, granted 1998-12-22; assignee Veritas Software Corp. (§ 102(e)/(a).)
• Note: I was unable to retrieve the full text of this reference before exhausting tool calls; the following is based on the patent record's title/assignee and my prior knowledge, and is therefore lower-confidence.
• Expected disclosure / assessment: An architecture where multiple primary servers share a single standby secondary server, with data (state) replicated to the secondary and failover on primary failure. Relevant to claims 1/16 (backup/secondary server holding backup data for one or more servers — cf. the '494 spec: "a backup server 26 may be assigned to a single application server 24 or to multiple application servers 24"). Likely § 103 art; the "application session" specifics and session-ID-encoded backup address are absent.

B.6 — US 5,796,934 A (Oracle) — fault tolerant client/server

• Citation: U.S. Patent 5,796,934, "Fault tolerant client server system," filed 1996-05-31, granted 1998-08-18; assignee Oracle Corp. (§ 102(e)/(a).)
• Note: Full text not retrieved (tool limit); description is lower-confidence.
• Assessment: General fault-tolerant client-server failover; background/§ 103 art for the "backup/failover" context of claim 1. Not anticipatory of the session-ID/backup-server-retrieval core.

C. Remaining citations — grouped assessment (§ 102 vs § 103)

D. Bottom-line conclusions

1. No single cited reference appears to be a clean § 102 anticipation of any of independent claims 1, 16, 17, or 28. Every independent claim requires (a) a backup-server tier that stores session data for a first application server and (b) retrieval of that session data from the backup server by a second application server that determines it is not hosting the session. The two references closest on (b)-type session transfer — US 5,951,694 and US 6,058,424 — transfer state directly from the first server / via a Gateway or shared file, with no backup-server tier. EP 0 798 893 recovers on the same server. None crosses the backup-server threshold.

2. The most relevant reference is US 6,076,108 (i2 Technologies' "global session server"), which supplies the missing "backup server transparently holding session state for stateless servers" element and is a genuine § 102(e) candidate — strongest against claim 28 (and arguable against claims 1/16/17).

3. The examiner's citation set reads as a § 103 combination, not a § 102 rejection. The natural combination is US 6,076,108 (or US 6,058,424) for backup/transfer of session state + US 5,951,694 for per-session assignment, load-based selection, and transparent redirection to a second app server.

4. Uncertainty I will not paper over:

   • I could not retrieve full text for US 5,852,724 (Veritas), US 5,796,934 (Oracle), the four Compaq references, or the Bacon et al. article before the tool budget was exhausted. Assessments of those are title/record-based and lower-confidence; a definitive § 102 call on them requires their full texts.
   • The § 102(e) vs § 102(a)/(b) bucketing above assumes the Google Patents date fields are correct; the US 6,058,424 one-day date discrepancy is flagged in § A.
   • I made no determination about un-cited prior art (e.g., other 1990s session-management or clustered-session patents such as the "maintaining sessions in a clustered server environment" family) — the task scope was the citations on the face of the patent.

Primary URLs used: https://patents.google.com/patent/US6539494 · https://patents.google.com/patent/US5951694 · https://uspto.report/patent/grant/5951694 · https://patents.google.com/patent/US6058424 · https://patents.google.com/patent/US6076108A · https://patents.google.com/patent/EP0798893A1/en · http://data.epo.org/gpi/EP0798893A1 · https://uspto.report/patent/grant/[5754752](/patent/5754752)

I'll ground the key prior-art references before building the obviousness analysis, since the analysis depends on what each reference actually teaches.

Good grounding on the core references. Let me verify three more that bear directly on the claim limitations.

Obviousness Analysis — U.S. Patent No. 6,539,494 B1

Patent: US 6,539,494 B1, "Internet server session backup apparatus"
Appl. No. 09/335,004 · Filed/priority 1999‑06‑17 · Granted 2003‑03‑25
Inventors: Nathan Abramson, Joseph T. Chung · Assignee of record: Oracle OTC Subsidiary LLC (originally Art Technology Group)
Legal standard: 35 U.S.C. § 103(a) (pre‑AIA, as the application was filed before 2013‑03‑16), construed under Graham v. John Deere and KSR Int'l v. Teleflex

Source of prior art. Per the task direction, I am using the references listed in the Prior Art / Citations section of the patent record at https://patents.google.com/patent/US6539494/en — the 21 patent citations and the single non‑patent citation. I am deliberately not using the "Cited By (147/298)" lists: those documents post‑date the 1999 priority date and are therefore not § 102 prior art (e.g., US 8,090,829, 2012; US 7,254,634, 2007; US 7,437,594, 2008). Using them would be a legal error.

1. Threshold: every cited reference qualifies as prior art

⚠️ Candor note: my tool budget was exhausted before I could pull the full text of US 5,796,934 (Oracle), US 6,141,759 (BMC), US 5,715,887 (BroadVision) and the Compaq/IBM/Vinca/Sybase set. Where I rely on those, I say so and frame the reliance as title/abstract‑level only. The core combinations below rest on the four references I verified in full.

One correction to keep straight: US 5,951,694 issued on 1999‑09‑14, i.e. after the '494 filing date — but it is still prior art under § 102(e) because its application was filed 1997‑02‑03 (and its parent on 1995‑06‑07). Do not treat the issue date as the operative date.

2. Level of ordinary skill (PHOSITA)

A PHOSITA here has a bachelor's in CS/EE plus ~2–3 years building multi‑tier networked servers, or equivalent experience with HTTP servers, application servers, TCP/IP sockets, and stateful session management. As of the 1999 priority date, session affinity/"sticky" load balancing, session IDs in cookies/URLs, and primary/standby failover were all mature, well‑documented arts — as the patent's own background admits (see § 7).

3. What the four verified references actually teach

US 5,951,694 (Microsoft, Choquier et al.) — https://patents.google.com/patent/US5951694

• Architectural twin of the '494 FIG. 1: "the application servers … arranged into service groups, with each service group corresponding to a particular service"; "each application server of a service group is preferably a 'replicated' version of the others."
• Session-to-server assignment: "Users of a service are assigned to individual application servers on a per‑service session basis… that application server will normally service the end user until the… session is terminated."
• A Gateway microcomputer (web‑server analog) selects the server using a load map and applies load balancing; one disclosed method "selects application servers such that the probability of selection of a given application server is proportional to that application server's available CPU processing power" — implemented (FIG. 8) by assigning integer ranges proportional to available CPU and drawing a pseudo‑random integer. This is materially the '494 claim 15 load‑manager/weighted‑random mechanism.
• "Hot redirection" (its claim 1): "prompting said first application server for service‑specific information about a state of the client service session; forwarding said service‑specific information about said state to said second application server; and transferring the client service session… without interrupting the client service session." Buffered client requests are forwarded so the new server "resumes processing of service requests where the former server left off."
• Express motivation to add failure‑triggered failover: "It is contemplated that this technique will be combined with a fault detection mechanism to automatically transfer service sessions to different servers when signs of abnormal service behavior are present."
• Transparency: the technique "improves service reliability from the perspective of the end user by allowing service sessions to continue when corresponding servers are taken down for maintenance."
• Messages are tagged with a service session identifier; the Gateway's session map records the selected server ID.

US 6,058,424 (IBM, Dixon et al.) — https://patents.google.com/patent/US6058424

• Method/claims for "transferring a session… from the first application server to a second application server," where a "transfer causing condition occurs when the first application server fails" (claim 4) or "when the first application server requests that the session be transferred" (claim 5) — i.e., both failover and voluntary migration.
• The second server "uses the session takeover data to reconstruct information… regarding all resources necessary to keep the session executing" (claim 1).
• Critically, the transfer is initiated by the second server after the first is gone: "the failure may be detected when the new application server detects a broken socket. Once the new application server detects that the original application server has terminated, the new application server accesses and uses the sessionTakeover data," which may be "stored in a shared file" or received over a pipe.
• Advantage: "non‑disruptive to the user… without losing resources."
• Significance: '424 closes the exact gap in '694 — under '694 the first server must be alive to be "prompted," which is useless if it has crashed. '424 teaches obtaining the state from a location outside the failed server.

US 6,076,108 (i2 Technologies, Courts et al.) — https://patents.google.com/patent/US6076108

• "A global session server (GSS)… transparently provides session information to servers in the web system and provides a fault‑tolerant architecture for maintaining state."
• Claim 1: session data "representing a state of the user session [is] stored in a global session server, the global session server accessible by the web system engines such that the web system engines can share the session data," with retrieval and update of that single set of session data on each subsequent request.
• An accompanying continuation recites "master or shadow copies of session data for a plurality of user sessions" on the physical systems — i.e., a backup of session data held off the serving engine.
• Its web tier uses a load distribution unit (e.g., Cisco Local Director) with a "sticky" feature to route requests back to the same physical system.
• Significance: this is the "third‑tier/off‑server store" the '494 claims, plus the sharing and updating mechanics, and it is expressly "transparent" and "fault‑tolerant."

EP 0 798 893 A1 (Tandem, "End‑to‑end session recovery") — https://patents.google.com/patent/EP0798893A1/en

• A primary/backup arrangement on two CPUs: memory of one CPU stores "a backup version of an application program" and "a backup server," while the other stores the primary.
• On a socket error, the server and client "switch from a server data socket and a client data socket… to a new server data socket and a new client data socket."
• Session ID mechanics: "the primary server generates a new session ID… and sends this session ID to the end‑to‑end client"; the server previously "requests the session ID from the end‑to‑end client"; the ID is exchanged in an encrypted/opaque form (MD5), and recovery is hidden from the application ("All of this session recovery happened without the primary application… being involved"), with buffering of commands during recovery.
• Significance: teaches recovering a session by asking a client for its session ID, generating a new session ID after recovery, doing so transparently, and buffering requests — i.e., the claim‑6/7/8/9 "new session ID" and claim‑1/17 "transparency" elements, plus the notion of an off‑server copy of the application state.

US 5,852,724 (Veritas) — https://patents.google.com/patent/US5852724

• "A system and method for 'n' primary servers to fail over to '1' secondary server… One secondary server is provided as a back‑up for the set of primary servers"; each primary also has a unique private‑network name by which the others "may monitor the status of each other."
• Significance: teaches the claim‑16 topology — each application server assigned to one backup server, while each backup server serves multiple application servers — and heartbeat/status monitoring.

Non‑patent citation (Bacon et al., "Mobile Applications for Ubiquitous Environments," ICL Systems Journal, Nov. 1997): I could not verify its content (tool limits). I therefore draw no § 103 conclusion from it and flag it as unassessed. If it discloses session‑state handoff or backup for mobile/ubiquitous clients, it would reinforce the motivation prong below, but I will not assume that.

4. Claim charts and proposed combinations

4.1 Claim 1 (system: app servers + backup server; off‑server recovery; transparent)

Combination A (primary): US 6,058,424 + US 6,076,108, optionally + US 5,951,694. Every element is disclosed; the only arguable gap is that '424 stores the takeover data in a "shared file" rather than a named backup server, and '608 stores it in a global session server rather than a per‑app‑server backup server. Substituting a dedicated backup server for a shared file/central service is a mere substitution of one known data store for another to obtain a predictable result (KSR rationale (2)) — and the '494 claims say nothing about the archival mechanism beyond "a backup server coupled to the application servers."

4.2 Claim 16 (web server + app servers + group of backup servers, one backup per app server; different session ID; transparent)

• Web server → US 5,951,694's Gateway microcomputers (they receive requests, select, and route). Caveat: '694's Gateway is not an HTTP server; the title‑level BMC reference US 6,141,759 ("distributing, monitoring, and managing information requests on a computer network") is a likely supplementary teaching for an HTTP request‑distribution tier, but I did not verify it. Independence with respect to a general web server is a weak hook — web servers were notoriously well known, and the '494 specification itself lists off‑the‑shelf Netscape/Microsoft HTTP servers.
• Each app server assigned to one backup server; each backup server backs up ≥1 app server → US 5,852,724 almost verbatim (N primaries : 1 secondary; one secondary serves several primaries).
• Session ID assigned; second server assigns a different session ID → EP 0 798 893 ("the primary server generates a new session ID… and sends this session ID to the client") + US 6,076,108 (engine‑specific session data keyed by session ID).
• Obtain backup from the backup server to which the first server was assigned → US 6,058,424 + US 6,076,108.
• Transparent → as § 4.1.

Combination B: US 5,852,724 + US 6,076,108 + EP 0 798 893.

4.3 Claim 17 (method: assign session → assign first ID → send request with first ID to second server → determine whether that server hosts the session → retrieve data from the first server's backup server → assign second ID; transparent)

This is the strongest § 103 case, because US 5,951,694 claim 1 and US 6,058,424 claim 1 are each a near‑mirror of the method:

4.4 Claim 28 (single app server + backup server; app server compares session ID to its hosted list to detect it is not hosting; transparent)

• App server maintains session data for assigned sessions and assigns session IDs → US 6,076,108 (claim 1) and EP 0 798 893 (server generates/assigns the session ID).
• "Obtain from the backup server the backup… if the application server is not hosting the user session" → EP 0 798 893 is highly pertinent: after a socket error the primary has lost its session state, and recovery runs by re‑obtaining the session ID from the client and reconstructing from the backup copy — which is precisely the scenario the '494 specification itself carves out ("If the failure and recovery of the application server cause it no longer to have a record that it is hosting the session it can nonetheless recover the session data from the backup server"). US 6,058,424 supplies the same concept from a shared file.
• The narrow limitation: "determine if the application server is not hosting the user session by comparing the session ID… to a list of session IDs currently being hosted by the application server."

Here the case is weaker and should be stated as such. Neither '608 (which uses a central store, making a local hosting list unnecessary) nor '424 (which keys off a broken socket) nor EP 0 798 893 (which keys off a protocol error) expressly discloses the local hosted‑session‑ID list comparison. The argument must then rest on KSR's "predictable variation" prong: maintaining a set of live session identifiers and testing membership is one of the most routine bookkeeping operations in the server arts (compare the Gateway session map of US 5,951,694, which records the selected server per session, and US 6,076,108's session managers managing access to session data). A PHOSITA implementing "is this session mine?" on a multi‑session server would predictably either (i) compare the incoming ID against the sessions in memory, or (ii) consult a routing map. I would rate claim 28 as likely obvious but the least airtight of the four independents, and I recommend not asserting it without a secondary reference (e.g., a session‑table/lookup teaching) in hand.

5. Motivation to combine (the KSR prong)

1. Same problem, same field, same solution family. '694, '424, and '608 all address session continuity when a multi‑server tier changes which server serves the session. A PHOSITA would look to each for the same reason.
2. Explicit invitation to combine in '694 itself. '694 states its hot‑redirection technique "will be combined with a fault detection mechanism to automatically transfer service sessions… when signs of abnormal service behavior are present." That is a teaching, suggestion, or motivation in the art to add failure‑triggered handoff.
3. Complementary capabilities / mutual gap‑filling. '694 requires prompting the first server — impossible if it has crashed. '424 expressly solves the crashed‑server case ("the new application server detects a broken socket… accesses and uses the session takeover data"). Combining them is the predictable, synergistic step a PHOSITA would make when told to automate failover.
4. Design incentive to centralize the state off the peers. The '494 background criticizes the known alternative — "broadcasting the session data on each application server to each of the other application servers… significantly increases the amount of cross‑communication, thereby greatly decreasing… scalability." This is a design incentive/market force rationale (KSR (6)) pointing to a dedicated store, which is exactly what US 6,076,108's GSS and US 5,852,724's secondary server supply.
5. Topology is a known, predictable arrangement. US 5,852,724 teaches N:1 assignment with status monitoring — the claim‑16 assignment scheme — so no new design work is needed.
6. "New session ID" is a known, expected variation. EP 0 798 893 already generates a fresh session ID after recovery and pushes it to the client; choosing to re‑key the session to the newly assigned server (claims 6–9, 16, 17) is a predictable administrative step, not an inventive leap.

6. Dependent claims

• Claims 2–3 (session ID unique identifier): EP 0 798 893's 16‑byte session ID; US 5,951,694's session identifiers. Obvious.
• Claims 4–5 (session ID identifies the app server; further identifies the backup server): the most vulnerable limitation. No verified reference teaches encoding both IP addresses in the session ID. The § 103 rebuttal is that (a) US 5,951,694's session map/registry already associates a session with its server and its service group, and (b) putting a routable handle in an identifier is a routine self‑describing‑identifier technique; but absent a reference that encodes server location in an ID, expect a genuine nonobviousness argument here. Title‑level US 6,141,759 (BMC, request distribution/management) is the reference I would investigate first; I could not verify it.
• Claims 6–9 (assign/replace with a new ID): EP 0 798 893 (new session ID after recovery). Strong.
• Claims 10–12 (equivalence/alias table, in an alias server or in the backup server): weakest coverage. The best in‑record analog is US 6,076,108's shared single‑set‑of‑session‑data model — note the tension: if session data is centralized and shared, alias tables are largely unnecessary, which cuts both ways. US 5,951,694's Conf_Loc/global‑registry resource→server mapping (a lookup table that maps an identifier to the server that owns it) is a reasonable secondary teaching. Flag claims 10–12 as the strongest potential validity argument in the patent.
• Claims 13–14 (web server routes to first server; routes to second on failure): US 5,951,694 (Gateway routing; load balancing; hot redirection to a different server). Strong. Drafting flag: claim 13's "web server" is broader than '694's Gateway, and the '494 spec lists third‑party HTTP servers as "suitable," so this adds little.
• Claim 15 (load manager polling app servers): US 5,951,694 is nearly anticipatory — service map with CPU LOAD/CPU INDEX per server, broadcast every 30 seconds, weighted (probability‑proportional) selection using a pseudo‑random number. Very strong.
• Claims 18–19, 21, 25–27 (identify backup server from the ID; determine prior assignment; obtain equivalence lists from the backup server; re‑assign old ID; recover/merge data): mostly bookkeeping/consistency mechanics. US 5,715,887 (BroadVision, electronic commerce state) and US 5,713,017 / US 5,155,678 (fault‑tolerant file server consistency) are plausible supports at title level but unverified; US 6,058,424's bidirectional "cooperative" transfer supports claim 25's round‑trip migration. Treat 21–24 (cross‑notifying backup servers, updating equivalence tables) as the segment most likely to survive — again the alias‑table theme.
• Claim 20, 22 (list from the backup server / from an alias server): as claims 10–12.
• Claim 28's list‑comparison: see § 4.4.

7. External admissions in the '494 specification

Two statements in the patent's own background are usable against it (applicant admissions are prior art for § 103 purposes; In re Nomiya; Riverwood Int'l v. R.A. Jones):

1. Session‑based load balancing with weighted‑random selection by load already existed — "The Dynamo 3.0 application server, provided by the Art Technology Group… achieves a near‑linear scalability through the use of session‑based load‑balancing techniques… The assignment of the application server is made through a weighted random selection according to load." The '494 asserts near‑linear scalability as its benefit, but the admission shows that benefit was achieved by the assignee's pre‑existing product, severing any nexus to the claimed contribution. This substantially defeats an objective‑indicia (secondary considerations) argument.
2. Peer‑to‑peer session replication was already known ("In some existing application server designs, this problem is addressed by broadcasting the session data on each application server to each of the other application servers"). Knowing the problem and a known (if inefficient) solution, the move to a centralized backup tier is a predictable design choice.

Since the previous sections of this analysis located no litigation or assertion campaign for this patent (and it expired 2019‑06‑17, putting it beyond IPR reach under 35 U.S.C. § 311(c)), there is no evidence of secondary considerations in the record — no commercial‑success evidence, no licensing‑driven nexus, no industry praise, no copying — beyond the patent's own attorney argument.

8. Recommended combinations, ranked by strength

For a single primary reference, US 6,058,424 is the closest to the claimed invention in purpose (session transfer without loss, on failure or cooperatively), with US 6,076,108 supplying the off‑server backup and transparency and US 5,952/5,951,694 supplying the load‑managed routing and the express failover‑automation motivation. For claims 1 and 16, US 5,852,724 supplies the N:1 backup‑server topology that the other references lack.

9. Weaknesses in this case and claim‑drafting defects (candid assessment)

1. No verified reference encodes both the application‑server address and the backup‑server address in the session ID (claims 4–5, 18). This is the patent's best defensive position. It is arguable but not obviously wrong to say a PHOSITA would route the session by embedding a server handle in the identifier; US 6,058,424 achieves the same routing through a shared file / shared takeover‑data channel, which is an equivalent, known alternative mechanism.
2. Alias/equivalence tables (claims 10–12, 20–24) are not clearly disclosed in the cited art. Recommend dedicated searching (self‑describing session handles, distributed session directories, "equivalent session" mapping) before asserting obviousness on these.
3. Claim 28's "list of session IDs currently being hosted" comparison is disclosed only by analogy to the Gateway session map of '951,694 / the session managers of '608; the mapping is persuasive under KSR but not airtight.
4. The "transparent to the user" limitation appears in all four independent claims. It is a result‑oriented recitation; under KSR a claim is not saved by stating the intended result of a combination that otherwise renders it obvious, and each of '694, '424, and EP 0 798 893 discloses user‑imperceptible session continuation independently. Also flag a potential § 112(b) concern: "transparent" is not defined with objective boundaries.
5. Claim 16 contains an antecedent‑basis defect — it recites "the second of the application servers" without ever introducing "a second of the application servers." This makes claim 16 vulnerable under § 112(b) independent of § 103, and it complicates any element‑by‑element mapping.
6. Claim 16 is also internally inconsistent in that its "session ID" paragraph recites both "a user session assigned to a first of the application servers is assigned a session ID" and "the second of the application servers assigns a different session ID" without first establishing the second server's role. Claim 17 similarly does not state that the "second session ID" differs from the first (contrast claim 16's express "different"). These are drafting defects, not defenses.

10. Bottom line

Under § 103(a) and KSR, claims 1, 13–15, 17, 18–19, 25–27 and 28 are vulnerable to the combinations above — most sharply US 6,058,424 in view of US 6,076,108, further in view of US 5,951,694, which collectively disclose (i) per‑session assignment and routing among replicated application servers, (ii) detection by the second server that it is not hosting the session, (iii) reconstruction of the session from state held outside the failed server, (iv) a new session ID on the receiving server, and (v) user‑transparent continuation. Claim 16 is vulnerable to US 5,852,724 + US 6,076,108 + EP 0 798 893 (and suffers an independent § 112(b) antecedent‑basis defect). Claims 4–5/18 (dual‑address session ID) and claims 10–12/20–24 (alias tables) are the limitations I would not rest an invalidity contention on without additional art beyond what is on the face of the patent.

Verification gaps I am flagging rather than papering over: (a) full texts of US 5,796,934, US 6,141,759, US 5,715,887 and the Compaq/IBM/Vinca/Sybase references were not retrieved (tool limit); (b) the content of the sole non‑patent citation (Bacon et al. 1997) is unverified; (c) I did not obtain the Pixion v. PlaceWare Markman holding on US 5,951,694's "service application" term in full — the retrieved excerpt shows the court viewed the '694 preamble as limiting and grappled with importing preferred‑embodiment language into "service application," which could narrow how broadly '694 may be applied as art. That holding should be checked in full before relying on '694 as the primary reference.