US20210398180A1 - Method and system for ride shares involving hierarchical driver referrals - Google Patents
Method and system for ride shares involving hierarchical driver referrals Download PDFInfo
- Publication number
- US20210398180A1 US20210398180A1 US17/464,453 US202117464453A US2021398180A1 US 20210398180 A1 US20210398180 A1 US 20210398180A1 US 202117464453 A US202117464453 A US 202117464453A US 2021398180 A1 US2021398180 A1 US 2021398180A1
- Authority
- US
- United States
- Prior art keywords
- driver
- rideshare
- passenger
- server
- mobile
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
- 238000000034 method Methods 0.000 title claims abstract description 102
- 230000004044 response Effects 0.000 claims description 7
- 230000008569 process Effects 0.000 description 82
- 238000010586 diagram Methods 0.000 description 10
- 230000009471 action Effects 0.000 description 8
- 230000015654 memory Effects 0.000 description 7
- 239000008186 active pharmaceutical agent Substances 0.000 description 6
- 238000004891 communication Methods 0.000 description 6
- 238000012795 verification Methods 0.000 description 6
- 230000000717 retained effect Effects 0.000 description 5
- 238000004590 computer program Methods 0.000 description 3
- 238000005516 engineering process Methods 0.000 description 3
- 238000012545 processing Methods 0.000 description 3
- 230000007423 decrease Effects 0.000 description 2
- 210000003811 finger Anatomy 0.000 description 2
- 230000006870 function Effects 0.000 description 2
- 239000003550 marker Substances 0.000 description 2
- 230000003287 optical effect Effects 0.000 description 2
- 210000004935 right thumb Anatomy 0.000 description 2
- 238000003491 array Methods 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 230000008901 benefit Effects 0.000 description 1
- 238000004364 calculation method Methods 0.000 description 1
- 238000012423 maintenance Methods 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 238000010295 mobile communication Methods 0.000 description 1
- 238000010200 validation analysis Methods 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q30/00—Commerce
- G06Q30/06—Buying, selling or leasing transactions
- G06Q30/0601—Electronic shopping [e-shopping]
- G06Q30/0609—Buyer or seller confidence or verification
-
- G—PHYSICS
- G01—MEASURING; TESTING
- G01C—MEASURING DISTANCES, LEVELS OR BEARINGS; SURVEYING; NAVIGATION; GYROSCOPIC INSTRUMENTS; PHOTOGRAMMETRY OR VIDEOGRAMMETRY
- G01C21/00—Navigation; Navigational instruments not provided for in groups G01C1/00 - G01C19/00
- G01C21/26—Navigation; Navigational instruments not provided for in groups G01C1/00 - G01C19/00 specially adapted for navigation in a road network
- G01C21/34—Route searching; Route guidance
- G01C21/3407—Route searching; Route guidance specially adapted for specific applications
- G01C21/3438—Rendez-vous, i.e. searching a destination where several users can meet, and the routes to this destination for these users; Ride sharing, i.e. searching a route such that at least two users can share a vehicle for at least part of the route
-
- G—PHYSICS
- G01—MEASURING; TESTING
- G01C—MEASURING DISTANCES, LEVELS OR BEARINGS; SURVEYING; NAVIGATION; GYROSCOPIC INSTRUMENTS; PHOTOGRAMMETRY OR VIDEOGRAMMETRY
- G01C21/00—Navigation; Navigational instruments not provided for in groups G01C1/00 - G01C19/00
- G01C21/26—Navigation; Navigational instruments not provided for in groups G01C1/00 - G01C19/00 specially adapted for navigation in a road network
- G01C21/34—Route searching; Route guidance
- G01C21/36—Input/output arrangements for on-board computers
- G01C21/3697—Output of additional, non-guidance related information, e.g. low fuel level
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q10/00—Administration; Management
- G06Q10/02—Reservations, e.g. for tickets, services or events
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q50/00—Systems or methods specially adapted for specific business sectors, e.g. utilities or tourism
- G06Q50/30—Transportation; Communications
- G06Q50/32—Post and telecommunications
-
- G06Q50/40—
-
- G06Q50/60—
-
- G—PHYSICS
- G07—CHECKING-DEVICES
- G07B—TICKET-ISSUING APPARATUS; FARE-REGISTERING APPARATUS; FRANKING APPARATUS
- G07B15/00—Arrangements or apparatus for collecting fares, tolls or entrance fees at one or more control points
- G07B15/02—Arrangements or apparatus for collecting fares, tolls or entrance fees at one or more control points taking into account a variable factor such as distance or time, e.g. for passenger transport, parking systems or car rental systems
-
- G—PHYSICS
- G07—CHECKING-DEVICES
- G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
- G07C2209/00—Indexing scheme relating to groups G07C9/00 - G07C9/38
- G07C2209/02—Access control comprising means for the enrolment of users
Definitions
- the present disclosure relates generally to vehicle rideshares. More specifically, embodiments of the present disclosure relate to systems and methods for facilitating vehicle rideshare involving a computerized hierarchical driver referral system and a biometric scan-based authentication of a rideshare driver's identity.
- rideshare systems have become available as another source of transportation.
- passengers request a ride from a driver by using an app on the passenger's mobile device.
- the mobile app communicates with a server managed by a rideshare system or service and provides information about the passenger's location.
- the server sends out a request to drivers in the general vicinity of the passenger's location, and also informs the passenger of average pickup times for drivers in the vicinity.
- the passenger selects a driver and an associated vehicle, the passenger is provided with the driver's information such as a name, a phone number, and an expected time of arrival.
- the passenger's credit card or debit card typically stored in a database coupled to the rideshare server
- rideshare systems do not provide adequate security measures to protect passengers. For example, an unauthorized person can impersonate a ride share driver and provide a ride to an unsuspecting passenger. Another concern is that known rideshare systems do not utilize technology effectively to adequately incentivize new drivers to become part of the riding sharing service.
- FIG. 1 illustrates an example system for facilitating rideshares utilizing a ride share management server.
- FIG. 2 illustrates example registration screens of a mobile device interface for registering drivers with an embodiment of the ride share management server, according to an embodiment of the present invention.
- FIG. 3 illustrates a mobile device interface for receiving biometric information from drivers, according to an embodiment of the present invention.
- FIG. 4 illustrates a schematic of discrete pairwise operations involving a driver's mobile app, a passenger's mobile app, a ride share management server, a navigation API, and a geocoding server associated with start of a trip, according to an embodiment of the present invention.
- FIG. 5 illustrates a schematic of discrete pairwise operations involving a driver's mobile app, a passenger's mobile app, a ride share management server, a passenger portal, and a geocoding server associated with end of a trip, according to an embodiment of the present invention.
- FIG. 6 illustrates a schematic of operations associated with a driver's mobile app according to an embodiment of the present invention.
- FIG. 7 illustrates a flow diagram showing method steps by a mobile app for registering a driver according to an embodiment of the present invention.
- FIG. 8 illustrates a flow diagram showing method steps by a mobile app running on a driver's mobile device in connection with a driver offering to provide a rideshare trip according to an embodiment of the present invention.
- FIG. 9 illustrates a flow diagram showing method steps by a mobile app running on a passenger's mobile device in connection with a passenger availing a rideshare trip, according to an embodiment of the present invention.
- FIG. 10 illustrates a flow diagram showing method steps by a rideshare server identifying referral chains according to an embodiment of the present invention.
- FIG. 11 illustrates several example mobile device interface screens of a driver's mobile app according to an embodiment of the present invention.
- FIGS. 12-14 illustrate example interfaces showing earnings accumulated via a driver's referral chain according to an embodiment of the present invention.
- FIG. 15 illustrates an example interface displaying a driver's earnings history according to an embodiment of the present invention.
- FIG. 16 illustrates an example interface showing a passenger's trip history according to an embodiment of the present invention.
- FIG. 17 illustrates an example interface showing a passenger's pickup location with respect to a rideshare driver's location displayed on a map according to an embodiment of the present invention.
- FIGS. 18-19 illustrate example interfaces linked to a driver database according to an embodiment of the present invention.
- FIG. 20 illustrates an example interface linked to a passenger database according to an embodiment of the present invention.
- FIGS. 21-22 illustrate example interfaces for a network marketer to access the rideshare server via a network marketer portal, according to an embodiment of the present invention.
- the inventive disclosure provided herein generally relates to systems and methods for authenticating ride share drivers using a biometric sensor.
- a driver When a driver initially registers with the rideshare service, the driver is prompted to provide biometric information via a mobile app running on the driver's mobile device.
- the biometric information is then stored in a database with a ride share management server in a file associated with the driver's account.
- the server performs an authentication check based on the pre-stored biometric information.
- the driver provides his or her biometric information to the ride share management server via a mobile application on the driver's mobile device.
- This information is then checked against the stored biometric information in the networked database to authenticate the identity of the driver. If authenticated, the driver receives pick-up information, including the passenger's pickup location and desired destination. In the meantime, the ride share management server notifies the passenger about the details of the rideshare driver and the rideshare vehicle via the mobile app on the passenger's mobile device. Once the driver arrives at the pickup location of the passenger and picks up the passenger, the ride share trip starts.
- the biometric information is stored inside non-volatile memory in or coupled to the driver's mobile device. Subsequently, when offering a rideshare trip, an identity of a driver who offers the rideshare trip is checked (by the mobile app running on the driver's mobile device) against the stored biometric information to authenticate the identity of the driver. However, the comparison of the biometric information received versus the pre-stored biometric information is performed by the rideshare server. Thus, in such implementations, the stored biometric information is transmitted from the driver's mobile device to the rideshare server, prior to the comparison.
- Drivers' mobile devices are configured to enable drivers to provide biometric information via a sensor coupled to or otherwise configured within a driver's respective mobile device.
- a biometric scan can include, for example, fingerprint, voice, iris recognition, or a combination thereof.
- a driver's mobile device, a passenger's mobile device, or both can be configured to enable receipt of biometric scans, process such scans to determine if the scan was successful, and transmit such scans to a ride share management server.
- the ride share management server compares the biometric scan of a driver offering to provide a ride share trip against a stored biometric scan to authenticate the identity of the driver.
- the biometric scan of a driver can be stored along with other types of driver information such as a name, license information, social security number, car information, picture of driver and the car, ride history of the driver accumulated over time, criminal background check, driver ratings by passenger, etc.
- a data structure associated with a driver enables storage and manipulation of different types and formats (e.g., alphabetical, numeric, alphanumeric, etc.) of data about a driver.
- a passenger can access some of the data relating to a driver. For example, a passenger can access such information at the start of a trip until the trip is over.
- the inventive disclosure relates to a computerized method and system for facilitating increased rideshare revenue generation by creating referral chains for a driver when a previously-registered driver (e.g., “Driver A”) refers a proposed new driver (e.g., “Driver B”) to the rideshare service and the proposed new driver then registers with the rideshare service.
- the referral chain can provide additional revenue for the previously-registered driver by accumulating a percentage of earnings from the proposed new driver.
- This referral chain can span a number of levels (e.g., five levels of referrals).
- a driver who has been referred by a registered driver is prevented from being referred by another registered driver.
- a registered driver who refers a new driver provides a referral ID to that is used by the proposed new driver when signing up with the rideshare service.
- a registered driver notifies the ride share management server that he or she has provided a referral ID to the new driver. Accordingly, when the new driver registers with the rideshare service, the new driver may be required to provide the referral ID provided by the registered driver.
- Such a methodology can prevent occurrences where a new driver has been referred by a registered driver but does not provide the referral ID provided by the registered driver in an attempt to avoid sharing his or her earnings with the referring driver.
- a mobile app running on a referring (registered) driver's mobile device is updated to show the referral chain. That is, data relating to the new driver is transferred to the registered driver's mobile app.
- embodiments of the present disclosure enable push notifications to be received by an app running on a driver's mobile device.
- the app running on a driver's mobile device can be configured to receive notifications on-the-fly from a ride share management server.
- the referral chain of the registered driver can be stored on the registered driver's mobile app, and additionally in a database associated with the rideshare service.
- an electronic payment is processed such that requisite funds amounting to the cost of a ride are transferred from a passenger's financial institution to the rideshare service.
- a driver who provided the ride can receive 85% of the cost of a ride, and the remaining 15% is retained by the rideshare service.
- details relating to a passenger's financial institution are stored in a passenger database associated with the rideshare service when the passenger registers with the rideshare service.
- the rideshare service retains a percentage from each driver in a referral chain.
- the registered driver who has referred the subject driver also earns a percentage of the earnings.
- driver 2 earns 85% of the cost of the ride.
- the remaining 15% is divided between the rideshare service and driver 1 .
- the driver who provided the ride earns 85% of the cost of a ride.
- the remaining 15% is divided among the rideshare service and the other driver(s) in the referral chain, according to certain percentages.
- the rideshare service retains 15% of driver 1 's earnings, 11% of driver 2 's earnings, 8.5% of driver 3 's earnings, 7% of driver 4 's earnings, and so on. Similarly, driver 1 earns 4% of driver 2 's earnings, 2.5% of driver 3 's earnings, 1.5% of driver 4 's earnings, and so on. (These percentages can vary, and are examples for discussion purposes only.)
- payments from a passenger's financial institution can be processed via a third payment processor acting as an intermediary between the passenger's financial institution and the rideshare service.
- the inventive disclosure relates to a computerized method and system for creating referral chains when a network marketer refers a proposed new driver to the rideshare service and the proposed new driver then registers with the rideshare service.
- a network marketer as used herein, is an individual or an entity that is not a registered driver of the rideshare service.
- a referral chain started by a network marketer can provide a revenue generation stream for the network marketer by accumulating a percentage of earnings from the proposed new driver.
- Referral chains by network marketers can have features and functionalities that are similar to referral chains by drivers. For example, the referral chain can span a number of levels (e.g., five levels of referrals).
- a network marketer who refers a new driver provides a referral ID that is used by the proposed new driver when signing up with the rideshare service.
- a network marketer notifies the rideshare management server that he or she has provided a referral ID to the new driver. Accordingly, when the new driver registers with the rideshare service, the new driver may be required to provide the referral ID provided by the network marketer.
- a network marketer can access the rideshare service via a network marketer portal for providing information to the rideshare server, checking earnings/invoices as a result of earnings from rideshare drivers that are part of the network marketer's referral chain, etc. Percentages of earnings from a network marketer-referred driver can, in some embodiments, be similar or different than driver-referred scenarios discussed above.
- FIG. 1 illustrates an example system where a rideshare management server 130 facilitates providing ride share trips to passengers 114 in vehicles driven by ride share drivers 112 .
- Passengers 114 and ride share drivers 112 own, operate, or otherwise have access to mobile devices 122 . Determining a trip can, in some embodiments, involve queries to a geocoding server 116 .
- a payment processor 120 is used to disburse payments to ride share drivers based on the cost of a rideshare trip.
- a passenger can pay the cost of a rideshare trip using a debit card or a credit card associated with a financial institution server 118 .
- ride share management server 130 which can be referred to as the “rideshare server,” can be a single server or a plurality of interconnected servers that are configured to exchange information. Further, such a server or a plurality of servers can be cloud-based or can be physical servers.
- a passenger 114 is waiting at a geographical location for a rideshare driver 112 to arrive and pick up the passenger 114 .
- Passenger 114 requests rideshare server 130 for a ride share trip by launching a mobile application on the passenger's mobile device 122 .
- the request typically includes information relating to the passenger's geographical location (e.g., latitude longitude) obtained via a location mechanism (e.g., a GPS sensor) on the passenger's mobile device 122 and an intended destination provided by the passenger 114 .
- a passenger 114 can request an estimated cost of the rideshare trip from the rideshare server 130 .
- a mobile application associated with the rideshare service can function dually as a mobile application for a passenger 114 as well as that for a driver 112 .
- the same mobile application can be used for both purposes.
- the terms “a mobile application running on a driver's mobile device,” “a driver's mobile app,” and “a driver app” would be considered analogous.
- the terms “a mobile application running on a passenger's mobile device,” “a passenger's mobile app,” and “a passenger app” would be considered analogous.
- a driver 112 in the vicinity offering to provide a rideshare trip launches a mobile application on the driver's mobile device 123 .
- the mobile application requests the driver 112 to provide his or her biometric information to the rideshare server 130 every time a driver launches the mobile application for offering a rideshare trip.
- a driver's mobile device 123 can be configured to enable a driver 112 to provide biometric information via a sensor coupled to or otherwise configured within a driver's respective mobile device 123 .
- a biometric scan can include, for example, fingerprint, voice, or iris recognition, or a combination thereof.
- the driver's mobile device 123 can be configured to enable receipt of biometric scans, process such scans to determine if the scan was successful, and transmit such scans to a rideshare server 130 .
- the rideshare server 130 checks the biometric information provided by the driver offering to provide the ride share trip against the stored biometric information in a networked database to authenticate the identity of the driver 112 .
- the driver 112 is provided with the destination of the passenger 114 and a pickup location of the passenger 114 .
- the passenger 114 is notified of details of the rideshare driver 112 and the rideshare vehicle, via the mobile app on the passenger's mobile device 122 , by the rideshare server 130 .
- the ride share server 130 can provide the passenger 114 with a name and contact information (e.g., phone number, email, etc.) of the driver 112 , a photograph of the driver 112 , a make, year, model and photograph of the vehicle that the driver 112 is driving.
- the rideshare server 130 provides an estimate of the rideshare trip to the passenger 114 .
- the wait time for the passenger 114 waiting for the rideshare driver 112 to arrive at the passenger's pickup location is typically a couple of minutes or less.
- the driver 112 arrives at the pickup location of the passenger 114 , picks up the passenger 114 and the ride share trip starts.
- a trip starts when a driver clicks on a button to start a trip using the mobile application running on the driver's mobile device 123 .
- more than one driver can respond to rideshare server 130 with an offer to provide a rideshare trip to passenger 114 .
- the ride share server 130 can choose a driver 112 randomly, or can choose a driver 112 who is closest to the passenger 114 .
- the rideshare server 130 communicates with a geocoding server 116 to provide real time navigation directions to the driver 112 , on the way to the passenger's destination.
- a rideshare server 130 can query (e.g., via an API call) the geocoding server 130 with the intended destination provided by the passenger 114 to obtain the real time navigation directions.
- the geocoding server provides the navigation directions (e.g., route information of the rideshare trip on a map) to the rideshare server 130 which is conveyed in real time to a mobile application running on the driver's mobile device 123 , and optionally to the passenger's mobile device 122 .
- the mobile application running on the driver's mobile device 123 can also compute information relating to a net distance traveled from the passenger's pickup location, a time of travel, etc. Such information can be used to calculate a total cost of the rideshare trip.
- geocoding server 116 performs some or all of these computations, and provides the same to the mobile application running on the driver's mobile device 123 .
- a passenger 114 goes through a one-time registration process (usually at any time before the first rideshare trip of the passenger 114 ) in which the passenger 114 provides his or her details, e.g., name, email, phone number, credit/debit card information, name of a financial institution associated with the credit/debit card, etc. to the rideshare server 130 .
- information relating to a passenger 114 is stored in a networked database (e.g., as a data structure) and can be viewed and/or edited by the passenger 114 via a passenger portal module 134 accessible by any electronic device connected to the Internet, including the mobile application running on the passenger's mobile device 122 .
- the mobile application running on the passenger's mobile device 122 stores a copy of the passenger's personal and financial information.
- the rideshare trip ends.
- Information relating to the rideshare trip e.g., duration of trip, distance traveled, route taken, etc. is also obtained by the mobile application running on the driver's mobile device 123 .
- the mobile application running on the driver's mobile device 123 calculates the total cost of the rideshare trip, e.g., on the basis of a monetary value per unit time of rideshare travel.
- such information is communicated to the rideshare server 130 .
- the rideshare server 130 typically provides that information (partially or entirely) to the mobile application running on the passenger's mobile device 123 .
- the mobile application on the passenger's mobile device 123 also provides an option to pay a tip to the rideshare driver 114 .
- a passenger 112 can approve of the payment of the cost of the trip via the mobile application running on the passenger's mobile device 123 .
- the mobile application running on the driver's mobile device 123 goes offline, for example, breaks off communication with the rideshare server 130 when a trip ends.
- a driver who wishes to offer to provide a subsequent rideshare trip re-launches the mobile application, and re-scans his or her biometric information for authentication.
- the rideshare server 130 Upon receiving the passenger's approval, in some embodiments, the rideshare server 130 communicates with a payment processor 120 (typically via an API call).
- Payment processor 120 is a third party financial services provider that allows both private individuals and businesses to accept payments over the Internet. For example, the payment processor 120 can initiate payment transactions associated with payment of the cost of the trip from the passenger's financial institution server 118 .
- a second driver 112 shares his or her earnings with a first driver 112 in a scenario in which the first driver 112 has referred the second driver 112 to sign up with the rideshare service as a driver.
- embodiments of the disclosed system facilitate the creation of referral chains which can provide residual income to drivers, after funds amounting to the cost of a rideshare trip is received from a passenger's financial institution.
- the rideshare server 130 includes a backend module 132 , a passenger portal module 134 , a driver portal module 136 , and a network marketer portal module 138 .
- the passenger portal module 134 and the driver portal module 136 are accessible by electronic devices such as mobile devices, laptops, desktops, tablet PCs, etc. connected to the Internet as well as mobile devices including but not limited to the driver's mobile device 122 , passenger's mobile device 123 , the geocoding server 116 , and the payment processor 120 .
- the network marketer portal module 138 is accessible via the web only, and not via mobile applications on mobile devices.
- the network marketer portal module 138 can be accessible via mobile applications running on mobile devices.
- the network marketer portal module 136 can, for example, be accessed by a network marketer module to provide information about a proposed new driver to the rideshare server 130 , or even directly refer a proposed new driver via the network marketer portal module 136 .
- a network marketer can also receive referral IDs generated by the rideshare server 130 to be shared or sent (e.g., via a social media network or in an email communication) to the proposed new driver.
- embodiments of the present disclosure enable both drivers 112 and passengers 114 to view their profile and affiliated information using a passenger portal module 134 and a driver portal module 136 hosted by the rideshare service.
- a passenger portal module 134 and a driver portal module 136 hosted by the rideshare service.
- both passengers and drivers can respectively view their profile information, their trip history, their payment history, their invoices, etc.
- the back end module 132 is typically involved in calculation of payments, maintenance and manipulation of passenger and driver data stored in networked databases, etc.
- functionalities of the back end module 132 can, in whole or in part, be performed by one or more of the portal modules disclosed herein, and vice versa.
- the rideshare server 130 can include a single module for performing various functionalities.
- Examples of mobile devices 122 and 123 include but are not limited to tablets, mobile smart phones, personal digital assistants, wearable consumer devices, etc. These mobile devices can run, for example, the popularly-known ANDROIDTM IPHONETM, and WINDOWSPHONETM platforms. It will be understood that there is no limitation imposed on the number of mobile devices, mobile device types, brands, vendors and manufacturers that may be used with embodiments of the present disclosure.
- Electronic data communications between elements shown in FIG. 1 can be achieved via one or more networks 110 , such as, but not limited to, a Local Area Network (LAN), Wireless Local Area Network (WLAN), Personal area network (PAN), or wireless wide area network (WWAN), enabled with technologies such as Global System for Mobile Communications (GSM), Personal Communications Service (PCS), Bluetooth, Wi-Fi, Fixed Wireless Data, 2G, 2.5G, 3G, 3G LTE, LTE Advanced, 4G, general packet radio service (GPRS), messaging protocols such as, TCP/IP, SMS, MMS, instant messaging, or any other wireless data networks or messaging protocols.
- networks 110 such as, but not limited to, a Local Area Network (LAN), Wireless Local Area Network (WLAN), Personal area network (PAN), or wireless wide area network (WWAN), enabled with technologies such as Global System for Mobile Communications (GSM), Personal Communications Service (PCS), Bluetooth, Wi-Fi, Fixed Wireless Data, 2G, 2.5G, 3G, 3G LTE, LTE Advanced, 4G, general packet radio service (GPRS), messaging
- the landmark server 130 includes functionality to allow it to communicate, for example, by using application programming interfaces (APIs), with various elements shown in FIG. 1 .
- APIs application programming interfaces
- FIG. 2 illustrates exemplary registration screens of a mobile device interface for registering drivers with an embodiment of the rideshare server, according to an embodiment of the present invention.
- a mobile application running on a driver's mobile device displays screen 210 .
- Screen 210 shows various exemplary driver-related information fields such as a name field, a date of birth field, a gender field, a country field, a city field, an address field, and an email id field.
- the date of birth information can be used to determine an age of the driver, such that drivers under the age of twenty-one, for instance, are not allowed to sign up as drivers with the rideshare service.
- the mobile application displays a message “You are Not Eligible to Drive.”
- a driver clicks on a “Next” button to land at screen 220 .
- the mobile application displays a message on the screen of the mobile device.
- the email id provided by the registering driver is in a wrong format, then the mobile application displays a message “Incorrect Email ID format.”
- Screen 210 also shows an option for a driver to upload his or her photograph via the mobile application running on the driver's mobile device, e.g., either by taking a photograph via the camera on the mobile device or uploading a pre-stored photograph saved in a memory of the mobile device.
- Screen 220 shows various exemplary fillable information fields of a vehicle that can be used to provide a rideshare trip.
- Example of such fields shown in screen 220 are a vehicle number, a type of vehicle, a license number of the driver, a registration number of the vehicle, an insurance policy number of the vehicle, a license expiration date of the driver, a registration expiration date of the driver, an insurance expiration date, etc.
- Screen 220 also shows an option for uploading a photograph of the vehicle.
- Screen 230 shows a driver's bank-related information such as a bank name and a bank account number, for receiving earnings associated with a ride share trip.
- Screen 230 also shows details to be filled by a driver for payments involving a (third party) payment processor.
- a driver can enter the information on the displayed registration screens 210 , 220 , and 230 and edit them if he or she desires. Such information is finally communicated from the mobile application running on the driver's mobile device to the rideshare server 130 , after the driver clicks a “Submit” button.
- the mobile application displays a message “All Fields are Mandatory.”
- information provided by a driver during a registration process is communicated to the rideshare server 130 for storage in a database.
- the rideshare server 130 keeps track of various dates, e.g., dates of registration renewal, license renewal, insurance renewal etc. Accordingly, in such embodiments, the rideshare server 130 sends an email to the driver in advance of the renewal date(s) so that the driver can take necessary actions.
- FIG. 3 illustrates a mobile device interface for receiving biometric information from drivers, according to an embodiment of the present invention.
- Screen 310 used for entering a driver's bank information for receiving earnings associated with a rideshare trip is similar to screen 230 shown in FIG. 2 .
- Screen 320 shows a predetermined scanning area on the screen of a driver's mobile device.
- the predetermined scanning area is a region inside which a driver can place his or her finger (right thumb, for example) in connection with providing the driver's biometric information.
- Drivers' mobile devices are configured to enable drivers to provide biometric information via a sensor coupled to or otherwise configured within a driver's respective mobile device.
- Screen 330 shows a message displayed on the screen of a driver's mobile indicating that the mobile application is processing an image associated with the biometric scan of a driver's finger. If the mobile application on the driver's mobile device determines that the biometric scan was successful, screen 340 shows an option to save the biometric scan. In some optional embodiments, as shown in screen 340 , the mobile application on the driver's mobile device can provide an option to re-take another biometric scan. In some embodiments, information provided by a driver during a registration process is communicated to the rideshare server 130 for storage in a database. In some embodiments, some or all of the information provided by a driver during a registration process can be saved on the driver's mobile device.
- FIG. 3 also displays a portion of a computer-implemented interface 350 that is linked to a database which stores the driver's biometric information.
- Interface 350 displays, for example, a driver (“provider”) with an id “ 1 ,” a name “Josh” having a biometric scan 360 linked to his employee account.
- Embodiments of the disclosed system utilize the biometric scan to authenticate the identity of a driver any time the driver launches the mobile application.
- Interface 350 also displays additional driver-related details such as a phone number, a linked photograph of a driver, a total number of trips that the driver has offered, and an approval status corresponding to whether the driver was approved by the system based on his background and driving history.
- Interface 350 also provides a drop-down menu displaying selectable actions that can be taken by an individual viewing this interface.
- FIG. 3 displays fingerprint recognition as a biometric
- embodiments of the disclosed system can also different types of biometric scan, such as, fingerprint, voice, or iris recognition, or a combination thereof.
- FIG. 4 illustrates a schematic indicating operations involving a driver's mobile app 402 , a passenger's mobile app 408 , a rideshare server 130 , a navigation API 440 , and a geocoding server 116 associated with start of a trip, according to an embodiment of the present invention. It is noted that the operations shown in FIG. 4 are not necessarily performed in a sequence or in an order of any sort.
- a driver who offers to provide a rideshare trip provides a biometric scan via the driver's mobile app.
- the biometric scan is compared against a pre-stored scan of the driver stored in the driver's mobile phone.
- the pre-stored scan can be a scan provided by the driver at the time of registration.
- the process of comparing the biometric scan received from a driver with the pre-stored scan can, in some embodiments, be performed by the driver's mobile app 402 . In some other embodiments, the driver's mobile app transmits the biometric scan to rideshare server 130 for comparison against a pre-stored scan.
- a driver receives the passenger's pickup location and the passenger's intended destination from geocoding server 116 (or, in some embodiments, from the rideshare server 130 ) displayed on a map.
- the driver's mobile app 402 integrates the received information updating the map displayed on the driver's mobile device with, for example, a real-time indication of the driver's location and the passenger's pickup location.
- the driver app 402 can display a marker on a map corresponding to the driver's location and the passenger's pickup location. Further, as the driver travels towards the passenger's pickup location, the driver marker is shown to accordingly move on the map.
- the driver app 402 sends ( 416 ) real-time information relating to the updated map, e.g., displaying the markers to the geocoding server 116 .
- the geocoding server transfers the information received from the driver app 402 to the rideshare server 130 in real time.
- the driver app 402 sends real-time information relating to the updated map, e.g., displaying the markers directly to the rideshare server 130 . It will be understood and appreciated that functionalities wherein the rideshare server 130 obtains a driver's real-time location allow the rideshare server 130 to track the driver's location.
- the driver Upon detecting that the driver has reached the location, the driver receives (at step 424 ) a notification of a start of a trip from the rideshare server 130 .
- a driver first informs (via the driver's mobile app 402 ) the rideshare server 130 that he or she has arrived at the passenger's pickup location before receiving a notification of a start of the trip from the rideshare server 130 .
- the rideshare server 130 is notified of the driver's input via the driver app 402 .
- the passenger app 408 receives a notification of a start of a trip from the rideshare server 130 .
- the driver app 402 sends (step 428 ) a passenger's pickup location and intended destination of the passenger to a navigation API 440 .
- the navigation API 440 guides the driver by providing (step 432 ) turn-by-turn directions to the intended destination.
- FIG. 5 illustrates a schematic indicating discrete pairwise operations involving a driver's mobile app 502 , a passenger's mobile app 528 , a rideshare server 130 , a web portal 134 , and a geocoding server 116 associated with end of a trip, according to an embodiment of the present invention. It is noted that the operations shown in FIG. 5 are not necessarily performed in a sequence or in an order of any sort.
- geocoding server 116 provides (step 506 ) information relating to a driver's current location, intended destination of the rideshare trip, a total time traveled, a total distance traveled, toll locations on the driver's route, etc. to the rideshare server 130 .
- the rideshare server 130 Upon detecting that the driver has arrived at the intended destination, the rideshare server 130 informs (step 510 ) the driver's mobile app that the driver has arrived at the intended destination.
- the driver's mobile app 502 responds (step 514 ) to the rideshare server 130 that the rideshare trip has ended. Accordingly, an invoice reflecting a summary of the rideshare trip is sent (step 522 ) by the rideshare server to the passenger's mobile device.
- a passenger can optionally provide (step 526 ) a tip amount and a rating/comments for the driver, via the passenger's mobile app 528 .
- rideshare server 130 provides (step 518 ) information relating to the rideshare trip, e.g., an invoice, a type of vehicle used, a distance traveled, a tip amount paid by the passenger to the driver, a rate per unit distance of travel that is used to calculate the fare, etc.
- This information can, in some embodiments, be provided to either or both of the driver and the passenger's account, which can be accessed via web portal 134 , e.g., a driver web portal for a driver and a passenger web portal for a passenger.
- FIG. 6 illustrates exemplary operations associated with a driver's mobile app associated with authenticating an existing driver's identity, according to an embodiment of the present invention.
- step 602 displays a mobile screen displaying an interface to capture a biometric scan of a driver's right thumb for authentication of a driver's identity.
- the biometric scan provided is compared against a driver's pre-stored biometric scan.
- the comparison is performed at the driver's mobile device.
- a rideshare server 130 performs the comparison, after receiving the biometric scan provided by the driver via the mobile app.
- FIG. 6 also displays operations associated with a driver's mobile app, after a driver is authenticated successfully.
- a driver logs in using login credentials such as a login id/password on his or her mobile device. The driver's credentials are verified (step 610 ).
- step 612 If the driver indicates that he or she has forgotten (step 612 ) their credentials, then an automated reset credentials link is sent to the driver by the rideshare server 130 via email. If a driver's credentials are successfully verified, then the driver is allowed (step 616 ) access to the main screen of the mobile app. Otherwise, a driver is not allowed (step 618 ) access. In some embodiments, a driver is provided a unsuccessful verification message, if the driver's credentials are not verified successfully.
- FIG. 7 illustrates a flow diagram showing method steps of a process 700 by a mobile app for registering a driver on a mobile application running on a driver's mobile device, according to an embodiment of the present invention.
- the process determines whether the driver chooses to register and provide his or her information via the mobile app.
- a driver can choose to register via a third party app such as a social media network app, in lieu of, or in addition to, utilizing the mobile app (associated with the presently disclosed system) for entering his or her information.
- the process can receive a driver's information from one or more respective third parties.
- the disclosed system allows driver referrals in which an existing driver can refer a proposed driver to the system.
- the process determines (for example, based on information received from rideshare server) whether the registering driver has been referred by another driver, at step 706 . If the process determines that the registering driver has been referred by another driver, then the process jumps to step 722 and continues thereafter.
- the process moves to step 708 in which the mobile app receives information pertaining to the driver and the associated vehicle.
- the mobile app running on the driver's mobile device also provides information identifying the driver's mobile device and the mobile app.
- the mobile app can provide a mobile device's International Mobile Equipment Identity (IMEI) number, a mobile app ID, a type and version of the operating system running on the driver's mobile device, the operating system ID of the driver's mobile device, etc.
- IMEI International Mobile Equipment Identity
- the process displays a message on the screen of the driver's mobile device requesting the driver to provide a biometric scan.
- the biometric scan is processed (at step 714 ).
- the mobile app applies image processing methodologies to determine the edges, boundaries, minutiae of the biometric scan.
- a biometric scan may not be correctly processed, for example, due to unrecognized artifacts in the biometric scan, or when the information in the biometric scan is not sufficient.
- the process determines (at step 716 ), if the scan is successful. If the scan is successful, the process moves to step 718 in which information relating to the scan is sent to the rideshare server 130 .
- step 720 the process displays (at step 720 ) a message on the screen of the mobile device indicating that registration was successful, and the process terminates thereafter.
- the process determines (at step 734 ) whether the process requests the registering driver to provide a referral ID.
- the process determines (at step 724 ) whether the registering driver submitted a referral ID, or not.
- a driver casually entering information via the mobile app may inadvertently enter an option indicating he or she has been referred by another driver, but then realize later that the option was incorrectly entered. In such scenarios, the driver may not have a referral ID to provide.
- the process (at step 724 ) whether the registering driver submitted a referral ID, or not.
- the mobile app communicates the referral ID to the rideshare server 130 .
- the server sends verification information to the mobile app verifying (or, denying) the validity of the referral ID.
- This functionality is to prevent a referral ID from being used multiple times or being used by unrecognized individuals associated with the referral ID, thereby preventing fraud.
- the process determines if the verification for the referral ID was successful, at step 730 . If the verification was successful, the process moves to step 734 in which the referral chain setting in the driver's mobile app is updated.
- the referral chain setting in the driver's mobile app can reflect the name of the driver who referred the registering driver, a number of hierarchical levels included in the referral chain of the registering driver, etc. If, however, verification of the referral ID was unsuccessful (at step 730 ), the mobile app provides (at step 732 ) the option to the registering driver to re-enter the referral ID, and the process loops back to step 722 .
- FIG. 8 illustrates a flow diagram showing method steps of a process 800 by a mobile app running on a driver's mobile device in connection with a driver offering to provide a rideshare trip, according to an embodiment of the present invention.
- the process displays a message on a driver's mobile device requesting the driver to provide a biometric scan.
- the driver's mobile app stays offline unless the driver provides his or her biometric scan.
- the biometric scan is processed (at step 804 ).
- the mobile app applies image processing methodologies to determine the edges, boundaries, minutiae of the biometric scan.
- a biometric scan may not be correctly processed, for example, due to unrecognized artifacts in the biometric scan, or when the information in the biometric scan is not sufficient.
- the process determines (at step 806 ), if the scan is successful. If the scan is successful, the process moves to step 808 in which information relating to the scan is sent, in some optional embodiments, to the rideshare server 130 . If, however, the scan is not successful, the process lops back to step 802 in which the driver is requested to provide a biometric scan.
- the process receives (at step 810 ) a response from the rideshare server 130 , the response including information relating to authentication of a driver's identity. Based on the response, the process determines (at step 812 ) whether the authentication was successful. If the authentication was unsuccessful, the process terminates. If, however, the authentication was successful, the process moves to step 814 in which the process receives information pertaining to a passenger's pickup location (e.g., in the form of a latitude longitude or a street address) from the rideshare server 130 . In some embodiments, the pickup location is displayed on a map. In some instances, information included in the map is provided by a geocoding server 116 to the rideshare server 130 which then conveys the same to the driver's mobile app via the Internet.
- a passenger's pickup location e.g., in the form of a latitude longitude or a street address
- the process displays a message on the screen of the driver's mobile device indicating that the authentication was successful.
- the message indicating successful authentication can be received prior to the process receiving the passenger's pickup location from the rideshare server 130 .
- the process waits for a selection from the driver indicating arrival at the passenger's pickup location.
- the process displays (at step 820 ) a message indicating a start of a rideshare trip, assuming the passenger gets in the driver's vehicle.
- the process displays route information relating to the rideshare trip on a screen of the driver's mobile device in real-time until the passenger arrives at the passenger's intended destination.
- the route information for example, can be obtained from a geocoding server 116 .
- the process Upon arriving at the passenger's intended destination, the process displays an indication of the end of the rideshare trip and a cost associated with the rideshare trip.
- the process enables a driver to enter (at step 824 ) passenger rating information (e.g., on a five star scale, or some other scale) via the mobile app running on the driver's mobile device. The process terminates thereafter.
- the mobile app running on the driver's mobile device goes offline, i.e., breaks network connections with the rideshare server 130 .
- a driver provides his or her biometric scan via the mobile app, for the mobile app to come back online.
- the process of matching or comparison a driver's biometric scan with a pre-stored scan can be performed at the driver's mobile device, e.g., by the mobile app running on the driver's mobile device.
- the mobile app does not necessarily need to send the biometric scan to the rideshare server 130 , and accordingly, no response from the rideshare server 130 with regard to comparison of biometric scans would be necessary, i.e. steps 808 and 810 in the flow diagram would be optional.
- FIG. 9 illustrates a flow diagram showing method steps of a process 900 by a mobile app running on a passenger's mobile device in connection with a passenger availing a rideshare trip, according to an embodiment of the present invention.
- the process receives a passenger's pickup location (e.g., in the form of an address) from a passenger via the mobile app running on the passenger's mobile device.
- the process transmits the pickup location to the rideshare server at step 904 .
- the rideshare server 130 responds back with information about the rideshare driver and the driver's vehicle, which is received by the process at step 906 .
- the ride share server 130 can provide a name and contact information (e.g., phone number, email, etc.) of the driver, a photograph of the driver, a make, year, model and photograph of the vehicle that the driver is driving.
- the rideshare server 130 provides an estimate of the rideshare trip to the passenger.
- the process displays (at step 908 ) a message indicating a start of a rideshare trip, assuming the passenger gets in the driver's vehicle.
- the process displays route information relating to the rideshare trip on a screen of the passenger's mobile device in real-time until the passenger arrives at the passenger's intended destination.
- the route information can be obtained from a geocoding server 116 .
- the process displays (at step 912 ) end of the rideshare trip and a cost associated with the rideshare trip.
- the process enables a passenger to enter (at step 914 ) driver rating information (e.g., on a five star scale, or some other scale) via the mobile app running on the passenger's mobile device.
- driver rating information e.g., on a five star scale, or some other scale
- a driver can view, for example by accessing a driver portal or via a mobile application, the rating information (e.g., comments/feedback etc.) provided by passengers along with an associated date and time.
- FIG. 10 illustrates a flow diagram showing method steps of a process 1000 by a rideshare server identifying referral chains, according to an embodiment of the present invention.
- an existing driver (referrer or “Driver A”) suggests a new driver (referee or “Driver B”) to sign up with the rideshare service.
- a referrer can share a referral ID provided by the rideshare server 130 with the referee.
- the process receives registration information of driver B during an initial registration process, for example, after launching the driver's mobile app for the first time on driver B's mobile device.
- the registration information can include, for example, the driver's biometric scan, the driver's personal information, the driver's vehicle information, etc.
- a registered driver notifies the rideshare server 130 that he or she has provided a referral ID to driver B. Accordingly, when driver B registers with the rideshare service, driver B may be required to provide the referral ID provided by the registered driver.
- driver B may be required to provide the referral ID provided by the registered driver.
- Such a methodology can prevent fraud when driver learns B about the rideshare service from a registered driver, but does not provide the referral ID provided by the registered driver, in an attempt not to share his or her earnings with the registered driver.
- the process determines (at step 1004 ) if driver B has indicated, as part of the registration process, as being referred by another driver A. If the process determines that the driver B has indicated as not being referred by a driver, then the process terminates. If, however, the process determines that the driver B has indicated as being referred by an existing driver, then the process receives a referral ID provided by driver B. Thus, the process determines (at step 1006 ) if the referral ID provided by driver B is a valid referral ID. For example, the process determines if the referral ID has been used multiple times, or is being used by unrecognized individuals associated with the referral ID. If the process determines that the referral ID is not valid, then the process terminates. In some embodiments, the process displays a message indicating that the referral ID provided by driver B is not valid.
- the process determines (at step 1008 ) whether an existing driver A has notified the rideshare server 130 of sharing the referral ID with driver B. If the process determines that no existing driver A has notified the rideshare server 130 of sharing the referral ID with a driver B, then the process terminates, suspecting fraud by registering driver B. If the process determines, however, that an existing driver A has notified the rideshare server 130 of sharing the referral ID with a driver B, then the process updates (at step 1010 ) a database to reflect the referrer/referee relationship between driver A and driver B.
- the process communicates the referrer/referee relationship between driver A and driver B to either, or both, driver A and driver B's mobile app running on their respective mobile devices.
- the process terminates thereafter.
- a network marketer can provide referral of proposed new drivers to the rideshare server 130 via the network marketer portal.
- a network marketer is an individual or an entity that is not a registered driver of the rideshare service and provides referral of proposed new drivers to the rideshare server 130 .
- a network marketer can earn percentages of a driver's earnings if such a driver was referred by a network marketer and signed up with the rideshare service.
- the process of identifying referral chains involving network marketers is similar to that in which an existing driver (referrer or “Driver A”) suggests a new driver (referee or “Driver B”) as discussed in FIG. 10 , with Driver A being replaced by a network marketer as suitable.
- FIG. 11 illustrates several mobile device interface screens 1100 of a driver's mobile app, according to an embodiment of the present invention.
- screen 1102 shows options in connection with at least the following inventive features: referring a proposed new driver (a “Refer” button), viewing a profile of the driver associated with the mobile app (a “Profile” button), viewing information about the rideshare service (an “About Us” button), viewing recent rideshare trips offered by the driver associated with the mobile app (a “My Recent Trips” button), viewing toll rates at a geographical location (a “Toll Rates” button), viewing a cost of a last rideshare trip offered by the driver associated with the mobile app (a “Fare Amount” button), facilitating a call with a driver support phone number (a “Call Support” button), and viewing a driver's personal settings on the mobile app (a “Driver's Settings” button).
- a proposed new driver a “Refer” button
- a profile of the driver associated with the mobile app a “Profile” button
- Screen 1104 shows clickable options for launching mobile apps of third parties such as social media network and social texting apps from the driver's mobile app.
- Screen 1106 displays an exemplary driver referral chain involving three drivers. For example, screen 1106 shows a driver John referred a driver Jason who referred a driver Tom. Thus, driver John that is associated with the mobile app accumulates earnings from drivers Jason and Tom.
- FIGS. 12-14 illustrate interfaces showing earnings accumulated via a driver's referral chain, according to an embodiment of the present invention.
- the interfaces in FIGS. 12-14 can be viewed by a system administrator associated with the rideshare service.
- Region 1202 of FIG. 12 displays four exemplary referral chains 1212 (chain 1 ), 1214 (chain 2 ), 1216 (chain 3 ), and 1214 (chain 4 ), each chain showing percentage contributions of a driver to the rideshare service.
- Embodiments of the present disclosure facilitate a hierarchical earning structure such that the rideshare service retains a percentage from each driver in a referral chain.
- the rideshare service retains 15% of driver 1 's earnings, 11% of driver 2 's earnings, 8.5% of driver 3 's earnings, 7% of driver 4 's earnings, and so on. These percentages are displayed as percentage deductions in line 1206 of FIG. 12 .
- Lines 1208 and 1210 of FIG. 12 respectively display a total amount earned by each driver in a referral chain from offering rideshare services, and an amount retained by the rideshare service from each driver's earnings.
- Region 1204 of FIG. 12 shows each driver's earnings from their referral chain network.
- Column 1226 shows percentage earnings by a respective driver from other drivers in their referral chain network, e.g., driver 1 earns 4% of driver 2 's earnings, 2.5% of driver 3 's earnings, 1.5% of driver 4 's earnings, and so on.
- Column 1228 displays a respective monetary amount corresponding to each percentage in column 1228 .
- Column 1230 displays a total amount earned by a driver by accumulating his or her earnings from the driver's referral chain.
- Referral chains 1222 and 1224 are exemplary referral chains showing earning by drivers 2 and 3 from their respective referral chain networks. FIG.
- FIG. 13 displays a detailed view of an exemplary referral chain showing percentages retained by the rideshare service and percentage earnings associated with each driver in the chain.
- FIG. 13 demonstrates that the percentages retained by the rideshare service can be similar as those discussed for chain 1 in FIG. 12 .
- region 1302 in FIG. 13 shows a referral chain in which driver pqr refers driver android, driver android refers driver nexus, driver nexus refers driver blackberry, and so on
- the ridesharing service retains 15% of driver pqr's earnings, 11% of driver android's earnings, 8.5% of driver nexus' earnings, 7% of driver blackberry's earnings, and so on.
- Percentages associated with each level can be varied by a system administrator of the rideshare server 130 .
- Region 1304 in FIG. 13 shows percentage earnings by a respective driver from other drivers in their referral chain network (e.g., similar to column 1226 in FIG. 12 ), a respective monetary amount corresponding to each percentage (e.g., similar to column 1228 in FIG. 12 ), and a total amount earned by a driver by accumulating his or her earnings from the driver's referral chain (e.g., similar to column 1228 in FIG. 13 ).
- FIG. 14 presents a magnified view of percentage earnings (region 1402 ) retained by the rideshare service from a respective driver and other drivers in the subject driver's referral chain network, similar to region 1302 shown in FIG. 13 .
- FIG. 15 illustrates an interface 1500 displaying a driver's earnings history, according to an embodiment of the present invention.
- the interface can display columns 1502 (“Passenger ID”), 1504 (“Passenger Name”), 1506 (“Date of Rideshare Trip”), 1508 (“Earned Fare”), 1510 (“Tip”), 1512 (“Toll Amount”), and 1514 (“Total Payable Amount”).
- Passenger ID (“Passenger ID”)
- 1504 (“Passenger Name”)
- 1506 (“Date of Rideshare Trip”)
- 1508 (“Earned Fare”)
- 1510 Tele
- Tip 1512
- Toll Amount 1514
- Total Payable Amount Total Payable Amount
- FIG. 15 shows earnings for a driver pqr from passengers Akshata (identified by passenger id 16 ) and John (identified by passenger id 20 ), the dates on which the rideshare trips were offered, a cost of the rideshare trip, a tip paid by each passenger to driver pqr, and a toll amount payable to the driver by the rideshare service in connection with the trip.
- FIG. 15 also displays a total payable amount to driver pqr based on the sum of the cost of the trip, the tip paid by a passenger and the toll amount.
- the interface in FIG. 15 can be viewed by driver pqr or a system administrator associated with the rideshare service.
- the system provides options to enter a start date and an end date over which a driver's earnings history is displayed.
- FIG. 16 illustrates an interface 1600 showing a passenger's trip history, as viewed by a system administrator associated with the rideshare service, according to an embodiment of the present invention.
- the interface can display columns 1602 (“Request ID”), 1604 (“Owner Name”), 1606 (“Driver”), 1608 (“Date”), 1610 (“Time”), 1612 (“Status”), 1614 (“Amount”), and 1618 (“Payment Status”).
- a request ID column is a unique identifier corresponding to an instance of a rideshare request from a passenger.
- a Status column provides a status of the rideshare trip.
- a Payment Status column provides information pertaining to receiving a payment for a rideshare trip from a passenger's financial institution.
- the system provides options to enter a start date and an end date over which a passenger's trip history is displayed.
- FIG. 17 illustrates an interface 1700 showing a passenger's pickup location with respect to a rideshare driver's location displayed on a map, according to an embodiment of the present invention.
- a rideshare driver's (provider's) location 1702 is relatively near the passenger's (user's) location 1704 .
- the interface 1700 can be viewed on the mobile app running on the driver's mobile device and/or the mobile app running on the passenger's mobile device.
- a system administrator can view/track the driver's movement and/or the passenger's movement via an interface similar to interface 1700 .
- the system can obtain in real-time, a number and location of drivers at a geographical location who are offering to provide rideshare trips to passengers.
- Such aspects are beneficial in selecting, for instance, a driver that is located closest to a passenger's location such that the driver can arrive at the passenger's pickup location in a short time.
- FIGS. 18-19 illustrate interfaces 1800 , 1900 linked to a driver database, according to an embodiment of the present invention.
- the interface can display columns 1802 (“Driver ID”), 1804 (“Name”), 1806 (“Email”), 1808 (“Phone”), 1810 (“Photo”), 1812 (“Bio”), 1814 (“Total Requests”), 1816 (“Status”), and 1818 (“Actions”).
- Photo column provides a link to a driver's photo saved in the database.
- Total Requests column indicates a total number of rideshare requests made to a driver by passengers.
- Status column indicates whether the driver was approved based on passing a background check and driving history.
- Action column provides a drop-down menu of selectable actions such as decline, set target, edit details, and view details.
- the decline option removes the driver from the database.
- the system administrator can view and edit driver-related information saved in the database, by selecting the edit details or view details options.
- the set target option can be used by a system administrator to set a target amount that a driver is required to earn between a start date and an end date. In some embodiments, a driver can view the days remaining to reach a target amount.
- the interface generated upon selecting the set target option is shown in greater detail in region 1902 of FIG. 19 .
- the set target option is applicable only to drivers who are part of a referral chain. That is, this functionality, in some embodiments, is disabled for drivers that are not part of a referral chain.
- FIG. 20 illustrates a passenger database, according to an embodiment of the present invention.
- the interface can display columns 2002 (“ID”), 2004 (“Name”), 2006 (“Email”), 2008 (“Phone”), 2010 (“Address”), 2012 (“State”), 2014 (“Zipcode”), and 2016 (“Actions”).
- Actions column provides a drop-down menu of selectable actions such as edit passenger details, view history of a passenger's rideshare trips, and view additional passenger-related information saved in database.
- FIGS. 21-22 illustrate interfaces 2100 A, 2100 B, and 2200 A, 2200 B respectively showing an embodiment of the network marketer portal presented by the rideshare server to network marketers.
- a network marketer can provide referral of proposed new drivers to the rideshare server 130 via the network marketer portal.
- a network marketer is an individual or an entity that is not a registered driver of the rideshare service and provides referral of proposed new drivers to the rideshare server 130 .
- a network marketer can earn percentages of a driver's earnings if such a driver was referred by a network marketer and signed up with the rideshare service.
- a (“View Profile”) button 2102 clicks on the interface 2100 A, the interface 2100 B is displayed.
- Region 2108 of interface 2100 A displays a subscription status of a network marketer and a subscription expiration date of a network marketer.
- a network marketer has to keep an active subscription with the rideshare service to be able to refer new drivers and/or earn percentages of a referred driver's earnings.
- a driver that was referred by a network marketer can refer new drivers to the rideshare service. In such scenarios, a network marketer earns percentages of all drivers that are included in the subject driver's referral chain, in addition to the earnings of the subject driver.
- a “Referral Tree” button 2103 displays a network marketer's referral tree.
- Interface 2100 B displays a “View Profile” interface to a network marketer.
- region 2104 displays registration information that is typically provided by a network marketer when he or she signs up with the rideshare service.
- Region 2104 includes example fields such as a first name, a last name, a date of birth, a gender, an email address, a password along with a confirm password, an address including a state, a city and a country.
- Region 2104 also includes an option for a network marketer to add a profile picture.
- region 2104 includes driver-related fields such as a vehicle number, a type of vehicle, a license number of the driver, a registration number of the vehicle, an insurance policy number of the vehicle, a license expiration date of the driver, a registration expiration date of the driver, an insurance expiration date, etc.
- interface 2200 B shows a region 2110 for providing a network marketer's bank-related information to the rideshare server 130 .
- region 2110 includes a router/routing number of a bank, a bank name, a credit card number along with its expiry date and its CVV number.
- region 2110 includes a referral ID button 2112 .
- the rideshare server 130 when a network marketer clicks on button 2112 , the rideshare server 130 generates dynamically a referral ID that can be shared with a proposed new driver or sent via email to the proposed new driver. In some embodiments, the rideshare server 130 retrieves a pre-generated referral ID and presents it to the network marketer, in response to the network marketer clicking on button 2112 .
- FIG. 22 illustrate interfaces 2200 A and 2200 B showing a portal accessible by a network marketer for referring a driver to the rideshare service.
- Interface 2200 A is similar to interface 2100 A.
- interface 2200 displays a network marketer having an ID 12 , and a name John Kerry having a subscription expiry date of Jul. 21, 2015, and a number of drivers (e.g., zero) referred by the network marketer.
- a “Subscription Status” button 2210 when clicked on this interface reveals whether the network marketer's subscription is expired or still subscribed, indicated in box 2208 .
- Interface 2200 B also includes a Status button 2214 , which when clicked, reveals the names of the drivers that were referred by the network marketer.
- existing drivers cannot be referred by a network marketer to the rideshare service.
- an existing network marketer can refer another driver by clicking on a Refer Driver button 2206 .
- an existing network marketer can refer another network marketer by clicking on a Refer Network Marketer button 2204 .
- New driver referrals and new network marketer referrals can be made by social media networks or via email, e.g., as shown in box 2212 . For example, if a new driver is referred, then a downloadable link to a driver's mobile application is shared, inviting the new driver to sign up with the rideshare service. If a new network marketer is being referred, then a link to the network marketer portal (for signup) is shared.
- Embodiments of the present disclosure include various steps.
- the steps may be performed by hardware components or may be embodied in machine-executable instructions, which may be used to cause a general-purpose or special-purpose processor programmed with the instructions to perform the steps.
- the steps may be performed by a combination of hardware, software and/or firmware.
- the steps of the processes shown in FIGS. 7-10 are not necessarily completed in the order shown, and various steps may operate concurrently and continuously.
- the drawings and discussions herein refer to two items of digital content, i.e. a first item and a second item. But such drawings and discussions are for exemplary purposes only. In alternate embodiments, multiple (e.g., more than two) items of digital content can be used as a part of a validation process.
- Embodiments of the present disclosure may be provided as a computer program product, which may include a machine-readable medium having stored thereon instructions, which may be used to program a computer (or other electronic devices) to perform a process.
- the machine-readable medium may include, but is not limited to, floppy diskettes, optical disks, compact disc read-only memories (CD-ROMs), and magneto-optical disks, ROMs, random access memories (RAMs), erasable programmable read-only memories (EPROMs), electrically erasable programmable read-only memories (EEPROMs), field programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), vehicle identity modules (VIMs), magnetic or optical cards, flash memory, or other type of media/machine-readable medium suitable for storing electronic instructions.
- embodiments of the present disclosure may also be downloaded as a computer program product or data to be used by a computer program product, wherein the program, data, and/or instructions may be transferred from a remote computer to a requesting computer by way of data signals embodied in a carrier wave or other propagation medium via a communication link (e.g., a modem or network connection).
- a communication link e.g., a modem or network connection
Abstract
Systems and methods according to which a mobile application is running on a driver's mobile device for authenticating ride share drivers. When a driver initially registers with a rideshare service, the driver is prompted to provide biometric information via a mobile app running on the driver's mobile device. The biometric information is then stored in a database with a ride share management server in a file associated with the driver's account. Subsequently, when the driver expresses an offer to provide a ride share trip, the server performs an authentication check based on the pre-stored biometric information. Furthermore, the system discloses herein facilitates increased rideshare revenue generation by creating referral chains for a driver when a previously-registered driver, or an affiliate of the rideshare service refers a proposed new driver to the rideshare service and the proposed new driver then registers with the rideshare service.
Description
- This application is a continuation of U.S. patent application Ser. No. 16/426,970 filed May 30, 2019, which is a continuation of U.S. patent application Ser. No. 14/938,129 filed Nov. 11, 2015, which claims the benefit of U.S. provisional patent application No. 62/124,196 filed Dec. 11, 2014, all of which are hereby incorporated by reference in their entireties.
- The present disclosure relates generally to vehicle rideshares. More specifically, embodiments of the present disclosure relate to systems and methods for facilitating vehicle rideshare involving a computerized hierarchical driver referral system and a biometric scan-based authentication of a rideshare driver's identity.
- Historically, passengers who do not wish to drive or use public transportation use taxi cabs to travel from one place to another. Recently, rideshare systems have become available as another source of transportation. Typically passengers request a ride from a driver by using an app on the passenger's mobile device. The mobile app communicates with a server managed by a rideshare system or service and provides information about the passenger's location. In turn, the server sends out a request to drivers in the general vicinity of the passenger's location, and also informs the passenger of average pickup times for drivers in the vicinity. Once the passenger selects a driver and an associated vehicle, the passenger is provided with the driver's information such as a name, a phone number, and an expected time of arrival. After the driver has provided the ride to the passenger, the passenger's credit card or debit card (typically stored in a database coupled to the rideshare server) is charged.
- One concern about known rideshare systems is that they do not provide adequate security measures to protect passengers. For example, an unauthorized person can impersonate a ride share driver and provide a ride to an unsuspecting passenger. Another concern is that known rideshare systems do not utilize technology effectively to adequately incentivize new drivers to become part of the riding sharing service.
-
FIG. 1 illustrates an example system for facilitating rideshares utilizing a ride share management server. -
FIG. 2 illustrates example registration screens of a mobile device interface for registering drivers with an embodiment of the ride share management server, according to an embodiment of the present invention. -
FIG. 3 illustrates a mobile device interface for receiving biometric information from drivers, according to an embodiment of the present invention. -
FIG. 4 illustrates a schematic of discrete pairwise operations involving a driver's mobile app, a passenger's mobile app, a ride share management server, a navigation API, and a geocoding server associated with start of a trip, according to an embodiment of the present invention. -
FIG. 5 illustrates a schematic of discrete pairwise operations involving a driver's mobile app, a passenger's mobile app, a ride share management server, a passenger portal, and a geocoding server associated with end of a trip, according to an embodiment of the present invention. -
FIG. 6 illustrates a schematic of operations associated with a driver's mobile app according to an embodiment of the present invention. -
FIG. 7 illustrates a flow diagram showing method steps by a mobile app for registering a driver according to an embodiment of the present invention. -
FIG. 8 illustrates a flow diagram showing method steps by a mobile app running on a driver's mobile device in connection with a driver offering to provide a rideshare trip according to an embodiment of the present invention. -
FIG. 9 illustrates a flow diagram showing method steps by a mobile app running on a passenger's mobile device in connection with a passenger availing a rideshare trip, according to an embodiment of the present invention. -
FIG. 10 illustrates a flow diagram showing method steps by a rideshare server identifying referral chains according to an embodiment of the present invention. -
FIG. 11 illustrates several example mobile device interface screens of a driver's mobile app according to an embodiment of the present invention. -
FIGS. 12-14 illustrate example interfaces showing earnings accumulated via a driver's referral chain according to an embodiment of the present invention. -
FIG. 15 illustrates an example interface displaying a driver's earnings history according to an embodiment of the present invention. -
FIG. 16 illustrates an example interface showing a passenger's trip history according to an embodiment of the present invention. -
FIG. 17 illustrates an example interface showing a passenger's pickup location with respect to a rideshare driver's location displayed on a map according to an embodiment of the present invention. -
FIGS. 18-19 illustrate example interfaces linked to a driver database according to an embodiment of the present invention. -
FIG. 20 illustrates an example interface linked to a passenger database according to an embodiment of the present invention. -
FIGS. 21-22 illustrate example interfaces for a network marketer to access the rideshare server via a network marketer portal, according to an embodiment of the present invention. - In one aspect, the inventive disclosure provided herein generally relates to systems and methods for authenticating ride share drivers using a biometric sensor. When a driver initially registers with the rideshare service, the driver is prompted to provide biometric information via a mobile app running on the driver's mobile device. The biometric information is then stored in a database with a ride share management server in a file associated with the driver's account. Subsequently, when the driver expresses an offer to provide a ride share trip, the server performs an authentication check based on the pre-stored biometric information. Particularly, the driver provides his or her biometric information to the ride share management server via a mobile application on the driver's mobile device. This information is then checked against the stored biometric information in the networked database to authenticate the identity of the driver. If authenticated, the driver receives pick-up information, including the passenger's pickup location and desired destination. In the meantime, the ride share management server notifies the passenger about the details of the rideshare driver and the rideshare vehicle via the mobile app on the passenger's mobile device. Once the driver arrives at the pickup location of the passenger and picks up the passenger, the ride share trip starts.
- In some embodiments, the biometric information is stored inside non-volatile memory in or coupled to the driver's mobile device. Subsequently, when offering a rideshare trip, an identity of a driver who offers the rideshare trip is checked (by the mobile app running on the driver's mobile device) against the stored biometric information to authenticate the identity of the driver. However, the comparison of the biometric information received versus the pre-stored biometric information is performed by the rideshare server. Thus, in such implementations, the stored biometric information is transmitted from the driver's mobile device to the rideshare server, prior to the comparison.
- Drivers' mobile devices are configured to enable drivers to provide biometric information via a sensor coupled to or otherwise configured within a driver's respective mobile device. A biometric scan can include, for example, fingerprint, voice, iris recognition, or a combination thereof. In some embodiments, a driver's mobile device, a passenger's mobile device, or both can be configured to enable receipt of biometric scans, process such scans to determine if the scan was successful, and transmit such scans to a ride share management server. The ride share management server compares the biometric scan of a driver offering to provide a ride share trip against a stored biometric scan to authenticate the identity of the driver. The biometric scan of a driver can be stored along with other types of driver information such as a name, license information, social security number, car information, picture of driver and the car, ride history of the driver accumulated over time, criminal background check, driver ratings by passenger, etc. In some aspects, a data structure associated with a driver enables storage and manipulation of different types and formats (e.g., alphabetical, numeric, alphanumeric, etc.) of data about a driver. In some embodiments, a passenger can access some of the data relating to a driver. For example, a passenger can access such information at the start of a trip until the trip is over.
- In another aspect, the inventive disclosure relates to a computerized method and system for facilitating increased rideshare revenue generation by creating referral chains for a driver when a previously-registered driver (e.g., “Driver A”) refers a proposed new driver (e.g., “Driver B”) to the rideshare service and the proposed new driver then registers with the rideshare service. In this scenario, the referral chain can provide additional revenue for the previously-registered driver by accumulating a percentage of earnings from the proposed new driver. This referral chain can span a number of levels (e.g., five levels of referrals). In some embodiments, a driver who has been referred by a registered driver is prevented from being referred by another registered driver. In some aspects, a registered driver who refers a new driver provides a referral ID to that is used by the proposed new driver when signing up with the rideshare service. In some other aspects, a registered driver notifies the ride share management server that he or she has provided a referral ID to the new driver. Accordingly, when the new driver registers with the rideshare service, the new driver may be required to provide the referral ID provided by the registered driver. Such a methodology can prevent occurrences where a new driver has been referred by a registered driver but does not provide the referral ID provided by the registered driver in an attempt to avoid sharing his or her earnings with the referring driver.
- When a driver who has been referred by another driver signs up with the ridesharing service, a mobile app running on a referring (registered) driver's mobile device is updated to show the referral chain. That is, data relating to the new driver is transferred to the registered driver's mobile app. Thus, embodiments of the present disclosure enable push notifications to be received by an app running on a driver's mobile device. The app running on a driver's mobile device can be configured to receive notifications on-the-fly from a ride share management server. The referral chain of the registered driver can be stored on the registered driver's mobile app, and additionally in a database associated with the rideshare service.
- When a driver completes a ride, an electronic payment is processed such that requisite funds amounting to the cost of a ride are transferred from a passenger's financial institution to the rideshare service. For example, a driver who provided the ride can receive 85% of the cost of a ride, and the remaining 15% is retained by the rideshare service. In some aspects, details relating to a passenger's financial institution are stored in a passenger database associated with the rideshare service when the passenger registers with the rideshare service. After receiving the funds, the rideshare service retains a percentage from each driver in a referral chain. In addition, the registered driver who has referred the subject driver also earns a percentage of the earnings. For example, in a referral chain in which
driver 1 refersdriver 2, anddriver 2 offers a ride to a passenger,driver 2 earns 85% of the cost of the ride. The remaining 15% is divided between the rideshare service anddriver 1. Thus, in some scenarios, the driver who provided the ride earns 85% of the cost of a ride. The remaining 15% is divided among the rideshare service and the other driver(s) in the referral chain, according to certain percentages. In another example, in whichdriver 1 refersdriver 2,driver 2 refersdriver 3,driver 3 refersdriver 4, and so on, the rideshare service retains 15% ofdriver 1's earnings, 11% ofdriver 2's earnings, 8.5% ofdriver 3's earnings, 7% ofdriver 4's earnings, and so on. Similarly,driver 1 earns 4% ofdriver 2's earnings, 2.5% ofdriver 3's earnings, 1.5% ofdriver 4's earnings, and so on. (These percentages can vary, and are examples for discussion purposes only.) In some embodiments, payments from a passenger's financial institution can be processed via a third payment processor acting as an intermediary between the passenger's financial institution and the rideshare service. - In some embodiments, the inventive disclosure relates to a computerized method and system for creating referral chains when a network marketer refers a proposed new driver to the rideshare service and the proposed new driver then registers with the rideshare service. A network marketer, as used herein, is an individual or an entity that is not a registered driver of the rideshare service. A referral chain started by a network marketer can provide a revenue generation stream for the network marketer by accumulating a percentage of earnings from the proposed new driver. Referral chains by network marketers can have features and functionalities that are similar to referral chains by drivers. For example, the referral chain can span a number of levels (e.g., five levels of referrals). A network marketer who refers a new driver provides a referral ID that is used by the proposed new driver when signing up with the rideshare service. In some other aspects, a network marketer notifies the rideshare management server that he or she has provided a referral ID to the new driver. Accordingly, when the new driver registers with the rideshare service, the new driver may be required to provide the referral ID provided by the network marketer. In some embodiments, a network marketer can access the rideshare service via a network marketer portal for providing information to the rideshare server, checking earnings/invoices as a result of earnings from rideshare drivers that are part of the network marketer's referral chain, etc. Percentages of earnings from a network marketer-referred driver can, in some embodiments, be similar or different than driver-referred scenarios discussed above.
- Various aspects and examples of the embodiments will now be described. The following description provides specific details for a thorough understanding and enabling description of these examples. One skilled in the art will understand, however, that the embodiments may be practiced without many of these details. Additionally, some well-known structures or functions may not be shown or described in detail, so as to avoid unnecessarily obscuring the relevant description.
-
FIG. 1 illustrates an example system where arideshare management server 130 facilitates providing ride share trips topassengers 114 in vehicles driven byride share drivers 112.Passengers 114 and rideshare drivers 112 own, operate, or otherwise have access tomobile devices 122. Determining a trip can, in some embodiments, involve queries to ageocoding server 116. Apayment processor 120 is used to disburse payments to ride share drivers based on the cost of a rideshare trip. A passenger can pay the cost of a rideshare trip using a debit card or a credit card associated with afinancial institution server 118. - It will be understood that the ride
share management server 130, which can be referred to as the “rideshare server,” can be a single server or a plurality of interconnected servers that are configured to exchange information. Further, such a server or a plurality of servers can be cloud-based or can be physical servers. - In the exemplary scenario shown in
FIG. 1 , apassenger 114 is waiting at a geographical location for arideshare driver 112 to arrive and pick up thepassenger 114.Passenger 114 requestsrideshare server 130 for a ride share trip by launching a mobile application on the passenger'smobile device 122. The request typically includes information relating to the passenger's geographical location (e.g., latitude longitude) obtained via a location mechanism (e.g., a GPS sensor) on the passenger'smobile device 122 and an intended destination provided by thepassenger 114. In some instances, apassenger 114 can request an estimated cost of the rideshare trip from therideshare server 130. - In some embodiments, a mobile application associated with the rideshare service can function dually as a mobile application for a
passenger 114 as well as that for adriver 112. Thus, depending on whether an individual is logging in as apassenger 114 or as adriver 112, the same mobile application can be used for both purposes. For purposes of discussion and illustration, the terms “a mobile application running on a driver's mobile device,” “a driver's mobile app,” and “a driver app” would be considered analogous. Similarly, the terms “a mobile application running on a passenger's mobile device,” “a passenger's mobile app,” and “a passenger app” would be considered analogous. - A
driver 112 in the vicinity offering to provide a rideshare trip launches a mobile application on the driver'smobile device 123. In some embodiments, the mobile application requests thedriver 112 to provide his or her biometric information to therideshare server 130 every time a driver launches the mobile application for offering a rideshare trip. A driver'smobile device 123 can be configured to enable adriver 112 to provide biometric information via a sensor coupled to or otherwise configured within a driver's respectivemobile device 123. A biometric scan can include, for example, fingerprint, voice, or iris recognition, or a combination thereof. In some embodiments, the driver'smobile device 123 can be configured to enable receipt of biometric scans, process such scans to determine if the scan was successful, and transmit such scans to arideshare server 130. Therideshare server 130 checks the biometric information provided by the driver offering to provide the ride share trip against the stored biometric information in a networked database to authenticate the identity of thedriver 112. - If authenticated, the
driver 112 is provided with the destination of thepassenger 114 and a pickup location of thepassenger 114. Thepassenger 114 is notified of details of therideshare driver 112 and the rideshare vehicle, via the mobile app on the passenger'smobile device 122, by therideshare server 130. For example, theride share server 130 can provide thepassenger 114 with a name and contact information (e.g., phone number, email, etc.) of thedriver 112, a photograph of thedriver 112, a make, year, model and photograph of the vehicle that thedriver 112 is driving. - In some instances, the
rideshare server 130 provides an estimate of the rideshare trip to thepassenger 114. The wait time for thepassenger 114 waiting for therideshare driver 112 to arrive at the passenger's pickup location is typically a couple of minutes or less. Thedriver 112 arrives at the pickup location of thepassenger 114, picks up thepassenger 114 and the ride share trip starts. In some embodiments, a trip starts when a driver clicks on a button to start a trip using the mobile application running on the driver'smobile device 123. In some scenarios, more than one driver can respond torideshare server 130 with an offer to provide a rideshare trip topassenger 114. In such a scenario, theride share server 130 can choose adriver 112 randomly, or can choose adriver 112 who is closest to thepassenger 114. - In some embodiments, the
rideshare server 130 communicates with ageocoding server 116 to provide real time navigation directions to thedriver 112, on the way to the passenger's destination. For example, arideshare server 130 can query (e.g., via an API call) thegeocoding server 130 with the intended destination provided by thepassenger 114 to obtain the real time navigation directions. The geocoding server provides the navigation directions (e.g., route information of the rideshare trip on a map) to therideshare server 130 which is conveyed in real time to a mobile application running on the driver'smobile device 123, and optionally to the passenger'smobile device 122. The mobile application running on the driver'smobile device 123 can also compute information relating to a net distance traveled from the passenger's pickup location, a time of travel, etc. Such information can be used to calculate a total cost of the rideshare trip. In some embodiments, geocodingserver 116 performs some or all of these computations, and provides the same to the mobile application running on the driver'smobile device 123. - In some embodiments, a
passenger 114 goes through a one-time registration process (usually at any time before the first rideshare trip of the passenger 114) in which thepassenger 114 provides his or her details, e.g., name, email, phone number, credit/debit card information, name of a financial institution associated with the credit/debit card, etc. to therideshare server 130. In some embodiments, information relating to apassenger 114 is stored in a networked database (e.g., as a data structure) and can be viewed and/or edited by thepassenger 114 via apassenger portal module 134 accessible by any electronic device connected to the Internet, including the mobile application running on the passenger'smobile device 122. In some embodiments, the mobile application running on the passenger'smobile device 122 stores a copy of the passenger's personal and financial information. - When the
passenger 112 arrives at the intended destination, the rideshare trip ends. Information relating to the rideshare trip, e.g., duration of trip, distance traveled, route taken, etc. is also obtained by the mobile application running on the driver'smobile device 123. In some embodiments, the mobile application running on the driver'smobile device 123 calculates the total cost of the rideshare trip, e.g., on the basis of a monetary value per unit time of rideshare travel. In some embodiments, such information is communicated to therideshare server 130. Therideshare server 130 typically provides that information (partially or entirely) to the mobile application running on the passenger'smobile device 123. In some embodiments, the mobile application on the passenger'smobile device 123 also provides an option to pay a tip to therideshare driver 114. After reviewing the details of the trip, apassenger 112 can approve of the payment of the cost of the trip via the mobile application running on the passenger'smobile device 123. In some embodiments, the mobile application running on the driver'smobile device 123 goes offline, for example, breaks off communication with therideshare server 130 when a trip ends. Thus, in such embodiments, a driver who wishes to offer to provide a subsequent rideshare trip re-launches the mobile application, and re-scans his or her biometric information for authentication. - Upon receiving the passenger's approval, in some embodiments, the
rideshare server 130 communicates with a payment processor 120 (typically via an API call).Payment processor 120 is a third party financial services provider that allows both private individuals and businesses to accept payments over the Internet. For example, thepayment processor 120 can initiate payment transactions associated with payment of the cost of the trip from the passenger'sfinancial institution server 118. - In some embodiments, a
second driver 112 shares his or her earnings with afirst driver 112 in a scenario in which thefirst driver 112 has referred thesecond driver 112 to sign up with the rideshare service as a driver. Thus, embodiments of the disclosed system facilitate the creation of referral chains which can provide residual income to drivers, after funds amounting to the cost of a rideshare trip is received from a passenger's financial institution. - In some optional embodiments as shown in
FIG. 1 , therideshare server 130 includes abackend module 132, apassenger portal module 134, adriver portal module 136, and a networkmarketer portal module 138. Typically, thepassenger portal module 134 and thedriver portal module 136 are accessible by electronic devices such as mobile devices, laptops, desktops, tablet PCs, etc. connected to the Internet as well as mobile devices including but not limited to the driver'smobile device 122, passenger'smobile device 123, thegeocoding server 116, and thepayment processor 120. In some embodiments, the networkmarketer portal module 138 is accessible via the web only, and not via mobile applications on mobile devices. In some other embodiments, the networkmarketer portal module 138 can be accessible via mobile applications running on mobile devices. The networkmarketer portal module 136 can, for example, be accessed by a network marketer module to provide information about a proposed new driver to therideshare server 130, or even directly refer a proposed new driver via the networkmarketer portal module 136. A network marketer can also receive referral IDs generated by therideshare server 130 to be shared or sent (e.g., via a social media network or in an email communication) to the proposed new driver. - Thus, embodiments of the present disclosure enable both
drivers 112 andpassengers 114 to view their profile and affiliated information using apassenger portal module 134 and adriver portal module 136 hosted by the rideshare service. For example, both passengers and drivers can respectively view their profile information, their trip history, their payment history, their invoices, etc. Theback end module 132 is typically involved in calculation of payments, maintenance and manipulation of passenger and driver data stored in networked databases, etc. In some embodiments, functionalities of theback end module 132 can, in whole or in part, be performed by one or more of the portal modules disclosed herein, and vice versa. Furthermore, in some embodiments, therideshare server 130 can include a single module for performing various functionalities. - Examples of
mobile devices - Electronic data communications between elements shown in
FIG. 1 can be achieved via one ormore networks 110, such as, but not limited to, a Local Area Network (LAN), Wireless Local Area Network (WLAN), Personal area network (PAN), or wireless wide area network (WWAN), enabled with technologies such as Global System for Mobile Communications (GSM), Personal Communications Service (PCS), Bluetooth, Wi-Fi, Fixed Wireless Data, 2G, 2.5G, 3G, 3G LTE, LTE Advanced, 4G, general packet radio service (GPRS), messaging protocols such as, TCP/IP, SMS, MMS, instant messaging, or any other wireless data networks or messaging protocols. Although not shown inFIG. 1 , it can be further understood that such communications may include one or more secure networks, gateways, or firewalls that provide information security from unwarranted intrusions and cyber attacks. In some embodiments, thelandmark server 130 includes functionality to allow it to communicate, for example, by using application programming interfaces (APIs), with various elements shown inFIG. 1 . -
FIG. 2 illustrates exemplary registration screens of a mobile device interface for registering drivers with an embodiment of the rideshare server, according to an embodiment of the present invention. For example, upon launching a mobile application associated with therideshare server 130 for the first time, a mobile application running on a driver's mobile device displays screen 210.Screen 210 shows various exemplary driver-related information fields such as a name field, a date of birth field, a gender field, a country field, a city field, an address field, and an email id field. For example, in some scenarios, the date of birth information can be used to determine an age of the driver, such that drivers under the age of twenty-one, for instance, are not allowed to sign up as drivers with the rideshare service. In such scenarios, the mobile application displays a message “You are Not Eligible to Drive.” Upon filling up the fields displayed on this screen, a driver clicks on a “Next” button to land atscreen 220. If the date of birth provided by the driver is a current date, then the mobile application displays a message on the screen of the mobile device. If the email id provided by the registering driver is in a wrong format, then the mobile application displays a message “Incorrect Email ID format.”Screen 210 also shows an option for a driver to upload his or her photograph via the mobile application running on the driver's mobile device, e.g., either by taking a photograph via the camera on the mobile device or uploading a pre-stored photograph saved in a memory of the mobile device.Screen 220 shows various exemplary fillable information fields of a vehicle that can be used to provide a rideshare trip. Example of such fields shown inscreen 220 are a vehicle number, a type of vehicle, a license number of the driver, a registration number of the vehicle, an insurance policy number of the vehicle, a license expiration date of the driver, a registration expiration date of the driver, an insurance expiration date, etc.Screen 220 also shows an option for uploading a photograph of the vehicle. Upon filling up the fields displayed on this screen, a driver clicks on a “Next” button to land atscreen 230.Screen 230 shows a driver's bank-related information such as a bank name and a bank account number, for receiving earnings associated with a ride share trip.Screen 230 also shows details to be filled by a driver for payments involving a (third party) payment processor. In some aspects, a driver can enter the information on the displayedregistration screens rideshare server 130, after the driver clicks a “Submit” button. In some embodiments, if the driver skips filling up any field, then the mobile application displays a message “All Fields are Mandatory.” In some embodiments, information provided by a driver during a registration process is communicated to therideshare server 130 for storage in a database. In some embodiments, some or all of the information provided by a driver during a registration process can be saved on the driver's mobile device. In some embodiments, therideshare server 130 keeps track of various dates, e.g., dates of registration renewal, license renewal, insurance renewal etc. Accordingly, in such embodiments, therideshare server 130 sends an email to the driver in advance of the renewal date(s) so that the driver can take necessary actions. -
FIG. 3 illustrates a mobile device interface for receiving biometric information from drivers, according to an embodiment of the present invention.Screen 310, used for entering a driver's bank information for receiving earnings associated with a rideshare trip is similar toscreen 230 shown inFIG. 2 .Screen 320 shows a predetermined scanning area on the screen of a driver's mobile device. The predetermined scanning area is a region inside which a driver can place his or her finger (right thumb, for example) in connection with providing the driver's biometric information. Drivers' mobile devices are configured to enable drivers to provide biometric information via a sensor coupled to or otherwise configured within a driver's respective mobile device.Screen 330 shows a message displayed on the screen of a driver's mobile indicating that the mobile application is processing an image associated with the biometric scan of a driver's finger. If the mobile application on the driver's mobile device determines that the biometric scan was successful,screen 340 shows an option to save the biometric scan. In some optional embodiments, as shown inscreen 340, the mobile application on the driver's mobile device can provide an option to re-take another biometric scan. In some embodiments, information provided by a driver during a registration process is communicated to therideshare server 130 for storage in a database. In some embodiments, some or all of the information provided by a driver during a registration process can be saved on the driver's mobile device. -
FIG. 3 also displays a portion of a computer-implementedinterface 350 that is linked to a database which stores the driver's biometric information.Interface 350 displays, for example, a driver (“provider”) with an id “1,” a name “Josh” having abiometric scan 360 linked to his employee account. Embodiments of the disclosed system utilize the biometric scan to authenticate the identity of a driver any time the driver launches the mobile application.Interface 350 also displays additional driver-related details such as a phone number, a linked photograph of a driver, a total number of trips that the driver has offered, and an approval status corresponding to whether the driver was approved by the system based on his background and driving history.Interface 350 also provides a drop-down menu displaying selectable actions that can be taken by an individual viewing this interface. AlthoughFIG. 3 displays fingerprint recognition as a biometric, embodiments of the disclosed system can also different types of biometric scan, such as, fingerprint, voice, or iris recognition, or a combination thereof. -
FIG. 4 illustrates a schematic indicating operations involving a driver'smobile app 402, a passenger'smobile app 408, arideshare server 130, anavigation API 440, and ageocoding server 116 associated with start of a trip, according to an embodiment of the present invention. It is noted that the operations shown inFIG. 4 are not necessarily performed in a sequence or in an order of any sort. According to some embodiments, a driver who offers to provide a rideshare trip provides a biometric scan via the driver's mobile app. In some embodiments, the biometric scan is compared against a pre-stored scan of the driver stored in the driver's mobile phone. For example, the pre-stored scan can be a scan provided by the driver at the time of registration. The process of comparing the biometric scan received from a driver with the pre-stored scan can, in some embodiments, be performed by the driver'smobile app 402. In some other embodiments, the driver's mobile app transmits the biometric scan torideshare server 130 for comparison against a pre-stored scan. - If the driver is authenticated (412), a driver receives the passenger's pickup location and the passenger's intended destination from geocoding server 116 (or, in some embodiments, from the rideshare server 130) displayed on a map. In some embodiments, the driver's
mobile app 402 integrates the received information updating the map displayed on the driver's mobile device with, for example, a real-time indication of the driver's location and the passenger's pickup location. For example, in some embodiments, thedriver app 402 can display a marker on a map corresponding to the driver's location and the passenger's pickup location. Further, as the driver travels towards the passenger's pickup location, the driver marker is shown to accordingly move on the map. In some embodiments, thedriver app 402 sends (416) real-time information relating to the updated map, e.g., displaying the markers to thegeocoding server 116. In some embodiments, the geocoding server transfers the information received from thedriver app 402 to therideshare server 130 in real time. In some other embodiments, thedriver app 402 sends real-time information relating to the updated map, e.g., displaying the markers directly to therideshare server 130. It will be understood and appreciated that functionalities wherein therideshare server 130 obtains a driver's real-time location allow therideshare server 130 to track the driver's location. Upon detecting that the driver has reached the location, the driver receives (at step 424) a notification of a start of a trip from therideshare server 130. In some embodiments, a driver first informs (via the driver's mobile app 402) therideshare server 130 that he or she has arrived at the passenger's pickup location before receiving a notification of a start of the trip from therideshare server 130. In some scenarios, a driver clicks on a Start Trip button viadriver app 402 to start a rideshare trip. Accordingly, therideshare server 130 is notified of the driver's input via thedriver app 402. In some embodiments, thepassenger app 408 receives a notification of a start of a trip from therideshare server 130. In some embodiments, thedriver app 402 sends (step 428) a passenger's pickup location and intended destination of the passenger to anavigation API 440. In turn, thenavigation API 440 guides the driver by providing (step 432) turn-by-turn directions to the intended destination. -
FIG. 5 illustrates a schematic indicating discrete pairwise operations involving a driver'smobile app 502, a passenger'smobile app 528, arideshare server 130, aweb portal 134, and ageocoding server 116 associated with end of a trip, according to an embodiment of the present invention. It is noted that the operations shown inFIG. 5 are not necessarily performed in a sequence or in an order of any sort. In some embodiments, geocodingserver 116 provides (step 506) information relating to a driver's current location, intended destination of the rideshare trip, a total time traveled, a total distance traveled, toll locations on the driver's route, etc. to therideshare server 130. Upon detecting that the driver has arrived at the intended destination, therideshare server 130 informs (step 510) the driver's mobile app that the driver has arrived at the intended destination. The driver'smobile app 502 responds (step 514) to therideshare server 130 that the rideshare trip has ended. Accordingly, an invoice reflecting a summary of the rideshare trip is sent (step 522) by the rideshare server to the passenger's mobile device. In some instances, a passenger can optionally provide (step 526) a tip amount and a rating/comments for the driver, via the passenger'smobile app 528. In some embodiments,rideshare server 130 provides (step 518) information relating to the rideshare trip, e.g., an invoice, a type of vehicle used, a distance traveled, a tip amount paid by the passenger to the driver, a rate per unit distance of travel that is used to calculate the fare, etc. This information can, in some embodiments, be provided to either or both of the driver and the passenger's account, which can be accessed viaweb portal 134, e.g., a driver web portal for a driver and a passenger web portal for a passenger. -
FIG. 6 illustrates exemplary operations associated with a driver's mobile app associated with authenticating an existing driver's identity, according to an embodiment of the present invention. For example, step 602 displays a mobile screen displaying an interface to capture a biometric scan of a driver's right thumb for authentication of a driver's identity. Accordingly, after a driver has provided his or her biometric scan, the biometric scan provided is compared against a driver's pre-stored biometric scan. In some embodiments, the comparison is performed at the driver's mobile device. In some embodiments, arideshare server 130 performs the comparison, after receiving the biometric scan provided by the driver via the mobile app. If the biometric scan provided (at step 604) by the driver matches with the pre-stored biometric scan, then the driver is allowed to proceed to the next step of launching the mobile app, e.g., the mobile app goes online allowing the driver to use the mobile app. However, if there is a mismatch, the driver's mobile app does not allow the driver to proceed further, e.g.,step 606.FIG. 6 also displays operations associated with a driver's mobile app, after a driver is authenticated successfully. Atstep 608, a driver logs in using login credentials such as a login id/password on his or her mobile device. The driver's credentials are verified (step 610). If the driver indicates that he or she has forgotten (step 612) their credentials, then an automated reset credentials link is sent to the driver by therideshare server 130 via email. If a driver's credentials are successfully verified, then the driver is allowed (step 616) access to the main screen of the mobile app. Otherwise, a driver is not allowed (step 618) access. In some embodiments, a driver is provided a unsuccessful verification message, if the driver's credentials are not verified successfully. -
FIG. 7 illustrates a flow diagram showing method steps of aprocess 700 by a mobile app for registering a driver on a mobile application running on a driver's mobile device, according to an embodiment of the present invention. Starting atstep 702, the process determines whether the driver chooses to register and provide his or her information via the mobile app. In some embodiments, a driver can choose to register via a third party app such as a social media network app, in lieu of, or in addition to, utilizing the mobile app (associated with the presently disclosed system) for entering his or her information. In such embodiments, the process can receive a driver's information from one or more respective third parties. In some embodiments, the disclosed system allows driver referrals in which an existing driver can refer a proposed driver to the system. Thus, the process determines (for example, based on information received from rideshare server) whether the registering driver has been referred by another driver, atstep 706. If the process determines that the registering driver has been referred by another driver, then the process jumps to step 722 and continues thereafter. - If, however, the process determines that the registering driver has not been referred by another driver, then the process moves to step 708 in which the mobile app receives information pertaining to the driver and the associated vehicle. In some embodiments, the mobile app running on the driver's mobile device also provides information identifying the driver's mobile device and the mobile app. For example, the mobile app can provide a mobile device's International Mobile Equipment Identity (IMEI) number, a mobile app ID, a type and version of the operating system running on the driver's mobile device, the operating system ID of the driver's mobile device, etc. At
step 710, the process displays a message on the screen of the driver's mobile device requesting the driver to provide a biometric scan. After receiving (at step 712) a biometric scan from the driver, the biometric scan is processed (at step 714). For example, the mobile app applies image processing methodologies to determine the edges, boundaries, minutiae of the biometric scan. In some scenarios, a biometric scan may not be correctly processed, for example, due to unrecognized artifacts in the biometric scan, or when the information in the biometric scan is not sufficient. Thus, the process determines (at step 716), if the scan is successful. If the scan is successful, the process moves to step 718 in which information relating to the scan is sent to therideshare server 130. If, however, the scan is not successful, the process lops back to step 710 in which the registering driver is requested to provide a biometric scan. Upon detecting a successful scan, the process displays (at step 720) a message on the screen of the mobile device indicating that registration was successful, and the process terminates thereafter. - In some embodiments if the process determines that the registering driver has been referred by another driver, then the process enters
step 734 in which the process requests the registering driver to provide a referral ID. Upon receiving an input from the registering driver, the process determines (at step 724) whether the registering driver submitted a referral ID, or not. In some scenarios, a driver casually entering information via the mobile app may inadvertently enter an option indicating he or she has been referred by another driver, but then realize later that the option was incorrectly entered. In such scenarios, the driver may not have a referral ID to provide. Thus, the process (at step 724) whether the registering driver submitted a referral ID, or not. Atstep 726, the mobile app communicates the referral ID to therideshare server 130. The server, in turn, sends verification information to the mobile app verifying (or, denying) the validity of the referral ID. This functionality, as can be appreciated, is to prevent a referral ID from being used multiple times or being used by unrecognized individuals associated with the referral ID, thereby preventing fraud. Based on the received verification information, the process determines if the verification for the referral ID was successful, atstep 730. If the verification was successful, the process moves to step 734 in which the referral chain setting in the driver's mobile app is updated. For example, the referral chain setting in the driver's mobile app can reflect the name of the driver who referred the registering driver, a number of hierarchical levels included in the referral chain of the registering driver, etc. If, however, verification of the referral ID was unsuccessful (at step 730), the mobile app provides (at step 732) the option to the registering driver to re-enter the referral ID, and the process loops back tostep 722. -
FIG. 8 illustrates a flow diagram showing method steps of aprocess 800 by a mobile app running on a driver's mobile device in connection with a driver offering to provide a rideshare trip, according to an embodiment of the present invention. Starting atstep 802, the process displays a message on a driver's mobile device requesting the driver to provide a biometric scan. Thus, in some embodiments, the driver's mobile app stays offline unless the driver provides his or her biometric scan. After receiving (at step 803) a biometric scan from the driver, the biometric scan is processed (at step 804). For example, the mobile app applies image processing methodologies to determine the edges, boundaries, minutiae of the biometric scan. In some scenarios, a biometric scan may not be correctly processed, for example, due to unrecognized artifacts in the biometric scan, or when the information in the biometric scan is not sufficient. Thus, the process determines (at step 806), if the scan is successful. If the scan is successful, the process moves to step 808 in which information relating to the scan is sent, in some optional embodiments, to therideshare server 130. If, however, the scan is not successful, the process lops back to step 802 in which the driver is requested to provide a biometric scan. - The process receives (at step 810) a response from the
rideshare server 130, the response including information relating to authentication of a driver's identity. Based on the response, the process determines (at step 812) whether the authentication was successful. If the authentication was unsuccessful, the process terminates. If, however, the authentication was successful, the process moves to step 814 in which the process receives information pertaining to a passenger's pickup location (e.g., in the form of a latitude longitude or a street address) from therideshare server 130. In some embodiments, the pickup location is displayed on a map. In some instances, information included in the map is provided by ageocoding server 116 to therideshare server 130 which then conveys the same to the driver's mobile app via the Internet. Atstep 816, the process displays a message on the screen of the driver's mobile device indicating that the authentication was successful. In some embodiments, the message indicating successful authentication can be received prior to the process receiving the passenger's pickup location from therideshare server 130. After the driver drives to the passenger's pickup location, in some embodiments, the process waits for a selection from the driver indicating arrival at the passenger's pickup location. After receiving (at step 818) a selection from the driver indicating arrival at the passenger's pickup location, the process displays (at step 820) a message indicating a start of a rideshare trip, assuming the passenger gets in the driver's vehicle. In some embodiments, the process displays route information relating to the rideshare trip on a screen of the driver's mobile device in real-time until the passenger arrives at the passenger's intended destination. The route information, for example, can be obtained from ageocoding server 116. Upon arriving at the passenger's intended destination, the process displays an indication of the end of the rideshare trip and a cost associated with the rideshare trip. In some optional embodiments, the process enables a driver to enter (at step 824) passenger rating information (e.g., on a five star scale, or some other scale) via the mobile app running on the driver's mobile device. The process terminates thereafter. In some embodiments, upon completion of a trip, the mobile app running on the driver's mobile device goes offline, i.e., breaks network connections with therideshare server 130. Accordingly, in such embodiments, a driver provides his or her biometric scan via the mobile app, for the mobile app to come back online. In some embodiments, the process of matching or comparison a driver's biometric scan with a pre-stored scan can be performed at the driver's mobile device, e.g., by the mobile app running on the driver's mobile device. In such embodiments, the mobile app does not necessarily need to send the biometric scan to therideshare server 130, and accordingly, no response from therideshare server 130 with regard to comparison of biometric scans would be necessary, i.e. steps 808 and 810 in the flow diagram would be optional. -
FIG. 9 illustrates a flow diagram showing method steps of aprocess 900 by a mobile app running on a passenger's mobile device in connection with a passenger availing a rideshare trip, according to an embodiment of the present invention. Starting atstep 902, the process receives a passenger's pickup location (e.g., in the form of an address) from a passenger via the mobile app running on the passenger's mobile device. The process transmits the pickup location to the rideshare server atstep 904. Therideshare server 130 responds back with information about the rideshare driver and the driver's vehicle, which is received by the process atstep 906. For example, theride share server 130 can provide a name and contact information (e.g., phone number, email, etc.) of the driver, a photograph of the driver, a make, year, model and photograph of the vehicle that the driver is driving. In some instances, therideshare server 130 provides an estimate of the rideshare trip to the passenger. After the driver drives to the passenger's pickup location, in some embodiments, the process displays (at step 908) a message indicating a start of a rideshare trip, assuming the passenger gets in the driver's vehicle. In some embodiments, the process displays route information relating to the rideshare trip on a screen of the passenger's mobile device in real-time until the passenger arrives at the passenger's intended destination. The route information, for example, can be obtained from ageocoding server 116. Upon arriving at the passenger's intended destination, the process displays (at step 912) end of the rideshare trip and a cost associated with the rideshare trip. In some optional embodiments, the process enables a passenger to enter (at step 914) driver rating information (e.g., on a five star scale, or some other scale) via the mobile app running on the passenger's mobile device. The process terminates thereafter. In some embodiments, a driver can view, for example by accessing a driver portal or via a mobile application, the rating information (e.g., comments/feedback etc.) provided by passengers along with an associated date and time. -
FIG. 10 illustrates a flow diagram showing method steps of aprocess 1000 by a rideshare server identifying referral chains, according to an embodiment of the present invention. In this flow diagram, it is assumed that an existing driver (referrer or “Driver A”) suggests a new driver (referee or “Driver B”) to sign up with the rideshare service. For example, a referrer can share a referral ID provided by therideshare server 130 with the referee. Starting atstep 1002, the process receives registration information of driver B during an initial registration process, for example, after launching the driver's mobile app for the first time on driver B's mobile device. The registration information can include, for example, the driver's biometric scan, the driver's personal information, the driver's vehicle information, etc. In some aspects, a registered driver notifies therideshare server 130 that he or she has provided a referral ID to driver B. Accordingly, when driver B registers with the rideshare service, driver B may be required to provide the referral ID provided by the registered driver. Such a methodology can prevent fraud when driver learns B about the rideshare service from a registered driver, but does not provide the referral ID provided by the registered driver, in an attempt not to share his or her earnings with the registered driver. - The process determines (at step 1004) if driver B has indicated, as part of the registration process, as being referred by another driver A. If the process determines that the driver B has indicated as not being referred by a driver, then the process terminates. If, however, the process determines that the driver B has indicated as being referred by an existing driver, then the process receives a referral ID provided by driver B. Thus, the process determines (at step 1006) if the referral ID provided by driver B is a valid referral ID. For example, the process determines if the referral ID has been used multiple times, or is being used by unrecognized individuals associated with the referral ID. If the process determines that the referral ID is not valid, then the process terminates. In some embodiments, the process displays a message indicating that the referral ID provided by driver B is not valid.
- If, however, the referral ID is determined to be valid, then the process also determines (at step 1008) whether an existing driver A has notified the
rideshare server 130 of sharing the referral ID with driver B. If the process determines that no existing driver A has notified therideshare server 130 of sharing the referral ID with a driver B, then the process terminates, suspecting fraud by registering driver B. If the process determines, however, that an existing driver A has notified therideshare server 130 of sharing the referral ID with a driver B, then the process updates (at step 1010) a database to reflect the referrer/referee relationship between driver A and driver B. In some embodiments, the process communicates the referrer/referee relationship between driver A and driver B to either, or both, driver A and driver B's mobile app running on their respective mobile devices. The process terminates thereafter. In some embodiments, a network marketer can provide referral of proposed new drivers to therideshare server 130 via the network marketer portal. A network marketer is an individual or an entity that is not a registered driver of the rideshare service and provides referral of proposed new drivers to therideshare server 130. A network marketer can earn percentages of a driver's earnings if such a driver was referred by a network marketer and signed up with the rideshare service. In some embodiments, the process of identifying referral chains involving network marketers is similar to that in which an existing driver (referrer or “Driver A”) suggests a new driver (referee or “Driver B”) as discussed inFIG. 10 , with Driver A being replaced by a network marketer as suitable. -
FIG. 11 illustrates several mobiledevice interface screens 1100 of a driver's mobile app, according to an embodiment of the present invention. Forexample screen 1102 shows options in connection with at least the following inventive features: referring a proposed new driver (a “Refer” button), viewing a profile of the driver associated with the mobile app (a “Profile” button), viewing information about the rideshare service (an “About Us” button), viewing recent rideshare trips offered by the driver associated with the mobile app (a “My Recent Trips” button), viewing toll rates at a geographical location (a “Toll Rates” button), viewing a cost of a last rideshare trip offered by the driver associated with the mobile app (a “Fare Amount” button), facilitating a call with a driver support phone number (a “Call Support” button), and viewing a driver's personal settings on the mobile app (a “Driver's Settings” button).Screen 1104 shows clickable options for launching mobile apps of third parties such as social media network and social texting apps from the driver's mobile app.Screen 1106 displays an exemplary driver referral chain involving three drivers. For example,screen 1106 shows a driver John referred a driver Jason who referred a driver Tom. Thus, driver John that is associated with the mobile app accumulates earnings from drivers Jason and Tom. -
FIGS. 12-14 illustrate interfaces showing earnings accumulated via a driver's referral chain, according to an embodiment of the present invention. According to embodiments of the present disclosure, the interfaces inFIGS. 12-14 can be viewed by a system administrator associated with the rideshare service.Region 1202 of FIG.12 displays four exemplary referral chains 1212 (chain 1), 1214 (chain 2), 1216 (chain 3), and 1214 (chain 4), each chain showing percentage contributions of a driver to the rideshare service. Embodiments of the present disclosure facilitate a hierarchical earning structure such that the rideshare service retains a percentage from each driver in a referral chain. For example, in a referral chain in whichdriver 1 refersdriver 2,driver 2 refersdriver 3,driver 3 refersdriver 4, and so on, the rideshare service retains 15% ofdriver 1's earnings, 11% ofdriver 2's earnings, 8.5% ofdriver 3's earnings, 7% ofdriver 4's earnings, and so on. These percentages are displayed as percentage deductions inline 1206 ofFIG. 12 . Lines1208 and 1210 ofFIG. 12 respectively display a total amount earned by each driver in a referral chain from offering rideshare services, and an amount retained by the rideshare service from each driver's earnings. -
Region 1204 ofFIG. 12 shows each driver's earnings from their referral chain network.Column 1226 shows percentage earnings by a respective driver from other drivers in their referral chain network, e.g.,driver 1 earns 4% ofdriver 2's earnings, 2.5% ofdriver 3's earnings, 1.5% ofdriver 4's earnings, and so on.Column 1228 displays a respective monetary amount corresponding to each percentage incolumn 1228.Column 1230 displays a total amount earned by a driver by accumulating his or her earnings from the driver's referral chain.Referral chains drivers FIG. 13 displays a detailed view of an exemplary referral chain showing percentages retained by the rideshare service and percentage earnings associated with each driver in the chain.FIG. 13 demonstrates that the percentages retained by the rideshare service can be similar as those discussed forchain 1 inFIG. 12 . For example,region 1302 inFIG. 13 shows a referral chain in which driver pqr refers driver android, driver android refers driver nexus, driver nexus refers driver blackberry, and so on, the ridesharing service retains 15% of driver pqr's earnings, 11% of driver android's earnings, 8.5% of driver nexus' earnings, 7% of driver blackberry's earnings, and so on. In some embodiments, there can be theoretically infinite levels of distribution of earnings. Percentages associated with each level can be varied by a system administrator of therideshare server 130.Region 1304 inFIG. 13 shows percentage earnings by a respective driver from other drivers in their referral chain network (e.g., similar tocolumn 1226 inFIG. 12 ), a respective monetary amount corresponding to each percentage (e.g., similar tocolumn 1228 inFIG. 12 ), and a total amount earned by a driver by accumulating his or her earnings from the driver's referral chain (e.g., similar tocolumn 1228 inFIG. 13 ).FIG. 14 presents a magnified view of percentage earnings (region 1402) retained by the rideshare service from a respective driver and other drivers in the subject driver's referral chain network, similar toregion 1302 shown inFIG. 13 . -
FIG. 15 illustrates aninterface 1500 displaying a driver's earnings history, according to an embodiment of the present invention. As shown inFIG. 15 , the interface can display columns 1502 (“Passenger ID”), 1504 (“Passenger Name”), 1506 (“Date of Rideshare Trip”), 1508 (“Earned Fare”), 1510 (“Tip”), 1512 (“Toll Amount”), and 1514 (“Total Payable Amount”). For example,FIG. 15 shows earnings for a driver pqr from passengers Akshata (identified by passenger id 16) and John (identified by passenger id 20), the dates on which the rideshare trips were offered, a cost of the rideshare trip, a tip paid by each passenger to driver pqr, and a toll amount payable to the driver by the rideshare service in connection with the trip.FIG. 15 also displays a total payable amount to driver pqr based on the sum of the cost of the trip, the tip paid by a passenger and the toll amount. According to embodiments of the present disclosure, the interface inFIG. 15 can be viewed by driver pqr or a system administrator associated with the rideshare service. In some embodiments, the system provides options to enter a start date and an end date over which a driver's earnings history is displayed. -
FIG. 16 illustrates aninterface 1600 showing a passenger's trip history, as viewed by a system administrator associated with the rideshare service, according to an embodiment of the present invention. As shown inFIG. 16 , the interface can display columns 1602 (“Request ID”), 1604 (“Owner Name”), 1606 (“Driver”), 1608 (“Date”), 1610 (“Time”), 1612 (“Status”), 1614 (“Amount”), and 1618 (“Payment Status”). A request ID column is a unique identifier corresponding to an instance of a rideshare request from a passenger. A Status column provides a status of the rideshare trip. A Payment Status column provides information pertaining to receiving a payment for a rideshare trip from a passenger's financial institution. There could be multiple payment statuses associated with a trip, e.g., completed or request not completed depending on whether the payment has been received from a passenger's financial institution or not. In some embodiments, the system provides options to enter a start date and an end date over which a passenger's trip history is displayed. -
FIG. 17 illustrates aninterface 1700 showing a passenger's pickup location with respect to a rideshare driver's location displayed on a map, according to an embodiment of the present invention. For example, a rideshare driver's (provider's)location 1702 is relatively near the passenger's (user's)location 1704. According to embodiments of the present disclosure, theinterface 1700 can be viewed on the mobile app running on the driver's mobile device and/or the mobile app running on the passenger's mobile device. In some embodiments, a system administrator can view/track the driver's movement and/or the passenger's movement via an interface similar tointerface 1700. Thus, according to inventive aspects disclosed herein, the system can obtain in real-time, a number and location of drivers at a geographical location who are offering to provide rideshare trips to passengers. Such aspects are beneficial in selecting, for instance, a driver that is located closest to a passenger's location such that the driver can arrive at the passenger's pickup location in a short time. -
FIGS. 18-19 illustrateinterfaces FIG. 18 , the interface can display columns 1802 (“Driver ID”), 1804 (“Name”), 1806 (“Email”), 1808 (“Phone”), 1810 (“Photo”), 1812 (“Bio”), 1814 (“Total Requests”), 1816 (“Status”), and 1818 (“Actions”). Photo column provides a link to a driver's photo saved in the database. Total Requests column indicates a total number of rideshare requests made to a driver by passengers. Status column indicates whether the driver was approved based on passing a background check and driving history. Action column provides a drop-down menu of selectable actions such as decline, set target, edit details, and view details. The decline option removes the driver from the database. The system administrator can view and edit driver-related information saved in the database, by selecting the edit details or view details options. The set target option can be used by a system administrator to set a target amount that a driver is required to earn between a start date and an end date. In some embodiments, a driver can view the days remaining to reach a target amount. The interface generated upon selecting the set target option is shown in greater detail in region 1902 ofFIG. 19 . In some embodiments, the set target option is applicable only to drivers who are part of a referral chain. That is, this functionality, in some embodiments, is disabled for drivers that are not part of a referral chain. -
FIG. 20 illustrates a passenger database, according to an embodiment of the present invention. As shown inFIG. 20 , the interface can display columns 2002 (“ID”), 2004 (“Name”), 2006 (“Email”), 2008 (“Phone”), 2010 (“Address”), 2012 (“State”), 2014 (“Zipcode”), and 2016 (“Actions”). Actions column provides a drop-down menu of selectable actions such as edit passenger details, view history of a passenger's rideshare trips, and view additional passenger-related information saved in database. -
FIGS. 21-22 illustrateinterfaces rideshare server 130 via the network marketer portal. A network marketer is an individual or an entity that is not a registered driver of the rideshare service and provides referral of proposed new drivers to therideshare server 130. A network marketer can earn percentages of a driver's earnings if such a driver was referred by a network marketer and signed up with the rideshare service. When a network marketer clicks on a (“View Profile”)button 2102 on theinterface 2100 A, theinterface 2100B is displayed. Region 2108 ofinterface 2100A displays a subscription status of a network marketer and a subscription expiration date of a network marketer. In some embodiments, a network marketer has to keep an active subscription with the rideshare service to be able to refer new drivers and/or earn percentages of a referred driver's earnings. In some embodiments, a driver that was referred by a network marketer can refer new drivers to the rideshare service. In such scenarios, a network marketer earns percentages of all drivers that are included in the subject driver's referral chain, in addition to the earnings of the subject driver. A “Referral Tree”button 2103 displays a network marketer's referral tree.Interface 2100B displays a “View Profile” interface to a network marketer. For example,region 2104 displays registration information that is typically provided by a network marketer when he or she signs up with the rideshare service.Region 2104 includes example fields such as a first name, a last name, a date of birth, a gender, an email address, a password along with a confirm password, an address including a state, a city and a country.Region 2104 also includes an option for a network marketer to add a profile picture. In some embodiments,region 2104 includes driver-related fields such as a vehicle number, a type of vehicle, a license number of the driver, a registration number of the vehicle, an insurance policy number of the vehicle, a license expiration date of the driver, a registration expiration date of the driver, an insurance expiration date, etc. However, such driver-related fields can be deactivated (shown with a “*” inFIG. 21 ), and accordingly, a network marketer would not be able to input data relating to such fields. Additionally,interface 2200B shows aregion 2110 for providing a network marketer's bank-related information to therideshare server 130. For example,region 2110 includes a router/routing number of a bank, a bank name, a credit card number along with its expiry date and its CVV number. In some embodiments,region 2110 includes areferral ID button 2112. In some embodiments, when a network marketer clicks onbutton 2112, therideshare server 130 generates dynamically a referral ID that can be shared with a proposed new driver or sent via email to the proposed new driver. In some embodiments, therideshare server 130 retrieves a pre-generated referral ID and presents it to the network marketer, in response to the network marketer clicking onbutton 2112. -
FIG. 22 illustrateinterfaces Interface 2200A is similar tointerface 2100A. For example, interface 2200 displays a network marketer having anID 12, and a name John Kerry having a subscription expiry date of Jul. 21, 2015, and a number of drivers (e.g., zero) referred by the network marketer. A “Subscription Status”button 2210 when clicked on this interface reveals whether the network marketer's subscription is expired or still subscribed, indicated inbox 2208.Interface 2200B also includes aStatus button 2214, which when clicked, reveals the names of the drivers that were referred by the network marketer. In some embodiments, existing drivers cannot be referred by a network marketer to the rideshare service. In some embodiments, an existing network marketer can refer another driver by clicking on a ReferDriver button 2206. In some embodiments, an existing network marketer can refer another network marketer by clicking on a Refer Network Marketer button 2204. New driver referrals and new network marketer referrals can be made by social media networks or via email, e.g., as shown inbox 2212. For example, if a new driver is referred, then a downloadable link to a driver's mobile application is shared, inviting the new driver to sign up with the rideshare service. If a new network marketer is being referred, then a link to the network marketer portal (for signup) is shared. - The terminology used in the description presented below is intended to be interpreted in its broadest reasonable manner, even though it is being used in conjunction with a detailed description of certain specific examples of the technology. Certain terms may even be emphasized below, however, any terminology intended to be interpreted in any restricted manner will be overtly and specifically defined as such in this Detailed Description section.
- In this disclosure, numerous specific details have been set forth in order to provide a thorough understanding of embodiments of the present disclosure. It will be apparent, however, to one skilled in the art that embodiments of the present disclosure may be practiced without some of these specific details.
- Embodiments of the present disclosure include various steps. The steps may be performed by hardware components or may be embodied in machine-executable instructions, which may be used to cause a general-purpose or special-purpose processor programmed with the instructions to perform the steps. Alternatively, the steps may be performed by a combination of hardware, software and/or firmware. As will be understood, the steps of the processes shown in
FIGS. 7-10 are not necessarily completed in the order shown, and various steps may operate concurrently and continuously. It will be understood that the drawings and discussions herein refer to two items of digital content, i.e. a first item and a second item. But such drawings and discussions are for exemplary purposes only. In alternate embodiments, multiple (e.g., more than two) items of digital content can be used as a part of a validation process. - Embodiments of the present disclosure may be provided as a computer program product, which may include a machine-readable medium having stored thereon instructions, which may be used to program a computer (or other electronic devices) to perform a process. The machine-readable medium may include, but is not limited to, floppy diskettes, optical disks, compact disc read-only memories (CD-ROMs), and magneto-optical disks, ROMs, random access memories (RAMs), erasable programmable read-only memories (EPROMs), electrically erasable programmable read-only memories (EEPROMs), field programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), vehicle identity modules (VIMs), magnetic or optical cards, flash memory, or other type of media/machine-readable medium suitable for storing electronic instructions.
- Moreover, embodiments of the present disclosure may also be downloaded as a computer program product or data to be used by a computer program product, wherein the program, data, and/or instructions may be transferred from a remote computer to a requesting computer by way of data signals embodied in a carrier wave or other propagation medium via a communication link (e.g., a modem or network connection).
Claims (1)
1. A method for facilitating vehicle rideshares to passengers by drivers via drivers' mobile devices, the method comprising:
receiving, via a user interface of a driver's mobile device, registration information from a driver, wherein the registration information includes a first biometric scan of the driver;
transmitting the registration information to a ridesharing server;
in response to detecting that the driver selects to provide a rideshare trip requested by a passenger, prompting the driver, via the user interface, to provide a second biometric scan;
upon receiving the second biometric scan from the driver, comparing the first biometric scan and the second biometric scan for a match; and
in response to detecting the match, providing pickup information to the driver, wherein the pickup information includes a name of the passenger and a pickup location of the passenger.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US17/464,453 US20210398180A1 (en) | 2014-12-11 | 2021-09-01 | Method and system for ride shares involving hierarchical driver referrals |
Applications Claiming Priority (4)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US201462124196P | 2014-12-11 | 2014-12-11 | |
US14/938,129 US20160171574A1 (en) | 2014-12-11 | 2015-11-11 | Method And System For Ride Shares Involving Hierarchical Driver Referrals |
US16/426,970 US11120487B2 (en) | 2014-12-11 | 2019-05-30 | Method and system for ride shares involving hierarchical driver referrals |
US17/464,453 US20210398180A1 (en) | 2014-12-11 | 2021-09-01 | Method and system for ride shares involving hierarchical driver referrals |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US16/426,970 Continuation US11120487B2 (en) | 2014-12-11 | 2019-05-30 | Method and system for ride shares involving hierarchical driver referrals |
Publications (1)
Publication Number | Publication Date |
---|---|
US20210398180A1 true US20210398180A1 (en) | 2021-12-23 |
Family
ID=56108271
Family Applications (3)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US14/938,129 Abandoned US20160171574A1 (en) | 2014-12-11 | 2015-11-11 | Method And System For Ride Shares Involving Hierarchical Driver Referrals |
US16/426,970 Active 2035-11-17 US11120487B2 (en) | 2014-12-11 | 2019-05-30 | Method and system for ride shares involving hierarchical driver referrals |
US17/464,453 Abandoned US20210398180A1 (en) | 2014-12-11 | 2021-09-01 | Method and system for ride shares involving hierarchical driver referrals |
Family Applications Before (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US14/938,129 Abandoned US20160171574A1 (en) | 2014-12-11 | 2015-11-11 | Method And System For Ride Shares Involving Hierarchical Driver Referrals |
US16/426,970 Active 2035-11-17 US11120487B2 (en) | 2014-12-11 | 2019-05-30 | Method and system for ride shares involving hierarchical driver referrals |
Country Status (2)
Country | Link |
---|---|
US (3) | US20160171574A1 (en) |
WO (1) | WO2016094823A1 (en) |
Families Citing this family (51)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20170286884A1 (en) | 2013-03-15 | 2017-10-05 | Via Transportation, Inc. | System and Method for Transportation |
US11244254B2 (en) | 2014-12-31 | 2022-02-08 | The City And County Of San Francisco | Application-based commercial ground transportation clearinghouse system |
US20160189067A1 (en) * | 2014-12-31 | 2016-06-30 | The City And County Of San Francisco | Application-based commercial ground transportation management system |
US20180137583A1 (en) * | 2015-04-30 | 2018-05-17 | Ent. Services Development Corporation Lp | Journey and charge presentations at mobile devices |
US20160356615A1 (en) * | 2015-06-05 | 2016-12-08 | MuV Technologies, Inc. | Scheduled and On-Demand Transportation Management Platform for Rideshare |
US10013697B1 (en) * | 2015-09-02 | 2018-07-03 | State Farm Mutual Automobile Insurance Company | Systems and methods for managing and processing vehicle operator accounts based on vehicle operation data |
US10157436B2 (en) | 2015-10-09 | 2018-12-18 | Gt Gettaxi Limited | System for navigating vehicles associated with a delivery service |
SG10201509383SA (en) * | 2015-11-13 | 2017-06-29 | Mastercard International Inc | An electronic safety system for a vehicle |
US9771018B2 (en) * | 2015-12-03 | 2017-09-26 | Opus Inspection, Inc. | System and method for identification of transport vehicles and drivers |
US10810533B2 (en) * | 2015-12-30 | 2020-10-20 | Lyft, Inc. | System for navigating drivers to passengers and dynamically updating driver performance scores |
US10794713B2 (en) | 2015-12-31 | 2020-10-06 | Lyft, Inc. | System for navigating drivers to passengers based on start times of events |
US20170323378A1 (en) * | 2016-05-09 | 2017-11-09 | Bank Of America Corporation | System for triggering of living option resource allocation |
MX2018016065A (en) | 2016-06-24 | 2019-03-28 | Crown Equip Corp | Electronic badge to authenticate and track industrial vehicle operator. |
EP4184461A1 (en) | 2016-06-24 | 2023-05-24 | Crown Equipment Corporation | Indirect electronic badge tracking |
US11176500B2 (en) | 2016-08-16 | 2021-11-16 | Teleport Mobility, Inc. | Interactive real time system and real time method of use thereof in conveyance industry segments |
US11182709B2 (en) | 2016-08-16 | 2021-11-23 | Teleport Mobility, Inc. | Interactive real time system and real time method of use thereof in conveyance industry segments |
US11087252B2 (en) * | 2016-08-16 | 2021-08-10 | Teleport Mobility, Inc. | Interactive real time system and real time method of use thereof in conveyance industry segments |
US10160412B2 (en) * | 2016-10-10 | 2018-12-25 | Paypal, Inc. | System configurations to retrieve review data and transmit notifications to mobile devices |
US11068837B2 (en) * | 2016-11-21 | 2021-07-20 | International Business Machines Corporation | System and method of securely sending and receiving packages via drones |
US10168167B2 (en) | 2017-01-25 | 2019-01-01 | Via Transportation, Inc. | Purposefully selecting longer routes to improve user satisfaction |
US10147325B1 (en) | 2017-02-02 | 2018-12-04 | Wells Fargo Bank, N.A. | Customization of sharing of rides |
JP6604985B2 (en) * | 2017-03-17 | 2019-11-13 | 本田技研工業株式会社 | Navigation system, user terminal, and navigation method |
US11030710B2 (en) * | 2017-03-24 | 2021-06-08 | Kolapo Malik Akande | System and method for ridesharing |
US11755960B2 (en) * | 2017-05-04 | 2023-09-12 | Lyft, Inc. | System and method for reserving drivers with minimum fare offers and navigating drivers to service transportation requests |
CA3062780C (en) | 2017-05-08 | 2023-09-26 | Arnold CHASE | Mobile device for autonomous vehicle enhancement system |
US10839684B2 (en) * | 2017-05-08 | 2020-11-17 | Arnold Chase | Direct vehicle engagement system |
CN109429507A (en) * | 2017-06-19 | 2019-03-05 | 北京嘀嘀无限科技发展有限公司 | System and method for showing vehicle movement on map |
US11493348B2 (en) | 2017-06-23 | 2022-11-08 | Direct Current Capital LLC | Methods for executing autonomous rideshare requests |
WO2019023324A1 (en) | 2017-07-26 | 2019-01-31 | Via Transportation, Inc. | Systems and methods for managing and routing ridesharing vehicles |
US10706487B1 (en) | 2017-11-11 | 2020-07-07 | Lyft, Inc. | Dynamically generating and updating multipliers for a transportation matching system using machine learning |
JP6408118B1 (en) * | 2017-12-12 | 2018-10-17 | ヤフー株式会社 | Information processing apparatus, information processing method, and information processing program |
US11106927B2 (en) | 2017-12-27 | 2021-08-31 | Direct Current Capital LLC | Method for monitoring an interior state of an autonomous vehicle |
WO2019136341A1 (en) | 2018-01-08 | 2019-07-11 | Via Transportation, Inc. | Systems and methods for managing and scheduling ridesharing vehicles |
US10853629B2 (en) * | 2018-02-20 | 2020-12-01 | Direct Current Capital LLC | Method for identifying a user entering an autonomous vehicle |
US11620592B2 (en) | 2018-04-09 | 2023-04-04 | Via Transportation, Inc. | Systems and methods for planning transportation routes |
JP7214983B2 (en) * | 2018-06-12 | 2023-01-31 | トヨタ自動車株式会社 | Information processing device and information processing method |
KR102575718B1 (en) | 2018-09-05 | 2023-09-07 | 현대자동차주식회사 | Apparatus and server for sharing position information of vehicle |
US10552773B1 (en) * | 2018-09-07 | 2020-02-04 | Lyft, Inc. | Efficiency of a transportation matching system using geocoded provider models |
US11074539B2 (en) * | 2018-10-02 | 2021-07-27 | General Motors Llc | Vehicle usage assessment of drivers in a car sharing service |
CN109583612B (en) * | 2018-11-23 | 2020-10-30 | 首约科技(北京)有限公司 | Method, system and storage medium for determining car pool driver |
KR20200067015A (en) * | 2018-12-03 | 2020-06-11 | 현대자동차주식회사 | Apparatus and server for sharing position information of vehicle |
CN111612558A (en) * | 2019-02-25 | 2020-09-01 | 福特全球技术公司 | Method and system for travel offers |
US11620608B2 (en) | 2019-02-28 | 2023-04-04 | Walmart Apollo, Llc | System and method for providing uniform tracking information with a reliable estimated time of arrival |
US11716616B2 (en) * | 2019-05-06 | 2023-08-01 | Pointr Limited | Systems and methods for location enabled search and secure authentication |
US20200387993A1 (en) * | 2019-06-07 | 2020-12-10 | Didi Research America, Llc | Analyzing passenger gender on a ridesharing platform |
US20210067350A1 (en) * | 2019-09-04 | 2021-03-04 | Adero, Inc. | Presence and identity verification using wireless tags |
US11562374B2 (en) * | 2019-09-05 | 2023-01-24 | Veri Rideshare L.L.C. | Rideshare verification |
US20210192663A1 (en) * | 2019-12-19 | 2021-06-24 | Lyft, Inc. | Systems and methods for communicating a predicted match to an offline transportation provider device |
CN111736787A (en) * | 2020-06-24 | 2020-10-02 | 北京云族佳科技有限公司 | Screen sharing method and device, storage medium and electronic equipment |
WO2022020650A1 (en) * | 2020-07-22 | 2022-01-27 | Justtraffic Inc. | Crowd sourced traffic and vehicle monitoring system |
IT202100014768A1 (en) * | 2021-06-07 | 2022-12-07 | Exerbe S R L | METHOD FOR MANAGING TRANSFER REQUESTS FOR A TRANSFER SERVICE WITH DRIVER TO A COLLECTIVE DESTINATION |
Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20080270019A1 (en) * | 2006-12-29 | 2008-10-30 | High Regard Software, Inc. | Systems and methods for enhancing private transportation |
US20110196726A1 (en) * | 2009-08-10 | 2011-08-11 | Devi Poellnitz | System of Artist Referral and Media Selling, Promoting and Networking |
US8344849B2 (en) * | 2005-07-11 | 2013-01-01 | Volvo Technology Corporation | Method for performing driver identity verification |
US20150379544A1 (en) * | 2013-01-31 | 2015-12-31 | Referme Holdings Pty Ltd | Method and system for rewarding referrals |
US20160352713A1 (en) * | 2015-05-27 | 2016-12-01 | Thomas GRISSEN | Methods and systems for ensuring that an individual is authorized to conduct an activity |
Family Cites Families (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5694594A (en) * | 1994-11-14 | 1997-12-02 | Chang; Daniel | System for linking hypermedia data objects in accordance with associations of source and destination data objects and similarity threshold without using keywords or link-difining terms |
US6366682B1 (en) * | 1994-11-28 | 2002-04-02 | Indivos Corporation | Tokenless electronic transaction system |
US7627422B2 (en) * | 2003-06-24 | 2009-12-01 | At&T Intellectual Property I, Lp | Methods, systems and computer program products for ride matching based on selection criteria and drive characteristic information |
US7756633B2 (en) * | 2007-05-11 | 2010-07-13 | Palo Alto Research Center Incorporated | System and method for security enhanced rideshare |
US20090248587A1 (en) * | 2007-08-31 | 2009-10-01 | Van Buskirk Peter C | Selectively negotiated ridershare system comprising riders, drivers, and vehicles |
US8750902B2 (en) * | 2011-05-31 | 2014-06-10 | Verizon Patent And Licensing Inc. | User profile-based assistance communication system |
US8799038B2 (en) * | 2011-09-07 | 2014-08-05 | National Tsing Hua University | Dynamic taxi-sharing system and sharing method thereof |
-
2015
- 2015-11-11 US US14/938,129 patent/US20160171574A1/en not_active Abandoned
- 2015-12-11 WO PCT/US2015/065288 patent/WO2016094823A1/en active Application Filing
-
2019
- 2019-05-30 US US16/426,970 patent/US11120487B2/en active Active
-
2021
- 2021-09-01 US US17/464,453 patent/US20210398180A1/en not_active Abandoned
Patent Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8344849B2 (en) * | 2005-07-11 | 2013-01-01 | Volvo Technology Corporation | Method for performing driver identity verification |
US20080270019A1 (en) * | 2006-12-29 | 2008-10-30 | High Regard Software, Inc. | Systems and methods for enhancing private transportation |
US20110196726A1 (en) * | 2009-08-10 | 2011-08-11 | Devi Poellnitz | System of Artist Referral and Media Selling, Promoting and Networking |
US20150379544A1 (en) * | 2013-01-31 | 2015-12-31 | Referme Holdings Pty Ltd | Method and system for rewarding referrals |
US20160352713A1 (en) * | 2015-05-27 | 2016-12-01 | Thomas GRISSEN | Methods and systems for ensuring that an individual is authorized to conduct an activity |
Also Published As
Publication number | Publication date |
---|---|
WO2016094823A1 (en) | 2016-06-16 |
US11120487B2 (en) | 2021-09-14 |
US20160171574A1 (en) | 2016-06-16 |
US20190295142A1 (en) | 2019-09-26 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US20210398180A1 (en) | Method and system for ride shares involving hierarchical driver referrals | |
US11113679B2 (en) | Method and system for cardless use of an automated teller machine (ATM) | |
US20240029067A1 (en) | Systems and methods for secure provisioning of access to tiered databases | |
US11710162B2 (en) | Utilizing a vehicle to determine an identity of a user | |
US10412536B2 (en) | Providing secure service provider reverse auctions using certification identifiers, symmetric encryption keys and encrypted uniform resource locators | |
US10037531B2 (en) | Identity verification and authentication | |
US11756032B2 (en) | Methods and systems for secure payment processing | |
CN108713307B (en) | Method, apparatus and system for authenticating a user in a transaction using an onboard system | |
US20180276674A1 (en) | Secure Transactions from a Connected Automobile Based on Location and Machine Identity | |
CN110892676A (en) | Token provisioning using a secure authentication system | |
US20160071082A1 (en) | Automated splitting of costs incurred during a shared vehicle travel | |
US20150088744A1 (en) | Transaction Authentication | |
US20150278810A1 (en) | Device commerce using trusted computing system | |
US9603019B1 (en) | Secure and anonymized authentication | |
WO2015100185A1 (en) | Systems and methods for transportation check-in and payment using beacons | |
US20150134508A1 (en) | Expedited person to person payment | |
US9763271B1 (en) | Networked Wi-Fi stations having multi-level displays and multiple antennas | |
HUE026214T2 (en) | A qualified electronic signature system, associated method and mobile phone device for a qualified electronic signature | |
US10872134B2 (en) | Method and system for identifying pre-identified or pre-selected groups of individuals for transportation | |
EP3693899A1 (en) | Methods and systems for navigating drivers to passengers based on trustworthiness ratings | |
US20200349474A1 (en) | System for navigating driver to passenger for ride authorized by another user of transportation service | |
WO2019007336A2 (en) | Data processing method, apparatus and device | |
RU2576494C2 (en) | Method and system for mobile identification, business transaction execution and agreement signing operations | |
JP2019121120A (en) | Transaction management system, transaction management device, transaction management method, and transaction management program | |
US20170357954A1 (en) | Network for onboarding and delivery of electronic payments to new payees |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: YUR DRIVERS NETWORK INC., NEW JERSEY Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:PAULUCCI, LOUIS FRANK;COLON, JULIO ANTONIO;REEL/FRAME:057360/0778 Effective date: 20151203 |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: DOCKETED NEW CASE - READY FOR EXAMINATION |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: NON FINAL ACTION MAILED |
|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |