Dynamic scheduling system for planned service requests.

Abstract

A computer system monitors a set of a user's computing resources to determine a planned user event, as well as a set of service parameters for the planned user event. The computer system may further schedule a service request for the planned user event, based at least in part on the event's location. Additionally, the computer system may perform an action on behalf of the user in relation to the start of the service request at a scheduled time.

Description

1 / 72 Descriptive Report of the Invention Patent for: "DYNAMIC SCHEDULING SYSTEM FOR PLANNED SERVICE REQUESTS" TECHNICAL FIELD

[001] The examples described in the present invention relate to a dynamic scheduling system for planned service requests. BACKGROUND

[002] There are several on-demand services to offer users a variety of services: transportation, shipping, food delivery, shopping, pet care, mobilized task force, and others. Typically, on-demand services leverage resources available through mobile devices, such as wireless devices (e.g., cell phones), which provide developers with a platform that can access sensors and other resources available through the mobile device. Many on-demand services include dedicated applications (sometimes called “apps”) to communicate with a network service through which an on-demand service is offered. BRIEF DESCRIPTION OF THE DRAWINGS

[003] FIG. 1 illustrates an example of a system for scheduling service requests for individual users.

[004] FIG. 2A illustrates an example of a service of Petition 870200030091, dated 05 / 03 / 2020, page 6 / 102 2 / 72 arrangement that includes a service scheduling system, as described in an example in FIG. 1.

[005] FIG. 2B is a block diagram representation of an application feature, according to one or more example(s).

[006] FIG. 3 illustrates an example of a method for scheduling service requests for a user's planned events and activities.

[007] FIG. 4 is a block diagram illustrating a computer system in which the embodiments described in the present invention can be implemented.

[008] FIG. 5 is a block diagram illustrating a mobile device in which the examples described in the present invention can be implemented. DETAILED DESCRIPTION

[009] The examples provide a computer system and method for scheduling service requests for planned user events and activities. According to some examples, a computer system monitors a set of a user's computing resources to determine a planned user event, as well as a set of service parameters for the planned user event. The computer system may additionally schedule a service request for the planned user event, based at least in part on the event's location. Petition 870200030091, dated 05 / 03 / 2020, page 7 / 102 3 / 72 Additionally, the computer system can perform an action on behalf of the user regarding the initiation of the service request at a scheduled time.

[0010] A common goal of ride-hailing services is to utilize leveraged personal mobile technology to bring convenience to users. For example, urban commuters can eliminate parking by using ride-hailing services. Ride-hailing services have also implemented technological solutions to provide an easier and more convenient alternative to the conventional ride-hailing approach. Unlike conventional ride-hailing services, ride-hailing services (i) allow users to interact with their mobile devices to generate service requests and (ii) match service requests with nearby available service providers so that a service requester can find a service provider at a location chosen by the requester.Among other benefits, courier services have eliminated the manual and uncertain effort that was often required for users to obtain transportation services. By leveraging the location recognition capabilities of mobile devices, courier services can track both requesters and service providers to their destinations. Petition 870200030091, dated 05 / 03 / 2020, page 8 / 102 4 / 72 facilitate the meeting of one or more parties at a service departure location, as well as tracking trips, and determining fares after the trips are completed.

[0011] In this context, the examples acknowledge that some users have difficulty planning the use of courier services for planned or scheduled activities. Some users do not consider, for example, that additional time needs to be allocated for a service provider to be selected, and for the service provider to travel to the requested pickup location. Furthermore, the availability of service providers can be fluid, meaning that sudden shortages of service providers can occur. Additionally, users do not always track the travel time to receive the courier service to a destination location.

[0012] In this context, the examples provide a system that schedules transportation service requests for users based on knowledge or information about when the user intends to arrive at a specific location. In this way, examples such as those described can calculate the appropriate service request time, taking into account factors such as congestion and service provider availability. By determining when the user should make a transportation service request, the examples avoid situations where the user Petition 870200030091, dated 05 / 03 / 2020, page 9 / 102 5 / 72 arrives too early and wastes time, or arrives late for an event. Given the user's reliance on personal mobile technology (e.g., mobile devices), the timely transmission of transportation service requests reduces the user's device downtime, thus preserving battery life and device usage.

[0013] Furthermore, the examples provide that scheduled transportation service requests are dynamic, to reflect events or conditions that require, for example, that the planned service request time be changed. The determination of service request times for planned service requests is therefore dynamic and subject to updating, for example, based on the user's current location, environmental conditions, user-owned information leveraged by other user devices, and other factors that may be outside the user's knowledge.

[0014] As used in the present invention, a client device, a driver device, and / or a computing device refers to devices corresponding to desktop computers, cellular devices or smartphones, personal digital assistants, wearable electronic devices, laptops, tablets, television (IP Television), etc., which can provide network connectivity and processing capabilities for communication with the system through a Petition 870200030091, dated 05 / 03 / 2020, page 10 / 102 6 / 72 network. A driver device may also correspond to custom hardware, onboard devices, or onboard computers, etc. The customer device and / or the driver device may also operate a designated application configured to communicate with the transportation arrangement system.

[0015] Although some examples described in the present invention relate to transportation services, the transportation arrangement system may allow other location-based on-demand services (e.g., a food truck service, a delivery service, an entertainment service) to be arranged between individuals and service providers. For example, a user may request an on-demand service, such as a delivery service (e.g., food delivery, courier service, food truck service, or product shipment) or an entertainment service (e.g., mariachi band, string quartet) using the system, and the system may select a service provider, such as a driver, food supplier, band, etc., to provide the on-demand service to the user.

[0016] One or more embodiments described in the present invention provide(s) that methods, techniques and actions performed by a computing device are performed programmatically, or as a method implemented by Petition 870200030091, dated 05 / 03 / 2020, page 11 / 102 7 / 72 computer. Programmatically, as used in the present invention, means through the use of computer-executable code or instructions. These instructions may be stored in one or more memory resources of the computing device. A step performed programmatically may or may not be automatic.

[0017] One or more embodiments described in the present invention may be implemented using modules, mechanisms, or programmatic components. A module, mechanism, or programmatic component may include a program, a subroutine, a portion of a program, or a software component or a hardware component capable of performing one or more declared tasks or functions. As used in the present invention, a module or component may exist within a hardware component independently of other modules or components. Alternatively, a module or component may be a shared element or process of other modules, programs, or machines.

[0018] Some embodiments described in the present invention may generally require the use of computing devices, including processing and memory resources. For example, one or more embodiments described in the present invention may be implemented, in whole or in part, in computing devices such as servers, desktop computers, mobile phones or smartphones, tablets, Petition 870200030091, dated 05 / 03 / 2020, page 12 / 102 8 / 72 wearable electronic devices, laptops, printers, digital picture frames, network equipment (e.g., routers), and tablets. All memory, processing, and network resources may be used in connection with the establishment, use, or performance of any embodiment described in the present invention (including the performance of any method or the implementation of any system).

[0019] Furthermore, one or more embodiments described in the present invention may be implemented through the use of instructions that are executable by one or more processor(s). These instructions may be carried on a computer-readable medium. The machines shown or described in the figures below provide examples of processing resources and computer-readable media on which instructions for implementing embodiments of the invention may be carried and / or executed. In particular, the numerous machines shown with embodiments of the invention include processor(s) and various forms of memory for storing data and instructions. Examples of computer-readable media include permanent memory storage devices, such as hard disks in personal computers or servers.Other examples of computer storage media include portable storage devices such as CD or DVD drives, flash memory (such as that used in smartphones, etc.). Petition 870200030091, dated 05 / 03 / 2020, page 13 / 102 9 / 72 multifunction devices or tablets), and magnetic memory. Computers, terminals, network-enabled devices (e.g., mobile devices such as cell phones) are all examples of machines and devices that utilize processors, memory, and instructions stored on computer-readable media. Additionally, embodiments may be implemented in the form of computer programs, or a computer-usable carrier medium capable of transporting that program.

[0020] FIG. 1 illustrates an example of a system for scheduling service requests for individual users. In particular, a 100 service scheduling system can be provided to facilitate a user making service requests that result in the user's timely arrival at a scheduled event. Furthermore, the 100 system can update planned service requests based on factors such as user activity, environmental conditions, user-related information leveraged from the user's other devices, and other events.

[0021] According to some examples, system 100 is implemented as a network service. Therefore, system 100 can be implemented on, for example, one or more server(s) or other networked computer machines. System 100 can be implemented as part of a transport arrangement service, which operates to do Petition 870200030091, dated 05 / 03 / 2020, page 14 / 102 10 / 72 matching of transportation service requests received from requesting devices with service providers that are available and in the vicinity of the requester's transportation request departure location. In variations, the 100 system can be implemented as a separate or independent service that can interact with a transportation arrangement service or user device (e.g., through a service application for the network service). Still further, in other variations, the 100 system can be implemented at least in part on individual user devices. For example, the functionality described with the 100 system can be implemented as part of a service application that runs on individual user mobile devices.

[0022] In more detail, the system 100 may include a service request scheduling means 120 and a service request manager 150. The service request scheduling means 120 operates to schedule service requests for planned user activities. The service request manager 150 includes one or more programmatic process(es) that may be triggered to perform an action, or a series of actions, to facilitate the user, or otherwise act on behalf of the user, in making a timely transportation service request for a scheduled event. Petition 870200030091, dated 05 / 03 / 2020, page 15 / 102 11 / 72

