Patent ID: 12261924

DETAILED DESCRIPTION

Examples provide a computer system and method to schedule service requests for planned events and activities of the user. According to some examples, a computer system monitors a set of computing resources of a user 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 location. Additionally, the computer system may perform an action on behalf of the user with respect to initiating the service request at a scheduled time.

A common objective of on-demand services is to utilize leveraged personal mobile technology to bring convenience to users. For example, urban commuters can eliminate parking by using on-demand transportation services. On-demand transportation services have also implemented technological solutions to provide an easier and more convenient alternative to the conventional approach of hailing transport. In contrast to conventional transport services, on-demand transportation services (i) enable users to interact with their mobile devices to generate service requests, and (ii) match service requests with available service providers who are nearby, so that a service requester can meet a service provider at a location of the requester's choosing. Among other benefits, on-demand transportation services eliminated the manual and uncertain effort that was often required for users to obtain transport service. By leveraging location-aware capabilities of mobile devices, on-demand transportation services can track requesters and service providers to facilitate the one or more parties in meeting at a service start location, as well as to track trips, and to determine fares after completion of trips.

In this context, examples recognize that some users have difficulty with respect to planning to use on-demand transport services for planned or scheduled activities. Some users neglect to take into account, 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. Still further, the availability of service providers can be fluid, meaning that sudden shortages of service providers may occur. Additionally, users do not always track the travel time for receiving the transport service to a destination location.

In this context, examples provide a system that schedules transport service requests for users based on knowledge or information as to when the user intends to arrive at a particular location. In this way, examples such as described can calculate the appropriate service request time, to account for factors such as congestion and service provider availability. By determining when the user should make a transport service request, examples avoid situations where the user 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 transport service requests reduces the user's device time, thus preserving battery life and device use.

Moreover, examples provide for scheduled transport service requests to be dynamic, to reflect events or conditions that require, for example, the planned service request time to be changed. The determination of the service request times for planned service requests is thus dynamic, and subject to update based on, for example, the current location of the user, environmental conditions, information pertaining to the user leveraged from the user's other devices, and other factors which may be outside of the user's awareness.

As used herein, a client device, a driver device, and/or a computing device refer to devices corresponding to desktop computers, cellular devices or smartphones, personal digital assistants, wearable electronic devices, laptop computers, tablet devices, television (IP Television), etc., that can provide network connectivity and processing resources for communicating with the system over a network. A driver device can also correspond to custom hardware, in-vehicle devices, or on-board computers, etc. The client device and/or the driver device can also operate a designated application configured to communicate with the transport arrangement system.

While some examples described herein relate to transport services, the transport arrangement system can enable other on-demand location-based services (for example, a food truck service, a delivery service, an entertainment service) to be arranged between individuals and service providers. For example, a user can request an on-demand service, such as a delivery service (e.g., food delivery, messenger service, food truck service, or product shipping) or an entertainment service (e.g., mariachi band, string quartet) using the system, and the system can select a service provider, such as a driver, food provider, band, etc., to provide the on-demand service for the user.

One or more embodiments described herein provide that methods, techniques, and actions performed by a computing device are performed programmatically, or as a computer-implemented method. Programmatically, as used herein, means through the use of code or computer-executable instructions. These instructions can be stored in one or more memory resources of the computing device. A programmatically performed step may or may not be automatic.

One or more embodiments described herein can be implemented using programmatic modules, engines, or components. A programmatic module, engine, or component can include a program, a sub-routine, a portion of a program, or a software component or a hardware component capable of performing one or more stated tasks or functions. As used herein, a module or component can exist on a hardware component independently of other modules or components. Alternatively, a module or component can be a shared element or process of other modules, programs or machines.

Some embodiments described herein can generally require the use of computing devices, including processing and memory resources. For example, one or more embodiments described herein may be implemented, in whole or in part, on computing devices such as servers, desktop computers, cellular or smartphones, tablets, wearable electronic devices, laptop computers, printers, digital picture frames, network equipment (e.g., routers) and tablet devices. Memory, processing, and network resources may all be used in connection with the establishment, use, or performance of any embodiment described herein (including with the performance of any method or with the implementation of any system).

