WO2023042095A1

WO2023042095A1 - Transportation management system and method

Info

Publication number: WO2023042095A1
Application number: PCT/IB2022/058668
Authority: WO
Inventors: Thabiso Cyrus MOLOKO
Original assignee: Moloko Thabiso Cyrus
Priority date: 2021-09-14
Filing date: 2022-09-14
Publication date: 2023-03-23

Abstract

A transportation management system (10) and a method (100) for creating a link between commuters and transport service providers. The method comprises receiving (102), on a backend (14), from a first entity (12), a first dataset relating to a first and second location (44, 46). At least one potential operator (22) is identified from a database of operators (20). An operator is identified as a potential operator when a route (36) associated with the operator coincides with a departure zone (48) associated with the first location. The departure zone (48) is calculated in accordance with a predetermined rule, and a departure location (52) associated with the potential operator is defined at a location where the route and the departure zone coincides. Data pertaining to the potential operator and the departure location associated with said at least one potential operator, is communicated to the first entity.

Description

TRANSPORTATION MANAGEMENT SYSTEM AND METHOD

BACKGROUND TO THE INVENTION

This invention relates to a transportation management system and method, and in particular to a system for creating a link between commuters and transport service providers.

Public transportation takes many forms, such as trains, buses, taxis and the like. Trains operate between stations and according to planned schedules.

In many cases, buses travel on predetermined routes, and according to planned schedules. However, prevailing traffic conditions may impact on a bus’s schedule.

Furthermore, persons not familiar with a specific area’s bus routes and schedules often find it difficult to get around and have to resort to more expensive forms of transportation.

Recently, developments in the field of taxi management systems, have resulted in increased use of taxi services. Known systems enable a commuter to request transportation to a specific destination, whereafter a taxi operator in the vicinity of the commuter is informed of the request. The taxi operator can respond to the commuter’s request and may proceed to pick the commuter up from a predetermined location. Such systems also provide for calculating the cost associated with the commute, and for facilitating electronic receipt of payment from the commuter, before the commuter is picked up.

Despite the convenience associated with systems of this type, these systems are generally known to be expensive, and more expensive than other forms of public transport, such as buses or trains. These systems generally do not pose affordable solutions for daily commuters, or for medium to longer distance commuting. Such systems furthermore are not capable of catering for peak-time commuter traffic.

Especially in developing countries, taxis often have predetermined routes and schedules, albeit more informal than the routes and schedules of buses. These are often established informally or based on agreements with associations. Furthermore, the taxis often take the form of minibuses, and are used for transporting larger numbers of persons between locations. Such minibuses typically have capacity to carry up to 16 passengers, and peak-time commuter traffic is, at least to a degree, catered for.

Like a bus, the minibus taxis carry various unrelated persons who may all join and leave the minibus taxi at different locations along the route. Since various persons are carried by the minibus taxi, it is usually not feasible to drop each commuter off at a specific desired destination. In some cases, a person may have to take two or more taxis to arrive at a desired destination or might have to walk or make use of further transportation means to arrive at the desired destination. This is an inconvenient, costly and time-consuming process.

In some cases, the commuters and operators of the minibus taxis communicate details of a destination via a signalling system, which is not known to persons form outside the specific area.

Also, it is sometimes difficult to determine when a suitable taxi heading in the correct direction or to the correct destination, will arrive at a point from which a commuter wishes to travel. Also, it is impossible to determine beforehand whether a minibus taxi will have capacity to carry all the commuters in need of transportation from a specific location.

Due to the dynamic nature of passengers joining and leaving the minibus taxi, the collection of fares (typically in the form of cash) is usually handled on behalf of the operator of the minibus taxi, typically by one of the passengers. This could potentially lead to incorrect fares charged to certain passengers, to the operator not receiving the correct amount of fares and the like. Problems also occur with providing correct change.

It is accordingly an object of the invention to provide a transport management system, a method for facilitating a transportation service to a first entity and a method for facilitating a transportation service to a plurality of first entities that will, at least partially, address the above disadvantages.

It is also an object of the invention to provide transport management system, a method for facilitating a transportation service to a first entity and a method for facilitating a transportation service to a plurality of first entities which will be a useful alternative to existing transport management systems. SUMMARY OF THE INVENTION

In accordance with a first aspect of the invention there is provided a method for facilitating a transportation service to a first entity, the method comprising the steps of: receiving, on a backend, from the first entity, a first dataset relating to a first location and a second location; identifying at least one potential operator from a database of operators, wherein an operator is identified as a potential operator when a route associated with the operator coincides with a departure zone associated with the first location, which departure zone is calculated in accordance with a predetermined rule, and wherein a departure location associated with the potential operator is defined at a location where the route and the departure zone coincides; and communicating data pertaining to the at least one potential operator and the departure location associated with said at least one potential operator, to the first entity.

