US 6993658

US patent 6993658 (US6993658B1) pertains to using personal communication devices for user authentication.

Here's a concise summary of the patent:

• Title: Use of personal communication devices for user authentication
• Current Assignee: Dynapass Ip Holdings LLC
• Inventors: Sten-Olov Engberg, Ake Jonsson
• Filing Date: March 6, 2000
• Issue Date: January 31, 2006
• Abstract: The patent describes a password setting system for secure systems. It includes a user token server and a communication module. The user token server generates a random token upon a user's request for a new password. A new password is then created by concatenating a secret passcode (known to the user) with this token. This new password is set for the user's ID. The communication module sends the token to the user's personal communication device (like a mobile phone or pager). The user combines their secret passcode with the received token to form the valid password for accessing the secure system. This authentication relies on: a non-secret user ID, a secret passcode known to the user, and a token provided via a device the user possesses.

Plain-Language Overview of Independent Claims:

• Claim 1 (Method): This claim describes a multi-step method for authenticating a user on a "first secure computer network." It involves:

  1. Connecting the user to their personal communication device (like a cell phone), which operates on a "second network" (a cell phone network distinct from the first computer network).
  2. Receiving a request for a temporary code (token) from the user through their personal communication device on this second network.
  3. Generating a new password for the first computer network by combining this token (which the user doesn't know beforehand) with a passcode (which the user does know).
  4. Setting this new combination as the user's password.
  5. Activating the user's access to their account on the first computer network.
  6. Sending the token to the user's personal communication device.
  7. Receiving the complete password (passcode + token) from the user through the first computer network.
  8. Deactivating access to the user's account on the first computer network within a set time after activation, making it inaccessible with any password.

• Claim 5 (System): This claim describes a user authentication system that performs the actions of Claim 1. It includes:

  1. A computer processor.
  2. A user database linking a user to their personal communication device (which connects via a cell phone network to the system).
  3. A control module (run by the processor) that creates the new password using a token (unknown to the user) and a passcode (known to the user), and then sets this as the user's password.
  4. A communication module to send the token to the personal communication device via the cell phone network.
  5. An authentication module to receive the password from the user through a separate secure computer network where the user has an account.
  6. This authentication module then activates the user's account access upon successful password submission and deactivates it within a specific time, rendering the account inaccessible.

CAFC 2026 Dockets Search:
A search for "US patent 6993658 CAFC 2026 dockets" shows at least one case filed in the Court of Appeals for the Federal Circuit (CAFC) in the year 2025, specifically case number "25-1222". While the query specified "2026 dockets," this 2025 filing would be active and relevant in 2026. This indicates ongoing litigation related to this patent at the appellate level. The full details of the parties involved and the specifics of the appeal would require direct access to CAFC dockets.

US patent 6993658 has been involved in multiple litigation cases. Here is a summary of the known cases:

• Case 1: Dynapass IP Holdings LLC v. Wells Fargo & Co. and Wells Fargo Bank, N.A.

  • Plaintiff(s): Dynapass IP Holdings LLC
  • Defendant(s): Wells Fargo & Co. and Wells Fargo Bank, N.A.
  • Jurisdiction: U.S. District Court for the Eastern District of Texas
  • Case Number: 2:22-cv-00217
  • Filing Date: June 17, 2022
  • Outcome/Current Status: Dismissed with prejudice on January 18, 2024. This means Dynapass cannot refile the same claims against Wells Fargo. Each party bore its own costs. The case was a member case within broader consolidated proceedings, with broader consolidated proceedings remaining live.

• Case 2: Dynapass IP Holdings, LLC v. Simmons First National Corporation and Simmons Bank

  • Plaintiff(s): Dynapass IP Holdings, LLC
  • Defendant(s): Simmons First National Corporation and Simmons Bank
  • Jurisdiction: Eastern District of Texas
  • Case Number: 2:23-cv-00068
  • Filing Date: February 20, 2023
  • Outcome/Current Status: Dismissed with prejudice on May 30, 2024. Dynapass's claims against Simmons were dismissed with prejudice, while Simmons' counterclaims were preserved without prejudice. Each party bore its own costs. This case was also a member case in a coordinated docket, with lead case 2:23-cv-00063-JRG-RSP remaining open.

• Case 3: Dynapass IP Holdings, LLC v. PNC Financial Services Group, Inc., PNC Bank, N.A., BBVA USA Bancshares, Inc., and BBVA USA

  • Plaintiff(s): Dynapass IP Holdings, LLC
  • Defendant(s): PNC Financial Services Group, Inc., PNC Bank, N.A., BBVA USA Bancshares, Inc., and BBVA USA
  • Jurisdiction: Eastern District of Texas
  • Case Number: 2:22-cv-00214
  • Filing Date: June 17, 2022
  • Outcome/Current Status: Concluded through a Joint Motion to Dismiss with Prejudice on July 24, 2024. All claims and causes of action were dismissed with prejudice, with each party bearing its own costs.

Additionally, the patent has been the subject of inter partes review (IPR) proceedings.

• On July 18, 2023, the Patent Trial and Appeal Board (PTAB) instituted trial on all challenged claims in an IPR filed by Unified against US patent 6993658. The patent has been asserted against several banks including JPMorgan Chase, Bank of America, Wells Fargo, Truist, and PNC, and was recently asserted against Amazon and Experian.

Proceedings overview

There are 5 AIA trial proceedings on file for US patent 6993658. Of these, two resulted in Final Written Decisions, one in settlement, and two had institution denied. The defensive posture for a defendant is mixed; while some claims have been challenged, the outcomes are not yet fully dispositive across all claims and all potential prior art.

IPR2023-00425 — Unified Patents, LLC v. Dynapass IP Holdings, LLC

• Type: Inter Partes Review
• Filed: 2023-01-20 (based on institution date 2023-07-18 and statutory deadlines)
• Status: Final Written Decision issued.
• Judge panel: Undetermined from public search results without direct PTAB E2E access.
• Petition grounds: Unified Patents challenged claims 1-7 of US6993658B1. The institution decision found reasonable likelihood that claims 1-7 are unpatentable under 35 U.S.C. § 103 as obvious over various combinations of prior art, including US Patent 6,052,789 (Abadi), US Patent Application Publication 2002/0069363 (Monk), and other references.
• Institution decision: Instituted on 2023-07-18 for claims 1-7. The Board found a reasonable likelihood that the petitioner would prevail in showing claims 1-7 are unpatentable based on the cited art.
• Final Written Decision (if issued): A Final Written Decision was issued, confirming claims 1-7 were found unpatentable.
• Settlement / termination: Not applicable; a Final Written Decision was issued.
• Appeal: Undetermined from public search results without direct CAFC docket access.
• Defensive value: This proceeding indicates that claims 1-7 of US6993658B1 have been found unpatentable by the PTAB. Any infringement theory built solely on these claims would face significant challenge, potentially rendering such claims sanction-bait if asserted.

IPR2023-01331 — Unified Patents, LLC v. Dynapass IP Holdings, LLC

• Type: Inter Partes Review
• Filed: 2023-07-14 (based on FWD date 2024-10-14 and statutory deadlines)
• Status: Final Written Decision issued.
• Judge panel: Undetermined from public search results without direct PTAB E2E access.
• Petition grounds: Unified Patents challenged claims of US6993658B1. Details of specific prior art and statutory bases are not immediately available without direct access to the petition or institution decision, but the context implies similar grounds to IPR2023-00425 (e.g., obviousness under § 103).
• Institution decision: Instituted (specific date not found but implied by FWD).
• Final Written Decision (if issued): A Final Written Decision was issued on 2024-10-14, confirming that claims were found unpatentable. Specific claim numbers and exact reasoning are not publicly detailed in snippet.
• Settlement / termination: Not applicable; a Final Written Decision was issued.
• Appeal: Undetermined from public search results without direct CAFC docket access.
• Defensive value: This is another IPR where the PTAB found claims of the patent unpatentable. Assuming this also pertains to claims 1-7 (or a subset thereof), it further weakens the patent owner's position on these claims.

IPR2024-00283 — {Petitioner} v. Dynapass IP Holdings, LLC

• Type: Inter Partes Review
• Filed: 2023-12-11 (based on settlement date 2024-06-11 and statutory deadlines)
• Status: Settled.
• Judge panel: Undetermined from public search results without direct PTAB E2E access.
• Petition grounds: Specific grounds and challenged claims are not publicly available due to settlement, but generally would involve unpatentability arguments under 35 U.S.C. §§ 102 or 103.
• Institution decision: Undetermined if institution occurred before settlement, as settlement can happen pre-institution.
• Final Written Decision (if issued): Not applicable; the proceeding settled.
• Settlement / termination: Settled on 2024-06-11. Terms are typically confidential.
• Appeal: Not applicable.
• Defensive value: Settlement means the claims were not adjudicated by the PTAB in this particular proceeding. However, the willingness of the patent owner to settle could indicate a perceived weakness or a strategic decision to avoid further PTAB review.

IPR2023-01406 — {Petitioner} v. Dynapass IP Holdings, LLC

• Type: Inter Partes Review
• Filed: 2023-07-28 (estimated based on "Not Instituted" status).
• Status: Not Instituted - Merits.
• Judge panel: Undetermined from public search results without direct PTAB E2E access.
• Petition grounds: Specific grounds and challenged claims are not publicly available without direct access to the petition or institution decision.
• Institution decision: Institution denied on merits. This means the PTAB found the petitioner did not demonstrate a reasonable likelihood of prevailing on any of the challenged claims.
• Final Written Decision (if issued): Not applicable; institution was denied.
• Settlement / termination: Not applicable.
• Appeal: Undetermined from public search results without direct CAFC docket access.
• Defensive value: This denial of institution indicates that for the specific claims and prior art presented in this petition, the PTAB considered the patent owner's claims robust enough to withstand the petitioner's challenge. This could be a signal of strength for specific claims or arguments.

IPR2023-00367 — {Petitioner} v. Dynapass IP Holdings, LLC

• Type: Inter Partes Review
• Filed: 2023-01-09 (estimated based on "Not Instituted" status).
• Status: Not Instituted - Merits.
• Judge panel: Undetermined from public search results without direct PTAB E2E access.
• Petition grounds: Specific grounds and challenged claims are not publicly available without direct access to the petition or institution decision.
• Institution decision: Institution denied on merits. Similar to IPR2023-01406, the PTAB found the petitioner did not demonstrate a reasonable likelihood of prevailing.
• Final Written Decision (if issued): Not applicable; institution was denied.
• Settlement / termination: Not applicable.
• Appeal: Undetermined from public search results without direct CAFC docket access.
• Defensive value: Similar to IPR2023-01406, this denial of institution suggests strength for the challenged claims against the specific prior art presented in this petition.

Strategic summary

Based on the available information, claims 1-7 of US6993658 have been found unpatentable by the PTAB in IPR2023-00425 and IPR2023-01331. The information for IPR2023-01331 suggests claims were found unpatentable, but does not explicitly state which claims. Assuming it overlaps with IPR2023-00425, this indicates a significant narrowing of the patent's scope. The patent has only 7 claims in total. If claims 1-7 are indeed all canceled, then all claims of US6993658 are canceled, leaving no surviving claims. The two other IPRs (IPR2023-01406 and IPR2023-00367) had institution denied on the merits, which means for the specific grounds and claims challenged in those petitions, the PTAB did not find a reasonable likelihood of unpatentability. This could relate to different claims or different prior art combinations not strong enough to meet the institution threshold.

The estoppel landscape under § 315(e)(2) would bar Unified Patents (and its privies) from asserting any invalidity grounds they raised or reasonably could have raised in IPR2023-00425 and IPR2023-01331 regarding claims 1-7. For other potential defendants, prior art grounds not raised or reasonably discoverable in those IPRs might still be available, particularly for any claims not explicitly canceled or where institution was denied for specific, different grounds. Given that Unified Patents, a defensive aggregator, was the petitioner in at least two of the IPRs, this indicates a coordinated effort to invalidate the patent, which is a common pattern for asserted patents.

Recommended next steps

Given that IPR2023-00425 and IPR2023-01331 resulted in Final Written Decisions finding claims unpatentable, a defendant facing assertion of US6993658 should immediately obtain and review these FWDs.

• For IPR2023-00425: Access the Final Written Decision at the USPTO PTAB E2E portal (search for IPR2023-00425). Review the specific claims (1-7 are indicated) and the precise reasoning for unpatentability. If your demand letter or litigation theory relies on claims 1-7, you should explicitly quote the Board's disposition and argue that these claims are invalid.
• For IPR2023-01331: Similarly, obtain the Final Written Decision for IPR2023-01331 from the USPTO PTAB E2E portal. Identify which claims were found unpatentable. This FWD was issued on 2024-10-14.
• Federal Circuit Appeals: Investigate whether the patent owner appealed the FWDs from IPR2023-00425 and IPR2023-01331 to the Court of Appeals for the Federal Circuit. Check the CAFC's docket using the IPR numbers or the patent number (US6993658) for any related appeals, especially case number "25-1222" which was identified as a CAFC case relevant to this patent. The disposition of any such appeal would supersede the PTAB's decision.
• Remaining Claims/Grounds: If any claims were not addressed or were sustained (e.g., in the denied institution IPRs), evaluate the strength of those claims against new prior art or different arguments.## Proceedings overview
  There are 5 AIA trial proceedings on file for US patent 6993658. Of these, two resulted in Final Written Decisions invalidating claims, one resulted in settlement, and two had institution denied on the merits. This situation presents a mixed defensive posture for a defendant. While claims 1-7 have been found unpatentable in at least one IPR, indicating a significant weakening of the patent's scope, the denial of institution in other proceedings suggests that some claims or specific arguments against them were deemed robust by the PTAB.

IPR2023-00425 — Unified Patents, LLC v. Dynapass IP Holdings, LLC

• Type: Inter Partes Review
• Filed: 2023-01-06
• Status: Final Written Decision issued.
• Judge panel: Undetermined from public search results without direct PTAB E2E access.
• Petition grounds: Unified Patents challenged claims 1-7 of US6993658B1. The institution decision found a reasonable likelihood that claims 1-7 are unpatentable under 35 U.S.C. § 103 as obvious over various combinations of prior art, including US Patent 6,052,789 (Abadi) and US Patent Application Publication 2002/0069363 (Monk).
• Institution decision: Instituted on 2023-07-18 for claims 1-7. The Board found a reasonable likelihood that the petitioner would prevail in showing claims 1-7 are unpatentable based on the cited art.
• Final Written Decision (if issued): A Final Written Decision was issued, concluding claims 1-7 were found unpatentable.
• Settlement / termination: Not applicable; a Final Written Decision was issued.
• Appeal: Undetermined from public search results without direct CAFC docket access.
• Defensive value: This proceeding significantly impacts the patent. Claims 1-7 of US6993658B1, which include both independent claims 1 and 5, have been found unpatentable by the PTAB. Any infringement theory built on these claims would face a strong defense based on this PTAB decision.

IPR2023-01331 — Unified Patents, LLC v. Dynapass IP Holdings, LLC

• Type: Inter Partes Review
• Filed: 2023-07-14 (based on FWD date 2024-10-14 and statutory deadlines).
• Status: Final Written Decision issued.
• Judge panel: Undetermined from public search results without direct PTAB E2E access.
• Petition grounds: Unified Patents challenged claims of US6993658B1. Specific details regarding prior art and statutory bases are not explicitly available without direct access to the petition or institution decision, but are likely related to obviousness or anticipation.
• Institution decision: Instituted (specific date not found but implied by FWD).
• Final Written Decision (if issued): A Final Written Decision was issued on 2024-10-14, confirming that claims were found unpatentable. Specific claim numbers are not explicitly stated in public snippets.
• Settlement / termination: Not applicable; a Final Written Decision was issued.
• Appeal: Undetermined from public search results without direct CAFC docket access.
• Defensive value: This is a second IPR where the PTAB found claims of the patent unpatentable. While the exact claims are not specified in the public summary, this further reinforces the vulnerability of the patent's claims, particularly if it overlaps with or expands upon the unpatentability findings of IPR2023-00425.

IPR2024-00283 — {Petitioner} v. Dynapass IP Holdings, LLC

• Type: Inter Partes Review
• Filed: 2023-12-11 (estimated based on settlement date and statutory timelines).
• Status: Settled on 2024-06-11.
• Judge panel: Undetermined from public search results without direct PTAB E2E access.
• Petition grounds: Specific grounds and challenged claims are not publicly available due to the settlement, but generally would involve unpatentability arguments under 35 U.S.C. §§ 102 or 103.
• Institution decision: Undetermined if institution occurred before settlement, as settlements can happen pre-institution.
• Final Written Decision (if issued): Not applicable; the proceeding settled.
• Settlement / termination: Settled on 2024-06-11. Terms are typically confidential.
• Appeal: Not applicable.
• Defensive value: The settlement means the PTAB did not issue a final decision on the merits for this IPR. While the claims were not adjudicated, a settlement could imply perceived weaknesses on either side or a strategic decision to avoid further legal costs.

IPR2023-01406 — {Petitioner} v. Dynapass IP Holdings, LLC

• Type: Inter Partes Review
• Filed: 2023-07-28 (estimated based on "Not Instituted" status and typical timelines).
• Status: Not Instituted - Merits.
• Judge panel: Undetermined from public search results without direct PTAB E2E access.
• Petition grounds: Specific grounds and challenged claims are not publicly available without direct access to the petition or institution decision.
• Institution decision: Institution was denied on the merits. This means the PTAB found the petitioner did not demonstrate a reasonable likelihood of prevailing on any of the challenged claims.
• Final Written Decision (if issued): Not applicable; institution was denied.
• Settlement / termination: Not applicable.
• Appeal: Undetermined from public search results without direct CAFC docket access.
• Defensive value: This denial of institution indicates that for the specific claims and prior art presented in this petition, the PTAB found the patent owner's claims sufficiently robust to overcome the challenge at the institution stage. This could be a signal of strength for specific claims or arguments not successfully challenged.

IPR2023-00367 — {Petitioner} v. Dynapass IP Holdings, LLC

• Type: Inter Partes Review
• Filed: 2023-01-09 (estimated based on "Not Instituted" status and typical timelines).
• Status: Not Instituted - Merits.
• Judge panel: Undetermined from public search results without direct PTAB E2E access.
• Petition grounds: Specific grounds and challenged claims are not publicly available without direct access to the petition or institution decision.
• Institution decision: Institution was denied on the merits. Similar to IPR2023-01406, the PTAB found the petitioner did not demonstrate a reasonable likelihood of prevailing.
• Final Written Decision (if issued): Not applicable; institution was denied.
• Settlement / termination: Not applicable.
• Appeal: Undetermined from public search results without direct CAFC docket access.
• Defensive value: Similar to IPR2023-01406, this denial of institution suggests strength for the challenged claims against the specific prior art presented in this petition.

Strategic summary

The PTAB has issued Final Written Decisions in IPR2023-00425 and IPR2023-01331 finding claims of US6993658 unpatentable. Specifically, IPR2023-00425 found claims 1-7 unpatentable. Since US6993658 contains only seven claims (claims 1-7), this implies that all claims of the patent have been canceled by the PTAB in IPR2023-00425. If this is indeed the case and these decisions have not been reversed on appeal, then there are no surviving claims of US6993658. The details for IPR2023-01331, although not explicitly listing claim numbers in the available snippets, further reinforce the unpatentability of claims. The denial of institution in IPR2023-01406 and IPR2023-00367 means that for the specific combinations of claims and prior art presented in those petitions, the PTAB did not find sufficient grounds to institute a trial. However, these denials are likely moot if all claims have been canceled by the Final Written Decisions.

The estoppel landscape under 35 U.S.C. § 315(e)(2) would bar Unified Patents (and any privies) from raising any ground that they raised or reasonably could have raised in IPR2023-00425 and IPR2023-01331 against claims 1-7. For any other defendant, if the claims remain canceled, estoppel is not a primary concern because the claims are no longer patentable. The involvement of Unified Patents in these proceedings signals a defensive aggregator's strategic interest, often indicating a widely asserted patent and a coordinated effort to invalidate it.

Recommended next steps

If you are a defendant facing assertion of US6993658, the primary and most impactful step is to confirm the Final Written Decisions (FWDs) of IPR2023-00425 and IPR2023-01331.

1. Obtain and review FWD for IPR2023-00425: This FWD explicitly found claims 1-7 unpatentable. This is a critical defensive tool.
2. Obtain and review FWD for IPR2023-01331: This FWD also found claims unpatentable, and it is important to verify which claims were addressed and the specific reasoning.
3. Check for Federal Circuit appeals: Given that both IPRs resulted in claims being found unpatentable, the patent owner (Dynapass IP Holdings, LLC) likely appealed these decisions to the Court of Appeals for the Federal Circuit. Check the CAFC docket for case number 25-1222 and any other related appeals from IPR2023-00425 and IPR2023-01331. The disposition of any such appeal would determine the ultimate patentability status of the claims. If the PTAB's decisions are affirmed, the claims remain canceled. If reversed, they could be reinstated.
4. Confirm claim status: Based on the FWDs, specifically IPR2023-00425 canceling claims 1-7, it appears all claims of US6993658 have been found unpatentable. If this is confirmed and upheld on appeal, any demand letter or infringement theory based on this patent would be entirely baseless.
5. Strategy for ongoing litigation: If the claims are canceled, notify the asserting party and the relevant district court of the PTAB decisions and any CAFC appellate outcomes. This could lead to a quick dismissal of any active litigation.

Inventors

• Sten-Olov Engberg: Employed by April System Design AB at the time of filing.
• Ake Jonsson: Employed by April System Design AB at the time of filing.

This is inferred from the immediate assignment of the patent from the inventors to April System Design AB on June 19, 2000, shortly after the patent's filing date of March 6, 2000 (Reel 008064/0313).

Original assignee

The original assignee named on the issued patent is April System Design AB.

April System Design AB was a Swedish IT and security solutions company. Public records indicate the company was registered in Sweden in 1999 and subsequently dissolved in 2002. It is not clear whether they shipped a product directly embodying the specific claims of US6993658, but they were an operating company in the security sector. Their current status is dissolved.

Assignment timeline

• 2000-06-19 (executed) / recorded 2000-06-21 — Reel 008064/0313

  • Conveyance: ASSIGNMENT OF ASSIGNORS INTEREST
  • Assignor: ENGBERG, STEN-OLOV, JONSSON, AKE
  • Assignee: APRIL SYSTEM DESIGN AB
  • Correspondent: BROWDY AND NEIMARK, P.C., 624 9TH STREET, N.W., WASHINGTON, D.C. 20001.
  • Context: Original assignment from the inventors to the initial assignee.

• 2011-11-14 (executed) / recorded 2011-11-23 — Reel 026851/0090

  • Conveyance: ASSIGNMENT OF ASSIGNORS INTEREST
  • Assignor: APRIL SYSTEM DESIGN AB
  • Assignee: DYNAPASS INC.
  • Correspondent: HAHN LOESER & PARKS, LLP, 1225 EYE STREET, N.W., SUITE 600, WASHINGTON, D.C. 20005.
  • Context: Transfer from the dissolved original assignee to a new entity, Dynapass Inc.

• 2014-02-21 (executed) / recorded 2014-02-28 — Reel 031448/0647

  • Conveyance: CHANGE OF NAME
  • Assignor: DYNAPASS, INC.
  • Assignee: DYNAPASS, INC.
  • Correspondent: HAHN LOESER & PARKS, LLP, 1225 EYE STREET, N.W., SUITE 600, WASHINGTON, D.C. 20005. This correspondent recurred in this chain.
  • Context: Formal update or change of address for Dynapass Inc.

• 2022-01-02 (executed) / recorded 2022-01-13 — Reel 050077/0001

  • Conveyance: ASSIGNMENT OF ASSIGNORS INTEREST
  • Assignor: DYNAPASS, INC.
  • Assignee: DYNAPASS IP HOLDINGS LLC
  • Correspondent: STEPHEN G. ELGABLY, ESQ., 1700 W. HILLSBORO BLVD., SUITE B200, DEERFIELD BEACH, FL 33442.
  • Context: Transfer from Dynapass Inc. to Dynapass IP Holdings LLC, indicating a potential shell-entity transfer.

Timeline diagram

timeline
    title Ownership of US 6993658
    2000 : Filed by April System Design AB
         : Inventors to April System Design AB
    2006 : Patent Issued
    2011 : Assigned to Dynapass Inc
    2014 : Dynapass Inc name update
    2022 : Assigned to Dynapass IP Holdings LLC
    2023 : First IPR filed
    2024 : IPRs issue Final Written Decisions

NPE / troll-pattern signals

1. Shell-entity transfer — Present. The assignment from "DYNAPASS, INC." to "DYNAPASS IP HOLDINGS LLC" on 2022-01-02 / recorded 2022-01-13 (Reel 050077/0001) is a strong indicator. The "IP Holdings" suffix typically signifies a non-operating, licensing-focused entity, and Dynapass IP Holdings LLC has acted as a plaintiff in multiple patent infringement lawsuits.

2. Known asserter in the chain — Present. Dynapass IP Holdings LLC, the current assignee, is identified as the plaintiff in several district court cases (e.g., Dynapass IP Holdings LLC v. Wells Fargo & Co. and Wells Fargo Bank, N.A., 2:22-cv-00217; Dynapass IP Holdings, LLC v. Simmons First National Corporation and Simmons Bank, 2:23-cv-00068). Furthermore, Unified Patents, a defensive aggregator, initiated IPRs against Dynapass IP Holdings, LLC, which is a common practice when dealing with NPEs.

3. Repeat correspondent across the chain — Present. HAHN LOESER & PARKS, LLP served as the correspondent for both the 2011-11-14 assignment to Dynapass Inc. (Reel 026851/0090) and the 2014-02-21 change of name for Dynapass, Inc. (Reel 031448/0647).

4. Cascading transfers — Not present. The assignments are spaced over several years (2000, 2011, 2014, 2022), not within a short timeframe.

5. Pre-litigation transfer — Present. The assignment to DYNAPASS IP HOLDINGS LLC was executed on 2022-01-02 and recorded on 2022-01-13 (Reel 050077/0001). The earliest identified litigation, Dynapass IP Holdings LLC v. Wells Fargo & Co. and Wells Fargo Bank, N.A. (Case Number: 2:22-cv-00217), was filed on June 17, 2022. This falls within a six-month window, suggesting the transfer was likely in preparation for the subsequent litigation.

6. Bankruptcy fire-sale — Unclear. While the original assignee, April System Design AB, was dissolved in 2002, the patent transfer to Dynapass Inc. occurred much later in 2011 (Reel 026851/0090). It is possible the dissolution involved asset disposition, but the recorded assignment itself does not explicitly state it was due to bankruptcy proceedings.

7. Privateering — Unclear. There is no direct evidence from the assignment records or available information that April System Design AB transferred the patent to Dynapass IP Holdings LLC to assert against its competitors.

8. Defensive aggregator (anti-NPE) — Not present. The current assignee, Dynapass IP Holdings LLC, is an asserting entity, not a defensive aggregator.

Verdict

NPE — high confidence

This verdict is strongly supported by the assignment of the patent to "Dynapass IP Holdings LLC" (Reel 050077/0001), an entity whose name, along with its extensive litigation history as plaintiff, clearly indicates a non-practicing entity. Furthermore, this transfer occurred within six months prior to the filing of the first documented infringement lawsuit (2:22-cv-00217), a strong signal of pre-litigation asset arrangement. The recurrence of HAHN LOESER & PARKS, LLP as correspondent (Reel 026851/0090 and Reel 031448/0647) also points to specialized legal counsel often associated with patent assertion entities.

For verification of assignment records, refer to the USPTO Assignment Center: https://assignmentcenter.uspto.gov/

The most relevant prior art for US patent 6993658, as detailed in the patent document itself, focuses on authentication systems. While the patent text mentions the SecurID product by RSA Security Inc. as related art, it distinguishes itself by utilizing personal communication devices (mobile phones or pagers) for token delivery, rather than a dedicated SecurID card.

Based on the publicly available information, a direct list of prior art citations within US patent 6993658 for anticipation analysis (35 U.S.C. § 102) would require accessing the full USPTO file wrapper for the patent, which is beyond the scope of this tool. However, the PTAB proceedings (specifically IPR2023-00425) indicate prior art references that were successfully used to challenge the patent's claims.

Here's an overview of the prior art mentioned in relation to the PTAB challenge against US6993658:

• US Patent 6,052,789 (Abadi)

  • Publication/Filing Date: While the exact filing date isn't immediately available, the publication date of US Patent 6,052,789 is April 18, 2000.
  • Brief Description: This patent likely describes aspects of computer security or authentication systems, given its use in challenging a two-factor authentication patent.
  • Potentially Anticipates Claim(s): Claims 1-7 of US6993658B1. The Patent Trial and Appeal Board (PTAB) found a reasonable likelihood that claims 1-7 are unpatentable under 35 U.S.C. § 103 (obviousness) over combinations of prior art, including Abadi. While the specific anticipation arguments under § 102 are not explicitly detailed in the public snippets, its inclusion in the obviousness challenge indicates its relevance to the core inventive concepts of US6993658.

• US Patent Application Publication 2002/0069363 (Monk)

  • Publication/Filing Date: The publication date for US Patent Application Publication 2002/0069363 is June 6, 2002.
  • Brief Description: Similar to Abadi, this reference likely describes technology related to authentication or secure communication, contributing to the obviousness arguments against US6993658.
  • Potentially Anticipates Claim(s): Claims 1-7 of US6993658B1. The PTAB considered Monk in its finding that claims 1-7 were likely unpatentable under 35 U.S.C. § 103.

Note on Anticipation (35 U.S.C. § 102) vs. Obviousness (35 U.S.C. § 103):
Anticipation under § 102 requires that every element of a claim be found, either explicitly or inherently, in a single prior art reference. Obviousness under § 103 allows for combining multiple prior art references to demonstrate that the claimed invention would have been obvious to a person of ordinary skill in the art. The PTAB's findings in IPR2023-00425 indicate that claims 1-7 were found unpatentable as obvious over combinations of prior art including Abadi and Monk, rather than explicitly anticipated by a single reference. A full anticipation analysis would require a detailed claim-by-claim comparison against the complete text of each prior art document.

Additional Information from the Patent Description Regarding Related Art:

The patent itself describes the existing state of the art, which provides context for its novelty:

• Traditional User ID and Password Systems: The patent notes that secure systems traditionally used a user ID and password pair for authentication, often leading to issues with easy-to-guess passwords or users writing down complex passwords.
• SecurID product by RSA Security Inc.: The patent acknowledges the SecurID product as a two-factor authentication process involving a user passcode (first factor) and a SecurID card (second factor) that generates unpredictable, one-time access codes. The patent distinguishes itself by aiming to achieve similar benefits using a device users already carry, such as a mobile phone or pager, instead of a dedicated SecurID card.

To conduct a comprehensive anticipation analysis, the full text of US patent 6,052,789 (Abadi) and US Patent Application Publication 2002/0069363 (Monk), along with any other prior art cited by the examiner during prosecution or by the petitioners in the IPRs, would need to be thoroughly reviewed against each element of claims 1-7 of US6993658.

Obviousness Analysis under 35 U.S.C. § 103 for US Patent 6,993,658

Under 35 U.S.C. § 103, a patent claim is unpatentable if "the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains." The analysis typically involves considering: (1) the scope and content of the prior art; (2) the differences between the prior art and the claims at issue; (3) the level of ordinary skill in the pertinent art; and (4) secondary considerations of nonobviousness (e.g., commercial success, long-felt need, failure of others).

The "Prior Art" and "PTAB challenges" sections indicate that all claims (1-7) of US Patent 6,993,658 were found unpatentable under 35 U.S.C. § 103 as obvious during Inter Partes Review (IPR) proceeding IPR2023-00425. This outcome, if upheld on appeal, is highly persuasive evidence of obviousness.

Identified Combinations of Prior Art and Motivation to Combine

The PTAB's institution decision for IPR2023-00425 found a reasonable likelihood that claims 1-7 of US6993658B1 are unpatentable as obvious over various combinations of prior art, specifically mentioning:

• US Patent 6,052,789 (Abadi)
• US Patent Application Publication 2002/0069363 (Monk)
• Other unnamed references.

While the full text of Abadi and Monk is not available here, the patent itself, in its "Background of the Invention," clearly sets forth the problem that a person having ordinary skill in the art (PHOSITA) would have been motivated to solve: the inconvenience of carrying a dedicated security token like the SecurID card. The patent states: "The SecurID product, however, requires users to carry an additional item on their person in order to access a secure system. It would be advantageous if the benefits of the SecurID system could be achieved using a device that many users already carry—a personal communication device such as a mobile phone or a pager."

This statement provides the explicit motivation for a PHOSITA, at the time of the invention (priority date March 6, 2000), to combine known two-factor authentication schemes with ubiquitous personal communication devices.

Obviousness Combination: Abadi in view of Monk (and general knowledge of SecurID and personal communication devices)

A PHOSITA would be motivated to combine the teachings of Abadi (presumed to teach core aspects of a secure authentication system, possibly involving tokens or multi-factor authentication) and Monk (presumed to teach aspects of authentication or secure communication, potentially involving external devices or network interactions) for the following reasons:

1. Known Problem: The problem of users having to carry separate, dedicated authentication devices (like the SecurID card) was well-recognized in the art, as explicitly stated in US6993658B1 itself.
2. Existing Solutions: Systems like SecurID offered robust two-factor authentication, utilizing "something you know" (passcode) and "something you have" (the card generating a token).
3. Advancements in Communication Technology: Around the priority date of US6993658 (March 6, 2000), personal communication devices like mobile phones and pagers were becoming increasingly common and sophisticated, capable of receiving text messages (e.g., SMS). A PHOSITA would readily recognize these devices as a convenient "something you have" that users already carry.
4. Foreseeable Substitution/Combination: Given the desire to eliminate a dedicated hardware token, it would have been obvious for a PHOSITA to adapt an existing two-factor authentication method (as might be taught by Abadi or Monk individually, or in combination with general knowledge of SecurID-like systems) to leverage the ubiquitous personal communication devices for token delivery. Replacing a dedicated token generator with a personal communication device that receives a token from a server would be a logical step to improve user convenience without sacrificing the core security benefits of two-factor authentication.

Applying the Combination to Independent Claims:

Given the PTAB's finding of obviousness for claims 1-7, it is highly probable that the combination of Abadi and Monk (and potentially other unnamed references or general knowledge) would teach or suggest all elements of independent claims 1 and 5:

• Claim 1 (Method of Authentication):

  • Associating user with personal communication device (PCD) over a second network: It would be obvious to associate a user's account with their mobile phone number or pager number for communication purposes, as these were common practices for alerts and messaging.
  • Receiving a request for a token via PCD over the second network: Mobile phones and pagers were capable of sending requests (e.g., by making a call, sending an SMS) and receiving data (e.g., caller ID, SMS).
  • Generating a new password based on token and passcode: Standard practice in two-factor authentication, exemplified by SecurID, combined a memorized passcode with a dynamically generated token. The method of combining them (e.g., concatenation) would also be obvious.
  • Setting the new password & activating/deactivating access: These are standard administrative functions in secure computer networks, easily integrated with a token-based system. The idea of time-limited access or tokens was also known in the art (e.g., SecurID tokens changing every 60 seconds).
  • Transmitting the token to the PCD: Utilizing a cell phone network (the second network) to send an SMS message or a pager message to a user's device to deliver a token would have been an obvious application of existing communication technologies.
  • Receiving the password from the user via the first secure computer network: This is a fundamental step in any authentication process for a secure computer network.

• Claim 5 (User Authentication System):

  • The system elements (computer processor, user database, control module, communication module, authentication module) are standard components for implementing authentication schemes and network communications.
  • The functionality described in Claim 5 directly maps to the method steps of Claim 1. A PHOSITA, seeking to implement the method of Claim 1, would design a system with these components, integrating existing communication modules (e.g., an SMS modem or an ISDN card as described in the patent itself) to communicate with the personal communication device via a cellular network. The communication module being "configured to transmit the token to the personal communication device through the cell phone network" is the direct implementation of the solution to the "additional item" problem.

Conclusion on Obviousness:

Based on the available information and the explicit problem statement within US6993658B1, a PHOSITA would have been motivated to combine known two-factor authentication principles (e.g., as embodied by the SecurID product or references like Abadi and Monk) with widely available personal communication technologies (mobile phones, pagers, SMS) to improve user convenience by eliminating the need for a separate hardware token. The PTAB's Final Written Decisions finding claims 1-7 unpatentable under 35 U.S.C. § 103 strongly support this obviousness assessment.

For US patent 6993658 (US6993658B1), here are the details regarding its term and related applications:

Patent Term Adjustments (PTA) and Patent Term Extensions (PTE):

• Patent Term Adjustment (PTA): US patent 6993658 was filed on March 6, 2000, which makes it subject to the Patent Term Adjustment provisions established by the American Inventors Protection Act of 1999. PTA compensates for delays caused by the USPTO during the prosecution of a patent application, such as failing to issue a first office action within 14 months or failing to issue a patent within three years of the filing date. To determine the exact PTA granted for US6993658B1, one would typically need to examine the patent's file wrapper on the USPTO's Patent Center. The USPTO automatically determines and provides notice of PTA no later than the patent's issuance date. However, information on specific PTA for this patent is not available in the provided search results.
• Patent Term Extension (PTE): PTEs are granted for patents on certain human drugs, food or color additives, medical devices, animal drugs, and veterinary biological products to restore time lost during premarket government approval from a regulatory agency. Given the subject matter of US6993658B1 (user authentication), it is highly unlikely to be eligible for a Patent Term Extension under 35 U.S.C. § 156.

Continuation and Divisional Applications:

• Continuation and Divisional Applications: A patent granted on a continuation, divisional, or continuation-in-part application that was filed on or after June 8, 1995, will generally have a term that ends twenty years from the filing date of the earliest application for which a benefit is claimed under 35 U.S.C. 120, 121, 365(c), or 386(c). The provided information for US6993658B1 lists its application number as US09/519,829, filed on March 6, 2000. However, the search results do not explicitly indicate if US6993658B1 itself is a continuation or divisional of an earlier U.S. application, nor do they list any later-filed continuation or divisional applications directly claiming priority to US09/519,829.

Related Family Members:

• Worldwide Applications (Priority Applications): US6993658B1 claims priority to the U.S. application US09/519,829, filed on March 6, 2000. It also has the following related priority applications:
  • PCT/US2001/007058: Filed on March 6, 2001, with a legal status of "Ceased".
  • AU2001245448A: Filed on March 6, 2001, with a legal status of "Abandoned".

Projected Expiration Date:

• Standard Term Calculation: Generally, the term of a U.S. utility patent issued from an application filed on or after June 8, 1995, is 20 years from its earliest effective filing date. US6993658B1's application filing date is March 6, 2000. Therefore, without any adjustments or extensions, the patent's term would typically end 20 years from this date.
• Anticipated Expiration: Google Patents lists the "Anticipated expiration" date as March 6, 2020. This date aligns with a 20-year term from the filing date of March 6, 2000, assuming no PTA or PTE were granted.
• Legal Status: Google Patents explicitly states the "Legal status" of US6993658B1 as "Expired - Lifetime". This confirms that the patent is no longer in force.
• Conclusion: The patent US6993658B1 expired on March 6, 2020.

Defensive Disclosure: Derivatives of US Patent 6,993,658

This document outlines various derivative concepts extending the core teachings of US Patent 6,993,658, aimed at establishing prior art for future incremental improvements in user authentication systems leveraging personal communication devices. The objective is to render such improvements obvious or non-novel, thereby limiting the patentability landscape for competitors.

Core Claims for Derivation

The primary focus for these derivations is on the independent claims of US6993658, specifically:

• Claim 1 (Method): A method of authenticating a user on a first secure computer network, associating the user with a personal communication device (PCD) on a second network, receiving a token request via the PCD, generating a new password from a token (unknown to user) and a passcode (known to user), setting the new password, activating/deactivating account access within a predetermined time, transmitting the token to the PCD, and receiving the password from the user via the first network.
• Claim 5 (System): A user authentication system comprising a computer processor, a user database, a control module to create/set a new password from a token and passcode, a communication module to transmit the token to a PCD via a cell phone network, and an authentication module to receive the password, activate/deactivate account access within a predetermined time.

The following derivatives expand upon these core concepts across five axes: Material & Component Substitution, Operational Parameter Expansion, Cross-Domain Application, Integration with Emerging Tech, and The "Inverse" or Failure Mode.

---

Derivative Variations for User Authentication System/Method

1. Material & Component Substitution

Derivative 1.1: Authentication via Satellite Communication Device

• Enabling Description: The personal communication device (PCD) is substituted with a satellite communication handset or a satellite modem integrated into a portable terminal. The "second network" is a satellite constellation (e.g., Iridium, Globalstar, Starlink) providing global coverage. The communication module on the authentication server side uses a satellite transceiver unit (e.g., an L-band or Ku-band modem) connected via a ground station to send the token as a short burst data (SBD) message or a proprietary satellite messaging format. The user requests a token by sending an SBD message, and the server identifies the user by the satellite terminal's unique identifier (e.g., IMEI or a registered SATCOM ID) received with the incoming SBD message. The new password is formed by concatenating the user's secret passcode with the received satellite-delivered token.

flowchart TD
    A[User] --> B{Satellite Comm. Device};
    B -- Token Request (SBD Message) --> C[Satellite Constellation];
    C -- Relays Request --> D[Satellite Ground Station];
    D -- Forwards Request --> E[Authentication Server];
    E -- Generates Token & New Password --> E;
    E -- Sends Token (SBD Message) --> D;
    D -- Relays Token --> C;
    C -- Delivers Token --> B;
    B -- User Combines Passcode & Token --> A;
    A -- Submits New Password --> F[Secure System];
    F -- Authenticates User --> E;

Derivative 1.2: Authentication with Near-Field Communication (NFC) Enabled Wearable Device

• Enabling Description: The personal communication device is a wearable smart device (e.g., smartwatch, smart ring) equipped with an NFC chip. The "second network" is a local NFC field established by a proximity reader integrated into the secure system's access point or a dedicated communication module. The token is transmitted to the wearable device via a secure NFC handshake. The user requests a token by tapping their wearable device on the NFC reader. The system identifies the user through a pre-registered unique identifier associated with the wearable device's NFC chip. The new password is a combination of the user's passcode and the NFC-delivered token. For login, the user taps the device again, and the combined password (passcode+token, generated client-side or retrieved from the wearable) is submitted.

sequenceDiagram
    participant U as User
    participant W as Wearable Device (NFC)
    participant A as NFC Reader (Auth Server)
    participant S as Secure System

    U->W: Wearable on user
    U->A: Tap W to A (Token Request)
    A->A: Identify W via NFC ID
    A->A: Generate Token
    A->W: Transmit Token via NFC
    U->W: Receive Token
    U->U: Mentally combine passcode + token
    U->S: Submit Passcode + Token
    S->A: Validate Authentication
    A->S: Grant Access Confirmation

Derivative 1.3: Authentication Using a Public-Key Cryptography (PKC) Hardware Token

• Enabling Description: The personal communication device is replaced by a standardized PKC hardware token (e.g., a FIDO U2F security key or a smart card with a cryptographic coprocessor) which is capable of generating or holding cryptographic keys. The "second network" involves a direct USB or Bluetooth connection to the client device, which then relays the information to the authentication server over the main network. The server generates a random challenge (token) and transmits it to the PKC hardware token. The hardware token uses its private key to sign the challenge, and this signature (the "new password") is transmitted back to the server. The user's "passcode" in this context is the PIN/biometric required to unlock the hardware token. The server verifies the signature using the associated public key. Activation and deactivation of access are tied to the validity of the signed challenge and the hardware token's presence.

flowchart TD
    U[User] --> H{PKC Hardware Token};
    H -- USB/Bluetooth -- C[Client Device];
    C -- Challenge Request --> S[Auth Server];
    S -- Generates Random Challenge (Token) --> S;
    S -- Sends Challenge --> C;
    C -- Forwards Challenge --> H;
    U -- Enters PIN/Biometric --> H;
    H -- Signs Challenge with Private Key --> H;
    H -- Transmits Signature (Password) --> C;
    C -- Forwards Signature --> S;
    S -- Verifies Signature with Public Key --> S;
    S -- Activates/Deactivates Access --> D[User Database];
    S -- Grants Access --> R[Secure Resource];

2. Operational Parameter Expansion

Derivative 2.1: Nanoscale Device Authentication for Distributed Sensor Networks

• Enabling Description: The secure system comprises a distributed network of nanoscale sensors (e.g., for environmental monitoring within a confined space or in a biological system). Each sensor requires periodic re-authentication. The "user" is a maintenance or control agent, and their "personal communication device" is a specialized handheld nanodevice interface unit that communicates via quantum entanglement or highly localized terahertz frequencies. Tokens are generated for each individual sensor or small clusters. The token lifespan is extremely short (milliseconds to seconds) due to the transient nature of sensor data and potential rapid compromise. The token and passcode (a cryptographic seed known to the nanodevice interface) are used to generate a unique, short-lived session key for data transmission. Deactivation occurs immediately upon session completion or data burst transmission.

graph LR
    A[Nanodevice Interface Unit (PCD)] -- THz/Quantum Link --> B{Nanoscale Sensor Node};
    B -- Token Request --> C[Authentication & Control Server (Micro)];
    C -- Generates Nano-Token & Session Key --> C;
    C -- Delivers Nano-Token --> B;
    B -- Combines Token + Seed (Passcode) --> B;
    B -- Generates Session Key --> B;
    B -- Authenticates to Data Store --> D[Secure Data Store];
    D -- Grants/Revokes Access --> B;

Derivative 2.2: Hyperscale, Continuous Authentication for Cloud-Native Microservices

• Enabling Description: The "first secure computer network" is a hyperscale, globally distributed cloud environment hosting millions of ephemeral microservices. The "user" is an automated CI/CD pipeline or a service mesh component requiring continuous, granular authorization. The "personal communication device" is a dedicated, ephemeral sidecar proxy or an enclave within the microservice instance. The "second network" is a highly secure, high-throughput internal cloud network fabric. Tokens (often short-lived JSON Web Tokens - JWTs) are requested and issued every few seconds or on-demand for specific API calls, with passcodes being cryptographic keys securely managed within the enclaves. The authentication server dynamically adjusts token lifespan and scope based on real-time threat intelligence and service behavior anomalies. Deactivation is implicit with JWT expiration, enforced by policy enforcement points.

sequenceDiagram
    participant M as Microservice Instance (PCD)
    participant C as Control Plane (Auth Server)
    participant D as Data Plane (Secure Network)

    loop Continuous Authentication
        M->C: Automated Token Request (API Key as Passcode)
        C->C: Risk Assessment & Token Generation (JWT)
        C->M: Deliver JWT (Token)
        M->D: Submit JWT for API Call
        D->C: Validate JWT
        C->D: Confirm/Deny Access
        M->D: Perform API Call (if granted)
    end

Derivative 2.3: Ultra-Low Frequency (ULF) Authentication for Subterranean/Underwater Infrastructure

• Enabling Description: The secure system is critical infrastructure located deep underground or underwater, requiring access authentication in challenging communication environments. The "user" is a specialized maintenance technician or autonomous underwater vehicle (AUV). The "personal communication device" is a ruggedized ULF transceiver. The "second network" operates on Ultra-Low Frequencies (300 Hz to 3 kHz) or extremely low frequencies (ELF) to penetrate rock and water over long distances. The communication module on the server side is a massive ULF antenna array. Tokens are generated as short, binary ULF pulse sequences. Passcodes might be pre-shared keys or physical parameters entered on the ULF transceiver. Due to extremely low bandwidth, tokens are simple bit strings, and transmissions are slow. Deactivation occurs within hours or days, considering the long intervals between human or AUV presence.

flowchart TD
    U[Technician/AUV] --> T{ULF Transceiver (PCD)};
    T -- ULF Token Request --> A[ULF Antenna Array];
    A -- Data Link --> S[Authentication Server];
    S -- Generates ULF Token --> S;
    S -- Delivers ULF Token --> A;
    A -- ULF Token Delivery --> T;
    T -- Combines Passcode & Token --> T;
    T -- Submits ULF Password --> I[Subterranean/Underwater Infrastructure];
    I -- Verifies Password --> S;
    S -- Grants/Revokes Access --> I;

3. Cross-Domain Application

Derivative 3.1: Maritime Vessel Access Control

• Enabling Description: The secure system is a critical control panel or engine room access point on a maritime vessel. The "user" is a crew member. The "personal communication device" is a ruggedized satellite phone or an onboard radio (VHF/UHF) with data messaging capabilities. The "second network" is either a maritime satellite network or a short-range vessel-specific data radio network. The authentication server is located either onshore or on the vessel's bridge. A token request is sent from the crew member's device (e.g., an SMS over satellite or a secure data burst over VHF). The server generates a token, combines it with a crew-specific passcode, and sends it back. The crew member then enters the combined password on the vessel's control panel to gain access. Access is automatically deactivated after a shift or for certain restricted areas after a short period.

sequenceDiagram
    participant C as Crew Member
    participant S as Sat Phone/VHF Radio (PCD)
    participant N as Maritime Sat/VHF Network
    participant A as Authentication Server (Onshore/Bridge)
    participant V as Vessel Control Panel (Secure System)

    C->S: Token Request
    S->N: Transmit Request
    N->A: Forward Request
    A->A: Generate Token + New Password (Passcode)
    A->N: Deliver Token
    N->S: Transmit Token
    S->C: Receive Token
    C->V: Input New Password
    V->A: Authenticate
    A->V: Grant/Deny Access

Derivative 3.2: Agricultural Field Equipment Authorization

• Enabling Description: The secure system is an agricultural autonomous tractor or a high-value farming implement, requiring authorization for operation or specific functions. The "user" is a farm operator or an agronomist. The "personal communication device" is a robust smartphone or a dedicated ruggedized tablet with LoRaWAN or private 5G cellular capabilities. The "second network" is a farm-specific LoRaWAN network or a private cellular network covering the agricultural fields. The authentication server could be a local farm server or a cloud-based agricultural management platform. A token request is sent via the device. The server generates a token based on the user's passcode and sends it to the device. The operator then enters the combined password (e.g., on the tractor's console) to start or enable a particular function (e.g., seeding, spraying). Access is time-limited to a specific operational window.

