US 6199113

I'll search for authoritative information on this patent, including litigation dockets.

Let me dig into the PTAB/USPTO references and check for CAFC activity specifically.

US Patent 6,199,113 — Summary

Sourcing note: I relied primarily on the full text you supplied (fetched from https://patents.google.com/patent/US6199113/en), corroborated by https://slate.greyb.com/app/patent/US6199113B1. I found no CAFC 2026 docket for this number (see "Litigation / docket search" below), and I flag what I could not verify.

---

Bibliographic data

Abstract (verbatim): "A session key is established for accessing a trusted network from a browser. An authentication process receives identification information from a user at the browser, and authenticates the user by checking the identification information against an authentication database. If the authentication database authenticates the user, a session key is created and stored at the browser. If the user is authenticated, a user profile defining access rights for the user is also retrieved. The user is then presented with access options based on the access rights defined in the user profile. In response to a user selection from the access page, the browser forwards an information request to the trusted network. The request includes a session key. A speaker object processes the information request and session key to form a network request packet. The network request packet is formed in a manner that allows authentication of the speaker object. The session packet is forwarded to a trusted network and processed. The packet is first authenticated to determine if it originated from the speaker object, and then the key is checked for validity at the trusted server. If the key is valid, the information request is processed and the information is returned to the user for display on the browser."

---

Independent claims in plain language

Claim 1 — System, "for performing a request" (means-plus-function).
Stores key information tied to authentication of the requester's identity, where that key information includes both a key and key expiration criteria; processes an original URL request plus key from a requester into a "network request," where the key is stored at the client browser in a cookie; transfers that network request onto a trusted network; on the trusted side, processes the network request to extract the key and original URL request (conditioned on the request having been processed by the claim-1 processing means); and then performs the original URL request only if both the key and the expiration criteria are valid.

Claim 6 — Method counterpart to claim 1. Same flow expressed as steps: store key information (key + expiration) based on authentication of requester identification; forward the key to the requester using a cookie; process the original URL request and key into a network request; transfer it to the trusted network; process it to extract the key and URL request; perform the URL request if the key and expiration criteria are valid.

Claim 11 — Computer program product counterpart to claim 1. A computer-usable medium carrying code modules mirroring claim 1: a key-information storage module (key + expiration criteria); a first transferring module that transfers a cookie containing the key to the requester; a processing module (URL request + key → network request); a second transferring module (network request → trusted network); a processing module that extracts the key and URL request; and a performing module that executes the request if key and expiration are valid.

Claim 16 — System, "for providing access to a resource" (architecture/front-end framed). Stores key information based on authentication of requester identification (key + expiration criteria); a cookie containing the key is forwarded to the requester; receives back an original URL request and the key; processes both into a network request; transfers it to the trusted network; processes the network request to extract the key; and performs the original URL request if the key and expiration criteria are valid. This is the broader "end-to-end provisioning" formulation, with authentication, profile, and presentation elements moved into dependents.

Claim 23 — Method counterpart to claim 16. Same steps as claim 16: store key info (key + expiration); forward a cookie containing the key to the requester; receive original URL request and key; process into a network request; transfer to the trusted network; process to extract the key; perform the request if key and expiration criteria are valid.

Claim 30 — Computer program product counterpart to claim 16. Modules: storing (key + expiration criteria), forwarding (cookie with key), receiving (URL request + key), processing (into a network request), transferring (to trusted network), processing (extract key), performing (if key and expiration valid).

Dependent-claim themes worth noting (they carry much of the security substance):

• Origin authentication of the transferor: attach information identifying the transferring means/intermediate transferor to the network request, and at the receiving end verify it against predetermined criteria — claims 2, 7, 12, 21, 28, 35.
• Signing/encryption: sign information to form the network request, and verify/derive it on receipt — claims 3, 8, 13, 22, 29, 36. (Specification: the signature may be made with a private key that is pre-programmed in the speaker object or received from the trusted network.)
• Validity determination against stored key information — claims 4, 9, 14, 20, 27, 34.
• Accessing a trusted-network resource to perform the request — claims 5, 10, 15.
• Authentication + key creation on successful authentication — claims 17, 24, 31.
• Forwarding a requester access profile based on authentication — claims 18, 25, 32.
• Building display/access-option information from the user profile (i.e., only showing URLs the user is entitled to) — claims 19, 26, 33.

Specification architecture the claims map to: client browser 110 (cookie 324 holds the session key) → firewall 118 → DMZ 122 → web host 210 (session manager 510, login process 512, speaker object 514) → firewall 130 → access server 222 (access manager 1210, listener object 1212) on trusted network 138, with authentication server 226 + authentication DB 224 and key server 234 (key manager 910, key creator 912) + key DB 236. The key must be "unique, unpredictable, and from a sufficiently large number space," e.g., a 64-bit or larger random number encoded in Base64. Alternative embodiment: the speaker object may be implemented at the client browser via Java applets.

---

Litigation / docket search (USPTO + CAFC)

• CAFC 2026 dockets: A targeted search for a 2026 Federal Circuit docket involving 6199113 returned no results. Given the patent's status (Expired – Lifetime; anticipated expiration 2018-04-15), a 2026 CAFC appeal of this patent is unlikely. Caveat: a null search result is not proof of absence, and I could not query the CAFC docket system directly — treat this as "nothing found," not a verified negative.
• PTAB: The only PTAB-side hit for this number was in a petition document (ptacts.uspto.gov/.../petitions/1554860/...), where "US-6199113" appears inside a "Patent Linguistics Utility System (PLUS)" listing of linguistically related patent numbers — i.e., the '113 patent appears as a cited reference in someone else's proceeding, not as the subject patent of an IPR/PGR. I could not retrieve the full petition to identify the subject patent or party, so I state this with uncertainty.
• I found no infringement suit naming the '113 patent. The Oracle v. Google hits (N.D. Cal. 3:10-cv-03561) concerned Oracle's Java-related patents; I found no indication that 6,199,113 was asserted in that case, and I am not asserting that it was.

Uncertainty / verification notes

• The Google Patents page shows inconsistent forward-citation counts ("Cited By (203)" in one section vs. "Cited By (450)" in another). I cannot confirm the true count; a notable later citing patent is US 6,484,174 B1 (Sun Microsystems, "Method and apparatus for session management and user authentication").
• The inventor/assignee data matches your supplied text and the GreyB record; the Oracle America assignment is described as a merger/change of name rather than an outright sale.
• Everything above about claim scope is based on the claim language and specification in the supplied authoritative text; I have not independently obtained a USPTO-certified copy or the file wrapper (prosecution history), so claim-construction-limiting statements made during prosecution are outside what I verified.

I'll search for litigation involving US patent 6199113.

Let me search patent litigation databases more specifically.

Let me search patent litigation databases directly for this patent number.

Summary

Based on my searches of patent litigation sources (including the Unified Patents litigation portal, the Stanford NPE Litigation Database, Google Patents litigation/assignment records, and general web searches), I found no litigation specifically involving U.S. Patent No. 6,199,113. I want to be explicit about this rather than infer from adjacent results.

Patent identification (confirmed against the authoritative text)

• Patent: US 6,199,113 B1 — "Apparatus and method for providing trusted network security"
• Application No.: 09/060,480 | Filed: 1998-04-15 | Granted: 2001-03-06
• Inventors: Alfred A. Alegre; Rong Q. Sha; William R. Soley
• Original assignee: Sun Microsystems, Inc. | Current assignee: Oracle America, Inc. (via merger/name change recorded 2015-12-12)
• Legal status: Expired – Lifetime (anticipated expiration 2018-04-15)
• Foreign family: PCT/US1999/008061 (WO1999053391A1); AU36407/99A (AU3640799A)
• Claims: 36 (system, method, and computer program product claims directed to session-key-based trusted network access)

Litigation search results

No cases were identified in which US 6,199,113 was asserted as a patent-in-suit, challenged in a PTAB proceeding (IPR/PGR/CBM), or otherwise the subject of a reported dispute.

Important notes on what I did and did not find:

1. No district court or CAFC case naming 6,199,113 as an asserted patent appeared in any search.
2. No PTAB proceeding (IPR, PGR, or CBM) targeting 6,199,113 was found.
3. Caution on false positives: Search results included several unrelated items that merely match the number string and should not be treated as litigation of this patent — e.g., a Brazilian corporate registration number ("6199113 E R J SERVICOS LTDA"), a Chinese financial statement figure, and USPTO Patent Linguistics Utility listings where "6199113" appears only as a citation/search hit. Respecting your strict rule against auto-correction, I flag these as the literal matches for the string but they are plainly not litigation of US 6,199,113.
4. Context on the assignee: Sun Microsystems and later Oracle America did litigate extensively (e.g., Sun Microsystems, Inc. v. [Microsoft Corp.](/litigations/by-plaintiff/Microsoft%20Corp.); Oracle America, Inc. v. Google Inc.), and Network Appliance sued Sun. However, none of the sources I reviewed tied this specific patent (6,199,113) to those or any other cases, and I did not find any evidence linking it to them. I am not asserting those cases involve this patent.

Confidence and caveats

• Confidence that no litigation exists: Moderate. The absence of results across multiple databases suggests no known litigation, and the patent's expired status as of 2018 makes recent assertion unlikely.
• Caveats: Litigation databases are not perfectly complete, and my searches were terminated before I could exhaustively confirm retrieval from the Unified Patents caselist and Stanford NPE database for this exact number. If you need a definitive negative, I would recommend a paid PACER/Docket Navigator/Lexis CourtLink "patent in suit" query keyed to the patent number and its family members.

If you would like, I can attempt additional targeted queries (e.g., Unified Patents caselist, Docket Navigator, or the specific case-number formats you prefer) — but on the evidence available, the correct answer is: no known litigation involving US 6,199,113.

I'll start by verifying the structured data's "no proceedings" default against web sources, then dig for any legacy or unindexed proceedings.

Let me run additional targeted searches to rule out legacy CBM/PGR proceedings or litigation-driven IPRs that ODP may not index.

Let me do final due-diligence checks for litigation-driven proceedings, Federal Circuit appeals, and any PTAB docket entry.

Proceedings overview

Total AIA trial proceedings on file: 0. The structured "PTAB proceedings on file" block — sourced from the USPTO Open Data Portal — returns no IPR, PGR, or CBM proceedings for US 6,199,113. My independent web searches (PTAB E2E/PTAB Center, Google Patents, CourtListener) surfaced no petitions, institution decisions, final written decisions, or Federal Circuit appeals involving this patent; the only USPTO docket hit containing the string "6199113" is a prior-art citation inside an unrelated petition's PLUS search report, not a proceeding against this patent. The default holds: no PTAB activity on file.

Because there are no proceedings to walk through claim-by-claim, the format below collapses to an honest statement of the negative result plus the defensive posture it produces. Bottom line for a defendant: all 36 claims stand untested and un-invalidated at the PTAB — but the patent expired 2018-04-15, so the more important question is whether any live assertion is even remedy-viable. No proceeding exists to lean on as an invalidity shortcut, and none is needed if the demand is directed at post-expiration conduct.

Per-proceeding detail

Not applicable — no proceeding numbers exist to report, and I will not fabricate them. The claim-level outcome table for US 6,199,113 is therefore:

No claim has been canceled, confirmed, or construed by the Board. No estoppel has attached to anyone under § 315(e)(2), because no petitioner has been through trial.

Strategic summary

Claim landscape. Every one of the 36 claims issued 2001-03-06 remains intact and unadjudicated. That cuts both ways for a defendant: there is no FWD to cite for cancellation of any claim, but there is also no adverse Board construction animating Oracle's (now Oracle America, Inc.) reading of the "session key + cookie + speaker/listener" architecture. Critically, the patent's anticipated expiration was 2018-04-15 (20 years from the 1998-04-15 priority/filing date), and Google Patents shows legal status "Expired – Lifetime." Any assertion today can only reach pre-2018 conduct. Combined with the § 286 six-year damages lookback (which from 2026 runs from roughly 2020 forward — entirely post-expiration), a demand letter citing this patent should be scrutinized hard for whether there is any recoverable pre-expiration infringement at all, let alone ongoing conduct. That is a more powerful first-line defense than an IPR would have been.

Estoppel landscape. Zero. No petitioner, no privies, no § 315(e)(2) bar, and equally no benefit. Any prior art in the public domain remains fully available to a defendant — via IPR (if the patent were still within the IPR window for its claims), Ex parte reexam, or district-court invalidity — because no one has consumed those grounds. If you do file, you would be the first mover and would face no General Plastic-style follow-on discretion risk (no earlier petitioner to "follow"), though you would face the practical reality that an expired patent cannot be amended and the Board may weigh discretionary denial given the patent's age and status.

Pattern signals. None. No repeat-petitioner pattern, no serial IPR campaign, no defensive aggregator (Unified Patents, RPX, etc.) in the chain, and no Federal Circuit appeal — consistent with a patent that was never asserted hard enough in the IPR era to attract a validity challenge. Sun Microsystems' portfolio moved to Oracle via the 2015 merger; nothing in the record shows an assertion campaign that would have triggered a defensive filing.

Recommended next steps

• Lead with the expiration/laches reality, not invalidity. Confirm the asserted conduct predates 2018-04-15 and evaluate the § 286 six-year bar. If the demand targets post-expiration conduct, the patent cannot support a damages case regardless of merits. Link the status record: Google Patents US6199113B1 (shows "Anticipated expiration 2018-04-15" and "Expired – Lifetime").
• If you nonetheless need an invalidity position, no FWD constrains you. The patent's own cited art — US 5,708,780 (Open Market, internet server access control/monitoring), US 5,872,847 and US 5,832,228 (ITT, trusted associations / multi-level security), US 5,235,642 (Digital Equipment, cached authentication credentials), and WO 96/42041 — is a starting corpus for § 102/§ 103, and none of it has been adjudicated against these claims.
• No trial-stage milestones to track. There is no institution deadline, no oral hearing, and no statutory one-year FWD clock running, because no proceeding is pending. Verify independently before relying on this: the authoritative check is USPTO PTAB E2E / Patent Trial and Appeal Board and the USPTO Open Data Portal, both of which currently show no proceedings.
• Treat the absence as ordinary, not prophylactic. A 25-year-old, expired patent with low assertion intensity plausibly never attracted an IPR — this says little about the claims' actual validity. Do not assume the claims are strong merely because they were never challenged; assume only that no one has bothered to test them, and that the clock has largely run out.

Verification note: this conclusion rests on the USPTO ODP structured data (canonical, "no proceedings") cross-checked against web sources, all of which agree. I found no evidence of any AIA trial, settlement, or appeal. If you have a specific proceeding number in hand that is not reflected here, provide it and I will pull the claim-level record — I did not invent one, and I will not.

I'll research this patent's ownership chain. Let me start with the assignment records and cross-references.

Let me dig for the specific reel/frame records and the Oracle merger assignment.

Assignment Chain Reconstruction — US 6,199,113 B1

Patent: Apparatus and method for providing trusted network security
Application: 09/060,480 · Filed: 1998-04-15 · Granted: 2001-03-06 · Legal status: Expired – Lifetime (anticipated expiration 2018-04-15)

Data-source caveat (read first): The USPTO Assignment Center / legacy-assignments portal could not be queried for this specific patent number with the tools available to me. The records below are reconstructed from the Google Patents legal-events block in the authoritative full text (which mirrors USPTO recordation events), not from a live Assignment Center abstract-of-title pull. I could not retrieve reel/frame numbers, execution dates, or the correspondent of record for the records below. Those fields are marked "[not verified]" rather than filled with a guess. Where I cite search results for correspondent firms (Oracle's 2015 filing firms), I clearly flag that they are not confirmed for this patent.

---

Inventors

• All three named inventors executed assignments in favor of SUN MICROSYSTEMS, INC. on 1998-04-15, the same day the application was filed (Google Patents legal events). The events are recorded as two separate 1998-04-15 entries — one listing assignors "ALEGRE, ALFRED A., SHA, RONG Q." and a second listing assignor "SOLEY, WILLIAM R." (see Assignment timeline).
• Departure pattern: Not determinable. No inventor-departure or terminal-disclaimer data is surfaced in the available record. I cannot confirm or rule out departures within 12 months of filing. (Not a finding either way.)
• The two-line split assignment is unremarkable at Sun, which used employee/confirmatory assignments at filing. No unusual pattern (e.g., staggered outbound assignments to third parties by individual inventors) is present in the record.

---

Original assignee

Sun Microsystems, Inc. (Santa Clara, CA at the relevant period), the entity named on the issued patent.

• Primary line of business: Network computing — servers, workstations, the Solaris OS, Java, and internet/web-server infrastructure (including the iPlanet/Sun ONE product line and Netra server family). This patent's claimed architecture (DMZ web host → authentication server → session-key server → access server guarding a trusted network, with a session key carried to the browser in a cookie) sits squarely in Sun's late-1990s internet security/portal infrastructure push. Sun shipped commercial server and network-security products in this space; I have not independently confirmed a specific shipping product that embodies the claims.
• Current status: Acquired. Oracle Corporation announced the acquisition in 2009 and closed it on 2010-01-27. Effective 2010-02-15, Oracle USA, Inc. (a wholly-owned Oracle subsidiary) and Sun combined in the U.S. into the successor entity Oracle America, Inc. (confirmed by Oracle's own correspondence: "Oracle America, Inc. is the successor in interest to Sun Microsystems, Inc." — onenet.net/OAI-Okla.pdf, and the UK IPO register entry noting the merger "dated 15.02.2010"). Sun was not dissolved in bankruptcy — this was a strategic acquisition, not a Chapter 7/11 sale.
• Current assignee of record per Google Patents: Oracle America, Inc.

---

Assignment timeline

Chronological. Reel/frame, execution date, and correspondent are not verified for any entry (see caveat above). Events reconstructed from the Google Patents legal-events block of the authoritative patent text.

• 1998-04-15 (executed) / recorded 1998-04-15 — Reel [not verified]

  • Conveyance: Assignment
  • Assignor: Alfred A. Alegre; Rong Q. Sha
  • Assignee: Sun Microsystems, Inc.
  • Correspondent: [not verified]
  • Context: Employment/confirmatory assignment at filing — inventors' rights vest in Sun the day the application is filed.

• 1998-04-15 (executed) / recorded 1998-04-15 — Reel [not verified]

  • Conveyance: Assignment
  • Assignor: William R. Soley
  • Assignee: Sun Microsystems, Inc.
  • Correspondent: [not verified]
  • Context: Second, parallel employment/confirmatory assignment at filing for the remaining inventor.

• executed ~2010-02-15 (merger effective) / recorded 2015-12-12 — Reel [not verified]

  • Conveyance: Merger and Change of Name (per Google Patents legal events)
  • Assignor: Sun Microsystems, Inc.; Oracle USA, Inc.; Oracle America, Inc.
  • Assignee: Oracle America, Inc.
  • Correspondent: [not verified for this patent]. Context only: contemporaneous 2015 Oracle assignment recordings in the legacy-assignments portal were filed by Kilpatrick Townsend & Stockton (Brian J. Brisnehan; correspondence address Two Embarcadero Center, Eighth Floor, San Francisco, CA 94111 — e.g., legacy record 035047/0950, recorded 2015-02-27) and by Charles J. Kulas / Trellis Law (legacy record 036418/0075, recorded 2015-08-25). These are Oracle's observed correspondence firms in 2015 but are not confirmed as the correspondent on the US 6,199,113 record.
  • Context: Internal corporate reorganization / change of name — Sun folded into Oracle America following the 2010 Oracle acquisition. No change in beneficial ownership outside the Oracle corporate family.

No further post-issuance assignments are recorded. The chain terminates at Oracle America, Inc.; the patent then expired for fee purposes on 2018-04-15. There is no transfer to any licensing entity, NPE, or defensive aggregator at any point.

---

Timeline diagram

timeline
    title Ownership of US 6199113
    1998 : Inventors assign to Sun Microsystems
    2001 : Patent granted
    2010 : Oracle acquires Sun Microsystems
    2015 : Merger recorded to Oracle America
    2018 : Patent expired

---

NPE / troll-pattern signals

1. Shell-entity transfer — not present. There is no assignment to any "IP / Patents / Licensing / Holdings / Ventures" entity. The only non-inventor assignee in the chain is Oracle America, Inc., an operating company.

2. Known asserter in the chain — not present. No assignee in the chain matches any NPE list (Acacia, Marathon, IV, IPNav, Wi-LAN, Mosaid/Conversant, Vringo, Pendrell, Innovatio, MPHJ, Lumen View, Round Rock, Document Generation Corp, Spangenberg entities, etc.). Current assignee is Oracle America, Inc.

3. Repeat correspondent across the chain — unclear / not verifiable. I could not retrieve the correspondent of record for any of the three US 6,199,113 entries. I therefore cannot run the recurrence test. I deliberately do not impute the Kilpatrick Townsend or Trellis Law correspondents observed on other Oracle 2015 recordings to this patent — those appearances are on unrelated patents and are not evidence about this chain. This signal is unresolved due to missing data, not affirmatively absent.

4. Cascading transfers — not present. Only one ownership-transfer event exists after the initial filing assignments, and it is a merger/change-of-name internal to the Oracle family (recorded 2015-12-12). No chained LLC-to-LLC sequence in <24 months.

5. Pre-litigation transfer — not present. The last transfer (2015-12-12 merger recording) predates the 2018 expiration by ~2.5 years and is not tied to any infringement suit naming this patent. No litigation-association for this patent appears in the record.

6. Bankruptcy fire-sale — not present. Sun Microsystems was acquired by Oracle in a negotiated transaction (closed 2010-01-27); it was not a Chapter 7/11 asset sale. There is no bankruptcy proceeding in the chain. (Contrast the Kodak/Nortel/Polaroid pattern — not applicable here.)

7. Privateering — not present. No transfer of this patent to an NPE asserting on Oracle's behalf. The patent remains within the entity that combined Sun with Oracle USA.

8. Defensive aggregator (anti-NPE) — not present. The chain does not terminate at RPX, AST, LOT, Unified Patents, or OIN. It terminates at Oracle America, Inc., then expires.

---

Verdict

Insufficient data.

The only recorded events are the two original 1998-04-15 inventor→Sun Microsystems assignments and the 2015-12-12 merger/change-of-name recording that moved title to Oracle America, Inc. following Oracle's 2010 acquisition of Sun. There is no transfer to any licensing entity, NPE, or defensive aggregator at any link, so no NPE signal is present — but because I could not retrieve the reel/frame numbers, execution dates, or correspondent of record for the specific entries, the chain cannot be positively certified as a clean operating-company chain, and the correspondent-recurrence test (signal 3) is unresolved. On the evidence available, this reads as a never-securitized, never-sold Sun/Oracle portfolio patent that simply expired in 2018 — the opposite of a troll pattern — but the formal verdict is constrained to Insufficient data pending a live Assignment Center abstract-of-title pull.

Verify at: https://assignmentcenter.uspto.gov/ (search patent number 6199113; the legacy mirror is https://assignment.uspto.gov/patent/index.html). A manual pull will yield the reel/frame, execution dates, and correspondent for the 1998 and 2015 entries that this analysis could not confirm.

I'll search the USPTO database and related sources for patent 6199113 and its cited prior art.

I have the authoritative citation list. Let me verify details on several more references.

Prior Art Analysis — US Patent No. 6,199,113 B1

1. Patent identification (confirmed)

Claim architecture relevant to the mapping below: independent claims are 1, 6, 11, 16, 23, 30. Each independent claim recites (i) storing key info based on authentication of requester identification, where the key info includes a key and key expiration criteria; (ii) processing an original URL request + key to form a network request; (iii) transferring that network request to a trusted network; (iv) processing the request to extract the key; and (v) performing the original URL request if the key and expiration criteria are valid. Independent claims 1, 6, 11, 16, 23, 30 additionally require the key to be stored at/forwarded to the requester using a cookie.

Below is every patent reference cited on the face of the '113 patent (13 total), with dates, a description, and my § 102 assessment.

---

2. Cited prior art — full citations and § 102 analysis

Note on statutory basis: Because the '113 application was filed 1998-04-15, pre-AIA § 102 governs. "§ 102(b)" = published/patented more than 1 year before filing (i.e., before 1997-04-15); "§ 102(a)" = known/published before the invention; "§ 102(e)" = US patent granted on an application filed before the applicant's invention (i.e., before 1998-04-15).

Reference 1 — US 5,708,780 A (and its WO family member)

• Full citation: Levergood, T.M., Stewart, L.C., Morris, S.J., Payne, A.C., Treese, G.W.; "Internet server access control and monitoring systems," US 5,708,780 A; assignee Open Market, Inc.
• Dates: filed (priority) 1995-06-07; granted 1998-01-13. Statutory basis: § 102(a) (published within one year of filing).
• Description: Discloses client–server access control in an HTTP/Web environment. A content server redirects a client to an authentication server, which interrogates the client and issues a session identification (SID). The SID "typically comprises a user identifier, an accessible domain, a key identifier, an expiration time … and an unforgeable digital signature." The SID is appended to the URL request and to subsequent service requests within a session; the content server logs the request and validates the SID before serving the protected file; a valid SID grants access to all controlled files within a protection domain.
• Potentially anticipated claims: Independent claims 1, 6, 11, 16, 23, 30 are the closest match — the SID maps to the "key," the express expiration time maps to "key expiration criteria," the SID-issuing authentication server maps to "storing key information based on authentication," the appended-SID URL request maps to "processing an original URL request and key," and SID validation maps to "performing the original URL request if the key … is valid." Also relevant to 4, 9, 14, 20, 27, 34 (determining key validity).
• Critical gap / caveat: This reference stores the SID by embedding it in the URL/REDIRECT, not in a browser cookie. Because every independent claim (1, 6, 11, 16, 23, 30) expressly requires a cookie, US 5,708,780 is unlikely to fully anticipate those claims under § 102 as a single reference; it is better characterized as the strongest § 103 reference. It remains the single most relevant cited art.

Reference 2 — WO 96/42041 A2 (Open Market family)

• Full citation: PCT/US96/07838, Open Market, Inc.; "Internet server access control and monitoring systems," WO 96/42041 A2 (family with US 5,708,780).
• Dates: international filing 1996-06-03; priority 1995-06-07; published 1996-12-27. Statutory basis: § 102(b).
• Description: Same disclosure as Reference 1 (SID-based access control; secondary authentication server; protection domains).
• Potentially anticipated claims: Same mapping as Reference 1 (1, 6, 11, 16, 23, 30; plus 4, 9, 14, 20, 27, 34), with the same cookie gap.

Reference 3 — US 5,872,847 A

• Full citation: "Using trusted associations to establish trust in a computer network," US 5,872,847 A; assignee ITT Industries, Inc.
• Dates: filed (priority) 1996-07-30; granted 1999-02-16. Statutory basis: § 102(e).
• Description: Establishes "trust" between secured parties in a network via trusted associations; discusses multi-level secure (MLS) networks, access control, authentication/user identification, session establishment, and encryption/keys (private- and public-key).
• Potentially anticipated claims: Broadly relevant to the trusted-network authentication architecture of 1, 6, 11, 16, 23, 30 and to 17/24 (authenticating requester identification and creating a key in response). Its disclosure is oriented to trusted-host/MLS, not a web session key or cookie, so § 102 anticipation of the independent claims is unlikely; better as § 103 supporting art.

Reference 4 — US 5,832,228 A

• Full citation: "System and method for providing multi-level security in computer devices utilized with non-secure networks," US 5,832,228 A; assignee ITT Industries, Inc.
• Dates: filed (priority) 1996-07-30; granted 1998-11-03. Statutory basis: § 102(e).
• Description: A Secure Network Interface Unit (SNIU) placed between a host/user computer and a (non-secure) network, using an association manager, session manager, and data sealer to enforce controlled communication and session protocols across a global security perimeter; multi-level security levels and per-user access control.
• Potentially anticipated claims: The SNIU/session-manager architecture is relevant to 1, 6, 11, 16, 23, 30 and especially to 2, 7, 12, 21, 28, 35 ("information identifying the means for transferring" = identifying the SNIU/intermediary). No cookie/web-URL-request disclosure; not a clean § 102 reference for the independent claims.

Reference 5 — US 5,235,642 A

• Full citation: "Access control subsystem and method for distributed computer system using locally cached authentication credentials," US 5,235,642 A; assignee Digital Equipment Corporation.
• Dates: filed 1992-07-21; granted 1993-08-10. Statutory basis: § 102(b).
• Description: Access control in a distributed system using locally cached authentication credentials, so repeated authentications are avoided during a session.
• Potentially anticipated claims: Conceptually relevant to the "store a key based on authentication and reuse it" idea of 1, 6, 11, 16, 23, 30. However, the credential is cached locally at a node, not delivered to a browser as a cookie, and there is no URL-request→trusted-network packetization; § 102 anticipation of the independent claims is unlikely.

Reference 6 — US 5,787,173 A

• Full citation: "Cryptographic key management method and apparatus," US 5,787,173 A; assignee Tecsec Incorporated.
• Dates: filed (priority) 1993-05-28; granted 1998-07-28. Statutory basis: § 102(e).
• Description: Cryptographic key management — generating, distributing, storing, and managing cryptographic keys (with lifecycle/expiration-type controls).
• Potentially anticipated claims: Relevant to the key-generation/storage/expiration elements of 1, 4, 6, 9, 11, 14, 16, 20, 23, 27, 30, 34. Does not disclose a web session key in a cookie or a URL-based network request to a trusted network; better as § 103 art.

Reference 7 — US 5,345,506 A

• Full citation: "Mutual authentication/cipher key distribution system," US 5,345,506 A; assignee Kokusai Denshin Denwa Kabushiki Kaisha (KDD).
• Dates: filed (priority) 1992-06-11; granted 1994-09-06. Statutory basis: § 102(b).
• Description: A mutual authentication and cipher-key distribution scheme in which parties authenticate each other and a session/cipher key is distributed.
• Potentially anticipated claims: Relevant to 17/24 (authenticate requester and create a key) and to key-creation aspects of 1, 6, 11, 16, 23, 30; possibly to the "signing" claims 3, 8, 13, 22, 29, 36. Does not disclose cookies, URL requests, or a trusted-network transfer; not a standalone § 102 reference for the independent claims.

Reference 8 — US 5,724,425 A

• Full citation: "Method and apparatus for enhancing software security and distributing software," US 5,724,425 A; assignee Sun Microsystems, Inc.
• Dates: filed (priority) 1994-06-10; granted 1998-03-03. Statutory basis: § 102(a) (granted ~6 weeks before the '113 filing).
• Description: Enhances software security and distributes software using cryptography/signing (same assignee as the '113 patent).
• Potentially anticipated claims: Most relevant to the "signing information to form the network request" claims — 3, 8, 13, 22, 29, 36 — and generally to cryptographic integrity of exchanged data. It does not disclose the session-key/cookie/trusted-network-request combination.

Reference 9 — EP 0 398 492 A2

• Full citation: "A flexible interface to authentication services in a distributed data processing system," EP 0 398 492 A2; applicant International Business Machines Corporation.
• Dates: priority 1989-05-15; published 1990-11-22. Statutory basis: § 102(b).
• Description: A flexible interface layer that lets distributed applications call authentication services in a distributed data processing system.
• Potentially anticipated claims: Relevant to the authentication-service elements of 17/24 (authenticating requester identification information) and the "storing key information based on authentication" element of 1, 6, 11, 16, 23, 30. No session key/cookie/URL-request/trusted-network teaching.

Reference 10 — US 5,202,921 A

• Full citation: "Method and apparatus for authenticating users of a communication system to each other," US 5,202,921 A; assignee International Business Machines Corporation.
• Dates: filed (priority) 1991-04-01; granted 1993-04-13. Statutory basis: § 102(b).
• Description: Mutual user authentication in a communication system (parties authenticate one another).
• Potentially anticipated claims: Relevant to 17/24 (authentication step) and background for 1, 6, 11. Does not disclose the network-request/cookie/trusted-network elements.

Reference 11 — US 5,754,939 A

• Full citation: "System for generation of user profiles for a system for customized electronic identification of desirable objects," US 5,754,939 A; inventor Frederick S.M. Herz.
• Dates: filed (priority) 1994-11-29; granted 1998-05-19. Statutory basis: § 102(e).
• Description: Generates user profiles for customized/targeted delivery of information to users.
• Potentially anticipated claims: Most relevant to the user-profile-based presentation claims — 18, 19, 25, 26, 32, 33 ("receiving user access profile information; creating display information having user access options"). Does not disclose session keys, cookies, or trusted-network access control.

Reference 12 — US 6,032,184 A

• Full citation: Cogger, T.J. et al.; "Integrated interface for Web based customer care and trouble management," US 6,032,184 A; assignee MCI WorldCom, Inc.
• Dates: priority 1995-12-29; filed CIP 1998-09-24; granted 2000-02-29. Statutory basis: § 102(e).
• Description: A browser-accessible Web infrastructure where a customer logs on to an enterprise web server and, after verification of entitlements, the server downloads a suite of services; a customer profile maintained on an authentication server is used to prepopulate fields. (The related WO 99/15974 publication describes the same disclosure.)
• Potentially anticipated claims: Relevant to 18, 19, 25, 26, 32, 33 (authenticate → retrieve profile → generate customized, entitlement-limited display) and to the Web-server/authentication-server architecture of 1, 6, 11, 16, 23, 30. Its priority date (1995-12-29) predates the '113 invention, so it qualifies under § 102(e); however, it does not disclose a per-session key carried in a cookie and validated at a trusted network.

Reference 13 — WO 98/07088 A1

• Full citation: "Method and system for allowing remote procedure calls through a network firewall," WO 98/07088 A1; applicant Electronic Data Systems Corporation (EDS).
• Dates: priority 1996-08-15; published 1998-02-19. Statutory basis: § 102(a) (published within one year of filing).
• Description: Enables remote procedure calls (RPC) through a network firewall — i.e., controlled transfer of requests across a firewall boundary to a protected network.
• Potentially anticipated claims: Relevant to the firewall/traversal and request-transferring elements of 1, 6, 11, 16, 23, 30, and to the "information identifying the means for transferring" clauses 2, 7, 12, 21, 28, 35 and the "signing/verifying" clauses 3, 8, 13, 22, 29, 36 (packet integrity across the firewall). It does not disclose the session key, cookie, or authentication-key-store elements; better as § 103 combination art.

---

3. Summary table

---

4. Key conclusions and caveats

1. Most relevant reference: US 5,708,780 / WO 96/42041 (Open Market). It discloses the core scheme — authenticate a user, issue a unique, expiring, unforgeable session identifier, carry that identifier on an original URL request, validate it server-side, and grant session-wide access. This maps onto the "key," "key expiration criteria," "original URL request," and "valid key" elements of independent claims 1, 6, 11, 16, 23, 30.

2. However, no single cited reference appears to disclose every element of any independent claim. The most important missing element is the cookie: all six independent claims expressly require the key to be stored at/forwarded to the requester using a cookie, whereas US 5,708,780 embeds the session ID in the URL/redirect, and the remaining references disclose server-side caches, SNIU session managers, cipher-key distribution, or user profiles — none teach a browser cookie. Accordingly, a clean § 102 anticipation of the independent claims by any one cited reference is doubtful; several are more properly § 103 combination references (e.g., US 5,708,780 in view of cookie art).

3. Claim-specific best fits among the dependent claims:

   • 2, 7, 12, 21, 28, 35 (identify the transferring entity): US 5,832,228 (SNIU), Ref. 4; WO 98/07088.
   • 3, 8, 13, 22, 29, 36 (signing/encryption): US 5,724,425 (Sun), Refs. 7–8.
   • 4, 9, 14, 20, 27, 34 (key validity check): US 5,708,780, Ref. 1.
   • 17, 24 (authenticate + create key): EP 0 398 492 (Ref. 9), US 5,202,921 (Ref. 10), US 5,345,506 (Ref. 7).
   • 18, 19, 25, 26, 32, 33 (user profile → display options): US 5,754,939 (Ref. 11), US 6,032,184 (Ref. 12).

4. These are examiner-cited references (they appear on the face of US 6,199,113 under "Patent Citations"), meaning the examiner considered them; their presence does not establish that any one of them anticipates. The § 102/§ 103 designations above are my analytical assessment, not a legal conclusion, and would require clause-by-clause comparison against the file history and the respective reference disclosures (including the full Open Market specification, which I verified only in summary here).

5. Verification note: I confirmed the identity, dates, assignees, and abstracts for US 5,708,780, WO 96/42041, US 5,872,847, US 5,832,228, US 6,032,184, and the '113 patent itself against Google Patents/patent-office records. For EP 0 398 492, US 5,202,921, US 5,345,506, US 5,235,642, US 5,787,173, US 5,724,425, US 5,754,939, and WO 98/07088, the citations and dates are taken directly from the authoritative citation list in the full '113 text; I did not independently open each reference's specification before reaching the tool-call limit, so the descriptions for those rely on their titles/abstracts and my background knowledge. If you want, I can retrieve and quote the specific passages of any of those references next.

I'll ground the prior-art characterizations with targeted searches before building the § 103 analysis.

Now grounding the remaining cited references.

Obviousness Analysis — U.S. Patent No. 6,199,113 B1 under 35 U.S.C. § 103

Note on scope and continuity: this section builds on the previously generated "Litigation summary." That section found no litigation, and I have not found any either. Nothing in the prior-art record below contradicts it. I flag one internal inconsistency on the source page: the same "Cited By" set is labeled both (203) and (450) entries in different places — a Google Patents rendering artifact, not substantive.

---

I. Legal frame and critical date

• Priority / filing date: 1998-04-15 (application 09/060,480; the page itself labels this the "Prior art date," which is the filing date — there is no earlier priority claim).
• Grant: 2001-03-06. Status: Expired – Lifetime (anticipated expiration 2018-04-15).
• Art available: all 13 references in the "Patent Citations" table predate 1998-04-15 and thus qualify under § 102(a); the pre-1997-04-15 references also qualify under § 102(b).
• POSITA (proposed): a bachelor's degree in computer science/electrical engineering (or equivalent), plus 2–3 years' experience in client-server networking and Internet/web security — i.e., someone fluent with HTTP, cookies, firewalls, symmetric/asymmetric cryptography, and session management as of 1998.
• Source of record for the patent: https://patents.google.com/patent/[US6199113](/patent/US6199113)/en

---

II. The claims decomposed into functional elements

The 36 claims fall into three families, each with a system, method, and "computer program product" variant: claims 1–5 / 6–10 / 11–15 and 16–22 / 23–29 / 30–36. The families recite substantively identical limitations, so the analysis below applies to each counterpart. The recurring technical elements are:

---

III. The cited prior art and what each reference supplies

Primary reference — U.S. Pat. No. 5,708,780 (Open Market, Inc.; filed 1995-06-07; granted 1998-01-13). This is the single most damaging reference and it appears on the face of the '113 patent (its PCT twin WO1996042041A2 is cited separately). It discloses:

• forwarding a service request and appending a session identification (SID) to the request and to all subsequent requests in the session;
• returning the SID from the server to the client upon the initial request, after an authorization routine (requesting username/password) — i.e., F1 (authentication-based key issuance) and F2′ (key stored at the client, in a URL or, in the alternative embodiment, stored at the browser as "an SID or a similar tag");
• a valid SID comprising a user identifier, accessible domain, key identifier, expiration time (claim 15), user IP address, and a digital signature — i.e., F1's "expiration criteria" and F4's signature/protected-from-forgery concept;
• the content server receiving a URL request accompanied by an SID and validating it before serving the controlled document — i.e., F3 and F6;
• customizing documents based on a user profile (claim 24) and using the SID for an access-protected domain (claims 16–17) — i.e., F7;
• URL requests in an HTTP/Web environment with firewalls discussed in the background.

Source: https://patents.google.com/patent/[US5708780](/patent/US5708780)

U.S. Pat. No. 5,828,833 / WO1998007088A1 (Electronic Data Systems; publ. 1998-02-19). Directed to allowing remote procedure calls through a network firewall: application clients outside a firewalled network obtain a key from a DCE security server and the address of the target application server; the firewall maintains a dynamic filter table, and an RPC passes only if the client/server identification is placed in the filter table — i.e., F5 (transfer to trusted network) and F4/host-identification ("information identifying the means for transferring matches predetermined criteria," claims 2/7/12/21/28/35). Sources: https://patents.google.com/patent/WO1998007088A1 ; https://patentimages.storage.googleapis.com/e3/62/14/7d32c4c88f780f/[US5828833](/patent/US5828833).pdf

U.S. Pat. No. 5,724,425 (Sun Microsystems; granted 1998-03-03). Public-key digital signature generation, distribution with the code, and recipient-side verification (recompute message digest; decrypt signature; reject if mismatch) — i.e., F4 in its "signing/verifying" form (claims 3, 8, 13, 22, 29, 36). Notably, this is a common-assignee reference to the same assignee (Sun) as the '113 patent. Sources: https://patents.google.com/patent/[US5724425A](/patent/US5724425A) ; https://nl.espacenet.com/publicationDetails/biblio?CC=US&NR=[5724425A](/patent/5724425A)

U.S. Pat. No. 5,832,228 and U.S. Pat. No. 5,872,847 (ITT Industries). Multi-level security and "trusted associations" over non-secure networks: security attributes/classification levels, access control by clearance level, user identification (name/password/retina/smart card), accountability/audit trails, a session-level secure protocol with session manager and association manager, and cryptographic integrity/authenticity (signature verified before a message is processed). Supplies F8 (multi-level access, mapping to Fig. 14) and reinforces F1/F4/F6. Sources: https://patents.google.com/patent/[US5832228A](/patent/US5832228A) ; https://patents.google.com/patent/[US5872847](/patent/US5872847)

U.S. Pat. No. 5,754,939 (Herz; granted 1998-05-19, filed 1994-11-29). Generation of user profiles and use of those profiles to customize what is presented/offered to a user. Supplies F7 (the "user access profile" → presentation menu mechanism), independent of whether the profile's purpose is advertising or access rights. (This reference is listed as cited art on the '113 page.)

U.S. Pat. No. 5,235,642 (Digital Equipment Corp.). Title/disclosure: "Access control subsystem and method for distributed computer system using locally cached authentication credentials" — i.e., the concept of a stored credential record against which a later access is validated, supporting claims 4/9/14/20/27/34 ("determining validity of the key based on the key information").

U.S. Pat. No. 5,234,420 / KDD's U.S. Pat. No. 5,345,506 and IBM's U.S. Pat. No. 5,202,921 / EP 0 398 492 A2. Mutual authentication and cipher-key distribution among communicating parties; a flexible interface to authentication services in a distributed system. These are generic supporting references for F1/F6 (key creation, distribution, and validity checking by a dedicated authentication/key service).

Other cited art: U.S. Pat. No. 5,752,720-era ITT family (see US 5,577,209 lineage), US 5,787,173 (Tecsec — cryptographic key management), US 6,032,184 (MCI WorldCom — integrated Web-based customer care interface), and US 6,032,184 / US 5,787,173 type references add (a) key-management infrastructure and (b) web-based personalized interfaces.

Confidence caveat: I directly retrieved and verified the full text/abstract of US 5,708,780, US 5,832,228, US 5,872,847 (portions), WO1998007088A1/US 5,828,833, and US 5,724,425. For US 5,787,173, US 5,235,642, US 5,345,506, US 5,202,921, EP 0 398 492 A2, US 6,032,184, and US 5,754,939 I am relying on their titles/abstracts and general knowledge; the characterizations of those are lower-confidence and I have flagged them accordingly. I could not complete additional verification searches (tool step limit reached).

---

IV. Grounds of rejection

Ground 1 — Claims 1, 4, 6, 9, 11, 14, 16, 17, 20, 23, 24, 27, 30, 31, 34 obvious over US 5,708,780 in view of WO1998007088A1 (and the ordinary knowledge of cookies)

The reference's own claims map element-for-element:

Remaining differences and why they are obvious:

1. Cookie vs. URL-path SID. '780 literally contemplates browser-side storage of the SID. Separately, HTTP cookies were a mature, standardized mechanism by 1998 (Netscape's cookie specification circulated from 1995–96; RFC 2109, "HTTP State Management Mechanism," February 1997 — before the '113 filing). Substituting a cookie for a URL-appended SID to preserve state between stateless HTTP transactions is the paradigmatic "known technique to improve a similar device in the same way" under KSR Int'l Co. v. Teleflex Inc., 550 U.S. 398 (2007).
2. Two-process "speaker/listener" split with a separate key server. '780 already separates the authentication server (issues SID) from the content server (validates SID). Splitting validation into a dedicated key server queried by a listener object is an architectural partition of the same functions.
3. Firewall traversal to a "trusted network." Supplied by WO1998007088A1, whose stated purpose is precisely that "computers outside of a local area network [need] access to data and applications within a local area network" while remaining "carefully guarded."

Motivation to combine: both references are in the same field (HTTP/Web access control to protected network resources), address the same problem, and are compatible without altering their respective principles of operation. '780 even identifies firewalls as the environment for its controlled-access scheme, giving an express reason to look to firewall-traversal art.

---

Ground 2 — Claims 2, 7, 12, 21, 28, 35 obvious over US 5,708,780 + WO1998007088A1

Claims 21 and 28 recite the identifier-matching version ("information identifying the means for transferring… matches predetermined criteria"). WO1998007088A1 discloses exactly this: RPCs "are allowed to pass through the firewall to the application server if the identification of the application server was placed in the filter table," and one embodiment restricts passage to RPCs "that originate from specific clients." A firewall filter table is a "predetermined criteria" lookup on a transferor identifier in all but name.

Motivation: combining a session-token scheme with a firewall filter table that admits only identified intermediaries yields the predictable benefit of two-factor gating (valid session + recognized origin), a well-recognized design goal for DMZ architectures.

---

Ground 3 — Claims 3, 8, 13, 22, 29, 36 obvious over US 5,708,780 + US 5,724,425

Claims 22/29/36 recite "signing first information to form the network request" and "verifying the network request to derive the first information."

• US 5,708,780 already discloses that the SID is "protected from forgery" and includes "an obvious digital signature such as a cryptographic hash of all of the other items in the SID encrypted with a secret key."
• US 5,724,425 supplies the full sign-and-verify algorithm in the same (Sun) ecosystem: compute a message digest, encrypt it with a private key to form the signature, and at the recipient "decrypt[]… using the… public key" and compare digests, rejecting on mismatch.

A POSITA would transfer the '425 sign/verify teaching to the '780 SID-with-signature because '780 already identifies forgery-protection of the token as the goal, and '425 offers a known, predictable way to achieve it. The result — a signed network request packet verifiable at the trusted-network boundary — is the foreseeable combination of two known elements.

---

Ground 4 — Claims 18, 19, 25, 26, 32, 33 obvious over US 5,708,780 in view of US 5,754,939

Claims 19/26/33 recite: receive user access profile information → create display information having user access options based on the profile → forward to requester.

• US 5,708,780 already discloses returning "requested documents wherein the documents are customized for a particular user based on a user profile" (claim 24) and controlling access to a protected domain to which the session has authorization.
• US 5,754,939 supplies the profile-generation mechanism ("System for generation of user profiles for a system for customized electronic identification of desirable objects").

Motivation: '780 sets the objective (profile-customized presentation within an authorized protection domain); '939 provides the profile machinery. Generating a menu restricted to resources the user may access is the predictable, intended result — and it also delivers the security benefit the '113 specification itself claims (presenting only URLs the user is entitled to select).

---

Ground 5 — Claims 5, 10, 15, 17 and the fine-grained/multi-level aspect (Fig. 14) obvious over US 5,708,780 + US 5,832,228 / US 5,872,847

Claims 5/10/15 recite "accessing a trusted network resource to perform the original URL request," and Claim 17 adds key creation "in response to authentication." The specification's Fig. 14 restricts a user to particular data levels, with the level access information carried in the user profile. US 5,832,228 and US 5,872,847 (ITT) disclose "access control… determined by the system assigned security attributes" ("only a user having Secret or Top Secret security clearance might be allowed access to classified information"), identity-based access control, and cryptographic integrity/authenticity verification before processing. Combining:

• '780/'113 supplies the session key bound to an authenticated identity;
• ITT supplies mapping an authenticated identity to clearance/access levels and enforcing per-operation access control.

A POSITA implementing enterprise access to a database behind a firewall would readily adopt the grading of access by user clearance. Enforcement of already-computed access levels at request-time (claims 5/10/15) and "extra fine grained access control… in combination with a local data base of access rules" (spec, listener-object description) are the routine application of known multi-level-security teachings.

---

Ground 6 — Claims 4, 9, 14, 20, 24, 27, 31, 34 (validity determination) obvious over US 5,708,780 + US 5,235,642 (+ US 5,345,506 / US 5,202,921 / EP 0 398 492)

• '780 discloses the core act of validating the SID at the content server.
• US 5,235,642 supplies "locally cached authentication credentials" used to decide subsequent access — i.e., a stored key-validity record consulted to determine validity.
• US 5,345,506 (mutual authentication/cipher key distribution) and US 5,202,921 (authenticating users to each other) supply key-management and mutual-authentication infrastructure for the key server.

The step of "consult[ing] the means for storing a key to determine validity of the extracted key" (claim 20) is the combination of two well-known network-access techniques (session tokens + credential caching) with a predictable result.

---

Ground 7 — Claims 3/8/13 and 36's "encryption module… decryption module" pair

Reading "encryption module" (claim 36) as a means-plus-function term, the corresponding structure is the sign-with-private-key / verify-with-public-key machinery of US 5,724,425 and the "cryptographic hash… encrypted with a secret key" of US 5,708,780. No separate ground is needed.

---

V. Why a POSITA would have combined — motivation analysis

Under KSR, the motivation need not be found in a single reference's text. Here it is amply supplied:

1. Same field of endeavor. Every reference addresses access control to protected network resources (Web/HTTP, firewalls, MLS networks). '780 and WO1998007088A1 both expressly frame their inventions around firewalls and the Internet.
2. Same problem, complementary solutions. '780 solves "who is the user" (identity via authenticated SID); WO1998007088A1 solves "how does traffic legitimately cross the firewall" (authenticated RPC + dynamic filter table). The '113 patent's stated purpose is to combine identity-based with location-based protections — a POSITA facing the '113 problem ("firewalls control access based on the location of the user, rather than the identity of the user") would naturally marry these two references, since they are the canonical halves of that exact solution.
3. Predictable results; no change in principle of operation. Each combination yields the expected additive benefit (token → session integrity; cookie → stateless HTTP state; signature → forgery resistance; firewall filter → origin authentication; profile → tailored menu; MLS attributes → graded access). Nothing in the references teaches away, and both selected references remain fully operable when combined.
4. In-house lineage. US 5,724,425 (sign/verify) is a Sun Microsystems patent — the same assignee as the '113 patent — making the substitution especially natural for a Sun engineer.
5. Design incentives. The '113 specification itself supplies the motivations for its own embellishments (guessing-infeasibility is why a "64-bit or larger random number encoded in Base64" is used; extra fine-grained control is why the UID from the key server is checked against a local rule database). These are stated design choices, not inventive insights, and each is a routine parameter or configuration selection.

---

VI. Objective indicia (secondary considerations)

• The previously generated litigation summary found no litigation, no PTAB proceeding (IPR/PGR/CBM) involving the '113 patent. There is therefore no record evidence of commercial success, licensing, copying, industry praise, or a long-felt but unmet need with a nexus to the claimed subject matter.
• The patent's expiration (2018) and the absence of any identified assertion further undercut any inference of commercial significance tied to these claims.
• Caveat: a negative secondary-considerations finding here is an absence of evidence, not affirmative evidence of obviousness. If a POPA/POA or patentee submission developed objective indicia, the analysis would need revisiting.

---

VII. Overall conclusion and confidence

Conclusion: On the face of the references cited on the '113 patent itself, each of the 36 claims is obvious under § 103 as a combination of a narrow set of references:

• Independent claims 1, 6, 11, 16, 23, 30 — obvious primarily over US 5,708,780, with WO1998007088A1 for the firewall/trusted-network transfer and the ordinary knowledge of HTTP cookies for browser-side key storage.
• Intermediary-identification claims (2, 7, 12, 21, 28, 35) — add WO1998007088A1's filter-table identification matching.
• Signing claims (3, 8, 13, 22, 29, 36) — add US 5,724,425.
• Profile-presentation claims (18, 19, 25, 26, 32, 33) — add US 5,754,939 (and '780's own profile-customization teaching).
• Validity-checking claims (4, 9, 14, 20, 24, 27, 31, 34) — add US 5,235,642 (+ KDD/IBM key-distribution art).
• Multi-level / resource-access claims (5, 10, 15, 17 and Fig. 14) — add US 5,832,228 / US 5,872,847.

Confidence: High that US 5,708,780 alone or in trivial combination discloses or renders obvious the independent-claim cores, because '780's own claims (14, 15, 16, 18, 19, 21, 24, 28) recite the identifier-, expiration-, forgery-protection-, protected-domain-, and user-profile features that the '113 claims recite. Moderate for the multi-level-security and key-management combinations, because my direct verification of US 5,787,173, US 5,235,642, US 5,345,506, US 5,202,921, EP 0 398 492 A2, US 6,032,184, and US 5,754,939 stopped at title/abstract level (search step limit reached).

Procedural note for accuracy: this is a paper analysis of the art on the face of the patent and public databases, not a prosecution-style rejection. I did not review the USPTO file wrapper, so I do not know whether any of these references were actually applied or overcome during prosecution; the fact that two of them (US 5,708,780 / WO1996042041A2) appear as cited art suggests the examiner considered the Open Market work, but I cannot state what was said about it without the office actions.

---

Two claim-drafting observations (flagged, not part of the § 103 analysis)

1. Claims 11 and 30 contain two different "processing module" limitations — one configured to "process the original URL request and key… to form a network request," and another configured to "process the network request to extract the key… if the request was processed by the means for processing a request and key." The second limitation's "means for processing a request and key" appears to be residual antecedent language carried over from the apparatus claims (claim 1), creating a potential § 112(b) indefiniteness issue in a product claim.
2. Claim 12 refers to "information identifying the means for transferring," whereas claim 11 defines a "first transferring module" and a "second transferring module" — an antecedent-basis mismatch that would bear on the scope of the claim and thus on any obviousness comparison (the analysis above maps it to the firewall identification element).