FIELD OF INVENTION

[0001] The present description relates to mobile application, and more specifically optimized transport service enabling vehicle pooling.

BACKGROUND

[0002] On a daily basis, majority of people commute to work, commute on business purpose, commute on job, etc. Typically people tend to avail private transport services such as taxi or cab for commuting. Such transport services can be availed by booking in advance or prior reservation. These transport services have specific vehicles operating on a specific set of routes. When a request for a trip is received by the transport service provider, the provider identifies a vehicle matching the request and confirms. This identification of vehicles matching the user requirement is on a non-real-time basis, and the availability of vehicles on a specific route is also limited. There is a need for an integrated transport management in real-time, where the passenger can book and manage booking of vehicles on the go in real-time without delay.

BRIEF DESCRIPTION OF THE DRAWINGS

[0003] The claims set forth the embodiments with particularity. The embodiments are illustrated by way of examples and not by way of limitation in the figures of the accompanying drawings in which like references indicate similar elements. Various embodiments, together with their advantages, may be best understood from the following detailed description taken in conjunction with the accompanying drawings.

[0004] FIG. 1 is a block diagram illustrating an example environment for optimized transport service enabling vehicle pooling, according to one embodiment.

[0005] FIG. 2A is a flow diagram illustrating a process of driver determining routes, according to one embodiment.

[0006] FIG.2B is a flow diagram illustrating a process of expanding the generated route including the intermediate points added, according to one embodiment.

[0007] FIG. 3 is a flow diagram illustrating a process of a passenger determining a driver, according to one embodiment.

[0008] FIG. 4 is a user interface illustrating logic to determine available drivers, according to one embodiment.

[0009] FIG. 5 illustrates a sequence of user interfaces for selecting a driver and booking a ride in vehicle pooling, according to one embodiment.

[0010] FIG. 6 illustrates a sequence of user interfaces for displaying driver details, according to one embodiment.

[0011] FIG. 7 illustrates a sequence of user interfaces for requesting an adhoc trip, according to one embodiment.

[0012] FIG. 8 illustrates a sequence of user interfaces for booking a ride within a closed group to pool vehicle, according to one embodiment.

[0013] FIG. 9 is a flow diagram illustrating a process of optimized transport service enabling vehicle pooling, according to one embodiment.

[0014] FIG. 10 is a block diagram illustrating an exemplary computer system, according to one embodiment.

DETAILED DESCRIPTION

[0015] Embodiments of techniques for optimized transport service enabling vehicle pooling are described herein. In the following description, numerous specific details are set forth to provide a thorough understanding of the embodiments. A person of ordinary skill in the relevant art will recognize, however, that the embodiments can be practiced without one or more of the specific details, or with other methods, components, materials, etc. In some instances, well-known structures, materials, or operations are not shown or described in detail.

[0016] Reference throughout this specification to "one embodiment", "this embodiment" and similar phrases, means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one of the one or more embodiments. Thus, the appearances of these phrases in various places throughout this specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.

[0017] FIG. 1 is a block diagram illustrating example environment 100 for optimized transport service enabling vehicle pooling, according to one embodiment. The environment 100 as shown contain passenger client systems ' 1' 105 to passenger client systems 'N' 110, driver client systems T 115 to driver client systems 'N' 120, server system 125, and network 130. The passenger client system and driver client system can be a computing device such as a mobile phone or a tablet computer used by end users to generate requests on the instance of transport application 110, executing on the passenger/driver client systems. The requests may be generated using appropriate user interfaces. The transport application 110 also requests the server system 125 for performing specific tasks and receives corresponding response from the server system 125.

[0018] The transport application 110 executes in the passenger/driver client systems, and provides a user interface, for example, based on display and inputs, such as touch, keypad and pointer device. User interacts with the user interface provided by the transport application 110 executing in the passenger/driver client systems and thus with the enterprise transport application, i.e. transport application 140 executing in the server system 125. In one embodiment, the transport application 110 can be application software comprising a set of instructions, published on a web or application server, which can be downloaded and installed on the client system 110. For example, transport application 110 can be a mobile application available for download in an application store, provided by a vendor or any service provider. In another embodiment, the transport application 140 executing on server system 125, can be accessed over a network 145 from the passenger/ driver client systems, for example as an on-demand software such as, software as a service (SaaS).

