Communication server device, method and communication system for managing transportation-related service requests

Abstract

A communication server device for managing transportation-related service requests, the communication server device being configured to generate a data record having a plurality of transit point data fields in response to receiving user request data, the plurality of transit point data fields having data of corresponding plurality of transit points from an origin to a destination, the plurality of transit point data fields including a variable transit point data field having data determined based on data associated with at least one transportation network-related parameter, and the data record having a plurality of journey interval data fields defining corresponding plurality of journey intervals for navigation directions from the origin to the destination, and for each journey interval data field, the communication server device being configured to associate the journey interval data field with the corresponding transit point data field, and being configured to determine a corresponding transportation mode based on the data of the associated transit point data field, and to generate transit data regarding the corresponding transportation mode.

Description

Technical Field

[0001] The present invention relates generally to the field of communications and trip planning. One aspect of the present invention relates to a communication server device for managing transport-related service requests. Another aspect of the present invention relates to a method for managing transport-related service requests. Other aspects relate to a computer program product, a computer program, a non-transitory storage medium having instructions for performing the method, and a communication system for managing transport-related service requests.

[0002] One aspect of the invention has particular, but not exclusive, application to processing requests (e.g., requests for transportation-related services related to a trip from an origin location (O) to a destination location (D)). This may include providing trip options (including multi-modal trip options) from O to D for selection by the user in response to a request from the user. Pareto-optimal trip options may be identified for the user. Background Art

[0003] Transportation systems often face a first mile / last mile problem, where users may face challenges getting from their origin to the transportation network and / or from the transportation network to their destination. Known systems attempt to solve this first mile / last mile problem by patching on-demand rides onto fixed rides or vice versa. Informally, this may be referred to as "Park and Ride". Summary of the invention

[0004] Various aspects of the invention are set out in the independent claims. Some optional features are defined in the dependent claims.

[0005] Embodiments of the technology disclosed herein may provide one or more important technical advantages. This includes generating a network having variable transfer points determined based on at least one transportation network related parameter. The variable transfer points may not be limited to fixed transportation services or schedule-based transportation services, nor are they strictly assigned fixed locations, but may be appropriately considered one or more parameters of the transportation network to determine their locations to maximize any desirable (multiple) effects and minimize any undesirable (multiple) effects or (multiple) risks associated with the (multiple) parameters.

[0006] In at least some embodiments, the techniques disclosed herein can provide identification of Pareto-optimal trip options optimized for multiple parameters. The techniques can also provide variable transfer points associated with a ride-hailing mode of transportation, where the variable transfer points can be determined based on at least one of driver supply, accessibility, risk of fare increases, or minimal detours. BRIEF DESCRIPTION OF THE DRAWINGS

[0007] The present invention will now be described, by way of example only, with reference to the accompanying drawings, in which:

[0008] Figure 1 is a schematic block diagram illustrating an exemplary communication system involving a communication server device for managing transportation-related service requests.

[0009] Figure 2A A schematic block diagram illustrating a communication server apparatus for managing transport-related service requests is shown.

[0010] Figure 2B A schematic block diagram showing data logging is shown.

[0011] Figure 2C A flow chart illustrating a method performed in a communication server device for managing transportation-related service requests is shown.

[0012] Figure 3 An example of a comparison of multimodal journeys in the time-price space is shown.

[0013] Figure 4 An example of a multi-mode network is shown.

[0014] Figure 5A An example showing a possible optimal multimodal path from the upper right node to the lower left node is shown.

[0015] Figure 5B The results of filtering Pareto optimal multimodal routes in the 2D space of time and fare are shown.

[0016] Figure 6 A block diagram of a multimodal trip recommender system is shown.

[0017] Fig. 7A A flow chart illustrating a method for generating multi-modal trip options is shown.

[0018] Figure 7B A flow chart illustrating a method for determining a variable transition point is shown.

[0019] Figure 7C A flow chart illustrating a method for determining a fixed transfer point is shown.

[0020] Fig. 8A An example of a multimodal network as input for determining Pareto optimal multimodal travel options is shown.

[0021] Figure 8B Shows the use of Fig. 8A Example of a multimodal network with as input and Pareto optimal multimodal trip options as output.

[0022] Fig. 9 Exemplary data structures and their purposes are shown.

[0023] Fig. 10A Shows how to shrink a node.

[0024] Fig. 10B The top 100 nodes determined for a portion of the city of Jakarta, Indonesia are shown. DETAILED DESCRIPTION

[0025] A multimodal journey recommender system may be provided, for example, a system for generating and identifying competing multimodal routes.

[0026] A system is provided for getting a user or any person from an origin (O) to a destination (D) that can be adjusted at any time to the preferences and circumstances of the user or person and this can be done in an optimized manner. The system utilizes on-demand and / or ride-hailing transportation options and public transportation (or any third-party transit service) infrastructure to get passengers from their origin to their destination via one (or more) possible itineraries (including (multiple) multi-modal itineraries) that can be optimized with respect to the passenger's preferences (e.g., duration, fare, number of transfers, etc.).

[0027] The system may include one or more of the following technical features:

[0028] (i) Multimodal journey generation: Given a road network (a graph where nodes are streets (or intersections) and edges are intersections (or streets, respectively) connecting nodes) and a transit network (a graph where nodes are designated stops and edges are connections), a multimodal network connecting an origin (O) to a destination (D) (i.e., O→D) can be derived based on intelligent filtering of the nodes (or vertices) of these two networks.

[0029] The road network and transit network were generated internally based on OpenStreetMap (OSM) data sources for the road network and publicly available public transportation data for the transit network.

[0030] (ii) Multimodal Optimal Journey Identification: Based on the obtained multimodal network, the system can perform an efficient multi-objective search to identify one or more optimal paths from an origin (O) to a destination (D) with respect to one or more preferences of a user or passenger.

[0031] First reference Figure 1, shows a communication system 100, which can be suitable for various embodiments. The communication system 100 includes a communication server apparatus 102, a first user (or client) communication device 104, and a second user (or client) communication device 106. These devices 102, 104, 106 are connected in or to a communication network 108 (e.g., the Internet) through corresponding communication links 110, 112, 114 that implement, for example, the Internet communication protocol. These communication devices 104, 106 can communicate through other communication networks (such as a public switched telephone network (PSTN network), including a mobile cellular communication network), but for clarity, from Figure 1 It should be understood that there may be one or more other communication devices similar to devices 104, 106.

[0032] The communication server device 102 may be Figure 1 The single server schematically shown in FIG. 1 may have functions that are performed by the communication server device 102 and distributed across multiple server components. Figure 1 In the example of , the communication server device 102 may include multiple separate components, including, but not limited to: one or more microprocessors (μP) 116, a memory 118 (e.g., volatile memory, such as RAM (random access memory)) for loading executable instructions 120, the executable instructions 120 defining the functions performed by the server device 102 under the control of the processor 116. The communication server device 102 may also include an input / output (I / O) module 122 that allows the server device 102 to communicate via the communication network 108. A user interface (UI) 124 is provided for user control and may include, for example, one or more peripheral computing devices, such as a display monitor, a computer keyboard, and the like. The communication server device 102 may also include a database (DB) 126, the purpose of which will become more apparent from the following discussion.

[0033] The user communication device 104 may include a plurality of separate components, including but not limited to: one or more microprocessors (μP) 128, a memory 130 (e.g., volatile memory, such as RAM) for loading executable instructions 132, which define the functions performed by the user communication device 104 under the control of the processor 128. The user communication device 104 also includes an input / output (I / O) module 134 that allows the user communication device 104 to communicate via a communication network 108. A user interface (UI) 136 is provided for user control. If the user communication device 104 is, for example, a smart phone or a tablet device, the user interface 136 may have a touch panel display that is ubiquitous in many smart phones and other handheld devices. Alternatively, if the user communication device 104 is, for example, a desktop computer or a laptop computer, the user interface may have, for example, one or more peripheral computing devices, such as a display monitor, a computer keyboard, and the like.

[0034] The user communication device 106 may be, for example, a smartphone or tablet device having a hardware architecture that is the same as or similar to that of the user communication device 104 .

[0035] Figure 2A A schematic block diagram showing a communication server apparatus 202 for managing transport-related service requests is shown. Figure 2B A schematic block diagram illustrating a data record 240 that may be generated by the communication server device 202 is shown.

