Server Application Access Request Status Tracking

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Users attempting to access restricted application functionality face issues with unclear status updates on access requests, leading to unnecessary resubmissions and increased workload for site owners due to lack of transparent communication about access approval or denial.

Innovation Solution

A server application provides a user interface for users to request access and track the status of their requests, with status updates sent to both users and site owners, preventing duplicate requests and enhancing communication through email or electronic messages.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Loss of information

If the site owner sends an email to the user to request additional information, then the site owner can obtain necessary information from the user, but the site owner's identity is exposed to the user

Engineering Contradiction:
Improveinformation from userVSAvoididentity protection
Core Design Contradiction:
Loss of informationVSReliability

Solution Approach 1:

The patent introduces an intermediary notification system that mediates between the site owner and the user. Instead of direct email communication that exposes the site owner's identity, the system uses automated notifications and a queue management interface where the site owner can view and respond to access requests without revealing their personal contact information to the user.

Inventive Principle:
Principle #24Intermediary (Mediator)

2Reliability

If the user attempts to access the application multiple times before approval, then the user can check if access is granted, but the user generates superfluous requests that increase workload for the site owner

Engineering Contradiction:
Improveaccess status verificationVSAvoidsite owner workload
Core Design Contradiction:
ReliabilityVSProductivity

Solution Approach 1:

The patent implements a feedback mechanism where the user receives automated status updates about their access request through notifications. This feedback loop allows the user to verify the status of their request without repeatedly attempting access or contacting the site owner, thereby reducing unnecessary workload while maintaining reliable access status verification.

Inventive Principle:
Principle #23Feedback

Solution Approach 2:

The system performs preliminary actions by sending proactive notifications to the user about the status of their access request before the user would need to attempt access again. This advance information allows the user to plan accordingly and avoid generating additional access requests or contact attempts.

Inventive Principle:
Principle #10Preliminary action

3Loss of information

If the user does not receive status updates on their access request, then the system remains simple, but the user cannot determine whether their request was approved or denied

Engineering Contradiction:
Improveaccess request statusVSAvoidnotification system
Core Design Contradiction:
Loss of informationVSDevice complexity

Solution Approach 1:

The patent implements a feedback mechanism where the user receives automated status updates about their access request through notifications. This feedback loop allows the user to verify the status of their request without repeatedly attempting access or contacting the site owner, thereby reducing unnecessary workload while maintaining reliable access status verification.

Inventive Principle:
Principle #23Feedback

Data Source

PatentUS9396347B2Providing status of site access requests
Publication Date: 2016.07.19 MICROSOFT TECHNOLOGY LICENSING LLC
  • US9396347B2 patent drawing
  • US9396347B2 patent drawing
  • US9396347B2 patent drawing

AI summary

Concepts and technologies are described herein for providing status of site access requests. In accordance with the concepts and technologies disclosed herein, a user attempts to access functionality of a server application that is limited to authorized users. In response to the access attempt, the server application determines if the user is authorized to access the functionality and if the user has previously requested access to the functionality. If the user has not previously requested access to the application, the server application can present a user interface to the user for requesting access to the server application. If the user has previously requested access to the application, the server application can present an indication that an access request already exists, history and status information associated with the access request, and/or an interface for submitting messages to the site owner or other entity.