Authentication Threshold Management for Session Continuity

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Current authentication methods, such as username and password entry, are insecure and susceptible to hacking, leading to unauthorized access and data breaches, especially in high-security settings, with no adequate solutions to manage temporary authentication interruptions without causing data loss or security failures.

Innovation Solution

A device with a processor and storage that identifies a threshold time for authentication failure based on activity and authentication method, taking different actions depending on the duration of the interruption, including refraining from notifications, saving changes, and prompting higher-security authentication, to balance security and usability.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If repeated authentication is implemented to enhance security, then security is improved, but user convenience deteriorates due to frequent authentication interruptions

Engineering Contradiction:
ImprovesecurityVSAvoiduser convenience
Core Design Contradiction:
ReliabilityVSEase of operation

Solution Approach 1:

The system dynamically adjusts authentication requirements based on the duration of interruption. During short interruptions (within threshold time), the system maintains current session state without requiring reauthentication, allowing users to resume work seamlessly. For longer interruptions, the system triggers reauthentication or session termination, thereby adapting security measures to actual usage patterns rather than applying static authentication rules.

Inventive Principle:
Principle #15Dynamics

Solution Approach 2:

The system changes the authentication parameter from a binary state (authenticated/not authenticated) to a time-based continuum. By introducing a threshold time parameter, the system allows authentication to remain valid within a certain time window without requiring continuous reauthentication, thus balancing security with user convenience during temporary interruptions.

Inventive Principle:
Principle #35Parameter changes

2Reliability

If authentication failure leads to immediate session termination, then security is improved, but data loss increases due to unsaved changes

Engineering Contradiction:
ImprovesecurityVSAvoiddata loss
Core Design Contradiction:
ReliabilityVSLoss of substance

Solution Approach 1:

The system provides a cushioning period (threshold time) during which users can continue working without immediate session termination. This buffer period allows users to complete their work and save changes before authentication failure becomes critical, preventing data loss while maintaining security. The system accepts changes during this cushioning period and only terminates sessions after the threshold is exceeded.

Inventive Principle:
Principle #11Beforehand cushioning (Prior cushioning)

Solution Approach 2:

The system performs preliminary actions by accepting and temporarily storing changes made during authentication interruptions, before determining whether to terminate the session. This preliminary acceptance of changes ensures that user work is not lost immediately upon authentication failure, but rather is preserved and saved before any termination action is taken.

Inventive Principle:
Principle #10Preliminary action

3Reliability

If strict authentication monitoring is implemented, then security is improved, but system complexity increases due to continuous monitoring requirements

Engineering Contradiction:
ImprovesecurityVSAvoidsystem complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The system extracts the continuous monitoring function from the authentication mechanism itself and implements it as a separate, dedicated monitoring component. This monitoring component independently tracks interruption duration and triggers appropriate responses only when thresholds are exceeded, simplifying the overall system architecture by separating monitoring logic from authentication logic.

Inventive Principle:
Principle #2Taking out (Extraction)

Solution Approach 2:

The authentication system performs self-monitoring by internally tracking interruption duration and automatically determining when threshold-based actions are required. This self-service approach eliminates the need for external complex monitoring systems, as the authentication mechanism itself maintains awareness of session state and triggers appropriate responses based on built-in threshold criteria.

Inventive Principle:
Principle #25Self-service

4Loss of information

If notification is sent on authentication interruption, then user awareness is improved, but user frustration increases due to frequent interruptions

Engineering Contradiction:
Improveuser awarenessVSAvoiduser frustration
Core Design Contradiction:
Loss of informationVSEase of operation

Solution Approach 1:

The system applies partial action by providing notifications only for authentication interruptions that exceed the threshold time, rather than notifying users for every minor interruption. This selective notification approach ensures users are informed of significant issues that may affect their work, while avoiding frustration from constant notifications during normal, temporary interruptions.

Inventive Principle:
Principle #16Partial or excessive action

Data Source

PatentUS20230222189A1Performance of different actions at device based on success or failure of subsequent authentication within threshold time after repeated authentication fails
Publication Date: 2023.07.13 LENOVO (SINGAPORE) PTE LTD
  • US20230222189A1 patent drawing
  • US20230222189A1 patent drawing
  • US20230222189A1 patent drawing

AI summary

In one aspect, a device may include at least one processor and storage accessible to the processor. The storage may include instructions executable by the processor to identify a threshold amount of time related to authentication failure based on an activity for which the device is currently being used and at least one method of authentication to be used for authenticating a user while the user performs the activity. The instructions may also be executable to take at least a first action based on an interruption that prevents repeated authentication not exceeding the threshold amount of time, and to take at least a second action based on successful authentication resuming subsequent to the interruption but within the threshold amount of time. The instructions may also be executable to take at least a third action based on the interruption exceeding the threshold amount of time.