Determining revenue share for transactions on MaaS platforms using a common database architecture

Abstract

A system for determining a revenue share of a mobility player (MP) of a MaaS network is disclosed. An MP node of the MP is onboarded to a node package of the MaaS network and associated with a MaaS node of the node package based on an onboarding process. The onboarding process includes defining a service structure including configuration data of the MP, and the MP node signing off on a service agreement and privacy policy associated with the MaaS network based on the service terms of the service agreement. Once the MP node is onboarded to the node package, a MaaS node, such as a plurality of aggregator nodes and a central MaaS node, and / or one or more external nodes can determine a revenue share of the MP based on receiving a trigger event associated with the node package.

Description

[Technical Field]

[0001] Cross-reference to related applications / incorporation by reference This application claims the benefit of priority to U.S. Patent Application No. 17 / 486,148, filed in the United States Patent and Trademark Office on September 27, 2021. This application references U.S. Patent Application No. 17 / 178,185, filed February 17, 2021.

[0002] The above-referenced applications are incorporated herein by reference in their entirety.

[0003] Various embodiments of the present disclosure relate to Mobility-as-a-Service (MaaS) and distributed ledger technology. Specifically, various embodiments of the present disclosure relate to systems and methods for determining revenue shares of transactions on a MaaS platform using a blockchain common database architecture. [Background technology]

[0004] A Mobility as a Service (MaaS) platform allows multiple mobility providers to offer their services through an infrastructure that may be based on a closed platform, and each such mobility provider may have a separate ticket processing infrastructure (e.g., ticketing gates and point-of-sale (PoS) devices) or separate applications (e.g., ticket booking applications and ride hailing applications) for making, paying for, or managing trips.

[0005] On such a MaaS platform, transaction messages can be exchanged between various nodes of the MaaS platform when a passenger books a ticket for a trip, boards a mobility provider's vehicle during the trip, or disembarks a mobility provider's vehicle. Trip-related transaction messages can be stored as transaction records in one or more database nodes (e.g., nodes of a distributed ledger system) associated with the MaaS platform. Each trip can involve the provision of transportation services by multiple mobility providers, and these services can span multiple geographic regions. Therefore, standardization for the settlement of multi-company, cross-border, or cross-regional transactions is considered necessary. However, mobility providers may operate locally or in silos, and therefore, such standardized transaction settlement can be challenging. Standardized transaction settlement may also require data ownership and data access agreements between the mobility providers and the MaaS platform. Such agreements are difficult to generate and can take a long time to implement. In some scenarios, transactions may be settled based on an analysis of transaction records on nodes of a distributed ledger system associated with the MaaS platform (e.g., for auditing, accounting, or other administrative purposes of the mobility provider). However, analyzing transaction records on nodes of a distributed ledger system associated with the MaaS platform can be a tedious and time-consuming process. Summary of the Invention [Problem to be solved by the invention]

[0006] The limitations and disadvantages of conventional approaches will become apparent to those skilled in the art by comparing the described system with certain aspects of the present disclosure illustrated in the remainder of this application and with reference to the drawings. [Means for solving the problem]

[0007] Provided are systems and methods for revenue share determination for transactions on a Mobility as a Service (MaaS) platform using a common database architecture substantially as shown and / or described in connection with at least one of the figures and more fully set forth in the claims.

[0008] These and other features and advantages of the present disclosure will become apparent from a consideration of the following detailed description of the disclosure when taken in conjunction with the accompanying drawings, in which like reference characters refer to like elements throughout. [Brief explanation of the drawings]

[0009] [Figure 1] FIG. 1 illustrates an exemplary network environment for revenue share determination of transactions on a Mobility as a Service (MaaS) platform using a common database architecture, according to an embodiment of the present disclosure. [Figure 2] FIG. 1 is an exemplary sequence diagram illustrating revenue share determination for large-scale transactions on a Mobility as a Service (MaaS) platform using a common database architecture, according to an embodiment of the present disclosure. [Figure 3] 2 is an exemplary sequence diagram illustrating verification of a first revenue share rate associated with a first mobility provider (MP) corresponding to the first MP node of FIG. 1 according to an embodiment of the present disclosure. [Figure 4] FIG. 1 is an exemplary sequence diagram illustrating revenue share determination for small or medium-sized transactions on a Mobility as a Service (MaaS) platform using a common database architecture, according to an embodiment of the present disclosure. [Figure 5] 2 is an exemplary scenario illustrating the determination of a first revenue share rate associated with a first mobility provider (MP) corresponding to the first MP node of FIG. 1, according to an embodiment of the present disclosure. [Figure 6]FIG. 1 illustrates an exemplary entity-relationship (ER) diagram related to onboarding a mobility provider (MP) node to a node package of a mobility-as-a-service (MaaS) platform using a common database architecture and determining a mobility provider revenue share percentage corresponding to the MP node, according to an embodiment of the present disclosure. [Figure 7] FIG. 1 is an exemplary sequence diagram illustrating the process of onboarding a mobility provider (MP) node to a node package of a mobility-as-a-service (MaaS) platform using a common database architecture, according to an embodiment of the present disclosure. [Figure 8] FIG. 1 is a block diagram of an exemplary system for revenue share determination of transactions on a Mobility as a Service (MaaS) platform using a common database architecture, according to an embodiment of the present disclosure. [Figure 9] FIG. 1 illustrates an exemplary flowchart of a method for determining revenue share rates for large transactions on a Mobility as a Service (MaaS) platform using a common database architecture, according to an embodiment of the present disclosure. [Figure 10] FIG. 1 illustrates an exemplary flowchart of a revenue share determination method for small or medium-sized transactions on a Mobility as a Service (MaaS) platform using a common database architecture, according to an embodiment of the present disclosure. DETAILED DESCRIPTION OF THE INVENTION

[0010] The disclosed system and method for determining revenue share rates for transactions on a Mobility as a Service (MaaS) network (hereinafter synonymously referred to as a MaaS platform) using a common database architecture may find implementation as described below. The disclosed system may be part of a federated transportation management system that can facilitate multiple homogeneous or heterogeneous mobility providers and their infrastructure, such as ticket gates, applications, and / or point-of-sale (PoS) devices, operating on the MaaS network to provide various mobility services. Each mobility provider has secure data ownership and can control the joint use of related transaction data through a distributed ledger, thereby enhancing connectivity between various mobility providers. The system can further enhance the handling of revenue share models, roaming management, and contract management between different mobility providers based on controlled co-use of related transaction records through the distributed ledger. Each mobility provider in the MaaS network may be associated with the MaaS network through a service agreement, including specific terms of service and associated privacy policies. A mobility provider node may be onboarded to the MaaS network based on a service agreement, terms of service, and privacy policy before joining the MaaS network. Upon accepting the service agreement, a mobility provider node may be onboarded and join the MaaS network based on the terms of service and privacy policy.

[0011] An exemplary aspect of the present disclosure provides a system that can include multiple node packages associated with a MaaS network. Each of the multiple node packages can include a subscriber node, a mobility provider (MP) node of a first distributed ledger, and a MaaS node of a second distributed ledger. The MaaS network can further include multiple issuer nodes and a broker node device. One or more nodes associated with the MaaS network can be configured to process multiple transaction records associated with a trip plan among a set of trip plans included in a MaaS mobility service. The transaction record can further be associated with a traveling user (e.g., a traveling user). The multiple transaction records can be associated with information such as ticketing information, subscription information, payment information, revenue sharing information, and / or mobility service information. Each of the multiple transaction records can be associated with a transaction message received by a subscriber node (e.g., a first subscriber node) of a first node package of the multiple node packages. The subscriber node can receive the transaction message from the issuer node (e.g., a first issuer node of the multiple issuer nodes) via the broker node device.

[0012] The disclosed system may further include a plurality of aggregator nodes and a central MaaS node. The plurality of aggregator nodes and the central MaaS node may be communicatively coupled to a plurality of node packages of the MaaS network. A first aggregator node of the plurality of aggregator nodes may be configured to receive a first set of transaction records from a first MaaS node of a first node package of the plurality of node packages based on a trigger event associated with the first node package. The first set of transaction records may be associated with a first MP node of the first node package. Each of the first set of transaction records may be associated with a transaction message received by a first subscriber node of the first node package.

[0013] In some embodiments, the MaaS network may further include a scheduler node communicatively coupled to the plurality of node packages. The scheduler node may generate a trigger event associated with the first node package based on at least one of a predetermined schedule or receipt of a predetermined number of transaction records at the first MaaS node. In some embodiments, a first MP (mobility player) corresponding to the first MP node and a first MaaS player corresponding to the first MaaS node are associated with the MaaS network based on a service agreement, revenue sharing model, data ownership agreement, terms of service agreement, privacy policy, and / or policy amendment associated with an area of ​​operation of at least one of the first MP or first MaaS player.

[0014] The first aggregator node may be further configured to determine a first summary record associated with the first MP node based at least on an aggregation of transaction amounts associated with each of the received first set of transaction records. In some embodiments, the determination of the first summary record associated with the first MP node may be further based on a first set of parameters. The first set of parameters may include business information associated with the first MP, service item information associated with each of the first set of transaction records, ticket sales data associated with each of the first set of transaction records, fare price master data associated with the first MP, service price master data associated with the first MP, and / or ticket transaction data associated with each of the first set of transaction records. In some embodiments, the determination of the first summary record may be further based on applying at least one of a big data platform, a Hadoop platform, or a MapReduce platform to at least one of the transaction amounts associated with each of the received first set of transaction records or the first set of parameters.

[0015] The first aggregator node may be further configured to transmit the determined first summary record to a central MaaS node. The central MaaS node may be configured to receive a set of summary records associated with the first MP node from the multiple aggregator nodes. The received summary of records includes at least the first summary record. The central MaaS node may be further configured to determine a second summary record associated with the first MP node based on an aggregation of transaction amounts associated with each of the received set of summary records. The central MaaS node may be further configured to determine a first revenue share rate associated with the first MP corresponding to the first MP node based on the determined second summary record. The central MaaS node may be further configured to transmit the determined first revenue share rate associated with the first MP to the first MaaS node.

[0016] In some embodiments, determining the first revenue share rate associated with the first MP can be further based on a second set of parameters. The second set of parameters can include a fee associated with the first MaaS player corresponding to the first MaaS node, a carbon footprint associated with the first MP, green energy incentives earned by the first MP, traffic congestion reduction achieved by the first MP, and / or a fare slab for vehicles associated with the first MP. In some embodiments, determining the first revenue share rate associated with the first MP can be further based on applying an artificial intelligence (AI) system to at least one of the determined second summary record or the second set of parameters.

[0017] In contrast to conventional systems that can analyze transaction records of mobility providers on distributed ledger nodes associated with a MaaS network, the disclosed system offloads analysis of transaction records to an external system, which may include multiple aggregator nodes and a central MaaS node. For example, a first set of transaction records may include a large number of transaction records of a first MP node, such as millions of transaction records that may be generated over a one-month period. In such cases, analyzing the first set of transaction records on the distributed ledger nodes may become cumbersome and time-consuming. When analysis of such a large number of transaction records is offloaded to the disclosed system (including an external system), each aggregator node may roll up the transaction records of the first MP node received from each node package associated with the aggregator node. For example, the first aggregator node may roll up the first set of transaction records of the first MP node associated with the first node package to determine a first summary record associated with the first MP node. Similarly, other aggregator nodes among the plurality of aggregator nodes may also compile transaction records of the first MP node associated with each other node package to determine corresponding summary records associated with the first MP node of the corresponding node package. For example, a second aggregator node among the plurality of aggregator nodes may determine a summary record of the first MP node associated with a second node package based on a second set of transaction records of the first MP node associated with the second node package. Such summary record determination at the various aggregator nodes may be performed in parallel. For example, a big data platform may be utilized at the various aggregator nodes to parallelize the determination of summary records associated with the first MP node.Parallelizing the determination of summary records can increase efficiency, reduce costs, and shorten the time involved in analyzing large volumes of transaction records. A central MaaS node can receive summary records determined by multiple aggregator nodes as a set of summary records associated with a first MP node. Furthermore, the central MaaS node can match the set of summary records to determine a second summary record. The central MaaS node can apply one or more rules and / or AI systems to the determined summary records to intelligently determine a first revenue share rate associated with the first MP or other MPs associated with the first MaaS player. Thus, for large sets of transaction records, offloaded revenue share calculations on a disclosing system (which can reside outside the distributed ledger nodes) can be more efficient and consume less time and resources than calculations of revenue share rates within the MaaS platform, e.g., on nodes of the distributed ledger (e.g., MP nodes and MaaS nodes).

[0018] FIG. 1 is a diagram of an exemplary network environment for revenue share determination of transactions on a Mobility as a Service (MaaS) platform using a common database architecture, according to an embodiment of the present disclosure. FIG. 1 illustrates a block diagram of a network environment 100. The network environment 100 may include a first MaaS network 102 that may be associated with a publish-subscribe pattern. The first MaaS network 102 may include a first plurality of nodes that may be organized in tiers, such as a client tier 104, a broker tier 106, and a server tier 108. The first plurality of nodes may include a plurality of publisher nodes 110 in the client tier 104 and a broker node device 112 in the broker tier 106. The first plurality of nodes may further include a first plurality of subscriber nodes 114A, 114B, ..., and 114N, a first distributed ledger plurality of mobility provider (MP) nodes 116A, 116B, ..., and 116N, a second distributed ledger plurality of MaaS nodes 118A, 118B, ..., and 118N, an analytics node 122A, a monitor node 122B, an archive database node 124, and a cache database node 126 (hereinafter also referred to as system 126) in the server tier 108. The first plurality of subscriber nodes 114A, 114B, ..., and 114N, the plurality of MP nodes 116A, 116B, ..., and 116N, and the plurality of MaaS nodes 118A, 118B, ..., and 118N may collectively form a plurality of node packages 120 of the first MaaS network 102. For example, a first node package of the plurality of node packages 120 may include a first subscriber node 114A, a first MP node 116A, and a first MaaS node 118A. In another example, a second node package of the plurality of node packages 120 may include a second subscriber node 114B, a second MP node 116B, and a second MaaS node 118B. An analytics node 122A may be communicatively coupled to the plurality of node packages 120. An archive database node 124 may be communicatively coupled to the analytics node 122A.A plurality of publisher nodes 110 in the client tier 104 can be configured to communicate with a first plurality of subscriber nodes 114A, 114B, ..., and 114N through a broker node device 112. In some embodiments, the network environment 100 can include a plurality of broker node devices 112. In other embodiments, the network environment 100 can include an intelligent broker node that can include the functionality of one or more broker node devices.

[0019] The plurality of issuer nodes 110 may include a first issuer node 110A, a second issuer node 110B, ..., and an Nth issuer node 110N. The first plurality of subscriber nodes 114A, 114B, ..., and 114N may include a first subscriber node 114A, a second subscriber node 114B, ..., and an Nth subscriber node 114N. In an embodiment, each of the first plurality of subscriber nodes 114A, 114B, ..., and 114N may interface with the broker node device 112 through a plug-in for communication of data (e.g., transaction messages). Each of the first plurality of subscriber nodes 114A, 114B, ..., and 114N may be associated with a respective MP node and MaaS node. For example, the first subscriber node 114A may be associated with each of the first MP node 116A and the first MaaS node 118A. Additionally, the second subscriber node 114B can be associated with each of the second MP node 116B and the second MaaS node 118B. Similarly, the Nth subscriber node 114N can be associated with each of the Nth MP node 116N and the Nth MaaS node 118N.

[0020] The network environment 100 may further include a first server 128 and an administrator device 130 operable by an administrator 132 of the first MaaS network 102. The administrator device 130 may be used by the administrator 132 to access the first server 128 and perform one or more operations on the first server 128. The network environment 100 may further include users (not shown) that may interact with the multiple issuer nodes 110 to utilize mobility services from different mobility providers of the first MaaS network 102. The system 126 may include multiple aggregator nodes 134 and a central MaaS node 136, and the multiple aggregator nodes 134 may be communicatively coupled to the central MaaS node 136. The multiple aggregator nodes 134 may include a first aggregator node 134A, a second aggregator node 134B, ..., and an Nth aggregator node 134N. A system 126 including a plurality of aggregator nodes 134 and a central MaaS node 136 may be communicatively coupled to a plurality of node packages 120. The system 126 may further include a configuration database 138, a consumer database 140, and a transaction database 142. The network environment 100 may further include a scheduler node 144 and an artificial intelligence (AI) system 146. In one embodiment, the scheduler node 144 may be communicatively coupled to the plurality of node packages 120. Further, the AI ​​system 146 may be communicatively coupled to the monitor node 122B. The AI ​​system 146 may further be communicatively coupled to the system 126. In another embodiment, both the scheduler node 144 and the AI ​​system 146 may be communicatively coupled to the plurality of node packages 120.

[0021] 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 tier 104, a broker tier 106, and a server tier 108. The first MaaS network 102 may process transactions (e.g., transaction messages) for MaaS mobility services associated with multiple mobility providers. Each of such mobility providers may own, lease, or manage a set of nodes in each of the client tier 104 and server tier 108 of the first MaaS network 102. For example, the first issuer node 110A, the first subscriber node 114A, and the first MP node 116A may be associated with a first mobility provider. The second issuer node 110B, the second subscriber node 114B, and the first MP node 116A may be associated with a second mobility provider, which may be different from the first mobility provider.

[0022] In some embodiments, the first MaaS network 102 may support open standard specifications for MaaS. In such cases, multiple issuer nodes 110 (e.g., ticket readers or sensor devices) from different companies associated with various mobility providers of the first MaaS network 102 may participate in the first MaaS network 102 as homogeneous issuer nodes. Legacy ticket readers or sensor devices may also connect to the first MaaS network 102 based on utilizing standard communication protocols, such as a Message Queuing Telemetry Transport (MQTT)-based messaging protocol, an Advanced Message Queuing Protocol (AMQP)-based messaging protocol, or a Message Oriented Middleware (MOM)-based messaging framework. The first MaaS network 102 may provide ticket roaming functionality to users utilizing the standard communication protocols. For example, a ticket reader at any mobility provider can scan the user's electronic ticket for MaaS mobility services and provide the user with the mobility provider's respective mobility services (regardless of the ticket issuer) based on seamless and secure access of the first MaaS network 102.

[0023] According to an embodiment, each of the multiple MP nodes 116A, 116B, ... 116N can be associated with a different mobility provider in the first MaaS network 102. MaaS mobility services can be provided by homogeneous mobility providers (such as multiple taxi ride provider companies or multiple rail companies) or heterogeneous mobility providers through a homogeneous set of devices, applications, or ticket barriers, or a heterogeneous set of ticket barriers, applications, and point-of-sale (PoS) devices. A MaaS mobility service can be a combination of individual service offerings of one or more homogeneous or heterogeneous mobility providers. MaaS mobility services can include, for example, train services, bus services, taxi / cab services, subway services, airplane services, shipping services, ride hailing services, car sharing services, carpool services, rental car services, bike sharing services, or a combination thereof.

[0024] Each of the plurality of issuer nodes 110A, 110B, ..., 110N may include suitable logic, circuitry, code, and / or interfaces that may be configured to operate as a ticket processing client for a respective mobility provider's mobility service. For example, as a ticket processing client, each of the first issuer node 110A, the second issuer node 110B, ..., and the Nth issuer node 110N may read, issue, recharge, or cancel tickets to create events related to the respective mobility service. Each of the first issuer node 110A, the second issuer node 110B, ..., and the Nth issuer node 110N may generate transaction messages based on such events, which may be communicated via the broker node device 112 to one or more subscriber nodes of the first MaaS network 102 or other MaaS networks. Examples of issuer nodes may include consumer electronic devices with travel planning or booking applications, ticket readers on turnstiles, ticketing kiosks, point of sale (PoS) devices, mobile POS, ticket vending machines, and / or smart doors on transportation vehicles that can read a ticket to start or end a ride.