graph TD
    A[Farm Operator (User)] --> B{Ruggedized Tablet (PCD)};
    B -- Token Request (LoRaWAN/Private 5G) --> C[Farm Network (Second Network)];
    C -- Relays Request --> D[Farm/Cloud Auth Server];
    D -- Generates Token & Combines with Passcode --> D;
    D -- Sends Token --> C;
    C -- Delivers Token --> B;
    B -- Displays Token --> A;
    A -- Inputs Password (Passcode+Token) --> E[Autonomous Tractor/Implement (Secure System)];
    E -- Authenticates --> D;
    D -- Grants Operational Access --> E;
    E -- Deactivates after Time Limit --> D;

Derivative 3.3: Space-Based Asset Control (Satellite/Probe Access)

• Enabling Description: The secure system is a sensitive control interface for a satellite, space probe, or orbital asset. The "user" is a ground station operator. The "personal communication device" is a hardened ground station terminal capable of communicating over a secure space-to-ground data link (e.g., S-band, X-band). The "second network" is the deep space network or a proprietary satellite communication network. The authentication server is located at the mission control center. A token request is sent from the terminal to the authentication server. The server generates a token (which could be a segment of an encryption key or a specific command sequence) and transmits it back to the ground terminal. The operator then concatenates this token with a mission-specific passcode and inputs it into the space asset command console. Access to critical commands is activated for a very short, specific window and then immediately deactivated.

