POS Terminal Kernel Controller for Dynamic Transaction Routing
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing payment readers often struggle to meet the processing demands of modern transactions due to hardware limitations, power constraints, or outdated software, leading to inefficiencies and security concerns during electronic payment processing.
Innovation Solution
Implementing a kernel controller that dynamically directs payment processing functions to external devices with more robust resources, such as mobile devices or remote servers, to offload processing tasks, thereby optimizing resource utilization and enhancing security through hybrid distribution of kernel functionalities.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Productivity
If payment readers use existing hardware with limited processing capabilities, then device complexity and cost are reduced, but processing speed and productivity cannot meet modern transaction demands
Solution Approach 1:
The payment processing system is segmented into multiple kernel versions (first version and second version) with different processing capabilities. The kernel controller dynamically routes transactions to appropriate kernel versions based on complexity requirements, allowing simple transactions to be processed by lightweight kernels and complex transactions to be handled by more capable kernels, thus improving overall productivity without requiring all devices to have high complexity hardware
Solution Approach 2:
The payment reader is designed to support multiple kernel versions and can dynamically switch between them based on transaction requirements. This multi-functionality allows a single device to handle both simple and complex transactions efficiently, improving productivity across different transaction types without requiring separate specialized hardware for each transaction complexity level
2Productivity
If payment readers are equipped with robust processing hardware to handle complex transactions, then productivity improves, but power consumption and use of energy increase
Solution Approach 1:
The system dynamically selects kernel versions based on transaction complexity rather than always using the most powerful kernel. For simple transactions, a lightweight first-version kernel is used with lower power consumption, while for complex transactions, the system activates the more capable second-version kernel. This dynamic adaptation allows the system to maintain high productivity when needed while reducing power consumption during routine operations
Solution Approach 2:
The kernel controller changes the operational parameters by switching between different kernel versions with different processing capabilities and power consumption characteristics. This parameter change allows the system to optimize the balance between productivity and power consumption based on real-time transaction requirements, using only the necessary processing power for each specific transaction
3Reliability
If payment readers run updated software with modern security protocols, then security improves, but compatibility with older hardware and devices decreases
Solution Approach 1:
The software is segmented into multiple kernel versions, where the first-version kernel provides basic secure processing compatible with older hardware, and the second-version kernel provides enhanced security features for modern transactions. This segmentation allows the system to maintain security through the second-version kernel when needed while ensuring compatibility with legacy hardware through the first-version kernel, thus resolving the contradiction between security and adaptability
Solution Approach 2:
The kernel controller acts as an intermediary that determines which kernel version to use based on the transaction type and hardware capabilities. It mediates between the requirements for modern security protocols and the need for hardware compatibility by selecting the appropriate kernel version, allowing the system to achieve both security and adaptability without requiring all components to support the latest protocols
4Reliability
If payment readers process all transactions locally with full processing capabilities, then reliability improves, but device complexity and power requirements increase
Solution Approach 1:
The system implements partial local processing by using the first-version kernel for routine transactions that can be handled with simpler processing, and only activates the more complex second-version kernel when specifically needed for challenging transactions. This partial action approach maintains reliability for critical transactions while avoiding the complexity and power requirements of full local processing capabilities for all transactions
Data Source
AI summary
A payment reader can have one or more kernels capable of performing certain payment processing functions but not capable of performing certain, more processing-intensive payment processing functions. The payment reader may be designed to selectively assign processing tasks to application layer kernels located on a mobile device and/or a cloud-based device external to the payment reader, the mobile device having more or different processing resources than the payment reader. The selective assignment may be made dynamically based on the measurement of a condition of the reader or an occurrence of an event, such as a determination that the payment reader cannot process a transaction, that the payment reader does not have sufficient battery strength to process the transaction, or that there has been a tempering attempt at the payment reader. The payment reader also has a physical layer module, which module maintains its processing on the payment reader. By these means, the processing related to a payment transaction is conducted on a hybrid system, using resources both local to and remote from the payment reader.