[0025] The broker node device 112 may include suitable logic, circuitry, code, and / or interfaces that may be configured to forward transaction messages from a publisher node (such as the first publisher node 110A) to an appropriate node, such as a subscriber node (such as the first subscriber node 114A). The broker node device 112 may be configured to communicate with each of the multiple publisher nodes 110A, 104B, ... 104N and the first plurality of subscriber nodes 114A, 114B, ... 114N through a suitable publish-subscribe network protocol, such as a Message Queuing Telemetry Transport (MQTT)-based messaging protocol, an Advanced Message Queuing Protocol (AMQP)-based messaging protocol, or a Message Oriented Middleware (MOM)-based messaging framework. Example implementations of the broker node device 112 may include an application server, a cloud server, a mainframe server, a database server, a web server, or other type of server.

[0026] Each of the first plurality of subscriber nodes 114A, 114B, ... 114N may include suitable 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 through the broker node device 112. In one embodiment, each of the first plurality of subscriber nodes 114A, 114B, ... 114N may interface with the broker node device 112 through a plug-in for communication of data (e.g., transaction messages). Each transaction message may include a topic to which one or more of the first plurality of subscriber nodes 114A, 114B, ... 114N may subscribe. Example implementations of subscriber nodes may include web servers, edge devices, edge nodes, cloud servers, clusters of cloud-based servers, workstations, and / or any computing device with fog or cloud computing capabilities.

[0027] Each of the MP nodes 116A, 116B, ... 116N may include suitable logic, circuitry, code, and / or interfaces that may be configured to store transaction records related to a respective mobility provider. For example, the first MP node 116A may store transaction records related to the first mobility provider. In one embodiment, each transaction record stored in each MP node may relate to a two-party transaction. For example, a transaction record stored in an MP node for a particular mobility provider may relate to a transaction that may involve the mobility provider and a MaaS provider. The transaction record may include a record of a user's journey. Each journey may correspond to a mobility service that the first mobility provider may provide during at least one leg of the journey. Each of the MP nodes 116A, 116B, ... 116N may be referred to as a node of a distributed ledger 116 (e.g., a first distributed ledger) that may store transaction records for various mobility providers in the first MaaS network 102. In one embodiment, each MP node may be implemented as, for example, an edge device, an edge node, or one of the distributed ledger nodes with fog or cloud computing capabilities.

[0028] Each of the MaaS nodes 120A, 120B, ... 120N may include suitable logic, circuitry, code, and / or interfaces that may be configured to store transaction records associated with all mobility providers in the first MaaS network 102. The storage of transaction records associated with each of the mobility providers may be used to settle travel transactions between mobility providers that provide mobility services to users. In some embodiments, each transaction record stored in each MaaS node may relate to a multi-party transaction. For example, a transaction record stored in a MaaS node may relate to a transaction that may involve one or more mobility providers and MaaS providers in the first MaaS network 102. In such cases, the MP node and the MaaS node may store the same transaction. Each of the MaaS nodes 118A, 118B, ... 118N may correspond to a node in a distributed ledger 118 (e.g., a second distributed ledger) that may store transaction records associated with the first MaaS network 102. In one embodiment, each MaaS node may be implemented as one of, but not limited to, an edge device, an edge node, or a distributed ledger node with fog or cloud computing capabilities.

[0029] In one embodiment, one or more of the plurality of node packages 120 may include a subscriber node, one or more of the MP nodes of a first distributed ledger, and a MaaS node of a second distributed ledger. For example, a first node package of the plurality of node packages 120 may include a first subscriber node 114A, a first MP node 116A, and a first MaaS node 118A. In another example, a second node package may include a second subscriber node 114B, a second MP node 116B, and a second MaaS node 118B. In some cases, MP nodes associated with different node packages may be associated with different mobility providers of the first MaaS network 102. In one example, the first MP node 116A may be associated with a first mobility provider (e.g., a taxi service provider), and the second MP node 116B may be associated with a second mobility provider (e.g., a subway service provider). In other aspects, an MP node (e.g., first MP node 116A) of one node package (e.g., first node package 120A) and an MP node (e.g., second MP node 116B) of another node package (e.g., second node package 120B) may be associated with the same mobility provider. In some embodiments, each node package of the plurality of node packages 120 may be connected to the client layer 104 through the broker layer 106 via a plug-in interface.

[0030] In some embodiments, at least two nodes of each of distributed ledger 116 and / or distributed ledger 118 can store transaction records related to the MaaS mobility service. The transaction records related to the MaaS mobility service can be included in a set of state objects, such as an initial state object and updated versions of the initial state object. Each state object can include a smart contract, contract code (or transaction rules agreed upon by the parties to the transaction), and state properties (which can be updated when the transaction record is updated based on a transaction message from the issuer node). By way of example and not limitation, each of distributed ledger 116 and distributed ledger 118 can be a Corda blockchain, an Ethereum blockchain, or a Hyperledger blockchain. For example, U.S. Patent Application No. 17 / 178,185, filed February 17, 2021, discloses details regarding distributed ledger 116 and distributed ledger 118.

[0031] In an embodiment, the first MP node 116A and the first MaaS node 118A can each be configured to receive the transaction message via the first subscriber node 114A. The first MP node 116A and the first MaaS node 118A can each update an initial state object associated with each of the distributed ledgers 116 and 118, respectively, based on the transaction message and output the updated state object. The first MP node 116A and the first MaaS node 118A can each construct a transaction that can include an initial state object with the initial transaction data and an updated state object with the updated transaction data.

[0032] The analytical node 122A may include suitable logic, circuitry, code, and / or interfaces that may be configured to store a first set of transaction records of the first plurality of transaction records associated with all mobility providers in the first MaaS network 102. Storage of the first set of transaction records at the analytical node 122A may be based on a first data retention threshold and a first storage period for the first plurality of transaction records on the first MaaS node 118A. For example, if the first data retention threshold is three days, all transaction records of the first plurality of transaction records that have a storage period (i.e., the first storage period) at the first MaaS node 118A of three days or greater may be selected as the first set of transaction records at the first MaaS node 118A. The analytical node 122A may receive the selected first set of transaction records from the first MaaS node 118A for storage at the analytical node 122A. In one embodiment, analytical node 122A can be configured to store selected transaction records from the first set of transaction records based on aggregation logic. In one embodiment, analytical node 122A can receive one or more queries related to the first set of transaction records stored in analytical node 122A from first server 128. Based on the one or more received queries, analytical node 122A can send one or more transaction records from the first set of transaction records to first server 128. Furthermore, analytical node 122A can store frequently queried transaction records of analytical node 122A in cache database node 126. According to one embodiment, analytical node 122A can be a node of a distributed ledger (e.g., distributed ledger 118) associated with first MaaS network 102 that can store the first set of transaction records related to mobility providers of first MaaS network 102. According to another embodiment, analytical node 122A can be a non-distributed ledger (or local) node.

[0033] The monitor node 122B may include suitable logic, circuitry, code, and / or interfaces that may be configured to periodically monitor a set of influence factors associated with each mobility provider in the first MaaS network 102. For example, the set of influence factors may be monitored at the end of each day (e.g., 11:59:59 PM). The set of influence factors associated with the mobility provider may be used to determine incentives or penalties that may be applied to the mobility provider's revenue share rate. An example set of influence factors is shown, for example, in FIG. 2 (216). The set of influence factors may be determined based on configuration data associated with the mobility provider, which may be stored in the configuration database 138. The monitor node 122B may transmit the monitored set of influence factors of the mobility provider to the central MaaS node 136 to determine the revenue share rate associated with the mobility provider based on the monitored set of influence factors. Examples of the monitor node 122B may include, but are not limited to, an Internet of Things (IoT)-based computing device, a smartphone, a mobile phone, or a consumer electronics device (CE) installed / used in the mobility provider's vehicle. Further examples of monitor node 122B may include, but are not limited to, an edge node, edge device, or fog or cloud computing enabled device capable of communicating with electronic devices installed / used in the mobility provider's vehicles.

[0034] The archive database node 124 may include suitable logic, circuitry, code, and / or interfaces that may be configured to store a second set of transaction records associated with all mobility providers in the first MaaS network 102. Storage of the second set of transaction records in the archive database node 124 may be based on a second data retention threshold and a second storage period of the third set of transaction records stored in the analytical node 122A. The third set of transaction records may include at least the first set of transaction records that may be stored in the analytical node 122A. For example, the second data retention threshold may be 60 days. In this case, the first MaaS node 118A may control the analytical node 122A to select, as the second set of transaction records, all transaction records that have a storage period (i.e., the second storage period) of 60 days or more from the third set of transaction records stored in the analytical node 122A. Here, the third set of transaction records may include at least the first set of transaction records received from the first MaaS node 118A. The third set of transaction records can further include other transaction records, which can be older or newer than the first set of transaction records. The first MaaS node 118A can further control to send the selected second set of transaction records to the archive database node 124 for storage therein. According to one embodiment, the archive database node 124 can be a node of a distributed ledger (e.g., the distributed ledger 118) associated with the first MaaS network 102 that can store a second set of transaction records related to mobility providers of the first MaaS network 102. According to another embodiment, the archive database node 124 can be a non-distributed ledger (or local) node that does not have a query mechanism. A non-distributed ledger-based node can be more cost-effective and faster than a distributed ledger-based node.

[0035] The cache database node 126 may include suitable logic, circuitry, code, and / or interfaces that may be configured to aggregate transaction records of various MP nodes and determine revenue share rates associated with various mobility providers associated with the first MaaS network 102 based on the aggregated transaction records. The cache database node 126 (also referred to hereinafter as system 126) may be communicatively coupled to multiple node packages 120. In an embodiment, the cache database node 126 may also be configured to store frequently queried transaction records of the analytics node 122A in a high-speed temporary memory or database (e.g., transaction database 142). The cache database node 126 may facilitate a reduced workload for other database nodes, such as the multiple MP nodes 116A, 116B, ... 116N, the multiple MaaS nodes 118A, 118B, ... 118N, the analytics node 122A, and the archive database node 124. For example, if the number of transaction records associated with the first MP node 116A within a certain period of time is greater than a certain threshold (e.g., 1 million transaction records), the first MaaS node 118A may offload the processing or analysis of such large number of transaction records associated with the first MP node 116A to the cache database node 126. By way of example and not limitation, given such a large number of transaction records for the first MP node 116A, calculation of the mobility provider's revenue share corresponding to the first MP may be offloaded to the cache database node 126.

[0036] In one embodiment, system 126 (i.e., cache database node 126) may reside within first MaaS network 102 (as shown in FIG. 1 ). Alternatively, system 126 may reside outside first MaaS network 102. In some embodiments, system 126 may be omitted (or not used if present) within network environment 100, and one or more database nodes, such as multiple MP nodes 116A, 116B, ... 116N, multiple MaaS nodes 118A, 118B, ... 118N, analytics node 122A, and archive database node 124, may perform the functions of system 126. For example, system 126 may be omitted (or not used) within network environment 100 if the number of transaction records associated with first MP node 116A within a certain period of time is below a certain threshold (e.g., several thousand transaction records). In such cases, one or more distributed ledger or blockchain nodes (such as multiple MP nodes 116A, 116B, ... 116N) of the first MaaS network 102 and other database nodes (such as multiple MaaS nodes 118A, 118B, ... 118N, analytics node 122A, and archive database node 124) can efficiently process or analyze such transaction records related to the first MP node 116A.

[0037] Each of the plurality of aggregator nodes 134 may include suitable logic, circuitry, interfaces, and / or code that may be configured to aggregate transaction amounts associated with each of a set of transaction records associated with an MP node (e.g., the first MP node 116A). The aggregator node (e.g., the first aggregator node 134A) may determine a first summary record associated with the MP node based on the aggregation of the transaction amounts associated with each of the set of transaction records. The determination of the first summary record may be further based on a first set of parameters. According to an embodiment, each of the plurality of aggregator nodes 134 may be a non-distributed ledger (or local) node. Non-distributed ledger-based nodes may be more cost-effective and faster than distributed ledger-based nodes. In one embodiment, each of the plurality of aggregator nodes 134 may be implemented in or apply at least one of, but not limited to, a big data platform, a Hadoop platform, or a MapReduce platform to the set of transaction records and / or the first set of parameters to determine the first summary record. The plurality of aggregator nodes 134 may be configured to parallelize the aggregation of the set of transaction records for each MP node in the first MaaS network 102. Examples of the plurality of aggregator nodes 134 may include, but are not limited to, database nodes, mainframe machines, servers, computer workstations, and / or any computing device having aggregation logic.

[0038] The central MaaS node 136 may include suitable logic, circuitry, interfaces, and / or code that may be configured to receive a set of summary records associated with an MP node (e.g., a first MP node 116A) from a plurality of aggregator nodes 134. The set of summary records may include at least a first summary record. The central MaaS node 136 may aggregate transaction amounts associated with each of the received set of summary records to determine a second summary record associated with the MP node. Furthermore, the central MaaS node 136 may determine a revenue share rate associated with the mobility provider corresponding to the MP node based on the determined second summary record. According to one embodiment, each of the plurality of aggregator nodes 134 may be a non-distributed ledger (or local) node. Non-distributed ledger-based nodes may be more cost-effective and faster than distributed ledger-based nodes. Examples of the central MaaS node 136 may include, but are not limited to, a database node, a mainframe machine, a server, a computer workstation, and / or any computing device having aggregation logic.

[0039] The configuration database 138 (also referred to as config. database 138) may include suitable logic, circuitry, interfaces, and / or code that may be configured to store configuration data associated with a mobility provider. The configuration data associated with a mobility provider may include a revenue share configuration that may be generated based on onboarding an MP node associated with the mobility provider to the first MaaS network 102. The configuration data may be used to determine a revenue share associated with the mobility provider. For example, the configuration data for a first MP may specify that 10% of the revenue earned by the first MP should be paid to the first MaaS player as a MaaS fee. In one example, the configuration data may include a second set of parameters and / or a set of influencing factors associated with the mobility provider. For example, the second set of parameters may include a fee associated with the first MaaS player corresponding to the first MaaS node, a carbon dioxide emission associated with the first MP, green energy incentives earned by the first MP, traffic congestion relief achieved by the first MP, and / or a fare slab for rides associated with the first MP. An example set of influencers may include incubation or innovation of new mobility modes, environmental sustainability, carbon impact, aggregate economic growth, normalization of traffic capacity, and / or health and wellness initiatives. According to one embodiment, the configuration database 138 may be a non-distributed ledger (or local) node. Non-distributed ledger-based nodes may be more cost-effective and faster than distributed ledger-based nodes.

[0040] The consumer database 140 may include suitable logic, circuitry, interfaces, and / or code that may be configured to store mobility provider data associated with each mobility provider associated with the first MaaS network 102. For example, the mobility provider data associated with the MP may include details of data ownership for the MP, a service agreement between the MP and the MaaS player, terms or services associated with the service agreement, a privacy policy associated with the service agreement, process services associated with the service agreement, and / or a revenue model associated with the MP and the MaaS player. Once an MP node (e.g., the first MP node 116A) is onboarded to the first MaaS network 102, it may register with a particular MaaS node (e.g., the first MaaS node 118A) to create a node package (e.g., the first node package 120A). Furthermore, at this stage, mobility provider data associated with the MP corresponding to the MP node is generated and stored in the consumer database 140. According to an embodiment, the consumer database 140 may be a non-distributed ledger (or local) node. Non-distributed ledger-based nodes can be more cost-effective and faster than distributed ledger-based nodes.

[0041] The transaction database 142 may include suitable logic, circuitry, interfaces, and / or code that may be configured to store transaction records associated with each of the plurality of MP nodes 116A, 116B, ... 116N received from the plurality of MaaS nodes 118A, 118B, ... 118N. In one embodiment, the transaction database 142 may also store frequently queried transaction records associated with the analytics node 122A in a high-speed temporary memory or database. According to one embodiment, the transaction database 142 may be a non-distributed ledger (or local) node. A non-distributed ledger-based node may be more cost-effective and faster than a distributed ledger-based node.

[0042] The scheduler node 144 may include suitable logic, circuitry, interfaces, and / or code that may be configured to generate trigger events associated with each of the plurality of node packages 120. In one embodiment, a trigger event associated with a node package (e.g., the first node package 120A) is based on at least one of a predetermined schedule or receipt of a predetermined number of transaction records at the node package's MaaS node (e.g., the first MaaS node 118A). Examples of the scheduler node 144 may include, but are not limited to, a smartphone, a mobile phone, a mainframe machine, a server, a computer workstation, and / or any computing device having a schedule-based or event-based triggering mechanism.

[0043] The AI ​​system 146 may include suitable logic, circuitry, interfaces, and / or code that may be configured to determine a revenue share rate associated with a mobility provider associated with the first MaaS network 102 based on a second summary record associated with the mobility provider's MP node and / or a parameter set associated with the revenue determination. For example, the parameter set may include a second parameter set that may be determined from a set of influence factors monitored by the monitor node 122B. In some embodiments, the AI ​​system 146 may be further trained on an environmental impact analysis task. In some embodiments, the environmental impact analysis task may include determining a score for a trend in the change in the value of each of the set of influence factors associated with the first MP. Based on the determined score, future changes in the value of the set of influence factors associated with the first MP may be predicted. The AI ​​system 146 may include an AI model, such as a regression model (e.g., AI model 812D of FIG. 8 ), that may be trained to identify a relationship between inputs, such as features in a training dataset, and output values, such as the MP's revenue share rate / percentage, the MP's absolute revenue value, or the influence factor score associated with the MP. The AI ​​model can be defined by hyperparameters, such as the number of weights, cost function, input size, and number of layers. The hyperparameters of the AI ​​model can be adjusted to move toward a global minimum of the AI ​​model's cost function, and the weights can be updated accordingly. After training for several epochs on feature information in the training dataset, the AI ​​model can be trained to output a determined revenue share result or influence factor score for a set of inputs (e.g., a second summary record, a second set of parameters, and / or a set of influence factors). The determined output can indicate a predicted revenue value for a set of inputs (e.g., input features extracted from new / undiscovered instances).

[0044] The AI ​​model may include electronic data that may be implemented, for example, as a software component of an application executable on an electronic device associated with the AI ​​system 146. The AI ​​model may rely on libraries, external scripts, or other logic / instructions for execution by processing circuitry of the electronic device associated with the AI ​​system 146. The AI ​​model may include code and routines configured to enable the electronic device associated with the AI ​​system 146 to perform one or more operations, such as determining the MP's revenue share / percentage or absolute revenue value. Additionally or alternatively, the AI ​​system 146 may be implemented using hardware, including a processor, microprocessor (e.g., performing or controlling one or more operations), field programmable gate array (FPGA), or application specific integrated circuit (ASIC). Alternatively, in some embodiments, the AI ​​system 146 may be implemented using a combination of hardware and software.

[0045] The first server 128 may include suitable logic, circuitry, interfaces, and / or code that may be configured to query one or more first transaction records stored in the analytical node 122A and verify one or more transactions associated with the one or more queried first transaction records. The first server 128 may further be configured to query one or more second transaction records stored in the archive database node 124 and control the display of statistical information associated with the one or more queried second transaction records. In some embodiments, if the one or more second transaction records are cached by the cache database node 126, the first server 128 may be configured to query one or more third transaction records from the one or more second transaction records stored in the cache database node 126. The first server 128 may similarly control the display of statistical information associated with the one or more queried third transaction records.

