US 6223289

I'll run several targeted searches to check for current USPTO status and any CAFC/litigation activity, then summarize.

Let me check for litigation/docket history and pull the claim text.

Let me try to retrieve the actual claim set for US6223289.

US 6,223,289 B1 — Analyst Summary

Note on dates: Your prompt frames the current date as April 26, 2026; my operating instructions give 2026‑09‑29. Either way, the patent below is long expired, so the date difference does not change any status conclusion. I flag it only for transparency.

Note on sourcing: All bibliographic facts below come from the authoritative patent text supplied in my context (Google Patents, https://patents.google.com/patent/US6223289/en) plus corroborating search hits (Unified Patents portal, https://portal.unifiedpatents.com/patents/patent/US-[6223289](/patent/6223289)-B1; the WO/EPO family record for WO9954803, https://patentimages.storage.googleapis.com/54/e0/87/e17e8b15c3751a/WO2002037267A3.pdf). Where I could not verify something, I say so explicitly.

---

1. Bibliographic data

Note on the assignment record: the 1998‑08‑04 assignment lists the assignor names as "WALL, GERAD A." and "NORHTCUTT, J. DUANE" (apparent typographical variants of Gerard/Northcutt in the USPTO assignment abstract). Per your strict rule, I am reporting those spellings literally rather than correcting them.

2. Abstract (verbatim)

Authentication and session management can be used with a system architecture that partitions functionality between a human interface device (HID) and a computational service provider such as a server. An authentication manager executing on a server interacts with the HID to validate the user when the user connects to the system via the HID. A session manager executing on a server manages services running on computers providing computational services on behalf of the user. The session manager notifies each service in a session that the user is attached to the system using a given HID. A service can direct display output to the HID while the user is attached to the system. When a user detaches from the system, each of the service's executing for the user is notified via the authentication manager and the session manager. Upon notification that the user is detached from the system, a service can continue to execute while stopping its display to the HID.

3. Plain‑language overview of the independent claims

Important honesty caveat. I was not able to retrieve the verbatim claim text of US 6,223,289 from the sources I could reach. The full text supplied to me contains the description but is truncated before the claims, and my searches returned the continuation patent US 6,484,174 rather than the '289 claim set. I therefore will not invent claim language or claim numbers. What follows distinguishes (a) what I can state from the specification/abstract, and (b) what I can state about the family's claim 1, which I do have verbatim.

(a) Subject matter the claims necessarily cover (from abstract + specification, high confidence):

• A human interface device (HID) / "network terminal" paradigm in which display and input are partitioned away from computation and state (FIG. 7, FIG. 8).
• An authentication manager executing on a server that validates a user when the user connects via the HID, using a challenge/response exchange (FIGS. 5A–5B, FIG. 6) that hashes identifier, PIN, secret and challenge values with a function such as hmac_md5 (RFC 2104/RFC 2103 line of art).
• A session manager executing on a server that maintains a session database mapping users → sessions → services, initiates required services, and sends connect/disconnect notifications so that services direct display output to whichever HID the user is currently at.
• Session portability / persistence: services continue executing while the user is detached (e.g., smart card removed), and are redirected to a new terminal when the user re‑attaches.
• One‑way authentication that avoids key exchange and central key lookups (stated in the specification as an advantage).

(b) The family claim 1 (verbatim, from US 6,484,174 B1, the continuation of application 09/063,339, published in the Official Gazette, Issue 1264‑3): This is the closest authoritative claim text I can give you for the '174 continuation — not for the '289 patent itself:

1. A method for interacting with a computer system comprising: accessing a first computer in said computer system using an identifier; authenticating a user on a server in said computer system using said identifier; and directing one or more services to said first computer system, if said user is authenticated on said server; disconnecting from said first computer; continuing to execute said services; re‑connecting on a second computer in said computer system using said identifier; authenticating said user on said server in said computer system using said identifier; and directing said services to said second computer system, if said user is authenticated on said server wherein said services continued to execute when said user was disconnected from said first computer.

The '174 patent reports 24 claims; the '289 patent's claim count and independent-claim structure are unverified in my sources. Structurally, a patent of this era and family typically presents one or more method claims (session management / authentication as above) mirroring this continuation claim, plus apparatus and/or computer program product claims covering the authentication manager + session manager architecture. I am labeling that last sentence as inference, not verified fact.

4. Litigation, PTAB, and CAFC 2026 docket check

• No record found. Targeted searches for "6223289" in combination with Federal Circuit, PTAB, IPR, or district‑court litigation terms returned no case, docket, IPR, or appeal involving US 6,223,289. The only "6223289"‑bearing hit was a stray numeric occurrence on a courtscast.com oral‑argument index page (Cascades Computer Innovation v. RPX Corp.), where the number appears as unrelated page metadata rather than as a patent‑in‑suit identifier. I would not treat that as evidence of litigation over this patent.
• Enforcement context: Even absent a docket hit, the patent's window for infringement suits is effectively closed — it expired 2018‑04‑20 (20 years from the 1998‑04‑20 filing, with no verified terminal disclaimer or extension in my sources). Damages recovery would be limited to the six years before expiration.
• Limits of my check: I could not query PACER, the CAFC CM/ECF docket, or USPTO Patent Center / PTAB APIs directly; my check rests on open‑web search. A negative result here means "not surfaced by search," not a certified clearance opinion. If you need a certified litigation history, pull the Patent Center "Legal Events" tab, PACER Docket Navigator/ Lex Machina, and the CAFC docket for the patent number.

5. Explicit uncertainty list

1. Verbatim claim text and claim count of US 6,223,289 — NOT verified. Do not rely on the claim‑1 description above as the '289 claim; it is the '174 continuation's claim 1.
2. No verified litigation/PTAB/CAFC history. Searches were negative; they are not exhaustive of PACER/ECF.
3. Assignee chain: Original assignee Sun Microsystems, Inc.; current Oracle America, Inc. per recorded reassignment — the Google Patents page itself warns that listed assignees "may be inaccurate" and that it performs no legal analysis.
4. Legal status ("Expired – Lifetime," 2018‑04‑20) is Google Patents' assumption, explicitly not a legal conclusion.

If you want, I can attempt a follow‑up pass aimed specifically at the USPTO full‑text claims view for 6,223,289 so the independent claims can be restated verbatim rather than by family proxy.

Litigation search result for US Patent 6,223,289

Bottom line: no litigation involving US Patent 6,223,289 was found. I ran targeted searches against the patent number in both its punctuated and unpunctuated forms ("6223289", "6,223,289") combined with litigation terms (infringement, complaint, defendant, district court, PTAB, IPR, CAFC, Oracle, Sun Microsystems), plus the Unified Patents patent/litigation portal. Nothing surfaced in which 6,223,289 is the patent-in-suit, the patent being challenged, or the subject of a declaratory-judgment action.

Because you asked for a per-case table, here is the truthful version:

I will not populate that table with cases involving similar numbers. And there are several such distractors, which is worth setting out explicitly so the negative result is not mistaken for a miss:

Numbers that are NOT 6,223,289 (do not conflate)

1. U.S. Patent No. 8,291,289 — Malikie Innovations Ltd. v. Hyundai Motor Co., No. 2:26-cv-00387 (E.D. Tex.). The complaint shorthand "'289" refers to an 8,291,289 LDPC-code patent, one of a family ('212, '829, '289). Different patent, different owner, different technology. (Ex Parte complaint analysis)
2. U.S. Patent No. 6,233,389 B1 — TiVo's "Multimedia Time Warping System," asserted against AT&T Inc. and [Verizon Communications, Inc.](/litigations/by-defendant/Verizon%20Communications%2C%20Inc.) in the Eastern District of Texas (also implicated in the EchoStar/DISH dispute and a Delaware declaratory-judgment action referenced in TiVo's Form 10-Q). This is a one-digit-adjacent number and is a common false positive for "6,223,289." (TiVo 10-Q excerpt)
3. A "'328 Patent" appearing in an IPR petition (claims 9, 14–16, 17–18, 19, 21–22; Facet Tech. Corp. v. Mobileye Glob., Inc., No. 2:24-cv-00058 (E.D. Tex.)) — that is a different patent entirely, not 6,223,289.
4. A stray numeric occurrence of "6223289" on a courtscast.com oral-argument index page (Cascades Computer Innovation v. RPX Corp.) appears as unrelated page metadata, not as a patent-in-suit identifier. Not evidence of litigation.

Enforcement posture (why a null result is not surprising)

Per the authoritative bibliographic record I already summarized (https://patents.google.com/patent/[US6223289](/patent/US6223289)/en), the patent:

• Filed/priority 1998-04-20, issued 2001-04-24;
• Carried legal status "Expired – Lifetime," with anticipated expiration 2018-04-20;
• Descended from Sun Microsystems, Inc. to Oracle America, Inc. (reassignment recorded 2015-12-12);
• Has a continuation, US 6,484,174 B1 (application 09/703,009, filed 2000-10-31), which is the family member I actually have verbatim claim text for.

Any infringement action would have had to be filed on or before 2018-04-20, with damages reaching back at most six years (35 U.S.C. § 286). If the patent was ever asserted in the 2001–2018 window, it did not surface in these searches.

Honest limits on this answer

• These searches rest on open-web and portal search, not on a certified database query. A negative result here means "not surfaced by search," not "certified no litigation."
• I could not directly query PACER, the CAFC CM/ECF docket, Lex Machina / Docket Navigator, or the USPTO Patent Center "Legal Events" tab. Lexis/Lex Machina and Docket Navigator are the reliable tools for a complete § 271/§ 282 litigation history, including cases that settled or were dismissed before any published opinion.
• For a bulletproof clearance-grade answer, the sequence is: (1) USPTO Patent Center → "Legal Events" and the "Patent Litigation" tab (which links to any district-court or PTAB proceedings reported under 35 U.S.C. § 290); (2) Docket Navigator or Lex Machina search on "6,223,289"; (3) CAFC docket search for appeals naming Oracle America/Sun and the patent number.
• Per your strict rule, I have not auto-corrected any identifier. The assignor-name variants in the 1998-08-04 assignment abstract ("WALL, GERAD A." and "NORHTCUTT, J. DUANE") are carried over literally from the record as previously noted.

Conclusion: no known litigation involving US Patent 6,223,289 (plaintiff, defendant, jurisdiction, case number, filing date, and outcome all unestablished). If you want, I can attempt one more pass aimed squarely at the USPTO Patent Center full-text/claims view for 6,223,289, which would both (a) confirm the claim count and verbatim independent claims that remained unverified in my earlier section, and (b) surface any § 290 litigation notices of record.

I'll verify the canonical "no proceedings" finding against the open web before writing up.

Let me run a couple more targeted checks for any post-grant challenge or Federal Circuit activity.

Proceedings overview

Total AIA trial proceedings on US 6,223,289: zero (0) — no IPRs, no PGRs, no CBMs ever filed; breakdown by status is therefore 0 active / 0 claims invalidated / 0 claims sustained / 0 settled / 0 institution denied. The defensive posture this gives a defendant is not "hardened by IPR" — it is that the patent was never tested at the Board at all, and separately that it has been expired since 2018‑04‑20, which makes AIA trial practice largely moot: an expired patent is still IPR‑eligible (the Board can and does review expired claims), but the practical value of filing is near zero unless there is an unresolved past‑damages exposure. See the caveat below on who could still be exposed.

---

Proceedings on file

None. The canonical structured source — the "PTAB proceedings on file" block generated from the USPTO Open Data Portal — returns an empty set for this patent as of the most recent ingest. That is the authoritative list, and it is empty.

I ran independent open‑web verification and it corroborates the structured data:

⚠️ Two false‑positive traps to avoid

1. US 8,531,289 is a different patent. Searches for "…289" + IPR pull up Unified Patents, LLC v. LBT IP II LLC, IPR2022‑00806, U.S. Patent 8,531,289 (a tracking‑device patent). Do not import that proceeding's institution, FWD, or claim outcomes into US 6,223,289. They are unrelated patents with a coincidentally similar suffix.
2. The Cascades Computer Innovation v. RPX Corp. oral‑argument index page at courtscast.com carries a stray string "6223289" as page metadata (and an unrelated "Docket ID"). This is not a patent‑in‑suit citation and is not evidence of litigation or an appeal over this patent. The prior‑generated summary flagged this correctly; I confirm it.

Related family proceeding of interest

There is also no PTAB proceeding on the '289 patent's continuation, US 6,484,174 B1 (application 09/703,009, filed 2000‑10‑31). If you are evaluating family exposure, that child is likewise untested at the Board.

---

Strategic summary

Claim status: everything is UNTESTED and, as of 2018‑04‑20, EXPIRED. No claim of US 6,223,289 has been canceled, narrowed, or affirmed by the Board. There is no FWD to point to, no certificate of cancellation, and no surviving‑claim set to inventory. The prior‑generated summary correctly refused to state the '289 claim set verbatim (it was not retrievable there, and it is not retrievable here either); the closest verified claim language in the family is claim 1 of the '174 continuation, which recites authenticating a user with an identifier, directing services to a first computer, disconnecting, continuing to execute the services, re‑connecting at a second computer, re‑authenticating, and redirecting the services. If a demand letter asserts US 6,223,289 today, the number one response is not an IPR petition — it is a calendar. The 20‑year term from the 1998‑04‑20 filing ran to 2018‑04‑20; the recoverable window under 35 U.S.C. § 286 is at most the six years preceding expiration, i.e., infringement accruing from roughly 2012‑04‑20 onward, and only if maintenance fees were paid and no terminal disclaimer shortened the term further (I have not verified the fee history — pull Patent Center for that).

Estoppel landscape: inapplicable. Because no IPR/PGR was ever instituted, § 315(e)(2) estoppel does not attach to anyone. No petitioner, real party‑in‑interest, or privy is barred from raising any § 102/§ 103 ground — which cuts both ways: a defendant gets a clean slate, but there is also no body of Board‑tested invalidity material to inherit. Every prior‑art ground is "available" in the estoppel sense and none is "developed" in the record sense. The Google Patents citation list and the 37‑reference "Patent Art" set on the Unified portal are the natural starting points for a § 102/§ 103 search, but note that much of that art post‑dates or is contemporaneous with the 1998‑04‑20 priority date.

Pattern signals. (a) No repeat petitioner — there is no petitioner at all, so no multi‑IPR campaign narrative. (b) No patent‑owner PTAB appeal aggressiveness — Oracle has nothing to appeal; there is no Board decision. (c) No defensive aggregator in the chain — Unified Patents never touched this patent, which is mildly probative that the patent was not being asserted against Unified's members in a way that merited a challenge, and/or that the 2018 expiration made a challenge economically pointless. The absence of PTAB activity here is not the usual "not enough value yet" signal; it is explained by expiration. Well‑asserted patents attract IPRs during their enforceable life; this one's enforceable life ended eight years before the current docket check.

---

Recommended next steps

1. If you are a defendant and have received a demand citing US 6,223,289: do not budget for an IPR. Confirm the expiration first (calendared at 2018‑04‑20) and, if the demand includes past‑damages periods, ask the claimant to produce the maintenance‑fee payment history and any terminal disclaimer from USPTO Patent Center (https://patentcenter.uspto.gov/). The absence of PTAB activity means there is no FWD to link or quote — I have deliberately quoted none, because none exists.
2. If there is meaningful pre‑2018 damages exposure (e.g., a long‑tail indemnity, a settlement evergreen, or a § 286 six‑year look‑back dispute), an IPR remains legally available on an expired patent, but weigh it against a district‑court § 102/§ 103 defense where no estoppel constrains you and the Board's "reasonable likelihood" threshold buys you little. If you do file, capture the ground fully — you get one clean shot with no prior Board record to build on.
3. If you need certifiable negative confirmation (rather than my search‑based finding): the structured ODP block in this prompt is your canonical negative, and you can independently confirm at the PTAB E2E/PTACTS portal (https://ptacts.uspto.gov/ptabweb/) and on Patent Center's "Legal Events" tab. CourtListener (https://www.courtlistener.com/) and the CAFC docket are the right sources for the equally‑negative appeal check. My check rests on open‑web search plus the ODP ingestion; a negative here means "not surfaced," not a certified clearance. I did not query PACER, the CAFC CM/ECF docket, or PTAB APIs directly.
4. Watch the '289‑suffix confusion. Any docket‑research vendor or over‑inclusive keyword alert that matches "…289" or "6223289" will mix in IPR2022‑00806 (U.S. 8,531,289, LBT IP II) and the Cascades/RPX metadata artifact. Screen those out before they reach a validity opinion or a privilege‑logged diligence memo.

I'll research the assignment chain for US 6,223,289 across the sources available to me.

Let me try to reach the assignment records directly and cross-reference the Unified Patents portal.

I need to find the specific reel/frame numbers. Let me try more targeted queries.

Method note (read first). I was unable to query USPTO Assignment Center / Assignments-on-the-Web directly — my live-search budget was exhausted before I could open the record pages, and the Assignment Search / Assignment Center systems consolidated on 2025-10-20 (legacy searches at assignment.uspto.gov were retired). The chain below is reconstructed from (i) the Google Patents legal-events block supplied in my context for US 6,223,289, (ii) the Official Gazette listing of the continuation US 6,484,174 B1, and (iii) Espacenet INPADOC records for a sibling Sun patent. Reel/frame numbers for US 6,223,289 itself are only partially verified — I flag exactly where below. Treat every reel/frame as "unverified for this patent" unless stated otherwise.

Inventors

Basis for the employer column: all five are named as assignors on the 1998-08-04 recorded assignment to Sun Microsystems, Inc. (Google Patents legal events for US 6,223,289), and all residences are in the Bay Area within commuting distance of Sun's Palo Alto campus. That is sufficient to place them as Sun personnel at filing; it is not independent confirmation of employment contracts.

Note on the literal spelling. The 1998-08-04 legal-event entry names the assignors as "BUTCHER, LAWRENCE L., WALL, GERAD A., HANKO, JAMES G., NORHTCUTT, J. DUANE, RUBERG, ALAN T." — i.e. "GERAD A." for Gerard A. and "NORHTCUTT" for Northcutt. Per the operating rule I report those literally rather than silently correcting them.

Unusual-pattern check — departures within 12 months of filing: Unclear / not determinable from my sources. I found no evidence either way. I note only that this is a team filing (five co-inventors) from Sun's thin-client / network-terminal effort, and that the same five inventors filed the continuation US 09/703,009 on 2000-10-31 and issued as US 6,484,174 B1 — i.e. the team stayed engaged with the family well past the 12-month mark, which is weakly inconsistent with a rapid post-filing break-up. This is inference, not verified personnel data.

Original assignee

Sun Microsystems, Inc., Palo Alto, California — named on the face of the issued patent and on the OG listing of the continuation US 6,484,174 B1 ("Assigned to Sun Microsystems, Inc., Palo Alto, Calif.").

• Primary line of business: enterprise computer systems — SPARC workstations/servers, Solaris, Java, and network/thin-client computing. This was an operating company, not a holding or licensing vehicle.
• Product embodying the claims: likely, moderate confidence. The '289 specification describes exactly the "human interface device" partition — a stateless display/input terminal plus a server-side authentication manager and session manager that relocates a persistent session to whichever terminal carries the user's smart card. Sun commercialized this as the Sun Ray thin client (and associated Sun Ray server software). The match is strong on its face, but I have not performed a claim chart against a shipped product, so treat "ships a product embodying the claims" as a well-supported inference, not a verified fact.
• Current status: acquired, no bankruptcy. Oracle Corporation acquired Sun; by a Delaware Certificate of Merger filed 2010-02-12 and effective 2010-02-15 03:01 EST, Oracle USA, Inc. (a Colorado corporation) merged into Sun Microsystems, Inc. (a Delaware corporation), with the surviving entity renamed Oracle America, Inc. (I retrieved this Certificate of Merger text in full.) Florida Sunbiz shows the same: document P16782, "NAME CHANGE AMENDMENT, 02/24/2010, OLD NAME WAS: SUN MICROSYSTEMS, INC." Sun did not file Chapter 7/11 as an end-of-life event, so this is an operating-company acquisition, not a bankruptcy sale.

Assignment timeline

USPTO record for US 6,223,289 contains two recorded conveyances (per the Google Patents legal-events block). Both are operating-company records.

1. 1998-08-04 (recorded) — Reel /__ — NOT VERIFIED

• Conveyance: ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS)
• Assignors: Lawrence L. Butcher; Gerad A. Wall; James G. Hanko; J. Duane Northhcutt; Alan T. Ruberg (spellings as recorded)
• Assignee: Sun Microsystems, Inc.
• Correspondent: Not retrieved. (No correspondent appears in the Google Patents legal-events rendering; the cover sheet itself was not reachable before my search budget ran out.)
• Context: standard inventor-to-employer assignment, executed roughly 3.5 months after the 1998-04-20 filing (application 09/063,339). Routine, not a fire-sale.

2. 2015-12-12 (recorded); merger effective 2010-02-15 — Reel 037303/0336 — CANDIDATE ONLY, NOT VERIFIED FOR THIS PATENT

• Conveyance: MERGER AND CHANGE OF NAME (SEE DOCUMENT FOR DETAILS)
• Assignors: Sun Microsystems, Inc.; Oracle USA, Inc.; Oracle America, Inc.
• Assignee: Oracle America, Inc.
• Correspondent: Not retrieved for this recording. ⚠️ Flag: my searches surfaced a different 2015 Oracle recording — app. 14/835,433, reel 036418/0075, recorded 2015-08-25, entered by correspondent Charles J. Kulas, 1900 Embarcadero Road, Suite 109, Palo Alto, CA 94303 (email domain trellislaw.com; submitter Sherry Sutterfield; Oracle docket ORACP0140). That is not the '289 merger recording and I am not attributing it to this chain — I surface it only because it is evidence that Oracle's 2015-era prosecution-side recordings ran through a Palo Alto outside correspondent rather than an in-house filer.
• Context: internal reorg / succession by merger — a pure change-of-name-and-survivorship record, not an arm's-length sale.

The reel/frame caveat, stated precisely. The 037303/0336 reel/frame is verified by Espacenet INPADOC for sibling Sun patent US 7,409,710 B1, where the event reads: "ORACLE AMERICA, INC., CALIFORNIA … MERGER AND CHANGE OF NAME; ORACLE USA, INC.; SUN MICROSYSTEMS, INC.; ORACLE AMERICA, INC.; REEL/FRAME:037303/0336", recording date 2015/12/16, effective date 20100212. Because Oracle's Sun merger was recorded as a small number of bulk cover-sheet recordings, the '289 entry may sit on 037303/0336 or on a different reel in the same batch (note the Google Patents recorded date for '289 is 2015-12-12 vs. 2015-12-16 for the sibling — possibly the same batch, possibly not). Do not cite 037303/0336 as the '289 reel without opening the Assignment Center record.

No recorded assignment exists for this patent beyond these two. There is no sale, no security interest, no license recordation, and no transfer to any licensing entity.

Timeline diagram

timeline
    title Ownership of US 6223289
    1998 : Filed by five Sun inventors
         : Inventors assign to Sun Microsystems
    2001 : Patent issues to Sun
    2010 : Oracle acquires Sun
         : Merger effective 15 February
    2015 : Merger and name change recorded
         : Owner of record is Oracle America
    2018 : Patent expires 20 April

NPE / troll-pattern signals

1. Shell-entity transfer — NOT PRESENT. No "IP / Licensing / Holdings / Ventures" entity ever appears in the chain. Both recorded conveyances land on operating corporations (Sun Microsystems, Inc.; Oracle America, Inc.).
2. Known asserter in the chain — NOT PRESENT. Neither assignee matches any of the listed NPE rosters (Acacia, Marathon, IV, IPNav, Wi-LAN, Mosaid/Conversant, Vringo, Pendrell, Innovatio, MPHJ, Lumen View, Round Rock, Document Generation, Spangenberg entities). Oracle America, Inc. is an operating company and the ultimate parent is an NYSE-listed S&P 100 corporation.
3. Repeat correspondent across the chain — UNCLEAR (data not retrieved). I could not obtain the correspondent-of-record for either the 1998-08-04 Sun recording or the 2015-12-12 Oracle recording; the Assignment Center pages were not reachable within my search budget. No recurrence can be asserted or ruled out. The only correspondent datum I actually verified (Charles J. Kulas / Trellis Law, Palo Alto) belongs to reel 036418/0075, a different Oracle recording, and is reported above only as context.
4. Cascading transfers — NOT PRESENT. Two conveyances, ~17 years apart (1998-08-04 and 2015-12-12), with a 5-year lag between the merger's 2010-02-15 effective date and its 2015 recording. There is no <24-month chain of LLC-to-LLC assignments.
5. Pre-litigation transfer — NOT PRESENT. No infringement suit naming this patent was surfaced in my earlier docket pass, and the only transfers are (a) the 1998 inventor assignment and (b) a 2010-effective intra-group merger recorded in 2015. Nothing is timed to a filing.
6. Bankruptcy fire-sale — NOT PRESENT. Sun was acquired by merger, not liquidated. The operative instrument is the Delaware Certificate of Merger effective 2010-02-15, which names Sun as the surviving entity renamed Oracle America, Inc. This is an acquisition, categorically distinct from a Chapter 7/11 asset sale (Kodak, Nortel, Polaroid). (Contrast the task's example of "Sun Microsystems → Oracle" as a fire-sale — on the records I retrieved, Sun's end was a merger, not a bankruptcy. I flag this because the task prompt lists it under bankruptcy; I believe the prompt's characterization is loose here.)
7. Privateering — NOT PRESENT. Oracle did assert Java patents against Google in Oracle America, Inc. v. Google Inc. (N.D. Cal. 3:10-cv-03561), but (a) Oracle asserted those claims first-party, not through a proxy, and (b) no source I reached places US 6,223,289 among the asserted patents. There is no transfer to an NPE asserting on Oracle's behalf.
8. Defensive aggregator — NOT PRESENT. The chain does not terminate at RPX, AST, LOT Network, Unified Patents, or OIN. Title remains with Oracle America, Inc.

Verdict

Operating-company assertion (owner-operator prong satisfied; assertion prong not documented for this patent — see caveat).

Justification. The complete chain is two operating-company records: the 1998-08-04 inventor→Sun Microsystems, Inc. assignment of assignors' interest, and the 2015-12-12 recorded MERGER AND CHANGE OF NAME vesting title in Oracle America, Inc. (merger effective 2010-02-15, certificate filed 2010-02-12) — with zero licensing-only entities, zero security interests, and zero pre-litigation transfers at any point. The current assignee, Oracle America, Inc., is a practicing operating company that ships the closest descendant product line (Sun Ray / Oracle VDI) to the claimed HID-partition architecture, and the patent expired 2018-04-20 (Google Patents "Expired – Lifetime"), so the assertion window is closed regardless of posture. Caveat: because I surfaced no infringement suit naming US 6,223,289, the "suing actual competitors" prong of this label is unmet on the evidence I have; if your taxonomy requires a documented filed action, the correct single label is Insufficient data rather than an affirmative assertion call. What is not in doubt is the negative finding: no NPE signal is present on this chain.

Verification links: USPTO Assignment Search — https://assignmentcenter.uspto.gov/ (patent-number search; legacy https://assignment.uspto.gov/patent/index.html retired 2025-10-20); patent record — https://patents.google.com/patent/US6223289/en; sibling INPADOC record used for the reel/frame cross-check — https://worldwide.espacenet.com/publicationDetails/inpadoc?CC=US&NR=[7409710B1](/patent/7409710B1)&KC=B1&FT=D.

---

Sourcing note: I did not reach any record page on USPTO Assignment Center, RPX, or Unified Patents' asserter directory in this pass. All reel/frame data are unverified for US 6,223,289; the two dates (1998-08-04, 2015-12-12) and the assignor/assignee names are taken from the Google Patents legal-events block supplied in my context, which is the same underlying USPTO data. No assignment above has been fabricated or inferred from naming alone.

I'll run several targeted searches to pull the USPTO record and the "References Cited" list for US 6,223,289.

Let me try more targeted sources for the cited references, including the WO search report and FreePatentsOnline.

Let me try the Justia page for 6,223,289 itself and the USPTO full-text source.

Prior-Art Analysis for US 6,223,289 — With a Critical Sourcing Caveat

Bottom line up front: I could not retrieve the face-of-patent "References Cited" list for US 6,223,289 from the patent text supplied to me or from the sources my search could reach. The patent full text in my context is truncated before the claims and before the front-page citations. I therefore will not invent a citation list. Below I give (A) exactly what I searched and the negative result, (B) the references that are verifiably cited inside the '289 specification, with full citation/date/description and a § 102 assessment, and (C) the closest verified proxy — the "References Cited" list of the '289's own continuation, US 6,484,174 B1 — clearly labeled as not the '289 list.

---

A. What I searched, and what the US 6,223,289 record returned

Target (interpreted literally, no auto-correction): US 6,223,289 — "Method and apparatus for session management and user authentication," App. No. 09/063,339, filed and priority 1998‑04‑20, issued 2001‑04‑24, Sun Microsystems → Oracle America.

Negative results (important):

• Searching the patent number together with "References Cited," "Patent Citations," "U.S. Patent Documents," or examiner‑citation terms returned only the specification/abstract body of US 6,223,289 (patents.google.com/patent/US6223289B1/en) — not its front-page citation column.
• The Google Patents / Espacenet records I reached for the family (WO 99/54803 A2/A3, EP 1074136 B1) expose family members and forward ("citing") documents, but I could not open the "Documents cited" (Documentos citados) tab, which for the WO publication would carry the ISR/IDR references.
• I could not query USPTO Patent Center or Patent Public Search (ppubs) APIs directly; my access was limited to open‑web search of mirrors (Google Patents, Justia, FreePatentsOnline, Unified Patents). A negative result here means "not surfaced by my search," not "no citations exist."

Do-not-conflate flag (per your strict rule): one search hit showed "X US 6 232 129 B1 (WIKTOR PETER)." That is US 6,232,129, a different patent. It is not US 6,223,289 and I treat it as unrelated.

Where the authoritative list actually lives: the printed '289 grant, column 1 ("References Cited"); USPTO Patent Center → Documents & Transactions (the "References Cited" / PTO‑892 form); or Espacenet's Documentos citados for WO9954803. Those are the only places I would trust for a § 102 opinion on this patent.

---

B. Prior art that is verifiably cited by US 6,223,289 itself

The '289 specification cites four standards documents by name in its Background Art section. These are "printed publications" and are genuine prior art of record inside the four corners of the patent (not front-page citations, but citable art):

Anticipation assessment (35 U.S.C. § 102) — with an explicit blocker

I cannot name the claim(s) of US 6,223,289 that these references "anticipate," because I still do not have the '289 claim text (this was flagged as unverified in the prior generated section, and the truncation persists). Anticipation requires that a single reference disclose every element of a claim arranged as in the claim. On the shared disclosure, the mapping is:

• RFC 1994 (CHAP) — relevant only to the authentication sub-steps (challenge command → response → verification). It does not disclose the session‑relocation elements (session manager, service persistence while detached, redirection of I/O to a second HID). So it cannot anticipate a claim that recites session portability; it is at most § 102 art against a bare challenge‑response claim, or § 103 art in combination.
• RFC 1321 / RFC 2104 — relevant to how the challenge response is computed (hashing of identifier + PIN + secret + challenge). Neither discloses authentication architecture or session management; combination only (§ 103), not anticipation of any session-management claim.
• RFC 2131 (DHCP) — relevant only to a terminal obtaining/being assigned a network address; not anticipatory of the authentication or session-relocation subject matter.

Net: on the disclosure available, none of the four RFCs individually anticipates a claim directed to authentication-manager + session-manager session relocation. They are § 102(a)/(b) references for the authentication/hashing sub‑elements.

---

C. Closest verified proxy — the "References Cited" list of US 6,484,174 B1

Read this label carefully: the following is the citation list of US 6,484,174 B1 (App. 09/703,009, filed 2000‑10‑31, issued 2002‑11‑19), which the record states is "a continuation of application No. 09/063,339, filed on Apr. 20, 1998, granted, now 6223289." It is NOT the '289's own citation list. I retrieved it verbatim from https://patents.justia.com/patent/[6484174](/patent/6484174) ("Referenced Cited"). It is offered only as the nearest available indicator of what the family's examiners were looking at.

Two cautions on this table:

1. Date problem. Only US 5,577,209 is unambiguously before the '289 filing date. Ten of the twelve issued after 1998‑04‑20 and could only be § 102(e) art if their own US filing dates precede it — I did not retrieve those filing dates and will not infer them.
2. Content not verified. I have not retrieved the titles/abstracts of these references in this pass, so I am not characterizing their disclosures. Any statement of the form "Reference X discloses Y" for these items would be unsupported. Pull each reference before asserting anticipation.

I also observed a forward citation: US 6,223,289 appears in the citation list of US 7,895,256 (TeleCommunication Systems, Inc.) — i.e., the '289 is itself cited as prior art by later patents. That is a "citing" document, not a "cited" reference, and is noted only for completeness.

---

D. What I will not do (and why it matters to your § 102 request)

Your instruction was to "look at each patent citation for 6223289" and map each to potentially anticipated claims. I can complete only the "each citation" half for the references I could actually retrieve (Part B), and I cannot complete the "which claim(s)" half at all, because:

• The '289 claim set is unavailable to me (verified again in this pass — the Justia/Google records surface the continuation's 24 claims, not the '289's). Naming a claim number and asserting anticipation without the claim text would be fabrication.
• The '289 front-page citation column is unavailable to me. Part C is a labeled proxy from the child patent and must not be cited as the '289's references.

To close both gaps, pull: (1) the '289 grant PDF, col. 1, from patentimages/USPTO; (2) USPTO Patent Center → Documents & Transactions → the "References Cited"/PTO‑892; (3) Espacenet's Documentos citados for WO9954803. Provide those and I will produce the full per-reference title, date, disclosure summary, and claim-by-claim § 102/§ 103 mapping you asked for.

---

Uncertainty ledger (explicit)

1. Front-page "References Cited" of US 6,223,289 — NOT retrieved. Do not treat Part C as it.
2. Verbatim claims/claim count of US 6,223,289 — NOT retrieved. No claim-level § 102 mapping is possible from my sources.
3. RFC publication dates (1321: Apr 1992; 1994: Aug 1996; 2131: Mar 1997; 2104: Feb 1997) are stated from training knowledge, not re-verified in this pass; the fact that the '289 cites them by number is verified from the supplied specification text.
4. § 102(e) status of the Part C references depends on their US filing dates, which I did not retrieve.
5. US 6,232,129 (Wiktor) ≠ US 6,223,289 — flagged to prevent conflation.

I'll ground this analysis in the prior-art material actually available on the patent page (the background-art discussion and the RFC references) and check whether the page's citation lists can be retrieved, since I still lack the verbatim claim text.

Excellent — the family's PCT/EP search reports surfaced the actual examiner-cited art. Let me verify a few key references and try once more for the '289 claim text.

Obviousness Analysis — US 6,223,289 B1 under 35 U.S.C. § 103

A. What changed since the earlier sections (and what did not)

Still not retrieved: the verbatim claim set of US 6,223,289. That gap remains, and I will not fabricate claim language. See §K for exactly how much this limits the analysis.

Newly retrieved and important: the examiner's own prior-art citations for this family. Both the PCT International Search Report for PCT/US 99/08665 and the granted European counterpart EP 1 074 136 B1 carry references-of-record, and the ISR contains a claim-by-claim relevance mapping. That is the closest thing available to a verified "Prior Art section" for this disclosure, so I anchor the analysis on it, supplemented by the art the specification itself cites in its background section.

Sources used:

• PCT ISR (in WO 99/54803 A3): https://patentimages.storage.googleapis.com/eb/d7/d7/f18ae5f3008085/WO1999054803A3.pdf
• EP 1 074 136 B1: https://patentimages.storage.googleapis.com/39/52/0b/94b062aa8fb442/EP1074136B1.pdf
• DE 699 25 996 T2 (German translation of EP 1074136): https://patentimages.storage.googleapis.com/77/e3/b5/42f2b277420f9a/DE69925996T2.pdf
• Unified Patents portal relating to US-6223289-B1: https://portal.unifiedpatents.com/patents/patent/US-6223289-B1
• Continuation claim 1, US 6,484,174 B1 (Official Gazette 1264‑3): https://webapp1.dlib.indiana.edu/virtual_disk_library/index.cgi/5628977/FID2/OG/html/1264-3/us06484174-20021119.html

Critical new fact. The WO 99/54803 ISR (PCT/US 99/08665) cites only two references and maps them to specific claims:

Two consequences follow immediately:

1. The '289 family has at least 20 claims. The continuation US 6,484,174 confirms 24 claims in that member; the '289 claim count itself remains unverified.
2. The examiner treated one reference as anticipating the session-relocation subject matter (X) and one reference as supplying the authentication subject matter (Y), in the same claim set. That is, the Office already viewed the invention as a two-reference assembly, not a unitary concept. This is directly on point for § 103.

Discrepancy flag (contradicts an earlier section). One retrieved page surfaced a Legal Events block containing "PATENT EXPIRED FOR FAILURE TO PAY MAINTENANCE FEES … EFFECTIVE 2020‑03‑18" adjacent to a Sun assignment (reel/frame 009311/0418; signing dates 1998‑05‑19 to 1998‑06‑20) matching this family. Those calendar dates are consistent with the 11.5‑year fee window of a patent granted in March 2008 — i.e., US 7,346,689, the page that was actually being served — not with a patent filed 1998‑04‑20. I treat the "Expired – Lifetime / 2018‑04‑20" characterization from the earlier sections as governing, and I flag the 2020 lapse entry as probable cross-contamination from a co-retrieved page. Verify via Patent Center before relying on either.

---

B. Governing law and the person of ordinary skill (POSITA)

• Pre-AIA § 103(a) applies. Priority/filing is 1998‑04‑20; the application was filed before the AIA's 2013 first-inventor-to-file date. The enabling date is the 1998‑04‑20 filing date.
• Every reference in the tables below predates 1998‑04‑20 by more than one year, so each is § 102(b) art and is fully available for § 103 with no swearing-behind and no "closeness of the art" fight of any weight.
• Motivation-to-combine standard: because any post-2007 review applies KSR Int'l Co. v. Teleflex Inc., 550 U.S. 398 (2007), the Office may rely on "any need or problem known in the field" and on "the background knowledge, creativity, and common sense of the person of ordinary skill." A teaching, suggestion, or motivation is not required. KSR also permits "obvious to try" and combination of "familiar elements according to known methods to yield predictable results."
• POSITA (proposed): a bachelor's degree in computer science or electrical engineering, or equivalent, plus 2–3 years of experience designing networked multi-user computer systems, with working familiarity with: X11/X Window client–server display splitting; TCP/IP and UDP sockets; terminal I/O and pseudo-terminal (pty) facilities; the IETF RFC corpus (including the PPP authentication RFCs and the DHCP RFC); challenge-response authentication and MD5/HMAC message digesting. This is a low skill level for this era, which broadens the scope of combinable art.

---

C. The prior art of record and the prior art available

C.1 Art the specification itself cites as background ("Prior Art" section of the page)

C.2 RFC 1994 in detail — the closest authentication art

Retrieved full text: https://www.ietf.org/rfc/rfc1994.txt and https://datatracker.ietf.org/doc/rfc1994/. RFC 1994 defines a three-way handshake:

1. The authenticator sends a "challenge" message (Code = 1) to the peer.
2. The peer responds with a value calculated using a one-way hash function (Code = 2).
3. The authenticator checks the response against its own calculation of the expected hash value (Code = 3 Success / Code = 4 Failure).
4. "At random intervals, the authenticator sends a new challenge to the peer, and repeats steps 1 to 3."

Its packet format: Code | Identifier | Length | Value-Size | Value | Name, where the Identifier field "MUST be changed each time a Challenge is sent" and the Response Identifier MUST be copied from the Challenge. The Response Value is the one-way hash calculated over … the Identifier, followed by (concatenated with) the "secret", followed by (concatenated with) the Challenge Value.

Now place that beside the '289's stated N_AUTHENTICATE implementation:

That is not a mere "field of use" overlap. The '289's authentication packet is RFC 1994's CHAP packet, with one added input (the PIN) and with the userID carried in the response. The '289 adds the PIN to the hash input and adds a userID field to the response packet — a substitution of one additional secret input into an unchanged hash construction and the addition of a lookup key. Both are the kind of predictable variation KSR treats as obvious.

C.3 Examiner-cited art

Dasgupta & Shukla (TENCON '91, IEEE, pp. 199–203), A Movable User Interface Based on a Simple X-Window Like Protocol — category X in the ISR; also discussed in EP 1074136 B1 ¶[0007]. Retrieved: https://ieeexplore.ieee.org/abstract/document/753867; https://www.semanticscholar.org/paper/ea36569dd40cedcbb2ca963cc0b0a4e261b05dd3.

What it discloses, from the paper itself:

• A client–server design: "the client (one for each user) acts as the user interface. The server, which controls a number of possible terminal devices, hosts its user's processes."
• "The terminal I/O of a process may be relocated by the user to a different terminal with complete continuity. No change is required to the process or to the operating system." Achieved by having the process use a pseudo-terminal; "a server is then responsible for forwarding the I/O to a client associated with a real (physical) terminal."
• "It is possible to enter a process through a client and then exit the client and even log off the terminal leaving the process executing. A process that has no associated client is called a disconnected process. Such a process can be connected to … through a client at any terminal."
• "Output generated by such process is buffered separately by the server. This allows a user to [re]enable output generated by a disconnected process."
• Session addressing: a per-user session number (snum), session connect request packet (OPC_CONRQ, carrying "a session number (or -1) and a password"), disconnect packet (OPC_DCONRQ), end/free-session packet (OPC_ENDRQ); the server is installed with a well-known address, and clients have this address built into their code; client addresses become known to the server at runtime.

Every load-bearing architectural element of the '289's session-management half — server-side processes on a pseudo-terminal, a broker (session manager) forwarding I/O to whichever client/terminal the user is at, a persistent process that keeps executing after the user detaches, buffered output reclaimed on reconnection, and a numeric session identifier with connect/disconnect protocol packets — is disclosed in Dasgupta. The examiner's "X" rating confirms the Office reached the same view.

US 5,590,199 A (Krajemski Jr. et al., issued 1996‑12‑31), Electronic Information Network User Authentication and Authorization System — category Y in the ISR (abstract; col. 2 l. 52 – col. 7 l. 53; claims 1, 4). This is the authentication-side complement the examiner paired with Dasgupta.

C.4 Art beyond the record that bears on the same subject matter

---

D. Feature decomposition used for the § 103 chart

Because I lack the '289 claim text, I decompose the disclosed invention into the features that any claim drawn to this specification must recite. The decomposition is grounded in (i) the abstract and summary, (ii) claim 1 of the '174 continuation (with which the '289 shares a specification), and (iii) — most importantly — the examiner's own mapping, which identifies claims 5, 7, 9, 10, 18 and 20 as the claim group carrying the Dasgupta/Krajemski subject matter.

---

E. Combination 1 — Dasgupta + RFC 1994 (primary § 103 combination)

Covers F1, F2, F4, F5, F7, F8, F11; and F6/F10 to a substantial degree.

Motivation to combine. KSR supplies the rationale directly: Dasgupta's own architecture creates the problem the RFC 1994 step solves. In Dasgupta, any client that presents a valid session number can attach to a live, persistent process at any terminal. That is precisely a situation that demands re-verification of the person at the new terminal — otherwise the relocation feature is a session-hijacking vector. The field knew the conventional answer: a challenge-response handshake in which the secret is never sent over the link, with a fresh random challenge per round and an incrementing identifier to defeat replay. RFC 1994 states both the motivation and the mechanism ("CHAP provides protection against playback attack … through the use of an incrementally changing identifier and a variable challenge value"). Substituting a network-wide challenge-response handshake for Dasgupta's static "password" in the connect packet is "the use of a known technique to improve [a] similar device[] in the same way" — the classic KSR formulation, yielding a predictable result.

Why this is more than a mere aggregation of old elements. The '289's own authentication packet (code 1/2/3/4, identifier, length, value, valueSize) and its hash input (identifier ‖ secret ‖ challenge, plus PIN) mirror RFC 1994's. The only added inputs are (a) the PIN and (b) the userID in the response. Both are predictable variations: RFC 1994 §2.1 expressly contemplates that "name fields may be used as an index to locate the proper secret in a large table of secrets," which is exactly the '289's userID-in-response/AM-database lookup; and adding a second shared secret (the PIN) to the hash input is a routine strengthening of the same hash.

---

F. Combination 2 — Dasgupta + Tarantella AIP + RFC 1994 (strongest combination for F7/F8)

Tarantella's October 1997 white paper is more on-point than Dasgupta for the reconnect-from-a-different-place feature, because it says it in the very words of the '174's claim 1:

"the server maintains a persistent session for the user. This enables users to disconnect their session and reconnect later, even from a different location if desired. The reconnected session continues, using the same set of running applications. The user can also switch the type of client device used when reconnecting."

Motivation to combine all three. Tarantella teaches the business and technical need for roaming persistent sessions across heterogeneous clients; Dasgupta teaches how to implement it (pty-hosted processes + a server-side broker + a client that may be disconnected and reattached); RFC 1994 teaches the authentication step that a roamed session requires. All three were addressing the same known problem — thin-client/remote-presentation computing with user mobility — and the field was explicitly combining display-transport protocols with server-side session state (X11, ICA, RDP, AIP; see the Citrix/RDP/Tarantella comparison literature). There was no teaching away, and the combination yields nothing more than the expected result: a mobile user who authenticates once at each terminal and gets the same running programs.

---

G. Combination 3 — US 5,590,199 + Dasgupta (the combination the examiner actually made)

This is the Office's own pairing, and it is the one to be most careful about because it is on the record as a rejection-type combination: Dasgupta X for claims 5, 7, 9, 10, 18, 20, and US 5,590,199 Y against the same claims.

What the pairing accomplishes. US 5,590,199 is an electronic information network user authentication and authorization system — it supplies the centralized identity/authorization layer (F2, and the "authorization/permissions" flavor of F6) that Dasgupta's RSX-11M+ paper does not. Because the examiner cited it as Y (not A) against the same claims that Dasgupta was cited as X against, the Office's position was that Dasgupta discloses the session/relocation structure and Krajemski supplies what Dasgupta lacks, with the two together rendering those claims obvious.

Motivation. A network in which users can attach to any terminal and reach server-hosted processes requires a central authentication/authorization authority, not a per-terminal check. Krajemski teaches exactly that role; the artisan implementing Dasgupta's multi-terminal movable interface across a real network would look to a network authentication and authorization system by simple engineering necessity. KSR: "a court must ask whether the improvement is more than the predictable use of prior art elements according to their established functions."

---

H. Combination 4 — Adding RFC 2131 + RFC 1321/RFC 2104 for the mechanical features

The '289's remaining recited elements are mechanical and are supplied by RFCs the specification itself names as background:

• F11 (terminal obtains its own and the AM's address) — RFC 2131 (DHCP) is the standard mechanism, and the spec says so ("An example of a dynamic host configuration protocol is provided in RFC 2131"). Where the terminal reads its addresses from a smart card, that is a design choice between a network protocol lookup and a stored configuration value — obvious either way.
• F4 (the specific hash primitive) — RFC 1321 (MD5) and RFC 2104 (HMAC), both cited in the spec's background section, and the spec concedes "the hmac_md5 function (RFC2104) is one example of a hashing function that is used in an embodiment of the invention." Selecting hmac_md5 over bare MD5 is an obvious "known technique available to the artisan" choice; the ISR-adjacent literature shows the field was moving from MD5-only to HMAC-MD5 in exactly this period.

There is no non-obviousness argument available here: the specification itself names these references as the prior art from which its implementation is drawn. That is close to an admission.

---

I. Combination 5 — Rebutting the "authenticate once for all of the user's services" advantage

The '289 touts that "authentication is a one-way authentication which improves the manageability and scalability," that "there is no need to exchange keys," and that its architecture "avoids the need to perform key lookups in a central database." Two independent problems defeat using these as § 103 rebuttal:

1. They are efficiency/design-choice arguments, not evidence of unexpected results. Under KSR, "the fact that the [claimed] improvement … [is] more efficient … does not make it patentable" where the result is the predictable product of known elements.
2. They are contradicted by the reference they are drawn from, and partly by the '289 itself. RFC 1994 §2.2 concedes that CHAP is "not as useful for large installations, since every possible secret is maintained at both ends of the link," and §2.1 tells implementers to use the Name field "as an index to locate the proper secret in a large table of secrets." The '289's authentication manager does essentially that — it holds a per-user record (userID, secret, PIN, sessionHost, sessionPort, sessionID) in authentication database 218 and looks up the record by the userID returned in the response packet. The "avoid key lookups" advantage is therefore (a) not clearly achieved, and (b) at best a known trade-off inherent in choosing CHAP-style one-way auth. This is a useful point for an obviousness or § 112(a) challenge, and I flag it as an internal tension in the specification.
3. The "authenticate once for all services" advantage is separately known. Wu et al. (Sun, App. 08/499,487, filed 1995) discloses unified login/logout spanning multiple authentication services via a single primary token, and the field's whole PAM/Kerberos literature (which the sibling EP 1 043 648 application discusses as prior art) is built on single-sign-on.

---

J. Conclusion on § 103, feature-by-feature

Bottom line. If the '289's independent claims are drawn where the specification and the continuation claim 1 point — a method of authenticating a user at a terminal and directing that user's already-executing services to whichever terminal the user is presently at, with authentication by a challenge-response using an incrementing identifier and a hash over the identifier, a secret and the challenge value — then the claims are obvious under pre-AIA § 103(a) over: (1) Dasgupta + RFC 1994; (2) Dasgupta + US 5,590,199 (the examiner's own combination); or (3) Dasgupta + Tarantella AIP + RFC 1994, with RFC 2131/1321/2104 supplying the remaining mechanical limitations. The two halves of the invention were each independently known, each indexed to the other's problem, and the field's own literature (Tarantella, Citrix) shows the combination being made commercially before the critical date.

---

K. Limits on this analysis — read before relying on it

1. No claim chart is possible at claim-level precision. I do not have the verbatim text of any claim of US 6,223,289. Everything in §D–§J is keyed to the disclosed embodiment and the examiner's claim-group mapping (claims 5, 7, 9, 10, 18, 20). If the '289's independent claims contain a narrowing limitation absent from the specification passages I have (e.g., a specific smart-card exchange, a specific two-level permanent/dynamic session-record structure recited structurally, or the specific isLazy lazy-instantiation rule), the analysis above would need to be re-run against that language. The isLazy lazy-instantiation feature and the permanent/dynamic session-record split are the two features I would most want the claim text to test, because they are the least prefigured in Dasgupta, Tarantella or RFC 1994.
2. The examiner-cited combinations are from the family, not necessarily from the '289's own file wrapper. The ISR is for PCT/US99/08665 and the EP citations are from EP 1 074 136 B1. A US examiner may have cited additional or different art in the '289's own file, which I have not seen. Pull the '289's USPTO file wrapper ("Patent Center → Documents & Transactions") to confirm the actual US rejections and any applicant remarks.
3. The § 102(b) status of the Tarantella white paper and the Citrix press coverage is asserted on date, not on proven public accessibility. Both are October 1997 / September 1998 — the Citrix article is after the 1998‑04‑20 date and therefore only usable to show the state of the art as of that date, not as § 102(b) art; the Tarantella paper (20 Oct 1997) is § 102(b) art only if its public accessibility can be proven (a Docket Alarm exhibit from IPR2015‑00471 is evidence it was publicly accessible, but that is a different proceeding's record).
4. The Wu et al. patent number is unverified. I have the application number (08/499,487, filed 1995‑08‑07) and the front-page content from a PTAB exhibit, not a patent number. I have deliberately not supplied one.
5. No litigation, PTAB or CAFC history exists for US 6,223,289 (per the earlier litigation section). There is therefore no § 282 validity judgment, no IPR estoppel, and no prosecution-bar or collateral-estoppel ruling to constrain or support the analysis above.
6. Legal status discrepancy remains open — see the flag at the end of §A.