Public transportation services, such as railway systems (passenger trains), buses, electric tram car, etc., play a critical role in a city to transport large numbers of commuters. People rely on public transportation services to move around in cities and public transportation services are typically a major component in a city.
Public transportation services suffer from disruptions in their service, which affect the commuters, depending on their route of travel in the service. During a service disruption, many commuters are and will be affected and those commuters need to find alternative transport service to reach their destinations. Usually, when there is a service disruption for a train system, for example, a commuter may contact a taxi company using an application on the commuter's electronic device (e.g., mobile device) or by phone calling the taxi company. If the contacted taxi company does not have any taxis available at the time, the commuter needs to contact another taxi company to arrange a pick-up. The drawbacks associated with contacting a taxi company when a disruption occurs is that there is usually a long waiting time for finding an available taxi and waiting for the actual pick-up, and the taxi fare is much higher than that of a public transportation service. Therefore, using a taxi to travel when the public transportation experiences the disruption is very inconvenient to the commuters.
To reduce the taxi fare, there are taxi sharing systems proposed in e.g., “Taxi Calling and Sharing System based on Mobile Terminal”, Chinese Pat. No. CN202362930 and “Dynamic Taxi-Sharing System and Sharing Method Thereof”, U.S. Pat. No. 8,799,038. In these systems, each taxi company has its own taxi sharing system, which matches people who are going to a similar destination. However, the only people matched for the sharing service are those who contacted the same company (to use their sharing service). Those systems do not take into account arranging a taxi for people who are going to the same destination but used taxi sharing systems of other companies.
Accordingly, some drawbacks to these systems are that the matching system employed by each of the taxi companies only match people who request (e.g., through an application or a call) a service for that particular taxi company. As a result, the success rate of matching people who are going to a similar destination is relatively low. The systems also do not give priority to a commuter who did not previously get a match using another taxi company and is now re-trying with another company. These systems have a long waiting time for the people using it.
An objective of the present invention is to provide a system that, after a service disruption of a public transportation system, groups commuters heading to a same or similar destination into a taxi, while utilizing the taxi sharing services of many taxi companies, taking into account the priority of each commuter, to minimize the total travel time for commuters with higher priority.
There are existing technologies for services that are able to use taxis from multiple taxi companies, but these technologies do not address the aforementioned problems. Chinese Pat. No. CN202871082 describes a taxi sharing service agent, which provides only a common interface for commuters to request taxi sharing from a single taxi company. If the request failed at one taxi company, commuters can use the same interface to request taxi sharing from another taxi company. On the other hand, Japanese Pub. No. JP2004-164256 describes a Bus Service Center, which can receive a taxi calling request from a bus, and forward the request to a taxi company. If the request fails, the system (i.e., Bus Service Center) will resend the request to another taxi company. These existing technologies do not consider a priority of a commuter and the waiting time a commuter may be experiencing, and cannot choose optimum schedules from a plurality of taxi companies for commuters.
The system and method disclosed herein provides a taxi sharing bridge system, which uses taxis from a plurality of taxi companies (and their respective taxi sharing systems) to effectively dispatch commuters to their specific destinations. In one example, the taxi sharing bridge system pro-actively consolidates taxi sharing demand from commuters affected by a disruption into groups, and is able to dynamically update a commuter's priority based on their waiting time, travel behavior, and a priority policy. The system then generates a group request based on the priority and sends the request to all taxi companies, and selects the optimum schedules for each group to minimize the total travel time for commuters with high priority.
By using the taxi sharing bridge system, a commuter inconvenienced by a disruption in public transportation will automatically be queried by the system to determine if he or she need a taxi and then automatically have a taxi arranged to pick him or her and others up at a necessary pick-up point (e.g., train stations or nearby taxi stands) to be transported to their destination. The taxi sharing bridge system utilizes existing taxi sharing systems operated by a plurality of taxi companies to automatically select a taxi for the commuter based on parameters, such as priority of the commuter, waiting time, and loyalty.
In the following detailed description, numerous specific details are set forth in order to provide a thorough understanding of the present invention. However, it will be apparent to one of ordinary skill in the art that these specific details may not all be needed to practice the present invention. In other circumstances, well-known structures, materials, circuits, processes and interfaces have not been described in detail, and/or may be illustrated in block diagram form, so as to not unnecessarily obscure the present invention.
Furthermore, some portions of the following detailed description are presented in terms of algorithms or processes and symbolic representations of operations within a computer. These algorithmic descriptions and symbolic representations are the means used by those skilled in the data processing arts to most effectively convey the essence of their innovations to others skilled in the art. An algorithm or process is a series of defined steps leading to a desired end state or result. In the present invention, the steps carried out require physical manipulations of tangible quantities for achieving a tangible result. Usually, though not necessarily, these quantities take the form of electrical or magnetic signals or instructions capable of being stored, transferred, combined, compared, and otherwise manipulated. It has proven convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, instructions, or the like. It should be borne in mind, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. Unless specifically stated otherwise, as apparent from the following discussion, it is appreciated that throughout the description, discussions utilizing terms such as “processing,” “computing,” “calculating,” “determining,” “displaying,” “mining,” or the like, can include the actions and processes of a computer system or other information processing device that manipulates and transforms data represented as physical (electronic) quantities within the computer system's registers and memories into other data similarly represented as physical quantities within the computer system's memories or registers or other information storage, transmission or display devices.
Some implementations relate to an apparatus (one or more apparatuses) for performing the operations herein. The apparatus may be specially constructed for the required purposes, or it may include one or more general-purpose computers selectively activated or reconfigured by one or more computer programs. Such computer programs may be stored in a computer-readable storage medium, such as, but not limited to optical disks, magnetic disks, read-only memories, random access memories, solid state devices and drives, or any other types of media suitable for storing electronic information. The algorithms and displays presented herein are not inherently related to any particular computer or other apparatus. Various general-purpose systems may be used with programs and modules in accordance with the teachings herein, or it may prove convenient to construct a more specialized apparatus to perform desired method steps. The operations described in flowcharts, for example, may be executed by one or more processing devices, e.g., central processing units (CPUs), processors, or controllers.
Some of the figures are flow diagrams illustrating example processes according to some implementations. The processes are illustrated as collections of blocks in logical flow diagrams, which represent a sequence of operations, some or all of which can be implemented in hardware, software or a combination thereof. In the context of software, the blocks may represent computer-executable instructions stored on one or more computer-readable media that, when executed by one or more processors, program the processors to perform the recited operations. Generally, computer-executable instructions include routines, programs, objects, components, data structures and the like that perform particular functions or implement particular data types. The order in which the blocks are described should not be construed as a limitation. Any number of the described blocks can be combined in any order and/or in parallel to implement the process, or alternative processes, and not all of the blocks need be executed. For discussion purposes, the processes are described with reference to the environments, systems and devices described in the examples herein, although the processes may be implemented in a wide variety of other environments, systems and devices.
Although the data may be described as being stored in tables, the data may be stored in other appropriate data structures.
The present invention is illustrated and described with the following drawings.
Each client device 130 may be a smart phone, tablet, or the like, and may include a respective instance of an application 214 that executes on the respective client device 130 for interacting with the taxi sharing bridge system 110. In some examples, the client application 214 and the taxi sharing bridge system 110 may communicate with each other via one or more application programming interfaces (APIs). For instance, the application 214 on the client device 130 may present information in one or more graphic user interfaces (GUIs). The client device 130 may be a computing device that is configured to receive information via email, instant messaging, such as SMS, or other electronic communication. The client device 130 may also be a mobile device, configured to receive information from the taxi sharing bridge system 110 via an SMS text message, voicemail, telephone call, or the like. The components of the client device 130 are further explained with reference to
A commuter uses a client device 130 to connect to a taxi sharing bridge system 110 through one or more networks 140. One or more networks 140, 150, 161 may include any appropriate network, including a wide area network (WAN), internet, local area network (LAN), wireless networks, such as a cellular network, a local wireless network (e.g., Wi-Fi and/or close-range wireless communications). The one or more networks 140, 150, 161 may also include a wired network (consisting of fiber optics and Ethernet), or any combination thereof. Accordingly, the one or more networks 140, 150, 161 may include wired and/or wireless communication technologies, or any combination thereof. Protocols implemented by the client devices 130, taxi sharing bridge system 110, public transportation system 160, and taxi sharing systems 120 for communicating over networks 140, 150, and 161 are well known and will not be discussed herein in detail.
The taxi sharing bridge system 110, provides taxi sharing bridging service to commuters, by using taxis from a plurality of taxi sharing systems 120. The communication between the taxi sharing bridge system 110 and taxi sharing systems 120 is through one or more networks 150. In addition, the public transportation system 160 communicates with the taxi sharing bridge system 110 over one or more networks 161 to provide information (such as transit logs and disruption information) to the taxi sharing bridge system 110.
In the exemplary illustration of
The memory 212 and storage device(s) 220 are examples of computer-readable media 226. Such computer-readable media 226 may include volatile and non-volatile memory and/or removable and non-removable media implemented in any type of technology for storage of information such as computer-readable processor-executable instructions, data structures, program modules or other data. The computer-readable media 226 may include, but is not limited to, RAM, ROM, flash memory, solid-state storage, magnetic disk storage, optical storage, and/or other computer-readable media technology. Further, in some cases, the client device 130 may access external storage, such as RAID storage systems, storage arrays, network attached storage, storage area networks, cloud storage, or any other medium that can be used to store information and that can be accessed by the processor(s) 204 directly or through another computing device or network. Accordingly, the computer-readable media 226 may be computer storage media able to store instructions, modules, or components, which are executed by the processor(s) 204.
The computer-readable media 226 may be used to store any number of functional components that are executable by the processor(s) 204. In some implementations, these functional components comprise instructions or programs that are executable by the processor(s) 204 and that, when executed, implement operational logic for performing the actions and services attributed to the client device 130. Functional components of the client device 130 that may be stored in the memory 212 may include the application 214, which as discussed above communicates with the taxi sharing bridge system 110 and may present the user with one or more GUIs via a display 208 of the client device 130. Additional functional components may include an operating system 218 for controlling and managing various functions of the client device 130 and for enabling basic user interactions with the client device 130. The storage interface 222 may provide raw data storage and read/write access to the storage device(s) 220. The modules, application 214, and operating system 218 may access data in the storage device(s) 220 via the storage interface 222.
In addition, the computer-readable media 226 may also store data used by the functional components. Depending on the type of the client device 130, the computer-readable media 226 may also include other functional components and data, such as other modules, which may include applications, programs, drivers, etc., and the data used or generated by the functional components. Also stored on the computer-readable media 226 are a confirmation reception module 216, which includes instructions, independently or in combination with the application 214, for providing a GUI for displaying information and for allowing the user to confirm or deny the use of the service when prompted by the taxi sharing bridge system 110. For example, the configuration reception module 216 may handles reception of information from the taxi sharing bridge system 110 and sending of information to the taxi sharing bridge system 110.
The communication interface(s) 202 may include one or more interfaces and hardware components for enabling communication with various other devices, such as over the network(s) 140 or directly. For example, communication interface(s) 202 may enable communication through one or more of the Internet, cable networks, cellular networks, wireless networks (e.g., Wi-Fi) and wired networks (e.g., fiber optic and Ethernet), as well as close-range communications, and the like, as additionally enumerated elsewhere herein.
The client device 130 may also include the one or more I/O devices 206. The I/O devices 206 may include speakers, a microphone, a camera, and various user controls (e.g., buttons, a joystick, a keyboard, a keypad, etc.), a haptic output device, and so forth. Other components included in the client device 130 may include various types of sensors, which may include a global positioning satellite (GPS) receiver 210 able to indicate location information, as well as other sensors (not shown) such as an accelerometer, gyroscope, compass, proximity sensor, and the like. In some cases, the GPS receiver 210 may be used by the application 214 to determine a current geographic location of the client device 130 or a nearby public transportation station (e.g., train station or bus station). Additionally, or alternatively, the communication interface(s) 202 may be used to determine the current location of the client device 130, such as based on communication with nearby cell towers, wireless access points, and the like. Additionally, the client device 130 may include various other components (not shown) including removable storage, and a power source, such as a battery and power control unit, and so forth.
Although the application module 214 is shown in block form separate from the configuration reception module 216, the application module 214 may include the functionality of the configuration reception module 216. The illustrations of the modules provided herein are exemplary. The modules may be executed by the processor(s) 204 of the client device 130.
In the illustrated example of the taxi sharing bridge system 110 of
The memory 310 may be an example of computer-readable media 386 and may include volatile and nonvolatile memory and/or removable and non-removable media implemented in any type of technology for storage of information, such as computer-readable instructions, data structures, program modules, or other data. Such computer-readable media 386 may include, but is not limited to, RAM, ROM, flash memory, optical storage, solid state storage, magnetic disk storage, RAID storage systems, storage arrays, network attached storage, storage area networks, cloud storage, or any other medium that can be used to store the desired information and that can be accessed by a computing device.
The computer-readable media 386 may be used to store any number of functional components that are executable by the processors 304. In many implementations, these functional components comprise instructions or programs that are executable by the processors 304 and that, when executed, specifically configure the one or more processors 304 to perform the actions attributed to the taxi sharing bridge system 110. Functional components stored in the memory 310 may include, a registration module 312, a travel demand modeling module 314, a demand consolidation module 316, a priority policy configuration module 318, a priority update module 320, a taxi sharing group request generation module 322, a schedule consolidation module 324, a commuter assignment module 326, and a service disruption module 330. Additional functional components stored in the computer-readable media 386 may include an operating system 328 for controlling and managing various functions of the taxi sharing bridge system 110. Each of the modules may be executed by the one or more processors 304 of the taxis haring bridge system 110.
The database 350 may include volatile and nonvolatile memory and/or removable and non-removable media implemented in any type of technology for storage of information, such as computer-readable instructions, data structures, program modules, or other data. Such computer-readable media may include, but is not limited to, RAM, ROM, flash memory or other memory technology, optical storage, solid state storage, magnetic tape, magnetic disk storage, RAID storage systems, storage arrays, network attached storage, storage area networks, cloud storage, or any other medium that can be used to store the desired information and that can be accessed by a computing device. The storage interface 382 may provide raw data storage and read/write access to the database 350.
The database 350 includes, but is not limited to, a user information table 352, a master data table 354, a transit log table 356, a travel demand table 358, a service disruption table 360, a taxi sharing request table 362, a priority policy 364, and a service timetable 366. The modules will use the data stored in the database 350 and may update the data during execution, in combination with the processor(s) 304, which will be further described hereafter.
The taxi sharing bridge system 110 may also include or maintain other functional components and data not specifically shown in
The communication interface(s) 302 may include one or more interfaces and hardware components for enabling communication with various other devices, such as over the network(s) 140, 150, and 161. For example, communication interface(s) 302 may enable communication through one or more of the Internet, cable networks, cellular networks, wireless networks (e.g., Wi-Fi) and wired networks (e.g., fiber optic and Ethernet), as well as close-range communications, and the like, as additionally enumerated elsewhere herein.
The taxi sharing bridge system 110 may further be equipped with various input/output (I/O) devices 306. Such I/O devices 306 may include a display, various user interface controls (e.g., buttons, joystick, keyboard, mouse, touch screen, etc.), audio speakers, connection ports and so forth. The taxi sharing bridge system may also be equipped with a management terminal 308 for an administrator to access directly or indirectly the I/O devices 306 so the administrator can manipulate settings of the taxi sharing bridge system such as certain thresholds, which are described later in more detail.
A taxi sharing system 120 may include one or more servers or other types of computing devices that may be embodied in any number of ways. For instance, in the case of a server, the modules, other functional components, and data may be implemented on a single server, a cluster of servers, a server farm or data center, a cloud-hosted computing service, and so forth, although other computer architectures may additionally or alternatively be used. These components and data may alternatively be distributed across different computing devices and different locations in any manner. Consequently, the functions may be implemented by one or more service computing devices, with the various functionality described above distributed in various ways across the different computing devices. As mentioned above, multiple taxi sharing systems 120 may be located together or separately, and organized, for example, as virtual servers, server banks, and/or server farms. The described functionality may be provided by the servers of a single entity or enterprise, or may be provided by the servers and/or services of multiple different entities or enterprises.
In the illustrated example, each taxi sharing system 120 may include one or more processors 404, a memory 420, one or more communication interfaces 402, I/O device(s) 406, a storage interface 418, one or more storage devices 422, communication interface(s) 402 and a system bus 416. Each processor 404 may be a single processing unit or a number of processing units, and may include single or multiple computing units or multiple processing cores. The processor(s) 404 can be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuitries, and/or any devices that manipulate signals based on operational instructions. For instance, the processor(s) 404 may be one or more hardware processors and/or logic circuits of any suitable type specifically programmed or configured to execute the algorithms and processes described herein. The processor(s) 404 can be configured to fetch and execute computer-readable instructions stored in the computer-readable media 420, which can program the processor(s) 404 to perform the functions described herein. Data communicated among the processor(s) 404 and the other components may be transferred via the system bus 416 or other suitable connections.
The memory 420 and storage device(s) 422 are examples of computer-readable media 424. Such computer-readable media 424 may include volatile and nonvolatile memory and/or removable and non-removable media implemented in any type of technology for storage of information, such as computer-readable instructions, data structures, program modules, or other data. Such computer-readable media 422 may include, but is not limited to, RAM, ROM, flash memory or other memory technology, optical storage, solid state storage, magnetic tape, magnetic disk storage, RAID storage systems, storage arrays, network attached storage, storage area networks, cloud storage, or any other medium that can be used to store the desired information and that can be accessed by a computing device.
The computer-readable media 424 may be used to store any number of functional components that are executable by the processors 404. In many implementations, these functional components comprise instructions or programs that are executable by the processors 404 and that, when executed, specifically configure the one or more processors 404 to perform the actions attributed to the taxi sharing systems 120. Functional components stored in the computer-readable media 420 may include a schedule generation module 408, and a dispatch module 410. Additional functional components stored in the computer-readable media 420 may include an operating system 412 for controlling and managing various functions of the taxi sharing system 120. A taxi sharing system 120 may also include or maintain other functional components and data not specifically shown in
The communication interface(s) 402 may include one or more interfaces and hardware components for enabling communication with various other devices, such as over the network(s) 150. For example, communication interface(s) 402 may enable communication through one or more of the Internet, cable networks, cellular networks, wireless networks (e.g., Wi-Fi) and wired networks (e.g., fiber optic and Ethernet), and the like, as additionally enumerated elsewhere herein.
The taxi sharing system 120 may further be equipped with various input/output (I/O) devices 406. Such I/O devices 406 may include a display, various user interface controls (e.g., buttons, joystick, keyboard, mouse, touch screen, etc.), audio speakers, connection ports and so forth.
In general, commuters who use the public transportation service and who are registered with the taxi sharing bridge system use their client devices 130 to receive and send information with the taxi sharing bridge system 110. The taxi sharing bride system 110 manages registered commuters and their travel demand. The travel demand indicates the route the commuter typically takes to get from an origin station to a destination during a trip on a particular day, for example. A commuter may have more than one trips in a day depending on how often the commuter uses the public transportation system. A trip from an origin to a destination may have more than one route.
The data used to develop a commuter's travel demand is the transit logs of the commuter which are recorded in accordance with the commuter's transit card. Each commuter typically has a transit card that when used allows information such as time, date, and location of travel to be recorded. The card has a unique ID, which associates the commuter with the transit ID card. The taxi sharing bridge system 110 acquires the data and is able to generate a travel demand for reach commuter, which is explained below. When a travel disruption occurs, the travel demand information and the disruption information can be compared to determine whether a commuter is affected by the disruption. If the commuter is affected then a message is sent to the client device of the commuter to confirm whether the commuter would like to use the taxi sharing bridge system service to obtain a taxi for the commuter, which may involve grouping the commuter with other commuters to take one taxi. If the commuter decides to use the service, the client device communicates with the taxi sharing bridge system 110, using the client device application or otherwise, to confirm that the commuter would like to use the taxi sharing service.
Based on a priority policy, which is described below, the commuter is grouped with other commuters based on their origin, destination, and gender. The taxi sharing bridge system communicates with a plurality of taxi sharing systems to initiate the generation of a taxi sharing schedule by each taxi sharing system. The taxi sharing bridge sharing system then receives a taxi sharing schedule from each taxi sharing system and merges the schedule. Subsequently commuters are assigned to taxis and the commuters are informed of the assignment. In addition, assignment information is sent to respective taxi sharing systems so each taxi sharing system may dispatch their own taxis according to their protocol.
A phone number may be a unique number assigned to a client device 130 where a client application 214 is installed. In the alternative, another unique identification number could be used such as one assigned to an application 214 existing on the client device 130 for receiving and sending communications to and from the taxi sharing bridge system 110. The value of a gender 630 is either M (Male) or F (Female). A loyalty 640 is generated and dynamically updated by the system. For instance, a commuter may have higher loyalty if the commuter accepts to use the taxi sharing bridge service more often than other commuters, or if the commuter uses the public transportation service more often than other commuters.
In step 810, the taxi sharing bridge system 110 loads the transit logs within a predefined threshold (e.g., threshold_1) from a transit log table 356, which consists of all the transit logs recorded in accordance with each commuter's transit card. Threshold_1 is a time period, such as one day. In some cases, the predefined threshold may be chosen from one of a set of days, such as a weekday (i.e., Monday-Friday) or weekend (Saturday or Sunday).
Referring back to
In step 820, instead of estimating the public transportation service timetable, the actual timetable (i.e., schedule) of the public transportation service may be obtained from the public transportation system 160. The data of the actual timetable of the service may be obtained from the public transportation system 160 or from the public domain (such as the published schedule). The actual timetable may be stored in the service timetable 366.
After the service timetable is estimated (or obtained) in step 820, the process continues to determine the route taken for each trip of an individual commuter in step 830 within the threshold_1 time period. As mentioned, there may be one or more routes for a commuter to travel from an origin to a destination of a trip. The route may involve transferring to different lines, for example. The possible routes for using the public transportation system to travel from an origin station to a destination station are previously known and stored in a master data table 354. This information includes the service line of the route 1030.
For each trip taken by a commuter, the commuter's travel time is calculated using the data of the trip start time 950 and trip end time 960 from the transit log 356. The travel time is the duration of time from the trip start time 950 to the trip end time 960. In step 830, the origin 930 and destination 940 for the commuter's trip is compared with the master data table 354 and the route 1030 the commuter took during a trip is determined by comparing the calculated travel time with the travel time 1050 stored in the master data table 354. For example, if the calculated travel time for traveling from origin station x (Stn_x) to destination station y (Stn_y) is 30 minutes (or within a predetermined variance threshold, for example 2 minutes, to the travel time 1050), then it can be determined that the commuter travelled according to Route_1 of the routes 1030. From the master data table 354, the type 1040 of the route is also determined. Using the above example, the commuter took the route having the type 1040 “shortest path,” which corresponds to Route_1. As mentioned above, each trip for the commuter in step 830 is compared to determine which route the commuter took for the trip. At step 840, the system updates the commuter's travel demand table.
The date 1120 is week-based, from Monday to Sunday. The weekday may be known by comparing the date of the transit log with calendar information. For example on a Monday, the commuter having transit card ID 11112222 has a starting time 1130 between 7:10 am and 7:20 am. The preferred route type 1160 is determined based on the travel history of the commuter in a time period (for example, 6 months or 1 year). For instance, in the given time period, the taxi sharing bridge system 110 determines which route 1030, out of Route_1, Route_2, or Route_3, the commuter took most often. After processing the above, the travel demand table 358 is updated for the commuter.
When a disruption occurs on a public transportation service many commuters are affected. A disruption may prevent many commuters from using the public transportation service to travel from their origin station to the destination station. As a result, the commuters must find an alternative mean for transportation, such as a taxi. The following describes the processing for how the taxi sharing bridge system 110 communicates with the client devices 130, public transportation system 160, and taxi sharing systems 120 to send client devices 130 information indicating a taxi and the number of commuters assigned to each taxi so the taxi may take one or more of the commuters to their destination station or other location near the destination station.
When a disruption occurs in the public transportation system, the public transportation system 160 sends data indicating disruption information over the one or more networks 161 to the taxi sharing bridge system 110.
After the system 110 receives disruption information and stores the disruption information in the database 360, step 1310 is executed. Step 1310 initializes taxi sharing requests for commuters affected by the disruption, who are determined based on the disruption information. The processing of step 1310 is illustrated in
Then, for each of the commuters found in step 1410, the system searches the travel demand table 358 in step 1420 to determine if the commuter's travel route 1030 of the preferred travel route type 1160 is affected by the disruption. The system compares the service line 1220 information in the disruption information with the travel route 1030 of each commuter to determine whether the route 1030 includes the service line 1220 of the disruption information. If, the route includes the service line affected 1220, the system then compares the stations in the station list 1230 with the stations in the travel route 1030 to determine if the commuter is affected by the disruption. For example, if a station in the station list 1230 is a station along a route 1030, then the system may determine a commuter is affected.
If the commuter is affected by the disruption (yes in step 1420), then the system determines if the commuter is registered to use the taxi sharing bridge system by searching the user information table 352 for the transit card ID 610 of the affected commuter. If yes, in step 1430, the system then determines the station where the commuter will need a taxi in step 1440. For instance, the station where the commuter will need a taxi may be the first station in the commuter's preferred travel route that is affected by the disruption based on the stations list 1230 in the disruption information table. The system can compare the stations in the disruption information to the stations along the preferred route to determine which station is first affected.
The system then estimates the commuter's arriving time to the determined station based on the trip start time 1130 from the commuter's travel demand table. For instance the system determines, based on the estimated service timetable, when the commuter will arrive to the affected station.
In step 1450, the system generates a taxi sharing request for the commuter with corresponding information from user information table 352 and travel demand table 358, default priority, and status as “Initialization”. If no in Step 1420 or 1430, the system will skip the current commuter and check the next commuter of the commuters found in step 1410.
The waiting time 1580 is the time (in minutes) a commuter has been waiting at the origin station 1520. It may be noted that the value of a waiting time can be less than 0, if the current system time is before the commuter arriving time 1530. A priority 1590 has default value as “0”, and may be updated to a higher value by the system (e.g., within priority update module 320), which will be further explained hereafter. The value of a status 1592 may be “Initialization”, “Accepted”, “Rejected”, “Assigned”, and “Retry”.
Referring back to
The taxi sharing initiation request is sent to the client device 130 of the commuter over the one or more networks 140. The request may be in the form of an SMS, email, call, application notification, or any other notification. The taxi sharing initiation request may be displayed as a guided user interface (GUI) on the client device 130. The contents of the request consists of, but is not limited to, the destination 1540, the origin station 1520, and a request for the commuter receiving the taxi sharing initiation request to accept or reject the use of a taxi sharing service via their client device. The request may be a text field, button field or the like. The response to the request from the commuter is sent to the taxi sharing bridge system, and step 1340 determines whether the response is acceptance (yes in step 1340) or rejection (no in step 1340).
If a commuter accepts to use the taxi sharing service from the origin 1520, in step 1350, the taxi sharing request status will be changed to “Accepted”. When, in step 1340, a commuter decides to use the taxi sharing bridge system, the instance is recorded in a table in the database 350 along with the date the commuter used the system. If a commuter does not accept to use taxi sharing service, then in step 1360, the taxi sharing request status 1592 will be changed to “Rejected.”
Once the system 110 has determined which commuters accept using a taxi sharing service, the priority 1590 in the taxi sharing request table for those commuters is determined.
For instance, a commuter with a longer waiting time 1580 at a station can have a higher priority than another commuter with a shorter waiting time 1580. In another instance, priority value 1590 may be calculated based on the preferred route type 1560 of a commuter. If a commuter prefers a “shortest path” route type, it may indicate that travel time is more critical for the commuter. Whereas, if a commuter prefers “less transfer” route type, it may indicate that the commuter is looking for a more comfortable service even if the travel time is longer. Therefore, a commuter whose preferred route type is “shortest path” can have a higher priority than another commuter whose preferred route type is “less transfer”. Similarly, a higher priority may be set for commuters with higher loyalty, to reward the commuters who often take public transportation service or who often use the taxi sharing bridge system. On the other hand, higher priority may be set for commuters with lower loyalty, if the service operator wants to promote public transport service to those commuters who do not often take public transport service, for example.
According to the exemplary priority policy of
In step 1708 if the waiting time is not greater than 10 minutes (no in step 1706) then the preferred route type 1560 of the commuter is considered. In step 1708 if the preferred route type 1560 is “shortest path” (yes in step 1708), then the loyalty 1570 of the commuter is considered in step 1714. If the loyalty 1570 of the commuter is “high” then the priority 1590 is set to 8 in step 1718. If the loyalty 1570 is not “high” (no in step 1714), then the priority 1590 is set to 7 in step 1716. If in step 1708 the preferred route type 1560 is not “shortest path” (no in step 1708), then the loyalty 1570 of the commuter is considered in step 1712. If the loyalty 1570 of the commuter is “high” (yes in step 1712), then the priority 1590 is set to 6 in step 1722. If the loyalty 1570 is not “high” (no in step 1712), then the priority 1590 is set to 5 in step 1720.
In step 1702, if the evaluation of the waiting time 1580 of a commuter is not greater than 5 minutes (no in step 1702), then the preferred route type 1560 of the commuter is considered in step 1704. In step 1704 if the preferred route type 1560 is “shortest path” (yes in step 1704), then the loyalty 1570 of the commuter is considered in step 1726. If in step 1726 the loyalty 1570 of the commuter is “high” (yes in step 1726), then the priority 1590 is set to 4 in step 1734. On the other hand, if the loyalty 1570 of the commuter is not “high” (no in step 1726), then the priority 1590 is set to 3 in step 1732.
If in step 1704 the preferred route type 1560 is not “shortest path” (no in step 1704), then the loyalty 1570 of the commuter is considered in step 1724. In step 1724, if the loyalty 1570 is “high” (yes in step 1724), then the priority 1590 is set to 2 in step 1730. If, in step 1724 the loyalty 1570 is not “high” (no in step 1724), then the priority 1590 of the commuter is set to 1 in step 1728.
In step 1810, sharing groups are created based on all taxi sharing requests, stored in taxi sharing request table 362, with a status of “Accepted” or “Retry.” The taxi sharing requests are grouped based on origin 1520, destination 1540, gender 1550, and priority 1590. In step 1810, the requests are grouped by origin 1520, followed by destination 1540, gender 1550, and priority 1590. In addition, a group ID 1950 is an ID assigned to each sharing group. In step 1820, the system sorts the requests in each group by the commuter waiting times 1580.
Referring back to
As mentioned above, each taxi sharing system is a system that communicates with many taxis. Taxi sharing systems are well known in the art and therefore the details of a taxi sharing system will not be explained here.
Each taxi sharing system 120 receives a taxi sharing group request. In step 2110, for each priority group in a taxi sharing group request, a sufficient number of taxis for the number of commuters 2060 in the group are determined. Each taxi sharing system 120 may use different methods that can be found in existing arts to choose their taxis. For instance, if a group has 50 commuters (number of commuters 2060), then the taxi sharing system will arrange as many taxis as possible for 50 commuters (for example, 13 taxis, if each taxi can take 4 commuters). It may be noted that a taxi sharing system 120 should arrange as many taxis as possible to serve the number of commuters 2060 in a priority group with higher priority, before arranging taxis for groups with lower priority. For each group (Group ID 2050), individual taxis are arranged that each have a passenger capacity. The taxi sharing system manages the pickup location of each taxi and the estimated arrival time of each taxi. In step 2120, each taxi sharing system generates a schedule with the chosen taxis for the taxi sharing group request, which includes the above information.
Referring back to
The schedule consolidation process is executed after the taxi sharing bridge system 110 sends a taxi sharing group request in step 1850 to each of the taxi sharing systems 120. In step 2310, the system 110 receives a schedule from each taxi sharing system 120 that received a taxi sharing group request. In step 2320, the system merges schedules from all the taxi sharing systems 120 for each sharing group and sorts the merged schedules by taxi arriving time 2460.
The system 110 assigns each taxi sharing system an identifier, such as taxi sharing system ID 2420. As mentioned above, each taxi sharing system 120 replies with the taxis 2430 arranged for each group 2410. The system in step 2320 considers all of the taxis from each of the taxi sharing systems 120 in each group and selects, in order of the taxis having the shortest taxi arriving time 2250, the taxis that will be assigned to that group based on the number of commuters 2060 in the group and the cumulative capacity of the taxis. For example, if the number of commuters 2060 in the group is 50, then the system 110 selects a number of taxis so that the sum of the capacity 2230 of the taxis in the group is greater than or equal to the number of commuters 2060 in the group. Each taxi is chosen, among the taxis arranged in all of the taxi sharing systems 120, based on the taxi arriving time. The taxi having the shortest taxi arriving time for a group is selected as the next taxi in the merged schedule.
The number of commuters in each group may change (in the sharing groups of
For a group, set as the current group, the commuters are sorted according to their waiting time 1970. Step 2604 determines whether there are commuters that still need to be assigned to a taxi but have not been assigned in the current group. If yes in step 2604, then step 2606 determines whether, in the current taxi, the capacity has been reached for that taxi. The current taxi is a taxi in the merged schedule selected for the group having the same group ID 2410 as the current group. The capacity for a taxi is determined based on the capacity 2440. If the capacity of the current taxi has not been reached (no in step 2606), then the system assigns the commuter to the current taxi in step 2608. Processing returns to step 2604 to determine whether another commuter exists in the current group.
If the capacity of the current taxi has been reached (yes in step 2606), then step 2610 determines whether there is another taxi in the merged schedule. The next taxi may come from the schedule for lower priority groups (in priority sequence), if they have same origin 1910, destination 1920, and gender 1930. If no in step 2610, then the processing ends for the current group. If yes, in step 2610, then the next taxi from the merged schedule is set as the current taxi in step 2612 and the commuter is assigned to this taxi.
In step 2604, if all commuters have been assigned in the current group (no in step 2604), then step 2614 determines whether there is a lower priority group. If there is not a lower priority group (no in step 2614), then the processing ends. If there is a lower priority group (yes in step 2614), then the lower priority group is set as the current group in step 2616 and processing continues to step 2602. The process repeats from 2604 to assign taxis for the commuters in the lower group.
Referring back to
In Step 2550, the system changes the commuter's status 1592 to “Assigned” in the taxi sharing request table 362. If the commuter is not assigned to a taxi (no in step 2530), in step 2560, the system updates the commuter's waiting time 1580 based on the current time. In step 2570, the system changes the commuter's status 1592 to “Retry”, and updates the priority 1590 according to the priority policy. As a result, the commuter's taxi sharing request will be included in the new sharing groups by taxi sharing group request generation module 322 (processing of
Referring to
Various instructions, methods, and techniques described herein may be considered in the general context of computer-executable instructions, such as program modules stored on computer-readable media, and executed by the processor(s) herein. Generally, program modules include routines, programs, objects, components, data structures, etc., for performing particular tasks or implementing particular abstract data types. These program modules, and the like, may be executed as native code or may be downloaded and executed, such as in a virtual machine or other just-in-time compilation execution environment. Typically, the functionality of the program modules may be combined or distributed as desired in various implementations. An implementation of these modules and techniques may be stored on computer storage media or transmitted across some form of communication media.
While given components of the system have been described separately, one of ordinary skill will appreciate that some of the functions may be combined or shared in given instructions, program sequences, code portions, and the like.