Transaction flow management based on operational failures on MaaS platforms

Abstract

A system and method for transaction flow management are provided. The system includes a proxy node device, which collects operation information associated with multiple nodes of a MaaS network, and determines an operation failure associated with one or more nodes in the multiple nodes based on the collected operation information. The one or more nodes process a ticket transaction associated with a first travel plan in a series of travel plans included in a MaaS mobility service. The proxy node device selects a first message routing strategy based on the determined operation failure, and receives a transaction message associated with the first travel plan from a first node in the first multiple nodes based on the first message routing strategy. The proxy node device routes the received transaction message to a second node of the same or different MaaS network based on the first message routing strategy.

Description

[0001] CROSS-REFERENCE / INCORPORATION BY RELATED APPLICATIONS

[0002] none Technical Field

[0003] Various embodiments of the present disclosure relate to Mobility as a Service (MaaS) and distributed ledger technology. More specifically, various embodiments of the present disclosure relate to systems and methods for transaction flow management based on operational failures on a MaaS platform. Background Art

[0004] In a traditional Mobility as a Service (MaaS) platform, multiple mobility providers may provide their services through an infrastructure that may be based on a closed platform. Each such mobility provider may have a separate ticket processing infrastructure (e.g., ticket gates and point-of-sale (PoS) devices) or separate applications (e.g., ticket booking applications, ticket processing applications, and ride-hailing applications) to create, pay for, or manage trips.

[0005] On such MaaS platforms, many operational issues of ticketing terminals and other nodes of the MaaS platform may not be detected, which may lead to transaction failures and subsequent operational downtime. The time taken to resolve such operational issues and prevent operational bottlenecks in the operation of traditional MaaS platforms may be much longer than required.

[0006] As described in the remainder of this application and with reference to the accompanying figures, limitations and disadvantages of conventional traditional approaches will become apparent to those skilled in the art by comparing the described system with some aspects of the present disclosure. Summary of the invention

[0007] As more fully set forth in the claims, there is provided a system and method for transaction flow management based on operational failures on a Mobility as a Service (MaaS) platform substantially as shown in and / or described in conjunction with at least one of the accompanying drawings.

[0008] These and other features and advantages of the present disclosure will be understood by examining the following detailed description of the disclosure and the accompanying drawings, wherein like reference numerals refer to like parts throughout. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] Figure 1 is a diagram of an exemplary network environment for transaction flow management based on operational failures on a Mobility as a Service (MaaS) network according to an embodiment of the present disclosure.

[0010] Figure 2is a diagram of an exemplary network environment for transaction flow management based on operational failures on nodes of multiple connected Mobility as a Service (MaaS) networks according to an embodiment of the present disclosure.

[0011] Figure 3 is a block diagram of a system for transaction flow management based on operational failures on (one or more) Mobility as a Service (MaaS) networks according to an embodiment of the present disclosure.

[0012] Figure 4A and Figure 4B Flowcharts collectively depict exemplary methods of transaction flow management based on operational failures on a Mobility as a Service (MaaS) network in accordance with embodiments of the present disclosure. DETAILED DESCRIPTION

[0013] Implementations of the following description may be found in the disclosed system and method for transaction flow management based on operational failures on a Mobility as a Service (MaaS) platform. The disclosed system may be part of a joint transportation management system that may facilitate multiple homogeneous or heterogeneous mobility providers and their infrastructure (such as ticket offices, applications, and / or point of sale (PoS) devices) to operate on a MaaS network to provide various mobility services. Each mobility provider may enjoy secure data ownership and may control the coordinated use of related transaction data through a distributed ledger. This may enhance connectivity between various mobility providers.

[0014] Exemplary aspects of the present disclosure provide a system that may include a proxy node device associated with one or more MaaS networks. The proxy node device may be configured to collect operational information (such as network connection status and device operational status) associated with multiple nodes of the MaaS network to determine operational failures associated with one or more of the multiple nodes based on the collected operational information. The one or more nodes may be nodes that can process ticket transactions associated with a travel plan in a series of travel plans included in the MaaS mobility service. For example, the one or more nodes may include a publisher node of the MaaS network, a subscriber node of the MaaS network, or a node of a distributed ledger associated with a subscriber node of the MaaS network. Examples of operational failures of the one or more nodes may include, but are not limited to, network connection failures, operational failures, application errors, overload of message processing capabilities, inability to process ticket transactions due to the absence of a transport vehicle available at the planned travel time, or delayed arrival of a transport vehicle for pick-up or drop-off compared to the planned travel time.

[0015] Based on the determined operational failure, the proxy node device may select a message routing strategy from a set of message routing strategies (such as a condition-based routing strategy or a fault-based routing strategy). Based on the selected message routing strategy, the proxy node device may receive a transaction message associated with the travel plan from a first node among multiple nodes of the MaaS network. The first node may be a publisher node of the MaaS network. Examples of transaction messages may include, but are not limited to, create messages (when creating or issuing a ticket for a mobility service), get-in messages (to start a user's mobility service), and get-out messages (when completing a user's mobility service).

[0016] The proxy node device may be configured to route the received transaction message to a second node among the plurality of nodes of the MaaS network based on the selected message routing strategy. As an example, the second node may be a subscriber node, a node of a distributed ledger associated with the MaaS network, or a backup node in the event that the subscriber node and / or the node of the distributed ledger is operationally faulty. Here, the first node and the second node may be different from the one or more nodes (which may be determined to be operationally faulty).

[0017] Policy-based routing of transaction messages can ensure that the flow of transactions (i.e., the transmission of transaction messages) through the MaaS network is not affected by downtime or any operational issues of any node of the MaaS network (whether a publisher node, a subscriber node, or a node of a distributed ledger). This can improve the uptime of the MaaS network and ensure that transactions can be properly executed by the MaaS network so that users may experience minimal lags or performance issues caused by operational failures of different nodes of the MaaS network.

[0018] In contrast, conventional systems may lack features for runtime monitoring of nodes of a MaaS network and identification of faults associated with nodes of the MaaS network. Failures associated with nodes may be due to various reasons, including but not limited to traffic accidents of vehicles of mobility providers of the MaaS network, malfunction of nodes, or sudden transaction load on nodes. Various problems faced by conventional systems may include limited availability of transport vehicles due to traffic congestion or accidents, and operational failures associated with facilities or information technology (IT) infrastructure of mobility providers. In addition, conventional systems may have interconnectivity issues and do not support features such as ticket transfer and roaming tickets as provided by the present disclosure.

[0019] Figure 1 is a diagram of an exemplary network environment for transaction flow management based on operational failures on a Mobility as a Service (MaaS) network according to an embodiment of the present disclosure. Figure 1, a block diagram of a network environment 100 is shown. The network environment 100 may include a first MaaS network 102, which may be associated with a publish-subscribe model. The first MaaS network 102 may include a first plurality of nodes, which may be configured in layers, such as a client layer 104, a proxy layer 106, and a server layer 108. The first plurality of nodes may include a plurality of publisher nodes 110 in the client layer 104; a proxy node device 112 in the proxy layer 106; and a first plurality of subscriber nodes 116A, 116B, ... 116N, a plurality of mobility provider (MP) nodes 118A, 118B, ... 118N, and a plurality of MaaS nodes 120A, 120B, ... 120N in the server layer 108. The plurality of publisher nodes 110 in the client layer 104 may be configured to communicate with the first plurality of subscriber nodes 116A, 116B, ... 116N through the proxy node device 112.

[0020] although Figure 1 A single proxy node device 112 is shown in FIG. 1 , but the scope of the present disclosure is not limited thereto. In an embodiment, the network environment 100 may include more than one proxy node device 112 without departing from the scope of the present disclosure.

[0021] The plurality of publisher nodes 110 may include a first publisher node 110A, a second publisher node 110B, ... and an Nth publisher node 110N. The first plurality of subscriber nodes 116A, 116B, ... 116N may include a first subscriber node 116A, a second subscriber node 116B, ... and an Nth subscriber node 116N. In an embodiment, each of the plurality of subscriber nodes 116A, 116B, ... 116N may be interfaced with a proxy node device 112 via a plug-in for communication of data (e.g., transaction messages). Each of the first plurality of subscriber nodes 116A, 116B, ... 116N may be associated with a corresponding MP node and a corresponding MaaS node. For example, the first subscriber node 116A may be associated with each of the MP node 118A and the MaaS node 120A. In addition, the second subscriber node 116B may be associated with each of the MP node 118B and the MaaS node 120B. Similarly, the Nth subscriber node 116N may be associated with each of the MP node 118N and the MaaS node 120N.

[0022] The network environment 100 may also include an administrator device 122 that may be operated by an administrator 124 of the first MaaS network 102. In the network environment 100, a user 126 that may interact with the plurality of publisher nodes 110 to utilize mobility services from different mobility providers of the first MaaS network 102 is also represented.

[0023] The first MaaS network 102 may include a network of nodes, such as a first plurality of nodes that may be configured to operate in a client layer 104, a proxy layer 106, and a server layer 108. The first MaaS network 102 may process transactions for MaaS mobility services associated with a plurality of mobility providers. Each such mobility provider may own, lease, or manage a cluster of nodes in each of the client layer 104 and the server layer 108 of the first MaaS network 102. For example, a first publisher node 110A, a first subscriber node 116A, and an MP node 118A may be associated with a first mobility provider. A second publisher node 110B, a second subscriber node 116B, and an MP node 118B may be associated with a second mobility provider that may be different from the first mobility provider.

[0024] MaaS mobility services may be provided by homogeneous mobility providers (such as multiple taxi ride provider companies or multiple railway companies) or heterogeneous mobility providers through a homogeneous set of devices, applications or ticket gates, or a heterogeneous set of ticket gates, applications and point of sale (PoS) devices. MaaS mobility services may be a combination of various service offers by one or more homogeneous or heterogeneous mobility providers. MaaS mobility services may include, for example, train services, bus services, taxi / cab services, subway services, airplane services, fleet services, ride-hailing services, car-sharing services, carpooling services, car rental services, bicycle-sharing services, or a combination thereof.

[0025] Each of the plurality of publisher nodes 110A, 110B, ... 110N may include appropriate logic, circuits, codes and / or interfaces that may be configured to function as a ticket processing client of a mobility service of a corresponding mobility provider. For example, as a ticket processing client, each of the first publisher node 110A, the second publisher node 110B, ... and the Nth publisher node 110N may read, issue, recharge or cancel a ticket to create an event associated with the corresponding mobility service. Based on such events, a transaction message may be transmitted to one or more subscriber nodes of the first MaaS network 102 or other MaaS networks via a proxy node device 112. Examples of publisher nodes may include, but are not limited to, consumer electronic devices with travel plans or reservation applications, ticket readers at ticket gates, ticket booths, point of sale (PoS) devices, mobile POS, ticket vending machines, and smart doors of transportation vehicles that can read tickets to start or end a ride.

