Privacy-preserving mobile-as-a-service powered by blockchain

Abstract

The present disclosure provides a communication network node for providing data to a distributed ledger, wherein the node has a circuit configured to: provide a user data management part for separating sensitive user data from non-sensitive user data; and provide the non-sensitive user data to the distributed ledger.

Description

Technical Field

[0001] The present disclosure generally relates to a communication network node, a communication network, and a method for providing a distributed ledger. Background Art

[0002] Generally, it is known to distribute a ledger on multiple nodes such as an entity (e.g., an electronic device recording digital transactions, a server, etc.). The distributed ledger can be based on the known blockchain technology, for example, the known cryptocurrency is based on this blockchain technology, and can also be based on the well-known Ethereum project, etc. Generally, the distributed ledger can also be implemented on other technologies besides the blockchain technology, and examples of distributed ledger projects that are not based on the blockchain are BigchainDB and IOTA, etc. For example, IOTA is a cryptocurrency that uses linked lists.

[0003] Furthermore, Mobility as a Service (MaaS) is known, where a user or passenger uses Mobility as a Service without owning, for example, a car etc. Mobility as a Service may combine public (e.g., trains, buses etc.) and private (e.g., car sharing, bike sharing etc.) transportation services from associated operators or providers.

[0004] Known MaaS solutions usually involve a central and unified gateway through which trips or journeys are planned and booked, wherein users can pay through a single account.

[0005] Although technologies exist for providing distributed ledgers and mobility as a service, it is generally desirable to provide a communication network node, a communication network, and a method for controlling a communication network to provide a distributed ledger. Summary of the invention

[0006] According to a first aspect, the present disclosure provides a communication network node for providing data to a distributed ledger, wherein the node comprises a circuit configured to provide a user data management portion for separating sensitive user data from non-sensitive user data; and provide the non-sensitive user data to the distributed ledger.

[0007] According to a second aspect, the present disclosure provides a communication network comprising a plurality of nodes for providing a distributed ledger, wherein at least one node comprises a circuit configured to provide a user data management portion for separating sensitive user data from non-sensitive user data; and provide the non-sensitive user data to the distributed ledger.

[0008] According to a third aspect, the present disclosure provides a method for controlling a communication network including a plurality of nodes for providing a distributed ledger, comprising: providing a user data management part for separating sensitive user data from non-sensitive user data; and providing the non-sensitive user data to the distributed ledger.

[0009] Further aspects are set out in the dependent claims, the following description and the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] Embodiments are described by way of example with reference to the accompanying drawings, in which:

[0011] Figure 1 A blockchain is schematically shown;

[0012] Figure 2 Schematically illustrating hashing in a blockchain;

[0013] Figure 3 is a flow chart illustrating an implementation of a consensus protocol;

[0014] Figure 4 shows the data flow in the MaaS system;

[0015] Figure 5 An embodiment of a blockchain including journey log data is shown;

[0016] Figure 6 An embodiment of a communication network for providing a blockchain is shown;

[0017] Figure 7 An implementation for separating sensitive data from non-sensitive data is shown;

[0018] Figure 8 A block of a blockchain including journey data is shown;

[0019] Fig. 9 Pseudonymization of passenger data is shown;

[0020] Fig.10 Anonymization of passenger data is shown;

[0021] Fig.11 An implementation of using different keys for data protection in a blockchain is shown;

[0022] Fig.12 shows the separation of non-sensitive data and sensitive data, wherein the sensitive data is protected;

[0023] Fig.13 shows third-party encryption of data;

[0024] Fig.14shows access to data by third parties, where sensitive data is anonymized;

[0025] Fig.15 An application programming interface for third-party access for big data analytics is shown;

[0026] Fig.16 A first implementation of erasing data from a blockchain by invalidating a key is shown;

[0027] Fig.17 A second embodiment of erasing data from a blockchain by erasing a block is shown;

[0028] Fig.18 An embodiment of a general-purpose computer is shown, on which a network device or a communication apparatus is implemented in some embodiments; and

[0029] Fig.19 An embodiment is shown in which an eNodeB and a user equipment communicate with each other. DETAILED DESCRIPTION

[0030] In reference Figure 1 Before giving a detailed description of the embodiments, a general description is given.

[0031] As mentioned at the beginning, generally, distributed ledgers and Mobility as a Service (MaaS) are known.

[0032] In some embodiments or aspects, the present disclosure generally relates to the application of blockchain / distributed ledgers for Mobility as a Service (MaaS) applications, in particular MaaS between more than one service provider (multimodal transportation).

[0033] In some embodiments or aspects, the present disclosure also generally relates to the application of a distributed ledger or blockchain as an example of a distributed ledger, without limiting the present disclosure to blockchain. According to some aspects of the present disclosure, the distributed ledger or blockchain is identified as suitable for Mobility as a Service (MaaS) applications because the distributed ledger requires a distributed database of journey history (or journey data) between multiple players (i.e., multiple Mobility as a Service providers).

[0034] In some embodiments, the MaaS blockchain may need to handle a large number of passengers, store various types of journey records, large block sizes, processing spikes during peak hours, etc.

[0035] In some embodiments, generally, a distributed ledger or blockchain is suitable for MaaS applications because it provides a distributed database of journey histories among multiple players.

[0036] However, personal data protection may be challenging for blockchain / distributed ledgers because personal data may generally be open to all members in the blockchain and the re-encoded data in the block cannot be deleted / modified by users.

[0037] Therefore, it has been recognized that in some embodiments, it may be useful to provide protection for user privacy using a blockchain-based distributed ledger, especially for MaaS applications. In addition, in some embodiments, the need to record a passenger's journey and protect the passenger's privacy may conflict with each other.

[0038] In some embodiments, the distributed ledger can be shared between players (including mobile service providers) and can even be immutable, in terms of an accurate record of a passenger's journey. In some embodiments, such a feature is suitable for record / evidence of journeys for things like revenue sharing calculations. Additionally, government transportation agencies may need to keep records of passenger information, especially for known air travel.

[0039] On the other hand, in some embodiments, the MaaS journey record may include sensitive passenger information, such as where, when, with whom, and what the passenger was doing. Therefore, anonymization and pseudonymization may be applied in terms of personal data protection. In some embodiments, there are requirements for protecting personal data, such as the General Data Protection Right (GDPR).

[0040] Therefore, in the present disclosure, some embodiments relate to the problem of how to protect personal data using access control and how to provide methods for anonymization and pseudonymization of passenger data.

[0041] Thus, in some embodiments, personal information is confined to an inaccessible portion of the system that may not be accessible to third parties. Furthermore, in some embodiments, confidentiality of the user profile / multimodal pass information is ensured by the mobile service provider with whom the user has a contract, while the user-specific ID is anonymized, for example, in a distributed ledger or blockchain. The journey log included in the distributed ledger or blockchain may be under access control and the contents of the journey log may be pseudonymized.

[0042] In the following, some definitions of terms that may be applied in some embodiments are given (without limiting the present disclosure to the definitions given below. Because the technical field of MaaS and distributed ledgers is highly dynamic and the definitions may change in the future, the definitions are merely provided to enhance the understanding of the present disclosure and are merely examples given).

[0043] The term “distributed ledger” can be obtained from Wikipedia, which defines it as: “A distributed ledger (also called a shared ledger or distributed ledger technology (DLT)) is a consensus of replicated, shared, and synchronized digital data that is geographically distributed across multiple locations, countries, or institutions. There is no central administrator or centralized data storage.”

[0044] The technology of distributed ledgers and their specific examples (i.e., blockchain) will be discussed further below. More generally, the term distributed ledger is used as a type of database that shares digitally recorded data with multiple nodes of a network. It can include a peer-to-peer network. The digitally recorded data can include information to prove its consistency from data previously recorded on the same database.

[0045] A distributed ledger may be public and accessible to anyone, but, in principle, it may also be non-public and accessible only to permitted users, where, as further explained below, a permitted group of entities, nodes, persons, operators, suppliers, etc. may also be referred to as a "consortium." It is also possible to differentiate access permissions to data on the ledger from each tier of users.

