[0001] This Patent Application claims the benefit of U.S. Provisional Patent Application Serial No. 62/037,445, filed on Aug. 14, 2014 and entitled "SYSTEMS AND METHODS FOR IMPROVED SHARED

TRANSPORTATION SERVICES AND IMPROVED QUEUED TRANSPORTATION SERVICES" which is incorporated by reference in its entirety.

[0002] This Patent Application claims the benefit of U.S. Patent Application Serial No. 14/573,401, filed on Dec. 17, 2014 and entitled "SYSTEMS AND METHODS FOR TRANSPORTATION SERVICES FOR PACKAGE DELIVERY" which is incorporated by reference in its entirety.

TECHNICAL FIELD

[0003] The present disclosure generally relates to transportation services and, more specifically, to systems and methods for the scheduling and routing of package deliveries.

BRIEF DESCRIPTION OF THE DRAWINGS

[0004] Some embodiments are illustrated by way of example and not of limitation in the figures of the accompanying drawings.

[0005] FIG. 1 is a schematic diagram showing an example of a system for providing a transportation marketplace, according to some embodiments;

[0006] FIG. 2 is a block diagram showing example components of a transportation server, according to some embodiments;

[0007] FIG. 3 is a block diagram showing example components of a client device, according to some embodiments; [0008] FIG. 4 is a flowchart showing an example method of clustering packages, according to some embodiments;

[0009] FIG. 5 is a flowchart showing an example method of filtering passenger requests, according to some embodiments;

[0010] FIG. 6 is a flowchart showing an example method of determining a rendezvous location, according to some embodiments;

[0011] FIG. 7 is a block diagram showing example additional components of a transportation server.

[0012] FIG. 8 is a flowchart showing an example method of dynamically modifying a route of a shared transportation service, according to some embodiments.

[0013] FIG. 9 is a diagram showing a user booking a shared transportation service that is currently transporting another user to a drop-off location, according to some embodiments.

[0014] FIG. 10 is a diagram showing a shared transportation service

dynamically modified to allow for a maximum number of users to utilize the shared transportation service.

[0015] FIG. 11 is a block diagram of a machine in the example form of a computer system within which a set of instructions, for causing the machine to perform any one or more of the methodologies discussed herein, may be executed, according to some embodiments.

DETAILED DESCRIPTION

[0016] Example systems and methods for transportation services for package delivery are described. In some embodiments, the transportation service combine the scheduling of the delivery of one or more packages with dynamically determining routes to a pick-up location and a drop-off location desired by at least one passenger.

[0017] Example systems and methods for improved shared transportation services and improved queued transportation services are described herein. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of example embodiments. It will be evident, however, to one skilled in the art that the present technology may be practiced without these specific details.

[0018] The following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of example embodiments. It will be evident, however, to one skilled in the art that the present technology may be practiced without these specific details.

[0019] Embodiments described below provide for an automated method for convenient, efficient allocation of personal and package transportation and other on-demand transportation resources and transportation services over a data communications network. These embodiments may also be extended for use in a variety of scenarios in which a mobile resource requires scheduling and allocation of that resource.

[0020] A transportation server may provide an online environment in which drivers and users (e.g. passengers) may connect with one another for transportation services. The transportation server determines payments required by each passenger of a transportation service and required for delivery of one or more packages. In some embodiments, a transportation service may comprise a trip (or route) from a starting location to a destination location. In some embodiments, a transportation service may be a trip (or a dynamically modifiable route) from a pick-up location associated with a passenger and/or a package to a drop-off location associated with the passenger and/or the package.

[0021] Systems, methods and a computer-readable medium provide for package delivery by one or more transportation services that transport one or more passengers to desired locations. In one or more embodiments, a transportation server identifies a package delivery location for a package(s). The transportation server determines a route characteristic based at least on the package delivery location. The transportation server sends the route characteristic to a transportation service for transporting at least one passenger to a passenger dropoff location.

[0022] In some embodiments, it is understood that a route characteristic can refer to at least a portion of a route by which the transportation service travels in order to transport a package(s) and a passenger(s). In some embodiments, the package and passenger concurrently share at least the portion of the route.

[0023] In other embodiments, the route characteristic can refer to a geographic area (or direction) upon which a route will be based on in order for the transportation service to travel to pick-up/deliver packages and pick-up/drop-off passengers. The route characteristic can also refer to an update to a portion(s) of a current route of the transportation service. The route characteristic can also refer to a scheduled time the transportation service should travel on a particular route.

[0024] In various embodiments, the transportation server determines the route characteristic based at least on any of the following: package pick-up location, package pick-up time, package delivery location, package delivery deadline, passenger pick-up location, passenger pick-up time (such as a pre-scheduled pick-up time), passenger drop-off location, passenger desired drop-off time.

[0025] The transportation server further determines the route characteristic based at least on a current location of a particular transportation service, a distance of the current location of the particular transportation service to a pickup location or a drop-off location of a package(s), a distance of the current location of the particular transportation service to a pick-up location or a dropoff location of a passenger(s).

[0026] In various embodiments, the transportation server further determines the route characteristic based on current traffic data, historical traffic data, as well as data indicative of various attributes of the current route of the transportation service.

[0027] In various embodiments, the transportation server further determines the route characteristic based on attributes of available transportation services. Such attributes of available transportation services comprising any of the following: start time of the transportation service's shift, end time of the transportation service's shift, current location of the transportation service, predicted location of the transportation service, current capacity of the transportation service (such as whether the transportation service is currently transporting a maximum number of packages and/or passengers).

Clustering of Packages

[0028] In one embodiment, the transportation server identifies a plurality of packages, where each package may a different package delivery location. The transportation server analyzes each different package delivery location to identify a cluster of packages that includes packages having respective package delivery locations located along an optimal route. For example, the

transportation server identifies the optimal route as including a first package delivery location and a second package delivery location by identifying a distance between the first and second package delivery locations as being at or below a threshold distance. The transportation server can further include a third package delivery location on the optimal route by identifying that a distance between the third package delivery location and at least one of the first and second package delivery locations is also at or below the threshold distance.

[0029] In other embodiments, the transportation server identifies a particular package delivery location and defines a package cluster area that encompasses the particular package delivery location. Any additional package with a package delivery location that is situated within the package cluster area is assigned to the package cluster area by the transportation server. In some embodiments, the transportation server iterates through various delivery package locations in order to identify a package delivery location that corresponds to a package cluster area in which a desired number of additional package delivery locations are also situated. [0030] Upon determining an optimal route through multiple package delivery location, or upon determining a package cluster area, the transportation server determines a period of time during which a transportation service should be located proximate to the optimal route or in the package cluster area. For example, a transportation service may be at a current location and receiving requests from potential passengers for respective rides to a desired passenger drop-off location. The transportation server predicts a period of time during which the transportation service is most likely to receive requests from one or more as-of-yet unidentified passengers for rides to passenger drop-off locations proximate to the optimal route or within the package cluster area. The transportation server determines a package delivery time for each package in the cluster of packages to occur during the predicted period of time so that as the transportation service travels towards and through the optimal route or the package cluster area during the predicted period of time, there is a high likelihood that the transportation service will receive and be able to service requests from potential passengers that will most likely have desired passenger pick-up/drop-off locations near and/or along the optimal route - or near and/or in the package cluster area.

Filtering of Passenger Requests

[0031] In various embodiments, the transportation server assigns a package(s) to a particular transportation service for transporting at least one passenger from a passenger pick-up location to a passenger drop-off location. The particular transportation service travels to a package delivery location to acquire the package. The transportation server defines a filter area based on at least one package delivery location that corresponds to a package to which the particular transportation service is assigned.

