US 7448075

I'll search for authoritative information on this specific patent number and check current litigation dockets.

Let me refine the searches to target this specific patent and any litigation.

Let me do one final targeted check for any appellate or district court activity.

Summary of US Patent 7,448,075

Important caveat up front: I found no CAFC 2026 docket or any federal court litigation involving US 7,448,075 in the searches I ran. I cannot confirm or deny judicial activity beyond what the search returned; treat the litigation query as not answered rather than negative. I also flag one literal-identifier trap: the number 7448075 also appears as a trademark registration number (mark "NINILOVELYACC," Shenzhen Ruixi Technology Co., Ltd., registered July 16, 2024). That is a different register and is not the patent. Per the operating rules I have not conflated or auto-corrected these.

Bibliographic data (from the authoritative patent text)

Abstract

A user terminal issues an access request to an Internet access / IP service provider containing (i) user identification and authentication data for the provider and (ii) user identification and authentication data for the access network / IP transport operator (ANO/ITO). The request is first routed through the operator's access controller to the operator's authentication server. That server authenticates the user from the user's ANO/ITO credentials. The provider's authentication server separately authenticates the user from the provider credentials. A response message containing the authentication results is returned to the user terminal.

Plain-language overview of the independent claims

Claim 1 — Method (dual/parallel authentication during connection setup). The user terminal sends an access request carrying two credential sets: first, Nid (user ID with the access network operator/IP transport network operator, ANO/ITO) plus AUTH; and second, IAPid (user ID with the Internet access provider or IP service provider) plus PW. An "access controller" receives the request, extracts the ANO/ITO credentials and forwards them to the ANO/ITO authentication server, which authenticates on that basis; the access controller also extracts the provider credentials and forwards them to the provider's authentication server, which authenticates on that basis. A response message is then sent back to the terminal (via the access controller) containing the result of the provider-side authentication.
Note: the granted claim text contains a typographical artifact, "the authentication server of the Internet access provider of IP service provider." I report it literally; I do not correct it.

Claim 7 — System. A system for ANO/ITO-side authentication comprising access networks with user terminals, an IP transport network, IP gateways between them, terminal-side means for issuing access requests containing both the ANO/ITO credentials (Nid/AUTH) and the provider credentials (IAPid/...), a per-provider authentication server for the provider credentials, an ANO/ITO authentication server, and an access controller. The access controller has means to receive all access requests, extract the first (ANO/ITO) credential set and send it to the ANO/ITO authentication server, and the ANO/ITO authentication server authenticates on that first set.
Note: claim 7 also contains a literal inconsistency — a "means for extracting … the second user identification and authentication data and for transmitting said data to the authentication server of the access network and IP transport network operator." Read literally, the second (provider) data is routed to the operator's server. I flag this rather than silently fixing it.

Claim 11 — Access controller (apparatus). An access controller as such, comprising means to receive a request containing first (Nid/AUTH) credentials for the ANO/ITO and second (IAPid) credentials for the provider; means to extract the first set and transmit it to the ANO/ITO authentication server; means to extract the second set and transmit it to the provider's AAA authentication server; and means to transmit a response to the terminal containing the provider-side authentication result.

Dependent claims: 2 (insert ANO/ITO authentication result into the response), 3 (insert user profile data on successful ANO/ITO authentication), 4 (authenticate sequentially in either order), 5 (authenticate substantially simultaneously), 6 (define the credential string format IAPid|Nid|AUTH@IAPdomain, PW), 8 (access controller inserts operator authentication result into provider-issued responses), 9 (user database with identification and profile data), 10 (access controller = RADIUS proxy server; authentication server = RADIUS server).

Technical context and grounding

• The patent's stated problem: in the prior art (its FIG. 1), users of the IP transport network are authenticated solely by the IAP/ISP's AAA server using credentials like IAPid@IAPdomain, which the ANO/ITO cannot validate because they live in a different administrative domain; the access/IP transport operator therefore cannot identify users to offer personalized services (mobility, personalization, single multi-access billing).
• Implementation is described via PAP and RADIUS: the terminal's PAP_Authenticate_Request is encapsulated by the IP gateway into a RADIUS Access-Request with UserName="IAPid|Nid|AUTH@IAPdomain" and UserPassword="PW"; the access controller splits out Nid|AUTH and issues a second RADIUS Access-Request (UserName="Nid", UserPassword="AUTH"), while forwarding IAPid/PW to the provider. Diameter is noted as an alternative.
• Cited prior art (11 references) includes EP 1251672 A1 (Microsoft, "authentication through multiple proxy servers"), WO 2002/086718 A1 (iPass, secure authentication of network access credentials), US 6,466,571 B1 (3Com, RADIUS-based mapping), US 6,910,074 B1 (Nortel), and US 7,188,360 B2 (Ericsson, "universal authentication mechanism").

Uncertainty / confidence flags

• High confidence on the bibliographic data, abstract, and claim content — these come directly from the authoritative full patent text supplied to me and are corroborated by the Google Patents and Justia pages returned in search.
• Low/unknown on any 2026 CAFC activity. My searches surfaced unrelated Orange S.A. matters (e.g., a UPC order in Orange v. HMD, UPC_CFI_301/2025, and French proceedings), but nothing tying US 7,448,075 to a CAFC or district court docket. If a specific 2026 docket exists, I did not find it and cannot confirm it.
• The patent's expired/lapsed status (maintenance-fee lapse effective 2020-11-04) means infringement litigation over the patent itself would be unusual at this date, though the Google Patents header simultaneously lists an "adjusted expiration" of 2026-03-30 — a discrepancy I am reporting literally rather than reconciling.
• Legal status is explicitly an assumption per the source's own disclaimer, not a legal conclusion.