[0023] According to some examples, the system 100 may include or interface with a user activity monitor 110 to determine user activity information 111 and scheduled event information 113. The service request scheduling medium 120 may also access user profile information 109 to determine the user's routine activities 115, such as a given user's normal commute from home to work, or from work to home. The service request scheduling medium 120 may process user activity information 111 provided by the user activity monitor 110 to identify planned user activities, including scheduled events (e.g., concert, party, air travel, etc.). The service request scheduling medium 120 may schedule new transportation requests for planned user events.Additionally, the service request scheduling medium 120 can process the respective user activity information 111 to modify or update a scheduled user transportation request. For example, the service request scheduling medium 120 can delay a service request when it retrieves user activity information 111 that indicates the user will not be available during the scheduled service time. The user activity information 111 in this... Petition 870200030091, dated 05 / 03 / 2020, page 16 / 102 12 / 72 context can be the user's location or information leveraged from devices linked by the user (e.g., smartwatch).

[0024] The user activity monitor 110 may include an online event monitor 112 which (with the user’s permission) may access individual online accounts linked to the user, such as an online calendar account, a social networking account, an email provider, a booking account, etc. The online event monitor 112 may identify information from scheduled events 113 from the user’s online resources, which the service request scheduling medium 120 may receive and process to generate a corresponding event record 102.

[0025] As an addition or variation, the user activity monitor 110 includes one or more device monitors 114 that monitor one or more of the user's computing devices (e.g., mobile device 92, smartwatch 94, etc.) to obtain user activity information 111. The user activity information 111 may include or correspond to contextual information to update the scheduled event log 102 determined by the service request scheduling medium 120. For example, the user activity monitor 110 may include processes to monitor the user's mobile device 92 Petition 870200030091, dated 05 / 03 / 2020, page 17 / 102 13 / 72 (e.g., multifunctional wireless messaging / telephony device, tablet) or multiple mobile devices simultaneously (e.g., mobile device 92 and / or smartwatch 94 or other wearable electronic device). User activity information 111 may include, for example, a user's location information (e.g., such as that provided from a satellite location receiver), motion data (e.g., such as that provided from an accelerometer and / or gyroscope), device usage data (e.g., usage related to running different applications on a user's mobile device), and / or activities performed by specific applications (e.g., online shopping application).

[0026] In some variations, profiler 118 can access a user account data store 103 to determine, for example, the user's service request history. From the user's request history, profiler 118 can determine the destinations of common, favorite, or recent service requests. In some variations, profiler 118 can also process user activity information 111 to obtain, for example, contextual information that identifies routine user activities 115 that may require transportation. For example, profiler 118 can Petition 870200030091, dated 05 / 03 / 2020, page 18 / 102 14 / 72 identify a common destination for the user (e.g., user's business address) based on the user's location during the workday, even if the user's business address is not one of the user's favorite or recent destinations via transportation service (e.g., the user may normally drive to work). The profiler 118 can store certain routine activities 115 as part of the user profile 109 in the user profile provider 105. In this way, the profiler 118 can determine a user activity profile.

[0027] According to some examples, the service request scheduling medium 120 includes an event determination component 122 and a service time component 124. The event determination component 122 can process user activity information 111 and scheduled event information 113, as provided by the user activity monitor 110, in order to determine a service request queue 155 of service requests planned for the user during an upcoming time period. The service request queue 155 may include service requests for events that are determined to be transportation events (e.g., events for which the user is likely to request transportation). In some examples, planned service requests may be determined for routine activities. Petition 870200030091, dated 05 / 03 / 2020, page 19 / 102 15 / 72 115 (e.g., user going to work from home, user going home from work), scheduled event information 113 (e.g., user buys theater tickets for a specific day and time) and / or detected activities determined from user activity information.

[0028] In one implementation, the event determination component 122 implements a rules mechanism to determine when a detected activity, calendar event, or routine activity should be treated as a planned event record 102. A planned event record 102 can identify user events (or planned activities) that correspond to events the user wishes to participate in and possibly travel to. In some variations, the event determination component 122 generates an event record 102 for each activity or event that satisfies a confidence threshold (e.g., probability determination) of being a transportation event (or an event the user is likely to want to receive transportation service for in connection with a corresponding event location). In one implementation, the event determination component 122 can generate the event record 102 using a normalized or common format.The event determination component 122 can populate event record 102 with metadata that identifies (i) a parameter of. Petition 870200030091, dated 05 / 03 / 2020, page 20 / 102 16 / 72 departure time 104, corresponding to a departure time (or time window) for the user to arrive at the activity location and (ii) an event location parameter 106 (e.g., activity address or geographic coordinates). The scheduled event record 102 may also include a service departure location parameter 108, corresponding to a predicted or determined departure location for the user within a duration immediately preceding the event departure time. In some examples, the service departure location 108 may be predicted based on the user's activity and / or a user activity profile. In variations, the service departure location parameter 108 may be dynamic, where the departure location may correspond to the user's current location at the time of the service request.Given that the timing of a service request may depend on the user's current location, the examples show that the service request scheduling medium 120 monitors user activity (via the user activity monitor 110) to update the event log parameters 102. Each event log 102 generated by the event determination component 122 can also be associated with an identifier for the user. As described below, the queue of service requests for user 155 can be determined during a given interval of... Petition 870200030091, dated 05 / 03 / 2020, page 21 / 102 17 / 72 time (for example, every 4-hour interval during the day) from scheduled event records 102 that are stored in event data storage 125.

[0029] In some examples, the event determination component 122 may generate scheduled event records 102 as a recommended set of scheduled service requests. The service request scheduling medium 120 may communicate a recommendation 129 that identifies information from a scheduled event record 102 (or set thereof). The recommendation 129 may be provided for the user to confirm or verify as related to a transportation event, meaning that the user's confirmation identifies an event for which the user may wish to receive a transportation service. For example, the service request scheduling medium 120 may send a confirmation notification 151 (e.g., an in-app notification, a calendar update, etc.) to the user, identifying information from the scheduled event record 102 of the recommended set.In some variations, confirmation notification 151 may prompt the user to respond and confirm (or decline) that the user intends to use a transportation service in connection with an event identified in scheduled event record 102. If the user provides confirmation input, then scheduled event record 102 may be marked as one. Petition 870200030091, dated 05 / 03 / 2020, page 22 / 102 18 / 72 Transportation Service Event. Event records 102 that are marked by confirmation or default as transportation service event identification may be part of the user's service request queue 155. Depending on the implementation, events that are not confirmed or dismissed may also be retained in the event data store 125. If the user provides a negative confirmation (e.g., dismisses the notification, rejects the recommendation, etc.), the corresponding event record 102 may be removed from the event data store 125.

[0030] In some examples, the event determination component 122 may format recommendations 129 to include pre-filled information that identifies the event (e.g., by descriptor, location, date, and departure time), an estimated departure time of the service (e.g., pick-up time), and the selected or default service type. In some variations, recommendations 129 may be prioritized, with higher-ranked determinations being presented more prominently to the user (e.g., on the user's mobile device 92 and / or smartwatch 94).

[0031] In some examples, the event determination component 122 may use a rules mechanism to determine which event records 102 signify transport service events. In some examples, the user's response to the recommended event records 102 may be Petition 870200030091, dated 05 / 03 / 2020, page 23 / 102 19 / 72 is used to develop the user profile, which can be stored in the user profile store 105. For example, the event determination component 122 can determine that the user is likely to want transportation services for certain events (e.g., restaurant reservations) or types of events (e.g., routine work event), for certain days or times of the week (e.g., Friday nights), or for certain locations (e.g., in an urban area). The event determination component 122 can also process determined events to cancel or modify planned service requests as needed. For example, routine activities 115 (e.g., service request to transport the user to work) can be canceled on a holiday, or when a calendar event indicates that the user is out of town.

[0032] Furthermore, the event determination component 122 may include logic to keep or discard a scheduled event record 102 that does not receive a response from the user. The event determination component 122 may base the determination on, for example, previous user responses to confirm or discard event records 102. For example, the event determination component 122 may determine whether to keep or discard a given Petition 870200030091, dated 05 / 03 / 2020, page 24 / 102 20 / 72 event log 102 based on user profile information 109 (as determined from user profile storage 105), which may include an aggregation of past user interaction with confirmation notifications from the event determination component 122. Based on past interactions, the event determination component 122 may determine the user's tendency or preference to (i) confirm scheduled event logs 102 that are of interest to the user as transport events, versus the user's tendency to discard event logs that are not of interest as transport events to the user and / or (ii) accept or act on scheduled events that have not been confirmed. In such examples, the user's response to the confirmation notification 151 may be logged with user profile storage 105.The user can also provide inputs to change or modify the 102 event record, such as to specify a specific type of service (e.g., large vehicles) for the event and / or specify an additional departure location (e.g., friend's address). Changes or modifications to the 102 event record to specify a specific type of service can also be dynamically adjusted based on information leveraged by applications linked by the user (e.g., social media events indicating that the user will be attending an event). Petition 870200030091, dated 05 / 03 / 2020, page 25 / 102 21 / 72 with a friend to generate an option to select an additional service location) or the provided input (for example, the number of checked bags the user has can be obtained from a user's airfare information to indicate whether a larger vehicle is needed for the user's service request).