[0019] Transport application uses global positioning system (GPS) or telecom cell towers to identify current location of the driver/passenger client system i.e. mobile device, and display on a map associated with the mobile device. Identifying the current location includes identifying the current latitude and longitude associated with the mobile device and direction of travel. Based on the movement or motion of the mobile device, the identified current latitude and longitude is displayed and updated in real-time in the map associated with the mobile device. Merely for illustration, only a representative number and type of systems is shown in FIG. 1. Often, environments contain more systems executing transport application (e.g., more server systems), both in number and type, depending on the purpose for which an environment is designed.

[0020] For example, passenger client system ' V 105 also includes memory 150A. The memory 150A stores the data, fetched from the server system 125, to enable the user to perform operations on the transport application 110. The result of user operation is stored in the memory 150A and subsequently synchronized with the data storage 160 in real-time. The memory 150A may be internal to the passenger client system '1' 105, such as flash drive. Data storage 160 represents a non-volatile storage, facilitating storage and retrieval of data by transport application 140, executing in server system 125. The server system 125 may reside in a cloud platform.

[0021] FIG.2A is a flow diagram illustrating process 200 of a driver determining routes, according to one embodiment. An instance of transport application may be downloaded and installed in a mobile device associated with a driver. At 205, an input including a start and a destination is received in the transport application executing in the mobile device. At 210, it is determined whether existing routes are available between the start and destination. Upon determining that existing routes are not available between the start and destination, at 215, routes and driving directions are determined from start to destination using route determining algorithm. Various route determining algorithm such as Dijkstra's algorithm, Floyd warshall algorithm, etc., can be used. Upon determining that routes are available from the start to destination, or, upon determining routes and driving directions using route determining algorithm, at 220, receive an input regarding the route confirmation from the driver. This route is identified with a driver route number.

[0022] At 225, it is determined whether the route is confirmed by the driver. Upon determining that the route is not confirmed by the driver, at 230, intermediate points such as landmarks are received as input and a route is generated via the added intermediate points between the start and destination. At 235, latitudes and longitudes are mapped in the generated route based on the current location of the mobile device associated with the driver. At 240, it is determined whether the driver is in movement or driving at present. Upon determining that the driver is in movement or driving at present, at 245, the latitudes and longitudes based on the current location of the mobile device is updated in the generated route in real-time, where the latitude and longitude crossed by the driver is removed or appropriately marked in the map associated with the mobile device. At 250, it is determined whether the driver has reached the destination. Upon determining that the driver has reached the destination, the process is terminated.

[0023] FIG.2B is a flow diagram illustrating process 230 of expanding the generated route including the intermediate points added (as mentioned in 230 of FIG.2A), according to one embodiment. At 260, select the generated route including start, destination and the intermediate points added, to expand the route. At 265, select further intermediate points that are on the route and at a user defined distance from the start or previous intermediate point. At 270, directions and distance between the start and destination along with the intermediate points is determined using route determining algorithm. At 275, the generated route along with the directions and distance is saved in the memory in the mobile device and synchronized with database in server. At 280. the latitudes and longitudes based on the current location of the mobile device associated with the driver is updated in the generated route in real-time, where the latitude and longitude crossed by the driver is removed or indicated as crossed in the map associated with the mobile device. For the individual intermediate points, the direction, distance, latitudes and longitudes are determined and updated instantaneously in real-time in the map associated with the mobile device.

