Backend Ticket Linking for Flexible Transport Usage Conditions
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Passenger transport systems with open ticket media face limitations in flexibility, requiring additional paper tickets for varying usage conditions, leading to reduced user convenience and increased infrastructural needs.
Innovation Solution
A backend system that allows for variable linking of electronic medium identifiers with different transport usage conditions, enabling dynamic changes to ticket validity through a backend system, reducing the need for paper tickets and infrastructure.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Ease of operation
If open ticket media systems are used with electronic medium identifiers, then user convenience is improved through contactless validation, but flexibility is reduced when varying usage conditions require additional paper tickets
Solution Approach 1:
The system dynamically changes the transport usage condition associated with an electronic medium identifier during the validation process. The validator device allows selection of different usage conditions (e.g., number of additional passengers, bicycle transport) after the initial check-in, enabling the ticket's validity parameters to be adjusted in real-time based on actual travel requirements.
Solution Approach 2:
The system performs a preliminary check-in validation to establish a base transport usage condition, then allows subsequent modifications to that condition. This two-stage approach enables users to first validate their ticket and then adjust parameters like adding passengers or bicycles without requiring separate paper tickets for each condition.
2Adaptability or versatility
If multiple paper tickets are required for varying usage conditions, then adaptability is improved, but device complexity and infrastructural needs increase
Solution Approach 1:
The validator device is designed to handle multiple usage conditions through a single electronic medium identifier. Instead of requiring separate validation processes for different ticket types, the system provides a unified interface where users can select from various usage conditions (additional passengers, bicycles, etc.) during the validation process, making the device multi-functional without requiring multiple specialized devices.
Solution Approach 2:
The system merges the functionality of multiple ticket types into a single electronic medium identifier. By combining the base ticket validation with optional additional services (passengers, bicycles) into one unified validation process, the system eliminates the need for separate paper tickets and reduces infrastructural complexity while maintaining adaptability.
3Adaptability or versatility
If additional paper tickets are purchased for varying usage conditions, then adaptability is improved, but loss of substance increases through paper consumption
Solution Approach 1:
The system uses electronic copies and data processing instead of physical paper tickets for representing and managing usage conditions. The transport usage condition is stored and modified as digital data associated with the electronic medium identifier, eliminating the need to print additional paper tickets for varying conditions and reducing paper consumption to zero.
Data Source
AI summary
A backend system for a passenger transport system includes: data memory for storing at least one user data set containing at least one electronic medium identifier authorizing the execution of a transport trip and at least one first transport usage condition linked to the electronic medium identifier; a receiving module configured to receive a change data set containing at least one second transport usage condition, at least one first time date and at least one user identifier for identifying a stored user data set; a change module configured to change the linkage between the electronic medium identifier stored in the identified user data set and the first transport usage condition for at least one future transport trip; a trip reconstruction module configured to reconstruct an executed transport trip at least based on a received user identifier; and a generation module configured to generate a billing data set.