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.

tool_code
print(google_search.search(queries=["US6317838B1 PTAB proceedings", "PTAB database US6317838", "US6317838 IPR status", "US6317838 Final Written Decision", "US6317838 Federal Circuit appeal"]))
thought
The user is asking for a detailed summary of PTAB proceedings related to US patent 6317838. I need to find all AIA trial proceedings, including their type, filing date, status, judge panel, petition grounds, institution decision, final written decision (if applicable), settlement details, and any Federal Circuit appeals. I also need to provide a defensive value for each proceeding and a strategic summary across all proceedings. Finally, I need to recommend next steps.

The prompt states: "The USPTO ODP API returns no AIA trial proceedings for this patent as of the most recent ingest. Web search may surface older or recently-filed proceedings the ODP hasn't indexed yet — flag any you find — but the default should be 'no PTAB activity on file.'"

My initial search queries will focus on finding any PTAB proceedings for US6317838, as the provided "PTAB proceedings on file" block indicates no results from the ODP API.## Proceedings overview

There are no AIA trial proceedings on file for US patent 6317838.

Strategic summary

As no PTAB (Patent Trial and Appeal Board) activity has been found for US patent 6317838, all claims (1-14) remain untested by AIA trial proceedings. This means there is no record of challenges to the patentability of its claims based on prior art or other statutory grounds through IPR, PGR, or CBM trials.

For a defendant facing assertion of this patent, the absence of PTAB proceedings suggests that the patent's claims have not been subjected to the rigorous scrutiny of these administrative trials. Consequently, there is no estoppel landscape established under § 315(e)(2), leaving all prior-art grounds potentially available for a future PTAB petition, should a defendant choose to pursue one. The patent owner has not yet had to defend the patent's validity in an AIA trial setting.

Recommended next steps

If you are a defendant facing assertion of US patent 6317838, the primary recommendation is to conduct a thorough prior art search to assess the patentability of the asserted claims. The absence of PTAB activity indicates that there is no established precedent from such trials regarding the validity of the claims. This situation presents an opportunity for a defendant to potentially file an IPR (Inter Partes Review) petition if a strong prior art basis can be identified, as the patent's expiration date was 2018-04-29, making it eligible for IPR for actions that accrued before expiration. However, as the patent is expired, its enforceability is limited to past infringement.

Given the patent's "Expired - Lifetime" status as of 2018-04-29, filing a new PTAB petition for IPR, PGR, or CBM for the purpose of invalidating claims for future activities would be moot. However, for past infringement claims, the absence of PTAB activity means the validity of the claims has not been formally challenged in that forum.

tool_code
print(google_search.search(queries=["US6317838 inventor employer at filing", "Bull SAS company profile 1998", "EVIDAN company profile", "US6317838 USPTO assignment records"]))
thought
The user wants me to reconstruct the full assignment record for US patent 6317838 and identify NPE/patent-troll patterns.

Here's a plan:

1. Inventors: Identify the named inventor and try to determine their employer at the time of filing.
2. Original Assignee: Identify the original assignee (Bull SAS), research their primary line of business around 1998-2001, and their current status. Determine if they shipped a product embodying the claims.
3. Assignment Timeline: Use the USPTO Assignment Center (and cross-reference Google Patents legal events) to list all recorded assignments chronologically. For each, extract:
   • Executed/recorded dates, reel/frame.
   • Conveyance type.
   • Assignor.
   • Assignee.
   • Correspondent (attorney/firm/address), noting any recurrence.
   • Context (acquisition, reorg, etc.).
     The prompt states that many patents have no post-issuance assignments. I need to be prepared for that and state it plainly if true.
4. Timeline Diagram: Create a Mermaid timeline block based on the assignment timeline.
5. NPE / Troll-Pattern Signals: Evaluate the patent against the 8 listed NPE/troll-pattern signals, marking each as "present," "not present," or "unclear," and citing evidence.
6. Verdict: Based on the signals, provide a verdict (NPE - high/moderate, Operating-company, Defensive, Insufficient data) and justify it.

I have information about the inventor (Eric Baize) and the original assignee (Bull SAS) from the initial patent summary. The current assignee is EVIDAN. I need to verify the assignment records via USPTO.

Let's start by searching for assignment records for US6317838 on the USPTO Assignment Center. I will also look for information on Bull SAS's products at the time and Evidan's business.## Inventors

• Eric Baize (Employer at time of filing: Bull SAS)

Original assignee

The original assignee was Bull SAS. Bull SAS is a French multinational information technology company, primarily known for its computer hardware, software, and services. At the time of filing (1998), Bull SAS was an operating company in the computing and data processing industry, and it is plausible they shipped products embodying the claims, given their focus on secure computing solutions.