[0024] FIG.3 is a flow diagram illustrating process 300 of a passenger determining a driver, according to one embodiment. An instance of transport application may be downloaded and installed in a mobile device associated with a passenger. At 305, a start and a destination are received as inputs in the transport application executing in the mobile device associated with the passenger. At 310, it is determined whether any driver may arrive within a user-defined distance or is at a user-defined distance from start, and at a user-defined distance from destination. This determination is based on a radius search, where the radius is based on the user-defined distance. If a driver is identified within the radius, a unique number is associated with current route of the driver referred to as unique driver route number. For a particular user-defined distance, radius search is performed on the start, and a set of source routes are identified. The individual routes in the set of source routes are identified with unique numbers referred to as source route numbers. Similarly, for a particular user-defined distance, radius search is performed on the destination, and a set of destination routes are identified. The individual routes in the set of destination routes are identified with unique numbers referred to as destination route numbers. Accordingly, all unique source route numbers, unique destination route numbers and unique driver route numbers are identified. Upon determining that no driver is at the user-defined distance from start, at 315, a regret message is displayed in a user interface of the transport application associated with the passenger, and the process stops 320 or terminates.

[0025] Upon determining that some drivers are at the user-defined distance from start or destination, at 330, the unique source route numbers and the unique destination route numbers are compared and intersecting route numbers are determined. These intersecting route numbers are considered as possible routes. These intersecting route numbers are matched with the unique driver route numbers to identify shortlisted drivers. At 340, the shortlisted drivers are displayed as options for selection in a user interface of the transport application executing in the mobile device of the passenger. At 345, a selection of driver is received from the passenger. At 350, the selected driver is notified with a request and details of the passenger. In one embodiment, instead of selection of a single driver, the passenger can broadcast a request to multiple drivers i.e., shortlisted drivers.

The first driver accepting the passengers request from the shortlisted drivers is determined as a selected driver. At 355, it is determined whether the driver has accepted the request from the passenger. Upon determining that the driver has accepted the request from the passenger, at 360, a confirmation message is sent to the passenger. Upon determining that the driver has not accepted the request from the passenger, at 365, it is determined whether alternate drivers are available. Upon determining that alternate drivers are available, at 340, the alternate drivers are displayed as options for selection in a user interface of the transport application executing in the mobile device of the passenger. At 345, a selection of driver is received from the passenger. At 350, the selected driver is notified with a request and details of the passenger. Upon determining that no intersection route numbers are matched with the unique driver route numbers, at 365, it is determined whether any other drivers are available at a distance from start and the determined drivers are displayed in the user interface of the transport application associated with the passenger. At 355, it is determined whether the driver has accepted the request from the passenger. Upon determining that the driver has accepted the request from the passenger, at 360, a confirmation message is sent to the passenger.

[0026] FIG. 4 is a user interface illustrating logic to determine available drivers, according to one embodiment. An instance of transport application may be downloaded and installed in a mobile device associated with a passenger. A user interface 400 is shown displaying a map in the transport application, where a passenger 405 is currently located at a source 410 'chintamani'. The passenger 405 triggers a search in the transport application to determine whether any drivers are available from the source 410 'chintamani' to destination 415 'Gandhi Nagar'. When this search is triggered, a radius search of any user-defined distance such as '500 meter' indicated with a dashed circle 420 is performed at the source 405 'chintamani', and routes '1' 425, '2' 430 and '3' 435 are identified. Similarly, a radius search of any user-defined distance such as '500 meter' indicated with a dotted circle 440 is performed at the destination 415 'Gandhi Nagar' and routes '4' 445, '5' 450, '6' 455 and '7' 460 are identified. The identified routes at source '1' 425, '2' 430 and '3' 435, and the identified route at destination '4' 445, '5' 450, '6' 455 and '7' 460 are compared to identify if there are any intersections. Routes '1' 425 and '5' 450, routes '2' 430 and '6' 455, routes '3' 435 and '7' 460 intersect.

[0027] 'Driver A' 465, 'driver B' 470 and 'driver c' 475 are available drivers. Route number ' 1' is associated with 'driver A' 465, route number '2' is associated with 'driver B' 470, and route number '3' is associated with 'driver C 475. Now, the intersection routes previously identified are matched with the driver route numbers. Intersecting routes '1' 425 and '5' 450, routes '2' 430 and '6' 455, routes '3' 435 and '7' 460 are matched with driver route numbers ' 1' of 'driver A' 465, '2' of 'driver B' 470, and '3' of 'driver C 475, and all the three drivers 'driver A' 465, 'driver B' 470 and 'driver c' 475 are identified as shortlisted drivers. The direction of travel of these drivers is determined. As the driver moves in a specific route in a specific direction numerals in increasing order i.e. ascending order are assigned to the route at regular intervals. For example, 'driver A' 465 moving in a direction from source to destination in route number T is assigned incremental numerals such as '8', '9', '10', etc. If the numerals are in ascending order from source, driver is in forward direction, and if the numerals are in descending order, then the driver is in reverse direction. Accordingly, it is determined that 'driver A' 465 and 'driver C 475 are in forward direction, and 'driver B' 470 is in reverse direction.

