Patent 36 / Rules-Based Transaction Auth
01 / 11 US11544718B2
↑↓ navigate  ·  all patents →
Siten Sanghvi  ·  Granted Jan 3, 2023

Rules-Based Transaction Auth

A two-tier authentication framework for Point of Sale transactions that evaluates contextual parameters — time window, device-edge pairing, geolocation, device identifier, and prior transaction count — before authorizing an electronic payment. First-tier match authorizes; second-tier fallback provides a broader evaluation path.

US11544718B2Patent
Sep 17, 2021Filed
15 monthsTime to grant
9 Claims / 3 independentScope
0 CitationsForward citations
SCROLL TO EXPLORE
Visual patent explainer
02 / The Problem

POS authorization is binary — approve or decline — with no contextual awareness between those two outcomes.

Traditional Point of Sale authentication verifies a payment instrument (card number, token, PIN) and approves or declines. It has no mechanism to evaluate the contextual signals surrounding the transaction: Was this the right time of day? Is this device known to be paired with this terminal or edge-node? Is the user's location consistent with their history? Is this transaction count within expected norms?

Context BlindnessAuthentication decisions ignore geolocation, device pairing history, time windows, and prior transaction frequency — signals that together distinguish legitimate from anomalous transactions
No Graduated ResponseA failed primary check means decline — there is no second evaluation path that can catch transactions that are legitimate under a different rule set
Static RulesAuthorization parameters are fixed per merchant or network — they don't adapt to the user's specific device, location, or behavioral pattern
03 / The Invention

Two parameter sets, two authorization paths — context determines which rule chain is evaluated first.

The system receives a payment authorization request from a POS device with both the payment information and the purchase amount. It maintains a first parameter set and a second parameter set. Authorization follows a decision tree: if the first parameters are satisfied, the transaction is authorized. If not, the system evaluates the second parameters before deciding. This two-tier structure enables context-sensitive authorization without requiring a single rigid rule.

The first parameter set includes conditions like a time window (the transaction must occur within a defined time range), a device-edge pairing (the device must be paired to a known edge apparatus), and a geolocation check. The second parameter set provides a fallback evaluation path for transactions that don't match the primary context but may still be legitimate under different criteria.

04 / Architecture

POS request → parameter evaluation → first-tier match → authorize or escalate to second tier.

The authentication computing platform receives the POS request, extracts contextual signals alongside the payment data, and evaluates them against the configured parameter sets. The evaluation is sequential: first parameters are checked before second parameters — ensuring the most restrictive or most common valid context is evaluated first.

The platform maintains both parameter sets per user or device, enabling highly personalized rules. A frequent commuter's morning transaction at a known terminal gets a first-parameter match immediately; an unusual out-of-region transaction might pass on second-parameter criteria that account for the user's historical travel pattern.

Architecture — US11544718B2
POS device sends
request + amount
Auth platform
receives request
Evaluate first
parameter set
Satisfied → Authorize
|
Not satisfied →
Evaluate second set
05 / First Parameters

Five contextual conditions define the primary authorization path.

The first parameter set contains the primary authorization criteria. Each condition represents a contextual signal that, when satisfied in combination, confirms the transaction is consistent with the user's known behavior. All first-parameter conditions must be satisfied for the primary path to succeed; failure of any condition routes to the second-tier evaluation.

First Parameter Set — US11544718B2
P1.1
Time Window — The transaction must fall within a defined time range (e.g., weekday business hours, usual transaction window for this user)
P1.2
Device-Edge Pairing — The electronic device must be paired to a known first apparatus (edge-node or terminal with an established trust relationship)
P1.3
Geolocation — The transaction location must match a first geolocation (home region, known merchant area, or prior transaction zone)
P1.4
Device Identifier — The requesting device must match a registered device ID on file for this user
P1.5
Prior Transaction Count — The number of prior transactions in the relevant window must fall within the expected range for this user
06 / Second Parameters

A second evaluation path catches legitimate transactions that don't match the primary context.

When the first parameter set is not satisfied, the system evaluates a second parameter set before declining. The second set is configured with different criteria — potentially broader geolocation bounds, a longer time window, or different device pairing requirements — capturing transactions that are legitimate under a different contextual rule.

This two-tier structure prevents false declines for users operating outside their normal context (traveling, using a new device, transacting at an unusual time) while maintaining the primary protection of the first-tier rules for standard usage. The platform authorizes on second-parameter match; declines only when both sets fail.

Two-Tier Decision Logic — US11544718B2

First-Tier Match

All five primary parameters satisfied → immediate authorization. This is the fast path for standard user behavior — low friction, high confidence.

First-Tier Fail