[0026] The proxy node device 112 may include appropriate logic, circuitry, code, and / or interfaces that may be configured to route transaction messages from a publisher node (such as the first publisher node 110A) to an appropriate node (such as a subscriber node of the first MaaS network 102 or a backup (or temporary) node (e.g., backup node 114)). The proxy node device 112 may route transaction messages based on a message routing policy, which may be a fault-based routing policy or a condition-based routing policy. The proxy node device 112 may maintain routing information that may establish relationships between publisher-subscriber nodes, different MP-MP nodes, and different MaaS-MaaS nodes. Example implementations of the proxy node device 112 may include, but are not limited to, application servers, cloud servers, mainframe servers, database servers, web servers, or other types of servers.

[0027] The proxy node device 112 can be configured to communicate with each of the multiple publisher nodes 110A, 104B, ... 104N and each of the first multiple subscriber nodes 116A, 116B, ... 116N via an appropriate publish-subscribe network protocol, such as but not limited to a messaging protocol based on Message Queuing Telemetry Transport (MQTT), a messaging protocol based on Advanced Message Queuing Protocol (AMQP), or a messaging framework based on Message Oriented Middleware (MOM).

[0028] The backup node 114 may include appropriate logic, circuitry, code, and / or interfaces that may be configured to back up or temporarily store transaction messages associated with an operationally faulty subscriber node or MP node of the first MaaS network 102. The backup node 114 may be configured to receive transaction messages from a publisher node via a proxy node device 112 on behalf of the operationally faulty subscriber node or MP node, and temporarily store such received transaction messages until the operationally faulty subscriber node or MP node is operationally normal. Once the operationally faulty subscriber node or MP node is operationally normal, the backup node 114 may forward the temporarily stored transaction messages to such subscriber node or MP node. Example implementations of the backup node 114 may include, but are not limited to, a database server, a web server, an edge device, an edge node, a cloud server, a cloud-based server cluster, a workstation, or any computing device with fog or cloud computing capabilities.

[0029] Each of the first plurality of subscriber nodes 116A, 116B, ... 116N may include appropriate logic, circuitry, code, and / or interfaces that may be configured to receive transaction messages from one or more of the plurality of publisher nodes 110A, 110B, ... 110N via the proxy node device 112. In an embodiment, each of the plurality of subscriber nodes 116A, 116B, ... 116N may interface with the proxy node device 112 via a plug-in for communication of data (e.g., transaction messages). Each transaction message may include a topic that may be subscribed to by one or more of the first plurality of subscriber nodes 116A, 116B, ... 116N. Example implementations of subscriber nodes may include, but are not limited to, web servers, edge devices, edge nodes, cloud servers, cloud-based server clusters, workstations, or any computing device with fog or cloud computing capabilities.

[0030] Each of the MP nodes 118A, 118B, ... 118N may include appropriate logic, circuitry, code, and / or interfaces that may be configured to store transaction data associated with a corresponding mobility provider. For example, the MP node 118A may store transaction data associated with a first mobility provider. The transaction data may include a record of trips of a user. Each trip may correspond to a mobility service that the first mobility provider may provide in at least one segment of the journey. Each of the MP nodes 118A, 118B, ... 118N may be referred to as a node of a distributed ledger 118 that may store transaction data of various mobility providers of the first MaaS network 102.

[0031] Each of the MaaS nodes 120A, 120B, ... 120N may include suitable logic, circuitry, code, and / or interfaces that may be configured to store transaction data associated with all mobility providers of the first MaaS network 102. The storage of transaction data associated with each mobility provider may be used to settle transactions for travel between mobility providers that provide mobility services to users. Each of the MaaS nodes 120A, 120B, ... 120N may correspond to a node of the distributed ledger 120 that may store transaction data associated with the first MaaS network 102.

[0032] In an embodiment, at least two nodes of each of the distributed ledger 118 and / or the distributed ledger 120 may store transaction data associated with the MaaS mobility service. The transaction data associated with the MaaS mobility service may be included in a set of state objects, such as an initial state object and an updated version of the initial state object. Each state object may include a smart contract, contract code (or the rules of the transaction agreed upon by the parties to the transaction), and state properties (which may be updated when the transaction data is updated based on a transaction message from a publisher node).

[0033] In at least one embodiment, each of the distributed ledger 118 and the distributed ledger 120 may be a decentralized distributed database system that may maintain an immutable record of data operations or transactions. A set of data operations may be grouped together as a block and may also be linked to a previous block of data operations to form a blockchain. All blocks of data operations may be stored in a decentralized manner, whereby at least two participants or nodes of the distributed ledger 118 and the distributed ledger 120 may store a subset of blocks associated with one or more transactions in which the at least two participants or nodes may participate. In addition, each of the distributed ledger 118 and the distributed ledger 120 may include an operating system (e.g., a Java Virtual Machine (JVM)) that may allow smart contracts to be deployed between multiple parties (e.g., a mobility provider and a MaaS provider of the first MaaS network 102).

[0034] By way of example and not limitation, each of distributed ledger 118 and distributed ledger 120 can be a Corda blockchain, an Ethereum blockchain, or a Hyperledger blockchain. Each of distributed ledger 118 and distributed ledger 120 can store a set of immutable state objects that can be tracked by the corresponding distributed ledger. State objects can include transaction data, such as smart contracts between parties, contract code (rules of the transaction), and content including state properties with certain state values. A smart contract can include a set of conditions under which multiple parties to the smart contract can agree to interact with each other. A smart contract can be run on one or more nodes of a corresponding distributed ledger and can govern transitions between state objects to generate transactions. A smart contract can be written only once, reused for a large number of state objects, and can reference governing legal provisions through cryptographic hashing.

[0035] Each of the distributed ledgers 118 and 120 can use secure cryptographic hashing to identify the parties and data, and also link the state object to the previous version of the state object to further provide a traceability chain. Transactions between a group of participants can be stored on the corresponding distributed ledger so that only the group of participants associated with the transaction can view the transaction. A party associated with a transaction can store the current state object of the transaction in a vault (i.e., a database associated with the corresponding distributed ledger). Another party who is eligible to view or process the transaction (e.g., verify the transaction) can retrieve the current state object of the transaction from the vault. In addition, each state object of the corresponding distributed ledger can include smart contracts between the parties or nodes involved in the associated transaction.

[0036] On each of the distributed ledgers 118 and 120, a participant or node (e.g., MP node 118A and / or MaaS node 120A) can update a transaction by updating the state properties of an input state object to generate an output state object. The updated transaction can thereby create a traceability chain that can be associated with the transaction data. Each of the distributed ledgers 118 and 120 can provide consensus for the updated transaction based on the determination of the validity of the updated transaction and the determination of the uniqueness of the updated transaction. In an embodiment, the participants of the nodes associated with the updated transaction can determine the validity of the updated transaction by independent execution of the smart contract and verification logic associated with the transaction. In addition, the uniqueness of the updated transaction can be determined based on checking that there are no other transactions that have reached consensus by using the same input state object as the current transaction.

[0037] According to an embodiment, each of the distributed ledger 118 and the distributed ledger 120 can be associated with a decentralized application, which can include a client-side interface (front end) and a server-side interface (back end). The decentralized application can be configured to implement a workflow (e.g., Corda flow) to record transactions on the nodes of the corresponding distributed ledger (such as MP node 118A and / or MaaS node 120A). The client-side interface can be hosted on each of the first plurality of subscriber nodes 116A, 116B, ... 116N, and the client-side interface can be configured to be loaded on a client associated with the subscriber node. For example, the client-side interface of the decentralized application can be a remote procedure call (RPC) client that can be configured on each subscriber node. The server-side interface of the decentralized application can run on each node of the distributed ledger 118 and the distributed ledger 120.

[0038] In an embodiment, each of the MP node 118A and the MaaS node 120A may be configured to receive the transaction message via the first subscriber node 116A. The MP node 118A may update the initial state object associated with each of the distributed ledger 118 and the distributed ledger 120 based on the transaction message to output an updated state object. Each of the MP node 118A and the MaaS node 120A may construct a transaction that may include an initial state object having initial transaction data and an updated state object having updated transaction data.

[0039] In operation, the proxy node device 112 may collect operating information associated with the first plurality of nodes of the first MaaS network 102. Examples of the collected operating information may include, but are not limited to, a network connection status and a device operating status of each of the first plurality of nodes.

[0040] In an embodiment, the proxy node device 112 may also collect traffic information associated with a fleet of transport vehicles on the road belonging to one or more mobility providers of the first MaaS network 102. The collected traffic information may include, for example, traffic congestion information, traffic collision information, detour information, information associated with below-average traffic volume, etc. For example, the proxy node device 112 may collect traffic information from an Internet of Things (IoT) sensor that may be deployed on each vehicle of the fleet of transport vehicles on the road. Such sensors may determine the location of the vehicle, the temperature, the number of nearby vehicles, and the number of people currently riding in the vehicle. In some cases, traffic information may be collected through an application programming interface (API) of a data aggregator for traffic information.

[0041] The proxy node device 112 may determine an operational failure associated with one or more nodes (hereinafter referred to as operationally faulty nodes) of the first plurality of nodes based on the collected operational information. Examples of operational failures may include, but are not limited to, network connection failures, operational failures, application errors, overload of message processing capabilities, inability to process ticket transactions due to no transportation vehicles available at the planned travel time or delayed arrival of transportation vehicles for pick-up or drop-off compared to the planned travel time. In an embodiment, the proxy node device 112 may further determine an operational failure associated with an operationally faulty node of the first MaaS network 102 based on the collected traffic information.

[0042] In order to ensure that the transaction flow associated with the node with the operational fault is not affected, appropriate message routing strategies may be needed to handle transactions that are largely dependent on the operation of the node with the operational fault. The proxy node device 112 may select a first message routing strategy from a set of message routing strategies. Such selection may be based on the determined operational fault.

[0043] In an embodiment, the set of message routing policies may include a fault-based routing policy and a condition-based routing policy. Figure 2 Details of such policies are provided in . In such a case, the first message routing may be selected as one or more of a fault-based routing policy and a condition-based routing policy. The selected first message routing policy may specify options that the proxy node device 112 may select and implement in order to process transaction messages associated with an operationally faulty node of the first MaaS network 102. Such operation may facilitate the proxy node device 112 to mitigate the impact of the determined operational fault on the first MaaS network 102.

