Patent Application
20240022884
On-demand mobility is a trend in transportation services today. On-demand mobility relates to moving people, goods, or services with the assistance of a computer, such as an application operable on a mobile computing device, that allows for ease of scheduling and payment. On-demand mobility services can bring convenience to user's lives. In some cases, the security and privacy of users can be diminished with this convenience.
In a general aspect, a method includes receiving, through the user interface of a user device of a user, a request for a ride from the user; assigning a driver to provide the ride for the user; according to one or more application rules associated with the request for the ride, providing the driver with access to information uniquely identifying the user or a rider.
Embodiments can include one or more of the following features.
Providing the driver with access to the information includes providing the driver with access based on a location of the driver, in which the application rules define the location at which the driver is to be provided with access.
The method includes providing the driver with access to the information at a pick-up location for the ride.
Providing the driver with access to the information includes providing the driver with access for a limited period of time, the limited period of time being specified by one or more of the application rules.
The method includes causing destruction of the information according to one or more of the application rules.
The method includes causing destruction of the information after the driver has accessed the information.
The method includes receiving, from a mobile device operated by the driver, a current fingerprint of the user; and in which providing the driver with access to the information includes providing the driver with information indicative of results of a comparison between the current fingerprint of the user or rider and a stored fingerprint of the user or rider.
The method includes providing the driver with access to one or more instructions associated with the ride according to one or more of the application rules.
The instructions include one or more of audio instructions, video instructions, image instructions, and text instructions.
In an aspect, a method includes receiving, through the user interface of a user device of a user, a request for a ride from the user; assigning a driver to provide the ride for the user; according to one or more application rules associated with the request for the ride, providing the user with access to information uniquely identifying the driver.
Embodiments can include one or more of the following features.
The information uniquely identifying the driver includes a visual code.
The visual code includes a pattern of colors.
The method includes providing the visual code to a mobile device associated with the driver.
The visual code is randomly generated based on the one or more application rules and in which the randomly generated visual code is synchronized between the mobile device associated with the driver and a mobile device associated with the user.
The visual code provided to the mobile device is configured to be displayed with one or more lights mounted on a vehicle operated by the driver.
The method includes receiving, from a mobile device operated by the user, a current fingerprint of the driver; and in which providing the driver with access to the information includes providing the driver with information indicative of results of a comparison between the current fingerprint of the driver and a stored fingerprint of the driver.
In an aspect, a method includes during transportation of a rider by a driver in a ride arranged by a computer-implemented driver assignment platform, implementing one or more rules to enable an image of the rider to be transmitted to one or more of an operator of the computer-implemented driver assignment platform and a supervisor of the rider.
Embodiments can include one or more of the following features.
Enabling an image of the rider to be transmitted includes streaming a live video of the rider.
The method includes adjusting the bandwidth of the streaming video by upscaling or downscaling of video during live video streaming.
Enabling an image of the rider to be transmitted includes capturing pictures or bursts of pictures of the rider and the car and transmitting the pictures or the bursts of pictures.
The method includes enabling transmission of a map depicting a predicted route of the ride and a current approximate location of the rider on the map.
The method includes preventing one or more functions of a device of the driver from being operational during the ride.
The method includes enabling the rider to generate a panic alert, using a rider device, responsive to a distress situation occurring during the ride.
In an aspect, a method includes during transportation of a user by a driver in a ride arranged by a computer-implemented driver assignment platform, receiving information indicative of a location of the ride; implementing one or more application rules to compare the received information indicative of a location of the ride with information indicative of an allowed boundary of the ride; and generating an alert when the location of the ride deviates from the allowed boundary of the ride.
Embodiments can include one or more of the following features.
The method includes establishing a geo-fence for the ride defining an area around the expected path of the ride, the geo-fence being based on the one or more application rules associated with the rider; and generating the alarm when the ride leaves the area defined by the geo-fence.
In on-demand transportation services, in which a service provider (e.g., a driver) takes a service receiver (e.g., a rider) from one point to another in a private vehicle, the security of users and riders are important. The approaches described here enable users and drivers to securely identify each other to ensure that a requested ride is provided by the intended driver to the intended driver. The approaches described here also enable monitoring of the status or behavior of the driver and/or the rider during the ride, e.g., via streaming video, images, or audio. The approaches described here also enable monitoring of the location of the driver's vehicle during the ride.
Referring to
Multiple drivers 160 are enrolled with the on-demand and scheduling service system 150. Responsive to receiving the user's request 156 for a ride, the on-demand and scheduling service system 150 selects a particular driver 160a from among the multiple drivers 160 and assigns that driver 160a to provide the ride for the user 152 or the rider 154. The on-demand and scheduling service system 150 can select the particular driver 160a from among the multiple drivers 160 based on an indication of the trust that the user 152 has for each of one or more of the drivers 160. For instance, the particular driver 160a selected by the on-demand and scheduling service system 150 for the user 152 can be the driver who is the most trusted by the user 152, based on one or more metrics of trust, such as based on a circle of trust for the user and/or based on a trust barometer value for the driver. In some examples, the on-demand and scheduling service system 150 can determine an indication of the trust that the user 152 has for each of the one or more drivers 160 upon receipt of the user's request 156 for a ride. In some examples, the indication of trust can be pre-determined and stored in a data storage associated with the on-demand and scheduling service system. Further description of trust-based selection of drivers can be found in U.S. application No. [Attorney Docket No. 42480-0002001], the entire contents of which are incorporated here by reference.
One or more measures can be implemented by the on-demand and scheduling service system 150 to maintain the safety and security of the rider 154 during the ride. In some examples, the driver 160 can be subject to one or more background checks 170. In some examples, the system 150 can enable identity verification 172 to ensure that the driver 160 picks up the intended rider 154 and that the rider 154 accepts a ride with the intended driver 160. For instance, the driver 160 can be provided with information to verify the identity of the user 152 or the rider 154 at pick-up, or the user 152 can be provided with information to verify the identity of the driver 160 at pick-up. The system 150 can facilitate the transmission of images or video of the rider 154 in real time 174 to the user 152 or to another third party during the ride to allow the user or third party to monitor the status of the rider 154. The system 150 can monitor the ride 176, such as the location of the driver's vehicle, and transmit an alert to the user 152 or to another third party if an unexpected action is taken, such as if the driver 160 deviates from an expected route for the ride.
In some examples, to maintain the safety and security of riders using the on-demand and scheduling service system 150, the drivers 160 can be verified and background checked, e.g., upon registration with the system, periodically, or at random intervals. For instance, during a driver's registration with the on-demand and scheduling service system 150, each driver completes a screening process. One or more activities can be performed in this screening process to verify the driver, such as collection and verification of the driver's personal information and documentation, interviews, trainings, mentoring by a coach, background checks, Department of Motor Vehicles (DMV) checks, reference checks, or other activities. Particulars of the driver's license, vehicle insurance, motor vehicle records, social security number, federal, county, or multi-state criminal records can also be verified.
In some examples, the user 152 can be provided with information to verify the identity of the driver, for instance, to verify that the driver 160 who has arrived to pick up the rider 154 is the same driver that was assigned to the user's requested ride 156. The information can include personal information, such as a name, photograph, demographic information, or other personal information. The information can include information about the driver's vehicle, such a description of the vehicle (e.g., a make and model of the vehicle), a photograph of the vehicle, the vehicle's license plate, or other information about the vehicle.
In some examples, fingerprints of a driver can be taken, such as at the time of registration. The fingerprints can be taken through the driver's computing device or at a central facility, such as a registration facility, and stored in a database of the on-demand and scheduling service system 150. When the driver 160 arrives to pick up the rider 154, the user 152 can obtain the driver's fingerprints, e.g., via the user's mobile device, and the system 150 can compare the obtained fingerprints with the stored fingerprints of the driver who is scheduled for the ride. If the fingerprints match, the driver 160 is verified as the correct driver.
In some examples, the on-demand and scheduling service system 150 can provide the driver 160 and the user 152 with a code 178 that uniquely identifies the driver 160. The driver 160 and the user 152 can compare their codes at pick-up to ensure that the driver 160 is picking up the correct rider 154 and that the rider 154 is accepting a ride with the correct driver 160. The code 178 can be a visual code, such as a pattern of colors. The code can be a static code or a dynamic code, e.g., a pattern of changing colors. In some examples, the code can be displayed on the user interface of a mobile device operated by each of the driver 160 and the user 152. In some examples, the driver's vehicle can be equipped with one or more lights that light up or flash to display the code on the driver's vehicle, thus helping the user 152 to identify the driver's vehicle even at a crowded pick-up location.
In some examples, the driver 160, the rider 154, or both can be monitored during the ride by the on-demand and scheduling service system 150, and information obtained by the monitoring can be provided to the user 152 or to a third party, such as a system administrator of the system 150. The monitoring can include capturing video and/or still images of the driver 160, the rider 154, or both, continuously throughout the ride or at regular or random intervals, and providing the captured video and/or images to the user 152 or third party. The monitoring can include monitoring driver behavior, such as speed, acceleration, use of mobile devices, or other behavior. The monitoring can include monitoring the route of the driver's vehicle during the ride. In some examples, if the driver's vehicle deviates from an expected route, an alert can be provided to the user 152 or to a third party.
Each of the server 35 and the client device 54 of the system 150 can include an application logic device 16, 17, a communication module 28, 29, a data access controller 41, and a data handling module 44, 45. For example, when the client device 54 receives input though a user interface 10 of the client device 54, the communication module 28 can send the instructions for processing server-side by the application logic 17 of the server 35, or the instructions can be parsed and processed by the application logic 16 of the client device 54.
Each of the server 35 and the client device 54 of the system 150 include application logic devices 16, 17. The application logic devices 16, 17 include data processors for managing instructions of the application, determining the application state, processing inputs to the application from the user, and fetching or obtaining application rules for determining functionality of the application of the system 150. In some examples, the application of the system 150 is a program running on the client device 54 and/or the server 35 for performing the functions described herein.
The application logic module 16, 17 includes an app state manager 18, 19, a user notification rules module 20, 21, and the application rules module 22, 23. The app state manager 18, 19 monitors and controls the state of the application, which can determine content of a response sent by the application in response to input by the user or data received by the application. The user notification rules module 20, 21 determines when notifications, such as alerts, SMS messages, emails, alarms, push notifications, etc. are sent to the user. The application rules module determines which rules are applied during operation of the application as described in further detail below. The application rules engine includes rulesets that are both static, such as static rules 24, 25, and configurable by a user, such as configurable rules 26, 27.
The application rules engine communicates with the internal communication interface 36, 37. The internal communication interface 36, 37 manages requests and responses from various modules of the server 35 or client device 54 of the system 150. For example, when data is requested from the functional database 48, 49, the internal communication interface 37, 38 can send a request for the data, receive the data in response, and route the data to the appropriate requesting module.
The communications module 28, 29 includes either a client communication module 31 or a sever communication module 30 for the server 35 and client device 54, respectively. The client communication module 31 includes a client request manager 33 for handling (e.g., queueing, parsing, etc.) requests from the client device 54. The server communication module 30 includes a server request manager 32 for handling (e.g., queueing, parsing, etc.) requests from the server 35.
Video broadcasting managers 110, 111 use the data retriever components 50, 51 of the data access controller 40, 41 to broadcast the live video of rider according to application rules 22, 23. Data creator components 42, 43 are used to store this video data in the functional database 48 of the on-demand and scheduling service system 150. Data update modules 112, 113 and data delete modules 55, 56, can be used for managing, updating, deleting, and maintaining data of the data module 44, 45, such as according to application rules 22, 23.
The data module 44, 45 stores and organizes data of the server 35 and client device 54 as required by the application rules 22, 23. For example, data for users can be stored in the function database 48, 49, such as demographic data of users, riders, etc. User preferences can be stored, such as preferred routes, no-go zones, geo-fences, a trusted driver list for that user, an image of the user, saved pickup instructions, and so forth. The data module 44, 45 also handles file system data 52, 53 required for running the application, such as system files and the like.
The client device 54 includes a user interface 10. The user interface 10 can be a touch screen, display, monitor, and so forth. The user can input commands via the user interface and otherwise interact with the application of the system 150 using the user interface 10. The user interaction manager 12 and user interface manager 14 are described in greater detail below.
A user (e.g., a customer or requestor) as described here refers to an individual who makes a service request to the on-demand and scheduling service system 150. The service provider can be an individual or entity that can provide the service requested by user. The service receiver can be an individual to whom the requested services are provided. A user or customer, using a customer device, can request an on-demand or scheduling service which can be a transport service, a telegram service, food delivery service, or a messenger service. The on-demand and scheduling service system 150 can communicate with the service providers using the provider devices and arrange for them to provide the requested service.
User inputs making up the request for a ride are converted into data by a client device 54 and sent to the on-demand and scheduling service system 150. In some examples, the client device 54 includes a mobile computing device, such as a smart phone, tablet, smart watch, and so forth. In some examples, a user's device, a driver's device, a rider's device, etc. can be a client device 54. In some examples a portion of the data that is sent to the system is relies on user input, and other information might be fetched from the client device 54 that the user is using. In some examples, more information might be fetched from the functional database 48. The request can be sent out of the device through a network 38 interface of the client-end computing device 54.
The inputs given by the user in the client device 54 can be received by a user interaction manager 12 that is a component of a user interface 10. In some examples, the user interaction manager 12 forwards the user's request to an internal communication interface 34 for sending it to the on-demand and scheduling service system 150 according to application rules 22 (e.g., data processing rule), discussed below. The application rules 22 can either be static 24 or configurable 26. Along with this request there can be data related to the request. For example, in addition to the data sent by the client device 54 there is some data that are already present in the on-demand and scheduling service system 150. There are also data present in a functional database 48 which can include the trust-related data of a user for one or more drivers. Some data can be directly collected from the driver when the driver registers with the service, and some data can be updated after registration. For instance, data can be updated by the driver or based on actions taken or reviews received by the driver. The trust-related data is stored in the database of the on-demand and scheduling service system 150. After receiving the request sent by the client device 54, the on-demand and scheduling service system 150 verifies one or more components of the request, such as for whom the ride request is made, pick-up or drop-off locations, time of pick-up (such as whether the ride is requested for now or scheduled for a later time), that only one ride is requested for a rider at one time, or other components of the request. In one example, the on demand and scheduling service system 150 can forward the user's request to the driver who is most trusted by the user and/or to one or more drivers having trust of the user for acceptance or the request. Forwarding can be done using the data that was sent to the on-demand and scheduling service system 150 by the client device 54 of the user, and the data that is already present in the functional database 48. The on-demand and scheduling service system 150 can notify the user that a response is requested from the user's trusted driver to accept the user's ride request.
In some examples, the on-demand and scheduling service system 150 can maintain photographs of riders, users, drivers, and/or other people. For instance, the user can take a photograph of a rider (e.g., a child) using the camera component of the user's client device 54 or can use a previously taken photograph. The picture can be sent to the on-demand and scheduling service system 150 through the network 38 interface of the client device 54 of the user, e.g., upon registration of the user or rider or upon the user requesting the ride. A data retriever 50 component of the data can access the controller 40 from the on-demand and scheduling service system 150 through the server request manager 32. The user interface manager 14 of the client device 54 of the driver can be used to display the rider's picture to the driver according to application rules 22. In some examples, video instructions or permissions (discussed below) can be recorded, e.g., using the camera hardware component of the user's device. The on-demand and scheduling service system 150 can send these instructions to the client device 54 of the driver through the network 38 interface of the device according to the application rules 22.
Capabilities of the on-demand and scheduling service system 150 can be accessible to the user, the driver, or both through an interface of an application executed on a mobile device. Through the interface, the user can provide instructions, confirm the identity of the driver, monitor the progress of a ride, or take other actions. Through the interface, the driver can view the user's instructions, confirm the identity of the user or rider, or take other actions.
In some examples, information about the user or rider can be provided to the driver prior to the beginning of the ride, e.g., when the driver is selected to provide a ride to the user. Referring to
In some examples, information about the driver assigned to provide a ride for a user can be provided to the user prior to the beginning of the ride. Referring to
Referring to
In some examples, the driver can be provided with information and instructions relevant to the requested ride. For instance, the information and instructions can help the driver to identify the user and/or the rider. The information and instructions can be provided to the driver as images, video, audio, or text, or in another form. In some examples, the information and instructions are provided to the driver according to one or more rules, e.g., default rules or rules established by the user. For instance, the rules can govern when the driver can have access to the information and instructions, how many times the driver can access the information and instructions, what happens to the information and instructions after having been accessed by the driver, and so forth.
In some examples, the user can be provided with information to verify the identity of the driver, e.g., to ensure that the rider accepts a ride from the driver who has been assigned for that rider. The information can help the user to identify the driver and/or the driver's vehicle. The information can include information about the assigned driver, such as the driver's name or picture and/or other information. The information can include information about the driver's vehicle, such as a description of the vehicle (e.g., make and model of the car, car color, or other description), a photograph of the vehicle, the vehicle's license plate number, and/or other information. The information can include fingerprints of the driver. The information can include a visual identifier, such as a visual code to be displayed on the driver's mobile device or vehicle that can be matched to a visual code displayed on the user's mobile device. In some examples, the information to verify the identity of the driver can be provided according to one or more rules, e.g., default rules or rules established by the user. For instance, a user who is less concerned about security can set rules such that identity verification of the driver is performed only by confirming the license plate number of the driver's car. A user who is more concerned about security can set rules such that identity verification of the driver is performed by a combination of license plate verification, fingerprint verification, and verification of a visual code displayed on the driver's vehicle.
Referring to
In some examples, the pickup interface 84 for a driver can include information 86 identifying the rider and information 88 identifying a supervisor of the rider, such as the user who requested the ride, a person supervising the rider at the pick-up site, a person who will receive the rider at the drop-off site, or another supervisor. The information 86, 88 can include the name of the rider and/or supervisor, phone number of the supervisor, photographs of the rider and/or supervisor, information regarding the relationship between the rider and the supervisor, and so forth. In some examples, the driver can verify the identity of the rider by scanning the rider's fingerprints, as discussed below. Verification of the rider's identity helps ensure that the driver is picking up the rider for whom the ride is intended, and that the rider remains in the care of an appropriate person. For instance, a photograph of the rider can help the driver to recognize the rider, e.g., if the pick-up location is crowded, and also serves as verification of the identity of the rider and helps to ensure that the driver picks up the proper rider.
The interface 84 can include controls 90, 92, 94 for viewing video, audio, or text instructions, respectively, provided by the user with the request for the ride. Pictures of instructions can also be provided and accessed by a control. Example instructions can include requests for photographs, videos, audio, text messages, or other types of information to be sent to the user or another third party upon pick-up, during the ride, and/or at drop-off.
In some examples, the instructions or permissions for a ride can be date- and time-stamped such that a driver knows that he is viewing up-to-date instructions or permissions. In some examples, the instructions or permissions have access limitations, e.g., the instructions or permissions can be accessed by the driver only at certain times, such as once the driver accepts the ride, once the driver arrives at the pick-up location, or at other times. In some examples, the instructions or permissions can self-destruct, e.g., after access by the driver, after a certain amount of time, or at a certain point in the ride (e.g., after pick-up of the rider or after drop-off of the rider). The time for destruction of the pictures, video, or other information can be set by default or can be specified by the user. Self-destruction helps to ensure that the instructions or permissions are not shared or misused. In addition, self-destruction of instructions helps to ensure that instructions are not erroneously used for a subsequent ride, e.g., a ride provided by the driver to another user or to the same user. In an example, the driver can be shown a photograph of the rider only once the driver arrives at the pick-up location. The rider's photograph can self-destruct once the driver indicates that the rider has been picked up. These access permissions and self-destruction provide the driver with enough time to find the rider at the pick-up location but do not allow the driver any time to otherwise handle the photograph.
Fingerprint verification can be performed by scanning one or more fingerprints scanner component of a device, such as the user's device or the driver's device. In some examples, the user can scan the driver's fingerprints to verify the driver's identity; in some examples, the driver can scan the rider's fingerprints to verify the rider's identity or can scan the fingerprints of a person receiving the rider at the drop-off location to verify that the receiving person is authorized to have custody of the rider.
The scanned fingerprints can be matched with one or more original fingerprints of the driver stored in a database of the on-demand and scheduling service system 150, such as the functional database 48. For instance, when the driver's fingerprints are scanned through user's device at pick-up, the server request manager 32 can retrieve the driver's original fingerprints from the functional database 48 using the data retriever 50 component of the data access controller 40. If the scanned fingerprints match the stored fingerprints, the user can allow the driver to pick up the rider.
Referring to
In some examples, the system can generate a unique visual code and provide the code to both the driver and the user. Matching of the driver's code to the user's code can help the user to confirm that the driver is the driver assigned to the user's ride and can help the driver to confirm that the rider is the person to whom the driver is assigned. In some examples, the visual code can be a pattern of colors that can be compared visually, e.g., by the driver, the user, or the rider. In some examples, the visual code can be a scannable code, such as a bar code or a QR code, that can be scanned by a device (e.g., the driver's device) and matched by an automated determination.
Referring to
In some examples, the visual code can be a static code that does not change. In some examples, the visual code can be a dynamic code that changes with time. The changes in the visual code can occur concurrently in the pattern 182 on the user's user interface and in the pattern displayed on the driver's user interface or the driver's vehicle. The visual code and/or the changes to a dynamic visual code can be randomly generated by the on-demand scheduling and service system 150.
The lights on the driver's vehicle can be solar powered or battery powered. The lights can have a communication component, such as a Bluetooth™ or a wireless sensor installed which can connect the lights with a program or application that is stored and operated on the driver's mobile device to receive the visual code. In some examples, ZigBee, Z-Wave or other such communication protocols can be used to connect the lights with the driver's device.
Referring to
In some examples, the driver's behavior can be monitored during the ride. Monitoring the driver's behavior can include monitoring driving behavior such as speed or acceleration (e.g., sudden acceleration or braking), monitoring the driver's use of his mobile device (e.g., whether the driver makes or takes calls, sends text messages, browses the internet, or other activities), or monitoring other types of data. Data indicative of the driver's behavior can be stored in a database of the on-demand scheduling and service system 150. The data indicative of the driver's behavior can be analyzed and used to determine a rating of the driver, such as a trustworthiness of the driver, that can be used, e.g., in determining the driver's trust barometer value.
In some examples, the driver's behavior can be controlled during the ride. Controlling the driver's behavior can include controlling the driver's driving behavior, such as preventing the driver from driving above a certain speed, preventing the driver from using sudden acceleration or braking, or preventing the driver from taking other actions. Controlling the driver's behavior can include controlling the driver's use of his mobile device, such as preventing the driver from making or taking calls, sending text messages, browsing the internet, or taking other actions. In some examples, the driver's behavior can be controlled according to default rules. In some examples, the user can define rules to be used to control the driver's behavior. For instance, a user may want to allow the driver to accept phone calls so that the user can call the driver to discuss the status of the rider, but may want to prevent the driver from using his mobile device in any other way.
In some examples, the status or behavior of the driver, the rider, or both can be monitoring by video and/or still images of the rider and/or driver. The video and/or still images can be transmitted in real-time or near real-time to the user or to another person. In some examples, the route of the ride can be tracked in real-time or near real-time and the tracking information transmitted to the user or to another person.
In some examples, when the ride begins, the on-demand and scheduling service system 150 begins capturing live video of the rider, e.g., through a camera hardware component of the driver s device or through a freestanding camera mounted in the driver's vehicle. The on-demand scheduling and service system facilitates broadcasting of the live video to the user or to another party, such as to an operations center of the on-demand and scheduling service system 150 and/or any to other individual designated by the user to watch the video streaming of the ride. For instance, the on-demand and scheduling service subsystem can implement one or more interfaces, e.g., a Web interface 128, a mobile application interface 102, or another type of interface, to broadcast live video of the ride and to enable tracking the route of the ride on a map 108. One or more of these interfaces can be made available to the user, to a customer support center, and/or to other individuals selected by the user to enable monitor his/her rider by watching live video streaming. Video data of the ride is processed through an internal communication interface 34 according to application rules 22 and sent to the on-demand and scheduling service system 150 through a network interface 38 of the client device 54 of the driver. A data creator component 42 can be operated to store the video data in the functional database 48 of the on-demand and scheduling service system 150. A video broadcasting manager 110 uses the data retriever 50 component of the data access controller 40 to broadcast the live video of rider according to application rules 22. A user interaction manager 12 enables the user and/or other individuals designated by the user to watch live video streaming of rider in one or more client devices 54. The video of the rider recorded during the ride can be stored in the functional database 48 of the on-demand and scheduling service system 150 and can be utilized in situations like accidents and other emergencies, or can be streamed but not stored, or both.
Referring to
Referring to
In some examples, the on-demand and scheduling service system 150 can allow the user or the rider or both to choose a person, such as a friend or a family member, to monitor their ride in real time by watching the live video streaming, viewing the broadcasted pictures, tracking the ride on map, or monitoring in another way. Users have full control over who can watch and track the ride. When a user generates a ride request, one or more service options can be displayed by the on-demand and scheduling service system 150 so that the user can choose from service options and designate a person (e.g., someone they trust) to share the ride details with and to allow them to watch the live video of their ride. The on-demand and scheduling service system 150 can send a notification to the designated individual, such as to the designated individual's mobile computing device. The designated individual can start tracking the rider on a map and monitoring video streaming of the rider from the pickup location to the drop off location for on demand rides, scheduled rides, or both.
In some examples, the on-demand and scheduling service system 150 can provide functionality to enable the rider to generate a panic alert if a distress situation occurs. For instance, the on-demand and scheduling service system 150 enables a user (e.g., an adult user) to create a family password by using a program or application that is operated on his/her mobile computing device and share the family password within his/her family. This family password is stored in the on-demand and scheduling service system 150 and can be visible to the support team of the system. During the ride if any kind of distress situation occurs the rider can send a panic alert to a customer support team by pressing a button displayed in the program or application that is operated on the rider's mobile computing device. Upon receipt of a panic alert, the support team can call the rider and ask for the family password. If it is wrong, the support team may determine that the rider is in distress and inform a law enforcement agency.
In some examples, the on-demand and scheduling service system 150 can provide geo-fencing functionality that generates an alert if the driver deviates from a prescribed route for a ride. Referring to
The alert can be a visual alert (e.g., using color coding), an audio alert, or another type of alert. A support team administering the on-demand scheduling and service system 150 can be alerted and can call the rider and/or the driver to request an explanation for the deviation. If the deviation from declared path is not legitimate, the support team can inform a law enforcement agency and provide the exact location of the vehicle.
Referring to
Referring to
Referring to
Application rules 22 are a component of data processing logic of a program or application which controls the overall flow of data processing through the program or application. Application rules 22 are a formal expression of application functionality for a state of the application, and the application rules 22 determine how data can be created, stored, changed, accessed or displayed through an application or program in response to one or more inputs.
An example of an application rule can include the process for selecting a driver responsive to a user's request for ride. For instance, when the user sends a request for ride, the on-demand and scheduling service system 150 selects and assigns a trusted driver and forwards the user request to that driver. The selection of driver and the forwarding of the user's request to the selected driver is performed according to configurable application rules, such as rules specifying a threshold distance from the pick-up within which drivers available to be selected by the on-demand and scheduling service system 150 should be currently located. For instance, the on-demand and scheduling service system 150 may consider only those drivers currently located within a 3 mile radius of the pick-up location for selection.
An example of an application rule relates a process for enabling a driver to accept a user's request for ride. For instance, configurable application rules can specify a time threshold within which a selected driver is to accept the user's request for ride. For instance, when the system forwards the user's request for ride to a selected driver, the driver can accept this request according to configurable application rules. For example, the driver can only accept the request within 15 seconds after receiving it.
An example of an application rule relates to notifications to a user about a driver's estimated arrival time. When a driver accepts the user's request for ride and leaves for the pick-up location, the user is notified about the driver's estimate arrival time. These notifications are sent according to configurable application rules. For example, the on-demand and scheduling service system 150 notifies the user when the driver is estimated to be 10 minutes away and again when the driver is estimated to be 5 minutes away.
An example of an application rule relates to instructions or permissions. When a user requests a ride, the user can provide secure text, audio, video instructions/permissions for pick-up. Configurable application rules can specify criteria for these instructions or permissions, such as maximum file sizes, maximum durations, a maximum number of separate instructions, or other criteria. For instance, audio or video instructions can be recorded according to one or more configurable application rules specifying that the audio or video length can be no more than, e.g., 10, 15, or 20 seconds.
An example of an application rule relates to driver viewing of instructions or permissions. Configurable application rules can specify criteria related to where the driver is allowed to view the instructions or permissions, the number of times the driver is allowed to view the instructions or permissions, the amount of time the driver is allowed to spend viewing the instructions or permissions, or other criteria. For instance, an application rule may specify that the driver can only view the instruction or permissions after reaching the pick-up location. For instance, the application rule may specify that the driver can view the instructions only once and for a maximum interaction time of 20 seconds.
The memory 1720 stores information within the system 1700. In some examples, the memory 1720 is a non-transitory computer-readable medium. In some examples, the memory 1720 is a volatile memory unit. In some examples, the memory 1720 is a non-volatile memory unit.
The storage device 1730 is capable of providing mass storage for the system 1700. In some examples, the storage device 1730 is a non-transitory computer-readable medium. In various different examples, the storage device 1730 may include, for example, a hard disk device, an optical disk device, a solid-date drive, a flash drive, or some other large capacity storage device. The input/output device 1740 provides input/output operations for the system 1700. In some examples, the input/output device 1740 may include one or more of a network interface devices, e.g., an Ethernet card, a serial communication device, e.g., an RS-232 port, and/or a wireless interface device, e.g., an 802.11 card, a 3G wireless modem, or a 4G wireless modem. In some examples, the input/output device may include driver devices configured to receive input data and send output data to other input/output devices, e.g., keyboard, printer and display devices 1760. In some examples, mobile computing devices, mobile communication devices, and other devices may be used.
In some examples, at least a portion on-demand and scheduling service system 150 can be realized by instructions that upon execution cause one or more processing devices to carry out the processes and functions described above. Such instructions may include, for example, interpreted instructions such as script instructions, or executable code, or other instructions stored in a non-transitory computer readable medium. The storage device 1730 may be implemented in a distributed way over a network, such as a server farm or a set of widely distributed servers, or may be implemented in a single computing device.
Although an example processing system has been described in
The term “system” may encompass all apparatus, devices, and machines for processing data, including by way of example a programmable processor, a computer, or multiple processors or computers. A processing system may include, in addition to hardware, code that creates an execution environment for the computer program in question, e.g., code that constitutes processor firmware, a protocol stack, a database management system, an operating system, or a combination of one or more of them.
A computer program (also known as a program, software, software application, script, executable logic, or code) may be written in any form of programming language, including compiled or interpreted languages, or declarative or procedural languages, and it may be deployed in any form, including as a standalone program or as a module, component, subroutine, or other unit suitable for use in a computing environment. A computer program does not necessarily correspond to a file in a file system. A program may be stored in a portion of a file that holds other programs or data (e.g., one or more scripts stored in a markup language document), in a single file dedicated to the program in question, or in multiple coordinated files (e.g., files that store one or more modules, sub programs, or portions of code). A computer program may be deployed to be executed on one computer or on multiple computers that are located at one site or distributed across multiple sites and interconnected by a communication network.
Computer readable media suitable for storing computer program instructions and data include all forms of non-volatile or volatile memory, media and memory devices, including by way of example semiconductor memory devices, e.g., EPROM, EEPROM, and flash memory devices; magnetic disks, e.g., internal hard disks or removable disks; magneto optical disks; and CD ROM and DVD ROM disks. The processor and the memory may be supplemented by, or incorporated in, special purpose logic circuitry. Computers used in the system may be general purpose computers including mobile devices, custom-tailored special purpose electronic devices, or combinations of the two.
Examples may include a back end component, e.g., a data server, or a middleware component, e.g., an application server, or a front end component, e.g., a client computer having a graphical user interface or a Web browser through which a user may interact with an example of the subject matter described is this specification, or any combination of one or more such back end, middleware, or front end components. The components of the system may be interconnected by any form or medium of digital data communication, e.g., a communication network. Examples of communication networks include a local area network (“LAN”) and a wide area network (“WAN”), e.g., the Internet.
Certain features that are described above in the context of separate examples may also be implemented in combination in a single example. Conversely, features that are described in the context of a single example may be implemented in multiple examples separately or in any sub-combinations.
The order in which operations are performed as described above may be altered. In certain circumstances, multitasking and parallel processing may be advantageous. The separation of system components in the examples described above should not be understood as requiring such separation.
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. Present embodiments are described here in detail with reference to the accompanying drawings, and the on-demand and scheduling service system 150 is not limited to these particular embodiments. The on-demand and scheduling service system 150 has been described in terms of particular embodiments and applications, and preceding description contains significant details. It should not be interpreted as limiting the scope of the on-demand and scheduling service system 150 but rather as providing illustrations of the preferred embodiments of the on-demand and scheduling service system 150, and it will be understood that many substitutions, changes and variations in the described embodiments, applications and details of the method and system illustrated herein and of their operation can be made by those skilled in the art without departing from the spirit of this description.
Other implementations are also within the scope of the following claims.
This application is a continuation and claims the benefit of priority under 35 USC § 120 of U.S. application Ser. No. 17/222,179, filed on Apr. 5, 2021, which is a continuation of U.S. application Ser. No. 15/337,808, filed on Oct. 28, 2016 (now U.S. Pat. No. 10,972,884), which claims priority under 35 USC § 119(e) to U.S. Application Ser. No. 62/248,687, filed on Oct. 30, 2015, the entire contents of which are hereby incorporated by reference.
| Number | Date | Country | |
|---|---|---|---|
| 62248687 | Oct 2015 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 17222179 | Apr 2021 | US |
| Child | 18104406 | US | |
| Parent | 15337808 | Oct 2016 | US |
| Child | 17222179 | US |