[0028] Driver in the reverse direction is ruled out, and only drivers in the forward direction are considered. 'Driver A' 465 and 'driver C 475 are considered, however only 'driver C 475 is shortlisted since 'driver C 475 is in forward direction and at a closer proximity i.e. within the radius of the passenger 405. This shortlisted driver 'driver C 475 is displayed in the user interface of the transport application associated with the mobile device of the passenger 405. The distance between the passenger 405 and the 'driver C 475 is calculated and displayed in the map of the passenger 405 along with the location of 'driver C 475. In one embodiment, 'passenger X' 480 is at a new route which does not intersection with any destination route numbers. The radius search is automatically extended to a different radius 485 as shown in semi dashed circle. Computation is performed to determine whether any drivers are available in the different radius 485. It is determined and displayed in the map of 'passenger X' 480 that if the 'passenger X' walked for 200 meters 'driver C 475 is available.

[0029] FIG.5 illustrates a sequence of user interfaces 500 for selecting a driver and booking a ride in vehicle pooling, according to one embodiment. In the mobile device of a passenger, an instance of transport application is executing. In the user interface 505, the passenger is provided with various modes of transport 510 such as premium car, economy car, two wheeler, company cab, etc. The modes of transport here indicate the entity to be pooled such as cars. The passenger specifies the mode of transport 510 as 'economy car', departure time as '10:00 AM' and pickup location as 'location D'. In user interface 515, the passenger can also optionally specify the type of trip as 'round trip' 520 and also specify an option to repeat this ride 'one week from today', and clicks on search. Based on the source and destination specified by the passenger, a radius search is performed, and unique source route numbers and unique destination route numbers are identified. The unique source route numbers and the unique destination route numbers are compared and intersecting route numbers are determined. These intersecting route numbers are considered as possible routes. These intersecting route numbers are matched with the driver route numbers to identify shortlisted drivers, and the identified shortlisted driver details are displayed in the user interface 525. For example, the identified driver details are displayed as shown in 530. In one embodiment, the identified drivers are sorted and displayed based on the proximity to the source.

[0030] FIG. 6 illustrates a sequence of user interfaces for displaying driver details, according to one embodiment. In user interface 605, the identified driver details can also be viewed in the map where the current location of the identified drivers and the distance at which they located from the passenger is displayed. In the user interface 610, one such driver 'C 92 Person C is selected and the passenger clicks on 'book ride' 615. A notification is sent to the driver and when the driver accepts, a confirmation message is sent to the passenger and is displayed in the user interface 620. In one embodiment, the driver can choose to reject the request from the passenger. In that case, a notification of rejection is sent to the passenger. The passenger can select a different driver from the displayed identified drivers.

[0031] FIG.7 illustrates a sequence of user interfaces for requesting an adhoc trip, according to one embodiment. In the mobile device of a passenger, an instance of transport application is executing. In user interface 705, passenger can specify a source as 'source A' and a destination 'destination B' and searches for available drivers. In case no drivers are available, the passenger can request for an adhoc trip. For example, the passenger can specify 'source A', 'destination B', purpose of travel, time and other details and request an adhoc or special trip. This information from the passenger is received by a manager for approval. When the manger approves, this information is sent to a web application instance of transport application executing in a client system associated with a travel desk of 'company A'. A travel agent receives the special request and determines whether any vehicle is available at the requested time using the transport application. Upon determining that a company vehicle is available, an approved message is sent to the mobile device of the passenger as shown in 710. After the vehicle has been confirmed by the travel agent, trip confirmation message is sent to the mobile device associated with the passenger. Details of the trip, name of the driver, contact details and specifications of the vehicle are sent to the passenger as shown in user interface 715.