I'll search for litigation involving US patent 7448075 across patent litigation databases.

Let me search more specifically across litigation databases.

Let me do a couple more targeted searches to be thorough.

Litigation Search Report: U.S. Patent No. 7,448,075

Patent Identified (interpreted literally)

• Patent number: US 7,448,075 B2
• Title: "Method and a system for authenticating a user at a network access while the user is making a connection to the Internet"
• Application: US 10/771,422
• Priority date: 2003-02-10 (FR 0301566)
• Filing date: 2004-02-03
• Grant date: 2008-11-04
• Original assignee: France Telecom SA; current assignee: Orange SA
• Inventors: Lionel Morand, Frederic Delmond, Estelle Transy, Celine Carpy
• Status: Expired – Fee Related (lapsed 2020-11-04 for failure to pay maintenance fees; adjusted expiration date listed 2026-03-30)

Result: No litigation found

I could not identify any litigation (district court, Federal Circuit, ITC, or PTAB action) involving U.S. Patent No. 7,448,075.

Searches of publicly available patent-litigation information — including the type of records surfaced through the Google Patents "Litigation" and family data for this patent, and general queries against patent-litigation aggregator content (Unified Patents–style case listings, Docket Alarm, and PACER-style dockets) — returned no asserted-case results tied specifically to 7,448,075.

Key corroborating indicators that this patent was not litigated:

1. No litigation field on the patent record. The Google Patents page for US7448075 contains no "Litigation" section listing lawsuits, only patent-family, citation, and legal-status data.
2. No third-party case citations. The "Cited By," "Families Citing," and citation maps reference this patent only as prior art / background art in later patents (e.g., US 8,543,710; US 8,397,282). Being cited as prior art is not evidence of litigation.
3. No IPR/PGR. No inter partes review or post-grant review proceeding appearing against 7,448,075 surfaced in the search.
4. Enforcement history of the family. The related family document US7665129B2 ("Method and system for managing access authorization for a user in a local administrative domain…," also France Telecom/Orange) likewise showed no evidence of litigation in the results.

Required caveats (stated explicitly, per my operating rules)

• Confidence level. I have moderate-to-high, but not absolute, confidence that no litigation exists. The negative result is consistent across the sources I could retrieve, but I could not directly query the Unified Patents litigation portal case list, PACER, or the CAFC docket for this specific number within my search limits. A definitive "no litigation ever filed" conclusion should be verified directly against PACER (all district courts) and the CAFC docket.
• Interpretation note. I interpreted the identifier literally as 7,448,075 only. I did not conflate it with near-numbers that appeared in search results (e.g., 7,448,number variants, 8,543,710, 8,397,282, 7,454,002, 10,476,868, 8,767,824), which belong to different patents and different parties and are not this patent.
• Date context. The patent lapsed for nonpayment of maintenance fees effective 2020-11-04, which is a practical reason it would not be a candidate for recent assertion campaigns.

Summary Table

Bottom line: Based on available public records, there is no known litigation involving US Patent 7,448,075. If you need a court-certified negative, I recommend a direct PACER docket search across all district courts and the Federal Circuit, plus a Unified Patents portal and ITC EDIS check, none of which I was able to complete exhaustively here.

Proceedings overview

Total AIA trial proceedings on file for US 7,448,075: 0 (zero). There is nothing to break down by active / invalidated / sustained / settled / institution-denied — the USPTO Open Data Portal ("PTAB proceedings on file") returns no AIA trials, and my independent web searches surfaced no IPR, PGR, or CBM naming this patent as the challenged patent, and no Federal Circuit appeal from any PTAB decision on it. Defensive posture for a defendant: the patent is PTAB-unbroken but also PTAB-untested — there is no claims-invalidated win to lean on, so your validity challenge would be a first impression, and the more pressing fact is that the patent appears to have lapsed for non-payment of maintenance fees in 2020.

Caveat on the record: Google Patents' header still shows "Expired - Fee Related, expires 2026-03-30," but the Legal Events section records a Lapse for failure to pay maintenance fees (2020-12-07) with Effective date 2020-11-04. Those two statements are inconsistent; I'm reporting both rather than reconciling them, and a defendant should confirm current fee/status in USPTO Patent Center before relying on either.

No proceeding-specific sections are included because no proceeding exists. Per the task constraints, I will not invent proceeding numbers, panels, grounds, or dispositions. What follows explains the absence and what it means.

Strategic summary

Claim status: all claims UNTESTED at the PTAB — none canceled, none sustained. Claims 1–6 (method) and 7–10 (system) plus claim 11 (access controller) have never been the subject of an AIA trial. There is therefore no final written decision to cite, no claim-level invalidation, and no surviving-claim list narrowed by the Board. Any statement that a claim of the '075 patent was "held unpatentable," "canceled," or "confirmed" by the PTAB would be fabricated. The closest family activity — the European counterpart EP 1 445 916 (EP1445916A3, "Withdrawn"), the Chinese CN1523811B, Korean KR101025403B1, and Japanese JP4741193B2, all listed as not active / expired-fee — involves foreign prosecution outcomes, not AIA trials, and cannot be transplanted onto the US claims.

Estoppel landscape: none has attached. Because no petitioner ever reached a final written decision, § 315(e)(2) estoppel is a non-issue for this patent. No party is barred from raising any prior-art ground under § 102 or § 103 in district court or the ITC. The practical corollary: if you are a defendant and want to challenge validity, you are not boxed out of the PTAB by someone else's prior win — but you also get no free ride from a prior petitioner's labor. The cited prior art from prosecution (US6032260, US6108789, US6466571, WO2001045352, US20010037466, US6910074, US6970848, WO2002086718, EP1251672, US20020194334, US7188360 — 11 references) is fully available, and so is any art a reasonable searcher would have found.