[0046] According to some embodiments, the first server 128 may be configured to process API requests, such as API requests related to transaction validation, analysis, or visualization. The API requests may be processed based on one or more first transaction records stored in the analysis node 122A and / or one or more second transaction records stored in the archive database node 124 (or cache database node 126). According to some embodiments, the first server 128 may provide API services that are programmable based on scripting languages ​​such as, but not limited to, JavaScript or Python. The first server 128 may be implemented as a cloud server or cluster of cloud servers that can perform operations through web applications, cloud applications, HTTP requests, repository operations, file transfers, and the like. Other implementations of the first server 128 may include, but are not limited to, a database server, a file server, a web server, a media server, an application server, a mainframe server, or a cloud computing server.

[0047] In at least one embodiment, first server 128 may be implemented as multiple distributed cloud-based resources using techniques known to those skilled in the art. Those skilled in the art will appreciate that the scope of the present disclosure may not be limited to the implementation of first server 128 and broker node device 112 as two independent entities. In some embodiments, the functionality of first server 128 may be incorporated, in whole or at least in part, into broker node device 112 without departing from the scope of the present disclosure.

[0048] According to an embodiment, a first server 128 associated with each of the analytical node 122A and the archive database node 124 can be configured to send queries of one or more first transaction records stored at the analytical node 122A to the analytical node 122A. In an exemplary scenario, the first server 128 can frequently query the one or more first transaction records. The one or more first transaction records can be queried, for example, to resolve a dispute between an organization managing the first MaaS network 102 and one or more mobility providers of the first MaaS network 102, or between two or more mobility providers of the first MaaS network 102.

[0049] The first server 128 may further receive the one or more queried first transaction records from the analysis node 122A. The received one or more first transaction records may, for example, be associated with transaction messages related to the same mobility provider or different mobility providers. Furthermore, the first server 128 may verify one or more transactions associated with the queried one or more first transaction records. The verification of the one or more transactions may be performed by the first server 128, for example, to resolve disputes. For example, the first server 128 may determine a total transaction amount and revenue amount to be allocated between an organization (i.e., an organization managing the first MaaS network 102) and one or more mobility providers that may have provided mobility services related to the transaction. The first server 128 may verify a match between the total transaction amount and the total allocated revenue amount. Furthermore, the first server 128 may verify that the revenue allocation is in accordance with a predetermined revenue allocation agreement between the organization and the various mobility providers of the first MaaS network 102. In some embodiments, the revenue sharing may be based on protocols such as smart contracts associated with distributed ledger technology. Thus, the first server 128 may verify that the revenue sharing complies with the smart contracts between the organization and the various mobility providers of the first MaaS network 102.

[0050] According to an embodiment, the first server 128 may be further configured to send a query to the archive database node 124 for one or more second transaction records stored in the archive database node 124. The first server 128 may further receive the queried one or more second transaction records from the archive database node 124. The one or more second transaction records stored in the archive database node 124 may be queried to enable dispute resolution, audit, and compliance tasks related to the first MaaS network 102, for example.

[0051] The first server 128 may further display statistical information related to the queried one or more second transaction records. The statistical information related to the queried one or more second transaction records may include a transaction identification (ID) for each of the queried one or more second transaction records, a timestamp associated with each of the queried one or more second transaction records, and / or a routing path for each of the queried one or more second transaction records. The statistical information may further include a distribution of the transaction records across each mobility provider, a distribution of transaction values ​​across each mobility provider, a distribution of the transaction records across days, weeks, months, or years, and / or a distribution of the transaction records across users of the first MaaS network 102.

[0052] According to some embodiments, cache database node 126 may be configured to receive one or more queried second transaction records from archive database node 124. Cache database node 126 may store the received one or more second transaction records in cache database node 126. Cache database node 126 may further receive a query for one or more third transaction records from first server 128. The one or more third transaction records may be included in the one or more second transaction records stored in cache database node 126. Cache database node 126 may transmit the one or more third transaction records to first server 128 based on the received query for the one or more third transaction records. In some embodiments, the one or more third transaction records may be frequently queried transaction records of archive database node 124. Thus, the first server 128 can easily access one or more third transaction records for use in dispute resolution, audit and compliance tasks, and the like, related to the first MaaS network 102.

[0053] In one embodiment, one or more new node packages can be added to the plurality of node packages 120 to expand the first MaaS network 102. Each of the one or more new node packages can include a subscriber node and a set of pre-configured nodes for a mobility provider (e.g., a local MP node) and a MaaS provider (e.g., a local MaaS node). The subscriber node and the set of pre-configured nodes of the one or more new node packages can be deployed as one of, but not limited to, edge nodes, edge devices, or fog or cloud computing-enabled devices to improve transaction performance and throughput. The MaaS provider node (e.g., a local MaaS node) can connect to an analytics node 122A (e.g., a central node) for data integration. Additionally, the subscriber node of the new node package can connect to the broker layer 106 (including the broker node device 112) through a plug-in interface. In one embodiment, the analytics node 122A can be a node in the distributed ledger 118 associated with the MaaS provider.

[0054] When a MaaS provider node (e.g., a local MaaS node) is connected to the analytical node 122A, the MaaS provider node (e.g., a local MaaS node) can select a first set of transaction records from a plurality of transaction records stored at the MaaS provider node (e.g., the local MaaS node) and send the selected first set of transaction records to the analytical node 122A for storage. The selection of the first set of transaction records can be based on a storage period for each of the plurality of transaction records on the MaaS provider node (e.g., the local MaaS node) and a data retention threshold associated with the MaaS provider node (e.g., the local MaaS node). Further, the analytical node 122A can be configured to select a second set of transaction records from a third set of transaction records stored at the analytical node 122A and send the selected second set of transaction records to the archive database node 124 for storage. The selection and sending of the second set of transaction records can be based on the analytical node 122A receiving an instruction from the MaaS provider node (e.g., the local MaaS node). The selection of the second set of transaction records can be based on a second storage period for a third set of transaction records on analytical node 122A and a second data retention threshold for analytical node 122A. In some embodiments, the third set of transaction records can include at least the first set of transaction records. For example, U.S. Patent Application No. 17 / 178,185, filed February 17, 2021, discloses data retention thresholds and storage periods in detail. Note that the data retention thresholds and storage periods described by the cited application are merely examples. However, other different examples of data retention thresholds and storage periods may exist without departing from the scope of this disclosure.

[0055] In one embodiment, each node package of the plurality of node packages 120 can be implemented as one of a set of edge nodes, a set of edge devices, or a set of fog or cloud computing-enabled devices. The nodes (e.g., subscriber nodes, MP nodes, and MaaS nodes) of each node package can be deployed in physical proximity to the plurality of issuer nodes 110A-110N (i.e., the client tier 104) of the first MaaS network 102. This physical proximity can reduce transaction latency and limit the capacity of the client tier 104 based on the performance limitations of the plurality of node packages 120, thereby further reducing transaction failures. Furthermore, the transaction processing capacity of the first MaaS network 102 can be expanded by adding new node packages to the first MaaS network 102. Each such node package can be easily configured based on a configuration template that can bind a pre-configured set of MP nodes and MaaS nodes to subscriber nodes. The subscriber nodes of the new node package can connect to the broker node device 112 of the first MaaS network 102 through a plug-in interface. Additionally, MaaS nodes in the new node package can connect to analytics node 122A. The MaaS nodes can then begin archiving transaction records to analytics node 122A, as described above, and then to archive database node 124. Additionally, analytics node 122A can utilize merged transaction records from multiple MaaS nodes 118A, 118B, ... 118N for revenue sharing between the MaaS provider and one or more mobility providers, and for data analysis.

[0056] Figure 2 is an exemplary sequence diagram illustrating revenue share determination for large-scale transactions on a Mobility as a Service (MaaS) platform using a common database architecture, according to an embodiment of the present disclosure. Figure 2 is described with reference to elements of Figure 1. Figure 2 illustrates a sequence diagram 200 illustrating a series of operations 202A-220 that may be performed by various nodes of the first MaaS network 102 (e.g., the first MP node 116A, the first MaaS node 118A, the first aggregator node 134A, and the central MaaS node 136) of Figure 1.

[0057] At 202A and 202B, a first MP node 116A may be onboarded to a first node package 120A. In one embodiment, the first MP node 116A and the first MaaS node 118A may be configured to communicate with each other to onboard the first MP node 116A to the first node package 120A. In one embodiment, based on the communication between the first MP node 116A and the first MaaS node 118A for onboarding, a first MP corresponding to the first MP node 116A and a first MaaS player associated with the first MaaS node 118A may be associated with the first MaaS network 102. In one embodiment, when a mobility provider (MP) joins the first MaaS network 102 or adds an MP node corresponding to the mobility provider to a newly created node package, the new MP node may be onboarded to the new node package based on an agreement or smart contract with the MaaS player corresponding to the new MaaS node associated with the new node package. For example, a first MP corresponding to the first MP node 116A can be onboarded to the first node package 120A based on its association with a first MaaS player corresponding to the first MaaS node 118A of the first node package 120A. The association of the first MP and first MaaS player with the first MaaS network 102 can be based on a service agreement, revenue sharing model, data ownership agreement, terms of service agreement, privacy policy, and / or policy amendments associated with the region of operation of at least one of the first MP or first MaaS player. For example, onboarding the first MP node 116A can include registration of a data owner (e.g., an organization or person that owns, operates, manages, or has an interest in the first mobility provider) associated with the first MP node 116A. In one embodiment, information required for registration can be received from an administrator 132 via the administrator device 130.The first MP node 116A can provide the information necessary for registration to the first MaaS node 118A, and the first MaaS node 118A can create a data ownership agreement based on the registration. After the onboarding process, the first MP, the first MaaS player, and the first MaaS network 102 can be bound by the data ownership agreement.

[0058] In some embodiments, the onboarding process of the first MP node 116A may further include generating configuration data associated with the first MP. The configuration data may include a revenue sharing configuration associated with the first MP and the first MaaS provider. The revenue sharing configuration may be created based on user input received from a data owner of the first MP node 116A via the data owner's computing device. The revenue sharing configuration may also be created or modified based on user input received from the administrator 132 via the administrator device 130. The revenue sharing configuration may include a set of consents associated with the first MP to share transaction data associated with the first MP. For example, the set of consents may include a first consent from the first MP allowing or denying submission of transaction records associated with the first MP for revenue calculation by the first MaaS network 102 and / or system 126. The set of consents may further include a second consent from the first MP allowing or denying MaaS players access to the submitted transaction records for revenue summarization and sales transaction sharing. The set of consents may further include a third consent from the first MP that grants or denies access to the transaction record in the event of an inquiry from another mobility provider. If the third consent indicates granting access to the transaction record, the third consent may also include information indicating mobility providers and / or MaaS players in the first MaaS network 102 with whom the transaction record can be shared in response to an inquiry. The set of consents may further include a fourth consent from the first MP that grants, partially grants, or denies archiving of the transaction record based on a request from the other mobility provider. In the case of partial permission, the fourth consent may also include information indicating mobility providers and / or MaaS players in the first MaaS network 102 with whom the transaction record can be shared for archiving. Configuration data including the revenue sharing configuration may be stored in the configuration database 138.

[0059] The onboarding process may further include registering a service contract for the business process between the first MP corresponding to the first MP node 116A and the first MaaS player corresponding to the first MaaS node 118A associated with the first node package 120A. The service contract registration may be based on specific terms of service and privacy policy that both the first MP and the first MaaS player can mutually agree upon. The first MP node 116A may create the service contract, terms of service, and privacy policy based on confirmation received from the first MP node 116A and / or the administrator device 130 (based on user input of the administrator 132). Additionally, the onboarding process for the first MP node 116A may be based on a specific revenue sharing model that may specify information such as the first MP node's transaction count, transaction amount or value, MaaS platform fees, first MaaS player fees, penalties associated with the first MP's vehicle's carbon dioxide emissions, and / or incentives associated with the first MP's use of clean fuels. The onboarding process may further include data registration based on terms of use of transaction data associated with the first MP. In some scenarios, the first MP and / or the first MaaS player may operate in multiple geographic regions or jurisdictions. In such cases, the onboarding process may also include policy amendments applicable to the service agreement, terms of service, privacy policy, and / or terms of use based on legal requirements of the geographic region in which at least one of the first MP or first MaaS player operates.

[0060] Based on onboarding the first MP node 116A to the first node package 120A, the first MP node 116A may be added to the first node package 120A, and a first smart contract between the first MP and the first MaaS player may be created. In other words, the first MP node 116A of the first node package 120A may be associated with the first MaaS node 118A based on the first smart contract. In some embodiments, based on a set of transaction records of the first MP node 116A, the first smart contract may be executed to determine a revenue share rate associated with the first MP. Onboarding the first MP node 116A may ensure that the determination of the revenue share rate of the first MP complies with a set of pre-agreed terms and conditions, privacy policy, and service agreement (or first smart contract) between the first MP and the first MaaS player. In this manner, the determination of the first MP's revenue share rate can be offloaded to the system 126 based on the onboarding process of the first MP node 116A, while the terms of business, privacy policy, and service agreement between the first MP and the first MaaS player can remain enforceable and valid. This addresses data privacy and contractual concerns between the first MP and the first MaaS player. An entity-relationship (ER) diagram for the onboarding process of the MP node and the revenue calculation of the mobility player associated with the MP node is further described, for example, in FIG. 6. The sequence of operations of the onboarding process of the MP node is further described, for example, in FIG. 7.

[0061] In another embodiment, the first MaaS network 102 may include multiple central MP nodes (not shown in FIG. 1 or FIG. 2). Each of the multiple central MP nodes may be associated with a particular mobility provider and may be communicatively coupled to the MP node(s) of the respective mobility provider. For example, a first central MP node may be associated with a first MP (and coupled to the first MP node 116A), and a second central MP node may be associated with a second MP (and coupled to the second MP node 116B). In some scenarios, each of multiple node packages may include MP nodes associated with a single MP. In such cases, a single central MP node may be associated with each MP node (of that single MP) that may be included in such multiple node packages. In some embodiments, the onboarding processing of an MP node may be performed by a central MP node associated with the MP node, which may be associated with the same mobility provider as the MP node.

[0062] A trigger event may be received at 204A (or 204B). In some embodiments, the first MP node 116A (204A) and / or the first MaaS node 118A (204B) may be configured to receive the trigger event from the scheduler node 144. While both 204A and 204B are shown in FIG. 2, in some embodiments, only the first MaaS node 118A, and not the first MP node 116A, may receive the trigger event at 204B without departing from the scope of this disclosure. In such cases, 204A may be omitted from sequence diagram 200.

[0063] In one embodiment, the scheduler node 144 can be configured to generate a trigger event associated with the first node package 120A. In one embodiment, the trigger event can be generated based on at least one of a predetermined schedule or receipt of a predetermined number of transaction records at the first MaaS node 118A. For example, the trigger event can be generated at the end of each day (e.g., 11:59:59 PM each day). In another example, the trigger event can be generated when a predetermined number of transaction records associated with the first MP node 116A (e.g., 100,000 transaction records) are received at the first MaaS node 118A. The first MaaS node 118A (and / or the first MP node 116A) can be configured to receive the trigger event from the scheduler node 144.

[0064] At 206, a first set of transaction records associated with the first MP node 116A may be transmitted. In an embodiment, the first MaaS node 118A may be configured to transmit the first set of transaction records associated with the first MP node 116A to a first aggregator node 134A of the system 126. The first aggregator node 134A may be configured to receive the first set of transaction records from the first MaaS node 118A. Each of the first set of transaction records may be associated with a transaction message received by the first subscriber node 114A of the first node package 120A. In one example, the first set of transaction records associated with the first MP node 116A may include transaction records for a predetermined period of time (e.g., a particular day) of the first MP node 116A in preparation for a trigger event being generated at the end of each day. In another example, the first series of transaction records may include a predetermined number of transaction records of the first MP node 116A (e.g., the most recent 100,000 transaction records) in preparation for a trigger event being generated upon receipt of the series of 100,000 transaction records related to the first MP node 116A.

[0065] At 208, a first summary record associated with the first MP node 116A may be determined. In one embodiment, the first aggregator node 134A may be configured to determine the first summary record associated with the first MP node 116A based at least on an aggregation of transaction amounts associated with each of the received first series of transaction records. For example, the first aggregator node 134A may determine a sum of the transaction amounts or transaction values ​​for each of the received first series of transactions and determine the first summary record based on the determined sum. In one embodiment, the first summary record may indicate a total transaction amount for the received first series of transactions. Determining the first summary record is further described, for example, with reference to FIG. 5.

[0066] In some embodiments, the determination of the first summary record associated with the first MP node 116A can be further based on a first set of parameters. Examples of the first set of parameters can include business information associated with the first MP, service item information associated with each of the first series of transaction records, ticket sales data associated with each of the first series of transaction records, fare price master data associated with the first MP, service price master data associated with the first MP, and / or ticket transaction data associated with each of the first series of transaction records. For example, the business information associated with the first MP can include the name, address, number of vehicles, and / or vehicle type associated with the business corresponding to the first MP. The service item information associated with each of the first series of transaction records can include the date / time of the trip associated with each of the first series of transaction records, the duration of the trip (based on pick-up / drop-off transaction messages), the distance traveled in the trip, and / or the type of vehicle associated with the trip. The ticket sales data associated with each of the first series of transaction records may include a price of a travel ticket associated with each of the first series of transaction records and / or a price of a travel itinerary associated with the first MP. The fare price master data associated with the first MP may include a travel leg distance-based fare table and / or a travel leg duration-based fare table associated with the first MP. The service price master data associated with the first MP may include a transportation surcharge, a wait time surcharge, a travel leg surcharge, a day-of-week-based surcharge, a time-based surcharge, a holiday surcharge, and / or a service tax associated with the first MP. The ticket transaction data associated with each of the first series of transaction records may include, but is not limited to, transaction data corresponding to a travel itinerary associated with the first MP from the ticket data in each of the first series of transaction records.

[0067] In some embodiments, the determination of the first summary record may be further based on applying a big data platform, a Hadoop platform, and / or a MapReduce platform to at least one of the transaction amount or the first set of parameters associated with each of the received first set of transaction records. For example, the first aggregator node 134A may offload the determination of the first summary record to the big data platform and parallelize the determination of the first summary record based on the received first set of transaction records and / or the first set of parameters. Based on the use of the big data platform, large-scale transactions (e.g., millions of transaction records) associated with the first MP node 116A may be processed in parallel to determine the first summary record efficiently, in a shorter timeframe, and more cost-effectively than conventional systems.

[0068] The first summary record may be transmitted at 210. In an embodiment, the first aggregator node 134A may be configured to transmit the determined first summary record associated with the first MP node 116A to the central MaaS node 136. The central MaaS node 136 may be configured to receive the first summary record from the first aggregator node 134A.

[0069] At 212, a set of summary records may be received. In an embodiment, the central MaaS node 136 may be configured to receive a set of summary records associated with the first MP node 116A from the multiple aggregator nodes 134. The set of summary records may include at least a first summary record received from the first aggregator node 134A.

[0070] At 214, a second summary record may be determined. In one embodiment, the central MaaS node 136 may be configured to determine a second summary record associated with the first MP node 116A based at least on an aggregation of transaction amounts associated with each of the received set of summary records. For example, the central MaaS node 136 may aggregate transaction amounts associated with each of the received set of summary records to determine a total transaction amount for each of a plurality of transaction records associated with the first MP node 116A stored in various node packages of the first MaaS network 102. In one embodiment, the second summary record may indicate a total transaction amount for each of a plurality of transaction records associated with the first MP node 116A stored in various node packages of the first MaaS network 102. Determining the second summary record is further described, for example, with respect to FIG. 5.