One or more primary parameters not satisfied → evaluate second parameter set. No immediate decline — the fallback path is always evaluated before rejection.

Second-Tier Match

Second parameter set satisfied → authorize with potential additional verification step. Covers out-of-context but legitimate transactions (travel, new device).

Both Tiers Fail

Neither parameter set satisfied → decline or escalate to manual review. Both contextual paths exhausted — transaction inconsistent with known user patterns.

07 / Device-Edge Pairing

Trust between the user's device and the edge apparatus is a primary authorization signal.

The device-edge pairing parameter (P1.2) is a distinguishing element: it requires not just that the user's device be recognized, but that it has an established pairing with the specific edge apparatus (terminal, kiosk, or edge-node) handling the POS request. This pairing adds a physical-layer trust signal beyond device identity alone.

A user's device paired to a known edge apparatus at their regular merchant represents a high-confidence combination — the device is recognized, and it's physically co-located with a trusted piece of infrastructure. This two-factor location confidence — device identity plus edge pairing — is a stronger signal than geolocation alone.

Pairing Signal in Auth Stack — US11544718B2
User device
(device ID)
Edge apparatus
(terminal / kiosk)
Pairing confirmed
in trust registry
P1.2 parameter
satisfied
Contributes to
first-tier authorization
08 / Behavioral Signals

Prior transaction count adds a behavioral layer — not just who, but how consistently.

The prior transaction count parameter (P1.5) adds a behavioral dimension to the authentication decision: not just "is this device legitimate?" but "is this pattern of transactions consistent with how this user normally behaves?" A sudden spike in transaction count, or a first transaction on a new device at a known location, each carry different risk profiles that the parameter set can encode.

The time window parameter (P1.1) works in concert with transaction count: a high count within a very short window at an unusual time is a different risk profile than the same count spread across a normal usage session. The parameter set framework allows these combinations to be expressed as explicit rules rather than ML thresholds — making authorization logic auditable and configurable per user.

Behavioral Parameters — US11544718B2

Time Window (P1.1)

Transaction must occur within the defined time range for this user. Morning commuter window, business hours, travel window — each maps to a different time parameter.

Transaction Count (P1.5)

Number of prior transactions in the relevant window must be within expected bounds. Prevents burst-pattern fraud where a stolen credential triggers rapid sequential charges.

Geolocation (P1.3)

Transaction location must match a known geolocation for this user. Customizable granularity — city, region, or specific merchant address — depending on user risk profile.

Combined Scoring

All five parameters are evaluated as a set, not individually. A transaction can fail one parameter but still match the overall first-tier pattern — or require all five to be satisfied simultaneously.

09 / Applications

Context-aware POS authorization that adapts to the user's known behavioral pattern.

The two-tier parameter framework replaces binary pass/fail authorization with a graduated, context-sensitive evaluation — reducing false declines for legitimate users while maintaining strong protection against out-of-pattern transactions.

Use Cases — US11544718B2
Express
Regular Merchant Fast Auth User transacts at their regular coffee shop at 8am on weekday. All five first-parameter conditions match: time window, edge pairing, location, device ID, expected count. Single-pass authorization — no additional friction.
Express
Travel Fallback Auth Same user transacts in a foreign city. First-tier fails (location mismatch). Second-tier parameters include a broader geolocation bound and a travel-mode flag set earlier in the session. Second-tier matches → authorized with step-up verification.
Inferred
New Device Onboarding User's new phone lacks the device-edge pairing history. First-tier fails on P1.2. Second-tier parameters include an alternative identity verification path that doesn't require prior pairing — enabling seamless first use.
Inferred
High-Frequency Fraud Block Stolen credential triggers 12 rapid transactions. Prior transaction count (P1.5) exceeds the threshold. First-tier fails. Second-tier also fails on count. Both tiers exhausted → decline and alert.
10 / Citations

0 Forward Citations

No forward citations on record as of June 2026. The two-tier contextual POS authentication framework is a recent continuation grant — citations typically accumulate over 2–3 years as examiners and practitioners reference the published claims.

Forward citations confirmed via Google Patents · Jun 2026
Citation Status — US11544718B2
No citations yet — recently granted US11544718B2 granted Jan 3, 2023 Citations typically begin accumulating 18–36 months post-grant
11 / Timeline

Patent Lifecycle

Sep 17, 2021
Filed
Continuation application filed — priority Jul 9, 2019
4 months
Jan 6, 2022
Published
Pre-grant publication US20220005037A1
12 months
Jan 3, 2023
Granted
US11544718B2 granted — 15 months from filing
~18 years
~Sep 2041
Expires
Est. expiration (subject to maintenance fees)
End / Patent 36