[0032] The transportation server detects that a current location of the particular transportation is proximate to or in the filter area defined by the transportation server. The transportation server receives a plurality of requests from potential passengers requesting trips from respective desired passenger pick-up locations to desired passenger drop-off locations. The transportation server filters those requests that correspond to a desired passenger pick-up/drop-off location that are in - or within a threshold distance from - the filtered area in which a respective package delivery location is situated.

[0033] In other embodiments, the transportation server filters those requests that correspond to a desired passenger pick-up/drop-off location located on an optimal route from the current location of the particular transportation service to the defined filter area. For example, the desired passenger pick-up/drop-off location may be within a threshold distance from a portion of a current route of the particular transportation service towards a respective package delivery location.

[0034] The transportation server sends those one or more filtered requests to the particular transportation service so that the particular transportation service can accept a filtered request from a potential passenger that has a desired passenger pick-up/drop-off location near the package delivery location of a package to which the particular transportation service is assigned.

Dynamic Rendezvous Location

[0035] In various embodiments, the transportation server receives an indication of a vehicle to which one or more packages are currently assigned. The transportation server may also receive an indication that the vehicle is currently on a route towards a package delivery location of a respective package. The transportation server identifies a current location of the vehicle and a current location of a particular transportation service for transporting at least one passenger to a passenger drop-off location. Based on the identified respective current locations, the transportation server identifies a rendezvous location and an optimal route for both the vehicle and the particular transportation service to arrive at the rendezvous location within a given range of time. It is understood that the rendezvous location is a location that is optimally located for both the vehicle and the particular transportation service given the current locations of the vehicle and particular transportation service.

[0036] Both the vehicle and the particular transportation service travel to the rendezvous location where the package is physically moved to the custody of the particular transportation service. The transportation server receives an indication that the particular transportation service has custody of the package. The transportation server modifies a record of assignment for the package to reflect that the particular transportation service is now assigned to the package - instead of the vehicle.

[0037] It is understood that, according to various embodiments disclosed herein, the transportation server determines an optimal route(s), an optimal location(s) and an optimal area(s) with respect to a current location of transportation services, a current location of other vehicles, package delivery locations and/or current locations of one or more packages.

[0038] Embodiments described below provide for an automated method for convenient, efficient allocation of personal transportation and other on-demand transportation resources and transportation services over a data communications network. These embodiments may also be extended for use in a variety of scenarios in which a mobile resource requires scheduling and allocation of that resource. [0039] A transportation server may provide an online environment in which drivers and users (e.g. passengers) may connect with one another for transportation services. The transportation server determines payments required by each passenger of a transportation service. In some embodiments, a transportation service may comprise a trip (or route) from a starting location to a destination location. In some embodiments, a transportation service may be a trip (or route) from a pick-up location associated with a passenger to a drop-off location associated with the passenger. In various embodiments, an upcoming transportation service may be a transportation service to be performed by a particular driver, from a pick-up location to a drop-off location, after the particular driver completes a transportation service that is currently in progress.

[0040] FIG. 1 is a schematic diagram showing an example of a system 100 for providing a transportation marketplace. The system 100 includes a

transportation server 104, one or more client devices 108, and a third party server 1 10. The components of the system 100 may be connected directly or over a network 102, which may be any suitable network. In various

embodiments, one or more portions of the network 102 may include an ad hoc network, an intranet, an extranet, a virtual private network (VPN), a local area network (LAN), a wireless LAN (WLAN), a wide area network (WAN), a wireless WAN (WW AN), a metropolitan area network (MAN), a portion of the Internet, a portion of the Public Switched Telephone Network (PSTN), a cellular telephone network, or any other type of network, or a combination of two or more such networks.

[0041] The transportation server 104 may include a network-addressable computing system that may facilitate communication between drivers and passengers and may obtain and utilize data relevant to drivers and/or passengers stored in the database(s) 106.

[0042] The client device 108 may be any suitable computing device that may be used by a driver and/or a passenger to communicate with one another, such as a smart phone, a personal digital assistant (PDA), a mobile phone, a personal computer, a laptop, a computing tablet, or any other device suitable for communication.

[0043] The third party server 110 may be any server that may be accessed by the transportation server 104 and/or the client device 108 to obtain information relevant to transportation services (e.g., public transportation, location-based services, etc.).

[0044] FIG. 2 is a block diagram showing example components of a transportation server 104. The transportation server 104 may include an input module 205, an output module 210, a transportation module 215, a package deliver module 220, a package cluster module 225, a request filter module 230, a rendezvous location module 235 and a dynamic route modification module 240.

[0045] The input module 205 is a hardware-implemented module to receive and process any inputs from one or more components of system 100 of FIG. 1 (e.g., one or more client devices 108, third party server 110, etc.). The inputs may include requests related to transportation, requests for transportation services, indications of a driver' s computing device, payment information, identification of one or more packages and corresponding package pick-up and/or delivery locations, and the like.

[0046] The output module 210 is a hardware- implemented module to send any outputs to one or more components of system 100 of FIG. 1 (e.g., one or more client devices 108, third party server 110, etc.). The outputs may include information about available drivers (such as drivers eligible to be booked for upcoming transportation services), passengers requesting transportation, passengers requesting upcoming transportation services, identification of one or more packages and corresponding package pick-up and/or delivery locations, and the like.

[0047] The transportation module 215 is a hardware- implemented module to manage, facilitate, and control information related to transportation requests for and acceptances of transportation services from passengers and drivers, respectively.

[0048] The package delivery module 220 is a hardware-implemented module to manage, control, store, and access information associated with one or more packages. The information may be stored in and accessed from the database(s) 106 shown in FIG. 1. The information managed by the package delivery module 220 may include any information describing a package identifier, a current location of a package, a pick-up location of a package, a package delivery location, a required delivery time of a package, a third party handler of the package, and an identification of a transportation service assigned to the package.

[0049] The package cluster module 225 is a hardware-implemented module to manage, facilitate, and control information related to a package cluster area. In some embodiments, the package cluster module 225 identifies and defines a package cluster area. The package cluster module 225 identifies one or more packages that are to be included in a particular package cluster area. The package cluster module 225 predicts a period of time when one or more unidentified passengers are most likely to request respective rides in or proximate to (i.e. within a threshold distance from) the package cluster area.

[0050] The request filter module 230 is a hardware-implemented module to manage, facilitate, and control information related to filtering passenger request to a transportation service assigned to one or more packages. The request filter module 230 assigns one or more packages to a particular transportation service from a plurality of transportation services. The request filter module 230 identifies an area with respect to a delivery location of the one or packages. The filters a plurality of transportation requests from passengers in order to identify requests that are in or proximate to the area.

[0051] The rendezvous location module 235 is a hardware-implemented module to manage, facilitate, and control information related to rendezvous locations. The rendezvous location module 235 identifies a rendezvous location between a vehicle assigned to one or more packages and a particular transportation service from a plurality of transportation services. The rendezvous location module 235 identifies a rendezvous location that is a threshold distance from both a portion of a current route of the vehicle and a particular transportation service from a plurality of transportation services.

[0052] The dynamic route modification module 240 is a hardware-implemented module to manage, facilitate, determine, identify, and calculate modifications to a route of a transportation service. In some embodiments, the dynamic route modification module 240 modifies at least a portion of a current route of a transportation service towards a package cluster area. The dynamic route modification module 240 modifies at least a portion of a current route of a transportation service to include a passenger pick-up location and/or a passenger drop-off location that is in or proximate to an area that surrounds one or more package delivery locations. The dynamic route modification module 240 modifies at least a portion of a current route of a transportation service to include a rendezvous location. The dynamic route modification module 240 modifies at least a portion of a current route of a vehicle to include a rendezvous location.

