Dual Virtual Machine Switching for ATM Transaction Continuity
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Automated Teller Machines (ATMs) face security breaches and availability issues due to corruption of memory, storage, and resources, leading to unavailability and potential security risks, with existing solutions often failing to detect and address hardware and software malfunctions promptly.
Innovation Solution
Implementing a system with dual Virtual Machines (VMs) that continuously switch and image cores, ensuring high availability by maintaining two stable processing environments, where one VM is always active and the other is imaged and swapped in case of failures, preventing malware spread and ensuring seamless transaction processing.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If a single ATM core is used for processing transactions, then device complexity is reduced, but reliability and security are compromised due to potential corruption and malware infections
Solution Approach 1:
The patent divides the ATM core into two separate virtual machines (first VM and second VM), each capable of independent operation. This segmentation ensures that if one core is corrupted or infected with malware, the other can continue processing transactions, thereby improving reliability without requiring a completely separate physical system.
Solution Approach 2:
The patent creates a copy of the ATM core in the form of a second virtual machine that mirrors the first VM's functionality. This copy allows for seamless failover and maintains system availability while distributing security risks across independent instances.
2Reliability
If dual virtual machines are implemented for high availability, then reliability is improved, but device complexity increases
Solution Approach 1:
The patent implements self-service through automatic failover mechanisms where the system autonomously detects failures and switches between virtual machines without requiring manual intervention. The monitoring and switching components automatically manage the dual VM architecture, reducing operational complexity despite the increased system capacity.
Solution Approach 2:
The patent introduces intermediary components (monitoring and switching mechanisms) that mediate between the two virtual machines and the transaction processing system. These intermediaries simplify the management of dual VM architecture by handling coordination, failure detection, and context switching automatically.
3Object-affected harmful factors
If hardware and software resources are patched or upgraded, then security is improved, but reliability deteriorates due to potential corruption and malfunction
Solution Approach 1:
The patent applies preliminary action by maintaining a second virtual machine that serves as a pre-prepared backup system. Before any corruption or security breach affects the primary system, the secondary VM can be activated, preventing reliability deterioration from patching or upgrade operations that might introduce corruption.
Solution Approach 2:
The patent implements beforehand cushioning by having a redundant virtual machine ready to absorb the impact of potential corruption, malware infections, or patch-related failures. This cushioning ensures that security improvements from patching do not compromise system stability, as the backup VM provides a safety net.
4Reliability
If ATM is taken offline for maintenance or repair, then reliability is improved by resolving issues, but productivity is reduced due to transaction unavailability
Solution Approach 1:
The patent ensures continuity of useful action by implementing continuous transaction processing across two virtual machines. When one VM requires maintenance or repair, the other VM continues to handle transactions without interruption, eliminating productivity loss that would otherwise occur during reliability maintenance activities.
Data Source
AI summary
Dual Self-Service Terminal (SST) Virtual Machines (VMs) are provided. A VM is selected for processing a transaction on the SST as an active core. The active core is dynamically switched back and forth between a first VM and a second VM on a per-transaction basis. Upon failure, a last-successful image for the failing VM is reloaded for the failing VM when the failing VM is scheduled to be cycled back to the active core.