[0032] FIG. 8 illustrates a sequence of user interfaces for booking a ride within a closed group to pool vehicle, according to one embodiment. In the mobile device of a passenger, an instance of transport application is executing. A community of closed group of users also referred to as friends can be registered in a group in the transport application. In user interface 805, a passenger can specify source as 'location X', destination as 'location Y', date and departure time and search to determine whether any of the friends in the closed group is travelling at the specified time to the specified location or via the specified location. As a result of this search, one friend is identified to match the search criteria, and the information associated with the travel schedule of the friend is displayed in the user interface of the mobile device associated with the passenger. In user interface 810, the travel information associated with friend 'friend E' is displayed and the passenger can choose to book a ride with this friend by clicking on the 'book ride' option. When 'friend E' accepts the request a confirmation message is sent to the user interface of the passenger.

[0033] In one embodiment, goods carrier service providers or common carrier can use the integrated transport application for maximum utilization of their resources. For example, a 'company A' owns fifty vehicles offering goods carrier service. Using the instance of transport application on mobile device, various vendors can pool and book these vehicles and transport their goods to appropriate destination. A web instance of transport application can also be used by 'company A' to mediate and manage such vehicle pooling as described above. Typically, such carrier vehicles offer services to transport goods across geographies. In such a scenario, using transport application improves efficiency of vehicle utilization.

[0034] In one embodiment, a passenger can choose to cancel or change a previously booked ride, according to one embodiment. When a passenger chooses to change the ride that is already booked, the passenger can click on a change option (not shown) displayed along with the driver information to change the timing or date of the ride. Passenger can also choose to cancel the previously booked ride by clicking on a cancel option displayed along with the driver information. A passenger can choose to block a driver or a driver can choose to block a passenger using a block option displayed in the user interface of the transport application. In one embodiment, passengers can rate and comment the service provided by the drivers. In the mobile application when any passenger specifies a source and destination and searches for available drivers, the drivers blocked by any of the passengers are excluded from the search for available drivers.

[0035] In one embodiment, passengers can schedule a trip for a later date. Passenger can specify the details and request a ride for a later date. This booking will appear as an entry in the calendar of the passenger and the driver. Reminders can be configured to remind such a scheduled ride. Passengers and drivers can maintain a profile with their details and preference in the transport application, and this preference can be used to initiate a search for drivers. Recurring trips can be scheduled in the appropriate user interface by scheduling daily, weekly or monthly recurring trips. In the closed group, passengers and drivers are provided option to chat or message to discuss on the timings or location.

[0036] FIG.9 is a flow diagram illustrating process 900 of optimized transport service enabling vehicle pooling, according to one embodiment. An instance of transport application is executing in a first mobile device of a passenger. At 910, a source and a destination are received in the first mobile device associated with the passenger. At 920, one or more unique source route numbers are identified. The source route numbers are based on a user-defined radius associated with the source. At 930, one or more unique destination route numbers are identified. The destinations route numbers are based on a user-defined radius associated with the destination. At 940, intersection is identified between the one or more unique source route numbers and the one or more unique destination route numbers. The intersection is referred to as intersection route numbers. At 950, the one or more intersection route numbers are matched with one or more driver route numbers. The driver route numbers are associated with current routes of drivers. Based on the matching, at 960, one or more drivers corresponding to the matched driver route numbers are displayed in the first mobile device of the passenger.

[0037] The various embodiments described above have a number of advantages. The transport application provides an integrated platform for vehicle pooling. Employees of various organizations commute to work on a daily basis, the transport application executing on the mobile device provides a platform to collaborate on travel in a real-time basis. It provides an economical and fuel efficient means of travel, when a passenger shares cost with the driver. Various other enterprises such as courier services, package delivery services, travel agency and various segments of users such as employees, tourists, students, and travel agents can benefit from this integrated platform.