Pattern signals: absent. No serial petitioner, no joinder cluster, no Director Review, no defensive aggregator (no Unified Patents, RPX, or similar filing) appears in the record or in search results for this patent. Nor has there been an aggressive patent-owner PTAB-appeal posture, because there was no PTAB decision to appeal. The asserted-prosecution history and the family are consistent with a 2003-era France Télécom / Orange SA portfolio patent that was maintained through the 8-year fee (2016-04-27) and then dropped at the 12-year window.

The real defensive story is expiration, not invalidation. The assignee is Orange SA (originally France Télécom SA), priority 2003-02-10, filed 2004-02-03, granted 2008-11-04. Per the Legal Events, the patent lapsed for failure to pay maintenance fees effective 2020-11-04. If that reading holds, the patent has been unenforceable-by-lapse for roughly six years, capping any damages recovery to pre-lapse infringement (subject to the 35 U.S.C. § 286 six-year lookback) and eliminating injunctive relief. For a defendant receiving a demand letter today, the expiration/lapse posture likely disposes of the case before validity ever matters — which is why the absence of IPRs is not surprising: there was little economic incentive to invalidate a patent that was about to lapse.

Recommended next steps

1. Confirm status in USPTO Patent Center first. Verify whether the 2020-11-04 lapse is effective and whether any petition to revive or fee payment reinstated the patent. If lapsed-and-not-revived, that alone is your lead argument; if revived, the "expires 2026-03-30" header governs and you have a live (if very old) patent. See https://patents.google.com/patent/US7448075/en for the Legal Events, and the USPTO Patent Center record for the authoritative fee/status history.
2. If the patent is live and being asserted, note that you would be the first AIA petitioner. There is no institution decision, no FWD, no appeal, and no estoppel to navigate. Grounds under § 102/§ 103 using the 11 prosecution-cited references or new art are all available. A PGR is unavailable (the patent predates the AIA first-inventor-to-file date and is not PGR-eligible); CBM is unavailable because the patent expired/lapsed and, in any event, CBM sunset on 2020-09-16.
3. If you find a proceeding I could not (e.g., an unindexed or very recently filed petition), treat it as an exception to the "no PTAB activity on file" default and verify it directly on PTAB E2E / the PTAB Decisions database at https://developer.uspto.gov/ptab-api and https://www.uspto.gov/patents/ptab/decisions — do not rely on my search as the last word on a record this old.
4. Do not cite a non-existent FWD. If opposing counsel or a demand letter references a PTAB outcome for the '075 patent, ask for the proceeding number and paper link; on this record there is none.

Bottom line: no PTAB activity on file — the absence is itself the signal here, and it points to a patent that was allowed to lapse rather than one hardened by surviving inter partes review.

I'll research the assignment record for US 7448075, starting with the USPTO Assignment Center and cross-referencing the inventor and ownership data.

Let me dig deeper into the assignment records and the France Telecom → Orange ownership change.

Let me check the USPTO assignment records and third-party assignment databases more specifically for this patent number.

I've gathered enough to reconstruct the ownership chain. Note upfront: only one assignment document is recorded against US 7448075, and I could not retrieve the correspondent-of-record field or directly query the Assignment Center UI (search-tool limits were hit). I flag that limitation explicitly below rather than guess.

Assignment & Ownership Report: U.S. Patent No. 7,448,075

Inventors

• Employer at filing. The assignment document (see below) names France Télécom as assignee and lists all four as assignors "of assignors' interest," which establishes they were France Télécom personnel at the time of filing. The subject matter (RADIUS/AAA access-network authentication) is squarely within France Télécom's network-research activity, consistent with that employer.
• Unusual patterns. No evidence of a pre- or post-filing inventor exodus. I could not determine individual departure dates from France Télécom/Orange; I found no public record tying any of the four to a spin-out, a competing entity, or a later assignment. So the "all inventors left within 12 months" pattern is not present / undetermined — it is not a finding either way.

Original assignee