[0071] One or more of the aggregator nodes 134 may have already aggregated transaction amounts for multiple transaction records to determine a set of summary records. Therefore, determining the second summary record (based on the aggregated transaction amounts associated with the set of summary records) may be a computationally inexpensive task for the central MaaS node 136. In some embodiments, the determination of the second summary record may not be parallelized. However, in some scenarios, the first MaaS network 102 may be a large network with many node packages operating in multiple regions. In such cases, the determination of the second summary record may be parallelized based on the use of, for example, a big data platform, a Hadoop platform, and / or a MapReduce platform.

[0072] At 216, a first revenue share rate can be determined. In one embodiment, the central MaaS node 136 can be configured to determine a first revenue share rate associated with the first MP corresponding to the first MP node 116A based on the determined second summary record. For example, the second summary record can include a total transaction amount for each transaction corresponding to the multiple transaction records associated with the first MP node 116A. The first revenue share rate associated with the first MP can be determined based on the total transaction amount. The total transaction amount can be used as an indicator of revenue or loyalty earned by the first MP for providing services to customers through the first MaaS network 102 during a certain time frame or accounting period. Determining the first revenue share rate is further described, for example, with reference to FIG. 5.

[0073] In one embodiment, the monitor node 122B may be configured to periodically monitor a set of impact factors associated with the first MP. For example, the set of impact factors may be monitored at the end of each day (e.g., 11:59:59 PM). The set of impact factors may be determined based on configuration data associated with the first MP, which may be stored in the configuration database 138. Examples of the set of impact factors may include new mobility mode incubation or innovation, environmental sustainability, carbon dioxide impact, total economic growth, traffic capacity normalization, and / or health and welfare initiatives. The set of impact factors associated with the first MP may be used to determine incentives or penalties that may be applied to the first revenue share rate of the first MP. In one embodiment, the monitor node 122B may generate historical data associated with the set of impact factors based on the periodically monitored values ​​of each of the set of impact factors. For example, the monitor node 122B may compare a first value of the set of impact factors determined within a previous time interval with a second value of the set of impact factors determined within a current time interval to determine a change trend in the values ​​of the set of impact factors. The determined change trend can be stored as historical data. The historical data can also include a first value and a second value of the set of influence factors. The monitor node 122B can periodically (e.g., at the end of each day) transmit the change trend of the values ​​of the set of influence factors associated with the first mobility provider to the central MaaS node 136.

[0074] In some embodiments, the determination of the first revenue share rate associated with the first MP may be further based on a second set of parameters. Examples of the second set of parameters may include a fee associated with the first MaaS player corresponding to the first MaaS node, a carbon dioxide emission amount associated with the first MP, a green energy incentive earned by the first MP, a traffic congestion reduction achieved by the first MP, and / or a fare slab for a vehicle associated with the first MP. In some embodiments, the central MaaS node 136 may be configured to determine the second set of parameters based on a change trend in the values ​​of a set of impact factors associated with the first MP. For example, the carbon dioxide emission amount may be determined based on carbon dioxide impact. Furthermore, the green energy incentive may be determined based on the incubation or innovation of new mobility modes and / or environmental sustainability. The traffic congestion reduction may be determined based on the normalization of traffic capacity.

[0075] For example, the first MaaS player may charge a fixed fee (e.g., 10% of the transaction amount) for each transaction. The first MP may earn or lose points, a percentage of the transaction amount, as an incentive or penalty for each transaction based on the carbon dioxide emissions of the first MP's vehicles. Similarly, the first MP may earn an incentive for each transaction based on the green energy source used by the first MP. Furthermore, the degree of traffic congestion alleviated by the first MP's vehicles may be determined based on the total number of rides (or the number of customers transported) during peak hours or transportation hotspots. The first MP may earn an incentive based on the degree of traffic congestion alleviated. The first MP may also earn an incentive or receive a penalty based on the fare slab for rides associated with the first MP. For example, the first MP may earn an incentive or receive a penalty based on a traffic surcharge, a waiting time surcharge, a journey duration surcharge, a day-of-week-based surcharge, a time-of-day-based surcharge, and / or a holiday surcharge.

[0076] In some embodiments, determining the first revenue share rate associated with the first MP may be further based on applying an AI system 146 (e.g., AI model 812D in FIG. 8 ) to at least one of the determined second summary record or the second parameter set. The AI ​​system 146 may be pre-trained for the revenue share rate determination task. In some embodiments, the AI ​​system 146 may be trained based on configuration data, revenue model, service agreement, terms of service, and / or privacy policy associated with the first MP stored in the configuration database 138. The central MaaS node 136 may provide the determined second summary record and / or second parameter set to the AI ​​system 146. The AI ​​system 146 may determine the first revenue share rate associated with the first MP based on the provided second summary record and / or second parameter set.

[0077] In some embodiments, the AI ​​system 146 can be further trained on an environmental impact analysis task. In some embodiments, the AI ​​system 146 can determine a score for the change trend of each value of a set of impact factors associated with the first MP. The AI ​​system 146 can predict future changes in the values ​​of the set of impact factors associated with the first MP based on the determined scores. The predicted future changes in the values ​​of the set of impact factors can indicate future environmental impacts resulting from the operation of the first MP. The central MaaS node 136 can update the determined first revenue share rate associated with the first MP based on the predicted changes in the values ​​of the set of impact factors associated with the first MP. For example, if the change in the predicted carbon dioxide impact value is positive, the future carbon dioxide impact can indicate a decrease in carbon dioxide levels. In such a case, the determined first revenue share rate can be updated with an incentive for a positive future carbon dioxide impact. Similarly, the determined first revenue share rate can also be updated with an incentive for a positive future capacity normalization and a positive future environmental sustainability. For example, in some scenarios, such an incentive to the first MP can be paid to the first MP as a state subsidy for the positive future environmental impacts of the first MP's operations. In some scenarios, the central MaaS node 136 can update the first MP's configuration data stored in the configuration database 138 based on the future positive environmental impacts. For example, the first MP's configuration data may initially indicate that the first MP can share 10% of its revenues (i.e., revenues earned by the first MP) with the first MaaS player as a MaaS fee. However, the central MaaS node 136 can update the first MP's configuration data to indicate that the first MP can pay 7% of its revenues earned to the first MaaS player as a MaaS fee based on the future environmental impacts. In this way, the first MP can be indirectly incentivized by reducing the first MaaS player's MaaS fee by 3% based on the positive future environmental impacts of the first MP's operations.

[0078] The central MaaS node 136 may periodically update the configuration data associated with the first MP stored in the configuration database 138 based on the AI ​​system 146's prediction of new future environmental impacts resulting from the operation of the first MP at the end of the periodic interval (e.g., the end of each day). The monitor node 122B may then use the updated configuration data to monitor new values ​​of the set of impact factors associated with the first MP at the end of the periodic interval. Further, the central MaaS node 136 may determine new values ​​of a second set of parameters based on the newly monitored values ​​of the set of impact factors. The central MaaS node 136 may determine a first revenue share rate associated with the first MP by using the AI ​​system 146 based on the new values ​​of the second set of parameters.

[0079] At 218, the determined first revenue share rate may be transmitted. In an embodiment, the central MaaS node 136 may be configured to transmit the determined first revenue share rate associated with the first MP to the first MaaS node 118A. The first MaaS node 118A may receive the determined first revenue share rate from the central MaaS node 136. In some embodiments, the central MaaS node 136 may also transmit the first revenue share rate to the first MP node 116A.

[0080] At 220, the first revenue share rate may be stored. In one embodiment, the first MaaS node 118A may be configured to store the received first revenue share rate associated with the first MP. In one embodiment, the first MaaS node 118A may transmit the first revenue share rate associated with the first MP to the first MP node 116A. Information regarding the transmitted first revenue share rate may serve as a consolidated report of the first MP associated with the first MP node 116A. The first MP node 116A may verify the first revenue share rate based on a plurality of transaction records stored in the first MP node 116A. Here, the plurality of transaction records may include at least a first series of transaction records. The first MP node 116A may transmit the verification result as first verification information to the first MaaS node 118A. The first MaaS node 118A may further cross-verify the verified first revenue share rate based on the first verification information and the first series of transaction records stored in the first MaaS node 118A. Cross-verification that the first revenue share rate is correct may indicate that there may be an agreement between the first MP and the first MaaS player on the determined first revenue share rate for the first MP. The first MaaS node 118A may be configured to store the cross-verified first revenue share rate in the first MaaS node 118A. In an embodiment, the first revenue share rate may also be stored in the first MP node 116A. The verification and storage of the first revenue share rate are further described, for example, in FIG. 3 .

[0081] In one embodiment, after determining the first revenue share rate (and, in some cases, after mutually validating the first revenue share rate), a final amount associated with the first revenue share rate may be stored in a distributed ledger node (e.g., the first MaaS node 118A and / or the first MP node 116A). Along with storing the final amount, the distributed ledger node may also store a sign-off status, transaction history, and evidence pointer associated with the transaction record (i.e., associated with the first revenue share rate). Here, the sign-off status (or sign-off point) may correspond to an indication of final settlement of the revenue share rate. Furthermore, the evidence pointer may correspond to the latest status of the proof data, which may be updated with respect to the sign-off point. Hereinafter, the final amount, sign-off status, transaction history, and evidence pointer associated with the transaction associated with the first revenue share rate are collectively referred to as evidence data. Hereinafter, the first verification information may also be referred to as feedback data from the first MP node 116A. The first MaaS node 118A may further extract current values ​​(i.e., latest values) of configuration data associated with the first MP from the configuration database 138 and store the extracted current values ​​(or latest values) of configuration data associated with the first MP. The evidence data regarding the first revenue share rate, the feedback data from the first MP node 116A, and the configuration data associated with the first mobility provider may be stored in the first MaaS node 118A for traceability and audit purposes. In an embodiment, if the cross-verification fails, the first MaaS node 118A may determine that there is potential for misconduct or fraud by the data owner (e.g., mobility player) who was able to capture the transaction records associated with the first revenue share rate. In such a case, the first MaaS player may impose a penalty on the data owner. The amount of the penalty may be determined based on the difference between the expected transaction amount associated with the first revenue share rate and the actual transaction amount associated with the first revenue share rate.

[0082] In one embodiment, the first MaaS node 118A can transmit the received first revenue share rate associated with the first MP to the analytical node 122A. The analytical node 122A can also store the first revenue share rate associated with the first MP. The analytical node 122A can also transmit the first revenue share rate to the archival database node 124 for long-term storage based on a data retention threshold (e.g., one month) associated with the analytical node 122A and a storage period for the first revenue share rate at the analytical node 122A. The archival database node 124 can store the first revenue share rate when the storage period for the first revenue share rate on the analytical node 122A exceeds the data storage threshold associated with the analytical node 122A. For example, U.S. Patent Application No. 17 / 178,185, filed February 17, 2021, describes data retention thresholds and storage periods in detail. Note that the data retention thresholds and storage periods described by the cited applications are merely examples. However, there may be other different examples of data retention thresholds and storage periods without departing from the scope of this disclosure.

[0083] Figure 3 is an exemplary sequence diagram illustrating validation of a first revenue share rate associated with a first mobility provider (MP) corresponding to the first MP node of Figure 1, in accordance with an embodiment of the present disclosure. Figure 3 is described with reference to elements of Figures 1 and 2. Figure 3 illustrates a sequence diagram 300 illustrating a series of operations 302-318 that may be performed by various nodes of the first MaaS network 102 of Figure 1 (e.g., the first MaaS node 118A and the first MP node 116A).

[0084] At 302, a first revenue share rate associated with the first MP may be received. In an embodiment, the first MaaS node 118A may be configured to receive the first revenue share rate associated with the first MP (corresponding to the first MP node 116A) from the central MaaS node 136. Determining the first revenue share rate is described, for example, in FIG. 2.

[0085] At 304, the first revenue share rate may be transmitted. In one embodiment, the first MaaS node 118A may be configured to transmit the first revenue share rate associated with the first MP to the first MP node 116A. The first MP node 116A may receive the first revenue share rate from the first MaaS node 118A. In another embodiment, the first MaaS network 102 may include multiple central MP nodes (not shown in FIG. 1 or FIG. 3). Each of the multiple central MP nodes may be associated with a particular mobility provider and communicatively coupled to the MP node(s) of the respective mobility provider. For example, the first central MP node may be associated with the first MP (and coupled to the first MP node 116A), and the second central MP node may be associated with the second MP (and coupled to the second MP node 116B). In some scenarios, each of the multiple node packages may include MP nodes associated with a single MP. In such a case, a single central MP node may be associated with each MP node (of this single MP) and these MP nodes may be included in such multiple node packages.

[0086] In one embodiment, each central MP node may receive from its respective MaaS node the revenue share rate associated with the corresponding MP. The central MP node may then verify and store the revenue share rate associated with the corresponding MP at the central MP node associated with the MP, as further described in FIG. 3 (operations 306-320). While FIG. 3 describes the verification and storage of the first revenue share rate for the first MP with reference to first MP node 116A, the first central MP node associated with the first MP may alternatively similarly verify and store the first revenue share rate without departing from the scope of this disclosure.

[0087] At 306, the received first revenue share rate may be verified. In one embodiment, the first MP node 116A may be configured to verify the received first revenue share rate based on a plurality of transaction records stored at the first MP node 116A. In one embodiment, the plurality of transaction records may include at least a first series of transaction records. For example, the first MP node 116A may aggregate transaction amounts associated with each of the first series of transaction records for verification. Further, the first MP node 116A may apply the AI ​​system 146 to the aggregated transaction amounts to estimate a second revenue share rate associated with the first MP. Thereafter, the first MP node 116A may compare the first revenue share rate and the second revenue share rate associated with the first MP and generate first verification information based on the comparison. The first verification information may indicate a verification result of the first revenue share rate received at the first MP node 116A. For example, the first verification information may indicate whether the first revenue sharing rate is the same as the second revenue sharing rate, and if not, may indicate how the first revenue sharing rate differs from the second revenue sharing rate. The first verification information may also include the second revenue sharing rate.

[0088] At 308, the first verification information may be transmitted. In an embodiment, the first MP node 116A may be configured to transmit the generated first verification information to the first MaaS node 118A. The first MaaS node 118A may receive the transmitted first verification information from the first MP node 116A. As described above, the first verification information may indicate a verification result of the first revenue sharing rate received at the first MP node 116A.

[0089] At 310, the first revenue share rate can be cross-validated. In one embodiment, the first MaaS node 118A can be configured to cross-validate the first revenue share rate associated with the first MP. In one embodiment, the first MaaS node 118A can be configured to validate the first revenue share rate based on a first set of transaction records stored on the first MaaS node 118A to determine second verification information. For example, the first MaaS node 118A can aggregate transaction amounts associated with each of the first set of transaction records stored on the first MaaS node 118A. Further, the first MaaS node 118A can apply the AI ​​system 146 to the aggregated transaction amounts to estimate a third revenue share rate associated with the first MP. The first MP node 116A then compares the third revenue share rate associated with the first MP with the first revenue share rate and generates second verification information based on the comparison. The second verification information may indicate a verification result of the first revenue at the first MaaS node 118A. For example, the second verification information may indicate whether the first revenue sharing rate is the same as the third revenue sharing rate, and if not, may indicate how the first revenue sharing rate differs from the third revenue sharing rate. The second verification information may also include the third revenue sharing rate.

[0090] In some embodiments, the first MaaS node 118A may be further configured to compare the received first verification information with the determined second verification information. The first revenue share rate may be cross-validated based on the comparison of the first verification information with the determined second verification information. If the first verification information is determined to be the same as the second verification information and the first revenue share rate is equal to both the second revenue share rate and the third revenue share rate, the determined first revenue share rate may be cross-validated as correct. In such a case, the first revenue share rate may be stored in the first MaaS node 118A as described at 312. On the other hand, if the first verification information is determined to be different from the second verification information or if the first revenue share rate is determined to be different from at least one of the second revenue share rate or the third revenue share rate, control may proceed to 314.

[0091] At 312, the first revenue share rate may be stored. In one embodiment, the first MaaS node 118A may be configured to store the first revenue share rate associated with the first MP based on the comparison between the first verification information and the second verification information at 310. The first revenue share rate may be stored if the first revenue share rate is cross-verified as correct, for example, as described at 310. Cross-verification of the first revenue share rate as correct may indicate that an agreement may exist between the first MP and the first MaaS player regarding the determined first revenue share rate for the first MP. In one embodiment, the first revenue share rate may also be stored in the first MP node 116A. Control may proceed to an end.

[0092] At 314, a first adjustment amount may be determined. In an embodiment, the first MaaS node 118A may be configured to determine the first adjustment amount based on the comparison between the first verification information and the second verification information at 310. In one scenario, the first verification information and the second verification information may be determined to be the same, but the first revenue share rate may be determined to be different from both the second revenue share rate and the third revenue share rate. Here, the second revenue share rate and the third revenue share rate may be the same. In such a scenario, the first adjustment amount may be determined as the difference between the first revenue share rate and the second revenue share rate (or the third revenue share rate). In another scenario, the first verification information may be determined to be different from the second verification information. Here, the second revenue share rate and the third revenue share rate may be determined to be different. In such a scenario, the first MaaS node 118A may determine the first adjustment amount based on applying the terms of service and / or service agreement (between the first MP and the first MaaS player) to the first revenue sharing rate, the second revenue sharing rate and / or the third revenue sharing rate.

[0093] At 316, an updated first revenue share ratio can be determined. In one embodiment, the first MaaS node 118A can be configured to update the first revenue share ratio associated with the first MP based on the determined first adjustment amount. For example, the first MaaS node 118A can determine the updated first revenue share ratio by adding (or subtracting) the first adjustment amount and the first revenue share ratio based on whether the first adjustment amount corresponds to a positive adjustment (or a negative adjustment) associated with the first revenue share ratio. Thus, the first revenue share ratio associated with the first MP can be modified based on the determined first adjustment amount. Cross-validating the first revenue share ratio and / or modifying the first revenue share ratio based on the first adjustment amount can ensure true and correct revenue distribution among the mobility providers of the first MaaS network 102. The mutual verification of the first revenue share rate and / or the modification of the first revenue share rate based on the first adjustment amount may further indicate that there may be an agreement between the first MP and the first MaaS player regarding the determined first revenue share rate of the first MP and / or the modification of the first revenue share rate.

[0094] At 318, the updated first revenue share rate may be transmitted. In an embodiment, the first MaaS node 118A may be configured to transmit the updated first revenue share rate to the first MP node 116A. The first MP node 116A may receive the updated first revenue share rate from the first MaaS node 118A. In an embodiment, the first MP node 116A may store the updated first revenue share rate received from the first MaaS node 118A.

[0095] The updated first revenue share rate may be stored at 320. In an embodiment, the first MaaS node 118A may be configured to store the updated first revenue share rate on the first MaaS node 118A.

[0096] Figure 4 is an exemplary sequence diagram illustrating revenue share determination for small or medium-sized transactions on a Mobility as a Service (MaaS) platform using a common database architecture, according to an embodiment of the present disclosure. Figure 4 is described with reference to elements in Figures 1, 2, and 3. Figure 4 illustrates a sequence diagram 400 illustrating a series of operations 402A-420. These series of operations may be performed by various nodes (e.g., first MP node 116A and first MaaS node 118A) of the first MaaS network 102 of Figure 1.