[0036] The communication server device 202 includes a processor 216 and a memory 218, wherein the communication server device 202 is configured to execute instructions stored in the memory 218 under the control of the processor 216 so as to: in response to receiving user request data including a data field indicating an origin location and a data field indicating a destination location, generate a data record 240 having a plurality of transit point data fields 242a, 242b, 242c to 242k, the transit point data field having a corresponding plurality of transit points from the origin location to the destination location data (as a non-limiting example, shown as corresponding data 244a, 244b for the transfer point data fields 242a, 242b), the plurality of transfer point data fields 242a, 242b, 242c through 242k including a variable transfer point data field (for example and for purposes of illustration, data field 242b) having data 244b corresponding to a variable transfer point determined based on data associated with at least one transportation network-related parameter; generating, in the data record 240, a plurality of transfer point data fields 242a, 242b, 242c through 242k corresponding to a variable transfer point determined based on data associated with at least one transportation network-related parameter; The communication server device 202 is further configured to associate the trip interval data fields 246a, 246b, 246c, 246d, 246e to 246n with the plurality of transit point data fields 242a, 242b, 246c, 246d, 246e to 246n for defining the corresponding plurality of trip intervals for the navigation direction to the destination location, and wherein, for each of the trip interval data fields 246a, 246b, 246c, 246d, 246e to 246n, the communication server device 202 is further configured to associate the trip interval data fields 246a, 246b, 246c, 246d, 246e to 246n with the plurality of transit point data fields 242a, 242b, 246c, 246d, 246e to 246n The processor 216 and the memory 218 may be coupled to each other (as represented by line 217), for example, physically connected and / or electrically coupled. The processor 216 may be configured to determine the corresponding transportation mode for the corresponding journey interval based on the data 244a, 244b of the associated transit point data fields 242a, 242b, 242c to 242k and generate transit data about the corresponding transportation mode (as a non-limiting example, the journey interval data fields 246a, 246c are shown as corresponding transit data 248a, 248c). The processor 216 and the memory 218 may be coupled to each other (as represented by line 217), for example, physically connected and / or electrically coupled. The processor 216 may be configured to determine the corresponding transportation mode for the corresponding journey interval based on the data 244a, 244b of the associated transit point data fields 242a, 242b, 242c to 242k and generate transit data about the corresponding transportation mode (as a non-limiting example, the journey interval data fields 246a, 246c are shown as corresponding transit data 248a, 248c). Figure 1 ) and / or the memory 218 may be as described in the context of the memory 118 ( Figure 1 ) in the context of.

[0037] In other words, a communication server device 202 for managing transportation-related service requests or for trip planning may be provided. The server device 202 may receive user request data related to a user-initiated request for transportation-related services (booking). The request may be initiated, for example, via a user communication device (e.g., a smart phone, a tablet computer, a handheld / portable communication device, a desktop computer or a laptop computer, etc.). According to instructions stored in the memory 218 and executed by the processor 216, and in response to receiving user request data including a data field indicating an origin location (O) (or a starting location) and a data field indicating a destination location (D) (or an ending location), the communication server device 202 may generate a data record 240 having a plurality of transit point data fields 242a, 242b, 242c to 242k, at least one of which is a variable transit point data field (e.g., 242b). Each of the plurality of transit point data fields 242a, 242b, 242c to 242k may include data 244a, 244b for a corresponding plurality of transit points from an origin location to a destination location. Data 244b corresponding to a variable transit point associated with the variable transit point data field 242b may be suitably determined based on data associated with at least one transportation network-related parameter (or condition). The data (e.g., 244a, 244b) may be transit point data, or a portion of a larger data set of a corresponding plurality of transit points or a corresponding transit point data field (e.g., 242a, 242b).

[0038] The communication server device 202 may also generate a plurality of journey (or route) interval data fields 246a, 246b, 246c, 246d, 246e to 246n of corresponding plurality of journey intervals (or sections or routes) in the data record 240 to define the navigation direction from O to D or cover the journey from O to D. The plurality of journey intervals may include a continuous or connected journey interval from O to D.

[0039] The plurality of transit point data fields 242a, 242b, 242c through 242k and the plurality of journey interval data fields 246a, 246b, 246c, 246d, 246e through 246n may be arranged in the data record 240 in any suitable manner.

[0040] It should be understood that there may be any number of transit point data fields 242a, 242b, 242c to 242k, and / or any number of journey interval data fields 246a, 246b, 246c, 246d, 246e to 246n. The number of journey interval data fields 246a, 246b, 246c, 246d, 246e to 246n may be greater than the number of transit point data fields 242a, 242b, 242c to 242k.

[0041] For each journey interval data field 246a, 246b, 246c, 246d, 246e to 246n, the communication server device 202 may be further configured to associate the journey interval data field 246a, 246b, 246c, 246d, 246e to 246n with a corresponding transit point data field in the plurality of transit point data fields 242a, 242b, 242c to 242k. As a non-limiting example, Figure 2B As shown by the double-headed dashed arrow in , the trip interval data field 246a can be associated with the transfer point data field 242a, the trip interval data field 246b can be associated with the transfer point data field 242c, the trip interval data field 246c can be associated with the transfer point data field 242b, the trip interval data field 246d can be associated with the transfer point data field 242k, the trip interval data field 246e can be associated with the transfer point data field 242b, and so on.

[0042] For each journey interval data field (e.g., using data field 246a as a non-limiting example), the communication server device 202 can also be configured to determine the corresponding transportation mode for the corresponding journey interval based on the data (e.g., 244a) of the associated transit point data field (e.g., 242a) and generate transit data (e.g., 248a) regarding the corresponding transportation mode. The transit data (e.g., 248a, 248c) can be part of a larger data set for the corresponding journey interval data field (e.g., 246a, 246c).

[0043] The transit point data (e.g., 244a, 244b) and transit data (e.g., 248a, 248c) may be transmitted or provided for display / presentation to the user or for selection by the user. Such data may be transmitted to the communication device of the user who initiated the request.

[0044] The data record 240 may be stored in the memory 218 or as a database of the communication server device 202 (e.g., Figure 1 126) in part.

[0045] A plurality of trip interval data fields 246a, 246b, 246c, 246d, 246e-246n and a plurality of transit point data fields 242a, 242b, 242c-242k may be generated to define a plurality of trip options from an origin location to a destination location, wherein each of the plurality of trip options may be defined by at least two of the plurality of trip interval data fields 246a, 246b, 246c, 246d, 246e-246n, and wherein the at least two trip interval data fields are trip interval data fields for corresponding trip intervals defining navigation directions for a single trip starting from the origin location and ending at the destination location. The plurality of trip options may include at least one multimodal trip option.

[0046] A "multi-mode" trip option may refer to a trip option having at least two journey intervals associated with respective different modes of transport. In other words, the at least two journey intervals of the multi-mode trip option may be provided by different modes of transport (ie, multi-mode).

[0047] As described, each journey interval (or journey interval data fields 246a, 246b, 246c, 246d, 246e to 246n) may have an associated or corresponding transfer point (or transfer point data fields 242a, 242b, 242c to 242k). A corresponding transfer point may refer to a starting point or an end point of a corresponding journey interval. A variable transfer point may refer to a point or location at which a user may start a journey interval associated with a variable transfer point, or a point or location at which a user may end or stop the journey interval.

[0048] In addition to the variable transit point, the plurality of transit points may include one or more fixed transit points and / or one or more other variable transit points. This may mean that the plurality of transit point data fields 242a, 242b, 242c to 242k may include: one or more fixed transit point data fields having data corresponding to the (multiple) fixed transit point(s), and one or more variable transit point data fields having data corresponding to the (multiple) variable transit point(s).

[0049] A "fixed transfer point" may be associated with a journey interval served by a schedule-based / fixed (schedule) transportation mode / service (e.g., LRT, MRT, train, bus, ferry, etc.). Thus, a fixed transfer point may be associated with a fixed / schedule-based journey interval. As non-limiting examples, a fixed transfer point may correspond to a train station, a bus station, or a ferry terminal, etc.

[0050] A "variable transfer point" may be associated with a journey segment that is served by an on-demand / variable transportation mode / service (e.g., a taxi or ride-sharing service, etc.). As such, a variable transfer point may be associated with a variable / on-demand journey segment. A variable transfer point is not limited by the presence of a fixed service, and the location of the variable transfer point may change as determined based on data associated with at least one transportation network-related parameter.

[0051] It should be understood that the variable transfer point (or its data) is determined based on data associated with at least one transportation network-related parameter, rather than being arbitrarily selected or fixed to a transfer point at the user's "current" location. For example, for a user who wants to start a journey segment associated with a variable transfer point, the variable transfer point may not necessarily be the exact location where the user may currently be located; instead, information related to the at least one transportation network-related parameter may be processed or analyzed to determine a suitable variable transfer point for starting the journey segment, which variable transfer point may be far away from the user's "current" location.

[0052] As a non-limiting example, the plurality of transit point data fields 242a, 242b, 242c to 242k and the corresponding data 244a, 244b may be generated by a transit point ranking engine (or circuit or module) of the device 202. The plurality of trip interval data fields 246a, 246b, 246c, 246d, 246e to 246n may be generated by a route planning engine (or circuit or module) of the device 202. The route planning engine may include a predictive pricing engine, a time-dependent route planning engine, and a time-independent route planning engine to provide trip intervals and parameterize them with criteria of interest (e.g., duration, fare, number of transfers as part of the transit data). One or more of the transit point ranking engine, the predictive pricing engine, the time-dependent route planning engine, and the time-independent route planning engine may be part of or implemented by the processor 216.

