Virtual Card Number Generation for Secure Friend-Paid Transactions

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Current systems lack a secure and assured mechanism for users to utilize a friend's or third-party cardholder's payment card for card-not-present transactions, risking sensitive information security and lacking guaranteed payment return options.

Innovation Solution

A computer system and method that processes card-not-present transactions by generating a virtual one-time use card number based on a friend's eligible card, ensuring secure sharing of card details and assured payment return through a server system that blocks and credits amounts dynamically, using a friend's card for transactions without disclosing actual card information.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Ease of operation

If card details are shared over open public channels (phone, email, text message), then the user can conveniently use a friend's card for transactions, but the sensitive card information becomes prone to fraudulent misuse

Engineering Contradiction:
Improveconvenience of using friend's cardVSAvoidfraudulent misuse of card information
Core Design Contradiction:
Ease of operationVSObject-affected harmful factors

Solution Approach 1:

The patent introduces a merchant server as an intermediary that facilitates the transaction without requiring direct sharing of card details between the user and friend. The system generates a virtual card number that acts as a mediator, allowing the transaction to proceed while keeping the actual card information secure and isolated on the merchant server.

Inventive Principle:
Principle #24Intermediary (Mediator)

Solution Approach 2:

The patent creates a virtual copy of the card information (virtual card number) that can be used for transactions without exposing the actual card details. This copy contains only the necessary transactional functionality while the original sensitive information remains protected on the merchant server.

Inventive Principle:
Principle #26Copying

2Object-affected harmful factors

If a friend or relative manually enters card details into a merchant terminal or website, then the card information remains more secure, but the cardholder must be physically present at the transaction site

Engineering Contradiction:
Improvesecurity of card informationVSAvoidphysical presence requirement
Core Design Contradiction:
Object-affected harmful factorsVSEase of operation

Solution Approach 1:

The system enables the cardholder to pre-register their card information with the merchant server in advance. This self-service registration allows the cardholder to set up the arrangement once, after which the user can conveniently initiate transactions without requiring the cardholder's physical presence or repeated manual entry of card details.

Inventive Principle:
Principle #25Self-service

Solution Approach 2:

The cardholder performs preliminary registration of their card information with the merchant server before any transactions occur. This advance setup stores the card details securely and establishes the framework for future transactions, eliminating the need for physical presence during actual purchasing events.

Inventive Principle:
Principle #10Preliminary action

3Adaptability or versatility

If informal arrangements are made between user and friend for card usage, then flexibility is maintained, but there is no obligation or assurance for the user to refund the payment amount to the friend

Engineering Contradiction:
Improveflexibility of arrangementVSAvoidassurance of payment refund
Core Design Contradiction:
Adaptability or versatilityVSReliability

Solution Approach 1:

The merchant server implements an automated feedback mechanism where the system actively manages the financial arrangement between user and cardholder. The server tracks transactions, calculates amounts owed, and automatically facilitates refunds or direct charging to the user's account, creating a closed-loop system that ensures repayment without requiring ongoing trust-based arrangements.

Inventive Principle:
Principle #23Feedback

Solution Approach 2:

The merchant server acts as a financial intermediary that mediates the payment relationship between the user and cardholder. Instead of relying on direct informal agreements, the server manages the funds, tracks obligations, and ensures repayment through automated processes, providing reliability while maintaining arrangement flexibility.

Inventive Principle:
Principle #24Intermediary (Mediator)

4Adaptability or versatility

If the merchant provides offers and rewards for specific card types, then card provider partnerships are strengthened, but users without eligible cards cannot access these benefits

Engineering Contradiction:
Improveaccess to offers and rewardsVSAvoidcard eligibility requirements
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The system provides universal access to merchant offers and rewards by allowing users to leverage their friend's eligible card through the virtual card number mechanism. The merchant server handles the complexity of card eligibility verification and reward allocation, making the benefit accessible to any user with a friend who has an eligible card, regardless of the user's own card status.

Inventive Principle:
Principle #6Universality (Multi-functionality)

Data Source

PatentUS11538043B2System and method for processing a card-not-present payment transaction by a purchaser using a friend's card for obtaining a reward
Publication Date: 2022.12.27 MASTERCARD INT INC
  • US11538043B2 patent drawing
  • US11538043B2 patent drawing
  • US11538043B2 patent drawing

AI summary

A server and method for processing a card-not-present transaction whereby a purchaser selects to use one or more friends' card to obtain a reward is disclosed. The server comprises at least a computer processor to: (i) receive, from a merchant server, a payment request including a contact mechanism for the friend(s); (ii) send a selection request to the friend(s) using the contact mechanism; (iii) receive, from the friend(s) a selection response including card number(s) eligible for the reward; (iv) request the issuer server(s) for authentication and blocking the amount; (v) track a cumulative amount dynamically and repeat steps (iii) and (iv) until equal to or greater than the payment amount; (vi) generate a virtual card number for one time use based on the card number(s); and (vii) send a payment response to the merchant server including the virtual card number for the purchaser to complete the transaction.