[0033] In variations, user profile information 109 may also store settings, in which the user may specify their preference for having the scheduled event record 102 become part of user service request queue 155. For example, the user may select certain types of activities (e.g., activities generated in a specific online calendar or for a specific event type) as becoming part of user service request queue 155 automatically, upon detection by the event determination component 122.

[0034] The service time component 124 can implement operations to determine the service scheduling parameters 123 for individual event records 102 of the event data store 125. For example, the service scheduling parameters 123 can correspond to (i) a service time to meet the user for the event location from an expected or determined user location, and (ii) a Petition 870200030091, dated 05 / 03 / 2020, page 26 / 102 22 / 72 service arrangement schedule, to select an available service provider for the user and have the provider arrive at the departure location identified by the corresponding event record 102. When determining the service scheduling parameters 123, the service time component 124 may use a service departure location, as determined, for example, by the departure location parameter 108 of the corresponding event record 102, a current or recent location of the user, or an expected or planned location of the user (for example, as determined from the user's profile information). In variations, the service time component 124 determines relevant information to update an event record 102 that identifies a future service request, based on user activity information 111, as provided in the user activity monitor 110.User activity information 111 can identify, for example, the user's current location. Consequently, the service time component 124 can update a specific event record 102 based in part on the user's current location.

[0035] In some examples, the service time component 124 may be triggered to update the service scheduling parameters 123 of a scheduled event record 102, monitoring user activity and / or Petition 870200030091, dated 05 / 03 / 2020, page 27 / 102 23 / 72 environmental conditions during a given time interval preceding the determined departure time of the corresponding event (e.g., a 2 or 4 hour interval prior to the activity's departure time). For a given event record 102, the service time component 124 determines the scheduling parameters 123 that identify when a corresponding service request for event record 102 should be made. The service timer component 124 can identify, from the scheduling parameters 123, a service request time, corresponding to a time interval prior to the departure time of a corresponding event, when the corresponding service request for a given record is timely, meaning that the service request is not made too early (so that the user does not leave too early for the event location) nor too late (so that the user arrives at the event location on time).The service request time may be based on time intervals that include (i) a service time for a service vehicle to complete the service from the service departure location to the event location and (ii) a service provider arrival time, corresponding to the time interval marked by the service provider's arrival after a service request transmitted by the user. As described in the examples, the service time... Petition 870200030091, dated 05 / 03 / 2020, page 28 / 102 24 / 72 may be subject to change, as factors such as congestion, roadworks, and other conditions may cause delays or variations in relation to the planned or normal travel time of a given route. Similarly, the arrival time of the service provider may also vary based on the availability of service providers and the proximity of available service providers to the service departure location. For example, service provider availability may vary based on factors such as the location of available service providers and the number of applicants in a given time interval.As described in more detail, some examples plan a service request so that the user includes a real-time determination of the arrival time of a corresponding service provider at the service departure location, as well as the service time between the departure and service event locations.

[0036] The service request scheduling medium 120 may also be responsible for uncertainty in the user's location at the time the service request should be made for a given event record. In some examples, the service time component 124 may use, for example, the user activity monitor 110 to repeatedly or continuously update the location of Petition 870200030091, dated 05 / 03 / 2020, page 29 / 102 25 / 72 user for a given event record 102, during a time interval prior to when a service request should be made for a corresponding event. The service time component 124 can update the corresponding scheduled event record 102 based on the current location (or service departure location) of the user being determined or updated (e.g., based on the user's current location) in the time interval preceding when the service request is made.

[0037] Therefore, at a given time interval prior to a departure time of a given event record 102, the service time component 124 may use the service time logic 126 to estimate the likely service time for a service provided to the user. The service time may be based, at least in part, on monitoring user activity information 111 (e.g., current location), as well as environmental conditions such as congestion and service provider availability (e.g., as determined by the regional monitoring service 140, described below).

[0038] The time component of service 124 can also use the availability logic of service provider 128 to determine an expected time interval between Petition 870200030091, dated 05 / 03 / 2020, page 30 / 102 26 / 72 when a given service provider is matched to the user's service request, and the estimated time of arrival of the service provider, marking when the service provider arrives at the service departure location. In this way, the service time component 124 can, for example, make separate determinations of (i) an expected time duration to match a service provider from an available pool of service providers to a service request from a given event record 102; and (ii) an expected duration (e.g., travel time) for the selected service provider to travel and meet the user at the service departure location (e.g., as determined from activity information 111).

[0039] According to some examples, system 100 communicates with regional monitoring service 140 to receive environmental input parameters that may impact service scheduling parameters 123. By way of example, regional monitoring service 140 may include interfaces to third-party information sources that include weather information, traffic reports, information on regional events (e.g., concerts), as well as information on other environmental conditions that may affect service transport times and supplier arrival times. By way of example Petition 870200030091, dated 05 / 03 / 2020, page 31 / 102 27 / 72 For example, the regional monitoring service 140 can identify conditions that increase congestion, or otherwise reduce the travel speed of vehicles on roads near the service start or event locations. In some examples, the regional monitoring service 140 operates in connection with a transportation arrangement service (e.g., see FIG. 2) to monitor position information (e.g., location and speed) of service vehicles in the vicinity of a service start location, an event location, or a segment of the road network between the service start location and the event locations. Based on the monitoring, the regional monitoring service 140 can detect road congestion conditions that may affect the arrival time of service providers or the transportation time of the service from service record 102.By detecting road congestion conditions and monitoring the location and speed of service vehicles, the regional monitoring service 140 can generate, at specified time intervals, a congestion signal 141 to indicate the relative speed of service vehicles on the road in a region that includes the service departure location and / or the event location.

[0040] In some examples, the scheduling method of Petition 870200030091, dated 05 / 03 / 2020, page 32 / 102 28 / 72 Service Request 120 can communicate with the regional monitoring service 140 to detect, for example, a serious accident that will significantly delay the user's travel time. The Service Request 120 scheduling medium can change the service request time to the planned service request to accommodate the possibility of a long trip.

[0041] Additionally, the regional monitoring service 140 can monitor the availability of service providers. Depending on the implementation, the availability of service providers can be based, for example, on one or more of the total number of service providers in the vicinity of the event's departure location, the total number of available service providers, the number of requesters in the vicinity of the service's departure location, and / or in the vicinity of the service's departure location for an available provider. The regional monitoring service 140 can generate, for the specified time intervals, the availability signal 143, which can be indicative of a number of service providers available in a given time interval compared to an expected or actual number of requesters.

[0042] In some examples, the logic of service time 126 uses congestion signal 141 (as Petition 870200030091, dated 05 / 03 / 2020, page 33 / 102 29 / 72 provided by the regional monitoring service 140) which is specific to the event location, the service departure location, and / or the route between the service start and the event location. When determining the service scheduling parameter 123, the service provider availability logic 128 may use the service provider availability signal 143, as determined from the regional monitoring service 140. As an addition or variation, the service provider availability logic 128 may use historical information to determine the availability of service providers and / or the time for providers to arrive at the departure location. In these examples, the historical information may be specific to the location, time of day, time of week, time of day, etc.

[0043] According to some examples, congestion and / or availability signals 141, 143 can be repeatedly determined and associated with geographic areas encompassing service departure locations, event locations, and routes between service departure and event locations. Congestion and / or availability signals 141, 143 can be associated with, for example, corresponding event records that are stored in event data storage 125. As the departure time of certain events becomes Petition 870200030091, dated 05 / 03 / 2020, page 34 / 102 30 / 72 approximates, the service time component 124 may use congestion and / or availability signal values ​​141, 143 in order to take into account time variations (e.g., delays) resulting from, for example, traffic congestion and / or lack of availability of service providers.

[0044] In some variations, the event determination component 122 records the type or source of a determined event for individual event records 102. The service request scheduling medium 120 may use or communicate with other types of monitors to update event records 102, based on the type or source of the determined event. For example, the event determination component 122 may record a planned flight, and the service timing component 124 may use a flight tracker database (which may be provided by a third party) to monitor the requester's flight departure time. In this way, when a requester's flight is delayed, the user's service request queue 155 is automatically updated to reflect the flight change.

[0045] Service request manager 150 can manage a service request queue 155, identified from user event logs 102 that identify upcoming transport events for a given time interval (e.g., 12 hours or one day). Petition 870200030091, dated 05 / 03 / 2020, page 35 / 102 31 / 72 The service request queue 155 may be based on scheduled event records 102 that the given user has confirmed or not dismissed. The service request handler 150 may implement one or more action type(s) to manage individual entries in the user's service request queue 155. In one implementation, the action(s) of the service request handler 150 must notify the user at an appropriate time to initiate a transport service request. The service request handler 150 may, for example, initiate the user's transmission of a notification 149 (or a series of notifications) through a notification interface 157 that processes the notification using a service application running on a user's device.Notification 149 may provide the user with a recommendation to make a transport request within a specific service request interval, as determined by the service time component 124. In variations, the service request manager 150 may use an alternative notification interface 157 to communicate notification 149, such as an SMS (Short Message Service) protocol. In variations, the notification interface 157 may allow other forms of notification, such as triggering the placement of a telephone call (e.g., via the mobile device). Petition 870200030091, dated 05 / 03 / 2020, page 36 / 102 32 / 72 user 92) or alarm tone (e.g., via user 103's smartwatch). Notification 149 itself can be selectively sent at a specific time interval prior to the specified service request time. Additionally, notification 149 can include content to indicate a time when the user should request the transportation service (e.g., "Request transportation in 5 minutes (3:45 PM) to arrive at your event at 4:15 PM").