[0044] In an embodiment, the first message routing strategy may be selected based on whether the operationally faulty node belongs to the client layer 104, the server layer 108, or both the client layer 104 and the server layer 108. If the operationally faulty node includes the proxy node device 112, the entire operation of the first MaaS network may be shut down.

[0045] In another embodiment, the proxy node device 112 can control the administrator device 122 to display information, including but not limited to the determined operational failure of the node with faulty operation and the collected operational information of the first plurality of nodes. The displayed information can also include traffic information associated with a fleet of transport vehicles on the road of one or more mobility providers. Afterwards, the proxy node device 112 can control the administrator device 122 to display a group of user-selectable options based on the displayed information. Each of the group of user-selectable options can correspond to one of the group of message routing strategies. The proxy node device 112 can receive administrator input from the administrator 124 via the administrator device 122. The administrator input can include a selection of a first user-selectable option in the group of user-selectable options. The first message routing strategy can be selected based on the received administrator input.

[0046] In an embodiment, it may be determined whether the operationally faulty nodes of the first MaaS network 102 include an operationally faulty publisher node that cannot publish a transaction message about the first travel plan of the user to the proxy node device 112. If the operationally faulty nodes do not include an operationally faulty publisher node, the proxy node device 112 may receive a transaction message associated with the first travel plan from a first node of the first plurality of nodes of the first MaaS network 102. The first node may be a publisher node (such as the first publisher node 110A) that may be configured to publish a transaction message about the first travel plan to the proxy node device 112.

[0047] If the operationally faulty nodes of the first MaaS network 102 include an operationally faulty publisher node, the proxy node device 112 may select an alternative publisher node (i.e., the first node) of the first MaaS network 102 as a replacement for the operationally faulty publisher node. This selection may be based on the first message routing policy. The alternative publisher node may belong to the first MaaS network 102 (i.e., the first node). Figure 2 In the case of intra-routing strategies as described in Figure 2 , for example, in the case of an inter-routing strategy). For example, if there is an operational failure associated with the first publisher node 110A, the second publisher node 110B may be selected as the first node (i.e., the alternative publisher node). After selection, the second publisher node 110B may publish a transaction message about the first travel plan to the proxy node device 112.

[0048] In an embodiment, an alternative publisher node (such as the second publisher node 110B) can be selected from a cluster of publisher nodes of a mobility provider, which can be the same mobility provider associated with the publisher node that is operationally faulty (such as the first publisher node 110A). For example, such a selection can be made when one of the ticket readers (i.e., the publisher node) of a station fails and a replacement for the failed ticket reader is available. In another embodiment, an alternative publisher node can be selected from a cluster of publisher nodes of another mobility provider, which can be different from the mobility provider of the publisher node that is operationally faulty. For example, such a selection can be made when there is no transportation vehicle of the mobility provider for pick-up at a scheduled time due to traffic congestion or an accident, or when all ticket terminals at a station are undergoing scheduled or unscheduled maintenance.

