A cross-region server architecture where a second data server detects when a requested amount exceeds local balance, queries the home server over a pre-authorized M2M connection, and requests only the difference — bridging the gap before processing the original request. Proactive variant: the server monitors balance and pre-requests from home before the gap occurs.
Cross-region data architectures distribute user account data across regional servers for performance and compliance reasons. When a user is present in a foreign region, a local server holds a subset of their total data. If a transaction request exceeds that local balance, the system has no mechanism to automatically source the difference from the home region — the request simply fails.
The second data server doesn't reject the request when local balance is insufficient. Instead it detects the gap (first amount requested − local balance = difference needed), determines over the pre-authorized M2M connection whether the home server has at least that difference, requests exactly that amount, receives it, and then processes the original request — all within the same transaction flow.
The proactive variant (Claim 7) inverts the trigger: instead of waiting for a request to fail, the second server continuously monitors local balance and requests a top-up from the home server whenever balance drops below a configured threshold — preventing the gap from occurring in the first place.
Claim 1 defines the system from the second data server's perspective: it receives the request, detects the insufficiency, queries home, receives the difference, and processes. The pre-authorized connection is the critical enabler — it allows the M2M query and transfer to happen without real-time user authorization at the point of the request.
Claim 10 defines the same flow from the first data server's (home server's) perspective: it receives the M2M query, verifies sufficiency, responds with availability, and transmits the requested difference amount.
The patent is precise about what gets transferred. The second server requests "a fourth amount of data that at least equals the difference between the first amount and the second amount" (Claim 1). It doesn't request the full transaction amount from home — only the shortfall. This minimizes cross-region data movement and preserves the home server's balance.
The pre-authorized secure connection (established before the transaction, per Claim 6 — dynamically set up by geo-location) is what makes this possible without human-in-the-loop approval at the moment of the request. Claim 4 adds the human-in-the-loop option for higher-value or flagged transfers.
The patent covers distinct scenarios depending on local balance, home availability, and whether a human authorization step is required. Select a scenario to trace the server decision tree.
The reactive bridge (Claim 1) handles the case after a request exposes a gap. Claim 7 introduces the proactive variant: the second server monitors its local balance and, when it falls below a configurable threshold, proactively requests a top-up from the home server — without waiting for a user request to trigger the shortfall detection.
This transforms the architecture from a reactive failure-recovery system into a predictive balance management system. Combined with Claim 5 (geo-location triggers the bridge) and Claim 6 (the pre-authorized connection is dynamically established by geo-location when the user enters a new region), the system can begin pre-populating the local server's balance before the user even initiates a transaction.
Triggered by a specific user request that exceeds local balance. Gap detected in-flight. Difference fetched from home. Original request completes without failure.
Second server monitors balance continuously. When it drops below threshold, top-up request sent to home server — before any user request has been made. No in-flight gap detection needed.
When the user enters a new region, geo-location detection dynamically establishes the pre-authorized connection between local and home server — preparing the bridge before it's needed.
For high-value transfers, the second server sends a transfer alert to the user requesting authorization before pulling from the home server — human-in-the-loop variant for sensitive cases.
The pre-authorized secure connection (referenced throughout Claim 1 and Claim 2) is not established on-demand when a gap is detected. It's a standing M2M channel that exists between the first and second data servers — authorized ahead of time so that the balance query, availability check, and difference transfer can all happen without requiring real-time user authentication or authorization during the transaction.
Claim 2 elaborates the sub-protocol: the second server sends a data query message over the pre-authorized connection, and the first server responds with a data reply confirming availability. This query-response sub-protocol is the formal M2M verification step before any data transfer occurs.
The secure connection between home and foreign servers is established in advance — not created on-demand during a gap event. Removes the authentication overhead from the critical path.
Before requesting data, the second server sends a formal query message. The home server responds with an availability confirmation. Only then is the transfer requested.
Claim 5 and 6: when the user enters a foreign region, the geo-detection event automatically initiates the pre-authorized connection setup — so it's ready before any transaction attempt.
Claim 9: before processing the original request after the bridge transfer, the second server authenticates the user's identity — ensuring the bridged data goes to the right account.
The patent's claim language is deliberately general — "data files" not "currency," "distribution interaction" not "payment." This gives the architecture broad applicability across any system where a user's account data is distributed across regional servers and continuity across regions matters.
B1 patents (no pre-grant publication) often grant quickly with well-scoped claims. US11265370B1 filed July 2021 and granted March 2022 — approximately 7 months, exceptionally fast for a utility patent. The three independent claims give multi-angle coverage: the second server's obligations, the first server's obligations, and a hardware apparatus claim.
Claim 1 covers the second server's decision logic (detect gap → query → verify → request → receive → process). Claim 10 covers the first server's complementary obligations (receive query → verify own balance → respond → transmit difference). Claim 16 is the apparatus claim for the first server hardware.
Second server perspective: receive request → detect insufficiency → query pre-authorized M2M → verify → request difference → receive → process. Foundation of the entire patent.
First server (home) perspective: receive query → verify own balance → confirm availability → transmit requested difference amount. Covers the method from the home side.
Hardware apparatus claim for the first server. Provides independent protection for the physical implementation — not just the method or system claim.
Claim 2: M2M query-response sub-protocol. Claim 4: human-in-loop transfer alert. Claim 5: geo-location triggers bridge. Claim 7: proactive top-up below threshold. Claim 9: user identity auth.