[0053] Although not illustrated in FIG. 2, a user profile module may also be included in the transportation server 104. The user profile module is a hardware- implemented module to manage, control, store, and access information associated with drivers and/or passengers. The information may be stored in and accessed from the database(s) 106 shown in FIG. 1. The information managed by the user profile module may include any information associated with a driver(s), passenger(s) and/or one or more packages, such as preferences, vehicle information, background information of a driver, ratings of drivers and/or passengers, payment information of drivers and/or passengers, package locations, package delivery pick-up/drop-off times, and the like. [0054] FIG. 3 is a block diagram showing example components of a client device 108. The client device may be a computing device of a driver(s) and/or a passenger(s) and may include a driver application 300 and/or a passenger application 350.

[0055] The driver application 300 is a software application associated with the transportation server 104 of FIGS. 1-2. The driver application 300 includes an input module 305, an output module 310, a settings module 315, and a location module 320.

[0056] The input module 305 is a hardware-implemented module to receive and process any inputs from a driver, including inputs related to responses to a request(s) for any kind of transportation service from one or more users (e.g. passengers), inputs related to preferences of the driver, inputs related to one or more package deliveries, and the like.

[0057] The output module 310 is a hardware- implemented module to send any outputs to one or more components of system 100 of FIG. 1 (e.g., other client devices 108, third party server 110, transportation server 104, etc.). The outputs may include indications of a current location of the client device 108, indications of a current location of the client device 108 with respect to a pick-up location(s) and/or drop-off location(s), acceptance and/or denial of requests for

transportation services, indications of a current status of a schedule package delivery, and the like.

[0058] The settings module 315 is a hardware-implemented module to manage, store, and access settings indicated by a driver, such as starting location, destination location, price, a rating of a passenger, and the like.

[0059] The location module 320 is a hardware-implemented module that may determine a location of the client device 108. The location module 320 may determine a location in any suitable manner (e.g., using a third party server 110, GPS capabilities on the client device 108, etc.).

[0060] The passenger application 350 is a software application associated with the transportation server 104 of FIGS. 1-2. The passenger application 350 includes an input module 355, an output module 360, a settings module 365, and a location module 370. [0061] The input module 355 is a hardware-implemented module to receive and process any inputs from a passenger (e.g. a user), including inputs related to a request for any kind of transportation service, inputs related to preferences of the passenger, and the like.

[0062] The output module 360 is a hardware-implemented module to send any outputs to one or more components of system 100 of FIG. 1 (e.g., other client devices 108, third party server 110, transportation server 104, etc.). The outputs may include requests for a transportation service, location of the client device 108, and the like.

[0063] The settings module 365 is a hardware-implemented module to manage, store, and access settings indicated by a passenger, such as a pick-up location, a drop-off location, a price preference, a driver rating, a driver response rate, a casual carpooling preference, a preferred estimated time of arrival, and the like.

[0064] The location module 370 is a hardware-implemented module to determine a location of the client device 108. The location module 320 may determine a location in any suitable manner (e.g., using a third party server 110, GPS capabilities on the client device 108, etc.).

Clustering of Packages

[0065] FIG. 4 is a flowchart 400 showing an example method of clustering packages, according to some embodiments.

[0066] At operation 402, the transportation server 104 identifies a package delivery location for a package. In one embodiment, a plurality of packages currently located at one or more package pick-up locations each have a package delivery location.

[0067] At operation 404, the transportation server 104 defines an area that includes the package delivery location. The transportation server 104 identifies and sorts each package delivery location to identify a cluster of packages. A cluster of packages comprises one or more packages that are to be assigned for delivery by a transportation service that can concurrently transport one or more passengers to various passenger drop-off locations. [0068] The transportation server 104 analyzes each package delivery location to determine a package cluster area. A package cluster area comprises package delivery locations that are optimally located near each other. To define the package cluster area, the transportation server 104 accounts, in part, for at least one of: the desired delivery times of the packages, past traffic data, current traffic data, predicted traffic data and various distances between respective package delivery locations.

[0069] The transportation server 104 includes packages in the package cluster area having delivery locations that do not exceed a threshold distance from each other. For example, if a first delivery location for a first package is below the threshold distance from a second delivery location for a second package, the transportation server 104 defines the package cluster area as including the first and second delivery locations. If a third delivery location for a third package exceeds the threshold distance from one of the first and second delivery locations, the transportation server 104 does not include the third delivery location in the package cluster area.

[0070] In determining whether the package cluster area includes a delivery location for a package, in some embodiments, the transportation server 104 can account for travel time between other delivery locations in the package cluster area. Based on historical and current traffic data, the transportation server 104 determines an amount of travel time between delivery locations. If the transportation server 104 determines the calculated amount of travel time from a first delivery location of a first package to a second delivery location of a second package exceeds a threshold travel time, the second delivery location for the second package is not included in the package cluster area - even if the distance between the first and second delivery locations does not exceed the threshold distance.

[0071] The package cluster area can be further defined for a predefined number of package delivery locations. In some embodiments, the package cluster area can be defined as including only package delivery locations situated in at least a portion of a zip code area or any pre-defined geographical area.

[0072] It is further understood that packages included in the package cluster area each have a similar required delivery time. For example, if a difference between required delivery times for a first package and a second package does not exceed a threshold time amount, the transportation server 104 defines the package cluster area as including the first and second packages. If a difference between a required delivery time for a third package and one of the required delivery times for the first and second package exceeds the threshold time amount, the transportation server 104 does not include the third package in the package cluster area.

[0073] At operation 406, the transportation server 104 identifies a period of time during which an unidentified passenger will request a desired route to a location situated in the package cluster area. Given the package cluster area, the transportation server 104 predicts when potential passengers are most likely to send requests for transportation to respective passenger drop-off locations situated in the package cluster area - or located within a threshold distance from the package cluster area.

[0074] In some embodiments, in order to make such a prediction, the transportation server 104 analyzes previous passenger request data to identify various days and/or time ranges associated with a threshold increase in passenger requests for passenger drop-off locations (and/or passenger pick-up locations) in or within a threshold distance from the package cluster area.

[0075] The transportation server 104 may also analyze current event data to identify time range(s) when an increase in population activity will most likely occur in or proximate to (i.e. within a threshold distance from) the package cluster area. In other embodiments, the transportation server 104 may also analyze user data (such as previous transportation requests, pre-scheduled transportation requests, etc.) to identify time range(s) when one or more persons intend to go to a location in the package cluster area. It is understood that various other types of data can be considered by the transportation server 104.

[0076] At operation 408, the transportation server 104 defines a package delivery time to occur during the period of time. For each package in the cluster of packages, the transportation server 104 determines a package delivery time to occur during a period of time the transportation server 104 predicts that one or more unidentified passengers are likely to request transportation to respective drop-off locations in or proximate to the package cluster area. [0077] It is understood that the package delivery time determined by the transportation server 104 does not occur after a required delivery time of any package included in the package cluster area.

[0078] With the package delivery times for packages assigned to the package cluster area occurring during the predicted period of time, the transportation server 104 increases a likelihood that as the transportation service travels towards one or more package delivery locations in the package cluster area, the transportation service will receive passenger requests for a desired drop-off location in or proximate to the package cluster area.

Filtering of Passenger Requests

[0079] FIG. 5 is a flowchart 500 showing an example method of filtering passenger requests, according to some embodiments.

[0080] At operation 502, the transportation server 104 assigns a package(s) to a transportation service. For example, the transportation server 104 assigns a plurality of packages currently located at one or more package pick-up locations to a transportation service, where each package has a package delivery location and delivery time. The transportation service can arrive at the one or more package pick-up locations at various times and acquire each of the plurality of packages. By assigning the packages to the transportation service, the transportation server 104 creates an association between the packages and the transportation service representing the transportation service as having physical custody of the plurality of packages.

