Privacy-protected MaaS (Mobility as a Service) supported by blockchain technology

Abstract

A communication network node, a communication network, and a method for controlling a communication network for providing a distributed ledger. [Solution] The present disclosure provides a communications network node for providing data to a distributed ledger, the communications network node providing a user data manager for separating sensitive user data and non-sensitive user data, and having circuitry configured to provide the non-sensitive user data to the distributed ledger.

Description

Technical Field

[0001] The present disclosure generally relates to communication network nodes, communication networks, and methods for providing a distributed ledger.

Background Art

[0002] Generally, it is known to distribute a ledger on a plurality of nodes such as entities that record digital transactions, for example, electronic devices, servers, etc. The distributed ledger can comply with well-known blockchain technologies such as, for example, the well-known cryptocurrency Bitcoin and the well-known Ethereum project. Generally, the distributed ledger may be realized by other technologies other than blockchain technology, and examples of distributed ledger projects not based on blockchain include BigchainDB and IOTA. For example, IOTA is a cryptocurrency that uses lists linked to each other. Also, for example, Mobility as a Service (MaaS) is known, in which users or passengers utilize mobility as a service without owning an automobile or the like. MaaS can combine public (e.g., trains, buses, etc.) and personal (e.g., car sharing, bike sharing, etc.) transportation services from related operators or providers.

[0003] Well-known MaaS solutions typically include a central unified gateway through which business trips or travels are planned and reserved, and users can make payments with a single account.

[0004] Although technologies for providing a distributed ledger and MaaS exist, generally, it is desirable to provide a communication network node, a communication network, and a method for controlling the communication network for providing a distributed ledger.

Prior Art Documents

Non-Patent Documents

[0005]

Patent Document 1

[0006] The present invention aims to provide a communication network node, a communication network, and a method for controlling the communication network for providing a distributed ledger. [Means for solving the problem]

[0007] According to a first aspect, the Disclosure provides a communication network node for providing data to a distributed ledger, which includes a user data management unit for separating sensitive user data from non-sensitive user data, and a circuit configured to provide the non-sensitive user data to the distributed ledger.

[0008] According to a second aspect, the disclosure provides a communication network having a plurality of nodes for providing a distributed ledger, wherein at least one of the plurality of nodes provides a user data management unit for separating sensitive user data from non-sensitive user data, and the communication network has a circuit configured to provide the non-sensitive user data to the distributed ledger.

[0009] According to a third aspect, the Disclosure provides a method for controlling a communication network having multiple nodes for providing a distributed ledger, comprising providing a user data management unit for separating sensitive user data from non-sensitive user data, and providing the non-sensitive user data to the distributed ledger.

[0010] Further embodiments are described in the independent claims, the following description and drawings.

[0011] Embodiments are described as illustrative examples with respect to the attached drawings. [Brief explanation of the drawing]

[0012] [Figure 1] Figure 1 provides a schematic representation of blockchain. [Figure 2] Figure 2 schematically shows hashing in a blockchain. [Figure 3] Figure 3 is a flowchart showing an embodiment of a consensus protocol. [Figure 4] Figure 4 shows the data flow in a MaaS system. [Figure 5] Figure 5 shows an embodiment of a blockchain including travel log data. [Figure 6] Figure 6 shows an embodiment of a communication network for providing a blockchain. [Figure 7] Figure 7 shows an embodiment of separating confidential and non-confidential data. [Figure 8] Figure 8 shows each block of a blockchain including travel data. [Figure 9] Figure 9 shows the pseudonymization of passenger data. [Figure 10] Figure 10 shows the anonymization of passenger data. [Figure 11] Figure 11 shows an embodiment of using different keys for data protection in a blockchain. [Figure 12] Figure 12 shows the separation of non-confidential and confidential data where the confidential data is protected. [Figure 13] Figure 13 shows the third-party encryption of data. [Figure 14] Figure 14 shows the access to data by a third party where the confidential data is anonymized. [Figure 15] Figure 15 shows an application programming interface for access by a third party for big data analysis. [Figure 16] Figure 16 shows a first embodiment of erasing data from a blockchain by invalidating a key. [Figure 17] Figure 17 shows a second embodiment of erasing data from a blockchain by erasing blocks. [Figure 18]FIG. 18 shows an embodiment of a general-purpose computer, and in some embodiments, a network device or a communication device is implemented based on the general-purpose computer. [Figure 19] FIG. 19 shows an embodiment of an eNodeB and a user equipment that communicate with each other.

Embodiments for Carrying out the Invention

[0013] Before explaining the embodiments in detail with reference to FIG. 1, a general description will be given.

[0014] As described at the beginning, generally, a distributed ledger and MaaS (Mobility as a Service) are known.

[0015] This disclosure generally relates to the use of blockchain / distributed ledger for MaaS applications, particularly for MaaS between two or more service providers (multimodal transportation), in some embodiments or aspects.

[0016] Also, this disclosure generally relates to the use of a distributed ledger or a blockchain as an example of a distributed ledger, without limiting this disclosure to a blockchain, in some embodiments or aspects. Since a distributed ledger requires a distributed database for travel history (or travel data) among multiple players, i.e., multiple MaaS providers, it is recognized that a distributed ledger or a blockchain is suitable for MaaS applications according to some aspects of this disclosure.

[0017] In some embodiments, an MaaS blockchain may need to handle a large number of passengers, store various types of travel records, store large-sized blocks, store the processing peak during congestion, etc.

[0018] In some embodiments, distributed ledgers or blockchains are generally suitable for MaaS applications because they provide a distributed database for travel history among multiple players.

[0019] However, since personal data is typically open to all members of the blockchain, and users cannot delete / modify the recoded data within a block, protecting personal data can be challenging for blockchains / distributed ledgers.

[0020] Therefore, it is recognized that in some embodiments, particularly for MaaS applications, it may be useful to protect user privacy using a blockchain-based distributed ledger. Furthermore, the requirements for passenger travel records and passenger privacy protection may conflict with each other in some embodiments.

[0021] In some embodiments, with respect to accurately recording passenger travel, the distributed ledger can be shared among players (including mobility service providers) and may be immutable. Such characteristics make it suitable in some embodiments for recording / providing evidence of travel, such as calculating revenue shares. In addition, national transport authorities may be required to maintain records of passenger information, as is known particularly for air travel.

[0022] On the other hand, in some embodiments, MaaS travel records may include sensitive passenger information such as where, when, who, and what a passenger is doing. Therefore, from the perspective of protecting personal data, anonymization and pseudonymization may be applied. In some embodiments, there are requirements to protect personal data, such as the General Data Protection Regulation (GDPR).

[0023] Therefore, in this disclosure, several embodiments relate to the issues of how to protect personal data with access control and how to provide methods for anonymizing and pseudonymizing passenger data.

[0024] Therefore, in some embodiments, personal information is limited to inaccessible parts of the system that are inaccessible to third parties. Also, in some embodiments, the sensitivity of user profile / multimodal path information is guaranteed by the mobility service provider contracted with the user, while, for example, user-specific IDs are anonymized in a distributed ledger or blockchain. Travel logs contained in a distributed ledger or blockchain may be under access control, and the contents of travel logs may be pseudonymized.

[0025] The following definitions are given. These terms may apply in several embodiments (however, this disclosure is not limited to the following definitions. These definitions are merely examples given to enhance understanding of this disclosure, and it should be noted that the MaaS and distributed ledger technologies are highly dynamic and definitions may change in the future).

[0026] As can be seen from Wikipedia, the term "distributed ledger" is defined as "a consensus of digital data that is geographically distributed across multiple sites, countries, or institutions, and is replicated, shared, and synchronized, without a central administrator or centralized data storage."

[0027] Distributed ledgers and their special example, blockchain technology, will be discussed further below. More generally, the term distributed ledger is used to refer to a type of digitally recorded data that shares a database with multiple nodes in a network. It may consist of a peer-to-peer network. The digitally recorded data may contain some kind of information to prove its consistency with previously recorded data on the same database.

[0028] A distributed ledger is public and accessible to anyone, but in principle, it may also be private, allowing only authorized users to access it. Here, a group of authorized entities, nodes, individuals, businesses, providers, etc., may be called a "consortium," as will be further explained below. It is also possible to differentiate access permissions to the ledger data for each hierarchical user.