[0046] Distributed ledgers can use mechanisms known, for example, from blockchain technology for cryptocurrencies. Such mechanisms include discovery methods, consensus mechanisms, mechanisms for maintaining data consistency, etc. The consensus mechanism ensures that all nodes or more than a certain number of nodes (usually electronic devices) that have a copy of the distributed ledger reach a consensus on the content of the distributed ledger. There are many consensus mechanisms including the so-called proof-of-work mechanism, which is a kind of cryptographic puzzle and ensures that old blocks of, for example, a blockchain cannot be (easily) changed. For example, proof-of-work is used in the mining process of cryptocurrency blockchains.

[0047] In a distributed ledger or blockchain, the confirmation process (called mining process) of reaching consensus on data updates on the blockchain among participating nodes can achieve irreversibility of the sequence of transactions recorded on the blockchain by including previously recorded data in the confirmation data. Such a mining process implements a distributed timestamp server for new blocks of transactions. In cryptocurrency (and therefore in some embodiments), the mining process is based on the SHA-256 hash function. The nodes of the blockchain participating in the mining process search for a hash output with predefined properties, while the input of the hash function depends on the current block of the blockchain and the new block of transactions added to the blockchain.

[0048] Hash-based proof-of-work computations may not be useful in themselves, except insofar as they are needed to achieve irreversibility in the distributed ledger.

[0049] In addition, generally, it is known to use blockchain for storing various data. For example, images, videos, measurements, and text files can be recorded on the blockchain in the form of transactions.

[0050] The term "Mobility as a Service (MaaS)" is also known from Wikipedia, which defines: "Mobility as a Service (MaaS) describes the shift away from personally owned modes of transport and towards mobility solutions consumed as a service. This is achieved by combining transport services from public and private transport providers through a unified gateway that creates and manages trips, which users can pay for through a single account. Users can pay per trip or monthly for a limited distance. The key concept behind MaaS is to provide travellers with mobility solutions based on their travel needs."

[0051] As also described above, in some embodiments, a "public blockchain / distributed ledger" refers to a distributed database (ledger) that anyone can share and join to execute a consensus protocol.

[0052] In contrast, a "permissioned blockchain / distributed ledger" refers to a distributed database (ledger) in which only permitted members can share and participate in the consensus protocol. As described above, the permitted members that are granted permission to access the blockchain are called a "consortium". In some embodiments, a permissioned / consortium type blockchain is suitable for MaaS applications because it is not public and therefore no one can access it.

[0053] The term "(mobile) edge computing" can also be found on Wikipedia, where it is defined as: "Multi-access edge computing (MEC) (formerly mobile edge computing) is a network architecture concept that enables cloud computing capabilities and IT service environments at the edge of cellular networks[1][2] (and more generally, at the edge of any network). The basic idea behind MEC is that by running applications and performing related processing tasks closer to cellular clients, network congestion is reduced and applications perform better."

[0054] The term “northbound API” in the context of network virtualization is understood as a software-based interface (API) that telecom operators can use to configure network functions, and network operators can configure virtual infrastructure (e.g., virtual machines) and requested network functions / application functions.

[0055] The term "instance" is understood as a software process running on the cloud. It can be moved somewhere in the distributed cloud.

[0056] “Public cloud” can be defined as (https: / / azure.microsoft.com / en-gb / overview / what-are-private-public-hybrid-clouds / ): “Public cloud is the most common way to deploy cloud computing. It is owned and operated by a third-party cloud service provider and delivers cloud resources (such as servers and storage) over the Internet.”

[0057] In some embodiments, the following terms will be used with a given understanding:

[0058] The term "multimodal transport pass" may be a pass valid for multiple mobility services with specified conditions, such as validity period or available transport, unacceptable services, etc. For example, a day pass, a week pass, a monthly MaaS service subscription, a quarterly pass, etc.

[0059] The term "mobility service provider" may be a general term for any type of service provider MaaS. In some embodiments, it is typically a transport organization such as a railway company, bus / coach, tour and taxi, car sharing, ride sharing, bike sharing, etc. Some mobility service providers may not provide actual transport means, but may only provide booking / arrangement comparable to travel agencies or online booking sites, etc.

[0060] The term "pass" may be a transport pass or a travel card (UK) (see also https: / / en.wikipe-dia.org / wiki / Transit_pass). In the present disclosure, a multimodal pass shall also fall under the term "pass", which means that a pass may be valid between more than one transport operator (or mobility service provider) and, therefore, may cover not only public transport but also other types of mobility such as ride sharing, bike sharing, etc. A pass may include information on acceptable transport, validity period, and any other conditions for ticket issuance / transport ride. In some embodiments, MaaS may offer a monthly service subscription with certain options for service levels. A passenger or user may pay a service subscription fee or purchase a pass for a specified period from a pass issuer (which may typically be a mobility service provider issuing the pass). The pass may be issued by a transport operator or travel agency, a MaaS service provider, etc. (which, as mentioned above, may all fall under the term mobility service provider). Thus, as mentioned, some pass issuers may sell passes but may not provide actual transport services or means of transport.

[0061] The term "ticket" may be a ticket for a one-way journey of a specified segment, such as a one-way train ticket with (or without) seat reservation. In some embodiments, the ticket may be issued under a multimodal transport pass and its terms and conditions, and it may include information such as the selected transport, seat number, price, etc. In some embodiments, even if seat reservation is not required or unlimited travel is allowed, tickets may be issued for revenue sharing between multiple mobile service providers. In addition, the passenger (user) may not pay the ticket issuer directly, but the pass issuer may pay the ticket issuer instead of the passenger, and the ticket may be issued by a transport operator or service provider (i.e., a mobile service provider).

[0062] The term "journey log" may cover a journey log for a one-way journey record based on a ticket. It may include information about the location of the embankment, its time / day, the location of the alighting, its time / day, whether the ticket was used or not used, etc., as will be discussed further below.

[0063] The term "anonymization" can be defined according to Wikipedia (see also https: / / en.wikipedia.org / wiki / Data_anonymization): "Data anonymization is a type of information cleansing whose intent is privacy preservation. It is the process of encrypting or removing personally identifiable information from a data set so that the person described by the data remains anonymous."

[0064] The term "pseudonymization" can be defined according to Wikipedia (see also https: / / en.wikipedia.org / wiki / Pseudonymization): "Pseudonymization is a data management and de-identification process by which personally identifiable information fields within a data record are replaced with one or more artificial identifiers, or pseudonyms. The individual pseudonyms for each replaced field or set of replaced fields make the data record less identifiable while remaining suitable for data analysis and data processing."

[0065] The term "untraceable" may be understood as no one (e.g., no entity, user, person, etc.) can track the history of actions or behaviors. For example, it may be prevented that a user may be tracked where he went, what he did, or what he did not do on a given day / time.

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

