WO2022091103A1

WO2022091103A1 - Systems and methods for providing a real-time smart transportation platform

Info

Publication number: WO2022091103A1
Application number: PCT/IL2021/051286
Authority: WO
Inventors: Uriel SHIMONY; Avi GABAY
Original assignee: Opticity Ltd.
Priority date: 2020-10-30
Filing date: 2021-10-31
Publication date: 2022-05-05

Abstract

System and methods for providing a real-time smart transportation platform, facilitating rides for a plurality of passengers to a destination, receive data representing the plurality of passengers; wherein the data comprises address information of each passenger of the plurality of passengers; cluster the plurality of passengers into a plurality of stations; compose one or more routes for the plurality of stations; and monitor in real time, a status of one or more rides which follow the one or more composed routes.

Description

SYSTEMS AND METHODS FOR PROVIDING A REAL-TIME SMART TRANSPORTATION PLATFORM

FIELD OF THE INVENTION

[0001] The present invention is in the field of real-time transportation optimization. In particular, the present invention is directed to systems and methods for providing a real-time smart transportation platform.

BACKGROUND OF THE INVENTION

[0002] Many companies coordinate transportation for their employees. However, currently available systems for coordinating transportation have many limitations. For example, such systems struggle to optimize the designations of pick-up/drop stations for large numbers of passengers. Likewise, basic systems are available for optimizing the specific routes drivers should take given certain constraints. However, these systems are limited. For example, Google® OR Tools Solver is a tool which, given a distance matrix between dots (e.g., stations), and number of vehicles, can provide optimize routes, which means the routes with the least total distance that start and end at the same dot (e.g., station). However, as additional constraints are added, optimization decreases substantially, and the problem becomes more difficult to solve.

