Before approving an offline ATM withdrawal — when the ATM has no internet connection — the system asks: does the customer's current location match where they normally conduct transactions? If the customer's transaction history is concentrated in New York but they're at an ATM in a different region, that's a fraud signal. Location history becomes the gating mechanism for offline access.
When an ATM loses internet connectivity, it can no longer ping the central server to verify: does this account have sufficient balance? Is this card flagged for suspicious activity? Is this customer's pattern consistent? Standard fraud checks become unavailable. The ATM must decide whether to process a cash withdrawal using only local information — but local information typically means nothing more than the card data the customer presents.
Before the ATM goes offline, the secure bank app on the customer's mobile device downloads and stores that customer's recent transaction history — including the location data (zip code granularity, per Claim 3) associated with each transaction. When the customer later approaches an offline ATM, the ATM reads the history from the phone via short-range wireless.
The ATM evaluates: are most recent transactions within a distance threshold of this ATM's location? If yes, the customer's profile is consistent — approve the withdrawal. If most transactions occurred far away — the customer's phone is being used at an anomalous location — deny the request. The customer's own transaction history, carried on their own phone, becomes the offline fraud-detection signal.
The eligibility check compares two variables: the locations of the customer's most recent transactions (stored on the phone) and the location of the ATM. If a threshold percentage of recent transactions occurred within a distance threshold of the ATM, the system determines the customer is a legitimate local user.
Claim 2 specifies the full three-factor evaluation: transaction value, location, and date. Location granularity is calibrated to zip code (Claim 3) — precise enough to detect cross-region anomalies without requiring GPS-exact coordinates. The date component adds recency weighting: stale transactions matter less than recent ones in evaluating current customer location patterns.
Even a customer who passes the location eligibility check faces additional constraints when the ATM is operating offline. The ATM can't verify current balance, so it applies conservative limits. Two separate capacity constraints gate the withdrawal amount: remaining ATM cash (Claim 6) and a combined storage + cash dual-factor cap (Claim 7).
Claim 8 adds a trust-tiered limit: when available cash falls below a threshold, the withdrawal limit is reduced — customers with limited offline transaction history or borderline location matches receive smaller limits. This graceful degradation prioritizes serving more customers with smaller amounts over serving fewer customers with full amounts as the ATM approaches empty.
Claim 6: withdrawal limit cannot exceed the ATM's remaining cash supply. Prevents the ATM from attempting to dispense cash it doesn't have when it can't check remotely.
Claim 7: limit is the lower of both the storage capacity constraint AND the cash capacity constraint. The tighter constraint always wins.
Claim 8: as cash supply runs low, the per-withdrawal limit decreases. Borderline-approved customers get proportionally smaller limits — more customers served at lower risk.
Claim 9: when connectivity returns, server reconciles the offline transactions and pushes a notification to the customer's device — confirming what was processed while offline.
Select a scenario to trace the full offline eligibility determination — from transaction history comparison through final outcome.
Independent Claim 13 extends the system with an activity log stored on the mobile device. This log records the timestamp of each offline transaction the customer has participated in — including transactions where their phone relayed data for ATM-to-server transfers (Patent 23/25).
Claim 14 adds the critical security layer: when the ATM receives a transaction request, it checks the activity log for timestamp matching. If the request's timestamp matches a prior log entry — indicating the same transaction is being re-submitted — the ATM can reject it as a potential replay attack. This prevents an attacker from capturing a legitimate transaction request and re-submitting it to a different offline ATM.
Claim 13: mobile device stores a log of offline transactions — both withdrawals and relay activities — with timestamps. Log is maintained by the secure bank app.
Claim 14: before processing a request, ATM compares the request timestamp against all entries in the activity log. A match indicates a replay — request is rejected.
Without timestamp matching: attacker captures NFC/BT transaction request, moves to second offline ATM, replays request. Second ATM has no way to know the request was already processed.
Activity log synchronizes with central server when connectivity is restored — timestamps are validated against server-side records and duplicates are permanently flagged.
The core innovation — using device-stored behavioral history as an offline fraud gate — extends to any system where a device-carried history can signal whether a transaction request is consistent with established patterns.
One third-party citation found. One additional citation omitted. Full list available on Google Patents.
One additional citation omitted. Full list on Google Patents →
US12299655B2 (Patent 23) defines the outbound data relay — phone carries transaction batch to server. US12051050B2 (Patent 25) closes the loop — server receipt returns to ATM via phone. This patent (US12020224B2) addresses the eligibility decision layer: before any of that infrastructure activates, should this customer's withdrawal be approved offline at all?
The three patents compose: Patent 26 gates eligibility using location history. Patent 23 handles the outbound data transport for approved transactions. Patent 25 provides the confirmation feedback loop when the relay completes. Three patents, three layers of the same offline ATM resilience architecture.
Answers: "Should this customer be allowed to withdraw offline?" Location history check, biometric auth, trust-tiered limits. The decision layer — everything else is downstream.
For approved transactions: phone carries the offline batch from ATM to server. Batch tagging, storage check, multi-phone split, deduplication. The transport layer.
After server processes the batch: receipt returns to ATM via phone. ATM clears queue. Full closed-loop confirmation. The feedback layer.
All three: short-range wireless (BT/NFC/ZigBee/LiFi), secure bank app on registered device, central server reconciliation. Three patent layers on one architecture.