[0038] Some embodiments may include the above-described methods being written as one or more software components. These components, and the functionality associated with each, may be used by client, server, distributed, or peer computer systems. These components may be written in a computer language corresponding to one or more programming languages such as, functional, declarative, procedural, object-oriented, lower level languages and the like. They may be linked to other components via various application programming interfaces and then compiled into one complete application for a server or a client. Alternatively, the components maybe implemented in server and client applications. Further, these components may be linked together via various distributed programming protocols. Some example embodiments may include remote procedure calls being used to implement one or more of these components across a distributed programming environment. For example, a logic level may reside on a first computer system that is remotely located from a second computer system containing an interface level (e.g., a graphical user interface). These first and second computer systems can be configured in a server-client, peer-to-peer, or some other configuration. The clients can vary in complexity from mobile and handheld devices, to thin clients and on to thick clients or even other servers.

[0039] The above-illustrated software components are tangibly stored on a computer readable storage medium as instructions. The term "computer readable storage medium" should be taken to include a single medium or multiple media that stores one or more sets of instructions. The term "computer readable storage medium" should be taken to include any physical article that is capable of undergoing a set of physical changes to physically store, encode, or otherwise carry a set of instructions for execution by a computer system which causes the computer system to perform any of the methods or process steps described, represented, or illustrated herein. Examples of computer readable storage media include, but are not limited to: magnetic media, such as hard disks, floppy disks, and magnetic tape; optical media such as CD-ROMs, DVDs and holographic devices; magneto-optical media; and hardware devices that are specially configured to store and execute, such as application-specific integrated circuits (ASICs), programmable logic devices (PLDs) and ROM and RAM devices. Examples of computer readable instructions include machine code, such as produced by a compiler, and files containing higher-level code that are executed by a computer using an interpreter. For example, an embodiment may be implemented using Java, CI I, or other object-oriented programming language and development tools. Another embodiment may be implemented in hard¬wired circuitry in place of, or in combination with machine readable software instructions.

[0040] FIG. 10 is a block diagram illustrating an exemplary computer system 1000. The computer system 1000 includes a processor 1005 that executes software instructions or code stored on a computer readable storage medium 1055 to perform the above-illustrated methods. The computer system 1000 includes a media reader 1040 to read the instructions from the computer readable storage medium 1055 and store the instructions in storage 1010 or in random access memory (RAM) 1015. The storage 1010 provides a large space for keeping static data where at least some instructions could be stored for later execution. The stored instructions may be further compiled to generate other representations of the instructions and dynamically stored in the RAM 1015. The processor 1005 reads instructions from the RAM 1015 and performs actions as instructed. According to one embodiment, the computer system 1000 further includes an output device 1025 (e.g., a display) to provide at least some of the results of the execution as output including, but not limited to, visual information to users and an input device 1030 to provide a user or another device with means for entering data and/or otherwise interact with the computer system 1000. Each of these output devices 1025 and input devices 1030 could be joined by one or more additional peripherals to further expand the capabilities of the computer system 1000. A network communicator 1035 may be provided to connect the computer system 1000 to a network 1050 and in turn to other devices connected to the network 1050 including other clients, servers, data stores, and interfaces, for instance. The modules of the computer system 1000 are interconnected via a bus 1045. Computer system 1000 includes a data source interface 1020 to access data source 1060. The data source 1060 can be accessed via one or more abstraction layers implemented in hardware or software. For example, the data source 1060 may be accessed by network 1050. In some embodiments the data source 1060 may be accessed via an abstraction layer, such as, a semantic layer.

[0041] A data source is an information resource. Data sources include sources of data that enable data storage and retrieval. Data sources may include databases, such as, relational, transactional, hierarchical, multi-dimensional (e.g., OLAP), object oriented databases, and the like. Further data sources include tabular data (e.g., spreadsheets, delimited text files), data tagged with a markup language (e.g., XML data), transactional data, unstructured data (e.g., text files, screen scrapings), hierarchical data (e.g., data in a file system, XML data), files, a plurality of reports, and any other data source accessible through an established protocol, such as, Open DataBase Connectivity (ODBC), produced by an underlying software system (e.g., ERP system), and the like. Data sources may also include a data source where the data is not tangibly stored or otherwise ephemeral such as data streams, broadcast data, and the like. These data sources can include associated data foundations, semantic layers, management systems, security systems and so on.