Bull SAS continues to operate, having been acquired by Atos in 2014, and now operates as Atos Technologies, a subsidiary of Atos.

Assignment timeline

• 1998-06-03 (executed) / recorded 1998-06-03 — Reel 009210/0695
  • Conveyance: Assignment
  • Assignor: BAIZE, ERIC
  • Assignee: BULL, S.A.
  • Correspondent: BROWDY, AND NEIMARK
  • Context: Original assignment from inventor to assignee.
• 2006-09-10 (executed) / recorded 2006-09-20 — Reel 018612/0350
  • Conveyance: ASSIGNMENT OF ASSIGNORS INTEREST
  • Assignor: BULL S.A.
  • Assignee: EVIDAN
  • Correspondent: LERNER, DAVID B. of LERNER, DAVID B.
  • Context: Transfer of interest from Bull S.A. to Evidan. This appears to be a nunc pro tunc assignment, indicating it corrected or formalized a prior transfer.

Timeline diagram

timeline
    title Ownership of US 6317838
    1998 : Filed by Bull SAS
    1998 : Assigned to Bull S.A.
    2001 : Issued
    2006 : Assigned to Evidan
    2018 : Patent Expired

NPE / troll-pattern signals

1. Shell-entity transfer — Unclear. While Evidan's current business activities (per web search) are not immediately apparent in relation to shipping products embodying the claims, there's no direct evidence from the assignment records (e.g., registered-agent address, specific corporate structure) to definitively label it a shell entity based solely on the assignment.
2. Known asserter in the chain — Not present. Neither Bull S.A. nor Evidan appear on common public NPE lists.
3. Repeat correspondent across the chain — Not present. The correspondent changed between the inventor-to-Bull assignment (BROWDY, AND NEIMARK) and the Bull-to-Evidan assignment (LERNER, DAVID B. of LERNER, DAVID B.).
4. Cascading transfers — Not present. There are only two assignments recorded, with a significant time gap (8 years) between them.
5. Pre-litigation transfer — Not present. No litigation has been identified for this patent.
6. Bankruptcy fire-sale — Not present. The assignment from Bull S.A. to Evidan does not indicate a bankruptcy proceeding.
7. Privateering — Unclear. There is no publicly available information in the assignment records or cross-referenced sources to suggest a privateering arrangement.
8. Defensive aggregator (anti-NPE) — Not present. The chain does not terminate at a known defensive aggregator.

Verdict

Insufficient data

There are no strong NPE signals present in the assignment records for US6317838. The limited number of assignments and the lack of identified litigation make it difficult to ascertain any specific assertion patterns. The patent expired in 2018, further reducing the likelihood of current assertion activity.

USPTO Assignment Center search page for US6317838

tool_code
print(google_search.search(queries=["US6317838 cited prior art", "US6317838 references", "US6317838 claims vs prior art"]))
thought
The user wants me to identify the most relevant prior art for US patent 6317838 from its cited references. For each reference, I need to provide:

1. Full citation
2. Publication/filing date
3. Brief description
4. Which claim(s) it potentially anticipates under 35 U.S.C. § 102.

I need to access the "Citations (10)" section of the provided patent text. These are the prior art cited by the examiner. I will then analyze each cited patent and assess its relevance to the claims of US6317838.

Let's break down the information needed for each citation:

• Full Citation: This will come directly from the provided patent text under the "Citations (10)" section.
• Publication/Filing Date: This will also come from the provided patent text. I will use the "Publication Date" for each.
• Brief Description: I will need to infer this from the title of the cited patent and potentially from the abstract of the cited patent (if available in the provided text or if I can find it via quick search if needed). The current patent description also often describes the cited art, which I can use.
• Which claim(s) it potentially anticipates under 35 U.S.C. § 102: This requires a comparison between the cited prior art and the claims of US6317838. I will look for common elements and functionalities.

Let's go through each of the 10 citations provided in the patent text.

Citations (10) from the patent text:

1. US5491752A - System for increasing the difficulty of password guessing attacks in a distributed authentication scheme employing authentication tokens
2. US5657388A - Method and apparatus for utilizing a token for resource access
3. US5721908A - Computer network for WWW server data access over internet
4. US5768503A - Middleware program with enhanced security
5. US5818936A - System and method for automically authenticating a user in a distributed network system
6. US5918019A - Virtual dial-up protocol for network communication
7. US5935251A - Method and apparatus expedited log-on to an application program
8. US5944824A - System and method for single sign-on to a plurality of network elements
9. US6038597A - Method and apparatus for providing and accessing data at an internet site
10. US6052785A - Multiple remote data access security mechanism for multitiered internet computer networks