An operator may additionally be identified as a potential operator when the route associated with the operator furthermore coincides with an arrival zone associated with the second location, which arrival zone is calculated in accordance with a second predetermined rule, and wherein an arrival location associated with the potential operator is defined at a location where the route and the arrival zone coincides.

The method therefore includes the steps of calculating the departure zone and arrival zone.

The departure zone may be an area surrounding the first location and having a boundary or periphery defined by the predetermined rule. The predetermined rule in accordance with which the departure zone is calculated may limit a distance between the boundary or periphery of the departure zone and the first location, to within a predetermined distance.

The predetermined distance may be determined by taking into account the time required for the first entity to reach the boundary or periphery of the departure zone from the first location.

The method may furthermore comprise the step of calculating the time required for each operator to reach the departure location associated with said operator.

The step of calculating the time required for each operator to reach the departure location associated with said operator may take into account prevailing traffic conditions. The method may include receiving on the backend, data pertaining to prevailing traffic conditions.

An operator may additionally be identified as a potential operator when the time required to reach the departure location associated with said operator, falls within a predetermined timeframe.

The predetermined timeframe may take into account a time required for the first entity to reach the departure location associated with said operator. The predetermined timeframe may be limited by a permissible waiting time.

The method may include receiving from the first entity a desired time of departure and calculating the predetermined timeframe in accordance with the desired time of departure.

The arrival zone may be an area surrounding the second location and having a boundary or periphery defined by the second predetermined rule. The predetermined rule in accordance with which the arrival zone is calculated may limit a distance between the boundary or periphery of the arrival zone and the second location, to within a predetermined distance.

The predetermined distance may be determined by taking into account the time required for the first entity to reach the second location from the boundary or periphery of the arrival zone.

The method may furthermore comprise the step of calculating the time required for each operator to reach the arrival location associated with said operator.

The step of calculating the time required for each operator to reach the arrival location associated with said operator may take into account prevailing traffic conditions.

An operator may additionally be identified as a potential operator when the time required to reach the arrival location associated with said operator, falls within a predetermined timeframe.

The predetermined timeframe may take into account a length of the route associated with said operator, the length of the route between the departure and arrival locations, and prevailing traffic conditions along said route. The method may include receiving from the first entity a desired time of arrival at the second location. The predetermined timeframe may be adjusted in accordance with the desired time of arrival.

The method may include receiving from an operator an indication of the availability of space associated with the operator.

A potential operator may furthermore be identified when the indication of the availability of space satisfies a predetermined requirement.

The method may furthermore include the step of compiling a list of more than one potential operator, wherein each potential operator may be associated with a separate departure location and arrival location.

The potential operators on the list may be ordered in accordance with a rule of relevance.

The list may be communicated to the first entity.

The first dataset may include an indication of a current time, a desired time of departure, and/or a desired time of arrival.

The method may furthermore include the step of receiving on the backend, from each of a plurality of operators, an operator dataset including at least some of data pertaining to a destination, data pertaining to a route, time data, and data pertaining to the availability of space, and storing the data from each operator dataset in the database of operators.

The method may include the step of receiving operator datasets in real time and updating the database of operators in real time with data from the operator datasets received in real time.

The method may include determining a cost associated with the transportation of the first entity between the first and second locations and communicating said cost to the first entity.

The method may include receiving as an input from the first entity, a selection by the first entity of an acceptable operator. The selection by the first entity may be communicated to the identified acceptable operator. Data pertaining to the departure location may be communicated to the identified second entity. The acceptance may be used to adapt the database of operators, including the availability of space associated with said potential operator. The method may provide for the receiving of funds in accordance with the determined cost and allocation of at least a portion of said received funds to the identified second entity.

The method may furthermore comprise receiving an acceptance by the identified second entity and communicating said acceptance to the first entity.

The method may include the step of alerting the operator in real time of the proximity of the departure location.

The method may include the step of alerting the operator in real time of the proximity of the arrival location.

The route associated with the operator may be a route that the operator has already set off on.

Alternatively, the route associated with the operator may be a planned route, indicated by the operator.

In accordance with a second aspect of the invention, there is provided a method of facilitating a transportation service to a plurality of first entities, the method comprising the steps of: receiving on a backend, from an operator an operator dataset including data pertaining to a planned route; receiving as input, in accordance with the first aspect of the invention, from each of a plurality of first entities, a selection of the operator as an acceptable operator; once a number of inputs received from said plurality of first entities reaches a predetermined number, providing an instruction to said operator to set-off on the planned route; and communicating data to the operator pertaining to a number of predetermined departure locations, each first entity associated with a specific departure location.