[0081] At operation 504, the transportation server 104 defines an area that includes a package delivery location for the package. In some embodiments, the transportation server 104 creates a route in a filter area the transportation service will travel, where the route includes a respective delivery location of each package assigned to the transportation service.

[0082] At operation 506, the transportation server 104 receives a request from a passenger for a ride to a desired passenger drop-off location situated in the area. In some embodiments, the transportation server 104 receives a plurality of requests from potential passengers requesting trips from respective desired passenger pick-up locations to respective desired passenger drop-off locations. The transportation server 104 sorts through the plurality of requests to identify one or more requests (hereinafter "identified requests") that correspond to pickup and/or drop-off locations situated in the filter area - or within a threshold distance from the filtered area.

[0083] In some embodiments, the transportation server 104 determines a current location of the transportation service along the route towards an upcoming delivery location for a package to which the transportation service is assigned. For each received request, the transportation server 104 determines whether a distance between the transportation service's current location on the route towards the upcoming delivery location and the requested passenger pick-up location does not exceed a threshold distance. The transportation server 104 further determines whether a distance between the requested passenger drop-off location and the upcoming delivery location does not exceed the threshold distance.

[0084] In addition, in some embodiments, the transportation server 104 determines whether a travel time between the transportation service's current location on the route and the requested passenger pick-up location does not exceed a threshold travel time. The transportation server 104 further determines whether a travel time between the requested passenger drop-off location and the upcoming package's delivery location does not exceed the threshold travel time.

[0085] At operation 508, the transportation server 104 sends the request to the transportation service that is assigned to the package. In various embodiments, if the threshold distance is not exceeded by pick-up/drop-off locations for a particular request, the transportation server 104 determines the particular request will be sent to the transportation service. If the threshold distance is exceeded by pick-up/drop-off locations for the particular request, the transportation server 104 determines the particular request will not be sent to the transportation service. Additionally, in some embodiments, if the threshold travel time is not exceeded, the transportation server 104 determines the particular request will be sent to the transportation service. Dynamic Rendezvous Location

[0086] FIG. 6 is a flowchart 600 showing an example method of determining a rendezvous location, according to some embodiments.

[0087] At operation 602, the transportation server 104 identifies a vehicle currently assigned to a package. In some embodiments, the transportation server 104 receives an indication of a vehicle associated with a third party delivery service, which is currently assigned physical custody of one or more packages.

[0088] At operation 604, the transportation server 104 identifies a current location of a transportation service. In various embodiments, the transportation server 104 receives an indication of a current location of one or more transportation services. Each transportation service may be currently traveling on a route, defined by the transportation server 104, through at least one of: a passenger pick-up location(s), a passenger drop-off location(s), a package pickup location(s) and/or a package delivery location(s).

[0089] At operation 606, the transportation server 104 identifies a current location of the vehicle assigned to the package. In various embodiments, the transportation server 104 receives an indication that the vehicle is traveling (or will be traveling) along a route to a destination - such as a package delivery location for one or more packages to which the vehicle is assigned.

[0090] At operation 608, the transportation server 104 determines a rendezvous location based on the current locations of the transportation service and the vehicle. In one embodiment, the transportation server 104 identifies a particular location and identifies a particular transportation service from a plurality of active transportation services whereby the particular location does not exceed a threshold distance from the vehicle' s current location and also does not exceed the threshold distance from the particular transportation service's current location.

[0091] In another embodiment, the transportation server 104 identifies a particular location and identifies a particular transportation service from a plurality of active transportation services whereby the particular location does not exceed a threshold distance from an upcoming portion of the vehicle's current route and also does not exceed the threshold distance from an upcoming portion of the particular transportation service's current route.

[0092] In addition to considering the threshold distance, the transportation server 104 determines whether identifying the particular location as a rendezvous location adds respective additional travel time amounts to a travel time of the current route of the particular transportation service and a travel time of the current route of the vehicle. If adding the particular location to either of the current routes of the transportation service and the vehicle does not exceed incur additional travel time above a threshold travel time, the transportation server 104 determines that the particular location further qualifies as a rendezvous location between the vehicle and the particular transportation service.

Shared Rides

[0093] A first passenger may use a software application on the first passenger's computing device to send a request for a shared transportation service. In response to the request for the shared transportation service sent from the first passenger's computing device, the transportation server may match the first passenger with a driver who will perform the shared transportation service. The transportation server books the first passenger for the shared transportation service to be performed by the driver. The transportation server may send a verification message to the first passenger's computing device. The purpose of the verification message may be to verify whether the first passenger intended to request the shared transportation service - as opposed to a non-shared transportation service. The verification message may provide to the first passenger a selectable option to opt-out of the requested shared transportation service. In some embodiments, the purpose may be to further notify the first passenger of other information required for the shared transportation service.

[0094] If the transportation server receives a cancellation response to the verification message from the first passenger's computing device within a period of time, the transportation server cancels the booked shared transportation service between the first passenger and the driver. If the transportation server does not receive a cancellation response to the verification message from the first passenger' s computing device within the period of time, the transportation server sends data for the software application on a second passenger's computing device indicating that the second passenger may also book the shared transportation service performed by the driver for the first passenger.

[0095] The second passenger may use the software application on the second passenger's computing device to view a representation of the shared

transportation service established between the driver and the first passenger. In some embodiments, the software application displays a discount price the second passenger will be required to pay for joining the shared transportation service established between the driver and the first passenger.

[0096] The second passenger may use the software application on the second passenger's computing device to send a request to join the shared transportation service established between the first passenger and the driver. In response to the second passenger's request to join the shared transportation service, the transportation server books the second passenger to accompany the first passenger during at least a portion of the shared transportation service. In some embodiments, the transportation server sends data to the driver's computing device indicating a selectable option to cancel the second passenger' s request to the join the shared transportation service. In other embodiments, the transportation server sends data to the first passenger's computing device indicating a selectable option to cancel the second passenger's request to the join the shared transportation service.

[0097] The transportation server establishes the shared transportation service between the driver, the first passenger and the second passenger. In one embodiment, the transportation server sends shared transportation service data to the first passenger's computing device and the second passenger's computing device. The shared transportation service data sent from the transportation server to the first passenger's computing device can be based on the first passenger's desired starting location and desired destination location and can also be based on the second passenger's desired starting location and desired destination location. In some embodiments, in order to be respectful of the second passenger's privacy, the shared transportation service data based on the second passenger's desired starting location and desired destination that is sent to the first passenger's computing device may be based on a result of the transportation server modifying (or obscuring) the second passenger's desired starting location and desired destination. For example, the transportation server sends a zip code or cross-streets associated with the second passenger's desired destination for display on the first passenger' s computing device.

[0098] The shared transportation service data sent from the transportation server to the second passenger's computing device can be based on the second passenger's desired starting location and desired destination location and can also be based on the first passenger' s desired starting location and desired destination location. In some embodiments, in order to be respectful of the first passenger's privacy, the shared transportation service data based on the first passenger's desired starting location and desired destination that is sent to the second passenger's computing device may be based on a result of the transportation server modifying (or obscuring) the first passenger' s desired starting location and desired destination. For example, the transportation server sends a zip code or cross-streets associated with the first passenger's desired destination for display on the second passenger's computing device.