[0046] As an addition or alternative, multiple notifications may be sent at different time intervals before the service request time. The number of notifications, as well as the time preceding the service request when the user prefers to receive one or more notification(s), may be determined by a user profile. User profile information 109, for example, may indicate a user's preference regarding a number or frequency of notifications, as well as the waiting period preceding the service request time when individual notifications should be sent. User profile information 109 may also specify notification preferences that are specific to a notification type (for example, when a user receives a notification that identifies the service request time for a routine destination, such as the address). Petition 870200030091, dated 05 / 03 / 2020, page 37 / 102 33 / 72 user's commercial).

[0047] As an addition or variation, the service request manager 150 can schedule a service request action with a user's calendar application (e.g., running on a user's mobile device) or the online calendar / scheduling service. The service request can be scheduled within, for example, a time window during which the user must ensure the service request arrives on time for a corresponding event in a given event record 102. Thus, the service request action can be scheduled in the calendar at a different time than the service scheduling record event, to account for both the service time and the service arrival time.

[0048] As an addition or variation, service request handler 150 may generate or otherwise configure the user's requesting device to include a selectable application resource (e.g., a selectable icon that appears on the touchscreen of a user's device) to cause the user's device to initiate the service request. Additionally, the user's selection of the application resource may cause the user's requesting device to transmit a complete service request, using service parameters specified in the corresponding event log. Petition 870200030091, dated 05 / 03 / 2020, page 38 / 102 34 / 72 102 (for example, service departure location, destination as event location).

[0049] Furthermore, in some variations, the service request manager 150 may automatically make the service request for the user at a specific service request time. For example, the service request manager 150 may automatically make a transportation service request for the user when the corresponding event record 102 has been confirmed or verified by the user. As a variation, the service request manager 150 may make the transportation service request on behalf of the user after providing a notification or alert to the user to cancel the automated action of the service request manager 150 before the service request time.

[0050] In some examples, service request manager 150 may perform any of several possible actions (as described above) to manage planned service requests from the user's service request queue. Service request manager 150 may determine the action to be performed on behalf of the user, as well as parameters for performing the action (e.g., time at which the action should be performed) based on, for example, (i) whether the user has confirmed or verified event log 102 as related to an event of Petition 870200030091, dated 05 / 03 / 2020, page 39 / 102 35 / 72 trip, (ii) the type of event (e.g., routine) or scheduled activity, (iii) previous instances of how the planned service request was managed, and / or (iv) user preferences. User profile information 109 may specify, for example, by settings or past behavior, the type of action the user prefers to occur for scheduled user service events. For example, user profile information may indicate one of several possible alternative actions that the service request manager 150 may perform, such as, (i) automatically requesting transportation service for the user at an appropriate time for an activity of a given event record 102; or (ii) providing the user with a programmatic mechanism to trigger the transmission of the service request at an appropriate time for the given event record 102.

[0051] In some examples, user preferences can be determined by monitoring user behavior at time intervals preceding scheduled events for which the user must utilize a transportation service. Profiler 118 can, for example, receive user activity information 111 from user activity monitor 110 during the time interval preceding when the user makes a service request for a specific event record 102. Profiler 118 Petition 870200030091, dated 05 / 03 / 2020, page 40 / 102 Profile 118 (36 / 72) can observe instances where, for example, a notification receives a response from the user, or instances where a service request is canceled by the user, by determining the user's profile on how at least some types of planned service requests should be managed.

[0052] In some instances, the 120 service request scheduling medium may also process an event record to identify additional service parameters, such as (i) a type of transportation the user may prefer (e.g., group transportation, large vehicle); (ii) an additional number of passengers or service locations; and / or (iii) conditions of the service provided (e.g., specific sequence of service stops). The 120 service request scheduling medium may schedule the planned service request, including the service request time, to account for these additional service parameters. For example, determining service availability may take into account that the type of service the user wishes to receive may be less available or take longer to arrive.Additionally, the 120 service request scheduling method can plan ahead for additional time that the service provider may need to find an additional passenger for the user's planned event. For the purposes of this... Petition 870200030091, dated 05 / 03 / 2020, page 41 / 102 37 / 72 For example, a user may purchase two tickets for a planned event (e.g., a concert). System 100 can schedule the transportation service request for the user, with the service request time accommodating an additional service stop to pick up another passenger. The scheduled service request may additionally be subject to dynamic updates based on, for example, the user's location, traffic, or other environmental conditions.

[0053] The service request scheduling medium 120 can also implement a rule-based intelligent workflow for scheduling service requests for the user based on the user's scheduled events. For example, the event determination component 122 can determine that the user has purchased a return flight ticket between two cities, and additionally that the user has made a hotel reservation in the destination city. The service request scheduling medium 120 can use the user's flight event to the destination city to schedule two service requests (i) from the user's current location to the airport, and (ii) from the destination city airport to the hotel. Each of the scheduled service requests can be monitored and modified, for example, by checking for delays and arrival times of a third-party flight service. In the same example, the scheduling medium Petition 870200030091, dated 05 / 03 / 2020, page 42 / 102 38 / 72 of service request 120 can schedule two additional service requests, one from the hotel in the destination city to the airport, and one from the airport in the departure city to home. When the airline ticket is purchased, the service request 120 scheduling medium can also check baggage check-in to determine, for example, a type of service or service vehicle the user should receive.

[0054] Furthermore, in some examples, the service request scheduling medium 120 can override scheduled service requests based on the detection of other scheduled events. For example, a user might receive transportation to work as a routine activity, with the service request being scheduled for the user to arrive at 7:00 AM. If the event determination component 122 detects that the user has a calendar invitation for a meeting before their normal arrival at work, the service request scheduling medium 120 can cancel the original (or usual) planned service request and generate a new service request to allow the user to arrive at work in time for the meeting. Additionally, the service request scheduling medium 120 can configure the service request scheduling based on contextual information, such as user habits, etc. (as determined from the profile). Petition 870200030091, dated 05 / 03 / 2020, page 43 / 102 39 / 72 of the user). For example, the service request scheduling method 120 can anticipate the user's preference to arrive 30 minutes earlier for a cataloged call, based on the user's perceived habits, as determined, for example, by the profile creator 118.