[0067] In some embodiments, the term “personal data” may be understood in the sense (see for example https: / / gdpr-info.eu / art-4-gdpr / ): “(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, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person;”

[0068] “Pseudonymisation in the GDPR” can be understood accordingly: “(5) ‘Pseudonymisation’ means the processing of personal data in such a manner that the personal data can no longer be attributed to a specific data subject without the use of additional information, provided that such additional information is kept separately and is subject to technical and organisational measures to ensure that the personal data can no longer be attributed to an identified or identifiable natural person;”

[0069] In some embodiments, the term "public key cryptography" is understood to be also as defined in Wikipedia (https: / / en.wikipedia.org / wiki / Public-key_cryptography): "Public key cryptography, or asymmetric cryptography, is any cryptographic system that uses paired keys: a public key that can be widely disseminated and a private key that is known only to the owner. This enables two functions: authentication, where the public key verifies that the holder of the paired private key sent a message; and encryption, where only the holder of the paired private key can decrypt a message encrypted by the public key." Among them, "the two most well-known uses of public key cryptography are: public Secret key encryption, where a message is encrypted using the recipient's public key. Anyone who does not possess the matching private key cannot decrypt the message, and is therefore assumed to be the owner of that key and the person associated with the public key. This is used when trying to ensure confidentiality."; and "Digital signatures, where a message is signed using the sender's private key, and can be verified by anyone with access to the sender's public key. This verification proves that the sender has access to the public key, and is therefore likely the person associated with the public key. This also ensures that the message has not been tampered with, as the signature is mathematically bound to the message it was originally sent from, and in fact the verification will fail for any other message, no matter how similar it is to the original."

[0070] In some embodiments, the term "salt" is understood according to Wikipedia (https: / / en.wikipedia.org / wiki / Salt(cryptography)): "In cryptography, a salt is random data used as an additional input to a one-way function that "hashes" data, a password, or a passphrase. Salts are closely related to the concept of random numbers. The primary function of a salt is to defend against dictionary attacks or their hash equivalents (precomputed rainbow table attacks)."

[0071] In the following, a general overview of the description is given, wherein embodiments of four different aspects of the present disclosure will be discussed, which may be implemented or realized as independent aspects or may be combined with each other in any possible combination.

[0072] According to the first aspect, some implementations involving basic techniques are discussed, including sensitive data separation (utilizing off-chain techniques) and naive methods of pseudonymization and anonymization (utilizing scrambling and / or hashing).

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

[0074] According to a third aspect, some embodiments relate to erasure of sensitive data, including, for example, key invalidation and / or block erasure.

[0075] In the following, reference will be made to Figure 1 Describes the blockchain and its general data structure. In this implementation of the blockchain, the features are network / topology, consensus algorithm, hash function, participant authentication, scalability / block structure, and performance.

[0076] Figure 1 The general structure of blockchain 1 is shown. Blockchain 1 includes a chain of multiple data blocks 2a, 2b, and 2c, where block 2b is the current block (block #N), block 2a is the previous block (block #N-1), and block 2c is the future or successor block (block #N+1). Each block includes the hash function result of the previous block, the main data structure, the input value of the hash function, and the hash function result of the current block, where the hash function result of the current block (2b) is always used as the input of the next block (2c).

[0077] In addition, each block includes a "one-time use number", which is a one-time random number used for secure blockchain processing and can prevent replay attacks. For example, if an attacker copies previously sent data and reuses the copied data again to spoof, the recipient is able to detect the spoofed communication because the next data must be used with a different "one-time use number". In cryptography, this random number is sometimes called a "nonce".

[0078] Furthermore, a timestamp may be inserted in each of the blocks 2a, 2b and 2c. The blockchain 1 is an example of a distributed ledger, which in some embodiments may be used, for example, to provide MaaS.

[0079] Figure 2 For example, it is shown that Figure 1 The input and output of the hash function of blockchain 1.

[0080] In general, 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 may be large and varied, whereas the output of the data may be compact and may have a fixed size. A known (and well-known) algorithm used for hashing in some blockchain implementations is the Secure Hash Algorithm (SHA) designed by the United States National Security Agency (e.g., SHA-2, SHA-256).

[0081] The input to the hash function is the previous hash output, a one-time use number, and the current block (e.g. Figure 1 The output of the hash function is a unique value in response to the input value. If someone tries to tamper with the body of the data, the output of the hash function will not be consistent.

[0082] The embodiments of the distributed ledger (blockchain) in the present disclosure may implement a consensus protocol or algorithm. For example, in some embodiments, Byzantine Fault Tolerance (BFT) is used for the consensus protocol, which is resilient to database fraud and hardware failures.

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

[0084] In some implementations, a permissioned blockchain is used and a relatively small number of permissioned blockchain nodes manage consensus (validation of blocks).

[0085] Figure 3 The PBFT process 10 is shown as an example.

[0086] The leader node (also called a non-validating peer) requests other nodes to validate the blockchain at 11. At 12, each requesting node (validating peer) checks the validity of the blockchain using a hash function and indicates its result to other nodes at 13. At 14, the node receives the validity results from multiple other peers and checks the consensus of the blockchain if it receives a more valid result than a predefined criterion. If there is a consensus, at 15, the node writes / completes the blockchain. The leader peer checks the overall progress of the validity check in other nodes and completes the blockchain process at 16.

[0087] For resilience, in some embodiments the total number of nodes is greater than 3f+1, where f is the number of failed nodes allowed. For example, if f=1, there are 4 total nodes; if f=3, there are 10 total nodes, etc.

[0088] As discussed herein, in some embodiments, PBFT has a permissioned blockchain for a mobile services blockchain, providing, at least in part, the following features:

[0089] Regarding security, PBFT in some embodiments provides a low risk of 51% attacks, which is common for cryptocurrencies because the permissions of the peers responsible for consensus must be trusted. Regarding privacy, since only the mobile service provider processes the blockchain at the (peer) node (due to permission-based blockchains and end users may not have permission to access the blockchain), the end user cannot access the entire blockchain. Regarding performance, in some embodiments, due to a small number of peers with high performance, the processing time for consensus is very short. Regarding flexibility, in some embodiments, the block size and format of the blockchain can be flexible compared to public blockchains.

[0090] In the following, reference is made to the diagram showing the overall data flow. Figure 4 The data flow of the MaaS system 20 is described. In the MaaS system 20, it is assumed that the end user has his own terminal 21, such as a smartphone (or any other type of electronic (mobile) device). Some users (e.g., visitors from overseas) may not have a smartphone, etc., and in such a case, for example, a service based on Figure 4 An optional solution for the proxy function (proxy 22) in , which provides a portal for users.

[0091] Figure 4 A data flow diagram of a MaaS system 20 is shown, wherein three main parts are provided: an end user part on the left, a mobile service operator / provider part in the middle, and an other entity part on the right, wherein the end user part and the other entity part communicate with the mobile service provider part in the middle.

[0092] For this embodiment of the MaaS system 20, it is assumed that the mobility service provider has a user management function 23 with a web server or cloud for customer service and a user profile management function 23a and a passenger journey management function 23b. The mobility service provider further has a blockchain management function 24. The blockchain function 24 with the blockchain management function 24a communicates with the blockchain management functions 25 of other entity parts. If seat reservation / shared ride reservation is provided by a reservation center 26, a central reservation server / cloud is provided.

[0093] The end user communicates with his own terminal (ie, smartphone 21 in this embodiment) having an exemplary user interface and sensors (eg, GNSS, NFC, etc.).

[0094] If you can also Figure 4 As can be seen, for example, the end user can use the terminal or via the agent 22 to perform the following actions: subscribe to services / purchase one-day / one-week tickets; book trains, reserve cars / ride sharing; transportation boarding / disembarkation permissions / records; post-disembarkation processing (e.g., customer surveys, refunds, or delay compensation), etc.

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

[0096] The passenger journey management function 23b is configured to perform several actions and communicate with the terminal 21. For example, regarding multimodal transport passes, it manages, for example, subscriptions to MaaS monthly services and purchases of day tickets, week tickets, etc. Regarding journey planning (or journey planner), it provides destination input, routing / transport options, reservation / travel arrangements, and issues tickets and issues ticket IDs, generates passenger's itineraries and issues itinerary IDs, etc. On a passenger / user's journey, the passenger journey management function is configured to start the journey, and for each part of the journey (trip), check pass / ticket holdings and record embankments, record disembarkations, and add journey logs to the blockchain, and at the end of the journey terminate it and close the trip.

[0097] The blockchain management function 24a communicates with the passenger journey management function 23b and other block management 25. It is configured to add, verify / execute consensus protocols and read blockchains. In addition, it can also be obtained from Figure 4 As can be seen in FIG, at least the pass, ticket and journey log information is communicated between the passenger journey management function 23b and the blockchain management function 24a, and between the blockchain management function 24a and other blockchain management 25.

[0098] In the following, reference Figure 5 An embodiment of a blockchain 30 including a passenger's journey history is described.

[0099] Also as reference Figure 1 Generally speaking, the blockchain 30 has a number of blocks 30a, 30b, 30c, wherein Figure 5 , a past block 30a (block #N-1), a current block 30b (block #N), and a subsequent or next / future block 30c (block #N+1) are exemplarily shown.

[0100] Each of the blocks 30a, 30b, 30c may include one or more passenger logs in transactions within a maximum given block size and an associated data structure. Figure 5 , block 30a (block #N-1) on the left hand side processes two passenger logs 31a and 31b. The hash output from the N-1 block 30a is provided to the next N block 30b (current block). Block 30b (block #N) processes the next journey logs 32a and 32b of passengers A and B, and additionally processes the journey log 32c of passenger C's journey. For example, if passenger D issues a new journey log, but if the block size limit is exceeded at the same time, a further journey log is processed in the next block (i.e., in block 30c of the present embodiment), which includes a further journey log 33a entry for passenger B, a further journey log 33b entry for passenger C, and a further journey log 33c entry for passenger D, so that block 30c (block N+1) processes the next journeys of passengers C and D and the remaining logs of passenger D. The hash output (N+1) is then provided to the next block (N+2) ( Figure 5 not shown).

[0101] Typically, the journey log in the blockchain 30 may include at least one of the following information:

[0102] - Issuers: Multimodal transport pass issuers, mobility service providers / transport operators, passenger IDs (anonymized data).

[0103] - Ticket information: type of ticket, type of transport (rail, ride-sharing, etc.), seat reservation (train / seat number), price or ticket, terms and conditions.

[0104] - Ride records: location of embankment, its time / day, location of alighting, its time / day, not used / used.

[0105] - Notes: Special considerations (e.g., cancellations, delays).

[0106] In some embodiments, it is assumed that the blockchain for MaaS uses a permissioned blockchain. In a permissioned blockchain, only permissioned operators (forming a consortium) can add / read blocks, and limited participants are allowed to join the validation of transactions (i.e., consensus with trusted players). Thus, in some embodiments, for example, mobility service providers are organized in a consortium, and only mobility service providers with corresponding permission are allowed to access the permissioned distributed ledger or blockchain, while malicious participants or dishonest participants cannot join the consortium of the blockchain.

[0107] In the following, reference Figure 6 An embodiment of a communication network 40 for a (permissioned) blockchain providing MaaS is described.

[0108] In terms of resiliency, the communication network 40 reduces the risk of single point of failure (SPOF), which is usually a weak point of the system, for example, for conventional systems that rely heavily on a server center, the single point of failure (SPOF) may be a SPOF in the system.

[0109] If you can Figure 6 As seen in the figure, the communication network 40 has a plurality of nodes (or entities) 41 (large circles) 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.

[0110] In addition, there are multiple passengers 42 (small circles) that can communicate with the mobility service provider's node 41. The mobility service provider nodes 41 can together form a permissioned blockchain that provides MaaS (e.g., Figure 5 A communication network 40 of the blockchain 30).

[0111] For example, the passenger 42 subscribes to a monthly MaaS service provided by a mobility service provider or communicates with the passenger 42 via a terminal (e.g. Figure 4 The terminal 21 in communicates with the associated mobile service provider to purchase a day / week pass for the multimodal transportation service.

[0112] As mentioned, the mobility service provider 41 may be a new service provider such as a MaaS operator (eg, ride-sharing), a bike-sharing service provider, a travel agency, in addition to conventional transport operators such as car-rail companies, transit operators.

[0113] The mobile service providers 41 are connected to each other through a communication network, which is a logical connection where a direct connection between operators or mobile service providers is not necessarily required, but low latency and high throughput may be required.

[0114] The entity or node 41 of the mobile service provider may have various functions, but there are two main functions, as also described above for Figure 4 The passenger management function supports the reservation of seats, reservation of seat reservation for ride-sharing / taxi / car rental / train, monthly subscription or purchase of one-day ticket, etc. Like a normal e-commerce website, it provides a user interface for website or smartphone backend processing.

[0115] On the other hand, the blockchain is hidden from the end user in this embodiment, but is accessed by and through multiple mobile service providers. In addition, in this embodiment, a consortium (permissioned) blockchain is implemented between nodes 41, which verifies the blockchain ledger between mobile service providers that are members of the consortium.

[0116] In some implementations, the above embodiment is extended to international MaaS operations or MaaS operations in different regions. Then, the blockchain is defined as a multi-layer structure. The first layer blockchain is configured between countries or regions, and the second layer blockchain is configured in the regional alliance. For example, a representative supplier in the regional alliance can join the first layer blockchain and handle international services.

[0117] As mentioned, some embodiments involve the separation of a user's personal information in a service subscription / user profile.

[0118] In some embodiments, Figure 7 As shown, as a first step, the sensitive information of the main (all) data 50 of the passenger (user) is separated. Here, the all data 50 includes personal (sensitive) information (e.g., passenger name, home address, phone number, gender, age, passport number, credit card number, etc.) and non-sensitive data such as journey data or journey statistics. Figure 7 As shown, all data 50 are divided into non-sensitive data 50a and sensitive data 50b, so that the non-sensitive data 50a and the sensitive data are separated from each other.

[0119] For subscription to MaaS services, passengers may be required to enter personal data such as name, age, home address, telephone number, credit card number, passport number / travel document, etc. These may be a mix of sensitive and non-sensitive (non-identifying) data.

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

[0121] For example, if a mobile service provider has credit card information, in some embodiments, it must comply with industry security standards such as the Payment Card Industry Data Security Standard (PCI Standard). Therefore, in such embodiments, a firewall is used to protect the database and network from external networks.

[0122] This means that in some embodiments, the database for sensitive information is also associated with the blockchain nodes and their network (such as Figure 6 The nodes 41 and the network 40 in are separated.

[0123] Also shown are blocks 55 and 55 of the blockchain. Figure 8 As shown in FIG. 1 , in some embodiments, this separation of sensitive information and non-sensitive information is performed using off-chain technology, as also shown in FIG. 10 , blocks 55 and 56 of the blockchain. Figure 8 shown.

[0124] In this embodiment, the relationship between the passenger’s personal data and the blockchain is not bound. Therefore, sensitive data ( Figure 7 50b) is not included in the blockchain (also called off-chain). Personal data (sensitive data) is stored internally by the MaaS provider (e.g., database, storage, etc.) and is not added to the blockchain.

[0125] Figure 8 An example of a ticket and journey log for a MaaS service is shown. The ticket may be issued by a ticket or pass issuer (e.g. a transport operator) or other MaaS service provider. In the blockchain, the passenger name or any personal data is not included, but only the (unique) ticket number is included in the data structure of blocks 55 and 56 of the blockchain together with other data such as who issued the ticket (pass issuer #1 etc.), who is the mobility service provider, the price of the ticket number associated with the specific passenger and a journey log identifier.

[0126] For example, in this embodiment, the blockchain is open to other members of the consortium, but they can only see the ticket number and not the sensitive data of the passenger (user). It is not known who the actual passenger is in the blockchain. Only the ticket or pass issuer (or MaaS provider) can identify the actual passenger name and identity because he has sensitive information stored in his database separate from the blockchain and associated with the ticket number.

[0127] However, generally, in the transportation industry or the tourism industry, it is known that a Passenger Name Record (PNR) is required in some instances (see also Wikipedia https: / / en.wikipedia.org / wiki / Passenger_name record).

[0128] Thus, for example, a reservation system provided by a mobile service provider should retain the passenger's personal data because boarding is generally not allowed if the name on the ticket does not match the name in the passport.

[0129] In an embodiment applying the discussed off-chain technology, for example, a blockchain member requests the required information from a MaaS provider having the passenger's personal data based on the ticket number or any other identification associated with the passenger.

[0130] However, in some embodiments, off-chain techniques cannot be applied, and therefore, in some embodiments, the passenger's personal data in the blockchain is subject to pseudonymization and / or anonymization (see next section).

[0131] In the following, implementations involving pseudonymization and anonymization of personal data in blockchain are discussed.

[0132] As discussed, if personal data like a passenger’s name needs to be included in a block on the blockchain, the name (or any other personal data) should be protected.

[0133] In some embodiments, personal data is replaced, and a typical way of pseudonymization is to replace sensitive parts with characters or numbers, or to zero-fill, or even remove them. For example, initials or other abbreviations are used instead of full names or user ID numbers are used instead of full names, etc. In some embodiments, personal data is removed. However, personal information can be guessed or inferred and / or user information can be tracked from other information.

[0134] In the following, further embodiments for pseudonymization and anonymization are discussed.

[0135] In some embodiments, scrambling (masking) is implemented, and also Fig. 9 It is shown in Fig. 9 , a method 60 of pseudonymization using scrambling is shown.

[0136] The input data 61 is divided into two parts, namely, an unprotected part 62 including the pass issuer information and a protected part 63 including personal data (ie, passenger ID).

[0137] The data of the protected part 63 is input as a stream to the scrambling process 64 ("+"). In the scrambling process 64, the protected part 63 and the scrambling code 65 are applied to each other (mathematical exclusive OR calculation). As output data, pseudonymized passenger data 66 is generated, which is combined with the unprotected part 62 as output 67.

[0138] Thus, after scrambling, other members in the consortium (e.g., mobile service providers) cannot identify the actual user in the blockchain, but only the pass issuer (which knows the scrambling code, or any other entity that knows the scrambling code) can descramble and de-mask the passenger ID, for example.

[0139] In general, there are various ways to generate scrambling codes, and the present disclosure is not limited to a specific implementation in this regard, but in some embodiments, a linear feedback shift register (LFSR) is used. In some embodiments, the scrambling code is also configurable and is selected from a large number of candidate codes, so that it can be similar to an encryption key.

[0140] In some embodiments, the scrambling technique allows for a simple hardware / software algorithm and the scrambling is generally reversible (at least as long as the scrambling code is available). If necessary or desired, the original source of the data can descramble it.

[0141] However, in some implementations, reversibility may not be required. For example, if there are malicious members among the blockchain members, the user ID can be identified and the information can be obtained, and therefore, in some implementations, a non-reversible implementation is required.

[0142] In the following, implementations utilizing secret key encryption are discussed. In principle, scrambling and encryption are similar processes, but their purpose and design are different.

[0143] The main purpose of scrambling is data masking, and there is no secret key, but only a code number (i.e., the initial value of the shift register) is set. If someone accidentally sets the same code, it is easy to descramble the data. In addition, the scrambling of the data may be vulnerable to trying all possible combinations, i.e., descrambling based on a brute force attack may be possible. However, scrambling generally involves only a light processing load and is easy to handle, so that in some embodiments scrambling is also implemented between trusted members (e.g., in a federation of trusted members).

[0144] On the other hand, the main purpose of encryption is to provide confidential data. The encryption algorithm is usually open to everyone, and it can be decrypted using, for example, a public key (if PKI). This is especially useful for public / untrusted combinations, as in the case of the Internet.

[0145] However, encryption may involve a heavy processing load for decryption, complex algorithms, and may also not be freely available but may be protected, for example, by intellectual property rights.

[0146] As discussed above, GDPR requires an irreversible process for anonymizing data. For example, if the data is openly provided to third parties, personal data must be anonymized.

[0147] Fig.10 Detailed description of an embodiment of a method 70 for anonymizing data is shown in FIG. 7 , wherein a hash function 71 is used for anonymizing the data.

[0148] In general, a hash function is any function that can be used to map input data to output data using a specified algorithm. The size of the input data may be large and varied, whereas the output of the data may be compact and may be of a fixed size.

[0149] The inputs to the hash function 71 are personal data 72 (or any data that needs to be protected) and a hash salt 73 (or any initialization random value).

[0150] The output of the hash function is anonymized personal data 74, which is a unique value responsive to the input value, wherein the hash output 74 is irreversible.

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

[0152] In some embodiments, the salt key is changed each time it is applied, for example, so that this enhances anonymization because in this case, even if the input is the same user ID again, the output is different because a different salt is used.

[0153] Thus, in this embodiment, due to the use of hashing, the anonymization of the data is non-reversible, thereby also providing untraceability. In some embodiments, this untraceability property is suitable for perfecting anonymization, where the original data can be accessed after the hash output.

[0154] Thus, in some embodiments, the method 70 is particularly useful for permanently removing personal data, such as when the data is provided to a third party for statistical / big data analysis.

[0155] As mentioned, some embodiments relate to access control to a distributed ledger or blockchain.

[0156] The overall advantage of a distributed ledger is that all members can access a distributed database. However, in some embodiments, personal information should be protected and should not be shared without restriction, and therefore, in some embodiments, data access is restricted depending on the purpose of data use.

[0157] Typically, access control, depending on the purpose of data use, may involve the following and / or may have the following characteristics (alone or in combination):

[0158] - Pass issuers or other mobility service providers responsible for service subscriptions: As also discussed above, such providers have sensitive information about customers / passengers who subscribe / purchase services. This sensitive information, including personal data, should be protected, where pseudonymization is required to be written to blocks of the blockchain.

[0159] -Ticket Issuer / Transport Operator: Ticket issuer / transport operator maintains relevant information in compliance with transport regulations. Depending on the type of transport (e.g., air, rail, bus, etc.) and the type of ticket (e.g., registered passenger only), the required information may be different. Transport operators do not access unnecessary information. In this case, pseudonymization is required to write blocks to the blockchain.

[0160] - Data analysis by third parties: Third parties should not have access to sensitive information. Therefore, third parties should not be able to identify personal information and should not have access to pseudonymized data. Therefore, in this case, anonymization is required before data access.

[0161] - Passengers: Passengers have the right to control their own information and delete it, but they are not allowed to access other passengers' information, and they cannot directly access the blockchain or distributed ledger.

[0162] - Emergency - Public Safety: Public safety authorities can access a passenger's full information in an emergency. A special encryption key is required to access a passenger's full information.

[0163] As mentioned, in some embodiments, a permissioned blockchain is implemented, and in a permissioned blockchain (e.g., a consortium), only permitted entities can access the distributed ledger / blockchain.

[0164] In theory, the security level of the consortium is higher than that of the public blockchain. However, in some implementations, encryption with individual keys is also beneficial for access control.

[0165] Now refer to Fig.11 An embodiment of a method 80 for access control to a blockchain using encryption is discussed.

[0166] First, the sensitive data should be encrypted with a first key 81 (master key) which is known only to the MaaS provider that has a contract with the user associated with the user profile data. This key should not be shared with other MaaS providers or any third party except in emergency situations. Therefore, the data is not shared with other parties. 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 journey management function 82b, so that the user profile data (sensitive data) and the passenger journey data (non-sensitive data) are separated from each other and can also be processed differently and separately.

[0167] The user management function 82 communicates with the blockchain management function 83 , which in turn communicates with one or more blockchains 84 .

[0168] In this embodiment, a firewall 85 is set 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.

[0169] As mentioned, the master key 81 is used to encrypt sensitive data so that the sensitive data is protected by the firewall 85 and encryption.

[0170] Secondly, the MaaS provider generates a second key 86 (the service provider key). This second key 86 can be shared with other MaaS providers and can be used for the blockchain, i.e. for encryption of data stored in blocks in the blockchain 84 by the blockchain management function 83.

[0171] If the members accessing the blockchain 84 are highly trusted, and the number of members is not large or the members do not change frequently (e.g., in a consortium), private key encryption is still preferred.

[0172] For example, the same key can be used for a long time. Or even in some embodiments it is possible to only scramble using a special sequence generator without a key, in which case key distribution can be avoided.

[0173] If members cannot be trusted or there are specific reasons, such as the blockchain is stored overseas, public key encryption should be used.

[0174] Other mobile service providers also access the blockchain 84 through a blockchain management function 87 that is separated from the third party's blockchain management function 88 via a firewall 89.

[0175] In addition, a third secret key 90 shared with a third party is provided so that the third party can access information of the blockchain protected by the third secret key 90.

[0176] Reference now Fig.12 The principles of data protection in blockchain are discussed in more detail.

[0177] Here, also as mentioned above, it is assumed that the MaaS operator 95 has a contract with the passenger, and therefore, the MaaS operator 95 also has the passenger's sensitive information and data.

[0178] Transport provider / operator #1 issues a ticket 96 based on the MaaS operator contract with the passenger, but Transport operator #1 does not have the passenger information details.

[0179] The MaaS operator has details of the passenger information, i.e. sensitive information, and inserts it into the ticket issued by Transport Operator #1, encrypted using the public key encryption of the specific transport operator (in this case, Transport Operator #1). As discussed above, this information is placed into the block comprising the ticket 96 of the blockchain.

[0180] If you can Fig.12 As can be seen, in the present embodiment, each transport operator is provided with its own public key, and here, it is assumed that the MaaS operator has all the public keys in advance.

[0181] Transport provider / operator #1 can decrypt the protected data in the block received from the blockchain using its own private key. The secret private key is not shared with other transport operators.

[0182] Thus, in this embodiment, other transport operators or even third parties may have access to the blockchain, but will not be able to decrypt the protected data because their secret private key is different.

[0183] In some embodiments, the data is, in principle, open data. Therefore, the third key (see Fig.11 ) should be shared with other third parties for data analysis (for example, for obtaining statistics, big data analysis, etc.).

[0184] In the following, reference Fig.13 Discuss implementation methods for open data access involving third parties.

[0185] Here, typically, the transport operator has a third party public key 100 for the open data. The third party secret key is shared with multiple third parties who wish to use it for data analysis. Transport operator #1 inserts the data into a block as shown in block 101 using 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 secret key 100 for the open data, but as discussed above, cannot decrypt protected data encrypted using a private key known only to, for example, the mobile service provider.

[0186] If more than one third party key is used, then in some embodiments multiple levels of access control (depending on the level of data confidentiality) or group-specific access control (depending on the group to which the third party belongs) may be provided.

[0187] In some embodiments, protected data (i.e., sensitive data) in a block can be anonymized. Fig.14 As shown, in some embodiments, anonymized data and open data are combined in a blockchain.

[0188] Here, Transport Operator #1 (Ticket Issuer) uses the above reference Fig.10 The salt and hashing method discussed generates anonymized data (e.g., passenger name) that is entered into block 105 of the blockchain. Block 105 also has open data (e.g., destination) encrypted using a third public key. In addition, as also discussed above, the ticket number and ticket issuer #1 are stored in the block.

[0189] The third public / secret key is shared with other parties and can be used to decrypt the open data in block 105, while the anonymized data cannot be decrypted and cannot be identified, as discussed above.

[0190] Some embodiments involve application programming interfaces (APIs), such as Fig.15 API 110 etc. are shown.

[0191] Fig.15 Basically corresponds to Fig.11 , and the same reference numerals also denote the same entities and functions. Fig.11 The implementation method and Fig.15 The only difference between the implementations of Fig.15 In an embodiment, a database 110 for big data is provided, and the database 110 also provides an API that can be accessed by a third party for big data analysis function 111.

[0192] The transportation statistics / data stored in the big data database 110 may be useful for public and commercial purposes. For example, the government may use it for urban planning, and private companies may determine the location of new stores based on it. In this embodiment, the big data is generally accessible and available to a wider range of third parties using an open application interface (API) 110.

[0193] The mobile service provider or a trusted database provider on behalf of the mobile service provider stores data in the database 110 without sensitive information. The mobile service provider or the trusted database provider provides an API 110 for accessing the database to an external third party. The external third party can access the database 110 without a key (optionally with a key).

[0194] The API 110 may include identity checks to prevent malicious access. For example, the API may support an authentication protocol similar to OAuth 2.0 (RFC 6749) (https: / / oauth.net / 2 / ).

[0195] In some embodiments, sensitive data may be erased from the blockchain, and in the following, reference is made to Fig.16 and Fig.17 Implementations involving erasure of sensitive data are discussed.

[0196] Typically, because blockchain was originally intended for permanent data storage, blockchain is implemented so that data cannot be erased.

[0197] In the first embodiment, Fig.16 As shown, the method 115 for erasing sensitive data from a blockchain maintains the sensitive data in the blockchain or erases the data, but invalidates the secret key.

[0198] However, even if the data is retained in the blockchain, if the decryption key does not exist, it is equivalent to erasing the data, although this is not strictly erasure because the data still exists, but it can no longer be decrypted.

[0199] In this embodiment, it is assumed that there is a host (typically a MaaS provider with a contract with the passenger) that manages the blockchain 116. At 117, one member requests that the data be erased, while another member has the blockchain and the key to decrypt the data.

[0200] Therefore, the flow in method 115 is as follows.

[0201] At 117 , as mentioned, one or more members of the alliance of mobile service providers request from the host 116 to delete the personal data (or any sensitive data) in the block.

[0202] At 118, the host 116 sends / broadcasts a request to invalidate the key to other blockchain members in the consortium.

[0203] At 119 , the other blockchain members delete the key and at 120 send a confirmation to the host 116 .

[0204] At 121, the host sends confirmation of data erasure to the requester.

[0205] There are various ways to invalidate a key. In some embodiments, the key has a timer or validity time / date (or the data itself has a validity timer), and after the time / date expires, the key can be automatically deleted, or after the time / date expires, the decryption algorithm can reject the key.

[0206] Fig.17 Another embodiment of a method 125 for erasing sensitive data from a blockchain is shown in , wherein the blockchain is erased after the consortium members reach a consensus, and wherein like reference numbers represent like entities and functions or method steps.

[0207] Advantageously, in a permissioned blockchain (consortium type), the blockchain within the consortium members can be freely managed.

[0208] If already targeted Fig.16 As discussed in the embodiments of FIG. 1 , it is assumed that there is a blockchain managed host 116 (typically a MaaS provider that has a contract with the passenger).

[0209] One member of the consortium requests to erase (sensitive) data, where another member has the blockchain and its associated keys.

[0210] Therefore, the process is as follows:

[0211] At 117, one (or more) members request from the host 116 to delete the personal data (or any sensitive data) in the block.

[0212] At 118', the host 116 sends / broadcasts a request for block erasure to other blockchain members, where the request may be to erase a specific portion of a block, multiple blocks, or an entire portion of the blockchain (i.e., the entire blockchain).

[0213] The other blockchain members check if it is acceptable. If not, the other blockchain members send an approval command to the host 116 at 126. For example, if the revenue sharing calculation has not been completed, the other members can send a rejection or wait command.

[0214] At 127, it is checked whether there is a consensus based on the command received at 126. If there is a consensus to delete the block, the host sends / broadcasts the corresponding command 127a to delete the block, otherwise, the blockchain is not erased. At 127b, each member deletes the block according to the command.

[0215] At 128, the member sends confirmation of the successful block deletion to the host 116, and at 129, the host sends confirmation of the data erasure to the requestor.

[0216] Generally, as discussed, it is known to anonymize data using a hash function. An anonymization engine can be used to convert a user ID or personal identifier into anonymized data. The anonymized data can be aggregated and stored in a central module. Anonymization prevents data miners from identifying individuals in the data. In some embodiments, as discussed herein, such anonymization is applied to a blockchain or distributed ledger.

[0217] Furthermore, as discussed above, although it is generally known to store sensitive data in a blockchain or distributed ledger, in some embodiments, the present disclosure provides for dividing the data into a sensitive portion and a non-sensitive portion and not storing the sensitive portion in the blockchain.

[0218] In the following, reference will be made to Fig.18 An embodiment of a general purpose computer 130 is described. The computer 130 can be implemented so that it can be used as basically any type of network device, for example, a base station or a new radio base station, a transmission and reception point or a communication device, such as a user equipment described herein, a (end) terminal device, etc. The computer has components 131 to 141 that can form a circuit, such as any one of the network devices and communication devices described herein.

[0219] Implementations using software, firmware, programs, etc. for performing the methods described herein may be installed on the computer 130, which is then configured as appropriate for the particular implementation.

[0220] The computer 130 has a CPU 131 (central processing unit), which can execute various types of processes and methods described herein according to programs stored in a read-only memory (ROM) 132, stored in a memory 137 and loaded into a random access memory (RAM) 133, stored on a medium 140 that can be inserted into a corresponding drive 139, etc., for example.

[0221] The CPU 131, ROM 132 and RAM 133 are connected to a bus 141, which in turn is connected to an input / output interface 134. The numbers of CPUs, memories and storage are exemplary only, and the skilled person will recognize that the computer 130 may be adapted and configured accordingly to meet specific requirements that arise when the computer 130 is used as a base station or user equipment (end terminal).

[0222] At the input / output interface 134, several components are connected: input 135, output 136, memory 137, communication interface 138 and drive 139 into which a medium 140 (compact disk, digital video disk, compact flash, etc.) can be inserted.

[0223] Input 135 may be a pointing device (mouse, graphics table, etc.), keyboard, microphone, camera, touch screen, etc.

[0224] The output 136 may include a display (liquid crystal display, cathode ray tube display, light emitting diode display, etc.), a speaker, etc.

[0225] The storage 137 may have a hard disk, a solid state drive, or the like.

[0226] For example, the communication interface 138 may be adapted to communicate via a local area network (LAN), a wireless local area network (WLAN), a mobile telecommunication system (GSM, UMTS, LTE, NR, etc.), Bluetooth, infrared, etc.

[0227] It should be noted that the above description relates only to an example configuration of the computer 130. Alternative configurations may be implemented with additional or other sensors, storage devices, interfaces, etc. For example, the communication interface 138 may support other radio access technologies besides the mentioned UMTS, LTE and NR.

[0228] When the computer 130 is used as a base station, the communication interface 138 may further have a corresponding air interface (e.g., providing E-UTRA protocols OFDMA (downlink) and SC-FDMA (uplink)) and a network interface (e.g., implementing protocols such as S1-AP, GTP-U, S1-MME, X2-AP, etc.). In addition, the computer 130 may have one or more antennas and / or antenna arrays. The present disclosure is not limited to any particularity of such protocols.

[0229] refer to Fig.19The user equipment UE 150 and eNB 155 (or NReNB / gNB) for implementing the embodiments of the present disclosure and the implementation of the communication path 154 between the UE 150 and the eNB 155 are discussed. The UE 150 is an example of a communication device, and the eNB is an example of a base station (ie, a network device), but the present disclosure is not limited in this regard.

[0230] The UE 150 has a transmitter 151, a receiver 152, and a controller 153, wherein, generally, technical functions of the transmitter 151, the receiver 152, and the controller 153 are known to technicians, and thus a more detailed description thereof is omitted.

[0231] The eNB 155 has a transmitter 156, a receiver 157, and a controller 158, wherein here, generally, the functions of the transmitter 156, the receiver 157, and the controller 158 are also known to technicians, and thus a more detailed description thereof is omitted.

[0232] The communication path 154 has an uplink path 154 a from the UE 150 to the eNB 155 and a downlink path 154 b from the eNB 155 to the UE 150 .

[0233] During operation, the controller 153 of the UE 150 controls reception of downlink signals through the downlink path 154 b at the receiver 152 , and the controller 153 controls transmission of uplink signals through the uplink path 154 a via the transmitter 151 .

[0234] Similarly, during operation, the controller 158 of the eNB 155 controls the transmission of downlink signals over the downlink path 154b at the transmitter 156, and the controller 158 controls the reception of uplink signals over the uplink path 154a at the receiver 157.

[0235] Further summarizing, as is apparent from the description, some embodiments relate to a communication network node for providing data to a distributed ledger, wherein the node has circuitry configured to: provide a user data management portion for separating sensitive user data (e.g., passenger name, home address, telephone number, gender, age, passport number, credit card number, etc.) from non-sensitive user data (e.g., journey data or journey statistics, etc.); and provide the non-sensitive user data to the distributed ledger. The communication network node may be a network device such as a base station, eNodeB, etc., but the node may also be configured as a communication device, such as a user equipment, (end) terminal device, etc. (e.g., a mobile phone, smart phone, computer, laptop, notebook, etc.) with correspondingly configured circuitry.

[0236] In some embodiments, the circuitry is further configured to store the sensitive user data in a database of the node, whereby the node may include a database or it may be connected to or associated with a database.

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

[0238] Thus, in some embodiments, sensitive user data is stored only in the node's database, while the distributed ledger or blockchain includes only non-sensitive user data.

[0239] In some implementations, the distributed ledger includes data for mobility-as-a-service.

[0240] In some embodiments, access to the distributed ledger is granted based on permissions, where a node may be part of a federation. The federation may be provided by mobile service providers, where, for example, each node may correspond to or may be associated with a mobile service provider.

[0241] Some embodiments relate to a communication network having a plurality of nodes for providing a distributed ledger, wherein at least one node has circuitry configured to provide a user data management portion for separating sensitive user data from non-sensitive user data; and provide the non-sensitive user data to the distributed ledger.

[0242] The communication network may be configured as a telecommunication network, wherein the telecommunication network may be configured as a mobile telecommunication network. The nodes of the communication network may be configured such that they provide a distributed ledger.

[0243] In some embodiments, as discussed, the circuitry is further configured to store the sensitive user data in a database of the node.

[0244] As discussed, the distributed ledger may include a blockchain, wherein the blockchain may include a plurality of blocks, the blocks include non-sensitive user data, and wherein the distributed ledger may include data for mobility as a service. Thus, in some embodiments, the communication network and its nodes are configured to provide MaaS.

[0245] In some implementations, access to the distributed ledger is granted based on permissions, where a node may be part of a consortium (e.g., a MaaS consortium).

[0246] In some embodiments, personal user data (e.g., a name or other data that may uniquely identify a user) in a distributed ledger is pseudonymized or anonymized. As discussed above, for example, because for an airline ticket, the passenger's name is known for boarding, the personal user data can be entered into the distributed ledger.

[0247] In some embodiments, the personal user data is pseudonymized by scrambling the sensitive user data, and wherein the personal user data may be anonymized based on applying a hashing algorithm.

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

[0249] In some embodiments, access control provides different keys for different parties so that different parties can obtain different levels of access. The different parties may be, for example, nodes with sensitive data, other nodes that access the distributed ledger (e.g., may be part of a consortium), and third parties that neither have sensitive data nor access to the distributed ledger or are not part of a consortium, do not provide MaaS, or only need the data for data analysis.

[0250] In some implementations, access control gives access to non-sensitive user data through an application programming interface.

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

[0252] Some embodiments relate to a method for controlling a communication network having a plurality of nodes for providing a distributed ledger (as discussed herein), as discussed in detail above, the method comprising: providing a user data management portion for separating sensitive user data from non-sensitive user data; and providing the non-sensitive user data to the distributed ledger. For example, all steps discussed herein performed by the communication network and / or by the communication network nodes may be part of the method.

[0253] In some embodiments, the methods discussed herein are also implemented as computer programs, which, when executed on a computer and / or a processor and / or a circuit, cause the computer and / or the processor and / or the circuit to perform the method. In some embodiments, a non-volatile computer-readable recording medium is also provided in which a computer program product is stored, which, when executed by a processor such as the above-mentioned processor, causes the methods described herein to be performed.

[0254] It should be appreciated that the embodiments describe methods with an exemplary order of method steps. However, the specific order of method steps is given only for illustrative purposes and should not be interpreted as being binding.

[0255] If not stated otherwise, all units and entities described in this specification and claimed in the appended claims may be implemented as, for example, integrated circuit logic on a chip, and if not stated otherwise, the functions provided by such units and entities may be implemented by software.

[0256] To the extent that the embodiments of the present disclosure described above are implemented at least in part using software-controlled data processing equipment, it should be understood that providing such software-controlled computer programs and providing transmission, storage or other media for such computer programs are contemplated as aspects of the present disclosure.

[0257] It should be noted that the present technology can also be configured as follows.

[0258] (1) A communication network node for providing data to a distributed ledger, wherein the node includes circuitry configured to:

[0259] Providing a user data management portion for separating sensitive user data from non-sensitive user data; and

[0260] Providing non-sensitive user data to a distributed ledger.

[0261] (2) A communication network node according to (1), wherein the circuit is further configured to store the sensitive user data in a database of the node.

[0262] (3) A communication network node according to (1) or (2), wherein the distributed ledger includes a blockchain.

[0263] (4) A communication network node according to (3), wherein the blockchain comprises a plurality of blocks, each of which comprises non-sensitive user data.

[0264] (5) A communication network node according to any one of (1) to (4), wherein the distributed ledger includes data for mobility as a service.

[0265] (6) A communication network node according to any one of (1) to (5), wherein access to the distributed ledger is granted based on permissions.

[0266] (7) A communication network node according to (6), wherein the node is part of a federation.

[0267] (8) A communication network comprising a plurality of nodes for providing a distributed ledger, wherein at least one of the nodes comprises a circuit configured to:

[0268] Providing a user data management portion for separating sensitive user data from non-sensitive user data; and

[0269] Providing non-sensitive user data to a distributed ledger.

[0270] (9) The communication network of (8), wherein the circuit is further configured to store the sensitive user data in a database of the node.

[0271] (10) A communication network according to (8) or (9), wherein the distributed ledger includes a blockchain.

[0272] (11) A communication network according to (10), wherein the blockchain includes multiple blocks, each of which includes non-sensitive user data.

[0273] (12) A communication network according to any one of (8) to (11), wherein the distributed ledger includes data for mobility as a service.

[0274] (13) A communication network according to any one of (8) to (12), wherein access to the distributed ledger is granted based on permissions.

[0275] (14) A communication network according to (13), wherein the node is part of a federation.

[0276] (15) A communication network according to any one of (8) to (14), wherein personal user data in the distributed ledger is pseudonymized or anonymized.

[0277] (16) A communication network according to (15), wherein personal user data is pseudonymized by scrambling sensitive user data.

[0278] (17) A communication network according to (15), wherein personal user data is anonymized based on applying a hashing algorithm.

[0279] (18) A communication network according to any one of (8) to (17), wherein access control is provided for non-sensitive user data.

[0280] (19) A communication network according to (18), wherein access control is performed based on a secret key used to encrypt non-sensitive user data.

[0281] (20) A communication network according to (19), wherein access control provides different keys for different parties.

[0282] (21) A communication network according to any one of (18) to (20), wherein access control provides access to non-sensitive user data through an application programming interface.

[0283] (22) A communication network according to any one of (8) to (21), wherein personal user data or non-sensitive user data can be erased in response to a request from at least one node.

[0284] (23) A communication network according to (22), wherein data is erased by invalidating the key.

[0285] (24) A communication network according to (22), wherein the data is erased by erasing the data from the distributed ledger.

[0286] (25) A communication network according to (24), wherein the distributed ledger includes a blockchain, and wherein at least one block is erased.

[0287] (26) A method for controlling a communication network including a plurality of nodes for providing a distributed ledger, comprising:

[0288] Providing a user data management portion for separating sensitive user data from non-sensitive user data; and

[0289] Providing non-sensitive user data to a distributed ledger.

[0290] (27) According to the method of (26), the sensitive user data is stored in the database of the node.

[0291] (28) A method according to (26) or (27), wherein the distributed ledger includes a blockchain.

[0292] (29) A method according to (28), wherein the blockchain includes multiple blocks, each of which includes non-sensitive user data.

[0293] (30) A method according to any one of (26) to (29), wherein the distributed ledger includes data for mobility as a service.

[0294] (31) A method according to any of (26) to (30), wherein access to the distributed ledger is granted based on permissions.

[0295] (32) A method according to (31), wherein the node is part of a federation.

[0296] (33) A method according to any one of (26) to (32), wherein the personal user data in the distributed ledger is pseudonymized or anonymized.

[0297] (34) A method according to (33), wherein personal user data is pseudonymized by scrambling sensitive user data.

[0298] (35) A method according to (33), wherein the personal user data is anonymized based on applying a hashing algorithm.

[0299] (36) A method according to any one of (26) to (35), wherein access control is provided for non-sensitive user data.

[0300] (37) A method according to (36), wherein access control is performed based on a secret key used to encrypt non-sensitive user data.

[0301] (38) A method according to (37), wherein access control provides different keys for different parties.

[0302] (39) A method according to any of (36) to (38), wherein access control provides access to non-sensitive user data through an application programming interface.

[0303] (40) A method according to any one of (26) to (39), wherein personal user data or non-sensitive user data can be erased in response to a request from at least one node.

[0304] (41) A method according to (40), wherein the data is erased by invalidating the key.

[0305] (42) A method according to (40), wherein the data is erased by erasing the data from the distributed ledger.

[0306] (43) A method according to (42), wherein the distributed ledger includes a blockchain, and wherein at least one block is erased.

Claims

1. A method for controlling a communication network comprising a plurality of nodes for providing a distributed ledger, comprising: Separate sensitive user data from non-sensitive user data; providing the non-sensitive user data to the distributed ledger, storing the sensitive user data off-chain and storing the sensitive user data only in a database of the sensitive user data, which is separate from the nodes of the blockchain and its network, and Limiting access to the distributed ledger based on the purpose of data usage, Wherein, in the case where the node is a mobile service provider, the mobile service provider requires pseudonymization of the sensitive user data in order to write the sensitive user data into the blockchain, wherein, in the case where the node is a ticket issuer, the ticket issuer is limited to information that depends on the type of transport and the type of ticket, and the ticket issuer requires pseudonymization of the sensitive user data to write the sensitive user data to the blockchain, Wherein, in the case where the node provides data to a third party for data analysis, the data analysis by the third party needs to be anonymized, and Wherein, in the event that the node receives a request from a passenger to delete the passenger's data, the node allows access to the passenger to delete the passenger's sensitive user data.

2. The method according to claim 1, wherein: The distributed ledger includes the blockchain.

3. The method according to claim 2, wherein: The blockchain includes a plurality of blocks, and the blocks include the non-sensitive user data.

4. The method according to claim 1, wherein: The distributed ledger includes data for mobility as a service.

5. The method according to claim 1, wherein: Access to the distributed ledger is granted based on permissions.

6. The method according to claim 5, wherein: The node is part of a federation.

7. The method according to claim 1, wherein: Personal user data in the distributed ledger is pseudonymized or anonymized.

8. The method according to claim 7, wherein: The personal user data is pseudonymized by scrambling the sensitive user data.

9. The method according to claim 7, wherein: The personal user data is anonymized based on applying a hashing algorithm.

10. The method according to claim 1, wherein: Access control to the non-sensitive user data is provided.

11. The method according to claim 10, wherein: The access control is performed based on a secret key, and the secret key is used to encrypt the non-sensitive user data.

12. The method according to claim 11, wherein: The access control provides different keys for different parties.

13. The method according to claim 10, wherein: The access control provides access to the non-sensitive user data through an application programming interface.

14. The method according to claim 1, wherein: The personal user data or the non-sensitive user data can be erased in response to a request from at least one node.

15. The method according to claim 14, wherein: Erases data by invalidating the key.

16. The method according to claim 14, wherein: Erasing the data by erasing the data from the distributed ledger.

17. The method according to claim 16, wherein: The distributed ledger includes the blockchain, and wherein at least one block is erased.

Images