Configuration of a service request interface based on a processing time prediction

Abstract

A network computer system that receives a service request from a requester's device over one or more networks. The network computer system predicts a response time, which extends from the time the service request is received until a service provider selected by the network computer system accepts an invitation to fulfill the service provider's request. The network computer system transmits content data to the requesting device, which then causes the requesting device to display content based on the predicted response time.

Description

CROSS-REFERENCE TO RELATED REGISTRATIONS

[0001] This application claims priority from (i) US patent application No. 18 / 217,186 dated June 30, 2023 and (ii) US preliminary patent application 63 / 443,611 dated February 6, 2023; the aforementioned priority applications are each incorporated herein in full by reference. TECHNICAL AREA

[0002] The examples refer to a network computer system for configuring an interface for service requests based on a prediction of the processing time. GENERAL STATE OF THE ART

[0003] There are numerous types of on-demand services. These services allow users to obtain a specific service, typically through user interaction with a service application running on a mobile computing device. Examples of such on-demand services include (i) passenger transportation services, where service providers provide transportation to service requesters; (ii) delivery services, where service requesters ask the service provider to deliver food or other items; and (iii) shipping services, where service providers ship items on behalf of the service requester. Due to the nature of on-demand services, speed can often be a priority for service requesters. Furthermore, because service requests are not scheduled in advance, there can be uncertainty about finding a service provider who can fulfill a service request.

[0004] On-demand services are typically supported by significant network computing resources. To fulfill a specific service request, a network computer system can be used that employs a number of specialized processes (e.g., microprocesses) to perform specific tasks. In the context of transportation services, for example, separate processes might be used to receive a service request, estimate the execution time for the requested services, select eligible service providers capable of fulfilling the service request, send invitations to these eligible service providers, match a service provider with a service request, and provide the customer with information about the matched service provider.In this context, the cancellation of a service request by a user can have an extremely disruptive and disproportionately large impact on the efficiency of a network computer system, as numerous processes may have been initiated in anticipation of the requester being assigned to a service provider who will fulfill the requester's service request. BRIEF DESCRIPTION OF THE DRAWINGS Fig. Figure 1 shows a network system for configuring an interface for service requests based on a prediction of the processing time according to one or more embodiments. Fig. Figure 2A shows an exemplary procedure for configuring an interface for service requests based on a prediction of the processing time according to one or more embodiments. Fig. Figure 2B shows an exemplary procedure according to one or more embodiments for recommending a series of measures for the requestor to improve the processing time. Fig. 3A to Fig. 3C demonstrates exemplary user interfaces for configuring an interface for service requests based on a prediction of the processing time according to one or more embodiments. Fig. Figure 4 is a block diagram showing a computer system on which one or more of the embodiments described herein can be implemented. Fig. Figure 5 shows a computer device of a requester on which one or more embodiments can be implemented. DETAILED DESCRIPTION

[0005] In some embodiments, a network computer system is configured to provide on-demand services to requesting users. The network computer system can receive a service request from a requesting device over one or more networks. The network computer system predicts a processing time, which extends from the time the service request is received until a service provider selected by the network computer system accepts an invitation to fulfill the service provider's request. The network computer system transmits content data to the requesting device, which then causes the requesting device to display content based on the predicted processing time.

[0006] In some embodiments, the content data can cause the requesting device to display content that shows the predicted processing time for the requester's service request. For example, the content displayed on the requesting device might include or represent a countdown timer that counts down a period of time corresponding to the predicted processing time for the service request.

[0007] Additionally or alternatively, the content data can instruct the requesting device to select a user interface (or a function thereof) that displays content based on the predicted processing time. The selected user interface can, for example, optionally present the requester with content configured or suitable for the predicted processing time.

[0008] Among other technical advantages, the described embodiments reduce the frequency with which requesters cancel service requests. These embodiments take into account that service request cancellations often occur early in the process of assigning the service request to a service provider. At this point, requesters are often most uncertain as to whether their service request will be assigned to a service provider. By reducing the number of service request cancellations, these embodiments enable more efficient use of the resources employed by a network computer system providing an on-demand service.

[0009] In the usage herein, client device, computer device, and / or mobile computer device refers to devices corresponding to desktop computers, mobile phones or smartphones, laptop computers, tablets, etc., which can provide network connectivity and processing resources for communication with a system for mediating services over one or more networks. In another example, a computer device may refer to a computer device in a vehicle, such as an on-board computer. As further described herein, a user may refer to a requester of a network service (e.g., a passenger) or a service provider (e.g., the driver of a vehicle) who provides location-based services to requesters.

[0010] In examples, the processing time can correspond to a period of time extending from the time a service request is received until the time a requested service has been (or is being) initiated by a service provider. In the context of transportation services, the time a requested service is initiated can correspond to the time a service provider is assigned to a service request. To assign a service provider to a service request, the network computer system can perform processes that include: (i) identifying available service providers that are eligible to fulfill the service request, (ii) inviting the available service providers to fulfill the service request according to a selection or communication protocol, and (iii) assigning the request to a selected service provider that accepts the invitation to provide a service for the service request.When a service request is assigned, it means that a suitable service provider has been selected for the request and that the service provider has committed to fulfilling the request. At this point, information about the assigned service provider can be communicated to the requesting party. Accordingly, in some examples, the processing time may correspond to the period from when a service request is received until a selected service provider is assigned to it.

[0011] While some examples, as described, relate to the use of on-demand transportation systems, other embodiments are more generally applicable to other types of on-demand services where service requests are matched with service providers. Accordingly, examples may relate to various location-based (and / or on-demand) services, such as a transportation service, a food truck service, a delivery service, an entertainment service, etc., that are to be mediated between requesters and service providers. In other examples, the system may be implemented by any entity that offers goods or services for sale through the use of computer equipment and a network.For the sake of simplicity, the service brokerage system in the described examples can be a transportation brokerage system that ensures that drivers of vehicles running service applications on appropriate computer equipment provide transportation and / or delivery services to passengers.

[0012] One or more of the described examples stipulate that procedures, techniques, and actions performed by a computer device are carried out by a program or as a computer-implemented procedure. "By a program" here means through the use of programming code or instructions executable by a computer. These instructions can be stored in one or more memory resources of the computer device. A step performed by a program may be automatic.

[0013] One or more of the described examples can be implemented using program modules, engines, or components. A program module, engine, or component can include a program, a subroutine, a part of a program, or a software or hardware component capable of performing one or more of the specified tasks or functions. In the usage herein, a module or component can exist independently of other modules or components on a hardware component. Alternatively, a module or component can be an element or process shared with other modules, programs, or machines.

[0014] Some of the examples described may generally require the use of computer equipment, including processing and storage resources. For example, one or more of the described examples may be implemented wholly or partially on computer equipment such as servers, desktop computers, mobile phones or smartphones, and tablet devices. Storage, processing, and network resources may all be used in connection with the setup, use, or execution of any example described herein (including the execution of any procedure or the implementation of any system).