[0049] The alternative publisher node may generate a transaction message about the user's first travel plan (on behalf of the operationally faulty publisher node), and may send the generated transaction message to the proxy node device 112. Examples of transaction messages may include, but are not limited to, a create message (when creating or issuing a ticket for mobility services), an enter message (to start the user's mobility service), and an exit message (when completing the user's mobility service).

[0050] After receiving the transaction message, the proxy node device 112 may route the received transaction message to a second node in the first plurality of nodes of the first MaaS network 102 based on the selected first message routing policy. The second node may be a subscriber node (such as the first subscriber node 116A) or a backup node 114. The backup node 114 may temporarily store the transaction message if one or more of the first plurality of subscriber nodes 116A, 116B, ... 116N and / or the MP nodes 118A, 118B, ... 118N fail in operation.

[0051] In an embodiment, it may be determined whether the operationally faulty nodes of the first MaaS network 102 include an operationally faulty subscriber node of the first MaaS network 102. If the operationally faulty nodes do not include an operationally faulty subscriber node, the proxy node device 112 may send a transaction message associated with the first travel plan to a subscriber node (i.e., the second node) of the first MaaS network 102. The subscriber node (such as the first subscriber node 116A) may be configured to receive the sent transaction message associated with the first travel plan.

[0052] In an embodiment, if the operationally faulty nodes of the first MaaS network 102 include an operationally faulty subscriber node (such as the first subscriber node 116A), the proxy node device 112 may select an alternate subscriber node (such as the second subscriber node 116B) from the first plurality of nodes of the first MaaS network 102 as the second node. Alternatively, instead of the alternate subscriber node, a backup node 114 of the first MaaS network 102 may be selected as the second node. This selection of the alternate subscriber node or the backup node 114 may be based on the first message routing policy.

[0053] The candidate subscriber node may belong to the first MaaS network 102 (in Figure 2 in the case of internal routing strategies as described in the previous section) or different MaaS networks (e.g. Figure 2 As shown in, for example, Figure 2 In the case of the inter-routing strategy described in ). In an embodiment, an alternative subscriber node can be selected from a subscriber node cluster of a mobility provider, and the mobility provider can be the same as the mobility provider associated with the operationally faulty subscriber node. For example, such a selection can be made when the subscriber node is down due to scheduled or unscheduled maintenance. In another embodiment, the selected alternative subscriber node can be associated with a first mobility provider, and the first mobility provider can be different from a second mobility provider associated with the operationally faulty subscriber node. After the selection, the alternative subscriber node can receive a transaction message about the user's first travel plan on behalf of the operationally faulty subscriber node.

[0054] In an embodiment, it may be determined whether the operationally faulty node includes an operationally faulty node of a distributed ledger (e.g., distributed ledger 118 or distributed ledger 120). If the operationally faulty node includes an operationally faulty node of a distributed ledger (e.g., MP node 118A), the proxy node device 112 may select a backup node 114 as a second node from the first plurality of nodes of the first MaaS network 102. The backup node 114 may be selected based on the selected first message routing policy. After the selection, the proxy node device 112 may route the transaction message from the first node to the backup node 114 for temporary storage until the recovery of the operationally faulty node (e.g., MP node 118A) of the distributed ledger (e.g., distributed ledger 118) is completed.

[0055] In another embodiment, the operationally faulty node may include both the operationally faulty node and the subscriber node of the distributed ledger of the first MaaS network 102. In this case, the proxy node device 112 may select the backup node 114 as the second node from the first plurality of nodes of the first MaaS network 102 based on the selected first message routing policy. After the selection, the proxy node device 112 may route the transaction message from the first node to the backup node 114 for temporary storage until the recovery of the operationally faulty node and the subscriber node of the distributed ledger is completed. After the recovery is completed, the proxy node device 112 or the administrator device 122 may instruct the backup node 114 to reroute the stored transaction message to the operationally faulty subscriber node or the operationally faulty node of the distributed ledger.

[0056] In the described embodiments, the selection of appropriate routes from the client layer 104 and the server layer 108 based on policies can ensure that the transaction flow of transaction messages on the first MaaS network 102 is rarely or almost unaffected by any downtime or any operational failure of the nodes (whether publisher nodes, subscriber nodes, and / or nodes of the distributed ledger) of the first MaaS network 102. This can improve the uptime of the first MaaS network 102 and can ensure that transactions are properly executed by the MaaS network so that users can experience minimal performance issues, which are generally encountered due to operational failures of different nodes of the first MaaS network 102.

[0057] The first subscriber node 116A may receive a transaction message from the proxy node device 112, and may share the transaction message with the MP node 118A and the MaaS node 120A. Each of the MP node 118A and the MaaS node 120A may receive the transaction message, and may perform a transaction associated with the first mobility service based on information associated with the event captured in the received transaction message. In order to perform the transaction, each of the MP node 118A and the MaaS node 120A may retrieve an initial state object, and may update the transaction data included in the first state object based on the received transaction message. The transaction data may be associated with information such as, but not limited to, ticket information, subscription information, payment information, revenue sharing information, or mobility service information. In an embodiment, the transaction data may include metadata that may be used by the MP node or the MaaS node for transaction processing and payment processing. In the case of regional routing (roaming), inter-routing, or intra-routing scenarios, the metadata may include data associated with the calculation of payments associated with the transaction. For example, the metadata may include a reason code (such as an event identifier (ID) or a transaction type ID) to identify the type of message routing strategy used and other details related to the nodes involved in the transaction. In addition, the proxy node device 112 may add details identifying the user 126 associated with the transaction (such as a user ID) in the metadata to support the first MaaS network 102 (and / or a different MaaS network, such as Figure 2 The proxy node device 112 may also add details identifying a user payment plan or user subscription associated with the first MaaS network 102 (eg, user subscription type).

[0058] In an example scenario, a mobility service can be created for a user 126's scheduled travel plan of taking a bus to the airport at 11:00AM, boarding a plane from the airport at 1:00PM, and then taking a taxi from the airport to the hotel at 8:00PM. For a bus ride, when the user 126 starts taking the bus, the publisher node associated with the bus ride provider can send a transaction message to the subscriber node of the bus ride provider. The transaction message can be an incoming message including the details of the trip (such as a pick-up or drop-off location, a pick-up time, etc.), subscription details, or user details. When the user 126 gets off the bus at the end of the trip, the publisher node associated with the bus ride provider can send a transaction message to the subscriber node of the bus ride provider again. The transaction message can be an exit message including travel details (such as travel time, drop-off location, etc.), subscription details, travel bills, or user details. The subscriber node can forward the incoming message or the exit message to its associated nodes of the distributed ledger 118 and the distributed ledger 120. The associated nodes of distributed ledger 118 and distributed ledger 120 may update the initial state object based on the incoming message or the outgoing message to generate a new state object with updated transaction data.

[0059] For example, if the state property of the initial state object includes a total payment amount of 500 U.S. dollars (USD) for the (multi-trip) MaaS mobility service, the updated transaction data of the new state object may include the total payment amount and a bill amount of 10 USD for the trip associated with the bus ride provider. Similarly, for all other trips of the MaaS mobility service (flight and taxi to hotel), the corresponding nodes of the distributed ledger 118 of the flight provider and the taxi provider and the corresponding nodes of the distributed ledger 120 may update the new state object successively in the order in which the user 126 completes the flight trip and the taxi trip. At the end of the last trip, the MP node and the MaaS node of the first MaaS network 102 may handle payment processing and revenue sharing based on the transaction data and metadata associated with the transaction data, as described above.

[0060] In at least one embodiment, the first MaaS network 102 may support open standard specifications for MaaS. In this case, publisher nodes (e.g., ticket readers or sensor devices) of different companies associated with various mobility providers of the first MaaS network 102 may join the first MaaS network 102 as homogeneous publisher nodes. In addition, legacy ticket readers or sensor devices may be connected to the first MaaS network 102 based on full utilization of standard communication protocols such as MQTT or AMQP. By using standard communication protocols, the first MaaS network 102 may provide ticket roaming capabilities to users. For example, a ticket reader of any mobility provider may scan a user's electronic ticket to find MaaS mobility services, and may provide the user with the corresponding mobility services of the mobility provider (regardless of who the issuer of the ticket is) based on seamless and secure access to the first MaaS network 102.

[0061] MaaS mobility services may be provided by homogeneous mobility providers (e.g., multiple taxi ride provider companies) or heterogeneous mobility providers (multimodal mobility providers) through a homogeneous set of devices, applications, or ticket offices of each mobility provider, or a heterogeneous set of ticket offices, applications, and PoS devices. MaaS mobility services may be a combination of various service offers by one or more homogeneous or heterogeneous mobility providers. For example, a ticket office, a ride-hailing app, or a PoS terminal of a MaaS provider may receive a request from a user 126 to create a MaaS mobility service (e.g., a combination of buses, taxis, and flights) via an input. MaaS mobility services may include, for example, train services, bus services, taxi / cab services, subway services, airplane services, fleet services, ride-hailing services, car-sharing services, ride-pooling services, car rental services, bicycle-sharing services, or combinations thereof.

[0062] Each mobility provider may enjoy secure data ownership of transaction data through the distributed ledger 118. Since the first MaaS network 102 is implemented using the distributed ledger 118, each mobility provider may own a node on the distributed ledger 118. The corresponding node of the distributed ledger 118 associated with the mobility provider may store transaction data related to the mobility provider. The corresponding node of the distributed ledger 120 may also store the same transaction data. This may ensure secure ownership of data between the MaaS provider and the mobility provider. This may also enhance connectivity between the various mobility providers. By sharing information technology (IT) infrastructure between mobility providers, the costs associated with owning IT infrastructure for each mobility provider may be lower than when each mobility provider maintains its own closed platform IT infrastructure. For example, Figure 2Transaction flow management based on operational failures on a MaaS network with multiple connections is further described in.

[0063] Figure 2 is a diagram of an exemplary network environment for transaction flow management based on operational failures on nodes of a plurality of connected Mobility as a Service (MaaS) networks according to an embodiment of the present disclosure. Figure 1 To illustrate the elements Figure 2 . refer to Figure 2 , a block diagram of a network environment 200 is shown. The network environment 200 may include a first MaaS network 102 and a second MaaS network 202, each of which may be associated with a publish-subscribe model. Each of the first MaaS network 102 and the second MaaS network 202 may include a plurality of publisher nodes 110A, 110B, ... 110N. The first MaaS network 102 may include a first plurality of subscriber nodes 116A, 116B, ... 116N, and similar to the first MaaS network 102, the second MaaS network 202 may include a second plurality of subscriber nodes 208A, 208B, ... 208N. Each of the plurality of publisher nodes 110A, 110B, . . . 110N, each of the first plurality of subscriber nodes 116A, 116B, . . . 116N, and each of the second plurality of subscriber nodes 208A, 208B, . . . 208N may be communicatively coupled to the smart proxy 206 .

[0064] The second plurality of subscriber nodes 208A, 208B, ... 208N of the second MaaS network 202 may be similar to the first plurality of subscriber nodes 116A, 116B, ... 116N and may include a first subscriber node 208A, a second subscriber node 208B, ... and an Nth subscriber node 208N. Similar to the first MaaS network 102, the first subscriber node 208A may be associated with the MP node 210A and the MaaS node 212A. In addition, the second subscriber node 208B may be associated with the MP node 210B and the MaaS node 212B. Similarly, the Nth subscriber node 208N may be associated with the Nth MP node 210N and the Nth MaaS node 212N.

[0065] Each of the MP nodes 210A, 210B, ... 210N may correspond to a node of the distributed ledger 210 that may store transaction data of a corresponding mobility provider associated with the second MaaS network 202. Each of the MaaS nodes 212A, 212B, ... 212N may correspond to a node of the distributed ledger 212 that may store transaction data of all mobility providers associated with the second MaaS network 202.

[0066] Figure 2 , a user 126 is shown who can interact with a plurality of publisher nodes 110A, 110B, ... 110N to utilize mobility services of different mobility providers associated with one or more MaaS networks, such as the first MaaS network 102 and the second MaaS network 202. The network environment 100 may also include an administrator device 122 that monitors the operation of nodes of the first MaaS network 102 and the second MaaS network 202.

[0067] The network environment 200 may further include a node management device 204 communicatively coupled to the intelligent agent 206. The node management device 204 may include suitable logic, circuitry, code, and / or interfaces that may be configured to initiate recovery of an operationally faulty node of the first MaaS network 102 and / or the second MaaS network 202. Examples of the node management device 204 may include, but are not limited to, a mobile diagnostic computer, a web server, an edge device, an edge node, a cloud server, a cloud-based server cluster, a workstation, or any computing device or system with fog computing capabilities.

[0068] The functionality of the second plurality of subscriber nodes, MP nodes, and MaaS nodes of the second MaaS network 202 may be similar to, for example, Figure 1 The functions of the first plurality of subscriber nodes, MP nodes, and MaaS nodes of the first MaaS network 102 described in . Therefore, for the sake of brevity, the description of these nodes is omitted from the disclosure.

[0069] like Figure 2 As shown in , the intelligent agent 206 can support a set of message routing strategies, such as a condition-based routing strategy 206A and a fault-based routing strategy 206B. The proxy node device 112 can implement one of the condition-based routing strategy 206A and / or the fault-based routing strategy 206B to handle transaction flows from publisher nodes to subscriber nodes and from subscriber nodes to nodes (MP nodes or MaaS nodes) of distributed ledgers. For example, if there is an operational failure on any node of the first MaaS network 102 and the second MaaS network 202, the fault-based routing strategy 206B can be used to select an alternative publisher node, an alternative subscriber node, or a backup node to temporarily store transaction messages.

[0070] In order to efficiently process the transaction flow, the proxy node device 112 may measure the load or overhead associated with the nodes of the first MaaS network 102 and the second MaaS network 202. The condition-based routing strategy 206A may determine an effective strategy to reduce / balance the measured load or overhead associated with the nodes of the first MaaS network 102 and the second MaaS network 202. The condition-based routing strategy 206A may include, but is not limited to, an intra-routing strategy, an inter-routing strategy, an area-based routing strategy, a traffic volume-based routing strategy, and a cost-based routing strategy.

[0071] In an embodiment, the inner routing policy may be a message routing policy based on which the proxy node device 112 may be configured to route transaction messages (received from a publisher node associated with a first mobility provider) to a subscriber node associated with a second mobility provider different from the first mobility provider within the first MaaS network 102. The inner routing policy may specify an option to route transaction messages for a subscriber node of one mobility provider to other subscriber nodes of another mobility provider within the MaaS network. For example, the proxy node device 112 may receive a transaction message from a first publisher node 110A of a first mobility provider. If there is an operational failure associated with a first subscriber node 116A of the same first mobility provider, the proxy node device 112 may route the transaction message received from the first publisher node 110A to a second subscriber node 116B of a second mobility provider (the second mobility provider may be different from the first mobility provider).

[0072] In an embodiment, the inter-routing policy may be a message routing policy based on which the proxy node device 112 may be configured to route a transaction message (received from a publisher node of the first MaaS network 102) to a subscriber node of a second MaaS network 202 that is different from the first MaaS network 102. The inter-routing policy may specify an option to route a transaction message to a subscriber node of a first mobility provider in the first MaaS network 102 to a subscriber node of a different mobility provider in the second MaaS network 202. For example, the proxy node device 112 may receive a transaction message from a first publisher node 110A of the first MaaS network 102. If there is an operational failure associated with the first subscriber node 116A, the proxy node device 112 may route the transaction message received from the first publisher node 110A to a first subscriber node 208A of the second MaaS network 202.

[0073] In an embodiment, the region-based routing policy may be a message routing policy based on which the proxy node device 112 may be configured to route a transaction message from a publisher node of a first MaaS network 102 in a first geographic region to a subscriber node of a first MaaS network 102 or a second MaaS network 202 in a second geographic region different from the first geographic region. The region-based routing policy may specify an option to select a geographic location and route the transaction message to a subscriber node of a mobility provider on a MaaS network associated with the selected geographic location (similar to regional or international roaming). For example, the proxy node device 112 may receive a transaction message from a first publisher node 110A of a first MaaS network 102 in a first geographic region. If there is an operational failure associated with the first subscriber node 116A, the proxy node device 112 may route the transaction message to a first subscriber node 208A of a second MaaS network 202 in a second geographic region (different from the first geographic region). As another example, if the first subscriber node 116A is operationally faulty, the proxy node device 112 may route a transaction message received from the first publisher node 110A (of the first mobility provider) of the first MaaS network 102 to the second subscriber node 116B (of the second mobility provider) of the second MaaS network 202.

[0074] The routing strategy based on traffic volume can specify the option of routing transaction messages to the appropriate subscriber nodes of the same or different mobility providers in the case of peak traffic. Such a situation can be based on the road congestion that the fleet vehicles on the road of one or more mobility providers may experience. The proxy node device 112 can use the routing strategy based on traffic volume to handle a large number of transaction messages during peak traffic. The proxy node device 112 can use the collected traffic information, such as traffic congestion information, flow collision information, detour information, or lower than the average traffic volume information to select the routing strategy based on traffic volume as the first message routing strategy. In an embodiment, when the operation failure includes the publisher node (e.g., the first publisher node 110A) with a fault in operation, due to the lack of transportation vehicles available at the planned travel time or compared with the planned travel time, the transportation vehicle for picking up or dropping off is delayed and cannot process the ticket transaction, the proxy node device 112 can select the routing strategy based on traffic volume.

[0075] The cost-based routing policy may specify options for routing transaction messages based on the cost of different routes between the publisher node and the subscriber node. Here, if network overhead or load is considered at the client layer, proxy layer, and server layer of the MaaS network, the cost of routing the transaction message from the publisher node to the subscriber node may be defined using the time required for the transaction message to reach the subscriber node from the publisher node. In some cases, the cost may be a transaction or ticket cost (e.g., in USD) for routing the transaction message to a subscriber node of a particular mobility provider.

[0076] The proxy node device 112 may select a cost-based routing strategy to route the transaction message from the first publisher node 110A to a subscriber node that incurs the lowest cost (e.g., the smallest time or the shortest route) compared to the remaining available subscriber nodes of the first MaaS network 102 or the second MaaS network 202. For example, the proxy node device 112 may calculate a delay for each message route that includes a path from a publisher node to a subscriber node. The proxy node device 112 may select a route for which the calculated delay is below a threshold, and may route the transaction message to the subscriber node according to the selected route.

[0077] In an example scenario, the proxy node device 112 may select one of the fault-based routing strategies 206B as the first message routing strategy based on an operational fault associated with an operationally faulty node of the first MaaS network 102 or the second MaaS network 202. Such selection may be further based on circumstances such as bursty reception of transaction messages, downtime experienced by a node, roundabout-trouble experienced by a node, or a requirement to balance the load associated with different routings of transaction messages. The circumstances may also include a first situation associated with the joining of a new node, a second situation associated with splitting an existing node into two new nodes, a third situation associated with rerouting transaction messages to a subscriber node of a different MaaS network or a different mobility provider to allow roaming options for a user, or transferring a ticket to an issuer node of a different mobility provider than the mobility provider that issued the ticket.

[0078] In operation, the proxy node device 112 may collect operation information associated with the first plurality of nodes of the first MaaS network 102. The proxy node device 112 may also collect operation information associated with the second plurality of nodes of the second MaaS network 202. Examples of the collected operation information may include, but are not limited to, the network connection status and device operation status of each node in the first plurality of nodes and each node in the second plurality of nodes. The proxy node device 112 may determine, based on the collected operation information, an operation failure associated with one or more nodes (referred to as nodes with operation failure) in the first plurality of nodes of the first MaaS network 102 and the second plurality of nodes of the second MaaS network 202. Examples of determined operation failures may include, but are not limited to, network connection failures, operation failures, application errors, overload of message processing capabilities, inability to process ticket transactions due to the lack of transportation vehicles available at the planned travel time, or delayed arrival of transportation vehicles for pick-up or drop-off compared to the planned travel time.

[0079] Based on the determined operational failure, the proxy node device 112 may select a first message routing strategy from a set of message routing strategies (including a condition-based routing strategy 206A and a fault-based routing strategy 206B). The proxy node device 112 may select the first message routing strategy based on whether the node with operational failure belongs to the client layer 104, the server layer 108, or both the client layer 104 and the server layer 108. The first message routing strategy may be further selected based on the type of operational failure that the node with operational failure may face.

[0080] In an embodiment, the proxy node device 112 in the intelligent agent 206 may be configured to determine a certain strategy as the selected first message routing strategy by calculating a probability-based score associated with various factors that may affect the transaction processing of one or more MaaS networks. Therefore, the selection of the first message routing strategy may be based on a calculated probability-based score, which may be a compromise of various factors associated with the transaction processing of one or more MaaS networks. Examples of such factors may include, but are not limited to, systemic risk mitigation of the MaaS network, remediation of operation and system failures associated with nodes of the MaaS network, cost-effectiveness of users of the MaaS network (e.g., based on price and / or user preferences), and cost-effectiveness of mobility providers and / or organizations operating the MaaS network. Examples of such factors may also include, but are not limited to, traffic optimization associated with the mobility providers of the MaaS network, energy consumption and carbon emissions associated with vehicles of the mobility providers of the MaaS network, and user time consumption associated with transactions of the MaaS network.

[0081] The first message routing policy may be a fault-based routing policy (one of the fault-based routing policies 206B) or a condition-based routing policy (one of the condition-based routing policies 206A). Based on the selected first message routing policy, the proxy node device 112 may receive a transaction message associated with a first travel plan of a user (e.g., user 126). The transaction message may be received from a first node of the first MaaS network 102 or the second MaaS network 202. For example, the first node may be a first publisher node 110A among a plurality of publisher nodes 110A, 110B, ... 110N. Here, the first node may be different from an operationally faulty node of the first MaaS network 102 and / or the second MaaS network 202.

[0082] In an embodiment, the proxy node device 112 may select an alternative publisher node as the first node from a first plurality of nodes of the first MaaS network 102, or from a second plurality of nodes of the second MaaS network 202. The alternative publisher node may be selected based on the first message routing strategy and the determination that the node with operational failure includes a publisher node with operational failure. For example, the proxy node device 112 may determine that the first publisher node 110A of the first MaaS network 102 is operationally faulty. The operational failure associated with the first publisher node 110A may be caused by circumstances such as traffic congestion, a vehicle accident, the vehicle being unavailable for pick-up or drop-off at a predetermined time, or due to hardware / software failure. The proxy node device 112 may select a first message routing strategy for the first publisher node 110A based on the operational failure, and may select an alternative publisher node (such as the second publisher node 110B) based on the selected first message routing strategy.

[0083] By way of example and not limitation, if other publisher nodes of the same mobility provider are operating normally, the candidate publisher node may be selected from a cluster of nodes of the same mobility provider that owns / manages the first publisher node 110A. If other publisher nodes of the same mobility provider are not operating normally or are operating faulty, the candidate publisher node may be selected from a publisher node of another mobility provider. If publisher nodes of several mobility providers within a geographic area are operating faulty (e.g., due to an accident), the candidate publisher node may be selected from publisher nodes of a mobility provider operating in a second MaaS network 202 in a different geographic location.

[0084] As another example and not limitation, if the operational failure of the first publisher node 110A is caused by an overload of the message processing capability of the first publisher node 110A, the proxy node device 112 may select the candidate publisher node as the least congested one of the multiple publisher nodes 110A, 110B, . . . 110N.

[0085] As another example and not limitation, if the operation failure of the first publisher node 110A is caused by a network connection failure, an operation failure, or an application error, the proxy node device 112 may select the candidate publisher node as a node that is near the first publisher node 110A and belongs to the same mobility provider. For example, the candidate publisher node may be at the same station where the first publisher node 110A is located.

[0086] As another example and not limitation, the operational failure of the first publisher node 110A may include the inability to process the ticket transaction due to the lack of a transport vehicle available at the planned travel time, or the delayed arrival of a transport vehicle for pick-up or drop-off compared to the planned travel time. In such a scenario, the proxy node device 112 may select the first message routing strategy as one of the routing strategies 206A based on the situation. For example, the selected first message routing strategy may be a routing strategy based on traffic volume, based on which the proxy node device 112 may select an alternative publisher node of different mobility providers whose transport vehicles may be used for pick-up or drop-off of the same travel plan. For example, the first publisher node 110A may be a publisher node of a taxi service provider whose vehicle may not be able to reach the user 126 for the pick-up and drop-off of the first travel plan, or may be delayed due to traffic congestion or road accidents. The second publisher node 110B may be a publisher node of a bus service provider whose vehicle is available near the user 126 and can be used for pick-up and drop-off according to the first travel plan of the user 126. In such a scenario, the proxy node device 112 may select the second publisher node 110B as a candidate publisher node.

[0087] The proxy node device 112 may receive a transaction message associated with the first travel plan from an alternative publisher node. In an embodiment, the alternative publisher node (such as the second publisher node 110B) may be associated with a first mobility provider, which may be different from the second mobility provider associated with the operationally faulty publisher node (such as the first publisher node 110A). In this case, the received transaction message may correspond to an unplanned or unpurchased ticket transaction that is scheduled in lieu of a ticket transaction that may be processed by one of the operationally faulty nodes.

[0088] The proxy node device 112 may route the received transaction message to a second node of the first MaaS network 102 or the second MaaS network 202. For example, the second node may be a subscriber node (such as the first subscriber node 116A) associated with the first MaaS network 102 or the second MaaS network 202. Here, the second node may be different from the operationally faulty node of the first MaaS network 102 and / or the second MaaS network 202.

[0089] In an embodiment, the proxy node device 112 may select an alternative subscriber node (such as the second subscriber node 116B) from the first plurality of nodes of the first MaaS network 102 or from the second plurality of nodes of the second MaaS network 202 as the second node. The alternative subscriber node may be selected based on the selected first message routing strategy and the determination that the operationally faulty node includes the operationally faulty subscriber node. For example, the proxy node device 112 may determine that the first subscriber node 116A of the first MaaS network 102 is operationally faulty. The proxy node device 112 may select the first message routing strategy for the first subscriber node 116A based on the operational fault associated with the first subscriber node 116A. The proxy node device 112 may also select the alternative subscriber node as the second node based on the selected first message routing strategy.

[0090] By way of example and not limitation, if the operational failure of the first subscriber node 116A is caused by an overload of the message processing capability of the first subscriber node 116A, the proxy node device 112 may select the first message routing strategy as one of the condition-based routing strategies 206A. Based on the selected message routing strategy, the proxy node device 112 may determine the second subscriber node 116B as an alternative subscriber node because the message processing capability of the second subscriber node 116B may not be overloaded.

[0091] As another example and not limitation, if the operational failure of the first subscriber node 116A is caused by a network connection failure, an operational failure, or an application error, the proxy node device 112 may select an alternative subscriber node of a mobility provider that owns / manages the operationally failed subscriber node. Alternatively, the alternative subscriber node may be selected from a subscriber node cluster of another mobility provider on the first MaaS network 102 or the second MaaS network 202. For example, the proxy node device 112 may select the first subscriber node 208A of the second MaaS network 202 as an alternative subscriber node for the operationally failed first subscriber node (such as the first subscriber node 116A) of the first MaaS network 102.

[0092] The proxy node device 112 may route transaction messages associated with the first travel plan to an alternative subscriber node. In an embodiment, the alternative subscriber node (such as the second subscriber node 116B) may be associated with a first mobility provider, which may be different from a second mobility provider associated with the operationally faulty subscriber node (such as the first subscriber node 116A).

[0093] As another example and not limitation, the operational failure of the first subscriber node 116A may be caused by the unavailability or failure of the MP node 118A or the MaaS node 120A associated with the first subscriber node 116A. In this case, the proxy node device 112 may select a backup node (such as the backup node 114) as the second node from the first plurality of nodes of the first MaaS network 102 or from the second plurality of nodes of the second MaaS network 202. The backup node may be selected based on the selected first message routing strategy and the determination that the operationally faulty node includes the operationally faulty subscriber node and / or the operationally faulty node of the distributed ledger (one of the first MaaS network 102 or the second MaaS network 202). For example, the proxy node device 112 may determine that both the first subscriber node 116A and the MP node 118A (or the MaaS node 120A) are operationally faulty. The operational failure of the first subscriber node 116A, the MP node 118A, or the MaaS node 120A may be caused by a network connection failure, an operational failure, or an application error. When both the subscriber node and the ledger node are down, it may be necessary to temporarily store transaction messages from the proxy node device 112 until the recovery of both the subscriber node and the ledger node is complete. The proxy node device 112 may select a backup node as the second node based on the selected first message routing strategy. The backup node may be a separate database node, a subscriber node of the same or different mobility provider (such as the second subscriber node 116B), or an MP node of the same or different mobility provider (such as the MP node 118B).

[0094] In an embodiment, the proxy node device 112 may determine the number of transaction messages that may be processed by a node of a distributed ledger (such as a node of the distributed ledger 118 or the distributed ledger 120). The proxy node device 112 may determine a trend associated with an increase or decrease in the number of determined transaction messages. If the increase is greater than a first threshold or the number of transaction messages is greater than a second threshold, the proxy node device 112 may expand the distributed ledger (such as the distributed ledger 118 or the distributed ledger 120) by adding another node with a larger capacity than the current node. In another case, if the decrease in the number of transaction messages is less than a third threshold, the proxy node device 112 may reduce the distributed ledger (such as the distributed ledger 118 or the distributed ledger 120) by merging two nodes of the distributed ledger.

[0095] In an embodiment, the proxy node device 112 may route a transaction message received from the first node (the transaction message may be associated with the first travel plan) to a selected backup node (such as the backup node 114) so ​​as to temporarily store the routed transaction message at the backup node. In an embodiment, the node management device 204 may initialize the recovery of a subscriber node (such as the first subscriber node 116A) that is operating at a fault or a node (such as the MP node 118A) that is operating at a fault of a distributed ledger (such as the distributed ledger 118). For example, the node management device 204 may reboot or restart the server that hosts the node that is operating at a fault of a distributed ledger to initialize the recovery. In some cases, the node management device 204 may reinitialize / reset the network connectivity of the server, run a diagnostic check, or perform automatic repair of software associated with a subscriber node that is operating at a fault or a node that is operating at a fault of a distributed ledger. After recovery is complete, the node management device 204 may instruct the backup node to reroute the stored transaction messages to the operationally failed subscriber node (now recovered) or the operationally failed node of the distributed ledger (now recovered).

[0096] In the event of an accident involving vehicles associated with various mobility providers, the proxy node device 112 may support recovery of transaction routing. The proxy node device 112 may record all transaction messages that may pass through the proxy node device 112 and provide an analysis of the recorded transaction messages to the administrator device 122.

[0097] The proxy node device 112 may maintain a messaging table to store routing configurations regarding interconnections between different mobility providers and between mobility providers and MaaS networks, such as the first MaaS network 102. In addition, the proxy node device 112 may support transaction / travel roaming between mobility providers (i.e., mobility providers) or multiple MaaS networks and provide incentive-based dynamic pricing to smooth peak-hour traffic and increase revenue associated with the operation of MaaS networks and mobility providers. In addition, the proxy node device 112 may support heterogeneous corporate messaging based on the use of a common messaging protocol for communication and routing (or rerouting) of transactional messages.

[0098] Through the node management device 204, each of the first MaaS network 102 and the second MaaS network 202 can provide bulk cluster management of publisher nodes. In addition, through the node management device 204, the corresponding MaaS network can select a backup node for a subscriber node that is faulty in operation and / or a node that is faulty in operation of a distributed ledger of each MaaS network. The backup node can act as a substitute for a subscriber node that is faulty in operation and / or a node that is faulty in operation of a distributed ledger of the corresponding MaaS network. All publisher nodes and subscriber nodes can follow a set protocol to start running on a MaaS network (such as the first MaaS network 102 or the second MaaS network 202). The set protocol can enforce a common security architecture (for publisher node authentication and authorization), a network protocol (e.g., HTTP, MQTT, AMQP, etc.), a unified data request or response format (e.g., JSON, CSV, or XML format), and an API / data scheme. This can ensure that each publisher node follows a standard cluster-level configuration (e.g., device profile including company name, company ID, gate ID, gate number, etc.) and device-level certificates (i.e., authentication credentials). Standard cluster-level configuration and set protocols can facilitate transportation providers to deploy new publisher nodes or replace existing publisher nodes with a plug-and-play approach. This can promote the MaaS network to function as a homogenous transportation network with interoperability between resources (e.g., publisher nodes) of various mobility providers.

[0099] In contrast, conventional publisher nodes, subscriber nodes or distributed ledger nodes may have proprietary configurations and proprietary connection methods to access and operate on the MaaS network. This may lead to interoperability issues with publisher nodes and subscriber nodes of other transport providers. In case of urgent needs, the deployment of new or backup publisher nodes, subscriber nodes or distributed ledger nodes may take more time than required.

[0100] Figure 31 is a block diagram of a system for transaction flow management based on operational failures on (one or more) Mobility as a Service (MaaS) networks according to an embodiment of the present disclosure. Figure 1 and Figure 2 To illustrate the elements Figure 3 . refer to Figure 3 , which shows a block diagram of a system 300. The system 300 may include an intelligent agent 206, which includes an agent node device 112 and stores a set of message routing policies, such as a routing policy 206A based on a condition and a routing policy 206B based on a fault. In some embodiments, the system 300 may also include a node management device 204 and an administrator device 122.

[0101] The node management device 204 and the administrator device 122 may be communicatively coupled to the intelligent agent 206 via an appropriate communication network (not shown). The agent node device 112 may include circuitry 302, a memory 304, an input / output (I / O) device 306, and a network interface 308. The circuitry 302 may be configured to communicate with the plurality of publisher nodes 110A, 110B, ... 110N, the first plurality of subscriber nodes 116A, 116B, ... 116N (and / or the second plurality of subscriber nodes 208A, 208B, ... 208N), the node management device 204, and the administrator device 122 by using the network interface 308.

[0102] The circuit 302 may include suitable logic, circuitry, interfaces and / or code that may be configured to execute instructions for the operations performed by the proxy node device 112. Examples of implementations of the circuit 302 include a central processing unit (CPU), an x86-based processor, a reduced instruction set computing (RISC) processor, an application specific integrated circuit (ASIC) processor, a complex instruction set computing (CISC) processor, a graphics processing unit (GPU), a coprocessor, other processors, and / or combinations thereof.

[0103] The memory 304 may include suitable logic, circuitry, code, and / or interfaces that may be configured to store instructions executable by the circuit 302. The memory 304 may also store a set of message routing policies, message receiving tables, and routing configuration tables. Examples of implementations of the memory 304 may include, but are not limited to, a random access memory (RAM), a read-only memory (ROM), a hard disk drive (HDD), and / or a secure digital (SD) card.

[0104] I / O device 306 may include suitable logic, circuitry, and / or interfaces that may be configured to receive input and provide output based on the received input. I / O device 306 may include various input and output devices that may be configured to communicate with circuit 302. Examples of I / O device 306 may include, but are not limited to, a touch screen, a keyboard, a mouse, a joystick, a display device, a microphone, or a speaker.

[0105] The network interface 308 may include suitable logic, circuitry, interfaces and / or code that may be configured to establish communications (such as peer-to-peer static connections) between the proxy node device 112 and each of the plurality of publisher nodes 110A, 110B, ... 110N, the first plurality of subscriber nodes 116A, 116B, ... 116N (and / or the second plurality of subscriber nodes 208A, 208B, ... 208N), the node management device 204, and the administrator device 122. The network interface 308 may implement known techniques for supporting wired or wireless communications with one or more communication networks.

[0106] The network interface 308 may include, but is not limited to, an antenna, a frequency modulation (FM) transceiver, a radio frequency (RF) transceiver, one or more amplifiers, a tuner, one or more oscillators, a digital signal processor, a codec (CODEC) chipset, a subscriber identity module (SIM) card, and / or a local buffer. The network interface 308 may communicate with a network such as the Internet, an intranet, and / or a wireless network such as a cellular telephone network, a wireless local area network (LAN), and / or a metropolitan area network (MAN) via wireless communication. Wireless communication may use any of a variety of communication standards, protocols, and technologies, such as Long Term Evolution (LTE), Global System for Mobile Communications (GSM), Enhanced Data GSM Environment (EDGE), Wideband Code Division Multiple Access (W-CDMA), Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Bluetooth, Wireless Fidelity (Wi-Fi) (e.g., IEEE 802.11a, IEEE802.1b, IEEE 802.11g, and / or IEEE 802.11n), Voice over Internet Protocol (VoIP), Wi-MAX, email protocol, instant messaging, and / or short message service (SMS).

[0107] Similar to the proxy node device 112, each of the administrator device 122 and the node management device 204 may include one or more components having similar functions, including circuits, memory, I / O devices, display devices, and network interfaces. Figure 1 , Figure 2 4 and the functions or operations performed by the proxy node device 112 may be performed by the circuit 302. For example, in Figure 1 , Figure 2 , Figure 4A and Figure 4B Such operation is described in detail in .

[0108] Figure 4A and Figure 4B 1 and 2 collectively depict a flow chart of an exemplary method for transaction flow management based on operational failures on a Mobility as a Service (MaaS) network according to an embodiment of the present disclosure. Figure 1 , Figure 2 and Figure 3 elements to illustrate Figure 4A and Figure 4B . refer to Figure 4A and Figure 4B , a flowchart 400 is shown. The exemplary method of flowchart 400 can be performed by any computing system, such as by Figure 1 The exemplary method of flowchart 400 may start at 402 and then proceed to 404.

[0109] At 404, operation information associated with the first plurality of nodes of the first MaaS network 102 may be collected. In an embodiment, the circuit 302 of the proxy node device 112 may be configured to collect operation information associated with the first plurality of nodes of the first MaaS network 102. The collected operation information may include a network connection status and a device operation status of each node of the first MaaS network 102.

[0110] At 406, an operational failure associated with one or more nodes of the first plurality of nodes of the first MaaS network 102 may be determined based on the collected operational information. In an embodiment, the circuit 302 of the proxy node device 112 may be configured to determine an operational failure associated with one or more nodes of the first plurality of nodes. The one or more nodes may be nodes that may process ticket transactions associated with a travel plan in a series of travel plans included in the MaaS mobility service. For example, the one or more nodes may include a publisher node of the first MaaS network 102, such as a ticket gate, an application, and / or a PoS device. In another example, the one or more nodes may include a subscriber node of the first MaaS network 102 or a node of a distributed ledger (e.g., a distributed ledger 118 or a distributed ledger 120) associated with a subscriber node of the first MaaS network 102. Examples of operational failures may include, but are not limited to, network connection failures, operational failures, application errors, overload of message processing capabilities, inability to process ticket transactions due to no transportation vehicle available at the planned travel time, or delayed arrival of a transportation vehicle for pick-up or drop-off compared to the planned travel time.

[0111] At 408, it may be determined whether there is an operationally faulty publisher node in the first MaaS network 102. In an embodiment, the circuitry 302 of the proxy node device 112 may be configured to check whether there is an operationally faulty publisher node in the first MaaS network 102. If there is an operationally faulty publisher node (such as the first publisher node 110A), control may be transferred to 410, otherwise control may be transferred to 416.

[0112] At 410, a first message routing strategy may be selected based on the determined operational failure. In an embodiment, the circuitry 302 of the proxy node device 112 may be configured to select a first message routing strategy from a set of message routing strategies (e.g., a condition-based routing strategy 206A and / or a fault-based routing strategy 206B). The selection of the first message routing strategy may be based on the type of operational failure associated with the publisher node that has an operational failure. For example, in Figure 1 and Figure 2 The selection of the first message routing strategy is further described in .

[0113] At 412, a candidate publisher node (such as the second publisher node 110B) may be selected from the first plurality of nodes of the first MaaS network 102. In an embodiment, the circuit 302 of the proxy node device 112 may be configured to select the candidate publisher node from the first plurality of nodes of the first MaaS network 102. For example, Figure 1 and Figure 2 The selection of candidate publisher nodes is further explained in .

[0114] At 414, a transaction message associated with the user's first travel plan may be received from an alternative publisher node, such as the second publisher node 110B. In an embodiment, the circuit 302 of the proxy node device 112 may be configured to receive a transaction message associated with the first travel plan from an alternative publisher node.

[0115] At 416, a transaction message associated with the user's first travel plan may be received from a publisher node (such as the first publisher node 110A) of the first MaaS network 102. In an embodiment, the circuit 302 of the proxy node device 112 may be configured to receive a transaction message associated with the first travel plan from an alternative publisher node.

[0116] At 418, a determination may be made as to whether there are operationally faulty subscriber nodes in the first MaaS network 102. In an embodiment, the circuitry 302 of the proxy node device 112 may be configured to check whether there are operationally faulty subscriber nodes in the first MaaS network 102. If the first MaaS network 102 includes an operationally faulty subscriber node (such as the first subscriber node 116A), control may pass to 420, otherwise control passes to 422.

[0117] At 420, a first message routing strategy may be selected based on the determined operational failure. In an embodiment, the circuitry 302 of the proxy node device 112 may be configured to select a first message routing strategy from a set of message routing strategies, such as the condition-based routing strategy 206A and / or the fault-based routing strategy 206B. The selection of the first message routing strategy may be based on the type of operational failure associated with the operationally faulty subscriber node. For example, in Figure 1 and Figure 2 The selection of the first message routing strategy is further described in .

[0118] At 422, the transaction message may be routed to a subscriber node (such as the first subscriber node 116A) of the first MaaS network 102. In an embodiment, the circuitry 302 of the proxy node device 112 may be configured to route the transaction message to a subscriber node (such as the first subscriber node 116A) of the first MaaS network 102. Control may pass to 428.

[0119] At 424, an alternate subscriber node (such as the second subscriber node 116B) may be selected from the first plurality of nodes of the first MaaS network 102. In an embodiment, the circuitry 302 of the proxy node device 112 may be configured to select the alternate subscriber node from the first plurality of nodes of the first MaaS network 102. The selection of the alternate subscriber node may be based on the selected first message routing strategy (at 420). For example, at Figure 1 and Figure 2 The details of this option are further explained in.

[0120] At 426, the received transaction message associated with the user's first travel plan may be routed to an alternative subscriber node (such as the second subscriber node 116B). In an embodiment, the circuit 302 of the proxy node device 112 may be configured to route the received transaction message associated with the first travel plan to an alternative subscriber node.

[0121] At 428, a determination may be made as to whether an operationally faulty node of a distributed ledger, such as the distributed ledger 118 or the distributed ledger 120, exists in the first MaaS network 102. In an embodiment, the circuitry 302 of the proxy node device 112 may be configured to check whether an operationally faulty subscriber node exists in the first MaaS network 102. If the first MaaS network 102 includes an operationally faulty node, such as the MP node 118A of the distributed ledger 118, control may pass to 430, otherwise control passes to 438.

[0122] At 430, a backup node (such as backup node 114) may be selected from the first plurality of nodes of the first MaaS network 102. In an embodiment, the circuit 302 of the proxy node device 112 may be configured to select a backup node from the first plurality of nodes of the first MaaS network 102. For example, Figure 1 and Figure 2 The selection of a backup node for a failed subscriber node or a failed node of the distributed ledger is further explained in.

[0123] At 432, the received transaction message associated with the user's first travel plan may be routed to the selected backup node. In an embodiment, the circuit 302 of the proxy node device 112 may be configured to route the received transaction message associated with the first travel plan to the selected backup node. The backup node may be configured to temporarily store the routed transaction message.

[0124] At 434, recovery of a failed node (such as MP node 118A) operating the distributed ledger may be initialized. In an embodiment, node management device 204 may be configured to initialize recovery of a failed node (such as MP node 118A) operating the distributed ledger.

[0125] At 436, after recovery is complete, the stored transaction messages may be rerouted to the node of the distributed ledger that was operating at the fault (e.g., MP node 118A). Node management device 204 may be configured to instruct backup nodes (e.g., backup node 114) to reroute stored transaction messages to the node that was operating at the fault (e.g., MP node 118A) after recovery is complete.

[0126] At 438, the received transaction message may be executed. In an embodiment, after recovery, the operationally faulty node (such as the MP node 118A) may execute the transaction on a distributed ledger (such as the distributed ledger 118) based on the transaction message (rerouted at 436). In another embodiment, if the first MaaS network 102 does not include any operationally faulty nodes, the receiving node (such as the MP node 118A) may execute the transaction based on the transaction message. Control may pass to end.

[0127] Although flowchart 400 is illustrated as discrete operations, such as 404, 406, 408, 410, 412, 414, 416, 418, 420, 422, 424, 426, 428, 430, 432, 434, 436, and 438, the disclosure is not limited thereto. Thus, in some embodiments, depending on the particular implementation, these discrete operations may be further divided into additional operations, combined into fewer operations, or eliminated without departing from the essence of the disclosed embodiments.

[0128] Exemplary aspects of the present disclosure may include a system (such as system 300), which may include a proxy node device (such as proxy node device 112), a node management device (such as node management device 204) and an administrator device (such as administrator device 122). The proxy node device 112 may be configured to collect operation information associated with a first plurality of nodes of a first mobility as a service (MaaS) network (such as the first MaaS network 102). The proxy node device 112 may also be configured to determine an operation failure associated with one or more nodes in the first plurality of nodes based on the collected operation information. The one or more nodes may process a ticket transaction associated with a first travel plan in a series of travel plans included in the MaaS mobility service. The proxy node device 112 may also be configured to select a first message routing strategy from a set of message routing strategies based on the determined operation failure. The proxy node device 112 may also be configured to receive a transaction message associated with the first travel plan from a first node in the first plurality of nodes based on the selected first message routing strategy. Furthermore, the proxy node device 112 may be configured to route the received transaction message to a second node of the first plurality of nodes based on the selected first message routing policy.

[0129] In an embodiment, the proxy node device 112 may also be configured to collect traffic information associated with a fleet of transport vehicles on the road belonging to one or more mobility providers of the first MaaS network 102. The collected traffic information may include traffic congestion information, traffic collision information, detour information, or below average traffic volume information. The proxy node device 112 may be configured to further determine an operational failure associated with one or more nodes in the first plurality of nodes based on the collected traffic information. The collected operational information may include a network connection state and a device operational state of each node in the first plurality of nodes. The determined operational failure may include at least one of a network connection failure associated with the one or more nodes, an operational failure of the one or more nodes, an application error on the one or more nodes, or an overload of the message processing capacity of the one or more nodes. The determined operational failure may also include that the one or more nodes are unable to process a ticket transaction due to the absence of a transport vehicle available at the planned travel time, or a delayed arrival of a transport vehicle for pick-up or drop-off compared to the planned travel time.

[0130] In an embodiment, the first node and the second node may be different from the one or more nodes. In an embodiment, the first node and the second node may be associated with a first mobility provider, which may be different from a second mobility provider associated with the one or more nodes of the first MaaS network 102.

[0131] In an embodiment, the proxy node device 112 may be configured to control the administrator device 122 to display information including the determined operational failure, the collected operational information, and traffic information associated with an on-road fleet of transport vehicles of one or more mobility providers belonging to the first MaaS network 102. The proxy node device 112 may be configured to control the administrator device 122 to display a set of user-selectable options corresponding to a set of message routing policies based on the displayed information. The proxy node device 112 may also be configured to receive an administrator input via the administrator device 122, the administrator input including a selection of a first user-selectable option in the set of user-selectable options. The first message routing policy may be selected based on the received administrator input.

[0132] In an embodiment, the proxy node device 112 may be configured to select an alternative publisher node as a first node from a first plurality of nodes of the first MaaS network 102, or from a second plurality of nodes of a second MaaS network different from the first MaaS network 102 (such as the second MaaS network 202). The alternative publisher node may be selected based on a selected first message routing strategy and a determination that the one or more nodes include a publisher node that is operationally faulty. The proxy node device 112 may be configured to receive a transaction message associated with a first travel plan from the selected alternative publisher node. In an embodiment, the received transaction message may correspond to an unplanned or unpurchased ticket transaction that is arranged in place of a ticket transaction processed by the one or more nodes. The selected alternative publisher node may be associated with a first mobility provider, which may be different from a second mobility provider associated with the publisher node that is operationally faulty.

[0133] In an embodiment, the proxy node device 112 may be configured to select an alternate subscriber node as the second node from a first plurality of nodes of the first MaaS network 102, or from a second plurality of nodes of a second MaaS network 202 different from the first MaaS network 102. The alternate subscriber node may be selected based on a selected first message routing strategy and a determination that the one or more nodes include an operationally faulty subscriber node. The proxy node device 112 may be configured to route a received transaction message associated with the first travel plan to the selected alternate subscriber node. The selected alternate subscriber node may be associated with a first mobility provider, which may be different from a second mobility provider associated with the operationally faulty subscriber node.

[0134] In an embodiment, the proxy node device 112 may be configured to select a backup node as the second node from a first plurality of nodes of the first MaaS network 102, or from a second plurality of nodes of a second MaaS network 202 that is different from the first MaaS network 102. The backup node may be selected based on the selected first message routing policy and a determination that the one or more nodes include an operationally faulty subscriber node or an operationally faulty node of a distributed ledger (e.g., distributed ledger 118 or distributed ledger 120) included in the first MaaS network 102. The proxy node device 112 may be configured to route a received transaction message associated with the first travel plan to the selected backup node, and the selected backup node may temporarily store the routed transaction message.

[0135] In an embodiment, the node management device 204 may be configured to initialize recovery of a failed subscriber node or a failed node of a distributed ledger (e.g., distributed ledger 118 or distributed ledger 120). After the recovery is complete, the node management device 204 may be configured to instruct the backup node to reroute the stored transaction messages to the failed subscriber node or the failed node of the distributed ledger.

[0136] In an embodiment, the first message routing policy may correspond to one of an intra-routing policy, an inter-routing policy, or a regional routing policy. The intra-routing policy may correspond to a routing policy in which the proxy node device 112 may route a transaction message received from a publisher node associated with a first mobility provider to a subscriber node associated with a second mobility provider different from the first mobility provider within the same first MaaS network 102. The inter-routing policy may correspond to a routing policy in which the proxy node device 112 may route a transaction message received from a publisher node of the first MaaS network 102 to a subscriber node of a second MaaS network 202 different from the first MaaS network 102. The regional routing policy may correspond to a routing policy in which the proxy node device 112 may route a transaction message received from a publisher node of a first MaaS network 102 in a first geographic area to a second MaaS network 202 in a second geographic area different from the first geographic area or a subscriber node of the first MaaS network 102.

[0137] The present disclosure may be implemented in hardware or in a combination of hardware and software. The present disclosure may be implemented in a centralized manner in at least one computer system, or in a distributed manner in which different elements may be distributed over several interconnected computer systems. A computer system or other device suitable for executing the methods described herein may be suitable. The combination of hardware and software may be a general-purpose computer system with a computer program that, when loaded and executed, may control the computer system so that the computer system executes the methods described herein. The present disclosure may be implemented in hardware including a portion of an integrated circuit that also performs other functions.

[0138] The present disclosure may also be embedded in a computer program product comprising all the features enabling the implementation of the methods described herein and capable of carrying out these methods when loaded into a computer system. In this context, a computer program means any expression in any language, code or notation of a set of instructions intended to cause a system with information processing capabilities to perform a specific function, either directly or after one or both of the following: a) conversion into another language, code or notation; b) reproduction in a different material form.