[0097] At 402A and 402B, a first MP node 116A may be onboarded to the first node package 120A. In an embodiment, the first MP node 116A and the first MaaS node 118A may be configured to communicate with each other to onboard the first MP node 116A to the first node package 120A. In an embodiment, based on the communication between the first MP node 116A and the first MaaS node 118A for onboarding, a first MP corresponding to the first MP node 116A and a first MaaS player associated with the first MaaS node 118A may be associated with the first MaaS network 102. The association of the first MP and first MaaS player with the first MaaS network 102 may be based on a service agreement, revenue sharing model, data ownership agreement, terms of service agreement, privacy policy, and / or policy amendments associated with an area of ​​operation of at least one of the first MP or first MaaS player. Based on onboarding the first MP node 116A to the first node package 120A, the first MP node 116A may be added to the first node package 120A, and a first smart contract between the first MP and the first MaaS player may be created. In other words, the first MP node 116A of the first node package 120A may be associated with the first MaaS node 118A based on the first smart contract. In an embodiment, as described at 416, based on a series of transaction records of the first MP node 116A, the first smart contract may be executed to determine a revenue share rate associated with the first MP. The onboarding of the first MP node 116A is further described, for example, in FIG. 2 (202A and 202B). The entity relationship diagram for onboarding an MP node and revenue calculation of a mobility player associated with the MP node is further described, for example, in FIG. 6. The sequence of operations of the on-board processing steps of the MP node is further explained in, for example, FIG.

[0098] In another embodiment, the first MaaS network 102 may include multiple central MP nodes (not shown in FIG. 1 or FIG. 4). Each of the multiple central MP nodes may be associated with a particular mobility provider and may be communicatively coupled to the MP node(s) of the respective mobility provider. For example, a first central MP node may be associated with a first MP (and coupled to the first MP node 116A), and a second central MP node may be associated with a second MP (and coupled to the second MP node 116B). In some scenarios, each of multiple node packages may include MP nodes associated with a single MP. In such cases, a single central MP node may be associated with each MP node (of that single MP) that may be included in such multiple node packages. In some embodiments, the onboarding processing of an MP node may be performed by a central MP node associated with the MP node, which may be associated with the same mobility provider as the MP node.

[0099] At 404A (or 404B), a trigger event may be received. In some embodiments, the first MP node 116A (404A) and / or the first MaaS node 118A (404B) may be configured to receive the trigger event from the scheduler node 144. While both 404A and 404B are shown in FIG. 4, in some embodiments, only the first MaaS node 118A, and not the first MP node 116A, may receive the trigger event at 404A without departing from the scope of this disclosure. In such cases, 404A may be omitted from the sequence diagram 400. In some embodiments, the scheduler node 144 may be configured to generate a trigger event associated with the first node package 120A. In some embodiments, the trigger event may be generated based on at least one of a predetermined schedule or receipt of a predetermined number of transaction records at the first MaaS node 118A. Receiving a trigger event is further described, for example, in FIG. 2 (204A and 204B).

[0100] At 406, a first set of transaction records may be extracted. In one embodiment, the first MP node 116A may be configured to extract the first set of transaction records associated with the first MP node 116A from the first MaaS node 118A based on receiving a trigger event. In another embodiment, the first set of transaction records may be extracted from the first MP node 116A instead of the first MaaS node 118A. Each of the first set of transaction records may be associated with a transaction message received by the first subscriber node 114A of the first node package 120A. In one example, the first set of transaction records associated with the first MP node 116A may include transaction records for a predetermined period of time (e.g., a particular day) of the first MP node 116A in preparation for a trigger event being generated at the end of each day. In another example, the first series of transaction records may include a predetermined number of transaction records of the first MP node 116A (e.g., the most recent thousand transaction records) in preparation for a trigger event being generated upon receipt of the series of thousand transaction records associated with the first MP node 116A.

[0101] At 408, a first summary record associated with the first MP node 116A may be determined. In one embodiment, the first MP node 116A may be configured to determine the first summary record associated with the first MP node 116A based on at least one of an aggregation of the transaction amounts associated with each of the extracted first set of transaction records. For example, the first MP node 116A may determine a sum of the transaction amounts or transaction values ​​for each of the extracted first set of transactions and determine the first summary record based on the determined sum. In one embodiment, the first summary record may indicate a total transaction amount for the extracted first set of transactions. In one embodiment, the determination of the first summary record associated with the first MP node 116A may be further based on a first set of parameters. Details related to the first set of parameters are shown, for example, in FIG. 2 (208). In another embodiment, the first MP node 116A may be configured to send the extracted first set of transaction records to the first MaaS node 118A. The first MaaS node 118A can be configured to determine a first summary record associated with the first MP node 116A based on at least one of the aggregations of the transaction amounts associated with each of the received first series of transaction records. For example, if the number of transaction records is less than a certain value (e.g., several hundred), the first MP node 116A can send the transaction records to the first MaaS node 118A, and the first MaaS node 118A can determine the first summary record.

[0102] The determined first summary record may be transmitted at 410. In an embodiment, the first MP node 116A may be configured to transmit the determined first summary record associated with the first MP node 116A to the first MaaS node 118A. The first MaaS node 118A may receive the first summary record from the first MaaS node 118A.

[0103] At 412, a set of summary records associated with the first MP node 116A may be received. In an embodiment, the first MaaS node 118A may be configured to receive the set of summary records associated with the first MP node 116A from the set of MP nodes of the plurality of node packages 120. The set of summary records associated with the first MP node 116A may include at least a first summary record associated with the first MP node 116A.

[0104] At 414, a second summary record may be determined. In one embodiment, the first MaaS node 118A may be configured to determine a second summary record associated with the first MP node 116A based at least on an aggregation of transaction amounts associated with each of the received set of summary records. For example, the first MaaS node 118A may aggregate transaction amounts associated with each of the received set of summary records to determine a total transaction amount for each of a plurality of transaction records associated with the first MP node 116A stored in various node packages of the first MaaS network 102. In one embodiment, the second summary record may indicate a total transaction amount for each of a plurality of transaction records associated with the first MP node 116A stored in various node packages of the first MaaS network 102.

[0105] At 416, a first revenue share rate can be determined. In one embodiment, the first MaaS node 118A can be configured to execute a first smart contract based on the determined second summary record to determine a first revenue share rate associated with the first MP corresponding to the first MP node 116A. For example, the first smart contract can include revenue calculation logic related to the terms and conditions of a service agreement between the first MP and the first MaaS provider. The revenue calculation logic can be applied to the second summary record during execution of the first smart contract to determine the first revenue share rate. The second summary record can include a total transaction amount for each transaction corresponding to multiple transaction records associated with the first MP node 116A. The total transaction amount can be used as an indicator of revenue or royalties earned by the first MP for providing services to customers through the first MaaS network 102 during a certain time frame or accounting period.

[0106] In some embodiments, the determination of the first revenue share rate associated with the first MP can be further based on a second set of parameters. Details related to the second set of parameters are shown, for example, in FIG. 2 (216). In some embodiments, the determination of the first revenue share rate associated with the first MP can be further based on applying the AI ​​system 146 to at least one of the determined second summary record or the second set of parameters. The AI ​​system 146 can be pre-trained for the revenue share rate determination task. In some embodiments, the AI ​​system 146 can be trained based on a revenue model, a service agreement, terms of service, and / or a privacy policy. The first MaaS node 118A can provide the determined second summary record and / or the second set of parameters to the AI ​​system 146. The AI ​​system 146 can determine the first revenue share rate associated with the first MP based on the provided second summary record and / or second set of parameters. The determination of the first revenue share rate associated with the first MP is further described, for example, in FIG. 2 (216).

[0107] The determined first revenue share rate may be transmitted at 418. In an embodiment, the first MaaS node 118A may be configured to transmit the determined first revenue share rate associated with the first MP to the first MP node 116A. The first MP node 116A may receive the determined first revenue share rate from the first MaaS node 118A.

[0108] At 420, the first revenue share rate may be stored. In one embodiment, the first MaaS node 118A may be configured to store the first revenue share rate associated with the first MP. In one embodiment, the first MP node 116A may verify the determined first revenue share rate based on a plurality of transaction records stored in the first MP node 116A, where the plurality of transaction records includes at least a first series of transaction records. The first MP node 116A may send the verification result to the first MaaS node 118A as first verification information. The first MaaS node 118A may further cross-verify the verified first revenue share rate based on the first verification information and the first series of transaction records stored in the first MaaS node 118A. The first MaaS node 118A may be configured to store the cross-verified first revenue share rate in the first MaaS node 118A. In some embodiments, the first revenue share rate may be stored in the first MP node 116A. Validation of the first revenue share rate is further described, for example, in Figure 3 (304-320). Storage of the first revenue share rate is further described, for example, in Figure 2 (220).

[0109] In one embodiment, the first MaaS node 118A can transmit a first revenue share associated with the first MP to the analytic node 122A. The analytic node 122A can also store the first revenue share associated with the first MP. The analytic node 122A can also transmit the first revenue share to the archival database node 124 for long-term storage based on a data retention threshold (e.g., one month) associated with the analytic node 122A and a storage period for the first revenue share on the analytic node 122A. The archival database node 124 can store the first revenue share once the storage period for the first revenue share on the analytic node 122A exceeds the data storage threshold associated with the analytic node 122A.

[0110] In some embodiments, determining the first revenue share rate, such as that described in FIG. 4, can be useful and advantageous when the first set of transaction records is not very large. An example of such a scenario can be when the first set of transaction records corresponds to a small transaction set (e.g., a few hundred transaction records or less) or a medium-sized transaction set (e.g., a few thousand transaction records or less). In such a scenario, one or more distributed ledger nodes in the first MaaS network 102 can determine the first revenue share rate. For example, as described in FIG. 4, the first MP node 116A and the first MaaS node 118A can be involved in determining the first revenue share rate. In such a case, system 126 can be omitted from network environment 100 (of FIG. 1) or, even if present in network environment 100, can be uninvolved in determining the first revenue share rate. Processing the first set of transaction records on one or more distributed ledger nodes to determine the first revenue share rate can be advantageous because it does not raise data privacy concerns. Additionally, because the number of transactions is small, one or more distributed ledger nodes may be able to efficiently process the first set of transaction records. In such cases, offloading the first set of transaction records may be unnecessary because it may be equally efficient to process a small or medium-sized transaction set on one or more distributed ledger nodes, and therefore no efficiency gains may be achieved by offloading the transaction records.

[0111] Figure 5 is an exemplary scenario illustrating the determination of a first revenue share rate associated with a first mobility provider (MP) corresponding to the first MP node of Figure 1, in accordance with an embodiment of the present disclosure. Figure 5 is described with reference to elements of Figures 1, 2, 3, and 4. Figure 5 illustrates an exemplary scenario 500. Scenario 500 illustrates the determination by system 126 of a first revenue share rate associated with a first MP corresponding to first MP node 116A.

[0112] The system 126 may include multiple aggregator nodes 134 (e.g., a first aggregator node 134A, a second aggregator node 134B, ..., and an Nth aggregator node 134N), a central MaaS node 136, a configuration database 138, a consumer database 140, and a transaction database 142. The scenario 500 may further include an AI system 146. The scenario 500 may further include transaction details 502 including a set of transaction records 502A received at the first aggregator node 134A, a set of transaction records 502B received at the second aggregator node 134B, ..., and a set of transaction records 502N received at the Nth aggregator node 134N. Scenario 500 further illustrates summary records 504, including summary records 504A determined at a first aggregator node 134A, summary records 504B determined at a second aggregator node 134B, ..., and summary records 504N determined at an Nth aggregator node 134N. Scenario 500 further illustrates a summary list 506 determined at a central MaaS node 136. Scenario 500 further illustrates a revenue share rate 508A associated with a first MP corresponding to a first MP node 116A, a revenue share rate 508B associated with a second MP corresponding to a second MP node 116B, ..., and a revenue share rate 508N associated with an Nth MP corresponding to an Nth MP node 116N. The central MaaS node 136 can be configured to determine the revenue share rate 508A, the revenue share rate 508B, ..., and the revenue share rate 508N.

[0113] The consumer database 140 can be configured to store mobility provider data associated with each mobility provider associated with the first MaaS network 102. For example, the mobility provider data associated with the first MP can include data ownership details for the first MP, a service agreement between the first MP and a first MaaS player corresponding to the first MaaS node 118A, terms or services associated with the service agreement, a privacy policy associated with the service agreement, process services associated with the service agreement, and / or a revenue model associated with the first MP and the first MaaS player. The transaction database 142 can be configured to store transaction records associated with each of the multiple MP nodes 116A, 116B, ..., and 116N received from the multiple MaaS nodes 118A, 118B, ..., and 118N of the multiple node package 120. For example, the transaction database 142 can store transaction details 502. In one embodiment, the transaction database 142 may receive a set of transaction records 502A from the first MaaS node 118A based on a trigger event associated with the first node package 120A. The transaction database 142 may store the received set of transaction records 502A with other transaction records (e.g., transaction details 502). The transaction database 142 may send the received set of transaction records 502A to the first aggregator node 134A for processing.

[0114] In one embodiment, the first aggregator node 134A can be configured to receive a set of transaction records 502A from a first MaaS node 118A of the first node package 120A based on a trigger event associated with the first node package 120A, where one or more MP nodes of the first node package 120A can include the first MP node 116A. For example, each of the set of transaction records 502A can be associated with a first mobility provider “MP-1” corresponding to the first MP node 116A. The set of transaction records 502A can include a first transaction record with an identifier (ID) of “TX1” and a transaction amount of “10,” a second transaction record with an ID of “TX2” and a transaction amount of “2,” and a third transaction record with an ID of “TX3” and a transaction amount of “3.” Similarly, the second aggregator node 134B can be configured to receive a set of transaction records 502B from a second MaaS node 118B of the second node package 120B based on a trigger event associated with the second node package 120B, where one or more MP nodes of the second node package 120B may include the first MP node 116A. For example, each of the set of transaction records 502B can be associated with a first mobility provider “MP-1” corresponding to the first MP node 116A. The set of transaction records 502B can include a fourth transaction record with an ID of “TX4” and a transaction amount of “4,” and a fifth transaction record with an ID of “TX5” and a transaction amount of “10.” Further, the Nth aggregator node 134N can be configured to receive a series of transaction records 502N from the Nth MaaS node 118N of the Nth node package 120N based on a trigger event associated with the Nth node package 120N.Here, the one or more MP nodes of the Nth node package 120N may include a first MP node 116A and a second MP node 116B. For example, the set of transaction records 502N may include a sixth transaction record with an ID of “TX6” and a transaction amount of “12,” a seventh transaction record with an ID of “TX7” and a transaction amount of “1,” and an eighth transaction record with an ID of “TX8” and a transaction amount of “2.” The sixth transaction record may be associated with a first mobility provider “MP-1” corresponding to the first MP node 116A. Furthermore, the seventh and eighth transaction records may both be associated with a second mobility provider “MP-2” corresponding to the second MP node 116B.

[0115] The N aggregator nodes shown in Figure 5 are presented by way of example only. The plurality of aggregator nodes 134 may include only two or more than N aggregator nodes for determining the first revenue share rate associated with the first MP without departing from the scope of this disclosure. Furthermore, for simplicity, the transaction details 502 of scenario 500 are described with reference to three sets of transaction records, including a set of transaction records 502A, a set of transaction records 502B, and a set of transaction records 502N. However, the transaction details 502 may include only two or more than three (or more than N) sets of transaction records without departing from the scope of this disclosure.

[0116] In one embodiment, each of the multiple aggregator nodes 134 can be configured to determine a summary record based on an aggregation of transaction amounts associated with each of the corresponding series of transaction records received by the respective aggregator node. For example, a first aggregator node 134A can be configured to determine a summary record 504A (i.e., the first summary record in FIG. 2 ) associated with a first MP “MP-1” corresponding to the first MP node 116A. The determination of the summary record 504A can be based at least on an aggregation of the transaction amounts of each of the series of transaction records 502A (i.e., the first series of transaction records in FIG. 2 ). In one example, the aggregated transaction amount associated with the summary record 504A can be “15” (i.e., 10+2+3) based on the sum of the transaction amounts of the first transaction record “TX1,” the second transaction record “TX2,” and the third transaction record “TX3.” The determination of a first summary record associated with the first MP node 116A by the first aggregator node 134A is further described, for example, in Figure 2. Similarly, the second aggregator node 134B may determine a summary record 504B that includes an aggregated transaction amount of "14" for the first MP "MP-1." Additionally, the Nth aggregator node 134N may determine a summary record 504N that includes an aggregated transaction amount of "12" for the first MP "MP-1" and an aggregated transaction amount of "3" for the second MP "MP-2."

[0117] In one embodiment, the central MaaS node 136 can be configured to receive a set of summary records from multiple aggregator nodes 134. In one embodiment, the received set of summary records includes at least summary record 504A. For example, the set of summary records received by the central MaaS node 136 can include summary record 504A received from a first aggregator node 134A, summary record 504B received from a second aggregator node 134B, and summary record 504N received from an Nth aggregator node 134N. The central MaaS node 136 can determine a summary list 506 based on the received set of summary records. For example, the summary list 506 can include a first set of summary information associated with a first MP “MP-1” and a second set of summary information associated with a second MP “MP-2.” The first set of summary information may include a first record with an aggregate amount of 15, a second record with an aggregate amount of 14, and a third record with an aggregate amount of 12. Additionally, the second set of summary information may include a fourth record with an aggregate amount of 3.

[0118] In one embodiment, the central MaaS node 136 can be configured to determine a second summary record associated with the first MP node 116A based at least on an aggregation of transaction amounts associated with each of the received set of summary records. For example, the central MaaS node 136 can determine a second summary record associated with the first MP node 116A based on the first set of summary information in the summary list 506. The consolidated amount associated with the second summary record associated with the first MP node 116A can be "41" (i.e., 15 + 14 + 12). Determination of the second summary record associated with the first MP node 116A is further described, for example, in FIG. 2. Similarly, the central MaaS node 136 can determine a second summary record associated with the second MP node 116B and a second summary record associated with the Nth MP node 116N. For example, the consolidated amount associated with the second summary record associated with the second MP node 116B may be “3” (because the aggregate amount of the fourth record in the second series of summary information in the summary list 506 is “3”).

[0119] In one embodiment, the central MaaS node 136 can be configured to determine a revenue share rate 508A (i.e., the first revenue share rate in FIG. 2 ) associated with the first MP “MP-1” corresponding to the first MP node 116A based on the determined second summary record associated with the first MP node 116A. For example, the central MaaS node 136 can determine a first ratio (denoted by R1) of the consolidated amount associated with the second summary record associated with the first MP node 116A to the sum of the consolidated amounts associated with each second summary record associated with each MP node of the multiple MP nodes 116A, 116B, ... 116N. As shown in FIG. 5 , the first ratio (i.e., R1) can be determined as 41 / (41+3), or 0.93 (or 93%). The central MaaS node 136 can determine the revenue share rate 508A associated with the first MP “MP-1” by using the following equation (1): Revenue sharing rate = R1 (MP split) - MaaS fee + incentive (1) where: The MP split represents the total revenue of all mobility providers, MaaS fees represent fees that MaaS players can charge. Incentives represent the incentives MPs receive in exchange for various green initiatives.

[0120] The determination of the first revenue share rate associated with the first MP (i.e., revenue share rate 508A) may be further based on a second set of parameters. In one embodiment, the central MaaS node 136 may be configured to determine the second set of parameters based on a change trend in the values ​​of a set of influence factors associated with the first MP. The change trend in the values ​​of the set of influence factors associated with the first MP may be monitored periodically (e.g., at the end of each day) by the monitor node 122B and transmitted to the central MaaS node 136. In one embodiment, the determination of the first revenue share rate associated with the first MP may be based on applying an AI system 146 (e.g., AI model 812D in FIG. 8 ) to at least one of the determined second summary record associated with the first MP node 116A or the second set of parameters. The AI ​​system 146 may be pre-trained for the revenue share rate determination task. In one embodiment, the AI ​​system 146 may be trained based on configuration data, revenue model, service contract, terms of service, and / or privacy policy associated with the first MP stored in the configuration database 138. The central MaaS node 136 may provide the determined second summary record and / or the second set of parameters to the AI ​​system 146. The AI ​​system 146 may determine a first revenue share rate associated with the first MP based on the provided second summary record and / or the second set of parameters.