[0029] Distributed ledgers can utilize mechanisms known from blockchain technology, such as that used in Bitcoin. These mechanisms include discovery methods, consensus mechanisms, and mechanisms for maintaining data consistency. The consensus mechanism ensures that all nodes, or a certain number of nodes, generally electronic devices, that possess a copy of the distributed ledger reach a consensus on the contents of the distributed ledger. There are many consensus mechanisms, including the so-called proof-of-work mechanism, a type of cryptographic puzzle that ensures older blocks in the blockchain cannot be (easily) altered. For example, proof-of-work is used in the mining process of the Bitcoin blockchain.

[0030] In a distributed ledger or blockchain, a confirmation process called mining, which creates a consensus among participating nodes regarding data updates on the blockchain, can achieve irreversibility of the transaction sequence recorded on the blockchain by including previously recorded data in the confirmation data. Such a mining process realizes a distributed timestamp server for new transaction blocks. In Bitcoin (and therefore in some embodiments), the mining process is based on the SHA-256 hash function. While the input to the hash function depends on the current block of the blockchain and any new transaction blocks to be added to the blockchain, the blockchain nodes involved in the mining process search for a hash output with predefined properties.

[0031] Proof-of-work computation based on hash functions may not be useful in itself, except when necessary to achieve the irreversibility of distributed ledgers.

[0032] Furthermore, blockchain is generally known to be used to store various types of data. For example, images, videos, measurements, and text files can be recorded on the blockchain in the form of transactions.

[0033] The term "MaaS (Mobility as a Service)" is defined on Wikipedia as follows: "MaaS represents a shift from privately owned transportation to mobility solutions consumed as a service. This is made possible by combining transportation services from public and private transport entities through a unified gateway that creates and manages trips for which users can pay with a single account. Users can pay per trip or a monthly fee for a limited distance. The key concept behind MaaS is to provide travelers with mobility solutions based on their travel needs."

[0034] In some embodiments, a "public blockchain / distributed ledger" means that anyone can share a distributed database (ledger) and participate in running a consensus protocol, as described above.

[0035] In contrast, a "permissioned blockchain / distributed ledger" means that only authorized members can share a distributed database (ledger) and participate in a consensus protocol. Authorized members who have permission to access the blockchain are called a "consortium," as mentioned above. In some embodiments, permissioned / consortium-type blockchains are suitable for MaaS applications because they are not public and therefore inaccessible to anyone.

[0036] The definition of the term "(mobile) edge computing" can also be found on Wikipedia, and is defined as follows: Multi-access edge computing (MEC) (formerly mobile edge computing) is the provision of cloud computing capabilities and IT service environments over mobile communication networks. [1][2] MEC is a network architecture concept that enables operation at the edge, or more generally, at the edge of any network. The fundamental idea behind MEC is that by running applications and bringing the associated processing work closer to the mobile communication customer, network congestion is reduced and application performance is improved.

[0037] The term "northbound API" is understood in the context of network virtualization to mean that a telecommunications carrier can configure network functions using a software-based interface (API), and that a network operator can configure virtual infrastructure (such as virtual machines) and requested network / application functions.

[0038] The term "instance" is understood as a software process running on the cloud. It can move to a different location within the distributed cloud.

[0039] A "public cloud" can be defined as follows: A public cloud is the most common way to deploy cloud computing, where cloud resources (servers, storage devices, etc.) are owned, operated, and delivered over the internet by a third-party cloud service provider (https: / / azure.microsoft.com / en-gb / overview / what-are-private-public-hybrid-clouds / ).

[0040] In some embodiments, the following terms are used in a given understanding.

[0041] The term "multimodal transport pass" can refer to a pass valid for multi-mobility services with specific conditions such as validity period, available transport, and services that cannot be permitted. Examples include daily tickets, weekly tickets, monthly MaaS service subscriptions, and season tickets.

[0042] The term "mobility service provider" can be a general term for any type of service provider (MaaS). In some embodiments, these are typically transportation companies such as railway companies, buses / long-distance buses, trams and taxis, car sharing, ride sharing, and bike sharing. Some mobility service providers may not provide actual transportation but only offer booking / configuration services comparable to travel agencies or online booking sites.

[0043] The term “Pass” may also mean a Transit Pass or Travelcard (UK) (see also https: / / en.wikipedia.org / wiki / Transit_pass), and in this disclosure, a multimodal pass is also equivalent to the term “Pass.” This means that a pass is valid across multiple transport operators (or mobility service providers) and therefore may cover not only public transport but also other types of mobility such as rideshares and bikeshares. A pass may include information on permitted transport, validity period, and any other circumstances of ticket issuance / transportation / boarding. In some embodiments, MaaS may offer a monthly service subscription with several options regarding service levels. Passengers or users may pay a service subscription fee or the purchase price of a pass for a specific period to the pass issuer (which may typically be a mobility service provider that issues the pass). Passes may be issued by transport operators or travel agencies, MaaS service providers, etc. (all of which may fall under the term Mobility Service Provider above). Therefore, as stated above, some pass issuers may sell passes but not provide the actual transport service or means of transport.

[0044] The term "ticket" may refer to a ticket for a one-way trip on a specific section, such as a one-way train ticket with (or without) a seat reservation. In some embodiments, the ticket may be issued under a multimodal transport pass and its terms and conditions, and may include information such as selected transport, seat number, and price. In some embodiments, even if a seat reservation is not required or unlimited travel is permitted, the ticket may be issued for revenue sharing among multiple mobility service providers. Furthermore, while passengers (users) cannot pay the ticket issuer directly, the pass issuer can pay the ticket issuer on behalf of the passenger, and the ticket may be issued by a transport operator or service provider, i.e., a mobility service provider.

[0045] The term "travel log" can include a travel log that is a record of a one-way trip based on a ticket. It may include information such as the location of embankment, the date and time of boarding, the disembarking location, the date and time of disembarking, and whether the ticket was used or not, which will be explained further below.

[0046] The term "anonymization" can be defined as follows, according to Wikipedia: Data anonymization is a type of information sanitization aimed at protecting privacy, which involves encrypting or removing personally identifiable information from a dataset so that the person described by the data remains anonymous (https: / / en.wikipedia.org / wiki / Data_anonymization).

[0047] The term "pseudonymization" can be defined, according to Wikipedia, as follows: Pseudonymization is a data management and anonymization procedure in which personally identifiable information items within a data record are replaced by one or more artificial identifiers or pseudonyms. A single pseudonym for each replaced item or set of replaced items makes the data record unidentifiable while remaining suitable for data analysis and processing (https: / / en.wikipedia.org / wiki / Pseudonymization).

[0048] The term "non-traceability" can be understood as meaning that no one (e.g., entities, users, people, etc.) can track the history of an action or behavior. For example, it can be impossible to track where a user went at a particular time, what they did, or didn't do.

[0049] Furthermore, the General Data Protection Regulation (GDPR) may be required. The General Data Protection Regulation (EU) 2016 / 679 ("GDPR") is an EU law regulation concerning the protection of data and privacy for all individuals within the EU (European Union) and the European Economic Area (EEA) (see also https: / / en.wikipedia.org / wiki / General_Data_Protection_Regulation).

[0050] The term “personal data” may, in some embodiments, be understood to mean: “(1) “Personal data” means any information relating to an identified or identifiable natural person (“data subject”); an identifiable natural person is one who can be identified, directly or indirectly, by reference to an identifier such as a name, identification number, location data, online identifier, or by reference to one or more factors inherent in that natural person’s physical, physiological, genetic, mental, economic, cultural, or social identity (see, for example, https: / / gdpr-info.eu / art-4-gdpr / ).”

[0051] Therefore, "pseudonymization under the GDPR" can be understood in the following sense: "(5) "Pseudonymization" means processing personal data in such a way that, without the use of additional information, the personal data cannot be attributed to any particular data subject, provided that such additional information is stored separately and that technical and organizational measures are in place to ensure that the personal data is not attributed to any identified or identifiable natural person."