[0055] In some variations, the 120 service request scheduling medium can schedule various actions for the user, including actions that are not directly related to scheduling service requests. For example, the 120 service request scheduling medium can schedule to wake the user at a specific time, and / or monitor (e.g., through sensor data obtained from the user's mobile device) when the user wakes up. In some implementations, the 120 service request scheduling medium can change the service request time for a planned service request based on, for example, user activity. For example, the 120 service request scheduling medium can receive motion sensor data and / or alarm clock data indicating that the user may have overslept.The 120 service request scheduling method can delay the service request time for the planned service request by a certain number of events, or until a specific event is detected (e.g., the user walks outside the house, etc.). Petition 870200030091, dated 05 / 03 / 2020, page 44 / 102 40 / 72 detected by device sensors and / or user location).

[0056] FIG. 2A illustrates an example of a transportation arrangement service that includes a service scheduling system, as described in an example in FIG. 1. In relation to FIG. 2A, a transportation arrangement service 200 includes functionality to implement a service scheduling system 100, as described in an example in FIG. 1. According to some examples, the transportation arrangement service 200 is implemented as a networked computer system that operates to match service requests from requesters with service providers that fulfill service requests. In some variations, the transportation arrangement service 200 is implemented as a networked computer system that implements a distributed functionality platform. When implemented as a distributed platform, the service 200 may incorporate functionality implemented by servers and mobile devices of users (e.g., users and service providers).

[0057] In an example in FIG. 2, the transport arrangement service 200 may include a requester interface 210, a provider interface 220, a matching component 230, and a service data store 240. The requester interface 210 communicates with Petition 870200030091, dated 05 / 03 / 2020, page 45 / 102 41 / 72 applicant service applications 216 that run on the respective mobile devices 202 of applicants. When started, each applicant service application 216 can establish a secure and persistent communication channel with the service 200 using a corresponding instance of the applicant interface 210. Among other operations, the applicant interface 210 can provide instructions and configure operations of the service application 216 in obtaining and transmitting data from the device 203 to the service 200.

[0058] The provider interface 220 can also communicate with provider service applications 218, running on mobile devices 204 of individual providers within a provider group. The service 200 can establish a secure and persistent communication channel with individual service applications 218 running on corresponding mobile devices 204. Each provider service application 218 can be run to obtain and transmit device information, including the current location 207 of the provider device 204. Each provider can also be associated with a vehicle that the provider operates to transport requesters from a service departure location to a destination.

[0059] In one example, a provider can interact with the provider service application 218 to indicate their Petition 870200030091, dated 05 / 03 / 2020, page 46 / 102 42 / 72 respective status as being available to provide service, or alternatively as offline or unavailable. Once the service provider is online, the service provider's application 218 may repeatedly or continuously transmit the location information of the service provider 207. Communications from the service provider device, including the location information of the service provider 207, may be received by the service provider's interface 220. The service provider's interface 220 may store and update a record for the service provider with the active service data storage 240. By way of example, the record for the service provider may identify the current location 207, as well as the status and service identifier of the service provider.The 220 provider interface can repeatedly update the service provider's record regarding the current location and service status of the service provider, based on repeated communications with the 204 service provider device.

[0060] Applicants may use their respective applicant service applications 216 to transmit service requests 201 from their respective mobile devices 202. Service requests 201 may be received by the applicant interface 210, with each service request specifying a set of service parameters 205 (e.g., location of Petition 870200030091, dated 05 / 03 / 2020, page 47 / 102 43 / 72 service departure, destination location). The matching component 230 can use the service parameter set to match individual service requests 201 to matching providers. The matching component 230 can perform matching based on criteria that include the proximity of available service providers (as determined by the service provider's current location 207) to the service departure location (e.g., requester's current location, search location, etc.). When the matching component 230 performs a match, a confirmation communication can be sent to the requester via the requester interface 210. The service provider can also receive an assignment via the provider interface 220.When a service provider is matched, the service provider may also receive the service's departure location, and the service provider may operate a corresponding vehicle toward the service's departure location, where the applicant may be picked up and transported to their destination.

[0061] According to some examples, the requester interface 210 communicates with the requester service applications 216 to receive service requests 201 and device data 203. Each service request 201 Petition 870200030091, dated 05 / 03 / 2020, page 48 / 102 44 / 72 may include service parameters 205 that identify, for example, a starting location and a destination. The requester interface 210 may also instruct individual service applications 216 to interface with and obtain data from (i) a location determination component of the mobile device (e.g., satellite receiver) via a location determination interface 226 of the requester service application 216; (ii) one or more motion sensor(s) (e.g., accelerometer and / or gyroscope) of the mobile device 202 via a sensor interface 228 of the requester service application 216; and / or (iii) another application (e.g., alarm clock, calendar application) or application dataset of the mobile device 202, via a corresponding application interface 232 of the requester service application 216.

[0062] According to some examples, the requester interface 210 may receive request 201, and forward request 201 to matching component 230. Matching component 230 determines a group of available service providers from 240, based at least in part on a comparison of the current location of the service providers and the starting location of the service request. From a group of available service providers, the component of Petition 870200030091, dated 05 / 03 / 2020, page 49 / 102 45 / 72 matching 230 selects a specific service provider for service request 201. Once selected, matching component 230 changes the service status of the service provider, and the provider interface 220 can communicate the service parameters of the matching service request to the requester via the requester's service application 218. Depending on the implementation, the service status of the service provider can change from, for example, available to travel to the departure location (e.g., when the service provider is first matched to the service request and begins traveling to the service departure location), to service provision (e.g., beginning when the requester enters the service provider's vehicle), and from travel to availability (e.g., when the service provider approaches or arrives at the service request destination).

[0063] In some examples, the requester service application 216 includes a user interface component 234 that includes a set of selectable application resources 235 for requesting services. Each application resource 235 can be selected to generate a service request 201 for the service 200, with each application resource 235 being individually assigned to a specific destination. For example, one or more of the resources Petition 870200030091, dated 05 / 03 / 2020, pages 50 / 102 46 / 72 of application 235 can be assigned to a user's favorite destination. With the user's selection of application resource 235, service application 216 can automate the generation of a service request that specifies a destination corresponding to the assigned location of application resource 235.