[0053] In various embodiments, multiple journey intervals and multiple transfer points may define multiple trip options (or candidate trips) starting from an origin location and ending at a destination location. This may mean that, in response to user request data, multiple multimodal trip options (or candidate multimodal trips) for a trip from O to D may be generated. Multiple journey intervals and multiple transfer points may be defined as corresponding trip options. A trip option may include at least some of the multiple journey intervals and at least one transfer point. A complete trip option may be defined by two or more of the multiple journey intervals. It should be understood that one or more of the multiple journey intervals may be defined in more than one trip option, and / or one or more of the multiple transfer points may be defined in more than one trip option. This may mean that the journey intervals and / or transfer points may be shared or common by two or more trip options. The multiple trip options may include at least one multimodal trip option.

[0054] In various embodiments, the at least one transportation network-related parameter may include a dynamic transportation network-related parameter. For example, information related to the at least one transportation network-related parameter may be variable in real time.

[0055] In various embodiments, the plurality of transfer point data fields 242a, 242b, 242c to 242k may include a plurality of variable transfer point data fields (e.g., including data field 242b), each of the plurality of variable transfer point data fields having data corresponding to a corresponding variable transfer point that may be determined based on data associated with at least one transportation network-related parameter. Each variable transfer point data field may be associated with a trip interval data field in the at least two trip interval data fields of a corresponding trip option in the plurality of trip options.

[0056] The communication server device 202 may be further configured to (under the control of the processor 216, execute instructions stored in the memory 218 to) identify one or more Pareto optimal trip options from the plurality of trip options based on the transit data corresponding to at least two trip interval data fields defining each trip option (e.g., 248a, 248c). The Pareto optimal trip options may be optimized with respect to one or more components of the transit data (e.g., at least one of duration, fare, or number of transfers). The one or more Pareto optimal trip options may be identified using, for example, a multi-objective shortest path engine (or circuit or module) of the device 202 as part of the processor 216.

[0057] The communication server device 202 may also be configured to (under the control of the processor 216, execute instructions stored in the memory 218, so as to) control the number of Pareto optimal travel options to be identified based on the defined ε resolution value. This may be achieved based on an ε resolution value that may be defined or specified.

[0058] In various embodiments, the road network and the transit network can be stored separately in the memory 218, and wherein a plurality of transit point data fields 242a, 242b, 242c to 242k and a plurality of journey interval data fields 246a, 246b, 246c, 246d, 246e to 246n can be generated using data corresponding to the road network and the transit point network. The "road network" is a time-independent network and is associated with a demand-based / variable mode of transportation or service, while the "transit network" is a time-dependent network and is associated with a schedule-based / fixed mode of transportation or service. By keeping the road network and the transit network separate, a suitable route planning algorithm can be applied to each of the two networks. As a non-limiting example, a contraction hierarchy algorithm can be used for the road network, while a connection scanning algorithm can be used for the transit network.

[0059] The communication server device 202 may also be configured to (under the control of the processor 216, execute instructions stored in the memory 218 to): provide data updates to at least one of the road network or the transit network in real time. As a result of maintaining the two networks separately, updates can be provided separately to the respective networks.

[0060] In various embodiments, the corresponding transportation mode for the trip interval data field (e.g., 246c) associated with the variable transfer point data field (e.g., 242b) may include a carpooling transportation mode. This may include, for example, car sharing, ride sharing, or bike sharing.

[0061] In various embodiments, the corresponding transportation mode for the trip interval data field (e.g., 246c) associated with the variable transfer point data field (e.g., 242b) may include a ride transportation mode. This may include, for example, a car call, or a (motorcycle) bicycle call.

[0062] In various embodiments, the data associated with at least one transportation network-related parameter may correspond to at least one of driver supply, accessibility (of a variable transfer point) to a user, a fare increase-related parameter, or a detour-related parameter.

[0063] In an embodiment where the data associated with at least one transportation network-related parameter corresponds to a fare increase-related parameter, the communication server device 202 may be further configured to (under the control of the processor 216, execute instructions stored in the memory 218 so as to) generate in the data record 240 a plurality of initial variable transfer point data fields for the corresponding plurality of initial variable transfer points from the origin location (O) to the destination location (D), determine a value (e.g., an increase multiplier value) for the fare increase-related parameter for each initial variable transfer point data field in the plurality of initial variable transfer point data fields, and if the value of an initial variable transfer point data field in the plurality of initial variable transfer point data fields is greater than a threshold value indicating a high risk of fare increase, disregard (or remove) the initial variable transfer point corresponding to the initial variable transfer point data field, and if the value of the initial variable transfer point data field in the plurality of initial variable transfer point data fields is less than the threshold value, keep the initial variable transfer point corresponding to the initial variable transfer point data field as a candidate for a variable transfer point (which corresponds to, for example, the variable transfer point data field 242 b). By setting the threshold to a cutoff point that represents a high risk of fare increases, and comparing relative to that threshold, variable transit points that may be prone to fare increases or have a high risk of fare increases may be eliminated from consideration.

[0064] In an embodiment where the data associated with at least one transportation network-related parameter corresponds to a detour-related parameter, the communication server device 202 may be further configured to (under the control of the processor 216, execute instructions stored in the memory 218 so as to) generate a plurality of initial variable transit point data fields corresponding to the plurality of initial variable transit points from the origin location (O) to the destination location (D) in the data record 240, determine a (ranking or importance) value for the detour-related parameter for each initial variable transit point data field in the plurality of initial variable transit point data fields, and if the value of the initial variable transit point data field of the plurality of initial variable transit point data fields is greater than a threshold value indicating the least detour, maintain the initial variable transit point corresponding to the initial variable transit point data field as a candidate for the variable transit point (which corresponds to, for example, the variable transit point data field 242 b), and if the value of the initial variable transit point data field of the plurality of initial variable transit point data fields is less than the threshold value, ignore (or remove) the initial variable transit point corresponding to the initial variable transit point data field. By setting a threshold to a cutoff point representing the least detour, and comparing against the threshold, it is possible to consider maintaining a variable transfer point that minimizes detours. As used herein, the term "initially" means "initial" and has been used to distinguish it from the term "initial variable transfer point" described above with respect to fare increase related parameters.

[0065] In various embodiments, the communication server device 202 may also be configured to (under the control of the processor 216, execute instructions stored in the memory 218 so as to) update the user's progress through the corresponding journey interval in the journey interval data fields of the plurality of journey interval data fields 246a, 246b, 246c, 246d, 246e to 246n; and provide a warning signal to the user via the user's communication device before the end of the corresponding journey interval (for example, when approaching the end of the corresponding journey interval).

[0066] Figure 2C A flowchart 250 is shown illustrating a method executed in a communication server device for managing transportation-related service requests under the control of a processor of the communication server device. In response to receiving user request data including a data field indicating an origin location (O) and a data field indicating a destination location (D), at 252, a data record is generated including a plurality of transit point data fields having data for a corresponding plurality of transit points from the origin location to the destination location, the plurality of transit point data fields including a variable transit point data field having data corresponding to a variable transit point determined based on data associated with at least one transportation network-related parameter; at 254, a plurality of trip interval data fields are generated in the data record for a corresponding plurality of trip intervals defining navigation directions from the origin location to the destination location; and at 256, for each trip interval data field, the trip interval data field is associated with a corresponding transit point data field in the plurality of transit point data fields, and further, a corresponding transportation mode for the corresponding trip interval is determined based on the data of the associated transit point data field, and transit data for the corresponding transportation mode is generated.

[0067] In various embodiments, a plurality of trip interval data fields and a plurality of transit point data fields may be generated to define a plurality of trip options from an origin location to a destination location, wherein each of the plurality of trip options may be defined by at least two of the plurality of trip interval data fields, and wherein the at least two trip interval data fields may be trip interval data fields of corresponding trip intervals defining navigation directions for a single trip starting from the origin location and ending at the destination location. The plurality of trip options may include at least one multimodal trip option.

[0068] The plurality of transfer point data fields may include a plurality of variable transfer point data fields, each of the plurality of variable transfer point data fields having data corresponding to a corresponding variable transfer point that may be determined based on data associated with at least one transportation network-related parameter. Each variable transfer point data field may be associated with a trip interval data field in the at least two trip interval data fields of a corresponding trip option in the plurality of trip options.

[0069] The method may further include: identifying one or more Pareto optimal trip options from the plurality of trip options based on the transfer data corresponding to at least two trip interval data fields defining each trip option. The method may further include: controlling the number of Pareto optimal trip options to be identified based on the defined epsilon resolution value.

[0070] In various embodiments, the plurality of transit point data fields and the plurality of trip interval data fields may be generated from a separately maintained road network and a transit network.Data updates may be provided to at least one of the road network or the transit network in real time.

[0071] In various embodiments, the corresponding transportation mode for the trip interval data field associated with the variable transfer point data field may include a carpool transportation mode.

[0072] In various embodiments, the corresponding transportation mode for the trip interval data field associated with the variable transfer point data field may include a taxi transportation mode.

