When cellular and Wi-Fi are unavailable, a satellite channel carries device data packets containing multiple device identifiers. The system computes a malfeasance value by comparing identifiers in the satellite packet against those in the transfer request. Mismatch raises the value; location anomaly adds more. If the value crosses the threshold, the transfer is flagged and an elevated action — delay, cancel, or request additional security — fires via the same satellite channel.
Standard real-time fraud detection systems are network-dependent: they query identity databases, check device fingerprints, and apply ML scoring models over cellular or Wi-Fi connections. If those connections are unavailable — in rural areas, during network outages, in high-interference environments, or when a user is traveling internationally — the fraud detection layer falls back to static rules or is bypassed entirely.
The system detects that cellular and Wi-Fi connectivity are unavailable and activates the satellite fraud-detection channel. The user's endpoint device transmits device data packets via satellite to the system's transfer processing component. These packets contain a plurality of device identifiers — hardware IDs, session tokens, device characteristics that uniquely identify the physical device.
The system computes a malfeasance value by comparing the device identifiers received via the satellite packets against the device identifiers in the transfer request itself. A match signals consistency — the device generating the request matches the device physically present. A mismatch raises the malfeasance value. If the value meets or exceeds the threshold, the transfer is flagged and an elevated action fires: delay, cancel, alert, or request additional security verification — all delivered via the satellite channel that's still available.
The system architecture has five components working together. The user's endpoint device generates both the transfer request (via whatever network channel is available) and the device data packets (sent via satellite). The satellite network is the secondary channel — not a fallback for the payment, but specifically for the fraud-detection data stream.
The transfer processing component receives both streams: the transfer request and the satellite-delivered device data packets. It routes the device identifiers from both sources to the malfeasance engine, which computes the discrepancy value. If the threshold is crossed, the elevated action handler fires — and delivers the response (alert, rejection, or additional-security request) back to the user endpoint via the satellite channel that's still available.
Claim 1 defines the system: computing platform with components that receive satellite device data packets, compare identifiers, compute malfeasance value, and trigger elevated action when threshold is crossed. Claim 8 defines the same invention as a computer-readable medium (CRM). Claim 15 defines it as a method — the sequence of steps that constitutes the process.
The dependent claim layers build in both detection dimensions and response dimensions. Detection: geolocation comparison (Claim 3/10/17) adds location mismatch as a second scoring signal alongside device ID mismatch. The satellite-specific fallback condition (Claim 5/12/19) limits the invention to activation only when cellular/Wi-Fi are unavailable — a precision claim that distinguishes this from general satellite communication patents. Response: elevated actions (Claim 4/11/18) enumerate the specific responses: alert, reject, or request additional security via satellite.
Computing platform: receives satellite device data packets, compares device IDs to transfer request, computes malfeasance value, triggers elevated action at threshold.
Computer-readable medium: same invention captured as stored instructions. Covers embedded systems and firmware implementations of the fraud-detection logic.
Method: ordered steps — receive satellite packets, compare identifiers, compute value, threshold decision, trigger action. Covers the process irrespective of implementation.
Approve path below threshold (2/9/16) · Geolocation comparison (3/10/17) · Elevated action options (4/11/18) · Satellite fallback condition (5/12/19) · Device identifier field (6/13/20) · ID cross-check mechanism (7/14)
Select a scenario to trace the transfer request through the satellite fraud-detection pipeline and see how the malfeasance value is computed and acted upon.
Beyond device identifier comparison, the system adds a geolocation layer as a dependent claim: the transfer processing component compares the geographic location of the transfer request against the geographic location of the device — derived from the satellite data packets themselves. Satellite communications inherently carry geolocation data (orbital geometry enables position derivation), giving the system a location signal independent of any GPS or cell-tower data.
If the transfer location and device location mismatch — a transfer claiming to originate from New York while the satellite data places the device in Southeast Asia — the geolocation discrepancy is added to the malfeasance value. This second scoring signal makes the fraud detection more robust: a fraudster who spoofs the device ID but cannot move the physical device to match the spoofed location will still trigger an elevated action through the location channel.
Satellite communications geometry provides a geolocation signal for the device independent of GPS or cell-tower data. Device location derived from satellite packet metadata.
Transfer request includes origination location — IP-geolocation, user-declared location, or device-reported coordinates. This is the location the system compares against.
Geographic mismatch contributes to the malfeasance value — added to any device-ID mismatch score. Two simultaneous signals: spoofed ID + wrong location = much higher composite value.
Location mismatch alone may not cross threshold. But combined with a device ID discrepancy, the composite malfeasance value reliably triggers elevated action — reducing false negatives.
The satellite fraud-detection channel solves a specific and growing problem: the expanding use of mobile payments in environments where cellular and internet connectivity are unreliable or deliberately unavailable. Satellite coverage is increasingly global and low-latency (LEO constellations), making the satellite fraud channel a practical real-time option for exactly the environments where traditional fraud detection fails.
No forward citations found as of this check. US12592768B2 was granted March 31, 2026 — roughly three months ago. Citation data has not yet accumulated. Verify the current list on Google Patents.
Patents 31 and 32 were filed on the same day (April 18, 2023) by the same sole inventor. Both were published as pre-grant applications on the same date (October 24, 2024). They address complementary roles for satellite communications in financial systems: P31 uses satellite as a fraud-detection channel, P32 uses satellite as the payment transmission channel itself.
The distinction is architectural: P31's satellite channel carries device data for verification — the payment itself may go through any available channel. P32's satellite channel carries the resource transmission request itself — satellite is the primary transmission medium for the payment, not just a verification sidecar. Together, they establish coverage for two different modes of satellite-enabled financial infrastructure: satellite as security layer and satellite as payment layer.
Satellite = second verification channel. Device data packets arrive via satellite for ID comparison. Activated when cellular/Wi-Fi unavailable. Malfeasance scoring and elevated action response.
Satellite = primary payment channel. Resource transmission request itself packaged and sent via satellite communication. Bandwidth-aware chunking, geo-triggered auto-release, and bidirectional transaction support.
Both patents address a world where LEO satellite networks (Starlink, OneWeb, etc.) provide global low-latency coverage — making satellite a practical real-time channel for financial operations, not just emergency backup.
P31 + P32 together cover satellite as both the security layer and the transaction layer for financial infrastructure. Two independent patents, two distinct inventions, coordinated filing strategy.