In accordance with a third aspect of the invention there is provided a system for providing a transportation service to a first entity by using the method according to the first aspect of the invention, the system comprising: a backend comprising a processing module and a memory arrangement, the memory arrangement having stored thereon a database of operators; a plurality of operator input modules, each operator input module associated with a specific operator, the plurality of operator input modules for capturing operator datasets in real time and transmitting same to the backend; a plurality of commuter input modules for receiving first datasets from a plurality of commuters onto the backend.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention will now be described in more detail, by way of example only, with reference to the accompanying drawings in which:

Figure 1 shows a schematic view of an example where a system according to the invention is used to facilitate a transportation service to a first entity, by following a method according to the invention;

Figure 2 shows a schematic view of the system used in the example of figure 1 ; and

Figure 3 shows a flow diagram setting out steps of the method used in the example of figure 1.

DESCRIPTION OF THE ILLUSTRATED EMBODIMENTS

Before any embodiments of the invention are explained in detail, it is to be understood that the invention is not limited in its application to the details of construction and the arrangement of components set forth in the following description or illustrated in the following drawings. The invention is capable of other embodiments and of being practiced or of being carried out in various ways. Also, it is to be understood that the phraseology and terminology used herein is for the purpose of description and should not be regarded as limiting. The use of "including," "comprising," or "having" and variations thereof herein is meant to encompass the items listed thereafter and equivalents thereof as well as additional items. Unless specified or limited otherwise, the terms "mounted", "connected", "engaged" and variations thereof are used broadly and encompass both direct and indirect mountings, connections, supports, and couplings and are thus intended to include direct connections between two members without any other members interposed therebetween and indirect connections between members in which one or more other members are interposed therebetween. Further, "connected" and "engaged" are not restricted to physical or mechanical connections or couplings. Additionally, the words "lower", "upper", "upward", "down" and "downward" designate directions in the drawings to which reference is made. The terminology includes the words specifically mentioned above, derivatives thereof, and words or similar import. It is noted that, as used in this specification and the appended claims, the singular forms "a," "an," and "the," and any singular use of any word, include plural referents unless expressly and unequivocally limited to one referent. As used herein, the term “include” and its grammatical variants are intended to be non-limiting, such that recitation of items in a list is not to the exclusion of other like items that can be substituted or added to the listed items.

Referring to the drawings, in which like numerals indicate like features, a non-limiting example of a system for providing a transportation service to a first entity 12, in accordance with the invention, is generally indicated by reference numeral 10.

The system 10 comprises a backend 14, having a memory arrangement 16 and a processing module 18.

A database of operators 20 is stored on the memory arrangement 16.

In general, a plurality of operators 22 (such as a first operator 22.1 , a second operator 22.2 and a third operator 22.3) is associated with the system 10. The operators 22 are all registered with the system 10 in known fashion. Each operator 22 registered with the system 10 is associated with an operator dataset or data bundle 24 (such as a first operator dataset 24.1 , associated with the first operator 22.1 , and so on).

Each operator dataset 24 comprises of administrative data 26 and real-time data 28.

The administrative data 26 includes, amongst others, data relating to: the identity of the operator 22; a type of vehicle 30 associated with the operator 22; a carrying capacity of the vehicle 30; historic data associated with the operator 22 (including commuting trends, ratings and the like); and financial information such as banking details of the operator.

The real-time data 28 includes, amongst others, data relating to: a current location 32 of the operator 22 (geolocation data); a planned destination 34 to which the operator 22 is heading; a planned route 36 along which the operator 22 will travel between the current location 32 and the planned destination 34; a current number of passengers; arrival and departure locations of all passengers; and estimated times of arrival of the operator 22 at the various arrival and departure locations associated with the passengers.

As will be described in more detail below, the real time data 28 is supplemented and updated in real-time, through the operation of the system 10 in accordance with the methods outlined herein.

The system 10 furthermore comprises a plurality of operator input modules 38. It will be appreciated that each operator 22 associated with the system 10 is associated with a separate operator input module 38. The operator input module 38 facilitates communication between the backend 14 and the operator 22. One expression of this would be the supplementation or updating of real-time data 28 in real time, as aforementioned. The operator input module 38 is of the known kind, and has means of capturing operator data, such as geolocation data and data manually captured on the operator input module 38 by the operator 22. The operator input module 38 typically takes the form of a smart device such as a smart phone, tablet computer, or the like. A processing module (not shown) associated with the operator input module 38 may execute an application or program stored on a memory arrangement (not shown) associated with the operator input module 38, during communication with the backend 14. Communication between the operator input module 38 and the backend 14 occurs in known fashion. Operator data sets or bundles may therefore be communicated between the operator input module 38 and the backend 14. A distinction should be made between data sets stored on the backend, and data sets or bundles received from the input modules.