[0139] Although the present disclosure has been described with reference to certain embodiments, it will be appreciated by those skilled in the art that various changes and equivalent substitutions may be made without departing from the scope of the present disclosure. In addition, many modifications may be made to adapt specific circumstances or materials to the teachings of the present disclosure without departing from the scope of the present disclosure. Thus, the present disclosure is not limited to the specific embodiments disclosed, but rather the present disclosure will include all embodiments falling within the scope of the appended claims.

Claims

1. A system comprising: A proxy node device, wherein the proxy node device is configured to: Collecting operational information associated with a first plurality of nodes of a first Mobility as a Service (MaaS) network; determining an operational fault associated with one or more nodes of the first plurality of nodes based on the collected operational information, wherein the one or more nodes process a ticket transaction associated with a first travel plan in a series of travel plans included in the MaaS mobility service; Based on the determined operational failure, selecting a first message routing strategy from a set of message routing strategies; receiving a transaction message associated with a first travel plan from a first node of the first plurality of nodes based on the selected first message routing strategy, wherein the first node is a publisher node of the first MaaS network or an alternate publisher node in the event that the publisher node fails in operation; and routing the received transaction message to a second node of the first plurality of nodes based on the selected first message routing strategy, wherein the second node comprises one of: a subscriber node, a node of a distributed ledger associated with the first MaaS network, or a backup node in case of operational failure of the subscriber node and / or the node of the distributed ledger, The first node and the second node are different from the one or more nodes, and the first node and the second node are not operationally faulty nodes.

