The MAAS platform supports a shared database architecture for large-scale transactions and node archiving.
By introducing a shared database architecture on the MaaS platform and using aggregators and archive database nodes to manage transaction records, the challenges of storing and managing large-scale transaction records are solved, improving efficiency and meeting audit and compliance requirements.
Patent Information
- Application Number
- CN202180005080.8
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Priority Date
- 2020-02-18
- Filing Date
- 2021-02-17
- Publication Date
- 2025-10-28
- Estimated Expiration
- 2041-02-17
AI Technical Summary
On the MaaS platform, the large number of nodes and users leads to a large volume of transaction records generated, making it difficult to store and manage historical data and affecting operation speed.
The system adopts a shared database architecture, which manages transaction records through aggregators and archive database nodes, sets data retention thresholds and storage durations, and achieves effective management and archiving of transaction records.
It improves the efficiency of transaction record storage and management on the MaaS platform, reduces processing latency, supports non-real-time transaction processing and long-term storage, and meets the audit and compliance requirements of regulatory authorities.
Smart Images

Figure HDA0003519868910000011 
Figure HDA0003519868910000021 
Figure HDA0003519868910000031
Abstract
Description
[0001] Cross-reference to related applications / incorporation by reference
[0002] This application claims priority to U.S. Provisional Patent Application Serial No. 62 / 978,137, filed February 18, 2020, the entire contents of which are incorporated herein by reference. Technical Field
[0003] Various embodiments of this disclosure relate to Mobile-as-a-Service (MaaS) and distributed ledger technologies. More specifically, various embodiments of this disclosure relate to systems and methods for supporting large-scale transaction and node archiving on a MaaS platform based on a shared database architecture. Background Technology
[0004] In a Mobility-as-a-Service (MaaS) platform, multiple mobility providers can offer their services through an infrastructure that can be built on a closed platform. Each such mobility provider can have separate ticketing infrastructure (e.g., ticket gates and point-of-sale (PoS) devices) or separate applications (e.g., ticket booking applications, ticket processing applications, and ride-hailing applications) to create, pay for, or manage trips.
[0005] On such a MaaS platform, due to the large number of nodes and the vast number of users it can serve, a massive flow of transaction messages can exist between these nodes at any given time. For example, each node on the MaaS platform can be associated with a large number of homogeneous and heterogeneous mobility participants. Each mobility participant can have a large number of users associated with it, generating a large volume of transaction messages. This results in the generation of a large number of transaction records on the MaaS platform. Storing and managing such a large number of transaction records on a MaaS platform would be difficult. Moreover, long-term management of historical data (such as historical transaction records) on a distributed ledger system (such as a MaaS platform) would be cumbersome and slow down operations.
[0006] By comparing the described system with some aspects of this disclosure, the limitations and disadvantages of conventional and traditional methods will become apparent to those skilled in the art, as illustrated in the remainder of this application and with reference to the accompanying drawings. Summary of the Invention
[0007] As set forth more fully in the claims, and substantially as illustrated in at least one figure and / or described in conjunction with at least one figure, a system and method are provided to support large-scale transaction and node archiving on a Mobile-as-a-Service (MaaS) platform based on a shared database architecture.
[0008] These and other features and advantages of this disclosure can be understood by reading the following detailed description of the disclosure and the accompanying drawings, in which the same reference numerals always denote the same parts. Attached Figure Description
[0009] Figure 1 This is a diagram of an exemplary network environment for supporting large-scale transactions and node archiving on a Mobile-as-a-Service (MaaS) platform based on a shared database architecture, according to embodiments of this disclosure.
[0010] Figure 2 This is an exemplary block diagram of a plug-in interface for a node packet of a MaaS network according to an embodiment of the present disclosure.
[0011] Figure 3 This is an exemplary sequence diagram depicting support for large-scale transactions and node archiving on a MaaS platform based on a shared database architecture, according to embodiments of the present disclosure.
[0012] Figure 4A , 4B Together with 4C, this describes an exemplary scenario for supporting large-scale transactions and node archiving on a MaaS platform based on a shared database architecture, according to embodiments of this disclosure.
[0013] Figure 5 This is an exemplary scenario depicting the aggregation of transaction messages based on aggregation logic according to embodiments of this disclosure.
[0014] Figure 6 This is a block diagram of a system for supporting large-scale transactions and node archiving on a MaaS platform based on a shared database architecture, according to embodiments of the present disclosure.
[0015] Figure 7 An exemplary flowchart illustrating a method for supporting large-scale transactions and node archiving on a MaaS platform based on a shared database architecture, according to embodiments of the present disclosure, is shown. Detailed Implementation
[0016] The implementations described below can be found in the disclosed systems and methods for managing transaction records aggregated and archived on a Mobility as a Service (MaaS) network. The disclosed system may be part of a joint transportation management system that facilitates the operation of multiple homogeneous or heterogeneous mobility providers and their infrastructure (such as ticket gates, applications, and / or point-of-sale (PoS) devices) on a MaaS network to provide various mobility services. Each mobility provider can have secure data ownership and can control the shared use of related transaction records through a distributed ledger. This can enhance connectivity between various mobility providers. Based on the controlled shared use of related transaction records through a distributed ledger, the system can also enhance the handling of revenue-sharing models, roaming management, and contract management among different mobility providers.
[0017] An exemplary aspect of this disclosure provides a system that may include multiple node packets associated with a MaaS network. Each of the multiple node packets may 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 may also include multiple publisher nodes and proxy node devices. One or more nodes associated with the MaaS network may be configured to process multiple transaction records associated with a trip plan in a series of trip plans included in a MaaS mobility service. The transaction records may also be associated with travel users (such as roaming users). The multiple transaction records may be associated with information such as, but not limited to, ticketing information, subscription information, payment information, revenue sharing information, or mobility service information. Each of the multiple transaction records may be associated with a transaction message received by a subscriber node (such as a first subscriber node) of a first node packet of the multiple node packets. The subscriber node may receive the transaction message from a publisher node (such as a first publisher node of the multiple publisher nodes) via a proxy node device.
[0018] The disclosed system may also include an aggregator database node and an archive database node. The aggregator database node may be communicatively coupled to each of the multiple node packages, and the archive database node may be communicatively coupled to the aggregator database node. A first MaaS node from a first node package of the multiple node packages may be configured to select a first set of transaction records from multiple transaction records stored on the first MaaS node. The first set of transaction records may be selected from the multiple transaction records based on a first data retention threshold and a first storage duration for each of the first multiple transaction records on the first MaaS node.
[0019] The first MaaS node of the first node package can also be configured to transfer the first set of selected transaction records to the aggregator database node for storage. The first set of selected transaction records can be transferred from the first MaaS node to the aggregator database node based on the completion of a first storage duration in the first MaaS node. For example, the first data retention threshold could be three days. Therefore, after three days of storage of the first set of transaction records in the first MaaS node, the first set of transaction records can be transferred to the aggregator database node.
[0020] The first MaaS node can also be configured to invalidate (or deactivate, i.e., soft delete) the first set of selected transaction records from the first MaaS node based on the transfer of the first set of selected transaction records to the aggregator database node. Therefore, older transaction records from the first plurality of transaction records can be invalidated in the first MaaS node but can still remain in the aggregator database node for any further use.
[0021] According to an embodiment, the first MaaS node can also be configured to control the selection of a second set of transaction records from a third set of transaction records stored on the aggregator database node. The selection of the second set of transaction records can be based on a second data retention threshold and a second storage duration for each of the third set of transaction records stored on the aggregator database node. The third set of transaction records may include a first set of transaction records that can be received by the aggregator database node from the first MaaS node. The third set of transaction records in the aggregator database node may include the first set of transaction records already stored on the aggregator database node and other transaction records (which may be newer or older than the first set of transaction records). For example, the second data retention threshold may be sixty days. The aggregator database node can also transfer the selected second set of transaction records to an archive database node for storage there. Therefore, after the second set of transaction records has been stored on the aggregator database node for sixty days, it can be transferred to the archive database node.
[0022] Compared to conventional systems that store all transaction records on the same database (e.g., in the context of a MAAS network) for the entire duration for which they need to be stored, the disclosed system provides a selection of older transaction records that can be stored on MaaS nodes. The selection of older transaction records on MaaS nodes can be based on the storage threshold of the MaaS node (e.g., a first data retention threshold) and the storage duration of such older transaction records on the MaaS node. Selected older transaction records can be moved to an aggregator database node for storage. Additionally, transaction records can be stored on an aggregator database node for a specific duration based on the aggregator database node's storage threshold (e.g., a second data retention threshold). Transaction records stored on an aggregator database node for a duration exceeding the aggregator database node's storage threshold can also be moved to an archive database node for storage. The storage thresholds of the aggregator database node and the archive database node can be configured such that a MaaS node can store a limited number of transaction records at any given time, as other transaction records can be sequentially migrated to the aggregator database node and the archive database node. This periodic migration improves the storage and management of large-scale transaction records in a MaaS network. Additionally, since a limited number of transaction records can be stored at a MaaS node at any given time (based on a storage threshold), the processing latency of transactions associated with transaction records stored on the MaaS node can be minimized.
[0023] Furthermore, aggregator database nodes can provide support for non-real-time transaction processing across the MaaS network and its various mobility providers. For example, an aggregator database node can include a month's worth of transaction records from all mobility providers across the MaaS network. These transaction records can be aggregated to consolidate ticketing transactions (e.g., closing monthly transactions) and to calculate revenue shares associated with different mobility providers and the organization managing the MaaS network itself. Moreover, archive database nodes can store large amounts of transaction records for longer periods to support auditing and compliance of transactions associated with such long-term storage (e.g., transaction records can be stored on archive database nodes for 3-5 years, as required by different regulatory bodies). Additionally, archive database nodes can support the analysis and visualization of large-scale transaction records associated with the MaaS network through an administrator system associated with the MaaS network, as required by the management of the MaaS network.
[0024] Figure 1 This is a diagram illustrating an exemplary network environment for supporting large-scale transactions and node archiving on a Mobile-as-a-Service (MaaS) platform based on a shared database architecture, according to embodiments of this disclosure. (See also...) Figure 1The diagram illustrates a block diagram of a network environment 100. Network environment 100 may include a first MaaS network 102, which may be associated with a publish-subscribe model. The first MaaS network 102 may include a first plurality of nodes, which may be configured in layers such as a client layer 104, a proxy layer 106, and a server layer 108. The first plurality of nodes may include a plurality of publisher nodes 110 in the client layer 104; and a proxy node device 112 in the proxy layer 106. The first plurality of nodes may also include a first plurality of subscriber nodes 114A, 114B, ... 114N, a plurality of mobility provider (MP) nodes 116A, 116B, ... 116N of a first distributed ledger, a plurality of MaaS nodes 118A, 118B, ... 118N of a second distributed ledger, an aggregator database node 122, an archive database node 124, and a cache database node 126 in the server layer 108. A plurality of subscriber nodes 114A, 114B, ... 114N, a plurality of MP nodes 116A, 116B, ... 116N, and a plurality of MaaS nodes 118A, 118B, ... 118N can collectively form a plurality of node packets 120 of a first MaaS network 102. For example, a first node packet in the plurality of node packets 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 packet in the plurality of node packets 120 may include a second subscriber node 114B, a second MP node 116B, and a second MaaS node 118B. An aggregator database node 122 can be communicatively coupled to the plurality of node packets 120. An archive database node 124 can be communicatively coupled to the aggregator database node 122. Multiple publisher nodes 110 in the client layer 104 can be configured to communicate with a first plurality of subscriber nodes 114A, 114B, ... 114N via proxy node device 112.
[0025] Although Figure 1 A single proxy node device 112 is shown, but the scope of this disclosure is not limited thereto. In embodiments, network environment 100 may include more than one proxy node device 112 without departing from the scope of this disclosure. In another embodiment, network environment 100 may include intelligent proxy nodes, which may include the functionality of one or more proxy node devices.
[0026] The plurality of publisher nodes 110 may include a first publisher node 110A, a second publisher node 110B, ... and an Nth publisher node 110N. The plurality of first subscriber nodes 114A, 114B, ... 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 plurality of first subscriber nodes 114A, 114B, ... 114N may interface with the proxy node device 112 via a plug-in for data (e.g., transaction messages) communication. Each of the plurality of first subscriber nodes 114A, 114B, ... 114N may be associated with a corresponding 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 may 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.
[0027] Network environment 100 may also include a first server 128 and an administrator device 130 operable by an administrator 132 of the first MaaS network 102. In network environment 100, there may also be users (not shown) who can interact with multiple publisher nodes 110 to utilize mobility services from different mobility providers of the first MaaS network 102.
[0028] The first MaaS network 102 may include a network of nodes (such as a first plurality of nodes that can be configured to operate in the client layer 104, the proxy layer 106, and the server layer 108). The first MaaS network 102 can process transactions (such as transaction messages) of MaaS mobile services associated with multiple mobility providers. Each such mobility provider may own, lease, or manage a cluster of nodes in each of the client layer 104 and the server layer 108 of the first MaaS network 102. For example, a first publisher node 110A, a first subscriber node 114A, and a first MP node 116A may be associated with a first mobility provider. A second publisher node 110B, a second subscriber node 114B, and a first MP node 116A may be associated with a second mobility provider that may be different from the first mobility provider.
[0029] In some embodiments, the first MaaS network 102 may support open standard specifications for MaaS. In this case, multiple publisher nodes 110 (e.g., ticket readers or sensor devices) from different companies associated with various mobility providers of the first MaaS network 102 can join the first MaaS network 102 as homogeneous publisher nodes. Furthermore, legacy ticket readers or sensor devices can connect to the first MaaS network 102 using standard communication protocols such as Message Queuing Telemetry Transport (MQTT), Advanced Message Queuing Protocol (AMQP), or Message-Oriented Middleware (MOM) messaging frameworks. By using standard communication protocols, the first MaaS network 102 can provide ticket roaming functionality to users. For example, a ticket reader from any mobility provider can scan a user's electronic ticket to obtain MaaS mobility services and can provide the user with the appropriate mobility services of the mobility provider (regardless of who issued the ticket) based on seamless and secure access to the first MaaS network 102.
[0030] According to an embodiment, each of the plurality of MP nodes 116A, 116B, ... 116N may be associated with a separate mobility provider of the first MaaS network 102. MaaS mobility services may be provided by homogeneous mobility providers (such as multiple taxi companies or multiple railway companies) or heterogeneous mobility providers through a set of homogeneous devices, applications, or ticket gates, or a set of heterogeneous ticket gates, applications, and point-of-sale (PoS) devices. MaaS mobility services may be a combination of individual service offerings from one or more homogeneous or heterogeneous mobility providers. MaaS mobility services may include, for example, train services, bus services, taxi / taxi services, subway services, airplane services, fleet services, ride-hailing services, car-sharing services, carpooling services, car rental services, bicycle-sharing services, or combinations thereof.
[0031] Each of the multiple publisher nodes 110A, 110B, ... 110N may include suitable logic, circuitry, code, and / or interfaces that can be configured to operate as a ticket processing client for the mobility service of the corresponding mobility provider. For example, as a ticket processing client, each of the first publisher node 110A, the second publisher node 110B, ... and the Nth publisher node 110N can read, issue, recharge, or cancel tickets to create events associated with the corresponding mobility service. Based on such events, transaction messages can be generated by each of the first publisher node 110A, the second publisher node 110B, ... and the Nth publisher node 110N, and the generated transaction messages can be transmitted via proxy node device 112 to one or more subscriber nodes in the first MaaS network 102 or other MaaS networks. Examples of publisher nodes may include, but are not limited to, consumer electronic devices with travel planning or booking applications, ticket readers at ticket gates, point-of-sale (PoS) devices at ticket booths, mobile POS, ticket vending machines, and smart doors of transport vehicles that can read tickets to start or end a journey.
[0032] Proxy node device 112 may include suitable logic, circuitry, code, and / or interfaces that can be configured to route transaction messages from publisher nodes (such as the first publisher node 110A) to appropriate nodes, such as subscriber nodes (such as the first subscriber node 114A). Proxy node device 112 may be configured to communicate with each of a plurality of publisher nodes 110A, 104B, ... 104N and each of the first plurality of subscriber nodes 114A, 114B, ... 114N via appropriate publish-subscribe network protocols, such as, but not limited to, message passing protocols based on Message Queuing Telemetry Transport (MQTT), message passing protocols based on Advanced Message Queuing Protocol (AMQP), or message passing frameworks based on Message-Oriented Middleware (MOM). Example implementations of proxy node device 112 may include, but are not limited to, application servers, cloud servers, mainframe servers, database servers, web servers, or other types of servers.
[0033] Each of the first plurality of subscriber nodes 114A, 114B, ... 114N may include suitable logic, circuitry, code, and / or interfaces that can be configured to receive transaction messages from one or more of the plurality of publisher nodes 110A, 110B, ... 110N via proxy node device 112. In an embodiment, each of the first plurality of subscriber nodes 114A, 114B, ... 114N may interface with proxy node device 112 via a plug-in for data (e.g., transaction message) communication. Each transaction message may include a topic that can be subscribed to by one or more of the first plurality of subscriber nodes 114A, 114B, ... 114N. Example implementations of subscriber nodes may include, but are not limited to, web servers, edge devices, edge nodes, cloud servers, clusters of cloud-based servers, workstations, or any device with fog or cloud computing capabilities.
[0034] Each of the MP nodes 116A, 116B, ... 116N may include suitable logic, circuitry, code, and / or interfaces configured to store transaction records associated with a corresponding mobility provider. For example, the first MP node 116A may store transaction records associated with a first mobility provider. In embodiments, each transaction record stored on each MP node may be associated with a two-party transaction. For example, a transaction record stored on an MP node of a mobility provider may be associated with a transaction that may involve both that mobility provider and a MaaS provider. Transaction records may include records of a user's travel. Each travel may correspond to a mobility service that may be provided by the first mobility provider in at least one travel mode. Each of the MP nodes 116A, 116B, ... 116N may be a node referred to as distributed ledger 116 (such as a first distributed ledger) that may store transaction records of various mobility providers in the first MaaS network 102. In embodiments, each MP node may be implemented as, but is not limited to, an edge device, an edge node, or a distributed ledger node with fog or cloud computing capabilities.
[0035] Each of the MaaS nodes 118A, 118B, ... 118N may include suitable logic, circuitry, code, and / or interfaces that can be configured to store transaction records associated with all mobility providers of the first MaaS network 102. The storage of transaction records associated with each mobility provider can be used to settle travel transactions between mobility providers offering mobility services to users. In an embodiment, each transaction record stored on each MaaS node may be associated with a multi-party transaction. For example, a transaction record stored on a MaaS node may be associated with a transaction involving one or more mobility providers and MaaS providers of the first MaaS network 102. In this case, MP nodes and MaaS nodes may store the same transaction. Each of the MaaS nodes 118A, 118B, ... 118N may correspond to a node of a distributed ledger 118 (such as a second distributed ledger) that can store transaction records associated with the first MaaS network 102. In an embodiment, each MaaS node may be implemented as, but is not limited to, an edge device, an edge node, or a distributed ledger node with fog or cloud computing capabilities.
[0036] In an embodiment, one or more of the plurality of node packets 120 may include subscriber nodes, a plurality of MP nodes of a first distributed ledger, and a MaaS node of a second distributed ledger. For example, the first node packet of the plurality of node packets 120 may include a first subscriber node 114A, a first MP node 116A, a second MP node 116B, and a first MaaS node 118A. In another example, the second node packet may include a second subscriber node 114B, a first MP node 116A, and a second MaaS node 118B. In another example, the third node packet may include a third subscriber node 114C, a first MP node 116A, a second MP node 116B, and a third MaaS node 118C. Each of the plurality of MP nodes may be associated with a separate mobility provider of the first MaaS network 102. In an 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).
[0037] In this embodiment, at least two nodes of each of distributed ledger 116 and / or distributed ledger 118 may store transaction records associated with the MaaS mobility service. Transaction records associated with the MaaS mobility service may include a collection of state objects, such as an initial state object and updated versions of the initial state object. Each state object may include a smart contract, contract code (or rules of the transaction agreed upon by the parties to the transaction), and state characteristics (which may be updated when the transaction record is updated based on transaction messages from the publisher node).
[0038] In at least one embodiment, each of distributed ledgers 116 and 118 may be a decentralized and distributed database system that maintains an immutable record of data operations or transactions. Sets of data operations may be grouped together as blocks and may also be linked to previous blocks of data operations to form a chain of blocks. All blocks of data operations may be stored in a decentralized manner, whereby at least two participants or nodes of distributed ledgers 116 and 118 may store a subset of blocks associated with one or more transactions in which these at least two participants or nodes may participate. Additionally, each of distributed ledgers 116 and 118 may include an operating system (e.g., a Java Virtual Machine (JVM)) that may allow the deployment of smart contracts among multiple parties (e.g., the mobility provider and the MaaS provider of the first MaaS network 102).
[0039] As an example and not a limitation, each of distributed ledgers 116 and 118 can be a Corda blockchain, an Ethereum blockchain, or a Hyperledger blockchain. Each of distributed ledgers 116 and 118 can store a collection of immutable state objects that can be tracked by the corresponding distributed ledger. State objects can include transaction data (from transaction records), such as smart contracts between parties, contract code (rules of the transaction), and content including state characteristics with specific state values. Smart contracts can include a set of conditions under which the parties to the smart contract can agree to interact with each other. Smart contracts can run on one or more nodes of the corresponding distributed ledger and can govern the transitions between state objects to generate transactions. Smart contracts can be written once, reused for a large number of state objects, and can reference governing legal provisions via cryptographic hashes.
[0040] Each of distributed ledgers 116 and 118 can use a secure cryptographic hash to identify the parties and data, and also links state objects to previous versions of state objects to further provide a chain of proof. Transactions between a group of parties can be stored (as associated transaction records) on the corresponding distributed ledger, allowing only the group of parties associated with the transaction to view it. A party associated with a transaction can store the current state object of the transaction in a vault (i.e., a database associated with the corresponding distributed ledger). Another party eligible to view or process the transaction (e.g., verify the transaction) can retrieve the current state object of the transaction from the vault. Furthermore, each state object of the corresponding distributed ledger can include a smart contract between the parties or nodes involved in the associated transaction.
[0041] On each of distributed ledgers 116 and 118, a participant or node (e.g., the first MP node 116A and / or the first MaaS node 118A) can update a transaction by updating the state characteristics of an input state object to produce an output state object. The updated transaction can thus create a chain of origins that can be associated with the transaction data. Each of distributed ledgers 116 and 118 can provide consensus for the updated transaction based on the determination of its validity and uniqueness. In an embodiment, participants of the node associated with the updated transaction can determine its validity by independently executing the smart contract and verification logic associated with the transaction. Additionally, the uniqueness of the updated transaction can be determined by checking that no other transaction has reached consensus using the same input state object as the current transaction.
[0042] According to an embodiment, each of distributed ledgers 116 and 118 can be associated with a distributed application, which may include a client-side interface (front-end) and a server-side interface (back-end). The distributed application can be configured to implement workflows (e.g., Corda streams) to record transactions (and thereby store associated transaction records) on nodes of the respective distributed ledgers (such as MP node 116A and / or MaaS node 118A). The client-side interface can be hosted on each of a first plurality of subscriber nodes 114A, 114B, ... 114N and can be configured to be loaded onto a client associated with the subscriber node. For example, the client-side interface of the distributed application can be a remote procedure call (RPC) client that can be configured on each subscriber node. The server-side interface of the distributed application can run on each node of distributed ledgers 116 and 118.
[0043] In this embodiment, each of the first MP node 116A and the first MaaS node 118A can be configured to receive transaction messages via the first subscriber node 114A. Each of the first MP node 116A and the first MaaS node 118A can update the initial state object associated with each of the distributed ledgers 116 and 118, respectively, based on the transaction message to output an updated state object. Each of the first MP node 116A and the first MaaS node 118A can construct a transaction that may include an initial state object with initial transaction data and an updated state object with updated transaction data.
[0044] Aggregator database node 122 may include suitable logic, circuitry, code, and / or interfaces, and may be configured to store a first set of transaction records of a first plurality of transaction records associated with all mobility providers of the first MaaS network 102. Storage of the first set of transaction records in aggregator database node 122 may be based on a first data retention threshold and a first storage duration of the first plurality of transaction records on the first MaaS node 118A. In an embodiment, aggregator database node 122 may be configured to store transaction records selected from the first set of transaction records based on aggregation logic. According to an embodiment, aggregator database node 122 may be a node of a distributed ledger (e.g., distributed ledger 118) associated with the first MaaS network 102, which may store the first set of transaction records associated with mobility providers of the first MaaS network 102. According to another embodiment, aggregator database node 122 may be a non-distributed ledger (or local) node.
[0045] Archive database node 124 may include suitable logic, circuitry, code, and / or interfaces, and may be configured to store a second set of transaction records associated with all mobility providers of the first MaaS network 102. Storage of the second set of transaction records in archive database node 124 may be based on a second data retention threshold and a second storage duration of a third set of stored transaction records on aggregator database node 122. The third set of transaction records may include at least a first set of transaction records that may be stored on aggregator database node 122. According to an embodiment, archive database node 124 may be a node of a distributed ledger (e.g., distributed ledger 118) associated with the first MaaS network 102, which may store the second set of transaction records associated with mobility providers of the first MaaS network 102. According to another embodiment, archive database node 124 may be a non-distributed ledger (or local) node without a query mechanism. Non-distributed ledger-based nodes may be more cost-effective and faster than distributed ledger-based nodes.
[0046] The cache database node 126 may include suitable logic, circuitry, code, and / or interfaces that can be configured to store frequently queried transaction records in a fast temporary storage or database. The cache database node 126 can reduce the workload of other database nodes, such as multiple MP nodes 116A, 116B, ... 116N, multiple MaaS nodes 118A, 118B, ... 118N, aggregator database node 122, and archive database node 124.
[0047] The first server 128 may include suitable logic, circuitry, and interfaces and / or code, which can be configured to query one or more first transaction records stored on aggregator database node 122 and verify one or more transactions associated with the queried one or more first transaction records. The first server 128 can also be configured to query one or more second transaction records stored on archive database node 124 and control the display of statistics associated with the queried one or more second transaction records. In some embodiments, if one or more second transaction records are cached on cache database node 126, the first server 128 can be configured to query one or more third transaction records from the one or more second transaction records stored on cache database node 126. The first server 128 can control the display of statistics associated with the queried one or more third transaction records in a similar manner.
[0048] According to an embodiment, the first server 128 may be configured to process API requests, such as API requests associated with transaction verification, analysis, or visualization. API requests may be processed based on one or more first transaction records stored on the aggregator database node 122 and / or one or more second transaction records stored on the archive database node 124 (or cache database node 126). According to an embodiment, the first server 128 may be pre-configured with API services that can be programmed 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 a cluster of cloud servers, which can perform operations through web applications, cloud applications, HTTP requests, repository operations, file transfers, etc. Other example implementations of the first server 128 may include, but are not limited to, database servers, file servers, web servers, media servers, application servers, mainframe servers, or cloud computing servers.
[0049] In at least one embodiment, the first server 128 can be implemented as multiple distributed cloud-based resources using several techniques well known to those skilled in the art. Those skilled in the art will understand that the scope of this disclosure is not limited to implementing the first server 128 and the proxy node device 112 as two separate entities. In some embodiments, the functionality of the first server 128 can be wholly or at least partially integrated into the proxy node device 112 without departing from the scope of this disclosure.
[0050] In operation, a first MaaS node 118A (such as a first subscriber node 114A, a first MP node 116A, and a first MaaS node 118A) from a first node packet 120 can be configured to select a first set of transaction records from a first plurality of transaction records stored on the first MaaS node 118A. Each of the first plurality of transaction records can be associated with a transaction message received by the first subscriber node 114A of the first node packet. The first set of transaction records can be selected based on a first data retention threshold and a first storage duration for each of the first plurality of transaction records on the first MaaS node 118A. For example, if the first data retention threshold is three days, then the first MaaS node 118A can select all transaction records from the first plurality of transaction records with a storage duration of three days or longer (i.e., the first storage duration) as the first set of transaction records. Furthermore, the first MaaS node 118A can transfer the selected first set of transaction records to the aggregator database node 122 for storage at the aggregator database node 122. For example, in Figure 4B The document provides details on selecting the first set of transaction records and transmitting the first set of selected transaction records.
[0051] The first MaaS node 118A can also control the selection of a second set of transaction records from a third set of transaction records stored on the aggregator database node 122. The first MaaS node 118A can control the selection of the second set of transaction records based on a second data retention threshold and a second storage duration for each of the first set of transaction records on the aggregator database node 122. The first MaaS node 118A can control the selection of the second set of transaction records by transmitting a command to the aggregator database node 122 to select the second set of transaction records based on the second data retention threshold and the second storage duration. For example, the second data retention threshold could be sixty days. In this case, the first MaaS node 118A can control the aggregator database node 122 to select all transaction records with a storage duration (i.e., the second storage duration) of sixty days or more from the third set of transaction records stored on the aggregator database node 122 as the second set of transaction records. In this document, 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 may also include other transaction records that are older or newer than the first set of transaction records. The first MaaS node 118A can also control the transfer of the second set of selected transaction records to the archive database node 124 for storage. For example, in Figure 4C The document provides details on the selection of a second set of transaction records and the transmission of that selected second set of transaction records. In some embodiments, each of the multiple node packets 120 can be connected to the client layer 104 via a proxy layer 106, through a plugin interface. Details of the plugin interface are provided, for example... Figure 2 Provided by China.
[0052] According to an embodiment, a first server 128 associated with each of the aggregator database node 122 and the archive database node 124 can be configured to transmit queries to the aggregator database node 122 for one or more first transaction records stored on the aggregator database node 122. In an exemplary scenario, one or more first transaction records may be frequently queried by the first server 128. One or more first transaction records may be queried, for example, to resolve disputes 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.
[0053] The first server 128 may also receive one or more first transaction records queried from the aggregator database node 122. The received or more first transaction records may relate to transaction messages associated with the same 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. Verification of 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 the total transaction amount and the amount of revenue allocated between the organization (i.e., the organization managing the first MaaS network 102) and one or more mobility providers that may have already provided the mobility services associated with the transaction. The first server 128 may verify the match between the total transaction amount and the total allocated revenue. Additionally, the first server 128 may verify that the revenue allocation is based on a predefined revenue allocation agreement between the organization of the first MaaS network 102 and the various mobility providers. In embodiments, revenue allocation may be based on a protocol associated with a distributed ledger technology such as smart contracts. Therefore, the first server 128 can verify whether the distribution of revenue complies with the smart contracts between the organization of the first MaaS network 102 and the various mobility providers.
[0054] According to an embodiment, the first server 128 may also be configured to transmit queries for one or more second transaction records stored on the archive database node 124 to the archive database node 124. The first server 128 may also receive the queried one or more second transaction records from the archive database node 124. The query for one or more second transaction records stored on the archive database node 124 may be used, for example, to enable dispute resolution, auditing, and compliance tasks associated with the first MaaS network 102.
[0055] The first server 128 may also display statistical information associated with one or more queried second transaction records. The statistical information associated with the one or more queried second transaction records may include, but is not limited to, the transaction identifier (ID) of each of the one or more queried second transaction records, the timestamp associated with each of the one or more queried second transaction records, or the routing path of each of the one or more queried second transaction records. The statistical information may also include, but is not limited to, the distribution of transaction records across each mobility provider, the allocation of transaction values across each mobility provider, the allocation of transaction records across days, weeks, months, or years; or the allocation of transaction records across users of the first MaaS network 102.
[0056] According to an embodiment, cache database node 126 can be configured to receive one or more second transaction records queried from archive database node 124. Cache database node 126 can store the received one or more second transaction records on its own. Cache database node 126 can also receive queries for one or more third transaction records from a first server 128. The one or more third transaction records can be included in the one or more second transaction records stored on cache database node 126. Cache database node 126 can transmit one or more third transaction records to the first server 128 based on the received queries for the one or more third transaction records. In some embodiments, the one or more third transaction records can be frequently queried transaction records from archive database node 124. Therefore, the first server 128 can easily access the one or more third transaction records for purposes such as dispute resolution, auditing, and compliance tasks associated with the first MaaS network 102.
[0057] In an embodiment, to scale up the first MaaS network 102, one or more new node packages can be added to multiple node packages 120. Each of the one or more new node packages may include a set of subscriber nodes and pre-configured nodes for mobility providers (e.g., local MP nodes) and MaaS providers (e.g., local MaaS nodes). To enhance transaction performance and throughput, the set of subscriber nodes and pre-configured nodes in the one or more new node packages may be deployed as, but not limited to, edge nodes, edge devices, or devices with fog or cloud computing capabilities. MaaS provider nodes (e.g., local MaaS nodes) may connect to aggregator database nodes 122 (e.g., central nodes) for data consolidation. Additionally, subscriber nodes in the new node packages can connect to the proxy layer 106 (including proxy node devices 112) via a plug-in interface 200, for example in… Figure 2Further description is provided below. In an embodiment, the aggregator database node 122 may be node 118 of a distributed ledger associated with a MaaS provider. Once a MaaS provider node (e.g., a local MaaS node) can connect to the aggregator database node 122, 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 on the MaaS provider node (e.g., a local MaaS node) and transfer the selected first set of transaction records to the aggregator database node 122 for storage. The selection of the first set of transaction records may be based on the storage duration of each of the plurality of transaction records on the MaaS provider node (e.g., a local MaaS node) and a data retention threshold associated with the MaaS provider node (e.g., a local MaaS node). Additionally, the aggregator database node 122 may be configured to select a second set of transaction records from a third set of transaction records stored on the aggregator database node 122 and transfer the selected second set of transaction records to the archive database node 124 for storage. The selection and transmission of the second set of transaction records can be based on instructions received by the aggregator database node 122 from the MaaS provider node (e.g., a local MaaS node). The selection of the second set of transaction records can be based on a second storage duration of the third set of transaction records on the aggregator database node 122 and a second data retention threshold of the aggregator database node 122. In embodiments, the third set of transaction records may include at least the first set of transaction records. For example, in... Figure 3 and Figures 4A-4C The document further explains the archiving of transaction records.
[0058] In this embodiment, each of the multiple node packages 120 can be implemented as one of a set of edge nodes, a set of edge devices, or a set of devices with fog or cloud computing capabilities. The nodes in each node package (e.g., subscriber nodes, MP nodes, and MaaS nodes) can be deployed as multiple publisher nodes 110A-110N (i.e., client layer 104) physically close to the first MaaS network 102. Physical proximity can reduce transaction latency and can limit the capacity of the client layer 104 based on the performance limitations of the multiple node packages 120, which further leads to a reduction in transaction failures. Additionally, 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, where a pre-configured set of MP nodes and MaaS nodes can be coupled to subscriber nodes. The subscriber nodes of the new node package can connect to the proxy node device 112 of the first MaaS network 102 via a plug-in interface. Additionally, the MaaS nodes of the new node package can connect to the aggregator database node 122. The MaaS node can then begin archiving transaction records to the aggregator database node 122, and then to the archive database node 124, as previously described. Furthermore, the aggregator database node 122 can utilize transaction records merged from multiple MaaS nodes 118A, 118B, ... 118N for revenue sharing between the MaaS provider and one or more mobility providers, and for other purposes such as... Figure 5 The data analysis described in the document.
[0059] Figure 2 This is an exemplary block diagram of a plug-in interface for a node packet of a MaaS network according to an embodiment of the present disclosure. Figure 2 Combination Figure 1 The elements in the text will be explained. (See reference.) Figure 2 The diagram illustrates block diagram 200. Block diagram 200 may include a first node package 120A among a plurality of node packages 120. The first node package 120A may include a first subscriber node 114A, a first MP node 116A, and a first MaaS node 118A.
[0060] The plug-in interface associated with the first subscriber node 114A may include a message queue (MQ) application server 202. The MQ application server 202 may include a message receiver 204, a message buffer 206, a transaction invoker 208, a concurrency / thread management plug-in 210, a monitor plug-in 212, a security plug-in 214, and a network protocol handler plug-in 216. In this embodiment, the message receiver 204, message buffer 206, concurrency / thread management plug-in 210, monitor plug-in 212, security plug-in 214, and network protocol handler plug-in 216 may be pre-configured plug-ins with basic functionality. The transaction invoker 208 may be a user-configurable plug-in that can be used to process transaction messages.
[0061] MQ application server 202 can be configured to enable inter-process communication between client layer 104 (via broker layer 106) and first subscriber node 114A of server layer 108. MQ application server 202 can utilize queues (such as message queues) to transmit and receive transaction messages. The message queue can be implemented as an asynchronous queue (based on an asynchronous messaging protocol such as MQTT or AMQP) to receive incoming transaction messages from one or more publisher nodes of client layer 104 and forward the received incoming transaction messages to subscriber nodes that can implement message queues (e.g., first subscriber node 114A). Therefore, transaction messages can be asynchronously delivered to first subscriber node 114A without real-time communication between the sending publisher node and the receiving subscriber node (such as first subscriber node 114A). The message queue can store received incoming transaction messages for first subscriber node 114A until first subscriber node 114A is available to receive and process such incoming transaction messages.
[0062] MQ application server 202 can include message-to-transaction pipelines (such as...) Figure 2As shown in the diagram, this pipeline can process received incoming transaction messages and convert them into transaction records for storage on the first MP node 116A and the first MaaS node 118A. The message-to-transaction pipeline can begin when the MQ application server 202 receives a transaction message. The message-to-transaction pipeline can perform various operations, such as verification checks (e.g., using monitor plugin 212), security checks (e.g., using security plugin 214), requests for parameter creation (using monitor plugin 212 and / or network protocol handler plugin 216), logging (using monitor plugin 212), transaction invocation (using transaction invoker 208), transaction result processing (using monitor plugin 212), and actions after transaction creation (e.g., transmitting the created transaction record to the first MP node 116A and the first MaaS node 118A). In an embodiment, the message-to-transaction pipeline can use a concurrency / thread management plugin 210 to run concurrently and manage simultaneously incoming transaction messages. Additionally, transaction messages can be buffered in the message-to-transaction pipeline via message buffer 206.
[0063] In this embodiment, to convert an incoming transaction message into a transaction, the MQ application server 202 can verify the header and format of the transaction message. The MQ application server 202 can be configured to create transaction message parameters by adding metadata (such as, but not limited to, subscriber node identifiers and timestamps). Once the transaction message parameters can be created, the MQ application server 202 can execute the transaction call.
[0064] Message receiver 204 can be configured to receive incoming transaction messages from one or more publisher nodes (such as the first publisher node 110A) among a plurality of publisher nodes 110. In an embodiment, message receiver 204 can implement an asynchronous message queue of MQ application server 202.
[0065] Message buffer 206 can be configured to store received incoming transaction messages in a buffer (or temporary) memory of the first subscriber node 114A before each received incoming transaction message can be processed by the first subscriber node 114A. Received incoming transaction messages can be stored in buffer memory 206 to match the rate at which incoming transaction messages are received with the rate at which the first subscriber node 114A can process transaction messages. In some embodiments, the rate at which the first subscriber node 114A can process transaction messages may depend on the size of subsequent MP nodes (e.g., the first MP node 116A).
[0066] Transaction invoker 208 can be a customizable application (e.g., a middleware application, such as a Java applet application) curated by administrator 132 or developers associated with the first MaaS network 102. Transaction invoker 208 can be used to extend the capabilities of MQ application server 202. For example, transaction invoker 208 can be programmed to process received incoming transaction messages and execute transaction invocations on remote procedure calls (such as smart contracts) on the first and second distributed ledgers, so that associated transaction records are subsequently created in the first MP node 116A and the first MaaS node 118A.
[0067] The concurrency / thread management plugin 210 can be configured to run multiple threads (e.g., parts of a process) of tasks associated with the first subscriber node 114A concurrently. The concurrency / thread management plugin 210 can improve the performance of the first subscriber node 114A by executing multiple tasks in parallel. Examples of such tasks may include, but are not limited to, receiving transaction messages at message receiver 204, storing the received transaction messages in message buffer 206, and having transaction calls associated with the received transaction executed by transaction invoker 208 to process the received transaction messages.
[0068] Monitor plugin 212 can be configured to monitor the conversion of incoming transaction messages into transaction records associated with the MQ application server 202 and then into the transaction pipeline. Furthermore, monitor plugin 212 can be configured to handle errors that may occur during the conversion of incoming transaction messages. For example, monitor plugin 212 can verify the header and format associated with the received transaction message and determine the validity of the received transaction message based on the verification of the header and format. Moreover, monitor plugin 212 can record transaction identifiers, such as the association ID associated with the transaction message, enabling the tracking of transaction messages. Therefore, monitor plugin 212 can handle transaction errors. Upon detecting an error based on verification, monitor plugin 212 can transmit an alert to the first subscriber node 114A. Monitor plugin 212 can thus function as a monitor and alert plugin, and / or as a transaction error handling plugin.
[0069] Monitor plugin 212 can also be configured to monitor resources and throughput associated with MQ application server 202. For example, monitor plugin 212 can monitor processor utilization associated with concurrency / thread management plugin 210. Additionally, monitor plugin 212 can monitor memory utilization of message buffer 206. Furthermore, monitor plugin 212 can monitor network utilization or available network bandwidth associated with message receiver 204. Monitor plugin 212 can also thus act as a transaction management plugin.
[0070] Security plugin 214 can be configured to enable MQ application server 202 to securely receive transaction messages. In an embodiment, security plugin 214 can enable the identification of incoming transaction messages based on the content of the header of each incoming transaction message. For example, the header may include an identifier of the creator / sender of the incoming transaction message (such as the identifier of the publisher node). When the creator or sender of the transaction message is identified as a whitelisted or authorized publisher node, security plugin 214 can allow MQ application server 202 to receive the incoming transaction message. Security plugin 214 can thus manage permissions associated with the receipt of transaction messages and filter transaction messages based on the identifier of the creator or sender of the transaction message.
[0071] Network protocol handler plugin 216 can be configured to enable the first subscriber node 114A to communicate with other nodes of the first MaaS network 102 (e.g., proxy node device 112 and one or more publisher nodes) based on a predefined network protocol. The network protocol may include a set of rules that govern the communication of transaction messages between multiple nodes of the first MaaS network 102 (such as multiple publisher nodes 110, proxy node device 112, and multiple subscriber nodes 114A, 114B, ... 114N). Examples of network protocols may include, but are not limited to, Hypertext Transfer Protocol (HTTP), MQTT, or AMQP. Network protocol handler plugin 216 can also be configured to perform data scheme and data quality checks on received transaction messages. For example, network protocol handler plugin 216 can verify a uniform predefined data request or response format (e.g., JSON, CSV, or XML format) and a shared API / data scheme that the first subscriber node 114A can adhere to when communicating with other nodes of the first MaaS network 102. Network protocol handler plugin 216 can thus function as a network protocol plugin as well as a data scheme and data quality check plugin.
[0072] Figure 3 This is an exemplary sequence diagram depicting support for large-scale transactions and node archiving on a MaaS platform based on a shared database architecture, according to embodiments of the present disclosure. Figure 3 Combining Figure 1 and 2 The elements in the text will be explained. (See reference.) Figure 3 This shows sequence diagram 300, illustrating the sequence of operations from 302 to 316. This sequence of operations can be derived from... Figure 1 The execution is performed by the individual nodes of the first MaaS network 102 (such as the first MaaS node 118A, the aggregator database node 122, and the archive database node 124).
[0073] At point 302, a first set of transaction records can be selected from a first plurality of transaction records stored on a first MaaS node (e.g., first MaaS node 118A). According to an embodiment, the first MaaS node 118A can be configured to select the first set of transaction records from the first plurality of transaction records. The first set of transaction records can be selected based on a first data retention threshold and a first storage duration for each of the first plurality of transaction records on the first MaaS node 118A.
[0074] According to an embodiment, a first MaaS node 118A can be configured to compare a first storage duration of each of a first plurality of transaction records on the first MaaS node 118A with a first data retention threshold. The first MaaS node 118A can also select a first set of transaction records from the first plurality of transaction records based on this comparison. For example, the first data retention threshold for storing the first plurality of transaction records on the first MaaS node 118A can be three days. The first MaaS node 118A can compare the first storage duration of each of the first plurality of transaction records with the first data retention threshold (i.e., three days). The first storage duration can indicate from how many hours, days, weeks, or months a particular transaction record began to be stored on the first MaaS node 118A. Based on this comparison, the first MaaS node 118A can select from the first plurality of transaction records those transaction records whose first storage duration on the first MaaS node 118A exceeds three days, as the first set of transaction records. For example, in Figure 4A The text explains an example of how multiple transaction records can be stored on the first MaaS node 118A. For example, in... Figure 4B The example explains how to select the first set of transaction records from the first plurality of transaction records stored on the first MaaS node 118A.
[0075] At point 304, the first set of selected transaction records can be transferred to aggregator database node 122. According to an embodiment, the first MaaS node 118A can be configured to transfer the first set of selected transaction records to aggregator database node 122. The first set of selected transaction records can be transferred to aggregator database node 122 once the first storage duration of the first set of selected transaction records exceeds a first data retention threshold on the first MaaS node 118A (or thereafter).
[0076] At point 306, the first set of selected transaction records can be invalidated in the first MaaS node 118A based on the transmission of the first set of selected transaction records to the aggregator database node 122. According to an embodiment, the first MaaS node 118A can be configured to invalidate (or deactivate, i.e., soft delete) the first set of selected transaction records in the first MaaS node 118A based on the transmission of the first set of selected transaction records to the aggregator database node 122. In some scenarios, the first MaaS node 118A can receive confirmation from the aggregator database node 122 that the first set of transaction records has been received at the aggregator database node 122. In some embodiments, the first MaaS node 118A can invalidate the first set of selected transaction records in the first MaaS node 118A based on receiving such confirmation from the aggregator database node 122. Since the amount of valid data on the first MaaS node 118A can be reduced, invalidating the first set of selected transaction records can enhance the performance of the first MaaS network 102. In another embodiment, when the first MaaS network 102 can be implemented as an offline (non-distributed ledger) database system, the first MaaS node 118A can be configured to delete a first set of selected transaction records from the first MaaS node 118A. For example, the invalidation (or deactivation) of older transaction records from the first MaaS node 118A (e.g., a first set of transaction records whose first storage duration exceeds a first data retention threshold) can free up storage space on the first MaaS node 118A for updated transaction records. This allows the first MaaS node 118A to be implemented as a storage device with smaller but faster memory, which can enhance the performance of the first MaaS node 118A and increase the transaction throughput of the first MaaS network 102.
[0077] Furthermore, the invalidation of the first set of selected transaction records can allow for a reduction in the number of nodes across multiple MaaS nodes 118A, 118B, ... 118N. The reduction in the number of nodes or the refresh of nodes can be based on a retention policy for transaction messages. The retention policy can be configurable and can be based on transaction messages pushed to the aggregator database node 122. Additionally, the retention policy can be based on compliance with storing data (such as transaction messages) at different nodes across multiple MaaS nodes 118A, 118B, ... 118N for a specific period. For example, based on a General Data Protection Regulation (GDPR) compliance policy, the retention policy can specify a storage period of up to 6 months for transaction messages. Furthermore, the retention policy can be consistent with configurable time periods, business logic, or requirements from the MaaS platform. By reducing or refreshing the number of nodes across multiple MaaS nodes 118A, 118B, ... 118N, the retention policy can be maintained to manage the performance of the MaaS platform periodically (e.g., daily). In some embodiments, compliance policies such as GDPR compliance policies can also be used for anonymizing data (such as personal information corresponding to users).
[0078] At point 308, a first set of transaction records can be stored on aggregator database node 122. According to an embodiment, a first MaaS node 118A can be configured to control aggregator database node 122 to store the first set of transaction records on aggregator database node 122. For example, the first MaaS node 118A can transmit an instruction to aggregator database node 122 to store the first set of transaction records on aggregator database node 122. The storage of the first set of transaction records on aggregator database node 122 enables the first server 128 to query aggregator database node 122 for one or more first transaction records from the first set of transaction records.
[0079] At point 310, a second set of transaction records can be selected from the third set of transaction records stored on aggregator database node 122. According to an embodiment, the first MaaS node 118A can be configured to control the selection of the second set of transaction records from the third set of transaction records stored on aggregator database node 122. For example, the first MaaS node 118A can transmit an instruction (as control) to aggregator database node 122 to select the second set of transaction records from the third set of transaction records. The second set of transaction records can be selected based on a second data retention threshold and a second storage duration for each of the third set of transaction records on aggregator database node 122. In an embodiment, the third set of transaction records may include a first set of transaction records received by aggregator database node 122 from the first MaaS node 118A and stored on aggregator database node 122. For example, the third set of transaction records may include the first set of transaction records and other transaction records (i.e., older transaction records) that may be stored on aggregator database node 122.
[0080] According to an embodiment, the first MaaS node 118A can be configured to control the comparison of a second storage duration for each of the third set of transaction records on the aggregator database node 122 with a second data retention threshold. The first MaaS node 118A can also be configured to control the selection of a second set of transaction records from the third set of transaction records based on this comparison. For example, the first MaaS node 118A can transmit instructions to the aggregator database node 122 to compare the second storage duration for each of the third set of transaction records with the second data retention threshold and select a second set of transaction records based on the comparison. According to an embodiment, the second data retention threshold can be greater than a first data retention threshold. In an alternative embodiment, the second data retention threshold can be lower than the first data retention threshold. For example, the second data retention threshold can be sixty days (i.e., more than the first data retention threshold, such as three days). The first MaaS node 118A can control the comparison of the second storage duration for each of the third set of transaction records with the second data retention threshold (i.e., sixty days). Based on this comparison, the first MaaS node 118A can control the selection of those transaction records with a second storage duration exceeding sixty days from the third set of transaction records on the aggregator database node 122 (as the second set of transaction records). For example, in Figure 4C The example explains how to select the second set of transaction records from the third set of transaction records stored on aggregator database node 122.
[0081] At point 312, the second set of selected transaction records can be transferred to archive database node 124. According to an embodiment, the first MaaS node 118A can be configured to control the transfer of the second set of selected transaction records from aggregator database node 122 to archive database node 124. For example, the first MaaS node 118A can transmit an instruction to aggregator database node 122 to transfer the second set of selected transaction records to archive database node 124. Once the second storage duration of the second set of selected transaction records exceeds (or thereafter) the second data retention threshold on aggregator database node 122, aggregator database node 122 can transfer the second set of selected transaction records to archive database node 124.
[0082] At point 314, the second set of selected transaction records can be invalidated (or deactivated) in the aggregator database node 122 based on the transmission of the second set of selected transaction records to the archive database node 124. According to an embodiment, the first MaaS node 118A can be configured to control the invalidation (or deactivation) of the second set of selected transaction records in the aggregator database node 122 based on the transmission of the second set of selected transaction records to the archive database node 124. For example, the first MaaS node 118A can transmit an instruction to the aggregator database node 122 to invalidate the second set of selected transaction records in the aggregator database node 122 based on the transmission of the second set of selected transaction records from the aggregator database node 122 to the archive database node 124. In another embodiment, the first MaaS node 118A can be configured to control the deletion of the second set of selected transaction records in the aggregator database node 122 when the aggregator database node 122 is implemented as an offline (non-distributed ledger) database system. In this scenario, deleting or invalidating (or deactivating) older transaction records (e.g., a second set of transaction records whose second storage duration exceeds a second data retention threshold) from aggregator database node 122 can free up storage space on aggregator database node 122 for newer transaction records. This allows aggregator database node 122 to be implemented as a storage device with smaller but faster memory, which can enhance the performance of aggregator database node 122 and improve query response time associated with queries about transaction records that can be received from the first server 128.
[0083] At point 316, a second set of transaction records can be stored on archive database node 124. According to an embodiment, a first MaaS node 118A can be configured to control archive database node 124 to store the second set of transaction records on archive database node 124. For example, the first MaaS node 118A can transmit an instruction to archive database node 124 to store the second set of transaction records on archive database node 124. The storage of the second set of transaction records on archive database node 124 enables the first server 128 to query archive database node 124 for one or more second transaction records from the second set of transaction records.
[0084] In an embodiment, the first MaaS node 118A can be configured to control the archive database node 124 to store a second set of transaction records on the archive database node 124 based on tamper-proof data storage technology. For example, the first MaaS node 118A can transmit an instruction to the archive database node 124 to store the second set of transaction records based on tamper-proof data storage technology. In this example, the tamper-proof data storage technology can be a data hashing technique (e.g., for text data), which allows the calculation of a hash value for each transaction record. The hash value can be used to determine the forgery of a transaction record during retrieval. In an embodiment, in the case of an offline database system, the hash value of each transaction record can be stored in the first MaaS node 118A and can be retrieved to determine the forgery of the transaction record.
[0085] Figure 4A , 4B Together with 4C, this describes an exemplary scenario for supporting large-scale transactions and node archiving on a MaaS platform based on a shared database architecture, according to embodiments of this disclosure. Figure 4A , 4B Combined with 4C Figure 1 , 2 Let's explain the elements with 3. Figure 4A , 4B An exemplary scenario for 4C may include a first MaaS node 118A, an aggregator database node 122, and an archive database node 124. Figure 4A , 4B Each of the exemplary scenarios in 4C depicts a snapshot of transaction records stored at a specific time on the first MaaS node 118A, aggregator database node 122, and archive database node 124. (See reference...) Figure 4AThe first exemplary scenario 400A is illustrated. First exemplary scenario 400A depicts the storage of a first plurality of transaction records on a first MaaS node 118A and the storage of one or more transaction records on an aggregator database node 122. The first plurality of transaction records stored on the first MaaS node 118A may include transaction records such as “TR01”, “TR02”, “TR03”, ... “TR11” (e.g., ...). Figure 4A (As shown in the diagram). Additionally, one or more transaction records stored on aggregator database node 122 may include transaction records such as “TR12” and “TR13” (e.g., as shown in the diagram). Figure 4A (as shown in the image).
[0086] In an embodiment, the first MaaS node 118A can receive a first plurality of transaction records “TR01”, “TR02”, “TR03”, ... “TR11” from the first MP node 116A based on the associated transaction messages received by the first subscriber node 114A. Figure 4A The document further describes the first storage duration of each of the first plurality of transaction records “TR01”, “TR02”, “TR03”, ... “TR11” on the first MaaS node 118A. For example, transaction record “TR01” may be stored on the first MaaS node 118A for a storage duration of 10 hours (i.e., the first storage duration). Transaction record “TR02” may be stored on the first MaaS node 118A for a storage duration of 15 hours (i.e., the first storage duration). Similarly, transaction record “TR09” may be stored on the first MaaS node 118A for a storage duration of 3 days and 2 hours (i.e., the first storage duration). Transaction record “TR10” may be stored on the first MaaS node 118A for a storage duration of 3 days and 10 hours (i.e., the first storage duration). Moreover, transaction record “TR11” may be stored on the first MaaS node 118A for a storage duration of 3 days and 18 hours (i.e., the first storage duration). Furthermore, the first exemplary scenario 400A illustrates the storage duration of one or more transaction records stored on the aggregator database node 122. For example, transaction record "TR12" can be stored for a storage duration of 4 hours on aggregator database node 122, while transaction record "TR13" can be stored for a storage duration of 7 hours.
[0087] refer to Figure 4BA second exemplary scenario 400B is illustrated. The second exemplary scenario 400B depicts a first set of transaction records being transferred from a first MaaS node 118A to an aggregator database node 122, and the first set of transaction records being stored on the aggregator database node 122. In the second exemplary scenario 400B, the first data retention threshold may be, for example, three days. The first MaaS node 118A may be configured to select transaction records (from a first plurality of transaction records) whose storage duration (i.e., the first storage duration) is greater than the first data retention threshold (e.g., three days in the current case) as the first set of transaction records. The first MaaS node 118A may, for example, transfer the first set of transaction records to the aggregator database node 122 at a specific time each day.
[0088] In an exemplary embodiment, the first set of transaction records may include transaction records "TR09", "TR10", and "TR11". Transaction record "TR09" may store a first storage duration of "3 days and 2 hours" at the first MaaS node 118A. Transaction record "TR10" may store a first storage duration of "3 days and 10 hours" at the first MaaS node 118A. Figure 4B As shown, transaction record "TR11" can be stored at the first MaaS node 118A for a first storage duration of "3 days and 18 hours". Therefore, as the first storage duration of each transaction record in the first set of transaction records exceeds the first data retention threshold (i.e., three days), the first MaaS node 118A can select the first set of transaction records (i.e., "TR09", "TR10", and "TR11") and transfer the selected first set of transaction records to the aggregator database node 122 for storage at the aggregator database node 122.
[0089] According to an embodiment, the first MaaS node 118A can also be configured to invalidate the first set of selected transaction records (i.e., transaction records "TR09", "TR10", and "TR11" from the first MaaS node 118A) after transmitting the first set of selected transaction records to the aggregator database node 122. The aggregator database node 122 can receive the first set of transaction records from the first MaaS node 118A and (under the control of the first MaaS node 118A, based on instructions received from the first MaaS node 118A) store the first set of transaction records on the aggregator database node 122. When storing the first set of transaction records on the aggregator database node 122, the storage duration of the first set of transaction records on the aggregator database node 122 can be reset to "0" hours, as... Figure 4BAs shown in the diagram. Therefore, based on the transmission and invalidation of the first set of selected transaction records, the aggregator database node 122 can store transaction records “TR09”, “TR10”, “TR11”, “TR12”, and “TR13”, and the first MaaS node 118A can now store transaction records “TR01”, “TR02”, “TR03”, “TR04”, “TR05”, “TR06”, “TR07”, and “TR08” as the remaining transaction records on the first MaaS node 118A. Additionally, the transaction records “TR09”, “TR10”, “TR11”, “TR12”, and “TR13” on the aggregator database node 122 can correspond to a third set of transaction records that may include the first set of received transaction records (i.e., “TR09”, “TR10”, and “TR11”) and the older transaction records stored on the aggregator database node 122 (i.e., “TR12” and “TR13”), as shown in the diagram. Figure 4B As shown in the image.
[0090] refer to Figure 4C A third exemplary scenario 400C is illustrated. The third exemplary scenario 400C depicts a second set of transaction records being transferred from the aggregator database node 122 to the archive database node 124, and the second set of transaction records being stored on the archive database node 124. In the third exemplary scenario 400C, the second data retention threshold may be, for example, sixty days. The first MaaS node 118A may be configured to control the aggregator database node 122 to select transaction records (as the second set of transaction records) from the third set of transaction records whose storage duration (i.e., the second storage duration) is greater than the second data retention threshold (e.g., sixty days in the current case). For example, the first MaaS node 118A may transmit instructions to the aggregator database node 122 to select the second set of transaction records and to transfer the selected second set of transaction records to the archive database node 124.
[0091] Aggregator database node 122 may, for example, transmit a second set of transaction records to archive database node 124 at a specific time each day or week. Therefore, at that specific time, the second set of transaction records can be transmitted to archive database node 124. In an exemplary embodiment, a third set of transaction records may include transaction records “TR01”, “TR02”, “TR03”, “TR04”, “TR05”, “TR06”, “TR07”, “TR08”, “TR09”, “TR10”, “TR11”, “TR12”, and “TR13”. Therefore, the third set of transaction records may include the first set of transaction records (i.e., transaction records “TR09”, “TR10”, and “TR11”). Additionally, the third set of transaction records may include older transaction records compared to the first set of transaction records (e.g., “TR12” and “TR13”) and newer transaction records (e.g., “TR01”, “TR02”, “TR03”, “TR04”, “TR05”, “TR06”, “TR07”, and “TR08”). The second set of transaction records, which can be selected from the third set of transaction records, may include, for example, transaction records “TR09”, “TR10”, “TR11”, “TR12”, and “TR13”. Figure 4C As shown, transaction records “TR09”, “TR10”, “TR11”, “TR12”, and “TR13” can be stored at aggregator database node 122 for a second storage duration of “60 days 2 hours”, “60 days 2 hours”, “60 days 2 hours”, “60 days 6 hours”, and “60 days 9 hours”, respectively. Therefore, when the second storage duration of the second set of transaction records exceeds the second data retention threshold (i.e., sixty days in the current case), the second set of transaction records can be selected as the second set of transaction records and transferred to archive database node 124 for storage at archive database node 124.
[0092] According to an embodiment, the first MaaS node 118A can also be configured to control the invalidation of the second set of selected transaction records (i.e., transaction records “TR09”, “TR10”, “TR11”, “TR12”, and “TR13”) from the aggregator database node 122 after the second set of selected transaction records has been transmitted to the archive database node 124. In the example, the first MaaS node 118A can transmit an instruction to the aggregator database node 122 to invalidate the second set of selected transaction records in the aggregator database node 122. The archive database node 124 can receive the second set of transaction records from the aggregator database node 122 and further store the second set of transaction records on the archive database node 124 (i.e., under the control of the first MaaS node 118A based on the instruction received from the first MaaS node 118A). When storing the second set of transaction records on the archive database node 124, the storage duration of the second set of transaction records on the archive database node 124 can be reset to 0 hours. Therefore, based on the transmission and invalidation of the second set of selected transaction records, archive database node 124 can store transaction records "TR09", "TR10", "TR11", "TR12", and "TR13", and aggregator MaaS node 122 can store transaction records "TR01", "TR02", "TR03", "TR04", "TR05", "TR06", "TR07", and "TR08" as the remaining transaction records on aggregator MaaS node 122, such as... Figure 4C As shown in the image.
[0093] It is worth noting that, Figures 4A-4C The first and second data retention thresholds shown in days (such as three days and sixty days respectively) are merely examples. The first data retention threshold applicable to the first MaaS node 118A and the second data retention threshold applicable to the aggregator database node 122 may be some seconds, minutes, hours, weeks, months, or years without departing from the scope of this disclosure. In embodiments, the first MaaS network 102 or the proxy node device 112 may set or change the first and second data retention thresholds based on the determination of the transaction message flow at the first MaaS network 102 or the proxy node device 112. In some embodiments, the first subscriber node 114A or other subscriber nodes of the first MaaS network 102 may set or change the first and second data retention thresholds based on the receipt of transaction messages at the corresponding subscriber node (such as the first subscriber node 114A).
[0094] It is also worth noting that, Figures 4A-4CThe first MaaS node 118A, which selects transaction records and transmits them to aggregator database node 122 and archive database node 124, is presented as an example only. In some embodiments, transaction records may be selected and transmitted from MP nodes (such as the first MP node 116A) to aggregator database node 122 and archive database node 124 without departing from the scope of this disclosure.
[0095] Figure 5 This describes an exemplary scenario depicting the aggregation of transaction records based on aggregation logic according to embodiments of this disclosure. Combined with... Figure 1 , 2 Explain using elements 3, 4A, 4B, and 4C. Figure 5 . refer to Figure 5 An exemplary scenario 500 is illustrated. Exemplary scenario 500 depicts the aggregation of transaction records based on aggregation logic according to embodiments of this disclosure.
[0096] Figure 5 An exemplary scenario 500 may include multiple MP nodes 116A, 116B, ... 116N, multiple MaaS nodes 118A, 118B, ... 118N, an aggregator database node 122, and an archive database node 124. Figure 5 Exemplary scenario 500 depicts a snapshot of transaction records stored at a certain time in multiple node packages 120 (e.g., a first node package, a second node package, and a third node package), an aggregator database node 122, and an archive database node 124. The first node package may include, for example, a first subscriber node 114A, a first MP node 116A, and a first MaaS node 118A, for example in... Figure 1 As described in [the document]. The second node packet may include a second subscriber node 114B, a first MP node 116A, and a second MaaS node 118B. The third node packet may include a third subscriber node 114C, a first MP node 116A, a second MP node 116B, and a third MaaS node 118C. It can be noted that multiple node packets 120 ( Figure 1 One or more of the nodes shown may include subscriber nodes, multiple MP nodes of the first distributed ledger, and MaaS nodes of the second distributed ledger, such as, for example Figure 5 As shown in the image.
[0097] Transaction records "TR01", "TR02", and "TR03" can be part of the first node packet. For example, transactions "TR01", "TR02", and "TR03" can be at the first MP node 116A. Furthermore, transaction records "TR04" and "TR05" can be part of the second node packet. For example, transactions "TR04" and "TR05" can be at the first MP node 116A, such as... Figure 5 As shown in the diagram. Additionally, for example, transaction records "TR05", "TR06", and "TR07" can be part of a third node packet. For instance, transaction record "TR05" can be located at the first MP node 116A, while transaction records "TR06" and "TR07" can be located at the second MP node 116B, as shown. Figure 5 As shown in the image.
[0098] At a certain time, when transaction records “TR01”...“TR07” are stored at multiple MP nodes, ownership of the transaction records can belong to multiple mobility providers (such as multiple MP nodes) and multiple MaaS nodes 118A, 118B,...118N. In other words, both MP and MaaS nodes can view the transaction records. The first MaaS node 118A of the first node packet can receive transaction records “TR01”, “TR02”, and “TR03” from the first MP node 116A, such as... Figure 5 As shown in the diagram, the second MaaS node 118B of the second node packet can receive transaction records "TR04" and "TR05" from the first MP node 116A. The third MaaS node 118C can receive transaction record "TR05" from the first MP node 116A and transaction records "TR06" and "TR07" from the second MP node 116B, as shown in the diagram. Figure 5 As shown in the diagram. Therefore, copies of all transaction records can be transferred from multiple MP nodes to multiple MaaS nodes 118A, 118B, ... 118N, as... Figure 5 As shown in the diagram. At the current stage, ownership of transaction records “TR01”...“TR07” can exist across multiple MaaS nodes 118A, 118B,...118N. Furthermore, multiple MaaS nodes 118A, 118B,...118N can aggregate transaction records from multiple node packages 120. Transaction records can be aggregated based on node packages within the multiple node packages 120.
[0099] In this embodiment, the aggregated transaction records may also be received by the aggregator database node 122. This can be based on a retention threshold and / or storage duration (i.e., for example, Figures 4A-4C(As described) and further aggregate transaction records based on each of the multiple MP nodes. Aggregator database node 122 can store aggregated transaction records for different MP nodes associated with each node packet. For example, as Figure 5 As shown, aggregator database node 122 can store aggregated transaction records for the first MP node 116A (i.e., associated with the first mobility provider) for the first node package as "MP1 with a storage duration of 15 hours," and it can aggregate multiple records stored in the first Maas node 118A (i.e., TR01-10 hours, TR02-2 hours, and TR03-3 hours). Similarly, for example, aggregator database node 122 can also store aggregated transaction records for the first MP node 116A for the second node package as "MP1 with a storage duration of 14 hours," and it can aggregate multiple records stored in the first Maas node 118A (i.e., TR04-4 hours and TR05-10 hours). Similarly, for example, aggregator database node 122 can also store aggregated transaction records for the first MP node 116A for the third node package as "MP1 with a storage duration of 12 hours." The aggregator database node 122 can also store aggregated transaction records for the second MP node 116B (i.e., associated with the second mobility provider) used for the third node package as "MP2 with a 3-hour storage duration," which can aggregate multiple records stored in the first Maas node 118A (i.e., TR06-1 hour and TR07-2 hours). In addition to retention thresholds and / or storage durations, transaction record aggregation can also be based on other parameters, such as the data support of subscribed users. In some embodiments, only selected transaction records can be aggregated and archived based on business logic (e.g., selection for a specific day or week or selection based on settlement completion).
[0100] In the embodiment, in addition to storing aggregated transaction records (such as "MP1 with a storage duration of 15 hours", "MP1 with a storage duration of 14 hours", "MP1 with a storage duration of 12 hours", and "MP2 with a storage duration of 3 hours"), such as... Figure 5As shown in the diagram, aggregator database node 122 can also store exact copies of all or selected transaction records stored at the corresponding MaaS node among multiple MaaS nodes 118A, 118B, ... 118N for each MP node within each node package of multiple node packages 120. In other words, for example, since the first MaaS node 118A stores transaction records “TR01”, “TR02”, and “TR03” (i.e., received from the first MP node 116A), similarly, in addition to storing aggregated transaction records (such as “MP1 with a storage duration of 15 hours”), aggregator database node 122 can also store exact versions of transaction records “TR01”, “TR02”, and “TR03” (i.e., received from the first MaaS node 118A). It is noteworthy that the storage of exact copies of transaction records (i.e., received from the corresponding MaaS nodes) in aggregator database node 122... Figure 5 It is not explicitly shown in the text, but in, for example Figure 4B-4C As described and illustrated in the diagram. Similarly, in addition to storing aggregated transaction records, the aggregator database node 122 can also store all (or selected) transaction records (i.e., in the same form) stored at different MP nodes and MaaS nodes for each of the multiple node packages 120.
[0101] In this embodiment, when transaction records are stored at the aggregator database node 122, ownership of the transaction records can belong to multiple MaaS nodes 118A, 118B, ... 118N. Multiple MaaS nodes 118A, 118B, ... 118N can share the aggregated transaction records with multiple mobile participants. Revenue sharing among mobility providers can be based on the aggregated transaction records. Additionally, when the aggregator database node 122 is a distributed ledger-based database, revenue sharing can be performed based on smart contracts or other protocols of distributed ledger technology. In some embodiments, when the aggregator database node 122 is a non-distributed ledger-based database, revenue sharing can be performed based on conventional sharing mechanisms such as file exchange or by utilizing an application programming interface (API).
[0102] like Figure 5 As shown, the aggregated transaction records can also be received by the archive database node 124 from the aggregator database node 122. The archive database node 124 can receive summarized transaction records, rather than individual transaction records “TR01”, ... “TR07” (e.g., ...). Figure 4CAs shown, archive database node 124 receives individual transaction records ("TR09-TR13") based on a second data retention mechanism. For example, archive database node 124 can receive aggregated transaction records associated with the first MP node 116A ("MP1") from aggregator database node 122. Archive database node 124 can also receive aggregated transaction records associated with the second MP node 116B ("MP2") from aggregator database node 122. Figure 5 As shown in (for example), archive database node 124 can receive transaction records for aggregation used by the first MP node 116A and store them as "MP1-41 hours storage duration," which can aggregate records from multiple aggregations stored in aggregator database node 122 (i.e., MP1-15 hours, MP1-14 hours, and MP1-12 hours). Similarly, as Figure 5 As shown in (for example), archive database node 124 can receive aggregated transaction records for the second MP node 116B and store them as “MP2-3 hours storage duration”.
[0103] In the embodiment, in addition to storing aggregated transaction records (such as "MP1-41 hour storage duration" and "MP2-3 hour storage duration"), Figure 5 In addition to the transactions shown in the diagram, the archive database node 124 may also store an exact copy of all or selected transaction records stored at the aggregator database node 122 for each MP node associated with each of the multiple node packages 120. In other words, for example, since the first MaaS node 118A stores transaction records “TR01”, “TR02”, and “TR03” (i.e., received from the first MP node 116A), similarly, in addition to storing aggregated transaction records (such as “MP1-41-hour storage duration”), the archive database node 124 may also store an exact copy of transaction records “TR01”, “TR02”, and “TR03” (i.e., received from the aggregator database node 122). It is noteworthy that the storage of exact copies of transaction records in the archive database node 124 (i.e., received from the aggregator database node 122) is... Figure 5 It is not explicitly shown in the text, but for example in Figure 4B-4C As described and illustrated in the diagram. Similarly, in addition to storing aggregated transaction records, archive database node 124 may also store all (or selected) transaction records (i.e., in the same form) stored at different MP nodes and MaaS nodes in each of the multiple node packages 120.
[0104] Therefore, during the audit process, individual transaction records for a specific mobility provider (e.g., “TR01,” “TR02,” “TR03,” “TR04,” “TR05” for MP1 in each node packet) and aggregated transaction records for the same mobility provider (e.g., “MP1-41-hour storage duration”) can be retrieved from archived database node 124 and compared to check the correctness of the stored transaction records (i.e., matching or checksum verification). For example, but not limited to, the sum of the storage durations (in hours / days) of each individual transaction record (e.g., “TR01,” “TR02,” “TR03,” “TR04,” “TR05” for MP1 in each node packet) can be compared with the aggregated storage duration of the aggregated transaction records stored at archived database node 124 (i.e., Figure 5 The 41 hours shown are compared to check the correctness (i.e., check and verification) of the same mobility participant (i.e., "MP1").
[0105] In one embodiment, the archive database node 124 can be a distributed ledger-based database (i.e., online or on-chain mode), and ownership of the archive database node 124 can be managed by the mobility provider. Therefore, transaction records on the archive database node 124 can be used by the mobility provider for revenue sharing. In another embodiment, the archive database node 124 can be a non-distributed ledger-based database (i.e., offline or off-chain mode). In this case, the mobility provider can query the archive database node 124 and access transaction records for revenue sharing. Therefore, each mobility participant can access curated or aggregated transaction records corresponding to each of the multiple MP nodes for revenue sharing. It can be noted that... Figure 5 The implementation of aggregation and revenue sharing between mobility providers based on time periods (i.e., a first storage duration, a second storage duration, and / or a retention threshold in hours or days) described / illustrated is merely an example. The disclosed system can perform aggregation and revenue sharing between different mobility providers based on cost values associated with transaction records (e.g., travel-related costs).
[0106] Figure 6 This is a block diagram of a system for supporting large-scale transactions and node archiving on a MaaS platform based on a shared database architecture, according to embodiments of the present disclosure. Figure 6 Combination Figure 1 , 2 Explain the elements in 3, 4A, 4B, 4C, and 5. (See reference.) Figure 6The diagram shows a block diagram of system 600A. System 600A may include a first subscriber node 114A, a first MP node 116A, a first MaaS node 118A, an aggregator database node 122, an archive database node 124, and a first server 128.
[0107] The first MP node 116A may include a processor 602A, a memory 602B, and a network interface 602C. The first MaaS node 118A may include a processor 604A, a memory 604B, and a network interface 604C. Furthermore, the aggregator database node 122 may include a processor 606A, a memory 606B, and a network interface 606C. The archive database node 124 may also include a processor 608A, a memory 608B, and a network interface 608C. Although not shown, each of the first server 128 and the first subscriber node 114 may also include a processor, memory, and a network interface.
[0108] The first subscriber node 114A, the first MP node 116A, and the first MaaS node 118A can form the first node package 120A in a plurality of node packages 120. The aggregator database node 122 can be communicatively coupled to the first MaaS node 118A. The archive database node 124 can be communicatively coupled to the aggregator database node 122. Additionally, the first server 128 can be communicatively coupled to each of the aggregator database node 122 and the archive database node 124.
[0109] Processor 604A may include suitable logic, circuitry, and / or interfaces that can be configured to execute a set of instructions stored in memory 604B. Processor 604A may be configured to execute program instructions associated with different operations to be performed by the first MaaS node 118A or any other MaaS node. For example, some of these operations may include selecting a first set of transaction records from a first plurality of transaction records stored in the first MaaS node 118A and transferring the first set of selected transaction records to aggregator database node 122 for storage. Processor 604A may also be configured to control the selection of a second set of transaction records from a third set of transaction records stored on the aggregator database node and control the transfer of the second set of selected transaction records to archive database node 124 for storage. Processor 604A may be implemented based on a variety of processor technologies known in the art. Examples of processor technologies may include, but are not limited to, a central processing unit (CPU), an x86-based processor, a reduced instruction set computing (RISC) processor, an application-specific integrated circuit (ASIC) processor, a complex instruction set computing (CISC) processor, a graphics processing unit (GPU), and other processors. The functions of processors 602A, 606A, and 608A can be compared with, for example, in... Figure 6 or Figures 4A-4C The processor 604A of the first MaaS node 118A described herein has the same function. Therefore, for the sake of brevity, the description of processors 602A, 606A and 608A is omitted in this disclosure.
[0110] Memory 604B may include suitable logic, circuitry, and / or interfaces, which may be configured to store one or more instructions to be executed by processor 604A. Memory 604B may be configured to store a plurality of transaction records. Instances of implementations of memory 604B 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 secure digital card (SD). The functions of memory 602B, memory 606B, and memory 608B may be, for example, in… Figure 6 The memory 604B described herein has the same function. Therefore, for the sake of brevity, the description of memory 602B, memory 606B and memory 608B is omitted in this disclosure.
[0111] Network interface 604C may include suitable logic, circuitry, and interfaces that can be configured to facilitate communication between corresponding processors of the first MaaS node 118A, the first MP node 116A, and the aggregator database node 122 (and archive database node 124) via a communication network. Figure 6(Not shown in the image) Communication. Network interface 604C can be implemented using various known technologies to support wired or wireless communication between the first MaaS node 118A and the communication network. Network interface 604C may include, but is not limited to, antennas, radio frequency (RF) transceivers, one or more amplifiers, tuners, one or more oscillators, digital signal processors, encoder-decoder (CODEC) chipsets, subscriber identity module (SIM) cards, or local buffer circuitry systems. Network interface 604C can be configured to communicate wirelessly with networks such as the Internet, intranets, or wireless networks (such as cellular telephone networks, wireless local area networks (LANs), and metropolitan area networks (MANs)). Wireless communication can be configured to use one or more of various 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, Wi-Fi (such as IEEE 802.11a, IEEE 802.11b, IEEE 802.11g, or IEEE 802.11n), Voice over Internet Protocol (VoIP), Li-Fi, Global Microwave Access Interoperability (Wi-MAX), and protocols for email, instant messaging, and Short Message Service (SMS). The functions of network interfaces 602C, 606C, and 608C can be compared with, for example... Figure 6 The network interface 604C described herein has the same function. Therefore, for the sake of brevity, the description of network interface 602C, network interface 606C and network interface 608C is omitted in this disclosure.
[0112] Figure 7 An exemplary flowchart illustrating a method for supporting large-scale transactions and node archiving on a MaaS platform based on a shared database architecture, according to embodiments of the present disclosure, is shown. Figure 6 Combination Figure 1 , 2 The elements in 3, 4A, 4B, 4C, 5, and 6 are described. (See reference.) Figure 7 The flowchart 700 is shown. The exemplary method of flowchart 700 can be executed by any computing system, for example, by the first MaaS node 118A or... Figure 1 Other Maas nodes are executed. An exemplary method of flowchart 700 can start from 702 and proceed to 704.
[0113] At point 704, a first set of transaction records can be selected from a first plurality of transaction records stored on a first MaaS node (such as first MaaS node 118A), wherein the selection of the first set of transaction records can be based on a first data retention threshold and a first storage duration for each of the first plurality of transaction records on the first MaaS node 118A. According to an embodiment, the processor 604A of the first MaaS node 118A can be configured to select the first set of transaction records from the first plurality of transaction records stored on the first MaaS node 118A. The selection of the first set of transaction records can be based on a first data retention threshold and a first storage duration for each of the first plurality of transaction records on the first MaaS node 118A. In an example, the first data retention threshold could be three days. Each of the first plurality of transaction records can be associated with a transaction message received by a first subscriber node (such as first subscriber node 114A) of the first node packet 120A. For example, in Figure 2 and 4B The text explains the selection of the first set of transaction records.
[0114] At point 706, the first set of selected transaction records can be transferred to aggregator database node 122 for storage. According to an embodiment, the processor 604A of the first MaaS node 118A can be configured to transfer the first set of selected transaction records to aggregator database node 122 for storage. For example, in... Figure 2 and 4B The document describes the transfer of the first set of selected transaction records to aggregator database node 122.
[0115] At point 708, a second set of transaction records can be selected from a third set of transaction records stored on aggregator database node 122. The selection of the second set of transaction records can be based on a second data retention threshold and a second storage duration for each of the third set of transaction records on aggregator database node 122. According to an embodiment, the processor 604A of the first MaaS node 118A can be configured to control the selection of a second set of transaction records from the third set of transaction records stored on aggregator database node 122. The third set of transaction records may include at least the first set of transaction records. The selection of the second set of transaction records can be based on a second data retention threshold and a second storage duration for each of the third set of transaction records on aggregator database node 122. In some embodiments, the second data retention threshold can be greater than the first data retention threshold (e.g., three days). For example, the second data retention threshold could be 60 days. In another embodiment, the second data retention threshold can be less than the first data retention threshold. For example, the second data retention threshold could be one day. Figure 2 and 4C The selection of the second set of transaction records is explained in the text.
[0116] At point 710, the transfer of a second set of selected transaction records to an archive database node (such as archive database node 124) can be controlled for storage at archive database node 124. According to an embodiment, the processor 604A of the first MaaS node 118A can be configured to control the transfer of the second set of selected transaction records to archive database node 124 for storage of the second set of transaction records at archive database node 124. For example, in Figure 2 and 4C The text explains how the second set of selected transaction records is transferred to archive database node 124.
[0117] Although flowchart 700 is shown as discrete operations, such as 704, 706, 708, and 710, this disclosure is not limited thereto. Thus, in some embodiments, these 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.
[0118] Various embodiments of this disclosure may provide non-transitory computer-readable media and / or storage media having stored computer-executable instructions or instructions executable by a machine and / or computer (for a system, such as system 600A). The system may include aggregator database nodes (such as aggregator database node 122), archive database nodes (such as aggregator database node 122), and multiple node packets (such as multiple node packets 120), wherein each of the multiple node packets may include a subscriber node of a first Mobile-as-a-Service (MaaS) network, a mobility provider (MP) node of a first distributed ledger, and a MaaS node of a second distributed ledger. The instructions may cause a machine and / or computer to perform operations that may include selecting a first set of transaction records from a first set of a first plurality of transaction records stored on the first MaaS node by a first MaaS node of the first node packet. The selection of the first set of transaction records may be based on a first data retention threshold and a first storage duration of each of the first plurality of transaction records on the first MaaS node. Each of the first plurality of transaction records may be associated with a transaction message received by the first subscriber node of the first node packet. The operation may further include the first MaaS node transferring a first set of selected transaction records to an aggregator database node for storage. The operation may also include the first MaaS node controlling the selection of a second set of transaction records from a third set of transaction records stored on the aggregator database node. The selection of the second set of transaction records may be based on a second data retention threshold and a second storage duration for each of the first set of transaction records on the aggregator database node. The third set of transaction records stored on the aggregator database node may include at least the first set of transaction records. The operation may also include the first MaaS node controlling the transfer of the second set of selected transaction records to an archive database node for storage.
[0119] Exemplary aspects of this disclosure may include systems (such as system 600A). System 600A may include multiple node packets (such as multiple node packets 120). Each of the multiple node packets 120 (such as a first node packet 120A) may include a subscriber node (e.g., first subscriber node 114A) of a first MaaS network (such as first MaaS network 102), a mobility provider (MP) node of a first distributed ledger, and a MaaS node of a second distributed ledger. System 600A may also include an aggregator database node (such as aggregator database node 122) communicatively coupled to each of the multiple node packets 120. System 600A may also include an archive database node (such as archive database node 124) communicatively coupled to aggregator database node 122. A first MaaS node (such as first MaaS node 118A) from the first node packet 120A of the multiple node packets 120 may be configured to select a first set of transaction records from a first plurality of transaction records stored on the first MaaS node 118A. The selection of a first set of transaction records can be based on a first data retention threshold and a first storage duration for each of the first plurality of transaction records on the first MaaS node 118A. Each of the first plurality of transaction records can be associated with a transaction message received by the first subscriber node 114A of the first node packet 120A. The first MaaS node 118A can also be configured to transmit the selected first set of transaction records to the aggregator database node 122 for storage at the aggregator database node 122. The first MaaS node 118A can be configured to control the selection of a second set of transaction records from a third set of transaction records stored on the aggregator database node 122. The selection of the second set of transaction records can be based on a second data retention threshold and a second storage duration for each of the first set of transaction records on the aggregator database node 122. The third set of transaction records can include at least the first set of transaction records. Furthermore, the first MaaS node 118A can be configured to control the transmission of the selected second set of transaction records to the archive database node 124 for storage at the archive database node 124.
[0120] According to an embodiment, the first MaaS node 118A may also be configured to compare a first storage duration for each of the first plurality of transaction records on the first MaaS node 118A with a first data retention threshold. The first MaaS node 118A may also select a first set of transaction records from the first plurality of transaction records based on this comparison.
[0121] According to an embodiment, the first MaaS node 118A can also be configured to control a comparison of a second storage duration with a second data retention threshold for each of the third set of transaction records on the aggregator database node 122. The first MaaS node 118A can also control the selection of a second set of transaction records from the third set of transaction records based on this comparison.
[0122] According to an embodiment, the first MaaS node 118A can also be configured to invalidate the first set of selected transaction records from the first MaaS node 118A based on the transmission of the first set of selected transaction records to the aggregator database node 122.
[0123] According to an embodiment, the first MaaS node 118A can also be configured to control the invalidation of the second set of selected transaction records in the aggregator database node 122 based on the transmission of the second set of selected transaction records to the archive database node 124.
[0124] According to an embodiment, the subscriber node of each of the plurality of node packets 120 can be associated with the first MaaS network 102 through a plug-in interface. The plug-in interface may include at least one of the following: a network protocol handler plug-in, a security plug-in, a data scheme and data quality check plug-in, a monitor and alarm plug-in, a transaction management plug-in, a transaction error handler plug-in, or a concurrent thread management plug-in.
[0125] According to an embodiment, one or more of the plurality of node packages 120 may include subscriber nodes, a plurality of MP nodes of a first distributed ledger (such as a plurality of MP nodes 116A, 116B, ... 116N), and a MaaS node of a second distributed ledger.
[0126] According to an embodiment, each of the plurality of MP nodes 116A, 116B, ... 116N may be associated with a separate mobility provider of the first MaaS network 102.
[0127] According to an embodiment, system 600A may further include a first server (such as first server 128) associated with each of aggregator database node 122 and archive database node 124. First server 128 may be configured to transmit queries for one or more first transaction records stored on aggregator database node 122 to aggregator database node 122. First server 128 may receive the queried one or more first transaction records from aggregator database node 122. First server 128 may also verify one or more transactions associated with the queried one or more first transaction records.
[0128] According to an embodiment, the first server 128 may also be configured to transmit queries for one or more second transaction records stored on the archive database node 124 to the archive database node 124. The first server 128 may also receive the queried one or more second transaction records from the archive database node 124. The first server 128 may also display statistical information related to the queried one or more second transaction records.
[0129] According to an embodiment, the system may further include a cache database node (such as cache database node 126). Cache database node 126 may also be configured to receive one or more second transaction records queried from archive database node 124. Cache database node 126 stores the received one or more second transaction records on its own cache database node. Cache database node 126 may receive queries from a first server 128 for one or more third transaction records among the one or more second transaction records stored on the cache database node. Cache database node 126 may transmit one or more third transaction records to the first server 128 based on the received queries for one or more third transaction records.
[0130] According to one embodiment, aggregator database node 122 and archive database node 124 may be distributed ledger nodes associated with the first MaaS network 102. According to another embodiment, aggregator database node 122 and archive database node 124 may be non-distributed ledger nodes associated with the first MaaS network 102.
[0131] According to one embodiment, the second data retention threshold may be greater than the first data retention threshold. According to another embodiment, the second data retention threshold may be lower than the first data retention threshold.
[0132] This disclosure can be implemented in hardware or a combination of hardware and software. It can be implemented in a centralized manner, on at least one computer system, or in a distributed manner, wherein different components can be distributed across multiple interconnected computer systems. A computer system or other apparatus suitable for performing the methods described herein may be appropriate. The combination of hardware and software can be a general-purpose computer system having a computer program that, when loaded and executed, can control the computer system to perform the methods described herein. This disclosure can be implemented in hardware that includes a portion of an integrated circuit that also performs other functions.
[0133] This disclosure can also be embedded in a computer program product that includes all features enabling the implementation of the methods described herein and, when loaded into a computer system, is capable of executing those methods. In this document, a computer program means any expression of a set of instructions represented in any language, code, or notation, which is intended to cause a system with information processing capabilities to directly perform a particular function, or to perform a particular function after one or both of the following: a) being translated into another language, code, or notation; or b) being copied in a different material form.
[0134] While this disclosure has been described with reference to certain embodiments, those skilled in the art will understand that various changes and substitutions can be made without departing from the scope of this disclosure. Furthermore, many modifications can be made to suit particular situations or materials to the teachings of this disclosure without departing from the scope of this disclosure. Therefore, it is intended that this disclosure be limited to the specific embodiments disclosed, but rather that this disclosure will include all embodiments falling within the scope of the appended claims.
Claims
1. A system comprising: Multiple node packets, wherein each of the multiple node packets includes a subscriber node of a first Mobile-as-a-Service (MaaS) network, a mobility provider (MP) node of a first distributed ledger, and a MaaS node of a second distributed ledger. The aggregator database node is communicatively coupled to each of the plurality of node packets; as well as An archive database node, communicatively coupled to an aggregator database node, wherein the first MaaS node of the first node package in the plurality of node packages is configured as follows: Select the first set of transaction records from the first plurality of transaction records stored on the first MaaS node, where The selection of the first set of transaction records is based on a first data retention threshold and a first storage duration for each of the first plurality of transaction records on the first MaaS node, and Each of the first multiple transaction records is associated with a transaction message received by the first subscriber node of the first node packet; The first set of selected transaction records is transferred to the aggregator database node for storage at the aggregator database node; The second set of control transactions is selected from a third set of transaction records stored on the aggregator database node, where... The selection of the second set of transaction records is based on a second data retention threshold and the second storage duration of each transaction record in the third set on the aggregator database node, and The third set of transaction records stored on the aggregator database node includes at least the first set of transaction records; as well as The control system transfers the second set of selected transaction records to the archive database node for storage there. The system further includes a first server associated with each of the aggregator database node and the archive database node, wherein the first server is configured as follows: Transmit queries for one or more first transaction records stored on the aggregator database node to the aggregator database node; Receive one or more first transaction records retrieved from the aggregator database node; Verify one or more transactions associated with the one or more first transaction records retrieved in the query; Transmit queries for one or more second transaction records stored on the archive database node to the archive database node; Receive one or more second transaction records retrieved from the archive database node; and Displays statistical information associated with one or more of the retrieved second transaction records. The system also includes a cache database node, which is further configured as follows: Receive one or more second transaction records retrieved from the archive database node; Store one or more received second transaction records on a cache database node; Receive queries from the first server for one or more third transaction records from one or more second transaction records stored on a cache database node; and Based on the received query for the one or more third transaction records, the one or more third transaction records are transmitted to the first server.
2. The system according to claim 1, wherein the first MaaS node is further configured as follows: Compare the first storage duration of each transaction record in the first plurality of transaction records on the first MaaS node with a first data retention threshold; and Based on this comparison, a first set of transaction records is selected from the first plurality of transaction records.
3. The system according to claim 1, wherein the first MaaS node is further configured as follows: The comparison of the second storage duration of each transaction record in the third set of control transaction records on the aggregator database node with a second data retention threshold; and The selection of a second set of transaction records from a third set of transaction records is based on this comparison.
4. The system of claim 1, wherein the first MaaS node is further configured to invalidate the first set of selected transaction records from the first MaaS node based on the transmission of the first set of selected transaction records to the aggregator database node.
5. The system of claim 1, wherein the first MaaS node is further configured to control the invalidation of the second set of selected transaction records in the aggregator database node based on transmitting the second set of selected transaction records to the archive database node.
6. The system of claim 1, wherein the subscriber node of each of the plurality of node packets is associated with the first MaaS network via a plug-in interface, wherein the plug-in interface includes at least one of the following: Network protocol handler plugin, Security plugins Data schemes and data quality inspection plugins Monitor and alarm plugins Transaction management plugin Transaction error handling plugin, or Concurrent thread management plugin.
7. The system of claim 1, wherein one or more of the plurality of node packets include subscriber nodes, a plurality of MP nodes of the first distributed ledger, and MaaS nodes of the second distributed ledger.
8. The system of claim 7, wherein each of the plurality of MP nodes is associated with a separate mobility provider of the first MaaS network.
9. The system of claim 1, wherein the aggregator database node and the archive database node are distributed ledger nodes associated with the first MaaS network.
10. The system of claim 1, wherein the aggregator database node and the archive database node are non-distributed ledger nodes associated with the first MaaS network.
11. The system of claim 1, wherein the second data retention threshold is greater than the first data retention threshold.
12. The system of claim 1, wherein the second data retention threshold is lower than the first data retention threshold.
13. A method comprising: The system includes multiple node packets, wherein each of the multiple node packets includes a subscriber node of a first Mobile as a Service (MaaS) network, a mobility provider (MP) node of a first distributed ledger, and a MaaS node of a second distributed ledger. The aggregator database node is communicatively coupled to each of the plurality of node packets; And the archive database node, communicatively coupled to the aggregator database node: The first MaaS node of the first node packet in the plurality of node packets selects a first set of transaction records from the first plurality of transaction records stored on the first MaaS node, wherein The selection of the first set of transaction records is based on a first data retention threshold and a first storage duration for each of the first plurality of transaction records on the first MaaS node, and Each of the first multiple transaction records is associated with a transaction message received by the first subscriber node of the first node packet; The first MaaS node transmits the first set of selected transaction records to the aggregator database node for storage at the aggregator database node. The selection of transaction records from a second set controlled by the first MaaS node is made from a third set of transaction records stored on the aggregator database node, where... The selection of the second set of transaction records is based on a second data retention threshold and the second storage duration of each transaction record in the third set on the aggregator database node, and The third set of transaction records stored on the aggregator database node includes at least the first set of transaction records; as well as The first MaaS node controls the transmission of the second set of selected transaction records to the archive database node for storage. The system further includes a first server associated with each of the aggregator database node and the archive database node, and the method further includes: The first server transmits a query for one or more first transaction records stored on the aggregator database node to the aggregator database node; The first server receives one or more first transaction records retrieved from the aggregator database node; The first server verifies one or more transactions associated with the one or more first transaction records retrieved in the query; The first server transmits a query for one or more second transaction records stored on the archive database node to the archive database node; The first server receives one or more second transaction records retrieved from the archive database node; and The first server displays statistical information associated with one or more of the queried second transaction records. The system further includes a cache database node, and the method further includes: The cache database node receives one or more second transaction records retrieved from the archive database node. The cache database node stores one or more received second transaction records on the cache database node; The cache database node receives a query from the first server for one or more third transaction records from the one or more second transaction records stored on the cache database node; and The cache database node transmits the one or more third transaction records to the first server based on the received query for the one or more third transaction records.
14. The method of claim 13, further comprising: The first MaaS node compares the first storage duration of each transaction record in the first plurality of transaction records on the first MaaS node with a first data retention threshold. as well as The first MaaS node selects a first set of transaction records from a first plurality of transaction records based on the comparison.
15. The method of claim 13, further comprising: A comparison of the second storage duration of each transaction record in the third set of transaction records controlled by the first MaaS node on the aggregator database node with a second data retention threshold; as well as The first MaaS node controls the selection of a second set of transaction records from a third set of transaction records based on the comparison.
16. The method of claim 13, further comprising invalidating the first set of selected transaction records in the first MaaS node based on the first set of selected transaction records transmitted to the aggregator database node.
17. A non-transitory computer-readable medium having computer-executable instructions stored thereon, the computer-executable instructions causing the system to perform operations when executed by a system comprising an aggregator database node, an archive database node, and a plurality of node packets, wherein each of the plurality of node packets comprises a subscriber node of a first Mobile-as-a-Service (MaaS) network, a mobility provider (MP) node of a first distributed ledger, and a MaaS node of a second distributed ledger, the operations comprising: The first MaaS node of the first node packet in the plurality of node packets selects a first set of transaction records from the first plurality of transaction records stored on the first MaaS node, wherein The selection of the first set of transaction records is based on a first data retention threshold and a first storage duration for each of the first plurality of transaction records on the first MaaS node, and Each of the first multiple transaction records is associated with a transaction message received by the first subscriber node of the first node packet; The first MaaS node transmits the first set of selected transaction records to the aggregator database node for storage at the aggregator database node. The selection of transaction records from a second set controlled by the first MaaS node is made from a third set of transaction records stored on the aggregator database node, where... The selection of the second set of transaction records is based on a second data retention threshold and a second storage duration for each transaction record in the first set on the aggregator database node, and The third set of transaction records stored on the aggregator database node includes at least the first set of transaction records; as well as The first MaaS node controls the transmission of the second set of selected transaction records to the archive database node for storage. The system further includes a first server associated with each of the aggregator database node and the archive database node, wherein the operation further includes: The first server transmits a query for one or more first transaction records stored on the aggregator database node to the aggregator database node; The first server receives one or more first transaction records retrieved from the aggregator database node; The first server verifies one or more transactions associated with the one or more first transaction records retrieved in the query; The first server transmits a query for one or more second transaction records stored on the archive database node to the archive database node; The first server receives one or more second transaction records retrieved from the archive database node; and The first server displays statistical information associated with one or more of the queried second transaction records. The system also includes a cache database node, and the operation further includes: The cache database node receives one or more second transaction records retrieved from the archive database node. The cache database node stores one or more received second transaction records on the cache database node; The cache database node receives a query from the first server for one or more third transaction records from the one or more second transaction records stored on the cache database node; and The cache database node transmits the one or more third transaction records to the first server based on the received query for the one or more third transaction records.
Citation Information
Patent Citations
Systems and methods for blockchain virtualization and scalability
US20170337534A1
Systems and methods for scalable structured data distribution
WO2013155532A2