The system 10 furthermore comprises a plurality of commuter input modules 42, associated with a plurality of commuters 40, all of which are registered as users of the system 10. The first entity 12, is one such a commuter 40 and therefore registered user of the system 10.

Each user input module 42 facilitates communication between the backend 14 and the commuter 40. The commuter input module 42 is of the known kind, and has means of capturing commuter data, such as geolocation data and data manually captured on the commuter input module 42 by the commuter 40. The commuter input module 42 typically takes the form of a smart device such as a smart phone, tablet computer, or the like. A processing module (not shown) associated with the commuter input module 42 may execute an application or program stored on a memory arrangement (not shown) associated with the commuter input module 42, during communication with the backend 14. Communication between the commuter input module 42 and the backend 14 occurs in known fashion. First data bundles or sets may therefore be communicated between the commuter input module 42 and the backend 14.

Other features of the system 10 will become apparent from what follows.

The system 10 is used for facilitating a method for facilitating a transportation service to the first entity 12. The method is schematically indicated by reference numeral 100 and shown in figure 3.

The method is initiated by the first entity 12, capturing on the commuter input module 42 associated with it, a first dataset (shown at 102), which relates to a first location 44 and a second location 46.

The first location 44 may typically be a current location or geolocation data of the first entity 12 and may be determined by an on-board GPS module associated with the commuter input module 42. Alternatively, the first entity may manually capture a first location 44 by capturing a physical address. The second location 46 typically relates to a destination where the first entity 12 is heading. The second location may typically be a physical address and may be manually captured by the first entity 12 on the commuter input module 42.

The first dataset is transmitted (shown at 104) to the backend 14 via the known communication medium and received (shown at 106) on the backend 14.

The backend 14 utilises the first dataset to calculate a departure zone 48 (shown at 108) which is associated with the first location 44 and to calculate an arrival zone 50 (shown at 1 10) which is associated with the second location 46.

The departure zone 48 is calculated according to a first predetermined rule and the arrival zone 50 is calculated according to a second predetermined rule (which calculations in accordance with the first and second predetermined rules are discussed in more detail below).

The processing module 18 identifies (shown at 112) at least one, but sometimes more than one potential operator 22 from the database of operators 20. An operator 22 is identified as a potential operator, when the route 36 associated with the operator 22 (which route is stored as part of the real-time data 28 associated with the operator 22) coincides with the departure zone 48.

Furthermore, for an operator 22 to be identified as a potential operator, the route 36 associated with said operator 22 must also coincide with the arrival zone 50.

The backend 14 next identifies (shown at 1 14) or determines a departure location 52 associated with each identified potential operator. The departure location 52 falls on the route 36 associated with the operator 22 and within the departure zone 48 associated with the first location 44.

The backend 14 also identifies (shown at 114) or determines an arrival location 54 associated with each identified potential operator. The arrival location 54 falls on the route 36 associated with the operator 22 and within the arrival zone 50 associated with the second location 46.

The backend 14 performs further backend calculations (shown at 1 16). This includes data relating to estimated times of arrival of each identified potential operator at the departure location 52 and arrival location 54 associated with said operator 22, estimated times for the first entity to reach the departure location 52 associated with each identified potential operator, the availability of space on each vehicle 30 associated with each operator 22, a cost involved in the commute, and the like.

Based on the further calculations mentioned above, all of the identified potential operators (in cases where more than one potential operator is identified) are compiled (shown at 120) onto a list. The identified potential operators on said list are sorted (shown at 122) in accordance with a rule of relevance, which is discussed more fully below.

Data pertaining to the identified potential operators, the departure locations 52, arrival locations 54 and the additional calculations is transmitted (shown at 124) to the first entity 12.

The first entity 12 now analyses (shown at 126) the data received from the backend 14, in order to select a suitable operator 22 from the list of potential operators.

The selection by the first entity 12 is transmitted (shown at 128) to the backend and relayed to the relevant operator 22 selected by the first entity 22. The real-time data of the relevant selected operator 22 is adjusted (shown at 130) by the selection of the first entity 12. This includes adapting the data relating to the occupants associated with the relevant operator 22, adding the departure location 52 and arrival location 54 to the route 36 of the operator 22, and the like.

