Cross-domain Inactivity Tracking in Cloud Services

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Cross-domain inactivity tracking in cloud computing environments is challenging due to disparate services with different inactivity periods and lack of scalability in existing solutions, leading to inefficiencies and performance overhead.

Innovation Solution

A master service tracks user authentication across multiple cloud services and selectively overrides inactivity timeouts by checking activity status on an as-needed basis, allowing users to remain active across services even if one service has exceeded its inactivity period.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If traditional inactivity monitoring techniques are used across distributed cloud services, then security is improved, but scalability deteriorates due to the requirement for centralized state management

Engineering Contradiction:
ImprovesecurityVSAvoidscalability
Core Design Contradiction:
ReliabilityVSAdaptability or versatility

Solution Approach 1:

The patent divides the centralized inactivity monitoring system into distributed components, where each cloud service independently tracks user inactivity. This segmentation eliminates the need for centralized state management while maintaining security, allowing the system to scale across multiple services without performance degradation.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

Each cloud service performs self-service inactivity tracking by maintaining local state and making autonomous decisions about user sessions. This eliminates dependency on centralized coordination, improving both security and scalability in distributed cloud environments.

Inventive Principle:
Principle #25Self-service

2Reliability

If inactivity tracking is implemented across multiple cloud services with different inactivity periods, then comprehensive security monitoring is improved, but system complexity increases

Engineering Contradiction:
Improvecomprehensive security monitoringVSAvoidsystem complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The patent applies local quality by allowing each cloud service to have its own inactivity period configuration and tracking mechanism tailored to its specific security requirements. This eliminates the need for a complex unified system while achieving comprehensive security monitoring across services with different needs.

Inventive Principle:
Principle #3Local quality

3Measurement precision

If frequent cookie updates are performed to track inactivity, then inactivity detection accuracy is improved, but performance overhead increases

Engineering Contradiction:
Improveinactivity detection accuracyVSAvoidperformance
Core Design Contradiction:
Measurement precisionVSProductivity

Solution Approach 1:

The patent implements periodic action by having each cloud service update inactivity tracking at intervals appropriate to its own inactivity period, rather than performing frequent updates across all services. This maintains detection accuracy while minimizing performance overhead through service-specific update frequencies.

Inventive Principle:
Principle #19Periodic action

Data Source

PatentUS9462068B2Cross-domain inactivity tracking for integrated web applications
Publication Date: 2016.10.04 DAEDALUS GROUP LLC
  • US9462068B2 patent drawing
  • US9462068B2 patent drawing
  • US9462068B2 patent drawing

AI summary

In a cloud computing environment, a user authenticates to multiple cloud services concurrently. A master service has knowledge of or tracks the cloud service(s) to which a user is authenticated. Each cloud service may enforce its own inactivity period, and the inactivity period of at least first and second cloud services may be distinct from one another. When the master service receives an indication that the authenticated user is attempting to take an action at a first cloud service despite an activity timeout there, the master service issues a status request to at least the second cloud service to determine whether the user is still active at the second cloud service (despite its different inactivity period). If the user is still active at the second cloud service, the master service provides a response, selectively overriding (re-setting) the activity timeout at the first cloud service to permit the action.