2. The system of claim 1, wherein the proxy node device is further configured to collect traffic information associated with an on-road fleet of transport vehicles belonging to one or more mobility providers of the first MaaS network, and wherein the collected traffic information includes at least one of traffic congestion information, traffic collision information, detour information, or below-average traffic volume information.

3. The system of claim 2, wherein the proxy node device is further configured to determine an operational fault associated with the one or more nodes of the first plurality of nodes further based on the collected traffic information.

4. The system of claim 1, wherein the collected operating information includes a network connection status and a device operating status of each node in the first plurality of nodes.

5. The system of claim 1 , wherein the determined operational failure comprises at least one of: a network connection associated with the one or more nodes fails, The operation of one or more nodes fails. application error on said one or more nodes, Overloading of the message processing capacity of one or more nodes, or The one or more nodes are unable to process the ticket transaction due to no transportation vehicle being available at the scheduled travel time, or a transportation vehicle for pick-up or drop-off arriving late compared to the scheduled travel time.

6. The system of claim 1, wherein the first node and the second node are associated with a first mobility provider, the first mobility provider being different from a second mobility provider associated with the one or more nodes of the first MaaS network.

7. The system according to claim 1, wherein the proxy node device is further configured to: controlling the administrator device to display information including the determined operational faults, the collected operational information, and traffic information associated with an on-road fleet of transport vehicles of one or more mobility providers belonging to the first MaaS network; Based on the displayed information, controlling the administrator device to display a set of user-selectable options corresponding to the set of message routing policies; receiving, via the administrator device, an administrator input comprising a selection of a first user-selectable option from the set of user-selectable options; and A first message routing strategy is selected based on the received administrator input.