The method may cater for the receiving of payment from the first entity 12, in accordance with the cost calculated as mentioned above. The payment may be made when the selection by the first entity 12 is transmitted to the backend 14 (at 128), or when the first entity 12 boards the vehicle 30 associated with the operator 22. Payment may be facilitated in known fashion. The departure zone 48 takes the form of an area surrounding the first location 44. A boundary or periphery of the departure zone 48 is defined or determined in accordance with the predetermined rule. Typically, the predetermined rule takes into account the time and effort required of the first entity 12, to reach the periphery of the departure zone 48 from the first location 44. For example, the predetermined rule may limit the departure zone 48 to an area which can be reached by walking from the first location 44, within a specific time.

Alternatively, the departure zone 48 may have a predetermined radius.

As mentioned, the calculations taking place on the backend 14 as aforementioned, include determining the time at which the operators will reach the respective departure locations 52. Similarly, the time it will take the first entity 12 to reach the departure locations 52 may be estimated. It follows that operators 22 that would otherwise qualify as potential operators, may be disqualified as such if their arrival time at the departure location 52 would be earlier than the arrival time of the first entity 12 at the departure location 52, or if the first entity would have to wait at the departure location 52 for too long. Therefore, an operator 22 will only be identified as a potential operator, if the arrival time of the operator 22 at the departure area or location 52 associated with that operator 22 would fall within a predetermined timeframe.

The calculation of the arrival times of the operators 22 may take into account prevailing traffic conditions. Data relating to prevailing traffic conditions may be received on the backend 14 from third party service providers.

The method may further provide for the first entity 12 to indicate a desired time of departure, in which case, the time of departure is used in the calculation of the predetermined timeframe.

As mentioned, the arrival zone 50 is typically calculated in accordance with the second predetermined rule. The arrival zone 50 takes the form of an area surrounding the second location 46. Typically, the second predetermined rule takes into account the time and effort required of the first entity 12, to reach the second location 46 from the periphery of the arrival zone 50 (since the first entity 12 may, theoretically alight from the vehicle 30 on the periphery of the arrival zone 50 and will have to make its way to the second location 46 thereafter).

The predetermined rule may limit the arrival zone 50 to an area from which the second location 46 can be reached by walking, within a specific time.

Alternatively, the arrival zone 50 may have a predetermined radius.

Since the planned routes 36 of the operators are known from the real-time data 28, the time required to reach the arrival location 54 may be determined by the backend (again taking into account prevailing traffic conditions). Operators 22 that would otherwise qualify as potential operators, may be disqualified as such if their arrival time at the arrival location 54 would fall outside of a required or predetermined timeframe. For instance, the first entity 12 may provide a desired time of arrival at the second location 46, which may be used to determine whether a specific operator 22 would be able to qualify as a potential operator.

The departure location 52 and arrival location 54 may be selected at specific known locations, such as bus stops, taxi ranks and the like.

After the first entity 12 has selected a suitable operator and the selection has been communicated to the operator, the departure location 52 and arrival location 54 may be communicated to the operator 22. The operator 22 may be alerted in real time as it approaches the departure location 52 or the arrival location 54.

The use of the system in accordance with the method will now further be described by way of an example, with reference to figure 1 .

Here, the first to fourth operators (22.1 , 22.2, 22.3 and 22.4) are all registered operators of the system 10. The first to fourth vehicles (30.1 , 30.2, 30.3 and 30.4) associated with the first to fourth operators (22.1 , 22.2, 22.3 and 22.4) are minibus taxis, having a carrying capacity of 15 persons per minibus taxi. The minibus taxis are used to provide transportation services. The first entity 12 is a person making use of transportation services such as that offered by the first to third operators (22.1 , 22.2 and 22.3) to commute between work and home.

Figure 1 shows a scenario at a specific time, TO. At the time TO, the first and third operators (22.1 , 22.3) are en route towards their respective destinations (34.1 , 34.3). The first and third operators (22.1 , 22.3) had previously entered their respective destinations (34.1 , 34.3) into their respective operator input modules 42, and indicated that they will be taking specific routes (36.1 , 36.3) to reach their respective destinations (34.1 , 34.3). This has all been stored in the real-time data (28.1 , 28.3) associated with the first and third operators (22.1 , 22.3).

At TO, the second operator 22.2 has not yet set of on its planned route 36.2, but has indicated that it plans to do so in the near future, at a time T1. The second operator’s destination 34.2, route 36.2 and time data are stored as part of the real-time data 28.2 associated with the second operator 22.2.

The fourth operator 22.4 is currently parked at a specific location and has not yet logged onto the system 10, nor has he indicated a planned route. No real-time data is stored in respect of the fourth operator 22.4.

At the time TO, the first entity 12 is ready to commute to work. The first entity 12 captures the location of its work as a second location 46 on its commuter input module 42. The commuter input module 42 furthermore captures the geolocation data of the first entity 12 at TO (by using an on-board GPS) and captures said geolocation data as the first location 44.

