The round-trip extension of the ATM offline relay: after the phone carries offline transaction data to the server and uploads it, the server sends a receipt back to the phone — which then returns to the ATM and delivers the confirmation. The ATM marks the batch as completed, deletes its pending queue, and the phone deletes both the batch and the receipt. Full lifecycle, closed loop.
Patent 23 (US12299655B2) solves the outbound problem: getting offline transaction data from an ATM to the central server via phone relay when the ATM has no internet. But that solution is one-directional — data flows ATM → phone → server. The ATM keeps its copy of the batch in the pending queue until it can confirm server receipt. Without a feedback path, the ATM can't know the batch was processed, can't mark it complete, and can't safely clear its local storage.
The server receives the batch file and generates a data packet containing: the batch file identifier, a timestamp of when the batch was transmitted, and a processing status for each transaction in the batch. The phone stores this data packet. When the phone is later detected within range of the ATM again, it transmits the data packet to the ATM via short-range wireless.
The ATM receives the data packet, uses the batch file identifier + device identifier to locate the corresponding pending batch in its local data repository, marks it as "completed," removes it from the pending queue, and deletes its local copy. The phone deletes both the batch file and the data packet. Full lifecycle complete — no residual data on the phone.
The round-trip architecture has five distinct legs. Claim 1 covers the full sequence from the mobile device's perspective — from receiving the communication request from the ATM through deleting the batch and data packet after final confirmation. Claim 16 covers the same sequence as an apparatus claim for the mobile device hardware.
The encryption requirement (Claim 17) is worth noting: the batch file transmitted to the mobile device is an encrypted batch file. The customer whose phone is carrying the data cannot view any transaction data in transit — the batch is opaque to the carrier device.
The data packet the server sends back is precisely defined in Claim 1: batch file identifier (so the ATM can locate the right pending batch), a timestamp of transmission to the server (audit trail), and a status for the processing of each transaction within the batch (success, failure, queued, or duplicate-detected).
Claim 15 extends the status field: it can include execution status, storage status, account update status, or a duplicate-detection flag. The duplicate flag is particularly important — if the ATM reconnected and uploaded the batch directly (while the phone was still carrying it), the server can set the flag in the data packet, and the ATM knows the batch was processed via its own connection, not via the phone relay.
Unique ID assigned when the ATM compiled the batch. Used by the ATM to locate the correct entry in its local data repository and mark it as completed.
When the phone transmitted the batch to the server. Creates a verifiable audit trail — ATM knows exactly when the server received its offline data.
Processing outcome for each transaction in the batch: executed, stored, account updated, or duplicate flag. ATM can identify any failed transactions for retry.
If ATM had already uploaded the batch directly, server sets a duplicate flag in the data packet — ATM sees this on the return trip and knows processing is complete via direct path.
Select a scenario below to trace the full round-trip data path from ATM to server and back.
When the batch was split across two phones (Claim 9's storage-check path), the round-trip lifecycle also splits. Each phone independently: uploads its portion to the server, receives its own data packet (scoped to its portion of the batch), and independently returns to the ATM to deliver its portion of the confirmation. The ATM marks both portions complete, deletes both from the queue.
Claim 9 adds the storage pre-check on the inbound path: before receiving the batch file, the phone checks whether it has sufficient storage. If not, it deletes the file and notifies the ATM of how much storage is available — enabling the ATM to calculate the right split before the transfer begins. This pre-negotiation prevents a failed transfer mid-batch.
Before transfer, phone reports available storage to ATM. ATM splits batch based on capacity, not trial-and-error — ensuring each phone gets a portion it can hold.
Each phone uploads its portion independently. Server receives two separate partial batches, each tagged with unique batch IDs and device IDs.
Each phone receives a data packet scoped to its own batch portion. Returns to ATM independently — may arrive at different times.
ATM marks each portion complete as it arrives. Only after both data packets have been delivered does the ATM consider the full offline batch closed.
The round-trip architecture closes a key gap in any system that uses mobile devices as temporary data carriers between offline nodes and central servers. The outbound trip (Patent 23) gets data to the server. The return trip (this patent) provides the audit trail: the ATM knows exactly when each transaction was processed, and customers' data is deleted from carrier phones once the loop is closed.
No forward citations found as of this check. US12051050B2 was granted July 2024 — citation data is still accumulating for this recently-issued patent. Verify the current list on Google Patents.
US12299655B2 (Patent 23) defines the outbound relay: phone carries batch from ATM to server. This patent (US12051050B2) adds the return trip: phone carries server receipt back to ATM. US12020224B2 (Patent 26) addresses a different dimension: how the ATM decides whether to approve offline transactions in the first place, using customer location history as an eligibility signal.
The trilogy covers the three core problems of offline ATM operation: data transport (P23), confirmation feedback (P25), and transaction eligibility (P26). Same inventor team, same short-range wireless infrastructure, same secure bank app framework — three patents that compose into a complete offline ATM architecture.
Defines the outbound path: phone carries batch from ATM to server. Batch tagging, storage check, split-batch, deduplication at server. Patent 25 builds on top of this.
Adds the return path: server receipt travels back to ATM via the same phone relay. Closes the lifecycle loop — ATM clears queue, phone deletes data. Full closed-loop confirmation.
Different problem: should the ATM approve this offline transaction at all? Uses customer's location history to detect anomalous usage patterns and block high-risk offline requests.
All three: same short-range wireless (BT/NFC/ZigBee/LiFi), secure bank app, pre-registration model, central server reconciliation. Three patent layers on one architecture.