[0121] In some embodiments, the AI ​​system 146 can be further trained on an environmental impact analysis task. In some embodiments, the AI ​​system 146 can determine a score for the change trend of the values ​​of each of the set of impact factors associated with the first MP. The AI ​​system 146 can predict future changes in the values ​​of the set of impact factors associated with the first MP based on the determined scores. The predicted future changes in the values ​​of the set of impact factors can indicate future environmental impacts caused by operation of the first MP. The central MaaS node 136 can update the determined first revenue share rate associated with the first MP based on the predicted changes in the values ​​of the set of impact factors associated with the first MP.

[0122] The central MaaS node 136 may periodically update the configuration data associated with the first MP stored in the configuration database 138 based on the AI ​​system 146's prediction of new future environmental impacts resulting from the operation of the first MP at the end of the periodic interval (e.g., the end of each day). The monitor node 122B may then use the updated configuration data to monitor new values ​​of a set of impact factors associated with the first MP at the end of the periodic interval. Furthermore, the central MaaS node 136 may determine new values ​​of a second set of parameters based on the newly monitored values ​​of the set of impact factors. The central MaaS node 136 may determine a first revenue share rate associated with the first MP by using the AI ​​system 146 based on the new values ​​of the second set of parameters. The determination of the first revenue share rate associated with the first MP is further described, for example, in FIG. 2 . Similarly, the central MaaS node 136 may determine a revenue share rate 508B associated with a second MP "MP-2" corresponding to the second MP node 116B, and a revenue share rate 508N associated with an Nth MP corresponding to the Nth MP node 116N. For example, the revenue share rate 508B may be determined as 7% of the MP split - MaaS fee + incentive based on use of equation (1). The scenario 500 of FIG. 5 is for illustrative purposes and should not be construed as limiting the scope of the present disclosure.

[0123] 6 is an exemplary entity-relationship (ER) diagram related to onboarding a mobility provider (MP) node to a node package of a mobility-as-a-service (MaaS) platform using a common database architecture and determining the mobility provider's revenue share corresponding to the MP node, according to an embodiment of the present disclosure. The description of FIG. 6 is provided with reference to elements of FIGS. 1, 2, 3, 4, and 5.

[0124] FIG. 6 illustrates an exemplary ER diagram 600. The ER diagram 600 may include multiple entities related to each other based on relationships. Each of the multiple entities may be a data structure, such as, but not limited to, a class, a structure, an object, a relational table, or any data structure capable of representing an entity. The ER diagram 600 may include a first set of entities 602 and a second set of entities 604. The first set of entities 602 may be related to onboarding a first MP node 116A to a first node package 120A, for example, as further described in FIG. 2. The second set of entities 604 may be related to determining a first revenue share rate associated with a first MP corresponding to the first MP node 116A, for example, as further described in FIG. 2.

[0125] The first set of entities 602 may include a first entity 602A, a second entity 602B, a third entity 602C, a fourth entity 602D, and a fifth entity 602E. The first entity 602A may be related to the second entity 602B, the fourth entity 602D, and the fifth entity 602E. Furthermore, the fourth entity 602D may be related to the third entity 602C. The first entity 602A may be related to a “service contract” between a first MP and a first MaaS player. The first entity 602A may have attributes such as, but not limited to, an identifier (ID), an owner ID, a data ID, a service ID, a terms of service (ToS), an agreement Y / N (Yes / No), and a revenue model. The second entity 602B may be related to a “data owner” (i.e., the first MP) and may have attributes such as, but not limited to, an ID, a name, and a role. The third entity 602C may be associated with a "Terms of Service (ToS) and Privacy Policy (PP)" between the first MP and the first MaaS player. The third entity 602C may have attributes such as, but not limited to, an ID, a service name, a version, an area, a language (Lang.), and a text (i.e., the text of the ToS). The fourth entity 602D may be associated with a "process service" corresponding to a business process between the first MP and the first MaaS player. The fourth entity 602D may have attributes such as, but not limited to, an ID and a service name. The fifth entity 602E may be associated with a "revenue model" related to a revenue sharing rate between the first MP and the first MaaS player. The fifth entity 602E may have attributes such as, but not limited to, an ID and a model. Table 1 below provides details regarding exemplary database tables that may be defined based on each of the first set of entities 602. TIFF0007728526000001.tif162154 Table 1: An exemplary database table that can be defined from a first set of entities 602.

[0126] For example, referring to Table 1, a table titled "Data Owner" can be defined for the second entity 602B. Additionally, a table titled "Process Services" can be defined for the fourth entity 602D. Additionally, tables titled "Tos&PP" and "Service Contract" can be defined for the first entity 602A and the third entity 602C, respectively. Additionally, a table titled "Revenue Model" can be defined for the fifth entity 602E. Note that the data shown in Table 1 can be considered empirical data and should not be construed as limiting the present disclosure.

[0127] The second set of entities 604 may include a first entity 604A, a second entity 604B, a third entity 604C, a fourth entity 604D, and a fifth entity 604E. The first entity 604A may be related to the second entity 602B and the first entity 602A of the first set of entities 602. Furthermore, the second entity 604B may be related to the first entity 602A of the first set of entities 602, as well as to the third entity 604C, the fourth entity 604D, and the fifth entity 604E of the second set of entities 604. The first entity 604A may be related to “transaction data” related to the first MP and may have attributes such as, but not limited to, an ID, a data type, and an owner. The second entity 604B may be associated with a "Revenue Share Report" associated with the first MP and may have attributes such as, but not limited to, ID, process service ID, and configuration ID. The third entity 604C may be associated with a "Revenue Share Configuration" associated with the first MP and may have attributes such as, but not limited to, ID, process ID, configuration, and version. The fourth entity 604D may be associated with a "Review Comment" associated with the verification of the revenue share report (i.e., the second entity 604B) by one or both of the first MP node 116A and the first MaaS node 118A. The fourth entity 604D may have attributes such as, but not limited to, ID, process ID, and comments. The fifth entity 604E may be associated with "Evidence" associated with the revenue share determined for the first MP. The fifth entity 604E may have attributes such as, but not limited to, an ID, a Row Data Path, and an Owner ID.Table 2 below provides details regarding exemplary database tables that may be defined based on each of the second set of entities 604. TIFF0007728526000002.tif160156 Table 2: An exemplary database table that can be defined from the second set of entities 604.

[0128] For example, with reference to Table 2, a table titled "Transaction Data" may be defined for the first entity 604A. Additionally, a table titled "Rev Share Config" may be defined for the third entity 604C. Additionally, tables titled "Rev Share Report" and "Review Comments" may be defined for the second entity 604B and the fourth entity 604D, respectively. Additionally, a table titled "Evidence" may be defined for the fifth entity 604E. Note that the data shown in Table 2 may be considered empirical data and may not be construed as limiting the present disclosure.

[0129] In an embodiment, the first MP node 116A may be onboarded to the first node package 120A and associated with the first MaaS network 102 and system 126 based on one or more of, but not limited to, a service agreement (based on the first entity 602A), a data ownership agreement (based on the second entity 602B), ToS&PP (based on the third entity 602C), a business process service model (based on the fourth entity 602D), and a revenue model (based on the fifth entity 602E). Once the first MP node 116A is onboarded, based on a trigger event, a first set of transaction records of the first MP node 116A may be sent to the first aggregator node 134A of the system 126, which may be stored in the first MaaS node 118A. The second entity 604B can be used to ingest transaction data (i.e., transaction records representing ticket usage) into the blockchain database node and cache database node 126 (such as the first MP node 116A and the first MaaS node 118A) or system 126. The system 126 can apply revenue share determination logic to determine a first revenue share associated with the first MP. The system 126 can determine a revenue share report associated with the determined first revenue share based on the first entity 604A. For example, the central MaaS node 136 can determine the first revenue share associated with the first MP based on one or more of, but not limited to, a revenue model (based on the fifth entity 602E), a ToS&PP (based on the third entity 602C), and a service contract (based on the first entity 602A). The central MaaS node 136 may also use the AI ​​system 146 to determine a first revenue sharing rate based on the revenue model and the ToS&PP terms.Once the first revenue share rate is determined, the first MP node 116A and / or the first MaaS node 118A may verify the determined first revenue share rate and provide comments regarding the verified first revenue share rate based on the fourth entity 604D. The results of the verified first revenue share rate may be stored in one or more blockchain database nodes (such as the first MP node 116A and the first MaaS node 118A) based on the fifth entity 604E. Note that the ER diagram 600 of FIG. 6 is for illustrative purposes and should not be construed as limiting the scope of the present disclosure.

[0130] Figure 7 is an exemplary sequence diagram illustrating the process of onboarding a mobility provider (MP) node to a node package of a mobility-as-a-service (MaaS) platform using a common database architecture, according to an embodiment of the present disclosure. Figure 7 is described with reference to elements in Figures 1, 2, 3, 4, 5, and 6. Figure 7 illustrates a sequence diagram 700 illustrating a series of operations 702-716. These operations may be performed by various nodes (e.g., first MP node 116A, first MaaS node 118A) of the first MaaS network 102 of Figure 1.

[0131] At 702, a service structure can be defined. In one embodiment, to onboard the first MP node 116A of the first MP to the first node package 120A, the first MaaS node 118A can be configured to define a service structure for the onboarding process. The first MaaS node 118A can generate configuration data for the first MP node 116A to define the service structure. For example, the generated configuration data can include a “process service” entity definition, which can include attributes such as an identifier (ID) and a service name. In one example, the process service entity can include a “revenue share reporting service” that can be used to calculate revenue for the first MP associated with the first MP node 116A. For example, other services, such as a traffic congestion analysis service for governments and a reward calculation service for low carbon emissions for mobility providers, can also be defined. The generated configuration data can further include text for a “terms of service” and a “privacy policy” for the “process service.” The specification of the service structure can also include configuration of an executable environment for the “process service.” The service structure definition may also include a definition of on-board data that may belong to a data owner (eg, the first MP node 116A in this case).

[0132] At 704, an invite message may be sent to the data owner. In one embodiment, the first MaaS node 118A may be configured to send the invite message to the data owner, where the data owner may be the first MP node 116A. Accordingly, the invite message may be sent to the first MP node 116A based on a defined service structure. The invite message may generate configuration data for onboarding processing of the first MP node 116A and may indicate that the onboarding processing process of the first MP node 116A has begun. The first MP node 116A may receive the invite message.

[0133] At 706, one or more of the service contract, the terms of service of the service contract, and the privacy policy may be transmitted. In an embodiment, the first MaaS node 118A may be configured to transmit one or more of the service contract, the terms of service of the service contract, and the privacy policy to the first MP node 116A (i.e., the data owner). The first MP node 116A may be configured to receive the transmitted service contract, the terms of service, and the privacy policy.

[0134] At 708, a sign-off operation of the service contract and privacy policy can be performed. In one embodiment, the first MP node 116A (i.e., the data owner) can be configured to perform the service contract and privacy policy sign-off operation. The first MP node 116A can validate the service contract, terms of service, and privacy policy using a set of business rules associated with the first MP. If, based on the validation, it is determined that the service contract, terms of service, and privacy policy satisfy the set of business rules, the first MP node 116A accepts the service contract and privacy policy. The first MP node 116A can indicate acceptance based on signing off on each of the service contract and privacy policy. The sign-off can form a legally binding contract between the first MP and the first MaaS player. The jurisdiction of the contract can be based on the first MP's place of operation, the MaaS player's place of operation, or a place of operation / headquarters associated with the first MaaS network 102.

[0135] At 710, a sign-off confirmation message may be sent. In one embodiment, the first MP node 116A may be configured to send the sign-off confirmation message to the first MaaS node 118A. The sign-off confirmation message indicates that the first MP node 116A has accepted the service agreement, terms of service, and privacy policy. The sign-off confirmation message may also indicate that the first MP node 116A has signed off on each of the service agreement and privacy policy based on the acceptance. In one embodiment, the first MaaS node 118A may generate a smart contract between the first MP and the first MaaS player based on receiving the sign-off confirmation message and store the smart contract in each of the first MP node 116A and the first MaaS node 118A. At this stage, the first MP node 116A may be onboarded to the first MaaS network 102 (and the first node package 120A).

[0136] At 712, transaction data may be prepared. In one embodiment, the first MP node 116A may be configured to prepare the transaction data for calculation of a revenue share rate associated with the first MP. To prepare the transaction data, the first MP node 116A may extract a set of transaction records from the first MP node 116A based on a trigger event associated with the first node package 120A. The first MP node 116A may then remove unnecessary information from each extracted transaction record. For example, the first MP node 116A may retain only the transaction ID and transaction amount fields of each transaction record for participation in a “revenue share rate reporting service” process (i.e., a process for calculation of the first MP’s revenue share rate).

[0137] At 714, the prepared transaction data may be transmitted. In an embodiment, the first MP node 116A may be configured to transmit the prepared transaction data to the first MaaS node 118A. The first MaaS node 118A may receive the transmitted prepared transaction data. Receipt of the prepared transaction data may be based on a trigger event associated with the first node package 120A.

[0138] At 716, a revenue share calculation service can be performed. In one embodiment, the first MaaS node 118A can be configured to perform the revenue share calculation service. The first MaaS node 118A can ingest the transaction data received from the first MP node 116A and perform the target service (e.g., a "revenue share report service" process) in accordance with the service agreement. The performance of the target service can be periodic, such as once a day (e.g., at 11:59:59 PM), or based on a trigger event associated with the first node package 120A. The first MaaS node 118A can also perform other specified services, such as a traffic congestion analysis service for governments and a reward calculation service for low carbon emissions for mobility providers. Calculation of MP revenue share is further described, for example, in Figures 2, 3, 4, and 5.

[0139] In some scenarios, the data owner associated with the service contract (e.g., the first MP associated with the first MP node 116A) may update the service contract at a later point in time. For example, a user may be excluded from the scope of the service contract and privacy policy. In response, the first MaaS node 118A may change the scope of the target service(s) to be fulfilled based on the updated scope of the service contract and privacy policy. In some cases, the first MaaS player (associated with the first MaaS node 118A) may cancel the service contract at a later point in time. In such a case, the first MP node 116A may send a message to the first MP node 116A indicating that the service contract is now invalid and may not be enforceable. Furthermore, in some cases, the first MaaS player may partially cancel or update the service contract. The first MaaS node 118A may communicate the updated service contract (and / or privacy policy) to the first MP node 116A. The first MP node 116A can validate the updated service contract (and / or privacy policy) based on the first MP's set of business rules and sign off on the updated service contract (and / or privacy policy) accordingly. Meanwhile, in some embodiments, the first MaaS node 118A can check a permission-based rule set to enable or disable data management policy functions of the first MaaS network 102 based on the updated service contract. The data management policy functions can be based on the region or area of ​​operation of the first MP, the first MaaS player, and / or the first MaaS network 102 as a whole. The data management policy functions can also depend on one or more legal requirements of the region or area, which may change from time to time. Data retention and processing rules can also be governed by fine-grained parameters within the service contract. Examples of fine-grained parameters can include data retention periods, data analysis policies, data disclosure policies to third parties, handling of personally identifiable information (PII), and data hashing.

[0140] Figure 8 is a block diagram of an example system for revenue share determination of transactions on a Mobility as a Service (MaaS) platform using a common database architecture, according to an embodiment of the present disclosure. Figure 8 is described with reference to elements in Figures 1, 2, 3, 4, 5, 6, and 7. Figure 8 shows a block diagram of an example system 800. System 800 can include a first subscriber node 114A, a first MP node 116A, and a first MaaS node 118A, a scheduler node 144, an artificial intelligence (AI) system 146, a first aggregator node 134A, and a central MaaS node 136.

[0141] The first MP node 116A may include a processor 802A, a memory 802B, and a network interface 802C. The first MaaS node 118A may include a processor 804A, a memory 804B, and a network interface 804C. Furthermore, the first aggregator node 134A may include a processor 806A, a memory 806B, and a network interface 806C. The central MaaS node 136 may further include a processor 808A, a memory 808B, and a network interface 808C. Furthermore, the scheduler node 144 may include a processor 810A, a memory 810B, and a network interface 810C. Furthermore, the AI ​​system 146 may include a processor 812A, a memory 812B, and a network interface 812C. Although not shown, the first subscriber node 114A may also include a processor, a memory, and a network interface.

[0142] The first subscriber node 114A, the first MP node 116A, and the first MaaS node 118A may form a first node package 120A of the plurality of node packages 120. The first MP node 116A may be communicatively coupled to the first subscriber node 114A and the first MaaS node 118A. The system 126 includes a first aggregator node 134A and a central MaaS node 136, which may be communicatively coupled to each other. The first node package 120A may be communicatively coupled to the system 126. For example, the first MaaS node 118A may be communicatively coupled to the first aggregator node 134A. Furthermore, each of the scheduler node 144 and the AI ​​system 146 may be communicatively coupled to the first node package 120A. The AI ​​system 146 may also be communicatively coupled to the system 126. For example, the AI ​​system 146 may be communicatively coupled to the central MaaS node 136. Although not shown, the AI ​​system 146 may be communicatively coupled to the monitor node 122B.

[0143] The processor 804A may include suitable logic, circuitry, and / or interfaces that can be configured to execute a set of instructions stored in the memory 804B. The processor 804A may be configured to execute program instructions associated with different operations performed by the first MaaS node 118A or any other MaaS node. The processor 804A may be implemented based on many processor technologies known in the art. Examples of processor technologies include, but are not limited to, central processing units (CPUs), X86-based processors, reduced instruction set computing (RISC) processors, application-specific integrated circuit (ASIC) processors, complex instruction set computing (CISC) processors, graphical processing units (GPUs), and other processors. The functionality of the processors 802A, 806A, 808A, 810A, and 812A may be the same as the functionality of the processor 804A of the first MaaS node 118A described in, for example, Figures 1, 2, 3, 4, 5, and 7. Accordingly, a description of processor 802A, processor 806A, processor 808A, processor 810A, and processor 812A will be omitted from this disclosure for the sake of brevity.

[0144] Memory 804B may include suitable logic, circuitry, and / or interfaces that may be configured to store one or more instructions executed by processor 804A. Memory 804B may be configured to store a first series of transaction records and a determined first revenue share rate associated with the first MP. Implementation examples of memory 804B may include, but are not limited to, random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), hard disk drive (HDD), solid-state drive (SSD), CPU cache, and / or a secure digital (SD) card. The functionality of memory 802B, memory 806B, memory 808B, memory 810B, and memory 812B may be the same as that of memory 804B described in FIG. 8, for example. Accordingly, descriptions of memory 802B, memory 806B, memory 808B, memory 810B, and memory 812B are omitted from this disclosure for the sake of brevity.