The data relating to the first and second locations (44, 46) is transmitted to the backend 14 as the first dataset.

The backend now calculates the departure zone 48 and arrival zone 50 associated with the first and second locations (44, 46) in accordance with the first and second predetermined rules. In this instance, the first and second rules requires the first and second locations (44, 46) to be no further than 1 km from the first and second locations (44, 46).

The first entity 12 furthermore indicates that it is ready to leave its house without further delay. The backend calculates that the first entity would be able to reach any departure location 52 within the departure zone 48, at a time T2. If the first entity 12 had indicated that it would only be able to leave its house after a specified time, T2 would be adjusted accordingly. The backend 14 now sets out to identify potential operators. Even though the third operator’s route 36.3 passes in close proximity to the second location 46, the route 36.3 does not pass through the departure zone 48, and therefore, the third operator 22.3 is not identified as a potential operator.

Since both the first and second operators’ (22.1 , 22.2) routes pass through the departure zone 48 and the arrival zone 50, both are initially identified as potential operators.

The backend 14 identifies departure locations (52.1 , 52.2) on the respective routes (36.1 , 36.2) of the first and second operators (22.1 , 22.2) within the departure zone 48.

Next, the backend 14 calculates the times at which the first and second operators (22.1 , 22.2) will reach their respective departure locations (52.1 , 52.2). This is done by taking into account the distance each of the first and second operators (22.1 , 22.2) will have to travel along their respective routes (36.1 , 36.2) to reach the respective departure locations (52.1 , 52.2). Traffic conditions along these sections of the routes are taken into account for this calculation. Further stops along these routes, for picking up other entities along the way, are also taken into account. According to the calculation, the first operator 22.1 will reach its departure location at a time T3, and the second operator will reach its departure location at a time T4 (even though the distance that the second operator has to travel to reach the departure location 52.2 is shorter, T4 is later that T3, since the second operator 22.2 will only set of on its journey at time T1 ).

Waiting times at each of the departure locations (52.1 , 52.2) are calculated.

The travel times along the routes (36.1 , 36.2) to the respective arrival locations (54.1 , 54.2) of each of the first and second operators (22.1 , 22.2) are also calculated, in the same way as the travel times are calculated to reach the arrival locations (52.1 , 52.2) as aforementioned. According to the calculation, the first operator 22.1 will reach its arrival location 54.1 at a time T5, and the second operator 22.2 will reach its arrival location 54.2 at a time T6.

The first entity 12 did not indicate a desired time of arrival at the second location 46. Therefore, there are no required timeframes within which T3, T4, T5 and T6 have to fall in order to qualify the first and second operators (22.1 , 22.2) as potential operators. From the real-time data (28.1 , 28.2) associated with the first and second operators (22.1 , 22.2), data relating to the availability of seats on the vehicles (30.1 , 30.2) is ascertained. Seats are available on both vehicles (30.1 , 30.2).

The first and second operators (22.1 , 22.2) are therefore compiled onto the list. The order in which the first and second operators (22.1 , 22.2) are shown on the list is determined by the predetermined rule. In this case, the first operator 22.1 is indicated first since the arrival time T5 is before the arrival time T6.

The list is transmitted to the first entity 12 and displayed on the commuter input module 42. The estimated times of arrival at the respective departure locations (52.1 , 52.2), the arrival locations (54.1 , 54.2) and the second location 46 is also indicated. Details pertaining to the locations of the respective departure locations (52.1 , 52.2) and the costs involved in each of the two trips are also indicated.

The first entity now accepts the first operator 22.1 as the operator of choice and makes payment for the trip in known fashion. The acceptance is received on the backend 14, and the real-time data 28.1 of the first operator 22.1 is adapted accordingly. Additional arrival and departure locations (52.1 , 54.1 ) are therefore added to the route, and the availability of seats on the vehicle 30.1 is adjusted.

The commuter input module 42 now indicates a route that the first entity 12 should take to reach the departure location 52.1 .

As the first operator 22.1 approaches the departure location 52.1 , the operator input module 38 provides a warning to the first operator. The first entity 12 is picked up at the departure location 52.1.

As the first operator 22.1 approaches the arrival location 52.1 , the operator input module 38 provides a warning to the first operator 22.1. The first entity 12 is dropped-off at the arrival location 54.1 and proceeds to walk to the second location 46.

As discussed above, the route 36 associated with the operator 22 may be a route 36 that the operator 22 has already set-off on. Alternatively, or in addition, the method may facilitate the pooling of potential first entities 12 before the operator 22 sets-off on its route 36. In such a case, the operator 22 provides a dataset to the backend, indicating a route 36 that the operator plans to set-off on in the near future. This planned route is seen as one of the routes 36 described above when the first entity 12 is using the system 10 to solicit the services of a potential operator.