[0003] Furthermore, currently available route optimization systems do not allow for monitoring of multiple routes simultaneously, nor accounting for different shifts (e.g., passengers who need to arrive or depart at different times. Additionally, currently available systems do not account for outliers or provide alternative modes of transportation (e.g., public transportation) for specific passengers.

SUMMARY OF THE INVENTION

[0004] Embodiments of the invention include a method for providing a real-time smart transportation platform facilitating rides for a plurality of passengers to a destination. Embodiments of the invention include a processor and one or more code sets which, when executed in the processor, configure the processor to: receive data representing the plurality of passengers; wherein the data comprises address information of each passenger of the plurality of passengers; cluster the plurality of passengers into a plurality of stations; compose one or more routes for the plurality of stations; and monitor in real time, a status of one or more rides which follow the one or more composed routes. [0005] In some embodiments, one or more routes are composed based on at least one of a maximum time of a ride, a maximum deviation from a first station of the plurality of stations to an endpoint, a vehicle capacity, or a walking distance from an address of a given passenger to a given station into which the given passenger has been clustered.

[0006] In some embodiments, the data further comprises a rides report of a company.

[0007] In some embodiments, the data further comprises shift times of each of the plurality of passengers, wherein the processor is further configured to: divide the plurality of passengers into one or more groups, each group having a same direction of ride and at least one of a same arrival time or same departure time, based on the shift times.

[0008] In some embodiments, when clustering the plurality of passengers into a plurality of stations, the processor is further configured to: identify at least one initial station for each of the plurality of passengers; iterate recursively over each initial station relative to all the passengers in which a maximum walking distance is within a predefined limit; identify one or more main stations from the initial stations based on the iterating step; identify for each main station, at least one duel station; and assign each of the plurality of passengers to at least one main station and at least one duel station.

[0009] In some embodiments, the processor is further configured to perform an initial step of dividing the plurality of passengers into a plurality of initial area clusters.

[0010] In some embodiments, when composing one or more routes for the plurality of stations, the processor is further configured to: generate a distance and time matrix between each station to all other stations of the plurality of stations; compose one or more initial routes beginning from a farthest station from the destination, based at least in part on the distance and time matrix; and if a first given route can be merged with a second given route without exceeding one or more routing limitations, merge the first and second given routes.

[0011] In some embodiments, the processor is further configured to: fine-tune the at least one of the one or more routes based on a history of manual changes to a given route.

[0012] In some embodiments, when clustering the plurality of passengers into a plurality of stations, the processor is further configured to: assign each passenger to at least one main station and at least one duel station; and, when composing the one or more routes for the plurality of stations, the processor is further configured to: add for each passenger, one of an assigned main station and an assigned duel station to one route of the one or more routes. [0013] In some embodiments, the processor is further configured to: identify one or more stations which, if the one or more stations were removed from a composed route would reduce a number of rides according to a predefined outlier threshold; isolate the identified one or more stations from the one or more routes; and provide at least one alternative mode of transportation.

[0014] In accordance with further embodiments of the invention, a system may be provided which may implement the methods described herein according to some embodiments of the invention.

[0015] These and other aspects, features and advantages will be understood with reference to the following description of certain embodiments of the invention.

BRIEF DESCRIPTION OF THE DRAWINGS

[0016] The subject matter regarded as the invention is particularly pointed out and distinctly claimed in the concluding portion of the specification. The invention, however, both as to organization and method of operation, together with objects, features and advantages thereof, may best be understood by reference to the following detailed description when read with the accompanied drawings. Embodiments of the invention are illustrated by way of example and not limitation in the figures of the accompanying drawings, in which like reference numerals indicate corresponding, analogous or similar elements, and in which:

[0017] FIG. 1 is a high-level diagram illustrating an example configuration of a system for performing one or more aspects of the invention described herein, according to at least one embodiment of the invention;

[0018] FIG. 2 is a high-level block diagram showing key elements of the system of FIG. 1, according to at least one embodiment of the invention;

[0019] FIG. 3 is a high-level block diagram of an optimization engine, according to at least one embodiment of the invention;

[0020] Fig. 4 is a flow diagram of a method for providing a real-time smart transportation platform facilitating rides for a plurality of passengers to a destination, according to at least one embodiment of the invention;

[0021] FIG. 5 is a flow diagram of a method of clustering a plurality of passengers into a plurality of stations is provided according to at least one embodiment of the invention; [0022] FIG. 6 is an example output of the station clustering engine, according to at least one embodiment of the invention;

[0023] FIG. 7 is a flow diagram of a method of composing one or more routes for the plurality of stations, according to at least one embodiment of the invention;

[0024] FIG. 8 and FIG. 9 are an example ordering problem and prior art solution, respectively;

[0025] FIGS. 10-13 are an example ordering problem and progressive steps of an improved solution, according to at least one embodiment of the invention;

[0026] FIGS. 14 and 15 are before and after views of a map containing various passengers and the clusters of stations to which they are assigned, respectively, according to at least one embodiment of the invention;

[0027] FIG. 16 is a user interface with assigned clustered stations, according to at least one embodiment of the invention;

[0028] FIG. 17 is a benchmarking engine, according to at least one embodiment of the invention;

[0029] FIG. 18 shows the input of reports and the output of a rides list on a User Interface, according to at least one embodiment of the invention;

[0030] FIG. 19 is a bird’s-eye-view of all the routes and an editing process, according to at least one embodiment of the invention; and

[0031] FIG. 20 is a system for tracking locations of a driver and a passenger, according to at least one embodiment of the invention.

[0032] It will be appreciated that, for simplicity and clarity of illustration, elements shown in the figures have not necessarily been drawn accurately or to scale. For example, the dimensions of some of the elements may be exaggerated relative to other elements for clarity, or several physical components may be included in one functional block or element. Further, where considered appropriate, reference numerals may be repeated among the figures to indicate corresponding or analogous elements.

DETAILED DESCRIPTION OF THE INVENTION

[0033] In the following description, various aspects of the present invention will be described. For purposes of explanation, specific configurations and details are set forth in order to provide a thorough understanding of the present invention. However, it will also be apparent to one skilled in the art that the present invention may be practiced without the specific details presented herein. Furthermore, well known features may be omitted or simplified in order not to obscure the present invention.

[0034] Although embodiments of the invention are not limited in this regard, discussions utilizing terms such as, for example, “processing,” “computing,” “calculating,” “determining,” “establishing”, “analyzing”, “checking”, or the like, may refer to operation(s) and/or process(es) of a computer, a computing platform, a computing system, or other electronic computing device, that manipulates and/or transforms data represented as physical (e.g., electronic) quantities within the computer’ s registers and/or memories into other data similarly represented as physical quantities within the computer’s registers and/or memories or other information non-transitory processor-readable storage medium that may store instructions, which when executed by the processor, cause the processor to perform operations and/or processes. Although embodiments of the invention are not limited in this regard, the terms “plurality” and “a plurality” as used herein may include, for example, “multiple” or “two or more”. The terms “plurality” or “a plurality” may be used throughout the specification to describe two or more components, devices, elements, units, parameters, or the like. The term set when used herein may include one or more items. Unless explicitly stated, the method embodiments described herein are not constrained to a particular order or sequence. Additionally, some of the described method embodiments or elements thereof may occur or be performed simultaneously, at the same point in time, or concurrently.

[0035] Systems and methods of the invention provide a platform that is an end-to-end solution for transportation in the Business-to-Business (B2B) area. Embodiments of the invention provide command and control of all the processes from the employee to the driver, the ability to plan, control execution, perform day-to-day investigation, and provide an automatic Proof of Transit (POT) solution. For example, each of the following features may be provided by one smart transportation optimization platform according to various embodiments of the invention: passengers/riders (e.g., employees) may submit shift times; an optimization engine may compose the best routes a predefined number of hours before each shift; drivers and passengers may be notified about the routes and estimated times, and both may be able to view the other’s location(s), e.g., via a mobile GPS-based application; and a manager and/or a dispatcher may be able to view and/or manage and/or modify routes and rides in real-time. [0036] From the customer-worker-side, embodiments of the invention may provide at least the following advantageous features: independent registration for work shifts, immediate ride reservation, real-time tracking of driver location, and push notifications.

[0037] From the customer-manager-side, embodiments of the invention may provide at least the following advantageous features: full back-office website to manage transportation, bird’s- eye-view on all transportation data, real-time tracking, optimized routes, financial reports, and recommendations .

[0038] From the transport-supplier-side, embodiments of the invention may provide at least the following advantageous features: management and registration of drivers and existing vehicles, edit price lists for customers/drivers/contractors, automatic pricing based on predefined parameters, detailed reports for drivers/customers/contractors, live view of all orders and reservations, real-time all-driver location and performance, and real-time tracking of ride changes.

[0039] Finally, from the driver side, embodiments of the invention may provide at least the following advantageous features: financial reports, and a watch ride list.

[0040] These and other aspects of the invention are explained in further detail herein with reference to the figures.

[0041] , according to at least one embodiment of the invention. System 100 includes network 105, which may include the Internet, one or more telephony networks, one or more network segments including local area networks (LAN) and wide area networks (WAN), one or more wireless networks, or a combination thereof. System 100 also includes a system server 110 constructed in accordance with one or more embodiments of the invention. In some embodiments, system server 110 may be a stand-alone computer system. In other embodiments, system server 110 may include a network of operatively connected computing devices, which communicate over network 105. Therefore, system server 110 may include multiple other processing machines such as computers, and more specifically, stationary devices, mobile devices, terminals, and/or computer servers (collectively, “computing devices”). Communication with these computing devices may be, for example, direct or indirect through further machines that are accessible to the network 105.

[0042] System server 110 may be any suitable computing device and/or data processing apparatus capable of communicating with computing devices, other remote devices or computing networks, receiving, transmitting and storing electronic information and processing requests as further described herein. System server 110 is therefore intended to represent various forms of digital computers, such as laptops, desktops, workstations, personal digital assistants, servers, blade servers, mainframes, and other appropriate computers and/or networked or cloud based computing systems capable of employing the systems and methods described herein.

[0043] System server 110 may include a server processor 115 which is operatively connected to various hardware and software components that serve to enable operation of the system 100. Server processor 115 serves to execute instructions to perform various operations relating to advanced search, and other functions of embodiments of the invention as described in greater detail herein. Server processor 115 may be one or a number of processors, a central processing unit (CPU), a graphics processing unit (GPU), a multi-processor core, or any other type of processor, depending on the particular implementation.

[0044] System server 110 may be configured to communicate via communication interface 120 with various other devices connected to network 105. For example, communication interface 120 may include but is not limited to, a modem, a Network Interface Card (NIC), an integrated network interface, a radio frequency transmitter/receiver (e.g., Bluetooth wireless connection, cellular, Near-Field Communication (NFC) protocol, a satellite communication transmitter/receiver, an infrared port, a USB connection, and/or any other such interfaces for connecting the system server 110 to other computing devices and/or communication networks such as private networks and the Internet.

[0045] In certain implementations, a server memory 125 is accessible by server processor 115, thereby enabling server processor 115 to receive and execute instructions such a code, stored in the memory and/or storage in the form of one or more software modules 130, each module representing one or more code sets. The software modules 130 may include one or more software programs or applications (collectively referred to as the “server application”) having computer program code or a set of instructions executed partially or entirely in server processor 115 for carrying out operations for aspects of the systems and methods disclosed herein, and may be written in any combination of one or more programming languages. Server processor 115 may be configured to carry out embodiments of the present invention by, for example, executing code or software, and may execute the functionality of the modules as described herein. [0046] In FIG. 1, the exemplary software modules may include a communication module, and other modules as described here. The communication module may be executed by server processor 115 to facilitate communication between system server 110 and the various software and hardware components of system 100, such as, for example, server database 135, client device 140, and/or external third-party systems (server and/or database) 175 as described herein.

[0047] Of course, in some embodiments, server module(s) 130 may include more or less actual modules which may be executed to enable these and other functionalities of the invention. The modules described herein are therefore intended to be representative of the various functionalities of system server 110 in accordance with some embodiments of the invention. It should be noted that in accordance with various embodiments of the invention, server module(s) 130 may be executed entirely on system server 110 as a stand-alone software package, partly on system server 110 and partly on one or more of user device 140 and/or third party system(s) 175, or entirely on user device 140 and/or third party system(s) 175.

[0048] Server memory 125 may be, for example, a random access memory (RAM) or any other suitable volatile or non-volatile computer readable storage medium. Server memory 125 may also include storage which may take various forms, depending on the particular implementation. For example, the storage may contain one or more components or devices such as a hard drive, a flash memory, a rewritable optical disk, a rewritable magnetic tape, or some combination of the above. In addition, the memory and/or storage may be fixed or removable. In addition, memory and/or storage may be local to the system server 110 or located remotely.

[0049] In accordance with further embodiments of the invention, system server 110 may be connected to one or more database(s) 135, for example, directly or remotely via network 105. Database 135 may include any of the memory configurations as described herein, and may be in direct or indirect communication with system server 110. In some embodiments, database 135 may store information relating to user documents. In some embodiments, database 135 may store information related to one or more aspects of the invention.

[0050] As described herein, among the computing devices on or connected to the network 105 may be one or more user devices 140. User device 10 may be any standard computing device. As understood herein, in accordance with one or more embodiments, a computing device may be a stationary computing device, such as a desktop computer, kiosk and/or other machine, each of which generally has one or more processors, such as user processor 145, configured to execute code to implement a variety of functions, a computer-readable memory, such as user memory 155, a user communication interface 150, for connecting to the network 105, one or more user modules, such as user module 160, one or more input devices, such as input devices 165, and one or more output devices, such as output devices 170. Typical input devices, such as, for example, input devices 165, may include a keyboard, pointing device (e.g., mouse or digitized stylus), a web-camera, and/or a touch- sensitive display, etc. Typical output devices, such as, for example output device 170 may include one or more of a monitor, display, speaker, printer, etc.

[0051] In some embodiments, user module 160 may be executed by user processor 145 to provide the various functionalities of user device 140. In particular, in some embodiments, user module 160 may provide a user interface with which a user of user device 140 may interact, to, among other things, communicate with system server 110

[0052] Additionally or alternatively, a computing device may be a mobile electronic device (“MED”), which is generally understood in the art as having hardware components as in the stationary device described above, and being capable of embodying the systems and/or methods described herein, but which may further include componentry such as wireless communications circuitry, gyroscopes, inertia detection circuits, geolocation circuitry, touch sensitivity, among other sensors. Non-limiting examples of typical MEDs are smartphones, personal digital assistants, tablet computers, and the like, which may communicate over cellular and/or Wi-Fi networks or using a Bluetooth or other communication protocol. Typical input devices associated with conventional MEDs include, keyboards, microphones, accelerometers, touch screens, light meters, digital cameras, and the input jacks that enable attachment of further devices, etc.

[0053] In some embodiments, user device 140 may be a “dummy” terminal, by which processing and computing may be performed on system server 110, and information may then be provided to user device 140 via server communication interfacel20 for display and/or basic data manipulation. In some embodiments, modules depicted as existing on and/or executing on one device may additionally or alternatively exist on and/or execute on another device. For example, in some embodiments, one or more modules of server module 130, which is depicted in Fig. 1 as existing and executing on system server 110, may additionally or alternatively exist and/or execute on user device 140 and/or third-party server 175. Likewise, in some embodiments, one or more modules of user module 160, which is depicted in FIG. 1 as existing and executing on user device 140, may additionally or alternatively exist and/or execute on system server 110 and/or third-party server 175. In some embodiments, third-party server 175 may provide the same or similar structure and/or functionality as system server 110, but may be owned, possessed, and/or operated by a third-party.

[0054] FIG. 2 is a high-level block diagram 200 showing key elements of the system of FIG.

1, according to at least one embodiment of the invention. As shown in FIG. 2, embodiments of the invention provide communication and coordination between four primary elements: customers (e.g., companies providing transportation), passengers (e.g., employees), transportation suppliers, and drivers (e.g., employees of the transportation supplier, independent contractors, etc.). In some embodiments, company manager 205 may provide to a centralized optimization system (e.g., system server 110 of FIG. 1) information regarding the company’s employees and other various requirements necessary for coordination of rides for the employees. In some embodiments, passenger(s) 205 may provide to the centralized optimization system shift information (e.g., e.g., starting/ending times of shifts which may generally correlate with arrival and depart times, respectively). In some embodiments, dispatcher 215 may provide to the centralized optimization system information about available drivers, cost information, etc. In some embodiments, drivers(s) 220 may provide to the centralized optimization system location and availability information, vehicle constraints (e.g., number of passengers per vehicle), etc. In various embodiments, these and/or other relevant information may be provided to the route optimization system, which may then provide optimized route information, e.g., to all parties.

[0055] FIG. 3 shows a high-level block diagram of an optimization engine 300, according to at least one embodiment of the invention. As described herein, optimization engine 300 is the core of the systems and methods described herein for providing a real-time smart transportation platform. An important function of the optimization engine 300 is to transform employees’ reservations to rides sets within preset or defined limitations, as described herein. Delivery/transportation companies may use the optimization for ordering the stops based on the reservations. As described herein, in some embodiments, a benchmark system may use the optimization engine to calculate the minimal cost for the same reservations of employees shifts/rides. The platform may provide an end-to-end solution for companies that transport employees from/to the office, e.g., daily.

[0056] In some embodiments, optimization engine 300 may be executed in part or entirely on system server 110 of FIG. 1. In some embodiments, optimization engine 300 contains an API Gateway 305, which may enable integration of optimization engine 300 with other elements of the system (e.g., as shown in FIG. 1 and FIG. 2). In some embodiments, optimization engine 300 may include various modules and sub-engines which may be configured to handle and process various aspects of the invention, each of which will be described in further detail herein. For example, in some embodiments, optimization engine 300 may include a grouping service 310, a debugger service 315, a ride/shift parser 320, and a human history change recorder 325. In some embodiments, optimization engine 300 may further include a station cluster engine 330, which may include a clustering service 335, a Dual Learning Engine 340, and a linear constraint solver 345. In some embodiments, optimization engine 300 may further include a Maps Services Engine 350, which may include a Geocoder 355, a Distance and Time Matrix Builder 360, a Nearest Road Service 365, and a Bus Station / Public Transit Service 370. Finally, in some embodiments, optimization engine 300 may further include a Route Composer Engine 375, which may include a TSP Solver 380 and a Route Learning engine 385. Of course, those skilled in the art will understand that more or less modules and/or sub-engines may be included in order to provide the various functionalities and features of the invention as described herein.

[0057] Fig. 4 is a flow diagram of a method 400 for providing a real-time smart transportation platform facilitating rides for a plurality of passengers to a destination, according to at least one embodiment of the invention. It should be noted that, in some embodiments, method 400 may implement one or more of the elements, features, and/or functions of system 100, e.g., as described in detail herein.

[0058] In order to appreciate various aspects of the invention, the following terms and definitions are provided:

[0059] pickup route - from home (e.g., initial departure location) to work office (e.g., destination location)

[0060] drop route - from work office (e.g., destination location) to home (e.g., initial departure location)

[0061] reservations - source address, destination address, and time stamp (e.g., a point-to-point ‘taxi’ order at a specific time)

[0062] rides - set of ordered stop stations (coordinates), passenger quantity, source point, destination point, and estimated times of arrivals [0063] set of rides - refers to N different vehicles which arrived/departed to the same company address at the same time

[0064] Nearest road API -The Roads API (e.g., Nearest Road Service 365 of FIG. 3) takes independent coordinates and returns the closest road segment for each point. The points passed do not need to be part of a continuous path. If the nearest road is bidirectional, two points may be returned.

[0065] Duality of stations (duel stations) - In mathematical optimization theory, duality or the duality principle is the principle that optimization problems may be viewed from either of two perspectives. A duel station may be an alternative station to a main station, which fits certain criteria, as explained herein.

[0066] Station (main station and dual station) - a station is a pickup/drop point, e.g., for an employee, that fits certain limitations, e.g., limits of a predefined walking distance. Any station may be designated as a main station and may have dual stations which are close to the main station and still keep the walking time limitations for most of the users at the station. However, often they are in different directions of traffic (for example, a dual station may be on the same road but on the opposite side of the street).

[0067] farthest and closest stations - calculated by time duration driving between them

[0068] limitations- predefined limitations to which the system is configured to adhere, e.g., when making calculations, as described herein. For example, configurable limitations for the process may include, maximum ride total time, vehicle type and capacity (e.g., four per taxi (4P), fifty per bus (50P), fourteen per minibus (14P), etc.), maximum deviation time in minutes for a passenger compared to if the passenger was the only passenger in the ride, maximum walk time from pickup/drop station, etc.

[0069] TSP - “traveling salesman problem” (explained in detail below): there are no solutions in polynomial time to this problem; embodiments of the optimization system may execute, e.g., an existing open-source solver to solve a similar problem. One such solver is called OR-Tools from Google® and there are others like it known in the art. The solver solves the problem in a naive way but within a short period of time (seconds to hours, depending on the data quantity). No polynomial time to a problem, as understood herein, means that it takes substantial computing time to calculate the best solution.

[0070] In some embodiments, method 400 begins at step 405, when a processor (e.g., server processor 115 of FIG. 1) receives data representing a plurality of passengers (e.g., passenger(s) 210 of FIG. 2). As described herein, in various embodiments, data may be provided in a number of different formats, e.g., directly by each individual passenger, in a single data structure from the customer (e.g., from company manager 205 of FIG. 1), such as a shifts report, a rides report, etc. Furthermore, data may include current data and/or historical data (e.g., data about past shifts and/or rides of the same and/or other passengers), as described in detail herein.

[0071] At step 410, in some embodiments, the optimization process may begin (e.g., by implementing optimization engine 300 of FIG. 3), when the processor is configured to cluster the plurality of passengers into a plurality of stations, as described in detail with reference to FIG. 5.

[0072] Turning to FIG. 5, a flow diagram of a method 500 of clustering a plurality of passengers into a plurality of stations is provided according to at least one embodiment of the invention (e.g., implemented by Station Cluster Engine 330 of FIG. 3). In some embodiments, the input may be a bulk of passengers’ home addresses, maximum walking time to a station, and, optionally, bus stations and/or other public transportation in the area. In some embodiments, the output may be that each passenger may be assigned a main station for pickup/drop, each station may have a plurality of dual stations which are close to the main station but still keep the walking time limitations for most of the users at the station, though the duel stations may be in a different direction of traffic (for example, a dual station could be at the same road but on the opposite side sidewalk).

[0073] In some embodiments, method 500 may begin at step 505 when the processor may divide passengers (e.g., using clustering service 335 of FIG. 3) into initial clusters using, e.g., a k-means algorithm (or any other clustering algorithm as known in the art), e.g., to reduce the size of the data and run the steps that follow in method 500 on each initial cluster. Note, this step may not be required, e.g., if the total number of passengers is already a reasonably sized set, but may be implemented in some embodiments, e.g., to improve processing time, etc.

[0074] In some embodiments, at step 510, the processor may find/identify a plurality of initial stations (e.g., using maps services 350 and geocoder 355 of FIG. 3). In some embodiments, for each user, the engine may stab N points in the radius of 0 to M meters (e.g., based on geographical distance) in the gap of K, e.g., randomly, and find the nearest road from each stab, e.g., using Google® Maps API or any other developed engine. If a nearest road is a bidirectional road, the system may return two stations (one will be identified as a dual station and one as a main station, as described herein). The results are the initial stations. It should be noted that K, M, and N may be user-configurable.

[0075] In some embodiments, at step 515, the processor may find/identify a plurality of main stations (e.g., using linear constraint solver 345 of FIG. 3). In some embodiments, the engine may iterate recursively over each initial station relative to all the passengers in which a maximum walking distance is within a predefined limit. When an iteration is completed, in some embodiments, the system may select the station with the most passengers to be a main station, and then iterate again on the station, but without the passengers who have been assigned the main station, until all the passengers have been assigned main stations.

[0076] In some embodiments, at step 520, the processor may be configured to relate (e.g., reassign) passengers to their closest station. For example, after the process described in 515, it is possible that a passenger may not have been assigned to the passenger’s closest main station. Therefore, in some embodiments, the system may be configured to iterate through the users and adjust assignments accordingly.

[0077] In some embodiments, at step 525, the processor may find/identify a plurality of dual stations, e.g., for each identified main station. In some embodiments, for each main station the engine may stab N points in the radius of 0 to M meters (e.g., based on geographical distance) in the gap of K, e.g., randomly, and find the nearest road from each stab, e.g., using Google® Maps API or any other developed maps engine. The processor may select from these new stabs X station(s) to be a dual station for the main station (e.g., in addition to any dual stations found in step 510. It should be noted that K, M, N, and X may be user-configurable.

[0078] At the end of the process, in some embodiments, each user should have at least one main station and each main station should have at least one dual station.

[0079] In some embodiments, the system may be configured to add bus station stops and/or other public transportation stops as dual stations if they fit predefined limitations. In some embodiments, the system may add a dual station from dual learning engine 340, which may be based on the history of human changes in the platform.

[0080] In some embodiments, the processor may implement an initial grouping phase, e.g., prior to step 505, in which the system may divide the reservations into groups based on the various schedules/shifts of different passengers (e.g., using grouping service 310). For example, in some embodiments, each group may have the same direction of ride (pickup or drop from/to the company office) and the same arrival/departure time of the reservation (shift start time / shift end time). This means, for example, that all the reservations to get to the office at 8:00AM will be in the same group and all the reservations to get to the office at 9:00AM will be in another group, all the reservations to leave the office at 5:00PM will be in yet another group, etc.

[0081] Turning briefly to FIG. 6, an example output of the station clustering engine is provided according to at least one embodiment of the invention. In this example, three (3) dual stations (shown as a teardrop with a van) and one (1) main station (shown as a teardrop with a dot) were generated for five (5) different passengers (shown as a teardrop with an avatar).

[0082] Returning to FIG. 4, at step 415, the processor may be configured to compose one or more routes for the plurality of stations, as explained in detail with reference to FIG. 7.

[0083] Turning to FIG. 7, a flow diagram of a method 700 of composing one or more routes for the plurality of stations is provided according to at least one embodiment of the invention (e.g., implemented by Route Composer Engine 375 of FIG. 3). In some embodiments, the input may be a bulk of reservations and the output may be ordered routes with an efficient station location for each passenger.

[0084] In order to emphasize a core innovative aspect of embodiments of the invention, namely, the functionality of route composer engine 375, some background information is provided herein with respect to Google® OR Tools and its inherent limitations:

[0085] Google® OR Tools is an open source software for combinatorial optimization, which seeks to find the best solution to a problem out of a very large set of possible solutions. Below are some examples of problems that OR-Tools solves in a naive way:

[0086] Vehicle routing: Finds optimal routes for vehicle fleets that pick up and deliver packages given constraints (e.g., “this truck can't hold more than 20,000 pounds” or “all deliveries must be made within a two-hour window”).

[0087] Scheduling: Finds the optimal schedule for a complex set of tasks, some of which need to be performed before others, on a fixed set of machines, or other resources.

[0088] Bin packing: Calculates packing of as many objects of various sizes as possible into a fixed number of bins with maximum capacities.

[0089] In most cases, problems like these have a vast number of possible solutions - too many for a computer to search them all. To overcome this, OR Tools uses algorithms to narrow down the search set, in order to find an optimal (or close to optimal) solution. OR-Tools includes solvers for the following:

[0090] Constraint Programming: A set of techniques for finding feasible solutions to a problem expressed as constraints (e.g., a room cannot be used for two events simultaneously, or the distance to the crops must be less than the length of the hose, or no more than five TV shows can be recorded at once).

[0091] Linear and Mixed-Integer Programming: The Glop linear optimizer finds the optimal value of a linear objective function, given a set of linear inequalities as constraints (e.g., assigning people to jobs, or finding the best allocation of a set of resources while minimizing cost). Glop and the mixed-integer programming software SCIP are also available via the Google Apps Script Optimization Service.

[0092] Vehicle Routing: A specialized library for identifying best vehicle routes given constraints.

[0093] Graph Algorithms: Code for finding shortest paths in graphs, min-cost flows, max flows, and linear sum assignments.

[0094] Embodiments of the invention provide an improvement to and modification of the OR Tools TSP solution by reordering the route with dual stations (e.g., using TSP Solver 380 of FIG. 3). Specifically, a core element of the Route Composing algorithm employs an innovative modification of the Google® OR-Tools solution for TSP to solve the best order of a route for a set of stations that includes main stations and dual stations.

[0095] Turning briefly to FIG. 8 and FIG. 9, an example ordering problem and prior art solution, respectively, are provided. Given a distance matrix between dots as seen in FIG. 8, and a number of vehicles, Google® OR-Tools gives the routes with the least total distance that start and end at the same dot. In this case, as seen in FIG. 9, the OR-Tool gave a solution for four (4) vehicles. Another feature of the OR-Tools solver is the ability to add a capacity to a vehicle or to add constraints to the route (e.g., max distance / max time) which force the solver to create the route with specific demands. This makes the problem more difficult to solve, and Google® OR-Tools does not provide accurate or useful results.

[0096] However, embodiments of the invention, as described in detail herein, reduce the amount of data (e.g., to at most 100 nodes including dual stations in each route), greatly improving the accuracy and usefulness of the results. [0097] In some embodiments, method 700 may begin at step 705 when the processor may be configured to build or generate a distance and time matrix (e.g., using Distance and Time Matrix Builder 360 of FIG. 3). In some embodiments, the processor may be configured to construct or generate a distance and time matrix (e.g., using Google® Maps API or any other developed Maps systems) between each station to all other stations including all dual stations.

[0098] At step 710, the processor may be configured to compose one or more initial routes beginning from a farthest station from the destination, based at least in part on the distance and time matrix. In some embodiments, to compose initial routes, the processor may implement one or more steps of the following process: (i) identify/select from all stations which are not handled yet the farthest main station from the office address (e.g. the destination); (ii) identify/select the best dual station of the station in step i. which fits the ride direction (if the duel station is a better fit than the main station, this duel will be used instead of the main station; otherwise, the main station will be used); (iii) mark this station and all of its duals stations as handled; (iv) identify/select the closest station to merge it into the route; if it does not break the limitations it may be added to the route, the station and any associated duel stations are marked as handled; (v) reorder the route, e.g., with OR-TOOLS or another TPS Solver, e.g., TPS 380 of FIG. 3; (vi) repeat on steps iv.-v. until any of the limitations are exceeded; and (vii) define the set of these stations as a route.

[0099] It will be understood by those skilled in the art that the above process optimizes pickup routes; drop routes start from the closest station to the office and then continue in the same way in reverse.

[00100] Once this process has been completed, in some embodiments it may be necessary to repeat step 710 (composing initial routes) until there are no more stations which are not handled.

[00101] At step 715, if a first given route can be merged with a second given route without exceeding one or more routing limitations, the processor may be configured to merge the first and second given routes. In some embodiments, routes may be improved which may reduce the number of vehicles required to cover all stations.

[00102] In some embodiments, to compose improve routes, the processor may implement one or more steps of the following process: (i) pick the A routes with the minimum number of passengers and pick all the routes with less than M passengers; (ii) for each route of step i., the processor may check if the route can be merged completely to another route without breaking predefined limitations (e.g., the check may also use the OR-tool, reorder with all possible dual stations versions, etc.); (iii) if there are still routes from step i., the processor may be configured to try to iterate over each station in each route and see if the route can be merged to different routes and still keep within the limitations, in which case the processor may merge all stations of a route (or not merge the route at all if the limitations would be violated, e.g., if a passenger would have to walk too far to a designated station).

[00103] In some embodiments, the processor may provide adjustments and/or alternatives to the OR-tools solver, e.g., by running the solver with a specific end/start point, one vehicle, and without the need to return to the same depot. This specific end/start point may be the office location (e.g., the destination). In some embodiments, this will give the system the best station order to a given route. However, such an adjustment does not take into consideration dual stations, as explained with reference to FIGS. 10-13.

[00104] Turning briefly to FIGS. 10-13, in FIG. 10 an example set of stations are shown according to an embodiment of the invention. In FIG 11, a basic initial route is calculated, connecting station 1

station 3c

station 3b

station 3a

station 2

station 4

Office (destination). As shown in FIG. 12, in some embodiments, the processor may be configured to cluster stations 3a, 3b, and 3c together (e.g., as described in detail herein), and assign station 3a as main station with stations 3b and 3c being dual stations that fall within predefined limitations, therefore enabling passengers of those stations to be serviced at station 3a, as shown in FIG 13, thus significantly improving the initial route.

[00105] Initially, stations 3a, 3b, and 3c in FIGS. 10-13 may be dual stations to each other. A simple run (in FIG. 10) of the solver will give the solution in FIG. 11. To force the solver to pick the best dual station, embodiments of the invention may configure the processor to add a penalty to the distance between each of the dual stations and add a constraint to the solver which limits the distance a vehicle can cover, as shown in FIG. 12. This forces the solver to choose a path with only one dual station of the group and skip all others, which gives the solution in FIG. 13. With the same principle, the system may be configured to adjust to any dual station group in the route. Of course, other modifications may be provided to generate different optimizations.

[00106] Turning briefly to FIGS. 14 and 15, before and after views of a map containing various passengers and the clusters of stations to which they are assigned, respectively, are shown according to embodiments of the invention. As is readily apparent from the figures, embodiments of the invention provide improved routes by minimizing unnecessary stations.

[00107] Returning to FIG. 7, at step 720, the processor may be configured to fine-tune the routes based on a history of human/manual changes to a given route, e.g., using route learning engine 385 of FIG. 3.

[00108] Returning to FIG. 4, at step 420, with the stations clustered and the routes composed, the processor may be configured to notify the drivers and the passengers of the designated composed routes and estimated times. Of course, dispatchers and managers may also be notified of the composed routes and estimated times. Furthermore, in some embodiments, the information may be displayed on various devices including mobile devices, computers, etc.

[00109] Finally, at step 425, the processor may be configured to manage all routes, e.g., in real-time, and make any adjustments that may be required to optimize the routes. For example, real-time information such as traffic reports, weather reports, shift changes, cancelations, vehicle break-downs, etc., may impact previously composed routes, which may be adjusted in real time.

[00110] Turning briefly to FIG. 16, a user interface with assigned clustered stations is shown according to at least one embodiment of the invention. Details of each cluster/route may be provided and may be e.g., color coordinated to enhance clarity. Information regarding specific passengers’ stations and walking distance from the stations may be provided as well.

[00111] Additional features and advantages of the invention may be realized according to various embodiments of the invention. For example, for potential and existing customers, providing the ability to save on transportation expenses may be a very important issue. Currently, most companies have no idea about business intelligence (BI) and statistics regarding their transportation expenses. Accordingly, embodiments of the invention may show expenses of various routes in real-time. In some embodiments, a benchmarking engine may provide a real-time view of transportation expenses of the company, e.g., per employee, per city, etc., and many more relevant fields.

[00112] Turning briefly to FIG. 17, a benchmarking engine is shown according to at least one embodiment of the invention. [00113] Within a given rides report of a company or shifts times and addresses of employees, embodiments of the invention may predict savings in transportation expenses (e.g., in percentages) and other efficiencies.

[00114] In some embodiments, the engine may reorder all the rides and decide on the best station for pickup and/or drop of an employee per each ride. Maximum ride time, vehicle limits, and maximum walking time for each pickup/drop station are all configurable.

[00115] Turning to FIG. 18, in some embodiments, the invention may be configured to receive a massive amount of data (e.g., as a .csv file) and parse/process it into visual and informative data with price offers within minutes, while minimizing processing power due to the improvements and innovations described herein (e.g., using ride/shift parser 320 of FIG. 3). As can be seen in FIG. 18, the input is an Excel report of company shifts and the output is a rides list for each day with the passengers, times estimations, and price estimations. The process of creating the routes and the stations composing is explained in detail in the description of the optimization routes engine herein.

[00116] In some embodiments, the engine can process the employee addresses to coordinate using any mapping API, e.g., Google Maps API. The engine may take into account the traffic and arrival time, etc.

[00117] In some embodiments, when the process starts, a number of parameter fields may be configured, for example: maximum time of a ride, maximum deviation (e.g., in minutes) from the first rider to the endpoint, vehicle capacity, walking distance from employee home address to pick-up point, etc.

[00118] In some embodiments, the user may run the processes on past rides reports of a company instead of on the shifts data, and the engine can iterate ride-by-ride per day, decompose them to shifts reports, and then rebuild the routes with the optimization engine. Then the platform may point out how many fewer vehicles were used with the same concentrations (e.g., maximum ride time and vehicle capacity). In some embodiments, if there are employees whose locations are isolated (e.g., out of the way for most of the rides) the program may be configured to mark them as a ‘waste-causing,’ which means that if they were removed from the list, the number of rides per month would be reduced. In some embodiments, the engine may display public transportation alternatives for each employee, e.g., based on Google Maps Data or other databases. Furthermore, the engine may recommend employees which can travel by public transportation without a significant difference in journey time. In some embodiments, the calculation of a ride’s time and distance may be taken from a map database, e.g., Google Maps API or any other developed maps systems.

[00119] In some embodiments, the system may predict how much a new employee will cost the company (e.g., divided by city or area, etc.). This may be accomplished by iterating each day backward in the past to see if the user could be inserted into an existing vehicle without breaking the previously defined limits (e.g., maximum ride time, maximum deviation, vehicle capacity, etc.), or if it will cause a new vehicle expense. The system may also rerun the whole process with the new employee and point out the difference in the expenses/number of vehicles. The platform may also predict how the transportation costs will be changed if the company changes its office location, based on rerunning the whole process with the new office location. In some embodiments, the platform may be integrated with other route optimizations engines with minor finetuning.

[00120] In some embodiments, some users/clients have close work locations, for example, three hotels near the beach which are located 200 meters from each other, or four office buildings which are located at the same industry park 300 meters from each other. In some embodiments, the system may merge the office locations and run the optimization task for the multiple locations together to reduce the number of vehicles

[00121] In some embodiments, every step and iteration may be displayed on a user interface (UI) within a map along with complete logs of the decision making in the route composing phase and in the station clustering phase. The platform may execute iterations backward and/or forward and change data on the run to understand the best configuration for the specific cycle (e.g., using Debugging service 315).

[00122] Turning briefly to FIG. 19, in some embodiments, the system may provide a bird’s-eye-view of all the routes and the process, and the ability to edit routes and understand the duration time cost for each editing, and report any anomalies, results, etc. Reports provided by the system may include, for example, attendance status of workers to the ride, planning vs actual performance of the driver, etc.

[00123] In some embodiments, whenever a human eye is looking at the set of rides and makes some changes on the platform, the system may be configured to record the change and whenever there are the same set of rides the optimization engine will make the same change to the set of the rides (e.g., using human history change record 325 of FIG. 3). This may happen often because the same group of employees may go to the same office during the same hours over a month.

[00124] The platform enables the option to add a new passenger to a set of rides, the platform iterates over the rides and chooses the best (e.g., having the least effect of time and/or distance) rides to fit in the new passenger without breaking the limitation which were mentioned above, if there is such a ride.

[00125] One of the biggest problems in B2B transportation is the proof that a user gets on/gets off the vehicle. In some embodiments, the system may provide a live location infrastructure which achieves this without necessitating any other electronic devices except smartphones and the platform’s mobile application. The system may track the driver location and the passenger(s) location(s) with the GPS sensor on the devices of each and send it to the system’s live location engine.

[00126] Turning briefly to FIG. 20, in some embodiments, the system may track the driver and a passenger’s locations and see if there are similarities between both paths. If the similarity of the speed and path starts on the passenger’s stop station, the system may assume the user got on the vehicle. Optionally, the system may use the NFC chip or Bluetooth of the passenger’s device, which are available on most mobile devices, and make a handshake between the driver and the passenger. In some embodiments, this live location tracker may be useful for many other features such as notifications-based driver location (e.g., “The [driver/passenger] will be there in 3 minutes.”). The system may notify the manager if the driver deviates from the track, or track the driver’s performance to ensure the driver is on schedule. In some embodiments, the system may generate a real time view of the rides status on the map of the UI. This feature may be used to insert a real-time reservation for rides to the closest driver with the best track. Furthermore, the system can record the driver path and performance for reports.

[00127] Unless explicitly stated, the method embodiments described herein are not constrained to a particular order or sequence. Furthermore, all formulas described herein are intended as examples only and other or different formulas may be used. Additionally, some of the described method embodiments or elements thereof may occur or be performed at the same point in time.

[00128] While certain features of the invention have been illustrated and described herein, many modifications, substitutions, changes, and equivalents may occur to those skilled in the art. It is, therefore, to be understood that the appended claims are intended to cover all such modifications and changes as fall within the true spirit of the invention.

[00129] Various embodiments have been presented. Each of these embodiments may of course include features from other embodiments presented, and embodiments not specifically described may include various features described herein.

Claims

What is claimed is:

1. A method for providing a real-time smart transportation platform facilitating rides for a plurality of passengers to a destination, comprising: receiving, by a processor, data representing the plurality of passengers; wherein the data comprises address information of each passenger of the plurality of passengers; clustering, by the processor, the plurality of passengers into a plurality of stations; composing, by the processor, one or more routes for the plurality of stations; and monitoring, by the processor, in real time, a status of one or more rides which follow the one or more composed routes.

2. The method as in claim 1, wherein the one or more routes are composed based on at least one of a maximum time of a ride, a maximum deviation from a first station of the plurality of stations to an endpoint, a vehicle capacity, or a walking distance from an address of a given passenger to a given station into which the given passenger has been clustered.

3. The method as in claim 1 wherein the data further comprises a rides report of a company.

4. The method as in claim 1, wherein the data further comprises shift times of each of the plurality of passengers; and wherein the method further comprises: dividing, by the processor, the plurality of passengers into one or more groups, each group having a same direction of ride and at least one of a same arrival time or same departure time, based on the shift times.

5. The method as in claim 1, wherein clustering the plurality of passengers into a plurality of stations further comprises: identifying, by the processor, at least one initial station for each of the plurality of passengers; iterating recursively, by the processor, over each initial station relative to all the passengers in which a maximum walking distance is within a predefined limit; identifying, by the processor, one or more main stations from the initial stations based on the iterating step;

24 identifying, by the processor, for each main station, at least one duel station; and assigning, by the processor, each of the plurality of passengers to at least one main station and at least one duel station.

6. The method as in claim 5, further comprising an initial step of dividing, by the processor, the plurality of passengers into a plurality of initial area clusters.

7. The method as in claim 1, wherein composing, by the processor, one or more routes for the plurality of stations comprises: generating, by the processor, a distance and time matrix between each station to all other stations of the plurality of stations; composing, by the processor, one or more initial routes beginning from a farthest station from the destination, based at least in part on the distance and time matrix; and if a first given route can be merged with a second given route without exceeding one or more routing limitations, merging, by the processor, the first and second given routes.

8. The method as in claim 7, further comprising: fine-tuning, by the processor, the at least one of the one or more routes based on a history of manual changes to a given route.

9. The method as in claim 1, wherein clustering the plurality of passengers into a plurality of stations further comprises: assigning, by the processor, each passenger to at least one main station and at least one duel station; and wherein composing the one or more routes for the plurality of stations further comprises: adding, by the processor, for each passenger, one of an assigned main station and an assigned duel station to one route of the one or more routes.

10. The method as in claim 1, further comprising: identifying, by the processor, one or more stations which, if the one or more stations were removed from a composed route would reduce a number of rides according to a predefined outlier threshold; isolating, by the processor, the identified one or more stations from the one or more routes; and providing, by the processor, at least one alternative mode of transportation. A system for providing a real-time smart transportation platform facilitating rides for a plurality of passengers to a destination, comprising: a processor and one or more code sets which, when executed in the processor, configure the processor to: receive data representing the plurality of passengers; wherein the data comprises address information of each passenger of the plurality of passengers; cluster the plurality of passengers into a plurality of stations; compose one or more routes for the plurality of stations; and monitor in real time, a status of one or more rides which follow the one or more composed routes. The system as in claim 11, wherein the one or more routes are composed based on at least one of a maximum time of a ride, a maximum deviation from a first station of the plurality of stations to an endpoint, a vehicle capacity, or a walking distance from an address of a given passenger to a given station into which the given passenger has been clustered. The system as in claim 11, wherein the data further comprises a rides report of a company. The system as in claim 11, wherein the data further comprises shift times of each of the plurality of passengers; and wherein the processor is further configured to: divide the plurality of passengers into one or more groups, each group having a same direction of ride and at least one of a same arrival time or same departure time, based on the shift times. The system as in claim 11, wherein, when clustering the plurality of passengers into a plurality of stations, the processor is further configured to: identify at least one initial station for each of the plurality of passengers; iterate recursively over each initial station relative to all the passengers in which a maximum walking distance is within a predefined limit; identify one or more main stations from the initial stations based on the iterating step; identify for each main station, at least one duel station; and assign each of the plurality of passengers to at least one main station and at least one duel station.

16. The system as in claim 15, wherein the processor is further configured to perform an initial step of dividing the plurality of passengers into a plurality of initial area clusters.

17. The system as in claim 11, wherein, when composing one or more routes for the plurality of stations, the processor is further configured to: generate a distance and time matrix between each station to all other stations of the plurality of stations; compose one or more initial routes beginning from a farthest station from the destination, based at least in part on the distance and time matrix; and if a first given route can be merged with a second given route without exceeding one or more routing limitations, merge the first and second given routes.

18. The system as in claim 17, wherein the processor is further configured to: fine-tune the at least one of the one or more routes based on a history of manual changes to a given route.

19. The system as in claim 11, wherein, when clustering the plurality of passengers into a plurality of stations, the processor is further configured to: assign each passenger to at least one main station and at least one duel station; and wherein, when composing the one or more routes for the plurality of stations, the processor is further configured to: add for each passenger, one of an assigned main station and an assigned duel station to one route of the one or more routes.

20. The system as in claim 11, wherein the processor is further configured to: identify one or more stations which, if the one or more stations were removed from a composed route would reduce a number of rides according to a predefined outlier threshold; isolate the identified one or more stations from the one or more routes; and provide at least one alternative mode of transportation.

27