[0015] Furthermore, one or more of the described examples can be implemented using instructions that can be executed by one or more processors. These instructions can reside on a computer-readable medium. The machines shown or described in the figures below represent examples of processing resources and computer-readable media on which instructions for implementing the described examples reside and / or can be executed. In particular, the numerous machines shown in the described examples contain one or more processors and various forms of storage for holding data and instructions. Examples of computer-readable media include permanent storage media such as hard disk drives in personal computers or servers. Other examples of computer storage media include portable storage devices such as CDs or DVDs, flash memory (e.g., USB flash drives), and USB flash drives.on smartphones, multifunction devices, or tablets) and magnetic storage. Computers, terminals, and network-enabled devices (e.g., mobile devices such as cell phones) are all examples of machines and devices that use processors, memory, and instructions stored on computer-readable media. Furthermore, examples can be implemented in the form of computer programs or a computer-usable storage medium capable of carrying such a program. NETWORK SYSTEM

[0016] Fig. Figure 1 shows a network computer system for configuring an interface for service requests based on a predicted processing time, according to one or more embodiments. Examples describe a network computer system 100 that provides an on-demand service (e.g., an on-demand transportation service). The network computer system 100 can be implemented, for example, on a server or a combination of servers. In variations, the network computer system 100 can have processors running on user devices, so that the network computer system 100 is distributed between, for example, the server(s) and the user computer devices (e.g., mobile devices carried by users to request and receive on-demand services).

[0017] In examples, the network computer system 100 has a requesting device interface 110, a provider device interface 112a, a service request handler 120, a service data store 130, and an allocation engine 140. The request handler 120 can further include processes represented by the prediction component 124 and the content configuration component 126. As described in more detail, the prediction component 124 can predict service request processing times, and the configuration component 126 can generate content data to configure the content of requesting devices based on the predicted processing time.

[0018] The network computer system 100 is operated to assign service requests 111 for a specific geographic region to service providers. Processes represented by the interface 110 of the requesting device communicate with the requesting devices 102 to authenticate the user (e.g., in response to the requester opening the service application 116 on the requesting device). The interface 110 of the requesting device can receive request information 103 communicated by requesting devices 102 through user interaction with the service application 116. For example, request information 103 can be provided by requesting devices 102 on which the requester recently opened the service application 116 and / or on which the service application 116 is running in the background.In one or more examples, the requester information 103 can include data corresponding to inputs made on various user interfaces and / or selectable functions on user interfaces of the service application. The requester information 103 can include the user's location, which can be determined from location-based resources of the requester device 102. The interface 110 of the requester device can also receive a service request 111 communicated by the requester device 102 using the service application 116.