Now, a number of first entities 12 all using the system 10, identifies the operator as a potential operator based on the planned route of the operator, and indicates their selection of the operator as an acceptable operator.

The operator may therefore now be able to wait until a predetermined number of first entities indicated it as an acceptable operator, before setting-off on the route. This may enable better utilisation of space in the vehicle 30 associated with the operator 22.

In the case of using the system for the purpose of pooling, the first entities may be informed through the system 10, that the operator 22 has not yet set-off on the route, and that the departure time will be dependent on the operator’s actual time of setting-off. The actual time of setting-off of the operator may be communicated to the first entities 12 associated with the pool. Each entity’s expected departure and arrival times may be calculated accordingly.

As the operator 22 travels along the planned route, data pertaining to departure locations of each first entity associated with the pool may be communicated to the operator, to enable the operator to stop at the various departure locations to pick first entities up.

It will be understood that the system 10 can be adapted to facilitate connecting commutes between a start and finish location. In such a case, the second location 46 would be an intermediate location, which would act as a first location for a second commute. The second commute may be facilitated in the same way as the commute between the first and second locations (44, 46) as discussed herein. Potential operators may be identified concurrently with potential operators for the first commute, or at a time thereafter.

It will be understood that the use of the system 10 in accordance with the method provides for a means to utilise shared public transport more efficiently. Commuters may better plan their commutes between locations and may avoid long queues or waiting times at pick-up locations. Commuters unfamiliar with an area or its public transport systems, may more easily make use of such systems.

Operators may be better utilised, while commuters are presented with an option to select the most time or cost-effective commute. Furthermore, the picking-up of commuters does not interfere with the planned route of the operator 22, and so the commuting time of the operator is not negatively impacted (apart from the stops that have to be made at the departure locations 52 and arrival locations 54 along the route 36). It will be appreciated that the above description only provides an example embodiment of the invention and that there may be many variations without departing from the spirit and/or the scope of the invention. It is easily understood from the present application that the particular features of the present invention, as generally described and illustrated in the figures, can be arranged and designed according to a wide variety of different configurations. In this way, the description of the present invention and the related figures are not provided to limit the scope of the invention but simply represent selected embodiments.

The skilled person will understand that the technical characteristics of a given embodiment can in fact be combined with characteristics of another embodiment, unless otherwise expressed or it is evident that these characteristics are incompatible. Also, the technical characteristics described in a given embodiment can be isolated from the other characteristics of this embodiment unless otherwise expressed.

Claims

1 . A method for facilitating or providing a transportation service to a first entity, the method comprising the steps of: receiving, on a backend, from the first entity, a first dataset relating to a first location and a second location; identifying at least one potential operator from a database of operators, wherein an operator is identified as a potential operator when a route associated with the operator coincides with a departure zone associated with the first location, which departure zone is calculated in accordance with a predetermined rule, and wherein a departure location associated with the potential operator is defined at a location where the route and the departure zone coincides; and communicating data pertaining to the at least one potential operator and the departure location associated with said at least one potential operator, to the first entity.

2. The method according to claim 1 , wherein identifying an operator as a potential operator furthermore requires the route associated with the operator to coincide with an arrival zone associated with the second location, which arrival zone is calculated in accordance with a second predetermined rule, and wherein an arrival location associated with the potential operator is defined at a location where the route and the arrival zone coincides.

3. The method according to claim 2, including the steps of calculating the departure zone and arrival zone in accordance with the respective predetermined rules.

4. The method according to any one of the preceding claims, wherein the departure zone comprises an area surrounding the first location and having a boundary or periphery defined by the predetermined rule.

5. The method according to claim 4, wherein the predetermined rule in accordance with which the departure zone is calculated limits a distance between the boundary or periphery of the departure zone and the first location, to within a predetermined distance.

6. The method according to claim 5, wherein the predetermined distance is determined by taking into account the time required for the first entity to reach the boundary or periphery of the departure zone from the first location.

7. The method according to any one of the preceding claims, comprising the further step of calculating a time required for an operator to reach its associated departure location.

8. The method according to claim 7, wherein the step of calculating the time required forth operator to reach its associated departure location takes into account prevailing traffic conditions.

9. The method according to any one of the preceding claims, including the step of receiving on the backend, data pertaining to prevailing traffic conditions.

10. The method according to any one of the preceding claims, wherein identifying an operator as a potential operator furthermore requires a time required to reach the departure location associated with said operator, to fall within a predetermined timeframe.

