Middleware Document Status Tracking Across Networks

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Current middleware management systems in B-to-B transactions lack efficient technical means to track document status across multiple computer networks, leading to delays and failures due to the complexity of interactions between disparate systems and networks, especially when the middleware layer is in the cloud and inaccessible to parties involved.

Innovation Solution

Implementing a standardized list of document statuses, or checkpoints, within a Community schema to record and summarize document flow, along with technical acknowledgments that provide end-to-end visibility through standardized status updates, enabling better tracking and reporting of document status changes across networks.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Loss of information

If a standardized list of document statuses and checkpoints is implemented within a Community schema, then visibility and tracking capability of document status is improved, but system complexity and implementation effort increase

Engineering Contradiction:
Improvedocument status visibilityVSAvoidsystem implementation complexity
Core Design Contradiction:
Loss of informationVSDevice complexity

Solution Approach 1:

The document tracking system is segmented into discrete checkpoints representing specific status transitions. Each checkpoint is an independent, standardized status point that can be individually implemented and tracked. This segmentation allows the complex tracking requirement to be broken down into manageable, standardized units that reduce overall implementation complexity while maintaining comprehensive visibility.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The Community schema implements a universal checkpoint framework that can track multiple document types and workflows through a common standardized structure. This multi-functional approach allows the same tracking mechanism to serve various transaction types (purchase orders, invoices, etc.) and multiple parties (buyers, suppliers, intermediaries), reducing the need for separate tracking systems for each scenario.

Inventive Principle:
Principle #6Universality (Multi-functionality)

2Reliability

If technical acknowledgments with standardized status updates are implemented, then end-to-end visibility and error reporting are improved, but communication protocol complexity increases

Engineering Contradiction:
Improveerror detection and reportingVSAvoidcommunication protocol complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The system changes the parameters of status communication by using standardized status codes and predefined checkpoint transitions. Instead of allowing free-form status descriptions, the system constrains status updates to specific parameter values representing defined checkpoints. This standardization improves reliability through consistent error detection while reducing protocol complexity by limiting the communication space to predetermined options.

Inventive Principle:
Principle #35Parameter changes

Solution Approach 2:

Technical acknowledgments implement a feedback mechanism where receiving systems automatically send standardized status updates back to sending systems. This feedback loop provides end-to-end visibility by confirming document delivery and processing status at each checkpoint. The automated feedback reduces manual intervention and improves reliability through systematic error reporting, while the standardized nature of the feedback messages keeps protocol complexity manageable.

Inventive Principle:
Principle #23Feedback

Data Source

PatentUS11848848B2Tracking of document status through multiple computer networks
Publication Date: 2023.12.19 SAP SE
  • US11848848B2 patent drawing
  • US11848848B2 patent drawing
  • US11848848B2 patent drawing

AI summary

In an example embodiment, a first function is performed on the first document received at first middleware management architecture, causing a change in the status of the first document. The change is logged in a record corresponding to the first document in a memory. Then the first document is sent to a second network via a transmission protocol layer. A notification of a change in the status of the first document within the second layer is received in a layer other than the transmission protocol layer, from the second network. The change in the second network is logged in the record corresponding to the first document in the memory. Information corresponding to the change in the status of the first document at the middleware management architecture and the change in the status of the first document in the second network is reported to the first network.