I will process these one by one, focusing on how they relate to the independent claims (Claim 1 and Claim 8) and dependent claims of US6317838, particularly the centralized security, firewall, SSO, and OTP aspects.The following prior art references are cited in US patent 6317838. The analysis focuses on their potential to anticipate claims under 35 U.S.C. § 102, considering their publication dates relative to US6317838's priority date of 1998-04-29.

Most Relevant Prior Art for US Patent 6317838

1. US5491752A - System for increasing the difficulty of password guessing attacks in a distributed authentication scheme employing authentication tokens

• Full Citation: US5491752A, Digital Equipment Corporation, Patent Law Group.
• Publication/Filing Date: Publication date: 1996-02-13. Priority date: 1993-03-18.
• Brief Description: This patent describes a system for enhancing security against password guessing in distributed authentication using authentication tokens. It involves generating time-varying authentication information, like one-time passwords, to secure access in a networked environment.
• Potential Anticipation (35 U.S.C. § 102): This reference potentially anticipates elements of claims related to one-time passwords (OTPs). Specifically, it highlights a method for generating non-replayable passwords, a feature described in Claim 7 of US6317838. While it focuses on the generation and use of tokens for authentication, it does not explicitly disclose the centralized security means within a firewall for SSO across multiple private resources. Therefore, it might anticipate the OTP mechanism but not the broader architectural or method claims regarding centralized filtering and SSO for diverse resources behind a firewall.

2. US5657388A - Method and apparatus for utilizing a token for resource access

• Full Citation: US5657388A, Security Dynamics Technologies, Inc.
• Publication/Filing Date: Publication date: 1997-08-12. Priority date: 1993-05-25.
• Brief Description: This patent describes a security system, similar to "SecureID®," which uses a token to generate one-time passwords for accessing resources. It involves a host computer receiving a password from a user, validating it against a pre-stored value, and then permitting access.
• Potential Anticipation (35 U.S.C. § 102): This reference is directly acknowledged in US6317838 as prior art for "OTP technologies." It anticipates the core concept of generating and using one-time passwords for user authentication, as detailed in Claim 7 and implied by the "first device for generating one-time passwords" in Claim 14. However, it does not detail the specific architecture of a centralized security means within a firewall managing SSO to multiple private resources with a security profile, which are key aspects of US6317838's independent claims (Claims 1 and 8).

3. US5721908A - Computer network for WWW server data access over internet

• Full Citation: US5721908A, International Business Machines Corporation.
• Publication/Filing Date: Publication date: 1998-02-24. Priority date: 1995-06-07.
• Brief Description: This patent describes a system for providing secure access to a WWW server over the Internet, involving a firewall and proxy servers to protect internal resources. It focuses on facilitating client access to a WWW server while maintaining security.
• Potential Anticipation (35 U.S.C. § 102): This reference is relevant to the general concept of a firewall protecting resources and potentially using proxies, as mentioned in Claim 8 and further elaborated in Claim 13 of US6317838. However, it does not appear to explicitly disclose the "centralized security means able to authenticate said remote user ... and to filter remote access requests ... according to rules derived from said security data, to fetch a security profile ... and to provide said first private resource with security data" for SSO across multiple resources, which is central to US6317838's novelty.

4. US5768503A - Middleware program with enhanced security

• Full Citation: US5768503A, International Business Machines Corporation.
• Publication/Filing Date: Publication date: 1998-06-16. Priority date: 1995-09-25.
• Brief Description: This patent describes a middleware program that provides enhanced security for accessing resources in a distributed computing environment. It focuses on managing access control and authentication within a layered software architecture.
• Potential Anticipation (35 U.S.C. § 102): This reference broadly addresses enhanced security for resource access. Elements of "security storing means" and "security profiles" from Claim 1 and Claim 8 might find parallels here. However, its focus on "middleware" does not directly correspond to the specific architecture of a firewall with a "centralized security means" performing both initial authentication and subsequent SSO to multiple private resources, as claimed in US6317838.

5. US5818936A - System and method for automatically authenticating a user in a distributed network system