[0073] In various embodiments, the data associated with at least one transportation network-related parameter may correspond to at least one of driver supply, accessibility to users, fare escalation-related parameters, or detour-related parameters.

[0074] In an embodiment in which the data associated with at least one transportation network-related parameter corresponds to a fare increase-related parameter, the method may further include: generating a plurality of initial variable transfer point data fields for corresponding plurality of initial variable transfer points from the origin location to the destination location in the data record, determining a value for the fare increase-related parameter for each initial variable transfer point data field in the plurality of initial variable transfer point data fields, and if the value of an initial variable transfer point data field in the plurality of initial variable transfer point data fields is greater than a threshold value indicating a high risk of fare increase, disregarding the initial variable transfer point corresponding to the initial variable transfer point data field, and if the value of an initial variable transfer point data field in the plurality of initial variable transfer point data fields is less than the threshold value, maintaining the initial variable transfer point corresponding to the initial variable transfer point data field as a candidate for a variable transfer point.

[0075] In an embodiment in which the data associated with at least one transportation network-related parameter corresponds to a detour-related parameter, the method may further include: generating a plurality of initial variable transit point data fields of a corresponding plurality of initial variable transit points from the origin location to the destination location in the data record, determining a value for the detour-related parameter for each initial variable transit point data field in the plurality of initial variable transit point data fields, and maintaining the initial variable transit point corresponding to the initial variable transit point data field as a candidate for the variable transit point if the value of the initial variable transit point data field of the plurality of initial variable transit point data fields is greater than a threshold value indicating least detour, and disregarding the initial variable transit point corresponding to the initial variable transit point data field if the value of the initial variable transit point data field of the plurality of initial variable transit point data fields is less than the threshold value.

[0076] The method may further include updating the user's travel progress through the corresponding journey interval in a journey interval data field of the plurality of journey interval data fields and providing a warning signal to the user via the user's communication device prior to the end of the corresponding journey interval.

[0077] It should be understood that the description in the context of the communication server device 202 may be correspondingly applicable to the method described in the context of the flowchart 250, and vice versa.

[0078] A computer program product having instructions for implementing the method for managing transportation-related service requests as described herein may also be provided.

[0079] A computer program having instructions for implementing the method for managing transportation-related service requests as described herein may also be provided.

[0080] A non-transitory storage medium storing instructions that, when executed by a processor, cause the processor to perform a method for managing transportation-related service requests as described herein may also be provided.

[0081] Various embodiments may also provide a communication system for managing transportation-related service requests, the communication system having a communication server apparatus, at least one user communication device, and a communication network device operable to enable the communication server apparatus and the at least one user communication device to establish communication with each other through the communication network device, wherein the at least one user communication device includes a first processor and a first memory, the at least one user communication device is configured to execute a first instruction stored in the first memory under the control of the first processor, so as to generate data corresponding to the starting location and the destination location in response to receiving a first request data including a data field indicating a starting location and a data field indicating a destination location, and transmit the data to be received by the communication server apparatus for processing, and wherein the communication server apparatus includes a second processor and a second memory, the communication server apparatus is configured to execute a second instruction stored in the second memory under the control of the second processor, so as to generate a data record including a plurality of transit point data fields in response to receiving a second request data indicating data transmitted by the at least one user communication device, the plurality of transit point data fields having a data record from the starting location to the destination location The communication server device of the present invention is configured to store data of a plurality of transit points corresponding to a destination location, the plurality of transit point data fields including a variable transit point data field having data corresponding to a variable transit point determined based on data associated with at least one transportation network-related parameter, in which a plurality of journey interval data fields defining a navigation direction from the origin location to the destination location are generated, wherein for each journey interval data field, the communication server device is further configured to associate the journey interval data field with a corresponding transit point data field in the plurality of transit point data fields, and is further configured to determine a corresponding transportation mode for the corresponding journey interval based on the data in the associated transit point data field, generate transit data about the corresponding transportation mode, and transmit data corresponding to the plurality of journey intervals, and for each journey interval in the plurality of journey intervals, transmit data corresponding to a corresponding transit point associated with the journey interval, data corresponding to a corresponding transportation mode for the journey interval, and the transit data about the corresponding transportation mode, so as to be received by the at least one user communication device.

[0082] Various embodiments may solve one or more problems by one or both of the following features: (i) creating a multimodal network that encodes possible competing multimodal journeys from an origin (O) to a destination (D) (O→D); (ii) performing inference on the multimodal network created in feature (i) above to extract favorable multimodal journeys with respect to one or more criteria.

[0083] A multimodal journey consists of two or more legs, each of which can be served by a different mode of transport. Typically, a mode of transport can be one of two types: on-demand / variable (e.g., ride-sharing or taxi-hailing modes / services, e.g., GrabCar, GrabBike, GrabTaxi, GrabCycle, etc.) or schedule-based / fixed (timetable) services (e.g., LRT, MRT, train, bus, ferry, etc.).

[0084] On the one hand, a unimodal journey may be optimal with respect to certain criteria, for example, public transport provides a cheap way from O→D at the expense of time and number of transfers, while taxis generally provide a fast and convenient way from O to D.

[0085] On the other hand, a multimodal journey may provide a compromise between two or more criteria (eg, fare, time, and number of transfers).

[0086] Figure 3 An example of how multimodal journeys can be compared in the time-price space is shown, illustrating the trade-offs between time and price for different multimodal routes or trip options. Figure 3 The Pareto optimal method used in multi-modal route recommendation is further shown.

[0087] Multimodal routes with public transport legs or journey sections are a travel option for "sandwich" passengers who want a journey that is faster than a pure public transport journey but cheaper than a point-to-point journey. Figure 3 In , "time" on the y-axis is used to represent general measures such as travel time, number of transfers, walking time, etc. Figure 3 As shown in , pure public transportation routes (represented by stars 360), multimodal routes or itinerary options (different itinerary options are represented by closed squares labeled "i", "ii", "iii" and closed diamonds labeled "1", "2", "3", "4"), and point-to-point routes (represented by stars 362) can be classified according to the time and price of the journey. Each of the closed squares "i" to "iii" and the closed diamonds "1" to "4" represents a feasible multimodal itinerary option, wherein the closed diamonds "1" to "4" also represent the optimal multimodal itinerary option. The multimodal itinerary option represented by diamond "4" shows a situation that is ideal but often rare, and the time of this multimodal itinerary option is shorter than that of the point-to-point route 362. As can be observed, the multimodal journey can provide a solution with a compromise objective function somewhere between the public transportation routes (represented by stars 360) and the point-to-point routes (represented by stars 362).

[0088] The optimal condition can be expressed as follows:

[0089] If and only if there is no other route υ such that (time υ ,price υ )≤(time ω ,price ω ), the multi-mode line ω is Pareto optimal, where “≤” is the vector inequality sign, and a≤b means (in, means "all") and a≠b.

[0090] Pareto optimality will be further described below.

[0091] Finding the optimal unimodal journey is usually viewed as the shortest path problem on a network of paths (graphs) of the corresponding modes of transport. For multimodal journeys or trips, two different types of networks need to be considered: time-dependent networks (or transit networks) (e.g., MRT), and time-independent networks (road networks) (e.g., ride-hailing services). Different route planning algorithms can be applied to different networks, for example, using a contracting hierarchy algorithm for a road network and a connection scanning algorithm for a transit network.

[0092] In various embodiments, the road network and the transit network are maintained separately, which allows the use of appropriate route planning algorithms for each network. A high-level lightweight network (or multi-modal network) can be constructed whose nodes represent transit points from one mode (and accordingly, one network type) to another mode. A non-limiting example of such a multi-modal network is shown in Figure 4 Shown in.

[0093] Figure 4 An example of a resulting multimodal network 460 is shown from an origin location (O) (or a boarding point) 462 to a destination location (D) (or a drop-off point) 464. A plurality of transfer points may be provided or generated between the origin 462 and the destination 464 (wherein such data may be provided in corresponding transfer point data fields), one or more of which may be variable transfer points (two such variable transfer points are represented by 466a, 466b), and one or more of which may be fixed transfer points (three such fixed transfer points are represented by 468a, 468b, 468c). Variable transfer points such as points 466a, 466b represent the beginning (or end) of a variable / on-demand leg or trip segment, while fixed transfer points such as points 468a, 468b, 468c represent the beginning (or end) of a fixed / schedule-based service. Figure 4The acronym "POI" in stands for "Point of Interest", which refers to a particular point of interest in a map. In various embodiments, a transit point is a POI, where there are fixed POIs (e.g., bus stops, MRT stations, etc.) and variable POIs (one or more transit points that can be selected by a contraction hierarchy algorithm).