[0019] The request handler 120 can implement operations to handle the service request 111. In examples, the request handler 120 can serve as an interface to the service data store 130 to store the service request 111, initiate a mapping process by the mapping engine 140, and communicate responses and updates to the requesting device 102 via the requesting device's interface 110. Each service request 111 recorded in the service data store 130 can have a set of service request attributes. The set of service request attributes includes a user identifier of the requester, location information of the requester (e.g., the current location), and / or one or more service locations (e.g., the start or pick-up location, the service end or destination location, etc.) specified in the requester's service request. In some variations, the service request attributes can also include a service type (e.g.,The service request handler 120 can include a type of vehicle, a service start or end time (e.g., a delivery by a specific time). The request handler 120 can also specify attributes to be associated with the service request 111. For example, for transport-type requests, the request handler 120 specifies attributes such as an estimated travel time and / or distance to fulfill the requester's service request. The request handler 120 can also communicate with the requester device 102 to update information about the service request in the service data store 130. Similarly, the request handler 120 can communicate with the service data store 130 to update information about the service request 111 at the requester.

[0020] The provider device's interface 112 can include operations to handle interactions with service providers. The provider device's interface 112 can collect information about service provider devices 104 ("Service Provider Information 105") in the service data store 130. The Service Provider Information 105 can include the user ID, location information, and status for each service provider. The service provider's status can indicate whether the service provider is available to fulfill a service request. The provider device's interface 112 can also update information about the service provider. For example, the provider device's interface 112 can receive location information for service providers when the service providers are online and available (e.g., when the service provider is not assigned to a service request).The provider device's interface 112 can also update the service data store 130 based on input received from the service provider. For example, service providers can communicate via their respective provider devices 104 when they are on break or online and waiting to fulfill service requests. The provider device's interface 112 can also include monitoring processes that monitor the service data store 130 to determine status information about service providers. The information captured in the service data store 130 can also indicate that a service provider may be online and waiting to be assigned a service request. Additionally or alternatively, the provider device's interface 112 can monitor the service data store 130 to determine, for example, when a service provider has almost completed fulfilling a service request.If a service provider is within a threshold for the time or distance required to complete a service request, the provider device's 112 interface can update the service provider's status to indicate availability. The provider device's 112 interface can also access a service provider profile store to determine, for example, when a service provider is approaching the end of their service time, after which they will no longer be available.

[0021] The interface 110 of the requesting device can also store the requester information 103 in the service data store 130. Likewise, the interface 112 of the provider device can store the service provider information 105 in the service data store 130. In this way, the service data store 130 can contain entries that link the requester's user ID with a corresponding service request 111 (if the requester has submitted one) and / or the requester's current position information. Furthermore, the service data store 130 can determine attributes of each service request 111, such as the respective start and end points of the service. For passenger transport service requests, the service data store can contain attributes that determine an estimated travel time or distance based on attributes such as the start and end points of the service.The service data store 130 can also store service provider information 105, including service provider identifiers, service provider location information and status (e.g. available or unavailable).

[0022] Furthermore, in the service data store 130, each service provider can be linked to a corresponding profile in a profile store 118. Each service provider identified by the service data store 130 can be linked to a type of service that the respective service provider offers. The service type can also be linked to various attributes that may influence the attractiveness or cost of the service provided by the specific vehicle. For example, the service type can reflect the type of vehicle driven by the service provider (e.g., luxury, green, spacious (e.g., SUV)), amenities offered by the service provider's vehicle, the level of experience (or trust) of the service provider, and other attributes.Furthermore, the profile of individual service providers can indicate their tendency or preference to accept invitations to fulfill service requests based on factors such as trip length, as well as the anticipated fee (or compensation) for fulfilling the service request. Additionally, the profile of individual service providers can reflect their tendency to accept an invitation to provide a service for a service request if an additional payment is offered. For example, a service requester might boost their service request by offering an additional payment to any service provider who accepts the invitation. This additional payment can increase the likelihood that the service requester's request will be accepted more quickly by a service provider, enabling them to reach their destination by a desired time. ASSIGNMENT PROCESS

[0023] When a service request 111 is received in examples, the mapping engine 140 initiates a mapping process to assign the open service request 110 to one or more service providers. The mapping process can include several subprocesses, such as (i) identifying a group of eligible service providers, (ii) sending an invitation 107 to fulfill a service request 111 to one or more service providers in the group of eligible providers, and (iii) mapping a service request 111 to a selected service provider who accepts the service invitation 107. The subprocesses executed by the mapping engine 140 are described in more detail below.

[0024] The group of potential service providers can be determined from the service data store 130, whereby service providers from the group of potential providers are selected at least partially based on their respective location information and availability status. When determining service providers for a group of potential providers, the current location of available service providers can be compared with the starting point of the open service request. If the available service provider is within a threshold for distance and / or expected travel time (e.g., measured by travel time, semiversus distance, etc.) from the starting point of the service, this service provider can be selected for the group of potential providers.

[0025] Furthermore, the assignment engine 140 transmits invitations 107 to individual service providers from the group of eligible providers (via the service data store 130 and / or the interface 112 of the provider device). Each service provider receiving an invitation 107 may have a predefined timeframe to respond. Depending on the implementation, invitations can be sent sequentially, simultaneously, or via a distribution process. The order in which service providers receive invitations can also vary depending on the implementation.

[0026] In examples, a service request can be considered assigned as soon as a service provider from the group of eligible providers accepts an invitation 107 to fulfill a service request. Once a service request has been assigned to a service provider, processes represented by the request handler 120 communicate with the corresponding request device 102 (via the request device's interface 110) to provide information about the assigned service provider. Information about the assigned service provider can include, for example, the service provider's name, vehicle type, license plate number, and level of experience. The request handler 120 can also transmit updates to the request device 102. These updates can include content (e.g.,Visual content (map content) that indicates the service provider's progress in initiating execution to fulfill the requester's service request. For example, service application 116 can run on requester device 102 to receive progress information showing that the service provider is driving their vehicle to the service starting point. ASSIGNMENT TIME

[0027] The processing time can include the time it takes for the allocation engine 140 to assign an open service request 111 to a selected service provider who accepts the invitation 107 to fulfill the service request. In such examples, the processing time can alternatively be referred to as the service request allocation time. The processing time for a specific service request can vary from seconds to minutes, depending on a variety of factors such as the service request's attributes and / or the service conditions. Service request 111 attributes such as the service location(s), travel time and / or distance (or fee earned by fulfilling the service request), or profile information about the requester (e.g., the service requester rating) can influence the attractiveness of the service request, which in turn can affect the processing time.Service conditions that may affect processing time include the number of open transport requests near the service requester or service starting location, the number of available service providers nearby, the type of product or vehicle requested by a user, and other conditions that may affect the number of available service providers or open service requests during the period in which the service request is assigned to a service provider.

[0028] For example, the service applications 116 run on the requester devices 102 to create interfaces, enabling requesters to submit transportation requests and obtain information about service providers who can fulfill their service requests. A requester can launch the service application 116 to submit a service request (e.g., a request for a passenger transportation service). When submitting a service request, the user can specify one or more service locations, such as a service endpoint (or destination), a service start point (e.g., a pickup location (e.g., the current location or an entered location or address)), and a service or vehicle type. Following conventional procedures, once the user submits the service request, the service application 116 can display an interstitial interface indicating to the user that a service provider is being sought for their service request.Once the service provider has been found, the service application can display information about the service provider (e.g., name, rating, experience, vehicle type, license plate number, etc.). The service application can also display information about the service provider's progress, such as their journey to the pickup location.

[0029] Before the requester is informed that a service provider has been selected and / or is traveling to the service starting point, they may be unsure whether their service request will be assigned. The longer the assignment time, the less confident the requester may be that their service request will be assigned. Furthermore, the service requester might misinterpret the length of the assignment time. For example, the requester may be accustomed to a relatively short assignment time because they typically submit service requests from a busy area with many service providers. However, if the requester submits a service request from a different area with fewer service providers, the average assignment time may be disproportionately longer, and the requester may interpret this longer duration as indicating that no service providers are available.

[0030] The examples take into account that requesters typically cannot be aware of the various factors that might influence the processing time of service requests. Furthermore, the requester experience of an interstitial interface may appear longer than it actually is, as requesters may stare at their devices while waiting for information about the service provider. This experience can discourage users from waiting any longer and may lead them to cancel the service request. Since the search for a service provider involves several steps (e.g., identifying potential service providers, communicating with the service providers, etc.), the occurrence of cancellations is disruptive to the operation of the network system and also reduces the efficiency of the network computing system. INQUIRY - DEALER

[0031] In examples, the request handler 120 may include processes that use information from the service data store 130 to (i) predict a processing time corresponding to the period between when the requester makes the service request and when information about a suitable service provider is delivered to the appropriate requester device 102, and (ii) generate content data 125 for transmission to the requester device to cause the requester device 102 to display content based on the predicted processing time. In some examples, the request handler 120 may further configure a content interface provided by the service application 116 running on the requester device 102, with the content interface intended to keep the requester engaged to reduce the mapping time experience.

[0032] In examples, the request handler 120 includes a prediction component 124 that predicts the allocation time for a specific service request 111. The request handler 120 may also include a content configuration component 126 that generates content data for transmission to the requesting device 1202, the transmitted content data 125 causing the corresponding service application 116 to display content based on the predicted processing time. In some examples, the displayed content includes or includes a timer that reflects the predicted processing time for the service request.As described in more detail, the prediction component 124 can predict an assignment time for the service request based on (i) attributes of the service request, (ii) service conditions including factors that affect the availability of service providers, and / or (iii) the tendency or actions of one or more service providers that are otherwise available to fulfill the service request. Once a service request 111 is received, the assignment engine 140 initiates an assignment process, as described by the examples. Simultaneously, the prediction component 124 can predict the processing time for assigning the service request 111 to an available service provider. PREDICTED PROCESSING TIME FOR A SERVICE REQUEST

[0033] Predictive component 124 can predict the processing time for newly received (or open) service requests. The predicted processing time extends from the time the service request is received until the time a service provider selected by the network computer system 100 accepts an invitation 107 to fulfill the service provider request. The predicted processing time can correspond to a specific value (e.g., a specific number of seconds, such as 35 seconds, 1 minute, etc.), a range of values ​​(e.g., between 40 and 65 seconds), or a threshold (e.g., less than 2 minutes). The prediction can also be an approximation and / or subject to rounding (e.g., rounding up to the nearest 10 seconds, 30 seconds, etc.). Furthermore, the approximation can include a margin, an error, or a deviation based on, for example, a standard deviation.

[0034] To predict the processing time for a specific service request 111, the prediction component 124 can use collected historical information to determine attributes of individual service requests that may affect the processing time. Specifically, the prediction component 124 can identify attributes of service requests that make individual service requests attractive to service providers. If a service request is more attractive, its processing time may be shorter, as service providers tend to accept more attractive service requests more quickly. In some examples, the attractiveness metric of a service request may be a learned metric derived from the historical data store 134. The historical data store 134 may, for example, contain information from the service data store 130 from past periods.Historical data can be analyzed to determine the tendency of individual service providers to accept or decline invitations to service requests when service requests have certain attributes, such as the service endpoint, the estimated travel time or duration, the fare (or the fee the service provider can earn by fulfilling the transportation request), and / or other attributes of the service request. Furthermore, the historical data store can be analyzed as a whole to identify a general tendency among service providers regarding characteristics of service requests that are considered attractive. These analyses can be conducted in the context of service types, location or region, date / time, or other factors.The determination of attractiveness indicators for individual service providers or overall can also be carried out using trained models, whereby the models are trained using information from the past from the historical data store 134.

[0035] Predictive Component 124 can further employ logic and / or predictive models to determine the processing time or the influence that service request attributes have on the processing time of individual service requests. In this way, Predictive Component 124 can link an attractiveness metric to attributes and properties of service requests. In some examples, Predictive Component 124 can identify significant service request attributes that include the destination, travel time, expected fare, or service provider compensation and / or service provider profile information. For example, if a service request specifies a destination where the service provider is highly likely to find another service request to handle, the service request can be considered more attractive.Conversely, if the destination is located a relatively short distance away in a direction with less demand for transportation services, the service request may be considered less attractive. Similarly, if a service request takes a service provider to a location requiring a long return trip where no additional service requests are likely, the service request may be less attractive. More specific correlations between service request attributes and the attractiveness of the service request to service providers can be determined by Predictive Component 124 through analysis of the historical data store. Furthermore, the extent to which the attribute affects the handling time can be modeled for identified attributes.Furthermore, the prediction component can identify 124 service attributes that are significant (or potentially significant), as well as the likely impact of these attributes on processing time. This identification can also be specific to geographic regions, service types, times of day / days, and other contextual factors.

[0036] In some examples, the attractiveness of service request 111 can be a learned metric determined from the historical data store 134. The historical data store 134 might, for example, contain information from the service data store 130 from past periods. The historical data can be analyzed to determine the tendency of service providers to accept or decline invitations 107 to service requests when service requests have certain attributes, such as the service endpoint, the estimated travel time or duration, and / or other attributes of service request 111. Furthermore, the attractiveness of the service request can include the fee that the service provider can earn for providing the requested service.

[0037] Additionally or alternatively, the predictive component 124 can also develop logical or predictive models from the historical data store to correlate aspects of the requester profile with the attractiveness and / or processing time of the service request. For individual service requests 111, the predictive component 124 can access the requester's profile to determine whether profile information about the requester affects the attractiveness of the requester's service request. For example, the rating (feedback from other service providers) can affect the attractiveness of the requester's service request. If the requester has a fairly good rating based on feedback from other service providers, for instance, service requests from this requester may be weighted as more attractive, since the good rating may indicate that the requester tips.The prediction component 124 can access the requester's profile from a profile data store 118 to determine whether the requester's attributes can affect the attractiveness of the service request.

[0038] Furthermore, in some examples, prediction component 124 can predict the processing time based on service conditions at a time and location relevant to the service request. The service conditions can be based on (i) the number of available service providers located within a certain radius of the service's starting point, and (ii) the number of open service requests that can be assigned to the available service providers. The determination of the service conditions can be specific to a time period and area relevant to the service request. The relevant time period can include a threshold for a time span from the moment the service request is received, corresponding, for example, to the time required to assign the requester to a service provider and ensure that the service provider picks up the requester.In some examples, the relevant time span may also include an estimated travel time to fulfill the service request. Time spans can filter the list of available service providers to determine the group of eligible providers. Service providers located outside a distance threshold, meaning their arrival at a service starting point would exceed a time span threshold, or service providers whose service is scheduled to end before or near the time the service request is to be completed, may be excluded as eligible providers for the service request. The relevant area may include a distance threshold that defines an area considered close to the service starting point.The distance threshold used to define the relevant area for a service request can be based on, for example, a semiversus distance or a driving distance. The relevant area can also be based on or coincide with the time-based threshold, where, for example, service providers available near the service request can be considered suitable potential providers.

[0039] The prediction component 124 can access the service data store 130 to determine the number of available service providers for a service request. Determining the number of available service providers can be specific to a predetermined proximity of the service start point. In some variations, the number of service providers can include those expected to complete an existing service request at a destination located near the service start point within a specific timeframe (e.g., one minute). Furthermore, the number of service providers can include those that are currently offline but are expected to come back online within the relevant timeframe.The service data store 130, for example, can identify service providers that are currently paused or otherwise temporarily unavailable, but are located near the service start point and are expected to come back online during the relevant period. In yet another variation, the number of available service providers can include a predictive element based on historical information. The predictive component 124, for example, can use historical information from the historical data store 134 to determine how frequently service providers near the service start point are expected to come online and become available during the relevant period. In determining the frequency with which service providers come online, the predictive component 124 can use historical information and the context (e.g., time of day, day of the week, month, weather, etc.).) develop a predictive model that is specific to the relevant area.

[0040] Predictive component 124 can also access service data store 130 to determine the number of open service requests near the service start point. Additionally, predictive component 124 can access service data store 130 to determine the number of requesting devices located near the service start point that have not yet submitted a service request. The number of these requesting devices can provide an indication of the number of service requests received during the relevant time period, which in turn can affect the pool of available service providers.

[0041] Additionally or alternatively, the predictive component 124 can predict the allocation time for the specific service request, at least partially, based on an anticipated response from individual service providers available to fulfill the service request. The anticipated response can reflect a tendency or probability that an available service provider will decline the service request. In examples, the anticipated response can be represented as a probability value or other metric that indicates a tendency or probability that the identified service provider will accept or decline an invitation 107 to provide a service for the service request.In some variations, the probability value or metric can also represent a tendency or probability that the identified service provider will reject the service request by not responding within an invitation response time, where the invitation response time corresponds to a period of time within which a service provider must accept an invitation 107 to fulfill a service request. This provision can particularly affect the allocation time in cases where only one service provider receives an invitation 107 to fulfill a service request at a time. If a service provider does not respond to an invitation to fulfill a service request, the lack of response can extend the allocation time by an invitation response time (e.g., 15 seconds).

[0042] In examples, the predictive component 124 can determine the likely response of a service provider to a service invitation 107 based on past information associated with the service provider. The predictive component 124 can determine the likely response of a service provider to a current service request by analyzing previous invitation responses from the service provider. The past information from the past information store 134 can include recent invitation responses from eligible or selected service provider(s). For example, if an eligible or selected service provider is online but declined one or more service invitations immediately prior to the most recent service requests, then the predictive component 124 can determine the value of the likely response in such a way that it has a higher probability (e.g.,(compared to an average or standard value) indicates that the service provider will decline Invitation 107 for the current service request. This finding may increase the predicted processing time for the service request, as it will likely take longer to find a service provider who accepts Service Invitation 107.

[0043] Predictive component 124 can also consider parameters related to the attractiveness of the service request when determining the expected response of a specific service provider available to fulfill that request. Predictive component 124 can access the profile store to determine if the service provider has preferences regarding timing or geography that do not match the attributes of the service request. If such preferences exist, predictive component 124 can adjust the predicted response value to reflect a higher probability that the service provider will decline the service invitation 107. In such a case, the predicted processing time can be assigned a higher value to account for the greater difficulty of finding a service provider willing to accept the invitation 107 for the service request.Furthermore, the profile memory 118 can, for example, contain the service provider's past responses to invitations 107. Based on such past responses, the predictive component 124 can determine the service provider's tendency to accept or decline invitations 107 to fulfill service requests, based on specific attributes such as the value or price associated with a service request.

[0044] In some examples, the prediction component 124 can develop a model that predicts a processing time (e.g., an allocation time) based on several different model parameters, such as parameters that reflect the attractiveness of the service request, the availability of service providers, and an expected response from one or more available service providers. For example, the model parameters can include one or more parameter values ​​that represent (i) one or more attributes of the service request, such as the service endpoint, the expected travel time or distance, the service start point, the value or price associated with fulfilling the service request, and / or the requester's rating; (ii) a number of open service requests near the service start point; (iii) a number of requester devices 102 running the service application 116 that have not yet submitted a service request;(iv) the number of service providers currently available near the service starting point; (v) the number of service providers likely or potentially available during the relevant time period and near the service starting point; and / or (vi) the expected invitation response (or probability value) of each service provider deemed available for the service request. The model parameters can be weighted based on learning processes that monitor and observe past information from the Service Data Store 130 and / or the Past Information Store 134.

[0045] In this way, the prediction component 124 can implement models that are tailored to the location and time period relevant to the specific service request, or otherwise configured. For example, the parameter values ​​used by the prediction component 124's model(s) can be weighted based on historical information specific to the area and time period of the service request. The prediction models can then be used to predict the processing time for a service request, based at least partially on the parameter values ​​described. CONTENT CONFIGURATION

[0046] Content configuration component 126 represents processes that transmit content data 125 to requester device 102 via the requester device's interface 110. The content data 125 can cause requester device 102 to display content that specifies the predicted processing time for the service request or is otherwise based on it. In examples, the content data 125 can correspond to a value representing the predicted processing time, and the service application 116 processes the content data to generate a dynamic function that reflects or is otherwise based on the predicted processing time value. In variations, the content data 125 can contain logic that enables the service application 116 to generate the dynamic function.

[0047] In examples, the content data 125 is transmitted to the requesting device 102 after the requesting device makes a service request. The service application 116 can use the content data 125 to display content on the service application for a period of time extending from the time the service request is received until the time a selected service provider accepts an invitation 107 for the service request. In one example, the content data 125 can contain data that allows the service application to generate a countdown timer that counts down from a value that matches or is based on the predicted processing time as determined by the prediction component 124. The countdown timer can take the form of a digital timer, for example,a digital timer that numerically displays the remaining time in seconds until the expected assignment of the service request to a service provider. In variations, the countdown timer can be displayed in alternative graphical and / or animated forms, and furthermore in combination with other types of content that can be selected based on the processing time. For example, content data 125 can be another form of dynamic graphic, such as animated content representing an hourglass (where the amount of sand remaining in one part of the hourglass indicates the remaining processing time), a falling ball (where the distance until the ball reaches the ground is based on the remaining processing time), or a traced circle or shape (where the portion of the shape that still needs to be traced indicates the remaining processing time).

[0048] Additionally or alternatively, the type and / or configuration of a content interface in the requesting device can be determined by content data 125 generated by the content configuration component 126. In some examples, the content configuration component 126 selects a content interface for the requesting device 102. The network computer system 100 can select one or more content interfaces for a requester, choosing from a collection of several types of content interfaces. These content interface types may include one or more that display the expected processing time graphically, for example, as a countdown timer visualization.Additionally, the types of content interfaces that can be displayed to the user based on the predicted processing time can include one or more interfaces configured to keep the user engaged. For example, a content interface can be selected to entertain the user. To illustrate, a selected user interface might offer a guessing game, an arcade game, or a puzzle for the user to solve. Such user interfaces can encourage the requester to engage with the requester device 102 in a way that is entertaining or engaging for the requester.

[0049] The content configuration component 126 can further generate the content data 125 to configure the selected user interface based on the predicted processing time. The predicted processing time can, for example, define a goal and / or the duration of the task. As an illustrative example, the user might be prompted to solve a certain number of puzzles, with the number of puzzles based on the predicted processing time. Furthermore, the decision of whether to provide the user with an interaction interface can be based, at least in part, on the predicted processing time exceeding a threshold (e.g., 45 seconds). UPDATE

[0050] Once the prediction component 124 has predicted the processing time for a service request in the examples, it monitors the subsequent mapping process to determine if the mapping process is proceeding as predicted. In the examples, each subprocess of the mapping process is monitored to determine if the completion time of that subprocess matches the predicted completion time. If the difference between the predicted time and the completion time exceeds a threshold, the prediction component 124 can update the predicted processing time. The content configuration component 126 can transmit content data 125 to update the content data provided on the requesting device 102. For example, a countdown timer present on the requesting device can be reset to a new value.Alternatively, an interaction field selected for the user can be adjusted to reflect the updated predicted duration.

[0051] In some examples, the prediction component 124 can also monitor the service request assignment process to detect events that could delay or accelerate the predicted processing time. Such events might occur, for example, if an unexpected number of eligible service providers decline the invitation 107 regarding the service request. In such examples, the content configuration component 126 can communicate a change in the predicted processing time along with the reasons for the change (e.g., multiple service providers declined the invitation regarding the service request). RECOMMENDATION OF MEASURES

[0052] In examples, the network system implements 100 processes, represented by the recommendation component 128, to recommend one or more actions to the requester that they can take to reduce the processing time of an open service request. The recommendation component 128 can recommend one or more actions, for example, in response to (i) an ongoing processing time for an open transport request that exceeds the predicted processing time; (ii) one or more service providers declining to accept an invitation 107 to fulfill the service request; (iii) the fact that fewer service providers are available than expected; (iv) profile information of certain service providers that are otherwise available for the service request, where the profile information indicates that the service request is unlikely to be attractive to the service provider (e.g.,(1) if the profile information indicates that the service provider typically rejects service requests with the same or a higher fare; (2) that another service or option becomes available while the processing time is running; and / or (3) that other events or occurrences indicate that the processing time for the service request is taking longer than expected or necessary. In response to the recommendation component 128 suggesting an alternative or additional set of actions regarding an open service request, the content configuration component 126 generates content data 125 to provide recommendations to the requesting device 102 based on the identified set of actions.

[0053] In examples, recommendation component 128 can specify an alternative or additional set of actions, including an action where the requester modifies the open service request or resubmits the service request with one or more modifications designed to make the service request more attractive to service providers. These modifications can alter the service parameters of the transportation request to make it more appealing to available service providers. For example, recommendation component 128 can specify recommended actions that include changing the service location of the service request (e.g., pick-up or drop-off location) and / or adding an additional payment or surcharge (e.g., to increase the fare for the service provider).

[0054] The recommendation component 128 can specify one or more modifications to an open transportation request based on past information about the service provider. For example, recommendation component 128 can specify a recommended action where the requester offers an additional payment with the service request. In such examples, the amount of the additional payment can be based on profile information associated with one or more available service providers. The service provider's profile information can, for example, indicate situations in which the service provider recently accepted an invitation 107 for a service request with an additional payment, accepted invitations 107 for service requests with additional payments of a certain value, and / or accepted invitations 107 for service requests where the fares were at or above a certain amount.

[0055] Additionally or alternatively, recommendation component 128 can determine modifications based on historical information that considers the overall behavior of service providers. For example, recommendation component 128 can determine the surcharge amount based on information gathered from all service providers, providing insights into surcharge (or total fare) thresholds at which the transport request is likely to become attractive.

[0056] Furthermore, the recommendation component 128 can implement one or more models that predict the attractiveness of service requests to service providers. The recommendation component 128 can use these models to define recommended actions that the user can take to make the service request more attractive to available service providers.

[0057] Additionally or alternatively, Recommendation Component 128 can specify a recommended action in which the Service Request 111 is modified or resubmitted to specify a different type of service (e.g., a different type of service vehicle, single or multi-passenger transport, etc.). Recommendation Component 128 can identify the alternative product / service type based on factors such as the availability of service providers offering the alternative product / service and the attractiveness of the service request to those providers. For example, if the service request originally specified a single-passenger transport service using an economy-class vehicle, Recommendation Component 128 can recommend an alternative vehicle type (e.g., a luxury sedan) based on the availability of the alternative vehicle type.Considering the higher fare associated with an upgrade in the transport request, changing the service type can also increase the attractiveness of service request 111. Conversely, if the recommended service type is a downgrade (e.g., an economy-class vehicle instead of a luxury vehicle), the service request may be available to a larger number of service providers.

[0058] In further variations, the recommendation component 128 can also propose or recommend a measure whereby the user's service request 111 is sent to multiple service providers who jointly offer several types of services. For example, the recommended measure might stipulate that the requester sends a service request to service providers who operate different vehicle classes, as well as to service providers who offer groupage and individual transport. In such a case, an invitation 107 for the service request 111 can be accepted by any service provider, regardless of the specific type of service that the service provider offers.

[0059] In examples, the content configuration component 126 can update the content data 125 based on certain actions of the recommendation component 128. The configuration component 126 can generate the content data 125 to specify, for example, one or more modifications that the service requester can make to the service request, such as (i) specifying an additional payment that the service requester can make, including specifying the recommended amount(s) for the additional payment; (ii) changing a service location of the service request (e.g., the content can suggest that the user walk to a different pickup location to increase the appeal of their service request); and / or (iii) changing the type of service requested (e.g., upgrading the service type), and including information that allows the requester to evaluate the alternatively recommended service type (e.g.,The fare of the alternative service type, the estimated processing time and / or the estimated time of arrival for the requester to reach their destination, etc.). The content data 125 can be generated in such a way that it is interactive, allowing the requester to make a selection in order to implement the recommended action.

[0060] In some examples, once the service requester decides to modify their service request or take the recommended action, the request handler 120 can initiate the prediction component 124 to determine a new or additional processing time. This new or additional processing time can correspond to a predicted duration until the modified service request has been assigned to an available service provider. METHODOLOGY

[0061] Fig. Figure 2A shows an exemplary procedure for configuring an interface for service requests based on a prediction of the processing time according to one or more embodiments. Fig. Figure 2B shows an exemplary method for recommending a series of measures to the requestor to improve the processing time according to one or more embodiments. Exemplary methods 200A, 200B, as in Fig. 2A and Fig. 2B described, can be used with the in Fig. The elements described in section 1 can be implemented. Accordingly, when describing the exemplary procedures 200A and 200B, reference can be made to elements of Fig. 1. Reference is made to illustrate a suitable component for carrying out a described step or sub-step.

[0062] With reference to Fig. In step 210, the network computer system 100 receives the service request from a requesting device. The network computer system 100 determines a set of attributes associated with the service request. The set of attributes can include one or more service start points, a service destination, an estimated travel distance, an estimated travel time, a fee or reward value associated with fulfilling the service request, and a service time (e.g., a time by which the service request should be fulfilled, based on the fee or reward value associated with the service request or a user preference). In examples, the set of attributes can also include information about the requester.For example, the network computer system 100 can use the requester's profile information, which comes from the profile store 118, to determine a requester's rating, where the rating reflects feedback from other service providers who have already provided service to that requester.

[0063] In step 220, the network computer system predicts a processing time for the service request, which extends from the time the service request is received until a selected service provider accepts an invitation for the service request. The network computer system 100 can predict the processing time in response to the transmission of a service request by the requesting device. Thus, the network computer system 100 can predict the processing time before the allocation process is initiated, or alternatively, while the allocation process is underway.

[0064] In step 222, the network computer system 100 predicts the processing time at least partially based on one or more of the attributes associated with the service request.

[0065] Additionally or alternatively, in step 224, the network computer system 100 predicts the processing time, at least in part, based on one or more service conditions that exist or are expected to exist for a period and geographic area relevant to the service request. Such service conditions may include, for example: (i) the number of open service requests near the service starting point; (ii) the number of requesting devices 102 running the service application 116 that have not yet submitted a service request; (iii) the number of currently available service providers; and (iv) the number of service providers that are likely or potentially available during the relevant period.

[0066] Additionally, or alternatively, in step 226, the network computer system 100 predicts the processing time, at least partially, based on the anticipated response from individual service providers that are otherwise available for assignment to the service provider. The anticipated responses can be determined based on historical information specific to the available service providers. For example, historical information can be used to determine whether the respective service providers have rejected one or more service requests in a recent period (e.g., in the immediate past). Additionally, or alternatively, historical information can be used to determine, for example, whether the requester has a tendency to decline invitations to service requests for a specific attribute that the current service request also possesses (e.g.,Service start or end point, travel time or distance, service value or price, etc.).

[0067] In step 230, the network computer system transmits content data to the requesting device to cause the requesting device to display content indicating the predicted processing time. In step 232, the network computer system 100 transmits content data 125 to cause the requesting device to generate a function that specifies the predicted processing time. The generated function can be dynamic in that it provides a value for the remaining processing time, which is continuously updated based on the passage of time and / or other events (e.g., when available service providers decline invitations for the service request). In some examples, content data 125 causes the requesting device 102 to generate a countdown timer. The countdown timer can be displayed in alphanumeric or graphical form.

[0068] Additionally or alternatively, the content data 125 transmitted by the network computer system 100 in step 234 includes a selection of a type of user interface to be displayed on the requesting device 102. The network computer system 100 can select a user interface to be displayed on the requesting device 102 based on factors such as the predicted processing time, requester profile information, and / or other factors. The user interfaces that can be selected include a set of interfaces that contain or graphically display a countdown timer based on the predicted processing time. The types of user interfaces that can be selected may also include one or more types of interactive content that prompt the user to engage with the requesting device.Such user interfaces can, for example, allow the user to play a game (e.g., a guessing game, an arcade game), solve a puzzle (e.g., a crossword or word puzzle), or perform another type of activity. In some examples, the selected user interface can also be configured based on the predicted completion time. For example, if the predicted completion time is two minutes, the user interface displayed to the user can prompt them to complete a task within two minutes or based on the predicted completion time of two minutes.

[0069] Referring to Fig. In step 240, 2B, the network computer system 100 determines that the actual processing time for assigning a service request from the requester is longer than the predicted processing time. For example, the network computer system 100 may determine that the service request remains open after the predicted processing time has elapsed. In variations, the network computer system 100 may determine that the actual processing time is likely to be longer than the predicted processing time. For example, the network computer system 100 may execute procedure 250 in response to one or more service providers declining an invitation for the requester's service request.

[0070] In step 250, the network computer system 100 determines one or more actions to recommend to the requester. These actions may be recommended to increase the likelihood that the requester's service request can be assigned to a service provider within a specific timeframe, and / or to otherwise reduce the processing time that would be required if no action were taken. In determining the actions, the network computer system 100 may, in step 252, select the one or more recommended actions by evaluating the service conditions that affect the service request.For example, the network computer system can evaluate 100 conditions such as the number of available service providers, the number of competing service requests, information from the past that indicates the attractiveness of the service request to the service providers, and / or other information that may indicate a change in the processing time.

[0071] In some examples, the network computer system 100 may determine in step 254 that the recommended action should be a modification of a service parameter of the service request to make the service request more attractive to available service providers. For example, the network computer system 100 may recommend that the requester make an additional payment to increase the value of the fare for a service provider who accepts the invitation for the service request. Additionally or alternatively, the network computer system 100 may recommend that the requester modify another service parameter of the service request, such as the service location (e.g., changing the pickup location to a more accessible one).

[0072] In further variations, the network computer system 100 can specify in step 256 that the recommended action should be a modification that makes the service request available to additional service providers. For example, the recommended action could be a modification of the service type originally requested. The recommended action could, for instance, suggest that the service requester raise or lower the requested service level.

[0073] As a further variation, the network computer system 100 can specify in step 256 that the recommended action is to allow the network computer system to forward the service request to service providers that jointly offer several different types of services. In the latter case, the recommended action can be chosen to minimize the processing time until the service request is assigned.

[0074] In step 260, the network computer system can generate 100 pieces of content that display the proposed action to the user. For example, the content configuration component 126 can transmit content data indicating a modification of the original service request, a change in the type of service requested, and / or a change to requesting multiple service types simultaneously. The content data 125 can be generated to be interactive, allowing the service requester to choose whether to implement the recommended actions. Furthermore, the content can provide information about the modified transportation request, including a fare change (e.g., based on the change in service type) and / or a recalculation (or update) of the processing time.

[0075] In some examples, after step 260, the network computer system 100 can perform steps 220 and 230 of the exemplary procedure 200. For example, if the requester chooses to modify the service request or change the type of service request, the procedure returns to step 220, where a predicted processing time for the modified service request is determined. Additionally, in step 230, content data can be sent to the service provider's device to cause the service provider's device to display content based on the updated or newly determined processing time.

[0076] While procedure 200B is described for a context where the actual processing time exceeds the predicted processing time, steps 250, 252, 254, 256, and 260 (and their associated examples) can also be implemented in other contexts. For example, steps 250, 252, 254, 256, and 260 can be performed while the predicted processing time is running. These steps might be implemented, for instance, when it is determined that the predicted processing time exceeds a threshold (such as ten minutes), or in response to one or more service providers declining an invitation for the service request. In such examples, the content displayed during the processing time could include information about modifications the requester can make to their request, as well as information about the modified service request.The information may include, for example, a fare, an updated processing time for the amended transport request and / or an estimated time of arrival of the requester at the destination. EXAMPLE USER INTERFACES

[0077] Fig. Figures 3A to 3A show exemplary user interfaces for configuring an interface for service requests based on a processing time prediction according to one or more embodiments. The description of the examples may vary accordingly. Fig. 3A to Fig. 3C on elements of Fig. 1. Reference is made to illustrate a suitable functionality for the described example.

[0078] With reference to Fig. 3A to Fig. 3C displays a requester computer device 300 with a service request interface 310 that has a content interface or function. The content interface or function may correspond to a user interface configured based on, or otherwise based on, a predicted processing time of the network computer system 100. The predicted processing time may include or correspond to a predicted allocation time, which corresponds to a period of time extending from the time the network computer system 100 receives a transport request transmitted by the requester computer device until the time a selected service provider accepts an invitation to fulfill the service request. Once the service request has been transmitted, examples from the requester's perspective envisage the requester device 102 to immediately (e.g.,within one second) displays intermediate content that is based on or contains the predicted processing time.

[0079] In examples, the service request interface 310 can be based on content data 125 transmitted by the network computer system 100, where the content data 125 specifies or is based on the predicted processing time. The service request interface 310 can be provided in response to a user submitting a service request. The service request interface 310 can contain content based on the predicted processing time.

[0080] In one example of Fig. Interface 3A for service requests 310 displays a content interface 312 that indicates the predicted processing time. The content interface 312 can be implemented as an alphanumeric countdown timer 315, which starts a countdown on the computer device 300 from the predicted processing time. The content interface 312 can be dynamic in that the countdown timer 315 can count down in a way that visualizes the remaining time until a service provider is assigned to the user's service request. Furthermore, the content interface 312 can also be dynamic in that it can be updated by the network computer system 100, for example, based on the progress of the processes implemented to assign the requester to a service provider.The countdown timer can be adjusted, for example, if one of the processes used to assign the user's service request is faster or slower than predicted. Furthermore, the countdown timer can be adjusted if an event occurs that was not considered when determining the predicted processing time. Examples of such events include the rejection of the service request by one or more available service providers.

[0081] In one example of Fig. 3B displays the service request interface 310 and a content interface 322 containing a graphical representation 325 of a countdown time that starts from a predicted processing time. In the example shown, the content interface 322 features a dynamic hourglass that visualizes the remaining time of the countdown. Numerous other graphical / animated features can be used to represent a countdown time. For example, the graphical / animated timers can be represented as a falling object, with the object's distance from the ground indicating the remaining time.

[0082] In one example of Fig. 3C's service request interface can include an Interaction Interface 332 (IUI) or function that provides interactive content. The Interaction Interface 332 can be configured to keep the user engaged. In one example, the Interaction Interface 332 can be configured as an arcade game for the user to play for enjoyment. Alternatively, an Interaction Interface can display other types of games (e.g., guessing games) or puzzles (e.g., crosswords, Hangman, Sudoku, etc.).

[0083] In examples, the network computer system 100 can transmit content data 125 to enable the requesting computer device 300 to display one of several possible content interfaces 312, 322, 332. The determination of which content interface to display can be based, at least in part, on the predicted processing time. For example, if the predicted processing time exceeds a threshold, an interaction interface 332 can be selected for the user. Furthermore, the type of interaction interface 322 displayed (e.g., the type of game) can also be based on the predicted processing time. For example, the selection of the interaction interface 322 to display (e.g., the game or activity with which the user is to be engaged) can be based, at least in part, on the predicted processing time. The selection of the interaction interface 322 can, for example,The predicted duration of a game or other form of interactive activity corresponds to the expected duration of the activity. If the predicted processing time is below the threshold, the selected user interface can display a countdown timer. Furthermore, the interface can provide both a countdown timer and an interaction interface (322). HARDWARE DISPLAY

[0084] Fig. Figure 4 is a block diagram showing a computer system on which one or more of the embodiments described herein can be implemented. A network system, as in an example from Fig. As described in section 1, a computer system can be used to achieve 400 different results. Fig. 4 can be implemented. In addition, the exemplary procedures 200A and 200B can be implemented using the 400 computer system.

[0085] In one implementation, the Computer System 400 comprises one or more processors 410, memory resources 420, and a communication interface 430. The Computer System 400 has at least one processor 410 for processing information. The memory resources 420 may include random access memory (RAM) or other dynamic storage devices for storing information and instructions to be executed by the processor(s) 410. The memory resources 420 may also be used to store temporary variables or other intermediate information during the execution of instructions to be carried out by the processor(s) 410. The Computer System 400 may also have other forms of memory resources, such as static storage devices for storing static information and instructions for the processor 410.The storage resources 420 can store information and instructions, including instructions 442 for predicting processing time and transmitting content data to the request devices 102.

[0086] The computer system 400 can communicate with one or more networks 480 (e.g., a cellular network) via the communication interface 430 using the network connection (wireless or wired). Through the network connection, the computer system 400 can communicate with one or more other computer devices and one or more other servers or data centers. In some variations, the computer system 400 can receive service requests from requesting devices via the network connection 480. Furthermore, the computer system 400 can receive information from provider devices, from which predictions regarding deployment rates, location preferences, and other aspects described herein can be generated.

[0087] The examples described herein relate to the use of the computer system 400 to implement the techniques described herein. According to one embodiment, these techniques are performed by the computer system 400 in response to the processor 410 executing one or more sequences of one or more instructions contained in the memory resource 420. Such instructions may be read into main memory from another machine-readable medium, such as a storage device. The execution of the sequences of instructions contained in the main memory 420 causes the processor 410 to perform the procedures described herein. In alternative implementations, hard-wired circuitry may be used instead of, or in combination with, software instructions to implement the examples described herein.The examples described are therefore not limited to any specific combination of hardware circuits and software.

[0088] Fig. Figure 5 shows a requester computer device on which one or more embodiments can be implemented. In one example, the requester computer device corresponds to a user device 500, e.g., a mobile device (e.g., a tablet). The user device 500 can run a service application 432 to submit service requests to a network service, such as that provided by the network computer system 100. Fig. 1 is provided. In addition, the user device can implement 500 procedures, as described in an example from Fig.2 are described. In many implementations, a requester computer device 500 can correspond to a mobile computer with a touch-sensitive display or touch-sensitive input interface, such as a tablet computer or a computer that can be held in one or two hands. In variations, the computer device includes a laptop, a VR or AR headset, and the like.

[0089] The requesting computer device 500 comprises one or more processors 540 and memory resources 530. Instructions that may correspond to the service application 532 are stored in the memory resources 530. The processor(s) 540 execute(s) the instructions of the service application 532 to generate an application user interface 534, e.g., a service request interface. Additionally, the computer device 400 includes a microphone 545, a camera 550, a satellite receiver 560, and / or a wireless communication interface 510.

[0090] A touchscreen 520 can receive user input 518 to interact with or engage with the user interfaces generated by the service application 532. The microphone 545 can also be used in conjunction with a speech transcription tool that can translate speech utterances into input 518, which is processed by the service application 532. In addition to or in a variation of this, the service application 532 generates output, as described in various examples. In some examples, the user can interact with the executing service application 532 by providing input 518, for example, via the screen 520, the microphone 545, or another input mechanism. The input 518 can be used to specify attributes of a service request, which can be transmitted to the network computer system 100 via one or more networks 501.Furthermore, user input 518 can be received and processed after the service request has been submitted, e.g. to interact with an interface of the service application where interaction content or other types of content are displayed. CONCLUDING REMARKS

[0091] It is intended that the examples described herein extend to individual elements and concepts described herein, independently of other concepts, ideas, or systems, and that the examples include combinations of elements mentioned anywhere in this application. Although the examples are described here in detail with reference to the accompanying drawings, it is understood that the concepts are not limited to these specific examples. Therefore, the scope of the concepts is intended to be defined by the following claims and their equivalents. Furthermore, it is intended that a specific feature, described either individually or as part of an example, may be combined with other individually described features or parts of other examples, even if the other features and examples do not mention this specific feature.The absence of a description of combinations should not preclude rights to such combinations. QUOTES INCLUDED IN THE DESCRIPTION

[0000] This list of documents cited by the applicant was automatically generated and is included solely for the reader's convenience. The list is not part of the German patent or utility model application. The DPMA accepts no liability for any errors or omissions. Cited patent literature

[0000] US 18 / 217,186

[0001] US 63 / 443,611

[0001]

Claims

[1] A network computer system comprising: one or more processors; a memory for storing a set of instructions; where one or more processors execute the set of instructions to perform operations that include the following: Receiving, via one or more networks, a service request for a service from a requesting device; Prediction of a service request processing time, wherein the processing time extends from the time the service request is received until the time a service provider selected by the network computer system accepts an invitation to provide the service; and Transferring content data to the requesting device, whereby the content data causes the requesting device to display content that is based at least partially on the predicted processing time. [2] The network computer system according to claim 1, wherein the operations further comprise: Initiating the execution of an assignment process to assign the service request to one or more service providers; and the transmission of content data includes causing the requesting device to display dynamic content indicating the predicted processing time while the mapping process is being carried out. [3] The network computer system according to claim 2, wherein the transmitted content data causes the requesting device to display a countdown timer. [4] The network computer system according to claim 3, wherein the countdown timer is provided in a graphical or dynamic form. [5] The network computer system according to claim 1, wherein the transfer of content data comprises the selection of a user interface from several available user interfaces based on the predicted processing time for the requesting device. [6] The network computer system according to claim 5, wherein the selection of the user interface includes the selection of an interaction interface for the user based on the predicted processing time. [7] The network computer system according to claim 6, wherein the selection of the user interface comprises the selection of the interaction interface based on a finding that the predicted processing time exceeds a limit. [8] The network computer system according to claim 1, wherein the operations further comprise: Determining a set of attributes for the service request; and where the prediction of the processing time is based at least partially on the set of attributes of the service request. [9] The network computer system according to claim 8, wherein the set of attributes includes a service request target. [10] The network computer system according to claim 9, wherein the set of attributes includes at least either an estimated travel time or an estimated travel distance of a service provider to complete the service request. [11] The network computer system according to claim 1, wherein the operations further comprise: Identify a number of service providers available to fulfill the service request; and where the prediction of the processing time is based at least partially on the number of service providers. [12] The network computer system according to claim 1, wherein the operations further comprise: Determine the number of service requests that are not assigned to any service provider for a geographic area and time period relevant to the service request; and where the prediction of the processing time is based at least partially on the specific number of service requests. [13] The network computer system according to claim 1, wherein the operations further comprise: Determine the number of one or more service providers available to fulfill the service request; Determining a probability value for each of the one or more service providers that the service provider will accept or reject the invitation; and where the prediction of the processing time is based at least partially on the probability value determined for each of the one or more service providers. [14] The network computer system according to claim 13, wherein the operations further comprise: Accessing a data store to determine, for each of the one or more service providers in a recent period, an invitation response to one or more invitations to fulfill a corresponding service request. where determining the probability value for each of the one or more service providers is based at least partially on the determined invitation response of the service provider to one or more invitations. [15] The network computer system according to claim 1, wherein the operations further comprise: Determine that the actual processing time for the service request exceeds the predicted processing time; and Recommending one or more actions to the user of the requesting device in response to the finding that the actual processing time exceeds the predicted processing time. [16] The network computer system according to claim 15, wherein the one or more measures comprise a modification of one or more parameters of the service request. [17] The network computer system according to claim 16, wherein one or more parameters comprise a service type for the service request. [18] The network computer system according to claim 15, wherein the one or more measures comprise a measure in which the service request is submitted to several service providers offering different types of service levels. [19] Non-volatile, computer-readable medium that stores instructions which, when executed by the one or more processors of the network computer system, cause the network computer system to perform operations that include: Receiving, via one or more networks, a service request for a service from a requesting device; Prediction of a service request processing time, wherein the processing time extends from the time the service request is received until the time a service provider selected by the network computer system accepts an invitation to provide the service; and Transferring content data to the requesting device, whereby the content data causes the requesting device to display content that is based at least partially on the predicted processing time. [20] A computer-implemented method comprising: Receiving, via one or more networks, a service request for a service from a requesting device; Prediction of a service request processing time, wherein the processing time extends from the time the service request is received until the time a service provider selected by the network computer system accepts an invitation to provide the service; and Transferring content data to the requesting device, whereby the content data causes the requesting device to display content that is based at least partially on the predicted processing time.

Images