US 6317838

Here's a concise summary of US patent 6317838, "Method and architecture to provide a secured remote access to private resources":

• Title: Method and architecture to provide a secured remote access to private resources
• Assignee: EVIDAN (Current Assignee), Bull SAS (Original Assignee)
• Inventor: Eric Baize
• Filing Date: 1998-04-29
• Issue Date: 2001-11-13
• Abstract: The patent describes a method and architecture enabling a remote user, particularly an Internet user, to securely access private resources protected by a firewall. The architecture includes a computer facility with a security server managing a security database. The firewall features a centralized security means, controlled by the security server, which authenticates remote users and provides a security profile detailing all resources a user can access with a single sign-on (SSO) during a single session. The user's terminal also includes a device for generating one-time passwords (OTPs), and the computer facility has a corresponding device to decode these passwords. The accessed resources can be servers or logical units accessed via protocols that support authentication.

Plain-Language Overview of Independent Claims:

• Independent Claim 1 (Method Claim): This claim describes a method for a remote user to securely access private resources within a digital data processing system protected by a firewall.
  • Initial Setup:
    • A security storage system is implemented to hold security data, including user authentication data, security profiles (listing which resources each user can access), and security data for the private resources themselves.
    • A centralized security system is implemented within the firewall. This system is designed to filter remote access requests based on rules derived from the stored security data.
  • Operational Steps:
    • User Side: The remote user initiates a session, provides security data (including authentication data), and requests access to a first private resource.
    • Digital Data Processing System Side: The centralized security system in the firewall compares the user's provided security data with the stored authentication data to authenticate the user. If authentication is successful, the centralized security means is provided with the user's security profile. Finally, the requested first private resource receives security data, allowing the authenticated user access.
• Independent Claim 8 (Network Apparatus Claim): This claim describes a network architecture (a system) that allows a remote user's terminal to securely access private resources within a digital data processing system protected by a firewall.
  • User's Terminal: The terminal includes mechanisms for a user to input security data (authentication data) and to request access to specific private resources.
  • Digital Data Processing System: This system contains security storage means for storing security data, including user authentication data, security profiles (indicating accessible resources), and security data for the private resources.
  • Firewall: The firewall is equipped with a centralized security means. This means is configured to:
    • Authenticate the remote user upon receiving their entered security data.
    • Filter remote access requests based on rules derived from the security data.
    • Retrieve the appropriate security profile for the authenticated user from the security storage means.
    • Provide the first private resource with the necessary security data, thereby allowing the remote user to access that resource.

CAFC 2026 Dockets Search:

A search of CAFC 2026 dockets for US patent 6317838 did not yield any specific results indicating ongoing litigation in the Court of Appeals for the Federal Circuit for the year 2026. This means there is no authoritative information available at this time to suggest active cases in the CAFC for this patent.

It's important to note that the patent "US6317838B1" has a legal status of "Expired - Lifetime" with an anticipated expiration date of 2018-04-29, as indicated in the provided patent text. This suggests that the patent rights have lapsed, which would make current litigation less likely. However, this information is based on the patent's metadata and not an exhaustive legal review of all possible dockets or related proceedings. While a patent's expiration generally means it can no longer be asserted, there could theoretically be lingering effects or related cases not directly identified through a simple docket search.

The USPTO website provides tools like Patent Public Search and Patent Center for checking patent status and file history. These resources can be used to search for application numbers, patent numbers, and assignment records.

As of April 26, 2026, a search for litigation involving US patent 6317838 across various patent litigation databases, including Unified Patents and PACER, did not yield any specific results for active or concluded cases.

Therefore, no known litigation involving US patent 6317838 can be listed with details regarding plaintiff(s), defendant(s), jurisdiction, case number, filing date, and outcome or current status.

It is important to reiterate that the patent US6317838B1 has a legal status of "Expired - Lifetime" with an anticipated expiration date of 2018-04-29. This means the patent rights have lapsed, making new infringement litigation unlikely.

I'll verify the structured-data default against live sources before drafting.

Let me check a couple of specialized sources to be thorough.

PTAB / AIA Trial Proceedings — US Patent 6,317,838

Proceedings overview

Total AIA trial proceedings on file: 0. The structured "PTAB proceedings on file" block (USPTO Open Data Portal ingest) returns no IPR, PGR, or CBM for US 6,317,838 — a breakdown of 0 active / 0 claims invalidated / 0 claims sustained / 0 settled / 0 institution denials. The bottom-line defensive posture is therefore not "the patent survived two IPRs and is hardened" and not "claim 1 was canceled." It is stronger and simpler than either: there is no PTAB record because there is no live patent to attack. US 6,317,838 expired 2018-04-29 (20 years from the 1998-04-29 filing, no PTA — filed pre-2000 — and no PTE), and all 14 claims are dead of natural term. A demand letter citing this patent in 2026 is citing an expired patent, which is a defect independent of, and more fundamental than, any validity attack.

I should be explicit about the evidentiary basis and its limits:

• What is authoritative: the structured PTAB block — 0 proceedings. That is the canonical USPTO Open Data Portal list and I have not overridden it.
• What I checked: targeted web searches for IPR/PGR/CBM petitions naming 6,317,838 or the Baize/Bull/Evidan chain returned no PTAB filing. Two apparent "838" hits are false positives from a different patent — U.S. Patent 12,010,838 (Micron v. YMTC, PTAB petitions filed 2024-11-29), which is a 3D NAND memory patent with no relationship to this one. Do not conflate them.
• What the searches did surface is US 6,317,838 in the prior-art role, not the challenged-patent role: it is cited as an "X" (most relevant) reference against claims 1–14 in the search reports of WO 2003/007157 (Nokia), WO 2005/034468 and WO 2006/037864 (Orange/France Télécom), and appears in the citation lists of EP 2 051 180 A1 and CN 100364265 C. Being cited as prior art by third parties is evidence the disclosure is broadly relevant to remote-access firewalls — it is not PTAB activity on this patent.

Because the count is zero, the per-proceeding template (petitioner, judge panel, institution decision, FWD, appeal, defensive value) has no entries to populate. I will not invent proceeding numbers, panels, or dispositions to fill it.

Strategic summary

Claim status across the patent: All claims 1–14 are neither canceled nor sustained — they are expired and unenforceable. Independent claim 1 (method) and independent claim 8 (network apparatus), plus dependents 2–7 (SSO re-use of session credentials; Internet delivery; authenticated application protocols; login/password; profile-driven credential provisioning; Hash-based OTP from a secret and a time word) and 9–14 (security server, database, protected servers, Internet, proxy devices, one-time-password generator/decoder), all lapsed on 2018-04-29. There are no "surviving claims" to list because there is no surviving term. The prior-art and obviousness analyses generated earlier in this file (firewall + SSO + OTP combinations over US 5,721,908, US 5,944,824, US 5,657,388, US 5,491,752) remain useful only as a defensive historical record — they are moot as a live PTAB strategy.

Estoppel landscape — § 315(e)(2): There is no estoppel, and this is the analytically interesting point. § 315(e)(2) bars a petitioner (and its privies/RPIs) from raising in a civil action any ground raised or that reasonably could have been raised in an IPR that reached a final written decision. With zero IPRs and zero FWDs, no party is estopped from anything. Conversely, no party has benefited from the estoppel shield either. The AIA trial window for this patent ran from 2012-09-16 (IPR/CBM availability) to 2018-04-29 (expiration) — a 5.7-year window in which an IPR on pre-AIA claims could be filed at any time by anyone (no § 315(b) one-year bar unless first served with a complaint). Nothing was filed. The practical read: any invalidity ground that could have been run is still fully available in theory, but it is academic, because a defendant's best ground is § 102(b)/§ 41(c) public-domain status and expiration, not prior art.

Pattern signals: Three negatives worth recording.