[0099] By establishing the shared transportation service between the driver, the first passenger and the second passenger, the transportation server defines a shared transportation service trip (hereinafter "shared trip") to be performed by the driver. The shared trip will transport the first passenger to a first destination desired by the first passenger (hereinafter "First Destination"). The shared trip will also transport the second passenger to a second destination desired by the second passenger (hereinafter "Second Destination"). In addition, the first passenger and the second passenger will accompany each other during at least a portion of the shared trip. Once the shared trip is established, the transportation server determines payments required by the first passenger and the second passenger in exchange for the shared trip.

[00100] In some embodiments, the First Destination and the Second Destination are the same location. In other embodiments, the First Destination and the Second Destination are not the same location. In some embodiments, the first passenger and the second passenger begin the shared trip from the same location. In other embodiments, the first passenger and the second passenger begin the shared trip from different locations.

[00101] In some embodiments, the driver performing the shared trip logs shared trip events by entering at least one input into the driver's computing device. For example, the driver enters a shared trip event into the driver' s computing device each time a respective passenger begins and ends the shared trip. The driver's computing device sends data representative of each logged shared trip event to the transportation server. In some embodiments, the transportation server uses the data representative of a shared trip event to initiate fulfillment of a discount payment from a passenger of the shared trip.

[00102] The transportation server may facilitate payment between the driver and the passengers of a shared trip. In particular, the transportation server determines discount payments required from both the first and second passengers in exchange for the shared trip. For example, the first passenger's discount payment determined by the transportation server may be less than a payment determined by the transportation server for a non-shared transportation service that transports the first passenger to the First Destination. In addition, the second passenger's discount payment may be less than a payment determined by the transportation server for a non-shared transportation service that transports the second passenger to the Second Destination.

[00103] In some embodiments, an amount of a first discount payment required by the first passenger in exchange for the shared trip may be different than an amount of a second discount payment required by the second passenger in exchange for the shared trip. In one embodiment, the difference in the amounts of the first and second discount payments is based at least on a detour portion(s) of the shared trip the first passenger had to experience due to the second passenger's desired starting location and/or desired destination. In other embodiments, the difference in amounts of the first and second discount payments is be based at least on a detour portion(s) of the shared trip the second passenger had to experience due to the first passenger's desired starting location and/or desired destination. It is understood that a detour portion of a shared trip is a portion of the shared trip that a passenger would not have had to experience but for the starting location and/or destination location of another passenger of the shared trip.

[00104] In other embodiments, the difference in the amounts of the first and second discount payments is based at least on a portion of the shared trip during which either the first passenger or the second passenger is

unaccompanied. In other embodiments, the difference in the amounts of the first and second discount payments is based at least on a portion of the shared trip during which the first and the second passenger accompany each other during the shared trip.

[00105] In some embodiments, the difference in the amounts of the first and second discount payments is based at least on a portion of the shared trip during which the first passenger accompanies the second passenger due to the second passenger's desired destination (i.e. the Second Destination) being different than the first passenger's desired destination (i.e. the First Destination). In other embodiments, the difference in the amounts of the first and second discount payments is based at least on a portion of the shared trip during which the second passenger accompanies the first passenger due to the first passenger's desired destination (i.e. the First Destination) being different than the second passenger's desired destination (i.e. the Second Destination).

[00106] In some embodiments, the difference in the amounts of the first and second discount payments is based at least on a portion of the shared trip during which the first passenger is unaccompanied due to the second passenger's desired destination (i.e. the Second Destination) being different than the first passenger's desired destination (i.e. the First Destination). In other

embodiments, the difference in the amounts of the first and second discount payments is based at least on a portion of the shared trip during which the second passenger is unaccompanied due to the first passenger's desired destination (i.e. the First Destination) being different than the second passenger's desired destination (i.e. the Second Destination).

[00107] In some embodiments, the difference in the amounts of the first and second discount payments is based at least on a portion of the shared trip during which the first passenger is unaccompanied due to the second passenger's starting location being different than the first passenger' s starting location. In other embodiments, the difference in the amounts of the first and second discount payments is based at least on a portion of the shared trip during which the second passenger is unaccompanied due to the first passenger' s starting location being different than the second passenger's starting location.

[00108] In other embodiments, the difference in the amounts of the first and second discount payments may be based at least on a portion of the shared trip required due to the first passenger's starting location and/or desired destination. The difference in the amounts of the first and second discount payments may be based at least on a portion of the shared trip required due to the second passenger's starting location and/or desired destination.

[00109] It is understood that shared transportation services that define a shared trip amongst a plurality of passengers may be provided to the passengers at a discount or at a premium rate, which may be automatically and dynamically based on any suitable characteristics and/or factors associated with the particular shared transportation service requested. For example, a particular request for shared transportation may be fulfilled at a discounted rate based on a location of a driver and/or a location of a passenger near the time of the shared

transportation request, based on a destination associated with the shared transportation request, and the like.

Improved Shared Transportation Services and Improved Queued Transportation Services

[00110] FIG. 7 is a block diagram showing example additional components of a transportation server 104. The transportation server 104 may include the input module 205, the output module 210, a transportation module 215, a user profile module 220, a booking window module 225, a maximum occupancy module 230, a payment module 235 and a dynamic route

modification module 240. In some embodiments, the components of the transportation server 104 as illustrated in FIG.7 can be included in the embodiment of the transportation server 104 as illustrated in FIG. 2.

[00111] The input module 205 is a hardware-implemented module to receive and process any inputs from one or more components of system 100 of FIG. 1 (e.g., one or more client devices 108, third party server 110, etc.). The inputs may include requests related to transportation, requests for upcoming transportation services, indications of a driver's computing device, payment information, and the like.

[00112] The output module 210 is a hardware- implemented module to send any outputs to one or more components of system 100 of FIG. 1 (e.g., one or more client devices 108, third party server 110, etc.). The outputs may include information about available drivers (such as drivers eligible to be booked for upcoming transportation services), passengers requesting transportation, passengers requesting upcoming transportation services, and the like.

[00113] The transportation module 715 is a hardware- implemented module to manage, facilitate, and control information related to transportation requests for and acceptances of upcoming transportation services from passengers and drivers, respectively. For example, the transportation module

715 may determine and generate a list of drivers eligible to be booked to perform an upcoming transportation service(s) for one or more passengers.

[00114] The user profile module 720 is a hardware- implemented module to manage, control, store, and access information associated with drivers and/or passengers. The information may be stored in and accessed from the database(s) 106 shown in FIG. 1. The information managed by the user profile module 720 may include any information associated with a driver(s) and/or passenger(s), such as preferences, vehicle information, background information of a driver, ratings of drivers and/or passengers, payment information of drivers and/or passengers, and the like.

[00115] The booking window module 725 is a hardware-implemented module to manage, facilitate, and control information related to booking a user(s) for a shared transportation service. In some embodiments, the booking window module 725 identifies a user with a desired pick-up and/or drop-off location that is within a threshold of proximity to at least a portion of a route of a shared transportation service that has already been booked by another user. In other embodiments, the booking window module 725 identifies a user with a desired pick-up and/or drop-off location that is within a threshold of proximity to at least a portion of a route of a shared transportation service currently transporting one or more users to their respective desired drop-off locations.

[00116] The maximum occupancy module 730 is a hardware- implemented module to manage, facilitate, and control information related to a maximum number of users allowed on a shared transportation service. In some embodiments, the maximum occupancy module 730 identifies a maximum number of occupants allowed for a shared transportation service that has already been booked by one or more users. In some embodiments, the maximum occupancy module 730 identifies a maximum number of occupants allowed a shared transportation service currently transporting one or more user to their respective desired drop-off locations. In some embodiments, the maximum occupancy module 730 determines when a current occupancy of a shared transportation service is below a maximum number of occupancy. In some embodiments, the maximum occupancy module 730 determines when a current occupancy of a shared transportation service is equal to a maximum number of occupancy. In some embodiments, the maximum occupancy module 730 determines when a shared transportation service will be available to be booked by one or more additional users in order for the shared transportation service to reach the maximum number of occupancy during at least a portion of a route the shared transportation service.

