Dynamic Transport Matching for Mass Egress Events

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing network-based transport services face inefficiencies in matching service providers with users at mass-egress locations, particularly during peak events, due to insufficient computational resources and lack of dynamic adaptation to changing demand and supply conditions.

Innovation Solution

A network system that employs dynamic pre-match determination and queue-based modes to identify and match service providers with users, utilizing historical data and real-time contextual information to optimize resource allocation and minimize disruptions, by pre-matching service providers in advance or selecting from a queue based on current availability.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If dynamic pre-match determination is implemented to pre-match service providers in advance, then service fulfillment reliability is improved, but computational resource consumption increases

Engineering Contradiction:
Improveservice fulfillment reliabilityVSAvoidcomputational resource consumption
Core Design Contradiction:
ReliabilityVSUse of energy by moving object

Solution Approach 1:

The system performs pre-match determination in advance of actual service requests by analyzing historical data and predicting future demand patterns. Service providers are pre-identified and positioned based on predicted service needs, allowing rapid response when actual requests occur without performing heavy computational analysis at the moment of request.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The system dynamically switches between pre-match mode and queue-based mode depending on real-time conditions such as event proximity, service provider availability, and demand patterns. This dynamic adaptation allows the system to optimize computational resource consumption by using pre-computed matches only when beneficial, while falling back to lighter queue-based processing when conditions change.

Inventive Principle:
Principle #15Dynamics

2Speed

If real-time matching is performed for every service request, then service responsiveness is improved, but system complexity increases

Engineering Contradiction:
Improveservice responsivenessVSAvoidsystem complexity
Core Design Contradiction:
SpeedVSDevice complexity

Solution Approach 1:

The matching system is segmented into two distinct modes: pre-match mode for advance service provisioning and queue-based mode for real-time matching. This segmentation allows each mode to be optimized independently, with pre-match handling bulk computational tasks in advance and queue-based handling providing rapid responsive matching when needed, reducing overall system complexity.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

By performing match determination in advance during pre-match mode, the system prepares service provider assignments before actual service requests occur. This preliminary action eliminates the need for complex real-time computational matching, simplifying the system's real-time response requirements while maintaining high responsiveness through pre-positioned service providers.

Inventive Principle:
Principle #10Preliminary action

3Productivity

If historical data is used for pre-match determination, then resource allocation efficiency is improved, but data processing requirements increase

Engineering Contradiction:
Improveresource allocation efficiencyVSAvoiddata processing requirements
Core Design Contradiction:
ProductivityVSQuantity of substance

Solution Approach 1:

The system performs historical data analysis and pattern recognition in advance during pre-match determination, extracting key insights about service demand patterns, provider availability trends, and optimal matching criteria. These pre-computed insights are stored and applied to future matching decisions, improving resource allocation efficiency without requiring heavy data processing during actual service requests.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The system extracts relevant patterns and insights from historical data during pre-match processing, separating the heavy data analysis work from real-time service requests. Only the essential matching criteria and provider recommendations derived from historical analysis are used during actual service fulfillment, significantly reducing real-time data processing requirements while maintaining high allocation efficiency.

Inventive Principle:
Principle #2Taking out (Extraction)

4Reliability

If service providers are pre-positioned at mass egress locations, then service availability is improved, but service provider downtime increases

Engineering Contradiction:
Improveservice availabilityVSAvoidservice provider downtime
Core Design Contradiction:
ReliabilityVSDuration of action of moving object

Solution Approach 1:

The system dynamically manages service provider status based on real-time conditions, switching between pre-match mode (where providers are positioned in advance) and queue-based mode (where providers respond to actual requests). This dynamic approach allows the system to optimize service availability by using pre-positioned providers during high-demand periods while minimizing downtime by allowing providers to be quickly reassigned when events conclude or demand changes.

Inventive Principle:
Principle #15Dynamics

Data Source

PatentUS20230039994A1Multi-staged event processing based on client device data
Publication Date: 2023.02.09 UBER TECHNOLOGIES INC
  • US20230039994A1 patent drawing
  • US20230039994A1 patent drawing
  • US20230039994A1 patent drawing

AI summary

A network computer system operates to determine one or more transport service parameters for an upcoming scheduled event at a mass egress location. One or more activities associated with the scheduled event are monitored to determine whether to update the one or more transport service parameters. Based at least in part on the one or more transport parameters, a set of relocation parameters is determined, including (i) an intermediate location where the service provider is to be located to provide the user with the transport service, and (ii) an intermediate arrival time when the first service provider is to arrive at the intermediate location before the pickup time. Based at least in part on a current location of a selected service provider and the intermediate arrival time, a relocation time when the service provider is to initiate travel to the intermediate location is determined.