[0094] A plurality of trip options (including multi-modal trip options) from a starting point 462 to a destination 464 may be defined by a plurality of transfer points. As a non-limiting example, a first trip option includes a journey interval (or link or route) 470a, 472, 474, 476, a variable transfer point 466a, and a fixed transfer point 468a, 468b, wherein the first trip option is a multi-modal trip option. As another example, there is a second trip option with journey intervals 470b, 472, 474, 476 and the same transfer points 466a, 468a, 468b. As a further non-limiting example, a third trip option with journey intervals 478, 480a and a fourth trip option with journey intervals 478, 480b may be generated, wherein both of these trip options include the same variable transfer point 466b. Information or data related to various journey intervals (e.g., 470a, 470b, 472, 474) may be provided in the corresponding journey interval data fields.

[0095] Different journey intervals may correspond to or be served by corresponding transportation modes or services. For example, walking may be involved in journey interval 472. A journey interval between two fixed transfer points 468a, 468b (such as journey interval 474) may correspond to a fixed / schedule-based transportation mode (e.g., shuttle, bus, MRT, etc.). Journey intervals associated or linked to variable transfer points (e.g., journey intervals 470a, 470b, 480b) may correspond to variable / on-demand transportation modes / services (e.g., carpooling services or taxi services).

[0096] exist Figure 4 In the acronym "GB" refers to GrabBike (car-hailing service), "GC" refers to GrabCar (car-hailing service), and "GS" refers to GrabShare (carpooling service). The acronym "GF" refers to GrabFare, which is an internal API (application programming interface) service used to help determine the fare of certain trips. Further, the acronym "GR" refers to GrabRoad, which is an internal API service related to route planning, where the service can be called or initiated to determine the duration of certain trips.

[0097] Route planning for each journey interval or link may be accomplished based on the type of journey interval. As a non-limiting example, a connection scanning algorithm may be used for journey intervals represented by dashed lines with squares at both ends (e.g., journey interval 474), and a contraction hierarchy (or contraction hierarchy algorithm) may be used for journey intervals represented by dashed lines with circles at both ends (e.g., journey intervals 470a, 478, 480a). In various embodiments, a connection scanning algorithm may be used for journey intervals corresponding to fixed / schedule-based transportation modes / services, and a contraction hierarchy may be used for journey intervals corresponding to variable / on-demand transportation modes / services.

[0098] Transfer points may be OD dependent and / or time dependent. In general, this applies to determining transfer points (both variable and fixed) to be included in an optimal route. By "OD dependent" it is meant that transfer points may be determined from these networks so as to produce the least detour in a multimodal journey compared to the route taken by a user or passenger using a unimodal journey from O to D. By "time dependent" it is meant that transfer points may be determined so that the allocation of subsequent on-demand / variable trips is maximized and the difference between predicted fares and actual fares is minimized.

[0099] In order to maximize allocations (or users assigned to drivers of an on-demand on-demand transportation service), variable transfer points with a greater supply (ie, drivers) may be recommended for trip options.

[0100] To minimize any discrepancies between predicted fares and actual fares, various embodiments can manage the risk of price increases by tracking real-time conditions and incorporating predictive models when selecting transfer points and creating routes. Fares can be predicted based on one or more of the following: estimated time for passengers to arrive at the corresponding transfer point (e.g., by a shortest path algorithm for variable journey intervals and by a connection scanning algorithm for fixed journey intervals), supply (driver availability), demand (number of reservations), and price increase predictions at the corresponding transfer point (e.g., by predictive models and machine learning models).

[0101] Compared to known systems that have only one type of transfer point (in the form of fixed transfer points, typically corresponding to bus stops, MRT stations, or other public transportation facilities), the multimodal networks of various embodiments (e.g., multimodal network 460 ( Figure 4 )) also includes one or more variable transfer points that are not limited by the existence of fixed transportation services. Further, in various embodiments, the determination of the variable transfer points can form part of the decision variables.

[0102] The variable transfer point may be determined or selected based on either or both of the following conditions:

[0103] (1) Variable transfer points are accessible and suitable for passengers to board and alight. This can be achieved by utilizing historical booking data and making inferences and verifications based on that data.

[0104] (2) Variable transit points should not generate too many detours. This can be achieved by implementing a shrinking hierarchy (CH) algorithm. In this algorithm, nodes are first sorted by "importance". A "hierarchy" is then generated by iteratively "shrinking" the least important nodes. Shrinking a node (e.g., node u) means replacing the shortest path through the node with a shortcut (e.g., see the following description). Fig. 10A ). A high importance indicates that the corresponding street segment is part of many shortest paths compared to the number of street segments it is connected to. In other words, the route of a journey is more likely to pass through some of such street segments than the rest of the network. This approach captures both the accessibility criterion and the least detour criterion. An example of the CH algorithm output is described further below. Fig. 10B Shown in.

[0105] In addition to fixed transfer points, the implementation of variable transfer points in various embodiments can also open up more routing possibilities, which can then increase the chances that one or more optimal trip options or routes are recommended. Further, variable transfer points can be determined based on accessibility (e.g., based on historical booking data) and / or fewer detours (e.g., through a contraction hierarchy algorithm).