[00117] The payment module 735 is a hardware-implemented module to manage, facilitate, and control payments between drivers and passengers. In some embodiments, payment module 735 determines suggested prices associated with shared transportation services that have already been booked by one or more users. In some embodiments, payment module 735 determines suggested prices associated with shared transportation services currently transporting one or more users to their respective desired drop-off locations.

[00118] In some embodiments, the payment module 735 determines prices based at least on one of: the one or more users who booked the shared transportation service, at least a portion of a current route of the shared transportation service, at least a portion of a modified route of the shared transportation service, a current location of the shared transportation service, a pick-up location and/or drop-off location of the one or more users and a requested pick-up time and/or a requested drop-off time of the one or more users.

[00119] The dynamic route modification module 740 is a hardware- implemented module to manage, facilitate, determine, identify, and calculate modifications to a route of a shared transportation service. In some

embodiments, the dynamic route modification module 740 modifies at least a portion of a route of a shared transportation service already booked by a user based on a pick-up location and/or drop-off location of an additional user. In some embodiments, the dynamic route modification module 740 modifies at least a portion of a route of a shared transportation service currently transporting one more users to their respective desired drop-off locations based on a pick-up location and/or drop-off location of an additional user.

[00120] In some embodiments, the dynamic route modification module 740 modifies at least a portion of a route of a shared transportation service already booked by a user based on a desired pick-up time and/or a desired dropoff time of an additional user. In some embodiments, the dynamic route modification module 740 modifies at least a portion of a route of a shared transportation service currently transporting one more users to their respective desired drop-off locations based on a pick-up time and/or drop-off time of an additional user.

Expanded Matching Window and Dynamic Re-routing

[00121] FIG. 8 is a flowchart 800 showing an example method of dynamically modifying a route of a shared transportation service, according to some embodiments. In some embodiments, the operations of FIG. 8 are performed by components of the transportation server 104 of FIG. 7.

[00122] In operation 802, the transportation server 104 calculates a first price for a first user for booking a shared transportation service that will include at least one unidentified additional user {e.g. an additional user(s) that has yet to book the shared transportation service). It is understood that the transportation server 104 calculates a discount price for the first user based on an expectation that the transportation server 104 will identify one or more additional users who will join the shared transportation service.

[00123] The shared transportation service includes a route that includes a first pick-up location desired by the first user and a first drop-off location desired by the first user. In some embodiments, the route of the shared transportation service also account for a pick-up time desired by the first user and a desired drop-off time desired by the first user.

[00124] In operation 804, the transportation server 104 receives, from a client device of the first user, a first request to book the shared transportation service according to the first price. [00125] In operation 806, the transportation server 104 calculates a second price for a second user for booking the shared transportation service modified to include a second pick-up location desired by the second user and a second dropoff location desired by the second user. In some embodiments, the shared transportation service is also modified to account for a pick-up time desired by the second user and a desired drop-off time desired by the second user. It is understood that the transportation server 104 also calculates a discount price for the second user since the first user has already booked the shared transportation service according to the first price.

[00126] In operation 808, the transportation server 104 receives, from a client device of the second user, a second request to book according to the second price the shared transportation service modified to include the second pick-up location and the second drop-off location.

[00127] It is understood that, in various embodiments, any and/or all of the modules of the transportation server 104 (as illustrated in FIGS. 2 and 7) may be involved in performing operations 802, 804, 806 and 808.

[00128] FIG. 9 is a diagram showing a user booking a shared

transportation service that is currently transporting another user to a drop-off location, according to some embodiments. In some embodiments, the actions, events, calculations and route modifications discussed below with respect to FIG. 9 are performed by components of the transportation server 104 of FIGS. 2 and. 7.

[00129] FIG. 9 illustrates a first moment of time 900 at which a first user books a shared transportation service from pick-up location 902-1 to drop-off location 902-2. FIG. 9 also illustrates a second moment of time 904 at which a second user books the shared transportation service from pick-up location 906-1 to drop-off location 906-2. The second moment of time 904 at which the second user books the shared transportation service occurs after the shared

transportation service arrives at the pick-up location 902- 1 desired by the first user.

[00130] In various embodiments, the transportation server 104 dynamically modifies a route of a shared transportation service to include pick- up locations and drop-off locations requested by multiple users. The transportation server 104 receives an indication from a client device of a first user that the first user is seeking transportation from a first pick-up location 902- 1 to a first drop-off location 902-2. The transportation server 104 defines the shared transportation service according to a route from the first pick-up location 902-1 to the first drop-off location 902-2 desired by the first user.

[00131] The transportation server 104 defines the shared transportation service as available to be booked to be routed towards additional, unknown pickup locations and one or more additional, unknown drop-off locations desired by respective, unidentified additional users. Once identified by the transportation server 104, the additional users will be able to book rides on the shared transportation service. In some embodiments, one or more additional users will accompany the first user during at least a portion of the route of the shared transportation service.

[00132] Prior to identifying the additional users of the shared

transportation service, the transportation server 104 calculates a first price for the first user to book the shared transportation service to transport the first user along a route that includes the first pick-up location 902-1 and the first drop-off location 902-2. Since the shared transportation service is defined according to a route that can be dynamically modified to include pick-up and drop-off location locations of yet to be identified additional users who will join the shared transportation service, the transportation server 104 calculates the first price as a discount price. The transportation server 104 receives a first request from the client device of the first user to book the shared transportation service according to the first price.

[00133] In some embodiments, in order to calculate the first price, the transportation server 104 accesses data to determine the first price. The data may include, but is not limited to: current traffic data, past traffic data, predicted future traffic data, data that describes when and/or where other users tend to join shared transportation services, data representative of current locations of other users seeking transportation, data representative of current conditions along the route from the first pick-up location 902-1 to the first drop-off location 902-2 desired by the first user and data representative of current locations of one or more drivers.

[00134] The transportation server 104 receives an indication from a client device of a second user(s) that the second user is seeking transportation from a second pick-up location 906-1 to a second drop-off location 906-2. In order to determine a second price for the second user, the transportation server 104 dynamically modifies the shared transportation service. For example, the transportation server 104 dynamically modifies the route of the shared transportation service with respect to a current location of the shared transportation service. The route is modified to also include the second pick-up location 906-1 and the second drop-off location 906-2 desired by the second user. In some embodiments, the transportation server 104 modifies the route based at least on a current location of the shared transportation service with respect to the second pick-up location 906-1 and/or the second drop-off location 906-2 desired by the second user. In some embodiments, the transportation server 104 modifies the route based at least on a current location of the shared transportation service with respect to a pick-up time desired by the second user and/or a drop-off time desired by the second user.

[00135] The transportation server 104 calculates a second price for the second user for the modified, shared transportation service. Since the first user has already booked the shared transportation service according to the first price, the transportation server 104 calculates the second price as a discount price as well. The transportation server 104 receives a request from the client device of the second user to book the modified, shared transportation service according to the second price.

[00136] In some embodiments, the transportation server 104 calculates the second price for the second user after the shared transportation service has calculated the first price for the first user. In some embodiments, the transportation server 104 calculates the second price for the second user while the shared transportation service is currently en route to the first pick-up location 902-2. In some embodiments, the transportation server 104 calculates the second price for the second user while the shared transportation service is currently en route from the first pick-up location 902-1 to the first drop-off location 902-2 desired by the first user. In some embodiments, the