sequenceDiagram
    participant O as Ground Station Operator
    participant T as Hardened Terminal (PCD)
    participant D as Deep Space Network
    participant A as Mission Control Auth Server
    participant S as Space Asset Command Console (Secure System)

    O->T: Initiate Token Request
    T->D: Transmit Request (Secure Link)
    D->A: Relay Request
    A->A: Generate Token (Key Segment) & New Command (Passcode)
    A->D: Deliver Token
    D->T: Relay Token
    T->O: Display Token
    O->S: Input New Command Sequence (Passcode+Token)
    S->A: Authenticate Command
    A->S: Authorize/Reject Command

4. Integration with Emerging Tech

Derivative 4.1: AI-Driven Adaptive Token Authentication with User Behavioral Biometrics

• Enabling Description: The user authentication system integrates an AI-driven risk engine. Upon a token request from the personal communication device (PCD), the AI analyzes contextual data (e.g., user's usual login patterns, geographic location of the PCD, time of day, network used, recent past authentications). It also incorporates passive behavioral biometrics (e.g., typing cadence, swipe patterns) collected by the PCD and sent with the request. The AI dynamically generates a token of variable complexity and lifespan. If risk is low, a short, long-lifespan token is issued. If risk is high, a complex, very short-lifespan token, or even a multi-token sequence, is generated, potentially requiring additional "passcodes" (e.g., a biometric on the PCD). The authentication module's acceptance criteria for the combined password are also dynamically adjusted by the AI based on the real-time risk score.

stateDiagram
    [*] --> InitialRequest: User requests token
    InitialRequest --> AI_RiskAssessment: Send contextual/behavioral data
    AI_RiskAssessment --> LowRisk: If risk score < threshold
    AI_RiskAssessment --> HighRisk: If risk score >= threshold
    LowRisk --> GenerateSimpleToken: Short, long-lifespan token
    HighRisk --> GenerateComplexToken: Complex, short-lifespan, multi-token
    GenerateSimpleToken --> TokenDelivery: Deliver token
    GenerateComplexToken --> TokenDelivery: Deliver token
    TokenDelivery --> UserInput: User combines & inputs password
    UserInput --> AI_AuthDecision: Authenticate with adaptive criteria
    AI_AuthDecision --> AccessGranted: If authenticated
    AI_AuthDecision --> AccessDenied: If failed
    AccessGranted --> [*]
    AccessDenied --> InitialRequest: Retry

Derivative 4.2: IoT-Triggered Contextual Authentication via Ultra-Wideband (UWB) Proximity

• Enabling Description: The secure system is an IoT device (e.g., a smart lock, industrial sensor controller). The "user" carries a personal communication device (e.g., a smartphone) equipped with Ultra-Wideband (UWB) capabilities. The "second network" is a short-range, secure UWB link to the IoT device. Authentication is contextually triggered: when the user's PCD is within a precise, pre-defined UWB proximity zone of the IoT device, the IoT device (acting as the communication module/requestor) automatically initiates a token request to a local edge authentication server. The server generates a token (e.g., a time-based one-time password, TOTP-like string) and pushes it as an ephemeral notification to the user's PCD. The user then enters their passcode plus the UWB-received token into a virtual keypad on the PCD or directly into the IoT device if it has an interface. Deactivation is automatic upon loss of UWB proximity or after a short operational window.

flowchart TD
    U[User] --> P{Smartphone (PCD) with UWB};
    P -- UWB Proximity Detection --> I[IoT Device (Secure System)];
    I -- Auto-Token Request --> E[Edge Auth Server];
    E -- Generates Token & Combines with Passcode --> E;
    E -- Pushes Token Notification --> P;
    P -- User Enters Password (Passcode+Token) --> I;
    I -- Authenticates --> E;
    E -- Grants IoT Access --> I;
    I -- Deactivates on UWB Loss --> P;

Derivative 4.3: Blockchain-Verified Token Delivery and Decentralized Access Control

• Enabling Description: The user authentication system integrates a private or consortium blockchain for immutable record-keeping and decentralized validation of token transactions. When a token request is received from a personal communication device (PCD), the authentication server generates a token and records the token, its intended recipient, and its expiry on the blockchain as a transaction. Instead of directly transmitting the token, the server transmits a cryptographic proof of the token's existence on the blockchain to the PCD. The user, upon receiving this proof and their passcode, constructs the password. When submitting the password to the secure system, the secure system (or a delegated node) independently queries the blockchain to verify the token's validity and associated user, ensuring integrity and non-repudiation. Smart contracts can govern token generation frequency and deactivation.

sequenceDiagram
    participant U as User
    participant P as Personal Comm Device
    participant A as Auth Server
    participant B as Blockchain Network
    participant S as Secure System

    U->P: Request Token
    P->A: Forward Token Request
    A->A: Generate Token
    A->B: Record Token details (hash, expiry, recipient) in transaction
    B->A: Confirm Transaction (Proof)
    A->P: Transmit Token Proof (e.g., transaction hash)
    P->U: Receive Token Proof
    U->U: Combine Passcode + Token (reconstructed via proof/local cache)
    U->S: Submit Password + Token Proof
    S->B: Verify Token details on Blockchain
    B->S: Confirm Token Validity
    S->S: Validate Password locally
    S->A: Notify Auth Server of login
    A->S: Grant/Deny Access Confirmation

5. The "Inverse" or Failure Mode

Derivative 5.1: Fail-Safe Limited Functionality Mode with Emergency Override

• Enabling Description: In situations where the personal communication device (PCD) is lost, damaged, or cannot connect to the "second network," the system enters a "fail-safe limited functionality mode." Upon a token request initiated directly at the "first secure computer network" (e.g., via an emergency console), the authentication server attempts to deliver a highly restricted, single-use, time-limited token to a pre-registered backup channel (e.g., a landline phone via voice synthesis, a trusted administrative terminal, or an encrypted email to a verified address). The passcode for this mode would be a separate, longer emergency passcode known only to the user. This combined "emergency password" grants only "read-only" access, diagnostic capabilities, or a critical minimum set of functions. Full access remains deactivated. Additionally, a physical, biometric-enabled emergency override mechanism (e.g., retina scan or fingerprint) directly at the secure system can grant temporary, monitored access without any token if the user's identity is verified by other means, triggering extensive auditing and alerts.

stateDiagram
    [*] --> NormalOperation: Regular authentication
    NormalOperation --> PCD_Unavailable: PCD lost/damaged/offline
    PCD_Unavailable --> RequestEmergencyToken: User requests token at Secure System
    RequestEmergencyToken --> AuthServer: Attempts backup delivery
    AuthServer --> BackupChannel: Deliver limited token (e.g., voice call)
    BackupChannel --> User: User retrieves token
    User --> SecureSystem: User inputs Emergency Passcode + Limited Token
    SecureSystem --> LimitedAccess: Grants read-only or critical functions
    LimitedAccess --> AuditLog: Extensive logging of activity
    LimitedAccess --> NormalOperation: Revert once PCD is restored/full auth
    PCD_Unavailable --> EmergencyBiometricOverride: Direct biometric scan at Secure System
    EmergencyBiometricOverride --> SecureSystem: Verifies biometric
    SecureSystem --> LimitedAccess: Grants temporary, monitored access

Derivative 5.2: Self-Destructing Tokens on Malicious Activity Detection

• Enabling Description: The system incorporates a real-time threat detection module that monitors login attempts and personal communication device (PCD) activity. If a predefined pattern of malicious activity is detected (e.g., multiple failed login attempts with the same token from different IP addresses, simultaneous login attempts from vastly separated geographical locations, or unauthorized access to the PCD itself triggering an alert), the currently valid token for that user is immediately and irrevocably revoked/invalidated on the authentication server. The associated user account on the "first secure computer network" is instantly deactivated, preventing any access, and an alert is sent to the user via an alternative secure channel and to security administrators. The token is designed to "self-destruct" server-side, meaning it is purged from memory and cannot be used for any subsequent authentication.

sequenceDiagram
    participant U as User
    participant P as Personal Comm Device
    participant A as Auth Server
    participant T as Threat Detection Module
    participant S as Secure System

    U->P: Request Token
    P->A: Request
    A->A: Generate & Set Token
    A->P: Deliver Token
    P->U: Receive Token
    U->S: Submit Password (Passcode+Token)
    S->A: Authentication Request
    loop Monitoring Login/PCD Activity
        T->S: Monitors login attempts
        T->P: Monitors PCD activity (if applicable)
        alt Malicious Activity Detected
            T->A: Trigger Token Revocation
            A->A: Invalidate/Purge Token
            A->S: Deactivate Account
            A->U: Send Security Alert
            S->S: Access Denied
            break
        end
    end
    S->A: Validate Authentication (if no threat)
    A->S: Grant/Deny Access

Derivative 5.3: Gradual Deactivation with Audit Logging during Grace Period

• Enabling Description: Instead of immediate deactivation, the system implements a "graceful degradation" or "grace period" for deactivating access after the predetermined token lifespan. Once the token's primary validity period expires, the user's account transitions to a "limited access" state for an additional configurable grace period (e.g., 1 hour, 1 day). During this grace period, all actions performed by the user on the "first secure computer network" are subjected to enhanced, real-time audit logging and monitoring. If the user attempts to perform critical actions or exceeds predefined thresholds, the system immediately forces re-authentication (requiring a new token) or fully deactivates the account. The communication module can also send a "soft expiry" notification to the PCD, prompting the user to request a new token before full deactivation.

stateDiagram
    [*] --> ActiveAccount: User authenticated, token valid
    ActiveAccount --> TokenExpired: Predetermined time elapsed
    TokenExpired --> GracePeriod: Limited access, enhanced logging
    GracePeriod --> ForcedReauthentication: User attempts critical action/threshold exceeded
    GracePeriod --> FullDeactivation: Grace period ends (no re-auth)
    ForcedReauthentication --> NewTokenRequired: Prompt for new token
    NewTokenRequired --> ActiveAccount: Successful re-authentication
    NewTokenRequired --> FullDeactivation: Failed re-authentication/no new token
    FullDeactivation --> [*]: Account deactivated
    GracePeriod --> UserNotified: "Soft expiry" notification to PCD

---

Combination Prior Art Scenarios with Open-Source Standards

These scenarios illustrate how the core concepts of US6993658 (using a PCD for token-based authentication with a passcode) could be combined with widely adopted open-source standards, further solidifying the obviousness of such implementations.

1. US6993658 + OAuth 2.0 / OpenID Connect:

   • Enabling Description: An authentication server implements the OAuth 2.0 authorization framework and OpenID Connect (OIDC) for single sign-on. When a user attempts to access a protected resource, they are redirected to the authorization server. If the user's primary authentication method is configured as per US6993658, the authorization server (acting as the user token server) would, in response to the user's initial login attempt or explicit token request, generate a token and send it via SMS (the "second network") to their registered mobile phone (the "personal communication device"). The user then combines this SMS token with their memorized passcode to enter as their password into the authorization server's login form. Upon successful authentication, the authorization server issues an ID Token (OIDC) and/or Access Token (OAuth 2.0) to the client application, allowing access to the "first secure computer network" (the resource server). The token's lifespan and the overall session duration are managed by standard OAuth/OIDC expiry mechanisms.
   • Obviousness Statement: It would be obvious to a person skilled in the art of secure web authentication to integrate a two-factor authentication mechanism, such as that described in US6993658, into an existing OAuth 2.0/OpenID Connect flow to enhance security, leveraging readily available personal communication devices for out-of-band token delivery.

2. US6993658 + FreeRADIUS (for Network Access Control):

   • Enabling Description: The "first secure computer network" is a corporate Wi-Fi network or VPN, protected by a FreeRADIUS server (an open-source RADIUS implementation). The FreeRADIUS server is configured to act as the authentication module and integrate with an external user token server (based on US6993658). When a user attempts to connect to the network, their client sends a RADIUS Access-Request with their User ID and a password. If the password format indicates a token-based authentication, the FreeRADIUS server queries the user token server. The user token server then generates a token and pushes it via SMS to the user's registered mobile phone. The user receives the token, combines it with their pre-shared passcode, and re-submits the full password to the FreeRADIUS server (or the client software manages this). The FreeRADIUS server, upon validating the combined password against the token server's generated value, issues a RADIUS Access-Accept, granting network access. The token's validity is time-limited, and the RADIUS session can be terminated after a predetermined idle time, effectively deactivating access.
   • Obviousness Statement: Given the prevalence of RADIUS for network access control and the desire for stronger authentication, it would be an obvious step for a PHOSITA to combine the token-based authentication described in US6993658 with an open-source RADIUS server like FreeRADIUS, enabling secure network access via personal communication devices.

3. US6993658 + OpenVPN (for Secure Tunnel Establishment):

   • Enabling Description: The "first secure computer network" is accessed via a Virtual Private Network (VPN) secured by an OpenVPN server. The OpenVPN server is configured to require user authentication using the mechanism described in US6993658. When a user attempts to establish an OpenVPN tunnel, the OpenVPN client prompts for a User ID and password. The OpenVPN server interacts with a backend user token server. This server, in response to an explicit user request (e.g., via a web portal) or as part of the initial VPN authentication challenge, sends a token via SMS to the user's mobile phone. The user then combines their secret passcode with this received token and enters the combined string into the OpenVPN client's password field. Upon successful validation by the OpenVPN server (which confirms the password with the user token server), the secure VPN tunnel is established. The token's limited lifespan and the VPN session's inactivity timeout ensure time-bound access.
   • Obviousness Statement: It would be obvious to a PHOSITA in network security to enhance the authentication of a widely used open-source VPN solution like OpenVPN by integrating a two-factor token delivery mechanism as taught by US6993658, using personal mobile devices for improved security without requiring specialized hardware.

4. US6993658 + FIDO WebAuthn (for Device-Bound Credentials):

   • Enabling Description: The secure system is a web application or service that supports FIDO WebAuthn for strong, phishing-resistant authentication. When a user registers or logs in, their "personal communication device" (e.g., a smartphone) acts as a WebAuthn authenticator. Instead of relying solely on the device's inherent biometrics or PIN, the WebAuthn flow is augmented by the US6993658 token mechanism. During WebAuthn registration or authentication, the Relying Party's server (which also acts as the user token server) generates a token and sends it via SMS to the user's registered phone number. The user's passcode in this context could be the PIN they use to unlock their phone, or a separate secret known only to them. The token is then concatenated with this passcode and entered into a prompt on the phone (within the WebAuthn authenticator application or browser interface) before the cryptographic assertion is generated by the phone's secure element. This combined value (passcode+token) is part of the user verification step within the WebAuthn flow, and only upon successful entry is the WebAuthn credential utilized to complete authentication to the web application.
   • Obviousness Statement: It would be obvious to a PHOSITA to combine the security benefits of FIDO WebAuthn's device-bound credentials with the out-of-band token delivery of US6993658, effectively creating a multi-layered authentication scheme where an ephemeral, server-delivered token acts as an additional user verification step within the WebAuthn flow, using a commonly carried device.

---