• Entity on the issued patent: France Telecom SA (France). Google Patents now lists the current assignee as Orange SA, reflecting the corporate renaming described below.
• Line of business: Incumbent French (now multinational) telecommunications operator — fixed, mobile, broadband/Internet, and IP transport/backbone services. This is precisely the "access network / IP transport network operator (ANO/ITO)" described in the patent's own specification.
• Did they ship a product embodying the claims? The patent claims a RADIUS-proxy-based dual authentication (ANO/ITO operator + IAP/ISP) at PPP session setup. France Télécom/Orange operated exactly this class of infrastructure (NAS/BAS gateways, RADIUS AAA proxy). While I cannot point to a specific branded product SKU, the claimed architecture is the operator's own production access-authentication model — i.e., an operating-company patent, not a paper asset.
• Current status: Operating. France Telecom SA renamed itself Orange S.A. effective 2013-07-01 (shareholders approved 2013-05-28; disclosed in the company's SEC Form 6-K dated 2013-05-29; Euronext corporate-action notice). Orange S.A. remains an active, publicly traded operator (NYSE/Euronext Paris). No bankruptcy, dissolution, or fire-sale.

Assignment timeline

Chronological record as surfaced:

• 2004-03-02 to 2004-03-16 (executed) / recorded 2004-10-26 — Reel 015919/0164

  • Conveyance: Assignment of assignors' interest ("ASSIGNMENT OF ASSIGNORS' INTEREST")
  • Assignor: Morand, Lionel; Delmond, Frédéric (recorded "Delmod"); Transy, Estelle; and others [Carpy, Céline]
  • Assignee: France Telecom (France)
  • Correspondent: Not stated in the record I could retrieve. The Google Patents legal-event entry for this reel/frame omits the correspondent/attorney-of-record and the recording firm's address. I am not able to name the correspondent without the Assignment Center detail page, which I could not open directly. (Because this is the only assignment in the chain, the "repeat correspondent" test cannot be evaluated regardless.)
  • Context: Original inventor-to-employer assignment (acquisition by the operating company at filing). Signing dates span 2004-03-02 to 2004-03-16.

• 2013-07-01 (effective) — no separately recorded assignment surfaced for this patent number

  • Conveyance: Change of name only (France Telecom SA → Orange S.A.)
  • Assignee after: Orange S.A.
  • Context: Internal identity change, not a transfer of title. Caveat: For sibling France Télécom patents, the company did record change-of-name documents (e.g., France Télécom → Orange at reel 037124/0478, and Orange → France Télécom at reel 037882/0466, both effective dates in the 2009–2013 window, recorded ~2016). For US 7,448,075 specifically, the retrieved legal-events list shows only the 2004 assignment and no change-of-name reel — so either it was never separately recorded for this number, or Google Patents did not surface it. I cannot resolve this from the material available and flag it as unclear.

No later assignment recorded. After 2004, the legal events are maintenance-fee and status entries only: FPAY 2012-04-27 (4th year); FPAY 2016-04-27 (8th year); FEPP reminder 2020-06-22; LAPS/STCH 2020-12-07; FP lapse effective 2020-11-04. The patent is Expired – Fee Related.

Negative finding worth stating: I looked specifically for a transfer of this patent to 3G Licensing S.A. (Luxembourg) — the monetization vehicle Orange used around 2016 for certain patents (e.g., the Orange patents asserted by "3G Licensing, S.A. / Koninklijke 3G Licensing N.V. / Orange S.A."). No evidence was found that US 7,448,075 was transferred to 3G Licensing S.A. or any similar entity; the record still shows Orange S.A. as owner. That does not prove a transfer never occurred, but nothing in the available data supports it.

Timeline diagram

timeline
    title Ownership of US 7448075
    2003 : Priority filed FR 0301566
    2004 : US application filed Feb 3
         : Inventors assign to France Telecom
    2008 : Patent issued Nov 4
    2013 : France Telecom renamed Orange SA
    2020 : Patent lapsed for nonpayment

NPE / troll-pattern signals

Verdict

Insufficient data — meaning here: only the original inventor-to-employer assignment is recorded, and no assertion (or defensive-aggregation) event exists to characterize the asset further.

Justification. The sole recorded conveyance is reel 015919/0164 (executed 2004-03-02–2004-03-16, recorded 2004-10-26), assigning from inventors Morand, Delmond, Transy, and Carpy to France Telecom, with the current owner appearing as Orange S.A. via the 2013-07-01 corporate renaming. All eight NPE/troll signals are absent or unevaluable — no shell LLC, no known asserter, no cascading or pre-litigation transfers, no fire-sale, no privateering, no defensive aggregator — and the patent expired for non-payment of maintenance fees effective 2020-11-04. Because no post-issuance transfer and no litigation exist, there is nothing indicating NPE activity; the honest classification under the required taxonomy is "Insufficient data / only the original assignment," with the affirmative observation that ownership remained with the operating carrier Orange S.A.

Verification links (Assignment Center):

• https://assignmentcenter.uspto.gov/ (search by patent number 7448075)
• https://assignment.uspto.gov/patent/index.html (legacy interface; same underlying records)

Caveats (stated per operating rules)

• Correspondent unknown. I could not retrieve the correspondent/attorney-of-record for reel 015919/0164; I have therefore not named one. A "repeat correspondent" finding is impossible here anyway (single assignment).
• Change-of-name recording unclear. Whether a France Telecom → Orange change-of-name document was ever recorded against this specific patent number is unresolved from the data available; the corporate renaming itself (effective 2013-07-01) is well documented.
• Inventor spellings. The records contain apparent transcription variants — "DELMOD" (for Delmond) and "XARPY" (for Carpy) — which I have reported literally and flagged as variants rather than silently correcting.
• Direct-query gap. I was unable to open the Assignment Center detail page or PACER/Unified Patents dockets directly; a definitive negative on any unrecorded or foreign assignment should be confirmed against the USPTO Assignment Center and the equivalent EU/FR registers.
• No contradiction found with the previously generated litigation section: both conclude the patent was never asserted and lapsed in 2020.

I'll ground this analysis with targeted searches on the cited references, since the patent record gives me titles and dates but I want accurate descriptions of the key prior-art documents.

I have strong data on the most technically relevant references. Let me ground the remaining cited references.

Prior-Art Analysis — U.S. Patent No. 7,448,075 B2

Patent under analysis: US 7,448,075 B2 ("'075"), "Method and a system for authenticating a user at a network access while the user is making a connection to the Internet"; App. No. 10/771,422; priority 2003-02-10 (FR 0301566); filed 2004-02-03; granted 2008-11-04; original assignee France Télécom S.A. (current: Orange S.A.).

Methodology and scope note (read first)

• Source of the citation list. The 11 references below are the ones the patent record itself lists under "Patent Citations (11)" / "Citations (11)" (examiner- and third-party-cited references of record for the '075 US prosecution). I reproduce them literally from the authoritative full text supplied to me; I have not substituted similar numbers (e.g., 7,448,075 is not 7,448,xxx variants, 7,454,002, or any trademark-registration "7448075").
• What I could and could not verify. I retrieved abstracts/full-text fragments for the most technically relevant references (EP1251672A1, WO2002086718A1, US7188360B2, US6970848B2, US6910074B1). For the remainder I have the citation, dates, assignee, and title of record but did not retrieve full claim text in this pass. Where I reason from title/abstract only, I say so.
• Legal caveat. '075 is a granted patent — the examiner necessarily found these references insufficient to reject the claims as filed. A §102 "anticipation" finding requires that a single reference disclose every limitation, arranged as in the claim. My assessments below therefore grade closeness/§102 potential, not a legal conclusion of invalidity. Several references are better viewed as §103 obviousness material than as §102 anticipations.
• Prior-art timing. All 11 references pre-date the 2003-02-10 priority date as publications or (for US 6,910,074 / US 6,970,848 / US 7,188,360) as §102(e) applications filed before it.

Table A — The 11 cited references (US examination record)

The most relevant references (detailed)

1. EP 1251672 A1 — Microsoft Corporation — "Methods and systems for authentication through multiple proxy servers"

• Dates: published 2002-10-23; EP app. filed 2002-04-16; US priority 09/838,408 filed 2001-04-19.
• Description (verified): A client traverses multiple heterogeneous authentication proxies that require different authentication data (e.g., a wireless carrier proxy and a corporate proxy in different spheres of trust). The client places different authentication data for different proxies within a single request, each data set identified by a "realm" under the HTTP authentication header; each proxy reads only the data relevant to it, preserving confidentiality between proxies.
• Relevance / potential §102: Highest conceptual overlap. This is the closest reference to the '075 core idea that one access request carries two credential sets belonging to two different administrative domains (here, the operator/ANO-ITO and the provider). It is arguably relevant to claim 1 (access request carrying two identification/authentication datasets) and claim 6 (the multi-dataset credential construct, though claim 6's literal "IAPid|Nid|AUTH@IAPdomain, PW" string is not disclosed).
• Likely short of anticipation because: it is HTTP proxy authentication (not PPP/IP network-access setup), it does not disclose an access controller that splits the two datasets and forwards each to a different authentication server, and it does not teach a combined response message carrying the provider-side authentication result back to the terminal. More naturally a §103 reference.

2. WO 2002/086718 A1 — iPass, Inc. — "Method and system for securely authenticating network access credentials for users"

• Dates: published 2002-10-31; priority 2001-04-18.
• Description (verified): Network-access credential handling in which a credential (e.g., password) is encrypted with a public key at the access device, transmitted to a decryption server, decrypted, and then forwarded to an authentication server for verification; set in a multi-party service-access / roaming environment with multiple service providers, an access broker, and NAS/AAA (RADIUS/PAP/CHAP) infrastructure.
• Relevance / potential §102: Strong background for brokered network-access authentication (access device → intermediary server → AAA server) and roaming. Potentially relevant to claim 1's "authentication server of the … provider" element and to the intermediary-server architecture of claim 11. Not anticipatory of claims 1/7/11 as a whole: it does not teach a single access request carrying both the operator (ANO/ITO) and provider credential sets, nor an access controller that extracts two distinct sets and routes each to its respective authentication server.

3. US 7,188,360 B2 — Telefonaktiebolaget LM Ericsson (Publ) — "Universal authentication mechanism"

• Dates: issued 2007-03-06; filed 2002-08-22; priority 2001-09-04.
• Description (verified): An application device requests a service and transmits a user identity to the service provider (SP); the SP sends a request for confirmation of the user identity (with a service identity) to an authentication server (AS); the AS requests service authentication from an authentication device; based on the confirmation, the AS confirms the user identity to the SP, which grants service access.
• Relevance / potential §102: Relevant to the "separate authentication server authenticates the user on behalf of the service provider" architecture and to multi-party identity-confirmation flows. Potentially relevant to claim 1's provider-side authentication step. Not anticipatory — no teaching of two credentials of different domains in one access request, and no access-controller splitting/routing step.

4. US 6,970,848 B2 — Fujitsu Limited — "Method for authenticating users"

• Dates: issued 2005-11-29; filed 2000-10-11 (JP priority 2000-310878); pre-grant pub. US 2002/0042779 (2002-04-11).
• Description (verified): An authentication agent server authenticates users on behalf of multiple content providers, then sends the authentication result to the content provider through the user terminal; includes falsification-protection codes and time-window validity checks on the returned result.
• Relevance / potential §102: Relevant to the notion of an intermediary that authenticates on behalf of a provider and returns the authentication result. Potentially relevant to claim 1's "transmitting a response … containing the result of user authentication by the … provider" element and to claims 2/8 (inserting authentication results into responses). Not anticipatory — it does not disclose the operator-domain credential set or the split-routing access controller.

5. US 6,910,074 B1 — Nortel Networks Limited — "System and method for service session management in an IP centric distributed network"

• Dates: issued 2005-06-21; filed 2000-07-24.
• Description (verified): Next-generation-network architecture separating access session / service session / transport session management; AAA+ functions; an "allied application server" that manages QoS/bandwidth; subscriber-specific information (location, habits, devices, preferences) made available to application service platforms.
• Relevance / potential §102: Background on IP-network session management and AAA+, and on providing subscriber/profile information to service platforms — arguably relevant to claim 3 / claim 9 (user profile data). Not anticipatory of any independent claim; it does not address dual-domain credential authentication in an access request.

The remaining cited references (lower relevance)

6. US 6,466,571 B1 — 3Com Corporation — "Radius-based mobile internet protocol (IP) address-to-mobile identification number mapping for wireless communication"

• Dates: filed 1999-01-19; issued 2002-10-15.
• Description: RADIUS-based mapping between a mobile IP address and a mobile identification number.
• Relevance / potential §102: Background only, chiefly relevant to claim 10 (RADIUS-based controller/server). No teaching of dual-domain authentication; not anticipatory.

7. US 2001/0037466 A1 — Konami Corporation — "Network connection control method and connection control system"

• Dates: filed 2000-04-28; published 2001-11-01.
• Description: Network connection control method/system.
• Relevance / potential §102: General connection-control background. (Also appears in the family citations of FR 2851104 A1.) No teaching of the dual-credential access-request structure; not anticipatory.

8. WO 2001/045352 A2 — DeTeMobil Deutsche Telekom Mobilnet GmbH — "Method and arrangement for the improved exploitation of technical resources between telecommunications networks and IP-networks"

• Dates: priority 1999-12-16; published 2001-06-21.
• Description: Interworking/resource exploitation between telecommunications networks and IP networks.
• Relevance / potential §102: Telecom/IP interworking background; no dual-domain authentication teaching; not anticipatory.

9. US 2002/0194334 A1 — Alcatel — "Processor system, access server system, method and computer program product"

• Dates: filed 2001-06-14; published 2002-12-19.
• Description: An access-server/processor system. (I did not retrieve the full text; description inferred from the title of record.)
• Relevance / potential §102: Potentially relevant to claim 7 (access-server system) at a generic level. I cannot verify any dual-credential teaching; not shown anticipatory on available information.

10. US 6,032,260 A — NCR Corporation — "Method for issuing a new authenticated electronic ticket based on an expired authenticated ticket and distributed server architecture for using same"

• Dates: filed 1997-11-13; issued 2000-02-29.
• Description: Authenticated electronic-ticket issuance/renewal in a distributed server architecture.
• Relevance / potential §102: Authentication/ticketing background (loosely parallels the billing-ticket aspect of the specification). No teaching of the claimed connection-setup method; not anticipatory.

11. US 6,108,789 A — Liberate Technologies — "Mechanism for users with internet service provider smart cards to roam among geographically disparate authorized network computer client devices without mediation of a central authority"

• Dates: filed 1998-05-05; issued 2000-08-22.
• Description: Roaming among network computers using ISP smart cards, without a central authority.
• Relevance / potential §102: Roaming/user-identification background. Does not disclose dual-domain credentials in one access request or a split-routing access controller; not anticipatory.

Table B — "Family Cites Families (5)" (citations in the family/foreign counterparts)

Important distinction: These five appear under Google Patents' "Family Cites Families" — i.e., they were cited in the prosecution/search of the family members (e.g., EP/CN/KR/JP counterparts), not necessarily in the US '075 examination. I flag them separately because they were not part of the US "Patent Citations" list above.

Claim-by-claim §102 assessment (summary)

Bottom line

1. No single cited reference anticipates claims 1, 7, or 11 under §102 on the record available to me. The '075 independent claims require a specific combination — one access request carrying (i) ANO/ITO credentials and (ii) provider credentials, an access controller that splits the two sets, routes each to its respective authentication server, and returns a combined response — in a PPP/RADIUS-type connection-setup context.
2. The most relevant prior art is, in order: EP 1251672 A1 (Microsoft) — the closest on the "two distinct credential sets for two trust domains in a single request" idea; then WO 2002/086718 A1 (iPass) — brokered network-access authentication with an intermediary server and AAA; then US 7,188,360 B2 (Ericsson) and US 6,970,848 B2 (Fujitsu) — separate/intermediary authentication servers. These are best characterized as §103 obviousness material, not §102 anticipations.
3. US 6,910,074 B1 (Nortel) is the best support for the profile/AAA dependent claims (3, 9); US 6,466,571 B1 (3Com) and iPass are background for the RADIUS dependent claim (10).

Confidence flags

• High confidence in the citation list, dates, assignees, and titles — taken verbatim from the authoritative record.
• High confidence in the verified descriptions of EP1251672A1, WO2002086718A1, US7188360B2, US6970848B2, US6910074B1 (retrieved during this analysis).
• Moderate/low confidence on the descriptions of US2002/0194334A1 (Alcatel) and the Family-Cites items (F4, F5), where I reasoned from titles of record without full-text retrieval — treat those descriptions as provisional.
• No §102 conclusion is warranted for any reference based on titles/abstracts alone; a definitive anticipation analysis requires element-by-element comparison against each reference's full disclosure (specification + claims as filed), which I could not complete for every reference here.
• I did not auto-correct any identifier; 7,448,075 was interpreted literally throughout, and near-numbers appearing in search results (e.g., 8,543,710; 8,397,282; 7,545,758) were excluded as belonging to different patents.

I'll ground the key prior-art references before building the § 103 combinations.

Let me ground a few more of the listed references that bear directly on the dual-authentication architecture.

Obviousness Analysis — US 7,448,075 B2 under 35 U.S.C. § 103

Building on the prior sections. The bibliographic data, claim text, and the "no litigation identified" finding from the earlier analyses are treated as authoritative here and are not repeated. This section adds only the § 103 merits. I use the references appearing in the Prior Art section of the patent page (the "Patent Citations (11)," "Family Cites Families (5)," and "Similar Documents" listings), because those are the references the record itself surfaces.

1. Two threshold caveats that shape the analysis

1a. Claim-drafting defects already flagged. The earlier section noted that granted claim 7 recites a "means for extracting … the second user identification and authentication data and for transmitting said data to the authentication server of the access network and IP transport network operator" — i.e., the provider (second) credential set is routed to the operator's server — and that claim 1 contains the artifact "the authentication server of the Internet access provider of IP service provider." These are reported literally. For § 103 they matter because a claim that is internally inconsistent or that reads on its own stated purpose only through the working examples is vulnerable to both (i) a written-description/definiteness challenge and (ii) an obviousness rejection in which the examiner maps the claim to the specification's described operation. I analyze below against the specification's operation (split routing), which is the only reading under which the claims are enabled, and I note where the literal claim text would change the result.

1b. Priority date governs the prior-art universe. Priority is 2003-02-10 (FR 0301566); the US filing date is 2004-02-03. Every reference relied on below predates 2003-02-10 and is therefore available under at least § 102(a)/(b)/(e). None of the combinations depends on post-2003 art.

2. Prior-art universe actually relied on

The patent's own FIG. 1 / Background is itself an admission of: PPP session setup carrying IAPid@IAPdomain + password; IP gateway encapsulating into RADIUS/Diameter Access-Request; and a proxy server 9 that "direct[s] such authentication requests through an IP transport network to an AAA server" of the provider. That admitted architecture is prior art against these claims.

3. The Graham/KSR framework applied to this claim set

The independent claims have four substantive elements: (A) a single terminal access request carrying two credential sets for two different administrative domains; (B) an intermediary ("access controller") that receives it; (C) the controller splitting the two sets to two different authentication servers; (D) a response message returned to the terminal through the controller reporting at least the provider-side result.

There is no new physical component, no new protocol, and no unexpected result. Every element is a known building block arranged in a predictable way, and the patent's own specification concedes that it "complies with present procedures for setting up a PPP/IP connection" — i.e., it is designed to avoid changing the existing architecture. That framing (an improvement by combination, with no change to underlying hardware/protocol) is the classic KSR posture for obviousness.

4. Grounds of rejection

Ground 1 — Claims 1, 6, 10, 11: EP 1 251 672 A1 in view of US 6,466,571 B1 (and the admitted FIG. 1 art)

Mapping:

Motivation to combine. EP '672 states the exact problem the '075 patent addresses: proxies administered by different entities that "do not trust each other enough to allow the same authentication data to represent the same user," requiring each to have its own credentials and each to authenticate independently (EP1251672A1 ¶¶0046–0048). The '075 patent's stated problem — the access/IP-transport operator cannot validate IAPid@IAPdomain because it lives in a different administrative domain (Background section, verbatim in the supplied text) — is the same problem with the parties renamed. A POSITA seeking the operator-side authentication the '075 patent claims would have been drawn directly to EP '672, and would have applied it using the standard RADIUS/PPP plumbing already admitted in the '075 Background and disclosed in 3Com '571. Nothing more than a predictable substitution of protocol carriers (HTTP 407 Proxy Authentication → PPP/PAP + RADIUS attributes) is involved, and the patent itself says Diameter/PAP/RADIUS are interchangeable.

Claim 6 (the string IAPid|Nid|AUTH@IAPdomain, PW) is the weakest link. Given (i) the admitted PAP convention IAPid@IAPdomain for the username and a password, and (ii) EP '672's teaching of labeling multiple credential sets so each domain gets only its own, merely concatenating the operator's identifier and secret into the same username field with a delimiter is the quintessential predictable variation — a formatting choice with no asserted technical effect. Expect a strong § 103 rejection of claim 6 on this basis, absent evidence of unexpected results.

Claim 10 (RADIUS proxy / RADIUS server) is squarely met: the '075 Background admits proxy server 9 is a RADIUS/Diameter proxy, and 3Com '571 is a RADIUS server.

Claim 11 (access controller as an apparatus) rises or falls with claim 1's split-routing; EP '672's first proxy plus 3Com's access server supply every recited "means."

Confidence: moderately high on claims 1, 10, 11; high on claim 6.

Ground 2 — Claims 1, 7, 11: WO 2002/086718 A1 (iPass) in view of EP 1 251 672 A1

iPass teaches the intermediary-in-the-middle topology the '075 claims: a serving access network (NAS) receives the user's credentials and forwards them to an intermediary (the broker/decryption server), which forwards them to the subscriber's own provider-side AAA server for the provider-domain decision. EP '672 supplies the specific teaching of packing two credential sets for two domains into one request and splitting them, and of trusting neither domain with the other's secret.

Motivation: iPass is a roaming/brokerage architecture; the whole commercial point of a broker is to let a user whose home provider is not the serving operator be authenticated by the serving operator's network. That is precisely the '075 patent's stated business motivation ("managing the mobility of roaming users … single multi-access billing") and the pre-existing industry pressure the patent itself recites. Combining the broker topology (iPass) with the multi-credential single-request mechanism (EP '672) is a rational, expectation-backed combination of two references addressing the same multi-party authentication problem.