transportation server 104 calculates the second price for the second user based at least on a current location of the shared transportation service with respect to the second pick-up location 906-1 and/or the second drop-off location 906-2 desired by the second user.

[00137] In some embodiments, in order to calculate the second price for the second user, the transportation server 104 accesses and utilizes the same type of data used to determine the first price. In order to calculate a price of any additional user, the transportation server 104 accesses and utilizes the same type of data used to determine the first price. It is further understood that, in various embodiments, the transportation server 104 accesses and utilizes the same type of data used in price calculation for determining and modifying at least a portion of a route.

Ride Chaining

[00138] FIG. 10 is a diagram showing a shared transportation service dynamically modified to allow for a maximum number of users to utilize the shared transportation service. In some embodiments, the actions, events, calculations and route modifications discussed below with respect to FIG. 10 are performed by components of the transportation server 104 of FIGS 2 and. 7.

[00139] FIG. 10 illustrates a first moment of time 1000 at which a first user books a shared transportation service from pick-up location 1002-1 to dropoff location 1002-2. FIG. 10 also illustrates a second moment of time 1004 at which a second user books the shared transportation service from pick-up location 1006-1 to drop-off location 1006-2. FIG. 10 also illustrates a third moment of time 1008 at which a third user books the shared transportation service from pick-up location 1010-1 to drop-off location 1010-2. FIG. 10 also illustrates a fourth moment of time 1012 at which a fourth user books the shared transportation service from pick-up location 1014-1 to drop-off location 1014-2.

[00140] The second moment of time 1004 at which the second user books the shared transportation service occurs after the shared transportation service arrives at the pick-up location 1002-1 desired by the first user. The third moment of time 1008 at which the third user books the shared transportation service occurs after the shared transportation service arrives at the pick-up location

1006-1 desired by the second user. The fourth moment of time 1012 at which the fourth user books the shared transportation service occurs before the shared transportation service arrives at the drop-off locations 1002-2, 1006-2, 1010-2 desired by the first, second and third users.

[00141] In some embodiments, the transportation server 104 defines and/or identifies a maximum number of users that can concurrently use the shared transportation service. According to a non-limiting example, as illustrated in FIG. 10, the shared transportation service may be an automobile that has a maximum occupancy of 3 seats that can be concurrently occupied during at least a portion of a route of the shared transportation service. The transportation server 104 dynamically modifies a route of the shared transportation service so that the shared transportation service experiences the maximum occupancy during at least a portion of the route.

[00142] Reference numerals 1016 and 1018 of FIG. 10 indicate that the maximum occupancy has been reached during at least a portion of the route of the shared transportation service. Reference numeral 1016 indicates that transportation server 104 has determined a route for the shared transportation service that at least includes drop-off locations 1002-2, 1006-2, 1010-2 whereby the first, second and third users accompany each other. Reference numeral 1018 indicates that transportation server 104 has determined a modified route for the shared transportation service that includes drop-off locations 1002-2, 1010-2, 1014-2 whereby the first, third and fourth users accompany each other.

[00143] It is understood that, in various embodiments, the transportation server 104 receives a current location of the shared transportation service as the shared transportation service is en route to the drop-off location 1006-2 desired by the second user. Based on the current location of the shared transportation service, the transportation server 104 determines the shared transportation service will be under the maximum occupancy after the shared transportation service arrives at the drop-off location 1006-2.

[00144] Prior to the shared transportation service's arrival at the drop-off location 1006-2, the transportation server 104 receives an indication from a client device of the fourth user that the fourth user is seeking transportation from pick-up location 1014-1 to drop-off location 1014-2. Based on at least one of (a) the current route and (b) the current location of the shared transportation service, (c) the current time, (d) the pick-up location 1014-1, (c) the drop-off location 1014-2 and (d) additional data related to past, current and/or predicted future traffic, the transportation server 104 determines a new route for the shared transportation service that includes locations 1002-2, 1010-2, 1014-1 and 1014-2 such that the shared transportation service will again reach the maximum occupancy by having the fourth user accompany the first user and the third user (See Reference Numeral 1018).

[00145] The transportation server 104 calculates a price for the fourth user to book the shared transportation service. The transportation server 104 receives from a client device of the fourth user, a request to book according to the fourth price the shared transportation service modified to include the pick-up location 1014-1 and the drop-off location 1014-2 requested by the fourth user.

Package Delivery

[00146] It is understood that the transportation server 104 can modify a route of a shared transportation service to include a pick-up location and/or a delivery location of one or more packages. In some embodiments, route modification can be made to account for a desired pick-up time of the one or more packages and/or a desired delivery time of the one or more packages. In some embodiments, the transportation server 104 modifies a route to include a pick-up location of a package that is to be delivered at a delivery location at a desired time. The transportation server 104 may further modify the route to arrive at a pick-up location and drop-off location of one or more additional users (and/or one or more additional packages) before the delivery of the package.

Carpooling

[00147] It is understood that the transportation server 104 can modify a route of a shared transportation service based on a starting location and a destination location desired by a driver of the shared transportation service. In other words, the transportation server 104 modifies the route to account for the starting location and a destination location desired by the driver as additional users book and join the shared transportation service.

Number of Parties

[00148] It is understood that the transportation server 104 can modify a route of a shared transportation service based on a particular pick-up location desired by a plurality of additional users. In some embodiments, the plurality of additional user may also desire a same drop-off location. In other embodiments, the plurality of additional user may desire different drop-off locations even though they joined the shared transportation service at the same particular pick- up location.

[00149] It is understood that the transportation server 104 can modify a route of a shared transportation service based on a particular drop-off location desired by a plurality of additional users. In some embodiments, the plurality of additional user may join the shared transportation service at different respective pick-up locations even though they desired the same particular drop-off location.

[00150] Certain embodiments are described herein as including logic or a number of components, modules, or mechanisms. Modules may constitute either software modules (e.g., code embodied on a machine-readable medium or in a transmission signal) or hardware modules. A hardware module is a tangible unit capable of performing certain operations and may be configured or arranged in a certain manner. In example embodiments, one or more computer systems (e.g., a standalone, client or server computer system) or one or more hardware modules of a computer system (e.g., a processor or a group of processors) may be configured by software (e.g., an application or application portion) as a hardware module that operates to perform certain operations as described herein.

[00151] In various embodiments, a hardware module may be implemented mechanically or electronically. For example, a hardware module may comprise dedicated circuitry or logic that is permanently configured (e.g., as a special- purpose processor, such as a field programmable gate array (FPGA) or an application-specific integrated circuit (ASIC)) to perform certain operations. A hardware module may also comprise programmable logic or circuitry (e.g., as encompassed within a general-purpose processor or other programmable processor) that is temporarily configured by software to perform certain operations. It will be appreciated that the decision to implement a hardware module mechanically, in dedicated and permanently configured circuitry, or in temporarily configured circuitry (e.g., configured by software) may be driven by cost and time considerations.

[00152] Accordingly, the term "hardware module" should be understood to encompass a tangible entity, be that an entity that is physically constructed, permanently configured (e.g., hardwired) or temporarily configured (e.g., programmed) to operate in a certain manner and/or to perform certain operations described herein. Considering embodiments in which hardware modules are temporarily configured (e.g., programmed), each of the hardware modules need not be configured or instantiated at any one instance in time. For example, where the hardware modules comprise a general-purpose processor configured using software, the general-purpose processor may be configured as respective different hardware modules at different times. Software may accordingly configure a processor, for example, to constitute a particular hardware module at one instance of time and to constitute a different hardware module at a different instance of time.