[0106] like Figure 4 As shown in the example of , the resulting network provides or encodes possible multimodal travel options or routes. However, there may be situations where not all generated travel options are optimal. Figure 5A An example showing a possible optimal multimodal path (depicted by multiple arrows) from the upper right node 560 to the lower left node 562 is shown. Figure 5A Different types of arrows (solid arrows, dashed arrows, etc.) are provided in FIG. 5 to represent different modes of transportation, thereby showing that the transportation from the upper right node 560 passes through multiple different nodes (in Figure 5A There are various possible multi-modal paths / options to reach the lower left node 562. As will be further described below Figure 5B As shown, each path combination from node 560 to node 562 may achieve different performance goals in terms of time and fare.

[0107] For Figure 5AFor each multimodal path or route generated in , its associated time and fare can be determined or calculated. The multimodal path can be projected onto the 2D space of time and fare by taking the normalized value of time (f1) and the normalized value of fare (f2) and plotting them in the 2D space of time and fare. Figure 5B In the 2D space diagram shown, Figure 5B Each point in (open and closed circles) represents a generated multimodal trip option. Points in the shaded area (represented by closed circles) represent dominated (i.e., suboptimal multimodal trip options or routes) multimodal trip options, while points at the leading edge of the shaded area (represented by open circles) represent Pareto optimal (excellent or non-dominated) multimodal trip options.

[0108] The number of recommended optimal multimodal travel options can be controlled based on the ε-dominance method, such as Figure 5B As shown. Figure 5B Various ε resolution values ​​are presented in , to illustrate that different resolutions provide different numbers of Pareto optimal multimodal routes. As non-limiting examples, an ε resolution of 1 may provide one Pareto optimal trip option or route, an ε resolution of 0.25 may provide two Pareto optimal trip options, and an ε resolution of 0.2 may provide three Pareto optimal trip options. The number of Pareto optimal trip options or routes presented to a user or passenger may be controlled by adjusting the ε resolution value. Figure 5B As shown, the number of optimal travel options decreases as the ε resolution increases.

[0109] One feature of a multimodal system is to provide more options to users based on their preferences. For example, if you decide to provide passengers with five optimal itinerary options to choose from, you can set the ε resolution value to 0.1. Figure 5B In FIG. 1 , for ease of reference, for the graph corresponding to an ε resolution of 0.1, the five Pareto optimal itinerary options represented by open circles are labeled “1” to “5”, respectively. For a very budget-conscious user or passenger, the user may select itinerary option “5”, while another very time-conscious user may select itinerary option “1”. Further, there are three other itinerary options (i.e., “2”, “3”, and “4”) in between for passengers to choose to meet their respective budget and / or duration requirements.

[0110] Non-limiting exemplary apparatus and methods will now be described.

[0111] Figure 6A block diagram of a multimodal (MM) journey recommender system 662 is shown. The recommender system 662 may be part of a communication server device. The MM system 662 may include one or more modules or engines, including but not limited to a multimodal network generation engine 664, a transit point ranking engine 666, a predictive pricing engine 668, a time-dependent route planning engine 670, a time-independent route planning engine 672, and a multi-objective shortest path engine 674. There may be communication between the multimodal network generation engine 664 and each of the transit point ranking engine 666, the predictive pricing engine 668, the time-dependent route planning engine 670, the time-independent route planning engine 672, and the multi-objective shortest path engine 674. Figure 6 The numbers "1" to "4" shown correspond to the respective steps described below.

[0112] 1. A passenger creates a booking request 660 that specifies a pick-up point (origin; O), a drop-off point (destination; D), and a departure time (T). Accordingly, there may be user request data including a data field indicating the origin location (O) and a data field indicating the destination location (D). The user request data may also include a data field indicating the departure time (T).

[0113] 2. MM system 662 receives request 660, and multimodal network generation engine 664 retrieves the multimodal network by calling transit point ranking engine 666 (see e.g. Figure 4 ) to initiate its process. The transit point ranking engine 666 is called to obtain a list of time-independent transit points with lower rise values. The time-dependent route planning engine 670 can also be called to obtain a list of time-dependent transit points.

[0114] 3. The multi-mode network generation engine 664 calls the predictive pricing engine 668, the time-dependent route planning engine 670, and the time-independent route planning engine 672 to populate the links (see e.g. Figure 4 ) and parameterizes it with the criteria of interest (e.g., duration of a trip interval or leg that defines a portion of the transit data, fare of the trip interval, number of transfers). At step (2), the time-dependent route planning engine 670 may return only a list of time-dependent transit points. At step (3), the time-dependent route planning engine 670 may also return the links between the transit points and their corresponding parameters (duration, fare, and number of transfers).

[0115] 4. The multimodal network generation engine 664 passes the generated multimodal network to the multi-objective shortest path engine 674 to identify Pareto optimal multimodal travel options or routes, which are then passed to the passengers.

[0116] Fig. 7A A flow chart 750 illustrating a method for generating multi-modal trip options (or routes) is shown.

[0117] At 752, a pick-up point (O), a drop-off point (D), and a pick-up time (T) are obtained based on a user request.

[0118] At 754, variable transfer points are determined or selected to be included in the multimodal network for the trip from O to D. Data corresponding to the variable transfer points may be provided in corresponding variable transfer point data fields.

[0119] At 756, fixed transfer points are determined or selected to be included in the multimodal network for the trip from O to D. Data corresponding to the fixed transfer points may be provided in corresponding fixed transfer point data fields.

[0120] At 758, one or more links are added to each of the determined variable and fixed transit points based on the defined framework (including but not limited to "variable-fixed-variable" or "variable-variable"). The fare (or cost), duration, and number of transfers may be determined for each link to define transit data.

[0121] At 760, a Pareto optimal multimodal journey segment or route may be determined taking into account cost, time, and number of transfers (e.g., by a multi-objective shortest path (MOSP) algorithm). This may mean that (all) possible links added at 758 may be evaluated based on Pareto optimality of cost, time, and number of transfers. Fig. 8A and Figure 8B More details are described further.

[0122] At 762, multi-modal travel options (or routes) are generated.

[0123] Figure 7B A flow chart 770 illustrating a method for determining a variable transit point (or point of interest, POI) is shown.

[0124] At 772, an initial list of variable transit points is retrieved (eg, via a collapse hierarchy algorithm).

[0125] At 774, a further list having variable transfer points closest to the trip or route from O to D is selected from the initial list.

[0126] At 776, the time to arrive at the corresponding variable transfer point can be estimated.

[0127] At 778, a bump-up multiplier value may be estimated based on the location of the corresponding variable transfer point and the estimated arrival time.

[0128] At 780 , the variable transit points may be ranked and a defined number n of variable transit points having the lowest upside multiplier value(s) may be selected.

[0129] At 782, desired variable transit points are selected for the multimodal network.

[0130] Figure 7C A flow chart 790 illustrating a method for determining a fixed transit point (or point of interest, POI) is shown.

[0131] At 792 , a defined number n1 of fixed transit points closest to O and a defined number n2 of fixed transit points closest to D may be determined or obtained.

[0132] At 794, a public transportation service or schedule-based service is generated from each fixed transfer point near O to each fixed transfer point near D (eg, via a connection scanning algorithm (CSA)).

[0133] At 796, desired variable transit points are selected for the multimodal network.

[0134] Pareto optimal multi-modal journey intervals or routes can be generated based on a multi-objective shortest path algorithm as follows:

[0135] Fig. 8A An example of a multimodal network 860a as an input for determining a Pareto optimal multimodal trip option from an origin (O) represented by node "0" (862a) to a destination (D) represented by node "1" (864a) is shown. As a non-limiting example, the multimodal network 860a includes a plurality of journey intervals (links), such as 866a, 867a, 868a, 869a, 870a, 871a, 872a, 873a, and a plurality of transfer points (represented by nodes "2" through "10"), including fixed transfer points (e.g., node "2" 874a) and variable transfer points (e.g., node "7" 876a). The multimodal network 860a provides a plurality of trip options from the origin 862a to the destination 864a, such as the trip options depicted by the dashed arrow 878a via the transfer point 876a and the journey intervals 869a, 870a.

[0136] The multimodal network 860a may be "G(V, E, W)", which includes vertices (V) (or nodes), edges (E) (or links), and corresponding weights / objective functions (W). The objective functions considered may include duration (shown in minutes), fares (US dollars), and number of transfers (XT) defined for transfer data for the corresponding mode of transportation.

[0137] Figure 8B shows the use of a multi-mode network 860a ( Fig. 8A ) as input and a Pareto optimal multimodal trip option as output. Figure 8B , thinner lines represent non-Pareto optimal journey intervals (eg, journey interval 870a), while thicker lines represent Pareto optimal journey intervals (eg, journey interval 873a).

[0138] Multi-mode network 860b shows a list of Pareto optimal routes. A route is Pareto optimal if there is no other route that is better with respect to all three objective functions described above.

[0139] The procedures involved may include the following:

[0140] -u i ← the initial state of u (referring to the state of the array of values ​​of the three objective functions considered).

[0141] -will u i Add to the set of non-dominated sets U of (a route is Pareto optimal / non-dominated if there is no other route that is better in all three objective functions).

[0142] -Put the initial state in the priority queue PQ.

[0143] -When PQ is not empty:

[0144] ○p←pop the state with the highest priority (the priorities are sorted lexicographically by their objective functions).

[0145] ○ Iterate over the neighboring nodes of p's node and generate their states.

[0146] ■If the generated state l of neighboring node r is Pareto optimal for r's current set of non-dominated states:

[0147] ●Add l to the set of non-dominated states of r.

[0148] ●Add l to PQ.

[0149] - Returns the set of non-dominated states of u.

[0150] Fig. 9 Exemplary data structures and their corresponding purposes that may be employed in various embodiments are shown.

[0151] Various embodiments may provide improvements over known systems and methods.

[0152] 1. Limited types of multimodal journeys

[0153] The known systems provide journeys of the form "variable + fixed", "fixed + variable", while various embodiments can in addition provide journeys of the form "variable + variable", "variable + fixed + variable", etc. This means that the known systems have only one type of transfer points (i.e., fixed transfer points), while various embodiments can consider another type of transfer points (i.e., variable transfer points).

[0154] The effect of these additional forms of route planning will become apparent when dynamic fares / availability are considered (related to "escalation risk" and "allocation risk" described further below at later points).

[0155] Variable transfer points can link two variable journey intervals or routes. Typically, fixed transfer points correspond to places that provide fixed or schedule-based transportation modes (e.g., train stations, bus stations, or ferry terminals, etc.). On the other hand, variable transfer points are not restricted by the existence of fixed services. Further, it is preferred that the variable transfer points are accessible and suitable for passengers to board or alight. It is desirable that the variable transfer points produce the least detour. Although accessibility can be assessed and verified through historical bookings, it may not be possible to simply check the least detour problem using historical bookings. In this regard, the concept of importance can be used to accelerate the shortest distance / time on the road network query.

[0156] For efficient route planning on a road network, a contraction hierarchy (CH) algorithm can be employed that maintains a ranking of compressed street segments of a road network. A high importance indicates that the corresponding street segment is part of many shortest paths compared to the number of street segments it is connected to. In other words, the route of a journey is more likely to pass through some of such street segments than the rest of the network. This concept captures both the accessibility criterion and the least detour criterion.

[0157] refer to Fig. 10A , it can be considered that node u 1060 is not as important as node v 1062 and node w 1064. Therefore, node u 1060 can be collapsed with a shortcut 1066 linking important nodes v 1062 and w 1064. Each of the numbers "3", "4", and "7" represents an edge weight, which corresponds to the distance / duration from one point to another. During the collapse of the hierarchy, the original weights are maintained by summing their collapsed versions.

[0158] As an illustrative, non-limiting example, Fig. 10B The top 100 nodes (potentially variable transit points) identified for a portion of the city of Jakarta, Indonesia are shown. These nodes are Fig. 10B, where the marks are 100 representative POIs (points of interest) of important streets in Jakarta. In other words, according to CH, the variable transit nodes along the corresponding streets are potentially more sufficient.

[0159] 2. Risk of rising prices

[0160] Since subsequent legs of a multimodal journey may occur in the future, a prediction of the corresponding fares may be required if the fare is to be properly or correctly estimated. Known systems do not address this issue. Various embodiments attempt to handle this risk based on historical data, as follows:

[0161] (a) Predictive ranking of transit points: A machine learning model is built to rank transit points along the route from O to D in real time in terms of supply, upside, etc. This can be considered the first step in eliminating transit points with too high upside risk for consideration.

[0162] (b) Predictive pricing for journey segments or trips: After filtering out high-risk transit points, the fares for one or more subsequent journey segments that may be prone to increase can be estimated.

[0163] 3. Allocate risk

[0164] Since subsequent legs of a multimodal journey may occur in the future, it may be necessary to predict the corresponding (driver) supply conditions. Similar to the risk of rising, known systems do not address this issue. However, various embodiments can handle this risk in a similar way to the method used for rising risk. This risk can be handled based on a prediction model of the transit point (POI) and the estimated price / supply conditions.

[0165] 4. Efficient network maintenance and query

[0166] Various embodiments separately maintain different types of networks—road networks covered by variable transport modes / services and transit networks covered by fixed transport modes / services—to generate a multimodal network. This approach can achieve one or more of the following:

[0167] ●The ability to use a corresponding or specialized routing algorithm for each network, for example, Contraction Hierarchy (CH) for time-independent; Connection Scanning Algorithm (CSA) for time-dependent.

[0168] ● Easy to inject real-time updates on a time-dependent network. Since the time-dependent network is maintained separately, it is simpler to consume a stream of real-time updates to modify the running time-dependent network. Examples of such updates may include train delays / disruptions that may affect the recommended routes or journey intervals. Although updates can be provided to the time-independent network, these updates may not have any effect on the recommended routes or journey intervals. Such updates may be for the purpose of tracking the real-time location of the transport vehicles / vehicles of the ride-hailing transportation service so that the user or passenger can know where they are.

[0169] ●Easy to expand and maintain.

[0170] By establishing an efficient modular network between a time-dependent (transit) network and a time-independent (road) network, one or more dynamically variable transit points can be determined or created by injecting real-time updates on the time-dependent network. As a non-limiting example, during a train breakdown, the demand for taxi services in the surrounding area may increase, which may subsequently increase the upside value of the area. In this case, the transit point ranking engine is less likely to select the variable transit point. As described herein, the variable transit point can be determined in real time based on one or more of the following: connectivity and fewer detours (CH algorithm), driver supply availability (allocation risk), and price competitiveness (upside risk).

[0171] Further, by having the described real-time capabilities in various embodiments, a user does not necessarily need to make advance reservations for an entire multimodal trip or journey. In this regard, in various embodiments, the status of a trip can be tracked and a user can be prompted when they are near or approaching the end of a trip segment they are on to warn the user to make reservations for the next trip segment.

[0172] As described above, an apparatus, method, and system are provided for recommending a multimodal itinerary or journey by generating multimodal journey options for a user / passenger attempting to travel from an origin (O) to a destination (D) ("O→D"). Competitive (or optimal) multimodal journey options may also be identified. A multimodal itinerary may include two or more journey intervals that constitute the O→D itinerary, wherein the itinerary may be served by different transportation types / modes in different journey intervals—for example, on-demand / variable (or time-independent) services (e.g., taxis, ride-sharing, taxi-hailing, bicycle sharing platforms / schemes), and schedule-based / fixed (or schedule- or time-dependent) services (e.g., MRT, subway, train, bus, ferry). For example, an itinerary may include a combination of on-demand services, or a combination of fixed services, or a combination of (multiple) on-demand services and (multiple) fixed services.

[0173] The two networks - the road network and the transit network - are maintained separately, so that a multimodal network can be obtained using information from both the road network and the transit network. "Road network" refers to a system of interconnected nodes (i.e., roads / intersections) ("variable transit points") in which the road network in a multimodal system is covered by on-demand / variable transportation services. "Transit network" refers to a system of interconnected nodes (i.e., designated stops) ("fixed transit points") in which the transit network in a multimodal system is covered by fixed / schedule-based services. By keeping the road network and the transit network separate, the most appropriate route planning algorithm can be applied to each different network, such as a contracting hierarchy route planning algorithm or a connection scanning algorithm. In addition, real-time updates can be provided to either network separately.

[0174] The multimodal network may provide different transfer points for various trip options, including "variable transfer points" that represent the beginning (or end) of a variable / on-demand trip segment and "fixed transfer points" that represent the beginning (or end) of a fixed / schedule-based service. Transfer points may be selected to minimize detours in a multimodal trip compared to a unimodal O→D trip, minimize the difference between predicted and actual fares, etc. The multimodal network may also recommend transfer points with a greater supply (i.e., drivers) to the user for subsequent on-demand / variable trips, thereby maximizing allocation.

[0175] Based on the resulting multimodal network, an optimal multimodal itinerary from O→D can be identified based on the user's preference(s). The optimal multimodal itinerary options can be determined using "Pareto efficiency" to provide multiple Pareto optimal itinerary options for the user to choose from. This helps ensure that a user who chooses a itinerary option based on his preference for one parameter (e.g., cost) does not lose too much (in the best possible way) in terms of other(s) parameters (e.g., time and / or convenience). The concept of "ε dominance" can be used for optimization to limit / control the number of optimal multimodal itinerary options to be recommended to or available to the user.

[0176] The system may also determine, based on historical data, transit points in the multimodal network that may have a high risk of pricing increases and remove such transit points from any recommended multimodal itinerary options.

[0177] It should be understood that various embodiments can be adopted to cover more applications, and these embodiments can be extended to include other modes of transportation, including but not limited to bicycles, ferries, and minivans. Various embodiments can also be used to adjust supply and demand, and potentially achieve consistent pricing for services.

[0178] Also provided are: a computer program product having instructions for implementing the method for managing transportation-related service requests as described herein; a computer program having instructions for implementing the method for managing transportation-related service requests; and a non-transitory storage medium storing instructions that, when executed by a processor, cause the processor to perform the method for managing transportation-related service requests.

[0179] It should be understood that the present invention has been described by way of example only. Various modifications may be made to the techniques described herein without departing from the spirit and scope of the appended claims. The disclosed techniques include techniques that may be provided in an independent manner or in combination with one another. Therefore, features described with respect to one technique may also be presented in combination with another technique.

Claims

1. A communication server device for managing transportation-related service requests, comprising a processor and a memory, the communication server device being configured to execute instructions stored in the memory under the control of the processor to: In response to receiving user request data including a data field indicating an origin location and a data field indicating a destination location, Generate a data record including a plurality of transit point data fields, the plurality of transit point data fields having data corresponding to a plurality of transit points from the origin location to the destination location, the plurality of transit point data fields including a variable transit point data field, the variable transit point data field having data corresponding to a variable transit point, wherein: The location of the variable transfer point is variable and is determined based on data associated with at least one transportation network-related parameter; generating, in the data record, a plurality of journey interval data fields defining corresponding plurality of journey intervals for navigation directions from the origin location to the destination location; and Wherein, for each journey interval data field, the communication server device is further configured to associate the journey interval data field with a corresponding transit point data field among the plurality of transit point data fields, and is further configured to determine a corresponding transportation mode for the corresponding journey interval based on data of the associated transit point data field, and generate transit data regarding the corresponding transportation mode; wherein the corresponding transportation mode for the trip interval data field associated with the variable transfer point data field comprises a taxi transportation mode, the data associated with the at least one transportation network-related parameter corresponds to a fare increase-related parameter, and Wherein, the communication server device is further configured as: In the data record, a plurality of initial variable transfer point data fields are generated for the corresponding plurality of initial variable transfer points from the starting position to the destination position; determining, for each of the plurality of initial variable transfer point data fields, a value for the fare increase related parameter; and If the value of an initial variable transfer point data field in the plurality of initial variable transfer point data fields is greater than a threshold value indicating a high risk of fare increase, disregarding the initial variable transfer point corresponding to the initial variable transfer point data field; and If the value of an initial variable transit point data field in the plurality of initial variable transit point data fields is less than the threshold, the initial variable transit point corresponding to the initial variable transit point data field is maintained as a candidate for the variable transit point, The road network and the transit network are stored separately in the memory so that different route planning algorithms can be applied to the road network and the transit network.

2. The communication server device according to claim 1, in, generating the plurality of journey interval data fields and the plurality of transfer point data fields to define a plurality of travel options from the origin location to the destination location, Each of the plurality of itinerary options is defined by at least two of the plurality of itinerary interval data fields, and The at least two journey interval data fields are corresponding journey intervals defining the navigation direction of a single journey starting from the starting position and ending at the destination position.

3. The communication server device according to claim 2, wherein: The plurality of trip options include at least one multi-modal trip option.

4. The communication server device according to claim 2 or 3, wherein: The plurality of transfer point data fields include a plurality of variable transfer point data fields, each variable transfer point data field of the plurality of variable transfer point data fields having data corresponding to a corresponding variable transfer point, wherein a position of the corresponding variable transfer point is changeable and is determined based on data associated with the at least one transportation network-related parameter.

5. The communication server device according to claim 4, wherein: Each variable transit point data field is associated with a trip interval data field of the at least two trip interval data fields of a corresponding trip option of the plurality of trip options.

6. The communication server device according to claim 2 or 3, wherein: The communication server device is further configured to identify one or more Pareto optimal trip options from the plurality of trip options based on the transfer data corresponding to the at least two trip interval data fields defining each trip option.

7. The communication server device according to claim 6, wherein: The communication server device is further configured to control a number of Pareto optimal travel options to be identified based on the defined epsilon resolution value.

8. The communication server device according to claim 1, wherein: The plurality of transit point data fields and the plurality of trip interval data fields are generated using data corresponding to the road network and the transit network.

9. The communication server device according to claim 8, wherein: The communication server device is also configured to provide data updates to at least one of the road network or the transit network in real time.

10. The communication server device according to claim 1, wherein: The corresponding transportation mode for the trip interval data field associated with the variable transfer point data field includes a carpool transportation mode.

11. The communication server device according to claim 1, wherein: The data associated with the at least one transportation network-related parameter further corresponds to at least one of the following: Driver Supply, accessibility to the user, or Detour related parameters.

12. The communication server device according to claim 11, in, The data associated with the at least one transportation network-related parameter corresponds to the detour-related parameter, and Wherein, the communication server device is further configured as: In the data record, a plurality of initial variable transfer point data fields are generated for the corresponding plurality of initial variable transfer points from the starting position to the destination position; for each of the plurality of initially variable transition point data fields, determining a value for the detour-related parameter, and If the value of an initial variable transit point data field of the plurality of initial variable transit point data fields is greater than a threshold value indicating least detour, maintaining the initial variable transit point corresponding to the initial variable transit point data field as a candidate for the variable transit point, and If the value of an initial variable transit point data field of the plurality of initial variable transit point data fields is less than the threshold, the initial variable transit point corresponding to the initial variable transit point data field is ignored.

13. The communication server device according to claim 1, wherein: The communication server device is also configured to: updating, in a journey interval data field of the plurality of journey interval data fields, the user's travel progress through the corresponding journey interval; and A warning signal is provided to the user via the user's communication device before the corresponding journey interval ends.

14. A method performed in a communication server device for managing transportation-related service requests, the method comprising, under the control of a processor of the communication server device: In response to receiving user request data including a data field indicating an origin location and a data field indicating a destination location, Generate a data record including a plurality of transit point data fields, the plurality of transit point data fields having data corresponding to a plurality of transit points from the origin location to the destination location, the plurality of transit point data fields including a variable transit point data field, the variable transit point data field having data corresponding to a variable transit point, wherein: The location of the variable transfer point is variable and is determined based on data associated with at least one transportation network-related parameter; generating, in the data record, a plurality of journey interval data fields defining corresponding plurality of journey intervals for navigation directions from the origin location to the destination location; and wherein, for each journey interval data field, the journey interval data field is associated with a corresponding transit point data field in the plurality of transit point data fields, and further, a corresponding transportation mode for the corresponding journey interval is determined based on data of the associated transit point data field, and transit data about the corresponding transportation mode is generated; wherein the corresponding transportation mode for the trip interval data field associated with the variable transfer point data field comprises a taxi transportation mode, the data associated with the at least one transportation network-related parameter corresponds to a fare increase-related parameter, and Wherein, the communication server device is further configured as: In the data record, a plurality of initial variable transfer point data fields are generated for the corresponding plurality of initial variable transfer points from the starting position to the destination position; determining, for each of the plurality of initial variable transfer point data fields, a value for the fare increase related parameter; and If the value of an initial variable transfer point data field in the plurality of initial variable transfer point data fields is greater than a threshold value indicating a high risk of fare increase, disregarding the initial variable transfer point corresponding to the initial variable transfer point data field; and If the value of an initial variable transit point data field in the plurality of initial variable transit point data fields is less than the threshold, the initial variable transit point corresponding to the initial variable transit point data field is maintained as a candidate for the variable transit point; The road network and the transit network are stored separately in the memory so that different route planning algorithms can be applied to the road network and the transit network.

15. The method of claim 14, in, generating the plurality of journey interval data fields and the plurality of transfer point data fields to define a plurality of travel options from the origin location to the destination location, Each of the plurality of itinerary options is defined by at least two of the plurality of itinerary interval data fields, and The at least two journey interval data fields are corresponding journey intervals defining the navigation direction of a single journey starting from the starting position and ending at the destination position.

16. The method of claim 15, wherein: The plurality of trip options include at least one multi-modal trip option.

17. The method according to claim 15 or 16, wherein: The plurality of transfer point data fields include a plurality of variable transfer point data fields, each of the plurality of variable transfer point data fields having data corresponding to a corresponding variable transfer point, wherein a position of the variable transfer point is changeable and is determined based on data associated with the at least one transportation network-related parameter.

18. The method of claim 17, wherein: Each variable transit point data field is associated with a trip interval data field of the at least two trip interval data fields of a corresponding trip option of the plurality of trip options.

19. The method of claim 15 or 16, further comprising identifying one or more Pareto optimal trip options from the plurality of trip options based on the transfer data corresponding to the at least two trip interval data fields defining each trip option.

20. The method of claim 19, further comprising controlling a number of Pareto optimal trip options to be identified based on the defined epsilon resolution value.

21. The method of claim 14, wherein: The plurality of transit point data fields and the plurality of trip interval data fields are generated from a road network and a transit network that are maintained separately.

22. The method of claim 21, further comprising providing data updates to at least one of the road network or the transit network in real time.

23. The method of claim 14, wherein: The corresponding transportation mode for the trip interval data field associated with the variable transfer point data field includes a carpool transportation mode.

24. The method of claim 14, wherein: The data associated with the at least one transportation network-related parameter further corresponds to at least one of the following: Driver Supply, accessibility to the user, or Detour related parameters.

25. The method of claim 24, in, The data associated with the at least one transportation network-related parameter corresponds to the detour-related parameter, and The method further includes: In the data record, a plurality of initial variable transfer point data fields are generated for the corresponding plurality of initial variable transfer points from the starting position to the destination position; determining, for each of the plurality of initially variable transition point data fields, a value for the detour-related parameter, and If the value of an initial variable transit point data field of the plurality of initial variable transit point data fields is greater than a threshold value indicating least detour, maintaining the initial variable transit point corresponding to the initial variable transit point data field as a candidate for the variable transit point, and If the value of an initial variable transit point data field of the plurality of initial variable transit point data fields is less than the threshold, the initial variable transit point corresponding to the initial variable transit point data field is ignored.

26. The method of claim 14, further comprising: updating, in a trip interval data field of the plurality of trip interval data fields, the user's travel progress through the corresponding trip interval; as well as A warning signal is provided to the user via the user's communication device before the corresponding journey interval ends.

27. A computer program product comprising instructions for implementing the method of any one of claims 14 to 26.

28. A computer program comprising instructions for implementing the method of any one of claims 14 to 26.

29. A non-transitory storage medium storing instructions which, when executed by a processor, cause the processor to perform the method of any one of claims 14 to 26.

30. A communication system for managing transportation-related service requests, the communication system comprising a communication server apparatus, at least one user communication device, and a communication network device operable to enable the communication server apparatus and the at least one user communication device to establish communication with each other therethrough, in, The at least one user communication device comprises a first processor and a first memory, the at least one user communication device being configured to execute a first instruction stored in the first memory under the control of the first processor so as to: In response to receiving first request data including a data field indicating an origin location and a data field indicating a destination location, generating data corresponding to the origin location and the destination location; and transmitting the data to be received by the communication server device for processing; and And wherein the communication server device includes a second processor and a second memory, and the communication server device is configured to execute a second instruction stored in the second memory under the control of the second processor so as to: In response to receiving second request data indicative of data transmitted by the at least one user communication device, generating a data record including a plurality of transit point data fields having data of a corresponding plurality of transit points from the origin location to the destination location, the plurality of transit point data fields including a variable transit point data field having data corresponding to a variable transit point, wherein a position of the variable transit point is variable and is determined based on data associated with at least one transportation network-related parameter; generating, in the data record, a plurality of journey interval data fields defining corresponding plurality of journey intervals for navigation directions from the origin location to the destination location; wherein, for each journey interval data field, the communication server device is further configured to associate the journey interval data field with a corresponding transit point data field among the plurality of transit point data fields, and is further configured to determine a corresponding transportation mode for the corresponding journey interval based on data of the associated transit point data field, and generate transit data regarding the corresponding transportation mode; and transmitting data corresponding to the plurality of journey intervals, and for each journey interval in the plurality of journey intervals, transmitting data corresponding to a corresponding transit point associated with the journey interval, data corresponding to a corresponding transportation mode for the journey interval, and the transit data regarding the corresponding transportation mode, for receipt by the at least one user communication device; wherein the corresponding transportation mode for the trip interval data field associated with the variable transfer point data field comprises a taxi transportation mode, the data associated with the at least one transportation network-related parameter corresponds to a fare increase-related parameter, and Wherein, the communication server device is further configured as: In the data record, a plurality of initial variable transfer point data fields are generated for the corresponding plurality of initial variable transfer points from the starting position to the destination position; determining, for each of the plurality of initial variable transfer point data fields, a value for the fare increase related parameter; and If the value of an initial variable transfer point data field in the plurality of initial variable transfer point data fields is greater than a threshold value indicating a high risk of fare increase, disregarding the initial variable transfer point corresponding to the initial variable transfer point data field; and If the value of an initial variable transit point data field in the plurality of initial variable transit point data fields is less than the threshold, the initial variable transit point corresponding to the initial variable transit point data field is maintained as a candidate for the variable transit point; The road network and the transit network are stored separately in the second memory so that different route planning algorithms can be applied to the road network and the transit network.

Images