[0145] The memory 812B of the AI ​​system 146 may include an AI model 812D that can be pre-trained to determine a revenue share rate (e.g., a first revenue share rate) associated with an MP (e.g., a first MP). The determination of the revenue share rate (e.g., the first revenue share rate) may be based on an aggregated transaction amount (e.g., based on the second summary record) of each of a set of transaction records of an MP node (e.g., the first MP node 116A) corresponding to the MP (e.g., the first MP). Determining the first revenue share rate by applying the AI ​​model 812D to the aggregated transaction amount is further described, for example, in FIGS. 2 and 4. The AI ​​model 812D may be further trained for an environmental impact analysis task. In one embodiment, the AI ​​model 812D may determine a score of a change trend of values ​​of each of a set of influence factors associated with the MP (e.g., the first MP). The AI ​​model 812D may predict future changes in values ​​of the set of influence factors associated with the MP based on the determined score. The predicted future changes in the values ​​of the set of influence factors can indicate the future environmental impact of the MP's operation. Further details regarding the AI ​​model are shown, for example, in Figure 1.

[0146] The network interface 804C may include suitable logic, circuits, and interfaces configurable to facilitate communication between corresponding processors of the first MP node 116A, the first MaaS node 118A, the system 126, the scheduler node 144, and the AI ​​system 146 over a communications network (not shown in FIG. 8 ). The network interface 804C may be implemented using various known technologies supporting wired or wireless communication between the first MaaS node 118A and the communications network. The network interface 804C may include, but is not limited to, an antenna, a radio frequency (RF) transceiver, one or more amplifiers, a tuner, one or more oscillators, a digital signal processor, a coder-decoder (CODEC) chipset, a subscriber identity module (SIM) card, or a local buffer circuit. The network interface 804C may be configured to communicate over wireless communication with a network such as the Internet, an intranet, or a wireless network such as a cellular telephone network, a wireless local area network (LAN), and a metropolitan area network (MAN). The wireless communication may be configured to use one or more of a number of communication standards, protocols, and technologies, such as Global System for Mobile Communications (GSM), Enhanced Data GSM Environment (EDGE), Wideband Code Division Multiple Access (W-CDMA), Long Term Evolution (LTE), Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Bluetooth, Wireless Fidelity (WiFi) (such as IEEE 802.11a, IEEE 802.11b, IEEE 802.11g, or IEEE 802.11n), Voice over Internet Protocol (VoIP), Light Fidelity (Li-Fi), or Worldwide Interoperability for Microwave Access (Wi-MAX), protocols for email, instant messaging, and short message service (SMS).The functionality of network interface 802C, network interface 806C, network interface 808C, network interface 810C, and network interface 812C can be the same as the functionality of network interface 804C described in Figure 8, for example. Accordingly, descriptions of network interface 802C, network interface 806C, network interface 808C, network interface 810C, and network interface 812C are omitted from this disclosure for the sake of brevity.

[0147] FIG. 9 illustrates an exemplary flowchart of a method for determining revenue share rates for large-scale transactions on a Mobility as a Service (MaaS) platform using a common database architecture, according to an embodiment of the present disclosure. FIG. 9 is described in conjunction with elements of FIGS. 1, 2, 3, 4, 5, 6, 7, and 8. FIG. 9 illustrates a flowchart 900. The exemplary method of flowchart 900 may be performed by any computer system, such as the first MaaS node 118A or other MaaS node of FIG. 1, the first aggregator node 134A or other aggregator node of FIG. 1, and / or the central MaaS node 136 of FIG. 1. The exemplary method of flowchart 900 may start at 902 and proceed to 904.

[0148] At 904, a first set of transaction records associated with a first MP node 116A of the first node package 120A may be received from a first MaaS node 118A of the first node package 120A based on a trigger event associated with the first node package 120A. Each of the first set of transaction records may be associated with a transaction message received by a first subscriber node 114A of the first node package 120A of the plurality of node packages 120. In one embodiment, prior to receiving the first set of transaction records, the first MP node 116A may be onboarded to the first node package 120A of the first MaaS network 102 and / or system 126. The onboarding of the first MP node 116A is further described, for example, in FIG. 2. An entity relationship diagram for MP node onboarding and revenue calculation of a mobility player associated with the MP node is further described, for example, in FIG. 6. The sequential operation of the MP node onboarding process is further described, for example, in FIG. 7.

[0149] In another embodiment, the first MaaS network 102 may include multiple central MP nodes (not shown in FIG. 1 ). Each of the multiple central MP nodes may be associated with a particular mobility provider and may be communicatively coupled to the MP node(s) of the respective mobility provider. For example, a first central MP node may be associated with a first MP (and coupled to the first MP node 116A), and a second central MP node may be associated with a second MP (and coupled to the second MP node 116B). In some scenarios, each of multiple node packages may include MP nodes associated with a single MP. In such cases, a single central MP node may be associated with each MP node (of that single MP) that may be included in such multiple node packages. In some embodiments, the onboarding processing of an MP node may be performed by a central MP node associated with the MP node, which may be associated with the same mobility provider as the MP node.

[0150] In an embodiment, a processor 806A of a first aggregator node 134A of the plurality of aggregator nodes 134 may be configured to receive, from a first MaaS node 118A, a first set of transaction records associated with a first MP node 116A based on a trigger event associated with a first node package 120A. Receiving the first set of transaction records is further described, for example, in FIG. 2.

[0151] At 906, a first summary record associated with the first MP node 116A may be determined based at least on an aggregation of transaction amounts associated with each of the received first series of transactions. In one embodiment, the processor 806A of the first aggregator node 134A may be configured to determine the first summary record associated with the first MP node 116A based at least on an aggregation of transaction amounts associated with each of the received first series of transaction records. For example, the processor 806A of the first aggregator node 134A may determine a sum of the transaction amounts or transaction values ​​of each of the received first series of transactions and determine the first summary record based on the determined sum. Determining the first summary record associated with the first MP node 116A is further described, for example, in FIGS. 2 and 5.

[0152] At 908, the determined first summary record may be transmitted to the central MaaS node 136. In an embodiment, the processor 806A of the first aggregator node 134A may be configured to transmit the determined first summary record associated with the first MP node 116A to the central MaaS node 136. The processor 808A of the central MaaS node 136 may be configured to receive the first summary record from the first aggregator node 134A.

[0153] At 910, a set of summary records associated with the first MP node 116A may be received from the multiple aggregator nodes 134. The set of summary records may include at least a first summary record received from the first aggregator node 134A. In an embodiment, the processor 808A of the central MaaS node 136 may be configured to receive the set of summary records associated with the first MP node 116A from the multiple aggregator nodes 134.

[0154] At 912, a second summary record associated with the first MP node 116A may be determined based at least on an aggregation of transaction amounts associated with each of the received set of summary records. In one embodiment, the processor 808A of the central MaaS node 136 may be configured to determine the second summary record associated with the first MP node 116A based at least on an aggregation of transaction amounts associated with each of the received set of summary records. For example, the processor 808A of the central MaaS node 136 may aggregate the transaction amounts associated with each of the received set of summary records to determine a total transaction amount for each of the plurality of transaction records associated with the first MP node 116A stored in various node packages of the first MaaS network 102. In one embodiment, the second summary record may indicate a total transaction amount for each of the plurality of transaction records associated with the first MP node 116A stored in various node packages of the first MaaS network 102. The determination of the second summary record associated with the first MP node 116A is further described, for example, in FIGS.

[0155] At 914, a first revenue share rate associated with the first MP corresponding to the first MP node 116A can be determined based on the determined second summary record. In some embodiments, the processor 808A of the central MaaS node 136 can be configured to determine the first revenue share rate associated with the first MP corresponding to the first MP node 116A based on the determined second summary record. For example, the second summary record can include a total transaction amount for each transaction corresponding to the multiple transaction records associated with the first MP node 116A. The first revenue share rate associated with the first MP can be determined based on the total transaction amount. The total transaction amount can be used as an indicator of revenue or loyalty earned by the first MP for providing services to customers through the first MaaS network 102 during a certain time frame or accounting period. In some embodiments, the determination of the first revenue share rate associated with the first MP can be further based on a second set of parameters. In some embodiments, determining a first revenue share rate associated with the first MP can be further based on applying AI system 146 (e.g., AI model 812D) to at least one of the determined second summary record or the second set of parameters. Determining a first revenue share rate associated with the first MP is further described, for example, in FIGS. 2 and 5.

[0156] At 916, the determined first revenue share rate associated with the first MP may be transmitted to the first MaaS node 118A. In an embodiment, the processor 808A of the central MaaS node 136 may be configured to transmit the determined first revenue share rate associated with the first MP to the first MaaS node 118A. The processor 804A of the first MaaS node 118A may receive the determined first revenue share rate from the central MaaS node 136. In some embodiments, the central MaaS node 136 may also transmit the first revenue share rate to the first MP node 116A. In an embodiment, the processor 804A of the first MaaS node 118A may be configured to store the received first revenue share rate associated with the first MP. In an embodiment, the processor 804A of the first MaaS node 118A may transmit the first revenue share rate associated with the first MP to the first MP node 116A. The processor 802A of the first MP node 116A may verify the first revenue share rate based on a plurality of transaction records stored in the first MP node 116A. The verification and storage of the first revenue share rate is further described, for example, in FIG. 3.

[0157] Although flowchart 900 is depicted as discrete operations such as 904, 906, 908, 910, 912, 914, and 916, the disclosure is not so limited. Thus, in some embodiments, such discrete operations may be further divided into additional operations, combined into fewer operations, or eliminated depending on the particular implementation without departing from the essence of the disclosed embodiments.

[0158] FIG. 10 illustrates an exemplary flowchart of a method for determining revenue share rates for small or medium-sized transactions on a Mobility as a Service (MaaS) platform using a common database architecture, according to an embodiment of the present disclosure. The description of FIG. 10 is provided with reference to elements in FIGS. 1, 2, 3, 4, 5, 6, 7, 8, and 9. FIG. 10 illustrates a flowchart 1000. The exemplary method of flowchart 1000 may be performed by any computer system, such as, for example, the first MaaS node 118A or other MaaS nodes of FIG. 1 and / or the first MP node 116A or other MP nodes of FIG. 1. The exemplary method of flowchart 1000 may start at 1002 and proceed to 1004.

[0159] At 1004, based on a trigger event associated with the first node package 120A, a first set of transaction records associated with a first MP node 116A of the first node package 120A may be extracted from the first MaaS node 118A. Each of the first set of transaction records may be associated with a transaction message received by a first subscriber node 114A of the first node package 120A. In an embodiment, prior to receiving the first set of transaction records, the first MP node 116A may be onboarded to the first node package 120A of the first MaaS network 102 and / or system 126. Based on onboarding the first MP node 116A to the first node package 120A, the first MP node 116A may be added to the first node package 120A, and a first smart contract between the first MP and the first MaaS player may be created. In other words, the first MP node 116A of the first node package 120A can be associated with the first MaaS node 118A based on the first smart contract. The onboarding process of the first MP node 116A is further described, for example, in FIG. 2 or FIG. 4. The entity relationship diagram for the onboarding process of the MP node and the revenue calculation of the mobility player associated with the MP node is further described, for example, in FIG. 6. The sequential operation of the onboarding process of the MP node is further described, for example, in FIG. 7.

[0160] In an embodiment, the processor 802A of the first MP node 116A may be configured to extract a first set of transaction records associated with the first MP node 116A from the first MaaS node 118A based on a trigger event associated with the first node package 120A. Extracting the first set of transaction records is further described in, for example, FIG. 4.

[0161] At 1006, a first summary record associated with the first MP node 116A can be determined based at least on an aggregation of transaction amounts associated with each of the received first series of transactions. In one embodiment, the processor 802A of the first MP node 116A can be configured to determine the first summary record associated with the first MP node 116A based at least on an aggregation of transaction amounts associated with each of the received first series of transaction records. Determination of the first summary record associated with the first MP node 116A is further described, for example, in FIGS. 4 and 5. In another embodiment, the first MP node 116A can be configured to send the extracted first series of transaction records to the first MaaS node 118A. The first MaaS node 118A can be configured to determine the first summary record associated with the first MP node 116A based at least on an aggregation of transaction amounts associated with each of the received first series of transaction records. For example, if the number of transaction records is less than a certain value (e.g., several hundred), the first MP node 116A can send the transaction records to the first MaaS node 118A, and the first MaaS node 118A can determine a first summary record.

[0162] At 1008, the determined first summary record may be transmitted to the first MaaS node 118A. In an embodiment, the processor 802A of the first MP node 116A may be configured to transmit the determined first summary record associated with the first MP node 116A to the first MaaS node 118A. The processor 804A of the first MaaS node 118A may be configured to receive the first summary record from the first MP node 116A.

[0163] At 1010, a set of summary records associated with the first MP node 116A may be received from a set of MP nodes of the plurality of node packages 120. The set of summary records may include at least a first summary record received from the first aggregator node 134A. In an embodiment, a processor 804A of the first MaaS node 118A may be configured to receive the set of summary records associated with the first MP node 116A from the set of MP nodes.

[0164] At 1012, a second summary record associated with the first MP node 116A can be determined based at least on an aggregation of transaction amounts associated with each of the received set of summary records. In an embodiment, the processor 804A of the first MaaS node 118A can be configured to determine the second summary record associated with the first MP node 116A based at least on an aggregation of transaction amounts associated with each of the received set of summary records. Determining the second summary record associated with the first MP node 116A is further described, for example, in Figures 4 and 5.

[0165] At 1014, a first smart contract between the first MP and the first MaaS player can be executed based on the determined second summary record to determine a first revenue share rate associated with the first MP corresponding to the first MP node 116A. In an embodiment, the processor 804A of the first MaaS node 118A can be configured to execute the first smart contract based on the determined second summary record to determine a first revenue share rate associated with the first MP corresponding to the first MP node 116A. For example, the first smart contract can include revenue calculation logic related to terms and service agreements between the first MP and the first MaaS provider. The revenue calculation logic can be applied to the second summary record during execution of the first smart contract for determining the first revenue share rate. The second summary record can include a total transaction amount for each transaction corresponding to a plurality of transaction records associated with the first MP node 116A. The total transaction amount may be used as an indicator of revenue or loyalty earned by the first MP for providing services to customers through the first MaaS network 102 during a certain time frame or accounting period. In some embodiments, the determination of the first revenue share rate associated with the first MP may be further based on a second set of parameters. Details related to the second set of parameters are shown, for example, in FIG. 2. In some embodiments, the determination of the first revenue share rate associated with the first MP may be further based on applying the AI ​​system 146 (e.g., AI model 812D) to at least one of the determined second summary record or the second set of parameters. The determination of the first revenue share rate associated with the first MP is further described, for example, in FIG. 4.

[0166] At 1016, the determined first revenue share rate associated with the first MP may be transmitted to the first MP node 116A. In an embodiment, the processor 804A of the first MaaS node 118A may be configured to transmit the determined first revenue share rate associated with the first MP to the first MaaS node 118A. The processor 802A of the first MP node 116A may receive the determined first revenue share rate from the first MaaS node 118A.

[0167] In one embodiment, the processor 804A of the first MaaS node 118A can be configured to store the received first revenue share rate associated with the first MP. In one embodiment, the processor 802A of the first MP node 116A can verify the first revenue share rate based on a plurality of transaction records stored in the first MP node 116A. The verification and storage of the first revenue share rate is further described, for example, in FIG. 3 (operations 304-320).

[0168] Although flowchart 1000 is depicted as discrete operations such as 1004, 1006, 1008, 1010, 1012, 1014, and 1016, the disclosure is not so limited. Thus, in some embodiments, such discrete operations may be further divided into additional operations, combined into fewer operations, or eliminated depending on the particular implementation without departing from the essence of the disclosed embodiments.

[0169] Various embodiments of the present disclosure may provide a non-transitory computer-readable medium and / or storage medium having computer-executable instructions stored thereon that may be executed by a machine and / or a computer (e.g., a system such as system 126). System 126 may include a plurality of aggregator nodes (e.g., a plurality of aggregator nodes 134) and a central Mobility as a Service (MaaS) node (e.g., a central MaaS node 136). The plurality of aggregator nodes 134 and the central MaaS node 136 may be communicatively coupled to a plurality of node packages (e.g., a plurality of node packages 120) of a first MaaS network (e.g., first MaaS network 102). Each node package of the plurality of node packages 120 may include a subscriber node of the first MaaS network 102, a mobility provider (MP) node of the first distributed ledger, and a MaaS node of the second distributed ledger. The computer-executable instructions or instructions may be executable by a first aggregator node (e.g., first aggregator node 134A) of the plurality of aggregator nodes 134 to perform a first set of operations. The first set of operations may include receiving a first set of transaction records from a first MaaS node (e.g., first MaaS node 118A) of a first node package (e.g., first node package 120A) of the plurality of node packages based on a trigger event associated with the first node package 120A. The first set of transaction records may be associated with a first MP node (e.g., first MP node 116A) of the first node package 120A. Each of the first set of transaction records may be associated with a transaction message received by a first subscriber node (e.g., first subscriber node 114A) of the first node package 120A. The first series of operations may further include determining a first summary record associated with the first MP node 116A based at least on an aggregation of transaction amounts associated with each of the received first series of transaction records.The first set of operations may further include transmitting the determined first summary record to the central MaaS node 136. The computer-executable instructions or instructions may be executable by the central MaaS node 136 to perform a second set of operations. The second set of operations may include receiving a set of summary records associated with the first MP node 116A from the plurality of aggregator nodes 134. The set of summary records may include at least the first summary record. The second set of operations may further include determining a second summary record associated with the first MP node 116A based at least on an aggregation of transaction amounts associated with each of the received set of summary records. The second set of operations may further include determining a first revenue share rate associated with the first MP corresponding to the first MP node 116A based on the determined second summary record. The second set of operations may further include transmitting the determined first revenue share rate associated with the first MP to the first MaaS node 118A.

[0170] Various embodiments of the present disclosure may provide a non-transitory computer-readable medium and / or storage medium having computer-executable instructions stored thereon that may be executed by a machine and / or a computer (e.g., a system). The system may include a plurality of node packages (e.g., a plurality of node packages 120) of a first Mobility as a Service (MaaS) network (e.g., a first MaaS network 102). Each node package of the plurality of node packages 120 may include a subscriber node of the first MaaS network 102, a Mobility Provider (MP) node of a first distributed ledger, and a MaaS node of a second distributed ledger. A first MP node (e.g., a first MP node 116A) of a first node package (e.g., a first node package 120A) of the plurality of node packages 120 may be associated with a first MaaS node (e.g., a first MaaS node 118A) of the first node package 120A based on a first smart contract. The computer-executable instructions or instructions may be executable by the first MP node 116A to perform a third set of operations. The third set of operations may include extracting a first set of transaction records from the first MaaS node 118A based on a trigger event associated with the first node package 120A. The first set of transaction records may be associated with the first MP node 116A. Each of the first set of transaction records may be associated with a transaction message received by a first subscriber node (such as the first subscriber node 114A) of the first node package 120A. The third set of operations may further include determining a first summary record associated with the first MP node 116A based at least on an aggregation of transaction amounts associated with each of the received first set of transaction records. The third set of operations may further include transmitting the determined first summary record to the first MaaS node 118A. The computer-executable instructions or instructions may be executable by the first MaaS node 118A to perform a fourth set of actions.A fourth set of operations may include receiving a set of summary records associated with the first MP node 116A from a set of MP nodes of the plurality of node packages 120. The set of summary records may include at least a first summary record. The fourth set of operations may further include determining a second summary record associated with the first MP node 116A based at least on an aggregation of transaction amounts associated with each of the received set of summary records. The fourth set of operations may further include executing a first smart contract based on the determined second summary record to determine a first revenue share rate associated with the first MP corresponding to the first MP node 116A. The fourth set of operations may further include transmitting the determined first revenue share rate associated with the first MP to the first MP node 116A.

