Identity Server Mediator for Secure P2P Transfers
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing peer-to-peer payment systems require users to store and manage multiple bank account details, which is a barrier to adoption and has limited market penetration due to the complexity and security concerns.
Innovation Solution
A method that uses an identity server for authentication and session management, allowing users to perform peer-to-peer transfers without sharing payment credentials, utilizing biometric authentication and ephemeral session keys, and integrating with existing contact information systems to facilitate transactions without central storage of payment details.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Ease of operation
If users store and manage multiple bank account details for peer-to-peer payments, then payment functionality is enabled, but user burden and security concerns increase
Solution Approach 1:
The patent introduces a server as an intermediary that stores payee account details centrally. Instead of users managing multiple bank account details locally, the server acts as a mediator that holds this information and provides it during transactions. This resolves the contradiction by maintaining ease of operation while reducing the complexity burden on user devices.
Solution Approach 2:
The patent extracts the account detail storage function from user devices and places it on a dedicated server. By taking out the burden of storing and managing multiple bank account details from the user's device, the system maintains payment functionality while significantly reducing the complexity and security concerns associated with local storage of sensitive financial information.
2Productivity
If users obtain and input bank account details from multiple payees, then payment capability is achieved, but time and effort burden increases
Solution Approach 1:
The patent implements preliminary action by having users register payees in advance with their account details stored on the server. This preliminary registration creates a database of pre-approved payees, so when a user needs to make a payment, they simply select from the existing list rather than manually obtaining and inputting account details each time. This resolves the contradiction by enabling quick payment transactions while the initial setup time is invested once rather than repeatedly.
Solution Approach 2:
The patent uses copying by storing payee account information once on the server and reusing this copied information for multiple transactions. Instead of requiring users to re-obtain and re-input account details for each payment, the system creates a reusable copy of the payee information that can be quickly accessed and referenced for subsequent transactions, dramatically reducing the time and effort required for each payment.
3Ease of operation
If a common system stores payee account details centrally, then user burden is reduced, but security and trust concerns increase
Solution Approach 1:
The patent introduces a server as a trusted intermediary that securely stores payee account details. The server acts as a neutral party that neither the payer nor payee needs to trust with their full account information. The server mediates the transaction by providing account details only when needed and authorized, resolving the contradiction by enabling ease of use through centralized storage while maintaining security through the intermediary's controlled access model.
Solution Approach 2:
The patent extracts the sensitive account detail storage from the user's direct control and places it in a secure, dedicated server environment with specialized security measures. This separation allows the system to provide ease of operation through centralized management while addressing security concerns by isolating sensitive data in a protected location with controlled access, rather than requiring users to manage security themselves.
Data Source
AI summary
In a first party mode, a peer-to-peer transfer application: authenticates the party to an identity server; obtains an amount of funds to be transferred; causes the identity server to establish a session for storing information relating to the transaction; provides the amount to the identity server; provides account information for the party to the identity server; obtains a token unique to the transaction; obtains contact information for the counterparty; and provides a message including the token to the counterparty to indicate the transaction has been initiated. In a second counterparty mode, the application: receives a message including a token for a transaction from a first party; authenticates the counterparty; determines the counterparty wishes to complete the transaction; and uses the token to provide account information for the counterparty to the identity server for storing in association with an established session and to enable the identity server to complete the transaction.