DESC:SYSTEM AND METHOD FOR VEHICLE ALLOCATION

CROSS-REFERENCE TO RELATED APPLICATION AND PRIORITY
[0001] The present application claims priority from Indian provisional patent application number 202321025621, filed on April 05, 2023. The entire content of the abovementioned application is incorporated herein by reference.
TECHNICAL FIELD
[0002] The present invention relates to a system and a method for vehicle allocation. More particularly, the present invention relates to a system and a method for allocating a vehicle to a passenger for a ride/trip based on the inputs received from the passenger.
BACKGROUND
[0003] Since the last decade, the practice of booking transportation services online through websites/mobile applications has become part and parcel of our daily lives. These websites/mobile applications allow users to avail transportation services in real-time without any restrictions including distance, departure time and the time taken for the ride and the like. The facility of availing transportation services online has the advantages of being convenient for the passengers to call/book a ride/travel anytime, reducing travel costs, alleviating traffic congestion and being environmentally friendly. It has significantly reduced passenger’s dependence on modes of public transport and alleviated the struggle of passengers living in areas where there is limited access to public transport.
[0004] While booking rides/trips online offers advantages over traditional methods like using public transport or conventional private taxi cabs (e.g., Kaali Peeli taxis in India), the personal safety of the passengers continues to be a point of concern. In this patent application, the term “taxi aggregators” shall mean and include service providers who facilitate the online connect between a passenger and a vehicle driver and provide a platform (mobile application or website or equivalent systems) through which a passenger sends requests for a ride/trip and the driver of a vehicle accepts the requests for the ride/trip and takes the passenger to the requested destination specified in the ride/trip requests.
[0005] At present, there are many security mechanisms in place to ensure safety and well-being of the passengers. However, most of the security measures installed suffer from one or more disadvantages which remains a cause of concern and has become a critical factor in passenger’s decision-making process when opting to travel with the system allocated vehicles and drivers.
[0006] Out of the various security mechanisms available in the prior arts, the first mechanism includes conducting background checks of the drivers by the taxi aggregators with the aim to strengthen safety measures. There have been multiple reports wherein loopholes in conducting background checks by local law enforcement or contractual agencies have been pointed out. However, even with comprehensive background checks, there have been instances of vicious cases of injuries and deaths of the passengers.
[0007] Second safety mechanism includes restricting total number of driving hours of vehicle drivers within a period of 24 hours. The number of driving hours are directly linked to driver’s fatigue, which includes nerve and sensory fatigue and limb fatigue, causing increase in reaction time and thus, leading to accidents. Globally, there have been regulations requiring strict compliance from the drivers and taxi aggregators to restrict driving beyond the allocated quota of hours. In India, the number of driving hours for a transport vehicle is limited to eight hours in a day with a rest of one hour if the driver has been driving for more than 5 hours continuously. As per the applicable provisions, the drivers are not supposed to accept ride requests from the passengers once this daily quota has been exhausted. However, due to lack or inadequate mechanisms in place, the drivers generally continue to accept ride requests after exhaustion of daily driving hours limit by rendering their driving services and registering their vehicles with more than one taxi aggregator(s), leading to accidents causing injury and/or death of the drivers, passengers and people on road.
[0008] Third safety mechanism commonly found in the online mobile applications/websites provided by the taxi aggregators to the passengers, is the provision of emergency buttons. Upon pressing the emergency button within the mobile application/web-interface, vehicle information, driver information, vehicle location (in real-time), passenger information and other data are sent to the emergency contacts for the passenger registered with the taxi aggregators and the local law enforcement (police). At times, the emergency button is a physical button provided within the vehicle, which is accessible to the passenger. Often, passengers are too late to press the emergency button to seek help or at times, delay in response from the emergency contacts and/or local law enforcement, has in some instances, led to unfortunate outcomes. In recent years, a mandate was issued to provide a separate panic button in the vehicle within the reach of the passenger to report safety incidents. However, passengers have reported that most of the times, such a measure is missing in vehicles provided by transport aggregators or sometimes the button is dysfunctional providing no immediate relief to the passengers.
[0009] Fourth safety mechanism includes providing in-built GPS tracking mechanism to track the trajectory of the vehicle, within the vehicle through the mobile application/web-interface used for booking the ride/trip and through taxi aggregators platforms. The GPS tracking mechanism is provided to track deviation from the designated route by the vehicle driver. In the event of deviation from the route, the passenger is not notified or even if the passenger becomes aware of the deviation, there is little which the passenger can do, apart from conversing with the driver about the deviation. Further, in such cases, the discretion is generally left to the vehicle driver and the passenger generally have no option rather to rely on the vehicle driver or terminate the ride/trip and get down from the vehicle, which might not be in the safe interests of the passenger at times.
[00010] Fifth safety mechanism includes displaying the picture or image of the vehicle driver with his/her overall rating in the taxi aggregator platforms (website/mobile applications). The rating mentioned in the taxi aggregator platforms most of the times do not mention any parameter for which the rating has been captured. Depending upon the driver rating, the passenger may choose to start the trip to the intended destination or request for another ride. Upon receipt of ride request from the passenger, some of the drivers assign/hand-over the trip request or vehicle to an unregistered individual, which may lead to safety and security issues. And, in the event of any accident or injury, it becomes difficult to track the details of such an unregistered individual.
[00011] Sixth safety mechanism includes conducting alcohol detection through breath analyzers and at times, the vehicle driver begins to drink after starting the trip, which causes discomfort to the passengers and increases the reaction time, leading to accidents and unfortunate outcomes.
[00012] Apart from the foregoing mechanisms, there are similar safety mechanisms available in prior art, however, most of them have been circumvented or suffer from a variety of loop holes. Considering these gaps in the safety mechanisms, the need to devise a comprehensive safety mechanism is the need of the hour, as the number of safety instances reported every year seem to be rising and endangering life of the passengers and people on road.
OBJECTIVES OF THE INVENTION
[00013] Some of the objectives of the present disclosure, which at least one embodiment herein satisfies, are as follows:
[00014] It is an objective of the present disclosure to overcome one or more problems of the prior art or at least provide a useful alternative.
[00015] An objective of the present invention is to provide a system and a method for vehicle allocation to ensure passenger safety.
[00016] Another objective of the present disclosure is to provide a system and a method that helps in ensuring that the allocated drivers do not suffer from sensory, physical and nervous fatigue.
[00017] Another objective of the present disclosure is to provide a system and a method that ensures that the body alcohol content of the allocated driver during the ride duration stays within a pre-determined threshold value so as to ensure there is no lag in the reaction time due to intoxication of the driver during the ride.
[00018] Another objective of the present disclosure is to provide a system and a method to track the allocated vehicle during the trip for route deviations and collecting reasoning behind route deviation in case said deviation is beyond a pre-determined limit to keep the passenger informed of the route deviation and reasoning behind said deviation.
[00019] Another objective of the present disclosure is to provide a system and a method to ensure that the allocated driver of the ride request does not assign the request to an illegitimate or unregistered driver or individual and puts the safety of the passenger in jeopardy.
[00020] Another objective of the present disclosure is to provide a system and a method to ensure that the legal compliances related to the vehicle including compliance with local, state and central law is ensured.
[00021] Other objectives and advantages of the present invention will become apparent from the following descriptions, taken in connection with the accompanying drawings, wherein, by way of illustration and example, an embodiment of the present invention is disclosed.
SUMMARY OF THE INVENTION
[00022] This summary is provided to introduce aspects of method and system for vehicle allocation and the aspects are further described below in the detailed description. This summary is not intended to identify essential features of the claimed subject matter nor is it intended for use in determining or limiting the scope of the claimed subject matter.
[00023] In view of the foregoing (para [00022]), an embodiment herein provides a method and system for vehicle allocation. In one aspect, a system for vehicle allocation, for ensuring passenger safety is provided. The system comprises a memory for storing instructions and a processor communicatively coupled to the memory to execute one or more instructions.
[00024] In an embodiment, a computer implemented system of vehicle allocation is provided. The system may include a processor and a memory storing processor-executable instructions that, when executed by the processor, configure the processor to: receive by a mobile application management module, a ride request from a passenger device using a pre-installed mobile application; analyze the ride request and extract contents of the ride request by a request management module wherein the extracted contents of the ride request include a pick-up location, a drop location, number of riders, vehicle type, preferred vehicle fuel type, preferred rating of driver, preferred gender of the driver and disability status of one or more passengers; match the extracted contents of the ride request by the request management module with nearby drivers and send the extracted contents of the ride request to the nearby drivers on their driver devices through the pre-installed mobile application on the driver device; receive ride request acceptance by one driver through the driver device out of the matched nearby drivers by the request management module and block other matched drivers from accepting the ride request; send the ride request acceptance to the passenger device including details of the matched driver and allocated vehicle; notify the driver on the driver device to depart to the pick-up location specified in the ride request.
[00025] In another embodiment, a processor implemented method of vehicle allocation is provided. The processor implemented method includes receiving by a mobile application management module, a ride request from a passenger device using a pre-installed mobile application; analyzing the ride request and extracting contents of the ride request by a request management module wherein the extracted contents of the ride request include a pick-up location, a drop location, number of riders, vehicle type, preferred vehicle fuel type, preferred rating of driver, preferred gender of the driver and disability status of one or more passengers; matching the extracted contents of the ride request by the request management module with nearby drivers and sending the extracted contents of the ride request to nearby drivers on their driver devices through the pre-installed mobile application on the driver devices, receiving ride request acceptance by one driver through the driver device out of the matched nearby drivers, by the request management module and blocking other matched drivers from accepting the ride request; sending the ride request acceptance to the passenger device including details of the matched driver and allocated vehicle; notifying the matched driver on the driver device to depart to the pick-up location specified in the ride request.

