Hybrid Tokenization for Push Payment Security

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing funds transfer systems lack adequate security measures to protect sensitive payment account information from exposure during transactions, which poses a risk of unauthorized access and exploitation.

Innovation Solution

A token-based system where a user's payment account is represented by a token stored on a transaction originator server, with a mobile device bound to the token using a split authentication code process, ensuring secure initiation and execution of funds transfer transactions by tokenizing payment credentials and shielding actual account information.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If payment account information is transmitted during funds transfer transactions, then transaction functionality is enabled, but security risk increases due to exposure of sensitive information

Engineering Contradiction:
Improvetransaction securityVSAvoidexposure of sensitive payment information
Core Design Contradiction:
ReliabilityVSObject-affected harmful factors

Solution Approach 1:

The authentication code is divided into two separate parts: a first part transmitted to the user's device via push notification, and a second part transmitted to the transaction originator. Both parts are required to complete the transaction, preventing unauthorized use of either part alone and eliminating the need to transmit sensitive payment account information across the network.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

A token is introduced as an intermediary that represents the payment account on the transaction originator server. The token can be bound to the user's device through the split authentication process, allowing transactions to proceed without exposing the actual payment account number. The token acts as a mediator between the payment account and the transaction system.

Inventive Principle:
Principle #24Intermediary (Mediator)

2Productivity

If payment account information is stored on the transaction originator server, then transaction processing is simplified, but security vulnerability increases due to potential interception or improper appropriation

Engineering Contradiction:
Improvetransaction processing efficiencyVSAvoidrisk of interception or improper appropriation
Core Design Contradiction:
ProductivityVSObject-affected harmful factors

Solution Approach 1:

Instead of storing the actual payment account information, the system stores a token that copies the essential functionality of the payment account. The token can be bound to the user's device through the split authentication process, allowing the transaction originator to process transactions efficiently without holding sensitive payment account data that could be intercepted or misappropriated.

Inventive Principle:
Principle #26Copying

3Ease of operation

If authentication code is transmitted in a single part to the device, then user operation is simplified, but security is weakened due to potential compromise of the entire code

Engineering Contradiction:
Improveuser operation simplicityVSAvoidauthentication security
Core Design Contradiction:
Ease of operationVSReliability

Solution Approach 1:

The authentication code is segmented into two parts with distinct distribution paths: the first part is sent to the user's device via push notification, while the second part is sent to the transaction originator. Both parts must be combined to complete authentication, maintaining user-friendly operation while significantly enhancing security through the split structure.

Inventive Principle:
Principle #1Segmentation

Data Source

PatentUS12099987B2Hybrid tokenization for push payments
Publication Date: 2024.09.24 MASTERCARD INT INC
  • US12099987B2 patent drawing
  • US12099987B2 patent drawing
  • US12099987B2 patent drawing

AI summary

A method of performing a funds transfer includes receiving a request for a cryptogram and generating an authentication code. The authentication code is divided into a first code portion and a second code portion. The first code portion is transmitted to a user device. The second code portion is transmitted to a transaction originator. A request for transaction data is received, including both code portions. The authentication code is verified based on the two code portions. A cryptogram is generated and transmitted to the transaction originator.