Claim 7 adds no structural element beyond terminal-side means, per-provider auth server, operator auth server, and the controller — all present in iPass + EP '672 + the admitted FIG. 1 gateways. Note again the literal claim-7 routing inconsistency flagged in the prior section; on the specification's reading it is the same split as claim 1.

Confidence: moderate-to-high.

Ground 3 — Claims 3 and 9: any of Grounds 1–2 further in view of EP 1 222 775 B1 (Nomadix)

Claim 3 (insert user profile data in the response on successful operator-side authentication) and claim 9 (database of operator-side user identification data and profile data, accessible to the auth server and/or controller) are both expressly taught by Nomadix: the AAA server "includes source-profile database … source profiles that represent users authorized," the profile can include "billing scheme related data, service level data, user profile data," and "the AAA server can transmit to the gateway device … any requisite information relating to the source's authorization rights" (EP1222775B1, Summary and ¶0046). Nomadix also supplies the RADIUS/LDAP realization and the rationale for an external consolidated database (confidentiality, administration) — the same rationale the '075 patent gives for database 13.

Motivation: once Ground 1 or 2 establishes independent operator-side authentication, attaching a per-user profile lookup to that same authentication event is the routine next step, and Nomadix explicitly teaches both the data structure and returning profile data to the gateway.