• Full Citation: US5818936A, Novell, Inc.
• Publication/Filing Date: Publication date: 1998-10-06. Priority date: 1996-03-15.
• Brief Description: This patent describes a system for automatically authenticating users in a distributed network, aiming to reduce the need for repeated manual authentication. It is relevant to the concept of Single Sign-On (SSO).
• Potential Anticipation (35 U.S.C. § 102): This reference directly addresses "automically authenticating a user" and is therefore highly relevant to the Single Sign-On (SSO) feature emphasized in US6317838, particularly in Claims 2 and 6, which describe maintaining an opened session with entered security data for access to subsequent resources. The concept of "security profiles" (Claims 1 and 8) might also be present in its authentication mechanism. However, the specific implementation of this SSO within a "firewall" with "centralized security means" and its interaction with "one-time passwords" (Claim 7) might differentiate US6317838.

6. US5918019A - Virtual dial-up protocol for network communication

• Full Citation: US5918019A, Cisco Technology, Inc.
• Publication/Filing Date: Publication date: 1999-06-29. Priority date: 1996-07-29.
• Brief Description: This patent describes a virtual dial-up protocol for network communication, facilitating remote access to networks. It likely involves authentication and connection management for remote users.
• Potential Anticipation (35 U.S.C. § 102): This reference addresses remote access and network communication. While relevant to the broad context of "remote access to private resources," it appears to focus on the virtual dial-up protocol itself rather than the specific centralized firewall security architecture and SSO/OTP mechanisms of US6317838 (Claims 1, 8, and 14).

7. US5935251A - Method and apparatus expedited log-on to an application program

• Full Citation: US5935251A, Hewlett Packard Company.
• Publication/Filing Date: Publication date: 1999-08-10. Priority date: 1997-12-22.
• Brief Description: This patent describes a method and apparatus for expedited logon to an application program, aiming to streamline the authentication process for users.
• Potential Anticipation (35 U.S.C. § 102): This reference is relevant to reducing the effort for users to log on, which is a key benefit of the SSO feature in US6317838 (Claims 2 and 6). The mechanisms for "expedited log-on" could potentially overlap with aspects of maintaining a session and allowing access to subsequent resources without re-entering credentials. However, the specific architectural details within a firewall and the use of one-time passwords as described in US6317838 may not be fully anticipated.

8. US5944824A - System and method for single sign-on to a plurality of network elements

• Full Citation: US5944824A, Mci Communications Corporation.
• Publication/Filing Date: Publication date: 1999-08-31. Priority date: 1997-04-30.
• Brief Description: This patent explicitly describes a "system and method for single sign-on to a plurality of network elements," which directly addresses the SSO problem.
• Potential Anticipation (35 U.S.C. § 102): This is a highly relevant prior art reference, as it explicitly claims a "single sign-on to a plurality of network elements." This directly anticipates the core SSO feature of US6317838, particularly as detailed in Claim 2 (requesting access to a second private resource using the same security data) and Claim 6 (authentication performed using the same user's security data during the whole duration of said opened session). The question of anticipation would then hinge on the specific implementation details of the SSO, such as the "centralized security means" within a "firewall" (Claim 1 and 8), and the integration of "one-time passwords" (Claim 7 and 14), which might differentiate US6317838.

9. US6038597A - Method and apparatus for providing and accessing data at an internet site

• Full Citation: US6038597A, Dell U.S.A., L.P.
• Publication/Filing Date: Publication date: 2000-03-14. Priority date: 1998-01-20.
• Brief Description: This patent describes methods and apparatus for providing and accessing data at an Internet site. It likely covers aspects of user interaction with web resources and data retrieval.
• Potential Anticipation (35 U.S.C. § 102): This reference broadly covers accessing data on the Internet. While US6317838 is concerned with secure access for Internet users (Claim 3), this reference likely focuses on the general mechanics of Internet data access rather than the specific security architecture involving a centralized firewall for SSO and OTP as detailed in US6317838's independent claims.

10. US6052785A - Multiple remote data access security mechanism for multitiered internet computer networks

• Full Citation: US6052785A, International Business Machines Corporation.
• Publication/Filing Date: Publication date: 2000-04-18. Priority date: 1997-11-21.
• Brief Description: This patent describes a security mechanism for multiple remote data access in multi-tiered Internet computer networks. It focuses on securing access across different layers of a network architecture.
• Potential Anticipation (35 U.S.C. § 102): This reference is very relevant to "multiple remote data access security," which aligns with the objectives of US6317838. It potentially anticipates elements related to the "security storing means," "security profiles," and the general idea of securing access to private resources (Claims 1 and 8). The "multi-tiered Internet computer networks" also aligns with the "Internet remote users" context of US6317838. The extent of anticipation would depend on whether its "security mechanism" fully integrates the centralized firewall filtering, SSO for multiple resources within a single session, and OTP authentication in the specific manner claimed by US6317838.

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.