1. No repeat petitioner — impossible, there are no petitioners at all.
2. No patent-owner appeal activity — nothing to appeal; no FWD went to the Federal Circuit, consistent with the earlier CAFC 2026 docket search and the litigation summary, both of which returned no cases.
3. No defensive aggregator in the chain — the assignment record runs Baize → Bull, S.A. (1998-06-03) → EVIDAN (2006-09-10, nunc pro tunc). Evidan is not a known member of Unified Patents or any defensive aggregator, and no Unified Patents page for US-6,317,838 surfaced. Note the timing: Evidan took title in 2006 — six years before IPRs existed — held the patent through the entire 2012–2018 AIA-trial window, and (per the litigation summary) never asserted it. An owner that held a broad, well-cited 1998 remote-access-security patent through the peak NPE-assertion years and never filed suit is the single strongest signal here that this was never an assertion asset. That is also the most likely reason no IPR exists: IPRs are overwhelmingly defendant-driven (≈70% of IPR petitioners were previously sued on the patent), and with no assertion there is no petitioner.

One caveat on the record, stated plainly: I am relying on the structured ODP block as the canonical list, and my web searches corroborate it. I did not obtain a live, hands-on query of the PTAB Center / PTAB E2E docket for the patent number in this session. Practitioners who need a belt-and-suspenders confirmation should run US 6,317,838 directly in PTAB Center and in the PTAB API (link below). If a proceeding were to surface, it would most likely be a CBM rather than an IPR (CBM reached pre-AIA patents and needed only a charge of infringement — though this patent's technological-invention carve-out makes CBM institution doubtful) or a pre-2018 IPR. I found no evidence of either.

Recommended next steps

• If you have received a demand letter or licensing communication citing US 6,317,838: the response does not require an IPR. State that the patent expired 2018-04-29, that all claims 1–14 are expired, and that the patent has been in the public domain for over seven years. If the sender asserts claims 1–14, note that claims 1 and 8 are the only independents and both are expired. Time-bar and laches/§ 286 damages-window defenses also collapse because there is no live right to enforce.
• If you are evaluating the patent as prior art against someone else's patent: this is where the reference has real value. US 6,317,838 is an "X"-category reference in multiple third-party search reports (WO 2003/007157; WO 2005/034468; WO 2006/037864) for claims covering firewall-resident centralized authentication, SSO to multiple protected resources, security-profile-driven credential provisioning, and time-based one-time passwords. Compare its 1998-04-29 priority date and its disclosure at column 3 line 50 – column 7 line 14 (the passage the foreign examiners relied on) against any later patent you are challenging. Because it is expired, it is unambiguously available as prior art with no § 102(b)(2)(C) common-ownership complications.
• If no proceedings exist and none is expected: say so plainly, as instructed. The absence here is a signal with a specific cause — the patent was never asserted, its owner never monetized it, and it expired before assertion economics made sense. Well-asserted patents eventually attract IPRs; this one was never asserted, so none was ever filed. There is no trial-stage milestone calendar to track (no institution deadline, no oral hearing, no statutory 1-year FWD deadline), because no trial was ever instituted.
• Verification links (for the belt-and-suspenders check): PTAB Center / PTAB E2E search — https://ptacts.uspto.gov/ptacts/ ; USPTO Open Data Portal — https://data.uspto.gov/ ; the patent's own record — https://patents.google.com/patent/[US6317838B1](/patent/US6317838B1)/en ; CourtListener docket search — https://www.courtlistener.com/?q=%226%2C317%2C838%22 ; Unified Patents patent page — https://portal.unifiedpatents.com/patents/patent/US-6317838-B1 (confirm whether a page resolves before relying on it).

Constraint check: no proceeding numbers, panels, institution decisions, or FWDs were fabricated; where the structured data says zero, I have said zero and declined to populate the per-proceeding template. Claim numbering is quoted as the patent states it (1–14, independents 1 and 8). Dates are YYYY-MM-DD.

I'll research the assignment record for US 6317838 using the available tools.

Let me dig deeper into the assignment records and the entities involved.

Assignment & Ownership Analysis — US Patent 6317838

Source note: The authoritative record available to me is the Google Patents legal-events block and front-page data for US6317838B1 (fetched 2026-09-23), cross-referenced against the Unified Patents patent portal, Bull S.A. investor filings, and Evidian corporate literature. I was not able to pull the reel/frame numbers, correspondent-of-record, or execution dates from the USPTO Assignment Center directly — the search tool available returned no assignment-center detail page, and Google Patents' legal-events block does not expose reel/frame or correspondent. I do not fabricate reel/frame numbers; where a field is unavailable it is marked not retrievable. Verify at the USPTO Assignment Center search page (https://assignmentcenter.uspto.gov/) and https://assignment.uspto.gov/patent/index.html by patent number 6317838.

---

Inventors

Pattern check: Only one inventor, so the "all inventors departed within 12 months" fire-sale precursor cannot apply. The near-immediate inventor→employer assignment (executed ~35 days post-filing) is the ordinary employment-assignment signature of a corporate R&D filing, not a distress signal. No inventor-side anomalies.

---

Original assignee

• Entity on the issued patent: Bull SAS (recorded in the 1998 assignment as "BULL, S.A."; later standardized as Bull SAS). Google Patents lists original assignee as Bull SAS.
• Line of business: Bull S.A. was a French publicly listed (Euronext Paris) information-technology group — mainframes/servers, HPC, integration, and security software. Security was a genuine Bull product line, not a patent-holding shell.
• Product embodying the claims? Yes, plausibly. The invention (centralized firewall authentication + Single Sign-On + One-Time Passwords for remote access) maps directly onto Bull's security software portfolio, which was consolidated under its Evidian subsidiary (founded July 2000 as a Bull Group company; products: identity & access management (IAM), SafeKit high-availability, OpenMaster monitoring). Bull's own annual reports list "Security Solutions (Amesys, Evidian, TrustWay...)" as core products (Bull DDR 2010, p. 38).
• Current status: Bull S.A. was acquired by Atos SE in 2014; the Bull/Evidian security business was folded into the Atos Group. (Moderate confidence on the exact current corporate nesting — Atos publicly pursued, then abandoned, an "Evidian" carve-out in 2022–2023.) The patent itself expired 2018-04-29, so no live owner is asserting it.

Discrepancy flag (per operating rules): The Google Patents record renders the post-2006 assignee as "EVIDAN." The well-documented Bull Group security subsidiary is spelled "Evidian." Unified Patents likewise renders the parent company of the sibling Bull patent US‑5951634‑A as "Evidan." I read "EVIDAN/Evidan" as the recorded/typo form of Evidian — but I cannot confirm from the available record whether the assignment was recorded to "Evidian" or to a separately named "Evidan" entity. Flagging rather than auto-correcting.

---

Assignment timeline

Two recorded conveyances appear in the legal-events chain. Reel/frame and correspondent-of-record were not retrievable with the tools available; I decline to invent them.

• 1998-06-03 (event date as listed) / recorded 1998-06-03 — Reel not retrievable/***

  • Conveyance: Assignment — "ASSIGNMENT OF ASSIGNORS INTEREST (see document for details)"
  • Assignor: Eric Baize (inventor)
  • Assignee: BULL, S.A.
  • Correspondent: not retrievable — a single appearance would not be a finding absent recurrence; cannot assess.
  • Context: Routine inventor-to-employer assignment of rights executed ~35 days after the 1998-04-29 filing.

• 2006-09-10 / recorded 2006-09-10 — Reel not retrievable/***

  • Conveyance: Nunc pro tunc assignment ("NUNC PRO TUNC ASSIGNMENT (see document for details)")
  • Assignor: BULL S.A.
  • Assignee: EVIDAN (Evidian — Bull Group security-software subsidiary; HQ Rue Jean Jaurès, Les Clayes-sous-Bois, France)
  • Correspondent: not retrievable — cannot assess recurrence.
  • Context: Internal corporate reorganization / intra-group transfer. "Nunc pro tunc" ("now for then") means the assignment was recorded retroactively to give effect to an earlier transfer date — the classic instrument for a parent housekeeping its IP title into the operating subsidiary that actually commercialized the technology. Bull → its own 100%-group subsidiary is not an arm's-length sale.

Cross-checks: SEC-filing analogues (Bull S.A. annual reports, e.g. 2004 report p. 24 listing "Evidan" and "Evidan GmbH (Germany)"; 2010 DDR listing Evidian under Security Solutions) corroborate that Evidian/Evidan was a Bull operating subsidiary, not a third-party acquirer. No bankruptcy sale, no NPE-intermediary link appears.

If the Assignment Center shows no additional records beyond these two, that is itself expected: the patent expired in 2018 and no post-2006 transfer was recorded.

---

Timeline diagram

timeline
    title Ownership of US 6317838
    1998 : Eric Baize files app 09 067 961
         : Rights assigned to Bull SA
    2001 : Patent US 6317838 issues
    2006 : Nunc pro tunc transfer to Evidan
    2014 : Bull acquired by Atos
    2018 : Patent reaches expiry

---

NPE / troll-pattern signals

1. Shell-entity transfer — NOT PRESENT. The only post-inventor transfer (2006-09-10) runs from Bull S.A. to Evidian/Evidan, a named Bull Group operating subsidiary (IAM/SafeKit/OpenMaster product line per Copperchase case study and Bull annual reports). No "IP/Holdings/Ventures" suffix, no evidence of a single-purpose Delaware/Texas LLC, no registered-agent address. Name resemblance to a shell is expressly not treated as a finding.

2. Known asserter in the chain — NOT PRESENT. Neither Bull SAS nor Evidan/Evidian appears on the public NPE rosters referenced (Acacia, Marathon, Intellectual Ventures, IPNav, Wi-LAN, Mosaid/Conversant, Vringo, Pendrell, Innovatio, MPHJ, Lumen View, Round Rock, Spangenberg entities). No Unified Patents/RPX high-frequency-plaintiff match surfaced.

3. Repeat correspondent across the chain — UNCLEAR. Correspondent-of-record for the 1998 and 2006 recordings could not be retrieved; recurrence therefore cannot be assessed. This is a genuine data gap, not a negative finding.

4. Cascading transfers — NOT PRESENT. Only two recorded conveyances across ~8 years (1998, 2006) with an 8-year gap; no chain of LLCs, and the single transferee shares the transferor's corporate group.

5. Pre-litigation transfer — NOT PRESENT. No infringement litigation is on record for this patent (see prior litigation section), so the 2006 recording cannot be a pre-suit venue/standing maneuver. The patent expired 2018-04-29.

6. Bankruptcy fire-sale — NOT PRESENT. No Chapter 7/11 sale of Bull or Evidian assets appears in the chain; the 2006 transfer was an intra-group reorganization, not a distressed docket sale. (Atos-level financial restructuring in 2023–24 post-dates the patent's 2018 expiry and is not a link in this chain.)

7. Privateering — NOT PRESENT. Evidian was not an independent NPE asserted on Bull's behalf; it was the operating product company. Nothing in SEC/product literature shows Bull funding a third-party plaintiff.

8. Defensive aggregator — NOT PRESENT. The chain does not terminate at RPX, AST, LOT, Unified Patents, or OIN.

Net: zero of the eight signals is affirmatively present; one (repeat correspondent) is unverifiable due to missing data.

---

Verdict

Defensive / non-asserting.

Justification: the ownership chain runs Eric Baize → Bull S.A. (1998-06-03) → Evidan/Evidian (2006-09-10, nunc pro tunc), i.e., from an inventor to his employer and then, eight years later, from that employer to its own security-software operating subsidiary — a classic intra-group title housekeeping transfer, not an arm's-length sale to an assertion vehicle. Neither assignee matches a public NPE roster, no litigation is on record, and the patent already expired 2018-04-29, so no live assertion is possible. Caveat on the label: the enumerated "Defensive / non-asserting" category is defined as termination at a defensive aggregator (RPX/AST/etc.), which is not what happened here — the chain in fact terminates at an operating company, Evidian. Read the verdict as "no NPE pattern; non-asserting," with the technical definitional mismatch noted, and the missing correspondent/reel-frame data as an open item for a direct Assignment Center pull.

Verify: USPTO Assignment Center — https://assignmentcenter.uspto.gov/ (search "6317838"), and https://assignment.uspto.gov/patent/index.html.

I'll research this patent and its cited prior art before providing the analysis.

Let me verify the remaining cited references before finalizing.

Prior Art Analysis — US Patent 6,317,838

Target patent: US 6,317,838 B1 — "Method and architecture to provide a secured remote access to private resources"
Application: US 09/067,961 · Filed: 1998-04-29 · Priority: 1998-04-29 · Issued: 2001-11-13 · Inventor: Eric Baize · Original assignee: Bull SAS (now EVIDAN)
Claims: 14 (independent method claim 1; independent network/apparatus claim 8)

(Note: the identifier is US 6,317,838 — not a similar number. All analysis below is tied to that literal patent number.)

---

Legal framework (why the dates matter)

Because the application was filed 1998-04-29, pre-AIA 35 U.S.C. § 102 governs. The relevant thresholds:

All ten references below appear in the patent's front-page "Patent Citations (10)" list, i.e., they were cited by/considered during prosecution (the * "cited by examiner" convention in the USPTO record). Their values under § 102 are as follows.

Important caveat on "anticipates." Anticipation requires a single reference disclosing every limitation of a claim. No single reference below discloses the full combination of claims 1/8 (firewall + centralized security means inside the firewall + single sign-on + provision of per-resource security data). The mappings below identify the claims each reference is most relevant to / could potentially anticipate on its own, and I flag where a reference reaches only part of a claim. Most of these are therefore better cast as § 103 combination art — consistent with the earlier Obviousness section of this analysis.

---

At-a-glance table

---

Detailed reference-by-reference analysis

1. US 5,491,752 A — "System for increasing the difficulty of password guessing attacks in a distributed authentication scheme employing authentication tokens"

• Full citation: U.S. Patent 5,491,752 A; priority 1993-03-18; granted 1996-02-13; assignee Digital Equipment Corporation.
• Description: A distributed authentication scheme in which authentication tokens are used and the system is hardened against password-guessing / replay attacks. It addresses token-based (challenge/nonce-style) distributed authentication.
• § 102 basis: § 102(b) — patented more than one year before the 1998-04-29 filing.
• Potential anticipation:
  • Claim 7 — one-time/token-based password generated from a secret combined with a varying (time/counter) value.
  • Claim 14 — the paired "user-side generator + system-side decoder" token architecture.
  • Claim 5 — the authentication-data (log-in/password) context.
• Weakness: No disclosure of a firewall-resident centralized security means or SSO across multiple private resources (the heart of claims 1/8).

2. US 5,657,388 A — "Method and apparatus for utilizing a token for resource access"

• Full citation: U.S. Patent 5,657,388 A (Kenneth P. Weiss); priority 1993-05-25; granted 1997-08-12; assignee Security Dynamics Technologies, Inc. (application US 08/213,951, filed 1994-03-16).
• Description: The classic token-based one-time-passcode system (the "SecureID®" family) — a token derives a non-predictable, time-varying code from a stored seed, which a host verifies against its own synchronized generation. Squarely the OTP technology the patent's own specification identifies as prior art.
• § 102 basis: § 102(e) (application filed 1994-03-16, before the 1998 invention date). Not § 102(b), because it published 1997-08-12 (after 1997-04-29). Also expressly referenced in the specification of US 6,317,838.
• Potential anticipation:
  • Claim 7 — OTP = Hash/combination of a secret digital word and a time-dependent digital word.
  • Claim 14 — user-terminal generator + system-side decoder with stored secrets and synchronized time words.
  • Claim 5 — log-in/password authentication.
• Weakness: Token/OTP only; no firewall, no SSO session, no centralized filtering.

3. US 5,721,908 A — "Computer network for WWW server data access over internet"

• Full citation: U.S. Patent 5,721,908 A; filed 1995-06-07; granted 1998-02-24; assignee International Business Machines Corporation.
• Description: A Web-server architecture with a "control program agent" and distributed sub-agents that gather data from intranet resources behind firewalls and external/internet databases in response to a single client (browser) request. Touches on firewalls, intranet protection, and unified access to heterogeneous back-end resources.
• § 102 basis: § 102(e) (filed 1995-06-07, before the invention date).
• Potential anticipation:
  • Claim 3 / Claim 12 — remote user connected via the Internet.
  • Claim 11 — private resources as protected servers.
  • Claim 1 / Claim 8 — a networked system providing access to protected resources; the firewall boundary is acknowledged.
• Weakness / flag: This reference is about distributed data access / agent architecture, not about an in-firewall authentication-and-filter engine. The earlier Obviousness write-up characterized it as teaching "a firewall and proxy servers," which slightly oversells it — the reference mentions firewalls as the intranet boundary and does not teach proxies in the sense of claim 13. Treat it as background/§ 103 art rather than a standalone anticipatory reference.

4. US 5,768,503 A — "Middleware program with enhanced security"

• Full citation: U.S. Patent 5,768,503 A; filed 1995-09-25; granted 1998-06-16; assignee IBM.
• Description: A middleware layer providing enhanced security, including single-log-on / authentication brokering across a distributed environment — i.e., a client acquires credentials once and the middleware handles downstream authentication to multiple systems.
• § 102 basis: § 102(e).
• Potential anticipation:
  • Claim 1 / Claim 8 — a system/method for authenticating a user and controlling access to multiple resources.
  • Claim 2 / Claim 6 — reuse of a single authentication to reach subsequent resources within the session.
  • Claim 5 — password/log-in authentication.
• Weakness: No firewall-integrated centralized filtering means; no per-resource security-data provisioning as specifically recited.

5. US 5,818,936 A — "System and method for automatically authenticating a user in a distributed network system"

• Full citation: U.S. Patent 5,818,936 A; filed 1996-03-15; granted 1998-10-06; assignee Novell, Inc.
• Description: Automatic authentication of a user across a distributed network — credentials are handled centrally so the user is not repeatedly challenged at each network node (a single-sign-on-like behavior).
• § 102 basis: § 102(e).
• Potential anticipation:
  • Claim 1 / Claim 8 — authenticating a remote user to a distributed system.
  • Claim 2 / Claim 6 — a single set of credentials carrying across multiple resource accesses.
  • Claim 5 — log-in/password.
• Weakness: No firewall-based enforcement point; no OTP; no express "centralized security profile fetched on authentication" architecture.

6. US 5,918,019 A — "Virtual dial-up protocol for network communication"

• Full citation: U.S. Patent 5,918,019 A; filed 1996-07-29; granted 1999-06-29; assignee Cisco Technology, Inc.
• Description: A virtual dial-up / tunneling protocol for remote network communication (remote-access establishment and addressing/authentication of remote clients).
• § 102 basis: § 102(e).
• Potential anticipation:
  • Claim 1 / Claim 8 — generic remote-access network architecture.
  • Claim 3 / Claim 12 — remote access over a wide-area/IP network.
• Weakness: Tunneling/transport art. The patent's own background distinguishes VPN-type tunneling approaches, and this reference does not teach SSO or the in-firewall centralized security means. Weak on its own; useful only as § 103 context.

7. US 5,935,251 A — "Method and apparatus for expedited log-on to an application program"

• Full citation: U.S. Patent 5,935,251 A; filed 1997-12-22; granted 1999-08-10; assignee Hewlett Packard Company.
• Description: "Expedited" log-on — credential caching/reuse so a user who has already authenticated is not forced to re-enter credentials when opening another application.
• § 102 basis: § 102(e) (filed 1997-12-22, before the 1998 filing).
• Potential anticipation:
  • Claim 2 — accessing a second resource using the same entered security data.
  • Claim 6 — reuse of the same user's security data throughout a session.
  • Claim 5 — log-in/password.
• Weakness: Single-machine/application log-on convenience; no multi-resource network, firewall, or SSO profile.

8. US 5,944,824 A — "System and method for single sign-on to a plurality of network elements" ← most on-point

• Full citation: U.S. Patent 5,944,824 A (He et al.); filed 1997-04-30; granted 1999-08-31; assignee MCI Communications Corporation.
• Description: Directly titled single sign-on to a plurality of network elements (NEs). A user authenticates once to a network Security Server (SS); the SS stores user identifiers/passwords and automatically logs the user onto all NEs the user is authorized to access, transparently to the user. Includes the network security administrator concept, security database requirements, and per-NE credentials managed centrally. Verified via Google Patents and the patent PDF (US005944824A).
• § 102 basis: § 102(e) (filed 1997-04-30, before the 1998-04-29 filing). Not § 102(b), because it published 1999-08-31 — after the critical date.
• Potential anticipation — the broadest overlap of any reference:
  • Claim 1 / Claim 8 — method/system where a user authenticates once and the system provides the requested resource with the necessary security data based on an authorization profile.
  • Claim 2 / Claim 6 — subsequent resource access with the same security data; centrally stored per-resource credentials/profiles.
  • Claim 9 / Claim 10 — a controlling security server + security database.
  • Claim 11 / Claim 12 — protected resources / network elements accessed over a network.
  • Claim 5 — log-in/password.
• Weakness: The SSO enforcement point is the security server, not a centralized security means integrated in a firewall; "network elements" are enterprise NEs (switches, STPs, mainframes) rather than firewall-protected Internet resources; no OTP. So it is the strongest § 103 (and near-miss § 102) reference for the SSO core, but it does not by itself meet the firewall-centralization limitation of claims 1/8.
• Cross-check: This reference is also cited against later patents (e.g., Nokia's CN 1314254C lists US 5,944,824 among references), confirming its status as a foundational SSO reference.

9. US 6,038,597 A — "Method and apparatus for providing and accessing data at an internet site"

• Full citation: U.S. Patent 6,038,597 A; filed 1998-01-20; granted 2000-03-14; assignee Dell U.S.A., L.P.
• Description: Providing and accessing data at an Internet site (server-side data provisioning to remote clients).
• § 102 basis: § 102(e) (filed 1998-01-20, ~3 months before the 6,317,838 filing; qualifies only if the invention date post-dates 1998-01-20).
• Potential anticipation:
  • Claim 3 / Claim 12 — remote user accessing resources via the Internet.
  • Claim 1 / Claim 8 — Internet-site resource access (marginal).
• Weakness: Remote relevance only. It is Internet-site data provisioning, not secured remote access through a firewall with centralized SSO. Lowest probative value of the ten patent references.

10. US 6,052,785 A — "Multiple remote data access security mechanism for multitiered internet computer networks" ← second most on-point

• Full citation: U.S. Patent 6,052,785 A (Lin et al.); filed 1997-11-21; granted 2000-04-18; assignee International Business Machines Corporation.
• Description: A three-tier client/middle-tier-server/back-end architecture. The middle-tier server performs client authentication once, caches the resulting credentials in a hash table keyed to the session, and then intercepts client requests and reuses the cached credentials to authenticate the client to multiple back-end remote data repositories — so the client need not re-authenticate on each access. Supports multiple secure protocols (SSL/SHTTP) and multiple back-end authentication schemes. Verified via the patent's Google Patents page and uspto.report full text.
• § 102 basis: § 102(e) (filed 1997-11-21, before the 1998 invention date).
• Potential anticipation:
  • Claim 1 / Claim 8 — authenticating a remote user once and then, on a resource request, supplying the resource with the needed security data (credential provisioning); fetching a stored profile/credential set corresponding to the authenticated user.
  • Claim 2 / Claim 6 — access to a second resource reusing the cached (same) credentials under the user's authorized profile.
  • Claim 9 / Claim 10 — a security server/database managing credentials.
• Weakness: The interceptor is a middle-tier server, not a firewall. It is aimed at SSL/SHTTP web sessions and back-end file/database access, not firewall-protected FTP/Telnet-type private resources; no OTP. Strong § 103 art for the "authenticate once → provision downstream credentials" concept.

Non-patent citation

• Citation: Pfleeger, Charles P., Security in Computing, Second Edition, 1996, pp. 428–434.
• Description: Standard security textbook treatment of authentication, passwords, and access control.
• § 102 basis: § 102(b) (published 1996, more than one year before filing).
• Relevance: Generic background on authentication mechanisms (supports the state of the art for claims 1, 5, 7); not anticipatory of any specific claim on its own, but supports a § 103 motivation to combine known authentication techniques.

References discussed inside the specification (for completeness)

The specification itself names, as known OTP prior art, the SecureID® system, US 5,657,388 (Weiss) (already item 2 above), and McLellan, "The future of Data Security looks Credit-Card Thin," Information Week, Oct. 7, 1985, pp. 24–30. These are acknowledged prior art and reinforce that the OTP elements of claims 7/14 were well known well before the 1998 filing (both § 102(b) for the 1985 article).

---

Overall assessment

1. No single cited reference anticipates independent claim 1 or claim 8. Each reference misses at least one essential limitation — most commonly the "centralized security means implemented in the firewall" and the provision of per-resource security data from a fetched profile as an integrated whole.

2. Closest § 102/§ 103 references:

   • US 5,944,824 A (MCI) — closest to the single-sign-on / centralized credential provisioning core (claims 1, 2, 6, 8–11). Missing: firewall integration.
   • US 6,052,785 A (IBM) — closest to "authenticate once, reuse credentials to reach multiple protected resources" (claims 1, 2, 6, 8–10). Missing: firewall (it uses a middle-tier server).
   • US 5,657,388 A (Weiss) and US 5,491,752 A (DEC) — closest to the OTP limitations (claims 5, 7, 14).

3. The strongest invalidity theory is a § 103 combination, not § 102 anticipation:

   • SSO reference (US 5,944,824 A or US 6,052,785 A) + firewall/proxy art (US 5,721,908 A for the firewall-protected intranet boundary) + OTP art (US 5,657,388 A / US 5,491,752 A) — which is exactly the combination developed in the earlier Obviousness section of this analysis.

4. Caveat on the record: Two references (US 6,038,597 A and, to a lesser extent, US 5,935,251 A) have filing dates only a few months before the 1998-04-29 filing and rest entirely on § 102(e); their availability depends on the applicant's invention date, which is not established in the provided materials. If the invention date precedes 1997-12-22 / 1998-01-20, they would drop out. Flagging this explicitly rather than assuming.

5. Contradiction flag (vs. earlier generated content): The earlier Obviousness section stated that US 5,721,908 A (IBM) teaches "a firewall and proxy servers to protect internal resources." Based on the verified text, US 5,721,908 A is a distributed-data-access / web-agent patent that mentions firewalls as intranet boundaries; it does not teach proxy servers in the claim-13 sense. The proxy limitation (claim 13) is better supported by the patent's own FIG. 2 discussion than by this reference. Recommend softening that characterization if it is reused.

Sources consulted: the authoritative patent text (Google Patents, https://patents.google.com/patent/US6317838B1/en) for the citation list and claim set; https://patents.google.com/patent/US5944824A/en and https://patentimages.storage.googleapis.com/70/a5/3a/430da9ceead26c/US5944824.pdf (US 5,944,824 A); https://patents.google.com/patent/US6052785A#1 and https://uspto.report/patent/grant/6052785 (US 6,052,785 A); https://patents.google.com/patent/US5721908A#1 (US 5,721,908 A); https://patents.google.com/patent/US5657388 (US 5,657,388 A); and the front-page citation table reproduced in the provided patent text for US 5,491,752, 5,768,503, 5,818,936, 5,918,019, 5,935,251, 6,038,597, and the Pfleeger non-patent citation.

Obviousness Analysis of US Patent 6317838 under 35 U.S.C. § 103

A person having ordinary skill in the art (PHOSITA) in 1998, working in network security and remote access systems, would have been motivated to combine various known techniques to achieve the functionalities described in US patent 6317838. The patent's claims, particularly independent claims 1 and 8, which describe a method and architecture for secured remote access to private resources through a firewall with centralized security means, Single Sign-On (SSO), and optionally One-Time Passwords (OTPs), appear to be an obvious combination of existing prior art.

Person Having Ordinary Skill in the Art (PHOSITA)

A PHOSITA in 1998 would possess knowledge of:

• Network architectures, including Local Area Networks (LANs) and Wide Area Networks (WANs) like the Internet.
• Security devices such as firewalls and proxy servers for network perimeter defense.
• User authentication methods, including traditional password/login systems and more advanced token-based authentication like OTPs.
• The concepts of access control, security profiles, and authorization.
• The challenges of remote access over insecure networks (e.g., the Internet), including data interception and replay attacks.
• The growing demand for user-friendly access to multiple network resources, prompting the development of solutions like Single Sign-On (SSO).

Combinations of Prior Art and Motivations

The claims of US6317838 can be rendered obvious by combining the following prior art references, with clear motivations for a PHOSITA to do so:

1. Combination of US5721908A (Firewall/Proxy) and US5944824A (Single Sign-On)

• US5721908A (IBM): Teaches secure access to a WWW server over the Internet, employing a firewall and proxy servers to protect internal resources. This patent establishes the use of a firewall for external-to-internal network security.

• US5944824A (MCI): Explicitly describes a "system and method for single sign-on to a plurality of network elements." This patent teaches the core functionality of SSO, allowing users to authenticate once and access multiple resources without re-entering credentials.

• Motivation to Combine: A PHOSITA aiming to improve user experience and streamline access to multiple private resources protected by a firewall would be strongly motivated to integrate an SSO mechanism into a firewall-protected network. The background of US6317838 itself notes that existing SSO solutions were not always suitable for the unlimited number of users and dynamic nature of the Internet, or that users still had to remember many authentication details. By combining the firewall protection of US5721908A with the SSO functionality of US5944824A, a PHOSITA would create a system where remote users could securely access multiple internal resources behind a firewall with a single initial authentication. This combination directly addresses the problem of managing multiple authentication data for successive resource accesses, as noted in the US6317838 patent.

• Obviousness of Claims 1, 2, 6, and 8:

  • Claim 1 (Method) and Claim 8 (Network Apparatus): The combined system would inherently involve a "digital data processing system protected by a firewall" (US5721908A), "security storing means" (required by SSO in US5944824A for user authentication data and access profiles), and "centralized security means able to filter remote access requests... and to fetch a security profile... and to provide said first private resource with security data" (a natural implementation of SSO within the firewall or a tightly coupled security module, consistent with centralized management objectives). The operational steps of opening a session, entering security data, authenticating, and then providing access to a resource based on a security profile are directly covered by the integration of SSO with a firewall.
  • Claim 2 (Subsequent access with same security data) and Claim 6 (Security profiles and single authentication): These claims describe the core SSO functionality. US5944824A directly anticipates this, showing a system for "single sign-on to a plurality of network elements." Integrating this functionality into the firewall-controlled access (US5721908A) is a straightforward application.

2. Combination of US5721908A (Firewall), US5944824A (Single Sign-On), and US5657388A (One-Time Passwords)

• US5657388A (Security Dynamics Technologies, Inc.): This patent describes a security system (like "SecureID®") that uses a token to generate one-time passwords (OTPs) for accessing resources, preventing replay attacks. The US6317838 patent itself refers to this as known prior art for OTP technologies.

• US5491752A (Digital Equipment Corporation): Describes a system to increase the difficulty of password guessing using authentication tokens and time-varying authentication information (OTPs).

• Motivation to Combine: Even with an SSO system behind a firewall, the initial authentication using static passwords remains vulnerable to interception and replay attacks, especially over an insecure network like the Internet. US6317838 itself highlights this vulnerability with Figure 3 and the accompanying description of an unauthorized user intercepting SSO data. A PHOSITA, recognizing these inherent insecurities and seeking to significantly strengthen the initial authentication step for the combined Firewall+SSO system, would be highly motivated to incorporate a robust, known authentication method like One-Time Passwords (OTPs), as taught by US5657388A and US5491752A. The motivation is to enhance security without sacrificing the user convenience of SSO for subsequent resource access.

• Obviousness of Claims 7 and 14:

  • Claim 7 (One-time password using Hash function and time-dependent word): US5657388A and US5491752A clearly describe the generation of one-time passwords using cryptographic techniques, often involving a secret and a time component, which would naturally employ a hash function.
  • Claim 14 (User terminal device to generate OTPs, digital data processing system device to decode OTPs): US5657388A describes a system with a user-side token for generating OTPs and a server-side component for decoding and authenticating these OTPs, involving synchronized time signals and shared secrets. Integrating this known OTP technology into the initial authentication phase of the centralized firewall security means (from combination 1) is a straightforward application of a known security enhancement.

3. Other Dependent Claims:

• Claim 3 (Remote user through Internet) and Claim 4 (Internet application protocol with authentication notion): The combined references already implicitly or explicitly deal with Internet access and application protocols. US5721908A specifically mentions "WWW server data access over internet." The nature of the Internet as an "insecure network" (as noted in US6317838) is a foundational motivation for all these security measures.
• Claim 5 (Password and log-in): This is a universally known authentication mechanism present in virtually all prior art related to user access.
• Claim 13 (Firewall comprises proxy devices): US5721908A explicitly teaches the use of "proxy servers" within a firewall for secure access.

Conclusion

The core inventive concepts of US patent 6317838—namely, a method and architecture for secure remote access to private resources behind a firewall, incorporating centralized security, Single Sign-On, and One-Time Passwords—are rendered obvious by the combination of the cited prior art. A PHOSITA, driven by the desire to enhance both security and user convenience for remote network access, would have been motivated to combine these known elements in a predictable manner. The individual components (firewalls, SSO, OTPs) and the problems they solve were well-established, making their combination to achieve the claimed functionality an obvious design choice for improving network security and usability in the late 1990s.

US Patent 6317838 was filed on April 29, 1998, and issued on November 13, 2001. [cite: The provided patent text]

Patent Term Adjustment (PTA) and Patent Term Extension (PTE)

• Patent Term Adjustment (PTA): Patent Term Adjustment (PTA) was established by the American Inventors Protection Act of 1999 to compensate patentees for certain delays caused by the USPTO during the prosecution of a utility or plant patent application. However, PTA applies to applications filed after May 28, 2000. Since US patent 6317838 was filed on April 29, 1998, which is before May 29, 2000, it is not eligible for Patent Term Adjustment.
• Patent Term Extension (PTE): Patent Term Extension (PTE) is available under the Hatch-Waxman Act (35 U.S.C. § 156) for patents on certain human drugs, food or color additives, medical devices, animal drugs, and veterinary biological products. The purpose of PTE is to restore some of the patent term lost while awaiting premarket government approval from a regulatory agency, primarily the FDA. There is no indication within the patent text or general patent information that US patent 6317838, which concerns a "Method and architecture to provide a secured remote access to private resources," relates to these specific types of products. Therefore, it is highly unlikely to have received or been eligible for a Patent Term Extension.

Continuation and Divisional Applications

The provided patent text and readily available public information do not explicitly list any continuation or divisional applications directly linked to US patent 6317838.

• A continuation application allows an applicant to pursue additional claims based on the same disclosure as an earlier "parent" application, provided it is filed before the parent application issues or is abandoned.
• A divisional application is filed when an initial patent application contains claims to more than one invention, and the USPTO requires the applicant to restrict the claims to one invention. The other inventions can then be pursued in divisional applications.

Without specific information from the patent's file wrapper or a detailed family search in the USPTO database, we cannot confirm the existence of any continuation or divisional applications.

Related Family Members

The patent text refers to US09/067,961 as the application number for US6317838. This indicates that US6317838 is the patent granted from application US09/067,961. This is the primary family member directly associated with the patent number. No other related patent family members (e.g., continuations-in-part, foreign equivalents beyond the priority claim) are explicitly detailed in the provided information.

Projected Expiration Date

The legal status of US patent 6317838 is listed as "Expired - Lifetime," with an anticipated expiration date of April 29, 2018. [cite: The provided patent text] This date is 20 years from its filing date (April 29, 1998), which is the standard patent term for utility patents filed on or after June 8, 1995. As the patent was not eligible for PTA and there is no indication of PTE, this expiration date is accurate. The patent has already expired.

Defensive Disclosure: Derivative Variations of US Patent 6317838

This document outlines derivative variations of the inventions described in US patent 6317838, "Method and architecture to provide a secured remote access to private resources." The objective is to proactively disclose these conceptual improvements and alternative implementations as prior art, thereby rendering future incremental advancements by competitors obvious or lacking novelty. The current date is April 26, 2026.

---

Derivative Variations

1. Material & Component Substitution: FPGA-Accelerated Centralized Security with Quantum-Resistant Cryptography

Enabling Description:
This derivative implements the centralized security means (5) within the firewall (2) using Field-Programmable Gate Array (FPGA) logic for hardware-accelerated authentication and filtering. Instead of a general-purpose CPU, critical security functions, such as cryptographic operations for user authentication data and the comparison of received security data with stored authentication data (Claim 1b, first stage), are offloaded to dedicated FPGA fabric. The security storing means (DB S) utilizes a distributed, immutable ledger (e.g., based on a quantum-resistant cryptographic algorithm like Dilithium or CRYSTALS-Kyber) for storing security profiles and user authentication data, ensuring data integrity and resistance to future cryptanalytic advances. Network proxies (7a-7p) are implemented as FPGA-accelerated network function virtualization (NFV) instances, optimizing throughput and reducing latency for high-volume authenticated sessions. The security data itself, including user's authentication data and security profiles (Claim 1a), is encrypted using these quantum-resistant algorithms before storage and during transmission within the secure perimeter.

graph TD
    A[Remote User's Workstation] -- Authenticated Request (Quantum-Resistant Encrypted OTP/Login) --> B(Firewall)
    B -- Ingress Filter (IP, Port) --> C{FPGA-Accelerated Centralized Security Means}
    C -- Decrypt/Authenticate (Quantum-Resistant Crypto Hardware) --> D[Security Storing Means (Distributed Immutable Ledger)]
    D -- Retrieve Security Profile --> C
    C -- Enforce Rules (FPGA Logic) --> E[FPGA-Accelerated Proxy (NFV)]
    E -- Forward Secure Session --> F[Private Resource (S1-Sm)]
    D -- Store Audit Log (Immutable) --> G[Audit & Monitoring System]

2. Operational Parameter Expansion: Nanoscale Microservice Access Control

Enabling Description:
This derivative extends the method and architecture to secure access to individual microservices or "nanoresources" within a highly distributed, fine-grained computing environment, operating at a logical "nanoscale" of resource access. The "private resources" (Claim 1a, Claim 8) are now individual API endpoints or functions exposed by microservices. The centralized security means (5) in the firewall (2) performs context-aware micro-authorization for each API call or function invocation. Security profiles (Claim 1a) are defined not just per user or server, but per user-to-microservice-function matrix, indicating granular permissions (e.g., User A can 'read' /api/order/123, but not 'update'). This system is designed to handle millions of simultaneous, short-lived micro-access requests with sub-millisecond latency. The "security data associated with said private resources" (Claim 1a) now includes specific API endpoint paths and method permissions (GET, POST, PUT, DELETE) for each microservice. The firewall’s centralized security means integrates with an API Gateway that intercepts all internal microservice traffic for granular policy enforcement.

graph TD
    A[Remote User] --> B(API Gateway/Firewall)
    B -- API Request (/order/123, Method: GET) --> C{Centralized Security Means}
    C -- Authenticate User (Claim 1b) --> D[Security Storing Means (Micro-Authorization Profiles)]
    D -- Retrieve Fine-Grained Profile (User X, Microservice Y, Function Z) --> C
    C -- Contextual Policy Enforcement --> E{Microservice Router}
    E -- Authorized API Call --> F[Microservice Instance 1 (Order Service)]
    E -- Unauthorized API Call --> G[Access Denied]

3. Cross-Domain Application: Agricultural Equipment Fleet Management

Enabling Description:
Applying the method and architecture of US6317838 to precision agriculture, a remote farmer (user) gains secured access to private resources comprising a fleet of autonomous agricultural equipment (tractors, harvesters, drones) and associated farm management software (e.g., yield mapping, irrigation control systems). The digital data processing system is the farm's central control network. The firewall is a ruggedized industrial gateway installed at the edge of the farm network, protecting the equipment and software from external threats. The centralized security means within this gateway authenticates the farmer and provides a security profile (Claim 1a) that details which specific equipment (e.g., Tractor #3), which control functions (e.g., 'start engine', 'adjust irrigation flow'), and which software applications (e.g., 'view drone telemetry') the farmer may access with a single sign-on. One-time passwords (Claim 7) are generated by a ruggedized handheld device carried by the farmer, or an authenticated farm management tablet, for initial login.

flowchart LR
    A[Remote Farmer (Tablet/PC)] -- Initial Login (OTP) --> B(Industrial Farm Gateway/Firewall)
    B -- Authenticate User --> C{Centralized Security Module}
    C -- Access Control Policy & SSO Data --> D[Farm Security DB (Profiles, Permissions)]
    D -- Security Profile --> C
    C -- Authorized Access --> E[Farm Management Software Suite]
    subgraph Farm Network
        E -- SSO Access --> F[Autonomous Tractor #1 (Resource)]
        E -- SSO Access --> G[Irrigation Control System (Resource)]
        E -- SSO Access --> H[Agricultural Drone (Resource)]
    end
    B -- Telemetry/Control --> E

4. Cross-Domain Application: Deep-Space Satellite Constellation Management

Enabling Description:
In this derivative, the invention secures remote access for mission control engineers (users) to private resources comprising individual satellites and their onboard systems within a deep-space constellation. The "digital data processing system" is the satellite ground station network, with each satellite acting as a "private resource." The "firewall" is implemented as a specialized space-ground communication gateway, designed to handle extreme latency and intermittent connectivity inherent in deep-space links. The "centralized security means" is housed within this gateway, authenticating mission control personnel and providing a security profile (Claim 1a) for SSO access to various satellite subsystems (e.g., propulsion, payload, telemetry, attitude control). One-time passwords (Claim 7), potentially derived from a combination of time and satellite ephemeris data, are used for initial authentication. This system prioritizes secure command execution and telemetry retrieval over highly unreliable channels, maintaining session state despite prolonged communication outages.

sequenceDiagram
    participant M as Mission Control Engineer
    participant G as Ground Station Gateway/Firewall
    participant S as Satellite 1 (Private Resource)
    participant P as Satellite 2 (Private Resource)

    M->>G: Initial Login Request (OTP + Engineer ID)
    G->>G: Authenticate User (Centralized Security Means)
    G->>G: Fetch Security Profile (Engineer Access Rights)
    G-->>M: Authentication Success (SSO Token for Session)
    M->>G: Command Satellite 1 (SSO Token)
    G->>G: Filter/Authorize (Security Profile Check)
    G->>S: Secure Command Link
    S-->>G: Telemetry Data
    G-->>M: Forward Telemetry
    M->>G: Access Satellite 2 (SSO Token)
    G->>G: Filter/Authorize
    G->>P: Secure Command Link

5. Cross-Domain Application: Smart Home/Building Management (Pro-Consumer)

Enabling Description:
This derivative applies the patent to pro-consumer smart home or building management. The "remote user" is the homeowner or building manager, accessing "private resources" like intelligent HVAC systems, advanced security cameras, access control systems, and smart appliance networks. The "digital data processing system" is the local smart home/building server (e.g., a home automation hub). The "firewall" is a residential/commercial IoT gateway device, enforcing perimeter security. The "centralized security means" within this gateway authenticates the user and retrieves a security profile (Claim 1a) that grants SSO access to various smart devices and control panels (e.g., adjust thermostat, view camera feed, unlock door, manage energy usage data). Protocols (Claim 4) include Zigbee, Z-Wave, and Matter, with an authentication layer implemented over them. The system allows a single login to manage a diverse array of smart objects within the physical space.

graph TD
    A[Remote User Device (Phone/Tablet)] -- Authenticated Request (Login/Password) --> B(IoT Gateway/Firewall)
    B -- User Auth --> C{Centralized Security Module}
    C -- Retrieve User Profile --> D[Home Security Database]
    D -- Security Profile --> C
    C -- Authorized SSO Access --> E[Smart Home Hub]
    subgraph Smart Home Network
        E -- Control/Access --> F[HVAC System]
        E -- Control/Access --> G[Security Cameras]
        E -- Control/Access --> H[Door Locks]
        E -- Control/Access --> I[Smart Appliances]
    end
    B -- Encrypted Tunnel --> E

6. Integration with Emerging Tech: AI-Driven Adaptive Security Profiles

Enabling Description:
This derivative integrates AI into the centralized security means (5) and security storing means (DB S) of US6317838. The security profiles (Claim 1a) are no longer static but dynamically adapted by an AI engine based on continuous monitoring of user behavior, network conditions, and threat intelligence. The AI engine, a deep neural network trained on historical access patterns and security events, constantly analyzes the remote user's (U X) behavior (e.g., access times, resource types, data volumes, geolocation) against their baseline profile. If an anomaly is detected, the AI automatically triggers an adjustment of the user's security profile in real-time. This could involve reducing access privileges (e.g., limiting read-only access), enforcing additional multi-factor authentication for sensitive resources, or temporarily blocking access until re-verification. The "rules derived from said security data" (Claim 1b) are thus fluid, reflecting an adaptive security posture.

stateDiagram-v2
    state "Remote User Access" as UserAccess
    state "Firewall Centralized Security Means" as FirewallSecurity
    state "Security Storing Means (AI-Managed Profiles)" as AIManagedProfiles
    state "AI Behavioral Analysis" as AIAnalysis
    state "Private Resources" as Resources

    UserAccess --> FirewallSecurity: Authenticated Session Request
    FirewallSecurity --> AIManagedProfiles: Retrieve Baseline Profile
    AIManagedProfiles --> FirewallSecurity: Baseline Profile
    FirewallSecurity --> Resources: Grant Initial Access
    FirewallSecurity --> AIAnalysis: Stream Access Telemetry
    AIAnalysis --> AIAnalysis: Detect Anomalies (ML Model)
    AIAnalysis --> AIManagedProfiles: Update Profile (Adaptive)
    AIManagedProfiles --> FirewallSecurity: Push New Profile
    FirewallSecurity --> Resources: Adjust Access (Dynamically)
    AIAnalysis --> FirewallSecurity: Alert/Action (e.g., Re-auth)
    FirewallSecurity --> UserAccess: Challenge/Revoke

7. Integration with Emerging Tech: IoT Sensor-Enhanced Contextual SSO

Enabling Description:
This derivative enhances the Single Sign-On (SSO) mechanism (Claim 2, Claim 6) and the authentication process (Claim 1b) by integrating real-time contextual data from Internet of Things (IoT) sensors. The "security data" (Claim 1a) and security profiles are augmented with environmental, biometric, or location-based context. For example, remote users accessing the system from a known, physically secure location (verified by local IoT presence sensors and geo-fencing) might receive broader SSO access or require less frequent re-authentication. Conversely, access from an unknown device or location, or if local environmental sensors detect unusual conditions (e.g., unauthorized physical intrusion near a server), could automatically trigger a re-authentication prompt, elevate authentication requirements (e.g., enforce biometric verification via a wearable IoT device), or restrict access entirely. The firewall's centralized security means (5) actively subscribes to a secure IoT message broker for these real-time contextual inputs to enrich its decision-making.

flowchart TD
    A[Remote User Device] -- Authenticate (Claim 1b) --> B(Firewall/Centralized Security)
    B -- Retrieve Security Profile --> C[Security DB]
    subgraph IoT Context Layer
        D[IoT Gateway] -- Sensor Data (Location, Environment, Biometrics) --> E(IoT Message Broker)
        E -- Real-time Context --> B
    end
    B -- Contextual Policy Decision --> F{SSO Token}
    F -- SSO Access (Claim 2) --> G[Private Resource 1]
    F -- SSO Access --> H[Private Resource 2]
    B -- Adaptive Auth Request --> A

8. Integration with Emerging Tech: Blockchain-Verified Access Credentials and Profiles

Enabling Description:
This derivative leverages blockchain technology for tamper-proof storage and verification of user authentication data and security profiles (Claim 1a). The "security storing means" (Claim 1a, Claim 8) is implemented as a distributed ledger (blockchain) where user identities, public keys, and authorization profiles are recorded as immutable transactions. When a remote user (U X) attempts to authenticate, the centralized security means (5) in the firewall (2) verifies the user's cryptographic signature against their public key stored on the blockchain. Furthermore, changes to security profiles or user privileges are recorded as new blocks, providing an auditable, transparent history. The firewall fetches the latest, cryptographically verified security profile from the blockchain, ensuring that no unauthorized modifications have occurred. This decentralizes trust and dramatically increases the integrity of the authorization system. One-time passwords (Claim 7) can be derived using seed values or challenges issued and recorded via the blockchain.

sequenceDiagram
    participant U as Remote User
    participant FW as Firewall/Centralized Security
    participant BC as Blockchain (Security Data Ledger)
    participant PR as Private Resource

    U->>FW: Authentication Request (Signed by User's Private Key)
    FW->>BC: Verify User Public Key & Latest Profile Hash
    BC-->>FW: User's Valid Public Key & Current Profile Hash
    FW->>FW: Authenticate User (Claim 1b)
    FW->>BC: Retrieve Full Security Profile (Validated)
    BC-->>FW: Immutable Security Profile
    FW->>FW: Filter Access Request (Claim 1b)
    FW->>PR: Provide Security Data (SSO Token for Session)
    PR-->>FW: Acknowledge Access
    FW->>BC: Record Access Event (Transaction)

9. The "Inverse" or Failure Mode: Graceful Degradation to "Read-Only Emergency Access"

Enabling Description:
This derivative implements a graceful degradation mechanism for the method (Claim 1) and architecture (Claim 8) in the event of a detected security breach, system overload, or critical component failure. The "centralized security means" (5) continuously monitors system health and integrity. Upon detecting a predefined critical event, it automatically transitions to a "read-only emergency access" mode. In this mode, all write, modification, or control operations to private resources (S1-Sm) are immediately blocked. Remote user sessions are automatically re-assigned a pre-configured, severely restricted "emergency profile" (Claim 1a) that only permits read-only access to a limited set of diagnostic or reporting resources. Furthermore, any existing Single Sign-On (SSO) sessions are immediately invalidated, and all subsequent access attempts, even for read-only resources, require re-authentication with mandatory multi-factor authentication, overriding the typical SSO convenience. This ensures minimal operational disruption while preventing further damage during a security incident.

stateDiagram-v2
    state "Normal Operation" as Normal
    state "Emergency Mode (Read-Only)" as Emergency

    Normal --> Emergency: Detected Security Breach / Overload
    Emergency --> Normal: System Recovery / Threat Mitigated

    Normal --> FirewallSecurity: Full Access (SSO Active)
    FirewallSecurity --> Resources: R/W Access Granted

    Emergency --> FirewallSecurity: Restricted Access (SSO Invalidated, MFA Enforced)
    FirewallSecurity --> Resources: Read-Only Access Only (Limited Subset)

    state FirewallSecurity {
        state "Authentication Module" as Auth
        state "Filtering Module" as Filter
        state "Profile Manager" as Profile
        Auth --> Filter: Authenticated User
        Filter --> Profile: Access Policy
        Profile --> Auth: Auth Challenge
    }

10. The "Inverse" or Failure Mode: Low-Power Standby with Minimal Authentication Services

Enabling Description:
This derivative outlines an "energy-saving" or "low-power standby" mode for the network architecture (Claim 8), particularly the firewall (2) and its "centralized security means" (5), for scenarios where remote access demand is minimal or non-existent (e.g., off-peak hours, remote site hibernation). In this mode, the main processing units of the firewall and the security server (S S) enter a low-power state, reducing energy consumption significantly. However, a minimal, always-on "wake-up authentication" module (a subset of the centralized security means) remains active. This module can perform basic authentication (Claim 1b, first stage) using a pre-configured, highly secure method (e.g., a specific OTP or a hardware-token-based challenge) to determine if a full system wake-up is required. Only upon successful authentication by this minimal module would the primary components of the firewall and security server transition back to full operational power, retrieving comprehensive security profiles (Claim 1b, second stage) and enabling full SSO functionality (Claim 2). All non-essential network interfaces and proxies (7a-7p) remain in a dormant state during low-power mode.

stateDiagram-v2
    state "Full Power Mode" as FullPower
    state "Low-Power Standby Mode" as LowPower

    FullPower --> LowPower: Low Activity / Scheduled Downtime
    LowPower --> FullPower: Wake-Up Authenticated Request

    LowPower: Minimal Authentication Module Active
    LowPower: Most Components Dormant
    LowPower --> WakeupAuth: Receive Request
    WakeupAuth --> FullPower: Authenticated Wake-Up

    FullPower: All Modules Active
    FullPower: Full SSO Functionality

    state WakeupAuth {
        state "Receive Initial OTP/Challenge" as Recv
        state "Verify Minimal Credential" as Verify
        state Recv --> Verify: Check OTP
        Verify --> WakeupAuth: Success/Fail
    }

---

Combination Prior Art Scenarios with Open-Source Standards

These scenarios describe combinations of US patent 6317838's core concepts with widely adopted open-source standards, demonstrating how the patented elements, or their obvious derivatives, would integrate with or be superseded by common industry practices.

1. Centralized Firewall Security with OpenID Connect for Federated SSO

• Open-Source Standard: OpenID Connect (OIDC) - an authentication layer on top of the OAuth 2.0 framework.
• Combination: A PHOSITA would combine the "centralized security means" (Claim 1b, 8) within the firewall (2) of US6317838 with OpenID Connect to enable federated Single Sign-On (SSO) for remote users. Instead of managing all user authentication data internally, the firewall would act as an OAuth 2.0 Client/Relying Party, delegating primary authentication to an external OpenID Provider (IdP) (e.g., Google, Microsoft Entra ID, or a corporate IdP using Keycloak). Upon successful authentication by the IdP, the firewall's centralized security means would receive an ID Token and potentially an Access Token. It would then use the information within the ID Token (e.g., user ID, roles) to fetch the appropriate "security profile" (Claim 1a, 8) from its internal "security storing means" (Claim 1a, 8) and enforce granular access rules to private resources. This approach leverages an established, secure, and widely implemented open standard for identity verification while retaining the centralized access control and filtering logic of the patent.

2. Firewall-Integrated SSO and OTP with FreeRADIUS and OpenLDAP

• Open-Source Standard: FreeRADIUS (open-source RADIUS server) and OpenLDAP (open-source LDAP directory service).
• Combination: A PHOSITA would integrate the "centralized security means" (Claim 1b, 8) and "security storing means" (Claim 1a, 8) of US6317838 with FreeRADIUS and OpenLDAP. The firewall's centralized security means would send authentication requests to a FreeRADIUS server, which, in turn, would authenticate users against an OpenLDAP directory storing "user's authentication data" (Claim 1a, 8) and potentially "security profiles" (Claim 1a, 8) or references to them. One-time passwords (Claim 7, 14) could be implemented by having the FreeRADIUS server integrate with a backend OTP generation mechanism (e.g., using OATH-TOTP/HOTP algorithms supported by many open-source implementations). The RADIUS server would also manage the "security profiles" (Claim 1a, 8) for users, dictating which private resources they can access, and relaying this authorization information back to the firewall for enforcement. This provides a robust, standardized, and centralized authentication, authorization, and accounting (AAA) framework that inherently supports SSO-like behavior for authorized sessions.

3. Secure Remote Access with OpenVPN and Netfilter/iptables for Application-Layer Filtering

• Open-Source Standard: OpenVPN (open-source VPN solution for secure tunneling) and Netfilter/iptables (Linux kernel firewall, for packet filtering and Network Address Translation).
• Combination: A PHOSITA would implement the "secured remote access" (Claim 1) and "firewall" (2) functionality of US6317838 using OpenVPN for establishing secure "data pipes" (VPN tunnels) and Netfilter/iptables for the "first set of filtering rules" (IP addresses filtering, module 20 in FIG. 2) and the "applicative services rules" (module 50 in FIG. 2). Remote users would first connect via an OpenVPN client, authenticating against a backend system (e.g., using client certificates, username/password, or even OTPs). Once the secure VPN tunnel is established, the "centralized security means" (Claim 1b, 8), potentially implemented as a daemon interacting with iptables rules, would perform "application-layer filtering" (e.g., Layer 7 inspection via Netfilter modules like l7-filter or conntrack) to enforce the "security profiles" (Claim 1a, 8) that permit or deny access to specific "private resources" (S1-Sm) or "Internet application protocols having a notion of authentication" (Claim 4) running within the trusted network. This combination leverages established open-source tools to provide both secure transport and granular application-level access control.