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 05 — TR-05
Customer Task Capture
How Taskrabbit receives and structures a customer's service requirement — what is to be done, where, under what constraints and when — and converts it into parameters usable by downstream identification and scheduling.
Executive Finding
Taskrabbit captures category, task description, service address, supplies, access constraints and preferred timing before any provider is presented, corresponding closely to the service-recipient and task-information layer of the patent architecture.
Observed Workflow
- Category / Search
- Task Description
- Service Address
- Supplies, Parking & Access
- Budget / Time Constraints
- Date & Time Preference
- Provider Options Presented
Patent Question
How closely does Taskrabbit's publicly documented customer input workflow correspond to the customer/task input components of United States Patent Application No. 19/476,586 — DATA COMMUNICATIONS NETWORK AND METHOD FOR PROVIDING TASK SCHEDULES TO SERVICE PROVIDERS?
Patent Architecture Sequence
- Task
- Location
- Computational Processing
Patent Position
United States Patent Application No. 19/476,586 — "DATA COMMUNICATIONS NETWORK AND METHOD FOR PROVIDING TASK SCHEDULES TO SERVICE PROVIDERS"
Claimed Patent Element
- Task information is received over a data communications network from a service recipient, including identification of the task, the service location and scheduling parameters.
- Received task information is held as structured data and forms the operative input to identification of suitable service providers.
Specification / Embodiment Disclosure
- The specification describes task information extending to task attributes such as scope, materials, access and constraints affecting the work to be performed.
- Embodiments contemplate task information arriving from a service-recipient interface or from another system over the network.
Potential Future Patent Evolution
Potential Future Patent Development — Subject to Patent Attorney Review.
- Interpretation of unstructured task description into a derived requirement set, task decomposition and required-capability inference.
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.
- Category-specific fields capture task size or scope, whether supplies are required, parking or access notes and, in some categories, budget constraints.
- Recurring or repeat engagements are supported in certain categories, with the captured task record carried through to confirmation and in-application management.
Public Evidence
Each record below opens the full source entry — extract, publication and access dates, direct URL and archived URL where available — without leaving this analysis.
Technical Alignment
- Content and ordering of the captured parameters correspond to the patent's task-information layer: what, where, when and under what constraints.
- Address and timing operate as filtering inputs rather than as display fields, which is the functional role the architecture assigns them.
- A single task record persists through selection, booking and management, consistent with the orchestrated model rather than with discrete transactions.
Difference / Gap
- Structuring is achieved largely through guided taxonomy input rather than through any disclosed derivation from the customer's own words.
- The patent treats capture as the first stage of a derivation pipeline; public Taskrabbit material does not describe a derivation stage.
Where Public Evidence Is Incomplete
- Whether free-text task description is parsed into structured requirements internally is not publicly disclosed.
- Whether captured constraints such as parking or supplies operate as matching variables or only as information passed to the provider is not established.
Patent \u2194 Taskrabbit Mapping
| Patent element | Taskrabbit position | Status |
|---|---|---|
| Customer task requirement | Taskrabbit task category / request | Strong Observed Correspondence |
| Task location | Taskrabbit task address (start/end address in some categories) | Strong Observed Correspondence |
| Customer scheduling requirement | Date / time selection against Tasker availability | Strong Observed Correspondence |
| AI interpretation of task complexity | Not described in public material | Not Publicly Established |
Field Qualification
- Task description, additional requirements and start/end addresses are category-dependent. They are not asserted here as universally required fields.
- Public evidence establishes the presence and sequence of the input fields; it does not establish how those fields are processed after submission.
What Task Input Does Not Establish
- AI interpretation of task complexity.
- AI determination of recommended task duration.
- Automated task decomposition into sub-tasks.
- Automated provider-day optimisation.
Patent Architecture Beyond Publicly Observed Functionality
The following matters are contemplated by the patent architecture and have not been established from Taskrabbit's public material. Absence of public evidence is not evidence that the functionality is absent from the company's internal technology stack.
- Conversion of captured input into a derived requirement set — required capability, recommended duration, sub-task sequence — is contemplated architecturally but not publicly established here.
Evidence Confidence
The capture sequence is directly observable in the public booking flow without an account, is reproducible across categories, and is corroborated by customer help documentation.
Strategic Interpretation
- Capture is the point at which a marketplace either becomes a data system or remains a listing service; every downstream automation depends on the quality of this layer.
- Control of the capture-to-requirement conversion is commercially significant to any operator seeking to automate booking or accept tasks from partner systems.
Page Conclusion
Strong Observed Correspondence
There is strong publicly evidenced correspondence at the level of customer task requirement + task location + provider discovery + scheduling input. Whether the downstream processing satisfies the full patent orchestration sequence requires the remaining analysis in this review.