[00026] It should be appreciated by those skilled in the art that any block diagram herein represents conceptual views of illustrative systems embodying the principles of the present subject matter. Similarly, it will be appreciated that any flow charts, flow diagrams, state transition diagrams, pseudo codes, and the like represent various processes which may be substantially represented in computer readable medium and so executed by a computing device or processor, whether or nor such computing device or processor is explicitly shown.
BRIEF DESCRIPTION OF DRAWINGS
[00027] The following detailed description of preferred embodiments, are better understood when read in conjunction with the appended drawings. For the purpose of illustrating the invention, there is shown in the drawings exemplary constructions of the invention; however, the invention is not limited to the specific methods and system disclosed. In the drawings:
[00028] Figure 1 illustrates a network implementation of a system for allocating a vehicle to a passenger for a ride in accordance with an embodiment of the present disclosure;
[00029] Figure 2 illustrates a block diagram of a mobile device (e.g., passenger device and/or driver device) and system modules, in accordance with an embodiment of the present disclosure;
[00030] Figure 3 illustrates a flow diagram depicting process of requesting a ride by the passenger through the passenger device, in accordance with an embodiment of the present disclosure;
[00031] Figure 4 illustrates a flow diagram depicting process of accepting ride request raised by the passenger through the passenger device, by a driver through the driver device, in accordance with an embodiment of the present disclosure;
[00032] Figure 5 illustrates a flow diagram depicting process of monitoring route deviation during a ride by the system, in accordance with an embodiment of the present disclosure;
[00033] Figure 6 illustrates a block diagram of a machine in the example form of a computer system within which instructions for causing the machine to perform any one or more of the methodologies discussed herein may be executed, according to the embodiments as disclosed herein.