[00153] Hardware modules can provide information to, and receive information from, other hardware modules. Accordingly, the described hardware modules may be regarded as being communicatively coupled. Where multiple of such hardware modules exist contemporaneously, communications may be achieved through signal transmission (e.g., over appropriate circuits and buses) that connect the hardware modules. In embodiments in which multiple hardware modules are configured or instantiated at different times,

communications between such hardware modules may be achieved, for example, through the storage and retrieval of information in memory structures to which the multiple hardware modules have access. For example, one hardware module may perform an operation, and store the output of that operation in a memory device to which it is communicatively coupled. A further hardware module may then, at a later time, access the memory device to retrieve and process the stored output. Hardware modules may also initiate communications with input or output devices, and can operate on a resource (e.g., a collection of information).

[00154] The various operations of example methods described herein may be performed, at least partially, by one or more processors that are temporarily configured (e.g., by software) or permanently configured to perform the relevant operations. Whether temporarily or permanently configured, such processors may constitute processor-implemented modules that operate to perform one or more operations or functions. The modules referred to herein may, in some example embodiments, comprise processor-implemented modules.

[00155] Similarly, the methods described herein may be at least partially processor- implemented. For example, at least some of the operations of a method may be performed by one or more processors or processor-implemented modules. The performance of certain of the operations may be distributed among the one or more processors, not only residing within a single machine, but deployed across a number of machines. In some example embodiments, the processor or processors may be located in a single location (e.g., within a home environment, an office environment or as a server farm), while in other embodiments the processors may be distributed across a number of locations.

[00156] The one or more processors may also operate to support performance of the relevant operations in a "cloud computing" environment or as a "software as a service" (SaaS). For example, at least some of the operations may be performed by a group of computers (as examples of machines including processors), these operations being accessible via a network (e.g., the Internet) and via one or more appropriate interfaces (e.g., application program interfaces (APIs)).

[00157] Example embodiments may be implemented in digital electronic circuitry, or in computer hardware, firmware, software, or in combinations of them. Example embodiments may be implemented using a computer program product, e.g., a computer program tangibly embodied in an information carrier, e.g., in a machine-readable medium for execution by, or to control the operation of, data processing apparatus, e.g., a programmable processor, a computer, or multiple computers. [00158] A computer program can be written in any form of programming language, including compiled or interpreted languages, and it can be deployed in any form, including as a stand-alone program or as a module, subroutine, or other unit suitable for use in a computing environment. A computer program can be deployed to be executed on one computer or on multiple computers at one site or distributed across multiple sites and interconnected by a communication network.

[00159] In example embodiments, operations may be performed by one or more programmable processors executing a computer program to perform functions by operating on input data and generating output. Method operations can also be performed by, and apparatus of example embodiments may be implemented as, special purpose logic circuitry (e.g., a FPGA or an ASIC).

[00160] The computing system can include clients and servers. A client and server are generally remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client- server relationship to each other. In embodiments deploying a programmable computing system, it will be appreciated that that both hardware and software architectures require consideration. Specifically, it will be appreciated that the choice of whether to implement certain functionality in permanently configured hardware (e.g., an ASIC), in temporarily configured hardware (e.g., a combination of software and a programmable processor), or a combination of permanently and temporarily configured hardware may be a design choice. Below are set out hardware (e.g., machine) and software architectures that may be deployed, in various example embodiments.

[00161] FIG. 11 is a block diagram of a machine in the example form of a computer system 1100 within which instructions, for causing the machine to perform any one or more of the methodologies discussed herein, may be executed. In alternative embodiments, the machine operates as a standalone device or may be connected (e.g., networked) to other machines. In a networked deployment, the machine may operate in the capacity of a server or a client machine in server-client network environment, or as a peer machine in a peer-to- peer (or distributed) network environment. The machine may be a personal computer (PC), a tablet PC, a set-top box (STB), a Personal Digital Assistant (PDA), a cellular telephone, a web appliance, a network router, switch or bridge, or any machine capable of executing instructions (sequential or otherwise) that specify actions to be taken by that machine. Further, while only a single machine is illustrated, the term "machine" shall also be taken to include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein.

[00162] Example computer system 1100 includes a processor 1102 (e.g., a central processing unit (CPU), a graphics processing unit (GPU) or both), a main memory 1104, and a static memory 1106, which communicate with each other via a bus 1108. Computer system 1100 may further include a video display device 1110 (e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)). Computer system 1100 also includes an alphanumeric input device 1112 (e.g., a keyboard), a user interface (UI) navigation device 1114 (e.g., a mouse or touch sensitive display), a disk drive unit 1116, a signal generation device 1118 (e.g., a speaker) and a network interface device 1120.

[00163] Disk drive unit 1116 includes a machine-readable medium 1122 on which is stored one or more sets of instructions and data structures (e.g., software) 1124 embodying or utilized by any one or more of the methodologies or functions described herein. Instructions 1124 may also reside, completely or at least partially, within main memory 1104, within static memory 1106, and/or within processor 1102 during execution thereof by computer system 1100, main memory 1104 and processor 1102 also constituting machine-readable media.

[00164] While machine-readable medium 1122 is shown in an example embodiment to be a single medium, the term "machine-readable medium" may include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) that store the one or more instructions or data structures. The term "machine -readable medium" shall also be taken to include any tangible medium that is capable of storing, encoding or carrying instructions for execution by the machine and that cause the machine to perform any one or more of the methodologies of the present technology, or that is capable of storing, encoding or carrying data structures utilized by or associated with such instructions. The term "machine-readable medium" shall accordingly be taken to include, but not be limited to, solid-state memories, and optical and magnetic media. Specific examples of machine-readable media include non- volatile memory, including by way of example semiconductor memory devices, e.g., Erasable Programmable Read-Only Memory (EPROM), Electrically Erasable Programmable Read-Only Memory (EEPROM), and flash memory devices; magnetic disks such as internal hard disks and removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks.

[00165] Instructions 1124 may further be transmitted or received over a communications network 1126 using a transmission medium. Instructions 1124 may be transmitted using network interface device 1120 and any one of a number of well-known transfer protocols (e.g., HTTP). Examples of communication networks include a local area network ("LAN"), a wide area network ("WAN"), the Internet, mobile telephone networks, Plain Old Telephone (POTS) networks, and wireless data networks (e.g., WiFi and WiMAX networks). The term "transmission medium" shall be taken to include any intangible medium that is capable of storing, encoding or carrying instructions for execution by the machine, and includes digital or analog communications signals or other intangible media to facilitate communication of such software.

[00166] Although an embodiment has been described with reference to specific example embodiments, it will be evident that various modifications and changes may be made to these embodiments without departing from the broader scope of the technology. Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense. The accompanying drawings that form a part hereof, show by way of illustration, and not of limitation, specific embodiments in which the subject matter may be practiced. The embodiments illustrated are described in sufficient detail to enable those skilled in the art to practice the teachings disclosed herein. Other embodiments may be utilized and derived therefrom, such that structural and logical substitutions and changes may be made without departing from the scope of this disclosure. This Detailed Description, therefore, is not to be taken in a limiting sense, and the scope of various embodiments is defined only by the appended claims, along with the full range of equivalents to which such claims are entitled. [00167] Such embodiments of the inventive subject matter may be referred to herein, individually and/or collectively, by the term "invention" merely for convenience and without intending to voluntarily limit the scope of this application to any single invention or inventive concept if more than one is in fact disclosed. Thus, although specific embodiments have been illustrated and described herein, it should be appreciated that any arrangement calculated to achieve the same purpose may be substituted for the specific embodiments shown. This disclosure is intended to cover any and all adaptations or variations of various embodiments. Combinations of the above embodiments, and other embodiments not specifically described herein, will be apparent to those of skill in the art upon reviewing the above description.