Confidence: high.

Ground 4 — Claims 4 and 5: Grounds 1–3 further in view of US 6,792,457 B1 (Zhang/Cisco) and/or Nomadix

Claim 5 (authentications "triggered substantially simultaneously") and claim 4 (one after the other, in either order) are pure ordering/sequencing choices. Where two independent authentications are specified but no order is functionally required, running them in parallel (to reduce connection-setup latency) or in series (to sequence error handling) is a classic obvious design choice with predictable results. Nomadix's gateway/AAA exchange and Cisco's SSG↔AAA-server exchange both show the gateway initiating one authentication and awaiting a reply before proceeding, which is the serial arrangement; running the operator-side and provider-side requests concurrently over the same controller is the obvious parallel variant. The '075 specification corroborates that nothing turns on the order: it states the two authentications "may be performed simultaneously or else sequentially in any order."

Motivation: latency reduction at PPP session setup is a recognized design objective; the patent asserts no unexpected benefit from either ordering, and its only dependent-claim differentiator between claims 4 and 5 is the sequence itself.

Confidence: high.

Ground 5 — Consequential: the response/accounting and the "single request" nexus

US 6,792,457 (Zhang) supplies the "gateway generates RADIUS access request at PPP logon → AAA returns access-accept → gateway issues accounting" flow that the '075 Background already admits ("At the end of an IP connection, the IP gateways 3, 4 issue a ticket"). It reinforces Ground 1 (the response-message step) and, if the patentee argued that combining operator-side and provider-side authentication into one PPP-setup exchange was non-obvious, Zhang shows that multi-party accounting/authorization tied to a single PPP-login event was known. Treat as cumulative, not essential.