8. The system according to claim 1, wherein the proxy node device is further configured to: selecting a candidate publisher node as the first node from a first plurality of nodes of the first MaaS network, or from a second plurality of nodes of a second MaaS network different from the first MaaS network, wherein the candidate publisher node is selected based on the selected first message routing strategy and a determination that the one or more nodes include an operationally faulty publisher node; and A transaction message associated with a first travel plan is received from the selected candidate publisher node.

9. The system of claim 8, wherein the received transaction message corresponds to an unscheduled or unpurchased ticket transaction that was scheduled in lieu of a ticket transaction processed by the one or more nodes.

10. The system of claim 8, wherein the selected alternative publisher node is associated with a first mobility provider that is different than a second mobility provider associated with the operationally faulty publisher node.

11. The system according to claim 1, wherein the proxy node device is further configured to: selecting a candidate subscriber node as said second node from a first plurality of nodes of a first MaaS network, or from a second plurality of nodes of a second MaaS network different from the first MaaS network, wherein the alternate subscriber node is selected based on a selected first message routing strategy and a determination that the one or more nodes include an operationally faulty subscriber node; and The received transaction message associated with the first travel plan is routed to the selected alternative subscriber node.

12. The system of claim 11, wherein the selected alternative subscriber node is associated with a first mobility provider that is different from a second mobility provider associated with the operationally faulty subscriber node.