DETAILED DESCRIPTION
[00034] Exemplary embodiments are described herein with reference to accompanying drawings. While examples and features of disclosed principles are described herein, modifications, adaptations and other implementations are possible without departing from the spirit and scope of the disclosed embodiments. It is intended that the following detailed description be considered as exemplary only.
[00035] The terms “comprising”, “containing”, including”, “having” and other forms thereof, are intended to be equivalent in meaning and open ended in that item(s) following any of these terms is not meant to be exhaustive listing of such item or items or meant to be limited to only the listed item or items.
[00036] The following description and drawings are illustrative in nature and not to be construed as limiting. Numerous specific details are provided to provide a thorough understanding. However, in certain instances, well-known or conventional details are not described in order to avoid obscuring the description.
[00037] It must also be noted that the singular forms “a,” “an,” and “the” include plural references unless the context clearly dictates otherwise. Although any systems and methods similar or equivalent to those described herein can be used in the practice or testing of embodiments of the present invention, the preferred, systems and methods are now described. In the following description for the purpose of explanation and understanding reference has been made to numerous embodiments for which the intent is not to limit the scope of the invention.
[00038] The elements illustrated in the Figures interoperate as explained in more detail below. Before setting forth the detailed explanation, however, it is to be noted that all of the discussion below, regardless of the particular implementation being described, is exemplary in nature, rather than limiting.
[00039] Various modifications to the embodiment will be readily apparent to those skilled in the art and the generic principles herein may be applied to other embodiments. However, one of ordinary skill in the art will readily recognize that the present disclosure is not intended to be limited to the embodiments illustrated, but is to be accorded the widest scope consistent with the principles and features described herein.
[00040] The invention disclosed herein, through contemplated embodiments, aims to resolve the biggest challenge of vehicle and driver allocation in the transportation services, rendered through online/web platforms, through the creation and usage of novel and inventive software and hardware, providing a platform for secure and safer vehicle allocation and transportation services for all the players involved including vehicle driver, passenger and taxi-aggregators and thus, solving one of the biggest issues of the transportation industry. Through this novel and inventive invention, the number of road accidents hampering life and limb of persons involved and damage to property will be significantly reduced, making roads and transport safer and secure.
[00041] Additional goals of the present invention include ensuring that the rides are allocated and driving services are rendered only by those drivers, who have not crossed the pre-defined limit of driving hours and are not suffering from sensory and nervous fatigue, or drivers who are in compliance with applicable laws including compliance with local, state and central laws related to or in connection to the transport vehicle. The broader objective being reduction in the instances of exploitation of the drivers especially in terms of physical health and well-being, reducing the number of crimes and accidents on road and ensuring safer environment for passengers while travelling.
[00042] It is to be noted that the term “vehicle driver” and “driver” may be interchangeably used based on the context, however, they refer to the individuals allocated by the taxi aggregators to complete a ride request raised by the passenger.
[00043] It is to be noted that the term “vehicle” means and includes two-wheelers, three-wheelers, four-wheelers, multi-wheelers and the like. In an embodiment, the vehicle may include self-driven automated and semi-automated vehicles, individual driven vehicles, irrespective of the type of energy source used for driving.
[00044] Turning now to Figure 1, illustrated therein is a network implementation (100) of a system (102) for allocating a vehicle in response to a ride request from a passenger to ensure comprehensive safety, according to an embodiment disclosed herein. The present disclosure is explained considering the system (102) is implemented on a variety of computing systems, including, for example, servers, a desktop PC, a notebook or portable computer, a workstation, a mobile computing device, an entertainment device, and an internet appliance.
[00045] The system (102) for enabling vehicle allocation in response to a ride request from the passenger, is connected to at least one passenger device (106), and at least one driver device (108), through a communication network (104). The passenger device (106) and the driver device (108) can be any type of portable personal device capable of independently communicating with the communication network (104) (hereinafter referred to as “network”) and includes without limitation a handheld mobile phone (e.g., iPhoneTM or AndroidTM Smart phones), a handheld mobile device (e.g., iPod TouchTM), a tablet (e.g., iPadTM), a notebook computer, a personal data assistant (PDA) or the like.
[00046] The network (104) provides voice and messaging capabilities and may provide access to other communication networks such as, for example, other mobile communication networks and internet. The network (104) includes any type of wireless communication network such as CDMA, GSM and other satellite-based networks. In one embodiment, the network (104) may be at least one of a wireless network and a wired network. The network (104) can be implemented as one or more of the different types of networks, such as intranet, local area network (LAN), wide area network (WAN), the Internet, etc. The network (104) may either be a dedicated network or a shared network. The shared network may represent an association of the different types of networks that use a variety of protocols (e.g., Hypertext Transfer Protocol (HTTP), Transmission Control Protocol/Internet Protocol (TCP/IP), Wireless Application Protocol (WAP), etc.) to communicate with one another. Further, the network (104) may include a variety of network devices, including, for example, routers, bridges, servers, computing devices, storage devices, etc.
[00047] In an implementation, the system (102) may be communicatively connected to the passenger device (106) and the driver device (108) through the network (104). In one implementation, the system (102) may comprise the cloud-based computing environment in which the passenger or the driver may operate individual computing systems configured to execute remotely located applications.
[00048] The system (102) may further be communicatively coupled with the sensor(s) (110) associated with the passenger device (106) and the driver device (108). In another embodiment, the sensors (110) may form an integral part of the passenger device (106) and the driver device (108). The sensor(s) (110) may include finger print biometric sensor, iris scanner, breath analyzer, face recognition sensors, camera, dash-cam of the vehicle, microphone, voice scanner, alcohol detection scanner and GPS sensors. The sensors include any mechanism by which physical, psychological and sensory parameters of the driver or the passenger are accessed by the system (102).
[00049] In one implementation, the system (102) may further be communicatively coupled with other computing systems or servers, hereinafter referred to as secondary systems (112) deployed by other taxi aggregators to provide online ride booking and transportation services to its users/passengers. The connection with the secondary systems (112) allows the system (102) to receive the information associated with the vehicle, its driver and the driver device (108) in real-time.
[00050] The system (102) may be communicatively coupled through a desired form of communication for example via dial-up modem connections, cable links, digital subscriber lines (DSL), wireless or satellite links, or any other suitable form of communication.
[00051] Figure 2 illustrates a high-level architecture of a part of the system (102) of Figure 1 that facilitates in vehicle allocation in accordance with an embodiment of the present disclosure. The part of the system (102) includes a mobile device (e.g. passenger device and/or driver device) and system modules therein, according to an embodiment disclosed herein. The mobile device (200) herein refers to the passenger device (106) and the driver device (108) and includes without limitation a network interface module (not shown), a display module (202), I/O interface (204) such as keypad, screen and the like, a mobile application (206), a location tracking module (208), a face recognition module (210), a timer module (212), a memory (not shown in drawings), a processor (not shown in drawings) that inter-alia execute the mobile application (206). In an embodiment, the driver device (108) may be connected to a breath analyzer (232) (not shown in drawings), with an inlet region and sensor arrangement for comparing a breath sample of the driver to a predetermined threshold value. The breath analyzer (232) is a part of the sensors (110) detailed out in the description of the system (102) of Figure 1.
[00052] The mobile application (206) is configured to aid the passenger in raising ride requests and the driver to accept ride requests and other ancillary requests and instructions received. The details of the ride requests and acceptance thereto is entered into the mobile application (206) through I/O interface (204). The display module (202) is configured to display interfaces based on requests raised and responses received through the mobile application (206).
[00053] The location tracking module (208) is configured to identify the geo-spatial location of the mobile device (200) through the network (104). In an embodiment, the location tracking module (208) includes built in global positioning system (GPS) and communicates its respective location to the network (104) periodically or continuously. In an embodiment, the geo-spatial location can be determined through other methods known in prior art without limiting the scope of this invention. The location tracking module (208) of the passenger device (106) or the driver device (108) is configured to track and trace the geo-spatial location of the passenger and rider respectively.
[00054] The face recognition module (210) is configured to capture the facial image of the user of the mobile device (200). With reference to the present invention, the face recognition module (210) of the driver device (108), captures facial image of the driver and transmits captured facial image to the system (102) to carry out facial recognition of the driver at the start and before the end of the ride. In an embodiment, the facial recognition match of the driver is carried out periodically or continuously during the duration of the ride, to ensure that the driver does not assign the ride request to an unauthorized driver. The face recognition module (210) also aids the driver to create his profile in the system (102) by capturing the facial image of the driver, which would be used by the system (102) for carrying out the facial recognition of the driver.
[00055] The timer module (212) is configured to capture driving hours of the driver within a span of 24 hours or a total number of continuous driving hours without break in a span of 5 hours to aid in estimation of driver’s fatigue. The timer module (212) calculates the driving time of the driver by tracking the movement of the driver device (108) with the aid of location tracking module (208).
[00056] The system modules, as illustrated in Figure 2, comprise a mobile application management module (214), a ride management module (216), a compliance module (228) and a provisional module (230). The mobile application management module (214) is configured to enable a downloaded mobile application (206) on the mobile device (200) to be registered with unique identification data. The unique identification data includes device information and user related information. The device information includes the IMEI (international mobile equipment identity) number, SIM number, IMSI number and any other details associated with the mobile device (200).
[00057] In an embodiment, the user may be a passenger and/or a driver. The user information, with reference to the passenger, includes information including name, email ID, phone number, gender, age, nationality, emergency contact details (name and phone number) and any other detail as voluntarily provided by the passenger. The user information, with reference to the driver, includes name, registered address, email ID, gender, phone number, bank account details, details related to background check, medical records, total driving experience, skill and expertise and any other detail as voluntarily provided by the driver or considered important to register the driver within the system (102).
[00058] In additional embodiment, the user information in relation to the driver also includes information related to the driver’s vehicle including details of manufacturer, year of manufacture, type of fuel used, mode of driving, maintenance details, accident records, vehicle registration details with the authorities including license plate, insurance details, color of the vehicle and seating capacity.
[00059] The mobile application management module (214) is configured to enable receipt of requests sent by mobile device (200). In an embodiment, the mobile device (200) is the passenger device (106) and the request involves authentication request. In another embodiment, the mobile device (200) is the driver device (108) and the request involves login request.
[00060] The ride management module (216) includes a request management module (218) and a safety module (220). The ride management module (216) is configured to ensure and prioritize the safety of the passenger during the complete duration of ride/trip by deploying novel and legally compliant safety features. The ride management module (216) is further configured to ensure and prioritize the safety of the passenger in case the system (102) detects any anomaly or deviation or if the same is reported by the passenger device (106).
[00061] The ride management module (216) is configured to resolve any safety issue, deviation or anomaly detected by the system (102) or reported by the passenger device (106). In an embodiment, if any safety issue related to driver intoxication (due to alcohol), unwelcomed driver behavior, unacceptable body language, driver fatigue is detected by the system (102) or reported by the passenger device (106), the ride management module (216) is configured to assess/evaluate said detected or reported issue, using the data captured from the driver device (108) or through external sensors (110) of the system (102). The data from the driver device (108) is captured through the in-built GPS, microphone, camera within the driver device (108). The data from sensors (110) include the recordings from the dash cam, readings from the breath analyzer and other readings relevant to access and evaluate the safety issue.
[00062] Upon assessment of the detected or reported safety issue, the ride management module (216) maps safety measure to be implemented against the assessed safety issue and transmits details of the assessed safety issue along with the mapped safety measure to the passenger device (106). The ride management module (216), in parallel transmits details of the assessed safety issue along with mapped safety measure to the passenger’s emergency contacts tagged in the system (102) and to the local law enforcement agency to prompt further action to ensure security and safety of the passenger.
[00063] The ride management module (216) includes a request management module (218), which is configured to communicatively sync with the mobile application (206) of the passenger device (106) and the driver device (108) respectively. Upon receipt of a ride request from the passenger device (106), the request management module (218) extracts information/details/contents within the ride request and matches the extracted information against the nearby available drivers. The system (102) captures the proximity of the drivers by tracking the driver device (108). The request management module (218) matches the extracted information from the ride request with driver information and associated vehicle information of the nearby drivers. Upon a successful match, the request management module (218) transmits ride request details to the matched drivers on their driver devices (108) and repeatedly prompts for acceptance of ride request. The acceptance of the ride request is configured to be done on first come first accept basis against the matched drivers through their driver devices (108).
[00064] Upon successful receipt of acceptance from one matched driver from the set of matched drivers, from the respective driver device (108), the request management module (218) transmits details of the matched driver and related vehicle to the passenger device (106) in response to the ride request raised by the passenger. For avoidance of doubt, it is to be noted that the request management module (218) upon receipt of acceptance from one driver device (108), blocks the other driver devices (108-N) from sending acceptance or accepting to the ride request. Such a measure is implemented to negate the acceptance of multiple ride requests by a single driver device (108) at a time.
[00065] Upon receipt of driver’s acceptance to the ride request, the request management module (218) transmits details of estimated time of arrival (ETA) of the driver to the pick-up location (mentioned in ride request), driver and vehicle details to the passenger device (106). The ETA is captured through the information received from the location tracking module (208) of the driver device (108). In an embodiment, the driver details transmitted by the request management module (218) to the passenger device (106) include without limitation, name of driver, rating of the driver, picture of the driver, number of rides taken, gender of the driver and other details requested in the ride request. In another embodiment, the transmitted vehicle details include the type of vehicle, registration number of the vehicle, vehicle fuel type, age of the vehicle, details of vehicle maintenance, vehicle manufacturer, and color of the vehicle. In continuation, the request management module (218) prompts the driver on the driver device (108) to travel to the pick-up location within the ride request to pick-up the passenger. It should be noted that this particular invention is not aimed towards scheduling a ride request by the passenger.
[00066] The safety module (220) includes a face recognition verification module (222), a duration tracking module (224), a deviation identification module (226) and a sobriety module (234). The safety module (220) through its sub-modules as mentioned earlier, is configured to match a plurality of parameters before the request management module (218) assigns a ride request to the driver device (108). The safety module (220) is configured to ensure the safety of the driver and the passenger during the entirety of the ride duration, from the start to the completion of the ride. The plurality of parameters includes driver’s identity, driver’ fatigue including number of driving hours within a period of 24 hours, sobriety status of the driver and route deviation.
[00067] The face recognition verification module (222) is configured to verify driver’s identity by communicatively syncing with the face recognition module (210) of the driver device (108) and running a facial match by comparing the facial image captured by the face recognition module (210) in real-time with the driver’s image available in the system (102). It is to noted that the face recognition verification module (222) may verify the driver’s identity anytime during the ride duration, which can be at the start, in mid of the ride and towards the end of the ride. The verification of driver’s identity during the ride duration is implemented to ensure that the registered driver assigned to the ride request continues to attend the ride request during the whole duration without illegally assigning or sub-contracting to other individuals, thereby ensuring safety of the passenger.
[00068] The duration tracking module (224) is configured to collect the data related to driver’s fatigue. For collection of driver’s fatigue data, the duration tracking module (224) communicatively syncs in real-time with timer module (212) of the driver device (108) and other secondary systems (112) to calculate the number of driving hours of the driver within a span of 24 hours or continuous driving hours within a span of 5 hours. The pre-defined limit of driving hours is decided based on applicable laws of the land and in case of absence of related laws, the pre-defined limit of driving hours is set at 8 (eight hours) in a span of 24 hours with a rest of one hour if the driver has been driving for more than 5 hours continuously.
[00069] Upon collection of driving hours data, if it is found that the pre-defined limit of driving hours has been exhausted, the duration tracking module (224) transmits the confirmation of exhaustion of driving hours to the ride management module (216). If such information is transmitted during an ongoing ride, the ride management module (216) allows the driver to complete the ongoing ride and restricts the driver from accepting further ride requests. If said information is transmitted before the start of the ride or at the end of the ride, the ride management module (216) restricts the driver from accepting further ride requests and continues to match with other eligible driver(s) against the ride request.
[00070] The deviation identification module (226) is configured to identify a route to be undertaken by the driver to reach to the drop location from the pick-up location (pre-designated route) and transmit the identified route to the passenger device (106) and the driver device (108). The identification of route from one location to another is based on the methods known in the prior art and the present invention relies on one of those methods to identify the route specifics. Additionally, the deviation identification module (226) is configured to identify route deviation by the driver during the ride duration. The deviation identification module (226) communicatively syncs with location tracking module (208) of the driver device (108). The deviation identification module (226) is configured to report any deviation in the route by the driver to the passenger device (106) and transmits to the passenger device (106) possible options to undertake as action(s) on route deviation. The deviation identification module (226) is configured to take action when the deviation is beyond a pre-determined threshold, which may include undertaking a route which is remote or unpopulated, which is not provided with street lights, which does not significantly reduce the riding time or distance or a route which is not often used by other passengers. The threshold parameters for route deviation are defined in the system (102) and are updated in real-time in the system (102). The threshold parameters are based on the additional time taken to complete the ride, additional distance to be travelled during the ride duration, remoteness of the route and accident or incident history of the deviated route. Such thresholds are defined to ensure that the safety of the passenger is not put into jeopardy.
[00071] In furtherance, the deviation identification module (226) is configured to mandate the driver device (108) to submit reasoning behind the deviation in the identified route. In an embodiment, the deviation identification module (226) collects the reasoning behind deviation by providing multiple choice options to be selected by the driver on the driver device (108). In another embodiment, the deviation identification module (226) triggers a call to the driver device (108) for collection of reasoning behind the deviation. Such call is generally triggered to be attended between the driver and human personnel of the taxi aggregator.
[00072] Upon collection of reasoning behind deviation, the deviation identification module (226) is configured to report the collected reasoning to the passenger device (106). In the event, the reported reasoning for the route deviation is accepted by the passenger through passenger device (106), the deviation identification module (226) takes no action and continues to track the ride for possible deviations on the route till the completion of the ride. In the event of non-acceptance of the reasoning by the passenger, the deviation identification module (226) informs the local law enforcement and emergency contacts of the passenger stored in the mobile application (206).
[00073] In the event of rejection of reasoning by the passenger, the deviation identification module (226) is configured to provide additional security measures to ensure safety of the passenger. In the event of reasoning rejection, the deviation identification module (226) prompts the passenger on the passenger device (106) to terminate the ongoing ride and provides option to either stay in the vehicle till a new driver and a new vehicle is allocated and sent to the passenger’s location for pick-up or continue the ride to the nearest police station where the passenger will be dropped to wait for the next driver and vehicle allocation. Irrespective of the option selected by the passenger, the deviation identification module (226) is configured to continuously monitor the location of the driver and the passenger through their respective devices, in real-time. In the event of reasoning rejection, the ride management module (216) transmits instructions to the sensors (110) to transmit and store the information within the vehicle including recording of audio and videos by dash cam or through the driver device (108) or the passenger device (106). In parallel, the ride management module (216) transmits real-time information including ETA to the police station, passenger’s location, ETA of the newly allocated driver and vehicle, to the local law enforcement and emergency contacts of the passenger.
[00074] The sobriety module (234) is configured to monitor the sobriety status of the driver to ensure safety of the passenger during ride duration. The sobriety module (234) is configured to collect the data from the breath analyzer (232) and compare the collected readings against a pre-determined value. The pre-determined values are set in the system (102) based on the statutory regulations or applicable laws of the land. For example, the permissible alcohol limit in India is set at 0.03% per 100 ml of blood. That is, the detection of more than 30mg of alcohol or drugs in a sample of 100 ml blood is considered a punishable offence by Indian law. To ensure compliance with the foregoing law and to ensure safety of the passenger during ride duration, the monitoring of the sobriety status of the driver is done before the start of the ride and before the completion of the ride.
[00075] If, at the time of start of the ride, the readings captured by the breath analyzer (232) are found higher than the pre-determined threshold values, the request management module (218) re-assigns the ride request to another driver and temporarily blocks the access of intoxicated driver till his readings revert back to normal limits. If, during the ongoing ride or towards completion of the ride, if the readings captured by the breath analyzer (232) are found higher than the pre-determined threshold value, the request management module (218) which in turn reassigns the ride request to another driver and gives the option to the passenger to be dropped off to the nearest police station. Such a measure has been implemented to ensure that the driver does not continue to driver under the influence of alcohol. Alternatively, the passenger may inform the request management module (218) of the drinking status of the driver through the mobile application (206) within the passenger device (106) and request for an alternate driver and a vehicle.
[00076] The compliance module (228) is configured to monitor driver’s compliance with local, state and central laws, rules and regulations including compliance with tax laws, environmental compliance including pollution checks, traffic compliance and submission of challans and fines on time and vehicle maintenance. The compliance module (228) is configured to ensure that the driver does not miss or ignore the legal compliances related to self and vehicle maintenance. The compliance module (228) stays communicatively sync with the ride management module (216) and in the event of any non-compliance reported by the compliance module (228), the ride management module (216) temporarily blocks the access of the driver to new ride requests through his driver device (108). The compliance module (228) regularly transmits information related to upcoming compliances to be followed by the driver to the mobile application (206) on the driver device (108).
[00077] The provisional module (230) is configured to monitor driver’s compliance with the system policies including clearing payments, checking status of subscriptions and their validity and other parameters. In the event of any expiration of validity of subscription or non-compliance with system policies, the provisional module (230) transmits details of non-compliance to the ride management module (216) and temporarily blocks the access of the driver to new ride requests.
[00078] The passenger device (106) and the driver device (108) maintain a connection with the network (104) through the procedures executed within the passenger device (106) and the driver device (108). The network (104) keeps a constant check of the geo-spatial location of the passenger device (106) and the driver device (108) in real-time or near time. For the purpose of this invention, it is assumed that the passenger and the driver carry their respective devices as they move from point to point.
[00079] The passenger for scheduling a ride from point A to point B with one of the drivers (not selected yet) opens a ride scheduling mobile application (206) (hereinafter referred to as mobile application (206) on the passenger device (106) and raises a request for scheduling a ride (hereinafter referred to as “ride request”) with one of the registered drivers within the mobile application (206). It should be noted that there are various methods known in the art for scheduling an appointment between a passenger and a driver, however, the present invention is not directed to the conventional methods known in the domain.
[00080] In an embodiment, the mobile application (206) running on passenger device (106) implements one or more tools, without limitation, to secure data that may be stored, to initiate ride request for scheduling a ride from point A to B and other services needed for maintaining the passenger account. The mobile application (206) can be executed on the passenger device (106) wherein the mobile application (206) is hosted and operated by system (102) (either independently or through a third-party) for use by its passenger or drivers over through the network (104). In an embodiment, the mobile application (206) is accessible through an API accessible over the web (or another network).
[00081] In an embodiment, the mobile application (206) executed on the driver device (108) implements one or more tools that may be in addition to the tools implemented on a passenger device (106). The tools include without limitation the ability to respond to passenger ride requests for scheduling rides. In an embodiment, the mobile application (206) running on a driver device (108) can be remotely locked through the ride management module (216). The mobile application (206) is provided as hosted services enabling central monitoring and management of all security aspects of the service hosted by system (102).
Scheduling a ride by the Passenger
[00082] In one implementation, the passenger submits a ride request through the mobile application (206) on the passenger device (106). In an implementation, the ride request, without limitation includes, a pick-up location, a drop location, number of riders, vehicle type, preferred vehicle fuel type, preferred rating of driver, preferred gender of the driver and disability status of one or more passengers. The mobile application (206) on the passenger device (106) is communicatively linked to the system (102) through the network (104). The mobile application (206) obtains the current geo-spatial location of the passenger from the passenger device (106) through the location tracking module (208) or from network (104) and transmits the location to the ride management module (216).
[00083] Upon receipt of the ride request, the request management module (218) extracts the details within the ride request and runs a match against the nearby available drivers by comparing extracted information from the ride request against driver and vehicle information available in the system (102). In an embodiment, the request management module (218) analyses the ride request and sends the ride request to the matched drivers and awaits acceptance from one of the matched drivers. It is to be noted that request management module (218) accepts only one acceptance per ride request. For avoidance of doubt, it is to be noted that the ride management module (218) upon receipt of acceptance from one driver device (108), blocks the other driver devices (108-N) from sending acceptance or accepting to the ride request. Such a measure is implemented to negate the acceptance of multiple ride requests by a single driver device (108) at a time.
[00084] Upon receipt of acceptance of the ride request from the driver through the driver device (108), the request management module (218) sends the details of driver and the vehicle to the passenger on the passenger device (106). In continuation, the request management module (218) prompts the driver to travel to the pick-up location as mentioned in the ride request to pick-up the passenger. It should be noted that this particular invention is not aimed towards scheduling a ride request by the passenger.
[00085] In one implementation as illustrated in Figure 3, at step (302), the passenger submits a ride request through the mobile application (206) on passenger device (106). In continuation, at step (302), the ride request of the passenger from the passenger device (106) is transmitted to the request management module (218) wherein the ride requests from the passengers are perceived as individual requests. The request management module (218), at step (304), analyses the ride request and extracts information needed for running a match against the nearby drivers. The request management module (218) captures the geo-spatial location of the passenger and the pick-up location and drop location within the ride request. In an embodiment, the request management module (218) may retrieve additional booking parameters from ride request and send the additional parameters to be matched along with the pick-up and drop location as main parameters for vehicle allocation to the nearby drivers. The additional parameters include a pick-up location, a drop location, number of riders, vehicle type, preferred vehicle fuel type, preferred rating of driver, preferred gender of the driver and disability status of one or more passengers.
[00086] At step (306), the request management module (218) matches the nearby available drivers by comparing the extracted information at step (304), with the driver and vehicle information and upon successful match, sends the ride request to the nearby available driver(s) and prompts the matched drivers to accept the ride request on first come first serve basis.
[00087] At step (308), matched driver sends its acceptance to the ride request through the mobile application (206) on the driver device (108). At step (310), the request management module (218) transmits the driver’s acceptance of the ride request to the passenger on the passenger device (106) along with estimate time of arrival of the driver at the pick-up location, driver details, vehicle details and the like. In an embodiment, the driver details sent by the request management module (218) to the passenger include without limitation, name of driver, rating of the driver, picture of the driver, number of rides taken, gender of the driver and other details requested in the ride request. In another embodiment, the vehicle details include the type of vehicle, age of the vehicle, registration number of the vehicle, vehicle fuel type, details of vehicle maintenance and color of the vehicle.
[00088] At step (312), the request management module (218) prompts the driver to depart to pick-up location, which is the pick-up location specified in the ride request.
Driver validation in the system and acceptance of ride requests
[00089] As illustrated in Figure 4, at step (402), the driver to gain access to the ride requests, raises a login request through the mobile application (206) on the driver device (108). The login requests are transmitted to the mobile application management module (214) where multiple requests are received from multiple driver devices and are perceived as individual requests. Upon successful authentication, the driver is allowed to access the mobile application (206). Failure to authenticate the login credentials lead to blocked access.
[00090] In the event of successful driver authentication, the face recognition module (210) and the timer module (212) within the driver device (108), at step (404) capture the picture/image of the driver in real-time and the data related to the number of hours spent driving on the road. In an alternate embodiment, the fingerprint of the driver may be captured through the fingerprint sensor present in the driver device (108).
[00091] At step (406), the duration tracking module (224) calculates the total number of hours spent by the driver on road in a period of 24 hours/in a day. This calculation is done basis the number of hours spent by the driver fulfilling ride requests with the system (102) and other secondary systems (112) available in the market. The duration tracking module (224) captures the data related to the number of hours by extracting driving data from the timer module (212) and the data from the secondary systems (112) which is communicatively linked with the system (102) in real-time. In case, the pre-defined limit of driving hours prescribed by the local and/or central laws is found to be exhausted, the request management module (218) refuses access and acceptance to any ongoing and new ride requests by the driver and transmits the revoked access to ride request to the driver on the driver device (108). Alternatively, the driver device (108) is allowed to continue to the next step i.e. (408).
[00092] At step (408), the face recognition verification module (222) compares the images/pictures captured by the face recognition module (210) with the images of the driver stored in the system (102). The images stored in the system (102) include the picture(s) provided by the driver through its driver device (108) at the time of creation of profile on the mobile application (206). The pattern match of the picture captured in real-time with the pre-stored picture may be done by the system (102) on the mobile device (200) or at the system (102). In the event of failed match, the request management module (218) refuses access and acceptance to any ongoing and new ride requests by the driver. Alternatively, the driver device (108) is allowed access to the ride requests within the system (102).
[00093] At step (410), upon successful match of the facial features and non-exhaustion of pre-defined limit of driving hours, the request management module (218) grants access to the new and pending ride requests in the system (102). The request management module (218) allows acceptance to one ride request at a time and sends the acceptance of the driver to the passenger device (106). Upon acceptance of the ride requests by the driver through driver device (108) at step (412), the request management module (218) prompts the driver to proceed to the pick-up location specified in the ride request at step (414). Alternatively, the driver device (108) continues to access new and pending ride requests raised in the system (102).
En-route ride safety of the Passenger and Route Deviation
[00094] As illustrated in Figure 5, at step (502), in response to the prompt by the request management module (218), the driver arrives at the pick-up location specified in the ride request. The location tracking module (208) of the driver device (108) captures the geo-spatial location of the driver and transmits the whereabouts of the driver to the ride management module (216). Upon arrival of the driver at the pick-up location, the ride management module notifies arrival of the driver to the passenger on the passenger device (106).
[00095] At step (504), the request management module (218) prompts the passenger on the passenger device (106) to check the driver details. The driver details required to be confirmed by the passenger through the passenger device (106) on the mobile application (206) include the name, physical description, gender of the driver, pictorial match, sobriety and the like. In an embodiment, the request management module (218) prompts the passenger to check the vehicle details including without limitation, color of vehicle, registration number, vehicle model, status of maintenance, fuel type and age of the vehicle.
[00096] At step (506), the request management module (218) prompts the passenger on the passenger device (106) to confirm the consistency of the driver information and vehicle information with the information specified within the ride request, on the mobile application (206) on the passenger device (106). After the passenger has checked the driver and vehicle information, the request management module (218) prompts the passenger to report the consistency of details mentioned in ride request with the details of vehicle and driver assigned by the request management module (218).
[00097] At step (508), in case, the passenger reports inconsistency in the match to the ride management module (218) at step (506), the request management module (218) reassigns the ride request to another driver and prompts another driver to proceed to the pick-up location. The request management module (218) transmits information to the passenger device (106) of the new driver being requested for fulfilling the ride request.
[00098] Alternatively, if the passenger reports consistency in the match to the ride management module (218) at step (506), the request management module (218) transmits information to the passenger device (106) and driver device (108) of the confirmation at step (510). This step constitutes confirmation of a match between the driver and vehicle assigned against the ride request by the request management module (218) by the passenger on its passenger device (106). This steps also confirms the alignment of the driver and vehicle information in the system (102) with the data of the matched driver and vehicle by the request management module (218).
[00099] At step (512), the face recognition module (210) of the driver device (108) captures real-time picture of the driver handling the ride request and transmits it to the system (102). In an embodiment, the image captured by the face recognition module (210) before the start of the ride, is sent to the face recognition verification module (222).
[000100] At step (514), the face recognition verification module (222) matches the picture transmitted by the face recognition module (210) in real-time to the image of the driver stored in the system (102). In the event of an unsuccessful match by the face recognition verification module (222) at step (516), the request management module (218) reassigns the ride request to another driver and prompts another driver to proceed to the pick-up location. The request management module (218) transmits information to the passenger device (106) of the new driver being requested for fulfilling the ride request.
[000101] At step (518), in case of successful face match or finger print match captured in real-time with the data stored in the system (102), the breath analyzer (232) (Not shown) prompts the driver on the driver device (108) to blow into the breath analyzer probe provided as external probe as part of sensors (110). Upon the driver blowing into the inlet region of the breath analyzer (232), the breath analyzer calculates alcohol level of the driver and compares the determined alcohol level with the pre-determined threshold value and transmits the alcohol level of the driver to the sobriety module (234). At step (520), the breath analyzer (232) compares the detected alcohol value to the pre-determined threshold value. The results of the comparison are transmitted by the breath analyzer (232) to the sobriety module (234). The sobriety module (234) stays connected to the request management module (218). At step (522), if the determined alcohol value exceeds the pre-determined threshold values, the request management module (218) reassigns the ride request to another driver and prompts another driver to proceed to the pick-up location. The request management module (218) transmits information to the passenger device (106) of the new driver being requested for fulfilling the ride request.
[000102] At step (524), if there is confirmed consistency, face/finger print match of the driver and the determined alcohol level does not exceed the pre-determined threshold values, the request management module (218) prompts the passenger device (106) and driver device (108) of the initiation of trip/ride. The driver device (108) is prompted to start departing towards the requested destination as specified in the ride request.
[000103] At step (526), during the ongoing trip towards the specified destination in the ride request, the safety module (220) of the system (102) tracks driver information, route of the vehicle towards the designated drop-off point and duration of the driving hours of the driver in real-time and the sobriety status of the driver.
[000104] At step (528), the deviation identification module (226) identifies a deviation in the designated route by the driver through the information captured from the location tracking module (208) of the driver device (108). The system (102) has pre-defined rules governing the calculation of deviation in the route and the set of pre-defined rules include without limitation, the new delta in time taken to reach the destination, difference in total distance due to route deviation, undertaking a route which is remote or unpopulated, which is not provided with street lights, which does not significantly reduce the riding time or distance or a route which is not often used by other passengers. There is a pre-determined threshold of deviation which does not trigger the system (102), more particularly, the deviation identification module (226) to send alerts. The threshold parameters for route deviation are pre-defined in the system (102) and are updated in real-time in the system (102). In an exemplary embodiment, if the passenger is travelling from point A to point B with a distance of 10 kms and the driver takes route deviation of 1.5 kms, due to which the customer will take additional 7 minutes to reach the destination. In such a situation, the deviation identification module (226) will not trigger alerts provided that the new route is not remote or unpopulated and is not prone to accidents and incidents. At step (530), in case of insignificant route deviation, the trip continues without any interruption or prompts from the deviation identification module (226).
[000105] At step (532), due to detection of deviation beyond the pre-determined threshold, the deviation identification module (226) prompts the driver through the driver device (108) for the reasoning behind the route deviation. In an embodiment, the prompt to the driver device (108) may be done in the form of an automated chat with multiple choice questions or a call on the driver device (108).
[000106] At step (534), the deviation identification module (226) transmits the information of route deviation to the passenger on the passenger device (106) and transmits the reason for route deviation received from the driver through the driver device (108) to the mobile application (206) on the passenger device (106). In another embodiment, the passenger may send a notification to the system (102) of the route deviation and request for reasoning or intervention. In such an event, the steps from (532) to (538) may be followed by the system (102) depending upon the reasoning and satisfaction of the passenger to the reasoning behind the deviation.
[000107] At step (536), the detection deviation module (226) sends prompt to the passenger device (106) to check whether the passenger accepts the route deviation and reason provided by the driver for the route deviation. In the event that the passenger finds the reason for route deviation acceptable, the deviation identification module (226) takes no action and it continues to track the vehicle for route deviation until the passenger is dropped off to the designated location.
[000108] At step (538), in the event that the route deviation is reported unacceptable by the passenger through the passenger device (106), the deviation identifications module (226) remains communicatively linked with the ride management module (216) and transmits emergency alert to the local law enforcement and passenger’s emergency contact. In addition, the request management module (218) opens the ride request to be accepted by locally available drivers. At this step, the request management module (218) gives the passenger the choice to stay in the current vehicle and wait for another driver to come to the current location (detected by the location tracking module (208) on the passenger device (106) or step out of the vehicle and wait on the road. In another embodiment, the request management module (218) gives the passenger a choice to get drop off a nearest police station and then wait for another driver to come, which has allocated by the system (102) on the acceptance of the ride request at this step.
[000109] FIG. 6 is a block diagram of a computer system (600) within which instructions for causing the machine to perform any one or more of the methodologies discussed herein may be executed. In alternative embodiments, the machine operates as a standalone device or may be connected (e.g., networked) to other machines. In a networked deployment, the machine may operate in the capacity of a server or a client machine in a server-client network environment, or as a peer machine in a peer-to-peer (or distributed) network environment. The machine may be a personal computer (PC), a tablet PC, a set-top box (STB), a Personal Digital Assistant (PDA), cellular telephone, a web appliance, a network router, Switch or bridge, or any machine capable of executing instructions (sequential or otherwise) that specify actions to be taken by that machine. Further, while only a single machine is illustrated, the term “machine' shall also be taken to include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein.
[000110] The example computer system (600) includes a processor (602) (e.g., a central processing unit (CPU), a graphics processing unit (GPU), or both), a main memory (604), and a static memory (606), which communicate with each other via a bus. The computer system 600 may further include a video display unit (610). The computer system (600) also includes an alphanumeric input device (612) (e.g., a keyboard), system modules (614) (including without limitation, the mobile application management module. Ride management module, compliance module and provisional module), a disk drive unit 616, a signal generation device (618) (e.g., a speaker), and a network interface device (620). The computer system (600) may also include an environmental input device (626) that may provide a number of inputs describing the environment in which the computer system (600) or another device exists, including, but not limited to, any of a Global Positioning Sensing (GPS) receiver, a temperature sensor, a light sensor, a still photo or Video camera, an audio sensor (e.g., a microphone), a Velocity sensor, a gyroscope, an accelerometer, a fingerprint sensor, a breath analyzer, and a compass.
[000111] The disk drive unit 616 includes a machine-readable medium (622) on which is stored one or more sets of data structures and instructions (624) (e.g., Software) embodying or utilized by any one or more of the methodologies or functions described herein. The instructions (624) may also reside, completely or at least partially, within the main memory (604) and/or within the processor (602) during execution thereof by the computer system (600), the main memory (604) and the processor (602) also constituting machine-readable media. While the machine-readable medium (622) is shown in an example embodiment to be a single medium, the term “machine-readable medium' may include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) that store the one or more instructions (624) or data structures. The term “non-transitory machine-readable medium’ shall also be taken to include any tangible medium that is capable of storing, encoding, or carrying instructions for execution by the machine and that cause the machine to perform any one or more of the methodologies of the present Subject matter, or that is capable of storing, encoding, or carrying data structures utilized by or associated with such instructions. The term “non-transitory machine-readable medium’ shall accordingly be taken to include, but not be limited to, Solid-state memories, and optical and magnetic media. Specific examples of non-transitory machine-readable media include, but are not limited to, non-volatile memory, including by way of example, semiconductor memory devices (e.g., Erasable Programmable Read-Only Memory (EPROM), Electrically Erasable Programmable Read-Only Memory (EEPROM), and flash memory devices), magnetic disks Such as internal hard disks and removable disks, magneto-optical disks, and CD-ROM and DVD-ROM disks.
[000112] The instructions (624) may further be transmitted or received over a computer network (650) using a transmission medium. The instructions (624) may be transmitted using the network interface device (620) and any one of a number of well-known transfer protocols (e.g., HTTP). Examples of communication networks include a local area network (LAN), a wide area network (WAN), the Internet, mobile telephone networks, Plain Old Telephone Service (POTS) networks, and wireless data networks (e.g., WIFI and WiMAX networks). The term “transmission medium” shall be taken to include any intangible medium that is capable of storing, encoding, or carrying instructions for execution by the machine, and includes digital or analog communications signals or other intangible media to facilitate communication of such software.
[000113] Furthermore, a computer that is running the previously mentioned computer software can be connected to a network and can interface to other computers using the network. The network can be an intranet, internet, or the Internet, among others. The network can be a wired network (for example, using copper), telephone network, packet network, an optical network (for example, using optical fiber), or a wireless network, or a combination of Such networks. For example, data and other information can be passed between the computer and components (or steps) of a system using a wireless network based on a protocol, for example Wi-Fi (IEEE standards 802.11, 802.11a, 802.11b, 802.11e, 802.11g, 802.11i, and 1802.11n). In one example, signals from the computer can be transferred, at least in part, wirelessly to components or other computers.
[000114] It is to be understood that although various components are illustrated herein as separate entities, each illustrated component represents a collection of functionalities which can be implemented as Software, hardware, firmware or any combination of these. Where a component is implemented as Software, it can be implemented as a standalone program, but can also be implemented in other ways, for example as part of a larger program, as a plurality of separate programs, as a kernel loadable module, as one or more device drivers or as one or more statically or dynamically linked libraries.
[000115] The preceding description has been presented with reference to various embodiments. Persons having ordinary skill in the art and technology to which this application pertains will appreciate that alterations and changes in the described structures and methods of operation can be practiced without meaningfully departing from the principle, spirit and scope.
[000116] The present disclosure will contribute to the country’s economy, which is one of the purposes to enact the Patents Act, 1970. The product in accordance with present invention will be in great demand in the country and worldwide due to novel technical features of a present invention is a technical advancement in the field of vehicle allocation and ensuring the safety of the passenger and people on road.
Dated this 4th day of April, 2024

Kalpana Garg
IN/PA-2175
Agent For the Applicant
To,
The Controller of Patents
The Patent Office, at Mumbai

,CLAIMS:WE CLAIM:
1. A method executed at least in part on a system (102) for allocating vehicle, comprising:
receiving (302) by a mobile application management module (214), a ride request from a passenger device (106) using a pre-installed mobile application (206);
analysing the ride request and extracting contents (304) of the ride request by a request management module (218) wherein the extracted contents of the ride request include a pick-up location, a drop location, number of passengers, vehicle type, preferred vehicle fuel type, preferred rating of driver, preferred gender of the driver and disability status of one or more passengers;
matching the extracted contents of the ride request by the request management module (218) with nearby drivers and sending the extracted contents of the ride request (306) to nearby drivers on their driver devices (108) through the pre-installed mobile application (206) on the driver devices (108)
receiving ride request acceptance (308) by one driver through the driver device (108) out of the matched nearby drivers, by the request management module (218) and blocking other matched drivers from accepting the ride request;
sending the ride request acceptance (310) to the passenger device (106) including details of the matched driver and allocated vehicle;
notifying the matched driver on the driver device (108) to depart to the pick-up location specified in the ride request.

2. The method as claimed in claim-1, further comprising:
providing access to the ride requests to the driver on the driver device (108) by checking fatigue of the driver by calculating (406) a total of driving hours within a span of 24 hours by a duration tracking module (224) from the driver device (108) and secondary system (112) and comparing with a pre-defined limit of driving hours as per applicable law and capturing a facial image of the driver and comparing (408) the facial image with a pre-stored image of the driver by a face recognition verification module (222), wherein an access to the ride request to the driver device (108) is allowed upon successful match of facial image of the driver and non-exhaustion of driving hours beyond the pre-defined limit of driving hours.

3. The method as claimed in claim-1, further comprising:
confirming (504) on the passenger device (106) alignment of matched driver and allocated vehicle with requirements specified in the ride request;
capturing (512) a facial image of the matched driver and matching (514) the facial image with the pre-stored image of the matched driver by the face recognition verification module (222) at the pick-up location of the passenger;
prompting (518) the matched driver to blow into a breath analyser probe (232) for calculating alcohol level of the matched driver and comparing it to a pre-determined threshold value wherein the matched driver is prompted to blow into the breath analyser probe (232) only if facial recognition match, matched driver and allocated vehicle alignment match is found;
prompting (524) the matched driver on the driver device (108) to pick the passenger in the allocated vehicle and depart to the drop off location if the detected content of alcohol level of the matched driver is found lesser than the pre-determined threshold value or alternatively, reassigning (522) the ride request to another driver if detected content of alcohol level of the matched driver is found higher than the pre-determined threshold value.

4. The method as claimed in claim-3, further comprising:
tracking (526) route of the allocated vehicle for entire ride duration by tracking the driver device (108);
comparing (528) the tracked route with a pre-designated route to identify route deviations;
prompting (532) the matched driver on the driver device (108) upon identification of route deviation for collecting reasoning for the route deviation;
confirming (534) the acceptance of the passenger on the passenger device (108) with the identified route deviation and collected reasoning for the route deviation;
reassigning (538) the ride request to another driver if the collected reasoning is confirmed unacceptable by the passenger and informing emergency contacts of the passenger and local law enforcement or alternatively continuing with the matched driver if the route deviation and collected reasoning are found acceptable by the passenger.

5. The method as claimed in claim-3, wherein the alcohol level detection of the matched driver is done during the start and towards completion of the ride.

6. The method as claimed in claim-2, wherein the secondary systems (112) include other public and private taxi aggregators providing vehicle allocation and transportation services.

7. A system for allocating vehicle, comprising:
a memory storing instructions;
a processor coupled to the memory to;
receive by a mobile application management module(214), a ride request from a passenger device (106) using a pre-installed mobile application (206);

analyse the ride request and extract contents of the ride request by a request management module (218) wherein the extracted contents of the ride request include a pick-up location, a drop location, number of passengers, vehicle type, preferred vehicle fuel type, preferred rating of driver, preferred gender of the driver and disability status of one or more passengers;
match the extracted contents of the ride request by the request management module (218) with nearby drivers and send the extracted contents of the ride request to nearby drivers on their driver devices (108) through the pre-installed mobile application (206) on the driver device (108);
receive ride request acceptance by one driver through the driver device (108) out of the matched nearby drivers by the request management module (218) and block other matched drivers from accepting the ride request;
send the ride request acceptance to the passenger device (106) including details of the matched driver and allocated vehicle;

notify the driver on the driver device (108) to depart to the pick-up location specified in the ride request.

8. The system as claimed in claim-7, wherein the processor is further configured to:
provide access to the ride requests to the driver on the driver device (108) by checking fatigue of the driver by calculating a total of driving hours within a span of 24 hours by a duration tracking module (224) from the driver device (108) and secondary system (112) and compare with a pre-defined limit of driving hours as per applicable law and capture a facial image of the driver and compare the facial image with a pre-stored image of the driver by a face recognition verification module (222), wherein an access to the ride request to the driver device (108) is allowed upon successful match of facial image of the driver and non-exhaustion of driving hours beyond the pre-defined limit of driving hours.

9. The system as claimed in claim-7, wherein the processor is further configured to:
confirm on the passenger device (106) alignment of matched driver and allocated vehicle with requirements specified in the ride request;
capture a facial image of the matched driver and matching (514) the facial image with a pre-stored image of the matched driver by the face recognition verification module (222) at the pick-up location of the passenger;
prompt the matched driver to blow into a breath analyser probe (232) to calculate alcohol level of the driver and compare it to a pre-determined threshold value wherein the matched driver is prompted to blow into the breath analyser probe (232) only if facial recognition match, matched driver and allocated vehicle alignment match is found;

prompt the matched driver on the driver device (108) to pick the passenger in the allocated vehicle and depart to the drop off location if the detected content of alcohol level of the matched driver is found lesser than the pre-determined threshold value or alternatively, reassign the ride request to another driver if detected content of alcohol level of the matched driver is found higher than the pre-determined threshold value.

10. The system as claimed in claim-9, wherein the processor is further configured to:
track route of the allocated vehicle for entire ride duration by tracking driver device (108);
compare the tracked route with a pre-designated route to identify route deviations;
prompt the matched driver on the driver device (108) upon identification of route deviation for collecting reasoning for the route deviation;
confirm the acceptance of the passenger on the passenger device (108) with the identified route deviation and collected reasoning for the route deviation;
reassign the ride request to another driver if the collected reasoning is confirmed unacceptable by the passenger and inform emergency contacts of the passenger and local law enforcement or alternatively continue with the matched driver if the route deviation and collected reasoning are found acceptable by the passenger.

11. The system as claimed in claim-9, wherein the alcohol level detection of the matched driver is done during the start and towards completion of the ride.

12. The system as claimed in claim-8, wherein the secondary systems (112) include other public and private taxi aggregators providing vehicle allocation services.