Furthermore, one or more embodiments described herein may be implemented through the use of instructions that are executable by one or more processors. These instructions may be carried on a computer-readable medium. Machines shown or described with figures below provide examples of processing resources and computer-readable mediums on which instructions for implementing embodiments of the invention can 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 holding data and instructions. Examples of computer-readable mediums include permanent memory storage devices, such as hard drives on personal computers or servers. Other examples of computer storage mediums include portable storage units, such as CD or DVD units, flash memory (such as carried on smartphones, multifunctional 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 mediums. Additionally, embodiments may be implemented in the form of computer-programs, or a computer usable carrier medium capable of carrying such a program.

FIG.1illustrates an example system to schedule service requests for individual users. In particular, a service scheduling system100can be provided to facilitate a user in making service requests that result in the user's timely arrival at a scheduled event. Moreover, the system100can update planned service requests based on factors such as user activity, environmental conditions, information pertaining to the user leveraged from the user's other devices, and other events.

According to some examples, the system100is implemented as a network service. Accordingly, the system100may be implemented on, for example, one or more servers or other network computer machines. The system100may be implemented as part of a transport arrangement service, which operates to match incoming transport service requests from requester devices with service providers who are available and in proximity to the start location of the requester transport request. In variations, the system100can be implemented as a separate or standalone service that can interface with a transportation arrangement service or user device (e.g., via a service application for the network service). Still further, in other variations, the system100can be implemented at least in part on individual user devices. For example, functionality described with the system100may be implemented as part of a service application that runs on the mobile devices of individual users.

In more detail, the system100may include a service request scheduler120and a service request handler150. The service request scheduler120operates to schedule service requests for planned activities of the user. The service request handler150includes one or more programmatic processes that can be triggered to perform an action, or series of actions to facilitate the user, or otherwise act on behalf of the user, in making a timely transport service request for a scheduled event.

According to some examples, system100may include or interface with a user activity monitor110to determine user activity information111and scheduled event information113. The service request scheduler120may also access user profile information109to determine routine activities115of the user, such as a given user's normal commute from home to work, or from work to home. The service request scheduler120may process user activity information111provided by the user activity monitor110to identify planned user activities, including scheduled events (e.g., concert, party, air trip, etc.). The service request scheduler120may schedule new transport requests for planned user events. Additionally, the service request scheduler120may process respective user activity information111to change or update a scheduled transport request of the user. For example, the service request scheduler120may delay a service request when it retrieves user activity information111that signals the user will not be available for the scheduled service time. The user activity information111in this context may be the user's location or information leveraged from the user's linked devices (e.g., smartwatch).

The user activity monitor110may include an online event monitor112that (with user permission) can access individual user's linked online accounts, such as an online calendar account, a social network account, an email store, a reservation account, etc. The online event monitor112may identify scheduled event information113from the online resources of the user, which the service request scheduler120may receive and process to generate a corresponding event record102.

As an addition or variation, the user activity monitor110includes one or more device monitors114that monitor one or multiple computing devices (e.g., mobile device92, smart watch94, etc.) of the user to obtain user activity information111. The user activity information111may include or correspond to contextual information for updating scheduled event record102determined by the service request scheduler120. For example, the user activity monitor110may include processes to monitor a user's mobile device92(e.g., multifunctional wireless telephony/messaging device, tablet device) or multiple mobile devices concurrently (e.g., mobile device92and/or smartwatch94or other wearable electronic device). The user activity information111may include, for example, a user's location information (e.g., such as provided from a satellite location receiver), movement data (e.g., such as provided from an accelerometer and/or gyroscope), device usage data (e.g., usage correlating to execution of different applications on a user's mobile device), and/or activities performed through specific applications (e.g., online shopping application).

In some variations, the profiler118may access a user account data store103to determine, for example, the user's service request history. From the user's request history, the profiler118may determine the destinations for common, favorite or recent service requests. In some variations, the profiler118may also process the user activity information111to obtain, for example, contextual information that identifies routine activities115of the user which may require transport. For example, the profiler118may identify a common destination for the user (e.g., user's work address) based on the user's location during the work day, even though the user's work address is not one of the user's favorite or recent destinations through the transport service (e.g., the user may normally drive himself to work). The profiler118may store determined routine activities115as part of the user profile109in the user profile store105. In this way, the profiler118may determine an activity profile of the user.

According to some examples, the service request scheduler120includes an event determination component122and a service timing component124. The event determination component122may process user activity information111and the scheduled event information113, as provided by the user activity monitor110, in order to determine a service request queue155of planned service requests for the user over an upcoming time period. The service request queue155may include service requests for those events which are determined to be transport events (e.g., events for which the user will likely request transport). In some examples, the planned service requests may be determined for routine activities115(e.g., user going to work from home, user going home from work), scheduled event information113(e.g., user purchases theatre tickets for a particular day and time) and/or detected activities determined from user activity information.

In one implementation, the event determination component122implements a rules engine to determine when a detected activity, calendar event, or routine activity is to be treated as a scheduled event record102. A scheduled event record102may identify events (or planned activities) of the user which correspond to events which the user may wish to attend, and possibly travel to. In some variations, the event determination component122generates an event record102for each activity or event that satisfies a confidence threshold (e.g., probability determination) as to being a transport event (or an event which the user will likely wish to receive a transport service for in connection with a corresponding event location). In one implementation, the event determination component122may generate the event record102using a normalized or common format. The event determination component122may populate the event record102with metadata that identifies (i) a start time parameter104, corresponding to a start time (or window of time) for the user to arrive at the location of the activity, and (ii) an event location parameter106(e.g., street address or geographic coordinate of activity). The scheduled event record102may also include a service start location parameter108, corresponding to a predicted or determined start location for the user in a duration immediately preceding the event start time. In some examples, the service start location108may be predicted based on user activity and/or an activity profile of the user. In variations, the service start location parameter108may be dynamic, in that the start location may correspond to the user's current location at the service request time. Given the service request time may depend on the user's current location, examples provide that the service request scheduler120monitors the user's activities (via the user activity monitor110) to update the parameters of the event record102. Each event record102that is generated by the event determination component122may also be associated with an identifier for the user. As described below, the user's service request queue155may be determined over a given time interval (e.g., every 4-hour time interval during the day) from scheduled event records102that are stored with the event data store125.

In some examples, the event determination component122may generate scheduled event records102as a recommended set of scheduled service requests. The service request scheduler120may communicate a recommendation129that identifies information from a scheduled event record102(or set thereof). The recommendation129may be provided for the user to confirm or verify as relating to a transport event, meaning the user's confirmation identifies an event for which the user may wish to receive a transportation service. For example, the service request scheduler120may send a confirmation notification151(e.g., an in-app notification, a calendar update, etc.) to the user, identifying information from the scheduled event record102of the recommended set. In some variations, the confirmation notification151may prompt the user to respond and confirm (or discard) that the user intends to use a transport service in connection with an event identified in the scheduled event record102. If the user provides the confirmation input, then the scheduled event record102may be marked as a transport service event. Those event records102which are marked by confirmation or default as identifying transport service events may be made part of a user's service request queue155. Depending on implementation, events which are not confirmed or discarded may also be maintained in the event data store125. If the user provides a negative confirmation (e.g., discards the notification, declines the recommendation, etc.), the corresponding event record102may be removed from the event data store125.

In some examples, the event determination component122may format recommendations129to include pre-populated information that identifies the event (e.g., by descriptor, location, date and start time), an estimated service start time (e.g., pickup time), and selected or default service type. In some variations, recommendations129may be prioritized, with higher ranked determinations being presented more prominently to the user (e.g., on the user's mobile device92and/or smart watch94).

In some examples, the event determination component122may utilize a rules engine in order to determine which event records102signify transport service events. In some examples, the user's response to recommended event records102may be used to develop the user's profile, which may be stored in the user profile store105. For example, the event determination component122may 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 a week (e.g., Friday nights), or for certain locations (e.g., in an urban area). The event determination component122may also process determined events to cancel or modify planned service requests as needed. For example, the routine activities115(e.g., service request to transport user to work) may be canceled on a holiday, or when a calendar event indicates the user is out of town.

Still further, the event determination component122may include logic to keep or discard a scheduled event record102which receives no user response. The event determination component122may base the determination on, for example, previous user responses in confirming or discarding event records102. For example, the event determination component122may determine to keep or discard a given event record102based on the user's profile information109(as determined from the user profile store105), which may include an aggregation of past user interaction with confirmation notifications of the event determination component122. Based on past interactions, the event determination component122may determine the tendency or preference of the user to (i) confirm scheduled event records102which are of interest to the user as transport events, versus the tendency of the user to discard event records which are not of interest as transport events to the user, and/or (ii) accept or act on scheduled events which have not been confirmed. In such examples, the user's response to the confirmation notification151may be recorded with the user's profile store105. The user may also provide input to alter or modify the event record102, such as to specify a particular type of service (e.g., large vehicle) for the event and/or specify an additional start location (e.g., address of friend). Alterations or modifications to the event record102to specify a particular type of service may also be dynamically adjusted based on information leveraged from the user's linked apps (e.g., social media events indicating that user will be attending an event with a friend to generate an option for selecting an additional service location) or provided input (e.g., the user's number of checked bags may be obtained from a user's flight ticket information to indicate whether a larger vehicle is necessary for the user's service request).

In variations, the user's profile information109may also store settings, where the user may specify their preference for having scheduled event record102made part of the user's service request queue155. For example, the user may be able to select certain types of activities (e.g., activities generated on a particular on-line calendar or for a particular type of event) as becoming part of the user's service request queue155automatically, upon detection by the event determination component122.

The service timing component124may implement operations to determine service scheduling parameters123for individual event records102of the event data store125. For example, the service scheduling parameters123may correspond to (i) a service time to service the user to the event location from an expected or determined user location, and (ii) a service arrangement time, to select an available service provider for the user and to have the service provider arrive at the start location identified by the corresponding event record102. In determining the service scheduling parameters123, the service timing component124may utilize a service start location, as determined from, for example, the start location parameter108of the corresponding event record102, a current or recent location of the user, or an expected or planned location of the user (e.g., as determined from user profile information). In variations, the service timing component124determines relative information for updating an event record102that identifies an upcoming service request, based on user activity information111, as provided from the user activity monitor110. The user activity information111may identify, for example, the user's current location. Accordingly, the service timing component124may update a given event record102based in part on the current location of the user.

In some examples, the service timing component124may be triggered to update the service scheduling parameters123of a scheduled event record102by monitoring user activity and/or environmental conditions during a given time interval that precedes the determined start time of the corresponding event (e.g., preceding 2 or 4-hour interval before start time of activity). For a given event record102, the service timing component124determines scheduling parameters123that identify when a corresponding service request for the event record102should be made. The service timing component124may identify, from the scheduling parameters123, a service request time, corresponding to an interval of time preceding a corresponding event's start time, when the corresponding service request of a given record is timely, meaning the service request is not made too soon (so that the user does not depart too early for the event location) and not 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 start location to the event location, and (ii) a service provider arrival time, corresponding to the time interval marked by the arrival of the service provider, following a transmitted service request of the user. As described with examples, the service time may be subject to change, as factors such as congestion, roadwork and other types of conditions may cause delays or variations from a planned or normal trip time of a given route. Likewise, the service provider arrival time may also fluctuate based on the availability of the service providers and the respective proximity of available service providers to the service start location. For example, the availability of the service provider may fluctuate based on factors such as the location of available service providers and the number of requesters at a given time interval. As described in greater detail, some examples plan a service request for user to include a real-time determination for the arrival time of a matched service provider at the service start location, as well as the service time between the service start and event locations.

The service request scheduler120may also account for uncertainty in the location of the user at the time the service request is to be made for a given event record. In some examples, the service timing component124may utilize, for example, the user activity monitor110to repeatedly or continuously update the user's location for a given event record102, during a time interval preceding when a service request is to be made for a corresponding event. The service timing component124may update the corresponding scheduled event record102based on the current location (or service start location) of the user being determined or otherwise updated (e.g., such as based on the user's current location) in the time interval leading up to when the service request is made.

Accordingly, in a given time interval preceding a start time of a given event record102, the service timing component124may utilize the service time logic126to estimate the likely service time for a service provided to the user. The service time may be based at least in part on monitoring of the user's activity information111(e.g., current location), as well as environmental conditions, such as congestion and service provider availability (e.g., as determined by the regional monitoring service140, described below).

The service timing component124may also utilize service provider availability logic128to determine an expected time interval between when a given service provider is matched to the service request of the user, and the estimated service provider arrival time, marking when the service provider arrives at the service start location. In this way, the service timing component124may, for example, make separate determinations of (i) an expected time duration for matching a service provider from an available pool of service providers to a service request of a given event record102; and (ii) an expected duration (e.g., travel time) for the selected service provider to travel and meet the user at the service start location (e.g., as determined from the activity information111).

According to some examples, the system100communicates with the regional monitoring service140to receive environmental input parameters that may impact the service scheduling parameters123. By way of example, the regional monitoring service140may include interfaces to third-party information sources that include weather information, traffic reports, regional event information (e.g., concerts), as well as information about other environmental conditions that can impact service transport times and provider arrival times. By way of example, the regional monitoring service140may identify conditions which increase congestion, or otherwise reduce the travel speed of vehicles on the roadways near the service start or event locations. In some examples, the regional monitoring service140operates in connection with a transport arrangement service (e.g., seeFIG.2) to monitor position information (e.g., location and speed) of service provider vehicles in the vicinity of a service start location, event location or road network segment between the service start location and the event locations. Based on the monitoring, the regional monitoring service140can detect conditions of roadway congestion which may impact either the service providers arrival time or the service transport time of the service record102. By detecting conditions of roadway congestion and by monitoring location and speed of service provider vehicles, the regional monitoring service140may generate, for given intervals of time, congestion signal141to indicate a relative speed of service provider vehicles on the roadway in a region that includes the service start location and/or the event location.

In some examples, the service request scheduler120may communicate with the regional monitoring service140to detect, for example, a major accident that will significantly delay the travel time of the user. The service request scheduler120may change the service request time for the planned service request to accommodate the possibility of a lengthy commute.

Additionally, the regional monitoring service140may monitor for the availability of service providers. Depending on implementation, the availability of service providers may be based on, for example, one or more of the total number of service providers in the vicinity of the event start location, the total number of available service providers, the number of requesters in the vicinity of the service start location, and/or the vicinity of the service start location to an available provider. The regional monitoring service140may generate, for the given intervals of time, availability signal143, which may be indicative of a number of available service providers in a given time interval as compared to an expected or actual number of requesters.

In some examples, the service time logic126utilizes congestion signal141(as provided by the regional monitoring service140) that is specific to the event location, service start location, and/or route between service start and event location. In determining the service scheduling parameter123, the service provider availability logic128may utilize service provider availability signal143as determined from the regional monitoring service140. As an addition or variation, the service provider availability logic128may utilize historical information for determining the availability of service providers and/or time for service providers to arrive at the start location. In such examples, the historical information may be specific to the location, time day of week, time of day etc.

According to some examples, the congestion and/or availability signals141,143may be repeatedly determined and associated with geographic areas that encompass service start locations, event locations and routes between service start and event locations. The congestion and/or availability signals141,143may be associated with, for example, corresponding event records that are stored in event data store125. As the start time for given events approach, the service timing component124may utilize values of the congestion and/or availability signals141,143, in order to take into account for timing variances (e.g., delays) resulting from, for example, traffic congestion and/or lack of available of service providers.

In some variations, the event determination component122records the type or source of a determined event for individual event records102. The service request scheduler120may utilize or communicate with other types of monitors to update event records102, based on the type or source of the determined event. For example, the event determination component122may record a planned flight, and the service timing component124may utilize a flight tracker database (which may be provided by a third-party) to monitor for the departure time of the requester's flight. In this way, when a requester's flight is delayed, the service request queue155of the user is automatically updated to reflect the flight change.

The service request handler150may handle a service request queue155, identified from the event records102of the user which identify upcoming transport events for an upcoming time interval (e.g., 12 hours or a day). The service request queue155may be based on scheduled event records102which the given user has confirmed or not discarded. The service request handler150may implement one or more types of actions to handle individual entries of the user's service request queue155. In one implementation, the action(s) of the service request handler150is to notify the user at an appropriate time to initiate a transport service request. The service request handler150may, for example, initiate transmission of user a notification149(or a series of notifications) through a notification interface157that renders the notification using a service application running on a user's device. The notification149may provide the user with a recommendation to make a transport request at a given service request interval, as determined by the service timing component124. In variations, the service request handler150may utilize an alternative notification interface157to communicate the notification149as, for example, a Short Message Service (SMS) protocol. In variations, the notification interface157may enable other forms of notifications, such as by triggering the placement of a phone call (e.g., via the user's mobile device92) or alarm chime (e.g., via the user's smart watch103). The notification149itself may be selectively sent at a given time interval preceding the determined service request time. Additionally, the notification149may include content to indicate a time when the user should make the transport service request (e.g., “Request transport in 5 minutes (3:45 PM) to arrive at your event at 4:15.”).

As an addition or alternative, multiple notifications may be sent at different time intervals preceding 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 notifications, may be determined by a user profile. The user profile information109, for example, may indicate a preference of the user as to a number or frequency of notifications, as well as lead time preceding the service request time when individual notifications should be sent. The user profile information109may also specify notification preferences which are specific to a type of notification (e.g., when a user receives a notification that identifies the service request time for a routine destination such as the user's work address).

As an addition or variation, the service request handler150may schedule a service request action with a user's calendar application (e.g., running on a user's mobile device) or online calendar/scheduling service. The service request may be scheduled within, for example, a window of time during which the user should make the service request to arrive on time at a corresponding event of a given event record102. Thus, the service request action may be scheduled on the calendar at a different time than the event of the service planning record, in order to account for the service time and the service arrival time.

As an addition or variation, the service request handler150may generate or otherwise configure a user's requesting device to include an application feature that is selectable (e.g., selectable icon appearing on a touchscreen of a user device) to cause the user device to initiate the service request. In addition, the selection of the application feature by the user may cause the user's requesting device to transmit a complete service request, utilizing service parameters specified in the corresponding event record102(e.g., service start location, destination as event location).

Still further, in some variations, the service request handler150may automatically make the service request for the user at a determined service request time. For example, the service request handler150may automatically make a transport service request for the user when the corresponding event record102has been confirmed or verified by the user. As a variation, the service request handler150may make the transport 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 handler150before the service request time.

In some examples, the service request handler150can perform any one of multiple possible actions (such as described above) to handle planned service requests of the user's service request queue. The service request handler150may determine the action that is to be performed on behalf of the user, as well as parameters for performing the action (e.g., time when the action is to be performed) based on, for example, (i) whether the user has confirmed or verified the event record102as being related to a travel event, (ii) the type of event (e.g., routine) or scheduled activity, (iii) previous instances as to how the planned service request was handled, and/or (iv) preferences of the user. The user's profile information109may specify, for example, by settings or past behavior, the type of action the user prefers to occur for scheduled service events of the user. For example, the user's profile information may indicate one of multiple possible alternative actions that the service request handler150may perform, such as (i) automatically request transport service for the user at an appropriate time for an activity of a given event record102; or (ii) provide the user with a programmatic mechanism to trigger transmission of the service request at an appropriate time for the given event record102.

In some examples, the preferences of the user may be determined by monitoring the user's behavior in time intervals preceding scheduled events for which the user is to utilize a transport service. The profiler118may, for example, receive user activity information111from the user activity monitor110during the time interval preceding when the user makes a service request for a given event record102. The profiler118may observe instances when, for example, a notification receives a response from the user, or instances when a service request is canceled by the user, in determining the user profile for how at least some types of planned service requests are to be handled.

In some examples, the service request scheduler120can also process an event record to identify additional service parameters, such as (i) a type of transport which the user may prefer (e.g., pooled transport, large vehicle); (ii) a number of additional passengers or service locations; and/or (ii) conditions of the provided service (e.g., specific sequence of service stops). The service request scheduler120may schedule the planned service request, including the service request time, to account for such additional service parameters. For example, the service availability determination may take into account that the type of service the user may wish to receive may be sparser, or take longer to arrive. Additionally, the service request scheduler120may plan in advance for additional time that may be required for the service provider to pick-up an additional passenger for the user's planned event. By way of example, a user may purchase two tickets for a planned event (e.g., concert). The system100may schedule the transport service request for the user, with the service request time accommodating an additional service stop to pick-up another rider. The scheduled service request may further be subject to dynamic updates based on, for example, user location, traffic or other environmental conditions.

The service request scheduler120can also implement an intelligent rule-based workflow in scheduling service requests for the user based on the scheduled events of the user. For example, the event determination component122may determine that the user has purchased a return plane ticket between two cities, and further that the user has made a reservation at a hotel in the destination city. The service request scheduler120may use the event of the user's airplane trip 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 may be monitored and changed by, for example, checking a third-party flight service for delays and flight arrival times. In the same example, the service request scheduler120can schedule two additional service requests, one from the hotel in the destination city to the airport, and one from the airport of the departure city to home. When the airline ticket is purchased, the service request scheduler120can also check for baggage check-in to determine, for example, a type of service or service vehicle the user should receive.

Still further, in some examples, the service request scheduler120can override scheduled service requests based on detection of other scheduled events. For example, a user may receive transport to work as a routine activity, with the service request being timed to occur so that the user arrives at 7:00 AM. If the event determination component122detects that the user has a calendar invite for a meeting at a time earlier than his normal arrival at work, the service request scheduler120can cancel the original (or usual) planned service request and generate a new service request to enable the user to arrive at work on time for the meeting. Moreover, the service request scheduler120can configure the scheduling of the service request based on contextual information, such as the user's habits, etc. (as determined from the user profile). For example, the service request scheduler120may anticipate the user's preference to arrive 30 minutes early for a calendared call, based on perceived habits of the user, as determined by, for example, the profiler118.

In some variations, the service request scheduler120may schedule multiple actions for the user, including actions which are not directly related to scheduling service requests. For example, the service request scheduler120may schedule to waken the user at a particular time, and/or to monitor (e.g., via sensor data obtained from the user's mobile device) when the user wakes up. In some implementations, the service request scheduler120may change the service request time for a planned service request based on, for example, the user's activity. For example, the service request scheduler120may receive motion sensor data and/or alarm clock data which indicates the user may have overslept. The service request scheduler120may delay the service request time for the planned service request by a given number of events, or until a particular event is detected (e.g., the user walks outside of the house, as detected by device sensors and/or user's location).

FIG.2Aillustrates an example transport arrangement service that includes a service scheduling system such as described with an example ofFIG.1. With respect toFIG.2A, a transport arrangement service200includes functionality for implementing a service scheduling system100, such as described with an example ofFIG.1. According to some examples, the transport arrangement service200is implemented as a network computer system that operates to match service requests of requesters with service providers who fulfill the service requests. In some variations, the transport arrangement service200is implemented as a network computer system that implements a platform of distributed functionality. When implemented as a distributed platform, the service200may incorporate functionality implemented by servers and mobile devices of users (e.g., users and service providers).

In an example ofFIG.2, the transport arrangement service200may include a requester interface210, a provider interface220, a matching component230, and a service data store240. The requester interface210communicates with requester service applications216that execute on respective mobile devices202of requesters. When launched, each requester service application216may establish a secure and persistent communication channel with the service200using a corresponding instance of the requester interface210. Among other operations, the requester interface210may provide instructions and otherwise configure operations of the service application216in obtaining and transmitting device data203to the service200.

The provider interface220may also communicate with provider service applications218, executing on mobile devices204of individual providers of a group of providers. The service200may establish a secure and persistent communication channel with individual service applications218executing on corresponding mobile devices204. Each provider service application218may execute to obtain and transmit device information, including the current location207of the provider device204. Each provider may also be associated with a vehicle that the provider operates to transport requesters from a service start location to a destination.

In an example, a provider may interact with the provider service application218to indicate their respective status as being available to provide service, or alternatively as offline or unavailable. Once the service provider is online, the provider service application218may repeatedly or continuously transmit the provider's location information207. The communications from the provider device, including the provider's location information207, may be received by the provider interface220. The provider interface220may store and update a record for the service provider with the active service data store240. By way of example, the record for the service provider may identify the current location207, as well as the status and service identifier of the provider. The provider interface220may repeatedly update the service provider record as to the current location and service status of the service provider, based on repeated communications with the service provider's device204.

The requesters may utilize the respective requester service applications216to transmit service requests201from their respective mobile devices202. The service requests201may be received by the requester interface210, with each service request specifying a set of service parameters205(e.g., service start location, destination location). The matching component230may use the set of service parameters to match individual service requests201to corresponding providers. The matching component230may perform the matching based on criteria that includes proximity of available service providers (as determined by the current location207of the service provider) to the service start location (e.g., requester current location, pickup location, etc.). When the matching component230performs a match, a confirmation communication may be communicated to the requester via the requester interface210. The service provider may also receive an assignment via the provider interface220. When a service provider is matched, the service provider may also receive the service start location, and the service provider may operate a respective vehicle towards the service start location, where the requester may be picked up and transported to the destination.

According to some examples, requester interface210communicates with the requester service applications216to receive service requests201and device data203. Each service request201may include service parameters205that identify, for example, a start location and a destination. The requester interface210may also instruct the individual service applications216to interface and obtain data from (i) a location determination component of the mobile device (e.g., satellite receiver) via a location determination interface226of the requester service application216; (ii) one or more motion sensors (e.g., accelerometer and/or gyroscope) of the mobile device202via a sensor interface228of the requester service application216; and/or (iii) another application (e.g., alarm clock, calendar application) or application data set of the mobile device202, via a corresponding application interface232of the requester service application216.

According to some examples, the requester interface210may receive the request201, and forward the request201to the matching component230. The matching component230determines a pool of available service providers from the240, based at least in part on a comparison of the current location of the service providers and the service start location of the service request. From a pool of available service providers, the matching component230selects a given service provider for the service request201. Once selected, the matching component230changes the service state of the service provider, and the provider interface220may communicate the service parameters of the matched service request to the requester via the requester service application218. Depending on implementation, the service state of the service provider may be changed from, for example, available to travel to the start location (e.g., when the service provider is first matched to the service request and begins to travel towards the service start location), to providing service (e.g., beginning with when the requester enters the vehicle of the service provider), and from on-trip to available (e.g., when the service provider nears or arrives at the destination of the service request).

In some examples, the requester service application216includes a user interface component234that includes a set of selectable application features235for requesting services. Each application feature235can be selected to generate a service request201for the service200, with each application feature235being individually assigned to a particular destination. For example, one or more of the application features235may each be assigned to a favorite destination of the user. With the user's selection of the application feature235, the service application216may automate generation of a service request that specifies a destination corresponding to the assigned location of the application feature235.

According to some examples, the service200includes an online event monitor212that monitors online accounts and other resources of individual users to detect and record scheduled events213which may require transport for the user. In an implementation, the online event monitor212utilizes user credential information (e.g., login and password), as provided by the user data store245, to identify and connect with a corresponding third-party network service that hosts a corresponding user account (e.g., online user calendar, email store, reservation store, social network site, etc.). In one implementation, the online event monitor212may utilize any one of multiple possible service connectors208(each for specific third-party online services), in order to access an online account or resource of the user to obtain scheduled events213.

In some examples, the service200includes a device monitoring component214that instructs, or otherwise configures operation of the requester service application216to return device data203that is indicative of user activity. By way of example, the device monitoring component214may trigger the requester service application216to communicate, over a given time interval, device data203corresponding to (i) location information, indicating a current location of the user, (ii) sensor data, indicating, for example, movement of the mobile device202, and (iii) application data, corresponding to, for example, local calendar records and application data of the requester's mobile device202, as well as notifications or other outputs from third-party and/or native application resident on the mobile device202. In this way, the device monitoring component214may determine user activity data211from the device data203. The device monitoring component214may communicate the user activity data211to the service scheduling system100.

According to some examples, the system100utilizes scheduled events213to determine a service request queue for individual users. The service request schedule may utilize activity data211and scheduled events213to determine a recommended set of planned service requests. In one implementation, the system100generates notifications for the user to view identified scheduled events213, in order to designate select events as being transport events (or events which the user elects to receive transportation services). In variations, the system100may automate the designation of at least some events as requiring transport services, based on, for example, past user designations.

A profiler206may also access user profile information via the user data store245, including, for example, prior service requests of individual users, as well as prior user designations by which certain scheduled events are also selected (or otherwise accepted) to be transport events. The profiler206may also identify routine events215(e.g., user traveling to work) for the system100.

In some examples, the system100may generate a service request queue255for individual users. The service request queue255may identify scheduled event record102that have been designated or determined (e.g., by default or through user profile) as transport service events. For each transport service event, the service request queue225may specify an event identifier, an event location, an event start time, and a service request time (or window of time). As described with an example ofFIG.1, the service request time may account for (i) the expected duration for a transport vehicle to travel from the service start location to the event location, (ii) the expected duration of time to locate an available service provider, and (iii) an expected time of travel for the service provider to arrive at the service start location. As described with other examples, the determination of the service request time may be impacted by environmental conditions, such as roadway congestion and service provider availability. The environmental conditions may impact the service request time based on location and time when such conditions are present.

In some examples, the system100utilizes the activity data211to update scheduled service requests of a given user. In an example, the system100may monitor user activity, in order to determine activity data211for requesters who have scheduled service requests in an upcoming duration of time. The monitored activity data211may identify for example, the requester's current location, which may also coincide with the service start location when the transport request is made. Thus, if the user changes location in an interval preceding the scheduled service request, the user's changed location can be detected and used to update the particular entry from the user's service request queue255.

According to some examples, a regional monitoring component244may monitor a given region using the active service data store240. The active service data store240may track service providers by location and status. The regional monitoring component244may monitor the active service data store240to identify, for example, service providers that are operating on roadways but moving at slow speeds. As an addition or variation, the regional monitoring component244may also identify sub-regions where there is an undersupply of service providers. The regional monitoring component244may include logic to generate geographic coordinates and/or route segments that identifying locations which are affected by congestion or other environmental conditions. The regional monitoring component244may further assign values, in terms of, for example, units of time, weights or other parameters, to reflect a 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 congestion signal241to the system100.

As an addition or variation, the regional monitoring component244may repeatedly sample service provider availability over a given geographic region. In an example, the service provider availability may be based at least in part on a number of service providers who are (or will be within a given duration of time) available to provide transport services within a given sub-region. As an addition or variation, the service provider availability may also be based on a number of requesters (or expected requesters) over the same duration. The regional monitoring component244may determine a service availability value, corresponding to a time value or weight that impacts timing parameters, such as the expected duration for selecting a service provider, and/or a time of travel for the selected service provider to arrive at the service start location. The regional monitoring component244may communicate the service availability value as the availability signal243.

Some examples provide for the regional monitoring component244to communicate respective congestion and availability signals241,243in response to determining that environmental conditions are present at a given area which deviate from an expected or default measure of the condition by more than a designated threshold amount. For example, the regional monitoring component244may assign default travel times for road segments, based on observed or model traffic patterns. As such, the regional monitoring component244may take into consideration normal or expected congestion over specific time intervals. In such an example, the regional monitoring component244may generate congestion signal241for a corresponding set of geographic coordinates or region in response to determination of the congestion is significantly different than what is expected. For example, the regional monitoring component may generate the congestion signal241for a particular location or sub-region when the observed congestion changes a traversal time of a vehicle across the route by more than 2 minutes.

In variations, the system100may trigger the regional monitoring component244to generate respective congestion and or availability signals241,243. For example, the system100may repeatedly query the regional monitoring component244for congestion and/or availability signals241,243in order to determine those scheduled service requests of a given number of users that may be impacted by environmental conditions.

In some examples, the system100may implement programmatic processes to handle, or otherwise act on planned service request entries of the service request queue255for individual users. Depending on implementation, different types of actions257may be performed by the system100in a time interval that immediately precedes a service request time for a scheduled transport event of the user. In some examples, the system100may perform different actions for different types of scheduled transport events. For example, a routine event (e.g., user traveling to work) may receive one type of action (e.g., notification), while a reservation event (e.g., user going to concert or dinner) may cause the system100to implement a different kind of handling action.

In an implementation, the system100may perform the action257of sending a notification261to the requester that identifies information about a user's scheduled service request. The notification261may be communicated through, for example, the service application216(via the requester interface210), a messaging application, and/or a calendar service or application (e.g., residing on the mobile device202). The notification261itself may include separate timing parameters, to provide the user with lead time to act on the notification and make the scheduled service request at the appropriate service request time indicated in the corresponding scheduled event record102. Depending on user preference, a user may receive several notifications at different times leading up to the service request time. Still further, in some variations, one or more notifications261may be triggered by monitoring the user's activity data211for predetermined markers (which may be stored as part of the user's profile).

For example, based on user profile or preference, the user may receive a first notification for a scheduled service request to transport the user to work when the user is deemed to be awake. To determine when the user is awake, the system100may monitor user activity data211, such as motion sensors that indicate when the mobile device was first moved in the morning, or when alarm notifications, indicating the user's alarm clock has sounded.

As an addition or variation, the system100may generate a set of configuration parameters259that configure the user interface component234of the service application216, running on the user's mobile device202. The configuration parameters259for a particular scheduled transport event may be active for a set window of time (e.g., one hour) preceding the service request time of the event. The duration in which the configuration parameters259are active may be based on, for example, user preference and/or the type of event.

In one implementation, the configuration parameters259include configuring an application feature235of the user interface component234to appear for an interval of time preceding the service request time of the corresponding scheduled transport event. The application feature235may be configured to associate service parameters205of a service request to information of the corresponding scheduled event record102of the scheduled event. Thus, the configuration parameters259may configure the application feature235to use the event location as one of the service parameters205for the corresponding service request201. The application feature235may persist on, for example, a home interface, calendar interface or request interface of the service application216. As an addition or variation, the application feature235may include linked features in other applications. For example, the application feature235may be selected from the service request interface of the service application216to transmit a service request201to the service200, while a separate calendar application running on the user's mobile device may also include a short-cut feature that links to the application feature235.

Still further, in other variations, the application feature may be dynamic in appearance, to indicate information about the scheduled event, including an amount of time remaining until the service request time and/or the event start time.

As an addition or variation, the system100may handle the scheduled service request by making the service request201on behalf of the user. In an example, the service200may deploy a trigger or other programmatic mechanism resident on the service application216to make the service request201at the service time indicated by the scheduled event record102of the scheduled service request. In some variations, the service200may utilize a server or network side agent or component to generate the service request201on behalf of the user.

FIG.2Bis a block diagram representation of an application feature, according to one or more examples. According to some examples, the service application216may provide a set of one or multiple application features235on a given interface when the service application216is executed on the requester's mobile device202. Each of the application features235may be selectable to trigger the requester's mobile device202(or service application216) to transmit or initiate a service request201, with one or more service request parameters205that are determined by the event record102of the planned service request.

According to some examples, the application feature235may include a graphic element282, one or more activation triggers284and a service parameter integration286. According to examples, the application feature235may be activated by activation triggers284during a time interval that can be set by configuration parameters259, as determined by the system100. For example, the configuration parameters259may designate a start time and end time for when the application feature235is to be active. When activated, the application feature235may convey information about a corresponding event. The application feature235may also display information that is indicative of a time when the application feature should be used by the user to make a transport request. In this way, the window of time which the application feature235is active (e.g., 15 minutes, 2 hours) may be based on the configuration parameters259.

The graphic element282of the application feature235can include image data, such as an iconic image or a dynamic set of images, which indicate or provide information about an event of a scheduled service request. In some examples, the graphic element282may convey an action the user should perform to ensure timeliness with regards to the user being able to use the transport service to arrive on time at a corresponding event. In variations, the appearance or visual state of the graphic element282may also be based on a remaining duration during which the application feature235is to remain active on an interface of the service application216. For example, the application feature235may include text content, or alternatively symbolic or iconic content, corresponding to an indication when transport service should be requested to enable the user to arrive at a particular location or event on time (e.g., time for when user should depart for airport). The appearance of the graphic element282may also be dynamic to reflect, for example, a proximity in time to when the user should make the service request (e.g., by selecting the application feature235).

The service parameter integration286may use metadata fields from the event record102of the scheduled response trigger to generate the service request201. The event record102may be structured to have a common format, to facilitate integration of event information from various sources (e.g., user online calendar or account) into a structure of the service request201.

FIG.3illustrates an example method for scheduling service requests for planned events and activities of a user. A method such as described with an example ofFIG.3may be implemented using one or more components of a system such as described with examples ofFIG.1,FIG.2AandFIG.2B. Accordingly, reference may be made to elements ofFIG.1,FIG.2AandFIG.2Bfor purpose of illustrating a suitable component for performing a step or sub-step described therein.

With reference to an example ofFIG.3, the system100monitors computing resources of a user to identify indicators for planned events of the user (310). In some examples, the system100performs the monitoring by communicating with the user activity monitor110. The computing resources of the user may include, for example, a mobile device of the user, and/or an online account or set of online accounts for the user. The system100may interface with a user's mobile device to access, for example, local data sources residing on the user's mobile device202. For example, the requester service application216running on the mobile device202of the user may be instructed to access a calendar application to identify upcoming events which the user may have recently scheduled. As an addition or variation, the system100may access information provided with one or more online accounts of the user (e.g., online calendar, social network feed, email store, reservation account, ticket purchase account etc.). Still further, the system100may be implemented to accept input regarding upcoming events from users via alternative forms of manual input.

The system100may determine a planned user event or activity from monitoring the computing resources of the user (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 implementation of a rules engine. As an addition or variation, the determination of transport events from the user's event and activities information may include profiling user activity using, for example, user activity data211generated from the user's mobile device, identification of select types of online activities (e.g., transactions, or transactions from specific sites indicating purchase of event related merchandise (e.g., concert)).

According to some examples, the system100determines a set of service parameters for a planned or scheduled user event (330). In one implementation, the system100implements programmatic processes to parse information and content from a disparate data set that includes records retrieved from online records and data items generated from the user's activity data (e.g., geographic coordinates and/or sensor data transmitted from the user's mobile device). In one implementation, the event records102are generated and structured to include fields that coincide with service request parameters for a transport request (e.g., event location, event start time, type of transport). The system100implements processes to parse detected events and activity data for tokens and information items which match to fields of the corresponding event record102. Once detected, the fields of the event record102may be populated with corresponding metadata, determined from the parsed information and detected information items.

In some variations, the system generates event records as part of a process to determine the planned user event or activity. The system100may process event records and information to populate the fields of the event record102, which in turn provide a uniform and readily formatted data structure that enables analysis and subsequent use of identified event information.

In some examples, the system100(or service200) may receive a QR code input (or other form of coded input), initiated by the user operating, for example, a mobile device. In such examples, the QR code may identify a purchased item. The system100may analyze the information of the purchased item to determine an event.

The system100may schedule a service request for a planned user activity (340). In some examples, the system100generates a service request queue155, corresponding to a set of scheduled service requests which are to be acted on by the system100. In determining the scheduled service requests, the system100may determine a service trip time (342) and a service provider arrival time (344). The determination of the service trip time may be monitored and updated based on, for example, the current location of the user. Additionally, the service trip time may be updated by monitoring environmental conditions, such as traffic congestion at a relevant geographic area of the service request.

The determination of the service provider arrival time may be based on factors such as a determination of the number of service requesters and/or service providers in the relevant geographic area of the service request. In some variations, the determination of the service provider arrival time may also account for a service state of detected service providers (e.g., whether service provider is available, whether service provider is nearing destination and will be available, etc.). In variations, the availability of the service provider may also depend in part on the number of requesters, such as the number of users with open (e.g., unmatched) service requests, and/or the number of users performing an action that is indicative of an imminent service request (e.g., launching the requester service application216). The determination of the service provider arrival time may also take into account factors which may impede transit time in general, such as traffic.

In some examples, the system100may modify the scheduled service request based on determined user activity. For example, the system100may monitor the set of computing resources to determine user activity in a time interval preceding the scheduled time of the original service request. The user activity can be monitored by, for example, obtaining location information from the user's mobile device (indicating the user's current location), obtaining sensor information (e.g., movement data to indicate whether the user is moving about), application data from the user's data (e.g., detect an application alert, etc.). The monitored activity can be extended to multiple user devices, such as the user's mobile device92and/or smart watch94. The scheduled service request may be modified by, for example, changing the scheduled service request time and/or service start location, based on a current or predicted user location. Additionally, the monitoring and modifying may be repeated throughout the time interval until the scheduled service request is made.

In some variations, the system100obtains (e.g., via the service200) real-time (or near real-time) information for determining the service time and/or the service provider arrival time. In variations, the system100may utilize a modeled determination, based on, for example, historical data that is specific to the geographic location, time of day, day of week and other contextual information.

According to examples, the system100performs an action on behalf of the user with respect to initiating the service request at a scheduled time (350). In an example, the action performed by the system100is to send a notification to the user about the planned service request. The notification may be transmitted through, for example, the requester service application216, or through an alternative transport medium. In some examples, the timing (i.e., when the notification is sent) of the notification may be based on the determined service request time for the planned service request. Additionally, the content of the notification may be dynamically determined. For example, the notification may identify a time remaining until when the planned service request is to be initiated.

As another example, the action performed by the system100includes configuring one or more selectable application features235(e.g., seeFIG.2B) to appear during a time interval that precedes a recommended service request time. The application feature235may be associated with service parameters, such that selection of the application feature causes the generation of a service request to transport the user to the event location.

Still further, as another example, the system100may automatically make the transport service request at the service request time, using service parameters identified from the corresponding event record102. The automation of the service request may be based on, for example, a preference or setting of the user.

FIG.4is a block diagram that illustrates a computer system upon which embodiments described herein may be implemented. A computer system400can be implemented on, for example, a server or combination of servers. For example, the computer system400may be implemented as part of a network computer system to schedule service requests, as described with an example ofFIG.1. The computer system400may be implemented as part of a network service to enable users to schedule service requests, as described with an example ofFIG.2AandFIG.2B. In the context ofFIG.1,FIG.2AandFIG.2B, some or all of the functionality described with the system100and/or the service200may be implemented using computer system400. Likewise, a method such as described with an example ofFIG.3may also be implemented using the computer system400.

In one implementation, the computer system400includes processing resources410, memory resources420(e.g., read-only memory (ROM) or random-access memory (RAM)), a storage device440, and a communication interface450. The computer system400includes at least one processor410to process information (including storing temporary variables) and execute instructions stored in the memory resources420. The computer system400may also include additional storage devices for storing static information and instructions for the processor410. A storage device440, such as a magnetic disk or optical disk, is shown for storing information and instructions.

The communication interface450enables the computer system400to communicate with one or more networks452(e.g., cellular network) through use of the network link (wireless or a wire). Using the network link, the computer system400can communicate with one or more computing devices, and one or more servers. In accordance with examples, the computer system400can execute instructions to enable scheduling of service requests for planned events (shown as “service scheduling instructions442”). The service scheduling instructions442may be stored in the memory420and can include, for example, processes for implementing the service scheduling system100and variations thereof, as described with an example ofFIG.1,FIG.2AandFIG.2B.

Examples described herein are related to the use of the computer system400for implementing the techniques described herein. According to an aspect, techniques are performed by the computer system400in response to the processor410executing one or more sequences of one or more instructions contained in the memory resources420. Such instructions may be read into the memory resources420from another machine-readable medium, such as the storage device440. Execution of the sequences of instructions contained in the memory resources420may cause the processor410to perform the process steps described herein. In alternative implementations, hard-wired circuitry may be used in place of or in combination with software instructions to implement examples described herein. Thus, the examples described are not limited to any specific combination of hardware circuitry and software.

FIG.5is a block diagram that illustrates a mobile device upon which examples described herein may be implemented. In an example, a mobile device500may include a roaming device, capable of wireless communications (e.g., cellular device that is 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 or wireless fidelity (“Wi-Fi”) communications.

With reference to an example ofFIG.5, a mobile device500includes a processor510, memory resources520, a display device530(e.g., such as a touch-sensitive display device), one or more communication sub-systems540(including wireless communication sub-systems), input mechanisms550(e.g., an input mechanism can include or be part of the touch-sensitive display device), and one or more sensors (e.g., a satellite receiver component, an accelerometer, one or more cameras, etc.)560. In one example, at least one of the communication sub-systems540sends and receives cellular data over data channels and voice channels.

The processor510can provide a variety of content to the display530by executing instructions and/or applications that are stored in the memory resources520. For example, the processor510is configured with software and/or other logic to perform one or more processes, steps, and other functions, including to execute (i) service application instructions516to implement, for example, service application216ofFIG.2A, and (ii) application configuration instructions525, to configure an appearance or functionality of an application feature235or application interface, as described with, for example,FIG.2AandFIG.2B. Additionally, application instructions516may be used to implement a method such as described with an example ofFIG.2.

Although embodiments are described in detail herein with reference to the accompanying drawings, it is to be understood that the invention is not limited to those precise embodiments. As such, many modifications and variations will be apparent to practitioners skilled in this art. Accordingly, it is intended that the scope of the invention be defined by the following claims and their equivalents. Furthermore, it is contemplated that a particular feature described either individually or as part of an embodiment can be combined with other individually described features, or parts of other embodiments, even if the other features and embodiments make no mentioned of the particular feature. Thus, the absence of describing combinations should not preclude the inventor from claiming rights to such combinations.

It is contemplated for embodiments described herein to extend to individual elements and concepts described herein, independently of other concepts, ideas or system, as well as for embodiments to include combinations of elements recited anywhere in this application. Although embodiments are described in detail herein with reference to the accompanying drawings, it is to be understood that the invention is not limited to those precise embodiments. As such, many modifications and variations will be apparent to practitioners skilled in this art. Accordingly, it is intended that the scope of the invention be defined by the following claims and their equivalents. Furthermore, it is contemplated that a particular feature described either individually or as part of an embodiment can be combined with other individually described features, or parts of other embodiments, even if the other features and embodiments make no mentioned of the particular feature. Thus, the absence of describing combinations should not preclude the inventor from claiming rights to such combinations.