13. The system according to claim 1, wherein the proxy node device is further configured to: selecting a backup node as the second node from a first plurality of nodes of the first MaaS network or from a second plurality of nodes of a second MaaS network different from the first MaaS network, wherein the backup node is selected based on the selected first message routing strategy and a determination that the one or more nodes include an operationally faulty subscriber node or an operationally faulty node of a distributed ledger comprised in the first MaaS network; and The received transaction message associated with the first travel plan is routed to the selected backup node, and the selected backup node temporarily stores the routed transaction message.

14. The system according to claim 13, further comprising a node management device, wherein the node management device is configured to: Initializing the recovery of a failed subscriber node or a failed node of the distributed ledger; and After the recovery is completed, the backup node is instructed to reroute the stored transaction message to the failed subscriber node or the failed node of the distributed ledger.

15. The system of claim 1, wherein the first message routing strategy is selected as one of: an inner routing policy, based on which the proxy node device routes, within the same first MaaS network, a transaction message received from a publisher node associated with a first mobility provider to a subscriber node associated with a second mobility provider different from the first mobility provider, an inter-routing strategy based on which the proxy node device routes a transaction message received from a publisher node of a first MaaS network to a subscriber node of a second MaaS network different from the first MaaS network, or Based on a region-based routing policy, the proxy node device routes a transaction message received from a publisher node of a first MaaS network in a first geographical region to a second MaaS network in a second geographical region different from the first geographical region or a subscriber node of the first MaaS network.

16. A method comprising: In a system that includes a proxy node device: collecting, by means of the proxy node device, operation information associated with a first plurality of nodes of a first Mobility as a Service (MaaS) network; determining, by the proxy node device, an operation fault associated with one or more nodes of the first plurality of nodes based on the collected operation information, wherein the one or more nodes process a ticket transaction associated with a first travel plan in a series of travel plans included in the MaaS mobility service; Selecting, by the proxy node device, a first message routing strategy from a group of message routing strategies based on the determined operation failure; receiving, by the proxy node device, a transaction message associated with a first travel plan from a first node of the first plurality of nodes based on a selected first message routing strategy, wherein the first node is a publisher node of the first MaaS network or an alternative publisher node in case the publisher node fails in operation; and The received transaction message is routed, by the proxy node device, to a second node of the first plurality of nodes based on the selected first message routing strategy, wherein the second node comprises one of the following: a subscriber node, a node of a distributed ledger associated with the first MaaS network, or a backup node in case the subscriber node and / or the node of the distributed ledger fails in operation, The first node and the second node are different from the one or more nodes, and the first node and the second node are not operationally faulty nodes.

17. The method of claim 16, further comprising collecting, by the proxy node device, traffic information associated with an on-road fleet of transport vehicles belonging to one or more mobility providers of the first MaaS network, The collected traffic information includes at least one of traffic congestion information, traffic collision information, detour information, or lower-than-average traffic volume information.

18. The method of claim 17, wherein determining an operational fault associated with the one or more nodes of the first plurality of nodes is further based on the collected traffic information.

19. The method of claim 16, wherein the determined operational failure comprises at least one of: a network connection associated with the one or more nodes fails, The operation of one or more nodes fails. application error on said one or more nodes, Overloading of the message processing capacity of one or more nodes, or The one or more nodes are unable to process the ticket transaction due to no transportation vehicle being available at the scheduled travel time, or a transportation vehicle for pick-up or drop-off arriving late compared to the scheduled travel time.

20. The method of claim 16, wherein the first message routing strategy is selected as one of: an inner routing policy, based on which the proxy node device routes, within the same first MaaS network, a transaction message received from a publisher node associated with a first mobility provider to a subscriber node associated with a second mobility provider different from the first mobility provider, an inter-routing strategy based on which the proxy node device routes a transaction message received from a publisher node of a first MaaS network to a subscriber node of a second MaaS network different from the first MaaS network, or Based on a region-based routing policy, the proxy node device routes a transaction message received from a publisher node of a first MaaS network in a first geographical region to a second MaaS network in a second geographical region different from the first geographical region or a subscriber node of the first MaaS network.

Images