[0052] In some embodiments, the term “public-key cryptography” is understood as follows, as defined on Wikipedia: “Public-key cryptography, or asymmetric cryptography, is any cryptographic system that uses a pair of keys: a public key that can be widely disseminated and a private key known only to its owner. This achieves two functions: authentication, which verifies that the holder of the paired private key sent the message, and encryption, which verifies that only the holder of the paired private key can decrypt the message encrypted with the public key.” On the other hand, “Two of the most well-known uses of public-key cryptography is public-key encryption, where a message is encrypted with the recipient’s public key. The message is encrypted with the recipient’s public key. The message is encrypted with the recipient’s public key. The message is encrypted with the recipient’s public key. Anyone who does not have a matching private key (i.e., the owner of the matching private key and the public key associated with) It cannot be deciphered even by someone presumed to be the person to whom it was attached. This is used to ensure sensitivity. A digital signature is a digital signature in which a message is signed with the sender's private key, and anyone with access to the sender's public key can verify the message. This verification proves that the sender has access to that private key and is therefore likely to be the person associated with that public key. This also guarantees that the message has not been tampered with, as the signature is mathematically bound to the message it was originally created with. Furthermore, verification against any other message, no matter how similar it may be to the original, will practically fail (https: / / en.wikipedia.org / wiki / Public-key_cryptography)

[0053] In some embodiments, the term “salt” can be defined, according to Wikipedia, as follows: “In cryptography, salt is random data used as an additional input to a one-way function that hashes data, passwords, or passphrases. Salt is closely related to the concept of a nonce. The primary function of salt is to defend against dictionary attacks, or their hashed equivalents, i.e., rainbow table attacks (https: / / en.wikipedia.org / wiki / Salt_(cryptography)).”

[0054] The following provides a general overview of the description. Herein, embodiments for four different aspects of the present disclosure are described. These may be implemented or realized as separate embodiments, or they may be combined with each other in any possible combination.

[0055] According to the first aspect, several embodiments relating to the basic technology are described, including the isolation of sensitive data (by off-chain technology) and naive methods of pseudonymization and anonymization (scrambling and / or hashing).

[0056] According to a second aspect, some embodiments relate to data access control, which may include levels of access control, block encryption with different access keys, and / or open data and APIs.

[0057] According to a third aspect, some embodiments relate to the erasure of sensitive data, including key deactivation and / or block erasure.

[0058] Below, blockchain and its general data structure will be described with reference to Figure 1. In this embodiment of blockchain, the features include the network / topology, consensus algorithm, hash function, participant authentication, scalability / block structure, and performance.

