Parallel Service Data Processing in Mobile Payment Systems

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

In existing mobile payment systems, payers may not receive request messages for collection services in a timely manner, leading to wasted server resources, reduced processing speed, and poor user experience as they often directly perform payments outside the payment interface.

Innovation Solution

Implementing a method that determines whether received data associated with a service item exists within a predetermined time period, sets a confirmation label, and displays a message interface to users to confirm combining the data into the service item, allowing users to complete the service processing efficiently and releasing server resources.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Productivity

If the system waits for payers to enter the payment interface based on request messages, then service processing can be completed through the standardized interface, but server resources are wasted and processing speed is reduced when payers perform payments outside the interface

Engineering Contradiction:

Improveservice processing speedVSAvoidserver resource wastage

Core Design Contradiction:

ProductivityVSLoss of energy

Solution Approach 1:

The system performs preliminary actions by proactively detecting payment data in chat messages before the payer enters the payment interface. The server monitors incoming messages, identifies payment-related content, and prepares service items in advance, allowing the service to be completed without requiring the payer to navigate to the payment interface, thus preventing server resource wastage and improving processing speed

Inventive Principle:

Principle #10Preliminary action

Solution Approach 2:

The system enables self-service by allowing the chat message itself to carry the payment instruction. The payment data embedded in the chat message automatically triggers service item creation and processing, eliminating the need for the payer to manually enter the payment interface. The system serves itself by detecting and processing payment intentions directly from user messages

Inventive Principle:

Principle #25Self-service

2Productivity

If the system proactively detects and processes payment data in chat messages, then server resources are released and processing speed is accelerated, but the system complexity increases due to additional detection and confirmation mechanisms

Engineering Contradiction:

Improveserver processing speedVSAvoidsystem complexity

Core Design Contradiction:

ProductivityVSDevice complexity

Solution Approach 1:

The system segments the payment processing flow into distinct modules: chat message monitoring, payment data detection, service item creation, user confirmation, and service completion. Each module handles a specific task independently, making the complex system manageable and maintainable while achieving improved processing speed through parallel operation of these segmented functions

Inventive Principle:

Principle #1Segmentation

Solution Approach 2:

The system introduces an intermediary confirmation mechanism where the service provider receives notifications about detected payment data and must confirm whether to create service items. This intermediary step simplifies the overall system by providing a clear decision point and avoiding complex automated judgment logic, while still achieving rapid processing through the streamlined confirmation flow

Inventive Principle:

Principle #24Intermediary (Mediator)

3Ease of operation

If the system requires users to enter the payment interface to complete service items, then the payment process is standardized and secure, but user experience is reduced when users directly transfer payments in chat

Engineering Contradiction:

Improveuser experienceVSAvoidservice completion rate

Core Design Contradiction:

Ease of operationVSReliability

Solution Approach 1:

The system inverts the traditional payment flow by allowing service completion to initiate from the chat message rather than from the payment interface. Instead of requiring users to enter the payment interface to start the service process, the system detects payment data in chat messages and creates service items automatically, then seeks user confirmation. This inversion improves ease of operation while maintaining reliability through the confirmation step

Inventive Principle:

Principle #13The other way round (Inversion)

Data Source

PatentUS10831740B2Parallel processing of service data corresponding to multiple target objects

Publication Date: 2020.11.10 ADVANCED NEW TECHNOLOGIES CO LTD

AI summary

Implementations of the present disclosure include methods, apparatuses, and client devices for processing service data. Target data and target objects associated with a service item are determined. Service data associated with the target data is received from the plurality of target objects. For service data that was received within a predetermined time period, labeled data including the service data and a confirmation label is generated. An option to process the labeled data associated with the plurality of target objects in parallel is provided by a confirmation interface. In response to receiving a user input confirming parallel processing of the labeled data, completing service processing for the target objects.