Dynamic Batch Allocation for Service Request Matching

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Current systems for managing transport-related service requests often encounter inefficiencies and non-optimal matching between users and service providers, particularly when considering multiple requests and providers over time and geographical areas, leading to suboptimal allocation of resources.

Innovation Solution

A processor-based system that batches service requests and providers, dynamically adjusts geographical regions and time periods based on demand and availability, and prioritizes matches based on likelihood of cancellation and fraud, to optimize the allocation of service requests to available service providers.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Speed

If service requests are processed individually in real-time, then response speed is improved, but matching optimality deteriorates

Engineering Contradiction:
Improveresponse speedVSAvoidmatching optimality
Core Design Contradiction:
SpeedVSManufacturing precision

Solution Approach 1:

The system segments service requests into batches based on temporal and geographical criteria. Requests are grouped into time periods and geographical regions, creating discrete batches that are processed collectively. This segmentation allows the system to balance individual request responsiveness with collective matching optimization by processing batches at optimized intervals rather than strictly in real-time or all at once.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The system implements periodic batch processing where requests are accumulated over defined time periods and then processed together. This periodic action creates a rhythm between data collection and matching execution, allowing the system to achieve optimal matching through collective processing while maintaining acceptable response times through appropriately configured batch intervals.

Inventive Principle:
Principle #19Periodic action

2Manufacturing precision

If batch size is increased to improve matching optimality, then resource allocation quality is improved, but processing time increases

Engineering Contradiction:
Improveresource allocation qualityVSAvoidprocessing time
Core Design Contradiction:
Manufacturing precisionVSLoss of time

Solution Approach 1:

The system divides the batch processing into smaller sub-batches based on geographical regions and time periods. This segmentation prevents excessive processing time by limiting the scope of each batch while still achieving collective optimization within each segment. Multiple segmented batches are processed in parallel or sequence, maintaining overall efficiency while improving allocation quality through multi-dimensional grouping.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The system introduces additional dimensions for batch organization beyond simple time-based grouping, including geographical regions, service types, and provider categories. This multi-dimensional batching strategy allows the system to create smaller, more focused batches that can be processed quickly while still achieving comprehensive resource allocation optimization across all dimensions.

Inventive Principle:
Principle #17Another dimension (Dimensionality change)

3Adaptability or versatility

If dynamic batch adjustment is implemented to improve adaptability, then system flexibility is improved, but computational complexity increases

Engineering Contradiction:
Improvesystem flexibilityVSAvoidcomputational complexity
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The system dynamically adjusts batch parameters including time period duration, geographical region boundaries, and batch formation criteria based on real-time demand patterns, provider availability, and historical data. This dynamic adaptation allows the system to respond to changing conditions while maintaining manageable computational complexity through incremental adjustments rather than complete recalculation.

Inventive Principle:
Principle #15Dynamics

Solution Approach 2:

The system incorporates feedback mechanisms that monitor matching outcomes, provider acceptance rates, and user satisfaction metrics to continuously refine batch parameters. This feedback-driven adaptation improves system flexibility by learning from actual performance data while controlling computational complexity through iterative optimization rather than exhaustive analysis.

Inventive Principle:
Principle #23Feedback

4Productivity

If prioritization based on cancellation likelihood is added, then resource allocation efficiency is improved, but system complexity increases

Engineering Contradiction:
Improveresource allocation efficiencyVSAvoidsystem complexity
Core Design Contradiction:
ProductivityVSDevice complexity

Solution Approach 1:

The system performs preliminary analysis of service requests to assess cancellation likelihood, provider availability, and matching priority before batch formation. This preliminary action allows the system to pre-sort and prioritize requests within batches, ensuring that high-priority matches are processed first while maintaining overall system efficiency without requiring complex real-time reordering during batch processing.

Inventive Principle:
Principle #10Preliminary action

Data Source

PatentUS11928752B1Allocation of dynamically batched service providers and service requesters
Publication Date: 2024.03.12 GRABTAXI HOLDINGS PTE LTD
  • US11928752B1 patent drawing
  • US11928752B1 patent drawing
  • US11928752B1 patent drawing

AI summary

A processor device has a CPU cooperating with an input device and an output device, under control of stored instructions, and is arranged to receive service requests at the input device, assign service requests received in successive time periods to respective batches of requests; access stored service provider data to identify available service providers from among a pool of service providers; after completing the assignment of service requests to a batch, perform a matching process to endeavour to match each service request of the batch of requests to a service provider; and for each service provider to whom a match is made, output a notification of the respective potential match from the output device.