[0059] Figure 1 shows the general structure of Blockchain 1. Blockchain 1 contains a chain of multiple data blocks 2a, 2b, and 2c, where block 2b is the current block (block #N), block 2a is the preceding block (block #N-1), and block 2c is the succeeding block (block #N+1). Each block contains the hash function result of the preceding block, the main data structure, the hash function of the current block, and the input values ​​of the hash function result. The hash function result of the current block (2b) is always used as the input to the next block (2c).

[0060] Furthermore, each block contains a "one-time use number," a unique random number for secure blockchain processing that prevents replay attacks. For example, if an attacker copies previously sent data and reuses the copied data for spoofing, the next data must be replaced by a different "one-time use number," allowing the recipient to detect the spoofing communication. This random number is sometimes called a "nonce" in cryptocurrency.

[0061] Furthermore, timestamps may be inserted into each of blocks 2a, 2b, and 2c. Blockchain 1 is an example of a distributed ledger that can be used, for example, to provide MaaS in some embodiments.

[0062] Figure 2 shows, for example, the input and output of the hash function used in Blockchain 1 in Figure 1.

[0063] Generally, a hash function is any function that can be used to map input data to output data using a specific algorithm. The size of the input data can be large and varied, while the output data can be compact and of a fixed size. In some embodiments of blockchain, a well-known (and famous) algorithm used for hashing is the Secure Hash Algorithm (SHA), designed by the US National Security Agency (e.g., SHA-2, SHA-256).

[0064] The inputs to the hash function are the previous hash output, the nonce, and the data body within the current block (e.g., block 2b in Figure 1). The output of the hash function is a unique value response for the input values. If someone attempts to tamper with the data body, the output of the hash function will become inconsistent.

[0065] The distributed ledger (blockchain) embodiments described herein can implement consensus protocols or algorithms. For example, in some embodiments, Byzantine Fault Tolerance (BFT) is used in the consensus protocol, which is resilient to database spoofing and hardware failures.

[0066] A well-known consensus algorithm implemented in several embodiments is the so-called PBFT (Practical Byzantine Fault Tolerance).

[0067] In some embodiments, permissioned blockchains are used, where a relatively small number of permissioned blockchain nodes are responsible for consensus (block verification).

[0068] Figure 3 illustrates the PBFT process 10.

[0069] In step 11, the leader node (also called a validating peer) requests other nodes to validate the blockchain. In step 12, each requested node (peer validation) uses a hash function to verify the validity of the blockchain and notifies other nodes of the result in step 13. In step 14, the node receives validity results from multiple other peers and, if it receives validity results that exceed a predetermined criterion, confirms consensus on the blockchain. If there is consensus, in step 15, the node writes / terminates the blockchain. The leader peer checks the overall progress of validity verification at other nodes and terminates the blockchain procedure in step 16.

[0070] For resilience, the total number of nodes exceeds 3f+1 in some embodiments, where f is the number of allowed failure nodes. For example, if f=1, there are a total of 4 nodes; if f=3, there are a total of 10 nodes, and so on.

[0071] In some embodiments, the PBFT has a permissioned blockchain for mobility service blockchains as described herein and provides at least partially the following features:

[0072] Regarding security, PBFT has a slight risk of a 51% attack in some embodiments. This is common to cryptocurrencies because the permission of the peers responsible for consensus must be trusted. Regarding privacy, only mobility service providers (for permissioned blockchains) process the blockchain at (peer) nodes, and end users may not have permission to access the blockchain, thus preventing end users from accessing the entire blockchain. Regarding performance, the processing time for consensus is very short in some embodiments because there are few high-performance peers. Regarding flexibility, the block size and format of the blockchain can be more flexible in some embodiments compared to public blockchains.

[0073] The data flow of the MaaS system 20 will be described below with reference to Figure 4, which shows the overall data flow. In the MaaS system 20, it is exemplified that end users have their own terminals 21, such as smartphones (or any other type of electronic (mobile) device). Some users (for example, visitors from overseas) may not have smartphones, etc. In such cases, an alternative solution can be provided, for example, based on the proxy function (proxy 22) in Figure 4 that provides a gateway to the user.

[0074] Figure 4 shows the data flow diagram of the MaaS system 20, which is provided with three main parts: the end-user section on the left, the mobility service provider / operator section in the center, and the other entity section on the right. The end-user section and the other entity section communicate with the central mobility service provider section.

[0075] In this embodiment of the MaaS system 20, the mobility service provider has a user management function 23 with a web server or cloud for customer service, a user profile management function 23a, and a passenger travel management function 23b. Furthermore, it has a blockchain management function 24. The blockchain function 24 having the blockchain management function 24a communicates with the blockchain management function 25 of another entity. When seat reservations / rideshare reservations are provided by a reservation center 26, a central reservation server / cloud is provided.

[0076] The end user communicates with their own terminal, which has exemplary user interfaces and sensors such as GNSS and NFC, i.e., a smartphone 21 in this embodiment.

[0077] As can be seen from Figure 4, end users can perform actions such as subscribing to a service / purchasing a daily / weekly ticket, booking a train, booking a car / rideshare, granting / recording landing permission for transport, and handling post-arrival procedures (e.g., customer survey, refund or delay compensation) via a terminal or proxy 22.

[0078] The user profile management function 23a is configured to store static data, such as name, age, contact address, payment method (e.g., credit card), service subscription status, transportation preferences, and any other unique ID such as TMEI, and to communicate with the terminal 21.

[0079] The passenger travel management function 23b is configured to perform several operations and communicate with the terminal 21. For example, with respect to multimodal transport passes, the passenger travel management function manages, for example, monthly service subscriptions for MaaS and the purchase of daily tickets, weekly tickets, etc. With respect to travel plans (or travel planners), the passenger travel management function provides destination input, route selection / transportation options, booking / travel configuration, issues tickets, issues ticket IDs, generates itineraries for passengers, issues itinerary IDs, etc. During a passenger / user's trip, the passenger travel management function is configured to start the trip, check the held pass / ticket for each segment of the trip (repetition), record boarding, record alighting, add the travel log to the blockchain, end the trip at the end of the trip, and close the travel itinerary.

[0080] The blockchain management function 24a communicates with the passenger travel management function 23b and other blockchain management functions 25. The blockchain management function is configured to add, verify / execute consensus protocols and read the blockchain. Furthermore, as can be seen from Figure 4, pass, ticket, and travel log information is communicated at least between the passenger travel management function 23b and the blockchain management function 24a, and between the blockchain management function 24a and other blockchain management functions 25.

[0081] The following describes an embodiment of blockchain 30 that includes passenger travel history, with reference to Figure 5.

[0082] Blockchain 30 has several blocks 30a, 30b, and 30c, as generally described under the criteria in Figure 1, where Figure 5 illustrates block 30a (block #N-1), the current block 30b (block #N), and the subsequent / future block 30c (block #N+1).

[0083] Each of blocks 30a, 30b, and 30c can contain one or more passenger logs in a transaction within a given maximum block size and associated data structure. In Figure 5, the leftmost block 30a (block #N-1) handles two passenger logs 31a and 31b. The hash output from block N-1 30a is passed to the next N block 30b (the current block). Block 30b (block #N) processes the next travel logs 32a and 32b for passengers A and B, and also the travel log 32c for passenger C's trip. For example, if passenger D issues a new travel log but simultaneously exceeds the block size limit, the further travel log is processed in the next block, i.e., block 30c in this example, which includes the input for passenger B's further travel log 33a, the input for passenger C's further travel log 3cb, and the input for passenger D's further travel log 33c, and block 30c (block N+1) processes the next trips for passengers C and D and the remaining logs for passenger D. Next, the hash output (N+1) is fed into the next block (N+2) (not shown in Figure 5).

[0084] Generally, travel logs within Blockchain 30 can include at least one of the following pieces of information:

[0085] • Issuer: Multimodal transport pass issuer, mobility service provider / transportation operator, passenger ID (anonymized data)

[0086] • Ticket information: Ticket type, type of transport (rail, rideshare, etc.), seat reservation (train / seat number), price or ticket, expiration date and conditions.

[0087] • Passenger record: boarding location, date and time, disembarking location, date and time, unused / used

[0088] • Remarks: Special notes (e.g., cancellation, delay)

[0089] In some embodiments, it is assumed that the MaaS blockchain uses a permissioned blockchain. In a permissioned blockchain, only authorized operators (forming a consortium) can add / read blocks, and limited participants are permitted to participate in transaction verification (i.e., agreement with trusted players). Thus, in some embodiments, for example, mobility service providers are organized into a consortium, and only those with the appropriate permissions are permitted to access the authorized distributed ledger or blockchain, and malicious or fraudulent participants cannot join the blockchain consortium.

[0090] The following describes an embodiment of the communication network 40 for providing a (permitted) blockchain for MaaS, with reference to Figure 6.

[0091] Regarding resilience, the communication network 40 mitigates the risk of a single point of failure (SPOF), which is typically a weakness in traditional systems that heavily rely on a central server.

[0092] As can be seen in Figure 6, the communication network 40 has multiple nodes (or entities) 41 (large circle) associated with different operators or mobility service providers such as MaaS service providers, railway operators, car-sharing / ride-sharing operators, bike-sharing operators, and bus operators.

[0093] Furthermore, there are multiple passengers 42 (small circles) that can communicate with the mobility service provider node 41. The mobility service provider node 41 can together form a communication network 40 that provides a permissioned blockchain for MaaS (for example, blockchain 30 in Figure 5).

[0094] Passenger 42 purchases a daily / weekly pass for multimodal transport services, for example, by subscribing to a monthly MaaS service provided by a mobility service provider, or by communicating with the relevant mobility service provider and its terminal (e.g., terminal 21 in Figure 4).

[0095] As described above, mobility service providers 41 can include not only conventional transportation operators such as automobile and railway companies and tram operators, but also new service providers such as MaaS operators (e.g., ride-sharing), bike-sharing service providers, and travel agencies.

[0096] Mobility service providers 41 connect with each other via a communication network, which is a logical connection. Direct connections between operators or mobility service providers are not necessarily required, but low latency and high throughput may be necessary.

[0097] The mobility service provider entity or node 41 can have various functions, but as mentioned above in Figure 4, it has two main functions: passenger management and blockchain management. The passenger management function supports seat reservations, rideshare / taxi / rental car reservations / train seat reservations, monthly subscriptions, or the purchase of daily passes. The passenger management function provides a user interface for website or smartphone backend processing, similar to a typical e-commerce site.

[0098] On the other hand, in this embodiment, the blockchain is hidden from the end user but is accessible by multiple mobility service providers. Furthermore, in this embodiment, a consortium (permissioned) blockchain is implemented among the 41 nodes, and the blockchain ledger is verified among the mobility service providers who are members of the consortium.

[0099] In some embodiments, the above example is extended to international MaaS operations or MaaS operations in different regions. The blockchain is defined as a multi-layered structure. The first layer of blockchain is configured between countries or regions, and the second layer of blockchain is configured within a consortium in that region. For example, a representative provider in a regional consortium can participate in the first layer of blockchain and handle international services.

[0100] As described above, some embodiments relate to the separation of user personal information in service subscriptions / user profiles.

[0101] In some embodiments, as also shown in Figure 7, the first step is to separate the sensitive passenger (user) master (full) data 50. Here, the full data 50 includes personal information (e.g., passenger, name, home address, telephone number, number, gender, age, passport number, credit card number, etc.) and non-sensitive data such as travel data or travel statistics. As shown in Figure 7, the full data 50 is divided into non-sensitive data 50a and sensitive data 50b, and the non-sensitive data 50a and sensitive data are separated from each other.

[0102] To subscribe to MaaS services, passengers may be required to enter personal data such as name, age, address, phone number, credit card number, and passport number / travel document. This data is likely to be a mix of sensitive and non-sensitive (non-identifiable) data.

[0103] Therefore, in this embodiment, sensitive information / data 50b is separated from the full data 50, the sensitive data is handled with extra care and stored in a secure location.

[0104] For example, if a mobility service provider holds credit card information, in some embodiments, the mobility service provider must comply with industry security standards such as the PCI Standard (PCI Standard). Therefore, in such embodiments, the database and network are protected from external networks by a firewall.

[0105] This means that, in some embodiments, the database for sensitive information is also decoupled from the blockchain node and its network (node ​​41 and network 40 in Figure 6, etc.).

[0106] In some embodiments, this separation of sensitive and non-sensitive information is performed using off-chain techniques shown in blocks 55 and 55 of the blockchain, as also shown in Figure 8.

[0107] In this embodiment, the relationship between passenger personal data and the blockchain is unbundled. Therefore, sensitive data (50b in Figure 7) is not included in the blockchain (also known as off-chain). Personal data (sensitive data) is stored within the MaaS provider (e.g., database, storage, etc.) and is not added to the blockchain.

[0108] Figure 8 shows an example of a ticket and travel record for a MaaS service. The ticket may be issued by a ticket or pass issuer (e.g., a transport operator) or another MaaS service provider. The blockchain does not include passenger names or any personal data, but the data structure of blocks 55 and 56 of the blockchain includes only the (unique) ticket number, along with other data such as who issued the ticket as a mobility service provider (e.g., pass issuer #1), the price of the ticket number associated with a particular passenger, and a travel log identifier.

[0109] For example, in this embodiment, the blockchain is open to other members of the consortium, but they can only see the ticket number, not the sensitive data of the passenger (user). The blockchain does not contain any clues as to who the actual passenger is. Only the ticket or pass issuer (or MaaS service provider) can identify the actual passenger's name and ID. This is because sensitive information stored in the database is separated from the blockchain and associated with the ticket number.

[0110] However, it is generally known that passenger name records (PNRs) may be required in the transportation or tourism industries (see also Wikipedia https: / / en.wikipedia.org / wiki / Passenger_name_record).

[0111] Therefore, for example, if the name on the airline ticket does not match the name on the passport, boarding is usually not permitted, so a booking system provided by a mobility service must retain the passenger's personal data.

[0112] In embodiments where the aforementioned off-chain technology is applied, a blockchain member requests necessary information from a MaaS provider that has the passenger's personal data, for example, based on the ticket number or other identified information associated with the passenger.

[0113] However, in some embodiments, off-chain technology cannot be applied, and therefore, in some embodiments, passenger personal data within the blockchain is subject to pseudonymization and / or anonymization (see below).

[0114] The following describes embodiments of pseudonymization and anonymization of personal data in blockchain technology.

[0115] As mentioned above, if personal data such as passenger names needs to be included in a blockchain block, then the name (or other personal data) should be protected.

[0116] In some embodiments, personal data is replaced, and a typical method of pseudonymization is to replace sensitive parts with letters or numbers, or with zero-padding, or to delete them. In some embodiments, personal data is deleted, for example, by using initials or other acronyms instead of a full name, or by using a user ID number instead of a full name. However, personal information may still be inferred or derivable, and / or user information may be traceable from other information.

[0117] Further embodiments of pseudonymization and anonymization will be described below.

[0118] In some embodiments, scrambling (masking) is performed, which is also shown in Figure 9, where a method 60 of kanaization with scrambling is shown.

[0119] The input data 61 is divided into two parts: an unprotected part 62 containing pass issuer information and a protected part 63 containing personal data, namely the passenger ID.

[0120] The data from the protected portion 62 is input as a stream to the scrambling process 64 ("+"). In the scrambling process 64, the protected data 62 and the scrambling code 65 are applied to each other (mathematically by Ex-OR calculation). The pseudonymized passenger data 66 is generated as output data, which is combined with the unprotected portion 62 as output 67.

[0121] This means that other members within the consortium (e.g., mobility service providers) cannot identify the actual user in the blockchain after scrambling, but only, for example, a pass issuer (who knows the scrambling code, or any other entity that knows the scrambling code) can descramble and unmask the passenger ID.

[0122] In general, various methods exist for generating scrambling codes, and this disclosure is not limited to any particular implementation in that respect. In some embodiments, a linear feedback shift register (LFSR) is used. In some embodiments, the scrambling code can also be constructed, and it is selected from a large number of candidate codes, similar to an encryption key.

[0123] In some embodiments, scrambling techniques enable simple hardware / software algorithms, and scrambling is typically reversible (at least as long as the scrambling code is available). If necessary, data can be descrambled by the original source of the data.

[0124] However, in some embodiments, reversibility may not be required. For example, if there is a malicious member among the blockchain members, it may be possible to identify the user ID and obtain information, and therefore, in some embodiments, an irreversible embodiment is required.

[0125] The following describes an embodiment that utilizes key-based encryption. In principle, scrambling and encryption are similar processes, but their purposes and designs differ.

[0126] The primary purpose of scrambling is a data mask, where no key exists, only a code number is set (i.e., the initial value of a shift register). If someone accidentally sets the same code, it is easy to descramble the data. Furthermore, data scrambling can be vulnerable to trying all possible combinations, i.e., descrambling can be possible based on a brute-force attack. However, scrambling typically involves only a light processing load and is easy to handle, and as a result, in some embodiments, it is performed among trusted members, for example, in a consortium of trusted members.

[0127] On the other hand, the primary purpose of encryption is to provide data secretly. Encryption algorithms are generally open to everyone, and for example, a public key (in the case of PKI) can be used for decryption. This is particularly useful for public / untrusted groups, such as on the internet.

[0128] However, encryption can involve heavy processing loads and complex algorithms for decryption, and may not be freely available, although it can be protected, for example, under intellectual property conditions.

[0129] As mentioned above, the GDPR requires irreversible processing of anonymized data. For example, if data is made openly available to a third party, personal data must be anonymized.

[0130] One embodiment of the data anonymization method 70 is shown in Figure 10, in which a hash function 71 is used for data anonymization.

[0131] Generally, a hash function is any function that can be used to map input data to output data using a specific algorithm. The size of the input data can be large and varied, while the output data can be compact and have a fixed size.

[0132] The inputs to the hash function 71 are personal data 72 (or any protected data as required) and a hash salt 73 (or any initialization random value).

[0133] The output of the hash function is anonymized personal data 74, which is a unique value response to the input value, and this hash output 74 cannot be reversed.

[0134] In some embodiments, the salt 73 is stored and protected separately.

[0135] In some embodiments, the salt key is changed each time, for example, on the application, to enhance anonymity, because the output is different even if the input is the same user ID again, i.e., a different salt is used.

[0136] Therefore, in this embodiment, data anonymization is irreversible due to the use of hashing, which also leads to handling difficulties. This untraceability is suitable for complete anonymization, and in some embodiments, it is impossible to access the original data after the hash output.

[0137] Therefore, this method 70 is particularly useful in some embodiments for permanently deleting personal data, for example, when the data is provided to a third party for statistical / big data analysis.

[0138] As described above, some embodiments relate to access control to a distributed ledger or blockchain.

[0139] A general advantage of distributed ledgers is that all members can access the distributed database. However, personal information should be protected and, in some embodiments, should not be shared without restriction; therefore, in some embodiments, data access is restricted depending on the purpose of data use.

[0140] Generally, access control may include and / or have the following features (either individually or in combination), depending on the purpose of the data's use:

[0141] • Pass issuers or other mobility service providers responsible for service enrollment: As explained above, such providers possess sensitive customer / passenger information regarding service enrollment / purchase. This sensitive information, including personal data, must be protected and requires pseudonymization in order to be written to a blockchain block.

[0142] • Ticket issuer / transportation provider: The ticket issuer / transportation provider will hold relevant information in accordance with transportation regulations. The required information may vary depending on the type of transportation (e.g., air, rail, bus, etc.) and the type of ticket (e.g., registered passengers only). The transportation provider will not access unnecessary information. In this case, pseudonymization is required to write it to a blockchain block.

[0143] • Data analysis by third parties: Third parties must not access sensitive information. Therefore, third parties must not be able to identify personal information, nor should they access pseudonymized data. Thus, in this case, anonymization is required before data access.

[0144] • Passengers: Passengers have the right to control and delete their own information, but they are not permitted to access other passengers' information, nor can they directly access the blockchain or distributed ledger.

[0145] • Emergency Public Safety: In the event of an emergency, public safety authorities can access full passenger information. Accessing full passenger information requires a special encryption key.

[0146] As described above, in some embodiments, permissioned blockchains are implemented, and in a permissioned blockchain, such as a consortium, only authorized entities can access the distributed ledger / blockchain.

[0147] Theoretically, the security level of a consortium is higher than that of a public blockchain. However, in some embodiments, encryption with separate keys is also beneficial for access control.

[0148] Next, with reference to Figure 11, one embodiment of method 80 for controlling access to the blockchain using encryption will be described.

[0149] Firstly, sensitive data should be encrypted with a first key 81 (master key) known only to the MaaS provider contracted with the user associated with the user profile data. This key should not be shared with other MaaS providers or third parties except in emergencies. Therefore, the data will not be shared with other users. Since this key is not distributed to external servers / networks, private key encryption is preferred in this embodiment. The user management function 82 has a user profile management function 82a and a passenger travel management function 82b, and passenger travel data (sensitive data) and passenger travel data (non-sensitive data) can also be separated from each other and processed separately.

[0150] The user management function 82 communicates with the blockchain management function 83, and the blockchain management function 83 communicates with one or more blockchains 84.

[0151] In this embodiment, a firewall 85 is provided between the user management function 82 and the blockchain management function 83 to protect sensitive data, and the user management function 82 and the blockchain management function 83 can be located on different entities, for example, different servers or other computing devices. As described above, the master key 81 is used to encrypt the sensitive data so that the sensitive data is protected through the firewall 85 and encryption.

[0152] Secondly, the MaaS provider generates a second key 86 (service provider key). This second key 86 can be shared with other MaaS providers and can be used to encrypt data stored in blocks within the blockchain 84 by the blockchain management function 83.

[0153] If the members with access to Blockchain 84 are highly trusted, and the number of members is not very large, or (for example, in a consortium) the members do not change frequently, then private key encryption remains preferable.

[0154] For example, the same key can be used for a long period of time. Alternatively, in some embodiments, it may be possible to simply use scrambling with a specific keyless sequence generator, which avoids key distribution in such cases.

[0155] Public-key cryptography should be used if members cannot be trusted, or for specific reasons such as the blockchain being stored overseas.

[0156] Other mobility service providers also access blockchain 84 via a blockchain management function 87, which is separated from third-party blockchain management functions 88 via a firewall 89.

[0157] Furthermore, a third key 90 is provided, which is shared with a third party, allowing the third party to access the blockchain information protected by the third key 90.

[0158] Here, the principles of data protection in blockchain will be explained in more detail with reference to Figure 12.

[0159] Here, as mentioned above, we assume that MaaS operator 95 has a contract with the passengers, and therefore MaaS operator 95 also possesses sensitive information and data about the passengers.

[0160] The transport operator / transport operator #1 issues ticket 96 based on the MaaS operator contract with the passenger, but transport operator #1 does not have detailed information about the passenger.

[0161] The MaaS operator possesses detailed passenger information, i.e., sensitive information, and inserts this information into the ticket issued by the transport operator #1, where it is encrypted using the public key encryption of the specific transport operator, in this case transport operator #1. This information is stored in the block containing ticket 96 on the blockchain, as described above.

[0162] As can be seen from Figure 12, in this embodiment, each transportation operator is provided with its own public key, and it is assumed here that the MaaS operator possesses all the public keys in advance.

[0163] Transportation company / operator #1 can decrypt the protected data within the block received from the blockchain using its own private key. This private key is not shared with other transportation companies.

[0164] Therefore, in this embodiment, other carriers or third parties can access the blocks, but they cannot decrypt the protected data because their secret keys are different.

[0165] In some embodiments, the data is, in principle, open data. Therefore, the third key (see Figure 11) should be shared with other third parties for data analysis (e.g., statistics, big data analysis, etc.).

[0166] The following describes embodiments of open data access for third parties, with reference to Figure 13.

[0167] Here, generally, the transport operator has a third-party public key 100 for open data. The third-party private key 100 is shared with multiple third parties who wish to use the data for data analysis. Transport operator #1 inserts the data into a block designated as block 101, along with encryption of the open data based on the third-party key. One or more third parties can decrypt the open data using the third-party private key 100 for the purpose of open data, but as described above, they cannot decrypt protected data that has been encrypted using a private key known only to the mobility service provider, for example.

[0168] When two or more third-party keys are used, in some embodiments, it is possible to implement multilevel access control (depending on the level of data sensitivity) or access control for a specific group (depending on the group to which the third party belongs).

[0169] In some embodiments, protected data (i.e., sensitive data) within a block can be anonymized. For example, as shown in Figure 14, in some embodiments, anonymized data and open data are combined within the blockchain.

[0170] Here, the transport operator #1 (ticket issuer) generates anonymized data (e.g., passenger name) using salting and hashing methods, as explained with reference to Figure 10, and inputs it into block 105 for the blockchain. This block 105 also contains open data (e.g., destination) encrypted with a third public key. Furthermore, the ticket number and ticket issuer #1 are stored in the block, as explained earlier.

[0171] The third public / private key is shared with others and can be used to decrypt the open data within block 105, but the anonymized data cannot be decrypted or identified, as described above.

[0172] Some embodiments relate to application programming interfaces (APIs), such as API 110 shown in Figure 15.

[0173] Figure 15 is essentially a correspondence to Figure 11, with the same reference numerals indicating the same entities and functions. The only difference between the embodiment in Figure 11 and the embodiment in Figure 15 is that the embodiment in Figure 15 provides a database 110 for big data, which also provides an API that can be accessed by third parties for the big data analytics function 111.

[0174] The transportation statistics / data stored in the big data database 110 can be useful for public and commercial purposes. For example, the government can use the data for urban planning, and private companies can use the data to determine the location of new stores. The big data of this embodiment is generally accessible, and the data is available through a broader open application interface (API) 110 for third parties.

[0175] On behalf of the mobility service provider, the mobility service provider or a trusted database provider stores data in database 110 without sensitive information. The mobility service provider or trusted database provider provides an API 110 to external third parties to access the database. External third parties can access database 110 without a key (optionally with a key).

[0176] API110 may include identity verification to prevent malicious access. For example, the API may support authentication protocols such as OAuth2.0 (RFC6749)(https: / / oauth.net / 2 / ).

[0177] In some embodiments, sensitive data can be removed from the blockchain, and embodiments relating to the removal of sensitive data will be described below with reference to Figures 16 and 17.

[0178] Generally, blockchain is designed to permanently store data, and therefore, it is implemented in a way that prevents data from being erased.

[0179] In the first embodiment, also shown in Figure 17, the sensitive data or erased data is retained in the blockchain by the method 115 for erasing sensitive data from the blockchain, but the key is invalidated.

[0180] However, even if the data is held within the blockchain, if there is no key to decrypt it, it is equivalent to erasing the data. However, this is not erasure in the strict sense, because the data still exists, but it can no longer be decrypted.

[0181] In this embodiment, it is assumed that there is a blockchain host manager 116 (typically a MaaS provider that contracts with passengers). One member requests data deletion at 117, while other members have the blockchain and a key for decrypting the data.

[0182] In other words, the procedure for Method 115 is as follows:

[0183] In 117, as described above, one or more members of the consortium of mobility service providers request host 116 to delete personal data (or any sensitive data) within the block.

[0184] Host 116 sends / distributes a request to invalidate the key to other blockchain members of the consortium at 118.

[0185] At 119, the other blockchain members delete the key, and at 120, they send an acknowledgment to host 116.

[0186] In step 121, the host sends a confirmation of data erasure to the requester.

[0187] Various methods exist for invalidating a key. In some embodiments, the key may have a timer or expiration time / date and time (or the data itself may have an expiration time timer), and the key may be automatically deleted after the time / date and time expires, or the decryption algorithm may reject the key after the time / date and time expires.

[0188] Another embodiment of method 125 for erasing sensitive data from a blockchain is shown in Figure 17, where the blockchain is erased after the agreement of the consortium members, and the same reference codes indicate the same entities and functions or method steps.

[0189] An advantage of permissioned blockchains (consortium type) is that members of the consortium can freely manage the blockchain.

[0190] As already described in the embodiment shown in Figure 16, we assume that there is a blockchain management host 116 (typically a MaaS provider that contracts with passengers).

[0191] One member of the consortium requested that the (sensitive) data be erased, while another member possessed the blockchain and the associated keys.

[0192] Therefore, the flow is as follows:

[0193] In 117, one (or more) members request that host 116 delete personal data (or any sensitive data) within the block.

[0194] In 118', host 116 sends / distributes a block deletion request to other blockchain members, which may delete a specific part of a block, multiple blocks, or all parts of the blockchain (i.e., the entire blockchain).

[0195] Other blockchain members check whether the request is acceptable. If it is acceptable, 126 sends a consensus command to host 116. For example, if the revenue sharing calculation is not yet complete, other members can send a reject or wait command.

[0196] At step 127, it is checked whether there is a consensus based on the command received at step 126. If there is a consensus to delete the block, the host sends / distributes the respective command 127a to delete the block; otherwise, the blockchain is not erased. Each member deletes the block according to the command at step 127b.

[0197] At step 128, the member sends a successful response regarding the block deletion to host 116, and at step 129, the host sends a confirmation of data erasure to the requester.

[0198] Generally, as mentioned above, data anonymization using hash functions is known. An anonymization engine can convert user IDs and personal identifiers into anonymized data. The anonymized data can be aggregated and stored in a central module. Anonymization prevents individuals in the data from being identified by data miners. In some embodiments, as described herein, such anonymization is applied to blockchain or distributed ledger.

[0199] Furthermore, as mentioned above, it is generally known to store sensitive data on a blockchain or distributed ledger. However, in some embodiments of this disclosure, the data is divided into sensitive and non-sensitive parts, and the sensitive parts are not stored on the blockchain.

[0200] Hereinafter, one embodiment of the general-purpose computer 130 will be described with reference to Figure 18. The computer 130 can be implemented to function as any type of network equipment, such as a base station or a new radio base station, a transmit / receive point, or a communication device such as a user equipment (end) terminal device, as described herein. The computer has components 131 to 141 that can form any one of the circuits of network equipment and communication equipment, as described herein.

[0201] Embodiments of performing the methods described herein using software, firmware, programs, etc., can be installed on a computer 130, which are then configured to suit specific embodiments.

[0202] The computer 130 has a CPU (Central Processing Unit) 131 that performs various procedures and methods as described herein according to a program stored in a recording medium 140 that is loaded into a ROM (Read-Only Memory) 132, stored in a storage unit 137, loaded into a RAM (Random Access Memory) 133, and loadable into each drive unit 139.

[0203] The CPU 131, ROM 132, and RAM 133 are connected to a bus 141, which is connected to an input / output interface 134. The number of CPUs, memory, and storage are merely illustrative, and those skilled in the art will understand that the computer 130 can be adapted and configured to meet specific requirements that arise when it functions as a base station or user equipment (end terminal).

[0204] Several components are connected to the input / output interface 134, including an input unit 135 into which a recording medium 140 (such as a compact disc, digital video disc, or compact flash memory) can be inserted, an output unit 136, a storage unit 137, a communication interface 138, and a drive unit 139.

[0205] The input unit 135 can be a pointing device (mouse, graphic table, etc.), a keyboard, a microphone, a camera, a touchscreen, etc.

[0206] The output unit 136 can be a display (liquid crystal display, cathode ray tube display, light-emitting diode display, etc.), a speaker, etc.

[0207] The memory unit 137 can be a hard disk, a solid-state drive, or the like.

[0208] The communication interface 138 can be configured to communicate via, for example, a local area network (LAN), wireless LAN (WLAN), mobile telecommunications system (GSM, UMTS, LTE, NR, etc.), Bluetooth, infrared, etc.

[0209] Please note that the above description pertains only to the configuration example of computer 130. Alternative configurations may be implemented using additional or other sensors, storage devices, interfaces, etc. For example, the communication interface 138 may support other radio access technologies other than UMTS, LTE, and NR mentioned.

[0210] When computer 130 functions as a base station, the communication interface 138 may further have air interfaces (e.g., providing the E-UTRA protocol OFDMA (downlink) and SC-FDMA (uplink)) and network interfaces (e.g., implementing protocols such as S1-AP, GTP-U, S1-MME, X2-AP). Furthermore, computer 130 may have one or more antennas and / or antenna arrays. This disclosure is not limited to any specificity of such protocols.

[0211] Referring to Figure 19, embodiments of user equipment UE150 and eNB155 (or NReNB / gNB), and the communication path 154 between UE150 and eNB155 used to implement embodiments of the present disclosure will be described. UE150 is an example of a communication device, and eNB is an example of a base station (i.e., network equipment), but this disclosure is not limited thereto.

[0212] The UE150 comprises a transmitter 151, a receiver 152, and a control unit 153. Here, the technical functions of the transmitter 151, receiver 152, and control unit 153 are generally well known to those skilled in the art, so a detailed description thereof is omitted.

[0213] The eNB155 comprises a transmitting unit 156, a receiving unit 157, and a control unit 158. Here again, the functions of the transmitting unit 156, the receiving unit 157, and the control unit 158 ​​are generally well known to those skilled in the art, so a detailed explanation will be omitted.

[0214] The communication channel 154 has an uplink path 154a from UE150 to eNB155 and a downlink path 154b from eNB155 to UE150.

[0215] During operation, the control unit 153 of the UE150 controls the reception of downlink signals via the downlink path 154b using the receiving unit 152, and the control unit 153 controls the transmission of uplink signals via the uplink path 154a using the transmitting unit 151.

[0216] Similarly, during operation, the control unit 158 ​​of the eNB155 controls the transmission of downlink signals via the downlink path 154b through the transmitter unit 156, and the control unit 158 ​​controls the reception of uplink signals via the uplink path 154a in the receiver unit 157.

[0217] To summarize further, as is clear from the description, some embodiments relate to a communication network node that provides data to a distributed ledger, wherein the node has a circuit configured to separate sensitive user data (e.g., passengers, names, addresses, telephone numbers, gender, age, passport numbers, credit card numbers, etc.) from non-sensitive user data (e.g., travel data or travel statistics, etc.) and to provide a user data management unit for providing non-sensitive user data to the distributed ledger. The communication network node may be network equipment such as a base station or eNodeB, but the node may also be configured as a communication device such as a user device, (end) terminal device, etc. (e.g., a mobile phone, smartphone, computer, laptop, notebook, etc.) having a circuit configured accordingly.

[0218] In some embodiments, the circuit is further configured to store sensitive user data in a node's database, and therefore the node may include a database or be connected to or associated with a database.

[0219] In some embodiments, the distributed ledger includes (or is) a blockchain, the blockchain may include multiple blocks, and the blocks may include non-sensitive user data.

[0220] Therefore, in some embodiments, sensitive user data is stored only in the node's database, and the distributed ledger or blockchain contains only non-sensitive data.

[0221] In some embodiments, the distributed ledger includes data for mobility services.

[0222] In some embodiments, access to a distributed ledger is granted on an authorization basis, and a node may be part of a consortium. The consortium may be provided by a mobility service provider, where each node may correspond to or be associated with, for example, one mobility service provider.

[0223] Some embodiments relate to a communication network having multiple nodes for providing a distributed ledger, wherein at least one node has a circuit configured to separate sensitive user data from non-sensitive user data and to provide a user data management unit for providing non-sensitive user data to the distributed ledger.

[0224] A communication network can be configured as a telecommunications network, and a telecommunications network can be configured as a mobile telecommunications network. The nodes of the communication network may be configured to provide a distributed ledger.

[0225] In some embodiments, as described above, the circuit is further configured to store sensitive user data in a node database.

[0226] As described above, a distributed ledger can include a blockchain, a blockchain can include multiple blocks, a block can include non-sensitive user data, and a distributed ledger can include data for mobility services. Therefore, in some embodiments, a communication network and its nodes are configured to provide MaaS.

[0227] In some embodiments, access to a distributed ledger is granted on an authorization basis, and the node may be part of a consortium (e.g., a MaaS consortium).

[0228] In some embodiments, personal user data in the distributed ledger (e.g., name or other data that could uniquely identify a user) is pseudonymized or anonymized. As mentioned above, personal user data can be entered into the distributed ledger, for example, in the case of an airline ticket, since the passenger name is known for boarding.

[0229] In some embodiments, personal user data may be pseudonymized by scrambling sensitive user data, and personal user data may be anonymized based on the application of a hash algorithm.

[0230] In some embodiments, access control to non-sensitive data is provided, and the access control may be performed based on a key, which is used to encrypt the non-sensitive data.

[0231] In some embodiments, access control provides different keys to different entities so that each entity has access at a different level. These different entities may be, for example, nodes with sensitive data, other nodes accessing the distributed ledger (which may be part of a consortium), third parties without sensitive data, third parties without access to the distributed ledger, or third parties that are not part of a consortium and do not provide MaaS or simply need the data for data analysis.

[0232] In some embodiments, access control enables access to non-sensitive data via an application program interface.

[0233] In some embodiments, personal user data or non-sensitive user data can be erased upon request from at least one node, and the data can be erased by invalidating the key or by erasing the data from the distributed ledger (including erasing all data). As described above, the distributed ledger may include a blockchain, and at least one block can be erased (including the personal data to be erased).

[0234] Some embodiments relate to a method for controlling a communication network having multiple nodes for providing a distributed ledger, as described herein, which includes providing a user data management section for separating sensitive user data from non-sensitive user data and providing non-sensitive user data to the distributed ledger, as detailed above. For example, all steps described herein, performed by the communication network and / or communication network nodes, may be part of such method.

[0235] In some embodiments, the methods described herein can also be implemented as computer programs that cause a computer and / or processor and / or circuit to perform the methods when executed on a computer and / or processor and / or circuit. In some embodiments, a non-temporary computer-readable recording medium is also provided for storing a computer program product that causes the methods described herein to perform when executed by a processor such as the aforementioned processor.

[0236] It should be understood that the embodiments describe a method with an illustrative sequence of method steps. However, the specific sequence of method steps is for illustrative purposes only and should not be construed as binding.

[0237] All units and entities described herein and claimed in the appended claims may be implemented, for example, as integrated circuit logic on a chip, unless otherwise stated, and the functions provided by such units and entities may be implemented by software, unless otherwise stated.

[0238] To the extent that the embodiments of the disclosure described above are carried out using a software-controlled data processing device, it will be understood that a computer program providing such software control, and a transmission device, storage, or other medium providing such a computer program, are assumed to be embodiments of the disclosure.

[0239] Furthermore, this technology can also be configured as follows. (1) A communication network node for providing data to a distributed ledger, We provide a user data management unit to separate sensitive user data from non-sensitive user data. The above non-sensitive user data is provided to the above distributed ledger. Circuit configured in such a way has A communication network node. (2) A communication network node as described in (1), The above circuit is further configured to store the above sensitive user data in the database of the above node. A communication network node. (3) A communication network node as described in (1) or (2), The above distributed ledger includes blockchain. A communication network node. (4) A communication network node as described in (3), The above blockchain includes multiple blocks containing the above non-sensitive user data. A communication network node. (5) A communication network node as described in any one of paragraphs (1) to (4), The above distributed ledger includes data for MaaS (Mobility as a Service). A communication network node. (6) A communication network node as described in any one of paragraphs (1) through (5), This is permitted based on the access permission to the distributed ledger mentioned above. A communication network node. (7) A communication network node as described in (6), The above nodes are part of the consortium. A communication network node. (8) A communication network having multiple nodes for providing a distributed ledger, At least one of the above multiple nodes is We provide a user data management unit to separate sensitive user data from non-sensitive user data. The above non-sensitive user data is provided to the above distributed ledger. Having a circuit configured in such a way Communication network. (9) The communication network described in (8), The above circuit is further configured to store the above sensitive user data in the database of the above node. Communication network. (10) A communication network as described in (8) or (9), The above distributed ledger includes blockchain. Communication network. (11) The communication network described in (10), The above blockchain includes multiple blocks containing the above non-sensitive user data. Communication network. (12) A communication network as described in any one of paragraphs (8) through (11), The above distributed ledger includes data for MaaS (Mobility as a Service). Communication network. (13) A communication network as described in any one of paragraphs (8) through (12), This is permitted based on the access permission to the distributed ledger mentioned above. Communication network. (14) The communication network described in (13), The above nodes are part of the consortium. Communication network. (15) A communication network as described in any one of paragraphs (8) through (14), The personal user data in the above distributed ledger will be pseudonymized or anonymized. Communication network. (16) The communication network described in (15), The above personal user data is pseudonymized by performing scrambling on the above sensitive user data. Communication network. (17) The communication network described in (15), The above personal user data will be anonymized by applying a hash algorithm. Communication network. (18) A communication network as described in any one of paragraphs (8) through (17), Access control will be implemented for the above non-sensitive data. Communication network. (19) The communication network described in (18), The above access control is performed based on the key used to encrypt the above non-sensitive data. Communication network. (20) The communication network described in (19), The access control described above provides different keys to different organizations. Communication network. (21) A communication network as described in any one of paragraphs (18) through (20), The above access control allows access to the non-sensitive data via the application programming interface. Communication network. (22) A communication network as described in any one of paragraphs (8) through (21), Personal user data or the aforementioned non-sensitive user data can be deleted upon request from at least one node. Communication network. (23) The communication network described in (22), The data will be erased by invalidating the key. Communication network. (24) The communication network described in (22), The above data will be deleted by removing it from the distributed ledger mentioned above. Communication network. (25) The communication network described in (24), The above distributed ledger includes a blockchain, and at least one block is deleted. Communication network. (26) A method for controlling a communication network having multiple nodes for providing a distributed ledger, A user data management unit is provided to separate sensitive user data from non-sensitive user data. The above non-sensitive user data is provided to the above distributed ledger. method. (27) The method described in (26), further The sensitive user data mentioned above is stored in the node's database. method. (28) The method according to (26) or (27), The above distributed ledger includes blockchain. method. (29) The method described in (28), The above blockchain includes multiple blocks containing the above non-sensitive user data. method. (30) The method described in any one of paragraphs (26) to (29), The above distributed ledger includes data for MaaS (Mobility as a Service). method. (31) The method described in any one of paragraphs (26) to (30), This is permitted based on the access permission to the distributed ledger mentioned above. method. (32) The method described in (31), The above nodes are part of the consortium. method. (33) The method described in any one of paragraphs (26) through (32), The personal user data in the above distributed ledger will be pseudonymized or anonymized. method. (34) The method described in (33), The above personal user data is pseudonymized by performing scrambling on the above sensitive user data. method. (35) The method described in (33), The above personal user data will be anonymized by applying a hash algorithm. method. The method according to any one of (36) to (35), wherein access control for the non-confidential data is executed Method. The method according to (37) (36), wherein the access control is executed based on a key used for encrypting the non-confidential data Method. The method according to (38) (37), wherein different keys are provided to different groups by the access control Method. The method according to any one of (39) (36) to (38), wherein access to the non-confidential data is enabled via an application programming interface by the access control Method. The method according to any one of (40) (26) to (39), wherein personal user data or the non-confidential user data is erasable in response to a request from at least one node Method. The method according to (41) (40), wherein data is erased by invalidating the key Method. The method according to (42) (40), wherein the data is erased by deleting the data from the distributed ledger Method. The method according to (43) (42), wherein the distributed ledger includes a blockchain and at least one block is erased Method.

Claims

1. A communication network node for providing data to a distributed ledger, The aforementioned distributed ledger includes data for MaaS (Mobility as a Service), It has a database and a circuit. The aforementioned circuit is We provide a user data management unit to separate sensitive user data from non-sensitive user data. Provide the sensitive user data to be stored in the database, The aforementioned non-sensitive user data is provided to the distributed ledger, Of the aforementioned sensitive user data, the personal information of the passengers who are users is irreversibly pseudonymized or anonymized. Provide the aforementioned personal information, which has been irreversibly pseudonymized or anonymized, to be added to the MaaS data. It is configured to A communication network node.

2. A communication network node according to claim 1, The aforementioned distributed ledger includes blockchain. A communication network node.

3. A communication network node according to claim 2, The blockchain includes multiple blocks containing the non-sensitive user data. A communication network node.

4. A communication network node according to claim 1, Access to the aforementioned distributed ledger is permitted based on authorization authority. A communication network node.

5. A communication network node according to claim 4, The aforementioned communication network node is part of the consortium. A communication network node.

6. A communication network having multiple nodes for providing a distributed ledger, The aforementioned distributed ledger includes data for MaaS (Mobility as a Service), At least one of the plurality of nodes is It has a database and a circuit. The aforementioned circuit is We provide a user data management unit to separate sensitive user data from non-sensitive user data. Provide the sensitive user data to be stored in the database, The aforementioned non-sensitive user data is provided to the distributed ledger, Of the aforementioned sensitive user data, the personal information of the passengers who are users is irreversibly pseudonymized or anonymized. Provide the aforementioned personal information, which has been irreversibly pseudonymized or anonymized, to be added to the MaaS data. It is configured to Communication network.

7. A communication network according to claim 6, The aforementioned distributed ledger includes blockchain. Communication network.

8. A communication network according to claim 7, The blockchain includes multiple blocks containing the non-sensitive user data. Communication network.

9. A communication network according to claim 6, Access to the aforementioned distributed ledger is permitted based on authorization authority. Communication network.

10. A communication network according to claim 9, The aforementioned node is part of the consortium. Communication network.

11. A communication network according to claim 6, Access control is performed on the aforementioned non-sensitive user data. Communication network.

12. A communication network according to claim 11, The access control is performed based on the key used to encrypt the non-sensitive user data. Communication network.

13. A communication network according to claim 11, The aforementioned access control provides different keys to different organizations. Communication network.

14. A communication network according to claim 11, The aforementioned access control allows access to the non-sensitive user data via the application programming interface. Communication network.

15. A method for controlling a communication network having multiple nodes for providing a distributed ledger, The aforementioned distributed ledger includes data for MaaS (Mobility as a Service), A user data management unit is provided to separate sensitive user data from non-sensitive user data. The sensitive user data is provided to be stored in a database. The aforementioned non-sensitive user data is provided to the distributed ledger, Of the aforementioned sensitive user data, the personal information of the passengers who are users is irreversibly pseudonymized or anonymized. Provide the aforementioned personal information, which has been irreversibly pseudonymized or anonymized, to be added to the MaaS data. method.

16. The method according to claim 15, The aforementioned distributed ledger includes blockchain. method.

17. The method according to claim 16, The blockchain includes multiple blocks containing the non-sensitive user data. method.

18. The method according to claim 15, Access to the aforementioned distributed ledger is permitted based on authorization authority. method.

19. The method according to claim 18, The aforementioned node is part of the consortium. method.

20. The method according to claim 15, Access control is performed on the aforementioned non-sensitive user data. method.

21. The method according to claim 20, The access control is performed based on the key used to encrypt the non-sensitive user data. method.

22. The method according to claim 21, The aforementioned access control provides different keys to different organizations. method.

23. The method according to claim 21, The aforementioned access control allows access to the non-sensitive user data via the application programming interface. method.

Images