Portable Payment Device Unified Application for Transaction Speed
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing smartcards used in closed payment systems are slow in operation, limiting their effectiveness in contactless access points where transit time is short, and are not flexible enough to be used in open payment systems across multiple fields.
Innovation Solution
A program for a portable payment device that integrates payment and ticketing interactions into a single application, allowing for faster transactions by executing a unified code portion that handles both payment and ticketing functions, ensuring compatibility with existing access points and enabling use in open systems without the need for separate invocation of payment and ticket applications.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Speed
If separate payment and ticket applications are used in smartcards, then compatibility with existing access points is maintained, but operation speed is slow and multiple cards are needed
Solution Approach 1:
The patent combines separate payment and ticket applications into a single integrated application on the smartcard. The card now contains a unified application that can handle both payment transactions and ticketing operations, eliminating the need for separate applications and multiple cards. This integration directly addresses the speed issue by reducing application switching overhead while maintaining versatility through a single multi-functional application.
Solution Approach 2:
The smartcard application is designed with multi-functionality to perform both payment and ticketing operations within a single application framework. The application can dynamically switch between payment mode and ticketing mode based on the transaction type, making the card universally applicable for both closed payment systems and open ticketing systems without requiring separate dedicated applications.
2Adaptability or versatility
If smartcards are designed for closed payment systems, then specific field requirements are met, but flexibility to be used in open payment systems across multiple fields is limited
Solution Approach 1:
The smartcard application implements universality by designing a single application that can operate in both closed payment systems and open ticketing systems. The application contains integrated functionality for payment processing and ticketing operations, allowing the same card to be used across multiple fields such as transportation, retail, and events without requiring field-specific card variants.
Solution Approach 2:
The application employs dynamic behavior to adapt its functionality based on the transaction context. It can dynamically switch between payment mode and ticketing mode, and can adjust its operational parameters based on whether it's interacting with a closed payment system or an open ticketing system, thereby achieving flexibility without requiring complex hardware changes.
3Ease of operation
If contactless smartcards are used in transit systems, then convenience is improved, but short transit time at access points limits transaction completion
Solution Approach 1:
By merging payment and ticketing functions into a single application, the system eliminates the time required to switch between separate applications during transaction processing. The unified application structure allows immediate execution of the appropriate function (payment or ticketing) upon card presentation, maximizing the use of the short contactless transit time window at access points.
Solution Approach 2:
The application is pre-configured with both payment and ticketing capabilities ready for immediate execution. When the card is presented at an access point, the system can immediately begin the appropriate transaction without needing to load or switch applications, thereby utilizing the full contactless transit time efficiently and improving convenience.
Data Source
AI summary
A program for running on a processor of a portable payment device is adapted for carrying out a payment interaction and permitting ticket storage in a memory of the portable payment device. The program is configured to interact with an access point and includes a set of instructions, a first code portion and a second code portion. The set of instructions, when executed by the processor, causes the portable payment device to perform the steps of: responsive to a first message from said access point, executing the first code portion; and responsive to a second message from the access point, executing the second code portion. The first code portion includes first instructions corresponding to the payment interaction. The second code portion includes instructions corresponding to the payment interaction and second instructions corresponding to the ticket interaction.