[0042] In the above description, numerous specific details are set forth to provide a thorough understanding of embodiments. One skilled in the relevant art will recognize, however that the embodiments can be practiced without one or more of the specific details or with other methods, components, techniques, etc. In other instances, well- known operations or structures are not shown or described in detail.

[0043] Although the processes illustrated and described herein include series of steps, it will be appreciated that the different embodiments are not limited by the illustrated ordering of steps, as some steps may occur in different orders, some concurrently with other steps apart from that shown and described herein. In addition, not all illustrated steps may be required to implement a methodology in accordance with the one or more embodiments. Moreover, it will be appreciated that the processes may be implemented in association with the apparatus and systems illustrated and described herein as well as in association with other systems not illustrated.

[0044] The above descriptions and illustrations of embodiments, including what is described in the Abstract, is not intended to be exhaustive or to limit the one or more embodiments to the precise forms disclosed. While specific embodiments of, and examples for, the one or more embodiments are described herein for illustrative purposes, various equivalent modifications are possible within the scope, as those skilled in the relevant art will recognize. These modifications can be made in light of the above detailed description. Rather, the scope is to be determined by the following claims, which are to be interpreted in accordance with established doctrines of claim construction.

CLAIMS

What is claimed is:

1. A non-transitory computer-readable medium to store instructions, which when executed by a computer, cause the computer to perform operations comprising: receive a source and destination from a first mobile device; identify one or more unique source route numbers based on a user-defined radius associated with the source; identify one or more unique destination route numbers based on a user-defined radius associated with the destination; identify intersection between the one or more unique source route numbers and the one or more unique destination route numbers as one or more intersection route numbers; match the one or more intersection route numbers with one or more driver route numbers, wherein the driver route numbers are associated with current routes of drivers; and based on matching, display one or more drivers corresponding to the matched one or more driver route numbers.

2. The computer-readable medium of claim 1, wherein displaying one or more drivers further comprises: display the one or more drivers along with distance from source on a map in the first mobile device.

3. The computer-readable medium of claim 2, wherein identifying intersection comprises matching direction of the current routes of the drivers with the direction from the source to the destination.

4. A computer-implemented method of optimized transport service enabling vehicle pooling, the method comprising: receiving a source and destination from a first mobile device; identifying one or more unique source route numbers based on a user-defined radius associated with the source; identifying one or more unique destination route numbers based on a user-defined radius associated with the destination; identifying intersection between the one or more unique source route numbers and the one or more unique destination route numbers as one or more intersection route numbers; matching the one or more intersection route numbers with one or more driver route numbers, wherein the driver route numbers are associated with current routes of drivers; and based on matching, displaying one or more drivers corresponding to the matched one or more driver route numbers.

5. The method of claim 4, wherein displaying one or more drivers further comprises: displaying the one or more drivers along with distance from source on a map in the first mobile device.

6. The method of claim 5, wherein identifying intersection comprises matching direction of the current routes of the drivers with the direction from the source to the destination.

7. A computer system for optimized transport service enabling vehicle pooling, comprising: receive a source and destination from a first mobile device; identify one or more unique source route numbers based on a user-defined radius associated with the source; identify one or more unique destination route numbers based on a user-defined radius associated with the destination; identify intersection between the one or more unique source route numbers and the one or more unique destination route numbers as one or more intersection route numbers; match the one or more intersection route numbers with one or more driver route numbers, wherein the driver route numbers are associated with current routes of drivers; and based on matching, display one or more drivers corresponding to the matched one or more driver route numbers.

8. The system of claim 7, wherein displaying one or more drivers further comprises: display the one or more drivers along with distance from source on a map in the first mobile device.

9. The system of claim 8, wherein identifying intersection comprises matching direction of the current routes of the drivers with the direction from the source to the destination.

10. The system of claim 7, further comprises: select a driver from the one or more drivers; and send a notification to the selected driver.