[0171] An example aspect of the present disclosure may include a system (e.g., system 126). System 126 may include a plurality of aggregator nodes (e.g., a plurality of aggregator nodes 134) and a central Mobility as a Service (MaaS) node (e.g., a central MaaS node 136). The plurality of aggregator nodes 134 and the central MaaS node 136 may be communicatively coupled to a plurality of node packages (e.g., a plurality of node packages 120) of a first MaaS network (e.g., first MaaS network 102). Each node package of the plurality of node packages 120 may include a subscriber node of the first MaaS network 102, a mobility provider (MP) node of the first distributed ledger, and a MaaS node of the second distributed ledger. A first aggregator node (e.g., first aggregator node 134A) of the plurality of aggregator nodes 134 may be configured to receive a first set of transaction records from a first MaaS node (e.g., first MaaS node 118A) of a first node package (e.g., first node package 120A) of the plurality of node packages based on a trigger event associated with the first node package 120A. The first set of transaction records may be associated with a first MP node (e.g., first MP node 116A) of the first node package 120A. Each of the first set of transaction records may be associated with a transaction message received by a first subscriber node (e.g., first subscriber node 114A) of the first node package 120A. The first aggregator node 134A may be further configured to determine a first summary record associated with the first MP node 116A based at least on an aggregation of transaction amounts associated with each of the received first set of transaction records. The first aggregator node 134A may be further configured to send the determined first summary record to the central MaaS node 136. The central MaaS node 136 may be configured to receive a set of summary records associated with the first MP node 116A from the multiple aggregator nodes 134.The set of summary records may include at least a first summary record. The central MaaS node 136 may be further configured to determine a second summary record associated with the first MP node 116A based at least on an aggregation of transaction amounts associated with each of the received set of summary records. The central MaaS node 136 may be further configured to determine a first revenue share rate associated with the first MP corresponding to the first MP node 116A based on the determined second summary record. The central MaaS node 136 may be further configured to transmit the determined first revenue share rate associated with the first MP to the first MaaS node 118A.

[0172] An example aspect of the present disclosure may include a system that may include multiple node packages (e.g., multiple node packages 120) of a first Mobility as a Service (MaaS) network (e.g., first MaaS network 102). Each node package of the multiple node packages 120 may include a subscriber node of the first MaaS network 102, a mobility provider (MP) node of a first distributed ledger, and a MaaS node of a second distributed ledger. A first MP node (e.g., first MP node 116A) of a first node package (e.g., first node package 120A) of the multiple node packages 120 may be associated with a first MaaS node (e.g., first MaaS node 118A) of the first node package 120A based on a first smart contract. The first MP node 116A may be configured to extract a first set of transaction records from the first MaaS node 118A based on a trigger event associated with the first node package 120A. The first set of transaction records may be associated with the first MP node 116A. Each of the first set of transaction records may be associated with a transaction message received by a first subscriber node (such as the first subscriber node 114A) of the first node package 120A. The first MP node 116A may be further configured to determine a first summary record associated with the first MP node 116A based on an aggregation of transaction amounts associated with at least each of the received first set of transaction records. The first MP node 116A may be further configured to send the determined first summary record to the first MaaS node 118A. The first MaaS node 118A may be configured to receive the set of summary records associated with the first MP node 116A from the set of MP nodes of the plurality of node packages 120. The set of summary records may include at least the first summary record.The first MaaS node 118A may be further configured to determine a second summary record associated with the first MP node 116A based at least on an aggregation of transaction amounts associated with each of the received set of summary records. The first MaaS node 118A may be further configured to execute a first smart contract based on the determined second summary record to determine a first revenue share rate associated with the first MP corresponding to the first MP node 116A. The first MaaS node 118A may be further configured to transmit the determined first revenue share rate associated with the first MP to the first MP node 116A.

[0173] In one embodiment, the first MaaS network 102 may further include a scheduler node (e.g., scheduler node 144) communicatively coupled to the plurality of node packages 120. In one embodiment, the scheduler node 144 may generate a trigger event associated with the first node package 120A based on at least one of a predetermined schedule or receipt of a predetermined number of transaction records at the first MaaS node 118A. In one embodiment, each of the first MP node 116A and the first MaaS node 118A may be a blockchain distributed database node. In one embodiment, the first MP corresponding to the first MP node 116A and the first MaaS player corresponding to the first MaaS node 118A may be associated with the first MaaS network 102 based on at least one of a service agreement, a revenue sharing model, a data ownership agreement, a terms of service agreement, a privacy policy, or a policy amendment associated with an area of ​​operation of at least one of the first MP or the first MaaS player.

[0174] In one embodiment, the first MP node 116A can be onboarded to the first node package 120A, and the first MP can be associated with the first MaaS player based on the onboarding. To onboard the first MP node 116A, the first MaaS node 118A can be configured to define a service structure including configuration data related to the first MP. The first MaaS node 118A can be further configured to send an invite message to the first MP node 116A based on the definition of the service structure. The first MaaS node 118A can be configured to send at least one of a service contract, terms of service, and privacy policy to the first MP node 116A based on sending the invite message. Furthermore, the first MaaS node 118A can be configured to receive a sign-off confirmation message from the first MP node. The sign-off confirmation message can indicate the first MP node's sign-off to the service contract and privacy policy.

[0175] In some embodiments, the determination of the first summary record associated with the first MP node 116a can be further based on a first set of parameters. The first set of parameters can include business information associated with the first MP, service item information associated with each of the first set of transaction records, ticket sales data associated with each of the first set of transaction records, fare price master data associated with the first MP, service price master data associated with the first MP, and / or ticket transaction data associated with each of the first set of transaction records. In some embodiments, the determination of the first summary record can be further based on applying at least one of a big data platform, a Hadoop platform, or a MapReduce platform to at least one of the transaction amount associated with each of the received first set of transaction records or the first set of parameters.

[0176] In some embodiments, determining the first revenue share rate associated with the first MP can be further based on a second set of parameters. The second set of parameters can include a fee associated with the first MaaS player corresponding to the first MaaS node, a carbon dioxide emission associated with the first MP, a green energy incentive earned by the first MP, a traffic congestion reduction achieved by the first MP, and / or a fare slab for a vehicle associated with the first MP. In some embodiments, determining the first revenue share rate associated with the first MP can be further based on applying an artificial intelligence (AI) system (e.g., AI system 146) to at least one of the determined second summary record or the second set of parameters.

[0177] In one embodiment, the first MaaS node 118A may receive a first revenue share rate associated with the first MP from the central MaaS node 136 and transmit the received first revenue share rate to the first MP node 116A. In one embodiment, the first MP node 116A may receive the first revenue share rate associated with the first MP from the first MaaS node 118A and verify the received first revenue share rate based on a plurality of transaction records stored at the first MP node 116A. The plurality of transaction records may include at least a first series of transaction records. The first MP node 116A may transmit first verification information to the first MaaS node 118A indicating a verification result of the first revenue share rate received at the first MP node 116A. In one embodiment, the first MaaS node 118A may receive the first verification information from the first MP node 116A. The first MaaS node 118A may verify the first revenue share rate based on the first series of transaction records stored in the first MaaS node 118A and determine second verification information indicating the verification result of the first revenue at the first MaaS node 118A. The first MaaS node 118A may compare the received first verification information with the determined second verification information and, based on the comparison, store the first revenue share rate associated with the first MP in the first MaaS node 118A.

[0178] In one embodiment, the first MaaS node 118A can determine a first adjustment amount associated with the received first revenue share rate based on the comparison. The first MaaS node 118A can update the first revenue share rate associated with the first MP based on the determined first adjustment amount. The first MaaS node 118A can send the updated first revenue share rate to the first MP node 116A and store the updated first revenue share rate at the first MaaS node 118A. In one embodiment, the first MaaS node 118A can receive the first revenue share rate associated with the first MP from the central MaaS node 136 and store the received first revenue share rate at the first MaaS node 118A.

[0179] The present disclosure can be implemented in hardware or a combination of hardware and software. The present disclosure can be implemented in a centralized manner in at least one computer system, or in a distributed manner where different elements can be distributed across several interconnected computer systems. Any computer system or other device adapted to perform the methods described herein can be suitable. The combination of hardware and software can be a general-purpose computer system that includes a computer program that, when loaded and executed, can control the computer system to perform the methods described herein. The present disclosure can be implemented in hardware, including portions of integrated circuits that also perform other functions.

[0180] The present disclosure may also be embodied in a computer program product, which includes all features that enable the implementation of the methods described herein and which is capable of executing these methods when loaded into a computer system. A computer program in this context means any expression, in any language, code or notation, of a set of instructions intended to cause a system having information processing capabilities to perform a particular function, either directly, or after a) conversion into another language, code or notation, or b) reproduction in a different content form, or both.

[0181] While the present disclosure has been described with reference to several embodiments, those skilled in the art will recognize that various modifications may be made and equivalents may be substituted without departing from the scope of the disclosure. Additionally, many modifications may be made to adapt a particular situation or material to the teachings of the disclosure without departing from the scope of the disclosure. Therefore, it is not intended that the disclosure be limited to the particular embodiments disclosed, but rather, it is intended to include all embodiments falling within the scope of the appended claims. [Explanation of symbols]

[0182] 100 Network Environment 102 First MaaS Network 104 Client Tier 106 Broker Layer 108 Server Layer 110A~N Issuer nodes 112 Broker node device 114A~N Subscriber Node 116A~N Mobility Provider (MP) Nodes 118A~N MaaS nodes 120 Multiple Node Packages 122A Analysis Node 122B Monitor Node 124 Archive Database Nodes 126 cache database nodes (system) 128 First Server 130 Administrator device 132 Administrator 134A~N Aggregator nodes 136 Central MaaS Nodes 138 Configuration Database 140 Consumer Database 142 Transaction Database 144 scheduler nodes 146 Artificial Intelligence (AI) Systems

Claims

1. 1. A system comprising: a plurality of aggregator nodes; a central Mobility as a Service (MaaS) node; the plurality of aggregator nodes and the central MaaS node are communicatively coupled to a plurality of node packages of a first MaaS network, each node package of the plurality of node packages including a subscriber node of the first MaaS network, a mobility provider (MP) node of a first distributed ledger, and a MaaS node of a second distributed ledger, and a first aggregator node of the plurality of aggregator nodes: receiving a first set of transaction records from a first MaaS node of a first node package of the plurality of node packages based on a trigger event associated with the first node package; the first set of transaction records is associated with a first MP node of the first node package; each of the first series of transaction records associated with a transaction message received by a first subscriber node of the first node package; determining a first summary record associated with the first MP node based at least on an aggregation of transaction amounts associated with each of the received first series of transaction records; sending the determined first summary record to the central MaaS node; The central MaaS node is configured as follows: receiving a set of summary records from the plurality of aggregator nodes, the set including at least a first summary record associated with the first MP node; determining a second summary record associated with the first MP node based at least on an aggregation of transaction amounts associated with each of the received set of summary records; determining a first revenue sharing rate associated with a first MP corresponding to the first MP node based on the determined second summary record; sending the determined first revenue share rate associated with the first MP to the first MaaS node; It is configured as follows: A system characterized by:

2. the first MaaS network further includes a scheduler node communicatively coupled to the plurality of node packages; The system of claim 1 .

3. the trigger event associated with the first node package is generated by the scheduler node based on at least one of a predetermined schedule or receipt of a predetermined number of transaction records at the first MaaS node; The system of claim 2 .

4. Each of the first MP node and the first MaaS node is a blockchain distributed database node. The system of claim 1 .

5. The first MP corresponding to the first MP node and the first MaaS player corresponding to the first MaaS node are associated with the first MaaS network based on at least one of a service agreement, a revenue sharing model, a data ownership agreement, a terms of service, a privacy policy, or a policy amendment associated with an area of ​​operation of at least one of the first MP or the first MaaS player; The system of claim 1 .

6. The first MP node is onboarded to the first node package, and the first MP is associated with the first MaaS player based on the onboarding, and the first MaaS node, in order to onboard the first MP node, defining a service structure including configuration data related to the first MP; Sending an invite message to the first MP node based on the service structure definition; Sending at least one of the service agreement, the terms of service, and the privacy policy to the first MP node based on the sending of the invitation message; receiving a sign-off confirmation message from the first MP node indicating that the first MP node has signed off on the service agreement and the privacy policy; The system of claim 5 , configured to:

7. Determining the first summary record associated with the first MP node comprises: Company information related to the first MP; service item information associated with each of said first series of transaction records; ticket sales data associated with each of said first series of transaction records; freight price master data associated with said first MP; Service price master data relating to the first MP; or ticket transaction data associated with each of said first series of transaction records; The system of claim 1 , further based on a first set of parameters including at least one of:

8. determining the first summary record is further based on applying at least one of a big data platform, a Hadoop platform, or a MapReduce platform to at least one of the transaction amount associated with each of the received first series of transaction records or the first set of parameters; The system of claim 7.

9. Determining the first revenue share rate associated with the first MP includes: a fee associated with a first MaaS player corresponding to said first MaaS node; a carbon dioxide emission associated with said first MP; the green energy incentives earned by the first MP; The traffic congestion relief achieved by the first MP, or a fare tier for a vehicle associated with said first MP; The system of claim 1 , further based on a second set of parameters including at least one of:

10. determining the first revenue share rate associated with the first MP is further based on applying an artificial intelligence (AI) system to at least one of the determined second summary record or the second set of parameters; The system of claim 9.

11. The first MaaS node receiving the first revenue share rate associated with the first MP from the central MaaS node; Sending the received first revenue share rate to the first MP node; The system of claim 1 .

12. The first MP node receiving the first revenue share rate associated with the first MP from the first MaaS node; verifying the received first revenue share rate based on a plurality of transaction records stored in the first MP node, the plurality of transaction records including the at least first series of transaction records; sending first verification information to the first MP node indicating a result of the verification of the received first revenue share rate at the first MP node; The system of claim 11.

13. The first MaaS node receiving the first verification information from the first MP node; verifying the first revenue share rate based on the first set of transaction records stored at the first MaaS node to determine second verification information indicating a result of the verification of the first revenue share rate at the first MaaS node; comparing the received first verification information with the determined second verification information; storing the first revenue share rate associated with the first MP in the first MaaS node based on the comparison; The system of claim 12.

14. The first MaaS node determining a first adjustment amount associated with the received first revenue share based on the comparison; updating the first revenue share rate associated with the first MP based on the determined first adjustment amount; Sending the updated first revenue share rate to the first MP node; storing the updated first revenue share rate in the first MaaS node; The system of claim 13.

15. The first MaaS node receiving the first revenue share rate associated with the first MP from the central MaaS node; storing the received first revenue share rate in the first MaaS node; The system of claim 1 .

16. 1. A system comprising: A first Mobility as a Service (MaaS) network includes a plurality of node packages, each node package of the plurality of node packages including a subscriber node of the first MaaS network, a Mobility Provider (MP) node of a first distributed ledger, and a MaaS node of a second distributed ledger, wherein a first MP node of a first node package of the plurality of node packages is associated with the first MaaS node of the first node package based on a first smart contract, and the first MP node: extracting a first set of transaction records stored in the first MaaS node based on a trigger event associated with the first node package; the first set of transaction records is associated with the first MP node; each of the first series of transaction records associated with a transaction message received by a first subscriber node of the first node package; determining a first summary record associated with the first MP node based at least on an aggregation of transaction amounts associated with each of the extracted first set of transaction records; sending the determined first summary record to the first MaaS node; The first MaaS node is configured as follows: receiving a set of summary records from a set of MP nodes of the plurality of node packages, the set including at least a first summary record associated with the first MP node; determining a second summary record associated with the first MP node based at least on an aggregation of transaction amounts associated with each of the received set of summary records; Executing the first smart contract based on the determined second summary record to determine a first revenue share rate associated with a first MP corresponding to the first MP node; transmitting the determined first revenue share rate associated with the first MP to the first MP node; It is configured as follows: A system characterized by:

17. The first MP node receiving the first revenue share rate associated with the first MP from the first MaaS node; verifying the received first revenue share rate based on a plurality of transaction records stored in the first MP node, the plurality of transaction records including the at least first series of transaction records; sending first verification information to the first MP node indicating a result of the verification of the received first revenue share rate at the first MP node; The system of claim 16 further configured to:

18. The first MaaS node receiving the first verification information from the first MP node; verifying the first revenue share rate based on the first set of transaction records stored at the first MaaS node to determine second verification information indicating a result of the verification of the first revenue share rate at the first MaaS node; comparing the received first verification information with the determined second verification information; storing the first revenue share rate associated with the first MP in the first MaaS node based on the comparison; The system of claim 17 further configured to:

19. The first MaaS node determining a first adjustment amount associated with the received first revenue share based on the comparison; updating the first revenue share rate associated with the first MP based on the determined first adjustment amount; Sending the updated first revenue share rate to the first MP node; storing the updated first revenue share rate in the first MaaS node; 20. The system of claim 18, further configured to:

20. the first MaaS node is further configured to store the determined first revenue share rate at the first MaaS node; 17. The system of claim 16.

21. 1. A system comprising: a plurality of aggregator nodes and a central Mobility as a Service (MaaS) node communicatively coupled to a plurality of node packages of a first MaaS network, wherein each node package of the plurality of node packages includes a subscriber node of the first MaaS network, a Mobility Provider (MP) node of a first distributed ledger, and a MaaS node of a second distributed ledger; a first aggregator node of the plurality of aggregator nodes receiving a first series of transaction records from a first MaaS node of the first node package based on a trigger event associated with the first node package of the plurality of node packages; the first set of transaction records is associated with a first MP node of the first node package; each of the first series of transaction records associated with a transaction message received by a first subscriber node of the first node package; determining, by the first aggregator node, a first summary record associated with the first MP node based at least on an aggregation of transaction amounts associated with each of the received first series of transaction records; the first aggregator node sending the determined first summary record to the central MaaS node; the central MaaS node receiving, from the plurality of aggregator nodes, a set of summary records including at least a first summary record associated with the first MP node; determining, by the central MaaS node, a second summary record associated with the first MP node based at least on an aggregation of transaction amounts associated with each of the received set of summary records; The central MaaS node determines a first revenue share rate associated with a first MP corresponding to the first MP node based on the determined second summary record; the central MaaS node transmitting the determined first revenue share rate associated with the first MP to the first MaaS node; Including, A method characterized by:

22. 1. A non-transitory computer-readable medium having stored thereon computer-executable instructions that, when executed by a computer in a system including a plurality of aggregator nodes and a central Mobility as a Service (MaaS) node, perform the following steps: a first aggregator node of the plurality of aggregator nodes receiving a first set of transaction records; the plurality of aggregator nodes and the central MaaS node are communicatively coupled to a plurality of node packages of a first MaaS network, each node package of the plurality of node packages including a subscriber node of the first MaaS network, a mobility provider (MP) node of a first distributed ledger, and a MaaS node of a second distributed ledger; the first set of transaction records is received from a first MaaS node of the first node package of the plurality of node packages based on a trigger event associated with the first node package; the first set of transaction records is associated with a first MP node of the first node package; each of the first series of transaction records associated with a transaction message received by a first subscriber node of the first node package; determining, by the first aggregator node, a first summary record associated with the first MP node based at least on an aggregation of transaction amounts associated with each of the received first series of transaction records; the first aggregator node sending the determined first summary record to the central MaaS node; the central MaaS node receiving, from the plurality of aggregator nodes, a set of summary records including at least a first summary record associated with the first MP node; determining, by the central MaaS node, a second summary record associated with the first MP node based at least on an aggregation of transaction amounts associated with each of the received set of summary records; The central MaaS node determines a first revenue share rate associated with a first MP corresponding to the first MP node based on the determined second summary record; the central MaaS node transmitting the determined first revenue share rate associated with the first MP to the first MaaS node; 10. A non-transitory computer-readable medium for causing the system to perform operations including:

Images