Contextual Support Message Generation for Multi-Layer Systems

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Conventional support systems for enterprise software deployments are inefficient, fault-prone, and time-intensive, leading to increased costs due to inefficient routing of support requests, inadequate context description, and lack of structured mechanisms for symptom identification and error resolution.

Innovation Solution

A method for generating contextual support messages by collecting data from multiple layers of a computing system, including user interface, services, business object, and application server layers, to provide intelligent, context-specific support, allowing for efficient incident identification, assignment, and resolution, and enabling the creation of a knowledge base for repeatable processes.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Productivity

If conventional support systems are used for enterprise software deployments, then support requests can be handled, but the costs increase and efficiency decreases as the number of users increases

Engineering Contradiction:
Improvesupport efficiencyVSAvoidnumber of support staff required
Core Design Contradiction:
ProductivityVSQuantity of substance

Solution Approach 1:

The system enables self-service by automatically collecting context data from multiple system layers and generating support messages without requiring manual intervention from support staff. The automated context collection and message generation allow the system to serve itself in preparing support requests, reducing the need for human operators.

Inventive Principle:
Principle #25Self-service

Solution Approach 2:

The invention changes the parameters of support request handling by collecting data from multiple layers (user interface, services, business object, application server) and transforming this data into structured context information. This parameter transformation enables more efficient routing and handling of support requests, improving productivity without proportionally increasing staff.

Inventive Principle:
Principle #35Parameter changes

2Ease of operation

If conventional support routing is used, then support requests can be directed to support entities, but requests are often not routed to the correct entities leading to inefficiency

Engineering Contradiction:
Improvesupport request routing accuracyVSAvoidtime to resolve incidents
Core Design Contradiction:
Ease of operationVSLoss of time

Solution Approach 1:

The system implements feedback by collecting context data from multiple system layers and using this information to determine the appropriate support entity for routing requests. The context information provides feedback about the incident's nature and location, enabling accurate routing decisions that reduce resolution time and improve operational ease.

Inventive Principle:
Principle #23Feedback

Solution Approach 2:

The system performs preliminary action by collecting and analyzing context data before routing the support request. This advance preparation of context information allows the system to pre-determine the appropriate support entity, eliminating delays associated with manual routing decisions and improving both ease of operation and time efficiency.

Inventive Principle:
Principle #10Preliminary action

3Loss of information

If users provide support requests without adequate context, then support requests can be submitted, but the situation requiring support cannot be adequately described or simulated

Engineering Contradiction:
Improvecontext information completenessVSAvoidsystem architecture complexity
Core Design Contradiction:
Loss of informationVSDevice complexity

Solution Approach 1:

The system applies segmentation by dividing context collection into distinct layers: user interface layer, services layer, business object layer, and application server layer. Each layer contributes specific context data, ensuring comprehensive information collection without overwhelming complexity. This segmented approach systematically captures all necessary context while maintaining manageable system architecture.

Inventive Principle:
Principle #1Segmentation

4Reliability

If conventional support processes are used, then support requests can be handled, but the processes are not repeatable as a structured mechanism for symptom description and cause identification

Engineering Contradiction:
Improvesupport process repeatabilityVSAvoidstructured mechanism complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The system achieves repeatability by standardizing parameters for context collection across all support requests. By defining consistent data collection points at each layer (user interface, services, business object, application server) and using uniform message generation processes, the system creates a repeatable structured mechanism that maintains reliability without excessive complexity.

Inventive Principle:
Principle #35Parameter changes

Data Source

PatentUS8527542B2Generating contextual support requests
Publication Date: 2013.09.03 SAP SE
  • US8527542B2 patent drawing
  • US8527542B2 patent drawing
  • US8527542B2 patent drawing

AI summary

User-generated input may be received to initiate a generation of a message associated with an incident of a computing system having a multi-layer architecture that requires support. Thereafter, context data associated with one or more operational parameters may be collected from each of at least two of the layers of the computing system. A message may then be generated on at least a portion of the user-generated input and at least a portion of the collected context data. Related apparatuses, methods, computer program products, and computer systems are also described.