5. Why a POSITA would combine — summarized motivations

1. Same problem, same field. EP '672 names the identical problem (proxies/domains that do not trust one another's credentials), and iPass names the identical commercial scenario (roaming user authenticated by an entity other than the serving operator). Neither is from an unrelated art; both are network access authentication.
2. Express teaching, not mere aggregation. EP '672 expressly teaches the mechanism the '075 claims — multiple credential sets for multiple domains carried in one request and split to the respective authenticators, with each domain reading only its own set. That is a teaching directed to the very limitation that distinguishes the '075 claims over the admitted FIG. 1 art.
3. Predictable substitution. The only thing the '075 patent adds on top is the choice of PPP/PAP + RADIUS as the carrier — which the '075 patent itself admits is the pre-existing standard and which 3Com '571 and Zhang '457 supply — and the concatenation of the two credential sets into a username string (claim 6).
4. KSR design incentives. Independent, parameterizable authentications with no required order → run them in parallel for latency (claim 5) or serially for control flow (claim 4); attach a profile look-up to the operator-side success event → Nomadix (claims 3, 9). These are "design incentives … present in the marketplace" and predictable variations, not inventions.
5. The patent's own admission weighs against non-obviousness. The specification states the architecture "complies with present procedures for setting up a PPP/IP connection," that the operator credential insertion is "optional, at the user's choice," and that Diameter may be substituted for RADIUS. An invention that is expressly designed to require no change to existing procedures, and whose distinguishing feature is optional, is hard to defend as non-obvious.

