U.S. Patent Position Review — 19/476,586
DATA COMMUNICATIONS NETWORK AND METHOD FOR PROVIDING TASK SCHEDULES TO SERVICE PROVIDERS
Published international application: PCT/AU2024/050370 / WO2024216337A1
Section 19 — TR-19
Taskrabbit — Patent Position Mapping
A single consolidated view of the function-by-function analysis. Each row states the architectural element, the position described by the application, the publicly observed Taskrabbit position, the classification reached, the difference identified and the confidence in the underlying public evidence.
Master Taskrabbit Patent Overlap Matrix
Technical Correspondence Indicator — Not an Infringement Assessment. Select a row to open the evidence, the identified material difference and the point at which the patent architecture extends beyond publicly established functionality.
| Function | Patent basis | Taskrabbit function | Evidence | Strength | Technical correspondence | Review status |
|---|---|---|---|---|---|---|
| Customer Task | Receipt of details relating to one or more tasks requiring completion | Task category selection, search and task description at booking | TR-E011 | High | Strong Observed Correspondence | Reviewed |
| Task Location | Task to be completed at a particular location | Customer task address; start/end address in some categories | TR-E011, TR-E006 | High | Strong Observed Correspondence | Reviewed |
| Provider Skill | Provider information confirming ability to provide particular services | Tasker declared skills and operating categories | TR-E012, TR-E013 | High | Strong Observed Correspondence | Reviewed |
| Provider Qualification | Qualification confirming ability to provide particular services | Category- and state-dependent licensing certification | TR-E012 | Medium | Partial / Requires Technical Analysis | Further Analysis |
| Provider Experience | Experience confirming ability to provide particular services | Skills & Experience profile section shown to customers | TR-E012, TR-E011 | High | Strong Observed Correspondence | Reviewed |
| Provider Work Area | Provider preferred geographic region | Tasker Work Area Map affecting visibility and invitations | TR-E014 | High | Strong Observed Correspondence | Reviewed |
| Provider Availability | Available or preferred times and dates of the provider | Tasker calendar blocks; unavailability removes the Tasker from search | TR-E015, TR-E016 | High | Strong Observed Correspondence | Reviewed |
| Provider Subset | Generation of a subset of suitable providers | Customer-visible Tasker list produced algorithmically | TR-E017 | High | Strong Observed Correspondence | Further Analysis |
| Algorithmic Filtering | Filtering of providers on relevant provider and task information | Availability, Work Area, category, price and business metrics | TR-E017 | High | Strong Observed Correspondence | Reviewed |
| Provider Ranking | Ordering of suitable providers presented to the service recipient | Search position stated to be influenced by performance and business metrics | TR-E017, TR-E021 | Medium | Partial / Requires Technical Analysis | Further Analysis |
| Customer Provider Selection | Selection of a particular provider from the suitable subset | Customer selects a Tasker from presented results | TR-E011, TR-E018 | High | Strong Observed Correspondence | Reviewed |
| AI Task Duration | AI technique assigning a recommended amount of time to complete the task | No public source identified | TR-E005, TR-E006 | None Identified | Not Publicly Established | Evidence Required |
| Price Estimation | Computational processing of task and location information | Estimate API returns eligibility and estimated price | TR-E005 | High | Partial / Requires Technical Analysis | Further Analysis |
| Appointment Availability | Determination of times at which the task may be scheduled | Availability API returns real-time date/time windows | TR-E006 | High | Strong Observed Correspondence | Reviewed |
| Schedule Generation | Generation and provision of a task schedule to the provider | Bid creates a project agreement; Book completes the booking | TR-E007, TR-E008, TR-E009 | High | Partial / Requires Technical Analysis | Further Analysis |
| Rescheduling | Adjustment of an existing task schedule | Customer and Tasker agree a new time, then confirm in the platform | TR-E019 | High | Partial / Requires Technical Analysis | Further Analysis |
| Replacement Provider | Identification of an alternative suitable provider | Rebooking flow can offer a new Tasker after cancellation | TR-E018 | Medium | Partial / Requires Technical Analysis | Further Analysis |
| Multi-Task Scheduling | Construction of a provider schedule across multiple tasks | No sufficient public evidence identified | TR-E015 | None Identified | Not Publicly Established | Evidence Required |
| Route Optimisation | Travel and routing considered in schedule construction | No sufficient public evidence identified | — | None Identified | Not Publicly Established | Evidence Required |
| Historical Performance | Punctuality, schedule maintenance and ratings held as provider history | Reviews, completed tasks, invitations, invoices, performance score, Elite status | TR-E020, TR-E021 | High | Strong Observed Correspondence | Reviewed |
| Future Performance-Based Scheduling | Provider performance assessment adjusting future task schedules | No public source identified | TR-E020 | None Identified | Not Publicly Established | Evidence Required |
| AI Service Discovery | Machine-mediated receipt of a service requirement | Taskrabbit available through Claude in the United States (23 April 2026) | TR-E010 | High | Partial / Requires Technical Analysis | Monitoring |
| Agentic Orchestration | Coordinated automated orchestration of the service lifecycle | No public source identified | TR-E010 | None Identified | Not Publicly Established | Monitoring |
Customer Task Capture
Patent position
Task information is received over a data communications network from a service recipient, including identification of the task, the service location and scheduling parameters.
Taskrabbit position
The booking flow captures a service category or search term, a free-text description, the service address, and a preferred date and time before any Tasker is shown.
Difference / gap
Structuring is achieved largely through guided taxonomy input rather than through any disclosed derivation from the customer's own words.
Patent architecture beyond observed functionality
Conversion of captured input into a derived requirement set — required capability, recommended duration, sub-task sequence — is contemplated architecturally but not publicly established here.
Provider Skills
Patent position
Service provider records maintained within the network include skills information used, with other provider data, to identify a subset of suitable providers.
Taskrabbit position
Taskers select the service categories and skill areas they wish to work in during registration; those selections determine the tasks they may be offered.
Difference / gap
Capability is self-declared rather than assessed, so the record describes what a provider elects to do, not what they have been verified as able to do.
Patent architecture beyond observed functionality
Qualification-class records used as matching constraints, and capability inference from completed-task evidence, are not publicly established.
Provider Experience & Qualifications
Patent position
Provider records include qualifications and experience, which contribute with skills and availability to the identification of suitable providers.
Taskrabbit position
Public profiles display completed-task counts, review text, ratings and, in several categories, category-specific experience statements.
Difference / gap
The architecture treats qualifications as data within the provider record; public material treats licensing as a contractual responsibility of the provider.
Patent architecture beyond observed functionality
Structured credential-class records, licence validation at task level, and performance-derived suitability prediction are architectural elements not established in public material.
Geographic Matching
Patent position
Provider records include a geographic region in which the provider is willing to work, and that region is used with the service location to identify suitable providers.
Taskrabbit position
Taskers configure the areas in which they will work, and the platform describes results as constrained by that work area.
Difference / gap
Public material evidences geography as a binary eligibility test; the architecture contemplates geography also informing schedule construction and sequencing.
Patent architecture beyond observed functionality
Travel-aware and clustering uses of geography — grouping nearby tasks, weighting candidates by route efficiency — are not publicly established for Taskrabbit.
Provider Availability
Patent position
Provider records include time and date availability, and a task schedule is generated consistent with that availability and transmitted to the provider.
Taskrabbit position
Taskers set a calendar with multiple availability blocks per day and can adjust it, with public material describing availability as affecting eligibility for work.
Difference / gap
Public material evidences availability at the level of a single engagement; the architecture contemplates availability as a resource consumed across a constructed schedule.
Patent architecture beyond observed functionality
Availability as an optimisation resource — allocated to maximise utilisation across a provider's day — is not publicly established.
Provider Filtering & Identification
Patent position
A subset of service providers suitable for the task is identified from the provider records using task requirements, skills, geographic region and availability.
Taskrabbit position
Provider-facing material indicates that the ordering of Taskers may reflect availability, work area, selected categories, hourly rate and business performance metrics.
Difference / gap
Identification does not itself determine the provider; it determines who may be chosen.
Patent architecture beyond observed functionality
System-determined selection producing a schedule without a human choice step is contemplated architecturally and is not publicly established.
Customer Provider Selection
Patent position
The identified subset of suitable providers is used to produce a task schedule for a service provider.
Taskrabbit position
Customers compare Taskers by hourly rate, rating, review text, completed-task counts, stated skills and the windows each provider can offer.
Difference / gap
Decision authority sits with the customer, so the schedule follows a human choice rather than a system determination.
Patent architecture beyond observed functionality
System-determined provider selection producing an issued schedule is contemplated architecturally and is not publicly established here.
Task Duration Intelligence
Patent position
An amount of time required to complete the identified task is assigned and used in generating the task schedule.
Taskrabbit position
Work is generally billed hourly against the Tasker's rate, with the customer shown an estimate before booking and the final amount reflecting time actually worked.
Difference / gap
The architecture assigns the duration; the observable product appears to receive it from the parties.
Patent architecture beyond observed functionality
AI-assisted, historically informed duration determination is a clearly identified area where the patent architecture extends beyond publicly established Taskrabbit functionality.
Pricing & Estimation
Patent position
The assigned amount of time required to complete a task is used in generating the schedule; no claimed element is directed to price determination.
Taskrabbit position
Partner integration material describes obtaining an estimate for a service at a validated address before availability is retrieved.
Difference / gap
Price estimation answers what it will cost; duration estimation answers how long it will take. Only the latter is an element of the architecture.
Patent architecture beyond observed functionality
Duration-derived pricing, and pricing that accounts for travel and sequencing cost, are not publicly established.
Scheduling
Patent position
A task schedule is generated for the selected service provider and transmitted to that provider over the data communications network.
Taskrabbit position
Booking produces a confirmed appointment issued to both parties and surfaced as a managed project in the application.
Difference / gap
The schedule is constructed for a single engagement chosen by the customer rather than composed by the system across a provider's day.
Patent architecture beyond observed functionality
Multi-engagement schedule composition and automatic retransmission on change are contemplated architecturally and are not publicly established.
Rescheduling & Schedule Management
Patent position
The generated task schedule is transmitted to the provider; the claimed elements are directed to generation and transmission rather than to post-booking recovery.
Taskrabbit position
A confirmed appointment can be rescheduled or cancelled in the application, with rescheduling described as agreed between the customer and the Tasker.
Difference / gap
No system-generated replacement schedule is evidenced; the architecture contemplates updated schedules being produced and transmitted.
Patent architecture beyond observed functionality
Automated rescheduling, substitute-provider selection and schedule reconstruction after disruption are labelled Potential Future Patent Development — Subject to Patent Attorney Review where they extend past existing disclosure.
Multi-Task & Route Optimisation
Patent position
A task schedule is generated for a provider consistent with availability, location and the assigned duration.
Taskrabbit position
Providers accept engagements individually and manage their own travel between them; guidance addresses allowing time between tasks rather than the platform doing so.
Difference / gap
Booking one provider for one customer does not require sequencing, travel modelling or optimisation; the architecture contemplates schedule construction under those constraints.
Patent architecture beyond observed functionality
Geographic clustering, travel-time calculation, traffic-aware scheduling, provider-day optimisation and multi-customer schedule construction are all areas where the architecture extends beyond publicly established functionality.
Performance & Historical Intelligence
Patent position
Provider records used in identifying suitable providers may include information about the provider held within the network.
Taskrabbit position
Ratings, review text and completed-task counts are displayed on profiles and are visible at the point of customer selection.
Difference / gap
Historical data appears to be used for visibility and trust rather than as an input to scheduling determinations.
Patent architecture beyond observed functionality
Predictive use of historical performance — suitability, duration correction, completion probability — is not publicly established.
AI & Agentic Technology
Patent position
The assigned amount of time required to complete a task may be determined with the assistance of artificial intelligence.
Taskrabbit position
Marketplace search and algorithmic ordering are evidenced today, and provider-facing material describes factors influencing results.
Difference / gap
The architecture places AI at the interpretation and duration layers; observable AI activity concerns discovery and access.
Patent architecture beyond observed functionality
AI-assisted duration determination and agentic schedule orchestration are contemplated by the architecture and are not publicly established.
Reading This Mapping
Classifications carry the analytical weight in this review. The alignment indicator is a coarse visual aid only and should not be cited on its own or aggregated into an overall figure. Technical alignment is an analytical assessment of publicly observable functionality and does not constitute a legal conclusion regarding infringement.