When an ATM loses internet, it recruits nearby pre-registered customer smartphones as data mules — batching offline transactions, transferring via Bluetooth or NFC, and relying on those phones to carry the data to connectivity and upload it to the central server. Batch too large for one phone? Split it across two.
ATMs can process transactions locally during network outages using offline protocols. But the transaction data generated during that offline period is trapped in the ATM's local storage — it can't reach the central server for final processing, reconciliation, or account updates until connectivity is restored. In disaster scenarios (hurricanes, power outages, infrastructure failures), that wait can be hours or days.
Customers pre-register their phones in their bank profile as potential "transaction transmission intermediaries" — opt-in, explicit consent. When the ATM detects a network outage, it searches the surrounding area via short-range wireless (Bluetooth, NFC, ZigBee, or LiFi) for any pre-registered customer phones running the secure bank app. When it finds one, it compiles offline transaction data into a tagged batch file and asks the phone for permission to transport it.
If the phone approves, it stores the batch file and carries it until the phone reaches cellular or Wi-Fi connectivity — then uploads automatically to the central server. The ATM keeps a copy until upload confirmation arrives. If one phone lacks storage, the batch splits across two phones simultaneously.
The system architecture turns customers into temporary data couriers. The ATM operates as an offline processor and batch compiler. The customer's pre-registered smartphone operates as a store-and-carry relay. The central server is the final destination, with deduplication built in to handle the case where both the ATM's direct connection and the phone relay deliver the same batch.
Deduplication uses two tags attached to every batch file: a batch file identifier (unique per batch) and a device identifier (the phone that carried it). When the server receives a batch, it checks for any previously received batch with the same pair of tags — discarding duplicates before processing.
The batch file contains all offline transaction data accumulated since the network outage began, tagged with a batch file identifier and the device identifier of the carrying phone. These two tags together form the deduplication key at the server — preventing double-processing if the ATM's direct connection also delivers the same data.
If the target phone's available storage is less than the batch file size (Claim 1), the ATM automatically splits the batch into a first and second batch file, each with unique identifiers. It transmits the first to the original phone and searches for an additional phone for the second. Claim 8 adds a priority layer: transactions can be sorted by value before batching, ensuring higher-value transactions are in the first (primary) batch file.
The patent covers four distinct relay scenarios. Select a scenario below to trace the ATM-to-server data path.
The pre-registration model is the security foundation of the architecture. Customers opt in through their bank account profile — before any network outage occurs. The profile records: the customer's mobile device, that the secure bank app is installed, and that the customer has explicitly opted to allow their device to function as a transaction transmission intermediary.
At the time of the relay request, the ATM uses its local data repository (which includes these customer profiles) to identify pre-registered phones within range — confirming both that the phone is pre-registered AND that the app is currently running before transmitting the pairing request. The approval step (Claim 4) adds a real-time accept/deny notification at the moment of each individual relay, even for pre-registered users.
Customer opts in via bank profile before any outage. Profile records: device ID, app installed status, explicit intermediary consent flag.
ATM cross-references profile in local data repository with detected phone. Must confirm: pre-registered AND app currently running AND within range.
Even for pre-registered users, ATM sends a real-time notification to the phone requesting explicit approval for each specific relay event — preserving user control.
Claim 5: Bluetooth, NFC, ZigBee, or LiFi. All short-range — limiting relay participants to customers physically near the ATM at the moment of the request.
The patent specification explicitly names hurricanes, weather events, and power outages as the motivating scenarios. The architecture achieves ATM data resilience by leveraging existing customer smartphones — turning a ubiquitous, already-deployed asset into backup infrastructure, with no new hardware required at the ATM or anywhere in the network.
No unaffiliated forward citations are available for this patent. As a May 2025 grant, citation data is still accumulating. Full list — including any sibling or related applications — available on Google Patents.
This patent is part of a coordinated trio covering different architectural layers of ATM resilience. US12299655B2 (this patent) covers the data transport mechanism — how offline transaction data gets from the ATM to the central server via phone relay. The companion patents extend the architecture in two additional directions.
US12051050B2 (Patent 25) adds the return trip: after the phone uploads, it carries a server receipt back to the ATM, closing the loop and confirming processing status. US12020224B2 (Patent 26) tackles the eligibility decision itself — how the ATM decides which offline transactions to approve, using the customer's transaction location history as a geofencing signal.
Data transport: phone carries offline batch to connectivity → uploads to server. Batch splitting. Deduplication. Consent model.
Adds return trip: server sends receipt to phone → phone returns to ATM → delivers confirmation. Full lifecycle tracking, data deletion after confirmation.
Eligibility gating: ATM uses customer's transaction location history to decide whether to approve offline transactions. Biometric auth. Trust-tiered withdrawal limits.
All three patents: same inventor team, same short-range wireless transports (BT/NFC/ZigBee/LiFi), same secure app framework, same central server reconciliation model.