A mobile wallet authentication system that enables a secondary user profile to be accessed on a device where a primary user is already logged in — without requiring the primary user to log out, without exposing primary credentials to the secondary user, and without merging the two profiles' financial data or permissions.
Mobile wallet applications authenticate a single user per device session. When a second user needs to access their own wallet on the same device — a spouse using a family member's phone, a child accessing a linked account while a parent is logged in, a joint account holder checking a shared balance — the only option is for the primary user to log out completely, let the secondary user authenticate, and then log back in. This disrupts the primary session, risks credential exposure if the device is handed to the secondary user with the primary session active, and creates friction in legitimate multi-user scenarios.
The system maintains the primary user's authenticated session in a suspended state while a secondary authentication flow runs in a parallel context. The secondary user authenticates using their own credentials — the primary user's credentials are never involved and are not accessible during the secondary session. Once authenticated, the secondary user accesses a scoped view of wallet functionality determined by the intersection of their own account permissions and any access grants configured between the two profiles.
When the secondary session ends, the primary session resumes from its suspended state — no re-authentication required. The primary user's session data was never exposed to the secondary user at any point during the concurrent access period. The system logs both sessions independently for audit purposes, maintaining a clear separation of actions between the two authentication contexts.
The multi-profile session architecture maintains two cryptographically isolated session contexts on the device. The primary context holds the primary user's authentication token, session state, and account data. When a secondary access request is received, the primary context is suspended — its data is encrypted and inaccessible — and a new secondary context is created for the secondary authentication flow.
The two contexts share the device's hardware security module for credential verification but have completely separate session tokens, encrypted storage partitions, and UI state. The secondary context cannot read from or write to the primary context's storage partition. When the secondary session ends, the secondary context is securely cleared before the primary context is resumed — preventing any residual secondary session data from being accessible in the primary session.
The secondary authentication flow is initiated from the primary user's active session — either by the primary user explicitly granting secondary access, or by the secondary user presenting a recognized access request (QR code, NFC tap, or deep link from a companion device). The wallet application transitions the UI to a secondary access screen while suspending the primary session context in the background.
The secondary user authenticates using their own biometric or PIN — separate from and invisible to the primary user's credentials. The authentication is validated against the secondary user's account credentials, not the primary user's. On successful secondary authentication, the system checks whether the secondary user has an established access relationship with the primary user's account (for shared accounts) or proceeds as a fully independent session with no cross-account data access.
The scoped permissions system determines what wallet functionality and account data the secondary user can access during their session. Permissions are derived from two sources: the secondary user's own account entitlements (what they can access in their own right) and any explicit cross-profile grants established between the primary and secondary profiles (e.g., a shared account balance, a linked card, a delegated payment capability).
The UI rendered during the secondary session reflects only the secondary user's permitted scope — primary account balances, transaction history, payment methods, and profile details that are not explicitly shared are not accessible, not visible, and not fetchable via any API call from within the secondary session context. The permission boundary is enforced at the session layer, not just at the UI layer.
Secondary user can access their own wallet features — their own balance, cards, and transaction history — using their own authenticated session on the shared device.
If primary and secondary users have a configured shared account relationship, secondary sees the shared account data within the scope of that relationship's grants.
Primary user can pre-authorize specific delegated actions for the secondary session — e.g., secondary user may initiate one payment up to $X from a specific account.
Primary user's non-shared account balances, payment methods, transaction history, and profile details are inaccessible and not rendered in the secondary UI context.
Multi-profile mobile authentication addresses a class of legitimate shared-device scenarios that existing single-session wallet architectures force into insecure workarounds — credential sharing, incomplete logout, or simply prohibiting the scenario entirely.
The multi-profile authentication system is built around three security invariants that must hold throughout any concurrent access scenario. These invariants are enforced at the session architecture level, not merely at the UI level — they cannot be violated by application bugs that might allow the UI to render data from the wrong context.
Secondary authentication flow never has access to primary credentials. Primary biometric/PIN is not presented, not used, and not derivable from any data accessible in the secondary context.
Primary context's encrypted storage partition is inaccessible while secondary context is active. All API calls in the secondary context are made using the secondary session token — responses contain only secondary-scoped data.
Actions taken during the secondary session are logged against the secondary user's identity — not the primary user's. Audit records clearly distinguish which session performed which action, with no attribution ambiguity.
On secondary session exit, the secondary context is securely wiped before primary context is decrypted and resumed. No secondary session residue is accessible in the primary session.
The independent claims cover the multi-profile mobile authentication system — the dual-context session architecture, the mechanism for suspending the primary context while a secondary authentication flow runs, the secondary credential verification against the secondary user's own account, and the scoped permission enforcement that governs what the secondary user can access during their session.
Dependent claims cover the specific session isolation mechanism (encrypted storage partitions, separate session tokens), the permission derivation system (secondary own entitlements + cross-profile grants), delegated action capabilities (primary user pre-authorizing specific secondary session actions), and the secure context transition protocol that wipes secondary context before resuming primary. The claims are mobile-platform agnostic — the invention applies to any mobile wallet architecture supporting the described session management model.
US20260080392A1 is a pending application published in 2026. The application is currently under examination at the USPTO. Forward citations will be recorded after grant.