[0064] According to some examples, the service 200 includes an online event monitor 212 that monitors online accounts and other resources of individual users to detect and record scheduled events 213 that may require transportation for the user. In one implementation, the online event monitor 212 uses user credential information (e.g., login and password), as provided by the user data store 245, to identify and connect to a corresponding third-party network service that hosts a corresponding user account (e.g., the user's online calendar, email storage, booking storage, social networking site, etc.). In one implementation, the online event monitor 212 may utilize any of multiple possible service connectors 208 (each for specific third-party online services) in order to access a user's online account or resource to obtain scheduled events 213.

[0065] In some examples, service 200 includes a device monitoring component 214 that instructs, Petition 870200030091, dated 05 / 03 / 2020, pp. 51 / 102 47 / 72 or configures the operation of the requesting service application 216 to return device data 203 that are indicative of user activity. By way of example, the device monitoring component 214 may trigger the requesting service application 216 to communicate, during a given time interval, device data 203 corresponding to (i) location information, indicating a user's current location, (ii) sensor data, indicating, for example, movement of mobile device 202, and (iii) application data, corresponding to, for example, local calendar records, and application data from the requesting mobile device 202, as well as notifications or other outputs from third parties and / or native applications residing on mobile device 202. In this way, the device monitoring component 214 can determine user activity data 211 from device data 203.The device monitoring component 214 can communicate user activity data 211 to the service scheduling system 100.

[0066] According to some examples, system 100 uses scheduled events 213 to determine a service request queue for individual users. Service request scheduling can use activity data 211 and scheduled events 213 to determine a Petition 870200030091, dated 05 / 03 / 2020, pages 52 / 102 48 / 72 recommended set of planned service requests. In one implementation, system 100 generates notifications for the user to view identified scheduled events 213, in order to designate selected events as transportation events (or events that the user chooses to receive transportation services). In variations, system 100 may automate the designation of at least some events as requiring transportation services, based on, for example, previous user designations.

[0067] A profiler 206 can also access user profile information through the user data store 245, including, for example, previous service requests from individual users, as well as previous user designations by which certain scheduled events are also selected (or otherwise accepted) to be transportation events. The profiler 206 can also identify routine events 215 (e.g., user traveling to work) for the system 100.

[0068] In some examples, system 100 may generate a service request queue 255 for individual users. The service request queue 255 may identify the scheduled event record 102 that has been designated or determined (e.g., by default or through the user profile) as transport service events. Petition 870200030091, dated 05 / 03 / 2020, page 53 / 102 49 / 72 For each transportation service event, the service request queue 225 can specify an event identifier, an event location, an event departure time, and a service request time (or time window). As described in an example in FIG. 1, the service request time can account for (i) the expected duration for a transportation vehicle to travel from the service departure location to the event location, (ii) the expected duration to locate an available service provider, and (iii) an expected travel time for the service provider to arrive at the service departure location. As described in other examples, the determination of the service request time can be affected by environmental conditions, such as road congestion and service provider availability. Environmental conditions can affect the service request time based on the location and time these conditions are present.

[0069] In some examples, system 100 uses activity data 211 to update scheduled service requests for a given user. In one example, system 100 may monitor user activity in order to determine activity data 211 for requesters who have scheduled service requests in an upcoming time period. The monitored activity data 211 may Petition 870200030091, dated 05 / 03 / 2020, pp. 54 / 102 50 / 72 to identify, for example, the requester's current location, which may also coincide with the service's departure location when the transport request is made. Thus, if the user changes their location in an interval prior to the scheduled service request, the user's changed location can be detected and used to update the specific entry in the user's service request queue 255.

[0070] According to some examples, a 244 regional monitoring component can monitor a given region using the 240 active service data store. The 240 active service data store can track service providers by location and status. The 244 regional monitoring component can monitor the 240 active service data store to identify, for example, service providers that are operating on roads but moving at slow speeds. As an addition or variation, the 244 regional monitoring component can also identify sub-regions where there is an insufficient supply of service providers. The 244 regional monitoring component can include logic to generate geographic coordinates and / or route segments that identify locations affected by congestion or other environmental conditions. The 244 regional monitoring component can additionally Petition 870200030091, dated 05 / 03 / 2020, page 55 / 102 51 / 72 assign values, in terms of, for example, time units, weights or other parameters, to reflect the presence and / or magnitude of congestion or other environmental conditions at a geographic coordinate and / or route segment. The geographic coordinate and / or values ​​reflected by the environmental conditions may be communicated as a congestion signal 241 to the system 100.

[0071] As an addition or variation, the 244 regional monitoring component can repeatedly sample service provider availability in a given geographic region. In one example, service provider availability may be based, at least in part, on multiple service providers that are (or will be within a given time period) available to provide transportation services in a given sub-region. As an addition or variation, service provider availability may also be based on multiple requesters (or expected requesters) within the same duration. The 244 regional monitoring component can determine a service availability value, corresponding to a time value or weight that affects time parameters, such as the expected duration to select a service provider and / or the travel time for the selected service provider to reach the service departure location.The 244 regional monitoring component can communicate the... Petition 870200030091, dated 05 / 03 / 2020, page 56 / 102 52 / 72 service availability value as the availability signal 243.

[0072] Some examples provide that regional monitoring component 244 communicates the respective congestion and availability signals 241, 243 in response to the determination that environmental conditions are present in a given area that deviate from an expected or standard measure of the condition by more than a designated threshold amount. For example, regional monitoring component 244 may assign standard travel times to road segments based on observed or model traffic patterns. As such, regional monitoring component 244 may take into account normal or expected congestion at specific time intervals. In this example, regional monitoring component 244 may generate congestion signal 241 for a corresponding set of geographic coordinates or region in response to the determination of congestion significantly different from what is expected.For example, the regional monitoring component may generate congestion signal 241 for a specific location or sub-region when observed congestion alters a vehicle's travel time through the route by more than 2 minutes.

[0073] In variations, system 100 can trigger the Petition 870200030091, dated 05 / 03 / 2020, page 57 / 102 53 / 72 regional monitoring component 244 to generate the respective congestion and / or availability signals 241, 243. For example, system 100 can repeatedly query regional monitoring component 244 for congestion and / or availability signals 241, 243 in order to determine scheduled service requests from a given number of users that may be affected by environmental conditions.

[0074] In some examples, system 100 may implement programmatic processes to manage, or otherwise act upon, planned service request entries from the service request queue 255 for individual users. Depending on the implementation, different types of actions 257 may be performed by system 100 in a time interval immediately preceding a service request time for a scheduled user transportation event. In some examples, system 100 may perform different actions for different types of scheduled transportation events. For example, a routine event (e.g., user traveling to work) may receive one type of action (e.g., notification), while a booking event (e.g., user going to a show or dinner) may cause system 100 to implement a different type of managing action.

[0075] In one implementation, system 100 can Petition 870200030091, dated 05 / 03 / 2020, pp. 58 / 102 54 / 72 perform action 257 of sending a notification 261 to the requester that identifies information about a user's scheduled service request. Notification 261 can be communicated through, for example, the service application 216 (via the requester interface 210), a messaging application, and / or a calendar service or application (e.g., residing on the mobile device 202). Notification 261 itself may include separate timing parameters to provide the user with waiting time for the notification to run and for the scheduled service request to be made at the appropriate service request time indicated in the corresponding scheduled event record 102. Depending on the user's preference, a user may receive multiple notifications at different times, up to the time of the service request.In addition, in some variations, one or more notification(s) 261 may be triggered by monitoring user activity data 211 in search of predetermined markers (which may be stored as part of the user profile).

[0076] For example, based on the user's profile or preference, the user may receive an initial notification of a scheduled service request to transport them to work when the user is deemed awake. To determine when the user is awake, the system 100 may monitor user activity data 211, such as Petition 870200030091, dated 05 / 03 / 2020, pages 59 / 102 55 / 72 as motion sensors that indicate when the mobile device was first moved in the morning, or when alarm notifications indicate that the user's alarm clock has rung.

[0077] As an addition or variation, system 100 may generate a set of configuration parameters 259 that configure the user interface component 234 of the service application 216, running on the user's mobile device 202. The configuration parameters 259 for a specific scheduled transport event may be active for a defined period of time (e.g., one hour) before the event's service request time. The duration for which the configuration parameters 259 are active may be based, for example, on user preference and / or the type of event.

[0078] In one implementation, configuration parameters 259 include configuring an application resource 235 of the user interface component 234 to appear for a time interval prior to the service request time of the corresponding planned transport event. The application resource 235 can be configured to associate service parameters 205 of a service request with information from the corresponding planned event record 102 of the planned event. Thus, configuration parameters 259 can configure the resource of Petition 870200030091, dated 05 / 03 / 2020, pages 60 / 102 56 / 72 application 235 to use the event location as one of the service parameters 205 for the corresponding service request 201. The application resource 235 can persist in, for example, a home interface, calendar interface, or service application request interface 216. As an addition or variation, the application resource 235 can include linked resources in other applications. For example, the application resource 235 can be selected from the service request interface of application 216 to transmit a service request 201 to service 200, while a separate calendar application running on the user's mobile device can also include a shortcut resource that links to the application resource 235.

[0079] Furthermore, in other variations, the application feature may be dynamic in appearance, to indicate information about the scheduled event, including a period of time remaining until the service request time and / or the event departure time.

[0080] As an addition or variation, system 100 can manage the scheduled service request by making service request 201 on behalf of the user. In one example, service 200 can deploy a trigger or other programmatic mechanism residing in service application 216 to make service request 201 at the service's scheduled time. Petition 870200030091, dated 05 / 03 / 2020, pages 61 / 102 57 / 72 indicated by scheduled event record 102 of the scheduled service request. In some variations, service 200 may use a server or agent or network-side component to generate service request 201 on behalf of the user.

[0081] FIG. 2B is a block diagram representation of an application resource, according to one or more example(s). According to some examples, service application 216 may provide a set of one or more application resource(s) 235 on a given interface when service application 216 is running on the requester's mobile device 202. Each of the application resources 235 may be selectable to trigger the requester's mobile device 202 (or service application 216) to transmit or initiate a service request 201, with one or more service request parameter(s) 205 that is / are determined by the planned service request event log 102.

[0082] According to some examples, application resource 235 may include a graphic element 282, one or more activation triggers 284, and a service parameter integration 286. According to examples, application resource 235 may be activated by activation triggers 284 during a time interval that may be defined by configuration parameters 259, as determined by Petition 870200030091, dated 05 / 03 / 2020, pages 62 / 102 58 / 72 system 100. For example, configuration parameters 259 can designate a start time and an end time for when application feature 235 should be active. When activated, application feature 235 can transmit information about a corresponding event. Application feature 235 can also display information that is indicative of a time when the application feature should be used by the user to make a transportation request. In this way, the time window in which application feature 235 is active (e.g., 15 minutes, 2 hours) can be based on configuration parameters 259.

[0083] The graphic element 282 of the application resource 235 may include image data, such as an iconic image or a dynamic set of images, that indicate or provide information about an event of a scheduled service request. In some examples, the graphic element 282 may convey an action that the user must perform to ensure punctuality in relation to the user being able to use the transportation service to arrive on time at a corresponding event. In variations, the appearance or visual state of the graphic element 282 may also be based on a remaining duration during which the application resource 235 must remain active in a service application interface 216. For example, the application resource 235 may include text content, or symbolic or iconic content, corresponding Petition 870200030091, dated 05 / 03 / 2020, pages 63 / 102 59 / 72 indicates when the transportation service should be requested to allow the user to arrive at a specific location or event on time (e.g., the time the user must depart for the airport). The appearance of graphic element 282 can also be dynamic to reflect, for example, a proximity in time when the user must make the service request (e.g., selecting application feature 235).

[0084] Service parameter integration 286 can use metadata fields from event log 102 of the scheduled response trigger to generate service request 201. Event log 102 can be structured to have a common format, to facilitate the integration of event information from various sources (e.g., calendar or user's online account) into a service request 201 structure.

[0085] FIG. 3 illustrates an example of a method for scheduling service requests for a user's planned events and activities. A method as described in an example in FIG. 3 can be implemented using one or more component(s) of a system as described in examples in FIG. 1, FIG. 2A, and FIG. 2B. Therefore, reference can be made to elements of FIG. 1, FIG. 2A, and FIG. 2B to illustrate a suitable component for performing a step or substep described herein. Petition 870200030091, dated 05 / 03 / 2020, pages 64 / 102 60 / 72 invention.

[0086] With reference to an example in FIG. 3, system 100 monitors a user’s computing resources to identify indicators for the user’s planned events (310). In some examples, system 100 performs the monitoring by communicating with the user’s activity monitor 110. The user’s computing resources may include, for example, the user’s mobile device and / or an online account or a set of online accounts for the user. System 100 may interact with a user’s mobile device to access, for example, local data sources residing on the user’s mobile device 202. For example, the requester service application 216 running on the user’s mobile device 202 may be instructed to access a calendar application to identify upcoming events that may recently be scheduled by the user.As an addition or variation, System 100 can access information provided by one or more of the user's online accounts (e.g., online calendar, social media feed, email provider, booking account, ticket purchase account, etc.). Furthermore, System 100 can be implemented to accept input regarding users' future events through alternative forms of manual input.

[0087] System 100 can determine an event or a Petition 870200030091, dated 05 / 03 / 2020, pages 65 / 102 61 / 72 planned user activity from monitoring user computing resources (320). In some examples, the planned user event is determined as a transport event. In some examples, the determination of transport events from user activity and event information may be based on the implementation of a rules mechanism. As an addition or variation, the determination of transport events from user activity and event information may include creating a user activity profile using, for example, user activity data 211 generated from the user's mobile device, identifying selected types of online activities (e.g., transactions or transactions from specific websites indicating the purchase of goods related to the event (e.g., concert)).

[0088] According to some examples, system 100 determines a set of service parameters for a planned or scheduled user event (330). In one implementation, system 100 implements programmatic processes to analyze information and content from a disparate dataset that includes records retrieved from online logs and data items generated from user activity data (e.g., geographic coordinates and / or sensor data transmitted from the user's mobile device). In one implementation, the records of Petition 870200030091, dated 05 / 03 / 2020, pages 66 / 102 62 / 72 events 102 are generated and structured to include fields that match the service request parameters for a transport request (e.g., event location, event departure time, transport type). System 100 implements processes to analyze detected events and activity data into tokens and information items that match the fields of the corresponding event log 102. Once detected, the event log 102 fields can be populated with corresponding metadata, determined from the analyzed information and detected information items.

[0089] In some variations, the system generates event logs as part of a process to determine the user's planned event or activity. System 100 can process event logs and information to populate the event log fields 102, which in turn provides a uniform and easily formatted data structure that allows for analysis and subsequent use of the identified event information.

[0090] In some examples, system 100 (or service 200) may receive a QR code input (or other form of encoded input), initiated by the user operating, for example, a mobile device. In these examples, the QR code may identify a purchased item. System 100 may analyze the information of the purchased item to determine a Petition 870200030091, dated 05 / 03 / 2020, pages 67 / 102 63 / 72 event.

[0091] System 100 can schedule a service request for a planned user activity (340). In some examples, System 100 generates a service request queue 155, corresponding to a set of scheduled service requests that must be acted upon by System 100. When determining scheduled service requests, System 100 can determine a service travel time (342) and a service provider arrival time (344). The determination of the service travel time can be monitored and updated based on, for example, the user's current location. Additionally, the service travel time can be updated by monitoring environmental conditions, such as traffic congestion in a relevant geographic area of ​​the service request.

[0092] Determining the service provider's arrival time may be based on factors such as determining the number of service requesters and / or service providers in the relevant geographic area of ​​the service request. In some variations, determining the service provider's arrival time may also be based on the service status of detected service providers (e.g., whether the service provider is available, whether the service provider is near the destination and will be available, etc.). In variations, the Petition 870200030091, dated 05 / 03 / 2020, pages 68 / 102 64 / 72 The availability of the service provider may also depend in part on the number of requesters, such as the number of users with open service requests (e.g., unmatched), and / or the number of users performing an action indicative of an imminent service request (e.g., initiating the service requester's 216 application). Determining the service provider's arrival time may also take into account factors that may impede overall transit time, such as traffic.

[0093] In some examples, system 100 can modify the scheduled service request based on certain user activity. For example, system 100 can monitor the set of computing resources to determine user activity in a time interval prior to the scheduled time of the original service request. User activity can be monitored, for example, by obtaining location information from the user's mobile device (indicating the user's current location), obtaining sensor information (e.g., motion data to indicate if the user is moving), application data from the user's data (e.g., detecting an application alert, etc.). The monitored activity can be extended to multiple user devices, such as the user's mobile device 92 and / or smartwatch 94. A Petition 870200030091, dated 05 / 03 / 2020, pages 69 / 102 65 / 72 Scheduled service requests can be modified, for example, by changing the time of the scheduled service request and / or the service departure location, based on a current or predicted user location. Additionally, monitoring and modification can be repeated throughout the time interval until the scheduled service request is made.

[0094] In some variations, system 100 obtains (for example, through service 200) real-time (or near real-time) information to determine the service schedule and / or the arrival time of the service provider. In variations, system 100 may use a modeled determination, based, for example, on historical data that is specific to geographic location, time of day, day of the week, and other contextual information.

[0095] According to examples, system 100 performs an action on behalf of the user regarding the start of the service request at a scheduled time (350). In one example, the action performed by system 100 is to send a notification to the user about the planned service request. The notification can be transmitted through, for example, the requester's service application 216, or through an alternative means of transport. In some examples, the timing (i.e., when the notification is sent) of the notification may be based on the determined time of the Petition 870200030091, dated 05 / 03 / 2020, pages 70 / 102 66 / 72 service request for the planned service request. Additionally, the notification content can be dynamically determined. For example, the notification can identify a remaining time until the planned service request is to be initiated.

[0096] As another example, the action performed by system 100 includes configuring one or more selectable application resource(s) 235 (for example, see FIG. 2B) to appear during a time interval preceding a recommended service request time. The application resource 235 can be associated with service parameters, so that selecting the application resource causes the generation of a service request to transport the user to the event location.

[0097] Furthermore, as another example, system 100 can automatically request transportation service at the time of the service request, using service parameters identified from the corresponding event log 102. The automation of the service request can be based, for example, on a user preference or setting.

[0098] FIG. 4 is a block diagram illustrating a computer system in which the embodiments described in the present invention can be implemented. A computer system 400 can be implemented in, for example, a Petition 870200030091, dated 05 / 03 / 2020, pp. 71 / 102 67 / 72 server or combination of servers. For example, computer system 400 can be implemented as part of a networked computer system for scheduling service requests, as described in an example in FIG. 1. Computer system 400 can be implemented as part of a network service to allow users to schedule service requests, as described in an example in FIG. 2A and FIG. 2B. In the context of FIG. 1, FIG. 2A and FIG. 2B, some or all of the functionality described in system 100 and / or service 200 can be implemented using computer system 400. Similarly, a method such as that described in an example in FIG. 3 can also be implemented using computer system 400.

[0099] In one implementation, the computer system 400 includes processing resources 410, memory resources 420 (e.g., read-only memory (ROM) or random-access memory (RAM)), a storage device 440, and a communication interface 450. The computer system 400 includes at least one processor 410 to process information (including temporary variable storage) and execute instructions stored in memory resources 420. The computer system 400 may also include additional storage devices to store static information and instructions for the processor 410. A storage device 440, such Petition 870200030091, dated 05 / 03 / 2020, pp. 72 / 102 68 / 72, like a magnetic disk or optical disk, is shown to store information and instructions.

[00100] The communication interface 450 allows the computer system 400 to communicate with one or more networks 452 (e.g., cellular network) through the use of the network link (wireless or wired). Using the network link, the computer system 400 can communicate with one or more computing device(s) and one or more server(s). According to examples, the computer system 400 can execute instructions to allow the scheduling of service requests for planned events (shown as “service scheduling instructions 442”). The service scheduling instructions 442 can be stored in memory 420 and may include, for example, processes to implement the service scheduling system 100 and variations thereof, as described in an example in FIG. 1, FIG. 2A, and FIG. 2B.

[00101] The examples described in the present invention relate to the use of computer system 400 to implement the techniques described in the present invention. According to one aspect, the techniques are performed by computer system 400 in response to processor 410 executing one or more sequence(s) of one or more instruction(s) contained in memory resources 420. Such instructions can be read from memory resources 420. Petition 870200030091, dated 05 / 03 / 2020, pp. 73 / 102 69 / 72 from another machine-readable medium, such as storage device 440. Execution of the instruction sequences contained in memory resources 420 can cause processor 410 to perform the process steps described in the present invention. In alternative implementations, wired circuits can be used in place of or in combination with software instructions to implement the examples described in the present invention. Thus, the examples described are not limited to any specific combination of hardware and software circuits.

[00102] FIG. 5 is a block diagram illustrating a mobile device in which the examples described in this invention can be implemented. In one example, a mobile device 500 may include a roaming device capable of wireless communications (e.g., a cellular device capable of telephony, messaging, and data services). Examples of such devices include smartphones, tablets (and phablets), and other portable or mobile devices capable of cellular communications or wireless fidelity (Wi-Fi).

[00103] With reference to an example in FIG. 5, a mobile device 500 includes a processor 510, memory resources 520, a display device 530 (for example, such as a touch-sensitive display device), one or more communication subsystems 540 (including Petition 870200030091, dated 05 / 03 / 2020, pp. 74 / 102 70 / 72 wireless communication subsystems), input mechanisms 550 (for example, an input mechanism may include or be part of the touch-sensitive display device) and one or more sensor(s) (for example, a satellite receiver component, an accelerometer, one or more camera(s), etc.) 560. In one example, at least one of the communication subsystems 540 sends and receives cellular data through data channels and voice channels.

[00104] Processor 510 can provide a variety of content to the display 530 by executing instructions and / or applications that are stored in memory resources 520. For example, processor 510 is configured with software and / or other logic to perform one or more processes, steps, and other functions, including executing (i) service application instructions 516 to implement, for example, service application 216 of FIG. 2A, and (ii) application configuration instructions 525, to configure an appearance or functionality of an application resource 235 or application interface, as described, for example, in FIG. 2A and FIG. 2B. Additionally, application instructions 516 can be used to implement a method as described in an example in FIG. 2.

[00105] Although the embodiments are described in detail in the present invention with reference to the accompanying drawings, it should be understood that the invention is not limited to Petition 870200030091, dated 05 / 03 / 2020, pages 75 / 102 71 / 72 these precise embodiments. As such, many modifications and variations will be evident to those skilled in the art. Consequently, it is intended that the scope of the invention be defined by the following claims and their equivalents. Furthermore, it is contemplated that a specific feature described individually or as part of an embodiment may be combined with other features described individually, or parts of other embodiments, even if the other features and embodiments do not mention the specific feature. Thus, the absence of described combinations should not prevent the inventor from claiming rights to such combinations.

[00106] It is contemplated that the embodiments described herein extend to individual elements and concepts described in this invention, independently of other concepts, ideas, or systems, as well as that the embodiments include combinations of elements described anywhere in this application. Although the embodiments are described in detail in the present invention with reference to the accompanying drawings, it should be understood that the invention is not limited to these precise embodiments. As such, many modifications and variations will be apparent to those skilled in the art. Consequently, it is intended that the scope of the invention is defined by the following claims and their equivalents. Furthermore, it is contemplated that a specific feature described individually or as part of an embodiment may be Petition 870200030091, dated 05 / 03 / 2020, pp. 76 / 102 72 / 72 combined with other individually described features, or parts of other embodiments, even if the other features and embodiments do not mention the specific characteristic. Thus, the absence of a description of combinations should not prevent the inventor from claiming rights to these combinations. Petition 870200030091, dated 05 / 03 / 2020, pages 77 / 102

Claims

1 / 14 CLAIMS 1. A computer system characterized in that it comprises: a set of memory resources for storing a set of instructions; one or more processor(s) for accessing the instruction set; wherein the instructions, when executed by one or more processor(s), cause the computer system to perform operations that include: monitoring a set of a user's computing resources; determining, from the monitoring of the set of computing resources, a scheduled user event; scheduling a service request for the scheduled user event, wherein scheduling the service request includes: (a) determining an event location and an event departure time;(b) determine a service request time prior to the event departure time, based at least in part on (i) an expected duration to match a service provider with the service request and (ii) an expected duration for a matching service provider to travel to a user's anticipated location at the service request time; and generate the service request for the user's scheduled event during the service request time.

2. Computer system according to claim 1, characterized in that the scheduling of the service request includes determining at least one of (i) a transit time to transport the user to the event location or (ii) an arrival time of the service provider to transport the user to the event location.

3. A computer system according to claim 1, characterized in that one or more processor(s) execute(s) the instruction set to cause the computer system to perform additional operations that include: determining, from monitoring the set of computing resources, the user's activity in a time interval prior to the service request; modifying the scheduled service request based on the determined user activity; and performing an action on behalf of the user with respect to the start of the service request, as modified during the time of the service request.

4. Computer system according to claim 3, characterized in that the modification of the scheduled service request includes: determining, from monitoring the set of computing resources, a current location of the user during a time interval preceding the user's scheduled event; and updating the service request time based, at least in part, on the user's current location during the time interval preceding the user's scheduled event.

5. Computer system according to claim 3, characterized in that the modification of the scheduled service request includes: determining, from monitoring the region, a set of traffic factors during a time interval prior to the user's scheduled event; and updating the service request time based, at least in part, on the set of traffic factors.

6. Computer system according to claim 5, characterized in that the set of transit factors is based, at least in part, on (i) a respective location of multiple service providers, and / or (ii) an availability of each of the multiple service providers during the time interval prior to the user's scheduled event.

7. Computer system, according to Petition 870250103823, dated 11 / 13 / 2025, page 15 / 40 4 / 14 claim 3, characterized in that performing the action includes generating an application resource for a service request interface of a service application running on a user's mobile device, the application resource being selectable by the user to automatically make the service request using multiple service parameters, including the specified set of service parameters.

8. Computer system according to claim 1, characterized in that the service request is generated automatically during the service request hours.

9. Computer system according to claim 1, characterized in that the monitoring of the set of computing resources includes instructing a service application running on a user's mobile device to acquire device information from a corresponding resource of the mobile device and send the device information to the computer system on one or more networks.

10. Computer system according to claim 9, characterized in that the device information includes at least one of (i) a current location of the mobile device, acquired from a satellite location receiver of the mobile device, (ii) sensor data obtained from a motion sensor of the mobile device, the sensor data indicating the movement of the user's mobile device, and / or (iii) a programmatic event generated by a second application running on the mobile device.

11. Computer system according to claim 10, characterized in that the device information includes sensor data obtained from a motion sensor of the mobile device, the sensor data indicating the movement of the user's mobile device.

12. Computer system according to claim 1, characterized in that the monitoring of the set of computing resources includes the monitoring of each of the user's mobile devices and at least one of the user's second devices or an online resource of the user.

13. Computer system according to claim 3, characterized in that the modification of the scheduled service request includes modifying one or more of the service request's starting locations or the service request's time before generating the service request at the service request time.

14. Method for operating a computer system, Petition 870250103823, dated 11 / 13 / 2025, p.17 / 40 6 / 14 method being implemented by one or more processor(s), characterized in that it comprises: monitoring a set of computing resources of a user; determining, from the monitoring of the set of computing resources, a scheduled event of the user; scheduling a service request for the scheduled event of the user, wherein scheduling the service request includes: (a) determining an event location and an event departure time; (b) determining a service request time prior to the event departure time, based at least in part on (i) an expected time duration to match a service provider with the service request and (ii) an expected duration for a matching service provider to travel to a predicted location of the user at the time of the service request; and generating the service request for the scheduled event of the user during the time of the service request.

15. Non-transient computer-readable medium characterized in that it stores instructions which, when executed by one or more processor(s) of a computer system, cause the computer system to perform operations that include: Petition 870250103823, dated 11 / 13 / 2025, p.18 / 40 7 / 14 monitor a set of a user's computing resources; determine, from monitoring the set of computing resources, a scheduled user event; schedule a service request for the scheduled user event, wherein scheduling the service request includes: (a) determining an event location and an event departure time; (b) determining a service request time prior to the event departure time, based at least in part on (i) an expected duration to match a service provider with the service request and (ii) an expected duration for a matching service provider to travel to a predicted user location at the service request time; and generate the service request for the scheduled user event during the service request time.

16. A computer system characterized in that it comprises: a set of memory resources for storing a set of instructions; one or more processors for accessing the instruction set; wherein the instruction set, when executed by Petition 870250103823, dated 11 / 13 / 2025, page 19 / 40 8 / 14 one or more processors, causes the computer system to perform operations that include: monitoring a set of a user's computing resources; determining, from the monitoring of the set of computing resources, a scheduled user event, the scheduled user event being associated with an event location and an event start time; triggering a service request for the scheduled user event, wherein triggering the service request includes: (a) monitoring user activity data to detect a predetermined marker;(b) upon detecting the predetermined marker, determine a service request time prior to the event start time based, at least in part, on (i) an expected duration of time for a service provider to match the service request, and (ii) an expected duration for a matching service provider to travel to a predicted user location at the time of the service request; and generate the service request for the scheduled user event based on the service request time.

17. Computer system according to claim 16, characterized in that (i) the predetermined marker is stored as part of a user profile for the user, (ii) the user's activity data is generated from the user's computing resource set, and (iii) the user's activity data includes motion sensor data and / or alarm notification data.

18. Computer system according to claim 16, characterized in that determining the service request time includes determining at least one of (i) a transit time to transport the user to the event location or (ii) an arrival time of the service provider to transport the user to the event location.

19. Method for operating a computer system, the method being implemented by one or more processors and characterized in that it comprises: monitoring a set of computing resources of a user; determining, from the monitoring of the set of computing resources, a scheduled user event, the scheduled user event being associated with an event location and an event start time; triggering a service request for the scheduled user event, wherein triggering the service request includes: Petition 870250103823, dated 11 / 13 / 2025, p.21 / 40 10 / 14 (a) monitor user activity data to detect a predetermined marker; (b) upon detecting the predetermined marker, determine a service request time prior to the event start time based at least in part on (i) an expected time duration to match a service provider to the service request, and (ii) an expected duration for a matching service provider to travel to a predicted user location at the time of the service request; and generate the service request for the scheduled user event based on the service request time.

20. Non-transient computer-readable medium characterized in that it stores instructions which, when executed by one or more processors of a computer system, cause the computer system to perform operations which include: monitoring a set of a user's computing resources; determining, from the monitoring of the set of computing resources, a scheduled user event, the scheduled user event being associated with an event location and an event start time; triggering a service request for the scheduled user event, wherein triggering the service request Petition 870250103823, of 11 / 13 / 2025, p.22 / 40 11 / 14 includes: (a) monitoring user activity data to detect a predetermined marker; (b) upon detecting the predetermined marker, determining a service request time prior to the event start time based at least in part on (i) an expected time duration to match a service provider to the service request, and (ii) an expected duration for a matching service provider to travel to a predicted user location at the time of the service request; and generating the service request for the scheduled user event based on the service request time.

21. A computer system characterized by the fact that it comprises: a set of memory resources for storing a set of instructions; one or more processors for accessing the instruction set; wherein the instructions, when executed by one or more processors, cause the computer system to perform operations that include: monitoring a set of a user's computing resources; determining, from the monitoring of the set of instructions, the purpose of the instruction set.23 / 40 12 / 14 computing resources, a scheduled user event; and scheduling or triggering a service request for the scheduled user event, wherein scheduling or triggering a service request includes: before a time specified prior to the user-scheduled event, monitoring the availability of transportation providers in the vicinity of the user's current location; determining a service request time for the user based on transportation provider availability; and generating the service request for the user-scheduled event based on the service request time.

22. A method for operating a computer system, the method being implemented by one or more processors and characterized in that it: monitors a set of computing resources of a user; determines, from the monitoring of the set of computing resources, a scheduled user event; and schedules or triggers a service request for the scheduled user event, wherein scheduling or triggering a service request includes: before a time specified prior to the user-scheduled event, monitoring the availability of transport providers in the vicinity of the user's current location; determining a service request time for the user based on the availability of the transport provider; and generating the service request for the user-scheduled event based on the service request time.

23. Non-transient computer-readable medium characterized in that it stores instructions that, when executed by one or more processors of a computer system, cause the computer system to perform operations that include: monitoring a set of a user's computing resources; determining, from the monitoring of the set of computing resources, a scheduled user event; and scheduling or triggering a service request for the scheduled user event, wherein scheduling or triggering the service request includes: before a time specified prior to the user-scheduled event, monitoring the availability of transport providers in the vicinity of the user's current location; determining a service request time for the user based on the availability of the provider of Petition 870250103823, of 11 / 13 / 2025, p.25 / 40 14 / 14 transportation; and generate the service request for the event scheduled by the user based on the service request time. Petition 870250103823, dated 11 / 13 / 2025, page 26 / 40.

Images