Java Middleware for Mobile Payment Interoperability

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing mobile consumer electronics devices with wireless communications functionality lack interoperability and have limitations in security, user interface richness, and compatibility, making them inadequate for conducting cashless transactions across various devices and regions.

Innovation Solution

A wireless financial transaction system utilizing Java 2 Enterprise Edition (J2EE) enabled servers, Java software products, and smart cards to facilitate secure, interoperable, and user-friendly cashless transactions across different mobile devices, including cellular telephones, PDAs, and smart cards, through Java 2 Enterprise Edition (J2EE), Java 2 Standard Edition (J2SE), and Java 2 Micro Edition (J2ME) technologies, ensuring compatibility and security.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If WAP protocol is used for mobile transactions, then wireless communication capability is provided, but security is insufficient and interoperability is limited

Engineering Contradiction:
Improvetransaction securityVSAvoiddevice interoperability
Core Design Contradiction:
ReliabilityVSAdaptability or versatility

Solution Approach 1:

The patent applies Java technology as a universal platform that can run on multiple types of mobile devices (cellular phones, PDAs, laptops, etc.) regardless of their underlying operating systems or hardware configurations. This enables the same Java-based payment application to function across diverse devices, resolving the interoperability limitation of WAP while maintaining secure transaction capabilities through Java's built-in security model.

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

Solution Approach 2:

The patent introduces a Java Virtual Machine (JVM) as an intermediary layer between the mobile device hardware and the payment application. This JVM acts as a mediator that translates device-specific operations into standardized Java bytecode, enabling secure and consistent transaction processing across different device types while maintaining the security requirements of financial transactions.

Inventive Principle:
Principle #24Intermediary (Mediator)

2Adaptability or versatility

If I-mode protocol is used, then wireless data service is provided, but client-side scripting capability is limited and geographic availability is restricted

Engineering Contradiction:
Improvegeographic availabilityVSAvoidclient-side scripting capability
Core Design Contradiction:
Adaptability or versatilityVSEase of operation

Solution Approach 1:

Java technology provides a universal scripting environment that works across all geographic regions and device types. Unlike I-mode which is region-specific, Java-based mobile applications can be deployed globally on any Java-enabled device, providing both wide geographic availability and full client-side scripting capability through Java's programmability.

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

3Adaptability or versatility

If multiple vendor gateways are used for different devices, then device-specific functionality is achieved, but system complexity increases

Engineering Contradiction:
Improvedevice compatibilityVSAvoidgateway system complexity
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The patent employs Java as a universal gateway that can interface with multiple device types through a single standardized platform. Instead of requiring separate vendor-specific gateways for different devices, the Java virtual machine and Java application programming interface provide a unified gateway solution that handles device compatibility universally, significantly reducing system complexity.

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

Solution Approach 2:

The patent creates a homogeneous execution environment using Java bytecode that runs consistently across all mobile devices regardless of their hardware differences. This homogenization of the execution layer eliminates the need for multiple heterogeneous gateways, as all devices present a uniform interface to the payment application through the Java platform.

Inventive Principle:
Principle #33Homogeneity

4Duration of action of moving object

If WAP is used for offline operations, then constant air time is required, but this increases energy consumption and operational constraints

Engineering Contradiction:
Improveoffline operation capabilityVSAvoidair time consumption
Core Design Contradiction:
Duration of action of moving objectVSUse of energy by moving object

Solution Approach 1:

The Java-based payment application on the mobile device can perform local processing and validation of transactions without requiring constant connection to the network. The device itself services the transaction locally using Java's capabilities, only communicating with the network when necessary for authorization or settlement, thereby reducing air time consumption while maintaining offline operational capability.

Inventive Principle:
Principle #25Self-service

Data Source

PatentUS8793184B2Mobile payment services
Publication Date: 2014.07.29 VISA USA INC
  • US8793184B2 patent drawing
  • US8793184B2 patent drawing
  • US8793184B2 patent drawing

AI summary

A Java 2 Enterprise Edition (J2EE) enabled server executing Java software provides a financial transaction Web service to a client each of which communicates wirelessly with the J2EE enabled server and executes Java software to conduct financial transactions between a merchant and a consumer upon an account issued by an issuer to the consumer. Each financial transaction is submitted by the merchant to an acquirer for processing by a transaction handler/payment processor, and is submitted by the transaction handler/payment processor to the issuer to obtain a payment amount for the financial transaction from the account, and wherein the issuer forwards the payment amount of the financial transaction to the transaction handler/payment processor who forwards the payment amount of the financial transaction to the acquirer to pay the merchant for the financial transaction.