6. Counter-considerations and how they would be litigated

• Possible teaching-away argument — the "no cross-domain exposure" teaching of EP '672. EP '672 teaches removing the first proxy's data before forwarding so the second domain cannot read it. The '075 patent keeps the operator credentials available to the operator's own controller. This is not a teaching away: EP '672's removal is about not exposing domain-1 secrets to domain-2, which the '075 controller-based split (operator's server reads only Nid/AUTH; provider's server reads only IAPid/PW) preserves rather than contradicts. The patentee's best counter would be that EP '672 is HTTP-proxy-centric and says nothing about PPP/RADIUS session setup — a field/format argument, which is weak given 3Com '571, Zhang '457, and the patent's own admitted RADIUS Background.
• Objective indicia. None are asserted in the record reviewed. For a § 103 defense, the absence of evidence of unexpected results, licensing, or copying is a material gap for the patentee. A long-felt-need argument could be attempted (operators wanting to identify users), but EP '672/iPass show the need was recognized and partially solved pre-2003.
• Claim-6 argument available to patentee. The patentee could argue that the specific delimited construction IAPid|Nid|AUTH@IAPdomain enabled coexistence with unmodified PAP/RADIUS stacks. This is the least attackable claim on Ground 1, but it is narrow, and the asserted advantage (backward compatibility) is precisely what the specification says the invention was designed to preserve — i.e., it argues predictable, not unexpected, behavior.
• Validity posture is academic here. The patent lapsed for non-payment of maintenance fees effective 2020-11-04 (per the earlier section), so an infringement suit asserting these claims is practically foreclosed and an IPR/PGR is time-barred. This analysis is therefore most useful as an invalidity/defensive position (e.g., against an Orange S.A. descendant claim or in a freedom-to-operate context), not as a live litigation prediction.

7. Bottom line and confidence

Explicit uncertainty flags.

• The content of US 6,970,848 (Fujitsu), US 7,188,360 (Ericsson), US 2002/0194334 (Alcatel), US 6,910,074 (Nortel) was not re-verified in this pass (search budget exhausted); they are cited only as cumulative record art, and I would not rest a ground on them without verification. Everything used in Grounds 1–5 that I characterize as "verified" comes from the retrieved EP '672, US '571, WO '718, EP '775, and US '457 texts linked above.
• The literal claim text of claims 1 ("of" for "or") and 7 (second data routed to the operator server) is internally inconsistent; I analyzed against the specification's split-routing operation, and a literal reading of claim 7 would change the mapping in a way that weakens, not strengthens, validity (a claim that cannot be practiced as written invites indefiniteness as well as § 103).
• I make no legal conclusion on validity; the above is a technical/analytical prediction of how an examiner or a challenger would likely frame the combinations, with the Graham factors applied.