1 1. The method according to claim 10, wherein the predetermined timeframe takes into account a time required for the first entity to arrive at the departure location associated with said operator.

12. The method according to claim 10 or 11 , wherein the predetermined timeframe is limited by a permissible waiting time.

13. The method according to any one of claims 10 to 12, including the step of receiving from the first entity a desired time of departure, and calculating the predetermined timeframe in accordance with the desired time of departure.

14. The method according to claim 2 or 3, wherein the arrival zone comprises an area surrounding the second location and having a boundary or periphery defined by the second predetermined rule.

15. The method according to claim 14, wherein the second predetermined rule limits a distance between the boundary or periphery of the arrival zone and the second location, to within a predetermined distance.

16. The method according to claim 15, wherein the predetermined distance is determined by taking into account the time required for the first entity to reach the second location from the boundary or periphery of the arrival zone.

17. The method according to claim 2 or 3, further comprising the step of calculating a time required for each operator to reach the arrival location associated with said operator.

18. The method according to claim 17, wherein the step of calculating a time required for each operator to reach the arrival location associated with said operator takes into account prevailing traffic conditions.

19. The method according to claims 17 or 18, wherein identifying an operator as a potential operator furthermore requires the time required to reach the arrival location associated with said operator, to fall within a predetermined timeframe.

20. The method according to claim 19, wherein the predetermined timeframe takes into account a length of the route associated with said operator, a length of the route between the departure and arrival locations, and prevailing traffic conditions along said route.

21. The method according to claim 19 or 20, wherein the method further includes receiving from the first entity a desired time of arrival at the second location, and wherein the predetermined timeframe is adjusted in accordance with the desired time of arrival.

22. The method according to any one of the preceding claims, including receiving from an operator an indication of the availability of space associated with the operator and wherein identifying an operator as a potential operator furthermore requires the indication of the availability of space to satisfy a predetermined requirement.

23. The method according to any one of the preceding claims, further comprising the step of compiling a list of more than one potential operator, each potential operator associated with a departure location and arrival location.

24. The method according to claim 23, wherein the potential operators on the list are ordered in accordance with a rule of relevance.

25. The method according to claims 23 or 24, including the step of communicating the list to the first entity. 22

26. The method according to claim 25, including the further step of receiving as an input from the first entity, a selection of an acceptable operator from the list, and communicating said selection to the relevant operator.

27. The method according to claim 26, including the further step of receiving as an input from the second entity an acceptance and communicating said acceptance to the first entity.

28. The method according to claim 27, including the steps of: providing data pertaining to a departure location to the first and second entities; and adapting the database of operators.

29. The method according to claim 28, including the steps of alerting the operator in real time of the proximity of the departure location and/or the proximity of the arrival location.

30. The method according to any one of the preceding claims, wherein the first dataset includes an indication of a current time, a desired time of departure, and/or a desired time of arrival.

31. The method according to any one of the preceding claims, including the steps of: receiving on the backend, from each of a plurality of operators, an operator dataset including at least some of data pertaining to a destination, data pertaining to a route, time data, and data pertaining to the availability of space; and storing the data from each operator dataset in the database of operators.

32. The method according to claim 31 , wherein operator datasets are received in real-time, and wherein the database of operators is updated in real-time with data from the operator datasets so received.

33. The method according to any one of the preceding claims, wherein the method includes determining a cost associated with the transportation of the first entity between the first and second locations and communicating said cost to the first entity.

34. The method according to claim 33, wherein the method comprises the further step of receiving funds from the first party and allocating at least a portion thereof to the identified second entity. 23 The method according to any one of the preceding claims, wherein the route associated with the operator is a route that the operator has already set off on. The method according to any one of claims 1 to 34, wherein the route associated with the operator is a planned route, indicated by the operator. A method of facilitating or providing a transportation service to a plurality of first entities, the method comprising the steps of: receiving on a backend, from an operator an operator dataset including data pertaining to a planned route; receiving as input, in accordance with any one of claims 1 to 36, from each of the plurality of first entities, a selection of the operator as an acceptable operator; and communicating data to the operator pertaining to a number of predetermined departure locations, each first entity associated with a specific departure location. The method according to claim 37, including the further step of providing an instruction to said operator to set-off on the planned route once a number of inputs received from said plurality of first entities reaches a predetermined number. A system for providing a transportation service to a first entity by using the method according to any one of claims 1 to 36, the system comprising: a backend comprising a processing module and a memory arrangement, the memory arrangement having stored thereon a database of operators; a plurality of operator input modules, each operator input module associated with a specific operator, the plurality of operator input modules for capturing operator datasets in real time and transmitting same to the backend; and a plurality of commuter input modules for receiving first datasets from a plurality of commuters onto the backend.